SharePoint Onlineのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

SharePoint Onlineのシステム開発は、サイトやファイルを作るだけではなく、情報の正本、権限、申請の流れ、運用責任者まで設計して段階的に定着させる取り組みです。

本記事では、要件整理、製品・構成の選定、設計開発、テスト、稼働、定着の6フェーズに分けて、実務で確認すべき項目を解説します。ライセンスと開発費を分けた費用相場、見積書の読み方、移行や権限で起きやすい失敗、2026年時点の最新動向も紹介します。

▼全体ガイドの記事
・SharePoint Onlineのシステム開発の完全ガイド

SharePoint Onlineのシステム開発の全体像

SharePoint Onlineは、Microsoft 365上で動くクラウド型の情報共有、文書管理、社内ポータルの基盤です。TeamsやOneDriveと接続できるため、単なるファイル置き場ではなく、情報の入口と業務データの管理場所を組み合わせる「業務システムの土台」と捉えることが大切です。

社内ポータルなら、サイトとページ、ニュース、検索、ハブサイトを組み合わせて部門情報を集約できます。文書管理なら、ドキュメントライブラリにメタデータ、版管理、承認、共有リンクを設定できます。SharePointリストを使えば、問い合わせ台帳、備品管理、案件一覧、申請の受付状況といった軽量な構造化データも管理できます。

入力画面を使いやすくしたい場合はPower Apps、通知や承認を自動化したい場合はPower Automateが候補です。複数テーブルの関係、細かな権限、厳密なトランザクションが必要な業務データはDataverseやSQLに分け、SharePointは文書やポータルの役割に集中させると、後から無理な作り替えが起きにくくなります。

SharePoint Onlineのシステム開発で最初に決めたいのは、どの情報をどこに置くかです。Teamsのチームに紐づくファイルは実体としてSharePointのライブラリに保存されますが、個人の作業中ファイルはOneDrive、部門や全社で共有する正式文書はSharePointというように、保存先の原則を決めます。

Power Appsは入力体験、Power Automateは処理の連携、DataverseやSQLは複雑なデータ管理、SharePointは文書・ページ・軽量台帳という分担です。この整理をしないまま「SharePointだけで全部作る」と、リストの行数、権限の例外、フローの所有者、検索の精度が問題になりやすいです。

Microsoft公式の比較ページでは、SharePointプラン1が年払いで1ユーザー月額749円相当、Microsoft 365 Business Standardが2,098円相当と表示されています。ただし、契約形態、税、地域、価格改定、既存契約によって変わるため、記事の金額は予算仮説として扱い、発注時点の見積もりで再確認する必要があります（出典: Microsoft公式「SharePointのプランと価格の比較」、2026年8月確認）。

さらに、Microsoftは2026年1月の告知で、スタンドアロンのSharePoint Onlineプラン1・2について、2026年6月の新規販売終了、2027年1月以降の更新終了、2029年12月のサービス終了という方針を示しています（出典: Microsoft Learn「2026年1月のお知らせ」、2026年確認）。新規案件では単体プランだけを前提にせず、Microsoft 365スイート、追加ストレージ、既存テナントの契約を含めて比較します。

SharePoint Onlineのシステム開発の進め方

SharePoint Onlineの導入は、サイトを先に作るのではなく、業務と情報の現状を整理してから小さく検証し、移行と運用を含めて段階展開します。ここでは、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズで、成果物と判断基準を具体化します。

最初に「何を作るか」ではなく「何を改善するか」を決めます。検索時間を何分短縮したいのか、申請処理を何日から何日にしたいのか、紙やメールのやり取りをどの業務で減らすのか、ポータルの利用率をどう測るのかをKPIにします。目的が「SharePointを使うこと」だけだと、サイトが完成しても成果を判定できません。

次に、ファイルサーバー、SharePoint Server、Notes、Excel、Teams、OneDrive、既存データベースを棚卸しします。対象ごとに、情報の正本、所有部門、更新者、保存期限、個人情報の有無、利用頻度、移行可否、現在のアクセス権を一覧化します。特に「同じ規程が複数の場所にある」「退職者が所有者のフローがある」といった例外を見つけることが重要です。

