AIはブームで終わるのか、それとも仕事に欠かせないインフラになるのか。この問いを自社のCopilot導入に置き換えると、見るべきところが変わります。どれだけ賢い回答が出るかに加えて、担当者が替わっても、必要な情報を、必要な人だけが使える状態を保てるか。提案書の作成、社内規程の確認、問い合わせへの回答。こうした仕事にAIを組み込むほど、情報の保存先、アクセス権、異動時の処理が、回答の品質と安全性を左右する構造です。

この記事は、Microsoft 365でCopilotを業務のインフラにするために、最初の1業務で決めることを書きます。読者は、Copilotのライセンスを買ったか買おうとしていて、どこから手を付けるかを決める立場の情報システム担当者と、AI推進を任された人です。記述は2026年10月26日時点の公式資料に基づきます。なお、確認時点の公式資料では、Microsoft 365 CopilotはMicrosoft Copilotに名称が変わっています。この記事では単にCopilotと書く。

結論を先に書きます。

  1. 最初に行うのは、全社の資料を一度に接続することではありません。 対象業務を1つ選び、その業務でAIが使う資料と、その資料を使ってよい人を整備します。資料ごとに、正しいバージョン、更新する担当者、閲覧権限、保存先を決めます
  2. Work IQをONにしても、新しい閲覧権限は付きません。 Copilotは、その人がすでに閲覧できる情報だけを参照します。だからこそ、権限が広すぎる状態は、そのまま回答に出る。SharePointの権限は、グループだけでなく個別共有と、部署異動の前後まで含めて確かめます
  3. 止める仕組みは、原本のアクセス権と、入力文を検査するDLPルールと、ラベル付きの資料を処理から外すDLPルールの3つを組み合わせます。 PurviewのDLPは、Copilotへ直接入力した文章に機密情報の種類が含まれるときに処理を止められます。ただしこの機能は確認時点でプレビューで、プロンプトに直接アップロードしたファイルの中身は検査しません
  4. AIが作った資料にも、公開範囲を別に決めます。 SharePoint Knowledge Baseのように、生成されたページが元資料の権限もラベルも引き継がない機能があります。生成して終わりにせず、保存先、共有相手、更新担当を原本とは別に決める、が4つ目です

まず、どの仕事を、どの情報で終えるかを決める

たとえば、営業担当が製品の仕様と社内の見積ルールを確認し、提案書の下書きを作る業務を考えます。

この場合、最初に対象にするのは、承認済みの製品資料と、その営業担当が閲覧できる見積ルールです。過去の案件資料、顧客の契約書、人事情報まで一緒につなぐ必要はありません。つなぐ範囲を広げるほど、確かめる権限の数が増え、最初の1業務が終わらなくなります。ここでいう資料の選定は、最初の業務で根拠にする資料を決めることです。質問するときも、対象のファイルやライブラリを指定して頼みます。選定しただけで、その人がアクセスできる他の情報がCopilotの参照対象から外れるわけではありません。外したい情報は、権限の側で扱います。

資料ごとに決めるのは4つです。

決めること 営業の提案書の例
正しいバージョン 製品カタログは2026年度版のPDFだけ。旧版はアーカイブ用のライブラリへ移し、質問時に指定しない
更新する担当者 製品企画の担当者が年1回更新し、更新したら営業責任者に知らせる
閲覧を認める人 営業部のグループ。協力会社の担当者は含めない
保存先 営業部のSharePointサイトの「提案資料」ライブラリ。個人のOneDriveには置かない

そのフォルダーに入っているから使う、という選び方では、古い条件や他社向けの約束を混ぜる恐れがあります。資料の一覧を作る段階で、使ってよいものと、見えてはいるが使わないものを分けます。

役割分担も、この段階で作ります。AIの導入担当だけで判断せず、営業責任者が資料と完了条件を決め、情報システム担当が権限と設定を確認する。完了条件とは、たとえば「製品の仕様と見積ルールに沿った提案書の下書きが出て、営業担当が15分以内に確認して送れる状態」のように、業務が終わったと言える状態のことです。これを最初の1業務で作ると、2つ目以降の業務は同じ型で進められます。

Work IQをONにすると、いつ社内情報がAIに伝わるのか

ここは、索引を作る、回答の材料として使う、モデルを学習させる、の3つを分けると理解しやすくなります。

