vibe codingは終わり。仕様書時代が来た

2026年、AIの神様が静かに前言撤回しました。 vibe codingという言葉を世に放った張本人、Andrej Karpathy本人が「これからはagentic engineeringの時代だ」と言い始めたんです。 しかも日本語圏では、まだほとんど誰もこの話を取り上げていない。 僕はClaude Codeとn8nを毎日触っているわけですが、ここ数ヶ月「AIに任せたら本番で事故った」「生成されたコードが2週間後に意味不明になっていた」という相談が一気に増えました。 たぶん同じ感覚を持っている個人事業主、結構いると思うんですよね。 この記事は、Karpathy本人の発言と海外主要メディアの議論を一次情報まで遡って整理した上で、日本の個人事業主・フリーランスが今日から取るべき行動を3つに絞ってまとめたものです。 読み終わる頃には、「明日から何を変えるか」が具体的に見えているはずです。 海外で何が起きているのか──Karpathy本人の方向転換 時系列で整理します。 2025年2月2日、Karpathyが「vibe coding」というワードを自身のXで投稿しました。「あなたはエージェントに何をするか伝えて、結果を評価するだけ。重要なのはHOWに踏み込まないこと」という意味づけでした。 これが爆発的に広まり、Collins Dictionaryの2025年Word of the Yearにも選ばれます。Wikipediaにも独立した項目ができました。 ここまでが2025年の話です。 そして2026年、Karpathy本人がSequoia主催のAI Ascent 2026の場で、「one-shotプロンプトの時代は終わり、agentic engineeringへ移行している」と明確に方向転換を宣言しました。 The New Stackが「Vibe coding is passé」というタイトルで取り上げ、aintelligencehub.comも「Vibe Prompts to Agent Workflows」という記事を出しています。海外では完全に潮目が変わったんです。 Karpathy本人の定義はこうです。 「agentic engineerは生成されたコードを盲目的に受け入れない。仕様を設計し、計画を監督し、差分を検査し、テストを書き、評価ループを作り、権限を管理し、worktreeを分離し、品質を保つ」 …単なるプロンプト職人ではなく、仕様書を書ける人が次の時代を作る、と本人が言い始めたわけです。 なお、本記事執筆の数日前である2026年5月13日には、OpenAIが「Codex Mobile Supervision」を発表しました。スマホ上でAIエージェントの作業を承認できる機能です。同時期にxAIも「Grok Build」というCLIコーディングエージェントをSuperGrok Heavy（月額$300）向けに投入しました。 Claude Code、OpenAI Codex、Grok Buildの三つ巴。エージェント側のスピードがさらに加速している今、人間側の「仕様書を書くスキル」の重要性は、本当に毎週上がっています。 海外インディーハッカーは、もう仕様書時代に適応している 抽象論だけで終わらせたくないので、海外の実例を1つ紹介します。 アメリカのインディーハッカー、Cameron Whiteside氏（プロダクト名「Kleo」）は、AI支援開発スタックで3ヶ月で月収$62,000（MRR）に到達したと、IndieHackersとMediumで本人が公表しています。 彼のプロダクトはLinkedIn向けのコンテンツ作成Chrome拡張で、複数の共同創業者（合わせて50万フォロワー規模）と組んで、プリローンチwebinarだけで$5,000以上売り上げてから本格ローンチしました。 出典: tamimbuilds.medium.com「8 Solo Founders Who Quietly Hit $20K–$62K MRR in the Last 6 Months」（2026年4月） もう一人、Samuel氏という独学エンジニアは「StoryShort」（ブログ記事を動画に変換するSaaS）で約$20,000 MRR、「Capacity」と合算で$28,000 MRRに到達しています。スタックはNext.js + Node.js、彼自身が「AIツールで独学コーディング」と公言しています。 面白いのは、これらの成功者の多くが「仕様書とプロンプトの比率を逆転させた」と語っていることです。Cameron氏もインタビューで「最初の1時間は仕様を書くだけに使う。残りの作業はエージェントに任せる」と発言しています。 Claude Code単体で年間売上は$1B→$2.5B（半年で2.5倍）まで爆増していますが、本当に稼いでいる人は、Claude Codeに「何を作るか」を細かく指示できる人なんです。 日本で同じ規模を再現するなら、まず必要なのは仕様書テンプレートの自分化です。後ろの章で具体的に書きます。 vibe codingが週末プロジェクト限定である理由 ここで一度、Karpathy本人がvibe codingをどう位置付けていたか戻ります。 Wikipediaの「Vibe coding」項目にも明記されているのですが、Karpathy本人は「throwaway weekend projects」、つまり「使い捨ての週末プロジェクト向け」とハッキリ書いていたんです。 つまり最初から、本番投入は想定されていない技法だった。 でも実際には、多くの個人事業主・スタートアップがvibe codingで本番運用に突入してしまい、事故が増えました。Red Hat Developer Blogが2026年2月17日に公開した「The uncomfortable truth about vibe coding」では、典型的な失敗パターンが整理されています。 パターン1: Whack-a-Mole問題 Reddit投稿の引用がそのまま記事に載っているのですが、これがあまりに核心を突いています。 「AI is still just soooooo stupid and it will fix one thing but destroy 10 other things in your code.」 要するに、1つ直すと10個壊す。直しても直しても、別の場所が崩れる。 やったことある方、いますよね…。 パターン2: Functionality Flickering（機能のチラつき） 仕様を明文化していないと、AIが生成のたびに違う実装を出してきます。ボタンの色、エラーメッセージ、APIのレスポンス形式が毎回ブレる。「言わなかったから」という理由で。 パターン3: Lost Intent（設計意図の蒸発） コードベースが大きくなるにつれて、「なぜこの設計にしたのか」が完全に忘れられる。動いてはいるが、誰も全体像を把握していない状態に陥ります。 Red Hatの記事では「だいたい3ヶ月でこの壁に当たる」と書かれています。 副業や個人開発を3ヶ月続けて、急に開発速度が落ちた経験がある方は、ほぼこれが原因です。 spec-driven development（SDD）が次の標準である根拠 2026年に入って、海外の主要技術メディアが揃ってspec-driven development（SDD）の解説を出し始めました。 Augment Code「Vibe coding vs Spec-driven development」 BCMS「Spec-Driven Development: The Definitive 2026 Guide」 Towards Data Science「From Vibe Coding to Spec-Driven Development」 itential「Vibes to Specs Development」 Red Hat Developer Blog（前述） 書き手は別々ですが、全員が同じ方向を向いています。 そしてGitHubは2025年9月1日、公式に「GitHub Spec Kit」をリリース。仕様書を主軸にした開発フローをツール化しました。AmazonもKiroという同種のツールを出しています。 注目すべきは数字です。 GitHub・AWS発表: SDD導入チームは「first-pass success rate（一発で正しく動く率）が3〜10倍に向上」 AWS Kiro事例: 「40時間かかっていた機能が、仕様書を先に書くだけで人間の作業時間8時間で完成」（出典: thebcms.com） GitHub内部プロジェクト: 「regenerate from scratch（最初から作り直し）のサイクルが約1桁減少」 さらに、Carnegie Mellon University（CMU）の研究では、AIツール導入後にコード複雑度が約41%増加、静的解析の警告が約30%増加というデータが出ています。 要するに、vibe codingで速くなった分、後で全部返済している。Augment Codeの記事にあった「2021〜2024年にリファクタリング活動が約60%減少、コピペが約48%増加、コード重複が最大8倍」というデータがその証拠です。 短期で速くても、3ヶ月後に詰む。 だからこそ、最初の1時間を仕様書に使う方が、結果的に何倍も速い。これがSDDの経済性です。 個人事業主が今日から取るべき行動1：プロンプト中心から仕様書中心へ ここから実践編です。 大企業のSDDをそのまま個人がやるのは無理です。だから個人事業主向けに、3つの行動に絞りました。 まず1つめ。 プロンプト時間と仕様書時間の比率を逆転させる 今までのvibe coding的な作業は、感覚的に「プロンプト9：仕様1」くらいの時間配分だったはずです。 これを最低でも「プロンプト6：仕様4」、できれば「プロンプト3：仕様7」に変えます。 具体的には、Claude CodeでもCursorでも、コードを書かせる前に必ず以下のmarkdownファイルを先に作ります。 ・SPEC.md：作るものの目的、ターゲット、ユースケース ・REQUIREMENTS.md：機能要件、非機能要件、制約条件 ・PLAN.md：実装の段取り、各ステップで触るファイル この3つを15分でも30分でもいいから書く。書いたあとに「これに従って実装してください」とエージェントに渡す。 最初の1週間にやること 今動いているプロジェクトのうち、1つだけでいいので、後付けでSPEC.mdを書いてください。 「あれ、自分でも何を作っているか説明できない」という感覚が来たら、それが正解です。その違和感こそが、これまでvibe codingで蓄積してきた負債の正体です。 Claude CodeであればCLAUDE.mdに書く。Cursorであれば.cursorrulesに書く。n8nワークフローならNotionに仕様ページを作る。 仕様書の置き場所はツールごとに違いますが、考え方は全部同じです。 個人事業主が今日から取るべき行動2：見積もり・提案書も仕様書化する 2つめ。これはコーディング外の話です。 個人事業主にとって、AI時代の最大のレバレッジは「クライアントワークの仕様化」だと僕は本気で思っています。 見積もりが甘いと、AI時代は即赤字 従来は「ふんわり要件で受注 → 都度ヒアリングで埋める」が通用しました。 でも、AIに作業を任せる時代では、要件が曖昧だと「AIが何回もズレた成果物を吐く → 手直し連鎖 → 工数オーバー」が起こります。Karpathyの言うagent thrash（エージェントの空転）が、クライアントワークでも発生するんです。 対策はシンプル。提案書段階で仕様書化することです。 提案書テンプレートを「ミニ仕様書」化する 僕がn8n構築を受注する時に必ず入れている項目はこんな感じです。 1. ゴール（クライアントが達成したい状態） 2. 入力データ（どこから何が来るか、形式まで含めて） 3. 出力データ（どこに何を吐くか、形式まで含めて） 4. エッジケース（想定外が起きた時の挙動） 5. 保守責任の境界線（誰が何をメンテするか） これを提案書の段階で書ききると、受注後の手戻りが激減します。クライアントも「こんなに具体的に考えてくれているのか」と信頼してくれます。 副次効果として、提案書そのものがプロジェクト終了後に「再利用可能な仕様書資産」になります。次回似た案件が来た時、ほぼコピペで使い回せる。これがAI時代のフリーランスの真の資産です。 個人事業主が今日から取るべき行動3：仕様書ストックを業務資産にする 3つめ。最も中長期で効いてきます。 書いた仕様書を、必ず資産化してください。 具体的な保管フロー 僕がやっている方法を共有します。 ・案件ごとにNotionデータベース「Specs」を作る ・1案件 = 1ページ。最低限SPEC.md / REQUIREMENTS.md / PLAN.mdの3セクション ・タグでツール（Claude Code / n8n / Cursor）と業界を分類 ・案件終了時に「振り返り」セクションを追加。何が想定通り、何がズレたか これを半年続けると、「テンプレ仕様書」が30〜50本溜まります。 ここからが本番です。 仕様書ストックがAI時代の知財になる Claude Codeにはskillsという機能があります。Cursorにはルールファイルがあります。 蓄積した仕様書をこれらの機能に流し込むと、自分専用のエージェントが完成します。「過去30案件の仕様書パターンを学んだ自分」が、24時間働く状態が作れる。 さらに、優れた仕様書ストックは、それ自体が商品になります。 Note / Brain / Tipsで「業種別n8n仕様書テンプレート集」「LINE構築の発注仕様書テンプレ20本」のような形で販売できます。仕様書は「真新しさ」ではなく「目新しさ」、つまり既存パーツの組み合わせの妙で勝負できる商材です。 ここで思い出してほしいのは、コンセプトメイキングの原則です。コンセプトは「クリエイティビティ」ではなく「パズル」。既存の要素を組み合わせて見せ方を変えるだけ。仕様書ビジネスは、まさにこのパズル型の典型です。 仕様書を書ける人は、AI時代に「真のコンセプトを作れる人」と同義になります。 余談：日本ではまだ誰もこの話をしていない 最後に、戦略的な話をひとつだけ。 ここまで紹介したKarpathy本人のagentic engineering宣言、AI Ascent 2026での発言、Spec Kit、Kiro、SDDの数値根拠──これら一連の話を、まとまった形で扱っている日本語記事はまだほぼゼロです。 試しにGoogleで「vibe coding 終わり」「agentic engineering 日本語」「spec-driven development 個人事業主」あたりで検索してみてください。海外メディアの英語記事ばかり出てくるはずです。 これは大きなチャンスです。 Xでも、Noteでも、YouTubeでも、いま日本語で先取りして発信すれば、確実に伸びます。なぜならエンジニア・個人事業主・フリーランスは、誰もが「自分の仕事がAIにどう侵食されるか」を毎日考えているからです。 海外で議論済みの話題を、日本の文脈に翻訳して届けるだけで、価値が出ます。 僕自身、この記事をきっかけにn8n × spec-driven開発のテンプレ集を準備中です。仕様書ストックをそのまま販売物にする実験でもあります。 もしこの話が刺さったら、ぜひあなたの専門領域でも「仕様書化」の発信を始めてみてください。1年後、振り返って「あの時に始めて良かった」と思えるはずです。 そしてもう少し具体的に深掘りしたい方は、僕のXもフォローしておいてください。Karpathy本人の続報、Spec Kit / Kiro / Claude Code skillsの実践テンプレ、海外インディーハッカーの最新事例を、毎週日本語で先取り解説していきます。 まとめ ここまでの内容を整理します。 ・Karpathy本人がAI Ascent 2026で「vibe coding → agentic engineering」へ方向転換を宣言 ・vibe codingは元々「使い捨ての週末プロジェクト向け」と本人が明言していた ・本番投入では3ヶ月で必ず壁に当たる（Whack-a-Mole / Flickering / Lost Intent） ・spec-driven development（SDD）で一発成功率3〜10倍、40時間が8時間に ・個人事業主の3アクション: 仕様書中心へ / 提案書を仕様化 / 仕様書を資産化 ・日本ではまだ誰もこの話をしていない。先取り発信は確実に伸びる AI時代に生き残るのは、AIに任せる人ではありません。AIに正しい仕様書を書ける人です。 プロンプトを上手く書ける人は、もう一定数います。でも、AIに渡せる仕様書を体系的に書ける人は、まだ圧倒的に少ない。 そこに、これからの個人事業主の勝ち筋があります。 まずは今日、いま動いているプロジェクトのうち1つだけ、SPEC.mdを書いてみてください。違和感が出たら、それがあなたの伸びしろです。 ここまで読んでくれてありがとうございます！ 僕の公式LINEに登録してもらうと、登録特典として無料プレゼント5本がまとめて受け取れます。 Brain／Tipsで初月10万を狙う「ローンチ7日完全台本」 万インプを連発する「バズX記事TOP30」勝ちパターン解剖レポート フォロワー0から3ヶ月で1,000人を狙う「X急成長ロードマップ」 引用RTで月100フォロワーを狙う「qrt職人テンプレ10型」 SNS運用を月1回30分に圧縮する「AI自動化の完全設計図」 僕自身、このノウハウ通りに動かして、note経由で50万円の売上、Xでは1本の記事で7万インプレッションを出しています。 ▼こま｜n8n × AIよろず屋 公式ラインはこちらから https://dz2knout.autosns.app/line