Microsoft Copilot導入の進め方2026｜費用と権限設計の急所

日本本社から「Copilotを全社に入れる」と通達が届いた、あるいは現地から本社へ提案したい——タイの日系製造業からMicrosoft Copilot 導入のご相談をいただく機会が増えています。ただ、この検討でつまずく箇所はモデルの賢さではありません。Copilotは権限を破らない代わりに、その人が技術的にアクセスできる情報を自然言語の質問一発で表に出します。つまり長年放置してきた共有設定の粗さが、導入初日に可視化されます。本記事では費用の見方、権限の棚卸し、業務の切り分け、そして海外拠点固有の論点を整理します。

この記事で扱うこと、扱わないこと

生成AIの導入記事は「何ができるか」の機能紹介か、逆に「情報漏洩が怖い」という抽象的な警告に偏りがちです。しかし実際の導入プロジェクトで工数と費用を食うのは、機能でも恐怖でもなく、ライセンスを買う前にやっておくべき下ごしらえの部分です。ここを飛ばすと、費用を払ったうえで社内の情報流通に穴を開けることになりかねません。

本記事は次の範囲を扱います。

Copilot以外の選択肢も含めて全体像から見たい場合は、企業向け生成AI比較2026で主要ツールの比較軸を整理しています。本記事は、そのうち「Microsoft 365環境にCopilotを入れる」という選択肢を深く掘る位置づけです。

なお、本記事に出てくる価格は執筆時点でMicrosoftの公式価格ページに掲載されている値と、報道等の二次情報を明確に分けて記載しています。ライセンス価格は改定が入る領域ですので、実際の見積もりの際は必ず最新の公式情報とマイクロソフトのパートナー各社にご確認ください。

Microsoft Copilot導入の前に整理すべき「Copilotとは何か」

「モデル」ではなく「自社データに接続された窓口」

社内でCopilotの説明をするとき、最初に合わせておきたい認識があります。Copilotは、インターネット上の知識を答えるチャットボットではなく、自社のMicrosoft 365テナントの中にあるデータに接続された窓口である、という点です。

この違いは、導入の前提条件を根本から変えます。汎用のチャットボットであれば、社内データとの関係を気にせずに配ることができます。しかしCopilotは、メール、Teamsのチャット、SharePointのファイル、OneDriveの個人領域、カレンダーといった自社の情報資産を参照して回答を作ります。したがって、回答の品質は「その人がアクセスできる情報の質と範囲」に強く依存することになります。

ここで重要なのが、Copilotが権限を破らないという性質です。ある社員が権限を持っていないファイルは、Copilotに聞いても出てきません。この点はしばしば「だから安全です」という説明に使われます。しかし、実務的な含意は逆向きです。

従来、共有設定が甘いファイルが実害を生まなかったのは、誰もそれを探し当てなかったからです。SharePointの検索窓に正確なキーワードを入れ、大量の結果から目的のものを見つけ出す作業は、それなりの手間がかかりました。Copilotは「今期の役員報酬の見直しについて書かれた資料をまとめて」といった自然言語の問いに対し、アクセス可能な範囲を横断して探し、要約して提示します。探索のコストがほぼゼロになることが、既存の設定の粗さを一気に表面化させます。

この構造を理解しておくと、導入プロジェクトで何に時間を使うべきかが変わります。プロンプトの書き方の研修に時間をかけるより先に、誰が何にアクセスできる状態になっているかを把握するほうが優先度が高い、という判断ができるようになります。

名前が混ざったまま社内会議が進む問題

もう一つ、導入検討の初期でよく起きるのが呼称の混乱です。「Copilot」という名前を冠した製品は複数あり、それぞれ対象も費用も権限モデルも違います。同じ会議に出ている人が、違うものを想定して話していることが珍しくありません。

社内の稟議書で「Copilot導入」とだけ書かれていると、経理は費用を、情シスは権限を、現場は業務支援を思い浮かべます。検討の最初に、対象がどれなのかを一行で確定させるだけで、その後の議論の速度が変わります。本記事で「Copilot」と書く場合は、原則として Microsoft 365 Copilot を指します。

何が新しく、何が新しくないのか

Copilotについて社内で期待値を合わせるとき、次の整理が役に立ちます。

最終行に注目してください。Copilotは権限モデルを変更しません。新しい権限を作ることも、既存の権限を緩めることもありません。変わるのは、権限の範囲内にある情報への到達しやすさだけです。この一点を社内で共有できていれば、「Copilotが勝手に情報を漏らした」という誤った説明を避けられます。実際に起きるのは、もともと見えていたものが、見えると気づかれるという現象です。

Microsoft 365 Copilotの費用と料金プラン2026

アドオン方式であることの意味

費用の見積もりで最初に押さえるべきは、Microsoft 365 Copilotがアドオン方式である点です。単体では契約できず、対象となるベースライセンスの上に追加する形になります。中堅・中小企業向けのCopilot Businessの場合、Microsoft 365 Business Standard以上のベースライセンスが必要とされています。

これが意味するのは、現在のライセンス構成によっては、アドオン費用に加えてベースライセンスの底上げ費用が発生するということです。たとえばBusiness Basicで運用している部門にCopilotを入れる場合、Standard以上への切り替えがまず必要になります。この「底上げ」分は、Copilotのアドオン価格だけを見ている段階では見落とされがちです。

Microsoftの公式価格ページに掲載されている値を整理します。

