Posts

openclawで業務を全てを自動化する。 最終的にやりたいこと。 人間がやっていることをopenclawにやらせる。 予約管理システムがある。 gmailもある。 そして、運用ポリシーもある。（マニュアルはまだない） つまり、人間に仕事をやらせる準備はできているのです。 その辺をslackからopenclawに指示するだけで全部やってくれるようにしたい。 正直、これはかなり未来を感じています。 事務職が淘汰されると言われて久しいが、それを実感してしまった。 codexやclaudeではダメなのか？ これら二つのAIエージェントは、デーモンプロセスでない。 一方で、openclawはデーモンプロセス。常駐しており、マジで自律的に動くAIエージェント。 OpenClaw → 常駐してタスク実行・監視・通知までやる“運用AI” → SlackやLINE感覚で指示できる Claude Code → 大規模コードを理解して設計・改善してくれる“頭脳担当” Codex → コード生成・実行・CIまでサクサクやる“作業担当” 一言で言うと OpenClaw：「動くAI秘書（常駐エージェント）」 Claude Code：「考えてくれるシニアエンジニア」 Codex：「手を動かす高速コーダー」 と言うことなので、マジで自律的に動くAIエージェントです。 slack経由で質問して、なんでも答えてくれるようになったら、これほど便利なものはないと思っている。 定期実行もしてくれるし、何かをトリガーにして実行もしてくれる。 なんでも相談できる。どんなシステムでも、しっかりAPIを設計して、openclawと繋げることで、slack経由で非常に便利なものができると思っている。 これは、もう本当にすごいことだと思います。 アーキテクチャ slack -> openclaw(local net) -> LLM(ollama) -> (openclaw) -> gmail, system API みたいな流れでデータと処理が走る。 ollama用のopenclawをインストール 最初にnodeをインストール curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install --lts openclawをインストール ray@kami:~$ ollama launch openclaw Installing OpenClaw... npm warn deprecated node-domexception@1.0.0: Use your platform's native DOMException instead added 540 packages in 14s 89 packages are looking for funding run `npm fund` for details npm notice npm notice New minor version of npm available! 11.9.0 -> 11.11.1 npm notice Changelog: https://github.com/npm/cli/releases/tag/v11.11.1 npm notice To update run: npm install -g npm@11.11.1 npm notice OpenClaw installed successfully Select models for OpenClaw: Type to filter... Recommended ▸ glm-4.7-flash Reasoning and code generation locally, ~25GB, (not downloaded) qwen3.5 Reasoning, coding, and visual understanding locally, ~11GB, (not downloade kimi-k2.5:cloud Multimodal reasoning with subagents qwen3.5:cloud Reasoning, coding, and agentic tool use with vision glm-5:cloud Reasoning and code generation minimax-m2.5:cloud Fast, efficient coding and real-world productivity More deepseek-r1:32b gemma3:27b gpt-oss:20b mixtral:8x7b ... and 3 more Download glm-4.7-flash? Yes No ←/→ navigate • enter confirm • esc cancel glm-4.7-flashがおすすめのようなので、これを使うことにした。ちなみになんだこれ。 ...

もう避けては通れない MCPサーバを作って既存のシステムと連携させようって流れが顕著すぎるよね。 まあ、簡単に言うと、MCPサーバは既存のAPIの前に立ち、AIとのAPIを繋ぐ架け橋になるってわけだよね。 これ、って概念は簡単にわかるんだけど、やっぱり実物を作ってみないとわからんと言うことでね。 作ってみようと思います！

