『世界最強企業40社』――AI・半導体・資本・エネルギー・製造・科学・社会から読み解く、2026年の産業構造（第7回）（第6章　Mobility & Society）

第6章　Mobility & Society

第1節　実世界を走るAI

Factoryの中では、Environmentをある程度制御できる。

Machineの位置は決まっている。

Production Lineも設計されている。

Workerの動線も一定範囲で管理できる。

しかし道路、都市、物流網では条件が違う。

Pedestrian。

Bicycle。

Vehicle。

Weather。

Construction。

Emergency。

Human Behavior。

未知のEvent。

多数の主体が同時に動く。

ここでAIは、よりOpenなPhysical Realityへ入る。

[
\boxed{
Factory\ AI
\rightarrow
Open\ World\ AI
}
]

Mobilityとは、AIが実世界を「走る」最も分かりやすい領域の一つである。

⸻

Mobilityは移動以上のSystemである

MobilityをVehicleだけで見ると構造を見失う。

人が移動する。

物が移動する。

情報が移動する。

Energyが消費される。

道路や都市Infrastructureが使われる。

[
Human
+
Goods
+
Vehicle
+
Infrastructure
+
Information
\rightarrow
Mobility\ System
]

となる。

Autonomous VehicleはこのSystemの一つのNodeである。

本当に重要なのは、そのNodeが社会全体のFlowへどう接続されるかである。

⸻

Perception

実世界を走るAIは、まず周囲を認識する。

Camera。

Radar。

Lidar。

Map。

Vehicle Sensor。

それらから、

Road。

Vehicle。

Pedestrian。

Signal。

Lane。

Obstacle。

を推定する。

[
Reality
\rightarrow
Sensor
\rightarrow
Perception
]

である。

しかし道路ではObject Recognitionだけでは足りない。

次に何が起こるかを予測しなければならない。

⸻

Prediction

前のVehicleは曲がるのか。

Pedestrianは横断するのか。

BicycleはLaneへ入るのか。

Traffic Lightは変わるのか。

[
Current\ State
\rightarrow
Future\ State
]

を予測する。

Mobility AIでは、Physical ObjectだけでなくHuman Intentも扱う必要がある。

この点でFactoryよりUncertaintyが大きい。

⸻

Planning

PredictionをもとにActionを決める。

進む。

止まる。

曲がる。

Laneを変える。

距離を取る。

[
Perception
\rightarrow
Prediction
\rightarrow
Planning
]

となる。

ただし「最短経路」を選べばよいわけではない。

Safety。

Comfort。

Traffic Rule。

Energy。

他者とのInteraction。

複数Objectiveを同時に扱う必要がある。

⸻

Control

PlanをVehicleのPhysical Motionへ変換する。

Steering。

Acceleration。

Braking。

[
Plan
\rightarrow
Control
\rightarrow
Physical\ Motion
]

である。

ここでAI Outputが直接Public Spaceへ作用する。

Mobility AIでは、Software DecisionがPhysical Riskへ変換されるため、Verificationの要求水準が高い。

⸻

Open World

FactoryのRobotは、設計されたEnvironmentで動くことが多い。

道路ではEnvironmentを完全には設計できない。

Unexpected Object。

Road Damage。

Weather。

Emergency Vehicle。

Human Mistake。

無数のCorner Caseが存在する。

[
Closed\ Environment
\rightarrow
Open\ Environment
]

へ進むことで、AIの難易度は急激に上がる。

⸻

Long-tail Problem

通常のScenarioでは高性能でも、Rare Eventで失敗すればSafety上重大な問題になる。

[
Average\ Performance
\neq
Safe\ Performance
]

である。

Mobility AIでは、平均Accuracy以上にLong-tail Scenarioが重要になる。

だからこそSimulation、Fleet Data、Scenario Generationが必要になる。

⸻

Simulation

危険なScenarioを道路上で意図的に再現することは難しい。

そこでSimulationを使う。

突然Pedestrianが飛び出す。

Heavy Rain。

Sensor Failure。

Unusual Vehicle。

Rare Traffic Pattern。

[
Rare\ Reality
\rightarrow
Simulated\ Scenario
]

として大量に検証する。

Digital TwinとSimulationがMobility Safetyの重要なLayerになる。

⸻

RealityによるVerification

しかしSimulationだけでは十分ではない。

道路のRealityにはModel化されていない差がある。

したがって、

[
Simulation
\rightarrow
Road
\rightarrow
Measurement
\rightarrow
Simulation
]

というLoopが必要になる。

実世界走行が最終的なValidation Environmentになる。

⸻

Fleet Data

Vehicleが大量にDeploymentされると、それぞれがSensor Nodeになる。

Road Condition。

Human Behavior。

Traffic Pattern。

Rare Event。

大量のPhysical Dataが得られる。

[
Vehicle\ Fleet
\rightarrow
Distributed\ Observation
]

となる。

Fleet ScaleをLearning Scaleへ変換できる企業は、大きなPhysical Feedback Advantageを持つ。

⸻

Tesla――Fleetという観測網

Tesla型の構造で注目すべきなのは、Vehicle、Software、AI、Manufacturing、Fleet Dataの接続である。

Vehicleが道路へ出る。

Dataが得られる。

Modelを改善する。

Software UpdateでFleetへ戻す。

[
Fleet
\rightarrow
Data
\rightarrow
Model
\rightarrow
Fleet
]

というLoopを形成できる。

重要なのはVehicle販売台数だけではない。

DeploymentされたPhysical AssetがLearning Interfaceになることである。

⸻

Waymo――Autonomous Mobilityの実装

WaymoのようなAutonomous Driving企業は、限定Regionでの高精度な自動運転実装を積み重ねてきた。

ここでは、

Map。

Sensor。

Simulation。

Vehicle。

Safety Operation。

Real-world Deployment。

を一つのSystemとして統合する。

[
AI
+
Physical\ Vehicle
+
Operational\ System
\rightarrow
Autonomous\ Mobility
]

となる。

AutonomyはModel単体では成立しない。

⸻

Toyota――VehicleからMobility Systemへ

Toyotaのような企業では、Vehicle ManufacturingだけでなくMobility Service、Software、都市実証などへ領域が広がる。

Vehicleを製造する。

道路で使われる。

人と社会へ接続される。

ここで、

[
Vehicle\ Company
\rightarrow
Mobility\ System
]

という転換が起こる。

Physical ProductからSystem Operationへ競争軸が広がる。

⸻

Woven Cityという実証環境

都市Scaleでは、一台のVehicleだけでなく、

Mobility。

Pedestrian。

Building。

Robot。

Energy。

Data。

を同時に扱うことができる。

こうした実証環境は、Physical AIを社会へ接続するための重要なLearning Environmentになる。

[
Technology
\rightarrow
Urban\ Experiment
\rightarrow
Social\ Feedback
]

となる。

⸻

MobilityはSafety-criticalである

Autonomous MobilityではSafetyが中心になる。

AIが誤る。

Sensorが故障する。

Networkが切れる。

Road Conditionが変わる。

そのときSystemがどう振る舞うか。

[
Failure
\rightarrow
Safe\ Response
]

を設計する必要がある。

CapabilityだけでなくFailure Handlingが重要になる。

⸻

Redundancy

Safety-critical SystemではRedundancyが使われる。

複数Sensor。

複数Compute Path。

Fallback System。

Backup Control。

[
Primary\ System
+
Fallback
\rightarrow
Resilience
]

である。

単一Modelの精度より、System Architecture全体を見る必要がある。

⸻

Human Driverとの共存

完全Autonomous VehicleだけがMobility AIではない。

Driver Assistance。

Navigation。

Safety Warning。

Fleet Management。

HumanとAIが共同で運転する形もある。

[
Human
+
AI
\rightarrow
Driving\ System
]

となる。

Autonomy LevelによってHuman ResponsibilityとSystem Responsibilityが変わる。

⸻

Human Handover

部分自動化では、HumanへControlを戻す設計が重要になる。

AIが限界を認識する。

Humanへ通知する。

十分な時間を与える。

[
AI
\rightarrow
Limit\ Detection
\rightarrow
Human\ Handover
]

である。

Human-in-the-loopは単に人を残せばよいわけではない。

Interface Designが重要になる。

⸻

MobilityとEdge AI

VehicleはReal-timeで動く。

Cloudへの通信を待っていては遅い。

そのため主要なPerception、Planning、ControlはVehicle側で処理する必要がある。

[
Sensor
\rightarrow
Edge\ Compute
\rightarrow
Action
]

となる。

一方、Cloud側ではFleet Learning、Map Update、Large-scale Simulationなどを行う。

[
Cloud
\leftrightarrow
Vehicle
]

というDistributed Architectureになる。

⸻

Connectivity

VehicleとCloud、Vehicle同士、Road InfrastructureとのConnectionも重要になる。

Traffic Information。

Map Update。

Fleet Operation。

Charging。

CommunicationはMobility SystemをさらにNetwork化する。

ただしNetwork Connectionが失われてもSafety-critical Functionは維持されなければならない。

[
Connected
\neq
Dependent\ on\ Constant\ Connectivity
]

という設計が必要になる。

⸻

Software-defined Vehicle

Vehicleの価値はMechanical PerformanceだけでなくSoftwareによって更新される部分が増える。

Driver Assistance。

Energy Management。

Infotainment。

Diagnostics。

AI Capability。

[
Vehicle
\rightarrow
Software\ Platform
]

への変化である。

Physical Productが継続的にSoftware Updateされる。

⸻

VehicleからLearning Platformへ

さらにSensor、Compute、Software Updateが接続されると、

[
Vehicle
\rightarrow
Data
\rightarrow
Learning
\rightarrow
Vehicle
]

となる。

Vehicleは移動手段であると同時に、Physical Learning Platformになる。

⸻

EVとEnergy

Mobility AIはEnergyとも接続する。

Electric VehicleではBatteryがEnergy Storageになる。

Charging Infrastructureが必要になる。

Gridへ負荷がかかる。

[
Mobility
\rightarrow
Electricity
\rightarrow
Grid
]

となる。

第4章のEnergy InfrastructureとMobilityがここで直接つながる。

⸻

Charging Network

Vehicleを大量に電動化すれば、VehicleだけでなくCharging Networkが必要になる。

Home Charging。

Fast Charging。

Commercial Fleet Charging。

Grid Connection。

[
EV
+
Charging
+
Grid
\rightarrow
Electric\ Mobility
]

である。

Physical ProductだけではSystemは成立しない。

⸻

Vehicle-to-Grid

BatteryをGrid Resourceとして利用する構想では、

[
Vehicle
\leftrightarrow
Grid
]

という双方向Connectionも可能になる。

Mobility AssetがEnergy Systemの一部になる。

ここでも産業境界が薄くなる。

⸻

Logistics Fleet

Mobility AIはPassenger Vehicleだけではない。

Truck。

Delivery Van。

Warehouse Vehicle。

Autonomous Delivery Robot。

物流Fleetへ展開する。

[
Warehouse
\rightarrow
Vehicle
\rightarrow
Customer
]

をAIで接続する。

ここではRoute Optimization、Load Planning、Autonomyが一つのPhysical Systemになる。

⸻

MobilityとLogistics

人の移動と物の移動は別市場に見えるが、Physical Infrastructureの多くを共有する。

Road。

Energy。

Vehicle。

Map。

Traffic。

AI。

したがって、

[
Mobility
+
Logistics
\rightarrow
Shared\ Physical\ Intelligence
]

という構造が見える。

次節以降で、この物流側をさらに掘り下げる。

⸻

CityというEnvironment

Vehicleは道路だけを走るのではない。

都市というSystemの中を走る。

Traffic Signal。

Parking。

Pedestrian。

Public Transit。

Building。

Energy。

都市全体のFlowと相互作用する。

[
Vehicle
\leftrightarrow
City
]

である。

Autonomous Vehicleを最適化しても都市全体が最適になるとは限らない。

⸻

Local Optimizationの限界

すべてのVehicleが自分の最短Routeだけを選べば、特定RoadへTrafficが集中する可能性がある。

[
Individual\ Optimization
\neq
System\ Optimization
]

である。

Mobility AIがScaleするほど、社会System全体のOutcomeを見る必要がある。

⸻

Regulation

公道は企業のPrivate Spaceではない。

Road Traffic Law。

Vehicle Safety Standard。

Insurance。

Liability。

Data Protection。

地方自治体のRule。

Physical AIは社会制度へ接続される。

[
Technology
+
Regulation
\rightarrow
Deployable\ Mobility
]

である。

⸻

Liability

事故が起きたとき誰が責任を持つのか。

Driver。

Manufacturer。

Software Provider。

Fleet Operator。

複数主体が関わる。

Autonomyが進むほど、責任Architectureの明確化が重要になる。

Technical ArchitectureとLegal Architectureが接続する。

⸻

Social Acceptance

安全統計だけでは社会受容性は決まらない。

人はAutonomous Vehicleを信頼するか。

PedestrianはRobotの挙動を理解できるか。

Public Spaceで不快感はないか。

[
Technical\ Safety
+
Perceived\ Safety
\rightarrow
Adoption
]

である。

Human FeedbackがPhysical AIのScaleを左右する。

⸻

Mobility DataとPrivacy

Vehicleは大量のDataを取得する。

Location。

Camera。

Route。

Driving Pattern。

Passenger Interaction。

これらにはPrivacyが関係する。

[
Physical\ Observation
+
Privacy\ Governance
]

が必要になる。

Fleet Learningを進めるほどData Governanceの重要性は増す。

⸻

Cybersecurity

Connected VehicleはCyber–Physical Systemである。

Software VulnerabilityがPhysical Motionへ影響しうる。

したがって、

[
Cybersecurity

Physical\ Safety
]

に近づく。

Software Update、Identity、Access Control、Secure BootなどがMobility Safetyの一部になる。

⸻

Roadは巨大なLearning Environmentになる

大量のVehicle、Sensor、AIが道路へDeploymentされると、Road Networkそのものが巨大なPhysical Learning Environmentになる。

[
Road
\rightarrow
Vehicle\ Data
\rightarrow
AI
\rightarrow
Better\ Mobility
]

となる。

Factoryに続いて、Public SpaceもLearning Environmentへ変わる。

ただしPublic SpaceではPrivate FactoryよりGovernanceの要求が高い。

⸻

Reality Diversity

道路の価値はData量だけではない。

Urban。

Rural。

Snow。

Rain。

Night。

Construction。

異なるRealityが存在する。

[
Reality\ Diversity
\rightarrow
Robustness
]

である。

多様なEnvironmentから学ぶことがGeneralizationに重要になる。

⸻

Mobility Feedback Loop

ここまでを一つにつなぐ。

Vehicleが走る。

SensorがRealityを観測する。

AIがDataを分析する。

Modelを改善する。

Simulationで検証する。

VehicleへDeploymentする。

再び道路で結果を見る。

[
\boxed{
Road
\rightarrow
Vehicle
\rightarrow
Data
\rightarrow
AI
\rightarrow
Simulation
\rightarrow
Vehicle
\rightarrow
Road
}
]

これがMobility Feedback Loopである。

⸻

Physical LoopからSocial Loopへ

しかしFactoryとの最大の違いはここにある。

道路には企業外の人間がいる。

住民がいる。

自治体がある。

Lawがある。

他社Vehicleがある。

Public Infrastructureがある。

したがって、

[
Physical\ Feedback
]

だけでは閉じない。

[
Social\ Feedback
]

が必要になる。

⸻

実世界を走るAI

本節の中心構造を最小化すると、

[
\boxed{
Perception
\rightarrow
Prediction
\rightarrow
Planning
\rightarrow
Action
\rightarrow
Reality
\rightarrow
Feedback
}
]

である。

AIが実世界を走るとは、VehicleへModelを載せることではない。

Open Environmentを観測し、

Uncertaintyの中で判断し、

