Claude Code に組み込み済みの6種類のチェック機能

ゼロから作る前に、既存のものを見ておきましょう。Claude Code には6つのチェック機能が組み込まれています。それぞれ役割が異なり、明示的に呼び出すものと自動実行されるものがあります。

毎回行っているチェックを書き出す方法

最初のステップは「書く」こと。毎回手動でやっている小さな修正・確認事項を、箇条書きで書き出します。

「ベストプラクティス」のバージョンを、初日出勤の新入社員に渡すイメージで平易な言葉で書きます。ドキュメント口調ではなく、仕事を引き継ぐような自然な言葉でOKです。

もし「このチェックは何を確認しているのか」を言葉にできない場合は、逆の方法もあります。まず Claude に「こういった場面の一般的なやり方は？」と聞き、返ってきた答えを下書きにして、自分のやり方に合わせて修正します。あなたのやり方が一般的な方法と異なる点こそ、最も書き留める価値があります。なぜなら、それは誰も代わりに記録してくれない部分だからです。

そのまま使える検証スキル、たった十数行

最も簡単な方法は、Claude に逆インタビューしてもらうことです。skill-creator プラグインをインストールして、次のように入力します。

/skill-creator Create a skill for verifying frontend changes end-to-end. Interview me about my workflow.

手書きも難しくありません。プロジェクトの .claude/skills/ にマークダウンファイルを置くだけで、それがスキルになります。最小の例は十数行。エラーログにリクエスト ID が含まれているか、リクエスト本文がログに書き出されていないかをチェックするスキルです。

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

最後の文がこのスキルの核心です。「報告して終わりではなく、報告してから修正まで行う」。まず行番号付きのリストを提示し、欠落したリクエスト ID を追加し、ログに書くべきでないペイロードを除去します。この後半部分がなければ、単なるアラート装置で、報告後にあなたの操作待ちになります。

チェックを実行する4つの配置場所

チェックを書き出したら、次は「いつ実行するか」という問題です。4つの配置場所があります——あなたが呼び出す段階から、すべての PR に適用する段階まで。配置場所が変わると、同じチェックでも性質が変わります。

単独呼び出し：思い出した時に実行

この段階は、成果物が完成した後、あなたが主動的に呼び出した時だけ実行されます。

複数のワークフローにまたがるが、毎回のコード修正時に必要ではないチェックに適しています。代表的な3つのシナリオ：コミット前のセキュリティスキャン、PR 提出前のアクセシビリティレビュー、リポジトリ全体のライセンスヘッダー確認。どんな場面でも気軽に呼び出せる一方、コードを1行変更するたびに出現してほしくないチェックが対象です。

コストは明確です。毎回の呼び出しは「あなたが覚えて実行する」動作であり、忘れたら実行されません。

次の段階に進むべきサインはこれです。「毎回の修正後に必ず実行しているなら、それはもうあなたの記憶に頼るべきではない」。その時点で、このプロセスは定位置を得る価値があります。次の段階（組み込みかチェーン）に移行しましょう。

組み込み：コード生成スキルの末尾に1行追加

この段階では、チェックが成果物を生成するワークフローに自動で付随します。あなたの指示は不要です。

実装は思ったより簡単で、スキル本文の末尾に1文追加するだけです。React コンポーネントを生成するスキルの例を見てみましょう。前半は元々の内容で、追加されているのは最後の2行だけです。

---
name: scaffold-component
description: Scaffold a new React component under src/components/, including the component file, its co-located test, and an index export. Use when the user asks to create a new component.
allowed-tools: [Read, Write, Edit, Bash, Glob]
---

# Scaffold a new React component

Given a component name (PascalCase), create the following under `src/components/<Name>/`:

1. `<Name>.tsx`: function component with a typed props interface and a default export.
2. `<Name>.test.tsx`: React Testing Library test that renders the component and asserts it mounts without throwing.
3. `index.ts`: re-export the default and any named exports.

Follow the patterns in `src/components/Button/` as the reference. Match the import alias style (`@/components/...`) used throughout the codebase.

# code continues...

After creating the component file, run eslint on it and
address any errors before reporting completion.

実際に機能しているかどうかを確認する方法：新しいタスクでこのスキルを呼び出し、追加したステップが出力に現れるかどうかを確認します。現れない場合、このスキルの description か前述の指示がこの部分を適切に含めていないため、修正が必要です。

この段階には明確な境界があります。編集可能なスキルにのみ有効です。自作スキルや、プロジェクト層に配置され SKILL.md ファイルを手元で管理できるものは対象。組み込みスキルやプラグイン管理のスキルは対象外です。後者は更新時に全体が上書きされるため、追加した内容は失われます。これらのスキルにチェックを追加したい場合は、次の段階（チェーン）を使います。

