ChatGPTが指標の定義を忘れる理由と、その解決策（2026年版）

指標名は指標そのものではない

「売上総利益（Gross margin）」という言葉は、6つの異なる意味を持ち得ます。AtScaleは、セマンティックドリフト（意味のズレ）のコストに関するレポートの中で、3つのチームが「前四半期の売上総利益はいくらだったか？」という質問に対し、それぞれ30%、32%、31%と回答した事例を紹介しています。これらは、何が売上原価に含まれるかという3つの異なる定義から導き出された、いずれも根拠のある数字です。

あなたのアシスタントAIは、この曖昧さをそのまま引き継ぎますが、あなたがそれをどう解決したかという情報は引き継ぎません。あなたが「チャーン（解約）」と言ったとき、モデルは一般的なチャーンの意味について強い事前知識を持っていますが、あなたの会社がアカウント数ではなく収益ベースで、年間ではなく月次で、さらにダウングレードを除外して測定しているという事実は知りません。定義がなければ、モデルは一般的な事前知識を使用します。これは狭い意味でのメモリ障害ではなく、「自信に満ちた回答」として現れるメモリ障害なのです。

定義はデータではなく、人の中に存在する

これが、指標の定義をスキーマよりも難しくしている要因です。テーブルには検査可能な構造があり、モデルはカラム名やデータ型を読み取ることができます。しかし、定義とは「意思決定」です。誰かがいつかの時点で「トライアルはカウントしない」と決定し、その決定はSlackのスレッド、ダッシュボードのSQL、あるいは誰かの頭の中に記録されています。

これに対する業界のコンセンサスは、驚くほど率直です。AtScaleは次のように述べています。「AIシステムは、矛盾する定義を調整できないだけではない。一貫性のない回答を自信たっぷりに提示することで、問題をさらに悪化させる。」 失敗の原因は、モデルが数学を捏造していることではありません。組織内に複数存在する定義のうち、モデルがたまたま再構築した定義を忠実に実行していることにあります。

これが、ChatGPTがデータスキーマを見失う問題とどのように異なるかに注目してください。スキーマの喪失は、存在しないカラムや結合の失敗など、気づきやすいエラーを引き起こします。一方で、定義の喪失は、何とも整合性の取れない数字を生み出し、それに気づくのは会議の席になります。

セッション間で定義を引き継ぐ仕組みがない

1つの会話で正しい定義を教え込めたとしても、それを次回以降に引き継ぐメカニズムは、この種の情報には存在しません。組み込みのメモリ機能は、あなたに関する短い事実を数ページ分保持する程度であり、除外条件を含む9つの条項からなる「適格パイプライン」の定義を保持できるような容量はありません。カスタム指示（Custom instructions）には2〜3個の定義を保存できますが、それだけで他の指示スペースを圧迫してしまいます。プロジェクトファイルは役立ちますが、そのプロジェクトとそのツール内だけに限定されます。

その結果、定義は手動で再提供されることになり、それは「大体の」内容になってしまいます。木曜日にあなたが入力するバージョンは、月曜日のものよりも短くなります。なぜなら、記憶を頼りにタイピングしており、除外条件などの細かい部分は面倒だからです。あなた自身の要約によって、定義のズレ（ドリフト）が入り込むのです。

定義は変更されるが、古いバージョンは撤回されない

さらに問題を複雑にするのは、第3四半期に定義を改定したとしても、それ以前のすべての分析は第2四半期のバージョンで計算されているという点です。チャットベースのワークフローには、ある定義が特定の日に別の定義に置き換わったことを記録する場所がありません。そのため、異なるルールで計算された数字が混在することになり、どちらが適用されたかを知る術もありません。これは分析における「日付のないドキュメント」と同じです。

すべてのチャットの冒頭に定義を貼り付ける。 効果的であり、最も一般的なアプローチである理由もここにあります。しかし、これも徐々に劣化します。貼り付けるテキストブロックは週を追うごとに短くなり、またチャットごとの対応となるため、チームの他のメンバーはそれぞれ独自のバージョンを貼り付けることになります。

カスタム指示（custom instructions）に定義を入れる。 毎日使用する2〜3個の指標については、より優れた方法であり、実際にやる価値があります。しかし、すぐに容量制限に達してしまい、アシスタントの振る舞いを制御するための指示スペースを定義だけで使い果たすことになります。

