「下書きだけを変更してください」は理にかなった作業指示です。しかし、それはまだ技術的なチェックポイントではありません。hook は、特定のアクションが準備された時点で、繰り返し使うルールを適用できます。これにより、一般的なお願いが、特定のツール呼び出しに関する検証可能な決定に変わります。
その Claude Code リファレンス では、ほかのイベントと並んで PreToolUse が説明されています。これはツールのパラメーターが作成された後、呼び出しが処理される前に発生します。hook は決定を返すことができます。以下の例は私たち自身の草案を説明するものであり、そのために hook の設定をインストールしたり実行したりはしていません。
決定の時点でどのような情報が利用できるのでしょうか
私たちの学習用プロジェクトには、下書きフォルダーと、その隣に参照ファイルがあります。エージェントは下書きだけを編集すべきです。したがって、理にかなったルールは書き込みアクションの具体的な対象を見ます。会話の内容全体が信頼できるかどうかを判断するものではありません。
インターフェースはツール名と入力を提供します。適切なファイルリクエストであれば、そこから対象を特定できます。未知のツールや理解できない入力は、それ専用の状態を引き起こすべきです。チェック用プログラムの暗黙のエラーが、正常にチェックされたパスのように見えてはなりません。
決定は構造化された戻り値です
ドキュメントに記載された PreToolUse の構造における、説明用の拒否の値は次のようになります。理由の文言は私たち独自のもので、ローカルなルールを説明しており、ユーザーに対する一般的な評価ではありません。
{
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "deny",
"permissionDecisionReason": "The target file is outside the drafts area."
}
}この抜粋は戻り値であり、完全なチェック用プログラムではありません。hook の登録も、入力の読み取りとチェックも含まれていません。まさにこの分離が役立ちます。ルール、技術的な評価、インターフェースの出力をそれぞれ独立して検討できるからです。
パスへの所属は、前方一致だけでは判断できません
文字列を単純に比較するだけでは、似た名前の隣接フォルダーを取り違えるおそれがあります。そのため、ご自身のルールでは一意に解決されたパスを扱い、対象が実際に意図したルートフォルダーに属しているかを確認すべきです。使用する環境では、異なる区切り文字やリンクも考慮する必要があります。
own rule logic, schematic:
Input fully readable? Otherwise check status unknown.
Tool belongs to the write path being handled? Otherwise not checked.
Resolve target and permitted root unambiguously.
Target really inside the root? Otherwise deny.
Assess only the specific call being handled.このスケッチは、意図的に完全な保護をうたうものではありません。特に、自らさらに別のファイルを変更する外部プログラムは、単一のファイル項目とは異なる検討が必要です。開始ファイルが許可されていても、スクリプトがどのような後続アクションを実行するかについては、まだ何も分かりません。
四つの試験で適用範囲が見えるようになります
使い捨てのプロジェクトで、許可されたファイル、保護された参照ファイル、そして似た名前の隣接フォルダーを作成します。無効な入力も加えます。それぞれのケースについて、どの決定が期待されるかを事前に書き留めてください。その後、戻り値と実際の実行の両方を確認します。
チェック用プログラム自体の障害もテストしてください。障害時の挙動はイベントと設定によって異なるため、受け入れ確認の一部となります。メッセージが出ないことは、ルールが正常にチェックされた証拠にはなりません。
各試験では、そもそも hook に到達したかどうかも記録してください。別の経路をたどるアクションは、内部のパスチェックが誤って動作したわけではなくても、ルールを迂回してしまうことがあります。
hook は完全な保護の枠組みではありません
PreToolUse はツール呼び出しに関するものです。コンテキストは別の経路からセッションに入り込むことがあり、現行のリファレンスはこの点についての限界を明示的に説明しています。したがって hook は、権限や環境の管理に代わるものではなく、プロンプトインジェクションに対する汎用的な安全策でもありません。
まずは一つのローカルルールから始め、それがカバーする経路とカバーしない経路を文書化してください。技術的な利点は、分かりやすいチェックポイントにあります。このチェックポイントがお使いのバージョンで正しく設定されているかどうかは、適切なインターフェースを用いた実際の試行によって確かめる必要があります。
情報源とドキュメントの確認時点：2026年十月25日。
