AIビジネス

Perplexity「Computer」登場!マルチエージェント時代の業務設計と責任分界

記事バナー画像

ざっくりまとめ

  • Perplexityが2026年2月に発表した「Computer」は、AIエージェントが別のAIエージェントに仕事を割り振る"マルチエージェント調整役"として設計された新サービスだ
  • OpenAIの「Operator」的アプローチより抑制的な設計を志向しており、人間が承認・監督に介在できる余地を残している点が企業導入の観点で注目される
  • マルチエージェント時代に管理職・企画職が押さえるべき「委任・監督・責任分界」の実務設計フレームを整理する

「AIがAIに仕事を振る」とは、何が起きているのか

従来のAIアシスタントは一対一だった。人間がプロンプトを入れ、AIが返す。だがComputerは違う。Perplexityが2026年2月に発表したこのエージェントは、タスクを受け取ったあと、自分で実行するのではなく他のAIエージェントに分解・委任する「調整役」として動く。

たとえばリサーチ、文書作成、データ取得という三つの工程があるとする。Computerはそれぞれを専門のサブエージェントに振り分け、結果を統合する。人間は最初の指示と最後の成果物だけを見ればいい——理論上は。

ただし「理論上は」という留保は重要だ。実務では中間の工程が失敗したとき、誰が検知し、誰が修正し、誰が責任を取るかが設計されていなければ、自動化は単なる「見えないカオス」になる。

Computerが「安全寄り」を標榜する意味

報道によると、PerplexityはComputerをOpenAIの「Operator」的コンセプトと比較しつつ、より抑制的な設計だと位置づけている。具体的には、エージェントが自律的に取れるアクションの範囲を絞り、人間が介在できるポイントを意図的に残す方針だ。

これは技術的な謙虚さではなく、企業導入の現実を見越した判断だ。完全自律のエージェントは「何でもできる」ように見えて、失敗時の追跡が極めて困難になる。承認ポイントを設けることで、ログが残り、人間の判断が記録され、監査に耐えられる設計になる。

日本の企業文化との相性という観点でも、「承認フローが残る」設計は現実的だ。稟議文化のある組織では、AIが完全自律で動くことへの心理的抵抗が強い。Computerのアプローチは、その抵抗を技術で押し切るのではなく、既存の承認構造に接続する余地を残している。

管理職が設計すべき「三つの分界点」

マルチエージェントを業務に組み込む際、現場の混乱は多くの場合、設計の曖昧さから生まれる。Computerのような調整エージェントを導入する前に、以下の三点を明文化しておく必要がある。

委任の粒度——どこまで任せるか

「リサーチを頼む」では粒度が粗すぎる。どのソースを使うか、何文字にまとめるか、引用の扱いはどうするか——こうした判断をエージェントに委ねるなら、その裁量範囲を事前に定義しなければならない。定義がないと、エージェントは「もっともらしい選択」をするが、それが社内ルールや法的制約と衝突したとき誰も気づかない。

監督の頻度——いつ人間が介在するか

全ステップを人間が確認するなら自動化の意味は薄い。かといってゼロ介入では制御を失う。現実的な設計は「例外トリガー型」だ。エージェントが想定外の判断をしたとき、コスト・時間・品質が閾値を超えたとき——そのタイミングだけ人間にアラートが飛ぶ仕組みを作る。

責任の帰属——失敗したとき誰が答えるか

これが最も見落とされやすい。AIエージェントは責任を取れない。エラーが起きたとき、それを承認した人間、設計した人間、運用を委託した部門——そのどこに責任が帰属するかを、導入前に書面で合意しておくことが不可欠だ。曖昧なままにすると、失敗時に「AIのせい」という無責任な結論だけが残る。

