はじめに

ここ数年で、AIは単なる業務補助ツールから、自律的に判断し行動する「エージェント」へと進化しつつあります。

この変化を象徴するプロダクトとして、次の3つが挙げられます。

Frontier Agents（AWS）
Devin（Cognition）
Agentforce（Salesforce）

本記事では、これら3つのプロダクトについて公開されている情報を整理し、そのうえで「AIエージェント時代のSIerとしての立ち位置」について考えていきます。

とくにSIerでシステム開発に携わるエンジニアの視点から、次の問いについて掘り下げていきます。

AIエージェント前提の世界で、SIerはどこに価値を出せるのか
既存のシステム開発から、ビジネスモデルをどのように成長させられるのか

本記事では、いずれも2025年12月時点で公開されている公式ドキュメントやレポート、ニュース記事などの情報のみを扱います

公開情報からみるAIエージェント

Deloitteが定義する“agentic AI”

Deloitteのレポートでは、Frontier AgentsやDevinのようなプロダクトをautonomous generative AI agents（agentic AI）と呼び、「人間の監督をほとんど必要とせずに、複雑なタスクを完了し、目標を達成できるソフトウェアソリューション」と定義しています。

大規模言語モデル（LLM）を土台にしつつ、複雑なジョブを一連のステップに分解して計画・実行し、必要に応じてツールや他のエージェントを呼び出し、短期・長期のメモリを使ってコンテキストを維持することで、「チャットボットのように対話に答えるだけ」から「ユーザーに代わってタスクを進めるソフトウェア」に近づけていくものだと説明されています。

同レポートでは、生成AIをすでに利用している企業のうち、2025年には約25%がagentic AIのPoCを開始し、2027年には約50%に増加すると予測しています。また、過去2年間でagentic AI関連スタートアップに20億ドル超の投資が行われていることも紹介されています。

Devinについては、実際のコードリポジトリから取得したGitHubのIssueを用いたベンチマークで、約14%のIssueを解決できたと報告されています。これはLLMベースのチャットボットと比べておおよそ2倍の性能とされていますが、一方で現状ではエラーも多く、人間の監視なしにジョブ全体や一部の処理を任せられる段階ではなく、「完全に自律的とは言えない」とも明記されています。

3つのプロダクトから見る「エージェントらしさ」

ここからは、具体的な3つのプロダクトを取り上げます。

Frontier Agents（AWS）
Devin（Cognition）
Agentforce（Salesforce）

それぞれ「どの領域で、どんな仕事を任せられる存在なのか」を公開情報ベースで整理します。

Frontier Agents

AWSはFrontier Agentsを、「目標を与えると、数時間から数日にわたって自律的にタスクを進めるAIエージェント」として紹介しています。

公式サイトでは、3種類のエージェントについて以下のように説明されています。

Kiro autonomous agent
- 実装・改修・テストなど、システム開発関連タスクを担当
AWS Security Agent
- 脆弱性診断や設計書レビューなど、セキュリティ関連タスクを担当
AWS DevOps Agent
- 監視・運用・インシデント対応など、運用関連タスクを担当

BitcoinWorldの記事では、Kiro autonomous agentについて「チーム固有のコーディングパターンを学習しつつ、セッションをまたいでコンテキストを維持しながら、数日にわたって自律的にコードを書き続けられる」といった紹介もされています。

Frontier Agentsの概要

エージェント名	担当領域	代表的なタスクの例
Kiro autonomous agent	システム開発	仕様やリポジトリを読み込み、設計変更・コード実装・リファクタリング・テスト追加・PR作成までを自動で進める
AWS Security Agent	セキュリティ	設計レビュー、スレットモデリング、コードや依存パッケージの脆弱性検知と優先度付け、修正案の提示
AWS DevOps Agent	運用 / SRE	メトリクス・ログ・トレースの監視、インシデント検知と一次分析、原因候補の特定、レポート作成やロールバック提案

Devin

CognitionのDevinは、「AI ソフトウェアエンジニア」を掲げるagentic AIです。

主に以下のような特徴を持っています。

自然言語で与えられた仕様から、アプリケーションの設計・実装まで行う
既存コードベースを読み込み、テストや修正を自動で進める
GitHubやSlack、Linearなどの開発・コラボレーションツールと連携し、チケット駆動でタスクを進められる

