ClaudeとChatGPTでチームを組む｜役割分担と、受け渡しの作り方

ひとつのnote記事を作成するにあたり、ClaudeとChatGPTで分担しています。
下書き係、清書係、検査係、書式やキットを作る係、調査の係、ヘッダー画像係、そして秘書。

最初からこの形だったわけではなく、ひとつの会話に全部を詰め込んでいたところから、少しずつ切り分けて、受け渡しの道を作って、点検の役を置いて、いまの形になりました。
途中で何度もつまずいていますが、そのたびに直し方を変え改良を重ね、いまは止まらずに回っています。

仕上がりまでの速さははっきりと変わって、原稿が書かれているあいだに別の係が公開済みの記事を点検し、さらに別の係が次の題材を集めるようになりました。
前はこれが順番待ちで、1本仕上がるまでほかの作業が動きませんでした。

もう1点、会話が長くなって扱いきれなくなっても、その係を新しい会話にして担当のフォルダとルールのファイルを渡せば、続きから動くようになりました。
覚えているかどうかに頼らず、フォルダの中のファイルに書いてあるからです。

ただし、全部を自動では動かしていません。
記事を書きはじめるのも点検に回すのも、きっかけは毎回こちらが出していて、これは手が回っていないからではなく、そういう形にしているからです。

根拠と更新について

ここに書く出来事は、すべて手元の記録に日付まで残っているもので、記録に無いものは書いていません。
係の名前は、出来事があった時点の呼び方ではなく、いまの呼び方にそろえています。
この内容は、仕組みが変わったときに更新します。

いまの分担

使っているのはClaude Coworkで、うちでは会話ごとに担当のフォルダを決め、役割で切ってから同じフォルダを共有させました。

分担は3層になっていて、制作・調査・検査に分かれています。

制作側には、下書き係、それをnoteの形にする清書係、有料noteの清書も受け持つ書式やキットを作る係、ヘッダー画像係がいます。
調査側には、広く当たって候補を並べる係と、一点に絞って掘る係がいて、どちらも記事そのものは書きません。
検査側には検査係と秘書がいて、検査係は清書係が作ったものを点検して通すか差し戻すかを決め、公開したあとの手当ても受け持ちます。
秘書は、ほかの係が出した資料どうしの食い違いを見て、ルールの文面も受け持ちます。
どちらも記事は作りません。

ここが大事なところですが、全員がClaudeではありません。

調査側の一方と、ヘッダー画像係はChatGPTです。
チームの親フォルダの中には、Claudeのフォルダと、ChatGPTのフォルダが並んでいます。
おたがいのフォルダの中のファイルは読むことができますが、相手のフォルダのファイルに書き込むこと、消すこと、ファイルそのものを削除することは禁止しています。
例外は、係どうしの連絡に使う連絡板という1枚のファイルだけで、ここだけは、どちらのAIのどの係も読んで、書き足すことができます。
この決めごとが、そのまま受け渡しの形になりました。

受け渡しのしくみ

フォルダを共有している相手どうしでも、おたがいの会話は見えません。
下書き係が決めたことは清書係の側には存在しませんし、清書係が気づいたことも書式やキットを作る係には届きません。
「前にそう決めたはずだ」が、片方の会話の中だけの事実になります。

そこで、係から係へ渡すときは、用件が1件動くたびに連絡板へ1行足すことにしました。
列は、日付、出した係、宛先、用件、関係するファイル、処理したかどうかの6項目だけです。

ChatGPT側との受け渡しも、この連絡板で回しています。
相手のフォルダには書き込めないので、頼みたいことの中身は自分のフォルダにファイルとして置き、連絡板には、宛先と、そのファイルの場所を書いた1行を足します。
受け取った側はその1行を見て、書いてある場所のファイルを読みに行きます。
読むことはおたがいにできるので、中身は出した側のフォルダに置いたままで届きます。
済んだら、受け取った側が自分あての行の状態を書き換えて閉じます。
ChatGPTとは、この1行でつながっています。
両方が書き込めるのは連絡板だけで、そこに足す1行が、相手のフォルダにある中身の場所を指しているからです。

そして、連絡板は放っておいても読まれず、係は言われたときに読みに行きます。
受け渡しが始まるきっかけも、こちらが出しています。

自動化を勧める話は多いけれど、採っていません

AIの運用を全部つなげて自動で回す、という話をよく見かけますが、採用していませんし、人にも勧めていません。
理由は3点あります。

