OpenClaw + Claude Code 超強チュートリアル：一人で完全な開発チームを構築できる！

今日は非常に衝撃的な実践例を共有します。（文末にチュートリアルを添付）

ある独立した開発者が、OpenClaw + Codex/CCを使ってAIエージェントシステムを構築しましたが、どのような効果があったのでしょうか？

1日に94回のコミット、30分で7つのPRを完了し、その日には3回の顧客会議も行い、エディタは一度も開かなかったのです。

これは2026年1月に実際に起こったことです。著者はシステム全体のアーキテクチャ、ワークフロー、コード設定を公開しました。この考え方は非常に学ぶ価値があると感じたので、この記事にまとめてあなたと共有します。

もしあなたもCodexやClaude Codeを使っている、またはOpenClawに興味があるなら、この文章は多くのインスピレーションを与えてくれるでしょう。

一人で、1日に94回のコードコミット

まずはデータをいくつか見て、このシステムの威力を感じてみましょう：

• 単日最高94回のコミット（平均して毎日50回のコミット）
• 30分以内に7つのPRを完了
• アイデアからオンラインまでのスピードは「その日に顧客の要求を納品できる」ほどの速さ

著者はこのシステムを使って実際のB2B SaaS製品を作成しており、創業者によるダイレクトセールスと組み合わせることで、大部分の機能要求をその日に解決できます。どのくらいの速さかというと、顧客が要求を出すと、その日に効果が見え、直接有料ユーザーに転換されます。

コストはどうでしょう？毎月$190（Claude $100 + Codex $90）、初心者は$20から始められます。

あなたはこう思うかもしれません：これはAIツールをたくさん積み重ねて、無駄なコードを狂ったように生成しているのでは？

違います。著者のGit履歴は「新しい開発チームを雇ったかのように見える」ですが、実際には彼一人だけです。重要な変化は、彼が「Claude Codeを管理する」から「AIの執事を管理し、その執事が一群のClaude Codeを管理する」に変わったことです。

• 1月以前：直接CodexまたはClaude Codeでコードを書く
• 1月以降：OpenClawをオーケストレーション層として使用し、Codex/Claude Code/Geminiを調整させる

この変化によって、システムはほぼすべての小から中程度の複雑さのタスクを自動的に完了できるようになり、人間の介入は不要です。

なぜCodexとClaude Codeを単独で使用するのは十分ではないのか？

この時、あなたはこう思うかもしれません：CodexとClaude Codeはすでに強力なのに、なぜオーケストレーションの層を追加する必要があるのでしょうか？

著者が示す答えは非常に直接的です：CodexとClaude Codeはあなたのビジネスについてほとんど何も知りません。彼らはコードしか見ず、ビジネスの全体像を見ることができません。

ここには根本的な制限があります：コンテキストウィンドウは固定されており、あなたは二者択一をしなければなりません。

あなたは何を入れるかを選ばなければなりません：

• コードで満たす → ビジネスコンテキストを入れるスペースがない
• 顧客の履歴で満たす → コードベースを入れるスペースがない

したがって、CodexまたはClaude Codeを単独で使用すると、次のような問題に直面します：

• その機能がどの顧客のために作られたのかを知らない
• 前回の類似の要求がなぜ失敗したのかを知らない
• あなたの製品のポジショニングやデザイン原則を知らない
• 現在のコードとあなたのプロンプトに基づいてのみ作業できる

OpenClawはこの等式を変えました。

それはオーケストレーション層として機能し、あなたとすべてのAIツールの間に位置しています。その役割は：

• すべてのビジネスコンテキスト（顧客データ、会議記録、過去の決定、成功/失敗の事例）を保持する
• ビジネスコンテキストを正確なプロンプトに翻訳し、具体的なエージェントに提供する
• これらのエージェントが得意なことに集中できるようにする：コードを書く

たとえば：

• Codex/Claude Code = プロのシェフ、料理だけを担当
• OpenClaw = シェフ、顧客の好み、食材の在庫、メニューのポジショニングを知り、各シェフに正確な指示を出す

これが二層システムが必要な理由です：コンテキストの専門化による分業を通じて、より強力なモデルに切り替えるのではなく。

二層システムの具体的なアーキテクチャ：オーケストレーション層 + 実行層

このシステムの具体的なアーキテクチャを見てみましょう。

二層、それぞれの役割を果たす：

OpenClaw（オーケストレーション層）は何ができるか？

