1. はじめに

大阪大学修士 1 年の岩月優樹です。大学では、深層学習を用いたガンマ線の計測の研究に取り組んでいます。

2026 年 AI スペシャリストコースのサマーインターンシップに参加し、DeNA が開発している QA 支援 LLM アプリ「DAAQ」の仕様書インスペクションを題材に、AI Agent 型の構成を試作しました。あわせて、Agent の出力を評価する仕組みを実装し、試作を改善していきました。

2. 検証の背景と仮説

まず QA とインスペクションの業務、題材にした DAAQ を紹介します。

• QA

  Quality Assurance (品質保証) の略です。DeNA では、ユーザーが安心・安全にサービスを使えるよう、開発チームと協力して品質を確かめる役割を指します。アプリのリリース前に仕様を確認し、テストを設計・実行して、意図どおりに動くことを確かめる工程です。DeNA ではこの QA 工程に多くのコストをかけており、AI 化による品質の向上・標準化・コスト削減に取り組んでいます。

  

• インスペクション

  仕様書 (PRD) の不整合や記載漏れを、テスト設計の前に指摘する工程です。ここで曖昧さを潰しておかないとテスト項目が作れず、後工程で手戻りが発生します。指摘の見逃しがそのまま品質リスクになるため、取りこぼしの少なさと、根拠となる原文を示せることが重視されます。

  

DAAQ とは

DAAQ (DeNA AI Advanced Quality) は、DeNA が独自に開発している QA 特化型の AI ツールです。テスト設計・テスト実行の支援から始まり、仕様書の不備検出 (インスペクション) にも対応しています。DAAQ の全体像やテスト設計を支える仕組みは、 こちらの記事 で紹介しています。

インスペクションは図のように、仕様書一式を投げて検査対象と参照資料を選ぶと、原文の引用つきの指摘一覧が返る作りです。内部では、関連資料をベクトル検索で絞り込み、検査対象の本文と確認観点の基礎知識とともに 1 つのプロンプトにまとめて LLM を 1 回呼びます。手順を固定することで出力の安定性を優先した設計です。LLM の呼び出しが 1 回で済むため、実行コストも抑えられます。

Agent 型の提案

QA の現場では、サービスや案件ごとに仕様書の形式も求められる成果物も変わるため、同じやり方では進められません。ドキュメントの形式はそろえられないので、DAAQ のインスペクションは、どんな形式の資料にも対応しつつ、QA エンジニアが見るのと同じ観点で不備を指摘できることを目指しています。QA チームへのヒアリングでは、「形式の異なる仕様書もそのまま扱いたい」「複数の資料をまたいで突き合わせたい」「人がチェックする前の初期品質をなるべく高めたい」といった、手順を固定した作りの延長では実現しにくい使い方への期待が挙がりました。

そこで今回、手順を LLM に委ね、LLM が自分で資料を検索・熟読して回りながら、複数ターンで成果物を作り込む Agent 型を試作しました。Agent 型は、どの資料をどの順に読むかを LLM 自身が決める自律探索ループです。Agent 型にすると何が変わるのかについて、次の 3 つの仮説を立てました (図)。

1. 資料を原本のまま渡して読み回らせれば、形式の違う仕様書も扱え、資料をまたぐ食い違いも拾える: ヒアリングの「形式の異なる仕様書もそのまま扱いたい」「複数の資料をまたいで突き合わせたい」に対応する仮説です。
2. 生成した指摘を別の LLM に判定させて返せば、自由度を上げても不要な指摘は抑えられる: ヒアリングの「人がチェックする前の初期品質をなるべく高めたい」に対応する仮説です。生成した指摘を別の LLM に判定させ、その結果を Agent に差し戻して考え直させます。
3. 制御を掛ければ、手順を委ねても出力形式の安定と低コストは保てる: 読む資料やターン数を LLM が実行ごとに決める Agent 型では、出力形式の安定性、実行ごとの揺れの少なさ、低コストが崩れやすくなります。ツール操作や出力を検査する制御を外から掛けることで、これらを保てるという仮説です。

この仮説に対応して、評価の観点を網羅性 (仮説 1)、精度 (仮説 2)、形式・安定性・コスト (仮説 3) の 3 つとしました。仮説を確かめるには指摘の良し悪しを測れる必要があるため、評価の仕組みづくりも今回の課題としました (4 章)。

3. Agent 型の実装

今回 Agent 型は Claude Agent SDK で実装し、LLM の呼び出しは Google Cloud の Vertex AI 経由で行っています。Claude Agent SDK は環境変数で接続先を Vertex AI に切り替えられるので、Google Cloud のプロジェクト ID とリージョンを渡すだけで、Anthropic の API キーを持たずに社内の Google Cloud 環境から Claude を呼ぶことができます。

