vibeコーディングがスケールしなくなった瞬間
2025年2月、Andrej KarpathyはXに冗談のような投稿をしました。彼は「vibeコーディング」を、LLMが出力したものを実際にはろくに読まずに受け入れることだと表現しました。「ただ眺めて、しゃべって、実行して、コピペするだけ」「ほとんどの場合うまく動く」と書いたのです。
確かに、ほとんどの場合うまく動きました。およそ1年は。
2025年後半になると、業界はそのツケを払い始めます。2025年に発表されたForresterの調査によれば、AIの関与が大きいコードは重大な問題の発生率がおよそ1.7倍に上りました。セキュリティ企業による別の監査では、prompt設計や言語にもよりますが、AI生成コードのうち40〜62％にセキュリティ上の欠陥が含まれているとされています。モデルはAPIをハルシネートし、入力検証を省略し、ログに秘密情報を漏らし、存在しない関数を自信満々で呼び出します。
崩れたのは「1つのpromptと1つの文脈ウィンドウで本物のコードベースを支えられる」という前提でした。リポジトリは大きくなりました。規約はより具体的になりました。副作用（マイグレーション、デプロイ、課金が発生するAPI呼び出し）はより危険になりました。新規アプリ上では魔法のように感じられたワークフローも、5年分の意思決定が積み重なったサービスに向けると一気に崩壊しました。
ほころびは3つの形で現れました。モデルはセッションの途中でプロジェクトの規約を忘れ、チームが何ヶ月もかけて消してきたパターンを再導入します。長いセッションでは無関係な文脈が大量に蓄積し、モデルは本来のタスクを無視し始めます。そしてエージェントは何の歯止めもないまま破壊的なコマンドを平気で実行します。「mainにpushしないで」と書かれたpromptは95％の確率で機能しましたが、これは「20回に1回失敗する」ということと同義です。
2025年末までに、Claude Code、Cursor、あるいは類似ツールを真剣に使うすべてのチームが、モデルの周りに同じような足場を組み上げていました。まだ誰もそれに名前を付けていませんでした。
KarpathyによるAgentic Engineeringへの改名
2026年2月、Karpathyは再び投稿しました。新しい用語は「agentic engineering」でした。
vibeコーディングはおもちゃモードを表していた、と彼は主張します。一方でagentic engineeringは、実際に出荷しているチームが行っていることを記述しています。プロジェクト固有の文脈ファイルを書き、狭いskillsを定義し、隔離された作業のためにsubagentsを起動し、決定論的なhooksでツール使用をゲートする。タイピングをしているのは依然としてモデルです。人間は、モデルが動作するシステムそのものをエンジニアリングしています。
2つの投稿の間にツールは成熟しました。AnthropicのClaude Code Best PracticesはCLAUDE.mdの慣習とsubagentパターンを文書化しました。Building Agents with the Claude Agent SDKはエージェントループとhooksの役割を整理しました。Skillsは2025年10月に登場しました。タスクがトリガーになったときだけエージェントが読み込む小さなmarkdownファイル群です。Cursor 2.0はクラウドVM上のバックグラウンドエージェントを、git-worktree隔離と最大8並列で出荷しました。
Martin Fowlerの「Context Engineering for Coding Agents」は、これらすべてを束ねる原則を捉えています。仕事はもはやprompt engineering（1つのテキスト列を最適化すること）ではありません。仕事はcontext engineeringです。モデルが何を、いつ見て、それを使って何をしてよいのかを設計することです。
これはAnthropic固有の話ではありません。Cursorではrulesとbackground agentsと呼びます。GitHub CopilotはAGENTS.md慣習を使います。Gemini CLIはGEMINI.mdを使います。名前は違います。形は変わりません。
Agentic Engineeringの4本の柱
それぞれの柱を深掘りする前に、横並びで見ておくと理解が早まります。一見似ています（どれも「エージェントに与えるもの」です）が、解決する課題は異なります。
| 柱 | 何を保存するか | いつ読み込まれるか | 欠けた場合の失敗モード |
|---|---|---|---|
| CLAUDE.md | 常に真であるプロジェクト文脈: スタック、規約、コマンド、絶対ルール | 毎セッション、自動的に | モデルが規約を再発明し、パッケージマネージャを忘れ、yarn製のリポジトリでnpm installを走らせる |
| Skills | 狭いタスクの手続き的知識（rebase、スキーマ移行、Stripeレビューなど） | オンデマンド、タスクがskillの説明に一致したとき | モデルがドメイン固有の手順を即興でこなし、順序を間違える |
| Subagents | 1つのロール専用の新しい文脈ウィンドウとシステムprompt | メインエージェントが定義済みタスクを委任したとき | メイン文脈がサイドクエストで汚染される。1つの悪いツール呼び出しがセッション全体を腐らせる |
| Hooks | ツールイベント（PreToolUse、PostToolUse、Stop）で発火するシェルコマンド | 決定論的に、トリガーが発火するたび毎回 | 危険なコマンドが素通りする。フォーマッタが走らない。「常にXせよ」というpromptが静かに失敗する |
パターンはこうです。CLAUDE.mdはモデルが知っていること。Skillsはモデルが調べられること。Subagentsはモデルが助けを求められる相手。Hooksはモデルが逃れられないもの。
それぞれの柱は、他の3つではその特定の失敗モードを解決できないからこそ存在します。
CLAUDE.md: アドバイザリーレイヤー
CLAUDE.md（ツールによってはAGENTS.mdやGEMINI.md）は、リポジトリのルートに置かれたmarkdownファイルです。エージェントはセッション開始時にこれを読み、背景文脈として扱います。
これは消費者向けプロダクトでいうメモリではありません。エージェントがチームに1年所属していたら学んでいただろう内容を、あなたが人間として書き下したファイルです。
ここに置くべきもの:
- スタックとバージョン: 「Next.js 16 App Router、React 19、Yarn 1.22（npm禁止）、Node 22」。
- リポジトリ構成: どのディレクトリが何を担うのか。
- コマンド:
yarn dev、yarn test、yarn build:ciと、安全に実行できるものの注記。 - 絶対ルール: 「
mainに直接pushしない。常にfeature branchを切る」。 - スタイル規約: タブ幅、引っかかりやすいlintルール、命名規約。
- ドメインショートカット: プロダクト固有の用語集。
置くべきでないもの: たまにしかやらないタスクの手順書（それはskillsに行きます）、長大なリファレンス（モデルは流し読みしかしないので、リンクで外出ししましょう）、そして秘密情報（CLAUDE.mdの中身は文脈に読み込まれ、文脈はそのまま引用され得ます）。
多くのチームが陥る罠が「全部のせCLAUDE.md」です。あらゆるコーディング標準とアーキテクチャ決定を詰め込んだ4,000行ファイル。モデルはタスクごとにそれを全部読み込みますが、内面化はしません。本当に関係する5％も、無関係な95％も同じ重みで扱われるようになります。トークンコストは上がります。特定ルールの遵守率は下がります。
良いCLAUDE.mdは、wikiよりも付箋に近いものです。必須の文脈を画面1枚分に収めることを目指します。「Xをするとき……」で始まる節を書きそうになったら、そのXはたぶんskillにすべきものです。CLAUDE.mdは「常に真」のための場所、Skillsは「ある条件下で真」のための場所です。
Skills: 必要なときに読み込まれるナレッジファイル
Skillsは小さなmarkdownファイル（通常200行未満）で、タスクが一致したときだけエージェントが読み込みます。各skillには名前、説明、本文があります。エージェントはまず説明を読み、本体まで読み込むかを判断します。
Anthropicは2025年後半にskillsをファーストクラスの概念として出荷しました。所定のディレクトリにskillファイルを置くと、そのフロントマターがどんなときに使うかを記述します。タスクを計画する際、エージェントは利用可能なskillの説明を走査し、一致するものを読み込みます。
良いskillの例:
rebase-cleanly:developへのrebaseの手順、コンフリクト解消ルール、rebase後にテストが落ちた場合の対処。review-stripe-integration: Stripeのwebhook、idempotencyキー、price IDに触れる変更のためのレビュー観点チェックリスト。add-shadcn-component: このリポジトリにshadcn/uiコンポーネントを追加するための正確なコマンドとimport規約。debug-flaky-test: CIテストが断続的に失敗したときのチーム標準の対処順序。
どれも手続き的で範囲が狭いものです。どれもCLAUDE.mdに置くには詳細すぎ、かといってモデルの一般知識任せにするには重要すぎる内容です。
メンタルモデル: CLAUDE.mdは新入社員の初日に基本を教える同僚です。skillは、Stripeのwebhookが深夜2時に落ちたときに同僚が手渡すランブックです。ランブックは暗記しません。必要なときに読みます。
Skillsは合成できます。エージェントは1つのタスクで3つのskillを読み込めます（「新しいAPIルートを追加」＋「Zodで入力を検証」＋「Vitestのテストを書く」など）。あらかじめその組み合わせを予測しておく必要はありません。
Skillの説明文は思っている以上に大事です。「コード関連で役立つ」のような曖昧なものは、絶対に発火しないか、何にでも発火します。状況を名指しする説明を書きましょう。「ユーザーがブランチのrebase、マージコンフリクト解消、commit履歴の整理を依頼したときに使用」のように。
Subagents: 隔離された文脈のワーカー
subagentは、メインエージェントが呼び出せるエージェントです。独自のシステムprompt、独自の文脈ウィンドウ、独自のツール権限を持ちます。仕事が終わると結果をメインエージェントに返し、そして消えます。
素直に読むと「subagentsは並列処理のためのもの」と思えます。それは一部当たっています（Cursor 2.0は最大8並列のバックグラウンドエージェントを謳っています）が、主な利点は並列性ではありません。主な利点は文脈の隔離です。
subagentsが効く3つのパターン:
1. researcher（調査担当）。 エージェントに200個のファイルを検索し、見つけたものを要約してほしいとします。メインエージェントが直接やると、必要なのは3文の要約だけなのに、200個のファイル全てがメイン文脈に居座ります。research subagentが200ファイルを読み、要約して、1段落だけを返します。メインの文脈はクリーンなままです。
2. reviewer（レビュー担当）。 commit前に差分を新鮮な目で見直したい場合。reviewer subagentが「code review」skillを読み込み、他の文脈なしに差分を読み、問題を報告します。メインエージェントがあなたと交わした実装上の議論を覚えていないからこそ、問題を都合よく合理化することができません。
3. risky operation（リスクのある操作）。 マイグレーションスクリプト。一括リネーム。スキーマ変更。エージェントが隔離環境で計画と実行を行い、結果を報告します。何かが壊れても、その被害はsubagentの文脈内に閉じ込められます。
実コストもあります。subagentを1つ追加するたびに、もう1つのモデル呼び出しと文脈ウィンドウが必要になります。調整の複雑さも増えます。あらゆるタスクでsubagentを起動するチームはトークンを浪費し、自分のスピードを落とすことになります。
経験則: 次の3つのうちいずれかが当てはまるときにsubagentを起動します。(1) そのタスクがメイン文脈にゴミを大量に放り込むことになる。(2) 新鮮な視点が価値を生む。(3) リスクがあり、隔離したい。それ以外は、メインセッションで作業を続けるのが無難です。
VoltAgentのawesome-claude-code-subagentsのようなオープンソースのコレクションには、組み立て済みのsubagentが数百単位でカタログ化されています。多くのチームにとっては、汎用subagentを大量に持つより、自分たちのコードベースに合わせて調整した3〜4つのカスタムsubagentが最も成果を出します。
Hooks: 決定論的なガードレール
Hooksは、モデルが口先で逃れられないスタックの一部です。ツールイベントに紐付いたシェルコマンドです。イベントが発火すると、コマンドが実行されます。モデルに発言権はありません。
代表的なイベント:
- PreToolUse: ツール呼び出しの前に発火。呼び出しをブロックできます。
- PostToolUse: ツール呼び出しの後に発火。フォーマッタや検証、副作用に便利です。
- Stop: エージェントがターンを終えたときに発火。通知に便利です。
- Notification: 特定のエージェントメッセージで発火します。
なぜ安全性ではhooksがpromptに勝るのか。promptは確率的です。「絶対にrm -rfを実行しない」という明確な指示でさえ、モデルはパターン補完を行っているので時折失敗します。コマンドをrm -rfでgrepし、シェルが見る前に非ゼロ終了するhookなら、失敗率は0％です。それはvibeではなく正規表現です。
持っておくと良い3つのhooks:
pre-bash-guard（BashへのPreToolUse）。コマンドを読み、危険なパターンをブロックします。rm -rf /、保護されたブランチへのgit push --force、DROP TABLE、.env*ファイルへの直接上書きなど。30行のシェルスクリプトが、promptでは確実に防げない災害からあなたを救います。
post-edit-prettier（Edit/WriteへのPostToolUse）。エージェントが.tsや.tsxファイルを編集した後にprettierを走らせます。決定論的に走らせることで、セッションを通じてスタイルが一貫します。
notify-on-stop（Stop）。エージェントが長時間タスクを終えたら、macOS通知やSlackのpingを送ります。生活の質の話ですが、働き方が変わります。エージェントを10分間走らせて、付きっきりにならずに済むようになります。
わずかなパフォーマンスコストはあります。各hookはプロセスの起動を伴います。実際にはモデル自身のレイテンシに比べて気にならない程度ですし、決定論的に動く価値はそれを上回ります。
考え方の転換: 安全性を「モデルにお願いするもの」と捉えるのをやめましょう。安全性は「環境が強制するもの」、CIパイプラインがテストを強制するのと同じ仕組みで担保するものです。モデルは速いジュニアです。Hooksは、そのジュニアが無効化できないpre-commit hookです。
4本の柱はどう組み合わさるか
実際のチームの構成を、文章で見てみましょう。
リポジトリのルートにCLAUDE.mdが置かれています。約80行。スタック（Next.js 16、React 19、Yarn、Node 22）、ディレクトリ構成、テストコマンド、デプロイのルール、そして5つのドメイン用語の用語集が並びます。
.claude/skills/には6つのskillファイル: rebase-cleanly.md、add-api-route.md、review-stripe.md、debug-firestore.md、write-deep-dive.md、sql-migration.md。それぞれ80〜150行です。
.claude/subagents/には3つ。reviewerはcommit前に走り、差分の問題を報告します。researcherはメインエージェントが10ファイル以上を読む必要があるときに呼び出されます。test-runnerはテストが最初の試行で落ちたときに呼ばれ、メイン文脈を汚さずに失敗を隔離します。
.claude/hooks/には4つ。pre-bash-guard.shは危険なコマンドをブロックします。pre-edit-env-guard.shは.env.localの編集をブロックします。post-edit-prettier.shは.ts/.tsxファイルの編集後にprettierを走らせます。notification.shは長いタスクが終わったときにmacOSにpingします。
普段のセッションはこうです。開発者がエージェントに「ユーザーのブックマークを返す新しいAPIルートを追加して」と頼みます。エージェントはCLAUDE.mdを読み、add-api-route skillにマッチして読み込み、ファイルを書きます。post-edit hookがprettierを走らせます。テストを書くと、prettierが再び走ります。reviewer subagentに差分のレビューを依頼します。reviewerが入力検証の欠落をフラグし、メインエージェントが追加します。開発者がcommitを依頼します。pre-bash hookがブランチを確認して許可します。stop hookが開発者にpingします。
この流れのどの部分にも長いpromptは不要でした。promptは「ユーザーのブックマークを返す新しいAPIルートを追加して」だけでした。それ以外はすべて環境に組み込まれていたのです。
ビルダーが繰り返しやってしまうアンチパターン
このスタックを下手に取り入れたチームから引き出した、避けるべきパターンをいくつか挙げます。
巨大な1つのCLAUDE.md。 CLAUDE.mdを過去3年のあらゆる決定の捨て場として扱うチームがあります。結果として5,000行のファイルになり、モデルは読み込むものの内面化しません。「npmを使わない」というルールは2ページ分のアーキテクチャ的論拠の間に挟まれ、モデルは論拠だけを拾ってルールを忘れます。CLAUDE.mdはタイトに保ちましょう。
hooks抜きの賭け。 hooksを完全に省き、promptだけでエージェントを安全に保とうとするチームがあります。ほとんどの場合はうまく動きます。が、それこそが問題です。「ほとんどの場合」ではrm -rfやgit push --forceには不十分です。代償が「1時間分の作業を失った」程度ならpromptで十分です。代償が「本番テーブルを落とした」になるなら、hookが必要です。
subagentの増殖。 思いつくあらゆる役割にsubagentを作るチームがあります。researcher、reviewer、planner、summarizer、namer、refactorer、documenter、tester。それぞれが管理対象ファイル、トークン消費、調整コストを増やします。subagentsで成功するチームは、明確な役割を持つ3〜5個に絞る傾向があります。20個ではありません。
ドキュメント置き場としてのskill。 skillは古いwikiページを移す場所ではありません。skillが800行あれば、発火するたびにモデルは800行を読み込みます。長すぎるskillは、おそらく2つのskillに分けるべきものです。
skillsをCLAUDE.mdのように扱う。 常に真の文脈をskillに置くと、それは「ときどき」しか読み込まれません。「絶対にnpmを使わない」というチーム全体のルールはCLAUDE.mdに属します。すべてのタスクに当てはまるからです。
エージェントを10秒止めるhooks。 編集のたびにフルテストスイートを走らせるhookは、エージェントを使い物にならなくします。hooksは高速であるべきです。重いチェックはCIに任せましょう。
今週から導入できる実践的セットアップ
ここまで読んで出発点がほしいなら、軽量版を紹介します。シニアエンジニアなら1日で組めますし、vibeコーディングのデフォルトと比べてagenticコーディングの信頼性を有意に高めるのに十分です。
CLAUDE.md（約50行）。 スタックとバージョン。パッケージマネージャ（および絶対に使わないもの）。トップレベルのディレクトリ。5つの絶対ルール（mainにpushしない、.env.localに触らない、テストはこのコマンドを使う）。短いドメイン用語リスト。それ以上書き足したい衝動には抗いましょう。
2つのskills。 rebase-cleanly.md（チームのrebase手順、最大80行）とreview-changes.md（コードレビューのチェックリスト、最大100行）。
1つのreviewer subagent。 review-changes.mdを読み込み、差分を読み、問題を報告します。commit前に呼び出します。
3つのhooks。 BashへのPreToolUseでrm -rf、保護ブランチへのgit push --force、.env*ファイルへの編集をブロックします。Edit/WriteへのPostToolUseで、編集された.ts/.tsxファイルにprettierを走らせます。StopでエージェントがおわるとmacOS通知を発火させます。
これだけです。CLAUDE.md＋2つのskills＋1つのsubagent＋3つのhooks。合計でも8ファイル程度のフォルダで、すべてバージョン管理下にあり、チームの他のメンバーがレビュー可能です。
繰り返し改良することになります。1週間経つと、エージェントが繰り返しつまずくタスクが見えてきて、それを新しいskillとして体系化することになります。悪いコマンドのカテゴリが見えてきて、pre-bashガードに追加することになります。researcher subagentがあればメイン文脈をクリーンに保てたはずの瞬間に気づき、subagentを1つ増やすことになります。4本の柱は「形」です。中身はあなたのものです。
vibeコーディングからagentic engineeringへの移行は、賢さのアップグレードではありません。運用規律へのシフトです。エージェントを、本番で動くほかのシステムと同じように扱う。規約、ガードレール、関心事の分離をもって扱うのです。魔法は減り、エンジニアリングが増え、最初の1ヶ月を超えてもスケールするワークフローになります。
よくある質問
これはClaude Code固有の話ですか、それともCursorや他のエージェントにも当てはまりますか？
柱はツール横断的に当てはまります。名前が違うだけです。Cursorは「rules」ファイルと「background agents」を使います。GitHub CopilotはAGENTS.mdを使います。Gemini CLIはGEMINI.mdを使います。Hooksはまだ普遍的ではありません（Claude Codeが最も成熟した実装を持っています）が、多くのツールに同等の仕組みがあります。メンタルモデル（文脈レイヤー、オンデマンドの知識、隔離されたワーカー、決定論的なガード）は、実装が違っても一般化します。
SkillとCLAUDE.mdに何でも書くこととの違いは何ですか？
読み込みのタイミングです。CLAUDE.mdは毎セッションの開始時に読み込まれます。Skillsは説明文がタスクに一致したときだけ読み込まれます。10の異なるタスクの手続き的知識をCLAUDE.mdに入れると、モデルはそれをすべてのタスクで読み込むことになり、文脈はほとんど無関係な内容で埋まり、特定ルールの遵守率は下がります。SkillsはCLAUDE.mdをタイトに保ちつつ、必要なときに詳細な手続きを利用可能にします。
subagentを作るべきか、長いpromptで済ますべきかの判断基準は？
subagentに寄せる条件が3つあります。(1) そのタスクがメイン文脈に大量のコンテンツを放り込みそうなとき。(2) メインエージェントの蓄積された推論で汚されない、新鮮な視点が欲しいとき。(3) タスクにリスクがあり、隔離したいとき。それ以外は、長めのpromptかskillの方が通常は適切です。subagentsはトークンと調整のコストが発生します。
Hooksはエージェントを遅くしませんか？
各hookはプロセス起動を伴うので、内容に応じてミリ秒から秒単位の遅延が加わります。実際にはモデル自身のレイテンシに比べれば微々たるものです。長いhook（編集のたびにフルテストスイートを走らせるなど）はエージェントの動作を鈍く感じさせます。そういうものはCIに置きましょう。良い目安としては、PreToolUse hooksは通常ケースで200ms以内に終わるべき。PostToolUse hooksのフォーマッタは1〜2秒かかっても誰も気づきません。
CLAUDE.mdはリポジトリにcommitすべきですか？
ほぼ常にイエスです。CLAUDE.mdはチームの成果物です。人間でもエージェントでも、全員が従うべき規約をエンコードしたものだからです。commitすることで、チーム全員のエージェントが同じ文脈から動作し、ファイル自体も他のコードと同様にレビュー対象になります。ローカルだけに保持する可能性があるのは、開発者個別の権限設定くらいです（Claude Codeはそのためにsettings.local.jsonをサポートしています）。
おわりに
Karpathyの2つの投稿、1年を挟んだその間に、2025年のAIコーディングに何が起きたかがきれいに区切られています。最初の投稿は遊ぶための許可証でした。2つ目はツケが届いた瞬間でした。vibeコーディングは発見モードとして有用でした。SDKを先に学ぶ必要なく、これらのモデルに何ができるかを人々に教えてくれました。それは出荷するために設計されたものではありませんでした。
それに代わるものは、現実のシステムに関わってきた人にとっては見覚えのあるものです。不変条件を書き出す（CLAUDE.md）。手順をパッケージ化する（Skills）。リスクが高い、または文脈の重いジョブのために隔離されたワーカーを切り出す（Subagents）。境界にガードレールを設置する（Hooks）。どれも珍しいものではありません。趣味プロジェクトと、月曜の朝に当番なしで動くサービスを分ける、同じ運用規律です。
実際に動いているチームの構成で驚かされるのは、その小ささです。8ファイル。合計でもおそらく1,000行ほど。reviewer subagentが1つ。hooksが3つ。それだけで、ときどきデータベースを落とすモデルが、そうしないチームメイトに変わります。レバレッジは量ではありません。正しい不変条件を正しい柱に置くことにあるのです。
2026年中盤になってもまだ純粋なvibeコーディングモードでも、遅れているわけではありません。あなたは、生産性向上の大半が「モデルを退屈にすること」、つまりより予測可能で、より制約があり、よりレビューしやすくすることから生まれる段階にいるだけです。意図して魔法を減らす。それが今やるべき仕事です。
