戦略コンサルティング

STP策定支援

ペルソナ / CJM /UXフロー策定支援

プライシング再設計支援

KGI / KSF / KPI / ミッションツリー策定支援

SaaSモデル / クラウド化転換支援

新規事業立ち上げ支援

ITコンサルティング

ビジネス部門支援

経営企画・事業企画チーム立ち上げ支援

カスタマーサクセスチーム立ち上げ支援

CS ヘルススコア構築支援

カスタマーサポート対応自動化支援

サービスサイト / ランディングページ構築 / リニューアル支援

オウンドメディア立ち上げ支援

プロダクト部門支援

グロースハック施策企画 / 実行支援

プロダクトロードマップ策定支援

プロダクト開発体制支援

プロダクト運用体制支援

プロダクト組織の強化 / 育成支援

開発部門支援

インフラ(クラウドサーバー)コスト削減支援

開発パートナー会社見極め・選定伴走

CTO採用支援

データ支援

データ基盤(DWH)構築支援

Tableauダッシュボード構築支援

GA4導入 / 活用支援

データ活用人材育成・トレーニング

サービス

暗黙知を書く仕事

2026/6/17

株式会社deflag CDO

深川 泰雅

リンクをコピー

  • # データ基盤

  • # AI

「先週の売上は?」に答えられないAIエージェント

AIエージェントに「先週の売上は?」と聞いたら経理が締めた数字と違う値が返ってきた、という失敗談があります。
エージェント導入の現場でよく語られるもので、米国のベンチャーキャピタルa16zもデータエージェントの典型的なつまずきとしてこの例を挙げています。

なぜこのようなことが起きるかと言えば、売上という数字がデータベースから素直に取ってこられるものではないためです。
請求と入金のどちらのタイミングで数えるか、返金やキャンセルをいつ引くか、新しく始めた事業の売上をどの科目に入れるかといった判断の積み重ねの上に「先週の売上」は成り立っており、その判断の多くは経理や事業の担当者の頭の中にしかありません。

人間のアナリストであればおかしな数字が出た時点で手を止めて担当者に確認しに行けますが、エージェントは確認をせず、もっともらしい数字を自信を持って返してきます。
どれだけモデルが賢くなっても書かれていないことは知りようがないため、この問題はモデルの進化では解決されません。
そして企業の業務知識は、その大半が文書化されないまま担当者の頭の中に蓄積されています。


コンテキストレイヤーとは何か

この「書かれていない業務知識」をAIが読める形で整備した層は「コンテキストレイヤー」と呼ばれており、2025年末頃から急速に注目されています。

2025年12月に米国のVCであるFoundation Capitalが論考を公開したのを皮切りに、a16zが概念を整理し、データカタログ大手のAtlanが自社を「AIのためのコンテキストレイヤー」と再定義し、Snowflakeも同様の機能を発表するなど、主要プレイヤーが一斉に参入しています。

コンテキストレイヤーが扱う情報は、大きく「データの意味」「データ同士の関係」「運用と判断の文脈」の3つに整理できます。

データの意味は、売上や解約率といった指標の定義や業務用語の説明など、「このデータは何を表しているのか」に答える情報です。

データ同士の関係は、顧客は契約を持ち、契約は商品にひもづき、商品は障害情報につながるという、モノとモノのつながりの情報です。
「この顧客の解約に影響しそうな要因は何か」のように、関係をたどって考える際に必要になります。

運用と判断の文脈は、複数あるテーブルのうちどれを正として信頼するか、誰がどのデータに触れてよいか、過去の似た場面でどう判断したか、という情報です。

人間の担当者が経験で補っている知識を機械が読める形に書き起こしたもの、と考えると実態に近いかと思います。
よく似た言葉であるセマンティックレイヤーは、このうち「データの意味」を担う指標の辞書であり、コンテキストレイヤーはその辞書を含んだより広い概念として語られています。

ただし、この用語はまだ固まっていません。
同じものを指してコンテキストグラフ、コンテキストエンジン、オントロジーと呼ぶ会社もあり、a16z自身が「呼び名は乱立しているが指しているものは同じで、解決策はまだ初期段階」と書いている通り、各社が同じ問題に別々の名前を付けて競っている段階です。