• Obsidianノート内のすべての会議記録を読み取る（自動同期）
• 生産データベースにアクセス（読み取り専用権限）して顧客設定を取得する
• 管理者API権限を持ち、顧客のチャージやブロック解除を直接行うことができる
• タスクの種類に応じて適切なエージェントを選択する
• すべてのエージェントの進捗を監視し、失敗した場合は原因を分析し、プロンプトを調整して再試行する
• 完了後、Telegramを通じて著者に通知する

エージェント（実行層）は何ができるか？

• コードリポジトリの読み書き
• テストとビルドの実行
• コードを提出し、PRを作成する
• コードレビューのフィードバックに応答する

重要なポイント：実行層のエージェントは生産データベースに決して触れず、顧客の機密情報を見ることもない。彼らは「このタスクを完了するために知っておく必要がある最小限のコンテキスト」だけを受け取る。

この設計は非常に賢い：安全境界が明確でありながら、効率も保証されている。

完全なワークフロー：顧客の要求からPRのマージまでの8つのステップ

ここからは核心部分に入ります。著者の先週の実際のケースを用いて、完全なプロセスを一通り説明します。

背景：ある企業顧客が電話をかけてきて、すでに設定した設定を再利用し、チーム内で共有したいと希望している。

第1ステップ：顧客の要求 → OpenClawが理解し分解する

通話が終わった後、著者はZoe（彼のOpenClaw）とこの要求について話しました。

ここでの素晴らしい点：説明コストゼロ。すべての会議記録が自動的にObsidianに同期されているため、Zoeは通話内容をすでに読んでおり、顧客が誰であるか、彼らのビジネスシーン、既存の設定を知っています。

著者とZoeは一緒に要求を分解し、ユーザーが既存の設定を保存および編集できるテンプレートシステムを作成することにしました。

その後、Zoeは3つのことを行いました：

• 顧客にチャージする — 管理者APIを使用して顧客の使用制限を即座に解除する
• 顧客設定を取得する — 生産データベース（読み取り専用）から顧客の既存の設定を取得する
• プロンプトを生成し、エージェントを起動する — すべてのコンテキストをパッケージ化し、Codexに供給する

第2ステップ：エージェントを起動する

Zoeはこのタスクのために：

• 独立したgitワークツリー（隔離されたブランチ環境）を作成した
• エージェントをバックグラウンドで実行するためのtmuxセッションを作成した

# ワークツリーを作成 + エージェントを起動 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 なぜtmuxを使うのか？途中で介入できるからです。

AIが方向を誤った場合、再起動する必要はなく、tmux内で直接指示を出すことができます：

# エージェントの方向が間違っている tmux send-keys -t codex-templates "止まって。まずAPI層をやって、UIは無視して。" Enter

エージェントにもっとコンテキストが必要

tmux send-keys -t codex-templates "型定義はsrc/types/template.tsにある、それを使って。" Enter 同時に、タスクはJSONファイルに記録されます：{ "id": "feat-custom-templates", "tmuxSession": "codex-templates", "agent": "codex", "description": "企業顧客のカスタムメールテンプレート機能", "repo": "medialyst", "worktree": "feat-custom-templates", "branch": "feat/custom-templates", "startedAt": 1740268800000, "status": "running", "notifyOnComplete": true}

第 3 歩：自動監視

cron タスクが 10 分ごとにすべてのエージェントの状態をチェックします。

ポイント：エージェントの進捗を「尋ねる」わけではなく（それはトークンを無駄にする）、客観的な事実を確認します：

• tmux セッションはまだ生きていますか？
• PR は作成されましたか？
• CI の状態はどうですか？
• 失敗した場合、再起動が必要ですか？（最大 3 回再試行）

この監視スクリプトは 100% 確定的で、非常にトークンを節約し、人工介入が必要な場合のみ著者に通知します。

これは実際には改良版の Ralph Loop で、後で詳しく説明します。

第 4 歩：エージェントが PR を作成

エージェントはコードを書き終え、コミットし、プッシュし、次に gh pr create --fill を使用して PR を作成します。

注意：この時点で著者は通知を受け取りません。なぜなら、PR 自体は「完了」を意味しないからです。

「完了」の定義は：

• ✅ PR が作成された
• ✅ ブランチが main に同期されている（競合なし）
• ✅ CI が通過した（lint、型チェック、単体テスト、E2E テスト）
• ✅ Codex レビュアーが承認した
• ✅ Claude コードレビュアーが承認した
• ✅ Gemini レビュアーが承認した
• ✅ UI に変更がある場合、スクリーンショットを含める必要があります

