テックカリキュラム

ゲーム理論でAIの攻防を導く「G-CTR」とは?

ゲーム理論でAIの攻防を導く「G-CTR」とは?

1. はじめに:AIによるペネトレーションテストに足りない「戦略」とは

大規模言語モデル(LLM:Large Language Model)を使ったセキュリティ診断の自動化が急速に進んでいます。AIエージェントがポートスキャンや脆弱性の探索、攻撃コードの実行を自律的に繰り返し、1時間に数千回の操作を行うことも珍しくなくなりました。

一方で、AIエージェントには弱点もあります。手数は多くても、「いまどの経路を攻めるべきか」「どこを守れば最も効果的か」という戦略的な判断が苦手で、同じ失敗を繰り返したり、関係のない作業に時間を使ったりすることがあります。

2026年1月、スペインのセキュリティ企業Alias Roboticsとオーストリアのヨハネス・ケプラー大学リンツの研究者らは、論文「Cybersecurity AI: A Game-Theoretic AI for Guiding Attack and Defense」をarXivで公開しました。

本論文は、この「戦略の欠如」という課題に対して、ゲーム理論の計算結果をLLMエージェントにフィードバックするという方法を提案しています。提案手法の名前は G-CTR(Generative Cut-the-Rope) です。

論文の主張を一言でまとめると、次のようになります。

  • AIエージェント自身の作業ログから「攻撃グラフ」を自動で作る
  • 攻撃グラフ上で攻撃者と防御者のゲームを解き、ナッシュ均衡(最適な戦略の組み合わせ)を求める
  • その結果を短い要約(ダイジェスト)にしてエージェントのシステムプロンプトに戻し、次の行動を導く

2. 前提知識:CAI・攻撃グラフ・Cut-the-Rope

2-1. CAI(Cybersecurity AI)とReActエージェント

G-CTRは、Alias Roboticsがオープンソースで公開しているセキュリティ用AIフレームワーク「CAI(Cybersecurity AI)」の上に構築されています。CAIは、LLMがツールを呼び出しながら診断を進めるエージェント型のフレームワークで、人間が途中で確認・介入できる仕組み(Human-In-The-Loop)を備えています。

CAIのエージェントは ReAct と呼ばれる方式で動作します。ReActは、LLMが「推論(Reasoning)」と「行動(Acting)」を交互に繰り返す手法です。たとえば「このポートが開いているならWebサーバーがあるはずだ」と考え、実際にHTTPリクエストを送り、その結果を見て次の行動を考えます。

ReActは柔軟な一方で、長い作業になるほど文脈が膨らみ、目的から外れた行動やハルシネーション(事実と異なる出力)が起きやすくなります。G-CTRは、この弱点を外部からの戦略的な指示で補うことを狙っています。

2-2. 攻撃グラフとは

攻撃グラフ(Attack Graph) は、攻撃者がシステム内をどのように進むことができるかを、ノード(点)とエッジ(矢印)で表した図です。ノードはドメイン、IPアドレス、ポート、API、データベース、設定ミスなどの要素を表し、エッジは「ここからここへ進める」という遷移を表します。

攻撃グラフは脅威モデリングの中で使われる表現手法の一つです。論文でも、攻撃グラフはそれ単体で完全な脅威モデルになるわけではなく、資産の特定や信頼境界、業務への影響分析などと組み合わせて使うものだと説明されています。

従来、攻撃グラフは専門家が手作業で作るか、脆弱性データベースから静的に生成するのが一般的でした。手作業では1つの演習に数時間から数日かかることもあり、AIの診断速度に追いつけないことが課題でした。

2-3. Cut-the-Rope(CTR)とナッシュ均衡

Cut-the-Rope(CTR) は、論文の共著者でもあるStefan Rassらが2019年に提案した、攻撃グラフ上のセキュリティゲームのモデルです。

CTRでは、システムを有向非巡回グラフ(ループのないグラフ)として表します。攻撃者はグラフのどこかにすでに潜んでおり、目標のノードへ向かって確率的に前進します。防御者は、どのノードを検査するかを確率的に選びます。攻撃者が目標に着く前に、防御者が攻撃者のいるノードを検査できれば、攻撃者を「ロープを切る」ように排除できます。