統合プランの価格に注目すると、ベースライセンスとアドオンを別々に積み上げた場合との差が見えます。既存のライセンス構成、契約更新のタイミング、シート数によって、どの組み合わせが有利かは変わります。この判断は各社の契約状況に依存するため、一般論として「こちらが得」とは申し上げられません。ただし、現在のベースライセンスの内訳（Basic / Standard / Premiumが何名ずつか）を先に洗い出しておくと、比較のスタートラインに立てます。

なお、大企業向けの価格については月4,497円／人という値が報じられています。こちらは公式価格ページの掲載値ではなく報道による二次情報ですので、社内の資料に載せる場合は出典の性質を明記したうえで、正式な見積もりで確認する前提としてください。

2026年に入ってからの変更点

2026年に入ってから、Copilotとその周辺のライセンス体系にはいくつかの動きがありました。いずれも導入計画の前提に影響するため、把握しておく価値があります。以下は主に二次情報に基づく整理ですので、正確な適用条件はマイクロソフトまたは契約中のパートナーにご確認ください。

2,000シート以上の組織に関する変更は、大規模テナントを持つ企業では「一部の部門だけCopilotを入れる」という進め方の前提が変わる可能性があるという点で重要です。これまで無償で使えていた範囲の機能が、アドオン未割当のシートでは利用できなくなったとされているためです。日本本社とタイをはじめとする海外拠点が同一テナントを共有している大手グループの場合、シート数の合計がこの閾値を超えているかどうかを確認しておくとよいでしょう。

また、7月1日のベースライセンス価格改定は、Copilotの検討とは別に発生するコスト増です。「Copilot導入でこれだけ上がる」という説明をするときに、この改定分と混ぜてしまうと、社内での議論が「Copilotが高い」という方向にずれます。Copilot起因の増分と、それとは無関係に発生する増分を分けて示すことをおすすめします。

費用は5層に分けて見積もる

ライセンス費用だけを見た予算計画では、後の段階で不足が生じやすくなります。Copilot導入で実際に発生する費用は、次の5層に分かれます。

このうち第3層（権限棚卸し・データ整備）が、Copilot導入プロジェクトの本体です。ここが本記事の中心的な主張です。ライセンスは発注すれば翌日から使えますが、権限の棚卸しは社内の実態調査であり、外部に丸投げできる作業ではありません。そして、この層を飛ばして展開した場合のリスクは、費用の問題ではなく情報管理の問題として現れます。

第5層の「運用」も見落とされがちです。Copilotのライセンスは、配った人が使わなければそのまま費用として流れ続けます。四半期ごとに利用状況を見て、使っていない人から使う人へ再配分するという運用を最初から設計に入れておくと、無駄が積み上がりません。この運用を誰が担うかを決めずに導入すると、1年後に「誰も見ていない」という状態になります。

予算化の前に測っておきたいこと

見積もりを取る前に、社内で確認しておくと精度が上がる項目があります。手作業の集計で構いませんので、次の数字を押さえておいてください。

特に2行目と3行目は、次の章で扱う権限の棚卸しの規模を左右します。この数字を持たずにベンダーへ相談すると、見積もりが「調査してみないと分かりません」で止まるか、逆に実態と合わない前提で出てきます。

導入前にやる権限の棚卸し（オーバーシェアリング対策）

破らないからこそ、粗さがそのまま出る

繰り返しになりますが、この章が本記事の核心です。Copilotは権限を破りません。ユーザーがアクセス権を持たない情報を勝手に読み出すことはしません。にもかかわらず問題が起きるのは、多くの組織で「技術的にアクセスできる範囲」が「業務上アクセスすべき範囲」より広くなっているからです。

この状態を一般にオーバーシェアリング（過剰共有）と呼びます。企業テナントあたり平均150〜300の過剰共有SharePointサイトが存在するという調査もあります。この数字をそのまま自社に当てはめることはできませんが、「うちは大丈夫」と根拠なく判断しないほうがよいという材料にはなります。

オーバーシェアリングが生まれる経緯は、悪意によるものではありません。多くの場合、次のような日常的な運用の積み重ねです。

4行目の「ラベルがコンテナのみ」は、特に誤解が多い点です。コンテナ（サイトやチーム）に付けた情報保護ラベルは、その中のアイテム（個々のファイル）には自動で継承されません。「Confidentialのサイトに置いてあるから保護されている」という理解は、ラベルベースの制御を前提にしたときに成立しません。Copilotは、ラベルの付いていないアイテムを通常の参照対象として扱います。サイト単位のラベル運用しかしていない組織は、この点を必ず確認してください。

何が起きるかを具体的に想像する

抽象的に「情報漏洩のリスクがある」と説明しても、社内の危機感は動きません。次のような具体例で示したほうが伝わります。いずれも、権限を破らずに起こりうることです。

これらは、Copilotが何かを壊したのではなく、もともと権限上は到達できた情報への到達が、容易になっただけです。だからこそ、対策は「Copilotを制限する」ではなく「共有設定を正す」という方向になります。

対策の順序：可視化 → 露出の遮断 → ラベル付け → 展開

権限の棚卸しは、順序を守ることで作業量が大きく変わります。逆に、順序を間違えると終わりません。推奨される流れは次のとおりです。

なお、この章では作業の順番を「工程」と呼びます。後段のロードマップで扱う「段階」とは別の粒度ですので、混同しないようご注意ください。

ここで実務上重要なのは、第2工程と第3工程の性質が違うことです。第2工程の「露出の遮断」は、Copilotの参照対象から外すという、比較的短期間で打てる手です。一方、第3工程の「ラベル付け」は情報分類のルールづくりから始まる恒久的な整備であり、数か月から年単位の取り組みになります。

