AIエージェントの種類と比較｜分類・選び方・メリットと導入手順

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

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

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

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

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

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

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

先に、AIエージェントの種類と比べ方を、教科書どおりに揃えておきます。分類が3種類あることを知らないまま比較表を開くと、列が噛み合わないためです。

AIエージェントとは

AIエージェントとは、目標を与えると、次に何をするかを自分で決めて、道具を使いながら手順を進めるソフトウェアです。人が一手ずつ指示しなくても、状況を読み取り、計画を立て、実行し、結果を見て次の手を選びます。

境目は「誰が次の一手を決めるか」の一点です。人が決めているうちは道具、ソフトウェアが決めているならエージェント。この線引きだけで、後に出てくる分類はすべて説明できます。

生成AI・チャットボットとの違い

生成AIとの違いは、担当する範囲です。同じ大規模言語モデルを使っていても、任される仕事の単位が変わります。

	入力に対して	道具を使うか	終わり方
チャットボット	決められた分岐をなぞる	使わない	想定問答が尽きたら人へ
生成AI	1回の応答を返す	基本は使わない	答えを出したら終わり
AIエージェント	目標を受け取る	使う	目標が満たされるまで続く

実務では「終わり方」がいちばん効きます。生成AIは答えを返して終わるので、間違っていても止まります。エージェントは続くので、途中で誤った判断をすると、その誤りの上に作業が積み上がります。止め方を決めずに動かさないでください。

エージェント型AI（Agentic AI）・RPAとの違い

エージェント型AI（Agentic AI、エージェンティックAI）は、個々のAIエージェントではなく、自分で判断して動く仕組み全体を指す言い方です。複数のエージェントが役割を分けて連携する形も含みます。

RPAは、画面操作やファイル処理をあらかじめ記録した手順どおりに再生する仕組みです。手順が変わると止まるのがRPA、手順を選び直せるのがAIエージェントです。

置き換えではなく、組み合わせが実務解になります。判断はエージェント、確実に同じ結果を出したい操作はRPA。この分担にすると、監査で「なぜこの処理をしたのか」を説明できる範囲が広がります。

AIエージェントが注目されるようになった背景

理由は4つに整理できます。

• モデルが道具を呼べるようになった — 外部のAPIやデータベースを、モデル自身が選んで呼び出せるようになった
• 長い手順を保持できるようになった — 途中経過を記憶し、数十手先まで前提を持ち越せるようになった
• 業務ソフト側が受け口を用意した — 既存の権限とデータの中で動かせる形が増えた
• 人手不足が続いている — 定型作業に人を割けなくなった

3つ目が導入の可否を分けます。技術ではなく「自社のデータと権限に、正規の入口があるか」が先に決まります。入口が無い場合、どれだけ賢いモデルを選んでも、接続を作る工程がそのまま費用になります。

AIエージェントの仕組み｜4つの構成要素

中身は、おおむね次の4つに分解できます。

• 頭脳（推論） — 大規模言語モデル。何をすべきかを決める
• 計画（プランニング） — 目標を、実行できる小さな手順へ割る
• 記憶（メモリ） — 直前のやりとりと、過去の結果を持ち越す
• 道具（ツール／環境） — 検索、社内データベース、業務ソフトのAPI、ファイル操作など、外の世界に触る手段

期待外れの多くは、頭脳ではなく記憶と道具の側で起きます。モデルを上位のものへ替える前に、「必要なデータに届いているか」「前の手順の結果を持ち越せているか」を確認してください。

分類の前に｜AIエージェントの「種類」は3通りの分け方がある

検索して出てくる「種類」は、実は別々の切り口が混ざっています。先に3つを分けておくと、比較表の列が噛み合わない理由がわかります。

分け方	何で分けているか	使いどころ
動き方による分類	判断の高度さ（5〜6種）	実現できることの上限を見積もる
提供形態による分類	誰から、どう買うか	発注先を決める
用途による分類	何の業務に使うか	当てどころを探す

教科書やベンダーの解説が扱っているのは、たいてい1つ目です。ところが発注の場で必要になるのは2つ目です。この記事は3つとも並べたうえで、2つ目を主に扱います。

動き方による分類①｜単純反射型エージェント

いま見えている入力だけを見て、あらかじめ決めた条件と照らして反応します。過去の経緯は持ちません。「在庫が0になったら発注する」のような、条件と対応が1対1で書ける仕事が範囲です。

実務ではRPAや業務ルールとの境目が曖昧になります。ここに当てはまる作業なら、AIを使わないほうが安く、監査もしやすくなります。

