最近仕事で重宝している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つです。
- データガバナンスと自律性の両立: データチームが全クエリを一手に受け付ける中央集権的な運用には限界があります。PMやBizDevが自走できる環境が必要でした。
- セルフアナリシスの実現: 定常的な調査をBizDevが単独で完結できるようにしたかったです。毎回データチームに依頼していては、スピードが出ません。
- コラボレーションの質の向上: 分析の結果だけではなく、クエリそのものや考察のプロセスをチーム間で共有したかったです。「このグラフどうやって出したの？」という問いにすぐ答えられる状態を作りたかったです。
Codatumは「クエリが書けるNotion型BI」×「堅牢な権限管理」という位置づけでこの課題要件にフィットしました。
2025年末から2026年初にかけて、Phase 1（基盤整備）→ Phase 2（パイロット運用）→ Phase 3（全社展開）と段階的にロールアウトが進んでいきました。
Text-to-BIで分析の世界が変わった
導入後、特に体験が変わったのがCodatum AIの存在です。
以前の分析ワークフローはこんな感じでした。
- BigQueryのコンソールを開き、クエリを考えて書く
- 結果を眺めながら分析の方向性を再検討する（これを繰り返す）
- 最終的なテーブルを確定し、Looker Studioやスプレッドシートにエクスポート
- グラフを作り、PNGでキャプチャ
- 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のプロダクト進化に並走しながら、社内の運用基盤を強固にしていきたいと思います。
