見えない駒を、CPUはどう推理するのか。Claude Codeと作る軍人将棋【第1回】

これまでAIに作ってもらったゲームは、マインスイーパー、3Dブロック崩し、猫のダンジョン探索でした。複雑さは少しずつ増えましたが、どれも「決められたルールに従って世界を動かす」ゲームです。

今回は一段違うものを作らせます。題材は軍人将棋です。軍人将棋は、将棋やリバーシのように盤面のすべてが両者に見える「完全情報ゲーム」ではなく、相手の駒の正体が見えない「不完全情報ゲーム」です。

完成したゲームのスマートフォン版で、こちらの中将が敵の総司令部（奥の中央の2マス）に入って勝った盤面です。上に敵軍、下に自軍の取られた駒が並びます。自分の駒は表向きですが、敵の駒は盤上に残っている駒も、取った駒も、すべて裏向きのままです。

作りたいのは、ゲームそのものよりも対戦相手のCPUです。見えない駒について仮説を立て、動きや戦闘の結果で考えを改め、次の手を選ぶ。そういう「考える」相手をAIに作らせたら、どうなるのかを試しました。

開発を任せたのは、AnthropicのAI開発ツール「Claude Code」です。企画の相談から、スマートフォン版、対局ルールの追加、終局後の振り返り機能まで、2日間の記録を4回に分けて書きます。初回は、企画から最初の版1.0.0で初めて対局するまでです。

これまでのゲームやソフトは、OpenAIのCodexで作ってきました。その中で決めてきたバージョン管理や配布ZIPの作り方などのルールは、この日の昼に、Codexのメモリに頼るのではなくMarkdownのファイルとして整備し直したところです。AIが変わっても、そのルールが通用するのか。それを確かめる意味もあって、今回はClaude Codeを選びました。

※Claude Codeは、ファイルの作成やコードの実装・テストなどをAIに任せられるAnthropicの開発ツールです。今回はモデルにClaude Opus 5.5を使いました。詳しくはClaude Codeとは、これまでの記事で使ったCodexとAstraについてはAstraとCodexとはをご覧ください。

ルールどおりに動くゲームの、次に作りたかったもの

企画は、いつものように外部チャットでの相談から始めました。最初に投げたのは、この一文です。

Unityで「軍人将棋」作成を開始する。今回の主題は一定のルールでしか動作しない物だったが思考をする物を作らせたらどうなるか検証。

対局では交互に1枚ずつ駒を動かし、大将から少佐までのどれかで相手の総司令部（陣地の最後列中央の2マス）に入れば勝ちです。駒同士がぶつかると、勝敗表で強い方が残ります。

軍人将棋では、自分の駒の正体は分かりますが、相手の駒は裏返しのままです。戦うと勝ち負けだけが分かり、相手が何だったかは明かされません。

そのため、CPUは序盤、相手の駒を「大将かもしれない」「地雷かもしれない」という候補と確率で扱うしかありません。ところが、駒が動けば地雷と軍旗ではないと分かります。こちらの少佐に勝てば、少佐より強い駒に絞れます。

外部チャットでは、この「確率でしか分からなかった駒が、観測によって絞られていく過程」が一番面白いところだ、という話になりました。

もう一つ、軍人将棋には審判役が要ります。対戦する二人とも相手の駒を見てはいけないので、戦った駒の強さを第三者が見比べて判定します。子供の頃は、審判が必要なのに審判役がなかなか見つからなくて、遊べないのがネックでした。コンピュータなら、審判はいつでもいます。しかも、そのコンピュータ自身を対戦相手にできます。

主役は、CPUの頭の中

相談の中で採用したのが、CPUの思考モニターという案です。

普通の軍人将棋のゲームなら、CPUが相手の駒をどう見積もっているかは隠します。今回はそれを逆に主役にします。ゲーム画面とは別に研究用の画面を用意し、CPUが何を知り、何を推測し、なぜその手を選んだのかを全部見えるようにします。

外部チャットは、最初から強いCPUを作らせることにこだわらなくていい、とも言っていました。初手ではCPUも何も知らない。敵が動いて候補が減る。戦闘してさらに減る。推定を使って手を選ぶ。そして、

外したｗ

これが見える方が企画らしい、というわけです。

Claude Codeへ渡した依頼文では、思考モニターを「初版から必須」とし、次のような表示例を付けました。

Enemy #17

