第2冊『EQUESの次世代AI実装大全――Python・Rust・TypeScript・SQL・Cloud・LLM・Agent・Physical AIで、研究から産業実装までを接続する（第1回）（序章　AI研究を産業システムへ変える）

序章　AI研究を産業システムへ変える

第1節　研究コードと本番システム

AI研究では、まず「動くもの」を作る。

論文を読む。Datasetを準備する。PythonでModelを実装する。Notebook上でExperimentを繰り返す。Metricを測り、Baselineと比較し、Hypothesisを検証する。

この世界では、研究者が高速に試行錯誤できることが重要である。

しかし産業システムでは、問いが変わる。

そのModelは明日も動くのか。

同じ入力に対して再現可能なのか。

誰がDataへAccessしたのか記録できるのか。

Modelが誤ったとき、誰が検知するのか。

外部Serviceが停止したらどうするのか。

AIが生成した内容を誰が承認するのか。

そして、数年後にも運用できるのか。

研究コードから本番システムへ進むとは、単にCodeをきれいに書き直すことではない。

AIをExperimentからResponsibilityのあるSystemへ変換することである。

────────

研究コードの目的

Research Codeの第一目的は、未知の問いを高速に検証することである。

典型的には、

```python
data = load_data()
model = train(data)
score = evaluate(model)

print(score)
```

これでも研究上の問いには答えられる。

「このMethodはBaselineより性能が高いか」

という問いであれば、十分な場合もある。

研究では、変更可能性が重要になる。

Modelを交換する。

Loss Functionを変える。

Hyperparameterを変える。

Datasetを変える。

Evaluation Methodを変える。

つまりResearch Codeは、

Change for Learning

に最適化される。

────────

Production Codeの目的

本番Systemでは目的が異なる。

必要なのは、一回成功することではない。

継続的に、

入力を受ける。

処理する。

結果を返す。

記録する。

異常を検知する。

失敗したら回復する。

変更を安全に反映する。

というOperationである。

したがってProduction Systemは、

Operate for Reliability

に最適化される。

この違いが、研究コードと本番システムの最初の境界になる。

────────

NotebookからServiceへ

AI ResearchではJupyter Notebookが強力である。

Dataを確認しながら処理できる。

Visualizationできる。

Cell単位でExperimentできる。

しかしNotebookは、そのまま企業SystemのRuntimeになるとは限らない。

研究段階の処理を、

```text
Experiment
   ↓
Reusable Module
   ↓
API / Service
   ↓
Application
   ↓
Production Runtime
```

へ分解する必要がある。

Notebookで発見したAlgorithmを、再利用可能なModuleへ切り出す。

それをAPIとして公開する。

Applicationから呼び出す。

CloudやLocal Environmentで継続運用する。

ここからSoftware Engineeringが本格的に始まる。

────────

Pythonは消えない

Production化するとPythonを捨てなければならない、という意味ではない。

Machine Learning。

Data Processing。

LLM。

Evaluation。

Scientific Computing。

これらではPythonは依然として中心的なLanguageである。

重要なのは、

Pythonを研究用Scriptとして使うこと

と、

Production Componentとして設計すること

を区別することである。

例えば、単純な関数でも型と境界を明確にする。

```python
from dataclasses import dataclass

@dataclass
class Prediction:
   label: str
   confidence: float

def predict(text: str) -> Prediction:
   if not text.strip():
       raise ValueError("input text must not be empty")

   # model inference
   return Prediction(
       label="example",
       confidence=0.92,
   )
```

入力条件。

Output Schema。

Error。

こうした境界を明示することからProduction化は始まる。

────────

再現可能性

研究者のPCでは動いた。

しかし別のMachineでは動かない。

これはProductionでは大きな問題になる。

Python Version。

Library Version。

CUDA。

Model Weight。

Environment Variable。

Prompt Version。

これらが変われば結果も変わり得る。

したがって、

CodeだけではSystemを再現できない。

必要なのは、

```text
Code
+ Dependencies
+ Model
+ Configuration
+ Data
+ Runtime
```

である。

Containerを使う理由もここにある。

Execution Environmentそのものを管理対象にする。

────────

ConfigurationをCodeから分離する

研究段階では、

```python
MODEL_NAME = "model-a"
TEMPERATURE = 0.2
```

と直接書いてもよい。

しかしProductionでは、

Development。

Staging。

Production。

で設定が異なる。

API KeyやCredentialをSource Codeへ書くこともできない。

そこで、

Code ≠ Configuration ≠ Secret

という境界を設ける。

この小さな分離が、Cloud、Security、Deploymentへつながっていく。

────────

DataもSystemの一部である

AIではSoftwareだけをVersion管理しても十分ではない。

Training Dataが変わる。

Knowledge Baseが更新される。

Embedding Modelが変わる。

Vector Databaseの内容が変わる。

すると同じCodeでもOutputが変化する。

したがって、

AI System = Code + Model + Data + Configuration

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

────────

LLMではPromptもVersionになる

Generative AIでは、さらにPromptが加わる。

例えば、

```python
SYSTEM_PROMPT = """
You are an assistant for reviewing regulated documents.
Use only the supplied evidence.
If evidence is insufficient, request human review.
"""
```

このPromptを変更すればSystem Behaviorが変わる。

したがってPromptは単なる文章ではない。

Production AIでは、

Prompt = Executable Configuration

としてVersion管理する必要がある。

────────

Outputを構造化する

Research Demoでは自然言語をそのまま表示してもよい。

しかしEnterprise Systemでは、後続処理が必要になる。

そこでOutputをSchemaへ変える。

```python
from pydantic import BaseModel
from typing import Literal

class ReviewResult(BaseModel):
   status: Literal["pass", "review_required", "reject"]
   reason: str
   evidence_ids: list[str]
```

これによってAI Outputを、

Databaseへ保存する。

UIへ表示する。

Audit Logへ残す。

Workflowへ渡す。

ことが容易になる。

自然言語生成をEnterprise Systemへ組み込む重要な一歩である。

────────

Model OutputとBusiness Decisionを分ける

高信頼AIでは、さらに重要な境界がある。

AIが、

```text
risk = high
```

と出力した。

だからSystemが自動的に重要Operationを停止する。

この二つを直接接続してよいとは限らない。

必要なのは、

```text
Model Output
     ↓
Validation
     ↓
Business Rule
     ↓
Human Approval
     ↓
Action
```

というLayerである。

つまり、

Prediction ≠ Decision ≠ Action

である。

この分離は本書全体を貫く重要な原則になる。

────────

Errorを前提にする

Research CodeではErrorが起きればStack Traceを読んでResearcherが修正できる。

Productionでは夜中にErrorが起きるかもしれない。

APIがTimeoutする。

LLM Providerが停止する。

Databaseへ接続できない。

Sensor Dataが欠損する。

Modelが想定外のOutputを返す。

したがって、

```python
try:
   result = run_inference(request)
except TimeoutError:
   result = fallback(request)
```

のようにFailureをSystem Designへ組み込む。

重要なのは例外処理の構文そのものではない。

Failure is expected.

という設計思想である。

────────

Observability

Systemが動いているだけでは足りない。

何が起きているか分からなければ運用できない。

必要になるのがObservabilityである。

Logs。

Metrics。

Traces。

AI固有のEvaluation。

例えば、

```text
request_id
user_id
model_version
prompt_version
retrieved_document_ids
latency
token_usage
output_status
review_result
```

を記録する。

すると、

どのModelが答えたのか。

何を参照したのか。

どこで遅延したのか。

Humanが修正したのか。

を追跡できる。

────────

Auditはさらに深い

製薬、Energy、原子力、重要なEnterprise Systemでは、ObservabilityだけでなくAuditabilityが必要になる。

単にDebugできるのではなく、

後から意思決定の経路を再構成できること

が求められる。

誰が実行したか。

どのDataを参照したか。

AIは何を提案したか。

誰がApproveしたか。

何が実行されたか。

ここでAI EngineeringはGovernanceと接続する。

────────

Rustが入る場所

すべてをPythonだけで構築する必要はない。

Low Latency。

Concurrency。

Memory Safety。

Long-running Runtime。

Edge Processing。

Device Integration。

こうしたRequirementが強くなれば、RustのようなLanguageが有効になる。

例えば、

```text
Python
 └─ Model / Research / Evaluation

Rust
 └─ Runtime / High-performance Service / Edge

TypeScript
 └─ Enterprise UI / Workflow / API Integration

SQL
 └─ Authoritative Business Data / Audit / State
```

というRole Separationが考えられる。

重要なのはLanguageを増やすことではない。

Requirementに応じて適切なRuntimeを選択することである。

────────

TypeScriptはHumanとの境界を担う

AIが企業で使われるためにはInterfaceが必要になる。

ReviewerがOutputを見る。

Evidenceを確認する。

修正する。

Approveする。

履歴を見る。

このHuman–AI InterfaceではTypeScriptが重要になる。

AI SystemはBackend Modelだけでは完成しない。

```text
AI
↓
API
↓
TypeScript Application
↓
Human
```

まで接続して初めて業務Systemになる。

────────

SQLは「現在」を保持する

LLMは生成する。

しかし企業は、生成された文章だけで動いているわけではない。

Customer。

Document。

Approval State。

User Permission。

Execution History。

Audit Record。

これらのAuthoritative Dataを保持する必要がある。

そこでRelational DatabaseとSQLが重要になる。

AIがProbabilityを扱う一方、企業Systemには、

現在何が正式な状態なのか

を保持するLayerが必要である。

────────

Cloudは実行環境である

研究者のLaptopから企業Systemへ移ると、Computeも変わる。

API。

Container。

Database。

Object Storage。

Queue。

Monitoring。

Identity。

Secret Management。

GPU。

これらをCloud Infrastructureとして組み合わせる。

Cloudとは単なるServerの置き場所ではない。

AIを継続的に運用するためのExecution Environment

である。

────────

しかしCloudだけではない

高機密Domainでは、すべてのDataを外部Cloud Serviceへ送れるとは限らない。

Private Environment。

On-premises。

Local LLM。

Edge AI。

を選択する必要がある。

したがって本書では、

```text
Public Cloud
Private Cloud
On-premises
Local
Edge
```

を二者択一として扱わない。

Security、Latency、Cost、Data Governanceに応じて配置する。

────────

Research PrototypeとProduction Architecture

ここまでを整理すると、Research Prototypeは比較的小さい。

```text
Data
↓
Model
↓
Result
```

Production Architectureは異なる。

```text
User / Machine
     ↓
Authentication
     ↓
Application
     ↓
Workflow / Agent
     ↓
AI Service
     ↓
Model / RAG / Tools
     ↓
Validation
     ↓
Human Approval
     ↓
Execution
     ↓
Database / Audit
     ↓
Monitoring / Evaluation
```

Modelは中心にある。

しかし、ModelだけがSystemではない。

────────

Physical AIではさらに外へ広がる

AIがPhysical Worldへ出ればArchitectureはさらに拡張される。

```text
Physical Environment
       ↓
Sensor
       ↓
Edge Runtime
       ↓
Perception AI
       ↓
Planning
       ↓
Safety Layer
       ↓
Human / Control
       ↓
Robot
       ↓
Physical Environment
```

ここではAI ErrorがPhysical Actionへ接続する。

だからSafetyとFail-safeがArchitectureの第一級Componentになる。

────────

研究コードを捨てるのではない

Production化とは、Research Codeを否定することではない。

研究には研究に適したArchitectureがある。

ProductionにはProductionに適したArchitectureがある。

重要なのは、その間にTranslation Layerを作ることである。

```text
Research
  ↓
Experiment
  ↓
Validated Method
  ↓
Reusable Component
  ↓
Production Service
  ↓
Industrial Workflow
```

研究速度を失わず、本番信頼性を獲得する。

それがResearch-to-Production Architectureの目的である。

────────

ProductionからResearchへ戻れるようにする

さらに、本書では一方向のProduction化だけを扱わない。

ProductionでFailureが起きる。

Humanが修正する。

Domain ExpertがFeedbackする。

Environmentが変化する。

それをResearchへ戻す。

```text
Research
  ↓
Production
  ↓
Observation
  ↓
Evaluation
  ↓
Feedback
  ↓
Research
```

この循環を成立させるため、Production Systemには最初からEvaluationとLoggingが必要になる。

────────

EQUES型実装の核心

第1冊で見たEQUESの企業構造を技術Architectureへ翻訳すると、重要なのは「最新AIを使うこと」ではない。

研究成果を受け取り、

Domainへ適応し、

Systemへ変換し、

Humanへ接続し、

高信頼に運用し、

現場から学び、

再びResearchへ戻す。

その全工程を実装可能にすることである。

最小化すれば、

Research Code
→ Domain AI
→ Production System
→ Human / Industry
→ Evaluation
→ Next Research

となる。

────────

本書はModelの作り方だけを扱わない

PythonでModelを作る。

LLMをFine-tuningする。

RAGを構築する。

それだけなら、AI Engineeringの一部分である。

本書が対象にするのは、その外側まで含めたArchitectureである。

PythonでIntelligenceを作る。

LLMとRAGをDomainへ適応する。

AgentでWorkflowへ接続する。

TypeScriptでHuman Interfaceを作る。

SQLでStateとAuditを保持する。

Cloudで運用する。

RustとEdgeでPhysical Worldへ近づく。

SensorとRobotを接続する。

OptimizationとQuantumを必要な計算Problemへ使う。

EvaluationとHuman Feedbackによって継続改善する。

これらを一つのIndustrial AI Systemとして接続する。

────────

研究コードは、問いを開くために書かれる。

本番システムは、その答えを現実世界で継続的に使うために作られる。

そして優れた産業AI Architectureは、その二つを分断しない。

Researchの自由度をProductionへ翻訳し、ProductionのRealityをResearchへ返す。

この双方向性こそが、EQUES型AI実装の出発点である。

次節では、その間に存在する最初の大きな断絶――PoCとProductionの距離を、Architecture、Data、Security、Operation、Evaluationの観点から具体的に分解していく。
第2節　PoCとProductionの距離

AI開発では、PoCが成功する瞬間がある。

実データを入力すると、期待した分類結果が出る。LLMが専門文書を生成する。RAGが関連資料を検索し、質問へ回答する。画像認識Modelが対象物を検出する。

Demoを見る限り、Technologyは完成したように見える。

しかし産業実装では、ここが出発点になる。