安全にActionし、

その結果をRealityから受け取り、

System全体を改善し続けることだ。

FactoryではPhysical Feedback Loopを閉じることができた。

Mobilityでは、そのLoopを社会へ開かなければならない。

道路、物流、都市、人間。

AIの次の学習環境は、企業の所有物ではない。

社会そのものである。

次節では、Mobilityの中でも特に巨大なPhysical Flowを持つ領域へ進む。

Autonomous Mobility。

AIが人と物の移動をどこまで自律化できるのか、その実装構造を整理する。
第2節　Autonomous Mobility

Autonomous Mobilityという言葉から最初に想起されるのは、自動運転車だろう。

しかし産業構造として見るなら、対象は一台のVehicleではない。

Passenger Vehicle。

Robotaxi。

Truck。

Delivery Vehicle。

Warehouse Vehicle。

Shuttle。

Mobile Robot。

これらが、人や物をPhysical Space上で自律的に移動させる。

したがってAutonomous Mobilityとは、

[
\boxed{
Perception
\rightarrow
Prediction
\rightarrow
Planning
\rightarrow
Action
\rightarrow
Verification
}
]

をVehicle上で閉じるだけではない。

Vehicle、AI、Compute、Map、Infrastructure、Fleet Operation、Energy、Safety、Regulationを接続し、移動そのものを継続的なLearning Systemへ変えることである。

────────

AutomationとAutonomy

AutomationとAutonomyは同じではない。

決められたRouteを走る。

決められた条件で停止する。

決められたRuleに従う。

これは高度なAutomationになりうる。

Autonomyではさらに、Environmentを観測し、状態を推定し、複数の選択肢からActionを決める必要がある。

[
Fixed\ Rule
\rightarrow
Adaptive\ Decision
]

への移行である。

ただしAutonomyが高いほど無制約になるわけではない。

むしろ、

[
Higher\ Autonomy
\rightarrow
Stronger\ Safety\ Architecture
]

が必要になる。

────────

Operational Design Domain

自動運転能力を考えるとき、「自動運転できるか、できないか」という二値では不十分である。

どの道路か。

どの速度か。

どのWeatherか。

どのRegionか。

どの時間帯か。

どのTraffic Conditionか。

Systemが安全に機能する条件範囲を明確にする必要がある。

[ Autonomy

Capability
\ within\ Conditions
]

である。

限定されたEnvironmentで高いAutonomyを実現する方法と、広いEnvironmentへGeneralizeする方法ではArchitectureが異なる。

────────

Perception Stack

Autonomous Mobilityの入口はPhysical Realityの観測である。

Camera。

Radar。

Lidar。

Ultrasonic Sensor。

GNSS。

IMU。

Vehicle State。

必要なSensor構成はSystemによって異なる。

重要なのはSensor数そのものではない。

[
Sensors
\rightarrow
Environment\ Representation
]

へ変換できることである。

Road。

Lane。

Signal。

Vehicle。

Pedestrian。

Obstacle。

Free Space。

これらをReal-timeで把握する。

────────

Sensor Fusion

一つのSensorには限界がある。

Cameraは豊富なVisual Informationを持つが、Conditionによって性能が変化する。

Radarには別の強みがある。

LidarにはGeometryを直接取得しやすい利点がある。

したがってSystemによっては、

[
Sensor_A
+
Sensor_B
+
Sensor_C
\rightarrow
More\ Robust\ Perception
]

というSensor Fusionを使う。

一方でSensor構成を単純化し、AI側の能力を高めるArchitectureも存在する。

ここには一つの正解があるのではなく、Cost、Scale、Safety、GeneralizationのTrade-offがある。

────────

Prediction

認識しただけでは走れない。

Pedestrianはどちらへ進むのか。

前方VehicleはLane Changeするのか。

Bicycleは交差点へ入るのか。

[
Observed\ State
\rightarrow
Possible\ Future\ States
]

を推定する。

しかしHuman Behaviorは完全には予測できない。

したがって一つの未来ではなく、複数の可能性とUncertaintyを扱う必要がある。

────────

Planning

次に、自車のActionを決める。

進む。

止まる。

譲る。

追い越す。

Lane Changeする。

目的地へ向かう。

[
Goal
+
Environment
+
Constraints
\rightarrow
Plan
]

となる。

ここでのConstraintには、

Traffic Rule。

Safety。

Comfort。

Energy。

Travel Time。

が含まれる。

最速のActionが最良とは限らない。

────────

Interaction

道路では他者もこちらを見ている。

Human Driverは相手のVehicleの動きからIntentを読む。

PedestrianもVehicleの速度や停止位置を見て判断する。

したがってAutonomous Vehicleは、

[
Observe\ Others
+
Be\ Observable\ to\ Others
]

でなければならない。

Autonomyは単独DecisionではなくInteractionで成立する。

────────

Uncertainty

道路では「分からない」状態が必ず生じる。

Object Classificationに自信がない。

Road Markingが見えない。

MapとRealityが違う。

Weatherが急変した。

このとき重要なのは、AIが必ず答えを出すことではない。

[
Uncertainty
\rightarrow
Safer\ Behavior
]

へ変換することである。

減速する。

停止する。

Fallbackへ移行する。

Autonomous Systemには「分からないときの行動」が必要になる。

────────

Minimal Risk Condition

System Failure時に何をするかは、通常時の性能と同じくらい重要である。

Sensor Failure。

Compute Failure。

Localization Failure。

Unexpected Environment。

このとき安全側へ移行する。

[
Failure
\rightarrow
Minimal\ Risk\ State
]

という設計が必要になる。

Autonomyとは、成功時だけ自律的であることではない。

Failureを管理できることでもある。

────────

Waymo型Architecture

Waymoに代表されるRobotaxi型のApproachでは、特定地域でAutonomous Driving SystemとFleet Operationを統合し、実際のMobility Serviceとして展開する。

重要なのは、

[
Autonomous\ Vehicle
+
Fleet\ Operations
+
Mapping
+
Simulation
+
Safety
]

を一体として扱うことである。

Vehicle Intelligenceだけでなく、Service Operationまで含めてAutonomyを成立させる。

────────

Tesla型Architecture

Teslaは量産Vehicle、On-board Compute、Software Update、実世界Fleetから得られるDataを接続する別の構造を持つ。

[
Vehicle\ Fleet
\rightarrow
Physical\ Data
\rightarrow
AI
\rightarrow
Software\ Deployment
\rightarrow
Vehicle\ Fleet
]

である。

ここではMass DeploymentそのものをLearning Infrastructureへ変換できるかが重要になる。

二つのApproachは、同じAutonomous Mobilityへ異なるSystem Architectureから接近していると読める。

────────

Robotaxi

RobotaxiではVehicleを販売するのではなく、Mobility Serviceを運用する。

CustomerがRideをRequestする。

VehicleをDispatchする。

Pickupする。

Transportする。

Chargeする。

Cleanする。

Maintainする。

[
Request
\rightarrow
Dispatch
\rightarrow
Ride
\rightarrow
Fleet\ Operation
]

までがSystemになる。

Autonomous DrivingだけではBusinessは閉じない。

────────

Fleet Intelligence

数千、数万のVehicleを運用するなら、一台ずつ最適化するだけでは足りない。

どのVehicleをどこへ配置するか。

Demandをどう予測するか。

いつChargingするか。

どのVehicleをMaintenanceへ回すか。

[
Fleet\ State
\rightarrow
Optimization
\rightarrow
Fleet\ Action
]

が必要になる。

Autonomous MobilityはVehicle IntelligenceからFleet Intelligenceへ広がる。

────────

Autonomous Truck

物流ではTruck Autonomyも大きなPotentialを持つ。

Long-haul Transport。

Hub-to-hub Operation。

Yard Operation。

特定Routeの反復。

Passenger Mobilityとは異なるOperational Conditionがある。

[
Autonomous\ Driving
+
Logistics\ Workflow
]

として設計する必要がある。

Truck単体ではなく、WarehouseやDistribution CenterとのConnectionが価値を決める。

────────

Last-mile

物流の最後にはLast-mileがある。

Delivery Van。

Small Robot。

Drone。

Human Courier。

都市条件によって最適な手段は異なる。

[
Warehouse
\rightarrow
Transport
\rightarrow
Last\ Mile
\rightarrow
Customer
]

このChainの一部だけをAutonomous化しても、全体Costが下がるとは限らない。

End-to-end Optimizationが必要になる。

────────

Warehouseとの接続

Autonomous TruckがWarehouseへ到着する。

荷物を下ろす。

Warehouse Robotが搬送する。

Inventory Systemが更新される。

次のVehicleへ積み込む。

[
Road\ Autonomy
\leftrightarrow
Warehouse\ Automation
]

が接続される。

Factoryで始まったPhysical AIが物流Networkへ拡張される。

────────

Infrastructureとの関係

Autonomous MobilityはVehicleだけで成立するとは限らない。

Road Marking。

Traffic Signal。

Charging Station。

Communication Infrastructure。

Map。

Parking。

都市側のInfrastructureも影響する。

[
Vehicle\ Intelligence
+
Infrastructure
\rightarrow
Mobility\ Capability
]

となる。

ただしInfrastructure依存をどこまで増やすかはArchitecture上の選択になる。

────────

EdgeとCloud

Autonomous Drivingの瞬間的なDecisionはVehicle側で行う必要がある。

[
Sensor
\rightarrow
Edge\ AI
\rightarrow
Action
]

一方、

Fleet Analysis。

Model Training。

Simulation。

Map Processing。

Large-scale Data Analysis。

はCloud側で行える。

[
Vehicle
\leftrightarrow
Cloud
]

である。

Autonomous Mobilityは巨大なDistributed Computing Systemでもある。

────────

Semiconductor

ここで第2章へ戻る。

Vehicle上でMultimodal Sensor Dataを低Latencyで処理するにはComputeが必要になる。

Accelerator。

Memory。

Networking。

Power Efficiency。

[
Autonomy
\rightarrow
Onboard\ Compute
\rightarrow
Semiconductor
]

となる。

AI研究とMobilityはSemiconductorを通じてPhysicalに接続される。

────────

Energy

Autonomous EV FleetではEnergy ManagementもSystemの一部になる。

いつChargeするか。

どのStationを使うか。

Peak Demandをどう避けるか。

Battery Degradationをどう管理するか。

[
Fleet\ Optimization
+
Energy\ Optimization
]

が必要になる。

Mobility AlgorithmとEnergy Algorithmが分離できなくなる。

────────

Capital

Autonomous MobilityはCapital-intensiveでもある。

Vehicle。

Sensor。

Compute。

Data Center。

Charging Infrastructure。

Maintenance Facility。

大量のPhysical Assetが必要になる。

したがって、

[
AI\ Capability
+
Capital
+
Physical\ Deployment
]

が同時に必要になる。

第3章で見たCapital AllocationがここでPhysical Realityへ到達する。

────────

Simulation Scale

実世界だけでCorner Caseを集めるのには時間がかかる。

そこでSimulationによってScenarioを大量生成する。

[
Scenario
\rightarrow
Simulation
\rightarrow
Failure\ Discovery
]

を高速化する。

しかしSimulationで成功しただけではDeploymentできない。

[
Simulation
\rightarrow
Verification
\rightarrow
Controlled\ Deployment
\rightarrow
Reality
]

という段階が必要になる。

────────

Shadow Evaluation

新しいModelをいきなりVehicle Controlへ使わず、既存Systemと並行してPredictionさせ、Realityと比較する方法も考えられる。

[
New\ Model
\rightarrow
Observe\ Only
\rightarrow
Compare
\rightarrow
Deploy
]

である。

Physical Systemでは、Deployment前にLearningできるArchitectureが重要になる。

────────

Safety Case

Autonomous Mobilityでは「AIが高性能だから安全」という説明では足りない。

どのHazardを想定したか。

どのFailure Modeを検証したか。

どの条件でSystemを使用するか。

どのFallbackがあるか。

System LevelでSafetyを説明する必要がある。

[
Model\ Performance
\subset
System\ Safety
]

である。

────────

Regulation

Autonomous MobilityがPublic Roadへ出ると、Technologyは制度へ接続される。

Vehicle Regulation。

Traffic Rule。

Operational Permission。

Liability。

Insurance。

Data Governance。

AutonomyのScaleはTechnologyだけでは決まらない。

[
Technical\ Readiness
+
Institutional\ Readiness
\rightarrow
Deployment
]

となる。

────────

社会が実装条件になる

Factoryなら企業がEnvironmentを設計できる。

Public Roadではそうではない。

住民。

自治体。

Driver。

Pedestrian。

Emergency Service。

Insurance Company。

多数のStakeholderが存在する。

したがってAutonomous Mobilityでは、

[
Technical\ Optimization
\neq
Social\ Optimization
]

である。

社会的受容性もImplementation Constraintになる。

────────

Human Feedback

乗客はどう感じたか。

急Brakeは多くなかったか。

Pickup位置は分かりやすかったか。

PedestrianはVehicleのIntentを理解できたか。

[
Physical\ Performance
+
Human\ Experience
]

を測る必要がある。

MobilityではHuman FeedbackがSystem Performanceの一部になる。

────────

Accessibility

Autonomous Mobilityには新しい社会的価値もありうる。

高齢者。

障害のある人。

運転できない人。

交通手段が少ない地域。

移動へのAccessを改善できる可能性がある。

したがって評価軸をCostやSpeedだけに限定しない。

[ Mobility\ Value

Efficiency
+
Safety
+
Accessibility
+
Reliability
]

として見る必要がある。

────────

CongestionというParadox

Autonomous Vehicleが便利になれば、Vehicle利用そのものが増える可能性もある。

一台の効率が上がっても、総Trafficが増えれば都市全体ではCongestionが悪化する可能性がある。

[
Vehicle\ Optimization
\neq
City\ Optimization
]

である。

ここからAutonomous Mobilityは都市Systemの問題になる。

────────

Public Transitとの関係

Autonomous MobilityはRailやBusを単純に置き換えるとは限らない。

First-mile。

Last-mile。

Low-density Area。

On-demand Shuttle。

Public Transitを補完する使い方もある。

[
Autonomous\ Mobility
+
Public\ Transit
\rightarrow
Integrated\ Mobility
]

という設計が可能になる。

────────

Mobility Digital Twin

都市やFleetをDigital Twinとして扱えば、

Vehicle配置。

Demand。

Traffic。

Charging。

Road Closure。

Event。

をSimulationできる。

[
Mobility\ Reality
\leftrightarrow
Mobility\ Twin
]

となる。

一台のVehicleではなくMobility System全体をOptimizationする方向へ進む。

────────

Physical Feedback Loop

Autonomous VehicleがRealityを走る。

Rare Eventを観測する。

Dataを集める。

Modelを改善する。

Simulationする。

安全性を検証する。

FleetへDeploymentする。

再びRealityで測定する。

[
\boxed{
Reality
\rightarrow
Fleet
\rightarrow
Data
\rightarrow
Learning
\rightarrow
Simulation
\rightarrow
Deployment
\rightarrow
Reality
}
]

これがAutonomous MobilityのPhysical Feedback Loopである。

────────

Social Feedback Loop

しかしPublic Spaceではもう一つのLoopが必要になる。

住民の反応。

事故・Incident。

交通への影響。

Accessibility。

Regulation。

自治体の判断。

これらをSystemへ戻す。

[
\boxed{
Deployment
\rightarrow
Society
\rightarrow
Feedback
\rightarrow
Governance
\rightarrow
Deployment
}
]

Autonomous MobilityはPhysical LoopとSocial Loopの二重構造を持つ。

────────

Autonomyの本質

したがってAutonomous Mobilityの競争を、

「誰が最初にDriverを不要にするか」

だけで理解するのは狭い。

重要なのは、

どこまで安全に自律化できるか。

どのEnvironmentへScaleできるか。

Fleetからどれだけ学習できるか。

