Scripts
答えの背後のコードを保存、ワンクリックで新データで再実行、クライアントごとにフォーク、スケジュール。
Script は保存された名前付きパラメータ化コード片。普段見ない Agent 答えの側面 — SQL、Python、整形 — を明日再実行できるものに変えたもの。
質問は同じでデータが変わるときに Script を使用してください。12 クライアントのコホート保持をするコンサルタント。毎週月曜に同じヘルスチェックを実行する創業者。今スプリントのエラーを前スプリントと比較する開発者。
Script の作成
任意の Agent 答えの下にある Keep バーから ＋ Script として保存をクリック。Agent は答えを生み出したツール呼び出しを名前付き関数にパッケージ化:
- リネーム可能なタイトル。
- クエリから抽出されたパラメータ — Agent が使った任意のリテラル（日付、クライアント名、閾値）が編集可能な入力に。
- 再実行可能な完全コード（SQL + Python）。
Script はサイドバー → Scripts に住みます。カテゴリ（分析 / 変換 / レポート / アラート）でブラウズしたり、名前で検索したりできます。
Script の解剖
Script は 3 部構成:
- 入力 — 型とデフォルト付きの名前付きパラメータ。
start_date: date = last_monday()、client_name: text、threshold: number = 0.03。 - ステップ — 順序付きツール呼び出し（SQL、Python、フェッチ）。各ステップは前のステップの出力を参照可能。
- 出力 — 何を返すか。テーブル、KPI、Markdown ブロック、チャート、またはその組み合わせ。
Script の編集はノートブックの編集に似ています — 各ステップがセル。デバッグ中に一度に 1 ステップ実行できます。
Script の実行
3 つの方法:
- 手動 — Run をクリック。パラメータを入力。出力を見る。
- スケジュール — 下のスケジューリングを参照。
- Agent に頼む — 「weekly-churn スクリプトを start_date = last Monday で実行して」。
出力は右パネルに表示。出力を Report として保存、Watch にパイプ、別の Script に連鎖できます。
スキーマ自動マッピング
Script を使う最高の理由: Agent はあなたがクエリを書き直さずに新データに適応できます。
例: あなたが (user_id, signup_date, plan) カラムのテーブルに対して Script を書きました。(customer_id, registered_at, tier) のテーブルを持つ新クライアントに対して実行します。Agent は:
- 新スキーマをイントロスペクト。
- マッピングを提案:
user_id → customer_id、signup_date → registered_at、plan → tier。 - マッピングを見せて確認を求める。
- その場で SQL を書き直す。
結果: 最初のクライアントは 30 分。次は 5 分。
マッピングをロックすることもできます — 「Mercato スキーマのクライアントには常にこのマッピングを使う」 — Agent は将来一致する実行に自動適用。
フォーク
Script が新しいコンテキストにほぼ正しいが調整が必要なとき（異なる閾値、異なるセグメント）、フォーク:
- サイドバー → Script → Fork。
your_script (fork)という名前のコピーが得られ、自由に編集できます。- オリジナルは触れられません。
フォークは、コンサルタントがクライアントごとに 1 つのスクリプトを維持する方法 — 共通テンプレート、クライアントごとの小さな逸脱。
バージョン履歴
すべての保存がバージョンを作成。Script のページから:
- バージョンドロワーが各保存を短い自動生成説明と表示。
- 任意の 2 バージョン間の Diff。
- 任意の前バージョンへの Revert。
- 名前付きタグ — バージョンを「v1.0」や「stable」として共有可能な参照に昇格。
スケジュール実行が壊れたときに有用 — 戻す、調査、再昇格。
スケジューリング
Script を開く → Schedule。頻度（日次 / 週次 / カスタム cron）を選択。スケジュール実行のためのパラメータデフォルトを入力（例: start_date = last_monday()）。
各スケジュール実行:
- 出力を新しい Run として保存。
- Report に供給可能（「report に添付」トグル）。
- Watch をトリガー可能（出力を閾値と比較）。
- Jobs ページに実行ステータスと所要時間で表示。
実行はデフォルトで 90 日保持。実行をピン留めしてより長く保持できます。
パラメータ
Script は以下のパラメータタイプをサポート:
| タイプ | 例のデフォルト | 備考 |
|---|---|---|
text | "last 7 days" | 自由形式文字列。 |
number | 0.03 | 整数と浮動小数点。 |
date | last_monday() | today()、last_monday()、first_of_month() のような式は実行時に評価。 |
timestamp | now() - interval '1 hour' | フル PG interval 構文。 |
table | data.users | パラメータが実行時にテーブルを選択。 |
enum | ["daily","weekly"] | 許可値のドロップダウン。 |
secret | @OPENAI_KEY | ワークスペースシークレットを参照。 |
Agent は Script として保存するとパラメータを自動検出。手動定義はまれです。
外部トリガーからの入力
Script はスケジュール以外のものでトリガー可能:
- Webhook POST —
https://api.tablize.com/scripts/<id>/runにスクリプトを公開。ペイロードがパラメータ入力に。 - Agent チェーン — あるスクリプトの出力が別のものの入力に。
- IoT イベント — センサーで発火する Watch が Script をトリガー可能（例: 「冷凍庫が閾値を越えたらインシデントレポートを生成」）。
これらが Script を、学ばずに済む軽量ワークフローエンジンに変える要素です。
共有
Script は:
- Private — ワークスペース内のみ。
- Team 共有 — ワークスペース内でチームメイトが実行とフォーク可能。
- 公開テンプレート — テンプレートギャラリー（Templates）に公開。他者が自身のワークスペースにフォーク。
公開テンプレートは良いパターンが広がる方法。良い候補: コホート分析、チャーンモデル、マージンレポート、週次サインアップまとめ。
よくある落とし穴
- スキーマ変更後に Script が失敗。 上流でカラムのデータ型がシフトした。一度手動実行 — Agent が UI で受け入れ可能な修正を提案。
- スケジュール実行が出てこない。 Jobs ページでスクリプトのステータスを確認。最も一般的な原因: NULL に評価されるパラメータデフォルト（例: クリアされたタイムゾーンの時刻式）。
- 遅いスケジュール実行。 全表スキャンする Script はデータ増加で遅くなります。日付フィルタを追加。実行が平均所要時間の 2 倍を超えると Agent が書き換えを提案。
- フォーク混乱。 フォークはオリジナルと自動同期しません。オリジナルにバグ修正があれば、フォークに適用する必要があります（UI が差分を表示）。