『SYNTHESIS』――武藤惣一郎・AI・データ・システム・Agent・コードから、Capability Generation Companyをつくる（第7回）（第Ⅵ部　Outcome 第6章　成果をコードで測る）

第Ⅵ部　Outcome

第Ⅴ部までに、SYNTHESISを一つの実装系として記述してきた。

Companyから始まり、Architectureを設計し、Intelligenceをつくり、AI AgentとHumanをRuntimeで接続し、Data、API、Event、Workflow、Cloud、ERPを通じてEnterprise Realityへ到達した。

しかし、ここで最も重要な問いが残る。

[
\boxed{
それで、何が変わったのか
}
]

AIを導入した。

Agentを実装した。

SystemをProductionへ入れた。

業務Processを変更した。

これらはすべてInterventionであって、Outcomeそのものではない。

[
\boxed{
Implementation
\neq
Outcome
}
]

第Ⅵ部では、Technologyの内部構造から一度離れ、企業Realityに生じた差分を測る。

⸻

OutputからOutcomeへ

Consulting Projectには、多くのOutputが存在する。

Report。

Strategy。

Roadmap。

Architecture。

Code。

System。

Dashboard。

AI Agent。

これらは必要である。

しかしOutputが存在することと、企業が変わったことは同じではない。

[
Output
\rightarrow
Use
\rightarrow
Change
\rightarrow
Outcome
]

まで進まなければならない。

たとえば営業AIを実装したなら、問うべきなのはAgent数ではない。

提案準備時間は短縮したか。

営業担当者の判断は速くなったか。

顧客接点は増えたか。

Conversionは変化したか。

売上へ影響したか。

そして、その改善をClient自身が維持できるか。

ここまで見て初めてTransformationを評価できる。

⸻

Before → Intervention → After

Outcomeを測る最小構造は単純である。

[
\boxed{
Before
\rightarrow
Intervention
\rightarrow
After
}
]

Beforeには、変革前のRealityがある。

Interventionには、Consulting、AI、System、業務変更、組織変更がある。

Afterには、その結果として生じた新しいRealityがある。

重要なのは、

[
After-Before
]

という差分を観測することである。

ただし、差分が存在するだけでInterventionが原因だったとは断定できない。

市場環境。

季節性。

価格。

競合。

組織変更。

景気。

他の施策。

が同時に作用するからである。

したがって本部では、単なるBefore / After比較から、可能な範囲で比較群、時系列、因果仮説、複数指標へ進む。

[
Measurement
\rightarrow
Evidence
\rightarrow
Causal\ Confidence
]

を高めていく。

⸻

Outcomeを多層で見る

Enterprise TransformationのOutcomeは一つではない。

本書では少なくとも、

[
\boxed{
Operational
+
Financial
+
Decision
+
Adoption
+
Capability
}
]

の五層を見る。

Operational Outcome。

処理時間。

作業量。

Error。

Lead Time。

Throughput。

Financial Outcome。

売上。

Cost。

利益。

Cash Flow。

投資効率。

Decision Outcome。

意思決定速度。

Evidence利用。

予測精度。

判断の一貫性。

Adoption Outcome。

利用率。

継続率。

Human Intervention。

AI利用範囲。

そしてCapability Outcome。

Clientが自ら運用できるか。

変更できるか。

次のProblemを発見できるか。

次のTransformationを起こせるか。

である。

最後のCapability Outcomeが、本書を通常のAI導入評価から分ける。

⸻

技術指標と経営指標を接続する

AI SystemにはTechnical Metricがある。

Latency。

Availability。

Error Rate。

Retrieval Quality。

Agent Completion Rate。

Token Cost。

しかし経営者が知りたいのは、それだけではない。

[
Technical\ Metric
\rightarrow
Operational\ Metric
\rightarrow
Business\ Metric
]

を接続する必要がある。

たとえば、

Agent Response Timeが改善した。

それによって提案準備時間が短縮した。

営業担当者がより多くの顧客へ対応できた。

商談数が増えた。

売上へ影響した。

という連鎖である。

この経路が見えなければ、AI Systemの改善とBusiness Valueの関係を説明できない。

⸻

OutcomeをProblemへ戻す

第Ⅱ部以降、本書ではProblem IDをArchitecture全体へ通してきた。

ここでその意味が現れる。

[
Problem
\rightarrow
Requirement
\rightarrow
Architecture
\rightarrow
Implementation
\rightarrow
Outcome
]

を一つのTraceとして持つ。

すると、

「このProjectは成功したか」

ではなく、

「最初に定義したProblemはどの程度変化したか」

を問える。

Project CompletionとProblem Resolutionを分離するのである。

[
Project\ Completed
\neq
Problem\ Solved
]

これはConsultingをOutcome-Nativeへ変える重要な転換になる。

⸻

測れないものを無理に数字にしない

Outcome-Nativeとは、すべてをKPIへ圧縮することではない。

組織のLearning。

意思決定の質。

顧客との信頼。

社員の理解。

新しいCapability。

将来の選択可能性。

には、単一の数値では表現しにくいものもある。

したがって、

Quantitative Evidence。

Qualitative Evidence。

Behavioral Evidence。

Operational Evidence。

を組み合わせる。

[
Measurement
\neq
Single\ Number
]

である。

重要なのは、曖昧な価値を無理に数字へ変えることではなく、何をEvidenceとして判断したのかを明示することである。

⸻

AI Adoptionを成果と誤認しない

AI利用率が上がった。

Prompt数が増えた。

Agent実行数が増えた。

これらはAdoptionを示す。

しかし、

[
Adoption
\neq
Outcome
]

である。

大量に使われても価値が生まれないAIは存在し得る。

逆に、利用頻度は低くても重要なDecisionを大きく改善するAIもあり得る。

したがって、

[
Usage
\rightarrow
Behavior\ Change
\rightarrow
Outcome
]

まで接続する。

AIを使ったかではなく、AIによって仕事と企業Realityがどう変わったかを見る。

⸻

Outcomeの後にCapabilityを測る

さらに本書では、通常のROI評価より一段先へ進む。

Projectによって短期的なOutcomeが生まれても、外部Consultantが離れた瞬間に元へ戻るなら、変革は定着していない。

そこで、

[
Outcome_t
]

だけではなく、

[
Outcome_{t+1}
]

をClient自身が維持・改善できるかを見る。

そのために、

運用できるか。

修正できるか。

測定できるか。

新しいUse Caseを追加できるか。

新しいProblemを発見できるか。

を測る。

これを、

[
\boxed{
Self\text{-}sufficiency
}
]

として扱う。

⸻

SYNTHESISをOutcomeから再評価する

SYNTHESISの公開情報では、AIを活用した迅速な効果創出、構想だけでなく実装・価値創出まで進む姿勢が繰り返し示されている。

さらに同社が示している成功の考え方には、Clientがより速くTransformationし、より早く自立的に変革できる状態へ近づくことが含まれている。

これは本書の仮説にとって重要である。

なぜなら、

[
Outcome
\rightarrow
Self\text{-}sufficiency
]

という方向が、SYNTHESIS自身の問題意識とも接続するからである。

ただし、2026年9月3日時点で、Clientごとの詳細なOutcomeやSelf-sufficiencyを示す公開定量Dataは十分ではない。

したがって本部では、理念と実績を混同しない。

[
Claim
\neq
Evidence
]

を守る。

⸻

Outcome-Native Consulting

ここからConsultingの評価軸を反転させる。

従来、

何人投入したか。

何か月支援したか。

何枚の資料をつくったか。

何Systemを導入したか。

がProjectの規模を表すことがある。

しかしOutcome-Nativeでは、

[
Input
\rightarrow
Output
]

ではなく、

[
Problem
\rightarrow
Outcome
]

を見る。

そしてさらに、

[
Problem
\rightarrow
Outcome
\rightarrow
Capability
]

へ進む。

⸻

これはProfessional Serviceの経済モデルにも問いを返す。

大量のHuman Hoursを投入するほど売上が増える構造と、少ない時間で大きなOutcomeを生成するAI-First Architectureは、必ずしも同じ方向を向かない。

この矛盾はまだ解かれていない。

だからこそOutcomeを測る必要がある。

[
Hours
]

ではなく、

[
Value
]

を観測できなければ、新しいConsulting Modelそのものを評価できないからである。

⸻

第Ⅵ部の生成軸

本部では、次の順序でOutcomeを測定する。

[
\boxed{
Outcome
\rightarrow
Before/After
\rightarrow
Time/Cost/Revenue
\rightarrow
Decision/Productivity
\rightarrow
AI\ Adoption
\rightarrow
Self\text{-}sufficiency
\rightarrow
Residual\ Capability
}
]

第1節では、Outcomeそのものを定義する。

第2節では、Before → Intervention → Afterによって変化を固定する。

第3節では、時間・Cost・売上という企業活動の基本量を測る。

第4節では、意思決定と生産性へ進む。

第5節では、AI Adoptionを利用量ではなくBusiness Changeとして評価する。

第6節では、Client Self-sufficiencyを測る。

そして第7節では、Project終了後に何が残ったのかを問う。

⸻

最後の問いは極めて単純である。

Consultantが去った。

Project Teamが解散した。

契約が終了した。

それでもClientの中に、

Dataが残った。

Systemが残った。

Knowledgeが残った。

AIが残った。

運用能力が残った。

判断能力が残った。

学習Loopが残った。

そして、

次のProblemを自分たちで解く能力が残ったか。

[
\boxed{
Project
\rightarrow
Outcome
\rightarrow
Capability
}
]

ここまで到達したとき、初めて第Ⅶ部の問いを開くことができる。

Consulting Companyは、Clientの問題を解く会社から、

[
\boxed{
Capability\ Generation\ Company
}
]

へ変わり得るのか。

その答えを出す前に、まずRealityを測る。

第Ⅵ部では、SYNTHESISを思想でもTechnologyでもなく、生成されたOutcomeによって検証する。
第6章　成果をコードで測る

第1節　Outcomeとは何か

企業変革では、「何をしたか」と「何が変わったか」が混同されやすい。

Strategyを策定した。

AIを導入した。

Agentを実装した。

SystemをProductionへ入れた。

業務Processを変更した。

これらはすべて重要である。

しかし、それ自体はOutcomeではない。

[
\boxed{
Action
\neq
Outcome
}
]

Outcomeとは、Interventionの結果として、企業Realityに生じた観測可能な変化である。

⸻

OutputとOutcomeを分ける

Consulting ProjectにはOutputがある。

Report。

Roadmap。

Architecture。

Prototype。

Code。

Dashboard。

System。

これらはProjectが生成した成果物である。

一方、Outcomeはその成果物が使われた結果として生じる。

たとえば、

Output
AI営業支援System
       ↓
Outcome
提案準備時間の短縮
商談対応数の増加
意思決定速度の改善
売上への寄与

となる。

したがって、

[
Output
\rightarrow
Use
\rightarrow
Behavior\ Change
\rightarrow
Outcome
]

という距離がある。

⸻

OutcomeはState Changeである

本書では企業を変化するStateとして記述してきた。

するとOutcomeも、

[
State_t
\rightarrow
State_{t+1}
]

として表現できる。

変革前の状態を、

[
S_t
]

変革後の状態を、

[
S_{t+1}
]

とすれば、

[
\boxed{
Outcome

\Delta S

S_{t+1}-S_t
}
]

と考えられる。

これは厳密な数学的減算という意味ではない。

企業Realityにどのような差分が生じたのかを固定するための記述である。

⸻

Outcomeには対象が必要である

「成果が出た」という表現だけでは測れない。

何が変わったのかを定義する。

Customer。

Employee。

Process。

Decision。

Revenue。

Cost。

Time。

Quality。

Risk。

Capability。

たとえば、

「営業生産性を改善した」

では広すぎる。

代わりに、

一件の提案作成に必要な時間。

一人当たりの商談対応数。

案件化率。

Proposal-to-Close期間。

などへ分解する。

[
Outcome
\rightarrow
Observable\ Variable
]

へ変換する。

⸻

Metricを定義する

OutcomeをCodeで測るにはMetricが必要になる。

from dataclasses import dataclass
@dataclass
class OutcomeMetric:
   metric_id: str
   name: str
   unit: str
   direction: str
   source: str

たとえば、

proposal_time = OutcomeMetric(
   metric_id="sales.proposal_time",
   name="提案準備時間",
   unit="minutes",
   direction="lower_is_better",
   source="sales_workflow"
)

とする。

重要なのは数値を集めることではない。

何を良い変化と定義したかをMachine-readableにすることである。

⸻

Baselineを持つ

Outcomeは単独の値では評価しにくい。

「提案準備時間が45分だった」

だけでは、それが良いのか悪いのか分からない。

変革前が120分だったなら意味が変わる。

そこでBaselineを持つ。

[
\boxed{
Outcome

Actual

Baseline
}
]

とする。

def delta(before: float, after: float) -> float:
   return after - before

たとえば、

[
120
\rightarrow
45
]

なら、

75分短縮された。

割合では、

[
\frac{120-45}{120}

62.5%
]

の短縮になる。

⸻

Targetも分ける

BaselineだけでなくTargetも必要である。

Baseline
120分
Target
40分
Actual
45分

この場合、

改善は大きい。

しかしTargetには届いていない。

したがって、

[
Baseline
\neq
Target
\neq
Actual
]

を分けて保存する。

@dataclass
class Measurement:
   baseline: float
   target: float
   actual: float

これによって、

[
Improvement
]

と、

[
Goal\ Achievement
]

を別々に評価できる。

⸻

Outcomeには時間軸がある

短期的に良く見えても、長期では戻る場合がある。

導入直後だけ利用率が高い。

一時的に処理時間が短縮する。

しかし数か月後には利用されなくなる。

そこで、

[
Outcome_t
]

を一時点で終わらせない。

Before
↓
1 Week
↓
1 Month
↓
3 Months
↓
6 Months

と追跡する。

[
Outcome

f(Time)
]

である。

⸻

LeadingとLaggingを分ける

Outcomeには早く観測できる指標と、時間がかかる指標がある。

AI営業支援なら、

利用率。

提案作成時間。

Agent Recommendation採用率。

は比較的早く観測できる。

一方、

契約率。

売上。

顧客Lifetime Value。

は遅れて現れる。

そこで、

[
Leading\ Indicator
\rightarrow
Lagging\ Outcome
]

