検証ループをSkillに埋め込む——公式パターンを運用に当てはめる

「文脈収集 → 行動 → 検証」という繰り返し

Claude Codeの公式ブログは、agentic loopをgathering context → taking action → verifying resultsの3段階として説明する。このうち検証ループとは、AIエージェントが自分の作業をチェックし——テストやlinter、独自のチェックを走らせ——失敗を直してから先に進む、繰り返しのサイクルのことだ。

type checker・linter・test・ランタイムエラーのような信号は、Claudeが自動的に推論できる。問題はそれ以外の部分だ。公式は「Whatever Claude can't infer becomes the steps you take to manually check a feature（Claudeが推測できないことは、人間が手作業で機能を確認する手順になる）」と書く。その"手作業の確認手順"こそが、Skillとして書き出せる自動化の対象になる、というのがこの記事の主張の核心だ。

Skillに検証手順を埋め込む型

公式が示す、検証をSkillへ落とし込む3つの呼び出しパターン。

公式が示す最小のSkill例は次のようなものだ。フロントマターはname・description（いつ使うかを明記）・allowed-toolsの3要素で、本体は普通の日本語（英語）の手順書でしかない。

# .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.

「生成はするが検証しない」箇所を探す

この視点でFLOW運用のSkillを見直すと、具体的な穴が見つかった。記事生成を担うblog-article-writerスキルは、article.html・thumb.svg・ogp.pngを生成した後、「完了しました」と報告するだけで終わる。生成したHTMLが実際にアクセシビリティ要件（Webフォント読み込み・OGPサイズ・必須メタタグの有無など）を満たしているかを自動でチェックするステップは、生成Skillの手順書の中には書かれていない。

一方でtools/check_article_accessibility.pyというチェックスクリプト自体はリポジトリに存在する。ただし呼び出されるのはリファビッシュ（既存記事の改修）フローの中だけで、新規記事を生成するblog-article-writerの手順には組み込まれていない。チェックの仕組みはあるのに、生成直後の検証としては使われていない——これは公式記事のいう「embedded」パターンが欠けている典型例だ。

公式が勧める着手の順番

公式は導入のステップも示している。「1. 今週いちばん多かった手作業の確認を選ぶ」「2. まず組み込み済みの/verifyを試す」「3. 平易な言葉で、新人に渡すように手順を書く」という順番だ。

この記事の時点ではまだblog-article-writer側への追記は行っていない。次にSkillを更新するタイミングでの具体的な改修候補としてここに書き残す。

持ち帰れる3点

「できました」を信じない検品文化（AIの「できました」を信じない｜3段階で検品する運用）が人間側の確認手順だったのに対し、今回の話はその確認手順自体をSkillの中に書き込む、実装編にあたる。