Alibaba Engineering、AI 評価における因果推論の手法と実践を公開

関連性≠因果性：AI評価における因果推論の手法と実践

徐海翔 2026年7月29日 18:18 浙江

因果推論とゲーム理論の手法を用いて、「原因」が「結果」に与える貢献度を定量化し、LLM（大規模言語モデル）、ランタイム環境、ツールなどからなる複雑なAIシステムの最適化ボトルネックを正確に特定します。

これは2026年第43回の投稿です。

（本文の読了時間：約25分）

核心目標： 因果推論とゲーム理論の手法を用いて、「原因」が「結果」に与える貢献度を定量化し、LLM、ランタイム環境、ツールなどからなる複雑なAIシステムの最適化ボトルネックを正確に特定すること。

目次：

1. 因果推論や帰属分析の基礎理論をご存知の場合は、第5章「AI評価における帰属分析の実践」へ直接お進みください。
2. 手法の選定に関心がある場合は、まず第4.3節「方法選択の意思決定フレームワーク」をご覧ください。
3. 結論や実践的な知見のみを知りたい場合は、第6章「まとめと展望」をご覧ください。

01 序論

1.1 「アイスクリームと水難事故」から考える

注釈： 気温という共通の原因が、アイスクリームの販売数と水難事故率の両方に影響を与える因果関係を示す図。

表面にある相関関係の背後にある真のメカニズムを明らかにします。

因果推論における古典的な事例として、「夏になるとアイスクリームの売上が上がるほど、水難事故も増える」という現象が知られています。データの相関関係だけを見て判断すれば、「アイスクリームを食べると水難事故に遭う」といった荒唐無稽な結論に至ってしまいます。しかし、常識的に考えれば両者に直接的な因果関係はないことは明白です。真の黒幕は気温にあります。気温が高くなると人々はアイスを購入したくなり、同時に泳ぐ人も増えるため、結果として水難リスクが高まるのです。

この事例が示す核心は、「相関関係と因果関係は同一ではない」という点です。データ分析において、気温のような交絡変数を特定・制御できなければ、表面的な相関に惑わされて誤った判断を下してしまうことになります。

この論理をAI評価の文脈に当てはめてみましょう。

「新版プロンプトを使用したエージェントのタスク成功率が高い」という現象を観測した場合、それを単にプロンプト改善の結果と即断するのは危険です。そこには重要な交絡変数——クエリの複雑さ——を見落としている可能性があります。もしかすると、新版プロンプトはたまたま単純なクエリに割り当てられ、旧版が複雑なタスクを処理していたのかもしれません。この交絡変数を制御しなければ、プロンプト最適化の真の効果を実際よりも過大評価してしまいます。最悪の場合、実際には性能が低下しているバージョンを「改善」と誤って判断してしまう恐れさえあります。

これが帰属分析（アトリビューション）が解決すべき核心的な課題です。多数が絡み合った要因の中から、各要素の純粋な寄与度を切り離し、「いったいどの工程が結果の変化を本当に引き起こしているのか」を明らかにすることです。

1.2 研究背景

データサイエンスの分野において、因果分析（Causal Analysis）は「原因」が「結果」にどれほど貢献したかを定量化する中核的な手法です。その本質的な目標は、異なる入力変数（要因）が目標結果に与える影響の重みを特定し、「どの要因が結果を駆動しているのか」「それぞれの寄与割合はいくらか」という重要な問いに答えることです。

人工知能が予測から意思決定へと進化するにつれ、従来の相関分析だけではもはやニーズを満たすことができません。因果推論（Causal Inference）は、「何が起きたか」から「なぜ起きたのか」、そして「もし介入したらどうなるか」という飛躍的な理解を可能にし、現代の帰属分析における理論的基盤となっています。

1.3 調査範囲

本稿では以下の3つの側面に焦点を当てます：

・ツールとフレームワーク：主要な因果推論ライブラリや帰属分析ツールの技術選定

・実践的なメソドロジー：古典統計学から機械学習に至るまでの帰属手法の体系

・AI 評価への応用：データサイエンスにおける帰属のパラダイムを、LLM やエージェントの評価にどう適用するか（実務レベルの詳細解説）

02 帰属分析の進化の道筋

2.1 ルールモデルからアルゴリズム駆動へ

帰属分析は、単純なルールから複雑なアルゴリズムへと進化を遂げてきました。

（注：ルール型から統計型、機械学習、そして因果推論へと至る4段階の進化を示す図。各段階を代表する手法を含みます）

従来のルールベースの帰属分析は、事前の業務ロジックに基づいて設計されるため複雑な計算を必要としませんが、柔軟性に欠け、要因間の相互作用を見落としがちです。一方、現代のアルゴリズム駆動型アプローチは、機械学習、ゲーム理論、そして因果推論を基盤として構築されており、高次元で非線形かつ強い相互作用を持つシナリオにおける真の寄与度を捉えることが可能です。

2.2 核心的な課題：相関と因果の溝

