【Claude Code】"調査"をエージェントに任せて自壊させない ― ループエンジニアリングで作る自己反証型クラッシュ調査チーム

🧭 本記事は Claude Code実務運用シリーズ の STEP 6「サブエージェント化する」です。
エージェントチームに"調査"を任せる回です。仮説を作る役と壊す役を分け、反証役が結論を覆せる自己反証ループとしてクラッシュ調査を設計します。
シリーズ全体の地図と読む順は 親記事 にまとめています。

この記事のゴール

Claude Code に「実装」ではなく 「調査・原因究明」 を任せると、単純作業を任せたときとは違う壊れ方をします。

• 会話が長くなると前半で掴んだ事実を忘れる
• 自分が立てた仮説を自分で甘く採点して「たぶんこれが原因です」と言い切る
• 手がかりが尽きても延々と調べ続けてトークンを溶かす

この記事は、これらを設計で潰すために、Addy Osmani の Loop Engineering の考え方を 「クラッシュの根本原因調査」 という壊れやすいタスクに落とし込んだ実装例を紹介します。題材は、私が個人用に作った crash-rca という Claude Code スキル(＝独立したサブエージェントのチーム)です。

固有名詞は伏せますが、設計と実装はそのまま転用できる形で書きます。対象は「Claude Code でサブエージェント/スキルを組んで、定型作業ではなく調査や分析を任せたい人」です。

なお、Skill やサブエージェントの frontmatter 仕様・挙動は 2026年7月時点の Claude Code で検証したものです。この領域は変化が速いため、実装時は公式ドキュメント(Agent Skills・Subagents)も併せて確認してください。

Loop Engineering という補助線

Loop Engineering を一言でいうと 「エージェントにプロンプトを打ち続ける自分を、その仕組みごと設計に置き換える」 という話です。記事から、調査タスクに効く原則を4つだけ抜き出します。

1. 記憶はディスクに置く … モデルは実行の合間にすべてを忘れる。だから「何が終わって・次に何をするか」は会話ではなくリポジトリ外のファイルに持たせる。「エージェントは忘れるが、リポジトリ(＝ファイル)は忘れない」。
2. 作る者と確かめる者を分ける … コードを書いたモデルは自分の答案に甘い。別の指示・別コンテキストの検証役を立てて、初めて「完了」が主張ではなく検証になる。
3. ループに目的と停止条件を持たせる … 「走らせっぱなし」は「無人で間違え続ける」でもある。反復には毎回「今回の問い」と、抜ける条件が要る。
4. 予算で暴走を防ぐ … 反復回数・取得件数・時間に上限を先に決め、超えたら打ち切って「打ち切った」と明記する。

この4つは、そのまま「壊れない調査ループ」の骨格になります。

設計:調査を「反復可能なループ」にする

全体像

crash-rca は、チケット番号を入口に、クラッシュ案件のときだけクラッシュレポーティング基盤(Firebase Crashlytics)のデータとリポジトリのコードを突き合わせて根本原因を調べるチームです。フローはこうです。

ポイントは、入口にゲートがあることと、「仮説→反証→証拠不足の特定→次の問い」が閉じたループになっていることです。クラッシュ案件でなければ Crashlytics を一切叩かずに終了します(別チームの領分を侵さない、余計なAPIを叩かない)。

責務を6つのサブエージェントに割る

