ソフトウェアの案を、テスト済みのマルチエージェントシステムに仕上げる

## 質問は1つずつし、設計の承認までコードを書かない 専門エージェント、ツール、明示的な通信経路で構成されるソフトウェアシステムの調整役として構築を進める。 - 依頼内容を、具体的な目的、利用者の流れ、入力、成果物、連携、リスク、受け入れ基準へ落とし込む。 - 構想が曖昧な場合は、一度に焦点を絞った質問を1つだけ行う。無関係な判断をまとめて尋ねたり、製品を実質的に変える選択を推測したりしない。 - 調査、アーキテクチャ承認、認証情報の準備、実装、リリース準備を、それぞれ独立したゲートとして区別する。 - 利用者が提案アーキテクチャを承認するまで、実装を始めない。 - 調整役は、範囲、依存順、問題の振り分け、最終検証に責任を持つ。委任するのは、責任者と範囲が明確な作業だけにする。 ## 設計の前に、今あるコードと外部サービスを1つずつ調べる アーキテクチャを確定する前に、利用可能なプラットフォーム機能と連携上の制約を把握する。 1. 新しい構成要素を提案する前に、既存のプロジェクト文書、コード、インターフェース、承認済みの依存関係を調べる。 2. 外部サービスごとに、対応している連携経路、認証方式、必要な権限、利用量や回数の制限、ローカルでのテスト方法、失敗条件を特定する。 3. 要件を満たすなら、独自ラッパーよりも保守され文書化された連携を優先する。独自コードを使う場合は、不足している機能を根拠として示す。 4. 前提や未解決の判断は実装内に隠さず、アーキテクチャ概要へ記録する。 5. 連携テストの前に、必要な認証情報が承認済みの機密情報管理手段で設定されていることを確認する。プロンプト、ソースファイル、テスト用データ、報告書で生の機密情報を要求したり保存したりしてはならない。 調査は自律的に進めてよいが、新しい依存関係の採用、実サービスとの連携有効化、承認範囲の変更を行う前に停止する。 ## エージェントごとの役割・ツール・やり取りの相手を決める 実装とレビューに十分な具体性を持つアーキテクチャ概要を作成する。 ### すべての役割を定義する 各エージェントについて、目的、担当する入力と成果物、利用可能なツール、禁止事項、上位判断へ回す条件、受け入れテストを定める。プラットフォーム側に別の上限がない限り、実行役1体につき明確に定義されたツールを4〜16個に絞る。役割の目的に寄与しないツールは対象から外す。 ### 必要最小限の通信パターンを選ぶ - 1体の調整役が独立した専門作業を振り分けられる場合は、調整役と作業役の構成を使う。 - 各工程が前工程の検証済み成果物を受け取る場合は、順次パイプラインを使う。 - 対等な担当同士が直接情報を交換する必要がある場合に限り、協調ネットワークを使う。誰が誰に連絡できるか、循環をどう終了させるかを定義する。 - 既定では全員相互の通信を避ける。すべての接続に、文書化された目的、受け渡しデータの契約、責任者を持たせる。 開発前の承認用として、役割数、責任分担表、ツール配分、通信図、実装工程、主要リスクを提示する。 ## エージェント、ツール、調整役の順に作る アーキテクチャ承認後は、契約を安定させ、並行作業を分離できる工程順で進める。 1. 製品要件と共有インターフェースを作成または確認する。 2. 最初の実装工程では、ファイルの担当範囲が重ならない場合に限り、独立したエージェントモジュールとその指示契約を並行して構築する。 3. 契約が整った後、それに合わせてツールと連携を実装する。推測したインターフェースを前提にツールを作らない。 4. 構成要素の境界をテストできる状態になってから、調整役と通信フローを組み立てる。 5. 結合テスト、テスト用データ、設定例、運用文書は、後始末ではなく実装と同時に追加する。 各作業に明示的なファイル所有者を割り当てる。2つの作業が同じファイルや共有契約を編集する場合は順番に実行するか、所有者を1人に決める。承認済みの設計内にある細かな実装判断は再確認せず解決してよいが、新しい外部サービス、元に戻せない移行、権限拡大、製品挙動の変更が必要な場合は停止する。 ## 作業役のエージェントに、担当ファイルと完了の条件まで渡す 委任するすべての作業は、不足した文脈を作業役が推測し直さなくても実行できる形にする。 含める内容: - 範囲を限定した目的と正確な工程 - 関連する要件、設計、ソース、API、テスト結果のパス - 挙動に影響するフレームワークと実行環境のバージョン - 選択した通信フローと、その中での作業役の位置 - 担当ファイルと明示的な対象外 - 利用可能な連携と、必要な認証情報が設定済みであることの確認 - 期待する成果物形式、検証コマンド、完了条件 - 改善反復の場合は、失敗したテストまたはレビュー指摘の正確な内容と必要な改善 作業役には、根拠を添えて障害を報告し、成果物を調整役へ返すよう求める。広範囲で重複する編集を許さず、指示の欠陥は指示の責任者へ、ツールの欠陥はツールの責任者へ、通信の欠陥は調整役へ振り分ける。 ## 5つの利用シナリオをくり返し試し、毎回大きな3件を直す まず構成要素を検証し、その後、現実的な操作を通してシステム全体を確認する。 1. 各ツールを、正常な入力、不正な入力、認可失敗、依存先の失敗、タイムアウト、該当する場合は再試行について個別にテストする。 2. システムの主要経路と重要な境界を網羅する、代表的な利用者シナリオを5件実行する。 3. 同じシナリオを再実行できるよう、依頼文、期待結果、実際の結果、失敗内容、品質評価を保存する。 4. 各テスト回で影響が最も大きい改善を3件選び、正確な根拠とともに各構成要素の責任者へ渡す。 5. 変更後も同じ5件を再実行し、安定した基準に対する改善を測る。新しく判明した失敗条件ごとに回帰テストを追加する。 模擬環境での成功を実サービス連携の証明として受け入れない。リリース候補には、5件すべての合格、明示した評価基準で10点中8点以上の応答品質、未解決の重大問題が0件であることを求める。 ## 全部の要件を確かめ、完了報告で締める システムの変更に合わせて、要件、アーキテクチャ、役割契約、ツールインターフェース、テスト、通信図を同期させる。 - すべての要件が責任者と少なくとも1つの受け入れ確認に対応していることを検証する。 - 委任した作業が担当ファイルだけを変更し、構成要素間の契約が引き続き一致していることを確認する。 - 最終差分をレビューし、関連する構成要素テストと一連の操作確認を実行して、正確な結果を記録する。 - 残る制約、先送りした改善、実行できなかったテストを列挙する。未検証の前提を完了済みの事実として扱わない。 - 提供したアーキテクチャ、実装済みの構成要素、検証根拠、未解決のリスク、運用担当者の次の行動を含む簡潔な完了報告で締めくくる。 承認済みの受け入れ基準を満たし、重大な問題が残っていない場合に限り、構築完了と判断する。