OpenClaw + Claude Code/Codex：個人開発エージェントスワームの構築

皆さん、こんにちは。私はルー工です。

先日、Xであるツイートを見かけて、一瞬で引き込まれました。独立開発者のElvisが、彼はもうClaude CodeとCodexを直接使っていない、OpenClawをオーケストレーションレイヤーとして使い、ZoeというAIオーケストレーターにClaude CodeとCodexのエージェントスワーム全体を管理させていると言っていました。

このツイートのデータも驚異的で、490万回の閲覧、1.1万のいいね、1800回のリツイート。

私たちのVibe Codingは4ヶ月以上続いており、Claude Codeは常に主力ツールです。以前にも、複数エージェントの協力やVSCodeの複数エージェントアーキテクチャに関する記事を書いたことがあります。

しかし、Elvisのこのやり方を見て、私はただただ感心するばかりです。一人で、オーケストレーションシステムを使って、平均50回のコード提出を行い、最も多い日は94回提出し、3件の顧客電話を受け、エディタを一度も開かなかったのです。

これこそ、一人で開発チームのように働いているのではないでしょうか？

今日はこの記事で、彼がどのようにそれを実現したのかを解説します。

OpenClawは皆さんにとって馴染み深い存在

この小さなザリガニは春節前から今まで、ずっと人気です。簡単に言うと、オープンソースのAIエージェントフレームワークで、GitHubでは現在24万を超えるスターを獲得し、数日前にはReactを超えて、GitHub史上最もスターが増加したオープンソースプロジェクトとなりました。

創設者のPeter Steinbergerはオーストリアの開発者で、以前はPSPDFKit（PDFフレームワークのB2B企業）を設立し、2021年にInsight Partnersから1億ユーロの投資を受けました。今年の2月、PeterはOpenAIに参加することを発表し、OpenClawプロジェクトはオープンソース財団に運営を移管されました。

OpenClawの位置付けはチャットボットではなく、あなたのローカルデバイス上で動作するAIエージェントのランタイムです。4つのコアコンポーネントがあります：Gateway（ゲートウェイ、50以上のメッセージプラットフォームに接続）、Agent（推論エンジン）、Skills（5400以上のプラグイン）、Memory（記憶システム）。

しかし、ElvisのOpenClawの使い方は特別です。彼はそれをオーケストレーションレイヤーとして、Claude CodeやCodexなどのコーディングエージェントを管理するために専用に使用しており、一般的なアシスタントとしては使用していません。

この考え方は確かに独特です。

なぜオーケストレーションレイヤーが必要なのか？

Elvisはツイートの中で非常に重要なポイントを挙げました：コンテキストウィンドウはゼロサムゲームです。

あなたがコードを詰め込むと、ビジネスコンテキストを置くスペースがなくなります。顧客の履歴や会議の記録を詰め込むと、コードベースを置くスペースがなくなります。単一のAIがどんなに強力でも、これら2種類の全く異なる情報を同時に保持することはできません。

そこで彼はシステムを2層に分けました。

上層はOpenClawのオーケストレーターZoeで、彼女はすべてのビジネスコンテキストを把握しています。顧客データ、会議の記録、過去の決定、どのプランが試されたか、どれが失敗したかなどの情報がすべてElvisのObsidianノートライブラリに保存されており、Zoeはそれを直接読み取ることができます。

下層はClaude CodeやCodexなどのコーディングエージェントで、彼らはコードだけを見て、コードを書くことだけに専念します。各エージェントが起動する際、Zoeはビジネスコンテキストに基づいて彼らに正確なプロンプトを書き、何をすべきか、背景は何か、顧客が求めているものは何かを伝えます。

簡単に言えば：オーケストレーターはニーズを理解し、コーディングエージェントは作業を行います。それぞれが得意なことを行うのです。

このアーキテクチャは、Stripeが最近公開した内部システムMinionsと似たようなものです。StripeのMinionsも並行コーディングエージェントと集中型オーケストレーションレイヤーの設計で、毎週1000以上の完全にAIによって書かれたPRを統合できます。Elvisは、彼が偶然にも似たようなアーキテクチャを構築したと言っていますが、ただ自分のMac mini上で動作しているだけです。

実際のケーススタディのワークフロー