機械学習は「X の条件下では Y がどうなるか」（関連性の層）を答えるのは得意ですが、「もし X を変えたら Y はどう変わるか」（介入の層）や「もし当時、異なる選択をしていたら結果はどうなったか」（反事実の層）には答えられません。これが因果推論が解決すべき核心的な課題です。

パール（Pearl）が提唱した因果の階段理論では、推論能力を3つの段階に分類しています。

（注：パールによる因果推論の3層構造を示す図。関連性の観察から介入実験、そして反事実的推論へと能力が段階的に高まる様子を表します）

03

主流ツールとフレームワークの比較

3.1 Python 生態系における主要ライブラリ

現在、因果推論のためのツールライブラリは多様化しており、代表的なものがいくつか存在します。

3.2 主要 3 つのフレームワーク技術比較

※図は、DoWhy（因果図モデリング）、EconML（正交機械学習）、CausalML（Meta-Learner）の主要な処理フローと技術的特徴を比較したものです。

DoWhy の強みは、原則に基づいた因果図によるモデリングフレームワークを提供し、すべての仮定を明確にすることにあります。また、自動的な反証检验（リファタリー）機能により結果の信頼性を高めます。一方、EconML は正交機械学習を活用して高次元データにおける因果効果の推定問題を解決することに特化しており、異質な処理効果を詳細に記述する必要があるケースに適しています。CausalML は Meta-Learner を中核とし、シンプルで使いやすい API を提供します。マーケティング帰属分析や A/B テスト解析において高いパフォーマンスを発揮します。

3.3 解釈性ツール：SHAP 値

SHAP（SHapley Additive exPlanations）は、ゲーム理論におけるシャプレイ値に基づき、各特徴量に対して公平な貢献度を割り当てます。この手法は「効率性」「対称性」「ダミー性」「可加性」という 4 つの公理を満たすため、モデル解釈における「ゴールドスタンダード（黄金基準）」と見なされています。

※図は、SHAP 値がすべての特徴量の部分集合を網羅し、各特徴の限界貢献度を計算して加重平均することで、最終的に公平な貢献度を得るプロセスを示しています。

帰属分析において SHAP 値を用いると、マーケティングチャネルや実験パラメータ、モデルの特徴量が最終結果にどの程度寄与したかを定量化できます。木モデルやニューラルネットワークなど、多様な予測モデルに対応可能です。

04

中核となる方法論体系

4.1 2 つの主要理論フレームワーク：Rubin vs Pearl

因果推論の分野には、主に 2 つの理論的アプローチが存在します。

Rubin 潜在結果モデル（RCM）

• 核心思想：各個人について、あらゆる可能な介入条件下での潜在的な結果を定義する。
• 主要概念：処理効果（TE）、平均処理効果（ATE）、条件付き平均処理効果（CATE）

代表的な手法としては、傾向スコアマッチング (PSM)、二重差分法 (DID)、そして工具変数法 (IV) が挙げられます。これらの手法は統計的推論が厳密であり、効果の推定に適しています。

一方、Pearl の因果図モデルでは、有向非巡回グラフ (DAG) を用いて変数間の因果関係を表現します。do-演算子や後門・前門の基準といった重要なツールを用い、構造因果モデル (SCM) や PC/GES/LiNGAM などの因果発見アルゴリズムを適用するのが典型的です。このアプローチは因果関係の特定が明確で、メカニズムの解明に適しています。

この図は、二大因果推論フレームワークの核心プロセスと相互補完性を示しています。Rubin 枠組みが効果推定に重きを置くのに対し、Pearl 枠組みは因果関係の特定とメカニズム理解を重視します。

両者の目標は共通しており、交絡変数が存在する状況下で介入が結果に与える影響を計算することです。しかし、焦点は異なります。Rubin 枠組みは因果効果の推定と統計的推論に重点を置く一方、Pearl 枠組みは因果関係の特定とメカニズムの理解により傾斜しています。実際の応用では、これら二つを組み合わせて使うことが一般的です（例：DoWhy は両方のフレームワークを統合しています）。

4.2 主要な帰属手法の詳細解説

(1) Shapley Value による帰属分析

これは協力ゲーム理論に基づき、各参加者がすべての可能な連合において果たす限界貢献の平均値を計算する手法です。マーケティングの文脈では、各チャネルを「参加者」、コンバージョン（成約）を「総収益」と見なし、Shapley 値を用いて各チャネルへの貢献を公平に配分します。

メリット：効率性や対称性といった公理を満たすという理論的な保証があり、特徴量間の相互作用効果も捉えることができます。

デメリット：計算複雑度が特徴量の数に対して指数関数的に増加するため、Kernel SHAP や Tree SHAP などの近似アルゴリズムを採用する必要があります。

(2) マルコフ連鎖による帰属分析

ユーザーのコンバージョン経路をマルコフ連鎖としてモデル化し、特定のチャネルを除去した場合にコンバージョン確率がどう変化するかを計算することで貢献度を測ります。接触点の順序を重視するため、マルチタッチポイントでのユーザージャーニー分析に適しています。

メリット：時系列依存性を自然に考慮でき、重要な転換点を特定できます。