PoCで動くことと、Productionで使えることの間には大きな距離がある。

この距離を埋めるEngineeringこそ、EQUES型AI社会実装の中心である。

⸻

PoCが検証するもの

Proof of Conceptの目的は、文字通りConceptが成立するかを確認することにある。

例えば製薬Documentなら、

「LLMを使って特定の文書作成を支援できるか」

を検証する。

Physical AIなら、

「CameraやSensor Dataから必要な状態を認識できるか」

を試す。

したがってPoCでは、最小限の構成で仮説を検証することが合理的である。

Problem
  ↓
Hypothesis
  ↓
Prototype
  ↓
Evaluation
  ↓
Go / No-Go

最初から巨大なProduction Systemを作る必要はない。

むしろ作るべきではない。

⸻

PoCの成功条件

PoCでは問いを限定する。

特定Dataset。

限定されたUser。

限定されたUse Case。

限定された期間。

例えば、

入力文書100件
↓
RAG
↓
LLM
↓
回答精度を評価

という構成でもTechnology Feasibilityは確認できる。

この段階で重要なのは、

Can it work?

である。

⸻

Productionでは問いが変わる

本番導入では問いが、

Can it keep working safely?

へ変わる。

Userが100人になったらどうなるか。

Documentが100万件になったらどうなるか。

Model Providerが停止したらどうするか。

機密情報を誰が閲覧できるか。

誤回答をどう発見するか。

新しいModelへ変更したら性能は維持されるか。

Productionでは、Technologyそのものだけでなく、その周囲にあるSystem全体が評価対象になる。

⸻

100件で動くことと100万件で動くこと

PoCではDataをMemoryへ読み込み、単純な検索を行ってもよい。

ProductionではData Volumeが増える。

そこで、

SQL。

Object Storage。

Vector Database。

Cache。

Index。

Queue。

といったData Architectureが必要になる。

つまり、

PoC
Data → Model

から、

Production
Data Source
  ↓
Ingestion
  ↓
Validation
  ↓
Storage
  ↓
Index
  ↓
Retrieval
  ↓
Model

へ変わる。

Modelの前後が大きくなる。

⸻

Demo UserとReal User

PoCではDeveloper自身が操作することも多い。

入力形式を知っている。

SystemのLimitも理解している。

Errorが起きても原因を推測できる。

しかしProductionでは、Systemを作っていないHumanが使う。

入力を間違える。

想定外のQuestionをする。

AI Outputを過信する。

したがって、

Developer-friendly Prototype

から、

Human-safe Product

への変換が必要になる。

⸻

Happy PathからFailure Pathへ

PoCは正常に動くCaseを中心に作りやすい。

Productionでは異常系の方が重要になる。

入力が空だったら。

File Formatが違ったら。

Databaseが落ちたら。

LLMがTimeoutしたら。

Retrieval Resultが0件だったら。

ModelがSchema外のOutputを返したら。

Production Architectureでは、

Success Path
+
Failure Path
+
Recovery Path

を設計する。

⸻

LLMは常に正しい形式を返すとは限らない

例えばAIへJSON出力を要求しても、想定外のResponseが返る可能性がある。

そこでSchema Validationを行う。

from pydantic import BaseModel, ValidationError
class AIResult(BaseModel):
   status: str
   reason: str
def validate_output(raw: dict) -> AIResult:
   try:
       return AIResult.model_validate(raw)
   except ValidationError as exc:
       raise ValueError("invalid AI output") from exc

重要なのはこのCodeそのものではない。

AI Outputを信頼境界の外側に置く

という原則である。

Modelが返したから正しい、とは考えない。

⸻

AccuracyからRiskへ

PoCではAccuracyが主要Metricになることが多い。

しかしProductionでは、

False Positive。

False Negative。

Hallucination。

Latency。

Cost。

Availability。

Security Incident。

Human Review Time。

まで見る必要がある。

特に高信頼Domainでは、平均Accuracyだけでは不十分である。

例えば99%正しくても、残り1%がCriticalなFailureなら採用できない可能性がある。

⸻

Errorを同じ重さで数えない

産業AIでは、Errorの種類によってCostが異なる。

そこで単純Accuracyから、

Risk-weighted Evaluation

へ進む。

例えば、

Minor Error          = 1
Review Required      = 5
Critical False Pass  = 100

のように、Business RiskをEvaluationへ反映する。

実際のWeightはDomain Expertと設計する。

ここでAI EvaluationとBusiness Requirementが接続する。

⸻

Domain Expertが必要になる理由

PoCからProductionへ進むと、AI Engineerだけでは判断できない問題が増える。

製薬なら品質保証。

Energyなら設備Operation。

原子力ならSafety。

AI EngineerはModel Behaviorを理解する。

Domain ExpertはFailure Consequenceを理解する。

したがって、

AI Engineer
    ⇅
Domain Expert
    ⇅
Operator

という協働が必要になる。

Production Requirementは、この境界から生まれる。

⸻

Human Reviewを後付けしない

高信頼AIでは、

「最後に人が確認する」

だけではArchitectureにならない。

誰が確認するのか。

何を確認するのか。

どのEvidenceを見るのか。

何分以内に判断するのか。

Rejectした場合どうなるのか。

これをWorkflowとして定義する。

AI Generate
   ↓
Automated Check
   ↓
Human Review
   ↓
Approve / Reject
   ↓
Record

HumanはSystem外部の例外処理ではない。

Production ArchitectureのComponentである。

⸻

PoCでは共有Accountでも動く

ProductionではIdentityが必要になる。

誰がLoginしたか。

どのRoleを持つか。

どのDataを見られるか。

どのActionを実行できるか。

そこで、

Authentication

と、

Authorization

を分離する。

「誰であるか」と「何をしてよいか」は別の問題である。

⸻

CapabilityとPermissionを分ける

AI Agentでは特に重要になる。

Agentには、

Documentを読む能力。

Draftを作る能力。

Databaseを更新する能力。

External Systemを操作する能力。

があるかもしれない。

しかし、

Capability ≠ Permission

である。

できるからといって、実行を許可する必要はない。

⸻

PoCではLogがなくても進める

Developerが画面を見ていれば挙動を確認できる。

Productionではそれでは足りない。

Request ID。

User ID。

Model Version。

Prompt Version。

Retrieved Documents。

Tool Calls。

Approval。

Execution Result。

を記録する。

これによって初めて、

「何が起きたのか」

を後から再構成できる。

⸻

LoggingからAuditへ

通常のApplication LogはDebugのために使われる。

高信頼AIではさらに、

Decision Trace

を残す。

User Request
  ↓
Retrieved Evidence
  ↓
Model Output
  ↓
Automated Validation
  ↓
Human Decision
  ↓
Executed Action

このChainを追えるようにする。

製薬や重要Infrastructureでは、これは単なるDeveloper ConvenienceではなくSystem Requirementになり得る。

⸻

SecurityがArchitectureを変える

PoCではPublic APIへDataを送れば数時間でDemoを作れることがある。

Productionでは、そのDataを外部Serviceへ送ってよいかを確認しなければならない。

Confidential Data。

Personal Data。

Regulated Data。

Critical Infrastructure Data。

用途によってDeployment Architectureそのものが変わる。

Public API
Private Cloud
Dedicated Environment
On-premises
Local Model
Edge

Securityは完成後に追加するLayerではない。

最初からArchitecture Decisionに入る。

⸻

RAGにもProduction Gapがある

PoCでは数十DocumentをVector Databaseへ入れればRAG Demoができる。

Productionでは、

Document Version。

Access Permission。

Deletion。

Metadata。

Freshness。

Duplicate。

Source Reliability。

が問題になる。

例えば退職したUserが閲覧できないDocumentを、RAG経由で取得できてはいけない。

つまりRetrievalにもAuthorizationが必要になる。

⸻

Knowledgeは更新される

Production Knowledge Baseは静的ではない。

Documentが追加される。

改訂される。

失効する。

そこで、

Document
↓
Version
↓
Validity
↓
Access Policy
↓
Index

を管理する。

RAGの品質はEmbedding Modelだけでは決まらない。

Knowledge LifecycleそのものがArchitectureの一部になる。

⸻

Modelも更新される

Foundation Modelは継続的に変化する。

新Versionが出る。

API Behaviorが変わる。

Costが変わる。

旧Modelが終了する。

だからApplicationを一つのModelへ強く結合すると、将来の変更Costが高くなる。

Model Adapterを置くことで、

Application
    ↓
Model Interface
    ↓
Model A / Model B / Local Model

と分離できる。

⸻

Model UpdateをそのままProductionへ出さない

新しいModelのBenchmarkが高い。

それだけでProductionへ切り替えるべきではない。

既存Test Setで評価する。

Domain Benchmarkで評価する。

Critical Casesを確認する。

Costを見る。

Latencyを見る。

Human Reviewへの影響を見る。

そしてReleaseする。

Candidate Model
     ↓
Offline Evaluation
     ↓
Domain Evaluation
     ↓
Safety / Security Check
     ↓
Staging
     ↓
Controlled Release

となる。

⸻

Stagingという中間世界

ResearchとProductionの間には、Staging Environmentを置く。

Productionに近いInfrastructure。

Productionに近いWorkflow。

しかし実業務へ直接影響しないEnvironment。

ここでIntegration Testを行う。

AI Systemでは、

Model TestだけでなくSystem Test

が必要になる。

⸻

Shadow Deployment

さらに既存Systemを止めず、新しいAIを裏側で動かす方法もある。

Userには旧Systemの結果を返す。

新Systemも同じInputを処理する。

結果だけ比較する。

Input
├─ Current System → Production Result
└─ New AI System → Shadow Result

これによってReal-world Distributionで性能を評価できる。

⸻

Gradual Rollout

Production Releaseも0か100かである必要はない。

一部User。

一部Department。

低Risk Task。

から開始する。

問題がなければ範囲を広げる。

これはAIの不確実性をDeployment Architectureで管理する方法である。

⸻

Rollbackできること

新Versionに問題が見つかったら、旧Versionへ戻せる必要がある。

Codeだけでなく、

Model。

Prompt。

Configuration。

Knowledge Index。

もVersion管理する。

つまり、

AI Deployment must be reversible.

変更可能性だけでなく、復元可能性を持たせる。

⸻

Availability

PoCは一時間動けば成功する場合がある。

Productionでは毎日利用される。

Systemが停止するとBusinessが止まる。

そこで、

Health Check。

Retry。

Timeout。

Redundancy。

Backup。

Disaster Recovery。

が必要になる。

AIはSoftware Engineeringの基本原則から免除されない。

⸻

CostもProduction Requirementになる

PoCでは数千円のAPI Costは問題にならない。

ProductionではRequestが百万回になる可能性がある。

すると、

Token Cost。

GPU Cost。

Storage Cost。

Network Cost。

Human Review Cost。

を含めて考える。

最も高性能なModelをすべてのTaskへ使うことが最適とは限らない。

⸻

Model Routing

簡単なTaskにはSmall Model。

難しいTaskにはLarge Model。

機密TaskにはLocal Model。

Critical TaskにはHuman Review。

というRoutingが可能である。

Request
  ↓
Risk / Complexity Classification
  ├─ Small Model
  ├─ Large Model
  ├─ Local Model
  └─ Human

Performance、Cost、Trustを同時に最適化する。

⸻

Physical AIでは距離がさらに広がる

RobotのPoCでは、

「対象物を認識してArmが動いた」

ことで成功と判断できる場合がある。

Productionでは、

Lightingが変わる。

Sensorが汚れる。

Networkが切れる。

Humanが近づく。

Obstacleが増える。

Hardwareが劣化する。

RealityはLabより複雑である。

⸻

Safety Layer

Physical AIでは、

AI Decision
    ↓
Safety Validation
    ↓
Control System
    ↓
Physical Action

とする。

AIがActionを提案しても、Safety Constraintに違反すれば実行しない。

これはSoftware AI以上に重要なProduction Boundaryである。

⸻

Edge Runtime

Physical SystemではCloud Latencyを待てない場合がある。

Emergency Stop。

Collision Avoidance。

Real-time Perception。

こうした処理はEdgeへ置く。

一方、大規模AnalysisやTrainingはCloudへ置ける。

Cloud
 ⇅
Edge
 ⇅
Sensor / Robot

Production化すると、Compute PlacementそのものがSystem Designになる。

⸻

PoCからProductionへ進む判定

PoCが成功したからProductionへ進むのではない。

複数のGateを通過する。

Technical Feasibility
       ↓
Domain Validity
       ↓
Business Value
       ↓
Security
       ↓
Reliability
       ↓
Operational Readiness
       ↓
Production

どこかで成立しなければ、止める判断も必要になる。

⸻

PoCを捨てる判断も成功である

PoCの目的はProduction化を正当化することではない。

Technologyが不適切だと分かることにも価値がある。

Accuracyが不足する。

Costが合わない。

Humanの方が速い。

Riskが高すぎる。

その場合、

No-Go

という結論を出す。

無理にAI化しないことも、優れたAI Engineeringである。

⸻

Production Readiness

Productionへ進む前に、最低限確認する。

* Domain上の有効性が検証されているか
* Failure Modeを把握しているか
* Data Accessが管理されているか
* Outputを検証できるか
* Human Responsibilityが定義されているか
* LoggingとAuditが可能か
* Security Requirementを満たすか
* Monitoringできるか
* Rollbackできるか
* 運用責任者が存在するか

ここまで来て初めて、AIは「Demo」から「Industrial System」へ近づく。

⸻

PoCとProductionの間にあるもの

両者の差を最小化すると、

PoC
│
├─ Architecture
├─ Data Engineering
├─ Domain Validation
├─ Security
├─ Human Workflow
├─ Evaluation
├─ Observability
├─ Reliability
├─ Governance
└─ Operations
│
Production

となる。

つまりPoCとProductionの距離とは、単なるCode量の差ではない。

責任を持って継続運用するために必要な構造の差である。

⸻

EQUES型実装の位置

EQUES型AI実装の価値は、研究Technologyを知っていることだけではない。

研究段階で成立したCapabilityを、

Domain Requirementへ翻訳する。

PoCで検証する。

Production Architectureへ変換する。

Humanを組み込む。

高信頼に運用する。

現場からFeedbackを取得する。

そして再びResearchへ返す。

ここまでを一つのProcessとして扱うことにある。

⸻

研究からPoCまでは、

可能かどうか