マルチエージェント業務設計の責任分界フレーム
委任・監督・責任分界の設計チェックリスト 委任の粒度 □ 裁量範囲を文書化したか □ 使用可能ソースを指定したか □ 出力フォーマットを定義したか □ 法的・社内制約を明示したか □ 禁止アクションを列挙したか ポイント 粒度が粗いと 「もっともらしい選択」が 社内ルールと衝突しても 誰も気づかない 監督の頻度 □ 例外トリガーを設定したか □ コスト閾値を決めたか □ 時間超過アラートを設けたか □ 品質チェックタイミングを明示 □ ログ保存ルールを策定したか ポイント 全ステップ確認は 自動化を無意味にする。 「例外トリガー型」が 現実解 責任の帰属 □ 承認者を役職で明記したか □ 設計者の責任範囲を定義 □ 運用委託部門を書面合意 □ 失敗時のエスカレーション先 □ 事後レビュープロセスを策定 最重要 AIは責任を取れない。 失敗時の帰属先を 導入前に書面合意 しておくことが必須 委任・監督・責任 設計チェックリスト 委任の粒度 □ 裁量範囲を文書化したか □ 使用可能ソースを指定したか □ 出力フォーマットを定義したか □ 法的・社内制約を明示したか □ 禁止アクションを列挙したか ▶ 粒度が粗いと社内ルール違反に誰も気づかない 監督の頻度 □ 例外トリガーを設定したか □ コスト・時間の閾値を決めたか □ 品質チェックタイミングを明示 □ ログ保存ルールを策定したか □ アラート通知先を設定したか ▶ 全確認は非効率。例外トリガー型が現実解 責任の帰属(最重要) □ 承認者を役職で明記したか □ 設計者の責任範囲を定義 □ 運用委託部門を書面合意 □ 失敗時のエスカレーション先 □ 事後レビュープロセスを策定 ▶ AIは責任を取れない。導入前に書面合意が必須
マルチエージェント導入前に三つの分界点を書面化することで、失敗時の「AIのせい」という無責任な結論を防ぐ

「自律性の幻想」に騙されないために

マルチエージェントの最大のリスクは、自動化が進むほど人間の関与が薄れ、問題が起きたときに誰も全体像を把握していない状態になることだ。Computerのような調整エージェントは、この問題を解決するのではなく、むしろ一段複雑にする可能性がある。

調整役のエージェントがサブエージェントに誤った指示を出した場合、その誤りは下流の全工程に伝播する。人間が最終成果物しか見ていなければ、問題の根本がどこにあったか追跡できない。自律性の高さは、ログと可視化の設計が追いついていない限り、リスクの高さと同義だ。

実務での対策は一つ。「エージェントが何をしたか」ではなく「エージェントがなぜその判断をしたか」を記録できる設計にすることだ。決定の理由が残らないシステムは、監査にも改善にも使えない。

KPIをどう設定するか——測れないものは管理できない

挿絵

マルチエージェントの導入効果を測定しようとすると、多くの組織が「体感として速くなった」で止まる。これでは次の投資判断ができない。

測定すべき指標は三層に分かれる。処理速度(タスク完了までの時間)、精度(人間による修正が必要だった割合)、そしてコスト(API費用+人間の介在コスト)だ。この三つを導入前後で比較しなければ、投資対効果は永遠に「感覚値」のままになる。

特に見落とされやすいのが「人間の介在コスト」だ。エージェントが失敗するたびに上位者が対応しているなら、その工数を計上しなければ自動化のコスト削減効果は過大評価になる。Computerのような設計が「承認ポイントを残す」としている以上、その承認に要する時間も測定対象に含めるべきだ。

まとめ

Computerが示したのは「AIがAIを管理する時代の入口」だ。だがその入口を安全に通るための設計——委任の粒度、監督の頻度、責任の帰属——は、AIが自動でやってくれるものではない。人間が事前に決める仕事だ。

明日できる一手は、自社の既存業務フローの中で「エージェントに任せられそうな工程」を一つ選び、その工程の裁量範囲・失敗時の連絡先・成果物の品質基準を一枚の紙に書き出すことだ。その紙がなければ、どんな高度なエージェントを導入しても、責任の所在は霧の中に消える。