grill-with-forms

この記事は2026年10月時点の情報に基づきます。Claude Code 2.1.296のArtifactツールで試しました。Artifactの公開範囲や承認の仕組みが変わると、この記事の手順は当てはまらなくなる可能性があります。

先に結論だけ

grill-with-formsは、Claude Codeからの質問をAskUserQuestionツールで1問ずつ受ける代わりに、1往復分の質問を1ページのフォーム（Claude Artifact）でまとめて受けるスキルです。モデルの進歩で余った能力を、ユーザーとエージェントの共通認識の形成に使います。

ユーザーが一度も矛盾せずに答え続けることはできないので、このスキルでは、回答は矛盾を含む前提で扱います。2往復目からはページの冒頭に図を置き、エージェントが回答をどう読み取ったかを確かめながら、矛盾と新しい論点を回収します。

質問のページは任意の回数（指定しなければ3回）までと決め、終わったら結果を「決定・未決・判断不能」に分けてレポートします。スキルはgistで公開しています。

はじめに

Claude Codeに計画や設計を相談すると、エージェントが質問を重ねて計画の穴を詰めてくれます。この質問攻めを扱うスキルには、mattpocock/skillsのgrill-meをはじめとする先駆者がいます。この記事でもそれにならい、質問攻めをグリルと呼びます。

Claude Codeには、ユーザーに質問するためのAskUserQuestionツールがあります。このツールは、少数の質問を順番に出す作りです。この形式には、質問どうしの関係を見渡せないという弱点があります。2問目を読んではじめて1問目の意味がわかり、答え直したくなったことはないでしょうか。

grill-meは、1往復分の質問をまとめてチャットに書きます。私は、1往復分の質問をチャットではなく1ページのフォームで受けるスキルを作りました。質問と回答が並ぶので、全体を見渡せます。この記事では、スキルの進め方を紹介します。

• どんなときにフォームへ切り替えるか
• 矛盾した回答をどう扱うか
• 図で読み取りをどう確かめるか
• 何往復で打ち切り、どう終えるか

対象の読者は、Claude Codeでスキルを使っていて、エージェントとの質問のやりとりを改善したい方です。フォームの部品（ボタンやスライダー）の作り方は、この記事では扱いません。gistのpage-rules.mdとtemplate.htmlを見てください。

使い方

gistのファイルのうち、README.mdとLICENSE以外を~/.claude/skills/grill-with-forms/にコピーします。

コピーしたら、いつもの言葉でエージェントにグリルを頼みます。スキルはエージェントが自分で呼び出してくれます。

このリリース計画について、フォームでグリルしてください。

「フォームで」と頼めば、質問の数によらずフォームになります。単に「グリルしてください」と頼んだ場合は、Claudeが質問の数と関係を見て、フォームにするかどうかを決めます。条件は次の節で説明します。

1往復は次の流れで進みます。

1. エージェントが質問のページを書き、Artifactとして作る
2. ユーザーがページで回答し、最下段のコピーボタンを押す
3. ユーザーがコピーされた1行のJSONをチャットへ貼る
4. エージェントがJSONを読み、矛盾と新しい論点を洗い出す
5. 質問が残っていれば、エージェントが次の往復のページを書く

質問のページの上限は、指定しなければ3回です。上限を変えたいときは、頼むときに回数を伝えます。

このリリース計画について、フォームで5往復のグリルをしてください。

スラッシュコマンドで呼ぶ場合は、/grill-with-forms rounds=5 <題材>のように引数で指定できます。

フォームに切り替える条件

フォームを名指しされなかった場合、Claudeは次の条件で使い分けます。どれかに当たる場合はフォーム、どれにも当たらない場合はAskUserQuestionです。

• 質問が3問以上ある
• 質問が互いに依存している（前の回答で、後の質問の選択肢や意味が変わる）
• 質問が2つ以上の軸の関係を問うている

互いに依存する質問は、数が少なくてもフォームにします。理由は次の節で説明します。

2つ以上の軸の質問は、たとえば「講義寄りか議論寄りか」と「入門向けか発展向けか」を同時に決めるような質問です。軸ごとに分けて答えた結果をあとで組み合わせる場合と、組み合わせた1点を見ながら答える場合とでは、人の考え方が変わります。質問の形式によって答えが変わってしまうので、組み合わせた結果を見せながら答えてもらいます。

矛盾は前提

このスキルは、回答が矛盾を含む前提で組み立てています。

1往復の質問を1ページにまとめるのも、この前提からです。ユーザーは、あとの質問に答えるうちに矛盾に気づき、前の回答を変えたくなります。質問と自分の回答が1ページに並んでいれば、送る前に見直して変えられます。