を区別する。

⸻

たとえば、

AI Adoption
     ↓
Proposal Time
     ↓
Sales Capacity
     ↓
Opportunities
     ↓
Revenue

という仮説的な連鎖を持つ。

ただし、前段が改善したから後段も必ず改善するとは限らない。

それぞれを観測する。

⸻

Technical OutcomeとBusiness Outcomeを分ける

Systemには技術成果もある。

Latencyが下がった。

Error Rateが下がった。

Availabilityが上がった。

Model Accuracyが上がった。

これらは重要である。

しかし、

[
Technical\ Improvement
\neq
Business\ Outcome
]

である。

⸻

たとえばResponseが、

5秒から1秒になった。

しかし業務時間が変わらなかった。

この場合、Technical Outcomeは改善したが、Business Outcomeへの影響は小さい可能性がある。

したがって、

[
Technical
\rightarrow
Operational
\rightarrow
Business
]

の階層を持つ。

⸻

Outcome Treeをつくる

一つのBusiness Outcomeを、その成立条件へ分解する。

たとえば売上増加なら、

Revenue
  ↑
Conversion
  ↑
Proposal Quality
  ↑
Proposal Preparation
  ↑
Data + AI Assistance

となるかもしれない。

これをOutcome Treeとして扱う。

[
Business\ Outcome
\leftarrow
Operational\ Outcome
\leftarrow
System\ Outcome
]

である。

これによって、どのLayerに変化が起きたかを追跡できる。

⸻

Outcomeと因果を混同しない

ここで慎重さが必要になる。

AI導入後に売上が増えた。

だからAIが売上を増やした。

とは直ちに言えない。

同時期に、

価格変更。

広告Campaign。

Seasonality。

競合撤退。

営業人員増加。

景気変化。

が起きている可能性がある。

したがって、

[
Correlation
\neq
Causation
]

を守る。

⸻

Outcome Measurementでは、

Before / After。

Comparison Group。

Time Series。

A/B Test。

Difference-in-Differences。

など、利用できる設計を状況に応じて使う。

すべてのProjectで厳密なRandomized Experimentが可能なわけではない。

重要なのは、

[
Causal\ Confidence
]

を明示することである。

⸻

Confidenceを保存する

OutcomeにもEvidence Strengthを持たせる。

@dataclass
class OutcomeEvidence:
   metric_id: str
   value: float
   confidence: str
   method: str

たとえば、

HIGH
Randomized / Strong Control
MEDIUM
Comparison / Time-series evidence
LOW
Simple Before-After
UNVERIFIED
Anecdotal only

とする。

成果を大きく見せるのではなく、どの程度確かに言えるのかを保存する。

⸻

Negative Outcomeも記録する

変革には期待外れもある。

Costが増えた。

処理時間が伸びた。

Human Reviewが増えた。

品質が低下した。

Security Riskが増えた。

社員の負担が増えた。

これもOutcomeである。

[
Outcome
\neq
Positive\ Outcome\ Only
]

である。

⸻

したがって、

[
Expected
+
Unexpected
+
Positive
+
Negative
]

を観測する。

成功だけを保存すれば、Learningは歪む。

⸻

Counter-metricを持つ

一つのMetricだけを最適化すると、別の価値を壊すことがある。

たとえば処理速度だけを上げると、

Errorが増える。

顧客満足が下がる。

Human Judgmentが弱くなる。

可能性がある。

そこで主要OutcomeにはCounter-metricを置く。

Primary
Processing Time ↓
Counter
Error Rate
Customer Satisfaction
Human Override Rate

とする。

[
Optimization
\rightarrow
Guardrail
]

を組み込む。

⸻

OutcomeをProjectへ閉じ込めない

Project終了時だけ評価すると、その後の変化を見失う。

本書では、

[
Project
\rightarrow
Production
\rightarrow
Outcome
\rightarrow
Learning
]

までを一つのLoopとして扱う。

Outcome DataはEnterprise Memoryへ戻す。

⸻

概念的には、

CREATE TABLE outcome_measurements (
   measurement_id UUID PRIMARY KEY,
   problem_id      UUID NOT NULL,
   metric_id       TEXT NOT NULL,
   value           NUMERIC NOT NULL,
   measured_at     TIMESTAMPTZ NOT NULL,
   source_system   TEXT NOT NULL
);

とする。

Problem IDを残すことで、

[
Outcome
\rightarrow
Problem
]

へ戻れる。

⸻

OutcomeをArchitectureへ戻す

Outcomeが期待を下回ったとき、

「AIが悪かった」

で終わらせない。

どこにGapがあったのかを見る。

Dataか。

Modelか。

Workflowか。

Human Adoptionか。

Architectureか。

Processか。

Target設定か。

そもそものProblem Definitionか。

⸻

したがって、

[
Outcome\ Gap
\rightarrow
Diagnosis
\rightarrow
Requirement’
]

へ戻す。

[
Requirement’
\rightarrow
Architecture’
\rightarrow
Implementation’
]

と再実装する。

Outcome Measurementは評価の終点ではない。

次のArchitectureを生成するInputである。

⸻

Client OutcomeとConsultant Outcomeを分ける

Consulting Companyには自社側のBusiness Outcomeもある。

Revenue。

Margin。

Project Utilization。

Growth。

しかしClient Transformationを測るとき、それらと混同してはいけない。

[
Consultant\ Outcome
\neq
Client\ Outcome
]

である。

本書の中心はClient側に置く。

⸻

ProjectがConsulting Firmにとって高収益でも、Clientに価値がなければTransformationとしては成功していない。

逆にClientが大きく自立し、同じ支援を必要としなくなることは、Capability Generationという観点では強い成果になり得る。

ここに本書が後で扱う経済的緊張がある。

⸻

Outcomeの最終層はCapabilityである

時間が短縮した。

Costが下がった。

売上が増えた。

これらは重要である。

しかし本書にはさらに一つ上のOutcomeがある。

[
\boxed{
Client\ Capability
}
]

である。

Project後にClientが、

同じSystemを運用できる。

Dataを改善できる。

Agentを変更できる。

新しいUse Caseを追加できる。

Outcomeを自分で測れる。

次のProblemを発見できる。

ならば、Projectは一時的な効果以上のものを残したことになる。

⸻

したがって、

[
Outcome

Immediate\ Change
+
Persistent\ Capability
]

として見る。

短期成果と長期能力を分離しない。

⸻

SYNTHESISをOutcomeから見る

SYNTHESISは公開情報上、AIを使った迅速な効果創出や、構想から実装・価値創出までを重視している。

さらにClientがより速く変革し、より早く自立的に進める状態を成功の重要な尺度として示している。

この方向性は、

[
Implementation
\rightarrow
Outcome
\rightarrow
Self\text{-}sufficiency
]

という本書の構造と強く接続する。

ただし、2026年9月3日時点では、Client別の詳細な定量Outcomeを公開情報だけから十分に検証することはできない。

したがって、

[
Direction\ Confirmed
]

と、

[
Outcome\ Proven
]

を分けて扱う。

⸻

Outcomeをコードで測る

ここまでを最小化すると、Outcome Measurementは次の構造になる。

Problem
  ↓
Metric
  ↓
Baseline
  ↓
Intervention
  ↓
Actual
  ↓
Delta
  ↓
Confidence
  ↓
Learning

これをCodeにすると、

@dataclass
class Outcome:
   problem_id: str
   metric_id: str
   baseline: float
   target: float
   actual: float
   confidence: str
   def delta(self) -> float:
       return self.actual - self.baseline

Outcomeを説明文ではなくDataとして保持できる。

⸻

しかし最も重要なのはCodeではない。

Outcomeの定義そのものである。

[
\boxed{
Outcome

Observable\ Change\ in\ Reality
}
]

企業Realityのどこが、どれだけ、どの方向へ、どの程度確かなEvidenceによって変わったのか。

それを記述する。

⸻

AIを導入したことは成果ではない。

Systemをつくったことも成果ではない。

Consultantが働いた時間も成果ではない。

Problemとして観測したRealityが、Interventionの後にどのようなRealityへ変化したのか。

そこにOutcomeがある。

そして、その変化を測るためには、変革前の状態と変革後の状態を同じ座標系へ置かなければならない。

次節では、

[
\boxed{
Before
\rightarrow
Intervention
\rightarrow
After
}
]

を固定する。

成果を印象ではなく、変化として測る。
第2節　Before → Intervention → After

Outcomeを測るには、変化の前後を固定しなければならない。

AIを導入した後に処理時間が短くなった。

売上が増えた。

Errorが減った。

意思決定が速くなった。

それだけでは、まだ十分ではない。

必要なのは、

[
\boxed{
Before
\rightarrow
Intervention
\rightarrow
After
}
]

という一つの観測構造である。

何が変わる前だったのか。

何を介入として行ったのか。

その後、何がどう変わったのか。

この三点を同じ座標系で記述する。

⸻

Beforeを固定する

最初に必要なのはBaselineである。

しかしBaselineは単なる一つの数字ではない。

たとえば、

「提案書作成に120分かかっていた」

という情報だけでは足りない。

誰が。

どの業務で。

どの期間に。

何件を対象として。

どの方法で測定したのか。

まで持つ必要がある。

[
Baseline

Value
+
Context
+
Time
+
Population
+
Method
]

である。

⸻

Codeでは、たとえば次のように持てる。

from dataclasses import dataclass
from datetime import datetime
@dataclass
class Baseline:
   metric_id: str
   value: float
   unit: str
   period_start: datetime
   period_end: datetime
   population: str
   method: str

これによってBeforeを後から再構成できる。

⸻

Beforeは「導入直前」とは限らない

AI導入の前月だけをBaselineにすると、特殊要因を拾うことがある。

繁忙期だった。

大型案件があった。

組織変更があった。

障害が発生していた。

したがって可能なら一定期間を観測する。

[
Before

{S_{t-n},…,S_t}
]

として、単一点ではなく時系列で見る。

⸻

たとえば過去12週間の平均処理時間をBaselineにする。

SELECT
   AVG(processing_minutes) AS baseline_minutes
FROM sales_tasks
WHERE completed_at >= :baseline_start
 AND completed_at <  :intervention_start;

このようにMeasurement Windowを明示する。

⸻

Interventionを独立して記述する

次に、何を行ったかを固定する。

これは重要である。

「AIを導入した」

では粗すぎる。

同じAI導入でも内容は異なる。

たとえば、

RAGを追加した。

CRMと接続した。

Agentを導入した。

Workflowを変更した。

Human Approvalを再設計した。

社員Trainingを行った。

業務Ruleを変更した。

という複数の介入が存在する。

したがって、

[
Intervention

Technology
+
Process
+
Organization
+
Governance
]

として記述する。

⸻

たとえば、

@dataclass
class Intervention:
   intervention_id: str
   problem_id: str
   started_at: datetime
   production_at: datetime
   version: str
   description: str

Versionを持つことも重要である。

AI Systemは継続的に更新されるため、

[
Intervention_1
\neq
Intervention_2
]

だからである。

⸻

Interventionの境界を決める

Production Releaseが介入開始なのか。

Training開始なのか。

全User展開なのか。

この境界を曖昧にするとBeforeとAfterが混ざる。

そこで、

[
T_0

Intervention\ Boundary
]

を明示する。

⸻

たとえば、

Before
─────── T0 ─────── After
       ↑
 Production開始

とする。

ただし、導入直後にはLearning Periodがある場合もある。

その場合、

Before
  ↓
Intervention
  ↓
Stabilization
  ↓
After Measurement

と分ける。

導入直後の混乱を、そのまま恒常的Outcomeとして扱わない。

⸻

Afterも同じ方法で測る

BeforeとAfterでMeasurement Methodを変えてはいけない。

Beforeでは人手計測。

AfterではSystem Log。

では、値の違いが業務変化なのかMeasurement Methodの違いなのか分からなくなる。

したがって、

[
Measurement_{Before}
\approx
Measurement_{After}
]

を可能な限り維持する。

⸻

同じMetric。

同じUnit。

同じPopulation。

同じCalculation Logic。

同じMeasurement Window。

を使う。

SELECT
   AVG(processing_minutes)
FROM sales_tasks
WHERE completed_at >= :after_start
 AND completed_at <  :after_end;

これによって比較可能性を保つ。

⸻

Deltaを計算する

最も単純な差分は、

[
\Delta

After-Before
]

である。

たとえば、

[
120
\rightarrow
75
]

なら、

[
\Delta=-45
]

となる。

処理時間なので低い方が良ければ、45分改善したと読む。

⸻

改善率なら、

[
Improvement\ Rate

\frac{Before-After}{Before}
]

である。

Pythonなら、

def improvement_rate(before: float, after: float) -> float:
   if before == 0:
       raise ValueError("baseline must not be zero")
   return (before - after) / before

120分から75分なら、

[
37.5%
]

の短縮である。

⸻

DirectionをMetric側に持たせる

すべてのMetricが低いほど良いわけではない。

Time。

Cost。

Error Rate。

は低い方がよい場合が多い。

Revenue。

Conversion。

Throughput。

Customer Satisfaction。

は高い方がよい場合がある。

そこで、

@dataclass
class MetricDefinition:
   metric_id: str
   unit: str
   better_when: str  # "higher" or "lower"

として方向を持つ。

⸻

こうすると評価を一般化できる。

[
Improvement

f(Before,After,Direction)
]

である。

⸻

BeforeとAfterの母集団を揃える

AI導入前は100人全員。

導入後はAI利用に積極的な20人だけ。

これでは比較が歪む。

[
Population_{Before}
\approx
Population_{After}
]

を意識する。

⸻

顧客Segment。

店舗。

部署。

担当者。

商品。

案件難易度。

などを揃える。

完全一致できない場合は、その違いをMetadataとして残す。

⸻

Case Mixを補正する

Afterの案件が簡単になっていたら、処理時間短縮がAIの効果に見える可能性がある。

そこでCase Complexityを持つ。

Simple
Medium
Complex

などへ分類し、

[
Outcome
\mid
Complexity
]

を見る。

⸻

より一般化すると、

[
Y

f(
Intervention,
Case\ Mix,
Time,
Environment
)
]

である。

OutcomeをInterventionだけの関数として扱わない。

⸻

Comparison Groupを置く

可能なら、Interventionを受けていないGroupと比較する。

たとえば、

