Treasure AI Studio は、見かけほど多くを最初から知っているわけではありません。モデルが持ち込むのは一般的な SQL と一般的な推論です。このプラットフォームに固有のこと — Treasure AI 独自の SQL 関数、セグメント定義が従うべきスキーマ、ジャーニーのステップに何を書けるか — のほとんどはスキルが運んでおり、どれが有効かはアカウントによって異なります。そしてあなたの業務については、誰かが伝えるまで何も知りません。自社で「アクティブ顧客」が何を指すのか、売上はどのテーブルから読むのが決まりで、どのテーブルからは読まないのか、キャンセル行は数えないのか、報告は「3つの箇条書きと数値1つ」で欲しいのか。
つまり回答は、あなたが制御できる2つの層の上に乗っています。エージェントがプラットフォームの流儀をどれだけ話せるかはスキルが決め（既定で有効なものもあれば、SQLスキルのように既定で無効なものもあります）、あなたの業務を理解しているかは指示と自前のスキルが決めます。供給されなかった部分は推測で埋められます。もっともらしい推測と正しいことは違います。
回答が安定しない原因はここにあり、プロンプトの書き方だけでは埋まりません。このページでは、回答が何によって決まるのか、なぜ同じ質問で違う結果が返るのか、そして毎回手で補わなくて済むように、どの知識をどこに置くべきかを説明します。
出力は正しいか — これはあなたのリクエスト、効いているスキル、エージェントが実行したツールの話です。その結論は導けるか — これはモデルの解釈の話であり、その下の作業がどれだけ正しく進んでも、生成されたテキストであることに変わりはありません。
回答は層の組み合わせから作られ、各層は個別に確認できます。何かがおかしいとき、有用な問いは「Studio が壊れているか」ではなく「どの層だったか」です。
| 層 | 決めていること | 確認方法 |
|---|---|---|
| あなたのリクエスト | どの対象、どの期間、どのレコードを有効とみなすか | 自分が何を頼んだかを読み直す。明示しなかったことはエージェントが代わりに選んでいます |
| カスタム指示 | 組織全体に適用される基準 | 設定 → Instructions（管理者） |
| 作業フォルダの指示 | そのフォルダ内の全チャットに効く恒常的な前提（既定のデータベース、規約、ルール） | 作業フォルダの指示を開く |
| スキル | エージェントが従う手順とプラットフォームの流儀（SQLパターン、セグメントのスキーマ、ワークフロー構文） | 設定 → マーケットプレイスで有効なプラグインを確認。カスタムスキルや共有スキルも対象です |
| 実行されたツール | 実際に行われたこと（実行されたクエリ、書かれたセグメント、生成されたファイル） | チャットのツールコールを展開し、入力と出力を読む |
| 解釈 | 要約、原因、推奨 | 回答の文章。数値はすべてツールの出力と突き合わせる |
これらがどう組み立てられて計画になるかはエージェントオーケストレーターにあります。このページで扱うのは、あなたが制御できるもう半分 — その層に何を入れるか — です。
2回尋ねて2つの異なる答えが返ることがあり、どちらも筋が通っている場合があります。理由はほぼ次の3つです。
- モデルは決定的ではありません。 同じプロンプトでも実行ごとに別の道筋を通り得ます。これはモデルの性質であって、Studioの不具合ではありません。
- リクエストで指定しきれていない要素があります。 対象・期間・除外条件を固定していなければ、実行のたびに選び直されます。
- 文脈が違います。 どのスキルが有効か、作業フォルダが何を指示しているか、会話の前段で何を話したか、エージェントが途中で何を見つけたか — そのすべてが次の一手に影響します。
あなたが取り除けるのは2つ目と3つ目だけです。そして、それを取り除く作業こそが、デモをチームで運用できるものに変えます。
固有の前提は書き留めてください。どこに書くかで、効く範囲と届く相手が決まります。
| 定義したいもの | 書く場所 | 理由 |
|---|---|---|
| このリクエスト限りの条件 | プロンプト | 再利用しないもの。対象・期間・除外条件を書いて済ませます |
| 用語の定義、そのプロジェクトで使うテーブル、常に効かせたいフィルター | 作業フォルダの指示 | そのフォルダ内の全チャットの開始時に読まれるため、誰も毎回言い直さずに済みます。フォルダ内の CLAUDE.md として保存されます |
| 組織全体で共通の規約 — 既定のデータベース、出力の体裁、意味が固定された用語 | カスタム指示 | 組織内のすべてのエージェントのシステムプロンプトに追加されます。アカウントに1つで、設定できるのは管理者です |
| 繰り返す価値のある手順 — 書くのが難しい処理のSQLテンプレート、必須の出力形式、指標の読み方、定型作業の段取り | スキル | リクエストが該当すれば自動的に適用され、チームに共有すれば、各自の我流ではなく全員が同じ手順から始められます |
最後の2つの線引きが、実務でいちばん間違えるところです。指示は恒常的な事実を述べるものです（「売上とは analytics.orders_clean のことで、status = 'cancelled' は除外する」）。スキルは手順を運ぶものです（四半期売上クエリの実際のSQLテンプレート、出力の形、解釈の手順）。指示欄に SQL や番号付きの手順を書き始めていたら、それはスキルにすべきものです。
スキルには指示にない性質が2つあります。常時適用ではなくリクエストに応じて選ばれること、そして共有できることです。誰か1人が苦労して確立した手順を、チーム全員の出発点にできます。
- 同じことで2回訂正したら、その時点で書く。 2回目の訂正は、その前提が実在していて、かつどこにも書かれていない証拠です。
- 常に真である最も広いスコープに置く。 1つのプロジェクトでだけ成り立つ規則はその作業フォルダへ、会社全体で成り立つ規則はカスタム指示へ。広すぎるスコープに書いた規則は、書かないより悪くなります。効いてほしくない場面でも効いてしまうからです。
「AIはこれが苦手だ」と見えるものの多くは、必要な知識を持たないまま作業しているエージェントです。その知識を運ぶのがスキルであり、管理するのはあなたです。
- 自分の業務に合うものを有効にする。 クエリならSQLスキル、パイプラインならワークフロースキル、CDPオブジェクトならtdxスキル。既定で有効になっていないものもあります。スキルとマーケットプレイスを参照してください。
- カスタムスキルや共有スキルもエージェントを動かすことを忘れない。 あるチームの規約に合わせて書かれたスキルは、有効にした全員に適用されます。曖昧な指示や矛盾した指示は、そのまま出力の不安定さとして現れます。
- 一度に1つだけ変える。 品質が変わったときは、プラグインを1つだけ切り替えて同じリクエストを繰り返してください。同時に複数動かすと何が効いたか分かりません。
結果に続く要約は、その結果を読んだ言語モデルが書いたものです。数値を言い間違えることもあれば、データが支持しない原因を提示することもあります。もっともらしい文であることは、その裏側の作業以上の証拠にはなりません。
抑え込むための習慣は2つです。行動の根拠にする数値は必ずツールの出力と突き合わせること。そして、頼んでいない結論が出てきたら「結果のどこがそれを支持しているのか」を尋ねること。Studioが入力欄の下に常に注意書きを出しているのも同じ理由です — AI生成の出力は不正確な場合があります。重要な情報は確認してからご利用ください。 エージェントの生成物を確認するを参照してください。
- クエリの回答がおかしいとき — 個別の数値やクエリの切り分け
- 作業フォルダ — プロジェクトの恒常的な前提を置く場所
- カスタム指示 — 組織全体に効く層
- スキルとマーケットプレイス — 手順の有効化・作成・共有
- エージェントオーケストレーター — リクエストが計画とツールコールになるまで