を問う。

PoCからProductionまでは、

現実の産業の中で、継続的かつ安全に使えるか

を問う。

この二つは似ているようで異なる。

そして、その距離を正しく認識することが、AI社会実装の最初の条件になる。

次節では、この距離が産業ごとに異なる理由をさらに深く掘り下げる。

一般的なAIを特定産業のKnowledge、Data、Workflow、Evaluationへ適応させる――Domain-specific AIという第三の層である。
第3節　Domain-specific AI

AIは汎用化している。

一つのLLMが、文章生成、要約、翻訳、検索支援、Coding、Question Answeringまで幅広いTaskを扱える。

しかし産業実装では、汎用性だけでは足りない。

製薬には製薬のLanguageがある。

EnergyにはEnergyのDataがある。

原子力には独自のSafety Requirementがある。

Enterpriseには企業ごとのWorkflow、Permission、Master Data、Approval Ruleがある。

同じAI Modelを利用しても、必要とされるKnowledge、Accuracy、Risk、OperationはDomainごとに異なる。

そこで必要になるのが、

Domain-specific AI

である。

Domain-specific AIとは、単に専門用語を多く知っているAIではない。

General AI Capabilityを、特定DomainのKnowledge、Data、Task、Evaluation、Workflow、Governanceへ適応させたAI System

である。

⸻

General AIとDomain AI

General-purpose AIは広いTaskへ対応する。

一方、Domain AIは対象範囲を狭くする代わりに、その領域で必要な条件を深く扱う。

概念的には、

General AI
  ↓
Domain Knowledge
  ↓
Domain Task
  ↓
Domain Evaluation
  ↓
Domain Workflow
  ↓
Domain AI

となる。

重要なのは、Modelだけを専門化するのではないことである。

System全体をDomainへ適応する。

⸻

「知っている」と「使える」は違う

LLMがGMPという言葉を説明できる。

それだけでは製薬AIとは言えない。

製薬業務で必要なのは、

どのDocumentを参照するのか。

どの項目が重要なのか。

どこでHuman Reviewが必要か。

どのOutputを正式記録として扱えるか。

どの情報を外部Modelへ送ってよいか。

まで理解したSystemである。

つまり、

Domain Knowledge ≠ Domain Implementation

である。

⸻

Domain-specific AIの五層

Domain AIを実装する場合、少なくとも五つのLayerを考えると整理しやすい。

1. Domain Knowledge
2. Domain Data
3. Domain Task
4. Domain Evaluation
5. Domain Workflow

この五つが揃って初めて、汎用AIが産業AIへ近づく。

⸻

第1層――Domain Knowledge

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

製薬なら、

GMP。

品質保証。

逸脱。

変更管理。

年次照査。

薬学。

Energyなら、

設備。

Inspection。

Maintenance。

Sensor。

Safety。

こうしたConceptを整理する。

Knowledge Sourceには、

Manual。

Regulation。

Internal Document。

Standard Operating Procedure。

Historical Report。

Expert Knowledge。

などがある。

⸻

KnowledgeをそのままLLMへ入れない

大量のDocumentをPromptへ貼り付けるだけではScaleしない。

そこでKnowledgeを構造化する。

例えば、

from dataclasses import dataclass
@dataclass
class DomainDocument:
   document_id: str
   title: str
   version: str
   effective_date: str
   document_type: str
   access_level: str

単なるTextではなく、

Version。

Validity。

Type。

Permission。

を持たせる。

Domain AIでは、Knowledgeの意味だけでなくLifecycleも重要になる。

⸻

第2層――Domain Data

KnowledgeとDataは同じではない。

KnowledgeはRuleやManualを含む。

Dataは実際の業務状態を含む。

製薬なら、

品質関連記録。

製造情報。

Document Metadata。

Energyなら、

Sensor Time Series。

Inspection Image。

Equipment State。

Maintenance History。

である。

AIが利用するDataは、

What the domain knows

だけでなく、

What is happening now

を表現する。

⸻

Data SchemaがDomainを表現する

Domain AIでは、Database Schemaそのものが業務理解になる。

例えば、

equipment
inspection
maintenance_event
sensor_reading
operator
approval

というEntityを定義する。

そのRelationshipを設計する。

するとDomain KnowledgeがSoftware Architectureへ変換される。

⸻

第3層――Domain Task

AIに何をさせるのかを明確にする。

「製薬に強いAIを作る」

では曖昧すぎる。

例えば、

Document Draft。

Consistency Check。

Knowledge Retrieval。

Anomaly Detection。

Risk Classification。

Maintenance Recommendation。

Task単位へ分解する。

つまり、

Domain → Concrete Task

へ落とす。

⸻

Task Definitionが最も重要になる

例えば、

「文書を確認する」

というTaskがある。

これを分解すると、

項目が欠落していないか。

数値が一致しているか。

日付が矛盾していないか。

記述内容がSourceと整合しているか。

という複数Taskになる。

AI Systemは、この具体化されたTaskを扱う。

⸻

第4層――Domain Evaluation

General Benchmarkで高性能でも、Domain Taskで高性能とは限らない。

そこで独自Evaluationが必要になる。

例えば、

General Benchmark
       ↓
Domain Benchmark
       ↓
Task-level Evaluation
       ↓
Critical Case Evaluation

という階層で見る。

JPharmaBenchのような取り組みは、このDomain Evaluationの考え方に接続する。

⸻

Domain Expertが正解を作る

Domain-specific Evaluationでは、AI Engineerだけで正解を決められない。

Domain Expertが必要になる。

どのOutputがAcceptableか。

どのErrorがCriticalか。

どこまで差異を許容するか。

これを定義する。

つまり、

Domain Expert → Evaluation Criteria

である。

⸻

第5層――Domain Workflow

最後に、そのAIを実際の業務へ組み込む。

AIが良いOutputを出しても、業務の外側にあるならValueは限定される。

例えば、

Business Event
   ↓
AI Processing
   ↓
Domain Validation
   ↓
Human Review
   ↓
Approval
   ↓
Enterprise System

へ接続する。

ここで初めてDomain AIがProduction Systemになる。

⸻

Domain-specific AIはModelだけではない

この五層をまとめると、

Model
+
Knowledge
+
Data
+
Task
+
Evaluation
+
Workflow
=
Domain AI System

となる。

これが本節の中心である。

⸻

Domain Adaptationの方法は一つではない

Domain AIを作る方法としてFine-tuningが注目されやすい。

しかし、最初からModel Trainingを行う必要はない。

選択肢には、

Prompt Engineering。

RAG。

Tool Use。

Fine-tuning。

Continued Pretraining。

Domain-specific Model。

がある。

どこまでModelそのものを変えるかはRequirement次第である。

⸻

Promptだけで十分な場合

General Modelが既にTaskを理解できる。

必要Knowledge量が小さい。

高いDomain-specific Reasoningが不要。

この場合、Promptだけで十分なこともある。

最小構成を選ぶ。

General Model
+
Domain Instruction
=
Domain Use

まずここから始める方が合理的である。

⸻

RAGが適する場合

Knowledgeが頻繁に更新される場合、Fine-tuningよりRAGが適することがある。

Regulation。

Manual。

Internal Document。

これらを外部Knowledgeとして管理する。

Question
 ↓
Retriever
 ↓
Domain Documents
 ↓
LLM
 ↓
Answer + Evidence

KnowledgeをModel Weightへ埋め込まず、参照可能な状態に保つ。

⸻

Fine-tuningが適する場合

一方、Task Behaviorそのものを変えたい場合にはFine-tuningが有効になる。

特定Formatで回答する。

Domain-specificな分類を行う。

独特のLanguage Patternを扱う。

このような場合である。

重要なのは、

Knowledge Problem

と、

Behavior Problem

を区別することだ。

Knowledgeが不足しているならRAG。

Behaviorを変えたいならFine-tuning。

この切り分けが必要になる。

⸻

Domain-specific Model

さらに深く入る場合、Domain-specific LLMを開発する。

ここでは、

Training Data。

Compute。

Evaluation。

Deployment。

が必要になる。

JPharmatronのような取り組みは、このLayerに位置づけられる。

しかし独自Modelを持つこと自体をGoalにしてはいけない。

⸻

Modelを作る理由を定義する

Domain-specific Modelを開発する前に問う。

General Modelでは何が不足しているのか。

Security上Local Deploymentが必要なのか。

Costを下げたいのか。

専門Knowledgeが足りないのか。

Domain Benchmarkで性能差があるのか。

つまり、

Build a Model because the requirement demands it.

である。

⸻

Local AIという要件

Domain-specific AIでは、性能以外の理由からLocal Modelが必要になる場合もある。

機密Dataを外部へ出せない。

Networkが使えない。

Latencyを下げたい。

Costを予測可能にしたい。

この場合、

Enterprise Data
    ↓
Local Model
    ↓
Local Application

というArchitectureを選択する。

Model CapabilityだけでなくDeployment Requirementを見る。

⸻

Domain-specific RAG

RAGもDomainごとに設計が変わる。

単純なSemantic Searchだけでは不十分な場合がある。

Document Type。

Version。

Effective Date。

Department。

Permission。

をFilterに使う。

例えば、

SELECT *
FROM documents
WHERE document_type = 'quality'
 AND is_active = TRUE
 AND access_level <= :user_access;

この結果をVector Retrievalと組み合わせる。

つまり、

Semantic Retrieval + Domain Constraint

である。

⸻

Hybrid Retrieval

Domain用語ではExact Matchが重要な場合がある。

Document Number。

Product Code。

Chemical Name。

Equipment ID。

そこで、

Keyword Search。

Vector Search。

Metadata Filter。

を組み合わせる。

Query
 ├─ Keyword
 ├─ Vector
 └─ Metadata
       ↓
   Re-ranking
       ↓
     Context

これがHybrid Retrievalである。

⸻

Domain Ontology

より高度なDomain AIではOntologyを持つこともできる。

例えば製薬なら、

Product。

Batch。

Process。

Deviation。

Document。

Approval。

それぞれのRelationshipを定義する。

Energyなら、

Facility。

Equipment。

Sensor。

Event。

Maintenance。

Operator。

となる。

Ontologyがあれば、AIがDomain Structureへより明確に接続できる。

⸻

Knowledge Graphとの接続

OntologyをGraphとして保持すれば、

Equipment
  ├─ hasSensor → Sensor
  ├─ hasEvent → FailureEvent
  └─ requires → MaintenanceProcedure

のようなRelationshipを検索できる。

LLMとKnowledge Graphを組み合わせることで、単純Text Retrievalだけでは扱いにくい構造を利用できる。

⸻

Domain RuleはLLMへ丸投げしない

Critical RuleをすべてNatural LanguageでLLMに解釈させるのは危険な場合がある。

明確なRuleはSoftware側へ置く。

def requires_human_review(risk_score: float) -> bool:
   return risk_score >= 0.8

曖昧な判断をAIへ。

決定的なConstraintをRuleへ。

つまり、

AI + Deterministic Logic

で設計する。

⸻

High-reliability DomainほどHybridになる

製薬やEnergyでは、

Machine Learning。

Rule-based System。

Optimization。

Human Judgment。

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

一つの巨大Modelですべてを解く必要はない。

Domain System
├─ LLM
├─ ML Model
├─ Rules
├─ Database
├─ Optimizer
└─ Human

このHybrid ArchitectureがIndustrial AIでは重要になる。

⸻

Domain-specific AI Agent

AgentをDomainへ入れる場合も同じである。

General AgentへすべてのToolを与えるのではない。

例えば製薬Agentなら、

Document Search。

Draft Creation。

Consistency Check。

Review Request。

だけを許可する。

Domain Agent
  ↓
Allowed Tools
  ├─ search_documents
  ├─ create_draft
  ├─ check_consistency
  └─ request_review

DomainとRiskに応じてCapabilityを制限する。

⸻

Tool SchemaもDomain Knowledgeである

Function CallingのSchemaは、単なるAPI Definitionではない。

業務で何が可能かを表現する。

例えば、

def request_quality_review(
   document_id: str,
   reviewer_role: str,
   reason: str
) -> str:
   ...

このFunctionには、

Document。

Reviewer。

Reason。

というDomain Conceptが埋め込まれている。

つまりTool InterfaceもDomain Modelの一部である。

⸻

Domain-specific Security

Domainが変わればSecurity Requirementも変わる。

誰が何を見られるか。

誰がApproveできるか。

どのDataを外部Modelへ送れるか。

Role-based Access ControlをDomain Roleに合わせる。

Researcher
Reviewer
Approver
Operator
Administrator

Role自体がBusiness Logicになる。

⸻

Domain-specific Audit

Audit LogもGeneral Logだけでは足りない。

例えば、

Document ID。

Model Version。

Evidence。

Reviewer。

Approval Timestamp。

を記録する。

Physical AIなら、

Sensor State。

Action。

Operator Override。

を記録する。

つまりAudit SchemaもDomainによって変わる。

⸻

Domain-specific Observability

Monitoringも同じである。

LLM Applicationなら、

Hallucination Rate。

Retrieval Success。

Human Correction Rate。

Physical AIなら、

Sensor Failure。

Control Latency。

Emergency Stop。

を見る。

同じObservability PlatformでもMetricはDomain-specificになる。

⸻

Domain-specific Failure Mode

産業AIでは、何が失敗なのかをDomainごとに定義する。

製薬では、

Critical Informationの欠落。

Document間の重大な不整合。

Energyでは、

異常の見逃し。

False Alarm。

Physical AIでは、

Unsafe Action。

Failure Modeを先に定義する。

それをEvaluationとMonitoringへ反映する。

⸻

Domain-specific AIの中心はFailure Definitionである

これは重要な点である。

「何が正しいか」だけでなく、

何が危険な失敗か

を定義できること。

ここにDomain Expertの価値がある。

General AIは平均的なPerformanceを示せても、Critical Failureの意味までは自動的に理解しない。

⸻

Domain ExpertをArchitectureへ組み込む

Domain ExpertはRequirement Definitionだけに参加するのではない。

Dataset作成。

Evaluation。

Prompt Design。

Review Workflow。

Incident Analysis。

へ継続的に関与する。

Domain Expert
   ⇅
AI Engineer
   ⇅
Production System

このLoopがDomain AIを継続改善する。

⸻

Knowledge Transfer

AI EngineerがDomainを学ぶ。

Domain ExpertがAIを学ぶ。

