【AI時代の個人開発】10. 本番デプロイ前に、最後まで残った課題の話

ログインできる。主要な機能も動いている。課金処理も、想定した状態へ反映される。

あとは、本番へ公開するだけ。

そう思ってからが、長くなりました。

スマートフォンでは使いにくい画面。コードを直しても消えないデプロイエラー。利用者には意味が伝わらないエラーメッセージ。規約や問い合わせ窓口も、まだ整っていません。

残っていたのは、大きな新機能ではありませんでした。

「動くサービス」を、「人に使ってもらえるサービス」へ変えるための作業でした。

「動いた」ので、完成したと思っていた

AIツールの選定から始まり、認証、Pull Request、課金機能の再設計まで進み、主要な機能は一通り動いていました。

私の中では、完成にかなり近づいた感覚がありました。

しかし、それは開発者から見た完成にすぎません。

利用者が触る環境を想定して見直すと、機能が動くこととは別の課題が残っていました。

PCとスマートフォンでは、使いやすいUIが違った

開発中は、PCのブラウザで画面を確認する時間が長くなります。

画面幅を狭くしながら表示を確認していたため、スマートフォンへの対応も進んでいるつもりでした。

ところが、実際の端末で操作すると、画面は崩れていなくても違和感が残ります。

今回のアプリには、利用者が複数のUIを切り替えられる機能を実装していました。ただし、最初に表示するUIは、PCでもスマートフォンでも同じ設定でした。

実際の端末で試すと、PCで操作しやすいUIと、スマートフォンで操作しやすいUIは異なると感じました。

そこで、利用する端末に応じて、最初に表示するUIを切り替えるようにしました。

機能そのものを作り直したわけではありません。

同じ機能でも、どの見せ方から始めるかを変えただけです。それでも、操作したときの違和感は大きく減りました。

それまでは、レスポンシブ設計で画面幅に合わせれば、PCで使いやすいUIをスマートフォンでも活用できると考えていました。

AIに問題を伝えれば、実装案はすぐに出てきます。

ただし、どちらのUIを最初に見せるべきか。その違和感を見つけ、方針を決めるのは人間の役割でした。

本番公開を止めたのは、コードではなく外部サービスの設定だった

画面の修正とは別に、本番環境へデプロイできない問題も発生しました。

表示されたのは、Stripeの認証トークンに関するエラーです。

最初は、コードや設定ファイルのどこかに不要な記述が残っているのだと考えました。AIに調査を依頼し、関連しそうな設定を削除します。

しかし、エラーは消えません。

別の原因候補を調べ、さらに修正する。それでも同じ場所で止まります。

AIは、見えているコードや設定をもとに修正案を出し続けました。

調査を進めるうちに、コードではなく、デプロイサービス側に残っていた設定が原因ではないかと考えるようになりました。

問題の場所が違えば、コードを直し続けても解決には近づけません。

最終的には、修正の反復を止め、サービスのサポートへ問い合わせました。

ここで必要だったのは、

「この問題は、もうコードの中にはないのではないか」と疑うことでした。

AIによる調査を続けるのか。調べる場所を変えるのか。外部へ問い合わせるのか。

問題解決の手段を切り替える判断が必要でした。

公開に必要だったのは、機能だけではなかった

本番公開へ向けて、規約、問い合わせ窓口、独自ドメイン、SNSで共有されたときの表示など、機能以外の準備も残っていました。

エラーが起きたときの案内も、修正対象です。

開発中のエラーメッセージは、原因を調べるための情報が中心です。そのため、内部の状態や技術用語が、そのまま利用者へ表示されている箇所がありました。

実際に見直してみると、技術的な原因を示すだけでは、利用者が次に何をすればよいのか分かりにくい箇所があります。

• 入力内容を直せばよいのか

• 少し待ってから再度試せばよいのか

• ログインし直す必要があるのか

• 問い合わせたほうがよいのか

次に取る行動が分からなければ、正確なエラー表示であっても、利用者にとって十分な案内にはなりにくいでしょう。

そこで、内部状態を示すだけだった文言を、利用者が次の行動を判断できる案内へ変えていきました。

エラーメッセージは、失敗を報告するためだけのものではありません。

利用者を、次の行動へ案内するためのものでもありました。

規約や問い合わせ窓口、エラー時の案内は、いずれも主要機能の外側にある要素です。

それでも、一つひとつが「このサービスを人へ渡してよいか」という判断に関わっていました。

本番に近い条件で、最初から最後まで通して確認した

個々の画面やAPIが動くことは、それまでにも確認していました。

しかし、本番前に必要だったのは、一人の利用者として、一連の操作を通して確認することでした。

• アカウントを作成してログインする

• 必要な手続きを進め、主要な機能を利用する

• 登録した内容を変更したり、取り消したりする

• 状態変化とエラー時の案内を確認する

それぞれの機能が単体で動いていても、前後の処理をつなげることで見つかる問題があります。

個々の機能を確認するだけでなく、利用者の一連の操作が途中で途切れないことまで確かめる必要がありました。

公開までの距離が短くても、判断の責任は軽くならない

今回の環境では、コードを修正しただけで、自動的に本番へ反映されるわけではありません。修正後には、本番環境へ公開するための操作が必要です。

それでも、複雑なサーバー作業を毎回手作業で行う場合と比べれば、修正から公開までの距離は短くなっていました。

問題を見つけ、AIと相談しながら修正し、変更内容を確認して本番へ反映する。

この速さは、個人開発にとって大きな武器です。

その分、公開前の確認は慎重に行う必要がありました。

本番前には、速く直すことよりも、確認した変更だけを公開することが重要になります。

そのために、これまで整えてきた GitHub連携や Pull Request も役立ちました。

AIは、コードを書き、修正案を出し、エラーの原因を推測してくれます。

たとえば、AIによる調査を続けるのか、サポートへ問い合わせるのか。こうした切り替えは、自分で判断する必要がありました。

どの問題を許容し、どこまで公開前に直すのかも同じです。

何を作るのか。
どこまで確認するのか。
いつ公開するのか。

AIが進化するほど、問われるのは人間でした。

完成とは、コードを書き終えることではなかった

開発を始めた頃、AIに期待していたのは、サービスを速く作れることでした。

実際に、AIは開発速度を大きく変えてくれました。

しかし、完成に必要だったのは、速さだけではありません。

違和感を見つける。利用者に伝わる言葉へ直す。問題の場所を見極める。そして、人へ渡してよい状態かを判断する。

AIは、サービスを完成へ近づけてくれました。

けれど、最後の一歩を踏み出したのは、AIではありませんでした。

AIを使う側から、使いこなす側へ。

関連情報

このシリーズは、第１０話で完結です。

前回：シリーズ９

【AI時代の個人開発】シリーズを最初から読む

創作大賞2026の選考期間中は、創作大賞2026 ビジネス部門応募作品｜AI時代の個人開発 にも全10話をまとめています。