最近、AIエージェントのデモや講演を見る機会が増えました。
「業務プロセスを全てAIエージェントが自律的に実行します！」
「エージェント同士が対話し、複雑なタスクを自動で完了します！」
すごい。本当にすごい。ワクワクするし、本当にそういう未来が訪れるのだろうなと感じます。
でも、ふと思ったのです。
「それ、全部AIがやる必要あるのか…？」
この記事では、AIエージェントに「楽をさせる」設計思想 — つまり、業務プロセスを分解し、各プロセスの性質に合った最適なツールを組み合わせる「ハイブリッドアプローチ」について考えてみます。
1. よくあるAIエージェントのアーキテクチャ
まず、最近よく見かけるAIエージェントのアーキテクチャを整理します。
今回はMicrosoft製品を中心に例を記載します（Copilot StudioやPower Automateなど）
たとえば、HR（人事）領域のマルチエージェント構成を考えると、以下のような形になります。
- HR Multi-Agent（オーケストレーター）がHR部門の従業員からの問い合わせを受け付け
- 意図を判断し、適切な専門エージェントに振り分ける
- 採用活動エージェント
- 勤怠管理エージェント
- 研修・育成エージェント
- オンボーディングエージェント
- 問い合わせ対応エージェント
- …etc
この構成自体には特に違和感はありません。
ただ、問題は、各エージェントの「中身」を紐解いたときに見えてきます。
2. 各エージェントの「中身」、全部AIになっていませんか？
各エージェントの中身を見てみると、こうなっていることが多いのです。
ここでは「従業員オンボーディング（IT環境セットアップ）」を例に取り上げます。新入社員が入社する際のIT環境セットアップのプロセスです。
| # | プロセス | 内容 |
|---|---|---|
| 1 | 情報受付 | 部署・役職・必要アプリをヒアリング |
| 2 | 上長承認 | マネージャーへ承認依頼→承認/却下 |
| 3 | アカウント作成 | Entra ID ユーザー作成 |
| 4 | ライセンス割当 | M365 ライセンス付与 |
| 5 | セキュリティ設定 | セキュリティグループ追加・条件付きアクセス適用 |
| 6 | 社内システム登録 | API非対応のレガシー社内システムにGUI操作で登録 |
| 7 | Welcome通知 | Teams/メールでオンボーディングガイド配信 |
| 8 | Q&A対応 | 入社者からの質問対応・セットアップ状況確認 |
この8つのプロセスを全てAIエージェント（Copilot Studio）で実行する。
これが「全部AIにやらせる」パターンです。
一見、シンプルで良さそうに見えます。では、何が問題なのでしょうか。
3. AIは汎用性が高い。しかし、完璧ではない
ここで重要なのは、AIエージェント（LLM）の特性を正しく理解することです。
AIエージェントは 確率的（probabilistic） な仕組みです。同じ入力に対して、毎回完全に同じ出力が返るとは限りません。
一方、コード実行（PowerShellコマンド）やローコード/ノーコードの自動化フロー（Power Automate）は 決定論的（deterministic） です。同じ入力には、必ず同じ結果が返ります。
つまり、AIにも得意不得意があるのです。
| 特性 | AIエージェントが得意 | 従来型自動化が得意 |
|---|---|---|
| 処理の性質 | 対話、判断、文脈理解、柔軟な対応 | 定型処理、一括実行、ルールベースの分岐 |
| 出力の一貫性 | 揺らぎがある（probabilistic） | 毎回同じ（deterministic） |
| 適した場面 | 曖昧な入力の解釈、例外対応 | 手順が明確な処理、大量実行 |
人がヒューマンエラーを起こすように、AIもエラーを起こします。
同じ作業を依頼しても、結果が異なることがあります。
であるならば、確実にできる処理は確実な手段で実行する方が、全体の品質は上がるはずです。
4. AIエージェントに「楽をさせる」設計
ここで設計していきたいのが、業務プロセスを分解し、各プロセスの性質に合ったツールを割り当てるアプローチです。
先ほどのオンボーディングの8プロセスを、Microsoft製品で以下のように振り分けます。
| # | プロセス | 担当ツール | 選定理由 |
|---|---|---|---|
| 1 | 情報受付 | Copilot Studio | 対話でのヒアリング、意図の理解が必要 |
| 2 | 上長承認 | Power Automate | 承認フローは定型。監査ログ付きで確実に動く |
| 3 | アカウント作成 | PowerShell |
New-MgUser で毎回100%同じ結果 |
| 4 | ライセンス割当 | PowerShell |
Set-MgUserLicense で確実に付与 |
| 5 | セキュリティ設定 | PowerShell | SG追加・CA適用もコマンドで一括実行 |
| 6 | 社内システム登録 | Power Automate Desktop (RPA) | APIがないレガシーシステムのGUI操作 |
| 7 | Welcome通知 | Power Automate | 定型メール/Teams通知の配信 |
| 8 | Q&A対応 | Copilot Studio | 入社者との対話、状況に応じた柔軟な回答 |
AIエージェント（Copilot Studio）が直接担うのは、プロセス1（情報受付）とプロセス8（Q&A対応）だけです。残り6プロセスは「自動化ゾーン」として、それぞれの性質に合ったツールが担います。
AIエージェントの視点で見ると、プロセス2〜7を実行する際は、 自動化ツールを「呼び出すだけ」 で良いのです。
5. この考え方は、実はソフトウェア設計の基本原則と同じ
この設計思想は、特に新しいものではありません。ソフトウェアの世界では当たり前に行われていることです。
データベースの設計思想：
1つのテーブルになんでもかんでもデータを入れるのではなく、スタースキーマのようにFact TableとDimension Tableに分離する。それと同じで、1つのAIエージェントにすべてを詰め込むのではなく、適切に分離すべきです。
プログラミングの設計思想：
1つのプログラムに全ての処理をベタ書きするのではなく、再利用可能な処理は関数化して呼び出す。AIエージェントが呼び出す自動化ツールは、まさにこの「関数」に相当します。
つまり、関心の分離（Separation of Concerns） という基本原則をAIエージェントの設計にも適用する、ということです。
6. 業界の識者も同じ方向を向いている（2026年3月時点）
この「決定論的な自動化とAIエージェントのハイブリッド」というアプローチは、2025〜2026年のエンタープライズAI業界で急速に主流化しつつあります。
IDC：「両方を支援するプラットフォームが求められている」
IDCのArnal Dayaratna氏（Research Vice President, Software Development）は2026年3月、Nintexの発表に際して以下のように述べています。
構造化されたプロセスを完全自律型システムに置き換えるのではなく、企業は決定論的アプローチとエージェント的アプローチの両方を単一のオーケストレーションフレームワーク内で支援するプラットフォームを求めている
出典：Nintex Unveils Agentic Business Orchestration Capabilities（2026年3月）
Andrew Ng：Agentic AIの4つのデザインパターン
AI分野の第一人者であるAndrew Ng氏は、Agentic AIの4つのデザインパターンとして Reflection、Tool Use、Planning、Multi-Agent Collaboration を提唱しています。
特に 「Tool Use」 パターンは、AIエージェントがAPI呼び出しや外部ツールとやり取りする設計であり、本記事で提案している「AIエージェントが自動化ツールを呼び出す」アプローチと同じ考え方です。AIエージェントの価値は、全てを自分で処理することではなく、適切なツールを判断して呼び出すことにあります。
出典：Agentic AI - DeepLearning.AI
Gartner：Agentic AIプロジェクトの40%以上がキャンセルされる予測
Gartnerは、Agentic AIプロジェクトの40%以上が2027年末までにキャンセルされると予測しています。その主な原因は、コスト高騰、不明確なビジネス価値、不十分なリスク管理です。
さらに、多くのベンダーが 「Agent Washing」（既存のAIアシスタント、RPA、チャットボットを実質的なエージェント機能なしにリブランディングする行為）を行っており、数千のAgentic AIベンダーのうち、本物と言えるのはわずか約130社だと推定しています。
出典：Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027（2025年6月）
7. メリットとデメリット
このハイブリッドアプローチにはメリットだけでなく、もちろんデメリットもあります。
メリット
1. 各プロセスの品質向上
決定論的な処理は決定論的なツールで実行するため、AIの「揺らぎ」によるエラーを削減できます。人のヒューマンエラー削減と同じ考え方です。
2. 新規エージェント開発の効率化
自動化ツールは複数のAIエージェントから共通で呼び出せます。たとえば、「アカウント作成」のPowerShellスクリプトは、オンボーディングエージェントだけでなく、異動時のアカウント変更エージェントからも再利用可能です。プログラミングにおける関数の再利用と同じです。
3. ランニングコストの削減
AIエージェントが全プロセスを直接実行すると、その分、LLMへのトークン消費量が増えます。プロセスを分解して自動化ツールに委譲することで、AIエージェントが消費するトークンを減らし、ランニングコストを抑えられます。
4. メンテナンス性の向上
たとえば、M365ライセンスの種類が変更になった場合。全プロセスがAIエージェント内にある場合、エージェントそのものを修正する必要がありますが、自動化ツールに分離している場合は、該当のPowerShellスクリプトだけを修正すれば完了です。影響範囲が局所化されます。
8. でも、丸投げしたところで…
デメリットとして「丸投げができない」と書きましたが、正直なところ、AIエージェントに丸投げしても、思っていた結果にならないことが多いのが現実です。
Gartnerが予測するAgentic AIプロジェクトの40%以上のキャンセルも、「全部AIにやらせれば何とかなる」という期待と現実のギャップから来ている部分が大きいのではないでしょうか。
であるならば、最初からしっかりとソリューションを設計し、各プロセスに最適な「武器」を持たせていくべきだと考えます。
9. さいごに：まとめ
本記事で伝えたかったことをまとめます。
AIエージェントは汎用性の高い、強力なテクノロジーです。 しかし、「何でもAIエージェントにやらせる」ことが最適解とは限りません。
業務プロセスを分解し、各プロセスの性質を見極め、最適なツールを割り当てる。AIエージェントには、対話や判断といった「AIでなければできないこと」に集中してもらう。そして、決定論的な処理は決定論的なツールに任せる。
AIエージェントに「楽をさせる」ことで、全体としてより高品質で、低コストで、メンテナンスしやすいソリューションが実現できる。
これは、ソフトウェア設計における「関心の分離」やデータベース設計における「正規化」と同じ、設計の基本原則です。Agentic AI時代においても、この原則は変わりません。
むしろ、AIが登場したからこそ、何をAIに任せ、何をAIに任せないのか — その判断と設計こそが、これからのエンジニアに求められるスキルなのだと思います。
10. さいごのさいごに余談：AIも「混乱」する
最後に、余談をひとつ。
先日、ChatGPTに複雑な業務要件を何度もプロンプトで伝え続けていたところ、思考プロセスにこんな表示が出ました。
「うーん、混乱してきた。」
もちろん、これはLLMの内部推論プロセスであり、人間の感情とは異なります。
しかし、複雑な指示を大量に与え続ければ、AIの処理精度が下がるのは事実です。
人が複雑なタスクを抱えすぎると混乱してミスが増えるように、
AIも処理が複雑になればなるほど、期待する結果から外れやすくなります。
だからこそ、AIエージェントに「楽をさせる」設計が大事なのだと思います。