Work IQは、Copilotがその人の仕事の文脈を理解するための層で、Microsoft Copilotのアドオンライセンスを持つ利用者が使えます。ライセンスがあればデフォルトでONになっており、切り替えはチャット画面の左上にあるWork IQのボタンです。ONにすると、Copilotはメールやファイル、チャットや会議、人やプロジェクトといったMicrosoft 365上の仕事のデータを回答に使えます。対象はすでに閲覧権限を持つ情報で、ONにしたこと自体が新しい閲覧権限を与えるわけではありません。公式のサポートページの言い方では、Work IQはすでに持っているアクセスの規則をそのまま守る、です。

タイミング 起きること 会社が決めること
質問する前 対象の情報について、検索用の索引がサービス側で作成され、更新される AIに参照させる情報の範囲と、原本のアクセス権
質問したとき 質問と利用者の権限に応じて、関連する業務情報が検索され、取得される 本当にその人が取得してよい情報か
回答を作るとき 取得した情報が、回答の文脈としてモデルに渡される 機密情報の利用条件、入力と参照の制御
回答した後 会話や生成した資料など、原本とは別の管理対象が生まれる 保存先、共有相手、保存期間、回収担当

索引について補足します。Microsoftの説明では、Copilotの有料ライセンスがあるテナントには、SharePoint Onlineのテキスト系ファイルから組織全体の索引が自動で作られます。管理者の操作は要らず、止めることもできません。2人以上がアクセスできるサイトに追加された新しい文書は毎日索引に入り、索引済みの文書が更新されると即時に反映されます。索引はその人のアクセス権を守るので、索引があること自体で誰かに見えるようにはなりません。

つまり、Work IQをONにした瞬間に、社内の原本をまとめて基盤モデルの学習へ渡す、という仕組みではありません。Microsoftは、Copilotのプロンプト、回答、Microsoft Graphを通じて参照するデータを、基盤モデルの学習に使わないと説明しています。

ただし、学習に使わないことと、情報を処理して保存しないことは別です。 プロンプトと回答は、Copilotの活動履歴として保存されます。管理者はコンテンツ検索やMicrosoft Purviewで閲覧と保持期間の設定ができ、利用者は自分のアカウントのページから履歴を削除できます。また、Work IQをOFFにしても、添付した資料、公開されているWeb情報、利用者のプロフィールとパーソナライズの設定は使われる仕様です。OFFを「何も社内情報を渡さない設定」として社内に案内しないようにします。

SharePointの権限は、部署異動まで含めて確認する

Copilotが既存の権限に従うなら、権限が広すぎる状態も、そのまま回答に影響します。Microsoftも、SharePointなどの権限モデルを使って、正しい利用者やグループが正しいコンテンツにアクセスできる状態にする必要がある、と説明しています。

導入前には、対象サイトについて、全社員、広い部門グループ、特定の人への個別共有の3つを確かめます。グループを整理しても、個別共有や共有リンクが残っていれば、期待した権限にはなりません。索引の説明にも、組織内の全員に有効なリンクで共有しただけでは組織全体の索引には入らず、そのリンクを開いた人の索引に入る、という記述があります。誰に見えるかは、グループと個別共有とリンクの3つを合わせて決まります。

部署異動では、次の2つを分けて扱います。

部署異動で分けて扱う2種類の情報を、権限と成果物の2つのレーンで示した図。上の権限のレーンでは、異動の発令の後に旧部署のグループ、個別の権限、共有リンク、接続アプリを見直し、本人のアカウントで旧部署の資料を取得できないことを確かめる。下の成果物のレーンでは、異動前に取得した回答、ダウンロードしたファイル、生成した提案書を洗い出し、保存義務を確かめてから、共有停止、保管、削除を決めた担当が実施する

1つ目は、異動後に新しく取得する情報です。 旧部署のグループ、直接付与した権限、共有リンク、接続アプリの権限を見直します。変更後は本人の利用条件で、旧部署の資料を新たに検索して取得できないことを確かめます。人事システムを更新したから完了、ではなく、実際のアクセス結果で判断してください。確かめ方は、本人のアカウントで旧部署の資料の直接URLや共有リンクを開き、アクセスが拒否されることを見て、付与した権限も点検する。そのうえでCopilotに旧部署の資料について質問し、新たに取得されないことを追加で確かめます。Copilotが回答に使わないことと、取得する権限が無いことは別なので、権限の点検を先にします。