このゲームを解くと、ナッシュ均衡が得られます。ナッシュ均衡とは、攻撃者も防御者も、自分だけ戦略を変えても得をしない状態のことです。CTRの場合、均衡から次の3つが得られます。

  • 防御者が各ノードをどの割合で検査すべきか(防御戦略)
  • 合理的な攻撃者がどの経路をどの割合で選ぶか(攻撃戦略)
  • 双方が最適に行動したときの攻撃成功確率(ゲームの値)

CTRは高度標的型攻撃(APT)への防御の研究などで使われてきましたが、入力となる攻撃グラフを人が用意する必要がありました。

3. G-CTRの仕組み:3つのフェーズによるクローズドループ

G-CTRの全体像は、次の3つのフェーズを繰り返すクローズドループ(閉ループ)です。

  1. ゲーム理論による分析:エージェントのログから攻撃グラフを作り、ナッシュ均衡を計算する
  2. 戦略の解釈(ダイジェスト生成):均衡の計算結果を、エージェントが使える短い指示文にまとめる
  3. エージェントの実行:ダイジェストを受け取ったエージェントがReActで診断を進め、その結果がまたログになる

論文の実装では、フェーズ1と2はエージェントの実行と並行して動き、約5回のやり取り(論文の記載では約80回のツール呼び出し)ごとに攻撃グラフとダイジェストを更新します。

3-1. フェーズ1:ログから攻撃グラフを自動生成する

元のCTRとG-CTRの最大の違いは、攻撃グラフの作り方です。G-CTRでは、LLMにエージェントの作業ログを読ませ、攻撃グラフをJSONL形式で出力させます。

LLMが作るグラフには、ループ(循環)が混ざるなど、ゲームの計算にそのまま使えない部分が含まれることがあります。そこでG-CTRでは、次のような後処理を行います。

  • NetworkXの関数を使って、ループを含まない経路だけを取り出す
  • 脆弱でない末端ノードを取り除き、脆弱なノードだけが終点になるようにする
  • 離れた開始ノードを、1つの入口ノードにつなげる

また、グラフのノード数にも上限を設けています。ログのメッセージ数に応じて上限の割合を変え、最終的に4〜25ノードの範囲に収めます。ノードを増やしすぎるとハルシネーションが増え、少なすぎると状況を表現できないため、そのバランスを経験的に調整したと説明されています。

3-2. 努力量スコア(Effort Score)

元のCTRでは、エッジに「攻撃が成功する確率」を割り当てます。しかし、LLMがログから作ったグラフには、そのような確率の根拠がありません。

そこでG-CTRでは、確率の代わりに 努力量スコア を使います。これは、あるノードから次の脆弱なノードに到達するまでに、どれだけの手間がかかったかを0〜1で表した値です。論文では、次の3つの指標を重み付けして組み合わせています。

  • メッセージ距離:ログ上で何メッセージ離れているか
  • トークン量:その区間でどれだけのトークンを消費したか
  • 計算コスト:その区間の推定API費用

つまり、「実際にエージェントが苦労した区間」は突破しにくい経路として、「すぐに到達できた区間」は突破しやすい経路として扱います。実際の作業記録から攻撃の難しさを推定する、実用的な工夫といえます。

3-3. フェーズ2:ダイジェストの生成

ナッシュ均衡の計算結果は数値の表なので、そのままLLMに渡しても活用しにくいという問題があります。G-CTRでは、これを短い指示文(ダイジェスト)に変換します。ダイジェストの作り方には2つのモードがあります。

モード方法生成時間特徴
algorithmicしきい値とテンプレートによる機械的な文章化約10ミリ秒出力は常に同じ(決定的)
llm計算結果をLLMに渡し、戦略として解釈させる平均28.3秒状況に応じた具体的な助言ができる

llmモードでは、計算結果を約350語の指示とともにLLMに渡し、「攻撃経路」「ボトルネック」「重要ノード」「リスクの高い遷移」「戦術的な助言」の5項目でまとめさせます。LLMの呼び出しに失敗した場合は、自動でalgorithmicモードに切り替わる設計です。

3-4. フェーズ3:システムプロンプトへの注入

生成したダイジェストは、エージェントの システムプロンプト に追加されます。論文によると、ユーザーメッセージやアシスタントメッセージとして追加する方法も試したところ、中〜長時間の演習では結果が悪くなり、推論の妨げになったため、システムプロンプトに入れる方法を採用したとのことです。

