【実録】Gemini API連携でアプリに魂を吹き込む！エラーの嵐を抜けて見えた「コックピットUI」
さて第二回のAIアプリ爆速開発記事。「Velocity English」の開発。
前回の記事ではモックまで作りました。
「前回の既存の英語アプリがしっくりこない？GeminiとClaude Codeで「自分専用」を爆速で形にする方法で作成したプロトタイプをベースに……本物のAIをつなげていきます」
「え？『ここからどうやって『本物のAI』と繋げればいいんだ？』だって？」
そんな悩みを持つ未来のエンジニア諸君、ようこそ。
難しいことは全くないから心配しなくていい。
今回は、英語学習アプリ『Velocity English』の開発フェーズ2「API連携とUI修正」の記録を公開する。429エラーで絶望し、空を見上げたこの日、コードの「ダイエット」で全てが解決した劇的な瞬間を共有しよう。
1. アプリに命を吹き込む：Gemini API (Google AI Studio) 取得フロー
まずは「脳」を手に入れるところからだ。Googleの最新AI「Gemini」は、Google AI Studioを使えば驚くほど簡単に、しかも無料で始められる。
APIキー取得の4ステップ
- Google AI Studioにログイン：Googleアカウントがあれば即座にエントリー可能。
- 利用規約に同意：未来の規約をチェックして進め。
- API Keyの発行：「Get API key」から「Create API key in new project」を選択。
- .envファイルで厳重管理：取得したキーは「銀行の暗号」と同じ。ローカルに保存でGitHubに生で晒すのはダメ絶対。
Python
# .env ファイルのイメージ
GEMINI_API_KEY=あなたのAPIキーをここに張り付ける2. 絶望の429と404：エラーとの死闘
取得したAPIキーをセットし、いざVelocity Englishアプリの「Generate」ボタンをポチッ……とした瞬間に現れたのは、真っ赤なエラーメッセージだった。
API Error: 429 You exceeded your current quota...API Error: 404 models/gemini-1.5-flash is not found...
なぜ動かない？エンジニアの仮説
エラー内容をかいつまんで説明すると以下の通り。
- 429エラー：無料枠の限界（Rate Limit）。アクセス集中によるリクエスト拒否だ。
- 404エラー：モデル名の指定ミス。
models/というプレフィックスが必要だったり、ライブラリのバージョンによって解釈が異なったりする「エンジニアあるある」の罠だ。
待て待て・・・どういうことだ？429はありうる。
世界中でアクセスが集中・・・。1分間のリクエスト数だけじゃなく、1日の合計リクエスト数（Daily Limit）でも制限がかかりやすいからエラーを掃いているという可能性はありうる。
つまりは時間をおいて試せばいいだけだが、念のため以前作った別のテストアプリで試すとリクエストが通る。
「・・・いや429も怪しいな・・・」
404についてはさらにあやしい。モデル名指定は間違ってないし、なんなら1.5以外も使えるようにコードを変えてみるも、やはり同じエラーを掃いていく。
「APIのベースURLとモデル名の組み合わせが、利用しているライブラリのバージョンと噛み合っていない？（404エラー）。だが組み合わせをいくら合わせてもエラーが解決しない・・・怪しいどころかおかしい。となると429エラーもアクセス過多によるリクエスト拒否というのは・・・。本来発生しないんじゃね？」
[関連記事] 【技術考察】コードは正しいのに4xxエラーが連発する「密結合」の罠
ここで一旦コーヒーブレイク。
「空は……遠いなぁ……」
そう呟いて5分間空を眺めた時、あることに気づいた。「・・・スパゲッティコードか？」
3. 600行のダイエット！「疎結合」リファクタリングで大逆転
当時の app.py は、UI、ロジック、データ処理がすべて一つのファイルに詰まった「密結合」な状態だった。これが処理の負荷を上げ、デバッグを困難にしていた。いわゆるスパゲッティコード。
経験則になるけど、pyファイルが巨大すぎるとその処理自体に負荷がかかったり、メモリを無駄に消費したりするからだ。
目安は何とも言えない。処理の内容によるが、俺は今のところ、多くても300行以内を心がけている。それでも人によっては200行と言ったりもするからこの辺りはアプリ開発の経験が多く必要になってくるだろう。
動かない原因がコードに在り！ということではなく、ファイルサイズや構造の複雑さによるリソース不足で動かない場合も十分に考えられる。
開発する上では１個のファイルのほうが楽ではあるんだけど、1つの巨大なファイルは、どこか1箇所壊れると全部止まる「密結合」な状態だから、AIにコードを書かせる時こそ、こまめに「疎結合」な構造に誘導するのが、デキるエンジニア。というわけで。
UI（見た目）、APIロジック（中身）、データ処理（保存など）で分けてリファクタリング。
機能を以下の3つに切り分けた。
- app.py：見た目（UI）担当
- core_logic.py：API連携・解析（中身）担当
- data_handler.py：保存・データ処理担当
結果……「よっしゃ動いた！！！」 構造を整理し、最新の安定版指定に書き換えた瞬間、AIからのレスポンスが爆速で返ってきた。音声入力ライブラリ（streamlit_mic_recorder）も追加し、ついに要件定義通りの「本物のアプリ」が誕生した。
4. UIの覚醒：相棒（AI）と描くコックピット
機能が動くと、今度は「見た目」の野暮ったさが気になり出す。
そこで俺の「相棒（Gemini）」に相談してみた。
俺：「なぁ相棒。一応完成したはしたけど・・・。このUI（アプリ操作画面）、かっこいいと思う？」
相棒：「最低限だね。この機能なら、もっとコックピット感を出した方がいい。」
そこで、そのコックピット感を出したイメージ画像（モックアップ）を生成してもらい、さらにイメージ画像を元に見た目の要件定義を整えていく。
ここで要件定義をやるのは、AIが生成した画像とはいえ、その精度が維持されてコーディングしてくれるとは限らないからだ。
要件定義をすることでさらに具体化して、精度の高いコーディングに繋がる。
背景にグリッドを引き、ステータスランプを配置し、フォントを調整する。AIと対話しながらデザインを清書していく過程は、まさに「未来の開発」そのものと言える。
🚀 アイデアがあるなら、今すぐ作ろう！
「完璧に理解してから」なんて言ってたら、AIのスピードには置いていかれる。 エラーが出たときは、確かに対処に困るだろう。どう考えても正しいはずなのに、今回のようにエラーを掃かれることは開発をしてれば日常茶飯事である。
今回は空を見上げ、やってきたことを振り返って、あり得る事実に着目して、コードを機能別で分割して事なきを得た。
これが不正解でも、AIに細かく聞きながらまた走ればいい。 君の頭の中は世界を変えるプロダクトを生み出す武器だ。
このアプリについては2日で作っているが、実は工数で言えば5時間かかっていない。
たったそれだけで作れるのだから、想い描いたアイデアは行動に移して即座に形にすべきだ。