デメリット：計算コストが高く、多数のランダムな経路シミュレーションが必要です。

(3) Uplift Modeling ( uplift モデル)

これは介入によって生じる増分効果に焦点を当てます。ユーザーは「説得可能層 (Persuadables)」、「確実層 (Sure Things)」、「絶望層 (Lost Causes)」、「反感層 (Sleeping Dogs)」の 4 つに分類されます。この手法の核心目標は、施策によって反応する「説得可能層」を正確に特定することです。

メリット：介入の ROI を直接最適化でき、リソースの無駄遣いを防げます。

デメリット：ランダム実験データが必要か、あるいは強力な仮定に基づいている必要があります。

(4) 因果推論手法

• 傾向スコアマッチング (PSM)：処理群と対照群の傾向スコアをマッチングさせ、疑似的な無作為化実験を模擬します。
• 二重差分法 (DID)：パネルデータを用いて固定効果を除去しますが、「平行トレンド仮説」が成立することが前提となります。
• 工具変数法 (IV)：外生変数を導入して内生性問題を解決しますが、関連性と排他性の制約が必要です。
• 二重機械学習 (DML)：機械学習の柔軟性と計量経済学の厳密性を組み合わせ、高次元データに適しています。

4.3 手法選択のための意思決定フレームワーク

注：データの利用可能性、分析次元、時系列情報などの条件に基づき、適切な帰属分析手法を選択するガイドラインです。

05 AI 評価における帰属分析の実践

注：以下の事例で使用されるデータはすべて例示であり、帰属分析方法の適用フローを演示するためのものです。実際の運用では、具体的なビジネスシーンに応じて実データを収集する必要があります。

5.1 なぜ AI 評価には帰属分析が必要なのか？

従来の LLM（大規模言語モデル）評価は、タスク完了率や出力品質に焦点が当てられてきました。しかし、複雑な Agent システムにおいては、このブラックボックス的な評価では重要な問いに答えることができません。

• ツール呼び出しの失敗：モデルが間違ったツールを選んだのか、それともパラメータの伝達に誤りがあったのか？
• 計画のミス：タスク分解が不適切だったのか、実行順序に間違いがあったのか？
• 推論の欠陥：知識不足なのか、論理チェーンが断絶したのか？

コンポーネントレベルでの帰属評価では、Agent を独立したモジュールに分解し、ツールの選択精度や計画の妥当性、推論チェーンの質などを個別に評価します。これにより、ボトルネックを正確に特定することが可能になります。

5.2 データ形態に応じた帰属戦略マトリクス

データの利用可能性に基づき、帰属分析は以下の 3 つのパターンに分類されます。

5.3 Agent 評価のための階層型帰属フレームワーク

注：エンドツーエンド評価からコンポーネント別帰属、そして根本原因分析に至るまでの 3 層構造の診断体系を示しています。各層を深く掘り下げることで、問題の根源を特定します。

5.4 Trace ログを用いた帰属分析の実践（高精度アプローチ）

方法論フレームワーク

Agent の完全な実行軌跡（Trace）が利用可能な場合、帰属分析の核心は、エンドツーエンドでの失敗を各コンポーネントへの寄与度へと分解することにあります。この手法はソフトウェア工学における「分散トレーシング」に似ていますが、対象となるのは AI Agent の思考連鎖とツール呼び出しチェーンです。

核心指標体系の設計

ツール呼び出しの実際と期待値の整合性を比較する

パラメータ構築の質

ツールに渡すパラメータが正しいか確認する。参数字段の完全性、フォーマットの適合性、意味的な妥当性をチェックする。

計画能力

多段階タスクが適切な順序で実行されているかを評価する。各ステップ間の論理的な一貫性と依存関係を分析する。

生成の質

最終回答が正確に関連しているかを確認する。LLM-as-Judge（LLM を審査員として用いる手法）や人手によるラベリングでスコアリングを行う。

リソース効率

コストとパフォーマンスのバランスを評価する。「Completion Tokens / Prompt Tokens」の比率を指標とする。

具体的な実施手順

ステップ 1：コンポーネントごとの評価基準を定義する

計測を開始する前に、各コンポーネントにおける「成功」の定義を明確にする必要がある。例えば以下の通りだ。

ツール選択の成功：単に利用可能なリストに含まれるツールを選べばよいのではなく、現在のサブタスクを完了するための最適解を選ぶことが求められる（過去の成功率や専門家のルールに基づいて判断する）。

パラメータ構築の成功：参数字段が欠落せず、データ型が正しく、かつユーザーの意図と意味的に合致していること。例えば「北京の天気」を問い合わせた場合、location 字段は"Beijing"ではなく"北京"であるべきだ。

ステップ 2：段階的な計測戦略を実行する

すべての指標を一度に監視しようとせず、段階を分けて進めることを推奨する。

第 1 段階：ツール呼び出しのシーケンスと最終結果のみを監視し、ベースラインを確立する。

第 2 段階：パラメータの品質チェックや計画の妥当性評価を追加する。

