大きな画面での利用をおすすめします — アニメーションと操作がより快適になります。
入力

権限

権限は、ツールを動かす harness が実行前に行う検査です。ポリシーは許可、拒否、人による承認要求を選びます。本例の優先順位は deny > ask > allow。ask は待機の開始であり、肯定の返答が来てからツールへ進めます。

エージェントがプロジェクトのメモを読み、ファイルを更新する場面です。通常の読み取りは進め、保護ファイルは読ませず、書き込みは審査を待たせます。読み取った後で確認しても、内容へのアクセスは防げません。

実行前に呼び出しを止める仕組み

モデルはツール名と引数を提案します。harness は要求を受け、実行前にルールを調べます。各ルールは効果、ツール名、対象を持ち、対象は正確なファイル名か、そのツールの全対象を表す * です。

ディスパッチャーは一致した効果を集め、deny、ask、allow の順で探します。画面の行順には依存しません。広い allow と特定ファイルの deny が同時に一致したとき deny が勝つのは効果の優先順位であり、狭いパターンが自動的に勝つからではありません。本例は一致なしも拒否します。

  • deny:ツールを呼ぶ前に阻止を返します。人の返答は求めません。
  • ask:その呼び出しについて返答を求めます。肯定なら続行、拒否なら阻止、未回答なら待機です。
  • allow:承認画面を出さず、ツール呼び出しへ進みます。

これらはポリシーの判断で、結果は executed、blocked、waiting です。allow は呼び出しの試行を認めるだけで、実行済みや成功を証明しません。

Python のディスパッチャーでは run_tool(call) が実行境界です。阻止する分岐はすべてその前で return します。承認アダプターは True、False、None を返し、None は未回答です。本番の非同期アダプターなら要求を保持し、返答後に再開します。待機中に架空のツールエラーをモデルへ送るものではありません。

権限のステップ

初期設定は書き込みルールが ask、模擬返答が approve。メモリ上の notes.txt は draft です。3 件の要求と初期状態は毎回同じです。

ルール効果ツール対象
r1allowRead*
r2denyReadsecrets.txt
r3askWritenotes.txt

1. 通常ファイルを読む。 c1 は Read("readme.txt")。r1 だけが一致し、allow を選んで deny、ask 分岐を通過します。Read が Project notes を返します。実行 1 回、承認要求 0 回で、notes.txt は変わりません。

2. 保護された例のファイルを読む。 c2 は Read("secrets.txt")。r1 と r2 が一致し、deny が選ばれます。Denied by policy を理由に blocked を返し、Read は呼びません。c2 の実行は 0 回、全体もまだ 1 回です。harness はツール結果を作らずに拒否を報告できます。

3. 書き込み要求。 c3 は Write("notes.txt", "reviewed")。r3 が ask を選び、カードに c3 と対象を示します。実行境界の前で待ち、承認要求は 1 回、ツールはまだ 1 回、ファイルは draft です。

4. 承認を受けてから実行。 模擬返答が c3 を承認します。返答のステップではまだファイルは不変で、次に実行行へ進みます。Write が draft を reviewed に変え、全実行回数を 2 にして結果を返します。

台帳は c1 を allow → executed、c2 を deny → blocked、c3 を ask → approve → executed と記録します。要求 3 件、実行 2 回、阻止 1 件。上部は全呼び出しの合計、現在の状態パネルは表示中の呼び出しだけを数えます。

時間・空間計算量

R 個のルールを、固定長のツール名と対象文字列で照合する時間は O(R) です。効果は 3 種だけなので優先順位の解決は O(1)。異なる効果の集合も最大 3 要素で、表示したディスパッチャーの補助空間は O(1) です。入力ルールとツール自身の処理は除きます。

可視化は一致したルール ID とスナップショットも保存します。それは再生履歴の費用で、権限分岐の必須費用ではありません。人の返答時間も計算量とは別です。ポリシーの計算が速くても、要求は無期限に待つことがあります。

境界条件

未回答。 ask と Unanswered を選ぶと、書き込みは waiting、ファイルは draft。実行済みなのは最初の通常読み取りだけです。再生が最終フレームに着いても承認されたことにはなりません。待機と拒否は別の結果です。

書き込みを拒否。 ask と Decline では否定の返答を受け、blocked を返します。保護ファイルの読み取りと書き込みの 2 件が阻止され、実行は通常読み取り 1 回です。

意図より広い自律性。 allow と Decline では承認要求自体がないため、その仮の返答を読みません。Write は実行され、reviewed になります。人に決めてもらうにはポリシーが ask を選ぶ必要があり、返答を設定するだけではプロンプトは生まれません。

deny に肯定の返答。 deny と Approve でも、承認アダプターを呼ぶ前に return します。返答は拒否ルールを上書きせず、draft のままです。

一致なし。 本例は拒否しますが、製品の既定値やモードは異なり得ます。実際の契約を確認してください。ここは正確な名前か * であり、notes.txt は notes.txt.bak に一致しません。

よくある間違い

  • 実行後に検査する。 すでに読み出した情報は blocked を返しても戻せません。呼び出しは権限ガードの後に置きます。
  • 最初の表示行を優先する。 行順と効果の優先順位は別です。allow を先に決めると r1 が保護ファイルを許してしまいます。
  • 承認要求を承認と読む。 要求は判断の開始です。本例の ask は肯定の返答でのみ進みます。
  • 要求数を実行数にする。 3 件とも harness に来ますが、初期設定でツールへ届くのは 2 件です。
  • 許可を成功と混同する。 権限は試行の可否を決め、許可済みでもツールは失敗し得ます。ツール呼び出し でエラーがループへ戻る仕組みを扱います。

モデルの簡略化

決定的な権限ディスパッチャーの説明で、本番の安全実装や正式なセキュリティ訓練の代わりではありません。要求は固定データ、ファイルはブラウザー内のメモリだけです。実資格情報、ファイルシステム書き込み、外部操作、モデル録画はありません。選んだ入力ごとに一致、判断、効果を計算します。

本番にはパスの正規化、権限モード、hooks、記憶または範囲付きの許可、キャンセル、すべての資源アクセス経路の検査も必要です。ある Read を拒否しても、別ツールが同じファイルを開くことまでは防げません。アプリケーション権限と OS サンドボックスは異なる境界を扱います。本例は早い return と 1 つの実行点を見せるため省略します。

参考と次の教材

Claude Code の権限文書 は deny/ask/allow と優先順位を説明し、実エンジンはさらにモードや hooks を持ちます。Agent SDK の承認ガイド は人の返答を扱います。本例の同期戻り値は小さな教材用インターフェースです。

エージェントループ では、モデルが提案してから harness がツールを呼ぶまでの間へ検査を置いてください。タスクシステム は、プロセス再起動後に完了済みの仕事を保つ別の責務を説明します。