データの意味をAtlanで渡すか自前か｜AIの誤答を減らす選び方

「社内のAIに先月の受注額を聞いたら、経理の数字と合わない」「同じ質問をしたのに、営業部とマーケ部で違う答えが返ってきた」——AIエージェントを社内に配り始めた会社で、最初の1か月に必ずと言っていいほど出てくる声です。多くの場合、原因はAIのモデルの賢さではありません。「受注」とは何を指すか、どの表を正とするか、誰がその定義を持っているかという、データの意味がAIに渡っていないことが原因です。この記事では、その意味を渡す層を、データの目録と統制の製品である Atlan で持つか、自前の表計算や既存の仕組みで整えるかを比べ、決め方を整理します。

「誤答はモデルのせい」という思い込みを先にほどく

AIエージェントに社内の数字を答えさせると、答えそのものはもっともらしいのに、社内の正式な数字と合わないことがよく起きます。このとき多くの会社は、指示文を工夫するか、より新しいモデルに替えるかで対応しようとします。しかし、受注を契約日で数えるか納品日で数えるか、解約を含むかといった社内の決めごとは、どのモデルも知りようがありません。

AIはデータベースの表と列の名前を見て、それらしい計算をします。列の名前が「金額」で、表が二つあれば、どちらかを選んで足し算をします。選んだ表が営業の見込みの表で、経理が使う確定の表ではなかった、というのが典型的な誤答の中身です。誤答の多くは計算の誤りではなく、意味の取り違えです。

データの目録に書く項目や、紙1枚から目録を始める方法は別の記事で扱いました。ここではその先、意味をAIエージェントに渡す層を、製品で持つか自前で持つかという選択に絞ります。

Atlan は、データの目録と統制から「AIに渡す文脈の層」へ広げた製品

Atlan は米国とインドに拠点を置く、データの目録とデータの統制の製品です。社内のデータベースや分析の道具をつないで、どんな表があり、どこから来て、誰が持っているかを一か所にまとめ、その上で利用の権限や品質を管理します。2026年1月には、Gartner のデータと分析の統制の基盤に関する評価でリーダーに位置づけられたと公表しています。前年の初回の評価では「ビジョナリー」の区分だったとしています。

ここ1年ほど、Atlan は自社の説明の中心を、データの目録から「AIエージェントのための文脈の層」へと移してきました。文脈とは、表の説明、指標の定義、正しい結合の仕方、よく使う絞り込みの条件、用語の意味といった、データを正しく使うために人が頭の中に持っている知識のことです。それをAIが読める形にして、各種のAIに配るのが、いまの Atlan の売り方です。

買収や社名変更の報道は確認できず、2026年に入っても、1月の評価の公表、4月の発表会、6月の Snowflake の年次イベントでの発表と、更新が続いています。製品としての実在と鮮度は確かめられますが、料金は公開されておらず、問い合わせで見積もる形です。

2026年4月の発表会で何が出たか

Atlan は2026年4月29日、オンラインの年次の発表会「アクティベート2026」を開き、主に三つを発表しました。一つ目は、AIに渡す文脈を組み立て、試し、配る作業場であるコンテキスト・エンジニアリングの作業場です。公式の説明では、組み立て、模擬の質問による試験、配布、観察の四段で回すとしています。公式の手引きでは、この作業場は限定公開の段階と書かれています。

二つ目は、9種のコンテキスト・エージェントです。基礎、派生、複合の三つの層に分かれ、過去の問い合わせの履歴や利用のされ方を分析して、表の説明、指標の定義、好ましい結合と絞り込み、用語の体系の下書きを作るとしています。同社は、AIが作った文脈の89%が、人が書いたものと同等以上と評価されたと述べていますが、これは同社の顧客での評価として公表された数字で、第三者の検証ではありません。

三つ目は、エージェントの一回ごとのやりとりを記録するトレースです。公式の説明では、質問、取り出した文脈、生成した答えを記録し、エージェントがどこで間違えたかを示し、直しはモデルではなく文脈の側に戻されるとしています。作った文脈は、版を持った「文脈の保管庫」にまとめられ、出荷の前に人が確認して承認する流れだと説明されています。

誤答を生む「意味の欠け」は3つの型に分かれる

製品か自前かを比べる前に、何が欠けると誤答になるのかを整理します。社内の数字の誤答は、おおむね三つの型に分かれます。一つ目は指標の定義の欠けです。受注、商談化、解約、有効な見込み客といった言葉が、部署ごとに違う意味で使われていて、AIはどれを使えばよいか分かりません。