背景 いや、ちょっとこれも恥ずかしい話なんですがね。 僕は長いこと、「自作パスワード管理システム」的なものを運用していました。 どうやっていたかというと、 自前ホストしているRocket.Chat に、自分専用のチャンネルをひっそり立てて、 誰も入れないように鍵をかけて、 そのスレッドに “ログイン情報をラベル付きで投稿する” という、 ある意味 究極のアナログ DX をやっていたわけです。 もちろん一応、安全面は全く考えてなかったわけではなくて、 Rocket.Chat のデータは gocryptfs で暗号化されたストレージに保存 通信経路は https で暗号化 サーバは自分の管理下 チャンネルは自分しかアクセスできない と、一応「最低限の安全性」は確保しているつもりでした。 だけど、世の中ではみんな LastPass だの 1Password だの Bitwarden だのと言っているじゃないですか。 僕はこういう “流行り物” に疎いところがちょっとあって、 「パスワード管理ツールって本当に必要？」 と長年スルーしていたんですよね。 そんなとき、エンジニアの先輩から 「Bitwarden の OSS クローンで Vaultwarden っていうのがあって、自前ホストも簡単で、めっちゃ良いよ」 とすすめられました。 で、触ってみたら、UI も綺麗だし、ストレージ管理もラクだし、 正直「これはかなりイケてるな」と感じたわけです。 しかし、ここから僕の悪い癖が発動します。 “仕組みが分かっていないものに重要な情報を預けるのが嫌” これは性格なんですが、 ブラックボックスは信用できない。 暗号化の仕組みがわからないと不安になる。 果たして、 自前のサーバ（しかもレンタル）に Vaultwarden を置いて、 そこに人生の全パスワードをぶち込んで大丈夫なのか？ という疑念がどうしても消えない。 結論から言うと： Vaultwarden（Bitwarden）は、むしろ「Rocket.Chatにパスワードを書いてた頃の比じゃないほど安全」だった。 調べれば調べるほど「これは信頼できる暗号設計だな」と感じたので、 今回はその 安全性の仕組み をブログとしてまとめたいと思う。 安全性の評価 Bitwarden / Vaultwarden が扱う暗号モデルは、 いわゆる ゼロ知識暗号（Zero-Knowledge Encryption） である。 ...

いつもnatの設定を忘れてしまうのでここに残しておきたい ss@kong:~$ sudo sysctl -w net.ipv4.ip_forward=1 && \ sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -d 192.168.10.0/24 -o enp9s0 -j MASQUERADE && \ sudo iptables -A FORWARD -i tun0 -o enp9s0 -s 10.8.0.0/24 -d 192.168.10.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT && \ sudo iptables -A FORWARD -i enp9s0 -o tun0 -s 192.168.10.0/24 -d 10.8.0.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT backupのトンネルの方はこっち rr@kong:~$ sudo sysctl -w net.ipv4.ip_forward=1 && sudo iptables -t nat -A POSTROUTING -s 10.10.0.0/24 -d 192.168.10.0/24 -o enp9s0 -j MASQUERADE && sudo iptables -A FORWARD -i tun1 -o enp9s0 -s 10.10.0.0/24 -d 192.168.10.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT && sudo iptables -A FORWARD -i enp9s0 -o tun1 -s 192.168.10.0/24 -d 10.10.0.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT net.ipv4.ip_forward = 1 これ、一応意味書いておくか。 ...

SRE本を読んでいく こちら

背景 複数拠点（A, B, Cなど）を OpenVPN 経由で接続し、 **2系統のVPNトンネル（10.8.0.0/24 と 10.10.0.0/24）**を経由して経路冗長化したい。（openvpnサーバは独立した2マシン） そんなニーズから検証を始めました。 各拠点はそれぞれローカルLAN（例: 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24）を持ち、 それらを OSPF (FRRouting) で自動経路学習させて、 VPNトンネル越しに相互通信できるようにしたい、という構成です。 やりたかったこと OpenVPNで各拠点を接続（多拠点site-to-site VPN） FRR (OSPF) を使って動的ルーティング トンネルごとにコストを設定して経路選択 できれば route-nopull で手動ルーティングを制御 目標は「OpenVPNトンネルを2本走らせて、FRRで経路選択を任せる」ことでした。 これを実現するにあたり、色々とハマったので知見をまとめておこうと思います。 OpenVPNのルーティングの構造 OpenVPNはユーザランドで動作し、/dev/net/tun デバイスを通じて通信します。 Linuxカーネルはtunデバイスにパケットを出す そこから先は**OpenVPNプロセス（ユーザランド）**が受け取り、独自の内部ルーティングテーブルで転送を行う つまり、Linuxのルーティングテーブル（ip route）とは別世界で動いています。（ここが非常に大事です。openvpnサーバないのルーティングテーブルがちゃんと設定されていないと、クライアントから届いたパケットをどのクライアントに転送すればいいかがわかりません。ちなみに、openvpnのルーティングテーブルは/var/log/openvpn-status.logから確認可能です） push と route-nopull の関係 OpenVPNサーバはクライアントに対して push “route …” を送ることで、 クライアントのOSにもユーザランドにもルート情報を注入します。 一方、クライアント設定で route-nopull を有効にすると、 その push 情報をすべて拒否します。 frrでルーティングをさせたい場合には、route-nopullにしておかないと、0.0.0.0/1と128.0.0.1/1がOSのルーティングテーブルに登録され、すべてのパケットが特定のnicから出るように設定されてしまうので注意が必要（server側で**push “redirect-gateway def1 bypass-dhcp”**が入っている場合） FRR(OSPF)を組み合わせても解決しない理由 FRRでOSPFを走らせると、 VPNトンネル越しに相手拠点のLAN情報（例: 192.168.x.x/24）が学習されます。 これにより、OSレベルのルーティングテーブルは更新されます。 しかし！ OpenVPNサーバはそのOSルートを全く参照しません。 OpenVPNプロセスは独自に「このLANはどのクライアントの背後にあるか」を iroute で知っていなければ、パケットをどこに転送すべきか判断できません。 自分の場合は、openvpnサーバの/etc/openvpn/ccd以下に書くルーティングファイルの情報が間違っており、クライアント1 -> サーバはパケットが届いていたが、サーバがクライアント2宛のパケットをうまく転送できずdropしてしまっていたのが原因ですね。 ...

