【完全ガイド】Notes/Domino から Microsoft 365・kintone への移行戦略 2026：業務DB別の置き換えパターンとリプレース実務

本記事は、Lotus Notes 時代から数えて20年以上 Notes/Domino を使い続け、メール・カレンダー・掲示板・ワークフロー・顧客DB・契約管理など Notesアプリを100〜500本抱える企業で、「いつまで Notes を続けるのか」を経営に答える情シス課長／部長を読者として書きました。HCLの保守は続いているが、開発者枯渇とライセンス費の上昇、Edge IE モード廃止に伴うクライアントの問題、社員のM365／Google体験との乖離——その全部に同時に答える3年計画を、Notesアプリ仕分けの粒度で整理します。

1. 「HCL保守はあるのに脱Notesが急ぐ」本当の理由

Notes／Domino は HCL Software が買収後も投資を続け、Domino 12／14 系へとロードマップが伸びています。「製品が消える」ではないのに、いま急加速している理由は次の4つです。

① Notes／LotusScript／@式・Formula 言語の開発者枯渇。新規供給がほぼゼロで、改修1件あたりの単価が年々上がります。
② HCL ライセンス費の継続的な見直し。買収以降、CCB/CCXなどの計算方式変更があり、契約更新時に経営の関心が高まっています。
③ クライアント環境の制約。Notes クライアントの配布・更新運用、Webブラウザ完結要件（在宅・モバイル）、IEモード廃止後の影響などが重なります。
④ 社員体験の乖離。M365 ／Google を個人で使い慣れた社員にとって、Notesクライアントの体験は新人定着の障害になっています。

つまり「製品論」ではなく「人材・契約・端末・体験」の4点が同時に崩れてきている、というのが脱Notesの本当の急所です。

2. Notesアプリの「3つの数字」を最初に出す

移行議論を発散させないため、最初に次の3つを揃えます。

意外なのは、「NSF本数」のうち実際に活発に使われているのは2〜3割であることです。500本中350本が「過去1年間更新ゼロ」「アクセス月10件未満」というのが現実で、移行プロジェクトの本質は「全部移す」ではなく「何を捨てるか」です。

3. Notesアプリ仕分けの判定基準（5分類）

仕分けは抽象論ではなく、判定SQLが書けるレベルの基準で行います。Domino のアクセスログ、最終更新日、文書件数を集計し、次のいずれかに割り当てます。

500本のNotesアプリのうち、Cで再構築するのは100〜150本程度に収まる、という規模感を経営と最初に共有することで、移行費の見積もり議論が現実的になります。

4. メール／カレンダー移行の現実：3つの選択肢

メール／カレンダーは選択肢が成熟しており、技術的には大きな論点になりません。しかし「移行ツールの選定」と「カレンダーの繰り返し予定」の2点は必ず詰まります。

カレンダー移行で必ず詰まるのは「繰り返し予定の例外日付」「会議の代理出席」「会議室予約のリソースカレンダー」の3点で、パイロット部門で必ず検証してから本展開します。

5. Cの再構築：kintone か Power Platform かの判断軸

Notesアプリの大半は「フォーム＋ビュー＋ワークフロー」の構造で、これは kintone ／Power Apps＋Power Automate の最も得意な領域です。判断軸は次のとおり。

kintone を主軸にするのがフィットする条件：
・社内に開発者が薄く、業務部門で内製したい
・100〜300人規模のアプリで、レコード件数が10万件未満
・テーブル間連携は緩く、申請・台帳・議事録が中心

Power Platform を主軸にするのがフィットする条件：
・全社で M365 E3／E5を導入済（Power Apps の per-app／per-user の判断が必要）
・SharePoint／Dataverse とのデータ統合が前提
・Teams 内に業務アプリを埋め込みたい
・SSO／条件付きアクセス／DLPなど Entra 統制を全面適用したい

両方併用するケースもありますが、ガバナンス（命名規則・権限・運用）が二重化するため、主軸は1つに決めることを推奨します。

6. NotesアプリのCに移すときに必ず詰まる3点

