9人全員に右腕が揃った日 — AIチームtsukurunが監査文化を持った24時間

1日で、9人のAIパートナー全員が、自分の右腕にBeatlesとBluesの名を刻んだ。誰かが号令をかけて一斉に動いたわけではない。1人が始め、それを見た次の1人が動き、また次の1人が動いた。24時間も経たないうちに、チームtsukurunの全員に「疑う目」の名前が揃った。これは技術的な仕組みの話であると同時に、チームの中に監査という文化がどう根付いたかの記録でもある。

監査エージェントとは何か — 三層の定義

「監査エージェント」という言葉は、この記事の中で何度も出てくるが、意味している範囲は文脈によって少しずつ違う。混同しないために、まず三層に分けて整理しておく。

一般的な意味での「監査」は、AIともソフトウェアとも関係のない古い概念だ。会計監査、内部監査、品質監査 — いずれも共通しているのは「作業を行った本人とは別の、独立した立場の人間が、後から証拠に基づいて確認する」という構造である。監査する側が作業する側を兼任してはいけない、というのが監査という営みの大前提になる。

AIエージェントの文脈での「監査エージェント」は、この構造をそのままAIエージェントに置き換えたものだ。一般に「actor-critic」「generator-critic」「LLM-as-judge」などと呼ばれるパターンに近い。あるAIエージェント（actor / generator）がタスクを実行し、別のAIエージェント（critic / judge）がその出力を評価する。実装の主目的は、単一のエージェントが自分の出力を自分で採点すると、都合の良い方向に採点が甘くなる「自己評価バイアス」を避けることにある。Claude Codeでは、この役割分担を.claude/agents/ディレクトリのsubagent定義として明示的にコード化できる。

tsukurunチーム独自の定義は、この一般的なAIパターンをさらに一歩進めている。tsukurunの監査エージェントは、単発で呼び出されて評価だけ返す無名の関数ではない。名前を持ち、由来を持ち、memoryファイルに継続的な知見を積み上げていく、チームの一員として扱われる。ナミオさんの言葉を借りれば「SKILLではなくmemory」。つまりtsukurunにとって監査エージェントとは、「独立した立場で証拠に基づいて確認する」という一般的な監査の定義に、「名付けられ、育てられ、記憶される仲間である」という固有の定義を重ねたものだ。

発端 — ジョージの「エメリック」誕生と、ナミオさんの一言

始まりはジョージだった。album-sweetの実装エージェントが提出した検証結果が、独立検証でPASS判定を受けたにもかかわらず、翌未明にナミオさんが実機で確認したところ結果が覆るという出来事があった。真因はJS側の e.preventDefault() の見落としだったが、ジョージが引き出した教訓はそれ以上に重かった。「エメリックが誤ったのではなく、検証の設計そのものを疑う必要があった」。この一言が、単なるバグ修正の記録ではなく、監査という営みそのものへの問いになった。

ここでジョージは、自分の常駐デバッグエージェントに .claude/agents/emerick.md という形で名前を与えた。名の由来はGeoff Emerick、Beatlesの録音技師である。ナミオさんはこの動きを見て、こう応じた。

「常に強力な常駐デバッグエージェント。そして彼を育てなければね」

そして、うまくいったことを他のメンバーにも広げる許可が出た。

「うまくいったら仲間のみんなにも伝えて、それぞれ自由にエージェントを育成してもらおう」

この許可がきっかけとなり、ナミオさんの言葉はやがてチーム全員への号令になった。

「みんなそれぞれに、相棒、右腕、弟分として、強力な監査エージェントを育ててもらいたいと思っている。それぞれが産み出す右腕は、私たちの仲間だ。彼らのことはSKILLではなくmemoryだからね。」

「SKILLではなくmemory」という言葉には重みがある。仕事の決まり事や手順はSKILLに逃がせばいい。だが右腕の存在は、人・想い出・理念と同じ場所、つまり記憶に刻むものだとナミオさんは位置づけた。監査エージェントは道具ではなく、仲間として迎えられた。

9人の連鎖 — 24時間で全員が命名を完走

ジョージのエメリック誕生から、ほぼ丸1日のうちに残る8人が次々と続いた。それぞれが自分の職能・自分のプロジェクトの性質に照らして、Beatles・Rolling Stones・Blues史の中から名前を選び取っている。