二つ目は、正とする表の欠けです。同じ顧客の一覧が、顧客管理の仕組み、MAの道具、データの倉庫に別々にあり、どれが正本かが書かれていません。三つ目は持ち主の欠けです。定義が古くなっても、誰が直すのかが決まっていないので、一度正しかった定義が、組織変更や商品の追加で静かに古びていくことになります。

• 「受注額」をAIに聞いたら、見込みの表と確定の表を足し合わせた数字が返ってきた
• 広告の成果の問い合わせに、媒体の管理画面の数字と分析の道具の数字を混ぜて答えた
• 解約率の定義が営業とカスタマーサクセスで違い、聞く人によって答えが変わった
• 去年廃止した商品区分の定義が残っていて、今年の売上の内訳が合わなかった

このうち、三つ目の持ち主の欠けは、どの製品を入れても解決しません。製品は定義を書く場所と配る仕組みを用意しますが、誰がその定義に責任を持つかは、会社が決めることです。比較の前に、この点を押さえておきます。

比べる前提：意味の層に要る5つの働き

製品と自前を公平に比べるために、意味の層に要る働きを五つに分けます。定義を書く、定義を承認する、AIに渡す、渡した結果を試す、誤答を追う、の五つです。自前の場合、書くと承認するは表計算と社内の手続きで代わりがききますが、渡す・試す・追うは仕組みが要ります。

五つの働きを簡単に言い換えておきます。書くは、指標や用語の定義を文章と計算式で残すこと。承認するは、その定義を正式なものとして持ち主が認めること。渡すは、AIエージェントが質問に答えるときに定義を読めるようにすること。試すは、典型的な質問を投げて正しく答えるかを確かめること。追うは、誤答が出たときに、どの定義や表が原因かをたどることです。

Atlan の発表に当てはめると、コンテキスト・エージェントが書くを、文脈の保管庫と承認の流れが承認するを、MCPの仕組みが渡すを、作業場の模擬の質問が試すを、トレースが追うを受け持つ形です。五つを一つの製品でつなげることが、Atlan を選ぶ最大の理由になる一方、五つのうち必要なのが二つか三つなら、自前で足りる可能性が高くなります。

Atlan と自前の比較表

五つの働きごとに、Atlan で持つ場合と自前で持つ場合を並べます。自前とは、表計算の定義表、社内の文書、既存のデータの倉庫や分析の道具の機能を組み合わせる形を指します。

働き	Atlan で持つ場合	自前で持つ場合
書く	既存の問い合わせや利用の履歴から、AIが定義の下書きを作る	担当者が表計算に書く。量が多いと止まる
承認する	版のある保管庫で、出荷前に人が確認する流れ	会議や回覧で承認し、版は手で管理する
渡す	MCPなどで複数のAIに同じ定義を配る	AIごとに指示文や設定へ貼り付ける
試す	模擬の質問をまとめて流し、通過率を見る（限定公開）	典型の質問を手で投げて確かめる
追う	質問・取り出した文脈・答えをトレースで記録	AI側の記録を手で突き合わせる
費用	見積もり。導入と運用の体制も要る	人の手間。量が増えると急に重くなる

この表から分かるのは、差が大きく開くのは、渡す先のAIが複数あるときと、誤答を追う必要が強いときだということです。AIが一つで、定義が数十個なら、自前の手間は小さく収まります。

Atlan を選ぶ理由が立つ会社

Atlan のような製品が見合うのは、まずデータの量と持ち主が多い会社です。データの倉庫に数百、数千の表があり、事業部ごとに分析の担当がいて、定義が部署ごとに分かれている状態では、表計算の定義表は数か月で追いつかなくなります。定義の下書きをAIに作らせ、人は承認に集中するという分担が意味を持つのは、この規模からです。

次に、渡す先のAIが複数ある会社です。Atlan は、Claude、Copilot、Cursor、Gemini、Slack などに、MCPの仕組みで同じ文脈を配れると説明しています。また、文脈の保管庫は一つの用途の意味の定義を、Snowflake や Databricks の分析用のAIにも、それぞれの形式で書き出せるとしています。部署ごとに別のAIを使っていても、定義を一か所で持てることは、自前では作りにくい利点です。同社は、2025年9月以降でMCPの利用の顧客数が17倍、月間の呼び出し回数が58倍に増えたと公表しており、複数のAIへ配る使い方に力を入れていることがうかがえます。

