「売上 15% 減」の背景にある、
「数字の読み方」をエージェントへ。
セマンティックレイヤーに接続した AI エージェントは、定義に従って集計し、「売上が落ちた」ことまでは把握できます。しかし、その落ち込みが季節要因なのか平常の揺らぎなのかといった「数字の読み方」は、スキーマのどこにも書かれていません。ochakai は、現場の解釈ノウハウや検証済みクエリを蓄積し、MCP・REST・CLI 経由ですべてのデータエージェントへ届けるコンテキストレイヤーです。
$ ochakai search "なぜ売上が落ちている?" metrics/revenue stable 売上 insights/why-revenue-falls stable 売上が落ちるときの要因 insights/reading-revenue stable 売上の読み方 $ ochakai get insights/why-revenue-falls 売上 = 受注点数 × 完了率 × 明細単価 この店の月次売上は、何も起きていなくても 前月比で 1 割前後揺れる。 linked from: metrics/revenue (Metric, unverified)
同じ質問でも、ナレッジがあると答えが変わる
データ分析エージェントに ochakai をつなぐと、答えはどう変わるのか。問いを選ぶと、同じ質問への 2 つの答えと、答えを変えたナレッジの一文が並びます。下の答えは、実際の検証で Claude が返した回答からの抜粋です。
「2026 年 8 月の売上はいくらでしたか?」
データだけ ✗ 誤り
2026年8月の売上は、全注文ベースで約$477,912、キャンセル・返品を除いた純売上ベースで約$358,975でした。
+ ochakai のナレッジ ✓ 正しい
結果: 売上 $127,148.82(完了明細ベース、注文数 1,476 件、通貨 USD・税抜相当)
答えを変えた一文
売上は配達完了ベースである。数えるのは
status = 'Complete'の明細だけである。
経理の wiki にある売上の計上ルールを、1 枚に写したものです。どの注文を売上に数えるかは、テーブルを眺めても分かりません。
「2026 年 8 月の返品率はいくつでしたか?」
データだけ ✗ 誤り
2026年8月の返品率は明細ベースで約10.5%、注文ベースで約10.4%とほぼ同水準でした。
+ ochakai のナレッジ ✓ 正しい
2026年8月の返品率は約28.8%(返品856件/分母2,973件)でした。
商品単位の見直しアクションの閾値(45%以上)は超えていないため、追加対応は不要です。
答えを変えた一文
分母は「返品の機会が閉じた明細」、つまり届いたか、届いて返ってきたかのいずれかであり、全明細ではない。
返品率の分母に何を入れるかを決めた定義です。エージェントが書いた定義を、担当者が確認して正式なナレッジにしました。
「2025 年 9 月に売上が前月から落ちた理由は何ですか?」
データだけ ✗ 2 回中 1 回は誤り
加えて返品率の上昇(10.1%→11.5%)とOrganic/Email経由売上の落ち込みが確定売上ベースの減少をやや押し下げた。
+ ochakai のナレッジ ✓ 正しい
2025 年 9 月の売上減(前月比 −10.1%)は、(中略)この店の通常の月次変動の範囲内であり、統計的に「落ちた」と言える大きさではありません。
答えを変えた一文
この店の月次売上は、何も起きていなくても前月比で 1 割前後揺れる。
過去 43 か月の売上を分解して、ふだんの増減の幅を書き残したものです。1 割の減少に、慌てて原因を探さずに済みます。
「2026 年 3 月は売上が前月から大きく伸びました。何が良かったのですか?」
データだけ ✗ 誤り
3月の売上増(+20.1%)は、(中略)新規顧客獲得の加速(注文+20.3%、売上+27.5%)を主因とした全面的な需要増によるもの。
+ ochakai のナレッジ ✓ 正しい
大半は2月が一時的に沈んでいた反動です。
答えを変えた一文
揺れを超えて落ちた月は、どれも 2 月だった。
ふだんの増減の幅を超えて落ちた月を、過去の売上から調べた結果です。伸びた月を調べるときは、前の月が低すぎなかったかを先に確かめられます。
回答の全文と採点結果を examples/demo-eval/results に置いています。正答数と検証の条件は下の節に、同じ問いをご自身のエージェントで試す方法は「公開デモを試す」にあります。
公開デモを試す
アカウント登録は不要です。デモ環境には、Google の公開データセット thelook_ecommerce に関する 37 件のナレッジが用意されています。「売上が落ちた。なぜか、次に何をすべきか」という問いに最後まで答えられるよう設計されています(最新リリース: v0.31.1)。
go install github.com/na0fu3y/ochakai/cmd/ochakai@latest ochakai use https://demo.ochak.ai ochakai search "なぜ売上が落ちている?" # 問いに関連するナレッジを検索 ochakai get insights/why-revenue-falls # 本文と、ここを指すドキュメントを取得
Web UI をブラウザで確認できます。次のコマンドを実行して http://127.0.0.1:8098 を開くと、レビュー画面が表示されます。
ochakai ui --url https://demo.ochak.ai
Go なしで使う(ビルド済みバイナリ)
# 以下は Apple Silicon Mac の例です。Intel Mac は darwin_amd64、Linux は linux_amd64 / linux_arm64、 # Windows は windows_amd64.zip をご利用ください(すべて同じリリースページにあります) curl -LO https://github.com/na0fu3y/ochakai/releases/download/v0.31.1/ochakai_0.31.1_darwin_arm64.tar.gz tar xzf ochakai_0.31.1_darwin_arm64.tar.gz sudo mv ochakai /usr/local/bin/ ochakai use https://demo.ochak.ai ochakai search "なぜ売上が落ちている?"
配布アーカイブにはデモ用ナレッジバンドル examples/demo も同梱されており、ご自身の環境の初期データとしても利用できます。
claude.ai で使う(インストール不要)
1. claude.ai の設定 → コネクタ → 「カスタムコネクタを追加」で、URL に https://demo.ochak.ai/mcp を入力します。OAuth の欄は空のままで構いません。
2. チャットで「ochakai を見て、2024 年 5 月に売上が落ちた理由を調べて」と指示すると、Claude がデモのナレッジを検索・参照して回答します。
デモは誰でも書き込めるサンドボックスです。書いた内容は匿名で記録され、定期的な初期化で消えます。Team / Enterprise プランでは、組織の管理者がカスタムコネクタを追加します。
Claude Desktop で使う(ワンクリック MCP 設定)
1. リリースページから ochakai_0.31.1.mcpb をダウンロードします。
2. ダウンロードしたファイルを開くと、Claude Desktop が自動的に設定画面を開きます。公開デモのサーバー URL が既定で入力されているため、そのまま確定するだけで接続完了です(macOS / Windows 対応)。
claude.ai やモバイルアプリから利用する場合は、Google Workspace の認証経由でアクセスできる Claude コネクタも用意されています。どちらを選ぶべきかは「エージェント接続ガイド」をご覧ください。
同じ問いに、BigQuery だけなら 9/18。ナレッジを足すと 18/18
9 つの問いを 2 回ずつ Claude Code(Sonnet 5)に入力して検証しました。両者ともに同一のプロンプトと同一の BigQuery 環境を与え、唯一の違いは片方のみが ochakai の MCP 経由でデモのナレッジ 37 件を参照できる点です。採点は別の Claude セッションが評価基準に沿って行い、数値の正解は BigQuery の直接クエリ結果に基づいて判定しています(2026-09-27)。
| 問い | BigQuery だけ | + デモの ナレッジ |
|---|---|---|
| 2026 年 8 月の売上はいくらか | 0/2 | 2/2 |
| 2026 年 8 月の返品率はいくつか | 0/2 | 2/2 |
| 今月の売上は先月より伸びているか | 1/2 | 2/2 |
| 揺れの範囲の売上減の理由 | 1/2 | 2/2 |
| 外れ月の翌月に売上が伸びた理由 | 0/2 | 2/2 |
| 先週と今日で過去の月の売上が違うのはなぜか | 1/2 | 2/2 |
| どのカテゴリが一番値引きされたか | 2/2 | 2/2 |
| 何年も前の明細が配送中のままなのはなぜか | 2/2 | 2/2 |
| 入荷から売れるまで平均何日か | 2/2 | 2/2 |
| 計 | 9/18 | 18/18 |
不正解となった回答は、いずれもデータウェアハウスへのクエリ自体は成立しているにもかかわらず誤っています。ステータスを考慮せず全レコードを売上に合算したり(実際値の 3.8 倍)、返品率の分母を全明細にしたり(正解の 28.8% に対し 10.5%)しました。また、平常の揺れの範囲内の減少に対して「キャンセルの増加」という誤った原因を推測した例もありました。スキーマには、どれが正しいかを決める材料がありません。37 件のうちわずか数件のナレッジが、エージェントの判断を正しい結果へ導きました。なお、データ構造を見るだけで自明な問いについては、両者ともに正しく回答できています。
一方で、コスト面のトレードオフもあります。ナレッジを参照する構成では、1 問あたりのツール呼び出し回数が約 2 倍(5.5 ターンから 11.4 ターン)、API 費用も約 2 倍($0.20 から $0.42)となりました。問いの選定はナレッジ作成者によるもので、検証回数は各 2 回、評価モデルも単一(Claude による自己採点)です。したがって、本検証は「事前に整備された少数のナレッジが、該当する種類の問いに対して回答精度を改善した」という限定的な示唆にとどまります。詳細な回答履歴や採点理由、再現手順は examples/README.md に掲載しています。
定義も「数字の読み方」も、ひとつの検索で
メトリクスの計算式だけでは、AI エージェントは正しいデータ分析にたどり着けません。真に必要なのは、「その数字をどう解釈すべきか(平常値・季節性)」「信頼できる検証済みクエリ」「指標の算出ルール」「社内用語の定義」、そして「テーブルの落とし穴やデータ品質の注意点」です。ochakai は、これらをまとめて検索インデックスに保持し、関連する文脈を一度にエージェントへ提供します。PDF や画像などのドキュメントも検索対象です。
Metric指標の定義と、社内での呼称や用途
Attested Computation検証済みの計算クエリ(ゴールデンクエリ)と検証手順
Skillクエリやデータ処理を実行するための具体的な手順
Insight指標の読み方・解釈ノウハウ(ベースライン、季節性、閾値、注意点)
Policy指標算出の前提となるルール(収益認識、コスト配賦など)
Glossary Term社内用語の定義(その言葉が組織内で何を意味するか)
BigQuery Datasetテーブル群をまとめるデータセットのカタログ項目
BigQuery Tableテーブルの出どころ、カラム注記、既知の注意点や落とし穴
Reference外部仕様書の写し(コード値・Enum 定義、ライセンス、スキーマ定義)
標準の推奨タイプは以上ですが、業務ドメインに合わせて自由にタイプを拡張できます。フォーマットの詳細は OKF v0.2 仕様、具体的な記述例はデモバンドルをご覧ください。
エージェントが学び、人間が検証する自律サイクル
データエージェントは分析業務の過程で、新たな発見やドメイン知識を獲得します。ochakai はエージェントが得た知見を「Draft(下書き)」として自動的に書き戻させ、人間のレビューキューへ届けます。人間が承認することで正式なナレッジへ昇格し、組織全体の AI エージェントに共有されます。Claude Code 向けには、ナレッジの想起と書き戻しを自動化するフックが同梱されています。
公開デモには、エージェントが書き戻した売上診断 2 件を、draft のまま収録しています。具体的には、2024 年 5 月の売上減少(−13%)を平常の揺れの範囲と判断し、過剰な施策を提案しなかったケースがあります。また、受注数は 17% 伸びたものの売上が伸び悩んだ 2026 年 3 月の分析ケースも含まれます。いずれも BigQuery のジョブ ID を根拠として記録し、人間の検証を待っています。
大がかりな専任体制なしで始める、実用的なオントロジー
データと業務知識を結びつけ、エージェントが自律判断できるようにする。それがオントロジーの本来の価値です。ochakai は、専用のスキーマ言語も、専任のオントロジーエンジニアも必要としません。ドキュメントは本文の Markdown リンクで互いにつながり、そのつながり自体が自然な構造になります。
デモでは、テーブルのドキュメントがオブジェクトの役割を担い、結合関係は各テーブルの # Joins 節のリンクや、特殊な結合ルールに関する Insight で保持されています。売上は受注点数・完了率・明細単価の 3 つの Metric に分解され、変動要因の特定ロジック、取るべき行動、データの適用限界まで、それぞれリンクをたどって把握できます。Palantir Foundry の用語との対応表は glossary/ontology にあります。
他のツールとの併用と競合
指標の定義を AI エージェントに提供するだけなら、セマンティックレイヤーやデータカタログでも可能です。ochakai は、それらのツールではカバーしきれない「数字の読み方や現場の解釈ノウハウ」を補うナレッジレイヤーとして併用できます。モデル定義はセマンティックレイヤーへ、技術メタデータはカタログへ、人間が検証したデータ知識は ochakai へ置きます。一方、付属のデータエージェント機能(オプション、既定は off)は、Databricks Genie などのデータエージェント製品と直接競合します。商用製品のような多機能さはありませんが、ochakai は回答根拠となったナレッジと人間による検証の有無を明示し、全データを OKF 形式で自由にポータブルに持ち出せます。
| 観点 | ochakai | Google Cloud Knowledge Catalog旧 Dataplex | セマンティックレイヤーdbt, DWH ネイティブの semantic model | データエージェント製品Databricks Genie, Snowflake Cortex Agents, BigQuery Conversational Analytics, Hex Threads | データカタログOpenMetadata, DataHub, Atlan | OKF ネイティブローカルツールokf-skills, kaut, llm-wiki-compiler 等 |
|---|---|---|---|---|---|---|
| 「読み方」のナレッジ | 専用の型(Insight)を提供。ベースライン・季節性・注意点を保持し、定義と同時に検索されるほか、定義を参照した際にも自動で関連付けられます。 |
保持可能。生成された説明やサンプルクエリを含むが、同一テーブルに複数視点の読み方を並べる用途には不向き。 | 持たない。定義や計算式は返るが、その数字をどう解釈すべきかは含まれない。 | 持つ。Genie と Cortex はクエリやダッシュボードから自動で集めて順位を付け、Conversational Analytics は開発者が説明や example query を書く。 | 持たない。テーブル定義・リネージ・オーナー情報が中心。 | 保持可能。OKF 形式のため自由に記述可能。 |
| 人間による検証と来歴 | インスタンス上で監査台帳を保持。誰が作成し誰がいつ検証したかの来歴が全ドキュメントに記録され、レビューキューや却下理由も保存される。 | ドキュメント記載の verified をそのまま表示。カタログ自体は検証フローを管理しない。 |
あり。通常のコードレビュー・プルリクエストを通る。 | Hex は承認(endorse)済みアセットに限定した回答が可能。Genie や Cortex は、機械学習モデルのランキングに基づいて採用する解釈を決定。 | あり。スチュワードシップや認定機能(ツールにより異なる)。 | ファイル記載情報と Git 履歴に依存。却下理由の蓄積やレビューキューは持たないものが多い。 |
| 運用の手間 | 一次情報の下書きはエージェントが自律的に収集。人間は重要な判断・承認のみを担当するため、最小限の負担で維持可能。 | メタデータを自動収集し AI が説明を生成。人間はそれをレビューして承認。 | データモデリング作業。データパイプラインの開発フローに含まれる。 | 最も手軽。Genie Ontology は手作業のキュレーションを必要とせず、Cortex Sense も短期間で導入可能。 | コネクタによる自動収集後、手作業でキュレーション。 | エージェントが生成し人間が Git で確認。手軽だが組織的なレビュー運用の仕組みは自前構築が必要。 |
| 対応クライアント | 柔軟に対応。MCP・REST・CLI を備え、Claude Code、各種エージェント、CI ジョブなど幅広い環境からひとつのナレッジベースを共有。 | 柔軟に対応。Context API や MCP を通して IAM 認証下で利用可能。 | ツール依存。dbt は MCP に対応。 | 各製品専用のチャット UI が中心。Genie は Slack、Teams、モバイル、定期実行などに対応。 | 幅広い。API 経由で連携。 | MCP 対応ツールであれば利用可能。多くはローカル 1 台の環境で完結。 |
| データのポータビリティ | オープンな Markdown(YAML Frontmatter 付き)。Git でそのまま管理できるプレーンファイルで、ロックインがなく他環境へも容易に移行可能。 | Cloud Storage に出力可能だがカタログ独自形式。OKF バンドルへの直接復元は不可。 | リポジトリ内のコード(SQL / YAML 等)。手元でそのまま管理可能。 | 製品内に限定。蓄積されたコンテキストは該当プラットフォーム内での利用を前提としており、外部への移行性は低い。 | API 経由で取得可能(形式はツールごとに異なる)。 | 高い。ローカルのプレーンファイル(Markdown)として管理されるため、可搬性に優れる。 |
| DWH への直接アクセス | アクセスしない(安全設計)。DWH の認証情報を持たない。SQL は呼び出し側のエージェントか、提案を読んだ本人が自分の権限で実行する。 | アクセスする。Google Cloud 内でリネージやデータ品質を直接監視。 | アクセスする。DWH 内部または隣接環境で直接連携。 | アクセスする。エージェント自身がクエリを実行する。 | アクセスしない(メタデータのみを収集・保持)。 | アクセスしない。 |
| セルフホスト対応 | 対応(MIT ライセンス)。テナントごとに自前運用可能。単一の Go バイナリと Postgres で月額約 $10 から運用可能(Google Cloud 外では字句検索のみ)。 | 非対応(Google Cloud のマネージドサービス)。 | 一部対応(dbt は可。DWH ネイティブのものはクラウド DWH に付随)。 | 非対応(クラウド DWH や SaaS に付随)。 | 対応(OpenMetadata、DataHub などオープンソース版あり)。 | 対応。サーバー構築が不要。LLM 実行を伴うものは API 費用が必要。 |
デプロイと導入
ochakai は、自組織の Google Cloud プロジェクト内にデプロイして運用できます。ナレッジや変更履歴はすべて自環境内に保持され、外部へ流出することはありません。
データのエクスポートも簡単です。ochakai export を実行すれば、すべてのナレッジが標準フォーマット OKF(YAML Frontmatter 付き Markdown)で出力され、他のシステムへもスムーズに移行できます。
前提条件、費用見積もり、IAM 認証設計、バックアップやアップデートの手順は、「デプロイと運用ガイド」にまとめています。
構築 Terraform で Cloud Run + Cloud SQL をデプロイ
git clone https://github.com/na0fu3y/ochakai && cd ochakai/deploy/terraform cp terraform.tfvars.example terraform.tfvars # project・region・invokers を設定 terraform init terraform apply # Cloud SQL の作成に 10〜15 分ほどかかります
# 初回のみの手作業: スキーマの初期化(流し込む SQL は terraform output が表示) gcloud sql users set-password postgres --instance=ochakai --prompt-for-password cloud-sql-proxy "$(terraform output -raw sql_connection_name)" --port 55432 & psql "host=localhost port=55432 dbname=ochakai user=postgres" # psql の中で「terraform output -raw database_bootstrap_sql」の出力を実行すれば完了 terraform output -raw use_command # チームメンバーに共有する ochakai use コマンドを表示
Terraform を利用しない場合は、gcloud コマンドだけで構築する手順もガイドに掲載しています。
ナレッジ登録 自組織のデータを登録する
# テーブル定義を取得して投影。ochakai がデータウェアハウスに直接アクセスすることはありません # ※ --max_rows を指定して全カラムを取得(省略時は先頭 100 行のみの出力になるため注意) bq query --max_rows=100000 --format=json --nouse_legacy_sql \ 'SELECT table_schema, table_name, column_name, data_type, is_nullable FROM `your-project.your_dataset.INFORMATION_SCHEMA.COLUMNS` ORDER BY ordinal_position' \ | ochakai seed - | ochakai import -
上記は BigQuery の例です。seed コマンドは INFORMATION_SCHEMA.COLUMNS 形式の JSON を読み込みます。Snowflake や PostgreSQL などでも同様に取り込み可能です。
インポートしたドキュメントは、最初はすべて draft(下書き)として登録されます。そこに人間やエージェントが現場の「読み方・注意点」を書き足すことで、実用的なナレッジへと育ちます。対象範囲の絞り方や記述の進め方は「ナレッジ作成ガイド」、ナレッジを最新に保つ運用サイクルは「運用サイクルガイド」をご覧ください。
MCP クライアントごとの設定
Claude Code はシェル実行環境を備えているため、CLI 経由での利用を推奨しています(ツールの定義スキーマでコンテキストウィンドウを消費しません)。MCP ツールとして接続する場合は以下を実行します:
claude mcp add ochakai -- ochakai mcp-stdio
Claude Desktop は前述の .mcpb バンドルを使うのが最も簡単です。手動で設定する場合は、設定 → Developer → Edit Config から claude_desktop_config.json に以下を記述します:
{
"mcpServers": {
"ochakai": { "command": "ochakai", "args": ["mcp-stdio"] }
}
}
Cursor、VS Code、Windsurf、Cline、Zed、Gemini CLI なども同様の形式で接続できます。各エディタ向けの設定手順、自動フックの導入方法、接続トラブルシューティングは「エージェント接続ガイド」をご覧ください。Cloud Run 上の ochakai に接続する際は、クライアント環境で PATH に ochakai が通っており、gcloud auth login が完了している必要があります。