SharePointとOneDriveのAI前提フォルダ設計

「OneDriveとSharePointの違いが分からない。とりあえず全部OneDriveに入れている」——中小企業のファイル管理で最も多い状態です。そしてAIを入れようとした瞬間に、この構成が壁になります。

結論から言うと、2つの違いは容量や機能ではなく「データが誰に紐づくか」です。OneDriveは人に紐づき、SharePointは組織に紐づきます。AIに社内資料を読ませたいなら、置き場所は組織側でなければ成り立ちません。

株式会社Fyveは中小企業のAI業務効率化を受託しており、AIを載せる前段のデータ整理から関わることが多くあります。この記事では、AIに読ませる前提でのフォルダ設計と権限設計を、Microsoftの公式ドキュメントで確認できる仕様を踏まえて整理します。

OneDriveとSharePointの違いは「誰に紐づくか」

機能の一覧を並べて比較しても、この2つの使い分けは決まりません。決めるべきは1点だけです。そのファイルは、その人がいなくなったら消えていいのか。

Microsoftのサポートページでは、使い分けをこう説明しています。OneDriveは「機密性の高い情報や個人情報を操作する場合など、自分だけのドキュメントを作成する場合に使用します」。SharePointは「チームによって作成および管理されるドキュメントを作成する必要がある場合、または広く共有する必要がある場合に使用します」。

言い換えると次の分担です。

• OneDrive——その人の作業領域。下書き、途中の資料、個人的なメモ、まだ人に見せる段階にないもの
• SharePoint——組織の資産。確定した資料、業務で参照し続けるもの、複数人が扱うもの

この分担で見ると、多くの会社の実態は「組織の資産が個人の作業領域に置かれている」状態です。見積書のテンプレート、価格表、業務マニュアル、顧客リスト。これらが誰かのOneDriveにあるなら、それは会社の資産が個人の引き出しに入っているのと同じ構造です。

「共有しているから大丈夫」ではない

「OneDriveから他の人にも共有しているので問題ない」という反論をよく受けます。しかし共有は所有を変えません。そのファイルの持ち主は、依然としてその個人アカウントです。

結果として、その人が退職したときにファイルの扱いが問題になります。OneDriveはアカウントに紐づくため、アカウントの扱いがそのままデータの扱いになります。保持期間や引き継ぎの挙動は設定によって変わるため、自社の設定は管理センターと公式ドキュメントで確認してください。

ここで言いたいのは期間の話ではなく構造の話です。組織の資産が個人アカウントに依存している限り、その資産は人の在籍という不安定な条件の上に載っています。

AIに読ませたいなら、置き場所は組織側でなければならない

Microsoft 365 Copilot のデータとプライバシーに関する公式ドキュメントには、こう明記されています。「Microsoft 365 Copilot は、個々のユーザーが少なくとも表示アクセス許可を持っている組織データのみを表示します。」

この一文から、置き場所の設計要件が3つ導かれます。

• クラウドに上がっていること——ローカルPCのフォルダは対象外
• その人に閲覧権限があること——権限がなければ、あっても見えない（これは正しい挙動）
• 組織データとして置かれていること——本人しか権限を持たない場所にある資料は、他の人のAIからは見えない

3番目が、OneDrive中心の運用が行き詰まる理由です。Aさんの作業領域にある資料は、Bさんが使うAIの参照範囲に入りません。会社としてAIを活用するなら、参照させたい資料は「会社の場所」にある必要があります。

公式ドキュメントもこの点を踏み込んで述べています。「SharePoint などの Microsoft 365 サービスで利用可能なアクセス許可モデルを使用して、適切なユーザーまたはグループが組織内の適切なコンテンツに適切にアクセスできるようにすることが重要です。」

Copilotが権限を尊重する設計であることは、セキュリティ上は望ましい仕様です。同時にそれは、権限設計の質が、そのままAIの使い勝手になるということでもあります。権限が雑なら、AIの回答も雑になります。

CopilotMicrosoft 365 Copilotとは｜仕組みと導入判断

フォルダ階層は浅くする——深さが探索を殺す

ここからは設計の話です。以下は公式の推奨事項ではなく、私たちが中小企業の環境を整えるときに使っている方針です。

階層を深くすると、人もAIも辿れなくなります。深い階層が生まれる原因はほぼ1つで、分類の軸を途中で増やしてしまうことです。

典型的な失敗はこうなります。「2026年 → 営業部 → 顧客A → 見積 → 改訂版 → 最終」。この構造は、作った人以外には辿れません。年度で切ったのか、部署で切ったのか、顧客で切ったのか、軸が5つ混在しています。