この双方向Learningによって共通Languageが形成される。

結果として、

Requirement Definitionが速くなる。

Failure Analysisが正確になる。

新しいUse Caseを発見しやすくなる。

Domain-specific AIは、TechnologyだけでなくTeam Capabilityでもある。

⸻

製薬からEnergyへ再利用できるもの

Domain-specific AIは、Domainごとにすべてをゼロから作るという意味ではない。

再利用できるCoreがある。

Evaluation Infrastructure。

Human Approval。

Audit。

Security。

RAG Framework。

Model Routing。

これらは共通化できる。

一方、

Domain Knowledge。

Rules。

Failure Definition。

Workflow。

は個別化する。

つまり、

Common AI Core
     +
Domain-specific Layer

である。

⸻

Trusted Coreという考え方

EQUES型Architectureでは、この共通部分をTrusted Coreとして持つことができる。

Trusted Core
├─ Identity
├─ Security
├─ Evaluation
├─ Audit
├─ Observability
├─ Model Gateway
└─ Human Approval

その上に、

Pharmaceutical Layer
Energy Layer
Physical AI Layer

を載せる。

これによってDomain差を保持しながらEngineering Assetを再利用できる。

⸻

Domain-specific AIとVertical AI

BusinessのLanguageでは、Domain-specific AIはVertical AIへ接続する。

Horizontal AIは多業種に同じCapabilityを提供する。

Vertical AIは特定IndustryのWorkflowまで深く扱う。

その差はModelではなく、Domain Integration Depthにある。

General Tool
  ↓
Domain Assistant
  ↓
Domain Workflow
  ↓
Vertical AI System

下へ行くほどIndustry固有のKnowledgeが増える。

⸻

Domain DepthがMoatになる

Foundation Model自体がCommodity化しても、

Domain Knowledge。

Evaluation Set。

Workflow Integration。

Customer Trust。

は簡単にはCommodity化しない。

したがってDomain-specific AIでは、

Model Advantage

より、

Domain Integration Advantage

が長期的な差別化になる可能性がある。

⸻

ただしOver-specializationにも注意する

一つのCustomerに合わせすぎると、Reusable Productにならない。

一つのDomainに閉じすぎると、共通Technologyを再利用できない。

したがって、

Specific enough to create value, general enough to reuse.

というBalanceが必要になる。

⸻

Domain-specific AIの開発手順

実装の流れを最小化すると、

1. Domain Problemを定義する
2. Domain Expertを参加させる
3. Knowledge / Dataを整理する
4. Taskを具体化する
5. Baselineを作る
6. General Modelで検証する
7. RAG / Fine-tuningを必要に応じて追加する
8. Domain Evaluationを作る
9. Human Workflowへ接続する
10. Production Feedbackで改善する

最初から巨大なDomain ModelをTrainingする必要はない。

Requirementに応じてDepthを増やす。

⸻

Smallest Sufficient Model

これは重要な設計原則になる。

必要なTaskを満たせる最小のSystemを選ぶ。

Promptで足りるならPrompt。

RAGで足りるならRAG。

Fine-tuningが必要なら追加する。

Local Modelが必要なら構築する。

つまり、

Smallest Sufficient AI Architecture

を選ぶ。

ComplexityはRequirementによって正当化されるべきである。

⸻

Domain-specific AIは固定されない

Domain Knowledgeは更新される。

Regulationが変わる。

Workflowが変わる。

Productが変わる。

したがってDomain AIも継続更新する必要がある。

Knowledge Baseを更新する。

Evaluation Setを追加する。

Promptを変更する。

Modelを交換する。

Human Feedbackを反映する。

つまりDomain-specific AIもContinuous Systemである。

⸻

Domain-specific AIの最小構造

本節全体を圧縮すると、

General AI
   ↓
Domain Knowledge
   ↓
Domain Data
   ↓
Domain Task
   ↓
Domain Evaluation
   ↓
Domain Workflow
   ↓
Production Feedback

となる。

そしてFeedbackが再びKnowledge、Evaluation、Modelへ戻る。

⸻

AIを産業へ実装するためには、汎用AIの能力をそのまま持ち込むだけでは足りない。

Domainの言葉を理解し、DomainのDataを扱い、DomainのTaskを実行し、Domainの基準で評価され、DomainのWorkflowの中でHumanとともに動く。

そこまで到達して初めて、AIは産業システムの一部になる。

EQUES型AI実装において重要なのは、General AIを無理に専門化することではない。

General CapabilityとDomain Realityの間に、正しいArchitectureを作ることである。

そしてDomainが製薬、Energy、原子力のようにFailure Costの高い領域へ進むと、次に問われるのは専門性だけではなく信頼性になる。

次節では、Domain-specific AIのさらに上に必要となる設計条件――高信頼AIを、Evaluation、Evidence、Security、Human Oversight、Audit、Fail-safeまで含めたSystem Architectureとして具体化していく。
第4節　高信頼AI

AIが産業の中で重要な判断や業務を担うほど、単に「高性能であること」だけでは不十分になる。

正しい結果を出す。

速く処理する。

大量のDataを扱う。

これらは重要である。

しかし製薬、Energy、原子力、Infrastructureのような高信頼領域では、さらに問われる。

なぜその結果になったのか。

どのDataを参照したのか。

どのModel Versionを使ったのか。

誰が確認したのか。

異常時に停止できるのか。

後から再現できるのか。

つまり必要なのは、

High-performance AI

ではなく、

High-reliability AI System

である。

⸻

高信頼AIは一つのModelではない

高信頼AIというと、極めて正確なModelを想像しやすい。

しかし実際には、

Modelだけを信頼できてもSystemは信頼できない。

Dataが古いかもしれない。

Retrievalが誤っているかもしれない。

Promptが変わっているかもしれない。

Userが誤操作するかもしれない。

Networkが落ちるかもしれない。

そこで、信頼性はSystem全体で作る。

AI Model
+
Data Quality
+
Evaluation
+
Evidence
+
Security
+
Human Oversight
+
Audit
+
Failure Handling
=
Trusted AI System

これが本書における高信頼AIの基本構造である。

⸻

Accuracyだけでは足りない

例えばModel Accuracyが99%だったとする。

高い数字に見える。

しかし残り1%が、

単純な表記揺れなのか。

重要な警告の見逃しなのか。

では意味がまったく違う。

したがって、

Average Accuracy

だけではなく、

Failure Severity

を見る必要がある。

⸻

Risk-based Evaluation

高信頼AIでは、ErrorをRiskで重みづける。

Minor Formatting Error        → Low Risk
Wrong Supporting Evidence     → Medium Risk
Critical False Negative       → High Risk
Unsafe Physical Action        → Critical Risk

評価Metricもこれに合わせる。

単なる平均Scoreではなく、

Critical Error Rate。

False-negative Rate。

Human Escalation Rate。

などを見る。

⸻

AIを信頼する前に測る

Trustの前にEvaluationがある。

新しいModelを導入する。

まず測る。

Domain Datasetで評価する。

Critical Caseを評価する。

既存Modelと比較する。

その後で採用を判断する。

つまり、

Candidate AI
   ↓
Evaluation
   ↓
Risk Analysis
   ↓
Deployment Decision

である。

⸻

Evaluation Setを資産化する

高信頼AIではEvaluation Datasetが非常に重要になる。

過去のFailure。

典型Case。

Edge Case。

Critical Case。

を蓄積する。

例えばPythonでは、

from dataclasses import dataclass
@dataclass
class EvalCase:
   case_id: str
   input_text: str
   expected_status: str
   severity: str

のようにTest Caseを構造化できる。

重要なのはCodeではなく、

Failure Experienceを再利用可能なEvaluation Assetへ変えること

である。

⸻

Regressionを防ぐ

新しいModelは全体では高性能でも、一部Critical Taskで性能が落ちることがある。

そこでModel変更のたびに過去Testを再実行する。

Current Model
   ↓
Regression Suite
Candidate Model
   ↓
Regression Suite
↓
Compare

これによって、

「新しくしたら重要なTaskが壊れた」

という問題をRelease前に発見する。

⸻

Continuous Evaluation

Productionへ出した後も評価は続く。

Model。

Prompt。

Knowledge Base。

User。

Environment。

すべてが変化するからである。

したがって、

Evaluation is not a phase.
Evaluation is a runtime capability.

である。

⸻

Evidenceを残す

LLMが回答した。

しかし高信頼Systemでは、回答だけでは不十分である。

何を根拠にしたのかを保持する。

例えば、

{
 "answer": "review required",
 "evidence_ids": ["doc-102", "doc-231"],
 "model_version": "v3",
 "confidence": 0.71
}

という構造にする。

HumanはEvidenceを確認できる。

後からAuditもできる。

⸻

EvidenceとExplanationを分ける

AIが説明文を生成したからといって、それが根拠とは限らない。

そこで、

Explanation

と、

Evidence

を分離する。

ExplanationはHuman理解のため。

Evidenceは検証のため。

高信頼AIではEvidenceの方が重要になる場合がある。

⸻

Source Traceability

RAGを使う場合、

どのDocument。

どのVersion。

どのChunk。

を参照したか記録する。

Answer
 ↓
Source Document
 ↓
Document Version
 ↓
Retrieved Section

Knowledgeが更新された後でも、当時の判断を再現できるようにする。

⸻

Versionをすべて持つ

AI Systemでは、Behaviorを決める要素が多い。

Code Version。

Model Version。

Prompt Version。

Knowledge Version。

Configuration Version。

それらを記録する。

つまり、

Decision State
=
Code
+ Model
+ Prompt
+ Knowledge
+ Config

である。

⸻

Human Oversight

高信頼AIではHumanをSystemへ明示的に組み込む。

AIが提案する。

Humanが確認する。

ApproveまたはRejectする。

例えば、

AI Result
  ↓
Risk Check
  ↓
Human Review
  ↓
Approve / Reject

である。

⸻

Humanを万能なSafety Layerにしない

しかし「最後にHumanが見る」だけでは不十分である。

大量のOutputを毎日確認すれば、Humanは疲れる。

AIを過信する。

見落とす。

そこでHuman Review自体も設計する。

High-risk Caseだけ強制Review。

Evidenceを強調表示。

低Confidenceを自動Escalation。

Second Reviewerを要求。

つまり、

Human Review must be engineered.

⸻

Automation Biasを抑える

HumanはAIが何度も正解すると、AIを信頼しすぎる傾向がある。

そこでUI側で、

Confidence。

Evidence。

Warning。

Contradiction。

を見せる。

AIのAnswerだけを大きく表示しない。

Humanが自分で判断できるInterfaceへする。

⸻

Uncertaintyを表現する

AIが常に一つの答えを出す必要はない。

例えば、

PASS
REVIEW_REQUIRED
INSUFFICIENT_EVIDENCE
REJECT

という状態を持たせる。

特に、

INSUFFICIENT_EVIDENCE

を第一級のOutputとして扱う。

「分からない」をSystem Behaviorとして実装する。

⸻

Confidence Threshold

例えば、

def decide(confidence: float) -> str:
   if confidence >= 0.90:
       return "pass"
   if confidence >= 0.60:
       return "review_required"
   return "insufficient_evidence"

のようなThresholdを置ける。

ただし実際のThresholdはDomain Evaluationによって決める。

単なる数値設定ではなくRisk Designである。

⸻

Deterministic Ruleを使う

Critical RuleまでLLMへ任せない。

例えば、

def can_auto_approve(risk_level: str) -> bool:
   return risk_level == "low"

というように、明確なPolicyはDeterministic Logicで扱う。

つまり、

Probabilistic AI + Deterministic Guardrail

というHybrid Architectureである。

⸻

Guardrail

Guardrailには複数種類がある。

Input Guardrail。

Output Guardrail。

Tool Permission。

Policy Check。

Safety Check。

例えば、

User Input
  ↓
Input Policy
  ↓
AI
  ↓
Output Validation
  ↓
Business Rule
  ↓
Action

とする。

AIをSystemの中で囲う。

⸻

Tool Useでは権限を限定する

AgentがToolを使える場合、Riskはさらに高まる。

検索だけできるAgent。

Draftだけ作れるAgent。

DB更新できるAgent。

Robotを動かせるAgent。

同じではない。

そこで、

Agent Capability
       ↓
Permission Policy
       ↓
Allowed Action

とする。

⸻

Least Privilege

Securityの基本原則として、

必要最小限の権限だけを与える。

例えばAgentにDB Readが必要なら、

Write Permissionは与えない。

一部TableだけAccessさせる。

期間限定Tokenを使う。

AI AgentにもLeast Privilegeを適用する。

⸻

AuthenticationとAuthorization

UserとAI Agent双方にIdentityを持たせる。

誰がRequestしたのか。

どのAgentがActionしたのか。

どのRoleを使ったのか。

を記録する。

つまり、

User Identity
     ↓
Agent Identity
     ↓
Permission
     ↓
Action

というChainを作る。

⸻

Audit Log

高信頼AIでは、Actionの記録が重要になる。

例えばSQLでは、

CREATE TABLE audit_events (
   event_id TEXT PRIMARY KEY,
   actor_id TEXT NOT NULL,
   action_type TEXT NOT NULL,
   model_version TEXT,
   created_at TIMESTAMP NOT NULL
);

のように記録できる。

ただし重要なのはSchemaではなく、

AI Actionを後から追跡可能にすること

である。

⸻

Audit Trail

より完全には、

Request
↓
Authentication
↓
Retrieved Evidence
↓
Model Output
↓
Validation
↓
Human Approval
↓
Action
↓
Result

を一つのTraceとして保持する。

これがDecision Audit Trailになる。

⸻

Data Governance

高信頼AIではData自体の信頼性も重要である。

どこから来たDataか。

誰が更新したか。

いつ有効になったか。

どこまで利用してよいか。

を管理する。

つまり、

Trusted AI requires trusted data provenance.

⸻

Data Classification

DataをRisk Levelで分類する。

Public
Internal
Confidential
Highly Confidential
Regulated

そしてAI Serviceごとに扱えるClassを制限する。

例えばPublic APIへRegulated Dataを送らない。

⸻

Model Gateway

複数Modelを直接Applicationから呼ばず、Gatewayを置く方法もある。

Application
   ↓
Model Gateway
   ├─ Public LLM
   ├─ Private LLM
   └─ Local LLM

Gatewayで、

Routing。

Logging。

Security。

Evaluation。

を統一する。

