AIで開発している小さめのゲームのコードの文字数と、プロンプトの文字数を調べ、どれだけAIがコーデイングを効率化するかを考えてみました。

どんな手法でどんなゲームを作った？

エージェント型のAIで３割と単純なネットワーク型のバトルゲームをAIコーディングの研究も兼ねて作成しています。

下記のような流れで製作しました。

・ゲームの格子を伝え非常に単純な部分でゲームとして成り立つ最小限の構造をAIに作成依頼

・実装を確認

・※ゲームにアイテムや武器、ルールなどを短いプロンプトを積み重ねてAIに次から次に肉付けして実装させていく

・実装を確認・バグ修正(AIと人間のどちらも行う)

・ある程度進んだら長すぎるプログラムや整理されていないプログラムをクラス化するなどして分割リファクタリング(AIと人間のどちらも行う)

・実装を確認→※に戻る

といった感じです。

結論

プロンプトをすべて残しているのですが、プロンプトの文字数を調べると約１０万文字でした。

次にゲーム自体のコードの文字数を簡単に調べると、平均８千文字ほどのファイルが３０ファイルほどある為、約２４万文字程度という事が分かります。

この為プロンプトで作ると５０％以上の文字数が効率化されたことになります。

しかし開発期間は実際に効率化されたのか？

・確実に減った時間は下記のようになるかと考えられます

コードを考える時間、実際にコードを書く時間、ロジックを検討する時間、コードの書き方を等の新規技術を学ぶ時間、バグ修正(ただこれは人間が関与する必要がある場合も多く軽微な現象に思えます)、ドキュメント・コメント作成時間、Stack Overflow等で調べる時間

・逆に確実に増えた時間は下記のようになるかと存じます

プロンプトを考える・修正する時間、動作確認、AIが検討している待ち時間、コードの内容を一応読み理解する時間、リファクタリングの時間、レイアウトの調整、AIが修正できないバグを人間が調べて修正方針を考える時間、品質レビュー

はて、これは実際に効率化されているのでしょうか？私の感覚では効率化は最大６割、最小３割のレンジに収まるかと存じます。

確実に効率化は実感しますが、思うほど大きくはない感覚です。

研究データを参照して調べてみる

AIコーディングツールが急速に普及しています。――これらのツールを使えば、コードを書く速度が劇的に上がるとベンダーは謳っています。一方、現場のエンジニアの多くは「確かに速くなった気はするが、思ったほどでもない」という感覚を口にします。

この感覚は正しいのでしょうか。近年、この問いに正面から向き合った研究が相次いで発表されています。結論から言えば、「最大6割・最小3割の効率化」という現場感覚は、研究データと概ね一致しています。ただし、その内訳には重要な構造があります。

効率化の恩恵は「タスクの種類」で大きく変わる

研究データが一貫して示しているのは、AIによる効率化の効果がタスクの種類と開発者の経験レベルによって大きく異なるという点です。

  • 定型的なCRUDコード・ボイラープレート生成：50〜70%の時間削減も現実的
  • 中程度の複雑さを持つ機能開発：20〜40%程度の改善
  • 複雑なアーキテクチャ設計・難解なバグの調査：改善はほぼなく、むしろ検証コストで増える場合も
  • UIの細かいレイアウト調整・ドメイン固有ロジック：プロンプト設計のコストが高く、効果は限定的

「AIで開発が速くなった」という体感と「思ったほどでもない」という感覚が同時に存在するのは、この分散が原因です。定型作業は劇的に速くなる一方、複雑な判断を要するタスクでは効果が薄い――その平均をとると「3〜6割の効率化」という感覚になるわけです。

研究データが示す「何が速くなり、何が増えたのか」

GitHub CopilotのMIT共同研究（Pengら、2023年）では、AIツールを使った開発者は使わない開発者より55%速くタスクを完了しました。ANZ銀行での6週間の実験（Chatterjeeら）でも平均42.36%の短縮が確認されており、初心者（52.27%改善）ほど恩恵が大きい傾向があります。

ZoomInfoで400名超の開発者を対象にした調査では、Copilotの提案が受け入れられた割合はわずか33%でした。約2/3の提案は使えないか修正が必要であり、生成されたコードを「確認・取捨選択・修正する」コストが、思った以上にかかっているのが実態です。

「体感ほど速くない」のはなぜか

興味深いのは、開発者の自己評価と実測値の間にズレが生じやすい点です。AI安全性研究機関のMETRによる2025年の研究では、経験豊富な開発者がAIツールを使って実タスクに取り組んだところ、「20%速くなった」と自己評価したにもかかわらず、実測では逆に19%遅かったという結果が出ています。

これは「AIが生成したコードを見て達成感を得てしまう心理的バイアス」によるものと考えられています。AIが動くコードをすぐに出してくれるため、実際には検証・修正にかかっている時間を過小評価しやすいのです。

この研究は成熟したオープンソースプロジェクトでの複雑なタスクが対象であり、全ての開発状況に当てはまるわけではありません。しかし「AIのおかげで速くなった」という感覚は、実際よりも誇張されている可能性があるという点は、現場感覚を較正するうえで重要な示唆です。