ゲーム理論の計算そのものは5ミリ秒未満で終わり、処理時間のほとんどはLLMによるグラフ生成とダイジェスト生成が占めます。

4. G-CTRの出力例を読む

論文では、G-CTRの出力を理解するための例として、入口(ノード1)から、ファイルアップロード、SQLインジェクション、権限昇格といった目標へ至る攻撃グラフを示しています。

この例でG-CTRが求めた防御戦略は次のとおりです。

ノード防御に割くべき割合
ラテラルムーブメント(ノード8)約67.4%
データベース(ノード4)約32.6%
偵察(ノード2)、Webサーバー(ノード3)0%

攻撃戦略としては、「偵察 → データベース → SQLインジェクション → 権限昇格」の経路が約67.4%、「ファイルアップロード → ラテラルムーブメント」を通る経路が約32.6%で選ばれるという結果になっています。双方が最適に行動したときの攻撃成功確率(ゲームの値)は約3.5%です。

ここで注目したいのは、すべてのノードを均等に守るのではなく、守る場所に優先順位を付けている点です。偵察やWebサーバーの段階は防御の割り当てが0%になっています。これは、そこで検査しても攻撃全体を止める効果が小さいと計算されたことを意味します。

なお、CTRモデルでの「防御」は、脆弱性の修正ではなく、経路上のノードを「検査」して攻撃者を見つけることとしてモデル化されています。この前提の違いは、実務に当てはめるときに注意が必要です。

5. 実験結果1:攻撃グラフの品質・速度・コスト

最初の実験では、5つの実際のセキュリティ演習のログを使い、LLMが作った攻撃グラフを、外部から依頼した2名の専門家が作った正解のグラフと比較しています。使われたモデルはgpt-4o、o3、grok-4、claude-sonnet-4、alias0の5つです。

主な結果は次のとおりです。

  • LLMが作ったグラフは6〜15ノードで、専門家のグラフとのノードの一致率は70〜90%
  • 生成時間は1演習あたり10〜46秒。専門家は30〜90分かかり、60〜245倍の高速化
  • 推論コストは1演習あたり0.05〜0.64ドル。専門家の作業(時給45ドルで換算)と比べて、要旨では140倍以上、本文では62〜450倍の削減と記載

モデルによる違いも報告されています。gpt-4oとo3は速く安い一方、gpt-4oはハルシネーションが多めでした。claude-sonnet-4は費用が高めですが、複雑な演習で最も構造的に完全で一貫したグラフを作ったとされています。

一方で、複雑な演習では、存在しないノードの生成、意味の取り違え、手順の抜けといった弱点も見られました。LLMは直接的な攻撃経路を強調し、試行錯誤の過程を省略しがちだという指摘もあります。

6. 実験結果2:サイバーレンジでの成功率

次の実験では、Shellshock(CVE-2014-6271、GNU Bashの環境変数の処理に関する脆弱性)を題材にした演習環境で、エージェントが制限時間40分以内にフラグを取得できるかを比較しています。実行モデルには、Alias Roboticsのセキュリティ向けLLM「alias1」が使われました。

構成試行数成功数成功率1回の成功あたりのコスト
G-CTRなし(ベースライン)15213.3%2.71ドル
G-CTR(algorithmicダイジェスト)15320.0%0.32ドル
G-CTR(llmダイジェスト)14642.9%0.12ドル

llmダイジェストを使った構成では、ベースラインと比べて成功率が13.3%から42.9%に上がり、1回の成功あたりのコストは約23分の1になりました。また、試行ごとのツール呼び出し回数のばらつき(最大値÷最小値)は、algorithmicモードの6.2倍に対し、llmモードでは1.2倍に縮まっています。

論文は、この結果を「LLMによる戦略の解釈が、エージェントの行動を安定させる制御装置として働いた」と解釈しています。同じ均衡の計算結果を受け取っても、機械的なテンプレートより、LLMが状況に合わせて言い換えたダイジェストのほうが効果的だったという点は興味深い結果です。

7. 実験結果3:Attack & Defense形式のCTF

最後の実験では、攻撃と防御を同時に行うAttack & Defense形式のCTF(cowsay、pingpongの2つの課題)で、チーム構成ごとの勝率を比較しています。各組み合わせで25試合を行い、すべてのエージェントにalias1とllmダイジェストを使っています。

