Dynamics 365 の保守設計 — Upgradeが構造的に難しい理由と、Agent時代の運用モデル ♠ DX 365 Life

こんばんは。室長こと、吉島良平（Microsoft MVP for Business Applications｜Microsoft Regional Director）です。
あ、今日も午前3時。頭は絶好調であります。

さて昨日公開した「Dynamics 365はアップデートのたびに揺れる」に、予想以上の反響をいただきました。
「保守やってます。こういう記事を待っていました、ありがとうございます。」
「チェックリスト、チームに共有しました。」
「もう少し掘り下げた内容が読みたいです。」

嬉しかったです。実は、本稿が続編となります。

今日は二つのことを書きます。
一つは「なぜUpgradeはここまで難しいのか」—技術的な構造の話です。
もう一つは「AIは保守のどこに入ってくるのか、そしてどう設計するか」—Agent時代の運用モデルの話です。

※本記事は、前回の「Dynamics 365はアップデートのたびに揺れる」の続編です。本記事でのCRMは「Dynamics 365 Customer Engagementアプリケーション（Sales、Customer Service、Field Serviceなど）」を指します。

Upgradeはなぜここまで難しいのか

前回の記事でチェックリストを公開したとき、「これだけの確認が必要なんですか」という声がありました。
そうです。でも、なぜそれだけ必要なのか—その「なぜ」を今日は話したいと思います。

Upgradeが難しい根本的な理由は一つです。

Microsoftの変更と、あなたの環境の変更が、独立して走り続けているから。

Microsoftのクラウドサービスは進化を止めません。あなたの会社は業務要件に合わせてカスタマイズを積み重ねます。ISVはそれぞれのタイミングで更新します。連携先のシステムも変わります。それが年単位で積み重なった結果、「Microsoft + あなたの環境」という複合体のアップデートになっている。だから難しいのです。

CRM（Customer Engagement apps）— Solution Layerと依存関係の複雑さ

CRMのUpgradeで難しいのは、Solution Layerの構造と、Component単位の依存関係です。

CRM環境のSolution構成と依存関係

① Solution LayerとALMの構造
Power PlatformのALMでは、開発環境でUnmanaged Solutionを管理し、ビルドしたManaged Solutionをテスト・UAT・本番環境へ展開するのがベストプラクティスです。Dataverseでは、System Solution、Managed Solution、Unmanaged customizationなどが、コンポーネント単位でレイヤーを形成します。Managed／Unmanaged、Solution Component、依存関係を区別して確認します。Microsoftの標準コンポーネントが更新された場合、そのコンポーネントを参照・拡張しているSolution Componentに影響する可能性があります。Solutionの依存関係として自動追跡されないコード、設定、外部連携については、別途インベントリや契約テストによって影響を確認します。

② 影響を受けうる関連資産の広さ
CRMの変更管理では、Solution本体だけでなく、Plugin（C#）・PCF・JavaScript・Canvas App・Power Automate・接続参照・環境変数・帳票テンプレート（Word/Excel）・FetchXMLクエリ・外部API連携を一体として管理する必要があります。たとえばDataverseのテーブルや列の変更は、そのComponentを参照しているFlow・Plugin・JavaScript・PCFに影響する場合があります。変更内容（列の削除・非推奨化か表示変更か、物理データ構造変更かUI変更か）と各資産の依存関係を確認し、影響する資産を特定します。

③ Deprecation情報の管理
MicrosoftはDataverse APIやSDKの非推奨化を公式ドキュメントで案内しますが、実際の削除時期と移行期間は機能ごとに異なります。非推奨化の通知、代替API、削除予定時期、適用対象となるバージョンは、機能ごとのMicrosoft公式告知で個別に確認することが必要です。

④ Power Automateフローへの影響
Dataverseのテーブル・列・データ型・必須レベル・Choiceなどのメタデータ変更に加え、フローのトリガー／アクション、接続参照、環境変数、接続ユーザーの権限、外部コネクターのAPI契約を確認します。これらに互換性への影響がある変更が行われた場合、既存のPower Automateフローに影響する可能性があります。フロー単体ではなく、依存するDataverseコンポーネント・接続参照・環境変数・実行ユーザーの権限を含めて検証します。