Sales Team A
AI導入
Sales Team B
従来方式

とする。

すると、

[
Change_A
]

だけでなく、

[
Change_B
]

も観測できる。

⸻

もし両方のTeamで同時に売上が10%増えていたなら、AI以外の市場要因かもしれない。

一方、

Aだけがさらに改善しているなら、Interventionとの関係が強くなる。

⸻

Difference-in-Differences

これを簡略化すると、

[
Impact

(After_T-Before_T)

(After_C-Before_C)
]

である。

Treatment GroupとControl Groupの変化差を見る。

たとえば、

def did(
   before_treatment: float,
   after_treatment: float,
   before_control: float,
   after_control: float
) -> float:
   return (
       after_treatment - before_treatment
       - (after_control - before_control)
   )

で計算できる。

⸻

すべてのConsulting Projectでこの方法が使えるわけではない。

しかし、

[
Before
\rightarrow
After
]

だけより、

[
Treatment
\leftrightarrow
Comparison
]

を置いた方がEvidence Strengthは高くなる。

⸻

Time Trendを見る

Comparison Groupがなくても、長いTime Seriesがあれば役立つ。

Jan  120
Feb  118
Mar  121
Apr  119
May  117
Jun  Intervention
Jul   91
Aug   78
Sep   75

この場合、介入前のTrendと介入後のLevel Changeを観測できる。

[
Time
\rightarrow
Intervention
\rightarrow
Structural\ Change?
]

を見る。

⸻

一時的なSpikeではなく、持続する変化かを確認する。

⸻

Multiple Interventionを分離する

実際の企業変革では一つの施策だけが動くとは限らない。

同時に、

AI。

組織再編。

価格改定。

新CRM。

営業Training。

Marketing Campaign。

が始まることがある。

この場合、

[
Intervention_A
+
Intervention_B
+
Intervention_C
]

の効果が重なる。

⸻

無理に、

「AIが売上を17.3%増やした」

と断定してはいけない。

代わりに、

どのInterventionが同時期に存在したかを記録する。

@dataclass
class ContextEvent:
   name: str
   occurred_at: datetime
   expected_impact: str

Outcome MeasurementそのものをContext-awareにする。

⸻

External Realityも保存する

企業は外部環境の中に存在する。

景気。

為替。

季節性。

競争環境。

規制。

市場価格。

災害。

これらもOutcomeへ影響する。

したがって、

[
Enterprise\ Reality
+
External\ Reality
]

を同時に観測する。

⸻

すべてを完全にControlすることはできない。

重要なのは、知らないふりをしないことである。

⸻

Intervention Exposureを測る

AI Systemを導入しても、全員が同じだけ使うとは限らない。

そこで、

[
Exposure
]

を測る。

たとえば、

利用回数。

利用時間。

対象TaskのうちAIを使用した割合。

Agent Recommendationを閲覧した割合。

などである。

⸻

すると、

[
Outcome
\mid
Exposure
]

を見ることができる。

AIをほとんど使っていない人まで「AI導入Group」として一括評価すると、効果が見えにくくなる。

⸻

AdoptionとOutcomeの間を見る

利用したから成果が出たとは限らない。

そこで、

[
Exposure
\rightarrow
Behavior\ Change
\rightarrow
Outcome
]

を分ける。

たとえば、

AI利用
↓
調査時間短縮
↓
提案件数増加
↓
商談数増加
↓
売上変化

というChainを持つ。

このChainのどこで変化が止まっているかを見る。

⸻

Human InterventionもInterventionの一部である

AIだけを変数として見ると、Human側の変化を見落とす。

AI導入と同時に、

Training。

業務Rule。

Management。

Incentive。

Approval Flow。

が変わる場合がある。

したがって、

[
AI\ Transformation
\neq
Model\ Intervention
]

である。

⸻

むしろ、

[
AI
+
Human
+
Process
+
System
]

のCombined Interventionとして記述する。

これはSYNTHESISのようなEnterprise Transformationを評価する際に特に重要になる。

⸻

Negative Controlを考える

可能であれば、本来影響しないはずのMetricも見る。

たとえば営業提案AIを導入したのに、全く関係のない業務Metricまで同じタイミングで急改善している。

その場合、組織全体の別要因が作用している可能性がある。

こうした比較によって、

[
Causal\ Interpretation
]

を慎重にする。

⸻

Outcome Snapshotをつくる

Projectごとに、Before / Intervention / Afterを一つの構造へまとめる。

@dataclass
class OutcomeSnapshot:
   problem_id: str
   metric_id: str
   before: float
   intervention_id: str
   after: float
   delta: float
   confidence: str

これによってProjectのOutcomeをMachine-readableに比較できる。

⸻

たとえば、

Problem:
営業提案作成時間が長い
Metric:
Proposal Preparation Time
Before:
120 min
Intervention:
AI Proposal Assistant v1
After:
75 min
Delta:
-45 min
Improvement:
37.5%
Confidence:
MEDIUM

という形になる。

⸻

一つのOutcomeだけを見ない

企業Transformationでは複数Metricを同時に見る。

処理時間が短縮した。

しかしError Rateが増えた。

Costが上がった。

Employee Satisfactionが下がった。

なら、単純な成功とは言えない。

そこでOutcome Vectorとして考える。

[
\mathbf{O}

(
Time,
Cost,
Quality,
Revenue,
Risk,
Experience,
Capability
)
]

である。

⸻

BeforeとAfterをVectorとして比較する。

[
\Delta\mathbf{O}

\mathbf{O}_{after}

\mathbf{O}_{before}
]

企業Realityは一つのMetricではなく、多次元に変化する。

⸻

Outcome Scoreを急いで一つにしない

すべてのMetricを一つのScoreへ圧縮すると便利である。

しかしWeightの決め方によって結果が変わる。

RevenueとEmployee Experienceをどう比較するのか。

Security Riskと速度をどう比較するのか。

簡単ではない。

したがって、最初から万能な総合点へ変換しない。

[
Multi\text{-}metric\ Reality
]

を残す。

必要なDecisionごとにWeightを定義する。

⸻

Segment別に見る

全体平均だけでは重要な違いが消える。

AI導入によって、

新人には大きな効果。

Expertには小さな効果。

特定業務には大きな効果。

複雑案件には逆効果。

ということもある。

そこで、

[
Outcome
\mid
Segment
]

を見る。

⸻

Department。

Role。

Experience。

Customer Type。

Task Complexity。

Location。

などで分解する。

平均値の裏側にあるRealityを見る。

⸻

Distributionを見る

平均が改善しても、一部で大きな悪化が起きているかもしれない。

したがって、

Mean。

Median。

Percentile。

Variance。

を確認する。

たとえば、

[
P50
]

だけでなく、

[
P90
]

を見る。

特にLatency、Processing Time、Agent Execution TimeではTailが重要になる。

⸻

「誰にとって良くなったか」を問う

Outcomeは企業全体だけでなくStakeholderごとに異なる。

経営者。

社員。

顧客。

取引先。

System Operator。

それぞれのRealityがある。

あるAutomationによってCompany Costが下がっても、顧客待ち時間が増えるならTrade-offが存在する。

したがって、

[
Outcome

Outcome_{stakeholder}
]

という視点を持つ。

⸻

Intervention後に戻っていないか

短期効果だけではTransformationとは言いにくい。

そこでRetentionを見る。

[
After_{1m},
After_{3m},
After_{6m}
]

を観測する。

⸻

たとえば、

Before       120 min
1 month       70 min
3 months      76 min
6 months     112 min

なら、短期的改善はあったが定着していない。

この場合、

[
Initial\ Outcome
\neq
Persistent\ Outcome
]

である。

⸻

持続性をCapabilityへ接続する

なぜ効果が戻ったのか。

Systemが使われなくなった。

Data Qualityが劣化した。

Agentを更新できなかった。

Ownerがいなくなった。

Trainingが不足した。

Workflowが元に戻った。

なら、Capabilityが定着していなかった可能性がある。

ここで、

[
Outcome\ Persistence
\rightarrow
Capability
]

という関係が現れる。

⸻

SYNTHESISをどう測るか

SYNTHESISが掲げるAI-First Consultingを評価するなら、単にAI利用Project数を見るだけでは不十分である。

本書の測定単位は、

[
Problem
\rightarrow
Intervention
\rightarrow
Outcome
]

である。

さらに、

[
Outcome_t
\rightarrow
Outcome_{t+n}
]

を追う。

⸻

そしてClientが外部支援を減らしてもOutcomeを維持できるかを見る。

これは、SYNTHESISが示しているClientのより速い変革やSelf-sufficiencyという方向性を、Reality側から検証することになる。

ただし2026年9月3日時点では、個別Clientについてこの種の詳細な公開時系列Dataは十分ではない。

したがって、本書では測定Architectureを提示しつつ、未観測領域を未観測のまま残す。

⸻

Before → Intervention → Afterを閉じる

最小構造は、

[
\boxed{
Before
\rightarrow
Intervention
\rightarrow
After
}
]

である。

しかし実際には、

[
\boxed{
Context
+
Before
+
Intervention
+
Exposure
+
After
+
Comparison
+
Confidence
}
]

まで持つ。

そして結果を、

[
Outcome
\rightarrow
Learning
]

へ戻す。

⸻

変革前を正確に記録する。

何を変えたかをVersion付きで記録する。

変革後を同じ方法で測る。

外部要因と比較対象を見る。

どこまで因果的に言えるかを残す。

これによって、

「成果が出た」という説明を、「どのRealityが、どの程度、どのEvidenceで変化したか」という検証可能な記述へ変える。

次節では、その変化を企業経営の最も基本的な三つの量へ落とす。

[
\boxed{
Time
+
Cost
+
Revenue
}
]

時間・コスト・売上を測る。
第3節　時間・コスト・売上を測る

企業変革の成果を最も基本的な経営量へ落とすと、

[
\boxed{
Time
+
Cost
+
Revenue
}
]

になる。

何時間短縮されたのか。

いくら削減されたのか。

いくら価値が増えたのか。

この三つは単純に見える。

しかし実際には、どの時間を測るのか、どのCostを含めるのか、Revenueとの因果をどこまで言えるのかを明確にしなければならない。

⸻

時間を測る

AI導入で最も早く現れやすいOutcomeの一つが時間である。

Research。

Document作成。

分析。

問い合わせ対応。

Approval。

System Development。

Incident Response。

さまざまなProcessで時間を測定できる。

基本形は、

[
Time\ Saved

Time_{Before}

Time_{After}
]

である。

たとえば一件の処理が、

[
60分
\rightarrow
20分
]

になれば、

[
40分
]

短縮された。

⸻

しかし、単に一件当たりの時間だけを見るのではない。

[
Total\ Time\ Saved

Time\ Saved\ per\ Case
\times
Number\ of\ Cases
]

を見る。

一件40分の短縮でも年間10件しか発生しない業務と、年間10万件発生する業務では経営Impactが異なる。

⸻

Cycle TimeとTouch Timeを分ける

一つの業務には、実際に作業している時間と、待っている時間がある。

[
Cycle\ Time

Touch\ Time
+
Waiting\ Time
]

である。

AIがDocument作成時間を半減させても、承認待ちが三日間残ればEnd-to-Endの速度はほとんど変わらない場合がある。

したがって、

Task Time。

Approval Time。

Queue Time。

End-to-End Lead Time。

を分離する。

⸻

企業Transformationでは、

[
Local\ Optimization
\neq
Process\ Optimization
]

である。

一つのOperationだけでなく、Process全体の時間を見る。

⸻

Throughputまで見る

時間短縮によって、同じ人員でより多くの仕事を処理できる可能性がある。

そこで、

[
Throughput

\frac{Completed\ Work}{Time}
]

を見る。

たとえば営業担当者が一週間に作成できる提案件数が、

[
5
\rightarrow
8
]

へ増えたなら、単なる時間削減ではなくCapacity拡張が起きている。

[
Time\ Reduction
\rightarrow
Capacity\ Increase
]

である。

⸻

Saved TimeはValueではない

ここで注意が必要である。

1000時間削減されたからといって、その1000時間分の人件費がそのまま削減されたとは限らない。

社員がその時間で別の仕事をするなら、

[
Time\ Saved
\neq
Cash\ Saved
]

だからである。

時間短縮後の状態を区別する必要がある。

削減された時間。

再配置された時間。

新しい仕事へ使われた時間。

未利用の時間。

⸻

したがって、

[
Saved\ Time
\rightarrow
Reallocated\ Capacity
\rightarrow
Business\ Value
]

まで追う。

AI Transformationでは、このCapacity Reallocationが重要になる。

⸻

コストを測る

Costも一種類ではない。

人件費。

Cloud Cost。

Model API Cost。

Software License。

Development Cost。

Integration Cost。

Maintenance。

Training。

Security。

Change Management。

などがある。

したがって、

[
Total\ Cost

Build
+
Run
+
Change
]

として見る。

⸻

AI導入で既存業務Costが下がっても、CloudやModel利用料が増える可能性がある。

そのため、

[
Net\ Cost\ Impact

Cost_{Before}

Cost_{After}
]

を測る。

ここでAfterには、新しいAI Systemの運用費を含める。

⸻

Unit Costを見る

Total Costだけでは、事業規模の変化を誤認することがある。

処理件数が倍になればTotal Costが増えても、効率は改善している可能性がある。

そこで、

[
Unit\ Cost

\frac{Total\ Cost}{Number\ of\ Transactions}
]

を見る。

たとえば顧客問い合わせ一件当たりCost。

一件のInvoice処理Cost。

一件の提案作成Cost。

一件のCode Change Cost。

などである。

⸻

AIによるScale効果は、

[
Cost\ per\ Unit
\downarrow
]

として現れることがある。

⸻

AI固有のCostを追跡する

AIには従来Systemとは異なるCost構造がある。

Inference。

Token。

Embedding。

Vector Search。

Agent Tool Call。

Evaluation。

Human Review。

などである。

したがって、

[
AI\ Cost
]

を単なるCloud請求額としてまとめない。

Task単位までTraceできる方がよい。

⸻

概念的には、

from dataclasses import dataclass
@dataclass
class AICost:
   problem_id: str
   task_id: str
   model_cost: float
   compute_cost: float
   tool_cost: float
   review_cost: float
   def total(self) -> float:
       return (
           self.model_cost
           + self.compute_cost
           + self.tool_cost
           + self.review_cost
       )