第 3 段階：SHAP 値の計算を導入し、各コンポーネントが最終スコアに与える寄与度を定量化する。

ステップ 3：根本原因の診断マトリクスを構築する

過去の Trace（実行履歴）を集約して特徴量テーブルを作成する。各行は1回の実行を表し、列には各コンポーネントの指標と最終スコアが含まれる。相関分析や回帰モデルを用いて、どのコンポーネントが失敗と強く関連しているかを特定する。

代表的なケーススタディ

ケース 1：ツール説明の不備による誤選択

シナリオ：ユーザーは「杭州の明日の気温を調べて、服装のアドバイスも教えて」と尋ねた。しかし Agent は weather_api の代わりに general_search ツールを誤って呼び出し、構造化された天気データではなく、雑多なウェブページの要約を返してしまった。

Trace 分析結果：

• ツール選択精度：0（誤ったツールを選択）
• パラメータ構築の質：N/A（パラメータ構築フェーズに進まなかったため）
• 計画の妥当性：0.3（「まず天気を調べ、その後アドバイスを出す」という2段階の手順を認識できていない）
• 最終スコア：0.2（回答として利用できないレベル）

帰属分析の結論：

類似するクエリ50件の Trace を比較した結果、ユーザーが「場所＋時間＋派生ニーズ」を同時に指定した場合、ツール選択の誤り率が60%に達することが判明した。さらに詳細な分析では、weather_api の説明に"服装アドバイス"というシナリオへの対応が明記されておらず、モデルが迷った結果、より汎用的な検索ツールを選んでしまったことが原因だった。

改善提案：

weather_api のツール説明に、「天気情報の照会および、それに基づく派生アドバイス（服装や移動手段など）の提供に対応」という具体例を追加する。

（注：同様のクエリ50件におけるツール選択の分布状況と、ツール説明の明確さと選択精度との相関関係を示すグラフ）

ケース 2：パラメータ形式の誤りによる呼び出し失敗

シナリオ：ユーザーが「この販売レポートを PDF に変換して」と指示した際、エージェントは正しく「doc_to_pdf_converter」ツールを選択しましたが、渡されたファイルパスにスペースや中国語文字などの特殊文字が含まれていたため、「ファイルが見つかりません」というエラーが発生しました。

Trace 分析結果：

• ツール選択の精度：1（正解）
• パラメータ構築の品質：0（パスが URL エンコードされていない）
• プランニングの妥当性：1（単一ステップのタスクであり、複雑な計画は不要）
• 最終スコア：0（完全失敗）

帰属分析の結論：直近の 100 件のファイル処理タスクの Trace を確認したところ、パラメータ構築の失敗が全失敗事例の 45% を占めていました。そのうち 70% はパス内の特殊文字が原因でした。これは、モデルがファイルシステムの仕様を正しく認識できていないことを示しています。

改善提案：System Prompt に「ファイルパスを渡す際は、スペースを %20 でエンコードし、中国語文字は UTF-8 エンコードする」というパラメータ構築の規範を追加するか、ツール層に自動エスケープ処理を実装します。

注釈：100 件のファイル処理タスクにおける各種パラメータエラーの分布を示し、特に特殊文字に起因する失敗の割合を強調しています。

事例 3：計画ステップが多すぎてタイムアウト

シナリオ：ユーザーが「過去 3 ヶ月の販売データを分析し、来四半期の予測を立てて」と指示しました。エージェントはデータ抽出→クリーニング→集計→可視化→トレンド分析→季節性分解→モデル訓練→予測という 8 ステップからなる詳細な計画を生成しましたが、各ステップで LLM を呼び出したため、総処理時間が 120 秒を超えてタイムアウトしました。

Trace 分析結果：

• ツール選択の精度：1（すべてのツール選択が正解）
• パラメータ構築の品質：1（パラメータに誤りなし）
• プランニングの妥当性：0.4（ステップが細かすぎて、統合可能）
• リソース効率：0.2（トークン消費量が過大）
• 最終スコア：0（タイムアウトにより未完了）

帰属分析の結論：同様のタスクで成功した事例の Trace と比較すると、平均的な計画ステップ数は 3〜4 歩です。現在のエージェントの計画モジュールはタスクを過度に分解する傾向があり、実行チェーンが長くなりすぎています。計画生成のプロンプトを分析した結果、「ステップ統合の原則」に関する指示が欠落していることが分かりました。

改善提案：計画段階のプロンプトに「並列実行可能なステップは優先して統合し、総ステップ数は 5 歩以内に抑える」という制約を追加します。また、データ処理タスクでは、個別に呼び出すのではなく pandas_agent のように多機能なツールを優先して使用することを推奨します。

注釈：成功したタスクと失敗したタスクの計画ステップ数分布を比較し、ステップ数と処理時間の正の相関関係を示しています。

5.5 摂動型帰属分析の実践（Trace 非存在時）

方法論フレームワーク

中間プロセスのデータが不足している場合、帰属分析はブラックボックス実験に退行します。具体的には、入力要素（プロンプトやツール設定）を微調整し、出力の変化幅を観察することで、各要素の貢献度を逆算する手法です。これは物理学における「変数制御法」や化学の「滴定実験」に似ています。