中身を分解する:指標の定義、関係の記述、暗黙知の形式知化

このコンテキストレイヤーですが、中身を分解してみると見覚えのある概念ばかりが出てきます。先ほどの3つの整理に沿って並べてみます。

「データの意味」を担うのがセマンティックレイヤーです。
売上をどのテーブルのどの列からどの条件で集計するかを1か所に定める、言葉と物理データの対応表です。
起源は1991年にフランスのBusiness Objects社が、データベースの列名を業務用語に翻訳する仕組みとして特許を出願したところまで遡り、BIの世界で30年以上使われてきた考え方です。

「データ同士の関係」を担うのがオントロジーとナレッジグラフです。
オントロジーは顧客・契約・商品といった概念とその関係を定めた設計図であり、ナレッジグラフはその設計図に実データを流し込んだものです。
セマンティックレイヤーが個々の言葉の意味を定める辞書だとすれば、オントロジーは言葉同士のつながりを描いた地図にあたります。
2001年にセマンティックWebという構想で脚光を浴び、GoogleがKnowledge Graphとして検索に取り入れたのが2012年です。

「運用と判断の文脈」は、複数の分野に分かれて発展してきました。
システム横断の顧客IDの名寄せはマスターデータ管理、データの来歴の記録はリネージ、誰に何を見せてよいかの管理はデータガバナンスとして、それぞれ製品分野になっています。
そしてベテランの頭の中にある判断のコツを書き起こす取り組みには、1990年代にナレッジマネジメントとして一大ブームになった歴史があります。
「暗黙知を形式知に」という掛け声を覚えている方も多いのではないかと思います。

こうして並べると分かる通り、コンテキストレイヤーは新しい発明ではなく、30年かけて何度も提唱されては定着しなかった概念たちが、AIエージェントを動かすという1つの目的のもとに束ね直されたものです。
実質的に新しい部品は、AIとデータをつなぐ共通規格のMCP(2024年公開)くらいしかありません。


暗黙知の文書化がようやくペイするようになった

これらの概念が30年間定着しなかった理由は、採算の問題だったと考えています。

セマンティックWebはWebの情報すべてに意味の注釈を付けるという構想でしたが、注釈を書くのは人間であり、その手間に見合う見返りがありませんでした。
ナレッジマネジメントも同様で、ベテランの知見をせっかく文書にしても読むのは社内の数人であり、書いた本人が異動すれば更新は止まり、1年後には誰も開かないファイルだけが残ります。
隣の席で聞けば済むものをわざわざ書いて維持する理由がなく、オントロジーに至っては書ける専門家自体が希少でした。

しかしこの採算が、書く側と読む側の両方から変わり始めています。

書く側では、LLMが文書化のコストを引き受け始めました。
2024年にMicrosoftがGraphRAGを公開したあたりから、文書の山からナレッジグラフを自動構築する手法が実用になり、専門家が数か月かけていた作業がLLMで数日に縮んだという報告が研究と実務の両方から出ています。
たたき台をAIが書き、人間がレビューするという分業が成立しつつあります。

読む側の変化はさらに大きく、書かれた知識を読む相手が社内の数人から、24時間動き続けるエージェントに変わりました。
OpenAIは自社内のデータエージェントについて、業務知識や指標定義など6層の文脈を整備した結果、複雑な質問への回答が22分から1分22秒に縮んだと公表しています。
書いた文書が毎日何百回も参照され、そのたびに答えの質を支えるため、書く手間を回収できる構造が初めてできたことになります。

30年間「正しいが割に合わない仕事」だった暗黙知の文書化は、書く手間をAIが肩代わりし、読む相手もAIが連れてきたことで、ようやくペイする仕事になりました。


セマンティックレイヤーで足りるのは「問いに答える」まで

私自身、クライアントのデータ基盤を設計する際にはセマンティックレイヤーの作法に従って指標の定義をそろえ、テーブルの構造を文書に残してきました。
対話型のAIで「先月の解約率をセグメント別に見たい」という問いに答えるだけであれば、SQLを書くハードルはAIが取り払ってくれたため、指標の定義さえ正しければ正しい数字が返ります。