軸を1つに決めて、階層を3つで止める

私たちが提案する型は次のとおりです。

• 第1階層：業務の単位——「見積・請求」「顧客対応」「社内規程」「仕入」など。部署ではなく業務で切る
• 第2階層：対象または期間——顧客名、または年度。どちらかに決めて混ぜない
• 第3階層：必要なときだけ——ここまでで足りるなら作らない

部署で切らない理由は、部署が変わるたびに構造を作り直すことになるからです。業務は組織変更に耐えます。

階層を浅くすると、代わりにフォルダ内のファイル数が増えます。それは問題ありません。ファイル名が整っていれば、検索で辿れます。逆に階層が深いと、検索で見つかっても「なぜここにあるのか」が分からず、次に同じものを探せません。

ファイル名——AIが探し当てられる名前にする

フォルダ設計より効果が大きいのが、実はファイル名です。名前が整っていれば、階層が多少雑でも辿れます。

命名で決めるべきは3つだけです。

• 日付の形式を統一する——「YYYY-MM-DD」または「YYYYMM」に固定する。「2026年8月」「26/8」「8月」が混在すると並び順が壊れる
• 先頭を検索語にする——探すときに打つ言葉を先頭に置く。「見積書_○○様_2026-08」の順
• 版の表現を1つに決める——「最終」「最新」「確定」「fix」「v2」を混ぜない

3番目が最も重要です。「最終版_修正後_これで確定」というファイルが存在する会社では、どれが最新かを人間も判断できません。人間が判断できないものを、AIが判断できるはずがありません。

版が判断できないと、AIの回答が壊れる

ここが「AIを入れたのに的外れな回答が返る」の主要な原因です。同じ内容の資料が複数版あって、どれが有効か区別できない状態だと、AIは古い版を根拠に答えることがあります。

そして回答の見た目は、正しいときと変わりません。根拠が古いだけで、文章としては自然に読めます。これが危険です。公式ドキュメントにも「生成 AI によって生成される応答は、100% 事実であるという保証はありません」と明記されており、確認は使う側の責任として残ります。

対策は単純です。旧版を同じフォルダに置かない。「_archive」など決めた1か所に落とす。現役の版だけが同じ場所にある状態を作る。これだけで、AIの回答精度に対する体感は変わります。

権限設計——サイト単位・グループ単位で持つ

権限をファイル単位・フォルダ単位で細かく付けていくと、半年で誰も全体像を把握できなくなります。私たちの方針は次のとおりです。

• 権限はサイト単位で設計する——「このサイトを見られる人」を決める。フォルダごとに例外を作らない
• 個人ではなくグループに付ける——人事異動のたびに全フォルダを触る運用にしない
• 見せたくないものは、同じサイトに置かない——権限で隠すのではなく、場所で分ける

3番目が設計の要点です。「同じ場所に置いて権限で隠す」は、必ず事故ります。フォルダを移動した、リンクを共有した、といった日常操作で崩れます。見せる範囲が違うものは、最初から別のサイトに分ける方が壊れません。

公式ドキュメントが「適切なユーザーまたはグループが」と書いている点も、グループ単位で持つ設計と整合します。

サイトを分ける単位

中小企業なら、最初は次の3〜4つで足ります。

• 全社共有——全員が見てよいもの。規程、様式、社内案内
• 業務別——その業務に関わる人だけ。経理、営業、製造など。業務の数だけ作る
• 限定——人事・給与・契約など、役職者だけが見るもの
• 外部共有用——社外の人と共有する範囲。社内向けと混ぜない

最後の1つを最初から分けておくのが重要です。社内向けサイトの一部を外部に開ける運用にすると、境界が曖昧になります。外部連携の方式そのものは別記事で扱っています。

CopilotTeamsに外部パートナーを招待する3方式

TeamsのチャネルとSharePointサイトの対応を理解する

Teamsを使っている会社では、この対応関係を知らないまま構造が増えていきます。

Teamsのチームを作ると、それに対応する SharePoint サイトが作られます。チャネルはそのサイトの中のフォルダに対応します。つまりTeamsでチャネルを増やす行為は、SharePointのフォルダを増やす行為です。Teams側だけを見て増やしていると、SharePoint側の構造が意図せず育ちます。

共有チャネルは例外で、独自のSharePointサイトを持ちます。公式ドキュメントには「各共有チャネルには、独自の SharePoint サイトがあります」「個別のサイトは、共有チャネル ファイルへのアクセスが確実に共有チャネルのメンバーのみに制限されるようにするためにあります」と記載されています。

この仕様には運用上の注意が伴います。公式には次の点も明記されています。

