Claude公式ブログに、Building verification loops in Claude Code with skillsという記事が公開されました。テーマは、Claude Codeで作業したあとに人間が毎回やっている確認・修正を、Skillsとして定義し、Claude自身に検証と修正のループを回させることです。
AIコーディングでよくあるのは、「だいたいできたけれど、最後に毎回同じところを直している」状態です。型エラー、lint、テストは自動で拾えても、プロジェクト固有の見た目、ログ方針、移行ルール、アクセシビリティ、公開前チェックは人が目で見て直しがちです。
この記事では、Claude公式記事、Claude Code Skills docs、CLAUDE.md/memory docs、GitHub Actions docs、海外X上の反応を確認しながら、i-Styleの実務目線で「検証ループ」をどう使えばよいかを整理します。
この記事を読むとわかること
- check_circleClaude Codeにおけるverification loopとは何か
- check_circle/verify、toolchain、Code Review、GitHub Actions、Skillsの役割
- check_circle手作業チェックをSkillに落とすときの考え方
- check_circle中小企業や制作現場で最初に検証ループ化しやすい業務
向き：Claude Codeで開発・サイト更新・業務自動化を進めている方、AIに作業を任せたあとの確認が毎回残る方
向かない：Claude Codeのコマンドリファレンスだけを知りたい方。今回は公式記事を実務設計に翻訳する内容です。
検証ループとは、AIが自分の作業を見直して直す流れ
公式記事では、agentic coding sessionを「context gathering → action → verification」というループで説明しています。人が依頼し、Claudeが文脈を集め、変更し、結果を確認し、必要なら追加で文脈を集め直す。この最後の確認がverificationです。
Claudeは型チェック、lint、テスト、runtime errorのような決定的なシグナルはある程度扱えます。ただし、プロジェクト固有の「ここは毎回人が見ている」という確認は、自動では推測できません。そこをSkillとして渡すと、AIが確認と修正を繰り返せるようになります。
| 工程 | Claude Codeで起きること | 人が見ていた部分 |
|---|---|---|
| 文脈収集 | 関連ファイル、仕様、テスト、過去パターンを読む | 「この案件ではこのルールを見る」判断 |
| 実行 | コードやHTML、設定ファイルを変更する | 作業範囲が広がりすぎていないか |
| 検証 | build、test、lint、表示確認などを行う | 目視・経験則・社内ルールでの最終確認 |
| 再修正 | 失敗や違反を見て直す | 毎回同じ指摘を繰り返していた部分 |
公式記事が挙げる組み込みの検証手段
Anthropicは、Claude Codeにはすでにいくつかの検証ループの入口があると説明しています。ポイントは、1つの万能機能ではなく、ローカル確認、PR確認、仕様確認、rubric評価を使い分けることです。
| 手段 | 役割 | 実務での見方 |
|---|---|---|
| /verify skill | アプリをbuild/run/observeして変更を確認 | まず試す標準の確認入口 |
| Toolchain | linter、type checker、testなどのエラー・警告を扱う | CLAUDE.mdに正確なbuild/testコマンドを書くのが重要 |
| Code Review | PRに自動レビューを走らせるresearch preview | 個人の確認からチームのPR確認へ広げる入口 |
| GitHub Actions | push/PRごとにClaudeと検証skillを走らせる | 忘れずに毎回同じ確認を走らせる仕組み |
| Spec validation | Markdown仕様に照らして変更を確認 | 仕様書と実装のズレを減らす |
| Rubrics in Managed Agents | 別のgrader agentでrubric評価し、失敗時に戻すbeta機能 | 主観的な品質基準を評価フローに入れる方向性 |
手作業チェックをSkillにするタイミング
公式記事で実務的なのは、「毎回同じ小さな修正をしているなら、それをcustom verification loopにするタイミング」と書いている点です。つまり、AIが苦手なことを嘆くのではなく、人間が毎回やっている確認を言語化して渡す、という発想です。
例として公式記事では、「backfill stepなしにcolumnをdropするmigrationを拒否する」というルールが挙げられています。これはgenericなlinterでは拾いにくいですが、プロジェクトにとっては明確なルールです。こういうものこそSkill化に向きます。
i-Style流に言うと
「AIが最後にミスる場所」は、会社の業務ルールが隠れている場所です。そこを毎回口で直すのではなく、Skillにしておくと、AI活用が属人的なやり取りから仕組みに変わります。
Skillに落とすなら、まずはこの形でよい
公式記事では、skill-creator pluginにインタビューさせる方法と、`.claude/skills/`に手書きでSkillを置く方法が紹介されています。最小のSkillは、frontmatterと本文だけです。
たとえば、エラーログにrequest IDが含まれ、request bodyやuser payloadを含めない、というログ衛生チェックをSkillにする例が示されています。これは地味ですが、実務ではかなり大事です。
---
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, confirm it includes the request ID
and does not pass the request body or user-supplied payload.
Report each violation with file:line, then fix it.実際に使う場合は、プロジェクトのログ方針、個人情報の扱い、利用できるtoolsを合わせて調整します。
4つの実行パターン：standalone、embedded、chained、PR
公式記事では、検証ループがどこで起動するかを4つに分けています。ここは中小企業の運用にもそのまま使えます。最初からPR全体に入れるより、まずは手動で呼び出すstandaloneから始める方が安全です。
| 型 | 使い方 | 向く場面 |
|---|---|---|
| Standalone | 作業後に意図して呼ぶ | たまに必要なアクセシビリティ確認、ライセンス確認、セキュリティ確認 |
| Embedded | 生成Skillの中に確認手順を組み込む | React component生成後にeslintを必ず走らせるなど |
| Chained | あるSkillの後に別の検証Skillを呼ぶ | /simplify後に/no-public-api-changeを必ず確認するなど |
| On every PR | GitHub Actions等で毎PR走らせる | チーム共通の品質ゲートにしたい確認 |
サイト運用・制作現場では何を検証ループ化できるか
Claude Codeの話は開発者向けに見えますが、Web制作やブログ運用でもかなり使えます。むしろ、毎回同じ確認を人がしている静的サイト運用こそ相性があります。
検証ループ化しやすいもの
- ・H1とmeta titleの完全一致
- ・canonical / sitemap / feed / llms.txt反映
- ・CTAとサポートbot導線の有無
- ・出典リンクと公開日の確認
- ・build/test後のローカル表示確認
人に戻すべきもの
- ・記事の主張がブランドに合うか
- ・公開してよいタイミングか
- ・顧客名や秘密情報が含まれないか
- ・炎上しやすい比較表現がないか
- ・最終的な公開判断
導入手順：今週やるなら、この順番
検証ループは、いきなり大きなCI/CDに組み込むより、小さく始めた方がうまくいきます。公式記事の流れを実務に置き換えると、次の順番です。
- 今週、人が3回以上直した確認を1つ選ぶ。
例：ログ方針、デザインガイド、公開前SEO、テスト漏れ。 - 新入社員に渡すつもりで、plain Englishまたは日本語で手順を書く。
曖昧な表現ではなく、合格条件とNG条件を書く。 - まずstandalone skillとして作る。
自分が明示的に呼び出し、意図通りに動くかを見る。 - 3回試してからembedded/chainedに進む。
毎回使うと確信できたものだけ自動化する。 - チームで安定してからPR全体に広げる。
不安定なループをPRゲートにすると、逆に現場が止まります。
注意点：検証ループは万能ではない
海外Xでは、verification loopsをAI-native developmentの重要パターンとして評価する声が目立ちます。一方で、ループを強くしすぎるとtoken消費が増え、修正が長引き、何を直しているのか人が追いづらくなる可能性もあります。
公式記事も、chained verification loopsはtoken spendを増やす可能性があるため、広く展開する前にテストするべきだと書いています。自動化は便利ですが、止める条件と人に戻す条件がないループは危険です。
最初に決めるべき停止条件
- ・最大試行回数を決める
- ・失敗理由をファイル名・行番号つきで出す
- ・同じエラーが2回続いたら人に戻す
- ・公開・削除・マイグレーションなど不可逆操作は必ず人が承認する
- ・コストが高くなるループはPR全体に入れる前に検証する
まとめ：AIに任せる範囲は「作る」から「確かめる」へ広がる
- ・Claude公式記事は、手作業の確認をSkills化し、Claude Codeに検証と修正のループを回させる考え方を示しています。
- ・/verify、toolchain、Code Review、GitHub Actions、spec validation、rubricsなど、複数の検証入口があります。
- ・毎回人が直している小さな確認こそ、custom verification loopに向いています。
- ・最初はstandaloneで試し、安定してからembedded、chained、PR-wideへ広げるのが安全です。
- ・中小企業や制作現場では、公開前チェック、H1/meta一致、CTA導線、出典確認などから始めると現実的です。
AIに「作って」と頼むだけなら、もう多くの会社が始めています。次の差は、AIに「確かめて、違っていたら直して」まで任せる設計を持てるかどうかです。地味ですが、この検証の型化こそ、半年後の手戻りを減らす力になるはずです。
参考リンク
- 公式: Building verification loops in Claude Code with skills（Claude / 2026年7月22日）
- 公式docs: Extend Claude with skills（Claude Code Docs / 2026年7月確認）
- 公式docs: How Claude remembers your project（Claude Code Docs / 2026年7月確認）
- 公式docs: Claude Code GitHub Actions（Claude Code Docs / 2026年7月確認）
- 参考: X上のverification loops関連反応（X / 2026年7月確認）
AI活用の確認フローを、業務の型にしませんか
i-Styleでは、AIに作業を任せるだけでなく、公開前チェック、品質確認、出典確認、手戻り防止の仕組み化まで含めて支援しています。まずは、毎回人が見ている確認作業を一緒に棚卸しできます。
お問い合わせページへarrow_forward問い合わせ前に、i-Styleサポートデスクbotでも相談できます
「どの確認をAIに任せられるか」「検証ループにするなら何から始めるべきか」など、軽い確認はサポートデスクbotでも相談できます。
i-Styleサポートデスクbotで聞くarrow_forward