おはようございます。室長こと吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。

本日10月23日、松井秀喜氏が読売ジャイアンツの新監督に就任することが正式発表され、就任記者会見が行われました。日米の頂点を極めたレジェンドが、背番号「90」を背負い、いよいよ指揮官としてチームの舵を取る姿に胸を熱くした方も多いはずです。

名選手が必ずしも名監督になるとは限らないと言われるプロの世界で、真の指揮官に問われるのは、個々のタレントを並べることではありません。ファンと交わした「勝利」という約束を、グラウンド上の規律、スコアラーのデータ分析、育成、ベンチワークへと変換し、再現性のある勝利の方程式として結実させるアーキテクチャの構築です。グラウンドの最前線で起きた一打席ごとの事実がベンチへフィードバックされ、首脳陣の分析を経て再び選手へ「次の勝負手」として還流していく。この双方向の循環が機能して初めて、組織は黄金時代を築くことができます。

この構図は、私たちがエンタープライズアーキテクチャで追い求めてきた思想と完全に重なり合います。

CRMでお客様と約束したこと（Customer Promise）を、ERPで在庫・能力・原価・会計として着実に実行する。ディーラーからNSC（各国販売会社）、そしてOEM本社へと吸い上げられてきた現場の業務事実やデータを、単なる実績報告で終わらせず、OEMからNSC、そしてディーラーへと「次の一手を導く新たな価値」として還流させる。フロントとバックオフィス、最前線の現場と司令塔の本社が分断されず、エンド・トゥ・エンドでデータと責任が循環して初めて、企業という巨大なエコシステムはひとつの生き物のように真価を発揮します。

 

AI Native CRMから始まった長い旅が、いよいよAI Native ERPの最終回まで来ました。CRM×AIでは、顧客を正しく識別し、Customer 360の文脈で理解し、Journey・Sales・Customer Service・Contact Center・Field Serviceを通じて行動し、その結果を次の顧客理解へ戻す世界を考えました。

続くERP×AIでは、CRMで作られたCustomer Promiseを、在庫・能力・Resource・原価・信用・税・会計・Cashという企業の現実へ変える方法を追ってきました。Financeの月次決算・照合・監査、Supply Chainの需要・供給・在庫・能力、Project Operationsの商談から収益認識まで、Business Centralの日常実務。さらにData Responsibility、Agent Operating Model、Governance／Human Accountability、CxOの経営レンズまで進みました。

最終回で行うのは、これまで分けて見てきたCustomer・Data・Transaction・Agent・Human・Governance・Outcomeを、ひとつのOperating Modelへ戻すことです。各回を順番に要約して終わるのではなく、シリーズを貫いてきた問いを一枚の設計原則へまとめます。

---

---

二つのシリーズで追ってきたのは「AI機能」ではない

CRM×AIとERP×AIを通して、製品ごとに多くのCopilotやAgentが登場しました。しかしシリーズを貫いていた問いは「どのAI機能を使うか」ではありません。企業は、何を事実として読み、どの選択肢を作り、誰が決め、何を実行し、どの結果に責任を持つのか。これが中心でした。

CRM側では、顧客Identityが曖昧なら、AIが優秀でも別の顧客へ働きかけます。Customer 360が一枚の画面に見えても、関係・役割・Consent・時点・Unknownが整理されていなければ、行動の根拠にはなりません。Engagementが増えても、顧客にとって意味のあるPromiseが作られなければ成果ではありません。

ERP側では、Recommendationが正しそうでも、在庫・能力・原価・Credit・Tax・契約・会計期間を通過しなければCommitmentにはなりません。AgentがTransactionを作れても、企業としてCommit／PostしてよいAuthorityを持つとは限りません。

二つのシリーズをつなぐ共通言語は、Data・Identity・Context・Constraint・Authority・Transaction・Evidence・Learningです。AIはこの間を高速に移動します。だからこそ、企業はアプリケーションの境界ではなく、DecisionとResponsibilityの境界を設計しなければなりません。

表1：CRM×AIとERP×AIを貫く共通の問いの軸。二つのシリーズは別々のAI戦略ではなく、企業が事実を読み・決め・実行し・学ぶ同じ問いを異なる業務領域から追ったものである。

---

Customer PromiseからCustomer Understandingへ戻るClosed Loop

最終回の背骨は、Customer Promiseを中心にしたClosed Loopです。出発点は顧客Signalです。会話・購買・利用・問い合わせ・設備状態・現場訪問・支払・解約兆候などのSignalを、正しいIdentityとContextへ結び付けます。そこで初めて、企業は顧客が何を必要としているかを理解できます。

