Hexでマーケの分析をAIに書かせる方法｜数字の検算は人が持つ

「マーケの数字を出すたびに分析の担当に頼んで、1週間待っている」「AIにSQLを書かせたら、それらしい数字が出てきたが、合っているのか誰も確かめていない」——データ基盤はあるのに、数字を引き出すところで詰まっているマーケ部門から聞こえてくる声です。前者の悩みは、AIが分析のコードを書く道具で軽くなりつつあります。けれども後者の悩みは、道具を入れるほど大きくなります。分析をAIに任せる話は、書かせる話ではありません。本当は、指標の定義と検算を人が持ったまま、書く手間だけをAIに渡す段取りの話です。この記事では、米国の Hex を例に、マーケの分析をAIに書かせるときの手順を、2026年10月時点の公式情報をもとに整理します。

Hexは何をする道具か

Hex は、Snowflake や BigQuery のようなデータ基盤につないで、SQL、Python、表、グラフを1枚のノートブックの上で組み立てる分析の道具です。公式サイトは2026年10月時点で、自らを「AI分析の基盤」と呼び、AIのエージェントが付いたノートブック、会話で自分で数字を調べる機能、操作できる形で共有するデータのアプリを、一つの作業場にまとめたものと説明しています。

中心になるAIの機能は Notebook Agent です。公式ドキュメントによれば、自然な言葉で指示すると、ノートブックの中の SQL、Python、文章、集計表、グラフのセルを作ったり書き換えたりします。以前は製品の中で Hex Magic と呼ばれていた機能群で、いまは用途ごとに名前が分かれています。

ほかに、技術に詳しくない利用者向けに会話で数字を尋ねるスレッドの機能、公開したアプリの中身を説明したり絞り込みを変えたりするエージェント、指標の意味を定める意味モデルを作るエージェントがあります。意味モデルを作るエージェントを使えるのは、管理者などの限られた役割だけです。

公式ドキュメントは、Notebook Agent について「エージェントが提案する SQL とコードを監査できる、技術の分かる利用者が使う前提」と書いています。提供元自身が、書かせたものを人が確かめることを前提にしている点は、導入の判断で押さえておきたいところです。

作っている会社と、国内でまだ知られていない理由

Hex は米国の会社が提供する道具で、海外では分析の担当者やデータの専門家の間で広く使われています。公式サイトには、データ基盤への接続、データの変換の道具との連携、GitHub や GitLab への書き出し、外部から使うための API や MCP の接続口など、分析の現場で使う機能が並んでいます。

それでも、2026年10月時点で Hex を日本語で紹介した記事はごくわずかです。確かめられる範囲の理由として、まず画面と公式ドキュメントが英語で、使う前提としてデータ基盤が社内に整っている必要があることが挙げられます。表計算のファイルを読み込んで使う道具ではなく、データ基盤に入ったデータを相手にする道具です。

もう一つは、利用者として想定されているのが、もともと SQL を書く分析の担当者だという点です。国内ではマーケ部門にその役割の人がいないことも多く、道具の名前がマーケの側まで届きにくい事情があります。AIのエージェントが加わったことで、分析の担当者でなくても使える場面は広がりましたが、確かめる役割の人がいなくてよくなったわけではありません。

公式サイトでは、データの変換の道具 dbt の説明文や指標の情報を取り込んで、表の説明を補えることも案内されています。社内のデータ基盤がこうした道具で整えられているほど、AIが表の意味を取り違えにくくなります。逆に言えば、表や列の説明が空のままのデータ基盤では、AIの書く集計の外れが増えやすいということです。導入の前に、マーケで使う表に説明が付いているかを見ておくと、効果の見込みが立てやすくなります。

マーケ部門がHexを使う場面、使わない場面

Hex が力を発揮するのは、マーケの数字がデータ基盤に集まっている会社です。広告の費用、サイトの行動、MAの反応、CRMの商談がデータ基盤に入っていれば、それらをつないだ集計をAIに書かせ、グラフとアプリにして部門で共有できます。

反対に、マーケの数字がそれぞれの道具の管理画面の中にしかない会社では、Hex を入れても使える材料がありません。その場合は、先にデータ基盤にデータを集める仕組みづくりが必要で、これはマーケ部門だけで決められる話ではなくなります。データ基盤の整備を外部に頼むか社内で持つかの考え方は、別の記事（データ分析は外注かAIで内製か）にまとめています。

