Geminiと歩んだアプリ開発のリアル：効率化と「丸投げ」の罠
公開日: 2026年3月14日
生成AI、特にGeminiを活用したプログラミングは、開発スピードを劇的に向上させますが、決して「魔法の杖」ではありません。自身の開発経験から得た、AIと共存するための鉄則と、実際に直面した苦労をまとめました。
1. AI開発における「黄金律」
AIへの「丸投げ」は失敗への近道
「AIに丸投げして完成」というSNSで見かける景気の良い言葉は、現時点（特に無料版）では鵜呑みにすべきではありません。AIを「全自動プログラミング機」ではなく、「優秀だが、指示されたことしか見えない作業員」として扱うのが正解です。
- 分解して部品を作る： 大きなプログラムをいきなり作らせるのではなく、機能を最小単位に分解し、一つずつ部品を組み上げる。
- 「忘却」を前提にする： AIは文脈を読み取るのは得意ですが、やり取りが長くなると変数名やファイルパス、HTMLのクラス名などを驚くほどあっさり忘れます。
対策： 修正のたびに、現在のコード全体やHTML構造を渡し直して「現在のコンテキスト」を同期させることが不可欠です。
- 計算ミスを疑う： 複雑なロジックだけでなく、単純な計算すら間違えることがあります。テストデータを用意し、入力と期待される出力を明確に示す「ガードレール」が必要です。
- 仕上げは人間による「検閲」： 完成後のコードレビュー、特にセキュリティ面のチェックは人間が行うべきです。
求められるのは「技術的な俯瞰力」
文法を知らなくてもコードは書けますが、「システムがどのような技術で構成され、部品がどう組み合わさっているか」という設計知識は、以前にも増して重要になっています。
2. 実践記：馬券点数シミュレーター開発での苦闘
当サイトの「馬券点数シミュレーター」は、Geminiとの共同作業で開発しました。計算ロジック自体は単純な組み合わせ計算のため、数日で完成すると予想していましたが、実際は意外と苦戦を強いられました。
陥った「機能追加」の罠
最初は「単勝」から順に、一つずつ機能を実装させていきました。単体では正しく動くのですが、「3連単」などの複雑な券種に入った途端、システムが破綻しました。AIは「今の指示（3連単）を正しく動かすこと」に全力を出すあまり、以前に作った「単勝」や「馬連」との整合性を壊してしまったのです。
「共通化」の誘惑を断ち切る
Geminiは隙あらば「共通ロジックで汎用化しましょう」と提案してきます。一見スマートに見えますが、日本の馬券システムのように「マルチ」や「フォーメーション」といった特殊なルールが絡む場合、共通化が仇となり、バグの温床になります。
最終的に、私はAIの提案に反して「全券種を独立した処理として実装する」という力技を選択しました。この判断のように、AIにはできない「人間による軌道修正」が必要な場面は多くあります。
独自アイデアほど「AIの知識」は通用しない
「電卓」のような手垢のついたプログラムなら丸投げでも作れるでしょう。しかし、日本の競馬システムのような「特定のドメイン知識」が必要な分野では、LLMの学習データが不足しています。「面白いアイデア」や「ユニークなツール」ほど、AIの中に答えはありません。自分のアイデアを噛み砕き、部品の挙動を正確な日本語で定義する能力が不可欠です。
3. 結論：AIは「ライブラリ」である
現在、生成AIはプログラミング言語の「巨大なライブラリ」のような存在になりつつあります。
実装スピードは以前と比べ物になりませんが、「何を作るか」「どう組み合わせるか」「そのコードが正しいか」を判断する舵取り役は、依然として人間です。
プログラミング言語の文法を覚える必要性は減るかもしれませんが、技術的な構造への理解と、曖昧さを排除した「正確な言葉」で伝える力こそが、これからのエンジニアの武器になると確信しています。