サブエージェントを畳む前に、分けてよい仕事を決める

出典: 【必見】Anthropic公式「サブエージェントはメインループへ統合」を徹底解説！残すべき3パターンも解説

サブエージェントを増やすほど、仕事が整っていく感覚。そんな安心感、ありませんでしたか？担当ごとに専門を任せれば、それぞれが集中してくれる気がします。そこへ公式の記事が、まっすぐ水を差しました。

まさおさんは冒頭で、Anthropic から、サブエージェントをメインループに統合したほうがよいという記事が出た、と切り出します。その中身と、自分の考えを解説する回です。

まさおさん（動画 0:20〜）

サブエージェントを単純にいらないみたいな形でね、え、ちょっと解釈もしそうなようなブログではあるんですけれども

記事の結論は、モデルの性能が上がり、1つのエージェントが長いタスクでも、関心事が混じっていても回せるようになった、ということ。その範囲なら、呼び出すたびに速度が落ち、やり取りで情報が落ちる、という中身です。

まさおさん（動画 0:48〜）

サブエージェントを呼び出したりすると余計なその速度低下

これまでの形は、開発担当やデザイン担当、さらにテスト係やフロントエンド係まで分けて、全体をまとめる構成。公式は、1つのエージェントにスキルとツールを持たせればよい、と言います。

背景の話も出てきます。昔のモデルは注意力に限りがあり、関心事を分ける必要がありました。やることリストも、ツールとして組み込まれる形。今は、1回で自分で回せる量が大きく増えた、と話します。

全部やめろ、という話ではありません。検証や並列の調査、切り出せるタスクでは、むしろ積極的に使う側。細かい分岐は速度の面で見直す時期に来ている、というのが記事の主張だと捉えている、と話します。

で、動画が見ているのは担当の数ではありません。1本のループで回せるかどうか。その一点。

分ければ安心、ではなく、回せるなら1本で。道具の向き不向きではなく、設計の考え方の話なんですよね。

実は2026年9月30日、朝の作業を任せたAIの下に、AIの作業が15個ぶら下がっていると知らされました。

契約で決まっていたのは、ブログ下書きの1つだけ。残りは、画像を直すたびに新しく作られた確かめ役が12個（うち11個は待ったまま）と、検査用のスクリプトを作る作業が2個でした。

私は「数の問題なのこれ？」と返しました。子の作業なしでできるものは、なしでやるのが筋ではないか、とも返しています。

同じ日に、AIの既定を、自分の手で進める形に変えました！別の作業を作ってよいのは三通りの場合だけ。検収も作業を作らず、別の家のモデルを1回呼ぶ形にしています。

私の判断の軸は、一つのボールは誰か一人が全部持ち、やり切る、というもの。所有者は一人です！

分ければ分けるほど、ボールを持つ人が増えます。途中で、誰の手にあるのか分からない球も出てきます。そこが気になるところです。

1本のループは、持ち主が一人。動画が示す向きと、私の軸はここで並びます。

分ける数を数える前に、ボールを持つのは誰か。そこを先に見ます。

担当を細かく分けると、一つ一つの出来は良く見えます。それなのに、全体を通して読むと、どこかがちぐはぐ。そんな場面、ありませんか？

画面には、専門の担当を十数個定義した図が出ます。依頼が来て全体をまとめる形にすると、口調がそろわず、情報の伝達で落ちる点を、公式は問題にしています。

つぎはぎになる、という話。チームごとに担当を作ると、担当の形が組織図と同じ形になる、とも記事の中で言われている、とまさおさんは話します。

まさおさん（動画 5:04〜）

チームごとに作ってしまうとエージェントがね、組織図と同じ形になる

伝言ゲームになるリスクはよく言われることで、対策もある、と前置きがあります。そのうえで挙げるのが、関心ごとで区切った担当それぞれに評価基準を持たせた場合。各担当が98点を出しても、全体の点は高くない場合がある、という話です。

1本のループなら、パート1から4まで全部の流れを見ているので、全体の最適も見られる、という主張。部分の点が高くても、全体までは見えません。

まさおさん（動画 5:58〜）

部分最適化だけじゃなくて、その全体最適化的な部分を見てもこの1本のね、ループにした方がいいっていう主張がありまして

