AIエージェント比較｜5類型の早見表と「半年後に誰が面倒を見るか」で選ぶ方法

「AIエージェントを入れたいのですが、どこに頼めばいいのか分かりません」——導入先を探し始めた担当者から、いちばんよく出てくる言葉です。

AIエージェント（指示に応じて、次の作業を自ら選んで進めるソフトウェア）を業務に導入する会社は、ここ数年で増えています。ところが、どこに頼むかを決める段になると、多くの担当者が導入先を決められなくなります。

候補が多すぎることが理由ではありません。候補が、そもそも比べられる形になっていないことが理由です。大手クラウド事業者が売っている、エージェントを動かすための基盤。日ごろ使っている業務ソフトに、追加機能として付いてくるもの。この2つが、同じ「AIエージェント」という言葉で並んでいます。そこに、エンジニアが自分で組み立てるための開発部品と、対象業務を決めるところから一緒に事業を作る会社まで混ざります。

そのうえ、比較サイトを開くと表が出てきます。ただ、その表の列は、たいてい「対応チャネル（チャットやメールなど、エージェントを出せる窓口）の数」や「日本語に対応しているか」です。実際に導入の承認を得る決裁の場で問われるのは、そこではありません。問われるのは、「AIエージェントを入れたあと、半年後に誰が面倒を見るのか」です。

たとえば、店舗のシフト表を作るソフトを、月額課金で売っている会社を考えます。契約者のうち解約した割合である解約率が下がらず、解約しそうな顧客を先に見つけて手を打つエージェントを作りたい。この種の相談は増えています。ただし、この会社が選ぶべき導入先と、何十件ものエージェントを全社の部署に配りたい大企業が選ぶべき導入先は、まったく異なります。

そこで本記事では、AIエージェントの導入先を5つの類型に分けて比較します。各社の記述は、それぞれの製品ドキュメントなど公開されている一次情報に基づく整理です。優劣を断定するものではありません。

なお、本記事は、アルチェコ（ARCHECO）という会社が運営する媒体に載っています。5類型のうち最後の1つは、そのアルチェコ自身が属する類型にあたります。手前味噌を承知で書く箇所があるので、先に明かしておきます。今日は、この5類型を強い軸と得意フェーズで並べ、判断が割れたときに使える軸を1つ置く、という話をしていこうと思います。

AIエージェントの比較が成立しない理由は、同じ土俵に載っていないこと

比較の前に、言葉を揃えます。AIエージェントとは、指示と手持ちの道具をもとに、次に何をするかを自分で決めて手順を進めるソフトウェアです。あらかじめ書かれた分岐をなぞるだけの自動化とは、この一点で違います。

ところが、この言葉が指すものは、売る会社の立場で大きくずれます。ある会社にとっては「業務ソフトの画面に住んでいる担当者の相棒」です。別の会社にとっては「クラウドの上でエージェントを動かす基盤そのもの」になります。さらに別の会社にとっては「開発者が組み立てるための部品」を意味します。

だから、値段の単位も、納品されるものも揃いません。利用者の人数に応じたライセンス費で請求する会社。エージェントが動いた時間で請求する会社。支援に入った人の作業量、いわゆる人月（人数と月数を掛け合わせた作業量）で請求する会社。この3つが、同じ言葉のもとに並んでいます。同じ表に置いて見かけの価格が安い導入先を選ぶと、あとで必ず破綻します。

そこで、比べる前に5つの類型に分けます。分け方の基準は「何を売っているか」の1点です。

【早見表】AIエージェントを比較する｜5類型と代表企業

まず全体像を置きます。各類型の代表企業と、そこから出てくる成果物を一覧にしました。他社の記述は公開情報の範囲です。最新の内容は各社の公式ドキュメントで確認してください。