定義ドキュメントを添付したプロジェクト（Project）を使用する。 製品内オプションとしては最善の方法です。ただし、そのプロジェクト内に限定されるため、コーディングエージェントやBIツールでも作業する場合、そのドキュメントはそこからは参照できません。

アシスタントにSQLを読み取らせる。 賢く、部分的に効果的です。定義は確かにクエリの中に存在します。しかし、意図や例外が欠落します。SQLは WHERE status != 'internal' という句を示しますが、その句が監査結果によって存在していることは示しません。また、あるダッシュボードのバージョンを表示しても、それが議論の余地があるバージョンであることは教えてくれません。

セマンティックレイヤーを構築する。 これが真のプロフェッショナルな解決策であり、はっきりと述べるべきです。セマンティックレイヤー（dbtのSemantic Layer、AtScale、Cubeなど）は、まさに指標を一度定義すれば、すべてのツールが同じ方法で計算できるようにするために存在します。AtScaleはその目標を次のように説明しています。「誰かが『売上はいくらか？』と尋ねたとき、定義が一貫してどこにでも適用されるため、答えは1つになります。」 組織が共通の指標に基づいて運営されている場合、これは投資すべき対象であり、メモリレイヤーがその代わりになるわけではありません。

また、AtScaleの報告によると、データベースに直接クエリを実行するLLMは、ビジネスに関する質問に対して約20%の精度にとどまりますが、セマンティックレイヤーが統治された定義、多次元のビジネスロジック、および文脈上の関係性を提供すると、ほぼ100%の精度に達します。この数値は、その結論に利害関係を持つベンダーからのものであるため、独立したベンチマークとして扱うべきではありません。しかし、その方向性自体に異論はなく、統治された定義を支持する最も強力な論拠となっています。

セマンティックレイヤーが埋められないギャップは、あなたが実際に直面している状況です。午後6時にCSVを貼り付けるアシスタント、モデル化されたレイヤーを一切通らないアドホックな質問、決定事項としては存在するがまだ指標として実装されていない定義、およびBIへのアクセス権を持たない人が行うすべての分析です。定義が失われるのはまさにこうした場面であり、実際に発生する分析の大部分がこれに該当します。

定義をチャットの外部、つまりアシスタントがリクエストごとに読み込むストアに保持します。コピー＆ペーストするメモではなく、回答の一部として定義を提供するレイヤーです。

これが機能する理由は、単なるストレージだからではなく、定義がその文脈（コンテキスト）とともに届くからです。保存された定義には、除外条件、各除外の理由、誰が承認したか、最後に変更されたのはいつか、そして以前のバージョンは何だったかを含めることができます。これが、「アクティブ ＝ 90日以内に支払いあり」という単純な記述と、誰かが実際に責任を持てる定義との違いです。

MemoryLakeは、そのために構築されたメモリレイヤーです。定義、決定記録、ソースドキュメントを1つのストアにまとめ、ChatGPTはAPIを介して、ClaudeやCodexなどのMCP対応ツールは直接それを読み取ることができます。これにより、アドホックなチャット、クエリを書くコーディングエージェント、そして先週入社したばかりのアナリストに、まったく同じ定義が届くようになります。

誇大広告が実質的な被害をもたらす領域であるため、2つの境界線を明確にしておきます。

• メモリレイヤーは定義を利用可能にし、一貫性を持たせ、追跡可能にしますが、強制はしません。 強制（エンフォースメント）はセマンティックレイヤーの役割です。すべてのクエリを1つの定義で計算します。メモリレイヤーは、質問した人に定義を提供するだけです。モデルに生のテーブルが渡され、独自の計算が行われるのを防ぐことはできません。取締役会向けの資料や提出書類に記載する数字は、チャットから出力されたものではなく、統治されたレイヤーから取得すべきです。
• 定義にはメタデータが必要です。さもなければ、問題を別の場所に移動しただけにすぎません。 指標名と数式だけの2カラムのテーブルは、まさにドリフトを引き起こした原因そのものです。一緒に引き継がれるべきなのは、粒度、時間枠、除外条件とその理由、オーナー、および適用開始日です。

ステップ 1: APIキーを作成する

キーを生成し、約30秒で最初のリクエストを実行できます。共有される設定ファイルやノートブックにインラインで記述するのではなく、環境変数やシークレットマネージャーに保管してください。

ステップ 2: 最初のメモリをアップロードする

