スマホ操作をLLMに任せよう LLM に「押させる」前に決めたこと

スマホ操作を LLM に任せよう LLM に「押させる」前に決めたこと 共通コアと差し込み式パッケージ、途中で見えたこと、まだ答えが出ていない問い OK: ショップのボタン Yuta Sugafuji

自己紹介 菅藤 佑太 (すがふじ ゆうた) IT本部AI・データ戦略統括部AIプロジェクト推進室 IT本部AI・データ戦略統括部AI技術開発部AIジャーニー推進G 大阪育ち→大学入学から上京→2024年に大阪に引っ越し ~2018年 自然言語処理×ネットワークセキュリティの研究 2019年~ 古のベンチャー企業に新卒入社 2021年~ 教育系サービスの会社を作る&YouTuber 2023年~ 複数社の会社経営 DeNA入社 全社生成AIツールのSAIのPdM 2024年~ 慶應義塾大学 生成AI利活用戦略ユニットメンバー 2025年~ エンジニアに転向

オープニング 本日のアジェンダ ① 2分 ② 6分 OK ③ 3分 B ④ 3分 ⑤ C 5分 ？ A コア 壊れ方と 答えの型 技術の工夫 コアと 個別パッケージ 実利 人に届ける 難しさ ほか AI を判断の 中心に置かない 押す前に確かめる AI は読むだけ 工夫の多くが アプリ固有の 知識だった 効いた所と、 効かなかった所 LLM と作った開発 未解決の問い

課題とアプローチ

1. ニーズと課題、答えの型 なぜ作ったのか 毎リリース、人が同じ長い操作を繰り返していた ── 3つの期待と、3つの壁 1 現場で起きていたこと 現場 毎リリース 2 求められたこと 品質管理 ニーズ 3 立ちはだかった壁 まず 課題 普通の自動テスト テスト工数を半分に 期待結果を書き切れない （画面が多すぎる） 上位 生成 AI に丸投げ AI で新しい価値を 往復する／位置がずれる／ 画面外に届かない 1回 30分〜1時間 長い操作を手でやったとき （ある安定性確認の例） 更新の多いアプリで 月に数十本 対象画面をすべて 撮影して確認 事業部 自動プレイと、 開発中の品質を ? 何も与えない端末 自律操作は まったく動かなかった 同じ道具に、3つの期待が乗った 問い：LLM に「押させる」前に、何を決めておけばいいか？ 3

1. 壊れ方と答えの型 長い確認操作と、AI に任せたら壊れた3つ 人がやっていること AI に画面を見せて任せたら 1 30分〜1時間 長い操作シナリオを手で1回 （ある安定性確認の例） それを毎リリース繰り返す （また）新しい画面だ！ 2 3 ↓ 画面の外 さっきと同じ 同じ画面を「新しい画面」と誤認して 往復 → だから、AI を判断の中心に置かない設計へ 狙い 押した所 目的の項目 押す位置がずれる スクロールしないと出ない 要素に届かない

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秒で押す 読み取って判定に利用 する土台を作る

1. 壊れ方と答えの型 答えの型: AI を判断の中心に置かない 決定論の土台と、機械の答え合わせで上下から挟む = Σ 指紋の一致 合計の検算 答え合わせ （機械） 取りこぼしの自己検算 ※ 不具合の判定ではない ⇄ どこまで届いたか 通信データと 表示の突合 到達 目的の画面まで操作できる 生成 AI 1 2 「3」 3 観測 選ぶ・分類する・ 確かめる だけ 画面・数値・構造を記録できる 判定 決定論の 土台 記録した座標 画面指紋 安全装置 器と第1観点（クラッシュ検知）は 配線済み。当たったかを測る正解デ ータはまだ少ない。

技術的工夫

2. 技術の工夫 確信度 1.00 でも間違える ── そして、座標も間違える 初期: 動画から AI が推定 後日: 同じ「はい」・同じ座標で押すと 録画 座標で押す AI が読む 「戻る」 確信度 0.98 AI に位置を解かせる 背景に 当たって 閉じる 「スキップ」 確信度 1.00 「いいえ」を 押して 閉じる 購入されない 購入されない 録画の座標 正解は「はい」 → そこで記録座標を正とした どちらも実行されない（記録上 座標側5件・AI側6件） 今の判断 記録と同じ画面か で決める 距離 記録 今 近い 遠い AI も解けない 座標で押す AI で位置を解く 止める

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 は番号と ラベルだけ答える

