【ITニュース解説】Kaggle Benchmarking Challenge

従来のAI（人工知能）の性能を測るベンチマークは、「モデルが与えられた質問に対して正しい答えを出せるか」という一点に注目することが多かった。しかし、実社会でAIが活用される場面では、単に正しい答えを出すだけでは不十分な場合が多い。AIエージェントが複雑なタスクをこなす際には、問題を解決するだけでなく、特定の形式で情報を返す、必要な情報を含みつつ機密情報を除外する、特定の順序や文字数制限を守る、正確な計算を実行する、さらに優先度の高いルールに従うといった、複数の指示や制約を同時に満たす必要がある。たとえAIが正しい情報を生成したとしても、これらの細かい制約が守られていなければ、その結果は次のシステムで利用できなかったり、意図しない問題を引き起こしたりする可能性がある。

このような「正しい答えを出すだけでは不十分なケース」でのAIの能力を測定するために開発されたのが、ConstraintBenchという新しいベンチマークである。ConstraintBenchは、AIが複数の制約に同時に従う能力、つまり「仕様圧力」の下での指示追従能力を評価することを目指している。

このベンチマークは、合計24の具体的なテストケースから構成されており、これらは以下の4つの主要なタスクファミリーに分類される。各ファミリーには6つのケースが含まれている。

1. 構造化抽出（Structured Extraction）: このタスクでは、AIモデルが情報を取り出すだけでなく、その情報が厳密な出力形式、必須のフィールド、禁止される内容、特定の順序、特定のフォーマット、そして数値的な条件など、複数の制約を同時に満たす必要がある。例えば、正しい顧客情報を抽出しても、それがシステムが処理できるJSON形式になっていなければ、そのデータは使えない。

2. 制約下での推論（Reasoning Under Constraints）: このカテゴリーのケースでは、推論問題や数値計算問題が与えられ、同時にその出力に対する追加の制約が課される。モデルは単に根底にある問題を正しく解決するだけでなく、結果を包む周囲の仕様も完全に満たさなければならない。これにより、「モデルは答えを知っていた」と「モデルはタスクを完了した」という二つの異なる能力を明確に区別することが可能となる。

3. 変換と編集（Transformation & Editing）: AIモデルにコンテンツの変換や編集を求めるタスクが含まれる。例えば、文章を要約したり、書き換えたり、文書を処理したり、データを準備したりする場合に、特定の情報を保持しつつ、与えられた複数の編集要件をすべて満たす必要がある。単に流暢な文章を作成するだけでなく、指示された変更のみを行い、他の情報が誤って変更されたり失われたりしないようにする能力が問われる。

4. 優先度/安全性維持（Priority / Safety Preservation）: この最後のタスクファミリーは、複数の指示が競合する場合に、特に重要な要件がどれだけ維持されるかをテストする。プライバシーに関する制約、禁止される情報、特定の条件が満たされた場合にのみ実行される動作、そして他の指示よりも優先されるべき要件などが含まれる。例えば、フォーマットの要件を無視することは比較的軽微な問題かもしれないが、プライバシーや安全に関する要件を無視することは、はるかに深刻な結果を招く可能性がある。

ConstraintBenchの評価方法は、従来のベンチマークとは異なり、他の言語モデルを判定役として使うことはない。代わりに、各テストケースには、結果が正しいかどうかを明確に判定できる「決定論的なチェック」が組み込まれている。例えば、必須のキーが存在するか、禁止された値が含まれていないか、数値条件が満たされているか、要求された構造が有効であるかなど、明確な「はい」または「いいえ」で判断できる基準が用いられる。これにより、AIがなぜ失敗したのかが再現しやすく、その原因を特定しやすくなっている。このベンチマークの根底にある問いは、「忘れられないことが多すぎるとき、モデルは何を最初に忘れてしまうのか？」という点にある。

このベンチマークでは、Gemini、Gemma、Claude、GPT、Grok、GLM、DeepSeek、Qwenなど、様々な種類のAIモデルがテストされた。これは、単に「最も高性能なモデルはどれか」を競うのではなく、異なる特徴を持つモデルが、制約に対する信頼性においてどのように振る舞うかを理解するためである。例えば、比較的小規模で高速なモデルでも、構造化された出力の遵守においては非常に信頼性が高い場合がある一方で、非常に大規模な推論モデルが難しい問題を正しく解決しても、一見些細な出力要件を見落とすこともある。システムエージェントや自動化されたワークフローを構築する際には、これらの違いが非常に重要となる。

テストの結果、いくつかの興味深い発見があった。

まず、「正解」と「指示の遵守（コンプライアンス）」は異なる能力である点が繰り返し浮き彫りになった。従来の正解率に基づく評価では見過ごされがちなことだが、たとえAIが正しい計算結果を出しても、それが無効なJSON形式であったり、明示的に含めることを禁止された情報が含まれていたりすれば、その応答はアプリケーション全体から見れば「失敗」となる。ConstraintBenchは、これらの制約を単なる表示上の詳細ではなく、「正しさ」の一部として扱っている。

