Claudeに聞く前に、会社の番人が先に読む。Anthropicが推論フックを正式提供、Enterpriseの安全設定は一括点検へ

まず初めに

会社のAI利用で一番困るのは、社員がうっかり機密を貼り付ける瞬間である。止めるなら、生成が始まってからでは遅い。今回Anthropicが出した答えは単純で、Claudeが口を開く前に、会社の番人に先に読ませる。AIの賢さ競争の横で、「止める仕組み」の競争が始まったということだ。

※個人の感想です

推論フック——生成の前に、自社の道具で確認する

推論フックは、Claudeを組織が既に使っているデータセキュリティツールへ接続する仕組みです。目的は、データ損失防止（DLP）をはじめとする自社のポリシーを、従業員がClaudeを使う場面にも適用することにあります。

フックは2種類あり、どちらも正式提供（generally available）になりました。

• プロンプトフック: 対応するClaude製品から送られるプロンプトを、自社のセキュリティツールへ送って確認する
• 事前ツールコールフック（pre-tool-call hooks）: 対応するClaude製品でツールが実行される前に、そのツールコールを確認する

Anthropicは「チームは既に書いたポリシーを保持したまま、それをClaudeに適用できる」と説明しています。つまり、メールやクラウド向けに整えたDLPのルールを、AI向けに書き直さなくてよい、という売りです。管理はOrganization設定の中で、セキュリティセンターとあわせて行います。

セキュリティセンター——推奨設定との「答え合わせ」

セキュリティセンターはOrganization設定内の新しいページで、ベータ提供です。チャット、Cowork、Claude Codeの設定を、設定項目ごとに歩き回らず1ページで確認できます。各コントロールについて、現在の値と（推奨がある場合は）推奨値、変更先へのリンクが並び、新規または最近変更された設定も示されます。ページを開くたびに構成を確認するため、自動チェック対象のコントロールは現在の設定を反映します。コンプライアンスAPIを持つ組織は、同じ結果をAPI経由でも読めます。

管理者同士でセキュリティレビューを進めるための「attestations（証明）」の共有ワークスペースも用意され、各コントロールの現状の記録、リスクの受容、課題のフラグ付けを1か所で行えます。ページは監査人や関係者へ渡すレポートとしてダウンロードでき、自動で確認された項目と、オーナーが確認した項目が区別して印されます。

ただしAnthropic自身が明記するとおり、これは同社の推奨に基づくガイダンスであり、いかなる法律や標準への準拠の認証や保証ではありません。「推奨どおり＝法的に安全」ではない点は、導入側が誤解しやすいところです。

統合管理とアクセス制御——親組織のコンソールと、追い出す手段

統合管理（centralized management）もベータです。会社全体を表す親組織が、admin.claude.comに専用の管理コンソールを持ち、シングルサインオン、ディレクトリ同期（SCIM）、ドメイン確認、グループ、コンプライアンスAPIキーを、配下の組織ごとにではなく一度だけ設定できます。買収した会社の既存のIDプロバイダーを残すなど、複数のIDプロバイダーをそれぞれのSSO・SCIM設定付きで接続することもできます。

線引きも明記されています。各組織は自前のメンバー、ロール、設定、組織レベルのセキュリティ管理（IP許可リスト、テナント制限、セッション時間など）を保持し、親組織のロールは既定では組織内へのアクセスを与えません。一方で、親側で作ったコンプライアンスAPIキーは組織を横断してデータを読めます。なお、この統合管理のセットアップは取り消せないため、始める前に親組織の管理者を特定しておくよう求められています。

アクセス制御側の新機能（いずれもベータ）では、Admin APIの1回の呼び出しでメンバーをClaudeからサインアウトさせることができます。そのメンバーのセッションは全てのブラウザと端末で終わり、Claude Codeのようなアプリは再サインインが必要になります。ただしAPIキー、既に動いているクラウドセッション、予定されたルーティンは終わらず、メンバーはその後に再びサインインできます。「即時に全てを止める」手段ではない点に注意が必要です。

このほか、IP許可リストをAnthropic経由でなく管理者自身が設定・管理できるようになり、管理対象コンピューター上のClaude Desktopで個人用や外部のアカウントをブロックしてシャドーITしゃどーあいてぃーを防ぐ設定、ワークスペースとして使えるフォルダーの制限も加わりました。

EDR連携——AIの仮想マシンの中まで見に行く

Coworkと統合Claudeがローカルで動くとき、シェルコマンドやコードは利用者のコンピューター上の隔離された仮想マシンの中で実行されます。隔離は端末を守る一方で、セキュリティチームからは中が見えないという不満がありました。今回のEDR連携（ベータ）では、組織のEDRいーでぃーあーるセンサーをその仮想マシンの中で動かし、活動を普段監視しているのと同じコンソールへ報告できます。

対象は利用者のコンピューター上の仮想マシンであり、クラウド上のCoworkセッションは含まれません。センサーは検知モードで動き、活動を報告するだけでブロックはしません。仮想マシンが起動するたびに、ClaudeはEDRベンダーのセンサーパッケージの署名を検証してから導入します。提供形態は、macOSとWindowsでのデバイス管理経由で、Claude TeamとEnterprise、および対応ベンダーのMDM経由で導入するBedrock／Vertex AI／Foundry上のデスクトップアプリが対象とされています。

IT Postの見方

IT Postでは、今回の更新の本質は「AIの利用を禁止するか許可するか」から「生成の前に検査を挟めるか」への移行にあると考えます。プロンプトとツール実行の両方に、自社の既存ポリシーをそのまま差し込める形にしたことで、企業はAI専用の新しい番人を買わずに済みます。特にツールコール側の事前確認は、エージェントがファイルを読んだり外部へ問い合わせたりする前に止められる点で、チャットの検査だけとは重みが違います。

一方で、正式提供は推論フックだけで、点検・統合管理・追い出し手段は軒並みベータです。しかもセキュリティセンターは「推奨との差分」を見せる道具であって、準拠の保証ではない。導入企業がやるべきことは変わらず、差分を見て、どれを受け入れどれを直すかを自分で決めることです。道具が「答え合わせ」までは機械化しても、答案の採点基準を決めるのは人間側、という当たり前が残っています。

今後どうなりそうか

今後の確認点は、ベータ機能群（セキュリティセンター、統合管理、サインアウト、IP許可リストのセルフサービス、EDR連携）がいつ正式提供になるか、推論フックの対象製品や確認の細部の仕様がヘルプセンターでどこまで具体化されるかです。

IT Postでは、新しい公式情報が確認できれば続報として整理します。