3ヶ月の壁

Vibe codingでSaaSを作る。最初は速い。「ログインを作って」――30秒。「決済を追加して」――2分。MVPが3週間で出荷される。

3ヶ月後、奇妙なことが起こる。AIが決済ロジックを「整理」し、割引計算をこっそり変更する。新しいエンドポイントを追加すると、既存の認証が壊れる。リファクタリングの依頼で公開APIのフィールド名が変わり、すべてのクライアントが死ぬ。

これがlogic driftと呼ばれるもの――AIが意図せず既存のビジネスロジックを変更してしまう現象だ。リグレッションバグは従来の開発にも存在する。だがlogic driftは違う。開発者が意図していない変更が、コードベース全体で見えない形で発生する。プロンプトのたびにコンテキストウィンドウはリセットされる。

数字で見るdrift

感想ではない。データがある。

速度の代償は複雑性。 カーネギーメロン大学の研究チームが、Cursor導入前後の807のGitHubリポジトリを比較した（MSR 2026）。コード追加量は最初の1ヶ月で3〜5倍に増加。2ヶ月後、速度の優位性は消滅。残ったもの：静的解析の警告が30%増加、コードの複雑性が41%増加――恒久的に。

速くなったのではなく、遅くなった。 非営利AI研究機関METRが、16人の経験豊富なオープンソース開発者を対象にランダム化比較試験を実施した（2025年）。よく知っているプロジェクトでは、AIツールを使ったグループはタスク完了に19%長くかかった。しかし開発者自身は20%速くなったと感じていた。知覚と現実の間に39パーセントポイントのギャップ。新規プロジェクトでは結果が異なる可能性があるが、「AI＝常に速い」という前提は崩れた。

スケールすると安定性が崩壊する。 Google DORA Report（2025）によると、AI導入が25%増加するごとに、ソフトウェアデリバリーの安定性が7.2%低下する相関がある。

実際に崩壊した。 Amazonは2025年に全社的なAIコーディングツールの使用を義務化し、21,000のAIエージェントを展開した。同時期に約30,000人の従業員が解雇され、レビュー能力が急激に低下した。AIによる高速コード生成とレビュー人員の削減が組み合わさった結果、90日間で4件のSev-1インシデントが発生した。2026年3月5日の6時間の障害では、推定630万件の注文が失われた。内部文書にはこう記されていた：「GenAIの高速コード生成が意図せず脆弱性を露出させており、現在のセーフガードはまったく不十分である。」

「TDDをやれ」は答えではない

Vibe codingのdriftに対する一般的なアドバイスは「テストを書け」だ。方向は正しい。だが、テストをどう提供するかで結果が決まる。

TDAD研究（arxiv 2026）がこれを正確に検証した。Qwen3-Coder 30BにSWE-bench Verifiedから100インスタンスが与えられた。

条件リグレッション率
ベースライン（テスト指示なし）6.08%
手続き的な「TDDをやれ」指示9.94%（悪化）
影響を受けるテストファイルをコンテキストに提供1.82%（70%削減）

エージェントに「TDDをやれ」と指示すると、結果は悪化する。エージェントは手続き的な指示に従おうとして本来のタスクから逸脱する。だが「これらのテストファイルがパスしなければならない」という具体的なコンテキストを提供すると、リグレッションは70%減少する。

違いは明確だ。「どうテストするか」の指示ではなく、「何がパスしなければならないか」のコントラクト。

Hurl：plain textのコントラクト

HurlはHTTPリクエストと期待されるレスポンスをplain textで宣言するテストツールだ。Orange（France Télécom）がメンテナンスし、ランタイム依存なしのRustバイナリ、GitHubスター18.7k。CIで毎コミット実行できるほど高速。

# Login succeeds
POST http://localhost:8080/api/auth/login
{
  "email": "test@example.com",
  "password": "secret123"
}
HTTP 200
[Asserts]
jsonpath "$.token" exists
jsonpath "$.user.email" == "test@example.com"

