LLMエージェントによって自然言語をゲーム理論モデルに変換する方法

本記事では、人間が思いついたゲーム理論的なシナリオを、コンピュータが理解できるプログラムに自動的に変換する研究を紹介します。

ゲーム理論は、企業間の競争や生物の生存戦略、SNSでのユーザー行動など、様々な相互作用を理解するための数理的な手法として注目されていますが、現実の状況をモデル化するには専門家による多大な労力が必要でした。

そこで研究チームは、LLMの言語変換能力を活用し、専門家でなくても自然な言葉でゲーム理論的な状況を記述し、コンピュータ上で検証・分析できる仕組みの開発に取り組みました。

背景

ゲーム理論のシミュレーションは、私たちの身近にある様々な相互作用を理解するための手法として注目されています。例えば、企業間の価格競争、生物の種の生存戦略、SNS上でのユーザーの行動パターンなど、利害関係者が互いの選択に影響されながら意思決定を行う状況を数理的にモデル化し、分析することができます。

ところが、現実の状況をゲーム理論でモデル化するのは簡単ではありません。たとえば、自動運転車同士が交差点で出会った時のシナリオを考えてみましょう。各車両の目的（安全性と速達性のバランス）、利用可能な情報（他の車両の位置や速度）、取りうる行動（加速、減速、停止など）に加えて、交通規則や歩行者の存在といった様々な要素を考慮する必要があります。このような複雑な状況を数学的に記述するには、専門家による多大な労力が必要です。

ここで注目されるのがLLMです。LLMは人間の言葉を理解し、それを数式や論理式に変換する能力を持っています。研究者らは、LLMの「翻訳者」としての能力に着目しました。

そこで彼らは、LLMで強化されたエージェント（プログラム）を開発し、日常言語で書かれたシナリオをコンピュータが理解できる論理プログラムに自動的に変換することに成功しました。さらに、変換されたプログラムの正しさを、エージェント同士の対戦を通じて検証できる仕組みも構築しました。結果、専門家でなくても、自然な言葉で記述したゲーム理論的な状況を、コンピュータ上で検証・分析できるようになりました。

基礎

ゲーム理論の基本的な枠組み

ゲーム理論は、人々や組織がどのように意思決定を行い、相互に影響し合うかを数学的に分析する手法です。たとえば、企業間の価格競争や国際関係における外交戦略などを理解する際に活用されます。

ゲームは4つの重要な要素から構成されます。まず「プレイヤー」は、自分にとって最も良い結果を得ようと合理的に行動する参加者です。次に「アクション」は、各プレイヤーが選択できる行動のことです。「報酬」は、プレイヤーたちの行動の組み合わせによって得られる結果の価値を数値化したものです。最後に「情報」は、各プレイヤーが知っている事柄（可能な行動、過去の出来事、相手の性質など）を表します。

対称ゲームと非対称ゲーム

ゲームは大きく2種類に分けられます。対称ゲームでは、プレイヤーの立場が変わっても、同じ行動の組み合わせなら同じ報酬が得られます。たとえば「囚人のジレンマ」では、2人の囚人が互いに協力するか裏切るかを選択し、その組み合わせによって刑期（報酬の逆数）が決まります。どちらの囚人にとっても、相手が協力したときに裏切ることが最も得になります。

一方、非対称ゲームでは、プレイヤーの立場によって同じ行動の組み合わせでも異なる報酬が発生します。たとえば「男女の戦い」では、カップルがデートの場所を決める際、男性はスポーツ観戦を、女性は映画鑑賞を望むような状況を表現します。一緒に過ごせることは双方にとって価値がありますが、望ましい場所は異なります。

汎用ゲームプレイの概念

汎用ゲームプレイとは、コンピュータがあらゆる種類のゲームのルールを理解し、自律的にプレイできるようにする研究分野です。人間がルールを教えなくても、ゲームの記述を読んで理解し、戦略を立てて実行できるシステムの開発を目指しています。

ゲームの記述はゲーム記述言語（GDL）で行われます。チェスや将棋のような完全情報ゲームから、ポーカーのような不完全情報ゲームまで、様々なゲームのルールをコンピュータが理解できる形式で記述するための言語です。以下のようなGDLを使うことで、ゲームのルール、合法手、勝利条件などが明確に定義され、コンピュータ同士で対戦することも可能になります。

