信頼できる回答

どんなAIでも、数値について自信たっぷりの文章を書くことはできます。難しいのは、その回答に基づいて行動してよいかどうかを左右する部分、つまりいつ信頼してよいかを知ることです。PlaidCloudはまさにそのために作られています。

接続したAIアシスタントにデータの説明を求めると、PlaidCloudは数値を返すだけでは終わりません。その数値をどの程度信頼できるかを評価し、根拠が弱い部分を平易な言葉で伝え、自身の計算を突き合わせ、何も作り話をしません。これが、それらしく聞こえるアシスタントと、CFOの前に出せるアシスタントとの違いです。

すべての回答に信頼度のシグナルが付く

PlaidCloudは自身の回答を高、中、低の信頼度で評価し、その理由も伝えます。完全に帰属できたクリーンな結果は「高」で返されます。比較する2つの期間の完全性が同じでない場合や、変化の一部を単一の原因に特定できない場合は、PlaidCloudがそのことを伝え、不確かな数値を確かなものとして提示する代わりに自身の信頼度を下げます。

アシスタントが確信しているかどうかを気にする必要はありません。回答の冒頭で伝えられます。

評価は、何を対象にしているかを明示します。 回答は1行の要約で始まります。そこでは、考えられる原因の名前を挙げたり、変動の大半を生んだメンバーを示したり、前年との比較で変化の大きさを示したりできます。そして最後に信頼度の評価で締めくくります。この評価が対象とするのは1点だけです。つまり、変化をそれに寄与した要素へどのように分解したか、そしてそれを生み出したステップまでどのようにさかのぼったか、という点です。上に挙げた原因そのものについての判定ではありません。現在は行にその旨が明記されており、*「分解についての信頼度であり、変動の理由についての信頼度ではありません：高」*のように表示されます。要約が原因を挙げていない場合は後半が省かれるため、述べていない主張を否定することはありません。この点が重要なのは、要約が単独で転送されたり、周囲のページを持たないアシスタントに読まれたりする可能性が最も高い部分だからです。

評価に条件を付ける内容は、独立した1文として続き、「注意事項：」という見出しが付きます。以前は、評価とその条件がダッシュでつながれていました。ダッシュは「なぜなら」と読めるため、高い評価の後にダッシュと制限が続くと、評価がすぐ隣の制限そのものに依拠しているように解釈されました。現在は2つの文に分かれており、両者の間に関係があるとは主張しません。条件の内容自体は変わらず、回答の下部にこれまでどおり詳しく記載されます。

評価を下げた理由は、評点への脚注ではなく、明示された制限です。 変化の一部が、単一の要因ではなく複数の影響が同時に動いたことに由来する場合、その割合が評価を「高」未満にとどめる要因になります。これは正直な制限事項に、その意味と何に関わるかとともに、回答が抱える他のすべての制限と並べて記載されます。評価自体は短いラベルのままです。複数の列を対象とする回答では、単一の数値ではそのすべてについて述べたことにならないため、評価の行にそれらの列にわたって測定した範囲が示されます。

列ごとに結果が異なる場合、理由はそれを最も必要とする列のものになります。 以前は、同じ評価を受けた複数の値の列を対象とする回答で、最初に現れた列の理由とその列自身の残差割合が、回答全体のものとして採用されていました。そのため、最も問題のある列の変動の大半が、個々の要因では説明できない部分にあっても、小さな割合を添えて「ほぼクリーン」として公開されることがありました。いずれかの列の変動が分離できない影響に支配されている場合は、現在はそれが示される理由となり、他の列で測定した割合は併記されません。

変化が反対方向の動きで相殺されたと述べながら、同じ分解をクリーンと評価することはありません。 あるメンバー自身の変化が正味の変化全体より大きくなる場合、両方向の動きが部分的に打ち消し合っています。そのメンバーを挙げる行は、メンバーの変化が正味をわずかに超えた時点でそう述べていましたが、隣の評価がその相殺を重要なものとして数えるのはそれよりかなり先でした。そのため、最大のメンバーが正味をわずかに上回っただけの回答が、動きが相殺されたと述べながら、同じページで同じ分解をクリーンと評価することがあり、どちらを信じるべきか分かりませんでした。現在この行は、相殺が評価を下げるほど大きい場合にのみ、動きが互いに相殺されていると述べます。それ未満の場合は、代わりにそのメンバーの割合を示します。たとえば*「line=PERSONAL_AUTO = デルタの101.6% — これはプールにおける持ち分の変動ではなく、そのメンバー自身の変化です」*のように表示し、100%を超える場合は小数点以下1桁まで示すことで、100%をわずかに超える分が丸めによって歪まないようにしています。相殺が重要な回答の表示は従来どおりで、どの要因が動いたかを示す別の行も変わりません。

回答が制限を抱えている場合、要約は必ず信頼度を述べます。 以前は、回答の背後のどのステップも固有の警告を出さなかった場合、評価が一切省かれていました。これは、回答全体としては前年との比較で変化の大きさを示せないなどの制限を抱えている場合でも同じでした。この行は単独で転送されることが最も多いため、その沈黙は「制限は下に記載されている」ではなく「伝えることはない」と受け取られていました。現在の要約は評価を述べ、制限も明示します。*「分解についての信頼度：高。注意事項：この変動は前年の変化との比較では測定されていません。」*回答に示すべきことがなければ、従来どおり何も付けずに終わります。

