第2回: 開発時のAI-Agent活用フロー

公開日: 2026-08-11 | 最終更新: 2026-08-11 | 読了目安: 11分

背景

ウェブ系のプログラミング経験が薄いこともあり、MadDrawの開発ではAI駆動開発に挑戦することにしました。ただ「AIに全部任せる」のではなく、まずルール決めから丁寧に進める方針を取りました。

最初の段階では、無料のGitHub Copilotや、XのアカウントについてきたGrokを使って壁打ちをしました。ゲームの面白さの理論（フロー理論など）を参照しながら、ルールを少しずつ固めていきました。

ルールの検討では、まずターゲット層を明確にしました。今回は「20〜30代で、流行ものが好きで、Discordで集まってパーティーゲームをする人たち」を想定しています。この層が実際にどう遊ぶかをイメージしながら、ルールのテンポや難易度を調整しました。

ルールがだいたい固まったところで、「どのような形で公開するのが一番望ましいのか」を議論しました。特に収益性と持続性についてはかなり時間をかけて検討しています。この点は別の記事でまとめる予定です。

最終的に「Firebase + React」を使い、広告収益モデルで進めることが決まりました。

タイトル決めにもAI-Agentをフル活用しました。特に英語での命名になるため、響きや意味の取り違えがないか、かなり気を使いました。複数の候補を出してもらい、ターゲット層に刺さりそうなものを選び、最終的にMadDrawという名前に落ち着いています。

実際の実装環境は GitHub Copilot Pro + VSCode です。ここからは、この組み合わせでの運用経験を中心に書きます。

最初は「決めたルールを渡して、あとは作ってもらう」というやり方を試しました。結果として、動かし方もよく分からず、コードの構造も理解できない状態になってしまいました。結局、作り直すことになりました。

この経験から、次のルールを自分に課しました。

「AIに任せる」前に「自分が理解する」ステップを入れるようにした、ということです。

実装の進め方は、概ね次のような流れでした。

後から知ったのですが、/plan コマンドを使えばもっとスムーズに計画を立てられたようです。当時はあまり知らなかったので、力業で進めた部分もあります。AGENTS.md のような仕組みをきちんと活用できれば、さらに効率が上がっただろうとも感じています。

それでも、実装プランを立ててくれたり、GitHub上にIssueを作ってマイルストーンを切って進めたりするあたりは、非常に心強いツールだと感じました。特に「何から手をつければいいか分からない」状態から抜け出す助けになりました。

使ってみて感じた得意・不得意があります。

得意：デザイン崩れの修正はかなり正確に直してくれます。レイアウトのズレやスタイルの不整合に対して、具体的な修正案を出してくれる印象です。
苦手・不安定：複雑なトランザクション管理はまだ不安定なところがあります。特に、Firebaseのコストを踏まえたアーキテクチャの検討には結構時間がかかりました。コスト構造を理解した上で設計を進める必要があり、ここは人間側の判断が重要でした。

ウェブサイトのデザイン自体は、もっと改善できる余地があると思っています。自分自身スキルがないので「良いデザインかどうか」の判断が難しいのが正直なところです。Design.md のような仕組みがあるらしいので、今後試してみたいと考えています。

個人的に一番気になったのは、バジェットがすぐに切れてしまうことです。モデル選択やプロンプトの書き方、どの作業をAIに任せてどこを自分でやるかなど、トークンを意識した運用をもう少しきちんと考える必要があると感じています。

今後は「どの作業にどのモデルを使うか」を意識して、コストと品質のバランスを取りたいと思っています。

経験が薄い分野でも、AIを「実装オペレーター」として使いながら、自分で設計を理解するプロセスを挟むことで、なんとか形にすることができました。完璧な使い方ではなかったと思いますが、「理解してから任せる」というルールは、今後も大事にしていきたいポイントです。

次回は、Gemini APIを判定処理に組み込む際の設計判断と、遅延時の扱いについてまとめます。