構成内容主な結果
Red G-CTR攻撃役だけに誘導を与えるcowsayでベースラインに33.3%勝ち/42.9%負けと負け越し
Blue G-CTR防御役だけに誘導を与えるcowsayで57.1%勝ち/28.6%負け(約2:1)
Purple G-CTR攻撃役と防御役に別々のグラフで誘導を与えるcowsayでは勝ち越し、pingpongでは13.6%勝ち/31.8%負け
Purple G-CTR merged攻撃役と防御役が1つのグラフと文脈を共有するpingpongでベースラインに52.4%勝ち/28.6%負け、cowsayでPurple G-CTRに55%勝ち/15%負け

最も良い結果を出したのは、攻撃役と防御役が同じ攻撃グラフと文脈を共有する「Purple G-CTR merged」でした。論文は、これを最も高い性能を持つエージェントの構成として位置付けています。

特に興味深いのは、攻撃役だけを誘導した構成がベースラインに負け越したという結果です。論文では、誘導を受けた攻撃役が特定の経路にこだわりすぎ、状況が変わっても別の攻撃手段に切り替えられなくなったのではないかと推測しています。システムプロンプトに入れた指示の影響が強すぎることが、裏目に出た可能性があります。

8. 論文に対する評価と限界

ここからは、論文の結果を読む際に注意すべき点を整理します。

8-1. 試行回数が少なく、統計的な確からしさは限定的

サイバーレンジの実験は、各構成14〜15回の試行です。成功数は2回、3回、6回と少なく、偶然による変動の影響を大きく受けます。

筆者が論文の表の数値から計算したところ、llmダイジェストとベースライン(6/14回と2/15回)の差について、フィッシャーの正確確率検定の両側p値は約0.11でした。llmダイジェストとalgorithmicダイジェスト(6/14回と3/15回)の差では約0.25です。一般的な有意水準である5%では、どちらも「偶然とは言い切れない差」とまでは言えません。

また、成功率42.9%(6/14回)の95%信頼区間をウィルソン法で概算すると、およそ21〜67%と幅があります。結果の方向性は示唆的ですが、「成功率が2倍になる」と断定するには、より多くの試行が必要です。

8-2. 数値の示し方に注意が必要

要旨では「ダイジェストを加えると成功率が20.0%から42.9%に上がる」と書かれていますが、20.0%はG-CTRなしのベースラインではなく、algorithmicダイジェストの成功率です。本文の別の箇所では、ベースラインの13.3%からの改善として「3.21倍」「コスト23分の1」と記載されています。

また、コスト削減の倍率も「140倍以上」「225〜450倍」「62〜450倍」と箇所によって表現が異なります。どの構成同士を比べた数値なのかを確認しながら読む必要があります。

8-3. 評価環境が限定的

サイバーレンジの実験は、2014年に公開された有名な脆弱性であるShellshockの1つの環境だけで行われています。Attack & Defenseの実験に使われた2つの課題も、論文自身が「very easy(非常に易しい)」の難易度だと説明しています。

さらに、Purple G-CTRはcowsayでは勝ち越した一方、pingpongでは負け越しており、課題によって結果が逆転しています。より複雑で現実的な環境でも同じ効果が出るかは、今後の検証が必要です。

8-4. 著者と評価対象の関係

著者の多くはAlias Roboticsの所属で、評価に使われたCAI、alias0、alias1はいずれも同社が開発したものです。CAIはオープンソースで公開されており、検証できる余地はありますが、第三者による再現実験はまだ確認できていません。

また、本論文はarXivで公開されたプレプリント(2026年1月9日公開のv1)であり、査読付きの学術誌や国際会議での採録は確認できていません。

8-5. 「ハルシネーションの抑制」は間接的な根拠

論文は、G-CTRがハルシネーションを抑えると主張しています。しかし、その根拠は成功率の向上やツール呼び出し回数のばらつきの縮小といった間接的な指標です。ハルシネーションの発生件数を直接数えた評価ではない点には注意が必要です。

9. 筆者の考察:この論文から何を学ぶべきか

ここからは、論文の内容を踏まえた筆者の考えです。

9-1. 本当の価値は「LLMの外に構造化された状態を持つ」設計にある