• 「親チームと管理者の People は、チャネル メンバーでなければアクセスできません」
• 「共有チャネル サイトのサイト アクセス許可を SharePoint を通して個別に管理することはできません」

後者は、権限設計を SharePoint 側で統一したい場合の制約になります。共有チャネルの権限は Teams 側のメンバーシップで決まると理解しておく必要があります。

サイトを誰でも作れる状態を放置しない

公式ドキュメントには「既定では、ユーザーはコミュニケーション サイトと Microsoft 365 グループ接続チーム サイトを作成できます。IT またはビジネス プロセスを使用してこれを管理する場合は、これを制限できます」と記載されています。

誰でもチームとサイトを作れる状態のまま1年運用すると、似た名前のサイトが並び、どこに何があるか分からなくなります。作成を止める必要はありませんが、命名と用途のルールは先に決めておくのが実務的です。

なお公式は、階層の整理手段としてハブサイトにも触れており、「ハブ サイトを使用して、組織またはビジネス プロセスに一致する階層内のサイトを整理するのに役立ちます」と説明しています。サイトが増えてきた段階で検討対象になります。

移行の順番——全部を一度に上げない

設計が決まったら移行ですが、ここで多くの会社が「全ファイルの移行計画」を作り始めて止まります。順番はこうします。

• 1. 毎月必ず触る資料を1〜2種類選ぶ——請求、シフト、日報など。使用頻度が判断基準
• 2. その資料だけを新しい構造に置き直す——名前も新ルールに揃える。ここで構造の妥当性が検証される
• 3. 1か月運用して、詰まった箇所を直す——最初の構造は必ずどこか間違っている
• 4. 次の資料に広げる

この順番の価値は、構造を実務で検証してから広げられることです。全ファイルを移してから構造の誤りに気づくと、やり直しの量が現実的でなくなります。

移行の負荷について、公式ドキュメントには移行支援の特典についての記載があります。「FastTrack は、ご利用のサブスクリプションに付属する Microsoft のベネフィットです」とあり、オンボード・移行・導入のガイダンスが含まれると説明されています。対象範囲や条件は公式で確認してください。

もう1点、公式が挙げている実務上の注意があります。ネットワーク帯域です。「さまざまな要因が、SharePoint と OneDrive で使用されるネットワーク帯域幅の量に影響する可能性があります。最適なエクスペリエンスを得るには、ロールアウトを開始する前に、この影響を評価することをお勧めします」と記載されています。大量のファイルを一斉に同期すると、業務時間中の回線が詰まります。

置き場所を1秒で決める判定

設計が正しくても、日々の運用で「どっちに置くか」を迷えば崩れます。現場に渡す判定は、質問1つで済ませます。

「自分が明日辞めたら、このファイルは誰かが困るか」

• 困る——組織の資産。SharePointへ置く
• 困らない——個人の作業物。OneDriveでよい

この1問で、実務のほぼすべてが判定できます。「共有するかどうか」で判断させると、共有していない組織資産が個人領域に残り続けます。「困るか」で判断させると、共有の有無に関係なく組織資産を拾えます。

迷いが残る3ケースの扱い

• 作りかけの提案書——完成まではOneDrive、確定したらSharePoint。「確定＝移動」を工程に組み込む
• 個人的なメモだが業務知識が入っている——メモのままなら個人領域。ただし他の人にも必要な知識なら、業務手順として書き直して組織側へ。メモを移すのではなく、資料に昇格させる
• 取引先から受け取ったファイル——受け取った本人の領域に置かれがちだが、業務の記録なので組織側。ここを個人領域に置く習慣が、属人化の主要な入口になる

3番目は特に見落とされます。メールの添付をそのままデスクトップに保存し、そこで作業して終わる。この流れが続くと、取引の記録がすべて個人のPCに散ります。

共有リンクの散乱を止める

フォルダ設計を整えても、共有リンクの運用が雑だと権限設計が意味を失います。よく起きるのが次の流れです。

誰かが急いでファイルを渡すために共有リンクを作る。その相手が別の人に転送する。元のフォルダの権限とは無関係に、アクセスできる人が増える。そして誰がリンクを作ったか、記録が残らないまま時間が経ちます。

公式ドキュメントには、認証を求めないリンク（すべてのユーザー リンク）について「アクセスを監査することはできません」と明記されています。取り消す手段は、そのリンクを覚えている人が削除することだけです。

対策は2つで足ります。

• 既定のリンク種類を「特定のユーザー」寄りにする——共有時に相手の認証が要求される形を初期値にする
• 「渡す」より「置く」に誘導する——リンクを作って送るのではなく、決まった場所に置いて場所を伝える運用にする

