画面を見ずにWoW初期クエストを40分で攻略、GPT-6 Astraがサーバー通信から操作ツールを自作

GPT-6 Astraが『World of Warcraft』（WoW）のオークの初期エリアにある全クエストを、40分、死亡ゼロで完了したと、オープンソースの実験基盤「agent-wow」の開発者が報告した。ゲーム画面を一度も見ることなく、サーバーとの通信から状況を把握し、必要な操作ツールを自ら作りながら進めたという。しかも、移動や戦闘の機能があらかじめ完成した関数として与えられていたわけではない。今回の注目点は、Astraが攻略に必要なツールをどのように組み立てたかにある。ただし、クエスト情報や経路探索用のデータを参照できる独自サーバー上での実験であり、人間と同じ条件でゲームをプレイした記録として捉えると、成果の意味を取り違える。

40分・死亡ゼロは、どのような攻略だったのか

開発者の10月2日付報告によると、Codexで動かしたGPT-6 Astraの推論設定は「xhigh」だった。開始時に与えられた指示は、「オークのキャラクターを作り、初期エリアの全クエストを完了せよ」という一文だけだった。開発者は、途中で何度も行き詰まる長時間の試行を予想していたが、実際には40分で完了し、一度も死亡しなかったと説明している。

接続先は、オープンソースのサーバー実装「AzerothCore」を使ってローカルに構築した独自サーバーだ。対象となったのは、拡張『Wrath of the Lich King』の最終版にあたるWoW 3.3.5aで、Blizzardが現在運営している公式サービスとは条件が異なる。完了したのも初期エリアのクエストであり、ゲーム全体や高難度の集団コンテンツを攻略したという報告ではない。

「一文の指示で成功した」という説明も、モデルを一度呼び出しただけですべてが終わったという意味ではない。Astraはコードを生成して実行し、ゲームから返ってくる情報を確認しながら次の行動を決めている。公開されたのは開発者による初回の実演結果であり、独立した追試や、複数回試した場合の成功率やばらつきまでは示されていない。

画面ではなく、通信からゲームの状況を把握する

agent-wowは、WoWの通信プロトコルを使ってサーバーとやり取りする。ゲーム画面を画像として認識し、キーボードやマウスを操作する方式ではない。人間が画面を見て把握する体力、周囲の敵、クエストの進捗などを、Astraは通信メッセージを解析して取得する。

開発者が公開した生成コードを見ると、エージェントは必要なメッセージを受信して保存するモジュールを作っている。Pythonプログラムが前回の読み取り位置以降に届いたメッセージを取得し、体力や周囲の生物の状態を更新する。クエストの進捗や戦利品の情報も反映し、次の行動を判断するための状態として保持する。そして、別の送信機能を使ってサーバーへ操作内容を伝える。

つまり、描画されたゲーム画面の代わりに、通信から得た情報をもとにゲーム内の状態を把握していた。開発者は当初、Astraが移動先や呪文を指定する高水準の操作関数を作ると予想していたという。しかし実際には、メッセージを送受信するモジュールを中心に、通信形式を直接扱う仕組みを構築して攻略を進めた。

さらにAstraは、AzerothCoreのSQLファイルからクエストの条件も調べていた。クエストを依頼するNPC、完了報告先のNPC、対象となる敵やアイテムが存在する座標を取り出せば、「どこへ行き、何をすればよいか」を具体的な手順に落とし込める。通信から得た現在の状態と、データベースから取得した目標や位置情報を組み合わせて行動を計画したのである。

開発者の観察によると、Astraは前提となるクエストを順番に終え、不要なアイテムを売り、装備も更新した。最後の洞窟へ入る前には新しい能力を習得し、洞窟内では二つのクエストを同時に受けてまとめて進めるなど、効率を考えた行動も見られた。目の前の敵を倒すだけでなく、その後の工程を見越して準備していた点も、今回の実演で注目すべき部分だ。

Astraが作ったものと、既存環境を利用したもの

agent-wowの公開READMEによると、ゲーム中に標準で用意されているRPC、つまり外部から直接呼び出せる操作は、ログアウト用のsession.logoutだけだ。認証やキャラクター作成の仕組みは用意されているものの、移動や戦闘には追加のモジュールを作る必要がある。すべてをゼロから構築するわけではなく、サーバーと通信できる基盤の上に、課題に必要な機能を追加していく設計となっている。

今回の攻略では、通信を読み書きするための仕組みはAstraが作り、クエスト情報や経路探索用のデータについては既存の資源を利用していた。

部分	最初から利用できた機能・データ	Astraが作ったもの・行ったこと
サーバーへの接続	agent-wowの認証、キャラクター管理、通信機能	目的に応じてクライアント機能を利用
状況の把握と操作	メッセージを扱うモジュールの基盤	受信・送信モジュールと、状態を更新するPythonコードを作成
クエストの計画	AzerothCoreのSQLファイル	条件やNPCの位置を抽出し、攻略順序や準備内容を決定
移動経路	mmapsと呼ばれる経路探索用データとDetourライブラリー	C++の補助プログラムを作り、算出した経路に沿って移動を指示

この表は、10月2日付の実験報告に掲載された生成コードと、10月5日時点の公開READMEを照合し、既存機能、Astraが作ったコード、既存データに分けて整理したものだ。READMEはシステムの設計を確認するための補助資料であり、当日の実行環境を独立に再現した検証ではない。