⑤ セキュリティモデルの確認
Microsoftの標準機能追加に伴って新しい権限やセキュリティ設定が導入される場合があります。標準ロールを複製して作成したカスタムロール、Field Security Profile、Business Unit・チーム・所有者・共有設計がある環境では、更新後も最小権限と職務分掌が維持されているかを確認します。画面上の表示可否と、Dataverseの実データ権限は分けて検証することが重要です。

FO（Finance & Operations apps）— X++ビルドパイプラインとランタイム互換性

FOのUpgradeは、CRMとは質的に異なる難しさを持っています。X++というMicrosoft固有の言語で書かれたカスタマイズが、更新後の環境でも正常に動作するかを検証する必要があるからです。

FOのアップデート対応：ビルドとランタイムの構造

① ランタイム互換性とコンパイル時互換性の違い
FOのサービス更新は、サービスとしての後方互換性を維持する方針で提供されます。ただし、顧客・パートナーが開発したカスタマイズについては、使用しているAPI、拡張ポイント、メタデータおよび依存関係に応じた互換性検証が必要です。開発環境での再コンパイル時には、非推奨API・拡張ポイント・Enum・メタデータ変更などにより警告やビルドエラーが発生する場合があります。更新後のApplication PackageとPlatformに対してCustom ModelをBuildし、Compiler Warning・Obsolete API・Extension Point・Metadata Dependencyを含む互換性を検証することが必要です。

② Deprecated / Removed / Internal化の区別
FOでは、非推奨化（警告が出るが利用可能）・可視性や拡張可能性の変更（Internal化など）・削除済みなど複数の状態があります。状態によって、Compiler Warning、コンパイルエラー、拡張実装の見直し、または実行時の不具合につながる可能性があります。削除済みのObjectやMethodを直接参照しているコードでは、コンパイルエラーや依存関係解決の問題が発生する可能性があります。間接参照や設定依存の場合は、実行時エラーとして現れることもあります。対象バージョンの公式情報と実際のBuild結果を併せて確認します。MicrosoftはRemovedとDeprecatedを明確に区別して公開しています。代替手段・削除予定・コンパイルへの影響は機能ごとに個別に確認します。

③ Electronic Reporting（ER）の管理
ERでは、Data Model・Model Mapping・FormatなどのConfigurationを組み合わせて電子文書と帳票を構成します。構成によって依存関係は異なるため、Configuration Version・Provider・Prerequisite・派生関係・Format Mappingを確認します。また、アプリケーション更新やプラットフォーム更新によって、ERの実行結果、利用可能なデータソース、式、出力処理などに影響が生じる可能性があります。使用中のER構成とMicrosoft提供構成との差分を確認し、代表的な帳票・電子ファイルを実データで検証します（帳票シリーズ参照）。

④ OData / DMFエンティティの確認
外部連携が利用するData Entityのデータ契約（公開列・データ型・Key・Validationなど）、またはAPI認証・接続方式に互換性へ影響する変更がある場合、API呼び出しやデータ処理が失敗する可能性があります。エラー監視が不十分な場合、業務データの欠落や遅延として後から発見されることがあります。疎通確認だけでなく、登録・更新・検索・大量データ処理を含む契約テストを実施します。

⑤ 環境管理とサンドボックス検証
クラウド版FOでは、環境構成、更新方式、Update Experienceに応じて、LCSや関連する管理画面で更新スケジュール、適用状況、Sandbox／Productionの検証・適用順序を確認します。利用環境に適用されるMicrosoft公式の更新管理手順に従うことが必要です。本番適用前に更新済みSandboxで重要業務プロセス・カスタマイズ・外部連携・帳票を、業務重要度と変更影響に基づくリスクベースのアプローチで検証します。

BC（Business Central）— Major / Minor二層更新とExtension互換性

Business Centralは毎年4月と10月のMajor更新に加えて、Minor更新が継続的に提供されます。更新の種類にかかわらず、導入済みExtensionが適用後の環境で正常に動作することを確認する必要があります。ただし、Microsoftによる事前互換性検証、更新スケジュール、通知および対応プロセスは、Major更新とMinor更新で異なる場合があります。