このフェーズの完了条件は、対象ユーザー数、移行元、対象容量、主要業務、外部共有の有無、保存・廃棄ルール、必要な連携、運用責任者が文書化されていることです。要件定義書だけでなく、サイト一覧、権限一覧、移行対象一覧、非機能要件、受入条件まで作ると、後工程での追加請求を抑えやすくなります。

技術選定は、標準機能、Power Apps・Power Automateなどのローコード、SPFx・Microsoft Graph・Azure Functionsなどのカスタム拡張の順で検討します。標準Webパーツ、ライブラリ、リストで目的を満たせるなら、追加コードを作らない方がアップデートへの追随と担当者交代が容易です。

標準機能では入力体験や承認条件が足りない場合にPower AppsやPower Automateを使います。外部システムのAPI連携、独自画面、複雑な処理が必要になって初めてSPFxやAzureを検討します。選定時は、実装の速さだけでなく、環境分離、Solutionsによる配布、DLP、フロー所有者の交代、ソースコード引き渡し、障害対応の責任範囲も確認します。

2026年時点では、古いSharePoint Add-inを新規採用しないことが必須です。Microsoft Learnでは、SharePoint Add-inが2026年4月2日に全テナントで終了し、代替の開発モデルとしてSPFxが案内されています（出典: Microsoft Learn「SharePoint Add-In retirement in Microsoft 365」、2026年確認）。既存資産がある場合は、現状調査と移行計画を見積もりに含めます。

設計では、サイト、ハブサイト、ライブラリ、リスト、ページの単位を決めます。部門ごとに何でもサイトを作るのではなく、組織の変更頻度、権限境界、情報のライフサイクル、検索のしやすさを基準にします。サイト名、URL、所有者、メンバー、閲覧者、命名規則、メタデータ、版管理、承認、保持期間を設計書に記載します。

権限は後から付け足さず、サイトやライブラリの設計と同時に決めます。基本はMicrosoft Entra IDのグループやSharePointグループを使い、個別ファイルへの例外権限を減らします。外部ユーザー、ゲスト、匿名リンクの扱い、退職・異動時の削除、サイト所有者が不在になった場合の交代手順も、アクセス設計の一部です。

移行がある場合は、古いファイルをそのままコピーするのではなく、重複、不要な版、長すぎるパス、機密情報、所有者不明のデータを整理します。Microsoft Learnの制限では、1ファイルのアップロード上限は250GB、ファイルパス全体は400文字、リストやライブラリのアイテム数は最大3,000万件とされています（出典: Microsoft Learn「SharePointの制限」、最終更新2025年11月）。ただし、制限値まで使えることと、利用者が快適に使えることは別のため、検索・同期・権限の実測を行います。

テストは、画面が開くかだけでは不十分です。代表ユーザーが検索、閲覧、編集、版戻し、承認、通知、モバイル利用を実行し、想定した権限と結果になるかを確認します。管理者はサイト作成、所有者交代、グループ変更、外部共有の申請、監査ログの確認、フロー失敗時の再実行まで試します。

移行テストでは、事前クレンジング後の件数、ファイル名、メタデータ、更新日時、版、所有者、権限、リンク切れを移行前後で照合します。本番切替の前に、代表部門のデータでリハーサルを行い、差分移行の所要時間、利用停止時間、失敗時のロールバック方法を確定します。受入テストでは、利用部門が合格条件に署名できる状態を作ります。

大容量の移行では、サイト間の移動・コピーに合計100GB、ファイル数30,000個以下という制限があるため、移行単位とツールの処理方式を先に検証します（出典: Microsoft Learn「SharePointの制限」、2026年確認）。制限に近い環境では、夜間の差分処理だけでなく、失敗したファイルを再処理する仕組みも確認します。

稼働は、全社一斉切替よりも、代表部門や1つの業務から始める段階展開が安全です。最初の部門で検索、承認、権限、移行、問い合わせ対応を検証し、手順を修正してから次の部門へ広げます。全社ポータル、文書管理、申請アプリを同時に始めると、どこでつまずいたか分かりにくくなるため、優先順位をつけます。