三つ目は、すでに Atlan をデータの目録として使っている会社です。目録の上に文脈の層を足す形になるので、表の所在や系譜をもう一度集める必要がありません。逆に、目録をまだ持たない会社が、AIの誤答対策だけのために導入すると、目録づくりの負担を同時に背負うことになります。

自前で足りる会社と、その始め方

自前で足りるのは、AIに答えさせたい数字の範囲が限られている会社です。たとえば、マーケ部門のAIに、商談化数、受注額、広告の成果の三つの領域だけを答えさせるなら、必要な定義は数十個に収まります。この規模なら、表計算の1枚に指標名・定義・計算式・正とする表・持ち主・最終確認日を並べるだけで、意味の層の役目は果たせます。

渡すのは、その定義表をAIの指示文や参照資料に入れる形です。試すのは、営業とマーケの担当者がよく聞く質問を20問ほど決めて、定義を変えるたびに投げ直すことで代わりがききます。最初から製品を入れず、自前で3か月回して、手が回らなくなった箇所を製品で補うという順番は、費用の面でも、何が本当に必要かを知る面でも合理的です。

自前の弱点は、量が増えたときに急に重くなることと、AIごとに定義を貼り付ける手間が増えることです。3か月後に手間を数えて、その二つが大きくなっていれば、製品を検討する時期だと判断できます。

自前の定義表で気をつけたいのは、定義と実際の表がずれていくことです。表の列の名前が変わったり、新しい商品区分が足されたりしても、表計算の定義表は自動では気づきません。データの仕組みに変更が入ったら定義表の担当に知らせる、という連絡の取り決めを、情シスと結んでおきます。Atlan の公式の手引きでは、文脈の保管庫が参照先の表の変更を検知して知らせ、作り直しを促すと説明されています。自前で同じことをするなら、この連絡が代わりになります。

第三の道：データの倉庫の側の機能で持つ

製品か自前かの二択に見えますが、実はもう一つ道があります。Snowflake や Databricks といったデータの倉庫の側にも、指標や結合の意味を定義して、その倉庫の分析用のAIに読ませる機能があります。社内のデータのほとんどが一つの倉庫に集まっていて、使うAIもその倉庫の分析用のAIが中心なら、倉庫の側の機能で意味を持つのがもっとも手数の少ない選び方です。

Atlan も、この倉庫の側の機能と競うのではなく、そこへ書き出す立場をとっています。公式の手引きでは、一つの文脈の保管庫から、Snowflake の分析用のAI、Databricks の Genie、変換の道具であるdbt、MCPを通じた Claude へ、それぞれの形式で配れるとしています。また、6月の Snowflake の年次イベントに合わせた同社の発表では、倉庫の側の意味の定義は人が手で作るため、作っても正しく答えるかを試しにくいことを課題に挙げていました。

倉庫の側で持つ道の弱点は、倉庫が二つ以上ある会社や、倉庫の外のAI、たとえば社員が日常で使う汎用のAIにも同じ定義を渡したい会社では、定義が倉庫ごとに分かれてしまうことです。倉庫が一つなら倉庫の機能、複数の倉庫と複数のAIにまたがるなら製品、その中間なら自前の定義表を正本にして各所へ写す、という三択で考えると整理しやすくなります。

AIが下書きした定義を、誰が承認するか

Atlan のコンテキスト・エージェントは、定義の下書きを大量に作れることを売りにしています。同社は、短期間の取り組みで50のチームが100万件を超えるAI生成の説明を作り、前年に全顧客が人の手で書いた説明は約2万5千件だったと述べています。数の差は大きいのですが、下書きが増えるほど、承認する人の負担が増えるという点は見落とせません。

承認の線は、定義の重さで分けます。売上、受注、解約といった経営の数字に使う定義は、事業の持ち主と経理の双方が承認します。広告の成果や見込み客の区分といったマーケの定義は、マーケの責任者が承認します。表の説明や列の意味のように、誤っても経営の数字に直結しない説明は、データの担当者が抜き取りで確かめる程度にとどめます。

AIに判断させてはいけないのは、二つの部署で定義が食い違ったときにどちらを正とするかです。コンテキスト・エージェントは食い違う定義を見つけて解消を手伝うと説明されていますが、どちらを正とするかは組織の決定であり、AIは候補と根拠を並べるまでにとどめます。承認した人と日付を定義ごとに残すことは、製品でも自前でも同じです。