また、施策ごとに商談への貢献を配分する数字のように、計算の型そのものが論点になる分析は、書かせる以前に型の選び方を決める必要があります。こちらは同じ便の HockeyStack の記事で扱っています。この記事で扱うのは、すでに定義の決まった数字を、AIに速く正しく出させる段取りです。

迷う場合は、上位の区分に用意されている30日の試用で、毎月の定例の報告を1本だけ作り直してみるのが近道です。いま分析の担当者に頼んでいる報告を、マーケの担当者が Hex のAIに書かせ、同じ数字が出るかを比べます。同じ数字が出るまでにかかった時間と、直した箇所の数が、そのまま導入の判断材料になります。

手順の全体像

マーケの分析を Hex のAIに書かせるときの流れを、6つの工程に分けます。工程の順番には意味があり、前の工程が決まらないまま次に進むと、後で数字の説明がつかなくなります。

工程1と工程2は、分析の担当者や情シスと一緒に決めます。工程3から先は、マーケの担当者が自分で回せるようになるのが目標です。ただし工程4の検算だけは、慣れるまでは分析の担当者に見てもらう期間を設けておくと安心です。

6つの工程のうち、道具の設定で済むのは工程1と工程5と工程6の一部だけです。工程2と工程4は、部門の中の合意と習慣の話で、道具を入れただけでは何も変わりません。導入の計画を立てるときは、設定の作業より、定義を決める会議と検算を回す担当の時間を先に確保しておくと、使い始めてから止まらずに済みます。

工程1　つなぐデータと権限を決める

最初に決めるのは、Hex にどのデータをつなぐかです。公式サイトによれば、Hex は OAuth による接続で、利用者がデータ基盤の側で持っている権限をそのまま引き継げます。つまり、データ基盤の側で読めない表は、Hex の中でも読めないという形にできます。マーケの担当者に読ませたくない表があるなら、データ基盤の側で先に権限を整えておくのが筋です。

公式ドキュメントによれば、データ接続を部門や全体に共有できるのは管理者です。案件の中で使われているデータ接続を持っていない利用者は、その案件では探索かアプリの閲覧までしかできません。マーケに渡す接続と、分析の担当者だけが使う接続を分けておくと、個人情報を含む表に誤って触れる心配を減らせます。

つなぐ表は、最初から全部にしないことをおすすめします。広告の費用、サイトの訪問、MAの反応、CRMの商談のように、マーケの定例の報告で使う表から始め、個人を特定できる列は集計済みの表に置き換えておくと、AIに書かせる範囲も安全に絞れます。

権限は、渡すときだけでなく外すときの段取りも決めておきます。担当者が異動したり退職したりしたときに、データ基盤の側の権限と Hex の作業場の役割の両方を外す手順を、情シスの退職時の手続きに組み込んでおきます。Hex の側だけ外しても、データ基盤の側の権限が残っていれば意味が薄れるからです。

工程1の続き　AIに何が送られるかを確かめる

AIに書かせる以上、社内のどの情報がAIのモデルに送られるかを確かめておく必要があります。Hex の公式ドキュメントによれば、モデルに渡されるのは、データベースの表や列の名前のようなメタデータ、案件のコード、そして出力の内容です。公式ドキュメントは、表や列の名前、コードに機密の情報が入っていれば、それがモデルに渡り得ると注意を促しています。

学習への利用については、公式サイトに「顧客のデータは Hex や提携先のAIモデルの学習に使わない」と書かれています。公式ドキュメントでも、AIの提供元は顧客のデータで学習せず、既定では保存もしない取り決めだと説明されています（2026年10月時点）。使われるモデルの提供元として、Anthropic の Claude と OpenAI の名前が挙がっています。

一方で、確かめておきたい点もあります。一部の高度なモデルは、提供元が一定期間だけ入力と出力を保存する必要があり、管理者が有効にした場合にだけ使えると説明されています。また、Hex 自身がプランによってはAIの利用のデータを機能の改善に使うことがあり、設定で止められるとされています。どの設定にしているかを、情シスと一緒に確かめてから使い始めることをおすすめします。管理者は、全体でAIの機能を止めることもできます。

工程2　指標の定義を先に書く