動き方による分類②｜モデルベース反射型エージェント

見えていない部分を、内部に持った世界の模型（モデル）で補って判断します。センサーや画面から得られる情報が部分的でも動けるのが違いです。

業務では「システムの現在の状態を推定しながら操作する」場面が該当します。模型が現実とずれると誤作動するので、状態を確認する読み取り処理を必ず挟んでください。

動き方による分類③｜目標ベース型（目的志向型）エージェント

達成したい状態を与えると、そこに至る手順を自分で組み立てます。いま業務で「AIエージェント」と呼ばれているものの多くは、ここです。

与えるべきは手順ではなく、達成条件です。「問い合わせに返信する」ではなく「未回答の問い合わせを0件にする」と置くと、エージェント側が調べる・確認する・返すの順序を選べるようになります。

動き方による分類④｜効用ベース型（有用性ベース）エージェント

目標に届く道が複数あるとき、どれがより望ましいかを点数で比べて選びます。速さ、費用、確実さのように、両立しない条件が混ざる仕事で使います。

点数の付け方が、そのまま経営判断になります。「速さを優先」と言葉で決めるのではなく、1時間の短縮を何円と見るかまで決めないと、選択が安定しません。

動き方による分類⑤｜学習型エージェント

実行した結果の良し悪しを取り込み、次の選び方を更新します。使うほど当たるようになる代わりに、同じ入力に同じ出力を返すとは限らなくなります。

検証が必要な業務では、学習を止める設定を先に確認してください。再現しない仕組みは、不具合が起きたときに原因を切り分けられません。

階層型・協調型とマルチエージェント・システム

1体で完結させず、役割を分けた複数のエージェントを並べる形です。上位が仕事を割り振る階層型、対等に情報を交換する協調型（コラボレーティブ）、それらをまとめてマルチエージェント・システム（MAS）と呼びます。

増やす方向を間違えやすいところです。担当を増やすほど賢くなるわけではなく、受け渡しの回数が増えるぶん、途中で情報が落ちる箇所も増えます。分けるなら、失敗したときに「どこで落ちたか」を記録できる形にしてください。

提供形態による分類｜発注先を決めるのはこの軸

買う立場から見ると、候補は次の5つに分かれます。この記事の後半の比較表は、この軸で並べています。

類型	何を買うことになるか	向いている状況
業務スイート組み込み型	使っている業務ソフトの追加機能	データと権限が、すでにその中にある
業務プロセス統制型	手順と承認を含む仕組み	どこで止まったかを記録に残したい
クラウド基盤型	エージェントを動かす土台	何十件も作って全社に配る
開発フレームワーク型	組み立てるための部品	自社に作れる人がいる
事業共創型	対象業務を決めるところからの伴走	何を任せるかが、まだ決まっていない

汎用型・特化型・システム搭載型・ノーコード型という分け方も、この軸の言い換えです。呼び名が違うだけで、問われているのは「誰が保守を持つか」です。

用途による分類｜何をさせるかで分ける

当てどころを探す段階では、この分け方が実務的です。

• タスク自動化型 — 申請、転記、集計のような定型作業を通しで実行する
• 情報収集・要約型 — 社内外の資料を集め、必要な形に整えて出す
• チャットボット・FAQ対応型 — 問い合わせを受け、調べて返す
• コーディング支援型 — 実装、テスト、修正を担当する

最初の1件は、間違えても取り返せるものから選んでください。情報収集・要約型は出力を人が読んでから使うため、誤りがそのまま外部へ出ません。

AIエージェントを導入するメリット

• 24時間・年中無休で動く — 夜間や休日に届いた依頼を、翌営業日まで滞留させずに処理できる
• 人的ミスが減る — 転記や計算の取り違えが起きにくい。ただし誤りの種類が変わるだけで、0にはなりません
• データ分析による判断支援が速くなる — 分散したデータを集めて整えるまでの時間が縮む
• 定型作業を通しで任せられる — 部分的な自動化と違い、受け取りから完了までを1本で処理できる
• 人件費と労働時間の制約から外れる — 人数を増やさずに件数を増やせる

効果が出るかどうかは、件数で決まります。月に数件しか発生しない作業では、接続と検証にかかる手間を回収できません。まず件数を数えてから、対象を決めてください。

AIエージェントを比較する7つのポイント

