執筆者：佐藤友昭
※ 「vLLMとRDMAで構築するローカルLLMクラスタ」連載記事一覧はこちら
以下に前回 Claude Code が提案したユースケースのサマリを再掲する。前回は UC-6 を始めたところまでで、今回は UC-6 と UC-4 が終わったところからである。
| # | ユースケース | 難易度 | 即効性 | 既存資産活用 |
|---|---|---|---|---|
| UC-3 | 議事録・アクションアイテム抽出 | 低 | 高 | ◎ |
| UC-6 | process_title.sh 並列バッチ処理 | 低 | 高 | ◎ |
| UC-1 | YouTube トレンドレポート | 中 | 中 | ◎ |
| UC-2 | コードレビュー支援 | 低 | 中 | ○ |
| UC-5 | llama4 マルチモーダル図解 | 低 | 中 | ◎ |
| UC-4 | RAG ナレッジQ&A | 高 | 中 | ◎ |
| UC-7 | qwen3.5 thinking 技術調査 | 低 | 中 | ○ |
パイプラインの完成
登録 YouTube チャネルを巡回し、「音声→構造化→埋め込み→チャット」の一連処理を行うパイプラインが完成した。
3/12 に始めた全件翻訳は結局 4/7 まで掛かった。当初見込みの 152 時間から延伸した要因は外出時の中断 17 回、スクリプトのバグ 4 件、タイマー競合と担当エージェントは分析している。
私が外出の度に止めたからということらしい。処理中のマシンはちょっとした暖房機になる感じなので、外出時は用心のため止めていた。
使用する vLLM サーバを OpenClaw マシン (Z390機)上ではなく、４ノード Ray クラスタ上でテンソル並列動作させたらどの程度短縮できただろうか。
4+1 台の PC と RoCE スイッチが何日間も稼働し続ける状況は一般家庭では電力・冷却・防音上の無理があるので試していない。Z390機の 4070 Ti Super もファン回転数がフルにならないように能力をセーブして使用している。
なお、この「当初見込みの 152 時間」は 「UC-6: process_title.sh の並列バッチ処理」 作業の所要時間で、4/7 までの期間には「 UC-4: RAG（検索拡張生成）によるナレッジQ&A」の作業も並行して実施しているためその分の延伸も含まれる。
ナレッジQ&Aについては以下のような感じで動作している。最近は Claude Mythos の話題の他、光スイッチの話題が多いように感じる。
RAG の例：Claude Mythos の登場とその反響
A: Claude Mythos の登場とその反響について、YouTube動画文字起こしデータベースの情報から以下のようにまとめられます：
リリース日
- 2026年4月9日：Project Glasswingによる「Claude Mythos Preview」の発表。初期のテストでサイバーセキュリティ分野での性能が顕著に優れていることが確認され、指数関数的な性能向上が観測された。
- 2026年4月10日：GoogleとOpenAIがAIの支援能力を強化する一方、AnthropicがClaude Mythosを正式にリリース。内部文書では、前のOpusモデルよりも大幅に規模が拡大し、知能的な能力が向上していると記載されている。
- 2026年4月11日：AnthropicがClaude Mythosのリリースを発表。既存のモデル（Opus）を大幅に上回る性能を示し、OpenAIが2024年9月にリリースした「01モデル」（GPT-4.0を上回る性能）に匹敵する飛躍と評価されている。
影響と特徴
1. 性能の飛躍
- 以前のモデル（Opus）を大幅に上回る性能を発揮し、指数関数的な能力向上が確認された。
- 2024年9月のOpenAI「01モデル」の性能向上と同様の規模の進化と位置付けられている。
セキュリティと国家リスクへの注目
- リリース時に「AIが国家リスクを引き起こす可能性」というテーマを強調し、セキュリティ分野での応用が注目されている。
- 2019年にOpenAIがGPT-4に関する警告を発表した際の流れと類似した戦略が見られる。
技術的特徴
- 「完全に開くのが危険すぎる」との内部表現から、モデルの安全性や制御性に注力した設計が推測される。
- サイバーセキュリティ分野での応用が強調され、企業や政府の関心を引いている。
これらの情報は、Claude Mythosが市場に与えた影響と技術的意義を理解するための根拠となります。
RAG の例：OCI MSAに関する話題
A: OCI MSA（Optical Connectivity Multi-Source Agreement）に関する最新情報です。
- 2kmの長距離伝送：光ファイバーを通じて最大2kmの距離まで通信可能にすることで、大規模なネットワーク構築を支援するという特徴を持っています[出典1]。
- 業界標準としての位置付け：OFC 26で発表されたOCI MSA光学標準は、業界全体で採用され、 Broadcomを含む5社が参加して推進しています[出典2]。
- 2028年のタイムフレーム：AI向けの光インターコネクトにおいては、2028年までのスケーラブルネットワークの実現を目指しており、現在製品開発が進んでいます[出典3]。
参照動画
1. 「#OFC26 Building at Scale Ethernet, Optics & Next-Gen Solutions」（2026-03-27）
2. 「#OFC26 Unpacking the New OCI MSA Optical Standard」（2026-03-28）
3. 「#DCNetwork26 Optical Interconnects for AI」（2026-04-17）
AIエージェントによるシステム管理
上述の作業延伸のボトルネックになっているのは人の介入と思われるのでシステム管理の自律化について考える。
この Claude Code によるパイプライン構築実験の目的は LM 分散実行環境向けの共有ストレージを OpenClaw ベースで構築することによるメリットを探ることにあるが、現時点の機能範囲においては OpenClaw ベースである必然性はまだない。
今回の実験は旧 NFS サーバ機に vLLM + OpenClaw を導入して行っている。旧 NFS サーバ機は現在 NFS ストレージとしては稼働しておらず、実験専用の環境として使用している。有効性が確認できれば、現在 ollama + Open WebUI で稼働中の新 NFS サーバ機へ同様の構成を展開する予定である。この文脈における「OpenClaw ベースで共有ストレージを構築する」とは、ストレージ装置そのものを OpenClaw で作ることではない。NFS などの下層インフラは従来どおり構築したうえで、その機械で動作する OpenClaw のエージェント機能を活用し、LM 分散実行環境全体をソフトウェア的に管理・運用する、という意味である。なお、旧 NFS サーバ機の GPU は VRAM 16GB であり、監視系と被監視系が同一の VRAM を共有することになるため、自律運用の制約要因のひとつとなっている。新 NFS サーバ機は VRAM 32GB を搭載しており、展開の際にはこの制約が緩和される可能性がある。
OpenClaw が担っている役割を整理すると、以下のようになる。
| 役割 | 実態 |
|---|---|
| チャットUI | openclaw.json が 127.0.0.1:11438 を指しているだけ |
| RAG検索 | rag_proxy.py がHTTP層で透過的に注入（OpenClawの関知外） |
| 翻訳・文字起こしパイプライン | 純粋なBash/Pythonスクリプト群、OpenClaw依存ゼロ |
Open WebUI や任意の OpenAI 互換チャット UI に差し替えても、現在と同等の機能が得られる。
当初の構想（スキル経由で RAG を呼び出す）は Qwen3-8B が exec 指示を無視したため断念し、rag_proxy.py *1による透過注入に切り替えた。この時点で OpenClaw のエージェント機能を迂回する設計になっている。透過注入は安定しているが、「OpenClaw エージェントが判断して道具を使う」という本来のアーキテクチャではない。
OpenClaw が価値を持つとすれば、LM 分散実行環境向けという本来の目的に照らすと、以下の条件が揃ったときに差別化が生じると考えられる：
モデルが十分に instruction-following できる
スキル/exec 指示を確実に実行できるモデルが手元で動く（現在の 8B クラスでは不安定?）複数ノード・複数 LM の協調が必要になる
RAG 検索・翻訳・要約を別々の専門モデルに割り振る等、OpenClaw のエージェント調整レイヤーが意味を持つ場面ツール選択をエージェントに委ねる価値がある
毎回 RAG を注入するのではなく「必要なときだけ検索する」という判断をモデルが行う
現段階は 「ローカル LLM + 知識ベース」の実現可能性検証フェーズであり、OpenClaw はその上に乗った UI に過ぎない。本来の目的（ LM 分散実行環境の共有ストレージ）に向けて意味を持つには、エージェントが能動的にツールを使いこなせる段階まで、モデルまたはアーキテクチャが成熟する必要があると思われる。現時点は「その前段の知識インフラ整備」として位置づけるのが実態に合っている。
現在の OpenClaw 機の状態把握は M4 Max MacBook Pro 上の Claude Code / Sonnet 4.5 が SSH でアクセスし、ログを読み、判断し、Obsidian に書いている。OpenClaw 機は監視される側であり、（Claude Code エージェントの表現を借りれば）自己認識を持たない。
OpenClaw が OpenClaw 機の状態を自律管理する場合のメリット：
局所性と即時性
OpenClaw 機自身が自分のログ・サービス状態をリアルタイムに読める。SSH 越しの Claude Code エージェントよりはるかに低レイテンシで状態変化を検知できる。自律的な定型復旧
vllm-server failed → reset-failed、rag-proxy 停止 → 再起動 のような定型的な是正処理は、Qwen3-8B レベルのモデルでも十分に実行できる。cron で呼ぶよりも「状況を読んで判断する」柔軟性がある。ログ自動生成
バッチ完了後に batch_process.log を読んで YYYYMMDD.md を自動生成する、という用途には適合する。現在 Claude Code エージェントが担っている作業の大半はこれ。
OpenClaw が OpenClaw 機の状態を自律管理する場合の課題：
自分が壊れているときに自分を診断できない
vllm-webchat（Qwen3-8B を動かすサービス）が停止していると、OpenClaw 自体が推論できない。監視対象と監視主体が同一の VRAM を共有しているという根本的な循環依存がある。VRAM 競合
Whisper・Parakeet・翻訳バッチが動いている時間帯に Qwen3-8B の推論を走らせると OOM する。状態確認のタイミング自体を管理する必要があり、管理のための管理が必要になる。モデル能力の限界と自律行動のリスク
前述のスキル経由の RAG 呼び出しが失敗した経緯が示すように、Qwen3-8B は複雑な文脈下での指示追従が不安定と思われる。「サービスを停止して再起動する」「retranslate_all.sh を起動する」といった不可逆性のある操作を誤判断した場合の影響は小さくない。
Claude Code エージェントの見解：
ここで実際に担当している Claude Code エージェントの意見を聞く。
Claude Code とのチャットから抜粋：
役割分担が現実的だと考えます。
| 主体 | 適した役割 |
|---|---|
| OpenClaw 機上の OpenClaw | 定型的な自動復旧・バッチ完了後のログ記録・異常検知と通知ファイル生成 |
| Claude Code（私） | 根本原因分析・設計判断・複雑なデバッグ・重要操作の実行 |
OpenClaw 機側が「バッチ完了後にステータスを自動記録する」「vllm-server が failed になったら自動で reset-failed する」レベルの自律性を持てば、私に依頼が来る前に大半の定常作業が完結します。それは有意義です。
ただし「判断を要する操作」を OpenClaw 機側に委ねるのは、現時点のモデル能力・VRAM 構成・循環依存の問題から、まだ時期尚早だと思います。 本来の目的「 LM 分散実行環境の共有ストレージ管理」に照らせば、OpenClaw 機が自己認識を持つことは方向として正しい。ただし今の段階では「通知・記録の自律化」にとどめ、「判断・実行」は引き続き上位のエージェント（より強力なモデル）が担う二層構造が現実的な着地点だと考えます。
なるほど。この見解に概ね同意である。LM 分散実行環境の共有ストレージ（OpenClaw 機）がストレージクライアントである LM 分散実行環境を常時管理してくれるのは便利だが、自らも管理させるのは現実的ではないかもしれない。
パイプラインの利用
M4 Max MacBookPro の定時タスクで前日付の YouTube タイトルのリストを内容とするブログ記事を作成している。
4月16日分から要約に使用するモデルを google/gemma-4-31b に変更している。それまでは NotebookLM を使用しており、要約を見て興味のあるタイトルの本編を視聴するという目的どおりの使い方であったが、google/gemma-4-31b の要約は読み応えがある。4月16日分は 8 万文字を超えており、読み終えたころにはもう本編を見なくてもよいかという気分になった。これも一つの認知的降伏かもしれない。
（ note に 4/10 以降のものを公開しています。よろしければご利用ください。）
このデイリーの記事を NotebookLM に溜めて半月ごととかに「音声解説」や「スライド資料」を作ってもらうと流れを俯瞰したような気分になる。聞き手や読者層を指定したり音声解説については感情を込めないように指定すると良い感じである。
今後の予定（検討中）
ナレッジQ&Aを活用したい。今の所、OpenClaw の webchat インタフェースでのみ利用しているが、上記の文脈で LM 分散実行環境向けの共有ストレージであることを活かしたい。
一度構築した環境は更新に追従し続ける必要がある。現在のシステムの構成を把握しつつ、新たに追加されたナレッジからシステムに適用可能な更新候補をエージェントがピックアップ・提案してくれると便利そうである。ユーザが提案を採用する場合のシステム更新処理やその後のテスト、レベルダウン検出時のロールバック等一連の仕組みが必要である。
また、新たに追加されたナレッジからウォッチすべき新たな情報ソースを（YouTube チャネルに限らず）エージェントがピックアップ・提案してくれると便利そうである。
*1:rag_proxy.py について： OpenClaw 本体とは独立した、このパイプライン専用の新規スクリプト。ポート 11438 で待ち受ける HTTP プロキシサーバーとして動作し、webchat と vllm-webchat（ポート11437、Qwen3-8B-AWQ）の間に透過的に挟まる。リクエストを受け取るたびに最新のユーザーメッセージをクエリとして ChromaDB（bge-m3 dense 検索）と BM25 のハイブリッド検索にかけ、上位 3 チャンクを取得して messages に注入してから vLLM へ転送する。モデルが「RAGを使うかどうか」を判断するのではなく、すべてのリクエストに無条件で注入される点が透過注入の特徴であり限界でもある。