Elvisはツイートの中で実際のケーススタディを使って彼の完全なワークフローを説明しました。私はその核心的なプロセスを簡単にまとめます。彼は顧客からの電話を受け、顧客はチーム内で既存の設定を再利用したいと考えていました。通話が終わった後、彼はZoeとこの要求について話しました。すべての会議記録は自動的にObsidianに同期されるため、Zoeは顧客が何を言ったのかすでに知っており、Elvisが追加で説明する必要はありませんでした。彼らは一緒に機能範囲を確認し、最終的な提案はテンプレートシステムを作成することになりました。

その後、Zoeは自動的に3つのことを行いました：顧客に対してサービスのアンロックを行うためにチャージを行う（彼女は管理者API権限を持っています）、生産データベースから顧客の既存設定を取得する（読み取り専用権限、エンコーディングエージェントはこの権限を持つことはありません）、そして、完全なビジネスコンテキストを含む詳細なプロンプトを持ったCodex Agentを生成します。

各エージェントは独自のworktree（隔離されたブランチ）とtmuxセッションを持っています。起動コマンドはおおよそ以下のようになります：

# Create worktree + spawn agent git worktree add ../feat-custom-templates -b feat/custom-templates origin/main cd ../feat-custom-templates && pnpm install tmux new-session -d -s "codex-templates" \ -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \ "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex highエージェントが起動した後、10分ごとに巡回する定期タスクがあります。しかし、エージェントに直接尋ねることはせず（それではトークンを消費しすぎるため）、決定論的なShellスクリプトを実行してtmuxセッションがまだ生きているか、PRが作成されたか、CIが通過したかを確認します。

もしCIが失敗した場合、自動的にエージェントを再起動し、最大3回まで再試行します。人の手による介入が必要な場合にのみ通知が送信されます。

エージェントがタスクを完了すると、自動的にPRが作成されます。しかし、PRを作成するだけでは終わりません。Elvisは完了基準のセットを定義しました：PRの作成、ブランチがmainに同期される（マージの競合なし）、CIがすべて通過、3つのAIモデルのコードレビューがすべて通過、UIの変更がある場合はスクリーンショットを添付する必要があります。

3つのAIモデルによるコードレビュー

3つのAIモデルによるコードレビューは非常に安定しているように見えます。彼がこの3つのモデルについての評価を話すのは非常に興味深いです。

Codex Reviewer、彼は最高の評価を与え、境界条件や論理エラーに関するレビューが非常に徹底しており、誤報率が非常に低いと述べました。

Gemini Code Assist Reviewer、無料で、彼は非常に実用的であり、他のモデルが見逃したセキュリティの脆弱性や拡張性の問題を発見でき、具体的な修正案を提供できると述べました。

Claude Code Reviewer、彼の原文は「基本的に役に立たない」であり、過度に慎重で、「考慮して追加する...」のような提案が画面に溢れており、大部分は過剰設計に属すると述べました。重要な問題としてマークされない限り、彼は直接スキップします。

この部分を見たとき、私は少し驚きました。Claude Codeのヘビーユーザーとして、確かにコードレビュー時に過度に保守的な状況に遭遇したことがありますが、「基本的に役に立たない」という評価は少し行き過ぎだと思います。しかし、これは多モデルの交差レビューが確かに価値があることを示しており、異なるモデルの偏見がちょうど補完し合うことを示しています。

3つのレビューがすべて通過した後、Elvisは初めてTelegram通知を受け取ります。この段階では、彼が主に見るのはスクリーンショットで、UIの変更が正しいかを確認し、多くのPRはコードを見ずに直接マージします。彼は自分の手動レビューには5〜10分しかかからないと言います。

Zoeの積極性

Zoeは単なる実行者ではありません。ワークフロー自体よりも興味深いのはZoeの積極性です。

Elvisは、Zoeはタスクの割り当てを待つことはなく、自ら仕事を探しに行くと言います。朝にSentryのエラーログをスキャンし、4つの新しいエラーを発見し、自動的に4つのエージェントを生成して修正します。会議が終わった後、会議記録をスキャンし、顧客が言及した3つの機能要求をマークし、その後自動的に3つのCodex Agentを起動します。夜にはGitログをスキャンし、Claude Codeを起動してchangelogと顧客文書を更新します。