切替当日は、旧環境の編集停止、最終差分移行、件数照合、権限確認、利用者への案内、問い合わせ窓口の開設を順番に実施します。旧環境をすぐ削除せず、参照専用や一定期間の保管にして、切戻し基準を決めます。稼働判定には、重大な権限不備がないこと、重要文書が検索できること、承認フローが完了すること、管理者が障害時の連絡先を把握していることを含めます。

稼働後は、使い方を説明して終わりではありません。利用率、検索で見つからなかったキーワード、未使用サイト、古い共有リンク、外部ゲスト、容量、失敗したPower Automate、問い合わせ件数を定期的に確認します。月次の管理者会議でサイトの新設・廃止、所有者変更、権限棚卸しを扱い、四半期ごとに情報設計とKPIを見直す運用が現実的です。

外部共有は、設定しただけでは管理できません。Microsoft Purviewの共有監査では、誰が誰にどのリソースを共有したか、招待が作成・承諾されたか、匿名リンクが作成されたかといったイベントを確認できます（出典: Microsoft Learn「監査ログで共有監査を使用する」、最終更新2026年6月）。個人情報や機密文書を扱う場合は、保持期間、DLP、秘密度ラベル、監査機能のライセンスを法務・情報システムと確認します。

2026年7月以降はSharePointアラート機能の削除が案内されており、通知にはルールまたはPower Automateを利用する方向が示されています（出典: Microsoft Learn「ユーザーがSharePointアラート通知を受信しない」、2026年確認）。通知をアラートに依存している既存環境は、稼働後の棚卸しで対象を洗い出し、代替フローと所有者交代の手順を用意します。

SharePoint Onlineのシステム開発の費用相場

SharePoint Onlineの費用は、ライセンス、初期構築、データ移行、追加開発、教育、保守に分けて考えます。SharePoint Onlineだけの公的な開発費平均統計はないため、以下はMicrosoft公式価格、国内ベンダーの公開支援価格、業務システムの一般的な工数から作った予算検討用のレンジです。個別案件の確定金額ではありません。

Microsoft公式の表示価格を基準にすると、SharePointプラン1を100ユーザーで利用する場合は月額7万4,900円、年額89万8,800円相当です。ただし、これは年払いの表示値を単純計算した参考値で、税、契約条件、追加容量、サポート費は含みません。すでにMicrosoft 365 Business StandardやEnterpriseを契約している場合、SharePoint機能が含まれている可能性があるため、人数分を重ねて購入しないように確認します。

2026年は単体プランの販売・更新方針が変わるため、見積書に「どのSKUを何ユーザー分、何年契約するか」「既存ライセンスで利用できる機能は何か」「追加ストレージやPower Appsのプレミアムコネクタが必要か」を明記してもらいます。単純な月額比較ではなく、契約期間中のTCOと将来の移行余地で判断します。

設定中心で1〜2サイト、基本権限、標準ページ、管理者説明までなら、初期費用は20万〜60万円程度、期間は2〜6週間が一つの目安です。部門ポータルにリスト、Power Automateの承認・通知、簡単なPower Apps、受入テストを加える場合は、100万〜500万円程度、1〜3か月のレンジを予算仮説にします。

ファイルサーバー、SharePoint Server、Notesからの移行、メタデータ変換、権限マッピング、検索設計、教育まで含む全社ポータルでは、300万〜1,000万円程度、2〜6か月が目安です。複数拠点、基幹API、DataverseやAzure、Purview、厳格な監査、段階展開まで含める場合は、1,000万〜3,000万円以上、6〜12か月以上になる可能性があります。

これらはクラウド標準機能でサーバー構築費を抑えられる一方、移行・権限・教育・連携の工数が残るという前提で、リサーチノートの業務システム相場から推定したレンジです。株式会社コムデックが公開するSharePoint Onlineサポートの月5,000円、Microsoft 365サポートの月20,000円は、小規模な運用支援の参考値であり、開発や大規模移行の費用とは分けて扱います（出典: 株式会社コムデック公開価格、2026年確認）。

