検証ループとは何か
エージェンティックなコーディングは、だいたい同じ形のループで進む。変更を依頼する、Claude がコンテキストを集める、手を動かす、結果を検証する、足りなければまたコンテキストを集めにいく。この3番目の「検証」が、成果物を返す前に自分の仕事を点検する工程にあたる。
Claude はすでに、この点検の一部を勝手にやっている。型チェッカ、linter、テスト、ランタイムエラー。コードベースが返す決定論的なシグナルは、そのまま検証材料として使われている。問題は、そこから推論できない残りの部分だ。それは結局「自分が毎回手で確かめている手順」として残る。
Anthropic の Claude Code チームが公開したこの記事は、その手動の確認手順を Skill として書き下し、Claude 自身にフィードバックループを閉じさせるための実践ガイドだ。検証ループとは、エージェントがテスト・lint・独自チェックで自分の成果物を検証し、失敗を直してから次に進む反復サイクルを指す。
Skill 化する意味: 検証を Skill としてパッケージすると、人間が「そういえばあれを確認しないと」と思い出さなくても、毎セッションで同じチェックが自動的に適用される。検証が記憶に依存しなくなる、というのがこの記事の核心にあたる。
まず組み込みの検証手段を知る
自作に走る前に、Claude Code 側が用意している検証の仕組みを把握しておくと重複を避けられる。
/verify skill
アプリケーションをビルドし、実行し、変更がどう反映されたかを観測する。まずこれを素で回してみて、自分の手順とどこまで重なるかを見るのが出発点になる。
ツールチェーン連携
linter などが返すエラーコードや警告を Claude が拾って対処する。ここで効くのが、ビルドコマンドとテストコマンドを CLAUDE.md に正確に書いておくこと。推測させる必要がなくなる。
Code Review Research Preview
有効化したリポジトリの PR に対して、自動レビューを走らせるマネージドな多エージェントサービス。指摘を手で直して push してもいいし、GitHub Actions を設定済みなら指摘に対してコメントで応答してループを閉じることもできる。
GitHub Actions
検証 Skill を呼ぶジョブを定義しておけば、ローカルで走らせているのと同じチェックが push や PR のたびに発火する。
Spec validation
リポジトリ内の markdown で書かれた仕様と各変更を突き合わせ、違反があれば修正を試みる Skill。
Rubrics in Claude Managed Agents Beta
別立ての grader エージェントが rubric に対して成果を検証する。失敗したものは自動的に手戻りに回る。検証者と実行者を分離したい場合の公式ルートになる。
手動チェックを Skill に書き下す
既存プロジェクトで、Claude が機能を実装するたびに同じ小さな修正を入れている。そう気づいたときが、自分の検証ループを作るタイミングだ。最初にやることは、毎回やっていることを全部書き出すこと。
新規プロジェクトで「このプロジェクトはどう振る舞うべきか」を決めるときも同じ。新しいチームメイトに初日に渡すつもりで、平易な文章でベストプラクティス版を書く。言語化に詰まったら、まず Claude にベストプラクティスを出させて、それを編集する形でもいい。自分の版が数か所で違ってくるはずで、その差分こそが捕まえたい固有知にあたる。
定性的なチェックだけではない: 「backfill ステップのないカラム削除マイグレーションは却下」のような、汎用の linter では拾えないがプロジェクト固有では決定論的なルールも、ここに含めてよい。手で強制し続けているものは全部、ループ化の候補になる。
Skill 化の最短経路は skill-creator プラグインを入れて、Claude に自分の作業をインタビューさせること。手書きするなら、プロジェクト内の .claude/skills/ に markdown を置くだけでいい。最小構成は frontmatter 数行と本文だけで成立する。
どこで走らせるか — 4つの発火パターン
次に決めるのは、その検証ループをどう起動するか。記事は4つのパターンを、成熟度の階段として並べている。
| パターン | 起動方法 | 向いている検証 |
|---|---|---|
| standalone | 自分で意図的に呼ぶ | 毎回は不要な横断チェック |
| embedded | 生成側 Skill の一部として自動発火 | 特定ワークフロー専用のチェック |
| chained | Skill が終了時に次の Skill を呼ぶ | E2E で通したい一連の検証 |
| on every PR | CI が全 PR に適用 | チーム全体で守らせたい基準 |
standalone
成果物ができてから、自分の判断で呼ぶ。コミット前のセキュリティスキャン、PR 前のアクセシビリティ監査、リポジトリ全体のライセンスヘッダ検証。多くのワークフローから使いたいが、コード変更のたびに走らせたくはないもの。
コストは、呼ぶこと自体を覚えていなければならない点にある。毎回の変更のあとに走らせているなら、standalone を卒業するサインだ。その手順はもう常設の居場所を持つべきで、embed するか chain するかの段階に来ている。
embedded
生成側の Skill の一部として自動発火する。チェックが特定のワークフローに属していて、そのワークフローが頼まれなくても検証を走らせるようになる形。最小構成は、生成側 Skill の本文への1行追記で済む。
追記が効いているかは、新規タスクでその Skill を呼び、追加したステップが出力に現れるかで確認する。現れないなら、Skill の description か前段の指示がそのチェックを引き込めていない。
ただし embedded が使えるのは自分が編集できる Skill だけだ。自作したもの、あるいは SKILL.md が自分の管理下にあるプロジェクトレベルの Skill に限られる。組み込み Skill やプラグイン管理の Skill は更新で上書きされるため、このパターンの対象外になる。
chained
ある Skill が終了時に別の Skill を呼び、検証済みの受け渡しが連続して走る。Anthropic の Claude Code チームが日常的に使っているのがこの形で、/code-review でバグを探し、/simplify で差分を整理し、/verify で E2E の挙動を確認し、UI に触れた変更なら DESIGN.md のガイドラインに照らす自作の /design にかける、という流れになっている。
改変できない Skill に検証を足したい場合も chain が答えになる。元の Skill を呼び、続けて自分の検証 Skill を呼ぶラッパー Skillを作る。
ここで起きているのは、「いつも /simplify のあとに /verify を打つ」という習慣が、「/simplify は終了時に必ず /verify を呼ぶ」という契約に変わるという転換だ。開発サイクル全体が自走し、人間はエスカレーションされたときだけ介入する。
on every PR
自分の変更に対してチェーンが安定して回るようになったら、同じ手順を全 PR に適用できる。チームメイトの変更が、本人がチェーンを呼んだかどうかに関係なく、自分の変更と同じゲートを通る。
ここで検証は個人のインフラからチームのインフラになる。自分の2分を節約するために書き下したチェックが、全員の2分を、変更のたびに節約するようになる。
導入の6ステップ
何を自動化するか、どの環境かによらず、作り方の手順は一定だ。
今週いちばん多かった手動フォローを選ぶ
頻度の高いものから着手する。効果が測りやすい。
組み込みの /verify をまず試す
自作する前に、既存の仕組みで足りるかを確認する。
手順を平文で書く
新しいチームメイトに初日に渡す文書のつもりで書く。
skill-creator に渡すか、自分で置く
インタビュー形式で作らせるか、.claude/skills/ に markdown を置く。
新規タスクで呼んで発火を確認する
チェックが出力の一部として走っているかを見て、必要なら直す。
チェーン化して E2E フローにする
安定したら次の Skill と繋ぎ、最終的には PR ゲートへ。
踏み込む前に押さえておく点
各パターンのトレードオフ
- chain はトークン消費が増える。広く展開する前にテストして、コスト差を把握してから常設化する
- chain は柔軟性を犠牲にしている。片方だけ走らせたい場面があるステップは chain にすべきでない
- embedded は自分が編集できる Skill 限定。組み込み・プラグイン管理の Skill に追記しても、次の更新で消える
- standalone は「呼び忘れ」が構造的な欠陥。重要な検証をここに置いたままにしない
- PR 全体へのゲート適用は、チェーンが固まってから。調整のたびにチーム全員に見える事象になる
- Code Review は research preview、Rubrics は beta。品質保証を全面的に預ける段階ではない
もうひとつ、記事が扱っていない領域がある。何を検証項目にするかの中身だ。発火のさせ方は一般化できるが、検証すべき内容そのものはプロジェクト固有で、自分で持つしかない。記事自身も、修正の手間から解放された注意を「どんな Skill にも書き下せない仕事」に振り向けろ、という締め方をしている。
まとめ
この記事の骨格は、standalone → embedded → chained → on every PR という4段階だ。単なる機能の並列ではなく、属人的な手順が組織の基盤になるまでの成熟度モデルとして読める。どの段階でどれを選ぶか、いつ卒業すべきか、どういうときに使うべきでないかが、全パターンについて書かれている。
ハーネス設計の観点から見ると、この記事は「コードで強制できないもの」の扱い方を埋めてくれる。lint やゲート条件は hooks で決定論的に潰せるが、プロジェクト固有の意味論を持つルールは hook では書きにくく、Skill として自然言語で書くほうが自然に収まる。工場自動化でいえば、インターロックと作業標準書の関係に近い。前者は物理的に不可能にし、後者は判断を伴う手順を明文化して属人性を消す。片方だけでは現場は回らない。
Claude にエンコードできるものが増えるほど、最初の一発が期待に近づく。手で直さなくなった分の注意を、書き下せない仕事に向けられるようになる。