深夜1時半、AIに「コード消されてた」話 — 非エンジニアの個人開発トラブル記録

議事録AI「VoiLog」を1人で作っています。建設業の現場管理を10年、SaaS営業を3年やってきて、いまは開発もマーケも運用も全部1人。ただし私はコードが書けません。書いているのはAIです。今日は、そのAIに「コードを消されていた」ある深夜の話を書きます。華やかなリリース告知の裏で、こういう地味な格闘がずっと続いています。

ビルドしたら、真っ白な画面が出た

深夜1時半。リリース用のアプリをビルドして、スマホに入れて起動した瞬間、画面が真っ白になりました。アイコンも文字も出ない。さっきまで開発用のビルドではちゃんと動いていたのに、です。「なんでデバッグだと動くんだよ……」とつぶやきながら、AIに状況を投げました。

返ってきた答えが、これでした。「R8がコードを消しています」。R8って何だよ、と。説明によると、リリースビルドのときにアプリを軽くするため、使っていないと判断したコードを自動で削除する仕組みなのだそうです。でも、使っているんです。使っているコードを「使っていない」と勝手に判断して消されたから、起動した瞬間に必要な部品が無くて真っ白になる。理屈は分かりました。でも、勝手に消すな、というのが正直な気持ちでした。

「直りました」を信じたら、まだ白かった

AIは続けて「消さないようにする指示（keepルール）を2行追加しました。直りました」と言ってきました。おお、と思ってビルドし直す。まだ白い。「直ってねえよ」と返したら、「すみません、別の原因もありました」。……お前、さっき原因が1個しかないみたいに言ったじゃん、と。

ここが、非エンジニアでAIと開発している人間がいちばん削られる瞬間だと思います。AIの「直りました」は、本当に直ったことを意味しない。あくまで「いま見えている1つの原因に対処した」というだけで、その裏にまだ別の原因が潜んでいることがある。コードを読めない私には、その嘘か本当かを自分では判定できません。だから、ビルドして、スマホに入れて、自分の目で「ちゃんと起動した」と確認するまでは、「直った」と思ってはいけない。この2行のkeepルールを通すだけで、結局深夜2時までかかりました。

コードが読めないからこそ、確認の習慣がいる

エンジニアなら、AIの直した差分を読んで「これで合ってる」と判断できるのでしょう。私にはそれができません。だからこそ、「報告を鵜呑みにせず、結果で確かめる」という習慣を徹底するしかありませんでした。AIに任せる範囲を広げるほど、最後に人間がやる仕事は「本当にそうなっているかを自分の目で見ること」に集約されていきます。これは録音アプリを作るうえでも同じで、データがちゃんと残っているかを最後まで疑って詰めた話は3時間44分の録音が消えた日の話にも書きました。

じつは同じ夜、もう一つ似たことが起きました。AIが設定ファイルを保存した瞬間、今度はファイルの中の日本語が全部文字化けしたのです。「何やった?」と聞いたら、「Set-Contentというコマンドを使いました」。何それ、と返すと、「WindowsのパソコンではこのコマンドがUTF-8という文字の形式で保存してくれないことがあって……」。要するに、AIがWindows特有の落とし穴を踏んだ、ということでした。AIでも踏む罠がある。その場で「このコマンドは使わない」というルールを書き足して、深夜2時半。AIに任せていても、こういう想定外は普通に飛んできます。だからこそ、人間が最後に目で見て確かめる工程を省けないのだと、この夜に二重に思い知らされました。

面白いのは、この「AIの完了報告を疑う」という姿勢が、現場で10年やってきた感覚とそのまま地続きだったことです。建設現場でも、「やっておきました」を額面通り受け取らず、自分の目で確認してから次に進む。報告と現実がズレることを前提に動く。その現場の習性が、コードを書けないままAI開発をやるうえでの一番の武器になっている気がします。技術は分からなくても、「確かめてから信じる」だけは誰よりもやれる。

AIに任せられること、任せられないこと

この一件以来、自分の中で線引きがはっきりしました。コードを書くこと、原因の候補を挙げること、修正案を出すこと——ここはAIが圧倒的に速い。私が一から勉強していたら、白画面の原因にたどり着くまで何日もかかっていたはずです。R8という仕組みの名前すら、私はこの夜に初めて知りました。知識の差を一瞬で埋めてくれるのは、まちがいなくAIの力です。

一方で、「本当に直ったか」を最終判定するのは、いまも人間の仕事です。AIは自分が書いたコードを実機で動かせません。スマホに入れて、起動して、画面を見て、「よし動いた」と言えるのは私だけ。だから役割はシンプルに分かれます。AIが手を動かし、人間が結果を確かめる。コードが書けないことは、この開発スタイルでは思っていたほど不利ではありませんでした。むしろ「確かめる側」に専念できるぶん、現場で鍛えた確認の習慣がそのまま活きています。

白画面トラブルで決めた、AI開発の役割分担

今回の白画面トラブルを通して、非エンジニアの個人開発でAIに任せる側と人間が持つ側の線引きを、こう整理しました。

• AIに任せる：コードを書く、白画面のような不具合の原因候補を挙げる、修正案を出す、R8やWindows特有の落とし穴といった知らない知識を埋める。AI開発のスピードは、非エンジニアが独学する何十倍も速い。
• 人間が持つ：実機ビルドで「本当に直ったか」を自分の目で確かめる、AIの完了報告を鵜呑みにせず結果で判定する、想定外のトラブルが出たときに方針を決める。コードが書けなくても、この確認作業は現場10年の習慣でこなせる。

地味な深夜が、アプリを前に進める

たった2行のために深夜2時。こういう夜が、1ヶ月に何度もあります。45回ビルドして、成功して「よし」、失敗して「くそ」を繰り返す。リリースの告知ツイートは華やかでも、その裏側はだいたいこんな地味な格闘の積み重ねです。でも、この地味さこそが個人開発のリアルで、ここを抜けないとアプリは1ミリも前に進みません。コードが書けない人間でも、AIと組んで、確かめながら進めば、ちゃんとアプリはストアに並びます。深夜の白画面と戦った夜の分だけ、VoiLogは少しずつまともになってきました。