保守費は、問い合わせ対応だけでなく、サイトや権限の棚卸し、所有者変更、フロー監視、容量確認、Microsoft 365の仕様変更対応、軽微な改修をどこまで含むかで変わります。一般的な業務システムの目安として、初期開発費の年15〜25％程度、または月15万〜80万円程度を置く方法がありますが、SharePoint案件では対象ユーザー数とサポート時間を基準に再見積もりします。

教育費は、管理者向けと一般利用者向けに分けます。管理者にはサイト作成、権限、保持、監査、フローの引継ぎを教え、一般利用者には検索、メタデータ、版管理、共有、申請の使い方を教えます。導入時の研修だけでなく、操作ガイド、FAQ、問い合わせの一次切り分け表を成果物に含めると定着しやすいです。

バックアップ、監査、DLP、秘密度ラベル、追加ストレージ、Power Appsのプレミアム機能などは、契約プランによって別費用になる可能性があります。見積もりでは、ライセンス、構築、移行、教育、保守、追加サービスを別行にし、初年度と2年目以降の費用を並べます。

SharePoint Onlineの見積もりを取る際のポイント

見積もりの安さだけで発注先を決めると、要件整理や移行リハーサル、権限テストが省かれて、稼働後に追加費用が発生しやすくなります。依頼時に対象範囲と成果物をそろえ、ライセンスと作業費を分離して比較することが、SharePoint Onlineのシステム開発では重要です。

依頼書には、対象ユーザー数、利用拠点、既存のMicrosoft 365契約、移行元、データ容量、ファイル数、サイト数、対象業務、外部共有、個人情報、保存期間、必要な検索条件、API本数、モバイル利用、SLA、教育、保守期間を記載します。ファイル数や容量が不明な場合は、ベンダーに現状調査を先に依頼し、調査費と本構築費を分けます。

機能要件だけでなく、非機能要件も明記します。たとえば、権限は最小権限を原則にすること、外部共有は申請制にすること、監査ログの保持期間を定めること、障害時の連絡時間を定めること、サイト所有者の交代手順を残すこと、設定ファイルやPower PlatformのSolution、SPFxのソースコード、移行スクリプト、運用手順を納品対象にすることなどです。

受入条件も、完成後に考えるのではなく発注前に決めます。「重要文書の検索結果が確認できる」「部門ごとの閲覧範囲が守られる」「承認が代理者を含めて完了する」「移行前後の件数と権限が一致する」「管理者がサイトを新設・廃止できる」といった観測可能な条件にします。

候補会社には同じRFPを渡し、要件整理、サイト設計、開発、移行、テスト、教育、保守をどこまで対応できるかを確認します。比較軸は、SharePoint Server・Notes・ファイルサーバー移行の実績、Power Platformの設計力、SPFxやAPIの開発体制、権限とセキュリティの経験、担当者の資格だけではありません。移行後の運用、サイト乱立の防止、担当者交代、障害時の復旧責任まで質問します。

見積書では、作業項目ごとの工数、前提条件、対象外、追加変更の単価、納品物、検収条件、保守の時間帯とSLAを確認します。「データ移行一式」「環境構築一式」のような大きな一行だけでは、どの作業が含まれるか判断できません。移行対象の除外条件や、利用部門が行うクレンジング作業も明示してもらいます。

価格公開の有無も比較材料ですが、公開価格だけで優劣を決めません。たとえば、Microsoft 365全体の導入支援として50万〜200万円、SharePoint・Teams導入支援20万円程度を公開している事業者がありますが、Exchangeなどを含む場合があり、個別のSharePoint開発費とは一致しません。対象範囲をそろえたうえで、2〜3社程度から提案を受けると判断しやすくなります。

典型的な失敗は、サイトを作りすぎて最新版が分からなくなることです。サイト作成権限を広く配りすぎず、サイトの目的、所有者、廃止条件、命名規則を決めます。次に多いのは、ファイルを移した後に権限とメタデータが壊れることです。移行前の棚卸し、権限マッピング、サンプル移行、差分移行、件数照合を作業項目に含めます。

