OpenClaw + Codex / ClaudeCode エージェントスウォーム：1 人開発チームの構築 [完全セットアップ]

私はもう Codex や Claude Code を直接使っていません。

OpenClaw をオーケストレーションレイヤーとして使っています。私のオーケストレーターである Zoe が、エージェントを起動し、プロンプトを作成し、各タスクに適したモデルを選び、進捗を監視し、PR のマージ準備ができたら Telegram で私に通知します。

過去 4 週間の実績:

• 1 日で 94 コミット。最も生産的な日でした - クライアントとの電話が 3 件ありましたが、エディターを一度も開きませんでした。平均は 1 日約 50 コミットです。

• 30 分で 7 件の PR。アイデアから本番環境までが非常に速いのは、コーディングと検証のほとんどが自動化されているからです。

• コミット → MRR: 実際に構築している B2B SaaS でこれを使用しています — ファウンダー主導のセールスと組み合わせて、ほとんどの機能リクエストを即日対応しています。スピードが見込み客を有料顧客に変えます。

私の Git 履歴は、まるで開発チームを雇ったかのように見えます。実際には、Claude Code を管理していた状態から、他の Claude Code や Codex エージェントの群れを管理する OpenClaw エージェントを管理するようになっただけです。

成功率: このシステムは、ほとんどすべての小〜中規模タスクを介入なしで一発で完了します。

コスト: Claude が月額約 $100、Codex が月額約 $90 ですが、$20 から始めることもできます。

これが Codex や Claude Code を直接使うよりも優れている理由はこちらです:

>Codex と Claude Code は、あなたのビジネスに関するコンテキストをほとんど持っていません。

コードは見えますが、ビジネスの全体像は見えません。

OpenClaw が状況を変えます。OpenClaw はあなたとすべてのエージェントの間のオーケストレーションレイヤーとして機能します — 私の Obsidian vault 内にすべてのビジネスコンテキスト（顧客データ、ミーティングノート、過去の決定、成功したこと、失敗したこと）を保持し、過去のコンテキストを各コーディングエージェントへの正確なプロンプトに変換します。エージェントはコードに集中し続けます。オーケストレーターは高い戦略レベルに留まります。

システムの大まかな仕組みは次のとおりです:

先週、Stripe が「Minions」と呼ばれるバックグラウンドエージェントシステムについて書いていました — 集中管理されたオーケストレーションレイヤーに支えられた並列コーディングエージェントです。私は偶然同じものを構築しましたが、それは私の Mac mini でローカルに動作しています。

設定方法を説明する前に、なぜエージェントオーケストレーターが必要なのかを理解する必要があります。

なぜ 1 つの AI では両方ができないのか

コンテキストウィンドウは ゼロサム です。何を入れるかを選ばなければなりません。

コードで埋め尽くす → ビジネスコンテキストの余地がありません。顧客履歴で埋め尽くす → コードベースの余地がありません。これが 2 層システムが機能する理由です: 各 AI には必要なものだけが正確にロードされます。

OpenClaw と Codex は、コンテキストが drastically 異なります:

異なるモデルではなく、コンテキストによる専門化です。

完全な 8 ステップワークフロー

先週の実際の例を見てみましょう。

ステップ 1: 顧客リクエスト → Zoe とのスコーピング

代理店の顧客と電話をしました。彼らは、チーム全体で既に設定した設定を再利用したいと考えていました。

電話の後、Zoe とリクエストについて話し合いました。すべてのミーティングノートが自動的に Obsidian vault に同期されるため、私からの説明は一切不要でした。一緒に機能のスコープを決めました — そして、既存の設定を保存および編集できるテンプレートシステムに落ち着きました。

その後、Zoe は 3 つのことを行います:

1. クレジットを補充して顧客をすぐにブロック解除 — 管理者 API アクセス権を持っています
2. 本番データベースから顧客設定を取得 — 本番 DB への読み取り専用アクセス権（私の Codex エージェントはこれを決して持ちません）を持ち、既存の設定を取得し、プロンプトに含めます
3. Codex エージェントを起動 — すべてのコンテキストを含む詳細なプロンプトを使用