指標ドキュメント、ダッシュボードの仕様書、除外が決定されたSlackのスレッド、それを引き起こした監査メモなど、定義が実際に存在するドキュメント、画像、ファイルをドロップします。整理された要約ではなく、ソースそのものをアップロードしてください。整理された要約こそ、「社内アカウントの除外」が静かに消え去る場所だからです。

ステップ 3: AIとエージェントを接続する

Claude、Codex、OpenClaw、その他のAIエージェントに、MCPまたはAPIを介してメモリへのアクセス権を付与します。ChatGPTにはMCPクライアントがないため、APIを介して関連する定義を取得し、プロンプト、カスタムGPT、またはモデルを呼び出すワークフローに注入します。MCPに対応しているツールの場合は、そのツールの設定にサーバーを追加すれば、同じストアを読み取ることができます。これが重要なポイントです。1つの定義を、複数の消費者が利用するのです。

木曜日の数字が月曜日の数字と一致します。これが最大のポイントであり、誇張なしに述べる価値があります。同じ定義に基づいて計算された同じ質問は、同じ回答を生み出します。定義を再入力する必要がなかったからです。

2つ目の変化は、意見の相違が生産的になることです。現在、2つの数字が一致しない場合、それぞれが何を測定したかを再構築するのに1時間を費やすことになります。定義が除外条件や適用開始日とともに保存されていれば、計算方法を逆算する代わりに定義同士を比較できます。そして多くの場合、2つの数字はどちらも正しく、異なる質問に答えていたことに気づくのです。

3つ目はオンボーディングです。新しいアナリストの最初の1ヶ月は、主に「トライアルはカウントしない」というルールを学ぶことに費やされます。それがツールの読み込むストアにあれば、ダッシュボードから再構築する代わりに、組織の公式バージョンからスタートできます。

そして、改定内容が明確になります。適用開始日のある定義があれば、誰も質問してこないことを祈る代わりに、「この分析は8月以前の定義を使用しました」と言うことができます。数字がどのルールに基づいて計算されたかを知るというこの1つの特性こそが、分析の信頼性を担保する最大の要素です。

数式だけでなく、除外条件とその理由を記述する

「アクティブ ＝ 過去90日間に支払い済みの請求書あり」は、定義の半分にすぎません。ドリフトを防ぐもう半分の要素は、トライアルの除外（2025年の価格改定前に数値を膨張させていたため）、社内アカウントの除外（3月の監査結果による）、シートレベルではなくアカウントレベルでのカウントといった記述です。理由が重要なのは、誰かが毎四半期ごとに除外条件について再議論するのを防ぐためです。

すべての定義に日付を付け、古いものも保管する

定義が変更された場合は、適用開始日を記載した新しいバージョンを追加し、古いバージョンには「置き換え済み」とマークして保管します。古い定義を削除してしまうと、前四半期の数値を解釈できなくなります。これは、この実践全体の中で最も価値が高く、最も見落とされがちな習慣です。

オーナーを指名する

すべての定義には、誰がそれを決定したかを記載すべきです。官僚主義のためではなく、「これはまだ正しいか？」という質問の宛先が必要だからです。オーナーのいない定義は静かにドリフトしますが、オーナーのいる定義は修正されます。

統治されたレイヤーを信頼できる唯一の情報源（Source of Record）にする

定義がどこでも利用できるようにメモリレイヤーを使用し、報告される数値を実際に計算するものとしてはセマンティックレイヤーやウェアハウスモデルを維持します。両者が矛盾する場合、統治されたレイヤーが優先され、メモリのエントリが修正されます。この階層を逆にしてしまうと、「十分に文書化された間違った数字」を生み出すことになります。

ChatGPTが指標の定義を忘れるのは、定義がデータ自体の属性ではなく「意思決定」であり、チャットベースのワークフローにはセッション間で意思決定を引き継ぐ仕組みがないためです。代わりに得られるのは、その指標名が通常何を意味するかというモデルの事前知識であり、それが自信たっぷりに実行されます。そのため、この失敗は目に見えるエラーではなく、整合性の取れない数字として表面化するのです。

ツールが読み込むストアに定義を保持することで、可用性の問題が解決されます。定義、除外条件、オーナー、適用開始日が質問と同時に届きます。強制力を持たせるため、また報告されるすべてのものについてはセマンティックレイヤーを維持してください。この2つを組み合わせることで、月曜日に説明した「アクティブ顧客」のバージョンが木曜日にも引き続き使用され、任意の数字がどのバージョンを使用したかを証明できるようになります。