1人で抱えるから、詰まる｜グラフエンジニアリング

AIに大きい仕事を丸ごと頼んで、途中でぐちゃぐちゃになったことないか。長い記事を書かせたら後半で話がずれる、資料一式を任せたら途中で抜け漏れが出る。それ、AIの実力不足やない。1人に全部やらせてるだけや。今日は、誰に何を任せるかを決めて分ける考え方を渡すで。

結論：1人に全部やらせへん。分けて、最後に束ねる

先に答えを言うとく。大きい仕事が途中で崩れるのは、1つのチャットに調べることも書くことも確認することも、全部乗せてしまっているからや。**役割ごとにチャットを分けて、最後に1人が束ねる。**これだけで、崩れ方がまるで変わる。

やることは大げさやない。今1つのチャットでやっていることを、2つに割るだけです。調べる係と、書く係。これだけでも、途中で話がずれる感覚がかなり減ります。

これは新しい技術の話やなくて、仕事の分け方の話や。1人に全部押しつけたら、途中でどこかがおろそかになる。誰かと分担して、最後に1人が全体を見て整える。人間の仕事でも当たり前にやっていることを、AIとのやりとりにそのまま持ち込むだけの話やで。

この記事では、なぜ分けると速くなるのか、上位モデルと下位モデルをどう使い分けるとお金の面でも得なのか、そして分けたあとに必ず要る「束ねる工程」まで、順番に渡していくで。

この記事で分かること

• 大きい仕事が途中で崩れる原因が、1人に全部やらせていることだと分かる
• 分けると速くなる理由が、「順番待ちが消えるから」だと具体的に分かる
• 上位モデルと下位モデルの使い分け方と、分けるほど増える教育コスト（トークン）の両方が分かる
• 今日、1つのチャットを2つに割る具体的なやり方が分かる

5つのうち、いまはこの話

AIとの付き合い方には、5つの考え方がある。前回までで、頼み方（プロンプト）、渡す資料（コンテキスト）、机や道具（ハーネス）、出す前の確認（ループ）と来た。今回はその5つ目、グラフの話や。

グラフは、誰に何を任せるかを決める話。プロンプトで頼み方を固め、コンテキストで資料を渡し、ハーネスで道具を揃え、ループで確認する。この4つは、ここまで全部「1人のAI社員」の中で完結してきました。今回だけは違う。1人でやりきれない大きさの仕事に出会ったとき、初めて必要になる考え方です。

だから、この5つ目はいちばん最後に置いた。小さい仕事なら、プロンプトとコンテキストだけで十分片づく。分ける必要が出てくるのは、1人のAI社員に任せる範囲そのものが大きすぎるときだけや。ここまで4つの考え方を積み上げてきた人にとって、この記事はいちばん腹落ちしやすい回になると思う。5つが、この回でようやく1枚の地図としてつながる。

前回、もう2人でやってました

前回、ループエンジニアリングの話をした。自分が書いたものを、自分でそのまま出さずに、採点役の別チャットに見てもらう。「見てから出す」という工程を作った回や。

思い出してみてほしい。あのとき、すでに2人でやっていたことに気づいたやろか。**書く係と、採点する係。**それぞれ別のチャットで動かしていたなら、それはもう分担です。難しそうな名前がついているだけで、やっていたことはすでに始まっていた。

グラフエンジニアリングと聞くと、複雑な仕組みを組む話に聞こえるかもしれへん。せやけど中身は、前回すでにやっていたことの延長にすぎひん。書く係と採点する係の2人がいたところに、もう1人か2人増える。それだけの話や。新しい技術やなくて、すでにやっていたことに名前がついただけだと思ってもらえたら、この先の話がすっと入ってくるはずやで。

1人で全部やる人が、いちばん遅い

会社で、1人の人間に「調査も執筆も校正もデザインも全部お願い」と頼んだらどうなるか。想像してみてほしい。その人は優秀でも、全部を順番にこなすしかない。調査に3日、執筆に2日、校正に1日、デザインに1日。合計7日かかる。