Physical Infrastructureと接続できるか。

社会からのFeedbackをSystemへ戻せるか。

である。

[ \boxed{ Autonomous\ Mobility

AI
\times
Vehicle
\times
Infrastructure
\times
Fleet
\times
Safety
\times
Learning
\times
Society
}
]

となる。

────────

VehicleからMobility Networkへ

一台のAutonomous VehicleはNodeである。

しかし一台だけでは産業構造は変わらない。

数千台がFleetになる。

Warehouseと接続する。

Charging Networkと接続する。

Roadと接続する。

Public Transitと接続する。

都市と接続する。

[
Vehicle
\rightarrow
Fleet
\rightarrow
Mobility\ Network
]

へScaleする。

このときAutonomous MobilityはVehicle TechnologyではなくInfrastructureへ近づく。

────────

Autonomous Mobility

本節を最小化すると、

[
\boxed{
Observe
\rightarrow
Predict
\rightarrow
Plan
\rightarrow
Act
\rightarrow
Measure
\rightarrow
Learn
}
]

である。

しかしそのLoopを一台のVehicleで閉じるだけでは足りない。

[
\boxed{
Vehicle
\rightarrow
Fleet
\rightarrow
Infrastructure
\rightarrow
Society
\rightarrow
Feedback
\rightarrow
Vehicle
}
]

まで広げる必要がある。

AIは道路を走る。

だが道路は単なるPhysical Spaceではない。

そこには物流があり、人間が暮らし、企業が活動し、都市が動いている。

Autonomous MobilityがScaleすると、次に最適化すべき対象はVehicleではなく、物の流れそのものになる。

次節では、その巨大なPhysical Networkへ進む。

第3節　物流という巨大な実験場。
第3節　物流という巨大な実験場

物流は、現代社会の巨大なPhysical Networkである。

FactoryでつくられたProductは、その場では価値を完結しない。

Warehouseへ運ばれる。

仕分けられる。

Truck、Ship、Rail、Aircraftへ載せられる。

Distribution Centerを通過する。

最後にCustomerへ届く。

[
\boxed{
Factory
\rightarrow
Warehouse
\rightarrow
Transport
\rightarrow
Distribution
\rightarrow
Customer
}
]

このNetworkでは、毎日膨大なPhysical Eventが発生する。

荷物が動く。

Vehicleが走る。

Inventoryが変化する。

Demandが変化する。

Delayが起こる。

人間とRobotが協働する。

その意味で物流は、AIがPhysical Realityから学ぶための巨大な実験場でもある。

────────

物流は「移動」だけではない

物流をTransportだけで理解すると構造を見失う。

本質的には、

何を。

どこから。

どこへ。

いつ。

どのRouteで。

どのVehicleに載せ。

どのWarehouseを経由し。

どのCostとService Levelで届けるか。

という巨大なAllocation Problemである。

[
Demand
+
Inventory
+
Capacity
+
Location
+
Time
\rightarrow
Logistics\ Decision
]

したがって物流は、Physical Operationであると同時にDecision Systemである。

────────

DigitalとPhysicalが交差する

CustomerがDigital InterfaceからOrderする。

その瞬間、Digital EventがPhysical Actionへ変換される。

[
Digital\ Order
\rightarrow
Physical\ Movement
]

WarehouseでProductを探す。

Robotが搬送する。

HumanがPickする。

Truckへ積む。

道路を走る。

Customerへ届ける。

E-commerceは、Digital Economyの背後に巨大なPhysical Runtimeを必要とする。

────────

Amazon――Digital DemandからPhysical Executionへ

Amazon型の構造で重要なのは、Online CommerceとPhysical Logisticsが切り離されていないことである。

Customer Demandが観測される。

Inventoryを配置する。

Fulfillment Centerで処理する。

Delivery Networkへ流す。

Delivery Resultが再びDataになる。

[
Demand
\rightarrow
Inventory
\rightarrow
Fulfillment
\rightarrow
Delivery
\rightarrow
Feedback
]

となる。

Digital DemandとPhysical Executionが一つのLoopに入る。

────────

WarehouseというPhysical Compute

Warehouseでは膨大なDecisionが発生する。

どの商品をどこへ置くか。

どのOrderから処理するか。

どのRobotを動かすか。

どのWorkerへTaskを割り当てるか。

どのDockへTruckを入れるか。

これを一つの計算問題として見れば、

[ Warehouse

Physical\ State
+
Optimization
+
Execution
]

である。

Warehouseは物理空間上でAlgorithmを実行するComputerに近づく。

────────

Robot Fleet

Warehouseには多数のRobotをDeploymentできる。

Mobile Robot。

Robot Arm。

Sorting System。

Autonomous Vehicle。

一台ごとの動きを最適化するだけでは足りない。

[
Robot_1,\ Robot_2,\ldots,Robot_n
]

が同じSpaceを共有するため、

[
Fleet\ Coordination
]

が必要になる。

物流はMulti-Agent Physical Systemになる。

────────

RobotとHuman

しかし物流はRobotだけで成立しているわけではない。

Human Workerがいる。

Robotが運ぶ。

Humanが判断する。

MachineがSortする。

AIがTaskを割り当てる。

[
Human
+
Robot
+
AI
\rightarrow
Fulfillment
]

となる。

重要なのはRobot単体の最高速度ではなく、System全体の安全性、Productivity、Work Qualityである。

────────

InventoryというState

物流SystemではInventoryが重要なState Variableになる。

どの商品が。

どこに。

いくつあるか。

[
Inventory(location,\ product,\ time)
]

を正確に把握できなければ、Optimizationは成立しない。

Digital System上では在庫があるのに、Physical Realityでは存在しない。

この差があればSystemは失敗する。

────────

Digital StateとPhysical State

したがって、

[
Digital\ Inventory
\approx
Physical\ Inventory
]

を維持する必要がある。

Barcode。

RFID。

Camera。

Sensor。

Warehouse Management System。

Physical EventをDigital Stateへ反映する。

物流はDigital Twinの非常に実践的な領域でもある。

────────

Demand Forecasting

物流は未来のDemandを予測する。

何が売れるか。

どのRegionで売れるか。

いつDemandが増えるか。

[
Historical\ Demand
+
External\ Signals
\rightarrow
Demand\ Forecast
]

ForecastによってInventory Placementを変える。

CustomerがOrderしてから動かすのではなく、その前からPhysical Assetを配置する。

────────

PredictionからPre-positioningへ

Demandを予測できれば、

[
Prediction
\rightarrow
Physical\ Positioning
]

が可能になる。

ProductをCustomerの近くへ移しておく。

配送距離を短くする。

Lead Timeを下げる。

しかしForecastが外れればExcess Inventoryになる。

したがってPrediction AccuracyとPhysical Costを同時に考える必要がある。

────────

Route Optimization

Warehouseを出た後にはRouting Problemがある。

複数Customer。

複数Vehicle。

Delivery Window。

Traffic。

Vehicle Capacity。

Energy。

[
Orders
+
Vehicles
+
Roads
+
Time
\rightarrow
Routes
]

をOptimizationする。

AIとOperations ResearchがPhysical Movementへ直接接続される代表領域である。

────────

Dynamic Routing

Realityは計画通りには進まない。

Traffic Jam。

Weather。

Customer Absence。

Road Closure。

Vehicle Failure。

新しいOrder。

そこでRouteをReal-timeに更新する。

[
Plan_t
+
Reality_t
\rightarrow
Plan_{t+1}
]

となる。

物流は継続的なRe-planning Systemである。

────────

Autonomous Truck

Long-haul LogisticsではAutonomous Truckが重要なNodeになりうる。

特定Route。

Hub-to-hub。

Highway中心。

Passenger Mobilityとは異なる条件でAutonomyを実装できる。

[
Warehouse
\rightarrow
Autonomous\ Truck
\rightarrow
Warehouse
]

が成立すれば、Warehouse AutomationとRoad Autonomyが直接接続される。

────────

Last-mile

物流で最も複雑な部分の一つがLast-mileである。

多数のDestination。

狭いRoad。

Building Access。

Customer Schedule。

再配達。

ここでは完全自動化より、

Human Driver。

Delivery Robot。

Locker。

Pickup Point。

Autonomous Vehicle。

を組み合わせる方が合理的な場合もある。

[
One\ Technology
\neq
One\ Solution
]

である。

────────

Drone

地理条件によってはDrone Deliveryも選択肢になる。

Road Infrastructureに依存しにくい。

一方で、

Payload。

Range。

Weather。

Noise。

Airspace Regulation。

Safety。

というConstraintがある。

物流ではTechnologyを単独評価せず、TaskとEnvironmentの対応関係を見る必要がある。

────────

Port

物流Networkをさらに広げるとPortへ到達する。

Container。

Crane。

Truck。

Ship。

Warehouse。

Customs。

大量のPhysical Assetが接続される。

[
Ocean
\rightarrow
Port
\rightarrow
Land
]

というInterfaceである。

Port Efficiencyの変化はGlobal Supply Chain全体へ波及する。

────────

Maritime Logistics

世界貿易では海運が巨大なPhysical Layerを担う。

Ship Position。

Port Congestion。

Weather。

Fuel。

Cargo。

これらをDataとして統合すれば、

[
Global\ Logistics
\rightarrow
Observable\ Network
]

へ近づく。

Physical Worldの大規模なFlowをDigital側から観測できる。

────────

Air Cargo

High-value、Time-sensitiveなGoodsではAir Cargoが重要になる。

Semiconductor。

Medical Supplies。

High-value Components。

Supply Chainは一つのTransport Modeだけで構成されない。

[
Sea
+
Air
+
Rail
+
Road
]

を接続したMultimodal Networkである。

────────

Semiconductor Supply Chain

第2章で見たSemiconductorも物流なしでは成立しない。

Material。

Equipment。

Wafer。

Package。

Memory。

Server。

複数Countryと企業を移動する。

したがって、

[
Semiconductor\ Capability
+
Logistics\ Capability
]

が必要になる。

最先端TechnologyほどSupply Chain Complexityが高くなる場合がある。

────────

AI Infrastructureの物流

Data Center建設にも物流がある。

GPU。

Server Rack。

Networking Equipment。

Cooling System。

Transformer。

Generator。

Construction Material。

AI Infrastructureそのものが巨大なPhysical Supply Chainを必要とする。

[
AI\ Demand
\rightarrow
Physical\ Infrastructure
\rightarrow
Logistics
]

となる。

Digital IntelligenceのScaleは物流能力にも依存する。

────────

Energyとの接続

物流には大量のEnergyが必要になる。

Truck Fuel。

Ship Fuel。

Aircraft Fuel。

Warehouse Electricity。

EV Charging。

したがって、

[
Logistics
\leftrightarrow
Energy
]

である。

Route OptimizationはDistanceだけでなくEnergy Optimizationでもある。

────────

EV Fleet

Delivery FleetをEV化すると新しいOptimization Problemが生まれる。

Battery State。

Charging Station。

Electricity Price。

Route。

Payload。

[
Route\ Planning
+
Charging\ Planning
]

を統合する必要がある。

Mobility AlgorithmとEnergy Algorithmが一つになる。

────────

Supply Chain Digital Twin

物流NetworkをDigital Twinとして表現する。

Factory。

Supplier。

Warehouse。

Inventory。

Vehicle。

Port。

Customer。

[
Physical\ Supply\ Chain
\leftrightarrow
Digital\ Supply\ Chain
]

となる。

現在Stateを把握し、Disruption ScenarioをSimulationする。

────────

Disruption

物流ではDisruptionが避けられない。

Natural Disaster。

Geopolitical Conflict。

Port Closure。

Cyberattack。

Factory Shutdown。

Extreme Weather。

一つのNodeの停止がNetwork全体へ波及する。

[
Node\ Failure
\rightarrow
Network\ Effect
]

である。

────────

Resilience

最安Costだけを追求するとNetworkがFragileになることがある。

Single Supplier。

Minimal Inventory。

Long Supply Chain。

これらは通常時には効率的でも、Disruption時にはRiskになる。

したがって、

[
Efficiency
\leftrightarrow
Resilience
]

のTrade-offを扱う必要がある。

────────

SimulationによるResilience設計

Supplier Aが停止したらどうなるか。

Port Bが閉鎖されたらどうなるか。

Demandが二倍になったらどうなるか。

Digital TwinでSimulationする。

[
Disruption
\rightarrow
Simulation
\rightarrow
Contingency\ Plan
]

となる。

物流はFuture Scenarioを検証する巨大なSimulation対象になる。

────────

Realityから学ぶ

しかし実際のDisruptionはSimulation通りではない。

そこで実Eventを記録する。

どこでDelayしたか。

どのAlternative Routeが機能したか。

どのSupplierが回復したか。

[
Real\ Disruption
\rightarrow
Learning
\rightarrow
Better\ Resilience
]

となる。

危機そのものが次のSupply Chain Designを改善するDataになる。

────────

Logistics Control Tower

物流Network全体を観測するために、複数SourceのDataを統合する。

Order。

Inventory。

Vehicle。

Supplier。

Weather。

Port。

[
Distributed\ Data
\rightarrow
Shared\ Operational\ View
]

をつくる。

重要なのはDashboardを表示することではない。

異常を検知し、Decisionへ接続し、Actionを追跡できることにある。

────────

AI Agent

物流はAI Agentと相性がよい。

Shipment Delayを検知する。

Alternative Routeを探す。

CostとLead Timeを比較する。

Warehouse Capacityを確認する。

Humanへ提案する。

[
Event
\rightarrow
Agent
\rightarrow
Options
\rightarrow
Decision
\rightarrow
Action
]

となる。

多数の小さなOperational DecisionをAIが支援できる。

────────

Human Approval

ただし重大なSupply Chain変更にはHuman Decisionが必要になる。

高額なAir Freightへ切り替える。

Supplierを変更する。

Critical Inventoryを再配分する。

[
AI\ Recommendation
\rightarrow
Human\ Approval
\rightarrow
Execution
]

というGovernanceが必要になる。

────────

Every Shipment is an Experiment

物流が巨大な実験場である理由はここにある。

毎日、

異なるRoute。

異なるDemand。

異なるWeather。

異なるCustomer。

異なるTraffic。

異なるInventory State。

が発生する。

[
Shipment_1,\ Shipment_2,\ldots,Shipment_n
]

一つひとつがPhysical Systemの観測機会になる。

────────

Experiment without Deliberate Experiment

すべてを意図的なExperimentとして設計する必要はない。

通常OperationからもLearningできる。

[
Operation
\rightarrow
Natural\ Experiment
\rightarrow
Learning
]

である。

ただしCorrelationをCausalityと誤認しないために、分析設計は必要になる。

────────

Logistics Data Flywheel

Deliveryが増える。

Dataが増える。

Forecastが改善する。

Inventory Placementが改善する。

Routeが改善する。

Serviceが改善する。

さらに利用が増える。

[
\boxed{
Deployment
\rightarrow
Data
\rightarrow
Optimization
\rightarrow
Better\ Service
\rightarrow
Deployment
}
]

というFlywheelが成立しうる。

────────

Scaleだけでは優位にならない

しかし荷物が多いだけではLearning Advantageにはならない。

Data Quality。

Context。

Model。

Experiment。

Implementation。

Verification。

が必要になる。

[
Volume
\neq
Learning
]

である。

物流量をLearning Scaleへ変換できるArchitectureが必要になる。

────────

Cross-company Learning

物流Networkは一企業では完結しない。

Manufacturer。

Supplier。

Carrier。

Warehouse Operator。

Port。

Retailer。

Customer。

複数企業が同じShipmentに関与する。

したがって、

[
Logistics\ Feedback\ Loop



Firm\ Boundary
]

である。

ここでも企業間Edgeが重要になる。

────────

Data Standard

企業を越えてLearningするには共通のData Definitionが必要になる。

Shipment ID。