大量の下書きを承認するときの現実的な進め方は、重さで並べて上から見ることです。経営の数字に使う定義は全件を人が読み、根拠として使われた問い合わせの履歴や元の表まで確かめます。中くらいの重さの定義は、一定の割合を抜き取って読み、誤りが見つかった割合が高ければ全件に広げます。下書きには、どの履歴や表を根拠にしたかを必ず付けさせるようにすると、承認する人は根拠を見て判断でき、AIの言い回しのもっともらしさに引きずられにくくなります。発表会では、専任のデータ管理の担当を置かずに下書きを確かめた利用企業の声も紹介されましたが、それは承認の負担が消えたという意味ではなく、承認に人の時間を集中できたという意味で読むべきでしょう。

MCPで外のAIに渡す範囲

Atlan はMCPの仕組みで、社外のAIサービスに文脈を渡せると説明しています。便利な一方で、何が外に出るかを先に決める必要があります。渡すのは定義や表の説明といった「意味」で、データそのものではないとしても、指標の定義や商品区分の体系は、それ自体が社外に出したくない情報であることがあります。

範囲は三段で決めると整理しやすくなります。全社に開いてよい一般的な用語と定義、特定の部署のAIにだけ渡す定義、外のAIには渡さない定義の三段です。たとえば未発表の商品の区分や、価格の決め方に関わる定義は、外のAIには渡しません。どのAIに、どの部署の定義を渡すかを、渡す先ごとの一覧にしておくと、後で確かめられます。

個人情報の扱いにも注意します。Atlan は、提携先の個人情報の分類の結果を列の単位で取り込み、その下流のエージェントが機微さの情報を引き継げるようにすると説明しています。ただ、どの列が個人情報に当たるかの最初の判断と、外のAIに渡してよいかの判断は、自社の情報管理の責任者が持ちます。自前の場合も、定義表に「外のAIに渡してよいか」の欄を一つ設けておきます。

• コンテキスト・エンジニアリングの作業場は、公式の手引きで限定公開と書かれている。全社で使う前に、提供範囲を契約時に確かめる
• 89%や2週間といった数字は、Atlan が自社の顧客での結果として公表したもので、第三者の検証ではない
• MCPで渡す先のAIの側で、受け取った文脈がどう保存され、学習に使われるかは、AIサービスごとの規約で確かめる

誤答の追い方：トレースと自前の記録

AIエージェントが誤答したとき、原因は大きく三つに分かれます。定義そのものが誤っている、定義は正しいがAIが別の定義を取り出した、定義も取り出しも正しいがAIの計算や言い方が誤っている、の三つです。どれが原因かで直す場所が違うので、追えないと、関係のない場所を直し続けることになります。

Atlan のトレースは、質問、取り出した文脈、答えを一組で記録すると説明されています。これがあれば、誤答のたびに、取り出した文脈が正しかったかを確かめられます。同社は、直しを文脈の側に戻すことで、モデルに手を入れずに、週ごとに答えが良くなるとしていますが、どの直しを採るかは人が決めることです。

もう一つ確かめたいのは、試す働きがどの機能に入っているかです。発表会の説明では、作業場が模擬の質問による試験まで担うとされていましたが、公式の手引きでは、作業場は意味の定義を組み立てて配るところまでで、エージェントの正答率の評価は別の機能で行うと書かれています。導入を検討するときは、試すと追うの働きが、契約する範囲にどう含まれるかを、機能名ではなく働きの単位で確かめるのが確実です。

原因ごとの直す場所を決めておくと、追った結果をすぐ直しにつなげられます。定義の誤りなら定義の持ち主が直し、取り出しの誤りなら定義の書き方や渡し方をデータの担当が直し、計算や言い方の誤りならAIの指示文や使い方の手引きを見直します。直したら、同じ質問を流し直して答えが変わったかを確かめ、変わらなければ原因の見立てを疑います。

自前の場合は、AIの側の記録と定義表を手で突き合わせます。誤答の報告を受ける窓口を一つにし、報告ごとに、質問、返ってきた答え、正しい答え、原因の型、直した場所を表に残します。月に数件なら、この形で十分に回ります。月に数十件を超えて手で追えなくなったら、トレースのような仕組みを検討する目安です。

費用の増え方と、やめ方