類型	代表的な企業・製品	何を売っているか	代表的な成果物
①業務スイート組み込み型	Microsoft Copilot Studio／Salesforce Agentforce	社内のデータと権限に、つながった状態	業務ソフトの画面に住むエージェント。チャットツールや顧客管理システム（CRM）の中で動きます。
②業務プロセス統制型	ServiceNow AI Agent Studio／UiPath Maestro	承認と証跡（誰がいつ何をしたかの記録）	承認を挟んだ業務の流れ。監査に出せる記録が残ります。
③クラウド基盤型	Amazon Bedrock AgentCore／Google ADK／IBM watsonx Orchestrate	エージェントを動かす基盤と、別の環境へ移せる可搬性	何十件を同じ基盤の上で動かせます。権限と監視が共通化されます。
④開発フレームワーク型	LangGraph／OpenAI Agents SDK／Claude Agent SDK	エンジニアが組むための開発部品	自社仕様のエージェント本体。ソースコードが資産として残ります。
⑤事業共創型	アルチェコなど、事業会社と組んで事業を立ち上げるスタジオ	何を任せるかの決定と、最初の一件	対象業務の選定から、動くところまでの実物が出ます。

表を見て「うちはどれに当たるのだろう」と迷ったなら、それが正常です。1つの案件に、業務プロセス統制型とクラウド基盤型のように、複数の類型がまたがることも普通に起きます。まずは、それぞれの類型が何で勝っているかを見ていきます。

【早見表】強い軸（◎）・得意フェーズ・向いている会社で比較する

大切なのは優劣ではありません。5類型それぞれに、ほかにはない「◎」があります。◎は各類型の最大の強みを示すものです。勝ち負けの断定ではありません。

類型	強い軸（◎）	得意フェーズ	向いている会社
①業務スイート組み込み型	◎ 立ち上がりの速さ	最初の数件	そのソフトを全社で使い切っている会社に向きます。
②業務プロセス統制型	◎ 統制と証跡の残り方	実際の業務で使う段階・拡大期	あとから経緯を説明する義務がある会社に向きます。
③クラウド基盤型	◎ 規模と可搬性	全社展開	何十件を同時に動かす前提がある会社に向きます。
④開発フレームワーク型	◎ 作り込みの自由度	自社で開発・運用する内製化	作れる人が社内にいる会社に向きます。
⑤事業共創型	◎ 何を任せるかの決定	構想〜最初の一件	まだ対象業務が決まっていない会社に向きます。

最後に効くのは、たいてい「作ったものを、半年後も誰かが直し続けられるか」です。この軸を外すと、どの類型を選んでも導入後の修正を続けられません。ここからは、なぜそう言えるのかまで含めて、一類型ずつ見ていきます。

比較の物差し｜導入先を見分ける6つの軸

早見表を読み解くための物差しを、6つ置きます。製品名を比べる前に、この6つで自社の位置を決めるほうが速く終わります。

軸1は「エージェントに何の業務を任せるか」が決まっているかどうかです。決まっていれば、あとは製品どうしの比べ合いになります。決まっていなければ、製品を比べる前に、任せる業務を決めるところへ戻ることになります。ここが最初の分岐です。

軸2は「エージェントに読ませたいデータが、どこに置かれているか」。1つの業務ソフトの中に揃っているのか、会社の主要業務を支える基幹システムや表計算に散っているのか。散っているほど、そのデータをつなぐ工数が前に出ます。

軸3は「同時に何件の業務をエージェントに任せるか」。1件から3件で試す段階と、全社で何十件を運用する段階では、必要な基盤がまったく違います。件数を先に決めないまま製品を見ると、必ず過剰か過小になります。

軸4は「誰が承認し、どこで止まったか」を後から説明する義務があるかどうか。義務があるなら、記録は追加機能ではなく前提条件になります。軸5は「エージェントを作れる人が社内にいるか」。開発部品そのものは無料で公開されていても、それを組み上げる人は無料ではありません。

そして軸6が「半年後に誰が面倒を見るか」です。これだけは最後まで残ります。

①業務スイート組み込み型｜データと権限が、すでに中にある

まず、複数の業務機能をまとめたソフトにエージェントを組み込む、業務スイート組み込み型から見ます。Microsoft Copilot Studio や Salesforce Agentforce に代表されるこの領域の統合力には、確かな定評があります。

この類型で確かめることは2つです。ひとつは、日ごろ使っている業務ソフトのデータと権限に、どこまで最初からつながっているか。もうひとつは、作ったあとに動かし続けるための機能が、製品として付いてくるかどうかです。