Location。

Status。

Time。

Exception。

意味が企業ごとに異なれば接続できない。

[
Interoperability
\rightarrow
Network\ Learning
]

である。

Digital StandardはPhysical Flowを高速化するInfrastructureになる。

────────

TrustとAccess Control

一方、すべてのDataを共有できるわけではない。

Price。

Customer Information。

Trade Secret。

Supplier Condition。

したがって、

[
Data\ Sharing
+
Access\ Control
+
Trust
]

が必要になる。

Network Learningと企業独立性を両立させる。

────────

Customer Feedback

Deliveryが完了した後にもDataがある。

予定通り届いたか。

Damageはなかったか。

Delivery Windowは適切だったか。

Customer Experienceはどうだったか。

[
Delivery
\rightarrow
Customer
\rightarrow
Feedback
]

を物流設計へ戻す。

Physical OptimizationがHuman Outcomeへ接続される。

────────

Worker Feedback

Warehouse Worker。

Driver。

Port Worker。

物流を動かす人間からのFeedbackも重要である。

Algorithm上は効率的でも、現場では危険かもしれない。

過剰なWorkloadを生むかもしれない。

[
Algorithmic\ Efficiency
\neq
Human\ Sustainability
]

である。

Learning SystemにはHuman Feedbackを含める必要がある。

────────

社会Infrastructureとしての物流

物流が停止すると、社会そのものが動かなくなる。

Food。

Medicine。

Energy Equipment。

Industrial Components。

Daily Goods。

したがって物流Optimizationは企業利益だけの問題ではない。

[
Logistics
\rightarrow
Social\ Resilience
]

でもある。

────────

Logistics Feedback Loop

本節の構造を一つにまとめる。

Demandを観測する。

Inventoryを配置する。

Warehouseで処理する。

Transportする。

Customerへ届ける。

Outcomeを測る。

Forecast、Route、Inventory、Networkを更新する。

[
\boxed{
Demand
\rightarrow
Plan
\rightarrow
Physical\ Flow
\rightarrow
Delivery
\rightarrow
Data
\rightarrow
Learning
\rightarrow
Plan
}
]

これがLogistics Feedback Loopである。

────────

物流という巨大な実験場

物流は毎日Realityと接触する。

AIが予測する。

Algorithmが計画する。

Robotが動く。

Vehicleが走る。

人間が判断する。

Weatherが変わる。

Customerが反応する。

そのすべてがOutcomeとして返ってくる。

だから物流は、

[
\boxed{
AI
\times
Physical\ Reality
\times
Massive\ Repetition
}
]

が同時に存在する稀有なEnvironmentである。

AIをPhysical Realityへ接続し、結果から継続的に学ぶための巨大な実験場なのである。

────────

Factoryから物流、物流から都市へ

第5章ではFactoryをLearning Environmentとして見た。

本節では、そのLoopをFactoryの外へ広げた。

[
Factory
\rightarrow
Warehouse
\rightarrow
Logistics
\rightarrow
Customer
]

しかし物流Networkは真空の中に存在しない。

Truckは都市を走る。

Warehouseは都市圏に配置される。

Delivery Robotは歩道を使う。

Charging Infrastructureは地域のEnergy Systemへ接続される。

Customerはそこで生活している。

物流をScaleすると、次に現れるSystemは都市である。

都市は、Mobility、Logistics、Energy、Building、人間、企業、行政が同時に存在するPhysical Realityである。

次節では、その最も複雑な実証環境へ進む。

第4節　都市という実証環境。
第4節　都市という実証環境

都市は、AIをPhysical Realityへ実装するうえで最も複雑なEnvironmentの一つである。

Vehicleが走る。

Pedestrianが歩く。

物流が動く。

BuildingがEnergyを消費する。

Shopが営業する。

Hospitalが機能する。

Public Transportが人を運ぶ。

GovernmentがInfrastructureを管理する。

企業、住民、観光客、行政、公共機関が同じPhysical Spaceを共有している。

[ \boxed{ City

Mobility
+
Logistics
+
Energy
+
Buildings
+
People
+
Institutions
}
]

Factoryは企業がEnvironmentをかなり設計できる。

都市は違う。

都市そのものが、多数の独立した主体によって継続的に変化するOpen Systemである。

────────

都市は一つの巨大Systemではない

都市を「一つのSmart City System」として完全に統合できると考えるのは危険である。

交通には交通のSystemがある。

EnergyにはEnergyのSystemがある。

Water。

Waste。

Healthcare。

Retail。

Housing。

それぞれ異なる主体、制度、時間軸を持つ。

したがって、

[
City
\neq
One\ Centrally\ Controlled\ System
]

である。

より正確には、

[ \boxed{ City

System\ of\ Systems
}
]

として理解する必要がある。

都市AIに必要なのは、すべてを一つの中央AIへ統合することではない。

異なるSystemの自律性を保ちながら、必要なConnectionを形成することである。

────────

都市はPhysical Dataを生み続ける

都市では常にEventが発生している。

Traffic。

Pedestrian Flow。

Electricity Demand。

Weather。

Public Transit。

Delivery。

Building Occupancy。

Emergency。

これらを適切にSensorやSystemから取得すれば、

[
City
\rightarrow
Continuous\ Physical\ Data
]

となる。

都市は非常に大きなObservation Environmentである。

しかし観測できることと、観測してよいことは同じではない。

ここでPrivacyとGovernanceが重要になる。

────────

Mobility Data

都市交通では、

Vehicle Location。

Travel Time。

Congestion。

Public Transit Operation。

Parking。

事故。

などのDataがある。

これを使えば、

[
Mobility\ State
\rightarrow
Observation
\rightarrow
Optimization
]

が可能になる。

ただし一台のVehicleを最適化するだけでは都市全体は最適化されない。

────────

System-level Mobility

各Driverが最短Routeを選ぶ。

Ride-hailing VehicleがDemand地点へ集中する。

Delivery Vehicleが同じ時間帯に道路へ出る。

それぞれ合理的でも、全体としてCongestionを生むことがある。

[
Individual\ Optimization
\neq
System\ Optimization
]

である。

都市では、

Vehicle。

Public Transit。

Walking。

Bicycle。

Logistics。

を一つのMobility Networkとして見る必要がある。

────────

Public Transport

都市MobilityではRail、Bus、SubwayなどPublic Transportが大きな役割を持つ。

AIは、

Demand Forecast。

Timetable Optimization。

Crowding Prediction。

Maintenance。

Incident Response。

に利用できる。

[
Public\ Transit
\rightarrow
Data
\rightarrow
AI
\rightarrow
Better\ Operation
]

となる。

Autonomous Vehicleだけが都市Mobilityの未来ではない。

既存Infrastructureをより高度に運用することも重要なPotentialである。

────────

First-mileとLast-mile

Public Transportの弱点の一つはStationやStopまでの移動である。

Autonomous Shuttle。

Shared Mobility。

Bicycle。

Walking。

Delivery Network。

を接続できれば、

[
First\ Mile
+
Mass\ Transit
+
Last\ Mile
]

というIntegrated Mobilityを設計できる。

新しいVehicleをつくることより、既存Node間のMissing Edgeを閉じる方が大きなValueを生む場合もある。

────────

Logisticsと都市

都市では物流Vehicleも大量に動く。

E-commerce Delivery。

Food Delivery。

Commercial Supply。

Construction Material。

Waste Collection。

物流を無視してPassenger Mobilityだけを最適化すると、都市全体のTrafficを理解できない。

[ Urban\ Mobility

People\ Flow
+
Goods\ Flow
]

である。

人と物のFlowを同時に扱う必要がある。

────────

Curbという希少資源

都市には興味深いPhysical Bottleneckがある。

Roadside Spaceである。

Taxiが乗降する。

Delivery Vehicleが停車する。

Busが停まる。

自転車が通る。

Parking需要がある。

[
Multiple\ Demand
\rightarrow
Limited\ Curb\ Space
]

となる。

AIによるMobility Optimizationは、Vehicleだけではなく都市空間のResource Allocationへ到達する。

────────

Building

都市ではBuildingも巨大なPhysical Nodeである。

Office。

Home。

Hospital。

Factory。

Retail。

Data Center。

BuildingはEnergyを消費する。

人を収容する。

物流のDestinationになる。

[
Building
\leftrightarrow
Mobility
\leftrightarrow
Energy
]

である。

Building AutomationとCity Systemを接続すれば、新しいOptimizationが可能になる。

────────

Building Energy

BuildingのHeating、Cooling、Lighting、EquipmentはEnergy Demandを生む。

AIで、

Occupancy。

Weather。

Electricity Price。

Building State。

を観測してControlすれば、

[
Building\ Data
\rightarrow
AI
\rightarrow
Energy\ Optimization
]

となる。

第4章のEnergy Feedback Loopが都市Scaleへ広がる。

────────

Distributed Energy

Solar。

Battery。

EV。

Building。

都市には分散型Energy Resourceが増えていく。

すると、

[
Building
\rightarrow
Energy\ Consumer
]

だけでなく、

[
Building
\rightarrow
Energy\ Resource
]

にもなり得る。

都市のEnergy Architectureが中央集中的な一方向Flowから、よりNetwork化されたSystemへ変化する可能性がある。

────────

EVと都市Grid

Electric Vehicleが増えればCharging Demandが都市Gridへ入る。

帰宅時間に一斉ChargingすればPeak Loadが増える。

一方、Charging Timeを調整できればDemand Flexibilityとして利用できる。

[
Mobility
\leftrightarrow
Grid
]

となる。

都市ではTransport PolicyとEnergy Policyを分離しにくくなる。

────────

WaterとWaste

都市にはWater、Sewage、Waste CollectionといったInfrastructureもある。

Leak Detection。

Demand Forecast。

Route Optimization。

Equipment Maintenance。

AIを利用できる領域は多い。

しかし重要なのは、Technologyを追加することではない。

[
Physical\ Infrastructure
\rightarrow
Measurement
\rightarrow
Maintenance
\rightarrow
Learning
]

というFeedback Loopを閉じることにある。

────────

Emergency

都市ではEmergencyが起こる。

Fire。

Flood。

Earthquake。

Accident。

Medical Emergency。

Systemが通常時だけ最適化されていても十分ではない。

[
Normal\ Efficiency
+
Emergency\ Resilience
]

が必要になる。

都市はEfficiencyだけでなくResilienceを検証するEnvironmentでもある。

────────

Woven City型実証

新しいMobility、Robot、Energy、Building Technologyを都市Scaleで実証する試みには重要な意味がある。

Labでは個別Technologyを評価できる。

FactoryではControlled EnvironmentでPhysical AIを評価できる。

都市では、

[
Technology
+
Human
+
Infrastructure
+
Institution
]

を同時に検証できる。

つまり都市はTechnologyそのものではなく、Technologyが社会Systemへ入ったときの挙動を観測するEnvironmentになる。

────────

Living Lab

この意味で都市の一部をLiving Labとして扱う考え方がある。

実際の人が生活する。

実際のMobilityが動く。

実際のBuildingを使う。

Technologyを導入する。

Outcomeを測定する。

[
Deploy
\rightarrow
Live
\rightarrow
Measure
\rightarrow
Improve
]

となる。

ただし住民はExperiment Subjectではない。

Consent、Transparency、Safety、Governanceが必要になる。

────────

Simulationだけでは足りない

都市Digital Twinを構築すれば、

Traffic。

Pedestrian Flow。

Energy。

Building。

Infrastructure。

をSimulationできる。

[
City
\rightarrow
Digital\ Twin
\rightarrow
Simulation
]

しかし都市はHuman Behaviorを含むため、Simulation Errorは大きくなりうる。

[
City\ Twin
\neq
City
]

という境界を維持しなければならない。

────────

Urban Digital Twin

都市Digital Twinの価値は未来を完全予測することではない。

Road Closureをしたらどうなるか。

Bus Routeを変更したらどうなるか。

新しいData Centerを建てたらGridへ何が起こるか。

災害時にどこがBottleneckになるか。

複数Scenarioを比較する。

[
Policy/Design
\rightarrow
Simulation
\rightarrow
Comparison
]

に使う。

Decision SupportとしてのTwinである。

────────

RealityによるCalibration

実際にPolicyやInfrastructureを変更する。

Outcomeを測る。

Simulationとの差を見る。

Twinを更新する。

[
Twin
\rightarrow
Reality
\rightarrow
Error
\rightarrow
Twin
]

となる。

都市Digital TwinもRealityから学習し続けなければならない。

────────

Privacy

都市AIではPrivacyが中心課題になる。

Camera。

Location。

Mobility Data。

Building Data。

個人の生活Patternを推定できるDataが大量に存在する。

したがって、

[
More\ Observation
\neq
Better\ City
]

である。

必要なDataだけを取得する。

Anonymization。

Aggregation。

Access Control。

Retention。

目的を限定する。

Privacy-preserving Architectureが必要になる。

────────

Surveillanceとの境界

都市をより詳しく観測できることは、同時にSurveillance Capabilityを増やすことでもある。

したがってSmart Cityを、

「すべてをSensorで観測する都市」

として設計するのは危険である。

[
Optimization
\leftrightarrow
Civil\ Liberty
]

のBalanceが必要になる。

Technical Capabilityが存在することと、社会がそれを許容すべきことは同じではない。

────────

Governance

都市ではAIによるDecisionがPublic Interestへ影響する。

Traffic Signalをどう変えるか。

Road Spaceを誰へ配分するか。

Public Resourceをどこへ投資するか。

これらは企業Algorithmだけで決める問題ではない。

[
Technical\ Decision
+
Public\ Governance
]

が必要になる。

都市AIにはDemocratic Accountabilityも関係する。

────────

Algorithmic Fairness

Optimization Objectiveによって恩恵を受ける地域と不利益を受ける地域が分かれる可能性がある。

平均Travel Timeを最小化した結果、一部NeighborhoodにTrafficが集中するかもしれない。

したがって、

[
Average\ Optimization
\neq
Fair\ Outcome
]

である。

都市ではDistributional Impactを見る必要がある。

────────

Human Feedback

住民は数字ではない。

便利になったか。

騒音が増えたか。

安全に感じるか。

歩きやすくなったか。

生活Qualityが改善したか。

[
Urban\ KPI
+
Human\ Experience
]

を同時に測る必要がある。

Social Feedbackが不可欠になる。

────────

Public Acceptance

Technologyが高性能でも、住民が受け入れなければScaleできない。

Autonomous Shuttle。

Delivery Robot。

Drone。

Sensor Infrastructure。

それぞれにPublic Acceptanceがある。

[
Technology
\rightarrow
Public\ Experience
\rightarrow
Acceptance
\rightarrow
Scale
]

というLoopが形成される。

────────

Regulationも学習する

新Technologyには最初から最適なRuleが存在するとは限らない。

限定区域で実証する。

Incidentを観測する。

Ruleを更新する。

Scaleを拡大する。

[
Experiment
\rightarrow
Evidence
\rightarrow
Regulation
\rightarrow
Deployment
]

となる。

RegulationもRealityから学習できる。

────────

Regulatory Sandbox

このため限定Environmentで新Technologyを試すRegulatory Sandboxには意味がある。

全面解禁か全面禁止かではなく、

限定。

観測。

検証。

更新。

を繰り返す。

[
Controlled\ Deployment
\rightarrow
Evidence
\rightarrow
Policy\ Learning
]

である。

Physical AIの社会実装にもFeedback Architectureが必要になる。

────────

CompanyとCity

企業は都市を所有しているわけではない。

したがって企業単独のOptimizationを都市へ押しつけることはできない。

Technology Company。

Mobility Company。

Utility。

Real Estate Company。

Municipality。

Citizen。

複数主体のCoordinationが必要になる。

[
\boxed{
Urban\ Innovation



Firm\ Boundary
}
]

である。

────────

Public–Private Connection