AIに「先月の商談化率を出して」と頼むと、AIは手元の表から、それらしい計算を組み立てます。けれども、商談化率の分母が問い合わせの数なのか、MAで点数が一定を超えた見込み客の数なのかは、AIには分かりません。定義が決まっていない指標をAIに書かせると、聞くたびに違う数字が出ます。

Hex には、指標の意味を定める意味モデルや、承認済みのデータに印を付ける仕組み、作業場の規則を管理するコンテキストスタジオがあります。公式ドキュメントによれば、会話で数字を尋ねる機能は、承認済みで意味モデルに定義されたデータを優先して使います。定義を道具の中に入れておけば、AIが勝手な計算を組み立てる余地を減らせます。

ただし、道具の中に入れる前に、定義そのものを部門で合意しておく必要があります。マーケと営業で商談の数え方が違うなら、それを先にそろえるのが先です。定義書に何を書くかは別の記事（指標の定義書に書く項目一覧）にまとめています。ここでは、少なくとも毎月の報告で使う5〜10の指標だけは、AIに書かせる前に定義を決めておく、という線を引いておきます。

定義を入れたあとも、AIが定義どおりに動いているかを見る仕組みがあります。公式ドキュメントによれば、コンテキストスタジオでは管理者がAIの使われ方を見て、エージェントの推論の過程を見直し、規則や定義を直せます。公式サイトは、変更を本番に出す前に試し、エージェントの正確さへの影響を測る評価の仕組みも案内しています。こうした見直しを誰がどの周期で行うかを、管理者の役割として決めておくと、定義が古びるのを防げます。

工程3　AIに書かせる

定義が決まったら、AIに書かせます。Notebook Agent に自然な言葉で問いを渡すと、SQL のセルとグラフのセルが組み立てられます。マーケの担当者にとっての利点は、問いを考えることと、結果を見ることに時間を使えるようになる点です。

書かせるときは、問いを1つずつ渡します。「チャネルごとの商談化率と、その月ごとの変化と、業種別の内訳を出して」とまとめて頼むと、どこかの段階で前提がずれても気づきにくくなります。チャネルごとの商談化率を出し、確かめてから月ごとの変化に進む、という順番にすると、ずれた箇所がすぐに分かります。

もう一つの工夫は、AIに前提と絞り込みの条件を文章で説明させることです。どの表を使い、どの期間で、何を除外したのかを、セルの横に書かせておきます。説明と SQL の中身が食い違っていれば、そこが確かめるべき箇所です。

AIが書いた SQL を、マーケの担当者がすべて読めるようになる必要はありません。ただ、どの表を結合しているか、期間の条件はどこか、件数を数えている列はどれかの3点だけは読めるようにしておくと、検算の工程がずっと楽になります。

工程4　検算する

AIが出した数字は、検算を通るまで外に出しません。公式ドキュメントが Notebook Agent を「SQL とコードを監査できる利用者が使う前提」と書いているとおり、書かせた集計が正しいことを確かめるのは、道具ではなく人の仕事です。

いちばん効くのは、別の集計と突き合わせることです。広告の費用ならそれぞれの媒体の管理画面の合計、商談の数ならCRMの標準の報告の数字と比べます。数字が一致しなければ、どちらかの条件が違っています。完全に一致しない理由が説明できるなら（集計の締めの時刻が違う、など）、その理由を記録に残してから使います。

件数の確認も欠かせません。表を結合したあとの行の数が、結合する前の行の数より増えていたら、同じ商談が二重に数えられている可能性があります。AIの書いた SQL でもっともよく起きる誤りの一つで、数字がもっともらしく見えるぶん、見落とされがちです。

• 結合で行が増えたまま合計し、商談の数や金額が実際より大きく出る
• 期間の条件が日付の境目でずれ、月の最終日の分が抜けるか重なる
• テスト用や社内の問い合わせを除外する条件が抜けたまま集計する

どれも、SQL の文法としては正しく、エラーも出ません。だからこそ、エラーが出ないことと、数字が正しいことは別だと部門で共有しておくことが大切です。数字が大きく動いたときほど、施策の効果を語る前に集計の条件を疑う順番にしておきます。

検算のチェックリスト

検算の工程は、人によってやり方がばらつきやすい工程です。数字を報告や会議に出す前に、次の項目を確かめることを部門の決まりにしておくと、確かめる人が変わっても水準が保てます。