多くの組織が失敗するのは、第3工程の完了を第4工程の前提にしてしまうためです。ラベル付けが終わるまで展開しない、と決めると、プロジェクトは事実上止まります。現実的には、第2工程まで完了した時点でパイロットを開始し、第3工程と第4工程を並行して進める設計が取りやすい形です。ただしこれは、第2工程を確実に完了させることが前提です。ここを飛ばしてはいけません。

Microsoft側の道具の位置づけ

権限の棚卸しには、Microsoftが提供している管理機能が使えます。何ができるかを整理しておくと、外部委託する範囲の判断がしやすくなります。

Restricted Content Discovery は、「共有設定を直しきる前に、まずCopilotの目から外す」ための機能として理解すると位置づけが明確になります。共有設定そのものを一つずつ正すのは時間がかかります。一方、過剰共有が疑われるサイトをまとめてCopilotの参照対象から外すことは、比較的短期間で実行できます。これによって、本質的な整備を進めながら、その間の展開を安全に行うという進め方が可能になります。

ただし、RCDで外したサイトは、Copilotから見えないだけで、権限を持つ人が直接アクセスすれば従来どおり見られます。根本的な解決ではなく、時間を稼ぐための措置であるという理解が必要です。外したまま放置すると、いずれ「なぜこの資料はCopilotで出てこないのか」という業務上の不便として跳ね返ります。

誰がこの作業をやるのか

権限の棚卸しで最も現実的な障害は、技術ではなく担い手です。情報システム部門だけでは完結しません。

この表が示すのは、検出は自動化できるが、判断は業務部門にしかできないという構造です。したがって、導入プロジェクトのスケジュールを引く際は、業務部門が判断に使う時間を必ず見込んでください。「情シスに任せた」で進めると、判断待ちの列ができて止まります。

現実的な進め方としては、検出結果を件数の多い順・リスクの高い順に並べ、上位から部門に確認していく形です。全件を一度に片付けようとせず、まずCopilotを配る予定の部門の範囲だけを優先して片付けるという区切り方も有効です。これはパイロットを小さく始める理由の一つでもあります。

Copilotで成果が出る業務・出ない業務の切り分け

成果が出やすいのは「情報が既にMicrosoft 365の中にある」業務

Copilotが参照できるのは、原則としてMicrosoft 365テナントの中にあるデータです。この一点から、成果が出やすい業務は自ずと絞られます。

この表の「前提となる条件」の列を見ていただくと、共通点が見えてきます。資料が個人のPCのローカルフォルダや、Microsoft 365の外にあるファイルサーバーに置かれている限り、Copilotの対象外です。タイの工場でよくあるのは、Windowsのファイルサーバー（NAS）に部門ごとの共有フォルダを切って運用している構成です。この場合、Copilotを導入しても、日常業務で最も参照されているデータには届きません。

したがって、導入の効果を見積もる前に、現在の業務データがどこにあるかを確認する必要があります。SharePoint/OneDriveへの移行が済んでいない状態でCopilotのライセンスを配ると、「思ったほど役に立たない」という評価になり、次の投資が止まります。

成果が出にくい業務を先に言っておく

期待値を合わせるうえで、効きにくい領域を先に伝えておくことが重要です。ここを曖昧にしたまま展開すると、現場の失望が「生成AIは使えない」という全否定に変わってしまいます。

上の3行目「現場の暗黙知」は、製造業でCopilotへの期待が最も大きく、かつ最も外れやすい領域です。ベテランの判断基準は、そもそもファイルとして存在しないため、どんなに優れたAIでも参照できません。この領域に取り組む場合は、技能伝承をAIで支える取り組みで整理しているように、まず知識を引き出して形にする工程が必要になります。

同様に、社内固有の手順書・図面・品質記録に答えさせたい場合は、Copilotとは別の仕組みが必要です。この場合の選択肢は自社RAGの構築になりますが、その設計の考え方は工場のナレッジをRAGで扱う際の実装論点にまとめています。「Copilotを入れたのに現場のことは何も分からない」という不満は、この境界線を最初に説明しておけば防げます。

「4人に1人しか時間削減できていない」という指摘への向き合い方

生成AIツールの導入効果について、実際に業務時間を削減できたユーザーは4人に1人に留まるという指摘があります。この数字は導入を検討する側にとって気持ちのよいものではありませんが、否定するより構造として理解するほうが実務的です。

考えられる理由を整理すると、次のようになります。

最後の行は見落とされやすい点です。削減された時間が他の業務に振り替わった場合、本人の実感としては「忙しさは変わらない」となります。効果測定の設計を導入前に行っておかないと、この種の効果は記録に残りません。何をどう測るかはAI導入の効果測定フレームワークで個別に扱っています。

なお、日本企業全体の状況としては、PwC Japanの「生成AIに関する実態調査2026 春」で、活用・推進度が87%、未着手・断念が4%とされています。一方、帝国データバンクの2026年3月調査では、業務で「活用している」企業は34.5%です。この二つの数字の差は、調査対象と設問の違いによるものと考えられますが、「取り組んでいる」と「業務で使っている」の間に大きな幅があることは読み取れます。導入を検討する立場としては、後者の数字のほうが実態に近い感覚を与えてくれるはずです。

同じ帝国データバンクの調査で、この「活用している」割合を企業規模別に見ると、大企業46.5%、中小企業32.4%、小規模企業28.0%となっています。他方、活用している企業のうち「業務への効果が出ている」と回答した割合は86.7%とされています。つまり、使い始めた企業では効果が出ている割合が高い一方、そもそも使い始めるかどうかの段階で規模による差が大きいという構図です。なお、46.5%／32.4%／28.0%はあくまで規模別の活用率であり、効果が出ている割合を規模別に分けた数字ではありません。