2. 技術の工夫 pre-tap predict ① 押す前に、照準を重ねた画像で確かめる ① 予定点を決める ② 照準だけ重ねる ③ AI が JSON で判定 ④ 補正して押す NG・もっと下・わずか 枠の中心を 押す予定の点に 十字と中心点だけ 描いて見せる "verdict": "ng", "direction": "below", "offset": "slight", NG のときの直し方（判定は最大4回） 下へずらし再判定 → OK → 押す 但し書き（fail-open） ? わずか・近い 同じ候補の中で 少しずらす 遠い その方向の 実在の候補へ 画面外 縦にスクロール して探し直す ずらした点を ③ でもう一度判定 NG のまま4回 押さずに 飛ばす 答えが無い 確認なしで そのまま押す

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 もっと下 押すと危ない側は アプリ固有 → 個別パッケージの ガードレールへ

2. 技術の工夫 毎回ちがう画面をどう吸収するか 待つ・区間で合わせる・2問に分ける 1 待つ 記録 2 区間で合わせる 3 入口 再生（今の画面）→ 出口 2問に分ける Q1 全体を見て 結果画面？ 記録 Q2 左下に ← がある？ 連打で飛ばす 2問とも「はい」で確定 指紋の 距離 再生 1問だけだと… 閾値 左下に ← ある？ 時間 → 最大5秒で打ち切り 出口: 指紋の「同じ」は信じない 結果画面？ AI を呼ばない → 速く、安く、毎回同じ 間は何コマでも、入口と出口だけ合わせる 隅の飾りを 「←」と誤判定 全体 → 決め手の部分、の順に聞く

2. 技術の工夫 AI は「読む」だけ、計算と検算はコード ── そして、検算は独立していなかった 画面（前・後） ① 切り出す ② AI は読むだけ ③ 計算はコード {"coins": 1250} 1750 − 1250 {"coins": 1750} 前 後 = +500 ④ 記録 前✓ 後✓ +500 読めない欄は null ※ 1,250 / 1,750 は模式図の例 同じ購入を2通りで確かめた {} AI に意味を答えさせる 正解の約7.7倍 数値の差分をコードで 本人の申告と一致

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分

2. 技術の工夫 LLM を呼ぶのは「一度だけ・事前に」 費用と、出力の揺れの扱い 事前に1回 実行は何度でも AI を使う 画面指紋で照合 JSON 1回だけ 録画の画面 人が読んで直せる まだ消えていないもの {} 画像3枚 / 1操作 動画は読ませない 構造が取れれば AI なし 画像認識を呼ばない 月数千円規模 登壇者の記録。 請求明細とは未照合 ? 数えていない呼び出しがある → 記録上の回数は下限 出力の揺れは残っている → 揺れる観測と、判定を分けた

2. 技術の工夫 地図を自分で作る・日本語1行で動かす 動いたが、まだ遅く脆い部分もある アプリ内通貨を ○○個購入してください ホーム ショップ 購入 もう達成した！ 確認 ホーム まだ → 止める 1手 約40秒 実測41回の中央値: 7画面・15手 （別条件の記録では約21秒） ✓ 開発者の手元では完走 ✕ 候補の58.7%を黙って落としていた → 今は警告を出す

スケールの為の手法

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つ。違うのは パッケージだけ

3. コアと個別パッケージ 個別パッケージの中身 (1) 置き場所の規則と、画面の「読み方・辿り方」 個別パッケージ（アプリごと） 地図 ＝ データ 画面遷移図 読み方・辿り方 ＝ コード ショップ 確認 一覧 詳細 ホーム /shop {} アプリ A アプリ B アプリ C 画像 ＋ AI で読む URL → 目的の画面へ 通信データを正とする 画像テンプレートで特定 詳細は通信データから 依存は一方向 A {} B アプリごとの束（zip） コードの外で、別に運ぶ 何をどこに置くか C パッケージ （アプリごと） コア 値に見えてロジック → コード 判定の述語・操作の順序 ロジックに見えて値 → 値 純粋な対応表 個別パッケージ 3件 画面遷移図 3件

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分 叩き続けうる作りだった

価値創出

4. 実利 実利: 定型画面の全件読み取りと検算 月の運用工数を最大 約95% 削減 以前 今: 端末が一覧を自分で巡回する 名前 表示 突合 全件 マスタ 突き合わせ 対象画面をすべて 人が撮影して確認 監査担当 更新の多いアプリは月に数十本 最大 約95% 2つのアプリの月の運用工数 社内記録・最大工数基準 削減 漏れ 46件 → 1件 画像しか使えないアプリ。 残りは目視で補完 正式導入 運用は推進チームが運用中。

4. 実利 効いた所・効かなかった所 どんな仕事なら効くか 現場の運用ルールで補った ↑ 正解を機械で検算できる 録画はホーム画面から始める 定型画面の監査 所持数をそろえる 効いた 日次の切り替わり時刻を跨がない 全部購入して並びをそろえる 不具合の判定 正解データが まだ少ない 毎月の定常確認 約7割を再生で テストの目的も問い直された 「そもそも回す必要があるのか」 撮影が目的の作業 状態を消費する操作 効かない 1日1回・売り切れ 1 2 3 人の操作を真似る 目的から逆算して探索する 更新の頻度 →