• 使った表と期間、除外の条件が、セルの説明として残っている
• 結合の前と後で行の数を比べ、増えていないことを確かめた
• 合計の数字を、媒体の管理画面かCRMの標準の報告と突き合わせた
• 使った指標が、部門で決めた定義のとおりに計算されている
• 前月や前年の同じ報告と比べ、大きく動いた数字の理由を説明できる
• 数字を外に出す前に、作った人とは別の人が一度見た

最後の項目は、とくに大切です。AIに書かせた人は、出てきた数字を正しいと思い込みやすくなります。作った人とは別の人が見るだけで、明らかな誤りの多くは見つかります。

チェックリストは、ノートブックの先頭に文章のセルとして貼っておくと、確かめたかどうかが記録として残ります。誰がいつ確かめたかを一行書き添える決まりにしておけば、後から数字の出どころを問われたときにも、確かめた人に経緯を聞けます。数字を外に出す判断は、AIでも作った人一人でもなく、決めた確認者が持つと決めておきます。

工程5　公開して共有する範囲を決める

検算を通った数字は、ノートブックやアプリの形で共有します。Hex の公式ドキュメントによれば、案件の共有の権限は、全権限、編集、探索、アプリの閲覧のみの4段階で、複数の経路で権限を持っている場合は高いほうが優先されます。閲覧者の役割の人は、探索かアプリの閲覧までしか受け取れません。

マーケの上長や営業に見せる数字は、アプリの閲覧のみで共有するのが基本です。中身の SQL を書き換えられる権限を広く渡すと、誰かが条件を変えた版が、検算を通った版と並んで出回ります。編集できる人を、作った担当者と確認者に絞っておくと、数字の出どころが一つに保てます。

公式ドキュメントでは、案件をウェブ全体に公開する選択肢や、外部のサイトに埋め込む機能、リンクを持っている人が他の人に転送できることも説明されています。社外への公開は、マーケの社内向けの数字では原則として使わないと決め、使う場合は承認者を決めておきます。会話の道具の Slack や、MCP 経由で他のAIから作業場に問い合わせられる接続口を開く場合も、どの範囲の数字に届くかを先に確かめます。

共有した数字には、いつ時点の数字か、誰が検算したかを、アプリの冒頭に書き添えておきます。見る人が数字の新しさと確かめた人を一目で分かるようにしておくと、会議で数字の出どころを巡る議論に時間を取られなくなります。

工程6　定期の更新を決める

毎週や毎月の報告に使う数字は、決まった周期で自動で更新する形にできます。公式ドキュメントによれば、定期の実行が終わったときや、データが条件を満たしたときに、アプリ内の通知、メール、Slack で知らせることができ、通知にはスクリーンショットやデータの書き出しを添えられます。

便利な反面、データの書き出しを添えた通知は、受け取った人の手元にデータが残ることを意味します。通知の宛先と、添えてよいデータの範囲を決めておくことが大切です。とくに個人を特定できる列を含む表の書き出しは、通知に添えないようにします。

定期の更新には、持ち主を必ず決めます。元の表の列の名前が変わったり、計算の定義が変わったりすると、更新は失敗するか、もっと悪い場合は誤った数字のまま更新され続けます。持ち主が異動するときに引き継ぐこと、使われなくなった報告は止めることも、あわせて決めておきます。

定期の更新で出た数字にも、検算は要ります。毎回すべてを確かめる必要はありませんが、前回から大きく動いた数字だけは、持ち主が理由を確かめてから共有すると決めておくと、元の表の変化による誤りを早く見つけられます。更新の失敗の通知を誰が受け取るかも、持ち主とは別に決めておくと安心です。

工程ごとの分担表

ここまでの6つの工程について、AIに任せることと、人が確かめることを一枚の表にまとめます。部門で使い始めるときの役割分担の確認に使ってください。

工程	AIに任せること	人が決める・確かめること
つなぐデータと権限	なし	つなぐ表、権限、AIに送られる情報の設定
指標の定義	定義の文章の下書き	定義の合意と、道具の中への登録
AIに書かせる	SQL・グラフのセルの下書き、前提の説明	問いの切り分けと、渡す順番
検算	突き合わせ用の集計の下書き	件数と合計の確認、外に出す判断
共有の範囲	なし	権限の段階、社外への公開の可否
定期の更新	決まった周期での実行	持ち主、通知の宛先、止める判断

