結論から書きます。AIに「チェックすべき観点リスト」を渡すと、自分で作った検証データでの成績は劇的に上がりますが、その改善は実データに転移しませんでした。合成データでF1 100.0%だった条件が、実データでは41.7%。観点リストを渡さない素のAI（61.5%）より低い数字です。手元のテストの点数は、本番の性能を保証しません。

何が測られたのか（一次資料の実測）

題材は、Manuel Israel Cázares氏の単著論文「Routing Ceilings Are Domain-Independent: Structural Prior Injection in Code Search」です（出典：arXiv:2607.14628、2026年7月16日（arXiv:2607.14628v1）、https://arxiv.org/abs/2607.14628v1）。

やっていることは単純です。ソースコードの脆弱性を見つけるという作業をAIにやらせるとき、何も指示しない状態（ゼロショット）と、「こういう観点で見ろ」という構造的な前提知識＝チートシートを与えた状態を比べています。使ったモデルは GPT-OSS-120B、Llama-3.3-70B、Gemma-4-31B の3種類です。

まず、著者が作った合成データでの結果です。ここでの成績は文句なしでした。

  • 意味的な脆弱性（N+1）の検出率は、20.0% から 100.0% へ改善。3モデルすべてが100.0%に到達しました（条件：合成データ、N+1カテゴリ）
  • GPT-OSS-120B の N+1 カテゴリのF1は、28.6% から 96.8%（+68.2ポイント）へ（条件：合成データ、表3）
  • 誤った枠組みに当てはめてしまう「ミスルーティング」は、ゼロショットでは合成13件・実データ19件発生していたのに対し、チートシート使用時は合成・実データ合わせて17ランすべてで0件でした

合成コーパスの規模は、学習用278ペア＋ホールドアウト70ペアの計348ペア（著者が作成した合成データセット）です。この数字だけ見れば、「観点リストを書けばAIは劇的に賢くなる」という話に見えます。

実データに当てた瞬間に何が起きたか

問題はここからです。著者は同じ設定を、VUDENCという実データのベンチマーク（実際に報告されたCVE由来）に当てました。評価は1条件あたり30サンプル（脆弱15＋正常15）です。

条件（GPT-OSS-120B、CWE-89） 合成データのF1 実データのF1 差
チートシートv2 100.0% 41.7% −58.3ポイント
ゼロショット（素のAI） 90.9% 61.5% −29.4ポイント

読み方は2つあります。ひとつは、どちらも実データでは落ちるということ。もうひとつは、落ち方が同じではないということです。素のAIは29.4ポイントの低下で済んだのに、丁寧に観点リストを作り込んだv2は58.3ポイント落ち、順位が逆転しました。実データでは、41.7% < 61.5% です。

しかもv2は、v1の誤答を見て直したバージョンです。「間違いを見て、プロンプトを直して、また試す」という、多くの現場でやっている改善サイクルそのものです。それが実データではv1より悪化した。著者はこの、自分の手法にとって都合の悪い結果をそのまま報告しています。反復的な再較正では直らない、ということです。

タスクの種類によって難易度がまったく違う

もうひとつ実務に効く数字があります。同じGPT-OSS-120B・合成データで、タスクの性質ごとにゼロショットのF1が階段状に落ちていました。

タスクの性質 例 ゼロショットF1
構文的（見た目のパターンで判断できる） CWE-798 90.9%
文脈的（周辺を見る必要がある） CWE-284 85.7%
意味的（意味を追って初めて分かる） N+1 28.6%

構文的なものは素のAIでも90.9%。一方、意味的なものは28.6%で、業務にそのまま使える水準ではありません。この勾配は、AIに任せる作業を切り分けるときの物差しになります。

中小企業にとって何を意味するか

中小企業のAI導入で最も起きやすい失敗は、「社内で作ったサンプルで試したら100点だったので本番投入」です。この論文は、その失敗の構造を数字で示しています。自作の観点プロンプトは、自作のテストケースに過剰適合します。そして過剰適合したプロンプトは、実データでは素のAIより悪くなりうる。