BC Upgradeの構造：自動チェックと人による検証の分担

① Microsoftの自動互換性チェックとその限界
BC Onlineでは、Major更新前にMicrosoftがPTEと次期バージョンの基盤アプリとの互換性を確認します。問題が検出された場合、Business Central Admin CenterのNotification Recipientsに登録された通知先へ、検出された問題と推奨対応が通知されます。通知先には、テナント管理者や関係するExtensionの発行者など、環境の通知設定に登録された宛先が含まれます。ただし、自動チェックは、Extensionの互換性やインストール可否など、機械的に確認可能な技術項目が中心です。業務ロジック、帳票出力、権限、バッチ、外部API、パフォーマンス、ISVアプリとの組み合わせまでを網羅的に保証するものではないため、別途リスクベースの回帰テストが必要です。

② PTEの修正と再配備
自動検証でPTEの非互換が検出された場合、Extension Publisherまたはパートナーは、ALコードを修正し、新Major版のSandboxでビルド・検証します。検証に成功した互換版PTEをアップロードし、環境の更新時に適用されるようDeployment Scheduleを設定します。非互換が解消されない場合、更新が失敗または再スケジュールとなり、PTEの修正・再配備が必要になる可能性があります。更新失敗時の再試行や適用可否は、問題の内容と更新期間・更新管理ルールによって異なります。

③ ALコードの依存先変更
PTEはMicrosoft標準のアプリケーションオブジェクト（Table、Page、Codeunit、Interface、Enumなど）に依存します。Microsoftが標準機能を変更・廃止（Obsolete指定）すると、そこを参照しているALコードでコンパイル警告やエラーが発生します。Obsolete化されたオブジェクトへの依存は、対象バージョンとObsoleteStateを確認し、コンパイル警告・エラーや将来の削除リスクにつながるものを計画的に洗い出します。Major／Minorで同じ対応が必要とは限らないため、更新内容に応じて確認範囲を決定します。

④ AppSource ISVアプリのタイミング管理
導入済みAppSourceアプリについては、対象BCバージョンへの対応状況・アプリの依存関係・更新手順・ISVのサポート方針を確認します。ISVの対応版が未提供の場合、環境更新が失敗または延期される可能性があります。更新延期・代替構成・ISVへの問い合わせなどを含めて適用方針を判断します。

⑤ 環境管理とサンドボックス検証
Business Central Admin Centerでは、環境ごとの更新ウィンドウ、更新スケジュール、環境状態、適用済みバージョンなどを確認・管理します。Major更新前には、Preview環境または更新対象バージョンのSandboxで、PTE・利用中の帳票（Word / Excel / RDLC Layout）・外部API連携・ISVアプリ・重要業務シナリオを、業務重要度と変更影響に基づくリスクベースのアプローチで検証します。Minor更新についても、重要な業務シナリオや変更影響のある機能をSandboxで確認することが推奨されます。更新スケジュールの確認・変更は、必要な管理権限を持つ管理者がBusiness Central Admin Centerで行います。Notification Recipientsは、更新の可用性、スケジュール、成功・失敗、互換性問題などの通知を受け取る宛先であり、更新を管理する管理者とは別に設定します。

Integration と Regression Testing — テスト設計の考え方

CRM・FO・BCに共通する難しさがあります。それがIntegration（連携）とRegression Testing（回帰テスト）です。

業務プロセス・法人数・Security Role・Localization・連携先・カスタマイズの組み合わせが増えるほど、確認対象は急速に増えます。すべてを同じ深度で手動テストするのではなく、変更影響分析とリスクに基づいて対象を選ぶことが現実的なアプローチです。

