第1冊『株式会社EQUES』――松尾研発AIスタートアップは、研究・製薬・エネルギー・量子・フィジカルAIをどう社会実装するのか（第6回）（第Ⅴ部 Human & Organization 第5章 AIを人と組織へ実装する――AI×DX寺子屋と現場定着）
第Ⅴ部 Human & Organization
――AIを人と組織へ実装する
AIの社会実装は、Technologyを導入した時点では完成しない。
高性能なModelを開発する。
Enterprise Dataへ接続する。
Cloud上へSystemを構築する。
Securityを整える。
業務Applicationを提供する。
それでも、現場で使われなければ価値は生まれない。
AIを利用するHumanが理解し、Organizationが業務Processを変え、継続的に運用できる状態になって初めて、Technologyは社会の内部へ定着する。
EQUESの事業を考えるとき、このHuman & OrganizationというLayerは見落とせない。
⸻
第Ⅲ部では、製薬AIを通じて、
Model → Evaluation → Product → Enterprise Workflow
という流れを見た。
第Ⅳ部ではさらに、
Sensor → AI → Human → Robot → Physical Environment
へ対象が広がった。
しかし、どちらにも共通して存在していた主体がある。
Humanである。
品質保証担当者がAIの生成結果を確認する。
Domain Expertが評価基準を定義する。
EngineerがSystemを運用する。
OperatorがRobotを監督する。
Managerが導入範囲を決める。
AIはHumanを取り除いたところで成立しているのではない。
Humanの仕事の中へ組み込まれることで初めて機能している。
⸻
AI導入はTechnology Projectだけではない
企業がAIを導入するとき、最初に議論されやすいのはTechnologyである。
どのLLMを使うか。
RAGを導入するか。
Fine-tuningするか。
CloudかLocalか。
どの程度のAccuracyが出るか。
もちろん、これらは重要である。
しかしProductionへ進むほど、別の問題が大きくなる。
誰が使うのか。
どの業務で使うのか。
どこまでAIへ任せるのか。
誰がOutputを確認するのか。
Errorが起きたらどうするのか。
従来の業務Processをどう変更するのか。
EmployeeはAIを理解しているのか。
つまり問題は、
AI Technology
から、
AI-enabled Organization
へ移る。
⸻
PoCが成功しても導入が成功するとは限らない
AI Projectでは、PoCで高い性能が確認できても、その後Productionへ進まないことがある。
技術的には動く。
しかしWorkflowに合わない。
User Interfaceが使いにくい。
現場に新しい作業が増える。
責任範囲が曖昧になる。
Security Ruleに適合しない。
Employeeが利用しない。
こうした問題が起こる。
したがって、
Technical Feasibility ≠ Organizational Adoption
である。
第Ⅱ部で見た伴走型開発の意味もここにある。
PoCを作ることだけではなく、そのTechnologyをOrganizationの中で使える形へ変換しなければならない。
⸻
AIは既存業務へ追加するだけではない
新しいAI Toolを既存Workflowの最後へ追加するだけでは、十分な効果が得られない場合がある。
例えば、HumanがDocumentを最初から最後まで作った後、AIにも同じDocumentを生成させるなら、単純に作業が増える。
必要なのは、
どこをHumanが担当するか。
どこをAIが担当するか。
どこを自動化するか。
どこでHuman Reviewを置くか。
を再設計することである。
つまり、
AI Adoption = Workflow Redesign
でもある。
⸻
Humanの役割は消えるのではなく変わる
生成AIによって「Humanの仕事がなくなる」という議論が繰り返される。
しかし、高信頼産業を見ると、より複雑な変化が起きる。
Humanがすべてを書く状態から、
AIがDraftしHumanがReviewする状態へ。
HumanがすべてのDataを見る状態から、
AIが異常候補を抽出しHumanが判断する状態へ。
HumanがRobotをすべて操作する状態から、
AIが一部を支援しHumanが監督する状態へ。
つまり、
Doer → Reviewer → Supervisor → Decision Maker
という役割変化が起こり得る。
HumanがSystemから消えるのではなく、Humanが担当する判断の位置が変わるのである。
⸻
Domain Expertが重要になる
AIが高度になるほど、AI EngineerだけでSystemを作れるようになるとは限らない。
むしろ産業実装ではDomain Expertの重要性が増す。
製薬なら、
GMP。
品質保証。
製造。
Regulation。
Energyなら、
設備。
Maintenance。
Safety。
原子力なら、
Radiation。
Remote Operation。
Facility-specific Knowledge。
AI EngineerはAlgorithmを理解していても、現場の「何が重要か」を自動的には知ることができない。
そこで、
AI Expert × Domain Expert
という共同設計が必要になる。
⸻
Tacit Knowledgeをどう扱うか
OrganizationのKnowledgeはDocumentだけに存在しているわけではない。
熟練者が経験によって知っていること。
異常時にどこを見るか。
どの順序で確認するか。
どの兆候を危険と感じるか。
こうしたTacit Knowledgeが存在する。
AI導入は、このKnowledgeを発見する機会にもなる。
Interviewする。
Workflowを観察する。
Decision Processを分解する。
Document化する。
Knowledge Baseへ蓄積する。
つまり、
Tacit Knowledge → Explicit Knowledge → Digital Knowledge
というKnowledge Transferが起こる。
⸻
AI Literacy
一方、AIを利用する側にも新しいKnowledgeが必要になる。
AIは必ず正しいわけではない。
Hallucinationがある。
InputによってOutputが変わる。
Confidential Dataを不用意に入力してはいけない。
生成結果を確認する必要がある。
用途によってRiskが異なる。
こうした基本的なAI Literacyがなければ、高性能なSystemを導入しても安全に利用できない。
したがってAI Educationは、Technology普及の周辺活動ではない。
AI Governanceの一部でもある。
⸻
AI×DX寺子屋
この文脈で見ると、EQUESが展開するAI×DX寺子屋の意味が明確になる。
AIを開発するだけでなく、HumanがAIを理解し、実際の課題へ適用する能力を形成する。
企業。
自治体。
教育機関。
それぞれに必要なAI LiteracyやProblem-solving Capabilityを育てる。
これはTraining Businessとして独立して見ることもできる。
しかしEQUES全体の構造から見ると、
Technology Adoption Layer
として位置づけることができる。
⸻
Learningは導入前だけではない
AI Trainingを一度行えばOrganizationがAI-readyになるわけではない。
Modelが変わる。
Toolが変わる。
Ruleが変わる。
業務が変わる。
新しいUse Caseが生まれる。
したがってHuman側も継続的に学習する必要がある。
AI Learning
と、
Human Learning
が並行して進む。
AI Systemだけを更新し、Organizationを更新しなければ両者のGapは広がる。
⸻
OrganizationもFeedback Loopを持つ
AI導入後には、現場から多くのFeedbackが生まれる。
このOutputは使える。
ここでは間違いやすい。
この操作は面倒である。
このDataが足りない。
この業務ならもっとAutomationできる。
こうしたFeedbackをDevelopment Teamへ戻す。
すると、
Development
→ Deployment
→ Use
→ Feedback
→ Improvement
というLoopが形成される。
伴走型開発とは、このLoopを継続するBusiness Modelでもある。
⸻
TechnologyとOrganizationのCo-evolution
ここまで進むと、AI導入を一方向のProcessとして見ることができなくなる。
AIがOrganizationを変える。
OrganizationがAIへ新しいRequirementを返す。
AIが改善される。
Workflowが再び変わる。
つまり、
Technology ⇄ Organization
という相互変化が起こる。
社会実装とは、完成したTechnologyをOrganizationへ「入れる」ことではない。
両者を適合させ続けるProcessである。
⸻
教育は将来のUserを作る
EQUESの教育活動が企業だけでなく学校や若い世代へ広がることにも意味がある。
AIを利用する人材を育てるだけではない。
AIを使ってProblemを発見する。
課題を分解する。
試す。
結果を評価する。
改善する。
こうしたProblem-solving Processそのものを経験する。
AI Educationは、
How to use AI
から、
How to solve problems with AI
へ進む必要がある。
⸻
HumanをAI Architectureへ戻す
ここまでの議論を最小化すると、AI Systemは次のようになる。
Data
↓
AI
↓
Human
↓
Organization
↓
Action
↓
Feedback
HumanはAI Systemの外側にいる「利用者」だけではない。
Reviewer。
Approver。
Operator。
Domain Expert。
Manager。
Learner。
としてSystem Architectureの内部へ存在する。
この視点を持つと、AI社会実装の定義も変わる。
⸻
社会実装の最小条件
AIが社会へ定着するためには、
Technology
だけでは足りない。
Technology
× Human Capability
× Workflow
× Organization
× Governance
が必要になる。
どれか一つが欠ければ、PoCでは動いてもProductionでは続かない可能性がある。
EQUESの伴走型技術開発、製薬AI、Physical AI、AI×DX寺子屋を横断して見ると、この構造が浮かび上がる。
⸻
第Ⅴ部で問うこと
本部では、EQUESのHuman & Organization Layerを分析する。
なぜAI導入はTechnologyだけでは成功しないのか。
AI×DX寺子屋は何を担うのか。
AI×DX寺子屋 Learningはどのように継続学習へ接続するのか。
企業のAI人材は何を学ぶべきなのか。
学校や地域でAI Educationを行う意味は何か。
そして、Humanを含めたAI社会実装とは何か。
中心となる問いは一つである。
AIを作ることと、AIが使われ続けることの間には何が必要なのか。
第Ⅴ部では、Technologyそのものから一度視点をHumanへ移す。
そして第5章「AIを人と組織へ実装する」を通じて、EQUESを単なるAI Development Companyではなく、TechnologyとHuman Organizationの間を接続する社会実装企業として読み解いていく。
第5章 AIを人と組織へ実装する
――AI×DX寺子屋と現場定着
第1節 AI導入はなぜ失敗するのか
AIの性能が高ければ、企業への導入も成功する。
必ずしもそうではない。
研究環境では高いAccuracyを示したModelが、現場では使われないことがある。PoCでは期待された生成AIが、本番導入まで進まないこともある。導入されたSystemが数か月後にはほとんど利用されなくなることもある。
問題は、AIの性能だけにあるのではない。
企業にAIを導入するという行為は、
Technologyを導入することではなく、仕事の仕組みを変更すること
だからである。
EQUESの伴走型技術開発やAI×DX寺子屋を理解するには、まずこの「導入の壁」を理解する必要がある。
⸻
AI導入には二つの成功がある
AI Projectでは、少なくとも二種類の成功を区別する必要がある。
一つは、
Technical Success
である。
Modelが期待した性能を出した。
必要なDataを処理できた。
Systemが動いた。
もう一つは、
Operational Success
である。
現場で実際に使われる。
業務時間が短縮される。
品質が改善する。
Userが継続利用する。
Organizationに定着する。
前者を達成しても、後者を達成できるとは限らない。
したがって、
Technical Success ≠ Business Success
である。
⸻
Problem Definitionが間違っている
AI導入が失敗する最初の原因は、TechnologyではなくProblem Definitionにある。
「生成AIを導入したい」
「AI Agentを使いたい」
「社内DataをLLMへ接続したい」
という要求からProjectが始まることがある。
しかし、それらはTechnologyの名前であってBusiness Problemではない。
本来問うべきなのは、
どの業務に時間がかかっているのか。
どこでErrorが起きているのか。
どのDecisionにInformationが不足しているのか。
どのKnowledgeが属人化しているのか。
である。
つまり、
Technology First
ではなく、
Problem First
でなければならない。
⸻
解く価値のないProblemを高精度で解く
AI Projectでは、技術的に興味深いProblemが選ばれやすい。
しかし企業にとって重要なのは、Technologyとして面白いかではない。
解決したときに価値があるかである。
Accuracyが99％でも、年間数時間しか発生しない業務ならInvestmentを回収できないかもしれない。
逆にAccuracyが完全でなくても、毎日数千回発生する業務のHuman Workloadを減らせれば大きな価値を生む場合がある。
したがって評価すべきなのは、
Model Performance × Operational Impact
である。
⸻
Dataが存在しない
AIはDataを必要とする。
しかし企業には、AIが利用しやすい形でDataが存在しているとは限らない。
PDF。
Excel。
Paper。
Email。
Legacy System。
個人PC。
口頭Knowledge。
複数SystemへInformationが分散している。
さらに、
Formatが違う。
表記が違う。
欠損している。
更新されていない。
権限が不明確である。
という問題がある。
AI導入Projectを始めた結果、実際にはAI開発よりData整理へ多くの時間を使うこともある。
⸻
Data QualityはAI Qualityになる
AI Modelだけを高度化しても、Input Dataが不正確ならOutputも不安定になる。
古いManual。
誤ったMaster Data。
重複Document。
不完全なRecord。
これらをAIへ入力すれば、Modelはその問題を引き継ぐ。
つまり、
AI Quality ≤ Data Quality
という制約が存在する。
製薬でData Integrityが重要になる理由もここにある。
高信頼AIでは、Model以前にData Governanceが必要になる。
⸻
PoCの罠
PoCでは条件を限定できる。
小さなDataset。
少数User。
限定されたTask。
EngineerによるSupport。
このEnvironmentならAIが高性能に見える場合がある。
しかしProductionでは条件が変わる。
大量User。
例外処理。
古いData。
Security。
Access Control。
System Integration。
Monitoring。
Maintenance。
Support。
そこで、
PoC Environment ≠ Production Environment
というGapが現れる。
⸻
DemoとSystemは違う
生成AIでは特にDemoを作りやすい。
DocumentをUploadする。
質問する。
AIが答える。
一見するとSystemは完成したように見える。
しかしProductionでは、
誰がDocumentを登録するのか。
Versionはどう管理するのか。
古いDocumentをどう除外するのか。
Access Permissionはどうするのか。
AI Outputを誰が確認するのか。
Logをどこまで残すのか。
といった問題が現れる。
AI Demoを作ることと、Enterprise Systemを作ることは別の仕事である。
⸻
Workflowに入らない
AI Toolを作っても、Userが毎回別のApplicationを開かなければならない。
DataをCopy & Pasteする。
AI Outputをまた別Systemへ転記する。
このようなWorkflowでは、AIが一工程を短縮しても、全体としては効率化しない場合がある。
必要なのは、
AIをWorkflowへ追加すること
ではなく、
Workflowそのものを再設計すること
である。
QAIのような製薬AIでも、既存の品質業務やSystemとのIntegrationが重要になる理由はここにある。
⸻
現場を知らずに設計する
AI Engineerが業務Documentだけを読んでSystemを設計すると、実際の現場との差が生じることがある。
Manualには書かれていない判断。
例外処理。
暗黙の確認手順。
熟練者の経験。
Department間の調整。
これらが存在する。
つまり、
Documented Workflow ≠ Actual Workflow
である。
現場ObservationとDomain Expertとの対話が必要になる。
⸻
Humanを「抵抗勢力」と考えない
新しいTechnologyが使われないとき、
「現場が変化を嫌っている」
と説明されることがある。
しかしUserが使わないことには合理的な理由がある場合も多い。
AI Outputを確認する方が時間がかかる。
Errorが多い。
責任だけHumanに残る。
既存Toolより操作が複雑である。
自分の仕事にどう役立つか分からない。
この場合、問題はHumanの意識ではなくSystem Designにある。
⸻
Automation Paradox
AIが多くの通常業務を自動化すると、Humanが担当するのは例外的で難しいCaseに集中する。
するとHumanは、
普段は操作しない。
しかし問題が起きたときだけ高度な判断を要求される。
という状態になり得る。
これはAutomationのParadoxである。
したがってAI導入では、
Human Skillを残す。
Trainingする。
Escalation Ruleを明確にする。
ことが必要になる。
⸻
Automation Bias
反対に、AIが高精度になるほどHumanが過信する問題もある。
AIが言っているから正しい。
いつも正しかったから今回も正しい。
この心理がAutomation Biasである。
Human Reviewを置くだけでは解決しない。
Reviewする人が、
AIがどこで間違えるのか。
どのEvidenceを見るべきか。
どの条件なら疑うべきか。
を理解している必要がある。
⸻
責任の境界が曖昧になる
AIがRecommendationした。
HumanがApproveした。
問題が起きた。
誰が責任を持つのか。
AI Vendorか。
System Developerか。
Operatorか。
Managerか。
Organizationか。
この境界が曖昧なままでは、高Riskな業務ほど導入が進まない。
必要なのは、
AI Responsibility
という抽象論だけではなく、
Role / Authority / Approval / Escalation
を具体的に設計することである。
⸻
SecurityとPrivacy
AI導入では、便利さだけを先に追うとSecurity問題が後から現れる。
機密Dataをどこへ送るのか。
Model ProviderはDataをどう扱うのか。
誰がKnowledge BaseへAccessできるのか。
PromptやOutputを保存するのか。
Personal Informationを扱うのか。
高信頼産業では、これらをProduction直前に追加することは難しい。
Security by Design
が必要になる。
⸻
Costを見落とす
生成AIではAPIを呼べば簡単に動く。
しかし利用量が増えるとCostも増える。
Inference Cost。
Cloud Cost。
Vector Database。
Monitoring。
Human Review。
Maintenance。
Model Update。
Security。
Support。
AI導入では開発費だけでなく、
Total Cost of Ownership
を見る必要がある。
⸻
KPIがModel Accuracyだけになる
AI TeamがAccuracyを改善する。
しかしBusiness側は時間短縮を求めている。
このズレも導入失敗を生む。
評価指標は、
Accuracy。
Precision / Recall。
Latency。
Cost。
Human Review Time。
Error Reduction。
Adoption Rate。
Business Outcome。
など複数Layerで設計する必要がある。
つまり、
Model KPI → Workflow KPI → Business KPI
を接続する。
⸻
Managementと現場が分離する
経営層は「AIを導入したい」。
現場は「何に使うのか分からない」。
AI Teamは「Dataがない」。
IT部門は「Securityを確認したい」。
Legal部門は「Riskを評価したい」。
この状態ではProjectが進まない。
AI導入は一DepartmentだけのProjectではない。
Cross-functional Project
として設計する必要がある。
⸻
AI人材がいない、だけではない
企業のAI導入問題は、AI Engineer不足だけでは説明できない。
必要なのは複数の役割である。
AIを作る人。
Domainを知る人。
Dataを管理する人。
Securityを見る人。
AIを使う人。
結果を評価する人。
Business Valueを判断する人。
つまり必要なのは、
AI Talent
という一種類の人材ではなく、
AI-capable Organization
である。
⸻
Educationが必要になる理由
ここでAI×DX寺子屋の位置が見えてくる。
企業へAI Toolを渡すだけでは、Organizationは変わらない。
AIの基本を理解する。
自社のProblemを発見する。
AIで解ける部分と解けない部分を区別する。
小さく試す。
評価する。
改善する。
このCapabilityをHuman側に形成する必要がある。
EducationはAI導入の前段階ではない。
Implementation Processそのものの一部である。
⸻
EQUESの伴走型開発との接続
EQUESが伴走型技術開発を重視する理由も、この構造から理解できる。
顧客がRequirementを完全に定義し、EQUESがSystemを納品するだけではない。
Problemを整理する。
PoCする。
結果を見る。
Requirementを修正する。
Productionへ進む。
User Feedbackを得る。
改善する。
つまり、
Client ⇄ EQUES
のInteraction自体がDevelopment Processになる。
⸻
導入は一回では終わらない
AIは変化する。
Modelが更新される。
業務が変わる。
Dataが増える。
Regulationが変わる。
Userが新しい使い方を発見する。
したがってAI Systemは「完成品を納品して終了」という形だけでは維持しにくい。
必要なのは、
Deploy → Observe → Learn → Improve
という継続的な運用である。
⸻
AI導入失敗の最小構造
ここまでの原因を整理すると、AI導入の失敗はModelだけから生じない。
Problem
が間違う。
Data
が整っていない。
Technology
が現場条件に合わない。
Workflow
へ統合されない。
Human
が使えない。
Organization
の責任構造が曖昧である。
Governance
が追いつかない。
そして、
Feedback
がDevelopmentへ戻らない。
つまり、
AI Failure = System Failure
として理解する必要がある。
⸻
AI導入を社会実装へ変える
反対に、成功条件も見えてくる。
適切なProblemを選ぶ。
Dataを整える。
Technologyを選択する。
PoCで検証する。
Workflowを再設計する。
HumanをTrainingする。
Governanceを構築する。
Productionで観測する。
改善を続ける。
最小化すれば、
Problem
→ Design
→ PoC
→ Integration
→ Adoption
→ Operation
→ Improvement
となる。
これがAI社会実装のProcessである。
EQUESが研究と現場の間に立つ意味も、この長いChainを見れば理解できる。
研究成果を企業へ持ってくるだけでは足りない。
TechnologyがHumanとOrganizationの仕事として定着するところまで翻訳する必要がある。
そのためには、AI Systemの設計だけでなく、組織側の導入設計が必要になる。
次節では、この境界をさらに具体化し、技術導入と組織導入という二つのImplementationを分けて考える。
第2節 技術導入と組織導入
企業がAIを導入するとき、目に見えやすいのは技術である。
Modelを選ぶ。
Dataを整備する。
RAGを構築する。
Applicationを開発する。
CloudへDeployする。
既存Systemと接続する。
しかし、それだけではAI導入の半分しか完成していない。
もう一つ必要なのが、Organization側のImplementationである。
誰がAIを使うのか。
仕事の流れをどう変えるのか。
どこまでAIへ任せるのか。
誰が確認するのか。
新しい能力をどう学ぶのか。
責任をどう分担するのか。
EQUESのようにAIを企業の実務へ実装する会社にとって、Technology ImplementationとOrganizational Implementationは分離できない。
⸻
二つのImplementation
AI導入を最小化すると、二つのProcessがある。
Technology Implementation
と、
Organizational Implementation
である。
前者では、
Data。
Model。
Software。
Infrastructure。
Security。
Interface。
を構築する。
後者では、
People。
Role。
Workflow。
Rule。
Skill。
Responsibility。
を再設計する。
そして両者が接続したとき初めて、AIはProductionで機能する。
⸻
技術だけを導入した場合
例えば企業が高性能な生成AI Systemを導入したとする。
社内Documentを検索できる。
Reportを生成できる。
質問にも答えられる。
技術的には成功している。
しかしEmployeeが、
何に使ってよいか分からない。
Outputをどこまで信用してよいか分からない。
機密情報を入力してよいか分からない。
誰が確認すべきか分からない。
となれば利用は広がらない。
つまり、
System Available ≠ System Adopted
である。
⸻
Organizationだけ変えても足りない
反対も成立する。
経営層がAI活用を強く推進する。
研修を行う。
AI担当者を配置する。
新しいRuleを作る。
しかしSystemのAccuracyが低い。
Latencyが大きい。
UIが使いにくい。
必要なDataへAccessできない。
その場合も定着しない。
したがって、
Technology × Organization
の双方が一定水準を超える必要がある。
⸻
Workflowを先に見る
AI導入では、Modelより先にWorkflowを見ることが重要になる。
例えば製薬の品質保証業務なら、
情報を集める。
Documentを作成する。
内容を確認する。
修正する。
承認する。
保存する。
監査に備える。
というProcessがある。
この中のどこへAIを入れるのか。
Document Generationなのか。
Consistency Checkなのか。
Knowledge Retrievalなのか。
すべてを一度に自動化する必要はない。
まずWorkflowを分解し、AIが価値を出せる場所を特定する。
⸻
Taskを分解する
一つの「仕事」は多数のTaskからできている。
例えばReport作成でも、
Data Collection。
Classification。
Drafting。
Fact Checking。
Formatting。
Approval。
がある。
AIが得意なTaskとHumanが担当すべきTaskは異なる。
そこで、
Job → Tasks → Human / AI Allocation
という分解を行う。
AI導入とはJobそのものを消すことではなく、Task Allocationを再設計することでもある。
⸻
Human–AI Division of Labor
AIは大量処理に強い。
検索に強い。
Draft Generationに強い。
Pattern Detectionに強い。
HumanはContextを理解する。
例外へ対応する。
価値判断を行う。
責任を引き受ける。
Domain-specificな暗黙知を使う。
したがって、
AI does what AI is good at.
Human does what Human must do.
という役割分担を設計する。
重要なのはAIの能力を最大化することではなく、System全体のPerformanceを最大化することである。
⸻
Humanの仕事は上流へ移る
AIがRoutine Taskを担当すると、Humanの仕事はより上位へ移る可能性がある。
作成から確認へ。
検索から判断へ。
入力から例外処理へ。
操作から監督へ。
つまり、
Execution → Judgment
への移動である。
しかし、この変化は自動的には起こらない。
Humanが新しい役割を学ばなければならない。
⸻
Role Definition
AI導入後には、新しいRoleが必要になることもある。
AI User。
Domain Reviewer。
AI Product Owner。
Data Steward。
Model Operator。
Security Administrator。
Approval Authority。
すべてを新しいJob Titleとして設ける必要はない。
重要なのは、
誰が何を担うのか
を明確にすることである。
曖昧なRoleは、AIのErrorより先に運用上のFailureを生む。
⸻
Authorityを設計する
Roleだけでは足りない。
誰が何を決められるのかも必要になる。
AIがRecommendationする。
担当者がReviewする。
ManagerがApproveする。
SystemがExecuteする。
Critical CaseはExpertへEscalateする。
このように、
Recommendation → Review → Approval → Execution
というAuthority Chainを設計する。
高信頼産業では特に重要になる。
⸻
AI Policy
Organizationには共通Ruleも必要になる。
利用可能なAI Tool。
入力してよいData。
禁止される用途。
Human Reviewが必要な用途。
Logを保存する期間。
Incident発生時のReporting。
Model UpdateのProcedure。
こうしたPolicyによって、Employeeが毎回ゼロから判断する必要を減らせる。
Governanceとは、AI利用を禁止する仕組みではない。
安全に利用できる範囲を明確にする仕組みである。
⸻
CentralizedかDecentralizedか
AI導入には二つの極端がある。
すべてを中央AI Teamが管理する。
あるいは、各Departmentが自由にAIを使う。
前者は統制しやすいが、現場のSpeedを失う可能性がある。
後者はInnovationが速いが、Securityや重複投資の問題が生じる。
そこで、
Central Governance + Local Experimentation
という構造が考えられる。
共通RuleとInfrastructureは中央で整備し、Use Caseは現場から生み出す。
⸻
Championを作る
AI導入では、各DepartmentにTechnologyと業務の両方を理解する人材がいると強い。
AI Engineerである必要はない。
自分の業務を理解し、
AIで何ができるかを知り、
同僚へ説明し、
Development TeamへRequirementを返せる。
こうした人材を、
AI Champion。
Digital Champion。
などと位置づけることができる。
彼らはTechnologyとOrganizationのTranslatorになる。
⸻
Trainingは操作説明ではない
AI研修というと、
Promptの書き方。
Toolの使い方。
が中心になりやすい。
もちろん必要である。
しかし組織導入では、さらに、
AIが得意なこと。
苦手なこと。
Hallucination。
Privacy。
Security。
Evaluation。
Human Review。
Problem Definition。
を理解する必要がある。
つまり、
Tool Training
から、
AI Capability Building
へ広げる。
⸻
AI×DX寺子屋との接続
EQUESが展開するAI×DX寺子屋は、このCapability Buildingという位置から理解できる。
単にAIの知識を教えるだけならEducation Serviceである。
しかし企業のAI社会実装という文脈では、
Human側のImplementation Infrastructure
として見ることができる。
AIを理解する人を増やす。
自分たちのProblemを発見できるようにする。
小さなUse Caseを作る。
試す。
評価する。
現場へ戻す。
このProcessそのものがOrganization Transformationになる。
⸻
Bottom-upとTop-down
AI導入にはTop-downとBottom-upの双方が必要になる。
Top-downでは、
経営方針。
Investment。
Risk Appetite。
Infrastructure。
Governance。
を決める。
Bottom-upでは、
現場課題。
Use Case。
Experiment。
User Feedback。
改善案。
が生まれる。
どちらか一方だけでは弱い。
Management Direction ⇄ Frontline Learning
という循環を作る必要がある。
⸻
小さく始める意味
組織全体を一度にAI化する必要はない。
むしろ小さなProblemから始める方が合理的である。
一つの業務。
一つのDepartment。
一つのDocument。
一つのDecision Support。
そこで効果とRiskを確認する。
成功したら広げる。
これは第Ⅱ部で見たPoCの考え方と同じである。
ただし、ここで試しているのはTechnologyだけではない。
OrganizationもPoCしている。
⸻
Organizational PoC
AI導入では、
Modelは使えるか。
だけでなく、
Humanは使えるか。
Workflowへ入るか。
Approval Processは機能するか。
Trainingは十分か。
Supportは必要か。
を試す。
つまり、
Technical PoC + Organizational PoC
である。
この二つを同時に行うことでProductionへのGapを小さくできる。
⸻
User Feedbackを開発へ戻す
Systemを実際に使うと、設計時には見えなかった問題が分かる。
このButtonはいらない。
このEvidenceを表示してほしい。
このTaskではAIを使わない方が速い。
このDocumentも検索対象にしたい。
こうしたFeedbackをDevelopmentへ戻す。
User → Product → Engineering
のLoopが必要になる。
AI ProductはDeveloperだけが完成させるものではない。
Userとの共同開発によって成熟する。
⸻
KPIも二つ必要になる
技術導入にはTechnical KPIがある。
Accuracy。
Recall。
Latency。
Availability。
Cost。
組織導入にはAdoption KPIがある。
Active Users。
Usage Frequency。
Task Completion Time。
Human Correction Rate。
Training Completion。
User Satisfaction。
さらにBusiness KPIとして、
Cost Reduction。
Quality Improvement。
Risk Reduction。
Revenue Impact。
などを見る。
つまり、
Technical KPI
→ Adoption KPI
→ Business KPI
を接続する。
⸻
導入率だけを成功としない
AI ToolをEmployeeの80％が使ったから成功、とは限らない。
簡単な文章作成にしか使われていないかもしれない。
反対にUser数は少なくても、Criticalな専門業務で大きな効果を生んでいる可能性もある。
重要なのは、
Usage Volume
だけでなく、
Value Created
である。
組織導入の目的はAIを使わせることではない。
仕事を改善することである。
⸻
Middle Managementの重要性
経営層がAI Strategyを決め、現場EmployeeがToolを使っても、その間をつなぐManagerが理解していなければTransformationは進みにくい。
Managerは、
業務を再設計する。
Roleを変更する。
Performanceを評価する。
Riskを管理する。
現場のFeedbackを上へ伝える。
したがってMiddle Managementは、AI Transformationにおける重要なTranslation Layerになる。
⸻
KnowledgeをOrganizationへ残す
外部VendorがAI Systemを作り、すべてのKnowledgeを持って帰ってしまえば、顧客Organizationは自律的に改善できない。
伴走型開発では、
なぜこのArchitectureなのか。
どのDataが重要なのか。
どこでModelが失敗するのか。
どう評価するのか。
というKnowledgeを顧客側にも蓄積することが重要になる。
つまり、
System Transfer + Knowledge Transfer
である。
⸻
Vendor Dependenceをどう考えるか
高度なAIをすべて内製する必要はない。
しかし、何も理解せず外部へ丸投げするのもRiskがある。
企業が内部に保持すべきなのは、必ずしもModel Development Capabilityではない。
少なくとも、
Problem Definition。
Data Ownership。
Evaluation Criteria。
Risk Judgment。
Vendor Management。
を理解するCapabilityが必要になる。
AI時代の内製化とは、すべてを自分でProgramすることではない。
重要なDecision Capabilityを内部に保持することである。
⸻
Organizationも学習する
AI SystemがFeedbackから改善するように、Organizationも経験から学習する。
最初のProjectで失敗する。
原因を分析する。
AI Policyを修正する。
Trainingを変える。
次のProjectへ反映する。
すると、
Project Experience → Organizational Knowledge
へ変換される。
一つ一つのAI Projectが、次の導入Costを下げる。
これが組織的なLearning Curveである。
⸻
AI導入能力そのものが資産になる
このLearningが蓄積すると、企業には目に見えにくいCapabilityが形成される。
AI Use Caseを発見できる。
PoCを短期間で回せる。
Riskを評価できる。
Dataを準備できる。
Human Reviewを設計できる。
Productionへ移行できる。
つまり、
AI Adoption Capability
そのものが企業資産になる。
長期的には、個々のModelよりこちらの方が重要になる可能性がある。
Modelは変わるからである。
⸻
EQUESの役割を再定義する
ここからEQUESの伴走型開発と教育事業を一つの構造として見ることができる。
EQUESがTechnologyを提供する。
顧客がDomain Knowledgeを提供する。
両者でProblemを定義する。
PoCする。
現場へ導入する。
HumanをTrainingする。
Feedbackを得る。
Systemを改善する。
その過程で顧客OrganizationにもAI Capabilityが蓄積される。
つまりEQUESは、
AIを納品する会社
だけではなく、
顧客がAIを使えるOrganizationへ変化する過程を支援する会社
として読むことができる。
⸻
二つのImplementationを接続する
最終的な構造は明快である。
Technology Implementation
Data
→ Model
→ Software
→ Infrastructure
と、
Organizational Implementation
Human
→ Skill
→ Workflow
→ Governance
を接続する。
その中央にあるのが、
Operational Adoption
である。
式にすれば、
AI Implementation
= Technology Implementation
× Organizational Implementation
となる。
どちらかがゼロなら、社会実装全体の価値も限りなく小さくなる。
⸻
AI導入の難しさは、AIが未熟だからだけではない。
企業というHuman Systemの中へ、新しいTechnologyを組み込むこと自体が難しいのである。
だからこそ、EQUESのHuman & Organization Layerでは、System Developmentと同じくらいLearningが重要になる。
次節では、そのLearningを独立した仕組みとして展開するAI×DX寺子屋へ進み、EQUESがなぜAI Development CompanyでありながらEducationへ取り組むのかを見ていく。
第3節 AI×DX寺子屋
AIを企業へ導入するために必要なのは、AI Engineerだけではない。
実際に業務を知る人がAIを理解し、自分たちの課題とTechnologyを結びつけられることが重要になる。
どこに時間がかかっているのか。
どの業務が属人化しているのか。
どの判断に大量のInformationが必要なのか。
何をAIへ任せ、何をHumanが担うべきなのか。
こうした問いに答えられるのは、必ずしもAIの専門家ではない。現場で仕事をしているHumanである。
EQUESが展開する「AI×DX寺子屋」は、このHuman側の能力形成を担う取り組みとして位置づけることができる。
⸻
「AIを教える」だけではない
AI Educationというと、Technologyの解説を想像しやすい。
Machine Learningとは何か。
生成AIとは何か。
LLMとは何か。
Promptをどう書くか。
もちろん、こうした基礎知識は必要である。
しかし企業で重要なのは、その先である。
自分たちの仕事にどう使うのか。
AI×DX寺子屋をEQUESの社会実装体系の中で見るなら、単なるTechnology Educationではなく、
AI Literacy → Problem Discovery → Experiment → Implementation
へ進む入口として理解できる。
⸻
寺子屋という形式
「寺子屋」という名称は興味深い。
高度なAI研究を専門家だけの閉じた領域にせず、学習する人がTechnologyへ接近できる場を作る。
質問する。
試す。
分からないところを確認する。
自分の業務へ当てはめる。
このようなInteractiveなLearningは、完成した教材を一方向に視聴するだけのEducationとは性格が異なる。
AIは変化が速い。
したがって、固定された知識だけではなく、
新しいTechnologyを自分で理解し続ける能力
が重要になる。
⸻
AI Literacyの第一段階
最初に必要なのは、AIを過大評価も過小評価もしないことである。
生成AIは高度な文章を作れる。
Documentを要約できる。
情報を整理できる。
Codeも生成できる。
一方で、
Hallucinationする。
古いInformationを使うことがある。
曖昧な指示では結果が変わる。
専門領域では検証が必要になる。
この両面を理解する。
つまりAI Literacyとは、
AIを信じる能力ではなく、AIを適切に評価しながら使う能力
である。
⸻
PromptよりProblem
生成AI研修ではPrompt Engineeringが注目されやすい。
しかし、良いPromptを書けても、解くべきProblemを見つけられなければBusiness Valueは生まれない。
重要なのは、
この業務はなぜ必要なのか。
どこに時間がかかっているのか。
どこでQualityが落ちるのか。
何が定型化できるのか。
どこにHuman Judgmentが必要なのか。
を考えることである。
したがって教育の中心も、
How to prompt
だけではなく、
What problem should we solve?
へ進む必要がある。
⸻
業務を分解する
例えば「Reportを作成する」という仕事がある。
それを一つのTaskとして見ると、AIを使えるかどうか判断しにくい。
しかし分解すると、
Dataを集める。
過去Documentを検索する。
重要事項を抽出する。
Draftを書く。
数値を確認する。
内容をReviewする。
承認する。
という複数Taskになる。
すると、
検索はRAG。
DraftはLLM。
数値確認は既存System。
最終判断はHuman。
という役割分担が見えてくる。
教育を通じて身につけるべきなのは、このTask Decompositionの能力でもある。
⸻
AI Use Caseを発見する
企業には、AIを利用できる場所が大量に存在する。
しかしすべてをAI化する必要はない。
頻度が高い。
時間がかかる。
定型性が高い。
大量のInformationを扱う。
Human Errorが発生しやすい。
こうした業務から候補を見つける。
その後、
Impact。
Feasibility。
Risk。
Cost。
を比較する。
つまり、
Use Case Discovery → Prioritization
である。
AI×DX教育が実務へ接続するには、この選択能力が重要になる。
⸻
小さく試す
Use Caseを見つけたら、最初から大規模Systemを作る必要はない。
既存の生成AI Toolで試す。
Sample Dataで確認する。
小さなPrototypeを作る。
数人で使う。
結果を評価する。
ここでは、第Ⅱ部で見た「ココロミ」と同じ考え方が現れる。
Learn → Try → Evaluate
である。
教育とPoCは別々ではない。
LearningからExperimentへ自然に移行できることが重要になる。
⸻
失敗をLearning Dataへ変える
AI Educationでは、成功例だけを学ぶべきではない。
AIが間違えた。
必要なInformationを見つけられなかった。
もっともらしい誤情報を生成した。
期待したFormatにならなかった。
この失敗を分析する。
Promptの問題なのか。
Dataの問題なのか。
Modelの限界なのか。
Task Definitionが間違っているのか。
すると、
Failure → Analysis → Learning
になる。
これはAIを安全に使う能力を形成するうえで重要である。
⸻
Security Literacy
企業でAIを使う場合、便利だからという理由だけでPublic AI ServiceへDataを入力することはできない。
Personal Information。
Confidential Information。
Intellectual Property。
Research Data。
Customer Data。
これらをどこまで扱えるか理解する必要がある。
したがってAI Educationには、
Privacy。
Security。
Access Control。
Data Governance。
も含まれる。
AI LiteracyはTechnology Literacyだけではない。
⸻
高信頼産業では教育の意味が変わる
製薬のような規制産業では、AIの使い方を知っているだけでは不十分である。
AIが生成したDocumentを誰が確認するのか。
どのEvidenceを参照したのか。
どのVersionのInformationを使ったのか。
どのProcessでApproveするのか。
を理解する必要がある。
つまりTrainingは、
Product Training
から、
Operational Assurance Training
へ広がる。
EQUESが製薬AIと教育の双方を持つことには、この点でも接続可能性がある。
⸻
Domain ExpertをAI Userへ
すべてのDomain ExpertをAI Engineerにする必要はない。
品質保証担当者がPythonを書く必要もない。
Energy EngineerがLLMをTrainingする必要もない。
重要なのは、
AIに何を依頼できるか。
Outputをどう評価するか。
どこでHuman Judgmentが必要か。
を理解することである。
つまり、
Domain Expert + AI Literacy
という人材を増やす。
これは産業AIの普及にとって重要な条件になる。
⸻
AI EngineerもDomainを学ぶ
Learningは一方向ではない。
Domain ExpertだけがAIを学ぶのではない。
AI Engineerも顧客業務を学ぶ。
製薬の品質保証。
GMP。
Energy Infrastructure。
Safety。
現場のWorkflow。
すると、
AI Expert → Domain
と、
Domain Expert → AI
の双方からTranslationが進む。
両者の間に共通Languageが形成される。
これが伴走型開発を速くする。
⸻
AI Championを育てる
すべてのEmployeeが同じ深さでAIを理解する必要はない。
Organizationの各部門に、
AIに詳しい。
業務にも詳しい。
同僚から相談される。
AI Teamと会話できる。
小さなExperimentを主導できる。
という人材がいると、導入は進みやすくなる。
こうしたAI Championは、
Technologyと現場を接続するLocal Translator
になる。
教育は、その人材を発見し育てる機会にもなる。
⸻
CommunityとしてのLearning
AIの変化速度を考えると、一度のTrainingですべてを学ぶことは難しい。
昨日まで最先端だったModelが更新される。
新しいAgent Frameworkが登場する。
新しいRiskが見つかる。
新しいUse Caseが生まれる。
そこで有効になるのがCommunity型のLearningである。
誰かが試す。
結果を共有する。
別の人が応用する。
失敗も共有する。
すると、
Individual Learning → Collective Learning
へ変わる。
⸻
KnowledgeをOrganizationへ蓄積する
Employeeが個人的にAIを使えるようになるだけでは、Knowledgeはその人に閉じる。
そこで、
有効だったPrompt。
Use Case。
失敗例。
Evaluation Method。
Security Rule。
Workflow。
をOrganizationへ蓄積する。
すると、
Personal Know-how → Organizational Knowledge
へ変換される。
このKnowledge Baseは、次のAI導入を速くする。
⸻
教育からDevelopmentへ
AI×DX寺子屋の重要な可能性は、LearningとDevelopmentの距離を縮めることにある。
研修中に、
「この業務にも使えるのではないか」
というIdeaが出る。
小さく試す。
効果が見える。
本格的なPoCへ進む。
必要ならEQUESの技術開発へ接続する。
つまり、
Education
→ Use Case
→ Experiment
→ PoC
→ Production
というPipelineを形成できる。
教育がBusiness Developmentの入口にもなり得る。
⸻
Developmentから教育へ戻る
反対方向もある。
実際のAI Projectで得られたKnowledgeをTrainingへ戻す。
どこで失敗したか。
何が重要だったか。
どのようなRiskがあったか。
どのWorkflowが有効だったか。
すると、
Project Experience → Educational Knowledge
へ変換される。
教育と開発が循環する。
⸻
学校・地域への展開
AI Literacyの必要性は企業だけに限定されない。
学校では、AIを単に答えを生成するToolとして使うのではなく、
課題を見つける。
調査する。
仮説を作る。
AIと対話する。
結果を検証する。
他者と協働する。
というProblem-solving Toolとして利用できる。
地域では、Local Businessや行政課題と結びつけることもできる。
ここではAI Educationが、将来のWorkforce Formationへ接続する。
⸻
若い世代とAI Agent
生成AIがAgent化すると、教育内容も変わる。
一つの質問へ答えるAIから、
Goalを与える。
Taskを分解する。
Toolを使う。
情報を取得する。
結果を統合する。
というAIへ進む。
Human側にも、
Goal Setting。
Task Design。
Verification。
Coordination。
という能力が求められる。
AI Educationは、操作教育からAIとの協働設計へ進むことになる。
⸻
教育はAI導入Costを下げる
AI LiteracyがOrganizationに蓄積されると、次のProjectは始めやすくなる。
Requirementを説明できる。
Use Caseを選べる。
Riskを理解できる。
AI Outputを評価できる。
EngineerとのCommunicationが速くなる。
したがって教育はCost Centerだけではない。
長期的には、
Future Implementation Costを下げるInvestment
として見ることができる。
⸻
EQUESにとっての意味
EQUESはResearch-originのAI Companyである。
だからこそ、教育事業は一見するとCore Technologyから離れているように見える。
しかし社会実装という観点では逆である。
Researchを理解する人がいる。
Technologyを作る人がいる。
Industry Problemを知る人がいる。
AIを使う人がいる。
これらを接続しなければTechnologyは社会へ広がらない。
AI×DX寺子屋は、その中でHuman側のInterfaceを担う。
⸻
「教える会社」ではなく「学べる組織を作る会社」
さらに一段抽象化すると、Educationの最終目的は知識を一回伝えることではない。
Technologyは変化し続ける。
したがって重要なのは、
新しいAIを自分で理解する。
試す。
評価する。
共有する。
業務へ取り込む。
というLearning CapabilityをOrganizationに形成することである。
つまり、
Teaching AI
から、
Building a Learning Organization
へ進む。
⸻
AI×DX寺子屋の位置
EQUES全体の構造へ戻すと、
伴走型技術開発は、
Technology Implementation
を担う。
製薬AIやPhysical AIは、
Domain Implementation
を担う。
そしてAI×DX寺子屋は、
Human Capability Development
を担う。
三つが接続すると、
Technology
→ Human Learning
→ Experiment
→ Implementation
→ Operation
→ Feedback
→ New Learning
という循環が形成される。
AIを社会へ実装するという仕事は、Systemを作るだけでは終わらない。
そのSystemとともにHumanが学習できる状態を作ることまで含まれる。
AI×DX寺子屋は、そのための入口である。
そして一度のWorkshopや研修だけでは、急速に変化するAI Technologyへ継続的に対応することは難しい。
次節では、このLearningを継続的な仕組みへ変えるAI×DX寺子屋 Learningへ進み、AI Educationが単発研修からContinuous Learning Infrastructureへどのように展開し得るのかを見ていく。
第4節 AI×DX寺子屋 Learning
AIを学ぶという行為そのものが変わり始めている。
従来の企業研修では、あるTechnologyについて体系的な教材を作り、Employeeが一定期間で学習する方法が一般的だった。
しかしAIでは、その前提が成立しにくい。
Modelが更新される。
新しい生成AI Serviceが登場する。
RAG、Multimodal AI、AI Agentなど利用方法が変わる。
SecurityやGovernanceについても、新しい論点が次々に生まれる。
半年、一年前のKnowledgeが完全に無意味になるわけではない。しかし、固定された教材だけで最新のAI活用を追い続けることは難しい。
そこで必要になるのが、
One-time TrainingからContinuous Learningへの転換
である。
EQUESが展開する「AI×DX寺子屋 Learning」は、この継続学習という観点から位置づけることができる。
⸻
WorkshopからLearning Infrastructureへ
前節で見たAI×DX寺子屋は、AIへ触れ、質問し、Problemを発見し、実際に試す入口として機能する。
しかし一度のWorkshopだけでは、OrganizationのAI Capabilityは十分に形成されない。
学んだ内容を現場へ持ち帰る。
実際に使う。
分からないことが生まれる。
新しいUse Caseを発見する。
さらに学ぶ。
この繰り返しが必要になる。
そこで、
Workshop → Practice → Learning → Practice
という継続構造が必要になる。
AI×DX寺子屋 Learningは、AI教育をEventからProcessへ変える位置にある。
⸻
なぜe-learningなのか
企業には多数のEmployeeがいる。
勤務時間も違う。
AI KnowledgeのLevelも違う。
必要なUse Caseも異なる。
全員を同じ時間、同じ場所へ集めるTrainingだけではScaleしにくい。
e-learningなら、
必要な時間に学ぶ。
必要な内容を選ぶ。
繰り返し確認する。
Organization全体へ展開する。
ことができる。
つまり、
Learning Scalability
を高められる。
AIを一部の専門家だけのKnowledgeにしないためには重要な仕組みである。
⸻
全員をAI Engineerにしない
企業のAI Educationで重要なのは、Employee全員へ高度なMachine Learningを教えることではない。
必要なKnowledgeはRoleによって異なる。
一般Userには、
生成AIの基本。
安全な利用方法。
Outputの確認方法。
が必要になる。
Managerには、
Use Case Selection。
Business Impact。
Risk Management。
が必要になる。
Domain Expertには、
AI Evaluation。
Human Review。
Knowledge Design。
が重要になる。
Engineerには、
Model。
RAG。
API。
Security。
Evaluation。
が必要になる。
つまり、
One Curriculum for Everyone
ではなく、
Role-based Learning
へ進む必要がある。
⸻
AI Literacyを階層化する
Organization全体のAI Capabilityは、いくつかのLevelとして考えることができる。
最初は、
Understand
である。
AIとは何かを理解する。
次に、
Use
である。
実際の業務で安全に使う。
さらに、
Evaluate
へ進む。
AI Outputを検証する。
その先に、
Design
がある。
AIを使ったWorkflowを設計する。
そして一部の人材は、
Build
へ進む。
AI Systemそのものを構築する。
すべてのEmployeeがBuildへ到達する必要はない。
Organizationとして必要なLevelが揃っていることが重要である。
⸻
製薬では一般的なAI研修だけでは足りない
EQUESの特徴を考えると、AI×DX寺子屋 Learningを一般的な生成AI研修だけで捉えるのは十分ではない。
製薬では、
GMP。
品質保証。
Document Management。
Data Integrity。
Human Review。
Compliance。
といったDomain固有の条件が存在する。
同じ生成AIでも、Marketing Copyを作る場合と品質保証Documentを扱う場合ではRiskが違う。
したがって、
General AI Literacy + Domain-specific AI Literacy
という二層構造が必要になる。
⸻
Domain-specific Learning
例えば製薬企業で生成AIを使うなら、
どの業務で利用できるのか。
どのInformationを入力できるのか。
生成内容を誰が確認するのか。
Sourceをどう確認するのか。
Audit Trailをどう扱うのか。
といった実務Knowledgeが必要になる。
ここではAI EducationとProfessional Educationの境界が薄くなる。
AIだけを教えるのではなく、
AIを使った新しい業務方法
を学ぶからである。
⸻
Product Educationとの接続
QAI GeneratorやQAI CheckerのようなProductが現場へ導入される場合、Trainingはさらに具体的になる。
どの場面で利用するのか。
どのDataを入力するのか。
Outputをどう読むのか。
どこをHumanが確認するのか。
問題があった場合どうEscalateするのか。
ここでLearningは、
General Education
から、
Operational Training
へ接続する。
ProductとEducationが別々に存在するのではなく、Product AdoptionをLearningが支える。
⸻
「使い方」から「判断の仕方」へ
AI Toolの操作自体は、今後さらに簡単になる可能性が高い。
Natural Languageで指示できる。
AI Agentが複数Taskを実行する。
Interfaceが自動化される。
するとHumanに必要な能力は、Buttonの位置を覚えることではなくなる。
何をAIへ依頼するか。
Outputは妥当か。
Evidenceは十分か。
Humanが介入すべきか。
という判断能力が重要になる。
したがってLearningの中心は、
Operation Skill → Judgment Skill
へ移る。
⸻
Hallucinationを経験する
Hallucinationについて説明を読むだけでは、そのRiskを実感しにくい。
実際にAIへ質問する。
もっともらしい誤答を見る。
Sourceを確認する。
Promptを変える。
RAGを使う。
Human Reviewする。
こうしたExperienceによって、
「AIは便利だが検証が必要である」
という感覚が形成される。
AI Educationでは、正しい使い方だけでなく、
AIがどのように失敗するのかを学ぶこと
が重要になる。
⸻
Evaluation Literacy
AI時代には、生成能力だけでなく評価能力が重要になる。
AIの答えを読んで「良さそう」と判断するだけでは足りない。
Correctness。
Completeness。
Consistency。
Source Reliability。
Domain Compliance。
を確認する。
つまりHuman側にも、
Evaluation Literacy
が必要になる。
これはEQUESがJPharmaBenchのような評価側のTechnologyを開発してきた方向とも構造的に重なる。
AIを作る能力とAIを評価する能力は、両方必要になる。
⸻
Securityを継続的に学ぶ
AI Securityも一度Ruleを説明すれば終わりではない。
新しいToolが登場する。
Employeeが個人的に利用する。
AgentがExternal Serviceへ接続する。
AIがFileへAccessする。
Riskの形が変わる。
そこで、
入力してよいData。
利用可能なService。
Access Permission。
Incident Response。
などを継続的にUpdateする必要がある。
AI GovernanceもLearning Systemでなければならない。
⸻
Learning Dataを取る
e-learningには、もう一つ重要な特徴がある。
どの教材が利用されたか。
どこで理解が止まったか。
どのTopicへの関心が高いか。
どのDepartmentでLearningが進んでいるか。
といった情報を取得できる。
ただし、Employee Monitoringを目的化するべきではない。
重要なのは、
OrganizationのLearning Gapを発見すること
である。
⸻
Skill Gapを可視化する
例えばOrganization全体で生成AIの基本理解は進んでいる。
しかしSecurity Knowledgeが弱い。
あるDepartmentではAI利用が進んでいる。
別のDepartmentではUse Caseが見つからない。
こうした差が分かれば、
追加Training。
Workshop。
Expert Support。
PoC。
を配置できる。
Learning Dataが次のEducation Designへ戻る。
つまり、
Learn → Measure → Improve Learning
というFeedback Loopが成立する。
⸻
Personalized Learning
AIそのものをLearningへ利用する可能性もある。
初心者には基礎を説明する。
EngineerにはTechnical Detailを説明する。
製薬担当者にはDomain-specific Exampleを示す。
質問へ対話的に回答する。
理解度に応じて内容を変える。
すると、
AI Education powered by AI
という構造が成立する。
AIが学習対象であると同時にLearning Interfaceにもなる。
⸻
LearningとKnowledge Base
企業のAI Educationを長期的に運用すると、大量のQuestionが蓄積される。
このDataは重要である。
Employeeは何につまずくのか。
どのRuleが分かりにくいのか。
どのUse Caseへの需要が高いのか。
これをFAQやKnowledge Baseへ変換する。
すると、
Question → Answer → Organizational Knowledge
という蓄積が始まる。
⸻
LearningからUse Caseが生まれる
EmployeeがAIを理解すると、
「この業務にも使えるのではないか」
というIdeaが生まれる。
これを単なるSuggestionで終わらせない。
Use Caseとして登録する。
Impactを評価する。
小さく試す。
有望ならPoCへ進める。
すると、
Learning → Idea → Experiment → Development
というPipelineが形成される。
AI EducationがInnovation Pipelineの入口になる。
⸻
Use Case Library
複数のDepartmentでAI活用が進むと、似たUse Caseが現れる。
Meeting Summary。
Document Search。
Report Draft。
Knowledge Retrieval。
Quality Check。
これらをOrganization内で共有すれば、毎回ゼロから考える必要がなくなる。
つまり、
Individual Experiment → Reusable Use Case
へ変換する。
Learning PlatformがUse Case Libraryと接続すれば、Organization全体のAI導入速度を上げられる。
⸻
成功例だけを共有しない
Use Case Libraryには成功例だけを入れるべきではない。
期待した効果が出なかった。
Accuracyが不足した。
Costが高かった。
Security上利用できなかった。
Human Reviewが重すぎた。
こうしたFailureもKnowledgeである。
失敗を共有すれば、他Departmentが同じ失敗を繰り返す必要がない。
Failure KnowledgeもOrganizational Asset
になる。
⸻
Learningと伴走型開発
ここでAI×DX寺子屋 LearningとEQUESの伴走型技術開発が接続する。
LearningによってProblemが見つかる。
小さく試す。
専門的なDevelopmentが必要になる。
EQUESとPoCする。
Productionへ進む。
そのProjectで得られたKnowledgeを再びLearningへ戻す。
構造は、
Learning
→ Problem Discovery
→ PoC
→ Development
→ Deployment
→ Experience
→ Learning
となる。
これはEducationとDevelopmentの循環である。
⸻
LearningとProduct
さらにQAIのようなProductとも接続できる。
Productを導入する。
Trainingする。
Humanが利用する。
QuestionやErrorが蓄積する。
Productを改善する。
教材も改善する。
つまり、
Product ⇄ Learning
という循環が生まれる。
SoftwareだけがUpdateされるのではない。
Human Knowledgeも同時にUpdateされる。
⸻
Continuous Learning Organization
この状態まで進むと、企業は「AI研修を受けたOrganization」ではなくなる。
新しいAIを観測する。
理解する。
試す。
評価する。
採用する。
Ruleを更新する。
Knowledgeを共有する。
このProcessを自律的に繰り返す。
つまり、
Continuous Learning Organization
になる。
AI Technologyが高速に変化する時代には、この能力自体が競争力になる。
⸻
Modelより長く残る能力
特定のAI Modelは数年後には置き換わっている可能性がある。
特定のPrompt Techniqueも変わる。
Toolも変わる。
しかし、
新しいTechnologyを理解する。
自社のProblemへ翻訳する。
小さく試す。
評価する。
安全に導入する。
という能力は残る。
したがって、企業が蓄積すべき最も重要なAI Assetの一つは、
Learning Capability
である。
⸻
EQUESにとっての戦略的意味
EQUESにとってAI×DX寺子屋 Learningは、教育事業としてだけでなく、他事業を接続する可能性を持つ。
伴走型技術開発。
製薬AI。
将来のEnergy AI。
AI Agent。
Physical AI。
これらが高度になるほど、User側にも新しいKnowledgeが必要になる。
そのためEducation Layerを持つことは、
Technologyを市場へ導入するためのAdoption Infrastructure
を持つことでもある。
⸻
ResearchからHumanまで
EQUESの出発点はResearchだった。
そこから、
Research → Model → Product → Workflow
へ進んだ。
さらに本部では、
Workflow → Human → Learning
へ進んでいる。
ここでResearchとEducationは反対側にあるように見える。
しかし実際には循環する。
Researchによって新しいTechnologyが生まれる。
EducationによってHumanが理解する。
Humanが新しいProblemを発見する。
Problemが次のDevelopmentやResearchへ戻る。
したがって、
Research → Technology → Learning → Problem → Research
という循環が成立する。
⸻
Learningは社会実装の継続装置である
AI×DX寺子屋 Learningの本質を最小化すれば、
Learn
→ Use
→ Evaluate
→ Share
→ Improve
→ Learn Again
となる。
AI Educationは導入前の準備ではない。
導入後も続く。
Technologyが更新される限り、HumanもOrganizationも学び続けなければならない。
この意味でLearningは、AI社会実装の周辺機能ではなく、
社会実装を継続させるInfrastructure
なのである。
しかし、Learning Infrastructureがあっても、企業の中にAIを理解し、課題を発見し、Development Teamと現場を接続できるHumanがいなければ変化は広がらない。
次節では、Learningを個人とOrganizationのCapabilityへ変換する主体として、企業のAI人材育成を見ていく。
第5節 企業のAI人材育成
企業がAIを使えるようになるためには、AI Engineerを何人採用すればよいのか。
この問いだけでは、AI人材の問題を十分に捉えられない。
AIを開発する人。
業務へ適用する人。
Dataを管理する人。
Outputを評価する人。
Riskを判断する人。
AIを使って仕事をする人。
これらは異なる役割だからである。
生成AIが企業全体へ広がるほど、必要になるのは少数の専門家だけではなく、Organization全体に分散したAI Capabilityである。
EQUESのAI×DX寺子屋や伴走型技術開発を人材という側面から見ると、AI人材育成とは「AIの専門家を増やすこと」だけではなく、企業そのものをAIを扱える組織へ変えるProcessとして理解できる。
⸻
AI人材は一種類ではない
「AI人材」という言葉は広すぎる。
Machine Learning Modelを開発できるResearcherと、生成AIを日常業務で安全に使えるEmployeeでは、必要な能力が異なる。
そこで企業のAI人材を役割ごとに考える必要がある。
例えば、
AI Researcher / Engineer
ModelやAlgorithmを研究・開発する。
AI / Software Engineer
AIをApplicationやSystemとして実装する。
Domain Expert
業界Knowledgeを提供し、Outputを評価する。
AI Product / Project Leader
Business ProblemとTechnologyを接続する。
AI Champion
各DepartmentでAI活用を広げる。
AI User
日常業務でAIを適切に利用する。
AI企業でない一般企業が、このすべてを同じ人数だけ持つ必要はない。
重要なのは、自社に必要な役割の組合せを設計することである。
⸻
全員をEngineerにする必要はない
生成AIの普及によって、Programmingを専門としない人でも高度なAIを利用できるようになった。
したがって企業のAI人材育成は、
Everyone → AI Engineer
を目指す必要はない。
むしろ、
Everyone → AI-literate Worker
を基礎とし、その上に専門人材を配置する方が現実的である。
全員がAIの基本特性とRiskを理解する。
一部の人材が高度な活用を主導する。
さらに少数の専門家がSystemを構築する。
階層的なCapability形成である。
⸻
第一層――AIを安全に使える人
最も広いLayerでは、EmployeeがAIを適切に利用できることが必要になる。
生成AIで何ができるか。
何ができないか。
Hallucinationとは何か。
機密情報をどう扱うか。
Outputをどう確認するか。
どの用途ではHuman Reviewが必要か。
ここで求められるのは高度な数学ではない。
Responsible AI Use
である。
AIを使わない人とAIを無条件に信じる人の間に、適切に利用できる人材を増やす。
⸻
第二層――AIで業務を改善できる人
次のLayerでは、自分の業務をAIによって改善できる能力が必要になる。
業務をTaskへ分解する。
AIに適したTaskを見つける。
Promptを設計する。
必要なKnowledgeを与える。
Outputを評価する。
Workflowを変更する。
ここではAIそのものより、
Problem-solving with AI
が中心になる。
企業のAI活用を広げるうえで、この層が非常に重要になる。
⸻
第三層――AIと現場を翻訳できる人
さらに重要なのが、TechnologyとDomainの双方をある程度理解する人材である。
現場の担当者が、
「この仕事をAI化したい」
と言う。
Engineerは、
「どのInputから、どのOutputを作ればよいのか」
と聞く。
その間を翻訳する。
Business RequirementをTechnical Requirementへ変換し、Technical Constraintを現場へ説明する。
この人材は、
Translator
として機能する。
EQUESのような伴走型開発企業にとって、顧客側にこの役割が存在することはProjectの速度と品質を大きく左右する。
⸻
第四層――AIを構築できる人
より専門的なLayerでは、
Machine Learning。
Deep Learning。
LLM。
RAG。
AI Agent。
Data Engineering。
Cloud。
Security。
MLOps。
などを扱える人材が必要になる。
ただし、Technologyは急速に変化する。
特定Frameworkの操作方法だけを覚えても、数年後には変わっている可能性がある。
そこで重要なのは、
Algorithm。
Data。
Evaluation。
Software Architecture。
System Design。
といった基礎能力である。
Tool SkillよりFundamental Capability
を重視する必要がある。
⸻
第五層――AIを評価できる人
AI時代には、作る人と同じくらい評価する人が重要になる。
ModelのAccuracyは十分か。
どのCaseで失敗するか。
Domain Requirementを満たしているか。
Biasはないか。
Human Reviewは機能しているか。
ProductionでPerformanceが変化していないか。
特に製薬やEnergyのような高信頼産業では、
Evaluation Capability
そのものが専門能力になる。
JPharmaBenchのようなBenchmarkを持つ意味も、この文脈から理解できる。
AIを高度化するだけでなく、AIの能力を測定できなければならない。
⸻
Domain ExpertはAI時代にも中心にいる
生成AIが専門Knowledgeを扱えるようになると、Domain Expertが不要になるように見えることがある。
実際には逆である。
AI Outputが専門的になるほど、それが正しいか判断できる人が必要になる。
製薬なら品質保証。
Energyなら設備やSafety。
原子力なら現場Operation。
AIが専門Languageを生成できることと、その内容へ責任を持てることは別である。
したがって、
AI Capability ↑ → Domain Evaluation Importance ↑
となる場合がある。
⸻
T-shaped人材
企業のAI社会実装では、すべての分野を深く理解する人材を作ることは現実的ではない。
そこで有効なのがT-shapedな能力構造である。
一つのDomainを深く理解する。
同時にAI、Data、Software、Businessについて横断的な理解を持つ。
例えば、
**Deep Pharmaceutical Knowledge
* Broad AI Literacy**
を持つ人材である。
逆方向もある。
**Deep AI Engineering
* Broad Pharmaceutical Knowledge**
である。
異なるT-shaped人材がTeamとして接続する。
⸻
Team Intelligence
複雑なAI Projectでは、一人のSuper Engineerがすべてを理解する必要はない。
AI Researcher。
Software Engineer。
Domain Expert。
Security Specialist。
Product Manager。
Operator。
それぞれが異なるKnowledgeを持つ。
重要なのは、
Individual Intelligence
ではなく、
Team Intelligence
である。
異なる専門家が共通LanguageでCommunicationできることが、AI社会実装のCapabilityになる。
⸻
採用だけでは追いつかない
AI人材不足に対して、外部から専門家を採用する方法は重要である。
しかし市場全体で需要が高ければ、必要な人数をすべて採用することは難しい。
そこで、
Hire + Develop
という二つの戦略が必要になる。
高度な専門家は採用する。
既存EmployeeにはAI Literacyを身につけてもらう。
Domain ExpertをAI Championへ育成する。
若手Engineerを高度なAI人材へ成長させる。
組織内部でCapabilityを増やしていく。
⸻
Reskilling
AI導入によってJobの一部が自動化される場合、人材育成は新しい仕事へ移るためのReskillingにもなる。
例えばHumanがDocumentを一から作成する時間が減れば、
Review。
Exception Handling。
Analysis。
Improvement。
Decision Support。
へ時間を移せる。
しかし、そのためには新しいSkillが必要になる。
AutomationとEducationを同時に設計しなければならない。
⸻
Learning by Doing
AIは座学だけでは身につきにくい。
実際の業務Problemへ使う。
失敗する。
修正する。
再び試す。
このProcessによって理解が深まる。
したがってAI人材育成では、
Learn → Build → Evaluate → Improve
というProject-based Learningが重要になる。
AI×DX寺子屋とPoCを接続する意味もここにある。
Learningの次に実際のExperimentを置く。
⸻
Sandboxを用意する
しかしEmployeeがProduction Dataを使って自由にExperimentすることにはRiskがある。
そこで安全なSandbox Environmentを用意する。
Sample Data。
Approved AI Tools。
Limited Access。
Testing Environment。
ここで自由に試す。
成功したUse CaseだけをGovernance Processへ進める。
つまり、
Safe Experimentation
を制度化する。
InnovationとGovernanceを対立させない方法である。
⸻
AI Champion Network
Organizationが大きくなると、中央AI TeamだけですべてのDepartmentを支援することは難しい。
そこで各DepartmentにAI Championを置く。
現場のQuestionへ答える。
Use Caseを集める。
Trainingを支援する。
成功例を共有する。
中央AI TeamとCommunicationする。
複数のChampionをNetwork化すれば、
Central AI Team ⇄ Local AI Champions ⇄ Employees
という構造ができる。
AI KnowledgeがOrganization全体へ分散する。
⸻
Community of Practice
さらに、AIを利用する人材同士が継続的にKnowledgeを共有する場を作る。
新しいUse Case。
便利なTool。
失敗例。
Security上の注意。
Prompt。
Evaluation Method。
これらを共有する。
するとLearningがTraining Departmentだけの仕事ではなくなる。
CommunityがCommunityを教育する
状態へ近づく。
⸻
Career Pathを作る
AIを学んでもCareer上評価されなければ、継続的なSkill Developmentは起こりにくい。
AI Champion。
AI Product Manager。
Domain AI Specialist。
AI Engineer。
といったRoleへのCareer Pathを用意する。
Skill Levelを評価する。
Project Experienceを認める。
するとAI Learningが個人のCareer Developmentと接続する。
人材育成を一時的なCampaignにしないために重要である。
⸻
ManagementもAI人材である
AI人材育成というと若手EmployeeやEngineerへ目が向きやすい。
しかしManagementにもAI Literacyが必要になる。
何に投資するか。
どのRiskを許容するか。
どこをAutomationするか。
どのCapabilityを内製するか。
どのVendorと組むか。
これらは経営Decisionである。
ManagerがAIを理解していなければ、過大投資と過小投資の双方が起こり得る。
したがって、
AI Literacy for Leadership
も必要になる。
⸻
経営層が理解すべきこと
経営層がModel Architectureの細部まで理解する必要はない。
しかし、
AIで何が変わるのか。
どこにCompetitive Advantageが生まれるのか。
どのDataがStrategic Assetなのか。
どのRiskが存在するのか。
どのCapabilityをOrganization内部に残すべきか。
は理解する必要がある。
AI StrategyをTechnology Departmentだけへ委任しないためである。
⸻
人材育成の成果をどう測るか
Training受講者数だけでは不十分である。
本当にCapabilityが形成されたかを見る必要がある。
AIを利用するEmployeeが増えたか。
有効なUse Caseが生まれたか。
PoCへ進んだか。
業務時間が短縮されたか。
Errorが減ったか。
安全な利用が定着したか。
つまり、
Learning KPI → Adoption KPI → Business KPI
へ接続する。
⸻
CertificationよりCapability
資格や修了証はLearningの可視化には役立つ。
しかし最終的に重要なのは、実際に何ができるかである。
Problemを定義できる。
AIを使える。
Outputを評価できる。
Riskを判断できる。
Workflowを改善できる。
この実践Capabilityを評価する。
AI Technologyが変化するほど、固定されたKnowledge Testだけでは不十分になる。
⸻
外部Expertとの共同学習
すべてのKnowledgeをOrganization内部だけで更新することも難しい。
AI Startup。
University。
Cloud Provider。
Industry Expert。
Consultant。
など外部のKnowledge Sourceと接続する。
EQUESのようなResearch-origin Companyとの協働には、System Developmentだけでなく、
Knowledge Transfer
という意味もある。
Projectを通じて顧客側の人材も学習する。
⸻
EQUES自身も人材を育てる必要がある
この構造は顧客企業だけの問題ではない。
EQUES自身にも当てはまる。
製薬。
Energy。
Physical AI。
Quantum Computing。
とDomainが広がれば、一人のEngineerがすべてを専門化することは難しい。
Technology Specialist。
Domain Specialist。
Project Leader。
Researcher。
を組み合わせながら、OrganizationとしてKnowledgeを保持する必要がある。
つまりEQUES自身も、
Learning Organization
でなければならない。
⸻
若いOrganizationの強みと課題
若いTechnology Companyには、新しいAI Technologyへ適応しやすいという強みがある。
一方で、Projectが増えるほどKnowledgeが個人へ集中するRiskも高まる。
誰が何を知っているのか。
どのProjectで何を学んだのか。
どの失敗を経験したのか。
これをOrganizationへ残さなければならない。
したがって成長過程では、
Individual Expertise → Organizational Capability
への変換が重要になる。
⸻
人材育成から企業能力へ
一人がAIを学ぶ。
その人が業務を改善する。
Knowledgeを共有する。
別の人が応用する。
Use Caseが増える。
共通Infrastructureが整備される。
Organization全体のAI導入速度が上がる。
このProcessによって、
Human Skill → Team Capability → Organizational Capability
へ拡張する。
企業のAI人材育成の最終目的は、個人のSkill向上だけではない。
企業そのものの問題解決能力を高めることである。
⸻
AI人材育成の最小構造
ここまでを整理すると、企業のAI人材育成は、
Literacy
→ Use
→ Evaluation
→ Problem Solving
→ Implementation
→ Knowledge Sharing
→ Organizational Learning
という流れになる。
この循環が継続すれば、特定のModelやToolが変わってもOrganizationは適応できる。
それこそが、AI Technologyの変化が速い時代に必要なCapabilityである。
⸻
EQUESのAI×DX寺子屋、AI×DX寺子屋 Learning、伴走型技術開発を一続きに見ると、EducationはAI事業の周辺に置かれた活動ではない。
Technologyを理解できるHumanを増やし、そのHumanがProblemを発見し、ProblemをDevelopmentへ接続し、そこで得られたKnowledgeを再びOrganizationへ戻す。
その循環を形成するための一つのLayerである。
そして人材形成の対象は企業だけに限られない。
AIが社会の一般的なInfrastructureになっていくなら、次の世代がAIをどのように理解し、地域や社会のProblemへ利用するかも重要になる。
次節では視点を企業の内部から外へ広げ、EQUESによる教育活動を手掛かりに、学校・地域とAI教育について考える。
第6節 学校・地域とAI教育
企業のAI人材育成をさらに長い時間軸で考えると、教育の対象は企業の中だけでは完結しない。
現在企業で働いている人がAIを学ぶこと。
次に社会へ出る若い世代がAIを理解すること。
学校が新しいTechnologyとの向き合い方を教えること。
地域の企業や自治体がAIを使って自らの課題を解決できること。
これらは別々の問題に見える。
しかしAIが電力やInternetのように社会の広い領域へ組み込まれていくなら、共通する問いがある。
AIを使える社会を、どのように形成するのか。
EQUESの教育活動を企業研修だけでなく学校・地域まで含めて見ると、AI社会実装のもう一つの側面が見えてくる。
Technologyを社会へ配布するだけではない。
Technologyを理解し、自分たちのProblemへ利用できるHumanを社会の中に増やしていくのである。
⸻
学校でAIを教えるとは何か
学校にAIを導入するというと、最初に考えられるのは学習支援である。
文章を要約する。
質問へ回答する。
英語を翻訳する。
Programを書く。
教材を生成する。
これらは重要なUse Caseである。
しかしAI教育は、「AIを使って勉強を効率化すること」だけではない。
より重要なのは、
AIとはどのようなTechnologyなのかを理解し、適切に使い、結果を自分で判断できるようになること
である。
⸻
答えを得る教育から問いを作る教育へ
生成AIは、多くの問いに即座に答える。
そのため教育では、新しい問題が生まれる。
答えを生成できるなら、人間は何を学ぶのか。
一つの方向は明確である。
答えそのものより、
何を問うのか。
なぜ問うのか。
どのInformationが必要なのか。
AIの答えは正しいのか。
別の解釈はないのか。
を考える能力の重要性が高まる。
つまり、
Answering Questions
だけでなく、
Formulating Questions
を学ぶ。
AI時代には、問いを設計する能力が教育の重要な要素になる。
⸻
AIを検索機械としてだけ使わない
AIへ質問し、答えをCopyする。
それだけならLearningは浅くなる可能性がある。
しかしAIを、
Brainstorming Partner。
Research Assistant。
Simulation Tool。
Programming Assistant。
Critic。
として使えば、学習方法は広がる。
重要なのは、AIがHumanの思考を代替するかどうかという二択ではない。
AIを使ってHumanの思考Processをどのように拡張するか
である。
⸻
Verificationを学ぶ
生成AI時代の学校教育で特に重要になるのがVerificationである。
AIが答えを出した。
それは正しいか。
Sourceは何か。
別の資料ではどう説明されているか。
数字は一致しているか。
AIが知らないことを知っているように話していないか。
これを確認する。
つまり、
Generate → Verify
を一組として学ぶ。
これは将来、企業でAIを利用するときにもそのまま必要になる能力である。
⸻
AI LiteracyとInformation Literacy
AI Literacyは従来のInformation Literacyから切り離されているわけではない。
情報源を確認する。
複数のSourceを比較する。
FactとOpinionを区別する。
著作権を理解する。
Privacyを守る。
生成AIによって、これらの重要性はむしろ高まる。
AI Educationは新しいTechnology教育であると同時に、
Information Literacyの再設計
でもある。
⸻
Programmingの意味も変わる
生成AIはCodeを生成できる。
するとProgrammingを学ぶ意味がなくなるようにも見える。
しかし実際には、Programming Educationの重点が変化する可能性がある。
Syntaxをすべて暗記することより、
何を作るのか。
Problemをどう分解するのか。
生成されたCodeが何をしているのか。
正しく動いているか。
Security上の問題はないか。
を判断する能力が重要になる。
つまり、
Writing Code
から、
Designing and Evaluating Systems
へ重点が広がる。
⸻
AI Agent時代の教育
AI Agentが普及すれば、さらに変化する。
AIへ一つの質問をするだけではない。
Goalを与える。
AIがTaskを分解する。
WebやDatabaseを利用する。
Toolを実行する。
複数の結果を統合する。
このときHumanには、
Goal Setting。
Constraint Definition。
Progress Monitoring。
Result Evaluation。
が求められる。
AIを「使う」というより、
AIへ仕事を設計する能力
が必要になる。
⸻
地域企業を教材にする
学校でAIを学ぶとき、抽象的なExerciseだけを行う必要はない。
地域には現実のProblemがある。
小売店の集客。
観光。
農業。
製造業。
交通。
高齢化。
行政業務。
地域文化の発信。
こうしたProblemを題材にできる。
生徒が地域企業から課題を聞く。
Problemを整理する。
AIでSolutionを考える。
Prototypeを作る。
企業へPresentationする。
すると、
School → AI → Local Problem
が接続する。
⸻
「未来の教室」という意味
EQUESが学校教育の場でAIを活用した課題解決型の取り組みを行ってきたことは、この文脈で重要である。
単に「生成AIの使い方」を教えるだけではなく、生徒がAI AgentなどのTechnologyを利用しながら、企業や地域の課題を考える。
ここでは学習対象がAIだけではない。
Business。
Communication。
Problem Solving。
Teamwork。
Presentation。
Technology。
が一つのProjectの中で接続する。
AIが教科ではなく、横断的なProblem-solving Infrastructureになる。
⸻
本物のProblemには正解がない
学校の問題には通常、正解がある。
しかし企業や地域のProblemには、一つの正解が存在しないことが多い。
売上を増やしたい。
観光客を増やしたい。
業務を効率化したい。
地域の魅力を伝えたい。
複数のSolutionが考えられる。
そこで、
仮説を立てる。
AIを使う。
調査する。
試す。
Feedbackを得る。
修正する。
というProcessを経験する。
これは企業のPoCと非常によく似ている。
⸻
EducationとPoCの共通構造
企業のAI Projectでは、
Problem
→ Hypothesis
→ Prototype
→ Evaluation
→ Improvement
と進む。
Project-basedなAI Educationでも同じである。
つまり学校教育と企業のAI Developmentは、対象こそ違うが同じProblem-solving Cycleを共有できる。
この構造を学ぶことは、特定AI Toolの操作方法を覚えるより長期的な価値を持つ。
⸻
AIが創造性を奪うのか
教育では、AIが生徒の創造性を奪うという懸念もある。
確かに、最初からAIへ「案を全部出して」と依頼すれば、自分で考える機会を減らす可能性がある。
しかし使い方は一つではない。
HumanがIdeaを作る。
AIに反論させる。
別のPerspectiveを生成させる。
比較する。
さらにHumanが選ぶ。
すると、
Human Idea → AI Expansion → Human Selection
というProcessになる。
AIを答えの代替ではなく、思考を広げるPartnerとして設計できる。
⸻
Teacherの役割も変わる
AIが大量のInformationを説明できるようになると、Teacherの役割も変化する。
Knowledgeを一方向に伝えることだけではない。
問いを設計する。
議論を促す。
AI Outputを検証させる。
異なる意見を比較させる。
Projectを支援する。
生徒の理解度を観察する。
つまり、
Information Provider
から、
Learning Designer / Facilitator
へ役割が広がる。
これは企業におけるHumanの役割変化とも似ている。
⸻
教師にもAI Literacyが必要になる
当然ながら、生徒だけをTrainingしても十分ではない。
教師自身が、
AIの能力。
限界。
Privacy。
Copyright。
Hallucination。
Assessmentへの影響。
を理解する必要がある。
AIを禁止するか全面的に許可するかという二択ではなく、
どの学習目的で、どのように使うのか
を設計できる能力が必要になる。
⸻
評価方法も変わる
AIがEssayやCodeを生成できるなら、提出物だけで学習成果を評価することは難しくなる。
そこで、
どのような問いを立てたか。
AIをどう使ったか。
Sourceをどう確認したか。
なぜそのSolutionを選んだか。
どのように修正したか。
といったProcessを見る。
つまり、
Output Evaluation
から、
Process Evaluation
へ広げる必要がある。
⸻
地域にAI人材を残す
AI人材が東京など大都市へ集中すれば、地方企業はAI導入で不利になる可能性がある。
地域にAIを理解する人材がいれば、
Local Company。
Municipality。
School。
University。
がTechnologyへ接続しやすくなる。
したがって地域でのAI Educationには、
Regional AI Capability
を形成する意味がある。
EQUESが北海道にも活動基盤を広げていることを考えると、地域人材と先端Technologyをどう接続するかは今後の重要な観点になる。
⸻
地方企業とAI
地方の中小企業が、大規模なAI Research Teamを持つことは難しい。
しかし生成AIによって、AI利用のEntry Costは大きく下がっている。
Document作成。
Translation。
Customer Support。
Knowledge Search。
Marketing。
Data Analysis。
Software Development Support。
など、利用可能な領域は広い。
ここで必要になるのは高度な研究設備より、
AIを自社のProblemへ翻訳できる人材
である。
⸻
地域にTranslatorを作る
地域のAI普及では、AI Engineerだけを増やす必要はない。
地元企業の業務を知り、
AIについて基本的に理解し、
外部のTechnology Companyとも会話できる人。
つまり、
Local AI Translator
を育てる。
学校教育。
大学。
企業研修。
Startup。
自治体。
が接続すれば、この人材を地域内部に形成できる。
⸻
SchoolとCompanyを接続する
学校と地域企業がAI Projectを共同で行うと、双方にLearningが生まれる。
生徒はReal-world Problemを学ぶ。
企業は若い世代のPerspectiveを得る。
教師は新しい教育方法を試す。
Technology Companyは新しいUse Caseを知る。
つまり、
Student
⇄ School
⇄ Company
⇄ Technology Partner
というNetworkができる。
Educationが地域Innovationの接点になる。
⸻
AI教育を採用活動だけにしない
企業が学校教育へ関わると、将来人材の採用という目的も考えられる。
それ自体は自然である。
しかし教育活動を採用Pipelineだけとして捉えると可能性を狭める。
より広く見れば、
AI Literacyを社会へ広げる。
Technologyへの理解を高める。
地域Problemを発見する。
次世代のEntrepreneurやEngineerを育てる。
という長期的なTechnology Ecosystem形成になる。
⸻
地域から新しいProblemが見つかる
研究開発は大学や大企業だけから始まるとは限らない。
地域には、その場所でなければ見えないProblemがある。
Agriculture。
Snow。
Transportation。
Healthcare Access。
Tourism。
Disaster Prevention。
Infrastructure Maintenance。
こうしたProblemがAI Researchの新しいQuestionになる可能性がある。
つまり、
Region → Problem → Technology Development
という逆方向のFlowも成立する。
⸻
EducationからResearchへ戻る
ここでEQUESの原点へ戻る。
EQUESはResearchから社会実装へTechnologyを移す会社として始まった。
通常は、
Research → Society
という方向を考える。
しかし学校や地域まで含めると、反対方向が見えてくる。
地域でProblemが発見される。
生徒や企業が試す。
解けないProblemが見つかる。
EngineerがDevelopmentする。
必要ならResearchへ進む。
つまり、
Society → Problem → Development → Research
である。
⸻
一方向のTechnology Transferではない
この二方向を合わせると、
Research
→ Technology
→ Education
→ Society
→ Problem
→ Research
という循環になる。
Research成果を社会へ渡して終わるのではない。
社会でTechnologyを使うことで、新しいResearch Questionが生まれる。
これは研究と社会の関係を、一方向のTechnology Transferから継続的なKnowledge Exchangeへ変える。
⸻
AI格差という課題
ただし、AI Educationが広がれば自動的にすべての人が恩恵を受けるわけではない。
Device。
Network。
Language。
教育機会。
Teacher Support。
家庭Environment。
地域差。
こうした条件によってAIへのAccessには差が生じる。
したがってAI Educationを社会Infrastructureとして考えるなら、
AccessだけでなくCapabilityの格差
を見る必要がある。
AI Toolを利用できることと、AIを有効に使えることは同じではない。
⸻
AIを安全に使う市民能力
AI Literacyは職業能力だけでもない。
Deepfake。
Synthetic Media。
AI-generated Information。
Recommendation Algorithm。
AIによるDecision。
これらが日常生活へ入るほど、市民にもAIを理解する能力が必要になる。
本物か。
Sourceは何か。
誰が生成したのか。
どのようなBiasがあるか。
つまりAI Educationは長期的には、
Digital Citizenship
の一部になる。
⸻
EQUESの教育活動をどう位置づけるか
EQUESは教育企業ではない。
中心にあるのは、最先端のMachine Learning Technologyを社会へ実装するという事業である。
だからこそ教育活動を過大評価せず、企業全体の中で位置づける必要がある。
その役割は、
Technologyを作ることではなく、
Technologyを理解し利用できるHuman Interfaceを広げること
にある。
企業。
学校。
地域。
それぞれでAIを扱える人が増えれば、社会実装可能な領域も広がる。
⸻
Human Infrastructure
道路や通信網がPhysical Infrastructureなら、AIを理解し使える人材の蓄積はHuman Infrastructureと考えることができる。
Technologyだけが高度化しても、それを利用できるHumanがいなければ普及しない。
したがって、
**AI Infrastructure
= Computing Infrastructure
* Data Infrastructure
* Human Infrastructure**
という見方ができる。
EQUESの教育活動は、この三番目のLayerに位置する。
⸻
学校・地域とAI教育の最小構造
ここまでを圧縮すると、
Learn
→ Question
→ Local Problem
→ AI Experiment
→ Verification
→ Feedback
→ New Learning
となる。
学校ではLearningから始まる。
地域ではProblemから始まる。
企業ではImplementationから始まる。
しかし、最終的には同じCycleへ接続できる。
⸻
AIの社会実装は、企業のServerへModelをDeployしたところで終わらない。
AIを理解するEmployee。
AIを評価できるDomain Expert。
AIと協働できる次世代。
AIを自分たちのProblemへ使える地域。
そこまで含めて初めて、Technologyは社会へ定着していく。
第Ⅴ部で見てきたのは、まさにこのHuman Layerである。
そして次節では、伴走型技術開発、AI×DX寺子屋、企業人材育成、学校・地域教育を一つに統合し、EQUESの社会実装を**「人間を含むAI社会実装」**として整理する。
第7節 人間を含むAI社会実装
AIの社会実装という言葉から、人間を取り除いて考えることはできない。
Modelが推論する。
Softwareが処理する。
AgentがTaskを実行する。
Robotが物理世界で動く。
こうしたAutomationが高度になるほど、人間がSystemから消えていくように見える。
しかし実際の産業では、人間は別の位置へ移動する。
目的を決める。
AIへ権限を与える。
結果を確認する。
例外を判断する。
責任を引き受ける。
現場からFeedbackを返す。
そして、AIとともに仕事の仕組みそのものを更新する。
EQUESの伴走型技術開発、製薬AI、エネルギー・フィジカルAI、AI×DX寺子屋を一つの構造として見ると、社会実装とは「AIを導入すること」ではない。
AIとHumanを含む新しいSystemを構築することである。
⸻
Human-in-the-Loopを超えて
AI Systemでは、Human-in-the-Loopという考え方が使われる。
AIがOutputを生成する。
Humanが確認する。
必要なら修正する。
これは高信頼AIにおいて重要である。
しかし社会実装を考えるなら、Humanの役割はReviewだけではない。
Humanは、
Problemを定義する。
Dataを生成する。
Requirementを決める。
Evaluation Criteriaを作る。
AIを利用する。
結果を判断する。
Systemを改善する。
つまりHumanはLoopの途中に置かれた確認者ではなく、System全体を成立させる主体の一つである。
⸻
Human-on-the-Loop
Automationが進むと、人間は一つ一つの処理を確認するのではなく、System全体を監督する位置へ移る。
通常処理はAIが行う。
異常があればAlertを出す。
Humanが必要な場合だけ介入する。
これは、
Human-in-the-Loop
から、
Human-on-the-Loop
への移行と考えられる。
Physical AIでは、この構造がさらに重要になる。
Robotが自律的に行動しても、人間がMission、Safety Constraint、Emergency Stop、Escalationを管理する。
Automationの高度化はHuman Controlを不要にすることではない。
Human Controlの粒度を変えることである。
⸻
Human-out-of-the-Loopには条件がある
もちろん、すべての処理へHuman Reviewを置けばよいわけでもない。
大量かつ低RiskなTaskでは、完全Automationの方が合理的な場合がある。
そこで重要になるのがRisk-based Designである。
Low Risk。
Medium Risk。
High Risk。
Critical Risk。
Riskに応じて、
Automatic Execution。
Post Review。
Pre-approval。
Mandatory Human Decision。
を使い分ける。
つまり、
Risk → Human Involvement Level
を設計する。
⸻
AIの自律性と責任を分ける
AI AgentやRobotが高度化すると、「AIが自律的に行動する」という表現が増える。
しかしTechnical AutonomyとOrganizational Accountabilityは同じではない。
AIがTaskを自律的に実行できても、
誰がGoalを設定したのか。
誰がPermissionを与えたのか。
誰がOperationを監督するのか。
誰が停止できるのか。
を明確にする必要がある。
したがって、
Autonomy ≠ Accountability
である。
自律性が高くなるほど、責任構造を明確に設計する必要がある。
⸻
製薬AIにおけるHuman
製薬の品質保証業務を考える。
AIがDocument Draftを生成する。
AIが複数Document間の不整合候補を検出する。
AIがKnowledgeを検索する。
しかし最終的な品質判断まで無条件にAIへ移すわけではない。
Domain Expertが確認する。
Evidenceを見る。
必要なら修正する。
承認Processを通す。
ここではAIはHumanを排除するのではなく、
Human Judgmentの前工程を高度化するTechnology
として働く。
⸻
Human Reviewの質も問われる
Humanを置けば安全になるとは限らない。
AI Outputを形だけ確認する。
時間がないためApproveする。
AIの専門的な文章を信用する。
これではHuman Reviewが形式化する。
必要なのは、
何を確認するのか。
どのEvidenceを見るのか。
どの条件ならRejectするのか。
どこからExpertへEscalateするのか。
というReview Designである。
Human ReviewそのものもEngineeringの対象になる。
⸻
AIがHumanへ説明する
そのためにはAI側にもHumanが判断できるInformationを提供する必要がある。
Outputだけを表示するのではない。
Source。
Evidence。
Confidence。
Reference Document。
Reasoningに代わる検証可能な根拠情報。
Warning。
を提示する。
つまりInterfaceは、
AI Output Interface
ではなく、
Human Decision Interface
として設計する必要がある。
説明可能AIやTraceabilityが重要になる理由もここにある。
⸻
HumanがAIを監査する
高信頼産業では、AI Systemそのものも監査対象になり得る。
どのModelを使ったか。
どのDataを参照したか。
いつOutputを生成したか。
誰が確認したか。
何を修正したか。
どのVersionを承認したか。
これらを記録する。
すると、
AI Action → Human Review → Audit Record
というChainが形成される。
AIの利用履歴がOrganizationのAccountabilityへ接続する。
⸻
Physical AIでは関係がさらに深くなる
Robotが物理世界へ出ると、AIのErrorはInformation上の問題だけではなくなる。
Robotが動く。
Objectへ接触する。
Equipmentを操作する。
危険区域へ入る。
このため、
Sensor Reliability。
Control System。
Safety Boundary。
Human Override。
Emergency Procedure。
などを含めて設計しなければならない。
Physical AIでは、
AI Safety + Machine Safety + Human Safety
を一つのSystemとして扱う必要がある。
⸻
HumanとRobotの役割分担
過酷環境ではRobotに大きな価値がある。
高線量環境。
高温。
狭所。
災害現場。
人間が長時間活動できない場所。
ここではAutomationの目的はHumanを単純に置き換えることではない。
Human Exposureを減らすこと
でもある。
RobotがPhysical Taskを担当する。
AIが認識や支援を行う。
HumanがRemote Environmentから監督する。
つまり、
Human Capabilityを危険区域の外側へ拡張するSystem
としてPhysical AIを理解できる。
⸻
AIはHuman Capabilityを拡張する
この視点を製薬へ戻す。
AIが大量のDocumentを読む。
Humanが重要なPointへ集中する。
Energyでは、
AIがSensor Dataを監視する。
Humanが異常判断へ集中する。
Robotでは、
AIが低Level Controlを支援する。
HumanがMission Levelを管理する。
共通するのは、
Human Replacement
より、
Human Augmentation
である。
社会実装の価値は、何人削減できるかだけでは測れない。
Humanがより重要なTaskへ時間を使えるかを見る必要がある。
⸻
Human ErrorとAI Error
Humanは間違える。
AIも間違える。
重要なのは、どちらかを完全な主体として扱わないことである。
Human ErrorをAIが発見する。
AI ErrorをHumanが発見する。
異なるFailure Modeを持つ主体を組み合わせる。
すると、
Human ⇄ AI
が相互確認するSystemを設計できる。
QAI CheckerのようなConsistency Checkingも、この広い構造の中で理解できる。
⸻
Complementarity
HumanとAIの最適な関係は、同じ能力を競わせることではない。
Humanが強いところ。
AIが強いところ。
それぞれを組み合わせる。
AIは大量Dataを高速に処理できる。
HumanはContext、価値判断、例外、責任を扱える。
したがって目標は、
AI Performance
だけではなく、
Human–AI System Performance
である。
⸻
Organizationを含める
しかしHuman個人まで含めても、まだ社会実装は完成しない。
HumanはOrganizationの中で仕事をしている。
Rule。
Role。
Authority。
Budget。
Workflow。
Compliance。
Culture。
これらがHumanの行動を規定する。
したがって、
AI + Human
だけではなく、
AI + Human + Organization
を見る必要がある。
⸻
OrganizationはAIのEnvironmentである
Machine LearningではEnvironmentという言葉を使う。
産業AIにとって、企業組織も一種のEnvironmentである。
AIがどのDataへAccessできるか。
どこまで自動実行できるか。
Human Reviewが必要か。
どのOutputを保存するか。
すべてOrganization Ruleによって決まる。
つまりAIのCapabilityはModelだけでは決まらない。
Organizational Environmentによって実効能力が決まる。
⸻
Technology Adoptionは共同設計である
そのため、社会実装ではTechnologyを完成させてからOrganizationへ渡すだけでは十分ではない。
現場からRequirementを得る。
Prototypeを見せる。
Userが試す。
Feedbackを得る。
Workflowを変える。
Systemも変える。
この共同設計が必要になる。
EQUESの伴走型技術開発は、この意味で、
Co-development
として捉えることができる。
⸻
Human FeedbackはDataになる
HumanがAI Outputを修正する。
その修正にはKnowledgeが含まれている。
どこが間違っていたか。
何が不足していたか。
どの表現が適切だったか。
どのCaseではAIを使わないべきか。
これを構造化すれば、System Improvementへ利用できる。
つまり、
Human Feedback → Improvement Data
となる。
HumanはUserであると同時に、System LearningのSourceにもなる。
⸻
現場そのものもFeedbackを返す
さらにPhysical AIではEnvironmentからもFeedbackが戻る。
Sensor Data。
Robot State。
Failure。
Near Miss。
Operator Intervention。
これらを記録する。
すると、
AI → Action → Environment → Observation → Improvement
というLoopが形成される。
Human FeedbackとEnvironment Feedbackの双方が、次のSystem Designへ戻る。
⸻
EducationがLoopを支える
しかしHumanがAIを理解していなければ、良質なFeedbackは得られない。
なぜ失敗したか説明できない。
どこを修正すべきか分からない。
AIの限界を理解できない。
そこでAI×DX寺子屋やLearningの役割が戻ってくる。
Educationによって、
Better User → Better Feedback → Better System
という関係が生まれる。
教育とDevelopmentはここで完全に接続する。
⸻
HumanもFeedbackから学ぶ
学習するのはAIだけではない。
AIが失敗する。
Humanが原因を知る。
Workflowを変更する。
Trainingを更新する。
Organization Ruleを変える。
つまり、
AI Learning
と、
Human Learning
と、
Organizational Learning
が同時に起こる。
社会実装を長期的に見るなら、この三つを分離できない。
⸻
三つのLearning Loop
最小化すると、産業AIには三つのLoopがある。
Model Learning
DataやEvaluationからAIを改善する。
Human Learning
利用経験や教育からHuman Capabilityを改善する。
Organizational Learning
Project ExperienceからWorkflowやGovernanceを改善する。
三つが接続すると、
AI ⇄ Human ⇄ Organization
が継続的に適応するSystemになる。
⸻
Technologyだけが更新される危険
AI Modelだけを高速にUpdateし、HumanやOrganizationが追いつかなければGapが生じる。
新しいFunctionが追加された。
しかしUserは知らない。
Agentが自動実行できるようになった。
しかしGovernance Ruleがない。
新しいModelへ切り替えた。
しかしEvaluation Procedureが更新されていない。
Technologyの進歩速度が速いほど、
Organizational Update Rate
も重要になる。
⸻
社会実装の評価単位を変える
AI ProjectをModel Accuracyだけで評価すると、この構造は見えない。
見るべきなのは、
Quality。
Safety。
Productivity。
Adoption。
Human Workload。
Error Rate。
Operational Stability。
Business Impact。
である。
つまり評価対象を、
Model
から、
Socio-technical System
へ拡張する。
AIは社会技術Systemの一部として評価されるべきである。
⸻
Socio-technical SystemとしてのAI
この考え方は新しいものではない。
Information SystemやIndustrial Engineeringでは、TechnologyとHuman Organizationを一体として設計するSocio-technical Systemの考え方が蓄積されてきた。
生成AIやPhysical AIは、この問題をさらに強くする。
AIが判断や生成、行動へ深く関与するからである。
したがって次世代AIの社会実装は、
AI Engineering
だけでなく、
Socio-technical Engineering
になる。
⸻
EQUESをこの位置から読む
ここまでの第Ⅴ部を通して、EQUESの複数の活動を一つの構造として見ることができる。
伴走型技術開発。
AI×DX寺子屋。
AI×DX寺子屋 Learning。
企業のAI人材育成。
学校・地域でのAI教育。
これらは一見異なる事業・活動である。
しかし共通しているのは、
TechnologyとHumanの間の距離を縮めること
である。
⸻
Researchから社会実装まで
第Ⅰ部からここまでを接続すると、EQUESの構造は次のように広がってきた。
Research
→ Technology
→ PoC
→ Product
→ Workflow
→ Human
→ Organization
→ Society
しかしこれは一方向ではない。
SocietyからProblemが生まれる。
OrganizationからRequirementが返る。
HumanからFeedbackが返る。
Productが改善される。
新しいTechnologyが必要になる。
Researchへ戻る。
したがって、
Research
→ Technology
→ Society
→ Feedback
→ Research
という循環になる。
⸻
人間を含むAI社会実装
本節の結論は単純である。
AI社会実装の単位を、
AI Model
だけに置いてはいけない。
必要なのは、
**Model
* Data
* Software
* Infrastructure
* Human
* Workflow
* Organization
* Governance
* Environment**
である。
この全体が機能して初めて、AIは社会の中で価値を持つ。
⸻
AutomationからAugmentationへ
AI導入の目的をAutomationだけに置けば、
「どこまでHumanを減らせるか」
という問いになりやすい。
しかし高信頼産業では、より重要な問いがある。
Human Errorをどう減らすか。
危険な作業をどう減らすか。
専門家の時間をどこへ集中させるか。
Knowledgeをどう継承するか。
少ない人材でInfrastructureをどう維持するか。
つまり、
Automation
だけでなく、
Augmentation / Safety / Knowledge Transfer / Sustainability
を見る。
⸻
第Ⅴ部の到達点
第Ⅴ部では、AI導入の失敗から始めた。
そこから、
Technology Implementation。
Organizational Implementation。
AI×DX寺子屋。
Continuous Learning。
AI人材育成。
学校・地域教育。
へ視野を広げてきた。
最終的に見えてきたのは、
AIを実装することと、人間・組織を実装条件として設計することは分離できない
という事実である。
AIが高度になるほどHumanが不要になる、という単純な構図ではない。
Humanの位置が変わる。
仕事が変わる。
必要なSkillが変わる。
Organizationが変わる。
そして、その変化がAIへ再びFeedbackされる。
⸻
EQUESを「最先端AIを開発する会社」とだけ定義すると、このHuman Layerは見えにくい。
しかしResearchを社会へ移す企業として見るなら、人間と組織は最後に残る障害ではない。
最初からArchitectureに含めるべき社会実装の構成要素である。
そして、こうした社会実装を継続的な企業能力へ変えるためには、Projectごとに得られたKnowledge、人材、顧客との関係、研究成果、失敗と成功を、EQUES自身のOrganizationへ蓄積していかなければならない。
次の第Ⅵ部では視点をEQUES自身へ戻す。
研究者、Engineer、Domain Expert、顧客、Public Support、Partner、Project Experienceは、どのように一つの企業能力へ変換されるのか。
第6章では、EQUESを個別事業の集合ではなく、研究・人材・資本・Knowledgeを蓄積する企業Systemとして分析する。
愛と敬意を込めてmandala