示された深さは、そのうちどれだけが数値を伴っていたかを示します。 要約の最後には、回答が何ステップさかのぼったかが記されます。この件数は、回答がどこまで到達したかを示す行内の唯一の情報であるため、読み手はそれを裏付けとして受け取ります。しかし、トレースが到達したものの数値が返ってこなかったステップは、裏付けにはなりません。トレースしたステップのいずれかが空で返った場合、現在の行はそのうち何件が数値を返したかを示します。*「上流を2ステージたどりました。数値が返ったのは2件中1件のみで、残りには数値が一切ありません。」*変化が測定されたものの単一の生成元ステップに特定できなかったステップは、測定された変化が証拠となるため、引き続き数に含まれます。特定できなかったことは、正直な制限事項に別途記載されます。すべてのステップが数値を返した要約は、従来どおりの表示です。

注意すべきときを教えてくれる

PlaidCloudは、前提を埋もれさせる代わりに、回答に添える平易な注意書きとして示します。

回答が示す内容	意味
「これはプール全体を表しています」	この数値は合計です。メンバー（地域、製品、コストセンターなど）の間でどのように変動するかを見るには、特定のメンバーについて質問してください。この注意書きは、回答にメンバー別の内訳が表示されない場合にのみ表示されます。内訳が表示されている場合、この注意書きは当てはまらないため出力されません。注意書きがチェーン内の前のステップを指す場合（「ステージ2（…）」で始まります）、質問を絞り込んでもそのステップには届かないため、そのステップ自体のテーブルをトレースしてください。
「期間の完全性が同じではありません」	一方の期間が月の途中までだったり、短い期間だったりする可能性があり、変動の一部が実際の変化ではなくデータの欠落である可能性があります。引用される行数は結果全体のものです。複数の配賦ブランチを再結合するテーブルでは、すべてのブランチを合算した行数になります。
「各要素が完全には整合していません」	詳細な内訳の合計が見出しの数値と完全には一致しません。この分割は正確なものではなく、目安として扱ってください。
「正確な原因は部分的です」	合計は正しいものの、変化の正確な要因は手元のデータからは完全には特定できません。
「一部のターゲットを測定できませんでした」	ホワットイフ分析で、あるステップの計算が失敗したため、そのステップが書き込む結果には推測値ではなく数値が一切ありません。合計は測定できたものを対象とし、そのステップの下流にあるものは、そこから推定するのではなく除外されます。
「現在のシェアに基づく推定」	ホワットイフの推定は、影響を受ける結果の間で、変化を各結果の現在のプールに占める割合に応じて分割します。そのため数値は合計と一致しますが、これはモデルが現在どのように構成されているかを反映したものであり、シェアが変動しているかもしれない将来の正確な予測ではありません。

これらは細かい注意書きではありません。自信ありげな回答が、データが実際に裏付ける内容を知らないうちに誇張してしまうのを防ぐための安全策です。

結果の一部だけを説明する注意書きは、どの部分かを明示します。 注意書きは結果全体ではなく、結果の一部によって発生することがあり、その場合、数値はその部分にのみ属します。そのため、注意書きはまずその部分を名指しします。複数の配賦ブランチを結合した結果では*「ブランチ4（管理コスト）：…」と表示され、複数の値の列を同時に配賦する結果では「列margin：…」*のように列が示されます。接頭辞のない注意書きは、質問した結果全体についてのものと読み、接頭辞のある注意書きは、その部分についてのものと読んでください。

複数の部分に当てはまる場合は、そのすべてを挙げます。 *「列revenue、margin：…」*のようになります。したがって、その一覧にない列は、その注意書きが当てはまらない列です。これが一覧を載せる目的です。3列の結果のうち2列が同じ注意書きを共有している場合、一方だけを挙げるともう一方は対象外のように読めてしまいます。すべての部分で発生した注意書きには接頭辞が一切付きません。区別すべきものがないからです。

1つのケースだけは、意図的に異なる表示になります。各部分がそれぞれ独自の数値でその注意書きを発生させた場合、表示される注意書きは1つの部分のものであり、複数の名前を1つの部分の数値の前に並べると数値の帰属を誤らせてしまいます。そのためその部分を名指しし、他の部分をその後ろに列挙します。*「列revenue（marginでも発生）：…」*のようになります。この文の数値はrevenueのものです。marginも同じ種類の注意書きを、自身の数値で発生させています。

何を比較したかを示し、それを時間とは呼ばない

数値がなぜ動いたかを尋ねるには、その間で比較する2つのものを指定する必要があります。通常は2つの期間で、先月と今月、2025年と2026年などです。回答もそれを前提に書かれており、期間の名前を挙げ、変化を1年前の同じ期間と比較して大きさを示し、一方の期間がもう一方より完全でないように見える場合は警告します。

しかし、比較する2つは期間でなくてもかまいません。シナリオ、バージョン、ケース、または予算と実績に比較を向けると、両者の違いについて、どちらが動いたか、何がそれを動かしたか、どのメンバーがそれを担っているかを、まったく問題のない形で説明する回答が得られます。これは機能しますし、活用する価値があります。

