AIエージェント（指示を受けると、自分で段取りを考えながら作業を最後まで進めてくれるタイプのAI）は、いまや一度に何十もの作業をこなせるだけの賢さを備えています。にもかかわらず、実際に「任せられる仕事量」は、思ったほどには増えません。二体、三体と並べても、そのぶん確認する対象が増え、人の側が追いつかなくなるからです。
問題はモデルの性能ではなく、それを見る人間の側にあります。本記事では、一人で複数のAIを動かしても破綻しないための「監督の設計」を扱います。鍵になるのは、役割を分けること、確かめ方を先に決めること、そして人の関与を「承認ゲート」に絞ること。これは、意図の伝え方（note・rule・skill）や、一連の作業をひとつながりに束ねて自動で最後まで進める仕組み化を扱った、これまでの記事の次の段階にあたる話です。当社の支援現場での運用知見も交えて、具体的に整理します。
AIを増やしても速くならない ― 本当の上限は「人間の注意力」
台数を増やすほど速くなる、とはならないのが、AIエージェント運用の最初のつまずきです。
いまのモデルは、単体でも相当に複雑な作業をこなします。ある解説では「今日のモデルは50のタスクを解決できる賢さがあるが、その実装を監督する人間の帯域が足りない」と表現されていました。つまり、成果を頭打ちにしているのは、AIの賢さではなく、その仕事を確かめ、方向づける人間の注意力の総量なのです。一人の担当者が一体のAIに張り付き、出力を逐一読み、間違いを直し、次を指示する——このやり方のままAIだけを増やしても、増えるのは自分が見るべき画面の数であって、片づく仕事の量ではありません。
だからこそ発想を変える必要があります。監督を「人が頑張って全部見る」ことで担うのをやめ、監視の一部を仕組みの側に持たせる。マルチエージェントという考え方の本質は、台数を増やすことそのものではなく、人の注意を解放するために、確認と是正の役割をシステムの内側に作り込むことにあります。
上限を決めているのは、モデルの賢さではなく、人間が確認に割ける注意力の総量である。
「単発の指示」から「回り続ける仕組み」へ
任せきるための第一歩は、都度プロンプト（AIへの指示文）を書く働き方から、条件を満たすまで回り続ける仕組みを書く働き方へ移ることです。
これまで本ブログでは、AIに意図を正しく伝えるために文脈をAIの外に書き残しておく話（note・rule・skill）と、会議の後続タスクをひとつながりの流れに束ねて自動で進める話を扱ってきました。今回はその延長線上で、束ねた処理を複数並走させ、それでも破綻させないための監督を設計します。ちょうど、世界的に使われているAIエージェント型開発ツールの作者が語った働き方の変化が、この流れを言い当てています。彼は自らの働き方を三段階で説明しました。第一段階は人が主役で、AIは補完役。第二段階は複数のセッション（AIとのやり取りのひとまとまり。チャットの画面を1つ開いて進める作業の単位です）を同時に走らせるが、指示は毎回人が打つ。そして第三段階で、人は「ループ」を書き、そのループがAIに指示を送り続けるようになります。
「もうプロンプトを送っていない。私が持っているのはループだ。次に何をするか考えるのは、そのループの方だ」——ある開発者の言葉
ここで言う「ループ」は難しい仕組みではありません。いつ次の一手が始まり、いつ止まるのか、その主導権を人からシステムへ渡すという一点が本質です。単発の指示は、始まりと終わりをいつも人が握っています。これを手放し、始動と停止の判断まで仕組みに委ねられて初めて、人は複数のAIを同時に見渡す側に回れます。監督の設計とは、この「回り続ける仕組み」を、暴走させずに信頼できるものにするための作法だと言えます。
段階が進むにつれて、人の仕事の中身も入れ替わります。第二段階までは、人は「次に何をさせるか」を毎回考え、指示という形で出力し続けていました。第三段階では、その「次を決める」判断の多くがループの側に移り、人に残るのは「どう回すかをあらかじめ設計すること」と「回った結果を要所で見て判断すること」です。作業の主語が人からAIへ移り、人は段取りと判断へ後退する。この後退はサボりではなく、より少ない接点で、より多くのAIを動かすための前進です。以降で述べる役割分離も検証設計も承認ゲートも、この「回り続ける仕組み」を信頼に足るものにするための具体策だと捉えてください。
役割を3つに分ける ― 計画／実装／検証
長い工程を任せるなら、一体にすべてをやらせるのではなく、計画・実装・検証という三つの役割に分けるのが出発点です。
役割を混ぜたまま一体に任せると、その一体は「自分で計画し、自分で作り、自分で合格と判断する」ことになります。作った本人が採点すれば、評価は甘くなりがちです。そこで、次の三つに分けます。計画は、要件を明確にし、大きな仕事をマイルストーンに割り、後述する検証基準までを先に用意する役割。実装は、余計な文脈を持ち込まないきれいな状態で、一つの機能だけを作り、何をやって何をやらなかったかを記録して次へ引き継ぐ役割。検証は、実装の中身や意図をあえて事前に見ずに、決められた基準に照らして合否を判定する「敵対的」な役割です。
これは開発の仕事に限った話ではありません。たとえば市場調査のレポートを複数のAIに任せる場面なら、調べる観点と目次を決め、合格の条件まで用意するのが計画。章ごとに調べて書き上げるのが実装。書いた本人とは別に、決められた確認項目へ照らして合否を判定するのが検証です。役割の呼び名は開発の現場から来ていますが、中身はどんな業務にも当てはまる分担です。
とりわけ検証は、実装側の会話履歴や「こう作りました」という説明を引き継がないことが肝心です。引き継いでしまうと、確かめる側が作り手の理屈に引きずられ、基準が甘くなります。作る主体と、確かめる主体を、文脈ごと分ける。この分離が、任せきりでも品質が崩れない土台になります。
役割を分けるうえで、もう一つ効くのが「引き継ぎの型」を決めておくことです。実装が一区切りしたら、次の担い手のために決まった項目を記録します。何を完成させたか、何をあえてやらなかったか、どんな操作を実行したか、途中で見つけた別筋の問題は何か、決められた手順を守ったか——この五点です。なかでも「あえてやらなかったこと」を明示しておくことが、長く走らせるときの信頼性に最も効くとされています。次の担い手が同じ場所を二重に作り込んだり、逆に誰も手を付けないまま抜け落ちたりする事故は、この一行があるだけで大きく減ります。口頭のニュアンスに頼らず、引き継ぎを構造化された記録として残す。これも役割分離を支える地味な作法です。
もう一段踏み込むなら、役割ごとに当てるモデルを変えるという手もあります。実装と検証で異なる系統のモデルを使うと、同じ教材で学んだ者どうしのような共通の思い込み（AIは学習に使った文章の傾向を、そのまま答えのクセとして引き継ぎます）を共有しにくくなり、検証が実装のクセをそのまま見逃す事態を構造的に避けられます。計画は考える力を、実装は作る力を、検証はまた別の視点を——と役割の性質に合わせて配分すれば、品質とコストの両面で無理がありません。同じ一体にすべてを兼ねさせないという原則を、モデルの選び方にまで広げる発想です。
検証は「先に」決める ― 後から書いた基準は追認にしかならない
確かめ方は、作り終えてからではなく、作り始める前に決めておくのが要点です。
実装が終わってから「さて、どうテストしよう」と考えると、その基準はできあがったものに寄り添う形になります。ある解説はこれを「実装後に書かれたテストはバグを捕まえない。決定を追認するだけだ」と言い切っていました。作ってから作った基準は、間違いを見つける道具ではなく、間違いを見逃す言い訳になりやすいのです。開発の世界には、先に合格条件（テスト）を書いてから作り始める「テスト駆動」と呼ばれる進め方がありますが、その場合でも、実装するのと同じ担当が基準を書けば、同じ思い込みがそのまま基準に混ざります。
だからこそ、検証基準は計画の段階で、実装とは別の主体が用意します。どんな振る舞いを満たすべきか、どこまで確認できていれば合格とするか。といっても、大がかりな仕様書は要りません。たとえば調査レポートなら「引用した数字にはすべて出典が添えてあるか」「結論は冒頭に立てた問いに答えているか」「章ごとの要約が本文と食い違っていないか」——この程度の、数行のチェックリストで十分です。大事なのは、作り手が着手する前に、合否を判定できる形で書き出されていること。これを先に固定し、実装が終わったら、その基準に照らして独立に採点する。生成する側と評価する側を、主体として分ける——この一手が、任せきりの品質を担保します。承認ゲートで人が最後に見るのも、この「先に決めた基準を通っているか」です。基準が後付けなら、人の承認もまた追認に堕ちてしまいます。
先に決めた基準だけが、間違いを捕まえる。後から書いた基準は、決定を追認するだけになる。
並列と逐次を分ける ― 「調べる」は並列、「変える」は逐次
同時に走らせてよい作業と、順番に一つずつ進めるべき作業を、はっきり分けることが安定運用の分かれ目です。
並列にしてよいのは、何かを書き換えることのない「調べる」作業です。コードベース（開発中のプログラム一式）の中身の探索、資料や前例の確認、確認すべき項目の洗い出し——これらは同時に何本走らせても互いを壊しません。一方、実際に何かを「変える」作業、つまり実装や修正は、逐次で一つずつ進めるべきです。複数を並行して書き換えると、変更同士がぶつかり、食い違いが生まれ、どこで壊れたのか追えなくなります。増やした並列が、そのまま「不具合の原因を探して直す作業（デバッグ）」の難しさに化けるのです。
この差は、工程が長くなるほど複利で効いてきます。よく引かれる例では、一手あたりの誤差が1%あると、100手を重ねたときの成功率はおよそ36%まで落ちます。誤差を0.1%に抑えれば、同じ100手でも90%以上を保てます。一手の精度のわずかな差が、長い工程の末に大きな差として現れる。だからこそ「変える」作業は逐次に絞り、一手ごとに検証と記録をはさんで、誤差が積み上がらないようにします。調べるは大胆に広げ、変えるは慎重に一列に——この使い分けが、長時間の自律運用を現実的なものにします。
並列を欲張らないことには、もう一つ実利があります。同時に何本も書き換えを走らせると、どの変更がどの不具合を生んだのかが見えなくなり、切り分けだけで時間が溶けます。逐次であれば、不具合が出たときに「直前の一手」を疑えばよく、原因の特定が段違いに速い。速さのために並列化したはずが、かえって全体を遅くする——この逆転を避けるためにも、変更は一列に保つ価値があります。並列で稼ぐのは「調べる」の速度、逐次で守るのは「変える」の確かさ。両者は競合しないので、役割を分けたうえで別々に最適化すればよいのです。
一発で通らない前提で設計する ― 是正を通常フローに組み込む
検証は一度で通らないのが普通です。だから是正を「例外」ではなく「既定の流れ」として組み込んでおきます。
任せきりの設計でつまずきやすいのが、検証が一発で成功する前提で工程を一直線に描いてしまうことです。実際には、作っては直し、直しては確かめるやり取りが必ず発生します。ある実践報告では、検証が一度で通ることはほとんどなく、常にフォローアップが必要で、工数のうち実装が占めるのは6割ほど、残りは検証と是正のサイクルに費やされたと述べられていました。是正を想定していない一直線の設計では、最初のやり直しが起きた瞬間に流れが止まってしまいます。
長く走らせるほど、AI特有の「ドリフト（ずれ）」も無視できません。「もう十分だ」と早すぎる完了を宣言する、「完璧です」と言いながら実際には崩れている、小さなずれが少しずつ積み重なる——こうしたずれは、放っておくと成果物を静かに侵食します。対処は、ずれを前提に仕組みで受け止めることです。図で示したように、検証で基準に届かなければ計画へ差し戻し、そこから調査・実装・検証をもう一巡させる。是正を通常フローの一部として最初から描いておくことで、やり直しが起きてもシステムは止まらず、人が慌てて介入する必要もなくなります。
検証は一度で通らない前提で組む。是正を例外にした設計は、最初のやり直しで止まる。
人間が持つのは「承認ゲート」だけ ― 監督を最小接点に絞る
任せきるとは、放任することではありません。人の関与を、あらかじめ決めた「承認ゲート」に絞り込むことです。
役割を分け、検証基準を先に決め、是正を織り込んでもなお、最後に人が判断すべき点は残ります。ただしそれは「全工程を見張る」ことではなく、「決めた地点だけを見る」ことであるべきです。ここで支えになるのが、監督の一部を仕組みに肩代わりさせる工夫です。よく整理されている観点として、完了条件をチェックボックスの形で外に出して自己判断に委ねない、視覚的な確認をはさんでAIに「目」を与え崩れを気づかせる、特定の操作のあとには、AIの裁量を挟まず毎回必ず同じ点検を通す関門を置く——といった手立てがあります。これらが「もう十分」という早すぎる自己完了や品質の自己過信を防ぎ、人が見るべき地点を最小限に減らしてくれます。
当社が支援の現場で複数のAIを並走させるときも、考え方は同じです。人がすべての出力を追うのではなく、人は計画と最終成果の「承認ポイント」だけを持ち、途中の確認は実装とは別の主体に投げる。こうして監督の接点を絞ると、一人が同時に面倒を見られるAIの数、ひいては任せられる仕事量が伸びていきます。承認ゲートは、AIを信用しないための関所ではなく、人の判断を「本当に効く一点」に集中させるための仕組みです。
承認ゲートには、もう一つ見落とされがちな効用があります。人がそこで下した判断を、次回以降のルールとして仕組みに還元できることです。たとえば、ある確認事項に人が「これはこう扱う」と判断を返したら、その判断を規約や手順に書き足しておく。すると次に同じ状況が来たときは、AIが自分でその基準に沿って処理し、人の出番が一つ減ります。承認ゲートは、その場の可否を決めるだけの関門ではなく、人の判断を蓄積し、監督の手間を回を追うごとに軽くしていく学習の入り口でもあるのです。判断を書き残す運用については、意図を note・rule・skill としてAIの外に書き残しておく考え方が、そのまま土台になります。監督を仕組みに移す設計と、意図を外に書き残す設計は、地続きの取り組みです。
監督とは、全部を見張ることではない。見るべき一点に、判断を集中させることだ。
まとめ ― 「作業者」から「監督者」へ
AIを増やしても仕事が速くならないのは、人間が確認に割ける注意力に上限があるからでした。それを解くのは、より賢いモデルではなく、監督そのものの設計です。
本記事で見た勘所は、五つに整理できます。役割を計画・実装・検証に分けること。検証基準を作り始める前に、別の主体が用意すること。「調べる」は並列に、「変える」は逐次に分けること。是正を例外ではなく通常フローに組み込むこと。そして人の関与を、承認ゲートという最小接点に絞ること。どれも派手な技術ではなく、任せきるための「段取り」です。この段取りがあって初めて、一人が複数のAIを見渡し、作業者ではなく監督者として振る舞えるようになります。
私たちが目指すのは、AIの台数を誇ることではなく、事業の成果に人の時間を向け直すことです。手を動かす部分をAIに委ね、人は方向づけと最終判断に集中する。その切り替えを支えるのが、ここで述べた監督の設計です。まずは一つの長い工程を選び、役割を分け、検証を先に決め、承認ゲートを一点だけ置いてみる。そこから、任せきれる範囲を少しずつ広げていくのが、確実な進め方です。
参考・引用元
- ハジメおうが「マルチエージェント設計の7原則：Factory『Missions』が16日間自律稼働を実現」（Zenn／Luke Alvoeiro（Factory）“Missions: Multi-Agent Systems That Ship for Days” の日本語解説） https://zenn.dev/aerign/articles/916513f6e96e7e
- 福島良典（LayerX）「エージェントハーネスとAIマネージドサービス」（note） https://note.com/fukkyy/n/n1d8fce44e67a
- 井本賢「もうプロンプトは書かない、ループを書く — /goal と /loop」（Zenn） https://zenn.dev/kenimo49/articles/write-loops-not-prompts-goal-loop
※本文は上記の公開情報および当社の運用知見をもとに再構成したものです。引用は日本語での意訳を含み、事例は特定の企業・案件・製品を指すものではありません。