Contents
データチームの仕事の中で、いちばん残らない作業は 「ダッシュボードに乗らない単発の問い」 にあたる仕事だと思います。「この数字、どうしてこうなってるの？」「先月のキャンペーン、効いてた？」のような仮説型の問いには、定例ダッシュボードでは答えにならず、SQL を 1 本その場で書いて、結果を Slack に貼って、口頭で解釈を 2-3 行添える、というやり方になります。問題は、ここで生まれた 数字と解釈が、ペアで後に残らないこと です。
最近は ChatGPT や Claude で SQL のドラフトを作る人が増えました。それでも、出てきた SQL をエディタに貼り直して、実行して、結果をどこかに残して、文章に整えて、というところは結局自分で往復している、という景色は変わっていません。SQL は SQL ツール、結果は Slack、考察はその下のコメント、と置き場が散ったまま、半年後に同じ問いが来るとまた一から書き直しになっています。
Codatum Agent を Notebook の Doc ページの中で動かすと、そこの景色が変わってきます。たとえば、こんな感じです。
月曜朝に「先週の売上どう？」と Slack で投げられて、Doc ページを 1 枚開いて Agent に話しかけるところから始める
30 分後、その Doc には SQL と実行結果と、「先週比 +18% は新規獲得が主因」の callout が縦に積まれている
半年後の同じ問いには、Slack 履歴を漁らずに Doc の URL 1 本を貼って答える
別のメンバーがその Doc を開けば、SQL も解釈 callout も読める ── 「あの数字、誰が出したっけ」が消える
Agent との対話の結果が、別ウィンドウや別タブに行かず、いま開いている Doc ページに直接書き込まれていく ── 並べた場面で共通しているのはそこです。対話のあとには、1 ページのドキュメントが手元に残ります。場面は違って見えても、起きていることはこの 1 つだけ です。
この記事では、その仕組みを 3 ステップで組む手順を、実機の画面付きで紹介していきます。
全体像 — Doc ページが「対話の作業場」になる
Codatum Agent が Doc ページの中で動くとき、組み合わさっているのは大きく 3 つの動きです。順に見ていきます。
ページコンテキストの自動共有 — いま開いているノートブックの SQL ・チャート ・パラメータが、毎ターン Agent に背景として渡る
Approve を挟んだ SQL 実行 — Agent が SQL を書く判断をすると、実行前に承認ダイアログが入る。承認すれば結果まで自動で取得される
SQL ブロック / Summary / callout を Doc に直挿し — 取得した結果をもとに、Agent が SQL ・要約テキスト ・考察 callout を Doc に直接書き込む
ポイントは、Agent の出力が外に行かないことです。SQL ブロックは Doc に挿入され、要約と考察も同じページに積まれていく。対話のあとに残るものが、そのまま読めるドキュメントになっている ── そこが、別ウィンドウで答えが返ってくる AI との違いです。
Step 1 — Agent に説明しなくても、文脈が伝わる
Agent と対話するときに地味に消耗するのが、前提を毎回説明することです。「いま月次の売上を見ていて、SQL はこうで、パラメータは先月で…」を毎ターン書くのは、それ自体が分析の足を引っ張ります。
Codatum Agent はその工程を一段省いています。Doc ページを開いた状態で AI Agent パネルを開くと、入力欄の上に いま開いているページ名と、ノートブック内の context 数のバッジ が表示されます。ノートブック内の SQL ブロック ・チャート ・パラメータが、まとめて Agent の背景情報として毎ターン渡る、という意味です。だから、たとえば次のような短い依頼でも通じます。
order_itemsを使って、月次売上の推移と前月比を出す SQL を書いて、結果を 2-3 行で要約してください。考察は callout で残してください。
order_items がどのテーブルを指しているかは、コンテキスト経由でノートブック内の他の SQL から推測されます。前提を 5 行書いていた頃と比べると、問いの密度がはっきり上がります。
依頼を送ると、Agent はまず関連テーブルの場所を Tool Execution: search で探しに行きます。テーブルが見つかれば次に進み、なければ「このプロジェクト/データセット名で進めますか？」のように選択肢を返してきます。データソースが揺れがちな環境でも、Agent が勝手に決めずに 対話に戻してくる 設計になっています。
Step 2 — Approve ひと押しで、Agent に SQL を任せる
Agent が SQL を書く判断をすると、Doc に流し込む前に Tool Execution: run_sql / Waiting for approval という承認ダイアログがチャット側に出てきます。SQL の中身、対象 Connection、そして「Do you want to execute this query?」の問いが並びます。
承認の選択肢は 3 つあります。Cancel（やめる）、Approve（このクエリだけ実行）、Auto-approve next time（このスレッドの次回以降は自動承認）。最初は 1 件ずつ Approve して、信頼できる流れになったら自動承認に切り替える、という段階を踏める設計です。
Approve を押すと SQL が実行され、結果は Tool Execution: run_sql / Completed として Result セクションに JSON 形式で表示されます。JobResultStatus: SUCCESS と rows が見える状態で、ここから Agent は次の判断（要約を書く、callout を残す、Doc に書き込む）に入っていきます。
Approve を挟む設計が効くのは、Agent が外したときの安心感です。BigQuery / Snowflake のような DWH に直接クエリが飛ぶ環境では、人がワンクッション置いてから走る、という設計が思っているより効いてきます。承認は 1 アクションで済むので、対話のリズムは大して止まりません。
Step 3 — 事実と解釈が、Doc に並んで残る
run_sql で結果を取り終えた Agent は、続けて Tool Execution: edit_docpage で Doc ページに書き込みを始めます。ここが、Codatum Agent が 「書き残す AI」 として動く真ん中です。流れるのは 3 種類の要素です。
SQL ブロック — 実行済みのクエリがそのまま Doc に挿入される。Connection ラベルと Run ボタンが付いた状態
<b>Summary</b>見出し + 本文 — 結果から事実だけを 2-3 行で書き起こした、見出し付きのテキスト<b>考察（Callout）</b>— 解釈や仮説が箇条書きで残される、左に縦線の入った注記ブロック
callout が効いてくるのは、事実と解釈を視覚的に分けて残せる ところです。Summary には数字の動きをそのまま書き、callout には「これはホリデーシーズン要因と推測される」のような仮説を載せる。半年後にこの Doc を読み返したときに、「事実はここまで、ここから先は当時の解釈」が一目で分かるようになります。
副次的に効いてくるのが、チャット名と Doc ページタイトルの自動命名 です。新規 Doc ページに最初の依頼を投げると、Agent はチャットの題目と、ページのタイトル（たとえば Monthly Revenue Trend (GA Sample)）を自分で付けてきます。Untitled page のまま放置される分析メモが積まれていく事故が、これで起きにくくなります。
edit_docpage の完了表示の横には Restore to previous version ボタンも出ています。Agent の編集が外したと思えばいつでも前の状態に戻せる仕組みなので、Doc に書き込ませることへの心理的なハードルがぐっと下がります。
ひとつのページに、SQL ・結果 ・要約 ・考察が縦に積まれた状態が出来上がります。これが、対話のあとに残るドキュメントの実体です。Slack に数字だけ貼って終わっていた頃と比べて、半年後にもう一度同じ問いが来たときに、リンクひとつで済むようになります。
応用 1 — チームのナレッジを Agent の前提にする
ここまでは「いま開いているページのコンテキスト」を Agent に渡す話でしたが、Codatum Agent には チーム全体のナレッジを毎回の前提にする 仕組みがもう一段用意されています。
ワークスペースに .agent という名前のフォルダを作って、その中に Notebook を置いておくと、Agent はその内容を 毎ターン背景に持って動きます。データ辞書、メトリクスの定義、SQL テンプレート、用語集 ── そういう「アナリストが毎回口頭で説明していたこと」を 1 度書いておけば済む形にできます。
.agent は 4 階層で読まれる設計です。
Workspace 配下の
<b>.agent</b>— 全員に常時読まれる組織共通のナレッジPersonal 配下の
<b>.agent</b>— 自分だけに読まれる個人ナレッジTeamspace 配下の
<b>.agent</b>— そのチームスペースの Notebook を開いている時だけNotebook 内の
<b>.agent</b>ページ — その Notebook を開いている時だけ
優先順位は Notebook > Teamspace > Personal > Workspace で、粒度の細かい指示で上書きできる 設計になっています。「テーブル users の created_at は登録日時ではなく初回ログイン日時」みたいなチーム固有の罠も、Workspace の .agent に書いておけば、Agent が毎回の依頼でちゃんと拾ってきます。
そしてもう一段、<b>search_notebooks</b> というツールが Agent に提供されています。これがあると、Agent は質問に応じて 過去のノートブック を検索して、関連する SQL や分析メモを引っ張ってこられます。
半年前の Q3 キャンペーン分析、似たやつあったら見つけてください
と頼めば、Agent はノートブック名 + Doc 本文を横断検索して、該当 Notebook のリンク（マッチ箇所のハイライト付き）を返してきます。チームの過去の分析資産が「Slack 履歴の海に埋もれて再利用されない」状態を、Agent 経由で再発掘できるようになる、という意味でもあります。
.agent と search_notebooks を組み合わせると、Agent は 「いま開いているページ」「チーム全体のナレッジ」「過去の分析資産」 の 3 つを毎ターン手に取れる状態になります。半年経って同じ問いが来ても、最初から書き起こすのではなく、過去の Doc を呼び出して 書き足していく 形に持っていける、という違いが出てきます。
応用 2 — Workflow と組み合わせて push 配信に育てる
Doc ページで Agent と一緒に作った分析が、定常的に見たいレポートに育ってきたら、そのまま Codatum Workflow に渡せます。Run Report Step で Doc ページを定期再実行し、Slack や Email に流すところまで地続きで組める、という関係です。
この記事の場面が「pull 型 ・対話で書き残す」、Workflow 記事の場面が「push 型 ・自然に届く」だとすると、両者は 同じ Doc ページを起点にしたまま、配信先と頻度だけが違う という構図になります。アドホックで生まれた分析が、価値が出てきたところで定期配信に引き上げられる、という流れが Codatum 1 つで作れる、という意味でもあります。
まとめ — 「答える」から「書き残す」へ
AI の使い方として広く普及しているのは、いまのところ 質問を投げて、別ウィンドウで答えが返ってくる という形です。便利ではあるのですが、出てきた答えを自分の仕事の文脈に貼り直す工程が残るので、思っているほど時間は浮きません。
Codatum Agent は、その答えを いま開いているドキュメントの中に置きにいきます。SQL ブロックも、要約も、考察 callout も、対話のあとには 1 ページのドキュメントとして残っている。貼って終わる作業から、貯まっていく作業へ、というのが「書き残す AI」と呼んでいる実体です。
Slack で「この数字どうなってる？」と聞かれた朝に、Doc ページを開いて AI Agent パネルに話しかけるところから始めてみてください。半日かけて往復していた仕事が、そのまま読める分析メモとして手元に積まれていく感覚があると思います。
「うちのデータ運用に Agent をどう載せようか」を含めて壁打ちしたいときは、選定相談の窓口を開いています。