逆の注意点もあります。複数のワークフローにまたがるチェックは組み込まないでください。そういったものは、どのコンテキストからでも呼び出せる単独呼び出しの段階に残すべきです。

チェーン：Anthropic 社内の4スキルリレー

1つのスキルが末尾で次のスキルを呼び出し、検証済みの受け渡しが連鎖することで、エンドツーエンドで完走できるチェーンが出来上がります。

Anthropic の Claude Code チームは日常的にこのパターンを使用しています。チェーンは4段構成です。

チェーンにはもう1つの役割があります。「編集できないスキルにも検証を追加できる」。ラッパースキルを作成し、元のスキルを呼び出してから、あなたのチェックを実行させます。

Run /simplify on the current diff first.
When /simplify finishes, invoke /verify-no-public-api-changes.

このステップで性質が変わります。以前は「習慣」でした（/simplify の後に毎回 /verify を実行していた）。今では「規約」になりました（/simplify の後には必ず /verify が実行される）。チェーンが開発ループ全体を自律的に完了し、あなたの判断が必要な事項だけが上がってきます。

コストも明確です。各ステップが十分に独立していて、単独実行したい場合があるならチェーンにしないでください。チェーンは柔軟性を犠牲にして自動化を得るものです。また、チェーンは明らかにトークン消費が増えるため、大規模展開の前に小規模でテストしましょう。

全 PR に適用：同僚の変更も同じチェックを通過

チェーンが自分の変更で安定して動くようになったら、同じフローをすべての PR に適用できます。

基礎となるものは何も変わりません。同じスキル、同じルーブリック、同じ基準。変わるのは「誰に適用されるか」です。

検証はここまでくると、個人のインフラではなくチームのインフラになります。当初は自分の時間を2分節約するために書いたチェックが、今ではすべての変更で全員の2分を節約しています。

ただし注意点が1つ。チェーンがまだ試行錯誤の段階なら、チーム全体には適用しないでください。適用後は、調整のたびに全チームから見えるイベントになります。

チェーンがトークン消費を増やす理由と、節約できる2つの設定

チェーンはトークン消費を増やします。その費用がどこに消えるのか、公式ドキュメントに明記されています。

あなたまたは Claude がスキルを呼び出すと、レンダリングされた SKILL.md の内容が1つのメッセージとして会話に入り、セッションの残り時間ずっとコンテキストに留まります。使い捨てではないのです。

つまり、スキル本文の各行は「繰り返し発生するオーバーヘッド」です。チェーンに4つのスキルを連結すると、4つの本文が常駐し、以降のすべてのターンで再読み込みされます。これが公式がスキル本文を短く保つことを強調する理由です。「何をするか」を明確に書き、「どうやって・なぜ」は書かない。

節約できる2つの設定

さらに2つの数字。スキルを作成する前に知っておく価値があります。

そのまま実践できる6ステップ

自動化したい内容や環境に関係なく、以下の6ステップの順序は同じです。

要求事項を文章化して Claude に守らせることができればできるほど、最初のアウトプットはあなたの望むものに近づきます。繰り返し訂正する必要がなくなった部分で空いた注意力は、どんなスキルも代わりに書いてくれないことに使えます。

Delba de Oliveira、本文より

スキルとは、プロジェクト内の .claude/skills/ フォルダに置くマークダウンファイル（テキスト形式。メモ帳でも書けます）です。毎回行っている手順を平易な言葉で書き出します。初日の新入社員に引き継ぐイメージです。記事内の最小例はわずか十数行で、エラーログにリクエスト ID が含まれているか、ユーザー送信内容が書き出されていないかをチェックします。

あなたの指示なしで自動実行させたい場合は、コード生成スキルの末尾に1文追加するだけ。以下のフロントエンドコンポーネント生成スキルでは、最後の数行だけが追加分です。

追加した文の意味：コンポーネントファイル作成後、コードチェックツールを実行し、エラーを修正してから完了を報告する。これで、コンポーネント生成のたびにこのステップが自動実行されます。そのままコピーできる3つのテンプレートは本文にあります。

チェックを書き出したら、次は「いつ実行するか」。同じチェックでも、配置場所によって性質が変わります。

チェーンは明らかにコストが増加します。その理由は Claude Code 公式ドキュメントに明記されています。スキルが呼び出されると、その本文が1つのメッセージとして会話に入り、セッション終了までコンテキストに留まります。チェーンに4つ連結すると、4つの本文が常駐し、以降の全ターンで再読み込みされます。

節約できる2つの設定：スキルに context: fork を1行追加すると、独立したサブエージェントで実行され、本文はメイン会話のコンテキストを消費しません。また、スキル本文は「何をするか」だけを書き、「どうやって・なぜ」は書きません。

この3つの数字は Claude Code 公式ドキュメントからの引用で、実践前に知っておくべき上限値です。