はじめに――この記事で一番伝えたいこと
最初に結論からお話しします。
Unityで外部APIと連携するゲームを作るのは、順番さえ間違えなければ、AIを相棒にしてかなり現実的に進められます。
「そんな簡単にいくの？」と思いますよね。もちろん簡単ではありません。ただ、難しくなる原因のほとんどは、技術力の不足ではなく「進める順番の間違い」にあるんです。今回の記事では、その順番を具体的にお伝えします。
この記事はどんな人に向けているのか
まず、この記事の対象をはっきりさせておきます。
Unityの基本操作がわかり、C#のコードをある程度読める方。APIやOAuth（外部サービスへのログイン認証の仕組みのことです）に興味はあるけれど、それをゲームに組み込むとなると不安がある。AIを使って開発を速くしたいけれど、全部を丸投げするのではなく現実的に活用したい。そういった方を想定しています。
逆に、完全なUnity初心者向けではありません。OAuthの仕組みを一から解説する記事でもありません。あくまで「Unityと外部APIの連携を、AIと一緒にどう進めるか」が主題です。
まず、最終的にできたことをお見せします
今回、最終的にどこまでたどり着いたのか。先にお見せしておきます。
Unityで「タイトル → ユニット選択 → バトル → 結果」という一連の画面遷移を作りました。最初は仮のデータだけでゲームとして1周回る状態にして、そこにAsset Storeの素材を安全に取り込んで見た目と音を整えました。それと並行して、ブレヒロAPI用の認証サーバーを自分のPC上に別で構築し、ブレヒロOAuthのログインを成功させ、所持ユニット一覧の取得まで通しました。最後に、Unity側のユニット選択画面に本物のデータを反映させるところまで到達しています。
ここで注目してほしいのは、「ゲーム本体を先に作り、そのあとで本物のAPIを接続した」という順番です。実は、この順番こそが今回うまくいった最大の理由なんです。
そもそも、なぜ最初にAPIから始めてはいけないのか
ここが今回の話の中で一番大事なところです。
外部APIを使うゲームを作ろうとすると、多くの人はこう考えます。「せっかくだから最初からAPIをつないで、本物のデータで開発しよう」と。気持ちはよくわかります。でも、これをやると、ほぼ確実に行き詰まるんです。
なぜか。具体的に説明します。
Unityの画面設計、ゲームの仕組み、API通信、OAuth認証、データ反映。これらを同時に進めたとしましょう。ある日、ユニットが画面に表示されなくなった。さて、原因は何でしょうか。OAuthの認証が通っていないのか。APIは通っているけれどデータの形式が違うのか。Unity側でデータの変換に失敗しているのか。そもそも画面表示の部品が壊れているのか。これが全部同時に起こりうるんです。
お医者さんに行って「頭も胃もひざも全部痛いです」と言ったら、お医者さんも困りますよね。まず一つずつ診ないと原因がわからない。ソフトウェア開発もまったく同じです。
だから今回は、こういう順番にしました。まずAPIを使わず仮のデータだけでゲームを作る。ゲームの流れが1周回ることを確認する。そのあとAPI側を別のプロジェクトで作る。最後にUnityに差し込む。この手順なら、問題が起きても「どこが悪いか」をすぐ特定できるんです。
Unity側の最小ゲームはこう作った
では、具体的にどう進めたかをお話しします。
まずUnityで作ったのは、物理アクションの簡易ゲームです。タイトル画面があって、ユニットを3体選んで、バトルで順番に引っ張って飛ばして、敵にぶつけて、勝敗が決まって結果画面に進む。この時点ではAPIはつながっていません。ユニットも全部仮のデータです。
「仮データで作って意味あるの？」と思うかもしれません。ここがポイントなんです。ゲームとしての操作感を先に作っておくと、後からAPIを組み込んでも設計が崩れにくくなります。家を建てるとき、家具を先に全部買ってから設計図を引く人はいませんよね。まず骨組みを作って、あとから中身を入れ替える。それと同じ考え方です。
進め方の具体的な流れ
プロジェクト作成時のテンプレートはUniversal 2Dを選びました。今回のゲームが2D物理アクションだからです。
最初に作ったのは、TitleScene、UnitSelectScene、BattleScene、ResultSceneという4つの画面の遷移だけ。まず「画面が順番に切り替わる」という骨組みを固めたわけです。タイトル画面はタイトル文字とStartボタンだけ。ユニット選択画面は最初は仮の3体分で、後から6属性まで拡張しました。
バトル画面は最初「飛ぶ」だけの動きから始めて、そこに壁反射、ターン制、敵のHP、自分のHP、勝敗判定、効果音、BGM、演出を一つずつ足していきました。大事なのは、最初から完成形を目指さなかったことです。常に動く状態を保ちながら、少しずつ育てていく。この進め方が安定につながりました。
AIにはどう指示を出せばいいのか
さて、ここからはAIの使い方についてお話しします。ここは誤解が多いところなんです。
AIは確かに便利です。でも「全部作って」と大雑把に投げると、たいていの場合まともに動かないコードが出てきます。では、どうすればいいのか。
うまくいったやり方をお伝えします。まずAIに「作るファイル」「画面の構成」「最初にやる一つの作業」だけを提案させます。そして、その一つの作業だけを実装させます。一回の変更は小さく保ちます。コンパイル（プログラムを動く形に変換する処理のことです）が通らないコードは出させません。そしてUnity Editor上での最終確認は必ず自分でやります。
ここで大事な考え方があります。AIは「何でもやってくれる万能の職人」ではなく、「指示を出せば正確に動く、非常に優秀な共同開発者」として扱うということです。
会社で考えてみてください。新しく入った優秀なメンバーに「このゲーム全部作っておいて」と丸投げする人はいませんよね。「まず画面遷移の部分だけ作ってもらえますか」と具体的に頼むはずです。仕事を分けて渡すから、相手も力を発揮できる。AIも同じなんです。
Asset Storeの素材で「やってはいけないこと」がある
ここで、多くの人が見落としがちな落とし穴についてお話しします。
Asset Storeには便利な素材がたくさんあります。しかし、テンプレート型の大きなアセットを、動いている本体プロジェクトにそのまま入れるのは危険なんです。
なぜか。そういった大きなアセットは、素材だけではなく、プロジェクト全体の設定、入力の仕組み、描画の設定、デモ用の画面、各種管理プログラムまで一緒に持ち込んでしまうことがあるんです。すると、せっかく動いていた本体のゲームが壊れる。これは本当によくある事故です。
では、どうすればいいか。今回やった方法はこうです。本体プロジェクトとは別に「AssetSandbox」という検証用のプロジェクトを作ります。そこに大きなアセットを入れて中身を確認し、必要な部品だけを本体に持っていく。テンプレート全体を使うのではなく、部品だけを移植する。この考え方が非常に有効でした。
TopDown Engineの正しい使い方
今回検証したTopDown Engineについても触れておきます。これは単なる見た目の素材集ではありません。見下ろし型ゲームを作るための開発の骨組みそのものです。キャラクター制御、武器、AI、カメラ、画面表示、音の管理など、ゲームの根幹がかなり含まれています。
つまり、TopDown Engineを使うなら「見下ろし型ゲームを丸ごと作る」という前提で活かすべきなんです。今回のような「引っ張って飛ばす物理アクション」の核心部分に無理やり使おうとすると、仕組みが合わない。
そこで今回は、TopDown Engineの仕組みそのものは使わず、UI部品、背景、視覚効果、音、一部の素材だけを流用しました。仕組み全体を無理に使うより、使えるところだけ使う方がはるかに安全です。
ブレヒロAPIの連携は、なぜ別プロジェクトにしたのか
さて、ここからはAPI連携の話に入ります。
実は、もともとブレヒロAPIを使ったブラウザゲームが、すでに公開されている状態にありました。「それをそのまま流用すればいいのでは？」と考えるのは自然です。でも、今回はあえてその方針を取りませんでした。
理由は3つあります。公開中のアプリに影響を出したくないこと。Unityとブラウザでは認証の流れが異なること。ブラウザ前提の設計をそのままUnityに持ち込むと扱いづらくなること。
ここで一つ、開発における大事な考え方をお伝えします。「コードをそのまま流用する」よりも「設計の考え方を流用する」方が成功しやすい。今回も、考え方は活かしつつ、Unity向けのAPI中継サーバーは新しく作りました。
最初にローカル環境でやる理由
「ローカル環境」というのは、自分のPC上で動かすことです。最初から公開サーバーに上げて試したくなりますが、それはおすすめしません。
なぜかというと、公開環境まで含めてしまうと、問題の原因が一気に増えるからです。サーバーの設定ミスなのか、認証の戻り先の設定ミスなのか、自分のコードの不具合なのか、Unity側の通信ミスなのか。全部が混ざって、どこが悪いかわからなくなります。
だから今回は、まず自分のPC上に認証サーバーを作って、ブレヒロOAuthのログインを通すところから始めました。先ほどの「一つずつ問題を切り分ける」という原則を、ここでも徹底したわけです。
OAuthアプリは用途ごとに分けるべき
もう一つ大事な点があります。ブレヒロのDeveloper Portal（開発者向けの管理画面です）上では、今回のUnity用ローカル開発のために、別のOAuthアプリを新しく作りました。
既存の公開ブラウザ用アプリをそのまま流用しなかったのは、設定が衝突するのを避けるためです。認証の戻り先、通信の許可設定、ローカル環境用の設定。これらが本番アプリと混ざると、どちらも動かなくなる危険があります。ローカル開発用と本番用は分ける。これは必須の判断です。
絶対にやってはいけないこと――Unityにclient secretを入れる
ここで、外部API連携において最も重要な注意点をお話しします。
client_secret（APIの秘密鍵です）は、Unityのアプリ側に絶対に入れてはいけません。なぜなら、完成したアプリのファイルを解析すれば、中に埋め込まれた秘密鍵を抜き取れる可能性があるからです。秘密鍵が漏れれば、第三者がそのAPIを悪用できてしまいます。
銀行の暗証番号をキャッシュカードに油性ペンで書いている人がいたら、「それは絶対にやめてください」と言いますよね。Unityアプリにclient_secretを入れるというのは、それと同じくらい危険なことなんです。
だから今回は、こういう構成にしました。Unityは中継サーバーにアクセスする。中継サーバーがブレヒロOAuthとブレヒロAPIのやりとりを担当する。Unityは最終的に必要なデータだけを受け取る。この分離があるから、安全で、しかも後から手直ししやすい構成になったわけです。
UnityとOAuthはこうつないだ
では、実際にUnityとOAuthの認証をどうつないだのか。ここも工夫したポイントです。
今回は、Unityにブラウザのセッション情報（ログイン状態を保持するための情報です）をそのまま持たせませんでした。代わりに、こういう流れにしています。
まずUnityが中継の仕組みを起動します。次に、外部ブラウザでブレヒロへのログインを行います。ログインが完了すると、サーバー側でUnity専用の短い有効期限つきの認証情報を発行します。Unityはその認証情報を使って、ユニット一覧を取得するAPIを叩く。
この仕組みにすると、Unity側は非常にシンプルになります。ログインの複雑な処理はブラウザに任せて、Unity自身は認証情報を受け取ってAPIを叩くだけ。将来スマートフォンに展開することを考えても、この設計は理にかなっています。
Unity側で変えたのは、実はユニット選択画面だけ
ここ、驚くポイントかもしれません。
APIを接続した際に、ゲーム全体を作り直す必要はありませんでした。もともと仮データ版で、ユニット選択画面、バトル画面、結果画面はすべてできていたからです。
差し替えたのはユニット選択画面だけ。仮の6属性ユニットを表示していた部分を、APIから取得した本物の所持ユニット一覧に置き換えて、選んだ3体はそのまま既存のバトルに渡した。たったそれだけです。
この形にしたことで、ゲームの仕組みとAPIの仕組みがきれいに分かれた状態を保てました。これこそが、最初に仮データでゲームを完成させておく最大の利点なんです。「差し込み口」を先に作っておけば、後から本物を入れるのは簡単になる。
AIを使って本当に良かったこと
今回AIを使って最も効果が高かったのは、「設計を壊さずに、小さい単位で前に進められた」ことです。
具体的には、ファイル構成の提案、画面構成の提案、小さな作業単位でのC#実装、エラー原因の切り分け、API中継サーバーの設計、リスクのある作業を避けるための方針整理。こうした場面でAIは力を発揮しました。
たとえば「公開中のブラウザ版に影響を出さないように、Unity専用のAPIを新しく作った方がいい」という方針判断を整理する際に、AIは非常に役に立ちました。コードを書くだけがAIの仕事ではありません。開発の進め方そのものを整理する相談相手としても、AIは強い。これは今回の大きな発見でした。
AIを使って危なかったこと
もちろん、AIにも限界はあります。正直にお話しします。
まず、Unityの入力システムに関する問題がありました。ドラッグ操作が効かなかった原因が、古い入力方式ではなく新しい入力システム側の設定にあったんです。これはUnity特有の落とし穴で、AIだけでは気づきにくい問題でした。
次に、2D物理まわりの仕様変更です。物理演算の部品であるRigidbody2Dの仕様が変わっていて、エラーが発生しました。こうしたUnity内部の変更は、AIが常に最新情報を把握しているとは限りません。
さらに、先ほどお話しした大型アセットを本体に直接入れるリスクも、AIが自発的に「それは危ないですよ」と止めてくれるわけではありません。
つまり、こういうことです。AIは優秀な相棒だけれど、Unity固有の落とし穴は最終的に人間が確認する必要がある。これは忘れてはいけない点です。
うまくいった理由は、突き詰めると3つ
ここまでお話ししてきたことを振り返ると、今回うまくいった理由は3つに集約されます。
第一に、問題を分割したこと。ゲーム本体、素材、API、OAuth認証。これらをそれぞれ別にして進めました。同時にやらないから、問題が起きたときに原因を特定できる。
第二に、仮データを先に作ったこと。いきなり本物のAPIに接続しなかった。仮データでゲームが1周回ることを先に確認したから、後でAPIを入れるときに変更箇所を最小限にできた。
第三に、AIに一度に大きすぎる仕事をさせなかったこと。「最初の一つの作業だけ実装」という形で進めた。開発が難しくなるのは、たいてい「全部を同時に進める」からです。順番を守るだけで、難易度はかなり下がります。
これから始める人への、おすすめの手順
もしこの記事を読んで「自分もやってみたい」と思った方のために、おすすめの手順をまとめます。
まず、Unityで仮データのタイトル、選択、バトル、結果画面を作り、ゲームとして1周回る状態にしてください。動いている状態は必ず保存しておきます。次に、Asset Storeの素材は別の検証用プロジェクトで試してから、必要な部品だけ本体に持ち込みます。そしてOAuthとAPIは別プロジェクトで、まず自分のPC上で動く状態にします。セッション確認とユニット一覧の取得が通ることを確認してください。最後に、Unityのユニット選択画面だけを本物のデータに差し替えます。
この順番で進めると、行き詰まる確率がかなり下がります。
まとめ
Cursor、Codex、GPT系AIを使ってUnity開発を進めることは、十分に可能です。ブレヒロAPIのような外部OAuth/API連携まで含めても、手順さえ正しければかなり現実的に進められます。
ただし、大事なのは「AIに全部やらせること」ではありません。本当に重要なのは、先に仮データでゲームを完成させること。APIは別で切り分けること。素材は検証用プロジェクトで扱うこと。AIには小さな作業単位で依頼すること。この順番を守ることです。
今回の開発を通じてわかったのは、AIは何でも自動化してくれる魔法の道具ではなく、開発を壊さず前に進めるための非常に優秀な相棒だということでした。
これからUnityで外部APIを使ったゲームを作ってみたいなら、まずは本記事の流れ通りに「仮データ → 自分のPC上でAPI構築 → Unity差し替え」で進めてみてください。それが最も安全で、最も再現性の高いやり方です。