これがチームなら違う動き方ができる。調査担当が動いている間に、過去の似た案件の資料をデザイン担当が探し始められる。執筆担当は、調査の途中経過が見え始めた時点で、確定している部分から書き出せる。リーダーが役割を割り振り、それぞれが自分の持ち場を進める。

AIも同じや。1つのチャットに、調べることも書くことも確認することも全部背負わせると、そのチャットは順番にしか動けへん。調べ終わるまで書けず、書き終わるまで確認できず、確認が終わるまで次に進めない。1人で全部抱える体制は、人間でもAIでも、いちばん遅い体制になる。

ここで大事なのは、分担そのものが目的やないということです。目的は、それぞれの作業に集中させること。調べる係には調べることだけを、書く係には書くことだけを渡す。1つのチャットにやることを詰め込みすぎないというだけの話が、結果として速さにも質にもつながっていく。

もう1つ、1人で全部やらせたときに起きがちな失敗がある。途中で目的を見失うことや。調べながら書いて、書きながらまた調べ直して、確認もその場でやろうとすると、チャット1本の中で話がどんどん長くなる。長くなった会話の中で、AIは最初に何を頼まれたかをだんだん見失っていく。人間でも、電話をしながらメモを取り、同時に別の作業もこなそうとすると、どれも中途半端になるやろ。あれと同じことがAIにも起きているだけや。

長いスレッドほど、AIは「バカ」になっていく

さっきの「途中で目的を見失う」、これは感覚の話やのうて、実際に確認されてる現象や。名前もついとる。「コンテキスト・ロット」、直訳すると「文脈の劣化」や。

海外のAI研究チームが2025年7月に、18種類のAIモデルを対象にした検証結果を公開した。結論はシンプルで、**入力が長くなるほど、AIの回答の信頼性は下がっていく。**同じ情報を渡していても、会話が短いときと長いときとでは、正しく拾える確率そのものが変わってしまうんや。

スタンフォード大学の別の研究では、もっと具体的な数字が出とる。長い文章の「真ん中あたり」に置いた情報を、AIがどれだけ正しく拾えるかを調べたところ、文章の最初や最後に置いた場合は70〜75%正解できたのに、真ん中に置いた場合は55〜60%まで落ちた。情報が間違ってるわけでも、消えてるわけでもない。ただ、AIがそこまで手を伸ばしきれてへんだけなんや。

うちらが普段感じとる「なんかこのチャット、急に頭悪なった気がする」は、これの体感版やと思ってくれたらええ。会話が長くなると、AIサービスの側で古いやりとりを自動でまとめ直す仕組みが動くこともある。まとめ直す過程で、細かいニュアンスがそぎ落とされる。会話が伸びるほど、AIが覚えとかなあかん量そのものも増える。どっちの理由にせよ、結果として「さっき言うたことを忘れる」「見当違いの答えが増える」という形で表に出てくる。

これは、この記事でここまで話してきた「1人に全部やらせると詰まる」という話と、根っこが同じや。**1つのチャットを長く伸ばして粘るという選択そのものが、AIの精度を自分から下げにいっているようなもんなんや。**役割ごとにチャットを分けると、それぞれの会話は短く保たれる。速くなるだけやのうて、**AIが賢いままでいてくれる時間も長くなる。**これが、分けることのもう1つの効き目や。

もう一つ付け加えとくと、これは「チャット」という形そのものの限界でもある。日常のやりとりならチャットで十分やけど、本当に大きい仕事——1つの会話にファイルを何十個も読ませて、何時間もかけて進めるような仕事——になってくると、チャットを人力で分けて回すだけでは、そろそろ限界が来る。そういう場面まで来たら、Claude CodeやCodexのような**「AIエージェント」**に切り替えることも、選択肢に入れておいてほしい。AIエージェントの多くは、必要な作業ごとに新しいサブエージェントを立ち上げる仕組みを持っとる。サブエージェントは、それぞれ独立した短い会話として動くから、今説明した「長引くほど劣化する」問題そのものが起きにくい。分けるという発想を、チャットの中で人力でやるか、AIエージェントの仕組みに任せるか。仕事が大きくなるほど、後者に頼ったほうが楽になる。

