連載：複数の AI を率いる統合管理環境「vicara」の裏側
- 第1弾：概要・思想編
- 第2弾：技術深掘り編
- 第3弾：徹底比較編
- 第4弾：開発プロセス編（本記事）
前回の記事では、多様な AI 開発ツールが溢れる中での vicara の立ち位置や、5 つのレイヤーによるマッピングについてお話ししました。
第 4 弾となる今回は、vicara 自体を開発しているのか、その「開発プロセス」の裏側をお話しします。
実は現在、vicara 自体の開発は 54 ループ（タスク完了回数） を突破し、Epic 54 まで到達しました。これだけの規模になっても、AI エージェントが文脈を見失ってプロジェクトが「崩壊」することなく、安定して前進し続けられています。
なぜ、モデルを切り替え、セッションを新しくしても、AI は迷わずに作業を継続できるのか？その裏側にある 「ハーネス（手綱）」 の設計と、 「役割分担」 の妙についてお話しします。
1. 開発を「崩壊」させないための「ハーネス」：規約による制御
AI エージェント、特に自律的にコードを書き換えるタイプ（Claude Code や Gemini / Codex 等）を使っていると、必ず直面するのが「文脈の迷子」と「トークンの浪費」です。
vicara の開発では、これらを防ぐために人間が AI に与える 「ハーネス（手綱・制約）」 を徹底的に言語化しています。
MODULE_MAP.json：AI の「視界」を制限する
プロジェクトが大きくなると、AI に全てのファイルを読ませるのはコスト的にも精度的にも悪手です。
そこで導入したのが MODULE_MAP.json です。
{
"frontend-core": {
"paths": ["src/components/ui/**", "src/context/**", "src/hooks/**", "src/types/**", "src/App.tsx", "src/main.tsx"],
"description": "【ベースライン】共通UI, Context, hooks, 型定義。フロントエンドのタスクでは型エラーを防ぐため必ず参照すること。"
},
"frontend-kanban": {
"paths": ["src/components/kanban/**", "src/components/board/**"],
"description": "Kanbanボード関連のUI。カンバンやスプリントのタスクに直接関係する修正の場合のみ参照すること。"
},
"backend": {
"paths": ["src-tauri/src/**"],
"description": "Tauri バックエンド（Rust）。バックエンドのロジックやIPCコマンドの実装・修正が必要な場合のみ参照すること。"
}
}
AI エージェントはこのマップをタスク開始時に読み込み、関係ないモジュールのファイルは一切読み込まないように規約で縛っています。これにより、「AI が不要なファイルまで読み込んで混乱する」のを防ぎ、同時にトークン消費を劇的に抑えています。
これらをスリムかつ厳格に保つことで、Gemini Flash や Claude Haiku といった軽量・高速な「小型モデル」でも、高度な文脈を理解して動ける環境 を整えています。
実際のルールファイルの中身（Why / How / What）
PRODUCT_CONTEXT.md (Why)
スクラムを「人間とAIの共通プロトコル」として定義する、プロダクトの魂です。
# PRODUCT_CONTEXT.md — vicara プロダクトコンテキスト
## 0. 解決したい課題とコアバリュー
- 課題: 既存のAIツールは「全自動（ブラックボックス）」か「都度指示（文脈リセット）」の二極化。
- 解決策: スクラムを、人間とAIの状態遷移を同期する「共通プロトコル」として採用する。
## 2. 役割分担の原則
- 人間（PO）: 「何を作るか（What）」のアイデア提示と、最終的な意思決定のみを行う。
- AI（Dev/SM）: 「どう作るか（How）」のタスク分解、実装、テスト、プロセス改善を自律的に担う。
...
Rule.md (How)
具体的な技術スタックと、AIが守るべき「絶対の掟」を記しています。
# vicara 開発ガイドライン (Rule.md)
## 2. コーディング規約とアーキテクチャ
- UIのリアクティビティ (最重要): Mutation後にUIが即時更新されない実装は「不正」とする。
- SQLの安全性: 文字列連結によるSQL生成は厳禁。プレースホルダーを徹底せよ。
## 3. エージェントの振る舞い（運用ルール）
- 実装前のプロセス: コーディング着手前に、(1)アプローチ (2)変更対象ファイル (3)影響範囲 (4)リスクを提示し、POの承認を得ること。
- 完了報告: 必ず walkthrough.md を出力し「変更内容・テスト手順・検証結果」を提示せよ。
ARCHITECTURE.md (What)
システムの構造を AI に正確に把握させるための設計図です。
# ARCHITECTURE.md — vicara 設計ドキュメント
## AIロールの責務分離
- POアシスタント: POの判断を補佐。API / CLI で動作。
- 開発エージェント: CLI経由でタスクを自律実行。Git Worktree上で動作。
## Git Worktree によるタスク分離
- 開発エージェントはタスクごとに git worktree を作成し、隔離された環境で実行する。
- 完了後に main ブランチへ --no-ff マージ → worktree 削除。
2. AI を「プロンプトエンジニア」にする：2 重ループワークフロー
人間が AI に指示を出すとき、どうしても「曖昧さ」が混じります。その曖昧さが AI の誤動作を招く。
そこで vicara の開発では、「AI に、AI への指示文を考えさせる」 という 2 重ループを採用しています。
Loop 1：指示文の精錬（Gemini Chat）
まず、ブラウザ版の Gemini 等で、私（人間）と AI で要件を壁打ちします。
人間：「ここをこんな感じに修正したい」
Gemini：「それなら、こういう計画で進めるのが良さそうです。エージェント向けに、この指示文（プロンプト）を使ってください」
人間が直接指示を書くのではなく、AI が「AI に最も伝わりやすい指示」を生成する。これにより、指示の曖昧さを排除します。
Loop 2：計画・実装・検証（AI エージェント）
生成された「完璧な指示文」を Antigravity などの AI エージェント環境に貼り付けます。
-
計画 (
implementation_plan.md) とタスク案 (task.md) の自動生成。 - その計画を再び Gemini Chat でレビュー。「この実装案は漏れがないか？」を確認。
- 実装の実行。
- 完了時に
walkthrough.md(変更内容・テスト手順) を生成させ、計画と一貫しているか人間が最終確認。
この「AI によるセルフレビュー」をプロセスに組み込むことで、人間に依存しない高品質な開発ループが実現しています。
3. 「チーム」としての実像：AI モデルの使い分け
さて、プロセスが「ハーネス」なら、そこを走る「馬」である AI モデルにも、個別の役割を振り分けています。これは以前 Zenn の記事 でも語らせてもらいました。
Gemini：「整える」担当
ブラウザ版の Gemini (3.1 Pro) は、驚異的なコンテキスト保持能力を活かし、「文脈の管理人」 として機能します。指示文の作成、バックログの精査、ドキュメントの整形を担います。たまーに変な方向に走るのでそこは人間がきちんと管理ですね。
Claude：「考える」担当
実装計画の検討や、複雑な設計の壁打ち、リスク分析には Claude 4.6 Opus を使います。 「行間を読み、最適な構造を提案する」 力は、やはり Claude が極めて優秀です。ただ、ドキュメント行数が圧倒的に多くなりやすいので、Proプランだと仕様作成するだけでも5時間制限が来てしまいなかなか利用が難しくなっています。
Codex / OpenAI：「作る」担当
実際の実装フェーズ、特に「とにかく動くものを出す」「既存のパターンに従って量産する」という場面では OpenAI 系のモデルが圧倒的な突破力を見せます。修正のラリー（試行錯誤）に強く、開発をグイグイ前進させてくれます。めちゃめちゃ動くコードを書いてくれますが、if文ネストを大量に使うなど、あまり美しくないコードとかも出してきたりしますね…ただ、利用制限が緩く圧倒的に実装できる。感謝。
このように、「最強の 1 モデル」を探すのではなく、この 3 者を「ハーネス（規約）」で繋ぎ、適材適所で使い分ける。 これが vicara を崩壊させずに Epic 54 まで導いたチームの実態です。
利用量制限によるやむなしも多かったのですけどね…笑
4. 継承の技術：handoff と BACKLOG
AI との開発で最も怖いのは、セッションが切れたり、モデルを切り替えた時に「今までの経緯」が忘れられることです。これを vicara では物理的に解決しています。
-
handoff.md (Layer 2 コンテキスト)
開発の節目のたびに、「今どこまでやったか」「次に何をすべきか」を AI に強制的に書き出させます。 -
BACKLOG.md
あえて今はやらない「技術的負債」や将来のアイデアをここに集約します。
これにより、新しいチャットセッションを始めても、AI はこの 2 つのファイルを読み込み、「前回の自分の記憶」を瞬時に取り戻して、続きから作業を再開できます。
5. まとめ：これは「ハーネスエンジニアリング」なのか？
自分でやりやすい方法を模索した結果、辿り着いたこの開発スタイル。最近言われている 「ハーネスエンジニアリング」 に近いものかもしれません。
AI という強力で、時に予測不能な推進力を、
-
MODULE_MAP.jsonという**「視界の制限」** - スリムなドキュメント群という**「行動原理（規約）」**
- 2 重ループという**「自己検閲プロセス」**
という「ハーネス（手綱）」によって制御する。
AI エージェントは魔法ではありません。適切な「仕組み」と「役割」を与えれば、たとえ個人の開発であっても、50 以上のループを戦い抜ける**「堅牢なチーム」**になってくれます。
この記事が、AI との協働に悩む皆さんの「手綱」を握るヒントになれば幸いです。
連載：複数の AI を率いる司令塔「vicara」の裏側
- [第1弾：概要・思想編] ：複数の AI を率いるコントロールプレーン
- [第2弾：技術深掘り編] ：Tauri v2 + ターミナル統合 + Git Worktree
- [第3弾：徹底比較編] ：Claude Code や Devin とはどう使い分けるべきか
- 第4弾：開発プロセス編（本記事）
- [第5弾：AIレトロスペクティブ編] ：次スプリントへ「経験」を引き継ぐ仕組み
🔗 GitHub: https://github.com/ytakahashi0302-ghb/ai_scrum_tool
（Star をいただけると、開発プロセスをさらに磨く励みになります！）