--- title: スマホ操作をLLMに任せよう LLM に「押させる」前に決めたこと tags: #dena ai talks author: [DeNA_Tech](https://docswell.com/user/DeNA_Tech) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/G75M9XPG74.jpg?width=480 description: 2026年9月29日に開催した「DeNA × AI Talks #9 LLMとどこまで付き合ったか」の登壇スライドです。 イベント概要：https://dena.connpass.com/event/404885/ published: September 30, 26 canonical: https://docswell.com/s/DeNA_Tech/5X2N6P-2026-09-30-123841 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/G75M9XPG74.jpg) スマホ操作を LLM に任せよう LLM に「押させる」前に決めたこと 共通コアと差し込み式パッケージ、途中で見えたこと、まだ答えが出ていない問い OK: ショップのボタン Yuta Sugafuji # Page. 2 ![Page Image](https://bcdn.docswell.com/page/9J292X6DER.jpg) 自己紹介 菅藤 佑太 (すがふじ ゆうた) IT本部AI・データ戦略統括部AIプロジェクト推進室 IT本部AI・データ戦略統括部AI技術開発部AIジャーニー推進G 大阪育ち→大学入学から上京→2024年に大阪に引っ越し ~2018年 自然言語処理×ネットワークセキュリティの研究 2019年~ 古のベンチャー企業に新卒入社 2021年~ 教育系サービスの会社を作る&YouTuber 2023年~ 複数社の会社経営 DeNA入社 全社生成AIツールのSAIのPdM 2024年~ 慶應義塾大学 生成AI利活用戦略ユニットメンバー 2025年~ エンジニアに転向 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/DEY4Y89MJM.jpg) オープニング 本日のアジェンダ ① 2分 ② 6分 OK ③ 3分 B ④ 3分 ⑤ C 5分 ？ A コア 壊れ方と 答えの型 技術の工夫 コアと 個別パッケージ 実利 人に届ける 難しさ ほか AI を判断の 中心に置かない 押す前に確かめる AI は読むだけ 工夫の多くが アプリ固有の 知識だった 効いた所と、 効かなかった所 LLM と作った開発 未解決の問い # Page. 4 ![Page Image](https://bcdn.docswell.com/page/VJNYPQL378.jpg) 課題とアプローチ # Page. 5 ![Page Image](https://bcdn.docswell.com/page/YE9P3D4PJ3.jpg) 1. ニーズと課題、答えの型 なぜ作ったのか 毎リリース、人が同じ長い操作を繰り返していた ── 3つの期待と、3つの壁 1 現場で起きていたこと 現場 毎リリース 2 求められたこと 品質管理 ニーズ 3 立ちはだかった壁 まず 課題 普通の自動テスト テスト工数を半分に 期待結果を書き切れない （画面が多すぎる） 上位 生成 AI に丸投げ AI で新しい価値を 往復する／位置がずれる／ 画面外に届かない 1回 30分〜1時間 長い操作を手でやったとき （ある安定性確認の例） 更新の多いアプリで 月に数十本 対象画面をすべて 撮影して確認 事業部 自動プレイと、 開発中の品質を ? 何も与えない端末 自律操作は まったく動かなかった 同じ道具に、3つの期待が乗った 問い：LLM に「押させる」前に、何を決めておけばいいか？ 3 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/GE8DM3QXED.jpg) 1. 壊れ方と答えの型 長い確認操作と、AI に任せたら壊れた3つ 人がやっていること AI に画面を見せて任せたら 1 30分〜1時間 長い操作シナリオを手で1回 （ある安定性確認の例） それを毎リリース繰り返す （また）新しい画面だ！ 2 3 ↓ 画面の外 さっきと同じ 同じ画面を「新しい画面」と誤認して 往復 → だから、AI を判断の中心に置かない設計へ 狙い 押した所 目的の項目 押す位置がずれる スクロールしないと出ない 要素に届かない # Page. 7 ![Page Image](https://bcdn.docswell.com/page/LELM3VXN7R.jpg) 1. 壊れ方と答えの型 Ishizue とは？ 生成AIを利用して録画から、再生・読み取りまで行うプロダクト 1 2 録画する 台本にする REC 3 事前解析 前 記録 1. タップ 97, 294 2. タップ 282, 258 2 いま 3. タップ 246, 424 図はイメージ（数値と座標は例） 重い AI 処理は ここで1回だけ 後 読むだけ 3 タップ位置と、 タップごとのスクショ 読み取って記録 JSON 台本 1 4 再生する 差分を記録 +500 同じ画面を待って押す 来なくても5秒で押す 読み取って判定に利用 する土台を作る # Page. 8 ![Page Image](https://bcdn.docswell.com/page/4JMYDGLQJW.jpg) 1. 壊れ方と答えの型 答えの型: AI を判断の中心に置かない 決定論の土台と、機械の答え合わせで上下から挟む = Σ 指紋の一致 合計の検算 答え合わせ （機械） 取りこぼしの自己検算 ※ 不具合の判定ではない ⇄ どこまで届いたか 通信データと 表示の突合 到達 目的の画面まで操作できる 生成 AI 1 2 「3」 3 観測 選ぶ・分類する・ 確かめる だけ 画面・数値・構造を記録できる 判定 決定論の 土台 記録した座標 画面指紋 安全装置 器と第1観点（クラッシュ検知）は 配線済み。当たったかを測る正解デ ータはまだ少ない。 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/PJR94ZKK79.jpg) 技術的工夫 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/PEXQ29L5JX.jpg) 2. 技術の工夫 確信度 1.00 でも間違える ── そして、座標も間違える 初期: 動画から AI が推定 後日: 同じ「はい」・同じ座標で押すと 録画 座標で押す AI が読む 「戻る」 確信度 0.98 AI に位置を解かせる 背景に 当たって 閉じる 「スキップ」 確信度 1.00 「いいえ」を 押して 閉じる 購入されない 購入されない 録画の座標 正解は「はい」 → そこで記録座標を正とした どちらも実行されない（記録上 座標側5件・AI側6件） 今の判断 記録と同じ画面か で決める 距離 記録 今 近い 遠い AI も解けない 座標で押す AI で位置を解く 止める # Page. 11 ![Page Image](https://bcdn.docswell.com/page/3EK9MPLRED.jpg) 2. 技術の工夫 LLM に座標を書かせない 番号付きの枠から「選ばせる」（Set-of-Mark） 座標を答えさせる 番号を選ばせる 1 AI の答え y = 951 1 2 3 2 3 4 5 4 5 6・受け取る 実際のボタン 6 y ≈ 1990 7 （端末の座標） 縦長の画面で 大きくずれた ① 文字認識と輪郭で 枠を列挙 6 8 ② 枠に番号を描く 突破口: 普通の画像処理で番号付けが作れた 7 8 ③ AI は番号と ラベルだけ答える # Page. 12 ![Page Image](https://bcdn.docswell.com/page/L73WYX3G75.jpg) 2. 技術の工夫 pre-tap predict ① 押す前に、照準を重ねた画像で確かめる ① 予定点を決める ② 照準だけ重ねる ③ AI が JSON で判定 ④ 補正して押す NG・もっと下・わずか 枠の中心を 押す予定の点に 十字と中心点だけ 描いて見せる "verdict": "ng", "direction": "below", "offset": "slight", NG のときの直し方（判定は最大4回） 下へずらし再判定 → OK → 押す 但し書き（fail-open） ? わずか・近い 同じ候補の中で 少しずらす 遠い その方向の 実在の候補へ 画面外 縦にスクロール して探し直す ずらした点を ③ でもう一度判定 NG のまま4回 押さずに 飛ばす 答えが無い 確認なしで そのまま押す # Page. 13 ![Page Image](https://bcdn.docswell.com/page/87DK524NJG.jpg) 2. 技術の工夫 pre-tap predict ② 見せる絵の描き方で判定が変わる／探すより確かめる方が当たる 枠を描いて見せる 照準1点だけ（探索で採用） 枠つきのまま動く一覧選択: 判定 441回を再集計 上下の二分探索（最大20回）での実測 最終 OK 124件（1マス＝1件） OK NG 誤り 枠を「答えの範囲」と読むらしい 初回で OK: 49件（約40%） 正しい 2回目以降 何回目で OK 照準1点の効果は未計測 中央値 2回目 最大 12回目 上限 20回 探すより、確かめる方が当たる（確認ダイアログの例） ① 位置を探す AI ② 確かめる AI ③ ヒントで押し直す 目的のボタンを押せた 中心は 質問文 NG もっと下 押すと危ない側は アプリ固有 → 個別パッケージの ガードレールへ # Page. 14 ![Page Image](https://bcdn.docswell.com/page/VJPKG1MNE8.jpg) 2. 技術の工夫 毎回ちがう画面をどう吸収するか 待つ・区間で合わせる・2問に分ける 1 待つ 記録 2 区間で合わせる 3 入口 再生（今の画面）→ 出口 2問に分ける Q1 全体を見て 結果画面？ 記録 Q2 左下に ← がある？ 連打で飛ばす 2問とも「はい」で確定 指紋の 距離 再生 1問だけだと… 閾値 左下に ← ある？ 時間 → 最大5秒で打ち切り 出口: 指紋の「同じ」は信じない 結果画面？ AI を呼ばない → 速く、安く、毎回同じ 間は何コマでも、入口と出口だけ合わせる 隅の飾りを 「←」と誤判定 全体 → 決め手の部分、の順に聞く # Page. 15 ![Page Image](https://bcdn.docswell.com/page/2EVV6Y9YEQ.jpg) 2. 技術の工夫 AI は「読む」だけ、計算と検算はコード ── そして、検算は独立していなかった 画面（前・後） ① 切り出す ② AI は読むだけ ③ 計算はコード {"coins": 1250} 1750 − 1250 {"coins": 1750} 前 後 = +500 ④ 記録 前✓ 後✓ +500 読めない欄は null ※ 1,250 / 1,750 は模式図の例 同じ購入を2通りで確かめた {} AI に意味を答えさせる 正解の約7.7倍 数値の差分をコードで 本人の申告と一致 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/57GLN9ZWEL.jpg) 2. 技術の工夫 画像より先に「構造」を探す 読み方で、速さが桁で変わる 通信データ DOM エンジン内部の構造 画像＋文字認識 開発用ビルドが前提 開発者ツールが前提 まだ空白 協力なしで使える <ul> <li>商品A</li> <li>商品B</li> <li>商品C</li> <li>商品D</li> … </ul> { "商品A":"あり", "商品B":"あり", "商品C":"あり", … 全件 } スクロールせず全件 速い・アプリの協力が要る ? 1行ずつ 文字認識 遅い・協力なしで使える 1件あたりの所要時間 社内暫定値・対数目盛り 構造で読めるアプリ 混在 画像のみ 約35秒 約2分15秒 約50分 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/4EQYQWLQJP.jpg) 2. 技術の工夫 LLM を呼ぶのは「一度だけ・事前に」 費用と、出力の揺れの扱い 事前に1回 実行は何度でも AI を使う 画面指紋で照合 JSON 1回だけ 録画の画面 人が読んで直せる まだ消えていないもの {} 画像3枚 / 1操作 動画は読ませない 構造が取れれば AI なし 画像認識を呼ばない 月数千円規模 登壇者の記録。 請求明細とは未照合 ? 数えていない呼び出しがある → 記録上の回数は下限 出力の揺れは残っている → 揺れる観測と、判定を分けた # Page. 18 ![Page Image](https://bcdn.docswell.com/page/KJ4WNKDY71.jpg) 2. 技術の工夫 地図を自分で作る・日本語1行で動かす 動いたが、まだ遅く脆い部分もある アプリ内通貨を ○○個購入してください ホーム ショップ 購入 もう達成した！ 確認 ホーム まだ → 止める 1手 約40秒 実測41回の中央値: 7画面・15手 （別条件の記録では約21秒） ✓ 開発者の手元では完走 ✕ 候補の58.7%を黙って落としていた → 今は警告を出す # Page. 19 ![Page Image](https://bcdn.docswell.com/page/LE1Y5XZN7G.jpg) スケールの為の手法 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/GEWG5N6MJ2.jpg) 3. コアと個別パッケージ 工夫の多くは、アプリ固有の知識だった なぜ「コア」と「個別パッケージ」に分けたか Before After 本体 個別パッケージ if A: … B A D C A 分けた理由 A B C 固有の情報を 本体に残さない スケール B B コア C A 秘匿 1本ずつ作り込まず 件数を増やせる形に アプリ名を持たない 派生版を増やさない D アプリ D を足す → 本体を編集する アプリ D を足す → パッケージを1枚足すだけ 創出価値 ＝（1件あたり価値 × 件数 × 自動化率）−（費用） 分けて気づいた: コアのプロンプトが1つのアプリ前提で全アプリへ ← 件数を増やせる形にする コアは1つ。違うのは パッケージだけ # Page. 21 ![Page Image](https://bcdn.docswell.com/page/47ZLN3YMJ3.jpg) 3. コアと個別パッケージ 個別パッケージの中身 (1) 置き場所の規則と、画面の「読み方・辿り方」 個別パッケージ（アプリごと） 地図 ＝ データ 画面遷移図 読み方・辿り方 ＝ コード ショップ 確認 一覧 詳細 ホーム /shop {} アプリ A アプリ B アプリ C 画像 ＋ AI で読む URL → 目的の画面へ 通信データを正とする 画像テンプレートで特定 詳細は通信データから 依存は一方向 A {} B アプリごとの束（zip） コードの外で、別に運ぶ 何をどこに置くか C パッケージ （アプリごと） コア 値に見えてロジック → コード 判定の述語・操作の順序 ロジックに見えて値 → 値 純粋な対応表 個別パッケージ 3件 画面遷移図 3件 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/YJ6W8XD5JV.jpg) 3. コアと個別パッケージ 個別パッケージの中身 (2) アプリ特有の挙動を抑える「ガードレール」 パッケージが持つ ── アプリ固有の書き方 コアが全アプリに効かせる 購入・破壊の判定 開発メニューの判定 A B C D E 押さない アニメーション 確認ダイアログ 危険なボタン 取りこぼし検知 叩いて飛ばす位置 押してはいけない側 名前と押した後の照合 名簿で不足を名指し DEFAULT_WAIT = … 既定値 BTN_RE = r"…" 正規表現 SKIP_POS = (x, y) 固定座標 PROMPT = "…" プロンプト 制度的記憶 if 文ではなく、バグ修正の履歴として 4つの形でコードに散らばっていた 前景アプリの監視 STOP ホームに 落ちたら 5入力ごとに 確認 2回連続で 外れたら停止 約10秒以内 監視前は、落ちた後も最大1〜2分 叩き続けうる作りだった # Page. 23 ![Page Image](https://bcdn.docswell.com/page/GJ5M9X3GJ4.jpg) 価値創出 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/LE3WYX6PE5.jpg) 4. 実利 実利: 定型画面の全件読み取りと検算 月の運用工数を最大 約95% 削減 以前 今: 端末が一覧を自分で巡回する 名前 表示 突合 全件 マスタ 突き合わせ 対象画面をすべて 人が撮影して確認 監査担当 更新の多いアプリは月に数十本 最大 約95% 2つのアプリの月の運用工数 社内記録・最大工数基準 削減 漏れ 46件 → 1件 画像しか使えないアプリ。 残りは目視で補完 正式導入 運用は推進チームが運用中。 # Page. 25 ![Page Image](https://bcdn.docswell.com/page/8EDK52V37G.jpg) 4. 実利 効いた所・効かなかった所 どんな仕事なら効くか 現場の運用ルールで補った ↑ 正解を機械で検算できる 録画はホーム画面から始める 定型画面の監査 所持数をそろえる 効いた 日次の切り替わり時刻を跨がない 全部購入して並びをそろえる 不具合の判定 正解データが まだ少ない 毎月の定常確認 約7割を再生で テストの目的も問い直された 「そもそも回す必要があるのか」 撮影が目的の作業 状態を消費する操作 効かない 1日1回・売り切れ 1 2 3 人の操作を真似る 目的から逆算して探索する 更新の頻度 → # Page. 26 ![Page Image](https://bcdn.docswell.com/page/V7PKG1VPJ8.jpg) 取り組みの反省 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/2JVV6YZVJQ.jpg) 5. 途中で見えたこと 当時そう言っていた／いまはこう分かっている 測ったら、別の姿が見えた 当時そう言っていた 4月 5月 6月 「AI の幻覚を構造的に排除した。 偽陽性 −100%」 「最初に1時間ほどかければ、 どんなアプリでもできる」 「新しいアプリも固有コードなしで 着手できる」 いまはこう分かっている 9月 座標 AI 約5倍 8月 8月 「クラウド化は今週中に完了」 同じボタンで座標側も失敗。記録上ほぼ同数 どちらを信じるかではなく、照合で決める 途中 新しいアプリ1本で 7〜56日の見積り 読み方の経路によって約5倍違う 未解決 今動いているものは、 アプリごとの調整が前提だった 途中 翌日撤回。今も後回し 途中 自分の読み取り漏れの自己申告だった 不具合の判定に使うと約4割が誤検出 途中 4月 「合計の検算で答え合わせできる」 約4割 9月 測るたびに、見えていなかった側が出てきた # Page. 28 ![Page Image](https://bcdn.docswell.com/page/5EGLN941JL.jpg) 展開の難しさ # Page. 29 ![Page Image](https://bcdn.docswell.com/page/4JQYQWGN7P.jpg) 6. 人に届ける難しさ 社内で前例のないものを説明する 言葉が先に期待を作る 「パッケージ」 1 ← 人によって、指していたものが違った 2 3 </> 期待の方が、実装より先に走った 機能を組み合わせた シナリオ アプリ固有の コード 画面遷移の 貯め場所 事業部の期待 実装の進み 「ガードレール」 コアの安全装置 作り手に課す枠 アプリ固有の制御 # Page. 30 ![Page Image](https://bcdn.docswell.com/page/K74WNK53E1.jpg) 6. 人に届ける難しさ 同じ道具に、3つの期待 ニーズは「素朴な質問」から出てきた 品質管理 テスト工数の半減 「なぜこの業務に、こんなに工数が？」 作り手 上位 AI による 新しい価値 事業部 ？ ？ 開発中の品質（左シフト） 誰の成功指標で測る？ 自動操作と 開発中の品質 「更新がとても多い（月に数十本）」 現場 # Page. 31 ![Page Image](https://bcdn.docswell.com/page/LJ1Y5XWZEG.jpg) 6. 人に届ける難しさ 体感してもらうまでの距離 実は「伴走」が前提だった 約20回 使う人 作り手（横で伴走） 前提の状態を そろえる アカウント （アプリ内の 数値・ 開始画面・ エミュレータ 日付） コンテナ 環境 配布ファイル を展開 ようやく ツールの 機能 約半年で配布 （6月だけで約10回） 「最新版なのに変わらない」 原因は、画面の 古いキャッシュ 現場はコードを書き換えて使っていた APP_ID = "sample.a" 対象アプリの識別子の固定値を書き換え 自分で触れるまでに、環境構築の長い階段があった # Page. 32 ![Page Image](https://bcdn.docswell.com/page/GJWG5N6672.jpg) 6. 人に届ける難しさ 失敗から変えたこと 「作り切ってから渡す」をやめた 1 やったこと 目的の画面 約1か月 約1か月直しても、目的の画面に届かず # Page. 33 ![Page Image](https://bcdn.docswell.com/page/4EZLN3YR73.jpg) いまだ残っている課題 # Page. 34 ![Page Image](https://bcdn.docswell.com/page/Y76W8XD17V.jpg) 7. 未解決の問いと持ち帰り まだ答えが出ていない問い 技術よりも、組織と定義の側に鍵がある 正解データは 誰が作る？ ? Aa ≠ あ 正解の例が現場から 来ないと検証できない AI と地図は同じ 言葉を話しているか 蒸留 警報26件中21件は 「言葉」が違った 遅い 鍵: 現場 23語 鍵: AI と地図 どこまで汎用か ? ? 「1時間でどんな アプリでも」→ 1本 7〜56日の見積り 置き換えるか、 蒸留するか ? ¥ 高い 鍵: 開発 誰がパッケージを 書くか ? 非エンジニア向けの 画面は構想段階 汎用はそこそこ動くが 遅くて高い。 人をどこに残すか ? 正解データを誰が いつ作るかは、 組織の問い ? 鍵: アプリ側の協力 鍵: 組織 あなたの現場の「正常」は、誰が書いていますか？ 鍵: 運用 # Page. 35 ![Page Image](https://bcdn.docswell.com/page/G75M9X3L74.jpg) 7. 未解決の問いと持ち帰り 現場に持ち帰れること LLM に押させる前に決めること ── 任せる範囲、黙ったときの動き、誰が正解を書くか 技術として持ち帰る 1 仕事とチームに持ち帰る AI に位置を書かせず、選ばせる・確かめさせる。 見せる絵の描き方で判定が変わる 4 効くのは「高頻度 × 正解を機械で検算できる × 読み取り中心」の仕事。まずそこから始める 2 事実も変わるし AI も間違える。 どちらかを常に信じるのではなく、 「前提が今も成り立つか」を照合して決める 5 固有の知識は本体に埋めず、後から差し込む。 宣言が無ければ何もしない 3 AI を呼ぶのは事前に一度。読むのは AI、 計算と検算はコード。処理が止まってしまった ときの動きを先に決める。 6 言葉は先に期待を作ってしまう。 確定と未確定を言葉で書き分け、 許諾を先に取り、触れるまでの距離を縮める 1 2 ×1 n/N あなたの現場の LLM は、処理が止まったとき・間違えたときに何をしますか？