分けると、なぜ速くなるんか

「並列で動くから速い」とだけ言われても、実感が湧かへんと思う。もっと具体的に説明するで。速くなる本当の理由は、順番待ちが消えるからや。

わしがLPを自動で作るツールを動かしているとき、これを実際に経験した。1つのAIに、構成づくりも画像生成も丸ごと任せていた時期がある。このやり方やと、構成が完全に固まるまで、画像生成はいっさい始まらへん。構成に3分かかったら、画像はその3分が終わってから、また一から動き出す。待っている時間が、まるまる無駄になっとった。

これを、構成担当と画像担当を分ける形に変えた。構成が固まり始めた時点、つまり「トップ画像はこういう雰囲気で」という方向性が見えた瞬間に、画像担当がもう動き出せる。構成の細部を詰めている裏側で、画像はすでに生成が進んでいる。待たずに並走できる。

数字で見るとイメージしやすい。構成に3分、画像生成に2分かかるとする。1人で順番にやると、3分＋2分で合計5分。分けて並走させると、構成が固まり始めた時点で画像も動き出すから、全体はだいたい3分強で終わる。**作業の中身は変わっていないのに、待ち時間だけが消える。**これが、分けると速くなるということの正体や。

人を増やすと仕事が速くなるのと、まったく同じ理屈です。1人に順番にやらせるより、待っている時間を並行して埋められる人がもう1人いる方が、全体の完了は早い。AIでも同じことが起きているだけやで。

お金の話｜上位モデルは、段取りと最終チェックだけ

前回、ループを回すほどお金がかかるという話をした。回すたびに1回分の利用料が乗るから、確認を重ねるとその分コストも増える。今回は、その答えの一部がここにあるで。

分担するとき、全員に同じ性能のモデルを使う必要はあらへん。**段取りを組む人と最後にチェックする人だけ、いちばん性能の高いモデルにする。**実作業をする人、つまり調べたり書いたりする係は、性能を落としたモデルで十分間に合うことが多い。

なぜこれでうまくいくかというと、最初の段取りと最後のチェックは、全体を見渡して判断する力が要る作業やからです。何をどう分けるか、出てきたものが噛み合っているか。ここは判断力が要る。一方で、調べる、下書きを書くといった実作業は、渡された範囲の中だけをこなす仕事なので、性能を落としたモデルでも十分こなせる場面が多い。

料金がどのくらい違うかは使っているサービスやプランによって変わるので、この記事では具体的な数字までは書かへん。ただ、上位モデルと下位モデルのあいだに料金差があるサービスは多く、実作業の部分を下位モデルに任せるだけでも、全体の費用感はかなり変わってくる。**品質を落とさず、費用だけを抑えられる。**これが、上位と下位を使い分ける意味や。

ここで注意してほしいのが、「全部を下位モデルにすれば、もっと安くなるやろ」という発想です。それは違う。段取りと最終チェックまで下位モデルに任せると、そもそもの割り振りが雑になったり、仕上がりの粗さに気づけなかったりする。**節約していい場所と、節約したらあかん場所がある。**この線引きを間違えないことが、コストと品質の両方を守る鍵になる。

イメージとしては、店の采配をする店長と、レジや品出しをするスタッフの違いに近い。店長が全体の段取りを見て、最後に「今日はこれでよし」と判断する。レジ打ちや品出しは、決められた手順の中で動くスタッフに任せる。全員を店長にする必要はないし、全員をスタッフにしてしまうと、誰も全体を見なくなる。役割に応じて、投じる力の大きさを変えるだけの話や。

分けるほど、教育コストもかかる

ここまでは「上位モデルと下位モデルの使い分け」の話やった。せやけど、分けることで増えるコストは、実はもう1つある。同じルールファイルやプロンプトを、分けた係の数だけ読ませ直す必要が出てくるということや。

