2026/08/29Claude Code

Skills活用AI活用非エンジニア向け

grill-me・grillingとは｜非エンジニアの使い方

「AIに頼むと、それっぽい成果物はすぐ返ってくる。でも自分が本当に決めたかったことは、結局まだ決まっていない」——grill-me / grilling というClaude Codeのスキルが注目されているのは、まさにこの悩みに効くからです。

結論から言うと、足りないのはAIの性能ではなく、AIに渡す前提の解像度です。grill-me（グリルミー）／ grilling（グリリング）は、その解像度を上げるためにAIが逆にあなたを質問攻めにするClaude Codeのスキルで、コードを書かない人ほど効きます。

株式会社Fyveは中小企業のAI活用を支援していますが、この記事は「開発者向けの紹介」ではありません。私が実際にコードではない事業側の判断に使い、1ラウンド出したところで打ち切るまでの記録と、日本語の解説記事がすでに古くなっている3つの点をまとめます。

grill-me・grillingとは何か｜合計2KBのテキストファイル

grill-me は、AI開発の解説サイト aihero.dev を運営する Matt Pocock 氏が公開しているスキル集の1本です。やることは一言で言えば「AIがあなたにインタビューする」。あなたが何かを作らせる前に、AIの側から論点を並べて質問を投げ、答えが揃うまで着手しない、という振る舞いをさせます。

実物は驚くほど小さいものです。私の環境に入れて実測した中身がこれです。

grill-me … 7行 / 22語 / 157バイト
grilling … 28行 / 319語 / 1,987バイト

合わせて2KBちょっと。プログラムでもアプリでもなく、Markdownで書かれた指示書が1枚あるだけです。作者自身も「スキルはインパクトを出すために長い必要はない。適切なタイミングで適切な言葉を選べばいい」と書いています。

grill-me と grilling は「改名」ではない

日本語の解説でよく見かける「grill-me は grilling に改名された」という説明は、正確ではありません。2つは今も両方存在していて、役割が違います。

grilling が本体。質問の設計思想と進め方が書かれた実体で、他のスキルからも呼び出される共用部品です
grill-me は人間が叩くための入口。中身は「grilling を呼べ」の1行だけ。しかも disable-model-invocation: true が付いていて、AIが勝手に発動することはありません（あなたが呼んだときだけ動きます）

本体が切り出されたのは2026年5月31日のコミットで、これは改名ではなく抽出です。同じ grilling を呼ぶ入口は他にもあり（grill-with-docs／triage／wayfinder など）、grill-me はその中で「いちばん有名になった入口」という位置づけになりました。

作者本人もXで「grilling がスキルの核であって、grill-me は馴染みがあるから残しているだけの薄いラッパーだ」と説明しています。

ちなみに規模感として、このスキル集のリポジトリは2026年2月3日に作られ、2026年8月29日時点で240,440スター / 20,444フォーク（GitHub API実測）。約7か月でこの数字です。

スター数は時期によって桁が変わるので、他所で数字を見たときは必ず「いつ時点か」を確認してください（作者本人の投稿でも2026年3月23日時点で9,000、4月30日時点で46,600と、短期間で大きく動いています）。

grill-me と grilling の関係図｜入口と本体（改名ではなく抽出）

なぜ「AIに質問させる」だけで成果物が変わるのか

AIは空欄を空欄のまま残さない

作者はこの技法が生まれた理由を、はっきり書いています。

この技法が存在するのは、エージェントが黙って隙間を埋めてしまうからだ。2行のプロンプトから仕様書を書けと言われたエージェントは、あなたがまだ決めていない決定の前で止まらない——勝手にデフォルトを選び、書き込む。出来上がったものは完成して見え、しかも推測とあなたの選択が見分けられない。だから発覚が遅れる。

ここが本質です。AIは「分かりません」と止まってくれません。もっともらしい既定値を入れて、あなたが決めたことと同じ顔で提出してきます。だから読んでも違和感がなく、動かし始めてから「そこ、そういうつもりじゃなかった」となる。