• Claude Agent SDK

  Claude Code の Agent ループをライブラリとして呼び出せるもので、ファイルの読み取り・検索・書き込みといったツール、複数ターンの会話管理、ツール実行の前後に処理を挟むフック、ツールごとの許可判定などを簡単に実装できます。

アーキテクチャ

Agent 型は、LLM が自分で資料を読み回り、複数ターンで指摘を作り込む構成です。処理は次の 5 段階です。

1. 作業フォルダーの用意: 検査対象の資料と関連資料を、原本のまま専用の作業フォルダーに置きます。
2. 自律探索: Agent はファイル検索と読み込みのツールを使い、複数ターンにわたって資料を検索・熟読して回ります。必要な資料を必要な分だけ、何度でも読みに行けます。網羅性を高めるための仕組みです。
3. 成果物の書き出し: 指摘を JSON ファイルに書き出します。書いた直後に、後述の「出力の検証」で形式と原文引用を確かめます。
4. 評価結果のフィードバック: 確定する前に評価結果を同じセッションに返し、再考させます。精度を上げるための仕組みで、中身は 4 章で説明します。
5. 対話による調整: 初回の出力が確定した後も同じセッションが続き、要望を会話のターンとして受け付けます。履歴が残るので、指示を積み重ねたり、直前の状態に戻したりできます。

制御

Agent は自由に動くことができる一方で安定性に欠けることがあり、実際、初期段階では作業フォルダー外の書き込みや出力の形式違反が見られたため、以下の 4 つの制御を SDK のフック機構で設けました。これらの制御は、開始前・ツールを呼ぶたび・指摘を書いた直後・実行全体の 4 か所に配置しました。これらは、手順を Agent に委ねても形式・安定性・コストを保つための仕組みです。

1. 見せる情報の限定: 無関係な情報の混入や機密の漏洩を防ぎます。検査対象と関連資料だけを置いた専用の作業フォルダーを与え、それ以外は見せないようにします。
2. 読み書きの検査: 作業フォルダーの外への読み書きを防ぎます。ツール操作を実行する直前に宛先を検査し、範囲外なら理由をつけて拒否し、Agent が次のターンでやり方を直せるようにします。
3. 出力の検証: 形式の崩れと引用の捏造を防ぎます。指摘ファイルを書いた直後に JSON 構文と原文との一致を照合し、崩れていればその場で直させます。
4. 実行の上限: 同じ処理を繰り返して終わらなくなったり、応答が返らなくなったり、費用がかさみすぎたりするのを防ぎます。ターン数・時間・費用に上限を置き、超えたら打ち切って理由を記録します。

4. 評価の実装

2 章で決めた 3 つの観点 (「網羅性」「精度」「形式・安定性・コスト」) を測るには、それぞれに合った評価の仕組みが必要です。そこで以下の 3 つの手段を組み合わせて評価させることにしました。

1. 機械検査: 出力形式や原文引用の一致を機械的に検査します。
2. LLM as a Judge: 指摘の妥当性や同一性を、生成とは別に呼び出す LLM に判定させます。
3. 人手評価: QA チームに、指摘が「必要」か「不要」かを判定してもらいます。精度の最終的な判断はここに置きます。

LLM as a Judge の検証

LLM as a Judge は評価の基準そのものなので、使う前に人手と突き合わせて検証しました。検証には、5 章で使う人手評価とは別に、QA 担当者に少数の指摘を判定してもらったラベルを使っています。

1. 壊した指摘を見抜けるか: 引用や論理をわざと壊した指摘を混ぜて判定させ、100% を検出しました。
2. 同じ論点かの照合: 同じ文書を何度か実行すると、言い回しは違っても中身が同じ指摘が出てきます。こうした同じ中身の指摘のまとまりを、ここでは「論点」と呼びます。2 つの指摘が同じ論点かの判定は、人がつけた正解との一致率が 94% でした。合格として、答えの一覧との照合と、複数回の実行の論点をまとめるときにそのまま使います。
3. 妥当性の判定: 一致率は 79% でしたが、食い違った指摘の中には、人が必要と判定したものをノイズとした例がありました。正しい指摘まで消してしまうおそれがあるため、単独では使わず、人手評価と併用します。

評価の設計で注意した点

評価を設計するにあたり、以下の 3 点に注意しました。

