第1冊『株式会社EQUES』――松尾研発AIスタートアップは、研究・製薬・エネルギー・量子・フィジカルAIをどう社会実装するのか（第9回・完結）（終章 研究と社会をつなぐ会社）
終章 研究と社会をつなぐ会社
第1節 研究から始まった
EQUESは、研究から始まった。
2022年2月1日、東京大学の松尾研究室を起点として設立されたこの会社の出発点には、Machine LearningやAIに関する研究能力があった。
まだ十分に解かれていないProblemを見つける。
論文を読む。
仮説を立てる。
Experimentする。
結果を評価する。
必要なら新しいMethodを作る。
大学研究室で培われるこうした能力は、EQUESという企業の最初の資産だった。
しかし、企業としてのEQUESを理解するには、ここで止まってはいけない。
重要なのは、
研究から始まったこと
ではなく、
研究をどこまで社会へ移動させてきたか
である。
⸻
研究は社会実装ではない
研究成果が得られたからといって、そのTechnologyがそのまま企業や社会で使えるわけではない。
Research Prototypeは動く。
Benchmarkでも高い性能が出る。
しかし現場では、
Dataが違う。
Requirementが違う。
Securityが必要になる。
Humanが使う。
既存Systemへ接続する。
長期間運用する。
Errorへ対応する。
つまり、
Research Success ≠ Social Implementation
である。
EQUESの四年間は、この距離を埋める過程だった。
⸻
ResearchからProblemへ
大学ではResearch Questionから始まることが多い。
企業ではCustomer Problemから始まる。
この違いは大きい。
「どのModelが最も高性能か」
ではなく、
「この業務の何が問題なのか」
を問う。
「新しいTechnologyを使えるか」
ではなく、
「このProblemにTechnologyが必要なのか」
を問う。
EQUESが伴走型技術開発を行ってきた意味も、ここにある。
Research-driven CompanyがProblem-driven Companyへ能力を拡張する。
⸻
最先端を使うことが目的ではない
研究室を起点とする企業は、最新Technologyへ強い。
しかし、その強みには一つのRiskがある。
Technologyそのものを目的化することである。
新しいLLM。
新しいAgent。
新しいRobotics Method。
新しいQuantum Algorithm。
それらを使うこと自体が価値なのではない。
現場のProblemに対して、既存手法より良いSolutionを作れるか。
そこが企業としての評価軸になる。
したがって、
Frontier Technology → Appropriate Technology
への選択が必要になる。
⸻
研究を翻訳する
研究成果は、そのまま産業のLanguageではない。
Paperには、
Algorithm。
Dataset。
Benchmark。
Experiment。
が書かれる。
企業現場には、
Workflow。
Cost。
Risk。
Security。
Responsibility。
Human Operation。
がある。
両者をつなぐにはTranslationが必要になる。
Scientific Capability → Operational Capability
への変換である。
EQUESという会社は、この翻訳機能を企業として持とうとしてきたと見ることができる。
⸻
Prototypeへ変える
翻訳の最初の形がPrototypeである。
論文を読む。
実装する。
顧客Dataへ適用する。
実際に使えるかを見る。
ここで研究Knowledgeが、初めてCustomer Realityへ触れる。
Prototypeの価値は、完成品を小さくしたものではない。
ResearchとRealityが最初に接触する場所
にある。
⸻
PoCでRealityを知る
PoCを行うと、Research Environmentでは見えなかったことが分かる。
Dataが不足している。
Accuracy以外のRequirementが重要だった。
Humanが使いにくい。
既存SystemとのIntegrationが難しい。
想定したProblemそのものが違っていた。
つまりPoCは、
Technologyを証明するだけではない。
自分たちの理解が正しかったかを検証するProcess
でもある。
⸻
Realityが研究を修正する
ここで重要な方向転換が起こる。
ResearchからRealityへTechnologyを出すだけではない。
RealityからResearchへFeedbackが返る。
「このCaseでは失敗した」
「このDataでは性能が落ちる」
「このExplanationではHumanが判断できない」
新しいProblemがResearch Questionになる。
つまり、
Research → Reality
だけでなく、
Reality → Research
が成立する。
⸻
企業が中間層になる
大学と社会を直接つなぐことは簡単ではない。
大学はResearchに最適化されている。
企業現場はOperationに最適化されている。
その間には、
Requirement Definition。
Software Engineering。
Product Design。
Security。
Support。
Commercialization。
というLayerがある。
EQUESのようなStartupは、この間に立つ。
Academia ⇄ Startup ⇄ Industry
という構造である。
⸻
松尾研発であることの意味
「松尾研発」という言葉をBrandとしてだけ読むと、本質を見失う。
重要なのは、研究室の名前ではない。
Research Culture。
Technical Network。
Young Talent。
最新Researchへ接近できるEnvironment。
そうしたKnowledge Environmentを企業形成へ接続できたことにある。
つまり、
Research Institution → Human Capital → Company Capability
というKnowledge Transferである。
⸻
しかし企業は研究室の延長ではない
一方、Startupになれば研究室と同じではいられない。
Customerへ価値を届ける。
Revenueを得る。
Employeeを雇用する。
Productを維持する。
Responsibilityを負う。
つまり企業には、
Economic Sustainability
が必要になる。
Research Capabilityを保持しながらBusiness Capabilityを形成する。
ここに大学発Startupの難しさがある。
⸻
研究者から組織へ
研究室では、一人の優秀なResearcherが大きな成果を出すことがある。
企業では、それをOrganization Capabilityへ変換する必要がある。
一人が知っている。
では足りない。
Codeへ残す。
Evaluationへ残す。
Documentationへ残す。
Productへ残す。
別のEngineerが再利用できる。
つまり、
Individual Knowledge → Organizational Knowledge
へ変換する。
⸻
案件が第二の学校になる
大学研究室を第一のLearning Environmentとするなら、顧客案件は第二のLearning Environmentになる。
現場へ行く。
Domain Expertと話す。
Production Constraintを知る。
Failureを見る。
ここで研究者やEngineerは、大学では学びにくいKnowledgeを獲得する。
その意味で、
Customer Project = Industrial Learning Environment
でもある。
⸻
製薬が教えたもの
製薬AIへの進出は、EQUESにとって重要なLearningだった。
AIが高性能であればよいわけではない。
GMP。
Quality Assurance。
Data Integrity。
Human Review。
Auditability。
AIを使うConditionそのものを設計する必要がある。
製薬を通じて、AI社会実装には、
Trust
というLayerが必要になることが見えてくる。
⸻
生成するだけでは足りない
QAI GeneratorはGenerationを支援する。
QAI CheckerはVerificationを支援する。
JPharmatronはModel Capabilityを広げる。
JPharmaBenchはEvaluationを担う。
これらを接続すると、一つの原則が見える。
BuildだけではなくMeasureする。
GenerateだけではなくVerifyする。
ここにEQUESの高信頼AIへの方向性が表れている。
⸻
Researchの形も変わる
企業のResearchは、大学Researchをそのまま持ち込むだけではない。
Customer ProblemがResearch Themeになる。
Product FailureがEvaluation Caseになる。
Market RequirementがArchitectureへ影響する。
つまり、
Research Agenda itself becomes industrially informed.
社会実装を続けることで、研究の問いそのものが変化する。
⸻
Energyがさらに境界を広げた
製薬では主としてDocumentとKnowledgeを扱った。
EnergyではSensorやInfrastructureへ対象が広がる。
さらに原子力・廃炉ではRobotとPhysical Environmentへ接続する。
Researchの対象が、
Digital Representation
から、
Physical Reality
へ近づく。
研究と社会の距離は、さらに短くなる。
⸻
Physical AIではResearchの責任も変わる
Physical AIでは、ModelのErrorがPhysical Consequenceへつながる可能性がある。
そこでResearcherはAccuracyだけを追えなくなる。
Safety。
Latency。
Robustness。
Failure Mode。
Human Override。
を考える。
つまり社会へ近づくほど、Research Requirementそのものが広がる。
⸻
QuantumもProblemから読む
Quantum Computingについても同じである。
Quantumを使うこと自体が目的ではない。
現実のOptimization Problemを定義する。
Classical Methodと比較する。
有効性を評価する。
つまり、
Frontier ComputingをReal Problemへ接続する。
これもEQUESのResearch-to-ImplementationというCoreと同じ方向にある。
⸻
教育まで広がった理由
AI×DX寺子屋のような教育活動も、研究から離れた別事業とだけ見る必要はない。
研究成果を社会へ届けるためには、Technologyを理解できるHumanが必要になる。
AIを使う。
疑う。
評価する。
業務へ組み込む。
Human CapabilityがなければResearch成果は定着しない。
したがって、
Research Implementation includes Human Learning.
研究と社会の間には教育も存在する。
⸻
ResearchからHumanへ
EQUESの活動範囲を一つの連鎖として見ると、
Research
↓
Technology
↓
Product
↓
Workflow
↓
Human
↓
Organization
へ広がってきた。
研究を社会へ実装するとは、Technologyだけを移すことではない。
利用者とOrganizationまで含めて変化させることである。
⸻
研究と社会は反対側ではない
従来、研究は大学、実務は企業というように分けられやすい。
しかし先端AIでは、この境界が薄くなる。
産業ProblemがResearch Questionになる。
Research ResultがProductになる。
Product Usageが新しいDataを生む。
Failureが新しい研究を生む。
つまり、
Research ⇄ Society
というFeedback Loopが形成される。
⸻
StartupがLoopを閉じる
このLoopの中でStartupが担える役割は大きい。
大学だけではProductionまで持ちにくい。
大企業だけではFrontier Researchを高速に試しにくい場合がある。
Startupは、
Researchを理解する。
Prototypeを作る。
Customerへ持っていく。
Feedbackを得る。
再び改良する。
そのLoopを比較的短く回せる。
⸻
四年間で形成されたもの
2022年のEQUESにはResearch Originがあった。
2026年には、それに加えて、
Customer Problem。
Domain Knowledge。
Product。
Evaluation。
Physical AI。
Human Development。
Partner Network。
が存在する。
企業がResearchから離れたのではない。
Researchを中心に、社会側のLayerを増やしてきた
と見ることができる。
⸻
研究を捨てずに社会へ進む
Startupが成長すると、Researchを減らし、SalesとDelivery中心になる場合がある。
それも一つの企業選択である。
しかしEQUESがResearch-origin Companyとして独自性を保つなら、
Productが成長してもResearchを残す。
Customer Problemから新しいResearchを作る。
Frontier Technologyを検証し続ける。
という循環を維持する必要がある。
⸻
研究から始まった会社の強さ
研究から始まった会社の強みは、一つのTechnologyを持っていることだけではない。
Technologyが変わっても、自分たちで学べる。
未知のProblemに対してResearchできる。
既存Solutionがないとき、新しいSolutionを探せる。
つまり、
Known Solution Delivery
だけではなく、
Unknown Problem Exploration
ができる。
ここにResearch Companyの長期的な価値がある。
⸻
研究から始まった会社の弱さ
一方で弱点もある。
Researchが目的化しやすい。
Customer Needから離れる。
Product化が遅れる。
Technology Portfolioが広がりすぎる。
だからこそ、
Research Excellence × Market Discipline
のBalanceが必要になる。
研究を弱めるのではない。
研究を社会的価値へ変換する力を強める。
⸻
本書の出発点へ戻る
序章で問うたのは、
研究はどのように産業になるのか
だった。
ここまで一冊を通して見えてきた答えは、一つのTechnology Transferではない。
Researchだけでも。
Capitalだけでも。
Productだけでも。
Humanだけでもない。
それらを連続させる必要がある。
⸻
研究から始まった
EQUESの最小構造を再び描けば、
Research
↓
Problem
↓
Prototype
↓
PoC
↓
Production
↓
Product / Operation
↓
Feedback
↓
Research
となる。
始まりはResearchである。
しかし終点もまたResearchへ戻る。
社会へTechnologyを出した結果、新しい問いが生まれるからである。
⸻
EQUESは研究から始まった。
しかし、研究の中に留まるために会社になったわけではない。
ResearchをTechnologyへ。
TechnologyをProductへ。
ProductをIndustryへ。
Industryから得たProblemを次のResearchへ。
その往復を継続するために企業という形を取った、と読むことができる。
そして、この循環の第二段階で必要になるのがTranslationである。
どれほど優れたResearchでも、産業のLanguage、Workflow、System、Humanへ変換できなければ社会へ届かない。
次節では、EQUESという会社の役割をさらに明確にする。
技術を産業へ翻訳する。
研究と社会の間にある、最も重要な仕事の一つを整理していく。
第2節 技術を産業へ翻訳する
研究からTechnologyが生まれる。
しかしTechnologyが存在することと、産業で使われることは同じではない。
論文として成立する。
Prototypeが動く。
Benchmarkで高いPerformanceを示す。
それでも、企業のProduction Environmentへ導入できるとは限らない。
産業には、研究とは異なる条件が存在するからである。
Cost。
Security。
Reliability。
Regulation。
Existing System。
Workflow。
Human。
Responsibility。
Technologyを社会へ届けるには、これらの条件に合わせて形を変えなければならない。
本書を通じて見てきたEQUESの役割を一つの言葉で表すなら、
Technology Translation
である。
⸻
翻訳とはTechnologyを簡単に説明することではない
Technology Translationというと、専門的な内容を一般の人にも分かる言葉へ説明することを想像しやすい。
しかし産業実装におけるTranslationは、それより深い。
研究成果そのものを、
業務。
Software。
Data。
Organization。
Safety。
Business。
へ変換する。
つまり、
Research Result → Industrial System
というTransformationである。
⸻
Research LanguageとIndustry Language
研究では、
Accuracy。
Loss。
Parameter。
Dataset。
Benchmark。
が中心になる。
産業では、
何時間削減できるのか。
誰が使うのか。
どのDataへAccessするのか。
失敗したらどうするのか。
誰が責任を持つのか。
いくらかかるのか。
が問われる。
両者は同じTechnologyを見ていても、評価軸が違う。
だからTranslationが必要になる。
⸻
最初の翻訳はProblem Definitionである
顧客は必ずしも、
「RAGを導入したい」
「Deep Learningを使いたい」
という形で本質的なProblemを持っているわけではない。
実際には、
Document作成に時間がかかる。
確認漏れが起きる。
設備点検が難しい。
熟練者のKnowledgeが共有されない。
というProblemがある。
ここから、
どこをAIで解けるのか。
どこはRule-based Systemがよいのか。
どこはHumanが担当すべきか。
を切り分ける。
Business Problem → Technical Problem
への翻訳である。
⸻
Technologyから始めない
AI Companyにとって最も避けるべきことの一つは、Technologyを先に決めることである。
LLMが流行しているからLLMを使う。
Agentが注目されているからAgent化する。
Physical AIが伸びているからRobotを導入する。
これではTechnology Adoptionそのものが目的になる。
必要なのは、
Problem → Requirement → Technology Selection
という順序である。
Technologyは目的ではなく選択肢である。
⸻
Requirementへ変換する
Problemが見えたら、次にRequirementへ変換する。
必要Accuracy。
Response Time。
Data Volume。
User Role。
Security Level。
Human Review。
Integration Requirement。
Operating Environment。
ここまで定義されて初めて、Technical Architectureを設計できる。
曖昧な課題を実装可能なRequirementへ変換すること自体が、高度なEngineeringである。
⸻
PoCは翻訳装置である
PoCには二つの世界が集まる。
Research側からは、
Model。
Algorithm。
Code。
が入る。
Industry側からは、
Data。
Workflow。
User。
Constraint。
が入る。
その接点で、
本当に動くか。
本当に役立つか。
どこで失敗するか。
を確認する。
つまりPoCは、
ResearchとIndustryのTranslation Interface
として機能する。
⸻
成功するPoCより、学べるPoC
PoCでは「成功した」と言える結果を求めたくなる。
しかし社会実装にとって重要なのは、Technologyの限界を発見することでもある。
このDataでは精度が出ない。
このTaskはHumanの方が速い。
この部分はAutomationすべきではない。
こうしたNegative Resultも価値を持つ。
なぜならProductionでのFailureを先に発見できるからである。
⸻
PoCからProductionへの第二の翻訳
PoCが成功しても、そのままProductionにはならない。
Prototypeには存在しなかったものが必要になる。
Authentication。
Authorization。
Logging。
Monitoring。
Backup。
Error Handling。
Scalability。
Maintenance。
つまり、
Working AI → Operable System
への第二のTranslationが必要になる。
ここでSoftware Engineeringの重要性が急激に高まる。
⸻
ModelからSystemへ
産業AIの価値は、Model単体では決まらない。
優れたModelでも、
Dataを取得できない。
UIが使いにくい。
Responseが遅い。
Security Requirementを満たさない。
既存Systemと接続できない。
ならProductionでは使えない。
したがって、
AI Model ⊂ AI System
である。
ModelはSystemの一Componentにすぎない。
⸻
製薬では翻訳条件が厳しくなる
製薬AIでは、一般的なOffice Automation以上に条件が厳しくなる。
GMP。
Quality Assurance。
Data Integrity。
Traceability。
Human Review。
AIが文章を生成できるだけでは不十分である。
生成した内容を、品質業務の中で安全に扱える形へ変換する必要がある。
⸻
QAI Generatorの意味
QAI Generatorをこの視点から見ると、その価値は「LLMで文章を作ること」だけにはない。
製薬業務のContext。
Document Structure。
User Workflow。
Review Process。
へGeneration Technologyを接続することにある。
つまり、
Generic Generation → Domain-specific Workflow
への翻訳である。
⸻
QAI Checkerの意味
Checkerではさらに別のTranslationが行われる。
LLMの能力を、
自由なText Generationではなく、
Consistency Verification。
Difference Detection。
Review Assistance。
へ使う。
同じFoundation Technologyでも、Industry Requirementに応じて役割が変わる。
Technology Translationとは、この役割設計でもある。
⸻
Domain Modelという翻訳
JPharmatronのようなDomain-specific Modelも、
General AI Capabilityを特定領域へ近づける試みとして理解できる。
一般的Language Capabilityだけでは扱いにくい専門VocabularyやContextへ適応する。
つまり、
General Intelligence Capability → Domain Capability
へのTranslationである。
⸻
Benchmarkという翻訳
EvaluationにもTranslationが必要になる。
一般Benchmarkで高性能だからといって、製薬業務でも高性能とは限らない。
そこでDomain-specific Evaluationを作る。
JPharmaBenchはこの問題と接続する。
General Performance → Domain-relevant Performance
へ評価軸そのものを翻訳するのである。
⸻
Energyでは翻訳対象が変わる
Energyへ進むと、Technology Translationの対象はDocumentからPhysical Environmentへ広がる。
Sensor Dataを取得する。
異常を検知する。
Equipment Stateを推定する。
Humanへ知らせる。
Maintenanceへつなげる。
ここでは、
Physical State → Data → Decision Support
というTranslationが必要になる。
⸻
RealityをDataへ翻訳する
Physical AIでは、最初の翻訳者はSensorである。
Temperature。
Image。
Vibration。
Position。
Force。
Physical RealityをMachine-readable Dataへ変える。
しかしSensorはRealityそのものではない。
Noiseもある。
Missing Dataもある。
Measurement Errorもある。
したがって、AIが見ているものと現実を同一視してはいけない。
⸻
DataからStateへ
次にAIはDataから意味のあるStateを推定する。
正常。
異常。
Obstacle。
Object。
Equipment Condition。
これは、
Measurement → Operational Meaning
へのTranslationである。
このTranslationを誤れば、その後のDecisionも誤る。
⸻
StateからActionへ
さらにPhysical AIでは、認識したStateをActionへ変える。
止まる。
移動する。
検査する。
HumanへAlertする。
Robotを操作する。
ここでは、
Understanding → Action
というTranslationが発生する。
AIがPhysical Worldへ近づくほど、翻訳の失敗Costは大きくなる。
⸻
SafetyはTranslation Boundaryになる
だからPhysical AIでは、
AIが提案したActionをそのまま実行してよいか。
というBoundaryが必要になる。
Rule。
Safety Constraint。
Human Approval。
Emergency Stop。
これらを置く。
つまり、
AI Decision ≠ Immediate Physical Action
である。
間にSafety Layerを入れる。
⸻
Humanへの翻訳
AIが正しいResultを出しても、Humanが理解できなければ使えない。
なぜこのAlertが出たのか。
どのEvidenceがあるのか。
どの程度Confidenceがあるのか。
次に何を確認すべきか。
Humanが判断可能なRepresentationへ変換する必要がある。
これは、
Machine Output → Human Decision
へのTranslationである。
⸻
HumanからAIへの翻訳
逆方向も必要になる。
現場担当者が持つTacit Knowledgeを、
Rule。
Label。
Feedback。
Evaluation Criteria。
Knowledge Base。
へ変換する。
つまり、
Human Expertise → Machine-usable Knowledge
である。
産業AIは、この双方向Translationによって成熟する。
⸻
Domain Expertが翻訳者になる
ここでDomain Expertの位置が重要になる。
AI EngineerはModelを理解する。
Domain ExpertはIndustry Realityを理解する。
両者の間にCommunicationがなければ、正しいSystemは作れない。
したがって産業AIでは、
AI Expert ⇄ Domain Expert
というTranslation Interfaceそのものが競争力になる。
⸻
Educationも翻訳である
AI×DX寺子屋のような活動も、この構造の中へ置ける。
AI Technologyを、
社員が理解できる。
使える。
評価できる。
業務Problemへ適用できる。
状態へ変える。
これは、
Technical Knowledge → Organizational Capability
へのTranslationである。
教育は社会実装の周辺ではない。
社会実装を成立させる一つのLayerである。
⸻
経営への翻訳
Technologyは経営Languageへも変換されなければならない。
どれだけAccuracyが上がったかだけではない。
Costをどれだけ下げるのか。
Riskをどれだけ減らすのか。
Revenueへどうつながるのか。
Strategic Capabilityを何年先へ作るのか。
つまり、
Technical Value → Business Value
へのTranslationである。
⸻
BusinessからResearchへの逆翻訳
一方、企業側のProblemをResearch Questionへ戻すこともできる。
「確認作業が重い」
というBusiness Problemを、
どの種類のInconsistency Detectionが難しいのか。
どのEvaluation Setが必要か。
どのModel Architectureが適切か。
というResearch Questionへ変える。
つまりTranslationは一方向ではない。
⸻
Translation Loop
ここまでをまとめると、
Research
↓
Technology
↓
Requirement
↓
System
↓
Workflow
↓
Human / Organization
↓
Operation
↓
Failure / Feedback
↓
Research
というLoopになる。
各境界でTranslationが起きている。
⸻
Translation Failure
AI社会実装が失敗するとき、Modelが悪いとは限らない。
Problem Definitionが間違っていた。
Requirementが不足していた。
UIが合わなかった。
Human Roleが定義されていなかった。
Operationを考えていなかった。
つまり、
Model FailureではなくTranslation Failure
である場合がある。
⸻
翻訳能力は再利用できる
重要なのは、個別Technologyが変わってもTranslation Capabilityは残ることである。
Deep LearningからLLMへ。
LLMからAgentへ。
Software AIからPhysical AIへ。
Technologyは変化する。
しかし、
Problemを理解する。
Requirementへ変換する。
Architectureを設計する。
評価する。
Productionへ移す。
Humanへ定着させる。
というProcessは繰り返し必要になる。
⸻
企業資産としてのTranslation Capability
したがってEQUESの長期的な企業資産は、特定Modelだけではない。
ResearchとIndustryの間を往復できるOrganization Capability
そのものになり得る。
これは一つのProductより長く残る可能性がある。
Modelは更新される。
Cloud Serviceも変わる。
Programming Frameworkも変わる。
しかし翻訳能力があれば、新Technologyを再びIndustryへ接続できる。
⸻
翻訳とStandardization
翻訳を毎回完全Customで行えばScaleしない。
そこでRepeated TranslationをStandardizeする。
共通Requirement Template。
Evaluation Framework。
Security Architecture。
Human Approval Pattern。
Data Governance。
これらをCompany Standardへ変える。
すると、
Translation Experience → Reusable Architecture
になる。
⸻
翻訳からProductが生まれる
さらに同じProblemへのTranslationが何度も起きれば、それをProduct化できる。
つまりProductとは、
繰り返されたTranslationをSoftwareとして固定したもの
と見ることもできる。
QAIのようなVertical Productは、この構造に位置づけられる。
⸻
翻訳からPlatformが生まれる
複数Productで同じTranslation Layerが使われるなら、それを共通基盤へする。
Evaluation。
Security。
Knowledge Retrieval。
Human Approval。
Audit。
こうして、
Translation Pattern → Platform
へ進む。
受託、Product、Platformはここでも一つの連続した構造になる。
⸻
研究から産業へ
EQUESの四年間をこの視点で読み直すと、
大学Researchをそのまま販売してきた会社ではない。
Researchを、
Customer Problem。
製薬Workflow。
Energy Infrastructure。
Physical Environment。
Human Organization。
へ変換してきた。
そのたびにTechnologyの形も変わった。
⸻
産業から研究へ
そして重要なのは逆方向である。
製薬でEvaluationの必要性を知る。
EnergyでRobustnessの必要性を知る。
Physical AIでSafetyの必要性を知る。
Human導入でEducationの必要性を知る。
社会へ近づくことで、次に研究すべきProblemが見える。
つまり産業はResearchの終点ではない。
新しいResearch QuestionのSource
になる。
⸻
技術を産業へ翻訳する会社
この構造を最小化すれば、
Research Language
↓
Technology
↓
Industrial Requirement
↓
Operational System
↓
Human Use
である。
そして運用結果が逆方向へ戻る。
Human / Industry Feedback
↓
Technical Problem
↓
Research Question
となる。
EQUESが長期的に強い会社になるとすれば、この往復を速く、高い精度で実行できる会社になったときである。
⸻
研究だけでは産業にならない。
産業だけを見ていても、Frontier Technologyは生まれにくい。
その間に必要なのが翻訳である。
研究の可能性を壊さず、産業のConstraintを無視せず、両者が接続できる形へ変える。
それがResearch-origin AI Startupの重要な仕事である。
そして、EQUESがその翻訳を製薬、Energy、Physical AIへ広げるほど、次に中心となる概念は明確になる。
Trustである。
AIが社会の深い部分へ入るほど、「動くか」だけでは足りない。
正しいか。
確認できるか。
説明できるか。
安全に止められるか。
Humanが最終的に判断できるか。
次節では、本書を通じて繰り返し現れてきたこの軸を、**「高信頼AIという方向」**として整理する。
第3節 高信頼AIという方向
AIの性能は上がり続けている。
文章を生成する。
画像を理解する。
大量のDocumentを検索する。
複雑なQuestionへ回答する。
Softwareを操作する。
Robotを制御する。
しかしAIが社会の深い領域へ入るほど、性能とは別の問いが大きくなる。
そのAIを、どこまで信頼してよいのか。
製薬。
Energy。
原子力。
Infrastructure。
これらの領域では、「かなり正しい」だけでは十分ではない。
AIが間違える可能性を前提に、
どう検出するか。
誰が確認するか。
何を記録するか。
どこでHumanへ戻すか。
どの条件なら利用しないか。
まで設計しなければならない。
本書で追ってきたEQUESの複数の事業を横断すると、ここに一つの共通方向が見えてくる。
High-reliability AI。
高信頼AIである。
⸻
高性能AIと高信頼AIは同じではない
高性能なModelが、そのまま高信頼なSystemになるわけではない。
Benchmark Accuracyが高い。
Generation Qualityが高い。
Reasoning Capabilityが高い。
それらは重要である。
しかし産業では、
同じ条件で安定して動くか。
Failureを検出できるか。
根拠を確認できるか。
Access Controlは適切か。
Humanが介入できるか。
が同時に問われる。
したがって、
High Performance ≠ High Reliability
である。
⸻
ModelではなくSystemを信頼する
AI Modelそのものを完全に信頼するという発想には限界がある。
Modelは誤る。
Dataも誤る。
Sensorも壊れる。
Humanも判断を誤る。
そこで、一つのComponentを絶対視するのではなく、System全体でRiskを管理する。
Model。
Data。
Evaluation。
Rule。
Human Review。
Logging。
Monitoring。
Fail-safe。
これらを組み合わせる。
つまり、
Trust in Model
から、
Trust in System
へ移る。
⸻
信頼はAccuracyだけではない
産業AIにおけるTrustは複数の要素から構成される。
Accuracy。
Consistency。
Robustness。
Security。
Traceability。
Explainability。
Auditability。
Privacy。
Human Oversight。
Operational Reliability。
一つの数字だけでは測れない。
用途によって必要なTrustの構成も変わる。
⸻
Riskに応じてRequirementを変える
社内文章のDraftを作るAIと、重要設備のOperationへ関与するAIでは、同じReliability Requirementを課す必要はない。
Riskが低いTaskではAutomationを広げられる。
Riskが高いTaskではHuman Approvalを強くする。
CriticalなActionではRuleやSafety Systemを追加する。
つまり、
Risk Level → Required Assurance Level
である。
高信頼AIとは、すべてのAIを同じ強度で管理することではない。
Riskに応じて適切なAssuranceを設計することである。
⸻
製薬が示したTrust
EQUESの製薬AIは、この問題を分かりやすく示している。
製薬品質業務では、AIが自然な文章を生成できるだけでは不十分である。
内容を確認する。
Document間のConsistencyを見る。
HumanがReviewする。
履歴を残す。
AI Outputを業務Processの中で管理する。
ここで重要になるのは、
Generation Capability + Verification Capability
である。
⸻
Generatorだけでは終わらない
生成AIの初期的な価値は、
「作ること」
に置かれやすい。
しかし高信頼業務では、
Generate
の次に、
Check
が必要になる。
さらに、
Approve
と、
Record
が必要になる。
したがって、
Generate → Verify → Approve → Record
というWorkflowになる。
この構造は製薬だけに限定されない。
⸻
Checkerという思想
QAI Checkerを本書全体の中で見ると、単なる一Product以上の意味を持つ。
AIによってAI Outputを確認する。
Human Reviewを支援する。
DifferenceやInconsistencyを見つける。
つまりAIの役割を、
Creator
だけでなく、
Reviewer
へ広げる。
生成AI時代には、生成能力と同じくらい検証能力が重要になる可能性がある。
⸻
Evaluationを独立させる
さらに重要なのがEvaluationである。
新しいModelが登場した。
Vendorが高性能だと言っている。
それだけでProductionへ導入することはできない。
自社Domainで測る。
実際のTaskで測る。
Failure Caseを見る。
CostやLatencyも見る。
そのためにBenchmarkとEvaluation Infrastructureが必要になる。
⸻
JPharmaBenchの位置
JPharmaBenchをこの視点で見ると、Domain-specific AIを「作る」だけではなく、「測る」ための仕組みとして位置づけられる。
これは重要な転換である。
AI Development
から、
AI Measurement
へ。
高信頼AIでは、測れないものを安全に改善することは難しい。
⸻
Evaluationは一度では終わらない
AI Systemは変化する。
Model Versionが変わる。
Promptが変わる。
Knowledge Baseが変わる。
RAG Pipelineが変わる。
そのたびにBehaviorも変わり得る。
したがってEvaluationはRelease前の一回限りの試験ではない。
Continuous Evaluation
が必要になる。
⸻
Regressionを検出する
新しいModelが平均Performanceでは向上しても、一部Taskでは悪化する可能性がある。
そこで過去Versionと比較する。
重要Caseが壊れていないかを見る。
つまりSoftware EngineeringにおけるRegression TestをAIへ拡張する。
Model Update → Evaluation → Regression Check → Release Decision
というProcessになる。
⸻
Hallucinationを前提に設計する
LLMは誤った内容を生成する可能性がある。
高信頼AIでは、
「Hallucinationを完全になくす」
という約束だけに依存すべきではない。
Evidenceを提示する。
Sourceへ戻れるようにする。
Confidenceが低い場合は回答を制限する。
HumanへEscalateする。
つまり、
Failure PossibilityをArchitectureへ組み込む。
⸻
RAGも万能ではない
RAGを使えば常に正しい回答になるわけではない。
Retrievalが間違う。
古いDocumentを取る。
Relevant Informationを見逃す。
Context Interpretationを誤る。
したがって、
Retrieval Quality。
Source Quality。
Answer Quality。
を分けて評価する必要がある。
Technologyの名前ではなく、System Behaviorを見る。
⸻
Traceability
高信頼業務では、
AIが何を出したか
だけでは足りない。
どのDataを使ったのか。
どのModel Versionだったのか。
どのPromptだったのか。
誰が確認したのか。
いつApproveしたのか。
を追跡できる必要がある。
これがTraceabilityである。
⸻
Auditability
Traceabilityをさらに組織的に利用できるようにしたものがAuditabilityである。
問題が起きた後に、
何が起きたのか。
どこで判断が変わったのか。
どのComponentに原因があったのか。
を調査できる。
つまり、
AI OutputをBlack Boxのまま業務へ埋め込まない。
これが高信頼AIの基本になる。
⸻
Explainabilityを目的化しない
Explainabilityも重要である。
しかし「説明らしい文章をAIが出した」だけでは十分ではない。
重要なのは、Humanが判断するために必要なInformationを提供できるかである。
Evidence。
Difference。
Source。
Confidence。
Relevant Rule。
つまり、
Explanation for Decision
である。
⸻
Human-in-the-loop
高信頼AIではHumanが重要なSystem Componentになる。
AIが候補を生成する。
HumanがReviewする。
必要なら修正する。
Approveする。
AIはHumanを置き換えるだけではなく、
Human Judgmentを増強する。
特に高Risk Domainでは、この設計が重要になる。
⸻
Humanを形式的に置くだけでは足りない
しかし「Humanが最終確認する」と書くだけでは安全にならない。
AI Outputを毎回承認しているうちに、Humanが自動的にApproveするようになる可能性がある。
Automation Biasである。
したがって、
何を表示するか。
どのCaseを強調するか。
どこでSecond Reviewを要求するか。
まで設計する必要がある。
⸻
Human Oversightそのものを評価する
高信頼AIでは、ModelだけでなくHuman–AI TeamのPerformanceを測る必要がある。
AIだけの場合。
Humanだけの場合。
Human + AIの場合。
どれが最も正確か。
どれが速いか。
どのFailureが増えるか。
つまり、
System Evaluation includes Human.
⸻
SecurityはTrustの一部である
AIが正確でも、Dataが漏洩すれば信頼できない。
企業Data。
製薬Document。
Infrastructure Information。
これらを扱うなら、
Authentication。
Authorization。
Encryption。
Access Logging。
Data Isolation。
が必要になる。
高信頼AIではCybersecurityを後付けできない。
⸻
PrivacyとData Governance
誰のDataを使えるのか。
Trainingへ利用できるのか。
どこへ保存するのか。
いつ削除するのか。
Third-party Modelへ送信できるのか。
AI導入では、Model選択以上にData Governanceが重要になる場合がある。
したがって、
Trusted AI = Trusted Data Handling
でもある。
⸻
Cloudだけが答えではない
高機密DataではPublic Cloud APIへ送れない場合がある。
そのため、
Private Cloud。
Dedicated Environment。
Local Model。
On-premises。
Edge AI。
など複数のDeployment Optionが必要になる。
用途によってArchitectureを変える。
⸻
EnergyではTrustがPhysicalへ広がる
製薬ではAI ErrorがDocumentやQuality Workflowへ影響する。
Energyでは、対象がEquipmentやInfrastructureへ近づく。
そこでTrust Requirementが変わる。
Sensor Reliability。
Real-time Processing。
Network Failure。
Operational Safety。
が加わる。
つまり、
Information Reliability → Operational Reliability
へ広がる。
⸻
Physical AIではSafetyが中心になる
RobotがPhysical Environmentで動く場合、AI OutputはActionになる。
そこで、
Collision Avoidance。
Emergency Stop。
Safe State。
Human Override。
Redundancy。
が必要になる。
高信頼Physical AIでは、
Model ConfidenceだけでSafetyを保証しない
ことが重要になる。
⸻
AIとSafety Systemを分ける
例えばAIが「進める」と判断しても、Independent Safety Layerが危険を検知すれば停止する。
つまり、
AI Decision
と、
Safety Constraint
を分離する。
これは高RiskなPhysical Systemにおいて重要な考え方である。
⸻
Fail-safeという原則
SystemはFailureする。
重要なのはFailureを想定しないことではなく、Failureしたとき安全側へ移れることである。
通信が切れる。
Sensorが壊れる。
AIが判断できない。
その場合、
停止する。
Humanへ戻す。
限定Modeへ移る。
これがFail-safeである。
⸻
Reliability Engineeringとの接続
ここまで来ると、高信頼AIはAI Researchだけの問題ではなくなる。
Software Reliability。
Systems Engineering。
Safety Engineering。
Cybersecurity。
Human Factors。
Quality Management。
これらとの統合領域になる。
つまり、
AI Engineering → Systems Engineering
への拡張である。
⸻
原子力が要求するもの
原子力・廃炉関連のような領域では、この考え方が極端な形で要求される。
Humanが容易に立ち入れない。
Failure Costが大きい。
Physical Environmentが複雑である。
このような領域でAIを利用するなら、単体Modelの性能以上にSystem Architectureが重要になる。
EQUESがこの領域で経験を蓄積する意味は、ここにある。
⸻
高信頼AIは一つのProductではない
High-reliability AIという名前の単一Productを作れば完成するわけではない。
それは、
Architecture。
Engineering Process。
Evaluation Method。
Operational Practice。
Organization Culture。
の組み合わせである。
つまり、
Trust is not a Feature.
Trust is a System Property.
⸻
Trustは組織から生まれる
さらに、TechnologyだけでTrustを作ることはできない。
誰がReleaseを承認するか。
Incidentをどう報告するか。
Model Changeを誰がReviewするか。
CustomerへLimitationをどう説明するか。
こうしたOrganization Processも重要になる。
高信頼AI企業には、高信頼なOrganizationが必要になる。
⸻
「分からない」と言えるSystem
高信頼AIの重要な能力の一つは、常に答えることではない。
Confidenceが不足している。
必要Dataがない。
Domain外である。
判断できない。
そのとき、
I don’t know / Human review required
に相当する状態へ移れることが重要になる。
無理に答えるAIより、適切に停止できるAIの方が信頼できる場合がある。
⸻
Autonomyの境界を明確にする
AI Agentが普及すると、
検索する。
Documentを作る。
Systemを操作する。
Actionを実行する。
という自律性が高まる。
そこで、
Readだけ許可する。
Draftまで許可する。
External ActionにはApprovalを要求する。
Critical Actionは禁止する。
といったPermission Designが必要になる。
つまり、
Capability ≠ Permission
である。
できることと、してよいことを分ける。
⸻
高信頼AIはAgent時代にさらに重要になる
Chatbotが間違った回答を返す場合と、Agentが間違ったActionを実行する場合ではRiskが違う。
AIがTool Useへ進むほど、
Approval。
Audit。
Rollback。
Permission。
Observability。
が重要になる。
EQUESが高信頼産業で蓄積するCapabilityは、Agent時代にも接続可能なものになる。
⸻
ModelがCommodity化しても残るもの
将来Foundation Modelがさらに高性能化し、複数企業が似たModelを利用できるようになった場合、差別化の中心は変わる。
誰が最も大きなModelを持つか。
だけではなく、
誰が最も安全にDomainへ実装できるか。
誰が最も正確に評価できるか。
誰が最も継続的に改善できるか。
へ移る可能性がある。
⸻
Trustを企業資産へ変える
EQUESが製薬、Energy、Physical AIで、
Evaluation。
Security。
Audit。
Human Oversight。
Safety。
を共通化できれば、それは個別案件のRequirementではなくCompany Assetになる。
つまり、
Project-specific Trust → Reusable Trust Architecture
である。
⸻
Trusted by Default
新しいProductを作るたびにSecurityやEvaluationを一から考えるのではなく、
標準Logging。
標準Evaluation。
標準Permission。
標準Human Approval。
を最初から組み込む。
これが、
Trusted by Default
というCompany Architectureになる。
⸻
TrustはScaleの障害ではない
高信頼性を追求するとDevelopmentが遅くなる、と考えることもできる。
確かに初期Costは増える。
しかし共通基盤として再利用できれば、逆にScaleを支える。
一度作ったEvaluation Infrastructure。
Security Pattern。
Audit Architecture。
を複数Productへ利用する。
するとTrustそのものがLeverageになる。
⸻
製薬からEnergyへ移転するもの
製薬で学んだGMP固有Knowledgeを、そのままEnergyへ移すことはできない。
しかし、
Evaluation。
Traceability。
Human Review。
Controlled Change。
というPrincipleは移転できる。
Domain-specificなRuleと、Domain-independentなTrust Principleを分離する。
これがEQUESの複数事業を接続する鍵になる。
⸻
Common Trust Core
したがって将来的なArchitectureとしては、
Common Trust Core
の上に、
Pharmaceutical Layer。
Energy Layer。
Physical AI Layer。
を置く構造が考えられる。
Coreには、
Security。
Evaluation。
Audit。
Human Oversight。
Observability。
を置く。
Domain差を消さず、共通する信頼構造だけを再利用する。
⸻
高信頼AIという方向
本書で見てきたEQUESの活動は、一見すると広い。
AI受託開発。
製薬。
LLM。
Energy。
Physical AI。
Quantum。
Education。
しかしその中から一つの共通軸を抽出すると、
Research Technologyを、失敗Costの高い現実の産業へ実装する能力
が見えてくる。
そこでは必然的にTrustが中心になる。
⸻
高信頼AIの最小構造
最小化すれば、
AI
だけではなく、
**AI
* Evaluation
* Evidence
* Security
* Human Oversight
* Audit
* Failure Handling**
によって、高信頼AI Systemが成立する。
さらにPhysical Worldへ接続すれば、
**+ Safety
* Fail-safe
* Human Override**
が加わる。
⸻
Trustとは「絶対に間違えない」ことではない
最後に最も重要な点を確認しておく。
高信頼AIとは、
絶対に間違えないAI
を意味しない。
現実のAI Systemに、その保証を安易に置くべきではない。
むしろ、
間違える可能性を測る。
間違いを発見する。
影響を限定する。
Humanへ戻す。
原因を追跡する。
改善する。
その能力をSystemとして持つことである。
⸻
EQUESが製薬からEnergyへ、SoftwareからPhysical AIへ進むほど、この原則は重要になる。
AIが現実世界から遠い場所にあるとき、Failureは画面上のErrorとして終わる場合がある。
しかしAIが企業Workflowへ入り、Infrastructureへ入り、Robotへ入れば、Technologyと現実世界の距離は縮まる。
そのとき必要になるのは、より大きなAIだけではない。
より信頼できるAI Systemである。
そして高信頼AIがDigital Worldだけで完結しなくなったとき、次の接続が始まる。
SoftwareとMachine。
CloudとEdge。
DataとSensor。
AIとInfrastructure。
次節では、EQUESの社会実装が到達しつつあるもう一つの境界を、**「デジタルと物理世界をつなぐ」**という視点から整理する。
第4節 デジタルと物理世界をつなぐ
AIは長い間、Digital Informationを扱うTechnologyとして発展してきた。
Text。
Image。
Data。
Code。
Knowledge。
企業業務の中では、AIの多くがComputer Screenの内側で価値を生んできた。
EQUESもまた、生成AI、RAG、製薬Document、Domain-specific LLMなど、Digital Domainを中心に事業を広げてきた。
しかしEnergy、原子力、Remote Robotics、Physical AIへ進むと、AIの位置が変わる。
AIはDataを読むだけではなく、Sensorを通じてPhysical Worldを観測し、Machineを介して現実へActionを返すようになる。
ここで必要になるのが、
Digital WorldとPhysical Worldを接続するArchitecture
である。
⸻
DigitalとPhysicalは別世界ではない
現代のIndustrial Systemでは、DigitalとPhysicalはすでに深く接続されている。
MachineはSensorを持つ。
EquipmentはSoftwareによって制御される。
Operational DataはCloudへ送られる。
EngineerはDigital Dashboardを見ながらPhysical Assetを管理する。
AIは、この既存の接続をさらに高度化する。
つまりPhysical AIは、まったく新しい世界を作るというより、
Physical SystemのDigital Intelligenceを高めること
から始まる。
⸻
Physical WorldをDigitalへ変換する
最初の接続はPhysicalからDigitalへの方向である。
Temperature。
Pressure。
Image。
Sound。
Vibration。
Position。
Force。
Radiation。
現実世界の状態をSensorがMeasurementへ変換する。
そしてMeasurementをDataとして扱う。
最小構造は、
Physical State → Sensor → Digital Data
である。
AIがPhysical Worldを理解するためには、まずこのTranslationが必要になる。
⸻
Sensor DataはRealityそのものではない
ここで重要なのは、MeasurementとRealityを同一視しないことである。
Sensorには限界がある。
Noise。
Calibration Error。
Blind Spot。
Sampling Rate。
Failure。
AIが見るのはRealityそのものではなく、Sensorを通じて得られたRepresentationである。
したがって、
Physical Reality ≠ Sensor Data
という境界を維持する必要がある。
⸻
複数Sensorを統合する
一つのSensorだけではEnvironmentを十分に理解できないことがある。
CameraでVisual Informationを見る。
LiDARでDistanceを測る。
MicrophoneでSoundを取得する。
Force Sensorで接触を確認する。
複数Dataを統合することで、より豊かなState Estimationが可能になる。
つまり、
Multimodal Sensor Fusion
である。
⸻
Digital Twinという中間表現
Physical Assetを継続的にDigital Representationへ写し取る考え方としてDigital Twinがある。
設備の現在状態。
位置。
温度。
Operation History。
Maintenance Record。
これらをDigital側へ保持する。
すると、
Physical Asset ⇄ Digital Representation
という接続が形成される。
AIはこのDigital Representationを使ってPredictionやSimulationを行える。
⸻
Digital Twinは単なる3D Modelではない
Digital Twinは、見た目を3Dで再現することだけではない。
重要なのはPhysical AssetとDigital Stateが継続的に対応していることである。
Sensorが更新される。
Digital Stateも更新される。
AIが分析する。
その結果をOperationへ利用する。
つまり、
Measure → Update → Analyze → Act
というLoopになる。
⸻
PredictionをPhysical Operationへ戻す
AIが設備異常の兆候を検出する。
Maintenance Timingを予測する。
HumanへRecommendationを出す。
ここでDigital AnalysisがPhysical Operationへ戻る。
つまり、
Physical → Digital → Decision → Physical
という循環が形成される。
これがCyber-Physical Systemの基本構造である。
⸻
Humanが中間にいる場合
すべてをMachineが直接実行する必要はない。
AIが異常を検出する。
Engineerが確認する。
Maintenanceを指示する。
つまり、
Sensor → AI → Human → Physical Action
である。
高信頼産業では、このHuman-mediated Loopが重要になる。
⸻
Robotが中間に入る場合
さらにRemote Roboticsでは、
SensorがEnvironmentを見る。
AIが認識を支援する。
HumanがTaskを指示する。
Robotが動く。
つまり、
Physical Environment
→ Sensor
→ AI
→ Human / Planner
→ Robot
→ Physical Environment
となる。
HumanとMachineの双方がLoop内部へ入る。
⸻
Physical AIではActionが重要になる
Digital AIではOutputをInformationとして返せばTaskが終わることがある。
Physical AIでは、
Actionが起きる。
そのActionによってEnvironmentが変わる。
したがって、
Inference
だけではなく、
Control
が必要になる。
ここでAIとControl Engineeringが接続する。
⸻
AIとControlは同じではない
AIが「右へ動くべき」と判断する。
しかしMotorをどの程度回すのか。
Accelerationをどう制御するのか。
どう停止するのか。
これはControl Systemの仕事になる。
つまり、
AI Planning → Control System → Physical Action
というLayer Separationが必要になる。
⸻
Classical Engineeringを置き換えない
Physical AIが進歩しても、すべてをNeural Networkへ置き換える必要はない。
Deterministic Control。
Safety Rule。
Mechanical Limit。
これらは既存Engineeringで確立されている。
必要なのは、
AI + Classical Engineering
である。
AIを現実世界へ接続するほど、既存Engineeringとの統合が重要になる。
⸻
Edgeという接続点
Physical WorldとCloudの間にはEdgeがある。
Robot。
Industrial PC。
Embedded Device。
Local Server。
Immediateな処理をここで行う。
例えば、
Obstacle Detection。
Emergency Stop。
Low-latency Control。
である。
一方、
Large Model。
Long-term Analysis。
Model Training。
はCloudで行える。
したがって、
Cloud ⇄ Edge ⇄ Physical Machine
という階層が成立する。
⸻
時間がArchitectureを決める
Digital Applicationでは、一秒程度のLatencyが問題にならないこともある。
Physical SystemではMillisecondsが重要になる場合がある。
つまり、
Latency Requirement
がCompute Placementを決める。
どこで処理するかは、CostだけではなくPhysical Timeによって決まる。
⸻
Network Failureを想定する
Physical AIがCloudへ依存する場合、通信Failureを無視できない。
Networkが切れる。
Bandwidthが落ちる。
Latencyが増える。
そのときMachineをどうするのか。
停止する。
Local Modeへ移る。
Humanへ戻す。
つまり、
Connectivity Failure → Defined Safe Behavior
を設計する必要がある。
⸻
Software UpdateがPhysical Behaviorを変える
Physical AIではSoftware Updateにも重い意味がある。
Modelを更新する。
するとRobotのRecognitionが変わる。
Planningが変わる。
Actionが変わる。
つまり、
Software Change → Physical Behavior Change
である。
そのためUpdateには再評価が必要になる。
⸻
Simulationで先に試す
Physical Environmentで直接すべてを試すことは危険でCostも高い。
そこでSimulationを利用する。
Robotを動かす。
Failureを発生させる。
Sensor Noiseを加える。
Network Delayを再現する。
新しいModelをTestingする。
Digital Environment側で多くのExperimentを行う。
⸻
SimulationはRealityの代替ではない
ただしSimulationだけでは十分ではない。
Realityには予測できない差が存在する。
したがって、
Simulation → Controlled Field Test → Operation
という段階が必要になる。
DigitalとPhysicalを行き来しながらSystemを成熟させる。
⸻
Digital側で学び、Physical側で検証する
このStructureを一般化すると、
Digital Learning
と、
Physical Verification
の組合せになる。
大量ExperimentはDigitalで行う。
最終的なValidityはPhysicalで確認する。
Physical AIでは、この往復が重要になる。
⸻
Physicalから再びDataが戻る
RobotがTaskを実行する。
成功した。
失敗した。
Humanが介入した。
この結果をDataとして保存する。
すると、
Physical Experience → Digital Learning Data
へ戻せる。
現実世界でのExperienceが次のModel Improvementへ使われる。
⸻
Closed Learning Loop
ここまで進むと、
Physical Environment
→ Data
→ AI
→ Action
→ Physical Result
→ New Data
→ AI Improvement
というLoopが形成される。
これはPhysical AIのLearning Cycleである。
ただしProduction中に自由にModelを変更することと、継続的にDataを収集してControlled Updateすることは区別する必要がある。
⸻
Human Feedbackも加わる
Physical Resultだけでは評価できないこともある。
Operatorが、
このMotionは危険だ。
このAlertは不要だ。
このInterfaceは見にくい。
とFeedbackする。
すると、
Environment Feedback + Human Feedback
の両方がSystem Improvementへ戻る。
⸻
DigitalとPhysicalの間にはHumanがいる
AIとRobotだけを見ているとHumanが抜け落ちる。
しかし実際には、
Operator。
Engineer。
Maintenance Staff。
Safety Manager。
がいる。
したがって完全なSystemは、
Digital + Physical + Human
である。
⸻
Human Interfaceは重要な接続層
Digital IntelligenceをHumanがPhysical Operationへ使う場合、Interface設計が重要になる。
どこに異常があるか。
どの程度Riskがあるか。
AIは何をRecommendationしているか。
Humanがすぐ理解できるようにする。
つまり、
Machine Representation → Human Actionable Representation
への変換である。
⸻
HapticsというPhysical Interface
EQUESのOriginにあるHapticsの視点をここで再び見ることができる。
Digital SystemからHumanへInformationを返す方法はVisual Displayだけではない。
Force。
Touch。
Resistance。
Physical Feedbackを利用することもできる。
Remote Operationでは、
Humanが遠隔地のPhysical Conditionを身体的に理解するためのInterfaceが重要になる。
⸻
DigitalからPhysicalへCommandを出すだけではない
Cyber-Physical Systemを、
「ComputerがMachineへCommandを送る仕組み」
とだけ捉えるのは不十分である。
本質は双方向性にある。
MachineからDataを得る。
Digital側で分析する。
Actionを返す。
結果を再び観測する。
つまり、
Physical ⇄ Digital
である。
⸻
製薬にもPhysicalとの接点がある
製薬AIは主にDocumentを扱ってきた。
しかしそのDocumentの背後にはPhysical Manufacturing Processがある。
製造設備。
原料。
工程。
品質検査。
DocumentはPhysical Processの記録でもある。
将来的には、
Manufacturing Data。
Sensor。
Quality Document。
を接続できる可能性もある。
ここでDocument AIとPhysical AIの境界が薄くなる。
⸻
KnowledgeとSensorを統合する
Industrial AIの強い形の一つは、
Current Sensor State
と、
Historical Knowledge
を統合することである。
今何が起きているか。
過去に似たCaseはあったか。
Manualではどう対応するか。
AIがこれらを同時に扱う。
EQUESのLLM/RAG CapabilityとPhysical AI Capabilityは、この地点で接続し得る。
⸻
AgentとPhysical AI
AI AgentがEnterprise Softwareを操作する。
Physical AIがRobotを操作する。
この二つが接続すれば、
Digital WorkflowからPhysical Taskまで一続きになる可能性がある。
例えば、
Maintenance Requirementを検知する。
AgentがWork Orderを作る。
HumanがApproveする。
RobotがInspectionする。
結果をSystemへ戻す。
という構造である。
⸻
ActionにはPermissionが必要になる
しかしAction範囲が広がるほど、Permission Designが重要になる。
Dataを読む。
Reportを作る。
Work Orderを作る。
Robotを動かす。
それぞれRiskが異なる。
したがって、
Action Capability → Permission Level
を対応させる必要がある。
⸻
Digital IdentityとPhysical Authority
さらにPhysical AIでは、
誰がRobotをControlできるのか。
誰がRemote Operationを開始できるのか。
どのAgentがどのMachineへCommandを送れるのか。
をIdentityで管理する。
つまり、
Digital Identity → Physical Authority
が成立する。
CybersecurityとPhysical Safetyが接続する地点である。
⸻
AuditもPhysical Eventまで追う
AI AgentがCommandを出した。
Robotが実行した。
HumanがOverrideした。
その結果何が起きたか。
これを一続きのLogとして残す。
すると、
Digital Decision → Physical Action → Physical Outcome
をAuditできる。
高信頼Physical AIでは重要なCapabilityになる。
⸻
DigitalとPhysicalの境界を誰が設計するか
AI Model Providerだけでは、このSystem全体を作れない。
Robot Companyだけでも難しい。
Cloud Providerだけでもない。
必要なのは、
Data。
AI。
Software。
Hardware。
Human。
Safety。
を統合するSystem Architectureである。
ここにEQUESのような社会実装企業が担える余地がある。
⸻
System Integratorとは少し違う
ただし従来型のSystem Integrationだけとも異なる。
既存Componentを接続するだけでなく、
まだ成熟していないAI Researchを扱う。
新しいModelを評価する。
必要ならResearchする。
つまり、
Research-capable System Integration
である。
これがEQUES型企業の一つの特徴になり得る。
⸻
Physical AI Companyになる必要はない
EQUESがすべてのRobot Hardwareを所有する必要はない。
重要なのは、
AI。
Software。
Evaluation。
Safety。
Partner Technology。
を統合するCapabilityを持つことである。
つまり、
Own the Intelligence and Architecture, collaborate on the Physical Stack
という形も可能になる。
⸻
デジタルから物理へは一方向ではない
本節の題名は「デジタルと物理世界をつなぐ」である。
重要なのは、DigitalからPhysicalへ進むだけではないことである。
Physical WorldからDataを得る。
Digitalで理解する。
PhysicalへActionを返す。
その結果を再びDigitalへ戻す。
接続は循環している。
⸻
二つの世界を一つのSystemとして扱う
最終的には、
Digital System
と、
Physical System
を別々に管理するのではなく、
一つのOperational Systemとして設計する必要がある。
AIはその中央にあるが、すべてではない。
Sensor。
Network。
Machine。
Human。
Environment。
が同時にSystemを構成する。
⸻
EQUESの変化を再び見る
2022年のEQUESをResearch-origin Software AI Companyとして見る。
そこから、
Document AI。
Domain Model。
Evaluation。
Energy。
Remote Robotics。
へ進む。
このTrajectoryは、
Digital Intelligenceの深度を高めながら、Physical Interfaceを獲得する過程
として読むことができる。
⸻
デジタルと物理世界をつなぐ会社
この方向が進めば、EQUESの役割は、
AI Softwareを提供する会社
だけではなく、
Digital IntelligenceをPhysical Operationへ安全に接続する会社
へ広がる。
ただし、その価値はRobotを持つことではない。
DigitalとPhysicalの間にある複数のTranslation Layerを設計できることである。
⸻
最小構造
本節を最小化すると、
Physical World
↓
Sensor / Measurement
↓
Digital Representation
↓
AI / Computation
↓
Human / Control / Safety
↓
Machine Action
↓
Physical World
となる。
そして結果は再びDataとして戻る。
つまり、
Physical → Digital → Physical
というClosed Loopである。
⸻
AIがこのLoopへ入ると、Softwareは現実世界から切り離されたものではなくなる。
だからこそ、AccuracyだけでなくSafetyが必要になり、CloudだけでなくEdgeが必要になり、ModelだけでなくHumanとHardwareが必要になる。
EQUESがDigitalからPhysicalへ進む意味は、このSystem全体を扱う必要が生まれることにある。
そして、DigitalとPhysicalを接続しても、なお最後に残る接続がある。
Technologyを使い、判断し、責任を持ち、学び続けるHumanである。
次節では、EQUESの社会実装を支えるもう一つの軸として、**「人間とAIをつなぐ」**ことの意味を整理する。
第5節 人間とAIをつなぐ
AIが高度になるほど、人間は不要になる。
そのように語られることがある。
しかし、EQUESの事業領域を追ってきた本書から見えるのは、むしろ反対の構造である。
AIが製薬、Energy、Infrastructure、Physical AIのような高信頼領域へ入るほど、人間の役割は消えるのではなく、再配置される。
AIが生成する。
人間が確認する。
AIが異常を検出する。
人間が判断する。
AIがAction候補を出す。
人間が権限を与える。
AIが実行する。
人間が監督する。
つまり、社会実装の中心には常に、
Human–AI Interaction
が存在する。
AIを社会へ導入するとは、MachineをHumanから切り離すことではない。
HumanとAIの間に、適切なInterface、Role、Responsibility、Feedback Loopを設計することである。
⸻
HumanはSystemの外側にいない
一般的なSoftwareでは、Humanを「User」としてSystem外部に置くことが多い。
しかし高信頼AIでは、それだけでは不十分である。
Reviewer。
Approver。
Operator。
Supervisor。
Domain Expert。
Manager。
Humanは複数のRoleを持ちながら、AI Systemの内部へ組み込まれる。
したがって、
AI System = Model + Software + Human
と考える必要がある。
⸻
Human-in-the-loop
最も分かりやすい形がHuman-in-the-loopである。
AIがOutputを作る。
Humanが確認する。
必要なら修正する。
その後、正式なActionへ進む。
製薬の品質保証業務では、この構造が特に重要になる。
AIがDraftを作れても、最終判断をHumanが担う。
つまり、
AI Generation → Human Verification
である。
⸻
Human-on-the-loop
Automationが進むと、Humanが一件ずつ確認するのではなく、System全体を監督する形も増える。
通常TaskはAIが処理する。
例外だけHumanへ送る。
Critical EventではHumanが介入する。
これは、
Human-on-the-loop
である。
Physical AIやAI Agentでは、この設計が重要になる。
⸻
Human-out-of-the-loopはRiskで決める
すべてのTaskにHumanを置く必要はない。
低RiskなTaskなら完全Automationできる。
一方、高RiskなTaskではHuman Approvalを必須にする。
つまり、
Risk → Human Involvement
である。
重要なのはHumanを減らすことでも、増やすことでもない。
適切な場所へ置くことである。
⸻
Humanの役割はExecutionからJudgmentへ
AIがRoutine Taskを担当すると、人間の仕事は変わる。
文章を書く。
から、
内容を確認する。
Dataを探す。
から、
どの情報が重要か判断する。
Robotを直接操作する。
から、
Missionを監督する。
つまり、
Execution → Judgment
への移動が起こる。
AI時代に人間へ求められるのは、単なる操作能力だけではなく、判断能力になる。
⸻
AIはHuman Capabilityを拡張する
製薬では、AIが大量Documentを読む。
Humanは重要な差異へ集中する。
Energyでは、AIがSensor Dataを監視する。
Humanは異常判断へ集中する。
Physical AIでは、Robotが危険区域へ入る。
Humanは安全な場所からOperationする。
共通するのは、
Replacement
より、
Augmentation
である。
AIはHuman Capabilityの範囲を広げる。
⸻
Human Errorも減らせる
AI導入の価値は、人員削減だけではない。
Humanは疲れる。
見落とす。
大量Documentを比較するとErrorが起きる。
AIがConsistency CheckやAnomaly Detectionを支援すれば、Human Errorを減らせる可能性がある。
つまり、
Human + AI > Human Alone
となるSystemを作る。
⸻
AI ErrorをHumanが補う
一方、AIもErrorを起こす。
Hallucination。
False Positive。
False Negative。
Unexpected Behavior。
これをHumanが補う。
したがってHumanとAIは、どちらかが完全であるという前提ではなく、
異なるFailure Modeを持つ二つの主体
として組み合わせる。
⸻
Complementarity
理想的なHuman–AI Systemでは、双方が同じTaskを競争するのではない。
AIが大量処理を担当する。
HumanがContextと責任を担当する。
AIが候補を作る。
Humanが選ぶ。
AIがMonitorする。
HumanがExceptionを処理する。
これがComplementarityである。
⸻
Interfaceが両者をつなぐ
HumanとAIの間にはInterfaceがある。
AIがどれだけ高性能でも、Interfaceが悪ければHumanは正しく使えない。
Output。
Evidence。
Confidence。
Warning。
Action Option。
これらを分かりやすく提示する。
つまり、
AI Output Interface
から、
Human Decision Interface
へ設計思想を変える。
⸻
説明は判断のためにある
Explainabilityも同じである。
AIの内部を完全に説明することが目的ではない。
Humanが、
信頼してよいか。
追加確認が必要か。
Rejectすべきか。
を判断できることが重要である。
したがって、
Explainability → Actionable Understanding
でなければならない。
⸻
Confidenceをどう見せるか
AIが不確実な場合、その不確実性をHumanへ伝える必要がある。
High Confidence。
Review Required。
Insufficient Information。
このような状態を表示する。
細かいProbabilityを見せればよいとは限らない。
HumanのActionにつながる形へ変換することが重要である。
⸻
「分からない」を伝える
AIが分からないときに、無理に答えるSystemは危険である。
必要Dataがない。
Domain外である。
Confidenceが低い。
その場合、
HumanへEscalateする。
Additional Dataを求める。
停止する。
つまり、
AI knows when to defer.
このCapabilityがHuman–AI Collaborationを成立させる。
⸻
Human Approvalは設計対象である
Approval Buttonを置けばHuman Oversightになるわけではない。
何を確認するのか。
Evidenceはどこにあるのか。
Rejectできるのか。
誰がApproveできるのか。
時間は十分か。
Approval Workflowそのものを設計する必要がある。
Humanを安全機能として扱うなら、その安全機能自体をEngineeringしなければならない。
⸻
Automation Bias
AIが高精度になると、HumanがAIを過信する可能性がある。
いつも正しいから今回も正しい。
そう思い始める。
その結果Reviewが形式化する。
したがって、
Human-in-the-loop ≠ Automatically Safe
である。
Humanが本当に疑い、検証できる仕組みが必要になる。
⸻
Cognitive Load
逆にHumanへ確認事項を増やしすぎると、Systemは使われなくなる。
すべてのAI Outputに詳細なLog。
Confidence。
Source。
Warning。
を大量表示すれば、Humanが処理できない。
重要なのは、
必要なInformationを必要な時だけ出すこと
である。
Human Factors Engineeringが必要になる。
⸻
Human Centered Design
AI SystemはModel中心ではなくHumanのTask中心に設計する必要がある。
Humanは何を達成しようとしているのか。
どの時点でAIが役立つのか。
どの情報が必要なのか。
どこで判断するのか。
つまり、
Human Task → AI Support
という順序で設計する。
⸻
AI×DX寺子屋の意味
EQUESのAI×DX寺子屋は、このHuman–AI接続の另一方を支える。
AI SystemをHumanに合わせるだけではない。
Human側もAIを理解する必要がある。
何ができるか。
何ができないか。
どこで疑うべきか。
どう使えばよいか。
EducationによってHuman側のCapabilityを高める。
⸻
InterfaceとEducationは両方必要
使いやすいSystemを作れば教育は不要になる。
あるいは、TrainingすればInterfaceは多少悪くてもよい。
どちらも十分ではない。
必要なのは、
Better System + Better User Capability
である。
TechnologyとHumanの双方を改善する。
⸻
Learningは一度で終わらない
AI Technologyは変化する。
Model。
Tool。
Agent。
Rule。
変わり続ける。
したがってHuman側も学び続ける必要がある。
AI×DX寺子屋 LearningのようなContinuous Learningが重要になる理由がここにある。
⸻
Human FeedbackがAIを改善する
HumanがAI Outputを修正する。
Rejectする。
追加情報を与える。
この行動はFeedbackになる。
どこでAIが失敗したか分かる。
Evaluation Dataになる。
Product Improvementへ使える。
つまり、
Human Use → Human Feedback → AI Improvement
である。
⸻
AIもHumanを育てる
反対方向もある。
AIを使うことでHumanが新しいKnowledgeへ接触する。
過去事例を検索する。
異なるPerspectiveを見る。
Draftを比較する。
AIはLearning Toolにもなる。
つまり、
AI Support → Human Learning
が起こる。
⸻
双方向Learning
ここでHumanとAIの関係は固定Roleではなくなる。
HumanがAIを改善する。
AIがHumanを支援する。
Humanがさらに高度なTaskを行う。
そのFeedbackがまたAIへ戻る。
つまり、
Human ⇄ AI
という双方向Learning Loopが形成される。
⸻
Organizationも入る
しかしHuman個人だけを見ていても不十分である。
HumanはOrganizationの中で働く。
Role。
Authority。
Policy。
Workflow。
Training。
Culture。
これらがAIの使われ方を決める。
したがって最終的には、
AI ⇄ Human ⇄ Organization
を見る必要がある。
⸻
Managerの役割
AI導入ではManagerのRoleも重要になる。
どの仕事をAutomationするか。
誰に新しいRoleを与えるか。
AI Errorをどう扱うか。
Training Timeを確保するか。
Human–AI Work DesignはManagement Issueでもある。
⸻
Responsibilityを残す
AIがRecommendationしたからといって、Organizationが責任をAIへ移すことはできない。
AIの権限範囲を決める。
Humanの責任範囲を決める。
Escalationを決める。
つまり、
Capability / Authority / Accountability
を分けて設計する。
⸻
AI Agentではさらに重要になる
AI AgentがToolを操作し始めると、Human–AI関係はさらに深くなる。
AIが読むだけではない。
Writeする。
Sendする。
Changeする。
Executeする。
このとき、
Permission。
Approval。
Audit。
Rollback。
が必要になる。
Agent時代はHuman Oversight Architectureの重要性を高める。
⸻
Physical AIではHuman Safetyになる
Physical AIではHumanとの接続はさらに直接的になる。
RobotがHumanの近くで動く。
Remote OperatorがMachineを操作する。
AIがCollision Riskを判断する。
ここではHuman–AI InterfaceがSafety Systemの一部になる。
⸻
Hapticsという接続
EQUESの創業者が関わってきたHapticsという研究領域は、この点で象徴的である。
Digital InformationをVisualやTextだけでなく、ForceやTouchとしてHumanへ返す。
HumanがPhysical Environmentを身体的に理解する。
Remote Roboticsでは特に重要になる可能性がある。
DigitalとHuman Bodyの間にもInterfaceが存在する。
⸻
Humanを危険から遠ざける
原子力廃炉のようなEnvironmentでは、Human–AI接続の目的は生産性だけではない。
人間が危険区域へ入る時間を減らす。
Remote OperationでHuman Capabilityを拡張する。
つまり、
Human Safety through AI and Robotics
である。
これはAutomationの社会的価値をより広く捉える視点である。
⸻
Humanを残すことは後退ではない
高度なAI SystemにHumanを残すことを、「AIが未熟だから仕方なく人間が確認している」とだけ見るべきではない。
価値判断。
責任。
Ethics。
Unexpected Situation。
Humanに残すべきTaskがある。
つまりHuman Oversightは暫定措置ではなく、System Design Choiceでもある。
⸻
AIに任せる範囲を進化させる
ただしHumanとAIの役割分担は固定ではない。
AI性能が上がる。
Evaluationが蓄積する。
Riskが理解される。
するとAutomation Levelを上げられる。
逆に問題が見つかれば下げる。
つまり、
Adaptive Autonomy
として設計することもできる。
⸻
Trust Calibration
HumanがAIを信じなさすぎれば価値が出ない。
信じすぎれば危険になる。
必要なのは、
適切な信頼水準
である。
AIの能力と限界に合わせてHuman Trustを調整する。
これがTrust Calibrationである。
Education、Explainability、Experienceがその基盤になる。
⸻
人間とAIをつなぐ企業
EQUESのHuman & Organization領域を一つの企業能力として見るなら、その役割は「AI研修をすること」だけではない。
AI SystemをHumanが使える形へする。
HumanをAIが使えるOrganizationへ育てる。
現場FeedbackをTechnologyへ戻す。
つまり、
AI ⇄ Human Translation
を担うことである。
⸻
ResearchからHumanまで
本書のStructureをここまで戻すと、
Research
→ Technology
→ Product
→ Workflow
→ Human
へ進んできた。
しかしHumanで終わらない。
Humanが使う。
Feedbackする。
新しいProblemを見つける。
そのProblemが再びResearchへ戻る。
つまり、
Research → Human → Research
という循環になる。
⸻
人間とAIをつなぐ最小構造
本節を圧縮すると、
AI
↓
Evidence / Interface
↓
Human Judgment
↓
Action
↓
Feedback
↓
AI Improvement
となる。
その周囲を、
Education。
Organization。
Governance。
が支える。
⸻
人間とAIをつなぐということは、人間にAIの操作方法を教えるだけではない。
AIの能力をHumanが理解できる形へ変え、HumanのKnowledgeをAIが利用できる形へ変え、両者の役割と責任をOrganizationとして設計することである。
この接続が成立して初めて、AIは社会の中で継続的に使われる。
そしてHumanとAIが実際の現場で協働すると、そこで新しいKnowledgeが生まれる。
どこでAIが失敗したのか。
どこでHumanが補ったのか。
どのWorkflowが有効だったのか。
そのKnowledgeを再び研究へ戻せば、Researchそのものも変わる。
次節では、この本全体を閉じる直前の重要な循環として、**「社会実装から研究へ戻る」**を整理する。
第6節 社会実装から研究へ戻る
研究からTechnologyが生まれる。
TechnologyをPrototypeへする。
企業へ導入する。
Humanが使う。
Systemが現場で動く。
通常、この流れは「研究成果の社会実装」として説明される。
しかし、そこで終われば一方向である。
EQUESのような研究開発型AI企業にとって本当に重要なのは、その先にある。
社会へ出したTechnologyから、新しいProblemが見つかる。
現場でしか見えなかったFailureが現れる。
Humanの使い方から、新しいRequirementが生まれる。
そのInformationを再びResearchへ戻す。
つまり、
Research → Implementation → Feedback → Research
というLoopを閉じることである。
社会実装はResearchの終点ではない。
次のResearchを生み出す観測地点でもある。
⸻
Labでは見えないProblemがある
研究Environmentでは、条件をある程度制御できる。
Datasetを用意する。
Benchmarkを設定する。
Taskを定義する。
しかしProductionでは、想定外が起きる。
入力Formatが違う。
Dataが欠ける。
Humanが予想外の使い方をする。
System同士が複雑に接続する。
Regulationが変わる。
現場では、Research Environmentで切り落としていたConstraintが戻ってくる。
つまり、
Lab Reality ≠ Operational Reality
である。
⸻
Failureは新しい研究資源になる
AIが失敗したとき、単にBug Reportとして処理するだけではもったいない。
なぜ失敗したのか。
Modelの限界か。
Dataの不足か。
Retrievalの問題か。
Domain Knowledgeの不足か。
Human Interfaceの問題か。
Failureを分解すると、新しいResearch Questionが見えてくる。
Failure → Question
へ変換する。
これが研究開発型企業の重要な能力である。
⸻
Production Failureは価値が高い
SyntheticなBenchmarkだけでは分からないFailureがある。
実際のUser。
実際のData。
実際のWorkflow。
実際のLatency。
そのEnvironmentで初めて起きるProblemである。
このFailureは、Researcherにとって非常に価値が高い。
なぜなら、
Real-world Distribution
の中でAIがどのように壊れるかを教えてくれるからである。
⸻
製薬現場から戻るQuestion
製薬AIを例にする。
AIはDocumentを生成できる。
しかし実際に利用すると、
特定Formで抜けが出る。
専門Vocabularyの解釈が曖昧になる。
複数Document間で矛盾が起きる。
Human Reviewに時間がかかる。
こうしたProblemが見える。
するとResearch Questionは変わる。
より正確なGenerationだけではなく、
Consistency。
Evidence Retrieval。
Uncertainty。
Human Review Assistance。
が必要になる。
⸻
Checkerは現場Failureから生まれる発想である
生成AIを作るだけなら、Generatorで止まる。
しかし実際の業務で使えば、
「生成した内容を誰が確認するのか」
という問題が現れる。
そこでCheckerという別のCapabilityが必要になる。
これは、
Implementationが新しいResearch / Product Requirementを生んだ
と見ることができる。
⸻
Benchmarkも現場から戻る
一般Benchmarkでは高性能だったModelが、製薬Domainでは十分に動かない。
すると、
「製薬で本当に必要な能力とは何か」
を測るBenchmarkが必要になる。
ここでJPharmaBenchのようなDomain Evaluationへ進む。
つまり、
Operational Gap → Evaluation Research
である。
⸻
Energyでは別のFailureが戻る
EnergyやPhysical AIへ進むと、さらに違うProblemが現れる。
Sensor Noise。
Network Delay。
Unknown Environment。
Hardware Failure。
Human Override。
SimulationとRealityの差。
これらはText AIだけを研究していても見えない。
Physical EnvironmentがResearch Questionを作る。
⸻
RealityがResearch Agendaを変える
この構造は重要である。
Researcherが「何を研究したいか」だけでAgendaを決めるのではない。
社会実装した結果、
「何を研究しなければならないか」
が分かる。
つまり、
Reality-informed Research
である。
⸻
Market Demandだけに従うことでもない
ただし、Customerが欲しいと言ったFeatureをすべてResearchすることとは違う。
顧客要望。
System Failure。
Domain Constraint。
それらの背後にある一般化可能なTechnical Problemを見つける。
例えば、
「この画面を変えてほしい」
ではなく、
「HumanがAI Confidenceを理解しにくい」
という一般Problemへ抽象化する。
Researchへ戻すには、再びTranslationが必要になる。
⸻
Specific ProblemからGeneral Questionへ
社会実装で見つかるProblemは具体的である。
A社のこのDocument。
B設備のこのSensor。
C RobotのこのFailure。
Researchへ戻すときは、
Specific Case → Generalizable Question
へ変換する必要がある。
これによって一社のProblemが、より広いTechnology Improvementへつながる。
⸻
顧客DataをそのままResearchへ使わない
ここではGovernanceが重要になる。
Production Data。
Confidential Information。
Personal Information。
これらを無条件にResearch利用することはできない。
Contract。
Consent。
Anonymization。
Access Control。
Purpose Limitation。
を考える必要がある。
つまり、
Learning Capability + Data Governance
を同時に設計する。
⸻
Privacy-preserving Learning
将来的には、Dataを外へ出さずに学習や評価を行う方法も重要になる。
Local Evaluation。
Federated Approach。
Synthetic Data。
Privacy-preserving Processing。
用途に応じた選択が必要になる。
高信頼産業では、Research SpeedだけではなくData GovernanceがResearch Architectureを決める。
⸻
Human Feedbackを研究資源へする
HumanがAI Outputを修正する。
Rejectする。
追加説明を求める。
これらには価値の高いInformationが含まれる。
どのCaseが難しいか。
どのOutputが不適切か。
Humanは何を重要と見たか。
これを構造化すれば、
Human Feedback → Evaluation / Training Signal
へ変換できる。
⸻
ただしFeedbackはそのまま正解ではない
Humanも間違える。
Expert同士で意見が分かれる。
Context依存の判断もある。
したがってHuman Feedbackを無条件にGround Truthとして扱うべきではない。
Multiple Review。
Consensus。
Rule。
Domain Validation。
が必要になる場合がある。
高信頼AIではHuman Feedbackそのものも評価対象になる。
⸻
Environment Feedback
Physical AIではHuman以外からもFeedbackが得られる。
RobotがTaskを完了したか。
Collisionしたか。
予定時間内に終わったか。
Energy Consumptionはどうだったか。
Physical Outcomeが直接Evaluationになる。
つまり、
Action → Outcome → Learning Signal
である。
⸻
RealityがObjective Functionを修正する
Research段階では、AccuracyをObjectiveにしていた。
しかし運用すると、
Latencyが重要だった。
Human Workloadが大きかった。
Costが高かった。
Safety Marginが不足していた。
と分かる。
するとObjective Functionそのものを変更する必要がある。
Optimize the right thing.
社会実装は、「何を最適化すべきか」を教えてくれる。
⸻
Model PerformanceからSystem Performanceへ
Researchへ戻すQuestionも変わる。
Model Accuracyを上げるだけではなく、
Human + AIでErrorを減らせるか。
End-to-end Latencyを下げられるか。
Production Costを下げられるか。
Safe Failureができるか。
つまり、
Model-level Research
から、
System-level Research
へ広がる。
⸻
Researchの単位が大きくなる
AIが産業へ深く入るほど、研究対象はModelだけではなくなる。
Data Pipeline。
Retrieval。
Agent。
Human Interface。
Sensor。
Control。
Security。
Organization。
複数LayerがInteractionする。
したがって、
AI Research → AI Systems Research
への拡張が起こる。
⸻
Socio-technical Research
HumanやOrganizationまで含めれば、さらに研究対象は広がる。
HumanはAIをどう信頼するのか。
どのApproval Designが有効か。
TrainingによってErrorは減るか。
Automation Biasはどう起きるか。
つまり、
Technical System + Human System
を一体として研究する必要がある。
これはSocio-technicalなResearchになる。
⸻
AI×DX寺子屋から戻るFeedback
教育活動もResearch Sourceになり得る。
Userはどこで理解につまずくのか。
何を誤解するのか。
どのUse Caseを思いつくのか。
どのRiskを見落とすのか。
これらはHuman–AI Interactionを理解するDataになる。
Educationは一方向にKnowledgeを渡すだけではない。
社会がAIをどう理解しているかを観測する場所でもある。
⸻
Productから研究へ
Productには継続的なUsageがある。
その中で、
どのFunctionが使われるか。
どこでErrorが起きるか。
Humanがどこを修正するか。
が分かる。
ここから、
Product Analytics → Research Prioritization
が可能になる。
研究Themeを現場価値と接続しやすくなる。
⸻
受託から研究へ
ProjectではProductより深いCustomer-specificなProblemへ入れる。
まだStandardizeされていないFrontier Problemを知る。
そこから新しいResearch Themeが生まれる。
つまり、
Project = Research Sensor
でもある。
受託開発を単なるRevenue Businessと見ない理由がここにもある。
⸻
Physical Fieldから研究へ
Physical AIではField TestそのものがResearchになる。
Labで成功した。
Fieldでは失敗した。
その差を見る。
Lighting。
Terrain。
Sensor Noise。
Human Behavior。
Field RealityがModelのAssumptionを破る。
これはResearchにとって重要なInformationである。
⸻
Sim-to-RealからReal-to-Simへ
通常はSimulationからRealityへ移すSim-to-Realを考える。
しかしFieldでFailureが起きたら、そのFailureをSimulationへ戻すこともできる。
Realityで見つかったSituationをSimulationで再現する。
大量にVariationを作る。
改善する。
つまり、
Real → Sim → Improve → Real
という逆方向Loopが成立する。
⸻
IncidentからTest Caseへ
Productionで起きたIncidentを、その場限りで終わらせない。
原因を分析する。
Test Caseへ変える。
以後すべてのModel Updateで確認する。
すると、
Failure → Permanent Regression Test
になる。
過去のFailureが未来のSafetyを高める。
⸻
Company MemoryとResearch Memory
このProcessを続けるには、Knowledgeを残す必要がある。
何が起きたか。
何を試したか。
結果はどうだったか。
どのHypothesisが否定されたか。
これをCompany Memoryへ残す。
Research Experimentも同様である。
つまり、
Operational Memory + Research Memory
を接続する。
⸻
AI自身がResearch Memoryを読む
Knowledgeが増えれば、Humanだけで全てを記憶することは難しい。
そこでAIを使って、
過去のExperimentを検索する。
類似Failureを探す。
Relevant Paperを見つける。
過去のArchitecture Decisionを読む。
EQUES自身がAIを使ってResearch Cycleを高速化できる。
⸻
Research Prioritization
社会実装から大量のProblemが戻る。
しかし全部を研究できるわけではない。
そこでPriorityを付ける。
Failure Frequency。
Impact。
Generalizability。
Strategic Relevance。
Technical Novelty。
を評価する。
つまり、
Feedback → Research Portfolio
へ変換する。
⸻
Business ValueとScientific Valueを両方見る
企業Researchでは、
顧客価値が高いか。
Scientificに新しいか。
二つの軸がある。
両方高いものは理想的である。
しかしすべてがそうではない。
短期的Engineeringで解くべきProblem。
長期Researchが必要なProblem。
を分ける。
ここにResearch Managementが必要になる。
⸻
研究へ戻ることで模倣を避ける
AI Applicationだけを作る企業は、Foundation Modelの進歩によって機能がCommodity化するRiskがある。
しかしProductionで独自のProblemを発見し、それをResearchへ戻せれば、次のDifferentiationを作れる可能性がある。
つまり、
Implementation → Proprietary Learning
である。
ただし独自性は顧客Dataの独占ではなく、一般化されたLearning Capabilityから生むべきである。
⸻
Research AdvantageはFeedback Advantageになる
大学発Startupの強みを、Research Talentだけと考える必要はない。
もし社会実装からResearchへ戻るLoopが短ければ、
Customer Problemを早く知る。
Failureを早く研究する。
改善を早くProductionへ戻す。
というAdvantageを作れる。
つまり、
Research Advantage = Feedback Loop Advantage
になり得る。
⸻
Loop Speed
競争力は、一回のTechnology Superiorityだけではない。
Problemを観測してから改善するまでの時間。
このLoop Speedが重要になる。
Observe → Analyze → Research → Implement → Verify
をどれだけ速く回せるか。
AI Technologyが速く変化するほど、この能力は重要になる。
⸻
SpeedだけでなくQuality
ただしLoopを速く回すためにValidationを省略してはならない。
特に高信頼産業では、
Fast Learning。
Controlled Deployment。
を分ける。
研究では高速に試す。
Productionへは慎重に出す。
つまり、
Learn Fast, Release Safely.
である。
⸻
Continuous LearningとはProductionで勝手に学習することではない
「社会実装から研究へ戻る」というLoopを、Production AIが無制限にOnline Learningすることと混同してはいけない。
Dataを集める。
分析する。
Modelを改善する。
評価する。
承認する。
ControlledにDeployする。
このProcessを継続する。
高信頼AIでは、
Continuous Learning + Controlled Change
が必要になる。
⸻
社会実装がResearchを成熟させる
研究だけを続けていると、TheoryやBenchmarkには強くてもOperationへの理解が不足する場合がある。
社会実装によって、
実際に重要なMetric。
実際のFailure。
実際のHuman Behavior。
を知る。
そのKnowledgeがResearchを現実に強くする。
つまり社会実装はResearchの「後工程」ではなく、
Research Qualityを高めるInput
でもある。
⸻
Researchが社会実装を成熟させる
逆も成立する。
現場で見つかったProblemに場当たり的なPatchだけを当て続ければ、SystemがComplexになる。
Researchによって原因を一般化する。
より根本的なMethodを作る。
すると複数Problemを同時に解ける可能性がある。
つまり、
ResearchがImplementationを深くする。
両者は相互依存する。
⸻
ResearchとRealityの往復
この関係を最小化すると、
Research
↓
Prototype
↓
Production
↓
Reality
↓
Failure / Feedback
↓
Question
↓
Research
となる。
直線ではない。
循環である。
⸻
EQUESという会社の位置
本書の冒頭では、EQUESを研究と実務現場の架け橋として見た。
終章まで来ると、その意味をさらに具体化できる。
橋は、一方向にTechnologyを渡すだけではない。
社会のProblemを研究へ戻す。
つまりEQUESの役割は、
Bidirectional Research–Industry Interface
として理解できる。
⸻
大学発Startupのもう一つの意味
大学発Startupの価値は、大学の研究成果をCommercializeすることだけではない。
企業としてIndustryへ入り、そこで見つかったQuestionをResearch Ecosystemへ戻せることにある。
Academia → Startup → Industry
だけではなく、
Industry → Startup → Research
がある。
この往復が成立すると、大学と産業の距離そのものが縮まる。
⸻
社会がResearch Agendaの一部になる
ここで、研究と社会の関係が変わる。
研究が社会へ答えを与えるだけではない。
社会がResearchへQuestionを返す。
人材不足。
老朽Infrastructure。
製薬Quality。
危険環境でのOperation。
これらの社会ProblemがResearch Agendaを形成する。
つまり、
Research for Society
だけではなく、
Research informed by Society
である。
⸻
社会実装から研究へ戻る
本節を最小化すれば、
Implementation
↓
Use
↓
Observation
↓
Feedback
↓
Generalization
↓
Research Question
↓
Research
となる。
そしてResearch Resultを再びImplementationへ返す。
このLoopが閉じれば、企業はTechnologyを一度作って終わる会社ではなくなる。
学習し続ける研究開発組織になる。
⸻
EQUESが長期的に価値を持つとすれば、その理由は現在持っている特定のModelやProductだけにはない。
製薬で新しいProblemを知る。
Energyで別のConstraintを知る。
Physical AIで現実世界のFailureを知る。
Humanから使い方を学ぶ。
それをResearchへ戻す。
そして再びTechnologyとして社会へ返す。
この往復を続けられることにある。
研究から始まり、社会へ出る。
社会から学び、再び研究へ戻る。
そこまで来て初めて、「研究と社会をつなぐ会社」という本書の題名が完成する。
しかし企業そのものが完成するわけではない。
AIは変わる。
産業も変わる。
社会Problemも変わる。
研究の問いも変わる。
だから最後に残るのは、一つの完成形ではない。
変化し続ける能力そのものである。
次節では本書を閉じる。
2022年に生まれ、2026年まで拡張してきたEQUESを、未完成であることを弱点ではなく次の学習可能性として捉えながら、**「EQUESはまだ完成していない」**という地点へ進む。
第7節 EQUESはまだ完成していない
2022年2月1日に始まったEQUESを、ここまで追ってきた。
松尾研究室を起点とするAI研究。
若い研究者とEngineer。
伴走型技術開発。
PoCからProductionへの移行。
製薬AI。
QAI Generator。
QAI Checker。
JPharmatron-7B。
JPharmaBench。
Energy。
原子力・廃炉。
Physical AI。
Quantum Computing。
AI×DX寺子屋。
東京から北海道へ。
そして、受託開発からProductと共通基盤への可能性。
四年間という短い時間の中で、EQUESが扱う対象は大きく広がった。
だが、本書の最後に置くべき結論は、
「EQUESという企業モデルは完成した」
ではない。
むしろ逆である。
EQUESはまだ完成していない。
そして、その未完成性こそが、2026年のEQUESを理解するうえで重要なのである。
⸻
四年は企業史として短い
創業四年の企業に完成形を求めること自体が適切ではない。
Productは変わる。
Customerも変わる。
Technologyも変わる。
Organizationも変わる。
ましてAIは、数か月単位で前提Technologyそのものが更新される領域である。
2022年に合理的だったArchitectureが、2026年には最適ではないこともある。
したがってEQUESを見るとき、現在の事業Portfolioを固定的な企業像として捉えるべきではない。
⸻
2026年は答えではなく現在地である
製薬AIへ進んだ。
Energyへ広がった。
Physical AIへ接続した。
Quantum Computingも研究する。
しかし、これらすべてが将来同じ規模の事業になるとは限らない。
どれかが大きく成長するかもしれない。
統合されるかもしれない。
縮小される領域もあるかもしれない。
つまり2026年は、
Final Portfolio
ではなく、
Current State
である。
⸻
Startupは仮説の集合でもある
若い企業の事業は、確定した答えというより複数のHypothesisとして見ることができる。
製薬でVertical AIは成立するか。
高信頼AIは差別化になるか。
Physical AIへResearch Capabilityを拡張できるか。
受託KnowledgeをProductへ変換できるか。
研究力をScale可能な企業能力へ変えられるか。
EQUESという会社そのものが、これらのHypothesisを検証している。
⸻
未完成とは弱いという意味ではない
未完成という言葉は、能力不足を意味しない。
むしろStartupでは、
まだ変われること
を意味する。
巨大Organizationになるほど、既存Business、Process、Technology、評価制度が企業の方向を固定する。
若い企業には、その固定がまだ少ない。
新しいTechnologyへ移れる。
新しいDomainへ入れる。
Organizationを作り直せる。
つまり未完成性は、
Strategic Plasticity
でもある。
⸻
ただし、何でもできるわけではない
柔軟性と無制限な多角化は違う。
製薬。
Energy。
Physical AI。
Quantum。
Education。
すべてを同時に最大化することは難しい。
Capital。
Talent。
Management Attention。
時間。
すべて有限だからである。
したがって次の段階では、
Possibilityを増やすこと
から、
Possibilityを選ぶこと
へ進まなければならない。
⸻
選択が企業Identityを作る
創業初期には、「何ができるか」が重要だった。
次には、
「何をしないか」
も重要になる。
どのDomainをCoreにするのか。
どのResearchを長期Optionとして残すのか。
どのProjectを断るのか。
どのProductへ集中するのか。
企業Identityは、追加したものだけでなく、選ばなかったものによっても形成される。
⸻
製薬はCoreになるのか
製薬ではすでに、
Product。
Domain Model。
Benchmark。
という複数のAssetが形成されている。
これはEQUESの中でも比較的深いVerticalである。
今後、
製薬AIをさらに深く掘るのか。
他のLife Science領域へ広げるのか。
高信頼AIのReference Domainとして利用するのか。
選択肢がある。
2026年時点では、その未来を一つへ固定する必要はない。
⸻
Energyは第二の柱になるのか
Energyでは、Digital AIだけでは扱えなかったPhysical Constraintへ接続する。
設備。
Sensor。
Infrastructure。
Remote Operation。
この領域を深めれば、EQUESはSoftware AI CompanyからIndustrial AI Companyへ大きく変化する可能性がある。
しかしPhysical領域には、異なるTalent、Partner、Capitalが必要になる。
可能性と同時に、実装Costも大きい。
⸻
Physical AIは境界である
Physical AIは、単なる新規事業の一つではない。
AIのOutputが現実のActionへ変わる境界である。
ここを越えるなら、
Safety Engineering。
Robotics。
Control。
Edge。
Hardware。
Human Factors。
まで企業能力を広げなければならない。
それはEQUESのCompany Architectureそのものを変える可能性がある。
⸻
Quantumは時間軸が違う
Quantum Computingはさらに異なる。
短期Productと同じ速度で評価すべきではない。
技術成熟度も市場形成も異なる。
だからこそ、
現在Revenueを作るBusiness。
中期でScaleを狙うProduct。
長期的なResearch Option。
を分離する必要がある。
未完成な企業には、複数の時間が同時に流れている。
⸻
受託はなくなるのか
Product化が進んだからといって、受託開発が不要になるとは限らない。
新しいProblemは、Customerとの共同開発から見つかる。
未知のDomainへ入る。
新Technologyを試す。
まだProduct化できないProblemを理解する。
受託を、
Revenue Model
だけではなく、
Exploration Function
として再定義できる。
⸻
Productは完成するのか
Productも完成しない。
Customerが使う。
新しいFailureが見つかる。
Requirementが変わる。
Modelが更新される。
Regulationも変わる。
したがってAI Productは、
Release → Use → Evaluate → Update
を続ける。
完成品というより、継続的に更新されるSystemになる。
⸻
Modelも完成しない
Foundation Modelの進化速度を考えれば、特定Modelを企業の最終形にすることは難しい。
今日のBest Modelが明日もBestとは限らない。
だからこそ、
Modelを選ぶ。
評価する。
交換する。
組み合わせる。
能力が重要になる。
企業の強さを、単一Modelへ固定しない。
⸻
Benchmarkも完成しない
Evaluation Setも更新されなければならない。
新しいFailureが見つかる。
新しいTaskが増える。
ModelがBenchmarkへ最適化される。
すると新しいTestが必要になる。
つまり、
Evaluation evolves with AI.
JPharmaBenchのような評価資産も、固定された答えではなく継続的な測定系として価値を持つ。
⸻
高信頼AIにも終点はない
Trustも一度認証すれば完成するものではない。
Modelが変わる。
Threatが変わる。
User Behaviorが変わる。
AI Agentが新しいActionを持つ。
Physical AIが新しいMachineへ接続する。
そのたびにRiskを再評価する。
したがって、
Trust is continuously maintained.
高信頼とは状態ではなくProcessでもある。
⸻
Human–AI関係も変わる
AI性能が向上すれば、Humanの役割も変わる。
最初はすべてReviewする。
次にExceptionだけを見る。
さらに一部TaskはAIへ委任する。
しかしCritical ActionではHumanを残す。
つまりHuman–AI Architectureも固定ではない。
Capabilityに応じてAutonomy Boundaryを更新する。
⸻
Organizationも更新される
Company Architectureも同じである。
創業者がすべてを見る段階。
Team Leaderが生まれる段階。
Product Teamが独立する段階。
Shared Platformが必要になる段階。
企業規模によって最適Structureは変わる。
初期の強さを維持しながら、Organizationを更新できるかが問われる。
⸻
少数精鋭の次
少数精鋭は創業期の強みになる。
Communicationが速い。
Talent Densityが高い。
Decisionが速い。
しかし事業が増えれば、個人依存がRiskになる。
そこで、
Knowledge。
Code。
Evaluation。
Decision。
をOrganizationへ残す。
Talent Density + Institutional Memory
へ進む必要がある。
⸻
創業者の会社から組織の会社へ
Startupが成長すると、FounderのKnowledgeだけでは運営できなくなる。
Visionを共有する。
Technical Principleを共有する。
Decision Ruleを共有する。
新しく入った人でも高Qualityな判断ができるようにする。
これは企業が「個人の集合」から「System」へ変わる過程である。
⸻
EQUES自身をAI-nativeにできるか
EQUESが顧客へAIを実装するなら、自社のOrganizationもAIによって変えられる。
Research Search。
Coding。
Documentation。
Evaluation。
Knowledge Retrieval。
Project Learning。
これらをAIで支援する。
するとCompany Memoryをより広く利用できる。
少人数でも多くのKnowledgeを扱える。
⸻
AI-nativeでもHumanは中心に残る
ただしAI-native Companyとは、人間を減らす会社ではない。
Humanが、
Research。
Architecture。
Domain Judgment。
Customer Relationship。
Ethical Decision。
へ集中できるようにする会社である。
AIを使ってHuman Capabilityを増幅する。
これはEQUESが顧客へ提供してきた思想を、自社へ適用することでもある。
⸻
東京と北海道も未完成である
地域展開も、拠点を設置した時点で完成ではない。
どのTalentが集まるのか。
どのUniversityとつながるのか。
どのIndustry Problemが見つかるのか。
東京と北海道の間でKnowledgeがどう循環するのか。
これから企業Networkとしての意味が決まっていく。
⸻
Partnership Networkも会社の一部になる
Physical AIやQuantumのような領域では、一社ですべてを保有する必要はない。
University。
Research Institute。
Large Enterprise。
Robot Company。
Cloud Provider。
Regional Partner。
外部Capabilityを接続する。
すると企業Boundaryは法人の内側だけではなくなる。
Company + Network
として競争力を形成する。
⸻
企業規模よりLearning Network
研究開発型企業では、従業員数だけで能力を測れない。
どれだけ高度なResearchへAccessできるか。
どれだけDomain Expertと接続しているか。
どれだけCustomerから学べるか。
どれだけPartner Capabilityを統合できるか。
つまり、
Organizational Scale
だけでなく、
Learning Network Scale
が重要になる。
⸻
大学との関係も変化する
松尾研を出発点としたとしても、企業が成長すれば独自のResearch Identityが必要になる。
大学との接続を保持する。
同時に、自社でResearch Agendaを持つ。
他大学や研究機関とも連携する。
つまり、
Originを保持しながらOriginを越える。
大学発Startupが成熟するとは、そのような状態でもある。
⸻
「松尾研発」の次
創業期には「松尾研発」というOriginが大きな意味を持つ。
しかし長期的には、
「EQUESだからできる」
という独自性が必要になる。
Product。
Domain Knowledge。
Research Method。
Evaluation。
High-reliability Engineering。
Physical AI。
Organization Culture。
これらの組み合わせがEQUES固有のCapabilityになっていく。
⸻
研究成果ではなく研究能力を残す
一つの研究成果は古くなる。
一つのModelも古くなる。
しかし、
Questionを立てる。
Experimentする。
Evaluateする。
Failureから学ぶ。
新しいMethodを作る。
というResearch Capabilityは残る。
EQUESが守るべきOriginは、特定Technologyではなくこの能力である。
⸻
社会実装能力も固定しない
同様に、社会実装とは特定CloudやFrameworkを使えることではない。
Customer Problemを理解する。
Requirementへ翻訳する。
Productionへ移す。
Humanへ定着させる。
Operationから学ぶ。
この能力もTechnologyから独立した企業資産になる。
⸻
二つの能力を接続する
ここで本書全体の核心へ戻る。
一方に、
Research Capability
がある。
もう一方に、
Implementation Capability
がある。
EQUESの価値は、どちらか片方だけではない。
両者を往復できることにある。
Research ⇄ Implementation
である。
⸻
その間に産業がある
しかし実際の往復は直接ではない。
Domain。
Customer。
Human。
Organization。
Regulation。
Physical Environment。
が間にある。
したがって完全な構造は、
Research
⇄ Technology
⇄ Industry
⇄ Human
⇄ Reality
となる。
そしてRealityから得たFeedbackがResearchへ戻る。
⸻
会社そのものがLoopになる
ここまで来ると、EQUESをProduct Portfolioとしてだけ見る必要はなくなる。
会社そのものが、
観測する。
研究する。
翻訳する。
実装する。
評価する。
学習する。
というLoopになる。
つまり、企業は固定された資産の集合ではなく、
Learning System
として理解できる。
⸻
完成しないことが条件になる
AIが変化し続ける以上、AI Companyが完全に完成することはない。
完成したArchitectureに固執すれば、新Technologyへ適応できない。
完成したBusiness Modelに固執すれば、新しいMarketを見失う。
完成したOrganizationに固執すれば、人材と事業の変化へ対応できない。
だから必要なのは、
完成ではなく更新可能性
である。
⸻
ただし変わらないCoreは必要である
何もかも変え続ければ、企業Identityは消える。
そこで、
変えるもの。
変えないもの。
を分ける。
Modelは変える。
Productは変える。
Domain Portfolioも変え得る。
しかし、
Researchを重視する。
Realityから学ぶ。
高いTechnical Qualityを求める。
Technologyを社会へ実装する。
というCore Principleは保持する。
⸻
Stable Core, Adaptive Edge
この企業像を最小化すれば、
Stable Core + Adaptive Edge
である。
Coreには、
Research。
Engineering。
Evaluation。
Trust。
Learning。
を置く。
Edgeには、
Model。
Product。
Domain。
Market。
Technology Stack。
を置く。
外側は変化する。
中心は蓄積する。
⸻
2022年から2026年へ
2022年のEQUESは、研究から企業へ出た。
2026年のEQUESは、企業から複数の産業へ入っている。
製薬。
Energy。
Physical World。
Human Organization。
境界を越えるたびに、新しいKnowledgeを得た。
そのKnowledgeが次のEQUESを作る。
⸻
2026年から先へ
ここから先を確定的に書くことはできない。
どのProductが最大になるか。
どのResearchがBreakthroughになるか。
どのIndustryが主要市場になるか。
それはまだ分からない。
しかし、現在までの構造から一つだけ言える。
EQUESの次の価値は、
未来を正確に予測すること
より、
未来が変化したときに学習し直せること
から生まれる可能性が高い。
⸻
EQUESはまだ完成していない
だから、この一冊は完成した企業の成功物語ではない。
2022年から2026年までに、
一つのResearch-origin Startupが、
どのようにIndustryへ入り、
どのようにDomain Knowledgeを獲得し、
どのようにProductを作り、
どのようにPhysical Worldへ近づき、
どのようにHumanとOrganizationまで扱うようになったか。
その形成過程を記述した本である。
⸻
本書の問いへの答え
序章では問うた。
研究はどのように産業になるのか。
その答えを一行で書くなら、
研究成果を市場へ「移す」だけではない。
研究と社会の間に継続的な往復を作ることで、研究は産業能力になる。
ということである。
⸻
研究する。
現場へ持っていく。
失敗する。
学ぶ。
評価する。
改善する。
Productにする。
別の産業へ翻訳する。
Humanへ接続する。
Physical Worldへ接続する。
そして再びResearchへ戻る。
その循環が続く限り、EQUESは変化し続ける。
だから本書の最後に置くべき言葉は、「完成」ではない。
EQUESはまだ完成していない。
研究も終わっていない。
AIも終わっていない。
社会実装も終わっていない。
製薬、Energy、Physical AI、Quantumの先に、まだ解かれていないProblemがある。
そのProblemが次のResearchを生み、
Researchが次のTechnologyを生み、
Technologyが次の社会実装へ進む。
EQUESという会社の本質が、その往復にあるのだとすれば、未完成であることは欠落ではない。
それは、
次の研究を始められる状態である。
そして次の研究が始まるたびに、研究と社会をつなぐ会社もまた、もう一度つくられていく。
愛と敬意を込めてmandala
