DeNA、仕様書インスペクションをAgent化　評価設計まで試作

編集: グリットアーツ編集部

公開日：2026年10月24日

3行解説

ニュースの概要

DeNAは2026年10月23日、エンジニアブログで、QA支援LLMアプリ「DAAQ」の仕様書インスペクションを題材にしたAgent型の試作と、その評価の仕組みを公開しました。執筆者はインターン参加者の岩月優樹氏です。記事では、仕様書の不整合や記載漏れを見つける工程を対象に、LLMが資料を検索しながら複数ターンで指摘を作る構成を試したこと、あわせて出力の妥当性を判定する評価基盤を作ったことが説明されています。

何が新しいのか

従来のDAAQでは、関連資料をベクトル検索で絞り込み、検査対象の本文と確認観点を1つのプロンプトにまとめてLLMを1回呼ぶ方式でした。これに対し今回の試作は、LLM自身がどの資料をどの順に読むかを決めるAgent型に変えています。狙いは、形式の異なる仕様書や複数資料の突き合わせに対応しやすくすることです。

同時に、自由度を上げたことで起きやすい崩れを抑えるため、作業フォルダー外の読み書き防止、出力JSONの検証、実行回数や時間、費用の上限設定をフック機構で入れています。つまり、「自由に読ませる」だけでなく「どこまで許すか」を外側で制御する設計です。評価も、網羅性・精度・形式安定性・コストの3観点に分けて組み立てています。

グリットアーツ編集部の分析

このニュースで実務上重要なのは、Claude Agent SDKを使っても、自由度を上げるだけでは運用できないと示した点です。DeNAは作業フォルダー外への書き込み防止、出力検証、実行上限を明示的に入れています。AIエージェントはPoCでは動いても、本番では暴走防止と再現性の確保が必要になります。今回の構成は、その境界をどこで引くかを考える材料になります。

また、評価を「網羅性」「精度」「形式・安定性・コスト」に分けたのは、導入判断に使いやすい切り分けです。特に、LLM as a Judgeを単独採用せず、人手評価と併用した点は重要です。自動評価だけで品質を決めると、必要な指摘まで落とす可能性があるためです。AI基盤の検討では、モデル性能だけでなく、評価設計そのものが運用品質を左右します。

日本の現場で考えると

日本の開発現場では、仕様書の形式が案件ごとにばらつきやすく、複数資料をまたいだ確認も多いです。そのため、今回のようなAgent型は、資料の読み回りが必要なQA支援には向きやすい一方、入力形式が比較的そろっていて処理手順を固定しやすい業務では、従来型の方が運用しやすい可能性があります。

一方で、Agent型は便利になるほど、権限管理やログ確認、失敗時の打ち切り条件が重要になります。社内のGoogle Cloud環境からClaudeを呼ぶ構成でも、どの範囲のファイルを見せるか、どこまで自動で書き戻すかを決めないと、品質より先に運用負荷が増えます。日本企業で導入するなら、QA部門だけでなく、情報システム部門やセキュリティ部門との調整が前提になります。

導入・検討時に確認したいこと

• 作業フォルダー外への読み書きを、どの権限設計で止めるか。
• 出力JSONの検証で、どのエラーを自動修正し、どこで人手確認に回すか。
• ターン数・時間・費用の上限を、業務上どの水準に置くか。
• LLM as a Judgeの判定を、どこまで自動採用し、どこを人手評価に残すか。
• 対象文書の形式差や資料数が増えたときに、性能と再現性が保てるか。

現時点で分かっていないこと

記事では、実運用で採用するための合格基準や閾値は示されていません。また、対象文書の規模、処理時間、費用の具体値も本文にはありません。どの程度の品質向上があれば手順固定型から切り替えるのかは、別途確認が必要です。

AIエージェントは自由度が上がる一方で、制御や評価の設計が甘いと運用で崩れやすくなります。自社のAI基盤や検証環境で何を先に固めるべきか、整理したい場合はご相談ください。

出典: DeNA Engineering