NotesからMicrosoft 365へ：SharePointにすべて移せるのか
NotesからMicrosoft 365への移行を考える際、「NotesのデータベースをSharePointへ移せばよい」と捉えると、見積もりや設計を誤る可能性があります。同じNotesデータベースでも、文書を共有するものと、承認・計算・外部連携を担う業務アプリでは、移すべき対象が異なるためです。
移行の起点は、製品同士を一対一に対応させることではなく、現在のアプリが提供している機能を分解することです。文書、画面、処理、データ、権限を整理し、それぞれに適した移行先を検討します。
本記事では、Notes／Domino上の業務アプリと共有データを対象にします。メール・カレンダーの移行は、別の計画として扱う必要があります。
Notesの「文書」には、業務の状態が入っている
見た目が帳票のようなフォームでも、入力に応じた計算、必須項目の判定、承認者の選択、定期的なデータ更新などが含まれている場合があります。Notes／Dominoでは、エージェントによる処理の自動化も可能です。そのため、文書を抽出するだけでは、アプリの動作までは引き継げません。
最初の棚卸しでは、名称や件数に加えて、次の内容を確認します。
フォーム、ビュー、数式、LotusScript、エージェントなどの設計要素
利用部門、業務責任者、利用頻度、繁忙期、廃止できる条件
添付ファイル、リッチテキスト、文書リンク、親子関係、過去版の必要性
ACL、ロール、Readers／Authorsフィールドなどのアクセス制御
定期実行、通知、外部システムとの送受信、オフライン利用や複製の要否
「最近更新されていない」というだけで、不要とは判断できません。年次業務の参照資料や、契約・監査の証跡として必要なデータもあります。反対に、現在の利用者がいないアプリを、現役アプリと同じ費用で作り直す必要もありません。
SharePointとPower Platformの役割を分ける
移行先・構成要素 | 主に担う役割 | 移行時に確かめること |
SharePoint | 文書共有、ライブラリ、リスト、ポータル | メタデータ、検索、版管理、権限、一覧の設計 |
Power Apps | 入力・参照画面、操作に応じたアプリの振る舞い | 利用者の操作、入力検証、データ取得、委任、端末対応 |
Power Automate | 承認、通知、定期実行、サービス間の処理連携 | 実行期間、再試行、重複防止、例外対応、接続の所有者 |
Dataverse | 業務データ、テーブル間の関係、データに対する権限管理 | データモデル、セキュリティ、監査、容量、ライセンス |
別の業務アプリ・API | 複雑な計算、大量処理、独自のトランザクションなど | 性能、一貫性、保守体制、連携境界 |
この表は、Notesの機能を機械的に置き換える対応表ではありません。同じ申請アプリでも、規模、承認期間、権限、連携先によって構成は変わります。
Power AppsはSharePointやDataverseなど複数のデータソースに接続できます。画面をPower Appsで作ることと、データをSharePointリストに置くことは、別々の設計判断です。
文書が中心ならSharePointを主軸にし、複数の関連データや複雑な権限を扱うならDataverseなども比較する。このように、必要な業務を起点に構成を決めます。
一覧が表示できても、業務データを正しく取得できるとは限らない
SharePointをデータ格納先にする場合、件数だけでなく、絞り込み、索引、列の種類、参照列、アクセス権の付け方まで確認します。
よく混同されるのが、リストの保存可能件数と、リストビューのしきい値です。SharePointで言及される5,000件のしきい値は、「リストには5,000件しか保存できない」という意味ではありません。大量データの検索・表示方法を設計する際の制約として扱います。
Power Appsでは、検索や集計をデータソース側に任せられるかという「委任」も重要です。委任できない処理では取得件数に上限があり、データが増えると、本来見つかるはずのレコードを取得できない場合があります。少量データで動いたことだけを根拠に、移行可否を決めないようにします。
検証では、本番相当の件数だけでなく、検索条件、ユーザーごとの可視範囲、繁忙期の同時利用を再現します。画面を開けることと、必要なデータを漏れなく処理できることを分けて評価します。
承認フローは、長期滞留と再実行まで設計する
Notesの承認ルートをPower Automateで再現するとき、承認が順に進む正常系だけでは不十分です。差し戻し、代理承認、承認者の異動、申請取消、途中の入力変更、連携先の停止をどう扱うかも決めておく必要があります。
たとえば、長期間承認待ちになる申請を、単一のフロー実行の中で待ち続ける設計には注意が必要です。Microsoftの公開仕様では、クラウドフローの実行期間は承認待ちを含めて30日とされています。長期案件では、業務の状態をデータとして保持し、次の処理を別の実行で再開できる構成などを検討します。実際に設計する際は、最新の制限を確認してください。
また、失敗した処理を再実行しても、通知や外部登録が二重に行われない設計が必要です。申請IDと処理状態を使って実行済みを判定する、再試行してよいエラーと担当者の確認が必要なエラーを分ける、といった方針を決めます。
業務上の承認履歴と、ツールが保存する実行ログも同じではありません。誰が、いつ、何を承認したかを、必要な期間保存できるようにします。
権限は「見え方」ではなく、アクセスそのものを検証する
Notesのアクセス制御を移す際は、データベース単位のACLだけでなく、文書単位のReaders／Authorsフィールドも確認します。HCLの資料でも、これらを文書に対するアクセス制御の要素として説明しています。
移行先でアプリの一覧を絞り込んだり、ボタンを非表示にしたりしても、それだけでデータへのアクセスを禁止したことにはなりません。直接URL、別のアプリ、API経由でも、許可されていない情報を取得できないかを確認します。
権限設計では、一般社員、上長、経理、代理承認者、退職者などの利用者像を設定します。組織変更や担当替えの前後で、過去文書へのアクセスをどう扱うかも決めます。添付ファイルだけが広く公開されるといった、本文と関連データの権限の食い違いがないことも確認します。
アプリごとに移行先と移行範囲を決める
仮の例として、同じ会社に次の三つのNotesアプリがあるとします。
アプリの例 | 検討する構成 | 先に検証したい点 |
社内規程・技術資料の共有 | SharePointのライブラリを中心に再編 | 分類、検索、文書リンク、版と権限の保持 |
部門内の備品申請 | Power Apps、Power Automate、SharePointリストなど | 承認の例外、件数、委任、運用担当者 |
契約・請求に関わる複雑な業務 | Dataverseや別の業務アプリを含めて比較 | 関連データ、厳密な更新、監査、外部連携、性能 |
備品申請でも、規模や条件によってはDataverseなどが適します。逆に、参照だけできればよい旧アプリは、更新機能を再構築せず、権限付きのアーカイブとして残す方法も考えられます。
データ移行では、本文や添付だけでなく、更新者・日時、文書ID、関連文書、アクセス制御の対応表を作成します。すべての履歴を同じ形式で再現できない場合は、どこに何を証跡として残すかを合意します。
移行後に誰が運用するかまで決める
低コードで開発できても、運用設計が不要になるわけではありません。開発・検証・本番の環境管理、変更の承認、フローの監視、接続アカウント、担当者が異動したときの引継ぎを決めます。
Microsoft 365の契約があれば、どのPower Platform構成でも追加費用なしで利用できるとは限りません。Dataverse、プレミアムコネクタ、実行形態など、実際の構成に基づいて契約を確認します。
株式会社ManagetechがNotes移行で重視するのは、文書の移送と、業務アプリの再設計を区別することです。残すべき業務ルールと権限を確認し、アプリごとに移行先・再構築・アーカイブ・廃止を判断することで、移行後も管理できる構成を目指します。
SharePointにすべて移せるかを考える前に、現在のNotesアプリが「何を保存し、何を判断し、誰に何を許可しているか」を整理する。その棚卸しから、移行計画を具体化できます。
製品の機能・制限に関する記述は、2026年10月6日時点の公式資料で確認した内容です。実装時には利用するプラン・環境・製品仕様を再確認してください。
コメント