メインコンテンツまでスキップ

Guide と Sensor のペア（寄り道：/grill-me）

Guides と Sensors で「重要な規範は Guide と Sensor のペアで守る」と述べました。この章は、その典型例を /grill-me を題材に、最後まで具体的に見ます。

題材：質問は平文で書かない​

/grill-me は、実装前に要件の曖昧さを詰問するスキルです。当然、ユーザーへの質問を何度も投げます。ここでこの環境のある規範が効きます。

ユーザーへの質問・確認・選択肢提示は、平文ではなく AskUserQuestion ツールで構造化する。

なぜ平文を避けるのか。「A と B どっちにしますか？」と地の文で書くより、選択肢・推奨・トレードオフを構造化して提示したほうが、根拠で選べるからです。この規範を、Guide と Sensor の両方で守ります。なお AskUserQuestion ツール自体は Claude Code 標準（📦）で、これから見る rule と hook は筆者の自作（🔧）です。

Guide 側：rules/ask-user-question.md​

行動の前に方向づけるのが rules/ask-user-question.md（Inferential Guide）です。「平文で質問するな、専用ツールを使え」と、禁止パターンと正しい挙動を文章で示します。

ask-user-question.md（規範の要旨）
全ての質問・確認・選択肢提示は AskUserQuestion ツールを使う。
禁止: 「どうしますか？ A or B」「〜でよろしいですか？」
     「ここまでOK？」のような平文確認

これは効果的ですが、文章である以上は確率的です。込み入った説明の流れで、つい「この方向で進めていいですか？」と地の文に書いてしまう瞬間があります。Guide だけでは、その 1 回を止めきれません。

Sensor 側：check-plain-question.sh​

そこで、行動の後に取りこぼしを捕まえるのが check-plain-question.sh（Computational Sensor、Stop hook で登場した Stop hook）です。応答が確定する瞬間に、平文質問のパターンを機械的に検出します。

check-plain-question.sh（検出パターンの一部）
EXPLICIT_PATTERNS='どうしますか|...|進めますか|続けますか|...'
CONFIRMATION_PATTERN='(ここまで|これで|この方向で|それで|この内容で|この方針で)?[[:space:]]*(OK|ok|オッケー|おっけー)[[:space:]]*(です|でしょう)?(か)?[?？]|...|合っ(て(る|ます)?|って(る|ます)?|てい(る|ます))[[:space:]]*(か)?[?？]|...'
# 検出したら
echo "対応: 直前の応答を取り消し、AskUserQuestion tool で..." >&2
exit 2

検出すると exit 2 で応答を差し戻し、AskUserQuestion で質問し直させます。文章の規範をすり抜けた 1 回を、機械が決定的に捕まえます。これが十字分類の対角線、つまり Inferential Guide と Computational Sensor のペアの実働です。

第 3 の要素：前提を整える SessionStart hook​

実は、この規範を支える仕掛けはもう 1 つあります。ensure-askuserquestion-loaded.sh（SessionStart hook）です。

Guide と Sensor を揃えても、抜け道が 1 つ残っていました。AskUserQuestion ツールはスキーマが遅延ロードされる仕様のため、未ロードのまま呼ぶとエラーで失敗します。すると「ツールが使えないから」と平文質問へ退避してしまう——規範を守ろうとした結果すり抜ける、という再発が実際に起きました。

そこで、セッション開始時に「先にスキーマをロードせよ」という案内を決定的に注入する hook を足しました。Guide（rule）× Sensor（Stop hook）× 前提整備（SessionStart hook）の三段構えです。規範がすり抜ける経路は文章の読み落としだけではなく、「守る手段が使えない」という構造側にもある。それを塞ぐのも、ハーネスの仕事です。

Sensor は誤検出への配慮も持つ

機械的な検出は、正当な文まで拾う危険があります。そこで check-plain-question.sh には細かい除外が組み込まれています。状況報告（「ビルド OK」）を誤検出しないよう文末の ?／？ を必須にしたり、直前に AskUserQuestion を使っていれば通過させたりします。一方、機械的に判定できない例外（ユーザーが明示指示済みの作業継続など）は、検出時のメッセージに退避手段を案内して逃がします。「うるさすぎる Sensor」は使われなくなるので、誤検出を抑える設計も品質の一部です。

この対が、ハーネスの背骨​

/debug の「対症療法を避けよ × check-suppression.sh」も、/grill-me の「平文質問を避けよ × check-plain-question.sh」も、構造は同じです。

文章で先回りして誘導し（Guide）、すり抜けを機械で捕まえる（Sensor）。

Guides と Sensors で「重要な規範は両構えで守る」と述べたのは、この積み重ねのことです。ペアを 1 つずつ増やすほど、すり抜けの余地は狭まっていきます。

この章のまとめ

要点は次のとおりです。

  • 「質問は構造化する」規範を、Guide（ask-user-question.md）と Sensor（check-plain-question.sh）のペアで守る
  • Guide は行動前に誘導するが確率的で、Sensor が行動後に取りこぼしを決定的に捕まえる
  • 「守る手段が使えない」という構造側の抜け道は、SessionStart hook の前提整備で塞ぐ（三段構え）
  • Sensor は誤検出を抑える除外条件もあわせて設計する
  • この Guide+Sensor のペアこそ、ハーネス全体に共通する背骨

最後に まとめ で、ここまでの旅を振り返り、自分のハーネスを育てる第一歩を示します。