1. 判定に根拠の引用を付けさせる

   ノイズ (指摘として妥当ではないもの) と判定した理由ごとに、根拠にした原文を引用させます。人は引用箇所を見るだけで判定の当否を確かめられ、人の判断と分かれたときも、どちらが正しいかを確かめられます。

2. 判定基準を 1 か所にまとめる

   ノイズとみなす基準を 1 つのファイルに定義し、LLM as a Judge のプロンプトに組み込むとともに、QA チームにも判定のときに使ってもらいました。基準がずれていると、判定が食い違ったときに LLM as a Judge の誤りか基準の違いかを区別できないためです。

3. LLM as a Judge に指摘を消す権限を与えない

   妥当性の判定は人手との一致が十分ではないため、LLM as a Judge はノイズと判定した指摘を消さずに理由と根拠を返すだけにし、残すか取り下げるかは Agent か人が決めます。

網羅性の評価

網羅性は、必要な指摘をどれだけ拾えたかで測ります。仕様書の不備をすべて洗い出した正解はないため、矛盾の埋め込みテストで正解がわかる状態を作って確かめます。関連資料に検査対象と食い違う記述をあらかじめ書き込み、それを拾えたかを数えます。拾えたかどうかはプログラムで機械的に判定し、最後に目で確認します。

精度の評価

精度は、不要な指摘をどれだけ抑えられたかで測ります。QA チームの判定は信頼できる一方で、工数がかかり一部の指摘にしか使えないため、すべての指摘にかけられる LLM as a Judge と併せて、次の 2 つを見ます。

1. QA チームの判定で必要率を出す: QA チームに指摘を「必要」か「不要」かで判定してもらい、答えの一覧を作ります。新しく実行したら、出てきた指摘を一覧と照らし合わせ (同じ内容かどうかは LLM as a Judge が判定)、一覧に当たった指摘のうち「必要」と判定された割合 (必要率) を出します。あわせて、「必要」の論点を拾える数が減っていないかも確かめます。
2. LLM as a Judge の 6 つの検査: 指摘 1 件を、引用が原文に実在するか、原文から導けるか、取り消し線や廃止で無効になった記述を対象にしていないか、対象文書にすでに書かれていないか、関連資料にすでに書かれていないか、対象範囲内かの 6 つに通し、「妥当」「ノイズ」「判定不能」のいずれかに振り分けます。1 つ目だけは文字列照合で、残りは LLM が判定します。

形式・安定性・コストの評価

形式とコストは機械検査で測ります。安定性は、同じ論点かの LLM as a Judge で論点をまとめてから機械的に数えます。

1. 形式: 指摘テーブルが読めるか、必須の列が揃っているか、確認観点や優先度が決められた選択肢の中か、指摘文の構成が規約どおりか、原文引用が一字一句一致するかを検査し、合格率を出します。
2. 安定性: 同じ文書を複数回実行し、各論点が何回の実行で出たかを見ます。
3. コスト: 実行ごとの費用とターン数を記録します。

評価結果を Agent に返す

評価結果を同じセッションに返して再考させることで、Agent の精度向上を図りました。

1. 機械検査で形式の崩れと引用の不一致を返す: 3 章の制御の「出力の検証」で、指摘ファイルを書いた直後にその場で直させます。
2. LLM as a Judge で妥当でない指摘を返す: 書き終えて確定する前に 6 つの検査にかけ、ノイズと判定した指摘を理由と引用つきで返します。仮説 2 (判定結果を返して再考させる) を実装した部分です。
3. 機械検査で指摘のない見出しを返す: 本文があるのに指摘が 1 件も付いていない見出しを列挙して返し、その範囲に見落としがないか再確認させます。

5. 評価の結果

2 章で決めた 3 つの観点ごとに、試作を評価した結果を見ていきます。

網羅性 (仮説 1)

矛盾の埋め込みテスト

PRD 1 本を対象に、関連資料の側へ検査対象と食い違う記述を 10 件書き込み (数値・条件・表記)、関連資料を全文で渡した Agent が拾えるかを試しました。

あわせて、指摘を書き終えたあとに、検査対象の数値・条件・名称を 1 つずつ関連資料と照らし合わせ、食い違いを矛盾として追加させる作業 (以下、突き合わせ) をもう 1 周させる条件も試しました。このとき、まだ開いていない関連資料の一覧も添えています。各条件を 3 回ずつ実行し、10 件のうち拾えた数を数えました。

突き合わせをもう 1 周させると、確認した資料が倍に増え、拾えた矛盾も増えました。費用は約 1.6 倍です。LLM as a Judge のフィードバックと組み合わせても拾えた数は減らず、増えた矛盾の指摘もすべて資料に実際にある食い違いでした。