とする。

これによって、

[
Problem
\rightarrow
Task
\rightarrow
Cost
]

を接続できる。

⸻

CostをOutcomeへ接続する

AI Costが月100万円かかっている。

この情報だけでは、高いのか安いのか判断できない。

もしそのSystemが月5000万円の追加利益を支えているなら意味が変わる。

したがって、

[
Cost
\rightarrow
Outcome
]

を接続する。

たとえば、

[
Cost\ per\ Successful\ Outcome
]

を見る。

⸻

単純化すれば、

[
ROI

\frac{Benefit-Cost}{Cost}
]

である。

ただし、Benefitに何を含めたかを明示する。

Time Savingを金額換算したのか。

実際のCash Savingなのか。

Revenue増加なのか。

Risk Reductionなのか。

これらを混ぜない。

⸻

Revenueを測る

売上は魅力的なOutcomeである。

しかし最も慎重に扱う必要がある。

AI導入後にRevenueが増えたとしても、

[
Revenue\ Increase
\neq
AI\ Impact
]

と直ちには言えない。

価格。

市場。

Marketing。

競合。

営業人員。

Seasonality。

Product Mix。

など多数の要因がある。

⸻

したがってRevenueを分解する。

たとえば、

[
Revenue

Customers
\times
Conversion
\times
Average\ Value
]

あるいは営業Processなら、

[
Leads
\rightarrow
Opportunities
\rightarrow
Proposals
\rightarrow
Wins
\rightarrow
Revenue
]

として見る。

AIがどこへ作用したのかを特定する。

⸻

Revenue Driverを測る

AI営業支援が提案作成を高速化したなら、最初に見るべきはRevenueそのものではないかもしれない。

Proposal Time。

Proposal Volume。

Response Speed。

Conversion。

Average Deal Size。

を順に見る。

[
AI
\rightarrow
Operational\ Driver
\rightarrow
Commercial\ Driver
\rightarrow
Revenue
]

というChainを測る。

⸻

この構造によって、

「AIがRevenueを増やした」

という粗い説明を避けられる。

⸻

Incremental Revenueを考える

可能であれば、

[
Incremental\ Revenue

Observed\ Revenue

Expected\ Revenue\ without\ Intervention
]

を見る。

問題は、

[
Expected\ Revenue\ without\ Intervention
]

を直接観測できないことである。

ここでComparison Group、Historical Trend、Forecastなどを使う。

つまりRevenue評価はCounterfactualの問題である。

⸻

RevenueだけでなくMarginを見る

売上が増えてもCostがそれ以上に増えれば、経済価値は弱い。

したがって、

[
Revenue
]

だけではなく、

[
Gross\ Margin
]

[
Contribution\ Margin
]

などを見る。

AI Agentによって営業件数が増えても、Model CostやHuman Review Costが過大なら改善余地がある。

⸻

時間・コスト・売上を一つのFlowにする

三つの量は独立していない。

たとえば、

[
Time
\downarrow
]

によって、

[
Capacity
\uparrow
]

し、

[
Cost\ per\ Unit
\downarrow
]

し、

さらに、

[
Revenue
\uparrow
]

する可能性がある。

⸻

したがって、

[
\boxed{
Time
\rightarrow
Capacity
\rightarrow
Cost
\rightarrow
Revenue
}
]

という経路を観測する。

ただし、これは自動的に成立する法則ではない。

各矢印をDataで確認する。

⸻

Value Treeへ変換する

たとえば営業AIなら、

[
Proposal\ Time
\downarrow
]

から、

[
Proposals\ per\ Person
\uparrow
]

へ進み、

[
Qualified\ Opportunities
\uparrow
]

し、

[
Revenue
\uparrow
]

というValue Treeを置く。

購買AIなら、

[
Analysis\ Time
\downarrow
]

[
Supplier\ Comparison
\uparrow
]

[
Purchase\ Price
\downarrow
]

[
Procurement\ Cost
\downarrow
]

となるかもしれない。

⸻

重要なのは、

[
Technical\ Intervention
\rightarrow
Economic\ Outcome
]

の途中を消さないことである。

⸻

コードでValue Flowを記録する

たとえばMetric間の関係をGraphとして保存できる。

from dataclasses import dataclass
@dataclass
class MetricRelation:
   source_metric: str
   target_metric: str
   relation_type: str
   confidence: str

たとえば、

MetricRelation(
   source_metric="proposal_time",
   target_metric="proposal_volume",
   relation_type="hypothesized_driver",
   confidence="MEDIUM"
)

とする。

これによって、

[
Metric
\rightarrow
Metric
\rightarrow
Outcome
]

をMachine-readableにできる。

⸻

Absolute ValueとRateを分ける

「Costを20%削減した」

という表現だけでは規模が分からない。

100万円の20%と100億円の20%は違う。

したがって、

[
Absolute\ Change
]

と、

[
Relative\ Change
]

を両方持つ。

⸻

たとえば、

[
Cost:
1000万円
\rightarrow
800万円
]

なら、

Absolute Reductionは200万円。

Relative Reductionは20%。

両方を保存する。

⸻

Annualizeを慎重に使う

一か月で100万円削減できたから、

年間1200万円削減。

と単純にAnnualizeしたくなる。

しかしSeasonalityや利用拡大、Cost変動がある。

したがって、

[
Observed
]

と、

[
Annualized\ Estimate
]

を分ける。

推計値を実績値として扱わない。

⸻

Avoided Costを分ける

AIによって人員削減はしていないが、事業拡大時に追加採用が不要になった。

この場合、

Cash Cost Reductionではなく、

[
Avoided\ Cost
]

である。

これは重要な経済効果だが、実際に支出が減ったこととは違う。

したがって、

Cash Saving。

Avoided Cost。

Capacity Gain。

を分けて記録する。

⸻

Opportunity Costも見る

時間短縮によって社員がより高付加価値な仕事へ移れたなら、それもValueである。

ただし金額換算には仮定が必要になる。

そこで、

[
Measured\ Outcome
]

と、

[
Estimated\ Economic\ Value
]

を分離する。

Evidence Strengthを落とさずに扱う。

⸻

Human Costを忘れない

AI導入では、新しい負担が発生することもある。

Prompt確認。

AI Output Review。

Exception処理。

Training。

System切替。

Change Management。

この時間もCostである。

[
Gross\ Time\ Saved

New\ Human\ Work

Net\ Time\ Saved
]

として見る。

⸻

「AIで30%効率化」という数字が、追加Reviewを含んでいるかどうかで意味は大きく変わる。

⸻

Risk Costも存在する

あるProcessを高速化した結果、Error Riskが増える可能性がある。

したがってCostには、

Expected Loss。

Incident Cost。

Compliance Cost。

Recovery Cost。

も影響する。

すべてを毎回金額換算する必要はない。

しかし、

[
Cost\ Reduction
]

の裏で、

[
Risk
\uparrow
]

していないかを見る。

⸻

Outcome Ledgerをつくる

Projectごとに経済Outcomeを一つのLedgerへ集める。

@dataclass
class EconomicOutcome:
   problem_id: str
   hours_saved: float
   cash_saved: float
   avoided_cost: float
   incremental_revenue: float
   incremental_margin: float
   ai_run_cost: float
   implementation_cost: float

これによって、BenefitとCostを同じ座標へ置ける。

⸻

ただし、実績と推計を混ぜない。

MEASURED
ESTIMATED
ATTRIBUTED
UNVERIFIED

のようにEvidence Typeを持たせる。

⸻

Outcome per Interventionを比較する

複数のAI Use Caseを比較するとき、

最も新しいTechnologyを使ったかではなく、

[
Outcome
\over
Cost
]

を見る。

たとえば、

Use Case Aは1000万円投資して年間1200万円のValue。

Use Case Bは200万円投資して年間1000万円のValue。

なら、投資優先順位は変わり得る。

⸻

したがってAI Portfolio全体を、

[
Problem
\times
Expected\ Outcome
\times
Implementation\ Cost
\times
Risk
]

で見る。

AI StrategyがTechnology選定からCapital Allocationへ進む。

⸻

Speed to Valueを測る

ConsultingとAI Implementationでは、最終ROIだけでなく、価値が出るまでの時間も重要になる。

[
Time\ to\ Value

T_{first\ measurable\ outcome}

T_{project\ start}
]

である。

同じ年間Valueでも、

三週間でOutcomeが出るProjectと、二年後にしか出ないProjectでは意味が違う。

⸻

特にSYNTHESISが掲げる迅速な効果創出という方向を検証するなら、

[
Time\ to\ Outcome
]

は重要な指標になる。

ただし2026年9月3日時点では、個別Clientについて詳細な公開比較Dataは十分ではない。

したがって理念と実証を分ける。

⸻

Consulting Economicsにも返ってくる

AIによってClient側の時間・Costが改善するなら、Consulting Firm自身の生産性も変わる可能性がある。

Research。

Analysis。

Architecture。

Code。

Testing。

Document Generation。

が高速化されれば、

[
Consulting\ Time
\downarrow
]

する。

ここで従来の、

[
Hours
\rightarrow
Revenue
]

という経済構造との緊張が生まれる。

⸻

短い時間で大きなOutcomeを出せるほど価値が高いのに、時間課金だけなら売上は減る可能性がある。

この問題は後のCapability章へつながる。

AI-First Consultingを本当に成立させるなら、

[
Time\ Sold
]

ではなく、

[
Value\ Generated
]

をどう経済モデルへ接続するかが重要になる。

これは2026年9月3日時点でSYNTHESISが解決済みだと確認できる問題ではない。

本書が残す検証課題である。

⸻

三つの数字だけで終わらない

Time。

Cost。

Revenue。

は経営Outcomeの強力な座標である。

しかし、

時間を短縮した結果、Decision Qualityが落ちた。

Costを削減した結果、Employee Experienceが悪化した。

Revenueを増やした結果、Riskが増えた。

なら、Transformation全体の評価は変わる。

したがって、

[
Economic\ Outcome
+
Quality
+
Risk
+
Human\ Outcome
]

を見る。

⸻

ここまでを最小化すると、

[
\boxed{
Time
\rightarrow
Capacity
}
]

[
\boxed{
Cost
\rightarrow
Economic\ Efficiency
}
]

[
\boxed{
Revenue
\rightarrow
Value\ Creation
}
]

である。

さらに、

[
\boxed{
Economic\ Outcome

Time
+
Cost
+
Revenue
}
]

を、

[
Before
\rightarrow
Intervention
\rightarrow
After
]

の中で測る。

⸻

成果をコードで測るとは、数字を大量に集めることではない。

どのProblemに対して、どのInterventionが、どの時間を短縮し、どのCostを変え、どのRevenue Driverへ作用したのかをTraceできる状態をつくることである。

しかし企業価値は経済量だけでは決まらない。

AI時代には、もう一つ重要な変化がある。

人間と組織が、より速く、より良く判断できるようになったのか。

次節では、

[
\boxed{
Decision
+
Productivity
}
]

を測る。
第4節　意思決定と生産性を測る

企業変革の成果は、時間・コスト・売上だけでは測り切れない。

AIが企業へ入ると、もう一つ重要な変化が起きる。

人間が、

より早く。

より多くのEvidenceを使い。

より一貫して。

より適切に判断できるようになる可能性である。

したがって次に測るべきなのは、

[
\boxed{
Decision
+
Productivity
}
]

である。

⸻

意思決定をOutcomeとして扱う

企業はDecisionの連続によって動く。

何を売るか。

誰へ売るか。

何を買うか。

どこへ投資するか。

誰を採用するか。

何を止めるか。

どのSystemをつくるか。

どのRiskを受け入れるか。

つまり、

[
Enterprise

Sequence\ of\ Decisions
]

と見ることもできる。

AIがこのDecision Processを改善するなら、それ自体が重要なOutcomeになる。

⸻

Decision Timeを測る

最も基本的なのは、判断までにかかる時間である。

[
Decision\ Lead\ Time

T_{decision}

T_{question}
]

たとえば、

問題発生から方針決定まで。

顧客問い合わせから回答決定まで。

投資案件の起案から承認まで。

異常検知から対応決定まで。

を測る。

AIによって情報探索や分析が高速化されれば、

[
Decision\ Lead\ Time
\downarrow
]

する可能性がある。

⸻

しかし、単に速ければよいわけではない。

誤った判断を高速化しても価値はない。

したがって、

[
Decision\ Speed
\neq
Decision\ Quality
]

を分ける。

⸻

Decision Qualityとは何か

意思決定の質は直接測りにくい。

そこで複数のProxyへ分解する。

Evidenceを参照したか。

重要な選択肢を比較したか。

Riskを確認したか。

予測と結果がどの程度一致したか。

後から大きな修正が必要になったか。

DecisionがOutcomeにつながったか。

などである。

⸻

たとえば、

[
Decision\ Quality

f(
Evidence,
Alternatives,
Accuracy,
Outcome,
Rework
)
]

として考える。

単一のScoreへ急いで圧縮せず、構成要素を保持する。

⸻

Evidence利用を測る

AI時代のDecisionで重要なのは、回答を得ることではない。

どのEvidenceを使って判断したかである。

そこでDecisionごとに、

Decision
↓
Evidence
↓
Source
↓
Confidence

を残す。

⸻

たとえば、

from dataclasses import dataclass
@dataclass
class DecisionRecord:
   decision_id: str
   problem_id: str
   evidence_count: int
   alternatives_considered: int
   confidence: str
   decided_by: str

のように記録できる。

これによって、

[
Decision
\rightarrow
Evidence
]

を追跡できる。

⸻

AI RecommendationとHuman Decisionを分ける

AIがRecommendationを出したからといって、それがDecisionではない。

[
AI\ Recommendation
\neq
Human\ Decision
]

である。

この二つを分けて保存する。

AI Recommendation
      ↓
Human Review
      ↓
Decision
      ↓
Action
      ↓
Outcome

すると、

AI Recommendationが採用されたか。

修正されたか。

却下されたか。

その結果どうなったか。

を測れる。

⸻

Overrideを失敗と決めつけない

HumanがAIをOverrideしたからといって、AI Systemが失敗したとは限らない。

AIが持っていないContextをHumanが持っていた可能性がある。

逆に、HumanがAI Recommendationを無視して悪いOutcomeになった可能性もある。

したがって、

[
Override
]

自体ではなく、