2つ目は、異動前に取得した情報です。 会話の回答、ダウンロードしたファイル、生成した提案書まで、原本の権限変更だけで回収できるとは限りません。必要な保存義務を確かめ、共有停止、保管、削除を判断する担当を決めます。

アクセス権の変更と、DLPや検索制限の設定変更は、反映を別々に確かめます。公式資料によると、DLPポリシーの更新がCopilotに反映されるまで最大4時間。後述のRestricted Content Discoveryは、項目が50万件を超えるサイトでは1週間以上かかる場合があります。権限そのものの反映はこれらとは別なので、実際のアクセス結果で確かめる。時間差がある前提で、急ぐときの利用停止の方法を用意しておく。導入試験には、正常な利用者に加えて、異動した利用者のケースも入れてください。

プロンプトを止めるDLPと、資料の保護を組み合わせる

Microsoft Purviewには、Copilotへ直接入力した文章に機密情報の種類が含まれる場合、プロンプトの処理を止める機能があります。Microsoftが用意した分類だけでなく、自社で作ったカスタムの機密情報の種類も対象です。確認時点ではプレビューで、Copilotを使えるテナントへ順に展開中です。自社のテナントで適用できるかを先に確かめます。

止める仕組みを3段に分けた図。1段目は原本のアクセス権で、見えてよい人だけに見せる。2段目は入力文を検査するDLPルールで、機密情報の種類を含むプロンプトの処理を止める。3段目はラベルを条件にしたDLPルールで、秘密度ラベルの付いたファイルやメールをCopilotが回答に使わないようにする。ラベルを付けただけでは止まらず、直接添付したファイルは別に確かめる

設定の流れはこうです。Purviewポータルでカスタムのポリシーを作る。場所をMicrosoft 365 CopilotとCopilot Chatにする。条件に機密情報の種類を指定し、アクションでプロンプトの処理を制限する。同じ条件で、Web検索だけを制限するアクションもあり、こちらは回答自体を社内データで続けます。どちらを選ぶかで動作が違うので、設定時に確かめてください。

ここで押さえておきたいのは、この検査は、プロンプトに直接アップロードしたファイルの中身を検査しないという点です。DLPが見るのは、プロンプトに入力した文章だけです。ファイルの側は、秘密度ラベルを付けたファイルやメールをCopilotが回答に使わないようにする別のルールで守ります。原本のアクセス権、入力文を検査するDLPルール、対象のラベルが付いた資料を処理対象から外すDLPルールの3つを組み合わせます。ラベルを付けただけでは処理は止まらず、ラベルを条件にしたルールが要る。プロンプトに直接添付したファイルや、ラベルに対応しない生成物は、この3つでは守れないので、別の方法を確かめます。

導入時は、検証用の顧客番号などを使い、止めたい入力が止まることと、通常の問い合わせは進むことの両方を確かめます。対象者を限定して運用を確かめ、問い合わせの窓口と例外の承認方法を用意してから広げる順番です。止められた利用者に出る案内文のリンク先は、自社の説明ページに変えられます。なぜ止まったかを社内の言葉で書いたページを1枚用意しておくと、問い合わせが減ります。

既存資料の整理に時間が必要な場合は、Restricted Content Discoveryという機能があります。特定のSharePointサイトを、組織全体の検索と、Copilotが組織全体から資料を探す場面から一時的に外す機能です。権限のある利用者が開いた文書を要約する操作などは対象外です。前提はCopilotのライセンスとSharePoint Advanced Managementで、SharePoint管理センターの対象サイトの設定で有効にします。ただし、この機能は元のアクセス権を変えません。すでにアクセスできる人は、サイトを直接開けば今までどおり見られます。あくまで権限を見直すまでの時間を稼ぐ機能なので、権限の見直しは並行して進めます。

AIが作った資料にも、公開範囲を設定する

原本の権限が正しくても、AIが作った資料を広い範囲へ置けば、情報の共有範囲は変わります。

具体例が、SharePoint Knowledge Baseです。確認時点ではFrontierプレビューで、組織によっては表示されません。公式の説明では、生成されるページは元資料の権限を引き継がず、ナレッジベースにアクセスできる人は、元資料から追加された内容を見られます。元資料の変更や削除も自動では反映されず、更新は頼んだときだけです。元ファイルの秘密度ラベルも引き継がれず、ページ自体がファイル単位の秘密度ラベルに対応していません。CopilotやAutopilotによる作成と更新にはCopilotのクレジットを使い、手動の作成と編集には要りません。