Microsoft Copilot Studio は、製品ドキュメントの言い方では「エージェントとワークフローを作って管理するための、ローコードのスタジオ」です。ローコードとは、少ないプログラミングで開発する方法です。作ったものは Microsoft Teams、Microsoft 365 Copilot、自社サイト、モバイルアプリへ公開できます。つまり、社員がすでに毎日開いている画面の中に出せます。

作るものは用途で分かれています。人と会話しながら仕事をこなす「エージェント」、決まった手順を並べて組む「ワークフロー」、エージェントから道具として呼び出せる「エージェントフロー」の3つです。裏を返せば、任せる業務が決まっていないと、どれを選ぶかも決められません。

運用のための機能も用意されています。会話がどうなったかを追う分析。想定問答を流して答えの良し悪しを採点する「評価」。社内でいくつのエージェントが動いているかを棚卸しする管理機能。どれも、作ったあとに使う機能です。

Salesforce Agentforce も同じ思想です。1つのエージェントの中を仕事の領域ごとに区切り、その単位を開発者向けドキュメントでは「サブエージェント」と呼びます。区切りの中で実際の作業をこなすのが「アクション」で、「エージェントがタスクを実行しデータとやり取りするための構成要素」と書かれています。試す機能も製品として付いてきて、管理画面から流す Testing Center と、外部のプログラムから呼び出す Testing API（ソフトウェア同士が機能を呼び出すための接続口）が使えます。

さらに2025年10月には、AIの判断に頼らず手順どおりに必ず通したい場面のために、その手順を書き下す Agent Script が発表されました。決まった手順とAIの判断を混ぜて動かす「ハイブリッド推論」も、同時に発表されています。つまり、AIに任せきりにできない業務が社内にある、という前提で作られています。

強いのは、つなぎ込みが最初から済んでいることです。エージェントを動かすとき、いちばん重い工程は外部データと権限のつなぎ込みです。この類型は、そこが終わっています。

弱いのは、そのソフトの外に出た瞬間です。基幹システムの提供会社が別だったり、現場が独自の表計算で回していたりすると、途端に手が止まります。

②業務プロセス統制型｜どこで止まったかが、記録に残る

次に、業務プロセス統制型です。代表するのは、社内の申請や問い合わせを回すクラウドサービスの ServiceNow と、事務作業の自動化から出発した UiPath です。この2社の統制の作り込みには、確かな定評があります。

この類型で確かめることも2つです。承認を業務の流れのどこに挟めるか。そして、止まった場所と理由が、あとで人に見せられる形で残るかどうかです。

ServiceNow の AI Agent Studio は、エージェントを作って運ぶための作業画面です。扱う範囲は広い。作って、担当させる分野を決め、使わせる道具と情報を足す。誰が触れるかを制限し、試し、どの窓口に出し、最後に使うのをやめるところまでが、この1か所に収まっています。

複数のエージェントを束ねる AI Agent Orchestrator には、経路が2つあります。自社で作ったエージェントを部下として呼び出す経路と、他社の製品で作られたエージェントを外から呼び出す経路です。後者に使われるのが「Agent2Agent」という、エージェント同士がやり取りするための共通の決まりごとです。

安全のための作り込みも具体的です。ドキュメントに挙げられているのは、不適切な発言を出させない「AI Guardian」と、想定外の動きをしたときに強制的に止める「キルスイッチ」。加えて、役職ごとに見せる情報を絞る機能と、誰が何に触れてよいかを一覧で決めるアクセス制御リスト（ACL）です。動かしたあとの様子は、AI Agent Analytics という集計画面で追えます。

並んでいる機能名は多いのですが、答えている問いは2つに絞れます。「暴走したときに止められるのか」と「見せてよい人にだけ見せているか」です。監査を受ける会社が最初に聞かれるのも、この2つです。

UiPath は、事務作業の自動化という別の入口から出発して、同じ統制にたどり着いています。業務の流れを設計して動かす製品が Maestro です。流れを書き表す方法は3つ。業務の手順を箱と矢印の図で描く国際的な記法の BPMN、エンジニアが処理の順序として書き下す Flow、手順を事前に決めきれない仕事を扱う「ケースマネジメント」です。エージェントは、BPMN で描いた図の中に1つの作業として置かれます。