組織全体で見ると効果が薄まる理由

個人レベルでは確実な効率化が起きていても、組織全体の生産性に反映されにくい構造的な理由があります。

コーディングが開発プロセスの最大ボトルネックでない場合、コーディング速度を上げても全体のスループットは改善しません。要件定義、コードレビュー、テスト、デプロイ、会議――ソフトウェア開発にはコーディング以外の無数のステップがあります。Stack Overflowの2025年開発者サーベイでは、AIツールの利用率が84%に達しているにもかかわらず、「生産性が大幅に向上した」と答えたのは16.3%に過ぎませんでした。

またGitClearの調査によれば、AIツールの普及に伴い、書かれてから2週間以内に破棄される「コードチャーン」が増加しています。AIが速くコードを生成する一方で、品質や一貫性の問題から後でまとめて作り直すケースが増えており、これが「速くなったはずなのに完成が早くならない」という現象の一因になっています。

それでもAIを使い続ける理由、そして正しい期待値

METRの研究チームは、純粋な生産性向上以外にもAIを使い続ける動機があることを指摘しています。「認知的負荷の軽減」「より楽しい体験」「将来のより高性能なツールへの習熟」がその代表例です。GitHubの調査では90%の開発者が「Copilotで仕事がより充実する」と回答しており、数値には表れない体験的な価値も確かに存在します。

また、経験の浅い開発者への効果は特に大きく、育成・教育コストの削減という文脈では明確な価値があります。

総じて言えば、AIコーディングツールによる効率化は「確実に存在するが、ベンダーが謳うほど大きくはない」というのが、現時点の研究データと現場感覚の共通した結論です。

まとめ：AIは「特定タスクの加速装置」として正しく使う

AIは開発全体を劇的に効率化する魔法の道具では現状無いようです。定型コード・調査・初稿作成といった作業を加速させる一方で、検証・理解・品質管理という新たなコストを生み出します。

現実的な向き合い方は、万能薬として期待するのではなく、「どのタスクで速くなり、どのタスクでは変わらないか（あるいは増えるか）」を自分のチームで把握し、使いどころを見極めることです。その認識を持って使うことで、AIツールの恩恵を最大限に引き出せるかと思います。

参考文献

 

関連記事:

  1. 無制限に無料でAIコーディング　VRAM 8GB のノートPCでQwen3 Coderを動かしてみる
    無制限に無料でAIコーディングできるオープンソースのモデルQwen3 Coder　をVRAM 8GB のノートPCで動かしてみてその実力を見てみたいと思います。 まずこちらの記事に従いOllamaを入れます。このソフトはローカルでChatGPTのような感じでLLMを動かすためのソフトです。...
  2. Stable Diffusionで思い通りの画像を生成するために学習データから理解する
    Stable Diffusionで思い通りの画像を生成するには、モデルがどのように学習されているかを理解することが近道です。この記事では、主要な学習データセットの構造を解説しながら、そこから導き出せるプロンプトのコツをまとめます。 学習データセットとは何か Stable Diffusionのような画像生成AIは、大量の「画像とテキストのペア」を使って学習します。モデルは「このテキストが入力されたとき、この画像に近いものを生成せよ」という対応関係を膨大なデータから学びます。つまり、学習データの特性がそのままプロンプトの効き方に直結するのです。...
  3. WAN 2.1の速度向上Self-Forcing とは何か？
    WAN 2.1（Wan-AI製）は、中国アリババグループ傘下の研究チームが開発・公開したオープンソースの動画生成AIモデルです。テキストから動画を生成するT2V（Text-to-Video）、画像から動画を生成するI2V（Image-to-Video）、動画編集など複数のタスクに対応しており、2025年初頭に公開されて以来、ComfyUI ユーザーを中心に急速に普及しました。 モデルの規模は 1.3B（13億パラメータ）...
  4. WindowsでVOICEVOXを使いPythonから日本語を話させる方法
    VOICEVOXとは？ VOICEVOXは、無料で使えるローカル動作の音声合成ソフトです。ずんだもん・四国めたん・春日部つむぎなど、個性豊かなキャラクターボイスを使って日本語テキストを音声に変換できます。 完全ローカル動作（インターネット不要） 商用・個人利用ともに無料（各キャラクターの利用規約要確認） REST...
  5. QwenImageEditPlusPipeline で 512px 画像が「ズームイン」される原因と修正方法
    HuggingFace の diffusers ライブラリに含まれる QwenImageEditPlusPipeline...
  6. LLMはなぜコードが書けるのか？現状・限界・リスク
    ChatGPTやClaude、GitHub CopilotなどのLLM（大規模言語モデル）が、プログラムコードをすらすら書く姿を見て「なぜ？」と思ったことはないでしょうか。また、実際に使ってみると「意外と使えない場面もある」と感じた方も多いはず。 この記事では、LLMがコードを書ける仕組みから、現在の実用レベル、エラーを防ぐ方法、そして将来の限界までを解説いたします。 なぜLLMはプログラムが書けるのか コードも「テキスト」だからです。...