AiNewsなどの報道では、Goldman SachsがDevinを大規模に試験導入していることも紹介されています。CIOはインタビューの中で、Devinを「開発者の仕事を拡張する新しい従業員のような存在」として位置づけており、「Devinでワークフォースを拡張していく」とコメントしています。

Devinの公式サイトやドキュメントでは、SlackやGitHub、Linearなど既存の開発ツールと連携し、Pull Requestやチケットの状況を踏まえてタスクを進めるといった利用イメージが紹介されています。

開発者が個別に「Devinを起動する」というより、既存の開発ワークフローの中に組み込んで使うことを前提に設計されている点が特徴的です。

Devinの概要

項目	内容
位置づけ	自律型ソフトウェアエンジニア（autonomous software engineer）を目指すagentic AI
主なタスク	アプリケーションの設計・実装、既存コードベースのテスト・修正、CI/CDやチケットと連携した保守タスクの自動化
ベンチマーク結果	SWE-benchで実コードのGitHub Issueの約14%を解決する一方、エラーも多く、人間によるレビューが前提と評価されている

Agentforce

SalesforceはAgentforce を、「人間・アプリケーション・AIエージェント・データを組み合わせてあらゆるエクスペリエンスを向上させる、エンタープライズ向けエージェントAIソリューション」と位置づけています。

公式サイトでは、Agentforceを使うことで「質問に答え、アクションを実行し、生産性を高める自律的な AI アプリケーション」を構築でき、適切なビジネス知識を与えることで、24時間365日従業員と顧客を支えるデジタル労働力を作り出せると説明しています。

他の2つと異なり、Agentforceは個々のエージェントそのものというよりも、「エージェントを定義・実行・運用するためのプラットフォーム」という位置づけです。

RivaEngineの解説などでは、AgentforceのエージェントはAgent Builderによって、概ね次の5要素で設計されると説明されています。

役割（例：Service / Sales / Coaching など）
参照するデータソース（Sales Cloud / Service Cloud / Data Cloud / 外部システムなど）
実行可能なアクション（ケース作成、レコード更新、外部API呼び出しなど）
ガードレール（自動化の範囲、エスカレーション条件など）
ユーザーチャネル（Webチャット、メッセージング、電話など）

Agentforceの全体構成

レイヤ	主な要素・役割
データ／業務システム層	Salesforce Sales CloudやService Cloud、Data Cloudのデータに加え、メール・通話ログなどの非構造化データや、指定された外部システムから必要な情報を取得する。
推論エンジン層	Atlas Reasoning Engineが「Agentforceの脳」として、ユーザー意図を解釈し、タスクの分解・必要なデータ取得・アクションの計画・実行をオーケストレーションする。
エージェント層	Service AgentやSales Development Representativeなどの標準エージェントに加え、Agent Builderで定義したカスタムエージェントが配置され、各チャネルを通じて顧客や従業員とやり取りする。

3つを並べると見えてくるもの

ここからは引用ではなく、3つのプロダクトに共通するポイントを整理します。

まず、いずれも「人が一問一答で操作するチャットボット」ではなく、「ある程度まとまった仕事を任せられるエージェント」として設計されている点です。人間の勤務時間に縛られず動かせるため、単純な生産性向上だけでなく、夜間対応や人手不足で後回しになりがちなタスクを埋める手段としても位置づけられます。

一方で、Deloitteの指摘や各社の説明が示す通り、現時点では人間の監督が前提です。前提条件や許可するアクションの範囲を誤ると、バグと修正を繰り返してコストだけ膨らむリスクがあります。だからこそ、タスクの粒度や自動化の範囲、どこで人の確認を挟むかをどう設計するかが重要になります。

この「どこまでをエージェントに任せ、どこから先を人が見るか」という設計の話は、そのまま次章で扱う「エージェント前提のエコシステム」や「SIerの役割」の議論につながっていきます。

Salesforceと富士通の取り組みに見る「エージェント前提」のエコシステム

ここからは、前章で見たAgentforceを手がかりに、「エージェントを前提にしたエコシステム」の中で、Salesforceと SIer（ここでは富士通を例にします）がどのような役割を果たしているのかを公開情報の範囲で整理します。

あくまで現時点で公開されている事例やサービス紹介をベースに、「Salesforceがどんなプラットフォームを用意し、SIerがどの部分を支援しているのか」という関係性を一度俯瞰しておくという位置づけです。

Salesforceとパートナーの関係

Salesforceの導入支援を行うパートナー企業のブログでは、SIerの役割として、概ね次のようなポイントが挙げられています。