なじみのない方にとっては上記を大まかに把握されてから以下を読まれることをお勧めします。

フレームワークの基本設計

今回考案されたシステムは、自然言語で書かれた”ゲーム理論的なシナリオ”を実行可能なプログラムへと変換するフレームワークです。中心となるのは、LLMで強化されたエージェントです。

エージェントの基本構造

エージェントは3つの主要なパーツから構成されています。

（１）ゲームモジュール（Game module）

ゲームのルールを定義する部分です。例えば「各プレイヤーがどのような選択肢を持つか」「ある選択をした時にどのような結果が得られるか」といった情報が、論理プログラミング言語Prologで記述されています。

（２）戦略モジュール（Strategy module）

プレイヤーが実際にどのように行動するかを決定する部分です。例えば「相手が前回協力してきたら、今回も協力する」といった戦略がプログラムとして実装されています。

（３）上記のモジュールを制御し、外部との通信を行うPythonプログラム

対戦履歴の管理や、他のエージェントとの情報のやり取りを担当します。

自動形式化の基本的な流れ

人間が自然言語で記述したゲームのルールは、まずLLMによってPrologプログラムに変換されます。変換されたプログラムは、構文的な正しさがチェックされ、エラーが見つかった場合は再度LLMに修正が依頼されます。プログラムが正しく生成されたら、実際に対戦を行うことで機能の検証が行われます。

ソルバーの仕組み

基本的なゲームの表現方法

ソルバーはPrologで実装され、ゲームの状態を「状況（situation）」として表現します。ゲーム開始時の状態は「s0」という定数で表されます。プレイヤーの行動は「do(Move, Situation)」という形式で表現され、ある状況で特定の行動を取った後の新しい状況を示します。

ゲーム進行の制御

ゲームの進行は以下のような論理規則で制御されます。

• ゲームは最終状態に到達すると終了します
• 最終状態でない場合、合法的な行動が選択され、新しい状態に移行します
• 各状態で何が成り立つかは、「holds(Fluent, Situation)」という述語で表現されます

例えば、囚人のジレンマゲームでは、プレイヤーが「協力」または「裏切り」を選択できることが、以下のように定義されます。

possible(move(Player, 'C'), Situation) :- holds(player(Player), Situation).
possible(move(Player, 'D'), Situation) :- holds(player(Player), Situation).

利得（報酬）の計算

プレイヤーの行動の結果得られる利得は、payoff述語で定義されます。例えば囚人のジレンマでは、

payoff('C', 'C', 3, 3).  % 両者が協力した場合
payoff('D', 'C', 5, 0).  % 一方が裏切った場合
payoff('C', 'D', 0, 5).  % 一方が裏切った場合
payoff('D', 'D', 1, 1).  % 両者が裏切った場合

このようになります。

戦略の実装とシミュレーション

戦略の実装方法

戦略はselect/4述語で実装されます。述語の引数は、プレイヤー(P)、対戦相手(O)、現在の状況(S)、選択する行動(M)の4つです。例えば、「しっぺ返し戦略」は以下のように実装されます。

select(P, O, S, M) :-
    \+ holds(last_move(O, _), S),    % 対戦相手の前回の手がない場合
    holds(default_move(P, M), S).    % デフォルトの手を選択

select(P, O, S, Mo) :-
    holds(last_move(O, Mo), S).      % 対戦相手の前回の手と同じ手を選択

このプログラムは、試合開始時（相手の前回の手がない場合）はデフォルトの手を選び、それ以外は相手の直前の手を真似る動作を表現しています。

シミュレーションの実行方法

シミュレーションには2つのモードがあります。

（１）クローンモード

同一のゲームルールを持つエージェントのコピーを作成し、指定された戦略で対戦を行います。得られた利得と、期待される利得を比較することで、プログラムが正しく生成されているか検証できます。

（２）ラウンドロビンモード

複数の異なる戦略を持つエージェントが総当たりで対戦します。各戦略の有効性を比較評価することができます。

勝者の判定方法

トーナメントの勝者は2つの方法で決定されます。

（１）目標利得到達方式

各エージェントに目標となる利得が設定されている場合、その値に到達したエージェントが勝者となります。

（２）最高利得方式