核心となる考え方は以下の通りです。ある要素を除去した際に出力品質が大幅に低下すれば、その要素は重要な貢献者であると言えます。逆に、除去しても影響が小さい場合は、その要素は冗長かノイズであると判断できます。

扰动策略设计原则

操作步骤详解

Step 1：基线输出の確立

元の設定で N 回（N ≥ 10）実行し、平均点と標準偏差を記録します。これが後の擾乱実験における参照基準となります。

Step 2：対照実験群の設計

各扰动タイプに対して 3〜5 つの変体を用意します。例えば：

• 指令扰动：変体 A（簡略化）、変体 B（詳細化）、変体 C（制約強調）
• 示例扰动：変体 D（例を 50% 削除）、変体 E（低品質な例に置換）、変体 F（例の順序入れ替え）

Step 3：バッチ実行とデータ収集

各変体を M 回（M ≥ 20）実行し、以下のデータを記録します。

• 出力と基線とのテキスト類似度（Embedding Cosine Similarity を使用）
• タスク完了度スコア（人手評価または LLM-as-Judge）
• 応答時間とトークン消費量

Step 4：帰属スコアの計算

貢献度 = (基线平均分 - 扰动后平均分) / 基线平均分 × 100%

この値が正の場合は、その要素に正の貢献があることを示します。負の場合、除去したことで結果が向上したことになります。これは元の要素がノイズであった可能性を示唆しています。

典型案例解析

案例 1：プロンプトに出力フォーマット制約がなく、パーサーが失敗するケース

シナリオ：カスタマーエージェントがユーザーメッセージから注文番号と問題タイプを抽出する必要があります。元のプロンプトは「重要な情報を抽出してください」とだけ記述されており、出力フォーマットの指定がありませんでした。

扰动実験：

• 基线：フォーマット制約なし。100 回実行のうち、パーサーが正しく抽出できたのは 60% のみ。
• 変体 A：「JSON 形式で出力し、orderid と issuetype フィールドを含めてください」と追加。
• 変体 B：「注文番号と問題タイプをカンマ区切りで出力してください」と追加。
• 変体 C：期待する出力フォーマットを示す Few-shot 例を提供。

結果：

• 変体 A のパーサー成功率は 95% に向上。
• 変体 B は 80% に向上。
• 変体 C は 92% に向上。

帰属結論：フォーマット制約の貢献度は (95% - 60%) / 60% = 58.3% となり、プロンプト要素の中で最も大きな影響を与えていました。これは、構造化された情報抽出タスクにおいて、明確なフォーマット指示が例示よりも重要であることを示しています。

最適化の提案：情報抽出に関わるすべてのプロンプトテンプレートにフォーマット制約を強制し、自然言語による記述ではなく JSON Schema を優先して使用すべきです。

注：本图展示了不同格式约束变体的解析成功率对比，其中 JSON 格式的约束优势尤为显著。

ケース 2：RAG で取得したドキュメントのノイズが生成を妨げる

シナリオ： 法律 Q&A エージェントが RAG（Retrieval-Augmented Generation）を用いて関連する法条を検索します。ユーザーが「労働契約解除時の経済補償金の計算方法」を質問すると、システムは 10 篇のドキュメントを返しますが、そのうち 3 篇は高品質で関連性が高く、残りの 7 篇はノイズ（例えば社会保険政策や税務規定など）でした。

摂乱実験（擾乱実験）：

• ベースライン： 10 篇のドキュメントすべてをコンテキストとして使用。
• 変体 A： 関連性スコアが 0.8 を超えるドキュメントのみを残す（3 篇に絞り込み）。
• 変体 B： ドキュメントをランダムに 50% 削除する（5 篇残る）。
• 変体 C： すべてのドキュメントを関連性で降順ソートし、上位 5 篇のみを採用。

結果（弁護士による専門家評価、満点 10 点）：

• ベースライン平均：6.2 点（回答が冗長で、無関係な情報も含まれる）。
• 変体 A 平均：8.5 点（関連する法条を正確に引用）。
• 変体 B 平均：7.1 点（重要なドキュメントが削除されてしまう場合がある）。
• 変体 C 平均：8.0 点（精度と完全性のバランスが取れている）。

帰属結論： 高品質なドキュメントの選別による貢献度は (8.5 - 6.2) / 6.2 = 37.1% です。これは、RAG システムの検索品質が生成結果に直結することを示しています。単純な Top-K（上位 K 件）戦略よりも、関連性閾値に基づく動的選別の方が効果的です。

最適化の提案： RAG 検索後に「関連性フィルタリング」工程を追加し、スコアが 0.75 を超えるドキュメントのみを保持します。同時に、検索モデルのリコール戦略を見直し、低関連性のドキュメントが混入しないように調整してください。

注：本図は、ドキュメント選別戦略ごとの専門家評価の比較と、関連性と回答品質の正の相関関係を示しています。

ケース 3：Few-shot（少サンプル）例示の順序が推論チェーンの質に影響する

