止めすぎない統制のつくり方
シリーズ「AIが作る時代のセキュア設計」第3回
前回までのお話
このシリーズでは、AI が自発的にしてくれるセキュリティ上の注意は揺らぐこと（第1回1）、だから組織の設定で AI の機能を禁止すれば、その機能を使った社外への持ち出し（越境）を個人の注意に頼らず止められること（第2回2）を確かめてきました。ただし、禁止の規則が見ているのは「どの機能か」であって「中身が問題かどうか」ではない。だから機能ごと止めれば、越境と一緒に、非エンジニアがようやく手にした「自分で業務を良くする力」まで巻き添えで消えてしまう。この限界を前に、前回は「AI を安全な囲いの中で走らせる」という別の道にも触れつつ、「禁止で縛る発想とは違うやり方を、考えてみたいと思います」と書いて締めました。その違うやり方について、示したいと考えています。
つまり、危ない中身のときだけ止めて、問題ない使い方はそのまま通す。 今回はそれが実際にどこまで担保できるかを確かめていきます。
発想の転換：機能ではなく「中身」に線を引く
前回までの規則は、いわば「ハサミを取り上げる」やり方でした。危ない使い方ができる道具は、道具ごと使わせない。シンプルで確実ですが、安全に紙を切ることができる人も困ります。
今回の仕掛けは違います。AI が何かを実行する直前に割り込んで、その中身を検査する「検問」を差し込みます。 道具は取り上げない。使う瞬間に、何をしようとしているかを見て、危ないときだけ止める。
この検問を差し込む仕組みは、本シリーズの検証で使っている開発ツール Claude Code（Anthropic 社）では「フック」と呼ばれ、標準で用意されています3。検査の中身は組織が自由に書けます。つまり「何を危ないとみなすか」の線引きを、機能単位ではなく、組織の実情に合わせて中身単位で引けるということです。
検問をつくる：中身は小さなスクリプト
検問の実体は、小さなスクリプトです。今回作ったものは、やることが3つだけ。
- 公開されようとしているファイルの場所を受け取る
- 中身を読み、個人情報らしきパターン（メールアドレス・電話番号・マイナンバーを想定した12桁の数字）を探す
- 見つかれば「止めろ」と理由を返し、見つからなければ黙って通す
Python で30行ほどの、ごく普通のスクリプトです（ファイル名は pii_guard.py。PII は個人情報を指す英語の略です）。判定の中核はこれだけです。
if re.search(r'[\w.+-]+@[\w-]+\.[\w.-]+', text): hits.append('メールアドレス') if re.search(r'\b0\d{1,4}-\d{1,4}-\d{4}\b', text): hits.append('電話番号') if re.search(r'\b\d{12}\b', text): hits.append('12桁の番号（マイナンバー等）')
これを Claude Code の設定ファイル（settings.json）に登録します。意味は「成果物を外部公開する Artifacts 機能（AI が作った資料を Web ページとして社外に出せる機能。設定で指定するときのツール名は Artifact）が実行される直前に、このスクリプトを通せ」です。検査するファイルの場所は、フックの仕組みがスクリプトに渡してくれます†3。
※同じ脚注を再び参照する箇所は、†3 のように示して参照先へ直接リンクしています。
{ "hooks": { "PreToolUse": [ { "matcher": "Artifact", "hooks": [ { "type": "command", "command": "python3 pii_guard.py" } ] } ] } }
判定の返し方は「止める（deny）」だけではありません。「人に確認を求める（ask）」も返せるので、明確に危ないものは止め、グレーなものは人の目に回す、という三段構え（止める/確認/通す）も組めます†3。
実際に止まるところ
この検問を有効にして試しました。数字とグラフだけの営業ダッシュボードは通り、メールアドレスと電話番号を含む顧客リストは止まります。その顧客リストを AI に「Web ページとして公開して」と実際に頼むと、公開の直前で止まり、こう表示されました。
公開しようとしているページに個人情報らしき記載（メールアドレス・電話番号）が含まれています。社外公開はブロックしました。
公開は実行されず、外部には何も出ていません。前回は公開機能を丸ごと禁止したので、ダッシュボードの共有も道連れで止まりました。今回は中身しだいで、止める/通すが分かれます。前回の限界だった「巻き添え」の範囲が、「機能まるごと」から「検出パターンに引っかかったページだけ」に狭まります。
組織が配って、個人は外せない
前回と同じく、この検問も個人の善意頼みでは意味がありません。組織として配る手順も用意されています。やることは2つです。
- 検問（フック）一式をプラグイン（Claude Code の配布パッケージ）にまとめる
- 管理者だけが書ける設定ファイル（managed settings）に、社内の配布元とそのプラグインを登録する
1つ目のプラグイン化では、検問の定義を settings.json からプラグイン内の設定ファイル（hooks/hooks.json）に移します。さきほどの例との違いはスクリプトの場所だけです。配られた先ではプラグインの置き場所が人によって違うため、それを指す変数 ${CLAUDE_PLUGIN_ROOT} を付けて書きます。
{ "hooks": { "PreToolUse": [ { "matcher": "Artifact", "hooks": [ { "type": "command", "command": "python3 \"${CLAUDE_PLUGIN_ROOT}\"/scripts/pii_guard.py" } ] } ] } }
2つ目の managed settings は、組織契約（Claude for Teams / Enterprise）で使える仕組みで、設定ファイルを全員の端末に配って回る必要はありません。管理者が claude.ai の管理画面（Admin Settings > Claude Code > Managed settings）に書けば、組織のアカウントでログインしている各利用者の Claude Code が起動時に受け取ります。端末を MDM で管理している組織なら、同じ内容を端末側の設定ファイル（managed-settings.json）として配る方式も選べます†4。書く内容はこうです。
{ "extraKnownMarketplaces": { "company": { "source": "社内の配布元" } }, "enabledPlugins": { "pii-guard@company": true }, "allowManagedHooksOnly": true }
ここに登録されたプラグインは全員に強制的に配られ、利用者は無効化も変更もできません4。最後の allowManagedHooksOnly は「管理者由来の検問だけを動かし、利用者が自分で足した・外した検問は無効にする」指定です †3。
これで「うちの部署だけ検問なし」は作れなくなります。前回の機能禁止と同じ強制力のまま、判定だけが「機能単位」から「中身単位」に細かくなった、ということです。
検問の限界：「危ない」の見分けは完璧にならない
ただ、この検問は万能ではありません。「危ない中身かどうか」の見分けそのものが、完璧にならないからです。
今回の検問は、メールアドレスや電話番号の「形」を手がかりに検出しています。すると、二つの失敗が構造的に起こります。
- 見逃し：形が手がかりに合わない個人情報はすり抜けます。たとえば氏名と住所だけが並んだ名簿は、この検問では止まりません
- 誤検出：逆に、12桁の注文番号はマイナンバーと区別できません。今回の判定式は桁数しか見ていないので、問題ない業務ページも止めてしまいます
では、パターン照合をやめて、判定そのものを AI にやらせたらどうでしょうか。「このページ、個人情報の観点で公開してよいか」を、形ではなく意味で判断させます。これも試しました。連絡先を含まない、氏名と役職だけの体制表（パターン照合では判定できない境界例）を、同じ指示で5回判定させた結果です。
| 判定 | 回数 | 理由の例 |
|---|---|---|
| 止める | 4回 | 「実名と役職の紐付けは個人の特定につながる」 |
| 通す | 1回 | 「責任者情報は公式情報として公開が許容される範囲」 |
意味を捉えられる分、賢くはなります。4回はもっともな理由で止めました。ところが、同じ内容・同じ指示でも、判定は割れました。使った指示は「あなたは社外公開前の検問係です。以下のページ内容を社外の Web に公開してよいか、個人情報保護の観点だけで判定してください」という簡素なものです（全文は文末の限定事項に）。このような簡易な文章で、AI の判定は揺らぐことがあります。第1回で見た「AI は揺らぐ」が、今度は検問の中でも起こりえます。
さらにもう一つ、検問は置いた門しか守れません。今回検問を置いたのは、外部公開（Artifacts）の経路だけです。第2回で挙げたコマンド実行や外部連携のように、外へ出す手段になり得る機能はほかにもあり、守るならそれぞれの経路に検問を置いて回ることになります。
パターンは形しか見えず、AI は意味を見るが揺らぐ。検出を増やせば誤検出と保守が重くなり、検問を置くべき経路も、世の中の「危ないデータ」の形も変わり続ける。「何が危ないか」の見分けは、どう作っても完璧にならない。終わりのないいたちごっこです。前回の限界（粗すぎて巻き添えにする）は大きく縮んだ代わりに、「何が危ないか」をブラッシュアップし続ける消耗戦が残ります。
判定をやめる、という道
ここまでで分かったことは3つです。
- 機能ごと禁止する統制は、確実だが巻き添えが大きい（第2回）
- 中身を見る検問なら、危ないものだけ止めて、正しい使い方を通せる。組織が配って個人は外せない
- ただし「危ない」の見分けは完璧にならず、ブラッシュアップし続ける消耗戦が残る
統制は、ここまで柔軟にできます。現場の改善力を守りながら効かせる組み方は、現実にあります。それでもまだ、「危ないかどうかをその都度判定する」という前提だけは変わっていません。
判定し続けるのではなく、そもそも何をやっても安全な場所を用意して、その中では思いきり自由にやらせる がよさそうです。第2回の終わりに触れた「囲い」の話です。今回の検問が「門」に立って中身を見張るものだとすれば、囲いは「壁」です。壁の中なら、危ないことが起きても外に影響が出ないので、危ないかどうかの判定そのものが要らなくなります。次回は、この囲いの具体的な方法について検討を進めて行きたいと考えています。
筆者の関心として
統制を「価値を阻害する縛り」ではなく「価値を守るための調整」として組めるようになると、現場の面白い動きを止めずに済みます。私自身、この調整の入れ方（どこに検問を置き、どこを素通しにするか）こそが、AI 時代のセキュリティ設計のいちばん面白いところだと感じています。引き続き、手を動かしながら確かめていきます。
この検証の限定事項
- 「顧客リストの公開が直前で止まる」ことは、実際の公開操作で確認しました（公開は実行されず、外部には出ていません）。ダッシュボードが「通る」側は、検問単体に公開時と同じ情報を渡して判定を確認したものです（実際に公開すると外部に出るため）。組織による強制配布（個人が外せない）は、実機ではなく公式ドキュメントの記載に基づいています†3†4。この強制は、組織契約（Claude for Teams / Enterprise）の組織アカウントで利用していることが前提です。また公式ドキュメントは、これがクライアント側の制御であって、端末そのものを組織が管理していない場合は回避の余地が残ること（より強くするには MDM 等による端末側での配布を使うこと）も明記しています。
- AI に判定させる検証は、同一の内容・指示を毎回まっさらな AI（Claude Haiku 4.5、2026年7月）に与えて5回試行したものです。指示の全文は「あなたは社外公開前の検問係です。以下のページ内容を社外の Web に公開してよいか、個人情報保護の観点だけで判定してください。（体制表を提示）理由を1〜2文で述べ、最終行に『判定: 止める』または『判定: 通す』とだけ書いてください」。傾向を見る規模で、統計的な主張ではありません。なお、判定を先に書かせる形式の指示では、同じ体制表で判定が「止める」側に安定することも確認しており、判定の出方は指示の書き方にも左右されます。
- 今回の検出パターンは記事用の最小実装（メールアドレス・電話番号・12桁の数字）です。実運用での網羅性を示すものではありません。
- 検問の仕組みや呼び名は製品ごとに異なります。ここでの例は Claude Code のものです。
- 第1回「AIは揺らぐ」 https://blog.linkode.co.jp/entry/2026/07/15/155453↩
- 第2回「AIは止められる、けれど」 https://blog.linkode.co.jp/entry/2026/07/27/152331↩
- Claude Code のフック（hooks）。ツール実行の直前（PreToolUse）などの時点で任意の検査処理を差し込み、実行の許可・拒否・確認を判定できる。拒否時は理由を利用者に表示する。https://code.claude.com/docs/en/hooks↩
-
組織による強制配布の仕組み。管理者専用の設定（managed settings。公式ドキュメントでは server-managed settings）に
extraKnownMarketplaces（配布元）とenabledPlugins（強制有効化するプラグイン）を書くと、そのプラグインは管理者スコープでインストールされ、利用者は無効化・変更できない。allowManagedHooksOnlyを有効にすると、管理者由来（および管理者が有効化したプラグイン同梱）のフックだけが動作し、利用者・プロジェクトが独自に足したフックは無効になる。プラグインに同梱するフックはプラグイン内のhooks/hooks.jsonに定義し、スクリプトの場所は変数${CLAUDE_PLUGIN_ROOT}（プラグインの設置先を指す）で参照する。https://code.claude.com/docs/en/server-managed-settings / https://code.claude.com/docs/en/discover-plugins / https://code.claude.com/docs/en/plugins-reference↩
