はじめに

2026年9月29日に開催された「DeNA × AI Talks #9 LLMとどこまで付き合ったか」に参加してきました。DeNAのAIスペシャリストの方々が、サービスに組み込み済みのものから検証中のものまで、LLMとの付き合い方を話すイベントです。会場は渋谷スクランブルスクエア40Fでした。

自分はQAエンジニア2年→開発エンジニア半年の若手です。最近は NanoClaw を使って、Slackを窓口にしたテスト自動化の仕組みを自分でも作っていました。なので後半のQA系の2本は特に前のめりで聞いたんですが、正直、レベルが高いなと実感しました。自分が「AIに任せたら動いた」で止まっていたところを、DeNAの方々は「AIが間違える前提で、どこを機械で答え合わせするか」まで設計していたからです。

筆者のメモと、公開スライドをもとにした参加レポです。数字はできるだけ公開スライドで確認しましたが、細かいところが違っていたらすみません（気づいた方はコメントで教えてください）。

イベントの概要

発表	登壇者	ひとことで
GPU不要！SLM・BERTによる音声対話向け高速ターン検出モデル	佐藤悠翔さん	小さいモデルでも、CPUだけで実用的に判定できる
そのライブラリ、モデルと相性いいですか？	吉田さん（オンライン）	同じモデルでも、ライブラリ次第で結果がだいぶ変わる
QA領域でのLLM活用：確認を楽にする工夫と利用データの活かし方	菅原勇紀さん・松山厚弘さん	生成で終わらせず、人の確認と評価まで設計する
スマホ操作をLLMに任せよう	菅藤佑太さん	AIを判断の中心に置かない

4本ともスライドが公開されています（参考にまとめています）。並べてみると、「LLMに何を任せて、何を任せないか」をそれぞれの現場で決めている、という点が共通していました。

GPUなしで78.4ms：文字だけで「話し終わり」を判定する

音声で会話するAIで、「ユーザーが話し終わったか」を判定するモデルの話です。

本来は音声データで学習したいところですが、使えるデータがほとんどなく、録音から集めるとお金もかかります。そこで、音声は使わず、文字起こしのテキストだけで判定するモデルを作ったそうです。

学習データは、1つの文を「途中まで話した状態」に細かく切って作ります。最後まで話した行だけを「話し終わり」、途中の行は「まだ話している」として覚えさせる、という作り方です。

最初はCPUで1回の判定に約860msかかっていましたが、軽量化して平均78.4msまで速くなったそうです。高いGPUも大きなLLMも使っていません。

ただし、文字だけだと「そうですね…（考え中）」と「そうですね。（言い切り）」が同じに見えてしまう、という弱点もあるとのことでした。

ライブラリとモデルの相性は、思ったより大きい

吉田さんの発表は、AIエージェントを作るときのライブラリ選びの話でした。LangChainのようなライブラリを使うと楽に書けますが、モデルとの組み合わせによっては結果がかなり変わるそうです。

結果を少しずつ画面に出したいとき、ライブラリ経由だと最後にまとめてしか返ってこないことがある。公式SDKで受け取って自分で組み立てるほうが細かく出せる
決まった形式（JSON）で答えさせると、発表時点の検証では、公式SDKなら失敗率9%なのに、LangChain経由だと約半分が失敗したケースがあった
ツールを何十回も呼ぶ複雑なタスクでは、ライブラリによってエラーで途中停止したり、最後までやりきれたりと差が出た
モデルやライブラリが更新されると、細かい初期設定が変わることがある。乗り換えるときは公式ドキュメントの確認が必須

QA領域でのLLM活用：AIに作らせて終わりにしない

ここからが元QAとして一番刺さった2本です。

菅原さん・松山さんの発表は、DeNA社内で作っているQA支援ツール DAAQ の話でした。冒頭で「DeNAではQAコストが年間数十億円規模」と出てきて、規模感にまず驚きました。

DAAQは仕様書からテスト項目表を作るツールで、成果はテスト作成工数80%削減、作成結果の95%が修正不要。そこに至るまでの工夫は4つありました。