同調査で懸念として最も多かったのは「情報の正確性」で50.4%でした。また、使いこなせていない層としては課長・リーダー職が最多とされています。この二点は、導入設計にそのまま示唆を与えます。正確性への懸念には検証を前提とした使い方のルール化で応え、中間管理職への浸透にはその層の日常業務に即した使用例を用意する、という対応です。若手向けの一般的な研修をそのまま流用しても、この層には届きにくいと考えられます。教育設計の考え方は製造業向けの生成AI研修の組み立て方にまとめています。

業務の棚卸しシート

導入前に、対象部門で次の形の棚卸しをしておくと、パイロットの設計が具体的になります。

この形で3〜5件挙げてもらうと、その部門にCopilotを配るべきかどうかの判断材料になります。「Microsoft 365の中で完結するか」の列がすべて「完結しない」であれば、その部門は優先順位を下げるべきです。ライセンスを配らない判断も、立派な導入設計の一部です。

ChatGPT企業導入との比較と使い分け（生成AIツールの選び方）

3つの類型で考える

「CopilotとChatGPTのどちらを選ぶべきか」という問いは、社内でほぼ必ず出ます。しかし、この問いの立て方自体が実態と合わなくなりつつあります。Forresterの2026年2月の調査では、企業のAI導入の34%が複数プラットフォームを併用しているとされています（二次情報）。どちらか一方を選ぶのではなく、用途で使い分けるのが現実的な姿になってきています。

使い分けの軸として、次の3類型で整理すると判断しやすくなります。

この3類型は排他ではありません。実際には、①を全社の基盤として置きつつ、②を企画・調達・品質保証など特定の職種に限定して配り、③を製造現場の課題に対して個別に構築する、という組み合わせが取られることがあります。③に踏み込む場合は、対象データの選び方と精度の維持が設計の中心になります。この点は工場ナレッジのRAG構築で扱っています。

比較の観点

3つの選択肢を、導入判断に関わる観点で並べると次のようになります。価格については、Copilotは公式価格ページの値、ChatGPT Enterpriseは報道値である点にご注意ください。

ChatGPT Enterpriseの最低シート数に関する報道値は、海外拠点単体での契約を検討する場合に効いてくる論点です。タイ拠点の従業員が150名を下回る場合、拠点単独での契約は成立しない可能性があります。この点は、後述する契約主体の議論に直結します。

選定を誤りやすいパターン

比較検討の場で起きがちな判断のずれを挙げておきます。

とくに最後のパターンは、海外拠点でよく起きます。本社が日本の業務実態を前提に選定した結果、現地の主要データがファイルサーバーにある状況が考慮されないまま展開される、という形です。現地から本社へ「うちのデータはここにある」という事実を早い段階で伝えることが、無駄なライセンス費用を防ぎます。

各選択肢の詳細な比較軸は企業向け生成AI比較2026で扱っていますので、Copilot以外も含めて広く検討する段階の方はそちらも併せてご覧ください。

海外拠点（タイ工場）にCopilotを入れるときの論点

契約主体をどこに置くか

タイ拠点でのCopilot導入で、技術より先に決着させる必要があるのが契約主体です。日本本社が一括で契約するのか、現地法人が独自に契約するのかで、その後の運用が大きく変わります。

多くの日系企業では、テナント自体は本社と共有しつつ、ライセンス費用を拠点に付け替える形が取られます。この場合に確認しておきたいのが、付け替えの単価と、使わなかった場合の扱いです。本社から一律に「現地20名分」と配分され、その費用が現地に付け替えられた結果、現地では使われないまま費用だけが計上される、という状況は避けたいところです。

現地から本社へ提案する立場の場合は、「何名分を、どの部門に、どういう目的で配るか」を具体的に示したうえで、パイロットの結果に応じて増減させる前提を明記しておくと、話が進めやすくなります。

多言語での実務品質をどう見積もるか

タイの日系工場では、日本語・英語・タイ語の3言語が同時に動いています。日本人駐在員は日本語、管理職層は英語、現場のオペレーターやスタッフはタイ語、という構成が一般的です。ここで問題になるのが、生成AIの実務品質が言語によって揃わないという点です。

これは特定の製品の欠点ではなく、学習データの量や、業務文書の蓄積の差から生じる構造的なものです。導入時に期待値を合わせておかないと、「日本人には便利だがタイ人スタッフには使えない」という不公平感が生まれます。

現実的な設計としては、言語ごとに用途を分けるという考え方が有効です。たとえば、日本語・英語での文書作成と要約は積極的に使い、タイ語については「日本語／英語との翻訳・要約の補助」という位置づけから始める、という形です。いきなりタイ語での完全な業務代替を期待すると、評価が下がります。

もう一つの論点は、参照される社内文書の言語です。Copilotはテナント内の文書を参照して回答します。社内文書が日本語中心であれば、タイ語で質問しても参照元が日本語であるため、翻訳を挟んだ回答になります。この構造は、多言語で業務している拠点では避けられません。むしろ、日本語資料をタイ人スタッフが読み下ろす用途としては、この構造が有利に働く場面もあります。従来、日本語の技術資料が現地に届かず眠っていた状況を考えれば、ここに一定の価値を見出す設計もあり得ます。

現地の共有ドライブは「とりあえず全員」で作られている

