【社内セミナー公開・後編】「AIを優秀なメンバーとしてどうコントロールするのか」上流エンジニアによるAI駆動開発「cc-sdd」実践のリアル
前編では、AI駆動開発のフレームワーク「cc-sdd」の基本と、新規・既存案件での導入事例をご紹介しました。
しかし、AIを実プロジェクト、特に大規模なシステムに導入するにあたっては、「AIの暴走をどう防ぐか」「複雑な仕様をどうAIに理解させるか」といった生々しい課題が必ず発生します。
後編では、セミナー終盤に行われたエンジニア同士のディスカッションの様子をお届けします。上流エンジニアがいかにしてAIを「優秀なメンバー」としてコントロールしているのか、リアルな議論をご覧ください。
1.AIを「育てる」というエンジニアの新しい面白さ
エンジニアM： ルールを書いた際、それが本当に効いているか定量的に示す方法はありますか？ 自分で書いていても、効いているのかどうかわからなくなる時がありまして…。
登壇者A： 実装を進める中で「この辺がうまく効かないからルール化したい」という現場の声をどんどん追加していくアプローチを取っていました。例えば「共通処理の重複排除」など、分かりやすいルールを書いて、次の実装や設計に反映されているか確認していく。このルールの「育成」によって、後半はAIが自律的に動けるようになりました。ただ、ルールを書きすぎると逆に精度が落ちるので、バランスは難しいですね。
2. モノレポ環境の壁：コンテキスト汚染をどう防ぐか
エンジニアM： 初手から複雑にしすぎず、シンプルにするのが大事そうですね。例えばモノレポ環境のプロジェクトで、全体ルールの「ステアリング」にドメイン知識などをすべて書き込むと、コードが複雑になりすぎる懸念がありますが、どう進めるのが良いのでしょうか？
石立（CTO）： これ、結構難しいなと思います。個人的には、ステアリングはなるべく軽く（薄く）しておきたいんです。ドメイン知識をすべて入れるとコンテキストが溢れてしまうので。最近は、ステアリングには「前提条件」だけを持たせてコンテキストを薄く保ち、個別のドメイン知識は「スキル（サブエージェント）」に分離して処理させるという考え方でやっています。
エンジニアM： なるほど。 ドメイン知識もスキルに外出しして、必要なときに注入できるようにしたほうがいいですね。モノレポ環境だとすごく効きそうなので試してみたいです。
登壇者A： そうですね。今回の新規案件もモノレポ環境だったので、ステアリングを可能な限り薄く保つことにはすごく注意しました。フロントエンドとバックエンドの実装が同じステアリングを読み込むことになるので、それを怠ると無駄なコンテキスト消費やシステムの精度低下を招いてしまいますから。
石立（CTO）の関連記事はこちら
おわりに
いかがでしたでしょうか。 テックファームでは、現場のエンジニアが自ら最新技術を実プロジェクトに導入し、そこで得られた知見や課題を全社でオープンに議論・共有しています。
今回はAI駆動開発のなかでも仕様駆動開発（SDD）を、cc-sddというフレームワークにて実践するテーマでの社内セミナーを紹介しました。みなさんの参考になれば幸いです。