⸻

Data SensitivityによるRouting

例えば、

Public Data       → Public Model
Confidential Data → Private Model
Critical Data     → Local Model

のようなPolicyを持つ。

これによってSecurity RequirementをRuntimeへ埋め込む。

⸻

Fallback

Productionでは外部Modelが停止する可能性がある。

そこでFallbackを設計する。

Primary Model
   ↓ failure
Secondary Model
   ↓ failure
Human Queue

重要Taskでは「何も返せない」状態にも対応する。

⸻

Circuit Breaker

外部Serviceが失敗し続ける場合、無限Retryしない。

一定回数Failureしたら呼び出しを止める。

Healthy
↓ repeated failure
Open Circuit
↓ recovery check
Healthy

これはTraditional Distributed Systemの原則だが、AI Systemにもそのまま必要になる。

⸻

Timeout

LLMやToolが永遠に応答しない可能性を想定する。

Timeoutを設定する。

Retry回数を制限する。

つまり、

AI Call is an unreliable network call.

として扱う。

⸻

Observability

高信頼AIでは、System状態を観測できなければならない。

見るべきMetricには、

Latency。

Error Rate。

Model Usage。

Token Usage。

Retrieval Success。

Human Correction Rate。

Critical Failure Rate。

などがある。

⸻

AI固有のRuntime Metric

例えば、

retrieval_hit_rate
citation_coverage
schema_failure_rate
human_rejection_rate
critical_error_rate

をMonitorする。

CPUやMemoryだけ見てもAI Qualityは分からない。

⸻

Human Correction Rate

HumanがAI Outputを何回修正したか。

これは非常に重要なMetricになる。

修正率が急に上がれば、

Model Change。

Knowledge Update。

Prompt Change。

に問題がある可能性がある。

Human FeedbackがMonitoring Signalになる。

⸻

Drift

Production Dataは変化する。

User Behaviorも変わる。

Documentも変わる。

Sensor Environmentも変わる。

するとTraining時と分布がずれる。

これがDriftである。

Training Distribution
      ↓
Production Distribution
      ↓
Drift Detection

必要なら再Evaluationする。

⸻

Incident Response

高信頼AIではIncidentが起きた後のProcessも定義する。

Detect。

Contain。

Investigate。

Recover。

Learn。

例えば、

Incident
 ↓
Stop / Limit
 ↓
Root Cause
 ↓
Rollback
 ↓
Evaluation Update

とする。

⸻

Postmortem

Incidentを直して終わりにしない。

なぜ起きたか。

なぜ検知できなかったか。

どう再発防止するか。

を分析する。

そしてFailure CaseをEvaluation Suiteへ追加する。

つまり、

Incident → Permanent Test Case

へ変換する。

⸻

Controlled Change

AI Systemは継続的に改善する。

しかしProduction中に自由に変化させない。

Modelを更新する。

Offline Evaluationする。

Stagingで確認する。

Canary Releaseする。

問題があればRollbackする。

Learn Continuously
      ↓
Evaluate
      ↓
Approve
      ↓
Deploy Carefully

である。

⸻

Safety Caseという考え方

Physical AIのような高Risk Systemでは、

「このSystemはなぜ安全だと考えるのか」

を構造化する必要がある。

Sensor。

AI。

Control。

Guardrail。

Human Override。

Emergency Stop。

それぞれの役割を整理する。

AI Model単体の性能ではなく、System全体のSafety Argumentを持つ。

⸻

Physical AIでは高信頼性がさらに厳しくなる

RobotがPhysical WorldへActionする場合、

誤回答ではなく誤動作になる可能性がある。

そこで、

AI Planning
  ↓
Safety Rule
  ↓
Collision Check
  ↓
Control
  ↓
Physical Action

のように複数Layerを置く。

⸻

Fail-safe

何かが壊れたら、安全側へ移る。

Networkが切れる。

Sensorが故障する。

Modelが判断できない。

その場合、

停止する。

Low-risk Modeへ移る。

Human Operationへ戻す。

これがFail-safeである。

⸻

Fail-operationalとの違い

Systemによっては停止そのものが危険な場合もある。

その場合は一部機能を維持する必要がある。

つまり、

Fail-safe

と、

Fail-operational

をRequirementに応じて選ぶ。

高信頼AIはFailure時のBehaviorまで設計する。

⸻

Redundancy

Critical Systemでは、一つのAIに依存しない。

複数Sensor。

Rule-based Check。

Second Model。

Human Verification。

を組み合わせる。

例えば、

Model A
  +
Model B
  +
Rule Check
  +
Human

一致しない場合はActionしない。

⸻

Diversityによる信頼性

同じArchitectureのModelを二つ使っても、同じFailureを起こす可能性がある。

場合によっては、

ML Model。

Rule-based System。

Human。

のように異なるFailure Modeを持つComponentを組み合わせる。

これはSystem Reliabilityの考え方である。

⸻

High Reliability Organization

高信頼AIには、高信頼なOrganizationも必要になる。

EngineerがWarningを無視する。

Incidentを報告しない。

Deliveryを優先してTestを省略する。

これではArchitectureが良くても信頼性は維持できない。

したがって、

Trusted AI = Technical System + Operational Culture

である。

⸻

Release Authority

誰がProduction Releaseを承認するのか。

Researcher。

Engineer。

Domain Expert。

Security。

Business Owner。

Riskに応じて複数Roleを設定する。

Technical Decisionだけで完結させない。

⸻

Responsibility Boundary

AIが提案した。

Humanが承認した。

Systemが実行した。

問題が起きた。

誰が何へ責任を持つのかを事前に定義する。

高信頼AIでは、

Capability

Authority

Accountability

を分離する。

⸻

Performance・Safety・CostのBalance

最も高性能なSystemが最適とは限らない。

巨大Modelは高性能だが高Cost。

Local Modelは低Latencyだが性能が低い。

Human Reviewは安全だが時間がかかる。

そこで、

Performance
Reliability
Safety
Cost
Latency

を総合して設計する。

⸻

高信頼AIは「AIを使わない判断」も含む

場合によっては、

このTaskではAIを使わない。

Rule-based Systemにする。

Human Decisionだけにする。

という判断もある。

AI導入そのものを目的にしない。

No AI can also be a valid architecture decision.

⸻

Trusted by Default

毎回Projectの最後に信頼性を追加するとCostが大きい。

そこで共通基盤へ組み込む。

Identity。

Logging。

Evaluation。

Audit。

Human Approval。

Security。

をStandard Componentとして持つ。

Trusted Core
├─ Identity
├─ Model Gateway
├─ Evaluation
├─ Audit
├─ Policy
├─ Human Approval
└─ Observability

その上にDomain Applicationを作る。

⸻

EQUES型Trusted Core

第1冊で見たEQUESの方向をArchitectureへ翻訳すると、

製薬。

Energy。

Physical AI。

それぞれに共通するのは、

高いFailure Costを持つDomainへAIを実装すること

である。

したがって再利用可能なCoreとして、

Evaluation。

Traceability。

Security。

Human Oversight。

Controlled Deployment。

を持つ意味がある。

⸻

高信頼AIの最小構造

本節を最小化すると、

Input
↓
Validation
↓
AI
↓
Evidence
↓
Evaluation / Guardrail
↓
Human or Policy Decision
↓
Action
↓
Audit
↓
Runtime Monitoring
↓
Feedback

となる。

このLoop全体がHigh-reliability AI Systemである。

⸻

高信頼AIとは、絶対に間違えないAIを作ることではない。

現実のAIは間違える。

Dataも間違える。

Humanも間違える。

だから、

間違いを測る。
発見する。
影響を限定する。
Humanへ戻す。
記録する。
学習する。

というArchitectureを持つ。

そこに「信頼」が生まれる。

そしてAIがDigital DocumentやEnterprise Workflowの中だけに存在する間は、Failureの多くをSoftware Layerで封じ込めることができる。

しかしAIがSensorを通じてRealityを観測し、Robotを通じて現実へActionするようになると、信頼性の意味はさらに変わる。

次節では、その境界を越える。

SoftwareからPhysical AIへ。

Cloud、Edge、Sensor、Robot、Human、安全制御を一つのCyber-Physical Architectureとして接続していく。
第5節　SoftwareからPhysical AIへ

これまでのAIは、主としてデジタル空間の中で働いてきた。

文章を生成する。

画像を分類する。

Databaseを検索する。

Documentを検査する。

企業Workflowを支援する。

AIが誤ったとしても、そのOutputが情報の段階に留まる限り、Human ReviewやSoftware上のValidationによって影響を止められる場合が多い。

しかしAIがCamera、LiDAR、Sensor、Robot、Industrial Equipmentへ接続されると、条件は根本的に変わる。

AIのOutputが、

Physical Action

になるからである。

ここにSoftware AIとPhysical AIの境界がある。

⸻

Software AI

Software AIの基本構造は比較的単純である。

Digital Input
    ↓
AI Model
    ↓
Digital Output

Textを入力する。

LLMが処理する。

Textを返す。

あるいはImageを入力し、Classification Resultを返す。

InputとOutputの双方がDigital Worldに存在する。

⸻

Physical AI

Physical AIではLoopが閉じる。

Physical World
     ↓
Sensor
     ↓
Digital Representation
     ↓
AI
     ↓
Decision / Planning
     ↓
Control
     ↓
Machine
     ↓
Physical World

現実世界を観測する。

AIが理解する。

Actionを決める。

Machineが動く。

その結果によってRealityが変わる。

そして変化したRealityを再びSensorが観測する。

Physical AIとは、このClosed Loopの中へAIを組み込むことである。

⸻

Physical Worldを直接理解しているわけではない

AIが見るのはRealityそのものではない。

Camera Image。

Point Cloud。

Temperature。

Pressure。

Vibration。

Force。

Position。

といったMeasurementである。

したがって、

Physical Reality ≠ Sensor Representation

という境界を保持する必要がある。

Sensorが見えていないものを、AIも見ることはできない。

⸻

Sensor Failure

Physical AIではModel Errorだけを考えても足りない。

Camera Lensが汚れる。

LiDARが遮られる。

Calibrationがずれる。

Sensorが故障する。

Network Packetが欠落する。

つまり、

Physical State
     ↓
Sensor Error
     ↓
Incorrect Representation
     ↓
AI Decision

というFailure Chainが存在する。

AIが正しく推論していても、Input自体が誤っている可能性がある。

⸻

Sensor Fusion

一つのSensorへ依存しない方法として、複数Sensorを統合する。

Camera ─────┐
LiDAR ──────┤
Force ──────┼→ Sensor Fusion → World State
Position ───┤
Audio ──────┘

Cameraは色や形を見る。

LiDARはDistanceやGeometryを見る。

Force Sensorは接触を測る。

複数のRepresentationを統合することで、Environmentをより頑健に認識できる。

⸻

Point Cloud

LiDARやDepth Sensorから得られる3D情報はPoint Cloudとして表現できる。

概念的には、

points = [
   (x1, y1, z1),
   (x2, y2, z2),
   (x3, y3, z3),
]

である。

ここから、

Object。

Surface。

Obstacle。

Free Space。

を認識する。

Physical AIでは、Text Tokenだけでなく3D GeometryがAI Inputになる。

⸻

Perception

Sensor DataをPhysical Meaningへ変換するLayerがPerceptionである。

Raw Sensor
   ↓
Preprocessing
   ↓
Detection
   ↓
Tracking
   ↓
Scene Understanding

例えば、

人がいる。

Valveがある。

Obstacleがある。

Robot Armがこの位置にある。

というStateへ変換する。

⸻

World Model

より高度なSystemでは、瞬間的なSensor Inputだけでなく、Environmentの内部Representationを保持する。

位置。

Object。

Relationship。

History。

これらを統合したものをWorld Modelとして扱える。

Observation
   ↓
World State
   ↓
Prediction
   ↓
Planning

AIは「今何が見えているか」だけでなく、「次に何が起こり得るか」を扱うようになる。

⸻

PerceptionからActionへ

Physical AIで重要なのは、認識だけではない。

Perception
   ↓
Reasoning
   ↓
Planning
   ↓
Action

まで進む。

ここでGenerative AI、Agent、Roboticsが接続する。

⸻

VLA

近年のPhysical AIで重要な方向の一つがVision-Language-Actionである。

VisionでEnvironmentを見る。

LanguageでInstructionを理解する。

Actionを生成する。

概念的には、

Vision
  +
Language
  ↓
Model
  ↓
Action

となる。

例えば、

「赤い箱を棚へ移す」

というInstructionとCamera Imageを入力し、Robot Actionへ変換する。

⸻

しかしModelからMotorへ直接つながない

高信頼Physical AIでは、

VLA
↓
Motor

という直接接続を避けるべき場合が多い。

間にSafety Layerを置く。

AI Planning
    ↓
Safety Validation
    ↓
Motion Planning
    ↓
Control
    ↓
Actuator

AIが提案したActionを、そのままPhysical Actionにしない。

⸻

PlanningとControlを分ける

AIが、

「Robot Armを対象物へ移動する」

と判断する。

しかし、

どの軌道で移動するか。

どの速度にするか。

どのTorqueを使うか。

どう停止するか。

はControl Engineeringの問題になる。

したがって、

AI Planning ≠ Control

である。

⸻

Classical Controlは残る

Physical AIが高度化しても、従来のControl Engineeringが不要になるわけではない。

PID。

State Estimation。

Trajectory Planning。

Constraint Control。

Emergency Stop。

確立されたEngineeringを利用する。

つまり、

AI
+
Classical Robotics
+
Control Engineering

というHybrid Systemになる。

⸻

Deterministic Safety Layer

Safety Constraintは、可能な限りAIとは独立して持つ。

例えば、

def is_safe(speed: float, distance: float) -> bool:
   if distance < 0.5 and speed > 0.1:
       return False
   return True

実際の安全制御ははるかに複雑だが、原則は同じである。

SafetyをAIの判断だけへ委ねない。

⸻

Human Override

Physical AIではHumanが即座に介入できることも重要になる。

AIが異常Actionを開始する。

Operatorが停止する。

Manual Modeへ切り替える。

AI Control
  ↓
Human Override
  ↓
Safe State

Human OverrideはUI FeatureではなくSafety Architectureの一部である。

⸻

Emergency Stop

Physical Systemでは、最終的に物理的な停止機構が必要になる場合がある。

Softwareが壊れている。

