曖昧なエンジニアリングの問題を解決するために、私がどのようにAI Councilを活用しているか

AIアシスタントが1つあれば便利です。しかし、複雑なソフトウェアアーキテクチャにおいては、それだけでは不十分です。

AIをオートコンプリート以上の用途で使っていると、あるパターンに気づきます。単一のモデルが解決策を提案します。それは良さそうに見えます。あなたはそれを実装します。しかし、3日後、重大なアーキテクチャ上の欠陥が見つかるのです。

これはモデルの失敗ではありません。あなたのプロセスの失敗です。単一のモデルが自らの前提に疑問を呈することはめったにありません。

曖昧な問題を解決するには、「AI Council（AI評議会）」が必要です。これは新しいプラットフォームのことではありません。複数のAIコンテキストが、異なる役割から提案をレビューするというワークフローのことです。

目標は、AIの利用を統制されたエンジニアリングワークフローへと変えることです。

ワークフローは以下の通りです：

• 問題定義 (Problem Statement): あなたが問題を定義します。 • アーキテクト・エージェント (Architect Agent): ソースに基づいたエージェントが、トレードオフを含めた提案を作成します。 • AI Councilによる批評 (AI Council Critique): さまざまなAIの役割が提案をレビューします。 • フィードバックの統合 (Feedback Synthesis): エージェントがすべてのフィードバックを評価し、矛盾点を特定します。 • 異議管理台帳 (Objection Ledger): すべての異議、その深刻度、および解決策を記録します。 • 人間によるガバナンス (Human Governance): プランが準備できているか、あるいはもう一度サイクルを回す必要があるかを判断します。 • エグゼキューター・エージェント (Executor Agent): 別のコンテキストがプランを実装します。 • オーディター・エージェント (Auditor Agent): 第三のコンテキストが、元の仕様に照らしてコードを監査します。

その力は「役割の分離」から生まれます。単に「どう思う？」と聞くだけではいけません。異なるAIセッションに特定の役割を割り当ててください：

  • システム思考者 (System Thinker): システム的なリスクと境界を評価します。
  • 批判的レビュアー (Critical Reviewer): 前提に疑問を投げかけ、論理的なギャップを見つけます。
  • 簡素化担当 (Simplifier): 不要な複雑さを見つけ出します。
  • 代替案レビュアー (Alternatives Reviewer): 異なるアプローチを提案します。

最も重要な部分は「異議管理台帳 (Objection Ledger)」です。これがないと、フィードバックは漠然とした意見になってしまいます。台帳を使うことで、あらゆる懸念事項を解決せざるを得なくなります。異議を「未解決 (Open)」「承認 (Accepted)」「却下 (Rejected)」「解決済み (Resolved)」としてマークします。これにより、監査可能な意思決定記録が作成されます。

あなたはコピペ作業のボトルネックにはなりません。ソースに基づいたエージェントが統合を行います。あなたは「ガバナー（統治者）」として振る舞います。手作業を行うのではなく、ゲート（承認プロセス）を管理するのです。

あなたが意思決定を行います：

  • いつイテレーションを止めるか。
  • いつ仕様を承認するか。
  • いつ最終的なリスクを受け入れるか。

高リスクなリファクタリングや、不明確なアーキテクチャに対してこれを使用してください。些細なバグ修正には使用しないでください。オーバーヘッドに見合うのは、設計ミスによるコストが高い場合のみです。

小さく始めてください。批評担当を1つ、簡素化担当を1つ用意するだけで十分です。すぐにその価値を実感できるはずです。

Source: https://dev.to/j3nnning/how-i-use-ai-councils-to-solve-ambiguous-engineering-problems-4dii