問題だったのは、その周辺の言い回しでした。バージョン7とバージョン8を比較したとき、回答は1つさかのぼってバージョン6との差で変化の大きさを示す「前年比」の判定を報告しました。*「昨年の変動の275%の大きさ。6 → 7は-$400,000変動」*というもので、含まれる数値はすべて正しいのに、文の主題が間違っていました。2つのバージョンを期間であるかのように扱い、行数の少ない方をまだ読み込み中かもしれないと述べていたのです。

現在は、比較に使う列が期間かどうかを、列の型、名前、指定した値の形から判断します。期間でない場合は次のようになります。

冒頭の行は比較した期間ではなく、比較した値と述べ、列とその2つの値を挙げます。
前年との判定は示されません。さかのぼる前年が存在しないためで、説明なしに比較を未測定のままにするのではなく、正直な制限事項でそのことが述べられます。撤回される数値はありません。
両側の行数の違いは、期間がまだ読み込み中かもしれないという話ではなく、各側が対象とする範囲の違いとして説明されます。2つのシナリオの間では、小さい側が意図したものであることがよくあります。どちらが少ないかは、比較した値と行数の両方が表示される順に従って、1つ目の側または2つ目の側として示されます。以前は「薄い側」と呼んでいましたが、これは行数が少ないことで定義されるため、短い側は短い、としか言っていない文になっていました。冒頭の行でも、以前は「後の側」と呼んでいた箇所を同じ方法で示します。カレンダーのない比較に、カレンダーの言葉を使っていたためです。

判定は意図的に慎重です。型がそう示している場合、または名前がそう示している場合、または指定した値が日付、月、四半期、年のように見える場合に、列は期間とみなされます。どれか1つで十分なので、整数のfiscal_yearも、テキストの2026-03も、引き続き期間として読み取られ、日付、期間、月、四半期、年の列にまたがる比較は変わりません。

どの母集団を測定したかを示す

1つのテーブルに対する2つの回答は、似て見えても意味がまったく異なることがあります。一方はすべての行を対象とし、もう一方は単一の事業ライン、エンティティ、プログラムを対象としています。続けて読むと、絞り込んだ数値は広い方の数値の一部だと簡単に思い込まれますが、そうとは限りません。除外されたメンバーは逆方向に動くことがあり、場合によっては絞り込んだ変化がテーブル全体の変化より大きくなるほどです。

各回答は、冒頭の行でそのどちらであるかを述べます。絞り込んでいない回答は、その数値が各期間におけるテーブル自身の合計であり、すべてのメンバーを含むと述べます。絞り込んだ回答は、その数値が各期間におけるそのメンバー自身の合計であり、テーブルの残りは除外していると述べ、さらに数値が正の場合は、その割合がより大きなものの持ち分を測るものではなく、その2つの合計を比較したものだと述べます。絞り込んだ回答の数値が両端で負の場合は、この最後の注記は省かれます。回答はすでに残高がゼロよりさらに下回ったことを伝えており、そこでその割合を通常の比較と呼ぶと要点がぼやけてしまうためです。

どちらの行も、除外されたメンバーがどのように動いたかについては何も述べません。回答はそれらを測定していないため、特徴づけることもしません。

絞り込んでいないという行は、回答がすでに自身の作業内の欠落を報告している場合は省かれます。複数の配賦を再結合するテーブルに関する質問は、ブランチごとに回答されます。そのうちの1つのブランチが帰属できなかった場合、回答はその旨を下で述べます。その上の冒頭の行で「すべてのメンバーを含む」と述べると、何も除外されていないという主張として読まれてしまいます。再結合されたテーブル自身の変化が読み取れなかった場合も同様で、その場合、行が説明すべきテーブル全体の数値は存在しません。

絞り込みを適用できなかったときに示す

絞り込みは列を指定しますが、回答が報告するテーブルにその列がない場合があります。ない場合、フィルターする対象がないため、クエリは絞り込まれずに実行され、返ってくるすべての数値はテーブル全体を対象とします。

以前は、ページ上にそのことを示すものが何もありませんでした。回答は、絞り込みを挙げるすべての場所で絞り込みを挙げ続けていました。冒頭の文、上記の母集団の行、テーブル全体ブロックの見出し、メンバー一覧の見出し、要約の行、そして最後のステップごとの説明の6か所です。6か所すべてが、数値の対象ではない母集団を挙げていました。さらに、絞り込んだ数値をそのテーブル全体と比較するためのブロックは、比較を謳う見出しの下に同じ数値を2回表示していました。そのページを見ても、読み手は、尋ねたメンバーがたまたま事業全体である場合のテーブルと区別できませんでした。

現在、回答は数値より前に、まずそのことを述べます。

結論： entity=DEを分離できませんでした（cost_line_adminにはentity列がありません）。そのため、これはテーブル全体の数値です。合計は26.2%減少しました（$4,200,000.00から$3,100,000.00へ）。

訂正が先に来て、数値はその従属になります。冒頭の行は単独で転送される可能性が最も高く、数値の後ろに置かれた訂正は読み飛ばされるためです。渡した設定ではなく欠けている列を名指しするため、間違った列を指定したのか、間違ったテーブルを指定したのかをすぐに判断できます。また、絞り込みを適用「しなかった」ではなく、適用「できなかった」と述べます。「しなかった」と書くとフィルターが実行されたが違いがなかったように読め、絞り込みの場合、尋ねたメンバーが事業全体であることを意味してしまうからです。

