2025年 AIエージェント元年を振り返る〜AI駆動なビジネスプロセスへの変革と実践〜

2025年 AIエージェント元年を振り返る〜AI駆動なビジネスプロセスへの変革と実践〜

Advent Calendar

※アイキャッチ及びブログ内の画像はNano Banana Proで生成

============================================

こんにちは、AI Shift、CAIO(Chief AI Officer)の友松です。

この記事はAI Shift Advent Calendar 2025の25日目、最終日の記事です。

AI Shiftではソリューション事業として、各企業様に AIエージェントに関連したAI活用戦略の立案から構築、運用までを一気通貫で支援しています。また社内でも「AI協働推進室」を立ち上げ、既存の業務プロセスを前提にしない AI駆動なビジネスプロセスへの抜本的な見直しを進めてきました。

本記事では、「AIエージェント元年」と呼ばれた2025年を振り返りながら、 技術の進化を“PoC止まり”で終わらせず、実際にビジネスプロセスの変革へつなげるには何が必要だったのかこれまでの実践を交えて整理していきたいと思います。

1. 2025年、AIエージェント元年。

2025年は、生成AIが「便利なツール」から「業務を遂行する主体」へと明確に進化した年でした。

マルチステップなタスクを自律的に分解・実行する

外部ツールや業務システムと連携する

人の指示を待たずに、目的達成のために判断・行動する

こうした AIエージェント的な振る舞いが、研究レベルではなく実務レベルで使えるようになったことが大きな転換点です。

今年3月に、AIエージェントの仕組みや技術的なポイントについて以下の記事でまとめておりますので、そちらもご参照ください。

CAIOが語る、AI Workerの技術ポイント

1.1 MCP（Model Context Protocol）の登場

技術的な転換点のひとつが、2024年後半に登場した MCP（Model Context Protocol） でした。それまでの生成AI活用では、

モデルごとにツール連携の実装が異なる

コンテキストの受け渡しが属人的・アドホック

「どこまでAIに任せてよいか」が設計しづらい

MCPは、AIアプリケーションが外部のデータソースやツールと連携する際に、文脈やツール情報をどのような形式・手続きでやりとりするか、およびどのツールにどの権限でアクセスできるかを標準化するプロトコルです。

AIエージェントと外部ツール／業務システムの接続がシンプルに

コンテキスト管理が明示的になり、安全性・再現性が向上

エージェント設計を“プロダクト”として考えられるようになった

結果として、「とりあえずAPIを叩くAI」から「役割を持った業務主体としてのAI」 への移行が一気に進みました。

MCP(Model Context Protocol)を用いた予約対話AIエージェントの構築と動作のトレース

MCP ClientをOpenAIモデルで実装する

AIエージェントの設計とその勘所

というマルチエージェント前提の設計思想です。例えば人の組織と同じように役割分担し、連携します。

情報収集を専門とするエージェント

実行・オペレーションを担うエージェント

この A2A（Agent to Agent）の登場により、AI は「単体で賢い存在」から「組織として機能する存在」へ進化し始めました。

A2A においては、多様なアーキテクチャが次々と提唱され、急速な進化を遂げています。

私個人の意見としては、Multi Agent（マルチエージェント）のベストプラクティスは今後も目まぐるしく変化していくと想像しております。一方でそのために Agent（エージェント）構築を足踏みするのではなく、Agent 自身が業務プロセス上のデータやツールにアクセスし問題を解くための準備を進めることが今のフェーズでとても重要だと感じます。

1.3 Browser Use, Agent Mode の登場

これまで述べてきた AI エージェントの仕組みや設計論に留まらず、実務でそのまま使える AI エージェントも次々と登場してきました。

例えば、Browser Use（ブラウザ使用機能）を搭載した ChatGPT Atlas や ChatGPT の Agent Mode など、エージェント自身がブラウザやマシンを直接操作しながら問題解決を行うタイプのエージェントが利用可能になっています。

これらは、単なるツール呼び出しではなく、

ログイン後の Web サイト内での作業

といった、従来は API（Application Programming Interface）や MCP（Model Context Protocol）が提供されていないために自動化が難しかった領域にまで、AI エージェントの適用範囲を広げました。