シナリオ： 数学問題解決エージェントが Chain-of-Thought (CoT) プロンプトを使用し、解法の思考プロセスを示す 3 つの例示を提供します。

摂乱実験（擾乱実験）：

• ベースライン： 例示を難易度順に並べる（簡単→中程度→困難）。
• 変体 A： 例示を逆順に並べる（困難→中程度→簡単）。
• 変体 B： 例示をランダムに配置。
• 変体 C： 最も難しい問題の例示のみを残す（1 つ）。

結果（50 問のテスト問題における正答率）：

• ベースライン正答率：78%
• 変体 A 正答率：72%
• 変体 B 正答率：65%
• 変体 C 正答率：70%

帰属分析の結論：サンプル順序による寄与度は (78% - 65%) / 78% = 16.7% と算出されます。フォーマット制約ほどの影響はありませんが、「段階的に難易度を上げる」ようなサンプル配置は、モデルが推論パターンをより効果的に学習する助けになります。一方、ランダムな順序にすると効果が著しく低下します。これはおそらく、モデルが規則性を捉えられなくなったためです。

最適化の提案：Chain of Thought (CoT) プロンプトを設計する際は、サンプルを難易度や論理の進展に従って厳密に並べるべきです。ランダム化や逆順配置は避けてください。

解説：異なる Few-shot サンプルの配置戦略が、推論チェーンの質にどう影響するかを比較したものです。

5.6 因果推論に基づく A/B テストの実践

方法論フレームワーク

従来の A/B テストでは、「新バージョンのプロンプトの方がスコアが高い」といった相関関係しか把握できません。しかし、「新バージョンを試すユーザーが元々経験豊富だった」や「テスト実施時にサーバー負荷が低かった」といった交絡因子の影響を排除することはできません。因果推論は、これらの交絡変数を制御することで、介入の純粋な効果を推定します。

核心となる概念：

処理変数（Treatment）：意図的に変更する要因（プロンプトバージョン、モデル選択、Temperature など）；

結果変数（Outcome）：注目している指標（タスク成功率、ユーザー満足度、応答時間など）；

交絡変数（Confounders）：処理と結果の両方に影響を与える第三者の変数（クエリの複雑さ、ユーザーの専門知識、時間帯など）；

平均処理効果（ATE）：交絡因子を除去した後の、処理変数が結果に与える純粋な影響。

手順の詳細解説

Step 1：因果図（DAG）の作成

実験設計の前に、有向非循環グラフ（DAG）を用いて変数間の関係を整理します。例えば以下のようになります。

クエリの複雑さ → プロンプトバージョン（複雑なクエリが新バージョンに割り当てられる傾向があるため）；

クエリの複雑さ → タスクスコア（複雑なクエリは元々難易度が高いため）；

ユーザーの経験 → タスクスコア（経験豊富なユーザーほど質問が明確になるため）；

時間帯 → サーバー負荷 → 応答時間。

この DAG を通じて、制御すべき交絡変数（ここではクエリの複雑さとユーザーの経験）を特定します。

Step 2：無作為対照実験の設計

2 つのグループの分布を一致させるため、以下の戦略を採用します。

完全ランダム化：同一のクエリ群を V1 と V2 のプロンプトにランダムに割り当て、クエリの複雑さの分布が同じになるようにします；

層別ランダム化：クエリの複雑さを「高・中・低」の 3 レベルに分け、各層内でランダムに割り当ててサンプルを均衡させます；

ペアデザイン：各クエリに対して V1 と V2 をそれぞれ実行し、スコアの差を直接比較します（クエリ自体の影響を排除するため）。

Step 3：推定手法の選択

データの特徴に応じて適切な方法を選びます。

単純な t テスト：交絡変数がないことが確認できている場合のみ使用（完全ランダム化かつサンプル数が十分大きい場合など）；

傾向スコアマッチング（PSM）：完全なランダム化が不可能な場合に、類似したサンプルをマッチングさせて疑似的な無作為実験を模擬します；

二重頑健推定（Doubly Robust）：回帰モデルと PSM を組み合わせた手法で、どちらかのモデルに誤りがあっても一貫性を保ちます；

神経直交学習（NOL）：交絡変数の次元が非常に高い場合（10 個以上など）に使用し、深層学習によって自動的に特徴を抽出します。

Step 4：感度分析

結論が観測されていない交絡変数に対してどれほど頑健かを検証します。仮の未観測交絡変数を追加しても処理効果が依然として有意であれば、その結論は信頼できると判断できます。

代表的な事例解析

相関関係と因果関係の混同：AI 評価における因果推論の実践

事例 1：新バージョンの Prompt が単純なクエリでは性能が向上する一方、複雑なクエリでは劣化する現象

シナリオ

チームは Agent のパフォーマンスを向上させるため、新版の Prompt（V2）を開発しました。初期の A/B テストでは V2 の平均スコアが V1 よりも 5% 高いという結果が出ましたが、実際にサービスにリリースした後のユーザー反応は賛否両論でした。

因果分析のポイント

