ToolShellからサポート終了まで：SharePoint移行のタイムラインは今すぐ始まる
ToolShellエクスプロイトチェーンは、単なるパッチが必要なセキュリティ脆弱性以上の意味を持ちます。これは、中国の脅威グループLinen TyphoonおよびViolet TyphoonがSharePointサーバーを侵害し、暗号鍵を窃取して永続的なネットワークアクセスを確立することで、国家レベルの攻撃者がオンプレミスのコラボレーション基盤を標的とする手法に根本的な変化をもたらしたことを示しています。このアクティブな悪用キャンペーンと、Microsoftの2026年7月14日の延長サポート終了期限が重なることで、多くの組織が大幅に過小評価している厳しいスケジュールが生まれています。
計算は単純ですが、容赦ありません。現実的なSharePoint移行には、初期評価から本番展開完了まで12〜18か月を要します。2025年11月時点でサポート終了まで残り20か月しかないため、今四半期を過ぎて計画を開始すると、意思決定の拙速化や予算制約、あるいは移行作業に追われながらサポートのないインフラを運用する事態に直面します。本記事では、予算サイクルやベンダー評価の複雑さ、実際の移行現場の現実を踏まえたマイルストーンベースのスケジュールを提示します。楽観的なベンダーの見積もりではありません。
エグゼクティブサマリー
主旨：Microsoftの2026年7月14日サポート終了前にSharePointオンプレミスから移行を成功させるには、今すぐ計画を開始し、12〜18か月にわたる5つのマイルストーンを段階的に進める必要があります。予算サイクル、徹底したベンダー評価、段階的な展開、ユーザー定着化など、スケジュール上圧縮できない要素を考慮しなければ、セキュリティ・コンプライアンス・業務継続性に重大なリスクを招きます。
なぜ重要か：2025年末や2026年初頭にSharePoint移行計画を始める組織は、重要な評価・計画フェーズを急いで進めるか、拙速な移行でセキュリティカバレッジのギャップを許容するか、移行完了まで脆弱でサポートのないインフラを運用するかという、いずれも困難な選択を迫られます。ToolShellのアクティブな悪用とサポート終了期限の接近により、来年度の予算サイクルや意思決定の先送りという余裕は失われています。
主なポイント
- ToolShellはアーキテクチャ上の脆弱性を示す：SharePointオンプレミスを標的としたこのエクスプロイトチェーン（CVE-2025-53770、CVSS 9.8）は、暗号鍵を窃取し永続的なアクセスを確立する高度な国家レベルの手口であり、レガシーなオンプレミスアーキテクチャではパッチだけで十分に対処できません。
- 移行には最低12〜18か月を要する：多くの組織は移行スケジュールを6〜12か月過小評価し、要件定義、ベンダー評価、コンプライアンス検証、段階的展開、分散環境でのユーザー定着化などを見落としがちです。
- 予算サイクルがスケジュール圧力を増大：2026年度の予算が確保できていない組織は、プロジェクト開始が2026年中盤以降となり、完了が2027年以降にずれ込みます。これは2026年7月14日のサポート終了を大きく超えます。
- 5つの重要なマイルストーンは圧縮不可：評価・要件定義、ベンダー評価、計画・設計、パイロット展開、本番移行の各フェーズには、セキュリティギャップや業務障害を生まずに成功させるための固有の期間が必要です。
- 2025年11月開始でも既に遅い：サポート終了まで20か月、移行に12〜18か月必要なため、今始めても予期せぬトラブルや遅延へのバッファは最小限です。
ToolShellの理解：なぜ移行計画が根本から変わるのか
ToolShellは、一般的な脆弱性とは範囲も意図も異なります。中国の国家レベルのグループがSharePoint Serverを標的に開発したこのエクスプロイトチェーンは、CVE-2025-53770、CVE-2025-53771、CVE-2025-49704、CVE-2025-49706などの重大な脆弱性を利用しています。その高度さは、初期侵害だけでなく、暗号鍵を窃取し、パッチ適用後も生き残る永続的なアクセスを確立できる点にあります。
セキュリティチームにとって、これは根本的な問題です。従来のゼロトラスト・セキュリティアーキテクチャは侵害を前提とし、継続的な検証で横方向の移動を制限しますが、SharePointオンプレミスは境界防御時代の設計であり、こうしたアーキテクチャ的防御がありません。厳格なインシデント対応能力を持つ組織でも、複雑な環境全体でエクスプロイト公表からパッチ適用までの間に脆弱な期間が生じます。
国家レベルの攻撃者によるコラボレーション基盤の標的化は明確な傾向です。これらのシステムには契約書、知的財産、機密通信などの高価値データが含まれます。侵害されたコラボレーションサーバーは、他のネットワークリソースへの横移動の足掛かりにもなります。こうしたシステムを魅力的な標的にするアーキテクチャ上の脆弱性は、パッチだけでは解決できません。
現実的な移行スケジュール：5つの重要マイルストーン
マイルストーン1：評価と要件定義（1〜3か月目）
移行成功の基盤は、組織が軽視・省略しがちな包括的な要件ドキュメントにあります。このフェーズでは、現行SharePoint基盤のセキュリティリスク評価、関連フレームワークへのコンプライアンス要件のマッピング、データ分類と機密度分析、部門横断のユーザーワークフローの把握、IT・セキュリティ・コンプライアンス・事業部門とのステークホルダー連携が求められます。
このフェーズを圧縮すると、移行途中で要件漏れが発覚し、高額な軌道修正や移行後のツール追加が必要になります。成果物は単なる要件書ではなく、セキュリティ・コンプライアンス・業務の観点からSharePoint代替が果たすべき役割を明確に理解することです。規制業種ではCMMC、HIPAA、GDPRなどの要件マッピングも含まれます。
マイルストーン2：ベンダー評価と選定（3〜6か月目）
ベンダー評価は、マーケティング資料やデモを見るだけでは不十分です。実データ・実ワークフローでのPoC（概念実証）テスト、セキュリティアーキテクチャの検証、コンプライアンスフレームワーク対応要件の具体的なマッピング、隠れた運用コストも含めたTCO（総所有コスト）分析、十分なサポート・SLAを含む契約交渉が必要です。
重要なのは「このプラットフォームはSharePointの代替になるか」ではなく、「SharePointから離れる理由を本質的に解決できるか」です。プライベートコンテンツネットワークアーキテクチャ、ゼロトラスト原則、FedRAMP Moderate認証、ファイル共有・メール・マネージドファイル転送の統合ガバナンスを備えたプラットフォームは、単なるクラウド移行とは根本的に異なるアプローチです。
マイルストーン3：計画と設計（6〜9か月目）
移行計画が成功するか、長期化した危機になるかはこのフェーズで決まります。段階的移行方針の決定、セキュリティアーキテクチャ設計・コンプライアンス設定、既存システムとの統合設計、ユーザーアクセス・権限マッピング、トレーニングプログラム開発・コミュニケーション計画、パイロットグループの特定と成功基準の定義など、詳細な移行方法論を策定します。
成果物は単なるプロジェクト計画ではなく、技術アーキテクチャ・セキュリティ／コンプライアンス検証・ユーザーコミュニケーション・トレーニング・コンティンジェンシープランまで網羅した包括的な設計図です。このフェーズを急ぐと、長期のダウンタイムやユーザー混乱、セキュリティギャップ、移行作業のやり直しが発生します。
マイルストーン4：パイロット展開と検証（9〜12か月目）
50〜200ユーザー規模でのパイロット展開は、全社展開前に移行アプローチを検証する重要なテストです。実際のワークフローが正しく機能するか、セキュリティポリシーが意図通りに適用されるか、監査証跡が必要なコンプライアンスデータを記録できるか、ユーザー体験が定着基準を満たすかを検証します。
パイロット展開で得られた教訓は、本番移行手順に直接反映されます。パイロットで発見・解決した課題は、全社展開時の問題回避につながります。このフェーズを省略・急ぐと、より大きな影響とリスクを伴うタイミングで問題が発覚し、スケジュール遅延や移行への信頼低下を招きます。
マイルストーン5：本番移行（12〜18か月目）
本番移行は一度きりの切り替えではなく、段階的なウェーブで進行します。先行部門が最初に移行し、標準ユーザーグループが続きます。複雑または高機密度のグループは最後に移行し、手順の洗練や教訓の恩恵を受けます。各ウェーブごとに監視・サポート・課題解決・検証を行い、次のウェーブへ進みます。
この段階的アプローチにより、ユーザーの適応期間が確保され、危機的状況下でなく課題解決が可能となり、レガシーシステム廃止前にすべてが正常稼働することを検証できます。スケジュールを圧縮すると、ユーザーの抵抗やセキュリティ回避策、データガバナンスのギャップが発生します。
カレンダーの現実：待つことは期限切れを意味する
移行スケジュールの計算は容赦ありません。今日は2025年11月。Microsoftのサポート終了は2026年7月14日、約20か月後です。現実的な移行には12〜18か月かかります。今始めても予期せぬトラブルへのバッファは2〜8か月。2026年第1四半期まで待つとバッファはゼロ。2027年度予算を待つ組織は完全に期限を逃します。
予算サイクルの現実がこの圧力をさらに強めます。2026年度のSharePoint代替予算が未確保の場合、2027年度の計画・承認が必要となり、プロジェクト開始が2026年中盤〜後半にずれ込みます。このスケジュールでは、移行完了が2027年または2028年となり、移行中もサポートのないインフラを長期間運用せざるを得ません。
1か月遅れるごとに、ToolShellのような悪用への脆弱性が増し、ベンダー評価にかけられる時間が減り、締め切りに追われた拙速な意思決定のリスクが高まります。遅れて開始した組織は、サポート終了直前に市場全体が移行を急ぐことで、ベンダーの対応キャパシティ不足にも直面します。
暫定的なセキュリティ対策：必要だが不十分
移行計画を進める間、既存SharePoint基盤には強化されたセキュリティ対策を講じるべきです。セキュリティパッチはリリース直後に即時適用し、ネットワークセグメンテーションで侵害されたSharePointサーバーからの横移動を制限、ToolShellの兆候や異常認証パターンの監視強化、多要素認証などアクセス制御の厳格化、バックアップ頻度の増加と定期的なリストアテストを実施してください。
これらの暫定対策はリスクを低減しますが、オンプレミスコラボレーション基盤を魅力的な標的にするアーキテクチャ上の根本的な脆弱性は解消できません。あくまで一時的なリスク緩和策であり、長期的なセキュリティ戦略ではありません。暫定的なコントロールに頼り続けるのではなく、移行計画を加速させるべきです。
Kiteworks：SharePoint移行の新たな選択肢
SharePointの代替を検討する組織は、SharePoint Onlineへの移行でマルチテナントアーキテクチャによるコンプライアンス制約を引き継ぐか、オンプレミス基盤から離れる理由を根本的に解決するために設計されたプラットフォームへ移行するかという重要な選択を迫られます。
Kiteworksは、国家レベルの攻撃者がオンプレミス基盤で悪用する攻撃面を排除するゼロトラストアーキテクチャのプライベートデータネットワークを提供します。SharePoint Onlineのマルチテナントモデルとは異なり、Kiteworksは論理的に分離されたインフラを提供し、FedRAMP Moderate認証（2017年6月取得）およびFedRAMP High Ready（2025年2月取得）の仮想プライベートクラウドを含み、他の選択肢では得られないセキュリティ検証を実現します。
このプラットフォームの統合ガバナンスは、SharePointの根本的な課題である複数のデータ交換チャネルにまたがるセキュリティの分断を解消します。Kiteworksは、セキュアなファイル共有、セキュアメール、セキュアMFT、Kiteworks SFTP、Kiteworksセキュアデータフォームなどのデータ通信チャネルを統合し、中央集権的なポリシーと監査証跡で管理することで、異なるシステム間のデータ相関によるコンプライアンス負担を排除します。
コンプライアンス部門にとって、KiteworksはSharePointで手作業が必要な作業を自動化します。防衛請負業者向けにCMMC 2.0 レベル2要件の約90%を標準でサポートし、HIPAAコンプライアンス、PCI DSSコンプライアンス、GDPRコンプライアンス、PCIコンプライアンス、CMMC 2.0コンプライアンス、ITARコンプライアンスの事前構成済みフレームワークを提供、監査レポートも自動化され、SharePoint手作業比で90%高速化されています。
予算根拠としても定量的な効果があります。Kiteworksへ移行した組織は、機密データ交換に関連するセキュリティインシデントが75%減少、コンプライアンスレポート作成がSharePointオンプレミス比で90%高速化、ハードウェアコスト削減・セキュリティ運用負担軽減・IT人員再配置を含めた総所有コストが60%低減したと報告しています。
特に2026年7月の期限が迫る組織にとって重要なのは、Kiteworksが数千件の導入実績で洗練された移行方法論を提供する点です。専任の移行チームが各マイルストーンを段階的にサポートし、業務への影響を最小限に抑えつつセキュリティ強化を最大化します。この体系的な支援により、要件やセキュリティギャップを妥協せず、厳しいスケジュールでも確実に移行を完了できます。
スケジュール圧力は現実ですが、解決策は明確です。Kiteworksが、2026年7月の期限を守りつつ、オンプレミス基盤では解決できないセキュリティ・コンプライアンス・ガバナンス課題を克服するマイルストーンベースのSharePoint移行をどのように実現できるか、ぜひご相談ください。ご相談予約はこちら。
よくあるご質問
ToolShellは、中国の国家レベルのグループLinen TyphoonおよびViolet Typhoonによって開発されたエクスプロイトチェーンで、SharePoint ServerのCVE-2025-53770（CVSS 9.8）、CVE-2025-53771、CVE-2025-49704、CVE-2025-49706などの重大な脆弱性を標的としています。これらのエクスプロイトにより、攻撃者はSharePointサーバーを侵害し、暗号鍵を窃取して初期脆弱性が修正された後も永続的なネットワークアクセスを維持できます。SharePointサーバーは、機密通信、契約書、知的財産などの高価値データを含み、他のネットワークリソースへの横移動の足掛かりとなるため、非常に魅力的な標的です。このエクスプロイトは、オンプレミスのコラボレーション基盤がパッチだけでは解決できないアーキテクチャ上の脆弱性を抱えていることを示しています。これらのシステムはゼロトラストアーキテクチャ（侵害を前提とし横移動を制限する設計）ではなく、境界防御時代の設計であるためです。
現実的なSharePoint移行には、初期評価から本番展開完了まで12〜18か月を要し、多くの組織が想定する6〜9か月よりも大幅に長くなります。この期間には、評価・要件定義（1〜3か月）、ベンダー評価・選定とPoCテスト（3〜6か月）、セキュリティアーキテクチャ設計・コンプライアンス設定を含む詳細計画（6〜9か月）、一部ユーザーでのパイロット展開・検証（9〜12か月）、段階的な本番移行（12〜18か月）が含まれます。多くの組織がこのスケジュールを過小評価するのは、予算承認サイクル、代替案のセキュリティ評価、コンプライアンス検証、ユーザートレーニング・定着化、大規模移行の現実的な制約を考慮していないためです。Kiteworksのように実績ある移行方法論と専任サポートチームを持つプラットフォームでも、組織のチェンジマネジメントや検証活動には圧縮できない固有の期間が必要です。
2026年7月14日のMicrosoftサポート終了後もSharePointオンプレミスを運用し続けると、時間の経過とともにリスクが複合的に深刻化します。期限以降に発見されたセキュリティ脆弱性にはパッチが提供されず、攻撃者が既知のエクスプロイトを悪用しても対処手段がありません。コンプライアンスフレームワークでは、機密データを扱うシステムに定期的なセキュリティ更新を要求するケースが増えており、サポート切れソフトウェアではコンプライアンス証明が困難または不可能になります。これは特にCMMC、HIPAA、PCI DSSなどの対象組織に影響します。サイバー保険も、サポート切れソフトウェアが関与した侵害は補償対象外となる場合が多く、財務リスクも増大します。運用面でも、新しいシステムやセキュリティツールとの互換性問題が蓄積し、最終的な移行コストや複雑性が増します。2026年7月は「目標」ではなく「最遅完了期限」と捉え、今すぐ評価・計画を始めて脆弱・非サポート・非コンプライアンスなインフラ運用を回避すべきです。
この判断は、SharePoint Onlineがオンプレミス基盤から離れる根本的な課題を解決できるかどうかにかかっています。SharePoint Onlineはハードウェア保守は不要になりますが、マルチテナントアーキテクチャで他組織とインフラを共有するため、機密性の高いデータに厳格なセキュリティ要件がある場合は不十分な場合もあります。また、SharePointオンプレミスと同様のコンプライアンス制約（自動監査レポートや完全なデータ系統追跡、メール・ファイル共有・他チャネル横断の統合ガバナンスの欠如）も引き継ぎます。高度なセキュリティやコンプライアンス要件を持つ組織では、専用設計のセキュアデータ交換基盤の方がニーズに合致することが多いです。Kiteworksのようなプラットフォームは、プライベートコンテンツネットワークアーキテクチャ、論理的に分離されたインフラ、FedRAMP Moderate認証、CMMC 2.0 レベル2要件の約90%サポート、全データ移動チャネルの統合ガバナンスを提供します。最適な選択肢は、組織のセキュリティアーキテクチャ要件、コンプライアンスフレームワーク、マネージドファイル転送・メールセキュリティ・ファイル共有の統合管理が必要かどうかによって異なります。
SharePoint移行計画で最も多く、かつ高コストな失敗は、スケジュールを6〜12か月過小評価すること、予算サイクルや承認プロセスを見落とすこと、要件定義を省略・簡略化して移行途中で軌道修正が必要になること、パイロット展開を省略・急いで全社展開前に問題を発見できないこと、段階的移行ではなく一斉切り替えを試みて検証・課題解決の余地を失うことです。また、コンプライアンス要件を網羅的にマッピングせず、移行後の監査でギャップが発覚するケースも頻発します。さらに、機能チェックリストだけでプラットフォームを評価し、セキュリティやガバナンスのアーキテクチャ的アプローチを見落とす（「SharePointの代替になるか」ではなく「SharePointから離れる理由を解決できるか」を問わない）ことも重大な失敗です。ユーザー定着化のためのチェンジマネジメントやトレーニング要件を過小評価し、セキュリティコントロールを回避する運用が生じることもあります。最後に、選定したプラットフォームが自組織のデータガバナンス・ゼロトラストセキュリティ・コンプライアンス自動化ニーズを本当に満たすかを移行前に検証せず、多大な時間と予算を投じた後で限界に気付くケースも多いです。
追加リソース
- ブログ記事
エンタープライズ向けセキュアファイル共有ソリューション5選 - ブログ記事
安全にファイルを共有する方法 - 動画
Kiteworks Snackable Bytes：セキュアファイル共有 - ブログ記事
セキュアファイル共有ソフトウェアの必須要件12選 - ブログ記事
エンタープライズ＆コンプライアンス向け最も安全なファイル共有オプション