送ったあとに残った矛盾は、エージェントが拾います。エージェントは回答をまとめて受け取り、次の2点を調べます。

• 回答どうし、または回答とすでにわかっている制約が食い違う箇所はないか
• 回答によって、新しく決めるべきことが生まれていないか

見つかった項目は、次の往復のページで質問になります。質問には「回答どうしの衝突」「回答から生まれた論点」のような種別を表示します。

誤った指摘

エージェントが挙げる矛盾は、エージェントの誤読かもしれません。

たとえば、エージェントが2つの回答を矛盾として挙げても、原因が選択肢の文言のあいまいさにあることがあります。選択肢に主語がなく、ユーザーとエージェントとで読み方が違っていた、という場合です。

このとき、選択肢だけのフォームでは、訂正を伝える手段が補足欄しかありません。エージェントが用意する選択肢は、指摘が正しいという前提で作られます。指摘の前提が違う場合の答えは、選択肢の中に現れません。

そこで、選択式の質問には「その他」と自由入力欄を置きました。矛盾を確認する質問では、「その他」に「この質問の前提が違う場合を含む」と書き添えます。私が使ったときも、「回答どうしの衝突」の質問に、前提の訂正で答えることがありました。

説明の量

質問の説明は、1段落までにとどめます。往復の間に、ユーザーは判断の前提を忘れます。それでも、質問のたびに前提（目的、ここまでの経過、前回の回答）を並べません。情報を厚くしても注意が散るだけで、回答の精度は上がらないからです。

前提を忘れて生じた矛盾は、説明を増やして防ぐのではなく、あとの往復でまとめて回収します。

読み取りの図

2往復目からは、ページの冒頭に図を置きます。図は、前の往復までの回答をエージェントがどう読み取ったかを表します。図を使う着想は、eli5という図示スキルの紹介から得ました。

図の規則は次のとおりです。

• 回答で決まった値は実線と塗りで描く
• エージェントの推測と未定の値は破線で描く
• 決める対象の側面ごとに小さな図を1つずつ描き、1枚にまとめない
• 場面の挿絵ではなく、決めている変数（量、割合、順序、流れ）を帯や箱と矢印で描く
• 図の直下に、読み取りが合っているかを答える質問を置く

破線の箇所は、そのまま次の質問になります。質問の説明は「図の破線の境界をどこに置くか」で足りるので、図と質問の対応を説明する文が短く済みます。

図は、エージェントが見落としていた変数も浮かび上がらせてくれました。流れを描いた図では、ある箱にだけ時間の条件が書いてあり、次の箱へ進む矢印には時間がありませんでした。私は図を見て、次の箱へ進むまでの時間が決まっていないことに気づきました。矢印として描かれていたから気づけた、という感触があります。

差分の表示

3往復目からは、前の往復の図から変わった箇所に色を付けます。コードのdiffと同じ考え方です。

変更	描き方
追加した要素	緑の枠。文字の前に「+」
削除した要素	赤の枠。前の位置に残し、文字の前に「−」
値の置き換え	削除した要素を上、追加した要素を下に並べる
破線から実線への変化	実線の要素を追加、破線の要素を削除として描く

色はVS Codeの既定テーマにならいました。削除した要素を残すのは、直後の往復だけです。変わっていない図には印を付けないので、印が1つもない図は「変更なし」と読めます。

置き換えを同じ位置で上下に並べるのは、図ならではの描き方です。コードのdiffでは削除行と追加行が別々の行になりますが、図なら元の位置に新旧の2つを束ねて「ここが入れ替わった」と示せます。

側面ごとに分けた図は、差分と相性がよいことが後からわかりました。1枚の大きな図に差分を重ねると、要素が多すぎて読めなくなるでしょう。

往復の上限

質問のページは、上限の数までしか作りません。上限は努力目標ではなく、守る規則です。

何度でも答え直しを求めると、ユーザーが疲れます。回数を重ねても回答の精度は上がり続けず、どこかで頭打ちになります。上限があるので、エージェントはその回数で必要な情報を得られるように質問を選びます。

• 1往復の質問は5問までとし、超えた分は次の往復へ回す
• 1往復目は目的と前提を先に聞き出し、細かい選択は後の往復に回す
• 2往復目からは洗い出した項目と持ち越した項目だけを質問し、決まったことは質問し直さない

既定の3という値は、仮に置いた値です。私が使った範囲では3往復で終えていますが、適切な値は題材によって変わるはずです。

決定・未決・判断不能

上限に達するか、質問がなくなったら、すべての項目を3つに分けて終えます。

