7月22日、Delba de Oliveira（Claude Codeチームメンバー）が「Building verification loops in Claude Code with skills」と題した記事を公開した。Claude Codeで手動チェックをスキル化し、AIに自律的な検証ループを回させる方法について詳しく紹介されている。
「毎回やっている手動チェック」をClaudeに任せる
AIコーディングの現場でよくある光景がある。Claudeに実装を依頼し、コードが生成されたら人間がブラウザで動作確認し、ログを眺め、「あ、またここが抜けてる」と修正を指示する——このループを毎回手作業でこなしている。
AIコーディングツールの普及に伴い、「生成は速くなったが検証は依然として人間が担っている」という非対称性が課題として浮上しつつある。この記事が提案するのはその非対称性を解消するアプローチだ。Claude Codeの「スキル」（skills）として検証手順を定義することで、毎回の手動確認を自動化し、Claudeが自律的に検証ループを回す仕組みを構築できる。
まず使える組み込みの検証ループ
カスタムスキルを書く前に、Claude Codeに組み込まれている検証機能を把握しておきたい。これらは設定コストがほぼゼロで即座に使い始められる点が強みだ。
/verifyスキル: ビルド・実行・変更の観察を一括で行う。検証ループの出発点として最も手軽な選択肢- ツールチェーン連携: リンターなどのツールからのエラーコードや警告をClaudeが検知して対処する。
CLAUDE.mdにビルドコマンドとテストコマンドを明示しておくと精度が上がる - Spec validation: リポジトリ内のMarkdownスペックに対して変更を照合するスキル。仕様書と実装の乖離を継続的に検出できる
- Rubrics in Claude Managed Agents（beta）: 別のグレーダーエージェントがルーブリックに基づいて成果物を検証し、失敗時は自動で差し戻す。人間のレビュアーが暗黙的に持っていた判断基準を明文化して自動化するアプローチだ
- Code Review（research preview）: PRに対して自動レビューを走らせるマネージドのマルチエージェントサービス。現時点ではresearch preview段階であり、一般提供前の試験的な機能として位置づけられている。利用可否や対象ユーザーは公式ページで確認されたい
- GitHub Actions連携: ローカルで動かす検証スキルをPush・PR時にも同じ条件で実行できる。GitHub Actions公式ドキュメントと組み合わせることで、ローカルとCI環境の検証条件を統一できる
カスタム検証ループの作り方
既存のプロジェクトでClaudeに新機能を追加させるたびに同じ修正を繰り返しているなら、それはスキル化のサインだ。
最速の方法は/skill-creatorプラグインをインストールし、Claudeにインタビューさせること。
/skill-creator Create a skill for verifying frontend changes end-to-end. Interview me about my workflow.
手書きするなら、.claude/skills/以下にMarkdownファイルを置くだけでよい。最小構成の例：
# .claude/skills/verify-log-hygiene/SKILL.md
---
name: verify-log-hygiene
description: Check that error logs include the request ID and never
include the request body. Use when the diff touches error handling
or logging.
allowed-tools: [Read, Edit, Grep]
---
Read the error-handling paths in the current diff.
For each log call on an error path, confirm it includes the request ID
and does not pass the request body, headers, or any user-supplied payload.
Report each violation with file:line, then fix it: add the request ID
where it's missing and strip the payload from the log call.
記事では一点、重要な視点が示されている。「チェックは定性的でなくてもよい」という点だ。たとえば「カラムを削除するマイグレーションにバックフィルステップがなければ却下」は汎用リンターには検出できないが、プロジェクト固有のスキルとして書ける。毎回手で直している規則があれば、何であれスキル化の対象になる。
スキルの組み合わせ方：Standalone / Embedded / Chained
スキルをどこで発火させるかは3つのパターンで整理できる。
Standalone（単独呼び出し）：都度手動で呼ぶ。セキュリティスキャンやライセンスヘッダーの確認など、毎回ではなく任意のタイミングで走らせたい処理に向く。毎回の変更後に実行していることに気づいたら、次のパターンへ移行すべき段階だ。
Embedded（組み込み）：既存の「生産スキル」の末尾に検証ステップを追記する。たとえばReactコンポーネントをスキャフォールドするスキルの末尾にAfter creating the component file, run eslint on it and address any errors before reporting completion.と一行加えるだけで、コンポーネント生成のたびに自動でESLintが走る。追加の呼び出し手順が不要で、既存ワークフローへの摩擦が最小限に抑えられる点が利点だ。
Chained（連鎖）：複数スキルを順次呼び出す。Anthropic社内のClaude Codeチームが実際に使っているパターンで、/code-reviewでバグ探索→/simplifyでdiffを整理→/verifyでエンドツーエンドの動作確認→UIが変わっていれば/designでガイドライン照合、という流れを組んでいる。各ステップが前のステップの成果物を前提として動くため、単純な並列実行よりも精度の高い検証が実現できる。
自分で修正できないスキルに検証を追加したい場合もチェーンで解決できる：
# .claude/skills/safe-refactor/SKILL.md
Run /simplify on the current diff first.
When /simplify finishes, invoke /verify-no-public-api-changes.
ただしチェーンはトークン消費が増えるため、広く展開する前にテストしておくことが推奨されている。
PR全体へ展開する最終ステップでは、このチェーンをGitHub Actionsなどで全PRに適用する。「自分が手間を省くための個人インフラ」が「チーム全員の変更を守るチームインフラ」になる段階だ。記事では、チェーン自体がまだ変動中の段階でPR全体に展開するのは避けるよう釘を刺している。調整のたびにチーム全体に影響が出るためだ。
実践の手順まとめ
記事が提示するステップは以下のとおりだ。この順序には理由がある。まず既存の組み込み機能で「スキル化の感触」を掴み、習熟したうえで自作スキル→チェーンへと段階的に複雑度を上げることで、いきなり複雑な仕組みを導入して破綻するリスクを避けられる。
- 今週最もよく行った手動フォローアップを1つ選ぶ——対象を絞ることで「とりあえず全部自動化しよう」という過剰設計を防ぐ
- まず組み込みの
/verifyスキルで試す——追加設定なしで始められ、スキルの挙動を体感できる - 新メンバーに渡すつもりで手順を平易な英語（または日本語）で書き下す——曖昧なままスキル化しても精度が出ないため、言語化が品質の鍵になる
skill-creatorに渡すか、.claude/skills/にMarkdownを置く——インタビュー形式で進めれば手順の抜け漏れが減る- 新しいタスクで呼び出し、チェックが出力に含まれることを確認・反復——期待通り動かなければスキルの記述を修正するサイクルをここで回す
- スキルチェーンでエンドツーエンドの検証フローに拡張する——個人の効率化からチームインフラへのステップアップ
詳細はBuilding verification loops in Claude Code with skillsを参照していただきたい。