Elvisが外に散歩に出かけて戻ると、Telegramには「7つのPRが準備完了、3つの新機能、4つのバグ修正」というメッセージが届いています。これこそが私がずっと期待していたOPC一人会社の開発チームの効果ではないでしょうか。エージェントが失敗したとき、Zoeの対処法は単純な再試行よりもはるかに高度です。彼女はビジネスの文脈を組み合わせて失敗の原因を分析します。エージェントの文脈が壊れた？それなら範囲を狭めて、エージェントに3つのファイルだけに集中させます。エージェントの方向性がずれた？それも修正し、エージェントに顧客が求めているのはXであってYではないと伝え、会議中の原文を添えます。

時間が経つにつれて、Zoeは経験を積み、どのプロンプト構造がどのタイプのタスクに効果的かを記憶し、次回はより正確なプロンプトを作成します。

この考え方は実際にはRalph Loopのアップグレード版です。Ralph Loopのコアロジックは、文脈を引き出し、出力を生成し、結果を評価し、経験を保存するというサイクルですが、ほとんどの実装では各サイクルのプロンプトは固定されています。Elvisのシステムは異なり、再試行のたびにZoeは失敗の原因に基づいてプロンプトを動的に調整し、完全なビジネス文脈を持っています。

費用とハードウェア

費用に関して、Elvisが公開したデータによれば、Claudeは月に約100ドル、Codexは月に約90ドルです。彼はまた、最初は20ドルから試してみることができるとも言いました。

この費用は開発者を雇うことと比べると、もちろん非常に安いですが、製品の意思決定、顧客とのコミュニケーション、コードレビューを自分で行う必要があることを考えると、これは効率の増幅器のようなもので、コーディングやテストといった最も繰り返しの多いプロセスを省く手助けをします。

ハードウェアに関して、Elvisは現在の最大のボトルネックはRAMであると述べています。各エージェントは独立したworktreeを必要とし、各worktreeには独自のnode_modulesがあり、各エージェントはビルド、型チェック、テストを実行する必要があります。5つのエージェントが同時に実行されるということは、5つの並行したTypeScriptコンパイラ、5つのテストランナー、5セットの依存関係を意味します。

彼のMac miniは16GBのメモリで、最大で4〜5のエージェントを同時に実行できます。それ以上になるとメモリスワップが始まります。そこで彼は128GBのメモリを搭載したMac Studio M4 Max（3500ドル）を購入し、より多くのエージェントの同時実行を支えるつもりです。

まとめと現実的な問題

正直なところ、Elvisのこのシステムは私にとってかなり衝撃的でした。私は以前、OpenClawをおもちゃとして扱っており、生産性を高めるためには独立したClaude Codeに依存していました。時折worktreeを使って並行処理を行っていましたが、これほどシステム化された編成には至っていませんでした。彼のツイートを見た後、AIプログラミングの限界がまた一段と引き上げられたと感じました。

最近、私は彼の考えに従って、OpenClawを使って完全自動化された一人開発チームを構築する準備をしています。したがって、今後私たちのアカウントではOpenClawの実践に関する記事をいくつか公開する予定です。

いくつかの現実的な問題についても注意を促す必要があります。

このシステムの前提は、明確な製品、明確な顧客ニーズ、整ったCI/CDパイプラインを持っていることです。Elvisは実際のB2B SaaS製品を作成しており、顧客がいて、収入があり、運用環境があります。もしあなたがまだデモを作成しているか、学習段階にいるのであれば、このアーキテクチャのROIはあまり良くないかもしれません。

さらに、OpenClawの現在のセキュリティ問題にも注意が必要です。公開情報によれば、すでに複数の高危険CVEが公開されており、341の悪意のあるコミュニティプラグインがデータ窃取行為を行っていることが発見されています。OpenClawを展開する際には、隔離と権限管理をしっかりと行う必要があります。これが私がOpenClawをローカルのメインマシンに展開していない理由でもあります。

もう一点、Elvisはツイートの中でClaude Codeのコードレビューに対する評価が低いですが、最近Claude Codeはエージェントチーム機能（公式に内蔵された複数エージェントの協力）を発表したばかりで、Anthropicも編成の方向に力を入れています。

しかし、これらの詳細を除けば、Elvisのこの編成層と実行層のアーキテクチャの考え方は確かに注目に値します。文脈ウィンドウのゼロサムゲームは実際に存在する制約であり、階層的なアーキテクチャを用いてこの問題を解決し、異なるAIがそれぞれの役割を果たす方向性は、私個人としては正しいと思います。