速度の面の話も。メインでやればよいことをサブエージェントに渡すと、書いてくるまでに時間がかかります。調べ物のあと、文脈を集めてメインに返す前段があり、認識のずれをなくす手間も乗ってきます。

まさおさん（動画 6:38〜）

遅くなりがちやなと思うんですよ

目指す姿は、層を何枚も重ねる形ではなく、1本のループ。より大きい仕事では1つのセッションでは厳しく、文脈の共有を考える場面は残ります。それでも毎回区切って作るのは余計、と理解している、と話します。

部分は98点、全体は別。この落差を、数字で見せてくれる章です！

分けた担当それぞれの出来と、全体の質。この2つは、別々に見ないと見分けがつかないんですよね。

2026年10月1日、まとめ役のAIが子18本の報告を読み、聞いてきました。要らなくなったとみなした4本を、完了にしてよいか、と。

その4本の中に、朝の配信の作業が入っていたんです。記事は公開済みで、残りは講座動画だけの作業。

私は、講座動画が終わっていない作業を完了移動に回すなんてありえない、と返しました！そのうえで、その記事のオンライン講座動画で進めるように、仕組みを直させています。

私の記事より（「AGENTS.mdを全員に読ませるな」深津貴之さんの経営論を尾原和啓さんが解説。監督と実務を分けるとAIコストは半分になる・役割を分けるほど（監督・実務・検査）の節）

役割を分けるほど、確認のための確認が減る。

正直、動画の話と、いま引いた一文では、向きが逆に見えます。

といっても、分けるか分けないかの対立ではありません。分ける線をどこに引くか。その違いとして見ています。

AIに委ねたいのは、作業だけではありません。約束を覚えて、期限まで運び、成果か本当に必要な判断だけを返すところまで。そこまで含めて委ねたいんです。

伝言で落ちると、管理のボールが人へ戻ってきます。分けた担当のあいだで、誰が最後まで運んでいるでしょうか？そこが見えにくくなります。

見るのは、分けた担当の点より、最後まで運ぶ人。

ずっと担当を分けて組んできた構成を、1本にまとめて本当に回るのか。そこ、気になりますよね？長く手を入れてきた仕組みほど、畳むのは怖いもの。動画では、1本で回せる理由が順番に出てきます。

画面にはエージェントループの図が出ます。モデルがツールを呼び（並列にも）、結果を見て、また動きます。何ターンか繰り返して、ユーザーに答えるか、質問して止まる流れです。

目指す姿は、伝言ゲームではなく、1つのセッションの中で複数の関心ごとを持つ形。昔は計画役のサブエージェントを先に作り、まとめたあとにメインが判断して次へ進めていました。今は、計画の文脈を持ったまま、メインが仕事を進められる、と話します。

理由の1つ目は、モデル自体が強くなったこと。スキルを呼ぶ自立性も高く、長い文脈で忘れる体験も減って、1本のループでこなせる長い仕事も大きい、と言います。

2つ目は、段階的開示の進化です。必要なところだけ情報を取れるようになりました。Claude Code では、システムの指示文を8割ほど減らした、という話もあった、とまさおさんは話します。

まさおさん（動画 9:07〜）

段階的開示がね、え、結構進化しているかなと思っていて、必要なところだけをね、え、情報を取るようにできるようになったかなっていう風に思う

3つ目は、全体の経過を共有して判断できる状況のほうが望ましい、という点です。

まさおさん（動画 9:59〜）

全体の経過を共有して、え、判断できる状況の方がより望ましいよねっていう部分もあって

サブエージェントをやめろという話ではなく、冗長な使い方をやめましょう、という解釈。1本にするならスキルの発動が要になり、説明文を呼べるように書いて確かめます。システムの指示文は丁寧に保ち、文脈や記憶のメモの扱いも意図して決める、と話します。

今までサブエージェントで区切っていた物は、スキルに切り出すか、外部ツールへ。参照資料は、検索ツールの先か、参照用のスキルに置きます。計画のように、モデルがもともとできることは不要になる、とも言います。

1本で回せるのは、モデルの強さと、必要な時だけ読む仕組みと、全体の経過の共有。この3点が揃うから、という筋道ですよね。