その後、絞り込みはページ上のほかのどこにも挙げられません。母集団の行も、テーブル全体ブロックも、メンバー一覧のスコープも、要約への絞り込みマーカーもありません。ステップごとの説明では、絞り込まれずに実行されたステップをフィルターしたステップとしてではなく、絞り込まれていないステップとして示します。

絞り込みが通常どおり適用された回答は変わらず、どちらの場合も数値は動きません。

テーブルが複数の配賦を再結合している場合、ブランチは別々のテーブルであり、違いが生じることがあります。1つがその列を持ち、別の1つが持たない場合です。その場合、絞り込めたブランチを残りの代表とするのではなく、回答は絞り込みを母集団としてどこにも挙げません。ステップごとの説明は、絞り込まれたブランチと絞り込まれなかったブランチを引き続き区別します。何が起きたかは回答自身の言葉で述べられます。以下の再結合されたテーブルで絞り込めたものと絞り込めなかったものを示すを参照してください。

絞り込みのどの部分が適用されたかを示す

絞り込みは複数の列を指定でき、テーブルにはその一部の列があって他にはないことがあります。lob列はあるがregion列がないテーブルで、lob=COMMERCIALとregion=WESTについて尋ねると、数値は事業ラインで絞り込まれ、すべての地域を対象として返されます。

それは有用な回答であり、実際に得られるものです。以前のページは、それをあたかも両方が適用されたかのように報告していました。冒頭の文、母集団の行、テーブル全体の見出し、メンバー一覧の見出し、要約の行、ステップごとの説明のすべてでregion=WESTを挙げていましたが、並ぶ数値は地域で一度もフィルターされていませんでした。すべての数値は正しく、それらが何を対象としているかについての記述はすべて誤っていました。

現在の回答は、数値を実際に絞り込んだものだけを挙げ、何が絞り込まれなかったかを述べて始まります。

結論： regionを分離できませんでした（cost_line_adminにはregion列がありません）。そのため、これらの数値はregionのすべての値を対象としています。lob=COMMERCIALの合計は26.2%減少しました（$4,200,000.00から$3,100,000.00へ）。

何も言わずにlob=COMMERCIALで絞り込むことは、それ自体が、回答が求められたものを対象としているという主張になります。そのため、ページは読み手が引用する2か所、つまり冒頭の行と、下部の正直な制限事項の一覧に、不足している点を記載します。後者には、数値が実際に測定された母集団も記載されます。

名前は挙げたが値を一切指定していない列も、同様に扱われますが、原因が異なるため言い方が異なります。列はテーブルにあり、欠けているのは値です。この場合、回答はフィルターが列を指定したが値を与えなかったと述べます。不足したのはデータではなくフィルターであり、列が存在しない場合とは異なり、質問し直すことで解決できます。

ステップごとの説明は、絞り込まれずに実行されたステップについてすでに使っていた語彙で、ステップごとに同じ区別を示します。

ステージ1（配賦）：cost_line_admin [cost]（lob=COMMERCIAL、regionのすべての値）— デルタ-$1,100,000.00。

テーブルが複数の配賦を再結合していて、ブランチ間でその列についての状況が異なる場合、回答はその列がないテーブルとして特定の1つのブランチのテーブルを挙げることはしません。それを持つブランチが1つもない場合は、「すべてに存在するわけではない」を、いくつかのブランチは結局絞り込まれたという意味に読ませることなく、はっきりそう述べます。一部が持っている場合は、各列を別々に、すべてのブランチのテーブルにあるわけではない列として挙げます。「すべてのテーブルにlobまたはregion列があるわけではない」は、各テーブルがそのどちらかを持っているページについては事実に反するからです。

この区別は、回答がその後に何を対象とすると主張するかに関わります。その列を持つブランチは、尋ねた値に実際に絞り込まれています。したがって、数値がその列のすべての値を対象としていると述べると、一方のブランチについては正しく、もう一方については誤りになります。そう伝えられた読み手は、求めたものの一部である数値を破棄してしまうかもしれません。そのため、回答は代わりに、絞り込みは各ブランチのテーブルが許す場合にのみ、そのブランチに及んだと述べます。

結論： regionを分離できませんでした（east_linesにはregion列がありません）。そのため、各ブランチはそのテーブルにregion列がある場合にのみregionで絞り込まれています。lob=COMMERCIALについて、再結合された2つのブランチ全体で、2つすべてが減少しました。

「すべての値を対象とする」という表現は、それが実際に当てはまるケース、つまり列を持つブランチのテーブルがなく、どこでも何も絞り込まれなかった場合のために残されています。

代わりに何で絞り込めるかを示す

絞り込みを適用できない回答は、以前はそう述べるだけで終わっていました。実行できないフィルターを偽装しなかったことは正しい拒否ですが、目の前の数値が求めたものではないと分かるだけで、代わりに何を求めればよいかは何も示されませんでした。

現在は、そのテーブルが実際に持つ列を、推測ではなくテーブル自体から読み取って最後に示します。