ところが、解約の兆候が出た顧客にフォローの連絡を入れる、在庫が閾値を割ったら発注をかける、といった実行までエージェントに任せようとすると、数字の定義に加えて、何が起きたら動くのか、どこまで自分で判断してよいのか、迷ったら誰に確認するのかという業務プロセスと判断基準の言語化が必要になります。

BIの画面であれば変な数字が出ても見ている人間が止められましたが、実行するエージェントにはその人間のチェックが存在しません。
そのため判断のルールごと渡しておく必要があります。

つまり、問いに答えるまでであればセマンティックレイヤーという辞書で足りますが、実行を任せるにはコンテキストレイヤーまで必要になる、という関係です。
業務プロセスの多くが文書化されていない以上、エージェント導入の成否はモデルやツールの選定よりも、この言語化がどこまでできているかで決まります。


データのモデリングから事業のモデリングへ

企業の側でまず変わるのは投資の優先順位で、どのAIツールを入れるかの比較検討よりも、自社の業務がどこまで言葉になっているかの棚卸しが先になります。
業務の大半が文書化されていないのであれば、AI導入の本体はツールの導入作業ではなく、自社の事業を書き起こす作業のほうにあるためです。
日本でもデジタル庁が、職員のノウハウをAIエージェントのスキルとして形式知化する取り組みを公表しており、この方向の動きは既に始まっています。

データ組織の仕事はこれまで、データを集めて指標の定義をそろえる、いわばデータのモデリングが中心でしたが、これからは、何が起きたら誰が動き、例外をどう扱い、なぜその判断を良しとするのかという業務の流れと判断基準、つまり事業そのものを記述する仕事が加わります。
書く対象がテーブルから事業に広がる分、データの技術よりも事業の理解が問われるようになります。

私はこの変化を、データ組織にとっての追い風だと考えています。
基盤を作る技術は今後も必要ですが、それだけであれば外部に頼むこともできます。
一方で、自社の事業を言葉にする仕事は、事業を知っている人間にしかできません。

問いは昔から変わっておらず、自分の事業を言葉で定義できるかという一点です。
セマンティックレイヤーもナレッジマネジメントも、この問いの別の呼び名でした。
違うのは、今回はその言葉を読んで動く相手がいることです。
コンテキストレイヤーという新しい言葉の下で問われているのは、この古くからの問いだと感じています。

株式会社deflag CDO

深川 泰雅

知見・コラム

  • 知見

AI業務自動化を事業部主導で進めるための分業設計|個人で動かせる「点」、開発が要る「線」

「商談の評価も、問い合わせの一次対応も、レポート作成も、AIで自動化したい。」 事業部でAI活用を任された推進担当者の方から、こうした相談をよく聞くようになりました。特徴的なのは、やりたいことのイメージがかなり明確に描けている、という点です。 たとえば「問い合わせフォームに届いた内容が自動で記録され...

2026/6/12

  • 知見

AI導入支援会社の選び方|工程に分解して「誰に何を頼むか」を見極める

「AIを業務に活かしたい」そう思って「AI導入支援」を提供している会社に何社か問い合わせてみたものの、各社の言うことがまるでバラバラで、かえって分からなくなった——こうした声をよく耳にします。ある会社は経営戦略やビジョンの話に終始し、ある会社は自社のツールを軸に提案を組み立て、また別の会社は「作るも...

2026/6/12

  • 知見

AI導入の有無が生む差|データと歴史で読む競争力格差

ChatGPTは触ったことがある。成功事例の記事も読んだ。市場が伸びていることも知っている。それでも、「では、入れないとどうなるのか」という問いに、自社の業務に引きつけて即答できる経営者の方は、意外と多くないように感じます。 多くの場合、危機感の出どころは「競合が使い始めたらしい」「取引先や投資家か...

2026/6/12

記事一覧へ

arrow_forward

お役立ち資料

営業部門のAIエージェント活用ガイド|営業現場が変わる10の業務

ダウンロード

お役立ち資料一覧を見る

Contact

まずはお気軽にご相談ください