[
Override
\rightarrow
Outcome
]

を見る。

⸻

Override Reasonも保存する。

Data不足。

Business Context。

顧客事情。

Risk。

倫理・法務。

Strategic Judgment。

などである。

Human JudgmentをLearning Dataへ変える。

⸻

Decision Reworkを測る

一度決めたことをすぐやり直すなら、Decision Qualityが低かった可能性がある。

そこで、

[
Decision\ Rework\ Rate
]

を見る。

たとえば、

決定後30日以内の大幅修正率。

承認差戻し率。

再検討回数。

追加Evidence要求回数。

などである。

⸻

ただし、環境変化による適切なDecision Revisionまで失敗扱いしてはいけない。

重要なのは、

「最初の判断が不十分だったためのやり直し」

と、

「Realityが変わったための再判断」

を分けることである。

⸻

Decision Calibrationを見る

予測を伴うDecisionでは、Confidenceと実績の関係を測れる。

たとえば、

「成功確率80%」

と判断した案件群が、本当におおむね80%成功しているかを見る。

[
Predicted\ Probability
\leftrightarrow
Observed\ Frequency
]

である。

これによって、

AIだけでなくHuman-AI Team全体の判断Calibrationを測ることができる。

⸻

意思決定の一貫性を測る

同じ条件なのに担当者によって判断が大きく変わる業務もある。

AIによってEvidenceや基準を揃えることで、

[
Decision\ Variance
\downarrow
]

する可能性がある。

ただし一貫性が高ければ必ず良いわけではない。

間違った基準へ統一されるRiskもある。

したがって、

[
Consistency
+
Outcome
]

を同時に見る。

⸻

Productivityを「作業量」だけにしない

次に生産性を見る。

最も単純な式は、

[
Productivity

\frac{Output}{Input}
]

である。

しかしKnowledge Workでは、Output Countだけでは十分ではない。

Reportを多く作った。

Codeを多く書いた。

Meetingを多く処理した。

それだけでは価値を意味しない。

⸻

そこで、

[
\boxed{
Productivity

Useful\ Outcome
\over
Resources
}
]

として見る。

Resourceには、

Human Time。

AI Cost。

Compute。

Capital。

Management Attention。

などを含める。

⸻

ActivityからValueへ移す

AI導入ではActivity Metricが増えやすい。

生成されたDocument数。

Prompt数。

Agent実行数。

Code行数。

これらは利用状況を示すが、生産性そのものではない。

[
Activity
\neq
Productivity
]

である。

⸻

たとえば、

100件の提案書を生成した。

しかし実際に使われたのは10件。

なら、

Generated Outputより、

[
Accepted\ Useful\ Output
]

を見る方が重要になる。

⸻

Useful Outputを定義する

業務ごとにUseful Outputを決める。

営業なら、

Qualified Proposal。

Resolved Customer Request。

Closed Opportunity。

開発なら、

Accepted Change。

Production Release。

Resolved Incident。

Researchなら、

Verified Finding。

Decision-ready Evidence。

といった単位である。

⸻

すると、

[
Productivity

\frac{Useful\ Work}{Human\ Time + AI\ Cost}
]

として比較できる。

⸻

Human ProductivityとSystem Productivityを分ける

AIによって一人当たり処理量が増えたとしても、System全体のCostが過大なら効率的とは限らない。

そこで、

[
Human\ Productivity
]

と、

[
System\ Productivity
]

を分ける。

Human Productivityは、

[
Useful\ Output
\over
Human\ Hours
]

System Productivityは、

[
Useful\ Outcome
\over
Total\ Resources
]

として見る。

⸻

AIはHuman Productivityを高めても、Compute Costを増やす場合がある。

両方を見なければならない。

⸻

Quality-adjusted Productivity

生産性を量だけで測ると、品質劣化を見落とす。

そこで、

[
Quality\text{-}Adjusted\ Productivity

\frac{Output \times Quality}{Input}
]

という考え方を使う。

たとえば、

処理件数。

Accuracy。

Customer Satisfaction。

Rework Rate。

を組み合わせる。

⸻

Code生成なら、

生成量ではなく、

Review通過率。

Test成功率。

Defect Rate。

Production Incident。

を見る。

AI時代ほど、

[
More
\neq
Better
]

を守る必要がある。

⸻

Reworkを生産性Costとして測る

AIは初回Outputを高速化しても、修正が大量に必要なら実質的な生産性は上がらない。

そこで、

[
Net\ Productivity
]

を見る。

概念的には、

[
Net\ Time\ Saved

Gross\ Time\ Saved

Review

Correction

Recovery
]

である。

⸻

Human Review Costを含めることで、見かけ上のAutomation率に惑わされにくくなる。

⸻

Automation Rateだけを追わない

AI導入では、

[
Automation\ Rate
]

が使われることがある。

しかし、自動化率を最大化することが目的ではない。

Riskの高いDecisionをHumanが判断する方が合理的な場合もある。

したがって、

[
Best\ Automation\ Rate
\neq
100%
]

である。

⸻

測るべきなのは、

どのOperationをAIへ委譲したか。

どこにHuman Judgmentを残したか。

その結果Outcomeが改善したか。

である。

⸻

Human Attentionを測る

AI時代には、人間の時間以上にAttentionが希少資源になる。

大量のAI Recommendation。

大量のAlert。

大量のApproval Request。

が届けば、Humanは処理できなくなる。

そこで、

[
Human\ Attention\ Load
]

を見る。

たとえば、

一人当たりApproval数。

Alert数。

Review時間。

Interruptions。

Escalation数。

などである。

⸻

AIが作業を減らしながら、Human Attentionを増やしているなら設計を見直す必要がある。

[
Automation
\uparrow
]

なのに、

[
Attention\ Burden
\uparrow
]

という逆説が起こり得るからである。

⸻

Decision Densityという見方

AIによってRoutine Workが圧縮されると、人間一人がより多くの重要Decisionを扱える可能性がある。

そこで、

[
Decision\ Density

\frac{Meaningful\ Decisions}{Human\ Time}
]

という見方ができる。

ただし、Decision数を増やすこと自体が目的ではない。

より重要な判断へHuman Attentionを移せたかを見る。

⸻

Work Mixの変化を測る

AI Transformationの重要なOutcomeの一つは、Human Workの構成が変わることである。

Beforeでは、

Search
Data Gathering
Formatting
Repetition
Coordination

に多くの時間を使っていた。

Afterでは、

Judgment
Problem Framing
Relationship
Creativity
Architecture
Learning

へ移る可能性がある。

⸻

したがって、

[
Work\ Mix_{Before}
\rightarrow
Work\ Mix_{After}
]

を測る。

単なる時間削減ではなく、

人間の時間が何へ再配分されたか

を見る。

⸻

Productivity Gainを再配分まで追う

AIで週10時間削減された。

その10時間が、

顧客対話へ移った。

新規案件探索へ移った。

学習へ移った。

余剰になった。

ではOutcomeが違う。

したがって、

[
Productivity\ Gain
\rightarrow
Capacity\ Allocation
]

まで追跡する。

これは前節のTime Savedを経営価値へ接続する。

⸻

Team Productivityを見る

Knowledge Workは個人だけで完結しない。

AI導入によって一人の生産性が上がっても、他のTeamへ大量の確認作業を移していれば全体では改善していない。

したがって、

[
Local\ Productivity
\neq
Team\ Productivity
]

である。

⸻

End-to-End Processで、

営業。

法務。

Finance。

IT。

Management。

などを横断して測る。

AIがどこか一部署の負荷を別部署へ移しただけではないかを見る。

⸻

QueueとBottleneckを見る

一つの工程が高速化すると、別の工程が新しいBottleneckになる。

たとえば、

AIでProposal Draft作成が10倍速くなった。

しかしManager Approvalは従来通り。

すると、

[
Draft\ Queue
\rightarrow
Approval\ Queue
]

へBottleneckが移る。

⸻

したがって、

[
Productivity
]

を個別TaskではなくSystem Flowとして測る。

[
Throughput

f(Bottleneck)
]

である。

AI TransformationはProcess全体の再設計でなければならない。

⸻

Learning Productivityも見る

AI時代には、単に仕事を多く処理するだけでなく、組織がどれだけ速く学習するかが重要になる。

たとえば、

Experiment数。

Hypothesis検証時間。

Feedbackから改善までの時間。

Release Frequency。

FailureからPolicy更新までの時間。

を見る。

⸻

これを、

[
Learning\ Velocity
]

として扱う。

[
Observe
\rightarrow
Learn
\rightarrow
Change
]

のCycleが速くなれば、企業の適応能力が上がる。

⸻

Productivityをコードで測る

概念的には、

from dataclasses import dataclass
@dataclass
class ProductivityMetric:
   useful_outputs: float
   human_hours: float
   ai_cost: float
   rework_hours: float
   def human_productivity(self) -> float:
       return self.useful_outputs / self.human_hours
   def net_human_hours(self) -> float:
       return self.human_hours + self.rework_hours

のように記述できる。

⸻

Decision側も、

@dataclass
class DecisionMetric:
   decision_id: str
   lead_time_minutes: float
   evidence_count: int
   alternatives_count: int
   rework_count: int
   outcome_score: float | None

として保存できる。

重要なのは、DecisionとOutcomeを後から接続できることである。

⸻

Decision → Action → Outcome

最終的には、

[
Decision
\rightarrow
Action
\rightarrow
Outcome
]

をTraceする。

良いDecisionだったかどうかは、Decision時点のEvidenceだけでなく、結果からも学習する。

⸻

ただしOutcomeが悪かったからDecisionも悪かったとは限らない。

不確実な環境では、合理的なDecisionでも悪い結果が起こり得る。

したがって、

[
Decision\ Quality
\neq
Outcome\ Alone
]

である。

Decision時点で利用可能だったInformationを保存しておく意味がここにある。

⸻

AIが判断能力を弱めていないか

AI導入には逆方向のRiskもある。

人間がRecommendationを確認せず受け入れる。

自分でEvidenceを読まなくなる。

理由を説明できなくなる。

異常時に判断できなくなる。

いわゆるAutomation BiasやSkill Atrophyである。

⸻

そのため、

Human Override。

Evidence Inspection。

Manual Capability。

Exception Handling。

Learning。

も観測する。

[
AI\ Assistance
\uparrow
]

と同時に、

[
Human\ Judgment
\downarrow
]

していないかを見る。

⸻

ProductivityとCapabilityを接続する

本書では、生産性向上だけでは最終成果としない。

ConsultantやAIがいるときだけ生産性が高いのであれば、そのOutcomeは外部Capabilityに依存している。

そこで、

[
Productivity_{with\ support}
]

と、

[
Productivity_{client\ operated}
]

を比較する。

⸻

Clientが自らSystemを運用し、改善しながら同程度以上のOutcomeを維持できるなら、

[
Productivity
\rightarrow
Capability
]

への変換が始まっている。

⸻

SYNTHESISをこの座標で見る

SYNTHESISがAI-First Consultingを成立させるなら、測るべきなのはAI利用量ではない。

ClientのDecision Lead Timeが短くなったか。

Evidenceに基づく判断が増えたか。

Meaningful Human Workへ時間が移ったか。

Useful Output per Resourceが改善したか。

Learning Velocityが上がったか。

そして、それをClient自身が維持できるようになったか。

である。

⸻

2026年9月3日時点では、こうしたClient別の詳細な公開Measurement Dataは十分ではない。

したがって、

[
AI\text{-}First
\rightarrow
Decision/Productivity\ Improvement
]

は検証すべき仮説として置く。

方向性と実証を分離する。

⸻

最小構造

意思決定は、

[
\boxed{
Question
\rightarrow
Evidence
\rightarrow
Decision
\rightarrow
Action
\rightarrow
Outcome
}
]

として測る。

生産性は、

[
\boxed{
Useful\ Outcome
\over
Human\ Time
+
AI\ Cost
+
Rework
}
]

として測る。

そして両者を接続する。

[
Better\ Decision
\rightarrow
Better\ Action
\rightarrow
Higher\ Productivity
\rightarrow
Outcome
]

ただし、この矢印を前提にしない。

Realityによって確認する。

⸻

AI時代の生産性とは、人間を高速に働かせることではない。

AIに任せられるOperationを移し、人間のAttentionをより重要な判断へ再配分し、組織全体としてより良いOutcomeを少ないResourceで生成できる状態をつくることである。

しかし、AIが存在しても人間が使わなければ、その構造はRealityにならない。

次に測るべきなのは、

[
\boxed{
AI\ Adoption
}
]

である。

ただし利用率を数えるだけではない。

AIが企業の日常業務へ本当に組み込まれたのかを測る。
第5節　AI Adoptionを測る

AIを導入しただけでは、企業は変わらない。

Accountを発行した。

Agentを公開した。

Trainingを実施した。

利用者数が増えた。

これらは導入状況を示すが、AIが企業の日常業務へ定着したことを意味しない。

[
\boxed{
Deployment
\neq
Adoption
}
]

AI Adoptionとは、AIが実際の業務、判断、Workflowの中へ入り、人間の行動と企業Processを継続的に変えている状態である。

⸻

利用率から始める

最も基本的な指標は利用である。

Active User。

Session。

Agent Execution。

Task Count。

Frequency。

対象業務に対するAI利用率。

たとえば、

[
Adoption\ Rate

\frac{AIを利用した対象者}{AIを利用可能な対象者}
]

として測ることができる。

しかし、これだけでは弱い。

月に一度開いただけのUserと、毎日の業務に組み込んでいるUserが同じ一人として数えられるからである。

⸻

FrequencyとDepthを分ける

利用には頻度と深さがある。

[
Adoption

Frequency
+
Depth
]

Frequencyは、どれくらい繰り返し使うか。

Depthは、業務ProcessのどこまでAIが入っているかである。

たとえば、

検索だけに使う。

下書きをつくる。

分析に使う。

Decisionを支援する。

Workflowを実行する。

という段階では意味が違う。

⸻

概念的には、

Level 0
未利用
Level 1
Search / Ask
Level 2
Generate / Analyze
Level 3
Workflow Support
Level 4
Decision Support
Level 5
Controlled Execution

のように分類できる。

重要なのはLevelを上げること自体ではない。

業務RiskとValueに合った深さへ到達しているかを見る。

⸻

AdoptionをTask単位で測る

User単位だけでは、何に使われているのかが分からない。

