外注に約100万円かけたゴミアプリが、
Codexで生まれ変わった件⑤|Codexとの出会い編

こんにちは!吉田です。
前回は、アプリの作り直しを依頼し、確認と修正を繰り返した話でした。今回は、その後止まっていた開発が、友人への相談をきっかけにCodexへつながるまでのお話です。

いろいろありましたが、最終的には、やりたかった機能がひと通りそろったアプリになりました。QRコードを発行し、配布後の反響を確認する。さらに、AIを使って配布先の提案や振り返りもできる。

ただ、形になったことと、公開できることは別でした。AIの回答には正確性や裏付けの問題が残り、利用コストも含めて、そのままお客様に提供できる状態ではなかったんです。

お金はかけた。でも、これってゴミアプリなのでは?

APIは1回叩くたびに数ドルかかり、結果が返ってくるまでの時間も長い。当時の自分なりの試算では、この費用をまかなうには、販売価格を2万円以上にしないと厳しいと考えていました。

しかも、価格を上げれば解決するわけでもありません。何度でも分析できる仕様にすると、使われるほどAPIの費用が増え、こちらの負担は青天井になってしまう。回答の精度も、使い続けられる料金の仕組みも、このまま公開するには問題が山積みでした。

それだけの価値を感じてもらえるなら、価格そのものが悪いわけではありません。ただ、目の前のアプリを見てみると、どうにも見た目がチープに感じる。
操作も分かりやすいとは言いづらく、初めて使う人が迷わず進められるのか、不安が残りました。

当時のUIをローカル保存版で再表示したものです。会社情報やチラシはサンプルです。 ※クリックで拡大。

作りたいと思っていた機能はあっても、この画面と使い勝手で、その金額を出してもらえるのかと考えてしまいました。

正直、私なら買わない。

お金も時間もかけたのに、このままでは公開できない。かといって、また外注して直すには追加の費用も、あの確認と修正のやり取りも必要になる。「このアプリ、正直どうすんの……」と、悶々とする日が続いていました。

本業の動画制作も忙しくなり、立て直す方法が見つからないまま、開発はいったん止まってしまいました。

きっかけは、Figma Makeを試してみたこと。

ちょうど同じ頃、ホームページの改修も少し進めたいと思っていて、そのワイヤーフレームを作るためにFigmaを使い始めました。そこで見つけたのが、Figma Makeです。試しにプロンプトを入れて、画面を作ってみました。

これ、アプリにも応用できるんじゃない?

保存されていた最古の履歴から表示した試作画面です。数値やキャンペーンはデモです。 ※クリックで拡大。

思っていた以上にそれらしい画面ができて、「これなら、今のアプリの見た目や使い勝手も変えられるかもしれない」と感じました。止まっていた開発をもう一度考え始めるきっかけは、Figma Makeだったんです。

画面として形になると、「ここは分かりやすい」「ここはまだ迷いそう」と、自分でも具体的に判断できます。文章だけで要望を伝えていたときとは、考えやすさが違いました。

ただ、見た目を変える前に、そもそも今のUIは何が使いにくいのか。その理由を整理してみようと、次にGeminiへ相談することにしました。

Geminiに「このUI、何が使いにくいんだろう?」と聞いてみた。

Geminiには、今のアプリの画面を見せて、使いにくい理由や、どう変えればよくなるのかを聞いてみました。「なんか使いにくい」「なんかチープ」という感覚を、具体的な改善につなげたかったんです。

そこで気になったのが、ツリー状になっている画面構成や、目的の操作にたどり着くまでの流れについての指摘でした。

当時の画面は、会社の下にチラシがあり、その下にAI分析がある、というように情報が階層で並んでいました。

当時のAI分析画面。左側のメニューから、会社・チラシ・分析へと進む構成でした。ローカル保存版を使用しています。 ※クリックで拡大。

もちろん、ツリー状のメニューが全部使いにくいという話ではなく、今回お客様にやってほしいことを考えると、もっと分かりやすい整理の仕方がありそうでした。

私は開発の経緯を知っているので「この情報はここにある」と分かりますが、
初めて触る人はそんなことを知りません。

必要なのは、項目をすべて並べることだけではなく、何から始めて、
次に何をすればいいのかが分かる画面
だったんだと思います。

Geminiが整理してくれた問題点や改善案を、今度はFigma Makeに渡して画面を調整していきました。「なんとなく気に入らない」から「ここを変えたい」へ、ようやく一歩進めた感じでした。