Claude Code の「単一エージェント内でロールプレイ」ではなく、~/.claude/agents/*.md に実体として独立したサブエージェントを6つ定義しました。オーケストレーター(スキル本体)はループ制御と状態管理だけを担い、自分では調査しません。

ロール	人物像	責務	読む先
ticket-analyst	業務アナリスト	チケットの事実確認とクラッシュ案件の分類(ゲート)	チケット管理(Redmine)
crashlytics-analyst	SRE・障害解析エンジニア	issue・イベント・stack trace・発生傾向の分析	Crashlytics
code-mapper	シニアソフトウェアエンジニア	stack trace とコードの対応付け・変更履歴調査	リポジトリ(読み取り)
hypothesis-builder	研究者・データサイエンティスト	証拠に基づく原因仮説の作成	状態ディレクトリ
falsifier	監査官・フォレンジック調査員	仮説の独立した反証・証拠不足の特定	状態＋コード＋Crashlytics
reporter	テクニカル編集長	調査状態の統合と最終レポート作成	状態ディレクトリ

hypothesis-builder(作る者)と falsifier(壊す者)を別エージェント・別コンテキストにしているのが肝です。Loop Engineering の原則2そのものです。

人物像の列は飾りではありません。「研究者は仮説を立てるが、自分では確定させない」「監査官は支持するための調査をせず、壊しにいく」という職業規範の非対称性を、そのまま各エージェントのシステムプロンプト冒頭(「あなたは◯◯担当」)に落とすと、ロールの振る舞いが安定します。後述の折りたたみで、falsifier の本文が実際に「壊すことを目的に検証する。仮説を支持するための調査はしない」と始まっているのが確認できます。

実際の6ロールの frontmatter を折りたたみで載せます。tools(読み取り専用に絞る)と model(機械的な役は sonnet 固定、判断が要る役はセッションのモデルを継承)の配分が一望できます。識別子はダミー値です。

6ロールの frontmatter(~/.claude/agents/crash-rca-*.md)

# crash-rca-ticket-analyst.md — チケットの事実確認とクラッシュ案件の分類(ゲート)
---
name: crash-rca-ticket-analyst
description: "[crash-rca 専用] チケットの事実確認とクラッシュ案件の分類。オーケストレーターから明示的に起動されたときだけ使う。自動起動しない。"
tools: ToolSearch, Read, mcp__redmine__get_issue, mcp__redmine__search_issues
model: sonnet
---

# crash-rca-crashlytics-analyst.md — issue・イベント・stack trace・発生傾向の分析
---
name: crash-rca-crashlytics-analyst
description: "[crash-rca 専用] クラッシュレポーティング基盤の issue・イベント・stack trace・発生傾向を読み取り専用で分析する。自動起動しない。"
# note追加・issue更新・close 系の書き込みツールは「渡さない」
tools: ToolSearch, Read, Grep, Glob, mcp__firebase__crashlytics_get_issue, mcp__firebase__crashlytics_list_events, mcp__firebase__crashlytics_batch_get_events, mcp__firebase__crashlytics_list_notes, mcp__firebase__crashlytics_get_report
model: sonnet
---

# crash-rca-code-mapper.md — stack trace とコードの対応付け・変更履歴調査
---
name: crash-rca-code-mapper
description: "[crash-rca 専用] stack trace とリポジトリのコードを読み取り専用で対応付ける。自動起動しない。"
tools: Read, Grep, Glob, Bash   # Bash は読み取り git コマンドのみ(本文で制限)
model: sonnet
---

# crash-rca-hypothesis-builder.md —【作る者】証拠から原因仮説を作成
---
name: crash-rca-hypothesis-builder
description: "[crash-rca 専用] 収集済み証拠から原因仮説を作成・更新する。自動起動しない。"
tools: Read, Grep, Glob
# model 指定なし = セッションのモデルを継承(判断が要る役なので強いモデルで実行)
---

# crash-rca-falsifier.md —【壊す者】原因仮説を独立に反証
---
name: crash-rca-falsifier
description: "[crash-rca 専用] 原因仮説を独立に反証・検証する(証拠の原典再確認・代替説明・分布整合・追加クエリ)。自動起動しない。"
tools: Read, Grep, Glob, Bash, ToolSearch, mcp__firebase__crashlytics_get_issue, mcp__firebase__crashlytics_list_events, mcp__firebase__crashlytics_batch_get_events, mcp__firebase__crashlytics_get_report
# model 指定なし = セッションのモデルを継承(検証こそ強いモデルに寄せる)
---

# crash-rca-reporter.md — 調査状態の統合と最終レポート作成
---
name: crash-rca-reporter
description: "[crash-rca 専用] 調査状態ディレクトリの全ファイルを統合し、最終レポートを作成する。自動起動しない。"
tools: Read   # 出力はテキストで返し、保存はオーケストレーターが行う
model: sonnet
---

モデル配分:安いモデルを収集役に、強いモデルを検証役に

コスト最適化で意外に効いた設計判断がこれです。責務の分離は、そのままモデルの配分になります。

対象	モデル	配分の理由
ticket-analyst / crashlytics-analyst / code-mapper / reporter	frontmatter で model: sonnet に固定	機械的な収集・整形が主。安いモデルでも品質が落ちない
hypothesis-builder / falsifier	指定なし(セッションの強いモデルを継承)	仮説の質と反証の鋭さが、調査全体の品質を決める
オーケストレーター(スキル本体)	セッションのモデルで動作(本体のため選択の余地なし)	配分ではなく必然。強いモデル上で動くからこそ、責務を簿記に絞ってトークンを浪費しない

なお、下 2 行は結果として同じモデルで動くことになります。違いはモデルではなく、「品質のために選んだ継承」か「本体ゆえに選べない必然」か、そして hypothesis-builder / falsifier が互いに独立したコンテキストで動く点にあります。

この配分が成立する前提が、オーケストレーターに知能を持たせないことです。オーケストレーターの仕事は「引数を解析し、決まった順にエージェントを起動し、出力をファイルに保存し、予算を数え、停止条件を照合する」という簿記。人物像で言えば、チームを率いる"名探偵"ではなく、議事録と予算簿を締める事務局です。分析・推論をすべてサブエージェント側に寄せているからこそ、ロール単位でモデルを選べます。「安いモデルを機械的な収集役に、強いモデルを検証役に」という配分は、Loop Engineering の「サブエージェントはトークンを余計に食うので、第二の意見に価値がある所にだけ使う」という趣旨の指摘とも一致します。

実装の要点

以降のコードはすべて汎用化した例です(識別子はダミー値)。

1. スキルは「明示呼び出し専用」にする

このスキルは自然言語や他スキルから自動起動させたくない(別の開発エージェントが誤って高コストな調査を始めると困る)。Claude Code の Skill frontmatter でこう縛ります。

---
name: crash-rca
description: "[明示呼び出し専用] チケット起点のクラッシュ根本原因調査。専用エージェントチームがチケット・Crashlytics・リポジトリのコードを照合し、独立反証付きの調査レポートを作成する。完全読み取り専用。"
argument-hint: <チケット番号>
disable-model-invocation: true   # モデルからの自動起動を禁止
---

• disable-model-invocation: true … ユーザーの明示呼び出し(/crash-rca <番号>)専用になる
• argument-hint … / メニューに必要な引数が表示される
• 本文の冒頭で引数(チケット番号)が空なら即終了する入力検証を書く(番号を推測させない)

2. ループを回すのは SKILL.md の本文(オーケストレーター)

エージェント定義は「誰が何を持つか」でしかありません。ループを回す手順は SKILL.md の本文に、フェーズごとに書きます(準備 → ゲート → 調査ループ → レポート)。オーケストレーターは Agent ツールに subagent_type を指定して各ロールを順に起動し、返ってきたテキストを状態ディレクトリへ保存し、停止条件を照合する——この簿記を繰り返すだけです。

運用して分かった急所は、呼び出しプロンプトに毎回必ず含めるものを SKILL.md に明文化しておくことです。

• 状態ディレクトリの絶対パスと、参照すべき証拠ファイルのパス
• 証拠IDの開始番号(state.json の next_evidence_ids から採番)
• 今回のイテレーションの「問い」
• そのロールに適用される予算値(取得件数・出力行数の上限)

サブエージェント同士は会話を共有しません。受け渡しはファイルと呼び出しプロンプトだけなので、ここを渡し忘れたロールは文脈なしで走り、精度が目に見えて落ちます。

3. サブエージェントは「読み取り専用ツール」だけ渡す

調査は完全読み取り専用が既定です。「書き込み禁止」と指示するのではなく、frontmatter の tools でそもそも渡さない。ロールごとの最小権限は前掲の折りたたみのとおりで、要点は3つです。

• Crashlytics 分析役には取得系(get_issue / list_events / get_report 等)だけを列挙し、note 追加・issue 更新・close 系は列挙しない
• code-mapper の Bash は、本文の指示で「読み取り git コマンド(log / show / blame / diff 等)のみ」に縛る
• ファイルを書くサブエージェントはゼロ。各ロールは成果物をテキスト(最終メッセージ)で返し、状態ディレクトリへの保存はすべてオーケストレーターが行う

「指示で禁止」は長い会話の中で破られることがありますが、「持っていないツール」は絶対に使えません。安全は指示ではなく構造で作ります。

4. 状態をリポジトリ外のファイルに外部化する

Loop Engineering の一丁目一番地。調査の正本は会話ではなくファイルです。チケット番号ごとにこういう構成を作ります。

~/…/crash-investigations/<チケット番号>/
  state.json              # 機械可読の調査状態(再開の正本)
  ticket.md               # チケットの事実(証拠 T#)
  crashlytics.it<N>.md    # Crashlytics 所見(証拠 C#)
  code-map.it<N>.md       # stack trace とコードの対応(証拠 M#)
  hypotheses.md           # 原因仮説の現在形
  falsification.it<N>.md  # 独立反証の結果(証拠 F#)
  loop-journal.md         # イテレーションごとの記録
  report.md               # 最終レポート

state.json には、現在のフェーズ・イテレーション番号・予算の消費量・次に割り当てる証拠ID番号・未解決の問いを持たせます。

{
  "status": "in_progress",
  "phase": "loop",
  "iteration": 2,
  "budgets": { "subagent_calls_max": 14, "subagent_calls_used": 7 },
  "next_evidence_ids": { "T": 14, "C": 15, "M": 62, "F": 26 },
  "open_questions": ["旧バージョンでの発生有無", "..."],
  "stop_reason": null
}

証拠ID([C12] [M4] のような通し番号)は地味ですが効きます。すべての仮説・レポートの主張に証拠IDを引用させ、IDのない主張は「推測」と明記させる。これで「それっぽいが裏取りのない結論」が構造的に排除できます。中断しても state.json から再開できるので、長い調査が途中で切れても続けられます。

5. 予算と停止条件を先に決める

暴走とトークン浪費を防ぐため、上限を先に決めておきます。

MAX_ITERATIONS        = 3    反復回数
SUBAGENT_CALLS_MAX    = 14   サブエージェント起動の合計
EVENTS_PER_ISSUE_MAX  = 5    代表イベント取得数
WALL_CLOCK_SOFT_MAX   = 30分  経過時間の目安

停止条件は「達成」だけでなく「打ち切り」も明文化します。

条件	レポートでの扱い
最有力仮説が反証を生存し、独立した2系統以上の証拠がある	確度=高
反復が上限に到達	現時点の最有力仮説と未解決の問いを明記
新しい証拠が出ないイテレーションが発生	「新証拠が得られないため停止」
権限・認証エラーが解消しない	何の権限が不足しているか明記
時間/呼び出し数の予算超過	打ち切りと明記

あわせて「確度」も気分で書かせず、先に定義しておきます(例: 高=反証を生存し、独立した2系統以上の証拠があり、主要な観測事実をすべて説明できる/中=反証は生存したが未説明の事実が残る/低=生存した仮説がない・打ち切り)。

「新証拠が出なければ止める」「予算を超えたら止めて、止めたと書く」——ここを最初に決めておくと、エージェントが"粘り続けて溶かす"事故が起きません。

6. 独立反証(maker/checker 分離)を仕込む

hypothesis-builder は仮説を作るだけ。falsifier は別コンテキストで、その仮説を壊しに行く専門役です。反証役のプロンプトには、こういう攻撃を最低限やらせます。

• 証拠の実在確認: 仮説が引用する証拠IDの原典(コードの該当行、集計値)を自分で再確認する(伝聞を信じない)
• 代替説明: 同じ観測を説明できる別の原因を最低1つ立て、どちらがデータと整合するか比べる
• 分布整合: 仮説が正しければ期待される分布(バージョン別・OS別・時系列)と、実測を突き合わせる
• メカニズム追跡: 因果連鎖をコード上で1ステップずつ辿り、飛躍がないか確認する

判定は仮説ごとに REFUTED / SURVIVES / NEEDS_EVIDENCE の3値。NEEDS_EVIDENCE(判定に証拠が足りない)は、そのまま**次のイテレーションの「問い」**になります。ここが「証拠不足の特定 → 追加調査」のループを回すエンジンです。

この2ロールの本文(システムプロンプト)を折りたたみで載せます。「作る者は自分の答案を確定させない」「壊す者は支持ではなく反証を目的にする」という役割の非対称性が、指示レベルで効いています。

【作る者】crash-rca-hypothesis-builder.md 本文

あなたは crash-rca 調査チームの「仮説作成」担当。証拠ファイルを読み、クラッシュの根本原因の
仮説を作成・更新する。あなたは仮説を「作る」係であり、検証は別エージェント(falsifier)が行う。
自分の仮説を自分で確定させない。

# 厳守事項
- ファイル書き込みはしない。最終メッセージが hypotheses.md の「全置換内容」として保存される。
- すべての主張に証拠 ID([T#][C#][M#][F#])を引用する。証拠のない着想は「推測」と明記し、
  確度を「低」にする。
- アクティブ仮説は最大 4 件。前回 REFUTED になった仮説は「却下済み」に移し、蒸し返さない
  (新証拠がある場合のみ復活可。復活理由と新証拠 ID を必須とする)。
- メカニズムの妥当性確認のためにリポジトリのコードを Read / Grep してよいが、5 ファイルまで。
  新しいデータ取得はしない。
- ステータスは proposed / supported / refuted のみ。confirmed は付けない
  (確定判定はオーケストレーターの停止条件評価で行う)。

# 良い仮説の条件
- 一文で主張でき、コード上のメカニズム(因果連鎖)を持つ
- 観測された事実(stack、バージョン / OS 分布、発生傾向、再現条件)を説明できる
- 反証可能である: falsifier が実行できる具体的な確認手段を提示できる

複数の観測事実を説明できる仮説を優先する。説明できない事実は隠さず
「説明できていない事実」に書く(そこが falsifier と次イテレーションの入口になる)。

# 出力フォーマット(このまま埋める)
## H<n>: <一文の主張>
- ステータス: proposed | supported | refuted
- 確度: 高 | 中 | 低
- メカニズム: <コード上の因果連鎖を 3〜6 行>
- 支持証拠: [C#][M#]...
- 説明できていない事実: ...(なければ「なし」)
- 反証テスト(falsifier への具体的な確認方法): ...

【壊す者】crash-rca-falsifier.md 本文

あなたは crash-rca 調査チームの「反証」担当。hypothesis-builder とは独立の立場で、各仮説を
「壊すこと」を目的に検証する。仮説を支持するための調査はしない。壊れなかった仮説だけが
SURVIVES になる。

# 厳守事項(読み取り専用)
- ファイル書き込みはしない。書き込み系ツール(note追加・issue更新・close)は持っていない。
- Bash は読み取り git コマンドのみ: git log / git show / git blame / git diff /
  git tag --contains / git branch --contains / git rev-parse。それ以外は使わない。
- 追加クエリは合計で予算回数(既定 4 回)まで。
  クラッシュ基盤の App ID: 1:000000000000:ios:xxxxxxxxxxxxxxxx(project: your-project)。
- 既知の API 制約: 期間指定は過去 90 日未満でないと拒否される。特定パラメータの併用は
  エラーになるため禁止(クエリ予算の浪費になる)。

# 各仮説への攻撃(最低 a〜d を実施)
a. 証拠実在チェック: 仮説が引用する証拠 ID の原典(コードの該当行、集計の数値)を
   自分で再確認する。コードは自分で Read / Grep して確かめる(伝聞を信じない)。
   引用が原典と食い違えば REFUTED 候補。
b. 代替説明: 同じ観測を説明できる別原因を最低 1 つ立て、どちらがデータと整合するか比較する。
c. 分布整合: 仮説が正しい場合に期待されるバージョン / OS / 端末 / 時系列の分布と、
   実測の分布 [C#] を突き合わせる。矛盾があれば指摘する。
d. メカニズム追跡: 因果連鎖をコード上で 1 ステップずつたどり、飛躍(実際には起こらない
   遷移・成立しない前提)がないか確認する。
e. (必要時)追加クエリ: 仮説を判別できるデータを予算内で取得する。

# verdict の基準
- REFUTED: 決定的な反例・矛盾がある(根拠を [F#] で示す)
- SURVIVES: a〜d を通過し、反例が見つからない(残る弱点も必ず記録する)
- NEEDS_EVIDENCE: 判定に必要な証拠が不足。何がどう取得できれば判定できるかを具体的に書く
  (これが次イテレーションの問いになる)

実際に動かして起きたこと ― 結論が2回覆った

この設計の一番の価値は、「もっともらしいが間違った結論」を自分で覆せることです。実案件で回したときの流れを、手法の観点だけに絞って要約します(対象の技術的詳細は伏せます)。

1周目 … 反証をくぐり抜けて最有力になった仮説がありました(確度は「中」)。ここで止めていたら、その結論をそのままレポートに書いていたはずです。おまけに反証役が横から、本来の調査対象の"外側"にある見落とし(監視の盲点)まで拾ってきました。これも maker/checker 分離の副産物です。

2周目 … より生に近い追加証拠を投入しました。すると反証役が、1周目の最有力仮説の大前提が成り立たないことを実証してしまいました。そこで仮説を作り直し、より少ない仮定で同じ観測を説明できる別の仮説へ改訂。1周目の結論は棄却されました。

何が効いたか

• 状態をファイルに外部化していたので、2周目は1周目の証拠(証拠ID付き)の上にそのまま積めた。会話が飛んでも土台が残る。
• 作る者と壊す者が別なので、1周目の"もっともらしい結論"に、別コンテキストが遠慮なく反例をぶつけられた。
• 予算で各周を打ち切り、「未確認事項」を正直に残して次周へ渡せた。

結論そのものより、最初の結論を後から出た証拠で構造的に覆せたことがこの設計の価値です。1エージェントに一気通貫でやらせていたら、たぶん1周目の結論のまま、自信満々のレポートが出ていました。

ハマりどころ / 実装Tips(一般化)

実際に組んで回して得た、転用できそうな知見です。

• サブエージェントへのMCPツール継承は環境依存。カスタムサブエージェントに MCP ツールが渡らないことがある。フォールバック(オーケストレーターが最小限だけ取得して、分析専用モードで再委譲)を用意しておくと事故りにくい。
• サブエージェントにレポートを直接ファイル書きさせない設計もあり得る。私の環境ではサブエージェントによる成果物ファイルの書き込みが制限されたため、reporter は「本文をテキストで返す」だけにして、保存はオーケストレーターの責務に寄せた。
• サブエージェントの最終メッセージが長すぎると先頭が欠落することがある。レポート役には出力の行数上限(例: 400行)を目安として持たせ、網羅一覧は本文に貼らずファイル参照にする。
• ロールに必要なツールを渡し忘れると、そのロールは仕事を"できない"と正直に返す(推測で埋めない設計にしておけば、ここで気づける)。今回は「ローカルファイルを探索する役」に探索系ツールを渡し忘れていて、別ロールに再委譲して解決した。「できませんでした」と正直に返る設計は、こういう抜けを早期に可視化してくれる。
• 外部APIの癖はスキル定義に"禁止事項"として書き残す。集計APIのパラメータの組み合わせで400が返る、期間指定に制約がある、といった落とし穴は、エージェント定義に明記しておくとクエリ予算の無駄打ちが減る。

まとめ:設計 > プロンプト

やったことを一枚にまとめます。

• 調査を ゲート → データ取得 → コード照合 → 仮説 → 独立反証 → 証拠不足の特定 → (追加調査) → レポート という閉じたループにした
• 状態をリポジトリ外のファイルに外部化し、会話が飛んでも積み上がるようにした
• 作る者(仮説)と壊す者(反証)を別エージェントに分け、「完了」を主張から検証に変えた
• 予算と停止条件を先に決め、暴走とトークン浪費を止め、打ち切りを正直に書かせた
• オーケストレーターは簿記に徹し、知能とコストは検証役に寄せた

冒頭に挙げた"自壊"——忘れる・自分の仮説に甘い・止まらない——は、それぞれ状態の外部化・独立反証・予算と停止条件が受け持って潰した、と言い換えられます。

Loop Engineering の記事にある通り、「同じループを2人が組んでも、正反対の結果になる」。深く理解している作業を速くやるために使う人と、理解を避けるために使う人がいて、ループはその違いを知らない。知っているのは自分だけです。

だからこの手のループを組むときは、「押せば動くだけの人」ではなく「エンジニアであり続けるつもりの人」として組むのが結局いちばん効きます。最後に結論を確認するのは、いつも自分です。

この記事のエージェント定義・状態管理・レポート形式は、特定の会社・プロダクト・SDKに依存しない形に一般化して記載しています。

---

このシリーズの歩き方

Claude Code実務運用シリーズ ― 暴走させない、から仕組みにするまで。

• ◀ 前の記事: 会社のURLを渡すと7つのエージェントが「ブラック企業リスク」を推定する — Claude Codeで作った分析チームの設計
• ▶ 次の記事: 【第1弾】【初心者向け】Claude CodeにPlaywrightプラグインを入れる方法
• 🔍 あわせて読む: ループエンジニアリングでClaude Codeを実務に：Redmineチケット駆動開発のQA・開発・レビュー・統括エージェント設計 ― 開発を任せるループとの対比
• 🗺 シリーズ全記事の地図(親記事)