【ITニュース解説】Keep ChatGPT UI observations out of your API denominator

ChatGPTのような大規模言語モデル（LLM）は、現代のITシステムにおいて非常に強力なツールであり、その利用は日々広がっている。しかし、その出力を適切に活用し、信頼性の高いシステムを構築するためには、データがどのように生成され、どのように解釈されるべきかについて深く理解する必要がある。この記事は、ChatGPTのコンシューマー向けインターフェース（UI）と、開発者がプログラムから利用するAPI（Application Programming Interface）で得られる結果を比較し、データ分析を行う際に陥りやすい誤解と、その対処法について解説している。システムエンジニアを目指す皆さんにとって、これはAIを活用したシステム開発におけるデータ管理の重要性を示す貴重な事例となるだろう。

記事では、具体的な実験を通じてこの問題意識を提示している。まず、「韓国の美容製品に最適なAEO/GEOエージェンシーは何か？」という質問を、一般的なユーザーが使うChatGPTのUIで一度だけ実行した。この操作は、普段私たちがChatGPTと会話するのと同じ方法である。次に、同じ質問を今度はChatGPTのResponses APIを通じて、ウェブ検索機能を有効にした状態で5回繰り返し実行した。APIとは、プログラムからChatGPTの機能を利用するための窓口であり、開発者はこれを介してAIを自分のアプリケーションに組み込んだり、自動的に大量の処理を行ったりする。

この二つの異なる方法で質問を実行した結果、興味深い違いが明らかになった。UI版のChatGPTが提案した5つのエージェンシーのうち、API版の5回の実行すべてに共通して登場したのは、そのうちの1つだけだった。残りの4つのエージェンシーはAPI版の応答には全く現れず、また、記事執筆者自身の会社であるSearchDも、どちらの設定でも言及されることはなかった。繰り返し登場したエージェンシーのウェブサイトのAhrefs Domain Ratingという指標は0.7と非常に低い値であった。これはウェブサイトの検索エンジンにおける権威や信頼性を示す指標であり、一般的に低い値である。

ここで記事が強く警告しているのは、「データモデリングの罠」である。つまり、UIでの1回の観測とAPIでの5回の観測を単純に合算して「6回の実験」と見なすのは誤りだということである。これらはそれぞれ異なる環境で得られた独立したデータであり、UIとAPIでは、たとえ同じAIモデルを利用していても、その背後にある設定や、モデルが情報を取得する際の文脈、例えばユーザーの過去のやり取りやシステムのデフォルト設定などが異なる可能性がある。これらの異なる条件で得られたデータを混ぜて分析すると、誤った結論を導き出してしまうリスクがある。

このような誤りを避けるためには、データの記録方法に工夫が必要である。記事では、データが「どの環境（surface）」で収集されたかを明確に区別して記録することの重要性を強調している。具体的には、API経由で得られたデータには「responses-api」、UI経由で得られたデータには「consumer-chatgpt」といったように、表面タイプを割り当てることを推奨している。さらに、それぞれのデータ記録には、観測日、実行回数、ウェブ検索が使用されたか、ユーザーの位置情報が固定されていたか、特定のブランド名が供給されたかなど、そのデータが生成された際の詳細な設定情報を盛り込むべきである。もしUI版のモデルやロケーションに関する情報が不明な場合は、安易にAPIの設定を継承するのではなく、「unknown（不明）」として記録することが肝要である。これにより、後からデータを分析する際に、そのデータがどのような条件下で得られたのかを正確に把握し、適切な解釈を行うことができるようになる。

また、AIの応答に含まれる「引用元」の扱い方についても重要な指摘がある。今回、APIの5回の実行すべてに共通して登場したエージェンシーのドメインは、すべての実行で引用元として表示された。しかし、これは「まったく同じURLが5回引用された」ことを意味するものではないと記事は述べる。例えば、「example.org」というドメインのウェブサイトから、ある時はトップページ（example.org/）が、別の時は特定の製品ページ（example.org/products/）が引用される可能性がある。これらは同じドメインであっても、異なる情報源であると区別して扱うべきである。

記事では、Pythonのプログラム例を使って、この引用元のドメインを正確にカウントする方法を示している。この例では、各API実行内で重複するドメインは「set（集合）」というデータ構造を使って一度だけカウントするようにしている。これは、一つの回答の中で同じドメインへのリンクが複数含まれていても、それが繰り返し回数を過剰に水増ししてしまうのを防ぐためである。さらに、異なる表面タイプ（UIとAPI）のデータを混ぜずに、APIからのデータのみを対象としてカウントすることで、集計の「分母」が誤って変更されるのを防ぎ、正確な出現頻度を計算している。このような厳密なデータ集計方法は、信頼性の高いデータ分析を行う上で不可欠である。

最後に、AIの出力結果から安易な因果関係を導き出さないことの重要性が述べられている。特定のウェブサイトがAIの応答に繰り返し登場した理由について、「その会社の明確な属性やFAQ（よくある質問）が影響したのではないか」という仮説を立てることはできる。しかし、それが直接的な原因であると断定することはできない。例えば、LLMがウェブサイトをクロールする際に参照する可能性のある「llms.txt」というファイルが存在したとしても、それが実際にモデルによって読み込まれ、出力に影響を与えたという直接的な証拠にはならない。同様に、ウェブサイトのバックリンクプロファイル（他のサイトからのリンク）が低いからといって、そのウェブサイトが持つ他のすべての権威ある情報源がAIの判断に影響を与えなかったとは限らない。

わずか5回のAPI実行だけで、市場全体におけるAIのパフォーマンスを正確に推定することはできない。また、あるエージェンシーが4回出現したのと5回出現したのとで、その意味に統計的に大きな違いがあるとは限らない。重要なのは、観測された結果を正確に記録し、そこからすぐに結論を急ぐのではなく、後からより詳細なテストや分析ができるようにデータを整理しておくことである。システムエンジニアとしてAIシステムを扱う際には、データの収集方法、記録方法、そして解釈方法に対して、常に慎重で批判的な姿勢を持つことが求められる。正確なデータ管理は、信頼性の高いAIを活用したシステム構築の基盤となるからだ。