AIが誤動作する。

Networkも利用できない。

その状況でも停止できる。

つまり、

Physical Safety must not depend entirely on AI.

である。

⸻

Edge AI

Physical AIではLatencyが重要になる。

Camera ImageをCloudへ送る。

AIが処理する。

結果を返す。

これでは遅すぎるTaskがある。

Collision Avoidance。

Emergency Detection。

Real-time Control。

そこでComputeをMachineの近くへ置く。

Cloud
 ⇅
Edge Computer
 ⇅
Robot / Sensor

これがEdge AIである。

⸻

CloudとEdgeの役割分担

すべてをEdgeへ置く必要もない。

Edgeでは、

Real-time Perception。

Safety-critical Processing。

Local Control。

Cloudでは、

Large-scale Training。

Fleet Analytics。

Long-term Storage。

Model Management。

を行う。

つまり、

Cloud
├─ Training
├─ Analytics
└─ Model Management
Edge
├─ Perception
├─ Local Inference
└─ Real-time Decision

という分業になる。

⸻

Rustが有効になる場所

Physical AIでは、

Low Latency。

Concurrency。

Memory Safety。

Hardware Interface。

Long-running Process。

が重要になる。

ここでRustが有効になる場合がある。

例えば、

Python
└─ Research / Training / Model Evaluation
Rust
└─ Edge Runtime / Device Service / High-performance Processing

というRole Separationが考えられる。

Pythonを捨てるのではなく、Runtime Requirementに応じて接続する。

⸻

Message-driven Architecture

Physical Systemでは複数Componentが同時に動く。

Camera。

LiDAR。

Inference。

Planner。

Controller。

Logger。

そこでEventやMessageによって接続する。

Camera
 ↓
Image Event
 ↓
Perception
 ↓
Object Event
 ↓
Planner
 ↓
Action Command

Componentを疎結合にすることで、交換やFailure Isolationを容易にする。

⸻

Timeが第一級Dataになる

Enterprise AIでは数秒のLatencyでも許容されるTaskがある。

Physical AIでは、

10ms。

50ms。

100ms。

という時間差がSystem Behaviorを変える。

したがってDataには、

Valueだけでなく、

Timestamp

が重要になる。

古いSensor Dataを最新Stateとして扱ってはいけない。

⸻

Synchronization

複数Sensorを統合する場合、それぞれのTimestampを揃える必要がある。

Cameraはこの瞬間。

LiDARは少し前。

Position Sensorはさらに別の時刻。

これを無視すると、存在しないWorld Stateを作ってしまう可能性がある。

Physical AIでは、

Space + Time

を一体として扱う。

⸻

Network Failure

CloudとのConnectionは必ず使えるとは限らない。

Networkが切れた場合、

停止するのか。

Local Modeで続けるのか。

HumanへControlを戻すのか。

あらかじめ決める。

Connected
  ↓ network failure
Local Safe Mode
  ↓
Reconnect / Human Decision

Connectivity Failureも通常状態の一つとして設計する。

⸻

Digital Twin

Physical AssetをDigital Representationとして保持する考え方がDigital Twinである。

例えば、

Physical Equipment
      ⇅
Digital State

設備状態。

Sensor History。

Maintenance History。

Current Configuration。

をDigital側へ保持する。

AIはこのRepresentation上で分析やSimulationを行える。

⸻

Simulation

Physical Worldで直接ExperimentすることはCostやRiskが高い。

そこでSimulationを利用する。

Robot Motion。

Sensor Noise。

Obstacle。

Failure。

Environment Variation。

をDigital Environmentで再現する。

Simulation
   ↓
Training / Testing
   ↓
Controlled Field Test
   ↓
Reality

という段階を踏む。

⸻

Sim-to-Real

Simulationで学習したAIをRealityへ移す。

しかしSimulationとRealityは完全には一致しない。

Lighting。

Friction。

Sensor Noise。

Material。

Human Behavior。

差がある。

これがReality Gapである。

⸻

Real-to-Sim

逆方向も重要である。

RealityでFailureが起きる。

その状況をSimulationへ戻す。

Variationを大量生成する。

改善したAIを再びRealityへ出す。

Reality
  ↓
Failure
  ↓
Simulation
  ↓
Improvement
  ↓
Reality

ここでもResearchとProductionの循環が成立する。

⸻

Physical AIのEvaluation

Model Accuracyだけでは評価できない。

Task Completion Rate。

Collision Rate。

Intervention Rate。

Control Latency。

Energy Consumption。

Recovery Rate。

などを見る。

つまり、

Model Evaluation → System Evaluation → Physical Outcome Evaluation

へ広がる。

⸻

Human Intervention Rate

Humanが何回介入したかは重要なMetricになる。

介入が多すぎればAutonomyが不足している。

しかし介入がゼロだから安全とも限らない。

必要なときにHumanへEscalateできているかを見る。

⸻

Safety Envelope

Robotに許可するOperation範囲を限定する。

位置。

速度。

Force。

Area。

Task。

例えば、

Allowed Workspace
Allowed Speed
Allowed Force
Allowed Actions

を定義する。

AIはこのSafety Envelopeの内部だけでActionできる。

⸻

Adaptive Autonomy

すべてを完全自律にする必要はない。

Low-risk Taskは自動。

Medium-risk TaskはHuman Supervision。

High-risk TaskはHuman Control。

Risk
↓
Autonomy Level

と対応させる。

Physical AIではAutonomyそのものを調整可能なSystem Propertyとして扱う。

⸻

Remote Operation

原子力施設や危険Environmentでは、完全自律だけでなくRemote Operationが重要になる。

Humanが安全な場所からRobotを操作する。

AIは、

Perception。

Stabilization。

Path Suggestion。

Anomaly Detection。

を支援する。

つまり、

Human + AI + Robot

というSystemになる。

⸻

Haptics

Remote OperationではVisual Informationだけでなく、ForceやTouchをHumanへ返すこともできる。

Robotが受けたResistance。

Surface Contact。

Force。

これをHumanへ伝える。

Physical Contact
     ↓
Sensor
     ↓
Digital Signal
     ↓
Haptic Interface
     ↓
Human

DigitalとHuman Bodyの間にPhysical Feedback Channelが形成される。

⸻

Physical AIとHuman-centered Design

Robotの性能だけを最大化すればよいわけではない。

Operatorが理解できるか。

警告に気づけるか。

Controlを取り戻せるか。

長時間Operationできるか。

Human Factorsが重要になる。

Physical AIは、

AI Engineering + Robotics + Human Factors

の統合領域である。

⸻

CybersecurityとPhysical Safetyが接続する

Software AIへのCyberattackはData Leakを引き起こす可能性がある。

Physical AIでは、それがPhysical Actionへつながる可能性もある。

Unauthorized Command。

Sensor Spoofing。

Compromised Model。

したがって、

Cybersecurity
     ↓
Control Integrity
     ↓
Physical Safety

が接続する。

⸻

IdentityからMachine Authorityへ

誰がRobotを操作できるのか。

どのAgentがどのMachineへCommandを送れるのか。

どのTaskまで許可されているのか。

IdentityとPermissionをPhysical Actionまで拡張する。

Identity
  ↓
Authorization
  ↓
Action Permission
  ↓
Machine

これはEnterprise AIのAccess ControlをPhysical Worldへ延長した構造である。

⸻

AuditもPhysical Worldへ伸びる

AIが何を判断したか。

どのCommandを送ったか。

Robotが何を実行したか。

HumanがOverrideしたか。

最終的に何が起きたか。

これらを一つのTraceとして残す。

Sensor
↓
AI Decision
↓
Command
↓
Robot Action
↓
Human Intervention
↓
Physical Outcome

高信頼Physical AIでは、Audit TrailもCyber-Physicalになる。

⸻

Software UpdateがMachine Behaviorを変える

通常のWeb ApplicationではSoftware Updateによって画面や機能が変わる。

Physical AIではModel UpdateによってMachine Behaviorが変わる。

Perceptionが変わる。

Planningが変わる。

Actionが変わる。

したがって、

Model Update = Potential Physical Behavior Change

として扱う必要がある。

⸻

OTA UpdateにもValidationが必要になる

Fleetへ新しいModelを配布する場合、

Offline Evaluation。

Simulation。

Hardware-in-the-loop Test。

Limited Deployment。

Monitoring。

を経て広げる。

New Model
  ↓
Simulation
  ↓
Hardware Test
  ↓
Limited Fleet
  ↓
Evaluation
  ↓
Full Deployment

Software DeliveryとSafety Engineeringが一つになる。

⸻

Physical AIは一つの巨大Modelではない

Physical AIを、すべてを処理する巨大Foundation Modelとして考える必要はない。

実際には、

Sensor
+
Perception Model
+
World Model
+
Planner
+
Rules
+
Controller
+
Human

という複数ComponentのSystemになることが多い。

VLAもその中の重要なComponentの一つとして配置できる。

⸻

General ModelとIndustrial Controlを分離する

General-purpose Modelは柔軟である。

Industrial Controlは予測可能性が必要である。

そこで、

General Intelligence
      ↓
Task Planning
      ↓
Constrained Execution Layer
      ↓
Physical Control

という階層を作る。

柔軟なIntelligenceと厳格なExecutionを分離する。

⸻

Software AIとの連続性

ここまで見るとPhysical AIは全く別のTechnologyに見える。

しかし前節までのArchitectureはそのまま残っている。

Identity。

Security。

Evaluation。

Audit。

Human Approval。

Observability。

Data Governance。

これらに、

Sensor。

Edge。

Control。

Safety。

Robot。

が追加される。

つまりPhysical AIは、

Trusted Software AIをPhysical Worldまで拡張したArchitecture

として理解できる。

⸻

EQUES型Physical AI

EQUES型実装として一般化するなら、重要なのはRobot Hardwareそのものをすべて自社開発することではない。

AI Research。

Domain Knowledge。

Edge Runtime。

Evaluation。

Safety。

Human Interface。

Partner Hardware。

を接続することである。

つまり、

Research Intelligence
      ↓
Industrial Architecture
      ↓
Physical Interface
      ↓
Trusted Action

へ進む。

⸻

DigitalからPhysicalへの境界

この境界を最小化すると、

Software AI
Data
↓
Model
↓
Information
Physical AI
Reality
↓
Sensor
↓
Model
↓
Planning
↓
Safety
↓
Control
↓
Action
↓
Reality

となる。

Physical AIでは、Outputが次のInputを生み出す。

ActionがRealityを変え、そのRealityをAIが再び観測するからである。

⸻

Closed-loop Intelligence

したがってPhysical AIの核心はRobotそのものではない。

Closed-loop Intelligence

である。

Observe
 ↓
Understand
 ↓
Plan
 ↓
Act
 ↓
Observe

このLoopを安全に、継続的に、現実世界の時間の中で回す。

⸻

研究室でModelが動く。

Cloud上でAI Serviceになる。

Enterprise Workflowへ組み込まれる。

Humanと協働する。

そしてSensorとMachineへ接続される。

ここまで進むと、AIは単なるSoftware Componentではなく、現実世界の状態変化へ参加するSystemになる。

だからPhysical AIでは、Intelligenceの高さだけでは足りない。

AIが何を認識し、何を判断し、何を実行でき、どこで停止し、誰が介入できるのか。

その境界をArchitectureとして定義しなければならない。

SoftwareからPhysical AIへ進むとは、AIに身体を与えることだけではない。

Digital Intelligenceへ、現実世界に対する責任あるAction Boundaryを与えることなのである。

次節では、このSoftware AIからPhysical AIまでを一つの産業システムとして成立させるために必要な全体構造――Research-to-Production Architectureを統合する。
第6節　Research-to-Production Architecture

AI研究を産業システムへ変えるには、研究コード、Model、Data、Cloud、Human、Security、Evaluation、Operationを一つの流れとして接続する必要がある。

研究段階では、各要素を分離して考えることができる。

Modelを作る。

Accuracyを測る。

結果をNotebookへ表示する。

しかしProductionでは、それぞれが相互依存する。

Dataが変わればModel Outputが変わる。

Modelが変わればEvaluationが必要になる。

Evaluation ResultによってRelease可否が変わる。

Release後はHuman Feedbackが発生する。

そのFeedbackが次のResearchへ戻る。

したがってResearch-to-Production Architectureとは、単なるDeployment Pipelineではない。

ResearchとProductionの間に継続的な双方向Loopを構築するArchitectureである。

⸻

最小構造

全体を最小化すると、

Research
  ↓
Experiment
  ↓
Evaluation
  ↓
Domain Adaptation
  ↓
Production
  ↓
Observation
  ↓
Feedback
  ↓
Research

となる。

重要なのは、Productionが終点ではないことだ。

Productionは、次のResearch Dataを生む地点でもある。

⸻

Research Layer

最上流にはResearch Layerがある。

ここでは、

Paper。

Algorithm。

Foundation Model。

Fine-tuning。

RAG。

Optimization。

Robot Learning。

などを検証する。

目的は、

What could work?

を明らかにすることである。

Research Layerでは自由度を高く保つ。

新しいLibraryを試す。

Modelを交換する。

Experimentを高速に回す。

⸻

Experiment Layer

Research Ideaを実行可能なExperimentへ変える。

例えば、

def run_experiment(model, dataset, evaluator):
   outputs = model.predict(dataset.inputs)
   return evaluator.evaluate(outputs, dataset.targets)

ここでは、

Dataset。

Model。

Configuration。

Metric。

を明示する。

重要なのはExperimentを再現可能にすることである。

⸻

Experiment Tracking

研究が増えると、

どのModelを使ったのか。

どのData Versionだったのか。

どのHyperparameterだったのか。

何点だったのか。

を追跡する必要がある。

Experiment
├─ code_version
├─ model_version
├─ dataset_version
├─ config
└─ metrics

これがResearch Memoryになる。

⸻

Research Artifact

ExperimentからProductionへ渡すものは、Notebookそのものではない。

Validated Model。

Evaluation Result。

Known Limitation。

Input / Output Schema。

Resource Requirement。

これらをまとめたResearch Artifactとして扱う。

つまり、

Research Result → Transferable Artifact

へ変換する。

⸻

Technology Readinessを判定する

新しいMethodが面白いからといって、すぐProductionへ出すわけではない。

例えば、

Experimental
   ↓
Reproducible
   ↓
Domain Validated
   ↓
Production Candidate

という段階を設ける。