分類	入れる項目
決定	回答で決まったこと
未決	質問すれば決まる見込みがあるが、上限までに質問しきれなかったこと
判断不能	質問しても決まらなかったこと

未決と判断不能を分けるのは、その後の扱いが違うからです。未決は、仮の値でよいかを確認すれば済みます。判断不能は、質問を重ねても決まりません。成果物や試作を見せるなど、別の手段が要ります。

エージェントが置いた値は「決定」に入れません。上限のために質問できなかった項目は、エージェントが仮に置いた値を添えて「未決」に入れます。

判断不能を残す理由

このスキルは、判断できないこと、理解できないことを無理に決めず、そのまま記録して先へ進みます。すべてを決めきってから作業に入ることは目指しません。grill-meのドキュメントは、話しても決まらない質問に当たったらグリルを止め、試作を見てから戻るよう勧めています¹。このスキルは止まらずに記録し、あとで振り返ります。

この進め方を選んだのは、私がUIのデザインと実装の両方を仕事にしているからです。UIの触り心地は、いくら文章にしても理解が深まりません。多くの要素が絡み合うので、文章で書ききるのが難しいか、そもそもできません。

「判断できない」の理由

図の確認と補足欄を除くすべての質問に、「判断できない」という答えを用意します。ユーザーがこの答えを選んだ質問は、もう一度出さずに判断不能へ入れます。

選ぶときは、理由を一緒に答えてもらいます。

理由	次に要ること
知識や情報が足りない	調べる、説明する
実物や試作を見て決めたい	試作を見せる
自分の権限の範囲外	決められる人へ確認する
その他	理由を確認する

権限の範囲外を選んだ場合は、決められる人の名前かIDも入力します。実際の仕事では、グリルされる人には決める権限がない質問が出てきます。そのときに、無理に答えさせず、誰に聞けばよいかを残すための欄です。

まとめのページ

終了時には、3分類の一覧をチャットに書くのに加えて、結論を1枚にまとめたページを作ります。決定は実線の枠、未決は破線の枠で描きます。

往復の途中の図は側面ごとに分けますが、まとめは1枚にします。差分を重ねる必要がなく、決定・未決・判断不能だけを描けば済むからです。まとめのページは質問がないので、上限には数えません。

回答の渡し方

回答は、ページのコピーボタンと、チャットへのペーストで渡します。ページの最下段に回答を1行のJSONにした文字列を常に表示し、ボタンでクリップボードへコピーします。出力の例を次に示します。

{"form":"oncall-grill","round":2,"fig":"ok","q1":"by-severity","q2":40,"q3":"other","q3Other":"副担当にも応答の許容時間が要る","q4":"cannot-judge","q4Reason":"no-authority","q4Decider":"@tech-lead","note":""}

formとroundは、どのページへの回答かを示します。

Artifactには、ページが書いたデータをClaudeが読む仕組みもありますが、このスキルでは使っていません。ペーストなら、特別な機能を使わないただのHTMLページで済みます。ペーストは「回答が終わった」という合図も兼ねます。

近い考え方の例

grill-with-formsを構成する要素には、すでに近い道具があります。

grill-meとgrilling

grill-meは、1往復ごとに質問をまとめて出します¹。質問の進め方はgrillingというスキルにあり、grill-meはそれを呼び出す入口です。

grillingは、決めることをツリー構造で捉えます。前提がすでに決まっていて、いま質問できる項目を1往復分にまとめて、チャットに書きます。質問にはQ1、Q2と問題番号を振り、それぞれに推奨する答えを添えます。ユーザーが答えると、grillingは次の往復の質問を作り直します。ドキュメントによれば、1問ずつ質問する形にも設定で戻せます。

まとめて質問し、回答を受けて次の質問を作り直す点は、grill-with-formsと同じです。違いは次のとおりです。

項目	grilling	grill-with-forms
互いに依存する質問	同じ往復に入れず、後の往復へ回す	同じページに置き、答えの影響を見せる
上限	質問の数に上限を設けない（意図した設計。長さはユーザーが言葉で調整する）	質問のページの数に上限を置く
質問と確認の手段	チャットの文章と推奨する答え	フォームと図

grillingがチャットの文章で質問するのは、意図した設計です²。作者は理由を2つ挙げています。

1つ目は、どのコーディングエージェントでも動くようにするためです。grillingは、Claude Codeのほかに、CodexやCursorなどでも使われます。質問のためのツールはエージェントごとに違い、持たないものもあります。Claude CodeのAskUserQuestionのように1つのツールを名指しすると、スキルごとにエージェント別の分岐を書くことになります。そうしなければ、1つのエージェントでしか正しく動かないスキルになります。