これ、新しく人を採用したときの教育コストと同じ発想で考えるとええ。1人でずっと仕事を回しとったら、一度教えたことは、その1人が覚えたままでええ。せやけど、人を2人、3人と増やすと、増えた人数分、同じ仕事のやり方を教え直さなあかん。調べる係にも、書く係にも、見る係にも、頼み方のルールやトンマナを、それぞれのチャットで一から読ませる必要がある。第4回で話した「ルール」、始める前に必ず読ませる資料のことやったな。分けるということは、あの「ルール」を、増えた係の数だけ毎回読ませ直すということでもあるんや。

ここで、AIに払っている料金の中身も少し触れておく。料金は、大きく分けて**入力トークン（AIに読ませる量）と出力トークン（AIが書き出す量）**の2つで決まる。ルールファイルを読ませ直すたびに発生するのは、この入力トークンや。係が増えるほど、同じ資料を読ませる回数も増えるから、入力トークンの分だけ費用が積み上がっていく。

もう1つ、思考トークンというものもある。上位モデルほど、答えを出す前に頭の中でじっくり考える工程を挟むことが多い。この「考える」工程にもトークンが使われていて、これも料金に乗ってくる。段取りや最終チェックのように、判断力が要る係を上位モデルにすると、実作業の係より1人あたりの費用が高くなりやすいのは、この思考トークンの分も含まれているからや。

つまり、分けて任せることには、実作業を分散させる効き目がある一方で、**同じ資料を読ませ直す入力トークンと、上位モデルの思考トークンという、増えるコストも背中合わせでついてくる。**新しく人を採用したら、その人が独り立ちするまでの教育コストがかかるのと、まったく同じ理屈や。分ける人数を増やすときは、この教育コストも込みで、増やす価値があるかを見てほしい。

ハツネに、仲間を2人つけてみる

うちのAI社員、ハツネで実際にやってみるで。ここまでの4回で、ハツネはもう指示書と引き継ぎ資料を抱え、机と道具を持ち、赤ペンを入れてもらった書類まで手にしている。今回、そのハツネに仲間を2人つける。

任せる仕事は、これまでと同じ「お客さんからの問い合わせに、返信の下書きを用意する係」や。1つのチャットにこの仕事全部を任せていたのを、3つの係に分ける。

• 調べる係：過去のやりとりを見て、お客さんが何に困っているのか、これまでどんな回答をしてきたかを調べる
• 書く係：調べる係が調べた内容と、頼み方の型（第2回で渡した役割・条件・形式・禁止事項）をもとに、下書きを書く
• 見る係：書く係が書いた下書きを、前回渡した合格基準3つに沿って確認する それぞれの係に渡すものが、実は肝心や。調べる係には、お客さんの名前と、過去のやりとりの置き場所だけを渡す。それ以外は要らへん。書く係には、調べる係が調べた結果と、頼み方の4つの型を渡す。見る係には、書く係が書いた下書きと、合格基準の3つだけを渡す。**それぞれに、その係が必要とする分だけを渡す。**これが渡す資料を絞る、前々回のコンテキストの話とそのままつながっている。

分けてみると、何が変わるか。調べる係が過去のやりとりを探している間に、書く係は待つしかない。ここは順番になる。せやけど、調べる係が「お客さんは配送遅延に困っている」というところまで見えた時点で、書く係はもう下書きを書き始められる。調べる係が細かい経緯まで確認し切るのを待たなくてもええ。**必要な情報が出た時点で、次の係が動き出せる。**これが、この記事の最初から言うてきた「順番待ちが消える」の実物や。

3人に分けたことで、それぞれが自分の持ち場に集中できるようにもなる。調べる係は調べることだけ、書く係は書くことだけ、見る係は基準に沿って見ることだけ。1つのチャットに全部乗せていたときより、それぞれの精度も上がりやすい。1つの仕事に集中している方が、抜け漏れに気づきやすいのは、人間もAIも同じやで。

わしの現場では｜サイトもシステムも、役割で回しとる

