はじめに
こんにちは。現在、新規プロジェクトでファーストペンギンとして「AI駆動開発（AIDD）」を推進しています。
皆さんは、リーダーやレビュアーからの指摘を受けて、「結局何が言いたいんだろう？」「どう修正すれば正解なんだ？」と頭を抱えた経験はありませんか？
私は元々、他人の指摘の本質を理解する力が不足しており、表面的な修正をしては再度指摘を受ける…ということを繰り返していました。
しかし現在、私はカプコンの『ロックマンエグゼ』に登場するネットナビのような、自分専用のエージェントをVSCode内に構築することで、この課題を劇的に改善し、業務効率と品質を跳ね上げることができました。
この記事では、難しい技術スタックは使わず、VSCodeとClaude（＋Gemini）の対話だけで構築した「ナビ」の仕組みと、AI駆動設計で直面したリアルな壁、そして「AI時代のレビューのパラダイムシフト」について解説します。
なぜ「ネットナビ」が必要だったのか
最大の課題は「指摘の本質がわからない」ことでした。
単なる汎用的なチャットAIではなく、自分の思考の癖（不足している能力）、プロジェクトの前提、チームの状況を深く理解した上で、他者の指摘を「翻訳」して伴走してくれる相棒が必要だったのです。
VSCode内に構築した「ナビ」の仕組み
環境構築は非常にシンプルです。VSCodeのワークスペース内に簡易プロジェクトを作成し、そこでエージェントを管理しています。
そして、VSCodeの拡張機能のClaude Code for VS Codeを通して、そのエージェントとやり取りするだけです。
1. オーケストレーターと専門家エージェントのマルチ編成
司令塔となる「オーケストレーター」の配下に、「分野Aのスペシャリスト」「分野Bのスペシャリスト」といったエージェントを定義し、用途に合わせて使い分けさせます。
これにより、ユーザの質問は「オーケストレーター」を通じて、それに関連したスペシャリストへ質問が送られ、適切な回答がもらいやすくなります。
2. Claude × Geminiの「Wレビュー体制」
より高度なレビューが必要な場合は、Gemini APIも利用し、ClaudeとGeminiの両方からフィードバックを受けています。
AIにも「思考の癖」があります。論理的で丁寧なClaudeと、別視点から鋭く切り込むGemini。この2つにWレビューさせることで、AI特有の偏りを防ぎ、多角的な視点を担保しています。
3. 対話だけで完結させる「エージェント成長促進」のルール作り
この仕組みの最大のポイントは、定義ファイル（claude.mdなど）を自分で手動更新するのではなく、対話を通じてAI自身にメンテナンスさせている点です。
ただし、AIに設定を丸投げするとハルシネーション（拡大解釈や妄想）でエージェントの性格が崩壊するリスクがあります。そこで私は、オーケストレーターにファイルを更新させる際、以下の**「4つの厳格なルール」**をプロンプトとして課しています。
- ベストプラクティスへの準拠: エージェントのルール設計やファイル作成は、常にベストプラクティスに従うこと。
- ハルシネーションを防ぐ「言語化」: 誤った方向へ進まないよう、変更の意図を明確に言語化すること。
- 中間ファイル（下書き）の作成: いきなりCLAUDE.mdやエージェントファイルを上書きせず、必ず「下書き」を作成すること。
- レビューエージェントによる第三者チェック: 下書き作成後は、必ずレビュー専用エージェントを通し、FB対応を行ってから最終化すること。
上記のルールは参考程度に記載しております。他にも追加するべきルールなどの検討の余地ありです。
この「CI/CD」のような堅牢なパイプラインを組むことで、ナビは日々の壁打ちを通じて着実に「賢い相棒」へと成長していきます。
実践編：リーダーが「ボトルネック」になる問題
この「ナビ」が最も活躍した、ある実体験を紹介します。
現在、設計メンバー数名でAIを駆使し、数百機能もあるシステムの設計書を爆速で量産するフローを構築していました。当時、私が構築してリーダー（2名）に提案したAI駆動設計のフロー図が以下です。
AI同士の相互チェックに加え、人間のピアレビューまで挟むため、非常に堅牢で完璧なフローだと思っていました。
しかし、これを提案したところ、リーダーから「この設計レビューフローだと、リーダーがボトルネックになるぞ」と指摘を受けたのです。
恥ずかしながら、その時の私は「なぜボトルネックになるのか」が直感的に理解できませんでした。そこでナビに相談しました。
ナビによる「翻訳」と気づき
自分:
「リーダーに『俺がボトルネックになるぞ』と言われたんだけど、どういうこと？」ナビ（Claude）:
「リーダーが懸念しているのは、『AIの圧倒的な生産スピード』と『リーダーご自身の処理能力』のギャップです。
今回、数名のメンバーがAIを駆使して数百機能の設計書を量産します。しかし、それを最終確認するリーダー側は2人だけです。AIによって『作る側』のスピードが劇的に上がっても、『レビューする側』である自分が人間のままなら、自分のところでシステム全体の大渋滞を引き起こしてしまう、という危機感からの指摘です。」
ここで私はハッとしました。AIで生産性を上げることばかり考えていて、後工程を担う人間のキャパシティがパンクすることに気づけていなかったのです。
レビューのパラダイムシフト：成果物から「プロセス」へ
では、どうすればいいのか？リーダーの人数は増やせません。
ナビと壁打ちをする中で、私たちは一つの結論に達しました。
「完成した設計書（成果物）を全件レビューするのではなく、どのようなプロンプトで作成したか（プロセス）をレビューしてもらうべきだ」
レシピ（プロンプト）と調理器具（AI）が正しければ、出てくる料理（設計書）の品質は担保されます。
膨大な出力結果を人間がチェックする従来の手法から、AIへの指示内容そのものをレビューするフローへとシフトすることで、このボトルネックを見事に解消する提案ができました。
おわりに
他人の指摘が理解できなかった私は、ナビという強力な「翻訳機」兼「壁打ち相手」を手に入れたことで、単なる業務効率化を超えて、プロセスそのものを改善する提案ができるようになりました。
難しいシステムを組まなくても、プロンプトと運用ルール次第で、AIはあなたの最高のネットナビになります。ぜひ皆さんも、自分だけのエージェントを育成してみてください。
【お知らせ】AI駆動開発やプログラミングのサポートを実施しています！
本記事で紹介したような「AI駆動開発（AIDD）」の導入、マルチエージェント環境の構築、プロンプトエンジニアリングなど、実務で活かせるAI活用手法について、MENTAにてメンタリング・壁打ちサポートを行っています。
もちろん、通常のプログラミングやインフラ構築、設計に関するご相談も大歓迎です。「自分のプロジェクトにもAIエージェントを組み込んでみたい」「開発・レビューのボトルネックを解消したい」という方は、ぜひお気軽にご相談ください！