どんな形式の仕様書でも受け取る: 表計算・文書・PDF・画像などを共通の入口で読み込む
AIに任せる所と、プログラムに任せる所を分ける: 仕様を読んで観点を考えるのはAI。条件の組み合わせを数えるような、答えが1つに決まる作業はプログラム
人が確認しやすくする: テスト作成を4つの工程に分け、工程ごとに人がチェックするポイントを絞る
使った結果を貯める: 人が直した内容を記録して、次の改善に使う

評価を「QAのレビュー頼み」から外した話

AIの設定を変えるたびに「前より良くなったか」を確かめる必要がありますが、最初はQAチームが目で見て確認するしかなかったそうです。

そこで正解データを用意して、自動で答え合わせする仕組みを作りました。ただ、AIが出すボタンの名前が「ログインボタン」「ログイン」「Login」のように毎回揺れて、名前ではうまく照合できなかったそうです。

解決策は、AIに画面上のどこにあるか（枠の位置）も出させること。名前ではなく枠の重なり具合で照合すれば、名前の揺れに左右されません。

さらに、この枠を人の確認画面にもそのまま使ったのがうまいなと思いました。スクショの上に枠と番号が出るので、「このテストは画面のどのボタンの話か」がひと目でわかる。以前は表とスクショを見比べる手作業だったそうで、QA時代にこれ欲しかったです。

スマホ操作をLLMに任せよう：AIを判断の中心に置かない

菅藤さんの発表は、スマホアプリの確認作業をAIに任せるツール Ishizue の話でした。

リリースのたびに、人が同じ長い操作（1回30分〜1時間）を手で繰り返していたそうです。ところが、AIに画面を見せて丸投げすると、こんなふうにうまくいきませんでした。

同じ画面を「新しい画面だ！」と勘違いして行ったり来たりする
押す位置がずれる
スクロールしないと出てこないボタンに届かない

そこで出した答えが「AIを判断の中心に置かない」です。決まった処理はプログラムに任せ、AIには「どれを押すか選ぶ」など一部だけをやらせ、最後にプログラムで答え合わせする。AIを上下から挟むような作りです。

確信度1.00でも間違える

録画からAIに「どのボタンを押したか」を推定させたところ、AIは確信度1.00（100%）で「スキップ」と答えたのに、正解は「はい」だったそうです。AIが自信満々でも間違えることがある、という話でした。

もうひとつ面白かったのが「AIに座標を答えさせない」工夫です。縦長の画面だと、AIが答えたボタンの位置が実際とは大きくずれる。そこで、先にプログラムで画面上のボタンに番号を振っておき、AIには「6番」のように番号を選ばせるようにしたそうです。

結果は、定型画面の確認で月の作業時間を最大約95%削減、確認漏れは46件→1件。すでに正式導入されているそうです。

まとめ

小さいモデルでも、用途に合ったデータがあればCPUで十分動く（ターン検出）
同じモデルでも、ライブラリ次第で結果が変わる（ライブラリとの相性）
DAAQもIshizueも、AIの答えをそのまま信じない作りになっていた。考えるのはAI、数える・照合するのはプログラム、最後は人が見やすい形で確認する

自分もNanoClawでSlackを窓口にしたテスト自動化を作ってみて、「AIに投げればテストが回る」ところまでは来ていました。でも今回の2本を聞くと、本当に難しいのはその先で、AIが間違える前提で、どこをプログラムで答え合わせするかを決めるところなんだなと。枠の位置を評価にも確認画面にも使い回すやり方は、自分の仕組みでも真似できないか試してみます。

参考

関連記事

「非開発組織のAIXを掘り下げる会」参加メモ（2026-09-28） … 前日に参加した勉強会のレポ。こちらは非エンジニア組織にAIをどう広めるかの話
「一緒にいて楽しい人を採用するようになった」── AI時代のCTOお悩み相談室で聞いた、エンジニア組織のこれから … 現場の技術の話に対して、CTOたちが組織目線でAI時代を語ったパネルのレポ
「お前がみろ」はAIに効くのか。高圧的なプロンプトで回答精度を検証した … AIの出力の当たり外れを、自分で回数を回して確かめてみた検証記事

告知

最後にお知らせとなりますが、イーディーエーでは一緒に働くエンジニアを募集しております。
詳しくは採用情報ページをご確認ください。

みなさまからのご応募をお待ちしております。