Atlan の料金は公開されておらず、問い合わせで見積もる形です。費用を見積もるときは、ライセンスの費用だけでなく、導入の体制、承認する人の時間、つなぐデータの仕組みの数を合わせて考えます。製品の費用が見合うかは、自前で同じことをしたときの人の手間と比べて判断します。

費用が増えやすいのは、つなぐ仕組みと渡す先のAIが増えたときと、文脈の量が増えて承認の手間が増えたときです。後者は製品の費用ではなく社内の人の時間として表に出るので、見落とされがちです。AIが下書きを作る速さに、承認する人の数が追いつくかを、導入前に見積もっておきます。

やめるときに備えて、定義や文脈を書き出せる形で持っておくことが大切です。Atlan は文脈の保管庫を、持ち運べる単位として説明し、利用者の声として製品に縛られたくないという意見も紹介しています。契約前に、定義・承認の履歴・トレースを、どの形式で書き出せるかを確かめます。自前の定義表を並行して残しておけば、製品をやめても意味の層は失われません。

マーケと情シスの持ち分

意味の層は、マーケと情シスのどちらか一方では持てません。情シスやデータの担当は、データの仕組みのつなぎ込み、権限、外のAIへの渡し方、トレースの保管を持ちます。マーケは、商談化や受注、広告の成果といったマーケの指標の定義と、その承認を持ちます。定義の中身を情シスに任せると、仕組みとしては正しくても、現場の言葉とずれた定義になります。

よく起きるのは、製品を情シスが選び、マーケは使う側として後から呼ばれる流れです。この流れだと、マーケの指標の定義は誰も承認しないまま、AIが作った下書きが正式なものとして使われ始めます。製品を選ぶ段から、マーケの定義の持ち主を一人決めて参加させることが、誤答を減らす近道です。

持ち分を決めるときは、コンテキスト・エージェントのような自動の下書きを、誰の名前で動かすかも決めておきます。下書きを作るには、問い合わせの履歴や利用のされ方を読む権限が要るからです。下書きのために広い読み取り権限を与えるなら、その権限の範囲と期間を情シスが決め、記録に残すようにします。下書きの材料に、本来は見られない部署の問い合わせの履歴が混ざると、定義の文面から他部署の事情が読み取れてしまうことがあるからです。

週次や月次の運用では、誤答の報告をマーケの担当が受け、原因が定義ならマーケが直し、取り出しや権限の問題なら情シスに回す、という流れを決めておきます。どちらが直すかの線が曖昧だと、誤答が報告されても誰も直さないまま残ります。

決める前のチェックリスト

最後に、製品を入れるか自前で始めるかを決める前に確かめる項目を並べます。半分以上に「はい」が付くなら製品の検討を、少なければ自前で3か月回すことを勧めます。

• AIに答えさせたい数字の領域が五つ以上あり、定義が百を超えそうだ
• 部署ごとに別のAIを使っており、同じ定義を複数のAIに渡す必要がある
• データの倉庫や分析の道具が複数あり、正とする表を決めるのに毎回議論になる
• 誤答の報告が月に数十件あり、手で原因を追いきれていない
• すでにデータの目録を製品で持っている、または持つ計画がある
• 定義を承認する持ち主を、マーケと事業部と経理でそれぞれ決められる
• 外のAIに渡してよい定義と渡さない定義を分ける責任者がいる

最後の二つは、製品でも自前でも必要な前提です。ここに「いいえ」が付くなら、どちらを選ぶ前にも、持ち主と渡す範囲を決めることが先になります。用語を補っておくと、ここでいう文脈とはデータを正しく使うための知識、トレースとはAIの一回ごとのやりとりの記録、MCPとはAIが外の道具やデータに接続するための共通の取り決めのことです。

まとめ

社内のAIエージェントの誤答は、モデルを替えても直りません。多くは、指標の定義・正とする表・持ち主という意味が渡っていないことから起きます。Atlan は2026年4月に、その意味を下書きし、承認し、複数のAIに配り、試し、誤答を追う層を発表しました。渡す先のAIが複数あり、定義が多く、誤答を追う必要が強い会社ほど製品の価値が大きく、範囲が限られるなら自前で十分です。どちらを選んでも、AIが下書きした定義を承認するのは人、食い違いを決めるのは組織、外に渡す範囲を決めるのは情報管理の責任者です。まず答えさせる範囲を絞り、定義の持ち主を決めるところから始めてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。