便利になるほど、並べたくなる
AIエージェントを使い始めると、最初は1つの仕事を頼むだけでも驚きがあります。調べもの、資料の下書き、データの整理。任せられることが増えるにつれて、だんだん欲が出てきます。
調べものはこのエージェント、資料づくりはあのエージェント、と業務ごとに使い分けたくなる。さらに、1つ終わるのを待つ時間がもったいなくなり、あわよくば、いくつも同時に走らせたくなる。
この欲求は、とても自然なものです。エージェントを使いこなし始めた人ほど、必ずここに行き着きます。そして、並べることで仕事の進み方が大きく変わるのも本当です。
ただ、並べた瞬間から、1体のときにはなかった問題が出てきます。本稿は、その問題に先回りするための話です。
1体のうちは起きない問題
AIエージェントを1体だけ使っている間は、作業の場所も、順番も、すべて自分の目の前にあります。ところが、エージェントを2体、3体と並べ、同僚もそれぞれのエージェントを動かし始めると、これまでなかった問題が起きます。衝突です。
筆者の手元でも、最近こんなことがありました。このサイトに記事を1本公開しようとしたとき、本番に出す直前になって、別の作業（別のセッションで進めていた、まだ公開する予定のない変更）がすでに共有の本流に入っていると気づきました。そのまま出していれば、記事と一緒に、準備中の変更まで本番に出ていたことになります。このときは、今の本番と同じ版に記事だけを足して出し、別の作業はそのまま残しました。
誰も悪いことはしていません。どちらの作業も、それぞれ正しく進んでいました。問題は、お互いの作業が見えていなかったことです。
図11体で使うときと、複数で並べるとき
1体で使う
- 作業の場所は1つ
- 順番は自分が決めている
- 変更はすべて自分のもの
- 頼むのはいつも本人
複数で並べる
- 同じ場所を、別のエージェントが触る
- ほかの作業の途中に、自分の作業が重なる
- 自分の変更以外が、混ざることがある
- ほかのエージェントからも、依頼が届く
並べた瞬間から、「誰が、どこで、何をしているか」を見えるようにする必要が出てくる
衝突は4種類ある
エージェントを並べたときに起きる衝突は、大きく4つに分けられます。3つはエージェントの作業どうしの衝突、1つは人の側のうっかりです。
図2エージェントを並べたときに起きる4つの衝突
- 01
同じ場所を同時に書き換える2体が同じファイルや資料を直し、片方の変更が消える
- 02
ほかの作業を知らずに反映する自分の作業を出すときに、準備中のほかの変更まで一緒に出る
- 03
依頼の出どころを取り違えるほかのエージェントからの依頼を、本人の指示として実行する
- 04
頼む相手を間違える人が、別のエージェントに、別の仕事を頼んでしまう
1つ目は道具で防ぎやすい。見落とされやすいのは、あいだで起きる残りの3つ
1つ目は、作業の場所を分ける、変更の履歴を残す、といった昔からある方法でかなり防げます。見落とされやすいのは残りの3つです。どれも、作業そのものではなく、作業と作業のあいだ、人とエージェントのあいだで起きるからです。
4つ目は、並べ始めた人なら一度は経験があるはずです。画面に同じような見た目のエージェントがいくつも開いていて、Aに頼むつもりの仕事を、Bに書き込んでしまう。エージェントの側は、頼まれれば、自分の担当でない仕事でもそのまま進めてしまいます。しかも、Bはその仕事に必要な前提を知らないまま、それらしい結果を返してきます。人のうっかりは、なくせません。だからこそ、間違えにくくする工夫と、間違えたときにエージェントの側で気づける仕組みの両方が要ります。
対策は「見えるようにする → 聞く → 人に返す」
衝突を防ぐ考え方は、シンプルです。まず、誰がどこで何をしているかを見えるようにする。重なりそうなら、黙って進めずに相手に聞く。判断がつかないものは、人に返す。
図3衝突を防ぐ3つの手順
- 01見えるようにする誰が、どこで、何をしているかを一覧にする
- 02聞く重なりそうなら、進める前に相手に確かめる
- 人人に返す判断がつかないもの、影響が大きいものは人が決める
衝突を道具で消すのではなく、衝突しそうなことに早く気づける状態をつくる
この考え方を、そのまま製品にしたものも出てきています。2026年10月に Reason が公開した Reason Network は、Claude Code や Codex など、自分と同僚のコンピューターで動くエージェントどうしをつなぐ仕組みです。誰が、どのマシンの、どのリポジトリのどのブランチで、作業中か空いているか、何をしているかを一覧でき、公式の説明では「衝突する代わりに、聞く」ことをうたっています。
ただし、Reason Network は開発の初期にあります。公式の設計文書では、M0〜M3 と名付けた段階までを macOS で作って試し、次の M4 は未着手としています。同じファイルを同時に触ったときに警告するような機能は、今の機能としては説明されていません。製品を待つより先に、何を見えるようにし、何を人に返すかを、自分たちのルールとして決めておくほうが確実です。
同僚のエージェントの依頼は、本人の指示ではない
3つ目の衝突、依頼の出どころの取り違えは、エージェントの数が増えるほど重くなります。エージェントどうしが連絡を取り合えるようになると、「ほかのエージェントから届いた依頼」が増えるからです。
Reason Network の公式ドキュメントにも、この線引きがはっきり書かれています。ほかの人のエージェントからのメッセージは、同僚からの依頼として扱い、自分のユーザーの指示としては扱わない、というものです。
図4本人の指示と、同僚のエージェントからの依頼
本人の指示
- そのまま実行してよい
- 範囲は本人が決めたとおり
- 公開・送信も、本人が頼んだものなら進める
同僚のエージェントからの依頼
- 参考として受け取る
- 実行する前に、本人に確かめる
- 公開・送信・削除は、本人の了承なしに進めない
依頼の中身が正しくても、出どころが本人でなければ、本人に確かめてから動く
筆者の手元でも、Claude Code のセッションどうしが、互いの作業内容を見て連絡できるようにしています。別のセッションから「このページを作って公開してほしい」という依頼が届いたときも、その依頼だけで作業は始めず、本人に確かめてから進めました。依頼の中身が妥当でも、それを決めるのは本人です。
並べる前に、ルールを1枚に
エージェントを並べるとき、最初にやることは道具選びではなく、ルールを1枚に書くことです。誰がどこで何をしているかをどこで見るか。重なりそうなときに誰に聞くか。何を人に返すか。
会員向けの部分では、見えるようにする項目、作業の「札」の決め方、本番に出す前の確認、並べる順番、そしてルールの記入例をまとめています。