2つ目は、質問のためのツールを使うと、質問の中身まで変わってしまうためです。選択肢を並べる部品があると、モデルは選択肢から選ばせる質問を作りがちになります。作者は、グリルを、ユーザーが自分の言葉で答える開かれた質問のためのものと考えています。そのため、AskUserQuestionを試したうえで、スキルには入れないと書いています。

grill-with-formsは選択式のフォームを使うので、この弊害を受けます。選択式の質問に必ず置く「その他」と自由入力欄は、これに対する私なりの答えです。この欄は、エージェントが誤った前提で質問を作ったとき、ユーザーが反論を書き込む場所になります。

grillingには、1往復分の質問をHTMLのフォームにまとめる提案も寄せられましたが、同じ判断に当たるとして対象外になっています³。

grill-with-formsの「判断できない」に「実物や試作を見て決めたい」という理由を用意したのは、grill-meのドキュメントが試作を勧めるのと同じ問題への対処です。扱いの違いは、「判断不能を残す理由」の節に書きました。

superpowersのbrainstorming

superpowersのbrainstormingスキルは、会話で質問を重ねて設計を詰めます⁴。

• 各メッセージを1つの質問で終える
• 理解できた部分を約200〜300語で言い直し、質問と交互に続ける
• 推測は推測と示す

grill-with-formsは、この「言い直し」と「推測の明示」を、文章の代わりに図と破線で行っていると言えます。

同じスキルのvisual companionは、モックアップや図をブラウザーで見せる部品です。質問ごとにブラウザーか端末かを選び、要件、概念的な選択、技術的な判断は端末で質問します。回答の中心は端末での発言で、ブラウザーでのクリックの記録はそれを補うものです。

visual companionとgrill-with-formsは、扱う層が違います。visual companionは1問の見せ方を豊かにし、grill-with-formsは往復の単位と進め方を変えます。

そのほかの例

• Plannotatorは、エージェントが再提出した計画の文書について、追加された行と削除された行を示します⁵
• agent-html-skillsは、ページのSubmitの結果を同じセッションへ通知で返し、通知が届かない環境ではJSONをクリップボードへコピーして貼る経路に切り替わります⁶
• claude-html-channelsは、ページの「Send to Claude」で入力が会話へ届き、Claudeがページを更新します⁷
• MCPのelicitationは、サーバーが回答の形をJSON Schemaで渡し、クライアントがそこから入力フォームを作れる仕組みです⁸

render-question-mcpは、elicitationを使って複数の質問を1つのフォームにまとめます。

JSONをコピーして貼る方式は、agent-html-skillsの切り替え先と同じです。自動で返す仕組みのほうが手数は少ないので、ここは今後の改善点かもしれません。

試した範囲と残る懸念

このスキルの評価は、私の主観です。私が使ったのは、スキルの挙動を確かめるための擬似課題だけです。同じ課題を、AskUserQuestionで1問ずつ受けるグリルやgrillingと比べてはいません。次の場合は、まだ試していません。

• 回答者が判断に必要な情報を持たない場合
• 関係者が複数いる場合
• グリル全体の質問が10問を超える場合

使う前に知っておいてほしい点もあります。

• 試した時点ではArtifactとして作ったページは既定で非公開でしたが、質問と選択肢がclaude.ai上に置かれることは変わりません
• 試した環境ではページを作るたびに承認を求められたので、フォームを名指しして少ない質問を受ける場合は、AskUserQuestionより手数が増えるかもしれません

おわりに

モデルが進歩するほど、エージェントの能力には余りが出ます。その余りを何に割り振るかは、エンジニアリングの課題です。このスキルでは、余った能力を、質問のフォームと、回答の読み取りを示す図を作ることに割り振りました。

スキルはgistに置いてあります。試してみて、合わないところがあれば書き換えて使ってください。

1. grillingのSKILL.md。grillingのドキュメント。grill-meのドキュメント。2026年10月13日閲覧。 ↩ ↩²

2. native-question-tool.md。2026年10月13日閲覧。 ↩

3. Proposal: experimental HTML questionnaire mode for batch grilling（issue 1152）。2026年10月2日起票、10月7日クローズ。2026年10月13日閲覧。 ↩

4. brainstormingのSKILL.md。visual-companion.md。2026年10月13日閲覧。 ↩

5. Plan review - Plannotator。2026年10月13日閲覧。 ↩

6. agent-html-skillsのREADME。2026年10月13日閲覧。 ↩

7. claude-html-channelsのREADME。2026年10月13日閲覧。 ↩

8. Elicitation - Model Context Protocol仕様 2026-07-28。2026年10月13日閲覧。 ↩