特に Browser Use は、ブラウザを人と同じように直接操作するため、「ツール接続の有無」に依存しないエージェント活用を可能にしています。現時点では、

セキュリティ観点でどこまで操作を委ねてよいか

誤操作や意図しない遷移への対策

といった点を考慮した上で、「どこまでエージェントに任せ、どこから人が介入するか」を慎重に設計する必要があります。

一方で、数年先を見据えると、多くの PC 上の操作が AI 駆動に置き換わっていく可能性は十分に考えられます。現時点でも「使える場面では積極的に使っていきたい」と感じる、非常に示唆に富んだエージェントだと言えるでしょう。

1.4 Coding Agent の登場

実務面で特に大きなインパクトを受けたのが、エンジニアリング領域です。

Cursor、Claude Code、CodeX などをはじめとする Coding Agent（コーディングエージェント）の普及により、ただ単に「コードを書く」だけではなく、設計、開発、レビュー、テスト、リリース、運用といったエンジニアリングプロセス全体に関与し、プロセスそのものの変革に寄与しています。

エンジニアリング領域に AI エージェントが自然に浸透した背景には、コーディング能力の飛躍的な向上だけでなく、以下の 3 点が大きかったと考えています。

エンジニアリングプロセスの多くのデータが GitHub に集約されており、一元性とアクセス性が非常に高いこと

IDE（Integrated Development Environment）やエディタなど、普段使いのツールの中からそのまま利用できること

エージェントの効果を体感するまでの利用ハードルが低いこと

これらの条件が揃っていたことで、エンジニアリング領域では AI エージェントが「試される前に、使われ始めた」と言える状況が生まれました。

この事例が示しているのは、AI エージェント活用の成否は、モデル性能よりも業務データの集約度・ツールとの距離・試しやすさに大きく依存するという点です。

エンジニアリング領域で起きている変化は、今後、他のビジネス領域へ AI エージェントを展開していく上での重要なヒントになるはずです。

昨年の今頃は、DALLE-3 が台頭し、プロンプトひとつで様々な画像を生成できるようになったという点で大きな進化がありました。一方で、制御性という観点ではまだ課題が多いのも事実でした。

意図した構図やトーンにならない

業務で求められる一貫性を保ちづらい

そのため、ブログのサムネイル生成などでは活躍するものの、もう一歩踏み込んだ実務用途では使いづらいという印象を持っていた方も多いのではないでしょうか。

今年発表された Nano Banana では、画像生成・画像修正の能力が飛躍的に向上しました。具体的には、

画像に対するスタイル変換をプロンプトで自然に指示できる

スライド 1 枚分の要約を、視覚的に表現できる

といった形で、「きれいな画像を作る」から「業務で使える画像を作る」へと、明確にフェーズが変わったと感じています。あと 1-2 年もすると、スライドを 0 から作成するという業務は無くなるかもしれないと感じるようなリリースでした。

※当社のスライド生成関連の記事

企業向けスライド生成 AI エージェントを Python と GPT5 で作ってみた

1. AI 駆動なビジネスプロセスへ

2025 年を振り返ると、「個人が AI を活用する」という観点では、モデル性能の向上やプロトコルの確立によって、活用は一気に加速しました。

一方で、組織として AI 駆動なビジネスプロセスへの変革を行うという点に目を向けると、そこにはまだいくつもの乗り越えるべき壁が存在しています。個人レベルでは、

コーディングや資料作成が速くなる

といった変化をすぐに実感できます。しかし、それらがそのまま

意思決定やオペレーションの変革

につながるかというと、決してそうではありません。この状態だと、エージェントを使いこなしている人と使いこなしていない人の差が広がっていき、業務適用範囲は一部にとどまり、組織全体としての効果は小さくなってしまいます。

2.1 点の業務ではなく線のプロセスとして考える

組織の AI 化の第一歩として、まず行うべきは As-Is と To-Be の整理です。ここでやってしまいがちなのが、「既存の業務フローのどこが AI 化できるか」という発想から入ってしまうことです。この考え方では、AI はどうしても既存業務の延長線上にある効率化ツールに留まってしまいます。

日々私たちが行っている業務は、それ単体で完結するものではありません。多くの場合、前後の業務と複雑に絡み合った一連の業務プロセスとして存在しています。