以前の記事 https://blog.ingenboy.com/post/problem_site2site/ こちらの記事でVPNクライアントを介して、別々のNWセグメントに所属するサーバ間で通信をする方法を軽く説目しました。 この問題は、リターンパス問題だったのですが、今回、改めてリターンパス問題について書きたい。 まず、 1. IP層での基本ルール 送信元IP と 宛先IP はパケットに埋め込まれていて、転送中は変わらない（※NATしない限り）。 各ホストやルータは「自分のルーティングテーブル」を参照して、この宛先IPはどこに渡すべきか？ を決める。 宛先が自分の直接つながっているネットワークじゃなければ、**次のホップ（ゲートウェイ）**に渡す。 今回問題が起こった構成 [jhonny] 192.168.1.4 tun0:10.8.0.14 │ (LAN:192.168.1.0/24) │ デフォルトほぼVPN (0.0.0.0/1,128.0.0.0/1 → 10.8.0.13) ▼ [家庭ルータ(1系)] 192.168.1.1 │ （インターネット側へ） ▼ [VPN Server] tun0:10.8.0.1 gw:162.x.xxx.xxx ルート: 192.168.2.0/24 → 10.8.0.2(tun0) ▼ [kami] 192.168.2.10 tun0:10.8.0.30 ルート: 192.168.2.0/24 → enp6s0(直結) ▼ [Mac] 192.168.2.3 (LAN:192.168.2.0/24) デフォルトGW: 192.168.2.1（※ここがキモ） 2. 今回の例で流れを追う（リターンパスがなくてpingが返ってこないパターン） サーバから(jhonny)Mac に ping サーバ(10.8.0.1) が「192.168.2.3にICMPを送りたい」と思う VPNトンネルを経由して kaminogou(192.168.2.10) に届く kaminogou の Linux がルーティングを見て「192.168.2.3は自分のLAN直結だからそのまま出す」 Mac の en0 で「送信元=10.8.0.1 宛先=192.168.2.3」の ICMP が見える（ここまではOK） Mac が返信するとき Mac が「宛先=10.8.0.1に返したい」と思う Mac のルーティングテーブルを見る 10.8.0.0/24 の経路が無い なのでデフォルトゲートウェイ(192.168.2.1)に投げる 192.168.2.1（家庭用ルータなど）が「10.8.0.0/24 なんて知らん」と捨てる これがリターンパス問題 問い なぜ送信元が10.8.0.1になるのか？ -> サーバから送ったからだな。完全理解。 ...

