アトリビューションギャップとは、意思決定者が尋ねることと、その人が本当に求めていることとの隔たりである。意思決定者は結果について尋ねるが、欲しいのはアトリビューション（原因帰属）、つまりその結果を自分が手を打てる何かへと結びつける因果の連鎖である。この用語は 4D-ARE：LLM エージェントの要求工学におけるアトリビューションギャップを埋める で導入されたもので、そこでの定式化によれば、マネージャーが「なぜ完了率は 80% なのか」と尋ねるとき、求めているのはデータの参照ではない。どのプロセスが失敗したのか、どのリソースが欠けていたのか、どんな戦略的要因が働いているのかを知りたいのである。
用法
この論文が例として挙げるのは、字義どおりの問いには正しく答えたものの、何ももたらさなかったエージェントである。論文のアブストラクトはこれを著者らが実際にデプロイしたエージェントとして述べているが、この話を語る節では、検討すべきデプロイのシナリオとして導入している。ある地域の預金完了率がなぜ 80% なのかと尋ねられたエージェントは、その完了率、訪問頻度、商品浸透率の数値を報告し、チームはこれらの指標を改善すべきだという助言で締めくくった。検索は正確で、推論のステップも妥当だった。それでもマネージャーの手元には数字しか残らなかった。これと対照的なのが、「完了率が 80% ← 高価値セグメントでの商品浸透率が低い ← 訪問カバレッジが不十分 ← 新規参入した 3 社による競争圧力」とたどる回答であり、こちらはマネージャーに打つべき手を与える。
この用語が不満の表明ではなく有用な診断になっているのは、欠陥の所在を特定しているからである。このギャップはエージェントの推論機構の失敗ではない。先の例では、推論と行動のループは設計どおりに正確に実行されていた。欠けていたのはもっと上流、つまりエージェントが何について推論するよう指示されていたかである。この説明によれば、実行時の推論フレームワークは十分に規定されたエージェントを前提としているが、その前提が実務で満たされることはまれである。
適用される場面
この問題は、とりわけアトリビューション駆動の意思決定支援エージェント、すなわち「なぜ」という問いに答え、因果の連鎖をたどり、推奨を因果的な説明に基づかせるエージェントにとっての問題として位置づけられている。たとえばビジネス分析アシスタント、診断支援、アドバイザリーシステムなどである。提唱者たちは 3 種類のエージェントを明示的にその範囲外に置いている。ユーザーが説明を求めずに提案を受け入れる推薦エージェント、目的がアトリビューションではなく予測である予測エージェント、そして人間の意思決定者をループに含めずに行動する自律エージェントである。彼らは別の箇所で、コーディング、クリエイティブ、推薦、自律の各エージェントには、おそらくそれぞれ独自の仕様化のアプローチが必要だとも付け加えている。
提唱者たちは、このギャップを放置したことによる組織的な帰結を「プロンプトウェア危機（promptware crisis）」と名づけている。エージェント開発が試行錯誤のプロンプトエンジニアリングに堕し、暗黙知が開発者の頭の中にしか存在せず、エージェントが不完全な説明、境界の逸脱、因果的なつながりの見落としといった予測可能なかたちで失敗する状態である。彼らが提案する解決策は 4D-ARE であり、これはアトリビューションのロジックを明示的に規定するための設計時の方法論である。
この用語は、自らの方法論を動機づけるためにそれを導入した 1 本のプレプリントに由来し、1 件のデプロイによって例示されているにすぎない。現時点では、確立された、あるいは独立に裏づけられた枠組みではない。