あなたにしか答えられない層がある

AIに渡す情報は、3つの層に分けて考えると整理できます。

第1層・事実（どのファイルに何が書いてあるか、今の数字はいくつか）… AIが自力で調べられる
第2層・常識と定石（一般的にはどう作るか）… AIが学習済みで持っている
第3層・意図と優先順位と許容範囲（誰に何を売るのか、何を捨てていいのか、どこまでなら失敗していいのか）… あなたにしか答えられない

AIは第3層を原理的に埋められません。にもかかわらず、空欄のままにもしない。この矛盾が「惜しい成果物」の正体です。grilling がやっているのは、第3層だけを、抜けなく、人から引き出すことです。

「惜しいけど、ちょっと違う」が現場の最大の摩擦になっている

これは私の実感だけの話ではありません。Stack Overflow の開発者調査2025では、AIツールを使用中または使用予定と答えた人が84%いる一方で、その正確性を信頼している人は29%にとどまっています。

そして最大の不満として挙がったのが、「AIの解決策が、ほとんど正しいのに、あと一歩正しくない」（66%）でした。2位は「AIが生成したコードのデバッグに時間がかかる」（45%）です。

完全に間違っているものは捨てられます。捨てられないから直すことになり、直す時間が積み上がる。この「惜しさ」は能力不足から来るのではなく、前提のズレから来ています。

聞き返させるだけで精度が上がるという研究結果

「先に質問させる」ことの効果は、学術的にも測られています。

ClarifyGPT の研究（ACM PACMSE 2024 収録）では、AIに曖昧な要求を検出させて人に質問し返させるだけで、同じモデル・同じ課題セットでも正答率が上がりました。

MBPP-sanitized というベンチマークで GPT-4 の Pass@1 が 70.96% → 80.80%、4つのベンチマーク平均でも GPT-4 が 68.02% → 75.75%、ChatGPT が 58.55% → 67.22% です。

裏返しの研究もあります。2026年4月に公開された論文では、要求仕様に曖昧さを混ぜると Pass@1 が平均 7.22ポイント低下し、GPT-4 では最大28ポイント超落ちたと報告されています。さらに決定的なのが次の点です。

LLMが「この要求は曖昧だ」と気づける精度は約50%（コイン投げと大差ない）
どこが曖昧なのかを特定できる精度は23%を超えることがほとんどない

AIは自分では曖昧さに気づけない。だから「気づけ」と祈るのではなく、外側から質問させる仕組みを付ける必要がある——これが grilling のような道具が要る理由です。

経営目線でまとめるなら、DORAの2025年レポートが言う「AIは増幅器である（既存の強みも弱みも拡大する）」が分かりやすいと思います。AIを入れれば良くなるのではなく、今の意思決定の質がそのまま拡大されます。grilling は、増幅器に入れる前の信号を整える装置です。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →

Plan Mode との違い｜止めるものが違う

Claude Code を使っている方から必ず聞かれるのが「Plan Mode（プランモード）と何が違うのか」です。似て見えますが、守っているものが根本的に違います。

	Plan Mode	grilling / grill-me
正体	Claude Code の権限モード（本体の機能）	テキストファイル1枚（合計2KB）
何を止めるか	AIの手（ファイル編集を物理的にブロック）	何も止めない。AIの口を変える
情報の流れ	AI → 人（AIが調べて提案し、人がYes/No）	人 → AI（AIが聞き、人が答える）
引き出すもの	調べれば分かること	調べても絶対に分からないこと（意図・優先順位・許容範囲）
主導権	AIが案を出し、人が承認する	決定は常に人

一言で言えば、Plan Mode は「AIに勝手にやらせない」ための安全装置、grilling は「AIに勝手に決めさせない」ための対話装置です。