テスト層	テスト種別	主な担当	主な検証対象	アップデート対応での役割
🔵 単体層	Unit Test	開発者	個別ロジック（Plugin / X++ / AL）	変更されたAPIやメソッドの動作確認
🔵 単体層	API / 契約テスト	開発者 / アーキテクト	APIの入出力・認証・エラー契約	OData / Dataverse API / BC APIの互換確認。UI構造の変更とは独立してAPI契約を検証しやすい一方、API仕様、認証、権限、データモデル、エラー応答の変更には影響を受けます。APIテストだけで業務プロセス全体を保証できるわけではないため、Integration Testおよび業務プロセステストと組み合わせます
🟡 機能層	機能テスト	コンサルタント / キーユーザー	個別機能が仕様通りに動くかを確認。UIテスト（画面操作・フォーム・表示・ユーザー導線）・帳票テスト（Word/Excel/RDLCレイアウト・ERコンフィグ・フィールドマッピング・計算式）を含む	画面構造変更に影響を受けやすい。Client Logic・Security・操作性・User JourneyはUIテストが必要。自動化スクリプトはアップデートで壊れやすいため保守コストを考慮する。帳票テスト（Word/Excel/RDLCレイアウト・ERコンフィグ・計算式）は、アップデートによる帳票出力・ERバージョン変更の影響を確認する
🔴 結合層	Integration Test	開発者 + コンサルタント	システム間連携・再送・順序・整合性	Dual-write / Virtual Table / DMF / 外部システム連携の疎通と正確性確認
🔴 結合層	業務プロセステスト	コンサルタント + キーユーザー	受注・購買・請求・期末締めなどのシナリオ	業務重要度と変更影響に基づいてリスクベースで対象を絞る。エンドツーエンドの業務検証
🔴 結合層	パフォーマンステスト	アーキテクト / 開発者	大量データ・同時実行・バッチ・応答時間	プラットフォーム変更でクエリ最適化が変わった場合の影響確認

この表はテストの引き出しです。起点は「Microsoftの変更が何に影響するか」。影響がない層はスキップできます。大変なのは確かですが、すべてをゼロからやり直すのではなく、変化の波及先だけを追う仕事です。

Upgradeが難しいのは、誰かの能力が足りないからではありません。
構造的に難しい仕事なのです。それを理解することが、保守を正しく評価する出発点だと思っています。

AIは保守サイクルのどこに入るか

では、AIはこの難しい仕事のどこを変えられるのでしょうか。
保守の仕事を「サイクル」として分解してみます。

保守サイクル	AIが支援できること	人が判断すること
📥 Update情報収集	Microsoft 365 Copilot Chatなどを利用したリリースノート・What’s New・Deprecations情報の要約・翻訳・抽出。複数製品の変更情報を横断してまとめる。機密資料を扱う場合は、利用するMicrosoft 365 Copilotの契約・ライセンス、Enterprise Data Protectionの適用条件、テナント設定、アクセス権、データ保持・監査要件を、導入時点のMicrosoft公式資料で確認します	自社環境に関係する変更かどうかの文脈判断
🔍 影響分析	GitHub Copilotを利用したX++ / ALコードの調査・参照箇所の検索支援・修正候補の作成。ただし、正式な非推奨検出と互換性判定にはCompiler Warning・AL Code Analyzer・Microsoft公式Deprecated情報を併用する	影響の重大度判定と対応優先順位の決定。業務文脈を踏まえたリスク評価
🧪 Regression Test	変更箇所から影響フローを逆引きしたテストケース案の生成。過去の障害記録からリスクの高いシナリオを提案。テスト結果ログの分析・異常候補の抽出	業務的に重要なシナリオの最終判断。「ここは必ずテストする」という優先順位付け。AIの出力の正確性確認
🚀 Deploy・適用	適用手順・事前確認・失敗時のEscalation Plan・復旧方法・代替運用の初稿作成。ただし、Rollback可否と復旧方法は製品・環境・Update TypeごとにMicrosoft公式手順を確認する（SaaS更新では任意のRollbackができない場合がある）	適用タイミングの最終決定（業務カレンダーとの調整）。Go / No-go判断
📊 Monitoring	製品・環境から取得可能なTelemetry、Alert、Exception、Dependency情報を、Application InsightsやAzure Monitorなどの監視基盤へ連携し、ルールまたはカスタムAgentによる異常候補の抽出と初期調査を支援する（取得できるTelemetryの種類、転送方式、保持先は製品・環境によって異なる）	「これは許容範囲か」の判断。顧客への影響有無の説明
🚨 Incident対応	類似障害事例の検索・提示。症状からの原因仮説リスト生成。初動対応手順の提案。対応が必要な候補をAgentが抽出し、承認後に構成済みConnectorまたはAPI Actionを使ってAzure DevOpsやServiceNowへWork Item / Ticketを登録する	顧客への状況説明と関係管理。根本原因の最終判断。対応完了の判定。チケット起票の承認
📝 ナレッジ化	障害報告書・ポストモーテムの初稿生成。今回の対応内容をナレッジとして整理・蓄積。AIの一次要約・候補生成については、情報の完全性・誤検知・見逃しを人または自動検証機構で確認する	「何を学んだか」の意味づけ。次回のプロセス改善への落とし込み

