SharePoint Onlineは、サイト、ページ、リスト、権限、検索、承認を組み合わせ、情報共有から申請管理までを支える業務基盤です。
構築できるシステムの種類、サービスの役割分担、開発・費用・移行の進め方を順に見ていきます。各テーマの詳細は、関連記事で扱っています。
▼関連記事一覧
・SharePoint Onlineのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・SharePoint Onlineのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・SharePoint Onlineのシステム開発の見積相場や費用/コスト/値段について
・SharePoint Onlineのシステム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SharePoint Onlineのシステムの概要
SharePoint Onlineは、Microsoft 365に含まれる情報管理サービスです。サイト作成、文書管理、検索、共同編集、権限管理を組み合わせて使います。
部門サイトや全社ポータルのほか、文書承認や申請台帳、案件一覧にも使えます。さらに、設備管理やナレッジ検索にも応用できます。標準機能を土台に、情報設計と運用ルールを組み立てる仕組みです。
情報共有基盤としての役割
SharePoint Onlineの基本単位は、サイト、ページ、ドキュメントライブラリ、リストです。役割を分けておくと、情報の置き場所を決めやすくなります。
- サイト：部門やプロジェクトの情報をまとめる範囲
- ページ：説明やニュースを見せる画面
- ライブラリ：ファイルを管理する場所
- リスト：案件・申請・備品などの構造化情報を管理する仕組み
ファイルにメタデータを付けておくと、検索条件をそろえられます。さらに、版管理や承認も有効にすると、共有フォルダに比べて、どれが正本かを判断できます。
システムとして導入する価値
導入の効果は、保存場所のクラウド化そのものよりも、情報の所有者、閲覧範囲、保存期間、承認者を決めて、分散した業務を組織のルールに戻せることにあります。また、検索時間、申請の滞留日数、重複ファイルの件数、ポータル閲覧率などをKPIにすると、導入後の改善を追えます。
目的や正本を決めないままサイトを作ると、情報がクラウド上で分散するため、注意が必要です。
SharePoint Onlineで構築できるシステムの種類
用途は、公開情報を見せるポータルから、部門内の申請や台帳管理まで広がります。そのため、発注側と開発会社が、利用者やデータの性質、処理の複雑さ、外部連携の有無を見て、SharePointに置く範囲を決めます。
社内ポータルと文書管理システム
社内ポータルでは、全社のお知らせや社内規程、部門の手続きを置けるほか、FAQや教育資料もまとめられます。また、ハブサイトを使えば、複数の部門サイトを横断して案内できます。
文書管理では、文書種別、部門、年度を列として持たせます。機密区分や承認状態、保存期限なども、列に加えます。こうした列があると、ファイル名に頼らずに検索・絞り込み・版管理を機能させられます。
ファイルサーバーから移行するときは、重複や古い版を洗い出しておきます。個人情報や保存期限切れの資料は、別に分けて扱います。そのうえで、業務部門と一緒に「残す」「アーカイブする」「廃棄候補にする」の扱いを決めると、容量と権限を抑えられます。
申請・台帳・ナレッジ管理システム
SharePointリストは、行単位で管理する業務に向いています。どの業務を載せるか、どこを自動化するかは、業務の流れを見て決めます。
- 管理対象：申請台帳、問い合わせ、備品、案件進捗、設備点検の記録
- 拡張方法：Power Appsで入力画面を整え、Power Automateで申請・承認・通知を自動化
期限超過のリマインドも、自動化できます。紙やメールの業務を置き換える際は、まず1つの申請と1つの承認ルートから始めると、利用者が流れを理解しやすくなります。
複雑なリレーションや大量の同時更新が必要なとき、あるいは厳密なトランザクションや高度な分析が必要なときは、DataverseやSQLとの役割分担を検討します。
業務データのすべてを一つのリストに集める必要はなく、用途ごとに分けても構いません。一方で、リストを万能な業務データベースとして使うと、権限・検索・性能の設計が難しくなり、保守費用が増える可能性があります。
Teams・OneDrive・Power Platformとの違い
TeamsやOneDriveはSharePoint Onlineと連携しますが、情報の公開範囲とライフサイクルは異なります。そこで、役割を決めておけば、同じファイルを複数の場所に置く状態を避けられます。
保存場所の役割分担
保存場所は、個人の作業中ファイル、チームの会話、組織の正式情報に分けて考えます。特に、正式な規程や確定版の成果物は、管理場所を決めて正本を一か所にまとめておきます。
- OneDrive：個人の作業中ファイルや個人起点の共有
- Teams：チャネルのファイルはチームに紐づくSharePointサイトのライブラリに保存
- SharePoint：部門・案件・全社ポータルなど、組織が継続管理する情報の正本
Power Platformと拡張開発の境界
要件に応じて、発注側と開発会社が標準機能、ローコード、拡張開発を組み合わせます。標準機能を活かせば、短期間で整えられます。
- 標準・ローコード：通知・承認はPower Automate、入力画面の改善はPower Apps、可視化はPower BI。
- 拡張開発：標準機能で足りない画面や、複雑な外部連携に対応します。
- 運用上の備え：自由度が上がる分、作成者異動後の修正、環境分離、テスト、ソース引き渡し、API仕様変更への対応が必要です。
- 要件定義：設定と開発成果物の境界を、要件書に明記します。
標準Webパーツにない画面や複雑な外部連携には、拡張方法を検討します。拡張の候補には、SharePoint Framework、Microsoft Graph、API、Azure Functionsがあります。どれを選ぶかは、要件を見て決めます。
SharePoint Onlineのシステム開発の進め方
開発では、画面を作る前に情報の持ち方と管理責任を決めておく必要があります。企画、設計、構築、移行、定着の順に分けて進めると、権限・検索・運用の問題を防ぎやすくなります。
企画・要件定義の決定事項
改善する内容は、利用者と成果を具体化して一文で定義します。「社内ポータルを作る」のように作るものだけを書くと、目的が伝わりにくくなります。
- 目標の例：「規程の最新版を3分以内に検索する」
- 利用規模：対象ユーザー数、利用部門、同時利用、文書容量
- データと統制：移行元、外部共有、個人情報、保存期間、必要な監査
- 連携と運用：連携API、SLA、教育、運用担当
現行業務では、ファイルサーバーやTeams、OneDrive、Excel、既存データベースを一覧にします。正本と更新者を確かめ、利用頻度や重複も見ます。さらに、廃棄の可否とアクセス権も確認します。
特に、所有者不明の情報や、退職者の個人フォルダにしかない情報、部門ごとに重複する規程は、構築の前に解消しておきます。
情報設計・PoC・開発
情報設計では、サイトやハブサイト、ライブラリ、リストの構成を決めます。メタデータや命名規則、権限グループ、ナビゲーション、検索分類も設計します。
- PoC対象：代表的な1部門、1つの申請、1つの移行フォルダ
- 確認項目：検索、版管理、承認、モバイル閲覧、権限エラー
- 運用確認：外部共有、復旧
PoCでは、実データと実際の利用者を使って、運用上の失敗を先に見つけます。
PoCで確認したルールは、標準機能、Power Platform、拡張コードのどれで実現するかに分類します。さらに、開発、検証、本番の環境も分けておきます。
Power Platformでは、Solutions、環境戦略、データ損失防止の設計が必要です。加えて、接続先、所有者交代、リリース手順も設計します。本番環境は直接設定を変えず、承認を得た変更として管理します。
移行・テスト・リリース・定着化
移行から定着までは、次の順序で計画します。
- 移行：事前クレンジング、権限マッピング、メタデータ変換、テスト移行と差分移行、受入テスト、切替後の凍結とロールバックを計画します。
- テスト：画面の表示に加え、閲覧可否・承認者不在・リンク切れ、検索・版の復元・通知失敗、外部共有・退職者アカウント・監査ログを確認します。
- 定着：利用者向けの操作説明と管理者向けの運用手順を用意します。30日でPoC、3か月で部門展開、6〜12か月で全社展開し、現場の負荷を抑えながら改善します。
SharePoint Onlineの個別ファイルのアップロード上限は250GBです。また、サイトやコンテナー間の移動・コピーは合計100GBかつ30,000ファイル以下です（出典: Microsoft Learn「SharePointの制限」、2025年11月更新）。
大量移行では、一括コピーに頼らず、分割、夜間実行、差分同期、エラー再実行を設計します。
SharePoint Onlineのシステム開発費用相場
SharePoint Online専用の開発費について、公的な平均統計は確認できません。そのため、公式ライセンス表示と公開価格、移行・設計・テストの工数を組み合わせた、予算検討用の目安を示します。
見積額を左右するのは、ユーザー数のほか、移行データの量と品質です。さらに、権限の複雑さや外部連携、教育、保守範囲も金額に影響します。
▶ 詳細はこちら：SharePoint Onlineのシステム開発の見積相場や費用/コスト/値段について
ライセンス費用と契約構成
発注側は、契約に使うライセンスの価格と提供終了時期を確認します。
- 価格：Business Basicは年払いで、1ユーザーあたり月額1,049円相当（税抜）です。
- 提供終了：単体プラン1・2の販売、更新、サービスの終了予定
新規販売は2026年6月、更新は2027年1月以降、サービス終了は2029年12月の方針です。この内容は2026年1月のお知らせに記載されています（出典: Microsoft Learn「2026年1月のお知らせ」、2026年）。
この価格は公式ページの表示です（出典: Microsoft「Microsoft 365 SharePoint: プランと価格を比較」、2026年）。確認日は2026年8月7日です。このプランには、SharePointのチームサイト、OneDrive、Teamsなどが含まれます。
価格は契約条件や地域、キャンペーンで変わります。100ユーザーなら単純計算で月10万4,900円相当、年125万8,800円相当です。そのうえで、既存契約との重複や対象ユーザーの範囲を確認し、予算に組み込みます。
古い単体プランの価格を前提にすると、将来の契約変更で予算が崩れるおそれがあります。そのため、Microsoft 365のスイートや追加ストレージ、必要なセキュリティ機能を、契約担当者と確かめておきます。
初期構築・移行・追加開発の目安
初期費用と期間の目安は、構成や移行範囲によって変わります。
- 設定中心：20万〜60万円程度、2〜6週間
- 部門ポータル：100万〜500万円程度、1〜3か月程度
- 移行込みの全社ポータル：300万〜1,000万円程度、2〜6か月程度
- 複数拠点等を含む構成：1,000万〜3,000万円以上、6〜12か月以上の場合があります。
設定中心は1〜2サイトが対象で、基本ライブラリや権限、標準ページ、管理者への説明までを含みます。一方、部門ポータルは、リスト、Power Automateの申請・通知、簡単なPower Apps、受入テストを加える構成です。
全社ポータルは、ファイルサーバーや旧環境、別の文書管理基盤からの移行を含みます。さらに、複数拠点や基幹API、DataverseやAzure、厳格な監査、段階展開を含む構成もあります。
これらは公開統計ではなく、クラウド標準機能でインフラ構築費を抑えたうえで、移行・権限・教育・連携の工数が残る前提の推定レンジです。なお、部門ポータルでは、要件整理と利用者確認の比重が大きくなります。
運用保守と隠れたコスト
見積もりは、費用項目ごとに分けて確認します。
- 契約・構築：ライセンス、初期構築、追加開発
- 移行・定着：データ移行、教育
- 運用・統制：保守、バックアップや監査の追加サービス
一般的な業務システムの保守費目安は、初期開発費の年15〜25％程度、または月15万〜80万円程度です。
SharePointでは、問い合わせ対応に加えて、権限の棚卸しや不要サイトの整理を含むかで差が出ます。さらに、フロー監視や容量管理、仕様変更対応を含むかどうかでも差が生じます。
要件定義、移行リハーサル、権限テスト、教育を削ると、稼働後の手戻りが増えます。そこで、見積もりでは作業時間に加えて、成果物の範囲も確認します。
サイト構成図、権限一覧、移行結果、テスト証跡が見積もりに含まれるかを確かめます。また、Power PlatformのSolution、拡張コード、運用手順、障害時の復旧手順も、対象になります。
標準機能・ローコード・拡張開発の選び方
基本は、標準機能を優先し、不足する部分をローコードやコードで補うことです。あわせて、5年後に誰が修正するか、どの契約で動かすか、何を監査できるかも判断材料になります。
標準機能を優先するケース
社内ニュースや規程公開、文書の版管理、基本的な承認、検索は、標準機能で始められます。部門サイトや簡単なリスト管理も、標準のページやライブラリ、リスト、権限、通知から始められます。
標準機能は製品の更新に追随しやすく、属人化も抑えやすい点が利点です。デザインの細かな調整より、命名規則やメタデータ、所有者、申請ルールのほうが、利用の定着に直結することもあります。
ローコードを使うケース
入力項目を減らすことや、スマートフォンからの登録、自動通知、期限超過の管理が必要な場合は、Power AppsとPower Automateが適しています。また、共有アカウントやサービスプリンシパルなど、運用方針も決めておきます。
ローコードでも、環境や接続、ライセンス、権限の設計は必要です。さらに、エラー処理や所有者交代、リリース管理も欠かせません。たとえば、個人アカウントにフローが依存していると、異動や退職で業務が止まることがあります。
カスタム開発を使うケース
標準Webパーツにない画面や、認証を伴う外部連携には、SPFxやGraph、API、Azure Functionsなどを組み合わせます。大量データ処理や複雑な業務ルールも、対象になります。
機能の実現性に加えて、セキュリティレビューやテスト、自動デプロイ、障害監視を成果物に含めます。ソースコード管理や、製品更新への追随方法も、成果物の範囲に入れます。
カスタム開発では、古い方式を新規設計の前提にしないことが基本です。
- 新規設計：現行のモダンサイトとサポートされる拡張方式を基本にする
- 既存移行：古いカスタマイズを再現する前に必要性を見直し、開発費や保守負担を抑えられる場合がある
移行・権限・セキュリティで失敗しない方法
導入の失敗は、機能不足よりも、移行前の整理不足や権限設計の後回しで起こりやすくなります。そのため、ファイルや利用者、権限、保存期限を一緒に設計します。外部共有や監査要件も、同じ検討の中で扱います。
最小権限での権限設計
権限、外部共有、機密情報の扱いは、構築の前にルールを定めておきます。
- 権限単位：サイト、ライブラリ、フォルダ、ファイルの分け方を決め、原則サイト・ライブラリ単位でグループ化
- 例外権限：増やすと閲覧者を説明しにくくなる
- 権限継承：継承を切る運用を減らし、性能と監査を保つ
- 外部共有：匿名リンクかゲスト招待か、有効期限、退職・異動者のアクセス、リンクの棚卸し、所有者交代を定める
- 機密情報：個人情報、機密情報、契約書の扱いを確認し、保存・廃棄・持ち出しを明文化
リストやライブラリの固有権限は最大50,000で、一般的な推奨上限は5,000です（出典: Microsoft Learn「SharePointの制限」、2025年11月更新）。
監査ログとサービス制限の確認
クラウドサービスだから安全と決めつけず、管理者が確認できる記録と契約上の責任範囲を整理します。
- 共有監査：外部ユーザーの招待・承諾、匿名リンク作成を確認
- 監査条件：必要なライセンス、保持期間、検索権限、ログ保存、調査手順を確かめる
- サービス制限：検索・同期、パス長、リスト表示、固有権限数を要件定義・移行計画に含める
- 移行検証：代表データで受入テストを行う
Microsoft Purviewの監査ログで共有イベントを検索できます。機能説明の出典はMicrosoft Learn「監査ログで共有監査を使用する」（2026年6月更新）です。
大規模なライブラリでは、検索や同期、ファイルパス、リスト表示、固有権限数が問題になりがちです。
移行ツールを使っても、ファイル名や文字コード、リンクが正しく再現されるとは限りません。所有者や版、更新日時についても、移行後に確かめておきます。
SharePoint Onlineの開発会社/ベンダーの選び方
会社やベンダーは、知名度や価格だけでなく、作るシステムに合う経験で比較します。ポータル、ファイル移行、Power Platform、外部API、セキュリティ・監査、運用保守では、必要な能力が異なります。
依頼の前に、対象ユーザーや移行元、データ量を1枚にまとめます。そこへ、外部共有や個人情報、承認、希望時期、予算、運用体制も書き加えます。
実績と対応範囲の確認
画面作成の件数よりも、自社の課題に近い工程での経験を確認します。対象となるのは、移行や権限マッピング、検索・メタデータ、Power Apps・Power Automateです。さらに、SPFxやAPI、監査・外部共有、教育、保守も含まれます。
実績については、規模や役割、期間を聞きます。加えて、移行データや成果物、障害対応、現在の保守体制も確かめます。
同じRFPでの見積もり比較
相見積もりでは、各社に同じRFPを渡します。そのうえで、ライセンス、初期構築、移行、追加開発の費用を分けて提示してもらい、テストや教育、保守も別々に示してもらいます。
「サイト構築一式」「移行一式」など内訳が示されない場合は、対象範囲と前提を確認します。データクレンジング、権限表の承認、移行後のリンク確認を誰が担うかも、あわせて決めます。
契約と運用体制の確認
発注側は、契約と運用体制の中で、引き渡しや責任の分け方、委託先の比較項目を確認します。
- 契約成果物：著作権・翻案権、設定情報・Power PlatformのSolution、SPFxソース・移行スクリプト、テスト証跡・運用手順
- 運用の役割：障害の一次受付、Microsoft 365の仕様変更、外部サービスの障害、バックアップ・復旧の責任
- 納品条件：担当者交代後も管理できる状態を含める
- 比較項目：得意領域、対応工程、移行経験・拡張開発、セキュリティ・公開価格・保守
▶ 詳細はこちら：SharePoint Onlineのシステム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：SharePoint Onlineのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
▶ 詳細はこちら：SharePoint Onlineのシステム開発の発注/外注/依頼/委託方法について
導入後の運用保守での確認事項
公開後も、利用状況と情報の品質を定期的に見直します。点検するのは、サイト所有者や権限、外部共有、容量です。さらに、検索やフロー失敗、古い文書、未使用サイトも確認し、利用部門と一緒に改善します。
定期レビューで見る指標
月次または四半期ごとに、閲覧数や検索ゼロ件、検索時間、申請処理時間を確認します。失敗フローや共有リンク、ゲストも見ます。未使用サイトや容量、重複文書も確認します。
導入前のKPIと比べて改善が見られなければ、機能を足すより先に、ナビゲーション、検索用メタデータ、利用者教育、正本ルールを見直します。
所有者交代と変更管理の仕組み
サイトやフローごとに、主担当と副担当を置きます。異動や退職の際の引き継ぎは、人の善意に任せず、運用の決まりとして行います。
サイト作成の申請や閉鎖の基準、権限変更の承認、外部共有の期限、Power Platformのリリース方法を、あらかじめ定めておきます。また、Microsoft 365の仕様やライセンスの変更で見直しが要る機能も記録しておけば、突然の作り直しを避けられます。
よくある質問
SharePoint Onlineの導入前によくある質問を、費用、開発難易度、既存環境からの移行の観点から取り上げます。構成は自社の要件によって変わるため、対象データと運用体制に当てはめて検討します。
SharePoint Onlineのシステム開発費用はいくらですか？
設定中心なら20万〜60万円程度、部門アプリなら100万〜500万円程度、移行を含む全社ポータルなら300万〜1,000万円程度が予算検討の目安です。
ライセンス、移行、追加開発、教育、保守は、それぞれ別費用です。そのため、総額だけで比べず、見積書の内訳と前提条件を確認します。
SharePoint Onlineはローコードだけで開発できますか？
ポータル、文書管理、基本的なリスト、承認や通知は、標準機能とPower Platformで実現できる場合があります。
複雑なデータ関係や大量処理、外部APIが必要なときは、DataverseやSQLを組み合わせます。独自画面や厳格な監査が必要な場合は、SPFxやGraph、Azureなども使います。
ローコードで作る場合も、権限やテスト、所有者交代、ライセンス、運用設計は欠かせません。
ファイルサーバーからSharePoint Onlineへ移行できますか？
移行はできますが、ファイルのコピーに加えて、準備が欠かせません。まず、重複や不要ファイルを整理したうえで、正本やメタデータ、所有者を決めます。権限や保存期限、リンク、版の扱いも決めておきます。
テスト移行と受入確認を行ってから、本番移行に進みます。大規模移行では、段階移行や差分同期、切替時の凍結、エラー再実行、旧環境への戻し方まで計画しておきます。
まとめ
SharePoint Onlineでは、社内ポータルや文書管理、申請、台帳、ナレッジ検索を、Microsoft 365上で組み合わせて使います。なかでも、正本、権限、メタデータ、移行対象、運用責任者を先に決めることが、導入の成否を左右します。
現行業務とデータの棚卸し
対象ユーザー、移行元、正本、権限を一覧にします。外部共有や保存期間、申請ルート、目標KPIも、この一覧に加えます。そのうえで、代表部門のPoCを行い、実現方法ごとに範囲を分けます。
標準機能で足りる部分、Power Platformで補う部分、カスタム開発が必要な部分を整理します。また、ライセンス、初期構築、移行、追加開発、教育、保守を分けておくと、契約変更や運用負荷も判断しやすくなります。
小さく始めて運用で育てる進め方
全社の情報を一度に移すより、1部門・1ワークフロー・1つの文書群で検証し、利用状況を見ながら広げる進め方があります。
権限や外部共有を定期的に見直し、所有者交代、監査、仕様変更、復旧を運用に組み込みます。これにより、ファイル置き場にとどまらない業務システムとして定着させられます。
▼関連記事一覧
・SharePoint Onlineのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・SharePoint Onlineのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・SharePoint Onlineのシステム開発の見積相場や費用/コスト/値段について
・SharePoint Onlineのシステム開発の発注/外注/依頼/委託方法について
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。