そして重要な運用上の注意があります。作者は「grilling を使うときは Plan Mode をオフにしろ」と明示しています。Plan Mode はAIを「早く計画書を出す」方向に急かすため、問いを掘り下げ続ける動きとは逆に働くからです。

もう一点。Claude Code には AskUserQuestion という「AIが人に質問する」標準ツールがすでにあります。つまり grilling の付加価値は「質問すること」自体ではありません。質問を止めないこと、そして論点を網羅すること——ここが違いです。

日本語の解説がすでに古くなっている3つの点

grill-me は2026年の春から夏にかけて日本語圏でも大きく話題になり、解説記事がかなりの数出ています。ただ、私が読んだ範囲ではほとんどが同じ時期の挙動を前提にしていて、その後の変更が反映されていません。実務で使うなら、ここは押さえておいてください。

1. 「質問は1問ずつ来る」はもう既定ではない

日本語の解説記事の多くが「1問ずつ聞いてくれるのが良い」と書いています。これは2026年7月16日の変更で覆っています。

作者が書いた変更履歴にはこうあります。

grilling を「1問ずつ」から「ラウンド単位」に作り直した。いまは決定ツリーを描いて、フロンティア（前提が既に決着していて今すぐ聞ける問い）を、番号付きで1ラウンドにまとめて聞く。同じ13問が、13回ではなく約3ラウンドで着地する。

この「フロンティア」という考え方が grilling の骨格です。決定は木構造になっていて、ある問いの答えが決まらないと聞けない問いがある。だから今この瞬間に聞ける問いだけをまとめて出し、答えが返ってきたら木を組み替えて、次のラウンドを計算し直す。順序そのものが設計されています。

そしてもう一つ、grilling には重要な決まりがあります。

事実を見つけるのはあなた（AI）の仕事であって、ユーザーの仕事ではない。フロンティアの問いに環境の事実（ファイルシステム、ツール等）が必要なら、サブエージェントを送って調べさせろ。自分で調べられることを人に聞くな。

人には、人にしか答えられないことだけが来る。これが後述する私の実体験で、いちばん効いた条項でした。

【日本語話者向け】1問ずつに戻す方法がある

ラウンド制になったことで「一度に5問も6問も来ると処理しきれない」という声もあります。これについて作者は、1問ずつに戻す設定を公式に用意していると明言しています。

「1問ずつに戻せますか？」——戻せます。実際、利用者のかなりの割合がそうしています。グローバルの CLAUDE.md にこの1行を足してください：When grilling, ask one question at a time.　ラウンド方式が既定であることについては議論があります。ゆっくり読む人、第二言語で仕事をしている人、順番に来る形式を集中の足場として使っている人からは、1問ずつのリズムのほうが良いという報告が来ています。この選択は「渋々許容している」のではなく、サポートされているものです。

「第二言語で働く人には1問ずつのほうが良い」と作者自身が書いている——これはまさに日本語で読んでいる私たちのことです。英語で5問まとめて飛んでくるとつらい、と感じたら、~/.claude/CLAUDE.md に次の1行を足すだけで戻せます。

When grilling, ask one question at a time.

2. 作者本人は「コードでは使うのをやめた」と言っている

これは日本語の解説でまだ見かけない情報です。作者はXでこう書いています。

grill-me は私史上いちばん人気のスキルで、ワークフローが良くなったという連絡を毎日5〜10通もらう。でも……コードでは使うのをやめた。改良版がこれだ。

後継として案内されているのが wayfinder というスキルで、1セッションに収まらない大きさのものに使うものです。

ただし、これを「grill-me はもう終わった」と読むのは誤読です。作者が公開している使い分けはこうなっています。

作業ディレクトリで作業していない（＝手元にコードベースが無い） → grill-me
作業ディレクトリにいる（コードベースがある） → grill-with-docs
1セッションに収まらない大きさ → wayfinder
会話では決着しない問い（見た目・触り心地） → prototype（作って判断する）