さらに絞り込むには： スライスを分離するには、cost_line_admin自身の列（account、cost_center、product）のいずれかを指定したtarget_filterと、その列の値を使って質問し直してください。

この一覧は、アシスタント自身が切り口を探すときに検索するものなので、示される列は回答が実際に扱えるものです。完全なスキーマ一覧ではなく提案です。名前が回答自身の制限の文言と衝突する列は省かれ、提案の中の何かが、回答が述べている制限と誤認されないようになっています。

テーブルに存在する列を指定したが値を指定しなかった場合、その列が提案の先頭に置かれます。ページを直す質問し直しが、アルファベット順の一覧に埋もれないようにするためです。

さらに絞り込むには： entityはcost_line_adminの列ですが、entityの値だけが指定されていませんでした。スライスを分離するには、cost_line_admin自身の列（account、cost_center、entity、product）のいずれかを指定したtarget_filterと、その列の値を使って質問し直してください。

テーブルにない列と、あるが値のない列の両方を指定した場合、回答は両方に1つの理由を挙げるのではなく、それぞれの失敗をそれ自身の原因とともに挙げます。後者は回復可能な方であり、最初の理由を後者にも当てはめる読み手は、うまくいくはずの方法を試すのをやめてしまいます。

絞り込みが適用された回答は変わりません。そのような助言は不要であり、示されません。

再結合されたテーブルで絞り込めたものと絞り込めなかったものを示す

複数の配賦を再結合するテーブルは複数のテーブルであり、それぞれが独自のスキーマを持つため、絞り込みが一部のブランチには届いても他には届かないことがあります。これは特殊なケースではなく、ユニオンが存在する通常の理由です。

どちらのパターンも、以前は絞り込みをどこにも挙げず、何も説明しないページを生んでいました。現在はそれぞれ異なる表示になります。異なる状況であり、両方に当てはまる文ではどちらも伝わらないためです。

どのブランチのテーブルにもその列がない場合は、どこでも何も絞り込まれていません。

結論： regionを分離できませんでした（regionという名前の列を持つブランチのテーブルはありません）。そのため、これらの数値はregionのすべての値を対象としています。合算した合計は26.2%減少しました（$8,400,000.00から$6,200,000.00へ）。再結合された2つのブランチ全体で、2つすべてが減少しました。

一部のブランチが絞り込まれ、他は絞り込めなかった場合、回答はそのことを述べ、別の場所で引用される可能性が最も高い数値である合算した合計に印を付けます。

結論： region=WESTは一部のブランチには届きましたが、他には届きませんでした（east_linesにはregion列がありません）。そのため、これらの数値は、そのスライスとテーブル全体が混在したものです。合算した合計は26.2%減少しました（$5,100,000.00から$3,740,000.00へ）が、これはregion=WESTの数値ではありません。再結合された2つのブランチ全体で、2つすべてが減少しました。

その下のブランチごとの一覧は、各ブランチを書き込み先のテーブルで示すため、冒頭で挙げられたブランチは一覧の中で見つけられます。

絞り込みがすべてのブランチに届いた再結合回答は、従来どおりの表示です。

テーブル全体がどう動いたかを示す

1つの事業ラインの数値だけでは、ほとんど意味がありません。6.2%縮小した全体の中で4.2%成長したラインは、成長した全体の中で成長したラインとは異なる話ですが、同じ数値がどちらも表します。以前の絞り込んだ回答は、その数値を示すだけで比較は読み手に任せていました。その一方で、絞り込んだ変化を比較した対象として、テーブル全体の変化を名指ししていました。

そのため現在の絞り込んだ回答は、自身の数値の隣に、報告する各列について、同じ期間にテーブル全体がどう動いたかを並べて示します。絞り込まれた行はその合計の一部であり、回答は読み手に計算させず、そのことを述べます。符号が一致しない場合、つまりそのラインが期間の両端で負であるのにテーブルは両端で正である場合は、見落としかねないマイナス記号に任せず、言葉で述べられます。

そのために新たに測定するものはありません。テーブル全体の数値は、絞り込んだ変化を比較した対象として元々使われていたもので、これまで表示されなかっただけです。

ただ、2つの数値が並んでいても、引き算は残ります。そして物語を伝えるのはその引き算です。テーブル全体の上昇幅を上回って上昇したラインは、そのライン以外のすべてが下がったことを意味します。つまり、そのラインは逆方向に動くプールの中でシェアを伸ばしたのであり、上昇する数値が単独で読まれる場合とは逆の意味になります。そのため、絞り込まれた行の外側の動きがそれらと逆方向である場合は、回答がそれを述べます。金額、その方向、そしてそれが属する列です。同じ方向に動く場合、これが通常のケースですが、何も追加されません。ラインと同じ方向に動く残りの部分は、行動の判断材料になることを何も伝えないからです。引き算の元になる2つの数値はどちらもその上に表示されるため、何も追加で質問しなくても計算を確認できます。

絞り込んでいない回答にはこのブロックはありません。すでにテーブル全体を報告しているため、繰り返すと2つの見出しの下に同じ数値が2回現れることになります。