エージェントを作る人向けの入口も用意されていて、Agent Builder は資料では「UiPath Studio 上の、ドラッグ&ドロップでエージェントを構成するキャンバス」と説明されています。人が引き取る場所も製品にあります。Action Center が、承認の依頼と例外処理を流れの中に組み込みます。

強いのは、統制と証跡です。誰が承認したか、いつ止まったか、何回やり直したかが、最初から記録に残ります。監査で経緯の説明を求められる業種では、この記録がそのまま材料になります。

弱いのは、決まった流れがない仕事です。何回やり取りすれば終わるのか読めない相談ごとを任せると、うまくはまりません。

③クラウド基盤型｜何十件を、ひとつの基盤の上で運ぶ

3つ目は、クラウド基盤型です。Amazon、Google、IBM に代表されるこの領域の完成度には、確かな定評があります。

この類型で確かめることは、1件ずつの出来ではありません。何十件を同じ規則の上に載せられるか、そして、あとから中身を差し替えられるかどうかです。

先に言葉を2つ決めておきます。「フレームワーク」はエージェントを組み立てるための開発部品。「基盤モデル」は中身で考える役を担うAIモデル本体のこと。どちらも、エージェントを動かす基盤とは別のものを指します。

Amazon Bedrock AgentCore の開発者ガイドには「どのフレームワークとどの基盤モデルを使っても、安全に大規模へ広げられるエージェント基盤」と書かれています。組み立ての部品も、考える役のモデルも、他社製のものを持ち込めるという意味です。

中身は役割ごとに分かれています。実際に動かす Runtime、やり取りを覚えておく Memory、誰として動くかを確かめる Identity。エージェントが使う道具も独立しています。社内にある機能をエージェントから呼べる形に変換する Gateway、動きを記録して後から追いかける Observability、そして道具を呼び出す直前に「この操作は許してよいか」を判定して止める Policy です。

Gateway が変換先にしているのは MCP（Model Context Protocol）という形式です。公式ドキュメントでは「AIアプリケーションを外部システムにつなぐためのオープンソースの標準」と定義されています。比喩も添えられていて、「AIアプリケーションにとってのUSB-Cポートのようなもの」だと書かれています。差し込み口の形をひとつに揃えておけば、どのAIからどの道具にもつながる、という考え方です。

Runtime が受け入れる開発部品も明記されています。CrewAI、LangGraph、LlamaIndex、Google ADK、OpenAI Agents SDK、Strands Agents の6つです。Policy に書く許可の条件は Cedar という専用の言語で記述するので、作った人が辞めたあとも、条件だけを読んで直せます。ここが、あとから差し替えられるかどうかの答えになります。

Google の Agent Development Kit（ADK）は、公式サイトで「信頼できるAIエージェントを企業規模で構築・デバッグ・デプロイするためのオープンソースのフレームワーク」と書かれています。書ける言語は Python、TypeScript、Go、Java、Kotlin の5つ。中身のAIモデルは「ほぼどんな生成AIモデルでも動く」とされます。

IBM watsonx Orchestrate は、一から作る前に既製のエージェントから選ぶ道を用意しています。Agent Catalog に並ぶのは、IBM とパートナー企業が作った150件を超えるエージェントと道具です。どの開発部品で組んだものでも受け入れ、つなぎ込みには MCP が使われます。

強いのは、規模と可搬性です。モデルもフレームワークも差し替えられ、権限と監視はエージェント基盤にまとめられます。全社で何十件も動かす前提なら、この類型なしでは運用が破綻します。

弱いのは、最初の1件です。基盤を整える工数が先に来るので、1業務だけ試したい段階では明らかに重すぎます。

④開発フレームワーク型｜決まった処理と、AIの判断を混ぜて作り込む

4つ目は、開発フレームワーク型です。エンジニアがプログラムを書いてエージェントを組み上げるための開発部品を指します。LangGraph や、各社が配っている開発キット（SDK）に代表されるこの領域の設計の柔軟さには、確かな定評があります。

この類型で確かめることは、機能の多さではありません。組める人が社内にいるか、そして、作ったものを別の場所へ持ち出せるかどうかです。