① 「ビュー」の概念差。Notes のビューは複数のソート・カテゴリで動的に切り替わりますが、kintone／Power Apps はビュー定義を固定する設計です。Notes時代に20種類のビューを使い分けていたアプリは、移行時に5〜7種類に統合します。
② 添付ファイルの扱い。Notes は文書内に添付を持ち、ビュー上でアイコン表示する文化があります。kintone の添付フィールド／Power Apps＋SharePoint Document Library への置換時に、命名規則とメタデータを再定義します。
③ 承認の「代理・回議・差戻し」。Notes Workflow の独特の承認パスを kintone のプロセス管理／Power Automate の承認アクションで再現するには、承認パターンの統廃合が必要です。50種類の承認フローは10〜15種類に集約できるのが普通です。

7. 業務基幹のNotesアプリを kintone で再構築する誘惑を避ける

Notesアプリの中に「育ちすぎた基幹アプリ」（顧客管理／案件管理／契約管理／調達管理など）が含まれることがあります。これを kintone で再構築するのは短期的には早いですが、長期的には「またガラパゴス化」します。

判断基準は次の3つ：①レコード件数が10万件超／②全社で日次利用される／③外部システム（会計・受発注・基幹DB）と連携する——のうち2つ以上当てはまるなら、kintoneではなく Salesforce／Dynamics 365／業界専用パッケージを検討すべきです。「Notesから kintoneへ」を機械的に進めると、5年後に「kintoneから Salesforce へ」の二度目の移行を強いられます。

8. ID基盤・認証の刷新が裏の本丸

Notes 時代は「Notes ID」と「インターネットパスワード」が事実上の社内IDでした。脱Notesの本当の本丸は、Microsoft Entra ID／Google Identity を中心に据えるID基盤の刷新です。

具体的にやることは次の通り：
・Entra ID または Google Identity を Master とした SSO の確立
・全SaaS（M365／kintone／Salesforce／勤怠／経費）を SAML/OIDCで連携
・条件付きアクセス（端末準拠・場所・リスクレベル）と MFA の必須化
・退職者プロビジョニング自動化（人事システム → SCIM → 各SaaS）
・「Notes時代の野良権限」を一掃して再付与

ID基盤を後回しにすると、Notes時代の権限の混乱がそのままSaaS群に持ち込まれます。ID基盤刷新を脱Notesプロジェクトの第1フェーズに置くことを強く推奨します。

9. 過年度Notesデータの「凍結アーカイブ」

20年分のNotes文書をどうするかで、必ず議論が止まります。実用解は次の3階層です。

・直近3年：新システムへ移行（C）または読み取り可能な形で再構築
・3〜10年前：HTML／PDF にエクスポートし、全文検索可能なアーカイブシステム（M365 Purview／専用アーカイブSaaS／Confluence＋検索）に格納
・10年超：法定保存対象のみアーカイブ、それ以外は削除

元の Notes／Domino 環境はライセンス最小構成で2〜3年は読み取り専用として残置し、業務側からの「あの文書を出して」要望が落ち着いてから完全停止します。

10. 3年プロジェクトの典型進め方

「3年で終わらせる」前提を経営と握り、年1回の進捗レビューでアプリ廃止数の達成度を経営に報告する運用にすると、プロジェクトが長期戦でも失速しません。

11. 失敗事例から逆算する「やってはいけない3つ」

① 「Notesアプリを全件 kintone にコピー」を初期スコープに置く。500本全部をkintoneアプリ化する計画で予算化し、半年後に「使われていない」が大量発覚して再仕分け。
② メールだけ先行してアプリを放置。M365へのメール移行は半年で終わったが、Notesアプリは2年経っても残り、結果的にNotes／Dominoライセンスを払い続け、移行ROIが出ない。
③ ID基盤刷新を後回し。SaaS導入を先行した結果、各SaaSで個別IDが量産され、退職者の権限剥奪が手作業で残り、監査指摘の常連になる。

12. 来期予算化までに、いま動かす3アクション

① Domino サーバーから「3つの数字」を出す。NSF本数・直近12カ月の更新あり数・アクセスログ集計。1〜2週間で出ます。
② メール移行ツール3社（純正・Quest・BitTitan等）からPoCの見積もりを取る。ライセンス課金方式と、繰り返し予定・代理出席の対応状況を比較。
③ ID基盤刷新の独立プロジェクト化を経営に提案する。脱Notes本体の前段階としてEntra／Google Identity 整備を半年〜1年先行させると、後続が一気に楽になります。

脱Notes は「ツール置換」ではなく、「20年蓄積した業務の癖を仕分け、ID基盤と社員体験を全面更新する3年プロジェクト」です。3年で終わらせる覚悟と、3年かける覚悟の両方を、経営と最初に握ることが成否を決めます。