最近仕事で重宝しているBIツール+AIエージェントである、Codatumについて書きたいと思う。

データ活用において、「検証したい仮説を、その瞬間に検証できない」という摩擦は結構ストレスである。

クエリを書く環境を立ち上げ、SQLを考え、結果を取り出し、可視化ツールに接続し、チャートをつくる。場合によってはスライドなどに貼って議論する——このサイクルを毎回繰り返していては、調べること自体が億劫になるし、そもそもデータ活用はこのアウトプットを用意した先の議論が本丸であるのに、データを作るヘッドのコストが高い。

ところが、Codatumを使い始めて、その摩擦がかなり減った感覚がある。この記事では、なぜTableauを離れてCodatumを選んだのか、実際に何が変わったのか、そしてまだ解決されていない課題を書いてみる。

Codatumとは何か

Codatum（コダタム）は、「先進的なデータ探索を当たり前に。チームのためのデータノートブック」をコンセプトに開発された次世代BIツール。

開発元の株式会社CODATUMは2023年10月設立。KARTE（顧客体験プラットフォーム）を手がける株式会社プレイドが、デベロッパー向けのデータ分析事業を吸収分割によりスピンアウトさせた専門企業で、KARTEで培ってきたデータ基盤の知見がプロダクトの背景にある。

• ノートブック形式を採用しており、SQLクエリの結果をリアルタイムで表示しながら、チャートや説明文と一体で管理できる。
• 複数メンバーでの同時編集にも対応している。
• データはコピーせずデータウェアハウスへ直接接続するため、常に最新かつ正確な状態が保証される。
• 対応データソースはBigQuery、Snowflake、Amazon Redshift、Databricksと主要なウェアハウスをカバーしている。

加えて、Codatum AIというAIエージェントがシームレスに統合されており、チームの文脈に合わせた分析エキスパートとして機能する。

紹介としてはざっとこんなところか。

なぜ導入したのか

10XではもともとTableauを社内公式BIとして運用していた。しかし、そもそもTableau自体が取り扱いが難しい故に、Tableauを避けて作られた非公式ダッシュボードが大量に存在するなどの課題があった。

この状況を解決するにあたって、課題は大きく3つ。

1. データガバナンスと自律性の両立: データチームが全クエリを一手に受け付ける中央集権的な運用には限界がある。PMやBizDevが自走できる環境が必要だった。
2. セルフアナリシスの実現: 定常的な調査をBizDevが単独で完結できるようにしたかった。毎回データチームに依頼していては、スピードが出ない。
3. コラボレーションの質の向上: 分析の結果だけではなく、クエリそのものや考察のプロセスをチーム間で共有したかった。「このグラフどうやって出したの？」という問いにすぐ答えられる状態を作りたかった。

Codatumは「クエリが書けるNotion型BI」×「堅牢な権限管理」という位置づけでこの課題要件にフィットした。

2025年末から2026年初にかけて、Phase 1（基盤整備）→ Phase 2（パイロット運用）→ Phase 3（全社展開）と段階的にロールアウトが進んでいった。

Text-to-BIで分析の世界が変わった

導入後、特に体験が変わったのがCodatum AIの存在だ。

以前の分析ワークフローはこんな感じだった。

1. BigQueryのコンソールを開き、クエリを考えて書く
2. 結果を眺めながら分析の方向性を再検討する（これを繰り返す）
3. 最終的なテーブルを確定し、Looker Studioやスプレッドシートにエクスポート
4. グラフを作り、PNGでキャプチャ
5. Google SlidesやNotionに画像として貼り付ける

この工程の問題は、ビジネスで最終的に活用されるアウトプットが「チャート画像」になりやすい、ということだ。

分析をビジネスに活用するうえでの課題

• 当然ながらグラフが画像になった瞬間に、データとの接続が切れる
• 次の週にデータが更新されても、画像を張り替えるだけの作業が発生する
• クエリも個人のローカルに眠っており、チームと共有するには別途手間がかかる
• 可視化のセンスも、作った人の力量に依存する

Codatum AIを使うと、この流れが根本から変わる。テキストで「このカテゴリ別に先週の発注ヒット率をヒートマップで見たい」と伝えると、AIがSQLを生成し、ドライランで検証し、実行し、チャートまで付けてくれる。テキスト → AI → チャートまで、摩擦なく一気通貫で完結する。