LangGraph は、公式ドキュメントの言い方では「長時間動く、状態を持つエージェントを構築・管理・デプロイするための低レベルのオーケストレーション基盤」です。ここでいう状態とは、処理の進み具合や、それまでに保持した情報のことです。複数の処理を順番と条件を決めて動かすことを「オーケストレーション」と呼び、出来合いの完成品ではなく細かい部品から自分で組む形を低レベルと呼びます。

特徴は4つ挙げられています。途中で障害が起きても「中断した場所から再開できる」実行。「任意の時点でエージェントの状態を人が確認して書き換えられる」という人の割り込み。短期の記憶と長期の記憶を、どちらも持てること。

4つ目が、公式ドキュメントの言い方で「決定的な処理とLLMが判断する処理を、ひとつのグラフの中で混ぜられる」ことです。ここでいうグラフは、処理の順序や分岐を表す構造です。何度動かしても必ず同じ結果になる決まった処理と、大規模言語モデル（LLM）にその場で考えさせる処理を指します。

手順を固めたいところは固め、判断が要るところだけAIに渡す。そういう組み方ができます。利用企業として Klarna、Uber、J.P. Morgan の名が挙がっています。

OpenAI Agents SDK は、もっと小さな要素でできています。公式ドキュメントによれば、中心にあるのは3つだけです。指示と道具を持った「エージェント」、別のエージェントへ仕事を渡す「ハンドオフ」、受け取った依頼と返す答えを検査してはじく「ガードレール」。これに、どの判断を経てその答えに至ったかを後から追える「トレーシング」が加わります。

Claude Agent SDK も、できることの一覧が公開されています。範囲を絞った下請けの作業を切り出し、別のエージェントに任せる「サブエージェント」。どの道具を黙って実行させ、どれに人の承認を求めるかを決める「パーミッション」。なお、先に出てきた Salesforce の「サブエージェント」が担当分野の区切りを指すのに対し、こちらは下請けに出す作業そのものを指します。同じ語でも、製品によって指すものが違います。

この類型を支えているのが、クラウド基盤型のところで触れた MCP です。Visual Studio Code や Cursor といった、エンジニアが日常的に使う開発用ソフトも同じ形式に対応しています。道具の接続だけは、もう会社をまたいで共通化しつつある。自前で組んだエージェントでも、つなぎ込みを一から書かずに済むということです。

強いのは、作り込みの自由度と可搬性です。特定の製品に縛られず、モデルもデータの持ち方も自分で決められます。作ったものは、そのままソースコードとして資産に残ります。

弱いのは、作れる人がいないと1行も進まないことです。部品は無料でも、組む人は無料ではありません。

⑤事業共創型｜何を任せるかが決まっていない段階から入る

最後に、5つ目の類型です。手前味噌を承知で書きます。本記事の発信元であるアルチェコが属するのが、ここになります。

事業共創型は、事業を持っている会社と組む形です。何をエージェントに任せるかを決めるところから一緒に入り、動くところまでを作ります。ここまでに見てきた4つの類型は、いずれも「作るものが決まっている」ことを前提にしています。

作るものが決まっていない段階では、製品の優劣を比べようがありません。この類型が引き受けるのは、製品を比べる前に、エージェントに任せる業務を決める工程です。

アルチェコは、利用者の体験を設計するUXデザインとAI開発と新規事業開発を組み合わせた事業共創スタジオです。強みは3つに絞ります。1つ目は、対象業務の選定から実物までを同じチーム体制で通すこと。2つ目は、指示を出すと設計と実装を自分で進めるAI開発ツールを、自社で持っていることです。通常6か月と言われる MVP（最小限の機能だけを載せた試作版）を、最短数週間で立ち上げられます。3つ目は、受託だけでなく、成果に応じて報酬が決まる成果報酬型や共同事業といった契約の形を選べることです。

正直に書けば、この類型が向かない場面のほうが多いかもしれません。作るものが決まっていて、社内に作れる人がいるなら、開発フレームワーク型が最も速い。全社展開が決まっているならクラウド基盤型です。監査対応が主目的なら、業務プロセス統制型以外にありません。弱いのは規模で、何十件を同時に運用する話には向きません。

強いのは、何をエージェントに任せるかを決めることです。「エージェントを入れたい。ただ、何を任せればいいか分からない」という段階で、業務内容を一緒に整理します。そのうえで、最初の一件を実際に動かすところまで持っていく。この「対象業務を決める仕事」の担当者が不在になりやすい理由は、製品を売る会社にとって、そこが商材にならないからです。