初期テストではクエリの複雑さを制御していなかったため、「辛普森の逆説（Simpson's Paradox）」が働いていた可能性があります。

実験設計の見直し

クエリを以下の 3 つの複雑度レベルに分類し、各カテゴリ内で V1 と V2 のスコア差を計算しました。

• 単純: 単一の事実確認クエリ
• 中程度: 多段階の推論が必要
• 困難: ツール呼び出しや計画立案が必須

結果

• 単純クエリ: V2 が 8.5、V1 が 7.8（+8.9%）
• 中程度クエリ: V2 が 7.2、V1 が 7.5（-4.0%）
• 困難クエリ: V2 が 5.8、V1 が 6.5（-10.8%）

帰結

V2 の Prompt は指示を簡素化することで単純なクエリの性能は向上させましたが、複雑なタスクへの対応能力を犠牲にしました。おそらく、計画立案に関する指導が削除されたことが原因です。全体として 5% の平均スコア上昇は、テストセットの 70% を単純なクエリが占めていたため、複雑なクエリでの性能低下が隠蔽されてしまった結果です。

改善策

動的な Prompt 戦略を採用すべきです。単純なクエリには V2 を、複雑なクエリには V1 をそのまま使うか、あるいは「V2-complex」のような専用バージョンを開発します。

解説: 異なるクエリ複雑度ごとの Prompt バージョンの効果を比較し、辛普森の逆説がどのように発生するかを示しています。

事例 2：傾向スコアマッチング（PSM）を用いて判明した Temperature 調整の実効性

シナリオ

チームは「Temperature を 0.7 から 0.3 に下げることで、回答の一貫性が向上するか」を検証したいと考えていました。しかし、過去のデータを見ると、低い Temperature は主に単純なクエリが多いカスタマーサポートで使われており、高い Temperature は複雑なクリエイティブライティングに用いられていました。このまま単純比較するとバイアスが生じます。

因果分析の設計

• 因果図の構築: Temperature → 回答の一貫性；クエリの種類 → Temperature（カスタマーサポートでは低温度が好まれる）；クエリの種類 → 回答の一貫性（クリエイティブなタスクは元々変動が大きい）
• 傾向スコアマッチングの実施: 各低 Temperature のサンプルに対し、クエリ種別が類似した高 Temperature のサンプルを 1 つずつ対応付けます。

マッチング後の結果

• 未調整の差分: 低 Temperature で一貫性スコア 0.85、高 Temperature で 0.72（一見して 18% の向上に見える）
• PSM マッチング後: 低 Temperature で 0.82、高 Temperature で 0.78（実質的な向上はわずか 5%）

帰結

当初観察された 18% の向上のうち、13% はクエリ種別の違いによる交絡効果でした。Temperature 自体がもたらす純粋な効果は 5% に過ぎません。つまり、Temperature を下げれば一貫性は確かに向上しますが、その効果は表面的に観測されるほど大きくないということです。

改善策

安易に Temperature を下げるのではなく、一貫性と創造性のバランスを考慮する必要があります。カスタマーサポートのような定型業務では 0.3 を使用し、クリエイティブなタスクには 0.7 を維持するのが適切です。

注：本图展示了倾向得分匹配（Propensity Score Matching）前后协变量分布的对比，用于验证匹配质量。

案例 3：利用 NOL 评估多参数联合优化效果

场景

团队同时调整了 5 个关键参数：Prompt 版本、Temperature（温度）、Top-p、最大 Token 数以及重试次数。面对如此高维的参数交互效应，传统的回归分析方法已难以胜任。

因果分析设计

• 数据收集：采集 1000 次实验数据，记录各参数的具体数值及最终得分；
• 模型构建：采用 EconML 库中的 LinearDML（线性双重机器学习）模型。将 5 个参数设定为处理变量（Treatment），Query 特征作为混淆变量（Confounders）。

分析结果

• Prompt 版本：ATE（平均处理效应）为 +0.12，提升显著；
• Temperature：ATE 为 -0.03，呈轻微负向影响，但统计上不显著；
• Top-p：ATE 为 +0.01，几乎无影响；
• 最大 Token 数：ATE 为 +0.08，带来中等幅度的提升，但存在边际递减效应；
• 重试次数：ATE 为 +0.15，显著提升效果，但成本增加了 3 倍。

交互效应的发现

• 协同作用："Prompt V2 + 低 Temperature"的组合效应达到 +0.18，高于两者单独效应之和（0.12 - 0.03 = 0.09），说明二者存在显著的协同作用；
• 收益递减：当重试次数超过 2 次后，额外收益急剧下降（从 +0.15 骤降至 +0.02）。

归因结论

最优策略应为采用"Prompt V2 + Temperature 0.3 + 重试 2 次"。预计综合提升可达 0.41 分（0.18 + 0.08 + 0.15），同时有效控制成本。

优化建议

应放弃单独优化单个参数的思路，转向参数组合的联合优化。建立参数配置的帕累托前沿（Pareto Frontier），在效果与成本之间寻求最佳平衡点。