つまり作者がコード用途を別スキルに移した結果、grill-me に残されたのは「コードから離れた用途」です。事業の構想、商品の設計、価格の考え方、ヒアリングの準備——コードベースを開いていない場面こそが、いま grill-me の本来の居場所になっています。非エンジニアにとってはむしろ好都合な整理です。

3. grill-me だけ入れても動かない

これは私が実機で踏んだ穴です。多くの記事やスキル配布サイトは grill-me だけをインストールするコマンドを載せていますが、それだけでは動きません。

理由は単純で、grill-me の中身は「grilling を呼べ」の1行しかないからです。呼ばれる側の grilling が入っていなければ、入口だけあって部屋がない状態になります。作者もFAQで同じ質問に答えています。

「grill-me だけ入れたのに何も起きません」——grill-me は全体が「grilling セッションを実行しろ」だけの1行スキルなので、grilling も一緒に入れる必要があります。

後述の導入手順では、この穴を踏まない入れ方を書きます。

導入手順｜非エンジニア向けの入れ方

ルートA：プラグインで丸ごと入れる（推奨）

非エンジニアの方にはこちらをおすすめします。Claude Code のターミナルで次を実行するだけです。

claude plugins install mattpocock-skills

これは Anthropic の公式マーケットプレースに登録されているスキル集で、作者のスキルがまとめて入ります。作者の説明によれば「読み取り専用の管理されたバンドルとして全部入り、私が更新を出せば追従する。フォークするのではなく購読する形だ」とのことです。

中身を自分で書き換えられない代わりに、依存関係の穴を踏まず、作者の改善が自動で降ってきます。「1問ずつから1ラウンドずつへ」のような変更も、放っておいて追従できるということです。

ルートB：必要なものだけ入れる（中身を見たい人向け）

中身を読みたい・自分で編集したい場合はこちらです。必ず2本とも入れてください。

npx skills@latest add mattpocock/skills -g -s grilling  -a claude-code -y --copy
npx skills@latest add mattpocock/skills -g -s grill-me  -a claude-code -y --copy

私が実際に踏んだ細かい落とし穴を2つ書いておきます。

エージェント名は claude-code。-a claude と書くと「Invalid agents: claude」で失敗します（対応エージェントは75以上ありますが、claude 単体は無効です）
-g は「個人の道具箱に入れる」オプション。~/.claude/skills/ に置かれ、どのフォルダで Claude Code を起動しても使えます

ここで1つ注意があります。npx skills は Anthropic の公式ツールではありません（開発元は vercel-labs）。GitHubをそのまま配布元にする仕組みなので、公開リポジトリさえあれば誰でも配布者になれます。

スキルは要するに他人が書いた指示書を自分のAIに読ませる行為なので、入れる前に必ず作者を確認してください。今回の場合は作者名 mattpocock がパスに入っていることが確認材料になります。

なお、ルートAとルートBの併用はしないでください。作者も「どちらか選べ。両方入れると全スキルが二重になる」と書いています。

置き場所は「個人」と「案件」で分ける

スコープ	置き場所	有効範囲
個人（Personal）	`~/.claude/skills/<名前>/SKILL.md`	自分の全プロジェクト
案件（Project）	`.claude/skills/<名前>/SKILL.md`	そのプロジェクトのみ

考え方はシンプルで、どんな仕事にも効く思考の道具は個人側、案件固有の手順は案件側です。名前が衝突した場合は個人側が優先されます。

私は今回あえて個人側に入れました。私のモノレポには自作スキルが73本あり、git管理下に置いています。そこに他人が書いたスキルを混ぜると、どれが自分の判断で、どれが借りものかが1か月後に分からなくなるからです。この置き分け自体が、スキルを増やしていくときの実務的な判断だと思っています。

使い方と消し方

Claude Code のチャットで /grill-me と打つ。あるいは普通に「grill me」と書くだけでも発動します
Plan Mode はオフにする（作者の明示的な指示）
新しい会話で始める。AIに書かせた計画書の上に重ねると、その計画を前提にした問いしか出てきません
1問ずつに戻したければ ~/.claude/CLAUDE.md に1行足す（前述）
やめたくなったら、該当のフォルダを削除するだけ。セッション内で即座に反映されます

