コンテキストエンジンによるワークオントロジー （AIカバレッジ：VOL.03）
VOL.02では、企業活動を構成するWorkやTaskとAI Capabilityを照らし合わせ、「自社のどこまでをAIが担えるのか」を可視化するAIカバレッジという考え方を整理しました。しかし、ここには一つ大きな前提があります。比較対象となる「自社の仕事」が、企業自身に正しく理解されていなければならないということです。
例えば、同じ「営業」や「人事企画」というJobでも、実際に担っているWorkやTaskは企業によって異なります。扱う商材、顧客、組織体制、業務プロセスが違えば、仕事の構造も変わります。当然、AIを適用できる範囲も同じではありません。一般的な職種データや標準的な業務一覧だけをもとにAI代替可能性を評価しても、企業固有のAIカバレッジを正確に捉えることはできません。
さらに、必要なのはTaskを一覧化することだけでもありません。企業活動は、Person、Organization、Job、Work、Task、Skill、Performanceといった要素が相互につながることで成り立っています。誰が、どの組織で、どの役割を担い、どのTaskを、どのSkillを使って実行し、どのような成果を生み出しているのか。こうした関係性まで含めて初めて、「仕事の意味」が見えてきます。この企業固有の仕事の構造を、一枚の「仕事の地図」として表現する考え方がWork Ontologyです。
ただし、この地図は一度つくれば終わりではありません。組織変更、新規事業、システム導入によって企業の仕事は変わり続けます。同時にAIも進化し、昨日まで人が担っていたTaskをAIが支援・実行できる可能性があります。だからこそ、AIカバレッジを継続的に把握するには、Work Ontologyそのものを継続的に構築・更新できる仕組みが必要です。
本稿では、企業内外に分散するデータを接続し、意味と関係性を与え、企業固有のWork Ontologyへ変えていく基盤として、Context Engineという考え方を取り上げます。重要なのは、単にデータを集めることではありません。AIが企業を理解するために、企業活動を構成する情報をContextとして捉えられる状態をつくることです。AIが企業を理解するためには、企業固有の「仕事の地図」が必要です。その地図がWork Ontologyであり、それを構築・更新する基盤がContext Engineなのです。
1｜AIカバレッジには「企業固有の地図」が必要
AIカバレッジを把握するためには、自社にどのようなWorkやTaskが存在するのかを正確に捉える必要があります。VOL.02でも、AI Capabilityと比較する対象となる「自社の仕事」が見えていなければ、企業固有のAIカバレッジを判断することはできないと整理しました。 しかし、ここでいう「自社の仕事」とは、単なる職種一覧や業務マニュアルのことではありません。企業ごとに異なる仕事の実態を、誰が、どの組織で、どのような役割を担い、何を実行しているのかという構造として捉える必要があります。AIカバレッジを正しく測るために必要なのは、一般論としての仕事の分類ではなく、その企業固有の「仕事の地図」なのです。
1-1｜一般的な職種データだけでは足りない
1-1-1｜Job Titleは同じでもWorkは違う
企業の仕事を整理する際、最も分かりやすい入口となるのがJobです。「営業」「人事企画」「経理」「エンジニア」「Account Executive」といった職種名によって、企業の中にどのような役割が存在しているのかを大まかに把握することはできます。しかし、AIカバレッジを測るという目的においては、Job Titleだけでは十分ではありません。同じJob Titleであっても、実際に行われているWorkやTaskは企業によって大きく異なるからです。
例えば、同じAccount Executiveでも、標準化されたSaaSをオンライン中心で販売する企業と、大企業に対して複数部門を巻き込みながら個別ソリューションを提案する企業では、仕事の中身が異なります。前者では、見込み顧客の選定、企業情報の収集、メールによるアプローチ、商談設定、提案資料作成など、比較的標準化しやすいTaskの比重が高いかもしれません。一方、後者では、顧客の事業構造を理解し、複数のステークホルダーとの関係を構築し、社内の専門部門を巻き込みながら提案内容を設計し、複雑な条件交渉を行うといったTaskの比重が高くなります。
これは人事企画やエンジニアでも同じです。組織規模、事業モデル、利用しているシステム、業務プロセス、権限設計などによって、同じJobの中に含まれるTaskは変わります。つまり、Job Titleは仕事を理解する入口にはなっても、仕事そのものではありません。
1-1-2｜AI Coverageは企業ごとに異なる
Jobの中身が企業によって異なるのであれば、当然、そのJobに対するAIカバレッジも企業ごとに異なります。「営業業務の40％はAI化できる」「人事業務の30％は自動化できる」といった一般的な数字だけでは、自社のAXを判断することはできません。
例えば、営業活動の中で情報収集や定型資料の作成に多くの時間を使っている企業では、現在のAI Capabilityによって支援・代替できる範囲は比較的大きくなる可能性があります。一方、同じ営業組織であっても、顧客との複雑な交渉や社内外の調整、個別性の高い意思決定が仕事の中心であれば、AIが担える範囲や、人が関与すべきポイントは異なります。
重要なのは、「この職種は一般的にどこまでAI化できるか」を知ることではありません。「自社に存在するこのTaskを、現在のAI Capabilityでどこまで担えるのか」を理解することです。そのためには、標準的な職種データを自社へ当てはめるのではなく、自社の仕事そのものを構造として捉える必要があります。
1-2｜静的な業務一覧でも足りない
1-2-1｜仕事は常に変わる
さらに、企業固有の仕事を一度整理すれば終わりというわけでもありません。企業の仕事は常に変化しています。組織変更によって役割分担が変わり、新しいサービスが生まれれば新しいWorkやTaskが生まれます。CRMやERPなどのシステムを刷新すれば、それまで人が行っていた入力や確認のプロセスが変わります。そしてAIそのものが業務に組み込まれれば、人が担うTaskとAIが担うTaskの境界も変化します。
例えば、これまで営業担当者が自ら行っていた企業情報の収集をAIが担うようになれば、営業担当者の仕事から一つのTaskがなくなるだけではありません。その結果として、仮説構築や顧客との対話に使える時間が増え、Jobを構成するTaskの比重そのものが変わります。仕事とは固定されたものではなく、事業、組織、Technologyの変化によって継続的に組み替えられていくものなのです。
そのため、年に一度の業務棚卸しによって作成したExcelの一覧表だけでは、企業の仕事を継続的に表現することは困難です。AIカバレッジの土台となる「仕事の地図」も、企業活動の変化に合わせて更新され続ける必要があります。
1-2-2｜AI Capabilityも常に変わる
変化するのは企業側の仕事だけではありません。比較対象となるAI Capabilityも急速に変化しています。生成、要約、検索、分類といった能力だけでなく、推論、計画、ツール操作、複数Taskの連続実行など、AIが担える領域は拡大し続けています。
現在はHuman Onlyと判断されているTaskであっても、新しいモデルやAIエージェントの登場によって、数か月後にはAI AssistedやAI Ledへ変わる可能性があります。逆に、技術的にはAIが実行できたとしても、精度、コスト、セキュリティ、説明責任などの条件によって、企業としてAIへ任せられる範囲が変わることもあります。
つまり、AIカバレッジは固定された数値ではありません。「企業側のWorkがどう変化したか」と「AI側のCapabilityがどこまで進化したか」という二つの変数によって、継続的に変化するものです。だからこそ必要なのは、一度だけ業務を棚卸ししてAI代替可能性を診断することではありません。企業固有の仕事を構造として捉え、その変化を継続的に更新できる「仕事の地図」です。
では、その仕事の地図を、どのような構造として表現すればよいのでしょうか。単なるJobやTaskの一覧ではなく、Person、Organization、Job、Work、Task、Skill、Performanceといった企業活動を構成する要素の関係性まで表現する必要があります。その考え方が、次に取り上げるWork Ontologyです。
2｜Work Ontologyとは何か
前章では、AIカバレッジを正確に把握するためには、企業固有の「仕事の地図」が必要であると整理しました。では、その地図は、どのような形で表現すればよいのでしょうか。単に「営業にはこの業務がある」「人事にはこの業務がある」とTaskを一覧化するだけでは十分ではありません。企業活動は、一つひとつのTaskが独立して存在しているのではなく、人、組織、役割、仕事、Skill、成果などが相互につながることで成立しているからです。VOL.02でも、AIカバレッジを経営判断につなげるには、Person、Organization、Job、Work、Task、Skill、Performanceなどの関係性として企業活動を捉える必要があると整理しました。 この企業固有の「仕事がどのような構造と関係性によって成り立っているのか」を表現する考え方が、Work Ontologyです。
2-1｜「一覧」ではなく「関係性」を表現する
Work Ontologyを理解する上で最も重要なのは、仕事を単なるデータの一覧として捉えないことです。例えば、「Aさんは営業部に所属している」「Aさんの職種はAccount Executiveである」「Aさんは提案資料を作成している」といった情報を個別に持っているだけでは、企業活動の全体像は十分に見えてきません。必要なのは、それらの情報がどのようにつながっているのかを表現することです。誰が、どの組織に所属し、どの役割を担い、どのWorkやTaskを実行し、そのためにどのSkillを使い、結果としてどのPerformanceにつながっているのか。この関係性を構造として持つことで、企業の仕事を「点」ではなく「地図」として捉えられるようになります。
2-1-1｜Person
最初の要素がPersonです。企業の仕事は、最終的には誰かによって担われています。そのため、企業活動を理解するには、「誰がその仕事を行っているのか」という情報が起点になります。ただし、単に社員名や社員IDを持つだけでは十分ではありません。そのPersonがどのOrganizationに所属し、どのJobやRoleを担い、どのWorkやTaskに関与しているのかまでつなげて見る必要があります。同じJobに属するPersonであっても、担当顧客、案件、経験、Skillによって、実際に担う仕事は異なる可能性があります。Personを仕事の構造と接続することで、制度上の人員配置ではなく、企業活動の中で実際に誰が何を担っているのかを理解できるようになります。
2-1-2｜Organization
次に必要となるのがOrganizationです。人は企業の中で単独で仕事をしているわけではなく、部門、チーム、プロジェクトなど、何らかの組織単位に所属しながら仕事を行っています。同じTaskであっても、営業部門で行われる場合と、カスタマーサクセス部門で行われる場合では、その目的や前後の業務プロセスが異なることがあります。また、組織構造が変われば、それまで特定部門が担っていた仕事が別部門へ移ることもあります。そのため、Work Ontologyでは「誰が何をしているか」だけではなく、「どの組織の中でその仕事が行われているか」まで表現する必要があります。
2-1-3｜Job / Role
Job / Roleは、そのPersonが企業の中でどのような役割を担っているのかを示します。営業、人事企画、エンジニアといったJobはもちろん、マネージャー、プロジェクトリーダー、採用責任者といったRoleも含まれます。重要なのは、Job / Roleを仕事そのものと同一視しないことです。Job / Roleはあくまで仕事を束ねる枠組みであり、その中には複数のWorkやTaskが存在します。AIカバレッジを把握する際には、「営業というJobをAI化できるか」ではなく、「営業というJobを構成するどのTaskをAIが担えるのか」を見る必要があります。そのため、Job / RoleとWork / Taskを明確につなげることが重要になります。
2-1-4｜Work / Task
Work / Taskは、Work Ontologyの中でもAIカバレッジと直接接続する重要な要素です。Workは一定の目的を持った仕事のまとまりであり、Taskはそれを構成する具体的な実行単位として捉えることができます。例えば、営業というJobの中には「新規顧客を開拓する」「商談を進める」「提案を行う」といったWorkがあり、その中に「対象企業を選定する」「企業情報を収集する」「アプローチ文面を作成する」「商談内容を記録する」といったTaskが存在します。AI Capabilityと直接照らし合わせるためには、このTaskの粒度まで仕事を捉える必要があります。
2-1-5｜Skill
Skillは、そのTaskを実行するために何が必要なのかを表します。例えば、顧客との商談というTaskには、業界知識、ヒアリング力、課題設定力、提案力など複数のSkillが必要になる可能性があります。一方、データ整理や情報検索では、求められるSkillの構成は異なります。TaskとSkillを接続しておくことで、AIが担えるTaskが増えたときに、人にどのSkillが残るのか、逆に新たにどのSkillが必要になるのかを考えられるようになります。これはAI活用だけでなく、採用、配置、育成などのWorkforce Strategyにもつながる重要な情報です。
2-1-6｜Performance
最後に必要なのがPerformanceです。仕事を理解する上では、「何をしているか」だけでなく、「その仕事がどのような成果につながっているか」まで見る必要があります。同じTaskに多くの時間を使っていたとしても、それが事業成果に大きく寄与しているのか、単なる付随業務なのかによって、AXの優先順位は変わります。営業であれば売上や受注率、採用であれば採用数や採用リードタイム、カスタマーサクセスであれば継続率や顧客満足度など、TaskとPerformanceをつなげて捉えることで、「どの仕事を変えると、どの成果に影響するのか」を理解できるようになります。
2-2｜関係性が企業のContextになる
Work Ontologyの本質は、これらの要素を個別に管理することではありません。Person、Organization、Job / Role、Work / Task、Skill、Performanceを相互に接続し、「企業の中で仕事がどのように成り立っているのか」を関係性として表現することにあります。この関係性こそが、AIが企業を理解するためのContextになります。
2-2-1｜「誰が何をしている」だけではない
例えば、「Aさんが提案資料を作成している」という情報だけでは、そのTaskの意味を十分に理解することはできません。Aさんがどの組織に所属し、どのJobを担い、どの顧客に対して、どのWorkの一部としてそのTaskを行い、どのSkillを使い、その結果としてどの成果を生み出しているのかまで分かって初めて、その仕事の意味が見えてきます。
同じ「資料作成」というTaskであっても、新規顧客向けの提案資料、経営会議向けの報告資料、採用候補者向けの会社説明資料では、目的も必要なSkillも成果も異なります。Task名だけを見れば同じ仕事に見えても、関係するPerson、Organization、Job、目的、成果が異なれば、企業にとっての意味はまったく異なります。
AIカバレッジを正確に評価する上でも、この違いは重要です。単純な資料作成であればAIが大部分を担えるかもしれませんが、高度な意思決定や顧客との関係性を前提とした資料であれば、人の判断がより強く求められる可能性があります。つまり、AI適用可能性を判断するためにはTaskの名称だけではなく、そのTaskが置かれているContextまで理解する必要があるのです。
2-2-2｜企業固有の意味を持たせる
さらに重要なのは、同じ言葉であっても、企業によって意味が異なるという点です。「営業」「プロジェクトマネージャー」「ハイパフォーマー」「重要顧客」といった言葉は、一見すると共通した意味を持っているように見えます。しかし、実際に何を指しているのかは企業によって異なります。
例えば、ある企業における「営業」は新規開拓を中心とする役割かもしれませんが、別の企業では既存顧客の拡大を中心とする役割かもしれません。「ハイパフォーマー」という概念も、売上額を指す企業もあれば、利益率、顧客満足度、チームへの貢献など複数の指標を組み合わせて定義する企業もあります。
AIが企業のデータを活用する際に重要なのは、データベース上に「営業」という文字列が存在していることではありません。その企業において「営業」がどのようなJobで、どのWorkやTaskによって構成され、どのSkillが求められ、どのPerformanceによって評価されているのかを理解できることです。
つまり、Work Ontologyの目的は、企業の情報に共通のラベルを付けることではありません。企業の中で使われる一つひとつの情報に、企業固有の意味と関係性を持たせることです。それによって初めて、AIは単にデータを検索するだけではなく、「この企業では、誰が、どのような役割で、何を行い、何によって成果を生み出しているのか」という企業活動の構造を理解できるようになります。
しかし、ここで新たな問題が生まれます。こうしたPerson、Organization、Job、Work、Task、Skill、Performanceの情報は、通常、一つのシステムにまとまって存在しているわけではありません。人事システム、CRM、ERP、プロジェクト管理ツール、ドキュメント、チャットなど、企業内のさまざまな場所に分散しています。Work Ontologyを構築するためには、まずこれらの分散した情報をどのようにつなぐのかを考える必要があります。
3｜Work情報は社内に存在するが、分散している
前章では、Work Ontologyとは、Person、Organization、Job、Work、Task、Skill、Performanceといった要素を単独で管理するのではなく、それらの関係性によって企業固有の「仕事の地図」を表現する考え方であると整理しました。では、その地図をつくるための情報は、どこから取得すればよいのでしょうか。実は、多くの企業にはすでに必要な情報の大部分が存在しています。問題は、情報がないことではありません。人に関する情報は人事システム、顧客との活動はCRM、売上や取引はERP、日々のプロジェクトはプロジェクト管理ツール、実際の議論や成果物はチャットやドキュメントに記録されるなど、企業活動を理解するための情報が複数のシステムに分散していることです。一つひとつを見れば企業活動の一部分は理解できます。しかし、それらが相互につながっていなければ、「誰が、どの仕事を、どのSkillを使って行い、どの成果につなげているのか」という企業全体の構造までは見えてきません。Work Ontologyを構築するためには、これまで別々の目的で蓄積されてきたデータを、企業理解という視点から接続し直す必要があります。
3-1｜HR Dataだけでは仕事の実態は分からない
3-1-1｜人事データは「骨格」
HR Dataは、企業固有の仕事の地図をつくる上で「骨格」にあたります。誰が企業に存在し、どのOrganizationに所属し、どのJobやRoleを担い、どのようなSkillや評価を持っているのか。これらを整理することで、企業の人と組織の基本構造を把握できます。
例えば、営業本部に100人が所属し、その中にAccount Executive、Sales Manager、Sales Operationsといった複数のJobが存在していることは、人事データから把握できます。また、誰がどの部署へ異動したのか、どのSkillを保有しているのか、どのような評価を受けているのかといった情報も、人と仕事の関係性を理解する上で重要です。
特にPerson、Organization、Job / Roleは、企業活動を構造化する際の基本的な軸になります。企業の仕事を理解する際に、いきなりすべてのTaskを並べても、それを誰が、どの組織で、どの役割として担っているのかが分からなければ、仕事の構造として捉えることはできません。その意味で、HR DataはWork Ontologyを形成する重要な土台です。
一方で、組織図や職種情報だけでは、実際の仕事の内容までは見えてきません。同じAccount ExecutiveというJobであっても、担当している顧客や案件、日々行っているTask、時間の使い方、成果の生み出し方は異なります。人事データによって企業活動の「骨格」は見えても、その骨格の上で実際に何が行われているのかまでは分からないのです。
3-1-2｜業務データで「肉付け」する
そこで必要になるのが、日々の企業活動から生まれる業務データです。CRMには、誰がどの顧客を担当し、どの商談を進め、どのような活動を行ったのかが記録されています。ERPには、受注、売上、原価、取引など、企業活動の結果が蓄積されています。プロジェクト管理ツールには、誰がどのプロジェクトに参加し、どのTaskを担当しているのかが記録されます。ドキュメントには、提案資料、議事録、企画書、仕様書などの成果物があり、チャットには、日々の議論、意思決定、情報共有、調整の過程が残されています。
これらをHR Dataと接続すると、人事データだけでは見えなかった仕事の実態が見えるようになります。例えば、「営業部に所属するAccount Executive」という情報に、「どの顧客を担当しているのか」「どの案件に関与しているのか」「どのような提案資料を作成しているのか」「どれだけ商談を行っているのか」「その結果としてどれだけの受注につながっているのか」といった情報が加われば、Jobの名称だけでは見えなかったWorkやTask、Performanceとの関係が見えてきます。
つまり、HR Dataによって人と組織の「骨格」をつくり、業務データによって実際のWorkやTask、成果を「肉付け」していくという考え方です。この二つを組み合わせることで、制度上定義された企業ではなく、実際に活動している企業の姿を捉えられるようになります。
重要なのは、企業内に新しいデータを大量につくることではありません。すでに企業活動の中で発生しているデータを、人、組織、仕事という共通の構造に沿って接続し直すことです。それによって、これまでシステムごとに切り離されていた情報が、「企業では実際にどのような仕事が行われているのか」を理解するためのContextへ変わっていきます。
3-2｜Closed Dataだけでも足りない
3-2-1｜外部のJob・Skill・AI情報も必要
企業内では、「自社でどのような仕事が行われているのか」を理解できます。しかし、その仕事を社会全体の中で意味づけるためには、外部の情報との照合が必要です。
例えば、ある企業の中で「データアナリスト」と呼ばれているJobがあったとしても、そのJobが市場一般ではどのようなSkillを求められているのか、類似するJobには何があるのか、どのSkillの需要が高まっているのかは、企業内部のデータだけでは十分に把握できません。求人情報、公開プロフィール、職種・Skillデータ、市場情報などのOpen Dataと照合することで、自社のJobやSkillを外部市場の中に位置づけられるようになります。
AIカバレッジを考える際には、さらにAI Capabilityの情報も必要です。自社に「契約書を確認する」「顧客情報を収集する」「提案書を作成する」といったTaskが存在することが分かっても、現在のAIがそれらをどの程度実行できるのかが分からなければ、AI適用可能性を評価できません。
AIモデルやAIエージェントのCapabilityは急速に進化しています。生成、検索、要約、分類だけでなく、推論、計画、外部ツールの操作、複数Stepの実行など、AIが担えるTaskは広がり続けています。企業側のWork Ontologyと照らし合わせるためには、こうした外部のAI Capabilityも継続的に捉える必要があります。
3-2-2｜Open × Closed
ここで重要になるのが、Open DataとClosed Dataを分けて考えるのではなく、両者を接続するという発想です。
Closed Dataには、自社の社員、組織、Job、顧客、案件、Task、成果など、その企業でしか持ち得ない固有の情報があります。一方、Open Dataには、市場に存在するJob、Skill、人材、企業、Technology、AI Capabilityなど、企業の外側に存在する情報があります。
Closed Dataだけを見れば「自社で何が起きているのか」は理解できますが、それが市場やTechnologyの変化の中でどのような意味を持つのかは見えにくくなります。Open Dataだけを見れば、世の中のJobやSkill、AIの進化は理解できますが、それが自社のどの仕事に関係するのかは分かりません。
だからこそ、Open × Closedという接続が重要になります。例えば、自社のAccount Executiveが実際に行っているTaskをClosed Dataから捉え、それを市場に存在する営業系JobやSkillの情報と照合し、さらに最新のAI Capabilityと接続することで、「自社のこのTaskに対して、現在どのようなAIを適用できるのか」を企業固有の文脈で考えられるようになります。
Work Ontologyとは、企業内部の情報だけをきれいに整理するものではありません。企業固有のClosed Dataを中心に置きながら、必要に応じて外部のOpen Dataを接続し、その企業にとっての意味を豊かにしていく構造です。こうして初めて、企業活動を内側だけから見るのではなく、市場、Skill、Technology、AIの変化まで含めたContextとして捉えられるようになります。
しかし、ここでさらに重要な問いが生まれます。企業の中には、人事、CRM、ERP、プロジェクト管理、ドキュメント、チャットなど多数のデータソースがあり、外部にもさまざまなOpen Dataが存在します。これらを単純に一か所へ集めれば、企業の仕事を理解できるのでしょうか。答えは、必ずしもそうではありません。必要なのは、データを集めることではなく、データ同士の意味と関係性を理解できる状態へ変えることです。
4｜Context Engineが分散データを「企業理解」に変える
企業の情報が分散しているのであれば、「すべてのデータを一か所に集めればよい」と考えるかもしれません。実際、企業ではData LakeやDWHなどを用いて、複数システムのデータを集約する取り組みが進められてきました。もちろん、データを横断的に利用できる状態をつくることは重要です。しかし、AIが企業固有の仕事を理解するという目的で考えると、データを集めるだけでは十分ではありません。必要なのは、異なるシステムに存在するデータについて、「これは誰なのか」「何を意味するのか」「何と何が関係しているのか」「どのような背景で生まれた情報なのか」まで理解できる状態にすることです。分散したDataを企業固有のContextへ変換し、Work Ontologyとして利用できる状態をつくる。そのための基盤となる考え方がContext Engineです。
4-1｜単純なデータ統合との違い
4-1-1｜集めるだけではAIは理解できない
例えば、人事システムに「山田太郎」という社員が存在し、CRMに「Taro Yamada」という担当者名があり、プロジェクト管理ツールではメールアドレスをIDとして同じ人物が記録されていたとします。これらのデータを同じData Lakeに保存したとしても、それだけで三つのデータが同一人物を指していると理解されるわけではありません。
同様に、「営業」という言葉もシステムごとに意味が異なる可能性があります。人事システムでは職種としての営業を意味し、CRMでは営業活動を意味し、会計データでは営業部門というコストセンターを意味しているかもしれません。文字列として同じでも、企業活動における意味は異なります。
さらに、チャットやドキュメントには、構造化されたデータベースの項目として表現されていない情報も大量に存在します。誰がどの案件について議論したのか、なぜその判断をしたのか、どのような資料を作成したのかといった情報は、文章や会話の中に含まれています。
このような状態では、データが一か所に存在していても、AIにとっては依然として断片的な情報の集合です。データ量が増えたからといって、自動的に「企業理解」が深まるわけではありません。
4-1-2｜必要なのはContext化
そこで必要になるのがContext化です。Context化とは、データを単なる値や文章として保存するのではなく、その情報が「何を意味し、何と関係し、どのような背景を持つのか」を扱える状態へ変えることです。
例えば、「Aさん」というPersonが「エンタープライズ営業部」というOrganizationに所属し、「Account Executive」というJobを担い、「顧客分析」「商談準備」「提案設計」といったTaskを行い、そのために「業界知識」「課題設定」「提案力」といったSkillを使い、結果として受注や売上というPerformanceにつながっているという関係性が形成されれば、一つひとつのデータは企業活動としての意味を持ち始めます。
重要なのは、Contextが単なる説明文ではないということです。「Person A」「Task B」「Skill C」という情報を持つだけではなく、Person AがTask Bを担い、そのTask BにはSkill Cが必要で、そのTask BがPerformance Dにつながっているという関係性まで扱えることが重要です。
AIが企業を理解するとは、企業内の文章を大量に読み込めることだけを意味しません。企業固有の人、組織、仕事、Skill、成果がどのようにつながっているのかを理解できることです。Context Engineは、分散して存在するDataを、この企業固有の関係性へ変換するための基盤として捉えることができます。
4-2｜Context Engineの役割
では、Context Engineは具体的に何を行うのでしょうか。重要な役割は、大きくConnect、Identify、Structure、Relate、Updateの五つに整理できます。これらは独立した機能ではなく、分散したDataを企業固有のContextへ変えていく一連のプロセスです。
4-2-1｜Connect
最初の役割がConnectです。企業内外に分散する複数のデータソースを接続します。
企業内部だけでも、人事システム、ATS、CRM、ERP、プロジェクト管理、ファイルストレージ、ドキュメント、チャットなど、多数のデータソースが存在します。さらに、必要に応じて外部の求人、企業、人材、Skill、AI CapabilityなどのOpen Dataも利用します。
ここで重要なのは、すべてのデータを一つの巨大なシステムへ置き換えることではありません。それぞれのシステムには、それぞれの業務上の役割があります。必要なのは、既存システムをすべてなくすことではなく、分散したまま存在する情報へ横断的にアクセスし、相互に利用できる状態をつくることです。
4-2-2｜Identify
次に必要なのがIdentifyです。複数のシステムに存在する情報が、現実世界の同じPerson、Organization、Job、Companyなどを指していることを認識し、つなげます。
例えば、人事システムでは社員番号、CRMではメールアドレス、ドキュメントでは氏名によって同じPersonが表現されているかもしれません。表記揺れや異なるIDが存在する状態で、単純にデータを結合しても正しく接続できないケースがあります。
同様に、企業名、部署名、Job名、Skill名についても、システムやデータソースによって表現が異なる場合があります。異なる情報が同じ実体を指しているのか、別の実体なのかを識別することで、初めてデータを企業活動の実態に沿って接続できます。
4-2-3｜Structure
三つ目がStructureです。企業の情報は、すべてが整理された表形式で保存されているわけではありません。ドキュメント、議事録、チャット、職務記述書、提案資料など、非構造・半構造の情報が企業内には大量に存在します。
これらの情報から、Person、Organization、Job、Work、Task、Skill、Performanceなど、企業理解に必要な要素を抽出し、AIが扱いやすい構造へ変換します。
例えば、職務記述書の文章からJobとSkillの関係を抽出したり、プロジェクト資料から関係するPersonやTaskを把握したり、業務マニュアルからWorkとTaskの構造を整理したりすることが考えられます。
Structureによって、文章として存在していた情報がWork Ontologyを構成する要素として扱えるようになります。
4-2-4｜Relate
四つ目がRelateです。これはContext Engineにおいて特に重要な役割です。構造化されたデータ同士の「関係性」を形成します。
PersonがOrganizationに所属する。PersonがJobを担う。Jobが複数のWorkによって構成される。Workが複数のTaskから成る。TaskにはSkillが必要になる。Taskの実行がPerformanceにつながる。さらにTaskにAI Capabilityを接続すれば、そのTaskをAIがどの程度支援・代替できるのかを評価できるようになります。
このように、個別のデータをつなぎ合わせることで、単なる情報の集合が「企業固有の仕事の地図」へ変わります。
Relateが重要なのは、企業の意味が個々のデータではなく、関係性の中に存在するからです。「Aさん」という情報そのものよりも、「AさんがどのOrganizationに所属し、どのJobを担い、どのTaskを実行し、どのPerformanceを生み出しているのか」という関係性の方が、企業理解において大きな意味を持ちます。
4-2-5｜Update
最後がUpdateです。Work Ontologyは一度構築すれば完成する静的なマスターデータではありません。企業活動が変化するたびに、その構造も更新される必要があります。
社員が入社・退職し、組織が変わり、Jobが変わり、新しいプロジェクトやTaskが生まれます。新しいシステムが導入されれば業務プロセスも変わります。そしてAIが企業活動へ組み込まれれば、それまでHumanが担っていたTaskをAIが担うようになり、Human側のJobやSkillも再設計されていきます。
さらに、外部のAI Capabilityも継続的に変化します。新しいAIモデルやAIエージェントによって、これまでAI化できなかったTaskがAI Ledへ変化する可能性もあります。
そのため、Context Engineに求められるのは、一度だけ企業データを整理することではありません。社内外のデータ変化を継続的に取り込み、Identify、Structure、Relateを繰り返しながら、企業固有のContextを更新し続けることです。
Connectし、Identifyし、Structureし、Relateし、Updateする。この一連の流れによって、企業内外に分散していたDataは、AIが利用可能な「企業理解」へ変わっていきます。そして、その上に形成されるWork Ontologyがあるからこそ、AIは単に社内情報を検索するだけではなく、「この企業にどのような仕事が存在し、その仕事を誰が担い、どのSkillが必要で、どの成果につながっているのか」を理解できるようになります。
ここまでくると、次に必要なものも見えてきます。企業側にWork Ontologyという「仕事の地図」ができても、それだけではAIカバレッジは算出できません。その地図に対して、「現在のAIには何ができるのか」というAI側のCapabilityを重ねる必要があります。次に、Enterprise Work OntologyとAI Capabilityという二つの構造をどのように接続し、企業固有のAIカバレッジへ変換していくのかを整理します。
5｜Work OntologyとAI Capabilityを接続する
ここまで、企業固有の仕事をPerson、Organization、Job、Work、Task、Skill、Performanceの関係性として捉えるWork Ontologyと、その構築・更新を支えるContext Engineについて整理してきました。しかし、Work Ontologyを構築すること自体が最終目的ではありません。Work Ontologyによって明らかになるのは、「この企業にはどのような仕事が存在し、それがどのような関係性によって成り立っているのか」という企業側の構造です。AIカバレッジを把握するためには、ここにもう一つの構造を重ねる必要があります。それが、「現在のAIには何ができるのか」を表すAI Capabilityです。企業側のWork OntologyとAI側のCapabilityを同じTaskの粒度で接続することで、初めて「自社のどの仕事を、現在のAIがどこまで担えるのか」を具体的に判断できるようになります。
5-1｜企業側とAI側の二つの構造
AIカバレッジを成立させるためには、企業側とAI側、それぞれを構造として捉える必要があります。企業側だけを詳しく理解しても、AIが何をできるか分からなければ適用可能性は判断できません。反対に、AIのCapabilityを詳しく把握していても、自社にどのようなTaskが存在するのかが分からなければ、それをどこへ適用すべきか判断できません。重要なのは、どちらか一方を起点にするのではなく、二つの構造を対応づけられる状態をつくることです。
5-1-1｜Enterprise Work Ontology
企業側に必要なのがEnterprise Work Ontologyです。これは、企業の中にどのようなJob、Work、Taskが存在し、それらを誰が担い、どのSkillが必要で、どのPerformanceにつながっているのかを企業固有の構造として表現したものです。
ここで重要なのは、単にTask名を並べるのではなく、そのTaskが置かれているContextまで持つことです。同じ「情報を収集する」というTaskでも、営業担当者が商談準備のために顧客企業を調査する場合と、人事担当者が候補者を理解するために情報を集める場合では、参照する情報、求められる精度、意思決定への影響が異なります。同じように見えるTaskでも、目的や責任、利用するデータ、後続するプロセスが違えば、AIへ任せられる範囲も変わります。
Enterprise Work Ontologyを持つ意味は、企業活動を一般的な職種分類ではなく、「自社では実際に仕事がどのように行われているのか」という実態から捉えられることにあります。誰が、何のために、どのTaskを実行し、何につながっているのか。その構造があることで、AI Capabilityを企業固有の仕事へ正しく対応づけるための土台ができます。
5-1-2｜AI Capability
もう一方に必要なのがAI Capabilityです。AI Capabilityとは、特定の製品名やモデル名そのものではなく、「現在のAIがどのような能力を持っているのか」をTaskへ適用可能な単位で捉えたものです。
例えば、文章を生成する、情報を検索する、複数の資料を要約する、情報を分類する、画像や文書から情報を抽出する、条件に沿って比較する、パターンを検出する、複数の情報をもとに推論する、計画を立てる、外部ツールを操作する、一定の条件下で一連の処理を実行するといったCapabilityがあります。AIエージェントの発展によって、単一のTaskを支援するだけではなく、複数のTaskをつなぎながら一連のWorkを実行できる領域も広がっています。
重要なのは、AI Capabilityを「生成AI」「AIエージェント」といった大きなカテゴリーで捉えすぎないことです。AIカバレッジを判断するには、「このAIを導入できるか」ではなく、「このTaskに必要な能力を、現在のAIがどの程度満たせるか」を見る必要があります。そのため、企業側をTaskまで分解するのと同じように、AI側についてもCapabilityの粒度で捉えることが重要になります。
5-2｜TaskとAI Capabilityをマッピングする
企業側にEnterprise Work Ontologyがあり、AI側にCapabilityの構造ができれば、次に行うのが両者のマッピングです。企業内の一つひとつのTaskについて、そのTaskを実行するために必要な能力を整理し、現在のAI Capabilityと照らし合わせます。ここで初めて、AIカバレッジが一般論ではなく、企業固有の評価へ変わります。
5-2-1｜AI適用可能性を評価する
例えば、「商談前に顧客企業の情報を調査し、仮説を整理する」というTaskがEnterprise Work Ontology上に存在するとします。このTaskには、企業情報の検索、複数情報の統合、要約、比較、仮説生成などの能力が必要になります。これらを現在のAI Capabilityと照らし合わせれば、情報収集や整理の多くはAIが担える一方で、最終的な仮説の妥当性判断には人の経験や顧客Contextが必要になる、といった評価が可能になります。
別のTaskとして、「重要顧客との契約条件を最終交渉する」という仕事を考えれば、必要なCapabilityは異なります。契約内容の整理や論点抽出はAIが支援できても、相手との関係性、過去の交渉経緯、事業上の重要性、リスク許容度などを踏まえた最終判断までAIへ委ねることが適切とは限りません。
つまり、TaskとAI Capabilityの接続では、「技術的にAIが実行できるか」だけを見るのではなく、そのTaskのContextまで含めて評価する必要があります。求められる精度、失敗した場合の影響、利用できるデータ、説明責任、セキュリティ、人による確認の必要性などによって、実際にAIへ任せられる範囲は変わるからです。
こうした評価によって、それぞれのTaskをHuman Only、Human Led / AI Assisted、AI Led / Human Approved、AI Autonomousといった段階に位置づけることができます。重要なのは、すべてのTaskをAI Autonomousへ近づけることではありません。それぞれの仕事について、HumanとAIのどのような役割分担が最も合理的なのかを判断することです。
5-2-2｜AI Coverageへ変換する
一つひとつのTaskについてAI適用可能性を評価し、それをEnterprise Work Ontology全体へ重ねることで、企業固有のAIカバレッジが見えてきます。
営業、人事、経理、マーケティング、開発といったJobごとに見ることもできますし、部門、組織、業務プロセス単位で見ることもできます。「この部門ではHuman Led / AI AssistedのTaskが多い」「この業務プロセスではAI Ledへ移行できるTaskが集中している」「このJobではAIによってTask構成が大きく変わる可能性がある」といった形で、企業活動のどこにAIが入り得るのかを構造的に把握できるようになります。
ここで重要なのは、AIカバレッジを一つのパーセンテージだけで表現しないことです。「全社のAIカバレッジは45％」という数字だけでは、どの仕事がどのように変わるのかは分かりません。本当に必要なのは、その45％がどのTaskによって構成され、誰の仕事に影響し、どのSkillが変化し、どのPerformanceにつながるのかまでたどれることです。
Work Ontologyがあることで、AIカバレッジは単なるAI代替可能性の一覧ではなくなります。あるTaskのAI適用度が変わったとき、そのTaskを含むWorkはどう変わるのか、そのWorkを担うJobはどう変わるのか、どのPersonに影響するのか、どのSkillが重要になるのかまで関係性をたどることができます。
つまり、Work OntologyとAI Capabilityを接続することで、AIカバレッジは「AIに何ができるか」というTechnologyの評価から、「AIによって自社の仕事がどう変わるか」を理解するための企業固有の地図へ変わります。
6｜静的な「診断」から動的な「経営基盤」へ
ここまでの考え方だけを見ると、企業のWorkやTaskを整理し、AI Capabilityと照らし合わせ、一度AIカバレッジを算出すればよいように見えるかもしれません。しかし、AIカバレッジをAXの基盤として使うのであれば、一度限りの「診断」にしてはいけません。なぜなら、比較する二つの対象である企業側のWorkとAI側のCapabilityが、どちらも変化し続けるからです。今日算出したAIカバレッジが、半年後にも同じとは限りません。企業が変わり、AIが変われば、HumanとAIの最適な役割分担も変わります。だからこそ、AIカバレッジは定期的に測定するレポートではなく、継続的に更新される経営基盤として捉える必要があります。
6-1｜AI Coverageは一度測って終わりではない
6-1-1｜企業が変わればCoverageも変わる
企業の仕事は常に変わっています。新しい事業が立ち上がれば新しいJobやWorkが生まれます。組織変更が行われればPersonとOrganization、Jobの関係が変わります。M&Aが行われれば異なる組織、システム、業務プロセスを統合する必要があります。CRMやERPなどのシステムを刷新すれば、これまで人が担っていたTaskがなくなったり、新しいTaskが生まれたりします。
さらに、AI導入そのものによって仕事も変化します。例えば、営業担当者が毎日行っていた顧客情報収集をAIが担うようになれば、そのTaskに使われていた時間は減少します。その結果、営業担当者は顧客との対話や提案設計により多くの時間を使うようになり、同じAccount ExecutiveというJobであってもTask構成が変化していきます。
つまり、AIを導入すればWork Ontologyが変わり、Work Ontologyが変われば再びAIカバレッジも変わります。AIカバレッジはAI導入前に一度算出するものではなく、AXが進むことによって自ら変化していく指標なのです。
6-1-2｜AIが進化すればCoverageも変わる
同時に、AI側のCapabilityも変わり続けます。新しいモデルが登場し、推論能力が高まり、扱えるデータ形式が増え、外部システムを操作できるようになれば、それまでHumanが主体だったTaskの一部をAIが担える可能性が生まれます。
例えば、現在はHuman Led / AI Assistedと評価されているTaskが、新しいAI CapabilityによってAI Led / Human Approvedへ変わることがあります。さらに、十分な精度、ガバナンス、データ環境が整えば、一定条件下でAI Autonomousへ進むTaskも出てくるかもしれません。
この変化を継続的に把握できなければ、企業はAI Technologyが進化するたびに、再びゼロから「このAIをどこで使えるのか」を探すことになります。一方、自社のWork Ontologyを持ち、AI Capabilityとの接続を継続的に更新できれば、新しいAIが登場した瞬間に、「自社のどのTaskに影響するのか」「どの領域のAIカバレッジが変化したのか」を把握しやすくなります。
重要なのは、AIの進化を追いかけること自体ではありません。AIの進化を、自社の仕事の変化へ翻訳できる仕組みを持つことです。
6-2｜継続的にHuman × AIを再設計する
6-2-1｜AI Coverageを更新する
そのための第一歩が、企業側のWorkとAI側のCapabilityを継続的に接続し直すことです。
Context EngineによってPerson、Organization、Job、Work、Task、Skill、Performanceの変化を捉え、Enterprise Work Ontologyを更新します。同時に、外部で進化するAI Capabilityを取り込み、各Taskとのマッピングを再評価します。
これによって、「これまでHuman OnlyだったTaskの一部がAI Assistedになった」「AI AssistedだったTaskをAI Ledへ移せるようになった」「新しい業務プロセスが生まれたことで新たなTaskが追加された」といった変化を継続的に把握できます。
この状態になれば、AIカバレッジは年に一度作成する診断レポートではなくなります。企業活動とAI Technologyの変化を反映しながら更新される、「HumanとAIの現在地」を示す地図になります。
6-2-2｜Workforceを更新する
そして、AIカバレッジが変われば、企業側のWorkforceも変える必要があります。
あるJobを構成するTaskのうち、AIが担える割合が大きくなれば、そのJobにおけるHumanの役割も変わります。それまで情報収集や資料作成が中心だったJobでAIがそれらを担うようになれば、人には顧客との対話、意思決定、創造、関係構築など、別のTaskへの比重が求められるようになります。
Taskが変われば、必要なSkillも変わります。必要なSkillが変われば、採用要件、育成内容、評価基準も変わります。さらに、Jobを構成するTaskそのものが大きく変われば、Job Designや人員配置、組織設計まで見直す必要があります。
このとき重要なのは、AIカバレッジを「何人減らせるか」という人員削減の指標として扱わないことです。見るべきなのは、AIによって生まれる新しいWorkforce Capacityをどのように使うのかです。同じ人数でより多くの成果を生み出すのか、人をより付加価値の高いTaskへ移すのか、新しい事業へ配置するのか。その選択は企業の戦略によって異なります。
AIカバレッジが示すのは、人をAIへ置き換える答えではありません。「どのTaskをAIへ任せ、どのTaskをHumanが担い、その結果としてHumanをどこへ再配置するべきか」を考えるための土台です。
ここまで来ると、Work OntologyとContext Engineの意味も変わって見えてきます。それらは、単にAIへデータを渡すための技術基盤ではありません。企業側のWorkとAI側のCapabilityを継続的に接続し、Human × AIの役割分担を更新し続けるための経営基盤です。
AIが進化するたびに新しいツールを探し、その都度ユースケースを考えるのではなく、自社の仕事の構造を持ち、その上に最新のAI Capabilityを重ね続ける。そうすることで企業は、AIの進化に追随する側から、AIの進化を継続的に企業変革へ取り込む側へ移ることができます。静的な「AI診断」ではなく、動的な「企業理解」を持つこと。その状態が、次に考えるAI ReadyからAI Nativeへの重要な前提になります。
7｜AIが企業を理解する時代へ
ここまで、AIカバレッジを成立させるためには、企業固有のWork Ontologyが必要であり、その構築と更新を支える基盤としてContext Engineが必要になることを見てきました。重要なのは、単に社内データをAIから利用できるようにすることではありません。企業の中に存在するPerson、Organization、Job、Work、Task、Skill、Performanceを相互の関係性として捉え、「この企業では、誰が、どこで、何を、どのように行い、どのような成果を生み出しているのか」をAIが理解できる状態をつくることです。AIの性能が高まり続けるほど、競争力を左右するのはモデルそのものだけではなく、そのAIが企業固有のContextをどこまで持てるかへと移っていきます。汎用的に賢いAIを導入することから、自社を理解したAIを企業活動へ組み込むことへ。AXは、その段階へ進み始めています。
7-1｜AI ReadyからAI Nativeへ
これまで企業におけるAI活用では、「AIにデータを渡せる状態をつくること」が重要なテーマの一つでした。社内情報を検索できるようにする、社内文書を参照して回答できるようにする、複数システムのデータをAIから利用できるようにするといった取り組みです。これらはAIを企業活動へ組み込む上で重要な前提です。しかし、AIを本格的に業務や意思決定へ組み込んでいくのであれば、その先を考える必要があります。AIが必要なデータへアクセスできるだけではなく、そのデータが企業活動の中で何を意味しているのかを理解できる状態です。
7-1-1｜データを使えるだけでは足りない
例えば、AIがCRMにアクセスできれば、顧客名、商談金額、商談履歴、担当者などを取得できます。人事システムへアクセスできれば、社員の所属、役職、評価、Skillなどを取得できます。ドキュメントを検索できれば、過去の提案書や議事録を見つけることもできます。しかし、それぞれのデータへアクセスできることと、それらを企業活動として理解できることは同じではありません。
ある営業担当者について、所属部署、担当顧客、過去の商談、作成した提案資料、保有Skill、受注実績といった情報が別々に存在していたとしても、それらの関係性が分からなければ、AIは個別の情報を取得することしかできません。一方、「このPersonはこのOrganizationに所属し、このJobを担い、この顧客に対してこれらのTaskを実行し、その過程でこのSkillを使い、その結果としてこのPerformanceを生み出している」という関係性まで分かれば、AIが扱える情報の意味は大きく変わります。
この違いは、AIがより高度な判断や実行を担うほど重要になります。単純な検索や要約であれば、必要な文書を見つけられるだけでも価値を生み出せます。しかし、「次にどの顧客へアプローチするべきか」「この案件を進めるには社内の誰を巻き込むべきか」「このJobで今後必要になるSkillは何か」「どのTaskからAIへ移すべきか」といった企業固有の判断をAIに支援させるためには、データそのものだけでは足りません。企業固有の意味と関係性、すなわちContextが必要になります。
つまり、AI Readyとは、単にデータ形式を整え、AIからアクセス可能にすることだけではありません。AIが企業活動の意味を理解し、必要なContextを利用できる状態まで含めて考える必要があります。そして、そのContextが蓄積されるほど、AIは一般的な回答を返す存在から、その企業の仕事を前提として判断や実行を支援する存在へ変わっていきます。
7-1-2｜企業そのものをContextとして理解させる
その先にあるのが、AIが「企業そのもの」をContextとして理解する状態です。企業とは、データベースや文書の集合ではありません。人が存在し、組織が形成され、それぞれのJobがWorkやTaskを担い、Skillを使いながら成果を生み出しています。顧客や取引先との関係があり、過去の意思決定や業務プロセスがあり、企業固有のルールや文化があります。こうした要素が相互に関係することで、一つの企業活動が成り立っています。
Work Ontologyによって、この企業活動を構成する関係性を構造として持つことができれば、AIは単に「社内に何の情報があるか」を知るだけではなく、「この企業がどのように動いているのか」を理解する方向へ進むことができます。
例えば、「営業部門の生産性を高めたい」という問いに対して、一般的なAIであれば営業生産性向上の方法を提示することはできます。しかし、企業固有のWork Ontologyを参照できれば、その企業の営業担当者がどのTaskに多くの時間を使っているのか、どのTaskが受注に強く関係しているのか、どのSkillを持つ人が高いPerformanceを出しているのか、現在のAI CapabilityによってどのTaskを支援・代替できるのかを踏まえて考えることが可能になります。
同じように、人員配置を考える場合も、単純な所属や職種だけではなく、PersonとSkill、Work、Performanceの関係性を踏まえて候補を考えられます。AIエージェントに業務を任せる場合も、そのTaskに必要なデータ、権限、前後の業務プロセス、人へのエスカレーション条件をContextとして理解させることで、企業固有の業務の中で動かせる可能性が高まります。
ここで目指しているのは、AIにすべての経営判断を委ねることではありません。企業固有のContextをAIが理解できるようにすることで、人が判断すべき領域とAIが担える領域をより高い解像度で設計し、AIを企業活動の一部として機能させることです。
これまでのAI活用が「人がAIを使う」という関係を中心としていたとすれば、これからは、HumanとAIが同じ企業Contextを共有しながら仕事を進める状態へ移っていきます。人だけが企業の文脈を理解し、AIには毎回必要な情報を入力するのではなく、AI自身が企業固有のPerson、Organization、Work、Task、Skill、Performanceの関係性を参照しながら支援・判断・実行する。その状態が広がるほど、企業はAIを後付けのツールとして利用する状態から、AIを前提として企業活動そのものを設計するAI Nativeな状態へ近づいていきます。
7-2｜Series 02への接続
Series 01では、「どのAIを導入するか」というTechnology起点の議論から離れ、AXを企業活動そのものから捉え直してきました。VOL.01では、AXが進まない背景にはAIの性能だけではなく、AIを適用する対象である「自社の仕事」が十分に見えていないという問題があることを整理しました。VOL.02では、その仕事をWorkやTaskの単位で捉え、現在のAI Capabilityと照らし合わせることで、「企業活動のどこまでをAIが担えるのか」を示すAIカバレッジという考え方を提示しました。そして本稿では、そのAIカバレッジを企業固有のものとして成立させるためには、Work Ontologyと、それを構築・更新し続けるContext Engineが必要になることを見てきました。
7-2-1｜基盤ができた後、どうAXを進めるのか
ここまでで、「なぜAXが進まないのか」「何を可視化するべきなのか」「それをどのような基盤によって把握するのか」というSeries 01の問いは一つにつながります。
自社のWorkを理解し、Work Ontologyとして構造化する。その上に最新のAI Capabilityを重ね、AIカバレッジを継続的に把握する。
これによって企業は、「生成AIを導入する」「AIエージェントを使う」といったTechnology起点ではなく、「自社のどの仕事を、どこまでAIに任せるのか」という企業活動起点でAXを考えられるようになります。
しかし、仕事の地図が見え、AIカバレッジが分かっただけで、企業がAI Nativeへ変わるわけではありません。次に必要になるのは、その情報を実際の変革へつなげることです。AIカバレッジの高い領域の中から何を優先するのか。既存の業務プロセスをどのように再設計するのか。HumanとAIの役割をどのように分けるのか。AIによって生まれた余力をどこへ再配置するのか。JobやSkill、人員配置、組織構造をどのように変えるのか。そして、それらを単発のAI導入施策ではなく、全社の経営変革としてどのように進めるのか。ここから先は、「理解する」ことから「変える」ことへテーマが移ります。
Series 02「AIネイティブ｜AX推進の考え方と方法論」では、このAIカバレッジを起点として、企業活動を実際にHuman × AIへ再設計していく方法を考えていきます。
AIの進化は、これからも止まりません。そのたびに新しいAIを導入し、新しいユースケースを探し続けるのか。それとも、自社の仕事の地図を持ち、AIの進化を企業変革へ継続的に取り込める構造をつくるのか。AXにおける大きな違いは、そこから生まれます。
「どのAIを導入するか」から、「自社のどこまでをAIが担えるのか」へ。そして、その可能性を前提に「企業そのものをどう変えるのか」へ。
AIが企業を理解できる基盤をつくることは、AI Nativeな企業へ向かうためのゴールではありません。それは、企業がHumanとAIの新しい働き方を設計し続けるためのスタート地点なのです。
あらゆるデータを整備し、AIが活躍できる状態へ
XAION（ザイオン）は特許技術を活用したコンテキストエンジンで、企業の眠るデータ資産にコンテキストを付与し"生きた知能"へと変換します。
