検証ループの閉鎖（14 分読了）
AI エージェントの普及により開発コストが低下した現在、機能の実装完了と実際の動作検証の間に生じる乖離を埋めるための「検証ループ」の重要性と具体的な構築手法について論じている。
キーポイント
開発パラダイムの転換点
AI エージェントによりコード作成が安価になった結果、重要なのは「作れるか」ではなく「実際に機能しているか」の証明へとシフトしている。
検証ループの定義と構造
検証ループとは、変更（change）を適用し、ユーザー視点で実行・観察し、不具合を修正し、テストで証明して再検証する一連のプロセスである。
ブラウザと人間による検証の必要性
単なるコンパイルやレビュー通過では不十分であり、実際のブラウザ環境での動作確認と、人間の視覚・文脈理解（ペルソナ）によるチェックが不可欠である。
証拠を伴う修正の重要性
バグ修正は単なるコード変更ではなく、その修正が有効であることを示すテストや証拠（evidence）を伴って初めて完了とみなされるべきである。
影響分析・編集コメントを表示
影響分析
この記事は、生成 AI がソフトウェア開発の生産性を劇的に向上させた現代において、品質保証の質的転換を迫っていることを示唆しています。開発スピードが速まるほど、検証プロセスの自動化と人間による最終確認の重要性が増大し、従来の CI/CD パイプラインに「ユーザー視点での実証」という新たなレイヤーを追加する必要性が生じます。これは AI エージェントが自律的に動作する未来において、信頼性を担保するための不可欠なインフラストラクチャの再定義を意味します。
編集コメント
生成 AI の台頭により「作ること」のハードルが下がった今、エンジニアリング組織は「正しく動くことを証明すること」にリソースを集中させるべきという、非常に示唆に富む提言です。
*ブランチが準備完了を証明する方法：ブラウザの現実、ペルソナの視点、そして証拠自体を伴う修正。
1. 閉じるべきループ
エージェントによってビルドのコストは劇的に低下しました。コストの所在が変わり、「これをリリースできるか」という高価な問いではなく、「実際に誰かがそれが機能していることを知っているか」が問われるようになりました。コンパイルに成功し、レビューを通過し、マージされたブランチであっても、最初のリアルユーザーを迎える際に、誤ったフィールドを検証するフォームや、誤ったスレッドへのリンクを含むメールを送信してしまう可能性があります。
検証ループとは、主張とその証明の間の距離です：
変更→主張：機能している
実行：ユーザーとして試す
観察：何が起きるか見る
修正：壊れている箇所を直す
証明：テストで裏付ける
再検証：準備完了
ループ：再検証に失敗した場合は、再度実行へ戻る
ほとんどのチームは人間によってこのループを閉じています。デモ前に誰かがクリックして確認し、ステージング環境を誰かが目でチェックします。これはエージェントが人間を上回るまで機能しますが、それはまさにエージェントが存在する理由です。複合工学（CE：Claude Code などのコーディングエージェント向けのスキルプラグイン）は、ループ自体がエージェントが行うべき作業であり、判断が必要な箇所やツールの手が届かない箇所においてのみ人間を巻き込むことで、エンドツーエンドで完結できると答えます。これを体現するスキルが /ce-dogfood です。この文章の残りの部分では、これがどのようにループを閉じるのか、そしてその目にペルソナ戦略がどう機能するのかを解説します。
2. Dogfood in one pass
/ce-dogfood は、アクティブブランチをドッグフード（社内テスト）する QA エンジニアとして機能します。すべての変更を理解し、ユーザーがブラウザで利用するかのようにリアルな環境で各変更を検証し、ブランチが準備ができるまで自律的に不具合を修正します。これを定義する 2 つの制約があります。
- 差分スコープ限定、アプリ全体ではない。これはこのブランチがトランク（本流）に対して何を変更したかをテストし、トランク自体では実行しません：差分が存在しなければ、ドッグフードする対象もありません。
- リアルなブラウザ、単一のツール。すべての自動化はエージェント・ブラウザ CLI を通じて行われます。これはブラウザを直接操作するシェルツールです（ラッパーでも MCP サーバーでもない Rust バイナリ）：例外はありません。
ワークフローは 7 つのフェーズからなり、その中央にループが含まれています：
0 スコープ設定 1 分析 2 フローとマトリックス作成 3 サービス提供 4 実行 5 修正ループ 6 レポート（すべての修正はシナリオを再実行します）
この哲学を体現するいくつかのフェーズの詳細：
- スコープはテスト対象の ref のアイデンティティを固定し、diff を正しいベースに対して切り出す（PR は PR として残り続ける；フォークのヘッドが文字通り main と名付けられることもあり得る）ため、ce-worktree を介して他人の ref をテストする際にワークツリー分離を提供し、チェックアウトが決して乱されないようにします。
- Serve は設計上手放し型です：ポートを検出（明示的なフラグ、次にプロジェクトの指示、次に package.json、次に .env、最後に 3000）し、実行中のサーバーを再利用するか新規起動し、接続を受け付けるまでポーリングします。開発サーバーを開始する際に許可を求めるために停止することはありません。
- すべての処理は再開可能です。マトリックス（シナリオチェックリストフェーズ 2 が生成するもの）は二重に存在します：セッション内のライブタスリストとして、および docs/dogfood-reports/<date>-<branch>-dogfood.md に保存されたディスク上のレポートドキュメントとして。これはマトリックスが作成された瞬間に作成され、シナリオごとおよび修正ごとに更新されます。実行中にセッションを停止しても、レポートは後続の実行（またはチームメイト）が再開するためのチェックポイントとなります。
ce-dogfood も意図的にソロ奏者ではなくオーケストレーターです：奇妙な障害の根本原因究明は ce-debug に委譲され、コミットは ce-commit を経由し、再利用可能な教訓は ce-compound へ送られます。
3. マトリックス前のフロー：メールルール
自動化された QA があなたを欺く最も一般的な方法は、ジャーニーではなくページをテストすることです。すべてのページがレンダリングされますが、機能はまだ壊れています。なぜなら、障害はページ間の隙間に存在するからです。
したがって、dogfood（社内製品テスト）ではチェックリストへのジャンプは禁止されています。フェーズ 2 ではまず、すべてのユーザーが視認できる変更を明示的なフローとしてマッピングします：エントリーポイント、各アクション、すべての分岐（バリデーションエラー、空の状態、権限拒否）、すべての副作用、そして真の終了状態です。その後、各フローをトレースし、すべてのノードと分岐をシナリオに変換することで、マトリックスが導き出されます。
ユーザーが/threadを開く→Replyをクリック→フォーム有効？→インラインバリデーションエラー→返信保存→UI が新しい返信にスクロール→参加者にメール送信→受信者がメールリンクをクリック→RIGHT スレッド、RIGHT 返信にスクロール？いいえ/はい<g transform=
原文を表示
*How a branch proves itself ready: browser reality, persona eyes, and fixes that carry their own evidence.*
1. The loop that must close
Agents made building cheap. The cost moved: the expensive question is no longer "can we ship this?" but "does anyone actually know it works?" A branch that compiles, passes review, and merges can still greet its first real user with a form that validates the wrong field and an email that links to the wrong thread.
The verification loop is the distance between a claim and its proof:
Most teams close this loop with humans: someone clicks around before the demo, someone eyeballs staging. That works until agents outrun the humans, which is what the agents were for. Compound engineering (CE, a plugin of skills for coding agents like Claude Code) answers that the loop itself is work an agent can do, end to end, with people pulled in where judgment belongs to them, and where the tooling genuinely cannot reach. The skill that embodies this is /ce-dogfood, and the rest of this piece walks through how it closes the loop, and the persona strategy that gives it eyes.
2. Dogfood in one pass
/ce-dogfood acts as a QA engineer who dogfoods the active branch: understand every change, test every change in a real browser as a user would, and fix what breaks, autonomously, until the branch is ready. Two constraints define it:
- Diff-scoped, never whole-app. It tests what this branch changed versus the trunk, and it refuses to run on the trunk itself: no diff, nothing to dogfood.
- A real browser, one tool. All automation goes through the agent-browser CLI, a shell tool that drives the browser directly (a Rust binary, not a wrapper, not an MCP server): no exceptions.
The workflow is seven phases with a loop in the middle:
A few phase details that carry the philosophy:
- Scope pins the identity of the ref under test, so the diff is cut against the right base (a PR stays a PR; a fork's head can literally be named main), and offers worktree isolation via ce-worktree when testing someone else's ref, so your checkout is never disturbed.
- Serve is hands-off by design: detect the port (explicit flag, then project instructions, then package.json, then .env, then 3000), reuse a running server or start one, poll until it accepts connections. It does not stop to ask permission to start a dev server.
- Everything is resumable. The matrix (the scenario checklist phase 2 produces) lives twice: as a live task list in the session, and as a report document on disk at docs/dogfood-reports/<date>-<branch>-dogfood.md, created the moment the matrix exists and updated after every scenario and every fix. Kill the session mid-run and the report is the checkpoint a later run (or a teammate) resumes from.
ce-dogfood is also deliberately an orchestrator, not a soloist: root-causing a weird failure delegates to ce-debug, commits go through ce-commit, reusable lessons go to ce-compound.
3. Flows before matrix: the email rule
The most common way automated QA lies to you is by testing pages instead of journeys. Every page renders; the feature is still broken, because the breakage lives between the pages.
So dogfood forbids jumping to a checklist. Phase 2 first maps every user-visible change as an explicit flow: entry point, each action, every branch (validation error, empty state, permission denied), every side effect, and the true end state. Only then does the matrix get derived, by walking each flow and turning every node and branch into scenarios.
user opens /threadsclicks Replyform valid?inline validation errorreply savedUI scrolls to new replyemail sent to participantsrecipient clicks email linkRIGHT thread, scrolledto the RIGHT reply?noyes<g transform=
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み