複数の配賦を再結合するテーブルに対する回答には、独自の版があります。ブランチは別々のテーブルであるため、名指しできる単一のテーブル全体はなく、各ブランチの行は、そのブランチが比較された対象としてそのプールの変化を挙げています。そのようなテーブルに対する絞り込んだ回答は、現在、同じ2つの期間における各ブランチのテーブル全体を一覧にし、すべての行でテーブルを名指しし、絞り込まれた行がその中に含まれることを示します。ある実際のモデルで、ドイツのコストがなぜ減少したのかを尋ねたところ、4つのブランチがそれぞれ約58%減少しており、それらを含む4つのテーブル自体もほぼ同じ割合で減少していました。つまり、何が動いたにせよ、ドイツだけに起きたことではありませんでした。回答は、表示されていない数値から読み手に推測させることはもうありません。

メンバー一覧は、誰の変化を分解しているかを示す

メンバー一覧は、回答の中で丸ごとコピーされる可能性が最も高い部分ですが、以前は内訳だけが見出しになっていました。「勘定科目別のすべての変動要因」のようなもので、その行がどの母集団に属するかは何も示されていませんでした。絞り込んだ回答では、同じ列のテーブル全体の変化がその見出しの上に表示されるため、そこに至るまでに最後に渡されたスコープが誤った母集団を指し、行はその上の数値と合計が合いません。

一見、何もおかしくは見えません。行は正確で、絞り込んだ変化と正確に合計が一致します。そのため、上から突き合わせる読み手は、自己整合的ではあるが誤った答えを得て、見直すきっかけも何もありません。各メンバーの全社的な変動に占めるシェアは、テーブルの残りが行ったことの分だけずれます。残りが逆方向に動いた場合は過大に、同じ方向にさらに動いた場合は過小になります。

絞り込んだ回答のメンバー一覧は、現在、見出しに母集団を示し、内訳と行をランク付けする列の間に置かれます。「entity=EU_DISTにおける勘定科目別のすべての変動要因」「lob=COMMERCIALにおけるブランチ別のすべての変動要因 — net_contribution」のようになります。内訳が勘定科目別であることが多く、「entity=EU_DISTの勘定科目別」だと、スコープとして読まれる前に動詞として読まれてしまうため、「～に対して」ではなく「～における」と表現しています。

スコープは、列の前、そして「（表示は大きい順）」の前に意図的に置かれます。列の後だと列名の一部として読まれ、「（表示は大きい順）」の後だと、まったく関係のない網羅性についての記述の後ろに付くことになるためです。

テーブル全体を対象とする回答は変わりません。その行はすでにテーブルのものであり、そこでスコープを示しても唯一の母集団を挙げることになるだけだからです。

要因とメンバーは別の切り口であることを示す

トレースのステップ行は、1つの変化について2つの記述を持つことがあります。1つ目は、その背後にある要因です。数値の元になるプールが動いたのであって、このスライスのプール内のシェアが動いたのではない、というものです。2つ目は、変化が位置するメンバーです。1つのブランチがその70%を占める、というものです。

どちらも正しく、別々の軸の切り口です。一方は変化をそれを生んだ要因の間で分割し、もう一方は変化が着地したメンバーの間で分割します。左から右に読むと、1つの問いに対する競合する答えのように見え、より具体的な方が優先されます。ページだけを渡された読み手は、「プール合計が減少した」と「1つのブランチがその70%を占める」を矛盾として受け取り、どちらかを選びました。

回答がすでに保存されたプールをメンバー別に分解している場合は、両者が別々の測定であることを述べていました。それが、これまで述べられていた唯一の形でした。そのため、1つの事業ライン、エンティティ、プログラムに絞り込んだ回答、つまり挙げられる要因がプール合計であることが最も多く、集中しているメンバーが絞り込みの内側にある場合に、これはどこにも述べられていませんでした。

そのような回答は、現在、正直な制限事項の下に1度だけそれを述べます。変化について挙げられる要因と、それが集中するメンバーは別々の測定であり、変化がほぼ完全にプール合計の動きに由来しながら、ほぼ完全に1つのメンバーに位置することがありえます。これは、ステップ行が両方の記述を持ち、かつページ上のほかの場所にまだ述べられていない場合にのみ追加されます。すでに述べていた回答に、2つ目のコピーは付きません。

自身の計算を確認する

PlaidCloudは、数値が動いた理由を説明するとき、最初のもっともらしい説明で止まりません。各要素を全体に突き合わせ、一致しなければそう述べて信頼度を下げます。そのため、データのわずかなずれは注意事項として現れ、偽りの精度として現れることはありません。

数値を捏造しない

すべての数値は、データに対する実際のクエリから得られます。質問がアクセス権のないデータを必要とする場合や、データが単に存在しない場合、PlaidCloudは推測せず、平易に伝えます。PlaidCloudは何も捏造しません。ハルシネーションによる合計も、作り話の勘定科目名も、でっち上げの傾向もありません。

書かれた要約は、書かれただけでなく検証される

アシスタントが分析を読みやすい段落にまとめるとき、静かなリスクがあります。文章が注意事項を落としたり、データが述べていない形に数値を丸めたりすることです。PlaidCloudはこの隙間を埋めます。構造化された結果とともに、分析から直接作成された平易な要約を返すことができます。それは信頼度を述べ、すべての注意事項を含み、データに対する実際のクエリから得られなかった数値を一切含みません。