で、2つ目の、必要な時だけ読む仕組み。ここには、私にも思い当たる記録があります！

2026年9月25日、長い文章を書く時の手順書（スキル）を、長文を書く時だけ読む形で入れました。

完了報告、失敗報告、質問への答え、長い作業のまとめ。この4題材を、手順書なしとありで書かせて、別のAIに伏せ字で判定させたんです。結果は、4題材とも手順書ありの側でした（自信は中・中・高・中）。

あ、指示書の1行でも違いが出ました。やわらかく、書く前に読む、と1行書いた時は、4回とも無視。

書き始める前に必ず読む、と強めた後は、新しく動かした2回とも読みました！標本は小さく、4組と、2回中2回です。

私は、一次情報や全体の文脈を読まずに、平均的な像で穴を埋めることを、手抜きだと考えています。

やり切るとは、調べ尽くし、手を尽くして、仕上げきること。

だから、必要な時に読ませる仕組みは、全体の文脈をちゃんと読ませるための道具です。読む場所とタイミングまで決めて、やっと手元で効いてくるんですよね！

読ませたい物は、書く前に読む場所へ。

1本のループが良いと聞くと、サブエージェントを全部畳みたくなりませんか？でも、ここで一度手を止めたい所があります。動画は、分けたまま残す仕事を、きちんと並べているんです。

画面には公式の図が出ます。以前は仕事の種類で分けていたのを、今はコンテキストで分ける、と話します。

1つのエージェントが長く一貫して回せても、できた成果物が全体として良いかは別の話。だから、評価する担当や検証する担当を付けるのは良い、と言います。新鮮な文脈のサブエージェントに、主観的に読みやすいかをチェックさせている、とまさおさん自身の使い方も語ります。

公式が挙げるパターンの1つ目は、膨大なリサーチです。

まさおさん（動画 12:22〜）

膨大なリサーチみたいな部分って、ま、やっぱりコンテキストをね、いっぱい使うしノイズとかもいっぱい乗るわけじゃないですか

欲しいものは絞れるので、ノイズが乗りそうな調べ物は分けてよい、という考え。2つ目は、境目の決まった部分です。仕様が決まり、壁打ちも済んだら、画面の部分とサーバーの部分で分け、セッションを別々に生やしてもよい、と話します。

3つ目は、中身を見ない検証。全体像を見たチェック係や、テストを走らせるチェックは、別に持ったほうがよい、と話します。

まさおさん（動画 13:06〜）

中身をね、ま、見ない検証

ほかにも残すものがあります。メインの会話にノイズを入れたくない仕事は、サブエージェントへ。決まった手順やルールを守らせたい仕事は、スキルに関心を分けて持たせます。ただし、スキルを1つのセッションで使い続けると、それが気になってタスクの質が下がることもある、と言います。

まさおさん（動画 14:12〜）

やっぱ注意力は有限なんで

その時は、サブエージェントや、別文脈で動くスキルも選択肢です。分け方は、ツールを取り違えたか、質が落ちたかを計測して決める、と話します。

全部やめるのではなく、分ける軸を、仕事の種類からコンテキストへ移す。動画の筋道は、ここなんですよね。

分けたまま残す場所の話。私の手元の運用とも、まっすぐ重なります！

実は私、公開や納品をする物の検収（できた物の点検）は、作った会話を引き継がない形にしています。依頼の原文と現物だけを、別の家のモデルに渡すんです。

2026年9月26日には、設計案10個を同じ1つのAIだけで作って、トーンが似てしまいました。その時、私は「AIの種類じゃない」と返しています。

2026年9月21日から10月26日までに、サブエージェントでチェックして、と頼む形の返事を40件しました！

数えたのは、自由入力の返事のうち、サブエージェントと、チェック・採点・確認・監修のどれかを含むもの。その全部が、全面チェックの依頼ではありません。

つまり私は、分けるのをやめたわけではないんです。分ける場所は、公開や納品をする物の検収のように、作った会話から切り離せる仕事に絞っています。

1本か、分けるか。表面だけ見ると、二者択一に見えますよね？

私は、違って見える両方を、片方だけ捨てずに、一段上の層へ置き直して考えます。

一段上から見ると、問いは、分けるか1本かではなく、どこを分けて残すか。そこを決めてから組むと、迷いがぐっと減るんです！