このGateによって、Research SpeedとProduction Reliabilityを分離する。

⸻

Domain Adaptation Layer

次にGeneral TechnologyをDomainへ適応する。

製薬なら、

専門Knowledge。

Document。

GMP Workflow。

Domain Evaluation。

Energyなら、

Sensor。

Equipment。

Maintenance。

Safety。

を組み込む。

ここで問いは、

Can it work?

から、

Can it work here?

へ変わる。

⸻

Domain Adapter

General Modelを直接Applicationへ結合するのではなく、Domain Adapterを置く。

General Model
    ↓
Domain Adapter
    ↓
Domain Application

Domain Adapterには、

Prompt。

RAG。

Ontology。

Business Rule。

Output Schema。

を配置できる。

これによってModel変更とDomain Logicを分離する。

⸻

Evaluation Gate

Domain Adaptation後にはEvaluation Gateを置く。

Candidate
  ↓
General Evaluation
  ↓
Domain Evaluation
  ↓
Critical Case Evaluation
  ↓
Go / No-Go

ここを通過しなければProduction Candidateにはしない。

⸻

Production Candidate

Production CandidateになったAI Componentには、少なくとも以下が必要になる。

Input Schema。

Output Schema。

Model Version。

Known Limitation。

Performance Profile。

Security Requirement。

Fallback Behavior。

つまり、

AI CapabilityをOperational Contractへ変える。

⸻

Service Layer

ModelをApplicationから直接呼び出さず、Serviceとして包む。

Application
   ↓
AI Service
   ↓
Model / RAG / Tool

AI Serviceは、

Validation。

Logging。

Model Routing。

Timeout。

Retry。

を担当する。

⸻

API Contract

例えば、

from pydantic import BaseModel
class ReviewRequest(BaseModel):
   document_id: str
   text: str
class ReviewResponse(BaseModel):
   status: str
   evidence_ids: list[str]
   requires_human_review: bool

Modelの自由なOutputを、安定したSoftware Contractへ変える。

⸻

Model Gateway

複数Modelを扱う場合はGatewayを置く。

AI Service
  ↓
Model Gateway
  ├─ General LLM
  ├─ Domain LLM
  ├─ Local LLM
  └─ Fallback Model

ここで、

Security。

Cost。

Latency。

Task Complexity。

に応じてRoutingする。

⸻

Data Layer

ProductionではDataを正式なSystem Assetとして管理する。

Relational Data。

Document。

Vector Index。

Sensor Stream。

Audit Log。

それぞれ異なるStorageへ配置する。

SQL
 └─ authoritative state
Object Storage
 └─ documents / large files
Vector DB
 └─ semantic retrieval
Time-series / Stream
 └─ sensor data

用途によってStorageを分ける。

⸻

Authoritative State

AIが生成した内容と、正式なBusiness Stateを混同しない。

例えば、

AIが「承認可能」と出力する。

しかし正式なApproval StateはDatabaseが保持する。

AI Recommendation
     ↓
Human / Policy Decision
     ↓
SQL Authoritative State

つまり、

AI Output ≠ Authoritative State

である。

⸻

Workflow Layer

AIを業務Processへ接続する。

例えば、

Document Uploaded
     ↓
AI Analysis
     ↓
Consistency Check
     ↓
Human Review
     ↓
Approval
     ↓
Record

ここでAgentやWorkflow Engineが役割を持つ。

⸻

Agent Layer

Agentは複数Taskを接続できる。

検索する。

Toolを呼ぶ。

Draftを作る。

ReviewをRequestする。

ただし自由度を無制限にしない。

Agent
├─ search
├─ analyze
├─ draft
└─ request_approval

許可されたToolだけ使わせる。

⸻

Human Approval Layer

High-risk TaskではHuman ApprovalをArchitectureへ組み込む。

AI
↓
Risk Classification
↓
Human Review Required?
├─ No → Continue
└─ Yes → Review Queue

Humanを後付けではなくWorkflow Componentとして扱う。

⸻

TypeScript Interface

Human ReviewにはInterfaceが必要になる。

AI Outputだけでなく、

Evidence。

Source。

Confidence。

Difference。

History。

を表示する。

つまりUIは、

AI Result Viewer

ではなく、

Decision Interface

として設計する。

⸻

SQLとAudit

正式なState TransitionをSQLへ記録する。

draft
 ↓
review_required
 ↓
approved
 ↓
executed

さらに、

誰が。

いつ。

何を。

変更したか。

をAudit Logへ残す。

⸻

Infrastructure Layer

Production Systemを支えるのがInfrastructureである。

Cloud。

Container。

Network。

Identity。

Secret。

Database。

Monitoring。

GPU。

これらを一つのRuntime Environmentとして設計する。

⸻

Environment Separation

少なくとも、

Development
Staging
Production

を分離する。

Research ExperimentをProduction Dataへ直接接続しない。

Model変更もStagingで検証する。

⸻

CI/CDからCI/CE/CDへ

Traditional Softwareでは、

CI。

Continuous Integration。

CD。

Continuous Delivery。

がある。

AIではさらに、

CE = Continuous Evaluation

を加える。

Code / Model Change
     ↓
CI
     ↓
Continuous Evaluation
     ↓
Staging
     ↓
Controlled Deployment

AIではTestがUnit Testだけでは足りないからである。

⸻

Model Registry

Productionへ出せるModelをRegistryで管理する。

model-a
├─ experimental
├─ validated
└─ production
model-b
└─ candidate

どのModelが正式に利用可能かを明確にする。

⸻

Prompt Registry

LLM SystemではPromptも管理対象になる。

prompt-v1
prompt-v2
prompt-v3

Prompt変更によるBehavior ChangeもEvaluationする。

⸻

Knowledge Version

RAGではKnowledge BaseもVersionを持つ。

Documentが更新された結果、AI Outputが変化する可能性があるからである。

したがって、

Model Versionだけでは再現性を保証できない。

⸻

Deployment Architecture

ProductionへのReleaseは段階的に行う。

Candidate
  ↓
Staging
  ↓
Shadow
  ↓
Canary
  ↓
Limited Production
  ↓
Full Production

Riskに応じて段階数を変える。

⸻

Rollback

ReleaseにはRollbackを必ず対応させる。

Code。

Model。

Prompt。

Configuration。

Knowledge Index。

これらを旧Versionへ戻せるようにする。

⸻

Runtime Layer

Production開始後はRuntimeへ視点を移す。

何件処理しているか。

Latencyは正常か。

Error Rateは上がっていないか。

AI Qualityは落ちていないか。

Human Correctionは増えていないか。

これを観測する。

⸻

Observability

Traditional System MetricとAI Metricの両方を見る。

System
├─ CPU
├─ Memory
├─ Latency
└─ Error Rate
AI
├─ evaluation score
├─ retrieval success
├─ schema failure
├─ human rejection
└─ critical failure

System HealthとAI Qualityを分離しない。

⸻

Trace

一つのRequestをEnd-to-Endで追えるようにする。

Request
↓
User
↓
Agent
↓
Retriever
↓
Model
↓
Human Review
↓
Action

これがRuntime DebuggingとAuditの共通基盤になる。

⸻

Feedback Layer

ProductionでHumanが修正する。

Domain ExpertがRejectする。

Operatorが介入する。

Physical EnvironmentでTaskが失敗する。

これらをFeedback Dataとして保存する。

Runtime
 ↓
Feedback
 ↓
Evaluation Dataset
 ↓
Research

ここでLoopが閉じる。

⸻

Human Feedback

Human Feedbackには、

Correction。

Approval。

Rejection。

Escalation。

Comment。

がある。

これを単なるUI Eventとして捨てず、Research Assetへ変換する。

⸻

Environment Feedback

Physical AIでは、

Task Success。

Collision。

Sensor Failure。

Operator Intervention。

Physical Outcome。

もFeedbackになる。

SoftwareとPhysicalでFeedback Sourceが異なる。

⸻

FeedbackをそのままTrainingへ入れない

Human FeedbackやField DataをそのままModelへ学習させることは危険である。

Noise。

Bias。

Incorrect Label。

Confidential Data。

が含まれる可能性がある。

そこで、

Feedback
  ↓
Validation
  ↓
Curation
  ↓
Evaluation / Training Data

というData Quality Gateを置く。

⸻

Research Backlog

Production FailureをResearch Questionへ変える。

例えば、

Hallucinationが多い。

Retrieval Precisionが低い。

Sensor Noiseに弱い。

Human Reviewが重い。

これらをResearch Backlogへ入れる。

Operational Problem
     ↓
Generalized Technical Question
     ↓
Research Backlog

具体的な障害を一般化することが重要である。

⸻

Researchへ戻す

例えば、

「A社のDocumentで間違えた」

というCaseをそのまま研究課題にはしない。

「長文Document間のCross-document Consistencyをどう改善するか」

へ抽象化する。

これによって一つのCustomer Problemから一般的Technologyを生み出せる。

⸻

Research-to-ProductionではなくResearch-to-Research

ここまで進むと、Architecture全体は直線ではなくなる。

Research
 ↓
Production
 ↓
Reality
 ↓
Feedback
 ↓
Research

つまり本質的には、

Research-to-Production-to-Research Architecture

である。

⸻

Physical AIを含める

Physical AIまで含めると全体はさらに広がる。

Research
  ↓
Model
  ↓
Cloud
  ↓
Edge
  ↓
Sensor
  ↓
Robot
  ↓
Physical Environment
  ↓
Feedback
  ↓
Research

この中にHuman、Safety、Auditが横断Layerとして入る。

⸻

Cross-cutting Layer

全Layerに共通して必要になるものがある。

Security。

Identity。

Evaluation。

Audit。

Observability。

Governance。

これらは後付けではない。

               Security
               Evaluation
               Audit
               Human
                 ↓
Research → Domain → Production → Physical

すべてのLayerを横断する。

⸻

Trusted Core

EQUES型Architectureでは、これらをTrusted Coreとして再利用できる。

Trusted Core
├─ Identity
├─ Security
├─ Model Gateway
├─ Evaluation
├─ Audit
├─ Observability
├─ Approval
└─ Policy

その上にDomain Applicationを作る。

⸻

Domain Layer

Trusted Coreの上に、

Pharma
Energy
Physical AI

のDomain Layerを置く。

Domainごとに、

Knowledge。

Task。

Rule。

Evaluation。

を変える。

つまり、

Common Reliability + Domain Specificity

を両立する。

⸻

Language Stack

本書で扱うLanguageも、このArchitectureのRoleとして配置する。

Python
 → Research / Model / Evaluation
Rust
 → Runtime / Edge / High-performance Processing
TypeScript
 → Enterprise Interface / Workflow
SQL
 → Authoritative State / Audit / Relational Data

Languageを列挙するのではなく、System Responsibilityに対応させる。

⸻

Cloud Stack

Cloudも同様である。

Compute
Storage
Database
Queue
Identity
Monitoring
GPU

をResearch-to-Production Pipelineへ配置する。

Cloudは単なるHostingではなく、継続運用Architectureである。

⸻

Physical Stack

Physical側では、

Sensor
Edge
Perception
Planning
Safety
Control
Robot

を接続する。

ここでSoftware ArchitectureとSystems Engineeringが一つになる。

⸻

Human Stack

HumanもRoleとして明示する。

Operator
Reviewer
Approver
Domain Expert
Administrator

それぞれにPermissionとResponsibilityを与える。

⸻

Architectureの中心は境界である

Research-to-Production Architectureで最も重要なのは、Componentそのものより境界である。

ResearchとProductionの境界。

AIとRuleの境界。

ModelとBusiness Decisionの境界。

AIとHumanの境界。

DigitalとPhysicalの境界。

それぞれにInterfaceとResponsibilityを定義する。

⸻

Loose Coupling

Modelは変わる。

Cloud Providerも変わり得る。

Robot Hardwareも変わる。

そこでComponent同士を強く結合しすぎない。

Interface
 ↓
Replaceable Component

という設計にする。

Future Technology Changeへ対応しやすくなる。

⸻

Replaceability

特定Modelが終了してもSystem全体は残る。

新しいModelへ交換できる。

同じように、

Vector DB。

Cloud Service。

Sensor。

を交換できるArchitectureが望ましい。

つまり、

Architecture should outlive individual technologies.

である。

⸻

Stable CoreとAdaptive Edge

変化しにくいものをCoreへ置く。

Security。

Audit。

Identity。

Evaluation。

Business State。

変化の速いものをEdgeへ置く。

Model。

Prompt。

Agent。

Sensor Algorithm。

つまり、

Stable Core + Adaptive Edge

である。

⸻

Research SpeedとProduction Stabilityを両立する

Researcherは新しいModelを毎日試したい。

Production OperatorはSystemを毎日変えてほしくない。

両者を同じProcessへ押し込むと衝突する。

そこで、

Research Environmentでは自由にExperimentする。

Productionへ入れるときだけGateを通す。

これがArchitectureによる組織的分離である。

⸻

Two-speed System

概念的には、

Fast Loop
Research → Experiment → Evaluation
Controlled Loop
Validation → Release → Operation

という二つの速度を持つ。

そしてProduction FeedbackをFast Loopへ戻す。

⸻

EQUES型Research-to-Production Architecture

本書で扱う全体を一つにまとめると、

Research
  ↓
Python / Model / Experiment
  ↓
Domain Adaptation
  ↓
LLM / RAG / Evaluation
  ↓
Agent / Workflow
  ↓
TypeScript / Human Interface
  ↓
SQL / Authoritative State
  ↓
Cloud / Secure Runtime
  ↓
Rust / Edge
  ↓
Sensor / Robot / Physical World
  ↓
Observability / Human / Environment Feedback
  ↓
Research

となる。

⸻

研究を産業へ変えるArchitecture

このArchitectureの目的は、単にAIをDeployすることではない。

Research Capabilityを失わず。

Domain Realityへ適応し。

Production Reliabilityを獲得し。

Human Responsibilityを保持し。

Physical Worldへ安全に接続し。

現場から再び学習する。

その全体を一つのSystemとして成立させることである。

⸻

Research-to-Production Architectureとは、

研究を本番へ運ぶ道

ではない。

より正確には、

研究と本番の間を往復できる道を作ること

である。

ProductionでAIがRealityへ接触する。

そこで初めて、本当のFailure、本当のHuman Behavior、本当のDomain Constraintが見える。

