DDDefense DeskWordPress 緊急対応
技術資料

アクセスログをAIに読ませて調べるときのプロンプトインジェクション

改ざんの原因を調べようとして、サーバーのアクセスログをそのままAIに貼り付けて要約させることがあります。ところがログに並ぶ項目のうちいくつかは、攻撃者が自分で中身を決めて書き込める欄です。そこにAIへの指示として読める文章が混ざっていると、返ってくる説明がその文章に沿って書き換わることがあります。何が起きるのか、渡すときに避けるべき使い方と確認の進め方がわかります。

公開日 2026.08.06読了目安 7分著者 DD Defense Desk

ログをAIに読ませると何が起きるのか

サイトの改ざんや不審な動きを調べるとき、サーバーのアクセスログを開いて原因を探すことがあります。1日分でも数万行になることがあり、目視で追うには時間がかかります。そのため、ログをそのままAIに貼り付けて「この中で何が起きているか」と尋ねる方法が使われるようになりました。

この方法には、ログという記録の性質からくる弱点があります。アクセスログの各行に並ぶ項目のうち、いくつかはサーバーが自分で書いたものではなく、アクセスしてきた側が送ってきた文字列をそのまま保存したものです。攻撃者は、そうした欄に何を書くかを自分で決められます。どの欄がそれにあたるかは、後の節で分けて示します。

AI側の性質と組み合わさると、この弱点が働きます。AIは、運営者が書いた依頼文と、貼り付けられたログの中身を、区切りのない一続きの文章として読み取ります。どちらが依頼でどちらが調べる対象なのかを見分ける対策は各社が実装していますが、この見分けが常に成功するわけではありません。ログの中に指示として読める文章があれば、それも依頼の一部として扱われることがあります。この手口は「プロンプトインジェクション」(AIに読ませる文章の中へ指示を紛れ込ませ、動作を乗っ取る手口)と呼ばれます。

ログ経由でこれが成立することは、検証として公開されています。2025年9月、セキュリティ企業LevelBlueのSpiderLabsは、ログを読み解かせるAIを用意してこの手口を試した結果(外部サイト)を公表しました。Webサーバーのアクセスログ、SSH(サーバーへ遠隔で接続する仕組み)の認証記録、Windowsのログイン失敗の記録という3種類について、アクセスしてきた側が中身を決められる欄に指示文を仕込んでいます。いずれの場合も、要約に現れた接続元のIPアドレスや端末の名前が、記録されていた値とは違うものへ置き換わりました。仕込まれた文章には、置き換えたことを要約に書かないという内容も含まれており、要約だけを読んでも改変には気づけません。

攻撃の段階

  1. 1

    ログに残る欄へ文章を書き込む

    攻撃者は、自分で中身を決められる欄に、AIへの指示として読める文章を入れてサイトへアクセスします。

  2. 2

    サーバーが記録する

    その文字列はアクセスログの一行として保存されます。構成によって切り詰めや変換は入りますが、指定された文字列の一部は残ります。侵入に成功したかどうかも問いません。

  3. 3

    調査のためにログがAIへ渡る

    運営者が原因を調べようとしてログを貼り付けると、攻撃者が書いた文章も同時に読み込まれます。

  4. 4

    要約と判断が書き換わる

    各社の対策をすり抜けた場合、AIは混ざった文章を指示として扱い、事実と違う要約や、危険な操作の提案を返します。

ログのどの欄が攻撃者の書いたものか

ログのどこまでを信用してよいかは、欄ごとに分かれます。「この行は怪しい」と判断する前に、その行のどの部分を誰が書いたのかを見分ける必要があります。

サーバー自身が書く欄があります。記録された時刻、接続元のIPアドレス、返した応答の種類、転送量です。これらは通信が成立した結果としてサーバー側が付ける値で、アクセスしてきた側が文字列を指定することはできません。ただし接続元のIPアドレスには例外があります。CDNや負荷分散の仕組みを間に挟んでいる構成では、実際の閲覧者のアドレスを別のヘッダーで受け取り、その値をログに書く設定が使われます。この設定を誤ると、アクセスしてきた側が申告した値がそのまま記録されます。自社の構成でどちらが記録されているのかは、サーバー会社に確認してください。

一方、アクセスしてきた側が中身を決める欄があります。閲覧に使われたソフトウェアの名称、アクセス先のパスとその後ろに付くパラメータ、参照元のURLです。ログイン失敗の記録に残る利用者名も、入力した側が決めた文字列です。長さの上限はありますが、そこに何を書くかの制限はほとんどありません。文章を書き込んでおくために攻撃者が行う必要があるのは、サイトへ一度アクセスすることだけです。侵入に成功したかどうかにかかわらず、その文字列はログに残ります。

どの欄が記録され、どの欄が残らないのかは、契約しているサーバーによって変わります。共用のレンタルサーバーでは、送信ボタンを通じて送られた本文が記録されないことが多く、攻撃の中身そのものは追えません。それでも、攻撃者が自由に書ける欄の文字列は残ります。何が残り何が残らないかは、共用サーバーで残らない記録を確認することで整理できます。

対策があっても、自分で貼った内容には効きにくい

AIの側に対策がないわけではありません。各社は2026年時点で、外部から入ってきた文章に紛れた指示を見分けるようモデルを訓練し、検査の仕組みを重ねています。それでもこの場面が問題になるのは、対策の効き方が経路によって違うためです。

