■ 1. コーディングエージェントの自律化と監視困難の背景
- コーディングエージェントの登場当初は、コマンド実行やコード生成のたびに承認し、逐一監視する手法が一般的であった
- AI モデルの性能向上とハーネスエンジニアリングの発展により、エージェントは自律的にタスクを完了できるようになっている
- 複数のエージェントを並行して実行したり、大規模なワークフローを構築する運用が標準化されている
- 並行して複数のエージェントを動かすことが当たり前になった今、エージェントの動きを逐一監視することは現実的ではなくなっている
■ 2. 認識のズレが引き起こす問題と設計フェーズの重要性
- 監視なしで動作するエージェントの認識のズレは、タスク完了後まで発見できない
- 要求が満たされていない場合、すべてやり直しになるリスクがある
- 要求が満たされていても、アーキテクチャの不適切さやコード品質の低さにより、コードレビュー段階で大幅な修正が必要になる場合がある
- 実装前の設計フェーズで要件を明確にし、人間と AI の間で共通理解を形成することが重要になっている
■ 3. 共通理解の形成における課題
- はじめのプロンプトで漏れなく要求や設計の意図を伝える必要があるが、実際に行うのは難しい
- 課題の種類:
- 暗黙知の問題: 人間は無意識のうちに重要な情報を省略する傾向があり、AI は毎回ゼロから理解を構築する必要があるため影響が大きい
- 言語化の難しさ: 複雑なシステムや抽象的な概念を言葉だけで正確に伝えることが難しい場合がある
- 要件の未確定: 言葉にしてみると設計に漏れや矛盾があることに気づく場合がある
■ 4. プランモードの機能と限界
- 機能:
- コードを変更せずにコードベースを調査し、変更内容の方針や手順を計画として提示する
- 不明点があればユーザーに質問し、回答をもとに計画を修正する
- 複数の選択肢を提示し、比較・議論しながら設計を検討できる
- 限界:
- 設計の全体像が一度にまとめて提示されるため、ユーザーが深く考えずに「OK」と承認してしまいがちである
- 全体像を AI が一気通貫に作成するため、人間と AI が議論しながら進めることが難しく、設計の主導権が奪われる問題が生じる
■ 5. /grill-me スキルの概要と特徴
- Matt Pocock 氏がプランモードの欠点を克服するために作成したスキル
- 計画や設計についてユーザーを徹底的にインタビューし、設計ツリーの各分岐を解決しながら共通理解に到達するまで質問を続ける
- スキルの内容はわずか 3 行で、要点は「共通理解に達するまで徹底的に質問し、設計ツリーの各枝をたどって依存関係を 1 つずつ解決する」こと
- 動作の特徴:
- AI が質問し、ユーザーが答える形式を取るため、設計の主導権は人間側にある
- 質問は 1 つずつ行われる
- コードベースを調べることで疑問が解決できる場合は、エージェント自身がコードベースを調査する
- 各質問に対して推奨回答を提示し、会話のスピードアップを図る
- 設計のテーマによっておよそ 10〜50 個程度の質問が行われ、徹底的に掘り下げられる
■ 6. 設計ツリーの概念
- 書籍『デザインのためのデザイン』（フレデリック・P・ブルックス Jr. 著）に由来する概念
- 1 つの設計判断を下すと、それに依存する複数の設計判断が必要になる木構造を指す
- 各ノードでは別の道を選ぶことができたという点が重要であり、設計空間を探索することで設計の全体像を把握しながら詳細を詰めることができる
■ 7. /grill-me スキルの活用上の注意点
- 最重要原則: AI に設計を任せきりにするのではなく、人間側で設計の構成要素をある程度把握しておくこと
- 失敗パターン:
- 人間が質問に対して受け身になりすぎ、深く考えずに「OK」と答え続ける態度
- 極端な例では 540 個もの質問を浴びせられたり、重要度の低い細部まで範囲が広げられたりする
- 求められる姿勢:
- エージェントの質問に対してアクティブに回答し、どこに向かうかを決め、会話の方向性を調整するなど議論をリードする
- 面接ではなく会話として進めることが重要
- 自分の頭の中にある設計のイメージを AI と協力して言語化するツールとして位置づける
■ 8. 実際の使用方法と実践上の注意点
- インストール方法: GitHub リポジトリから直接コピーするか
npx skills addコマンドを使用する- 質問の忠実度によるスコープ管理:
- 低忠実度な質問（プロトタイプなしで答えられる質問）に限定して進めることが推奨される
- 高忠実度な質問（プロトタイプが必要な質問）が出てきた場合はハンドオフパターンを使用し、プロトタイプ作成後に再度スキルを呼び出す
- 設計スコープの管理:
- スコープが広すぎると高忠実度な質問が多くなり、コンテキストウィンドウの限界に達しやすくなる
- 巨大なスコープを扱う場合は、まずタスクを分解してから各タスクに個別に適用する
- プロンプトの渡し方:
- 最初のプロンプトはあえてざっくりとした指示にとどめ、実装方法を制約として与えない
- 実装方法ではなく必要な性質を伝えることで、AI がよりよい解を見つける余地を確保する
- 実践例（カンバンアプリへの生産性ダッシュボード機能追加）:
- 18 回にわたる質問が行われた
- 「完了」の定義、ボトルネックの算出・表示方法、集計スコープ、時間範囲フィルタ、グラフ描画手段、差し戻し時の扱い等が議論された
■ 9. 実装フェーズへの移行と関連スキル
- コンテキスト管理:
- 設計フェーズ完了後に実装フェーズへ移る際、コンテキストをリセットすることは失敗パターンである
- 設計フェーズの質問と回答のやりとりは実装フェーズのコンテキストとして引き継がれるべきである
- コンテキストに余裕がない場合や実装が大規模な場合は、設計フェーズのやりとりを /docs ディレクトリなどにドキュメントとして保存する
- 関連スキル:
- /to-prd スキル: 設計を PRD（Product Requirements Document）にまとめるためのスキル
- /grill-with-docs スキル: 計画を既存ドキュメントと照らし合わせながら検証し、CONTEXT.md や ADR を決定のたびにその場で更新するアプローチを取るスキル（Matt 氏が推奨）