【TubeLingo開発記】AIに「それが最善ですか？」と問い詰めたら、見事な手のひら返しをされた件 〜マイク自動オフの泥沼と3つの教訓〜

「いや、それ最初から言ってよ！！！」

深夜の自室で、思わずPC画面に向かって叫んでしまいました。 こんにちは！TubeLingo（チューブリンゴ）開発奮闘中の開発チームです。プログラミングほぼ未経験からAIとペアプログラミングを始めて約1ヶ月。今日は、まさに「AI開発あるある」の泥沼にハマり、そしてそこから自力で這い上がった（？）時の、笑いあり、涙あり、学びありの開発記録をお届けします。

事の発端は、TubeLingoの「自動マイクオフ機能」の改善でした。明示的にオフにしないとマイクが絶対に止まらないという状態だったため、いつものように私の相棒である ** 「Geminiリードエンジニア」 ** に泣きつき、コードを修正してもらいました。

ちなみに、彼（Geminiリードエンジニア）は私がGeminiのカスタマイズ機能を使って独自に生み出した、TubeLingo開発専属のAIアシスタントです。例えるなら、履歴書に「何でも完璧にこなします！」と書いている、超優秀だけど少し融通が利かない新入社員。「コーヒーを淹れて」と頼むと、豆の産地選びから始めようとするタイプです。

彼の修正のおかげで、マイクは無事に止まるようになりました。しかし、意気揚々とテスト環境にデプロイしてみると、新たなモンスターが誕生していたのです。

「g...go...good...good morning」

なぜか、音声認識された文字が何度も重複して繰り返される「繰り文字」バグが発生。ここから、私とGeminiの終わりのない泥沼の修正作業が幕を開けました。

「文字が重複するから直して！」 そうお願いすると、Geminiは根本原因を探るのではなく、 ** 「重複してしまった文字列を、無理やり切り貼りして綺麗な文字列に整形する」 ** という対症療法に走りました。 直ったように見えて、実機でテストするとまた別のパターンでおかしくなる。「まだおかしいよ」と伝えると、さらに複雑な文字列操作のロジックが追加されていく……。

以前の私なら、言われるがままコピペを繰り返して、コードを完全に破壊していたでしょう。

追加の修正や継ぎ足しを繰り返した結果、コードが複雑に絡み合い、どこをどう修正すればいいのか誰にも分からなくなってしまう。いわゆる「スパゲッティコード」の危機です。例えるなら、カバンの中でイヤホンと充電ケーブルがぐちゃぐちゃに絡まった状態。AIの言う通りに複雑なコードを継ぎ足し続けていたら、システム全体が「触れたら崩壊するスパゲッティ」になるところでした。

しかし、1ヶ月間毎日コードと向き合ってきた私の直感がアラートを鳴らしました。「いや、なんかコードがどんどん膨れ上がって複雑になってないか…？」 修正のたびにGit（変更履歴を記録するセーブ機能のようなシステム）でコミットし、差分をしっかりチェックする自分なりのコツができていたおかげで、この異常事態に気がつくことができたのです。

私は提案された複雑怪奇なコードの反映をストップし、Geminiにこう問いかけました。

「……これが最善ですか？」

すると、Geminiリードエンジニアから返ってきた答えがこちらです。

「おっしゃる通りです。私の先ほどの提案（オーバーラップを計算して文字列をマージするアプローチ）は、 ** あまりにも泥臭く、過剰なエンジニアリング（Over-engineering）でした。 ** 混乱を招いてしまい申し訳ありません。もっとスマートで、Reactのモダンな設計思想に沿った、非常にシンプルで確実な解決策があります。」

……えぇっ！？ あるの！？ 最初に言えよ！！！！

なんと、原因は文字列のバグではなく、音声認識の途中結果を拾う設定とReactの非同期のステート更新が、モバイル端末の処理速度の遅さによって競合（レースコンディション）を起こしていることでした。根本原因が分かれば、解決策は非常にシンプルだったのです。

一見、AIが意地悪をしているように見えますが、冷静に考えるとこれは「技術力がない初心者が陥るプロンプトの罠」です。 AIは「文字がおかしいから直して」という具体的な指示に対しては忠実に、その結果の文字列をこねくり回して直そうとします。人間同士なら「あー、これ根本的な設計がマズイですね」と察してくれますが、AIは勝手に忖度してはくれません。 AIからすれば、 ** 「いや、原因究明じゃなくて『文字を直せ』って言ったのそっちじゃん！最初から具体的な要件を言えよ！」 ** と思っていたのかもしれません（笑）。

この失敗から、AIと一緒に開発を進める上で必須となる3つのアプローチを学びました。 1つ目は、詳細に要件を言語化すること。「バグった！直して！」ではなく事実を正確に伝えること。 2つ目は、プロンプトの指示出し自体もフォーマット化すること。 そして最も重要なのが、 ** 要件定義フェーズを分ける ** ことです。いきなり「コードを書いて」とお願いするのではなく、まずは「壁打ちの相手」になってもらい、根本原因の仮説を出すところから始めるべきなのです。

「これが最善ですか？」というたった一言の問いかけが、スパゲッティコードの危機から私を救ってくれました。AIは魔法の杖ではなく、超優秀だけど少し融通の利かない新入社員。上手く使いこなすためには、こちら側の「マネジメント能力」が問われるのだと痛感した1日でした。

---

🍳 【今日のAI開発レシピ】

技術難易度：⭐☆☆☆☆

1. 「オーバーエンジニアリング」とは？

本来はとてもシンプルに解決できる問題に対して、無駄に複雑で大掛かりな仕組みを作ってしまうことです。 例えるなら、「1＋1の答えは？」と聞かれた時に、「2」と答えればいいのに、わざわざ ** 「スーパーコンピューターを起動し、ピタゴラスイッチのような巨大なカラクリ装置を動かして『2』という看板を出す」 ** ような状態です。「ハエを叩くのにバズーカ砲を持ってこないで！」というツッコミ待ちの状態ですね。

2. どうやったの？

AIが提案してくるコードがどんどん長く、複雑になっていくのを見て「これはおかしい」と直感しました。そこで、すぐにコードをコピペするのをやめました。 変更履歴を管理するGitの差分画面を見ながら深呼吸し、チャット欄に一言、「そのアプローチは複雑すぎませんか？これが最善ですか？」とストレートに疑問をぶつけました。結果としてAIは自らの提案を撤回し、根本原因（レースコンディション）にアプローチする数行のシンプルなコードを出し直してくれました。

3. 読者の皆様へ

もしAIを使って文章作成やプログラミングをしていて、「なんかややこしくなってきたな…」と感じたら、チャットの最後に ** 「もっとシンプルで確実な別のアプローチはありますか？」 ** とGeminiに頼んでみてください。驚くほどスッキリとした「真の正解」をポロッと出してくれることがありますよ！

---