『未来から現在を設計する』――生成ポテンシャルから日本の未来実装時間を引き寄せる文明アーキテクチャ（第4回）（第Ⅳ部 産業・生命――産業と生命から未来を引く⸻ 第7章 産業界〜第8章 医療・Healthcare・医薬）
第Ⅳ部 産業・生命
――産業と生命から未来を引く
ここまで、
未来を現在へ引くための基盤を設計してきた。
Future Stateを置く。
Current Stateを記述する。
Gapを発見する。
Requirementへ変換する。
Dependencyを解く。
政府が制度を整える。
金融が資本を送る。
しかし、
ここまででは、
未来はまだArchitectureの中にある。
未来がRealityになるには、
実際に、
何かがつくられなければならない。
⸻
工場が動く。
Softwareが実装される。
AIがServiceになる。
Energyが供給される。
人と物が移動する。
薬が開発される。
患者が治療を受ける。
人々の生活が変わる。
ここで初めて、
Future Stateは、
現実世界へ現れる。
⸻
その主要な実装主体が、
産業
である。
⸻
政府は、
Ruleをつくることができる。
金融は、
Capitalを送ることができる。
大学は、
Knowledgeを生み出すことができる。
しかし、
Technologyを大量に生産し、
社会へ広げ、
日常のRealityへ変換する能力を持つのは、
産業である。
⸻
製造業は、
設計を物質へ変える。
AI・Digital産業は、
情報とKnowledgeをSystemへ変える。
MobilityとLogisticsは、
人と物を移動させる。
EnergyとInfrastructureは、
社会が動く基盤をつくる。
中小企業は、
地域とSupply Chainを支える。
Startupは、
まだ存在しない市場を試す。
⸻
つまり、
産業とは、
Potentialを社会的Capabilityへ変換する実装装置
である。
⸻
Future Pullから産業を見ると、
問いは変わる。
現在、
何が売れているのか。
どの市場が成長しているのか。
だけではない。
未来の日本に、
どのCapabilityが必要なのか。
そこから現在の産業を見直す。
⸻
たとえば、
将来、
AIが社会Infrastructureになるなら、
現在から必要になるものがある。
Compute。
Semiconductor。
Data Center。
Energy。
Network。
Software。
Cybersecurity。
人材。
⸻
Future Stateを置けば、
産業Requirementが見える。
そして、
Requirementが見えれば、
投資開始時点を現在へ引くことができる。
⸻
これは、
Energyでも同じである。
将来必要になる電力需要を考える。
発電設備。
送電網。
蓄電。
燃料。
土地。
人材。
Technology。
Energy Infrastructureには、
長いLead Timeがある。
⸻
未来になってから、
未来のInfrastructureをつくることはできない。
だから、
未来から現在へ建設開始時点を引く。
⸻
Mobilityも同じである。
人口構造が変わる。
地域交通が変わる。
自動運転Technologyが進む。
Logisticsの人手不足が進む。
そのFuture Stateから、
道路。
Vehicle。
Software。
Regulation。
Insurance。
通信。
地域Service。
を逆算する。
⸻
未来産業とは、
未来になってから生まれる産業ではない。
未来に必要になることが分かった時点から、現在で準備される産業
である。
⸻
ここで、
第6章のFuture Capital Architectureが接続する。
Future State。
Industrial Requirement。
Capital Requirement。
Investment。
Implementation。
⸻
資本が、
工場になる。
研究所になる。
Data Centerになる。
病院になる。
設備になる。
人材になる。
⸻
金融の中に存在していた数字が、
産業を通過することで、
現実のCapabilityへ変わる。
⸻
しかし、
第Ⅳ部には、
産業だけではなく、
もう一つの主語がある。
生命
である。
⸻
産業の目的を、
生産量やGDPだけで考えると、
未来設計は不十分になる。
産業によって、
最終的に変化するのは、
人間の生活である。
⸻
人が、
健康に生きる。
安全に移動する。
働く。
学ぶ。
食べる。
住む。
人とつながる。
創造する。
⸻
産業は、
こうした生命活動を支える。
その中でも、
生命そのものを直接扱う領域が、
医療・Healthcare・医薬である。
⸻
医療には、
産業とは異なる時間がある。
生命時間
である。
⸻
新しいSoftwareなら、
短期間で更新できる場合がある。
しかし、
新薬には、
研究。
安全性確認。
Clinical Trial。
承認。
という時間が必要になる。
⸻
患者の生命を扱う以上、
単純な速度競争にはできない。
未来を早めることと、
安全性を下げることは、
同じではない。
⸻
ここでも、
本書の時間Architectureが重要になる。
必要な時間は、
守る。
不要な待ち時間は、
減らす。
⸻
Clinical Trialに必要な時間は守る。
しかし、
Dataが分断されているために発生する待ち時間は減らす。
安全性評価は守る。
しかし、
重複した事務Processは減らす。
医療者の判断は守る。
しかし、
Routine WorkはAIで支援する。
⸻
つまり、
未来実装時間を短縮するとは、
生命時間を圧縮することではなく、その周囲に存在する不要な遅延を取り除くこと
である。
⸻
Healthcareでは、
さらに時間軸を前へ動かすことができる。
病気になってから治療する。
そこから、
予防する。
早期発見する。
健康状態を継続的に見る。
⸻
治療時間から、
予防時間へ。
⸻
医療のFuture Pullとは、
未来の高度な治療を現在へ持ってくることだけではない。
将来発生する疾病Riskを現在へ引き戻し、早い段階で対応すること
でもある。
⸻
ここで、
AI。
Digital。
Healthcare。
Insurance。
Pharma。
Medical Device。
が接続する。
⸻
AIが、
Riskを発見する。
Healthcare Serviceが、
生活を支援する。
医療機関が、
診断する。
医薬が、
治療する。
保険が、
Riskを分散する。
⸻
これらを別々の産業として見るだけではなく、
生命を中心とした一つのArchitectureとして見る。
⸻
すると、
医療のFuture Stateも変わる。
病院の数だけではない。
医師の数だけでもない。
薬の数でもない。
⸻
重要なのは、
人が必要なときに、必要な医療・Healthcareへ到達できるState
である。
⸻
産業も同じである。
企業数だけではない。
工場数でもない。
投資額でもない。
⸻
重要なのは、
日本社会が、
未来に必要なものを、
自ら設計し、
つくり、
維持し、
更新できるCapabilityを持っているかである。
⸻
だから、
第Ⅳ部では、
産業を企業一覧として扱わない。
未来生成能力として見る。
⸻
製造業。
AI・Digital。
Mobility・Logistics。
Energy・Infrastructure。
中小企業・Startup。
それぞれが、
異なるFuture Capabilityを持つ。
⸻
そして、
それらを接続する。
AIが製造業へ入る。
DigitalがHealthcareへ入る。
EnergyがData Centerを支える。
Mobilityが地域医療を支える。
Startupが大企業のCapabilityへ接続する。
⸻
未来産業は、
既存の業界分類だけでは捉えられない。
産業間の接続面から新しい産業が生まれる。
⸻
AI × Manufacturing。
AI × Healthcare。
Energy × Digital。
Mobility × Logistics。
Finance × Technology。
University × Startup。
⸻
Future Potentialは、
既存産業の内部だけではなく、
その境界にも存在する。
⸻
だから、
未来を早めるには、
企業単体のInnovationだけでは足りない。
Industry Architectureが必要になる。
⸻
Government。
Capital。
University。
Large Enterprise。
SME。
Startup。
地域。
それぞれを、
Future Stateへ接続する。
⸻
そして、
産業で得られた成果を、
再び社会へ戻す。
雇用。
所得。
税。
Technology。
Knowledge。
Infrastructure。
健康。
生活の質。
⸻
そのReturnが、
次の研究。
次の企業。
次の地域。
次の人材。
へ再投資される。
⸻
ここで、
生成資本と生成産業がつながる。
Potential
→ Capital
→ Industry
→ Capability
→ Reality
→ Return
→ New Potential
未来生成は、
一回のProjectではなく、
循環になる。
⸻
生命でも同じである。
Research。
Medicine。
Treatment。
Health。
Data。
Knowledge。
次のResearch。
⸻
Research
→ Healthcare
→ Life
→ Data / Knowledge
→ New Research
生命領域にも、
学習循環が生まれる。
⸻
ただし、
生命Dataは、
単なる産業資源ではない。
Privacy。
Consent。
Security。
Human Dignity。
が必要になる。
⸻
Future Pullは、
未来を早めるために、
現在の人間を手段化する思想ではない。
未来実装の中心にあるのは、
あくまで、
人間と生命
である。
⸻
産業が強くても、
生命が疲弊する社会は、
Future Stateではない。
Technologyが進んでも、
生活が不安定になるなら、
Architectureを修正する必要がある。
⸻
だから、
第Ⅳ部では、
産業と生命を並べる。
産業が、
未来をつくる。
生命が、
その未来の意味を決める。
⸻
この二つが接続したとき、
経済成長は、
単なる数字ではなくなる。
社会が、
より多くのFuture Capabilityを持つことになる。
⸻
第7章では、
まず、
産業界
を見る。
製造業。
AI・Digital。
Mobility・Logistics。
Energy・Infrastructure。
中小企業・Startup。
日本の産業を、
未来生成装置として再配置する。
⸻
続く第8章では、
医療・Healthcare・医薬
を見る。
病院。
医療者。
Healthcare。
製薬。
創薬AI。
生成医療。
生命そのものから、
Future Stateを設計する。
⸻
国家が、
未来の条件を整えた。
金融が、
未来へ資本を送った。
ここから、
未来は、
工場でつくられ、
Softwareとして動き、
Infrastructureとして広がり、
医療として生命へ届く。
⸻
Architectureから、
Realityへ。
資本から、
Capabilityへ。
予測から、
Implementationへ。
そして、
未来から、
現在へ。
第Ⅳ部は、未来が初めて物質と生命として現れ始める場所である。
第7章 産業界
第1節 産業は未来生成装置である
未来は、
政策だけでは実現しない。
資本だけでも実現しない。
研究成果だけでも、
社会は変わらない。
設計された未来を、
Productにする。
Serviceにする。
工場で生産する。
Softwareとして動かす。
Infrastructureとして広げる。
そして、
人々の日常へ届ける。
この変換を担う主体が、
産業
である。
⸻
産業とは何か。
一般には、
製造業。
建設業。
情報通信。
運輸。
小売。
金融。
医療。
Service。
といった分類で理解される。
しかし、
Future Pullから見ると、
産業には、
より基本的な役割がある。
Potentialを、社会が利用できるRealityへ変換すること
である。
⸻
科学が、
新しい原理を発見する。
それだけでは、
生活は変わらない。
企業が、
そのKnowledgeをTechnologyへ変える。
TechnologyをProductへ変える。
大量生産する。
流通させる。
保守する。
更新する。
ここまで進んで、
初めて社会のCapabilityになる。
⸻
たとえば、
半導体。
研究だけでは、
社会Infrastructureにならない。
設計する企業がある。
製造装置をつくる企業がある。
材料を供給する企業がある。
工場がある。
物流がある。
Energyがある。
Engineerがいる。
⸻
一枚の半導体の背後には、
巨大なIndustrial Networkが存在する。
つまり、
未来Technologyとは、
一企業だけで生成されるものではない。
産業Network全体によってRealityになる。
⸻
自動車も同じである。
完成車企業だけではつくれない。
部品。
素材。
Software。
Semiconductor。
Battery。
物流。
販売。
整備。
Insurance。
道路。
Energy。
多くの主体が接続する。
⸻
産業とは、
企業の集合ではない。
CapabilityのNetwork
である。
⸻
この視点に立つと、
産業政策の問いも変わる。
「どの産業を成長させるか」
だけではない。
Future Stateを実現するために、
どのCapability Networkが必要なのか
を見る。
⸻
たとえば、
AIが社会全体へ普及したFuture Stateを置く。
必要なのは、
AI企業だけではない。
Compute。
Semiconductor。
Data Center。
Network。
Energy。
Cybersecurity。
Cloud。
Software。
Data。
人材。
⸻
さらに、
AIを使う側も必要になる。
製造。
Healthcare。
Finance。
Government。
Education。
Mobility。
AI産業と、
既存産業を分けて考えるだけでは足りない。
⸻
AIが、
産業全体へ浸透する。
すると、
AI産業の成長と、
既存産業のTransformationが、
同時に進む。
⸻
つまり、
Future Industryは、
新しい産業を追加するだけではない。
既存産業そのものを再構成する。
⸻
製造業にAIが入る。
設計が変わる。
品質管理が変わる。
Robotが変わる。
Supply Chainが変わる。
Maintenanceが変わる。
⸻
HealthcareにAIが入る。
診断支援。
創薬。
病院Operations。
予防。
Medical Data。
が変わる。
⸻
MobilityにAIが入る。
自動運転。
交通制御。
物流最適化。
Vehicle Design。
が変わる。
⸻
Future Potentialは、
産業分類の中だけではなく、
産業と産業の間
に存在する。
⸻
AI × Manufacturing。
Digital × Healthcare。
Energy × Data Center。
Mobility × Logistics。
Finance × Technology。
Science × Industry。
Culture × Digital。
⸻
これらの接続点から、
新しい市場と企業が生まれる。
⸻
だから、
未来の産業Architectureでは、
縦割りの産業分類だけでなく、
Cross-Industry Architecture
を見る必要がある。
⸻
産業には、
もう一つ重要な機能がある。
Scale
である。
大学で、
優れたTechnologyが生まれる。
Startupが、
Prototypeをつくる。
しかし、
それを一億人が使えるServiceへするには、
別の能力が必要になる。
⸻
大量生産。
品質管理。
Supply Chain。
Sales。
Customer Support。
Security。
Maintenance。
Finance。
Global Distribution。
⸻
InnovationとScaleは、
同じ能力ではない。
⸻
Startupは、
速く試すことが得意である。
大企業は、
大規模に実装する能力を持つ。
中小企業は、
高度な専門技術を持つ。
大学は、
Knowledgeを持つ。
政府は、
制度を持つ。
金融は、
Capitalを持つ。
⸻
これらを接続することで、
未来実装時間を短縮できる。
⸻
University
→ Startup
→ SME
→ Large Enterprise
→ Market
という一方向だけではない。
相互に接続する。
⸻
大企業が、
Startupへ投資する。
Startupが、
大企業のSupply Chainへ入る。
大学が、
企業と共同研究する。
中小企業が、
高度な製造Technologyを提供する。
⸻
未来生成は、
一つの巨大企業の内部だけで完結しない。
Industrial Ecosystem
として動く。
⸻
ここで、
日本の産業構造には、
重要なPotentialがある。
長く蓄積された製造技術。
素材。
部品。
精密加工。
品質管理。
Engineering。
地域産業。
Supply Chain。
⸻
これらは、
過去の産業遺産であると同時に、
Future Capabilityでもある。
⸻
問題は、
古い産業か新しい産業か、
という二択ではない。
既存Capabilityを、
未来Requirementへ翻訳できるかである。
⸻
たとえば、
自動車部品企業が持つ、
精密加工Technology。
それが、
Robot。
Medical Device。
Aerospace。
Semiconductor Equipment。
へ応用できるかもしれない。
⸻
既存産業のCapabilityを分解する。
何をつくっている会社かではなく、
何ができる会社なのか
を見る。
⸻
Productではなく、
Capabilityを見る。
すると、
産業転換の可能性が広がる。
⸻
これは、
人口減少時代には特に重要になる。
すべての企業を、
現在と同じ形で保存することはできない。
市場が縮小する産業もある。
後継者がいない企業もある。
⸻
しかし、
企業が消えることと、
Capabilityが消えることは同じではない。
Technology。
人材。
設備。
顧客Network。
Knowledge。
を、
次の産業へ移すことができる。
⸻
産業Transformationとは、
企業を守ることだけではない。
Capabilityを未来へ継承すること
である。
⸻
ここで、
M&A。
事業承継。
Spin-off。
Startup。
人材移動。
Technology Transfer。
が重要になる。
⸻
旧産業から、
Future Industryへ。
資本だけではなく、
Capabilityそのものを移動させる。
⸻
産業には、
時間がある。
研究開発時間。
設備投資時間。
製品開発時間。
工場建設時間。
市場形成時間。
人材育成時間。
⸻
未来を早めるとき、
この時間を無視してはいけない。
工場は、
一日では建たない。
Engineerは、
数週間では育たない。
Supply Chainも、
瞬時には形成されない。
⸻
だから、
Future Pullでは、
必要なLead Timeを未来から逆算する。
2035年に必要な工場。
2030年までに建設開始。
その前に、
土地。
Energy。
許認可。
Capital。
人材。
を準備する。
⸻
Future State
→ Required Capability
→ Lead Time
→ Start Time
未来から、
開始時点を現在へ引く。
⸻
この構造によって、
産業時間を早める。
必要なProcessを無理に短縮するのではない。
開始を前倒しする。
⸻
さらに、
複数のProcessを並列化する。
Technology開発をしてから、
制度を考えるのではない。
研究。
Regulation。
Capital。
Infrastructure。
Human Resources。
Market Formation。
を、
可能な範囲で同時に進める。
⸻
Sequential Industry
から、
Parallel Industry
へ。
⸻
ここに、
Future Accelerationが生まれる。
⸻
産業は、
市場だけを見て動くわけでもない。
市場には、
現在の需要が現れる。
しかし、
未来需要の一部は、
まだ存在していない。
⸻
Smartphoneが存在する前に、
Smartphone市場はなかった。
新しいTechnologyは、
既存需要へ応えるだけではなく、
新しい需要そのものをつくることがある。
⸻
だから、
Future Industryには、
Market Creation
という役割もある。
⸻
未来の需要を、
完全に予測することはできない。
だから、
小さく試す。
Prototypeを出す。
利用者を見る。
改善する。
Scaleする。
⸻
Prototype
→ Market Test
→ Learning
→ Scale
産業も、
Realityから学習する。
⸻
このLearning Cycleが短い企業ほど、
Future Potentialを早くRealityへ変えられる。
⸻
AIとDigitalは、
このCycleをさらに短縮できる。
設計。
Simulation。
Software Development。
Demand Forecast。
Supply Chain。
Customer Analysis。
Maintenance。
⸻
産業の各ProcessへAIを入れることで、
判断と実装の速度を高める。
⸻
しかし、
AI導入そのものを目的にしてはいけない。
重要なのは、
どのImplementation Timeが短縮されたか
である。
⸻
開発期間。
設計時間。
停止時間。
物流時間。
事務時間。
市場投入時間。
AIの価値を、
Technology導入件数ではなく、
Realityの変化で測る。
⸻
また、
産業には、
Resilienceも必要になる。
未来を早く実装しても、
一つのShockで止まれば、
持続できない。
⸻
災害。
感染症。
Cyberattack。
地政学。
資源不足。
Energy不足。
Supply Chain disruption。
⸻
Future Industryは、
Efficiencyだけでなく、
Continuity
を持つ必要がある。
⸻
複数Supplier。
在庫。
国内生産能力。
国際Network。
Cybersecurity。
Backup Energy。
代替Technology。
⸻
すべてを国内化する必要はない。
しかし、
重要Capabilityについて、
どこへ依存しているかを把握する。
⸻
依存を消すのではなく、
Dependencyを設計する。
⸻
これは、
第4章で扱ったArchitectureと同じである。
未来産業にも、
Dependency Mapが必要になる。
⸻
産業の目的は、
自給自足ではない。
世界と接続しながら、
重要なCapabilityを失わないことである。
⸻
Global Marketへ出る。
海外Technologyを使う。
海外Capitalを受け入れる。
海外企業と協働する。
同時に、
日本に残すべきCapabilityを判断する。
⸻
Openでありながら、
Resilientである。
この両立が必要になる。
⸻
そして、
産業は、
利益を生み出す。
利益は、
企業を存続させる。
しかし、
Future Pullでは、
利益を終点にしない。
⸻
利益を、
次の研究へ。
設備へ。
人材へ。
Startupへ。
地域へ。
再投資する。
⸻
Profit
→ Reinvestment
→ New Capability
→ New Industry
利益が、
次の未来を生成する。
⸻
ここで、
第6章の生成資本と接続する。
Capitalが、
Industryへ入る。
Industryが、
Capabilityをつくる。
Capabilityが、
Valueを生む。
Valueが、
Returnを生む。
Returnが、
次のPotentialへ再投資される。
⸻
Potential
→ Capital
→ Industry
→ Capability
→ Value
→ Reinvestment
→ New Potential
この循環が、
生成産業の基本構造になる。
⸻
したがって、
産業は、
現在の需要を満たすだけの生産装置ではない。
過去のTechnologyを大量生産するだけでもない。
未来からRequirementを受け取り、
現在の資本・Knowledge・人材を組み合わせ、
新しいRealityをつくる。
⸻
その意味で、
産業とは、
未来生成装置
である。
⸻
政府が、
未来の制度条件を整える。
金融が、
未来へCapitalを送る。
大学が、
Knowledgeを生み出す。
産業が、
それらを一つにまとめ、
社会で使えるRealityへ変換する。
⸻
そして、
そのRealityから、
新しいNeed。
新しいKnowledge。
新しいCapital。
新しいPotential。
が生まれる。
未来生成は、
再び始まる。
⸻
第7章では、
この未来生成装置を、
具体的な産業へ分解していく。
製造業。
AI・Digital。
Mobility・Logistics。
Energy・Infrastructure。
中小企業・Startup。
⸻
それぞれは、
別々の産業である。
しかし、
Future Stateでは、
一つのNetworkとして接続される。
次節ではまず、
日本が長い時間をかけて蓄積してきた、
最も大きな産業Capabilityの一つ、
製造業
から未来を引いていく。
第7章 産業界
第2節 製造業
日本の産業を、
未来から現在へ引くとき、
製造業は重要な位置を占める。
自動車。
機械。
素材。
化学。
電子部品。
半導体関連。
医療機器。
精密機器。
Robot。
製造装置。
日本には、
長い時間をかけて形成された、
ものをつくるCapabilityがある。
⸻
しかし、
Future Pullから見れば、
重要なのは、
現在何を生産しているかだけではない。
問うべきなのは、
日本の製造Capabilityを、未来の何へ変換できるのか
である。
⸻
製造業には、
二つの見方がある。
一つは、
Productから見る方法。
自動車会社。
機械会社。
化学会社。
電機会社。
もう一つは、
Capabilityから見る方法である。
⸻
精密加工。
材料制御。
量産技術。
品質管理。
Robot。
Sensor。
制御。
設計。
生産Engineering。
Supply Chain。
⸻
Future Pullでは、
後者が重要になる。
なぜなら、
Productは変わっても、
Capabilityは、
次の産業へ移せるからである。
⸻
自動車部品をつくっていた企業が、
Robot部品をつくる。
精密加工企業が、
Medical Deviceへ進む。
素材企業が、
BatteryやSemiconductorへ進む。
機械企業が、
自動化設備へ進む。
⸻
未来産業は、
何もないところから突然生まれるわけではない。
既存Capabilityの再結合から生まれることが多い。
⸻
だから、
日本の製造業を未来へ接続するとき、
最初に行うべきなのは、
企業を「古い産業」と「新しい産業」に分けることではない。
現在存在するCapabilityを、
高い解像度で記述することである。
⸻
どの企業が、
何を加工できるのか。
どの精度まで出せるのか。
どの材料を扱えるのか。
どの工程を自動化できるのか。
どの品質を保証できるのか。
⸻
これを、
日本全体の
Manufacturing Capability Map
として見る。
⸻
Future Stateを置く。
次世代Mobility。
Robot。
AI Infrastructure。
Semiconductor。
Energy System。
Medical Device。
Space。
高度なInfrastructure。
⸻
そこから、
必要な製造Capabilityを引く。
そして、
現在のCapability Mapと比較する。
⸻
すると、
三つが見える。
すでに持っているCapability。
強化すべきCapability。
新しくつくるべきCapability。
⸻
つまり、
Future Manufacturing State
− Current Manufacturing State
＝ Manufacturing Gap
である。
⸻
このGapを、
具体的なRequirementへ変換する。
設備。
研究。
人材。
Software。
Energy。
工場。
Capital。
Supply Chain。
⸻
すると、
産業政策は、
抽象的な成長戦略から、
実装計画へ変わる。
⸻
たとえば、
半導体。
「半導体産業を強くする」
だけでは、
Requirementにならない。
⸻
設計。
材料。
製造装置。
前工程。
後工程。
Packaging。
検査。
電力。
水。
物流。
人材。
Research。
⸻
Supply Chainを分解する。
どこにCapabilityがあるのか。
どこが不足しているのか。
どこを国内で保持するのか。
どこを海外と接続するのか。
⸻
ここまで分解して初めて、
Future Architectureになる。
⸻
製造業の未来では、
AIとDigitalも重要になる。
しかし、
単に工場へAIを導入すればよいわけではない。
重要なのは、
製造時間のどこを短縮できるのか
である。
⸻
設計時間。
試作時間。
検査時間。
設備停止時間。
調達時間。
生産計画時間。
Maintenance時間。
⸻
AIを、
これらの時間へ入れる。
⸻
設計では、
Generative Design。
Simulation。
Digital Twin。
を使う。
⸻
工場では、
Sensor Dataから、
異常を早期検知する。
品質を予測する。
設備故障を予測する。
⸻
Supply Chainでは、
需要変化を見る。
在庫を調整する。
部品不足を予測する。
代替Supplierを探索する。
⸻
AIの目的は、
工場をAI化することではない。
Future Stateへ到達するImplementation Timeを短縮すること
である。
⸻
Digital Twinも、
同じ位置にある。
工場をDigital空間へ再現する。
設備配置を変える。
Production Lineを試す。
Energy消費を確認する。
故障Scenarioを見る。
⸻
現実の工場を変更する前に、
Digital上で試す。
すると、
Physical Implementationの失敗Costを減らせる。
⸻
Design
→ Simulate
→ Verify
→ Implement
という順序をつくる。
⸻
製造業の未来には、
Robotもある。
人口減少によって、
労働力は減少する。
特に、
工場。
物流。
建設。
Maintenance。
では、
人手不足が大きな制約になる可能性がある。
⸻
だから、
Automationは、
単なる人件費削減ではない。
社会が必要な生産能力を維持するためのInfrastructure
になる。
⸻
しかし、
すべてを無人化する必要はない。
人間が得意な仕事。
Robotが得意な仕事。
AIが得意な仕事。
を分ける。
⸻
人間は、
判断する。
改善する。
設計する。
例外へ対応する。
⸻
Robotは、
反復する。
運ぶ。
加工する。
危険な作業を行う。
⸻
AIは、
Dataを分析する。
予測する。
最適化する。
⸻
Human
＋ AI
＋ Robot
を、
一つのProduction Systemとして設計する。
⸻
ここで、
製造現場の技能が重要になる。
日本の製造業には、
長期間の経験によって形成された、
Tacit Knowledgeがある。
⸻
音。
振動。
手触り。
材料の状態。
設備の微妙な変化。
熟練者が、
言葉にせず判断しているKnowledgeである。
⸻
人口減少によって、
熟練者が退職すれば、
このKnowledgeが失われる可能性がある。
⸻
だから、
Digital化には、
もう一つの役割がある。
技能を次世代へ継承すること
である。
⸻
作業を記録する。
Sensorで測る。
映像を残す。
判断理由を言語化する。
AIで整理する。
Trainingへ使う。
⸻
Tacit Knowledgeを、
完全にDataへ変えることはできない。
しかし、
失われる量を減らすことはできる。
⸻
製造業のDigital Transformationとは、
PaperをDigitalへ変えることだけではない。
産業Memoryを保存し、次のCapabilityへ変換すること
でもある。
⸻
中小製造企業には、
特にこの視点が重要になる。
一社では小さくても、
特定工程では、
世界的に高いCapabilityを持つ企業がある。
⸻
問題は、
そのCapabilityが、
未来産業から見えないことである。
⸻
大企業の既存Supply Chainの中では知られている。
しかし、
Startup。
大学。
新しい産業。
海外企業。
からは発見されにくい。
⸻
だから、
Manufacturing Capability Mapを、
Matching Infrastructureへ接続する。
⸻
「この部品をつくれる企業」
ではなく、
「この精度、この材料、この工程を扱える企業」
として検索できる。
⸻
すると、
Startupが、
必要な製造Partnerを見つけられる。
大学Technologyを、
試作できる企業が見つかる。
海外企業が、
日本のSupplierへ接続できる。
⸻
製造Capabilityそのものが、
Network化される。
⸻
これによって、
未来産業の立ち上げ時間を短縮できる。
⸻
製造業には、
EnergyというDependencyもある。
工場は、
電力を使う。
熱を使う。
水を使う。
材料を使う。
⸻
特に、
Semiconductor。
Data Center関連。
素材。
化学。
などでは、
Energy Infrastructureが重要になる。
⸻
Future Manufacturingを設計するなら、
工場だけを設計してはいけない。
Energy。
Grid。
Water。
Logistics。
Land。
Housing。
人材。
まで見る。
⸻
つまり、
Factory Architectureから、
Industrial Area Architecture
へ視点を広げる。
⸻
未来の工場を誘致した。
しかし、
電力が足りない。
Engineerが住めない。
物流がない。
水が足りない。
これでは、
Implementationは止まる。
⸻
Future Pullでは、
Dependencyを先に解く。
⸻
工場建設。
Energy Infrastructure。
人材育成。
住宅。
交通。
Supply Chain。
を、
可能な限り並列で準備する。
⸻
これによって、
Future Implementation Timeを短縮する。
⸻
Supply Chainにも、
新しい考え方が必要になる。
過去には、
Cost最小化が重要だった。
しかし、
未来には、
Resilienceも必要になる。
⸻
災害。
感染症。
地政学。
輸送障害。
Cyberattack。
資源制約。
⸻
一つのSupplier。
一つの国。
一つの輸送Route。
へ依存すれば、
効率は高くても、
System全体が停止する可能性がある。
⸻
だから、
重要部品について、
Dependencyを可視化する。
⸻
どこでつくられているのか。
代替Supplierはあるか。
在庫はどれだけあるか。
国内で再生産できるか。
別Technologyへ切り替えられるか。
⸻
Future Supply Chainでは、
Costだけではなく、
Continuity Value
を見る。
⸻
ただし、
すべてを日本国内で生産する必要はない。
それでは、
CostもInnovationも失う可能性がある。
⸻
必要なのは、
閉じることではない。
世界と接続したまま、重要Capabilityを失わないこと
である。
⸻
Japan Manufacturingは、
Global Networkの中で存在する。
海外市場。
海外工場。
海外Supplier。
海外研究機関。
海外人材。
これらとの接続は、
未来にも必要になる。
⸻
だから、
製造業のFuture Stateは、
国内回帰だけではない。
Domestic Capabilityと、
Global Networkを、
適切に組み合わせる。
⸻
さらに、
製造業には、
Circularityが必要になる。
つくる。
使う。
捨てる。
という一方向だけではなく、
回収する。
修理する。
再利用する。
再製造する。
Recycleする。
⸻
資源制約が大きくなるほど、
製品のLife Cycle全体を見る必要がある。
⸻
設計段階から、
Repair。
Reuse。
Recycle。
を考える。
⸻
すると、
製造業は、
大量生産だけではなく、
資源を循環させるSystem
になる。
⸻
未来の製造業では、
Productそのものも変わる。
製品を売って終わりではない。
Software Update。
Maintenance。
Data Service。
Subscription。
Remote Support。
⸻
Physical ProductとDigital Serviceが接続する。
⸻
自動車。
Robot。
Medical Device。
Industrial Equipment。
多くの製品が、
製造後も継続的に更新される。
⸻
つまり、
製造業は、
ManufacturingからContinuous Productへ
広がっていく。
⸻
ここでは、
Cybersecurityも、
製品品質の一部になる。
Softwareを持つ製品は、
出荷後も安全性を維持する必要がある。
⸻
Qualityとは、
寸法精度だけではない。
Reliability。
Software。
Security。
Update。
まで含む。
⸻
日本が持ってきた品質管理Capabilityを、
Digital Productへ拡張する。
⸻
これは、
日本の製造業にとって、
大きなFuture Potentialになり得る。
⸻
製造業の価値は、
安く大量につくることだけではない。
壊れにくい。
安全である。
長く使える。
修理できる。
信頼できる。
⸻
これらのCapabilityは、
未来社会でも重要である。
⸻
Future Pullから見ると、
日本の製造業は、
過去の成功産業ではない。
未来を物質世界へ実装するための巨大なCapability Reservoir
である。
⸻
そこには、
設備がある。
人材がいる。
企業がある。
技術がある。
Supply Chainがある。
地域Knowledgeがある。
⸻
これらを、
現在のProduct分類から解放する。
未来Requirementへ再接続する。
⸻
すると、
自動車産業のCapabilityが、
Robotへ移る。
精密機械のCapabilityが、
Healthcareへ移る。
素材産業が、
Energyへ移る。
電子部品が、
AI Infrastructureへ移る。
⸻
産業は、
Productの寿命より長く生きることができる。
なぜなら、
Capabilityを、
次のProductへ移せるからである。
⸻
だから、
製造業の未来戦略を、
最小に整理すれば、
こうなる。
Current Manufacturing Capability
↓
Capability Mapping
↓
Future Manufacturing State
↓
Gap
↓
AI / Digital / Robot
↓
Capital / Energy / Human Resources
↓
Parallel Implementation
↓
Future Manufacturing Capability
⸻
守るべきなのは、
過去のProductではない。
未来をつくる能力
である。
⸻
製造業が、
この転換を行えば、
日本は、
未来製品を輸入して消費するだけの国ではなく、
未来Technologyを、
実際の物質へ変換できる国であり続けることができる。
⸻
しかし、
未来の産業は、
Physicalだけでは動かない。
工場。
Machine。
Robot。
Supply Chain。
そのすべての上に、
DataとSoftwareとAIが重なり始めている。
製造業そのものも、
Digital Industryと分離できなくなる。
次節では、
日本の産業全体のImplementation Timeを変える基盤として、
AI・Digital
を見ていく。
第7章 産業界
第3節 AI・Digital
AIとDigitalは、
一つの産業ではない。
製造。
金融。
医療。
物流。
Energy。
行政。
教育。
文化。
ほぼすべての産業へ入り込み、
その動き方そのものを変える。
だから、
Future Pullから見ると、
AI・Digitalは、
日本全体の未来実装時間を短縮する共通基盤
である。
⸻
Digital化の本質は、
紙を画面へ変えることではない。
情報を、
検索できる。
接続できる。
再利用できる。
更新できる。
状態へ変えることにある。
⸻
DataがDigital化される。
System間がAPIで接続される。
Cloudで共有される。
AIがそのDataを読み、
分析し、
判断を支援する。
ここまで進むと、
Digitalは、
単なる事務効率化ではなく、
社会や産業の認知能力を高めるInfrastructure
になる。
⸻
AIも、
人間の仕事を置き換えるTechnologyとしてだけ見てはいけない。
未来産業で重要なのは、
人間だけでは処理しきれない情報量を扱い、
設計と判断の速度を高めることである。
⸻
市場を分析する。
設計案をつくる。
Softwareを書く。
研究文献を読む。
異常を検知する。
需要を予測する。
物流を最適化する。
創薬候補を探索する。
⸻
AIは、
産業のさまざまな場所で、
思考時間
を短縮する。
⸻
ここで重要なのは、
AIによって何人を減らしたかではない。
何日かかっていた設計が、
どれだけ短くなったか。
どれだけ多くの仮説を試せたか。
どれだけ早く異常を発見できたか。
どれだけ人間が高度な仕事へ移れたか。
⸻
AIの価値を、
Implementation Time
から見る。
⸻
たとえば、
製造業なら、
設計。
Simulation。
品質管理。
Maintenance。
Supply Chain。
へAIを使える。
⸻
物流なら、
需要予測。
配車。
Route。
倉庫。
在庫。
へ使える。
⸻
Healthcareなら、
診断支援。
医療事務。
画像解析。
創薬。
予防。
へ使える。
⸻
行政なら、
文書検索。
政策分析。
申請支援。
問い合わせ。
Simulation。
へ使える。
⸻
つまり、
AIは、
各産業の内部に、
新しい知性Layerとして入る。
⸻
このとき、
AI産業だけを育てればよいわけではない。
重要なのは、
AIを使える産業を増やすこと
である。
⸻
世界最高水準のAI Modelが存在しても、
企業のDataが整理されていない。
業務がDigital化されていない。
人材がいない。
Security Ruleがない。
これでは、
産業全体の生産性は変わらない。
⸻
だから、
AI Future Stateを、
Model性能だけで置いてはいけない。
日本の企業や行政が、
日常的にAIを利用できる状態。
必要なDataへ安全にAccessできる状態。
人間がAI Outputを検証できる状態。
そのStateを置く。
⸻
すると、
必要なRequirementが見える。
Compute。
Data。
Cloud。
Semiconductor。
Energy。
Network。
Security。
Human Resources。
Governance。
⸻
AIは、
Softwareだけでは成立しない。
物理Infrastructureを必要とする。
⸻
大量の計算には、
Semiconductorが必要になる。
Data Centerが必要になる。
電力が必要になる。
通信が必要になる。
冷却や土地も必要になる。
⸻
つまり、
AI Future Stateは、
Digital ArchitectureとPhysical Infrastructureの接続
によって成立する。
⸻
ここで、
製造業とAIがつながる。
日本が、
AIを利用するだけなのか。
AI Infrastructureの一部を、
自らつくるのか。
⸻
半導体材料。
製造装置。
精密部品。
Power Electronics。
Cooling。
Robot。
日本がすでに持つManufacturing Capabilityを、
AI Infrastructureへ接続できる可能性がある。
⸻
AIと製造業を、
別産業として考える必要はない。
AI × Manufacturing
その接点に、
新しいFuture Industryが生まれる。
⸻
Digital Infrastructureでは、
Dataが重要になる。
しかし、
Dataは、
集めればよいわけではない。
⸻
誰のDataか。
何のために使うのか。
品質は十分か。
更新されているか。
他Systemと接続できるか。
Securityは確保されているか。
⸻
Dataには、
Governanceが必要になる。
⸻
企業ごとに、
異なるFormat。
自治体ごとに、
異なるSystem。
病院ごとに、
異なるData。
この分断が大きければ、
AIのImplementation Timeも長くなる。
⸻
だから、
未来のDigital Architectureでは、
Interoperability
が重要になる。
すべてを一つの巨大Systemへ統合するのではない。
共通Standard。
API。
Identity。
Access Rule。
によって、
必要なときに接続できるようにする。
⸻
分散したまま、
接続可能にする。
これは、
Japan Architecture全体と同じ原理である。
⸻
Cloudも、
重要なInfrastructureになる。
企業ごとに、
すべての計算設備を所有する必要はない。
必要なときに、
必要なComputeを使う。
⸻
しかし、
Cost。
Security。
Data Sovereignty。
Vendor Dependency。
も考える必要がある。
⸻
Future Digital Architectureでは、
一社のTechnologyへ完全固定されない。
Open Standard。
Multi-cloud。
Portable Data。
Exit Strategy。
を持つ。
⸻
Technologyは、
変化する。
だから、
未来のSystemは、
最新Technologyを選ぶことより、Technologyを交換できること
が重要になる。
⸻
Cybersecurityも、
AI・Digitalの外側には置けない。
Digital化が進むほど、
攻撃されたときの影響は大きくなる。
⸻
工場。
病院。
銀行。
Energy。
交通。
行政。
すべてがNetwork化すれば、
Cyberattackは、
情報問題ではなく、
Realityの停止につながる。
⸻
だから、
Securityは、
後から追加するCostではない。
Digital Infrastructureの基本Requirement
である。
⸻
Securityを高める。
しかし、
接続をすべて閉じるわけでもない。
Innovationには、
Data利用と接続性が必要になる。
⸻
Open
＋ Secure
この両立をArchitectureとして設計する。
⸻
AIには、
Governanceも必要になる。
AIが、
採用。
融資。
医療。
行政。
など、
重要な判断を支援するほど、
誤りの影響も大きくなる。
⸻
誰が責任を持つのか。
人間が確認するのか。
異議申立てはできるのか。
どのDataを使ったのか。
Biasはないか。
⸻
AIの能力だけではなく、
Human Accountability
を残す。
⸻
Future AIは、
人間をDecision Loopから消すことを目的にしない。
Routineな判断は自動化する。
複雑な判断は支援する。
重大な判断は、
人間が責任を持つ。
⸻
Riskに応じて、
AIの権限を変える。
⸻
Assist
→ Recommend
→ Limited Automation
段階的に実装する。
⸻
企業にとって、
最大の課題の一つは、
Legacy Systemである。
古いSystem。
分断されたDatabase。
紙Process。
個別最適された業務。
⸻
その上へAIを載せても、
十分な効果が出ないことがある。
だから、
AI導入の前に、
Processそのものを見直す必要がある。
⸻
AIに、
非効率な仕事を高速でやらせるのではない。
その仕事は、
本当に必要なのか。
重複していないか。
消せないか。
⸻
Digitize
→ Redesign
→ Automate
という順序が重要になる。
⸻
これは、
日本企業の生産性向上にも直結する。
人手不足の中で、
すべての既存業務を人間が維持することは難しい。
⸻
書類。
照合。
入力。
Scheduling。
定型問い合わせ。
Reporting。
これらを自動化する。
⸻
そして、
人間を、
Research。
Design。
Sales。
Management。
Care。
Creation。
へ移す。
⸻
未来の生産性向上とは、
人間を減らすことではなく、
人間時間の再配置
である。
⸻
AI・Digitalは、
中小企業にも重要になる。
従来、
高度なSoftware。
Data Analysis。
海外Marketing。
翻訳。
Design。
には、
多くの専門人材が必要だった。
⸻
生成AIによって、
小規模企業でも、
一部の高度能力へAccessできる。
⸻
海外顧客へ営業資料をつくる。
製品Descriptionを多言語化する。
契約文書を確認する。
Design案を出す。
社内Knowledgeを検索する。
⸻
これは、
企業規模によるCapability Gapを、
一部縮める可能性がある。
⸻
だから、
AI導入を、
大企業だけのTransformationにしてはいけない。
中小企業。
地域企業。
自治体。
病院。
学校。
社会全体へ届くInfrastructureにする。
⸻
そのためには、
共通AI Service。
教育。
導入支援。
Security。
Cloud。
が必要になる。
⸻
AI人材についても、
全員をAI Engineerにする必要はない。
三つの層を考えればよい。
AIをつくる人。
AIを業務へ組み込む人。
AIを日常的に使う人。
⸻
Build
→ Integrate
→ Use
それぞれの人材を育てる。
⸻
特に不足しやすいのは、
Technologyと業務をつなぐ人材である。
製造とAI。
医療とAI。
金融とAI。
行政とAI。
⸻
現場を理解し、
AI Capabilityを理解し、
両方を翻訳できる。
この人材が、
Implementationの接続点になる。
⸻
AI・Digitalには、
地域格差を縮める可能性もある。
Remote Work。
Online Education。
Remote Healthcare。
Digital Government。
地域に住みながら、
都市と同じKnowledgeへAccessできる。
⸻
しかし、
通信Infrastructureがなければ成立しない。
Digital Literacyがなければ使えない。
だから、
Technologyだけで格差が消えるわけではない。
⸻
Access
＋ Skill
＋ Service
三つを同時に整える。
⸻
さらに、
AI・Digitalは、
企業間の接続を変える。
Supply Chain。
Research。
Procurement。
Finance。
企業同士がDataで接続されれば、
産業Networkの状態を、
より早く把握できる。
⸻
部品不足。
需要変化。
設備停止。
物流遅延。
早期に検知できる。
⸻
つまり、
Digital化は、
一企業を効率化するだけではなく、
産業Network全体を観測可能にする。
⸻
これによって、
Japan StateとIndustry Stateも接続できる。
どの産業で、
どのCapabilityが不足しているか。
どの地域で、
人材が不足しているか。
どのSupply Chainに、
Critical Dependencyがあるか。
⸻
現在を高解像度で見ることで、
未来への投資を早く決められる。
⸻
AI・Digitalの最大の価値は、
ここにある。
未来を正確に予測することではない。
観測から実装までのLoopを短くすること
である。
⸻
Observe
→ Analyze
→ Design
→ Implement
→ Verify
→ Update
これまで人間だけで回していた循環を、
AIとDigitalで高速化する。
⸻
しかし、
高速化だけを目的にしない。
誤った方向へ速く進めば、
損失も大きくなる。
だから、
Verificationを必ず入れる。
⸻
AIが提案する。
人間が確認する。
小さく実装する。
Realityを見る。
修正する。
⸻
速さと検証を、
一つのCycleへ入れる。
⸻
Future Pullから見たAI・Digitalを、
最小に整理すると、
次のようになる。
Data
→ Digital Infrastructure
→ AI Intelligence
→ Human Decision
→ Implementation
→ Reality Data
→ Learning
Realityから得たDataが、
次のAIと設計へ戻る。
⸻
この循環が、
製造。
物流。
Energy。
Healthcare。
Government。
Education。
すべての領域で動く。
⸻
だから、
AI・Digitalは、
一つの成長産業ではない。
日本社会全体へ埋め込まれる横断的な知性Infrastructure
である。
⸻
そして、
このInfrastructureが整えば、
未来実装時間は、
一つの企業だけでなく、
日本全体で短縮される。
研究から製品へ。
製品から市場へ。
問題発見から政策へ。
診断から治療へ。
⸻
未来と現在の距離を縮める共通Layerとして、
AIとDigitalが働く。
⸻
しかし、
DataとSoftwareだけでは、
社会は動かない。
人も、
物も、
薬も、
食料も、
部品も、
現実空間を移動する必要がある。
未来の速度は、
情報速度だけでは決まらない。
次節では、
Physical Realityを接続する
Mobility・Logistics
から、
未来実装時間を引いていく。
第7章 産業界
第4節 Mobility・Logistics
未来は、
情報だけでは動かない。
人が移動する。
食料が届く。
部品が工場へ運ばれる。
薬が病院へ届く。
商品が家庭へ届く。
災害時には、
必要な物資が必要な場所へ運ばれる。
Physical Realityを接続するのが、
MobilityとLogistics
である。
⸻
Mobilityとは、
自動車産業だけを意味しない。
鉄道。
Bus。
Taxi。
航空。
船舶。
自転車。
徒歩。
On-demand Service。
自動運転。
それらを接続した、
人が必要な場所へ到達するためのSystem
である。
⸻
Logisticsも、
Truckだけではない。
倉庫。
港湾。
空港。
鉄道貨物。
配送拠点。
Inventory。
Supply Chain。
Digital Platform。
荷物が発生してから、
目的地へ届くまでの全体がLogisticsである。
⸻
Future Pullから見ると、
重要なのは、
車両台数でも、
輸送量でもない。
Future Stateとして問うべきなのは、
必要な人と物が、必要な場所へ、必要な時間内に移動できるか
である。
⸻
人口減少は、
このFuture Stateへ大きな影響を与える。
利用者が減る。
Driverが減る。
物流人材が不足する。
地域交通を現在と同じ方法だけで維持することが難しくなる。
⸻
だから、
未来のMobilityを、
現在の交通手段の延長としてだけ考えてはいけない。
Busを何台残すか。
Taxiを何台増やすか。
ではなく、
まず、
移動Requirementを見る。
⸻
高齢者が、
病院へ行ける。
子どもが、
学校へ行ける。
働く人が、
職場へ行ける。
買い物できる。
地域活動へ参加できる。
⸻
そこから、
最適なMobilityを組み合わせる。
⸻
都市では、
大量輸送が重要になる。
鉄道。
地下鉄。
Bus。
Walking。
それらをDigitalで接続する。
⸻
地方では、
固定Routeだけでは維持しにくい場合がある。
On-demand Mobility。
Taxi。
Community Transport。
自動運転。
複数の手段を組み合わせる。
⸻
つまり、
Future Mobilityは、
Vehicle中心からAccess中心へ
視点を移す。
⸻
これは、
Healthcareとも接続する。
地域医療を改善するために、
病院だけを増やす必要はない。
患者が病院へ行く。
医療者が地域へ移動する。
Remote Healthcareを使う。
薬を配送する。
⸻
Medical Accessは、
HealthcareとMobilityの組み合わせで決まる。
⸻
だから、
産業分類上は別でも、
Future Stateでは一つのSystemとして設計する。
⸻
Healthcare
× Mobility
× Digital
この接続によって、
地域の医療Accessを変えることができる。
⸻
Logisticsも、
日本の人口構造と強く関係する。
物流需要が存在しても、
Driverが不足すれば、
現在の配送網を維持できない。
⸻
そこで、
Automation。
共同配送。
自動倉庫。
AI Route Optimization。
自動運転。
Drone。
鉄道。
船舶。
複数のTechnologyを組み合わせる。
⸻
重要なのは、
特定Technologyを導入することではない。
少ない人員でも必要な物流能力を維持できるFuture State
を実現することである。
⸻
物流には、
多くの待ち時間が存在する。
荷待ち。
積み下ろし。
倉庫内移動。
受発注処理。
在庫確認。
配送調整。
⸻
Future Pullでは、
移動速度だけではなく、
この待ち時間を見る。
Truckを速く走らせることには、
安全上の限界がある。
しかし、
荷待ち時間や情報処理時間は、
Digital化によって短縮できる。
⸻
つまり、
Logisticsの未来実装では、
Physical Speedよりも、
Process Time
を改善できる場合がある。
⸻
Dataを接続する。
荷物の位置を知る。
倉庫の空き状況を知る。
到着予定を共有する。
需要を予測する。
⸻
すると、
物流は、
物が動いてから管理するSystemから、
物が動く前に全体を調整するSystem
へ変わる。
⸻
AIは、
この領域で重要になる。
需要を予測する。
在庫を配置する。
Routeを組む。
Vehicleを割り当てる。
天候やTrafficを考慮する。
⸻
人間が一つずつ調整していた複雑なNetworkを、
AIが支援する。
⸻
しかし、
AIだけでは物流は動かない。
道路。
倉庫。
港。
Vehicle。
Energy。
人材。
Physical Infrastructureが必要になる。
⸻
ここでも、
DigitalとPhysicalの接続
が重要になる。
⸻
自動運転は、
Future Mobilityの大きな要素になり得る。
しかし、
Vehicle Technologyだけでは実装できない。
⸻
道路。
Map。
通信。
Insurance。
事故責任。
Cybersecurity。
Maintenance。
地域運用。
社会受容。
⸻
複数のRequirementがある。
⸻
だから、
「自動運転Technologyが完成した日」
と、
「自動運転社会が実装された日」
は同じではない。
⸻
Future Pullでは、
このGapを先に見る。
Technology開発と並行して、
制度。
Infrastructure。
Insurance。
地域実証。
人材。
を準備する。
⸻
Technology
＋ Regulation
＋ Infrastructure
＋ Operation
を並列化する。
⸻
これによって、
Technology完成後の待ち時間を短縮する。
⸻
EVなどの新しいMobilityも同じである。
Vehicleだけではなく、
Charging。
Grid。
Battery。
Energy Supply。
Repair。
Recycle。
まで必要になる。
⸻
一つの製品を導入するのではなく、
Mobility Ecosystem
を実装する。
⸻
ここで、
製造業との接続が再び現れる。
日本の自動車産業は、
完成車だけではない。
部品。
Material。
精密加工。
Electronics。
Software。
Battery。
生産設備。
巨大なCapability Networkを持つ。
⸻
未来のMobilityでは、
Vehicleの構造が変わっても、
すべてのCapabilityが消えるわけではない。
⸻
どのCapabilityを残すか。
どのCapabilityを更新するか。
何をSoftwareへ移すか。
どこへ新規投資するか。
Productではなく、
CapabilityからTransformationを設計する。
⸻
物流では、
共同化も重要になる。
各企業が、
それぞれTruckを走らせる。
それぞれWarehouseを持つ。
それぞれ配送Systemをつくる。
⸻
人口減少下では、
この重複を維持するCostが大きくなる。
⸻
競争すべき部分と、
共有できる部分を分ける。
幹線輸送。
地域配送拠点。
Digital Standard。
共同Warehouse。
⸻
共通Infrastructureを共有しながら、
Serviceでは競争する。
⸻
Shared Infrastructure
＋ Competitive Service
というArchitectureが考えられる。
⸻
地域Logisticsでは、
さらに重要になる。
過疎地域で、
複数企業が別々に少量配送すれば、
効率が低くなる。
⸻
食料。
薬。
宅配。
行政物資。
地域内物流を、
一定範囲で接続できれば、
少ない輸送能力を有効に使える。
⸻
物流は、
商業Serviceであると同時に、
地域生活Infrastructureでもある。
⸻
災害時には、
その性格がさらに明確になる。
道路が止まる。
港が使えない。
Warehouseが被災する。
通信が切れる。
⸻
平常時だけ最適化された物流Networkは、
危機に弱い。
だから、
Future Logisticsには、
Resilience
を入れる。
⸻
代替Route。
複数拠点。
Emergency Stock。
異なる輸送手段。
位置情報。
需要情報。
⸻
災害発生後に、
Network全体を再構成できるようにする。
⸻
ここでは、
Digital Twinも利用できる。
道路。
物流拠点。
港。
Warehouse。
Vehicle。
需要。
をDigital空間で把握する。
⸻
一部Routeが停止した場合、
どこへ切り替えるか。
どの物資を優先するか。
事前にSimulationする。
⸻
Mobility・Logisticsは、
経済安全保障とも接続する。
日本は、
世界のSupply Chainと深く結ばれている。
原料。
Energy。
部品。
食料。
医薬品。
⸻
すべてを国内で完結させることは現実的ではない。
しかし、
Critical Goodsについて、
どこから来ているのか。
どの港を通るのか。
どこに代替Routeがあるのか。
理解する必要がある。
⸻
つまり、
未来の物流では、
Costだけでなく、
Dependency Visibility
が重要になる。
⸻
国際物流と国内物流を分けすぎない。
港から工場へ。
工場からWarehouseへ。
Warehouseから店舗へ。
一つのFlowとして見る。
⸻
Supply Chainのどこか一つが止まれば、
最終Productも止まる。
だから、
End-to-Endで観測する。
⸻
また、
Mobilityは、
時間だけでなく、
都市そのものを変える。
自動車を前提にした都市。
鉄道を中心とした都市。
Walkingを中心とした地域。
⸻
交通Systemが変われば、
住宅。
商業。
医療。
学校。
企業立地。
も変わる。
⸻
Future Mobilityは、
Transport Policyではなく、
Urban and Regional Architecture
の一部になる。
⸻
人口減少地域では、
すべてのServiceを各集落へ固定配置することが難しくなる。
Mobilityを高めることで、
複数地域でServiceを共有するという選択肢も生まれる。
⸻
逆に、
Digital Serviceによって、
移動そのものを減らせる場合もある。
Remote Work。
Online Administration。
Remote Healthcare。
Online Education。
⸻
未来のMobility政策には、
移動を増やすことだけでなく、不要な移動を減らすこと
も含まれる。
⸻
人が動く。
Serviceが動く。
Dataが動く。
どれが最適なのかを選ぶ。
⸻
たとえば、
行政手続きのためだけに、
役所へ移動する必要はない。
診療内容によっては、
Remote Healthcareが使える。
一方、
人と直接会うことに価値がある場面もある。
⸻
PhysicalとDigitalを、
目的によって組み合わせる。
⸻
ここでも、
未来は二択ではない。
RealかDigitalかではなく、
最適なAccess Architecture
をつくる。
⸻
Mobility・Logisticsには、
Energyも不可欠である。
車。
鉄道。
航空。
船舶。
Warehouse。
物流拠点。
すべてEnergyを必要とする。
⸻
将来、
MobilityのEnergy構成が変われば、
Energy Infrastructureも変える必要がある。
Charging。
Fuel Supply。
Grid。
Storage。
⸻
だから、
Mobility Future Stateと、
Energy Future Stateを、
別々に設計してはいけない。
⸻
Mobility
↔ Energy
↔ Infrastructure
として見る。
⸻
最小に整理すると、
Future Mobility・Logisticsには、
四つのRequirementがある。
Access。
人と物が必要な場所へ到達できる。
Efficiency。
限られた人材と資源でNetworkを維持できる。
Resilience。
Shockが起きても重要なFlowを止めない。
そして、
Connectivity。
Digital、Energy、Healthcare、Industryと接続できる。
⸻
Future Pullは、
移動を未来から考える。
将来、
どこに人が住むのか。
どの産業がどこにあるのか。
どの医療Serviceが必要なのか。
どの物流量が必要になるのか。
⸻
そこから、
現在必要なInfrastructure。
Technology。
制度。
人材。
Capital。
を引く。
⸻
未来になってから、
交通網をつくり直すのでは遅い。
未来の人口配置。
産業配置。
Energy配置。
を見ながら、
現在から準備する。
⸻
Mobility・Logisticsとは、
単に物理的な距離を縮める産業ではない。
日本の中に存在する分散した人、物、産業、生命を、一つのRealityとして接続するNetwork
である。
⸻
製造業が、
未来を物質へ変える。
AI・Digitalが、
情報と知性を接続する。
Mobility・Logisticsが、
その物質を現実空間で動かす。
⸻
しかし、
これらすべてが動くためには、
さらに深い基盤が必要になる。
工場を動かす。
Data Centerを動かす。
鉄道を動かす。
病院を動かす。
都市を動かす。
その根底にあるのが、
EnergyとInfrastructureである。
次節では、
日本の未来社会そのものを支える
Energy・Infrastructure
へ進む。
第7章 産業界
第5節 Energy・Infrastructure
未来の産業は、
Energyなしには動かない。
工場。
Data Center。
病院。
鉄道。
物流。
通信。
住宅。
AI。
Robot。
社会のほぼすべての機能は、
EnergyとInfrastructureの上に存在している。
だから、
Future Pullから見れば、
Energy・Infrastructureは、
一つの産業分野ではない。
未来社会そのものを成立させる基盤条件
である。
⸻
たとえば、
AI産業を大きく育てたいとする。
AI Model。
Semiconductor。
Data Center。
Engineer。
そこだけを見ても、
Future Stateは完成しない。
大量のComputeには、
大量の電力が必要になる。
電力を届けるGridが必要になる。
冷却。
通信。
土地。
水。
Security。
も必要になる。
⸻
つまり、
AI Future Stateは、
Energy Future Stateと分離できない。
同じことが、
製造業。
Mobility。
Healthcare。
にも言える。
⸻
だから、
Future Stateを設計するとき、
産業ごとに必要なEnergyを、
後から足し合わせてはいけない。
未来の産業構造から、Energy Requirementを先に引く。
⸻
将来、
どこに工場があるのか。
どこにData Centerがあるのか。
MobilityはどのEnergyを使うのか。
住宅や都市の需要はどう変わるのか。
そこから、
必要な供給能力を逆算する。
⸻
Energy Infrastructureには、
長いLead Timeがある。
発電設備。
送電。
変電。
蓄電。
燃料Supply Chain。
一日ではつくれない。
⸻
だから、
2035年に必要な電力は、
2035年から準備するのでは遅い。
Future Stateから、
現在のInvestment Start Timeを引く。
⸻
Future Demand
→ Energy Requirement
→ Infrastructure Requirement
→ Investment
→ Construction
→ Supply
という順序になる。
⸻
ここに、
Future Pullの時間設計が最も明確に現れる。
未来を早めるために、
発電所の安全確認を省略するのではない。
建設に必要な時間を無理に消すのでもない。
必要になることが分かった時点で、準備を始める。
⸻
Energy政策には、
複数の条件がある。
安定供給。
Cost。
Environment。
安全。
Energy Security。
一つだけを最大化すればよいわけではない。
⸻
安価でも、
供給が不安定なら、
産業Infrastructureとして弱い。
安定していても、
Costが高すぎれば、
産業競争力へ影響する。
低炭素でも、
System全体のReliabilityが不足すれば、
社会は動かない。
⸻
必要なのは、
複数条件を同時に成立させるPortfolio
である。
⸻
未来のEnergy Systemは、
一つのTechnologyだけで決まるとは限らない。
複数の発電方式。
蓄電。
Demand Response。
Grid。
Energy Efficiency。
地域Energy。
それぞれを組み合わせる。
⸻
ここでも、
Future Stateを固定Technologyへ結びつけない。
Future Stateとして必要なのは、
「この発電方式を何％にする」
ことよりも、
必要な電力を、
安全で、
持続可能なCostで、
安定して供給できることにある。
⸻
そのRequirementを満たすTechnology Portfolioを、
Realityに合わせて更新する。
⸻
Energyには、
地理もある。
発電場所。
需要地。
送電Network。
工場。
都市。
地域。
すべてが空間に配置されている。
⸻
だから、
Energy PolicyとIndustrial Location Policyは、
接続する必要がある。
大量の電力が必要な工場を誘致する。
しかし、
送電能力がない。
これでは実装できない。
⸻
Future Pullでは、
企業誘致と、
Energy Infrastructureを並列化する。
土地。
Grid。
通信。
水。
物流。
人材。
を一体で準備する。
⸻
これを、
単なる工業団地ではなく、
Future Industrial Infrastructure
として見る。
⸻
Infrastructureについても、
同じ考え方が必要になる。
道路。
橋。
Tunnel。
鉄道。
港。
空港。
水道。
通信。
公共施設。
日本には、
長い時間をかけて整備された巨大なInfrastructureがある。
⸻
これは、
大きな資産である。
しかし、
同時に、
維持と更新の問題もある。
Infrastructureは、
建設した瞬間で終わらない。
点検する。
修理する。
更新する。
災害へ備える。
⸻
人口が減少する中で、
過去と同じ量のInfrastructureを、
同じ方法で維持できるとは限らない。
だから、
未来から見直す。
⸻
どの地域に、
どの人口が住むのか。
どの産業があるのか。
どのServiceが必要なのか。
それを基準に、
Infrastructure Requirementを決める。
⸻
すべてを残す。
すべてを廃止する。
という二択ではない。
維持する。
集約する。
共同化する。
Digitalで代替する。
新設する。
複数の選択肢を持つ。
⸻
たとえば、
行政Serviceなら、
建物を維持するだけでなく、
Digital Serviceによって、
一部のPhysical Infrastructure需要を減らせる。
⸻
Healthcareなら、
すべての地域へ同じ施設を置くのではなく、
地域医療。
Remote Healthcare。
Mobility。
を組み合わせられる。
⸻
Infrastructureは、
Facilityの数ではなく、
必要なServiceを継続的に提供できるか
で評価する。
⸻
これは、
人口減少社会では特に重要である。
⸻
一方、
Physical Infrastructureでなければ代替できないものもある。
水。
Energy。
道路。
物流。
災害対応。
すべてをDigitalへ置き換えることはできない。
⸻
だから、
Future Infrastructureでは、
PhysicalとDigitalを組み合わせる。
⸻
道路へSensorを入れる。
橋をRemote Monitoringする。
Droneで点検する。
AIで劣化を予測する。
Digital Twinで補修Priorityを決める。
⸻
すると、
Maintenanceも、
故障してから修理する方法から、
故障する前に対応する方法
へ変えられる。
⸻
これは、
InfrastructureのFuture Pullである。
将来の故障Riskを、
現在へ引き戻す。
早い段階で、
小さく修理する。
⸻
結果として、
Cost。
停止時間。
災害Risk。
を抑えられる可能性がある。
⸻
Maintenanceには、
人材問題もある。
技術者。
建設作業員。
保守人材。
人口減少によって、
これらの人材も不足する可能性がある。
⸻
だから、
Infrastructure Technologyは、
新設だけではなく、
少ない人員で維持する能力
へ向かう。
⸻
Robot。
Drone。
Sensor。
AI。
Remote Operation。
これらを、
Maintenance Architectureへ組み込む。
⸻
しかし、
最終的な安全判断まで、
すべてAIへ委ねる必要はない。
AIが異常を検出する。
人間が確認する。
必要な場所へ、
技術者を集中する。
⸻
Human。
AI。
Machine。
を組み合わせる。
⸻
Infrastructureには、
Resilienceも必要である。
日本では、
災害を前提から外すことはできない。
地震。
津波。
豪雨。
台風。
火山。
⸻
平常時に最も効率的なSystemが、
災害時にも最も強いとは限らない。
だから、
Future Infrastructureには、
Backupを入れる。
⸻
複数の電力Route。
通信の冗長化。
分散したData Center。
緊急輸送Route。
地域Energy。
Emergency Supply。
⸻
すべてを完全に二重化することはできない。
重要度に応じて、
Resilience Levelを決める。
⸻
病院。
通信。
Energy。
金融。
行政。
物流。
社会のCritical Infrastructureは、
高い継続性を持たせる。
⸻
つまり、
Efficiencyだけでなく、
Continuity
を評価する。
⸻
Energy Securityも、
このResilienceに含まれる。
日本のEnergy Systemは、
国際市場と接続している。
燃料。
資源。
Technology。
Supply Chain。
⸻
完全に国内だけで完結する必要はない。
しかし、
どこへ依存しているのか。
代替はあるのか。
どれだけ備蓄できるのか。
Supply Routeは複数あるか。
⸻
Dependencyを可視化する。
⸻
Future Energy Architectureでは、
Open Network
＋ Strategic Resilience
を両立させる。
世界と接続する。
同時に、
Critical Dependencyを管理する。
⸻
Environmentも、
Future Stateの条件になる。
EnergyやInfrastructureは、
自然環境へ大きな影響を与える。
⸻
だから、
建設Costだけで評価しない。
CO2。
土地。
水。
生態系。
廃棄物。
Life Cycle全体を見る。
⸻
ただし、
Environmentと産業を、
単純な対立として扱わない。
環境負荷を減らすTechnology。
Energy Efficiency。
Recycle。
Circular Infrastructure。
新しい産業Capabilityへ変換する。
⸻
課題そのものが、
Future Industryになる。
⸻
Infrastructure投資には、
Capital Timeも重要である。
道路。
Grid。
発電。
水道。
通信。
長期間使われる。
⸻
だから、
短期Returnだけでは評価できない。
建設Cost。
Maintenance Cost。
更新Cost。
社会Benefit。
Resilience。
将来Technologyとの接続性。
⸻
Life Cycle Value
を見る。
⸻
これは、
Future Capital Architectureと接続する。
Infrastructureには、
長いDurationのCapitalを合わせる。
公共資金。
民間資本。
Insurance。
Long-term Finance。
Projectごとに組み合わせる。
⸻
また、
公共Infrastructureと民間Infrastructureの境界も変化する。
通信。
Cloud。
Data Center。
Energy。
Mobility。
社会Infrastructureを、
民間企業が運営する領域も大きい。
⸻
だから、
政府がすべて所有する必要はない。
重要なのは、
社会に必要な機能が継続的に提供されるArchitecture
である。
⸻
Ownershipより、
Availability。
Reliability。
Security。
Interoperability。
を見る。
⸻
Digital Infrastructureでは、
この考え方が特に重要になる。
通信。
Cloud。
Compute。
Digital Identity。
Cybersecurity。
Data Exchange。
これらが止まれば、
行政。
Finance。
Healthcare。
Industry。
も止まる可能性がある。
⸻
Digitalは、
すでにPhysical Infrastructureと同じくらい、
社会基盤になりつつある。
だから、
未来のInfrastructureを、
道路や橋だけで考えない。
⸻
Physical Infrastructure
＋ Digital Infrastructure
＋ Energy Infrastructure
三つを一つの基盤として見る。
⸻
さらに、
これらを別々に設計しない。
Data Centerには、
通信とEnergyが必要になる。
自動運転には、
道路と通信が必要になる。
Smart Factoryには、
EnergyとDigitalが必要になる。
Remote Healthcareには、
通信と医療Infrastructureが必要になる。
⸻
Future Stateでは、
Infrastructure同士が接続される。
⸻
ここで、
共通Architectureが必要になる。
一つの地域で、
Energy。
Mobility。
Digital。
Healthcare。
を別々に整備するのではなく、
地域Future Stateから一体で設計する。
⸻
未来の都市。
未来の工業地域。
未来の農村。
それぞれに、
必要なInfrastructure Packageがある。
⸻
つまり、
Infrastructure政策は、
個別施設の更新計画から、
地域と産業のFuture Architecture
へ拡張する。
⸻
Future Pullから見れば、
Infrastructureは、
未来の後からついてくるものではない。
Future Stateを可能にする、
最初のRequirementの一つである。
⸻
AI産業をつくる。
その前にEnergyが必要になる。
新しい工場をつくる。
その前にGridと物流が必要になる。
地域医療を変える。
その前に通信とMobilityが必要になる。
⸻
だから、
Infrastructure Requirementを、
最後に検討してはいけない。
⸻
Future State
→ Infrastructure Requirement
→ Early Investment
→ Parallel Construction
→ Future Implementation
早い段階へ引く。
⸻
最小に整理すると、
Future Energy・Infrastructureには、
四つの原則がある。
Capacity。
未来に必要な需要を支えられる。
Resilience。
Shockが起きても重要機能を維持できる。
Adaptability。
Technologyや人口構造の変化に合わせて更新できる。
そして、
Connectivity。
産業、地域、Digital、生命を接続できる。
⸻
EnergyとInfrastructureは、
派手な未来そのものではない。
しかし、
この基盤がなければ、
AIも、
製造業も、
Mobilityも、
Healthcareも、
Future Stateへ到達できない。
⸻
未来を早めるとは、
未来Technologyの登場を待つことではない。
そのTechnologyが到着した瞬間に使える基盤を、先に現在へつくっておくこと
である。
⸻
製造業が、
未来を物質へ変える。
AI・Digitalが、
知性を加える。
Mobility・Logisticsが、
人と物を接続する。
Energy・Infrastructureが、
そのすべてを動かし続ける。
⸻
しかし、
日本の産業を支えているのは、
大企業と巨大Infrastructureだけではない。
地域には、
無数の中小企業があり、
新しい未来を試すStartupがある。
既存Capabilityを継承し、
新しいPotentialを最初にRealityへ変える主体である。
次節では、
日本産業の分散した実装主体として、
中小企業・Startup
を見ていく。
第7章 産業界
第6節 中小企業・Startup
日本の産業は、
大企業だけでできているわけではない。
地域の工場。
部品メーカー。
商店。
建設会社。
IT企業。
物流会社。
医療関連企業。
サービス企業。
そして、
新しい市場へ挑戦するStartup。
その無数の企業が、
日本の産業Realityを支えている。
⸻
Future Pullから見ると、
中小企業とStartupには、
それぞれ異なる役割がある。
中小企業は、
長い時間をかけて蓄積されたCapabilityを持つ。
Startupは、
まだ存在していない市場やTechnologyを、
小さく早く試す。
つまり、
中小企業は蓄積されたPotentialを保持し、Startupは新しいPotentialを探索する。
⸻
この二つを、
別々に考えすぎてはいけない。
未来産業は、
蓄積と探索の両方から生まれる。
⸻
中小企業には、
見えにくいCapabilityがある。
精密加工。
特殊材料。
金型。
制御。
設計。
保守。
地域物流。
顧客との関係。
特定工程のKnow-how。
企業規模は小さくても、
産業Networkの中では、
代替しにくい役割を持つ場合がある。
⸻
だから、
中小企業を、
単に「小さい企業」として扱うのではなく、
Capability Node
として見る。
何人働いているか。
売上はいくらか。
だけではなく、
何ができるのか。
どの産業を支えているのか。
どのKnowledgeを持っているのか。
を見る。
⸻
このCapabilityが、
未来産業へ接続されれば、
企業の意味も変わる。
現在は、
自動車部品をつくっている。
しかし、
その本質的Capabilityが、
精密加工なら、
Robot。
Medical Device。
Space。
Semiconductor。
へ移れる可能性がある。
⸻
Future Pullでは、
現在の取引先から企業を見るのではない。
未来Requirementから、
企業Capabilityを読み直す。
⸻
ここで必要になるのが、
Capability Matching
である。
Future Industryが必要とする技術と、
既存中小企業が持つ技術を接続する。
⸻
Startupが、
Prototypeをつくりたい。
大学が、
新しいDeviceを試作したい。
海外企業が、
特殊部品を探している。
必要なCapabilityを検索し、
地域企業へ接続する。
⸻
これだけでも、
未来実装時間を大きく短縮できる。
新しい工場をゼロからつくる前に、
すでに存在している能力を使えるからである。
⸻
しかし、
中小企業には、
TransformationのGapもある。
人材不足。
後継者不足。
Digital化。
資本。
海外市場へのAccess。
研究開発能力。
⸻
Future Potentialがあっても、
これらのGapによって、
次の産業へ移れない場合がある。
⸻
だから、
中小企業政策を、
単なる企業維持政策にしてはいけない。
重要なのは、
企業を未来へ移行可能な状態にすること
である。
⸻
Digital化する。
AIを使う。
設備を更新する。
人材を育てる。
大学と接続する。
Startupと接続する。
海外顧客へ接続する。
⸻
つまり、
企業単体を支援するだけではなく、
その企業が入るNetworkを更新する。
⸻
特に、
事業承継は重要である。
後継者がいないから廃業する。
そのとき、
失われるのは法人だけではない。
Technology。
設備。
顧客。
人材。
地域Knowledge。
が失われる。
⸻
だから、
事業承継を、
「会社を同じ形で残すこと」
だけで考えない。
M&A。
Employee Buyout。
Startupとの統合。
別企業への技術移転。
複数の方法がある。
⸻
会社の形が変わっても、
Capabilityが次へ継承されればよい。
⸻
Future Pullから見た事業承継は、
過去を守る仕事ではない。
産業Memoryを、
未来へ移す仕事である。
⸻
一方、
Startupには、
別の役割がある。
Startupは、
まだ成立していない市場へ、
小さな資本と少人数で入る。
⸻
大企業が、
大規模投資を決める前に、
Prototypeをつくる。
顧客へ出す。
失敗する。
修正する。
再び試す。
⸻
この速度が、
Startupの強みである。
⸻
Startupとは、
単に若い企業ではない。
Future HypothesisをRealityで検証する装置
である。
⸻
新しいAI Serviceは、
本当に使われるのか。
新しいHealthcareは、
患者に価値があるのか。
新しいMobilityは、
地域で成立するのか。
⸻
市場に出す。
Realityを見る。
仮説を修正する。
⸻
Hypothesis
→ Prototype
→ Market
→ Learning
→ Rebuild
このCycleを高速で回す。
⸻
だから、
Startupの価値を、
企業数だけで測ってはいけない。
いくつ設立されたか。
だけではない。
⸻
どれだけ新しい仮説が試されたか。
どれだけKnowledgeが得られたか。
どれだけScaleしたか。
どれだけ次の産業へCapabilityを残したか。
を見る。
⸻
Startupが失敗しても、
人材。
Technology。
Knowledge。
Network。
が残る場合がある。
その資産が、
別の企業や次のStartupへ移れば、
探索は無駄にならない。
⸻
重要なのは、
Failureから次のAttemptまでの時間を短くすること
である。
⸻
ここで、
資本が必要になる。
Startupには、
銀行融資だけでは対応しにくい段階がある。
売上がない。
担保もない。
Technologyが未完成。
Riskが高い。
⸻
だから、
Seed Capital。
Venture Capital。
Corporate Venture。
Public Funding。
が必要になる。
⸻
しかし、
Startupの資金問題は、
創業時だけではない。
成長すると、
さらに大きな資本が必要になる。
人材を採用する。
工場をつくる。
海外へ進出する。
Marketingする。
⸻
ここに、
Scale Capital Gap
が生まれやすい。
Future Capital Architectureでは、
SeedからScaleまで、
資本が途切れないようにする。
⸻
Seed
→ Growth
→ Scale
→ Market
資本をRelayする。
⸻
さらに、
Startupと大企業の接続が重要になる。
大企業には、
顧客。
工場。
Brand。
Supply Chain。
Global Network。
がある。
Startupには、
速度と新しいTechnologyがある。
⸻
両者を対立させる必要はない。
Startupが、
大企業のCapabilityを利用する。
大企業が、
StartupのInnovationを取り込む。
⸻
Startup Speed
× Enterprise Scale
をつくる。
⸻
ここでは、
M&Aも重要になる。
Startupの成功を、
IPOだけで考えない。
大企業がStartupを買収する。
TechnologyをScaleする。
Founderが次のStartupへ進む。
⸻
Capitalと人材が、
次のFuture Potentialへ循環する。
⸻
大学との接続も必要である。
大学には、
まだ企業になっていないKnowledgeがある。
Research。
Patent。
Researcher。
Laboratory。
⸻
しかし、
研究成果が、
自動的にStartupになるわけではない。
Business。
Capital。
Management。
Regulation。
Market。
が必要になる。
⸻
大学とStartupの間に、
Translation Layerをつくる。
研究を、
Product Requirementへ変換する。
⸻
Research
→ Technology
→ Startup
→ Industry
この経路を短くする。
⸻
自治体も、
Startup Ecosystemへ参加できる。
地域課題を公開する。
Pilot環境を提供する。
地域Dataを適切に利用できるようにする。
公共調達で、
初期顧客になる。
⸻
すると、
地域そのものが、
Future TechnologyのTestbedになる。
⸻
高齢化。
人口減少。
Mobility。
Healthcare。
防災。
Agriculture。
日本の地域には、
世界が将来直面する可能性のある課題が、
先に現れている。
⸻
その課題を解くStartupが、
日本の地域で実証する。
成功すれば、
国内外へ展開する。
⸻
地域課題が、
Global Future Marketへの入口
になる。
⸻
中小企業とStartupを接続すると、
さらに大きな可能性が生まれる。
Startupには、
新しいDesignがある。
しかし、
製造Capabilityがない。
中小企業には、
製造Capabilityがある。
しかし、
新しい市場へのAccessが弱い。
⸻
両者をつなぐ。
⸻
Startupが、
未来を設計する。
中小企業が、
Physical Realityへ変える。
⸻
これは、
日本のManufacturing Potentialを、
新しい産業へ接続する有効な経路になる。
⸻
Startup
＋ SME
＝ New Industrial Capability
という関係である。
⸻
また、
AIは、
中小企業とStartupの両方のCapabilityを拡張する。
中小企業では、
翻訳。
営業。
Design。
受発注。
Knowledge検索。
Production Planning。
に使える。
⸻
Startupでは、
Software Development。
Research。
Marketing。
Customer Support。
Prototype。
少人数でも、
より広い業務を扱える。
⸻
AIによって、
企業規模とCapabilityの関係が変わる。
⸻
これまでは、
100人必要だった仕事を、
10人とAIで実行できる領域が増えるかもしれない。
その場合、
小さな企業でも、
より大きな市場へ挑戦できる。
⸻
ただし、
AIを導入するだけでは足りない。
Data。
Security。
業務Process。
人材。
が必要になる。
⸻
ここでも、
AIを目的にせず、
企業のImplementation Timeをどこまで短縮できるか
を見る。
⸻
中小企業・Startupには、
地域との関係もある。
大企業本社がなくても、
地域には、
中小企業がある。
起業家がいる。
大学がある。
金融機関がある。
⸻
これらを接続すれば、
地域は、
企業誘致だけに頼らず、
自ら新しい産業を生成できる。
⸻
地域金融が、
Potentialを発見する。
大学が、
Knowledgeを提供する。
中小企業が、
Manufacturingを担う。
Startupが、
新しい市場を開く。
自治体が、
実証を支える。
⸻
Local Future Ecosystem
が形成される。
⸻
ここでは、
東京と地方を、
対立させる必要もない。
地域でTechnologyをつくる。
東京でCapitalへ接続する。
海外市場へ出る。
東京のStartupが、
地方工場と連携する。
⸻
Networkとして考える。
⸻
未来産業は、
一つの中心から生まれない。
複数の地域。
大学。
企業。
Startup。
から、
分散して立ち上がる。
⸻
中小企業とStartupには、
異なる時間がある。
中小企業には、
蓄積時間がある。
Startupには、
探索時間がある。
⸻
一方は、
何十年もかけてCapabilityを蓄積する。
もう一方は、
数か月で仮説を試す。
⸻
Future Industryでは、
この二つの時間を、
どちらかへ統一しない。
Accumulated Capability
× Rapid Experimentation
として接続する。
⸻
長い時間で形成された技術を、
短い時間で新市場へ試す。
Startupの新しい仮説を、
中小企業の蓄積された能力で物質化する。
⸻
ここに、
日本独自のFuture Accelerationが生まれる可能性がある。
⸻
最小に整理すれば、
中小企業・StartupのFuture Pullは、
次の構造になる。
Existing Capability
＋ New Hypothesis
↓
Matching
↓
Prototype
↓
Capital
↓
Market Test
↓
Scale
↓
New Industrial Capability
⸻
重要なのは、
企業を守ることそのものでも、
Startup数を増やすことそのものでもない。
日本社会が、
既存Capabilityを失わず、新しいPotentialを継続的に試せる状態
をつくることである。
⸻
その状態ができれば、
産業は、
大企業だけから未来を待たなくなる。
地域企業からも。
大学発Startupからも。
若い起業家からも。
既存企業の事業承継からも。
未来が生まれる。
⸻
そして、
その複数の未来が、
製造。
AI。
Mobility。
Energy。
Healthcare。
Culture。
へ接続される。
⸻
中小企業は、
日本産業のMemoryを保持する。
Startupは、
日本産業のFuture Hypothesisを試す。
その二つが接続されたとき、
産業界は、
過去の蓄積を失わずに、
次のRealityを高速に生成できる。
⸻
次節では、
これまで見てきた、
製造業。
AI・Digital。
Mobility・Logistics。
Energy・Infrastructure。
中小企業・Startup。
を一つの産業Architectureとして統合する。
それが、
Generative Industry
である。
第7章 産業界
第7節 Generative Industry
ここまで、
製造業。
AI・Digital。
Mobility・Logistics。
Energy・Infrastructure。
中小企業・Startup。
を見てきた。
これらは別々の産業に見える。
しかし、
未来のRealityでは、
互いに分離して存在しない。
AIを動かすには、
半導体とEnergyが必要になる。
工場を動かすには、
物流とDigitalが必要になる。
Mobilityには、
製造、Software、Energy、Insuranceが必要になる。
StartupがScaleするには、
中小企業、大企業、金融、Infrastructureが必要になる。
未来産業とは、
産業間の接続によって成立するSystem
である。
⸻
本書では、
この接続された産業構造を、
Generative Industry
と呼ぶ。
⸻
Generative Industryとは、
単に新しい産業を増やすことではない。
既存産業をすべてDigital化することでもない。
AI企業を大量につくることでもない。
本質は、
Future Potentialを継続的にCapabilityへ変換し、新しいRealityを生み出し続ける産業構造
をつくることである。
⸻
従来の産業政策では、
業界単位で考えることが多かった。
自動車。
半導体。
鉄鋼。
化学。
情報通信。
医療。
しかし、
Future Stateから見ると、
業界境界は薄くなる。
⸻
たとえば、
Robot。
そこには、
Mechanical Engineering。
AI。
Sensor。
Semiconductor。
Battery。
Material。
Software。
Cloud。
通信。
が入る。
⸻
Medical Deviceなら、
Medicine。
Precision Manufacturing。
AI。
Data。
Sensor。
Regulation。
Insurance。
が接続する。
⸻
Future Industryは、
既存産業分類より先に、
Requirement Network
として現れる。
⸻
だから、
Generative Industryでは、
「何産業を育てるか」
より先に、
未来にどのCapabilityが必要なのかを見る。
⸻
Future Stateを置く。
そこから、
Capability Requirementを引く。
現在の産業Capabilityと比較する。
Gapを発見する。
不足部分へ、
研究。
人材。
Capital。
Technology。
Infrastructure。
を送る。
⸻
その構造は、
Future State
→ Capability Requirement
→ Industrial Gap
→ Investment
→ Implementation
→ New Capability
となる。
⸻
ここで重要なのは、
現在の企業を、
現在の業種へ固定しないことである。
企業の本質を、
ProductではなくCapabilityとして見る。
⸻
自動車企業。
ではなく、
大量生産。
Safety Engineering。
Material。
Motor。
Battery。
Software。
Supply Chain。
を持つ企業として見る。
⸻
精密加工企業。
ではなく、
Micron単位の加工Capabilityを持つ企業として見る。
⸻
すると、
現在の企業が、
未来の複数産業へ接続できる。
⸻
つまり、
Generative Industryとは、
企業を業種から解放し、Capabilityを未来Requirementへ再配置するArchitecture
でもある。
⸻
これは、
産業転換のCostを小さくできる。
すべてをゼロからつくらない。
すでに存在する設備。
人材。
Knowledge。
Supplier。
地域Network。
を再利用する。
⸻
未来実装時間を短縮する最も強い方法の一つは、
現在にすでに存在するものを未来から再発見すること
である。
⸻
Generative Industryには、
探索層が必要になる。
その役割を担うのが、
Startup。
大学。
研究機関。
新規事業。
である。
⸻
新しいTechnologyを試す。
新しい市場を試す。
新しいBusiness Modelを試す。
失敗する。
学ぶ。
また試す。
⸻
未来を一つに決めるのではなく、
複数のFuture Hypothesisを同時に走らせる。
⸻
Explore
の層である。
⸻
しかし、
探索だけでは産業にならない。
成功したTechnologyを、
大量に社会へ届ける必要がある。
ここで、
大企業。
中小企業。
金融。
物流。
Infrastructure。
が働く。
⸻
Scale
の層である。
⸻
Generative Industryは、
ExploreとScaleを接続する。
Startupが試す。
中小企業がPrototypeをつくる。
大企業がScaleする。
金融が資本を送る。
政府が制度を整える。
⸻
未来生成を、
一社の内部だけで完結させない。
⸻
このNetworkが強くなるほど、
未来実装時間は短くなる。
⸻
大学にTechnologyがある。
しかし企業へ届くまで五年。
Startupが成功した。
しかし大企業と接続するまで三年。
工場建設が決まった。
しかしEnergy Infrastructureで四年待つ。
⸻
この待ち時間を減らす。
⸻
Generative Industryでは、
未来Requirementが見えた時点から、
複数主体が並列に動く。
⸻
大学は研究する。
企業はProduct Designを始める。
政府は制度を検討する。
金融はCapitalを準備する。
地域は土地とInfrastructureを準備する。
人材育成も始める。
⸻
Sequential Industry
ではなく、
Parallel Industry
へ。
⸻
Future Accelerationの核心は、
ここにある。
⸻
Generative Industryには、
State Observationも必要になる。
現在、
日本にはどのCapabilityがあるのか。
どこに不足があるのか。
どこでSupply Chainが詰まっているのか。
どこへCapitalが流れているのか。
⸻
産業を、
年に一度の統計だけで見るのではない。
可能な範囲で、
継続的にStateを観測する。
⸻
企業。
工場。
研究。
Patent。
人材。
物流。
Energy。
Capital。
複数の情報から、
Industry Stateを更新する。
⸻
すると、
Future StateとのGapを、
継続的に確認できる。
⸻
Observe
→ Detect Gap
→ Invest
→ Implement
→ Verify
→ Update
産業そのものが、
Learning Cycleを持つ。
⸻
AI・Digitalは、
このCycleの共通知性になる。
AIが、
Demandを読む。
Researchを探索する。
CapabilityをMatchingする。
Supply Chain Riskを発見する。
設計を支援する。
⸻
しかし、
AIが産業を中央管理するわけではない。
企業は、
それぞれ異なる仮説を持つ。
市場は、
異なる判断を行う。
地域も、
異なるPotentialを持つ。
⸻
Generative Industryは、
一つの最適解へ収束するSystemではない。
複数のFuture Potentialを並列に試せるSystem
である。
⸻
その意味で、
競争はなくならない。
むしろ、
必要である。
異なる企業が、
異なるSolutionを試す。
市場が評価する。
利用者が選ぶ。
⸻
ただし、
すべてを競争させる必要もない。
Energy Grid。
通信。
Data Standard。
物流拠点。
Research Infrastructure。
共通化したほうが効率的な基盤もある。
⸻
だから、
Generative Industryでは、
Shared Infrastructure
＋ Competitive Innovation
を使い分ける。
⸻
共通基盤では協調する。
その上で、
ProductとServiceでは競争する。
⸻
これは、
産業全体のImplementation Costを下げる。
⸻
Generative Industryには、
地域も組み込まれる。
未来産業を、
東京だけへ集中させる必要はない。
⸻
製造Capabilityは、
地域に分散している。
Energy Potentialも、
地域によって異なる。
大学もある。
医療機関もある。
文化もある。
⸻
地域ごとに、
異なるFuture Industryを実装する。
⸻
ある地域は、
Semiconductor。
ある地域は、
Healthcare。
ある地域は、
Energy。
ある地域は、
Mobility。
ある地域は、
Creative Industry。
⸻
そして、
地域同士をNetwork化する。
⸻
全国を、
同じ産業構造へ揃えない。
異なるCapabilityを持つ地域が、相互に接続される産業国家
をつくる。
⸻
これによって、
Resilienceも高まる。
一つの地域が止まっても、
他地域が補完できる。
⸻
もちろん、
すべてを分散すればよいわけではない。
Scale Meritが大きいものは集中する。
分散したほうが強いものは分散する。
⸻
Future Stateから、
集中と分散を選ぶ。
⸻
Global Networkとの接続も必要になる。
日本だけで、
すべてのTechnologyや資源を持つことはできない。
⸻
海外Technologyを使う。
海外Capitalを受け入れる。
海外企業と共同研究する。
海外市場へProductを出す。
⸻
同時に、
Critical Capabilityは、
どこへ依存しているのかを見る。
⸻
Global Openness
＋ Strategic Capability
を両立する。
⸻
Generative Industryは、
閉じた国内産業ではない。
世界のPotentialを取り込み、
日本のCapabilityを世界へ出す。
⸻
Capitalも循環する。
投資する。
Capabilityが生まれる。
Productが生まれる。
Profitが生まれる。
⸻
そのProfitを、
次のResearchへ。
Startupへ。
人材へ。
Infrastructureへ。
再投資する。
⸻
Capital
→ Capability
→ Value
→ Return
→ Reinvestment
ここで、
第6章の生成資本と、
Generative Industryが一つになる。
⸻
資本が未来を選ぶ。
産業が未来をRealityへ変える。
Realityが、
次の資本を生む。
⸻
この循環が強くなれば、
日本の未来実装は、
一回の大型政策や一企業の成功へ依存しなくなる。
⸻
未来が、
複数の場所から、
継続的に生まれる。
⸻
Generative Industryには、
人材循環も必要である。
大学から企業へ。
大企業からStartupへ。
Startupから大学へ。
地域企業から新産業へ。
⸻
人材が移動すれば、
Knowledgeも移動する。
⸻
企業を越えて、
Capabilityが循環する。
⸻
終身的に一つの組織へ固定されるだけではなく、
複数の組織を通じて、
未来産業をつくる人材が育つ。
⸻
これは、
企業を弱くすることではない。
日本全体のIndustry Networkを強くする。
⸻
そして、
Generative Industryの評価方法も変わる。
GDP。
売上。
利益。
輸出。
これらは重要である。
しかし、
Future Pullでは、
さらに見る。
⸻
新しいCapabilityが増えたか。
新しい企業が生まれたか。
研究が産業へ移ったか。
人材が育ったか。
Critical Dependencyが減ったか。
未来実装時間が短くなったか。
⸻
つまり、
産業の価値を、
Current OutputだけでなくFuture Capacity
で見る。
⸻
これは、
現在の利益を軽視するという意味ではない。
利益がなければ、
企業は継続できない。
しかし、
現在利益だけを最大化し、
未来Capabilityを失えば、
長期的な産業力は弱くなる。
⸻
現在収益。
未来投資。
両方を持つ。
⸻
Operate Today
＋ Build Tomorrow
この二つを並列で行う。
⸻
最小に整理すると、
Generative Industryは、
次の構造になる。
Future Potential
↓
Future State
↓
Capability Requirement
↓
Research / Capital / Human Resources / Infrastructure
↓
Startup / SME / Enterprise
↓
Parallel Implementation
↓
Product / Service / Industrial Capability
↓
Market / Society
↓
Return / Knowledge
↓
New Future Potential
⸻
ここで、
産業は、
現在の需要へ反応するだけのSystemではなくなる。
未来Requirementを現在へ引き、
自ら次の市場とCapabilityをつくるSystemになる。
⸻
製造業が、
物質へ変える。
AI・Digitalが、
知性を加える。
Mobility・Logisticsが、
現実空間を接続する。
Energy・Infrastructureが、
社会を動かす。
中小企業が、
蓄積されたCapabilityを保持する。
Startupが、
新しいPotentialを探索する。
⸻
そして、
それらすべてが接続されたとき、
Generative Industry
が成立する。
⸻
産業は、
未来を待たない。
未来を予測するだけでもない。
Future Stateから必要なCapabilityを読み、
現在からResearch、Capital、Technology、人材を動かす。
⸻
未来を、
Productへ。
Serviceへ。
Infrastructureへ。
そして、
日常のRealityへ変える。
⸻
しかし、
産業がどれほど進化しても、
最終的に未来を受け取るのは、
人間である。
そして、
人間にとって最も基本的なFuture Stateの一つは、
生きること。
健康であること。
必要な治療へ到達できることである。
⸻
産業の未来生成能力は、
次に、
生命そのものへ接続される。
第8章では、
病院。
医師・医療者。
Healthcare。
医薬・製薬。
創薬AI。
生成医療。
を通じて、
未来実装時間を、
生命時間
から再設計する。
ここから、
Future Pullは、
産業の未来から、
生命の未来へ進む。
第8章 医療・Healthcare・医薬
第1節 生命から未来を設計する
産業が、
未来をProductやServiceへ変換するなら、
医療・Healthcare・医薬が扱うのは、
さらに根本的な対象である。
生命
である。
人が生きる。
成長する。
病気になる。
回復する。
老いる。
そして死ぬ。
医療は、
この生命時間へ直接介入する。
だから、
医療の未来を設計するとき、
Technologyや市場だけを起点にすることはできない。
まず、
生命側からFuture Stateを置く必要がある。
⸻
従来の医療は、
病気が発生した後に、
診断し、
治療することを中心に発展してきた。
これは、
これからも医療の中核である。
しかし、
Future Pullから見ると、
時間軸をさらに前へ動かすことができる。
病気になってから治療する。
その前に、
早期発見する。
さらに前に、
Riskを知る。
そして、
可能なものについては、
病気になる確率そのものを下げる。
⸻
Treatment
← Early Detection
← Prevention
← Health
医療時間を、
疾病発生後から、
疾病発生前へ広げる。
⸻
これは、
治療を不要にするという意味ではない。
治療。
予防。
健康維持。
すべてを一つの生命時間として接続する。
⸻
Future Healthcareの中心に置くべき問いは、
「病院をどれだけ増やすか」
ではない。
「薬をどれだけ開発するか」
だけでもない。
問うべきなのは、
人が生涯を通じて、必要なときに必要な支援へ到達できる状態とは何か
である。
⸻
そこから、
Healthcare Future Stateを置く。
必要な医療へ、
地域にかかわらずAccessできる。
病気を、
可能な範囲で早期に発見できる。
治療法を、
患者の状態に合わせて選べる。
医療者が、
過度な事務負担ではなく、
患者へ時間を使える。
⸻
さらに、
医療と介護。
医療と薬局。
医療と生活。
医療と予防。
Dataが、
適切なConsentとSecurityのもとで接続される。
こうした状態を、
先にFuture Stateとして置く。
⸻
すると、
現在とのGapが見える。
地域による医療Accessの差。
医療者不足。
病院間のData分断。
長い事務Process。
創薬に必要な長い時間とCost。
予防と治療の分断。
⸻
これらを、
単に「医療問題」と呼ばず、
Requirementへ変換する。
⸻
医師を何人増やすのか。
だけではない。
どの業務を医師が担うべきなのか。
看護師。
薬剤師。
他の医療職。
AI。
それぞれへ何を分担できるのか。
⸻
つまり、
未来医療では、
人員数だけでなく、
医療Capabilityの配置
を見る。
⸻
医師が、
書類作成へ時間を使う。
看護師が、
重複入力へ時間を使う。
薬剤師が、
情報探索へ時間を使う。
こうした時間を、
Technologyによって減らせるなら、
新しい医療者をゼロから育てなくても、
既存の医療Capabilityを患者側へ戻せる。
⸻
これは、
生命時間を短縮するのではない。
医療者の周囲にある不要な時間を削る
ことである。
⸻
Future PullにおけるHealthcareでは、
この違いが重要になる。
診断には、
必要な時間がある。
患者との対話にも、
必要な時間がある。
Clinical Trialにも、
必要な時間がある。
薬の安全性確認にも、
必要な時間がある。
⸻
これらまで高速化の対象にしてはいけない。
生命を扱う領域では、
慎重さそのものに価値がある。
⸻
だから、
未来医療の時間設計は、
単純なSpeedではない。
必要時間を守り、不要な待ち時間を減らす。
⸻
たとえば、
患者が専門医へ到達するまでの待ち時間。
病院間で情報を取り寄せる時間。
書類を転記する時間。
研究者が必要なDataを準備する時間。
⸻
こうした周辺時間を短縮すれば、
医療の安全性を損なわず、
Implementation Timeを前へ引ける。
⸻
ここで、
DigitalとAIが入る。
患者Dataを整理する。
画像診断を支援する。
医療Knowledgeを検索する。
事務作業を支援する。
創薬候補を探索する。
⸻
しかし、
AIが医療そのものになるわけではない。
医療には、
身体を見ること。
患者の言葉を聞くこと。
不確実性の中で判断すること。
倫理的な選択。
がある。
⸻
だから、
Future Healthcareでは、
Human Care
＋ Medical Science
＋ AI
として設計する。
⸻
AIは、
医療者を置き換えるためではなく、
医療者のCapabilityを拡張する。
医療者は、
患者との関係。
最終判断。
責任。
を持つ。
⸻
生命Dataには、
特に慎重なGovernanceが必要になる。
健康情報。
遺伝情報。
診療記録。
これらは、
極めて個人的な情報である。
⸻
研究に利用すれば、
新しい治療法につながる可能性がある。
しかし、
利用者本人の権利を無視してはいけない。
Consent。
Privacy。
Security。
Access Control。
Audit。
⸻
Future Healthcareは、
Data利用と人間の権利を対立させない。
TrustをInfrastructureとして設計する。
⸻
Trustがなければ、
患者はDataを提供しなくなる。
医療者もSystemを使わない。
結果として、
Innovation自体が遅れる。
⸻
つまり、
倫理やPrivacyは、
未来実装の障害ではない。
持続的な未来実装を可能にするRequirement
である。
⸻
医療Future Stateには、
地域も重要になる。
高度医療のすべてを、
すべての地域へ配置することは難しい。
しかし、
必要な医療へ到達できる状態は設計できる。
⸻
地域診療所。
中核病院。
高度専門病院。
Remote Healthcare。
Mobility。
救急搬送。
それぞれをNetwork化する。
⸻
一施設の能力だけではなく、
地域医療Network全体のCapability
を見る。
⸻
これによって、
「病院が地域にあるか」
から、
「必要な医療へ到達できるか」
へ評価基準を変える。
⸻
Healthcareは、
病院の外にも広がる。
家庭。
職場。
学校。
地域。
日常生活。
人は、
一年のほとんどを病院の外で過ごす。
⸻
睡眠。
食事。
運動。
Mental Well-being。
社会的つながり。
生活環境。
こうした日常の状態が、
長期的な健康に関係する。
⸻
だから、
未来のHealthcareは、
医療機関だけのSystemではない。
生活と医療を接続するSystem
になる。
⸻
Wearable。
Health App。
Remote Monitoring。
AI。
これらは、
医療と日常の間をつなぐ可能性を持つ。
⸻
ただし、
人間を常時監視する社会にしてはいけない。
利用するかどうか。
誰と共有するか。
本人が選択できることが重要である。
⸻
Future Healthcareは、
健康を国家や企業が管理するSystemではない。
人が自分の生命について、より多くの選択肢を持てるSystem
である。
⸻
医薬にも、
Future Pullがある。
新しい薬が必要になる。
しかし、
創薬には時間がかかる。
⸻
Target探索。
候補化合物。
非臨床。
Clinical Trial。
承認。
製造。
市場へ届くまで、
長いProcessがある。
⸻
この時間を、
すべて単純に短くすることはできない。
安全性確認は必要である。
一方、
AIによって、
候補探索や研究設計を支援できる可能性がある。
Data Infrastructureによって、
Clinical Researchの準備時間を減らせる可能性もある。
⸻
つまり、
創薬でも、
Safety TimeとAdministrative Timeを分ける。
必要な生命時間は守る。
不要なProcess Timeは削る。
⸻
ここに、
創薬AIの意味がある。
AIによって、
無限に近い候補の中から、
有望なものを早く探索する。
研究者の仮説生成を支援する。
⸻
しかし、
AIが見つけた候補も、
最終的には現実の生命で検証しなければならない。
⸻
AI Exploration
→ Biological Verification
→ Clinical Verification
Digitalから生命へ移るたびに、
Verificationが必要になる。
⸻
この慎重な接続が、
Generative Healthcareの基本になる。
⸻
医療には、
Capitalも必要である。
病院Infrastructure。
研究。
創薬。
Medical Device。
Healthcare Startup。
大きな資本と長い時間が必要になる領域がある。
⸻
だから、
第6章のFuture Capital Architectureを、
生命時間へ合わせる。
短期Returnだけで、
創薬研究を評価しない。
一方、
永続的に資本を投入するだけでもない。
⸻
Research Stage。
Clinical Stage。
Scale Stage。
それぞれに、
適切なCapitalを接続する。
⸻
Life Time
↔ Capital Time
を合わせる。
⸻
さらに、
医療のFuture Stateは、
産業成長だけでは測れない。
医療市場が拡大した。
薬の売上が増えた。
それだけで、
生命が良くなったとは限らない。
⸻
最終的に見るべきなのは、
Health Outcome。
Quality of Life。
Access。
Safety。
医療者の持続可能性。
患者の選択。
⸻
つまり、
Healthcareでは、
Industry OutputよりLife Outcome
を上位に置く。
⸻
これによって、
産業と生命の関係が逆転しない。
生命のために、
産業がある。
⸻
しかし、
生命を守るだけが未来ではない。
医療Technologyが進歩すれば、
これまで治療できなかった病気を治せるかもしれない。
失われた機能を回復できるかもしれない。
健康に生きられる時間を延ばせるかもしれない。
⸻
Future Healthcareには、
生命Capabilityを拡張するPotential
もある。
⸻
ここで、
治療中心の医療から、
生命を継続的に支えるHealthcareへ視野が広がる。
⸻
その最小構造は、
次のようになる。
Life State
→ Future Health State
→ Gap
→ Medical / Healthcare Requirement
→ Research / AI / Capital / Human Care
→ Implementation
→ Health Outcome
→ New Life State
⸻
生命を観測する。
未来の健康状態を置く。
必要な医療を引く。
実装する。
結果を見る。
再び更新する。
⸻
しかし、
生命はMachineではない。
同じ治療でも、
すべての人が同じ結果になるとは限らない。
不確実性がある。
個人差がある。
⸻
だから、
医療Future Stateを、
完全制御として設計してはいけない。
必要なのは、
より良い選択肢を増やすこと
である。
⸻
治療法が一つしかない状態から、
複数の選択肢へ。
病気になってからしか分からない状態から、
早期にRiskを知れる状態へ。
地域によって医療へ届かない状態から、
複数のAccess方法を持つ状態へ。
⸻
未来医療とは、
生命を完全に管理することではない。
生命が、
より多くの可能性を持つことである。
⸻
だから、
「生命から未来を設計する」とは、
Technologyから生命を見ることではない。
生命にとって必要なFuture Stateから、Technology、医療、医薬、制度、資本を逆算すること
である。
⸻
産業界では、
Future RequirementからCapabilityを引いた。
Healthcareでは、
さらに深く、
生命Requirementから社会Systemを引く。
⸻
人が健康に生きられる。
必要な医療へ届く。
安全な治療を選べる。
医療者が持続的に働ける。
研究が次の治療へつながる。
⸻
このFuture Stateを先に置く。
そこから、
現在の病院。
医療者。
Healthcare。
製薬。
AI。
制度。
Capital。
を再配置する。
⸻
ここから第8章では、
生命を中心として、
医療Systemを具体的に分解していく。
まず、
医療がRealityとして最も明確に現れる場所。
患者が訪れ、
医療者が働き、
Technologyと生命が出会う場所。
次節では、
病院・診療所
から未来を引いていく。
第8章 医療・Healthcare・医薬
第2節 病院・診療所
医療のFuture Stateが、
最も具体的なRealityとして現れる場所。
それが、
病院と診療所
である。
患者が訪れる。
医師が診察する。
看護師がケアする。
検査を行う。
薬を処方する。
手術を行う。
生命と医療Technologyが、
実際に出会う場所である。
だから、
未来医療を考えるとき、
病院・診療所を単なる施設として見るだけでは足りない。
生命を支える医療Capabilityの実装拠点
として見る必要がある。
⸻
Future Pullから最初に問うべきなのは、
病院を何棟増やすかではない。
病床を何床持つかでもない。
重要なのは、
人が必要な医療へ、
必要な時間内に到達できるかである。
⸻
つまり、
Future Stateは、
Facility StateではなくAccess State
として置く。
高度な医療が必要なら、
高度医療へ届く。
日常的な診療なら、
地域で受けられる。
救急なら、
必要な時間内に対応される。
継続治療なら、
生活と接続しながら続けられる。
⸻
このFuture Stateから、
病院と診療所の役割を逆算する。
すべての医療機関が、
同じ機能を持つ必要はない。
地域診療所。
一般病院。
地域中核病院。
高度専門病院。
それぞれが、
異なるCapabilityを持つ。
⸻
重要なのは、
一施設ですべてを完結させることではない。
医療機関同士をNetworkとして接続すること
である。
⸻
診療所で、
初期診断を行う。
必要なら、
専門病院へ紹介する。
治療後は、
地域へ戻る。
在宅医療。
薬局。
介護。
とも接続する。
⸻
患者から見れば、
医療制度の組織境界は重要ではない。
重要なのは、
治療が途切れないことである。
⸻
だから、
未来の病院Architectureでは、
Hospital OptimizationからCare Network Optimizationへ
視点を広げる。
⸻
ここで、
Dataが重要になる。
患者が、
病院を移る。
診療科を移る。
地域へ戻る。
そのたびに、
必要な情報が途切れれば、
同じ検査を繰り返す。
同じ説明を繰り返す。
医療者が、
過去の状態を確認するために時間を使う。
⸻
これは、
生命に必要な時間ではない。
System分断によって生まれる、
Information Waiting Time
である。
⸻
Future Pullでは、
この時間を減らす。
診療記録。
検査。
薬。
Allergy。
画像。
必要な情報を、
適切な権限とConsentのもとで利用できるようにする。
⸻
すべてのDataを、
一つの巨大Databaseへ集める必要はない。
病院がDataを保持したまま、
必要な情報を、
必要な主体が安全に参照できればよい。
⸻
Distributed Data
＋ Interoperability
である。
⸻
これによって、
患者は、
施設を移っても、
医療の連続性を保ちやすくなる。
⸻
病院内部にも、
大量の時間がある。
受付。
問診。
検査待ち。
診察待ち。
会計。
薬。
Bed Management。
手術室調整。
退院調整。
⸻
医療の質を落とさず、
これらのProcess Timeを短縮できれば、
患者の負担も、
医療者の負担も減らせる。
⸻
ここで、
AI・Digitalを使う。
予約を最適化する。
問診を事前入力する。
診療記録作成を支援する。
検査結果を整理する。
Bedの利用状況を把握する。
退院先調整を支援する。
⸻
AIの目的は、
病院を無人化することではない。
医療者と患者の時間を、医療そのものへ戻すこと
である。
⸻
医師が、
Keyboardを見る時間を減らす。
看護師が、
重複入力する時間を減らす。
薬剤師が、
情報を探す時間を減らす。
⸻
その分、
患者を見る。
話を聞く。
状態を確認する。
判断する。
⸻
Future Hospitalでは、
Technologyが人間関係を減らすのではなく、
TechnologyによってHuman Careの時間を増やす
という方向が重要になる。
⸻
診療所では、
さらに別の役割がある。
地域の患者を、
長い時間見ることができる。
病気だけではなく、
家族。
生活。
仕事。
高齢化。
地域環境。
まで知る。
⸻
この継続性は、
高度専門病院とは異なるCapabilityである。
⸻
Future Healthcareでは、
専門医療だけでなく、
Continuity of Care
が重要になる。
⸻
慢性疾患。
高齢者医療。
予防。
生活習慣。
継続的な健康管理では、
地域診療所の役割が大きい。
⸻
だから、
病院か診療所か、
どちらが重要かという問いではない。
両者が、
異なる時間を持っている。
⸻
病院には、
高度医療の時間がある。
診療所には、
生活を継続的に見る時間がある。
⸻
この二つを、
一人の患者の生命時間に沿って接続する。
⸻
Primary Care
→ Specialized Care
→ Treatment
→ Recovery
→ Community Care
一方向ではなく、
必要に応じて往復する。
⸻
Remote Healthcareも、
このNetworkへ入る。
すべての診療を、
Remoteへ移す必要はない。
身体診察が必要な場合。
検査が必要な場合。
緊急性が高い場合。
対面が必要になる。
⸻
一方、
経過確認。
相談。
一部の慢性疾患管理。
服薬確認。
など、
Remoteで対応できる場面もある。
⸻
Future Hospitalは、
PhysicalかDigitalかという二択ではない。
患者状態に応じて最適なInterfaceを選ぶ。
⸻
対面。
Remote。
在宅。
地域施設。
複数のAccess Channelを持つ。
⸻
これによって、
地域距離の一部を縮められる。
⸻
しかし、
地域医療のすべてをDigitalで解決することはできない。
救急。
手術。
画像検査。
入院。
Physical Capabilityが必要になる。
⸻
だから、
どのCapabilityを地域に置き、
どのCapabilityを広域で共有するかを設計する。
⸻
ここで、
Mobilityが接続する。
患者が病院へ行く。
救急車が運ぶ。
医療者が地域へ移動する。
薬や医療物資が届く。
⸻
Medical Accessは、
病院配置だけではなく、
Hospital
＋ Mobility
＋ Digital
によって決まる。
⸻
人口減少地域では、
この接続が特に重要になる。
現在ある施設を、
すべて同じ形で維持することが難しくなる可能性がある。
⸻
Future Pullでは、
施設を守ることから始めない。
地域住民に必要な医療Capabilityを守る。
そのために、
施設配置を変える。
Network化する。
Digitalを使う。
Mobilityを使う。
⸻
つまり、
Hospital PreservationではなくHealthcare Capability Preservation
へ視点を変える。
⸻
病院には、
Infrastructureとしての側面もある。
電力。
水。
通信。
医療Gas。
薬。
食料。
Medical Device。
災害時にも、
止めにくい施設である。
⸻
だから、
Future Hospitalには、
Resilienceが必要になる。
Backup Power。
通信。
Supply Stock。
Cybersecurity。
Disaster Plan。
⸻
特に、
医療SystemがDigital化するほど、
Cybersecurityは、
生命Safetyの一部になる。
⸻
Electronic Medical Recordが停止する。
Networkが使えない。
Medical Deviceが攻撃される。
こうしたRiskは、
IT部門だけの問題ではない。
⸻
Digital Safety = Patient Safety
として設計する。
⸻
病院の建物にも、
長い時間がある。
建設すれば、
何十年も使う。
だから、
現在の医療だけを前提として設計すると、
Technology変化へ対応しにくい。
⸻
Future Infrastructureとしては、
用途変更できる。
設備を交換できる。
Digital Technologyを追加できる。
感染症や災害時に空間を再構成できる。
⸻
Adaptability
を持たせる。
⸻
病院を、
完成した建物ではなく、
医療変化へ対応できるPlatformとして考える。
⸻
病院経営にも、
Future Pullが必要になる。
病院が持続しなければ、
医療Capabilityも維持できない。
⸻
しかし、
経営効率だけを優先すれば、
地域に必要な医療が失われる場合もある。
反対に、
すべてを維持し続ければ、
財務的に持続できない。
⸻
必要なのは、
Medical Value
＋ Operational Sustainability
の両立である。
⸻
どの機能を、
どこへ集中するか。
どの機能を、
地域へ分散するか。
どこを共同化するか。
⸻
病院同士で、
すべてを競争させる必要はない。
高額設備。
Specialist。
Data Infrastructure。
共同利用できる部分もある。
⸻
Shared Medical Infrastructure
＋ Distributed Care
というArchitectureを考える。
⸻
これによって、
地域全体の医療Capabilityを高める。
⸻
病院と大学の接続も重要になる。
医療現場には、
新しいResearch Questionが生まれる。
大学には、
Scienceがある。
⸻
患者のRealityから、
研究課題を発見する。
研究成果を、
病院で検証する。
⸻
Clinical Reality
→ Research
→ Innovation
→ Clinical Reality
この循環を短くする。
⸻
病院は、
治療施設であると同時に、
Medical Innovationの実装地点でもある。
⸻
ただし、
患者を単なるResearch Resourceとして扱ってはいけない。
Consent。
Ethics。
Safety。
が必要になる。
⸻
生命研究ほど、
Trustが重要になる。
⸻
病院と企業の関係も変わる。
Medical Device。
AI。
薬。
Digital Health。
新しいTechnologyを、
病院で実証する。
⸻
しかし、
Technology企業だけで医療を設計しない。
医療者。
患者。
病院Operations。
Regulator。
と共同で設計する。
⸻
Clinical Co-design
によって、
現場で使えるTechnologyへ変える。
⸻
これによって、
「Technologyはあるが使われない」
というGapを減らせる。
⸻
病院・診療所には、
Healthcare Dataが蓄積される。
このDataから、
新しいKnowledgeが生まれる可能性がある。
治療効果。
副作用。
疾患Pattern。
地域差。
⸻
しかし、
Dataは患者から預かっている。
だから、
利用には明確なRuleが必要になる。
⸻
誰が使うのか。
何の目的か。
どの範囲か。
患者は知ることができるか。
利用を拒否できるか。
⸻
Future Hospitalでは、
Data Governanceを、
研究の後処理ではなく、
Hospital Architectureの基本機能
として持つ。
⸻
病院・診療所のFuture Stateを、
最小に整理すると、
五つのCapabilityがある。
Access。
必要な医療へ到達できる。
Continuity。
医療機関を越えて治療がつながる。
Quality。
安全で適切な医療が提供される。
Sustainability。
医療者と施設が持続できる。
そして、
Learning。
医療Realityから次の医療を改善できる。
⸻
その循環は、
Patient State
→ Care
→ Treatment
→ Outcome
→ Data / Knowledge
→ Improved Care
となる。
⸻
Future Hospitalとは、
未来Technologyを大量に置いた病院ではない。
患者の生命時間に沿って、
必要な医療Capabilityが、
途切れず接続される病院Systemである。
⸻
診療所も、
小さな病院ではない。
生活に近い場所で、
長い生命時間を観測し、
必要な医療へ接続するNodeである。
⸻
病院は、
高度Capabilityを持つ。
診療所は、
生活との連続性を持つ。
両者がNetwork化されることで、
Healthcareは、
施設中心から生命中心へ移る。
⸻
Future Pullは、
病院を未来化することではない。
生命に必要な医療を未来側から定義し、その医療が現在のどこで、どのように提供されるべきかを再設計すること
である。
⸻
そして、
この病院・診療所を実際に動かしているのは、
建物でも、
AIでも、
Medical Deviceでもない。
患者を診る。
判断する。
治療する。
支える。
生命と直接向き合う人々である。
次節では、
未来Healthcareの中核主体として、
医師・医療者
を見ていく。
第8章 医療・Healthcare・医薬
第3節 医師・医療者
医療を動かしているのは、
病院という建物ではない。
医師。
看護師。
薬剤師。
臨床検査技師。
診療放射線技師。
リハビリテーション職。
救急救命士。
介護職。
そして、
多くの医療専門職である。
未来医療を設計するとき、
Technologyだけを見ることはできない。
生命と直接向き合う人間のCapability
を中心に置く必要がある。
⸻
Future Pullから見ると、
医療者不足という問題も、
人数だけでは捉えきれない。
何人いるのか。
どこにいるのか。
何の専門性を持つのか。
どの仕事へ時間を使っているのか。
その全体を見る。
⸻
たとえば、
医師が不足しているとする。
しかし、
医師の時間の一部が、
文書作成。
入力。
予約調整。
情報検索。
事務手続き。
に使われているなら、
不足しているのは、
医師数だけではない。
医師時間の配置
にもGapがある。
⸻
Future Healthcareでは、
この時間を再設計する。
医師にしかできない仕事。
他職種へ移せる仕事。
AIやDigitalへ任せられる仕事。
を分ける。
⸻
Human Judgment
＋ Team Medicine
＋ AI Support
として、
医療Capabilityを再配置する。
⸻
重要なのは、
医療者を減らすことではない。
医療者が、
最も価値を生む場所へ時間を戻すことである。
⸻
患者を見る。
話を聞く。
身体を診る。
不確実な状況で判断する。
治療方針を説明する。
患者と家族の意思を確認する。
こうした仕事には、
人間の時間が必要である。
⸻
だから、
AI導入によって目指すべきなのは、
人間を医療から消すことではなく、人間にしかできない医療を増やすこと
である。
⸻
医師の役割も、
Knowledgeを記憶していることだけではなくなる。
医学Knowledgeは、
増え続ける。
一人の医師が、
すべてを記憶することはできない。
⸻
AIが、
文献を探す。
Guidelineを検索する。
薬剤情報を確認する。
診療記録を整理する。
画像診断を支援する。
⸻
すると、
医師の価値は、
情報を持っていることだけから、
情報を患者のRealityへ翻訳して判断すること
へ移る。
⸻
同じ病名でも、
患者は違う。
年齢。
身体状態。
生活。
仕事。
家族。
価値観。
治療への希望。
⸻
医学的に可能な治療と、
その人にとって望ましい治療が、
常に同じとは限らない。
⸻
ここに、
医療者の重要な役割が残る。
Scienceを、
一人の生命へ翻訳する。
⸻
Future Healthcareでは、
この能力がさらに重要になる。
治療選択肢が増えるからである。
薬。
手術。
遺伝子関連Technology。
Digital Therapeutics。
Remote Care。
予防。
多くのOptionがある。
⸻
選択肢が増えるほど、
患者は、
何を選べばよいか分からなくなる。
だから、
医療者は、
単なるTreatment Providerではなく、
Life Decision Partner
としての役割も持つ。
⸻
しかし、
医療者一人へ、
すべての責任を集中させることもできない。
未来医療は、
より複雑になる。
⸻
だから、
Team Medicineが重要になる。
医師。
看護師。
薬剤師。
栄養。
リハビリ。
心理。
介護。
Social Worker。
⸻
患者の状態に応じて、
複数の専門性を接続する。
⸻
一人のSuper Doctorを中心にするのではなく、
Distributed Medical Intelligence
として医療Teamを設計する。
⸻
ここでは、
職種間の情報共有が不可欠になる。
医師が知っていること。
看護師が観察したこと。
薬剤師が把握している薬の状態。
介護職が知る生活状態。
⸻
これらが分断されれば、
患者全体が見えない。
⸻
Future Healthcareでは、
Dataを、
職種間の共通言語として使う。
ただし、
Dataだけですべてを理解できるわけではない。
⸻
数字にならない情報もある。
患者の表情。
家族関係。
生活の変化。
「何となくいつもと違う」
という現場感覚。
⸻
だから、
Data IntelligenceとClinical Experience
を接続する。
⸻
看護師の役割も大きい。
患者の近くで、
状態変化を継続的に見る。
Treatmentだけでなく、
生活。
不安。
痛み。
回復。
を観察する。
⸻
未来医療でTechnologyが増えるほど、
このHuman Observationの価値は、
むしろ高くなる可能性がある。
⸻
Sensorが、
心拍を測る。
AIが、
異常を検知する。
しかし、
患者が何を感じているのか。
その変化が本人にとって何を意味するのか。
そこには、
人間によるCareが必要になる。
⸻
未来医療では、
MeasurementとCareを分離しない。
⸻
薬剤師も、
薬を渡すだけではない。
複数薬剤。
副作用。
服薬状況。
患者の生活。
医薬品が高度化するほど、
Medication Managementの重要性が増す。
⸻
AIは、
薬剤情報を確認できる。
相互作用を検知できる。
しかし、
患者が実際に服薬できているか。
生活上の問題があるか。
そこを見るのは、
医療者である。
⸻
各職種の専門性を、
AIによって弱めるのではない。
AIによって専門性をより深く使える状態へする。
⸻
ここで、
Task ShiftとTask Shareが重要になる。
医療者不足に対して、
すべてを新規人材採用だけで解決することは難しい。
⸻
誰が何を担うかを見直す。
医師に集中している業務を、
適切な教育と制度のもとで、
他職種へ移せる場合がある。
⸻
また、
複数職種が共同で担うこともできる。
⸻
重要なのは、
Cost削減ではなく、
医療Capability全体の最適配置
である。
⸻
地域医療では、
この考え方がさらに重要になる。
都市には専門医が多い。
地域には少ない。
すべての専門医を、
すべての地域へ配置することは難しい。
⸻
そこで、
地域医療者と専門医をDigitalで接続する。
Remote Consultation。
画像共有。
Clinical Support。
⸻
地域の医師が、
すべての専門性を持つ必要はない。
必要なときに、
専門KnowledgeへAccessできる。
⸻
つまり、
人材配置を、
Physical Locationだけで考えない。
Medical Knowledge Network
として考える。
⸻
それでも、
身体を診る人は地域に必要である。
だから、
DigitalとLocal Human Presenceを組み合わせる。
⸻
Future Healthcareでは、
医療人材を、
施設へ固定されたResourceとしてだけ見ない。
NetworkのNodeとして見る。
⸻
教育も変わる。
医学Knowledgeの更新速度は速い。
医療者は、
資格取得時に学んだ知識だけで、
生涯働くことはできない。
⸻
Continuing Education。
Simulation。
Digital Learning。
AI Tutor。
を使い、
継続的にKnowledgeを更新する。
⸻
Future Medical Professionalとは、
すべてを知っている人ではない。
新しいKnowledgeを継続的に取り込み、患者へ適切に使える人
である。
⸻
AI Literacyも必要になる。
AIを使える。
だけでは足りない。
AIが間違えることを知る。
Outputを検証する。
Data Biasを理解する。
AIを使うべきでない場面を判断する。
⸻
つまり、
AI時代の医療者には、
Clinical Judgmentに加えてAI Judgment
が必要になる。
⸻
AIを信じすぎない。
拒否しすぎない。
使えるところで使い、
最終責任を理解する。
⸻
この能力は、
医療安全の一部になる。
⸻
医療者の働き方も、
Future Stateとして置く必要がある。
患者の健康を守るために、
医療者が持続不能な状態で働くことは、
長期的には成立しない。
⸻
過度な長時間労働。
夜間負担。
事務負担。
人員不足。
Burnout。
⸻
医療者のSustainabilityは、
福利厚生の問題だけではない。
Healthcare SystemのResilience
そのものである。
⸻
医療者が疲弊すれば、
Safety。
Quality。
Continuity。
すべてへ影響する。
⸻
だから、
Future Healthcareでは、
患者Outcomeと同時に、
Medical Workforce Stateを見る。
⸻
勤務時間。
業務構成。
休息。
Training。
心理的負担。
離職。
⸻
医療者のStateを継続的に観測する。
⸻
ここでも、
AI・Automationの価値を、
「人を減らせたか」ではなく、
医療者の持続可能性を高めたか
で評価する。
⸻
また、
医療者には、
研究者としての役割もある。
Clinical Realityには、
研究室だけでは見えないQuestionがある。
なぜこの患者には効かなかったのか。
なぜ副作用が起きたのか。
地域で疾患Patternが違うのか。
⸻
医療者が、
Clinical Questionを研究へ返す。
大学や企業が研究する。
結果が再び医療現場へ戻る。
⸻
Clinical Practice
→ Question
→ Research
→ Knowledge
→ Clinical Practice
この循環を短くする。
⸻
これによって、
病院は、
Knowledgeを使う場所だけではなく、
Knowledgeを生成する場所になる。
⸻
ただし、
医療者には、
もう一つ重要な役割がある。
限界を知ること
である。
すべての病気を治せるわけではない。
すべての生命を救えるわけでもない。
⸻
Future Healthcareが進歩しても、
死や不確実性が完全になくなるわけではない。
⸻
だから、
医療は、
治すことだけではない。
痛みを減らす。
不安を支える。
患者の意思を尊重する。
人生の最終段階を支える。
⸻
Technologyが高度になるほど、
「何ができるか」だけではなく、
「何をするべきか」
という問いが大きくなる。
⸻
ここで、
Ethics。
Communication。
Shared Decision Making。
が重要になる。
⸻
AIは、
生存確率を推定できるかもしれない。
しかし、
その数字を、
一人の患者と家族へどう伝えるか。
どの治療を選ぶか。
そこには、
人間同士の関係が残る。
⸻
だから、
Future Healthcareの中心から、
Careを外してはいけない。
⸻
医師・医療者のFuture Stateを、
最小に整理すると、
五つの能力になる。
Clinical Intelligence。
生命状態を理解し判断する。
Collaborative Intelligence。
複数職種で医療をつくる。
Digital Intelligence。
AIとDataを適切に利用する。
Human Care。
患者の意思と生活へ向き合う。
そして、
Learning Capability。
医療Realityから継続的に学ぶ。
⸻
その構造は、
Human
＋ Team
＋ Data
＋ AI
→ Better Medical Decision
→ Better Care
となる。
⸻
Future Pullから見ると、
医療人材政策も変わる。
「医師を何人増やすか」
だけではない。
どのCapabilityが必要なのか。
どこへ配置するのか。
どの業務を誰が担うのか。
どの部分をDigitalで支援するのか。
⸻
人数から、
Capability Architecture
へ移る。
⸻
未来の医療者とは、
Technologyによって役割を失う人ではない。
Technologyによって、
本来の役割へ戻る人である。
患者を見る。
生命を理解する。
判断する。
支える。
⸻
AIが、
情報処理を引き受ける。
Robotが、
一部の作業を引き受ける。
Systemが、
事務を引き受ける。
⸻
その結果、
医療者が、
より多くの時間を、
生命そのものへ使える。
⸻
これが、
Future Pullから見た医療人材の未来である。
⸻
そして、
医療者が患者と出会う時間だけでは、
健康は支えきれない。
人は、
病院の外で生活している。
食べる。
眠る。
働く。
運動する。
地域で暮らす。
この日常時間へ医療を接続する領域が、
次に見る
Healthcare
である。
第8章 医療・Healthcare・医薬
第4節 Healthcare
医療は、
病気と向き合う。
Healthcareは、
それより長い時間を扱う。
人が生まれ、
育ち、
働き、
年齢を重ね、
生活する。
その全体の中で、
健康を支える。
だから、
Future Pullから見たHealthcareとは、
医療を病院の外へ拡張しただけのものではない。
生命の日常時間と医療時間を接続するSystem
である。
⸻
人は、
一年のほとんどを、
病院の外で過ごしている。
家庭。
学校。
職場。
地域。
食事。
睡眠。
運動。
仕事。
人間関係。
これらの日常が、
長期的な健康状態と関係する。
⸻
にもかかわらず、
従来の医療Systemは、
病気になった後の時間を中心に構築されてきた。
症状が出る。
病院へ行く。
診断する。
治療する。
⸻
Future Healthcareでは、
時間を前へ広げる。
Health
→ Risk
→ Prevention
→ Early Detection
→ Treatment
→ Recovery
→ Health
治療を終点にしない。
健康へ戻り、
再び日常へ接続する。
⸻
この循環の中心にあるのは、
病気ではない。
人のLife State
である。
⸻
Future Stateとして置くべきなのは、
「病院を利用しなくてよい社会」
ではない。
必要なときには、
適切な医療へアクセスできる。
同時に、
病気になる前から、
自分の健康状態を理解できる。
必要な予防を選べる。
治療後も、
生活へ戻る支援を受けられる。
そうした状態である。
⸻
Healthcareは、
生命時間を分断しない。
健康なとき。
Riskが高まったとき。
病気になったとき。
回復したとき。
それぞれを、
一つの連続したStateとして見る。
⸻
ここで、
Dataが意味を持つ。
健康診断。
診療記録。
薬。
検査。
Wearable。
生活記録。
これらは、
別々に存在していることが多い。
⸻
しかし、
必要な範囲で接続できれば、
生命状態の変化を、
より早く発見できる可能性がある。
⸻
たとえば、
血圧。
血糖。
睡眠。
活動量。
体重。
一つの値だけではなく、
時間変化を見る。
⸻
Future Healthcareでは、
一点の診断から、
Longitudinal Health State
へ視点を広げる。
⸻
重要なのは、
Dataを大量に集めることではない。
何のために使うのか。
本人にどのBenefitがあるのか。
誰がAccessできるのか。
明確にすることである。
⸻
健康Dataは、
本人の生命に関わる。
だから、
Future Healthcareには、
Personal Control
が必要になる。
⸻
Dataを利用するか。
誰と共有するか。
どのServiceへ接続するか。
本人が理解し、
選択できる。
⸻
便利さのために、
人間を常時監視する社会へしてはいけない。
⸻
Healthcare Technologyの目的は、
人を管理することではない。
人が自分の健康について、より良い選択をできるようにすること
である。
⸻
ここで、
AIが入る。
大量のHealth Dataから、
変化を見つける。
Riskを提示する。
生活改善を支援する。
医療機関へ相談すべき時期を示す。
⸻
しかし、
AIによるRisk推定を、
診断そのものとして扱ってはいけない。
⸻
AIが、
可能性を示す。
必要なら、
医療者へ接続する。
医療者が、
診断する。
⸻
AI Detection
→ Human Medical Evaluation
という境界を明確にする。
⸻
これによって、
AIは、
医療者の代わりではなく、
HealthcareとMedical Careをつなぐ入口になる。
⸻
予防も、
一律であってはいけない。
同じ年齢でも、
生活。
家族歴。
身体状態。
仕事。
環境。
Riskは異なる。
⸻
Future Healthcareでは、
可能な範囲で、
Personalized Prevention
へ移る。
⸻
しかし、
個人化だけでは不十分である。
健康には、
社会環境も影響する。
歩ける街か。
健康的な食事へAccessできるか。
孤立していないか。
働き方はどうか。
⸻
だから、
Healthcareを、
個人責任だけにしてはいけない。
⸻
Personal Health
＋ Social Environment
として設計する。
⸻
ここで、
自治体の役割が出てくる。
地域ごとに、
Health Stateは異なる。
高齢化。
生活習慣。
医療Access。
交通。
所得。
地域環境。
⸻
地域Dataから、
どの健康課題が大きいのかを見る。
そして、
医療機関。
自治体。
学校。
企業。
地域団体。
を接続する。
⸻
Healthcareは、
厚生分野だけの政策ではない。
Mobility。
Housing。
Education。
Work。
Environment。
地域設計とも関係する。
⸻
たとえば、
高齢者が外出しなくなる。
運動量が減る。
孤立する。
健康状態が悪化する。
この問題を、
医療だけで解くことは難しい。
⸻
地域交通。
Community Space。
Digital Service。
介護。
Healthcare。
を接続する必要がある。
⸻
つまり、
未来Healthcareは、
Cross-sector Architecture
になる。
⸻
企業にも、
役割がある。
人は、
長い時間を職場で過ごす。
働き方。
睡眠。
Mental Health。
運動。
Stress。
仕事と健康は分離できない。
⸻
だから、
企業のHealthcareを、
福利厚生だけで考えない。
従業員が、
長期間働き続けられる状態をつくる。
⸻
健康診断。
Mental Health Support。
Work Design。
休息。
Remote Work。
必要な医療へのAccess。
⸻
Human CapitalとHealthcareを接続する。
⸻
ただし、
企業が従業員の健康情報を、
過度に管理してはいけない。
EmploymentとHealth Dataには、
明確な境界が必要になる。
⸻
本人の権利。
Privacy。
Consent。
を守る。
⸻
保険も、
Healthcareへ接続する。
従来、
保険は、
病気や事故が起きた後のCostを支える役割が大きかった。
しかし、
予防によって将来Riskを下げられるなら、
より早い段階へ資源を送る意味がある。
⸻
Compensation
→ Prevention
へ一部の時間軸を前へ動かす。
⸻
健康支援。
早期検査。
Digital Health。
慢性疾患Management。
それによって、
Life OutcomeとCostの両方が改善するかを検証する。
⸻
ここでも、
重要なのは、
Serviceを導入したことではない。
Health Outcomeが変わったか
である。
⸻
Healthcare産業が成長した。
App利用者が増えた。
Wearableが売れた。
それだけでは、
成功とは限らない。
⸻
病気の早期発見につながったか。
生活の質が上がったか。
医療Accessが改善したか。
医療者負担が減ったか。
⸻
Technology Outputではなく、
Life Outcomeを見る。
⸻
Future Healthcareには、
介護との接続も不可欠である。
高齢化すると、
治療だけではなく、
生活を支える時間が長くなる。
⸻
医療。
介護。
Rehabilitation。
Housing。
家族。
地域。
これらが分断されれば、
本人と家族の負担が大きくなる。
⸻
だから、
治療終了を、
Healthcare終了にしない。
⸻
退院する。
地域へ戻る。
Rehabilitationする。
生活を再構築する。
必要なら、
介護につなぐ。
⸻
Hospital
→ Home
→ Community
までを、
一つのCare Journeyとして見る。
⸻
ここでも、
DataとCoordinatorが重要になる。
誰が、
次のCareへつなぐのか。
誰が、
全体を見ているのか。
⸻
Systemが複雑になるほど、
患者本人へCoordinationを押し付けてはいけない。
⸻
Future Healthcareでは、
System Complexityを利用者側から減らすこと
が重要になる。
⸻
患者が、
制度をすべて理解しなくてもよい。
どの医療機関へ行くか。
どの介護Serviceが使えるか。
どの行政支援があるか。
必要な情報へ到達できる。
⸻
AIやDigital Assistantは、
このNavigationを支援できる。
ただし、
公式情報と接続し、
必要な場合は人間へ引き継ぐ。
⸻
Healthcareには、
Mental Healthも含まれる。
身体だけを健康と考えない。
不安。
Stress。
孤独。
社会関係。
⸻
精神的な状態は、
身体Healthや生活にも影響する。
だから、
Future Health Stateは、
身体指標だけでは測れない。
⸻
Quality of Life。
社会参加。
本人のWell-being。
複数の視点を見る。
⸻
ただし、
幸福を国家や企業が一つの数値として定義する必要はない。
⸻
重要なのは、
本人が、
より多くの選択を持つことである。
休める。
相談できる。
治療できる。
人とつながれる。
⸻
Healthcareは、
人間の生活可能性を支える。
⸻
Future Healthcareには、
Healthy Agingという長い時間軸もある。
寿命が延びることと、
健康に生活できる時間が延びることは同じではない。
⸻
長い人生の中で、
働く。
学ぶ。
地域に参加する。
創造する。
自立して生活する。
⸻
Healthcareの目的を、
単なるLife Extensionだけに置かない。
HealthspanとLife Capability
を見る。
⸻
これは、
Education。
Labor。
Community。
Culture。
とも接続する。
⸻
人が長く生きる社会では、
Healthcareは、
医療制度の一分野ではなく、
社会Architectureの中核になる。
⸻
だから、
Future Healthcareを、
病院と保険だけで設計することはできない。
⸻
Healthcare
＝ Medical Care
＋ Prevention
＋ Daily Life
＋ Community
＋ Technology
＋ Social Infrastructure
として見る。
⸻
そして、
このSystemにもLearning Cycleを持たせる。
Serviceを実装する。
利用者が使う。
Outcomeを見る。
副作用を見る。
改善する。
⸻
Health State
→ Intervention
→ Outcome
→ Learning
→ New Health State
継続的に更新する。
⸻
ただし、
人間は実験対象ではない。
新しいHealthcare Serviceには、
安全性。
Evidence。
Consent。
が必要になる。
⸻
特に、
健康不安につけ込むService。
根拠の弱い診断。
過剰なMonitoring。
こうしたものから利用者を守る必要がある。
⸻
Innovationと、
Consumer Protectionを両立する。
⸻
Future Healthcareの最小原則を整理すると、
四つになる。
Prevent Earlier。
対応可能なRiskには早く介入する。
Connect Continuously。
医療と日常を分断しない。
Personalize Carefully。
個人差を扱いながら権利を守る。
Measure Outcomes。
Service量ではなく生命への結果を見る。
⸻
Healthcareは、
病気を完全に消すSystemではない。
生命の不確実性は残る。
老いも、
病気も、
死も、
完全には消えない。
⸻
しかし、
発見を早めることはできる。
選択肢を増やすことはできる。
苦痛を減らすことはできる。
必要な支援へつなぐことはできる。
⸻
未来Healthcareとは、
生命を完全制御することではない。
生命がより長く、多くの選択可能性を保持できる状態を支えること
である。
⸻
病院・診療所が、
治療の拠点になる。
医師・医療者が、
生命へ判断とCareを届ける。
Healthcareが、
その医療を日常へ接続する。
⸻
そして、
生命へ直接作用するもう一つの大きな技術体系がある。
薬である。
分子。
Biotechnology。
新しい治療法。
それらを研究し、
安全性と有効性を確認し、
患者へ届ける。
次節では、
生命のFuture Stateを薬として実装する、
医薬・製薬
へ進む。
第8章 医療・Healthcare・医薬
第5節 医薬・製薬
医療が、
患者の生命へ直接向き合うなら、
医薬は、
その生命状態へ作用するための重要な手段である。
感染症。
がん。
循環器疾患。
代謝疾患。
神経疾患。
希少疾患。
多くの病気に対して、
薬は生命の可能性を変えてきた。
Future Pullから医薬を見るとき、
中心に置くべきなのは、
薬そのものではない。
どの生命状態を、どのように変えたいのか
である。
⸻
従来の創薬は、
長い探索から始まる。
病気を理解する。
標的を探す。
候補物質を見つける。
効果を確認する。
安全性を調べる。
臨床試験を行う。
承認を受ける。
製造する。
患者へ届ける。
⸻
この長い時間には、
削ってはいけない部分がある。
生命に作用する以上、
安全性。
有効性。
品質。
を確認する必要がある。
⸻
だから、
Future Pullにおける医薬の目的は、
創薬時間を無条件に短縮することではない。
生命に必要な検証時間を守りながら、その周囲にある探索・接続・待機時間を短縮すること
である。
⸻
たとえば、
候補化合物を探す時間。
過去研究を調べる時間。
Clinical Trial候補施設を探す時間。
患者Recruitment。
Data整理。
申請資料作成。
製造Scale-up。
⸻
この中には、
DigitalとAIによって改善できる部分がある。
⸻
創薬のFuture Stateを、
薬の数で置いてはいけない。
重要なのは、
必要な患者へ、
有効で安全な治療選択肢が、
必要な時期に届くことである。
⸻
そのFuture Stateから、
現在を逆算する。
治療法が存在しない疾患。
既存薬では十分な効果がない疾患。
副作用が大きい治療。
患者数が少なく、
開発が難しい疾患。
⸻
どこに、
Therapeutic Gap
があるのかを見る。
⸻
そして、
そのGapから、
Research Requirementを引く。
病態理解。
Target。
Biomarker。
Drug Candidate。
Clinical Evidence。
Manufacturing。
Regulatory Science。
⸻
「売れそうな薬を探す」
だけではない。
生命側に存在する未充足Requirementから創薬を始める。
⸻
これは、
市場を否定することではない。
新薬を継続的に生み出すには、
企業が研究開発投資を回収できることも必要である。
しかし、
Market PotentialとMedical Needは、
必ずしも一致しない。
⸻
患者数が少ない。
治療期間が短い。
開発Riskが高い。
こうした領域では、
民間資本だけでは十分な研究が進みにくい場合がある。
⸻
そこで、
大学。
公的研究機関。
政府資金。
製薬企業。
Biotech。
患者団体。
を接続する。
⸻
Medical Need
→ Public Research
→ Private Development
→ Clinical Implementation
複数主体で、
Riskを分担する。
⸻
医薬産業には、
異なる主体が存在する。
大手製薬企業。
Biotech Startup。
大学。
CRO。
CDMO。
病院。
薬局。
Regulator。
⸻
一社が、
すべてのCapabilityを持つ必要はない。
むしろ、
研究。
Clinical Development。
製造。
販売。
それぞれの専門性をNetwork化する。
⸻
これによって、
創薬を、
巨大企業内部だけの閉じたProcessから、
Distributed Drug Development
へ拡張できる。
⸻
大学には、
新しいScienceがある。
Startupには、
新しいTechnologyと速度がある。
大手製薬には、
Clinical Development。
製造。
Global Distribution。
のScaleがある。
⸻
これらを接続する。
⸻
University Science
→ Biotech Exploration
→ Pharmaceutical Scale
という流れを強くする。
⸻
重要なのは、
Researchから次のStageへ移る待ち時間を減らすことである。
優れた研究成果がある。
しかし、
事業化する主体がいない。
Patentはある。
しかし、
資本がない。
Startupはできた。
しかし、
Clinical Development能力がない。
⸻
ここに、
Translation Gap
がある。
⸻
Future Pullでは、
研究成果が生まれてから接続先を探さない。
将来必要になる治療領域を見ながら、
研究。
Capital。
Clinical Network。
Manufacturing。
を早い段階から並列に準備する。
⸻
Research
＋ Capital
＋ Clinical
＋ Manufacturing
を同時に見る。
⸻
創薬には、
Clinical Trialという重要な生命時間がある。
新しい治療が、
人間で安全か。
本当に効果があるか。
確認しなければならない。
⸻
ここを、
単純な速度競争にしてはいけない。
一方、
Clinical Trialの周囲には、
改善可能なProcessがある。
⸻
施設選定。
患者Recruitment。
Data Capture。
Remote Monitoring。
文書管理。
解析。
⸻
Digital Technologyによって、
これらを効率化できれば、
Verificationそのものを弱めずに、
Implementation Timeを短縮できる。
⸻
つまり、
Future Pharmaceutical Developmentでは、
Verificationを高速化するのではなく、Verificationへ到達するまでの摩擦を減らす。
⸻
患者も、
創薬Systemの外側にはいない。
どの症状が最も困るのか。
どの副作用なら受け入れられるのか。
どの治療方法が生活と両立するのか。
患者のPerspectiveを、
Developmentの早い段階から入れる。
⸻
すると、
Clinical EndpointやTreatment Designも、
より生命Realityへ近づく。
⸻
薬が効くかだけではない。
患者がその治療によって、どのように生きられるか
を見る。
⸻
医薬には、
Precision Medicineの方向もある。
同じ病名でも、
病態が異なる。
遺伝的特徴。
Biomarker。
生活背景。
他疾患。
⸻
将来、
患者をより細かく分類できれば、
効果が期待できる治療を、
より適切に選べる可能性がある。
⸻
つまり、
One Disease – One Drug
だけではなく、
患者Stateに応じて治療を選ぶ。
⸻
ただし、
個別化が進むほど、
Data。
Diagnostic。
Clinical Evidence。
Cost。
が複雑になる。
⸻
だから、
薬だけではなく、
DiagnosticとData Infrastructureを同時に設計する必要がある。
⸻
Drug
＋ Diagnostic
＋ Data
である。
⸻
製薬には、
Manufacturingもある。
薬を発見しても、
安定して製造できなければ、
患者へ届かない。
⸻
原材料。
製造設備。
Quality Control。
Cold Chain。
物流。
在庫。
⸻
特に、
Biologics。
Cell Therapy。
Gene Therapy。
などでは、
製造そのものが高度になる。
⸻
つまり、
Future Pharmaは、
Research Industryであると同時に、
高度Manufacturing Industry
でもある。
⸻
ここで、
日本の製造Capabilityを接続できる。
精密機器。
Sensor。
Automation。
Quality Management。
材料。
⸻
第7章で見たManufacturing Capabilityが、
医薬生産へ接続される。
⸻
医薬品Supply Chainには、
Resilienceも必要になる。
薬が開発されても、
必要なときに供給できなければ、
生命へ届かない。
⸻
原薬。
原材料。
製造拠点。
物流。
海外依存。
在庫。
⸻
どこにCritical Dependencyがあるのかを見る。
すべてを国内でつくる必要はない。
しかし、
生命維持に不可欠な医薬品について、
Supply Riskを把握する。
⸻
Pharmaceutical Security
も、
Healthcare Architectureの一部になる。
⸻
薬価や保険制度も、
未来医薬に影響する。
新しい薬を開発するには、
研究投資を回収できる環境が必要になる。
一方、
患者が利用できない価格なら、
Future Stateは実現しない。
⸻
ここには、
InnovationとAccessの両立が必要になる。
⸻
高いInnovation Value。
患者Access。
Healthcare Systemの持続可能性。
この三つを、
単純な一軸ではなく、
同時に見る。
⸻
Future Stateは、
「薬が開発された状態」
ではない。
薬が必要な患者へ、持続可能な形で届く状態
である。
⸻
したがって、
医薬政策は、
Research支援だけで終わらない。
承認。
価格。
保険。
Distribution。
使用後の安全性確認。
まで含む。
⸻
薬が市場へ出た後も、
Learningは続く。
Clinical Trialでは、
限られた条件の患者を見る。
実際の医療現場では、
より多様な患者が使う。
⸻
副作用。
長期効果。
実臨床での有効性。
Real-world Dataから学ぶ。
⸻
Development
→ Approval
→ Clinical Use
→ Real-world Evidence
→ Updated Knowledge
薬も、
継続的に学習される。
⸻
ここで、
病院・診療所のDataと、
製薬研究が接続する。
ただし、
患者Dataの利用には、
Consent。
Privacy。
Governance。
が必要である。
⸻
Trustを失えば、
研究基盤そのものが弱くなる。
だから、
Data Governanceは、
創薬Accelerationの前提条件である。
⸻
Future Pharmaには、
薬を新しくつくる以外の可能性もある。
既存薬の新しい用途。
Combination。
Dosage Optimization。
Drug Delivery。
⸻
すでに存在するKnowledgeを再評価することで、
新しい治療Optionが生まれる場合がある。
⸻
これは、
本書全体の原理と同じである。
未来をつくるために、
すべてをゼロから発明する必要はない。
現在に存在するPotentialを、未来Requirementから読み直す。
⸻
医薬品にも、
既存Capabilityの再配置がある。
⸻
AIは、
この探索を大きく支援できる。
病態Networkを解析する。
候補分子を生成する。
Protein Structureを扱う。
既存Drugを探索する。
Clinical Trial Designを支援する。
⸻
しかし、
AIが薬を「完成」させるわけではない。
生命は、
Digital Modelだけでは確認できない。
⸻
Computer上のPotentialを、
Biologyで確認する。
BiologyのPotentialを、
Clinical Realityで確認する。
⸻
Digital Hypothesis
→ Biological Evidence
→ Clinical Evidence
この順序を守る。
⸻
ここに、
創薬AIの本当の位置がある。
生命時間を飛び越える装置ではない。
探索空間を狭め、より良い仮説をより早く生命検証へ送る装置
である。
⸻
製薬企業自身も、
Future Pullへ移行する必要がある。
既存ProductのPipelineを管理するだけではない。
将来のDisease Burden。
新しいScience。
人口構造。
Healthcare State。
を見ながら、
Research Portfolioを更新する。
⸻
一つのBlockbusterへ依存しない。
複数のScience。
複数のModality。
複数の疾患領域。
を探索する。
⸻
Portfolio of Future Therapies
を持つ。
⸻
そして、
成立したものへ、
Capitalを追加する。
成立しないものから、
早く学ぶ。
⸻
Future Capital Architectureと同じように、
創薬にも、
探索とScaleの資本配分が必要になる。
⸻
最小に整理すると、
Future Pharmaの構造は、
次のようになる。
Unmet Medical Need
↓
Research
↓
Drug Hypothesis
↓
Preclinical Verification
↓
Clinical Verification
↓
Approval / Manufacturing
↓
Patient Access
↓
Real-world Evidence
↓
New Research
⸻
ここで、
医薬は、
製品を売って終わる産業ではなくなる。
生命Realityから学び、
次の治療へKnowledgeを戻す、
循環型の研究・実装Systemになる。
⸻
医薬・製薬の未来とは、
薬を無限に増やすことではない。
必要な生命状態に対して、
より適切な治療選択肢を、
より安全に、
より確実に、
必要な人へ届けることである。
⸻
病院・診療所が、
治療を実装する。
医師・医療者が、
生命へ判断を届ける。
Healthcareが、
日常と医療をつなぐ。
医薬・製薬が、
新しい治療Capabilityを生み出す。
⸻
そして、
この創薬Processそのものを、
AIによってさらに早く探索し、
生命検証へ接続する可能性がある。
次節では、
AIと生命科学を接続し、
未来の治療候補を現在へ引く
創薬AI・生成医療
へ進む。
第8章 医療・Healthcare・医薬
第6節 創薬AI・生成医療
医薬の開発には、
長い時間が必要になる。
病態を理解する。
Targetを探す。
候補を探索する。
生物学的に検証する。
Clinical Trialを行う。
安全性と有効性を確かめる。
この時間のすべてを、
消すことはできない。
生命には、
生命を通してしか確認できないことがあるからである。
しかし、
その長いProcessの中には、
AIによって大きく変えられる時間がある。
それが、
探索時間
である。
⸻
創薬では、
膨大な可能性の中から、
有望な仮説を探す。
どの分子が、
どのTargetへ作用するのか。
どのProtein構造が重要なのか。
どの患者群に効果が期待できるのか。
どの既存薬を、
別の疾患へ使える可能性があるのか。
人間だけで、
すべての組み合わせを調べることは難しい。
⸻
AIは、
この探索空間を扱う。
論文。
分子。
Protein。
遺伝子。
Clinical Data。
既存薬。
多様な情報を接続し、
候補を生成する。
⸻
ここで、
創薬の順序が変わる。
大量の候補を、
一つずつ試すだけではない。
先に、
Digital空間で探索する。
有望な候補を絞る。
その後、
Biologyへ送る。
⸻
Digital Exploration
→ Biological Verification
→ Clinical Verification
この構造によって、
生命に必要な検証を残したまま、
そこへ到達するまでの時間を短縮できる。
⸻
創薬AIの価値は、
薬を自動的につくることではない。
より良い仮説を、より早く実験へ送ること
にある。
⸻
そして、
実験結果を、
再びAIへ戻す。
予測した。
実験した。
外れた。
なぜ外れたのかを学ぶ。
次の候補を出す。
⸻
Predict
→ Experiment
→ Learn
→ Predict Again
この循環が短くなるほど、
Research Timeも短くなる。
⸻
ここで、
AIと研究者は対立しない。
AIは、
大量の可能性を探索する。
研究者は、
生物学的意味を考える。
仮説を評価する。
実験を設計する。
意外な結果から、
新しいQuestionをつくる。
⸻
つまり、
Future Drug Discoveryは、
Researcher Intelligence
＋ AI Exploration
として進む。
⸻
重要なのは、
AIのOutputを答えにしないことである。
生命は複雑である。
Digital Modelが、
すべてを再現できるわけではない。
⸻
AIが、
「有望」と判断した。
だから薬になる。
という順序ではない。
AIは、
検証すべき候補を提示する。
最終的には、
現実のBiologyとClinical Realityが答える。
⸻
ここに、
生成医療の基本原則がある。
生成と検証を分離しない。
⸻
AIは、
多くの可能性を生成できる。
しかし、
生成量が増えるほど、
Verificationの重要性も増える。
薬。
診断。
治療計画。
どの領域でも同じである。
⸻
未来医療では、
AIが候補を生成する。
医療者や研究者が検証する。
患者のRealityで結果を見る。
⸻
Generate
→ Verify
→ Implement
→ Observe
この循環を持つ。
⸻
本書でいう生成医療とは、
AIが無限に治療を生成することではない。
生命のFuture Stateから必要な治療・予防・Careの可能性を探索し、検証を通じてRealityへ変換する医療
である。
⸻
従来の医療では、
患者が病気になる。
診断する。
既存の治療Optionから選ぶ。
この構造が中心だった。
⸻
生成医療では、
既存Optionを選ぶだけでなく、
患者Stateから、
より適切な治療候補を探索する。
⸻
どの薬が適しているか。
どのCombinationがよいか。
どのTimingがよいか。
どの患者群に近いか。
⸻
ただし、
すべてを個別にゼロから発明するという意味ではない。
既存Knowledgeを、
患者Stateに合わせて再構成する。
⸻
Patient State
＋ Medical Knowledge
＋ AI
→ Treatment Options
という構造である。
⸻
ここでも、
最終決定は人間へ残る。
AIは、
Optionを広げる。
医療者は、
Clinical Realityを判断する。
患者は、
自分の価値観を含めて選択する。
⸻
AI Proposal
＋ Clinical Judgment
＋ Patient Choice
この三つを接続する。
⸻
生成医療は、
Personalized Medicineとも接続する。
同じ疾患名でも、
患者Stateは異なる。
遺伝的特徴。
Biomarker。
年齢。
併存疾患。
生活。
過去の治療。
⸻
Dataが増えれば、
より細かい患者分類が可能になる。
そして、
その患者群に適した治療を選ぶ。
⸻
しかし、
個別化が進むほど、
Evidenceが細分化される。
だから、
AIによる推定だけでなく、
Clinical Evidenceを継続的に蓄積する必要がある。
⸻
生成医療は、
PersonalizationとEvidenceを同時に進める。
⸻
ここで、
Real-world Dataが重要になる。
Clinical Trialでは、
一定の条件を満たした患者を対象にする。
実際の医療現場には、
より多様な患者がいる。
⸻
薬を使った。
治療した。
結果がどうだったか。
副作用はどうだったか。
⸻
このDataを、
適切なGovernanceのもとで学習へ戻す。
⸻
Clinical Reality
→ Data
→ Knowledge
→ Better Treatment
医療Systemそのものが、
継続的に学習する。
⸻
ただし、
患者Dataを、
AIの原料とだけ考えてはいけない。
Dataの主体は、
人間である。
Consent。
Privacy。
Security。
Purpose Limitation。
が必要になる。
⸻
生成医療が高度になるほど、
Trust Architecture
が重要になる。
⸻
AIがどのDataを使ったのか。
どこまで判断へ影響したのか。
誰が最終判断したのか。
後から確認できる。
⸻
Auditabilityを持つ。
⸻
重大な医療判断で、
「AIがそう言ったから」
という説明は成立しない。
⸻
AIは、
責任主体ではない。
責任ある医療Systemの中で、
利用されるTechnologyである。
⸻
創薬AIには、
大学と製薬企業の接続を変えるPotentialもある。
大学には、
病態Knowledge。
基礎Science。
研究Data。
がある。
⸻
製薬企業には、
Development。
Clinical Trial。
Manufacturing。
Global Scale。
がある。
⸻
AI Platformを通じて、
複数のKnowledgeを接続できれば、
Research Translationを速められる可能性がある。
⸻
大学で発見したTarget。
StartupがAIで候補探索する。
製薬企業がDevelopmentする。
病院がClinical Verificationする。
⸻
University
→ AI / Startup
→ Pharma
→ Hospital
一つのPipelineとして接続する。
⸻
これによって、
研究成果が次の主体へ移るまでの待ち時間を減らす。
⸻
生成医療では、
HospitalもLearning Siteになる。
治療結果から、
新しいQuestionが生まれる。
⸻
なぜ効かなかったのか。
なぜこの患者には効いたのか。
どの副作用が生じたのか。
⸻
そのQuestionを、
AIとResearchへ戻す。
⸻
Care
→ Question
→ Research
→ New Care
医療と研究の境界が、
一方向ではなくなる。
⸻
予防にも、
生成医療の考え方を使える。
将来Riskを推定する。
その人に必要な介入候補を生成する。
食事。
運動。
検査。
医療相談。
⸻
ただし、
Risk推定は確定未来ではない。
確率である。
だから、
人をRisk Scoreだけで扱ってはいけない。
⸻
AIは、
未来を決定するものではない。
未来の選択肢を早く提示するもの
として使う。
⸻
ここで、
Future Pullと生成医療が重なる。
未来のDisease Stateを予測して恐れるのではない。
将来発生する可能性のあるGapを、
現在へ引く。
⸻
Riskが高い。
ならば、
今できることは何か。
検査する。
生活を変える。
専門医へ相談する。
⸻
未来Riskを、
現在の選択可能性へ変換する。
⸻
これは、
TreatmentからPreventionへ時間を引くことである。
⸻
生成医療には、
RobotやMedical Deviceも入る。
手術支援。
Rehabilitation。
Remote Monitoring。
Diagnostic Device。
⸻
AIによって、
Deviceが患者Stateへ適応する。
しかし、
Safety Verificationが必要になる。
⸻
Software Updateによって、
医療Deviceの機能が変わる時代には、
一度承認して終わりではなく、
継続的なSafety Managementが必要になる。
⸻
つまり、
Future Medical Technologyは、
Continuous Verification
を必要とする。
⸻
生成医療には、
制度時間も関係する。
Technologyが進歩しても、
承認制度。
保険。
医療責任。
Data Rule。
が追いつかなければ、
Clinical Realityへ出せない。
⸻
だから、
研究が完成してから制度を考えるのでは遅い。
Research段階から、
Regulator。
医療者。
企業。
患者。
が接続する。
⸻
Research
＋ Regulation
＋ Clinical
＋ Patient
を並列に準備する。
⸻
Future Pullの原則が、
ここでも働く。
⸻
Capitalも同時に必要になる。
AI創薬には、
Compute。
Data。
研究人材。
Wet Lab。
Clinical Trial。
Manufacturing。
多段階の資本が必要になる。
⸻
Seed Capitalだけでは、
患者まで届かない。
Research Funding。
Venture Capital。
Growth Capital。
Pharma Investment。
Public Support。
⸻
生命時間に合わせて、
CapitalをRelayする。
⸻
Life Time
↔ Research Time
↔ Capital Time
↔ Regulation Time
これらを並列接続することが、
医療のFuture Accelerationになる。
⸻
生成医療は、
すべてを速くする思想ではない。
むしろ、
速くしてよい時間と、
守るべき時間を区別する。
⸻
AI探索は速くする。
情報検索は速くする。
Data処理は速くする。
研究者間の接続は速くする。
⸻
一方、
生命検証。
患者との対話。
倫理判断。
安全確認。
これらには、
必要な時間を置く。
⸻
つまり、
Acceleration with Verification
である。
⸻
ここが、
一般的なTechnology Accelerationと、
医療Accelerationの違いになる。
⸻
未来医療では、
速さの単位も変わる。
何日でAI Modelをつくったかではない。
何年早く患者へ有効な治療が届いたか。
何か月早くRiskを発見できたか。
医療者が何時間患者へ戻せたか。
⸻
Life Outcomeに結びついた時間短縮
だけを価値として見る。
⸻
生成医療の最小構造を整理すると、
次のようになる。
Life Future State
↓
Medical Gap
↓
AI / Human Hypothesis Generation
↓
Biological Verification
↓
Clinical Verification
↓
Personalized Implementation
↓
Life Outcome
↓
Real-world Learning
↓
New Medical Potential
⸻
未来から、
必要な医療を引く。
AIが、
探索を広げる。
Scienceが、
生命で確かめる。
医療者が、
患者へ翻訳する。
患者が、
選択する。
結果が、
次のKnowledgeになる。
⸻
この循環が継続すると、
医療は、
完成したKnowledgeを患者へ適用するだけのSystemではなくなる。
生命Realityから学びながら、次の治療可能性を生成し続けるSystem
になる。
⸻
これが、
生成医療である。
⸻
そして、
この構造を、
創薬だけに限定しない。
病院。
医療者。
Healthcare。
医薬。
AI。
Data。
Research。
Capital。
制度。
すべてを一つの生命Architectureへ接続する。
⸻
第8章で見てきた要素は、
ここで統合される準備が整った。
病院・診療所が、
医療を実装する。
医師・医療者が、
生命へ判断とCareを届ける。
Healthcareが、
日常時間へ広げる。
医薬・製薬が、
新しい治療Capabilityを生み出す。
創薬AI・生成医療が、
未来の治療可能性を現在へ引く。
⸻
次節では、
これらを一つの継続的な生命Systemとしてまとめる。
それが、
Generative Healthcare
である。
第8章 医療・Healthcare・医薬
第7節 Generative Healthcare
ここまで、
病院・診療所。
医師・医療者。
Healthcare。
医薬・製薬。
創薬AI・生成医療。
を見てきた。
これらは、
現在の制度では別々の領域として扱われることが多い。
しかし、
生命から見れば、
一つの連続した時間である。
健康である。
Riskが高まる。
病気になる。
診断される。
治療する。
回復する。
生活へ戻る。
そして再び、
健康状態を維持する。
⸻
未来医療を設計するなら、
この生命時間を分断してはいけない。
本書では、
その全体を一つの生成Systemとして接続した状態を、
Generative Healthcare
と呼ぶ。
⸻
Generative Healthcareとは、
AIを使うHealthcareではない。
新しい薬を大量につくることでもない。
病院を高度化することだけでもない。
その中心にあるのは、
生命のFuture Stateから、医療・予防・医薬・Technology・制度・資本を逆算して接続すること
である。
⸻
従来のHealthcareは、
現在存在する制度から始まりやすい。
病院がある。
診療科がある。
保険制度がある。
薬がある。
その中で、
何ができるかを考える。
⸻
Generative Healthcareでは、
順序を変える。
まず、
生命側にFuture Stateを置く。
必要な医療へ到達できる。
疾病Riskを可能な範囲で早期に知ることができる。
患者Stateに合った治療を選べる。
医療者が持続的に働ける。
研究成果が患者へ届く。
治療結果が次の研究へ戻る。
⸻
そこから、
Current Healthcare Stateを見る。
⸻
どこにAccess Gapがあるのか。
どこに人材Gapがあるのか。
どこでDataが分断されているのか。
どこでResearchが止まっているのか。
どこにCapital Gapがあるのか。
⸻
そして、
Requirementへ変換する。
⸻
Life Future State
→ Healthcare Gap
→ Requirement
→ Implementation
この順序を持つ。
⸻
Generative Healthcareの第一の特徴は、
治療から生命時間へ視野を広げること
である。
病気になった後だけではない。
Risk。
Prevention。
Early Detection。
Treatment。
Recovery。
Care。
一つのContinuumとして見る。
⸻
だから、
医療制度の評価も変わる。
病床数。
診察件数。
薬剤数。
だけでは足りない。
⸻
必要な医療へ到達できたか。
病気を早く発見できたか。
治療後に生活へ戻れたか。
Quality of Lifeはどう変わったか。
⸻
Medical OutputからLife Outcomeへ
評価軸を移す。
⸻
第二の特徴は、
施設からNetworkへ
移ることである。
一つの病院が、
すべての医療Capabilityを持つ必要はない。
診療所。
中核病院。
高度医療機関。
薬局。
介護。
在宅。
Remote Healthcare。
⸻
患者Stateに応じて、
必要なNodeへ接続する。
⸻
地域に専門医がいなくても、
専門KnowledgeへAccessできる。
高度医療は集中する。
日常Careは地域で行う。
⸻
重要なのは、
患者から見て、
医療が途切れないことである。
⸻
Distributed Medical Capability
＋ Connected Care
これが、
未来医療Networkの基本になる。
⸻
第三は、
医療者とAIの再配置
である。
AIが医療者を置き換えることを目的にしない。
情報検索。
記録。
分析。
定型業務。
AIやDigitalが得意な部分を任せる。
⸻
医療者は、
Clinical Judgment。
患者との対話。
身体診察。
Care。
倫理判断。
へ時間を使う。
⸻
AI Timeを増やすのではなく、Human Care Timeを取り戻す。
これが重要になる。
⸻
第四は、
Healthcareを日常へ接続すること
である。
人は、
病院の中だけで生きているわけではない。
家庭。
職場。
学校。
地域。
そこでHealth Stateは変化する。
⸻
睡眠。
食事。
運動。
Stress。
社会的孤立。
Environment。
日常状態とHealthcareを、
必要な範囲で接続する。
⸻
ただし、
人間を常時監視しない。
Dataは、
本人の権利と選択のもとで使う。
⸻
Generative Healthcareでは、
生命を管理するのではなく、生命の選択可能性を増やす。
⸻
第五は、
ResearchとCareの循環
である。
研究者が研究する。
製薬企業が薬を開発する。
病院が治療する。
これを、
一方向で終わらせない。
⸻
Clinical Realityから、
新しいQuestionが生まれる。
Dataが得られる。
研究へ戻る。
新しい治療候補が生まれる。
⸻
Research
→ Treatment
→ Clinical Reality
→ Knowledge
→ New Research
医療そのものが、
Learning Systemになる。
⸻
第六は、
生成と検証の接続
である。
AIは、
大量の仮説を生成できる。
薬候補。
診断候補。
治療Option。
Risk Prediction。
⸻
しかし、
生命領域では、
生成量が増えるほど、
Verificationが重要になる。
⸻
Digitalで生成する。
Biologyで検証する。
Clinical Realityで検証する。
医療者が判断する。
患者が選択する。
⸻
Generate
→ Verify
→ Decide
→ Implement
この順序を崩さない。
⸻
Generative Healthcareは、
生命検証を飛び越える医療ではない。
むしろ、
Verificationを中心に持つ生成System
である。
⸻
第七は、
複数の時間を接続することである。
医療には、
多くの時間が存在する。
患者の生命時間。
医療者の勤務時間。
Clinical Trialの時間。
創薬研究の時間。
制度時間。
Capital Time。
Technology Time。
⸻
これらを、
一つの速度へ揃える必要はない。
⸻
生命検証には、
必要な時間を置く。
研究には、
研究時間を置く。
しかし、
制度が研究終了後まで何も準備しない必要はない。
CapitalがClinical Stageまで待つ必要もない。
Manufacturingが承認後に初めて準備を始める必要もない。
⸻
可能なものを、
並列化する。
⸻
Research
＋ Regulation
＋ Capital
＋ Manufacturing
＋ Clinical Network
を早い段階から接続する。
⸻
ここに、
HealthcareのFuture Accelerationがある。
⸻
未来を早めるとは、
生命を急がせることではない。
生命の周囲に存在する待ち時間を減らすこと
である。
⸻
創薬に十年必要なら、
十年を無理に二年にするのではない。
十年後に必要になる治療を、
今日から探索する。
⸻
地域で医療人材が不足すると分かっているなら、
不足してから対応するのではない。
教育。
Task Sharing。
Remote Support。
AI。
Mobility。
を現在から準備する。
⸻
これが、
生命領域におけるFuture Pullである。
⸻
Generative Healthcareには、
Capital Architectureも必要になる。
基礎研究。
Startup。
Clinical Trial。
病院Infrastructure。
Medical Device。
予防Service。
それぞれ、
Riskと時間が違う。
⸻
だから、
一つのCapitalで支えない。
Public Research Funding。
Venture Capital。
Corporate Capital。
Long-term Finance。
Insurance。
それぞれを、
生命時間へ合わせる。
⸻
Life Time
↔ Capital Time
を接続する。
⸻
同時に、
Healthcareの持続可能性を見る。
新しいTechnologyが有効でも、
Costが高すぎて使えない。
医療者負担が大きすぎる。
地域では運用できない。
これでは、
Future Stateにならない。
⸻
Generative Healthcareには、
Clinical Effectiveness
＋ Access
＋ Sustainability
が必要になる。
⸻
さらに、
公平性も必要である。
Future Healthcareが、
一部の人だけに届くなら、
社会Systemとしては不十分である。
⸻
都市と地域。
若者と高齢者。
Digitalに強い人と弱い人。
所得差。
障害。
Language。
⸻
Technologyが新しいGapを生まないようにする。
⸻
だから、
Digital Serviceだけではなく、
Physical Accessも残す。
AI Interfaceだけでなく、
人間Interfaceも残す。
⸻
Future Healthcareは、
一つの利用方法へ人を合わせるのではない。
複数のAccess Pathを用意する。
⸻
そして、
Generative Healthcareには、
死も含まれる。
医療が進歩しても、
生命は無限ではない。
治療できない状態もある。
⸻
そのとき、
Healthcareは失敗したのではない。
苦痛を減らす。
意思を尊重する。
家族を支える。
人生の最終段階を支える。
⸻
生命のFuture Stateとは、
死を完全に排除することではない。
その人が最後まで可能な限り自分の生命を選べる状態
でもある。
⸻
だから、
Generative Healthcareは、
治療技術だけで完成しない。
Care。
Ethics。
Communication。
Death and Dying。
まで含む。
⸻
Technologyが高度になるほど、
このHuman Layerは重要になる。
⸻
Generative Healthcareを、
最小に整理すれば、
次の循環になる。
Life State
↓
Future Health State
↓
Gap
↓
Medical / Healthcare Requirement
↓
Research / Human / AI / Pharma / Capital
↓
Verification
↓
Care Implementation
↓
Life Outcome
↓
Learning
↓
New Life State
⸻
この循環には、
完成点がない。
新しい治療が生まれる。
新しい疾患が見える。
人口構造が変わる。
Technologyが変わる。
生命についてのKnowledgeも更新される。
⸻
だから、
Healthcare Architectureも更新され続ける。
⸻
病院は、
固定された施設から、
NetworkのNodeになる。
医療者は、
Knowledge保持者から、
生命への判断・翻訳主体へ広がる。
Healthcareは、
病院から日常へ広がる。
製薬は、
製品開発からLearning Cycleへ変わる。
AIは、
答えを出す主体ではなく、
Potentialを探索する知性になる。
⸻
そして、
患者は、
Systemの末端にいる受益者ではない。
生命Future Stateの中心主体
になる。
⸻
患者の意思。
生活。
価値観。
Outcome。
そこから、
医療Systemを再設計する。
⸻
これが、
Generative Healthcareである。
⸻
第7章では、
産業を未来生成装置として見た。
第8章では、
その生成能力を生命へ接続した。
ここで第Ⅳ部の構造は、
一つにつながる。
⸻
Future Potential
→ Capital
→ Industry
→ Technology
→ Healthcare
→ Life Reality
しかし、
生命Realityから、
再び新しいKnowledgeが生まれる。
⸻
Life Reality
→ Data / Knowledge
→ Research
→ New Potential
循環は閉じない。
次の未来へ開いていく。
⸻
そして、
未来を生成するためには、
産業と生命だけでは足りない。
まだ存在していないKnowledgeを発見し、
次世代へ渡し、
社会へ翻訳する主体が必要になる。
大学。
科学。
研究機関。
学校。
教育。
⸻
次の第Ⅴ部では、
未来を先に知り、
学び、
表現する
知性・文化
へ進む。
Generative Healthcareによって生命へ届いたFuture Pullは、
ここから、
Knowledgeそのものの生成へ向かう。
愛と敬意を込めてmandala