以前は「このクエリ書くの面倒だな」と諦めていた分析も、気軽に試せるようになった。これは思っていた以上に大きい心理的な変化で、「ちょっと気になる」という軽い好奇心のままデータを見に行けるようになったことで、分析の頻度そのものが上がった。

具体的な利用シーン

• AI発注（AIO：AIを用いて最適な発注を支援するプロダクト）の発注精度評価では、カテゴリ別のヒートマップを動的に掘り下げながら、どういった性質の発注領域で勧告精度が落ちているかを追っている。以前はこの種の分析に小一時間かかっていたが、今は数分で初手の仮説まで持てる
• トップ面談用のレポートも、NotionへのPNG貼り付けからCodatumへ移行した。データが更新されるたびに画像を差し替える作業から解放されたのは実際に効いている

改善してほしいポイント

使い込むほど、プロダクトとしてのポテンシャルを感じる一方で、いくつか越えるべき壁も見えてきた。

管理API・IaC・監査ログの整備

現状、TerraformなどのIaaSとの連携がなく、設定のコード管理ができない。APIは存在するが、IaCツールと組み合わせて設定を宣言的に管理する手段がまだ整備されていない。手作業でのオペレーションが残り、スケールさせるほど運用コストがかかる構造になっている。

監査ログについては、Enterpriseプランに機能自体は存在する。ただし、ログのエクスポートには未対応で、ノートブック内容の詳細が記録されないなど制限がある。Tableau時代は監視スクリプトを外部から組んで不正共有を検知していたが、Codatumでは同等の仕組みを外から構築するのが難しい状態だ。

「誰がどのノートブックを誰と共有したか」を事後的にトレースする手段が限られており、特にエンプラ顧客企業向けに大規模共有ニーズが強い10Xにおいて、ガバナンスの観点では不安が残る。

ノートブックが乱雑になりやすい

もう一点、運用を続けていて気になるのが、ノートブックの散在リスク。

1ノートブックあたり最大10MBのサイズ制限があり、要素数やページ数が増えるとパフォーマンスが低下する。Codatum公式も「ノートブックはコンパクトに保つことを推奨」しており、大きくなりすぎたら新しいノートブックを作成するよう案内している。

これは裏を返せば、管理・整理のルールをチーム自身で設計しなければ、ノートブックがどんどん増えて使われなくなるリスクがある。Tableauの「野良ダッシュボード問題」がCodatum上で再燃する可能性がある。同じ轍を踏まないために、早い段階からノートブックのガバナンス設計を進める必要がある。

外部共有とセキュリティ

将来的には、パートナー（小売事業者）にもデータ環境を開放して施策PDCAを自律的に回してもらいたいと考えている。しかし現状、Codatumの外部共有機能はセキュリティ面で課題があり、パートナーへの本格運用には踏み切れていない状態だ。

ノートブック単位での共有は、編集者・閲覧者ロールで外部ユーザーを招待できる設計になっている。一方で、Editor権限があれば外部ユーザーを招待できてしまうため、意図しない共有が発生するリスクがある。前述の監査ログの制限と合わせると、ミスが起きても気づく手段が限られていて、傷口が広がってから発覚するパターンになりうる。

パートナーへの展開を視野に入れるなら、このセキュリティ基盤の強化が前提になる。

まとめ ── BIの民主化が現実味を帯びてきた

総じて、プロダクトとしてのポテンシャルは非常に高いと感じており、私が一番ハマっているプロダクトと言える。

特にAIエージェントとの統合によって、「データを見る」ハードルが劇的に下がった。生成AI登場初期からこういった分析に活用するユースケースは多々試してきたが、プロダクトとしての統合性という意味で、はじめて完成度の高いプロダクトだと感じる。

一方で、管理APIの整備、ノートブックガバナンス、外部共有のセキュリティといった課題は、プロダクトの成熟とともに解決されていくことを期待している。これらが整えば、社内にとどまらずパートナーへの展開も視野に入る。

Codatumのプロダクト進化に並走しながら、社内の運用基盤を強固にしていきたい。