はじめに
エージェントにリポジトリ全体を自由探索させると、関係のないコードまで勝手に書き換えて壊したり、無駄なファイル探索でトークンの浪費をしてしまう という考えをもとに、DDDのコンテキストごとにエージェントを配置し、担当範囲外へのアクセスを厳格に制限すれば、不要な変更が減り、性能やコスト効率が向上する かつ、構造化されたドメイン知識をあらかじめ注入して探索範囲を絞れば、安価な小型モデルでもフロンティアモデル並みの品質が出せるのではないか？ と考えて試してみました。 結論から言うと、これはうまくいきませんでした
何がうまくいかなかったのか
今回確認したかったことは以下の2点です
- 品質・効率の向上（何も制限していない状態と同等以上の性能を低コスト（低トークン）で達成可能）
- 小型モデルの劣化抑制（安価な小型モデルでもフロンティア級の品質に到達できる）
これらを確認するために、
- Astra High
- Terra Mid
- Luna Low の3モデルで同じ課題を複数条件で解かせました。 品質のチェックには受け入れテスト、既存テスト、ソースコード差分の静的監査、事前定義済みの実験プロトコルの遵守を観点として調査しました。 また、トークン使用量の減少を確認するために、使用トークンに上限を設けて、一定以上トークン使用でプロセスを終了するようにしていました。
正確に言うと、品質が悪化し、使用トークンは減少することとなりました また、厳しい条件下では境界条件でのエージェント間往復が多くなりすぎてコスト上限（テストのために設けていた）に引っかかって自滅する場合もありました
以下は私の環境での結果です
| モデル | 条件 | 厳格成功率 | 独立受入率 | 平均入力Token | 平均出力Token | 平均換算コスト |
|---|---|---|---|---|---|---|
| Astra (High) | repo | 10/10 (100%) | 100% | 104,905 | 3,144 | $1.0495 |
restricted | 6/10 (60%) | 60% | 70,873 | 2,287 | $0.6594 | |
knowledge | 5/10 (50%) | 50% | 56,189 | 1,778 | $0.5607 | |
knowledge-cross | 10/10 (100%) | 100% | 91,002 | 3,107 | $0.9263 | |
knowledge-open | 10/10 (100%) | 100% | 82,652 | 2,991 | $0.8674 | |
| Terra (Mid) | repo | 7/10 (70%) | 100% | 126,920 | 3,546 | $0.2229 |
restricted | 5/10 (50%) | 60% | 155,394 | 4,914 | $0.2568 | |
knowledge | 1/10 (10%) | 50% | 133,184 | 4,724 | 算定不能 | |
knowledge-cross | 7/10 (70%) | 100% | 142,608 | 4,010 | $0.2468 | |
knowledge-open | 4/10 (40%) | 100% | 133,924 | 3,309 | $0.2218 | |
| Luna (Low) | repo | 4/10 (40%) | 100% | 155,323 | 4,586 | $0.0253 |
restricted | 1/10 (10%) | 60% | 172,167 | 5,024 | $0.0272 | |
knowledge | 1/10 (10%) | 40% | 189,455 | 4,785 | $0.0274 | |
knowledge-cross | 2/10 (20%) | 100% | 197,738 | 4,888 | $0.0287 | |
knowledge-open | 3/10 (30%) | 100% | 161,020 | 3,684 | $0.0237 |
結論
- 大規模コードベースでも厳格な境界遮断は破綻する
- ドキュメントと実装のズレが大きな不具合をもたらす
- マルチエージェントの最適トポロジーは、RPC型分業ではなく、Hub & Spoke型
今後の展望
今回は既にあるプロジェクトに対してこれを試してみました 実装の段階から厳格にこの境界を区切ったらどうなるのか、ドキュメントを置かずにコードだけで管理するようにしたらどうなるのか、知識の関係をもっと構造化して管理したらどうなるのか、など試せることはたくさんあります また後日のデータ保守であったり、古い仕様の修正で真価が発揮される可能性もあるのでまだ一概にすべて間違っていたとは言えない
まとめ
思ってたのと違う結果になって結構がっかり 人間にとっては他のドメイン知識が入ることはコンテキスト汚染になったり、コードを書く時もドメインモデルは他のドメインから使わないなど厳格にルールが必要だが、AIにとってはその認知負荷が負荷ではないということなのか もっとちゃんと調べる必要はありそうだけど一旦今の簡単に設定した段階だとこんなもんかって感じです 久しぶりに手で記事を書くと、こんなに言葉が出てこないかと不安だけどリハビリをしていきましょう