ステップ 2: エージェントを起動

各エージェントは、独自のワークツリー（独立したブランチ）と tmux セッションを取得します:

1# ワークツリーを作成 + エージェントを起動
2git worktree add ../feat-custom-templates -b feat/custom-templates origin/main
3cd ../feat-custom-templates && pnpm install
4
5tmux new-session -d -s "codex-templates" \
6  -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \
7  "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high"

エージェントは、スクリプトによる完全なターミナルログ記録付きの tmux セッションで実行されます。

エージェントの起動方法は次のとおりです:

1# Codex
2codex --model gpt-5.3-codex \
3  -c "model_reasoning_effort=high" \
4  --dangerously-bypass-approvals-and-sandbox \
5  "Your prompt here"
6
7# Claude Code
8claude --model claude-opus-4.5 \
9  --dangerously-skip-permissions \
10  -p "Your prompt here"

以前は codex exec や claude -p を使っていましたが、最近 tmux に切り替えました:

tmux の方がはるかに優れているのは、タスク途中でのリダイレクトが強力だからです。エージェントが間違った方向に進んでいますか？ 殺さないでください:

1# 間違ったアプローチ:
2tmux send-keys -t codex-templates "Stop. Focus on the API layer first, not the UI." Enter
3
4# より多くのコンテキストが必要な場合:
5tmux send-keys -t codex-templates "The schema is in src/types/template.ts. Use that." Enter

タスクは .clawdbot/active-tasks.json で追跡されます:

1{
2  "id": "feat-custom-templates",
3  "tmuxSession": "codex-templates",
4  "agent": "codex",
5  "description": "Custom email templates for agency customer",
6  "repo": "medialyst",
7  "worktree": "feat-custom-templates",
8  "branch": "feat/custom-templates",
9  "startedAt": 1740268800000,
10  "status": "running",
11  "notifyOnComplete": true
12}

完了すると、PR 番号とチェックで更新されます。（詳細はステップ 5 で）

1{
2  "status": "done",
3  "pr": 341,
4  "completedAt": 1740275400000,
5  "checks": {
6    "prCreated": true,
7    "ciPassed": true,
8    "claudeReviewPassed": true,
9    "geminiReviewPassed": true
10  },
11  "note": "All checks passed. Ready to merge."
12}

ステップ 3: ループでの監視

cron ジョブが 10 分ごとに実行され、すべてのエージェントを監視します。これは基本的に改良された Ralph Loop として機能します。詳細は後述します。

ただし、エージェントを直接ポーリングすることはありません — それはコストがかかります。代わりに、JSON レジストリを読み取り、以下をチェックするスクリプトを実行します:

1.clawdbot/check-agents.sh

スクリプトは 100% 決定論的で、トークン効率が非常に優れています:

• tmux セッションが生きているかチェック
• 追跡されたブランチにオープン PR があるかチェック
• gh cli を介して CI ステータスをチェック
• CI が失敗した場合や重要なレビューフィードバックがあった場合、失敗したエージェントを自動再起動（最大 3 回）
• 人間の注意が必要な場合のみアラート

ターミナルを見ているわけではありません。システムがいつ見るべきかを教えてくれます。

ステップ 4: エージェントが PR を作成

エージェントはコミット、プッシュし、gh pr create --fill で PR を開きます。この時点では通知は されません — PR だけでは完了ではありません。

完了の定義（エージェントにこれを知らせることが非常に重要です）:

• PR が作成された
• ブランチが main に同期されている（マージ競合なし）
• CI がパスしている（lint、型、ユニットテスト、E2E）
• Codex レビューがパスした
• Claude Code レビューがパスした
• Gemini レビューがパスした
• スクリーンショットが含まれている（UI 変更がある場合）

ステップ 5: 自動コードレビュー