その理解はEngagementへ変わり、価格・数量・納期・Scope・Quality・Service Level・Payment TermsというPromiseになります。しかしPromiseは、CRMで保存された瞬間にはまだ企業の現実ではありません。ERPが在庫・Capacity・Resource・Cost・Margin・Credit・Tax・Contractを検証し、Feasibilityを示します。

FeasibleであることとCommitmentも同じではありません。Decision Rightを持つ主体がCommitmentを確定し、Transactionを正しいStateへ進めます。Delivery・Billing・Posting・Settlement・Service Resolutionを経て、PromiseはOutcomeになります。

Outcomeは「完了」だけでは足りません。予定したMarginを守れたか。Cashへ変わったか。顧客の問題は解決したか。ReworkやExpediteを増やしていないか。必要なCorrectionは行われたか。判断と結果をEvidenceとして再構成できるか。ここまで確認して初めてLearningが生まれます。

そしてLearningはERPの中だけへ戻りません。次のPricing・Forecast・Safety Stock・Resource Model・Policyへ戻ると同時に、Customer 360・Knowledge・Journey・Sales・Serviceへ戻り、次のCustomer Understandingを変えます。閉じるべきLoopはTransaction Loopではなく、企業学習のLoopです。

---

CRMとERPの間にあるのはIntegrationではなくDecision

CRMとERPの統合を、API・同期・共通データモデルだけで説明すると、本質を見失います。データが届いても、誰が決めるかが届かなければ、業務は止まります。状態が同期されても、訂正責任が不明なら、同じ誤りが複数システムへ広がります。

CRMからERPへ渡すべきものはOrderだけではありません。顧客が何を期待し、どの条件へ合意し、何が固定で、何が変更可能か。どの期限が顧客価値に直結し、どのRiskを許容できるか。ERPからCRMへ返すべきものも在庫数だけではありません。Constraint・代替案・Cost・Recommit可能日・承認が必要な例外です。

このHandoffで途切れやすいのは四つです。Data・Decision・Responsibility・Evidenceです。技術的に接続されていても、この四つが揃わなければ、営業は約束を前へ送り、現場は例外を吸収し、財務は後から差異を訂正し、Serviceは顧客へ説明できないという構造が残ります。

---

ERPの各領域は何を「企業の現実」として確定するのか

Customer Promiseは製品境界を理解しません。しかし企業内部では、異なる業務領域が異なる事実を確定します。総集編では、各製品の機能一覧ではなく、「何を企業の現実として引き受けるか」で整理します。

Financeは、Journal・Invoice・Payment・Settlement・Closeを通じて、企業のMoneyとAccounting Stateを確定します。数字を生成することではなく、どの業務事実がどの勘定・法人・期間へ反映され、どう照合・訂正されたかを説明できることが責任です。

Supply Chain Managementは、Demand・Supply・Inventory・Capacity・Quality・Warehouse・Transportationを通じて、何を・いつ・どれだけ実行できるかを確定します。Exceptionが起きたときは、最速案ではなくService・Cost・Risk・Time・Future Capacityを比較し、Recoveryを選びます。

Project Operationsは、OpportunityをProject Commitmentへ変えます。Scope・Resource・Time・Cost・Rate・Contract・Actual・Billing・Revenueをつなぎ、進捗と請求・請求と収益を分けながらProject Economyを確定します。

Business Centralは、販売・購買・在庫・支払・会計が近接する日常実務の中で、Agentと人のAction境界を具体化します。少人数の組織ほど、Read／Prepareを速くすることと、Commit／Postの責任を明確にすることを同時に行う必要があります。

表2：Finance・Supply Chain・Project Operations・Business Centralは異なる業務事実を確定するが、すべてCustomer Promiseを企業の現実へ変える同じ流れに参加する。

---

Operational TruthとAnalytical／Learning Truthを分けてつなぐ

AI時代のData設計で最も危険なのは、すべてを一つの「正しいデータ」にまとめようとすることです。Operational ERPは、現在のTransaction Stateと更新・訂正責任を持ちます。Order・Reservation・Shipment・Invoice・Ledger・Settlementは、業務RuleとAuthorityを通じて変更されます。

一方、Microsoft Fabric／OneLake・Power BI・Semantic Model等は、複数システムの履歴・意味・Measure・Evidenceを横断し、分析とAI Groundingへ接続します。ここで価値があるのは、ERPの正本を置き換えることではなく、異なるOperational Truthから生まれた経験を、次のDecisionで再利用できる形へ整えることです。