比較の観点	確かめること	手を抜くと
機能性	目標を与えて完了まで到達できるか	実演では動くが、自社の例外で止まる
連携範囲	使っている業務ソフトとAPI連携できるか	接続の開発費が、製品費用と別に発生する
セキュリティ	入力データの学習利用、保存先、権限の分離	社外に出せないデータが、確認されないまま流れる
サポート体制	日本語での問い合わせ窓口と応答時間	止まったときに、復旧を待つしかなくなる
自律性のレベル	どこまでを人の承認なしに実行させるか	想定より広い範囲を、勝手に実行される
カスタマイズ性	自社の手順や語彙に合わせられるか	業務のほうを製品に合わせることになる
費用	利用者数か、実行時間か、作業量か	単位が違う見積もりを、同じ表で比べてしまう

最後の1行が、比較でいちばん事故が起きるところです。利用者ライセンス、実行時間、人月。請求の単位が揃っていない見積もりは、金額を並べても意味がありません。件数と稼働時間を仮に置いて、年額に直してから比べてください。

AIエージェントの選び方｜決める順番

順番を変えると、決まらなくなります。

• 1. 導入目的と対象業務を1つに絞る — 何を減らしたいのかを、件数か時間で書く
• 2. データと権限の在り処を確認する — その業務のデータが、どの製品の中にあるか
• 3. 提供形態を決める — 組み込み型か、基盤型か、共創型か
• 4. 運用と保守の担当を決める — 半年後に手を入れるのは、社内か、委託先か
• 5. 費用を年額に直して比べる — 請求の単位を揃える

4番を最後に回すと、選定がやり直しになります。保守を社内で持てないなら、自由度の高い開発フレームワーク型は、そもそも候補から外れます。

無料で試せるか｜無料プランとオープンソース

無料プランやオープンソースの製品もあり、当てどころを探す段階では有効です。ノーコードで組めるものも増えています。

ただし本番で使うときは、次の3点が制約になります。

• 実行回数・接続数の上限で、業務が途中で止まる
• 入力したデータの取り扱いが、有料版と条件が違うことがある
• 障害時の問い合わせ窓口が無い

「無料で検証し、本番は有料へ移す」前提で、移行の費用を先に見積もってください。

リスク①｜情報漏えいとセキュリティ

エージェントは、目標を達成するために自分でデータを取りに行きます。人が都度確認しないぶん、「見せてよいデータかどうか」を仕組みで決めておく必要があります。

• 入力したデータが学習に使われる設定になっていないか
• エージェントに与える権限が、担当者本人の権限を超えていないか
• 実行ログに、個人情報や認証情報が残っていないか
• 外部サービスへ送信する経路が、社内規程で認められているか

権限は、人ではなくエージェントに付きます。担当者が異動しても権限が残る事故が起きるので、棚卸しの対象に加えてください。

リスク②｜誤りと責任の所在

もっともらしい誤りを出すハルシネーションは、エージェントでも起きます。厄介なのは、誤った前提のまま次の作業に進んでしまう点です。

意思決定を任せた結果に問題が起きたとき、責任を負うのは導入した側です。外部に出る書面、金額の確定、契約に関わる判断は、人の承認を挟む形にしてください。「どこまでを承認なしで実行してよいか」を、文書で決めておくのが実務です。

リスク③｜過度な依存と、運用が回らなくなること

動いている間は誰も中身を見なくなります。止まったときに、手順を知っている人がいない状態が生まれます。

• 継続的な監視 — 成功率と処理件数を、日次で見られる形にする
• 手動での代替手順 — 止まったときに人が回せる手順を残す
• 社内ルールの整備 — 誰が何を作ってよいかを決め、把握されていない利用（シャドーAI）を防ぐ
• 従業員教育 — 出力をそのまま使わないことを、手順として教える

3つ目が抜けると、部署ごとに似たものが作られ、半年後に誰も全体を把握していない状態になります。

技術面・実務面で残っている課題

現時点では、次が未解決です。導入前に想定しておいてください。

• 長い手順の途中で、前提を取り違えたまま進むことがある
• 同じ入力でも、実行のたびに結果が揺れることがある
• 既存システムに、エージェントが使える正規の入口が無い
• 効果の測り方（何と比べて何%短縮したのか）が決まっていない

4つ目は、導入の可否ではなく社内での存続に効きます。導入前の件数と所要時間を記録していないと、効果を後から証明できません。

業務別の活用例

領域	任せる仕事	効果が出る条件
カスタマーサポート	問い合わせの一次対応と履歴の記録	過去の回答が、検索できる形で残っている
営業	見込み客の調査、提案資料の下書き、活動記録の入力	顧客データの入口が1つに揃っている
バックオフィス・経理	申請の受付、証憑の突合、転記	例外処理の判断基準が文章になっている
データ運用・分析	収集から加工までの手順の実行	データの置き場と権限が決まっている
開発・IT運用	実装、テスト、障害の一次切り分け	レビューする人が確保されている