例えば、営業プロセスにおける「提案資料を作る」という業務を考えてみます。提案資料を作ること自体は一見すると「点の業務」に見えますが、その先には「提案する」という行為があり、さらにその結果として受注・失注という成果につながっていきます。この業務は、明確な“線”の中に位置づけられているのです。

実際に人が提案資料を作成するときには、自社製品の強みを踏まえた訴求や、過去の提案時のお客様の反応、失注理由として挙がった懸念点、次回の提案で強調すべきポイントなど、関連する複数の業務プロセスのコンテキストを無意識のうちに反映しています。

これは、提案資料作成という業務が、マーケティング活動や営業のヨミ会、商談の議事録、過去の受注・失注データといった営業プロセス全体と強く結びついているからです。

もし「提案資料作成」という点の業務だけを切り出して AI 化してしまうと、それなりに綺麗な資料は作れるようになりますが、受注率そのものは変わらない、という結果になりがちです。

一方で、営業プロセス全体を俯瞰し、どの情報がどの判断に使われ、どこで次のアクションにつながっているのかを整理した上で AI を組み込むことができれば、単なる業務生産性の改善にとどまらず、真のビジネスインパクトをもたらすプロセス変革へと昇華させることができます。

2.2 ツールへのアクセス／データの再構築：土台を作る

業務プロセスを AI エージェント化するうえで、避けて通れないのが業務データや業務ツールにエージェントがどのようにアクセスできるかという問題です。どれだけ高度な AI エージェントを設計したとしても、必要な情報にアクセスできなければ、業務を成立させることはできません。

SaaS 製品の場合、API が一定程度整備されていることも多く、それらと接続することでエージェント化が比較的スムーズに進むケースがあります。一方で、自社開発システムや受託開発で作られた業務アプリケーションでは、そもそも API が存在しなかったり、外部からのアクセスを前提にしていなかったりすることも少なくありません。この場合、「AI エージェントをどう作るか」を考える以前に、業務システムそのものをどう開いていくかという課題に直面します。

さらに、SaaS 製品であっても、もう一つの壁として浮かび上がるのが権限設計です。人によって閲覧・操作できる情報が異なる中で、その権限をどのように AI エージェントへ切り出して渡すのか。そもそも SaaS 側に、そうした細かな権限分離の仕組みが用意されていないケースもあります。「どのエージェントに、どこまでの権限を与えるのか」という設計を曖昧にしたまま進めてしまうと、セキュリティやガバナンスの観点で、後から大きな問題になる可能性があります。

また、2.1 で述べたように、業務を点ではなく線のプロセスとして捉えるためには、プロセス内で何が起きているのかを示すログや履歴が不可欠です。しかし実際の現場では、業務データの入力は人にとって非常にコストが高く、日々の業務に追われる中で後回しにされたり、結果として記録の粒度や精度が下がってしまうことがよくあります。入力項目を増やしたり、詳細な記入を求めたりするだけでは、長期的に質の高いデータを維持することは難しいのが実情です。

だからこそ重要になるのが、人に入力させる前提そのものを見直すことです。業務の中で自然に発生する操作ログやイベント、会話や議事録の自動生成、ツール間のイベント連携など、仕組みで解決できる部分は極力仕組みに任せるという発想が求められます。データを「入力するもの」から「自然に記録されるもの」へと転換することが、AI 駆動なビジネスプロセスを支える重要な土台になります。

ツールへのアクセス設計やデータの再構築は、AI 活用の文脈ではつい後回しにされがちなテーマです。しかし実際には、この部分をどれだけ丁寧に設計できるかが、AI エージェント活用の成否を大きく左右します。

2.3 人と AI の役割分担を再定義する：価値に集中する

AI を駆使したビジネスプロセスを設計する上で、最も重要かつ難しいのは、人と AI の役割分担をどう定義するかという点です。多くの現場では、「どこまで AI に任せてよいのか」「人がやるべき仕事は何なのか」という問いに対して、明確な答えを持てていません。

その結果、AI は常に人の指示待ちになり、人は AI のアウトプットを細かくチェックし続けるという、効率化どころか負荷が増える状態に陥ってしまいます。これは、AI の性能の問題ではなく、役割設計の問題です。