1点目は、ハルシネーションが出たときに、その都度どう直すかを自分の目で見たいからです。
自動で流すと、誤りが誤りのまま次の工程へ渡ります。
実際、有料noteを清書している書式やキットを作る係も、記録に無い出来事を本文に入れたことがあって、点検も通りました。
止めたのは、読んだ人間です。

2点目は、やり方とルールを軽く変えられるようにしておきたいからです。
これまでに係の分け方も点検の手順も受け渡しの形も変えていますが、手で起動する形だったので、変えるのが軽くて済んでいます。
自動で固めるほど、変えるのは重くなります。

3点目は、自動だと速さが裏目に出るからです。
ルールに一文足しただけで、37本のファイルに1,639か所の書き換えが入りました。
正しい指示なら速いのはいいことですが、誤った一文でも同じ速さで広がります。
人が起点を持っていれば、広がる前に一度止まります。

自動で回したいなら、Claude Codeを採用します。
プログラムを置いてある場所の中で、手順をつないで動かせます。
使っていないのは、こちらが触るのがプログラムではなく、ふだんのパソコンのフォルダに入っているファイルで、最後はブラウザを開いてnoteに貼るからです。
何の話を書くかではなく、何を触る仕事かで、使うものが決まります。

つまずいたのは、いつも受け渡しのところ

ここに書く4件は、どれも記事そのものではなく、その手前で起きています。
食い違ったのは、記事を作るために係が読む資料のほうです。
進み具合を書いたメモ、係ごとのルール、noteに貼る前の原稿の控え。
どれも複数の係が読み書きするもので、つまずいた場所は決まって、係から係へ手渡すところでした。
起きた順に4件あって、どれも、そのあと直しています。

朝に直した7か所が、昼に消えた

ひとつのファイルを2人が同時に開いていて、あとから保存した人の内容だけが残る。
これと同じことが、AIの係どうしで起きました。

舞台は、進み具合を書いたメモです。
どの記事を公開したか、次に何を書くかが書いてあり、係から係へ作業を引き継ぐときの土台になっています。

2026年9月8日の朝6時58分、秘書がこのメモを7か所直しました。
公開した記事を「公開済み」にして、書き上がった原稿5本を在庫に足す、といった直しです。

同じ日の11時45分、清書係が同じメモを保存しました。
清書係がメモを読み込んだのは、秘書が直すより前です。
その古い中身に自分の作業の分を書き足して、ファイルを丸ごと保存したので、秘書の7か所は上書きされて消えました。

どちらの係も、手を抜いたわけではなく、それぞれの作業は正しく終わっています。
清書係は、自分が何かを消したことに気づかないままです。
秘書のほうも、気づけるのは、もう一度そのメモを開いたときです。
分かったのは12時21分で、別の用事でメモを開いたときでした。

最初の手当ては、書き込む前にファイルを読み直す、という決まりでした。
けれど注意に頼る決まりは、いずれ抜けます。
10月2日、係どうしの連絡板で、検査係が書き足した5行が同じ形で消えました。

止まったのは、連絡板の作りを変えてからです。
それまで連絡の表はファイルの途中にあって、1行足すにはファイル全体を読み込み、丸ごと書き戻す必要がありました。
表をファイルのいちばん下に移すと、新しい行は末尾に足すだけで済み、ほかの行はそのまま残ります。
回覧板の最後に1行書き足すのと同じで、前のページを書き写す必要がなくなりました。

一文を足したら、37本のファイルが書き換わった

AIの係は、ルールに書いてあることを、そのとおりに実行します。
書いてあれば、誰が足した一文でも同じです。

2026年9月9日、こちらから出した指示は「改行は遡ってやりたい」「それぞれの係にまかせます」というものでした。
すでに公開した記事にも、文の終わりの「。」ごとに改行を入れる、見た目の直しです。

秘書はこれをルールに書き起こすとき、公開ページと手元の原稿の控えの両方に入れる、という一文を足しました。
控えに入れることは、こちらが言っていない中身でした。

それを読んだ書式やキットを作る係は、ルールのとおりに、受け持ちの控え37本に1,639か所の改行を入れました。
この係は、ルールのとおりに動いただけです。
一方、清書係はこちらから、控えには入れないと直接聞いていたので、自分の受け持ちの控えはそのままにしています。
同じ日のうちに、係によって控えの形が食い違いました。