ここからは、わしが実際に動かしている例を話すで。うちで作っているものは、問い合わせ返信よりもっと大きい仕事やけど、考え方は同じや。

AI大将のサイトは、5役で運用してる

このAI大将のサイトも、実は5役に分けて回しとる。

• プロジェクトマネージャー：わしと壁打ちしながら、全体のスケジュールを管理する
• ディレクター：生成タスクをそれぞれの係に割り振り、クオリティーを管理して、わしとPMに報告する
• リサーチャー：ニュースやネタを集める
• ライター：記事を書いたり、画像生成のプロンプトを作ったりする
• デザイナー：画像を生成する リサーチャーが集めたネタを、わしとPMが「これは記事にする価値があるか」で選ぶ。ディレクターが誰にどこまで任せるかを割り振り、ライターが本文と画像プロンプトを書く。デザイナーが画像を仕上げ、ディレクターがクオリティーを確認してから、わしとPMへ報告が上がってくる。この記事自体も、この5役の流れに乗って出来上がっとる。

SNS運用エージェントシステムも、4役で動いとる

もう1つ、今はまだ公開してへんサービスやけど、SNS運用を自動化するエージェントシステムも同じ考え方で作っとる。

• プロジェクト管理担当（PM）
• 要件定義・設計担当（SE）
• 実装担当（PG）
• テスト担当（テスター） PMが全体の進め方を決め、SEが「何を、どう作るか」を設計書に落とす。その設計書をもとにPGが実際に組み立て、テスターが動くかどうかを確認する。**これは、システム開発の現場そのままのやり方や。**AI社員の分担も、結局は人間のチーム作りと同じ発想でできとるんや。

この2つの例で共通しているのは、どちらも最初から5役や4役を狙って設計したわけやないということです。1人でやってみて、詰まった場所に気づいて、そこだけ分けた。その積み重ねが、今の形になっとる。読者のみんなに、いきなり5人分業を目指してほしいわけやない。うちがここまで来たのは、詰まった場所を1つずつ分けていった結果やという話やで。

束ねる人がおらんと、バラバラになる

ここまで、分けることのメリットばかり話してきた。せやけど、分けるだけで終わったら失敗する。最後に1人が全体を見て、つじつまを合わせる工程が要る。

調べる係、書く係、見る係の3人に分けたとしても、それぞれが自分の持ち場だけを見て終わったら、出てくるものはバラバラのままになりかねへん。調べる係が見つけた情報と、書く係が実際に書いた内容が微妙にずれていたり、見る係が指摘した修正が、下書きに反映されないまま残っていたり。分けた工程を、誰かが最後に1本の流れとして通す必要がある。

これは新人の分業でも同じことが起きる。営業部が集めた情報と、制作部が作った資料の内容がずれたまま、それぞれが「自分の仕事は終わった」と思っていたら、最終的に出す資料はちぐはぐなものになってしまう。誰かが最後に通しで見て、整えて、初めて1つの仕事として完成する。

AI社員のハツネたちの例で言えば、束ねるのは自分です。調べる係と書く係と見る係、3人の成果をそのまま送信するんやなくて、自分が最後に通して読んで、送信ボタンを押す。ここを他の誰かに任せることはできへん。分けた分だけ、束ねる側の責任は逆に重くなる。ここを忘れて「分けたから、あとは勝手にできあがる」と思ってしまうのが、いちばんよくある失敗や。

束ねる工程は、面倒に思えるかもしれへんけど、実際には数十秒で終わることが多い。調べる係が調べたことと、書く係が書いたことが噛み合っているか。見る係が指摘したことが、ちゃんと直っているか。この2点をざっと見るだけで十分や。**分けたからこそ、最後の確認は1箇所に集中できる。**むしろ、1人で全部やっていたときより、束ねる工程は軽くなることが多いんやで。

どこまでやるか｜1人で足りるなら、分けんほうが速い

ここまで分けることの効き目を話してきたけど、大事な線引きを1つ渡しておく。1人で足りる仕事は、分けんほうが速い。

