🤖 AI

LLMs for Qualitative Data Analysis Fail on Security-specificComments in Human Experiments

この論文は、脆弱性コードの分析に関する人間の自由記述コメントからセキュリティ固有のトピックを抽出する際、詳細なコードブックを用いても LLM は人間のアノテーターを信頼性を持って代替できないことを示しています。

原著者： Maria Camporese, Fabio Massacci, Yuanjun Gong

公開日 2026-04-14

📖 1 分で読めます☕ さくっと読める

原著者： Maria Camporese, Fabio Massacci, Yuanjun Gong

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

この論文は、**「人工知能（AI）は、セキュリティの専門家が行う『複雑な人間関係の分析』を、本当に代わってやれるのか？」**という疑問に答えた、非常に興味深い実験の結果報告です。

結論から言うと、**「残念ながら、今の AI はまだ人間に代わってこの仕事を任せるには不十分です」**というのが結論でした。

この難しい研究を、誰でもわかるような「料理の味見」や「探偵の推理」に例えて、わかりやすく解説しますね。

🕵️‍♂️ 物語の舞台：セキュリティの「味見」実験

まず、背景を理解しましょう。
コンピュータのプログラムには「バグ（欠陥）」や「セキュリティの穴」が潜んでいることがあります。研究者たちは、学生や専門家を集めて、コード（プログラム）を見て「どこが危ないか」を分析させ、その**「なぜそう思ったのか？」という理由（コメント）**を書かせました。

この「理由」は、自由な言葉で書かれた文章（自由記述）です。
研究者たちは、この膨大な文章を一つずつ読み、以下のようなタグ（ラベル）を付けます。

「特定のプログラム変数名が出てきたか？」
「特定の行番号に触れられたか？」
「セキュリティ用語が使われたか？」
「『わからない』という曖昧な表現があったか？」

これを**「テーマ分析（Thematic Analysis）」**と呼びます。

🤖 挑戦：AI に「味見」を任せる

この作業は非常に時間がかかります。信頼性のために、複数の人間が同じ文章を読み、意見が一致しているか確認する必要があります（これを「アノテーション」と言います）。

そこで、「最新の AI（大規模言語モデル）」にこの作業を任せて、人間を代用できないか？ と試みました。
AI には、以下のような指示（プロンプト）を与えて実験しました。

基本指示だけ: 「このタグを付けてね」
詳細なマニュアル: 「タグの定義と、良い例・悪い例を載せるね」
迷い事例の解説: 「他の人が迷ったケースと、どう判断すべきかの解説も載せるね」

📉 実験結果：AI は「料理の味」を間違えた

結果はどうだったでしょうか？

1. 単純な作業はできるが、複雑な判断は苦手

できたこと: 「『変数』という言葉が出てきたか？」のような、文字通りそのままの検索なら、AI はそこそこできました。
できなかったこと: 「この文脈では『デバッグ』という言葉はコードの話をしているのか、それとも単なる日常会話なのか？」といった、文脈やニュアンスを汲み取る判断は、AI は全くできませんでした。

2. 指示を詳しくしても、劇的には良くならなかった
人間がマニュアルを読んでも、最初は間違えるものです。AI に対しても、より詳しいマニュアルや、迷った事例の解説を与えてみました。
しかし、「指示を詳しくすればするほど、AI の性能が劇的に向上した」ということはなかったのです。むしろ、複雑な指示を与えすぎると、AI が混乱して余計なミスを犯すこともありました。

3. 確率論的な「偶然の正解」ではない
AI がたまたま正解したように見える場合でも、統計的に計算すると、「人間がやるべきレベルの信頼性」には到底届いていませんでした。
人間同士でも意見が割れる難しい問題について、AI は「正解」を導き出せませんでした。

🍳 具体的な例え：料理の味見

この研究を料理に例えてみましょう。

人間のアノテーター（専門家）:
料理の味見をして、「このスープは『塩味が効いている』か？」「『スパイスの効きすぎ』か？」を判断します。
例：「少し塩辛いけど、胡椒の香りが強いから『塩味』ではなく『スパイス』と判断する」といった、文脈に合わせた微妙な判断ができます。
AI（今のところ）:
味見をさせると、「『塩』という文字が入っていれば『塩味』、『胡椒』が入っていれば『スパイス』」と、文字通りに判断してしまいます。
「塩が入っているけど、実は胡椒が効いていて、全体としてはスパイシーな味だ」というニュアンスが理解できません。
さらに、「味見のガイドライン（マニュアル）」を何ページも渡しても、AI は「文字通り」の解釈から抜け出せず、同じようなミスを繰り返します。