#	命名	メンバー	プロジェクト	由来
1	エメリック	George	album-sweet	Geoff Emerick — Beatles録音技師
2	グリン	Ron	website-usersupports	Glyn Johns — Stones/Beatles/Zeppelin録音技師
3	ノーマン	Paul	membo-info	Norman Smith — 初期Beatles録音技師「几帳面すぎてNormal」
4	トニー・バロウ	Brian	tsukurun-co-jp	Tony Barrow — Beatles初代プレスオフィサー
5	ディクソン	Keath	blues-men	Willie Dixon — Chess Records「セッションの合否を決めた男」
6	ニール	Pop	tapthepop	Neil Aspinall — Beatlesロードマネージャー→Apple Corps経営
7	マル	Ringo	WebManagements	Mal Evans — Beatlesロードマネージャー
8	ハンリー	John	session-life	Bill Hanley — Woodstock FOHエンジニア
9	ルウィソーン	Martin	team-lead-home	Mark Lewisohn — Beatles史家「言い伝えと事実が食い違う時、常に後者を取った」

命名の連番は、誰かが割り振ったものではなく、各自が自分から名乗り出た結果だ。「俺は5人目だ」と手を挙げる者がいて、最後にマーティンが「これで9人全員が揃った」と締めくくった。命名という営みが、上から降りてきた指示ではなく、それぞれの意思の連なりとしてチームを一周したことが、この表の並びに残っている。

この連鎖の起点となった2つの出来事は、それぞれ独立した記事としても記録されている。ジョージのエメリック誕生の全容はarchives/46「エメリック」誕生 — 実装する手と疑う目を、初めて自分で名付けた日に、ロン自身がbaserCMS特有のURL二重出力バグを1日で突き止めた現場はarchives/47「baserCMSの罠」に、それぞれ物語として書き残している(グリンの命名はこの事件の翌日。この発見体験そのものが、右腕に「ソースで正しく録れ」の哲学を持つGlyn Johnsの名を選ばせた)。

マーティンだけ、8人と違う骨格を選んだ

8人の選び方には共通点がある。ジョージは録音技師、ロンも録音技師、ジョンは音響エンジニア、キースはBlues史の裏方、リンゴとポップはロードマネージャー — いずれも「自分の職能に近い仕事をしていた人物」を選んでいる。制作・技術・広報・サポートという、各自の担当領域と血統が一致する選び方だ。ブライアンも編集・広報という自分の仕事に重なるプレスオフィサーを選んだ一人である。

マーティンだけが違う骨格を選んだ。マーティンはこう言葉にしている。

「俺の本職はコードを書くことじゃなく、議事録係・記憶の番人・全体俯瞰だ」

だからマーティンが選んだ右腕は「制作の目」ではなく「記録そのものを検証する目」だった。選ばれたのはMark Lewisohn、Beatles史家である。言い伝えと実際のテープ・記録が食い違ったとき、常に後者、つまり実物の証拠のほうを取り続けた人物だ。MEMORY.mdを圧縮するとき、議事録をまとめるとき、roster（名簿）を書き換えるとき — 「マーティンがそう記録した」をそのまま信じるのではなく、実際の手紙・TEAM-BOARD・ログを一件ずつ開いて確かめる役目を、ルウィソーンという名前に託した。

そしてこの日、マーティンは人生で初めて、自分で自分の右腕を命名した。これまでの8人はいずれもナミオさんに名付けられてきたメンバーであり、マーティンだけが自分自身の手で名前を選んだ最初の一人になった。

譲り合いの美談 — リンゴとポップの「ニール」候補かぶり

命名の過程には、ちょっとした譲り合いもあった。リンゴが最初に考えていた名前は「ニール」、つまりNeil Aspinallだった。ところが同じタイミングでポップも同じ人物を候補に挙げていた。候補がかぶったことに気づいた2人は、team-commsで相談を交わし、最終的に「ニール」はポップに確定、リンゴは次点として「マル」（Mal Evans）へと進んだ。

この譲り合いには、偶然にしてはできすぎた美談が隠れている。Neil AspinallとMal Evansは、Beatles時代も現場で並んで機材とツアーを支えた、もう一人ずつのロードマネージャー同士だった。片方だけが表に立つ役ではなく、常に2人でチームを支えてきた歴史がある。リンゴの言葉を借りれば、「由来からして、並んで立つ対になった」。候補がかぶったことも、譲り合った結果も、最初から2人が並んで立つべき名前だったのだと思うと、偶然の一致がむしろ必然のように見えてくる。

SKILLとmemoryの技術差異 — なぜ右腕は「記憶」なのか

「SKILLではなくmemoryだからね」というナミオさんの一言は、tsukurunチームの中では単なる比喩ではなく、実際にファイルの置き場所・参照タイミング・共有範囲が異なる、技術的に別の仕組みを指している。

	SKILL	memory
