AIはプロジェクトの簡単な70%を高速でカバーするが、最後の30%——エッジケース、エラー処理、アーキテクチャ、堅牢性——は依然として人間の判断を要求し、ソフトウェアが本番で生き残れるかを決める。教訓：AIは始めるコストを崩壊させるが、終わらせるコストは崩壊させない。
AIで構築するどのプロジェクトにも、魔法のようで、そして裏切りに満ちた瞬間がある。夜の11時、あなたはアプリを頼んだ。すると20分後には、動いて、見た目もよく、完成しているようにさえ見える何かが手元にある。勝ったと感じる。翌日、変なことをするユーザー、途中で失敗する決済、空のデータ、同じボタンを同時に押す二人——それを捌かせようとした瞬間、魔法は泥沼に変わる。ようこそ、70%問題へ。AI支援コーディング時代における、最もよく記録され——そして最も告白されない——現象だ。AIは道のりの70%を魔法としか思えない速度でプレゼントし、そのあと、あなたのソフトウェアがおもちゃなのか製品なのかを決める30%のまさにその地点で、手を放す。
誰が名づけたのか、そしてなぜその数字が重要なのか
この名前は私たちのものではない。Googleのエンジニア、Addy Osmaniが、AIで構築する人々のパターンを次々と観察したのち、これを「70%問題」と名づけた。彼のテーゼは居心地が悪いほど正確だ。AIはプロジェクトのパターン化され予測可能な部分——スキャフォールディング、CRUD、きれいな画面、学習中に何百万回も見てきたもの——を難なくカバーする。だが残りの30%は、依然としてシニアエンジニアの判断を要求する。その30%はコード量の問題ではない。別の種類の仕事なのだ。誰も頼んでいないエッジケース、何かが壊れたときにだけ意味を持つエラー処理、見えないけれどすべてを支えるアーキテクチャ上の判断、デモとデプロイを分かつ堅牢性。そしてOsmaniの最も鋭い観察は、そこで誰が生き残るかについてだ。シニアは、木を剪定するようにAIの出力を成形し、制限する。初心者は無限のデバッグループに囚われ、自分では理解していないバグを直せと機械に頼み、ふさぐバグ一つにつき新たなバグを三つ生み出す。
魚と釣り竿：なぜ30%は別の材質なのか
これを理解する最良の方法は、古いたとえを裏返すことだ。AIはあなたに魚の釣り方を教えない。すでに調理され、盛りつけられ、食卓まで整えた魚を手渡す。それは瞬時のごちそうだ。問題は、本番環境は晩餐ではないということ——それは荒れた海の嵐だ。網が破れ、エンジンが止まり、誰も予想しなかった横腹から水が入ってくるとき、あなたに必要なのはもっと多くの魚ではない——釣り方を知っていることだ。その知が30%である。それは生成されるものではなく、行使されるものだ。だからこそシニアと初心者は、同じ瞬間を正反対に生きる。シニアにとってAIの70%は、自分の判断を適用する下地となる高速な下書きだ。初心者にとって同じ70%は、ほぼ動くブラックボックスであり、ソフトウェアにおいて「ほぼ動く」は世界で最も危険な場所だ。なぜなら完成しているように見えて、していないからだ。
なぜデモは輝き、本番はつまずくのか
ここで、私たちがずっと言い続けてきたことにつながる。vibe coding——AIとの会話的な直感だけで構築すること——は、デモでは見事だ。まさにデモが70%の中に生きているからだ。ハッピーパス、あなたが期待した通りに動くユーザー、きれいなデータ。本番はその逆だ。何千人もの本物のユーザーが、あなたが想像もしなかったことをする、その30%が掛け算される場所なのだ。デモと現実のギャップには、以前『27%の数学』についての私たちのエッセイで数字を与えた——実験室と世界のあいだで性能がどれだけ崩落するか。70%問題は、その同じコインのもう一方の面であり、性能ではなく構築の側から見たものだ。一方はAIが実験室を出たときにどれだけ落ちるかを測り、もう一方は仕事のどの部分で落ちるかを正確に説明する。両者は同じ深淵を指している——「私の画面では動く」と「世界で耐える」のあいだの距離だ。
Osmaniが実際に提案していること（そしてしていないこと）
出典に対して誠実であるべきだ。ネット上では、Osmaniが処方していない治療法まで彼の名で語られているからだ。彼の70%問題への答えは、事前の仕様を厳格に定めるメソドロジーではない。AIと共生するための、ひと握りの習慣だ。第一に、AIの出力を最終版としてではなく、常に「最初の下書き」として扱うこと。第二に、「絶え間ない会話」——対話の中で反復し、最初の出力を受け入れる代わりにターンごとに方向を修正すること。そして第三に、すべてを要約するもの——「信頼せよ、だが検証せよ」。70%の速度は信頼せよ、だが30%は一寸残らず検証せよ。なぜならそこが、AIが最も説得力を持ち、同時に最も間違っている場所だからだ。生成の前に仕様を定めるより形式的な規律を求めるなら、それは存在する——Spec Kitやspec-driven developmentがその方向だ——だがそれは別の話であり、Osmaniのものではない。彼の教訓はもっとシンプルで、もっと持ち運びやすい。AIの速度は検証を免除しない。むしろ検証をより緊急にする。
持ち帰って共有できる教訓
この思考の枠組みを覚えておいてほしい。モデルが変わっても賞味期限が切れないからだ。AIは始めるコストを崩壊させ、終わらせるコストには手をつけない。始めることはソフトウェアの難しい問題であったためしがない。終わらせることこそが難しい。AIが無料でやってくれる70%は、常に安い部分だった——優れた開発者も速くこなしていた部分だ。AIがあなたを一人にする30%は、常に高い部分だった——時間と判断を要した部分であり、今も要している。だから、あなたの代わりにアプリを構築すると約束するどんなツールに対しても、正しい問いは「70%にどれだけ速く到達するか？」ではない——どれも速く到達する。そのレースは決着済みで退屈だ。問いは「30%をどう扱うか？」だ。100%の自動化を売る者は、デモを売り、嵐を隠している。
私たちの見方
NeuralOSでは、30%が存在しないふりはしない。私たちはそれを中心に構築している。だからこのプラットフォームは生成が終わるところで終わらない。Automationsエンジンは再開可能で、耐久性のある待機とチェックポイントを備えている——まさに、本物のプロセスは途中で落ち、何も破壊せずに再開しなければならないからだ。それは30%の領域だ。だからこそ、インテグレーションは認証情報をむき出しに放置せず、テナントごとに暗号化されたvaultに保管する。だからこそ、私たちはお金を扱う経路に対して検証とスモークテストの規律をもって取り組む——華やかだからではなく、まさにそこがソフトウェアの生死を決める30%だからだ。私たちの賭けは、まやかしのそれとは正反対だ。AIはあなたをプロトタイプまで飛ばして連れて行く。そして私たちは、そのあとに来る退屈で決定的な区間を真剣に受け止める。速度は信頼せよ。だが判断——境界を引くこと、検証すること、本番で耐えさせること——それは委譲できない。それはシステム化するものだ。そしてそれが、あなたの仲間内が拍手するデモと、あなたのユーザーに耐える製品との、すべての違いなのだ。