都市Innovationの重要なEdgeがPublic–Private Connectionである。

企業はTechnologyとCapitalを持つ。

自治体はPublic Infrastructureと制度を持つ。

大学はResearchを持つ。

住民はRealityとHuman Feedbackを持つ。

[
Company
\leftrightarrow
Government
\leftrightarrow
University
\leftrightarrow
Citizen
]

を接続する。

都市はMulti-stakeholder Learning Systemになる。

────────

Universityと都市

Universityは都市の中でResearch Nodeにもなる。

Mobility。

Energy。

Healthcare。

Urban Planning。

Data Science。

Research Resultを実証する。

都市からDataとQuestionを得る。

[
University
\rightarrow
City
\rightarrow
Research
]

となる。

Research Feedback Loopが社会Scaleへ広がる。

────────

Startupと都市

Startupにとって都市はInitial Deployment Environmentになりうる。

新しいMobility。

Delivery Robot。

Energy Management。

Urban Software。

限定地域で試す。

結果を得る。

Productを改善する。

[
Startup
\rightarrow
City\ Deployment
\rightarrow
Feedback
\rightarrow
Startup
]

となる。

都市がInnovation Ecosystemの実験場になる。

────────

Capitalと都市

都市InfrastructureにはCapitalが必要になる。

Public Budget。

Private Capital。

Infrastructure Finance。

Real Estate Investment。

新しいTechnologyへ投資する。

しかしReturnはFinancial Returnだけとは限らない。

Travel Time。

Safety。

Health。

Resilience。

Environmental Outcome。

[
Capital
\rightarrow
Urban\ Outcome
]

を見る必要がある。

────────

City-level Outcome

都市AIの評価は、Model Accuracyではない。

Congestionは減ったか。

事故は減ったか。

Energy Useは改善したか。

Accessibilityは上がったか。

Public Serviceは改善したか。

住民のQuality of Lifeはどうか。

[
AI\ Capability
\rightarrow
Urban\ Outcome
]

まで測る。

────────

Unintended Consequences

都市は複雑なため、一つの改善が別の問題を生むことがある。

Roadを広げた。

Trafficが増えた。

Ride-hailingを便利にした。

Vehicle Kilometerが増えた。

Deliveryを高速化した。

Curb Congestionが増えた。

[
Intervention
\rightarrow
Unexpected\ System\ Response
]

が起こる。

だから都市ではFeedbackが特に重要になる。

────────

Adaptive Policy

一度Policyを決めて固定するのではなく、

実装する。

測る。

修正する。

[
Policy_t
\rightarrow
Outcome
\rightarrow
Policy_{t+1}
]

とする。

企業のProduct Learningと同様に、都市政策にもLearning Loopを持たせることができる。

────────

Urban Feedback Loop

都市を一つのLearning Systemとして表すと、

[
\boxed{
City
\rightarrow
Observation
\rightarrow
Analysis
\rightarrow
Intervention
\rightarrow
Outcome
\rightarrow
Human/Social\ Feedback
\rightarrow
City
}
]

となる。

ただし中央AIがすべてを制御するLoopではない。

複数主体が異なる役割を持ちながら、Evidenceによって改善する分散型Feedback Loopである。

────────

PhysicalとSocialの二重Twin

都市ではPhysical StateだけをModel化しても足りない。

TrafficやEnergyはPhysical Stateである。

しかしTrust、Acceptance、Fairness、Human BehaviorはSocial Stateである。

したがって、

[
Physical\ Model
+
Social\ Observation
]

が必要になる。

Social Realityを完全にDigital Twin化できるという意味ではない。

むしろModel化できない領域をHuman Feedbackで補完する必要がある。

────────

都市は最終的なVerification Environmentになる

AI Labで動いた。

Simulationでも動いた。

Factoryでも動いた。

しかし社会で本当に有用かどうかは別問題である。

都市へDeploymentすると、

Real Human。

Real Institution。

Real Constraint。

が応答する。

[
Technology
\rightarrow
City
\rightarrow
Social\ Reality
]

ここで初めてTechnologyの社会的価値が検証される。

────────

都市という実証環境

都市が巨大な実証環境である理由は、Technologyを試せるからだけではない。

Technologyと人間。

Technologyと制度。

TechnologyとInfrastructure。

Technologyと他のTechnology。

そのConnectionそのものを検証できるからである。

[
\boxed{
Technology
+
Physical\ Reality
+
Society
\rightarrow
Urban\ Experiment
}
]

ここでは一社のProduct PerformanceよりSystem-level Outcomeが重要になる。

────────

Missing NodeよりMissing Edge

都市には多くのNodeがすでに存在している。

Train。

Bus。

Vehicle。

Building。

Grid。

Hospital。

Warehouse。

Data。

Government。

Company。

Citizen。

問題は、それらの間のConnectionが弱いことにある場合が多い。

[ Strong\ Nodes + Weak\ Edges

Fragmented\ City
]

である。

したがって次のUrban Innovationは、さらに新しいPlatformを一つ追加することより、既存System間のMissing Edgeを閉じることから生まれる可能性がある。

────────

都市という実証環境

本節を最小構造へ圧縮すると、

[
\boxed{
Deploy
\rightarrow
Observe
\rightarrow
Measure
\rightarrow
Human\ Feedback
\rightarrow
Govern
\rightarrow
Improve
}
]

である。

都市はFactoryよりOpenである。

物流より多様である。

Vehicleより多くの主体を含む。

そのためAIが社会へ接続されたときに何が起きるのかを最も厳しく検証するEnvironmentになる。

そして都市で最終的に返ってくるFeedbackは、Machine Sensorの数値だけではない。

人間の評価。

Trust。

Comfort。

Fairness。

Accessibility。

Quality of Life。

である。

ここから第6章は、Physical FeedbackからSocial Feedbackへ進む。

次節では、その中心にあるものを扱う。

第5節　Human Feedback。

AIによる最適化が、人間にとって本当により良いRealityを生み出しているのか。その最後の測定主体としての人間を読み解く。
第5節　Human Feedback

AIがPhysical Realityへ入ると、最後に無視できない観測主体が現れる。

人間である。

Vehicleは安全に走ったか。

Delivery Robotは邪魔ではなかったか。

都市の交通は本当に便利になったか。

AIによるSchedulingは働きやすさを改善したか。

Technologyが社会へ入った結果、人間はどう感じ、どう行動し、どのような価値を得たのか。

ここで返ってくる情報は、Sensor Dataだけではない。

[
\boxed{
Human\ Experience
\rightarrow
Feedback
}
]

Physical AIが社会へ広がるほど、Human FeedbackはSystem Performanceを評価する中心的なLayerになる。

────────

Machine Metricだけでは足りない

AI Systemは多くの数値を測定できる。

Latency。

Accuracy。

Throughput。

Energy Consumption。

Failure Rate。

Travel Time。

しかし、これらだけで社会的価値は決まらない。

Autonomous Vehicleの事故率が低くても、乗客が極端に不安を感じるかもしれない。

Deliveryが速くなっても、Workerの負荷が高まりすぎるかもしれない。

Traffic Flowが改善しても、一部地域に騒音が集中するかもしれない。

したがって、

[
Technical\ KPI
\neq
Human\ Outcome
]

である。

────────

Experienceという観測値

Human Feedbackにはさまざまな形がある。

満足度。

不安。

Trust。

Comfort。

疲労。

理解しやすさ。

Accessibility。

Fairness。

これらは完全に一つの数値へ還元できるものではない。

それでも、System Designへ戻すべき重要な情報である。

[
Technology
\rightarrow
Human\ Experience
\rightarrow
Design
]

というLoopを持つ必要がある。

────────

Trust

Physical AIではTrustが特に重要になる。

AIが何をするか分からない。

なぜ止まったのか分からない。

なぜRouteを変えたのか分からない。

この状態では、Technical Performanceが高くても人は利用しない可能性がある。

したがって、

[
Capability
+
Predictability
+
Transparency
\rightarrow
Trust
]

という構造が重要になる。

────────

Predictability

人間は、Systemが完璧でなくても挙動を予測できれば対応しやすい。

Vehicleがどこで止まるのか。

Robotがどちらへ動くのか。

AIがどのタイミングでHumanへControlを返すのか。

[
Predictable\ Behavior
\rightarrow
Human\ Coordination
]

である。

Physical AIでは、最高PerformanceだけでなくHuman-readableな挙動も重要になる。

────────

Explainability

すべてのAI Decisionを完全に説明できるとは限らない。

しかし重要なDecisionでは、

何が起きたか。

どのDataを参照したか。

どのRuleが適用されたか。

どこにUncertaintyがあったか。

を追跡できる必要がある。

[
Decision
\rightarrow
Traceability
\rightarrow
Accountability
]

である。

Explainabilityは単なるUI Featureではなく、Operational Trustの一部になる。

────────

Human Intervention

Physical SystemではHumanが介入する瞬間が重要なDataになる。

Emergency Stop。

Manual Override。

AI RecommendationのReject。

Route変更。

こうしたInterventionを記録すれば、

[
Human\ Intervention
\rightarrow
System\ Weakness
]

を発見できる。

人間がAIを止めた場所は、ModelやOperationのBottleneckを示している可能性がある。

────────

Human Correction

AIが誤ったObjectを認識する。

Workerが訂正する。

AIが不適切なMaintenance Proposalを出す。

Engineerが修正する。

[
AI\ Output
\rightarrow
Human\ Correction
\rightarrow
Learning
]

となる。

Human Correctionは、高価だが非常に高品質なFeedbackになり得る。

────────

Preference Feedback

正解が一つではない領域では、Human Preferenceが重要になる。

Vehicleの乗り心地。

Robotの動作速度。

Notificationの頻度。

Route Choice。

最適解はPhysicsだけでは決まらない。

[
Technically\ Valid\ Options
\rightarrow
Human\ Preference
\rightarrow
Selected\ Design
]

となる。

AIが社会へ入るほど、Optimization Objectiveそのものを人間から学ぶ必要がある。

────────

Value Alignmentを企業レベルで考える

企業Systemでは、何を最大化するかが重要になる。

Speed。

Cost。

Revenue。

Safety。

Worker Well-being。

Accessibility。

Environment。

すべてを同時には最大化できない。

したがって、

[ Objective\ Function

Technical\ Goals
+
Human\ Values
]

として設計する必要がある。

Human FeedbackはObjective Functionを更新する情報になる。

────────

Worker Feedback

FactoryやWarehouseでは、WorkerからのFeedbackが重要である。

AI Schedulingは現場に無理を生んでいないか。

Robotは危険ではないか。

Interfaceは使いやすいか。

Maintenance Recommendationは現実的か。

[
AI\ Operation
\rightarrow
Worker\ Experience
\rightarrow
Operational\ Improvement
]

となる。

現場の人間は単なるAIの利用者ではない。

Physical Realityを最も深く観測しているSensorでもある。

────────

Tacit Knowledge

WorkerやEngineerはData化されていないKnowledgeを持つ。

Machineの音。

微妙な振動。

作業順序の違和感。

Customerの反応。

こうしたTacit Knowledgeを無視すると、AIはDigital RecordだけをRealityだと誤認する。

[
Machine\ Data
+
Human\ Tacit\ Knowledge
\rightarrow
Better\ Reality\ Model
]

である。

────────

Customer Feedback

CustomerもSystemの重要なObserverである。

商品は届いたか。

Vehicle Rideは快適だったか。

Robot Serviceは役に立ったか。

AI Recommendationは信頼できたか。

[
Product/Service
\rightarrow
Customer
\rightarrow
Feedback
]

となる。

利用後のExperienceをProduct Designへ戻すことで、Customer Realityが企業のLearning Loopへ入る。

────────

Non-user Feedback

しかし利用者だけを観測しても不十分である。

Autonomous Vehicleを利用していないPedestrian。

Delivery Robotの横を歩く住民。

Data Centerの近くに暮らす人。

Technologyの影響を受けるがCustomerではない人もいる。

したがって、

[
Customer\ Feedback
\subset
Social\ Feedback
]

である。

企業はUserだけでなくAffected Stakeholderを見る必要がある。

────────

Accessibility

Technologyが一部の人にだけ使えるなら、社会的Outcomeは限定される。

高齢者。

障害のある人。

Digital Literacyが低い人。

地方に住む人。

言語が異なる人。

[
Technology\ Capability
\rightarrow
Accessible\ Capability
]

へ変換できるかを見る。

Human Feedbackは、誰が取り残されているかを発見するSignalにもなる。

────────

Fairness

平均的なOutcomeが改善しても、特定Groupだけが不利益を受けることがある。

移動時間は平均で短縮した。

しかし特定地域のTrafficは増えた。

AutomationでProductivityは上がった。

しかし一部Workerの負荷が急増した。

[
Average\ Improvement
\neq
Fair\ Improvement
]

である。

Human FeedbackをGroup別、地域別、役割別に見る必要がある。

────────

Comfort

Autonomous MobilityではSafetyだけでなくComfortも重要になる。

Brakeが急すぎる。

Accelerationが不自然。

Vehicleが他車へ近づきすぎる。

Technicalには安全でも、Human Experienceが悪ければ普及しにくい。

[
Safe
+
Comfortable
\rightarrow
Usable
]

である。

Physical AIではQualitativeなHuman ExperienceがDeployment Scaleを左右する。

────────

Perceived Safety

統計的に安全であることと、人が安全だと感じることも同じではない。

[
Measured\ Safety
\neq
Perceived\ Safety
]

両者が大きく乖離すれば、Technology Adoptionは進まない。

ただし感覚だけに合わせてSafetyを判断するわけでもない。

Objective MeasurementとSubjective Experienceを両方見る。

────────

Human BehaviorがSystemを変える

Human FeedbackはQuestionnaireだけではない。

行動そのものもFeedbackである。

Robotを避ける。

Serviceを使わなくなる。

別Routeを選ぶ。

AI Recommendationを毎回無視する。

[
Human\ Behavior
\rightarrow
Implicit\ Feedback
]

である。

利用率やOverride Rateなどから、Systemと人間のMismatchを発見できる。

────────

ExplicitとImplicit Feedback

Human Feedbackには二種類ある。

明示的に答えてもらう。

[
Explicit\ Feedback
]

実際の行動から推定する。

[
Implicit\ Feedback
]

両者には利点と限界がある。

「満足している」と答えていても利用をやめるかもしれない。

利用しているから満足しているとも限らない。

複数Signalを組み合わせる必要がある。

────────

Observationの倫理

人間からFeedbackを取得するために、すべてを監視すればよいわけではない。

Privacy。

Consent。

Purpose Limitation。

Data Minimization。

が必要になる。

[
Learning
\neq
Unlimited\ Observation
]

である。

Human Feedback SystemそのものにもGovernanceが必要になる。

────────

Consent

特に都市やMobilityでは、人間が意図せずSensorの対象になることがある。

Camera。

Location Data。

Behavioral Data。

したがって、

誰がDataを取得するのか。

何の目的で使うのか。

どれだけ保持するのか。

を明確にする必要がある。

Human Feedbackを得ることとHuman Autonomyを尊重することを両立させる。

────────

Privacy-preserving Learning

必要に応じて、

Aggregation。

Anonymization。

On-device Processing。

Limited Retention。

Access Control。

などによって、Privacy Riskを抑えながらFeedbackを利用する。

[
Useful\ Feedback
+
Privacy\ Protection
]

を同時に成立させる。

────────

Human-in-the-loop

Human FeedbackをOperationへ直接入れる方法がHuman-in-the-loopである。

AIがRecommendationする。

Humanが確認する。

承認、修正、拒否する。

その結果を記録する。

[
AI
\rightarrow
Human
\rightarrow
Decision
\rightarrow
Learning
]

となる。

Physical AIでは重要なGovernance Architectureになる。

────────

Human-on-the-loop

すべてのActionをHumanが事前承認すると速度が出ない場合もある。