それらを再びResearchへ戻せるなら、ProductionはResearchの終点ではなく次の出発点になる。

この双方向Architectureが成立したとき、AI研究は一度きりのTechnology Demoではなく、継続的に更新される産業Capabilityへ変わる。

次節では、ここまでの序章をさらに圧縮し、本書全体で実装していく**「本書の実装モデル」**を定義する。
第7節　本書の実装モデル

ここまで、研究コードと本番システム、PoCとProduction、Domain-specific AI、高信頼AI、Physical AI、Research-to-Production Architectureを順に見てきた。

ここから本書は、それらを個別の技術として学ぶのではなく、一つの産業AIシステムとして実装していく。

Python。

Rust。

TypeScript。

SQL。

Cloud。

LLM。

RAG。

Agent。

Sensor。

Robotics。

Optimization。

Quantum Computing。

これらは、それぞれ独立したTechnologyである。

しかし本書の目的はTechnology Catalogを作ることではない。

異なるTechnologyへ明確な責任を与え、研究から産業実装までをEnd-to-Endで接続することにある。

そのため、本書全体で共通して用いる実装モデルをここで定義する。

⸻

一つの最小Architecture

本書の全7章を最小化すると、次の構造になる。

Research
  ↓
Intelligence
  ↓
Domain
  ↓
Workflow
  ↓
Data / Infrastructure
  ↓
Physical
  ↓
Evaluation
  ↓
Feedback
  ↓
Next Research

これは単なる章構成ではない。

一つのAI TechnologyがResearchからRealityへ到達し、再びResearchへ戻るまでのLifecycleである。

⸻

第1層――Research

出発点はResearchである。

新しいModel。

新しいAlgorithm。

新しいOptimization Method。

新しいRobot Learning。

新しいRetrieval Method。

研究段階では、TechnologyのPotentialを検証する。

ここで重視するのはExperiment SpeedとReproducibilityである。

Paper
 ↓
Hypothesis
 ↓
Experiment
 ↓
Evaluation
 ↓
Validated Method

研究成果を、そのままProductionへ送らない。

まず再現可能なCapabilityへ変換する。

⸻

第2層――Intelligence

Researchで検証されたMethodを、再利用可能なIntelligence Componentへ変える。

本書では主としてPythonがこのLayerを担う。

Research Code
    ↓
Python Module
    ↓
Model Interface
    ↓
AI Service

Machine Learning。

Deep Learning。

LLM。

Embedding。

Evaluation。

ここでAIの知的処理能力を構築する。

第1章ではこのLayerを実装する。

⸻

第3層――Domain

General Intelligenceを産業へそのまま投入しない。

製薬。

Energy。

Enterprise。

それぞれのKnowledgeとRequirementへ適応する。

General AI
   ↓
Domain Knowledge
   ↓
Domain Data
   ↓
Domain Rules
   ↓
Domain Evaluation

第2章では、製薬AIを代表例としてこの変換を扱う。

QAIやJPharmatronそのものを複製するのではない。

その背後にある、

Domain Knowledge → LLM / RAG → Evaluation → Human Review

という一般化可能なArchitectureを実装する。

⸻

第4層――Workflow

AIが正しいOutputを返しても、それだけでは企業は動かない。

検索する。

分析する。

Draftを作る。

Toolを呼ぶ。

Humanへ確認する。

承認後に次の処理へ進む。

これらをWorkflowへ変換する。

Request
  ↓
Agent
  ↓
Tool
  ↓
AI
  ↓
Validation
  ↓
Human Approval
  ↓
Business Action

第3章ではAgentとEnterprise Integrationを扱う。

ここが、

PoC → Production

の中心になる。

⸻

第5層――Interface

HumanはAI Systemの外部に存在するのではない。

Operator。

Reviewer。

Approver。

Domain Expert。

としてArchitectureへ入る。

そこでTypeScriptを用いて、

AI Output。

Evidence。

Risk。

Approval。

History。

を操作できるInterfaceを構築する。

AI System
   ⇅
TypeScript Interface
   ⇅
Human

Interfaceは単なる画面ではない。

Human ResponsibilityをSystemへ実装する境界である。

⸻

第6層――State

AIは確率的なOutputを生成する。

しかし企業には正式なStateが必要である。

DocumentはDraftなのか。

Review中なのか。

Approvedなのか。

どのVersionがCurrentなのか。

誰が承認したのか。

そこでSQLを用いる。

AI Proposal
    ↓
Human / Policy
    ↓
State Transition
    ↓
SQL

本書では、

Generated Output ≠ Authoritative State

という原則を保持する。

⸻

第7層――Infrastructure

AIを継続運用するためにはExecution Environmentが必要になる。

Cloud。

Container。

Database。

Object Storage。

Vector Database。

Identity。

Secret Management。

Monitoring。

これらを接続する。

Application
   ↓
Cloud Runtime
   ├─ Compute
   ├─ Database
   ├─ Storage
   ├─ Identity
   └─ Observability

第4章では、この基盤をTrusted AI Infrastructureとして構築する。

⸻

第8層――Physical

AIがSoftwareの外へ出ると、

Sensor。

Camera。

LiDAR。

Edge。

Robot。

Control System。

へ接続される。

Reality
 ↓
Sensor
 ↓
Edge
 ↓
AI
 ↓
Planning
 ↓
Safety
 ↓
Robot
 ↓
Reality

第5章では、このClosed Loopを扱う。

ここではRustも重要になる。

PythonでResearchとModelを担い、RustでLow-latency RuntimeやEdge Processingを担う。

Languageを競合させるのではなく、責任を分担する。

⸻

第9層――Advanced Computing

すべての産業ProblemがLLMで解けるわけではない。

Scheduling。

Routing。

Resource Allocation。

Combinatorial Problem。

Simulation。

には、数理最適化や異なる計算手法が必要になる。

そこで第6章では、

AI
+
Mathematical Optimization
+
Classical Computing
+
Quantum Computing

を接続する。

Quantum Computingを万能な未来Technologyとして扱わない。

Classical Computingで解く領域、Hybrid Approachを検討する領域、Research段階に留まる領域を区別する。

⸻

第10層――Evaluation

SystemはProductionへ出した瞬間に完成するわけではない。

むしろそこから本当のEvaluationが始まる。

Model Quality。

Domain Accuracy。

Latency。

Failure。

Human Correction。

Physical Outcome。

を観測する。

Production
  ↓
Observation
  ↓
Evaluation
  ↓
Feedback

第7章では、このContinuous Evaluationを実装する。

⸻

第11層――Human

Humanは一つの独立Layerであると同時に、全Architectureを横断する。

Researcher
Domain Expert
Engineer
Operator
Reviewer
Approver

Humanは、

Training Dataを作る。

Evaluation Criteriaを定義する。

AI Outputを確認する。

例外を判断する。

Incidentを分析する。

次のResearch Questionを発見する。

したがって、

Human-in-the-loop

だけでは十分ではない。

本書では、

Human-in-the-Architecture

として扱う。

⸻

第12層――Feedback

Productionから生まれた情報をResearchへ戻す。

Human Correction
Domain Failure
Runtime Error
Physical Outcome
      ↓
Feedback
      ↓
Curation
      ↓
Evaluation Dataset
      ↓
Research

このFeedback Loopがなければ、Systemは時間とともに劣化する。

⸻

本書の共通実装Stack

以上をTechnology Stackへ翻訳すると、次のようになる。

Python
   Intelligence / Research / Evaluation
LLM / RAG
   Generative Intelligence / Knowledge
Agent
   Task Orchestration / Tool Use
TypeScript
   Enterprise Interface / Human Interaction
SQL
   Authoritative State / Audit
Cloud
   Production Runtime / Data Infrastructure
Rust
   High-performance Runtime / Edge
Sensor / Robotics
   Physical Interface
Optimization / Quantum
   Advanced Computation
Evaluation
   Continuous Reliability

重要なのは、すべてのProjectですべてを使うことではない。

Requirementに必要なComponentだけを選択する。

⸻

Smallest Sufficient Architecture

本書では、Technologyを増やすことを高度化とは考えない。

Promptだけで解けるなら、Agentを作らない。

SQLで十分なら、Graph Databaseを追加しない。

Cloud APIで十分なら、独自LLMをTrainingしない。

Ruleで安全に解けるなら、AIに判断させない。

つまり基本原則は、

Smallest Sufficient Architecture

である。

必要十分な最小構造から始める。

⸻

Complexity Budget

System ComplexityにはCostがある。

Componentが増えれば、

Development。

Testing。

Security。

Monitoring。

Maintenance。

が増える。

したがって、新しいTechnologyを追加するときには、

「何ができるか」

だけではなく、

そのComplexityを導入する理由があるか

を問う。

⸻

Stable Core

一方で、Domainが変わっても共通して必要になるComponentがある。

Trusted Core
├─ Identity
├─ Security
├─ Model Gateway
├─ Evaluation
├─ Audit
├─ Observability
├─ Human Approval
└─ Policy

これをStable Coreとする。

⸻

Adaptive Layer

その外側には変化の速いTechnologyを置く。

Adaptive Layer
├─ Model
├─ Prompt
├─ RAG
├─ Agent
├─ Optimization
├─ Sensor Algorithm
└─ Robot Policy

これらは交換可能にする。

つまり、

Stable Core + Adaptive Layer

である。

⸻

Domain Layer

さらにDomain固有部分を分離する。

Domain Layer
├─ Knowledge
├─ Data Schema
├─ Workflow
├─ Rules
├─ Evaluation
└─ Failure Definition

すると全体は、

Stable Core
   +
Adaptive AI
   +
Domain Layer

として構成できる。

⸻

Interface Contract

各ComponentはInterfaceで接続する。

Python ModelをRust Runtimeから利用する。

AgentをTypeScript Applicationから呼ぶ。

AI OutputをSQLへ記録する。

CloudとEdgeを接続する。

このとき重要なのは内部実装ではなくContractである。

Input Schema
Output Schema
Permission
Failure Behavior
Version

を明示する。

⸻

Replaceable Architecture

Foundation Modelは変わる。

Vector Databaseも変わる。

Cloud Serviceも変わる。

Robot Hardwareも変わる。

しかし企業のAI System全体を毎回作り直すわけにはいかない。

そこで、

Technology is replaceable; architecture persists.

という設計を採る。

⸻

Trust Boundary

本書ではSystem内に複数のTrust Boundaryを置く。

External Input
     ↓
[Validation]
LLM Output
     ↓
[Schema / Evidence Check]
Agent Action
     ↓
[Permission]
High-risk Decision
     ↓
[Human Approval]
Physical Action
     ↓
[Safety Layer]

AIが賢くなるほどBoundaryを消すのではない。

CapabilityとAuthorityを分離する。

⸻

State Transition

本書の実装では、AI Applicationを単なるQuestion Answering Systemとして作らない。

Stateを持つ。

例えば、

CREATED
  ↓
ANALYZED
  ↓
REVIEW_REQUIRED
  ↓
APPROVED
  ↓
EXECUTED
  ↓
VERIFIED

というTransitionを定義する。

AIはこのState Machineの中で働く。

⸻

Verificationを最後に置く

Actionを実行したから終わりではない。

期待した結果になったか確認する。

Plan
↓
Execute
↓
Observe
↓
Verify

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

RobotがCommandを受け取ったことと、RealityでTaskが完了したことは同じではない。

⸻

Failureを第一級Stateにする

Successだけを設計しない。

FAILED
RETRY_REQUIRED
HUMAN_REQUIRED
SAFE_STOP
ROLLBACK_REQUIRED

も正式なStateとして扱う。

Failureを例外ではなくSystem Behaviorとして実装する。

⸻

本書の共通Pipeline

ここまでを統合すると、本書全体の実装Pipelineは次のようになる。

Research
  ↓
Prototype
  ↓
Domain Adaptation
  ↓
Evaluation
  ↓
Production Candidate
  ↓
Secure Deployment
  ↓
Human / Agent Workflow
  ↓
Industrial Execution
  ↓
Runtime Observation
  ↓
Verification
  ↓
Feedback
  ↓
Next Research

このPipelineを、7章を通して段階的に構築していく。

⸻

第1章から第7章まで

第1章では、Intelligenceを作る。

第2章では、Domain Trustを作る。

第3章では、Enterprise Workflowへ接続する。

第4章では、DataとInfrastructureを作る。

第5章では、Physical Worldへ接続する。

第6章では、Advanced Computationを追加する。

第7章では、Continuous Learningを閉じる。

つまり、

Intelligence
  ↓
Domain
  ↓
Workflow
  ↓
Infrastructure
  ↓
Physical
  ↓
Advanced Computing
  ↓
Continuous Learning

という順序になる。

⸻

松尾・岩澤研究室編との境界

ここで、本書の位置も明確になる。

研究室を起点とするAI実装体系が、

AI Research
    ↓
General AI Architecture

を主として扱うなら、本書はそこから先へ進む。

AI Architecture
     ↓
Domain
     ↓
Trust
     ↓
Production
     ↓
Industry

である。

焦点は、新しいAIを発明することだけではない。

発明されたAIを、責任を持って現実の産業へ置くことにある。

⸻

EQUES型実装の最小式

第1冊で分析した企業構造を、Executable Architectureへ最後に圧縮する。

Research
  ↓
Technology
  ↓
Domain
  ↓
Implementation
  ↓
Human
  ↓
Industry
  ↓
Feedback
  ↓
Next Research

この循環をCode、Data、Infrastructure、Human Workflowとして実装する。

それが本書の目的である。

⸻

本書では、完成された一つの巨大Systemを最初から提示しない。

最小Componentを作る。

接続する。

評価する。

信頼境界を追加する。

Productionへ移す。

RealityからFeedbackを得る。

必要な部分だけを高度化する。

その反復によって、Research PrototypeをTrusted Industrial AI Systemへ成長させていく。

AI研究を産業へ移すとは、ModelをDeployすることではない。

ResearchのPotentialを、DomainのRequirementへ翻訳し、Humanが責任を持てるProduction SystemとしてRealityへ実装し、そのRealityから再び学習できる循環を構築することである。

ここで序章のArchitectureは完成した。

次の第Ⅰ部では、その最初のComponentへ入る。

研究、Machine Learning、Deep Learning、LLM、Domain Adaptation、Fine-tuning、RAG、Evaluationを担う、産業AIのIntelligence Layer。

Python / Domain AIから実装を開始する。

愛と敬意を込めてmandala