Model Context Protocol（MCP）でAIエージェントをワークスペースに接続 すると、配賦ステップを通じたコストのトレースを、自然な言葉で依頼できます。レポートを実行したりSQLを書いたりする必要はありません。質問するだけで、エージェントがPlaidCloudの配賦トレース用ツールを呼び出し、モデルの検索、変化の説明、チェーンのたどり、仮定の質問への回答を行います。
これは、MCPに接続された任意のクライアントで動作します。チャットエージェント（Claude Desktop、ChatGPT）でも、コーディングエージェント（Claude Code、Cursor）でも、すべてMCPサーバー を通じて同じツールにアクセスするためです。
配賦ステップ（allocation_split、allocation_rules、またはallocation_dim）を含むプロジェクト。
MCPでワークスペースに接続されたAIエージェント。AIコーディングエージェントを始める を参照してください。
エージェントへの質問 …
動作
使用されるツール
「このプロジェクトにはどんな配賦モデルがありますか？」
各モデル、そのステージ、生成される結果テーブルを一覧表示します
allocation_model_find
「cost_line_revはどのように計算されますか？」
分割されるコストプール、分割に使うドライバー、ターゲットテーブルを表示します
allocation_describe
「cost_line_revは2025年から2026年でなぜ変化しましたか？」
2つの期間を比較し、変化をプールの規模とドライバーの構成に帰属させ、寄与の大きい勘定科目を示します
allocation_root_cause
「cost_line_revは何から成り立っていますか？」
上流のチェーン（ドライバー、ソースプール、インポート）をたどります
allocation_lineage
「revenue_by_lineはどこでドライバーとして使われていますか？」
そのテーブルで分割しているすべての配賦を一覧表示します
allocation_driver_usage
「米国の収益が100万ドル増えるとどうなりますか？」
変化を、プールに占める現在の構成比で、影響を受ける各結果に分割します。ファンアウト全体で加算され、テーブルごとの最悪ケースではありません
allocation_forward_impact
「組立コストセンターの人員ドライバーが10増えたらどうなりますか？」
新しいドライバーの重みで固定のプールを再分割し、増えるターゲットと減るターゲットを示します。結果テーブルが複数のステップによって書き込まれている場合や、ドライバーがモデルの前回の実行で行った分割と一致しなくなっている場合は、配賦自身のものではないプールを再分割するのではなく、回答を見合わせます
allocation_driver_scenario
財務アナリストが、収益ドライバーによるコスト行が前年比で減少していることに気づき、1つの質問をします。エージェントは、裏で複数の配賦ツールを呼び出し、エンドツーエンドで回答します。
あなたの質問： 収益ベースのコスト配賦（cost_line_rev）が、2025年に比べて2026年に減っているようです。何が起きたのか、何から構成されているのか、米国の収益が100万ドル変動するとどうなるのかを教えてください。
エージェントの回答：
これは何か。 cost_line_revは、活動基準原価計算（ABC）モデルの収益ドライバーによるステージです。コストプール（group_amount、一連の損益計算書の勘定科目に限定）を、revenue_by_lineの収益 で、エンティティ、年、月ごとに重み付けして分割します。
減少した理由（米国、2025年→2026年）。 米国に配賦されたコストは、712万ドルから299万ドルへ、413万ドル（−58.0%）減少 しました。これは構成の変化ではありません 。プールに占める米国の割合は、両年とも約23%で変わっていません。原因はコストプール全体の縮小 で、いくつかの勘定科目に集中しています。
勘定科目
2025
2026
変化
700000
$2.58M
$1.09M
−$1.49M
701000
$1.85M
$0.77M
−$1.08M
610000
$1.71M
$0.72M
−$0.99M
670000
$0.68M
$0.29M
−$0.39M
702000
$0.30M
$0.13M
−$0.18M
この5つの勘定科目で、変動のほぼすべてを説明できます。
入力元。 cost_line_revは、revenue_by_line（分割ドライバー）とgl_pool_entity（コストプール）から構成されています。
注意：このドライバーは共有されています。 revenue_by_lineはcost_line_csとcost_line_adminも駆動しているため、収益を修正すると、3つすべてに波及します。
米国の+100万ドルのシナリオ。 100万ドルは、このドライバーを共有する結果に、それぞれのプールに占める現在の構成比 で配分されます。そのため、テーブルごとの見積もりは、それぞれが100万ドル全額を繰り返すのではなく、変化の合計に一致します 。cost_line_rev、cost_line_cs、cost_line_adminの数値が得られ、合計することができます。質問を1つのターゲットに絞ると、見積もりはその部分にのみ適用されます。
アナリストは、変化の大きさ、その背後にある勘定科目、リネージ、仮定の影響範囲という完全な回答を、1つのテーブルも開くことなく得られます。
流暢な回答が、必ずしも正しいとは限りません。「なぜ変化したか」という回答には必ず、どこまで信頼できるか を示す平易な説明が付き、もっともらしくても不確かな数値は、行動する前に 、文章に埋もれることなく明示されます。エージェントは、説明とともに次の内容を伝えます。
信頼度 — 高、中、低のいずれかで、変化がどれだけきれいに分解できるかを反映します。1つの明確な原因による変化は高、複数の原因が重なっている場合や数値が完全には一致しない場合は低くなります。結果が複数の配賦ブランチから構成される場合、信頼度は各ブランチが変化に占める割合で重み付けされるため、小さく不確かな1つのブランチが、それ以外は明確な回答の信頼度を下げることはありません。ただし、数値そのものが疑わしいブランチ（照合できない分割、古いデータ、帰属できないもの）があると、回答全体の信頼度は引き下げられます。平易な言葉での注意事項 — たとえば、原因が単一ではなく重なり合う複数の要因であること、回答が現在の 階層やドライバーの重みに基づいていること、変化の一部が実際の動きではなくデータの完全性に起因するもの（読み込みが完了していない期間）である可能性があること、配賦の入力となるプールやドライバーが最近再読み込みされておらず、数値が古いデータに基づいている可能性があること、ホワットイフの数値をターゲット間で加算できないこと、などです。実施できなかった比較の明示。 ほとんどの回答では、報告する変動の大きさを、1年前の同じ変動や直近の期間と比較するため、通常の年とトレンドの断絶を区別できます。複数の値列を一度に配賦するステップが書き込むテーブルでは、どちらの比較も、単一列の回答向けに作られているため、生成されません。以前はこれが通知されなかったため、データが許す限りの回答になっているように見えて、実際には設計上そこで止まっていました。現在は、制限事項の中に明記され、より絞り込んだ質問を代わりにする方法がない理由、およびこれによって回答内の数値が撤回されることはないという事実も併せて示されます。金額は正確であり、欠けているのは文脈です。
エージェントが正確な原因を裏付けられない場合は、確かな物語をでっち上げるのではなく、その旨を伝え、明確に回答できるようになる範囲やフィルターを案内します。また、信頼度と注意事項は回答の一部であるため、一緒に引き継がれます。別のエージェントに要約を依頼しても、信頼性を示すシグナルが黙って失われることはありません。
基になるデータが一定の期間内に再読み込みされていない場合に信頼度を下げる鮮度の注意事項は、デフォルトではオフ で、管理者がワークスペースごとにオンにします。管理者は、どの程度の新しさを新鮮とみなすかも設定します（四半期ごとや年ごとにしか更新されないデータでは、より長くします）。チームが意図的に古いデータを扱っている場合は、誰かがオンにするまで影響しません。
オンにすると、ウェアハウスを読み取るすべての回答に適用されます。「なぜ変化したか」の説明と、2種類のホワットイフの回答が対象で、後者が最も重要です。ホワットイフは、モデルが前回の実行で実現した構成比を使って伝播または再配分を行うため、古いデータでは見積もりの信頼性が最も低くなります。
この機能が伝えられる内容には2つの制約があり、ホワットイフだけでなく、すべての回答に当てはまります。1つ目は、年齢を確認するのは、PlaidCloudに直接ロードされた テーブルだけだということです。ワークフローのステップが構築するテーブルは、そのステップが最後に実行された時刻しか報告できず、これはデータが到着した時刻とは別の問題です。そのため、誤った数値で回答するのではなく、意図的に確認しません。2つ目は、各種類で最も古いテーブル （1つのプール、1つのドライバー）の名前を示すことです。したがって、ホワットイフが複数のステップに広がり、古いドライバーが複数ある場合、通知されるのはそのうちの1つです。どちらの場合も、古いテーブルを新鮮と報告することはありません。
配賦のソース行が制限されている場合（たとえば、一連の損益計算書の勘定科目に限定）、エージェントはそのフィルターを自動的に適用し、それでもプール全体の明確な帰属を示します。何も追加する必要はありません。
結果テーブルが複数の 配賦ステップによって生成される場合、エージェントはどれが変化の原因かを推測せず、候補のステップを一覧表示して、どれを指すかを尋ねます。質問が、それらのステップのうち1つだけが生成した行（たとえば、それだけが配賦する地域）に絞られている場合は、エージェントがそれを認識して、そのステップを自動的にトレースし、その旨を伝えます。
ステップを指定すると、どのステップを説明するかをエージェントに伝えることになりますが、どの行を測定するかは決まりません。 報告される変化はテーブル全体のもので、正確です。1つのステップに帰属できないのは要因間の内訳 であるため、複数のライターを持つテーブルでは、エージェントはその内訳を見合わせ、数値がテーブルに書き込むすべてのステップを対象としていることを伝え、他のステップを順に通してテーブルをトレースすることを提案します。こうした再実行はそれぞれ個別の測定です。見ている変化に占めるそのステップの割合でもなく、そのステップのみ の測定でもありません。これらのステップは同じ列に書き込むため、内訳が見合わされており、返ってくる変化はそれらすべてを対象としています。
これは、他のライターが何であっても 当てはまります。配賦ではないステップ（たとえば、結果テーブルに行を追加するステップ）は、トレースの候補にならないため、選択を求められることはありませんが、その行は同じように合計に含まれています。エージェントは、その動きを内訳に折り込むのではなく、その旨を伝えます。
「このプールが…増えたらどうなりますか」という回答は、変化を、各ターゲットのプールに占める現在の構成比 でファンアウト全体に分割するため、テーブルごとの数値は、それぞれが最悪ケースの上限になるのではなく、合計が一致します 。これらはモデルの現在の構成比を反映したものであり、変化がどこに及ぶかを適切な範囲で見積もったもので、正確な予測ではありません。入力プールではなくドライバーまたは基準 テーブルを指定した場合は、ドライバーの変更は値を追加するのではなく固定の分割を並べ替えるため、ドライバー のホワットイフ（後述）として扱われます。
このケースでは、期間を明示してください。 「なぜ変化したか」の質問やドライバーのホワットイフとは異なり、フォワードのホワットイフでは、期間列を自動的に判別しません 。指定しないと、見積もりは、想定していた期間ではなくすべての期間 を対象にします。
フォワードのホワットイフは、各ターゲットの構成比を、それを書き込むステップに問い合わせて算出します。そのクエリが失敗した場合（ステップのテーブルに期間列がない、ウェアハウスに拒否されたなど）、そのターゲットは、理由とともに見積もりをまったく報告しません 。以前は、そのターゲットに到達する変化の全体 を報告しており、これは測定された回答とまったく同じ見た目で示される最大値でした。そのステップより下流のすべてがそこから見積もられていたため、ブランチ全体が通常の数値のように見えていました。
その結果として、次の3点があり、回答はそれぞれを明示します。合計は、測定されたターゲットのみ を対象とします。測定できなかったステップの下流は、そこから見積もられることはないため、それらのターゲットは推測されるのではなく回答から除外されます。書き込むものの一部 からしか測定できなかったターゲットは、その旨と、読み取れなかったステップの名前を示します。その部分的な数値は、読み取れたものの実際の測定値なので有効ですが、ターゲット全体ではなく、欠けている部分はそれより大きいか、小さいか、符号が逆である可能性があります。下限として読まないでください。
ドライバー の変更で何が起きるか、たとえば「組立コストセンターの人員ドライバーが10増えたらどうなりますか？」と尋ねると、エージェントは、モデルを再実行することなく、新しい重みで固定のプールを正確に 再分割します。増える ターゲットと減る ターゲットが示され、組み込みのチェックとして、増減の合計はゼロになります 。正確に計算できるもの、つまり単純なドライバーによる単一の分割のみを対象とします。それ以外の複雑なもの、たとえば階層ベースやフィルター付き／条件付きの配賦、まったく新しいドライバーメンバーの追加、グループが空になる変更は、見積もられるのではなく、理由とともに回答が見合わされます 。
列は、ドライバーテーブルでの表記のとおりに指定してください。 ステップがドライバー列を別の名前で引き継いでいる場合は、ドライバーテーブル自体の名前で質問する必要があり、間違えた場合は、回答がその名前を引用して返します。結果では逆になります。動いたコストセンターとグループは、結果 テーブルでの表記で示されます。フィルターや結果の読み取りに使う名前だからです。ほとんどのステップでは、この2つは同じ名前です。
フィールドで変化を内訳すると、同じ値を共有する行が集められますが、値がない 行もまとめて集められます。そのため、比較する期間のすべての行で空のままのフィールドでは、変化全体を含む単一のグループが生成され、最も集中した結果、つまり1つのメンバーが動き全体を占め、信頼度も満点という結果に見えていました。
エージェントは現在、それらの行でフィールドが入力されていないことを伝え、集中度の数値を100%と報告するのではなく見合わせます 。入力されているフィールドを使うか、内訳をまったく行わないことを提案し、後者の場合は、変化を最もよく説明するフィールドを自分で探します。2つ目のグループ化フィールドが入力されている場合は、内訳は本物であり、通常どおり報告され、空のものはその旨が記されます。空の値は*(no value)または (blank)*と表示され、両者は区別されます。一度も入力されなかったフィールドと、明示的に何もない値に設定されたフィールドは、別のものです。
影響を受けたのは内訳のみです。見出しの変化、その合計、帰属の方法は、常に正しいものでした。
フィールドを指定しない場合、エージェントは変化を最もよく説明するものを選びます。そして、答えがそのフィールドの値がまったくない 行であることもあります。これは不具合ではなく本物の検出結果なので、隠されずに報告されます。静かにタグ付けされなくなったコストは、知っておく価値があります。
しかし、「未割り当ての行が増えた」ことの意味は、ほぼ常に入力されているフィールドと、ほぼ常に空のフィールドとでは大きく異なります。回答には現在、同じ文の中でどちらかが示されます。「勝った切り口はcost_centreの未割り当ての行です。cost_centreは、比較した期間の行の12%に値があります」 。12%の行に入力されているフィールドはほとんど使われておらず、95%に入力されているフィールドには、追跡する価値のある本物のギャップがあります。非常に疎なフィールドと非常に充足しているフィールドは、ここでは0%や100%のどちらもあり得ないため、1%未満 や99%超 と表示されます。
検索の前に、エージェントはデータに対して簡単な確認を1つ行い、全体で単一の値しか持たないフィールドや、細かく分割されすぎてグループ化として成り立たないフィールドを除外します。この確認に回答できない場合（ウェアハウスが測定できない列の型、接続の切断など）、以前はすべてのフィールドを検索しており、すでに何か問題が起きているまさにその時点で、2つの制限が両方とも解除されていました。
現在は、検索が実行されなかったことを、独自の表現で伝えます。これは検索の制限であり、データに関する検出結果ではありません。この表現は、比較する期間が大きすぎて検索できない場合の注記とは異なります。対処方法も異なるためです。その場合は期間を絞り込みますが、この場合は、調べたいフィールドを指定します。これは原因を問わず有効です。再試行が役立つのは、障害が一時的なものだった場合だけです。
テーブルにないフィールドでの内訳を求めると、その旨と、テーブルにある フィールドが示されるため、1回の操作で質問を修正できます。以前は、内訳だけが欠けた状態で、完全で確かな回答が返され、内訳が試みられたことを示すものは何もなく、「さらに進むには」という提案は、まったく別の場所を指していました。実際のモデルでは、4つの連続した質問がこのように返されました。
チェーンのさらに上流では、意図的にルールが異なります。配賦によって追加されたフィールドは、その下流のテーブルにしか存在しないため、質問したテーブルにあるフィールドが、2段階前では実際には存在しないことがよくあります。その場合、トレースは、そのステージの内訳を失うのではなく、そのステージにあるフィールドでグループ化 し、省略したものを通知します。
その注記は前のステージに関するもので、その旨が記されます。「求められた内訳は、このステージでは使用できませんでした」 。回答に表示されるメンバーのテーブルに関する ものではありません 。それは、質問したテーブルを、求めた完全なグループ化で示したものです。前のステージのより粗いグループ化は、そのステージ自身の集中度の数値が測定される基準であり、そのメンバーは一覧表示されません。それに付随する提案でも、そのステージが示されます。メンバーも必要な場合は、トレースしたすべてのステージが持つフィールドでグループ化してください。2026年8月までは、注記は「is not in this answer」となっており、*「so the members you see are grouped only by the rest」*と説明され、提案では、そのフィールドが「トレースしたテーブル」にないとされていました。これは、表示されたテーブルを指しており、実際とは異なるものとして説明し、正常に機能していたフィールドを削除するよう助言していました。
また、内訳が他の理由（一時的なウェアハウスの障害など）で欠けている場合も、回答は同じ形で、内訳を生成できなかったステージの名前とともに、その旨を伝えます。合計は測定されており、影響を受けません。再試行も提案されます。欠けているのは詳細であり、誤りではありません。
2つの期間の間で合計が正から負に動いた場合（たとえば、純粋な費用だったコストセンターが純粋な収益になった場合）、動きを原因ごとに分ける意味のある方法はなく、意味のある割合もありません。小さな正の値から大きな負の値への変動は、−10,013%のような、何も測定していない数値になります。
エージェントは、従来どおり、このような変化の配賦を見合わせます。現在は、測定方法に関する一般的な注記から始めるのではなく、その旨 を理由として伝えます。以前の注記は、あたかもそれが説明であるかのように読め、直後に表示される行と食い違っていました。ゼロをまたいだ変化の割合は、まったく表示されなくなりました。両側の金額と変化そのものは、正確で影響を受けません。
2つの期間は別々の数値として読んでください。回答は現在、回答を見合わせる行に両方を表示し、質問したスライスなのか列全体なのかを示します。何が動いたかを確認するには、内訳ディメンションを追加します。ゼロをまたぐ合計は原因に分割できませんが、その背後にあるメンバーごと の動きは通常どおり読み取れ、多くの場合、答えはそこにあります。
すべての回答は、実行できる次のステップで終わります。以前は、2つの状況で何も提案されず、そのどちらも最も行き詰まりやすい場面でした。ゼロをまたいだ合計と、エージェントがまったく集計できなかったステージです。現在はどちらにも提案が付き、後者では、確認すべきテーブルと最も可能性の高い原因（そのステージのテーブルに期間列がない）が示されるため、一時的なウェアハウスの障害を疑う前に、それを除外できます。
同様に、すでに質問を1つのメンバーに絞っている場合は、回答がメンバーへの絞り込み を提案することはなくなりました。そのアドバイスは、質問した内容ではなく、チェーンのさらに上流で記録された制限から来たもので、ここにも当てはまるかのように、記載された制限の中で繰り返されていました。
次善のケースが1つだけ、引き続き次のステップを提案しません。ドライバーテーブルの独立した読み取りが、実現した分割と食い違う場合、回答はその旨を伝えますが、それを解決する再実行は提案できません。その場合に有効なのは、ドライバーテーブルを直接調べることで、これはこの質問の調整ではなく、別のリクエストです。
テーブルは名前 （cost_line_rev）またはIDで指定します。どちらも使用できます。
変化に関する質問では、比較する期間 （たとえば2025年と2026年）を指定し、必要に応じて、勘定科目やエンティティなどの内訳 ディメンションを指定します。
広い質問（「このプロジェクトにはどんな配賦モデルがありますか？」）から始めて、掘り下げていきます。エージェントは会話の流れを保持するため、追加の質問は同じモデルを土台にします。
ホワットイフには2種類 あります。値 の変更（「このプールが100万ドル増える」）は現在の構成比で見積もられ、ターゲット間で合計が一致します。ドライバー の変更（「このドライバーの重みを変える」）は正確に再分割され、合計はゼロになります。意図する方に合わせて質問を組み立ててください。