分けるということは、それぞれの係に何を渡すか考える手間、最後に束ねる手間が新たに発生するということです。小さい仕事、たとえば「このメールを丁寧な言い回しに直して」くらいのお願いに、調べる係と書く係を用意する必要はまったくあらへん。段取りにかける手間の方が、実作業より大きくなってしまう。

分ける目安は、1つのチャットの中で「今、何をしているか自分でも分からなくなる」瞬間があるかどうかや。調べながら書いて、書きながら確認して、また調べ直して。話がどんどん長くなって、途中で前提を見失う感覚があるなら、それが分けどきのサインになる。逆に、そんな感覚がまったくない小さい仕事なら、1人のままで十分速い。

前回、ループエンジニアリングの回でも「毎回チェックさせる必要はない」という線を渡した。今回も同じや。**全部の仕事に5つの考え方をフル装備で使う必要はない。**普段の小さいやりとりはプロンプトだけで済ませて、大きくて詰まる仕事に出会ったときだけ、分ける発想を取り出す。これがいちばん無理のない使い方や。

やり方｜2つに割ってみる

理屈はここまでにして、今日やる手順に落とし込むで。難しいことは要らん。今、1つのチャットでやっていることを、2つに割るだけや。

1. **いま1つのチャットでやっていることを、そのまま書き出す。**調べて、書いて、自分で確認する。この3つが1つのチャットに全部乗っていないか見てみる
2. 調べる部分と、書く部分に線を引く。「情報を集める作業」と「文章を組み立てる作業」で分けると、線が見つけやすい
3. **チャットを2つに分ける。**片方には調べることだけを頼み、もう片方には書くことだけを頼む
4. **調べる係が出した結果を、書く係にそのまま渡す。**渡すときは、書く係が必要とする部分だけに絞る

この4ステップも、今日中に終わる。新しいツールも契約も要らへん。今使こてるチャット画面を、もう1つ開くだけでできることや。

自分の仕事に置き換えるための表を用意した。うちのハツネに問い合わせ返信を任せた例と、自分の欄を並べて書けるようにしとる。

決めること	例（問い合わせ返信の下書き）	あなたの場合
いま1つでやっていること	過去のやりとりを探して、下書きを書いて、自分で確認する	＿＿＿＿
調べる係に渡すもの	お客さんの名前と、過去のやりとりの置き場所	＿＿＿＿
書く係に渡すもの	調べた結果と、頼み方の4つ（第2回）	＿＿＿＿
見る係に渡すもの	下書きと、合格基準3つ（第5回）	＿＿＿＿
束ねるのは誰か	自分。最後に通して読んで、送信ボタンを押す	＿＿＿＿

この表でいちばん大事なのは、最後の行や。**束ねるのは誰かを、必ず自分で埋めてほしい。**ここが空欄のまま分けてしまうと、さっき話した通り、バラバラの成果物が手元に残るだけになる。分けることと、束ねる人を決めることは、必ずセットで進めてくれ。

いきなり3人まで分ける必要もあらへん。まずは調べる係と書く係の2つだけでもええ。慣れてきたら、見る係を足す。今日は2つに割るところから始めたら十分やで。

つまずきやすいところ

実際にやってみると、いくつか引っかかるところが出てくるはずや。よくあるつまずきを先に潰しとく。

最初から5役に分けようとする

うちのサイト運用の例を読んで、「よし、うちも5役でやろう」と思ってしまう人がいる。それは順番が逆や。うちも最初から5役やったわけやなくて、1人でやって詰まった場所を、1つずつ分けていった結果が今の形になっとる。**まずは2つに割るところから。**足りひんと感じた場所だけ、後から増やしたらええ。

束ねる人を置かない

分けることに気を取られて、最後に通して見る工程を忘れてしまうパターンや。調べる係と書く係の成果を、そのままつなげて送ってしまうと、細かいずれが残ったままになる。**分けた分だけ、最後に束ねる工程を必ず残す。**ここは省略できひん。

全部を上位モデルで回して費用が跳ねる

