エージェントに17役職の組織図を持たせて8ヶ月動かしたら、割り当ての98.3%が1役職に集中した

複数のAIエージェントを8ヶ月運用した結果、組織図と実際の割り当てが大きく食い違っていた。17役職を定義したが、572件の割り当ての98.3%が1役職に集中し、14役職は0件のままだった。この偏りは時間とともに解けず、5日前の集計でも比率は変わらなかった。問題は役職の定義ではなく、仕事の入口にあった。仕事は自由記述テキストで1本のキューに投入される。割り当て側から見ると、型が無い仕事は「何でもできる役職」に最も適合する。結果、能力の広い1役職が全部を吸い込み、特定の役職を対象とした仕事の発生経路がどこにも無いから、その役職は永遠に0件で終わる。

この事例の重要な指摘は「分岐は出口ではなく入口で決まる」ということだ。組織図は美しく見える。役職を多く定義すれば多く分かれるだろうと思うのは自然だ。だが実際には、入力される仕事の型が決まっていなければ、出口をいくら細かく割っても流れは分かれない。この構造は人間の組織でも同じだが、人間の職場では「なんとなくあの人に集まっている」で曖昧に終わる。ログを数字で見るから、98.3%という残酷さが浮き彫りになるのだ。複数のAIエージェントを導入しようとする企業は、役職設計の前に、実際に発生する仕事の分類を先に観測すべき。仕事の型が出そろってから後付けで役職に対応させる順序が正しい。

中小企業がAIエージェント基盤を導入するときの教訓は明確だ。ペルソナや役職を先に凝らず、最初の3ヶ月は仕事がどう発生しているかを記録に取ること。その上で「これらの仕事は何種類に分かれるか」を観測して、初めて役職分け設計を始める。組織図を先に作ると、使われない役職が必ず出現する。その無駄を減らすには、設計の順序が重要だ。ただしエスカレーション経路の配送失敗率が15.4%だったことも同じ運用ログから判明している。「送った側」と「届いた側」の記録は別に取り、配送状況を監視する警報を監視対象と同じ経路に置かないことも、複数エージェント運用の必須条件だ。