# Unauthenticated access returns 401
GET http://localhost:8080/api/pages
HTTP 401

2つのコントラクト。ログインは200とトークンを返さなければならない。未認証アクセスは401を返さなければならない。

このファイルがgitにコミットされ、CIで毎コミット実行されていれば――AIが認証ロジックを「整理」して401が200になった瞬間、コミットはリジェクトされる。Driftはプロダクションに到達する前に捕捉される。

なぜHurlなのか

ユニットテストもdriftを検出できる――AIにテストファイルの変更権限を与えなければ。だがユニットテストは内部関数を検証するため、構造的に実装と結合している。関数名が変われば、テストが壊れる。リファクタリングのたびにテストの更新が必要になる。

HurlはHTTP境界で動作する。リクエストとレスポンスだけを宣言する。コードの内部構造を一切知らない。AIがコードをどう変更しても、外部から観察可能な振る舞いが同じならテストはパスし、異なればフェイルする。自然に実装から独立している。

ユニットテストHurl
検証対象関数内部HTTPコントラクト
AIリファクタリング時一緒に変更変更なし
Drift検出条件付き（ロック時）自然
コード構造への依存高いなし
人間の可読性コードレベルPlain text
LLM生成コード構造の理解が必要HTTPだけで十分

Hurlが検証するのはコードではなく振る舞いだ。コードはAIが自由に変更できる。振る舞いは変わってはならない。この区別がdrift検出の鍵だ。

ラチェットロック

Hurlテストがパスしたら、ロックする。これがラチェットだ。

1. Write Hurl tests for current API (or auto-extract)
2. Run on every commit in CI
3. Passing tests cannot be deleted or modified
4. New features require new Hurl tests
5. All existing + all new tests must pass to merge

エージェントに「このコードをリファクタリングしてくれ」と伝えれば、コードは自由に変更される。だがHurlテストが壊れれば、コミットはリジェクトされる。エージェントはリファクタリング中に既存の振る舞いをすべて保持しなければならない。Hurlがカバーしていないエッジケースでのdriftは依然として起こりうるが、カバーされた振る舞いについてはdriftが構造的に抑制される。

これはTDAD研究の知見と正確に一致する。手続き的な「テストを書け」指示ではなく、具体的な「これらのHurlファイルがパスしなければならない」コントラクト。エージェントは方法を選べるが、コントラクトを破ることはできない。

レガシーにも有効

すでにvibe codingで作ったソフトウェアを本番運用している？やり直す必要はない。

ステップ1：現在の振る舞いをHurlで記録する。

APIドキュメントがあれば、それを直接Hurlに変換する。なければ、エージェントに既存コードを読ませてHurlテストを書かせる。目標は、すべてのエンドポイントについて「現在こう動いている」をplain textで宣言すること。

ステップ2：CIに組み込む。

すべてのHurlテストがパスすることを確認し、マージ条件に追加する。

ステップ3：これで安全だ。

AIがリファクタリングしようが新機能を追加しようが、Hurlが既存の振る舞いを守る。Driftが発生すれば、CIが即座に検出する。

基礎工事ではない――耐震補強だ。店を閉めずにビルを補強する。

Vibe codingの終わりではない――その進化

「Vibe coding」という言葉を生み出したAndrej Karpathyは、ちょうど1年後の2026年2月にこう宣言した：「vibe codingの時代は終わった。」新しいパラダイムはagentic engineering――人間がコードを書くのではなく、自律的に計画・実装・テストするエージェントをオーケストレーションする。

Thoughtworks Technology Radar（2025）はSpec-Driven Developmentを「Assess」レベルに位置づけた。Martin FowlerのチームがSDDツール分析を公開した。業界は同じ方向に収束している。

Hurlテストは、この移行の最小単位だ。10のスペックは必要ない。OpenAPIを学ぶ必要もない。1つのHurlファイルが1つのコントラクト。 そしてそのコントラクトが、エージェントの自由を制約せずにdriftを構造的に防止する。

モデルを変えるな。コントラクトを追加しろ。

関連

References