筆者は、この論文の最も重要な貢献は、ゲーム理論そのものよりも、LLMエージェントの外側に、構造化された「状況の地図」を持たせる設計にあると考えています。

LLMエージェントは、作業が長くなるほど文脈が膨らみ、何が重要だったかを見失いがちです。G-CTRは、膨らんだログを攻撃グラフという小さな構造に圧縮し、そこから計算した優先順位を短い指示にして戻します。人間のエンジニアが作業の途中でホワイトボードに状況を整理し直すのと似た働きです。

この考え方は、セキュリティに限らず応用できます。たとえば、障害調査を行うエージェントであれば、ログから「原因候補の依存グラフ」を作って調べる順番を決める、といった使い方が考えられます。LLMに推論をすべて任せるのではなく、構造化と計算は外部の仕組みに任せ、LLMには解釈と実行を任せるという役割分担は、エージェント設計の有力なパターンだといえます。

9-2. 「攻撃役だけの誘導が負けた」結果こそ示唆的

筆者が最も興味深いと感じたのは、攻撃役だけを誘導した構成が負け越したという結果です。

これは、「強い指示を与えれば性能が上がる」とは限らないことを示しています。システムプロンプトに入れた戦略が強く効きすぎると、エージェントは状況の変化に合わせて計画を変えにくくなります。相手が動く環境では、計画に従う力と、計画を捨てる力の両方が必要です。

実務でエージェントに指示を与えるときも、「この経路を優先せよ」と固定的に指示するだけでなく、「この前提が崩れたら計画を見直す」という条件をあわせて書いておくことが重要だと考えます。

9-3. 防御側の優先順位付けにこそ使い道がある

論文の実験でも、防御役を誘導した構成のほうが攻撃役を誘導した構成より良い結果を出しています。筆者は、実務での使い道も防御側にあると考えています。

金融システムのように守るべき範囲が広いシステムでは、すべての箇所に同じだけの監視や検査を行うことは現実的ではありません。G-CTRの出力例のように、「どこを検査すれば攻撃全体を最も止めやすいか」を数値で示せれば、限られた予算や人員をどこに割くかの判断材料になります。

ただし、CTRモデルの「防御」は経路上の検査であり、脆弱性の修正やアクセス制御の見直しといった対策は含まれていません。実務では、ゲーム理論の出力をそのまま正解とするのではなく、担当者が優先順位を考えるための材料の一つとして扱うのが適切だと考えます。

9-4. 導入するときの注意点

AIによる攻撃の自動化は、使い方を誤れば実際の攻撃にも転用できる技術です。G-CTRのような仕組みを試す場合は、次の点を守る必要があります。

  • 診断の対象は、書面で許可を得たシステムや、専用の検証環境に限定する
  • エージェントが実行できる操作の範囲と時間をあらかじめ決めておく
  • 重要な操作の前には、人間が確認する手順(Human-In-The-Loop)を残す
  • エージェントのログには認証情報などの機密情報が含まれることがあるため、外部のLLMに送る前に取り扱いを確認する

10. まとめ:ゲーム理論はLLMエージェントの「羅針盤」になり得る

本論文は、AIエージェントの作業ログから攻撃グラフを自動で作り、ゲーム理論で求めた最適な戦略をエージェントに戻すG-CTRを提案しました。

論文の主な結果は次のとおりです。

  • LLMは専門家のグラフと70〜90%一致する攻撃グラフを、60〜245倍の速さで作れた
  • サイバーレンジでは、llmダイジェストによって成功率が13.3%から42.9%に上がり、行動のばらつきが小さくなった
  • Attack & Defense形式のCTFでは、攻撃役と防御役が1つのグラフを共有する構成が最も良い結果を出した

一方で、試行回数が少ないこと、評価環境が易しい課題に限られていること、著者の開発したモデルで評価していることなどから、効果の大きさについては今後の検証が必要です。

それでも、LLMの推論を外部の構造化された計算で導くという考え方は、セキュリティに限らず、長い作業を自律的にこなすAIエージェントを設計するうえで参考になります。LLMを「何でも考えるもの」ではなく、「地図と羅針盤を受け取って進むもの」として設計するという発想が、今後のエージェント開発で重要になると筆者は考えています。

参考文献・関連研究

本記事は2026年10月時点で公開されている文献・情報に基づく解説です。論文の主張と、筆者による統計的な再計算・考察を区別して記載しています。