すべてが満たされて初めて、真に完了と見なされます。

第 5 歩：自動化されたコードレビュー

各 PR は 3 人のエージェントによってレビューされます：

• Codex レビュアー — 最も信頼できるレビュアー - 境界条件を見つけるのが得意
• 論理エラー、欠落しているエラーハンドリング、競合状態を捉えることができます
• 誤報率は非常に低い

• Gemini コードアシストレビュアー — 無料で使いやすい - 他のレビュアーが見逃したセキュリティ問題や拡張性の問題を発見できます
• 具体的な修正提案を提供します
• 無駄にすることはありません

• Claude コードレビュアー — 基本的に役に立たない - 過度に慎重で、常に「……を追加することを検討してください」と提案します
• 大部分の提案は過剰設計です
• 「critical」とマークされていない限り、直接スキップします

3 人のレビュアーはすべて PR 内でコメントします。

第 6 歩：自動化されたテスト

CI パイプラインは次を実行します：

• Lint と TypeScript チェック
• 単体テスト
• E2E テスト
• Playwright テスト（本番環境と全く同じプレビュー環境で実行）

先週追加されたルール：PR が UI を変更した場合、説明にスクリーンショットを添付する必要があります。そうでない場合、CI は直接失敗します。

このルールはレビュー時間を大幅に短縮しました — 著者はスクリーンショットを一目見るだけで何が変更されたかを理解でき、プレビュー環境に入る必要がありません。

第 7 歩：手動レビュー

今、著者は Telegram 通知を受け取ります：「PR #341 が準備できました。レビューできます。」

この時点で：

• CI はすべて緑です
• 3 人の AI レビュアーがすべて承認しました
• スクリーンショットは UI の変化を示しています
• すべての境界条件がレビューコメントに記録されています

著者のレビューは 5-10 分で済みます。多くの PR では、コードを見ずにスクリーンショットだけを見て直接マージします。

第 8 歩：マージ

PR がマージされます。毎日 cron タスクが孤立したワークツリーとタスク記録をクリーンアップします。完成したプロセスを経て、顧客の要求からコードのデプロイまで、実際には1〜2時間しかかからず、著者の実際の投入時間はわずか10分かもしれません。

## 3つのシステムをより賢くするメカニズム

### メカニズム1：改良版Ralph Loop — 繰り返すだけでなく、学習する

あなたはRalph Loopを聞いたことがあるかもしれません：コンテキストをメモリから引き出す → 出力を生成する → 結果を評価する → 学習を保存する。

しかし、ほとんどの実装には1つの問題があります：各ループで使用されるプロンプトが同じです。学習したことは将来の検索を改善しますが、プロンプト自体は静的です。

このシステムは異なります。

エージェントが失敗したとき、Zoeは同じプロンプトで再起動しません。彼女は完全なビジネスコンテキストを持って、失敗の原因を分析し、プロンプトを書き直します：

❌ 悪い例（静的プロンプト）：
{
"カスタムテンプレート機能を実装する"
}

✅ 良い例（動的調整）：
{
"止まれ。顧客が求めているのはXであり、Yではない。彼らの会議での原文は：
私たちは既存の設定を保存したいのであり、新しいものをゼロから作成したくありません。
重要なのは設定の再利用であり、新しいプロセスを作成しないことです。"
} Zoeはこのような調整ができるのは、彼女が実行層のエージェントにはないコンテキストを持っているからです：

- 顧客が会議で何を言ったか
- この会社が何をしているか
- 前回の類似の要求がなぜ失敗したのか

さらに、Zoeはあなたがタスクを割り当てるのを待つことはありません。彼女は自ら仕事を探します：

- 朝：Sentryをスキャン → 4つの新しいエラーを発見 → 4つのエージェントを起動して調査と修正を行う
- 会議後：会議記録をスキャン → 3つの顧客が言及した機能要求を発見 → 3つのCodexを起動
- 夜：git logをスキャン → Claude Codeを起動してchangelogと顧客文書を更新

著者が散歩から戻ると、Telegramに表示されます："7つのPRが準備完了。3つの新機能、4つのバグ修正。"

成功したパターンは記録されます：

- "このプロンプト構造は請求機能に非常に効果的です"
- "Codexは事前に型定義を取得する必要があります"
- "常にテストファイルのパスを含める必要があります"

報酬信号は：CIが通過、3つのコードレビューが通過、手動マージ。いかなる失敗もループを引き起こします。

時間が経つほど、Zoeが書くプロンプトは良くなります。なぜなら、彼女は何が成功するかを覚えているからです。

