結論を先に
情シス業務にAIアシスタントを噛ませたランダム化比較試験(181名)で、正答精度は平均34.53%改善、時間は29.79%短縮しました。ただし効いたのは複数のログやポリシーを横断して要点をまとめる自由記述型の作業(事実抽出数+146.07%、時間-61.14%)であり、選択肢が最初から絞られた多肢選択型では精度改善は統計的に有意でなく、時間はむしろ25.13%増加しています。導入判断は「AIを入れるか」ではなく「どの業務に入れるか」です。
(出典:Microsoft Corporation(James Bono、Alec Xu)/2024年11月/©2024 Microsoft Corporation、2024-11、https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/final/en-us/microsoft-brand/documents/Randomized-Controlled-Trials-for-Security-Copilot-for-IT-Administrators-V5-FINAL.pdf)
まず、この数字の出どころを明かします
読み進める前に、必ず押さえておくべき前提が2つあります。
ひとつめ。この記事は Microsoft 社自身による発表であり、同社は当該製品(Microsoft Security Copilot)の提供者である。 執筆者は James Bono 氏と Alec Xu 氏の2名で、いずれも Microsoft の所属です。文書には ©2024 Microsoft Corporation と記載されています。つまり「メーカーが自社製品の効果を自分で測って自分で発表した数字」であり、第三者機関による独立検証ではありません。査読付き学術誌への掲載についても、文書中に記載はありません。
ふたつめ。この記事を書いている株式会社TOEも、中小企業向けにAI導入の支援を行っている利害関係者です。「AIを入れましょう」と提案して対価を得る立場にあります。そして、TOEではこの実験を再現していません。以下の読み筋はすべてTOE未実施の前提で書いています。
自社製品の効果測定だからといって、内容がすべて信用できないという話ではありません。むしろこの文書は、後述するとおり自社製品にとって不都合な結果(多肢選択タスクで遅くなった件)も数字付きで書いています。読者に必要なのは、数字を捨てることではなく、誰がどんな条件で測ったのかを分かったうえで読むことです。
何をどう測ったのか
行われたのは意見調査でもベンチマークでもなく、ランダム化比較試験(RCT)です。参加者を treatment 群(Security Copilot が使える)と control 群(使えない)に半々でランダム割付し、同じ課題を解かせて比較しています。
調査の対象範囲
| 項目 | 内容 |
|---|---|
| 被験者(n数) | Upwork経由で募集した182名のうち181名が完遂 |
| 割付方法 | treatment群/control群に半々ランダム割付 |
| 課題 | 小規模組織を模したEntra/Intune環境で3シナリオ、想定所要は約2時間 |
| シナリオ | サインイン障害の切り分け/デバイスポリシー管理/デバイス障害の切り分け |
| 報酬 | 速度と精度の組み合わせに応じた成果報酬、最大130ドル |
| 対照群の環境 | Entra/Intune管理センター、Web検索、他AIツールの利用を制限せず許可 |
| 実施時期 | 文書の公開は2024年11月 |
| 発信元 | Microsoft Corporation。当該製品の提供者本人 |
ここで重要なのは、対照群にも他のAIツールの利用を許した点です。実際、対照群の25%が他のAIツール(多くはChatGPT)を使ったと回答しています(分母は対照群のみ、約90名)。著者はこれにより推計値がより保守的になると述べています。「AIあり vs AIなし」ではなく「専用AIあり vs 汎用AIも含む通常環境」の比較に近い、という理解が正確です。
そしてもうひとつ。環境は実企業の実データではなく、小規模組織を模してシミュレーションしたデータです。被験者も実際に組織で働く情シス担当者ではなく、Upworkで募集したフリーランスです(英語の読み書きができ評判が良いこと以外の要件は文書から読み取れません)。
全体の数字 ― 精度+34.53%、時間-29.79%
まず総括値です。
- 正答精度 +34.53%(p≦0.01)。11点満点で treatment 6.97 に対し control 5.18。分母は全被験者の全タスクで、実運用データではありません
- タスク完了時間 -29.79%(p≦0.01)。全体平均53.84分に対し、treatment 44.29分/control 63.10分
- 時間の数字は単純比較ではなく、対照群の「精度→所要時間」の回帰から同じ精度に到達するのに要する時間を推計し、ブートストラップ検定したものです
3番目の点は地味ですが大事です。速く終わらせるだけなら雑にやればいい。精度を一定に保った条件で時間を比べているので、「速いが雑」という抜け道は塞がれています。
ただし、この34.53%という総括値だけを持ち帰るのが、この文書の一番もったいない読み方です。中身に入ると、業務タイプによって結果が正反対に割れています。
業務タイプで結果が正反対に割れた
自由記述型 ― 桁違いに効く
複数のログや複数のポリシーを横断して要点をまとめる自由記述タスク(全3問)では、こうなりました。
- 関連事実の抽出数 +146.07%(3点満点で1.66 vs 0.67、p≦0.01)
- 所要時間 -61.14%(p≦0.01、17.03分 vs 43.82分)
事実を2.4倍拾って、時間は4割で済んでいます。ただし採点はLLMベースの採点者が「鍵となる事実」を含むかで判定したもので、文章の品質は精度点に含まれていません。人手による検証手順は文書中に記載がありません。ここは割り引いて読むべき箇所です。
多肢選択型 ― 精度は有意に上がらず、時間は増えた
一方、デバイスポリシー管理の多肢選択タスク(4問のみが分母、4点満点で2.01 vs 1.80)では、
- 精度 +11.99%。ただし統計的に有意ではない
- 所要時間 +25.13%(p≦0.01)で悪化
つまり、選択肢が最初から絞られている作業にAIを噛ませると、有意に遅くなったわけです。これは製品提供者にとって不都合な結果ですが、文書はきちんと書いています。
著者の説明はこうです。精度が有意にならなかった理由として、対照群の変動係数が56.1%と大きく検出力が不足していたこと、多肢選択の0/1採点方式であることを挙げています。実際、0点だった被験者を各群8名ずつ除くと +11.39%(0.05<p≦0.1)になります。時間増については、Copilotの応答レイテンシと、1問目でCopilotの使い方を学習していたためと説明しており、1問目を除くと +10.92% で有意差はなくなります。
説明としては筋が通っています。ただ、実務で使う側にとっては「レイテンシがあるから遅い」も立派な遅さです。原因が説明できることと、現場で遅くならないことは別の話です。
シナリオ別
| シナリオ | 精度改善 | 時間短縮 | 満点 |
|---|---|---|---|
| サインイン障害の切り分け | +46.88% | -45.41% | 3点満点 |
| デバイスポリシー管理 | +36.39% | -21.64% | 5点満点 |
| デバイス障害の切り分け | +24.99% | -15.69% | 3点満点 |
いずれも p≦0.01 です。ただしデバイス障害切り分けの +24.99% は「複数選択(SATA)タスク」のみで構成されている点に注意が必要です。
「経験が浅い人ほど効く」は言えるのか
よく語られる話ですが、この研究では言い切れていません。
サインイン障害切り分けシナリオでの精度改善は、ID管理経験0-3年が +57.1%(n=110)、3年以上が +43.0%(n=68)。点推定では確かに経験の浅い側が上ですが、90%信頼区間が大きく重なり、交互作用項を入れた回帰でも群間差は有意ではありません。デバイス管理経験別でも 0-3年 +33.5%(n=135)vs 3年以上 +16.2%(n=43、p=0.16で非有意)です。
さらに、時間短縮では逆転しています。デバイス管理経験別の時短は、経験3年以上が -30.2%、0-3年が -12.6%。ベテランのほうが時短幅が大きいという、よく語られる直感と逆の結果です。
加えてサンプルの経験年数分布は浅い側に偏っています。デバイス管理経験0-1年が181名中93名、ID管理経験0-1年が61名。ベテラン情シスの実態を代表するサンプルではありません。
体感は実測を大きく上回った ― 社内アンケートの落とし穴
この研究で、中小企業の実務に最も直結するのはここかもしれません。
- 実測の平均時短は 18.23分(p≦0.01)
- しかし treatment 群の 64.5%が「20分以上節約できた」と回答
- 41.9%が「30分以上」と回答
著者は「Copilotを使うのが楽しかったことによる過大評価と整合的」と説明しています。満足度アンケート(「次回も使いたい」96.77点など)も treatment 群のみへの設問であり、ツールを与えられた高揚感を含む可能性があります。
つまり、社内でAIの効果を体感アンケートだけで評価すると、過大評価になるということです。同じ構図は他の実験でも報告されており、AIコーディングツールで開発は本当に速くなるのか では実測と実感の符号そのものが逆を向いた例が出ています。効果を測るなら、少なくとも作業ログの時刻か、成果物の点検基準が要ります。自社で基準を作る手順は AI導入効果を自社の基準で測る にまとめています。
著者自身が認めている限界
この文書は、限界を自分で列挙しています。読者として押さえるべきものを整理します。
- 著者は「実運用の細部を完全に再現できる実験室は存在せず、観測された効果がどれだけ実運用に転移するかは未解明」と明記し、今後のフィールド実験を待つとしています
- 被験者は実務の情シス担当者ではなくUpworkのフリーランス。速度と精度の組み合わせに応じた成果報酬(最大130ドル)が設定されており、報酬設計が行動に影響した可能性を著者自身が議論しています
- 環境はシミュレーションデータであり、Entra/Intune という特定の管理コンソール上での結果です。他のIT運用ツールには一般化できません
- 課題は想定約2時間の一回限りの実験です。長期運用でのコスト、定着、誤答リスクは測定されていません
- 自由記述の採点はLLMベースの自動採点で、人手検証の手順は文書に記載がありません
「一回2時間の実験で速かった」と「毎日使い続けて回る」は別の話です。ここを混ぜないことが、導入判断の分かれ目になります。
TOEの読み筋(TOEでは未実施)
繰り返しますが、TOEはこの実験を再現していません。以下は文書の数字から読み取れる仮説であって、TOEが検証した結果ではありません。
1. 導入判断は「業務単位」で行う。この研究の一番の含意は34.53%という総括値ではなく、業務タイプによる差です。狙うべきは「情報をかき集めて統合する作業」──複数ログの横断確認、複数ポリシーの照合、障害の一次切り分けとその要約です。逆に、選択肢がすでに絞られていて答えを知っているか探すだけの作業に噛ませると、レイテンシの分だけ遅くなります。
2. 効果測定を体感に任せない。64.5%が「20分以上節約」と答えた裏で、実測は18.23分でした。導入前後で同じ作業の所要時間を数件でも記録しておけば、この乖離は避けられます。何をどう測るかは AIの効果測定 の考え方が転用できます。
3. 情シス1〜数名の会社ほど、狙いを絞る価値が大きい。この研究の被験者は経験の浅い層に偏っており、少人数で兼務している中小企業の情シス像に、たまたま近い部分があります。ただし前述のとおり経験年数による効果差は統計的に有意ではないため、「経験が浅いから効くはず」という期待で導入根拠にするのは無理があります。根拠にできるのは業務タイプの差のほうです。小さく始める手順は AI導入の最初の一歩 を参照してください。
4. 一次資料は自分で開く。この研究はMicrosoft自身によるものであり、数字は自社製品に有利な方向で設計されうる立場から出ています。それでも不都合な結果を書いている点は評価できます。逆に言えば、その不都合な部分こそが実務で最も役に立ちます。
まとめ
- Microsoft自身による181名のランダム化比較試験で、情シス業務の正答精度は平均34.53%改善、時間は29.79%短縮(いずれもp≦0.01)。ただし発信元は当該製品の提供者本人であり、査読の記載はない
- 効いたのは自由記述型の作業。事実抽出数 +146.07%、所要時間 -61.14%(いずれもp≦0.01)
- 多肢選択型では精度改善は統計的に有意でなく、所要時間はむしろ25.13%増加(p≦0.01)。著者はレイテンシと学習効果で説明するが、実務上は遅いことに変わりはない
- 「経験が浅い人ほど効く」は本研究では有意差なし。時短ではむしろ経験3年以上(-30.2%)が0-3年(-12.6%)を上回り、直感と逆の結果が出ている
- 実測の時短18.23分に対し、64.5%が「20分以上節約」と回答。体感アンケートだけの効果測定は過大評価になる
- 環境はシミュレーション、被験者はUpwork募集のフリーランス、成果報酬あり、一回2時間の実験。著者自身が実運用への転移は未解明と明記している。TOEでは未実施