そこで通常OperationはAIが実行し、Humanは監視して必要時に介入する。

[
AI\ Action
\rightarrow
Human\ Oversight
]

というHuman-on-the-loopもある。

Risk LevelによってHumanの位置を変える。

────────

Risk-based Autonomy

低Risk Taskは自動化する。

中Risk TaskはHuman Oversight。

高Risk TaskはHuman Approval。

[
Risk
\rightarrow
Level\ of\ Human\ Control
]

というArchitectureにする。

Autonomyを一律に最大化するのではなく、Impactに応じて設計する。

────────

Feedback Fatigue

人間へFeedbackを求めすぎる問題もある。

毎回Ratingする。

毎回確認する。

大量Alertを出す。

すると人間は無視するようになる。

[
Too\ Much\ Feedback\ Request
\rightarrow
Low\ Quality\ Feedback
]

となる。

Human Attentionも希少Resourceである。

必要な場面で高品質なFeedbackを取得する設計が重要になる。

────────

Alert Fatigue

FactoryやHealthcare、MobilityではAIが大量のWarningを出す可能性がある。

False Positiveが多ければ、人はAlertを信用しなくなる。

[
Too\ Many\ Alerts
\rightarrow
Low\ Trust
]

である。

AI Accuracyだけでなく、Human Attention Costを含めて最適化する必要がある。

────────

FeedbackをProductへ戻す

Human Feedbackを集めても、ProductやOperationが変わらなければ意味がない。

[
Feedback
\rightarrow
Product\ Change
]

が必要になる。

UIを変える。

Robot Behaviorを変える。

Vehicle Planningを変える。

Safety Policyを変える。

FeedbackからImplementationまでのEdgeが重要である。

────────

FeedbackをResearchへ戻す

さらに重要なHuman FeedbackはResearch Questionへ戻る。

人間が特定状況でAIを信用しない。

なぜか。

Modelにどの能力が不足しているのか。

新しいResearch Problemになる。

[
Human\ Experience
\rightarrow
Research\ Question
]

となる。

社会実装がResearch Agendaを更新する。

────────

FeedbackをCapitalへ戻す

Human OutcomeによってCapital Allocationも変わる。

Adoptionが高い。

Safety Outcomeがよい。

Customer Valueが確認できた。

追加投資する。

逆に、

Trustが低い。

事故Riskが高い。

社会的反発が強い。

ならばDeployment Strategyを見直す。

[
Human\ Outcome
\rightarrow
Resource\ Reallocation
]

である。

Human Feedbackは経営Decisionへも戻る。

────────

FeedbackをGovernanceへ戻す

公共空間ではHuman Feedbackが制度へも戻る。

住民の意見。

Incident。

利用状況。

Access格差。

これらからRuleを更新する。

[
Society
\rightarrow
Feedback
\rightarrow
Policy
]

となる。

Technology FeedbackとInstitutional Feedbackが接続する。

────────

Human Feedbackの時間軸

人間の反応は一つの時間軸ではない。

瞬間的なReaction。

数週間の利用Experience。

数年後の社会変化。

それぞれ異なる。

[
Immediate
\rightarrow
Behavioral
\rightarrow
Long\ Term
]

のFeedbackを見る必要がある。

短期満足が長期Well-beingを意味するとは限らない。

────────

Long-term Outcome

便利なServiceが普及した。

しかしWalkingが減った。

地域交通が衰退した。

Employment Structureが変わった。

Technologyの長期Outcomeは初期KPIでは見えない。

したがって、

[
Short\ Term\ KPI
+
Long\ Term\ Impact
]

を分けて観測する。

Social Feedback Loopには長い時間が必要になる。

────────

Human FeedbackとCausality

人間の満足度が下がった。

その原因がAIなのか、Priceなのか、Environmentなのか。

単純には分からない。

したがってHuman Feedbackでも、

[
Feedback
\neq
Cause
]

である。

Controlled Experiment、比較、定性調査などを組み合わせて原因を探る。

────────

Qualitative Data

すべてのHuman ExperienceをNumeric Scoreへ圧縮する必要はない。

Interview。

Observation。

Open-ended Feedback。

Incident Report。

Qualitative Dataから重要なPatternが見つかることがある。

[
Quantitative
+
Qualitative
\rightarrow
Better\ Understanding
]

である。

────────

AIによるFeedback Analysis

大量のHuman FeedbackをAIで分析することもできる。

Reviewを分類する。

ComplaintをCluster化する。

Emerging Issueを検出する。

ただしAIによる要約でMinority Voiceが消えないよう注意する必要がある。

[
Human\ Feedback
\xrightarrow{AI}
Structured\ Insight
]

としつつ、Raw Voiceへ戻れる構造を持つ。

────────

Minority Signal

多数派が満足していても、一部の人に重大なSafety Problemが起きているかもしれない。

したがって、

[
Rare\ Human\ Signal
]

をAverageの中へ埋めてはいけない。

Physical AIではRare Failureと同様に、Rare Social Harmも重要になる。

────────

Human Feedback Loop

ここまでを一つにつなぐ。

Technologyを実装する。

Humanが利用・経験する。

Experienceを観測する。

問題を分析する。

Product、Policy、AIを更新する。

再び利用される。

[
\boxed{
Technology
\rightarrow
Human\ Experience
\rightarrow
Feedback
\rightarrow
Learning
\rightarrow
Technology
}
]

これがHuman Feedback Loopである。

────────

Machine Feedbackとの統合

Physical AIではMachine FeedbackとHuman Feedbackを統合する必要がある。

Machineは安全だと測定している。

しかしHumanは不安を感じている。

あるいは逆もある。

[
Machine\ Feedback
+
Human\ Feedback
\rightarrow
System\ Understanding
]

両者の不一致自体が重要なSignalになる。

────────

Realityの二つの側面

Physical Realityには、

Machineが測定できるReality

と、

人間が経験するReality

がある。

[
Measured\ Reality
]

と、

[
Experienced\ Reality
]

である。

社会実装では両方を扱う必要がある。

────────

Human Feedbackは最終Objectiveではない

ただし「人が好むものをすべて最大化すればよい」という意味でもない。

短期的PreferenceがSafetyやLong-term Welfareと衝突することもある。

したがって、

[
Human\ Preference
\neq
Automatic\ Optimality
]

である。

Feedbackは重要なInputだが、Safety、Law、Ethics、Long-term Outcomeと統合して判断する必要がある。

────────

Social Feedbackへの橋

Human Feedbackが個人Experienceに留まらず、

多数の住民。

企業。

行政。

Community。

へ広がると、Social Feedbackになる。

[
Individual\ Feedback
\rightarrow
Collective\ Feedback
]

である。

ここで企業のProduct Loopは社会Systemへ接続される。

────────

Human Feedback

本節の問いへ戻る。

AIが実世界へ接続されたとき、誰がその成功を決めるのか。

Modelだけではない。

Sensorだけでもない。

市場価格だけでもない。

最終的には、TechnologyによってRealityを経験する人間が重要なObserverになる。

[
\boxed{
AI
\rightarrow
Physical\ Reality
\rightarrow
Human\ Experience
\rightarrow
Feedback
\rightarrow
AI/System
}
]

AIが高度になるほど、人間をLoopの外へ出すのではない。

むしろ、Human Feedbackをより正確にSystemへ戻す必要がある。

そして複数の人間、Community、InstitutionからのFeedbackが集まると、Loopは個人を越える。

次節では、その拡張を扱う。

第6節　Social Feedback Loop。

AI、Mobility、物流、都市が社会へ実装されたとき、社会全体がどのように応答し、その応答が企業とTechnologyを再び変えるのかを読み解く。
第6節　Social Feedback Loop

AIが社会へ実装されると、Feedbackの主体は個人だけではなくなる。

住民。

企業。

行政。

自治体。

学校。

病院。

交通機関。

Community。

Regulator。

複数の主体が同じTechnologyから異なる影響を受け、それぞれ異なる形で応答する。

このとき必要になるのは、Human Feedbackをさらに社会Scaleへ拡張した、

Social Feedback Loop

である。

[
\boxed{
Technology
\rightarrow
Society
\rightarrow
Social\ Outcome
\rightarrow
Feedback
\rightarrow
Technology/Governance
}
]

企業がProductを改善するだけでは閉じない。

社会の反応が制度、企業行動、Capital Allocation、Technology Designへ戻ることで初めてLoopが閉じる。

────────

Social FeedbackはUser Feedbackより広い

Customer Feedbackは重要である。

しかし社会へ実装されたTechnologyの影響を受けるのはCustomerだけではない。

Autonomous Vehicleを利用しないPedestrian。

Data Centerの近隣住民。

Warehouseで働くWorker。

Delivery Vehicleが走る地域。

AI SystemによってDecisionを受ける人。

したがって、

[
User
\subset
Affected\ Society
]

である。

Social Feedbackでは、直接利用者ではないStakeholderも観測対象になる。

────────

Private ProductからPublic Realityへ

企業のProductがPrivate Spaceだけで利用される場合、Feedback Loopは比較的企業内部へ閉じやすい。

しかしMobility、Energy、Logistics、Urban AIはPublic Realityへ入る。

Road。

Grid。

Water。

Land。

Public Space。

ここでは企業のActionが共有Resourceへ影響する。

[
Private\ Decision
\rightarrow
Public\ Outcome
]

となる。

したがって企業だけで評価基準を決めることはできない。

────────

Social Outcome

社会へ実装されたTechnologyのOutcomeは多次元になる。

Safety。

Accessibility。

Employment。

Congestion。

Energy Use。

Environmental Impact。

Privacy。

Fairness。

Economic Productivity。

Quality of Life。

一つのKPIでは表現できない。

[ Social\ Outcome

Multi\ Objective
]

である。

ある指標を改善すると別の指標が悪化する場合もある。

────────

EfficiencyとDistribution

例えば都市交通を平均的に効率化したとする。

平均Travel Timeは短くなった。

しかし特定地域だけTrafficが増えた。

全体効率は改善しても、BenefitとCostの分布が偏ることがある。

[
Efficiency
\neq
Distributional\ Fairness
]

である。

Social Feedbackでは平均値だけでなく、誰がBenefitを受け、誰がCostを負担しているのかを見る必要がある。

────────

Employment

AIとAutomationがPhysical Industryへ入れば、仕事の構造も変わる。

一部Taskが自動化される。

新しいTaskが生まれる。

Skill Requirementが変化する。

WorkerがAIを使うようになる。

[
Technology
\rightarrow
Work\ Structure
]

となる。

Productivityだけでなく、Training、Transition、Work QualityもSocial Outcomeになる。

────────

AutomationとJob Design

「Robotが何人を代替したか」だけを見ると狭い。

より重要なのは、

危険作業を減らせたか。

単調作業を減らせたか。

人間がより高度な判断へ移れたか。

新しいSkillを習得できたか。

[
Automation
\rightarrow
Job\ Redesign
]

という観点である。

Technology AdoptionとHuman Capability Developmentを接続する必要がある。

────────

Accessibility

Autonomous Mobilityが一部の人に新しい移動手段を提供する。

AI ServiceがLanguage Barrierを下げる。

Robotが身体的負担を補助する。

TechnologyにはAccessを拡張するPotentialがある。

[
Technology
\rightarrow
Expanded\ Access
]

しかしCost、Location、Digital Literacyによって利用できない人が残れば、Gapも生じる。

────────

Digital DivideからPhysical Divideへ

AI時代の格差はInternet Accessだけではない。

Compute Access。

Mobility Access。

Energy Infrastructure。

AI-enabled Healthcare。

Automation Benefit。

Physical Infrastructureへの接続差が生まれる。

[
Digital\ Divide
\rightarrow
Capability\ Divide
]

として捉える必要がある。

Social Feedbackは、Technology Benefitがどこへ届いていないかを示す。

────────

Privacy

社会ScaleではObservation能力が大きくなる。

Vehicle Camera。

Urban Sensor。

Location Data。

Mobility Pattern。

Workplace Sensor。

便利さのためのData取得がSurveillance Capabilityへ変わる可能性がある。

[
Observation\ Capability
\rightarrow
Privacy\ Risk
]

である。

社会からの反応が強ければ、Technology DesignやData Governanceを変更する必要がある。

────────

TrustはSystem-levelで形成される

一企業のAIが高性能でも、社会全体のAIへのTrustが低ければAdoptionは難しくなる。

事故。

Data Breach。

不透明なDecision。

不公平なOutcome。

一つのIncidentがIndustry全体のTrustへ影響することもある。

[
Company\ Event
\rightarrow
Industry\ Trust
]

となる。

Trustも企業境界を越えるShared Resourceである。

────────

IncidentからRegulationへ

Physical AIで重大Incidentが発生する。

社会が反応する。

Mediaが報道する。

Regulatorが調査する。

Ruleが変更される。

企業がSystemを修正する。

[
Incident
\rightarrow
Social\ Response
\rightarrow
Regulation
\rightarrow
Technology\ Change
]

となる。

ここに典型的なSocial Feedback Loopがある。

────────

Regulationは外部制約ではない

企業から見るとRegulationは外部Constraintに見える。

しかし社会System全体では、RegulationもFeedback Mechanismの一つである。

Technologyが新しいRiskを生む。

Evidenceが蓄積する。

社会が許容範囲を再定義する。

[
Technology
\rightarrow
Evidence
\rightarrow
Rule
]

となる。

Regulationも社会がTechnologyから学習した結果として更新される。

────────

ただしRegulationも誤る

制度も完全ではない。

過度に厳しければInnovationを止める。

緩すぎればRiskを増やす。

そのため、

[
Regulation_t
\rightarrow
Outcome
\rightarrow
Regulation_{t+1}
]

というPolicy Learningが必要になる。

制度も一度制定して終わりではない。

────────

Evidence-based Governance

新しいTechnologyを評価するとき、期待や恐怖だけで判断するのではなく、実際のOutcomeを測る。

Safety Data。

Utilization。

Accessibility。

Economic Impact。

Environmental Impact。

Incident。

[
Deployment
\rightarrow
Evidence
\rightarrow
Governance
]

となる。

Social Feedback Loopを高品質にするにはMeasurementが必要になる。

────────

Regulatory Sandbox

不確実性が高い領域では、限定条件でDeploymentする方法がある。

Regionを限定する。

Userを限定する。

Speedを限定する。

Riskを管理する。

Outcomeを測る。

[
Limited\ Deployment
\rightarrow
Evidence
\rightarrow
Rule\ Update
]

となる。

全面許可か全面禁止かという二択ではなく、社会もExperimentとLearningを行う。

────────

Community Feedback

Infrastructureは地域社会へ具体的な影響を与える。

Data Center。

Warehouse。

Power Facility。

Delivery Network。

住民から見れば、

雇用。

Tax Revenue。

Noise。

Traffic。

Water Use。

Energy Price。

複数のOutcomeがある。

[
Infrastructure
\leftrightarrow
Community
]

である。

Community Feedbackを無視すれば、Technicalに可能なProjectでもSocialに実装できない。

────────

Social License

法律上許可されていることと、社会から受け入れられていることは同じではない。

[
Legal\ Permission
\neq
Social\ Acceptance
]

である。

企業には社会的に継続運営できるTrustが必要になる。

これを広い意味でSocial Licenseとして捉えることができる。

────────

ProtestもFeedbackである

社会からのFeedbackはSurveyだけではない。

利用しない。

反対運動を起こす。

Policy Changeを要求する。

訴訟する。

投資判断を変える。

こうした行動もSignalである。

[
Social\ Action
\rightarrow
Feedback
]

企業は肯定的なFeedbackだけでなく、拒否や抵抗もSystem Informationとして扱う必要がある。

────────

MarketもSocial Feedbackである

CustomerがProductを選ぶ。

離れる。

価格を受け入れる。

Alternativeへ移る。

市場は企業への重要なFeedback Mechanismである。