FreshであることはAuthoritativeであることを意味しません。Goldレイヤーにあることは、業務的な訂正責任を持つことを意味しません。Semanticが整っていても、Posting Authorityは生まれません。AIが広いデータを読めても、Current Stateを変更してよいわけではありません。

Learningも無条件の自動再学習ではありません。過去のException・当時のContext・選択肢・Decision・Authority・Action・Correction・Outcomeへ、根拠付きで到達できる状態を作り、Rule・Prompt・Policy・Planning Parameter・Knowledgeを改善することです。

---

Agentは能力ではなくActionとAuthorityで設計する

Agentを導入するとき、「このAgentは何ができるか」から始めると、CapabilityとAuthorityが混ざります。技術的に生成・呼出・更新できること、IdentityにPermissionがあること、企業としてActionを委任したこと、結果へAccountableであることは別々です。

シリーズでは、Read→Summarize→Recommend→Prepare→Update→Commit→PostというAction Ladderを使いました。右へ進むほど、System Change・External Impact・Irreversibility・Correction Cost・Evidence要件が増えます。同じAgentでもReadは自動・PrepareはReview付き・UpdateはField限定・CommitはThreshold内・PostはHuman Authorityという設計が可能です。

Bounded Autonomyとは、Agentを弱くすることではありません。Low Risk・High Frequency・High ReversibilityのActionを速く進めながら、Customer／Supplier Commitment・Master／Money・Inventory／Resource・Accounting／Closeの境界で正しいAuthorityへ戻すことです。

Human ReturnはAgentの失敗ではありません。停止理由・影響範囲・Source・Evidence・選択肢・推奨・何もしない場合の影響・再開条件を揃えて、Decision Rightを持つ主体へ仕事を返せたなら、それもAgentの成功です。

表3：Agent委任の7段階。右へ進むほどSystem Change・External Impact・Irreversibilityが増す。Capability（できる）とAuthority（任せてよい）は別の設計で管理する。（DX365Life編集モデル）

---

GovernanceはブレーキではなくControl Plane

Governanceを承認画面や監査ログの話に縮めると、Agent時代の本質を捉えられません。Governanceは、許可された範囲では速く動き、高影響Actionの前では止まり、正しいOwnerへEscalateし、正式に訂正し、再開できるようにするControl Planeです。

Human-in-the-Loopは、処理の最後に人を残すことではありません。Design・Operate・Decide・Execute・Correct・Review／Auditの責任を配置することです。Approveした一人へ全責任を集めず、人・Agent Identity・Service Principalを含めてSoDを設計します。

Stopは失敗ではありません。Policy・Authority・Evidence・Stateの条件が満たされないときに、影響発生前で止める正常なControlです。EscalateではEvidence Packageと期限を正しいOwnerへ渡します。OverrideにはReason・Owner・Expiry・代替Control・Resume Conditionが必要です。

Posting後の誤りを万能なRollbackで語ってはいけません。Reversal・Credit Memo・Return・Adjustment・Repost／Rebill等、各業務と製品が定める正式Correction Methodを使い、Original TransactionとCorrected StateをEvidenceで結びます。

---

CxOはActivityではなくOutcomeとLearningを読む

Agent Run Count・Automation Rate・Task Completion・Tool Call・処理時間は、Operating Capacityを理解するには必要です。しかし、それだけでは経営成果を示しません。処理件数が増えても、価格例外・請求遅延・在庫滞留・Correction・Write-offが増えればOutcomeは悪化します。

CxOはMargin・Cash・Working Capital・Resilience・Decision Latency・Promise Reliabilityという六つのレンズで、同じCustomer Promise・Operational State・Evidenceを読みます。これらは独立KPIではありません。在庫削減はWorking Capitalを改善してもResilienceを傷つけ、納期遵守は特急輸送によってMarginを失うことがあります。

重要なのは、Outcomeが悪化してから原因を探すだけでなく、Exception Detection・Human Return・Stop-before-Impact・Correction・Evidence Completeness・Decision LatencyというLeading Indicatorを読み、Outcomeへ至るDecisionの流れを変えることです。

ただし、Leading IndicatorとOutcomeの関係を単純な因果として断定してはいけません。市場・価格・Mix・季節性・Policy・Data Quality等を確認し、どのDecisionがどのOutcomeへつながったかをEvidenceで検証します。経営ダッシュボードは数字の景色ではなく、Exception・Impact・Decision Needed・Owner・Evidence・Expected Outcomeをつなぐ作業Canvasであるべきです。

---

シリーズを貫いた「≠」を一つの設計原則へ

