本文へスキップ

生成 AI のセキュリティ対策は何から始めるか。Anthropic と OpenAI が重視する2つ

生成 AI のセキュリティ対策は何から始めるか。Anthropic と OpenAI が重視する2つ

執筆者

Rui Onodera CTO

2026年8月、健康診断の結果を扱う会社の社員が、疾患情報を含む約2万人分の個人情報を、個人で使っている生成 AI サービスにアップロードしました。許可していない生成 AI の業務利用でした。

こういったセキュリティインシデントは毎日のように報道されていますし、AI 導入のご相談でも、同じようなケースに対してどういう対策を講じればいいのかと必ず聞かれます。それほどセキュリティに対する意識は高まっています。しかしながら、AI だからといって身構える必要はなく、講じる対策は従来の IT セキュリティと大きく変わりません。

利用を禁止してもインシデントは無くせない

Anthropic のセキュリティ部門の責任者が2026年7月に公開した文書は「ゼロリスクは仕事ではない(Zero risk isn’t the job)」と題され、禁止すれば会社が把握できない形で AI が利用される、と書いています。IPA も2026年1月の「情報セキュリティ10大脅威」で、従業員が個人的に利用している AI サービスを業務に使うこと、そして職場がそれを認識できないことをリスクに挙げました。

これは従来の IT セキュリティと同じで、規則だけでは守れないからこそ、技術的な対策を重ねる多層防御の考え方を取り入れてきました。

AI の通信先制限は Web アクセス制限と同じ

Anthropic と OpenAI が公開している対策を整理すると、ネットワークセキュリティ、ログ管理、権限管理、アカウント管理、構成管理の5つになります。ネットワークセキュリティは両社が特に重視しています。AI の通信先を制限すれば、社員のミスでも外部からの攻撃でも、許可していない外部サービスへの送信をそこで止められます。

通信先を制限する手段にはプロキシを使います。AI の通信をプロキシに通し、接続できる先をそこで決めます。従来の Web アクセス制限と同じ仕組みです。

OpenAI は自社で使う Codex にすでにプロキシを導入していると、2026年5月の公式ブログで公表しています。ECU でも2026年4月から、エンジニアが使う Claude Code に対して接続先を組織的に許可したドメインに制限する設定を強制しています。

AI の操作もログに残す

ログ管理は、Anthropic も OpenAI も欠かせない対策として挙げています。通信先の制限をすり抜けたものを、記録で追えるようにする層です。冒頭のインシデントは、社員の自己申告で発覚しました。記録がなければ、申告がない限り気づけません。

残す記録は、PC の操作ログと同じです。誰が、いつ、どのサービスに何を送り、AI が何をしたか。プロキシのログと AI ツール自身の記録を、既存のログ基盤に集めます。

Claude Code や Codex の記録は OpenTelemetry という共通の形式で書き出すことができ、2026年9月現在は Team プランや Business プランでも使えます。

AI のセキュリティも多層防御が基本

ここまでの通信先の制限とログ管理は、両社が挙げる5つの対策のうちの2つです。残る権限管理、アカウント管理、構成管理も、情報システム部門が端末や SaaS に対して積み上げてきた業務で、対象は増えますがやり方はこれまでの経験がそのまま使えます。1つで全部を防ぐ対策はなく、層を重ねて管理する点も、AI の前から変わりません。

どういう対策から講じればいいかは、すでにあるプロキシやログ基盤、契約しているプランで変わります。ECU では AI 導入のご相談の最初にその現状を伺い、層を整える順番を決めています。

AI だからと身構える必要はありません。守り方は、従来の IT セキュリティと同じです。

出典

SNSでシェア