💡 この研究が教えてくれること

AI は「助手」にはなれるが、「代役」にはなれない
今の AI は、人間が「あ、ここは『変数』の話だな」と気づくのを手伝うことはできます。しかし、最終的な判断を AI 任せにして人間を完全に抜くのは、まだ危険です。
セキュリティ分野は「文脈」が命
セキュリティの分析は、単なるキーワード検索ではありません。「なぜその言葉が使われたのか」という背景や、人間の思考プロセスを理解する必要があります。今の AI は、その「深さ」がまだ足りていません。
人間の仕事はこれからも必要
複雑な判断や、責任を伴う分析においては、人間の専門家（味見をする人）の役割は依然として不可欠です。AI はあくまで「下書き」や「候補」を出すツールとして使うのが賢明です。

🎯 まとめ

この論文は、「AI 万能論」に水を差す冷静な研究でした。
「AI が何でもできる」という期待に対し、「セキュリティのような繊細で文脈依存の分析では、まだ人間の方が優れている（あるいは少なくとも、AI 単独では信頼できない）」と、データに基づいて明確に示しました。

今後の AI は、人間を「置き換える」のではなく、**「人間の能力を補完するパートナー」**として進化していく必要がある、というメッセージが込められています。

以下は、提示された論文「LLMs for Qualitative Data Analysis Fail on Security-specific Comments in Human Experiments（人間実験におけるセキュリティ固有のコメントに対する LLM による定性データ分析の失敗）」の技術的な要約です。

1. 研究の背景と問題定義

ソフトウェア工学における人間を対象とした実験では、参加者の自由記述による正当化（コメント）を分析する「主題分析（Thematic Analysis）」が不可欠ですが、これは複数のドメインエキスパートによる手動アノテーションを必要とし、コストと時間がかかります。大規模言語モデル（LLM）は、このアノテーション作業を自動化する有望な候補として注目されています。

しかし、既存の研究の多くは感情分析（ポジティブ/ネガティブ）や一般的な意見抽出に焦点を当てており、セキュリティ分野に特化した技術的なコメント（例：特定の脆弱性タイプの言及、コード行の参照、セキュリティキーワードの検出など）の分析における LLM の能力は未検証でした。

本研究は、以下の 2 つの主要な研究課題（RQ）を提起します：

RQ1: LLM は、セキュリティ技術的なアノテーションにおいて人間のアノテーターを代替できるか？
RQ2: アノテーションのベストプラクティス（コードの定義、例、矛盾する事例の提示など）を模倣したプロンプト設計は、LLM の性能にどのような影響を与えるか？

2. 手法と実験設計

本研究は、人間のアノテーションプロセスを厳密に模倣した実験的アプローチを採用しています。

データセット:
- 未公開のセキュリティ実験（Papotti et al. [36, 37] の著者から提供）から得られた 263 件の人間による自由記述コメントを使用。
- 参加者はコードスニペットの脆弱性分析を行い、その理由を記述。
- これらのコメントは、4 人の人間アノテーターとレビューアによって、9 つのセキュリティ関連コード（例：変数/メソッド識別子の言及、行番号の言及、脆弱性の言及、不確実性の表現など）に対してラベル付けされた。
対象モデル:
- LiveBench ベンチマークで最高性能を誇る 4 つの LLM を選択：
  - 商用モデル：GPT-5, Claude-4 (Anthropic)
  - オープンソースモデル：DeepSeek-V3.2, Qwen3-Max (Alibaba)