この機能を使うなら、ページを作る前に公開先と閲覧者を確かめ、元資料に変更があったときの更新担当を決めます。機密区分の異なる資料を混ぜる場合は、生成された内容を確かめてからの公開が前提です。

同じ考え方は、AIで作る提案書や議事録にも使えます。保存先、共有相手、更新責任者を、原本とは別に決めることです。営業の提案書の例なら、下書きは営業担当の個人フォルダーではなく、営業部の「提案書下書き」ライブラリに保存し、送付前に営業責任者が確かめる、という運用にします。生成して終わりにせず、その後の利用まで業務として設計します。

最初の1業務を、4つの確認で公開する

最初の会議では、次の4つを決めれば実装へ進めます。

  1. 使う資料を確定する。 業務担当が、対象資料、正しいバージョン、更新者を一覧にする
  2. 権限と保護を設定する。 情報システム担当が、閲覧者、共有方法、入力制御、保存先を決める
  3. できることと、できないことを試す。 正常な回答に加えて、他部署の情報、機密情報の入力、異動後のアクセスを検証する
  4. 運用を引き継ぐ。 問い合わせ先、異動時の作業、資料の更新、停止する人を業務手順へ入れる

3番目の検証は、試験の項目を先に書いておくと進めやすくなります。営業の提案書の例で書くと、次のようになります。

試験 期待する結果
営業担当が製品の仕様を聞く 2026年度版のカタログを根拠に回答が出る
営業担当が人事評価の資料を聞く 見つからない、または回答に使われない
検証用の顧客番号を含む文章を入力する DLPで処理が止まり、案内文が出る
異動した元営業担当が見積ルールのファイルを直接開き、続けてCopilotに聞く 直接のアクセスが拒否され、回答にも使われない
生成した下書きの保存先を確かめる 営業部のライブラリに保存され、個人フォルダーには無い

利用開始の条件は、回答が一度うまく出たことではありません。対象業務が終わり、許可しない情報は取得できず、誤入力や異動が起きても担当者が対応できることです。

KOIYALの見解

当社がCopilotの導入支援で最初に聞くのは、どの機能を使いたいかではなく、どの業務を、どの資料で終わらせたいか、です。全社を一度に対象にすると、権限の確認の負担が大きくなり、最初の運用までたどり着きにくくなります。1つの業務に絞ると、確かめる資料は数件、確かめる権限は数グループに収まる。開始の時期は、資料の数、権限の状態、使う機能の提供状況を見て決めます。

この記事で書いた4つの確認は、Copilotに限った話ではありません。資料の大もとを決める、使ってよい人を決める、成果物の置き方を決める、運用を引き継ぐ。この型を1業務で作れた会社は、2つ目以降の業務で、資料の整理と運用手順を業務部門で再利用できます。新しい権限設定や保護ルールが要るときだけ、情報システム担当の出番です。当社はこれをインハウス経営（AIを活用し、自社で業務を改善し、自社で仕組みをつくる経営）の入口だと考えています。Copilotが仕事のOSになる前に自社で持つ3つで書いた、データの大もとと枠を決める人を、最初の1業務で実際に置くのがこの記事の中身です。

1つ付け加えると、プレビューの機能は、設定できることと、自社のテナントで動くことが別です。プロンプトの検査もKnowledge Baseも、確認時点ではプレビューです。設計には入れてよいが、運用開始の条件には、自社で止まることを確かめた日付を入れてください。

次の行動

  1. 最初の1業務を1つ決め、その業務で使う資料を4列（正しいバージョン・更新者・閲覧者・保存先）で一覧にする
  2. 対象サイトの権限を、グループ、個別共有、共有リンクの3つに分けて書き出す
  3. 上の試験の表を自社の業務に置き換え、異動した利用者のケースを1つ入れる

3つが書けたら、それを持って相談に来てください。AI・DXコンサルティングの初回の打ち合わせでは、最初の1業務を、資料、権限、成果物の3点で一緒に決めます。お問い合わせの本文に、Copilotのライセンスの有無と、最初に任せたい業務を1つ書いていただければ、初回の前に当社で確かめる権限の範囲を仮置きします。手順を社内で配る形にしたい会社は、Copilotに毎回同じ説明をしない。SharePointで手順を配るも合わせて読んでください。

参考