※アイキャッチ及びブログ内の画像は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エージェントの仕組みや技術的なポイントについて以下の記事でまとめておりますので、そちらもご参照ください。
1.1 MCP（Model Context Protocol）の登場
技術的な転換点のひとつが、2024年後半に登場した MCP（Model Context Protocol） でした。それまでの生成AI活用では、
- モデルごとにツール連携の実装が異なる
- コンテキストの受け渡しが属人的・アドホック
- 「どこまでAIに任せてよいか」が設計しづらい
といった課題がありました。
MCPは、AIアプリケーションが外部のデータソースやツールと連携する際に、文脈やツール情報をどのような形式・手続きでやりとりするか、およびどのツールにどの権限でアクセスできるかを標準化するプロトコルです。
- AIエージェントと外部ツール／業務システムの接続がシンプルに
- コンテキスト管理が明示的になり、安全性・再現性が向上
- エージェント設計を“プロダクト”として考えられるようになった
結果として、「とりあえずAPIを叩くAI」から「役割を持った業務主体としてのAI」 への移行が一気に進みました。
※当社のMCP関連の記事
1.2 Multi-Agent, A2A（Agent-to-Agent）の登場
さらに重要な変化として登場したのが、A2A（Agent-to-Agent） という考え方です。A2Aとは、
- 役割を持った複数のAIエージェントが
- 互いに状態や成果物を共有し
- 協調しながら一つの目的を達成する
という マルチエージェント前提の設計思想 です。例えば人の組織と同じように役割分担し、連携します。
- 情報収集を専門とするエージェント
- 分析・判断を行うエージェント
- 実行・オペレーションを担うエージェント
このA2Aの登場により、AIは「単体で賢い存在」から「組織として機能する存在」へ 進化し始めました。
A2Aにおいては、多様なアーキテクチャが次々と提唱され、急速な進化を遂げています。
私個人の意見としてはMulti Agentのベストプラクティスは今後も目まぐるしく変化していくと想像しております。一方でそのためにAgent構築を足踏みするのではなく、Agent自身が業務プロセス上のデータやツールにアクセスし問題を解くための準備を進めることが今のフェーズでとても重要だと感じます。
1.3 Browser Use, Agent Modeの登場
これまで述べてきたAIエージェントの仕組みや設計論に留まらず、実務でそのまま使えるAIエージェント も次々と登場してきました。
例えば、browser use を搭載した ChatGPT Atlas や ChatGPT のAgent Modeなど、
エージェント自身が ブラウザやマシンを直接操作しながら問題解決を行う タイプのエージェントが利用可能になっています。
これらは、単なるツール呼び出しではなく、
- 画面遷移を伴う情報収集
- 視覚的な情報を前提とした操作
- ログイン後のWebサイト内での作業
といった、従来はAPIやMCPが提供されていないために自動化が難しかった領域 にまで、
AIエージェントの適用範囲を広げました。
特に browser use は、ブラウザを人と同じように直接操作するため、
「ツール接続の有無」に依存しないエージェント活用 を可能にしています。現時点では、
- セキュリティ観点でどこまで操作を委ねてよいか
- 誤操作や意図しない遷移への対策
- アクセス権限や監査ログの設計
といった点を考慮した上で、「どこまでエージェントに任せ、どこから人が介入するか」 を慎重に設計する必要があります。
一方で、数年先を見据えると、多くのPC上の操作が AI駆動に置き換わっていく可能性 は十分に考えられます。現時点でも「使える場面では積極的に使っていきたい」と感じる、非常に示唆に富んだエージェントだと言えるでしょう。
1.4 Coding Agentの登場
実務面で特に大きなインパクトを受けたのが、エンジニアリング領域 です。
Cursor、Claude Code、CodeX などをはじめとする Coding Agent の普及により、ただ単に「コードを書く」だけではなく、設計, 開発, レビュー, テスト, リリース, 運用といった エンジニアリングプロセス全体 に関与し、プロセスそのものの変革に寄与しています。
エンジニアリング領域にAIエージェントが自然に浸透した背景には、コーディング能力の飛躍的な向上だけでなく、以下の3点が大きかった と考えています。
- エンジニアリングプロセスの多くのデータが GitHub に集約されており、
一元性とアクセス性が非常に高いこと - IDE やエディタなど、普段使いのツールの中からそのまま利用できること
- エージェントの効果を体感するまでの利用ハードルが低いこと
これらの条件が揃っていたことで、エンジニアリング領域では AIエージェントが「試される前に、使われ始めた」 と言える状況が生まれました。
この事例が示しているのは、AIエージェント活用の成否は、モデル性能よりも 業務データの集約度・ツールとの距離・試しやすさ に大きく依存するという点です。
エンジニアリング領域で起きている変化は、今後、他のビジネス領域へAIエージェントを展開していく上での重要なヒント になるはずです。
1.5 画像生成の飛躍
昨年の今頃は、DALLE-3 が台頭し、プロンプトひとつで様々な画像を生成できるようになった という点で大きな進化がありました。一方で、制御性という観点ではまだ課題が多い のも事実でした。
- 意図した構図やトーンにならない
- 修正を重ねるとブレていく
- 業務で求められる一貫性を保ちづらい
そのため、ブログのサムネイル生成などでは活躍するものの、もう一歩踏み込んだ実務用途では使いづらい という印象を持っていた方も多いのではないでしょうか。
今年発表された Nano Banana では、画像生成・画像修正の能力が 飛躍的に向上 しました。具体的には、
- 画像に対するスタイル変換をプロンプトで自然に指示できる
- スライド1枚分の要約を、視覚的に表現できる
といった形で、「きれいな画像を作る」から「業務で使える画像を作る」 へと、明確にフェーズが変わったと感じています。あと1-2年もすると、スライドを0から作成するという業務は無くなるかもしれないと感じるようなリリースでした。
※当社のスライド生成関連の記事
2. 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に何をやらせるか」から考えるのではなく、「このプロセスの中で、人が本来担うべき価値は何か」から考える必要があります。意思決定、責任の所在、例外対応、価値判断といった部分は、引き続き人が担うべき領域です。一方で、情報収集、整理、選択肢の生成、過去事例との照合といった作業は、AIが主導した方が圧倒的に効率的です。
重要なのは、「自動化できるかどうか」で線を引くのではなく、「人がやる必然性があるかどうか」で線を引くことです。人がやらなくてもよい仕事をAIに任せるのではなく、人がやる意味のある仕事だけを人に残す。この発想の転換が、AI駆動なプロセス設計の核心になります。
また、役割分担はタスク単位ではなく、プロセス単位で考える必要があります。ある一部分だけをAIに任せても、その前後が人依存のままであれば、プロセス全体としてはボトルネックが解消されません。AIがどこから入り、どこまでを一気通貫で担い、どのタイミングで人が介入するのか。この流れを明確に設計することが重要です。
ここで鍵になるのが、「人は常に正解を出す存在である必要はない」という前提です。AIが生成した複数の選択肢に対して、どれを採用するかを決める、あるいは方向性だけを示す。そのように、人の役割は「実行者」から「判断者・設計者」へとシフトしていきます。
AIエージェントが前提になると、求められるスキルも変わります。作業を正確にこなす力よりも、問いを立てる力、判断基準を言語化する力、例外を扱う力が重要になります。これは一部の専門職に限った話ではなく、組織全体に共通する変化です。
AI駆動なビジネスプロセスとは、人の仕事を奪うものではありません。むしろ、人が本来向き合うべき意思決定や価値創出に集中できる状態を作るための仕組みです。そのためにも、人とAIの役割分担を曖昧にせず、意図をもって設計することが欠かせません。
3. 業務プロセスに入り込み、線で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に関する記事は昨日、一昨日の記事をご参照ください
最後に
AI駆動なビジネスプロセスは、技術を導入すれば一足飛びに実現できるものではありません。業務を点ではなく線として捉え直すこと、データやツールへのアクセスを再構築すること、人とAIの役割分担を設計することなど、乗り越えるべき壁は多く存在します。
一方で、世の中全体は確実にAI駆動な状態へと進んでいます。この流れが止まることはありません。だからこそ重要なのは、完璧な形を急ぐことではなく、その前提に立ち、構えと準備を進めているかどうかです。
AI駆動なビジネスプロセスに向けた取り組みそのものが、これからの企業にとっての競争力になっていくと考えています。AI Shiftは「人とAIの協働を実現し、人類に生産性革命を起こす」のミッションを掲げ、各企業様のAI駆動化の支援を続けてまいります。
AI Shift Advent Calendar 2025はこれにて完遂です！皆様良いクリスマスをお過ごしください！
---------------------------------
AI Shiftではエンジニアの採用に力を入れています！ 少しでも興味を持っていただけましたら、カジュアル面談でお話しませんか？ （オンライン・19時以降の面談も可能です！）