プロンプト設計（RQ2 への対応）:
人間のアノテーションプロセス（コードの創出→コードブックの作成→矛盾事例の解決）を段階的に模倣し、プロンプトを洗練させました。
- P1: タスク説明とコード名のみ。
- P2: 各コードの正式な定義と具体例（コードブック）を追加。
- P3: 他のアノテーターのラベル付け結果（Few-shot）を追加。
- P3+: 人間が議論した「矛盾する事例（Contrastive Examples）」と、それに対する研究者の明確化（Clarification）を追加。
評価指標:
- 単純な精度（Accuracy）ではなく、Cohen's Kappa（ $\kappa$ ） または Heidke Skill Score (HSS) を使用。
- 理由：セキュリティ関連のコードは出現頻度が低く（不均衡データ）、偶然の一致による高スコアを防ぐため、確率補正後の一致率を評価基準とした。
- 人間のアノテーター間の一致率を基準とし、LLM がそれを代替できるか（ $\kappa$ 値が 0.6 以上など）を判定。

3. 主要な結果

実験結果は、LLM がセキュリティ固有のコメント分析において人間を代替できないという否定的な結論を示しました。

RQ1 の結果（LLM の代替可能性）:
- 全体的に、どのモデルも人間のアノテーターを信頼性を持って代替できませんでした。
- Qwen3-Max が最も高い性能を示しましたが、平均 $\kappa$ 値は 0.61（「実質的（Substantial）」の下限）であり、完全な代替には至りませんでした。
- GPT-5 や Claude-4 は性能が低く（ $\kappa \approx 0.26 \sim 0.30$ ）、人間のアノテーターよりも劣る場合もありました。
- 意外なことに、オープンソースモデル（DeepSeek, Qwen）の方が、商用モデルよりも全体的に高い性能を示しました。
- コードごとの分析では、「変数識別子の言及（Var）」や「脆弱性なし（NoVul）」のような単純なタスクでは一定の成果を上げましたが、「不確実な表現（Unsr）」や「不明瞭な回答（Unclr）」の識別など、文脈やニュアンスを要するタスクでは著しく失敗しました。
RQ2 の結果（プロンプトの影響）:
- プロンプトの洗練（P1 から P2 への移行）により、コードの正式な定義と例を追加した時点で性能がわずかに向上しましたが、それ以降（P3, P3+）の追加情報（矛盾事例や研究者の解説）による性能向上は統計的に有意ではなく、限界効果（Diminishing Returns） が観察されました。
- 複雑なプロンプトや多くのトークンを使用しても、モデルの誤解（ハルシネーションや文脈の読み違え）を解消できず、むしろ混乱を招くケースもありました。

4. 質的分析からの知見

エラーの源泉を分析した結果、以下のような傾向が明らかになりました：

技術用語とコード識別子の混同: モデルは「debug」や「vulnerable」といった一般的な技術用語を、文脈に関係なくコード識別子や脆弱性の言及として誤ってラベル付けする傾向がありました。
不確実性の解釈: 人間のアノテーターが「確信がない」と判断する表現（例：「I would be inclined to think」）を、モデルが過度に解釈したり、逆に無視したりする不一致が見られました。
構造化データの処理: 一部のモデルはスプレッドシート形式の入出力において、行数の不一致やフォーマットエラーを起こし、実用性に課題があることが判明しました。

5. 貢献と意義

セキュリティ分野における LLM の限界の明確化: 感情分析などの一般的なタスクと異なり、セキュリティ特有の技術的・文脈的ニュアンスを含む定性分析において、現状の SOTA LLM は人間を代替できないことを実証しました。
評価指標の重要性の再確認: 不均衡データにおける「偶然補正済み精度（Cohen's Kappa / HSS）」の重要性を強調し、単純な精度（Accuracy）のみで LLM の性能を過大評価しないよう警告しています。
プロンプトエンジニアリングの限界: 詳細なプロンプトや Few-shot 学習だけでは、ドメイン固有の深い推論能力の欠如を補うことはできない可能性を示唆しました。
将来の方向性: LLM を「自律的なアノテーター」としてではなく、「人間の支援ツール（候補の提示、低複雑度タスクのフィルタリング）」として位置づけるべきであり、ハイブリッドなワークフローやモデルのファインチューニングが必要であると提言しています。

結論

本研究は、セキュリティ分野の技術的コメント分析において、LLM が人間のアノテーターを信頼性を持って代替するにはまだ時期尚早であることを示しました。特に、文脈依存性の高い判断や不確実性の解釈において、モデルは依然として人間に劣ります。今後の研究では、LLM を完全な自動化ではなく、人間の専門知識を補完する「支援的（Assistive）」な役割として統合するアプローチが推奨されます。