大将 0%
中将 0%
少将 0%
工兵 35%
飛行機 65%
地雷 0% ← 移動したため除外
軍旗 0% ← 移動したため除外

Reason:
Turn 8 : 3マス移動を観測
Turn 12: 他駒を飛び越した

一方で、思考アルゴリズム、評価関数、何手先まで読むかといった中身は指定していません。

最終的なAIアルゴリズム、
評価関数、
探索方法、
先読み深度等はこちらから指定しません。

今回の検証目的を理解した上で、
合理的に勝利を目指すCPUをあなた自身で設計してください。

「カンニング禁止」を最上位の要件にした

CPUが相手の駒を推理するゲームでは、一番やってはいけないことがあります。CPUが答えを見てしまうことです。

ゲームの審判処理は、当然すべての駒の正体を知っています。同じプログラムの中にあるCPUが、その情報をこっそり参照すれば、推理しているふりをしながら全部お見通しの相手になってしまいます。画面を見ている人間には、その違いが分かりません。

そこで依頼文では、これを最上位の要件にしました。

単に「参照しない」という実装ではなく、
可能な限りアーキテクチャ上アクセスできないように分離してください。

Claude Codeは、プログラムを役割ごとの部品に分けて作りました。駒の本当の種類は審判側の部品の内部にだけ置き、CPUの部品からは、その部品をそもそも参照できない構成です。CPUが受け取る「相手の駒」のデータには、駒の種類を入れる欄自体がありません。

確かめ方も面白いものでした。駒の並びの形は同じまま、相手の駒の正体だけを入れ替えた2つの対局を用意し、同じ最初の一手のあとのCPUの判断を比べます。CPUから見える情報は同じなので、CPUが本当に観測だけで考えているなら、候補手も評価値も確率もまったく同じになるはずです。自動テストでは、これがビット単位で一致することを確認しています。

ルールが割れるところは、質問してきた

軍人将棋には地方ルールや製品ごとの違いがあります。依頼文では、古典的な31枚型に近いルールを一つに固定するよう頼み、ゲーム性に大きく影響する曖昧な点は、勝手に決めずに質問するよう書いておきました。

Claude Codeは、まず勝敗表と盤の形を調べました。最終的に参考にしたのは、足立区生涯学習センターのサイトで配布されている軍人将棋の遊び方と勝敗表のPDFと、一ノ瀬武志さんの「軍人将棋ルール研究」にある8列31枚のX字型の盤です。

そのうえで、4つの質問が返ってきました。

盤の中央にある丸（突入口の中心）を、普通のマスとして扱うか。
タンクや騎兵の「前へ2マス」、工兵の「何マスでも」は、中央の丸をまたげるか。
地雷を総司令部に置いてよいか。
軍旗の強さをどう扱うか。

それぞれに推奨案が付いていたので、すべて推奨どおりにしました。地雷は総司令部に置ける。軍旗は、すぐ後ろにいる味方の駒と同じ強さになる。この2つは、後の対局にも関わってきます。

駒の見た目も、機械的に作ってもらいました。素材は、外部チャットで作った木製駒やアイコン、盤の木目などの画像と、手持ちの筆文字フォント「KSO闘龍」です。人間が用意した原本はプロジェクト内の専用フォルダーへ移し、加工したものは別の場所に作る、という境界も指定しました。16種類の駒の画像は、スクリプトから毎回同じように生成されます。

Claude Codeに渡した素材です。どれも外部チャットの画像生成機能で用意しました。駒デザイン案と駒の完成イメージは見た目の基準、無地の木製駒・アイコン素材集・盤の木目は材料、盤面の完成イメージは材質やカメラの角度の参考です。画像をそのまま貼るのではなく、無地の駒にアイコンとKSO闘龍の文字を重ねて、駒の画像を作り直しています。

30分後、EXEが勝手に対局を始めた

質問に答えると、Claude CodeはUnityのプロジェクトを作り、実装に入りました。プロジェクトのフォルダーができたのは15時14分です。

15時45分ごろ、画面に見慣れないウィンドウが現れました。ビルドしたゲームのEXEが起動し、誰も触っていないのに対局が進んでいきます。Claude Codeの自動検証でした。

自動試験キター

自動検証中の1.0.0です。画面はTURN 116で、右側の思考モニターにはTURN 114のCPUの判断が出ています。検討した34手の候補を、駒得・前進・防衛・リスクなどの内訳付きで並べています。この手は評価の差がごく小さい候補が28手あり、その中からDecision Seedという乱数で選んだ、と理由に出ています。

