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

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

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

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

AIの読み方が加わると、弱点がはじめて問題になります。運営者が書いた依頼文と、貼り付けられたログの中身は、同じ一続きの文章としてAIに届きます。どちらが依頼でどちらが調べる対象なのかを見分ける対策はありますが、この見分けが常に成功するわけではありません。ログの中に指示として読める文章があれば、それも依頼の一部として扱われることがあります。この手口は「プロンプトインジェクション」（AIに読ませる文章の中へ指示を紛れ込ませ、動作を乗っ取る手口）と呼ばれます。

同じ手口は、実際に見つかったマルウェアにも入っていました。2026年6月、セキュリティ企業SentinelOneの調査部門SentinelLABSが、macOSを遠隔から操るプログラムを調べました。AIの解析を妨げる文章が埋め込まれている（外部サイト）と報告しています。3.5KBの文章に、AIの分析基盤がやりとりする形式をまねた偽のメッセージが38個並びます。解析の途中で認証が切れた、メモリが足りずに強制終了した、ディスクの空きが尽きた、操作に何度も失敗したという知らせを装っています。どれも、解析を続けても無駄だとAIに思わせて、途中で打ち切らせたり断らせたりするための文面です。

ただし、アクセスログの話ではありません。攻撃者が文章を仕込んだ先は、解析にかける実行ファイルの中です。読む側もマルウェアを解析する基盤で、サイトの運営担当者ではありません。狙いも、要約の中身を書き換えることではなく、解析を止めることでした。SentinelLABSは、検体に文章が入っていたところまでを確かめています。実際にAIが解析をやめたかどうかは報告されておらず、被害に遭った組織も公表されていません。それでも、調べる対象の中身を攻撃者が決められるという条件は、ログにも当てはまります。

AIに読ませる前提で文章を仕込む動きは、Webページでも数えられています。Googleは2026年4月の報告（外部サイト）で、英語圏のWebページを集めた公開のデータ（Common Crawl）を調べ、AIへの悪意ある指示に分類した検出が、2025年11月から2026年2月のあいだに相対で32%増えたとしています。件数そのものは示されていません。見つかったものの多くは個々のサイトの書き手による試しやいたずらとみられるもので、最近の研究で公表された高度な手口をなぞったものではなかったとしており、攻撃が成功したという報告でもありません。ログではなく、Webページでの観測です。

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

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

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

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

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

どの欄が記録され、どの欄が残らないのかは、契約しているサーバーによって変わります。たとえばエックスサーバーのアクセスログの記録項目には、送信ボタンを通じて送られた本文が含まれず、その場合は攻撃の中身そのものは追えません。それでも、攻撃者が自由に書ける欄の文字列は残ります。何が残り何が残らないかは、共用サーバーで残らない記録を確認することで整理できます。

各社の対策と、効き方の限界

AIの側にも対策はあります。ただし、効き方は経路によって違います。

Anthropicは2026年5月に公表した説明（外部サイト）で、自社のコーディング支援などでは、AIが自分で取りに行った外部の情報を、モデルへ渡る前に検査できるとしています。ログを自分でコピーして貼り付ける調査は、AIが取りに行く経路ではないので、この検査が見る範囲の外にあります。同社が2026年9月に公表したClaude Opus 5.5の技術文書（システムカード）は、貼り付けた文章を、AIが取りに行った情報への攻撃とは別の問題として論じています。

同じ文書のコーディングの作業での試験では、公開された版のOpus 5.5が、貼られた文章に仕込まれた指示に沿って動いた割合は、考える量を既定にした設定で約2%、最大にした設定で約7.4%でした。同社は、この試験はあからさまに有害な指示に絞って測ったものだとしています。同社の以前のモデルのうち、Claude Opus 5とClaude Sonnet 5は同じ試験で一度も従っておらず、Opus 5.5で弱くなっています。同じ条件で製品の対策を加えると0件でしたが、Anthropicは、貼り付けた文章に印を付けるといった製品の変更を加えているところだとしています。また、攻撃者が細工した文章を利用者が貼った場合、完全に耐えられるモデルは無いとしつつ、訓練と安全対策の変更が、この弱さによるデータや認証情報の持ち出しといった問題を防ぐ助けになるとしています。