[
Product
\rightarrow
Market
\rightarrow
Selection
]

となる。

しかしMarket FeedbackだけではExternalityを十分に捉えられない。

Customerではない人への影響が価格に反映されない場合があるからである。

────────

Capital Market

Investorも企業へFeedbackを返す。

Growth Potential。

Regulatory Risk。

Environmental Risk。

Governance。

Capital Costが変化する。

[
Social/Business\ Outcome
\rightarrow
Capital\ Market
\rightarrow
Resource\ Allocation
]

となる。

社会的RiskがCapital Allocationを通じて企業行動へ戻ることがある。

────────

Insurance

Physical AIではInsuranceも重要なFeedback Nodeになる。

事故率。

Failure Rate。

Risk Exposure。

これらがPremiumやCoverageへ反映される。

[
Observed\ Risk
\rightarrow
Insurance\ Pricing
\rightarrow
Business\ Incentive
]

となる。

Insurance MarketがSafety改善へのEconomic Signalになる可能性がある。

────────

Standards

Industry StandardもFeedback Mechanismになる。

Interoperability。

Safety。

Data Format。

Cybersecurity。

事故や実装経験からBest Practiceが形成される。

[
Operational\ Experience
\rightarrow
Standard
\rightarrow
Industry
]

となる。

一社のLearningを産業全体へ広げる役割を持つ。

────────

ResearchへのFeedback

社会でUnexpected Outcomeが起きれば、それはResearch Questionになる。

人間はなぜAI Vehicleを信頼しないのか。

どのInterfaceならRobot Intentを理解しやすいのか。

AutomationはWorker Behaviorをどう変えるのか。

[
Social\ Reality
\rightarrow
Research\ Question
]

である。

社会実装がResearch Agendaを更新する。

────────

ProductへのFeedback

社会から得たEvidenceはProduct Designへ戻る。

VehicleのBehaviorを変える。

RobotのSpeedを変える。

Privacy Architectureを変更する。

Notificationを変える。

[
Social\ Feedback
\rightarrow
Product\ Update
]

となる。

企業に必要なのはFeedbackを受け取る窓口だけではない。

実際にDesignへ戻すEdgeである。

────────

Capital AllocationへのFeedback

社会的受容性が高いTechnologyへ投資を増やす。

Riskが高い領域へのDeploymentを遅らせる。

Safety Researchへ追加投資する。

Worker Trainingへ資源を配分する。

[
Social\ Outcome
\rightarrow
Capital\ Reallocation
]

となる。

第3章で見たFuture Allocation Systemが社会から修正される。

────────

Corporate StrategyへのFeedback

最初の企業Strategyが正しいとは限らない。

Autonomyを最大化する方針だった。

しかし社会ではHuman Assistance型の方が受容される。

完全自動化ではなくCollaborative Automationへ変える。

[
Strategy_t
\rightarrow
Social\ Reality
\rightarrow
Strategy_{t+1}
]

となる。

社会が企業Strategyを学習させる。

────────

Negative Externality

TechnologyのBenefitが企業に帰属し、Costが社会へ外部化されることがある。

Pollution。

Traffic。

Water Consumption。

Privacy Loss。

Worker Burden。

[
Private\ Benefit
+
Social\ Cost
]

を分けて観測する必要がある。

社会的Feedbackが弱ければExternalityは修正されにくい。

────────

Positive Externality

逆に企業だけでは回収できないBenefitもある。

Reduced Accidents。

Better Accessibility。

Cleaner Air。

Infrastructure Resilience。

Scientific Knowledge。

[
Private\ Return
<
Social\ Return
]

となる場合がある。

ここではPublic InvestmentやPolicy Supportが必要になることもある。

Social Feedbackは、Private Marketだけでは過小投資になる領域を示す。

────────

Public Capital

社会的Benefitが大きいTechnologyへ、

Research Grant。

Subsidy。

Infrastructure Investment。

Public Procurement。

を配分する。

[
Social\ Value
\rightarrow
Public\ Capital
\rightarrow
Capability
]

となる。

第3章で見たPublic CapitalがSocial Feedback Loopへ入る。

────────

DemocracyとTechnology

公共空間へ深く影響するTechnologyでは、企業の経営判断だけでは決定できない問題がある。

どの程度監視を許容するのか。

公共道路を誰に優先配分するのか。

Automation Benefitをどう社会へ分配するのか。

これらにはPublic Deliberationが必要になる。

[
Technology\ Governance
\rightarrow
Collective\ Choice
]

である。

────────

Majorityだけではない

しかし民主的Feedbackを単純な多数決だけで捉えることも危険である。

少数者に重大なHarmが集中する可能性がある。

したがって、

[
Majority\ Preference
+
Minority\ Protection
]

を同時に見る必要がある。

Social FeedbackにはRightsというConstraintも存在する。

────────

Rights as Constraint

Privacy。

Safety。

Equality。

Due Process。

Technology Optimizationより優先される権利がある。

したがって、

[
Optimization
\subset
Rights\ Boundary
]

という構造になる。

社会はObjective Functionだけでは記述できない。

Constraintも必要になる。

────────

Societyは一つのObjectiveを持たない

企業なら一定のStrategic Objectiveを持てる。

社会には多数のValueが存在する。

Efficiencyを重視する人。

Privacyを重視する人。

Accessibilityを重視する人。

Environmentを重視する人。

[ Society

Plural\ Objectives
]

である。

Social Feedback Loopは、そのPluralityを消すのではなく扱う必要がある。

────────

ConflictもFeedbackである

Stakeholder間で意見が一致しない。

これはSystem Failureではない。

社会には異なる利害がある。

重要なのはConflictを隠すことではなく、可視化してDecision Processへ入れることである。

[
Conflict
\rightarrow
Deliberation
\rightarrow
Governance
]

となる。

────────

Feedbackの速度差

Social FeedbackはMachine Feedbackより遅い。

Robot ControlはMillisecond。

Customer FeedbackはDayやMonth。

RegulationはMonthやYear。

文化的変化はさらに長い。

[
Machine\ Loop



Human\ Loop



Institutional\ Loop
]

という時間差がある。

Technology企業はこのTime Scaleの違いを理解する必要がある。

────────

Fast Technology, Slow Society

AI Technologyが急速に変化する。

制度や社会慣行はゆっくり変わる。

[
Technology\ Velocity



Institutional\ Velocity
]

となると、Gapが生まれる。

Ruleが追いつかない。

社会理解が追いつかない。

企業側もImpactを十分理解しない。

この速度差がSocial Riskを生む。

────────

Slow Loopをどう高速化するか

制度を単純に速くすればよいわけではない。

重要なのは、

Evidenceを速く収集する。

Stakeholderへ共有する。

限定実証する。

Ruleを更新する。

というLearning Cycleを改善することである。

[
Observe
\rightarrow
Deliberate
\rightarrow
Decide
\rightarrow
Measure
]

を効率化する。

────────

Social Observability

社会的Impactを学習するには観測可能性が必要になる。

Safety Incident。

Accessibility。

Worker Outcome。

Environmental Impact。

地域別Outcome。

しかしPrivacyを侵害しない範囲で測定する必要がある。

[
Observability
\leftrightarrow
Privacy
]

のBalanceが必要になる。

────────

Transparency

企業がSocial Feedbackを得るには、社会側もSystemについて一定の情報を持つ必要がある。

何を測っているか。

どのObjectiveで動いているか。

Incidentが起きたとき何をするか。

[
Transparency
\rightarrow
Informed\ Feedback
]

である。

情報がなければFeedbackも質を失う。

────────

Accountability

Feedbackを受け取っても、誰も責任を持たなければLoopは閉じない。

企業。

Operator。

Government。

Regulator。

役割を明確にする。

[
Feedback
\rightarrow
Responsible\ Actor
\rightarrow
Correction
]

となる。

AccountabilityはSocial LoopのActuatorに近い。

────────

Social Learning

同じTechnologyを複数地域で試す。

異なるOutcomeが出る。

何が違ったのかを比較する。

Best Practiceを共有する。

[
City_A
+
City_B
+
City_C
\rightarrow
Social\ Learning
]

となる。

社会もParallel Experimentから学べる。

────────

Local Context

ただし、一都市の成功を別都市へそのまま移せるとは限らない。

Population Density。

Transport Culture。

Law。

Climate。

Urban Form。

異なる。

したがって、

[
Global\ Knowledge
+
Local\ Adaptation
]

が必要になる。

社会実装もContext-dependentである。

────────

Social Feedback Dataを中央集約する必要はない

複数企業・自治体・市民が関わる社会Systemでは、すべてのDataを一社へ集約することは適切でない場合がある。

必要なInformationだけを共有する。

Standardを揃える。

各主体がControlを保持する。

[
Distributed\ Data
+
Shared\ Learning
]

というArchitectureが重要になる。

────────

Interoperability

Social SystemでもConnectionには共通Interfaceが必要になる。

VehicleとRoad。

UtilityとData Center。

CompanyとGovernment。

自治体間。

共通StandardがなければFeedbackは断片化する。

[
Interoperability
\rightarrow
Social\ Learning\ Velocity
]

となる。

────────

Social FeedbackのBottleneck

社会的Feedbackが存在していても、企業へ届かなければ意味がない。

住民が問題を報告している。

しかしProduct Teamへ届かない。

事故Dataがある。

しかしResearchへ戻らない。

WorkerのFeedbackがある。

しかしManagement Decisionへ反映されない。

この場合、

[ Feedback\ Exists + Missing\ Edge

No\ Learning
]

である。

ここでも核心はConnectionになる。

────────

Social Feedback Loop

Social Feedback Loopを最小化すると、

[
\boxed{
Deploy
\rightarrow
Society
\rightarrow
Observe
\rightarrow
Evaluate
\rightarrow
Govern
\rightarrow
Redesign
\rightarrow
Deploy
}
]

となる。

Technologyを社会へ入れる。

Outcomeを観測する。

BenefitとHarmを評価する。

Rule、Product、Capital Allocationを更新する。

再び実装する。

社会も一度のDecisionで完成するのではなく、Evidenceから学習する。

────────

Physical FeedbackとSocial Feedback

第5章で閉じたのはPhysical Feedback Loopだった。

[
Machine
\rightarrow
Reality
\rightarrow
Data
\rightarrow
Machine
]

第6章では、そこへ人間と制度が加わる。

[
Technology
\rightarrow
Society
\rightarrow
Feedback
\rightarrow
Technology
]

両者を統合すると、

[ \boxed{ Physical\ Feedback + Human\ Feedback + Institutional\ Feedback

Social\ Learning
}
]

となる。

────────

社会は企業の外部ではない

企業分析ではSocietyを「外部環境」と呼ぶことがある。

しかしMobility、Energy、AI Infrastructure、Physical AIが社会へ深く入るほど、その区別は弱くなる。

社会の反応が、

Demand。

Regulation。

Talent。

Capital。

Technology Design。

へ戻るからである。

[
Society
\rightarrow
Enterprise
]

というFeedbackが常に存在する。

社会は企業の外部条件であるだけでなく、企業を学習させるFeedback Sourceでもある。

────────

Social Feedback Loopという競争力

社会からのFeedbackを早く、正確に、偏りなく受け取り、企業行動へ戻せる企業は強い。

問題が起きたら隠すのではなく測る。

Human Experienceを観測する。

制度変化を読む。

Capital Allocationを更新する。

[
Social\ Signal
\rightarrow
Enterprise\ Learning
]

へ変換する。

このCapabilityはTechnology Performanceだけでは測れない。

────────

最強企業から社会学習Systemへ

ここまで進むと、本書の「最強企業」という問いはさらに変わる。

一社で最も多くのAssetを持つ企業か。

最も高度なAIを持つ企業か。

それだけではない。

AIをRealityへ実装し、

Physical Feedbackを受け、

Human Feedbackを受け、

Social Feedbackを受け、

自らを書き換えられる企業。

[
\boxed{
Enterprise
\leftrightarrow
Society
}
]

のLoopを持つ企業が重要になる。

────────

Social Feedback Loop

本節の核心は単純である。

社会はTechnologyの受け手ではない。

社会は応答する。

利用する。

拒否する。

Ruleを変える。

Capitalの流れを変える。

新しいResearch Questionを生む。

[ \boxed{ Society

Active\ Feedback\ System
}
]

である。

AIが社会へ入るほど、企業は社会を一方向に「最適化する」のではなく、社会からCorrectionを受ける必要がある。

そしてPhysical AI、Mobility、物流、都市、Human Feedback、Social Feedbackまで接続すると、企業の境界はさらに曖昧になる。

次節では第6章全体を統合し、

企業から社会システムへ

という転換を読む。

企業がProductを提供する主体から、Mobility、Energy、Logistics、Urban Infrastructureと相互依存する社会Systemの一Nodeへ変わる構造を明らかにする。
第7節　企業から社会システムへ

企業は、どこまで企業なのか。

Productをつくる。

Serviceを提供する。

Customerへ価値を届ける。

Revenueを得る。

この範囲だけを見れば、企業は市場の中に存在する一つの経済主体である。

しかし第6章で見てきたMobility、物流、都市、Human Feedback、Social Feedbackを接続すると、企業の境界はそれほど単純ではなくなる。

AI CompanyがMobilityへ入る。

Mobility Companyが道路や都市Infrastructureへ接続される。

物流企業が地域社会とEnergy Systemへ接続される。

Data CenterがGridとWaterへ接続される。

RobotがWorkerやPublic Spaceへ入る。

このとき、

[
\boxed{
Company
\rightarrow
Infrastructure
\rightarrow
Society
}
]

となる。

企業は社会の外側からProductを供給する存在ではなく、社会System内部で他のNodeと相互依存する主体になる。

────────

企業境界は法的境界だけではない

株式会社としての境界は明確である。

Ownership。

Contract。

Employee。

Asset。

しかしCapabilityの境界はもっと広い。

Cloud ProviderはUtilityに依存する。

AI CompanyはSemiconductor Companyに依存する。

Automotive CompanyはRoad、Energy、Regulationに依存する。

物流企業はPort、Warehouse、Worker、都市Infrastructureに依存する。

したがって、

[
Legal\ Boundary
\neq
Operational\ Boundary
]

である。

企業を理解するには、法人内部だけでなく、実際にCapabilityを成立させている外部Connectionを見る必要がある。

────────

Company as Node

この視点から企業は、

[ \boxed{ Company

Node\ in\ a\ Larger\ System
}
]

として読める。

一社がすべてを支配しているわけではない。

Technologyを提供する企業。

Energyを提供する企業。

Capitalを提供するInvestor。

制度を設計するGovernment。

Infrastructureを運営するUtility。

利用するCitizen。

それぞれが異なるCapabilityを持つ。

企業の強さは、そのNetworkの中でどの位置を占め、どのConnectionを形成できるかによって変わる。

────────

ProductからSystemへ

企業がPhysical Realityへ深く入るほど、Product単体では価値を完結しにくくなる。

EVだけではElectric Mobilityは成立しない。

Charging Infrastructureが必要になる。

Autonomous VehicleだけではMobility Systemは成立しない。

Road、Map、Fleet Operation、Regulationが必要になる。

RobotだけではFactory Automationは成立しない。

Process、Worker、Safety、Softwareが必要になる。

したがって、

[
Product
\rightarrow
System
]

への転換が起こる。

企業は単体Productではなく、複数Nodeを接続したSystem Capabilityを設計する必要がある。

────────

Platformより広いもの

この構造はPlatform Economyにも似ている。

しかしPhysical RealityではPlatformよりさらに広い。

Software PlatformならAPIやMarketplaceで接続できる。

Physical Systemでは、

土地。

Electricity。

Machine。

Vehicle。

Worker。

Law。

Safety。

を扱う必要がある。

[
Digital\ Platform
\rightarrow
Physical\ System\ Architecture
]

へ広がる。