申請フローが作成者に依存する問題もあります。接続情報、フローの所有者、代理管理者、失敗時の通知先、再実行手順、環境ごとの設定を文書に残し、Solutionsやソースコードを納品対象にします。外部共有では、ゲストの在籍確認、匿名リンクの禁止または期限、監査ログの定期確認を運用ルールにします。

最後に、契約上の成果物を確認します。設定値、サイト設計書、権限一覧、テスト仕様書・結果、移行ログ、切替手順、ロールバック手順、管理者マニュアル、利用者向けFAQ、Power PlatformのSolution、SPFxのソースコードとライセンス、保守窓口がそろっているかを確認します。納品後に自社で運用できる状態までが、システム開発の完了です。

SharePoint Onlineのシステム開発でよくある質問

最後に、導入前によく寄せられる質問へ回答します。費用だけでなく、どこまでSharePointに任せるか、移行できるか、開発会社へ何を依頼するかを整理すると、自社に合わない構成を避けられます。

社内ポータル、文書管理、規程・ナレッジ検索、申請台帳、案件一覧、問い合わせ管理、承認・通知の仕組みなどを構成できます。複雑なリレーションや大量トランザクションを持つ基幹業務は、DataverseやSQLなどに分け、SharePointは文書・ポータル・軽量台帳に使うと安定します。

移行できますが、単純なコピーではなく、不要データの削除、重複整理、メタデータ設計、権限マッピング、パス長やファイルサイズの確認、差分移行、受入テストまで計画します。まず代表的な1部門や1フォルダでリハーサルを行い、件数、権限、検索性、利用者の操作を確認してから全体へ広げる方法が安全です。

Microsoft 365の設定経験だけでなく、SharePoint移行、Power Platform、権限・セキュリティ、API連携、テスト、教育、保守まで必要な工程を確認します。自社と似たデータ量や規制、移行元の実績があるか、成果物とソースコードを引き渡すか、担当者交代後も運用できるかを、同じRFPで2〜3社に質問します。

標準機能を優先し、対象業務を絞ったMVPから始めると、初期費用と保守負担を抑えやすいです。ただし、要件整理、権限設計、移行リハーサル、テスト、管理者教育を削ると、稼働後の手戻りが増えます。機能の削減ではなく、段階導入とライセンス・開発・移行・保守の分離で予算を管理します。

まとめ

SharePoint Onlineのシステム開発は、サイトを作成する作業ではなく、情報の正本、権限、業務フロー、移行、運用を一つの仕組みとして整えるプロジェクトです。要件整理でKPIと対象範囲を決め、標準機能、ローコード、カスタム拡張の順に選び、代表部門で検証してから段階的に広げます。

着手時は、（1）対象業務とKPI、（2）情報の正本と移行元、（3）サイトと権限の単位、（4）標準・Power Platform・カスタムの境界、（5）受入テストと切戻し条件、（6）稼働後の所有者と保守範囲を確認します。特に権限、外部共有、退職者アカウント、サイト所有者の交代を後回しにしないことが、長期運用のポイントです。

費用は、ライセンス、構築、移行、追加開発、教育、保守、追加容量・監査サービスに分けます。設定中心なら20万〜60万円程度、部門業務アプリなら100万〜500万円程度、移行・全社ポータルなら300万〜1,000万円程度、大規模な連携・統制なら1,000万〜3,000万円以上というレンジが予算検討の出発点です。公開統計ではなく、対象ユーザー数、容量、移行難度、権限、連携、教育の前提で変わる推定値であることを忘れないでください。

見積もりを比較するときは、安さではなく、要件整理から定着までの抜け漏れと、納品後に自社で運用できるかを確認します。まずは対象部門と業務を絞ったPoCやMVPから始め、利用状況と課題を見ながら、無理のない順番でSharePoint Onlineのシステムを育てていくことが成功への近道です。

▼全体ガイドの記事
・SharePoint Onlineのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。