【完全ガイド】リコー文書管理システム から Box・Microsoft 365・kintone・Google Workspace への移行戦略

本記事は、リコーの複合機（MFP）と一体で導入した文書管理システム（RICOH Streamline NX、Ridoc Document System、RICOH eドキュメント）を10年以上運用してきた中堅企業（500〜2,000名）で、「次の文書基盤をどうするか」を経営に答える総務部長／情シス部長を読者として書きました。複合機からのスキャン → 自動振り分け → 部門ライブラリの仕組みを継承しつつ、リモートアクセス・電帳法・全文検索を実現する移行設計の本音材料を整理します。

1. 「リコー系文書管理はまだ動くのに動かす議論が出る」5つの理由

リコー系文書管理は継続提供されており、製品が消えるわけではありません。それでも次の3年で動く議論が出る理由は次の5つ。

① リモート／在宅で社内文書にアクセスしたい。VPN経由のオンプレ参照では遅い／不便。
② 電子帳簿保存法／インボイス制度の検索要件への継続対応負担。
③ M365／Google Workspace への統合。SharePoint／Drive と分断していると検索が二重化。
④ オンプレサーバーの更改負担。5年に1回 数百万〜1,000万円。
⑤ 情報漏洩対策の高度化。MFA・条件付きアクセス・DLPを全社統一したい。

2. 三択の整理：リコー継続／クラウド全面移行／部分置換

3. 移行候補の本音比較

4. 複合機スキャン運用の継承設計

移行で最大の論点はここです。リコー系の文書管理は、複合機（MFP）からのスキャン → 自動分類 → 部門共有の一気通貫が強みでした。SharePoint／Box／DocuWare はリコー／キヤノン／富士フイルムBI／コニカミノルタなどの複合機からの直接スキャン投入に対応していますが、設定の作り込みが必要です。

具体的に設計するもの：
・複合機側の設定：スキャン先（クラウドストレージ）、認証方式（社員カード／PIN）、ファイル命名規則
・クラウド側のライブラリ設計：スキャン受信フォルダ、自動分類ルール、メタデータ自動付与
・OCR処理：スキャン直後にOCRをかけるか、後追いか
・承認フロー：スキャン後に承認が必要な文書（請求書・契約書）のフロー設計

複合機側の設定変更は、リコー保守と並走で進めないと止まります。「複合機運用の継承」を移行プロジェクトの第1フェーズに置きます。

5. 文書ライブラリ・フォルダ階層の再設計（最大の落とし穴）

移行で最大の落とし穴は、オンプレ時代の深いフォルダ階層をそのままコピーすることです。SharePoint／Boxは「メタデータ＋検索」が本質で、深い階層はアンチパターンです。

具体的な再設計指針：
・SharePointの階層深度は3層以内に抑える（サイト→ライブラリ→フォルダ）
・「年→部門→種別→案件→ファイル」のような深い階層をやめる。代わりにメタデータ（年・部門・種別・案件）でフィルタする設計に
・ライブラリ単位で権限を分ける。フォルダ単位の権限はメンテ不能
・検索しやすい命名規則を全社標準化（取引先＋日付＋種別）

6. 電子帳簿保存法・インボイス対応の必須要件

電子取引データの保存要件（真実性・可視性・検索性）を満たすため、次の機能を必ず実装します。

・取引年月日・取引金額・取引先名での検索
・タイムスタンプまたは改ざん検知の代替措置
・適格請求書発行事業者番号での検索
・保存期間管理（7年・10年・永久）と自動削除／保留

国税庁の電子帳簿保存法 一問一答の最新版を踏まえ、各候補SaaSの対応状況を比較します。DocuWareは電帳法対応の実績が厚く、SharePointはPower Automate ＋ SharePoint メタデータで設計が必要、Boxは Box Skills と組み合わせます。

7. OCR・全文検索の実装

過去スキャン文書の活用は、OCR＋全文検索が肝です。

・SharePoint：標準OCR（精度はそこそこ）／Premium 版で日本語精度向上
・Box：Box Skills でOCR連携／追加コスト
・DocuWare：標準で高精度OCR・帳票テンプレ認識
・外部OCR：ABBYY FineReader／Adobe Acrobat OCR／専用OCR API で補強

日本語OCR精度はSaaS標準では帳票によって差が出るため、業務上重要な帳票（請求書・契約書）でPoC を実施してから本番化します。

8. 既存スキャン文書の移行範囲

既存のスキャン文書（数十万〜数百万ファイル）を新システムに持ち込む場合、「全件移行」は失敗の典型です。実務では次の3階層で持ち込み範囲を切り分けます。

・直近2〜3年：新システムへ移行（メタデータ自動付与）
・3〜10年前：法定保存対象のみ移行、それ以外は旧システムを2〜3年参照系として残す
・10年超：法定保存対象のみアーカイブ、それ以外は削除

移行ツール（ShareGate、Migration Manager、Box Migration Service 等）でフォルダ構造をメタデータに変換しつつ、検索性を確保します。

9. ワークフロー（回覧・承認）の再設計

リコー系で稼働している回覧・承認フローは、次の選択肢で再現します。

・SharePoint＋Power Automate：M365統合・標準で多くを実装可能
・Box Relay：Box内で完結する承認フロー
・DocuWare 標準ワークフロー：文書中心の承認に特化
・kintoneのプロセス管理：業務台帳との一体化

移行前に稼働中ワークフローの棚卸しを必ず実施し、「使われていないフロー」を廃止します。経験上、半数以上が廃止可能です。「全部移行」を目指すと費用も運用負荷も爆発します。

10. プロジェクト期間の典型値（500〜2,000名規模）

11. 3年TCOの実数試算（1,000名規模）

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

① 深いフォルダ階層をそのままコピー。オンプレ時代の10階層構造をSharePointに持ち込み、検索性が悪化、現場が「使えない」とローカル保存に逃げる。
② 全件移行を目指して費用爆発。10年分の数百万ファイルを移行する見積もりで予算化し、結局直近3年だけに絞り直して再見積もり。3カ月のロス。
③ 複合機側の設定変更を後回しにして二重保管。新システムに移行したつもりが、複合機からのスキャンは旧システムに送り続けられ、結果的に両方に文書が貯まる事態。

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

① 文書ライブラリ・フォルダ階層の現状棚卸しを総務主導で開始する。「使われている／いない」「アクセス頻度」を集計し、再設計の材料にする。
② SharePoint／Box／DocuWare の3社からアセスメント提案を取る。複合機連携・電帳法対応・OCR精度を、自社業務でPoCする。
③ 複合機側の設定変更可否をリコー保守に確認する。新システムへのスキャン投入が技術的に可能かを早期に握る。

リコー系文書管理の今後3年は、「動かすか・据え置くか」を根拠付きで経営に提示できる状態を作ることがゴールです。複合機運用の継承設計と、ライブラリ再設計が、議論の質を決めます。