はじめまして、JBSの窪田です。
この度、JBSとアバナード株式会社（Avanade Japan K.K.）の共同企画として、AIエージェントの「管理と統制」にフォーカスしたブログ連載をスタートします。
Microsoft Agent 365（Agent 365）やEntra Agent ID（Agent ID）といったマイクロソフトの最新テクノロジーをベースに、企業がAIエージェントを安心してスケールさせるための統制基盤を、構想から実装・運用まで一貫して支援する取り組みです。
本連載では、その取り組みの背景にある課題感から、Agent 365等のリアルな検証情報まで、順次お届けしていきます。
初回となる今回は「ビジネス編」です。技術的な話に入る前に、そもそもなぜAIエージェントには統制基盤が必要なのか、2025年の振り返りを通じて整理します。
それでは、本題に入りましょう！
※ 本記事では、生成AIで作成した画像を使用しています。
※ 過去記事はこちら
- 「AIエージェント元年」の通信簿
- 壁1：仕事の「渡し方」が雑だった ── Human-in-the-Loop設計の不足
- 壁2：管理する仕組みがなかった ── セキュリティ・ガバナンスの構造的不在
- まとめ：2つの壁を、どう乗り越えるか
- 次回予告
「AIエージェント元年」の通信簿
「AIエージェントを導入したんですが、結局、誰も使っていないんですよ」
2025年後半から2026年にかけて、お客様と会話するなかで、私自身何度も耳にしたフレーズです。
数千万円かけてPoCを回し、デモも大成功、経営層のGOも出て実行に移したはずなのに、半年後現場の利用率は10%を切ってしまう、といったケースは残念ながら珍しくありません。
2025年は間違いなく「AIエージェント元年」でした。
OpenAI、Google、Microsoft、Anthropicをはじめとする大手ベンダー各社がエージェント製品を次々に発表し、技術の進化は目覚ましいものがありました。
Microsoftだけでも23万以上の組織がCopilot Studioでエージェントを構築し、作成されたカスタムエージェントの総数は300万体を超えたという発表もありました。
IDCは2028年までに世界で13億のAIエージェントが稼働すると予測しています。
しかし現実はどうだったでしょうか。
McKinseyが2025年11月に発表した調査では、AIエージェントを試行中の組織は62%に達する一方、全社規模でスケーリングできた企業はわずか7%、米国の大手金融機関BNYでさえ、本番稼働はたったの100体です。
引用: McKinsey The state of AI in 2025
正直に言いましょう。
「AIエージェント元年」の実態は、「AIエージェントの導入に向けた準備年」でした。
では、なぜこうなってしまったのか。私は大きく2つの構造的な壁があったと考えています。
壁1：仕事の「渡し方」が雑だった ── Human-in-the-Loop設計の不足
まず一つ目の壁。これは端的に言うと、AIへの仕事の渡し方の問題です。
AIエージェントの生成物は、体感で平均70点程度です。
ゼロから人間が作るよりは速いですが、その70点を90点に仕上げる「後始末」が、現場の担当者にとって予想以上に重くのしかかります。
たとえるなら、超優秀だけど入社初日の中途社員に、いきなり「あの案件よろしく」と丸投げするようなものです。
AIは地頭はよく、処理速度も圧倒的に早いです。しかし「部長は慎重派だからこの表現は避けて」「競合名は社内では出さない暗黙ルールがある」なんて、誰も教えていません。
結果、アウトプットのそこかしこに穴が空いていて、上司が全部チェックして直す羽目になるわけですが、そうなると「自分でやったほうが早い」に着地するのは、ある意味当然です。
一方で、2025年に確実に成果を出していた領域もあります。
たとえば、要約や定型文書のレビュー、公開情報のリサーチ、テストケースの生成などです。
これらに共通するのは、判断の拠り所となる情報が明示的に与えられていて、人間の「察し」を必要としないという特徴です。
つまり解決策は、AIの性能が上がるのをじっと待つことではありません。仕事をタスクに分解し、AIに渡す工程と人間が担う工程を明確に設計することです。
いわゆるHuman-in-the-Loop（HITL）の設計力こそが、定着のカギだったのです。
HITLをどう実践するか
では、具体的にどう設計すればよいのでしょうか。
私がお客様にお伝えしているのは、まず「ROIインパクト」と「HITL設計のしやすさ」の2軸で業務を評価し、優先順位をつけるということです。
一足飛びに全業務を自動化しようとするのは、失敗パターンの典型です。まずは必要な情報と判断基準が比較的はっきりしており、人間の確認ポイントも設計しやすい業務から始めることが大切です。
たとえば、ROIに直結しやすい営業業務があります。
商談方針やヒアリング設計、商談内容の要約、SFA/CRMへの自動入力、次回アクションの整理、提案書レビュー、案件リスクの一次判定などが該当します。
こうした領域では、AIが一次処理を行い、営業担当者が内容を確認・補正し、マネージャーがその情報をもとに介入判断を行います。さらに、その判断結果や次回アクションが次の商談準備に反映されます。
このように、AIの出力が単発の効率化で終わらず、営業サイクルの次のアクションにつながる業務ループとして設計することが重要です。
JBSも社内でこのアプローチを実践しています。
たとえばSales AIgentという営業支援AIは、商談前には顧客情報や過去の接点をもとに商談指示書、商談資料を作成し、商談後には議事録生成、SFA/CRM自動入力、ネクストアクションを整理します。
営業担当者はそれを確認・補正し、マネージャーは案件状況やリスクの兆候をもとに、どの案件に介入すべきかを判断します。
さらに、その介入内容や次回アクションは、次の商談準備や提案書レビュー等に反映されます。
つまり、Sales AIgentは単に営業情報を集めるツールではなく、「商談 → 記録 → 判断 → 介入 → 次の商談準備」という商談サイクルの全てに連続的にAIを組み込むことで、人間の判断を支援する仕組みとして活用しています。
これにより、営業業務（商談関連）において30～40％の業務効率化効果と、商談の質向上による商談機会の増加につながっています。
地味ですが、生成AI活用で成果を出している企業は、例外なくこのように「AIが処理する領域」と「人間が判断する領域」を連続する業務の中で細かく定義し、AIの出力を次の業務アクションに接続する形で、業務ループそのものを再設計しています。
適切なHITLは「やると決めれば終わる」話ではない
ここで一つ補足しておきたいことがあります。
HITL設計は概念としてはシンプルですが、実際にやろうとするとかなり泥臭い仕事です。
考えてみてください。
既存の業務フローを可視化し、タスク単位に分解し、それぞれについてAIの得意・不得意を見極め、チェックポイントを設計し、例外処理のルールまで決める必要があります。
これは、実質的に業務プロセス全体のBPR（Business Process Re-engineering）です。
しかも、AIの最新テクノロジーが「今どこまでできるのか」を正確に把握した上で設計しなければ、絵に描いた餅になったり、実装できてもすぐに陳腐化します。
「AIエージェント導入」と聞くとテクノロジーの話に聞こえますが、この壁の本質は業務変革です。
現場の暗黙知を引き出し、AIと人間の最適な役割分担を設計し、評価制度や承認フロー、文化的要因も含めて再設計が必要です。
緻密な設計図なしに進めれば、関係各所に混乱を招く可能性があるため、計画的な設計が重要です。
だからこそ、数多くの企業で業務変革を支援してきた実践的な経験値が問われます。
この壁は人と組織の領域である分、すぐに着手することはできますが、「正しく」乗り越えるには、相応のノウハウが必要です。
壁2：管理する仕組みがなかった ── セキュリティ・ガバナンスの構造的不在
そして二つ目の壁。こちらは正直、一つ目よりも深刻だと私は考えています。
なぜなら、企業の意思だけでは解決できない「基盤の問題」だからです。
少し想像してみてください。
AIエージェントは従来のシステムとは根本的に異なり、人の操作を待たずに自ら判断し、自ら行動します。この「自律性」こそがAIエージェント最大の価値であり、同時に最大のリスクです。
こんなシナリオはどうでしょう。
営業支援エージェントが業務効率化のために、独自の判断で顧客の機密データを外部のクラウドサービスにアップロードしてしまいました。
あるいは、本来アクセスすべきでない人事情報の領域にアクセスしてしまいました。
しかも厄介なのは、そのエージェントがどのデータに触れ、何を外部に送ったのか、追跡する手段がないことです。
これはもはやIT部門の問題ではありません。
法的・財務的・レピュテーション上の経営・監査リスクです。
EU AI Actや2025年6月に日本で公布された「人工知能関連技術の研究開発及び活用の推進に関する法律（AI新法）」の動きを見ても、「AIが何をしたか説明できること」は、もはやオプションではなく義務になりつつあります。
AIエージェントのセキュリティは、「人と同じ」に考える
ではこのリスクにどう向き合えばよいのでしょうか。
ここで重要なのは、AIエージェントを「人間の社員と同じ枠組み」でセキュリティ管理するという発想です。
現代のエンタープライズセキュリティの基本はゼロトラストです。
「社内ネットワークだから安全」ではなく、すべてのアクセスを都度検証し、最小限の権限だけを付与します。人間の社員に対しては、多くの企業が既にこの考え方を適用しています。
AIエージェントも同じです。むしろ、自律的に動く分だけ人間以上に厳密な管理が求められます。
エージェント一体ごとに固有のIDを発行し、「誰が（どのエージェントが）」「いつ」「何のデータに」「どの権限で」アクセスしたのかを常時追跡できる状態にします。また、不審な挙動があれば即座にブロックし、事後に監査できるログを残すようにします。
つまり、従来の「人のID管理」をAIエージェントにまで拡張するアプローチです。
人間の社員に社員証を発行し、入退室を管理し、アクセス権限をコントロールしているのと同じことを、AIエージェントにも行う必要があります。
そしてこの考え方を基盤として持っていれば、エージェントの「登録→権限付与→運用→監視→停止→廃棄」というライフサイクル全体を一貫して管理できるようになります。
「作れるけど管理できない」 2025年に欠けていたもの
考え方として、ゼロトラストにAIエージェントを準拠させるべき、という方向性は明確になりました。
しかしここ最近まで、このゼロトラストの考え方をAIエージェントに適用するためのテクノロジーや基盤が存在しなかったことが最大の問題でした。
今やローコードツールを使えば、エンジニアでなくともAIエージェントを作れます。これ自体は素晴らしいことです。
しかし裏を返すと、IT部門が知らないうちに各部署で次々とエージェントが生まれるということでもあります。
作成者が異動したり退職したりすれば、所在も中身も不明な「野良AIエージェント」が社内に増殖し、「誰がいつ、何のために作ったのか」すら把握できません。
これはまるで、社員名簿も社員証もないまま社員を増やし続けている会社のようなものです。
ゼロトラストどころか、トラストの前提すら作れていない危険な状態です。
さらに厄介なのは開発基盤のマルチベンダー化です。Microsoft、Google、OpenAI、オープンソースなど、基盤ごとに管理体系が違うものを、人手で横串管理しようとすれば確実に破綻します。
エージェントが数百、数千に増えたときに本当に必要なのは、エージェントに対してもゼロトラストを実現するための具体的な仕組みです。すなわち、ライフサイクル全体を管理する基盤と、開発基盤を問わず一元的に管理できる仕組みの2つです。
この2つが最近まで存在しなかったことが問題でした。
これこそが、多くのエージェントが作成されたものの、継続的に使われるものが少なかった、最大の構造的原因だと私は考えています。
まとめ：2つの壁を、どう乗り越えるか
ここまでお伝えした内容を整理しましょう。
AIエージェント元年が「着手元年」に留まった原因は、以下の通り大きく2つの壁に集約されることをお伝えしました。
- 壁1 HITL設計の壁：人と組織の領域の壁
- 既存業務を可視化し、AIと人間の最適な役割分担を再設計するという、本質的にはBPRそのもの。
- 着手すること自体は可能だが「正しく」乗り越えるには、最新のAIテクノロジーへの理解と、数多くの現場で培った業務変革の経験値が不可欠。
- 壁2 セキュリティ・ガバナンスの壁：意思だけでは解決できない壁
- AIエージェントを人間と同様にゼロトラストの枠組みで管理する。
- そのためのID管理、アクセス制御、行動監視、監査証跡を実現するには、統制基盤なしには構造的に解決不可能。そして放置すれば、経営レベルのリスクに直結しうる。
Microsoftが用意した答え：Agent 365という解決策
ここからは、これらの壁に対する解決策についてお話しします。
まず、この壁2に対するマイクロソフトの回答が、2025年11月のIgnite 2025で発表されたMicrosoft Agent 365です。
主なAgent 365の機能と役割です。
- Registry：エージェントの台帳管理
- Entra Agent ID：専用IDによるアクセス制御
- Visualization：ダッシュボードでの可視化
- Interoperability：マルチベンダー（マルチモデル）対応のSDK
- Security：Defender/Purviewによるセキュリティ対応
大きく5つの特徴があり、先ほど述べた「AIエージェントへのゼロトラスト適用」を具体的に実現し、セキュリティ・ガバナンスを含めたライフサイクル全体をカバーするエンタープライズ向けの管理基盤です。
日本の大企業の多くが既にAD DSやEntra IDで従業員のID管理を運用している現状を考えると、AIエージェントの管理もこの延長線上に統合するのが最も合理的な選択肢でしょう。
「人間の社員」と「デジタル社員（AIエージェント）」を同じID体系・同じセキュリティポリシーで一元管理できます。これは別基盤を新設するよりも、はるかにシンプルです。
JBS × アバナードが、なぜこの領域で力を発揮できるのか
ただし、製品があるだけでは壁は越えられません。
- 壁1：HITL設計
- 先ほど述べた通り業務プロセス全体のBPRに踏み込む領域であり、最新のAIテクノロジーを熟知した上で現場の業務を再設計する経験値が求められる。
- 壁2：統制基盤構築
- AIに対する知識だけでなく、多層的なセキュリティの考え方から、MicrosoftテクノロジーとID管理への深い実装力が不可欠。
この両方をカバーできるパートナーはなかなかいません。コンサルタントは壁1に強い反面、システム基盤の構築・運用が手薄になりがちですし、SIerは壁2が得意でも、人と組織の業務変革設計には踏み込みにくい。
そこで、JBSとアバナードが連携することにより双方の課題を解決します。
- アバナード
- マイクロソフトテクノロジーを軸にした戦略・コンサルティングの知見。
- 業務変革の構想設計からガバナンス・セキュリティ設計まで、グローバルで蓄積された経験値をもとに「スピードと統制の両立」を設計する力を持つ。
- JBS
- Active Directory/Entra IDをはじめ、多くのMicrosoft Cloudサービスの導入・運用で国内トップクラスの実績を持つ実装力を持つ。
- Agent 365の早期アクセスプログラム（Frontier）にも参加し、自社環境で実機検証を進めている。
この2社が手を組むことで、壁1の業務設計から壁2の基盤構築・運用定着まで、一気通貫で支援できる体制が整ったのです。
次回予告
次回以降の記事では、Agent 365のコントロールプレーンとしての全体像から、主要機能を実際に検証していきます。
Copilot StudioやAzure AI Foundryでエージェントを作成し、Registry上でどんな情報が見えるのかなど、カタログスペックではなく、触ってみて初めてわかる「使い勝手」をお伝えします。
「見えないものは守れない」
まずは全体を可視化すること。それが、すべての出発点です。
次回もぜひお楽しみに！
