「onedrive sharepoint 違い」は理解したつもりなのに、現場では保存先がバラバラ、退職者のOneDriveから重要ファイルが見つかる、Teamsの裏側のSharePoint構造を誰も説明できない。こうなっているなら、すでに静かな損失が始まっています。
本記事は「個人ロッカーと共有キャビネット」の例えでOneDriveとSharePointとTeamsの関係性を一枚の地図に落とし込み、「どのファイルをどこに置くか」まで迷わないレベルに整理します。
さらに、全部OneDriveや全部Teamsに寄せた結果起きる退職者問題、SharePoint→OneDriveコピー連発による最新版崩壊、SharePoint OneDrive 同期とショートカットの設計ミスでPCがパンクするケースを、実務の因果関係として解体します。
そのうえで、OneDriveとSharePoint Onlineの保存先フローチャート、Teams/SharePoint/OneDriveの使い分け、同期ボタンがない時に設計側が見るポイント、外部共有の線引き、容量とアーカイブ戦略、やってはいけない権限設計までを一気通貫で示します。
読み終えるころには、「うちの会社ではこう使う」と言い切れる社内ルール案と、情シスや部門ITリーダーが上司や現場に説明するための台本が手元に残ります。
目次
いまさら聞けないonedrivesharepoint違いとTeamsとの関係を「一枚の地図」で整理する
「どこに保存すれば正解か分からない…」と社内から問い合わせが増え始めたら、それは設計を見直す合図です。ここではまず、全体像を一枚の“地図”として整理します。
onedrivesharepoint違いとSharePointとTeamsは何者か?関係性を人間関係になぞらえて理解する
3つのサービスを人間関係で例えると、次のようになります。
-
OneDrive=自分の机と引き出し(個人の作業スペース)
-
SharePoint=部門ごとの共有キャビネット(チームや部署の公式置き場)
-
Teams=会議室+チャットツール(会話の窓口であり、裏でSharePointを使う顔役)
私の視点で言いますと、運用が崩れる現場の多くは「Teamsさえ使っていればどこに保存されているか気にしなくてよい」と思い込んでいるケースです。実際には、Teamsのファイルタブの裏側ではSharePointサイトが自動作成され、チャット添付はOneDriveに置かれています。この“二重構造”を理解していないと、退職や組織変更のタイミングで「どこに本体があるのか誰も説明できない」状態に陥ります。
onedrivesharepoint違いをわかりやすく整理するための「個人ロッカーと共有キャビネット」の例え
よくある「個人用と共有用」という説明を、もう一歩だけ具体化します。
| 役割 | OneDrive | SharePoint |
|---|---|---|
| イメージ | 個人ロッカー | 共有キャビネット |
| 主な利用者 | 個人 | チーム・部署・全社 |
| 想定寿命 | 人に紐づく(退職で消えるリスク) | 組織に紐づく(部署が続く限り存続) |
| 得意な用途 | 下書き・個人メモ・一時的な共有 | 版管理・承認フロー・ナレッジ共有 |
ポイントは「寿命」と「責任の所在」です。個人ロッカーに社内で唯一のマニュアルを入れておくと、その人が鍵を返した瞬間に行方不明になります。これが、導入数年後に表面化する退職者の個人領域だけに重要ファイルがあった問題です。
逆に、共有キャビネットに何でも入れると、誰の責任で整理するかが曖昧になり「最新版がどれか分からないフォルダ地獄」が起きやすくなります。個人作業はロッカー、正式版はキャビネットという線引きを、情シス側から明文化してあげることが重要です。
office365やM365全体で見たときのonedrivesharepoint違いやTeamsの役割分担
M365全体の中で3つを俯瞰すると、次のような役割分担になります。
-
OneDrive
- WordやExcelの「上書き保存」の初期保存先になりやすい
- チャットで送ったファイルの保存先にもなる(送信者の領域)
- 外部共有は「個人責任」色が強く、ガバナンス上のリスクも高い
-
SharePoint Online
- TeamsのチームやMicrosoft 365グループの裏側ストレージ
- 権限グループと情報分類ラベルを組み合わせて、社外プロジェクトや部署間共有をコントロール
- バージョン管理やワークフロー、メタデータ管理など“情報資産”としての運用が前提
-
Teams
- 「会話」「会議」「ファイル」を一画面に集約するフロントエンド
- 実体はSharePointやOneDrive、Exchangeなど複数サービスの入り口
- チャネルごとにSharePointのドキュメントライブラリやフォルダが紐づき、チーム構造がそのままサイト構造に影響する
ここで押さえたいのは、ファイルの実体はあくまでOneDriveかSharePointにあるという点です。Teamsは入り口にすぎません。導入初期はTeamsだけを見ていても何とかなりますが、1〜3年経った頃に「どのチームの裏がどのSharePointサイトか」「退職者のチャット添付ファイルはどこにあるか」が説明できず、情シスが慌てて棚卸しに追われるケースが実際に起きています。
この“時間差爆発”を避けるには、今のうちから地図を描いておくことが欠かせません。次の章では、その地図を無効化してしまう「全部OneDrive」「全部Teams」運用が、なぜ危険なのかを具体的な落とし穴から掘り下げていきます。
なぜ「全部OneDrive」や「全部Teams」が危ないのか?現場で本当に起きている落とし穴
「とりあえず全部OneDriveに」「会議もファイルも全部Teamsで」
導入直後は楽に見えるこの判断が、2~3年後に情シスの首を締めるパターンを何度も見てきました。ここでは、表面の機能差ではなく、時間差で爆発する落とし穴に絞って整理します。
退職者によるonedrivesharepoint違いの重要ファイル問題と、気づくのが1〜3年後になりがちな理由
全部OneDrive運用で一番怖いのは、退職と同時に業務の「証拠」と「履歴」が消えることです。
ざっくり整理すると、退職時のリスクは次の3つに集約されます。
| 状況 | 何が起きるか | なぜ気付きにくいか |
|---|---|---|
| 重要ファイルが個人領域にだけ保存 | 見積・設計書・議事録が共有サイトに残っていない | 退職までは本人が対応しているため問題化しない |
| 業務プロセスが個人フォルダ依存 | どのフォルダを見れば良いか本人しか把握していない | 引き継ぎシートに書ききれない暗黙知になりやすい |
| 退職後にアカウント削除 | OneDriveごと削除され証跡が消える | 削除の数カ月後に「過去の契約書がない」と発覚しがち |
「社内の正式な成果物はSharePointのチームサイトに」「個人のメモやドラフトはOneDriveに」という線引きをしないまま数年経つと、会社としてのナレッジが個人フォルダにばらけた状態で退職ラッシュを迎えることになります。
退職者対応の相談を受けることが多い私の視点で言いますと、導入1年目は「便利になった」で終わり、2~3年目に人の出入りが増えたところで初めて「やばい、どこにも最終版がない」と露呈するケースが目立ちます。
防ぐための最低ラインは次のようなルールです。
-
契約書・見積・仕様書・マニュアルは必ず対象チームのSharePointに保存
-
OneDrive上の重要ファイルは「移動」してSharePointに寄せる
-
退職フローに「OneDrive内の業務データ棚卸しチェック」を必ず入れる
「Teamsの裏にあるSharePoint」を意識しなかったことで、サイト構造が誰にも説明できなくなるパターン
Teamsを立てると、自動的に裏側にSharePointサイトが作成されます。ここを意識せずに「とりあえずチームを量産」すると、数年後に次のような地獄絵図になります。
-
プロジェクトごとにチームを乱立
-
部門異動のたびに新チームを作成
-
一時的なやり取りにも新チームを作成
その結果、SharePoint側には「誰も覚えていないサイト」が山のように積み上がります。管理センターで一覧を見ると、似た名前のサイトが何十個もあるのに、どれが本番でどれが終わった案件か分からないという状態です。
ここでよく起きる問題は次の通りです。
-
Teamsの一覧からは消えているのに、SharePointサイト単体は生きている
-
オーナーが退職しており、権限設計も不明
-
容量だけ食い続けている「ゾンビサイト」が大量発生
これを防ぐには、Teams作成ポリシーと命名規則が必須です。
-
チーム作成を誰でも自由にではなく、部門代表か情シス承認制にする
-
チーム名に「部門-目的-開始年」を含める (例: 営業-顧客案件A-2024)
-
プロジェクト終了時には「アーカイブ済」ラベルを付けて読み取り専用にする
SharePointからonedrivesharepoint違いによるコピー連発で「最新版がどこか分からない」案件が量産される流れ
もう1つの典型的な落とし穴が、「コピー運用」によるファイルの二重管理です。SharePointで管理しているファイルを、個人で編集したいからといってOneDriveにコピーするパターンが代表例です。
流れを時系列で見ると問題点がはっきりします。
- チームサイトのドキュメントライブラリから、ファイルをOneDriveにコピー
- コピー側で編集し、そのまま使い続ける
- 元のSharePoint側も別メンバーが更新
- しばらくして「どっちが最新版?」と混乱
- 誤った版を取引先に送ってクレーム
コピーを多用すると、同じファイル名の別バージョンが組織中にばらまかれることになり、検索システムが優秀でも人間の判断は追いつきません。
現場で現実的なのは、次のような使い分けです。
-
一時的なドラフトはOneDriveで作成し、レビューに乗せるタイミングでSharePointへ「移動」
-
チームで扱うファイルは最初からSharePointに置き、個人用は「自分用ビュー」やメタデータで切り分け
-
共有が必要なときは「コピー」ではなく、SharePointのリンク共有を使う
特にOneDriveへのコピーは、退職時に元データが行方不明になる原因にも直結します。コピーではなくリンクを配る文化をどこまで根付かせられるかが、情シスにとっての勝負どころになります。
onedriveとsharepointの違いを社内ルールに落とす「保存先フローチャート」の考え方
導入直後の現場で一番事故を生むのは「機能不足」ではなく「保存先ルールがない状態」です。ここでは、情シスや部門リーダーがそのまま社内説明に使えるレベルまで、保存先の考え方を整理します。
私の視点で言いますと、最初に決めるべきなのは「どの種類のファイルを、どの場所に置くか」を3レベルで割り切ることです。
個人ドラフトとチーム共有と全社ナレッジをどう分けるか(onedriveとsharepoint違いの保存先具体例)
まずは「誰のためのファイルか」で切り分けます。
| 種類 | 代表的な用途 | 保存先の推奨 | ポイント |
|---|---|---|---|
| 個人ドラフト | 下書き、メモ、評価前の資料 | OneDrive | 原則「自分だけが編集」する段階 |
| チーム共有 | プロジェクト資料、部門共有 | Teams経由のSharePoint | 担当メンバー全員が編集・閲覧 |
| 全社ナレッジ | マニュアル、規程、FAQ | 部門/全社ポータルのSharePointサイト | 原則参照のみ、権限は厳しめ |
具体例をいくつか挙げます。
-
評価途中の提案書やアイデアメモ
→ OneDriveに保存し、レビューが始まったらチームのSharePointに「移動」
-
部門定例会の議事録
→ 最初からTeamsのチャネルに保存(裏側はSharePoint)し、担当者以外も編集可能にする
-
経理のマニュアルや就業規則
→ 経理部門や総務部門のSharePointサイトに集約し、OneDriveには置かない
この「下書きはOneDrive、動き出したらSharePoint、決着したらナレッジ用サイト」という3ステップを徹底しておくと、退職者のOneDriveにだけ重要ファイルが残るパターンをかなり抑えられます。
SharePointOnlineやOneDriveの保存先で迷うグレーゾーンをどう裁くか(社外共有や一時的コラボなど)
問題は、「一時的だが重要」「社外も絡む」といったグレーゾーンです。ここで迷うとファイルサーバ時代よりカオスになります。
おすすめは、次のようなルールを紙に書いてしまうことです。
-
社外と継続的にコラボする案件
→ 専用のMicrosoft Teamsチームを作成
→ 裏側のSharePointサイトにファイルを集約
→ 社外メンバーはゲストユーザーで招待し、OneDriveでの直接共有は禁止 -
一度きりのやり取り(見積書・申込書の受け渡し程度)
→ 担当者のOneDriveから「特定のユーザー共有」で送付
→ 完了後はチームのSharePointに移動し、OneDrive上の元ファイルは削除 -
社外共有が禁止されている部署(経理、人事など)
→ OneDriveもSharePointも外部共有をポリシーでブロック
→ 社外への送付は別途承認フローや専用サービスで対応
このように、「期間」と「関わる相手」で保存先と共有方法を切り分けておくと、OneDrive外部共有の事故やリンク拡散を最小限にできます。
TeamsやSharePointやOneDrive関係性を前提にした「チャットとチャネルとサイト」の使い分け
ファイルの迷子を防ぐには、「どこから作ったファイルか」を意識させることが重要です。
-
Teamsのチャット(1対1・少人数)
- 短期的なやり取りが中心
- 添付ファイルの保存先はOneDriveになりやすい
- 長期保管したい資料は、そのまま放置せずチャネルに移すルールを明文化
-
Teamsのチャネル(プロジェクト・部門単位)
- 投稿に添付したファイルは、そのチーム専用のSharePointに保存
- 「プロジェクトの公式な成果物」は必ずチャネルに紐づくSharePointに置く、と教える
-
SharePointサイト(ポータルや部門サイト)
- Teamsに紐づくサイトとは別に、「全社ポータル」「部門ポータル」として設計
- 規程やマニュアルなど、期日やバージョン管理が必要な文書を集中管理
よくある失敗は、「全部Teamsで作れば整理されるはず」と考えて、案件のたびにチームを量産するパターンです。数年後に「どのチームに何のSharePointがぶら下がっているのか誰も説明できない」という状況になりがちです。
そのため、情シス側では次のような簡易フローチャートを作っておくと運用が安定します。
-
日常業務・部門内の定型仕事 → 既存の部門TeamsとSharePointに保存
-
時限付きプロジェクト(半年〜数年) → プロジェクト用Teamsを新設し、終了時にSharePointでアーカイブ
-
全社向け情報 → 専用のSharePointポータルにのみ配置し、Teamsからはタブで参照するだけ
この「どこからファイルを作るか」「どの単位でTeamsやSharePointサイトを増やすか」を最初に決めておくかどうかで、3年後の運用コストが大きく変わります。現場ではここをあいまいにした結果、後から棚卸しプロジェクトに多大な時間を取られるケースが少なくありません。
OneDriveやSharePoint同期とショートカットの違いを知らないとPCがパンクする話
「とりあえず全部同期」で始めた結果、半年後にPC容量が真っ赤になり情シスにヘルプ、というケースは珍しくありません。同期とショートカットの違いをきちんと押さえておかないと、ファイルサーバ移行後の“静かな爆弾”になります。
SharePointやOneDriveの同期とSharePointへのショートカット追加は何が違うのかを実務目線で噛み砕く
同期とショートカットは、見た目はどちらもエクスプローラーにフォルダが出てきますが、中身はまったく別物です。
| 項目 | 同期(Sync) | ショートカット追加 |
|---|---|---|
| 実体 | ファイルをPCにダウンロード | クラウド上の場所へのリンク |
| 容量 | PCのディスクを消費 | ほぼゼロ |
| オフライン利用 | 可能(必要に応じて) | 原則不可(オンライン前提) |
| 更新の仕組み | OneDriveクライアントが双方向同期 | 毎回クラウドに直接アクセス |
| 想定用途 | 少数メンバーで頻繁に編集する業務 | 参照中心・大容量ライブラリ |
同期は「ローカルコピーを持つ」ことなので、数十GBクラスのSharePointライブラリを丸ごと同期すると、PCのSSDが一気に圧迫されます。ショートカット追加は「そこへの近道を作る」だけなので、容量リスクをほぼゼロに抑えられます。
私の視点で言いますと、標準はショートカット、例外的に同期と決めるだけで、PCパンク案件はほぼ止まります。
「同期ボタンがない」「同期できない」「同期が遅い」と言われたときに設計側がまず見るポイント
現場からよく上がる3大問い合わせと、設計側がチェックすべき順番を整理します。
-
「同期ボタンがない」と言われたら
- サイトコレクションやライブラリ単位で、管理者が同期機能を制限していないか
- ブラウザが古い、もしくはOneDriveクライアントと紐付くアカウントが違っていないか
-
「同期できない」と言われたら
- すでに別パスで同じライブラリを同期していないか
- パス長(フォルダ名+ファイル名)がOSの制限を超えていないか
- OneDriveクライアントが会社アカウントで正常サインインしているか
-
「同期が遅い」と言われたら
- 初回同期で数万ファイルを落とそうとしていないか
- ネットワーク帯域制限や、ウイルス対策ソフトのリアルタイムスキャン設定
- 「必要なファイルのみオンライン保持(ファイルオンデマンド)」が有効か
ここで大事なのは、「壊れている」のではなく「意図的に絞っている」ケースが多いという視点です。特に同期ボタン非表示は、ガバナンス目的で情シスが止めている場合があり、安易に「出してあげましょう」とは言えません。
SharePointフォルダをエクスプローラーで開く運用と「全部同期しない」ための現実的ルール
同期に頼らず、エクスプローラーからストレスなくSharePointを扱うためには、次の組み合わせが現実的です。
-
基本方針
- 大容量ライブラリは同期禁止、ショートカットのみ許可
- チームの「よく使う」サブフォルダだけを、限定的に同期を許可
- エクスプローラーからのアクセスは「ショートカット+ファイルオンデマンド」を前提にする
-
ユーザー向けルールサンプル
- 日々編集するプロジェクト資料 → 小さめライブラリを同期
- 過去案件や全社共有ドキュメント → ショートカットで参照のみ
- 「PCの空き容量が50GBを切ったら、同期対象を棚卸しする」
| シナリオ | 推奨手段 | ポイント |
|---|---|---|
| 毎日更新する少人数プロジェクト | 同期+ファイルオンデマンド | オフライン編集も想定 |
| 部門共有のナレッジ庫 | ショートカットのみ | 容量肥大を確実に防ぐ |
| 数年分のアーカイブ | ブラウザアクセス中心 | 検索とメタデータを活用 |
「エクスプローラーで見えないと不安」という声も出がちですが、全部同期してPCを詰ませてからルールを引き直す方がはるかにコスト高になります。最初から「どこまでローカルに置くか」の線引きを設計し、ユーザー説明用の図解やマニュアルまでセットで用意しておくことが、3年後のトラブル削減につながります。
onedrivesharepoint違いやファイル共有と社外共有の線引きはどこまで許してどこを禁止するか
社内で一度でも社外共有を解禁すると、気づかないうちに「どこまでOKなのか」が人によってバラバラになりがちです。ここをあいまいにしたまま運用すると、1〜3年後に情報漏えいや契約トラブルの火種になります。鍵は、OneDriveとSharePointで「誰と・どの期間・どのレベルで」共有してよいかを切り分けることです。
OneDrive外部共有禁止に踏み切る前に押さえる「特定のユーザー共有」と「リンク共有」の違い
OneDriveの社外共有には、大きく2つのやり方があります。この違いを押さえずに「全面禁止」にすると、現場は結局メール添付に逆戻りします。
| 項目 | 特定のユーザー共有 | リンク共有(組織外を許可) |
|---|---|---|
| 相手の特定 | メールアドレスを個別指定 | URLを知っていればアクセス可能な場合がある |
| 管理のしやすさ | 共有先を一覧で確認しやすい | 「誰に渡ったか」を追いにくい |
| 向いている用途 | 個別の取引先・士業とのやりとり | 公開資料、カタログなど広く見せたい情報 |
情シス視点では、原則は特定のユーザー共有のみ許可し、リンク共有は「全社で数パターン」に限定したサイトからだけ許可という設計が現実的です。OneDrive外部共有を完全禁止するのは、「退職時にOneDriveを即時削除する方針」とセットでないと、現場が回らないケースが多いと感じます。
SharePointファイル共有社外で抑えたいアクセス権限と有効期限と監査ログのイメージ
社外プロジェクトや長期の取引では、SharePoint側で社外共有を設計した方が、安全性と見通しの良さが段違いになります。ポイントは3つだけです。
-
アクセス権限
- 原則は「閲覧のみ」からスタートし、「編集はプロジェクトメンバーに限定」
- フォルダ単位で権限を細かく切るより、「外部向けドキュメント専用ライブラリ」を1つ作る方が管理しやすいです。
-
有効期限
- 「外部リンクは90日で自動失効」「プロジェクト完了から半年でゲスト権限を棚卸し」など、日付ベースのルールを決めておきます。
-
監査ログ
- すべてを詳細に追うのではなく、「社外からの大量ダウンロード」「深夜帯のアクセス増加」だけを見ると決めておくと運用負荷を抑えられます。
社外共有をSharePointに寄せておくと、「どのサイトから、どのドキュメントが外に出ているか」が管理者画面から俯瞰しやすく、ファイルサーバ時代の「誰がUSBで持ち出したか分からない」状態から抜け出しやすくなります。
TeamsからSharePointを開く社外プロジェクトやゲストユーザー運用のよくあるつまずき
Teamsにゲストユーザーを招いてやりとりを始めると、「チャットは盛り上がるが、ファイルが迷子になる」状態がよく起きます。私の視点で言いますと、つまずきポイントは次の3つに集約されます。
-
Teamsのどのチャネルに何を置くかを決めていない
- 決め事がないと、標準チャネルとプライベートチャネルと個人チャットに同じファイルがバラまかれます。
- ルール例として「公式成果物は“ファイル”タブ配下のSharePointのみ」「チャット添付はドラフト限定」としておくと整理しやすくなります。
-
ゲスト権限が過剰
- 「メンバーと同じ編集権限」でゲストを入れると、フォルダ削除や構成変更のリスクが一気に上がります。
- 外部は「閲覧中心+アップロード専用フォルダだけ編集可」に抑えておくのが無難です。
-
プロジェクト終了後の片付けが決まっていない
| タイミング | やることの例 |
|---|---|
| プロジェクト完了時 | ゲストユーザーのアクセス停止、Teamsチームの所有者確認 |
| 数カ月後 | SharePointサイトのアーカイブ場所へ移動、不要なチャネルやタブの削除 |
| 年次棚卸し | 外部共有リンクとゲストアカウントの一括見直し |
Teamsで気軽に社外ユーザーを招けるようになった反面、「SharePointのどのサイトに、どんな権限で乗ってきているか」を把握している人が社内に1人もいない、という状態が珍しくありません。社外共有の線引きは、OneDriveとSharePointの違いを踏まえたうえで、「OneDriveは一時的で個人寄り」「SharePointはプロジェクト単位で設計し、Teamsから入口を用意する」という二段構えにしておくと、後からの手戻りが激減します。
容量や寿命を読み間違えないためのonedriveとsharepointの違いに沿った容量設計とアーカイブ戦略
「容量はまだ余っているし、細かい設計は後でいいや」と判断した組織ほど、3年後に容量超過とファイル行方不明で身動きが取れなくなります。ストレージは数字ではなく、寿命と片付け方まで含めた設計がないと必ず破綻します。
私の視点で言いますと、容量設計は次の3ステップで押さえると迷いにくくなります。
1 保存フェーズとアーカイブフェーズを分けて考える
2 個人領域とチーム領域の役割を数値とルールで決める
3 使っていないサイトを早めに棚卸しする
onedriveとsharepointの違いによる容量の数字だけで判断すると失敗するワナ
同じ1TBでも、個人の一時保管に使うのか、部門の長期保管に使うのかで、寿命はまったく変わります。よくある失敗は次の通りです。
-
個人のonedriveにだけドラフトではなく正式版まで貯め込み、退職時にまとめて削除される
-
sharepointのドキュメントライブラリをファイルサーバ代わりにし、版管理とアーカイブを分けずに延々と積み上げる
容量を読む時は「誰の領域に、どのくらいの期間置くか」をセットで見ます。ざっくりの目安は次のイメージです。
| 領域 | 主な用途 | 想定期間 | 設計のポイント |
|---|---|---|---|
| onedrive | 個人ドラフト、一時共有 | 数カ月〜1年程度 | 退職時の移管フローを必ず作る |
| チーム用sharepointサイト | プロジェクト、部門共有 | 1〜5年 | 終了時にアーカイブ先を決めておく |
| 全社ポータル用sharepoint | 規程やマニュアル | 恒久 | 定期的に棚卸しと改訂サイクルを回す |
数字だけでなく、この「想定期間」が決まっていないと、どこから掃除してよいか誰も判断できなくなります。
SharePoint容量追加料金を払う前に見直すべき使われていないチームとサイト
容量が逼迫してくると、追加購入より先に死んでいるサイトを捨てる方がコストインパクトは大きくなります。現場でまず見るべきポイントは、次の3つです。
-
最終アクセスから1年以上経っているTeamsチームとsharepointサイト
-
所属メンバーが誰も分からない「謎のプロジェクト名」のサイト
-
ライブラリのほとんどがZIPや巨大なバックアップファイルで占められているケース
棚卸しでは、次のようなシンプルな観点で判定すると進みやすくなります。
-
まだ業務で使うか
-
法令や契約で保存義務があるか
-
保存義務はあるが、参照頻度は低いか
「参照頻度は低いが残す必要がある」データを、後述のアーカイブ用ライブラリに移すだけでも、現役チームのsharepoint容量はかなりスリムになります。
プロジェクト終了後のアーカイブをSharePointOnlineやOneDriveのどちらに置くかという悩みの解き方
プロジェクト終了後、「成果物をどこに寝かせるか」で多くの組織が迷います。ポイントは、誰が将来そのファイルを探しに来るのかを具体的にイメージすることです。
-
将来参照するのが特定の担当者だけ
- onedriveに置きたくなりますが、退職時に消えるリスクが高く、組織の資産としては不適切です
-
将来参照する可能性が部門全体や後任にもある
- 部門単位のsharepointアーカイブサイトに移した方が検索性と継続性が保てます
アーカイブ先の判断軸を整理すると、次のようになります。
| 条件 | 推奨アーカイブ先 |
|---|---|
| 組織の公式ドキュメントとして残す | 部門または全社のsharepointサイト |
| 一担当者のメモレベル、他者参照は稀 | onedriveだが、退職時移管ルール必須 |
| 法的・契約的に長期保管が必要 | retentionルールを設定したsharepointアーカイブサイト |
プロジェクトのキックオフ時に「終了後はどのアーカイブサイトへ移すか」「どの単位のフォルダを移動するか」まで決めておくと、終了時の作業は移動と権限の見直しだけになります。これがあるかないかで、3年後のストレージの健康状態は大きく変わります。
情シスや部門ITリーダーが必ず知っておきたい「やってはいけない設計」と最低限の標準ルール
「とりあえず使えるようにしておいて」は、数年後に必ずツケが回ってきます。ここでは、現場で何度も見てきた“やってはいけない設計”と、それを避けるための現実的なルールを整理します。
「直接ユーザーに権限付与」や「全員フルコントロール」を続けると何が起きるか
SharePointとOneDriveとTeamsで最初に崩れるのは、ほぼ権限設計です。
悪いパターンを整理すると、次のようになります。
| よくあるNG運用 | 短期的に起きること | 数年後に起きること |
|---|---|---|
| ユーザー個人に直接権限付与 | 「あの人だけ見える/見えない」問い合わせ増加 | 誰がどこにアクセスできるか誰も説明できなくなる |
| チーム全員をフルコントロール | 意図せずフォルダ削除や権限変更が発生 | 重要なファイル消失、監査対応で致命傷 |
| 外部共有を個人判断に丸投げ | OneDriveから安易なリンク共有が乱発 | 退職者の個人領域から情報流出リスクが残り続ける |
最低限押さえたいポイントは3つです。
-
権限は「Microsoft 365グループ」や「セキュリティグループ」に集約し、個人付与を極力しない
-
「閲覧」「編集」「所有者(フルコントロール)」の3階層を明確に分け、所有者を絞る
-
OneDriveでの社外共有は原則禁止か、特定部署だけに限定し、外部共有はSharePointの専用サイトで行う
退職者OneDriveにだけ重要ファイルがあったケースでは、そもそも共有サイト側の権限設計が甘く、「面倒だから個人領域で共有」が常態化していたことが多いです。
Teamsやonedriveとsharepointの違いを踏まえた、現実的な命名規則とサイト構造の決め方
名称と構造がカオスになると、検索システムよりも「誰がどこに置いたか」を人に聞く文化が残り、クラウドのメリットが消えます。現実的なルール例を示します。
推奨する命名の軸
-
軸1: 組織(部門・拠点)
-
軸2: 業務カテゴリ(営業、開発、総務など)
-
軸3: 目的(プロジェクト、ナレッジ、アーカイブ)
| 種別 | 例 | 保存の主目的 |
|---|---|---|
| Teamsチーム名 | SALES_東日本_案件 | 部門別の案件コラボ |
| SharePointサイト | SALES_全社ナレッジ | マニュアル・テンプレート共有 |
| OneDrive | 氏名_YYYY | 個人ドラフト・一時保管 |
ポイントは、Teamsで作るチームと裏側のSharePointサイトを「1対1」で意識しつつ、全社ナレッジ用のSharePointサイトはTeamsと切り離しておくことです。全部Teamsで作ると、数年後に「どのチームのどのタブに何があるか」を誰も追えなくなります。
情報分類(機密度や公開範囲や保存期間)からonedriveとsharepointやTeams保存先をマッピングする手順
保存先ルールを腹落ちさせるには、「どのサービスを使うか」より前に、「情報の種類」を決め打ちする方が早道です。私の視点で言いますと、次の3軸で分類すると社内説明がしやすくなります。
- 機密度(公開/社内限定/部署限定/機密)
- 公開範囲(個人/チーム/全社/社外含む)
- 保存期間(短期/中期/長期・保管義務有無)
この3軸から、保存先をマッピングするイメージです。
| 情報のタイプ | 機密度 | 公開範囲 | 期間 | 推奨保存先 |
|---|---|---|---|---|
| 個人が作成中のドラフト | 中 | 個人 | 短期 | OneDrive |
| 部署内で共同編集する資料 | 中 | チーム | 中期 | Teamsのチーム→裏側のSharePoint |
| 全社マニュアル・規程 | 高くない | 全社 | 長期 | 全社ポータル用SharePointサイト |
| 社外メンバーと共同作業する資料 | 中〜高 | チーム+社外 | プロジェクト期間 | 専用プロジェクトサイト(SharePoint)+Teamsゲスト |
この表をもとに、「迷ったらここに置く」というフローチャートを1枚作り、情シスが研修や問い合わせ回答で使い回せるようにしておくと、ファイルサーバ移行後の混乱をかなり抑えられます。権限と命名と情報分類、この3点を最初に固めておくことが、数年後の“地獄の棚卸し作業”を避ける一番の近道になります。
よくある勘違いQ&Aで総まとめ!onedriveとsharepointの違いは同じですか?なぜSharePointを使うべき?
「どっちもクラウドストレージでしょ?」で片付けると、3年後に退職者のアカウント削除で社内が凍りつきます。このゾッとする未来を避けるために、情シスが現場にどう説明すべきかを整理します。
「onedriveとsharepointの違いは同じですか?」に情シスがどう答えると腹落ちしてもらえるか
現場に一番刺さるのは、仕様の説明ではなく仕事の流れでの違いです。
よく使う説明パターン
| 質問する人の頭の中 | 情シスが返すと刺さる答え方 |
|---|---|
| どっちもクラウドの保存場所では? | 用途が違います。OneDriveは「個人の作業机」、SharePointは「部署のキャビネット」です。 |
| じゃあ全部OneDriveで共有すれば? | 机の上に契約書を山積みして、本人が休んだら誰も触れない状態になりますよ。 |
押さえたいポイントは3つです。
-
所有者が誰か
-
中身を継承したいか、一時利用でよいか
-
アクセス権を人で見るか、チームで見るか
一言でまとめるなら、
「個人で責任を持つ一時保管はOneDrive、組織で引き継ぐ資産はSharePoint」
と説明すると、多くの社員が腑に落ちて動いてくれます。
「なぜSharePointを使うべきなのか?」に対する、業界人が現場でよく使う説明
「全部OneDriveでやってはいけない理由」は、リスクの話にすると一気に伝わります。私の視点で言いますと、次の3つを出すと経営層が静かになります。
-
退職者のOneDriveにしかないファイル問題
導入直後は誰も気にしませんが、1〜3年後に退職者が増えると、「あの見積もりデータどこ?」が必ず発生します。OneDriveはアカウントありきのストレージなので、削除と同時に中身も消える前提で考えるべきです。
-
社外監査やトラブル対応での検索性
SharePointはサイトやライブラリ単位で構造化され、検索システムも組織利用を前提に設計されています。ファイルサーバ代替として監査対応や証跡確認を考えると、個人単位で散らばったOneDriveより圧倒的に追いやすくなります。
-
Teamsとの連携とチームワーク
Teamsのチャネルにひも付いて自動作成されるのはSharePointサイトです。チャットで投げあったファイルが、結果的にチームの共有ストレージに整理される仕組みは、OneDriveでは代替できません。
要するに、「組織として責任を持つ情報」を置く前提で設計されているのがSharePointなので、ファイルサーバの置き換えやナレッジ共有をやる以上、避ける選択肢はありません。
「シェアポイントの欠点は?」と聞かれたときに、あえて“設計や運用の難しさ”を正直に伝える理由
SharePointの欠点を聞かれたとき、あえて次のように正直に話した方が、結果的に社内の協力を得やすくなります。
主な弱点
-
設計を誤ると、どこに何があるか誰も説明できない
-
権限をユーザー個別で付け続けると、整理不能な状態になる
-
同期やショートカット、外部共有のポリシーを決めないと、トラブルが必ず増える
ここで大事なのは、ツールの欠点ではなく「設計しないこと」の危険性として伝えることです。
-
「全部Teamsでチームを乱立すると、裏側のSharePointサイトがスプロールして棚卸しが地獄になる」
-
「その場しのぎで個別権限を足していくと、情報漏えい時に『誰が見えていたか』を誰も説明できない」
こうしたリスクを包み隠さず共有したうえで、
-
サイト構造
-
命名規則
-
権限モデル
-
同期とショートカット、外部共有のルール
を最初に情シス主導で決める必要があると説明すると、現場も「設定の細かさ」に意味を感じてくれます。
SharePointは、単なるクラウドフォルダではなく、組織の情報設計そのものを映す鏡です。欠点を隠さず伝えることが、情シスにとって最大の防御策になります。
専門家たちが現場で見てきた失敗と、その後に選ばれた解決パターンをあなたの職場に活かすには
「最初は順調だったのに途中で崩れた」M365運用の典型パターンから学べる体験談
導入直後は「クラウドに上がった、便利になった」で拍手喝采なのに、2~3年後に情シスが青ざめるパターンがはっきりあります。代表的な流れは次のようなものです。
-
ファイルサーバからSharePointへ移行
-
個人作業用としてOneDriveも展開
-
Teamsでチームサイトが量産される
-
保存先ルールがないまま現場に任せる
その結果、よく出る悲鳴はこの3つです。
-
退職者のOneDriveにしかない資料が見つからない
-
Teamsが山ほどあり、裏のSharePointサイト構造を誰も説明できない
-
同じファイル名がSharePointとOneDriveに乱立し、どれが最新版か分からない
表にすると、崩壊のサインはこう見えます。
| タイミング | 典型症状 | 背景 |
|---|---|---|
| 導入~半年 | 不満なし | ルールがなくても「勢い」で回る |
| 1~2年 | どこに保存したか分からない | サイトとフォルダが増殖 |
| 2~3年 | 退職者・異動で業務継続に支障 | 個人と共有の境界が曖昧 |
私の視点で言いますと、ここを「ツールの問題」と見るか「設計と運用の問題」と見るかで、その後の数年の楽さが決定的に変わります。
同期依存からショートカット中心へ、全部OneDriveからSharePoint中心へ…現場で起きた“方針転換”の理由
運用が崩れた後に、多くの企業が通るのが次の2つの方針転換です。
1つ目は、同期依存からショートカット中心への切り替えです。
-
すべてのSharePointライブラリをPCに同期
-
オフライン編集は快適だが、TB級のデータがローカルに降りてきてPC容量が逼迫
-
同期エラーの問い合わせが情シスを圧迫
そこで成功したパターンは次のルールです。
-
「標準はショートカットでエクスプローラー表示」
-
「特定の小規模ライブラリだけ同期を許可」
-
「大容量ライブラリは同期禁止ポリシーを適用」
2つ目は、保存先をOneDrive中心からSharePoint中心に寄せる判断です。
-
最初は「とりあえず全部OneDriveで共有」
-
退職者・長期休職者が出た瞬間に、業務必須ファイルが吹き飛ぶリスクに気付く
-
「ドラフトはOneDrive、決定版と共有はSharePoint」という線引きへ移行
このとき、単に「これから気を付けよう」で終わらせず、既存のOneDriveからSharePointへの計画的な移動と、リンク共有への置き換えまでやり切った組織ほど、その後のトラブルが激減しています。
こうした知見を踏まえて設計やルール作りを支援している専門家が、本当に重要視するポイント
情シスや部門ITリーダーが、自社の「地獄予防ライン」として押さえておくべきポイントは、実はそこまで多くありません。専門家が必ず確認するのは次の5点です。
-
保存先ルールが1枚の図で説明できるか
- 個人作業、チーム作業、全社共有、社外プロジェクトの4区分で「どこに置くか」が明文化されているか
-
退職者・異動時のファイル引き継ぎプロセスがあるか
- OneDriveをいつ、誰が、どうアーカイブするかが業務フローに組み込まれているか
-
同期とショートカットのポリシーが決まっているか
- 同期ボタンを出すサイト/出さないサイトの方針
- PC容量とネットワーク負荷の上限イメージを情シスが把握しているか
-
Teamsで作られたSharePointサイトを棚卸しできる仕組みがあるか
- 使われていないチームの定期的な確認
- プロジェクト終了時のアーカイブ先と期限のルール
-
権限設計が「個人直付け」から「グループ単位」に整理されているか
- アクセス権を誰が、どの単位で管理するかを決めているか
これらを一気に完璧にしようとすると現場は拒否反応を示します。現実的なのは、まず「退職者ファイル」「同期ポリシー」「Teams由来サイトの棚卸し」の3点に絞って手を打つやり方です。ここを押さえるだけでも、3年後の情シスの工数と、ファイル紛失のリスクは目に見えて下がります。情シスが疲弊する前に、今のうちに小さく試し、大きく崩れない設計へ寄せていくことが肝心です。
この記事を書いた理由
著者 – 宇井 和朗(株式会社アシスト 代表)
経営者として自社のIT基盤を整えつつ、数多くの企業のホームページやGoogleビジネスプロフィール、SNSだけでなく、社内の情報共有設計にも関わってきました。その中で繰り返し見てきたのが、OneDriveとSharePoint、そしてTeamsの関係をあいまいにしたまま運用を始めてしまい、「気づいた時には誰も全体像を説明できない」という状態です。
退職者のOneDriveから重要ファイルが見つかったり、Teamsのチーム乱立で裏側のSharePointサイトが把握不能になったり、同期を安易に多用して社員のPCがパンクしかけたケースもありました。ツール自体より、「どのファイルをどこに置くか」を決める前の設計が抜けていることが原因です。
私は、SEOやMEOと同じように、Microsoft 365の運用も「仕組み化」できなければ再現性が出ないと考えています。80,000社以上の支援を通じて見えてきたのは、難しい理論より、現場の社員が迷わない地図とルールが必要だということです。
この記事では、情シスや部門リーダーが「うちではこうする」と言い切れる判断軸を持てるよう、実際の運用でつまずきやすいポイントを具体的な保存ルールに落とし込んで整理しました。ツール任せにせず、自社に合った設計を主体的に選び取ってほしい、という思いで執筆しています。