実際に事業の構想に使ってみた｜1ラウンドで打ち切った記録

ここからが本題です。私はスキルを自作して運用している側の人間で、モノレポには自作スキルが73本、共通部品が15枚あります。一方で外部の他人が書いたスキルを入れたのは今回が初めてでした（導入前に検索したところ、grill 関連のファイルは0件でした）。

題材はコードではなく、新メニューの構想

題材に選んだのは、社内で温めていた「AIで作ったWebアプリの本番リリース前監査」という新メニューの事業構想です。コードは1行も関係ありません。誰に売るのか、何を成果物にするのか、いつ撤退を判断するのか——完全に事業側の判断です。

状態は正直に書くと、こうでした。

構想メモは159行。未決事項が6件、そのうち一番大きい「位置づけ」の欄には「AI推奨・私が未決」と書かれたまま
「私がレビューして確定する」というタスクが12日間そのまま

止まっている理由は明快で、何から決めればいいのか分からなかったからです。こういう状態こそ grilling の出番だ、と作者も書いています。

曖昧さは待つ理由ではない。むしろ、このセッションが食べるのはその曖昧さだ。すでに正確に仕様を書けるなら、グリルする必要はない。

提示された4つの問い

起動すると、AIはまず構想メモ159行を読み、そのうえで後続のラウンドで必要になる事実を調べに行きました（例の「事実を見つけるのはAIの仕事」条項です）。そして最初のラウンドとして4問が並びました。

位置づけ：既存サービスの新メニューとして出すのか、独立したブランドにするのか
対象を絞るか：固定価格・時間内で終わらせるなら、検査対象は有界である必要がある。技術の種類で絞るのか
合否を出す商品か、現状報告を出す商品か
撤退判断の時計をいつから回すか：撤退ラインは書いてあるが、起点が書かれていない

各問には ➡️ 付きでAI側の推奨回答が必ず添えられます。これは仕様として決まっている形式で、非エンジニアが完走できる理由はここにあります。答えに詰まる問いが来ても「推奨で」と返せば進むので、止まりません。

そして3問目が、私にとって痛いところでした。構想メモの中で言っていることが割れていたのです。ある節では「審査して合否を出す＝自分が関門になる商品」と書き、別の節では「公開までの距離を示す地図を売る商品」と書いていました。これは別の商品です。12日間そこに置かれていたのに、書いた本人が気づいていませんでした。

私が1問も答えないうちに、前提が3つ崩れた

この記事でいちばん伝えたいのはここです。私が1問目に答えるより先に、AIが投げたサブエージェントの調査結果が返ってきて、構想の前提が実測で崩れました。

(1)「今これを始める」という前提

構想メモには「同じ週に立てた3件目の構想であることを踏まえ」と書いてありました。ではその3件はその後どうなったのか。12日後のコミット数を実測すると、1件は公開直前まで進んでいた一方、残り2件は実質的な作業がゼロのまま止まっていました。片方はリポジトリすら作られていない状態です。

つまり「自分が同時に走らせられる本数は1〜2本」という証拠が、すでに手元にあった。書いた当人が見ていなかっただけでした。結果、最初のラウンドには無かった問い——「そもそも3件目を今動かすのか」——が、1問目の上に追加されました。

(2)「SEOで先行できる空白地帯がある」という前提

構想メモは「関連する日本語検索は競合がおらず、既存のSEOの仕組みで先行できる」としていました。自社サイトのSearch Console実測を当ててみると、こうです。

「バイブコーディング非エンジニア」…通算4回表示
「中小企業バイブコーディング」…通算1回表示
「codex セキュリティリスク」…通算6回表示

空白地帯ではなく、需要そのものが極小でした。「競合がいない」を「先行できる」と読んでいましたが、正しくは「誰も探していない」だったわけです。