右の列が満たされていない領域から始めると、「AIが悪い」という結論になりがちです。実際に足りていないのは、その前段の整備です。

AIエージェント導入のステップ｜5段階の進め方

• 1. 目的の明確化 — 対象業務を1つに絞り、現状の件数と所要時間を記録する
• 2. 適切なツールの選定 — 提供形態を決め、連携とセキュリティの条件で候補を絞る
• 3. 小規模なパイロット運用 — 一部の担当者・一部の件数だけで動かす
• 4. 効果測定と改善 — 1で記録した数字と比べ、止まった箇所を潰す
• 5. 段階的な展開 — 対象の部署と業務を広げる

1を飛ばすと、4ができません。導入前の数字は、導入した後には取れません。着手する日に、件数と時間を控えておいてください。

今後のトレンド

• マルチエージェント化 — 役割を分けた複数体の連携が一般化する
• 業界特化型の増加 — 業種の手順を織り込んだ製品が出てくる
• 業務ソフト側への内蔵 — 単体製品ではなく、使っているソフトの機能として入る
• 統制の仕組みの整備 — 権限、監査ログ、承認の線引きが製品要件になる

3つ目が進むほど、「どれを買うか」より「どこに保守を置くか」が選定の中心になります。

AIエージェントのよくある質問

Q. AIエージェントには、どんな種類がありますか。
分け方が3通りあります。動き方による分類（単純反射型・モデルベース反射型・目標ベース型・効用ベース型・学習型）、提供形態による分類（業務スイート組み込み型・業務プロセス統制型・クラウド基盤型・開発フレームワーク型・事業共創型）、そして用途による分類（タスク自動化・情報収集要約・FAQ対応・コーディング支援）です。発注先を決めるときに使うのは、2つ目です。

Q. AIエージェントと生成AIは何が違いますか。
生成AIは1回の応答を返して終わります。AIエージェントは目標を受け取り、道具を使いながら、目標が満たされるまで手順を続けます。違いは賢さではなく、終わり方です。

Q. AIエージェントを選ぶとき、最も重要な比較ポイントは何ですか。
機能性・連携範囲・セキュリティ・サポート体制・自律性・カスタマイズ性・費用の7つで比べます。ただし先に決めるべきは「半年後に誰が保守を持つか」です。ここが決まらないと、どの列を重く見るかが決まりません。

Q. 専門知識がなくてもAIエージェントは使えますか。
ノーコードで組める製品や、業務ソフトの追加機能として提供されるものなら、作る作業自体は専門知識なしでも可能です。ただし権限の設計と、止まったときの切り分けには知識が要ります。作れることと、運用できることは別です。

Q. 導入時に、とくに注意すべき課題は何ですか。
入力データの取り扱い、エージェントに与える権限の範囲、そして効果を測るための「導入前の数字」を残しておくことの3つです。最後の1つは、着手した日を過ぎると取れなくなります。

Q. 無料のAIエージェントは業務で使えますか。
当てどころを探す段階では使えます。ただし実行回数の上限、データの取り扱い条件、問い合わせ窓口の有無が本番の制約になるため、有料版へ移す費用を先に見積もっておいてください。

ここまでが、AIエージェントの種類と比べ方の教科書どおりの整理です。分類を知り、7つの観点で並べ、5つのステップで進める。候補が同じ形をしていれば、この手順で選べます。

この記事の後半で扱うのは、その先です。並べた候補が、そもそも同じ土俵に載っていないとき、比較表の列は何を測っていることになるのか。

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類型のうちどれを選んでも大きくは間違えません。逆に、ここが空いたまま製品を比べると、どれだけ丁寧に比較しても決まりません。

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

この記事を書いた会社について（アルチェコ）

本記事を載せている媒体を運営するアルチェコ（ARCHECO）は、UXデザイン・AI開発・新規事業開発を組み合わせた事業共創スタジオです。大企業と組み、対象業務の選定から試作版（MVP）が動くところまでを一緒に作っています。上の表で言えば、事業共創型にあたります。

繰り返しますが、ほかの4類型が強い場面では、そちらを選ぶほうが速い。一方で、「エージェントを入れたい」「ただ、何を任せればいいか分からない」という段階なら、いちど話してみてください。

• AIエージェント開発
• 新規事業コンサル・MVP・PoC開発
• ご相談・お問い合わせ

以上です。