2番目は文化の問題ですが、効果が大きいです。リンクを送る文化のままだと、フォルダ構造は誰も見に来ません。置き場所を伝える運用にすると、構造が使われ、構造の不備も早く見つかります。

やってはいけない3つの設計

1. 既存のフォルダ構造をそのまま持ち上げる

ファイルサーバーの構造をそのままコピーすると、深い階層と混在した軸もそのまま引き継ぎます。移行は構造を見直す唯一の機会です。そのまま上げるなら、AIに読ませる目的は達成できません。

2. 部署ごとにサイトを作って完結させる

部署単位でサイトを作ると、部署をまたぐ業務の資料が2か所に置かれます。すると版が分岐します。業務単位で切り、その業務に関わる人を部署をまたいで入れる方が壊れません。

3. 「とりあえず全員が全部見られる」から始める

権限設計を後回しにして全公開で始めると、後から絞るときに強い抵抗が起きます。「今まで見られていたものが見られなくなる」は、最も反発される変更です。最初から業務単位で区切っておく方が、結果的に摩擦が小さくなります。

よくある質問

OneDriveは使わない方がいいのですか

いいえ。個人の作業領域としては必要です。下書きや途中の資料はOneDriveで問題ありません。問題は、組織の資産がそこに置かれ続けることです。確定したら組織側に移すという運びを決めておけば、両方を使い分けられます。

デスクトップに置いているファイルはどうすればいいですか

OneDriveには「既知のフォルダー移動（フォルダーバックアップ）」という機能があり、デスクトップ・ドキュメント・画像といったフォルダをOneDriveにリダイレクトできます。公式には、ユーザーが使い慣れたフォルダーを使い続けながらクラウドにバックアップされ、任意のデバイスからアクセスできるようになる利点が説明されています。macOSではデスクトップとドキュメントが対象として案内されています。対応フォルダーと設定手順は最新の公式ドキュメントで確認してください。

ただしこれは個人領域へのバックアップです。組織で共有すべき資料は、これとは別にSharePointへ置き直す必要があります。

フォルダの数はどれくらいが適切ですか

数の正解はありませんが、判断基準はあります。入社3か月の人が、説明なしに正しいフォルダにファイルを置けるか。置けないなら、分類が細かすぎるか、軸が混ざっています。

ファイル名のルールを決めても守られません

ルールを文書で配っても守られません。効くのは、フォルダの中に「正しい名前の実例」が並んでいることです。最初の10件を正しい名前で作っておくと、後から入れる人はそれに揃えます。ルール文書より実例の方が強く働きます。

権限を細かく設定したい要望が現場から出ます

その要望はたいてい「見せたくないものが混ざっている」ことの裏返しです。権限で隠すのではなく、置き場所を分けて解決できないか先に検討してください。場所で分けた方が、後から見直せます。

整理してからAIを入れるべきか、並行でよいですか

並行で構いません。ただし順序は「読ませたい資料の整理」が先です。整理されていない状態で読ませて期待外れの結果になると、AIそのものの評価が下がり、次の投資判断が難しくなります。1業務分だけ整えて、そこで試すのが現実的です。

AIに読ませたくない資料はどう扱いますか

Copilotは本人の閲覧権限に従うため、その人に権限がなければ参照されません。加えて公式ドキュメントには、秘密度ラベルによる暗号化について「Microsoft 365 Copilot はユーザーに付与された使用権を尊重します」との記載があります。ラベルや暗号化の運用は自社の要件に応じて公式情報で確認してください。

まとめ

AI前提のフォルダ設計の要点を整理します。

• OneDriveは人に紐づき、SharePointは組織に紐づく——組織の資産を個人領域に置かない
• Copilotは本人が閲覧権限を持つ組織データしか見ない——公式明記。置き場所と権限がそのまま参照範囲になる
• 階層は軸を1つに決めて3つで止める——部署ではなく業務で切る
• ファイル名の方が効果が大きい——日付形式・先頭の検索語・版の表現を統一する
• 旧版を同じ場所に置かない——人間が判断できない版の混在は、AIの回答を静かに壊す
• 権限はサイト単位・グループ単位——見せたくないものは権限で隠さず場所で分ける
• 移行は1業務ずつ——構造を実務で検証してから広げる

フォルダ設計は、AIのための特別な作業ではありません。人が探せる状態を作ることが、そのままAIが読める状態になるという関係です。逆に言えば、AIを入れるという話は、いままで放置してきた整理に着手する口実として使えます。私たちが関わる案件でも、成果が出るのはたいてい整理の側からです。