Copilotを全社に配って半年。使っている人はいるのに、出てくる成果が人によってまるで違う。社内でそういう状態になっている会社は多いはずです。
よく観察すると、成果を出している人は毎回、長い前置きを書いています。この部署ではこの書式を使う、参照するのは共有フォルダのこの資料、見てほしい観点はこの3つ。この前置きが上手い人だけが、まともな答えを引き出せています。そして前置きは本人のチャット履歴に残るだけで、他の人が使える形にはなりません。
この記事では、その前置きを個人の頭から取り出して、社内で配れる形にする方法を扱います。Microsoftが2026年8月27日に公開した5社の実例と、SharePointの機能仕様を整理します。あわせて、自社で始める3ステップと、導入前に確認すべき提供段階・ライセンス条件までまとめます(確認日: 2026年9月6日。この領域は数週間で変わるため、導入判断の際は各公式ページで最新の状態をご確認ください)。
先に結論を3つ書きます。
- 毎回書いている前置きは、SharePointのサイト上に保存して他の人が使える手順にできる。Microsoftはこれを skills と呼んでいます
- ただしこの機能を提供する Copilot in SharePoint は、2026年9月6日時点でプレビューの扱いです。利用にはMicrosoft Copilotライセンスが要ります
- 効果が出るのは、繰り返す・社内コンテンツが中心・良し悪しの基準がある業務に限られます。思いつきの相談や一回きりの企画には向きません
Copilotの成果が人によって割れる理由
生成AIの社内展開が止まる場所は、だいたい決まっています。契約でも、操作研修でもありません。同じ仕事を同じ品質で繰り返せないところで止まります。
Copilotに何かを頼むとき、答えの質を決めているのは指示の長さではなく、指示に含まれた前提の量です。どの資料を根拠にするか。どんな形式で出すか。何を確認済みとして扱い、何を人が判断するか。この前提を毎回書ける人は成果を出し、書けない人は当たり障りのない要約を受け取ります。
問題は、前提を書ける人が社内に数人しかいない点ではありません。その人が書いた前提が、どこにも残らない点です。ベテランが20分かけて組み立てた指示は、本人の履歴の中に埋もれます。次に同じ仕事をする人は、またゼロから組み立てます。
これは生成AIが持ち込んだ新しい問題ではなく、業務手順が人に付いていて会社に残らない昔からの課題が、AIの画面の上で見えやすくなっただけです。引き継ぎ資料が薄い会社、ベテランの勘で回っている工程がある会社では、Copilotを配っても差がそのまま拡大します。
Microsoftが今年に入って SharePoint に入れてきているのは、この前提をサイトの上に置いて共有する仕組みです。
SharePointの手順(skills)が何をするものか
まず機能の説明をします。以下はすべてMicrosoftの公式ドキュメントに基づく内容です(確認日: 2026年9月6日)。
Copilot in SharePoint は、SharePoint上のサイト・ページ・リスト・ライブラリ・ファイルを対象にした機能です。質問への回答、内容の比較と要約、情報の整理、成果物の作成を行います。動かすのはチャットパネルからの自然言語のやり取りです。
その上に載っているのが skills です。公式ドキュメントでは英語名の skills で説明されています。中身は繰り返し行う複数ステップの作業を再利用可能な資産に変えたもので、実態は業務手順そのものです。この記事では以降、読みやすさのため手順と書きます。
仕様のうち、導入判断に効く点を並べます。
- 作り方: チャットで自然言語のまま作れます。やりたい流れを説明すると下書きが返り、内容を確認してから保存します
- 呼び出し方: 保存後は、関連する依頼をしたときにCopilotが自動で読み込みます。名前を指定した明示的な呼び出しも可能です。チャットに
/skillsと入力すると、その場で使える手順の一覧が出ます - 保存場所: サイト内の Agent Assets ライブラリに、Markdownファイルとして保存されます。パスは
/Agent Assets/Skills/<スキル名>/SKILL.mdです。ファイルを直接開いて中身を読めます - 統制: Agent Assets ライブラリは製品が作成・管理し、削除はできません。一方で、権限・保持ラベル・秘密度ラベル・監査といったSharePointの通常のファイル統制は、他のコンテンツと同じようにかけられます
- 権限の既定: サイトの編集(Edit)権限があるユーザーが手順を作成でき、閲覧(View)権限があるユーザーが実行できます。この配分を変えたい場合は、Agent Assets ライブラリの権限継承を切って個別に設定します
- 管理者のスイッチ: 手順はCopilot in SharePointのネイティブ機能で、手順だけをオン/オフする管理者向けの設定はありません
- 組み込みの手順: Microsoftが提供・保守する組み込みの手順があり、手順の作成・点検・改善そのものを助けます。組み込みの手順はAgent Assetsライブラリには保存されず、ユーザーが直接編集することもできません
そして、できないことも公式に明記されています。
- 外部システムへの接続とカスタムコードの実行はできません
- 手順は、実行するユーザーが元々持っている権限の範囲でしか動きません。アクセスを広げることも、Copilot in SharePointが持っていない機能を新たに足すこともありません
この2点は導入検討で最初に聞かれるところなので、押さえておくと社内の説明が楽になります。基幹システムと繋いで自動処理を回す用途ではなく、SharePointに置いてある文書とリストを、決めた手順で読んで整理する用途です。
Microsoftが公開した5社の実例
2026年8月27日、SharePointチームのブログに、Copilot in SharePointで業務プロセスを改善した5つの事例が公開されました。記事には、実際の顧客シナリオに基づくものだが、顧客の機密を守るため組織名と識別情報は一般化してあると明記されています。個社の実名事例ではない点は差し引いて読む必要がありますが、業種と業務の型が具体的なので、自社に当てはめる材料としては十分に使えます。
1. 散らばったプロジェクト更新を、たどれる変更履歴にする
ライフサイエンス企業の事例です。複雑なプロジェクトが時間とともにどう変わってきたかを把握する手段がありませんでした。重要な決定や更新が、メールの書き出し、プレゼン資料、計画書などに散らばっており、経緯を再構成するには大量の手作業が必要でした。何がいつ、なぜ変わったのかが見えない状態です。
このチームは、承認済みのプロジェクト資料をSharePointサイトに集め、段階的に内容を確認する再利用可能な手順を設計しました。手順は計画上の前提、スケジュール、リソースなどの変更点を特定し、人が確認できる形の変更履歴に整理します。
記事にはプロンプト例も載っています。サイト上のプロジェクトファイルを確認し、前提・スケジュール・リソース・決定事項の変更を特定する。そのうえで、根拠資料へのリンク付きで構造化された変更履歴を作る。この流れを手順として作成してほしい、と依頼する形です。
結果として、プロジェクトの要約・変更レビュー・関係者への報告が、毎回同じ出発点から始められるようになりました。判断するのは引き続き人ですが、過去を組み立て直す時間が減った分だけ、次の一手に早く移れます。
2. 公開前の資料を、承認済みの原典と突き合わせる
企業の財務部門の事例です。定期的に社外公開向けの資料を作っており、公開前に、財務数値・業績要因の記述・定性的な主張を、承認済みの社内文書と突き合わせて確認する必要がありました。細かく、繰り返しが多く、根拠をたどれることが強く求められる作業です。
このチームは、下書きと裏付け資料をSharePointに置きました。Copilot in SharePointで複数ファイルにまたがる記述を確認し、結果を人のレビュー用に整理する流れです。出力に並ぶのは、対象の記述・根拠となった文書・参照箇所・検証ステータス・備考・推奨される次のアクションです。
この事例には数字が出ています。四半期あたり約4週間分の手作業が削減されました。 レビュー担当者は、全文書を手で当たって一次通過を作る作業から解放され、裏付けが取れない記述、矛盾する記述、あいまいな記述に注意を集中できます。最終的な解釈と判断の責任は財務チームが持ったままです。
3. 600人が使うナレッジリストを、会話で引けるようにする
テクノロジー企業の事例です。カスタマーサクセスチーム向けの中央ナレッジとして、SharePointリストを運用していました。顧客の目的別に、推奨される戦略・アクション・資料・ガイダンスが入っています。リストが育つにつれ、目的に合う項目を探す、重複を見つける、顧客向けの計画に組み直すといった作業が重くなっていきました。
Copilot in SharePointを使い、このリストを自然言語で扱えるようにしました。特定の目的で絞り込む、関連するガイダンスを要約する、結果を使える計画の形に整える。リストの持ち主側も、構造の見直し、列やビューの改善、重複または統合候補の項目の洗い出しに使っています。
600人を超えるチームが、数百件のリスト項目をたどる代わりに、Copilotとの短いやり取りで必要なガイダンスに届くようになりました。全員が複雑な絞り込みの操作を覚える必要がなくなった点が、この事例の効きどころです。
4. 提案書づくりを5つの手順に割る
プロフェッショナルサービス企業の事例で、5つの中では最も設計が細かい例です。提案書の作成にかかる手作業を減らしたい課題がありました。過去の提案書や承認済みナレッジを探し、要件を解釈し、再利用できる内容を見つけ、初稿を組み立てる。そこまで終えてようやく、提案の差別化に頭を使えます。
この組織は、それぞれの段階に人の確認地点を置いた5つの手順を設計しました。
- 要件の抽出: RFP一式を読み、必須要件・評価項目・提出方法・主要な義務を特定して、構造化した要件表を作る
- コンテンツの探索と対応付け: 承認済みのSharePoint上の情報源から、関連する事例・方法論・提案文を探し、それぞれを該当する要件に対応付ける
- 提案戦略: 要件・承認済みの情報・関係者の入力を統合し、提案の構成・伝えるメッセージの優先順位・専門家の入力が要る箇所を提示する
- 本文の作成: 決まった提案戦略とSharePoint上の根拠に基づいて各節を書き、情報が足りない箇所には明示的なプレースホルダーを挿入する
- 品質とリスクの点検: 下書きを原典、提出要件、社内規程、ブランド規約と突き合わせ、裏付けのない主張・抜け・人の承認が要る項目を洗い出す
分割したことで、初稿までの速度を上げつつ、提案戦略・専門的判断・主張の裏付け・最終承認の責任範囲をはっきりさせられました。AIに一発で提案書を書かせない設計が、この事例の核です。
5. 大量の契約書のコンプライアンス点検
グローバル企業の法務オペレーション部門の事例です。第三者のコンテンツ・サービス・データの利用条件を定める契約を管理しています。定期的なコンプライアンスレビューでは、大量の契約を精査し、主要な条項を承認済みの標準や許容される代替表現と比較する必要がありました。全件を手で見るやり方では、大規模な文書群に対して一貫した水準を保つのが困難でした。
契約書、コンプライアンスのガイダンス、レビュー基準をSharePointに置き、Copilot in SharePointで監査を支援しています。数千件の文書を解析し、承認済みガイダンスと突き合わせ、結果を分類し、追加調査が要りそうな契約を浮かび上がらせる流れです。検証と最終的なコンプライアンス判断の責任は、引き続きレビュー担当者にあります。
5社に共通していた5つの設計
Microsoftの記事は、5社が異なる課題を扱いながら、強い成果につながったワークフローには共通の設計があると書いています。
- 信頼できるコンテンツから始める。チームがすでに管理しているファイル・リスト・ライブラリ・ページ・サイトの文脈に根ざしている
- 実際に繰り返す業務を選ぶ。目的は気の利いた一回きりのプロンプトではなく、人が一貫して行う必要のある業務である
- 一貫性が要る箇所は、焦点を絞った指示と再利用可能な手順にする。ステップ、想定される入力、出力形式、品質の基準を書き留めて、繰り返せるようにする
- 人が決める状態を保つ。Copilotは調査・整理・比較・下書きを助け、内容の専門家が出力を確認して最終判断を持つ
- たどれるようにする。出典への参照と明確な確認地点を設計に含め、重要な仕事に使う前に検証できるようにする
この5つは、そのまま自社の点検項目として使えます。特に4番目と5番目は、社内でAI活用が進み始めた会社ほど抜けやすいところです。
最初の1本をどう選ぶか
ここからは自社で始める話です。Microsoftのプログラムマネージャーが、早期利用プログラムで複数の顧客と作業した経験をまとめた記事を2026年6月30日に公開しており、そこに実務的な選定基準が書かれています。
多くの失敗は、業務の選び方の段階で決まります。何かを作り始める前に、次の3つの問いを通します。
- 作る価値があるか。手間をかけるだけの繰り返しがあり、再利用する価値が出るだけの効果があるか
- コンテンツ中心の業務か。仕事が文書やデータに駆動されていれば、Copilot in SharePointは正しい原典にアクセスし、手順に書かれた規則に従い、チームが確認・再利用できる出力を作れます
- 正しい結果にたどり着く、再現可能な進め方があるか。再現可能とは、毎回同じものが出ることではありません。良い状態の基準があり、そこへ至る一貫した道筋があることを指します
この3問を通すと、通る業務と通らない業務がはっきり分かれます。記事に挙げられている例は次のとおりです。
通る業務: 提案書の作成、契約や規程のコンプライアンス確認、調達先や取引先の評価、リスクの洗い出しと対策の計画、リリース可否のレビュー。
通らない業務: 一回きりのクリエイティブ作業(繰り返しがなく、積み上がるものがない)、発散的なブレインストーミング(目標が定まらず、正解の共通基準もないため、手順に書き留める対象がない)。
自社の業務をこの物差しに当てると、最初の1本はかなり絞られます。中小企業で選ばれやすいのは、見積書と提案書の下書き、社内規程との突き合わせ、定例報告の材料集め、問い合わせ対応のテンプレート化あたりです。
手順を配る3ステップ
5社の事例と選定基準から取り出せる作業は、次の3つです。順番にも意味があります。
ステップ1: 信頼できる社内コンテンツを1か所に集める
最初にやるのはAIの設定ではなく、根拠にする資料をSharePointサイトに集めることです。5事例のすべてが、この作業から始まっています。承認済みのプロジェクト資料、承認済みの原典、ナレッジリスト、過去の提案書、契約書と審査基準。
ここで効いてくるのが、資料そのものの状態です。古い版と新しい版が混在している、担当者のOneDriveに原本がある、PDFをスキャンしただけで文字が拾えない。こうした状態のままでは、手順を書いても出力は安定しません。AIに読ませることを前提にした資料の作り方については、AIに読ませる資料の作り方に別途まとめています。
このステップは地味ですが、着手から最も時間がかかる部分です。1か月見ておくくらいの感覚が現実的です。
ステップ2: ベテランがやっている手順を書き出す
次に、その業務を分かっている人が実際にたどる段取りを文章にします。何を見て、どの順で判断し、どういう形式で出すか。曖昧なまま残っている判断基準ほど、書き出す価値があります。
ここで参考になるのが、先ほどのプログラムマネージャーの記事にあるハンドオフから設計するという考え方です。AIができることから手順を決めると、要約する、下書きする、抽出するといった単位になりがちです。そうではなく、次に受け取る人が仕事を進めるために何が要るかから決めます。提案書の例なら、答えを書く手順ではなく、回答すべき項目の一覧を作る手順、要件と承認済み資料を対応付ける手順、レビュー担当者向けの判断材料をまとめる手順のほうが役に立ちます。
書き出した段取りは、チャットでそのまま渡せば手順の下書きになります。返ってきた定義を読み、ステップ・入力・出力を直してから保存してください。ここで保存された SKILL.md は普通のMarkdownファイルなので、後から中身を読んで手を入れられます。
ゼロから書くのが難しければ、コミュニティが公開している手順を読むのが早道です。SharePointの開発者コミュニティ(PnP)が運営する公開サイトには、2026年9月6日時点で49本の手順が並んでいます。未公開ページの棚卸し、OneDrive同期を壊すファイル名の検出、ドキュメントライブラリの一覧ダッシュボードなど、内容も具体的です。自社で書く前に、書き方の型を見る材料になります。
ステップ3: 人が判断する地点を先に決める
3つ目が、実務でいちばん差が出る部分です。先の記事は、自動化を設計する前に人の確認地点を設計せよと指摘しています。
紹介されているのは、取引先評価の場面です。手順が回答を採点し、理由付きの順位表を出しました。書類の上ではレビュー担当者に最終決定権があります。ところが実際には、出力が完成品に見えるため、評価し直すより受け入れるほうが楽になっていました。人が確認する形式を残しても、確認が形骸化します。
有効な確認地点には条件があります。レビュー担当者に本当に決めるべきことがあり、確かめられる根拠が示され、おかしいと思ったときに覆す理由が持てること。設計としては、判断基準を先に合意しておく、推奨の根拠を必ず表示する、承認や差し戻しの際に理由の記入を求める、といった形になります。
レビューの量を増やすのではなく、レビューの設計を変える発想です。この観点は、AIを業務に組み込む会社が最初につまずくところで、社内規程やチェックリストの見直しとセットで考える価値があります。
使い始める前に、効果の測り方も決めておく
同じ記事に、測定についての指摘もあります。利用回数は成果ではありません。 チームが数百回使っても、業務が良くなっていないことはあります。試している、プロンプトを書き直している、答えを確かめている、価値の低い作業に使っている。どれも利用回数としては同じに見えます。
見るべき問いは、業務そのものが良くなったかどうかです。コンテンツ中心の業務では、かかった時間・着手から完了までの日数・手戻りの回数の3つが手がかりになります。指標を並べたダッシュボードを作るのではなく、経営層が見て広げる価値があると判断できる数字を1つだけ選ぶほうが現実的です。
導入前に確認すること
ここまでの内容は使い方の話でした。実際に社内へ展開する前には、提供段階・ライセンス・制約の確認が要ります。以下は2026年9月6日に公式ドキュメントで確認した内容です。
提供段階とライセンス
Copilot in SharePointは、公式ドキュメント上でプレビューとして説明されています(以前は AI in SharePoint と呼ばれていました)。2026年6月中旬からは、オプトイン方式のプレビューからオプトアウト方式のプレビューに変わり、Microsoft Copilotライセンスを持つユーザーに自動的に提供される形になりました。管理者側の有効化操作は不要で、以前にテナントまたは特定サイトをオプトアウトしていた場合は、その設定が引き継がれます。
- 必要なライセンス: 有効なMicrosoft Copilotライセンス。Copilot in SharePointは、プレビュー中も一般提供後も、このライセンスに追加費用なしで含まれると公式に記載されています
- 一般提供(GA)の時期: 公式ページでは確認できませんでした。提供段階が変わる可能性がある前提で計画してください
- 有効かどうかの確認: 管理はPowerShellの
Set-SPOTenantのKnowledgeAgentScopeパラメータで行います。ドキュメントには自動的に提供されるとの記述と、このパラメータの既定値はNoSitesであるとの記述の両方があります。自社の設定値を見るコマンドはGet-SPOTenant | Select-Object KnowledgeAgentScope, KnowledgeAgentSelectedSitesListです(SharePoint Online管理シェル)。適用範囲がIncludeSelectedSitesまたはExcludeSelectedSitesの場合、サイトの一覧まで見ないと対象は分かりません。なおこの設定値だけで利用可否は決まらず、ライセンスの有無と後述のRestricted Content Discoveryも効きます。サイトの一覧は100件までの上限があります
なお、SharePointのエージェントは別の機能です。各サイトに標準で付いてくるものと、編集権限のあるユーザーが作る独自のものがあります。こちらもMicrosoft Copilotライセンス、または組織で有効化した従量課金(pay-as-you-go)が必要です。社内で話をするときは、エージェントと手順を混ぜないほうが混乱しません。
使えない環境と言語
- 対象外の環境: 現時点では次の環境に対応していません。Microsoft 365 Government(GCC・GCC High・DoD)、エアギャップのOffice 365環境、21Vianetが運営するMicrosoft 365
- 言語: SharePoint Onlineの対応言語一覧と、Microsoft Copilotの対応言語一覧の両方に含まれる言語だけが対象です。Microsoft Copilot側の一覧には日本語の記載があります。対応外の言語では検証されておらず、結果が変わる可能性があると公式に注意書きがあります
利用量の上限
プレビュー中は、公平な利用のためユーザーごとに日次と週次の利用上限がかかります。上限は個人単位で、組織内で共有されるものではありません。上限に達すると、リセットまでCopilotの機能が一時的に使えなくなり、その旨がSharePoint上で通知されます。Microsoftは利用状況を見ながら上限を調整する可能性があるとしています。全社の基幹業務をこの上に載せる前に、この制約は社内に共有しておくべき点です。
情報統制の観点
手順は、実行するユーザーの権限を超えて動きません。裏を返すと、SharePointの権限設計が粗いままだと、その粗さがそのまま出力に現れます。見えてはいけない資料が閲覧できる状態になっていれば、Copilotは素直にそれを根拠として使います。
- Agent Assetsライブラリの権限: 既定では編集権限があれば手順を作れます。作れる人を絞りたい場合は、このライブラリの権限継承を切ります
- Restricted Content Discovery: この設定が有効なサイトでは、Copilot in SharePointとAIの各種操作は表示されません。Copilot in SharePointの提供設定にかかわらず適用されます
- サイトのAI設定: サイト所有者は、AIアイコンから開くエージェントの選択や、サイト訪問者に対するCopilotボタンの非表示を設定できます
生成AIの社内展開でいちばん多い事故は、機能の不具合ではなく過剰共有の顕在化です。展開の前に、共有リンクの棚卸しと権限の見直しを済ませておくと、後から慌てずに済みます。
使われるモデル
Copilot in SharePointは、Microsoftが管理するOpenAIの推論モデルで動きます。モデルの選定と管理はMicrosoftが行い、新しいモデルの採用に伴って変わる場合があります。利用者側でモデルを設定する必要はなく、設定もできません。モデルの指定が要件になっている業務では、この点を確認してください。
確認事項の一覧
| 確認項目 | 2026年9月6日時点 |
|---|---|
| 提供段階 | プレビュー(2026年6月中旬からオプトアウト方式) |
| 必要ライセンス | Microsoft Copilotライセンス(追加費用なしで含まれる) |
| 一般提供の時期 | 公式ページで確認できず |
| 有効化 | 管理者操作は不要。実状態は Get-SPOTenant で確認 |
| 対象外の環境 | GCC / GCC High / DoD / エアギャップ / 21Vianet |
| 言語 | SharePointとCopilotの対応言語一覧の重なりのみ |
| 利用上限 | プレビュー中は個人ごとに日次・週次の上限あり |
| 手順の保存先 | サイト内 Agent Assets ライブラリ(Markdown) |
| 手順の作成/実行権限 | 既定は Edit で作成・View で実行 |
| 外部接続 | 不可。カスタムコードの実行も不可 |
KOIYALの見解
私たちは法人向けのAI研修とコンサルティングを行っていて、受講企業の課題は業種を問わずよく似ています。AIの使い方が分からないのではなく、自社の仕事の進め方が言葉になっていない。この一点です。
研修の現場で最も時間を使うのは、プロンプトの書き方ではありません。受講者に自分の担当業務の段取りを書き出してもらう時間です。書き出せた人は、その日のうちにCopilotから使える出力を引き出します。書き出せない人は、どれだけ良い例文を配っても再現できません。
今回のSharePointの手順は、この構造を製品として実装したものです。段取りを書き出し、保存し、他の人が呼び出せるようにする。Microsoftの記事にある繰り返す判断を書き留めるという表現は、私たちが研修で扱っている内容とほぼ同じことを指しています。裏返せば、この機能を使える会社と使えない会社の差は、ライセンスの有無ではなく、業務を言語化できるかどうかで決まります。
もう1つ、実務者として付け加えておきたいのは導入順です。この機能を活かすには、SharePointに信頼できる資料が揃っていて、権限が整理されている必要があります。共有ドライブが散らかったまま手順だけ作っても、出力の質は上がりません。先に情報の置き場と権限を整え、その上に手順を載せる。順番を逆にした会社は、たいてい半年後に作り直しています。
基盤の選び方についてもよく相談を受けます。私たちの答えは一貫していて、いま契約している基盤に付いているAIを使い切ることです。Microsoft 365ならCopilot、Google WorkspaceならGemini。Google側の同時期の動きはGoogle WorkspaceのAI新機能8つにまとめています。AIのために基盤を乗り換えると、移行コストが効果を食いつぶします。
最後に、5事例の読み方について。四半期あたり約4週間の削減は魅力的な数字ですが、これは財務部門が承認済み資料をSharePointに揃えていたから出た数字です。同じ手順を、資料が散らばった状態の会社に持ち込んでも再現しません。事例を読むときは、成果ではなく前提条件のほうを見てください。
次の行動
自社でこれを進める場合、状態によって次の一手が変わります。
業務の段取りを書き出すところから始めたい会社へ。KOIYALの法人向けAI研修では、CopilotとGeminiを題材に、AIを仕事に取り入れる考え方を扱います。6時間×2日間の全6コース(ビジネススキル・ビジネススキル応用・製造業・食料品製造業・建設業・DX)で、受講料は15万円/人(税抜)です。人材開発支援助成金の対象コースです。中小企業事業主が所定の要件を満たす場合の試算では、実質負担は29,250円/人になります。内訳は、経費助成率75%で123,750円、賃金助成1,000円/時間×12時間で12,000円の差し引きです(助成率と賃金助成額は企業規模で変わります)。今回の記事でいえば、ステップ2の「ベテランの手順を書き出す」を全社員ができる状態にするための投資です。
方針はあるが進める人がいない会社へ。FDE型支援(Do with you.)では、社外のAI・DX推進チームとして中に入ります。SharePointの情報整理・権限の棚卸し・手順の設計と実装・社内定着までを一緒に実行します。今回の記事のステップ1とステップ3は、社内の担当者だけで抱えると止まりやすい部分です。
何から手を付けるべきか判断したい会社へ。AI・DXコンサルティング(Design for you.)では、AI・既存のIT・SaaS・業務改善を同じ選択肢として比較して、進む道を設計します。Copilotの追加ライセンスを買う前に検討すべきことがある会社は少なくありません。
いずれの場合も、初回のご相談でうかがうのは3点です。現在使っているMicrosoft 365またはGoogle Workspaceのプラン、社内の情報の置き場、いま人手でやっている繰り返し業務。この3点を教えていただければ、その場で優先順位の見立てをお出しします。お問い合わせからご連絡ください。
追記: 2026年9月の更新
この記事の初稿は2026年9月6日時点の情報で書いています。その後、Microsoftは2026年9月にSharePointのページ編集にもAIの手伝いを入れると発表しました。ページの部品を選んで、2列にして、中央に寄せて、と言葉で指示すると、AIが下書きと手直しをする流れで、Copilot in SharePointが有効なテナントへ順次展開されます(確認日: 2026年9月24日。出典: SharePoint AI page authoring: select, describe, and refine)。
手順(skills)が答えの側の型なら、こちらは社内ポータルの見た目の側の型です。手順を配る場所であるSharePointのページ自体を、担当者しか触れない仕事から、指示すれば作れる仕事に変える動きとして、あわせて押さえておくと導入の説明がしやすくなります。
まとめ
- Copilotの成果が人によって割れるのは、前提を書ける人の前置きが、その人の頭にしか残らないため
- SharePointの手順(skills)は、その前置きをサイト上のMarkdownファイルとして保存し、社内で共有する仕組み。作成はチャットからの自然言語で行う
- Microsoftが公開した5事例に共通するのは、信頼できるコンテンツ・繰り返す業務・書き出した手順・人の最終判断・出典のたどりやすさの5つ
- 最初の1本は、作る価値・コンテンツ中心・再現可能な進め方の3問で選ぶ。一回きりの制作や発散的な検討には向かない
- 2026年9月6日時点でCopilot in SharePointはプレビュー。Microsoft Copilotライセンスが必要で、利用量の上限、対象外環境、対応言語の制約がある
- 効果を測るときは利用回数ではなく、時間・完了までの日数・手戻りを見る