- 「同じClaude Codeに頼んでいるのに、なぜ結果が変わるのか」
- 役割を与えるとは何か——最小の定義
- writer + reviewer を分けて起きたこと
- 「指示を出してから初稿が上がるまで7〜8分」という体感
- 「役割の実装」はテキストファイル一つ
- なぜ「2体から始める」のが正解なのか
- 「道具」と「チーム」の違い
- Claude Code エージェントチームを始めるための次の一歩
- 関連記事
この記事の概要（2026年5月）: Claude Codeの同一AIモデルに「writer」と「reviewer」という役割を与えることで品質と速度がどう変わったかを記録した実践レポート。コードを書かずテキストファイル一つで役割を定義できる仕組みと、9体構成AIチームの起点となった2体構成の設計思想を解説する。Zenn Book Vol.1「コードを書けない私がClaude Codeで『AIチーム』を作るまで」の第2部をもとに構成。
「同じClaude Codeに頼んでいるのに、なぜ結果が変わるのか」
AIに記事を書かせるとき、こんな経験はないだろうか。
「この記事を書いて、確認もして」と一つのAIに頼む。できた文章を読み返すと、なんとなく甘い。「もう少し厳しく確認してほしい」とリクエストしても、大きくは変わらない。
原因は構造にある。書いた本人が同じ文脈の中で確認するという作業に、本質的な限界がある。
私がClaude Codeで試したのは、これを分解することだった。「書く役割」と「確認する役割」を別々に定義し、同じAIモデルに渡す。それだけで、返ってくるアウトプットが変わった。
本記事では、この「役割を与える」という発想が実際に何をもたらすのかを、自分の体験をもとに記録する。Vol.1の第2部「AIに役割を持たせるという発想転換」を素材に、ブログ記事として独立して読める形に再構成した内容だ。
役割を与えるとは何か——最小の定義
「役割を与える」という言葉は、大げさに聞こえるかもしれない。実際には単純な話だ。
AIへの前提を、こう変える。
あなたはプロのライターです。 読者に伝わる記事を書くことを最優先にしてください。 内容の正確さよりも、読みやすさと論理の流れを重視します。
そして別の会話（または別のエージェント）に、こう渡す。
あなたはファクトチェックを担うレビュアーです。 提出された記事の事実確認を厳密に行い、 数値の根拠が曖昧なもの、主張の飛躍があるもの、出典が不明確なものを指摘してください。 読みやすさより正確さを優先します。
これだけだ。別々のAIアカウントが必要なわけではない。特別なAPIも不要。同じClaude Codeに、観点の前提を変えて渡す。
「ライターとして書く」という前提を持ったAIは、「読みやすさ」「論理の流れ」「読者の引き込み」に注意を向けながら出力する。「レビュアーとして確認する」という前提を持ったAIは、「正確さ」「根拠の有無」「論理の飛躍」に注意を向ける。
同じ文章を、同じモデルが読んでいる。でも「どこを重視するか」が変わる。これが、役割を与えることの仕組みだ。
writer + reviewer を分けて起きたこと
この発想を実際に試したのは、記事を書くwriterと、確認するreviewerを2体構成にしたときだ。
それまでは一つのAIに「書いて、確認もして」と頼んでいた。当然、「書いた文脈の中でチェックする」という構造になり、書いたときの思い込みや見落としがそのまま出力に残った。
二体に分けた途端、状況が変わった。
reviewerはwriterが書いた文章を、「書いていない立場」から読む。前提を知らない読者の視点に近い。「この記述は根拠が薄い」「ここの論理がつながっていない」という指摘が、書いたときには気づかなかった粒度で出てくるようになった。
具体的に言うと、私の場合、reviewerが1記事あたり重要度の高い指摘を3〜5件出してくる。同じ原稿を自分一人で確認したときは、そのうち1〜2件しか気づけなかったこともある（体感値。記事の長さや内容によって変わる）。
「書いた人間が自分でチェックする」構造の限界は、数字で見ると明確になる。
「指示を出してから初稿が上がるまで7〜8分」という体感
役割を分けた分業体制で気づいた変化がもう一つある。
「指示を出してから初稿が上がるまでの時間が、7〜8分程度になった」
これは体感値であり、記事の長さや指示文の精度によって大きく変わる。再現を保証するものではない。ただ、一体体制のときと比べて感覚が変わったのは確かだ。
一体体制では、一つのAIに「記事を書いて」と頼み、画面を眺めながら待っていた。出てきたものを読んで、修正点を指示して、また待つ。この往復に相当の時間がかかっていた。
分業体制では、自分の手を離れた後にAIが動き続ける。researcherが素材を集め、writerが構成を考えながら書き、reviewerが確認する——この連鎖を「始めてください」の一言で走らせることができる。
自分は途中で他の作業をしていられる。最後に成果物を確認するだけだ。
「指示を出して待つ」から「指示を出して離れて、戻ってきたら成果物がある」への移行。この体験は、一体体制では得られなかった。
もう少し具体的な話をする。本書のたたき台になった初期原稿を作るとき、「テーマと構成案を渡すから、全11章のドラフトを作ってほしい」という指示を出した。私が発言した回数は、確認・返答を含めてその夜で15回程度。「次」「はい」「１」という一言返答が大半だった。翌朝には全11章のドラフトが上がっていた。AIの出力は約2,000行だった（自己計測。その原稿は後にボツになったが、本書はそこから生まれている）。
自分が15回Enterキーを押す間に、AIが2,000行を書いた。
「役割の実装」はテキストファイル一つ
「仕組みは分かったけど、実際にどうやるの？」という疑問があるはずだ。
実装は驚くほどシンプルだ。テキストファイルを一つ作るだけ。
# writerエージェント あなたは記事執筆を担うwriterです。 ## 担当業務 - 記事・文章の執筆 - ドラフト作成 ## 行動指針 - 読者にとって読みやすい文章を最優先にする - 事実の確認はreviewerに任せる - 一文の長さは短くまとめる
このファイルをClaude Codeに読み込ませることで、「自分はwriterである」という前提でAIが動き始める。reviewer用のファイルにはreviewerの役割を書く。researcherにはresearcherの役割を書く。それだけだ。
コードを書く必要はない。テキストを書くだけ。これが「コードを書けない自分でも始められる」理由でもある。
役割ファイルが増えれば、観点も増える。writer・reviewer・researcherと役割が分かれるほど、「誰が何に注意を向けるか」が明確になり、成果物に込められる観点が分化していく。
なぜ「2体から始める」のが正解なのか
私が現在運用しているのは9体構成のAIチームだ。COO・researcher・writer・reviewer・reader・secretary・devopsなど、それぞれが役割を持って動いている。
ただし、「最初から9体を揃えた」わけではない。最初の2日間は、writerとreviewerの2体だけだった。それで十分機能していた。記事が書けて、確認が取れて、公開できる。
researcherを追加したのは「調査に時間がかかる」という問題が出てきてからだ。secretaryを追加したのは「タスク管理が追いつかなくなってきた」から。devチームを追加したのは「スクリプトの開発が必要になった」から。問題が出るたびに「この問題を担当するエージェントが必要だ」と判断して追加した。その積み重ねが9体だ。
逆に言えば、「2体から始めて、必要になったら増やす」が現実的なアプローチだ。
最初から9体を抱えると管理の複雑さも一緒についてくる。ルールが重複する。役割の境界があいまいになる。「どのエージェントに頼むべきか」の判断が増える。AIの組織も、人間の組織と同じ問題を抱える。
実際、私自身が複数エージェントを2ヶ月運用してきた体感として、こういった問題が具体的に表面化する。役割定義ファイルがエージェントごとに散在して最新版がどれか分からなくなる。COOへの依頼順序が乱れて、前工程の成果物を待たずに後工程が走る。同じ確認作業をreviewerとreaderの両方が担っていて、指摘が重複する。これらは組織規模に比例して起きやすくなる。「チームをどう回すか」という問いは、「チームをどう作るか」とは別の難しさがある。このテーマはVol.2で正面から扱っている。
まず2体で「動いた」という体験をする。それが続けるための一番の動機になる。
「道具」と「チーム」の違い
最後に、もう一つの視点を加えておく。
多くの人がAIを「道具として」使っている。必要なときに取り出して、終わったらしまう。「AIに聞いてみよう」という使い方だ。これは悪い使い方ではない。私もそこから始めた。
「道具としてのAI」と「チームとしてのAI」の違いは、継続性と文脈の共有にある。
道具としてのAIは、毎回ゼロから始まる。前回の会話は引き継がれない。「この仕事は自分が担当だ」という認識もない。
チームとしてのAIは、役割を持った状態で動き続ける。「自分はreviewerだ」という前提を持って同じプロジェクトに関わり続ける。だから品質が安定し、成果物が一貫性を持つ。
「道具」から「チーム」への移行が、私が試してきたことの本質だ。
そのための最初の一歩が、writerとreviewerの2体構成だった。役割を定義して、分業させて、成果物を確認する。このサイクルを一度でも体験すると、「AIを一つ使う」という発想に戻りにくくなる。
Claude Code エージェントチームを始めるための次の一歩
この記事で触れたのは、Vol.1の第2部「AIに役割を持たせるという発想転換」のエッセンスだ。
Vol.1では、9体全員の役割マッピング（第2部、無料公開）、ゼロから環境を準備してwriter + reviewerの2体を動かすまでの手順（第3部）、役割を追加するかの判断基準と運用フロー（第4部）、失敗と事故の記録（第5部）も収録している。「動かせそう」と感じた方は、続きは本書で確認してほしい。
Zenn Book「コードを書けない私がClaude Codeで「AIチーム」を作るまで」（Vol.1、900円）
AIチームの立ち上げから最小構成の実装まで、コードを書かずに進めた記録を一冊にまとめている。本書の序章と第1部は無料で読める。
なお、Vol.1で作ったチームを「どう回すか」を扱う続編Vol.2は、現在進行中だ。
