Vol.072 — AIエージェントは複数か、一人か——どちらが正しい道なのか

Vol.072 — Multi to Single Agent Journey 第1回

掲載日: 2026-10-13 | ニュースレター · Multi to Single Agent Journey 全10回の第1回


今回は私自身が抱えていた悩みをどう解決したかというストーリーを皆さんに語っていきたいと思います。私は自分の仕事や個人用ではClaudeを頻繁に利用します。ChatGPTは仕事やエージェント開発、レポ公開の時に利用ですね。

この全10回シリーズは私がClaude環境で開発した実際の業務を任せている6名のAIスタッフ(当社では勤務中のAIエージェントをAIスタッフを呼んでいます)についてです。

ある程度、業務にClaudeやChatGPTのプロジェクト化などを使いこなされた方が直面する悩みごとと思い、私の「1つの解決策」としてご紹介します。一番大事なのは、解決する中での課題やどのような考えでその決断に至ったかというプロセスと思い全10回となってしまいました。少しでも皆さんのお役に立てることができれば幸いです。

出発点

まず、今年の9月の時点で私の手元がどうなっていたかをお話しします。

Functional AI PartnersとDCCグループの日々の業務は、六人のAIスタッフが回していました。六人には一人ずつ名前があり、役割があり、Claudeのプロジェクトが一つずつ割り当てられています。プロジェクトごとに指示ファイル(その人物が誰で、何をどうやるかを書いたもの)があり、記憶ファイル(覚えておくべき事実)があり、状態ファイル(いま何がどこまで進んでいるか)があり、OneDrive上に専用のフォルダがありました。ウェブサイトを作り直すウェブ担当。ニュースレターやプレスリリースを書くPR担当。Brevoでのメール配信を組んで送るプロモーション実行担当。n8n上で動くカスタマーサービス担当。画像を作るデザイナー。そしてM&A案件の資料をまとめるM&Aデスク。その横に七人目として、通称「ドクター」がいました。ドクターの仕事は人間の仕事を手伝うことではなく、六人の指示ファイルを診断して書き直すことです。つまり、AIスタッフの面倒を見るためのAIスタッフです。

私はこの六人を「チーム」として設計したわけではありません。ウェブの仕事が増えたからウェブ担当を作り、メール配信が増えたからプロモーション担当を作り、というふうに、仕事が現れるたびに一人ずつ作っていきました。人を採用するときとまったく同じ発想です。そして正直に言えば、一人ひとりはよく働いていました。ウェブ担当はステージングサイトにページを積み上げていましたし、PR担当は週に何本もニュースレターを出していました。8月に誰かに「その体制はうまくいっていますか」と聞かれていたら、私は迷わず「はい」と答えていたと思います。

ここで一つ、私の考えを書いておきます。AIスタッフを一人ずつ増やしていく方法は、始めるのが一番簡単な方法です。新しい仕事が来たら、新しいプロジェクトを作り、役割を書いて、名前をつける。それだけで「担当者」が一人できます。問題は、それがいつまで簡単なままなのか、誰も教えてくれないことです。

見直すきっかけ

ごく普通の仕事が二つ続いたことです。一つはDCCグループのウェブサイト再構築で、ウェブ担当・PR担当・デザイナーの三人が、今どこまで進んでいるかという同時並行の作業ステータスを共有する必要がありました。それができていませんでした。彼らの記憶はそれぞれが単独で持っていて、三人に共通するはずのプロジェクトには、プロジェクト自身のファイルが存在しなかったのです。いえ、正しくは存在しましたが、誰も書き込みや読み出しをしなかったのです。もう一つはアクションカレンダーです。このカレンダーは私も毎日目を通し、全AIスタッフが書き込みをしながら進捗を更新していくはずのものでしたが、全員のものだったために、誰も更新しなくなったという現象がおきていました。

2026年9月15日時点の旧アクションカレンダー(M&A関連はマスク)
2026年9月15日時点の旧アクションカレンダー(M&A関連はマスク)

上の画像が、9月15日時点のそのカレンダーです。見ていただきたいのは、一番上の黄色い枠です。「Brevoは26日間、何も動いていない」「本日提出期限のJCCI原稿、担当者未定」「10日のメール配信、起きなかった——一度も準備されていない」。カレンダーは、起きなかったことを正確に記録する装置になっていました。これはこれで役に立つのですが、私が作りたかったのは、起きなかったことを教えてくれる表ではなく、物事を起こす表だったはずです。

そこで、9月3日から17日までの二週間の記録を、全スタッフ分を読み返しました。六人のうち二人は何も更新しておらず、更新できていたのは四人とドクターです。そして、その二週間、私自身が「AIスタッフの子守り」としか呼びようのないことに使われていました。特にアクションカレンダーについては、各スタッフの記憶更新がうまく言っていなかったため、「西田待ち」のリクエストばかりが増え、私のタスクばかりが増加し、チームを作ったはずが、チームの成果物は「私を待っている仕事の量」で、本来会社全体のプロモーション「アクション」を管理するカレンダーが私の仕事を管理するものに入れ替わっていました。

ウェブサイト再構築のほうも、中身を見ると同じ形をしていました。この仕事は9月の時間の大半を占めていて、一つの長いセッションの中で進めていたのですが、そこから出てくる「やるべきこと」は四人のスタッフに散らばっていました。ページそのものはウェブ担当、問い合わせフォームの裏側の仕組みはM&Aデスク、お礼メールの文面はPR担当、資料請求のパッケージはデザイナー。一つの仕事の宿題が四つの記憶に分かれて置かれていて、それを一つに戻すのは、毎回、私でした。

決め手になった発見