取り組みの反省

5. 途中で見えたこと 当時そう言っていた／いまはこう分かっている 測ったら、別の姿が見えた 当時そう言っていた 4月 5月 6月 「AI の幻覚を構造的に排除した。 偽陽性 −100%」 「最初に1時間ほどかければ、 どんなアプリでもできる」 「新しいアプリも固有コードなしで 着手できる」 いまはこう分かっている 9月 座標 AI 約5倍 8月 8月 「クラウド化は今週中に完了」 同じボタンで座標側も失敗。記録上ほぼ同数 どちらを信じるかではなく、照合で決める 途中 新しいアプリ1本で 7〜56日の見積り 読み方の経路によって約5倍違う 未解決 今動いているものは、 アプリごとの調整が前提だった 途中 翌日撤回。今も後回し 途中 自分の読み取り漏れの自己申告だった 不具合の判定に使うと約4割が誤検出 途中 4月 「合計の検算で答え合わせできる」 約4割 9月 測るたびに、見えていなかった側が出てきた

展開の難しさ

6. 人に届ける難しさ 社内で前例のないものを説明する 言葉が先に期待を作る 「パッケージ」 1 ← 人によって、指していたものが違った 2 3 </> 期待の方が、実装より先に走った 機能を組み合わせた シナリオ アプリ固有の コード 画面遷移の 貯め場所 事業部の期待 実装の進み 「ガードレール」 コアの安全装置 作り手に課す枠 アプリ固有の制御

6. 人に届ける難しさ 同じ道具に、3つの期待 ニーズは「素朴な質問」から出てきた 品質管理 テスト工数の半減 「なぜこの業務に、こんなに工数が？」 作り手 上位 AI による 新しい価値 事業部 ？ ？ 開発中の品質（左シフト） 誰の成功指標で測る？ 自動操作と 開発中の品質 「更新がとても多い（月に数十本）」 現場

6. 人に届ける難しさ 体感してもらうまでの距離 実は「伴走」が前提だった 約20回 使う人 作り手（横で伴走） 前提の状態を そろえる アカウント （アプリ内の 数値・ 開始画面・ エミュレータ 日付） コンテナ 環境 配布ファイル を展開 ようやく ツールの 機能 約半年で配布 （6月だけで約10回） 「最新版なのに変わらない」 原因は、画面の 古いキャッシュ 現場はコードを書き換えて使っていた APP_ID = "sample.a" 対象アプリの識別子の固定値を書き換え 自分で触れるまでに、環境構築の長い階段があった

6. 人に届ける難しさ 失敗から変えたこと 「作り切ってから渡す」をやめた 1 やったこと 目的の画面 約1か月 約1か月直しても、目的の画面に届かず

いまだ残っている課題

7. 未解決の問いと持ち帰り まだ答えが出ていない問い 技術よりも、組織と定義の側に鍵がある 正解データは 誰が作る？ ? Aa ≠ あ 正解の例が現場から 来ないと検証できない AI と地図は同じ 言葉を話しているか 蒸留 警報26件中21件は 「言葉」が違った 遅い 鍵: 現場 23語 鍵: AI と地図 どこまで汎用か ? ? 「1時間でどんな アプリでも」→ 1本 7〜56日の見積り 置き換えるか、 蒸留するか ? ¥ 高い 鍵: 開発 誰がパッケージを 書くか ? 非エンジニア向けの 画面は構想段階 汎用はそこそこ動くが 遅くて高い。 人をどこに残すか ? 正解データを誰が いつ作るかは、 組織の問い ? 鍵: アプリ側の協力 鍵: 組織 あなたの現場の「正常」は、誰が書いていますか？ 鍵: 運用

7. 未解決の問いと持ち帰り 現場に持ち帰れること LLM に押させる前に決めること ── 任せる範囲、黙ったときの動き、誰が正解を書くか 技術として持ち帰る 1 仕事とチームに持ち帰る AI に位置を書かせず、選ばせる・確かめさせる。 見せる絵の描き方で判定が変わる 4 効くのは「高頻度 × 正解を機械で検算できる × 読み取り中心」の仕事。まずそこから始める 2 事実も変わるし AI も間違える。 どちらかを常に信じるのではなく、 「前提が今も成り立つか」を照合して決める 5 固有の知識は本体に埋めず、後から差し込む。 宣言が無ければ何もしない 3 AI を呼ぶのは事前に一度。読むのは AI、 計算と検算はコード。処理が止まってしまった ときの動きを先に決める。 6 言葉は先に期待を作ってしまう。 確定と未確定を言葉で書き分け、 許諾を先に取り、触れるまでの距離を縮める 1 2 ×1 n/N あなたの現場の LLM は、処理が止まったとき・間違えたときに何をしますか？