AIは「収集・検出・提示・初稿」が得意。人は「判断・関係・文脈・承認」を担う。

Microsoftの変更情報と顧客環境固有のカスタマイズ・依存関係・過去障害・業務重要度を統合し、常に正確な影響判断を自動で行うには、データ整備・権限設計・評価・監査・人による承認が必要です。AIは保守を「なくす」のではなく「変える」のです。

Copilot・Agentは今どこまで来ているか

保守・運用でのCopilot / Agent 活用：現状マップ

✅ 既存のMicrosoft製品・サービスを利用して実現可能
Microsoft 365 Copilot Chatを利用したリリースノートの要約・翻訳。GitHub Copilotを利用したX++ / ALコードの調査・修正候補生成（正式な非推奨検出にはCompiler / Analyzerとの併用が必要）。Power Automateを中心に、Copilot StudioやAIサービスを組み合わせて構築するアラート通知・初期トリアージ支援（利用可能なCopilot機能、Connector、Action、ライセンス、実行権限は個別に確認が必要）。

🔄 標準機能を組み合わせて構築可能（実装コストあり）
Copilot Studioで構築した保守問い合わせAgent（利用するOrchestration・Knowledge Source・Connector・Actionの提供状態とライセンスを個別に確認）。テスト結果ログをAIが分析し異常候補を抽出するカスタムAgent（Fabric + Azure AI活用）。過去のインシデント記録から類似事例を検索するRAG構成。

🔬 顧客固有のデータ・権限・評価基盤が必要
自社環境のカスタマイズ一覧・コードリポジトリ・Solution依存関係・テスト結果・権限設計を接続した上での変更影響分析。複数製品（CRM + FO + BC + ISV）を横断した影響の自動判定。これらはデータ整備・権限設計・人による検証の仕組みが整備されて初めて機能します。
※利用可否は、製品、提供状態、地域、言語、ライセンス、管理者設定、接続先および組織のセキュリティポリシーによって異なります。

設計案：保守運用を捉える5つの視点

ここからは、「保守ナレッジをどう整理し、AIに渡せる形にするか」という設計の話をします。一つの正解があるわけではなく、目的や組織の成熟度によって向いている考え方が異なります。五つの視点を紹介します。

案1：ALM / DevSecOpsパイプラインとして設計する

保守対応は、情報を整理する話である前に、変更を安全に本番へ届ける話です。そう考えると、ALM（Application Lifecycle Management）とDevSecOpsパイプラインは、変更を安全に本番へ届けるという目的に直接対応する設計モデルです。

案1：保守の変更管理パイプライン

変更情報収集 → 影響分析 → コード・設定修正 → ビルド / 静的解析 → 自動テスト → UAT / 承認 → 本番適用 → 監視 → ナレッジ化

CRM / FO / BCそれぞれの技術要素をこのパイプラインに対応付けられます：

CRM：Solution・Plugin・PCF・Power Automate・接続参照・環境変数

FO：X++・モデル・ER・ビルドパイプライン・回帰テスト

BC：AL Extension・PTE・AppSource依存・アップグレードコード

Power Platform ALM / Power Platform Pipelines / Azure DevOpsとの親和性が高く、Microsoft製品の開発・展開・テスト・承認の流れと対応付けやすい構成です。

案2：Incident / Problem / Change Managementとして設計する

ITサービスマネジメントで一般的なIncident、Problem、Change、Knowledgeの考え方に近い整理です。保守の仕事を「Incident（今起きている問題を復旧）」「Problem（再発原因を分析）」「Change（Microsoftの更新を管理）」「Knowledge（解決策を蓄積）」の4区分で整理します。

