deep-thinkingとgrillmeの比較

[mapserver2007]

grill-me と deep-thinking — 議論の要点

結論（先に）

• grill-me をワークフロー（kit の ①〜⑥）に乗せる必要はない。
• 検査・裁定のベースは現行 deep-thinking のまま。grill-me に乗り換えない。
• grill-me の席はワークフロー内ではなく、issue 化前のユーザー意図の固定（任意の前工程）。
• 理想の「既存知識に照らした総合検査」の本体は deep-thinking 単体ではなく requirement-analysis（Gate A/B/C）。deep-thinking はその deep 経路の推論エンジン。

---

両者の違い

	grill-me / grilling	deep-thinking
叩く対象	ユーザーの計画（暗黙決定を表に出す）	エージェント自身の判断（単一視点バイアス）
対話	尋問が本文。決定はユーザー	尋問は内部。回答だけ返す
事実	エージェントがコード/環境から取る	docs-first + 一次証跡で再確認
成果	会話上の shared understanding（ファイルを書かない）	自然言語回答。ワークフローでは Investigation Memo へ吸収
品質の主な振れ	ユーザーの回答・反論の質 × エージェントの質問設計	初回プロンプトと既存証跡。途中の往復尋問にはほぼ依らない

似て見える理由は、どちらも「迎合」と「暗黙前提の放置」を嫌うから。手段は対立する。

• grill-me: 暗黙前提を ユーザーに言わせる
• deep-thinking + Gate B: 暗黙前提を 既存証跡で反証する

---

認識の補正

1. grill-me の成果は人間の関与で変わる — 正しい。公式も「質問数ではなく回答の質」と書く。ただし frontier は計算グラフではなくエージェント判断なので、質問側の質も効く。
2. deep-thinking は人間の尋問なしに機械的な裁判で判定する — 前半（往復尋問しない）は正しい。後半は言い過ぎ。独立性・正確性は保証されず、裁定は LLM 判断。価値判断だけ AskQuestion。
3. だからプロンプトに依らない — 誤り。依るのは途中の尋問ではなく 初回の問いと既存 docs/コード。
4. 深掘り範囲は限られる — 「ユーザーの暗黙知を掘る経路がない」なら正しい。「常に浅い」ではない。掘れる軸が違う。

---

理想の検査との対応

理想: プラン/チケットを、ワークフロー・ドメイン・FR/NFR に照らして漏れ・逸脱を検査する。

理想の検査	既存の置き場
要求の漏れ・未決定	Gate A
仕様・ワークフロー・ADR・Boundaries との逸脱	Gate B
実現性・依存・性能・ロールバック	Gate C
高影響・仕様矛盾・候補複数の裁定	deep-thinking（deep 経路）

「deep-thinking がその目的で作られた」は、Step ① deep 経路の部品としては正しい。検査スキルそのものとしては広すぎる。

grill-me をベースにしない理由: 照合先が人間の頭になり、本キットが避けたい「尋問品質依存」に戻る。既存の Memo / Gate / G-DEEP-* 接続も全部組み直しになる。

足りないのは primitive の置換ではなく、deep 経路ブリーフへの検査次元の必須化（Gate A/B 項目、NFR、設計逸脱）。grilling から借りるのは尋問 UI ではなく「全枝を沈黙前提のまま残さない」思想だけ。

---

grill-me が使える場面

使える。主戦場はワークフローの外。
workflow-orchestrator は issue 作成を対象外にしており、requirement-analysis の入口は「要求テキスト」。そのテキストを sharpen する段階が grill-me の席。

推奨パイプライン（条件つき）:

1. 要求が粗いときだけ grill-me（技術決定は聞かない）
2. 結果を issue / plan に書く（stateless なので成果物化が必須）
3. 別セッションでワークフロー
4. Gate A/B/C は必ず通す。deep-thinking は現行の深度判定のまま

固めてよい: 困りごと、対象/対象外、ユーザー視点の成功、今はやらないこと、優先。
固めてはいけない: API・分割境界・既存 ADR/NFR・実装候補の優劣（それは Gate B / deep-thinking）。

使わない: 既に Gate A を満たす issue、再現付きバグ、PO 確定済み、1–2 ファイル作業、ワークフロー途中の再尋問。
毎回の必須前工程にすると、passivity（全部 agreed）と Context Budget の両方を踏む。

同一チャットで尋問→①〜⑥は避ける。評価だけで Yellow に入ると実装が劣化する。

---

最終推奨

1. ベースは現行 deep-thinking。組み替えない。
2. 検査の本体は requirement-analysis。
3. 改善するなら deep 経路のブリーフに検査次元を足す。
4. grill-me は別スキルとして、曖昧要求の issue 化前に任意で使う。
5. framework.* / D-WORKFLOW を変える実装に進むなら ADR が必要。今は組み替えない判断で足りる。

---

確定: kit のワークフローには乗せない

grill-me をワークフロー（kit の ①〜⑥）に乗せる必要はない。

requirement-analysis と deep-thinking で、既存 SoT に照らす検査と裁定は足りる。Step ① の前段や deep 経路の置換として組み込むと、尋問の二重化と Context Budget の悪化の方が大きい。

使うなら kit の外で十分。要求が粗いときだけ、issue 化する前の任意作業として手元で回す。必須スキルとしても、オーケストレータのステップとしても、追加しない。