招待制から、自分で登録して使えるサブスクへ。

画面を作り直す中で、サービスの提供方法も見直そうと考えました。それが、招待制から、利用者が自分で登録して使えるサブスク型への変更です。

それまでは、こちらから招待して使ってもらうことが前提でした。でも、より多くの事業者に使ってもらうなら、興味を持った人が自分で登録し、必要なプランを選んで使い始められる形のほうがいいんじゃないか、と。

そうなると、ダッシュボードだけきれいにすれば完成、というわけにはいきません。ログイン画面に加えて、新規登録やメールアドレスの確認、会社情報の入力。
その先には、プランの選択や支払い、契約内容の確認・変更・解約といった流れも必要になります。

初期のログイン画面。実際の認証は行わないデモ画面です。 ※クリックで拡大。

さらに、無料でどこまで使えて、有料になると何ができるのか。APIを使うたびに費用がかかる以上、AI分析の利用回数なども考えなければなりません。

サブスクにするというのは、料金表を付けるだけの話ではなかったんですよね。

初期の試作にも、Freeプランの表示や、Proプランへのアップグレードを案内する画面を用意していました。

プラン変更の見せ方を検討するための画面です。この時点で実際の決済まで完成していたわけではありません。 ※クリックで拡大。

見た目が形になるにつれて、「ここも必要だ」「この操作の後はどうなるんだろう」と、サービスとして考えるべきことも見えてきました。ただ、そこで次の問題が出てきます。

で、これを誰が実装するの?

アプリの経緯を知る、二人の友人に相談した。

最初は、二人のエンジニアの友人に実装をお願いしようと考えていました。一人はフロントエンド、もう一人はゲームのインフラ設計に関わり、AIにも詳しいバックエンドのエンジニアです。

二人には以前から開発会社とのやり取りも見てもらっていて、このアプリの開発経緯をよく知っていました。Figma Makeの画面にも、「ここはいい」「ここは変えた方がいい」と率直な意見をくれました。

外注についての、友人の見立て。

これまでの外注には、「ハズレくじを引いたね」と手厳しい感想も。特に、ソースコードを受け取れない条件は、依頼前に説明してほしかったね、と言われました。

一方、APIの実装は良いという評価でした。ただ、
プロンプトが実務に合うか、運用費が事業として成り立つかは、また別の話。
日本語で会話できても、ポスティングの業務や細かな仕様まで共有できるとは限らない、という指摘もありました。

予算も用意して相談しましたが、二人とも忙しく、実装を引き受けるのは難しいとのこと。アプリ自体も、片手間で直せる規模ではなくなっていました。

今なら、それも分かります。私には「画面ができたから、あとはつなぐだけ」に見えていても、友人には、確認画面やプラン変更時の処理など、まだ必要な作業が見えていたんですよね。

見た目ができたことと、サービスとして動かせることは、別の話でした。

そこで初めて聞いた「AIエージェント」という言葉。

そんな中で、友人から教えてもらったのが、AIエージェントでした。
私は仕事でも毎日のようにAIを使っていましたが、当時は有料版を使った覚えもないくらいで、基本的には質問をしたり、文章を考えてもらったりする使い方が中心でした。

なので、最初は「AIエージェント」と言われても、何が違うのかさっぱり分かりません。
話を聞くと、チャットで答えてくれるだけでなく、アクセスを許可したパソコン内のファイルを読み、コードを調べたり、修正したりする作業まで進められるらしい。

え、それって、今まで自分では触れなかった
ところまで見てもらえるってこと?

友人からは、まずAIエージェントを使って、
今のアプリにどんな問題があるのか洗い出してみたら、と勧められました。
使い始める方法も教えてもらい、AWSのサーバー構築のような作業まで任せられる、と聞いたときには、正直、話についていくので精いっぱいでした(笑)

今のアプリを自分で調べ、直していく方法があるのかもしれない。そう思えたことは、大きかったです。

いよいよ、Codexを動かしてみる。

こうして、2026年8月末からCodexを使い始めました。まずは、今のアプリの問題点を調べてもらうところから。

早速動かしてみた結果、どうだったのか?

次回は、納品されたAPIをCodexに見てもらったお話です。
処理時間や費用、そして回答の根拠をどう見直していったのかをお届けします!

シリーズの続きを読む

記事一覧へ戻る →