これはタイに限った話ではありませんが、海外拠点では特に顕著な傾向として、共有フォルダやSharePointサイトが「とりあえず全員アクセス可」で作られていることが多くあります。

理由は理解できるものです。拠点の立ち上げ期には人数が少なく、細かい権限設計をする余裕も必要性もありません。全員が見える状態にしておくほうが業務が回ります。しかし、拠点が成長して人数が増え、離職・入社が繰り返されるうちに、当初の前提が崩れます。

最終行は、タイ拠点で特に注意が必要な領域です。従業員の待遇に関する情報が、権限設定の甘い場所に置かれている状態でCopilotを展開すると、「誰の給与がいくらか」を自然言語で質問できる状態が生まれかねません。これは労務管理上、極めて大きな問題になります。導入前の棚卸しでは、人事・給与に関わる情報の格納場所とアクセス権を最優先で確認してください。

現地の権限棚卸しを進める際の実務的な難しさは、当時の経緯を知る人がもう社内にいないことです。作成者が退職しており、なぜこの権限になっているのかを説明できる人がいない、という状況が普通に起こります。この場合、「元に戻してよいか」の判断ができないため、作業が止まります。現実的な対処としては、リスクの高いものから順に、いったん制限したうえで業務に支障が出たら個別に開けるという進め方が取られます。全件の経緯を解明しようとすると終わりません。

タイ側のAI投資環境という追い風

社内で予算を通す文脈として、タイのデジタル・AI投資の状況を把握しておくと役に立つ場面があります。

Bangkok Postが報じたThailand Digital Outlook 2026では、タイ企業のデジタル成熟度が4点満点中2.12となり、前年の1.56から上昇して初めて「中程度」の水準に入ったとされています。また、タイのSMEの7割超がAIを実装中とされ、MicrosoftのGlobal AI Diffusion Reportではタイが韓国に次いでAI導入成長率で世界2位とされているという報道もあります（二次情報）。

投資環境としては、BOI（タイ投資委員会）の2026年上半期の投資申請は、前年比37%増の1.47兆バーツ（1,299件）に達したと報じられています。うち「Smart and Sustainable Industry」枠では132件・約172億バーツが申請されているとされます。

これらの数字は、「現地は遅れているからまだ早い」という本社側の想定に対する反証材料として使えます。ただし、Copilotのようなソフトウェアライセンスの費用がBOIの恩典の対象になるかどうかは、業種・投資内容・申請区分などの条件によって変わります。本記事の記述をもって自社が対象になると判断することはできません。検討される場合は、所轄の窓口またはBOIに直接ご確認ください。

タイでのAI導入全般の進め方についてはタイ拠点でのAI導入の現実的な進め方で、現地特有の制約と体制づくりを扱っています。

本社と現地で言葉が噛み合わないとき

最後に、海外拠点でのAI導入で最も多い実務的な困りごとに触れておきます。それは技術でも費用でもなく、本社と現地の間で前提が共有されていないことです。

この表の右列に共通するのは、現地から事実を数字で返すという対応です。「うちには合いません」という主観的な反応ではなく、対象者数、データの所在、言語比率、必要工数といった形で示すと、本社側も計画を修正しやすくなります。逆に、事実を返さないまま一律配布が決まると、その後の運用負荷はすべて現地にかかります。

導入ステップと社内の進め方（ロードマップ）

全体の流れ

ここまでの内容を、実行の順序に並べ直します。期間は組織の規模や現在の整備状況によって大きく変わるため、順序の参考としてご覧ください。

この6段階のうち、第0段階と第1段階を飛ばして第2段階から始めてしまうのが最も多い失敗です。ライセンスは今日申し込めば明日から使えるため、心理的に先へ進めたくなります。しかし、目的が言語化されていないパイロットは評価ができず、権限が整理されていない展開は事故の温床になります。

第0段階：目的の言語化

「生成AIを活用する」は目的ではありません。この段階で書き出すべきは、特定の業務と、その業務で今かかっている時間です。前章で示した業務の棚卸しシートを使い、部門ごとに3〜5件挙げてもらいます。

このとき注意したいのは、挙がってきた業務が本当にMicrosoft 365の中で完結するかを確認することです。「不良分析を効率化したい」という要望が挙がっても、不良データが製造実行システムの中にあるのであれば、Copilotでは扱えません。この段階でふるいにかけておくと、後の失望を防げます。

第1段階：権限の可視化と露出の遮断

前章で扱った内容です。実務上のポイントを繰り返すと、次の3点になります。

第一に、全社の権限を完全に整理してから始めようとしないことです。パイロットの対象部門がアクセスできる範囲に絞って優先的に片付けるほうが、現実的に前へ進みます。

第二に、判断は業務部門に返すことです。検出は自動化できても、「この共有を止めてよいか」は使っている人にしか判断できません。判断待ちの時間をスケジュールに織り込んでください。

第三に、人事・給与・待遇に関わる情報を最優先で確認することです。ここだけは、パイロットの範囲がどこであれ、先に確認しておく価値があります。なお、恒久的な整備であるラベル付けは、この段階で完了させる必要はありません。パイロットと並行して進める前提で計画してください。

第2段階：パイロットを20〜50名で

パイロットの規模として20〜50名程度を目安とする理由は、評価に足る量のデータが取れ、かつ問題が起きたときに手を戻せる規模だからです。5名では偶然の影響が大きすぎ、数百名規模では問題が起きたときの収拾がつきません。

対象者の選び方には設計が必要です。