### メカニズム2：エージェント選択戦略 — 異なるタスクには異なる専門家を選ぶ

すべてのエージェントが同じ強さではありません。著者がまとめた選択戦略：

- Codex(gpt-5.3-codex) — 主力- バックエンドロジック、複雑なバグ、多ファイルのリファクタリング、コードベースを超えた推論が必要なタスク
- 遅いが徹底的
- 90%のタスクを占める

- Claude Code(claude-opus-4.5) — スピード型選手- フロントエンド作業
- 権限の問題が少なく、git操作に適している
- （著者は以前はもっと使っていたが、Codex 5.3が出てからは変更した）

- Gemini — デザイナー- デザインセンスがある
- 美しいUIの場合、まずGeminiにHTML/CSSの仕様を生成させ、その後Claude Codeにコンポーネントシステムで実装させる
- Geminiがデザインし、Claudeが構築する

Zoeはタスクの種類に応じて自動的にエージェントを選択し、それらの間で出力を渡します。請求システムのバグはCodexに、ボタンスタイルの修正はClaude Codeに、新しいダッシュボードのデザインは最初にGeminiに渡します。

### メカニズム3：ボトルネックはどこにある？RAM

ここには予期しない制限があります：トークンコストでもなく、APIの速度でもなく、メモリです。

各エージェントには必要があります：

- 自分のworktree
- 自分のnodemodules
- ビルド、型チェック、テストを実行する

5つのエージェントが同時に実行される = 5つの並行したTypeScriptコンパイラ + 5つのテストランナー + 5セットの依存関係がメモリにロードされます。

著者のMac Mini（16GB RAM）は、同時に最大4〜5のエージェントを実行でき、それ以上になるとスワップが始まり、彼らが同時にビルドしないことを祈る必要があります。彼は3月末に到着する予定です。彼はその時にそれが価値があるかどうかを共有すると言っています。

## あなたも構築できます：ゼロから実行するのにわずか10分

このシステムを試してみたいですか？

最も簡単な方法：

この記事全体を OpenClaw にコピーして、次のように伝えてください："このアーキテクチャに従って、私のコードベースにエージェントクラスターシステムを実装してください。"

すると、彼は：
- アーキテクチャ設計を読み取ります
- スクリプトを作成します
- ディレクトリ構造を設定します
- cron 監視を構成します

10分で完了します。

あなたが準備する必要があるもの：
- OpenClaw アカウント
- Codex および/または Claude Code の API アクセス
- git リポジトリ
- （オプション）ビジネスコンテキストを保存するための Obsidian

## 2026：一人の百万ドル企業

著者は記事の最後に次のようなことを言っています。私はそれが非常に示唆に富んでいると感じました：

"2026年から、多くの一人の百万ドル企業が登場するのを見るでしょう。レバレッジは巨大で、再帰的な自己改善 AI システムを構築する方法を理解している人々に属します。"
それは次のようになります：
- あなたの延長としての AI オーケストレーター（著者にとっての Zoe のように）
- 専門のエージェントに仕事を委任し、異なるビジネス機能を処理します
- エンジニアリング、カスタマーサポート、オペレーション、マーケティング
- 各エージェントは自分が得意なことに集中します
- あなたは集中し、完全にコントロールを維持します

次世代の起業家は、1人と1つのシステムでできることをするために10人を雇うことはありません。彼らはこう構築します——小規模を維持し、迅速に行動し、毎日リリースします。

現在、AI が生成するゴミコンテンツがあまりにも多すぎます。さまざまな誇大広告、さまざまな"タスクコントロールセンター"の派手なデモですが、実際に役立つものはありません。

著者は、逆のことをしたいと言っています：誇大広告を減らし、実際の構築プロセスを記録することを増やすこと。実際の顧客、実際の収入、実際のプロダクション環境への提出、そして実際の失敗もあります。

この記事はここまでです。

核心要点の振り返り：
- 二層アーキテクチャ：オーケストレーション層はビジネスコンテキストを保持し、実行層はコードに集中します
- 完全自動化：要求から PR までの8ステッププロセス、大部分のタスクが一度で成功します
- 動的学習：繰り返し実行するのではなく、失敗の原因に基づいて戦略を調整します
- コスト管理可能：開始は月$20、重度使用は月$190

もしあなたも AI 自動化の実践的な応用を探求しているなら、このケースがあなたにいくつかのインスピレーションを与えることを願っています。

参考リンク：[[HTMLPLACEHOLDER_0]]