表を見ると分かるとおり、AIに任せられるのは、書く作業と下書きです。何を数え、正しいと認め、誰に見せるかは、どの工程でも人の側に残ります。この分担を最初に共有しておくと、「AIが出した数字だから」という理由で誤りが通ることを防げます。

表の「なし」の欄は、AIに任せてはいけない工程という意味です。たとえば共有の範囲をAIのエージェントに決めさせたり、接続の権限をAIの提案どおりに広げたりすると、誰が判断したのかが残りません。権限と公開に関わる判断は、人が決めて記録に残す工程として切り分けておきます。

費用の増え方と、やめるときに残すもの

Hex の料金は、2026年10月時点で無料の区分から企業向けまで4つの段階に分かれ、上位の区分には30日の試用が用意されています。金額は公式サイトで確かめてください。公式ドキュメントによれば、AIの機能はクレジットを消費します。使う人と問いの数が増えるほど、席の数に加えてAIの利用量の分も費用が増えると考えておきます。

企業向けの区分では、自社が契約しているAIの提供元の鍵を使う方式も選べます。この場合、AIの利用は Hex のクレジットを消費しませんが、公式ドキュメントは、必ずしも費用の節約になるわけではないと注意しています。自社側の提供元への支払いが増えるためです。公式サイトでは、使うモデルを選べること、会話ごとにAIの利用量を見られることも案内されています。どのモデルを標準にするかと、利用量を月に一度見る担当を決めておくと、費用の増え方を早めにつかめます。

やめるときに困らないように、残すものも決めておきます。Hex は案件を GitHub や GitLab に書き出せると公式サイトで説明しています。少なくとも、毎月の報告に使う SQL と指標の定義は、道具の外にも控えを残しておくと、道具を替えても数字の出し方を引き継げます。

分析の担当とマーケの役割を分け直す

Hex のような道具を入れると、マーケの担当者が自分で数字を出せる場面が増えます。そのぶん、分析の担当者の仕事は、依頼された集計を書くことから、定義を整え、検算の水準を保ち、難しい問いを受け持つことへ移っていきます。

この移り変わりを放っておくと、マーケは確かめずに数字を出し、分析の担当者は自分の知らない数字が会議に出ることに困る、という状態になりがちです。役割を分け直すときは、定義を持つ人、検算の水準を決める人、数字を外に出す承認をする人を名前で決めておくと、責任の線がはっきりします。

最初の数か月は、分析の担当者がマーケの書かせた数字を定期的に見直す期間を設けるとよいでしょう。どの種類の問いで誤りが出やすいかが分かれば、その問いだけは分析の担当者が受け持つ、という分担も決められます。

マーケの担当者の側にも、身につけておきたいことがあります。SQL を書けるようになる必要はありませんが、表の結合と期間の条件と除外の条件の3つを読めることは、AIに書かせる側の最低限の素養です。分析の担当者が短い勉強会を開き、実際に誤った集計の例を一緒に読むと、検算の勘所が部門に広がります。

まとめ

Hex は、データ基盤につないだノートブックで、AIに SQL やグラフを書かせられる分析の道具です。2026年10月時点で日本語の解説はほとんどありませんが、マーケの数字がデータ基盤に集まっている会社なら、分析の依頼を待つ時間を大きく減らせる可能性があります。ただし、書く手間がなくなっても、数字の正しさに責任を持つ人はなくなりません。つなぐデータと権限を決め、指標の定義を先に書き、AIに書かせた数字は検算を通してから出し、共有の範囲と定期の更新の持ち主を決める。この6つの工程を人が持つことで、AIが書いた数字を部門の判断に使えるようになります。まずは毎月の報告に使う指標を5つ選び、定義を書き出すところから始めてみてください。

• 製品の機能・データの扱い・共有の権限・料金の考え方は、Hex の公式サイトと公式ドキュメントを2026年10月15日に確かめた範囲に基づきます。機能や条件は更新されることがあるため、利用前に最新の原文を確かめてください
• AIに送られる情報や学習・保存の扱いは、契約の区分と管理者の設定で変わります。実際の設定は情シスの担当者と一緒に確かめてください

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