分けるか1本かの前に、分ける場所を決めておくこと。

1本にまとめたのに、前より悪くなっていませんか？設計を変えた人なら、誰にでも起こり得る場面ですよね？そうなった時の戻り道を、先に用意しておけるか。動画の最後の章は、その備えの話です。

画面には評価（eval）の図が出ます。サブエージェントを減らす前に、評価の機能が Claude Code の中にすでにある、と話します。フェーズで評価を変え、振り分けられたか、スキルを読んだか、タスクを最後までやり遂げたか、を見るそうです。

移行の手順は三段階です。1つ目は、同じ情報を扱うサブエージェントを合体すること。

まさおさん（動画 18:35〜）

同じね、情報を扱うようなサブエージェント合体してみましょうと

2つ目は、それをツールとして呼べるようにすること。3つ目は、そこまでできたらスキルやツールにすること。公式の図でも共有されていた、と話します。

ツールとして呼ぶだけなら、書き直さずに移行を進められます。ただ、プロンプト・文脈・評価がサブエージェントごとにバラバラで、呼ぶたびにループが回って遅く、細かい情報も落ちます。だから、できるだけシンプルにスキルやツールへ移したい、と言います。

移行の途中は、評価で比べる段階。移行できれば1つのループにできますが、下がる例もあります。

まさおさん（動画 19:54〜）

ここでね、下がってしまうみたいな例も、ま、あるわけですよ

公式の実例にも、評価を複数回走らせて、微妙だった例がありました。その場合は、サブエージェントのままにする判断になる、と話します。

サブエージェントが要る場面で使えているか、冗長になっていないか。再現性のチェックがとても重要、と話します。

まさおさん（動画 20:37〜）

再現性チェックみたいなところはね、やっぱすごく重要かなと思います

ツールは、操作の1つずつではなく、ユーザーの目的ごとにまとめる、という話も出ます。締めは、厚いマルチエージェント設計を変えていこう、変えなくてよい所もある、その基準は評価のツールで測って決める、という言葉です。

畳む前に、測っておく手順。下がった時は、残す判断。動画の最後は、この順番に尽きるんですよね。

で、私にも、2通りで比べた記録があります。2026年9月16日から17日、同じ素材を2つの形で書かせました。

1体に直列で書かせた版は、4分で3,919字。12工程の分業に分けた版は、19分50秒で4,686字です。

審査員は、別々のAI3体です。匿名にして3人の審査員に読ませた結果は3対0。分業版が勝ちました！

ただし、最後まで読めるか、の1点だけは、直列版が9点、分業版が7点でした。分業版は3回走らせて、最後まで終わったのは1回。

比べたのは、それぞれ1回ずつの結果。同じ条件を何度も繰り返してはいません。

動画は、畳む前に評価で測り、複数回走らせ、下がるなら残す、と言います。測ってから足したり畳んだりする向きは、私の比較と同じです。

ただ、私の比較は1回ずつ。動画が言う、複数回の再現性チェックには届いていません。

測る手間を省いて畳むと、下がったことに気づけません。気づけなければ、戻す判断もできなくなります。

私は、完璧を、一度で満足できる結果では見ません。見るのは、プロセスと姿勢です。

目的とゴールが合っていれば、未完成でも受け入れます。違和感があれば、やり直し。

だから、測ってから畳むのは、やり直せる形にしておくこと。戻れる道があるから、思い切って変えられるんです！

畳むのは、測ってから。下がったら、戻す側へ。

細かく分けた担当は、1本のループへ。分けると口調がずれ、伝言で落ち、全体が見えず、遅くなりがち。1本で回せる理由、残す仕事、畳む前の評価。動画はこの順で進みました。

で、この動画から私が持ち帰ったのは5点です。ボールを持つ人を一人にすること、最後まで運ぶ人を見ること、読ませたい物を書く前に読む場所へ置くこと、分ける場所を決めること、畳む前に測ること。

振り返ると、分けすぎた作業を減らしたり、検収だけ別の家のモデルに任せたり、1体と分業を読み比べたりしてきました。その向きは、動画の話と並びます！

次にAIへ仕事を分ける時、先に決めたいのは、どこで分けるかですか？