実務ルールとして持ち帰るべきは3つです。

  • 評価は必ず本番と同じ実データで行う。自分で作ったサンプルの点数は、導入可否の根拠にしない
  • プロンプト改善の効果を、手元テストの点数で判定しない。手元の誤答を潰す作業は、本番性能を下げる方向に働くことがある
  • 「見た目のパターンで済む作業」と「意味を追う作業」を分ける。後者は素のAIで28.6%という水準がありうるので、人の確認を残す設計にする

評価軸そのものの作り方については自社の評価基準をどう作るか、指示文の効果をどう見積もるかについてはスキル指示書の効果検証も併せて読むと、判断の順序が組み立てやすくなります。

論文自身が認めている限界

この論文は、自分の弱点をかなり率直に書いています。読むときは以下を前提にしてください。

  • 実データ評価が1条件あたり30サンプル（脆弱15＋正常15）と極めて小さく、統計的な確からしさが弱いことを著者自身が認めている。母集団はCWE-89が8,646脆弱/10,223正常、CWE-22が1,701/2,469
  • チートシートは第一著者が手作業で作成しており、作成者間の一致度（inter-rater reliability）は検証されていない
  • Gemmaは一貫性のため推論（reasoning）を無効にして実行しており、先行研究と条件が揃っていない
  • 実験マトリクスが未完成で、条件C（統合チートシート）と条件D（漸進的飽和）は未検証
  • VUDENCはPython限定。C/C++やJavaなどコンパイル言語で同じ崩壊パターンが起きるかは未解決
  • 本研究は先行研究（数学的推論）の実験デザインを別ドメインで再現したものであり、新規手法の提案ではない

つまり「観点リストは必ず失敗する」と一般化できる論文ではありません。30サンプルで出た41.7%という数字は、方向性の警告として受け取るのが妥当です。それでも、警告としては十分に具体的です。

TOEの読み筋

前提として、TOEではこの論文の再現実験を実施していません。コード脆弱性検出への適用も未実施です。以下は論文の数字を踏まえた読みです。

社内でAI活用を進めると、ほぼ必ず「プロンプトを育てる」段階に入ります。誤答が出るたびに指示文へ条件を書き足していく、あの作業です。この論文が示しているのは、その作業が本番性能の改善と等号で結べないことです。書き足した条件は、書き足すきっかけになった事例に最適化されているので、当然といえば当然の話でもあります。

そこで運用に組み込むべきなのは、「改善前後を、改善のきっかけになった事例とは別の、本番由来のデータで比較する」という一手間です。素のAIとの比較も残しておく。素のAIより悪くなっていないかを確認する列がないと、今回のような逆転に気づけません。導入初期の進め方は中小企業のAI最初の一歩、ツールの選び方の考え方はAIツールの選定基準にまとめています。

もうひとつ。ミスルーティングが0件になったことは事実です。観点リストには、AIの答えを「暴走させない」効果は確かにあります。ただしそれは精度が上がることとは別の話で、枠に沿って自信を持って間違える、という状態にもなりえます。安定と正確さを混同しないこと。ここが今回の一番実務的な教訓だと考えています。

まとめ

  • 観点リスト（構造的プリオール）を与えると、合成データでは検出率20.0%→100.0%、F1 28.6%→96.8%（+68.2ポイント）と劇的に改善した（GPT-OSS-120B、N+1カテゴリ）
  • しかし実データ（VUDENC、CWE-89、1条件30サンプル）では、チートシートv2のF1は41.7%まで落ち、素のAIの61.5%を下回った
  • 誤答を見て直したv2が実データでv1より悪化しており、手元の誤答を潰す改善サイクルが本番性能を下げうる
  • タスクは構文的90.9%・文脈的85.7%・意味的28.6%と難易度に明確な勾配があり、意味を追う作業には人の確認を残す設計が要る
  • 実データ評価は30サンプルと小さく、チートシートは単一著者の手作業、Pythonのみという限界を著者自身が明記している。TOEではこの再現実験を未実施