16時16分、1.0.0がコミットされました。企画の相談を始めたのは13時19分なので、ここまで約3時間です。

整備したルールも読まれていました。Claude Codeは作業の最初に「まず規約資料と提供素材を確認します」と書き、版数ごとのフォルダーにReleaseビルドを出力して、ローカルにコミットしています。以後の版でも「互換を保った機能追加なので、マイナー更新の1.1.0」のように、ルールに沿って版数を決め、規約のフォルダーにあるこのプロジェクト用のページも自分で更新していきました。

Claude Codeが設計したCPUの考え方は、おおまかに次のようなものでした。

相手の31枚それぞれについて、16種類の候補と確率を持つ。
観測と矛盾する候補を消す。1マスでも動けば地雷と軍旗ではない。駒を飛び越えれば飛行機。戦闘の結果が勝敗表と合わない種類も消す。
「自分から攻めてきた駒は強い駒寄り」のような傾向は、弱い証拠として少しだけ反映する。
31枚の内訳は決まっているので、全体の枚数と矛盾しないように確率を調整する。飛行機が1枚確定すれば、ほかの駒の飛行機の確率は下がる。
その推定を使って全合法手を評価し、相手の応手まで読む2手読みで選ぶ。

機械学習ではなく、ルールと確率と評価関数の組み合わせです。最初の画面には、Seedと、CPUの配置の思想を選ぶボタンが並んでいます。

1.0.0の初期配置の画面です。自分の配置、CPUの配置、CPUの意思決定の乱数を別々のSeedで管理し、同じ配置のまま判断だけを変えて比べられるようにしました。CPUの配置は「いのちだいじに」「ガンガン行こうぜ！」など5種類の思想から決まります。

初対戦は、勝った。ただ、気になる動きがあった

さっそく対戦しました。

TURN 155で、こちらの大将が敵の総司令部に入り、勝ちました。自軍は残り3枚、敵は11枚残っています。撃破した敵駒の正体は、終局後も公開されません。

外部チャットに書いた感想は、これです。

まず相手の思考の印象。こちらの動きに対してアンドゥリドゥ的な動かし方が散見された。千日手嫌ってこちらが折れる感じ。地雷潰し要員と大将の特攻で勝てた感じ。初期配置はやはり重要

こちらが動くと、CPUが一歩動いてはまた戻る。同じ局面が続くのを嫌って、こちらが先に手を変える。初戦から、そういう場面がありました。

実はClaude Codeは、1.0.0の時点で「直前にいたマスへ戻る手」を少し減点する仕組みを入れていました。それでも往復は出ていたわけです。この話は、最終回でもう一度出てきます。

「勝利確定手」の先にあった地雷

次の対局では、思考モニターも開いてみました。

TURN 18のCPUの判断です。敵の駒#26が、こちらの総司令部にいる駒へ攻撃しました。採用理由は「敵総司令部を占領できる（勝利確定手）」、評価値は+7044です。

この#26は、それまでにこちらのタンク、工兵、大佐、少佐を次々に倒していました。CPUから見れば、自分の強い駒が総司令部の前にいて、その先の1枚を倒せば勝ちです。候補手の備考には、その戦闘の見積もりとして「勝70%」「分25%」と出ており、負ける見込みはわずかです。

総司令部にいたのは、こちらの地雷でした。地雷は飛行機と工兵以外とは相打ちになります。戦闘履歴の結果は「相打ち」。CPUの「勝利確定手」は、#26ごと消えました。

ルールの質問で「地雷を総司令部に置いてよい」を選んでいたので、成立した場面です。なお「勝利確定手」という表示は、勝てば総司令部を占領できる手の評価が一定以上になると出るもので、勝つことが確定していたわけではありません。CPUも25%の相打ちは見込んでいて、勝つ可能性の方が高いと判断して突っ込みました。実際に起きたのは、その相打ちの方でした。企画段階で言っていた「外したｗ」が、そのまま画面に出た形です。

どの程度当たっているのかも、数字で出ています。Claude Codeの自動テストでは、CPU同士の自動対局で動いたか戦ったことのある相手の駒について、終局時にCPUが本当の種類に割り当てていた確率は平均41.5%でした。これは正体を言い当てた割合ではなく、正解の種類にどれだけ確率を割り当てていたかの平均です。駒の枚数の比から計算した観測前の基準値7.0%から大きく上がっていて、観測から絞り込めていることが分かります。