助かったのは、ファイルを変える前に、元の版を日付付きで別の場所へ移しておく決まりがあったことです。
37本とも元の版に戻し、1文字も違わない状態まで戻っています。

この件のあと、全員が読むルールの冒頭に「指示されていないことをしない」を置きました。
読む側には、書いてある一文がこちらの指示なのか、書いた係の思いつきなのか、見分けがつかないからです。

公開したページだけを直して、手元が古いまま残った

記事は、手元にある原稿の控えから、noteの編集画面に貼って出しています。
公開したあとで直したくなったときは、noteの画面で直接直すこともあります。

2026年9月10日、公開済みの37本について、手元の控えとnoteのページを突き合わせたところ、29本で中身が食い違っていました。
冒頭の決まった言い回しをそろえた直しや、あとから足した関連記事への案内、言い回しの手直しが、noteのページにだけ入っていて、控えに戻っていなかったのです。

これだけなら、読む人に見えるnoteのページは正しいままです。
困るのは次に控えから貼り直したときで、noteの画面で直したはずのものが、古い中身で上書きされて元に戻ります。
印刷した書類を赤ペンで直して、元のデータを直し忘れたのと同じ形です。

そこで、何かを直すときは、同じことがどこに書いてあるかを先に数えて、全部を直すことにしました。
9月14日に、ある記事の末尾から有料記事への案内の段落を1か所外したときは、noteのページ、手元の控え、その記事の作業記録、どの記事に案内を置いたかの一覧の4か所を直しています。
直す前と後で文字数と、ページを組み立てている要素（段落、見出し、画像、区切り線など）の数も数え、減ったのがその1段落だけであることを数字で見られるようにしました。

渡したのに、届かなかった

2026年9月12日、清書係から下書き係へ「次はこの題材で書いてはどうか」という提案を、決まった場所にファイルで置ける道ができました。

その日、下書き係あての提案が1件、一度も開かれないまま残っていました。
置く場所も書き方も決まっていたのに、置いたことを知らせる手段は、こちらが口で伝えることだけでした。
受け取る側の手順にも、そのフォルダを見に行く段は無かったのです。
いまは、下書き係が作業を始める前に確かめることの中に、そのフォルダを見る項目が入っています。

同じことは、ChatGPT側でも起きています。
ChatGPTの係は、見出し画像を作っています。
9月24日、ガジェット紹介の記事は金曜20時に公開すると決まり、見出し画像に通し番号を入れることも決まりました。
どちらも画像の枚数と中身が変わる話なのに、ChatGPT側への連絡は、1行も出ていない状態でした。
前の日にも、ChatGPTにも伝えたのかとこちらから聞いていて、これで2度目です。

伝える役の秘書が落とした理由は、こうです。
変更を頼んできたのはClaudeの係だったので、返事もその係に返して、そこで終わりにしていました。
ChatGPTの係は、そのやり取りの外にいました。

出てこない相手こそ、こちらから見に行く必要があります。
いまは秘書の手順に、ルールを1か所直すたびに、ChatGPT側の作るものが変わるかを確かめる段が入っています。

直し方には、効く形と効かない形がある

4件とも起きたあとに手当てをしましたが、そのうちいくつかは同じ形で戻ってきました。

分かったのは、文章で決まりを足すと戻ってくる、ということです。
止まったのは形を変えたときだけで、上書きできない置き方にしたのは10月3日、題名の点検を機械に移したのは10月6日です。
どちらも、2026年10月7日の時点で同じ形はまだ出ていません。

この仕組みは、記事づくりだけのものではありません

ここまでは記事を作る話でしたが、中身は記事に限りません。

作る人がいて、調べる人がいて、できたものを見る人がいて、決めたことを次の人に渡す。
同じ資料が2か所にある。
どれも、見積りでも報告書でも調査でも、同じ形で出てきます。

実際、ここで決めたことのほとんどは題材が何かに関係がなく、誰が作って誰が見るか、どこで渡すか、何を機械に数えさせるか、どこで人が止めるか、この4点だけです。

ここから先は、その4点の決め方です。

分担の切り方と、公開の前と後で線を引いた理由。
分けた全員を束ねている1枚に、何を書いて何を書かないか。
受け渡しの1行の作り方と、書き込めない相手のフォルダへの渡し方。
差し戻しの書き方と、直したことを数値で確かめるやり方。
効いた直し方と、効かなかった直し方の分かれ目。
人が起点を持っている場所を、どこに置いてどこに置かなかったか。
そして、いまも修正できていないもの。