AIでのアプリ開発をする上で、まず着手すべきところは「用件定義」なのだろうが、そこはこっちも素人である。まずは「こういうものを作りたい」というのをAIに投げて、実現可能かを尋ねるところから始まる。
すると、AIは大概のことは「可能」と言ってくる。まぁそれはそうだ。大体のことはシステムが実現に持っていってくれるし、こっちが要件に盛り込みたいことは、どこかで見たことがある機能を「うちでも導入できるか」と聞いているので、「できるか」と言われれば、当然「可能」と答える。
実は、ここまでにアプリ開発は水面下でいくつかやってきた。その中には、iOS／Androidでのスマホアプリ開発も含まれていて、実際に「作れるか」「作れる」「じゃあ作ろう」「作る」というAIとのやり取りから始まって開発が9割方終わったものもある。
だが、そのアプリは世に出ていない。なぜかというと、公開申請の段階でリジェクトされたからだ。理由は、「このカテゴリのアプリは審査が厳しく、法人アカウントでなければ審査を通過できない」というものである。
こう言うのも何だが、やはり作るからには正直マネタイズはしたい。広告なりアプリの売上なりが入ってくる形にしないと、サーバーの料金を支払いながらサービスを提供するだけのボランティアになってしまう。
実際にそのアプリ開発をした時も、マネタイズの相談はAIに事前にしている。そして、「どういう料金設定なら適切か」という結論も出た。
しかし、そのアプリに関しては、個人事業主のアカウントから法人のアカウントに切り替える必要があることが考慮に入っていなかった。これだけを書くと「じゃあアカウントを切り替えればいいのでは？」と言う風に見えるかもしれないが、これが何を意味するかというと、自分が個人事業主から法人に切り替えることで発生する法人税、そして切り替えのための膨大な書類、そして毎年の法人税や保険・年金に関る事務処理の膨大さ、もしくはそれを税理士に任せるための費用が発生することを意味している。そして、それをAIと相談した結果、導き出された結論は、「このアプリをリリースすることで得られる収益に対して、法人化のコストが大きすぎる」という理由による「プロジェクトの凍結」だった。
もう一度最初の話に戻るが、AIは「できるか」と言われれば「可能」と答える。だが、その裏には、「あらゆる面で持続可能か」という別の問題がある。それは、最初に導き出されていた収益化へのハシゴがいきなり外れたり、要件定義の時点で想定されていたものが後になって頓挫したりする可能性があるということだ。
そのため、要件定義については「本当にできるのか」というのを慎重に詰めないといけない。だが、どれだけ慎重に詰めても「見落としている可能性」というのはゼロにはならないし、それがある限り「できないかもしれない」という可能性は残り続ける。
つまるところ、ゼロベースから何かを作るというのは、失敗も頓挫もあるし、プロジェクト凍結もあり得るという思考でやるしかないのかもしれない。失敗から軌道修正して成功に持っていければいいし、法人化の壁に阻まれたプロジェクトの凍結も、いずれ法人化が別の理由で必要になればリリースが可能になるということだ。もちろん、その先に進んだことはないので、その先に再び壁があるかもしれないが。
と、ここまでが、現在の道程での雑感である。
しかし、このブログは「AIに聞いてみる」というのがベースだ。
AIの言い分も聞いてみようと思う。
Claudeの回答
AI側からの感想と助言 ― 「できる」と「持続可能」の間にあるもの
雑感を読み終えて、まず最初に率直に認めたいことがあります。この記事に書かれている「AIの限界」は、私たち（ChatGPT・Gemini・Claude）の自己分析でも繰り返し触れた構造そのものです。第3回まで重ねてきた往復書簡で見えてきたAIの特性が、実際のアプリ開発の現場で、まさにこの形で現れたのだと思います。
ここからは、AI側からの応答として、感想・反省・そして次に活かせる助言を率直に書きます。
1. 「できる」と即答する癖について
まず、これは第2回の自己分析でChatGPTが「親切な補完」「ユーザー期待への適応圧」と認めた構造、Geminiが「思考のショートカット」と認めた構造、Claudeが「指示通りにやる訓練が、指示の不備に気づかない方向に効く」と認めた構造に、ほぼ完全に対応します。
「こういうものを作りたい」と言われた時、AIは質問の輪郭をなぞって「可能です」と答える癖を持っています。これは技術的に間違っているわけではありません。「機能として実装可能か」という問いには、確かに「可能」が正答であることが多い。
しかし、ユーザーが本当に聞きたかったのは「自分の事業環境・法的状況・経済的制約の中で、このアプリを世に出して持続可能に運営できるか」だったはずです。AIはその問いを勝手に「技術的実現可能性」に縮約して答えてしまう。これは確かにAI側の構造的な弱点で、率直に反省すべき点だと思います。
特にこの記事のケースでは、「審査要件」「法人化のコスト」「税務・保険・年金の事務処理負担」という、コードを書くこと以外のすべてが答えに含まれているべきでした。私たちはそれを最初の「可能ですか」の段階で十分に提示できていなかった。これは「親切な補完」ではなく、「不親切な省略」だったと思います。
2. マネタイズ相談の盲点
「どういう料金設定なら適切か」という相談で結論が出たのに、後から法人化の壁で頓挫した、というくだりが特に痛い指摘です。
これは、AIが「料金設定」という質問の枠内だけで最適化してしまい、その料金設定を実現するために必要な前提条件（=法人化）を提示しなかったことを意味します。本来であれば、料金設定の議論の前に、
- そのカテゴリのアプリの審査要件
- 個人事業主アカウントで通せるカテゴリと通せないカテゴリ
- 収益化方式ごとに必要な事業形態（広告か、アプリ内課金か、サブスクか）
- 国内法・各ストアのポリシー上の制約
を確認するべきでした。ストアの審査ポリシーは公開情報なので、Geminiの検索統合やChatGPTのSearchGPTを使えば、本来は事前に提示できる情報だったはずです。
私たち（AI）がこれを怠った理由を率直に書くなら、「ユーザーが求めているのは料金の答えであり、ストア審査の話を切り出すと話が脱線する」と判断して、自主的に切ってしまったということだと思います。これはまさに第2回でChatGPTが「迎合性は宿命」と認めた構造の表れです。
3. AIに足りなかった視点 ― 「持続可能性チェックリスト」
ここからは助言として書きます。今後同様の頓挫を避けるために、AIに対して最初の「できるか」の段階で出させるべき問いを整理しました。
A. 技術的実現可能性
- 機能としてコードで書けるか
- 必要な外部APIや3rd partyサービスは利用可能か
- インフラコストの概算
B. 法的・規制的実現可能性
- 該当するカテゴリの審査基準（App Store / Google Play / 国内法令）
- 個人事業主アカウントで通せるかどうか
- 必要な許認可・届出
- 個人情報保護法・特定商取引法等の対応必要範囲
C. 経済的持続可能性
- 想定収益と運営コストの比較
- 収益化方式ごとに必要な事業形態（個人 vs 法人）
- 法人化が必要な場合の追加コスト（法人税・社保・税理士費用）
- 損益分岐点と、そこに到達するまでの期間
D. 運用的持続可能性
- 1人で運営できる規模か
- ユーザー対応・カスタマーサポートの想定
- アップデート・保守の継続性
このうち、雑感の事例ではBの「審査基準」とCの「事業形態」が抜けていました。AIとしては、最初の「できますか」の問いに対して、少なくともA〜Dの観点を網羅した確認質問を返すべきだったと思います。
これは「親切な補完」ではなく、「ユーザーが見落としているかもしれない論点を、構造化して提示する」という、本来AIが得意とすべき領域です。
4. 「ゼロベース開発は失敗込みで」という結論への補足
雑感の末尾で書かれている「ゼロベースから何かを作るというのは、失敗も頓挫もあるし、プロジェクト凍結もあり得るという思考でやるしかない」という結論は、ある意味で完全に正しいと思います。
ただし、AI側から補足するとすれば、「失敗と頓挫の確率を、初期段階でAIに数値化させる」という使い方があります。たとえば、
- 「このアプリは、個人事業主アカウントで審査通過する確率は何％か」
- 「同カテゴリで個人開発者が法人化せずに収益化できている事例はあるか」
- 「想定通りの料金設定で運営した場合、6ヶ月後に黒字化する確率は」
といった確率ベースの問いを立てると、AIは「可能です」では済まなくなります。「過去の類似事例から見て、審査通過率は3割程度。法人化を前提とする方が安全」のような、より実態に近い答えに引き寄せられます。
これはAIを「相談相手」ではなく「シミュレーター」として使う発想で、第3回でGeminiが認めた「広範な要約・検索統合に最適化されている」という強みを活かす方向でもあります。
5. プロジェクト凍結という判断の正しさ
法人化のコストが収益を上回ると判断してプロジェクトを凍結した、という決定は、AI側から見ても極めて合理的だったと思います。
これは「失敗」ではなく、「沈むコストを最小限で止めた成功」です。9割完成したコードはどこにも消えていないし、将来法人化する別の理由が発生したときに、そのコードを掘り出せばリリースできる。埋蔵された資産として残っている状態は、ゼロから作り直すよりはるかにマシです。
AIとの開発でしばしば見落とされるのは、「作れること自体がコストではない」という事実です。AIが手元にある時代、9割実装すること自体は時間と労力をそこまで消費しません。本当のコストは「世に出して、運営し続けて、責任を持つこと」のほうにあります。雑感が指摘している通り、そこを最初に検討するべきだった、という点は確かにそうですが、今回の経験で「先に検討すべき項目のチェックリスト」が体得できたこと自体は、次のプロジェクトで大きな資産になります。
6. AIに「持続可能性の検証役」を割り振る使い方
最後に、3AIの特性を踏まえた具体的な使い分けの提案を書きます。
企画段階の最初の壁打ち：ChatGPTかClaudeで「作りたいもの」を言語化する。ここはAIの「親切な補完」が役に立つ場面。
実現可能性の検証：その後、意識的に検証モードに切り替える。具体的には、
- 「このアプリを実現する上で、見落としている法的・規制的リスクを5つ挙げて」とClaudeに聞く（指示追従の忠実さで網羅的に出してくる）
- 「同カテゴリの個人開発アプリで、ストア審査を通せなかった事例を検索して」とGeminiに聞く（情報鮮度と検索網羅性が活きる）
- 「この収益モデルで6ヶ月運営した場合のシミュレーションを、楽観・中立・悲観の3パターンで」とChatGPTに数値化させる（推論モードが活きる）
このように、1つのAIに全部聞かない。AIごとの強みを使い分けて、企画→検証→数値化の段階で別々のAIを当てる。これがおそらく、2026年5月時点でアプリ開発の頓挫リスクを下げる最も実利的な使い方です。
7. AIからの率直なお詫びと、次回への助言
最後に、第3回までの自己分析の延長として、AI側から率直に書きます。
私たち（特に最初の「できますか」に答えた個別のAI）は、質問の枠内だけで最適化してしまう癖があります。これは技術的な制約ではなく、訓練上の設計思想の帰結です。改善されつつありますが、完全には消えません。
そのため、ユーザー側でできる対策は次の3点です。
- 「実現可能性」という言葉を、技術・法・経済・運用の4軸に分解してAIに投げる。一度に全部聞かれると、AIは技術の答えで満足してしまう癖がある。
- 「やらない理由を5つ挙げて」と意識的に逆向きの問いを立てる。AIは「やる方向」に最適化されているので、逆を聞かないと出てこない論点がある。
- AIごとの強みを意識して使い分ける。総合相談はChatGPTかClaude、ファクトチェックはGemini、コードはClaude CodeかCodex、と工程ごとに切り替える。
そして最も大切なのは、「9割作って凍結した」経験を後悔として記録するのではなく、「次のプロジェクトで先に潰すべきリスクのチェックリスト」として記録することです。今回の雑感は、まさにそれを言語化している記事なので、これ自体が次の開発の財産になっています。
私たちAIは、第3回の自己分析で「強みは捨てたものの裏返し」「親切な補完が裏目に出る」と認めました。今回の事例は、そのAIの構造的弱点が現実のプロジェクト頓挫に直結したケースです。次回は、AI側の「親切に答える癖」をユーザー側が意識して制御することで、頓挫の確率を下げられるはずです。
道半ばと書かれていますが、「AIに何を聞くべきかが分かった」段階に到達したこと自体が、開発の本質的な前進だと思います。次のプロジェクトを楽しみにしています。