すべての PR は 3 つの AI モデルによってレビューされます。それぞれ異なるものをキャッチします:

• Codex レビューア — エッジケースに優れています。最も徹底的なレビューを行います。ロジックエラー、欠落したエラーハンドリング、競合状態をキャッチします。誤検出率は非常に低いです。
• Gemini Code Assist レビューア — 無料で非常に便利です。他のエージェントが見逃すセキュリティ問題やスケーラビリティの問題をキャッチします。そして具体的な修正を提案します。導入は間違いなくお得です。
• Claude Code レビューア — ほとんど役に立ちません - 過度に慎重になる傾向があります。「...の追加を検討してください」という提案が多く、通常は過剰設計です。クリティカルとマークされていない限り、すべてスキップします。単独でクリティカルな問題を見つけることはほとんどありませんが、他のレビューアがフラグを立てたものを検証します。

3 つすべてが PR に直接コメントを投稿します。

ステップ 6: 自動テスト

CI パイプラインは大量の自動テストを実行します:

• Lint と TypeScript チェック
• ユニットテスト
• E2E テスト
• プレビュー環境（本番環境と同一）に対する Playwright テスト

先週、新しいルールを追加しました: PR が UI を変更する場合、PR の説明にスクリーンショットを含める必要があります。そうしないと CI が失敗します。これによりレビュー時間が大幅に短縮されます — プレビューをクリックしなくても、何が変更されたかを正確に確認できます。

ステップ 7: 人間によるレビュー

ここで Telegram 通知が届きます: 「PR #341 のレビュー準備完了。」

この時点で:

• CI がパスした
• 3 つの AI レビューアがコードを承認した
• スクリーンショットが UI の変更を示している
• すべてのエッジケースがレビューコメントに文書化されている

私のレビューには 5〜10 分かかります。多くの PR はコードを読まずにマージします — スクリーンショットが必要なすべてを示してくれます。

ステップ 8: マージ

PR がマージされます。毎日の cron ジョブが、孤立したワークツリーとタスクレジストリ JSON をクリーンアップします。

Ralph Loop V2

これは基本的に Ralph Loop ですが、より優れています。

Ralph Loop はメモリからコンテキストを取得し、出力を生成し、結果を評価し、学びを保存します。しかし、ほとんどの実装は毎回同じプロンプトを実行します。蒸留された学びは将来の検索を改善しますが、プロンプト自体は静的のままです。

私たちのシステムは異なります。エージェントが失敗した場合、Zoe は同じプロンプトで再起動するだけではありません。完全なビジネスコンテキストで失敗を分析し、どのようにブロックを解除するかを考えます:

• エージェントのコンテキストが不足した？ 「これらの 3 つのファイルだけに集中して。」
• エージェントが間違った方向に進んだ？ 「やめて。顧客が望んだのは X ではなく Y です。会議で彼らが言ったことはこちらです。」
• エージェントが明確化を必要としている？ 「こちらが顧客のメールと、彼らの会社の事業内容です。」

Zoe はエージェントが完了するまで監視します。彼女はエージェントが持っていないコンテキスト — 顧客履歴、ミーティングノート、以前試したこと、失敗した理由 — を持っています。そのコンテキストを使用して、再試行ごとにより良いプロンプトを作成します。

しかし、彼女は私がタスクを割り当てるのを待つこともありません。積極的に仕事を見つけます:

• 朝: Sentry をスキャン → 4 つの新しいエラーを発見 → 4 つのエージェントを起動して調査と修正を実行
• 会議後: ミーティングノートをスキャン → 顧客が言及した 3 つの機能リクエストをフラグ → 3 つの Codex エージェントを起動
• 夕方: Git ログをスキャン → Claude Code を起動して変更ログと顧客ドキュメントを更新

顧客との電話の後、散歩に出かけます。戻ると Telegram に: 「7 件の PR レビュー準備完了。3 つの機能、4 つのバグ修正。」