実務的には、一つか二つの部門にまとめて配りつつ、その中に管理職層と多言語の利用者を含めるという組み合わせが、得られる情報のバランスがよいと考えられます。帝国データバンクの調査で使いこなせない層として課長・リーダー職が最多とされていることを踏まえると、この層をパイロットに含めて実態を確認しておくことには意味があります。

パイロット期間中に集めるべきものは、使用ログだけではありません。「どんな質問をしたか」「期待どおりの答えが返ったか」「返らなかった場合は何が足りなかったか」を記録してもらうと、展開時の教育材料になります。

第3段階：効果測定の設計

効果測定は、パイロット開始後に考え始めると手遅れになります。導入前の状態を測っておかないと、比較する相手がいないためです。第0段階の業務棚卸しで「効果の測り方」を記入しているのは、このためです。

最終行の考え方は、社内説明で重要です。削減された時間が他業務に振り替わる場合、人件費は減りません。この場合は「同じ人数で処理できる量がどれだけ増えたか」という形に組み替えたほうが、説明として正確です。

第4段階：展開と教育

展開の段階で費用を見落としやすいのが教育です。特に海外拠点では、現地語での教育資料と、現地語で質問に答えられる窓口が必要になります。日本語の資料を配って終わりにすると、定着しません。

教育の内容としては、操作方法よりも業務に即した使用例のほうが効果があります。「この会議の議事録を作るときは、こう頼む」という具体例が3つあるだけで、使い始めるハードルが下がります。パイロット期間中に集めた記録が、そのまま教材になります。

もう一点、検証を前提とした使い方を教育に含めてください。帝国データバンクの調査で懸念の最多が「情報の正確性」（50.4%）であったことを踏まえると、「出力をそのまま使わない」「数字は必ず元資料で確認する」といったルールを明示しておくことが、信頼の維持につながります。

第5段階：再配分をやめない

Copilotのライセンスは、配ったまま放置すると使われないまま費用が流れ続けます。四半期ごとに利用状況を確認し、使っていない人から使う人へ移す運用を、導入時から設計に入れておいてください。

この運用を成立させるには、次の準備が要ります。

この仕組みがあることを事前に周知しておくと、回収時のあつれきが減ります。「使わなければ他の人に回る」というルールが共有されていれば、それ自体が利用を促す効果も持ちます。

「全社一斉配布」をやらない理由

日本本社から「全社に入れる」という指示が来た場合、そのまま実行するのではなく、段階を刻む提案をする価値があります。理由は3つです。

第一に、ライセンスが遊ぶためです。Microsoft 365を日常的に開かない現場スタッフに配っても、費用だけが発生します。対象者の実数を出して、配る範囲を絞る提案をしてください。

第二に、権限整備が追いつかないためです。全社に一斉展開するということは、全社の共有設定が整理済みであることを意味します。この前提が満たされていないまま展開すると、情報管理上の問題が広範囲に一度に発生します。

第三に、問題が起きたときに戻せないためです。段階を刻んでいれば、想定外の事態が起きた時点で次の展開を止められます。一斉配布では、その判断の余地がありません。

これらを本社に伝える際は、反対ではなく順序の提案として示すのが有効です。「全社展開を前提として、まず20〜50名で3か月のパイロットを行い、権限整備と効果測定を並行して進める」という形であれば、本社の意向と現地の実務が両立します。

よくある質問（FAQ）

Microsoft Copilotの導入費用はいくらですか？

Microsoftの公式価格ページに掲載されている値では、Microsoft 365 Copilot Business のアドオンが1ユーザーあたり月額¥3,148（年払い相当）、月払いの場合は¥3,778です。2026年7月1日から9月30日までは、初年度のみのプロモーション価格として¥2,698（年払い相当）が案内されています。統合プランでは、Microsoft 365 Business Standard + Copilot Business が¥3,523、Business Premium + Copilot Business が¥4,797（いずれも年払い相当・1ユーザーあたり月額）です。大企業向けについては月4,497円／人という値が報じられていますが、これは二次情報ですので正式な見積もりでご確認ください。

ただし、これはアドオンライセンスの費用にすぎません。実際の総額は、①アドオンライセンス、②ベースライセンスの底上げ（Business Standard以上が必要なため、Basic利用者は切り替えが要ります）、③権限棚卸し・データ整備、④展開・教育、⑤運用（利用状況の監視と再配分）の5層で見積もる必要があります。このうち③が最も工数を要し、かつ社外に丸投げできない部分です。ライセンス費用だけで予算を組むと、後の段階で不足が生じやすくなります。

Copilotを入れると情報漏洩しますか？

Copilotは権限を破りません。ユーザーがアクセス権を持たない情報を勝手に読み出すことはありません。したがって、権限設定が意図どおりに保たれている状態であれば、Copilotが新しい情報の経路を作るという設計にはなっていません。既存の経路が見えるようになるのであって、経路そのものが増えるわけではない、という理解が出発点になります。

問題は、多くの組織で「技術的にアクセスできる範囲」が「業務上アクセスすべき範囲」より広くなっている点です。従来はそれが実害にならなかったのは、誰も探し当てなかったからです。Copilotは自然言語の質問一つで権限内を横断して探し、要約します。探索のコストがほぼゼロになることで、既存の共有設定の粗さがそのまま表面化します。

具体的には、継承が切れたフォルダ、「組織全体」で共有されたリンク、退職者が作って誰も管理していない共有サイト、といったものが典型です。また、情報保護ラベルをサイト（コンテナ）にだけ付けている場合、そのラベルは中のアイテムには継承されないため、個々のファイルは未ラベルとして参照対象になります。導入前に、可視化→露出の遮断→ラベル付け→展開という順序で棚卸しを行ってください。SharePoint Advanced Management の権限レポートで現状を検出し、Restricted Content Discovery で過剰共有サイトをCopilotの参照対象から外す、という手順が実務的です。

