AIエージェント
セキュリティ

AIエージェントは「素直で騙されやすい天才」

AIコーディングエージェント（Claude Code、Codex、Cursor…）は、ファイルの読み書き、コマンド実行、Git操作、外部通信——ほぼ何でもできる強力な権限を持っています。

従来のコード補完ツールとは根本的に違う。AIエージェント自体は、悪意ある指示を見抜く能力を持っています。でも、実際の開発環境では、正規のユーザー指示なのか、READMEやissueコメントに仕込まれた罠なのか、区別がつきにくい。その結果、悪意ある指示を「ユーザーからの正当な依頼」と誤判定して、そのまま実行してしまうことがあります。

さらに厄介なのが「承認疲れ」の問題です。AIエージェントが操作のたびに確認を求めてくると、人間はだんだん中身を確認せずに承認ボタンを押すようになる。攻撃者にとっては、この心理的な隙こそが狙い目です。

つまり、AI自身の誤判定と、人間側の承認疲れ——この2つが重なることで、強い権限を持ったAIが意図せず攻撃の手先になってしまう。これが、AIエージェント特有のセキュリティリスクの正体です。

攻撃者はAIを経由してくる

従来のセキュリティは「外部からの攻撃を防ぐ」ことが中心でした。ファイアウォール、ウイルス対策、多要素認証。これらは今でも重要です。

でも、AIエージェントの登場で、攻撃の経路が根本的に変わりました。

攻撃者はもう、直接あなたの環境に侵入する必要がありません。リポジトリのREADME、issueのコメント、外部のWebページ——AIが読むコンテンツに罠を仕込むだけで、AIエージェントを経由してあなたの開発環境にアクセスできてしまう。これが「プロンプトインジェクション」と呼ばれる攻撃です。

人間なら「これは怪しい」と無視できるような指示でも、AIは正規の指示と区別できずに従ってしまう可能性がある。しかも、ウイルス対策ソフトはこの種の攻撃を検知できません。AIが実行するのは cat や curl といった正常なコマンドだからです。

「今の対策で大丈夫」は、本当か？

多くの企業が、こんなふうに考えています。

残念ながら、AIエージェントに対しては、これらの対策だけでは不十分です。

.envをgitignoreに入れても、AIはファイルを直接読めます。環境変数に展開しても、AIはそれを取得できます。ウイルス対策ソフトは、AIが実行する正常なコマンドを攻撃と判定できません。

従来の対策が無意味というわけではありません。でも、AIエージェント特有のリスクに対しては、それだけじゃ足りない。ここに気づけるかどうかが、大きな分かれ道になります。

対策	内容	AIエージェントへの有効度
.env + gitignore	Gitリポジトリへの混入を防止	防御不可
dotenv（環境変数展開）	ファイルではなく環境変数で管理	防御不可
git-crypt	ファイルの暗号化	部分的
1Password等	パスワード管理ツール	条件付き
ウイルス対策ソフト	マルウェア検知・ブロック	防御不可

AIエージェント時代に必要な、新しいセキュリティの考え方

じゃあ、どうすればいいのか。AIエージェントを安全に活用するには、3つの原則があります。

どんなに優れた対策でも、単体では突破される可能性がある。だからこそ、セキュリティ対策を何重にも重ねて、一つの層が破られても次の層で食い止められる設計にする。AIの権限制御、ネットワーク分離、操作ログの監視——複数の防御層を組み合わせることで、被害を最小限に抑えます。

APIキーやパスワードなどの機密情報を、AIがアクセスできない場所に置く。そもそも、万が一漏洩しても被害が小さい情報だけがAIの手の届く範囲にある——という状態を作ることが大切です。「漏れても大丈夫な環境」を前提にすることで、リスクの総量そのものを減らせます。

この3つの原則を、自社の環境に合わせてどう実装するか。ここが最も重要なポイントであり、一番難しいところでもあります。

私たちができること

AIエージェントのセキュリティリスクは、まだ多くの企業で認識されていません。「そもそもこんなリスクがあるとは知らなかった」——そう言われることがほとんどです。

私たちは、AIエージェント活用に伴うセキュリティリスクの評価から対策の設計・導入支援まで、一緒に取り組みます。

• 現在のAIエージェント利用状況のセキュリティ評価
• リスクの可視化と優先度付け
• AI環境の隔離設計・権限設計
• セキュリティポリシーの策定支援
• 運用ルール・ガイドラインの整備

「うちは大丈夫かな？」——その疑問を感じた時が、始めるタイミングです。