接続CostもFailure Costも大きい。

────────

社会Infrastructureへ近づく企業

一部の企業Serviceは社会Infrastructureに近づく。

Cloud。

Payment。

Logistics。

Mobility。

Communication。

AI。

これらが停止すると、多数の企業や人間の活動へ影響する。

すると企業には、

[
Commercial\ Service
+
Infrastructure\ Responsibility
]

という二重性が生まれる。

高いAvailability。

Security。

Resilience。

Governance。

が必要になる。

────────

Scaleが責任を変える

小さなProductでは、一つのFailureの影響範囲も小さい。

しかしServiceが社会Scaleへ達すると、同じFailureでもSystemic Impactを持つ。

[
Scale
\uparrow
\Rightarrow
Responsibility
\uparrow
]

である。

企業競争力をGrowthだけで測ることはできなくなる。

ReliabilityとResilienceが同時に重要になる。

────────

Amazon型の社会接続

Commerce、Cloud、Logisticsを持つ企業では、Digital DemandとPhysical Distributionが社会へ深く接続される。

CustomerがOrderする。

Warehouseが動く。

Truckが走る。

Workerが作業する。

地域道路が使われる。

Data CenterがElectricityを使う。

一つの企業活動が複数の社会Systemへ波及する。

[
Company\ Operation
\rightarrow
Social\ Infrastructure
]

である。

企業内部のOptimizationが社会全体ではExternalityを生む可能性もある。

────────

Toyota型の社会接続

Mobility企業も同様である。

Vehicleを売るだけなら企業とCustomerの関係に見える。

しかしVehicleが大量に走れば、

Road。

Traffic。

Energy。

Parking。

Safety。

Environment。

Urban Form。

へ影響する。

[
Vehicle
\rightarrow
City
]

となる。

Mobility Companyは都市Systemから独立できない。

────────

Microsoft・Google型の社会接続

Digital企業もPhysical Realityから離れているわけではない。

Cloud Data Center。

Electricity。

Semiconductor。

Enterprise System。

Public Sector。

AIが社会Infrastructureへ広がるほど、

[
Digital\ Company
\rightarrow
Physical/Social\ Infrastructure
]

となる。

Software企業も、結果的にはEnergy、Industry、Governmentと深く接続される。

────────

NVIDIA型の社会接続

AI Compute Providerは直接都市を運営しなくても、他企業がPhysical AIを実装する基盤を提供する。

Robot。

Factory。

Vehicle。

Healthcare。

Scientific Computing。

一つのCompute Platformが複数のPhysical Domainへ波及する。

[
Enabling\ Technology
\rightarrow
Many\ Social\ Systems
]

となる。

Enabler企業の社会的影響は、自社Productの直接利用だけでは測れない。

────────

社会から企業へ戻る

重要なのは矢印が一方向ではないことである。

企業が社会へ影響する。

社会も企業へ影響する。

Regulation。

Customer Demand。

Worker Choice。

Community Reaction。

Capital Market。

Public Opinion。

[
Company
\leftrightarrow
Society
]

である。

企業は社会を変えるだけでなく、社会によって継続的に修正される。

────────

Social FeedbackがStrategyを変える

新Technologyを導入する。

社会が反応する。

予想外の問題が起きる。

企業がProductを変更する。

Investmentを変更する。

Deployment Speedを変更する。

[
Strategy_t
\rightarrow
Society
\rightarrow
Strategy_{t+1}
]

となる。

企業StrategyもClosed PlanではなくFeedback Systemになる。

────────

Regulationが企業Architectureへ入る

AIやAutonomous Mobilityでは、Regulationを製品完成後に対応する外部要件として扱うことが難しい。

Data Governance。

Safety。

Audit。

Human Oversight。

これらを初期Architectureから組み込む必要がある。

[
Regulation
\rightarrow
System\ Design
]

となる。

Legal LayerとTechnical Layerが接続する。

────────

InsuranceもSystemへ入る

Physical AIではRisk Financingも重要になる。

事故Risk。

Equipment Failure。

Liability。

Insurance PriceがBusiness Modelへ影響する。

[
Physical\ Risk
\rightarrow
Insurance
\rightarrow
Business\ Economics
]

となる。

社会制度が企業Economicsの一部になる。

────────

Public Procurement

GovernmentはRegulatorだけではない。

Customerにもなる。

Transport。

Healthcare。

Defense。

Infrastructure。

Public Procurementによって新TechnologyのInitial Marketを形成することがある。

[
Public\ Demand
\rightarrow
Corporate\ Capability
]

となる。

国家・自治体は企業Systemの外部にいるだけではない。

Demand Nodeでもある。

────────

Public Capital

さらにPublic Capitalが入る。

Research Funding。

Infrastructure Investment。

Semiconductor Incentive。

Energy Subsidy。

企業Capabilityの形成へ直接影響する。

[
Public\ Capital
+
Private\ Capital
\rightarrow
Industrial\ Capability
]

となる。

企業と国家の境界はOwnershipとしては明確でも、Capability Formationでは深く接続される。

────────

University

Universityも社会Systemの重要Nodeである。

Talentを育てる。

Researchを行う。

Startupを生む。

企業と共同研究する。

都市で実証する。

[
University
\leftrightarrow
Company
\leftrightarrow
Society
]

という循環になる。

企業だけを分析してもInnovation System全体は見えない。

────────

Citizen

最も忘れてはならないNodeがCitizenである。

Consumer。

Worker。

Resident。

Driver。

Patient。

Taxpayer。

同じ一人の人間が複数Roleを持つ。

企業にとってCustomerでも、自治体にとってCitizenでもある。

したがって、

[
Human
\neq
Customer\ Only
]

である。

社会Systemでは人間を市場上のUserだけとして扱えない。

────────

一人のOptimizationと社会全体

Personalized AIが一人ひとりを最適化する。

しかし各個人のOptimizationを合計しても社会最適になるとは限らない。

全員が最速Routeを選ぶ。

全員が同時刻にChargeする。

全員が同じRecommendationに従う。

[
Individual\ Optimization
\neq
Collective\ Optimization
]

である。

社会SystemにはCoordinationが必要になる。

────────

Collective Outcome

企業はCustomer-level Outcomeだけでなく、Collective Outcomeを見る必要がある場合がある。

Congestion。

Energy Peak。

Public Safety。

Environmental Impact。

Employment Structure。

[
Individual\ Actions
\rightarrow
Collective\ Outcome
]

となる。

AIが多くの個人Decisionを支援するほど、このAggregate Effectが重要になる。

────────

Externalityを内部へ戻す

企業が生むCostが市場価格に入っていなければ、企業内部のOptimizationだけでは修正されない。

Pollution。

Congestion。

Water Use。

Privacy Risk。

そこでRegulation、Tax、Standard、Social PressureなどがFeedbackを返す。

[
Externality
\rightarrow
Social\ Feedback
\rightarrow
Enterprise\ Decision
]

となる。

Social Feedback LoopはExternalityを企業Decisionへ戻す仕組みでもある。

────────

Shared Resource

道路。

Grid。

Water。

Spectrum。

Public Space。

社会には共有Resourceがある。

企業がScaleすれば、その利用量も増える。

[
Corporate\ Scale
\rightarrow
Shared\ Resource\ Demand
]

となる。

そのためScale StrategyとPublic Resource Strategyを分離できなくなる場合がある。

────────

Coordinationという企業能力

ここで企業に新しいCapabilityが必要になる。

政府と交渉する。

UtilityとPlanningする。

Communityと対話する。

SupplierとDataを共有する。

UniversityとResearchする。

[
\boxed{
Coordination\ Capability
}
]

である。

Technology Capabilityだけでなく、異なる主体を接続する能力が競争力になる。

────────

Orchestration

さらに一段進むと、企業はすべてを所有せずともSystemをOrchestrateできる。

AIはPartner。

EnergyはUtility。

FactoryはSupplier。

FinanceはExternal Capital。

Governmentは制度。

それでも必要なCapabilityを組み合わせられる。

[
Ownership
\rightarrow
Orchestration
]

という転換である。

────────

Orchestratorは支配者ではない

ただしOrchestrationは中央支配を意味しない。

各企業。

自治体。

Citizen。

独立した主体が存在する。

必要な部分だけ接続する。

[
Autonomy
+
Coordination
]

を両立する。

社会Systemは一企業のEnterprise Architectureではない。

Distributed Governanceが必要になる。

────────

Data Sharing

社会Systemを学習させるにはDataの共有が必要になる場合がある。

しかしすべてのDataを中央集約する必要はない。

必要なInformationだけ共有する。

共通Standardを使う。

Privacyを守る。

[
Distributed\ Data
+
Interoperability
\rightarrow
Shared\ Learning
]

である。

────────

Trust Infrastructure

企業間・Public–Private間のConnectionにはTrustが必要になる。

Dataを正しく扱うか。

Contractを守るか。

Cybersecurityは十分か。

事故時に責任を持つか。

[ Connection \times Trust

Usable\ Connection
]

である。

Edgeが存在してもTrustがなければ実質的には弱い。

────────

StandardというEdge

共通Standardは企業間Connectionを低Cost化する。

Data Format。

Communication Protocol。

Safety Requirement。

Identity。

API。

[
Standard
\rightarrow
Lower\ Connection\ Cost
]

となる。

産業や社会のFeedback Loopを高速化する重要なInfrastructureである。

────────

Feedback Velocity

社会SystemにもLearning Velocityがある。

Technologyを実装する。

Outcomeを測る。

問題を発見する。

企業が修正する。

制度が修正される。

再実装する。

[ \boxed{ Social\ Learning\ Velocity

\frac{Validated\ Social\ Improvement}{Time}
}
]

と概念的に表現できる。

────────

速すぎても危険である

しかし社会SystemはSoftwareのように毎日書き換えればよいわけではない。

人間の生活。

Law。

Infrastructure。

企業投資。

長い時間を持つ。

したがって、

[
Speed
+
Stability
]

の両方が必要になる。

社会には予測可能性そのものにも価値がある。

────────

Slow Loopの意味

社会制度のLoopが遅いことは、単純な欠点ではない。

重大Decisionを慎重に検討する。

Stakeholderの意見を聞く。

Rightsを守る。

こうした機能もある。

したがって目標は、

[
Maximum\ Speed
]

ではなく、

[
Appropriate\ Feedback\ Speed
]

である。

────────

Resilience

企業から社会Systemへ視野を広げると、Efficiencyだけでは不十分になる。

一社が停止しても社会が動くか。

一つのSupply Routeが止まっても代替できるか。

一つのCloudが停止してもCritical Serviceを維持できるか。

[
System\ Resilience
]

が必要になる。

RedundancyとDiversityにも価値が生まれる。

────────

CompetitionとResilience

一社への極端な集中はEfficiencyを高める可能性がある。

しかしSystemic Riskも増える。

[
Concentration
\rightarrow
Efficiency
+
Systemic\ Risk
]

である。

社会Scaleでは企業競争政策やInteroperabilityもInfrastructure Resilienceの一部として見えてくる。

────────

CompetitionもLearningを生む

一方、複数企業が異なるApproachを試すことは社会全体の探索能力になる。

[
Company_A
\quad
Company_B
\quad
Company_C
]

が異なるTechnologyを試す。

MarketとSocietyが結果を比較する。

[
Competition
\rightarrow
Parallel\ Experiments
\rightarrow
Selection
]

となる。

Competitionは単なる勝敗ではなくDistributed Learning Mechanismでもある。

────────

Cooperationも必要になる

しかしCritical Infrastructureでは共同作業も必要になる。

Cybersecurity Standard。

Charging Standard。

Safety Data。

Disaster Response。

Supply Chain Resilience。

[
Competition
+
Cooperation
]

が同時に存在する。

企業は競争しながら、Systemを成立させる部分では協働する。

────────

Company as Learning Node

この構造から企業を再定義できる。

企業は完成したCapabilityを社会へ提供するだけではない。

社会からSignalを受け取る。

Technologyを更新する。

Resource Allocationを変える。

再び社会へ実装する。

[
\boxed{
Society
\rightarrow
Company
\rightarrow
Society
}
]

企業は社会Learning Systemの一Nodeになる。

────────

Society as Learning Environment

逆に社会も企業の「市場」だけではない。

Reality Dataを返す。

Human Feedbackを返す。

Institutional Feedbackを返す。

Research Questionを生む。

[
Society
\rightarrow
Knowledge
]

となる。

社会は企業にとって最終的なVerification EnvironmentでありLearning Environmentでもある。

────────

企業から社会システムへ

第6章の流れを一つにすると、

Autonomous Mobilityが道路へ出る。

物流がPhysical Flowを接続する。

都市が複数Systemを重ねる。

Human FeedbackがExperienceを返す。

Social Feedbackが制度と企業を修正する。

[
\boxed{
AI
\rightarrow
Mobility
\rightarrow
Logistics
\rightarrow
City
\rightarrow
Human
\rightarrow
Society
\rightarrow
Feedback
}
]

となる。

ここまで来ると、企業分析は企業内部では終わらない。

────────

社会システムの中の40社

本書が扱う40社も、それぞれ孤立した巨大企業ではない。

Researchを担う企業。

AIを担う企業。

Semiconductorを担う企業。

Capitalを持つ企業。

Energyを担う企業。

Industrial Realityを持つ企業。

Mobilityを持つ企業。

Scienceへ接続する企業。

それぞれが異なるLayerを持つ。

[ \boxed{ 40\ Companies

40\ Independent\ Firms
+
One\ Interdependent\ Industrial\ Network
}
]

として読む必要がある。

────────

競争と接続

もちろん40社は競争している。

Market Share。

Talent。

Capital。

Technology。

Customer。

しかし同時に相互依存している。

NVIDIAにはFoundryが必要である。

FoundryにはEquipmentが必要である。

CloudにはEnergyが必要である。

MobilityにはSemiconductorとAIが必要である。

ScienceにはComputeとPhysical Experimentが必要になる。

[
Competition
\land
Interdependence
]

が2026年の産業構造の特徴である。

────────

社会SystemからScienceへ

そしてここまでで、AIは社会へ到達した。

だがもう一つ、巨大な領域が残っている。

Scienceである。

AIが既存Productを最適化するだけでなく、

新しいDrugを発見する。

新Materialを探索する。

Biologyを理解する。

Experimentを設計する。

Scientific Discoveryそのものを高速化する。

ここでは企業が社会SystemのNodeであるだけでなく、Knowledge Generation SystemのNodeになる。

────────

第Ⅲ部が示したもの

第Ⅲ部では、

AIをDigitalからPhysicalへ移した。

Factoryへ入れた。

Robotへ入れた。

Roadへ出した。

物流へ広げた。

都市へ接続した。

人間と社会からFeedbackを受け取った。

その結果、

[
\boxed{
AI
\rightarrow
Physical\ Reality
\rightarrow
Society
\rightarrow
Feedback
\rightarrow
AI
}
]

というLoopが成立した。

AIは社会を一方的に変えるTechnologyではない。

社会から継続的にCorrectionを受けるTechnologyである。

────────

企業から社会システムへ

本節の最小構造は、

[
\boxed{
Firm
\rightarrow
Network
\rightarrow
Infrastructure
\rightarrow
Society
\rightarrow
Feedback
\rightarrow
Firm
}
]

である。

強い企業とは、社会から独立して巨大化する企業ではない。

自らのCapabilityを社会Systemへ接続し、その結果を社会から学習し、再び自らを更新できる企業である。

そして次に見るScienceでは、このFeedback Loopがさらに深くなる。

Realityを観測する。

Hypothesisを立てる。

Experimentする。

結果を測る。

Knowledgeを更新する。

企業のLearning LoopとScienceのMethodは、驚くほど近い構造を持つ。

ここから本書は第Ⅳ部 Science へ進む。

AIが社会を動かす段階から、AIが発見そのものを変える段階へ移る。