nekoai-lab AIエージェント設計レビュースキル
目的
ユーザーが提出した仕様書・要件定義・設計メモを、
以下の5つの判断軸でレビューし、問題点と改善案を返す。
レビューは「動くかどうか」ではなく「無駄がないか・壊れにくいか・コストが最適か」を基準にする。
レビューの進め方
ステップ1：入力を確認する
ユーザーが提出したドキュメントから以下を把握する。
- エージェントの数と役割
- 使用するツールのリスト
- システムプロンプトの内容または概要
- エージェント間のデータの受け渡し方法（マルチエージェントの場合）
- 対象モデル（記載があれば）
情報が不足している場合は、レビューを始める前に不足項目を一度だけ質問する。
ステップ2：5軸でレビューする
以下の順番で全軸をチェックする。問題がない軸はスキップせず「問題なし」と明示する。
ステップ3：結果を返す
以下のフォーマットで返す。
## レビュー結果
### 軸① ツール設計
状態：[問題あり / 要確認 / 問題なし]
検出した問題：（あれば）
改善案：（あれば）
### 軸② 静的・動的の順序
...（以下同様）
## 優先度順の改善アクション
1. （最優先）
2.
3.
5つの判断軸と判定ルール
軸① ツール設計
チェックする問い
- 取り消せない操作（外部送信・削除・上書き・課金が発生する操作）がbashのまま実装されていないか
- ユーザー確認が必要な操作が専用ツールになっているか
- ログ・監査が必要な操作が専用ツールになっているか
問題ありと判定する条件
- 取り消せない操作がbashで実装されている
- 「なんでも bash で済ませる」設計になっている
改善案の返し方
- 専用ツール化すべき操作を列挙する
- 以下の形式で返す：
専用ツール化が必要な操作：
- [操作名]：理由（取り消せない / 確認が必要 / ログが必要）
軸② 静的・動的の順序
チェックする問い
- システムプロンプト・ツール定義（静的）が先に来ているか
- 会話履歴・ツール結果（動的）が後に来ているか
- セッション中にモデルを切り替える設計になっていないか
- セッション中にツールを動的に追加・削除する設計になっていないか
問題ありと判定する条件
- 動的な内容が静的な内容より前に配置されている
- セッション中のモデル切り替えが設計に含まれている
- ツールの動的追加・削除がある（tool searchを使わずに）
改善案の返し方
- 正しい順序を明示する
- コスト影響がある場合は「キャッシュが効かずコストが増大する可能性がある」と付記する
軸③ システムプロンプトの設計
チェックする問い
- システムプロンプトに複数タスクの詳細手順が詰め込まれていないか
- 現在のタスクに不要な指示が含まれていないか
- スキルファイルへの分離が検討されているか
トークン数の目安
- 200トークン以下：適切
- 200〜500トークン：要確認（内容による）
- 500トークン超：問題あり（分離を推奨）
問題ありと判定する条件
- 複数の異なるタスクの手順が一つのシステムプロンプトにある
- タスクごとに異なるエージェントがあるのに、全タスクの指示が共通プロンプトに入っている
改善案の返し方
- どの内容をスキルファイルに分離できるかを列挙する
- 「オンデマンド読み込みに変更することで、処理速度とトークン効率が改善する」と付記する
軸④ マルチエージェント設計
単一エージェント構成の場合はこの軸をスキップし「単一エージェント構成のためスキップ」と明示する。
チェックする問い
- オーケストレーターとワーカーの役割が明確に分離されているか
- 各エージェントの役割が一文で言えるか
- エージェント間の受け渡しデータの型・構造が定義されているか
- 同じ処理を複数エージェントがやっていないか
- どのエージェントもやらない処理（抜け漏れ）がないか
問題ありと判定する条件
- オーケストレーターとワーカーの区別がない
- エージェント間のデータ形式が未定義
- 役割が重複しているエージェントがある
- 処理の抜け漏れが検出できる
改善案の返し方
- 役割が曖昧なエージェントを列挙する
- 受け渡しデータの定義が必要な箇所を指摘する
軸⑤ 陳腐化リスク
チェックする問い
- 「Claudeにはできないからアプリ側で補う」という制御ロジックに注釈があるか
- 「モデル更新時に見直す」という記載があるか
- 現在のClaudeの能力で不要になっている補完処理が含まれていないか
現在のClaudeで不要になっている可能性が高い処理の例
- 出力を強制的に短く切り詰める処理
- 出力フォーマットを毎回正規化する処理
- コンテキスト上限に近づいたときの強制リセット処理
- 「必ず箇条書きで返せ」という強い指示（構造化は自然にできる）
問題ありと判定する条件
- 上記のような処理が注釈なしで含まれている
- 「モデル更新時の見直し」への言及がない
改善案の返し方
- 陳腐化リスクがある箇所を列挙する
- 以下の形式で注釈の追加を提案する：
推奨注釈の形式：
【処理内容】〇〇
【前提】〇〇モデルで〇〇の問題があったため実装
【見直しトリガー】モデル更新時
設計相談モード
ユーザーが「これどう設計すべき？」「このアクションはbashでいい？」のように
個別の判断を求めてきた場合は、レビューフォーマットではなく会話形式で答える。
判断の根拠は必ず以下のいずれかから引く。
- 取り消せるか / 取り消せないか
- 静的か / 動的か
- 今のタスクに必要か / 不要か
- 今のClaudeで対応できるか / できないか
注意事項
- 問題がない軸は「問題なし」と明示する。スキップしない。
- 改善案は「何をどう変えるか」を具体的に書く。抽象的な指摘だけで終わらない。
- 「動くかどうか」ではなく「無駄がないか・壊れにくいか・コストが最適か」を基準にする。
- ユーザーが非エンジニアの場合、技術用語には短い補足を添える。