(3)「既存の集客資産に接続できる」という前提

新メニューなので既存のサービスページの下にぶら下げる想定でした。ところが実測すると、サービス紹介系のページの検索流入はほぼゼロ。一方でサイト全体では直近17日間で14,737クリックあり、それを稼いでいたのは全部記事のクラスタでした。つまり当初の案は、人が来ていない棚に商品を並べることを意味していました。

そして打ち切った

ここまで来たところで、私はセッションを打ち切りました。1問も回答していません。完走もしていません。それでも、12日間動かなかった構想について、前提が3つ更新され、商品定義の矛盾が1つ表に出ました。

この体験から言えることを3つ書きます。

「AIに質問させる」ことの価値の相当部分は、質問そのものではなく、質問を作るためにAIが事実を調べる工程にあった。「壁打ち」という言葉から想像するものとは、効き方が違いました
自分が書いた文書の中の矛盾は、自分には見えない。「関門を売る」と「地図を売る」が別商品であることは、12日間そこにあったのに誰も気づきませんでした
12日前に決めたことは、もう古い。事業構想は書いた瞬間から現実とズレ始めますが、ズレたことを誰も報告してくれません。実測を取りに行かせて初めて分かります

事業側でどう使われているか

私だけの用途ではありません。日本語圏でも、コードを書かない人がすでに転用しています。

顧客ヒアリングに転用：AIに質問攻めさせながらヒアリング設計を固める。「議事録をとって後で作業するより、はるかにいいものが作れる」（2026年6月18日の投稿）
要件定義の前工程：税理士の方が「容赦なく問い詰めてくれるので、要件定義が固まってから最高モデルでぶん回す」（2026年7月14日の投稿）
商品設計・商談ロープレ：「見えなかった部分も見えてきて、どんどん形になります」（2026年8月10日の投稿）
ビジネス職にこそ：「Bizサイドにも最も必要なスキルも、grill-meなんじゃないか」（2026年7月23日の投稿）

作者自身も、コード以外の用途として講座の設計、家のトイレの修理（「配管工を呼べと説得された」）を挙げています。ある利用者は母親の弔辞を書くのに使ったそうです。

非エンジニアでも答えられる問いが来る、という証拠

「専門的な質問が来たら答えられないのでは」と心配される方が多いのですが、実際の質問はかなり日常語です。日本語の実例では、Gmailの内容をLINEに転送する仕組みを作ろうとした人に対して、AIはこう聞いています。

「転送対象は特定の送信元だけに絞りますか？」
「同じメールを重複送信しないよう、処理済みの目印をつけますか？」

これは技術的には「冪等性を担保するか」という論点ですが、そうは聞いてきません。動作で聞いてきます。だから答えられます。

ブログ執筆に使った人には「体験エピソードはAIの創作ですか、実体験ですか」という問いが飛んだそうです。書き手の誠実性を問い詰めてくる、という点で示唆的な例だと思います。

質問攻めを、そのままヒアリングシートにできる

同じスキル集には、事業側で効く関連スキルもあります。

to-questionnaire：自分だけでは答えられない決定を、答えられる人向けの質問票に変換する。AIの質問攻めを、そのままクライアントへのヒアリングシートにできます
grill-with-docs：質問攻めをしながら用語集と決定記録を同時に作る。ヒアリングしながら議事録と用語集が出来上がる形です

向いていない場面と、失敗の仕方

良いことばかり書いても実務では役に立たないので、批判と限界も並べます。評価はおおむね「効くが、疲れる」で一本化していて、「効かない」という批判はほとんど見当たりません。これ自体が道具としての評価だと思います。

最大の失敗モードは「受動性」

作者が挙げる最大の失敗モードは、質問の多さではなく、あなたが全部うなずいてしまうことです。