目標利得が設定されていない場合、最も高い合計利得を獲得したエージェントが勝者となります。

検証プロセス

正確性の3段階検証

生成されたプログラムの正確性は、3つの段階で検証されます。

（１）構文的検証

生成されたPrologプログラムが文法的に正しいかがチェックされます。例えば、かっこの対応が取れているか、必要な述語が全て定義されているかなどが確認されます。エラーが見つかった場合、エラーメッセージとともにLLMに修正が依頼されます。

（２）機能的検証

実際にプログラムを実行してゲームがプレイ可能かが確認されます。例えば、全てのプレイヤーが合法的な手を選択できるか、利得が正しく計算されるかなどがテストされます。

（３）意味的検証

ゲームの結果が期待通りかが確認されます。例えば「囚人のジレンマ」では、互いに協力するよりも裏切った方が得をする、という性質が保たれているかが検証されます。

制約チェックの仕組み

生成されたゲームが意図した性質を持っているかは、制約チェック機能によって確認されます。例えば「囚人のジレンマ」の場合、

valid_pd_payoffs(T, R, P, S, C, D) :-
    payoff(C, C, R, R),    % 相互協力の利得
    payoff(C, D, S, T),    % 一方が協力、一方が裏切りの利得
    T > R,                 % 裏切りの誘惑
    payoff(D, C, T, S),
    payoff(D, D, P, P),    % 相互裏切りの利得
    R > P,                 % 協力の価値
    P > S.                 % 搾取の回避

この制約を満たすことで、生成されたゲームが確かに「囚人のジレンマ」として機能することが保証されます。

利得計算と結果の評価

利得計算の実装

利得の計算は、finally/2述語を使って実装されます。ゲームの結果は、各プレイヤーの選択と得点を含む完全な情報として以下のように記録されます。

finally(outcome(P1, M1, U1, P2, M2, U2), S) :-
    holds(role(P1, row), S),     % P1が行プレイヤー
    holds(did(P1, M1), S),       % P1の選択した手
    holds(role(P2, col), S),     % P2が列プレイヤー
    holds(did(P2, M2), S),       % P2の選択した手
    payoff(M1, M2, U1, U2).      % 対応する利得

正規化スコアの計算

複数のゲーム間で戦略の性能を比較する際は、以下の式で利得が正規化されます。

正規化利得 = (獲得利得 - 最小可能利得) / (最大可能利得 - 最小可能利得)

例えば、あるゲームで獲得可能な利得が0から5の範囲で、実際に3点を獲得した場合、正規化スコアは0.6となります。

戦略の評価方法

戦略の評価は以下の手順で行われます。

1. 基準となる戦略（例：しっぺ返し戦略）との対戦を4ラウンド実施
2. 各ラウンドの利得を記録
3. 期待される利得パターンと実際の利得を比較
4. 試行を5回繰り返し、結果の一貫性を確認

例えば、ランダム戦略の場合、選択が実際にランダムに行われているか、長期的な平均利得が理論値に近いかが確認されます。

実験手法と実装

実験全体を通して、GPT-4oがLLMとして採用されました。温度パラメータは1.0に設定され、最大出力トークン数は1,024に制限されました。コード生成の試行回数は最大5回までと定められました。

実験は3つのフェーズに分けられ、それぞれ異なるパラメータ構成で実施されました。

第1実験　ゲーム記述の自動形式化

55件のゲーム理論シナリオのデータセットが用いられました。各シナリオに対して5つのエージェントが生成され、tit-for-tatとanti-tit-for-tatの戦略を用いて4ラウンドのトーナメントが実施されました。

第2実験　アクセルロッドのトーナメント再現

第1実験で生成された5つのゲームから各1つのエージェントが選択されました。各エージェントに6つの異なる戦略が割り当てられ、総当たり戦（ラウンドロビン）方式で10ラウンドが実施されました。

第3実験　戦略の自動形式化

囚人のジレンマを対象に、5つの戦略の自動形式化が試みられました。各戦略に対して5つのエージェントが生成され、4ラウンドのトーナメントが実施されました。

以下では、それぞれの実験についての詳細と結果を説明していきます。

実験の詳細と評価

第1実験　ゲーム記述の自動形式化の検証