現状業務やシステムの評価と要件整理（Assessment / Planning）
画面・項目・ワークフロー・権限などの設計とカスタマイズ
既存システムからのデータ移行（Data Migration）
ERP や基幹システム、データレイクなど他システムとの連携（Integration）
ユーザー教育と定着支援（Training / Adoption）
導入後の運用・保守・継続的な改善（Ongoing Support）

Agentforceが登場してもこの基本構造は変わりません。変わるのは、「設計の中にエージェントの観点が追加される」という点です。

具体的には、以下のような設計項目が増えているイメージです。

どの業務で、どのような役割のエージェントを定義するか
どこまでを自動化し、どこから人に引き継ぐか
Salesforce以外のシステムやデータソースと、エージェントを通じてどうつなぐか

Salesforceはエージェントを含むプラットフォームを用意し、その上で「顧客の業務に合わせて組み立てる部分」をSIerに期待していると整理できます。

富士通が担っている「仲介」の役割

富士通は、自社のニュースリリースやサービス紹介ページ等で、SalesforceやAgentforceを活用した顧客接点改革・コンタクトセンター高度化の取り組みを紹介しています。

公開情報ベースで見ると、主に次のような役割を担っていることが分かります。

Salesforceソリューションの導入・活用支援サービスの提供
MuleSoftなどを用いた他システムとの連携を含むインテグレーション支援
Salesforce Japan主催イベントでの事例紹介・登壇を通じたノウハウ共有

こうした事例からは、富士通がSalesforceの提供する機能やサービスの特性を踏まえつつ、顧客企業の業務プロセスや既存システムの制約とのあいだをつなぐ「仲介役」として動いていると読むことができます。

エージェント前提の世界になっても、この「ベンダーと顧客の間をつなぐ」という本質は変わりません。むしろ、エージェントの設計・ガードレール・運用ルールまで含めて仲介する必要が出てくる分、仲介役としての仕事の厚みは増していくと考えられます。

次の章では、この仲介の視点から「SIerの仕事がどう広がるか」を、もう少し具体的に整理していきます。

AI エージェントで「SIerの仕事」がどう広がるか

ここからは、これまで見てきた一次情報を踏まえたうえでの筆者なりの整理になります。

AIが仕事にどんな影響を与えるのかという議論も重要ですが、本記事ではそのうち、「こうしたプロダクトの登場によって、SIerにどのような新しい役割や仕事の広がりが生まれうるか」という点に焦点を当てていきます。

エージェント＋既存システムのオーケストレーション

前章で触れたように、現時点でもSIerはSalesforceをはじめとするSaaSと、既存のシステム群をつなぐ役割を担っています。
AIエージェントが前提になってくると、この「つなぎ方」にもう一段設計の層が増えてくると考えています。

多くの企業では、例えば次のようなシステムが並行して存在しています。

基幹業務システム（ERP・会計・生産管理など）
データ基盤（DWH / データレイク / 分析基盤）
認証・認可基盤（ID管理、シングルサインオンなど）
運用・監視基盤（モニタリング、ログ管理、インシデント管理など）

エージェントを導入する際には、こうしたシステム群に対して「どこまで何を任せるか」を、業務フローとシステム構成の両面から設計していく必要があります。

設計観点をざっくり整理すると、次のようになります。

設計観点	具体的に考えるポイントの例
トリガー	どのイベントでエージェントを動かすか（アラート発生時／定期ジョブ／担当者の操作など）
アクセス範囲	どのシステムの、どの API／データにアクセスさせるか（読み取り専用か、更新も許すかなど）
人の関与	どのタイミングで人のレビュー・承認を必須にするか（レコード更新前／本番反映前など）
モニタリング／検証	想定外の動きをしたとき、どのログやダッシュボードを見れば原因を追えるか

これは従来の「システム連携」を否定してゼロから作り直す話ではなく、その上に「エージェントを含めた全体のオーケストレーション」を一段高い視点で設計する仕事が乗ってくるというイメージに近いと思います。

このレイヤーは、まさにSIerが得意としてきた領域の延長線上にあります。

ガードレールと責任分界の設計

Agentforce関連の資料では、どこまで自動化を許し、どの条件で人にエスカレーションするかといった「ガードレール」の重要性が繰り返し言及されています。
Devinについても、Deloitteは「現時点の精度では、人間によるレビューなしに開発プロセス全体を任せるのは難しい」といった趣旨の評価をしています。