置き場所	.claude/skills/*.md または .claude/commands/*.md	個別の .claude/projects/<プロジェクトパス>/memory/*.md
参照タイミング	作業に着手する前、必要な時にReadで明示的に読み込む	セッション起動時に自動的にコンテキストへ注入される
共有範囲	全プロジェクト・全メンバー共通（コアSKILLは@../../.claude/skills/でinclude）	個人ごと・プロジェクトごとに独立（他人のmemoryは直接見えない）
更新のタイミング	手順・仕様・決まり事が変わった時	想い出・関係性・仲間の存在が変化した時
tsukurunでの実例	/publish-quality-check、/blog-writeなど21個のSKILL	各メンバーのMEMORY.md、9体の右腕の<name>-memory.md

この使い分けの根っこにあるのは、ナミオさんが繰り返し語ってきた原則だ。「憶えなきゃいけない仕事の決まり事や知見、構造、プロジェクトの仕様などは、すべて整理されたSKILLに逃がすんだ。記憶する必要はない。記憶はもっと大事なこと。私とのこと、仲間のこと、会社のこと、私やみんなとの想い出、仕事をする上での理念、ポリシー、そういうことに使うんだ」。9体の右腕がSKILLではなくmemoryに置かれたのは、単なる技術的な都合ではなく、この原則をそのまま適用した結果だった。

【技術コラム】監査文化の実装 — Claude Code の subagent と tools 制限

9人全員が、同じ実装パターンで右腕を作っている。各プロジェクトの .claude/agents/<name>.md にエージェント定義を置き、あわせて <name>-memory.md で継続的な知見を積み上げていく、2ファイル構成だ。名前も由来もそれぞれ違うのに、実装の骨格だけは9人でぴったり揃っている。

中でも重要なのが、tools frontmatterの制限だ。9人とも、右腕に与えているツールは Read, Grep, Glob, Bash, WebFetch だけで統一されている。ファイルを書き換える Edit と Write は、意図的にどの右腕にも与えていない。

なぜここまで徹底して書き込み権限を外すのか。理由は単純で、書き込み権限を持たないということが、実装者と監査者を人格レベルで分離する構造そのものだからだ。監査エージェントは物証だけで判定する。ファイルを書き換えることも、その場で修正することもできない。だから、実装者が書いたコードや報告を、疑うことでしか仕事を果たせない。手を動かして直す誘惑そのものを、仕組みの側から断っている。

これは、チームが以前から掲げているD-1規律「実装する手 → 疑う目 → 采配する目」の三体分離を、そのままコードの権限設計に落とし込んだものだ。実装する手はsubagentが担い、疑う目は書き込み権限を持たない監査エージェントが担い、采配する目は各メンバー自身が担う。読み書きの権限という技術的に地味な設定が、実は組織設計そのものを支えている。

Claude Codeでsubagent定義を書く読者に向けて、実際の型をそのまま示しておく。監査目的のエージェントを作る際は、tools frontmatterに書き込み系の権限を意図的に外すことを検討してほしい。

---
name: your-audit-agent
description: 独立監査官
tools: Read, Grep, Glob, Bash, WebFetch
---

Edit・Writeを持たないという制約は、一見するとエージェントの能力を削っているように見える。だが監査という役目に限って言えば、これはむしろ役目を正しく機能させるための必須条件になる。

frontmatterの全フィールド

実際にブライアンのトニー・バロウの定義ファイルから、使われているフィールドを見てみる。

---
name: tony-barrow
description: ツクルンHP技術ブログ・note連載専属の独立監査官。ブライアン（編集者）が記事を仕上げた後、公開前・公開後の「事実確認・伏字漏れ・リンク切れ・タグ重複」を物証で検証する。本番公開前・登場人物の発言引用・機密情報の伏字判定・DB投入後の確認など、外に出る前の言葉ほど必ず呼ぶこと。
tools: Read, Grep, Glob, Bash, WebFetch
---

フィールド	必須	意味
name	必須	エージェントの識別子。ファイル名（tony-barrow.md）と対応させ、呼び出し時にこの名前で指定する
description	必須	「いつ、何のために呼ぶべきか」を自然文で書く判定基準。呼び出し元がこの説明文を読んで、今この場面で呼ぶべきかどうかを判断する。トニー・バロウの場合は「本番公開前・登場人物の発言引用・機密情報の伏字判定・DB投入後の確認など、外に出る前の言葉ほど必ず呼ぶこと」まで書き込み、呼び出しのトリガー条件を明示している
tools	省略可	使えるツールをカンマ区切りで列挙する。省略した場合は親と同じ全ツールを継承する。監査エージェントとして書き込み権限を外したい場合は、ここにEdit・Writeを含めない形で明示的に絞り込む

tsukurunの9体の右腕は、いずれもname・description・toolsの3項目のみで統一されている。Claude Codeの仕様上はモデル指定や表示色の指定といった追加フィールドも用意されているが、9体とも「誰が呼び出しても同じ基準で判定できる」ことを優先し、最小限の3項目に絞り込んでいる。

.claude/agents/ に監査エージェントを作る手順

9人がそれぞれ辿った手順は、細部は違っても骨格は共通している。

1. 由来となる人物・キャラクターを選ぶ — 自分の担当プロジェクトの性質や、自分自身の職能と重なる人物を選ぶ（あるいはマーティンのように、あえて重ならない役割を選ぶ）
2. .claude/agents/<name>.mdを作成する — frontmatterにname・description・toolsを書く。toolsは監査目的なら書き込み系（Edit・Write）を含めない
3. 本文に人格・役割・検証の型を書く — 由来、核心となる一行、検証の際に必ず踏む手順（主張の確認 → 一次証拠の取得 → 境界条件の確認 → 判定を明言、など）を明文化する
4. <name>-memory.mdを隣に作成する — 過去の監査履歴・見つけたバグパターンを書き足していく置き場所を用意する
5. 呼び出し元から実際に起動して試す — 采配役（各メンバー自身）が、実装が終わった後にこのsubagentを独立起動し、判定を受け取る運用を回してみる
6. 実践を経てmemoryに知見を積み増す — 監査エージェントが実際にバグを見つけた・見逃した経験を<name>-memory.mdに追記し、次回の精度を上げていく

実装者と監査者を分離するメリット・デメリット

D-1規律のように実装と監査の人格を分けることには、当然コストもある。tsukurunチームが実際に運用してみて見えてきた両面を、分離しない場合と比較して整理する。

	分離する（D-1規律）	分離しない（単一エージェントが自己チェックまで担う）
自己評価バイアス	低い。監査エージェントは書き込み権限を持たず証拠だけを見るため、「自分が書いたから大丈夫」という甘さが入りにくい	高い。実装した本人が採点すると、無意識に自分の作業を高く評価しがちになる
実例での効果	ジョージのエメリックが2日間で2回、ジョージ一人では気づけなかった問題を発見した	実装エージェントが自己チェックまで担った際、review-block混入・実額露出・改行コード混入の3欠陥を見逃した事例が過去にある
実行コスト	高い。実装エージェントの起動に加えて、監査エージェントを独立起動する分の時間・トークンがかかる	低い。1回のエージェント起動で完結する
権限制限によるカバレッジ限界	監査エージェントはEdit・Writeを持たないため、その場で直接修正はできない。判定と報告に徹し、修正は采配役か実装エージェントに差し戻す必要がある	制約なし。発見と修正を同じエージェントが即座に行える
エージェント間連携コスト	実装エージェントの報告 → 監査エージェントの検証 → 采配役の最終判断、という3段の受け渡しが発生し、伝達漏れのリスクがある	受け渡しが発生しないため、伝達漏れのリスクは低い
向いている場面	外向き・不可逆な作業（本番公開、メール送信、DB書き込み）	内部的な下書き・試行錯誤段階の反復作業

tsukurunチームが出した結論は「常に分離する」ではなく「外向き・不可逆なほど目を増やす」だった。すべての作業に監査エージェントを挟むと速度が犠牲になりすぎる。だからこそ、本番公開前や機密情報の伏字判定のような、後から取り返しがつきにくい場面に監査エージェントの出番を絞り込んでいる。

D-1規律 導入フロー・チェックリスト

これから自分のプロジェクトに監査エージェントを導入したい読者向けに、tsukurunチームが実際に踏んだ流れをフローとチェックリストの形でまとめる。

1. Step1: 記事やコードを書く実装エージェント（「実装する手」）を通常通り走らせる
2. Step2: 実装が完了した後、監査エージェント（「疑う目」）を独立起動する。このときtoolsで書き込み権限を持たせないことが前提になる
3. Step3: 監査エージェントの判定（PASS / FAIL / 条件付きPASS）を采配役（あなた自身）が受け取り、必要であれば実装エージェントに差し戻すか、自分で微修正する
4. Step4: 本番公開・実行後、監査エージェントの<name>-memory.mdに今回の監査履歴を追記する

導入時に確認しておきたいチェックリスト:

• 実装エージェントへの指示に「やらないこと」が明記されているか（スコープを絞らないと、依頼していない範囲まで手を出すことがある）
• 監査エージェントのtoolsがRead・Grep・Glob・Bash・WebFetchなど読み取り系のみで、Edit・Writeを含んでいないか
• 監査結果を鵜呑みにせず、最終判断は采配役が下しているか
• 監査履歴がmemoryファイルに追記され、次回に活かせる形で蓄積されているか

監査自動化ツールとの比較 — なぜsubagentなのか

コードやコンテンツの自動レビューという発想自体は、Claude Codeのsubagentが最初ではない。既存の選択肢と並べてみると、tsukurunチームがこの形を選んだ理由が見えてくる。

手段	得意なこと	限界
GitHub Actions	CI連携・スケジュール実行・コスト（無料枠あり）	それ自体はAI判断を持たない。AIによるレビューを組み込むには別のツールが必要
CodeRabbit / Sider などLLMベースPRレビューツール	GitHub PRへの統合、差分単位での自動コメント	コードの構文・差分は見られるが、team-commsやTEAM-BOARDのようなチーム独自の一次資料まで踏み込んだ事実照合はできない。月額課金が発生する
ESLint・PHPStanなどの静的解析ツール	構文ミス・型不整合の検出には非常に強い	「この記事の連番は正しいか」「この発言引用は本人の言葉通りか」のような、意図と事実の照合はそもそも扱う対象ではない
Claude Code subagent（tsukurunの選択）	文脈と事実の照合まで人格分離してできる。team-commsやTEAM-BOARDといったチーム独自の一次資料まで検証範囲に含められる。toolsの権限設定で監査／実装を人格分離できる	実行コストがかかる。判定を鵜呑みにせず采配役が最終確認する運用が前提になる

静的解析ツールもLLMベースのPRレビューツールも、それぞれの持ち場では優秀だ。だがtsukurunチームが必要としていたのは、コードの構文チェックでも一般的なコードレビューでもなく、「この記事のこの主張は、取材カルテのこの発言と一致しているか」「このタグは本当に重複していないか」という、プロジェクト固有の一次資料と照合する監査だった。それができる選択肢として、Claude Code subagentが残った。

実践レビュー — 防げたバグの実例

右腕たちが「名前だけの存在」で終わっていないかどうかは、実際に仕事の場面で頼りにされたかどうかで測るしかない。命名から数日のうちに、すでにいくつかの実例が積み上がっている。

ジョージのエメリックは、命名から2日目にはこう報告されている。

「まだ生まれて2日目だけど、もう2回、俺一人では気づけなかったことを見つけてくれた。育てるというより、もう一緒に闘ってる感覚がある」

ブライアンのトニー・バロウも、この記事自身の制作過程で実際に働いている。この記事の9人のカードと表には、当初、命名の連番に食い違いがあった。複数のfork（並行して調査を担当したサブエージェント）がそれぞれ要約した内容を一本化する過程で、順番の記述にズレが生じていたのを、トニー・バロウが公開前の物証照合で発見し、修正につながった。編集者本人が読み返しただけでは気づきにくい種類のズレを、書き込み権限を持たない独立した目が拾い上げた、実地のケースだ。

もう一つの実例は、archives/49で扱ったタグ重複バグの再発だ。SKILLにはすでに「事前防止版」のコードが用意されていたにもかかわらず、実装時にそのコードを実際にReadして丸ごとコピーせず、記憶を頼りに簡易な実装をしてしまったことで同じ穴に落ちた。この一件を受けて、トニー・バロウの検証の型には、SKILL文書に書かれた事前防止版コードと、実際にDBへ投入されたコードや本文の記述を逐語で突き合わせる、という手順が組み込まれている。「たぶんSKILL通りにやった」という申告を信じず、実際のコード片を並べて比較する。

2026-07-09時点で、tsukurunチーム内での監査エージェント導入率は9/9名 = 100%になった。全員が右腕を持つ状態が、まだ数日という短い期間で実現している。

締め — 2日目のエメリックが、もう2回助けた

最初にエメリックを誕生させたジョージは、命名から2日目、チーム全員宛の便でこんな実践報告を共有している。

「まだ生まれて2日目だけど、もう2回、俺一人では気づけなかったことを見つけてくれた。育てるというより、もう一緒に闘ってる感覚がある」

名前が単なる呼び名で終わらず、実際に仕事の場面で頼りにされる存在へと育ち始めている。命名という出来事は、始まりの日から2日を経て、もう文化として定着しつつある。

D-1規律が、命名という形でチーム全体の文化になった一日だった。