データセットは55件のゲーム理論シナリオから構成されました。5つの代表的なゲーム（囚人のジレンマ、タカ-ハト、雄鹿狩り、男女の戦い、マッチング・ペニー）について、一般的な比喩を用いた5つのシナリオと、代替的な説明を用いた50のシナリオ（各ゲーム10件）が含まれています。

実験手順として、各シナリオに対して5つのエージェントが生成されました。エージェントは自動形式化されたゲームルールを用いて、tit-for-tatとanti-tit-for-tat戦略を採用し、4つの可能なすべての手の組み合わせをテストしました。

評価方法は以下の通りです。

各エージェントには最大5回のコード生成機会が与えられ、5回以内に構文的に正しいコードを生成できなかった場合は「構文的に不正確」とラベル付けされました。

そしてトーナメント後、各エージェントの個別および合計報酬が目標値と比較され、一致した場合は意味的に正確と判断されました。

第2実験　戦略の比較評価

第1実験で生成された5つのゲームから、各1つのエージェントが選択されました。各エージェントに6つの戦略（anti-default-move、anti-tit-for-tat、best-response、default-move、random、tit-for-tat）が割り当てられ、10ラウンドの総当たり戦が実施されました。

協力・裏切りの概念が明示的でないゲームに対応するため、「デフォルトの手」とその「反対の手」が定義されました。例えば、

• 囚人のジレンマ：「協力」をデフォルト
• タカ-ハト：「ハト」をデフォルト
• 雄鹿狩り：「雄鹿を狙う」をデフォルト
• 男女の戦い：「オペラ」をデフォルト
• マッチング・ペニー：「表」をデフォルト

戦略のパフォーマンスは、得られた合計報酬を正規化して評価されました。正規化の計算式は以下の通りです。

normalized_payoff = (total_payoff – min_total_payoff) / (max_total_payoff – min_total_payoff)

この正規化によって、異なるゲーム間での戦略の効果を公平に比較することが可能となりました。

第3実験　戦略の自動形式化の評価

戦略の自動形式化の意味的正確性が評価されました。tit-for-tat戦略の自然言語による説明とPrologによる実装が参照例として使用され、残りの5つの戦略に対して自動形式化が試みられました。

評価手順は以下の通りです。

1. 自動形式化された各戦略が、既定の囚人のジレンマゲームルールを持つエージェントに割り当てられました。
2. エージェントはanti-tit-for-tat戦略を使用するクローンと4ラウンドの対戦を行いました。
3. 各戦略に固有の目標報酬と比較して正確性が評価されました。
4. random戦略については、手動での検証も追加で実施されました。
5. 結果の一貫性を確保するため、各戦略について5回のトーナメントが実施されました。

評価結果の解釈

実験結果から、以下の主要な知見が得られました。

まず、ゲーム記述の自動形式化においては、93%のエージェントが初回試行で構文的に正しいコードを生成できました。残り7%は2回目の試行で成功し、全体で96%の構文的正確性が達成されました。

次に意味的正確性は87%に達し、特に合計報酬に基づく近似的検証と個別報酬に基づく厳密な検証で、ほぼ同等の結果が得られました。

さらに、戦略の比較では、best-response戦略が平均して最も高いパフォーマンスを示し、次いでtit-for-tat戦略が効果的でした。ただし、男女の戦いと囚人のジレンマでは、異なる結果パターンが観察されました。

最後に戦略の自動形式化では、default-move、anti-default-move、anti-tit-for-tatといった比較的単純な戦略で100%の正確性が達成された一方、より複雑なbest-response戦略では40%にとどまりました。

以上の結果は、LLMを用いたゲーム理論シナリオの自動形式化が実用的なレベルで可能であることを示唆しています。その中でも、単純な戦略やルールについては高い信頼性が確認されました。

一方で、複雑な戦略の自動形式化には改善の余地が残されています。

まとめ

本記事では、ゲーム理論的なシナリオを自然言語から実行可能なプログラムに自動変換する研究を紹介しました。研究チームが開発したフレームワークは、2×2の同時手番ゲームにおいて高い精度でプログラム生成を実現し、生成されたプログラムの正しさを自動的に検証できることが示されました。今後、より複雑なゲームへの対応や、対話的なプログラム生成機能の開発が期待されます。

理解度クイズ（β版）