Claude Code チームは 2026-07-22、内部で毎日使っている「検証ループ」の実践手法を公開しました。Claude にコードを書かせてそのまま納品させるのではなく、まず自分で4つのチェックを走らせるというものです。本記事は検証というレイヤーに絞り、4つの組込みセルフチェックSkill、独自の検証Skillの書き方、そして4段階の自動化レベルを取り上げます。agentic loops の一般的なパターン（ループ、フィードバック、ツール呼び出し）をすでに知っている方にとって、これは既存のループの上に重ねる「検証レイヤー」の話です。

公式原文：

• Building Verification Loops in Claude Code with Skills
• Getting Started with Loops

検証ループで何が変わるのか

公式の定義：Claude が自分の仕事を検査し、修正を試みる反復プロセスのこと。

従来の agentic loop の閉ループは「コンテキスト収集 → アクション実行 → 人間によるチェック」で、最後の一段階が人間に固定されていました。検証ループではこれを次のように組み替えます。

コンテキスト収集 → アクション実行 → 自動検証 → 修正 → 再検証

チェックと修正がループの中に押し戻され、AI は「コードが書ける」から「自分の書いたコードを検査できる」へと進化します。

区別すべき2種類のチェック：

• 決定論的なシグナル：型チェッカー、linter、テスト実行、実行時エラー——Claude はもともとこれらを読めるし、ついでに直すこともします。
• プロジェクト固有の判断：UI は正しく変わったか、フローはスムーズか、今回の変更に地雷が埋まっていないか——これまでは人間が見張るしかありませんでした。Anthropic の解決策は、手動チェックの1つ1つを Skill としてカプセル化し、Claude が毎回のタスクで自動実行するようにすることです。

4つの組込みセルフチェック Skill

Claude Code チームが毎日使っている4つの工程：

• /code-review：コードの変更点を専任でレビューし、潜在的なバグを炙り出してレビュー意見を1通返します。疲れを知らないレビュアーのような存在です。
• /simplify：今回の変更の diff を清掃し、回りくどい複雑な実装を削除して構造をシンプルにします。機能は足さず、引き算だけしてメンテナンスコストを下げます。
• /verify：エンドツーエンドの検証を行い、実際に一度走らせて、機能が「完成に見える」のではなく本当に完成していることを確認します。CLAUDE.md にビルド/テストコマンドを明記しておけば、それに従って実行してくれます。
• /design：UI をいじったときだけ登場します。リポジトリ内の DESIGN.md と照合し、ビジュアルの実装がズレていないかを1項目ずつ確認します。

この4工程を通して初めて納品です。この4つの Skill は、Claude Code の汎用の土台（組込み /verify、PR のマルチエージェントレビュー、GitHub Actions による自動トリガー）の上に、もう1工程を重ねるものといえます。

独自の検証 Skill の書き方

ステップ1：手動チェックを平易な言葉に翻訳する

毎回手動でやっているその手順を書き出します。入社1日目の新しい同僚に注意点を伝えるつもりで書けば十分です。

このチェック自体の説明に詰まってしまう場合は、まず Claude に汎用のベストプラクティス案を出してもらい、それを編集しましょう。あなたのバージョンが一般的なやり方と違うあの数点こそ、最も書き留めるべき部分です。

ステップ2：あいまいな判断を硬いルールに書き換える

チェックを「なんとなく正しい気がする」といったあいまいな判断のままにしてはいけません。

💡 ヒント：典型的なプロジェクト固有のレッドライン——「データベースのフィールドを削除しておきながら、対応するデータ移行手順を伴わない変更は、すべて差し戻す」。これは汎用 linter には決して検出できない、あなたのプロジェクト固有の「ローカルルール」です。手動で死守し続けて初めて守れるレッドラインは、すべてループとして書き留める価値があります。

ステップ3：skill-creator に投げるか、直接 Markdown に落とす

2つの方法のどちらかを選びます：

• skill-creator を呼び出し、逆にいくつか質問を受けた上で自動生成させる。
• 自分で .claude/skills/ ディレクトリに Markdown ファイルを1つ放り込む。

最もシンプルな検証 Skill は、数行の説明と1段落の本文だけのものです。

ステップ4：一度呼び出して、本当に追随して実行されるか確認する

新しいタスクで一度呼び出し、このチェックが実際に一緒に実行されていることを確認します。

💡 注意点：どうしても手を入れられない Skill（組込みのもの、プラグインがホストしているもの）に当たったら、外側のラッパー Skill を書き、まず元の Skill を呼んでから自分の検証を呼ぶようにすれば、同じようにチェックを組み込めます。

検証は一括適用ではない：4段階の自動化

緩い順に4段階：

公式はこの中間のレイヤーにおける飛躍を「習慣から契約へ」と呼んでいます。もともとは「/simplify の後に /verify を追い実行するのを毎回忘れない」という個人の習慣でしたが、チェーン化すると「/simplify の実行後に自動で /verify を呼ぶ」という固定の契約になります。

⚠️ 重要：チェーン化した検証は token を確実に燃やします。いきなりすべてのチェックを PR gate にして、コミットごとに必ず止める設定にはしないでください。正しいやり方は、まず安定しているかを見極め、それから一段階ずつ引き上げていくことです。

検証の結果

4段階すべてをフル稼働させるのは終着点であって出発点ではありません。推奨される最小の検証チェーン：

/code-review → /verify → /simplify

このチェーンを Chained 段階で1週間回し、token 消費とバグの足止め率を観察してから、On-every-PR に引き上げるかどうかを決めましょう。

よくある質問

• Skill と Markdown プロンプトは同じものですか？ 違います。Skill は能力モジュールであり、指示、ファイル構成、スクリプト、ツール呼び出し、設定、そして一式のワークフローを内包し、チームのチェック手順、デザイン規約、踏んだ地雷を、呼べばすぐ来るパッケージとして蓄積するものです。
• Claude Code にロックインされますか？ Skill は Claude Code の機能から、ベンダー横断のオープンスタンダードへと移りつつあります。GitHub Copilot、Cursor、OpenAI Codex、Gemini CLI がすでに同じフォーマットを採用しており、チームが蓄積した Skill は持ち運べます。
• モデル間の差が縮まるなか、本当に差を開けるものは何ですか？ エージェント能力 = モデル + ツール + 検証機構 + ワークフロー。モデルの項目は各社ますます接近しており、本当に差を開けるのは残りの3項目で、それはすべてあなたの手の中にあります。
• この仕組みは AI が独力でソフトウェアを書けることを意味しますか？ いいえ。これは AI 支援開発のプロセス最適化であり、エンジニアは依然として不可欠で、人の手を離れたプロダクションレベルの納品はできません。

適用シーン

• Claude Code で中長期タスク（5ターン超の対話）を回しており、基礎的な agentic loop をすでに組んだことがある。
• チームに固定のコードレビューチェックリスト、デザイン規約、移行ルールがあり、それを自動化された工程として蓄積したい。
• 追加の token コストを払ってでも、初回納品の品質を高めたい。