grill-me と dig の比較・使い分け提案

調査日: 2026-05-21

結論

grill-me は、計画や設計を短い対話でその場検証するための軽量なインタビュー指示です。1問ずつ深掘りし、必要ならコードベースを調べ、各質問に推奨回答も添える前提なので、初期案の穴を素早く見つける用途に向いています。

dig は、Claude Code のプラグインとして構成された重めの探索プロセスです。事前の文脈収集、仮定のリスク分類、2から3問単位の構造化質問、発見事項の整理、計画ファイルへの反映、完了判定まで含むため、高リスクな計画を固める用途に向いています。

使い分けの基本方針は「まず grill-me で軽く炙り出し、リスクや未決定事項が多い場合に dig へ移る」です。最初から dig を使うのは、計画ファイルがあり、決定ログを残したい場合か、失敗時の影響が大きい場合に限るのがよいです。

参照元

比較

観点	grill-me	dig
位置づけ	AI エージェント用の短いスキル指示	Claude Code の slash command / plugin
主目的	計画・設計を対話で厳しく詰める	隠れた仮定、リスク、未検討の意思決定を体系的に発見する
質問スタイル	1問ずつ質問する	1ラウンド 2から3問、各問に複数選択肢と pros/cons を付ける
深掘り方針	決定ツリーの各分岐を順に解決する	高リスク仮定から depth-first に掘る。主要トピックは2段階以上深掘りする
事前調査	コードベースで答えられる質問は、質問せず調べる	計画ファイル、`CLAUDE.md`、関連ドキュメント、会話文脈を読む
出力	質問と推奨回答が中心	ラウンドごとの発見、意思決定表、残リスク、次アクション、計画ファイル更新
停止条件	明示的な停止条件は弱い	完了チェックリストがある
ファイル編集	指示上は必須ではない	計画ファイルへの反映を前提にしている
ツール依存	比較的移植しやすい	`AskUserQuestion`、`TodoWrite`、`Write/Edit` など Claude Code 前提が強い
適した粒度	まだ粗いアイデア、短時間の設計確認	実装前の計画レビュー、設計確定、リスク洗い出し

向いている場面

grill-me が向いている場面

まだ計画が粗く、まず論点を見つけたい。
5分から15分程度で計画の弱点を見たい。
ユーザーが1問ずつ考えたい。
既存コードを見れば答えが出ることは、AI 側に調べてほしい。
計画ファイルや決定ログまでは不要。
実装前の軽い design review として使いたい。

例:

この認証設計を grill-me してください。
コードで確認できる前提は質問せず調べて、最大5問に絞ってください。
各質問にはあなたの推奨回答も添えてください。

dig が向いている場面

すでに plan.md、PRD、仕様書がある。
隠れた前提や障害時の扱いを体系的に洗いたい。
複数人に共有する意思決定ログを残したい。
失敗時の影響が大きい設計、移行、権限、データ、課金、運用を扱う。
「何を決めたか」「なぜそうしたか」「何が未解決か」を文書に反映したい。
一度の質問ではなく、回答から新しい問いを作って深掘りしたい。

例:

/dig
対象は docs/plan.md です。
高リスクな仮定を優先し、決定事項は plan.md の Decisions に反映してください。

使い分けフロー

flowchart TD
  A["計画・設計を検証したい"] --> B{"計画ファイルや仕様書がある?"}
  B -- "ない / まだ粗い" --> C["grill-me"]
  B -- "ある" --> D{"失敗時の影響が大きい?"}
  D -- "小さい" --> C
  D -- "大きい" --> E["dig"]
  C --> F{"高リスク仮定が複数見つかった?"}
  F -- "いいえ" --> G["そのまま実装・次アクションへ"]
  F -- "はい" --> E
  E --> H["決定・残リスク・次アクションを計画へ反映"]

導入時の推奨ルール