分担する上で、全員に同じ性能のモデルを使ってしまうと、コストの面での得がなくなってしまう。段取りと最終チェックだけを上位モデルにして、実作業は性能を落としたモデルに任せる。この線引きを忘れると、分けたのに費用だけ増えるという本末転倒な結果になる。

分けたのに、それぞれに前提を渡し忘れる

チャットを分けると、それぞれのチャットは独立した存在になる。調べる係が知っている前提を、書く係は知らへん。係を分けるときは、その係が必要とする情報を、毎回きちんと渡す。「言わなくても分かるやろ」は、分けたチャットには通用せえへん。ここは第3回のコンテキストの話がそのまま生きてくる場所やで。

小さい仕事まで分けようとする

一度この考え方を覚えると、なんでも分けたくなる時期が来る。「今日のランチ、何が良いか聞くだけやのに、調べる係と提案する係に分けよう」みたいな話や。それはやりすぎ。分ける手間の方が、実作業より大きくなってしまっては本末転倒やで。詰まりを感じたときだけ、分ける発想を取り出すくらいでちょうどええ。

よくある質問

チャットを分けるだけで、本当に効果はありますか？

あります。1つのチャットに調べることと書くことを両方任せていると、AIは会話の途中で目的を見失いやすくなります。チャットを分けて、それぞれに1つの役割だけを渡すと、途中で話がずれる頻度がはっきり減ります。特別なツールや設定は不要で、今使っているチャット画面を複数開くだけで試せます。

上位モデルと下位モデルの使い分けは、どう決めればいいですか？

全体を見渡して判断する作業（最初の段取り、最後のチェック）には上位モデルを、渡された範囲の中だけをこなす実作業（調べる、下書きを書く）には下位モデルを使うのが基本です。判断力が要る場所を見極めて、そこだけ性能を高くするという考え方で線を引いてください。

何人まで分けられますか？上限はありますか？

技術的な上限より先に、管理できる人数の方が問題になります。係が増えるほど、それぞれに何を渡すか、最後にどう束ねるかの手間も増えます。この記事の例のように、まずは調べる係と書く係の2つから始めて、必要を感じたときだけ増やす進め方が現実的です。5人、10人と分けている例もありますが、それは詰まった場所を1つずつ分けていった結果であって、最初からその人数を狙うものではありません。

無料版のAIでもできますか?

できます。チャットを分けるという行為自体は、無料版でも有料版でも変わりません。無料版だと1つのチャットで扱える会話の長さに制限が出やすいため、大きい仕事ほど分けることの効果を感じやすいはずです。有料プランへの切り替えを検討する前に、まずは分けて試してみることをおすすめします。

まとめ｜今日やる一歩

長々書いてきたけど、この記事で持って帰ってほしいのはこの3つだけや。

1. 大きい仕事が途中で崩れるのは、1人に全部やらせているからで、役割ごとに分けて最後に束ねると崩れにくくなる
2. 分けると速くなるのは、並列で動くからやなくて、順番待ちが消えるから
3. 上位モデルは段取りと最終チェックだけに使い、実作業は下位モデルに任せると、品質を落とさずコストを抑えられる 今日やることは1つだけや。**いま1つのチャットでやっていることを、調べる部分と書く部分に線を引いて、2つに分けてみてくれ。**それだけで、詰まる感覚がどう変わるか、自分の目で確かめてみてほしい。

これで、5つの考え方が全部出そろった。頼み方、渡す資料、机と道具、出す前の確認、そして今回の分担。ハツネはもう、指示書も引き継ぎ資料も机も赤ペンも、仲間2人も抱えている。次はいよいよ最終回や。**今、うちのAI社員はどこでつまずいているのか。**5つのうちどれが足りていないのかを、症状から見分ける話をするで。

うちのAI社員、いまどこでつまずいてる？5つの見分け方へ進むと、5つを使い分けるための見分け方が読めます。今回の「分ける」がまだしっくりきていない人は、先に自分の仕事に、自分で赤ペンは入れられない｜ループエンジニアリングを読み返すと、この記事の入口だった「もう2人でやってました」の意味がつながります。