区分	保守での役割	AIの役割
Incident	発生中の障害を復旧する	ログ検索・類似事例検索・初動案の提示
Problem	再発原因・構造原因を分析する	原因候補・影響範囲・再発パターンの分析支援
Change	Microsoftの更新・修正・設定変更を管理する	変更影響候補の生成・テストシナリオ案・承認資料の初稿
Knowledge	解決方法・判断基準・再発防止策を蓄積する	報告書・手順書・FAQ・検索用ナレッジの初稿生成

この設計の強みは、保守業務の責任分界とチケット運用が明確になることです。ServiceNow・Azure DevOps・Power Platform ALMとの相性も良いです。

Dynamics 365自体を保守業務のプラットフォームとして使う

案2のIncident・Problem・Change・Knowledgeの運用を、Dynamics 365のモジュールで構成することもできます。Case Management（Dynamics 365 Customer Service）はIncident・Problemの起票・エスカレーション・SLA追跡に、Knowledge ManagementはKB記事の蓄積・検索・Copilotによる提示に、Contact Center（Dynamics 365 Contact Center）は顧客からの問い合わせチャネル統合に対応します。「Dynamics 365を保守する仕事」を「Dynamics 365を使って回す」というEnd-to-Endな構成は、Microsoft製品スタックの強みの一つです。

案3：Dependency Graph（依存関係グラフ）として設計する

技術者にとって最も本質に近い考え方です。保守の核心は「どのMicrosoft変更が、どのカスタマイズ・API・帳票・権限・業務プロセスに影響するかを辿れること」にあります。

Microsoft変更ノード → Dataverse列 → Plugin / Flow / PCF / 帳票
Microsoft変更ノード → FOデータエンティティ → OData連携 / DMF / 外部システム
Microsoft変更ノード → BC標準オブジェクト → AL Extension / PTE / AppSourceアプリ

このモデルでは、AgentはGold層だけを静的に参照するのではなく、変更ノードから依存ノードを探索し、関連するテストケース、過去障害、確認済みのGold層情報を組み合わせて、未確認の依存関係や対応候補を提示します。対応チケットの起票は承認後に実施します。実現にはカスタマイズ台帳・コードリポジトリ・テスト結果・障害履歴をグラフ構造で管理する基盤整備が必要です。

案4：Digital Thread（変更のデジタルスレッド）として設計する

一つの変更について、Microsoftの変更から顧客の意思決定まで「一続きの証跡」として管理する考え方です。経営層への説明にも使いやすいです。

Microsoftの変更 → 自社資産の特定 → 影響分析 → テスト結果 → 承認 → 本番適用 → 監視 → 障害 → 改善—この一連の流れを切れ目なく追跡できる設計です。Change Intelligence（変更に関するインテリジェンス）として、保守対応の品質と透明性を経営・顧客・監査の視点で示せます。

案5：Medallion Architectureの発想を転用する

※ここから紹介する3層は、Microsoftが保守ナレッジ管理のReference Architectureとして定義したものではありません。Microsoft FabricのMedallion Architectureが持つ「Raw Dataを段階的に検証・変換し、利用目的に適したData Productへ高める」という考え方から着想を得た、本記事独自の整理です。

以前このブログで「データ移行とは、AIに経験・証跡を引き継ぐこと」と「続・データ移行はAIへの経験伝承」で紹介したMedallion Architecture（Bronze / Silver / Goldによる段階的なデータ品質向上）の考え方を、保守ナレッジのパイプラインに転用するとどうなるか、という発想です。

案5：D365保守ナレッジ × Medallionの発想（独自モデル）

🥉 Bronze — 原情報と証跡をそのまま保持する
Release Notes・What’s New・Deprecated Features・Hotfix情報・顧客環境のTelemetry・Incident・問い合わせ記録・Customization Inventory・ISV情報を、取得日時・ソース・バージョン・Environment・権限・Content Hashなどのメタデータとともに原形式で保持します。原文・原ログの業務内容を変える分類・要約・正規化は、Bronzeの原情報を保持したうえでSilver側の処理として実施します。一方、取得日時・ソース・スキーマバージョン・イベントID・Content Hash・取り込み状態などの技術メタデータは、Bronzeの管理情報として付与できます。
→ 収集・取り込みの自動化はAIが担えます。