そこで、

[
User
\rightarrow
Task
\rightarrow
AI\ Usage
]

へ分解する。

たとえば営業担当者がAIを毎日使っていても、実際にはMeeting要約だけかもしれない。

一方、利用頻度は低くても、重要な投資判断や契約Reviewに使われている場合もある。

したがって、

[
Adoption\ Value
\neq
Usage\ Frequency\ Alone
]

である。

⸻

Eligible Taskを定義する

AI Adoption Rateの分母も重要になる。

全業務をAI化する必要はない。

そこで、

[
Eligible\ Tasks
]

を定義する。

AIによる支援が適しているTask。

Human Judgmentを中心に残すTask。

AutomationすべきTask。

AIを使うべきでないTask。

を分ける。

⸻

そして、

[
Task\ Adoption\ Rate

\frac{AIを利用した適格Task数}
{AI利用が適切なTask数}
]

を見る。

これなら「全社員がAIを使っているか」ではなく、「使う価値のある場所へAIが入ったか」を測れる。

⸻

Adoption Funnelをつくる

AI Adoptionにも段階がある。

Available
  ↓
Aware
  ↓
Tried
  ↓
Repeated
  ↓
Embedded
  ↓
Value-producing

利用可能になった。

存在を知った。

試した。

繰り返し使った。

業務へ組み込んだ。

Outcomeを生み出した。

⸻

このFunnelを見ると、どこでAdoptionが止まっているかが分かる。

認知が低いのか。

初回利用で離脱するのか。

繰り返し使われないのか。

Workflowへ入らないのか。

Outcomeへつながらないのか。

問題を分解できる。

⸻

Activationを測る

AI Toolを一度開いたことではなく、最初の価値体験までを見る。

たとえば、

初めて有用な回答を得た。

初めて業務時間を短縮した。

初めてAgent Recommendationを採用した。

初めてWorkflowを完了した。

これを、

[
Activation
]

として扱う。

[
Available
\rightarrow
First\ Value
]

までの時間も重要になる。

⸻

Time to First Value

導入から最初の価値体験までが長いと、定着しにくい。

そこで、

[
Time\ to\ First\ Value

T_{first\ useful\ outcome}

T_{access\ enabled}
]

を測る。

AI Adoptionの初期設計では、この時間を短縮することが重要になる。

Training資料を増やすだけではなく、最初の業務Valueへ早く到達させる。

⸻

Retentionを見る

初月だけ利用が増えても意味はない。

そこで、

[
Retention
]

を見る。

1週間後。

1か月後。

3か月後。

6か月後。

に継続利用しているかを測る。

Trial
↓
Week 1
↓
Month 1
↓
Month 3
↓
Month 6

⸻

Adoptionは一度の利用ではなく、

[
Repeated\ Useful\ Use
]

である。

⸻

Cohortで見る

全体利用率だけを見ると、新規利用者の増加によって既存Userの離脱が隠れることがある。

そこで導入時期ごとにCohortを分ける。

[
Retention_{cohort}
]

を見る。

たとえば4月導入Groupと6月導入Groupの継続率を比較する。

これにより、Product改善やTraining改善がAdoptionへ効いているかを確認できる。

⸻

AIを使う理由を測る

利用回数だけでは、人間がなぜ使うのか分からない。

AI Adoptionが続く理由には、

速い。

便利。

品質が高い。

探しやすい。

既存Workflowへ入っている。

Managementが求めている。

などがある。

逆に使わない理由には、

精度への不信。

使い方が分からない。

既存Toolの方が速い。

Context入力が面倒。

承認Processが複雑。

AccessできないDataが多い。

などがある。

⸻

したがって、

[
Usage\ Data
+
User\ Evidence
]

を組み合わせる。

Logだけでは見えない摩擦を観測する。

⸻

Adoption Frictionを測る

AIが使われない原因を、

[
Friction
]

として記述する。

たとえば、

Access Friction。

Data Friction。

Workflow Friction。

Trust Friction。

Skill Friction。

Governance Friction。

である。

⸻

概念的には、

[
Adoption

Value

Friction
]

として考えられる。

もちろん厳密な数式ではない。

しかし、利用促進を「社員の意識」の問題だけにしないための重要な見方である。

⸻

Context Switchingを測る

前章で見たように、AIを別画面として置くと利用Costが生まれる。

業務SystemからDataをコピーする。

AIへ貼る。

結果をコピーする。

元Systemへ戻す。

この往復が多いほどAdoptionは下がりやすい。

そこで、

[
Context\ Switches\ per\ Task
]

を見る。

⸻

AIが既存Workflowへ組み込まれれば、

[
Context\ Switching
\downarrow
]

し、Adoptionが自然になる。

AI AdoptionはChange ManagementだけでなくInterface Architectureの問題でもある。

⸻

Recommendation Acceptanceを測る

Decision Support AIなら、

AI Recommendationがどの程度使われたかを見る。

[
Acceptance\ Rate

\frac{Accepted\ Recommendations}
{Total\ Recommendations}
]

である。

しかしAcceptance Rateが高ければ良いとは限らない。

100%なら、Humanが内容を確認せず受け入れている可能性もある。

⸻

そこで、

Accepted。

Modified。

Rejected。

Escalated。

を分ける。

Recommendation
├─ Accepted
├─ Modified
├─ Rejected
└─ Escalated

そして最終Outcomeと接続する。

⸻

Trustを行動から見る

「AIを信頼していますか」

というSurveyだけでは十分ではない。

実際の行動を見る。

Recommendationを確認する。

Evidenceを開く。

修正する。

Overrideする。

重要なTaskで使う。

繰り返し利用する。

これらから、

[
Behavioral\ Trust
]

を見る。

⸻

Trustが低すぎれば使われない。

高すぎればAutomation Biasが起こる。

したがって目標は、

[
Calibrated\ Trust
]

である。

AIが得意な場面では利用し、弱い場面では確認する。

その状態を設計する。

⸻

AdoptionとQualityを同時に見る

利用率を上げるだけなら、Mandatory Useにすることもできる。

しかしそれでは意味がない。

[
High\ Adoption
+
Low\ Quality
]

では、企業全体へ低品質なAIを拡散することになる。

したがって、

[
Adoption
\times
Quality
]

を見る。

⸻

たとえば、

Task Completion Rate。

Correction Rate。

Hallucination Incident。

Human Override。

Customer Complaint。

などと利用率を並べる。

ScaleするほどQuality ControlもScaleさせる。

⸻

AdoptionとOutcomeを接続する

最も重要なのは、

[
Adoption
\rightarrow
Outcome
]

が成立しているかである。

利用率が上がった。

しかしTime、Cost、Revenue、Decision Qualityが変わらない。

なら、AIがBusiness Valueへ変換されていない可能性がある。

⸻

そこで、

[
Outcome
\mid
Adoption\ Level
]

を見る。

高利用Group。

中利用Group。

低利用Group。

でOutcomeに差があるかを比較する。

ただし、能力の高い人ほどAIも多く使うなどSelection Biasがあるため、因果を即断しない。

⸻

Adoption → Behavior → Outcome

本書ではAdoptionを中間変数として扱う。

[
\boxed{
AI\ Availability
\rightarrow
Adoption
\rightarrow
Behavior\ Change
\rightarrow
Outcome
}
]

である。

AIを利用した。

その結果、調査方法が変わった。

Decision Processが変わった。

業務時間が変わった。

そしてBusiness Outcomeが変わった。

このChainを見る。

⸻

Shadow Adoptionを区別する

企業では正式Toolではなく、個人が外部AIを使っていることもある。

これは潜在的な需要を示す一方で、SecurityやData GovernanceのRiskになる。

したがって、

[
Official\ Adoption
]

だけではなく、

[
Unmanaged\ AI\ Use
]

の存在も把握する必要がある。

目的は監視ではない。

なぜ正式環境ではなく別のToolが選ばれているのかを理解することである。

⸻

そこには、

使い勝手。

Model Quality。

Access制限。

Workflowとの不整合。

など、Architecture上の問題が隠れている可能性がある。

⸻

RoleごとにAdoptionを分ける

AIの使い方はRoleによって異なる。

Executive。

Consultant。

Engineer。

Sales。

Finance。

HR。

Operation。

では適切なUse Caseが違う。

したがって、

[
Adoption_{role}
]

を見る。

全社平均だけでは、特定部署の未定着や過度な依存を見落とす。

⸻

Task Complexityごとに見る

Simple TaskではAI利用率が高い。

Complex Taskでは低い。

ということもある。

それ自体は問題ではない。

むしろ重要なのは、

[
Adoption
\mid
Task\ Complexity
]

である。

AI CapabilityとHuman Judgmentの境界が適切に設計されているかを見る。

⸻

Trainingの効果を測る

Trainingを実施したことを成果にしない。

[
Training
\neq
Capability
]

である。

Training前後で、

Activation。

Retention。

Task Adoption。

Quality。

Outcome。

が変わったかを見る。

⸻

さらに、

[
Training
\rightarrow
Independent\ Use
]

へ進んだかを測る。

受講者数ではなく、業務行動の変化を見る。

⸻

Champion依存を測る

AI導入初期には、少数の熱心なUserが全体を支えることがある。

これは重要だが、組織Capabilityとしては脆い。

その人が異動すると使われなくなる可能性があるからである。

そこで、

[
Adoption\ Concentration
]

を見る。

⸻

利用が一部Userへ極端に集中していないか。

Knowledgeが共有されているか。

複数人が運用できるか。

を見る。

[
Individual\ Adoption
\rightarrow
Organizational\ Adoption
]

へ進む必要がある。

⸻

AI Adoptionをコードで記録する

たとえばTask単位で、

from dataclasses import dataclass
from datetime import datetime
@dataclass
class AIAdoptionEvent:
   user_id: str
   role: str
   task_type: str
   ai_used: bool
   recommendation_status: str | None
   occurred_at: datetime

を記録する。

集約すれば、

利用率。

Task別利用率。

Role別利用率。

Retention。

Acceptance。

などを計算できる。

⸻

しかしPrivacyには注意する。

個人を過度に監視する仕組みにしない。

目的は、

[
Employee\ Surveillance
]

ではなく、

[
System\ Improvement
]

である。

必要な粒度へAggregationし、目的・権限・保持期間を明確にする。

⸻

Adoption Dashboardの最小構造

AI Adoption Dashboardには、単なるMAUだけでなく、

Availability
Activation
Retention
Task Adoption
Workflow Depth
Quality
Outcome
Friction

を置く。

これによって、

「何人使ったか」

から、

「企業のどこへ定着し、何を変えたか」

へ進める。

⸻

Adoption成熟度を見る

AI Adoptionは、次のような変化として捉えられる。

[
Optional
\rightarrow
Useful
\rightarrow
Repeated
\rightarrow
Embedded
\rightarrow
Operational
]

最初は個人が試す。

次に価値が認識される。

繰り返し使われる。

Workflowへ組み込まれる。

最終的には通常業務の一部になる。

⸻

しかし最終段階でもHuman AuthorityやGovernanceを失ってはいけない。

[
Embedded
\neq
Uncontrolled
]

である。

⸻

Adoptionの先にSelf-sufficiencyがある

AIが日常業務へ定着しても、外部Consultantが毎回設定を直し、Promptを変更し、Agentを保守しなければ動かないなら、Client Capabilityは限定的である。

そこで次の問いが生まれる。

Client自身が、

Userを追加できるか。

Use Caseを設計できるか。

Workflowを変更できるか。

Agentを評価できるか。

Policyを更新できるか。

障害へ対応できるか。

Outcomeを測れるか。

⸻

つまり、

[
Adoption
\neq
Self\text{-}sufficiency
]

である。

Adoptionは「使っているか」。

Self-sufficiencyは「自分たちで動かせるか」。

この二つを分ける。

⸻

SYNTHESISをAdoptionから検証する

SYNTHESISがAI-First Consultingを企業へ実装するなら、重要なのはAI Toolを納品することではない。

Client Organizationの中で、

AIが繰り返し使われる。

Workflowへ組み込まれる。

Decisionが変わる。

Outcomeが生まれる。

そして外部支援が減っても運用できる。

という状態へ到達する必要がある。

⸻

2026年9月3日時点では、SYNTHESISのClientごとのActivation、Retention、Task Adoption、Self-sufficiencyなどを示す詳細な公開定量Dataは十分ではない。

したがって、

[
AI\text{-}First
\rightarrow
Sustainable\ Adoption
]

は、本書がRealityによって今後検証すべき重要な命題である。

⸻

最小構造

AI Adoptionを最小化すると、

[
\boxed{
Available
\rightarrow
Used
\rightarrow
Repeated
\rightarrow
Embedded
\rightarrow
Outcome
}
]

となる。

しかしCapability Generationまで含めれば、

[
\boxed{
Available
\rightarrow
Adoption
\rightarrow
Behavior
\rightarrow
Outcome
\rightarrow
Self\text{-}sufficiency
}
]

へ進む。

利用率は入口にすぎない。

AI Adoptionの本当の意味は、AIが日常業務へ入り、行動を変え、その変化が継続的なOutcomeへつながったかにある。

そして次の境界は、さらに厳しい。

ClientはAIを使えるようになっただけなのか。それとも、外部支援がなくてもAIを運用し、改善し、次の変革を起こせるようになったのか。

次節では、

[
\boxed{
Self\text{-}sufficiency
}
]

を測る。
第6節　Self-sufficiencyを測る

AIを使えるようになったことと、AIを自分たちで運用できることは同じではない。

外部Consultantが常に設定を変更する。

障害が起きるたびに外部へ問い合わせる。

新しいUse Caseを追加するたびにProjectを発注する。

Outcomeを測る仕組みも外部が管理する。

この状態では、Adoptionは進んでいても、Client Capabilityは十分に内部化されていない。

したがって次に測るべきなのは、

[
\boxed{
Self\text{-}sufficiency
}
]

である。

本書ではSelf-sufficiencyを、

外部支援が減少しても、Clientが自らAI・Data・System・業務を運用し、改善し、次の変革を起こせる程度

として定義する。

⸻

Self-sufficiencyは外部支援ゼロではない

最初に重要な境界を置く。

Self-sufficiencyとは、外部企業を一切使わなくなることではない。

高度な専門技術。

大規模Migration。

Security Assessment。

新しいArchitecture。

特殊なAI Research。