AIサービスが自分で取りに行った外部の情報は、モデルへ渡る前に検査を通せます。ところがAnthropicは2026年5月に公表した説明(外部サイト)で、モデル側の対策は利用者の意図を手がかりにしているため、利用者自身が打ち込んだ指示には、分類器が異常として捉える手がかりがないと述べています。ログを自分でコピーして貼り付ける調査は、この後者にあたります。攻撃者の書いた文章が、運営者自身の発言として入っていくためです。

対策は成功率を下げますが、0にはしていません。各社が公表している数値と、記録の整理から操作の実行までのどこに線を引くかは、AIに任せてよい範囲を確認することで整理できます。

ログをAIに渡すときに避けること

AIの利用に伴うリスクは、IPA(情報処理推進機構)が2026年1月に公表した「情報セキュリティ10大脅威 2026」で、組織向けの3位に初めて選ばれました。AIが加工した結果を検証せずに受け取ることが、そこで挙げられている問題の一つです。ログの調査では、次の5つがそれにあたります。

  • ログ全体を渡して丸ごと要約させる:GPT-4o-miniを調査役に置いた2026年5月公開の査読前の検証では、要約を頼んだ場面が最も歪みやすい作業だと報告されています。何を知りたいのかを決めてから渡します。
  • 返ってきた要約だけを読んで判断する:要約に出た値は、元のログの該当行を開いて突き合わせるまで、確定した事実として扱いません。
  • 返ってきた内容のままファイルを消す、遮断する、設定を変える:誤った説明に沿って動くと、正規の利用者を遮断したり、調査に必要な記録を自分で消したりすることがあります。
  • サーバーを操作できる権限をAIに渡す:ログを読ませたうえで対処まで任せる使い方は、混ざった指示がそのまま実行される経路になります。検証では、この使い方で外部から任意の命令を実行できる状態まで到達しています。
  • 中身を確かめずに社外のAIサービスへ貼り付ける:アクセスログには、URLに含まれた入力値や、利用者を識別する文字列が残ります。プラグインが別に出力するログには、問い合わせ内容が残ることもあります。プロンプトインジェクションより先に、社外への情報の持ち出しが問題になる場合があります。

AIを使ってログを見るときの進め方

避けることの裏返しとして、次の順で進めます。ここで「範囲を絞る」を防御として数えていないのは、攻撃者が調査対象になりやすい時間帯を狙って文字列を残せる以上、行数を減らしても仕込みが混ざる可能性は消えないためです。範囲を絞るのは、確認の手間を減らすための手順です。

  • 原本を保全してから始める:ファイル一式とデータベース、取得できるログを別の場所へ複製します。AIに渡すのは、その複製から取った抜粋です。
  • 渡す前に消すものを決める:URLに含まれた入力値と、利用者を識別する文字列を落とします。あわせて、勤務先の利用規程と、契約しているAIサービスの学習利用の設定を確認します。
  • サーバーが書いた欄を先に見る:時刻、応答の種類、転送量は、アクセスしてきた側が文字列を指定できません。接続元のIPアドレスは、転送元のヘッダー由来でないことを確認したうえで、判断の土台に置きます。
  • 答えを検算できる頼み方をする:「この時間帯のアクセスを接続元ごとに件数の多い順に並べてください」のように、元のログを開けば正しさを確かめられる作業を頼みます。
  • 出てきた値を一件ずつ突き合わせる:IPアドレス、時刻、ファイルのパスは、元のログの該当行で確認してから使います。一致しない項目があれば、その回答全体を疑います。
  • 遮断と削除は人が実行する:確認した内容にもとづいて、運営者かサーバー会社が操作します。AIの回答を実行の根拠にしません。

この進め方で分かるのは、いつ、どこへ、どれだけのアクセスがあったかまでです。どこから侵入されたか、どこまで書き換えられたかを決めるには、記録の突き合わせに加えて、サーバー上のファイルの照合が必要になります。AIに読ませて整理する作業と、何が起きたのかを決める作業は別のものです。判断がつかない段階に入ったら、当日中初動で切り分けを依頼することを検討してください。

改ざん検知の通知が届いたときの初動を確認する →

参考情報(外部サイト)

本文で参照した外部の公開情報です。

AIに読ませる前に決めておくこと

ログをAIに読ませること自体を避ける必要はありません。勤務先の規程と契約している条件を満たし、外に出せない値を消したうえで、結果を元の記録で確かめられる作業に限れば、補助として使えます。件数を数える、時間帯ごとに並べ替えるといった整理がこれにあたります。問題になるのは、返ってきた内容をそのまま事実として扱い、次の操作へつなげてしまうことです。

渡す前に原本の複製を取ること、渡す前に消すものを決めておくこと、出てきた値を元のログで確かめること。この3つを手順として決めておけば、混ざった文章にそのまま従ってしまう場面は避けやすくなります。それでも判断がつかないときに誰へ渡すのかを被害に気づく前に決めておけば、確認に使う時間を判断そのものに回せます。

Next

WordPressの調査と運用をAIにどこまで任せてよいか

整理と判断と操作のどこに線を引くかを確認する →

← コラム一覧へ戻る

緊急: 当日中初動