AIに作らせて、最後に自分で直す。その直している場所が、毎回だいたい同じだと気づいた瞬間があります。型の書き方でもテストの通し方でもなく、うちのルールに合わせる部分。そこだけは、いつも人の手が入っていました。
Claude公式ブログの「Building verification loops in Claude Code with skills」は、まさにその話です。人が毎回やっている確認と修正を手順として渡し、Claude自身に検証と修正を回させる。公式記事と各ドキュメントを読みながら、実務でどう使えるかを整理します。
先にまとめ
型エラーやテストのように機械で判定できるものは、AIもすでに扱えます。残っているのは、プロジェクト固有の「毎回ここを見ている」という確認です。それを手順として書いて渡すと、AIが自分で確認して直すようになります。始め方は、今週3回以上直した確認を1つ選ぶだけ。
Claude Codeで開発やサイト更新を進めていて、任せたあとの確認が毎回残る方に向けた内容です。コマンドの一覧を探している方には向きません。
検証ループとは、自分の作業を見直して直す流れ
公式記事では、AIに作業させるときの流れを「文脈を集める → 実行する → 検証する」のループとして説明しています。依頼を受けて、必要な情報を読み、変更し、結果を確かめ、足りなければまた読みに戻る。最後の確かめる部分が検証です。
Claudeは、型チェック、lint、テスト、実行時のエラーのような、はっきり白黒がつく合図はある程度扱えます。困るのはその先です。「この案件ではここを見る」という社内の判断は、書いていなければ推測できません。
| 工程 | Claude Codeで起きること | 人が見ていた部分 |
|---|---|---|
| 文脈収集 | 関連ファイル、仕様、テスト、過去のやり方を読む | 「この案件ではこのルールを見る」という判断 |
| 実行 | コードやHTML、設定ファイルを変更する | 作業の範囲が広がりすぎていないか |
| 検証 | build、test、lint、表示確認を行う | 目視・経験・社内ルールでの最終確認 |
| 再修正 | 失敗や違反を見て直す | 毎回同じことを指摘していた部分 |
右の列が、この記事の主役です。ここを言葉にして渡せると、確認と修正のループがこちらの手を離れます。
すでに用意されている検証の入口
Claude Codeには、検証の入口がいくつも用意されています。1つの万能機能があるのではなく、手元での確認、公開前の確認、仕様との照合、主観的な品質の採点を使い分ける作りです。
まず標準の確認として、アプリを動かして結果を見る入口があります。linterや型チェック、テストのエラーを扱う道もあります。ここで効いてくるのが、プロジェクトの共通メモに正確なbuildコマンドとtestコマンドを書いておくことです。地味ですが、これが無いと検証そのものが始まりません。
個人の確認から先へ広げるなら、変更をまとめて出すときに自動レビューを走らせる方法や、pushのたびに同じ確認を必ず走らせる方法があります。仕様書と実装のズレを確かめる仕組みや、別の採点役に評価させて基準を満たさなければ戻す仕組みも登場しています。全部を一度に入れる必要はありません。順番があります。
手順にするタイミングは「3回目」
公式記事でいちばん実務的だと感じたのは、ここです。毎回同じ小さな修正をしているなら、それを手順にするタイミングだと書かれています。AIが苦手なことを嘆くのではなく、人が毎回やっている確認を言葉にして渡す。発想が前向きです。
例として挙げられていたのは、「データを移し替える手順を挟まずに列を削除する変更は拒否する」というルールでした。一般的な検査ツールでは拾いにくい。けれど、そのプロジェクトにとっては明確なルールです。こういうものこそ、手順にする価値があります。
AIが最後にミスる場所には、会社のルールが隠れている
毎回そこを口で直しているうちは、AI活用は人と人のやり取りのままです。手順として置いた瞬間に、それは仕組みに変わります。裏を返せば、AIが間違える場所を集めると、言語化できていない社内ルールの一覧ができます。
手順の書き方は、難しくありません。新しく入った人に渡すつもりで、合格の条件とNGの条件を書く。「気をつける」ではなく、「この形なら通す、この形なら止める」と書けているかどうかが分かれ目です。
走らせる場所は4つある
公式記事では、検証をどこで起動するかが4つに分けられています。最初から全体の関門にせず、手で呼び出すところから始めるのが安全です。
| 型 | 使い方 | 向く場面 |
|---|---|---|
| 手で呼ぶ | 作業後に、意図して呼び出す | たまに必要な確認（表示、ライセンス、セキュリティ） |
| 組み込む | 作る手順の中に確認を含める | 生成のたびに必ず走らせたい検査 |
| つなげる | ある手順のあとに、別の確認を呼ぶ | 整理したあとに、影響範囲を必ず確かめる |
| 毎回走らせる | 変更を出すたびに自動で実行 | チーム共通の品質の関門にしたい確認 |
上から下へ、1段ずつ上げていきます。まだ不安定な確認をいちばん下の段に置くと、現場が止まります。止まった関門は、そのうち誰かが外します。
サイト運用でも、検証ループは効く
開発者向けの話に見えますが、Web制作やブログ運用のほうが相性は良いかもしれません。毎回同じ確認を人がしている作業が、たくさん残っているからです。
手順にしやすいのは、見出しとタイトルタグが一致しているか、正規URLやサイトマップやフィードに反映されたか、問い合わせ導線が入っているか、出典リンクと公開日が揃っているか、ビルド後の表示が崩れていないか。どれも、目で見れば分かるのに、忙しい日ほど抜けるものばかりです。
逆に、人へ戻すべきものもはっきりしています。記事の主張が自社の考えと合っているか。公開してよいタイミングか。顧客名や社外に出せない情報が混ざっていないか。比較の表現が誰かを傷つけないか。そして、最終的に出すかどうかの判断。ここは手順にしません。
今週やるなら、この順番
大きな自動化に組み込む前に、小さく始めたほうがうまくいきます。公式記事の流れを、実務向けに置き換えるとこうなります。
- 今週、人が3回以上直した確認を1つ選ぶ。
ログの方針、デザインの決まり、公開前のSEO、テストの漏れ。どれでも構いません。 - 新しく入った人に渡すつもりで書く。
曖昧な言い回しではなく、合格の条件とNGの条件を書きます。 - まず手で呼び出して試す。
自分で呼んで、意図どおりに動くかを見ます。 - 3回試してから自動化する。
毎回使うと確信できたものだけ、走る場所を上げていきます。
i-Styleでも、公開前に必ず見る項目は決めてあります。タイトル面の一致、出典リンクの有無、公開してよいかの最終判断。前の2つは仕組みへ、最後の1つは人に。この配分に落ち着くまでに、何度か行き来しました。
検証ループは、万能ではない
最後に、期待しすぎないための話です。検証ループが強いのは、合格の条件を言葉にできる確認だけです。「なんとなく品質が低い」は、そのままでは渡せません。渡せる形にするには、こちらが基準を言語化する必要があります。
つまり、この仕組みの本体は技術ではありませんでした。自分たちが何を見ているのかを、書けるかどうかです。書けた分だけ手を離れ、書けない分は残る。冒頭の「毎回同じところを直している」は、裏を返せば「まだ書けていないルールが1つある」という合図でした。
よくある質問
検証ループとは何ですか？
AIが作業したあと、決めた基準で自分の結果を確かめ、必要なら直す流れのことです。人が毎回していた確認を手順として渡すことで成り立ちます。
何から手順にすればよいですか？
直近で3回以上、同じ指摘をした確認からです。頻度が高く、合格条件を言葉にできるものが向いています。
開発をしていなくても使えますか？
使えます。サイト更新や記事公開のように、毎回同じ確認が発生する作業のほうが向いている場面もあります。
まとめ：書けた分だけ、手を離れる
機械で判定できる確認は、もうAIが扱えます。残っているのは、社内にしかないルールです。それを1つずつ言葉にして渡していく作業が、そのままAI活用の地力になります。
最後に直している場所を、次から直さなくて済むようにする。派手さはありませんが、毎日1回ずつ効いてきます。
参考: Building verification loops in Claude Code with skills（Claude） ／ Skills ／ Memory ／ GitHub Actions
AI活用の確認フローを、業務の型にしませんか
i-Styleでは、AIに作業を任せるだけでなく、公開前チェック、品質確認、出典確認、手戻り防止の仕組み化まで含めて支援しています。まずは、毎回人が見ている確認作業を一緒に棚卸しできます。
お問い合わせページへarrow_forward
