第1冊『株式会社EQUES』――松尾研発AIスタートアップは、研究・製薬・エネルギー・量子・フィジカルAIをどう社会実装するのか（第5回）（第Ⅳ部 Physical & Computational Frontier 第4章 エネルギー・フィジカルAI・量子――AIはソフトウェアの外へ出る）
第Ⅳ部 Physical & Computational Frontier
――AIはソフトウェアの外へ出る
第Ⅲ部で見た製薬AIでは、EQUESの人工知能は主として情報の世界を扱っていた。
Documentを読む。
Knowledgeを検索する。
文章を生成する。
複数の記録を比較する。
専門領域に適応したModelを構築する。
Benchmarkによって性能を測定する。
そしてHumanが確認し、企業のWorkflowへ組み込む。
そこでは、
Domain → Data → Model → Evaluation → Application → Human
という高信頼AIの構造が形成されていた。
しかし、AIの社会実装はDigital Informationの内部だけでは終わらない。
社会を構成しているのは、発電設備、道路、工場、建築物、Machine、Robot、SensorといったPhysical Systemでもある。
EQUESの事業領域を製薬からEnergy、原子力、Physical AIへ広げて見ると、AIが次の境界を越え始めていることが分かる。
Digital AI → Physical AI
である。
⸻
情報を生成するAIから、現場を認識するAIへ
LLMはLanguageを扱う。
しかしPhysical EnvironmentではLanguageだけでは足りない。
CameraからImageが入る。
SensorからMeasurement Dataが入る。
RobotからPositionやStateが入る。
3D Environmentが変化する。
Machineが動く。
Humanが遠隔から操作する。
AIはこれらを統合しながら、Physical WorldのStateを認識しなければならない。
つまりInputが、
Text
から、
Image / Video / Sensor / Spatial Data
へ拡張する。
AIは文章の意味を理解するだけでなく、現実空間の状態を推定する必要が生じる。
⸻
Energy Infrastructureという現場
Energyは社会を動かす基盤である。
電力設備が停止すれば、企業活動だけでなく生活そのものへ影響する。
一方、日本のInfrastructureは設備の老朽化、保守人材の不足、技能継承など複数の課題を抱える。
こうした環境では、
Inspection。
Monitoring。
Anomaly Detection。
Maintenance。
Remote Operation。
Automation。
へのAI活用が考えられる。
ただしEnergy Infrastructureでは、一般的なWeb ServiceとはFailure Costが異なる。
AIが間違ったRecommendationを出しても、画面をReloadすれば済むとは限らない。
したがって、
AI Capability
と同時に、
Safety / Reliability
が中心Requirementになる。
⸻
原子力という極端な条件
その要求がさらに明確になるのが原子力である。
原子力施設、とりわけ廃炉のような環境では、人間が容易に立ち入れない場所が存在する。
放射線。
複雑な構造物。
不確実なEnvironment。
通信条件。
遠隔操作。
Machine Failure。
通常のFactory Automationとは異なる条件が重なる。
ここでRobotを利用する理由は、単なるLabor Savingではない。
Humanが安全に作業できない場所へMachineを送り込む
ことにある。
AIとRoboticsの社会的価値が最も明確になる領域の一つである。
⸻
Remote RoboticsからPhysical AIへ
従来のRemote Robotでは、Human OperatorがCamera Imageなどを見ながらMachineを操作する。
これは重要なTechnologyであり、AIがなくても成立する。
しかしEnvironmentが複雑になるほど、Humanだけですべてを認識し操作する負荷は大きくなる。
そこでAIが、
Object Recognition。
Environment Understanding。
Position Estimation。
Operation Support。
Planning。
Anomaly Detection。
などを支援する可能性が生まれる。
構造は、
Human → Robot
から、
Human ⇄ AI ⇄ Robot ⇄ Environment
へ変化する。
これがPhysical AIを考える基本形になる。
⸻
Physical AIではErrorが物理化する
Software AIとPhysical AIの最大の違いの一つは、Outputが現実世界へ作用することである。
文章生成AIが誤れば、誤った文章が表示される。
Robot AIが誤れば、Machineが誤った方向へ動く可能性がある。
つまり、
Digital Error → Physical Consequence
となる。
そのためPhysical AIでは、
Perception Accuracy。
Control Stability。
Latency。
Fail-safe。
Human Override。
Redundancy。
Logging。
Simulation。
などが重要になる。
高性能ModelだけではSystem Safetyを保証できない。
⸻
製薬AIとの共通性
一見すると、製薬Document AIと原子力Robotはまったく異なる。
しかしSystem Architectureの抽象度を上げると共通点がある。
製薬では、
Dataを取得する。
AIが処理する。
Outputを評価する。
Humanが確認する。
記録を残す。
Physical AIでも、
Sensor Dataを取得する。
AIがEnvironmentを認識する。
Action候補を生成する。
HumanまたはSafety Systemが確認する。
Robotが実行する。
結果を記録する。
つまり双方とも、
Observe → Analyze → Decide → Verify → Act → Record
という高信頼Processとして読むことができる。
⸻
Explainabilityが必要になる理由
高信頼AIでは、AIが「正しい答えを出した」だけでは十分でない場合がある。
なぜその判断になったのか。
どのDataが重要だったのか。
どの部分をAIが認識したのか。
どの程度確信しているのか。
どの条件では判断できないのか。
これらをHumanが理解できることが重要になる。
ここでExplainable AI――XAI――が関係する。
ただし、Explainabilityを「AIの内部を完全に説明するTechnology」と考えるべきではない。
実務では、
HumanがAI Outputを検証し、適切なActionを選択するために必要な情報を提供する
ことが重要になる。
⸻
SensorはAIの目と耳になる
Physical AIでは、ModelだけでなくSensorが重要になる。
Camera。
Depth Sensor。
LiDAR。
Temperature Sensor。
Pressure Sensor。
Radiation Measurement。
Position Sensor。
Machine State。
AIがRealityを直接見るわけではない。
SensorによってDigital Dataへ変換されたPhysical Environmentを認識する。
したがって、
Environment → Sensor → Data → AI
という変換が存在する。
Sensorが誤ればAIも誤る。
Calibrationが崩れれば、Modelが高性能でも正しい判断はできない。
Physical AIではInput LayerそのものがEngineeringの対象になる。
⸻
Edge Computing
RobotやIndustrial Equipmentでは、すべてのDataをCloudへ送って処理すればよいとは限らない。
通信が切れる。
Latencyが大きい。
Bandwidthが不足する。
機密Dataを外部へ送れない。
即時判断が必要になる。
そこで、
Cloud AI
だけでなく、
Edge AI
が重要になる。
Robotや現場Computerの近くでInferenceする。
必要な情報だけをCloudへ送る。
Cloudではより大きなModelや長期Data Analysisを行う。
すると、
Edge ⇄ Cloud
というDistributed Architectureになる。
⸻
Simulationという安全装置
Physical AIでは、実世界で何度もFailureを試すことはできない。
そこでSimulationの価値が高くなる。
Digital Environmentを作る。
Robotの動作を再現する。
AIの判断を試す。
Failure Conditionを作る。
Human OperatorのTrainingにも使う。
つまり、
Real Environment
だけでなく、
Simulated Environment
を持つ。
Physical AIのLearningとValidationでは、この二つを接続することが重要になる。
⸻
Digital Twinへの接続
Sensor DataによってPhysical AssetのStateをDigital側へ反映し、SimulationやAnalysisと組み合わせれば、Digital Twinの方向へ進む。
Physical Equipment。
Sensor。
Digital Representation。
AI。
Simulation。
Maintenance。
を接続する。
ただし、本書ではEQUESが現在実装している事実と、Technology Architectureとして将来接続可能な領域を区別する。
Digital Twinという言葉だけで、実装済みの機能を過大に描いてはならない。
EQUESの現在地と、そのTechnologyから論理的に導ける将来Architectureを分けて記述する。
⸻
もう一つのFrontier――計算そのもの
第Ⅳ部にはPhysical AIだけでなく、もう一つの軸がある。
Computational Frontier
である。
AIが解こうとするIndustrial Problemには、LanguageやPerceptionだけではなくOptimizationが含まれる。
大量の組合せから良いSolutionを探す。
Scheduleを最適化する。
Resource Allocationを改善する。
複雑なConstraintの中から解を求める。
ここではMachine Learningだけでなく、
Mathematical Optimization。
Combinatorial Optimization。
Classical Computing。
そしてQuantum Computing。
といった計算技術が関係する。
⸻
AIとOptimizationは同じではない
AIという言葉ですべてを包む必要はない。
Problemによっては、LLMより数理最適化の方が適している。
Deep LearningよりTraditional Algorithmが適している場合もある。
Rule-based Systemが最も安全な場合もある。
重要なのは、
AIを使うこと
ではなく、
Problemに最適なComputational Methodを選ぶこと
である。
これはEQUESのような研究開発型企業を見るうえで重要な視点になる。
⸻
Quantum Computingを誇張しない
Quantum Computingは大きな将来性を持つ研究領域である一方、現在のClassical Computingを全面的に置き換えているTechnologyではない。
したがって、
「QuantumによってすべてのOptimization Problemが解決する」
という描き方は避ける必要がある。
重要なのは、
どのProblemがQuantum Algorithmと相性を持つのか。
現在のHardwareで何が可能なのか。
Classical Algorithmとどう比較するのか。
Hybrid Architectureが有効なのか。
を検証することである。
つまり、
Expectation
ではなく、
Engineering Evaluation
として扱う。
⸻
ClassicalとQuantumを対立させない
将来のComputing Architectureは、
ClassicalかQuantumか、
という単純な二択にはならない可能性が高い。
CPU。
GPU。
Edge Device。
Specialized Accelerator。
Quantum Processor。
それぞれが得意な計算を担う。
構造としては、
Heterogeneous Computing
である。
AI System側から見れば、Problemに応じて最適なCompute ResourceへTaskを割り当てることが重要になる。
⸻
Physical FrontierとComputational Frontierは接続する
Physical AIとAdvanced Computingは別々の領域に見える。
しかし最終的には接続する。
RobotがEnvironmentを認識する。
大量のSensor Dataを処理する。
ActionをPlanningする。
RouteをOptimizationする。
Simulationを実行する。
安全条件を満たすSolutionを探索する。
つまりPhysical Intelligenceの高度化は、Computational Capabilityにも依存する。
Physical World × Computation
という接続である。
⸻
高信頼AIの要求はさらに厳しくなる
製薬AIでは、AI OutputをHumanがReviewしてからDocumentを確定できる。
Physical AIでは、Milliseconds単位の判断が必要になる場合がある。
Humanが毎回確認できない。
すると、
Human Approval。
Automatic Safety Control。
Fail-safe。
Emergency Stop。
Rule-based Constraint。
などを用途ごとに配置しなければならない。
Human-in-the-loopだけではなく、
Human-on-the-loop
や、
Human-in-command
といった異なるSupervision Architectureが必要になる。
Automation Levelそのものを設計するのである。
⸻
Researchから社会Infrastructureへ
EQUESのOriginはAI研究にある。
しかしEnergy、原子力、Physical AIへ進むと、その研究は社会Infrastructureと直接接触する。
ここでは、
「新しいAlgorithmを作れたか」
だけでは成功を測れない。
安全に動くか。
現場で使えるか。
既存設備へ接続できるか。
Human Operatorが扱えるか。
長期間運用できるか。
FailureからRecoverできるか。
が問われる。
研究成果は、Engineering Systemへ変換されなければならない。
⸻
第Ⅳ部で見るもの
第Ⅳ部では、この境界を七つの方向から追う。
Energy AI。
原子力と高信頼AI。
福島第一原子力発電所の廃炉と遠隔作業。
Physical AI。
Explainable AIとAudit。
Quantum Computing。
そしてDigitalからPhysical Worldへの移行。
ここで問うのは、
「EQUESは何種類のTechnologyを扱っているか」
ではない。
製薬で形成した高信頼AIの能力を、より複雑なPhysical Environmentへ拡張できるのか。
ということである。
⸻
DigitalからPhysicalへ
第Ⅲ部までの構造は、
Knowledge
→ Model
→ Document
→ Human
だった。
第Ⅳ部では、
Environment
→ Sensor
→ AI
→ Human / Control System
→ Robot / Infrastructure
へ広がる。
そして計算側では、
Problem
→ Algorithm
→ Compute
→ Optimization
→ Action
が接続される。
両者を重ねると、
Physical Environment
⇄ Sensor
⇄ Data
⇄ AI / Optimization
⇄ Human
⇄ Machine
というIndustrial AI Systemが見えてくる。
⸻
製薬では、AIが品質を支える情報へ入った。
Energyでは、AIが社会を支えるInfrastructureへ入る。
原子力では、AIとRobotがHumanの立ち入りにくいEnvironmentへ入る。
Quantumでは、AIが利用する計算そのものの境界が拡張される。
EQUESの社会実装が次に向き合うのは、Screenの中だけでは完結しない世界である。
AIは、情報を処理するSoftwareから、現実世界を認識し、Humanと協調し、Machineを通じてPhysical Environmentへ関与するSystemへ変わり始める。
第Ⅳ部では、その境界を見ていく。
第4章 エネルギー・フィジカルAI・量子
――AIはソフトウェアの外へ出る
第1節 エネルギーAI
エネルギー産業は、AIにとって巨大な応用領域である。
発電する。
送る。
蓄える。
設備を監視する。
異常を発見する。
保守する。
将来の需要を予測する。
そして、社会Infrastructureとして長期間、安全かつ安定的に稼働させる。
ここには大量のDataと複雑なPhysical Systemが存在する。
一方、製薬AIと同じ方法をそのまま持ち込めるわけではない。
製薬で中心となったのはDocument、Knowledge、Languageだった。
Energyでは、
Equipment / Sensor / Time-series Data / Physical Environment
が前面に出る。
EQUESがEnergy領域へ事業を広げる意味は、この境界にある。
AIが情報処理Systemから、Physical Infrastructureを支えるTechnologyへ近づくのである。
⸻
エネルギーは止められない
Energy Infrastructureには特徴がある。
社会が常時利用していることである。
電力供給が止まれば、
家庭。
Hospital。
Factory。
Transportation。
Communication。
Data Center。
多くの社会機能へ影響する。
したがってEnergy AIの目的は、単純なAutomationではない。
Reliabilityを維持しながらProductivityを向上させること
にある。
AIによって効率化できても、System全体の安定性を損なえば意味がない。
⸻
Infrastructureの老朽化
日本では高度経済成長期以降に整備された多くのInfrastructureが長期運用段階へ入っている。
設備が長く使われるほど、
Inspection。
Maintenance。
Repair。
Replacement Planning。
の重要性が高まる。
すべての設備を一定周期で交換すれば安全性は高めやすいが、Costも大きい。
反対に、故障するまで使えばInfrastructure Riskが高まる。
そこで必要になるのが、
Condition-based Maintenance
という考え方である。
設備の状態を観測し、必要な時点でMaintenanceを行う。
AIはこの判断を支援する可能性を持つ。
⸻
Sensor Dataを読む
Physical Infrastructureでは、設備の状態がSensorを通じてDataになる。
温度。
圧力。
振動。
電流。
電圧。
音響。
画像。
位置。
その他のMeasurement。
これらは時間とともに変化する。
したがってEnergy AIでは、
Time-series Analysis
が重要になる。
通常状態を学習する。
変化を捉える。
異常Patternを検出する。
将来の状態を予測する。
構造としては、
Physical Equipment
→ Sensor
→ Data
→ AI
→ Maintenance Decision
となる。
⸻
異常検知
AIの代表的な応用の一つがAnomaly Detectionである。
通常時のData Patternを学習し、そこから大きく外れる状態を検出する。
ただし、Energy Infrastructureでは単純な分類問題では済まない。
本当に異常なのか。
Sensorの故障なのか。
一時的な変動なのか。
Operating Conditionが変わっただけなのか。
複数の可能性を区別しなければならない。
したがって、
Anomaly ≠ Failure
である。
AIは異常候補を提示し、その意味をHumanや他のSystemが評価する。
⸻
予兆検知
さらに一歩進むと、故障した後ではなく、その前に兆候を発見する。
Predictive Maintenance
である。
過去Data。
Current State。
Operating Condition。
Maintenance History。
これらを組み合わせ、
「このEquipmentは近い将来Failure Probabilityが高くなる」
と推定できれば、Maintenanceを計画的に行える。
しかしPredictionはProbabilityである。
未来を確定するものではない。
したがって、
Prediction → Risk Assessment → Human Decision
という構造が必要になる。
⸻
False AlarmというCost
異常検知AIが慎重すぎれば、大量のAlertを出す。
すべてのAlertをEngineerが確認しなければならないなら、AIが新しいWorkloadを生む。
逆にAlertを抑えすぎれば、重要な異常を見逃す。
ここでも、
False Positive ⇄ False Negative
のBalanceが重要になる。
製薬のQAI Checkerで見た問題と構造は同じである。
対象がDocumentからEquipmentへ変わっただけで、
Human Attentionをどこへ配分するか
という問題は残る。
⸻
AIはMaintenance Engineerを置き換えるのか
Energy AIをHuman Replacementとして考える必要はない。
現場Engineerには、
設備Knowledge。
過去のExperience。
音や振動への感覚。
現場Context。
Safety Knowledge。
が蓄積されている。
AIは大量Dataを継続監視することには強い。
Humanは例外的状況やContextを含む判断に強い。
したがって、
Machine Monitoring + Human Expertise
というComplementary Relationshipを作る方が現実的である。
⸻
熟練者不足という問題
Infrastructure Industryでは、設備だけでなくHuman側の高齢化や人材不足も重要な課題になる。
熟練者が退職すれば、長年蓄積されたTacit Knowledgeが失われる可能性がある。
ここでAIには二つの役割が考えられる。
一つは、Humanが行ってきたMonitoringの一部を自動化すること。
もう一つは、
Expert KnowledgeをDigital Knowledgeへ変換すること
である。
Inspection Record。
Maintenance Report。
Manual。
Failure History。
熟練者へのInterview。
こうしたKnowledgeをAIが検索・利用できるようにすれば、Knowledge Transferを支援できる。
ここでは再びLLMが関係してくる。
⸻
LLMとSensor AIを接続する
Energy AIをSensor Analysisだけに限定する必要はない。
例えばAIがSensorから異常候補を検出する。
そのEquipmentに関連するManualを検索する。
過去のFailure Caseを取得する。
LLMが情報を整理する。
Engineerへ確認事項を提示する。
すると、
Sensor AI + Enterprise Knowledge + LLM
という構造になる。
製薬で構築してきたKnowledge AIと、Physical AIがここで接続する。
⸻
Multimodal化
現場の状態は一種類のDataだけでは十分に表現できない。
Camera Image。
Thermal Image。
Sound。
Vibration。
Sensor Value。
Text Record。
Human Observation。
複数のModalitiesを組み合わせることで、より豊かなState Estimationが可能になる。
したがってEnergy AIは、
Single-modal AI
から、
Multimodal Industrial AI
へ進む可能性がある。
これは後のPhysical AIへ直接つながる。
⸻
Inspectionの自動化
Energy Infrastructureには多数のInspection Taskがある。
Humanが現場へ行き、目視確認する。
写真を撮る。
Measurementする。
記録する。
Reportを書く。
このProcessの一部を、
Camera。
Drone。
Robot。
Computer Vision。
LLM。
によって支援できる可能性がある。
すると、
Human Inspection
から、
Human + Machine Inspection
へ変化する。
ただし、設備ごとにEnvironmentやSafety Requirementが異なるため、一般的なAIをそのまま導入できるとは限らない。
⸻
Energy AIは現場条件に支配される
Laboratoryでは高い精度を示したModelでも、現場では性能が低下することがある。
照明が変わる。
Camera Angleが変わる。
Noiseが入る。
設備が汚れる。
Weatherが変わる。
Sensorが劣化する。
つまり、
Training Environment ≠ Operating Environment
である。
Physical AIでは、このDistribution Shiftが重要なProblemになる。
AI ModelのAccuracyだけではなく、Environment ChangeへのRobustnessを評価しなければならない。
⸻
Edge AIが必要になる
Energy Facilityでは、すべてのDataをCloudへ送信できるとは限らない。
通信が不安定かもしれない。
大量Videoを常時送信するとBandwidthを消費する。
Security上、Facility外へDataを出しにくい場合もある。
即時処理が必要なTaskもある。
そこで、
Edge Computing
が重要になる。
現場側でInferenceする。
必要な結果だけをCloudへ送る。
Cloud側では長期AnalysisやModel Managementを行う。
構造は、
Sensor → Edge AI ⇄ Cloud AI
となる。
⸻
Cybersecurityとの接続
InfrastructureへAIを導入すると、Cybersecurityの重要性も増す。
Sensor。
Network。
Cloud。
AI Model。
Remote Operation System。
接続点が増えるほどAttack Surfaceも広がる。
したがって、
AI Security。
Network Security。
Identity。
Authorization。
Logging。
Incident Response。
を分離せずに考える必要がある。
AIを賢くすることと、Infrastructureを安全にすることは別の問題である。
両方が成立しなければProduction Systemにはならない。
⸻
Explainability
EngineerがAIのAlertを受け取ったとする。
「異常です」
だけでは十分でない。
どのSensorが変化したのか。
いつから変化したのか。
過去と何が違うのか。
どのFeatureが判断へ影響したのか。
どの程度のConfidenceなのか。
こうした情報があれば、Humanは判断しやすくなる。
つまりExplainabilityは、
AIを説明するため
だけではなく、
Human Decisionを支援するため
に必要になる。
⸻
Digital Twinという方向
Physical Assetの状態をSensorで継続取得し、Digital側へ反映する。
その上でSimulationやAI Analysisを行う。
この構造を高度化するとDigital Twinへ近づく。
Physical Asset ⇄ Digital Representation
である。
設備の現在状態を把握する。
将来状態をSimulationする。
Maintenance Planを比較する。
ただし、EQUESについては現在確認できる事業と、将来的に接続可能なTechnologyを区別しなければならない。
Digital Twinは、Energy AIのArchitectureとして重要な方向性であって、すべてが同社ですでに完成していることを意味しない。
⸻
Energy AIの先に原子力がある
Energy Infrastructureの中でも、さらに厳しい条件を持つのが原子力である。
特に廃炉では、
Humanが入りにくい。
放射線環境がある。
未知の状況が存在する。
遠隔操作が必要になる。
RobotのFailure Recoveryも難しい。
ここではAIの役割が、
Monitoring
だけではなく、
Physical Operation Support
へ広がる。
Energy AIからPhysical AIへの境界が最も明確に現れる場所である。
⸻
EQUESにとってのEnergy
EQUESは2026年にEnergy AI領域を新たな事業軸として本格化させ、原子力・廃炉を含む高信頼領域へのAI実装を打ち出している。
ただし、この展開を単純な「製薬の次にEnergy市場へ参入した」と読むだけでは不十分である。
Technology Capabilityの側から見ると、
Document AI
から、
Sensor AI
へ。
Enterprise Workflow
から、
Physical Workflow
へ。
Digital Verification
から、
Physical Safety
へ。
対象が拡張している。
⸻
製薬とEnergyをつなぐもの
製薬とEnergyは異なるIndustryである。
しかしEQUESが両者で蓄積し得るCapabilityには共通項がある。
高いReliability。
Domain Knowledge。
Traceability。
Explainability。
Human Review。
Security。
Evaluation。
現場Integration。
つまりEQUESの共通軸は、
Pharma
そのものでも、
Energy
そのものでもない。
その奥にある、
High-reliability Industrial AI
として読むことができる。
⸻
AIがPhysical Infrastructureへ入る
Energy AIの構造を最小化すると、
Physical Infrastructure
↓
Sensor / Inspection
↓
Data
↓
AI Analysis
↓
Risk / Anomaly Detection
↓
Human Decision
↓
Maintenance / Operation
となる。
ここでAIは、Screen上で文章を生成するだけのTechnologyではない。
Physical Infrastructureの状態を認識し、Humanが現実世界へActionするための判断を支えるTechnologyになる。
そして、さらに過酷なEnvironmentでは、Human自身が現場へ入れない。
そのとき必要になるのがRobotである。
Humanが観測できない場所をMachineが観測し、Humanが作業できない場所でMachineが作業する。
EQUESのPhysical AIを考えるうえで、その最も重要なCaseの一つが福島第一原子力発電所の廃炉である。
次節では、Energy AIの中でも極めて高い安全性と信頼性を要求される原子力と高信頼AIへ進む。
第2節 原子力と高信頼AI
AIを原子力へ導入するという言葉には、特別な慎重さが必要である。
一般的なSoftware ServiceでAIが誤れば、誤ったRecommendationをHumanが修正できる場合がある。しかし原子力施設では、Systemの役割によっては誤認識や誤操作の影響がPhysical Environmentへ及ぶ。
さらに廃炉では、放射線、狭隘空間、複雑な構造物、通信条件、未知のEnvironmentなどが重なる。
だから原子力に必要なのは、単に「高性能なAI」ではない。
安全上の役割と限界が明確で、検証でき、Humanが適切に介入でき、Failureを前提として運用できるAI Systemである。
EQUESがEnergy・原子力領域へ進む意味は、この極めて厳しい条件の中でAIを社会実装することにある。
⸻
原子力では「できる」と「使える」が遠い
Research Environmentで高いAccuracyを達成した。
RobotがObjectを認識できた。
AIが適切なActionを生成できた。
それだけで原子力施設へ導入できるわけではない。
現場では、
どの条件で性能を確認したのか。
未知の状況ではどうなるのか。
Sensorが故障したらどうするのか。
通信が途絶えたらどうするのか。
AIが判断できないときに停止できるのか。
Humanが介入できるのか。
といった問いが加わる。
したがって、
Research Performance ≠ Operational Reliability
である。
この距離を埋めるEngineeringが高信頼AIの中心になる。
⸻
Safety-criticalとMission-critical
高信頼Systemを考えるとき、すべてのAI機能を同じRisk Levelとして扱う必要はない。
例えば、過去の作業記録を検索するAIと、RobotのMotionへ直接影響するAIではFailureの意味が異なる。
前者が誤ればHumanが検索結果を確認できる。
後者が誤ればPhysical Actionへつながる可能性がある。
したがって、
AI Function → Hazard → Required Control
というRisk-basedな設計が必要になる。
「原子力でAIを使う」という大きな一語ではなく、AIがSystemのどこで、何を担当するのかを分解しなければならない。
⸻
Humanが入れないEnvironment
廃炉でRoboticsが重要になる理由の一つは、Human Exposureを減らせることにある。
放射線量が高いEnvironmentでは、Humanが長時間作業できない。
そこで、
Camera。
Sensor。
Manipulator。
Mobile Robot。
Remote Control。
などを利用して、Humanの代わりにMachineを現場へ送る。
ここではAutomationそのものが目的ではない。
Human Safetyを確保しながら必要な作業を実行すること
が目的である。
⸻
Remote Operationという出発点
高Risk Environmentでは、完全自律RobotよりRemote Operationが重要になる場合がある。
Human Operatorが離れた場所からRobotを操作する。
Camera Imageを見る。
Sensor Dataを確認する。
Manipulatorを動かす。
この構造は、
Human → Interface → Robot → Environment
である。
AIはHumanをいきなり取り除くのではなく、このLoopを支援するところから入ることができる。
⸻
AIはOperatorを支援する
Remote OperationではHumanへ大きな認知負荷がかかる。
複数Cameraを見る。
Robotの姿勢を把握する。
周囲との距離を判断する。
作業対象を認識する。
Collision Riskを避ける。
Machine Stateを監視する。
そこでAIが、
Object Detection。
Segmentation。
Depth Estimation。
Environment Recognition。
Anomaly Detection。
Operation Recommendation。
などを支援する。
構造は、
Human → Robot
から、
Human ⇄ AI ⇄ Robot
へ変化する。
⸻
SensorがRealityをDigital化する
AIはPhysical Environmentを直接認識しているわけではない。
CameraやSensorから得られたDataを通じて認識する。
したがって、
Physical Reality
→ Sensor
→ Digital Representation
→ AI
という変換がある。
この途中でInformationが失われる。
Cameraには死角がある。
SensorにはNoiseがある。
MeasurementにはErrorがある。
通信にはLatencyがある。
AIが正しくても、InputがRealityを正確に表現していない可能性がある。
高信頼AIではModelだけでなく、Observation System全体を見る必要がある。
⸻
Sensor Failureを前提にする
Sensorは故障する。
Cameraは汚れる。
Lighting Conditionは変わる。
通信Packetが失われる。
Calibrationがずれる。
したがって、
Sensor Input = Truth
とは置けない。
複数Sensorを比較する。
異常値を検出する。
Confidenceを持たせる。
Sensor Failure時には安全側へ移行する。
こうした設計が必要になる。
AI Systemの信頼性は、Model Accuracyより広い。
⸻
Unknown Environment
廃炉Environmentでは、事前にすべてを完全把握できない可能性がある。
物体の位置が予想と異なる。
障害物がある。
構造物が変形している。
視界が悪い。
Robotが想定外の姿勢になる。
Machine Learningが苦手とするのは、このようなDistribution Shiftである。
Training Dataに存在しない状況で、Modelがどのように振る舞うか。
ここが重要になる。
⸻
「分からない」と言えるAI
高信頼AIでは、常に答えを出すことが優秀とは限らない。
Confidenceが低い。
未知のSituationである。
Sensor間でDataが矛盾している。
その場合には、
I don’t know
に相当する状態をSystemとして表現できる方が安全である。
つまり、
Prediction
だけではなく、
Uncertainty Estimation
が重要になる。
AIが判断できないときにHumanへ戻す。
これは高信頼AIの基本的な設計思想である。
⸻
Explainable AI
原子力のような領域では、AI Outputの根拠をHumanが理解できることも重要になる。
なぜそのObjectを危険と判断したのか。
Imageのどこを見たのか。
どのSensor値が異常だったのか。
過去のどのPatternと似ているのか。
どの程度のConfidenceなのか。
ここでExplainable AI――XAI――が関係する。
ただし、説明らしい文章をAIに生成させればExplainabilityが成立するわけではない。
必要なのは、
Decision Evidence
をHumanへ提示することである。
⸻
ExplainabilityとTraceability
ExplainabilityとTraceabilityは似ているが異なる。
Explainabilityは、
なぜこの判断になったのか
を理解するための情報である。
Traceabilityは、
Systemで何が起きたのか
を後から追跡する能力である。
どのSensor Dataを使ったのか。
どのModel Versionだったのか。
どのOutputを出したのか。
Humanはどう操作したのか。
Robotはどう動いたのか。
これらを記録する。
高信頼AIでは両方が必要になる。
⸻
Auditability
Traceabilityを組織的に利用可能にするとAuditabilityにつながる。
事故やUnexpected Behaviorが発生した場合、
何が起きたのか。
どのComponentが関与したのか。
HumanとAIはそれぞれ何をしたのか。
System Requirementを満たしていたのか。
を検証できる必要がある。
これは責任追及だけのためではない。
System Improvement
のためでもある。
Failureから学習するには、Failureを再構成できなければならない。
⸻
AIにSafetyを丸投げしない
AI Safetyという言葉から、AI Model自身がすべてのSafetyを保証するように考えることがある。
しかしPhysical Systemでは、Safetyは複数Layerで構築される。
AI Model。
Rule-based Constraint。
Motion Limit。
Collision Avoidance。
Emergency Stop。
Mechanical Safety。
Communication Control。
Human Override。
Operational Procedure。
つまり、
Safety = Defense in Depth
である。
一つのAI ModelがFailureしても、System全体が直ちに危険状態へ移らないArchitectureを作る。
⸻
Fail-safe
高信頼Systemでは、
「FailureしないSystem」
を目標にするだけでは不十分である。
すべての複雑なSystemにはFailure可能性がある。
したがって、
Failureしたとき安全側へ移行できるか
が重要になる。
通信が切れたら停止する。
Sensorが異常ならActionを制限する。
AIのConfidenceが低ければHumanへ戻す。
Critical Componentが故障したらBackupへ切り替える。
これがFail-safeの考え方である。
⸻
Redundancy
一つのComponentだけに依存しないことも重要になる。
Cameraだけではなく複数Sensorを使う。
AI PredictionだけではなくRule Checkを行う。
Automatic ControlだけではなくHuman Overrideを残す。
一つのCommunication Pathだけに依存しない。
このように、
Independent Layers
を重ねる。
製薬AIで見た、
GenerationとVerificationを分離する考え方が、Physical AIではさらにSafety Architectureとして強化される。
⸻
Human-in-the-loopだけでは足りない
すべてのAI判断をHumanが事前承認すれば安全に見える。
しかしRobot ControlではMilliseconds単位の反応が必要になる場合がある。
Humanが毎回判断することはできない。
そこでAutomation Levelを分解する必要がある。
AIがRecommendationだけを出す。
AIがAction候補を作りHumanが承認する。
AIが一定範囲を自律実行しHumanが監視する。
Safety-criticalな条件ではAutomatic Stopが介入する。
つまり、
Human-in-the-loop
だけでなく、
Human-on-the-loop
を含む複数のSupervision Modelが必要になる。
⸻
Simulationで失敗する
実際の原子力施設で大量のTrial and Errorを行うことは難しい。
そこでSimulationが重要になる。
RobotをDigital Environmentへ置く。
Sensor Conditionを変える。
Communication Failureを起こす。
未知のObstacleを置く。
AIを意図的に失敗させる。
つまり、
Fail in Simulation before Failing in Reality
である。
SimulationはRobot Learningのためだけでなく、Safety ValidationのためのEnvironmentでもある。
⸻
Rare Eventという難しさ
Safety-critical Systemでは、重大事故は頻繁には発生しない。
これは望ましいことである。
しかしMachine Learningには難しい。
Training Dataが少ないからである。
したがって、
Historical Dataだけに依存できない。
Simulation。
Synthetic Data。
Physics-based Model。
Expert Knowledge。
Rule。
Stress Testing。
などを組み合わせる必要がある。
ここでも、
AI alone
ではなく、
Hybrid Engineering
が必要になる。
⸻
CybersecurityもSafetyになる
RobotがNetworkへ接続されれば、CybersecurityとPhysical Safetyは分離できなくなる。
不正Access。
Command Manipulation。
Sensor Data Tampering。
Model Manipulation。
Communication Disruption。
Digital AttackがPhysical Consequenceへつながる可能性がある。
したがって、
Cybersecurity → Physical Safety
という関係が生まれる。
Identity、Authentication、Authorization、Encryption、Loggingは、単なるIT Departmentの仕事ではなくPhysical AI Systemの一部になる。
⸻
原子力でAIを使う意味
ここまで見ると、原子力へAIを導入することは難しい。
では、なぜ使うのか。
理由の一つは、AIによってHuman Riskを下げられる可能性があるからである。
Humanが高線量Environmentへ入る時間を減らす。
遠隔から状況を理解しやすくする。
Robot Operationを支援する。
大量Dataから異常候補を見つける。
つまり、
Automation for Productivity
だけではなく、
Automation for Human Safety
である。
⸻
EQUESの位置
EQUESは、廃炉関連の技術開発において、大学・研究機関・企業などとの共同体制の中でAI・Roboticsに関わる開発へ参加している。
ここでは事実関係を慎重に区別する必要がある。
EQUES一社が廃炉Robot全体を開発しているわけではない。
Robot Hardware。
Remote Operation。
AI。
研究設備。
現場Knowledge。
それぞれ異なる主体がCapabilityを持つ。
重要なのは、
Multi-organization Engineering
である。
高難度Infrastructureでは、一社完結ではなく複数の専門組織を接続する能力そのものが重要になる。
⸻
大学発Startupの役割
大学には先端Researchがある。
大企業には現場とInfrastructureがある。
公的研究機関には専門設備と長期Knowledgeがある。
政府には政策と研究開発支援がある。
StartupにはTechnologyを素早く試し、Softwareとして実装する能力がある。
これらを接続すると、
**Academia
* Startup
* Industry
* Public Research
* Government**
というInnovation Systemが形成される。
EQUESはその中で、AI Technologyを現場Requirementへ翻訳する役割を担い得る。
⸻
製薬で得た高信頼設計との対応
製薬AIでは、
Trusted Data。
Evaluation。
Human Review。
Traceability。
Audit。
が重要だった。
原子力AIでも同じ言葉が現れる。
ただし、対象が変わる。
Document Error
から、
Physical Error
へ。
Document Approval
から、
Operation Control
へ。
Quality Assurance
から、
Physical Safety Assurance
へ。
製薬で形成した高信頼AIの考え方を、より厳しいPhysical Systemへ拡張することになる。
⸻
Trusted AIとは「絶対に間違えないAI」ではない
ここで本章の重要な定義ができる。
Trusted AIとは、
絶対に間違えないAI
ではない。
そのような保証を一般的なMachine Learning Systemへ置くことは現実的ではない。
むしろ、
どこまで信頼できるかを測れる。
分からないときに分からないと扱える。
Failureを検出できる。
Humanが介入できる。
安全側へ移行できる。
何が起きたか追跡できる。
継続的に改善できる。
そうしたSystemである。
したがって、
Trust is engineered, not assumed.
信頼はModelに最初から備わっている属性ではなく、System Architectureによって構築される。
⸻
原子力は高信頼AIの極限Caseである
原子力はすべてのAI Applicationの代表ではない。
要求されるSafety Levelも用途によって異なる。
しかし、AI社会実装の本質を考えるには重要なCaseである。
Model Accuracyだけでは足りない。
Hardwareだけでも足りない。
Humanだけでも足りない。
必要なのは、
**Sensor
* AI
* Control
* Safety
* Human
* Governance**
の統合である。
ここまで来ると、AIは単なるSoftware Applicationではない。
Cyber-Physical Systemの一Componentになる。
⸻
高信頼AIからPhysical AIへ
原子力AIの最小構造は、
Physical Environment
↓
Sensor
↓
AI Perception / Analysis
↓
Uncertainty / Explainability
↓
Human / Safety Control
↓
Robot Action
↓
Audit / Feedback
となる。
製薬でAIは「記録を扱うSystem」だった。
原子力では、AIは「現場を認識し、MachineのActionを支援するSystem」へ広がる。
そして、その具体的な実装対象として重要になるのが、福島第一原子力発電所の廃炉である。
そこでは、高線量Environment、遠隔操作、Robot、AI、Human Operatorが一つのSystemとして接続される。
次節では、一般論としての原子力AIから具体的な現場へ進み、福島第一原発と遠隔作業を通じて、EQUESのPhysical AIがどこで、どのような役割を担おうとしているのかを見ていく。
第3節 福島第一原発と遠隔作業
福島第一原子力発電所の廃炉は、通常の設備解体とは異なる。
2011年3月の事故によって損傷した原子炉建屋内部には、人間が長時間立ち入ることが難しい高線量区域が存在する。内部状況の把握、調査、障害物への対応、燃料デブリに関係する作業などを、長い時間をかけて安全に進めなければならない。
ここで必要になるのが遠隔技術である。
Camera。
Sensor。
Manipulator。
Mobile Robot。
Remote Operation System。
そしてAI。
EQUESが関与する廃炉関連の研究開発を理解するには、「AI企業が原発へ参入した」と見るだけでは足りない。
そこでは、
Humanが直接作業することの難しいPhysical Environmentを、Machineを介して観測し、理解し、操作する
という、Physical AIの根本問題が現れている。
⸻
廃炉は長期のEngineering Projectである
福島第一原発の廃炉は、一つのRobotを投入すれば終わる仕事ではない。
現場を調査する。
内部状態を把握する。
放射線量を測る。
作業方法を設計する。
必要な装置を開発する。
遠隔で作業する。
結果を確認する。
新しく得られた情報から、次の作業を設計する。
つまり、
Observe → Understand → Plan → Operate → Verify → Replan
という反復的なEngineering Processになる。
AIが入る余地も、このProcessの複数箇所に存在する。
⸻
なぜRemoteなのか
遠隔作業の第一目的は、人間を危険なEnvironmentから遠ざけることにある。
通常のIndustrial Automationでは、
Cost Reduction。
Productivity。
Labor Saving。
が主要な導入理由になる場合が多い。
しかし高線量Environmentでは意味が変わる。
Remote Technology → Reduction of Human Exposure
となる。
RobotはHumanを不要にするためのMachineではない。
Humanが直接到達しにくい場所へ、HumanのPerceptionとActionを延長するMachineである。
⸻
RobotはHumanの身体を延長する
Remote Robotを抽象化すると、人間の身体機能を離れた場所へ移していると考えられる。
CameraはEyeになる。
MicrophoneはEarになる。
SensorはHumanでは直接取得しにくいMeasurementを行う。
ManipulatorはHandになる。
Mobile PlatformはLegになる。
すると、
Human Body
が、
Sensor + Network + Interface + Robot
によってPhysicalに拡張される。
遠隔Roboticsは、単なるAutomation Technologyではなく、Human CapabilityのExtensionでもある。
⸻
しかし遠隔操作は簡単ではない
RobotにCameraを付け、Remote Controllerを用意すれば十分というわけではない。
Operatorが見るのはRealityそのものではなく、CameraやSensorを通じて再構成されたEnvironmentである。
視野が狭い。
Depthが分かりにくい。
Robot自身の姿勢が把握しにくい。
Obstacleとの距離を判断しにくい。
通信にはLatencyがある。
複数Cameraを同時に監視する必要がある。
その結果、Operatorには大きなCognitive Loadがかかる。
⸻
AIはHumanの認識を補助する
ここにAIを組み込む余地がある。
Camera ImageからObjectを認識する。
作業対象をSegmentationする。
Obstacleを検出する。
3D Structureを推定する。
Robotと周囲との距離を推定する。
危険なMovementを警告する。
AIの役割は、いきなりRobotを完全自律化することだけではない。
まず、
Human Perception Assistance
として利用できる。
つまり、
Camera → Human
だった情報経路へ、
Camera → AI → Human
という補助Layerを追加する。
⸻
PerceptionからActionへ
さらにAIの役割を広げれば、RecognitionだけでなくAction Supportへ進む。
どの方向から接近するか。
Manipulatorをどう動かすか。
どのRouteがCollision Riskを下げるか。
どのOperation Sequenceが適切か。
AIが候補を生成し、Humanが判断する。
構造は、
Perception → Planning → Human Approval → Action
となる。
完全自律化ではなく、段階的にMachine Assistanceを増やすことができる。
⸻
Shared Autonomy
このHumanとMachineの中間にある重要な考え方がShared Autonomyである。
すべてをHumanが操作するわけでもない。
すべてをAIが判断するわけでもない。
例えばHumanが、
「この対象を把持する」
というGoalを指定する。
AIが、
Approach。
Position Adjustment。
Collision Avoidance。
Grasp Planning。
などの一部を支援する。
Humanはより上位のDecisionへ集中する。
つまり、
Human Intent + Machine Assistance
である。
高難度Remote Operationでは、この役割分担が重要になる。
⸻
ハプティクスという接点
EQUES代表の岸尚希は、東京大学大学院でSystem Information Engineeringを学び、Hapticsに関係する研究経験を持つ。
Hapticsは、力や触覚などのPhysical InformationをHumanとMachineの間で扱うTechnologyである。
Remote Roboticsでは視覚だけでなく、
どの程度の力が加わっているのか。
対象へ接触したのか。
硬いのか。
滑っているのか。
といった情報も重要になる。
Remote Operationを、
Visual Interface
だけでなく、
Physical Interaction Interface
として考える視点につながる。
⸻
HumanとRobotの間にある情報量
Humanが現場で直接作業するときには、多数の情報を同時に利用している。
視覚。
聴覚。
触覚。
力覚。
身体位置。
空間感覚。
しかしRemote Operationでは、その一部しかOperatorへ届かない。
つまり、
Physical Environment → Digital Interface
への変換でInformation Lossが起きる。
AIの重要な役割の一つは、その不足を補うことである。
複数Sensorを統合し、Humanが理解しやすいRepresentationへ変換する。
⸻
Multimodal AI
ここでMultimodal AIが重要になる。
Videoだけではない。
Depth。
Point Cloud。
Force。
Position。
Radiation Measurement。
Equipment State。
過去の作業記録。
複数のDataを統合する。
するとAIは、
What is visible?
だけではなく、
What is happening?
を推定する方向へ進む。
これはLanguage Model中心の生成AIとは異なるPhysical Intelligenceである。
⸻
放射線はRobotにも影響する
Humanが高線量Environmentへ入れないからRobotを使えば、すべて解決するわけではない。
放射線EnvironmentはElectronicsにも影響し得る。
Camera。
Sensor。
Semiconductor。
Communication Equipment。
Robot Controller。
使用条件に応じて耐放射線性や運用時間などを考慮しなければならない。
したがってPhysical AIでは、
Model Performance
だけでなく、
Hardware Survivability
もSystem Requirementになる。
SoftwareとHardwareを分離して設計できない。
⸻
通信が切れたらどうするか
Remote RobotはCommunicationに依存する。
しかし通信品質が常に理想的とは限らない。
Latencyが増える。
Bandwidthが落ちる。
Connectionが切れる。
このときRobotが危険なActionを継続してはならない。
したがって、
Communication Failure → Safe State
という設計が必要になる。
必要に応じてEdge側で最低限のSafety Functionを保持する。
ここでEdge AIとFail-safe Architectureが接続する。
⸻
Cloudだけには依存できない
LLMの普及によってAIはCloud上で動かすものという印象が強くなった。
しかしRemote Roboticsでは、Cloudへの往復時間がCriticalになるTaskがある。
Collision Detection。
Emergency Stop。
Immediate Control。
こうした処理はRobotやLocal Computerの近くで行う必要がある。
一方、
Long-term Analysis。
Model Training。
Large-scale Simulation。
Knowledge Management。
はCloudを利用できる。
したがって、
Robot / Edge ⇄ Local System ⇄ Cloud
という階層的Architectureが必要になる。
⸻
Simulationで操作を学ぶ
廃炉現場でRobotを無制限に試験することはできない。
そこでDigital Environmentが重要になる。
Robot Modelを作る。
作業空間を再現する。
OperatorがTrainingする。
AI Algorithmを試す。
Collisionを発生させる。
Communication Delayを再現する。
Failure Conditionを作る。
SimulationではRealityでは危険なExperimentも行える。
つまり、
Physical Trial
の一部を、
Digital Trial
へ移す。
⸻
Sim-to-Realの問題
ただしSimulationが精密でもRealityと完全には一致しない。
Surface Frictionが違う。
Object Positionが違う。
Camera Noiseが違う。
Robot Dynamicsが違う。
予想外のObstacleがある。
したがって、
Simulation ≠ Reality
である。
Simulationで学習したAIをReal Environmentへ移すときには、Sim-to-Real Gapを考慮する必要がある。
Physical AIにおける重要なResearch Problemの一つである。
⸻
Digital Twinとの違い
SimulationとDigital Twinも同一ではない。
Simulationは仮想Environmentで挙動を試すことが中心になる。
Digital TwinはPhysical AssetのCurrent StateとDigital Representationを継続的に接続することを重視する。
Sensor Dataが入る。
Digital Stateが更新される。
Simulationする。
結果をPhysical Operationへ戻す。
将来的には、
Physical Facility ⇄ Digital Representation
の接続が高度化する可能性がある。
ただし、EQUESの具体的な研究開発について、確認できる範囲を超えてDigital Twin全体を実装済みと扱うべきではない。
⸻
共同研究でなければ成立しにくい
福島第一原発の廃炉というProblemは、一社だけで完結する規模ではない。
原子力Engineering。
Robotics。
AI。
Remote Operation。
Radiation Measurement。
Hardware。
Communication。
Safety。
現場Knowledge。
多様なExpertiseが必要になる。
EQUESが関係する廃炉向け技術開発も、研究機関、大学、企業など複数主体との連携として捉える必要がある。
ここで重要なのは、
One Company
ではなく、
Engineering Ecosystem
である。
⸻
Startupの役割
大規模Infrastructure ProjectでStartupは何を担えるのか。
すべてを所有する必要はない。
むしろ、
新しいAI Methodを試す。
Softwareを素早くPrototypeする。
RobotへAIを接続する。
Research AlgorithmをProduction Codeへ変換する。
新しいInterfaceを作る。
というTechnology Translationに強みを持ち得る。
これはEQUESが創業以来掲げてきた、
研究と社会実装の距離を縮める
という役割のPhysical版でもある。
⸻
福島第一原発は特殊Caseである
福島第一原発のEnvironmentは極めて特殊である。
したがって、そこで開発されたTechnologyをそのまま一般Factoryへ持ち込めるとは限らない。
しかしExtreme Environmentで要求されるCapabilityには、他分野へ応用可能なものがある。
Remote Inspection。
Robot Assistance。
Multimodal Perception。
Human-machine Interface。
Robust Control。
Edge Computing。
Fail-safe。
Simulation。
こうしたTechnologyは、
Infrastructure Inspection。
Disaster Response。
Plant Maintenance。
Construction。
Mining。
Space。
などにも接続し得る。
⸻
Extreme EnvironmentをTechnology Testbedとして見る
過酷なEnvironmentではTechnologyへのRequirementが高くなる。
低Latency。
高Reliability。
Limited Communication。
Human Safety。
Unknown Environment。
Hardware Constraint。
これらを満たすTechnologyを構築できれば、より一般的なEnvironmentへ展開できる可能性がある。
つまり、
Extreme Environment → Generalizable Capability
というTechnology Transferが考えられる。
ただし、実際の横展開には各Industry固有のValidationが必要である。
⸻
廃炉から社会Infrastructureへ
日本には今後、
老朽Infrastructure。
災害対応。
人口減少。
Maintenance Worker不足。
危険作業。
という課題が存在する。
HumanがすべてのPhysical Workを直接担い続けることが難しくなれば、
Robot。
Remote Operation。
AI Assistance。
Automation。
の必要性は高まる。
福島第一原発向けのTechnology Developmentは、極端に特殊な一案件であると同時に、日本社会全体が将来必要とするRemote Physical Workの先行事例として読むこともできる。
⸻
Humanを消すのではなく、危険から離す
Physical AIの議論では「無人化」という言葉が使われやすい。
しかし廃炉では、より正確な表現がある。
HumanをSystemから消すのではなく、危険な場所から離す。
Humanは、
Goalを決める。
Situationを判断する。
AIを監視する。
RobotへInstructionを与える。
Unexpected Situationへ対応する。
最終的な責任を担う。
Humanの位置がPhysical SiteからControl Layerへ移るのである。
⸻
Human–AI–Robot System
この構造を最小化すると、
Human Operator
⇅
AI Assistance
⇅
Remote / Autonomous Robot
⇅
Physical Environment
となる。
しかし実際には、その周囲に、
Sensor。
Network。
Edge Computing。
Safety System。
Simulation。
Audit Log。
Domain Expert。
が存在する。
したがってPhysical AIはRobot単体ではない。
Human–AI–Robot System
として設計しなければならない。
⸻
福島第一原発から見えるEQUES
EQUESを生成AI Startupとしてだけ見ると、JPharmatronやQAIが中心に見える。
しかし福島第一原発に関係する研究開発まで視野を広げると、別の企業像が現れる。
Textを扱う。
Knowledgeを扱う。
Imageを扱う。
Sensorを扱う。
Robotへ接続する。
Human Operationを支援する。
つまり対象が、
Digital Information
から、
Physical Interaction
へ拡張している。
ここに第Ⅳ部の転換点がある。
⸻
遠隔作業からPhysical AIへ
遠隔作業はHumanがMachineを操作するTechnologyである。
Physical AIは、その間にMachine Intelligenceを加える。
最初は認識を支援する。
次に操作を支援する。
さらに限定されたTaskを自律化する。
そしてHumanが全体を監督する。
したがって、
Remote Operation
→ AI-assisted Operation
→ Shared Autonomy
→ Bounded Autonomy
という段階的な発展として考えることができる。
完全自律か完全手動かという二択ではない。
⸻
Softwareの外へ
福島第一原発の廃炉がEQUESのTechnology Strategyにとって象徴的なのは、AIのOutputが初めてPhysical Consequenceへ直接近づくからである。
製薬では、
Text → Text
が中心だった。
ここでは、
Sensor → Intelligence → Physical Action
となる。
AIはScreenの中から出て、
Robotを通じてRealityへ接触する。
その瞬間、必要になるEngineeringも変わる。
Accuracyだけではない。
Latency。
Robustness。
Safety。
Hardware。
Human Interface。
Environment。
すべてを統合しなければならない。
それがPhysical AIである。
次節では、この概念をさらに一般化し、Robotだけに限定されないPhysical AIとは何かを、EQUESの事業展開と現代AI技術の双方から整理していく。
第4節 フィジカルAI
生成AIの急速な普及によって、2020年代前半のAIはLanguageとDigital Informationを中心に発展した。
文章を生成する。
画像を理解する。
Programを書く。
Knowledgeを検索する。
企業Dataを分析する。
しかし、人間が暮らす世界の大部分はSoftwareの内部には存在しない。
工場がある。
発電設備がある。
道路がある。
建築物がある。
Machineがある。
Robotがある。
そして、重力、摩擦、温度、距離、力、時間といったPhysical Constraintがある。
AIがこれらと直接接続し始めると、問題は大きく変わる。
それがPhysical AIである。
EQUESがEnergy、原子力、遠隔Roboticsへ事業領域を広げていることは、同社のAI社会実装がDigital DomainからPhysical Domainへ拡張していることを意味する。
⸻
Physical AIとは何か
Physical AIという言葉には複数の使われ方がある。
本書では、最も広く、
Physical EnvironmentをSensorによって認識し、その状態を推定し、HumanまたはMachineのActionへ接続するAI System
として捉える。
最小構造は、
Environment
→ Sensor
→ Perception
→ World Representation
→ Decision / Planning
→ Action
→ Environment
である。
ここには重要な特徴がある。
最後のActionがEnvironmentを変える。
そして変化したEnvironmentを再びSensorが観測する。
つまりPhysical AIは、一方向の情報処理ではない。
Closed Loop System
である。
⸻
LLMとの違い
LLMでは、多くの場合、
Text → Model → Text
という構造になる。
Physical AIでは、
Physical World → Data → AI → Physical Action
となる。
Outputの性質が根本的に異なる。
LLMが誤った文章を生成すれば、Humanが削除できる場合がある。
Robotが誤ったMovementを実行すれば、ObjectやEquipmentへPhysicalな影響を与える可能性がある。
したがってPhysical AIでは、
Accuracyだけでなく、
Latency。
Robustness。
Safety。
Control。
Hardware Reliability。
Human Override。
が不可欠になる。
⸻
RobotだけがPhysical AIではない
Physical AIをHumanoid Robotだけと考える必要はない。
例えば、
Infrastructure Inspection。
Autonomous Vehicle。
Drone。
Industrial Robot。
Remote Manipulator。
Warehouse System。
Agricultural Machine。
Energy Facility。
Medical Robot。
などもPhysical AIの対象になり得る。
さらに、AIが直接MachineをControlしなくても、
SensorからPhysical Stateを理解し、HumanのActionを支援するSystemも広い意味ではPhysical Intelligenceの一部として捉えられる。
重要なのはRobotの形ではない。
AIがPhysical EnvironmentとのFeedback Loopへ入っているか
である。
⸻
Perception
Physical AIの第一段階はPerceptionである。
Camera ImageからObjectを認識する。
LiDARからDistanceを測る。
Point Cloudから3D Structureを把握する。
Sensor DataからMachine Stateを推定する。
音から異常を検出する。
Physical Worldは、そのままComputerへ入力されるわけではない。
まずDigital Representationへ変換される。
Reality → Measurement → Representation
である。
したがってPhysical AIの性能は、ModelだけでなくSensor Systemにも依存する。
⸻
World Representation
認識した情報を単発で処理するだけでは、複雑な作業は難しい。
Robotは、
自分はどこにいるのか。
周囲に何があるのか。
Objectはどこにあるのか。
どこが通行可能なのか。
何が動いているのか。
を継続的に把握する必要がある。
そこでEnvironmentの内部Representationが必要になる。
Map。
3D Model。
Object State。
Robot State。
Task State。
こうした情報を統合したものが、Physical AIにおけるWorld Representationになる。
⸻
World Modelとの接続
AI研究ではWorld Modelという考え方が重要になっている。
現在のObservationからEnvironmentのStateを推定し、
「このActionを取ったら何が起こるか」
を予測する。
Physical AIでは、この能力が直接的な価値を持つ。
Robot Armを動かせばObjectはどう動くか。
このRouteを進めばCollisionするか。
この力を加えれば対象はどう変化するか。
つまり、
State + Action → Next State
を予測する。
AIが現実世界で安全に行動するには、現在を認識するだけでなく、Actionの結果を予測する能力が重要になる。
⸻
Planning
Environmentを理解した次には、何をするかを決める。
Goalを設定する。
Taskを分解する。
Action候補を生成する。
Constraintを確認する。
安全なSequenceを選ぶ。
これがPlanningである。
例えば、
「このObjectを回収する」
というGoalがあれば、
接近する。
位置を調整する。
Manipulatorを伸ばす。
把持する。
持ち上げる。
移動する。
という複数Actionへ分解できる。
Physical AIでは、Language上のPlanningをPhysical Constraintへ変換しなければならない。
⸻
Control
PlanningしたからといってRobotが正確に動くとは限らない。
Physical Worldには誤差がある。
Motor。
Friction。
Load。
Surface。
Position Error。
External Force。
そこでControl Systemが必要になる。
AIがHigh-level Planを作り、従来型Control AlgorithmがLow-level Motionを安定化する構成も考えられる。
つまり、
AI or Planner ≠ Entire Robot System
である。
既存のControl EngineeringとMachine Learningを接続することが重要になる。
⸻
VLAという方向
近年のRoboticsでは、Vision-Language-Action――VLA――というArchitectureが注目されている。
Imageを見る。
Language Instructionを理解する。
Actionへ変換する。
概念的には、
Vision + Language → Action
である。
LLMやVision-Language Modelで蓄積された能力をRoboticsへ拡張する方向といえる。
しかし、Language Modelが高度だからといって、そのままSafety-critical EnvironmentでRobotを動かせるわけではない。
Physical Actionには追加のConstraintとValidationが必要になる。
⸻
Foundation ModelからRobotへ
生成AIでは、一つの大規模Modelが多数のTaskへ対応するFoundation Modelという考え方が広がった。
Roboticsでも、多様なRobot、Environment、TaskからDataを学習し、汎用的なPhysical Capabilityを獲得しようとする研究が進んでいる。
もしこれが高度化すれば、
TaskごとにProgramを書くRobotから、
Instructionを理解し、新しいTaskへ適応するRobot
へ移行する可能性がある。
ただし、Industrial Applicationでは汎用性だけでは不十分である。
現場固有のSafety RequirementとPerformance Requirementを満たす必要がある。
⸻
General Physical AIとDomain Physical AI
ここで、製薬AIと同じ構造が現れる。
汎用LLMに対してJPharmatronのようなDomain-specific Modelが存在した。
Physical AIでも、
General Physical Model
と、
Domain-specific Physical System
を分けて考えられる。
Factory。
Nuclear Facility。
Warehouse。
Hospital。
Space。
それぞれEnvironmentもFailure Costも異なる。
したがって、
Foundation Capability × Domain Adaptation
という構造がPhysical AIでも必要になる。
⸻
Simulation
Physical AIではData Acquisitionが難しい。
TextはInternet上に大量に存在する。
しかしRobotの失敗Dataを大量にReal Worldで集めることはCostもRiskも大きい。
そこでSimulationを使う。
Digital EnvironmentでRobotを動かす。
大量のSituationを生成する。
Rare Eventを作る。
Failureを経験させる。
Trainingする。
評価する。
つまり、
Physical Experience
の一部を、
Synthetic Experience
へ変換する。
⸻
Sim-to-Real
しかしSimulationだけで完結しない。
実世界にはSimulationで再現しきれない差がある。
そこで、
Simulation → Real World
へのTransferが必要になる。
これがSim-to-Realである。
Simulation上で高性能でも、Realityで同じ性能が出るとは限らない。
Physical AIでは最終的にReal EnvironmentでVerificationする必要がある。
⸻
Edge AI
RobotはPhysical Worldの時間で動く。
Obstacleへ接近してから数秒後にCloudからResponseが返ってきても遅い場合がある。
そこでImmediate Controlに必要な処理はEdge側へ置く。
一方、大規模Modelや長期分析はCloud側へ置く。
例えば、
Robot / Edge
では、
Perception。
Collision Avoidance。
Local Control。
Safety。
を処理する。
Cloud
では、
Large Model。
Fleet Learning。
Long-term Analytics。
Model Training。
を処理する。
この分業によってPhysical AIのRuntimeが形成される。
⸻
Latencyは知能の一部になる
Digital AIではResponseが一秒遅れても許容される用途が多い。
Physical AIでは数十Millisecondsの差が重要になる場合がある。
つまり、
Intelligence Quality = Accuracy only
ではない。
Accuracy + Latency + Reliability
として考える必要がある。
どれほど優秀なModelでも、必要な時間内に答えを出せなければPhysical Systemでは利用できない。
⸻
HardwareとSoftwareは分離できない
Physical AIではHardware SpecificationがAI Capabilityを制約する。
Camera Resolution。
Sensor Accuracy。
Compute Power。
Battery。
Motor。
Network。
Thermal Condition。
Radiation Resistance。
AI EngineerがSoftwareだけを見てSystemを設計することはできない。
逆にHardware EngineerもAI Requirementを理解する必要がある。
したがって、
AI Engineering × Hardware Engineering
という統合が必要になる。
⸻
Safety Architecture
Physical AIではSafetyをModelへ任せない。
例えば、
AIがActionを提案する。
Rule EngineがConstraintを確認する。
Control SystemがMotion Limitを守る。
Collision Detectorが監視する。
Emergency Stopが独立して存在する。
HumanがOverrideできる。
つまり、
AI Layer
の外側に複数のSafety Layerを配置する。
これはDefense in Depthである。
⸻
ExplainabilityとPhysical Action
Physical AIでは、Explainabilityにも具体性が必要になる。
「AIはこのActionが最善だと考えました」
では足りない。
どのObjectを認識したか。
どのRouteを選択したか。
どこにCollision Riskがあるか。
Confidenceはいくつか。
どのConstraintが適用されたか。
Human OperatorがActionを理解し、必要なら止められるRepresentationが求められる。
⸻
Human–AI Collaboration
Physical AIの将来を「RobotがHumanを完全に置き換える」とだけ描く必要はない。
特に高Risk Environmentでは、
HumanがGoalを決める。
AIがEnvironmentを分析する。
RobotがPhysical Actionを行う。
Humanが監督する。
Safety Systemが独立して監視する。
という役割分担が考えられる。
Human + AI + Robot
を一つのSystemとして最適化する。
これが高信頼Physical AIの基本形になる。
⸻
Autonomyを段階として考える
Robotは、
ManualかAutonomousか、
という二択ではない。
Manual Remote Operation。
AI-assisted Operation。
Shared Autonomy。
Task-level Autonomy。
より高度なAutonomy。
複数の段階が存在する。
現場Requirementに応じて、どこまでAIへ任せるかを決める。
したがって、
Maximum Autonomy
ではなく、
Appropriate Autonomy
が重要になる。
⸻
Physical AIとEQUES
EQUESの現在地をこの巨大なTechnology領域全体と同一視してはならない。
同社がHumanoid Foundation Model全体を開発していると解釈するのは過剰である。
現在確認できる重要な方向は、原子力・廃炉などの高Risk EnvironmentにおけるRemote Robotics、AIによる認識・操作支援、高信頼化へ研究開発領域を広げていることである。
したがってEQUESにとってのPhysical AIは、
General-purpose Robot Company
になることより、
AIを高信頼Physical Operationへ実装するCapability
として読む方が適切である。
⸻
製薬AIからの連続性
ここでも製薬との連続性が見える。
製薬では、
Documentを認識する。
内容を生成する。
Consistencyを確認する。
Humanが承認する。
Physical AIでは、
Environmentを認識する。
Actionを生成する。
Safetyを確認する。
HumanまたはControl Systemが承認・監督する。
抽象化すれば、
Observe → Generate → Verify → Act
という同じ構造になる。
違うのは、最後のActがPhysical Worldへ作用することである。
⸻
SoftwareからRealityへ
Physical AIの本質は、Robotという新しいProduct Categoryだけではない。
AI Systemが、
Open-loop Information System
から、
Closed-loop Physical System
へ移ることである。
Environmentを観測する。
判断する。
Actionする。
Environmentが変わる。
再び観測する。
このLoopが高速に繰り返される。
AIがRealityからFeedbackを受けながら動くようになる。
⸻
EQUESにとっての次の境界
QAIではAIがEnterprise Documentへ入った。
JPharmatronではDomain Knowledgeへ入った。
JPharmaBenchではEvaluation Systemへ入った。
Energy AIではInfrastructure Dataへ入る。
廃炉ではRemote Robotへ接続する。
Physical AIでは、これらがさらに、
Sensor → Intelligence → Action
として統合される。
これはEQUESにとってTechnology領域の拡張であると同時に、責任範囲の拡張でもある。
AIのOutputがPhysical Actionへ近づくほど、
Safety。
Explainability。
Verification。
Auditability。
Human Supervision。
の重要性は増していく。
だからPhysical AIの次に問われるのは、単に「Robotをどこまで賢くできるか」ではない。
その判断を、人間と組織がどこまで理解し、検証し、責任を持って運用できるのか。
次節では、この問題を支えるもう一つの技術軸である説明可能AIと監査へ進む。
第5節 説明可能AIと監査
AIが企業の補助Toolとして使われている間は、「なぜその答えを出したのか」を完全に説明できなくても、HumanがOutputを確認することで運用できる場合がある。
しかし、AIが製薬、エネルギー、原子力、Infrastructure、Robotへ入るほど事情は変わる。
AIは何を見たのか。
どのDataから判断したのか。
どの程度確信していたのか。
Humanは何を確認したのか。
最終的に誰がActionを承認したのか。
問題が起きたとき、後から再現できるのか。
ここでは、単なるModel Accuracyを超えて、ExplainabilityとAuditabilityが必要になる。
EQUESが高い信頼性を要求される産業へAIを実装していくうえで、この二つは付加機能ではない。
AIを社会Systemの内部で運用可能にするための基盤である。
⸻
AIはなぜ説明しにくいのか
従来型Softwareでは、明示されたRuleによって処理が進む場合が多い。
条件Aなら処理B。
条件Cなら処理D。
Programを追えば、少なくとも設計上のLogicを確認できる。
Machine Learningは異なる。
大量のDataからParameterを学習し、その内部状態を通じてPredictionを生成する。
特にDeep Learningでは、数百万から数十億以上のParameterが複雑に作用する。
したがって、
Outputは得られるが、その理由を単純なRuleとして説明できない
という問題が生じる。
これがBlack Box問題である。
⸻
Explainabilityとは何を説明するのか
「AIを説明する」といっても、対象は一つではない。
なぜこのPredictionになったのか。
どのInputが重要だったのか。
どのDataでModelを作ったのか。
どの条件で性能が落ちるのか。
どの程度のConfidenceなのか。
Model Versionは何か。
誰がどの目的で使用しているのか。
これらはすべて異なる問いである。
したがってExplainabilityを一つのTechnologyで解決することはできない。
必要なのは、
説明の目的を先に定義すること
である。
⸻
Developerへの説明とOperatorへの説明
AI Developerが必要とする説明と、現場Operatorが必要とする説明も異なる。
Developerは、
Feature Importance。
Error Distribution。
Training Data。
Model Behavior。
を詳しく見たい。
一方、原子力施設のRemote Operatorが必要なのは、
どのObjectをAIが認識したのか。
どこにRiskを検出したのか。
Confidenceは十分か。
Actionしてよいのか。
といったOperational Informationである。
つまり、
Explainability must be role-specific.
説明可能性は、誰に説明するのかによって設計されなければならない。
⸻
説明と正しさは同じではない
ここには重要な注意点がある。
AIがもっともらしい説明を生成したからといって、Predictionが正しいとは限らない。
特にLLMは、自然なExplanationそのものを生成できる。
しかし、その文章が実際のModel Decision Processを忠実に表している保証はない。
したがって、
Plausible Explanation ≠ Faithful Explanation
である。
高信頼AIでは、「説明文が自然か」ではなく、Evidenceとの対応を確認する必要がある。
⸻
Evidenceを見せる
実務では、AIの内部ParameterすべてをHumanへ説明する必要はない。
むしろ、
どのDocumentを参照したのか。
どのSensorが異常だったのか。
Imageのどの領域を検出したのか。
どのRuleへ抵触したのか。
過去のどのCaseと対応するのか。
といったEvidenceを提示する方が有用な場合がある。
つまり、
Explain the model
だけでなく、
Show the evidence
である。
製薬でもPhysical AIでも、この考え方は共通する。
⸻
製薬におけるExplainability
例えばQAI Checkerが二つのDocument間に齟齬を発見したとする。
単に、
「矛盾があります」
と表示するだけではHumanは確認しにくい。
どのDocumentのどの記述と、
もう一方のどの記述が、
どの点で一致していないのか。
それを示せれば、Humanは原文へ戻って判断できる。
ここではExplainabilityが、
Human Verification Interface
として機能する。
AIの内部を完全に可視化することより、Humanが検証可能な形でOutputを提示することが重要になる。
⸻
Physical AIにおけるExplainability
Robotの場合はさらに具体的になる。
AIがObstacleを検出した。
どのObjectなのか。
どの位置なのか。
RobotとのDistanceはいくつか。
Collision Riskはどの程度か。
なぜ停止をRecommendationしたのか。
Human Operatorがこれらを理解できれば、AIの判断を監督しやすくなる。
つまり、
Perception → Evidence → Human Decision
というInterfaceを設計する。
ExplainabilityはHuman–AI Collaborationの一部である。
⸻
Uncertaintyを表示する
AIは常に同じ確信度で判断しているわけではない。
明確なObject。
曖昧なObject。
Training Dataに近いSituation。
未知のSituation。
それらを同じ「正解」として表示すると危険である。
そこでConfidenceやUncertaintyをHumanへ伝える。
例えば、
High Confidence。
Review Required。
Unknown。
といった状態へ変換する。
重要なのは細かなProbabilityそのものではなく、
HumanがActionを変えるために利用できるUncertainty Representation
である。
⸻
「分からない」をSystemへ組み込む
高信頼AIでは、
Abstention
が重要になる。
AIが十分なConfidenceを持てない場合には、自動的なDecisionを行わない。
HumanへEscalationする。
追加Dataを要求する。
別のModelで再確認する。
SystemをSafe Stateへ移す。
これは能力不足ではない。
適切なRisk Managementである。
Always answer
するAIより、
Know when not to answer
できるAIの方が、高Risk Environmentでは信頼できる場合がある。
⸻
ExplainabilityからTraceabilityへ
説明できても、後から何が起きたか分からなければAuditはできない。
そこでTraceabilityが必要になる。
どのUserが利用したか。
いつ実行したか。
どのInputだったか。
どのModel Versionだったか。
どのPromptやConfigurationだったか。
どのExternal Dataを参照したか。
どのOutputが生成されたか。
Humanが何を修正したか。
何を承認したか。
これらを記録する。
構造は、
Input → Model → Output → Human Action
を時間軸に沿って保存することである。
⸻
Audit Log
この記録をSystematicに残すものがAudit Logである。
高信頼AIでは、
AIが何をしたか。
Humanが何をしたか。
Systemが何をしたか。
を区別して記録する必要がある。
例えば、
AI proposed.
Human reviewed.
Human approved.
System executed.
というProcessが残る。
これによって、AIとHumanのResponsibility Boundaryが明確になる。
⸻
Auditは監視だけではない
Auditという言葉には、誰かを監視する印象がある。
しかしAI SystemにおけるAuditの目的はそれだけではない。
Failure Analysis。
Quality Improvement。
Compliance。
Security Investigation。
Model Evaluation。
Workflow Improvement。
にも利用できる。
つまりAudit Logは、
Accountability Infrastructure
であると同時に、
Learning Infrastructure
でもある。
⸻
Model Versionを残す
AI Systemは更新される。
Model AからModel Bへ変更する。
Promptを変更する。
RAGのKnowledge Baseを更新する。
Inference Parameterを変更する。
すると、同じInputでもOutputが変わる可能性がある。
そのため、
「AIを使った」
という記録だけでは足りない。
Which AI?
を記録する必要がある。
Model Version。
Configuration。
Knowledge Version。
Software Version。
これらを保存して初めて、過去のDecisionを再構成できる。
⸻
Data Lineage
さらに重要なのがData Lineageである。
AIがどのDataを利用したのか。
そのDataはどこから来たのか。
いつ更新されたのか。
誰が作成したのか。
どのTransformationを経たのか。
を追跡する。
高信頼AIでは、
Output Provenance
だけでなく、
Input Provenance
も必要になる。
誤ったDataから正しいDecisionを期待することはできないからである。
⸻
RAGにも監査が必要になる
RAGを利用すると、AIは外部Knowledgeを検索して回答を作る。
その場合、
どのDocumentを取得したのか。
どのVersionだったのか。
どのChunkを参照したのか。
検索Scoreはどうだったのか。
を記録できれば、Outputを検証しやすくなる。
これは製薬AIで特に重要である。
最新SOPを使ったのか。
古いDocumentを参照していないか。
権限のない情報を取得していないか。
RAGはAccuracy Technologyであると同時に、Governanceの対象でもある。
⸻
Access Controlとの接続
AuditabilityはIdentityとAuthorizationにも接続する。
誰がAIを使えるのか。
誰がどのDataを読めるのか。
誰がModelを変更できるのか。
誰がProductionへDeployできるのか。
誰がAI Outputを承認できるのか。
ここを分離する。
つまり、
Identity → Permission → Action → Audit
という構造を作る。
高信頼AIはModelだけではなくEnterprise Security Architectureの内部で動く。
⸻
Human Approval
高RiskなActionでは、AIが生成した結果をそのまま実行しない。
Human Approvalを置く。
ただし、「Humanが確認する」という一文だけでは不十分である。
何を見るのか。
どのEvidenceを見るのか。
何秒・何分で判断するのか。
Rejectできるのか。
修正できるのか。
責任者は誰か。
を設計する必要がある。
Human ApprovalそのものもEngineeringの対象である。
⸻
Rubber Stamp Problem
Human Approvalが存在しても、実質的に機能しない場合がある。
AI Outputが大量に届く。
毎回正しいように見える。
Humanが徐々に確認しなくなる。
最終的にApprove Buttonを押すだけになる。
これはAutomation BiasやRubber Stampの問題につながる。
したがって、
Human-in-the-loop ≠ Safe by default
である。
Humanが本当に判断できる量、時間、Evidenceを設計しなければならない。
⸻
Riskに応じて承認Levelを変える
すべてのAI Outputを同じ方法でReviewする必要もない。
低RiskならAutomatic Processing。
中RiskならHuman Review。
高Riskなら複数人Approval。
CriticalならAIの自動Action自体を禁止する。
というように、
Risk-based Governance
を設計できる。
これはAI導入を止めるためではない。
Riskの低い部分ではAutomationを進め、高い部分ではControlを強めるためである。
⸻
ExplainabilityとAuditabilityの違い
ここまでを整理すると、二つは明確に異なる。
Explainabilityは、
Why did the AI do this?
に答える。
Auditabilityは、
What happened, when, by whom, and with which system?
に答える。
前者はDecision Understanding。
後者はProcess Reconstruction。
高信頼AIには両方が必要になる。
⸻
Safety Caseという考え方
高Risk Systemでは、単に「安全です」と主張するだけでは足りない。
どのRiskを想定したか。
どのControlを設けたか。
どのTestを行ったか。
どのEvidenceによって安全性を説明するか。
を体系化する必要がある。
これはSafety Caseという考え方に近い。
AIでも、
Claim → Evidence → Argument
によって、なぜこのSystemをこの用途で使用できるのかを説明する方向が重要になる。
⸻
Continuous Audit
AIは一度認証すれば永遠に同じSystemではない。
Modelが更新される。
Dataが変わる。
Environmentが変わる。
User Behaviorが変わる。
したがってAuditも一回限りでは足りない。
Productionで継続的に、
Performance。
Error。
Drift。
Security Event。
Human Override。
を観測する。
つまり、
Pre-deployment Audit
から、
Continuous Assurance
へ進む。
⸻
高信頼AIは記憶を持つSystemである
ここまでを見ると、Audit Logは単なる記録ではない。
SystemのMemoryである。
何を見たか。
何を判断したか。
何を実行したか。
何が成功したか。
何が失敗したか。
それを保持する。
Memoryがあれば、過去のFailureを次のEvaluationへ戻せる。
つまり、
Audit → Feedback → Improvement
というLoopが成立する。
⸻
EQUESにとっての意味
EQUESが製薬や原子力のような高信頼領域へ進むなら、競争力はModel性能だけでは形成されない。
必要になるのは、
Domain Understanding。
Evaluation。
Explainability。
Human Approval。
Traceability。
Security。
Auditability。
というSystem Capabilityである。
これはQAI Checker、JPharmaBench、Physical AIという一見異なる取り組みを、一つの方向へ接続する。
生成する能力だけでなく、検証できる能力を持つこと。
EQUESの事業を理解する重要な軸である。
⸻
信頼は説明だけでは成立しない
最終的に、Trusted AIは「説明できるAI」と同義ではない。
説明できる。
測定できる。
追跡できる。
止められる。
Humanが介入できる。
Failureを記録できる。
改善できる。
これらが重なって初めて、社会Systemの内部で継続利用できる。
最小化すれば、
Explain
→ Verify
→ Approve
→ Execute
→ Record
→ Audit
→ Improve
となる。
信頼とはModelの属性ではない。
System全体の運用によって形成される性質である。
⸻
Physical AIが現実世界へ接触するほど、この構造の重要性は高くなる。
しかし、AIが扱うPhysical Problemを解く方法はMachine Learningだけではない。
大量の選択肢から最適な組合せを探す問題には、数理最適化がある。
そして現在、その計算方法そのものを拡張しようとする研究領域としてQuantum Computingが存在する。
次節では、EQUESのもう一つの技術Frontierである量子コンピューティングへ進み、AI、Optimization、Classical Computingとの関係を、現在可能なことと将来可能性を分けながら見ていく。
第6節 量子コンピューティング
EQUESをAIスタートアップとして見ると、量子コンピューティングは一見すると少し離れた領域に見える。
しかし、EQUES自身は2026年時点で事業領域を「伴走型技術開発」「製薬AI」「エネルギーAI」「量子コンピュータ」の四つとして紹介している。量子は単なる将来構想ではなく、NEDOのQuantum Computing Challengeへの採択と具体的な研究開発を伴う、新しい事業・研究領域として位置づけられている。(EQUES)
重要なのは、「AIの次は量子」という単純な技術進化として読むことではない。
EQUESが向き合っているのは、より一般的な問いである。
現実の複雑な問題に対して、どの計算方法を選べば、より良い解へ到達できるのか。
Machine Learningも、数理最適化も、量子計算も、そのための異なるComputational Methodなのである。
⸻
AIと量子コンピュータは同じものではない
まず境界を明確にしておく必要がある。
AIとQuantum Computingは別のTechnologyである。
AIは、DataからPatternを学習し、Prediction、Generation、Recognition、Decision Supportなどを行う。
Quantum Computingは、量子力学的な性質を利用して計算を行うComputing Paradigmである。
したがって、
AI ≠ Quantum Computing
である。
両者が接続する可能性はあるが、「量子AI」という言葉だけで一体化して理解すべきではない。
⸻
Classical Computingという基盤
現在のAIはほぼすべてClassical Computer上で動いている。
CPU。
GPU。
Accelerator。
Cloud。
Data Center。
Edge Device。
LLMもDeep Learningも、この巨大なClassical Computing Infrastructureによって支えられている。
したがって量子コンピュータを考えるときも、
Classical Computingを置き換えるもの
と最初から考える必要はない。
むしろ、
Classical Computing + Quantum Computing
というHybridな構造から考える方が現実的である。
⸻
なぜ量子計算が注目されるのか
現実の産業には、計算量が急速に増大するProblemが存在する。
候補が十個なら探索できる。
百個になる。
千個になる。
さらにConstraintが増える。
組合せ数が爆発する。
このような問題では、すべての候補を単純に試すことは現実的でなくなる。
そこで、
Combinatorial Optimization
が重要になる。
どの組合せを選べば最も良いのか。
量子計算は、こうしたProblem Classに対する新しい計算手段として研究されている。
⸻
EQUESが選んだProblem
EQUESの量子研究で興味深いのは、最初から抽象的なQuantum Benchmarkだけを追っているわけではないことである。
同社はNEDOの「量子コンピュータを用いた社会問題ソリューション開発」に採択され、多剤耐性菌――MDRO――に対する新しい治療戦略を研究している。(EQUES)
ここで再び、EQUESの既存Domainである製薬・医療と接続する。
Pharmaceutical / Medical Problem × Optimization × Quantum Computing
である。
⸻
多剤耐性菌という問題
抗菌薬を使用し続けると、薬剤への耐性を持つ菌が選択される可能性がある。
複数の抗菌薬へ耐性を持つ多剤耐性菌は、感染症治療における重大な課題となる。
EQUESの研究では、病原体を直接「殺す」ことだけではなく、病原体が必要とする栄養素を常在菌側に消費させ、増殖しにくいEnvironmentを作るNutrient Blockingという方向が検討されている。(EQUES)
ここで重要になるのが、
どの常在菌を組み合わせるか
という問題である。
⸻
組合せ爆発
候補となる細菌が増えると、その中から複数種を選ぶ組合せ数も急速に増える。
さらに、
どの栄養素を消費するか。
病原体とどう競合するか。
細菌同士がどう相互作用するか。
といったConstraintを考える必要がある。
するとProblemは、
Best Combination Search
になる。
EQUESはこの部分をQuantum Optimizationの対象としている。NEDO採択時には量子アニーリング等の利用を含む構想を公表し、その後の研究では量子ネイティブなXY-QAOAを用いて常在菌コンソーシアムの選択を行っている。(EQUES)
⸻
QAOA
QAOAはQuantum Approximate Optimization Algorithmの略である。
組合せ最適化Problemに対して、Quantum CircuitとClassical Optimizationを組み合わせながら良いSolutionを探索するVariational Quantum Algorithmの一つである。
重要なのは、
Quantumだけですべてを計算する
わけではないことである。
概念的には、
Classical Computer
⇄ Quantum Circuit
という反復が行われる。
ここでもHybrid Computingが現れる。
⸻
XY-QAOAへの具体化
EQUESが2026年6月のQuantinuum Symposiumで発表した研究では、肺炎桿菌 Klebsiella pneumoniae の腸内定着を抑制する常在菌群の設計に、XY-QAOAを統合したSimulation Frameworkが示された。
公表内容では、最適な五種の常在菌Consortiumを選択し、導入条件を変えたSimulationでも病原体を設定閾値以下へ抑える結果が得られたとしている。(EQUES)
ここで量子計算は、治療そのものを行っているわけではない。
候補を選ぶOptimization Layer
を担っている。
この役割分担は重要である。
⸻
Quantumが答え、AIが実行するわけではない
量子コンピュータについては、Technologyの役割を誇張しやすい。
量子計算が「新しい治療法を自動的に発見する」わけではない。
Problemを定義する。
Dataを用意する。
Objective Functionを決める。
Constraintを設計する。
Quantum Algorithmを実行する。
得られた候補をSimulationする。
さらに実験・臨床研究によって検証する。
多数のProcessが必要になる。
したがって、
Quantum Output ≠ Medical Evidence
である。
Computational ResultとBiomedical Validationは明確に区別しなければならない。
⸻
量子優位を断定しない
さらに重要な境界がある。
特定の量子Algorithmを使用したことと、Classical Computingより実用上優れていることは同じではない。
速度。
精度。
Cost。
Scalability。
Noise。
Hardware Availability。
Problem Size。
比較条件によって結果は変わる。
したがってEQUESの研究も、
Quantum Advantageが確立した
と読むのではなく、
社会Problemに対してQuantum Optimizationがどこまで有効かを具体的に検証している
と読むのが適切である。
これは同社の「研究と実践をつなぐ」という企業姿勢とも整合する。(EQUES)
⸻
Classical Baselineが必要になる
Quantum Algorithmを評価するには、比較対象が必要になる。
Exact Solver。
Heuristic。
Metaheuristic。
Classical Optimization。
その他のApproximation Algorithm。
同じProblemをClassical Methodでも解き、
Solution Quality。
Computation Time。
Resource Requirement。
Scalability。
を比較する。
そこで初めて、
Why Quantum?
という問いへ答えられる。
量子を使うこと自体を目的にしない。
Problemに対して最も適したMethodを選ぶ。
これはEQUESの量子研究を評価するときの重要な基準になる。
⸻
Optimizationという共通言語
ここで、EQUESが以前から扱ってきた数理最適化と量子計算が接続する。
Optimization Problemでは、
Objective。
Variable。
Constraint。
Solution Space。
を定義する。
これはClassical OptimizationでもQuantum Optimizationでも共通する。
したがって、長期的に価値を持つのは特定Hardwareの操作Knowledgeだけではない。
現実のProblemを計算可能なOptimization Problemへ翻訳する能力
である。
⸻
Domain KnowledgeがなければProblemを作れない
量子Computerが高性能になっても、何を解かせるかを定義できなければ価値は生まれない。
どの細菌をCandidateにするのか。
何をObjectiveにするのか。
どのConstraintを置くのか。
何を「良いSolution」と定義するのか。
ここにはBiologyやMedicineのDomain Knowledgeが必要になる。
つまり、
**Domain Expert
* Optimization Engineer
* Quantum Engineer**
というTeamが必要になる。
量子コンピューティングもまた、Technology単独では社会実装できない。
⸻
製薬AIとの意外な接続
ここで第Ⅲ部と第Ⅳ部が再び接続する。
製薬AIでは、
Document。
Knowledge。
LLM。
Benchmark。
を扱った。
量子研究では、
Microbiome。
Optimization。
Simulation。
Quantum Algorithm。
を扱う。
Technologyは大きく異なる。
しかしDomainは重なる。
Pharmaceutical / Healthcare
である。
つまりEQUESは、一つのIndustry Problemに対して一種類のTechnologyだけを当てるのではなく、
LLM。
Machine Learning。
Optimization。
Quantum Computing。
という異なるComputational Methodを選択できる方向へ広がっている。
⸻
AI × Quantumをどう考えるか
AIとQuantum Computingの接続には複数の方向がある。
AIによってQuantum Circuit DesignやParameter Optimizationを支援する。
Quantum AlgorithmをMachine Learningへ利用する。
LLMをQuantum DevelopmentのInterfaceとして利用する。
Optimization Pipelineの一部だけをQuantumへ移す。
しかし2026年時点では、これらすべてが成熟したIndustrial Standardになっているわけではない。
EQUES自身も2025年には「生成AIと量子コンピューティングの応用」をテーマに外部講演を行い、融合領域を探索している。(EQUES)
ここは完成したTechnology Stackというより、Research Frontierとして見るべき領域である。
⸻
Quantum ComputingもToolになる
もし量子HardwareとAlgorithmが成熟すれば、Software EngineerがQuantum Physicsのすべてを意識せずに利用できるLayerが整備される可能性がある。
Cloud API。
Optimization Service。
SDK。
Compiler。
Hybrid Solver。
その場合、量子Computerは特殊な研究装置から、
Specialized Compute Resource
へ近づく。
GPUがAI計算を支えるように、特定ProblemにQuantum Processing Resourceを利用する。
ただし、そこへ至る速度や適用範囲には不確実性がある。
⸻
Heterogeneous Computing
将来のComputing Systemを一種類のProcessorで考える必要はない。
CPU。
GPU。
Edge Accelerator。
Specialized Hardware。
Quantum Processor。
それぞれ得意なTaskを担当する。
すると、
Problem
→ Task Decomposition
→ Appropriate Compute
というArchitectureになる。
これはHeterogeneous Computingである。
AI Systemは「どのModelを使うか」だけでなく、
どの計算資源で解くか
まで選択するようになる可能性がある。
⸻
量子はPhysical AIとも無関係ではない
本節の量子研究は現在、MDROという医療・製薬Problemを中心に具体化されている。
しかしより一般的にOptimizationという観点から見ると、
Robot Planning。
Scheduling。
Resource Allocation。
Network Optimization。
Energy Management。
など、Physical Systemにも多数の組合せ最適化Problemが存在する。
したがって、
Physical AI
と、
Advanced Computing
は将来的に接続可能な領域である。
ただし、EQUESがこれらすべてを量子計算で実装していると解釈してはならない。
現在の研究成果と将来Architectureは明確に分ける必要がある。
⸻
量子研究を持つStartupの意味
Startupにとって、まだ市場が成熟していないTechnologyへ研究資源を投入することにはRiskがある。
短期的なRevenueへ直接つながらない可能性もある。
一方で、Technology Transitionが起きたときに内部Capabilityを持っていれば、早い段階でApplicationを構築できる。
つまり量子研究は、
Current Business
だけではなく、
Future Technical Capability
へのInvestmentとして読むことができる。
⸻
NEDOがRiskを分担する
こうしたFrontier Researchでは、公的研究開発支援の意味が大きい。
EQUESは2025年12月、NEDOのQuantum Computing ChallengeのScreeningを通過し、MDROに対する量子最適化研究へ進んだ。2026年には研究成果を外部発表する段階まで進めている。(EQUES)
構造としては、
Public R&D Support
→ Startup Research
→ Experimental Application
→ Evaluation
→ Possible Industrialization
となる。
まだMarketが形成されていないTechnologyのRiskを、企業だけに負わせない仕組みである。
⸻
ResearchをResearchのまま終わらせない
EQUESの企業Missionは、研究と実務現場をつなぐことに置かれている。(EQUES)
その観点から量子研究を見ると、最終的な問いは、
「高度なQuantum Algorithmを実装できたか」
だけではない。
現実のProblemに対して、従来より良いSolutionを提供できるのか。
である。
これは同社がMachine Learningで行ってきたことと同じである。
⸻
技術ではなくProblemから始める
EQUESの量子研究から抽出できる重要な原則は、Technologyから始めないことである。
「Quantum Computerがある。何に使おうか」
ではなく、
「この社会Problemには巨大な組合せ探索がある。どのComputational Methodが有効か」
と考える。
つまり、
Technology-first
ではなく、
Problem-first
である。
AIについても同じである。
LLMを使うことが目的ではない。
Robotを使うことが目的ではない。
Quantumを使うことが目的ではない。
より良い解を社会へ実装すること
が目的になる。
⸻
EQUESのTechnology Portfolio
ここまで来ると、EQUESが扱うTechnology群を一つの階層で整理できる。
LanguageやKnowledgeには、
LLM / Generative AI
がある。
Pattern Recognitionには、
Machine Learning / Deep Learning
がある。
Physical Environmentには、
Computer Vision / Robotics / Physical AI
がある。
複雑な意思決定には、
Mathematical Optimization
がある。
そして特定の計算Problemに対する新しい探索手段として、
Quantum Computing
がある。
重要なのはTechnologyの数ではない。
それぞれをProblemに応じて選択できることにある。
⸻
「AI企業」から「Computational Engineering企業」へ
ここから、EQUESをもう少し広く読むことができる。
同社は依然としてAIを中心とするStartupである。
しかし、
Machine Learning。
LLM。
Optimization。
Robotics。
Quantum Computing。
まで扱うなら、その能力は徐々に、
AI Development
だけでは説明しきれなくなる。
より一般化すれば、
高度な計算技術を現実の産業Problemへ翻訳するComputational Engineering
という方向が見えてくる。
これは現時点の公式な企業分類ではなく、本書から導く分析である。
しかし、同社のTechnology Portfolioを理解するには有効な視点である。
⸻
量子コンピューティングの現在地
量子コンピューティングは、未来の万能Computerではない。
少なくとも2026年時点では、
Classical Computing。
Quantum Hardware。
Algorithm。
Error。
Scalability。
Cost。
Application。
のすべてについて研究と検証が続いている。
だからこそ重要なのは、期待を膨らませることではなく、
どのProblemで、どのAlgorithmを、何と比較し、どの程度の価値が得られるのか
を一つずつ検証することである。
EQUESのMDRO研究は、その具体的な一例として位置づけることができる。
⸻
PhysicalとComputationalという二つのFrontier
ここまで第Ⅳ部では二つの境界を見てきた。
一つは、
Digital → Physical
である。
Energy。
原子力。
Remote Robotics。
Physical AI。
もう一つは、
Classical Computing → New Computational Methods
である。
Optimization。
Hybrid Computing。
Quantum Computing。
この二つは別々のTechnology Trendではある。
しかしEQUESという企業を通して見ると、一つの方向へ収束する。
より難しい現実Problemを解くために、AIの対象と計算手段の双方を拡張する。
という方向である。
⸻
次の境界
第Ⅲ部の製薬AIでは、AIはDocumentとKnowledgeを扱った。
第Ⅳ部では、
Document → Sensor → Robot → Physical Environment
へ対象が広がった。
同時に計算側では、
Machine Learning → Optimization → Quantum
へ選択肢が広がった。
これらを統合すると、
Real-world Problem
→ Measurement / Data
→ AI / Optimization
→ Appropriate Compute
→ Human Decision
→ Physical or Digital Action
というArchitectureが現れる。
AIはSoftwareの中だけに存在するものではなくなり始める。
そしてComputingも、一種類のMachineだけで完結するものではなくなり始める。
次節では第Ⅳ部を総括し、EQUESのTechnology Expansionを、**「デジタルから物理世界へ」**という一つの企業変化として読み解く。
第7節 デジタルから物理世界へ
EQUESの事業を創業時点から追うと、一つの重要な拡張が見えてくる。
最初に中心となったのは、Machine LearningやDeep Learningを企業課題へ適用する技術開発だった。
そこから生成AI、LLM、RAGへ進み、製薬では品質保証Documentや専門Knowledgeを扱うようになった。
さらにEnergyへ進むと、対象はSensor Data、設備、Infrastructureへ広がる。
原子力・廃炉ではRobotとRemote Operationが加わる。
そして量子コンピューティングでは、現実の複雑なProblemを解くための計算方法そのものへ探索領域が広がる。
これは単なる事業領域の追加ではない。
EQUESが扱う「現実」の範囲が変化しているのである。
⸻
最初のAIはDataの中にいた
Machine Learningの基本構造は比較的明快である。
Dataを集める。
Modelへ入力する。
Patternを学習する。
Predictionする。
概念的には、
Data → Model → Output
である。
ここではAIが扱う対象はDigital Representationである。
ImageもTextもSensor値も、Computerの中ではDataとして扱われる。
AIはData Spaceの内部で高い能力を獲得してきた。
⸻
LLMはKnowledgeへ広がった
生成AIとLLMによって、AIが扱える対象は大きく広がった。
Document。
Manual。
Report。
Regulation。
Research Paper。
Enterprise Knowledge。
HumanがLanguageとして蓄積してきた大量のKnowledgeをAIが利用できるようになった。
EQUESの製薬AIは、この変化を典型的に示している。
QAI Generator。
QAI Checker。
JPharmatron-7B。
JPharmaBench。
これらは異なるTechnologyではあるが、共通して、
Human KnowledgeをComputational Systemへ接続する
方向にある。
⸻
DocumentからWorkflowへ
しかし、Documentを生成できるだけでは社会実装にはならない。
AIが生成する。
Humanが確認する。
既存Systemへ登録する。
別のDocumentとConsistencyを確認する。
履歴を残す。
Auditできるようにする。
そこでAIは、
Document Tool
から、
Enterprise Workflow
の一部へ移る。
この段階で、AIは単独ApplicationではなくOrganizational Systemになる。
⸻
WorkflowからInfrastructureへ
Energy AIでは、さらに境界を越える。
InputがDocumentだけではなくなる。
Temperature。
Pressure。
Vibration。
Image。
Sound。
Equipment State。
Physical Environmentから継続的にDataが入ってくる。
つまり、
Stored Data
から、
Living Data Stream
へ変わる。
AIは過去のDataを読むだけではなく、現在進行しているPhysical Systemを観測するようになる。
⸻
SensorはPhysical Worldへの入口である
AIはPhysical Worldを直接見ることができない。
必ずSensorを介する。
Camera。
LiDAR。
Microphone。
Force Sensor。
Temperature Sensor。
Radiation Detector。
SensorはRealityをMeasurementへ変換する。
したがって、
Physical World
→ Measurement
→ Data
→ AI
という境界が存在する。
Physical AIでは、この入口の品質がSystem全体を左右する。
⸻
AIからPhysical Actionへ
さらにRobotが接続されると、方向が逆転する。
Physical WorldからDataを受け取るだけではない。
AIのDecisionがMachineを通じてPhysical Worldへ戻る。
Physical World
→ Sensor
→ AI
→ Robot
→ Physical World
となる。
ここで初めて完全なFeedback Loopが形成される。
AIはRealityを観測するだけではなく、Realityへ作用する。
⸻
Open LoopからClosed Loopへ
これはAI Architectureにとって大きな転換である。
一般的な生成AIでは、
Prompt。
Generation。
Human Review。
で一つのTaskが終了する場合がある。
Physical AIでは終了しない。
Environmentを観測する。
Actionする。
Environmentが変わる。
再び観測する。
再びActionする。
つまり、
Observe → Decide → Act → Observe
が連続する。
AIはClosed Loop Systemへ入る。
⸻
Feedbackの意味が変わる
LLMではFeedbackは、
Good / Bad。
Human Rating。
Correction。
といったDigital Feedbackであることが多い。
Physical AIではRealityそのものがFeedbackを返す。
RobotがObjectを掴めたか。
移動できたか。
Collisionしたか。
Equipment Stateが改善したか。
Taskが完了したか。
つまり、
Action → Physical Result → Measurement
がFeedbackになる。
現実世界がAI SystemのEvaluation Environmentになる。
⸻
Physical Worldは曖昧である
Digital SystemではInput Formatを定義できる。
しかしPhysical Environmentは完全には制御できない。
Lightingが変わる。
Temperatureが変わる。
Objectが移動する。
Humanが入る。
Sensorが劣化する。
Noiseが発生する。
未知のSituationが起きる。
したがってPhysical AIでは、
Expected Environment
だけではなく、
Unexpected Environment
への対応が重要になる。
⸻
Robustnessが中心になる
このため、Physical AIでは平均Accuracyだけを見ることができない。
通常状態では99％正しい。
しかしRare Conditionで大きく失敗する。
それではSafety-criticalな用途には使えない場合がある。
必要なのは、
Noise。
Distribution Shift。
Sensor Failure。
Network Failure。
Unknown Object。
などに対するRobustnessである。
つまり評価対象が、
Model Performance
から、
System Behavior
へ広がる。
⸻
Software Engineeringだけでは足りない
Digital AIなら、ModelとCloud Applicationを中心にSystemを作れる場合がある。
Physical AIでは、
Mechanical Engineering。
Electrical Engineering。
Control Engineering。
Communication。
Sensor Engineering。
Robotics。
Safety Engineering。
Human Factors。
が関係する。
AI EngineerだけでSystem全体を作ることは難しい。
ここでもEQUESに必要になるのは、一つのTechnologyを所有することではなく、
異なるEngineering Domainを接続する能力
である。
⸻
HumanもPhysical Systemの一部である
Physical AIではHumanを外部Observerとして扱うこともできない。
OperatorがRobotを操作する。
EngineerがMaintenanceする。
Domain ExpertがAI Outputを確認する。
Safety ManagerがOperation Ruleを決める。
Human BehaviorそのものがSystem Performanceへ影響する。
したがって、
Human + AI + Machine + Environment
を一体として設計する必要がある。
⸻
自律化だけを目的にしない
Physical AIという言葉から、完全自律Robotを想像しやすい。
しかし産業実装では、Autonomyを最大化することが常に最適とは限らない。
Humanが操作した方が安全な部分。
AIが支援した方が効率的な部分。
Machineへ完全に任せられる部分。
独立したSafety Systemが監視すべき部分。
これらを分ける。
重要なのは、
Maximum Automation
ではなく、
Appropriate Automation
である。
⸻
DigitalとPhysicalをつなぐEdge
Cloud AIとPhysical Machineの間にはEdgeがある。
Robot。
Industrial PC。
Local Server。
Embedded Device。
ここでLow-latencyなInferenceやSafety Processingを行う。
一方、Cloudでは、
Large-scale Training。
Long-term Data Analysis。
Knowledge Management。
Fleet Management。
を行う。
したがってPhysical AIのInfrastructureは、
Cloud ⇄ Edge ⇄ Machine ⇄ Environment
という階層になる。
⸻
Digital Twinという中間層
Physical WorldとAIを直接接続するだけでなく、その間にDigital Representationを置く方法もある。
Equipment State。
Environment Map。
Robot Position。
Maintenance History。
Simulation Model。
これらを統合すれば、Physical AssetのDigital Representationを構築できる。
ここからDigital Twinという方向が見えてくる。
ただし、EQUESがDigital Twin Platform全体を完成させているという意味ではない。
Technology Architectureとして、
Physical ↔ Digital Representation
が重要になるということである。
⸻
SimulationとReality
Physical AIでは、Realityだけで学習することはCostが高い。
そこでSimulationを使う。
大量のSituationを生成する。
失敗する。
Rare Eventを再現する。
Robot Policyを評価する。
しかし最終的にはRealityへ戻らなければならない。
Simulation → Physical Verification
である。
この往復によってAIは徐々に現場へ適応する。
⸻
Computational Frontierとの接続
本章ではもう一つ、Quantum Computingという方向も見た。
Physical AIとQuantum Computingは同じTechnologyではない。
しかし共通するものがある。
どちらも、
現実の複雑なProblemを計算可能な形へ変換する
ことである。
Physical AIではEnvironmentをDigital Representationへ変換する。
Optimizationでは現実のDecision ProblemをObjectiveとConstraintへ変換する。
Quantum Computingでは、そのProblemに新しいComputational Methodを適用する。
つまり、
Reality → Representation → Computation → Decision
という共通構造がある。
⸻
Technologyを目的にしない
ここでEQUESの事業を理解するうえで重要な原則が見える。
LLMを使うこと。
Robotを使うこと。
Quantum Computerを使うこと。
それ自体が目的ではない。
まずProblemがある。
そのProblemを理解する。
必要なDataを定義する。
適切なTechnologyを選ぶ。
現場へ実装する。
結果を評価する。
必要ならTechnologyを変更する。
つまり、
Problem → Technology Selection
であり、
Technology → Find a Problem
ではない。
⸻
一つの企業に複数のTechnologyが必要になる理由
製薬と原子力は全く異なるIndustryに見える。
LLMとRobotとQuantum Computingも異なるTechnologyである。
しかし現実のProblemは、Technology Categoryごとに分かれて存在しているわけではない。
一つのProblemの中に、
Language。
Image。
Sensor。
Optimization。
Human Decision。
Physical Action。
が同時に存在する。
したがって社会実装企業には、
Technology Stackを横断する能力
が必要になる。
⸻
EQUESの拡張をどう読むか
EQUESの2022年から2026年までを、単純な事業多角化として読むこともできる。
しかし別の読み方ができる。
最初は、
AI Modelを作る会社
だった。
次に、
AIをEnterprise Workflowへ入れる会社
になる。
さらに、
AIをHigh-reliability Industryへ入れる会社
へ進む。
そして現在、
AIをPhysical Environmentへ接続する会社
へ能力領域を広げつつある。
この変化は、企業規模の拡大以上に重要である。
⸻
責任範囲も広がる
Technology Capabilityが広がれば、Responsibilityも広がる。
Document Generationなら、Humanが最終確認できる。
Infrastructure Monitoringでは、見逃しが問題になる。
Robot Operationでは、Physical Actionが発生する。
したがって、
Capability ↑ → Required Assurance ↑
となる。
AIがRealityへ近づくほど、
Evaluation。
Explainability。
Audit。
Security。
Safety。
Human Supervision。
が重要になる。
これはEQUESのTechnology ExpansionとGovernance Expansionが同時に進まなければならないことを意味する。
⸻
DigitalからPhysicalへ、しかしDigitalを捨てるわけではない
Physical AIへ進むことは、LLMやCloudを捨てることではない。
むしろ、それらが統合される。
LLMがManualを読む。
Knowledge Baseから過去事例を取得する。
Sensor AIが現在状態を認識する。
OptimizationがAction候補を比較する。
RobotがPhysical Actionを行う。
Humanが監督する。
Audit LogがProcessを記録する。
つまり、
Digital Intelligence + Physical Intelligence
である。
⸻
EQUESの技術体系
ここまでを最小化すると、EQUESの技術的な広がりは次のように整理できる。
Knowledge
LLM / RAG / Domain AI
↓
Decision
Machine Learning / Optimization
↓
Observation
Vision / Sensor / Multimodal AI
↓
Execution
Robot / Remote Operation / Physical AI
↓
Computation
Cloud / Edge / Classical / Quantum
↓
Assurance
Evaluation / Explainability / Audit / Human Supervision
これらは別々の事業ではなく、将来的には一つのIndustrial AI Architectureとして接続可能である。
⸻
研究からRealityまで
第Ⅰ部では、EQUESが松尾研から生まれたResearch-oriented Startupであることを見た。
第Ⅱ部では、そのResearchを企業課題へ翻訳する伴走型開発を見た。
第Ⅲ部では、製薬というHigh-reliability Domainで、
Model → Evaluation → Product → Workflow
を構築する過程を見た。
そして第Ⅳ部では、その対象が、
Document → Infrastructure → Sensor → Robot → Physical Environment
へ拡張していることを確認した。
EQUESの企業像は、ここで大きく変わる。
ResearchをSoftwareへ変換するだけではない。
Softwareを現場へ接続する。
現場からDataを取得する。
AIで理解する。
HumanとMachineのActionへ戻す。
その結果を再びDataとして取得する。
最小構造は、
Research
→ Digital System
→ Physical System
→ Operation
→ Feedback
である。
⸻
Physical Worldの次にあるもの
しかし、Technologyが現実世界へ届いても、それだけでは社会実装は完成しない。
AIを使うのはHumanである。
導入を決めるのはOrganizationである。
運用を続けるのもOrganizationである。
どれほど優れたAIでも、現場の人間が理解できず、業務Processへ組み込まれず、Knowledgeが共有されなければ定着しない。
したがってEQUESの次の境界は、DigitalとPhysicalの間ではない。
TechnologyとHuman Organizationの間にある。
第Ⅴ部では、AI×DX寺子屋、人材育成、企業への導入支援を通じて、EQUESがAIを「作る」だけでなく、人と組織の内部へどのように定着させようとしているのかを見ていく。
愛と敬意を込めてmandala
