こんにちは。「超高齢化社会の、希望となるインフラを創る」株式会社ゼストのプロダクトマネージャーを担当している川添です。
2025年12月のアドベントカレンダー企画で「NotionとAIを使い倒して、家事をRPG化してみた」という記事を書きました。今回はその後、ノリでアプリ開発に挑戦してみたという後日談と、そこから感じたSaaSやPdMの今後についてです。
2026年5月現在のスナップショットとして、私の考えを整理しておきたいと思います。
上の記事を書いたのは家事に追われて心身ともにヘトヘトになっていた時期でした。夜中にふと「ゲーム中の買い物みたいなUXで買いものリストを作りたい」とClaudeに相談したのをきっかけに、家事をRPG化してNotion管理できるようにしたところ、子どもたちがノリノリになって片付けや買い物を手伝ってくれるようになり驚くほど暮らしやすくなりました。
でも、Notion単独でできるUI/UXには限界があります。ちょうど冬休みに入るタイミングだったこともあり、
「勉強ついでに、AIでアプリ化してみるか」
と思い立ちました。
家族用アプリだったことと、Xでも非エンジニアの方が短期間でアプリ開発している事例をよく見ていたので「PWAなら9日間もあればいいところまでいけるのでは」と。
が、しかし。
甘かった…。
ちなみに私のバックグラウンドは企画職で、プログラミングをしたことはほとんどありません。長い間ウェブ界隈に生息しているので、HTMLをほんの少し書いてみるとか、FTPで公開するとか、Wordpressの既存テーマをいじってブログを作ってみるという経験はあったものの、ほぼ素人も同然です。
そんな私が、Claude、Gemini、ChatGPT、Codexを使ってPWAをゼロから作ってみて見えてきたのは、Xでよく目にする「AIで何でも作れる」「SaaSはもう終わる」「PdMは不要」といったフレーズとは少し違う景色でした。
この記事では、夜な夜なAIたちと格闘して体感した「AIで爆速でアプリを作れるかどうかを決める4つの軸」と、開発することで見えてきたSaaSとPdMの仕事の輪郭について共有します。
1. AIで爆速で作れるアプリかどうかは「4つの軸」で決まる
巷では毎日のように「AIを使って◯時間でアプリ開発した」「◯週間で収益化した」と話題になっていますが、非エンジニアが爆速でアプリを作るには条件があります。
今回、PWAをゼロから作ってみて強く感じたのは「アプリが受け取るデータがどこから来て、どのように使われるか」で、開発速度はまったく変わるということです。
重さを測る軸として私の中で整理できたのは、次の4つでした。
これらは並列の独立した軸で、1つでも「重い」側に倒れた瞬間に、開発難易度が増します。複数倒れれば、もう爆速とは無縁の世界です。
たとえば、4軸すべてが軽いアプリとは
自分が入れた値をその場で計算し、表示して終わり。保存もしないアプリ
というものです。これなら、AIに任せきりでもあっという間に動くものができます。自分で作ったデータを自分だけが使うので、ハンドリングが容易であること、DBも認証も要らないためです。
当然、4軸すべてが重いアプリは開発が複雑です。
データを保存するということはアプリ内外どちらかにDBが必要になります。さらに保存したデータをあちこちの画面で使うなら、それをどうやって引っ張ってくるか、どう加工するか、DB読み書き数は妥当か考える必要があります。複数人で使うなら外部DBへの保存が必要になるのと、認証や権限について考えなければなりません。
また、ZEST SCHEDULEの外部連携データやZEST RRMの厚労省由来データのように、いつ誰が、どう変えるかわからない外部データを扱うとなると、ここにさらに別のリスクが乗ってきます。
リスク①フォーマットが一定でなければ壊れる
第三者が作るファイルやデータは知らないうちにフォーマットが変わる可能性があります。列名・粒度が変わったり、全角・半角・表記揺れだけでも取り込みがコケる可能性もあります。取り込みで失敗しないのも恐ろしく、油断していると操作した瞬間に思いもよらぬことが起こるかもしれません。顧客やお金、契約などに関わるデータを扱っていたとしたら…と考えると、胃がきゅっとなります。
リスク②フォーマットの揺れに対応するためにAIに読ませると、意図通りに解釈しない可能性がある
かといって、柔軟性を持たせるためにAIに渡して丸めさせようとしても、おそらく意図通りには解釈してくれません。「だいたい合っているように見えて、実は誤読している」アウトプットが返ってくる可能性があるのが怖いところです。
リスク③入力データの不備が外部向けデータに影響する
顧客向けのデータを出力したり、入力したデータをもとに顧客に提供するサービスが変わったりする場合、さらにハードルが上がります。
さて。
「保存の有無」「画面数」「使う人数」「データ入出力」。それだけ聞くと開発界隈の人には「そこまでややこしいか？」と思われるかもしれません。
確かに、人間のエンジニアと一緒に作るのであれば、ここはそれほどややこしいものではないと思います。
しかし、非エンジニアが人間ではなくAIと開発する最大の壁は、これらの要件について「話せば話すほど忘れていくAI」とあーでもないこーでもないと議論して、懸念点を潰しながら結論を出し、それを作らせて、レビューしなければならないという点です。
保存できる、いろんな画面があるというごくありふれた機能だけであっても、決めるべき要件や選択肢を膨らませ、非エンジニアとAIとのコミュニケーションのボリュームを増やし、認識のズレとブラックボックス化を誘発し、AI開発を雪だるま式に重くしていくのです。
では、我が家の家事アプリはどうかというと、4軸のうち3軸が重い側に倒れていました。
唯一、データの入出力が自分自身で作ったアプリで閉じていたのが救いでしたが、結局、冬休みどころか次男の入学式2日前に滑り込みでリリース。しかも、未リリース段階ですでにフルリニューアルを2回…。
休日と平日夜中のかなりの割合を費やして3か月かかりましたが、もしPdMとしての経験がなかったら、もっと時間がかかっていたはず。作るだけでなく機能拡張するたびに「壊して作る」を繰り返す羽目になっていたと思います。
2. AI時代のSaaSの仕事とは
4つの軸が軽い側に倒れるアプリは、SaaSではなく非エンジニアである個人が直接AIで爆速で解決するのがいいかもしれません。そうしたサービスは、いずれ対価も発生しなくなるでしょう。
しかし、仮に多くの家庭や多くの企業が抱える汎用的な課題を解決しなければならないとき、稼働時間の制約もある中でそれぞれが数か月という時間を溶かし、さらに機能拡張のたびに無駄になる。それは社会全体で見た時にあまりにも非効率です。
ややこしいデータを扱う時。ややこしい扱い方をする時。開発知見のある専門家が、多くの人の代わりにベストプラクティスを形にして広めるほうが安くて早くて旨い。
これがSaaSの本質的な役割だとするなら、AI時代においてもSaaSは「重いものを社会全体で割り勘にするための器」として、これからも生き続けるはずです。
3. PdMの仕事はどう変わるのか
PdMもコードを書く。実装ありきで進めていく。そんな言説を見かけることが増えたように思います。
3か月の開発を経て思うのは、一定以上の複雑さを持つプロダクトを扱う限り、機能の試作はできても作り切ることはまだできそうにないということです。なぜなら、非エンジニアがAIに要件や意図を伝えるには、大量のメモリが必要になり、それに押し出される形で必ずどこかで歪みが生じるためです。
少ない言葉で的確に意図を伝え、プロダクト内部の整合性を取るには、やはり開発の専門知識が必要であることを痛感します。さらには、過去の経験に裏打ちされた「未来を見据えた判断」ができるところにこそ、エンジニアやデザイナーの真の価値があると考えています。
そうすると、逆に「PdM不要論」についてはどうなのでしょう。これはいくつかの論点が考えられます。
- エンジニアが顧客とすり合わせるから不要
- 営業が顧客とすり合わせるから不要
- 経営者や事業責任者が作れるようになるから不要
- AIが代替できるから不要
プロトタイプでのすり合わせは簡単に行えるようになり、ヒアリングや具現化はこれまでよりもずっと簡単になりました。しかし、エンジニアも営業も立場上、自社のプロダクトで「作る」ことを前提にしか話せないという点がPdMの視点との違いだと考えています。エンジニアは「自分が作るべきものは何か」がテーマであり、営業は「自分が売るべきものは何か」がテーマだからです。逆に言えば、作れないもの・作るべきでないものの議論に時間を割くことは、彼らにとっての生産性を下げることになってしまう。
これまでのPdMは顧客に寄り添い、課題を深く理解し、プロダクトの中でどう扱うべきか、または扱わないべきかという観点で検討する役割を担ってきました。個人的には、今後は課題と要件を見極めて、プロダクト内外の解決方法を提案する役割へと寄っていく可能性について考えています。
- 顧客のペインを掴む（ここはいままで通り）
- AI開発した場合の重さとビジネス可能性を見極める
- AI開発で顧客が個人完結できるもの、小規模向けに作るマイクロプロダクト、SaaSとして提供するものの境界線を引く
なぜなら、深さはどうあれ課題と要件とビジネス可能性のすべてに向き合っているのがPdMであり、それは作ることの外側も見なければならないからです。
そういう意味では、経営者がPdMの役割を取り戻すというのが1番起こりやすい代替かもしれません。ただ、この変革をすぐに起こせるとしたら、作り手から経営者になった人の組織かなとも思います。
そして、もうひとつ。
AIはこれからもっとできることが増えて、一般論やいろんなセオリーをもとに「あるべき姿」さえも導出できるようになるはずです。そのとき、論理的な正しさだけでなく顧客の価値観に基づいた「ありたい姿」に寄り添い、自分たち自身もそうありたいと思えるのは同じ人間でなければ難しい。
よく「意思決定できるのは人間だけ」と言われますが、「あるべき姿」に基づく意思決定から「ありたい姿」に基づく意思決定に変わっていくのかもしれません。
おまけ：家事アプリができるまでの裏話
ここからは本筋から少し外れて、家事アプリがどう作られたかの裏話です。AI開発で語られる地雷をだいたい踏み抜いてきたので、「非エンジニアがAIでアプリを作る時のあるある失敗集」みたいになってしまいました。めちゃくちゃ勉強になって面白かったですけどね。
第一期：Claude + Gemini 壁打ちと手作業の限界
Claude Codeが日本の一般層で騒がれる直前だったので、非エンジニアにとっては選択肢も多くありませんでした。そのため、初期はClaudeとアーティファクトをもとに議論を重ねて仕様を固めていきました。
実装もClaudeで…と思っていたものの、クレジットがあっという間に枯渇。何度か課金してみるも、すごい勢いで消費するので致し方なく、Claudeと壁打ちして要件を固め、Geminiがコードを書き、私がVS Codeで貼り付ける体制に仕切り直しました。これが死ぬほど大変でした。
「これを関数の後のどこかに貼れ」って、関数ってどこからどこまでなの…どこかってどこなの…と迷子になった回数は数え切れません。
開発フローも、UIを作ってから裏側をつくっていたのですが、フロント込みのコードを読ませることが足枷になり、改修に改修を重ねるうちにコードがスパゲッティ化。あっちを直すとこっちが壊れる状態でした。
Firestoreにマスターデータを投入するところまでは進めたものの、ハイドレーションエラーの根治がどうにもこうにもできなかったのと、投入スクリプトの不備が判明して限界を感じ始めました。
第二期：Geminiのメモリ問題
今度はGeminiだけでゼロから作り直すことにしました。最初は順調だったものの、Geminiはクレジットは尽きない代わりに、どんどん忘れます。何度言ってもコードを省略する。いつのまにか仕様がズレ始めて別物になる。
スレッドごとに役割を分けてみても、仕様を固めたスレッドが早々に忘れてしまうので、実装が意図通りになされているのかわからない。ドキュメント化して読ませてもスレッドの中盤くらいから忘れていき、途中でカンフル剤的に読ませても効果が薄く、正解は私の頭の中だけにあり、永遠にずれ続けていくような気分でした。
第三期：ChatGPT＋Codex体制でやっと本格始動
2回目のリニューアルでChatGPTに切り替えて、ようやく本格始動できました。（この時点で既に1か月溶かしました）
ChatGPTは私が非エンジニアであることを前提にしつつ、もっとも壊れにくい形でローカル構造を設計してくれたのが成功要因だと思います。Claudeはわかりやすく簡略化してくれていたのですが、その結果、スパゲッティ化しやすい形になってしまいました。
そして、ChatGPTのメニューにそっと佇むCodexの存在を、何かの拍子にVS Code内で発見した瞬間、世界がガラッと変わりました。
同じファイルを見て会話できるだと・・・！？
そこからは、ChatGPTで仕様を詰め、Codexに実装させる形で進めました。
最初に痛い目を見たので、CSSが効いていない白い背景と黒文字状態で先にロジックをガチガチに詰めることからはじめ、ちゃんとしたUIになったのはビルドする数日前でした。2か月近くほぼ何のスタイルも効いていない画面と睨めっこしていたので、子どもたちに経過を見せても薄い反応しか返ってこず、さみしかったです（遠い目）。
リリース直前：Cloudflare弾かれVercelでデプロイ。そしてFirestore Reads爆発
ようやくCSSも反映してCloudflareでデプロイを開始。ビルドログがスタッフロールのようにざーっと流れていくのを眺めながら、苦しかった3か月に思いを馳せていると、最終的にサイズで弾かれました。うわああん！その後、右往左往してVercelの個人プランを見つけて本番デプロイに漕ぎ着けました。
スマホで動くようになって子どもたちに使ってもらいながらFirestoreを開いた瞬間、
Readsがとんでもないことに・・・！
プロのデザイナーさん・エンジニアさんクオリティには至らないとはいえ、仕組みとしては割とよくできたから趣味つながりの人たちに公開してもいいかなーと思っていたにも関わらず、あかん。これでは10家族くらいで無料枠使い切る。誰かのペインを解決するどころか、我が家の平穏も保たれない。ということでやむなく断念。
ゼストのエンジニアさんたちが日々細やかな気遣いをしてくれているのはこれかよ！完全に理解した！ありがたすぎてもう東京に足を向けて眠れない！という気持ちになりました。
大急ぎでマスターデータをローカル化し、ついでに外国人夫を巻き込むため多言語化と「かな」にも対応しました。
そんなこんなしているうちにNotionがChatGPTにもCodexにも接続できることがわかり、すべてのdocsをNotionに移行。マスターデータ管理もCSVを卒業して、作ったものを後からユースケースに反映する逆運用も始めました。
そして、入学式2日前、無事に本番運用スタートすることができました。いやー。新生活に間に合って良かった。
今では日常の中にすっかり溶け込み、親子でモンスター（家中の散らかりや汚れ）を退治し、買い物気分で買う物リストを更新する日々です。
子どもたちとの不定期の企画会議も楽しくて、自由な発想や想像力に感心しています。嬉々として「バグだー！バグを見つけたー！」と報告してくれるのにも助かっています。
心にゆとりも生まれ、産後3日と続けられることのなかったダイエットもようやく続けられそうです。待ってろよ健康診断！
小ネタ：ChatGPTの残メモリが十分かわかる猫語🐱
途中で発見したのですが、ChatGPTで新しいチャットを始める時には「猫語で話して」と伝えています。メモリが危うくなると猫語を話さなくなるので「あ、そろそろ次のスレッドに行くタイミングだ」を体感的に検知できるようになります。
ついでに、ムカつくことも減りました（猫様だからしゃーないな、と）。
AIを積極活用しつつ、AIだけでは作れないバーティカルSaaSを作っています
もし、この記事を読んでちょっとでもゼストに興味を持たれたら、ぜひ一度、弊社のWantedlyをチェックしてみてください！Notion lover引き続き大歓迎です！
