Claude Codeに「解釈確認スキル」を作った ーー Claudeが生成する前に、人が一度立ち止まる仕組み

Claude Code用に「interpretation-check」というSkillを自作した。これは、依頼の解釈が複数通り考えられる場面や、後戻りしにくい生成を伴う場面で、Claudeが本生成に入る前に「この依頼をこう解釈しました」という候補を提示し、ユーザーが選択・修正してから本生成に進む、というワンクッションを挟むための仕組みである。Claude・Claude Code限定で動作するグローバル配置のSkillとして実装済みで、2026年7月時点でテストを終え、実運用の段階に入っている。

なぜ作ったのか

AIとのやり取りは、基本的に「プロンプトを投げる→結果が出てから間違いに気づく」という一発勝負になりがちだ。生成物を見てはじめて「思っていたのと違う」と気づき、プロンプトを書き直して再生成する。この手戻りのコストは、特にコード変更や設計判断が絡む場面では小さくない。

そこで発想したのが、AIが本題の生成に入る前に「この依頼をどう解釈したか」を示す仕組みだった。ユーザーは生成物が出る前の早い段階で「そこは違う」「その解釈もあったか」と軌道修正できる。結果として、プロンプトの精度も上がり、見当違いの生成物を防げるのではないか、という仮説である。

Claude・ChatGPT・Geminiのどれでも使える貼り付け型ツールではなく、Claude・Claude Code限定のSkillとして実装する方針を選んだ。理由は、普段の主な作業環境がClaude Codeであり、そこに根付かせたほうが実際に使われる可能性が高いという判断である。

何を解決するのか（発動判定のロジック）

このSkillの最大の設計課題は、「毎回発動する」のと「必要な時だけ発動する」の境界線をどこに引くかだった。毎回確認を挟んでいては、ワンクッション減らすという設計目的そのものと矛盾する。

そこで、次の3つの問いをすべて満たした場合にのみ発動する、というルールにした。

1. 解釈が実際に2通り以上に分岐しうるか（語感だけの曖昧さは対象外）

2. どの解釈を選ぶかで、生成物や実装が表面的でなく実質的に変わるか

3. 選択を誤った場合のやり直しコストが高いか（数行の修正やすぐ言い直せる程度は対象外）

判断に迷うときの目安はシンプルで、「もしここで解釈を外したら、ユーザーはどれくらいの手戻りを強いられるか」を考える。手戻りが数秒の言い直しで済むなら発動しない。

付随ルールとして、以下の2点も組み込んだ。

• ユーザーが「解釈を確認してから進めて」と明示的に求めた場合は、3条件の判定を省略して常に発動する

• 発動判断自体は毎回説明せず黙って行うが、後で「なぜ確認しなかったの」と聞かれたら、3条件のうちどれがNoだったかを含めて簡潔に説明する。これはオンデマンドの仕組みであり、常時説明するとワンクッション減らすという設計目的と衝突し、かつトークンの無駄になるためである

テスト結果

サブエージェントによるシミュレーション5件と、同一セッション内での実発動テスト1件、あわせて6件のテストを実施し、全てのケースで想定通りの発動・非発動判定となった。

最後のケースでは、実際にこのSkillを介して「他言語への移植」「GASのまま設計刷新」「機能ごと再構築」という3つの解釈候補が提示され、選択・修正を経て本生成に進むという流れが機能することを確認できた。

副産物として見えてきたこと

このライブテストの過程で、思いがけない気づきがあった。「AIが質問して人が答える」形式ではなく、「AIが自分の解釈を先に示して人に委ねる」形式は、単に誤解を防ぐだけでなく、「Claudeはこう考えているんだ、じゃあどうする?」という人間側の内省を誘発する、という点だ。

これは当初の設計意図(誤解防止・手戻り削減)を超えた効果であり、以下のような展開の可能性を示唆している。

• 開発プロセスを楽しむためのツールとしての利用

• 営業会議前のブレストツールとしての利用

現行版はコード変更・生成物中心の設計になっているため、これらの用途に本格的に展開するなら、別Skillとして切り出すか拡張として検討するのが妥当だろう。現時点では未着手のアイデアに留めている。

設計思想としての一貫性

この仕組みは、単発の思いつきというより、これまで積み重ねてきた設計方針の延長線上にある。

「AIの解釈過程を可視化し、人間が介入できる余地を残す」という考え方は、以前検討していたプロファイル分析ツール（就活自己分析・福祉計画書のたたき台作成等）における「断定的な出力ではなく参考情報に留める」という設計方針と同じ方向を向いている。AIに最終判断を委ねず、人間が途中で軌道修正できる余地を常に残す、という一貫した姿勢だ。

また、APIコストをかけない設計を重視する普段の方針(Claude API不使用、プロンプト生成→貼り付け型)とも矛盾しない。Skillsはclaude.ai/Claude Code側の機能として動作するため、追加のAPI呼び出しコストが発生しない点も、採用の後押しになった。

今後の課題

現時点（2026年7月末）で残っている課題は主に3つ。

1. 実運用での検証がまだ済んでいない。テストケースはすべて想定シナリオであり、日常的なやり取りの中で実際にしっくりくるかはこれから確かめる段階。発動しすぎ・足りなさすぎを感じたら、その場でフィードバックしながらSKILL.mdの判定基準や例を調整していく運用を想定している

2. 境界ケースの追加検証。曖昧さはあるが影響範囲が小さいケース、逆に具体的に見えて実は複数解釈があるケースなど、より際どい例で精度を試す余地が残っている

3. descriptionのトリガー精度の最適化。skill-creatorには自動最適化ループの仕組みがあるが、今回はドラフト作成のみを目的としたため未実施。必要になれば実施できる

まとめ

• Claude Code用に、本生成前に解釈候補を提示する「interpretation-check」Skillを自作した

• 発動条件は「解釈の分岐」「実質的な差」「やり直しコストの高さ」の3条件がすべて揃った場合のみ

• シミュレーション5件+実発動テスト1件、計6件で想定通りの判定を確認

• 副産物として、AIの解釈提示が人間の内省を誘発するという気づきがあり、ブレストツールへの展開可能性も見えてきた

• 「断定を避け、人間の介入余地を残す」という一貫した設計思想の延長線上にある取り組み

実運用での検証はこれからだが、AIとのやり取りにおける「一発勝負」の構造そのものに手を入れる試みとして、しばらく使いながら判定基準を育てていきたい。

#ClaudeCode #Skills #AIワークフロー #プロンプト設計 #解釈確認 #InterpretationCheck