私が眠っている間に稼働するエージェント

Japanese Translation:

記事では、AI エージェントがテスト駆動開発（TDD）を通じてコードを書きつつ、同じエージェントが生成・実行するのではなく「外部」検証に依存する新しいワークフローを提案しています。著者は Gastown などの自律型エージェントを構築しましたが、その内部テスト生成は信頼性が低く、シンタックス的には正しくても論理エラーを含むコードを出力してしまうことがあります。

Claude Code ワークショップで100人以上のエンジニアと共に実施した結果、プルリクエストのマージ率は週40〜50件（約10件）から大幅に上昇しましたが、AI が生成した変更点をレビューする時間も増えました。同じ AI が自分の出力をテストすると「自己賞賛機械」になり、安全性に欠けるためです。

提案された解決策では、開発者はエージェントへプロンプトを与える前に、英語で受け入れ基準（Acceptance Criteria）を書きます。これによりエッジケースを考慮し、仕様が明確になるよう強制されます。その後、エージェントはそれらの基準を満たす機能を構築します。検証は次のように行われます。

フロントエンド：Playwright ブラウザエージェントが各基準を実行し、スクリーンショットを取得して判定レポートを生成します。
バックエンド：
```
curl
```
コマンドで API 応答を期待されるステータスコードや JSON 構造と照合します。

完全な差分（diff）をレビューする代わりに、失敗した受け入れ基準のみを検査することでレビュープロセスが大幅に短縮されます。Claude Skill（

github.com/opslane/verify

）はこのプロセスを4段階でオーケストレーションします ― 事前チェック、Opus プランナー、Sonnet ブラウザエージェント、および最終 Opus ジャッジ ― を通じて判定を出力します。

ツールは既存の Claude OAuth のみで追加 API キーは不要であり、CI に

claude -p

コマンドを一つ実行するだけで統合できます。ワークフローは開発速度とマージ率を向上させますが、テストでは検出できない仕様ミスを人間の監視で捕捉する必要があります。

私は眠っている間にコードを書いてくれるエージェントを構築しています。Gastown のようなツールは、私が監視しなくても数時間動き続けます。変更は、まだ読んだことのないブランチへと落ち込みます。数週間前、私はそれらが本当に正しいかどうか――つまり「私が言った通りに動く」かどうかを確実に知る方法が無いことに気づきました。

この点は非常に重要です。不要なコードをプッシュしたくなくて、結局のところ明確な答えも得られませんでした。
過去 6 か月で Claude Code を使ったワークショップを 100 人以上のエンジニア向けに開催してきましたが、この問題は規模が違うだけで全世界どこでも存在します。Claude を日常的な PR に利用するチームでは、週に 10 件ではなく 40〜50 件をマージしています。その結果、コードレビューに費やす時間は格段に増えます。システムがより自律化すると問題はさらに深刻になります――ある時点で差分レビューをまったく行わず、デプロイの監視だけで「何も壊れない」ことを期待するようになるからです。

したがって私は度々問うようになりました：すべてをレビューできないとき、実際に何を信頼するのでしょうか？

明白な回答は機能しない

もっとレビュアーを雇えばいい。
しかし、人員確保が追いつかず、シニアエンジニアが AI が生成したコードを一日中読むこと自体の価値もありません。
Claude が書いたコードに対してテストを書き、実行させると。
それは Claude 自身の作業を検証しているだけです。テストは「Claude が思った通り」に動くかどうかを示すので、元々の誤解や意図しない振舞いは捉えられません。
同じ AI を使って書いてチェックすると。
それは自己満足型のマシンに過ぎず、本来コードレビューが目指していた「別人の目」を提供できません。同一 AI が作成と検証を行えば、同じ欠点を見逃す可能性が高いです。

TDD（テスト駆動開発）が正しく実装したこと

まずテストを書く。
次にコードを書き、テストが通るまで停止する。

多くのチームは「コードを作る前に何をすべきかを考える時間がない」ためこれを行いません。しかし AI がその余裕を取り除いてくれます。速さは Claude に任せ、残りは「コードが正しいか」を判断することです。これこそ TDD の真髄です。

TDD はユニットテストを書き、コードを書く前に動作を想定させます。AI ならば以下のように簡単です：

機能要件を英語で書き出す。
マシンがそれを検証する方法を決める。

「ユーザーはメールアドレスとパスワードで認証できる。誤った資格情報では『Invalid email or password』というメッセージが表示され、成功したら
/dashboard
に遷移し、セッショントークンは 24 時間後に期限切れになる。」
この要件をコードエディタを開く前に書けば、エージェントが自動で実装します。別のプロセスがそれを検証します。