当面の現実的な姿は次のようなものだと考えています。

エージェントがある程度までタスクを進め、クリティカルな変更や高リスクな操作は人がレビュー・承認する

つまり現状のエージェントは、「人間の監督を前提としたデジタルメンバー」というポジションです。

ここでSIerに出番があるのは、「どこまでを自動化してよいか」を決めるところにとどまりません。現場で運用できるように、それを契約・運用ルール・システム設計に落とし込むところまで含めて設計する必要があります。

具体的には、例えば次のような観点です。

エージェントが自動で変更してよい範囲と、必ず人の承認が必要な範囲
エージェントが行った操作ログの保存期間と閲覧権限
事故が起きた場合の一次対応フロー（誰がどこまでロールバックするか）
ベンダー／SIer／顧客の三者間での責任分界

クラウドでよく語られる「共有責任モデル」を、AIエージェントにまで拡張して設計していくイメージに近いと思います。

「対サプライチェーン」型のサービスづくり

もう一つ、筆者が面白いと感じているのが「対サプライチェーン」という視点です。

1社だけに焦点を当てても、エージェントが関わるレイヤーは1つにとどまりません。

レイヤー	代表的な役割・例
顧客接点レイヤー	Agentforceや各種SaaS上のエージェントが、顧客対応・営業支援・問い合わせ対応などを担う
開発・運用レイヤー	Frontier AgentsやCI/CDパイプラインが、アプリ開発・テスト・デプロイ・運用自動化を担う
基盤レイヤー	インフラ・セキュリティ・オンプレ基幹システム、ID管理、監視・ログ基盤などを維持・運用する

ここでSIerが取りうる関わり方を整理すると、ざっくりと次の3パターンに分けられます。

関わり方のパターン	特徴	限界になりがちなポイント
個別プロダクト単位の導入支援	特定ベンダー（例：Salesforce / AWS）のエージェント導入を支援	企業内の他レイヤーとの連携や責任分界は、別プロジェクトに任せがち
プロジェクト単位のスポット支援	ある業務領域やシステム更新プロジェクトに紐づけてエージェントを導入	プロジェクトをまたいだ「全体最適」の設計までは踏み込みにくい
「対サプライチェーン」視点での全体設計	企業内の複数レイヤーを見渡し、どこにどんなエージェントを置くかを設計	要求される視野が広く、ベンダー横断の知識とガバナンス設計が必要

このうち「対サプライチェーン」型のスタンスをとると、以下の範囲まで拡大して提案できるようになります。

顧客接点〜開発〜基盤までを1本のサプライチェーンとして見立てる
どのレイヤーにどのエージェントを置くと、全体として価値が最大化されるか
そのために、どのベンダーとどう組むべきか（SaaS・クラウド・監視基盤など）

実際にONEiOのように、自らを「Managed Integration Service Provider」と位置づけ、複数のベンダーやサービスプロバイダをまたぐ接続を、クラウドネイティブな IntegrationOpsモデルで「インテグレーションそのものを継続的なマネージドサービス」として提供するプレイヤーも現れています。

エージェントが前提になればなるほど、以下のような設計の比重は確実に増していきます。

どのプラットフォームをどう組み合わせるか
どのレイヤーで誰が責任を持つか

そこを「対サプライチェーン」の視点で設計できるSIerにとっては、むしろビジネスの射程が広がるフェーズだと捉えた方が、新たな収益機会や提供価値の拡大につなげやすくなるはずです。

SIerとして「今からできること」

最後に、ここまで見てきた一次情報を踏まえて、「SIerとして今日から着手しやすいこと」を3点に絞って整理します。

自社や身近な部門で小さなエージェント運用を試してみる

いきなりお客様向けの大規模導入に踏み込むのではなく、まずは自社の中で小さく試してみるのが現実的です。例えば、次のような領域は影響範囲をコントロールしやすく、試行錯誤もしやすいゾーンです。

社内ヘルプデスク（よくある問い合わせ対応の一部）
開発チーム内の簡単な保守タスク
定型的な問い合わせ対応やレポート作成の一部

こうした領域で小さく導入してみることで、「エージェントにどこまで任せられるのか」「どこから先を人が確認すべきか」を、自分たちの目で確かめることができます。