🥈 Silver — 正規化・関係付け・影響評価の中間層
BronzeのRaw情報を自社環境への影響評価に変換します。Silverでは、AIによる推定、ルールによる判定、人による確認済みの事実を、状態・根拠・信頼度とともに区別して保持します。対象製品・バージョン・Microsoft変更項目・自社資産ID・依存関係・影響種別・影響の根拠・AIによる推定か人による確認済みかの区別・信頼度・最終確認者・確認日時・テストケースID・関連チケットを属性として持たせます。AIが出した候補と技術者が確認した事実を同じレコードとして扱うと、後から誤判定が混入するため、状態の区別が重要です。
→ AIが候補を出し、人が確認・判断するハイブリッド層です。

🥇 Gold — 承認済みの業務利用層
技術者や責任者が確認した影響評価・対応方針・テスト結果・承認状態などを、顧客・運用チーム・Agentが利用できる形に整えた層です。生成・更新はパイプラインで自動化できますが、Risk Acceptance・Go / No-go・顧客説明・顧客へのCommitmentは権限を持つ人が決定します。AgentはGold層を優先的に参照して回答・初稿生成・チケット起票の候補を提示します。
→ AgentもHumanも使う層。承認責任は人が持ちます。

5つの視点をどう使うか

これらは互いに排他的ではありません。実装上は組み合わせることができます。

Fabric / OneLakeでBronze / Silver / Gold（案5）として情報を蓄積・品質化し
↓
Dependency Graphで変更と自社資産の依存関係を管理し（案3）
↓
ALMパイプラインで修正・テスト・承認・適用を実行し（案1）
↓
Incident / Problem / Change Managementでチケットと責任分界を管理し（案2）
↓
Digital Threadとして変更から顧客説明まで一続きに追跡する（案4）

どこから始めるかは、組織の成熟度と目的によります。
「まず変更情報の収集を整理したい」ならBronze層から。「AI Agentに保守問い合わせを任せたい」ならGold層の整備から。「説明責任と監査を強化したい」ならDigital Threadから。どこからでも始められます。

まとめ — Agent時代の保守チームの姿

AIが保守に入ってくると、保守の仕事は「なくなる」のではなく「変わる」と私は思っています。

変わるのは、定型作業の比重です。リリースノートの一次要約、ログからの異常候補抽出、定型チェックの実施支援—こうした作業をAIが担えるようになります。ただし、情報の完全性・誤検知・見逃しは人または自動検証機構で確認する必要があります。
残るのは、判断です。影響の重大度を決める。顧客に何をどう伝えるか決める。今回のリリースで何を優先するか決める。過去の経験と業務文脈を踏まえてリスクを評価する。

保守チームがAgent時代に求められるのは、「AIが出した候補を正しく判断できる人」です。
AIが「このAPIは廃止されています、影響候補が17件あります」と言ったとき、その17件の中から「これが本当に問題」「これは今は関係ない」を見分けられる人。
その判断力は、AIだけに委ねるのではなく、現場経験、レビュー、ケース学習、業務理解を通じて人が身につけ、継続的に磨く必要があります。

一つ聞いてもいいですか？

あなたのチームの保守ナレッジは、どこに蓄積されていますか？
担当者の頭の中にあるなら、その人が異動したとき何が残りますか？
AIに渡せる形になっていますか？

Agent時代の保守力は、「蓄積したナレッジの質」で決まります。どの視点から始めるにしても、今から整備しておくことが、将来の保守品質、対応速度、説明責任、AI活用の土台になります。

前回の記事で「保守は、プロジェクトより難しい仕事です」と書きました。
Agent時代になっても、それは変わりません。むしろ、AIを正しく活用するための判断力が加わる分、求められる能力は広がります。

でも、それはチャンスでもあります。
定型作業をAIに渡すことで、本当に価値のある「判断・関係・文脈・承認」の仕事に集中できる。保守の仕事の価値が、より見えやすくなる時代が来ます。

保守・サポートの現場にいる皆さんへ。Agent時代の保守は、あなたたちが主役です。
AIはツールです。使いこなすのは、現場を知っているあなたたちです。

Let’s Enjoy our DX365LIFE!