私がソフトウェア開発者になった最大の理由は、子供の頃にビデオゲームが大好きだったからです。数え切れないほどの時間をゲームに費やし、それがどのように作られているのかに深く興味を持っていました。父はテレビやコンピューターの仕組みについて一生懸命説明してくれましたが、当時は全く頭に入ってきませんでした。
10代になってようやくインターネットにアクセスできるようになり、少しずつ理解できるようになりました。普通の10代の若者がチャットルームに入り浸り、ICQで友達を追いかけ、Orkutのプロフィール作りに熱中している間、私はゲーム開発のチュートリアルを調べていました。本当に良い時代でしたね。
年月は流れ、私がプロのゲーム開発者になることはありませんでした。私のキャリアは、データベース、データエンジニアリング、バックエンドサービス、そしてクラウドの方向へと進みました。自分の選択を後悔はしていません。それでも、時々「自分のインディーゲームを作ったらどんな気分だろう」と想像することがあります。
でも、どうでしょう？エージェンティック・コーディングの台頭により、ゲームを含む複雑なアプリケーションの構築は非常に身近なものになり、もう想像だけで終わらせる必要はなくなりました。これからお見せするように、私たちは今日、完全に機能し、クラウドにデプロイされたゲームを作ることができるのです。
この記事の読み方には2つの道があります。1つは、GenAIを試してみたいと考えているゲーム開発者志望の方として。もう1つは、新しいエージェンティック・コーディングのスキルを楽しく学ぶためにゲーム開発を活用するプロの開発者としてです。どちらの道を選ぶにしても、この記事の中で、Gemini CLIの2つの特定の機能、つまりプランモードとサブエージェントについて紹介します。でもその前に、少し技術的な話をしましょう。
プロジェクトに最適な技術を選ぶ方法#
これは、あらゆるソフトウェアチームにおいて常に重要な決定事項です。使い慣れたツールを使うべきか？新しい市場のトレンドに従うべきか？自社で構築するべきか？大企業は通常、すでに知っているツールに固執します。変更を正当化するには、非常に説得力のある理由が必要です。その理由は、市場コストの変動や利用可能な人材の不足など、外部からやってくるかもしれません。あるいは、新しいスタックをサポートするためにチームを再教育するコストが高いなど、内部から生じるかもしれません。
エージェンティック・コーディングは、この力学を完全に変えてしまいます。AIがボイラープレートを処理してくれるため、今日ではプログラミング言語の選択は、システム全体のアーキテクチャに比べればずっと重要ではなくなっています。私たち開発者にとって、これは大きな安堵です。新しい構文を学ぶために何ヶ月も費やすことなく、問題に合わせて技術スタックを切り替えることができます。
言語の重要性が失われたら何が残るのか、疑問に思うかもしれません。私の答えは「パターン」です。サイロとしてではなく、システムの集合体としてソフトウェアを構成する方法です。これはマクロ（システム設計）とミクロ（プログラム設計）の両方のレベルで機能します。コードの1行1行が何をしているかを知る必要はありませんが、ソフトウェアのさまざまな部分がどのように相互作用するかは知っておく必要があり、また、エージェントを正しい実装の方向へと導く方法も知っておく必要があります。
ということは、すべてをBASICで書いていた時代に戻れるということでしょうか？いいえ、違います。なぜなら、言語の選択は単独で行われるものではないからです。言語は、特定の機能のセットと全体的なエコシステムをもたらします。私たちは、達成しようとしていることに最も適した技術を選ばざるを得ないのです。もはや重要ではない唯一のことは、チームがそのソフトウェアを書く能力があるかどうかということです。これは、チームに強力なソフトウェアエンジニアリングの基礎さえあれば、最新のコーディングエージェントを使って簡単に補うことができます。
ある基準が時代遅れになる一方で、新しい基準が現れます。今回の場合、対象となる言語において、コーディングエージェントがどれだけ高品質なソフトウェアを簡単に生成できるかに細心の注意を払うことになります。
この特定のプロジェクトにおいて、私は主に2つの理由からGoを選びました。1つは、コーディングエージェントがうまく扱える軽量な言語であること（私のgodoctor MCPも役立っています！）、もう1つは、Ebitengineを中心とした成熟したオープンソースのゲーム開発エコシステムがあることです。
これをThree.jsで行うことはできたでしょうか？はい、できました。しかし、私はどうしてもコンソールやアーケードゲームの体験にできる限り近づけたかったので、コンパイルされたゲームであることが必須条件でした。また、私が気にするのは2Dだけなので、UnityやUnrealのような大規模なエンジンは必要ありません。最後に、EbitengineにはNintendo Store（Nintendo Switch向け）で公開されている商用ゲームがあり、これが「いつかゲームを公開したい（もちろん、このゲームではありませんが）」という私の夢を膨らませてくれるのです。
Goの強みについて少しお話ししましょう。コンパイル言語であることは、開発プロセスの早い段階で多くのエラーをキャッチするのに役立ちます。Pythonにも同様のゲーム開発機能がありますが、インタープリタ型であるため、テストサイクルが遅くなります。さらに、Goはローカルマシン向けにネイティブコンパイルすることも、Web向けにWebAssembly（WASM）としてコンパイルすることもできます。これはつまり、少しの変更を加えるだけで、自分のゲームをWebサービスとしてデプロイできるということです。
ソフトウェアアナリストの帰還#
エージェントがGoコードの記述や、サーバーとWASMバイナリのコンパイルといった重労働をこなしてくれる一方で、私たちには設計に関する厳密な責任が依然として残されています。
ソフトウェアエンジニアリングは変化しています。私たちは巧妙な構文について悩む時間を減らし、よりハイレベルなパターンについて考えることに多くの時間を費やすようになっています。
ある意味では、昔ながらの「ソフトウェアアナリスト」の時代に戻ったような気がします。コードを1行1行手書きするのではなく、人間の要件を正確な指示のセットに翻訳し、AIが実際のコードを書けるようにすることが私たちの主な仕事になるのです。
私自身にはゲーム開発の経験があるわけではありませんが、ゲーマーであり愛好家として、自分のゲームで達成したいことを説明するために使われるドメイン言語には精通しています。特定のキーワード（例えば、アーケードゲーム、マッチ3など）をプロンプトのベースにしたり、よく知られた例（例えば、「16ビットや32ビット世代のパズルゲームにインスパイアされつつ、モダンなひねりを加えたトラックが必要」など）を使用したりすることで、ゲーム経験が全くない人がゲームを作ろうとするよりも、はるかにうまくエージェントに意図を伝えることができます。
要点を強調するためにここに記しておきます。たとえコーディング自体が副次的なスキルになったとしても、パターンや機能を説明する能力は、依然として不可欠なソフトウェアエンジニアリングのスキルです。バックエンドであれ、フロントエンドであれ、あるいはその間にある何であれ、自分の分野のドメイン言語を知っておく必要があります。
プランモードを使った設計から実装への移行#
ドメイン言語は出発点ですが、完璧なワンショットのプロンプトを書くことはめったにできません。Developer Relationsとして、私たちはデモやプレゼンテーションでワンショットプロンプトを常に使用していますが、私たちが普段語らないのは、それを公開できるようになるまでに、どれだけの時間を費やしてそのプロンプトを洗練させているかということです。
完璧なプロンプトを作成することはアートとサイエンスの融合であり、ドメイン言語を深く理解していたとしても、必ずギャップは生じます。幸いなことに、デモやプレゼンテーションの世界の外では、すべてをワンショットで済ませる必要はありません。また、エージェントもプロンプト作成を手伝ってくれるので、自分一人で取り組む必要もありません。ここで役立つのがプランモードです。
プランモードでは、Gemini CLIはコードを書く前に、まず実装計画を練り上げます。これにより、エージェントとやり取りをする機会が生まれ、計画を洗練させ、実装が望む方向に進んでいることを確認できるようになります。
エージェントとの通常の会話の中で、会話の流れに基づいてプランモードに入るよう求められることがあります（例えば、「計画を立てよう」というフレーズが含まれるプロンプトに対する応答など）。しかし、プランモードに入るタイミングの判断をエージェントに頼りたくない場合は、いつでも/planコマンドを使って手動で切り替えることができます。
プランモードでは、エージェントはあなたのリクエストに基づいて実装計画を練るだけでなく、ask_userツールを使って1つ以上の明確化のための質問をしてくることもあります。計画の準備ができると、レビューを求められ、前提条件の修正や機能の追加・削除など、あらゆる方向に計画を修正する機会が与えられます。
例えば、私のマッチ3ゲーム向けの、かなり洗練されてはいるものの完璧には程遠いプロンプトを以下に示します。
Build a Match-3 game called 'Cloud Crush' in Go using Ebitengine v2.
The entire game screen should have background.png as background.
The play area should be an 8x8 grid with white background.
On the right side of the play area include a side panel with UI elements
like player score and how to play instructions.
The side panel should have a solid background colour to help with readability of the UI.
Use standard GCP product logos (e.g. Compute Engine, Cloud Storage, BigQuery, etc.)
as the game gems. These logos are provided in the gcp_sprites.png file.
The logos are saved as 64x64 sprites but scale them as necessary
based on the screen resolution. Implement swapping, clearing 3+ gems, and gravity.
Use ebitengine native font rendering (size 48 for titles and size
24 for normal text) for all text and not the debug print.
The font should be monospaced (golang.org/x/image/font/gofont/gomono).
Keep the UI tidy and harmonic, e.g. centered text should always be
adjusted based on text length, not just guess based on estimates.このプロンプトはゲームの多くの側面をカバーしていますが、エージェントが「画面解像度はどうすべきか」や「アニメーションはスムーズなものがいいか、それとも静的なものがいいか」など、さらなる詳細を尋ねてくるのはよくあることです。
計画の詳細レベルに満足したら、エージェントにビルドの開始を指示することができ、これによってプランモードは終了します。この部分は、一般的なコーディング作業と何ら変わりません。何度かやり取りを重ねると、次のように動作するゲームができあがります。
ブラウザエージェントによるWebテストの自動化#
ゲーム開発で最も難しいことの1つがテストです。考えられるすべてのゲーム状態を検証したり、レンダリング関数が正しい要素を画面に描画しているかどうかを確認したりするための、標準的なユニットテストを書くことはできません。試みることはできるかもしれませんが、それが退屈で壊れやすく、時間のかかるプロセスになることは保証します。
これは自動テストを一切書くべきではないということではなく、純粋なコードで行うべきことと、人間によるプレイテストが必要なことの間には限界があるということです。例えば、衝突判定や経路探索のようなアルゴリズムのユニットテストは問題ないと思いますが、異なる解像度にわたってUIを検証することは、人間が行った方が良いかもしれません（例えば、「このフォントは読みやすいか？」ということをどうやってユニットテストするのでしょうか）。
あるいは、少なくともこれまではそうでした… サブエージェントがチャットに参加しました
最先端モデルのマルチモーダル機能とエージェントの賢い使い方により、視覚的な検証を自動化することが実際に可能になります。Gemini CLIにおいて、サブエージェントはメインの会話とは独立して独自のコンテキストウィンドウで実行される特化したペルソナです。サブエージェントは、基本的なコーディングワークフローにあらゆる種類の機能を追加するために使用できます。
今回のテストシナリオでは、CLIに同梱されている@browser_agentという実験的なエージェントを使用できます。これは実験的な機能であるため、settings.jsonファイルを編集して手動で有効にする必要があります。例えば、以下はブラウザエージェントをビジュアルモデルとともに有効にする最小限のsettings.jsonです。
{
"agents": {
"overrides": {
"browser_agent": {
"enabled": true
}
},
"browser": {
"visualModel": "gemini-2.5-computer-use-preview-10-2025"
}
}
}通常、ブラウザエージェントは、スクリーンリーダーが使用する隠された構造であるアクセシビリティツリーを読み取ることでWebページをナビゲートします。しかし、私たちのマッチ3ゲームはすべて単一のHTMLキャンバス上に描画されます。アクセシビリティツリーにとっては、巨大な空白の箱にしか見えません。
ここで、ビジョンモデルを追加することが状況を一変させます。エージェントにvisualModel（例えばgemini-2.5-computer-use-preview-10-2025など）を設定することで、エージェントは文字通り「見る」ことを学びます。スクリーンショットを撮り、視覚的なレイアウトを分析し、画面上でクリックすべき正確なX座標とY座標を見つけ出します。
デプロイされたCloud Runアプリケーションを手動でクリックする代わりに、@browser_agent please test the live URL... と入力するだけで、サイトをナビゲートし、ゲームを1ラウンドプレイし、動作している画面のスクリーンショットを撮るように指示できます。
これはゲームの操作感を確認するための人間によるプレイテストの代わりにはなりませんが、ターミナルから離れることなくUIが正しくレンダリングされることを証明する視覚的な検証を自動化してくれます。
セキュリティの不安をアウトソーシングする#
実装が機能し、UIの検証も終わったら、セキュリティのことを忘れてはいけません。
私はアプリケーションセキュリティの専門家ではないので、Webアプリのセキュリティ態勢を評価する適任者ではありません。しかし、エージェンティック・コーディングがゲームエンジンの経験不足を補ってくれたように、サブエージェントは私のセキュリティに関する専門知識の不足を補ってくれます。オーケストレーターとして、すべてのクロスサイトスクリプティングの攻撃ベクターを知る必要はありません。クリーンなコンテキストを持つスペシャリストを立ち上げて、それらを探す方法さえ知っていればよいのです。
Markdownファイル（.gemini/agents/security-auditor.md）でカスタムエージェントを定義することで、隔離された実行環境を作成し、@security_auditorを使って呼び出すことができます。
---
name: security_auditor
description: Specialized in finding security vulnerabilities in code.
kind: local
tools:
- read_file
- grep_search
model: gemini-3-flash-preview
temperature: 0.2
max_turns: 10
---
You are a ruthless Security Auditor. Your job is to analyze code for potential
vulnerabilities.
Focus on:
1. SQL Injection
2. XSS (Cross-Site Scripting)
3. Hardcoded credentials
4. Unsafe file operations
When you find a vulnerability, explain it clearly and suggest a fix. Do not fix
it yourself; just report it.特定のシステムプロンプト（Markdownファイルの本文）と、read_fileやgrep_searchといったツール（フロントマターで定義）を与えます。これらは独自のコンテキストループで実行されるため、メインの会話履歴を乱すことはありません。
私はこの監査エージェントを Cloud Crush のコードベースに向け、ハードコードされた認証情報、安全でないファイル操作、デプロイメントのリスクがないかチェックさせました。たとえカスタムのセキュリティエージェントが専門のプロフェッショナルに取って代わるものではなくても、自分だけでは欠けてしまう基本的な防御の層を提供してくれます。
新しい開発ワークフロー#
このワークフローは、私が考えるソフトウェア開発の新しい標準を定義するものです。私たちはエージェントを使ってコードを書き、アーキテクチャや品質の基準を適用するために、カスタムツール、スキル、サブエージェントを積極的に構築しています。
そして、注意深い読者の皆さんは、この記事で段階的な手順の説明を意図的に少なめにしていることにお気づきかもしれません。それは、この体験に特化したCodelab全体が用意されており、以下のリンクからアクセスできるからです。このCodelabでは、段階的な指示に従いながら、この記事で議論されたすべてをテストし、最終的にあなた自身のバージョンのマッチ3ゲームを構築することができます。
Codelab: Gemini CLIでマッチ3アーケードゲームを作ろう
もちろん、質問があればいつでも私のSNSでお気軽に声をかけてください。