私は毎週 Claude Code の内部構造について執筆しています。先週は「Claude Code は 23 のツールを備えた while-loop である」と紹介しました。次回もぜひご覧ください！

実際にどう動くのか

フロントエンド変更例

仕様ファイルから自動生成した受け入れ基準（Acceptance Criteria）：

# Task
Add email/password login.

## Acceptance Criteria
### AC-1: Successful login
- User at /login with valid credentials gets redirected to /dashboard
- Session cookie is set

### AC-2: Wrong password error
- User sees exactly "Invalid email or password"
- User stays on /login

### AC-3: Empty field validation
- Submit disabled when either field is empty, or inline error on empty submit

### AC-4: Rate limiting
- After 5 failed attempts, login blocked for 60 seconds
- User sees a message with the wait time

各基準は 「合格か不合格」 の判定が可能です。エージェントが機能を構築すると、Playwright を使ったブラウザエージェントがそれぞれの AC に対してテストを実行し、スクリーンショットを撮ってレポートを生成します。不具合がある場合は、どの基準が失敗したかとブラウザで何が起きたかを正確に把握できます。

バックエンド変更例

同じパターンをブラウザ不要で実行可能です。

curl

などで確認できる API の振舞い（ステータスコード、レスポンスヘッダー、エラーメッセージ）を指定するだけです。

注意点：仕様自体が誤っている場合は検証に通ります。Playwright が捕捉できるのは「統合テスト失敗」「レンダリングバグ」「理論上は動くはずなのに実際にブラウザで壊れるケース」です。「正しい」ことを保証するものではありませんが、従来のコードレビューよりも確実に欠陥を発見できます。

ワークフロー

プロンプト前に受け入れ基準を書き出す
エージェントはそれに沿って構築します。
検証を走らせる
差分ではなく、失敗した箇所だけをレビューします。

具体的な実装方法

私は Claude Skill（

github.com/opslane/verify

）を作り、

claude -p

（Claude Code のヘッドレスモード）と Playwright MCP を組み合わせて動かしています。追加のバックエンドや API キーは不要で、既存の Claude OAuth トークンだけで済みます。

四段階構成

ステージ	内容
Pre‑flight	純粋な Bash で LLM を使わずにサーバ起動確認、認証セッション、有効な spec ファイルの存在をチェック。トークン消費前に早期失敗。
Planner	Opus コール 1 回。spec と変更ファイルを読み込み、各テストが何を検証すべきか、どのように実行するかを決定し、コードから正しいセレクタを抽出します。
Browser agents	AC ごとに Sonnet コール 1 回（並列実行）。AC が 5 つなら 5 台のエージェントが独立してブラウザ操作とスクリーンショットを取得。Sonnet は Opus よりコストが 3〜4 倍低く、クリックや入力に十分です。
Judge	最後の Opus コールで全証拠を読み取り、各基準ごとに「合格」「不合格」「人間レビュー必要」の判定を JSON 形式で返します。

実行例

claude -p --model claude-opus-4-6 \
  "Review this evidence and return a verdict for each AC.
   Evidence: $(cat .verify/evidence/*/result.json)
   Return JSON: {verdicts: [{id, passed, reasoning}]}"

Claude Code プラグインとして導入

/plugin marketplace add opslane/verify/plugin install opslane-verify@opslane/verify

またはリポジトリをクローンして自分用にカスタマイズ。各ステージは入力と構造化された出力が明確な

claude -p

コールですので、モデルの切替や追加ステージ、CI への組み込み（

--dangerously-skip-permissions

）も容易です。

キーとなる洞察

エージェントに何を「完成」と認めさせるかは、作業開始前に明示しておく必要があります。
受け入れ基準を書き出すことはプロンプトを書くより難しいと感じられるかもしれませんが、実際にはエッジケースまで考えさせるための重要なステップです。TDD と同様に最初は遅く見えるかもしれませんが、欠陥を事前に排除し、最終的にはレビュー時間を大幅に短縮します。

まとめ
AI がコードを書いてくれる現代においても、人間が「何を期待するのか」を明確に定義しておくことは不可欠です。受け入れ基準（AC）を書くことで、エージェントが自動で実装・検証し、失敗箇所だけを人間が確認できる環境を構築できます。これにより、コードレビューの「第二の目」機能を AI でも再現しつつ、正確性と品質を担保することが可能になります。