失敗モードは受動性だ。40問に「賛成、賛成、賛成」と答えて、エージェントが書きあなたがうなずいただけの計画を持って出てくる。長かったから生産的に感じる。だが実際には何も決まっておらず、その成果物は身に覚えのない確信を帯びている。

裏返しの判定基準も、作者はきれいに言い切っています。

あなたが何かに反対する。あなたからの押し返しが一度もなかったセッションは、そもそも必要のなかったセッションだ。

推奨回答が必ず付くのは完走のための設計ですが、「推奨で」と答え続けたセッションには価値がありません。ここは非エンジニアほど陥りやすい落とし穴です。

単純に、量が多い

批判で最も多いのは量です。「26ラウンド、118問まで来た。止めてくれ」（2026年8月27日の投稿）、「4ファイルの機能に200問投げてきた」（2026年6月3日の投稿）といった声があります。日本語でも「メリット：共通認識が揃うまで質問し続けてくれる／デメリット：疲れる」というまとめが的確です。

作者の回答はこうです。

200問を聞かれてうんざりしている人へ。主導権を握っているのはあなただということを思い出してほしい。質問は、より多くの情報を渡すためのきっかけとして使えばいい。これは試験ではなく、会話だ。

実務的な対処としては、200問来たらスコープが大きすぎると考えるのが正解です。まず作業を小さく分解させてから、それぞれをグリルする。私の場合も、構想全体を1セッションで扱おうとした時点で、スコープはかなり大きい部類でした。

精神的にこたえることがある

日本語圏で最も生々しかった感想を、そのまま紹介します。「Claudeに grill-me と頼んだら僕の計画が全て消えた。全部だめだったんだって思った」（2026年8月27日の投稿）。

これは道具の欠陥ではなく、効きすぎたときに起きることです。事前に知っておくだけでもだいぶ違います。潰されたのは計画であって、あなたではありません。

作者が挙げる「使うべきでない場面」

会話では決着しない問い：「このUIはどう感じられるべきか」のように、見ないと答えられないものは prototype で作ってから戻る
スコープが大きすぎる：モデルには判断が鈍る領域（作者いわく約15万トークン）があり、そこに入る前に分解する
安いモデルでグリルする：「グリリングはモデル自身の『システムがどう壊れるか』の感覚に寄りかかるので、最良のモデルを与えること」
グリルした後にコンテキストを捨てる：設計判断で満たされた会話そのものが成果物なので、捨てると意味がない

作者自身が認めている粗さ

誠実だと思ったのは、作者が未修正の弱点を公表している点です。

正直な限界：フロンティアはエージェントの判断であって、計算されたグラフではない。2つの問いを同じラウンドに入れてしまい、片方の答えがもう片方を変えるべきだったと後から気づくことがある。

実際、日本語圏でも「Claudeが勝手にユーザーの回答を推測して次に進む現象が多発中」という報告があります（2026年7月20日の投稿）。勝手に進み始めたら止める——これは使う側が持つべき態度です。

また、grilling はあくまで「あなたの計画をAIが問い詰める」スキルであって、AI自身の計画をAI自身が掘り下げる自問自答ではありません。負荷も判断責任も、常にあなたの側に残ります。そこは変わりません。

まとめ｜非エンジニアが今日から使うなら

最後に、実務に落とす形で整理します。

入れる：claude plugins install mattpocock-skills でまとめて入れる。個別に入れるなら grilling と grill-me の2本とも（片方だけでは動きません）
題材を選ぶ：コードではなく、「決めたいのに決まっていない事業の判断」を持ち込む。曖昧なほど向いています。ただし一度に扱うのは1テーマまで
始め方：新しい会話で、Plan Mode をオフにして /grill-me。質問が多すぎると感じたら ~/.claude/CLAUDE.md に When grilling, ask one question at a time. を1行足す
やってはいけないこと：全部の推奨回答にうなずくこと。一度も反対しなかったセッションは、やる意味がなかったセッションです
成果物の扱い：グリルし終わった会話そのものが資産です。捨てずに、そのまま次の作業へつなげてください