決めきれないときの共通の軸｜「半年後、誰が面倒を見るか」

ここまで並べても、候補は2つか3つ残ります。そのときに使う問いは1つだけです。半年後にそのエージェントが動かなくなったとき、誰が直すのか。

AIエージェントは、作った瞬間がいちばん賢い状態です。そのあと、実際の業務が変わっていきます。「取扱商品が増える」「承認者が異動する」「法令が変わる」。3か月に1回でもこれが起きれば、そのたびに手を入れる人が要ります。

この問いが効く理由は、各社の製品ドキュメントが、そろってこの点を詳しく説明しているからです。Copilot Studio には、答えの良し悪しを採点する評価と、社内のエージェントを棚卸しする機能があります。ServiceNow には動きを集計する画面と強制停止のキルスイッチがあり、AgentCore には動きを記録して追いかける Observability があります。どれも「作ったあとに使う機能」です。エージェントを作る機能の説明より、導入後の運用・改善に使う機能の説明のほうが多くなっています。

冒頭に挙げた、店舗のシフト表を作るソフトを月額で売っている会社で言えば、答えははっきりします。解約しそうな顧客を先に見つけるエージェントは、料金プランを変えるたびに作り直しになります。手を入れるのは、営業でも情報システム部門でもなく、料金プランを決めている事業側の担当者です。だとすれば、「その担当者が読めて直せる形で残ること」が、機能の多さより優先されます。

役割別｜立場が変われば、見るべき行も変わる

同じ会社の中でも、立場によって正解が変わります。読者がどの立場にいるかで、見るべき類型が入れ替わります。

立場	抱えている課題	見るべき類型
情報システム部門	全社の運用と権限を引き受ける	③クラウド基盤型を先に敷き、その上に業務スイート組み込み型と業務プロセス統制型を載せます。
事業部門の担当者	自部門だけで完結させたい	①業務スイート組み込み型。使っているソフトの中で閉じます。
監査・リスク管理の担当	あとから経緯を説明する必要がある	②業務プロセス統制型。証跡が製品として用意されています。
社内に開発者がいるチーム	自社仕様で作り込みたい	④開発フレームワーク型。作ったコードが資産として残ります。
新規事業の担当者	まだ何を任せるか決まっていない	⑤事業共創型で形にしてから、ほかの4類型へ渡します。

たとえば、情報システム部門がクラウド基盤型を選び、事業部門が業務スイート組み込み型を選ぶ。この2つは矛盾しません。むしろ、同じ会社で同時に起きるのが普通です。困るのは、情報システム部門と事業部門が、互いの動きを知らないまま進めた場合だけです。

フェーズ別｜1社で全部を賄う必要はない

類型は、どれか1つを選ぶ話ではありません。順番の話であることが、実際には多くなります。

一般的な進み方はこうです。まずクラウド基盤型を敷き、権限と監視を共通化します。次に開発フレームワーク型で自社仕様に作り込み、コードを資産として残します。そのうえで業務スイート組み込み型と業務プロセス統制型に載せ替え、日々の運用と承認の流れに落とします。ここまでが「作るものが決まっている会社」の道筋です。

一方で、決まっていない会社は、その前でつまずきます。基盤も開発部品も揃っているのに、「何を任せるか」が決まらない。だから最初の一件が動きません。どの類型に載せるかを決めて、最初の一件を実際に形にする——この役割を引き受けるのが事業共創型です。

この比較表に、意図的に入れなかったもの

比較表は、載せた候補より、外した候補のほうが問題になります。だから、表から外した選択肢と、その理由を3つ明示します。

1つ目は、システムの企画から構築までを請け負う大手SIer（システムインテグレーター）と、総合コンサルティングファームです。外した理由は、この2つが5類型のどれとも組める立場にあることです。「どの類型を使うかを決めて発注する側」に回ることが多くなります。