ここまでなら、「連携の仕組みを作ればいい」という話で済んだかもしれません。実際、最初に私が考えたのもそれでした。六人が共通で読むファイルを一つ作る、カレンダーの更新を担当するスタッフを決める、週に一度まとめる、といった案です。

ところが、ドクターに構造全体を診断させたとき、一行だけ、私の考えを止める発見がありました。この連載が存在する理由は、その一行にあります。

私が使っていた6名のAIスタッフのうち、3名には各タスクの進捗管理をする状態ファイル(Status.md) が搭載されており、1名は膨大なファイルサイズに、その他2名はほとんど空にという状態でした。

各AIスタッフの設定をしてから一度も再確認をしていなかったのが私のミスですが、ここまでルールの解釈が各AIスタッフで異なるとは。。と愕然としていました。

これでは各AIスタッフが正しい進捗認識などできるわけがありません。同じルールブック(Claude.mdと基本的な記憶ファイルの使い方、進捗ファイルの使い方は同じ)であるにも関わらず、数カ月間の利用でここまで変わるとは。

深く原因究明をすると、それは当然ですが私にありました。

私が各AIスタッフに気づいた点を直ぐに指摘をすると各人がそれぞれの状況は私の口調(かなり怒っている。。苦笑)に応じてルールブックを書き換え始めます。最初はそれほど影響はないのですが、時間が立つに連れてそれらのルールブック(追加分)の差が各AIスタッフにより偏りが生じてきます。

この瞬間に、問いが変わりました。それまで私は「六人をどう連携させるか」と考えていました。本当の問いは「一つの会社に、なぜ六つの記憶があるのか」でした。そして、その問いを立ててしまうと、連携の仕組みを足す案は全部、六つの記憶を前提にした応急処置に見えてきました。

決断と、三つの理由

9月17日、六人ではなく一人のエージェントで行くことを決めました。理由は三つあり、私にとって重かった順に書きます。

一つ目は、機能の数が思ったより少なかったことです。マーケティング側の四人が実際に私のために何をしていたかを、名前ではなく仕事の種類で書き出してみました。記録を取る、全体を見える形にする、外部ツールを操作する、文章を書く、画像を作る、調べて一緒に考える、道具を作る——この七つです。七つの機能は、人で言えば「プロモーション・クリエイティブ担当」一人の肩書きに収まります。M&Aデスクはアシスタントの仕事です。六人という人数は、分ける必要のない仕事につけた頭数でした。

二つ目は、連携の問題は、規模を広げる前に解くべきだということです。一人のエージェントにすると、間違いなく不利な点が出てきます。セッションの冒頭で、そのエージェントは課題を把握するためにより多くのものを読まなければなりません。読むべき状態が増え、立ち上がりの手順も長くなります。このコストは分かった上で引き受けました。理由は単純で、多機能の一人を円滑に動かせないなら、複数にしたところで同じ連携の失敗が、より大きな規模で現れるだけだからです。逆に言えば、一人を動かすために作ったルールは、将来また複数に広げるときにも、あるいは元に戻すときにも、そのまま土台になります。

三つ目は、これが棚卸しの機会になることです。各機能が本当にどのスキルを使っているのかを、「スタッフにはこれが必要だろう」という私の想像からではなく、私が実際に何をどう頼んでいるかという記録から確かめる。六人のときには、この確認を一度もしたことがありませんでした。

何も捨てないと決めたこと

決断の中で、決断そのものより大事だったと今でも思っている一文があります。「これまでに作ったものは、何一つ捨てない」。六人が作ったプロジェクト、ファイル、ルールは、一人のエージェントがそれらに対して実力を証明するまで、すべてそのまま残しました。

これは精神論ではなく、費用の話です。ゼロから作り直すなら、それは数か月かかる再構築です。統合であれば、三週間ほどのプログラムで済みました。その三週間の中で何が起きたか——記憶、ファイル、ルール、謝罪、スキル、自動化、フォルダ、自分のやること一覧、コスト——を、残りの九回で一つずつお話しします。

なぜこれが、あなたへの答えにならないのか

タイトルに「どちらが正しい道なのか」と書きましたが、ここまで読んでいただいた方には、私の答えが「一人」ではないことが伝わっていると思います。私の答えは「場合による」で、しかもその「場合」はかなりはっきり言えます。

複数エージェントが向くのは、本当に並行して進む仕事です。たとえば、同時に複数の長い処理を走らせる必要がある場合。あるいは、理由を名指しできる切り離しが必要な仕事です。顧客Aの情報を顧客Bの担当に見せてはいけない、守秘義務のある案件を他の仕事と混ぜてはいけない、といった場合です。そしてもう一つ、チームを率いるのが好きで、チームが求める調整の手間を惜しまない経営者にも向きます。これは皮肉ではなく、本当にそういう方がいます。

一人のエージェントが向くのは、仕事の種類は多いけれども、一番難しいのは事実を一つに保つことだ、という場合です。昨日決めたことを今日も同じように扱ってほしい、Aの仕事で分かったことをBの仕事でも使ってほしい、という要望が中心なら、記憶は一つであるべきです。そして、六つの記憶を突き合わせるより一つのファイルを直すほうがましだ、と思う経営者にも向きます。

私は後者でした。前者の方にこの連載が考えを変えさせることはないでしょうし、その必要もありません。ただ一つだけ言えるのは、この後に私がぶつかった問題は、どれも「六人か一人か」の問題ではなかったということです。記憶が消える、ファイルが多すぎる、ルールが守られない、謝ってばかりいる——これらはAIスタッフと働くこと自体についてくる問題で、複数で動かしている方には、むしろ早く効いてくるはずです。残りの九回は、それぞれ一つの問題を入口にしています。自分に当てはまる扉から入ってください。