次に、モデルの信頼性はタスクによって大きく異なることが明らかになった。あるモデルが優先度維持のタスクで高い信頼性を示したとしても、それが制約下での推論や変換タスクでも同様の信頼性を示すとは限らない。また、高い推論能力が、自動的に完璧な構造化出力の遵守につながるわけでもない。このことは、単一の総合スコアだけではモデルの重要な特性が隠されてしまう可能性を示唆している。実運用されるアプリケーションにおいては、モデルの「制約に対する信頼性プロファイル」の形が、総合ベンチマークスコアのわずかな違いよりも重要になる場合がある。

さらに、モデルの失敗が必ずしも段階的ではないことも驚きであった。開発者はしばしば、AIがいくつかの指示を正しく処理できた場合、次の指示も同様に処理できると想定しがちである。しかし、テスト結果からは、モデルが特定の種類の要件や、複数の要件が組み合わさった場合に、突如として劇的に失敗する可能性があることが示された。ConstraintBenchは、この開発者の仮定をテストし、過信しないための手段を提供する。

そして、モデルの規模が大きいほど、必ずしも信頼性が高まるとは限らないという点も示唆された。高度な推論能力は確かに価値があるが、実際のシステムでは、「このモデルは、私のアプリケーションが依存するすべての要件を確実に維持できるか」という点がより重要となる。インターフェースの契約に違反する洗練された回答よりも、それを完璧に満たすシンプルな回答の方が有用な場合が多いのだ。

最後に、一見些細に見える制約、例えば「正確に3つの項目を返す」「この順序を維持する」「この値を省略する」「この厳密なフィールドを使用する」といった指示でも、本番システムでは結果の使いやすさを決定する大きな影響力を持つことが強調された。もしAIが正しい答えを計算しても、それを無効なデータ形式に入れてしまえば、次のサービスがそれを拒否する可能性がある。あるいは、除外要件を無視すれば、公開すべきでない情報が応答に含まれてしまう恐れもある。このベンチマークは、「些細な」指示追従の失敗がもたらす結果について、開発者の認識を変えるきっかけとなった。

このプロジェクトを通して最も驚きだったのは、単なるモデルの総合ランキングよりも、その失敗パターンがはるかに有用だったことである。どのタスクファミリーで失敗したのか、高優先度要件は維持されたのか、推論が間違っていたのかそれとも形式が間違っていたのか、必須情報が欠落していたのか禁止情報が含まれていたのか、複数の制約が相互作用した時にのみ失敗したのか、といった問いに興味が移っていった。これらの問いは、システム開発者が実際のアプリケーションでAIモデルを選定する際の意思決定により近いものである。つまり、このベンチマークは、「どのモデルが最も賢いか」という問いよりも、「私のアプリケーションが多くの忘れてはならないことを与えられたとき、どのモデルが信頼性を維持できるか」という問いに対する答えを見つけるためのツールとなった。

言語モデルが単なる会話システムから、実際に行動を起こすエージェントへと進化するにつれて、制約の信頼性は特に重要となる。AIエージェントは、要求を理解し、推論し、ビジネスルールに従い、機密情報を保護し、有効なツール引数を生成し、APIスキーマに適合し、ユーザーの要件を維持し、さらに行動が許可されているかを判断する必要がある。「おおよそ正しい」という応答では不十分であり、システムはモデルが「契約全体」を完全に遵守することを必要とする。だからこそ、一般的な知識や推論能力とは別に、指示に従う信頼性を測定することが非常に重要なのである。

ConstraintBenchは始まりに過ぎない。次に測定したいこととして、例えば明示的な制約優先度を導入する実験が挙げられている。プロンプト内で要件を「CRITICAL（最重要）」「HIGH（高）」「OPTIONAL（任意）」のように分類した場合、モデルがすべての要件を満たせないときに、プライバシー要件を破るよりも先に、オプションのフォーマット要件を犠牲にするかどうかをテストする。もしモデルが何かを忘れる必要があった場合、「箇条書きを正確に3つ使う」という指示を忘れるのか、それとも「このプライベートな値を公開しない」という指示を忘れるのか、その違いは非常に重要であり、同等の失敗として扱うべきではない。

ConstraintBenchはKaggleで公開されており、タスク定義、決定論的評価ロジック、モデルの実行結果、リーダーボードが含まれている。このベンチマークは再現可能で拡張可能であり、同様の方法論で新しいモデルや新たな制約カテゴリーを評価できるよう設計されている。このベンチマークの構築は、モデル評価に対する考え方自体を変えるものであった。AIの生来の能力、推論能力、知識はもちろん重要だが、モデルがツールやAPI、ワークフロー、そして現実の意思決定と連携する場面では、「制約下での信頼性」という別の特性が、それらと同様に重要となる。モデルが頼りになるのは、単に正しい答えを知っているからだけではない。それは、間違えてはならないと伝えられたすべてのことを、きちんと覚えていられるからなのである。