補足: 想定外の形式の仕様書

2 章で挙げた「形式の異なる仕様書もそのまま扱いたい」も試しました。Word 文書と、表計算ソフトを方眼紙のように使ったシーケンス図を、テキスト化のコードを渡さずにそのまま Agent に渡しました。3 回実行した結果は次のとおりです。

精度 (仮説 2)

4 章で説明した 2 種類のフィードバック (妥当でない指摘の差し戻しと、指摘のない見出しの列挙) を入れたときに、不要な指摘を抑えられたかを、必要率とノイズ率で確かめました。

必要率とノイズ率

PRD 5 本を対象に、関連資料の全文を渡す条件で、フィードバックあり・なしを 3 回ずつ実行して比べました。

人手と LLM as a Judge のどちらで見ても、フィードバックを入れると不要な指摘が減りました。また、不要な指摘を減らしても、QA チームが「必要」と判定した論点を拾える数は減りませんでした。

フィードバックの組み合わせ

どのフィードバックが効いたかを見るため、PRD 1 本を対象に、検査対象だけを渡して、フィードバックなしと 2 種類のフィードバックをそれぞれ足した条件を 3 回ずつ実行しました。

下がり幅は、指摘のない見出しの列挙のほうが大きくなりました。精度と費用のどこで折り合うかは、使い方に合わせて決める必要があります。

差し戻された 15 件のうち、維持が 11 件、修正が 1 件、取り下げが 3 件で、Agent は差し戻しを受けて指摘を改めて考え直し、根拠があるものは自分の指摘として残していました。

形式・安定性・コスト (仮説 3)

形式

3 章の制御がどう働いたかを、これまでの実行の記録から集計しました。

「拒否 + 理由」を返す設計にしたことで、制御は Agent を止めるだけでなく、Agent が自分で直して続行するきっかけになりました。

また、費用の上限は 1 回の応答が終わるたびにしか確かめられないため、設定した金額を超えてから止まることがありました。

安定性

PRD 5 本を 3 回ずつ実行すると、Agent が出した論点の約 7 割は 3 回のうち 1 回しか出ませんでした。どの論点を拾うかの揺れは、制御では消せません。そのため、評価では複数回の実行を「同じ論点か」の LLM as a Judge でまとめてから数えました。

コスト

PRD 5 本を関連資料の全文つきで検査したとき、1 文書あたりの費用は平均約 0.7 ドル、初回の出力までの時間は平均約 6 分でした。フィードバックを入れると、平均約 1.0 ドル・約 12 分になります。ターン数・時間・費用には上限を置いているので、Agent が暴走しても上限で実行を打ち切ります。

仮説ごとの結果

6. まとめ

本インターンでは、DAAQ の仕様書インスペクションを題材に Agent 型を試作し、その指摘を測る評価の仕組みを作って確かめました。その結果、網羅性 (仮説 1) は突き合わせの手順を足すことで資料をまたぐ矛盾を拾えるようになり、精度 (仮説 2) はフィードバックで改善できました。形式・安定性・コスト (仮説 3) は、形式は制御で保てた一方、実行ごとの揺れと費用には課題が残りました。

学んだこと

一番難しかったのは、インスペクションの良し悪しを測ることでした。指摘が必要かどうかは人が見ても判断に迷うことがあり、決まった正解もないため、Agent の作りなのか、入力や指示なのか、実行ごとの揺れなのかを切り分け、直しては測り直しました。この試行錯誤を通じて、QA のように良し悪しを測りにくい対象ほど、どう評価するかを決めることが大切だと学びました。

次にやりたいこと

今回は QA チームの負担を減らすため、過去の実行の指摘を一部だけ判定してもらいました。この一覧は仕様書の不備をすべて含むものではないため、網羅性は矛盾の埋め込みテストでしか測れていません。次は QA チームが普段どおりにインスペクションした結果を、判定の理由も付けて正解とし、実際の仕様書でも網羅性を測れるようにしたいです。

また、突き合わせで拾える矛盾は増えましたが、どの資料と照らし合わせるかは、まだ Agent の判断に頼っています。照合する相手の洗い出しはプログラムに任せ、Agent には食い違いかどうかの判断だけをさせるなど、照合を決まった手順として組み込みたいです。

感想

試作を作るだけでなく、それをどう測るかまで自分で考えて決めていく経験は、とても学びの多いものでした。方針に迷うたびに相談に乗ってくださったメンターの菅原さん、DAAQ チームとして今回の取り組みを支えてくださった藤﨑さん、ヒアリングや指摘の判定に何度も協力してくださった QA チームの皆さん、本当にありがとうございました！