Vibe Coding覚書

1年後の2026年2月、同じ Karpathy 氏は、仕事で使う形に別の名前を付けています。「エージェンティック・エンジニアリング」── コードを自分で書くのは1%で、残りはエージェントに書かせて監督する。「エンジニアリング」と呼ぶのは、そこに技術と専門性があるからだ、という説明です。実務で「Vibe Coding」と言うときは、こちらの意味で使われることも多くなりました。この記事も、その意味で書きます。

監督が要る理由は、データにも出ています。

AI は「動くコード」をとても上手に書くようになりました。けれど「正しい仕様どおりか」「安全か」「前に決めたことと矛盾しないか」は、放っておくと保証されません。規模が大きくなるほど、この差が効いてきます。

ポイントは、読み込まれるタイミングが違うことです。全部を AGENTS.md に詰めると、毎回すべてを読ませることになり、前回の研究のとおり、かえって成績が落ちます。

道具も出そろってきました。代表的な二つを並べます。

名前は違っても、中身はほぼ同じです。仕様・計画・タスクの三つの文書を機能ごとのフォルダに置き、段階ごとに人が確かめる。とくに大事なのは次の二つです。

• AI に質問させる段階を入れる ── Spec Kit の clarify のように、書きかけの仕様を AI に読ませて「決まっていないこと」を洗い出させます。仕様の穴は、コードになってから見つかるほど高くつきます
• 仕様は機能ごとに分ける ── Kiro の公式も、1つの巨大な仕様ではなく「認証」「商品一覧」「カート」のように機能ごとに分けるよう勧めています。1つが小さいほど、AI も人も読み切れます

道具を入れなくても、同じ形のフォルダと Markdown を手で作れば、どのエージェントでも同じ進め方ができます。次の章の配置は、道具に依存しない形にしてあります。

例として、社内向けの受発注管理システムを考えます。画面は30枚ほど、フロントとAPIとDBがあり、購買・営業・経理が使う、というくらいの規模です。リポジトリはこう分けます。

置き方の原則は五つです。

• 毎回読むものは薄く、必要なときに読むものは厚く ── AGENTS.md は入口と約束だけ。詳しいことは docs/ と specs/ に置き、AGENTS.md から場所を示します
• 仕様は機能ごとに番号つきのフォルダ ── 012、013 と番号を振ると、順番と履歴が分かり、ブランチ名や PR とも対応させやすい
• 決めたことは ADR に、理由と一緒に ── 「なぜ PostgreSQL か」「なぜ承認を状態遷移で持つか」。AI が勝手に設計を変えそうになったとき、根拠として効きます
• 分野別のルールは、パスで限定する ── API の規則は API を触るときだけ読ませる。毎回読ませない
• 同じことを二か所に書かない ── ルールから docs を参照する。写すと、片方だけが古くなります

入口になる AGENTS.md は、たとえばこうです。前回の例と違うのは、「仕様がないものは作らない」という進め方そのものを約束にしている点です。

道具ごとの置き場所の違いは、次のとおりです。

受発注システムに「発注の承認フロー」を足す場面で、仕様から検証までを通してみます。進め方は6段階で、そのうち3か所で人が承認します。

STEP 1 仕様を書く（spec.md）

目的と受け入れ条件は、人が書きます。業務の事情を知っているのは人だけだからです。書けたら AI に読ませて、「決まっていないことを質問して」と頼みます。

受け入れ条件は、そのままテストにできる書き方にします。「使いやすく」ではなく「50万円以上なら承認待ちになる」。条件と結果が一文ずつ対応していれば、STEP 5 で AI にも人にも判定できます。

STEP 2 計画を立てる（plan.md と ADR）

計画は AI に書かせ、人が判断します。見るべきは「既存の構成を壊していないか」「決めてあることと矛盾しないか」。状態の持ち方のような後から変えにくい判断は ADR に残します。

STEP 3 タスクに分ける（tasks.md）

1タスクは1回のやりとりで終わり、終わったと確かめられる大きさにします。テストを書くタスクを実装より前に置くのがコツです。

STEP 4〜6 実装・検証・仕様を閉じる

• 実装 ── tasks.md を上から1つずつ。1タスク1コミットにしておくと、おかしくなったときに戻る場所がはっきりします。広く調べる作業（影響範囲の洗い出しなど）はサブエージェントに任せ、本筋の会話を散らかさない
• 検証 ── 「テスト・型・E2E が通る」を完了の条件にし、CI で必ず回します。人のレビューは差分より先に、受け入れ条件と照らして。権限チェックの漏れや XSS のような安全性は、明示的に見る（第一章の数字のとおり、放っておくと半分近くが素通りします）
• 仕様を閉じる ── 実装中に決まったこと（代理承認は不要、など）を spec.md に戻して、仕様とコードを一致させて終えます。ずれた仕様は、次の機能で AI を間違った方向に導きます

ルールは「お願い」です。必ず守らせたいことは、フックや CI に移します。Claude Code の公式ドキュメントも「『.env を編集しない』と書くのはお願いで、保証ではない。毎回守られるべきならフックにせよ」と書いています。たとえば、ファイルを書き換えるたびに lint を走らせるフックはこうです。

この表は Claude Code 公式の「少しずつ育てる」ための目安をもとにしています。最初から全部そろえる必要はありません。

逆に、避けたいことも三つ挙げておきます。

• 巨大な仕様書を一度に書かせる ── 読み切れない仕様は、誰も確かめていない仕様です
• AI が書いた文書を読まずにコミットする ── 前回の研究のとおり、自動生成のまま置いた指示はかえって成績を下げます
• 画面で動いたから完成とする ── 「動く」と「正しい」「安全」は別物です

道具や名前は、これからも変わっていきます。ここで挙げたのは、Spec Kit や Kiro、Claude Code や Cursor の公式ドキュメントに共通している考え方を、道具に依存しない形にまとめたものです。