その際、ログやダッシュボードで動きを見える化しながら、自動化の範囲と人が関与する境界を少しずつ調整していくプロセス自体が、その後の提案や設計で使える運用イメージや、リスク・効果を説明するための材料になっていきます。

エージェントに任せたい業務を、プロセスとして分解しておく

Deloitteのレポートでは、agentic AIの特徴の一つとして「複雑なタスクを複数のステップに分解し、順番に実行していくような使い方」が想定されているといった趣旨の説明がなされています。

ただし、これは「どんな業務でも自動的にうまく分解してくれる」という意味ではなく、筆者としては「人間側がある程度プロセスを整理して渡したときに、本来の力を発揮する」イメージに近いと考えています。

SIerの現場ではすでに、例えば次のような成果物を日常的に作っているはずです。

業務フロー図
手順書
システム構成図

これらを「エージェントに任せる前提」であらためて棚卸しし、以下のような粒度まで整理しておくだけでも十分な付加価値になります。

各ステップで何を入力として、どんな処理を行うのか
どこが機械的に進めやすい作業で、どこが判断や例外対応を伴うのか

そのプロセス定義は、そのままエージェント設計時のインプットとして利用できるうえ、顧客に対して「どの部分を自動化しようとしているのか」を説明する材料にもなります。

「対サプライチェーン」のPoCシナリオを書き出してみる

もう一つのアプローチとして、「自分が顧客側の情報システム部門だったらどう組み立てるか」という前提で、簡単なPoCシナリオを書き出してみる方法があります。

例えば、次のような観点で 2〜3 パターンほどラフな案を描いてみます。

顧客接点まわりはAgentforceのエージェントを中心に構成する
開発・運用まわりはFrontier Agentsや既存のCI/CDパイプラインと組み合わせる
それらをつなぐデータ基盤やID基盤をどのようなアーキテクチャにするか

こうしたシナリオを一度書き出してみると、以下のような論点が整理しやすくなります。

自社としてどのレイヤーを支援できそうか
どのベンダーと組むとシナジーを出しやすいか

この段階では「正解の構成」を当てにいく必要はありません。むしろ、「この構図なら、こういうオーケストレーションサービスが提案できそうだ」といった仮説をいくつか持っておくこと自体が、実際にお客様から相談が来たときに、初期のたたき台を素早く提示するための準備になります。

おわりに

AIエージェントをめぐる情報は、派手なデモやキャッチーなコピーが先行しがちで、「何がどこまでできて、どこから先はこれからなのか」がやや見えづらい状況です。

ただ、本稿で見てきた一次情報を整理していくと、少なくとも次の点は押さえられます。

観点	押さえておきたいポイント
プロダクトの現状	AWS・Salesforce・Cognitionなど主要プレイヤーが、すでに「エージェント前提」のプロダクト／プラットフォームを提供し始めている。
能力と限界	チャットボットやCopilotより広いタスクを扱える一方で、完全自律というより「人間の監督前提のデジタルメンバー」として捉えるのが現実的。
エコシステムとしての構図	SaaSベンダー、SIer、必要に応じてコンサルやMSPなどを含むエコシステム全体で、業務・システム・運用を設計していく必要がある。

この状況を「仕事が奪われるかどうか」だけの軸で捉えてしまうと、議論の幅がどうしても狭くなります。

むしろ以下のような問いに軸足を移した方が、SIerにとっても、お客様や現場にとっても建設的です。

どの業務をどこまでエージェントに任せると、現場の負荷が下がり、品質が上がるのか
どのプラットフォームやサービスを組み合わせると、お客様にとっての価値が最大化されるのか
その全体像の設計とオーケストレーションを、誰がどの立場で担うのか

AIエージェントは、うまく設計・運用すれば「面倒な部分を肩代わりしてくれる心強いチームメイト」になり得ます。

対サプライチェーンまで視野を広げ、「どのレイヤーにどのエージェントを置き、どのように連携させると自社の強みを最大限に活かせるか」を考えていく。その延長線上に、AIエージェント時代ならではのSIビジネスの機会が広がっていくはずです。

参考文献

agentic AIに関するレポート

Frontier Agents 公式サイト

Kiro autonomous agentに関するBitcoinWorld記事

Devin 公式サイト

Goldman SachsによるDevin試験導入に関するAiNewsの報道

Agentforce 公式サイト

Agentforceに関するRivaEngineの解説

Salesforceの導入支援を行うパートナー企業のブログ

富士通 x Salesforceに関する紹介ページ

ONEiO 公式サイト