ログ内の攻撃そのものは、ログを読ませるAIへの攻撃を調べた研究（外部サイト）が直接扱っています。攻撃者が値を決められる欄がプロンプトに入れば、攻撃者がプロンプトの一部を制御することになる、と説明しています。そのうえでAIは、同じ文章として届いた記録の中身と指示を見分けなければならなくなります。

前の段落で挙げたログを読ませるAIへの攻撃の研究では、攻撃の成功率は、4種類の手口と3種類の作業（分類・要約・対処の提案）を平均すると、対策なしの26.6%から、AIの答えを決まった選択肢に縛った条件の11.8%まで下がりましたが、0にはなりませんでした（GPT-4o-miniでの査読前の検証）。要約に限ると、文脈を操作する手口では、対策なしで96%、答えの形を縛った条件でも38%が通っています。記録の整理から操作の実行までの各段階の危険度は、AIに任せてよい範囲を確認することで比べられます。ログの調査での線は、この記事の結びにまとめます。

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

「AIの利用をめぐるサイバーリスク」は、IPA（情報処理推進機構）が2026年1月に公表した「情報セキュリティ10大脅威 2026」で、組織向けの3位に初めて選ばれました。解説書（組織編）（外部サイト）では、情報漏えいと、AIが加工した結果を検証せずに受け取ることが、別々の問題として挙げられています。ログの調査で気をつけたいのは、次の5つです。

• 要約をそのまま頼む：ログを読ませるAIへの攻撃を調べた先の研究（GPT-4o-miniを調査役に置いた、2026年5月公開の査読前の検証）では、要約は、分類や対処の提案より歪みやすい作業だったと報告されています。歪み方は、攻撃の記述が落ちる、記述が弱まる、対処は要らないと結論される、といったものでした。出てきた値を突き合わせても、書かれなかったことは見つかりません。要約に出てこなかったことを、無かったこととして扱わないでください。
• 返ってきた要約だけを読んで判断する：要約に出た値は、元のログの該当行を開いて突き合わせるまで、確定した事実として扱いません。
• 返ってきた内容のままファイルを消す、遮断する、設定を変える：誤った説明に沿って動くと、正規の利用者を遮断したり、調査に必要な記録を自分で消したりすることがあります。
• サーバーを操作できる権限をAIに渡す：ログを読ませたうえで対処まで任せる使い方は、混ざった指示がそのまま実行される経路になり得ます。対処まで任せる構成で、AIが混ざった指示どおりのコマンドを実行しようとした検証があります（出所はこの節の終わりに示します）。ログを読ませて要約や分類だけをさせる使い方を扱った研究は、AIがコマンドを実行することを前提に置いていません（研究側は、AIがコマンドを実行することも、道具（ツール）を呼び出すことも、証拠を消すことも、ログを集める監視の仕組みを操作することもない前提だと明記しています）。同じ「ログをAIに読ませる」でも、操作権限を渡すかどうかで届く範囲が変わります。
• 中身を確かめずに社外のAIサービスへ貼り付ける：アクセスログには、URLに含まれた入力値や、利用者を識別する文字列が残ります。プラグインが別に出力するログには、問い合わせ内容が残ることもあります。プロンプトインジェクションより先に、社外への情報の持ち出しが問題になる場合があります。

操作権限を渡した場合については、2026年4月に公開された査読前の検証（LogJack）（外部サイト）が、クラウドのログを読んで復旧のコマンドまで実行する構成で、AIが混ざった指示どおりのコマンドを、実行するための道具へ渡した例を示しています（検証ではコマンドを実行せずに止めて記録しています。コマンドを実行して直せるとAIに伝えただけの条件で、割合はモデルによって0%から86.2%まで開きます。直す操作をしないよう指示すると、Llama 3.3 70Bは30.0%でしたが、ほかの7つのモデルは0%から1.9%でした）。チャットへ貼り付ける使い方ではなく、AIに操作の権限を渡した構成の結果です。

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

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

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

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

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