社内にAIエージェントを入れる計画を立てるとき、多くの会社が最初にこう考えます。「まず営業支援AIを作って、次に経理AI、それから人事AI」。部門ごとに専用AIを並べる構成です。組織図に沿っているので、一見自然に見えます。
結論から書きます。この「役割別エージェント」構成は、AIエージェント専業の米Sierra社が自社で試して、失敗と結論づけた構成です。同社は役割別に作った4体のAIを廃止し、窓口が1つの「単一エージェント」に統合しました（出典: AI-pilling our company: lessons learned、2026年7月）。この記事では、役割別の何が問題なのか、そして「それでも分けるべきもの」は何かを解説します。
Sierraで起きたこと
Sierraは企業向けAIエージェントを開発・販売している会社です。つまりAIエージェント作りのプロが、自社の社内向けに本気で作った結果だという点に意味があります。
同社はまず、サポート担当AI・データ分析AI・エンジニアAI・営業AIの4体を役割別に作り、それぞれに名前を付けて社内に配りました。結果はどうだったか。従業員は「この質問はどのAIに聞くんだっけ」を覚えなければならなくなり、部門をまたぐ仕事はAIの間で分断されました。
そこで4体を廃止し、窓口が1つのAI（Pinecone）に統合しました。統合後は600人以上が使い、社内のコード変更の70%がこのAI経由で作られるまで定着しています。
役割別エージェントが行き詰まる4つの理由
1〜3はSierraが実際に体験した問題、4は窓口を分けた構成の構造上の帰結です。
1. 「どのAIに聞くか」を人間が覚えさせられる
役割別に並べると、AIの守備範囲を全員が記憶する必要が生まれます。これは本来ツール側が吸収すべき複雑さを、利用者に押し付けている状態です。使い分けを覚える負担は、「使われなくなる理由」の1つになりやすいものです。
2. 大事な仕事は部門の「中」ではなく「間」で起きる
例えば新商品を1つ出す仕事は、開発・営業・マーケ・法務・経理をまたいで流れます。部門が存在する理由の1つは「1人では仕事を全部こなせない」という人間側の制約です。AIはこの制約が薄く、データや権限の条件さえ整えば、最初から最後まで通しで仕事を処理できます。それを部門で切るのは、人間の組織図をわざわざAIに逆輸入する設計です。
3. AIの引き継ぎで仕事の文脈が切れる
単一エージェントなら、質問から成果物まで1つの会話でつながります。役割別だとAIからAIへの受け渡しが発生し、そこで経緯や前提が失われがちです。人間の部門間で起きる「言った言わない」のAI版だと考えてください。
4. 改善が全社に波及しない
窓口が1つなら、AIへの改善は全部門が同時に恩恵を受けます。役割別は1体ずつ育てることになり、同じ投資で得られる効果が分散します。
「専門性が出ないのでは？」への答え
ここでよくある反論が「1つのAIに全部やらせたら、器用貧乏にならないか」です。
答えは、単一にするのは利用者から見た窓口であって、中身まで1つにする話ではない、です。Sierraも内部では、仕事の種類ごとに最適なAIモデルへ処理を振り分けています。専門性は窓口を分けることではなく、中の道具（業務手順書・データ接続・チェックリスト）で持たせます。
「オーケストレーターを立てれば役割別でも同じでは？」
もう1つ、鋭い反論があります。「振り分け役のAI（オーケストレーター）を先頭に置いて、質問を営業AI・経理AIに割り振れば、利用者から見れば窓口は1つ。単一エージェントと同じことでは？」。
半分正しいです。窓口を1つにして振り分けを機械にやらせた時点で、「人間が使い分けを覚える」という一番の問題は消えます。その構成はもう、役割別というより単一エージェント側の設計です。
それでも「部門単位の役割AIに割り振る」形には、残る問題が2つあります。
1つ目は、文脈の分断が内部に残ることです。部門をまたぐ仕事では、オーケストレーターが仕事を切り刻んで営業AIへ渡し、結果を受け取って経理AIへ渡すことになります。受け渡しのたびに「なぜこの判断をしたか」の経緯が要約され、削れていきます。Sierraが統合後に採った形は「1つの脳が仕事の文脈を最初から最後まで持ったまま、必要な道具やモデルを切り替える」でした。分けたのは頭ではなく手足です。
2つ目は、育てる対象が分散したままなことです。役割AIごとに指示や知識を別々に改善する構造は変わらないので、投資効率の問題は残ります。
見分けるための問いはこうです。「分けたものの間で、仕事の文脈を持ち回る必要があるか？」。持ち回るなら、それは1つの脳に道具を持たせるべき仕事です。互いに独立して完結するなら、分けて構いません。次の節の「責務で分ける」は、まさに独立して完結する分け方の話です。
それでも分けるべき3つの境界線
では何も分けなくてよいのか。そうではありません。分けるべきは「役割」ではなく「責務」です。具体的には次の3つです。
- 作る係と採点する係: AIが作った成果物を、同じAIに自己採点させない。別の評価役を立てて合否を判定させる。作った本人（AI）は自分の前提ごと採点してしまうため、誤りに気づきにくいからです
- 作業場所の分離: 大量の調査を並行で走らせるときは、それぞれの作業文脈を混ぜない。人間でいう「会議室を分ける」に相当します
- 権限と記録の分離: 誰の権限で動いたか、何をしたかの記録は、AI本体とは別の層で強制する。AIの善意に任せず、仕組みで縛る必要があります
覚え方は「役割で分けるな、責務で分けろ」。利用者に見えるのは1つの窓口、内部は分業です。
背後にある設計思想：「人間を信頼しないシステム」
ここまでの話には、共通する1本の設計思想があります。KOIYALが自社の製品開発・業務効率化でも、お客様の支援でも大事にしている考え方で、私たちは「人間を信頼しないシステムを組む」と呼んでいます。
誤解のないように補足すると、これは人を疑う話ではありません。人間の記憶・注意力・その日の集中の度合いを、システムの部品にしないという設計原則です。人はミスをする前提で、ミスが成果物に到達しない構造を機械側に持たせます。
「どのAIに聞くかを人間が判断する」役割別構成は、この原則に反しています。人間の記憶を、システムの振り分け装置として使っているからです。
同じことは、AI以前の業務にもたくさんあります。分かりやすいのがファイル管理です。「この種類の書類は、このフォルダのこの階層に、この命名規則で保存する」型のルールは、全員が覚えて守り続けることを前提にしています。守れない人が悪いのではなく、人間の記憶に依存した設計が悪い。人間を信頼しない設計にするなら、こうなります。
- 出力側: 誰がどんな意識で書いても、同じフォーマットでアウトプットが出る（フォーマットは書き手でなく仕組みが保証する）
- 保存側: どんな形式で放り込まれても、同じ形式に変換されて保存される
- 入口: 「ここにこういうフォルダがあって」ではなく、アップロード先は全部ここ、の一本化。仕分けは機械の仕事
以前はこの理想に限界がありました。RPAに代表される従来の自動化は「このパターンならこの処理」を人間が事前に定義する方式で、例外に弱かった。だから結局、人間側がシステムに合わせて正確に操作する必要があり、覚えることはむしろ増えました。
生成AIで変わったのはここです。「これはどのパターンか」の判断そのものをAIができるようになったため、例外処理を機械側に置けるようになりました。その結果、人間のワークフローは既存のまま・できる限りシンプルに保ち、複雑さを全部AI側へ寄せる設計が現実になっています。
単一エージェントは、この思想のAI版です。「どこに聞くか」「どう頼むか」の判断を人間から取り除き、窓口を1つにする。役割別エージェントへの違和感の正体は、せっかくAIを入れるのに、人間の記憶に依存する部品を新しく増やしている点にあります。
注意点：会社の規模と段階によります
正直に書きます。この話にも前提があります。
- 最初の1体すら定着していない段階なら、構成の議論は早い: まず1人の1業務で成功例を作る方が先です
- セキュリティ要件が部門で大きく違う場合: 窓口は1つでも、アクセスできるデータの範囲は人・部門ごとに制御が必要です。Sierraもこの部分は専用の仕組み（全操作の権限チェックと監査記録）を作り込んでいます
- 外販のAIサービスは別の話: この記事は「社内向けAI」の設計論です。顧客に売るAI製品の構成は、また別の判断になります
KOIYALの見解
私たちは自社の業務基盤も同じ思想で運用しています。窓口はAIとの対話1本で、その内側に手順書・チェックリスト・独立した評価役を分業させる構成です。役割別に「ブログAI」「広告AI」を並べる構成は取っていません。実際、この記事の下書きも「記事にして」という1つの指示から、執筆・文章チェック・別AIによる採点までが内部で分業されて作られています。書き手がどんな意識の日でも、同じ品質ゲートを通ってから外に出る。前の節で書いた「人間を信頼しないシステム」を、自社で毎日回しているということです。
社内AI導入の計画段階で「部門ごとにAIを作る」ロードマップを描いている会社は、一度立ち止まる価値があります。プロが自社で試して失敗した構成を、後追いする必要はありません。
実務への一言: 導入計画書に「◯◯部門向けAI」の箱が3つ以上並んでいたら、それを「1つの窓口＋部門ごとのデータ接続と手順書」に描き直せないか検討してみてください。作るものは減り、届く範囲は広がります。
KOIYALの法人AI研修では、この設計判断を含めた「定着する社内AI」の導入計画づくりを扱っています。計画段階での壁打ち相談も受け付けています。