などで外部Expertiseを使うことは合理的である。

したがって、

[
Self\text{-}sufficiency
\neq
No\ External\ Support
]

である。

重要なのは、

[
\boxed{
External\ Support

Choice
}
]

となっているかである。

外部支援がなければ通常業務すら止まる状態と、必要なときに戦略的に外部Capabilityを利用する状態は異なる。

⸻

Dependencyを分解する

Client Dependencyには複数の種類がある。

Technology Dependency。

Knowledge Dependency。

Operational Dependency。

Decision Dependency。

Vendor Dependency。

Change Dependency。

たとえばSystemを運用できても、新しいAgentを追加できなければChange Dependencyが残る。

Data Pipelineを直せても、AI Outputの品質を評価できなければKnowledge Dependencyが残る。

したがって、

[
Dependency

Technology
+
Knowledge
+
Operation
+
Decision
+
Change
]

として測る。

⸻

Operationできるか

Self-sufficiencyの第一段階は、日常運用である。

Client Teamが、

System Statusを確認する。

Userを管理する。

障害を一次診断する。

Agent実行を監視する。

Costを確認する。

定常的なConfigurationを変更する。

ことができるかを見る。

[
Run
]

の能力である。

⸻

運用能力を、

External Operated
     ↓
Co-Operated
     ↓
Client Operated

という移行で評価できる。

目標は、すべてをClientだけで抱えることではない。

Clientが自ら運用主体になれる状態である。

⸻

Diagnoseできるか

Systemは必ず失敗する。

Dataが届かない。

APIが失敗する。

Agent Qualityが下がる。

Workflowが止まる。

Costが急増する。

重要なのは、正常時に使えることだけではない。

異常時に何が起きているかを理解できるかである。

[
Self\text{-}sufficiency
\rightarrow
Diagnostic\ Capability
]

が必要になる。

⸻

Client Teamが、

症状を確認する。

Logを見る。

原因候補を絞る。

影響範囲を判断する。

Escalationの必要性を決める。

ことができるかを見る。

⸻

Recoverできるか

診断の次はRecoveryである。

Rollback。

Agent停止。

Previous Versionへの切替。

Workflow再実行。

Data Reprocessing。

Fallback Operation。

などを実行できるか。

[
Failure
\rightarrow
Diagnosis
\rightarrow
Recovery
]

をClient側でどこまで閉じられるかを見る。

これによって、運用の実質的な自立度が分かる。

⸻

Changeできるか

日常運用より重要なのが変更能力である。

企業Realityは変化する。

Business Ruleが変わる。

商品が増える。

組織が変わる。

新しいDataが追加される。

Modelが更新される。

したがってSystemを維持するだけでは足りない。

Client自身が、

PromptやPolicyを変更する。

Workflowを変更する。

新しいData Sourceを追加する。

API Integrationを追加する。

Agentを更新する。

Evaluationを変更する。

ことができるかを見る。

[
\boxed{
Run
\rightarrow
Change
}
]

への移行である。

⸻

New Use Caseを生成できるか

Self-sufficiencyのさらに上には、新しいUse Caseを自ら発見・実装する能力がある。

外部Consultantから、

「次はこのAIを導入しましょう」

と言われなければ進めない状態から、

Client自身が、

Problemを発見する。

AI適用可能性を判断する。

Expected Outcomeを定義する。

Small Experimentを設計する。

結果を測る。

Productionへ進める。

というLoopを回せる状態へ進む。

[
Problem
\rightarrow
Experiment
\rightarrow
Implementation
\rightarrow
Outcome
]

をClient内部で実行する。

⸻

Knowledgeを持っているだけでは足りない

Manualがある。

Documentがある。

Trainingを受けた。

これだけではSelf-sufficiencyではない。

[
Knowledge
\neq
Capability
]

である。

Capabilityとは、そのKnowledgeを使って実際にActionできることである。

したがってTraining Completionではなく、

実際に障害を解決できたか。

Workflowを変更できたか。

新しいUse Caseを実装できたか。

を見る。

⸻

Documentation CompletenessよりExecutionを見る

Documentが100ページあっても、誰も使えなければ意味はない。

そこで、

[
Documentation
\rightarrow
Observed\ Execution
]

まで確認する。

たとえばClient Teamだけで、

Production Deployment。

Agent Update。

Incident Recovery。

Outcome Dashboard追加。

を実際に行う。

このExecution Evidenceの方がSelf-sufficiencyを強く示す。

⸻

Time to Independenceを測る

Project開始からClientが主体運用できるようになるまでの時間を測る。

[
Time\ to\ Independence

T_{client-operated}

T_{project-start}
]

である。

短ければ良いとは限らない。

安全性や品質を犠牲にして移管してはいけない。

しかし同程度のComplexityなら、より短い時間でClient Capabilityを形成できる方がCapability Generationとして強い。

⸻

External Support Ratioを測る

運用に必要な総作業量のうち、外部が担う割合を見る。

[
External\ Support\ Ratio

\frac{External\ Work}
{External\ Work + Client\ Work}
]

Project初期には高くてもよい。

重要なのは時間とともに、

[
External\ Support\ Ratio
\downarrow
]

するかである。

⸻

ただし、単に外部作業をClientへ押し付ければよいわけではない。

OutcomeとQualityを維持しながら移る必要がある。

したがって、

[
Dependency
\downarrow
]

と同時に、

[
Outcome
\geq
Baseline
]

を確認する。

⸻

Escalation Rateを見る

Client Teamがどれだけ外部へEscalateするかも一つの指標になる。

[
Escalation\ Rate

\frac{External\ Escalations}
{Operational\ Issues}
]

ただしEscalationが少なければ必ず良いわけではない。

重大Incidentを抱え込んでいる可能性もある。

したがって、

適切なSelf-resolution。

適切なEscalation。

の両方を見る。

⸻

Independence Testを行う

Self-sufficiencyはSurveyだけでは測りにくい。

そこで実際に外部支援を限定した期間を設ける方法がある。

たとえば、

Week 1
共同運用
Week 2
Client主導
Week 3
ExternalはEscalationのみ

として、

Clientがどこまで運用できるか観測する。

これを、

[
Independence\ Test
]

として扱う。

⸻

Test項目には、

障害対応。

Release。

Policy変更。

User管理。

新しいData追加。

Outcome Measurement。

などを置く。

実行結果からCapability Gapを特定する。

⸻

Capability Matrixをつくる

Self-sufficiencyを一つの数字だけへ圧縮しない。

たとえば、

[
C

(
Operate,
Diagnose,
Recover,
Change,
Evaluate,
Govern,
Generate
)
]

というCapability Vectorで見る。

具体的には、

Operate      4/5
Diagnose     3/5
Recover      3/5
Change       2/5
Evaluate     4/5
Govern       3/5
Generate     2/5

のように可視化できる。

⸻

ここで最も高い成熟度は、単にSystemを使える状態ではない。

[
Generate
]

つまり新しいTransformationを自ら生成できる状態である。

⸻

Levelで記述する

Self-sufficiencyを段階として表すこともできる。

Level 0
External Dependent
Level 1
Client Uses
Level 2
Client Operates
Level 3
Client Changes
Level 4
Client Improves
Level 5
Client Generates Next Transformation

この構造なら、AdoptionとSelf-sufficiencyの違いが明確になる。

Level 1では使える。

Level 2では運用できる。

Level 3では変更できる。

Level 4ではOutcomeを見ながら改善できる。

Level 5では次のProblemを自ら発見し、Transformationを始められる。

⸻

Human Capabilityを測る

Self-sufficiencyはSystem Capabilityだけでは成立しない。

Client側に、

Business Owner。

Product Owner。

Data。

AI。

Engineering。

Security。

Operation。

Governance。

のCapabilityが必要になる。

すべてを専任社員として持つ必要はない。

しかし、

誰が何に責任を持つのか

が存在しなければならない。

[
Capability
+
Ownership
]

である。

⸻

Single Person Dependencyを測る

Client内部で一人だけがすべてを理解している状態も脆い。

その人が異動・退職するとCapabilityが失われる。

そこで、

[
Key\ Person\ Dependency
]

を見る。

重要Operationを複数人が実行できるか。

Knowledgeが共有されているか。

RoleのBackupがあるか。

を確認する。

⸻

Capabilityを個人から組織へ移す。

[
Individual\ Capability
\rightarrow
Organizational\ Capability
]

である。

⸻

Governanceを自分たちで更新できるか

AIは変化する。

Model。

Risk。

Regulation。

Business Use Case。

が変わる。

したがって、一度つくったPolicyを外部Consultantが永久に更新するArchitectureでは不十分である。

Client自身が、

Risk Classification。

Approval Threshold。

Allowed Tools。

Data Policy。

Evaluation Criteria。

を更新できるかを見る。

[
Governance
\rightarrow
Living\ Capability
]

である。

⸻

Outcome Measurementも内製化する

Capability Generationにとって極めて重要なのは、Clientが自分でOutcomeを測れることである。

外部ConsultantだけがDashboardをつくり、成果を解釈するのであれば、Clientは自らTransformationを改善できない。

したがってClient側で、

Metricを定義する。

Baselineを取る。

Outcomeを観測する。

Gapを分析する。

次のInterventionを決める。

ことができるかを見る。

[
Measure
\rightarrow
Learn
\rightarrow
Change
]

を内部化する。

⸻

Learning Loopを持てるか

Self-sufficiencyの中心は、実は運用ではない。

Learningである。

Systemは必ず古くなる。

最初の設計は必ず不完全である。

だからClient自身が、

[
Observe
\rightarrow
Evaluate
\rightarrow
Learn
\rightarrow
Change
]

を回せる必要がある。

⸻

ここまで来ると、

[
Self\text{-}sufficiency

Self\text{-}learning
]

に近づく。

固定された完成状態ではなく、自ら更新し続けられる状態である。

⸻

External Dependencyをゼロ目標にしない

すべてを内製化すればよいわけでもない。

Internal Costが高くなる。

Specialist Skillが不足する。

Technology変化への追従が遅くなる。

こともある。

したがって最適なのは、

[
Make
+
Partner
+
Buy
]

の組み合わせである。

Self-sufficiencyとは、

「全部自分でやる」

ではなく、

何を自分で持ち、何を外部へ委ねるかを自分で判断できること

でもある。

⸻

Strategic DependencyとUnwanted Dependencyを分ける

外部Partnerとの継続関係には二種類ある。

価値があるから継続する関係。

自分ではできないから離れられない関係。

この二つを分ける。

[
Strategic\ Partnership
\neq
Lock\text{-}in
]

である。

Capability Generation Companyを考えるなら、ClientをLock-inするほど成功という評価にはできない。

⸻

Economic Paradoxが現れる

ここでConsulting Businessの根本的な緊張が明確になる。

Client Self-sufficiencyが高まるほど、

同じOperationへの外部支援需要は減る。

[
Self\text{-}sufficiency
\uparrow
\Rightarrow
Repeated\ Dependency
\downarrow
]

これはCapability Generationという目的には成功である。

しかし、従来型Professional ServiceのRevenue Modelとは緊張する可能性がある。

⸻

だからこそ、Consultant側も次のProblemへ移動する必要がある。

[
Problem_A
\rightarrow
Capability_A
]

をClientへ残す。

そして、

[
Problem_B
]

へ進む。

これが本書でいう、

[
Dependency\ Business
\rightarrow
Frontier\ Business
]

という仮説につながる。

⸻

Self-sufficiencyをコードで測る

たとえばCapabilityごとの状態を記録する。

from dataclasses import dataclass
@dataclass
class CapabilityAssessment:
   capability: str
   client_score: int
   external_support_ratio: float
   last_verified_at: str

さらに、

@dataclass
class SelfSufficiencySnapshot:
   operate: int
   diagnose: int
   recover: int
   change: int
   evaluate: int
   govern: int
   generate: int

として、時間変化を追う。

⸻

[
C_t
\rightarrow
C_{t+1}
]

を見る。

重要なのは最終Scoreだけではない。

ProjectによってClient Capabilityが本当に増加したかである。

⸻

Self-sufficiencyとOutcomeを同時に見る

最も重要な評価は、

[
Outcome
]

と、

[
Self\text{-}sufficiency
]

を同時に見ることである。

四つの状態を考えられる。

高Outcome × 高Self-sufficiency
理想的
高Outcome × 低Self-sufficiency
成果はあるが依存が強い
低Outcome × 高Self-sufficiency
能力は残るが成果設計に問題
低Outcome × 低Self-sufficiency
変革失敗

この二軸によってProjectの質をより正確に評価できる。

⸻

SYNTHESISにとって特別な指標になる

SYNTHESISの公開された考え方には、Clientがより速くTransformationし、より早くSelf-sufficientになることを成功の重要な尺度として見る方向がある。

これは本書のCapability Generation Company仮説にとって強い接点である。

しかし、

[
Declared\ Success\ Metric
]

と、

[
Measured\ Client\ Self\text{-}sufficiency
]

は別である。

2026年9月3日時点では、ClientごとのExternal Support Ratio、Time to Independence、Client-operated Transformation₂などを詳細に示す公開Dataは十分ではない。

したがって、ここは最重要の未検証領域として残す。

⸻

最も強い検証方法

Capability Generation Companyを検証する最も強い方法は、Project終了時のSurveyではない。

その後を見ることである。

[
Transformation_1
]

が終わった後に、

Client自身が、

新しいProblemを発見し、

新しいArchitectureを設計し、

AI・Data・Systemを変更し、

新しいOutcomeを生み出したか。

つまり、

[
\boxed{
Transformation_1
\rightarrow
Client\ Learning
\rightarrow
Transformation_2
}
]

が成立したかを見る。

⸻

Transformation₂でも最初と同じ量の外部支援が必要なら、Capability Generationは限定的だった可能性がある。

逆に、Clientがより大きな部分を自ら実行できたなら、

[
Client\ Capability
\uparrow
]

したEvidenceになる。

⸻

Self-sufficiencyの最小構造

ここまでを圧縮すると、

[
\boxed{
Use
\rightarrow
Operate
\rightarrow
Diagnose
\rightarrow
Change
\rightarrow
Improve
\rightarrow
Generate
}
]

である。

AdoptionはUseを測る。

Self-sufficiencyは、その先を測る。

そして最終地点は、

[
\boxed{
Generate\ Next\ Transformation
}
]

