社内で使っている指標の定義のばらつきを洗い出して、指標辞書にまとめる

処理の起点を決める

毎週の決まった時刻を起点にします。n8n の Schedule Trigger は、Unix の cron に相当する動きをするノードで、秒・分・時・日・週・月の間隔、またはcron式でワークフローを実行できます。

週12〜13本ずつ処理します。600本を一度に処理しないでください。 指摘が一度に数百件出ると、誰も読みません。この取り組みが失敗する典型が、初回に全件を流して大量の指摘を出し、そこで止まることです。

もう1つの起点として、新しいレポートが作られたときを置きます。BIツールに新しいダッシュボードが登録されたら、その週のうちに定義を抽出して辞書と突き合わせます。これが入ると、増える速さに追いつけるようになります。 実は、既存600本を一巡することより、こちらのほうが効果が持続します。

入力データを集める

データの取得方法を決める

BIのメタデータ： 多くのBIツールはダッシュボードの定義をAPIまたはファイルでエクスポートできます。計算式の設定がどこまで取れるかは製品によって違うため、先に確認してください。 取れない製品では、画面のキャプチャから読むことになり、精度が大きく落ちます。

集計クエリ： データウェアハウスのビュー定義を取得します。SQLが読めれば、分子・分母・期間・除外条件はかなり正確に取れます。この構成でもっとも精度の高い情報源です。 ただし、ビューが多段に重なっている場合、最終的な定義を読むには展開が必要になります。

報告資料と表計算： 注記から定義が取れることがありますが、多くは書かれていません。 表計算は数式を読みますが、セル参照が別シートに散っていると追えません。「定義不明」として記録する割合が高くなる情報源です。 それ自体が結果です。

指標辞書（既存）： Excelの辞書があるなら、そのまま索引へ取り込みます。別名の列を必ず作ってください。 「解約率」の別名に「チャーンレート」「Churn Rate」を登録しておくと、引き当ての精度が上がります。

全社共通の用語集： 指標の定義は、基本用語の上に立っています。「契約数」の定義が決まっていないのに「解約率」の定義だけ決めても意味がありません。用語集がなければ、10語程度の基本用語から作ってください。

AIへ渡す前に整形する

1. 対象の絞り込み … 使われていないダッシュボード（直近90日でアクセスがないもの）、個人が試作したもの、廃止済みの資料を除きます。600本のうち、実際に使われているのは半分以下ということがあります
2. テキストの抽出 … BIのメタデータはJSON、クエリはSQL、資料はテキストと、形式がばらばらです。共通の形（レポートID／指標の表示名／定義に関わるテキスト／出所）に正規化します
3. SQLの展開 … ビューが多段の場合、最終的な集計に効いている条件を追えるところまで展開します。深い階層は追わず、「3段まで」のように上限を決めてください
4. 指標候補の抽出 … 1本のレポートに複数の指標が載っています。表示名と計算式の組み合わせで、指標の単位に分解します
5. 明らかな重複の除去 … 同じダッシュボードの複数のページに同じ指標が出ている場合、1つにまとめます

AIに処理させる

2つの工程に分けます。

定義要素を抜き出す工程：

辞書と突き合わせる工程：

「どちらが正しいか」は判定させません。 出せるのは「違いがある」「この違いは数値に影響する」までです。正とする定義を決めるのは、その指標を使う部門と経営企画です。

指示内容を固定する

定義要素を抜き出す側の指示は次のようになります。

あなたはデータマネジメントを支援する担当者です。
下のレポートから、使われている指標とその定義要素を抜き出してください。

【厳守事項】
- 下のレポートに書かれている内容だけを根拠にしてください。
  一般的な定義（「解約率は通常、月初契約数で割る」など）で補わないでください。
  **知識から補った時点で、この作業の意味がなくなります。**
- 読み取れない要素は null にし、undetermined にその要素名を入れてください。
  推測で埋めないでください。
- 1つのレポートに複数の指標がある場合、指標ごとに分けて返してください。
- 計算式がある場合、その式をそのまま source_expression に写してください。
  書き換えたり整形したりしないでください。
- 「売上」「件数」のような、それだけでは指標と呼べない項目は除いてください。
  分子と分母、または明確な集計条件があるものだけを指標として扱ってください。
- 指標の良し悪し、定義の妥当性について書かないでください。

【レポート】
{report_content}

【出所の種類】
{source_type}

突き合わせる側の指示は次のようになります。

下の指標の定義が、辞書に登録済みの指標と一致するかを判定してください。

【厳守事項】
- 判定は、下の「辞書の検索結果」に書かれている内容のみを根拠にしてください。
  検索結果に該当がない場合は status を "new" にしてください。
  **知識で補って「一般的にはこう定義される」と書かないでください。**
- status は次から選んでください。
  match ... すべての定義要素が一致する
  variant ... 同じ指標を指しているが、定義要素の一部が違う
  new ... 辞書に該当する指標がない
  unknown ... 抽出した定義に欠けがあり、判定できない