AI を駆使したプロセスでは、「AI に何をやらせるか」から考えるのではなく、「このプロセスの中で、人が本来担うべき価値は何か」から考える必要があります。意思決定（decision making）、責任の所在、例外対応、価値判断といった部分は、引き続き人が担うべき領域です。一方で、情報収集、整理、選択肢の生成、過去事例との照合といった作業は、AI が主導した方が圧倒的に効率的です。

重要なのは、「自動化できるかどうか」で線を引くのではなく、「人がやる必然性があるかどうか」で線を引くことです。人がやらなくてもよい仕事を AI に任せるのではなく、人がやる意味のある仕事だけを人に残す。この発想の転換が、AI を駆使したプロセス設計の核心になります。

また、役割分担はタスク単位ではなく、プロセス単位で考える必要があります。ある一部分だけを AI に任せても、その前後が人依存のままであれば、プロセス全体としてはボトルネックが解消されません。AI がどこから入り、どこまでを一気通貫で担い、どのタイミングで人が介入するのか。この流れを明確に設計することが重要です。

ここで鍵になるのが、「人は常に正解を出す存在である必要はない」という前提です。AI が生成した複数の選択肢に対して、どれを採用するかを決める、あるいは方向性だけを示す。そのように、人の役割は「実行者」から「判断者・設計者」へとシフトしていきます。

AI エージェントが前提になると、求められるスキルも変わります。作業を正確にこなす力よりも、問いを立てる力、判断基準を言語化する力、例外を扱う力が重要になります。これは一部の専門職に限った話ではなく、組織全体に共通する変化です。

AI を駆使したビジネスプロセスとは、人の仕事を奪うものではありません。むしろ、人が本来向き合うべき意思決定や価値創出に集中できる状態を作るための仕組みです。そのためにも、人と AI の役割分担を曖昧にせず、意図をもって設計することが欠かせません。

1. 業務プロセスに入り込み、線で AI 化する AI Shift の AI ソリューション事業

AI Shift の AI ソリューション事業は、単一業務の効率化に留まらず、業務プロセス全体に入り込み、線で AI 化を実現することを特徴としています。

第 2 章で述べた通り、業務は個々のタスクが連なったプロセスとして成立しており、真の価値創出にはプロセス全体を見据えた AI 設計が不可欠です。

そのため AI Shift では、コンサルティング・FDE（Forward Deployed Engineer）・AI エージェント構築プラットフォームを三位一体で提供しています。コンサルタントが顧客業務を深く理解し要件を整理し、FDE が顧客ごとの業務環境に合わせて AI 業務プロセスを素早く個別構築します。さらに、その構築知見はプラットフォームに蓄積され、次の AI 化を加速させていきます。

この循環により、PoC で終わらない実運用を前提とした AI 業務プロセスの実装が可能になります。AI Shift のソリューションは、ツール導入ではなく、業務の流れそのものを変革する AI 化を実現するサービスです。

※FDE に関する記事は昨日、一昨日の記事をご参照ください

Forward Deployed Engineer(FDE) 職はじめました

Forward Deployed Engineer（FDE）とは？お客様の業務改革を技術でリードするエンジニアの実像

AI 駆動なビジネスプロセスは、技術を導入すれば一足飛びに実現できるものではありません。業務を点ではなく線として捉え直すこと、データやツールへのアクセスを再構築すること、人と AI の役割分担を設計することなど、乗り越えるべき壁は多く存在します。

一方で、世の中全体は確実に AI 駆動な状態へと進んでいます。この流れが止まることはありません。だからこそ重要なのは、完璧な形を急ぐことではなく、その前提に立ち、構えと準備を進めているかどうかです。

AI 駆動なビジネスプロセスに向けた取り組みそのものが、これからの企業にとっての競争力になっていくと考えています。AI Shift は「人と AI の協働を実現し、人類に生産性革命を起こす」のミッションを掲げ、各企業様の AI 駆動化の支援を続けてまいります。

AI Shift Advent Calendar 2025 はこれにて完遂です！皆様良いクリスマスをお過ごしください！

AI Shift ではエンジニアの採用に力を入れています！少しでも興味を持っていただけましたら、カジュアル面談でお話しませんか？（オンライン・19 時以降の面談も可能です！）