従業員が自分でAIエージェントを作れるようにすると、数はすぐに増えます。困るのは増えることではなく、増えたもののうちどれを業務に使ってよいのかを決める仕組みが無いことです。米国の保険会社State Farmは、この順序を先に決めていました。作れる人を増やす前に、リスク審査を通す道筋と、そこを通れる作り手を育てる場を用意しています。
Microsoftが2026年8月11日に公開した導入事例には、リスク審査を通って本番で動いているものが41件、Power Platformの環境の中にあるAIエージェントのIDが3,000を超える、と書かれています。用途の1つは翻訳で、マーケティング資料を英語とスペイン語のあいだで訳す作業が、12か月から24時間になりました。
この記事で扱えるのは、この導入事例とMicrosoftの公式ドキュメントに書かれている範囲だけです。費用、投資の回収、削減された人数や人件費は、どちらにも書かれていません。読みどころは削減の幅ではなく、作れる人を増やす前に何を用意したのかという順序のほうにあります。確認日は2026年9月12日です。
公表されているのは「本番41件」という数字
State Farmは、自動車・住宅・生命・医療などの保険を扱う米国の大手保険・金融サービス会社です。本社はイリノイ州Bloomingtonにあり、導入事例には従業員がおよそ65,000人と書かれています。
数字として明示されているのは次の3つです。
| 公表されている値 | 何の数か |
|---|---|
| 41 | リスク審査を通り、本番で動いているビルドの数 |
| 3,000超 | Power Platformの環境の中にあるAIエージェントのIDの数 |
| 12か月 → 24時間 | 翻訳にかかっていた期間と、いまの期間 |
ここで単位が違うことに注意してください。41は「リスク審査を通った本番のビルド」、3,000超は「エージェントのID」です。導入事例は2つを並べて比率として示していません。したがって「3,000作って41通った」という通過率として読むことはできません。審査に出した件数も、落ちた件数も書かれていないためです。
それでも、この2つの数が同じページに並んでいること自体に意味があります。試しに作られたものと、業務で使ってよいと認められたものは別の数で管理されている、ということが読み取れるからです。社内でエージェントの数を成果として報告するときに、どちらの数を出しているのかは確認する価値があります。
マーケ資料の翻訳は12か月から24時間になった
導入事例には、実際に作られたエージェントの用途がいくつか挙がっています。マーケティングの担当者にとって近いのは翻訳です。
翻訳エージェントは、マーケティング資料を英語とスペイン語のあいだで翻訳する作業を、メールを使った流れの中で受け持ちます。導入事例は、これによって翻訳の所要期間が12か月から24時間へ短くなったと書いています。
この数字の読み方には前提が要ります。12か月という長さは、翻訳そのものにかかっていた時間というより、依頼から手元に戻るまでの待ち行列を含んだ期間だと考えるのが自然です。ただし対象の資料量、依頼の出し方、品質を誰が確認しているのか、24時間の内訳は導入事例に書かれていません。そのため、この値を自社の翻訳費用の削減見積もりにそのまま持ち込むことはできません。
翻訳のほかに挙がっているのは次の3つです。
1つ目はHRです。「Ask HR policy agent」は、従業員がHRの担当者へ個別に連絡する代わりに、人事の規程や福利厚生について質問できるようにしたものです。担当者のAzsure Dortonさんは “This has saved our HR department a lot of time, and it’s also helped employees feel confident in finding the information they need on their own.”（HR部門の時間をかなり節約できたし、従業員が必要な情報を自分で見つけられるという自信にもつながった）と述べています。
2つ目は生命保険の引受です。データサイエンティストが、大きくて探しにくいマニュアルの中にあった引受の基準を検索できるエージェントを作りました。導入事例によれば、このエージェントは30日で社内で2番目によく使われるものになっています。
3つ目はコンテンツの点検です。書き手が自分の原稿を社内の基準と照らし合わせるエージェントで、そのために別のライセンスを用意する必要がなくなった、と書かれています。マーケティングの現場で言えば、表記ゆれや禁止表現の確認を人に回す前に自分で済ませられる、という形になります。
統治を最初に置いたから、現場が動けた
導入事例の中心にあるのは、個々のエージェントではなく統治のほうです。Dortonさんの言葉は “Getting governance, risk, and responsible AI right is an important part of the journey.”（統治、リスク、責任あるAIを正しく扱うことが、この道のりの重要な一部だ）というものです。
導入事例は、State Farmでは統治が制約ではなく加速装置として働いたと書いています。理由として挙げられているのは3つで、承認の道筋がはっきりしていたこと、リスク部門やコンプライアンス部門と近い距離で足並みをそろえたこと、責任あるAIについて実務で使える指針があったことです。作り手の側のためらいが減り、役に立つ案を本番へ運べるようになった、という順序で説明されています。
育て方も同じ考え方で作られています。ワークショップは責任あるAIの原則から始め、そのあとで手を動かす構成になっており、Microsoftが用意したラボを土台にしながら、State Farmの統治の要件に合わせて中身を作り替えています。開催の規模は、オンラインと対面を合わせて最大150人に達することがあると書かれています。加えてオープンオフィスアワーがあり、新しい作り手も経験のある作り手も、作りかけのものを見せ合い、助けを得られる場になっています。
技術ディレクターのBrad Houseさんは “We are energized by Power Platform adoption at State Farm and look forward to exploring new AI capabilities that can empower our employees and deliver greater value for our customers.” と述べています。ここで語られているのは導入の規模ではなく、従業員が使える力と顧客に届く価値です。
なお、現場の担当者が自分でエージェントを作る形そのものは、他社でも公表されています。製造・物流の現場へ広げた例はGE AppliancesがGemini Enterpriseでエージェントを配った事例で扱っています。配る前に研修を置いた順序についてはPictetが研修を先に置いて社内へ広げた順序が参考になります。
公式ドキュメントは作り手を3つのゾーンに分けている
State Farmが使っているMicrosoft Copilot Studioには、この「作れる範囲をどう分けるか」についての公式ドキュメントがあります。ゾーン別ガバナンスと呼ばれる考え方で、エージェントの目的とリスクの高さに応じて環境を区切り、区切りごとに違う方針を当てます。
前提として、Copilot Studioのエージェントは必ずPower Platformの環境の中で作られ、管理されます。公式ドキュメントは、この環境をデータの境界、セキュリティロール、データポリシー、ライフサイクルの分離を定める論理的な入れ物と説明しています。エージェントのデータがどこに置かれるか、誰が作成や編集をできるか、どのコネクタや連携が許されるか、開発・テスト・本番がどう分離されるかは、この環境が決めます。
ゾーンは3つです。
Zone 1（Citizen Development Zone） は、だれでも作れる範囲です。対象は個人とチームの生産性を上げるエージェントで、すでにその人がアクセスできる内容だけを素材にします。権限は読み取りのみで、エージェントは私的なまま共有されません。
Zone 2（Partnered Development Zone） は、ITが承認した作り手が、ほかのチームや部門に使ってもらうエージェントを作る範囲です。幅広い機能を使える代わりに、ITが管理する審査の手続きを通り、ITが管理する安全な環境へ配置されます。
Zone 3（Professional Development Zone） は、プロの開発者が全社で使う基幹級のエージェントを作る範囲です。組織の標準的なALM（アプリケーションライフサイクル管理）の作法と、いちばん強いセキュリティ統制が使われます。
ゾーンが変わると、公開までの手続きが変わる
同じ「エージェントを作る」でも、ゾーンによって守る仕組みと公開の手続きが変わります。公式ドキュメントが挙げている内容を、作り手から見える形で並べると次のようになります。
| 見るところ | Zone 1 | Zone 2 | Zone 3 |
|---|---|---|---|
| 使えるコネクタ | Microsoft 365とPower Platformのコネクタのみ | ゾーンごとの高度なコネクタポリシー | ゾーンごとのポリシーとMicrosoft Purview |
| 実行の文脈 | 利用者本人の権限の範囲で動く | 承認されたデータソースをチームで共有 | 組織の基準に沿った統制 |
| 置かれる環境 | 開発者用の環境。環境ルーティングで作り手に隔離 | 管理者が承認して用意した環境 | 管理センターの統合アプリで共有を管理 |
| 共有 | 無効。作り手の利用に限定 | 範囲を絞ったロールと共有ポリシー | 管理センター側で制御 |
| 公開 | 個人利用のため公開の手続きなし | 公開にIT管理者の承認。ALMパイプラインで版を管理 | 組織標準のALMの作法に従う |
| 見張り方 | Power Platform管理センターのCopilot領域で利用状況を確認 | 管理センター・Purview・Power Platform管理センターで追跡 | Zone 2と同じ場所で追跡 |
この表で実務上いちばん効くのは、Zone 2の「公開にIT管理者の承認」とALMパイプラインです。誰でも作れる状態を保ったまま、他人に使わせる段階だけに審査を置く形になっています。State Farmの「41件が審査を通って本番にある」という書き方は、この構造と重なります。
個人から始めて、部門、そして全社へ
Dortonさんは、作り手の育て方をこう表現しています。“Start for yourself. Build for your team. Build for your department. Then you begin to see where an enterprise idea takes shape and can grow.”（まず自分のために作る。次にチームのために作る。次に部門のために作る。そうすると、全社規模の案がどこで形になり、育っていくのかが見えてくる。）
導入事例は、作り手を急いで本番へ押し出すことが目的ではなかった、と明記しています。狙いは自信と良い習慣を先に身につけてもらうことで、規模を広げるのはそのあとでした。
再利用の仕組みも置かれています。導入事例によれば、State Farmはカタログの機能を使って、コネクタや解決策をチームのあいだで共有できるようにしました。ある短期集中の取り組みからは、Power Apps・Power Automate・Copilot Studioを組み合わせた入社と退社の手続きの再利用できる部品が生まれています。誰かが作ったものを次の人が土台にできる状態は、審査を通る作り手を増やすことと同じ方向を向いています。
次の段階についてもDortonさんの言葉が載っています。“Right now, we’re looking at moving past those conversational or knowledge-retrieval AI agents towards more complex, action-oriented or autonomous AI agents.”（いまは、会話や知識の検索をするAIエージェントから先へ進み、もっと複雑で、行動を伴う、あるいは自律的なAIエージェントへ向かおうとしている。）自分のサイト向けのアシスタントを役割別に作り替えた例はMicrosoftがAsk Microsoftをサブエージェントへ分けた事例で扱っています。
公表されていないこと
判断に使う前に、確認できた項目とできなかった項目を分けておきます。
| 項目 | 状態 |
|---|---|
| 本番で動いているビルドの数 | 41件（審査に出した件数・落ちた件数は記載なし） |
| エージェントのIDの数 | 3,000超（41件との関係は記載なし） |
| 翻訳の期間 | 12か月 → 24時間（対象の資料量・品質確認の担当・内訳は記載なし） |
| 引受のエージェントの利用 | 30日で社内2番目（利用回数の実数は記載なし） |
| ワークショップの規模 | 最大150人（開催回数・累計の参加者数は記載なし） |
| 費用・投資の回収 | 記載なし |
| 削減された人数・人件費 | 記載なし |
| 審査にかかる期間 | 記載なし |
導入事例は、Microsoftが自社製品の利用を紹介するために公開しているものです。第三者が検証した数値ではないことを前提に読む必要があります。
日本の実務者が明日確認できること
自社へ持ち込めるのは、数値ではなく順序のほうです。マーケティング部門でAIエージェントを増やしたい担当者が、今日の時点で確認できることを4つ挙げます。
1つ目は、いま社内で数えている「エージェントの数」がどちらの数かを確かめることです。作られた数なのか、他人に使わせてよいと認められた数なのか。State Farmの公表の仕方は、この2つを分けて持つ形になっています。混ざったまま報告されている場合、増えた分が成果なのかリスクなのかを誰も判断できません。
2つ目は、他人に使わせる段階に審査を置くことです。公式ドキュメントのZone 1とZone 2の違いは、能力の差ではなく、利用者が自分だけか、他人が含まれるかです。自分のためだけに作るものまで審査に回すと、作り手が減ります。他人に使わせるものを無審査で出すと、後から止められません。線はこの境目に引くのが、公式ドキュメントの考え方です。
3つ目は、責任あるAIの話を、作り方の研修の前に置くことです。State Farmのワークショップは原則から始めて手を動かす順序で作られていました。逆にすると、動くものができてから制約を告げることになり、作り直しが発生します。
4つ目は、再利用できる形で残すことです。カタログで解決策を共有する、入社と退社の手続きのように部品化する。1人が作ったものが次の人の土台になる状態は、審査を通る作り手が増える速度をそのまま上げます。
最後に注意点を1つ置きます。ここで紹介した数値は、いずれもState Farmという特定の会社が、特定の製品構成のもとで公表したものです。同じ手順を踏めば同じ結果になると約束するものではありません。効果は扱う業務の内容と運用の作り方によって変わります。参考にできるのは、作れる人を増やす前に通り道を決めたという設計の順序であり、12か月が24時間になるという幅のほうではありません。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。
あわせて読みたい
現場が自分でAIを作る。GE Appliancesが800超のエージェントを配った設計 米GE AppliancesはGemini Enterpriseで800を超えるAIエージェントを製造・物流・調達に展開したと公表しました。誰が作り、何に使い、どこまでが公表された結果なのかを公式発表の範囲で整理します。
配る前に研修25回。Pictetが約700人へ広げた順序 スイスのPictetは、Claude CodeとClaude Coworkを約700人へ配る前に、ハッカソンと25回のワークショップを置きました。公表されている展開の順序と、EU・スイス内で処理するという条件を整理します。
サイト全体を1体に読ませない。MicrosoftがAsk Microsoftを作り直した Microsoftのマーケティング部門は、サイト全体を1体に読ませていた自社サイトのAIアシスタントを、役割別のサブエージェントへ作り直しました。公表された4つの数値と、公式ドキュメントが認めている制約を整理します。