はじめに——「攻撃者は応答そのものを読んでいない」
従来のAIセキュリティ対策は、「AIに何を入力させないか」「AIが何を出力するか」に注目してきました。プロンプトインジェクション、データ漏洩、サプライチェーン攻撃——これらはすべて、攻撃者が「AIの入出力の中身」を狙う攻撃です。
しかし2025年後半から、まったく別の系統の攻撃が研究者の間で注目を集めています。それがサイドチャネル攻撃（Side-Channel Attack）、特にLLMに対するタイミング攻撃（Timing Attack）です。
サイドチャネル攻撃とは、システムの「直接の出力」ではなく、応答時間・消費電力・キャッシュ挙動・トークン消費量などの副次的に観測できる情報から、本来秘匿すべき内部状態を逆算する攻撃手法です。CPUやスマートカードの世界では古くから知られていますが、LLMの世界では2025年に入って実証研究が一気に進みました。
具体的には、応答時間のわずかな差から「プロンプトキャッシュにヒットしたかどうか」を判定し、システムプロンプトの内容を1文字ずつ復元する攻撃論文が複数発表され、日本国内の企業実装にも影響が出始めています。
この記事では、AIエージェントに対するタイミング攻撃・サイドチャネル攻撃の手口を整理し、定数時間応答・ノイズ注入・レート制限といった具体的な防御策を、中小企業でも実装できるレベルまで落とし込んで解説します。
サイドチャネル攻撃とは——「漏れている情報」を再考する
従来のセキュリティモデルの盲点
セキュリティ設計では、「機密情報は出力しない」「権限のない操作はさせない」という原則が徹底されています。しかしサイドチャネル攻撃は、この原則の外側にある情報を狙います。
たとえば以下の情報は、AIシステムが「出力していない」つもりでも、実は外部から観測可能です。
- 応答時間：リクエストからレスポンスまでのミリ秒単位の遅延
- トークン消費パターン：input tokens・output tokensの数値
- ストリーミングのチャンク間隔：SSEで送られてくる各チャンクの到着タイミング
- エラーメッセージのタイミング：何ミリ秒目にエラーが返るか
- キャッシュヒット率：プロンプトキャッシュが効いたかどうかの応答時間差
これらは「機密情報」とはみなされず、むしろ運用ログやパフォーマンスメトリクスとして正常に取得できる情報です。攻撃者にとっても、APIを正規に叩くだけで得られるため、不正アクセスを伴わないという特徴があります。
なぜ2026年に問題になるのか
2025年から2026年にかけて、以下の3つの状況が同時に進行しました。
- プロンプトキャッシュ機能の普及：Anthropic（Claude）のPrompt Caching、OpenAIのPrompt Cacheなど、長いシステムプロンプトを再利用してコストを削減する機能が一般化
- ストリーミング応答の標準化：UX向上のため、ほぼすべてのLLM APIがSSEストリーミングをサポート
- AIエージェントの本格運用：単一のLLMコールではなく、複数ツール呼び出し・RAG検索・外部API連携を含む複雑なエージェントが企業に導入され始めた
この3点が揃ったことで、「応答時間や消費トークンの差」が、攻撃者にとって極めて有用な情報チャンネルになりました。
具体的な攻撃手口——5つのカテゴリ
手口1：応答時間からRAGのヒット状況を推定する
RAG（Retrieval-Augmented Generation）を使ったAIシステムでは、ユーザーの質問に対して、まずベクトル検索で関連文書を取得し、その内容をプロンプトに含めてLLMに渡します。
このとき、関連文書がヒットしたかどうかで応答時間が大きく変わります。
- ヒットあり：ベクトル検索 + 文書読み込み + LLM推論 → 応答が遅い
- ヒットなし：ベクトル検索のみ + LLM推論（短いプロンプト）→ 応答が速い
攻撃者は「特定のキーワード」を含む質問を多数送り、応答時間の分布を観察することで、そのRAGが何を知っているかを推測できます。たとえば社内RAGに対して「○○プロジェクトの予算は？」と聞いて応答が遅ければ、「そのプロジェクトに関する文書が存在する」と推定できるわけです。
手口2：プロンプトキャッシュのヒット/ミスからシステムプロンプトを復元する
これが2025年後半から最も注目されている攻撃です。
プロンプトキャッシュ機能は、長いシステムプロンプトの先頭部分が同じであれば、その部分の処理結果を再利用してコストと時間を削減する仕組みです。逆に言えば、キャッシュヒット時とミス時で応答時間が明確に違うことを意味します。
攻撃者は以下のような手順でシステムプロンプトを1文字ずつ復元します。
- システムプロンプトの先頭が「あなたは○○の専門家です」で始まると推測
- 「あなたは○○の専門家です」+ 任意のユーザー入力 をAPIに送信し、応答時間を測定
- キャッシュヒットすれば応答が速い → 推測が正しい
- 1文字ずつ変えて試し、最も応答が速い文字列を採用
- これを繰り返してシステムプロンプト全体を復元
この手法は、CPUのキャッシュタイミング攻撃（Spectre/Meltdown系の研究系譜）と同じ発想であり、LLM版のサイドチャネル攻撃として2025年に学術論文が複数発表されています。
手口3：トークン消費パターンから内部ツール呼び出しを逆算する
AIエージェントは複数のツールを内部で呼び出します。たとえばClaudeのTool UseやOpenAIのFunction Callingを使ったエージェントは、ユーザーの質問に対して以下のような動きをします。
- 「天気を教えて」→ weather APIを呼び出し → 結果をLLMに戻して整形 → 応答
- 「在庫を確認して」→ database query → 結果をLLMに戻して整形 → 応答
このとき、APIレスポンスのusageフィールドに含まれるoutput tokens数や合計トークン数のパターンから、攻撃者は「このエージェントがどんなツールを内部で使ったか」を推定できます。
たとえば、特定の質問でoutput tokensが急増する場合、内部で大量のデータを取得するツール（DB検索、ファイル読み込みなど）が呼ばれた可能性が高い、と推測できるわけです。
手口4：ストリーミング応答のチャンク間隔から思考プロセスを推定する
LLMのストリーミング応答では、トークンが生成されるたびにSSEでチャンクが送られてきます。このチャンクの到着間隔には、以下のような情報が反映されています。
- 長い停止：ツール呼び出し中、外部API待ち
- 規則的な短い間隔：通常のテキスト生成中
- 急な高速化：キャッシュされた定型文の出力中
攻撃者がこのパターンをログとして大量に収集すれば、AIが「いつ思考を止めて外部に問い合わせたか」「定型応答を返したか」が分析可能になります。Reasoning機能（思考プロセスを内部で実行するモード）を持つモデルでは、思考フェーズと出力フェーズの境目もタイミングから検出されます。
手口5：エラーメッセージの種類・タイミングからスタック構成を推測する
エラーが返るまでの時間と、返ってくるエラーの種類・形式は、システム内部の構成を雄弁に物語ります。
- 瞬時に返る400系エラー → ゲートウェイ層でのバリデーションエラー
- 数秒後に返る500系エラー → LLM呼び出し後の処理失敗
- タイムアウト → 外部API呼び出しのハング
- JSON形式のエラー本文 → どのフレームワーク（LangChain、LlamaIndex等）を使っているか
攻撃者はこの情報から、システムのアーキテクチャ・利用ライブラリ・ガードレールの構成を推定し、より精度の高い攻撃ペイロードを組み立てます。
防御設計——5層のサイドチャネル耐性
これらの攻撃に対して、企業はどう防御すべきでしょうか。完全な遮断は難しいものの、観測される情報の精度を下げることで攻撃成功率を大きく下げられます。
防御1：定数時間応答（Response Time Padding）
もっとも基本的な対策は、応答時間を一定にすることです。
具体的な実装パターンは以下の通りです。
- API Gatewayで応答時間の下限を設定（例：すべての応答を最低3秒待たせる）
- キャッシュヒット時もミス時も同じ時間で返す
- RAGヒットあり/なしで応答時間が変わらないようにバッファリング
UXとのトレードオフはありますが、機密性の高いシステム（社内RAG、医療系AIなど）では検討する価値があります。
防御2：ランダムノイズ注入
応答時間にランダムな揺らぎを加えることで、攻撃者の統計的分析を困難にします。
- 応答時間に±200msのランダムジッターを追加
- output tokensの少ない応答にダミーのpadding tokensを混ぜる（ただし内容に影響しない範囲で）
- ストリーミング応答のチャンク間隔をランダム化
ノイズの大きさは、攻撃者が統計的に取り除けない程度に調整する必要があります。一般に、平均的なネットワーク遅延の倍以上のノイズを加えると効果的とされています。
防御3：ストリーミング応答のバッファリング統一
ストリーミングのチャンク間隔から内部状態が漏れる問題に対しては、サーバー側でバッファリングして固定間隔で配信する方式が有効です。
- LLMが生成したトークンを一定量バッファに溜め、固定間隔（例：100ms）でクライアントに送信
- すべてのチャンクサイズを統一する
- ツール呼び出し中の沈黙を、ダミーのkeepaliveチャンクで埋める
これにより、「ツール呼び出し中の長い停止」が観測されなくなります。ストリーミングの「リアルタイム感」は若干失われますが、セキュリティ要件の高いシステムでは妥当な選択です。
防御4：エラーメッセージの一律化
エラーメッセージは、内部実装の手がかりになる情報を一切含めないように設計します。
- すべてのエラーで同じステータスコード（例：500）を返す
- エラー本文は「An error occurred. Please try again.」など定型文に統一
- エラー応答までの時間も一定に保つ
- 詳細なエラー情報は内部ログに残し、ユーザーには返さない
OWASP Top 10 for LLM Applicationsでも、エラーメッセージの情報漏洩は重要な項目として挙げられています。
防御5：レート制限による観測機会の削減
サイドチャネル攻撃は、大量のリクエストを送って統計的に解析することで成立します。したがって、リクエスト数自体を制限すれば、攻撃成功までの時間を大幅に伸ばせます。
- IPアドレス単位、APIキー単位、ユーザー単位での厳格なレート制限
- 応答時間の分散が大きいリクエストパターンを検出するアラート
- 同一クライアントから類似のプロンプトが連続して送られる場合の自動ブロック
- 異常なAPI使用量パターンの監視（例：通常の10倍のリクエストが特定エンドポイントに集中）
レート制限は実装コストが低く、効果も大きいため、最初に着手すべき対策です。
中小企業でも実装できる「最低限のサイドチャネル耐性チェックリスト」
大企業のような専門チームを持たない中小企業でも、最低限の対策として以下を実施することを推奨します。
レベル1：今すぐできる（数時間〜1日）
- □ APIにレート制限を設定（例：1ユーザーあたり毎分60リクエスト）
- □ エラーメッセージを定型文に統一
- □ APIレスポンスから不要なメタ情報（usage、model_name等の詳細）を削除
- □ ヘルスチェックエンドポイントを認証必須化
レベル2：1週間以内に実施
- □ プロンプトキャッシュを使う場合、応答時間にランダムジッター（±200〜500ms）を追加
- □ 応答時間の最低値を設定（例：すべての応答を最低1秒以上にする）
- □ 異常なリクエストパターンを検知するアラート設定
- □ ログから応答時間の分布を可視化し、特異点がないか確認
レベル3：中長期で実施
- □ ストリーミング応答にサーバー側バッファリングを導入
- □ 内部ツール呼び出し時のダミーレスポンス（keepalive）の実装
- □ サイドチャネル攻撃を想定したレッドチーム演習の実施
- □ セキュリティベンダーによる定期的な脆弱性診断の依頼
運用上の注意点——防御策の副作用
サイドチャネル対策は、副作用にも注意が必要です。
UXへの影響
定数時間応答や応答時間の最低値を設定すると、本来高速に返せる応答も意図的に遅延させることになります。これにより、エンドユーザーから「AIが遅い」「使いにくい」というクレームが出る可能性があります。
対策としては、機密性の高いエンドポイント（社内RAG、医療系AI）と、一般向けの公開エンドポイント（チャットボットなど）で、適用する防御レベルを使い分けることが現実的です。
コスト増加
ストリーミングのバッファリングや、ダミーチャンクの送信は、サーバー側の処理コストとネットワーク帯域を増加させます。クラウドコストへの影響を事前にシミュレーションしておく必要があります。
運用の複雑化
レート制限のしきい値、ノイズの大きさ、バッファリングの間隔——これらのパラメータは、システムの利用状況を見ながら継続的にチューニングする必要があります。「設定して終わり」ではなく、運用フェーズでの監視体制が不可欠です。
よくある質問（Q&A）
Q1. プロンプトキャッシュは使わないほうがいい？
いいえ、コスト削減効果が大きいため、無効化する必要はありません。重要なのは、キャッシュを使いつつ応答時間にノイズを加えることです。AnthropicやOpenAIのドキュメントでも、キャッシュ自体は安全な機能として提供されており、副次的なタイミング情報をどう扱うかが利用者側の責任とされています。
Q2. RAGシステムで応答時間を一定にすると、検索精度が落ちる？
応答時間を一定にすることと、検索精度は基本的に独立した問題です。検索処理自体は通常通り実行し、結果を返すタイミングだけを統一すれば、精度には影響しません。ただし、サーバーリソースの効率は若干低下します。
Q3. AIエージェントのusage情報を完全に隠すべき？
用途によります。社内向けの管理画面では、usage情報はコスト管理のために重要です。一方、外部公開APIでは、output tokensの正確な数値を返さず、丸めた値（例：100単位に丸める）を返すなどの対策が考えられます。
Q4. レート制限はどれくらいに設定すべき？
業務用途のチャットボットであれば、1ユーザーあたり毎分30〜60リクエストが目安です。サイドチャネル攻撃は通常、数千〜数万リクエストを必要とするため、この程度の制限でも十分に攻撃を遅延させられます。
Q5. クラウドAPIを使っている場合、自分側で対策できる範囲は限られる？
確かにLLM自体（モデル本体）の挙動は変えられませんが、API Gatewayやアプリケーションサーバーでのラッピングはユーザーがコントロールできるレイヤーです。応答時間のパディング、エラー統一、レート制限はすべてアプリケーション側で実装可能です。
まとめ——「漏れている情報」を減らす設計へ
AIエージェントのセキュリティは、これまで「入力させない・出力させない」という直接的なアプローチが中心でした。しかし2026年に向けて、応答時間・トークン消費・キャッシュ挙動といった副次情報からの情報漏洩が、新たな攻撃面として顕在化しつつあります。
重要なポイントは以下の3点です。
1. サイドチャネル攻撃は「不正アクセス」ではない。 正規のAPI呼び出しだけで成立するため、従来のセキュリティ対策では検知しにくい新種の脅威です。
2. 完全な防御は難しいが、難易度を上げることはできる。 定数時間応答、ノイズ注入、レート制限を組み合わせることで、攻撃成功までのコストを大幅に上昇させられます。
3. 中小企業でも、レート制限とエラーメッセージの統一だけは今すぐ実施すべき。 実装コストが低く、効果が大きいため、AIシステムを運用しているすべての企業の最低ラインとなります。
2026年は、企業のAIエージェント本格運用が広がる年です。同時に、攻撃者側の手法も高度化していきます。「正常に動いているように見えるシステム」が、実は副次情報を漏らしている可能性を、運用責任者は常に意識する必要があります。
参考リンク
- OWASP Top 10 for LLM Applications
- Anthropic Prompt Caching Documentation
- OpenAI Prompt Caching Documentation
- IPA 情報処理推進機構（セキュリティ関連情報）
- 内閣サイバーセキュリティセンター（NISC）
免責事項： 本記事は2026年4月時点の公開情報に基づく一般的な情報提供であり、特定のシステム構成に対するセキュリティアドバイスではありません。実際のシステム設計においては、自社の利用状況・脅威モデル・コンプライアンス要件に応じて、専門のセキュリティエンジニア・コンサルタントへ相談することを推奨します。サイドチャネル攻撃の研究は急速に進展しているため、最新動向は学術論文や各クラウド事業者のセキュリティ情報で確認してください。
コメント