概要 2025年9月、RTX 5060 Ti を新マシンに差して Ubuntu 24.04 を入れたら…案の定ドライバ認識でドハマりしました。 この記事では、最初に遭遇したエラーから、最終的に nvidia-smi で 5060 Ti が認識されるまでの流れをまとめます。 1. 最初に出た症状 lspci では GPU が見えている（NVIDIA Corporation Device 2d04）。 しかし nvidia-smi を叩くとエラー： NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. dmesg には probe failed with error -1 が連発。 この時点では「ドライバが GPU を見つけてるけど、初期化に失敗してる」状態でした。 2. CSM と UEFI の壁 調べてみると、自分の Ubuntu は Legacy (CSM有効) モードでインストールされていたことが発覚。 最新の GPU は UEFIブート前提 なので、CSM 有効だと GPU 初期化に失敗しがちです。 対応したこと BIOS で CSM を OFF Above 4G Decoding = Enabled Resizable BAR = Enabled そして Ubuntu を UEFIモードで再インストール これで「Bootable device not found」問題も解決し、環境が最新GPUに対応できるようになりました。 ...

背景 地理、楽しいっすよね。めっちゃ好きです。 でも Google Maps って使うと、結局は Google って会社にお世話になってるわけですよ。 僕はこの「どっかの会社のお世話になっている状態」があまり好きではない。 だからサーバやデータセンターも自前運用するし、 Slack の代わりに Rocket.Chat を使うし、 JIRA ではなく Redmine を使うんです。 じゃあ Google Maps を自前で運用するにはどうするか？ これが今回のテーマです。 地図アプリがどうやって動いているか 必要なものは大きく分けて二つ。 レンダリングエンジン（地図を描画するライブラリ） マップデータ（地図そのもののソース） OSSのレンダリングエンジン（ライブラリ） Leaflet OpenLayers MapLibre GL JS それぞれでベースマップを比較できるデモも作りました。 👉 比較サイト OSSのマップデータ 選択肢は色々あります。 OpenStreetMap (OSM) 世界中のボランティアが作る地図データ。ラスタ（画像タイル）も配布されているが、見た目は少し古臭い。 実際の中身はベクタだが、配信されている地図はあらかじめ描画されているラスタタイル。（元がベクタならそれを出せばいいじゃん、、とは思った） OpenMapTiles OSMデータをベクトルタイル化するOSS。 これを使えば、Google Maps 並みにきれいなベクトル地図を完全自前で運用できる。 ラスタはやっぱり綺麗に映らないですね。なのでベクトルマップが欲しいのですが、 ベクトルマップは自分で作るしかないっぽいです。（Maptilerって会社がOSMを所有しようとしているので気をつけて） 実際に OSM → Vector Map を自前ホストする流れ 1. OSMデータのダウンロード Geofabrik から地域ごとの .osm.pbf を落とす。 例: 日本全体 https://download.geofabrik.de/asia/japan.html 2. OpenMapTiles でベクトルタイル生成 まずは GitHub から OpenMapTiles を取得します。 ...

背景 gmailの返答を自動化するプロジェクトを推進しています。 そこで、RAGですね。もうだいぶ時間が経っていますが、しっかりやっていきたいと思う。 RAG = 「Retrieval-Augmented Generation」 これを理解できればもう仕組みを理解したも同然です。 が一応説明しておきます。 RAGの仕組み めっちゃ簡単にいうと、 ベクトルデータベースに保存されたナレッジから 問い合わせと類似するナレッジを検索し引っ張り出し それを元にGEN AIに回答を作らせる という流れになります。 1でベクトルデータベースにナレッジを保存する時には、元の自然言語をベクトル表現に変換した物を格納する必要があります。 このベクトル変換器のことを「Embedding model」と言います。 x: 自然言語 f: Embedding model とすると y = f(x) で得られたy（とそれに対応するx）をベクトルDBに格納しておくわけですね。 x_q: 問い合わせが来た時 y_q = f(x_q) から得られるy_qと類似しているy_1, y_2, y_3, ,,, y_nを検索し、 それに対応するx_1, x_2, x_3, ,,, x_n を出力し、 ans = LLM(x_1, x_2, x_3, ,,, x_n) とう感じで回答を作らせるという流れです。 Embedding modelsの選定 こちらの記事に書いてある通り、Embedding modelの選定がRAG全体の回答生成性能に大きく影響する。 まあ、chatGPTに聞いた結果これが一番いいのかな。 BAAI/bge-base-en 今回RAGを構築するにあたり使うソフト vector DB: qdrant embedding model: BAAI/bge-base-en LLM: phi4 14b on ollama (@ rtx 3060 12g) Langchainなどの統合的なライブラリは使わない。なぜなら自由度が低いから。 vector DBでの検索も普通にREST APIでできるので問題なさそう。 ...