日本マイクロソフトが2026年7月27日、「日経225企業の87％がAIエージェントを活用」というブログ記事と記者説明会で、国内企業のAIエージェント活用状況と自社製品を説明した。AIエージェントの社内導入がどこまで進んだのか、そして進んだ先に何が起きるのかを、エージェントを受託で作っている側から読む。
出典: 日経225企業の87％がAIエージェント活用、カギは「組織の再設計」――日本マイクロソフト
要点 (出典に書かれている事実)
- 日本マイクロソフトは2026年7月27日、「日経225企業の87％がAIエージェントを活用」と題するブログ記事を掲載し、同日に記者説明会を開催した。説明したのは同社 業務執行役員 AI Workspace GTM本部 本部長の山田恭平氏。
- 日経225企業の87％がAIエージェントを活用しており、そのすべてが市民開発したカスタムAIエージェントを利用しているという。
- 「Microsoft 2026 Work Trend Index」では、65％（日本でも65％）が「今すぐAIに適応しないと遅れる」と考える一方、45％（日本では30％）が「仕事のやり方を変えるより今の目標を守るほうが安全」と感じ、「AIで仕事を再設計することが評価される」と感じているのは13％（日本では8％）にとどまる。
- 同レポートでは、AIの効果を左右する要因のうち個人要因が32％、組織要因が67％。山田氏は「AI活用の課題は、もうツールがないことではなく、実際に組織がAIを生かせる設計になっているかが本質的な課題だ」と述べた。
- 製品面では、チャット型の「Copilot Chat」、マルチステップ作業を実行する「Copilot Cowork」（6月に一般提供開始）、ローカルとクラウドを横断して自律実行する「Microsoft Scout」（Frontierプログラムで提供）の3段階を提示。Copilot CoworkとMicrosoft Scoutは、それぞれClaude CoworkとOpenClawの技術をベースにしていると説明された。
- 事例として、りそなグループが融資・住宅ローン・企業年金・iDeCoの4領域でCopilot Studioによる市民開発を実施。株式会社INPEXはタスクフォース「AIR」を設置し、1000を超えるAIエージェントを社内開発して年間20億円超の効果を創出したという。
徐 聖博の見解
87％という数字そのものには、正直あまり驚かない。「市民開発したカスタムエージェントを含む」という定義なら、Copilot Studioが配られている大企業でその水準に達するのは自然だ。私が引っかかったのは別の2つの数字である。組織要因67％に対して個人要因32％、そして「AIで仕事を再設計することが評価される」と感じている人が日本では8％しかいない、という組み合わせだ。
これは要するに、ツールは配られ、現場は使い、しかし評価制度は旧来の目標のままだ、ということである。日本では45％ではなく30％が「今の目標を守るほうが安全」と答えているので、保守的だから進まないのではない。むしろ「変えたい人はいるが、変えたことが評価される設計になっていない」。山田氏の言う「組織の再設計」は、この評価と職務定義の話まで含めて初めて意味を持つ。ツールベンダーの主張としては珍しく、率直だと思う。
「1000個作った」の次に来るのは、誰が止めるかという問題
INPEXの1000超のエージェント、年間20億円超という数字は、事例として強い。ただ、エージェントを受託で作る側にいる人間としては、この数字を成果としてだけ読むのは危ういと考えている。
私たちがPoCから本番に上げるときに毎回詰まるのは、精度ではない。権限設計・ログ・停止条件である。誰の権限でどのデータを読むのか、誰かが困ったときに何を見れば原因が分かるのか、そして要らなくなったエージェントを誰がどう止めるのか。1体ずつなら人間の記憶で回るが、市民開発で数百・数千体になった瞬間、これは記憶では回らない。棚卸しの仕組みを持たない組織の1000体は、数年後には「誰も所有者が分からない、しかし止めるのが怖いエージェント群」になる。
Microsoft自身の事例で、サポート窓口業務を数十のプロセスに分解してから、AIが効く工程を特定して3体だけ作った、という話が出てくる。個人的にはこちらのほうがはるかに再現性が高い。先に業務を分解し、効く場所を絞ってから作っている。数を誇る話とは順序が逆だ。この「作る前に業務を分解する」順序については、そのシステム開発、本当に必要ですか——「言われた問題」を疑う進め方でも書いた通りで、AIエージェントでも前提は変わらない。エージェントを大量展開したときの監視側の問題はAIエージェントが壊す「人間スケール前提」の監視基盤に詳しい。
SIer・開発会社にとっての含意——受注ポイントが移動している
ここからは、同じように開発を生業にしている会社の経営・事業責任者に向けた話だ。
この発表を素直に読むと、エージェント単体の実装は、市民開発とCopilot Studioに食われていく。日経225企業の87％が既に市民開発でやっている領域に、「エージェントを1体作ります」という提案を持ち込んでも単価は上がらない。実際、りそなグループの4領域も業務部門の担当者自身が作っている。
一方で、組織要因67％の部分——業務の分解、権限とデータソースの設計、エージェントの棚卸しと廃止フロー、効果測定の設計——は、Copilot Studioを配っただけでは埋まらない。そしてここは、社内に専任を置きにくい領域でもある。つまり開発会社の受注ポイントは、「エージェントを作ること」から「エージェント群を運用可能な状態に保つこと」へ移る。後者は継続契約になりやすく、単価も落ちにくい。自社の商品設計をここに寄せられるかどうかが、今後1〜2年の差になると私は見ている。
ただし注意点がある。「組織の再設計」は外部ベンダーが最も売りにくい商材でもある。顧客の評価制度や職務定義に踏み込む提案は、情シス部門との商談だけでは決まらない。売るなら経営レイヤーに接続する必要がある。この構造は野村不動産HDが技術選定より先に「定義」と「やらないこと」を決めた事例や、三井倉庫×日本IBMの現場社員が業務アプリを自作するDX人材育成を見ても同じで、入口が現場か経営かで到達点が変わる。
作る側として——差別化はモデルではなくデータ接続に移った
もう1点、作る側として見逃せない開示があった。Copilot CoworkとMicrosoft Scoutが、それぞれClaude CoworkとOpenClawの技術をベースにしていると明言されたことだ。
つまりMicrosoftですら、エージェントの実行エンジン部分は自前で囲い込んでいない。そのうえで差別化点として挙げたのが、Microsoft 365のメール・チャット・カレンダー・ファイルとの連携であり、「Microsoft IQ」（Work IQ / Fabric IQ / Foundry IQ / Web IQ）という業務文脈の理解層だった。
自社で同じものを作るとしたら何が難所か、と考えると答えは明確で、エージェントの実行ループではなく、業務文脈をどう保持するかである。モデルもエージェントフレームワークも、今はコモディティに近い。勝負は、顧客の業務データにどう安全に接続し、誰が何を見てよいかをどう表現するかにある。ここはAIエージェント活用の本質はデータ基盤設計にあるで扱った論点と完全に地続きだ。低コード内製とデータ整備の順序についてはスマートファクトリーの事例に学ぶ実装の中身も参考になる。
まとめ
87％という普及率の数字は、もう議論の起点にならない。問うべきは、作ったエージェントの所有者と停止条件が決まっているか、業務を分解してから作っているか、そして再設計した人が評価される制度になっているか、の3点だ。開発を請ける側から見れば、この3点こそが次の商品領域である。
(編集レンズ: 作る側の目線 / 発注側・開発実務への含意 / 組織・人材)