二つのシリーズでは、多くの「≠」を使いました。これは言葉遊びではありません。似て見えるものを分離しなければ、AIの速度が責任の曖昧さを増幅するからです。

表4：シリーズを貫いた10組の「≠」。AIの能力・権限・企業責任・Outcomeを混同しないための設計原則。分離した要素をEvidenceで接続する。（DX365Life編集モデル）

これらを一つにまとめると、AI Native Enterpriseの設計原則は明快です。理解すること・提案すること・許可されていること・企業として決めること・実行すること・結果へ責任を持つことを、同じものとして扱わない。分離した上でEvidenceによってつなぐ。その分離と接続が、AI時代の企業設計です。

---

ERPを企業判断と実行学習の中枢へ変える

では、ERPを企業判断と実行学習の中枢へ変えるとは、実際に何を変えることでしょうか。新しいAgentを導入することから始めるのではありません。Promise・Truth・State・Authority・Evidence・Outcome・Learningの責任を、End-to-Endで設計することから始めます。

第一に、Customer Promiseを条件の束として定義します。Price・Quantity・Date・Scope・Quality・Service Level・Payment Terms・Change Conditionを、ERPが検証可能なConstraintへ翻訳します。

第二に、FeasibilityとCommitmentを分けます。AIが可能性を評価し、Optionを作ることはできます。しかし企業としてCapacityを拘束し、顧客へ確約し、MoneyやAccountingへ影響させる地点では、Decision Rightが必要です。

第三に、Operational TruthとLearningの責任を分けます。ERPは現在Stateと正式Correctionを持ち、Fabric／OneLake等は履歴・Semantic・Evidenceの横断利用を支えます。

第四に、AgentをAction単位で委任します。Observe／Shadowから始め、Recommend・Prepare・Bounded Update・Bounded Commitへ段階的に広げます。Evidence Completeness・Correction・Human Return・Resume Success・Outcomeが悪化すれば、範囲を縮小・停止します。

第五に、Governanceを運用可能なControl Planeにします。Decision Right・Threshold・SoD・Stop・Escalate・Override・Resume・Correction・Change Management・Reviewを、設計書ではなく日々のOperating Modelへ組み込みます。

第六に、CxOの問いをActivityからOutcomeへ変えます。何件自動化したかではなく、Promiseを守りながらMarginとCashを残し・Working Capitalを健全に使い・Exceptionから回復し・Decision Latencyを短縮し・次の判断を改善できたかを問います。

---

まとめ — 約束を守る企業から、約束から学べる企業へ

AI Native CRMから始まり、AI Native ERPの最後までたどり着きました。振り返ると、扱ってきたのはAIの機能ではなく、企業が顧客と交わす約束の設計でした。

CRMは顧客の期待を理解し、価値あるPromiseを作ります。ERPはそのPromiseを、在庫・能力・Resource・原価・信用・税・会計・Cashという企業の現実へ変えます。Serviceは、Promiseが実現されたかを顧客の問題解決とEvidenceで確かめます。Customer 360・Knowledge・Fabric／OneLake等は、OutcomeとEvidenceを次の理解と判断へ戻します。

この循環が切れていると、各システムが正常に動いていても、企業は学べません。CRMが作ったPromiseがERPのConstraintへ翻訳されない。ERPのFeasibilityがSalesへ戻らない。ServiceのResolution EvidenceがJourneyや製品改善へ戻らない。AgentのActionは増えても、誰が決め・誰が訂正し・何を学んだかが残らない。

ERPを企業判断と実行学習の中枢へ変えるとは、ERPだけを変えることではありません。Customer Understanding・Promise・Feasibility・Commitment・Transaction・Outcome・Evidence・Learningを、同じ企業責任の中でつなぎ直すことです。

AIが賢くなるほど、人の責任が消えるわけではありません。人がすべてを処理する必要は減ります。しかし、何を企業として引き受けるかを決め・例外を止め・結果を説明し・次の設計を変える責任は、より明確でなければなりません。

CRM×AIシリーズとERP×AIシリーズ、合計24回にわたる連載はこれで完結です。読んでいただいた皆さん、本当にありがとうございました。

---

Let’s Enjoy our DX365LIFE!

---

次回以降：DX365Lifeでは、このシリーズに限らず幅広いテーマを継続的に発信しています。Microsoft Copilot・Azure OpenAI・Fabric・Power Platformといった最新技術の動向、プロジェクトマネジメントの実践、そしてDynamics 365の導入・開発に携わるベンダーのコンサルタントや開発者向けのディープな技術コンテンツも掲載しています。新しいシリーズや記事はDX365Lifeブログからぜひご確認ください。