VM0開発チームでは、すべての開発者が同時に複数のClaude Codeインスタンスを使用しています。通常8つ以上です。
私たちはClaude Codeを実際の開発者と同じように扱っています。(そう、私たちの会社は半分冗談でAI Colleagues Coと呼ばれています!)
そのため、VM0開発ワークフローの設計思想は、ソフトウェアエンジニアリングにおける古典的なチーム管理手法を反映しています。
GitHub Issuesで作業を追跡し、プルリクエストでコードレビューとマージを行い、GitHub Actionsで自動化を処理します。 2ヶ月間で、このセットアップにより404回のリリースを出荷し、23万行以上のコードを記述しました。
この記事では、どのようにそれを実現可能にしたか、そしてなぜ主要な問題がAIの能力ではなく、人間の調整にあったのかを説明します。
実践におけるAI駆動開発ワークフロー
複数のAIエージェントを並行して調整する場合、ボトルネックはモデルがコードを書けるかどうかではありません。真のボトルネックは人間の認知負荷です。
このワークフローは14のスラッシュコマンドで構成され、Deep Dive、Issue管理、PR管理の3つのレイヤーに整理されています。
まず、私のワークフローがどのように見えるか、そして機能が通常どのように構築されるかを見てみましょう。
-
要件の整合
人間がClaudeセッションを開き、
/deep-researchから始めます。Claudeはコードベース、ドキュメント、関連コンテキストから事実を収集します。調査結果について議論し、実際に解決している問題について整合します。 -
解決策の探索
/deep-innovateを使用して、Claudeはトレードオフを含むいくつかの可能な方向性を提案します。議論し、絞り込み、方向性を選択します。 -
Issueの作成
/issue-createを使用してGitHub Issueを作成します。人間がIssueをレビューして、要件が明確に捉えられているか確認します。 -
計画と承認
/issue-todoを使用してClaudeに作業を続行させます。Claudeは自動的に完全なディープダイブワークフローを実行し、結果をIssueに投稿します。これには以下が含まれます:/deep-researchからの調査結果/deep-innovateからの比較/deep-planからの具体的な実装計画
-
実装
承認後、
/issue-continueによりClaudeは計画を実装し、テストを記述し、PRを開き、CIが通過することを確認します。 -
レビューとマージ
構造化されたレビューには
/pr-review-and-commentを使用し、マージ前に最終的な人間レビューを行います。人間は3つのチェックポイントで介入します:要件、方向性、承認。それ以外はすべて自律的に実行されます。
マインドセットの転換:AI開発者のチームをリードしている
構造化されたワークフローが必要だと気づいた瞬間は、Claudeセッションを追加することで実際に状況が悪化したときでした。並行して実行するインスタンスが増えるほど、それぞれが何をしているのか、作業がどの状態にあるのか、何がすでに決定されたのかを追跡することが困難になりました。
外部ツールなしでは、これほど多くのClaudeインスタンスを同時に管理することは単純にできませんでした。そのとき気づきました:これはAIの問題ではなく、管理の問題でした。
GitHubはすでにソフトウェア開発におけるコラボレーションの自然なツールであるため、新しいものを発明する代わりに、Claudeを人間のチームメイトと同じように扱い始めました。そうすることで、私の管理帯域幅が突然スケールしました。
10年間のプロジェクトおよびチーム管理の経験が、この新しいコンテキストでついに意味を持ちました。ClaudeをチームメンバーとしてGitHubを共有のコミュニケーションと管理スペースとして扱うことで、システム全体が再び管理可能になりました。
優れたチームリーダーは、いつ関与し、いつ一歩引くかを知っています:
| チェックポイント | 私がすること | AIがすること |
|---|---|---|
| 要件 | 問題について整合、範囲を明確化 | コードベースを調査、コンテキストを収集 |
| 方向性 | 調査結果をレビュー、アプローチを承認 | 2~3のアプローチを提案、トレードオフを評価 |
| 承認 | PRをレビュー、品質を検証 | 実装、テスト、CIを修正 |
これは、効果的なソフトウェアチームがどのように運営されているかを反映しています。開発者をマイクロマネジメントするのではなく、明確な要件を設定し、重要な決定をレビューし、最終的な成果物を検証します。同じ原則がAIエージェントの管理にも適用されます。
ディープダイブフローは構造化されたスロー思考を強制する
ディープダイブワークフローは、実装前に意図的な思考を強制します。時々、Claudeは行き詰まることがあります。そのような場合、Claudeを停止させて考えさせ、一緒に話し合います。3つのフェーズがあります:
| フェーズ | コマンド | 目的 | 出力 |
|---|---|---|---|
| リサーチ | /deep-research | 事実を収集、コンテキストを理解 | research.md |
| イノベーション | /deep-innovation | 複数のアプローチを探索 | innovate.md |
| プラン | /deep-plan | 具体的なステップを定義 | plan.md |
各フェーズには厳格な境界があります。
- リサーチ:提案なし
- イノベーション:詳細なし
- プラン:実装なし
これらの制約により、Claudeはコードに直接飛びつく代わりに、遅く慎重な推論を行うことを余儀なくされます。これらがないと、エッジケースやアーキテクチャの懸念がしばしば見逃されます!
使用例
/deep-research investigate the authentication flow, I'm seeing token expiration issues
[Claude researches, analyzes 12 related files, finds 3 similar patterns]
/deep-innovate what are our options for fixing this?
[Claude presents 3 approaches with trade-offs, you pick one]
/issue-create let's track this fix
シンプルなタスクの場合、ディープダイブをスキップして直接/issue-createに進むことができます。
技術的な不確実性を伴う複雑なタスクの場合、ディープダイブフェーズは、実装が始まる前にあなたとClaudeが整合していることを確認するのに役立ちます。
GitHubを共有メモリとして使用する
ほとんどのAIツールはコンテキストを一時的なものとして扱います。セッションが終了すると、メモリは消えます。
VM0はGitHubを永続的なメモリとして使用します:
| GitHub機能 | 保存するもの |
|---|---|
| Issue本文 | 要件と決定事項 |
| Issueコメント | リサーチ、オプション、計画 |
| PRコメント | レビューと要約 |
| ラベル | ワークフロー状態 |
これは人間の問題も解決します:コンテキストの復元。
8つ以上のClaudeインスタンスを管理している場合、作業が完了したという通知を受け取ります。しかし、Claudeの会話から、それが何をしていたのか、どのような決定が下されたのか、現在の状態は何かを再構築することはできません。
GitHub Issuesがこれを解決します。各Issueには以下が表示されます:
- 元の要件
- リサーチの調査結果(何が発見されたか)
- イノベーションフェーズ(どのオプションが検討されたか)
- 承認された計画(何が実装されるか)
この構造化された形式により、レビューが効率的になります。フェーズを素早くスキャンし、アプローチを理解し、元の会話を覚えていなくても、承認または変更を要求できます。
作業が終了したとき、チャットウィンドウで何が起こったかを覚えておく必要はありません。Issueを開いて、構造化され書き留められた完全なストーリーを見ることができます。
エージェント間の引き継ぎ
すべてのコンテキストがGitHubに存在するため、作業はエージェント間でシームレスに移動できます:
- 1つのエージェントがIssueまたはPRを作成
- 別のエージェントが後で
/deep-research issue 123または/issue-todo 123または/deep-research PR 124を使用して続行
長い議論の場合、/issue-compactがすべてをクリーンなIssue本文に統合します。これにより、人間とAIの両方にとって引き継ぎが簡単になります。
ワークフローパターンの要約
これらすべての後、いくつかの実用的なヒントをまとめます。
シンプルなタスク
/issue-create → /issue-todo → /issue-continue → /pr-check-and-merge
要件が明確で、作業が簡単な場合にこれを使用します。
複雑なタスク
/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-todo → /issue-continue →
/pr-review-and-comment → /pr-check-and-merge
これにより、間違ったアプローチへの無駄な努力を防ぎます。
並行作業
人間が完了したチェックポイントをレビューしている間に、複数のエージェントが同時に作業できます。ここがワークフローが最もスケールする場所です。
Agent 1: /issue-todo #123
Agent 2: /issue-todo #124
Agent 3: /pr-review-and-comment #100
Agent 4: /deep-research new feature requirements
コマンドリファレンス
ディープダイブコマンド
| コマンド | 目的 |
|---|---|
/deep-research | 情報を収集、コードベースを理解。提案は禁止。 |
/deep-innovate | 2~3のアプローチを探索、トレードオフを評価。コードは禁止。 |
/deep-plan | 具体的な実装ステップを作成。実装は禁止。 |
Issueコマンド
| コマンド | 目的 |
|---|---|
/issue-create | 会話コンテキストからIssueを作成 |
/issue-bug | 再現手順を含むバグレポートを作成 |
/issue-feature | 要件に焦点を当てた機能リクエストを作成 |
/issue-todo | 完全なディープダイブワークフローを実行、結果をIssueに投稿 |
/issue-continue | 人間の承認後に実装を続行 |
/issue-compact | 引き継ぎのためにIssue本文+コメントを統合 |
PRコマンド
| コマンド | 目的 |
|---|---|
/pr-check | CIパイプラインを監視、自動修正、最大3回リトライ |
/pr-check-and-merge | CIを監視し、すべてのチェックが通過したらマージ |
/pr-review | プロジェクト標準に対してコミットごとにPRをレビュー |
/pr-review-and-comment | レビューして調査結果をPRコメントとして投稿 |
/pr-comment | 会話の議論をPRコメントに要約 |
始め方
- シンプルに始める:最初のタスクには
/issue-create→/issue-todo→/issue-continueを使用 - 複雑なタスクにディープダイブを追加:要件が不明確または技術的に複雑な場合、
/deep-researchから始める - 徐々にスケール:レビューリズムに慣れてきたら、より多くのClaudeインスタンスを追加
- プロセスを信頼:チェックポイント間でClaudeが自律的に作業できるようにする
ワークフローは段階的に採用できるように設計されています。初日から14のコマンドすべてを使用する必要はありません。基本的なIssueフローから始めて、自信がついたらディープダイブフェーズと並行作業を追加してください。
スケーリングの考慮事項:より多くのエージェントがいる場合に何をすべきか
このワークフローは10以上の同時Claudeインスタンスでテストされています。推奨事項:
- 10エージェントまで:それぞれと深くコラボレーションするのに快適
- 10を超える:推奨しない
制限要因はワークフローではなく、人間の注意と意思決定の質です。10を超えるエージェントを管理する場合、レビューチェックポイントでボトルネックになるリスクがあり、意思決定の質が低下し始めます。
古典的な「2ピザチーム」の原則がここに適用されます。人間のチームサイズを制限する同じ制約が、1人が効果的に管理できるAIエージェントの数も制限します。
現在、10エージェントを超えるスケーリングのために8×8の2層チーム構造を探索していますが、まだ効果的なプラクティスを開発していません。具体的な結果が出たら、さらに共有します…
VM0開発ワークフローは、AIがチームの一部になるときのソフトウェア開発の考え方を変えます。
AIエージェントをツールではなくチームメンバーとして扱うと、すべてがうまくいきます。GitHubはチームの共有メモリになります。Issueはワークアイテムになります。PRは成果物になります。そして、あなたはチームリーダーとなり、AIチームが実装を処理する間、アーキテクチャ、方向性、品質に集中します。
それが、2ヶ月間で404回のリリースを出荷した方法です。そして、それがAIで自分の開発をスケールできる方法です。