ChatGPTとMicrosoft Copilotはどちらを選ぶべきですか？

どちらか一方を選ぶという問いの立て方自体を見直すことをおすすめします。本文で触れたとおり、複数のプラットフォームを併用する企業が既に相応の割合を占めているという調査もあり、択一で考える前提が実態と合わなくなってきています。

判断の軸としては、扱いたい情報がどこにあるかで3類型に分けると整理しやすくなります。会議・メール・社内資料の探索や要約といったMicrosoft 365の中で完結する業務であればCopilot、Microsoft外のデータや自由度の高い調査・企画であればChatGPT Enterprise等、自社固有の手順書・図面・品質記録に答えさせたいのであれば自社RAG、という切り分けです。

なお、ChatGPT Enterprise については $45〜75／ユーザー／月・年間契約で最低150シートという報道値があります。この最低シート数は、海外拠点単体で契約を検討する場合に制約になり得ます。従業員数が少ない拠点では、拠点単独での契約が成立しない可能性がありますので、契約主体の設計と合わせて確認してください。

タイ語や英語でも日本語と同じ品質で使えますか？

同じ水準を前提にしないほうが安全です。生成AIの実務品質は言語によって差があり、これは特定の製品の欠点ではなく、学習データや業務文書の蓄積の差から生じる構造的なものです。

対処としては、本文で述べたとおり言語ごとに用途を分ける設計をおすすめします。タイ語については、最初から独立した業務代替を任せるのではなく、翻訳と要点整理の補助という限定された役割から入るほうが、実際の使われ方につながります。期待値を高く置いたまま配ると、現地スタッフの評価が下がり、その後の展開が難しくなります。

もう一点、参照される社内文書の言語も効きます。社内資料の多くが日本語で書かれている拠点では、タイ語で質問しても材料が日本語であるため、翻訳を経た回答になります。ただしこれは、従来は現地に届いていなかった日本語の技術資料をタイ人スタッフが自分で読み解けるようになる、という形で有利に働く場面もあります。期待値を下げるだけでなく、この方向の使い方を設計に入れておくと、多言語環境ならではの価値が出せます。

何人から始めるのが現実的ですか？

20〜50名程度を目安とすることをおすすめします。この規模であれば、評価に足る量のデータが取れ、かつ問題が起きたときに手を戻せます。5名程度では個人差の影響が大きすぎて評価になりませんし、数百名規模で始めると想定外の事態が起きたときの収拾がつきません。

配る相手は無作為に選ばず、部門をまとめて押さえたうえで、管理職層と日本語以外で業務している人を意図的に混ぜてください。帝国データバンクの2026年3月調査で、使いこなせていない層として課長・リーダー職が最多とされている点は、対象者を決める際の実務的な手がかりになります。

集めるものについては、本文で述べたとおり、利用ログよりも実際のやり取りの記録のほうが価値があります。展開段階の教材は、この記録から作るのが最も早い方法です。

現場（製造ライン）の業務にも効きますか？

期待は抑えたほうがよい領域です。生産管理システムの中の実績データ、設備の稼働データ、手書きの帳票、現場での口頭のやり取り——これらはいずれもMicrosoft 365テナントの外にあるか、そもそも記録されていません。参照できる材料がなければ、回答は作れません。

また、ベテランの判断基準のような暗黙知は、文書として存在しないため、どんなに優れたAIでも参照できません。この領域に取り組む場合は、まず知識を引き出して形にする工程が必要になります。

現場に効かせたい場合の現実的な選択肢は、Copilotではなく、自社固有のデータを対象にしたRAGの構築や、製造実行系・IoT側の仕組みです。逆に言えば、Copilotが向いているのは事務部門・技術部門・管理部門の文書業務です。導入の説明会でこの守備範囲を先に伝えておくかどうかで、現場側の受け止め方が大きく変わります。

2,000シート以上の組織で何が変わったのですか？

2026年4月15日より、Microsoft 365ライセンスが2,000シート以上の組織では、Copilotアドオンが割り当てられていないシートにおいて Word / Excel / PowerPoint / OneNote のCopilot機能が使えなくなったとされています。この内容は二次情報に基づくものですので、自社への適用条件は必ず一次情報でご確認ください。

実務上の含意としては、部分導入を前提にした計画の見直しが必要になる場合があります。日系企業の場合、本社と海外拠点でテナントを共有していることが多く、拠点単体では小規模でもグループ合計では閾値を超えていることがあります。自社がこの区分に入るかどうかは、契約の窓口となっている部署に早い段階で確認しておいてください。

権限の棚卸しは全社分を終わらせてから展開すべきですか？

全社分の完全な整理を展開の前提にすると、プロジェクトは事実上止まります。現実的には、可視化と露出の遮断（過剰共有サイトをCopilotの参照対象から外す）までを完了させた時点でパイロットを開始し、ラベル付けのような恒久的な整備は並行して進める設計が取りやすい形です。

ただし、露出の遮断を飛ばしてはいけません。これは短期間で打てる手であり、かつ最も効果の大きい対策です。また、人事・給与・待遇に関わる情報の格納場所とアクセス権については、パイロットの範囲がどこであれ、先に確認しておく価値があります。海外拠点では、これらの情報が共有領域に置かれていることが珍しくありません。