ただし、公平を期して書くなら、事業共創型と重なる部分はあります。何を任せるかが決まっていない段階から入る、という点は同じだからです。違いは座組みの規模と入り口にあります。数十人規模の体制を組み、全社の計画から手をつけるのが大手SIerと総合コンサルティングファーム。対象業務を1つに絞り、最初の一件が動くところまでを少人数で通すのが事業共創型です。全社の計画づくりから始めたいなら、事業共創型ではなく大手SIerや総合コンサルティングファームが正解です。

2つ目は、カスタマーサポートなど特定業務に特化したエージェント製品です。対象業務が合致すれば最も速い選択肢になります。ただし、「その業務そのものを外注する」話になるため、製品の比較とは土俵が変わります。

3つ目は、AIモデルを提供している各社が公開している接続口（API）を、自社のプログラムから直接呼び出して作る方法です。これは外したのではありません。実質が開発フレームワーク型の一部にあたるため、そちらに含めて数えました。

この比較表が自社に有利になっていないかを、3つで確かめる

比較記事は、書いた会社に有利すぎると信頼性を失います。そこで、3つの検査を通しました。

1つ目は、「事業共創型の行を消しても、この表が成立するか」です。成立します。作るものが決まっている案件は、残る4類型だけでほぼ判断できます。事業共創型が要るのは、まだ決まっていない場合に限られます。

2つ目は、「他社が取っている◎が、読者にとって本当に重要な軸か」です。立ち上がりの速さ、統制と証跡、規模と可搬性、作り込みの自由度——いずれも決裁の場で必ず問われます。むしろ事業共創型に置いた◎は、対象業務が決まっている読者には無関係です。

3つ目は、「有力な選択肢を外していないか」です。前の節で、表の外に置いた3つを名指しで書きました。とくに大手SIerと総合コンサルティングファームについては、事業共創型と重なる部分と、そちらを選ぶべき場面まで書いています。

よくある質問（FAQ）

Q. AIエージェントの比較は、何から始めればよいですか

製品名を並べる前に、対象業務を1つに絞ることから始めます。「どの製品がよいか」ではなく「何を任せるか」が先です。任せる業務が決まると、5類型のうち2つか3つに自然に絞られます。

Q. 大手クラウドの基盤と、業務ソフトの機能は、どちらが先ですか

動かす件数で分かれます。1件から3件で試す段階なら、データと権限のつなぎ込みが済んでいる業務スイート組み込み型が速い。「同時に何十件を運用する」前提があるなら、権限と監視を共通化できるクラウド基盤型を先に敷きます。

Q. 内製と外注は、どちらを選ぶべきですか

「半年後に誰が直すか」で決まります。社内にエージェントを作れる人がいるなら、開発フレームワーク型で内製する意味が大きい。作れる人がいないままこの型を選ぶと、「納品された瞬間から誰も触れない資産」になります。

Q. 導入先を1社に絞る必要はありますか

必要はありません。実際の案件では、クラウド基盤の上に開発フレームワークで組んだエージェントを載せ、業務ソフトの画面に出す、という組み合わせが普通に起きます。MCP のような、AIと外部システムをつなぐ共通の形式が広がったことで、組み合わせの手間は下がっています。

まとめ｜優劣ではなく、目的で選ぶ

AIエージェントの導入先には、5つの類型があります。業務スイート組み込み型、業務プロセス統制型、クラウド基盤型、開発フレームワーク型、そして事業共創型です。それぞれに、ほかにはない◎があります。立ち上がりの速さなら業務スイート組み込み型、統制と証跡なら業務プロセス統制型、規模と可搬性ならクラウド基盤型、作り込みの自由度なら開発フレームワーク型——どの類型も、それぞれの目的に合えば有力な選択肢です。

そのうえで、多くの担当者が本当に苦しむのは「どれが優れているか」ではありません。「何を任せるか」と「半年後に誰が面倒を見るか」の2つです。ここが決まっていれば、5類型のうちどれを選んでも大きくは間違えません。逆に、ここが空いたまま製品を比べると、どれだけ丁寧に比較しても決まりません。

手前味噌を承知で、最後にひとつだけ書きます。何を任せるかが決まっていない段階なら、事業共創型は選択肢に入れてよいはずです。ただ、ここまで読んだ人には、もう自社がどの類型に当てはまるかが分かっているはずです。最後に選ぶのは——半年後に誰がそのエージェントを直すのかを、いちばん知っている読者自身です。