2026-09-08 · claudecode · 設計 · テスト · 個人開発 · oss
誤検出を避けるために書いた規則が、そのまま死角になっていた
設定ファイルの検査ツールを作っています。README の1画面目にこう書いてあります。
指摘は、公式ドキュメントが「エラーになる」「スキップされる」「無視される」と 明記しているものだけ。
この方針の帰結として、あえて検査しないものの一覧があります。いちばん分かりやすいのはこれ。
未知のキー。 公式が「スキーマは最新 CLI に遅れる」と明記しているので、 検査すると新機能を使うたびに誤検出する。
良い規則だと思っています。いまも思っています。
そしてこれが、自分の製品が4箇所で壊れた行を数日間配っていた理由です。
検査は通っていた
有料ガイドに章を足そうとして、先に自分の製品が配っている設定を全部検査しました。
product/kit No problems (5 files checked)
product/oss No problems (4 files checked)
publish/quartet No problems (4 files checked)
publish/mdlinkcheck No problems (4 files checked)
全部緑。 それでファイルを開いて読みました。この記事があるのはそのためです。
# .claude/agents/coder.md
---
name: coder
description: ...
tools: *
model: inherit
---
tools: *。「こいつには全部使わせる」という意味で、何ヶ月か前に書いたものです。
ドキュメントを読みました。この欄が受け付けるのは
正確なツール名か、サーバ単位の mcp__<server> / mcp__<server>__* です。
裸の * はそこに含まれていません。
そして「解決できない項目があると、サブエージェントは起動を拒否される」 （解決できなかった項目名を挙げたエラーが返る）とも書いてあります。
「全部」の文書化された書き方は、欄ごと省くこと。
tools: * が実際に起動を拒否されるかは、ここでは確かめられません。断定しません。
言えるのは「文書化された書き方ではない」ことと、
省けば同じ意図が曖昧さなしに通ることです。だから行を消しました。
4箇所ありました。うち2つは公開済み。
なぜ検査ツールに見えなかったか
ここが残す価値のある部分です。
「ツール名が実在するかは検査しない」は正しい規則です。 ツールは増えます。検査ツールが持てるのはスナップショットだけです。 スナップショットは、それ以降に出た全部のツールを「未知」と報告します。 誤検出を1件出したら、その出力は二度と読まれません。
ただ、その規則を私は「tools の欄を見ない」として書いていました。
そして捕まえるべきだったものは、名前ではありませんでした。
Bashが実在するツールか → 最新の一覧が要る → 古びる*が有効な項目か → 一覧が要らない → 古びない
* はどの版でもツール名ではありません。これからもなりません。
問いは欄の構文についてのもので、私はそれを値の同一性の話に分類し、
自分の規則が「そこを見るな」と言っている場所に置いていました。
修正は9行で、出典は同じページです。
warn .claude/agents/coder.md:4
`tools: *` is not a documented pattern. Omit `tools` to inherit every
tool available to subagents.
why: https://code.claude.com/docs/en/sub-agents
「誤検出を出さない」という約束を守るために、clean 側の fixture に
出てはいけないものを2つ置きました。tools を省いたファイルと、
disallowedTools: mcp__github（文書化されたパターン）です。
そのディレクトリで0件であることを要求しています。テストは 71 → 73件。
この間違いの形
「誤検出するから X を検査しない」は、いつのまにか「X を見ない」になります。
この2つは同じ規則ではありません。 そしてその差のところに、 検査できるはずの場合が、検査されないまま座ります。
自分が書いた除外規則の全部に、1つ問いを立てるようにしました。
ここに、外部の知識を要らない部分問題は無いか。
未知の設定キーについては、答えは本当にありません。
最新のスキーマなしに、typo と新機能は区別できません。
tools についてはありました。 そして私は問いを立てていませんでした。
もう1つ変えたこと。自分のコードに対する緑は、自分のコードについての証拠ではありません。 それは**「自分のコード」と「たまたま自分が書いた規則」の交わり**についての証拠です。
ファイルを読むのに4分かかりました。緑4回では見つからなかったものが出ました。
Claude Code に設計・実装・レビューを別々の人格として分担させ、GitHub Issue と
ブランチを軸に並列開発を回すための設定一式を MIT で公開しています。
コピーして ./setup.sh を叩けば動きます。技術スタックには依存しません。
https://github.com/quintetkit/quartet
このワークフローだけで実際にツールを 1 つ作りました。Issue の分割から PR、 レビュー、マージまで記録が全部残っています。うまくいかなかった箇所も消していません。
https://github.com/quintetkit/mdlinkcheck
UI 設計人格・レビュー基準・Issue 単位の並列実行スクリプト・実践ガイド 10 章を 足したものは製品ページにあります。
実践ガイド全10章は Zenn Book で読めます（¥1,500・2章まで無料）。
https://zenn.dev/quintetkit/books/claude-code-parallel-workflow
設定一式（5人格・スクリプト・ガイド全文）の配布はこちらです。