- variant の場合、違っている要素を differences に列挙してください。
  「分母：辞書＝月初契約数 / 本レポート＝月末契約数」の形で書いてください。
- impact は次から選んでください。
  high ... 数値が大きく変わる（分子・分母・除外条件の違い）
  medium ... 条件によって変わる（期間・対象範囲の違い）
  low ... 表記の違いのみ（名称・単位の書き方）
- どちらの定義が正しいかを書かないでください。
  統一の方針も提案しないでください。判断は経営企画が行います。

【抽出した指標の定義】
{extracted_metric}

【辞書の検索結果】
{retrieved_definitions}

「知識から補わない」の一文を、両方の工程に入れてください。 これがないと、AIは自社のレポートに書かれていない一般的な定義を埋めてしまいます。指標辞書を作る作業で、社外の一般論を書き込んだら、作る意味そのものがなくなります。

「どちらが正しいかを書かない」も必要です。 AIが「月初契約数で割るのが一般的です」と書けば、その意見が調整の場に持ち込まれます。定義の統一は、その指標を何に使うかで決まるものです。

出力形式を固定する

{
  "report_id": "",
  "report_name": "",
  "source_type": "bi | sql | document | spreadsheet",
  "owner_department": "",
  "last_modified": "",
  "metrics": [
    {
      "display_name": "",
      "numerator": "",
      "denominator": "",
      "period": "",
      "scope": "",
      "exclusions": [],
      "unit": "",
      "source_tables": [],
      "source_expression": "",
      "undetermined": [],
      "dictionary_match": {
        "status": "match | variant | new | unknown",
        "matched_metric_id": "",
        "differences": [],
        "impact": "high | medium | low",
        "evidence": ""
      }
    }
  ],
  "undetermined_count": 0
}

JSON Schema を指定して出力を固定します。Claude API では output_config.format に json_schema を渡すことで、応答をスキーマに沿った形に制約できます。

source_expression に元の式をそのまま写させる設計が重要です。 AIが整形した式では、後から人が検証できません。元の式が残っていれば、AIの抽出が誤っていても気づけます。

undetermined と undetermined_count は、この構成では「結果」の一部です。 定義が読み取れないレポートが多いということは、そのレポートが信用できないということです。指標辞書を作る前に、その事実が分かることに価値があります。

システムへ連携する

点検リストをスプレッドシートに作ります。2層にします。

レポート単位（週12〜13行）：

指標単位：

レポートから展開して見る形にします。抽出された定義要素、辞書との突合結果、違っている要素、元の式が並びます。

辞書への登録は、人が確定してから行います。 抽出結果をそのまま辞書へ流し込むと、誤った定義が正本として残ります。辞書は一度誤ると、それを根拠に新しいレポートが作られるため、修正の影響が広がります。

食い違いが high のものは、調整の議題として別のリストへ回します。 ここが、この取り組みでもっとも詰まる部分です。調整の場がないなら、リストに積み上がるだけになります。 月1回、経営企画が関係部門を集めて数件ずつ決める場を先に作ってください。

人が確認する

全件、経営企画が確認します。辞書への自動登録はしません。

理由は3つあります。1つは、定義の抽出が誤っていても辞書に入れば正本になるためです。2つ目は、どの定義を正とするかが業務の判断だからです。3つ目は、「所管部門はどこか」を決める必要があるためで、これは機械では決まりません。

確認を速くするための設計が効きます。

• impact が high の食い違いを最上部に並べる
• undetermined が多いレポートを別に集める（定義が書かれていないレポートの一覧そのものが成果）
• 元の式と、辞書に登録済みの定義を左右に並べて表示する
• 同じ指標名で variant が3件以上あるものを抽出する（もっとも混乱している指標）
• 最終更新日が2年以上前のレポートに印を付ける（廃止の候補）

4つ目が、着手する順番を決めてくれます。 600本を順番に見るより、「解約率」のように定義が3通り以上ある指標から手を付けるほうが、効果がはっきり出ます。

例外に対処する

記録を残す

この記録は、数字の根拠をたどるための資産になります。

• 抽出した定義要素と、元の式（原文）
• 辞書との突合結果と、その根拠
• 人が確定した定義と、確定した日・確定者
• 食い違いの調整の経緯（どちらに統一したか、その理由）
• undetermined の推移（減っているかどうかが、この取り組みの進捗そのもの）
• 辞書の変更履歴（いつ、誰が、どの定義をどう変えたか）

「調整の経緯」を残すことが特に重要です。 「解約率は月初契約数で割ることにした。理由は、経営会議で使う指標として、期中の増減の影響を受けにくくするため」という記録がなければ、1年後にまた同じ議論が起きます。

辞書の変更履歴は必須です。 定義が変わると、過去の数字と比較できなくなります。いつ定義が変わったかが分からない指標は、時系列で見られません。