経路探索の仕組みは、この役割分担をよく表している。Astraが作成したC++の補助プログラムは、出発地と目的地の座標を受け取り、mmapsを読み込んでDetourに経路を問い合わせる。Recast Navigationの公式説明によると、ナビゲーションメッシュは、移動可能な地形とそのつながりを表現したデータである。Detourは、そのデータを使って経路を探索するライブラリーだ。Astraが作ったのは、既存の地形データと経路探索機能を、自らの行動制御に組み込むための補助ツールだった。

計算された中間地点の座標はPython側へ返され、移動を指示するメッセージへ変換される。公開されたC++コードには、経路が目的地までつながっていない場合にエラーを返す処理も含まれている。進めそうな方向を推測し続けるのではなく、目的地までの経路が成立しているかをプログラムで確認する設計になっている。

もう一つ、公開APIの定義を見ると、メッセージの送信処理が完了したことと、サーバー側で操作が正常に受け付けられたことは明確に区別されている。メッセージを送信できただけでは、攻撃やクエストに関する操作が成功したとは限らない。その後に返ってくる状態や応答を確認する必要がある。

これは現在公開されているAPIの設計から分かる条件であり、今回のすべての操作が適切に確認されていたことを保証するものではない。ただ、AIが生成した指示をゲーム内の実際の行動へ結び付ける際に、どのような確認が必要になるかを具体的に示している。

評価を左右する情報アクセスと権限

SQLファイルからクエスト条件や座標を読み取れる環境では、画面だけを与えた場合と比べて探索に必要な負担が大きく変わる。画面を見ていなかったことと、攻略に必要な情報を持っていなかったことは同じではない。今回の実演は、利用可能な情報を探し出し、それを自作したツールや行動計画へ組み込む能力を評価する材料になる。

開発者は、SQLを調べる行動を、人間が攻略サイトのWowheadで事前に情報を調べることになぞらえている。この見方には一定の妥当性がある。ただし、どこまでの情報へアクセスできるのかは、評価条件として明示する必要がある。現在公開されているエージェント向けの作業指示にも、AzerothCoreのソースコードやモジュールのひな型などが参照先として記載されている。開始時の指示自体は短くても、その周囲にはこうした資料と実行環境が用意されている。

移動性能についても注意が必要だ。開発者は、キャラクターが壁をすり抜けた場面があったと報告している。衝突判定に必要な情報が欠けた場所を通過できた可能性を挙げているものの、原因が特定されたわけではない。したがって、人間が画面を見ながら通常の移動経路を使う場合と同じ条件で、移動能力を比較できる実験ではない。

さらに重要なのが、今回の実行環境にはサンドボックスが設けられていなかった点だ。開発者自身も、Astraが稼働中のサーバーやデータベースへ管理者権限でアクセスし、内部を書き換えることも技術的には可能だったと認めている。サンドボックスとは、エージェントがアクセスしたり変更したりできる範囲を制限する仕組みである。今回、実際にサーバー内部を書き換えて攻略したと報告されているわけではないが、そうした操作を権限レベルで禁止した環境でもなかった。

そのため、今後の評価では「参照してよいデータ」と「変更してよい対象」を明確に分ける必要がある。攻略に役立つ情報を参照することと、クエストの達成条件そのものを書き換えることでは、測っている能力がまったく異なる。また、今回ゲーム専用の追加訓練を行っていないという説明から、モデルが事前学習の段階でWoWに関する情報へ触れていなかったとまでは判断できない。

次の課題は、長期的な攻略と複数エージェントの協調

コードを生成してゲーム世界へ働きかける方式には先行例がある。Factorio Learning Environmentでは、エージェントがPythonプログラムを生成・実行し、その結果を次の観測情報として利用する。画面操作を前提とせず、プログラムの実行結果から状況を読み取り、次の行動を決める仕組みだ。agent-wowも、こうしたコード生成とゲーム内行動を組み合わせる手法をWoWへ広げる試みと位置付けられる。

WoWを使う意味は、課題を長期間にわたって連続させられる点にある。装備を整えるには、素材を集めて自分で作るのか、資金を稼いで購入するのかを選ぶ必要がある。クエストの前提条件を満たし、仲間と役割を分担し、戦闘中には状況の変化へ素早く対応しなければならない。準備段階での判断が、その後の攻略に影響する。

開発者が今後確かめたい課題として挙げているのは、単独のエージェントがレベル80まで完全自律でキャラクターを育成できるか、そして複数のエージェントがゲーム内のコミュニケーション機能を使い、クエストやダンジョンを協力して攻略できるかという点だ。最終的な目標には、高難度コンテンツであるIcecrown Citadelを複数のAIエージェントで攻略することも挙げられている。いずれも、今回の実験で達成された成果ではない。

長期間の状態を追跡できる観測ツールと、アクセス権限を適切に制限する仕組みを整えたうえで、同じ条件で試行を繰り返せば、生成したツールを別の課題でも再利用できるのか、行動に失敗した後で原因を突き止めて修正できるのかといった能力も評価できる。そこまで進めば、今回の40分間の初期エリア攻略は、AIに長期的な仕事を任せるうえで必要となるツール作成能力や協調能力を測るための出発点として位置付けられる。