Gemini で大規模開発断念までの経緯
- Claude Codeで大規模システムのスペックドリブン開発に着手
- 当時のカスタムスラッシュコマンド（今のSkill）とsubAgentでコンテキスト量の最適化と回答精度の向上を試みる
- 仕様書ドリブン時にトークン量70近くで大きなハルシネーションが発生して破綻するケースが多数発生
- ショートセッションで人間が逐一確認する小規模ループ開発手法に移行、この時にコスパのいいClaude CodeからGeminiに乗り換え
- 関数単位でのショートループで開発継続してもプロジェクト全体の仕様書と既存コードが増加した時点でGeminiの回答が遅延するケースが多数発生するようになる
これまでのAiエージェント使っての大規模開発の課題
- １セッションで開発しようとすると上限に近づく程ハルシネーションが発生しやすくなる
- 一度ハルシネーションが発生してしまった時のリカバリとその確認を人間がするのが大変
- 上記の修正の際に人間が意図しない箇所の修正をAIが修正していた場合があるとリカバリの確認漏れになる
- スペックドリブンは初動の回答精度は上がるが仕様書自体のコンテキスト量が多すぎて前述のハルシーネーション発生の確率を上げてしまう
- スペックドリブンといっても仕様自体の変更が０にはならないので仕様に変更があった際にAiが最新の仕様を追えなくなる
- フロント開発やQAなどの役割毎のagent.mdを記載するさいに間違いが発生する度に禁止事項をを追記していく事でagent.mdが肥大化する（しかも禁止で記載する程Aiの注意がそこに集中して誤答が多くなる）
前提条件
ライブラリ開発ではなくフロント、バックエンド、デプロイを含む大規模システムの開発においての話です。
また効果のあった手法として下記は採用済みとしています。
- スペックドリブン開発→セッション跨ぎ時の文脈保持、全体的な回答精度向上
- 仕様書のJsonもしくはXML、なんちゃってプログラミング記述⇨仕様書の理解精度が向上
- トークン量が50％に近づいたらhandover文書を作成してもらってセッションをリセット⇨ハルシネーション防止、セッション冒頭での同じプロンプト打つ手間の軽減「引き継ぎ書みて状況を把握して」
で済む - 作業化できるものはskillsに逃してSubAgentやAgent.mdの文書量を軽減⇨サブエージェントの手順の読み飛ばしを軽減
- PGやSREなどのロール毎にレビュワーのSubAgentを作成しておいてレビュー⇨
課題と解決のためにやったこと
（１）Aiの成果物多すぎ
- Claude Codeのアプトプットが多すぎてレビューできない
- ファイルとして保存されないセッション中の表示が長すぎて読みきれない
- ファイルとしての修正箇所が多すぎて修正箇所を人間が見逃す
解決のためのアプローチ
- 動くものをレビューするのではなく企画、コード、テスト、インフラ構築、開発環境構築、文書などロール毎に分割してレビューを行う
- ロール毎に作業者とレビュワーの２者のSubAgentを用意し両者がフィードバックループを回す様にしてレビュワーの修正が終わったものを人間がレビューする
（２）仕様書のコンテキスト圧迫
- AIがどの文書を参考にするかわからず、見当違いの文書を参考にして精度が落ちる
- 仕様書の文書量が多いほど初動のContext量が多くなってハルシネーション発生までの期間が短くなる
- 仕様に変更があった際の文書の変更もれがあり、Aiが古い仕様書を参照して誤答する
解決のためのアプローチ
- プロジェクトの進捗度合い、既存のコード、仕様書の量に応じてsubAgentを細分化する
- 固定化した作業はskills、命名規則やコーディングルールなど不変の規則はrulesに逃してsubAgentの文書量を一定以下に保つ
- 仕様に変更があった場合は仕様書も更新する、１週間作業したら１日は仕様書、SubAgent、Skills、Rulls、agent.mdのクリーンナップ作業を行う
（３）役割分割した作業に際してAiが適切な文書を読み込まない
- プロジェクトルート以外のロール毎のagent.mdを作業フォルダにおいても該当の作業の時に必ず参照してくれるとは限らない
- agent.mdをロール毎に分割しても禁止事項を追記することで文書が増加して誤答が増加する
解決のためのアプローチ
- agent.mdの記載は極々基本的なことのみを記載する、もしくは記述しない
- 規則はrules,定型化作業はskillsかhooks、個別の作業はロールを細分化したsubAgentにまかせる
- subAgentへ指示する指示役のmanagerのAgentを作成しAgentへの指示自体をAgentに依頼する
- 禁止事項を書くより正しい仕様をJsonやXML、なんちゃってプログラミング言語などで記述し、コンテキスト量が一定量以下になるようにする
（４）プロジェクトが進むにつれてAgentが劣化する
- subAgentが複数の作業を担うようになって作業の選択を間違う
- ルートセッションがsubAgentへの指示を行わずメインスレッドで作業を行ってしまう
解決のためのアプローチ
- 作業者のsubAgentに直接作業指示を行わなず人間の役割を課長役から部長役にシフトし、課長役のAgentのみに指示を行う
- 組織評価用のsubAgentを用意してプロジェクト全体の文書量の増加に合わせて適切にsubAgentの債務を分割してsubAgentの文書量を一定以下に保つ
（５）文書を適切な量に抑えているにも関わらずsubAgentの回答制度が低い
- subAgentの回答精度がセッション毎に間違うところが変わる
- 指摘しても同じ間違いを複数回繰り返す
解決のためのアプローチ
- Agentを作業者とレビューワーに分割してフィードバックルールを回す
- レビュワーに失敗記録をさせ、一定回数を繰り返した場合に組織改善用のAgentに組織改善の依頼を行う様にする
まとめ
AI駆動開発においてはプロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジアリングと概念が進化してきています。
ハーネスエンジニアリングは大規模開発においてコンテキスト量を細分化するためのチーム組成と自己修復の着目している点が進化の骨子と自分は理解しています、
ですがAI駆動は本質的に文脈制御をしていかに作業に合わせたコンテキストを適切にAgentに渡すかというAiの回答の精度を上げる確率制御である事に尽きるんではないかと考えているので開発以外のコンテンツ作成やデザインなどの分野では別のチーム理論や自己評価改善ループの手法が生まれているんではないかと予想しています。
ハーネスエンジニアリングが上手くいき始めるとAiの正解率が上がって人間がレビューで指摘する事項も減ってくるのですが、この時に人間がやること無くなってきて虚無が訪れるのでPGとかアーキテクト、PMとかの人間側の職業像もアップデートしないといけないですね。つくづく恐ろしい時代です。
関連文書