である。

⸻

ClientがAIを使えるようになった。

それだけでは足りない。

ClientがAIを運用できる。

変更できる。

評価できる。

改善できる。

そして次のProblemへ自分で進める。

そこまで到達して初めて、外部Interventionは内部Capabilityへ変換されたと言える。

[
\boxed{
External\ Intervention
\rightarrow
Internal\ Capability
}
]

これがSelf-sufficiencyの本質である。

そしてProjectが終わった後にそのCapabilityが本当に残っているのか。

次節では、第Ⅵ部の最後として最も厳しい問いを置く。

[
\boxed{
Projectの後に何が残ったか
}
]

Outcomeが消えず、Capabilityとして残ったかを測る。
第7節　Projectの後に何が残ったか

Projectには終わりがある。

契約期間が終わる。

Consultantが離れる。

開発Teamが縮小する。

会議がなくなる。

しかし企業変革の価値は、その瞬間から初めて試される。

[
\boxed{
Project\ End
\neq
Transformation\ End
}
]

Projectの後に何が残ったのか。

それを測ることが、第Ⅵ部Outcomeの最後の問いである。

⸻

成果物は残る。

Report。

Code。

System。

Dashboard。

Manual。

Data。

しかし、成果物が残っていることと、Capabilityが残っていることは同じではない。

Systemがあっても誰も変更できない。

Dashboardがあっても誰もMetricを解釈しない。

AI Agentがあっても外部支援なしでは動かせない。

なら、Projectの価値は固定されたArtifactに閉じ込められている。

[
Artifact
\neq
Capability
]

である。

⸻

残るものを分解する

Project後に残るものは、少なくとも次の七つに分けられる。

Data。

System。

Knowledge。

Process。

Governance。

Human Capability。

Learning Loop。

これらを、

[
Residual\ Capability
]

として見る。

重要なのは「納品されたか」ではない。

Project終了後にも機能しているかである。

⸻

Dataは残ったか

Project中だけ使われた分析Dataではなく、企業が継続的に更新・利用できるDataが残ったかを見る。

Data Model。

Data Quality Rule。

Lineage。

Metric Definition。

Access Policy。

Pipeline。

がClient側へ残っているか。

[
Raw\ Data
\rightarrow
Operational\ Data\ Capability
]

へ変換されている必要がある。

⸻

Systemは運用可能か

Productionへ入ったSystemが、その後も安全に動いているか。

監視できるか。

障害へ対応できるか。

更新できるか。

Costを把握できるか。

依存Technologyが変わったときに対応できるか。

Systemが残るとは、BinaryやSource Codeが存在することではない。

[
System
+
Operation
+
Ownership
]

が残ることである。

⸻

Knowledgeは再利用できるか

Projectでは大量のKnowledgeが生まれる。

なぜこのArchitectureを選んだのか。

なぜ別案を捨てたのか。

どのDataに問題があったのか。

どのExperimentが失敗したのか。

どのDecisionがOutcomeにつながったのか。

これらが個人の記憶だけに残れば、Teamが変わると失われる。

したがって、

[
Experience
\rightarrow
Organizational\ Knowledge
]

へ変換する。

⸻

Knowledge Graph。

Decision Record。

Architecture Decision Record。

Runbook。

Evaluation History。

Outcome Data。

として保存し、次のProblemから再利用できる状態にする。

⸻

Processは変わったままか

Project中だけ新しいWorkflowを使い、終了後に従来Processへ戻ることもある。

そこで、

[
Process_{after\ project}
]

を見る。

AIが日常業務へ組み込まれているか。

Approval Ruleが維持されているか。

Roleが明確か。

旧Processとの二重運用が残っていないか。

を確認する。

一時的なProject Practiceではなく、

[
New\ Operating\ Model
]

として定着したかを測る。

⸻

Governanceは残ったか

AI Systemには継続的なGovernanceが必要である。

誰がModelを評価するのか。

誰がAgent Authorityを変更するのか。

誰がRiskを判断するのか。

誰がIncidentを処理するのか。

誰がPolicyを更新するのか。

Project終了後にこれらのOwnerが消えるなら、Governanceは実装されていなかったことになる。

[
Governance

Rule
+
Owner
+
Operation
]

である。

⸻

Human Capabilityは増えたか

最も重要なのは人間である。

Client TeamがProject前より、

Problemを構造化できる。

Dataを読める。

AIを評価できる。

Architectureについて判断できる。

Outcomeを測れる。

改善を設計できる。

ようになったかを見る。

[
Human\ Capability_{After}

Human\ Capability_{Before}
]

である。

これはTraining受講数だけでは測れない。

実際のExecutionで確認する。

⸻

Ownerが存在するか

CapabilityにはOwnerが必要である。

「会社としてできます」

では弱い。

誰が責任を持つのか。

誰が次の変更を決めるのか。

誰がOutcomeを追うのか。

を明確にする。

[
Capability
+
Ownership

Operable\ Capability
]

である。

OwnerのいないCapabilityは、時間とともに劣化する。

⸻

Learning Loopが残ったか

Project後に最も重要なのは、改善Loopが動き続けていることである。

[
Observe
\rightarrow
Measure
\rightarrow
Learn
\rightarrow
Change
]

である。

Systemが完成している必要はない。

むしろRealityの変化に応じて更新できる方が重要である。

Project終了後にも、

新しいFeedbackが入り、

Outcomeが測定され、

Gapが発見され、

Requirementが更新される。

なら、Transformationは継続している。

⸻

Residual Capabilityを測る

Project終了時点だけでなく、その後の時間軸で測る。

[
C_{end}
]

だけではなく、

[
C_{+3m},
C_{+6m},
C_{+12m}
]

を見る。

一時的にCapabilityが高くても、外部Teamが離れた後に低下することがあるからである。

したがって、

[
Capability\ Persistence
]

をOutcomeの一部として扱う。

⸻

残存率という考え方

概念的には、

[
Capability\ Retention

\frac{Capability_{after\ period}}
{Capability_{project\ end}}
]

として見ることができる。

完全な単一数値化は難しい。

しかし、

Operate。

Change。

Evaluate。

Govern。

Generate。

ごとに追跡すれば、どのCapabilityが残り、どこが失われたかを確認できる。

⸻

External Dependencyも再測定する

Project終了時にClient Operatedへ移行していても、数か月後に外部依存が戻る可能性がある。

そこで、

[
External\ Support\ Ratio_t
]

を追う。

理想は単純なゼロではない。

Clientが必要な領域だけ外部Expertiseを選択できる状態である。

[
Dependency
\rightarrow
Selective\ Partnership
]

へ変わったかを見る。

⸻

次のProblemを誰が発見したか

Capability Generationを判定するうえで強いEvidenceになるのが、次のProblemである。

Project後に、

外部Consultantが次の課題を持ち込んだのか。

Client自身が課題を発見したのか。

この違いは大きい。

[
Problem_{t+1}
]

をClient自身が観測できたなら、Problem Finding Capabilityが残っている可能性がある。

⸻

次のTransformationを誰が始めたか

さらに強い検証は、

[
Transformation_2
]

を見ることである。

Client自身が、

Problemを定義し、

Outcomeを設定し、

Dataを集め、

Architectureを選び、

AIやSystemを実装し、

結果を測ったか。

ここまで進めば、

[
Transformation_1
\rightarrow
Capability
\rightarrow
Transformation_2
]

が観測できる。

⸻

これは本書におけるCapability Generation Company仮説の最も重要な実証点になる。

⸻

Project Successを再定義する

従来のProject Successは、

Scope。

Schedule。

Budget。

Quality。

などで測られてきた。

これらは必要である。

しかしCapability Generationでは、それだけでは足りない。

[
Project\ Success

Delivery
+
Outcome
+
Residual\ Capability
]

として見る。

納品したか。

成果が出たか。

そして、その成果を再生成できる能力が残ったか。

である。

⸻

HandoverではなくCapability Transfer

Project終盤では「引き継ぎ」が行われる。

しかしDocumentを渡すだけでは弱い。

必要なのは、

[
Handover
\rightarrow
Capability\ Transfer
]

である。

見る。

一緒にやる。

Clientがやる。

外部が観察する。

Clientだけでやる。

という移行が必要になる。

Consultant Does
     ↓
Consultant + Client
     ↓
Client Does
     ↓
Consultant Observes
     ↓
Client Operates

Capabilityは説明によってではなく、Executionによって移る。

⸻

Exit Architectureを最初から設計する

Self-sufficiencyをProject終了直前に考えても遅い。

開始時点から、

誰が最終Ownerになるのか。

どのKnowledgeをClientへ残すのか。

どのOperationを移管するのか。

どのSkillを育成するのか。

どのMetricをClientが測るのか。

を設計する必要がある。

つまり、

[
Project\ Architecture
]

の中に、

[
Exit\ Architecture
]

を含める。

⸻

Consultantが抜けることをFailure Scenarioとして扱うのではない。

正常系として設計する。

これはCapability Generation Companyにとって重要なArchitecture原則になる。

⸻

CodeにもExitを埋め込む

Clientが引き継げないCodeは、Capabilityとして弱い。

したがって、

Readable Code。

Test。

Documentation。

Deployment Automation。

Infrastructure as Code。

Observability。

Runbook。

Access Ownership。

をProjectのDefinition of Doneへ含める。

⸻

概念的には、

from dataclasses import dataclass
@dataclass
class ResidualCapability:
   data_owned: bool
   system_operable: bool
   knowledge_reusable: bool
   governance_owned: bool
   client_can_change: bool
   client_can_measure: bool
   client_can_generate_next: bool

として確認できる。

ここで重要なのは最後である。

client_can_generate_next

次のTransformationを生成できるか。

⸻

Artifact Inventoryだけでは足りない

Project終了時には、何を残したかを一覧化できる。

Code Repository。

Data Model。

API。

Agent。

Dashboard。

Runbook。

Policy。

Training Material。

しかし、本書ではさらに、

[
Artifact
\rightarrow
Owner
\rightarrow
Operation
\rightarrow
Capability
]

まで追う。

誰もOwnerでないArtifactは、時間とともに死ぬ。

使われないKnowledgeは消える。

更新されないAIは劣化する。

⸻

Outcomeそのものが残っているか

Capabilityだけでなく、Outcomeの持続性も見る。

Project終了直後に処理時間が50%短縮された。

半年後にも維持されているか。

売上効果が一時的ではなかったか。

Decision Qualityが戻っていないか。

AI Adoptionが低下していないか。

を測る。

[
Outcome_{end}
\rightarrow
Outcome_{+n}
]

である。

⸻

持続していれば、

[
Persistent\ Outcome
]

になる。

さらにClient自身が改善していれば、

[
Compounding\ Outcome
]

になる。

ここまで進むと、Projectは終了していてもTransformationは進み続けている。

⸻

Projectの後にOutcomeが増える状態

最も強い状態は、Consultantが離れた後にOutcomeが増えることである。

たとえば、

Project終了時の処理時間短縮が30%。

半年後にClient自身の改善で45%。

新しいUse Caseも追加された。

なら、

[
External\ Intervention
]

が内部Learning Loopへ変換された可能性が高い。

[
Outcome_1
\rightarrow
Learning
\rightarrow
Outcome_2
]

である。

⸻

Project Memoryを残す

成功だけでなく、失敗も残す。

失敗したExperiment。

却下されたArchitecture。

効果のなかったPrompt。

採用されなかったRecommendation。

Incident。

Rollback。

これらも重要な資産になる。

[
Failure
\rightarrow
Knowledge
]

へ変換する。

同じ失敗を繰り返さないこともCapabilityである。

⸻

Client側で再利用されたか

Knowledgeが本当に残ったかを見るには、次のProjectで再利用されたかを確認する。

前回のData Modelが使われた。

Evaluation Frameworkが再利用された。

Agent Runtimeが別Use Caseへ拡張された。

Outcome Metricの定義が再利用された。

なら、

[
Reuse
]

が観測できる。

Reusable Artifactが、

[
Reusable\ Capability
]

へ変わったEvidenceになる。

⸻

SYNTHESISを最も厳しく測る問い

SYNTHESISがCapability Generation Companyへ向かっているかを判断するなら、最終的にはProject中の華やかな成果を見るだけでは足りない。

問うべきは、

SYNTHESISがいなくなった後、Clientに何が残ったか。

である。

AI Systemか。

Dataか。

Knowledgeか。

新しい業務Processか。

Human Skillか。

Governanceか。

Learning Loopか。

それとも、次のProblemを自ら解ける能力か。

⸻

2026年9月3日時点で、SYNTHESISの公開情報から確認できるのは、AI活用、実装、価値創出、Clientのより速い変革とSelf-sufficiencyを重視する方向である。

一方、

Project終了後にClient Capabilityがどの程度維持されたのか。

Transformation₂をClientがどこまで自走したのか。

外部Dependencyがどのように変化したのか。

についての詳細な公開Evidenceはまだ十分ではない。

したがって、

[
Capability\ Generation
]

はここでも結論ではなく、検証対象として残る。

⸻

第Ⅵ部の最小構造

第Ⅵ部では、成果を次の順序で測ってきた。

[
Outcome
]

から始まり、

[
Before
\rightarrow
Intervention
\rightarrow
After
]

を固定し、

[
Time
+
Cost
+
Revenue
]

を測った。

さらに、

[
Decision
+
Productivity
]

を測り、

[
AI\ Adoption
]

を測り、

[
Self\text{-}sufficiency
]

へ進んだ。

そして最後に残るのが、

[
\boxed{
Residual\ Capability
}
]

である。

⸻

したがって、Projectの最終評価は、

[
\boxed{
Problem
\rightarrow
Implementation
\rightarrow
Outcome
\rightarrow
Residual\ Capability
}
]

となる。

成果とは、Project期間中に生じた一時的な変化だけではない。

Projectが終わった後にも、Clientの内部で変化を生成し続ける能力が残っていること。

そこまで確認できて初めて、

[
Outcome
\rightarrow
Capability
]

という変換が成立する。

そして本書はいよいよ最後の第Ⅶ部へ進む。

問いは、さらに一段深くなる。

[
\boxed{
Capabilityとは何か
}
]

AI、Data、System、Knowledge、人間、組織を接続したとき、企業自身が次のProblemを解ける能力は、どのように生成されるのか。

ここから、SYNTHESISをCapability Generation Companyとして検証する。