本社が「全社一斉配布」と決めた場合、どう対応すべきですか？

反対ではなく、順序の提案として返すことをおすすめします。全社展開そのものを前提として受け入れたうえで、その手前に小規模のパイロットと権限整備を置く、という組み立てにすれば、本社の意向を否定せずに現地の実務を守れます。

その際に添えるべきは、主観ではなく事実です。Microsoft 365を日常的に開いている人の実数、主要な業務データの所在（SharePointか、ファイルサーバーか）、業務で使われている言語の比率、権限棚卸しに必要な工数——これらを数字で示すと、本社側も計画を修正しやすくなります。「うちには合いません」という反応だけでは、計画は変わらず、その後の運用負荷がすべて現地にかかります。

導入後、効果が出ているかをどう判断すればよいですか？

導入前の状態を測っておかないと判断できません。目的の言語化の段階で対象業務を3〜5件挙げ、それぞれについて現在の所要時間と「効果の測り方」を決めておいてください。

測る対象としては、特定業務の所要時間、利用頻度、利用者の実感、出力の再作業率（そのまま使えたか、直したか）、同じ人数で処理できた件数、といったものがあります。注意点として、削減された時間が他業務に振り替わる場合、キャッシュフロー上の人件費は動きません。人員削減の話として説明すると前提を問われて崩れますので、処理できる量の変化として示すほうが、社内の議論に耐えます。

なお、実際に業務時間を削減できたユーザーは4人に1人に留まるという指摘もあります（二次情報）。この数字を悲観的に受け取るより、業務との不適合、データの所在、使い方が分からない、使う場面がない、といった要因に分解して、自社ではどれに当たるかを確認するほうが実務的です。

まとめ

Microsoft Copilotの導入検討でつまずく箇所は、モデルの性能ではありません。Copilotは権限を破らない一方で、その人が技術的にアクセスできる情報への到達コストをほぼゼロにします。従来、共有設定の粗さが実害を生まなかったのは誰も探し当てなかったからであり、その前提が変わることが、導入時に起きる現象の本質です。

したがって、導入プロジェクトの本体は「ライセンスを買うこと」ではなく「権限の棚卸し」です。継承が切れたフォルダ、「組織全体」リンク、退職者が作った共有サイト、コンテナにしか付いていないラベル——これらを可視化し、露出を遮断してから展開するという順序を守ってください。この順序を飛ばして全社展開すると、費用を払ったうえで情報が広く見える状態を作ることになります。

費用は、①アドオンライセンス、②ベースライセンスの底上げ、③権限棚卸し・データ整備、④展開・教育、⑤運用（利用状況の監視と再配分）の5層で見積もってください。公式価格ページのアドオン価格は1ユーザーあたり月額¥3,148（年払い相当）ですが、これは第1層にすぎません。第3層が最も工数を要し、かつ社外に丸投げできない部分です。

業務の切り分けも先に済ませておく必要があります。会議の要約、長文の読み下ろし、過去資料の探索、議事録からのタスク抽出といった、情報がMicrosoft 365の中にある業務には効きます。一方、基幹システムの中のデータ、図面や品質記録に基づく判断、現場の暗黙知には届きません。後者に取り組む場合は、自社RAGのような別の仕組みが必要です。

ChatGPT等との関係は、択一ではなく用途による使い分けとして設計してください。Microsoft 365に閉じた業務はCopilot、横断・非Microsoft資産はChatGPT Enterprise等、自社固有の資産は自社RAG、という3類型が判断の軸になります。複数プラットフォームの併用は既に珍しくありません。

タイをはじめとする海外拠点では、契約主体（本社一括か現地法人か）と費用の付け替え、多言語での実務品質の差と期待値の合わせ方、そして「とりあえず全員アクセス可」で作られた共有ドライブの現実、という3つが固有の論点になります。特に人事・給与に関わる情報の格納場所は、最優先で確認してください。現地から本社へは、主観ではなく対象者数・データの所在・言語比率・必要工数といった事実を数字で返すことが、無駄な費用と後の運用負荷を防ぎます。

進め方としては、目的の言語化 → 権限の可視化 → 20〜50名のパイロット → 効果測定の設計 → 展開 → 再配分、という順序を推奨します。全社一斉配布を避けるのは、ライセンスが遊ぶこと、権限整備が追いつかないこと、問題が起きたときに戻せないこと、の3つが理由です。

本社から「Copilotを全社に入れる」と言われた段階でも、現地から本社へ提案したい段階でも、まだ何も決まっていない検討の入口でも構いません。「共有フォルダが全員アクセス可のまま10年経っている」「主要なデータがファイルサーバーにあってSharePointに移せていない」「本社の想定と現地の実態が噛み合わない」といった状況の形でお話しいただければ、権限の棚卸しの範囲の見立てや、パイロットの設計から一緒に整理できます。導入を決める前の相談でも構いませんので、お問い合わせフォームからお気軽にお声がけください。

参考情報

• Microsoft「Microsoft 365 Copilot 料金」
• Microsoft Tech Community「Mitigate oversharing to govern Microsoft 365 Copilot and agents」
• Microsoft Learn「Get ready for Copilot with SharePoint Advanced Management」
• Microsoft「Microsoft 365 Copilot vs ChatGPT Enterprise」
• PwC Japanグループ「生成AIに関する実態調査2026 春」
• 帝国データバンク「生成AIの活用状況に関する企業アンケート（2026年3月調査）」
• Bangkok Post「AI adoption helps Thai firms become digitally mature」
• The Nation Thailand（2026年上半期のBOI投資申請）