SharePoint Onlineの開発は、要件整理から利用定着まで6つのフェーズで進めます。テストや段階的な稼働を経て定着へ進むことで、情報と業務を無理なく運用できます。
全体像はSharePoint Onlineのシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・SharePoint Onlineのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SharePoint Onlineのシステム開発の全体像
SharePoint Onlineは、Microsoft 365上で動くクラウド型の情報共有・文書管理・社内ポータル基盤です。TeamsやOneDriveと接続し、情報の入口と業務データの管理場所を組み合わせる土台で、単なるファイル置き場ではありません。
SharePoint Onlineで構成できる業務システム
SharePointでは、次のような業務システムを構成できます。
- 社内ポータル：サイトやニュースで部門の情報を集約
- 文書管理：ライブラリでの版管理と承認
- 軽量な業務データ：リストで台帳や申請状況を扱う
ポータルは、ページ、ニュース、検索、ハブサイトを組み合わせて作ります。また、文書管理では、メタデータや共有リンクも設定できます。
リストは、問い合わせ台帳、備品管理、案件一覧にも使えます。入力画面にはPower Apps、通知や承認の自動化にはPower Automateが候補になります。
複数テーブルの関係、細かな権限、厳密なトランザクションが必要なデータは、DataverseやSQLに分けます。そのため、SharePointを文書やポータルに集中させると、無理な作り替えを避けやすくなります。
Teams・OneDrive・Power Platformとの役割分担
まず、情報をどこへ保存するかを決めておきます。たとえば、Teamsのチームに紐づくファイルは、SharePointのライブラリに保存されます。
- OneDrive：個人の作業中ファイルを置く場所
- SharePoint：部門や全社で共有する正式文書の保管先
- Power Platform・Dataverse・SQL：入力・処理の連携と、複雑なデータ管理
Power Appsは入力画面、Power Automateは通知や承認の自動化に使います。この整理をせず「SharePointだけで全部作る」と、リストの行数、権限例外、フロー所有者、検索精度が問題になりやすいです。
2026年に確認したいライセンスと開発モデル
ライセンスを検討するときは、次の4つの点を確認します。
- 表示価格：プランごとのユーザー月額
- 契約条件：税や既存契約を含めた見積もり
- 販売方針：単体プランの終了時期
- 新規案件：スイートや追加容量との比較
Microsoft公式比較ページでは、SharePointプラン1は年払いで1ユーザー月額749円相当です。また、Microsoft 365 Business Standardは2,098円相当です（出典：Microsoft公式「SharePointのプランと価格の比較」、2026年8月確認）。
金額は、契約形態、税、地域、価格改定、既存契約によって変わります。そのため、予算の仮説として扱い、発注時の見積もりで改めて確認します。
Microsoftは2026年1月、単体プラン1・2の終了方針を示しました。新規販売は2026年6月に終了します。更新は2027年1月以降、サービスは2029年12月に終了する方針です（出典：Microsoft Learn「2026年1月のお知らせ」、2026年確認）。
新規案件では、Microsoft 365スイート、追加ストレージ、既存テナント契約を比べます。
SharePoint Onlineのシステム開発の進め方
導入では、まず業務と情報の現状を整理し、サイトはその後に作ります。そのうえで、小さく検証し、移行や運用も含めて段階的に展開します。
開発は6つのフェーズに分け、各フェーズで成果物と判断基準を具体化します。
フェーズ1：要件整理（正本・KPI・対象範囲）
要件整理では、改善目的と対象範囲を、次の4つの観点で定めます。
- 改善目的：何を変えるのかをはっきりさせる
- KPI：検索時間や申請日数を測る
- 情報資産：正本や移行元を洗い出す
- 完了条件：対象範囲と受入条件を文書にまとめる
KPIには、紙やメールを減らす業務やポータルの利用率も含めます。目標値と測り方もあわせて定めます。たとえば、検索時間を何分短縮するか、申請処理を何日から何日にするかをKPIにします。
目的を「SharePointを使うこと」にしてしまうと、完成後に成果を判定できません。
既存の情報の置き場所は、まずファイルサーバー、SharePoint Server、Notesから洗い出します。次に、ExcelとTeams、OneDriveを確認します。既存データベースも洗い出します。
対象ごとに、正本、所有部門、更新者を一覧にします。そのうえで、保存期限と個人情報の有無、利用頻度を書き込みます。移行の可否と現行の権限も、同じ一覧に残します。
同じ規程が複数箇所にある状態や、退職者が所有するフローといった例外も見つけておきます。完了時には、ユーザー数、移行元、容量を文書にまとめます。あわせて、主要業務、外部共有、保存・廃棄ルールを書き、連携と運用責任者も記載します。
要件定義書に加えて、サイト一覧、権限一覧、移行対象一覧を作ります。さらに、非機能要件と受入条件を定めておくと、後工程で追加請求が出る場面を減らせます。
フェーズ2：標準・ローコード・カスタムの選定
技術選定では、標準機能、ローコード、カスタム拡張の順に検討します。
- 標準機能：標準Webパーツやリストで要件を満たす
- ローコード：不足する入力や承認を補う
- カスタム拡張：API連携や複雑な処理向け
ローコードには、Power AppsやPower Automateなどがあります。カスタム拡張では、SPFx、Microsoft Graph、Azure Functionsなどを使います。
標準機能で要件を満たせるなら、追加のコードを避けます。そうすると、更新への追随や担当の交代が容易になります。入力の使いやすさや承認条件が足りない場合は、Power AppsやPower Automateで補います。
外部API連携や独自画面、複雑な処理が絡む場合は、SPFxやAzureを検討します。
実装の速さだけでなく、運用の面も確認します。環境分離、Solutions配布、DLPの扱いを見ます。フロー所有者の交代、ソースコードの引き渡し、障害対応の責任も含めます。
2026年時点では、古いSharePoint Add-inを新規に採用しません。Microsoft Learnは、2026年4月2日の全テナントでの終了と、代替モデルのSPFxを案内しています（出典：Microsoft Learn「SharePoint Add-In retirement in Microsoft 365」、2026年確認）。
既存の資産がある場合は、現状調査と移行計画を見積もりに含めます。
フェーズ3：情報設計と開発
情報設計では、構成単位、権限、移行対象を、この順に決めます。
- 構成単位：サイトやライブラリの設計
- 権限：グループを基本に、例外を減らす
- 移行対象：不要データや重複の整理
構成単位は、組織変更の頻度と権限の境界を基準に選びます。あわせて、情報のライフサイクルと検索性も見ます。
サイトが部門ごとに増えないよう、設計書にはサイト名、URL、所有者を書いておきます。
そのほか、メンバーと閲覧者、命名規則を記載します。メタデータや版管理などの運用ルール、承認、保持期間も書いておきます。
権限は、サイトやライブラリの設計と同時に決めます。そのうえで、基本はMicrosoft Entra IDやSharePointのグループを使い、個別ファイルの例外権限を減らします。
外部ユーザーやゲスト、匿名リンクの扱いも設計します。退職や異動の際の削除、所有者がいない場合の交代手順も決めておきます。
移行時は、重複や不要な版、長すぎるパスを整理します。機密情報や所有者が分からないデータも、整理の対象です。
なお、Microsoft Learnによると、アップロード上限は1ファイル250GBです。ファイルパス全体は400文字、リスト・ライブラリは最大3,000万件です（出典：Microsoft Learn「SharePointの制限」、最終更新2025年11月）。
ただし、上限まで使えることと快適に使えることは別です。検索、同期、権限を実測します。
フェーズ4：機能・権限・移行のテスト
テストでは、次の4つの面から確認します。
- 利用者操作：検索や承認が想定どおりに動くか
- 管理者操作：権限やフローの管理を試す
- 移行結果：件数や権限を移行前後で照合
- 受入条件：利用部門による合格の判定
代表ユーザーには、検索、閲覧、編集、版戻しを試してもらいます。承認、通知、モバイル利用も試し、想定した権限と結果になるかを確かめます。確認では、画面が開くことより、権限と結果が想定どおりかを見ます。
管理者は、サイト作成や所有者の交代、グループ変更を試します。さらに、外部共有の申請、監査ログの確認、フロー失敗時の再実行も確かめます。
移行前後では、クレンジング後の件数、ファイル名、メタデータを照合します。更新日時や版、所有者も照合し、権限とリンク切れも確かめます。代表部門のデータでリハーサルし、差分移行時間、停止時間、失敗時のロールバックを確定します。
サイト間の移動やコピーには、合計100GB、ファイル数30,000個以下という制限があります。そのため、移行単位とツールを先に検証します（出典：Microsoft Learn「SharePointの制限」、2026年確認）。
制限に近い環境では、夜間の差分処理に加えて、失敗したファイルの再処理方法も確かめます。受入テストでは、利用部門が合格条件に署名できる状態を整えます。
フェーズ5：段階的な稼働
稼働は段階的に進め、検証後に次の部門へ広げます。
- 小さく開始：代表部門や1業務からの切替
- 切替作業：差分移行と権限確認
- 稼働判定：検索、承認、連絡体制の確認
最初の部門では、検索と承認、権限を検証します。移行と問い合わせ対応も見たうえで、手順を直してから次へ進みます。
全社ポータル、文書管理、申請アプリを一度に始めると、どこでつまずいたのか分かりにくくなります。優先順位をつけて展開します。
切替当日は、旧環境の編集停止、最終差分移行、件数照合を順に行います。続いて、権限確認、利用案内、問い合わせ窓口の開設を進めます。旧環境は参照専用や一定期間の保管とし、切戻し基準を決めます。
稼働判定では、重大な権限不備がないこと、重要文書を検索できること、承認フローが完了することを確認します。加えて、管理者が障害時の連絡先を把握していることも条件になります。
フェーズ6：利用定着とガバナンス
定着とガバナンスでは、次の4つを続けて行います。
- 利用状況：利用率や問い合わせの追跡
- 管理会議：サイトと権限を見直す
- 共有監査：外部共有や招待の確認
- 仕様変更：通知方法と引継ぎの見直し
稼働後は、利用率や検索で見つからない語句、未使用サイトを定期的に確認します。古い共有リンクや外部ゲスト、容量も見ます。加えて、失敗フローや問い合わせ件数も追います。
月次の管理者会議では、サイトの新設や廃止、所有者の変更、権限の見直しを扱います。四半期ごとには、情報設計とKPIを見直します。
Microsoft Purviewの共有監査では、共有相手やリソースを確認できます。招待の作成・承諾、匿名リンクの作成なども確認できます（出典：Microsoft Learn「監査ログで共有監査を使用する」、最終更新2026年6月）。
個人情報や機密文書では、保持期間やDLP、秘密度ラベルを法務・情報システムと確認します。あわせて、監査機能のライセンスを確認します。共有設定後の監査も必要です。
2026年7月以降、SharePointアラート機能の削除が案内されました。通知にはルールまたはPower Automateを使う方針です（出典：Microsoft Learn「ユーザーがSharePointアラート通知を受信しない」、2026年確認）。
既存環境でアラートを使っている場合は、まず対象を洗い出します。そのうえで、代替フローと所有者交代の手順も用意します。
SharePoint Onlineのシステム開発の費用相場
費用はライセンスや初期構築、移行で分けて考えます。さらに、追加開発と教育、保守も別々に見積もります。
SharePoint Onlineだけの公的な開発費の平均統計はありません。ここに示すのは予算検討用のレンジで、個別案件の確定額ではありません。Microsoft公式価格、国内ベンダーの公開支援価格、業務システムの一般的な工数をもとにしています。
ライセンス費用と既存契約の重複
ライセンス費用は、次の3つの点から見ます。
- 表示価格：人数と契約期間をもとにした費用
- 既存契約：機能の重複購入を避ける
- 将来費用：追加機能や移行余地との比較
SharePointプラン1を100ユーザーで使う場合、月額7万4,900円、年額89万8,800円相当です。これは年払い価格の単純計算で、税と契約条件は含みません。追加容量やサポート費も入っていません。
Microsoft 365 Business StandardやEnterpriseには、SharePoint機能が含まれる場合があります。そのため、人数分を重ねて買っていないかを確認します。
2026年は単体プランの販売・更新方針が変わるため、見積書には、SKU、人数、契約年数を明記します。加えて、既存ライセンスの機能と、追加ストレージやPower Appsプレミアムコネクタの要否も明記します。
月額だけでなく、契約期間中のTCO（総所有コスト）と将来の移行余地で判断します。
初期構築・移行・追加開発の目安
初期構築の費用と期間は、対象規模や移行・連携の範囲で変わります。
- 設定中心：20万〜60万円程度、2〜6週間
- 部門ポータル：100万〜500万円程度、1〜3か月
- 全社ポータル：300万〜1,000万円程度、2〜6か月
- 大規模連携・統制：1,000万〜3,000万円以上
設定中心の範囲は、1〜2サイトと基本権限です。標準ページと管理者説明までを含みます。
部門ポータルでは、リストとPower Automateの承認・通知を加えます。さらに、簡単なPower Appsと受入テストも含めます。
全社ポータルでは、ファイルサーバー、SharePoint Server、Notesからの移行を含みます。あわせて、メタデータ変換や権限に加え、検索設計と教育も含めます。
複数拠点や基幹API、Dataverse・Azure・Purviewを含む場合や、厳格な監査、段階展開を伴う場合は、期間が6〜12か月以上になる可能性があります。
これらの目安は、クラウドの標準機能でサーバー構築費を抑える一方、移行・権限・教育・連携の工数が残る前提にしています。リサーチノートの業務システム相場から推定したものです。
株式会社コムデックの公開価格では、SharePoint Onlineサポートが月5,000円、Microsoft 365サポートが月20,000円です。小規模な運用支援の参考値で、開発や大規模移行とは別の数字です（出典：株式会社コムデック公開価格、2026年確認）。
保守・教育・追加容量のランニングコスト
ランニングコストは、保守、教育、追加サービスに分けて見積もります。
- 保守：対象作業とサポート時間をもとにした見積もり
- 教育：管理者と一般利用者で分ける
- 追加サービス：契約外の機能にかかる費用
保守作業には、問い合わせ対応、サイトと権限の見直し、所有者変更があります。さらに、フロー監視と容量確認を含みます。仕様変更対応や軽微な改修も含まれます。
一般的な業務システムでは、初期開発費の年15〜25％程度、または月15万〜80万円程度を目安にする方法があります。SharePointでは、ユーザー数とサポート時間を基準に見積もり直します。
管理者向け教育では、サイト作成と権限、保持と監査を扱います。あわせて、フローの引継ぎも扱います。
一般利用者には、検索、メタデータ、版管理を説明します。共有と申請も説明します。操作ガイドやFAQ、問い合わせ一次切り分け表も成果物に含めると、定着の助けになります。
バックアップや監査、DLPは、契約によって別費用になる可能性があります。秘密度ラベルや追加ストレージ、Power Appsのプレミアム機能も、契約によっては別費用になることがあります。
見積もりでは、ライセンス、構築、移行を分けて書きます。教育、保守、追加サービスも分け、初年度と2年目以降を並べます。
SharePoint Onlineの見積もりを取る際のポイント
安さだけで発注先を決めると、要件整理や移行リハーサル、権限テストが省かれ、稼働後に追加費用が生じやすくなります。そこで、対象範囲と成果物をそろえ、ライセンスと作業費を分けて比較します。
RFP・依頼書の対象範囲
依頼書には、見積もりの前提となる次の4点を盛り込みます。
- 対象範囲：利用者や拠点、移行元、容量の記載
- 非機能要件：権限や監査の条件
- 納品物：設定や運用手順の指定
- 受入条件：確認できる合格基準
対象ユーザー数、拠点、既存のMicrosoft 365契約を書きます。加えて、移行元と容量、ファイル数を記載します。サイト数や業務も書きます。
外部共有、個人情報、保存期間を明記します。検索条件とAPI本数、モバイルも書き添えます。SLAや教育、保守期間も明記します。
ファイル数や容量が不明なら、先に現状調査を依頼します。調査費と本構築費は分けます。
機能以外にも、最小権限や外部共有の申請制を明記します。監査ログの保持期間、障害時の連絡時間、所有者交代の手順も書きます。
設定ファイルとPower PlatformのSolution、SPFxのソースコードを納品対象にします。移行スクリプトや運用手順も含めます。
受入条件は、確認できる形で書きます。たとえば、重要文書の検索、部門ごとの閲覧範囲、代理者を含む承認などです。移行前後の件数と権限、管理者によるサイト新設・廃止も、確認できる条件として書きます。
複数社の同じ条件での比較
同じRFPを候補各社へ渡し、対応範囲と技術経験を比べます。見積条件や公開価格も比較します。
- 対応範囲：工程ごとの支援内容
- 技術経験：移行や開発の実績
- 見積条件：工数や除外、納品物の中身
- 価格例：対象範囲をそろえたうえでの判断
対応範囲は、要件整理から保守までの各工程で確認します。移行実績やPower Platformの設計力を比べます。SPFxやAPIの開発体制、権限・セキュリティの経験も見ます。
担当者の資格だけでなく、移行後の運用とサイト乱立の防止を質問します。さらに、担当交代と障害時の復旧責任も尋ねます。
作業項目ごとの工数、前提条件、対象外を確認します。追加変更の単価や納品物、検収条件も見ます。保守時間帯とSLAも確認します。
「データ移行一式」と一行だけ書かれていると、含まれる作業が見えません。そのため、移行対象の除外条件と、利用部門が行うクレンジングも書いてもらいます。
公開価格も比較材料になりますが、優劣は価格以外も含めて判断します。たとえば、Microsoft 365全体の導入支援は50万〜200万円、SharePoint・Teams導入支援は20万円程度といった公開例があります。
公開例にはExchangeなどが含まれることがあるため、個別のSharePoint開発費とは一致しません。対象範囲をそろえて、2〜3社程度から提案を受けます。
失敗しやすいリスクと契約前の確認
契約前には、次の4つのリスクを確認します。
- サイト：目的や所有者、廃止条件を定める
- 移行：権限やメタデータを照合する
- フロー・共有：引継ぎと監査のルール
- 成果物：納品後の運用に必要な資料
サイトを作りすぎると、どれが最新版か分からなくなります。そのため、作成権限は絞り、目的と所有者、廃止条件を決めます。命名規則も揃えます。
移行後に権限やメタデータが壊れることもあります。そのため、作業には対象の洗い出しと権限マッピングを含めます。あわせて、サンプル・差分移行や件数照合も行います。
特定の作成者に頼らないよう、接続情報や所有者、代理管理者を文書に残します。さらに、失敗通知先、再実行手順、環境別設定も記録します。Solutionsやソースコードも納品対象にします。
外部共有では、ゲストの在籍確認、匿名リンクの禁止または期限、監査ログの定期確認を運用ルールにします。
成果物には、設定値、設計書、権限一覧を含めます。テストの仕様と結果、移行ログも入れます。切替やロールバックの手順、管理者マニュアル、FAQも揃えます。
Power PlatformのSolution、SPFxのソースコードとライセンス、保守窓口も確認します。納品後に自社で運用できる状態が開発完了です。
SharePoint Onlineのシステム開発でよくある質問
導入前によくある質問を、SharePointの役割、移行、開発会社の選び方、費用の順に取り上げます。自社の業務に合わない構成を避ける手がかりになります。
SharePoint Onlineではどのようなシステムを作れますか？
社内ポータル、文書管理、規程・ナレッジ検索を構成できます。申請台帳や案件一覧、問い合わせ管理、承認・通知も構成できます。
一方で、複雑なリレーションや大量トランザクションを持つ基幹業務はDataverseやSQLに分けます。SharePointは、文書やポータル、軽量な台帳に使うと安定します。
ファイルサーバーからSharePoint Onlineへ移行できますか？
移行はできますが、単純なコピーでは不十分です。不要データや重複を整理したうえで、メタデータと権限、パス長を計画します。ファイルサイズや差分移行、受入テストも計画に含めます。
まず代表的な1部門や1フォルダでリハーサルします。件数と権限、検索性を確認し、操作も確かめてから全体へ広げます。
SharePoint Onlineの開発会社は何を基準に選ぶべきですか？
Microsoft 365設定に加え、SharePoint移行とPower Platformの経験を確認します。権限・セキュリティの経験も見ます。API連携の経験も対象で、テストや教育、保守の経験も含めます。
似たデータ量や規制、移行元の実績があるかも確認します。成果物やソースコードの引き渡しも確かめ、担当が交代した後に運用できるかを、同じRFPで2〜3社に質問します。
SharePoint Onlineの開発費用を抑える方法はありますか？
標準機能を優先し、対象業務を絞ったMVP（Minimum Viable Product）から始めると、初期費用と保守負担を抑えやすくなります。
要件整理や権限設計、移行リハーサルを削ると、稼働後の手戻りが増えます。テストや管理者教育を削ると、後から手直しが必要になる場面も増えます。機能は段階的に導入し、ライセンスや開発、移行の費用を分けて予算を管理します。保守も別に見ておきます。
まとめ
SharePoint Online開発では、情報の正本と権限を、業務フローや移行、運用とつなげて一つの仕組みに整えます。進め方としては、KPIと対象範囲を決め、標準、ローコード、カスタムの順に選び、代表部門で検証して段階展開します。
最初に確認する6項目
着手時には、対象業務とKPIを確認します。あわせて、正本と移行元、サイトと権限の単位、標準・Power Platform・カスタムの境界も見ます。
受入テストと切戻し条件、稼働後の所有者と保守範囲も決めます。権限や外部共有、退職者アカウント、所有者交代を早めに扱うことが、長期運用の要点です。
費用のレンジと前提条件
費用は作業と規模ごとのレンジで捉え、前提条件を確認します。
- 設定中心：20万〜60万円程度
- 部門アプリ：100万〜500万円程度
- 全社ポータル：300万〜1,000万円程度
- 大規模連携・統制：1,000万〜3,000万円以上
費用は、ライセンスや構築、移行で分けて考えます。追加開発、教育、保守、追加容量・監査サービスも、別に見ておきます。
いずれも、ユーザー数や容量、移行難度による推定値です。権限や連携、教育の条件によっても変わります。
見積もりでは、安さより要件整理から定着までの作業と、自社で運用できる成果物を確認します。部門と業務を絞ったPoCやMVPから始め、利用状況と課題に応じて段階的に育てます。
▼全体ガイドの記事
・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を創業。