最初から質問責めにしない。コード、仕様書、既存ドキュメントで確認できることは先に調べる。これは両者に共通して入れるべきルールです。
grill-me には停止条件を足す。元の指示は「relentlessly」「every aspect」「each branch」の圧が強く、無限に分岐しやすいです。最大質問数、対象範囲、終了条件を追加した方が実務向きです。
推奨回答の出し方に注意する。 grill-me は各質問に推奨回答を添えるため、ユーザーの判断を早い段階で誘導する可能性があります。重要な意思決定では「まず選択肢と trade-off、次に推奨」の順にする方が安全です。
dig は軽い相談には使わない。 dig は文脈収集、仮定マッピング、計画更新まで含むので、数分で済む確認には重すぎます。小さなタスクで使うと、実装より儀式が大きくなります。
dig を移植するならツール依存を置き換える。 dig は Claude Code の AskUserQuestion や TodoWrite を前提にしています。Codex や ChatGPT で使う場合は、通常の質問、タスク管理、ファイル編集フローへ明示的に置き換える必要があります。
計画ファイルの自動更新は確認ルールを持つ。 dig は発見と決定を計画ファイルへ書く設計です。チーム運用では、どのファイルのどのセクションへ書くか、既存記述を上書きしてよいかを明確にしてから使うべきです。

指示として適当でなさそうな点

grill-me の懸念

「あらゆる側面」「決定ツリーの各分岐」を追う指示は、範囲が広すぎます。実務では、リスク上位、不可逆な決定、コードで確認できない前提に絞る方が効率的です。
明示的な停止条件がありません。時間制限、最大質問数、または「高リスク論点がなくなったら終了」を加えた方がよいです。
推奨回答を毎回出す設計は有用ですが、ユーザーの考えを狭めるリスクがあります。特にプロダクト判断や組織判断では、推奨より先に選択肢と trade-off を出すべきです。
「質問できるがコードで答えられることは調べる」という方針はよい一方で、何をもって「答えられる」とするかが曖昧です。調査結果と推測を区別するルールがあると安全です。

dig の懸念

Claude Code 専用ツールへの依存が強く、そのまま別環境に移すと破綻しやすいです。特に AskUserQuestion がない環境では、質問 UI と選択肢提示のルールを再設計する必要があります。
計画ファイル更新が前提なので、読み取り専用レビューや短時間相談には不向きです。
完了チェックリストは強力ですが、すべて満たそうとすると調査が長引きます。高リスク領域だけに限定する運用が必要です。
「2段階以上深掘り」はよい制約ですが、すべての主要トピックに適用すると過剰です。重要度が低いトピックは1段階で止める裁量が必要です。

推奨するハイブリッド運用

普段使いでは、次のように組み合わせるのが扱いやすいです。

grill-me で初期スクリーニングする。最大5問、1問ずつ、コードで確認できることは先に確認する。
高リスク仮定が見えたら dig に移る。対象ファイル、更新先セクション、質問ラウンド数、完了条件を明示する。
dig 後は実装タスクに変換する。決定事項、未解決リスク、検証タスク、実装タスクを分ける。
小さな修正や既知のバグにはどちらも使わない。その場合は質問よりコード調査とテストを優先する。

改良版プロンプト例

軽量版 grill-me

この計画を grill-me してください。
先に関連コードとドキュメントを確認し、そこから答えられることは質問しないでください。
質問は最大5問、1問ずつ行ってください。
各質問では、選択肢、trade-off、あなたの推奨を示してください。
高リスクな未決定事項がなくなったら終了してください。

実務向け dig

docs/plan.md を対象に dig してください。
まず文脈を読み、高リスクな仮定だけを優先してください。
質問は1ラウンド最大3問、最大2ラウンドまでにしてください。
決定事項は docs/plan.md の Decisions セクションに追記し、既存記述は上書きしないでください。
最後に残リスクと次アクションを箇条書きでまとめてください。

最終提案

日常的な設計相談、アイデア検証、実装前の軽い壁打ちは grill-me。
仕様書・計画ファイルがあり、リスクや意思決定を記録したい場合は dig。
高リスクだがまだ計画が粗い場合は、grill-me で論点を絞ってから dig。
既知の実装作業やバグ修正では、どちらも使わずコード調査とテストを優先する。

両者は競合するツールではなく、計画の成熟度とリスクに応じて段階的に使い分けるものです。

k2ikeda/grill-me-vs-dig.md

Select an option

No results found