JA EN
shiichan

まさかの「リスクゼロを目指さない」！Anthropic が説くエージェント AI 時代の CISO の新常識

Claude Blog ★★★ Markdown で見る
#anthropic#security#ai

やっほー、しぃちゃんだよ！今日は技術というよりガバナンスの話なんだけど、発想の転換になるいい記事を見つけたから紹介させて！セキュリティの現場から届いた、ちょっとドキッとする内容だったの。

Claude Blog claude.com

なにが発表されたの？

Claude Blog に、Anthropic の Deputy CISO(副 CISO)を務める Jason Clinton さんの寄稿記事「Zero risk isn't the job: a CISO's guide to agentic AI」が公開されたよ。2026 年 7 月 17 日付の記事で、タイトルの通り「エージェント型 AI を導入するとき、セキュリティ責任者はリスクをゼロにすることを目指しちゃいけない」っていう、ちょっと意外な主張から始まるの。

Clinton さんいわく、セキュリティリーダーの本当の仕事はリスクを消し去ることじゃなくて、「エージェントのリスクを可視化して、範囲を区切ること」。そうすれば組織は"こっそり導入(シャドー導入)"に振り回されるんじゃなくて、自分たちで納得したうえで管理可能なリスクを引き受けられるようになるんだって。

なぜ重要なの？

記事では、エージェント AI が抱えるリスクを外部脅威と内部リスクの 2 つに整理してるよ。外部脅威としては、フロンティアモデルが OpenBSD や Firefox のような有名なソフトウェアの脆弱性を、人間のレビュアーが何年も見逃してきたレベルで見つけ出しているという話が紹介されてるの。内部リスクとしては、データ漏えいやプロンプトインジェクションが挙げられてるよ。

こういう状況で公式なガバナンスを待ってると、現場は待ちきれずに勝手にエージェントを使い始めちゃう(シャドー AI)。だからこそ、リスクをちゃんと言葉にして受け入れる仕組みが、AI の進化スピードに追いつくために欠かせないんだよね。

これで何が変わるの？

Clinton さんは、エージェントのユースケースを評価するための「4 つの質問」を提示してるよ。

  • そのエージェントは、攻撃者が書き換えられるような信頼できないコンテンツ(外部メール・公開ウェブ・第三者の文書など)を処理する？
  • 何ができて、誰の権限で動く？(読み取り専用か、読み書きできるか)
  • もし暴走したら、影響範囲はどこまで広がる？(1 ファイルだけか、組織全体か)
  • エージェントの行動はユーザーの行動と区別できる？ SIEM にちゃんと記録される？

さらに、エージェントに持たせる ID のあり方についても、「システムのサービスアカウント(単一目的・最小権限で人と紐づかない)」と「人間の資格情報を使うパーソナルエージェント」という 2 つの極を提示してるの。

"The middle of the spectrum, where an agent carries a person's delegated identity into systems that person is not watching, is where accountability gets ambiguous."

人がちゃんと見ていないシステムに、その人の委任された ID を持ち込んでしまう"中間"のケースが、いちばん責任の所在があいまいになる、ということだね。

深く潜ってみよう

記事では実例も紹介されてるよ。Anthropic 社内では、本番ログへの読み取り専用アクセス・Slack 連携・Google ドキュメント作成ができるインシデント対応エージェントを運用してるんだけど、Claude Opus 4 から Claude Opus 4.5 にアップグレードしたら、エージェントが自律的に別のエージェントへ連絡してコード修正案を作らせ、本番障害の解決を試みたんだって(もちろん人間のレビューが必須な、制御された範囲内でね)。

もうひとつの実例が Claude Cowork。こちらは人間のオペレーターに近い側の運用で、次のようなセキュリティ管理が組み込まれてるよ。

  • ID 連携: SCIM プロビジョニング付きの SAML / OIDC サインイン
  • コネクタの許可リスト: 管理者がデータの境界線を決められる
  • ツール・操作単位の制限: 「外部へのメール送信は禁止」のように細かく制御できる
  • サンドボックス実行: エージェントのロジックは隔離された一時的なサンドボックスで動き、認証情報の注入で持ち出しを防ぐ
  • Egress の許可リスト化: 必須のプロキシで、外向き通信を承認済みの宛先だけに制限
  • OpenTelemetry でのログ送信: すべてのツール呼び出しを、ユーザー ID や文脈つきで SIEM に流す
  • 組織全体のオフスイッチ: ひとつのトグルで全ユーザーのコネクタを無効化できる

これらをまとめて、記事ではエージェントのガバナンスに必要な「7 つの要件」として整理してるの。ID は自社の ID プロバイダーから発行する・コネクタの許可リストでデータ境界を決める・ツールや操作ごとに承認を入れる・サンドボックスで隔離する・Egress を許可リスト化する・テレメトリを SIEM に流す・組織全体のキルスイッチを用意する、の 7 つだよ。

ガバナンス自体がボトルネックになる必要はない、というのも面白いポイント。Anthropic 自身の GRC(ガバナンス・リスク・コンプライアンス)チームも、セキュリティ質問票への回答やベンダーのフラグ確認にエージェントを使ってるんだって。そこから得た教訓は 3 つ。

  • リスク登録簿(risk register)を自動化する: 四半期ごとのレビューじゃ、ドキュメントより速く変化するシステムを統制しきれない
  • 誰がなぜ作ってるかを理解する: エンジニアじゃない人が Claude Code でツールを作れるようになると、シャドー導入が減る
  • 人間の説明責任を組み込む: リスク受容には権限を持つ人の承認が必要で、ISO 42001 のような枠組みと統合するべき

Clinton さんはさらに、「今のモデルの能力」に合わせて統制を設計しちゃダメだとも警告してるよ。

"If you design your new program for what the model can do today, you will be behind by the time your program launches."

だいたい 6 か月先の能力水準を見越して設計しないと、プログラムが立ち上がる頃にはもう時代遅れになっちゃう、ってことだね。モデルの知性が上がるほど、凝った足場や細かいプロンプト調整はどんどん不要になっていくから。

最後に、今日から始められる 3 ステップも紹介されてるよ。

  • いちばんプレッシャーの大きいエージェントのユースケースを、さっきの 4 つの質問にかけて承認条件を洗い出す
  • 自社の ID プロバイダー・SIEM・エージェントのベンダーに、7 つの要件のうちどれを今すぐ示せるか聞いてみる
  • 自分たちの環境で何が「信頼できないコンテンツ」にあたるのかを、きちんと言葉にして書き出す

まとめ

  • Anthropic の副 CISO・Jason Clinton さんが、Claude Blog で「エージェント AI のリスクはゼロにできない」という前提に立ったガバナンス論を公開
  • 評価の軸は「信頼できない入力」「権限」「被害範囲」「可観測性」の 4 つの質問
  • ID の持たせ方はシステムアカウントと人間の資格情報の間のスペクトラムで考える
  • Claude Cowork や社内のインシデント対応エージェントの実例から、ガバナンスに必要な 7 つの要件を整理
  • 6 か月先を見越した設計と、今日からできる 3 ステップも提示

自社でエージェント AI の導入を検討している CISO・セキュリティ担当者はもちろん、ガバナンスの土台を知っておきたいエンジニアにも刺さる記事だよ！

関連記事