注：本图展示了多参数联合优化的交互效应及帕累托前沿分析结果。

5.7 综合归因工作流可视化

Trace 归因 Pipeline

擾乱型アトリビューションのワークフロー

因果関係に基づく A/B テストの設計

06

課題と今後の方向性

6.1 手法の適用範囲と限界

解説: 本図は、AI の評価におけるアトリビューション（帰属分析）に因果推論を適用する際に直面する主要な課題とボトルネックを示しています。

アトリビューション分析は万能ではありません。実務においては、その能力の境界線を明確に理解しておく必要があります。

Trace ログに基づくアトリビューションの限界

• 埋め込み（インストゥルメンテーション）の完全性への依存: 特定のコンポーネントが監視されていない場合、分析結果には見落としが生じます。
• コンポーネント間の強い結合: モジュール間で密接に連携している場合、独立したアトリビューションを行うことで、各モジュールの貢献度を過大評価または過小評価するリスクがあります。例えば、「ツール選択」は「プランニング（計画）」に強く依存しており、両者を完全に分離することは困難です。
• データ量の要件: 統計的な有意性を確保するためには、一定規模のデータ蓄積が必要です（目安として少なくとも 100 回以上の実行が必要）。

擾乱型アトリビューションの限界

• コストの高さ: 安定した結果を得るためには、各擾乱変体に対して 20 回以上の実行が必要です。変体が N 個ある場合、API 呼び出しは 20N 回に膨れ上がります。
• 設計の主観性: 「何を」「どの程度」擾乱するかという判断自体が主観に左右され、これが結論の信頼性に直結します。
• 相互作用効果の検出不能: コンポーネント A と B を個別に擾乱しても影響が見られなくても、両方を同時に擾乱した際に初めて問題が顕在化するようなケース（相互作用）を捉えることができません。

因果推論を用いた A/B テストの限界

• PSM（Propensity Score Matching：傾向スコアマッチング）のサンプル要件: 十分なマッチングペアを見つけるためには、通常 500 件以上のサンプルが必要となります。

因果図の構築にはドメイン知識が不可欠であり、誤った因果仮説は誤った推定結果を招きます。

また、高次元のシナリオでは DML（Double Machine Learning）などの手法も理論的には優れていますが、パラメータ調整や収束には現場での経験が必要です。

6.2 帰属分析を行わないべきケース

以下の状況では、あえて複雑な帰属分析を行うよりも、Bad Case（失敗事例）の直接分析を行った方が効率的です。

• データ量が 50 件未満の場合: 統計的な有意性が得られず、帰属結果のばらつきが大きくなります。この場合は、個々の事例を一つずつ確認する方が確実です。
• システムが急速に迭代（更新）されている場合: プロンプトやツールの設定が毎日変更されるため、データが蓄積される前に分析対象として陳腐化してしまいます。
• 問題の原因がすでに明確な場合: デバッグで特定できる事象（例：特定のツール API の障害など）であれば、「科学的な帰属分析」は不要です。
• 単一コンポーネントのシステムの場合: エージェントが「1 つのモデル＋1 つのプロンプト」のみで構成されており、分解可能なコンポーネントの次元が存在しないケースです。

帰属分析の真価を発揮するのは、複数のコンポーネントが絡み合い、複雑度が高く、スケーラブルな診断が必要な場面です。単純な問題には、シンプルなアプローチで十分対応できます。

6.3 現在直面している核心的な課題

実際の導入現場では、主に以下の点に困難が生じています。

6.4 実践経験と避けるべき落とし穴

初期段階でのアプローチ

• 単一コンポーネントから始める: いきなり全工程の帰属システムを構築するのではなく、まず明確な問題を抱えるコンポーネント（例：ツール選択機能など）一つに絞って手法の妥当性を検証し、その後で範囲を広げます。
• ベースラインデータの先行収集: 最適化を行う前に、必ず 100 回以上の実行を通じてベースラインデータを収集します。比較対象となるデータがなければ、帰属結論を導き出すことは不可能です。
• 「十分であれば良い」という姿勢: 帰属分析の目的は「主要なボトルネックを見つけること」であり、各コンポーネントの影響度を小数点以下第二位まで正確に算出することではありません。80% の確信度があれば、最適化の方向性を示すのに十分です。

中級者向けの戦略

• 帰属→最適化→検証のループを構築する: 帰属分析はスタート地点に過ぎません。ボトルネックを特定したら最適化を行い、その効果を検証するために再度帰属分析を行います。「分析はしたが誰も手を加えない」という状況を防ぎます。
• 単一指標への依存に警戒する: 最終スコアだけを見てはいけません。「成功した事例」であっても、ツール選択が誤っていたにもかかわらずモデルの推論力でカバーされたケースでは、ツール選択を依然としてリスク要因としてマークする必要があります。
• コンポーネント間の連動分析: 単一コンポーネントごとの帰属では説明力が不足する場合（例：各コンポーネントを個別に見れば「まあままだが」、システム全体としては失敗している場合など）、コンポーネント間の相互作用効果を分析してみましょう。

よくある落とし穴のチェックリスト