これには、アシスタントが言い換えた自身のバージョンに対して実行できる忠実性チェックが付属します。信頼度を保っているか、すべての注意事項を保っているか、数値を捏造していないか、を確認します。言い換えがずれた場合は、チェックが検出します。その結果、単に流暢なだけでなく、その下にある数値に確かに忠実な文章が得られます。

「もしこれが変わったら」という回答にも、同じ扱いがされます。 以前は、数値と注意書きの一覧を返すだけで、物語を組み立てるのは読み手に任されていました。現在は、変化のどれだけを、いくつの結果にわたって説明できるかを述べて始まり、変化が直接及ぶ結果を、適用した変化に対する各結果の割合とともに一覧にし、部分的にしか測定できなかった結果と、まったく測定できなかった結果を、同じ一覧に印なく混ぜずに、それぞれ独自のセクションに置きます。他の結果の結果としてのみ動く結果は別に一覧にされ、上の数値にすでに含まれているものとして印が付くため、重ねて加算することはありません。変化をまったく追跡できない場合、回答は数値ではなく理由から始まります。

このチェックは、ホワットイフの言い換えを、回答が測定できなかった内容に照らして検証します。 回答が測定できなかった結果は、影響がゼロなのではなく不明ですが、言い換えられたバージョンが別の結果の数値をそれに対して引用しても、チェックを通過してしまうことがありました。現在は、そのような結果を数値の隣に挙げる節は、それが測定されなかったことも述べなければなりません。述べていない場合、チェックは修正方法を示します。数値を、それが属する結果または合計の隣に置いて、その結果が測定されなかったと述べるか、その結果に割り当てられた数値を取り下げます。また、結果の名前にドル金額が含まれている場合に、ホワットイフ回答自身の文言を拒否することもなくなりました。

次の質問を提案する

優れたアナリストは、答えるだけでなく、次に何を尋ねるべきかを教えてくれます。各要約は、分析が実際に見つけたことに基づいて、自然なフォローアップを提案します。数値がプール全体の合計であれば単一のメンバーに絞る、ある次元が変化を牽引しているように見えればその次元で変化を分解する、結果テーブルが複数のステップで構築されていれば特定のステップを指し示す、といった具合です。正確な文言を知らなくても提案に従って行動できます。そのまま依頼するだけです。

これらはいずれもどれがという問いに答えるものです。どのメンバーか、どのフィールドか、どのステップかです。さらにもう1つはいつに答えます。回答が主要な要因を挙げてその割合を示す場合、その割合は比較した期間全体で1回だけ測定されます。そのため、1回の跳ね上がりで起きた動きと、着実に積み上がった動きが同じ数値になります。アシスタントは、いくつかのより狭い期間で再実行し、それらを互いに比較することを提案します。それが両者を区別する方法です。狭い期間を1つだけ使っても、同じ2点比較に戻るだけです。同時に、より狭い期間の数値は上の数値と合計が合わないことも述べます。各期間はそれ自体で測定されるため、プール、ドライバー、分割はすべてその期間のために再導出され、それらの割合はより広い期間を分割したものではなく、独自の答えです。特定の期間は挙げません。範囲のどの部分が重要かはあなたが選ぶことであり、それを推測することは、分析がまだ行っていない発見になってしまうからです。2つのシナリオ、2つのバージョン、予算と実績など、期間ではない2つのものを比較した場合は、実行できる狭い範囲がなく、アシスタントはその比較を時間として説明しないため、この提案はまったく表示されません。

さらに2つのケースでは提案が控えられます。どちらも、提案が求めた回答から離れる方向を指してしまうためです。2つの期間の一方がもう一方よりはるかに行数が少ないと回答がすでに報告し、変化に依拠する前にロードを確認するよう求めている場合、その期間をより狭い期間に分割すると、不足が解消されるのではなく分散してしまい、疑義を生んだ行数は、より狭いウィンドウでさらに弱くなります。そして、回答が複数の値の列を対象とし、先頭に挙げる列に独自の割合がない場合は、提案が条件づけるすべての割合が尋ねていない列のものになるため、回答の制限として読めるにもかかわらず、回答にはまったく関係がありません。先頭の列自身が割合を述べている回答には、引き続きこの提案が表示されます。

実行すると、すでに見ているものが返るような提案も省かれます。単一の列を対象とする回答では、アシスタントが最良の説明として選んだフィールドは、メンバーテーブルがすでにグループ化されているフィールドであるため、「そのフィールドで変化を分解する」と提案しても同じテーブルが返ってきました。しかも隣の注記は、数値がページ上のものと一致しないと述べていましたが、実際には完全に一致します。分解が別の列で本当に答えを返す場合、この提案は残ります。

分析が推測で選ばない複数の候補を見つけた場合、たとえば、どちらもテーブルを構築する2つのステップや、変化の説明として区別できないほど近い複数のフィールドがある場合、何から選べるのかを言わずに選ばせるのではなく、それぞれを別々の提案として示します。書かれたとおりに実行できる提案が先に来ます。