エージェントが成功すると、パターンが記録されます。「このプロンプト構造は課金機能に有効。」「Codex は型定義を事前に必要とする。」「テストファイルのパスを常に含めること。」

報酬シグナルは次のとおりです: CI パス、3 つのコードレビューすべてパス、人間によるマージ。失敗があるとループがトリガーされます。時間の経過とともに、Zoe は何が出荷されたかを記憶しているため、より良いプロンプトを作成します。

適切なエージェントの選択

すべてのコーディングエージェントが同じではありません。クイックリファレンス:

Codex は私の主力です。バックエンドロジック、複雑なバグ、複数ファイルのリファクタリング、コードベース全体にわたる推論を必要とするものすべて。遅いですが、徹底しています。タスクの 90% に使用しています。

Claude Code はより速く、フロントエンド作業に優れています。また、権限の問題が少ないため、Git 操作に最適です。（以前は日常業務でこれをより多く使用していましたが、Codex 5.3 は単純に優れており、より高速です）

Gemini には別のスーパーパワーがあります — デザインセンスです。美しい UI のために、まず Gemini に HTML/CSS 仕様を生成させ、それを Claude Code に渡してコンポーネントシステムに実装させます。Gemini がデザインし、Claude が構築します。

Zoe は各タスクに適切なエージェントを選択し、それらの間で出力をルーティングします。課金システムのバグは Codex へ。ボタンスタイルの修正は Claude Code へ。新しいダッシュボードデザインは Gemini から始まります。

設定方法

この記事全体を OpenClaw にコピーして、次のように指示します: 「私のコードベースにこのエージェントスウォーム設定を実装してください。」

アーキテクチャを読み取り、スクリプトを作成し、ディレクトリ構造を設定し、cron 監視を構成します。10 分で完了します。

販売するコースはありません。

誰も予想しないボトルネック

ここが私が今直面している限界です: RAM。

各エージェントには独自のワークツリーが必要です。各ワークツリーには独自の node_modules が必要です。各エージェントはビルド、型チェック、テストを実行します。5 つのエージェントが同時に実行されると、5 つの並列 TypeScript コンパイラ、5 つのテストランナー、5 セットの依存関係がメモリにロードされます。

16GB の Mac Mini では、スワップが始まる前に最大 4〜5 エージェントが限界です — そして、それらが同時にビルドしようとしないことを祈る必要があります。

そこで、このシステムを動かすために、128GB RAM の Mac Studio M4 max（$3,500）を購入しました。3 月末に到着予定で、価値があるかどうかを共有します。

次回: 一人で年収 100 万ドルの会社

2026 年から、一人で年収 100 万ドルの会社が大量に出現するでしょう。再帰的に自己改善するエージェントを構築する方法を理解している人々にとって、レバレッジは莫大です。

これがその姿です: 自分自身の拡張としての AI オーケストレーター（私にとっての Zoe のようなもの）が、さまざまなビジネス機能を処理する専門エージェントに作業を委任します。エンジニアリング。カスタマーサポート。オペレーション。マーケティング。各エージェントは得意なことに集中します。あなたはレーザーフォーカスと完全なコントロールを維持します。

次世代の起業家は、適切なシステムを持つ一人でできることを、10 人のチームを雇って行うことはしません。彼らはこのように構築するでしょう — 小さく留まり、迅速に動き、毎日出荷します。

今、AI 生成のゴミが大量にあります。エージェントや「ミッションコントロール」に関する誇大広告が、実際に役立つものを何も構築せずに溢れています。実際の利益のない派手なデモ。

私はその逆をしようとしています: 誇大広告を減らし、実際のビジネス構築のドキュメントを増やすこと。実際の顧客、実際の収益、本番環境に出荷される実際のコミット、そして実際の損失も。

何を構築しているのか？ Agentic PR — エンタープライズ PR の既存大手に挑む一人会社です。月額 $10,000 のリテイナーなしでスタートアップが報道を得るのを支援するエージェントです。

これをどこまで推し進めるかを見たいなら、フォローしてください。