それらの候補がフィールドである場合、現在は下の提案だけでなく、発見自体の中で名指しされます。それぞれには、最も強いメンバーと、そのメンバー自身の数値がどれだけ動いたかが、列全体の変化と比べて示されます。そのため、どちらかを選ぶ前に、同点の話のうちどちらが大きいかが分かります。同じスコアだったと述べるだけでは、それが隠れていました。ある自動車モデルでは、同点の両メンバーが列全体より大きく動いており、2つの数値を合わせると列全体の4倍超になりましたが、「複数が同程度のスコア」と伝えられた読み手は、2つを互換なものと受け取り、最初に来た方を報告しました。回答は同時に、候補はプールを分け合うのではなく重なり合うとも述べます。それぞれが同じ変化の別の切り口であるため、数値は1つの合計の部分ではなく、足し合わせても何も表しません。そして、フィールドのペアは検索がスコアリングしたことのないビューであるため、クロス集計は分析が測定したものとしてではなく、次に実行するステップとして、つまり両方で同時に変化を分解するものとして提案されます。

何も見つからなかった検索も、伝える価値があります。変化を分解するフィールドを指定しない場合、アシスタントはそれを最もよく説明するものを探します。試したどれもが報告に値するほど変化を説明しなかった場合、黙り込むのではなくそう述べます。変化はプール全体にわたる広い動きとして読め、最も近かったフィールドは次のものです、とそのフィールドを挙げ、最大のメンバーと、そのメンバーが説明する変化の割合を示します。メンバーを挙げるのは、これが回答に自信のない唯一の発見であり、確認できる必要が最も高いからです。また、フォローアップが別のメンバーを先頭にする可能性があるという付随の警告を、検証可能なものにするのもこれです。そのフィールドは、近い勝負ではなく、弱いフィールドの中で最も強いものとして説明される、そのまま実行できる提案として示されます。検索が説明力なしと判断したためです。それによって数値の信頼度は下がりません。何も選ばれていないため、割り引くべき推測がないからです。

これら最後の2つは異なる結果であり、文言がそれらを区別します。複数のフィールドが同等に良いスコアだった場合は、候補が名指しされてサイズが示され、2つを同時に切るという提案を含む、それぞれ1つずつの提案になります。一方、十分に良いスコアのものがなかった場合は、最も近い1つが、まさにそのものとして提案されます。

複数の値の列を持つ結果では、注記が検索した列を名指しします。 コスト、収益、マージンが並ぶような結果は、1列ずつ検索される一方、回答自体は要約の列を先頭に置きます。そのため、「何も見つからなかった」という結果は、結果全体への判定として読まれるのではなく、どの列の変化を対象としているかを述べます。名指しされた内容のとおりに読んでください。同じ結果の別の列には、それを説明するフィールドがあるかもしれず、その分解を直接依頼すれば分かります。

似て見える2つの割合は区別されます。 アシスタントが変化を最もよく説明するフィールドを選ぶとき、報告される数値は、プールにおけるそのフィールドのシェアの変動です。ご自身でフィールドによって変化を分解するとき、数値は各メンバー自身の変化です。これらは異なる合計に対する異なる測定で、どちらも正しいため、それぞれがどちらであるかを述べ、両方が単なる変化の割合として読まれないようにしています。どちらも、2つの数値が異なると約束することはしません。メンバー別の内訳は、メンバーごとの割合をまったく表示せず、その行は金額です。そのため、不一致と言い表した警告は、行えない比較を探させることになり、確認できない警告は、無視するようになる警告です。それぞれが、2つの尺度が何であるかを述べて、そこで止まります。

これは、検索が何も決められなかった上記の最も近い候補の注記にも当てはまります。最も近かったフィールドについて引用されるシェアも、シェアの変動であり、そのフィールドによる分解は別の尺度を報告します。基準に届かないということは検索についての記述であり、分解が示す内容の上限ではありません。

同点の場合にも当てはまり、そこでは2つの尺度が1つの文に並びます。候補は同じシェアの変動で同点とスコアされ、その隣に表示される数値は、それらのメンバー自身の変化です。そのため、回答は両方の尺度を名指しし、金額がスコアリングで比較されたものであるかのように見せません。2つが異なる大きさになると言い進むこともしません。確認する対象となるシェアの数値がそこには表示されておらず、確認できない警告は、無視するようになる警告だからです。

これが違う理由

ほとんどのAI分析ツールは、正しいかどうかにかかわらず自信満々です。ダッシュボードに後付けされた汎用チャットボットは、流暢で権威があるように聞こえる回答を作り出しますが、しっかりした回答と誤った回答を見分ける手段は何も与えてくれません。そのようなツールにとって、すべての数値はただの数値です。

PlaidCloudは逆の発想で作られています。信頼できない回答には価値がないため、信頼度の評価、自己突き合わせ、正直な注意事項が、すべての回答の一部になっています。この誠実さこそが核心です。だからこそ、AIが生成した説明を、役員会向け資料、予測、意思決定の中で、手作業で再確認することなく実際に使うことができます。

すでに使っているAIで利用できる

この機能を得るために、新しいツールを導入する必要はありません。PlaidCloudの誠実な分析は、チームがすでに使っているどのアシスタントからでも利用できます。

Microsoft 365 Copilotチーム全員がTeams、Outlook、Microsoft 365アプリから質問できます。サインインは1回だけで、デフォルトは読み取り専用です。

AIコーディングエージェント（MCP）Model Context Protocolを使って、Claude Code、Cursor、Claude Desktop、ChatGPT、Geminiを接続します。