AI Daily Digest

1. GrapheneOSが「個人情報不要」を宣言：Motorola提携とプライバシーOSの未来

何が起きたか

GrapheneOSが2026年3月20日、「個人情報・身分証明・アカウントなしで誰でも利用できる状態を維持する」と公式に宣言しました。規制で端末販売が制限される国が出ても、その原則を曲げないという姿勢です。

背景には、MWC 2026で発表されたMotorolaとの提携があります。2027年以降のMotorola端末にGrapheneOSをプリインストールする計画で、これまでのPixel限定から大きく方向転換しました。Tier1 OEMとの正式提携はGrapheneOS史上初です。

要点

• Motorola端末にはQualcomm SPU（セキュリティスイート）やハードウェアメモリタギングなど厳格な要件が課される
• 既存のMotorola端末は要件を満たさず、2027年以降の新規ハードウェアが対象
• サンドボックス化されたGoogle Play Servicesにより、多くのアプリが問題なく動作する実績がある

3月21日に取り上げたAndroidサイドローディング24時間待機の文脈で見ると、ローカルAIアプリの配布にもこの宣言は影響します。GrapheneOS上でのローカルLLM実行環境が、クラウド依存しないAI活用の選択肢として注目される可能性があります。

なぜ重要か

プライバシーOSがPixel以外のハードウェアに広がることは、「プライバシーかユーザビリティか」の二択を崩す第一歩です。ブラジルでは銀行アプリがGrapheneOSをブロックする事例が報告されており、普及には課題もあります。ただ、Motorolaの販売網・認証・サプライチェーンが加わることで、「使いたいけど端末が限られる」という障壁が下がります。

議論の争点

• Motorola（Lenovo傘下）との信頼性：ハードウェア要件は厳格だが、ファームウェアレベルのバックドア懸念を指摘する声がある。一方、メモリタギングやセキュアエンクレーブがリスクを軽減するとの反論も。
• 銀行アプリのブロック問題：Play Integrity検証でGrapheneOSを拒否する金融アプリが増加傾向にあり、日常利用への影響が指摘されている。これはOS側の問題ではなく、アプリ側のポリシーの問題。
• 提携の持続性：Motorolaが唯一の対応端末になった場合、立法で排除されるリスクがある。Pixel対応を維持しつつ選択肢を増やす戦略が妥当との意見が多い。

少数意見：「政府が十分長い腕を持てば、こうした絶対的宣言は撤回させられる」という冷めた指摘。

判断のヒント：プライバシーを重視するなら、現時点ではPixelでGrapheneOSを試すのが最も安全な選択肢です。Motorola提携は2027年以降の話なので、今すぐ判断を迫られるものではありません。

所感

「個人情報なしで使える」という当たり前のことを、わざわざ宣言しなければならない時代になりました。Androidのサイドローディング制限やアプリ側のOS検証強化が進む中、GrapheneOSの立ち位置はますます重要になります。Motorola提携が実を結ぶかどうかは2027年まで見えませんが、選択肢が増えること自体に価値があります。

用語メモ

Play Integrity API

Googleが提供するデバイスの信頼性検証API。
この記事ではGrapheneOSを「改変OS」として拒否する銀行アプリの仕組みとして登場。

ハードウェアメモリタギング

メモリ領域にタグを付与し、不正アクセスを検出するセキュリティ機能。
Motorola提携の必須要件として言及。

2. GitHubの可用性が99.9%を下回る：AI偏重とAzure移行が招いた信頼低下

概要

GitHubの可用性が深刻な低下を続けています。2025年上半期だけで109件のインシデントが発生し、前年同期比58%増。2月9日にはActions、PR、Webhook、Copilotなど複数のサービスが同時にダウンし、Copilotの復旧には18時間を要しました。Enterprise Cloud顧客に約束している99.9%のSLAを下回る状態が常態化しています。

先に押さえる3点

• 根本原因はレガシーデータセンターからAzureへの移行。2025年10月から段階的に進行中で、「分割トラフィック」状態がカスケード障害を引き起こしている
• AIコーディングツール（Copilot、Claude Code、Codex）からのAPIトラフィック急増が、移行中のインフラにさらなる負荷をかけている
• OpenAIのエンジニアが数時間コミットできなかった事例があり、Zig言語プロジェクトは2025年12月にGitHubを離脱済み

3月23日のTrivy侵害でも触れたGitHub Actionsのセキュリティ問題に加え、可用性の低下は開発ワークフロー全体のリスクを高めています。3月20日のAstral→OpenAI参加のように、開発ツールの集中がさらに進む中での信頼低下は影響が大きいです。

議論の争点

• AI機能 vs 基盤安定性：Copilot関連の機能開発にリソースが偏り、コアのGit操作・Actions・APIの安定性がおろそかになっているとの批判が多い。ただし「Copilotの売上がGitHub全体を支えている」との反論も。
• Azure移行の是非：GitHub CTOが2025年に「可用性がJob #1」と述べてAzure移行を推進したが、結果は逆。インフラ経験者からは「分割トラフィックアーキテクチャは障害の温床」との指摘。
• AIエージェントによるトラフィック急増：Issue登録の数分後に10件以上のPRが自動投稿される事例もあり、AIコーディングツールがGitHubのインフラを想定外の負荷にさらしている。

少数意見：「Copilotのダウンタイムを含めて"全体"のスコアを出すのは不公平。使わない機能の障害で全体を評価すべきではない」。

判断のヒント：CI/CDをGitHub Actionsに強く依存している場合は、代替パイプラインの検討が現実的です。非公式ステータスページで実態を確認できます。

影響

GitHubに依存する開発チームにとって、障害が「たまにある不便」から「ワークフローの構造的リスク」に変わりつつあります。セキュリティスキャンをActionsで回している場合、障害時にPRがチェックなしでマージされるリスクがあるとの報告も出ています。GitHub自身が3月11日に「自社の可用性基準を満たしていない」と認めた点は重要です。

実務メモ

GitHub Actionsに全面依存している場合は、セルフホストランナーやCircleCIなどの併用を検討するタイミングです。少なくとも、障害時にマージゲートが無効化されない運用ルールを整備しておくと被害を抑えられます。

用語メモ

スリーナイン（99.9%）

年間ダウンタイム約8.7時間に相当する可用性水準。
GitHubのEnterprise Cloud SLAで約束されている基準だが、達成できていない。

カスケード障害

ある箇所の障害が他のサービスへ連鎖的に波及する現象。
Azure移行中の「分割トラフィック」アーキテクチャが原因として指摘されている。

3. iPhone 17 Proで400BパラメータLLMを動かす：Flash-MoEの仕組みと現実

ざっくり言うと

開発者のDaniel Woodsが、12GBしかRAMを持たないiPhone 17 Proで、400Bパラメータの大規模言語モデルをローカル実行するデモを公開しました。クラウド接続なし、端末のA19 ProチップとNVMeストレージだけで動いています。

昨日のFlash-MoE記事ではMacBook上での実行を取り上げましたが、今回はiPhoneです。同じ技術がスマートフォンにまで降りてきた格好です。

ポイントは3つ

• 使用モデルはQwen3.5-397B-A17B（MoEアーキテクチャ）。総パラメータ数397Bだが、トークンごとに使うのは約17B分だけ
• 2ビット量子化＋SSD-to-GPUストリーミングで、モデル全体をRAMに載せずに推論する。Appleの「LLM in a Flash」論文がベース
• 速度は0.6トークン/秒。最初の応答までに50秒近くかかる。実用にはほど遠いが、「動く」という証明にはなった

議論の争点

• 「400B」の看板に偽りはないか：MoEで実際にアクティブなのは17B分、さらに2ビット量子化で品質低下。「密な30Bモデルを4ビットで動かす方が実用的」との指摘は的を射ている。
• 発熱とバッテリー：Neural EngineとSSDを同時に高負荷で回すとiPhoneはすぐに発熱し、スロットリングが入る。0.6tok/sがさらに遅くなる可能性がある。
• 技術の応用先：400Bモデルを無理やり動かすより、7B〜30Bの小型モデルに同じ手法を適用すれば、実用的な完全オフラインAIが実現できるのでは、との建設的な意見も。

少数意見：「みんなポケットに超知能AIを持つ夢を見たけど、実際にやったのはドゥームスクロールとキャットフィッシュだった」。

判断のヒント：これ自体は使い物にならないデモですが、SSDストリーミング技術を小型モデルに適用した場合の可能性に注目してください。

どこに効く？

「スマホでLLMを動かす」こと自体はもう珍しくありません。TermuxでOllamaを動かす人も、M2 iPadで推論している人もいます。今回のデモの本質は、SSDストリーミングという技術がモバイルでもスケールすることを見せた点にあります。同じ手法で7Bモデルをフルオフラインで快適に動かせるなら、プライバシー重視のローカルAIアシスタントが現実になります。

一言

「ノートパソコンで動く」「スマホで動く」というタイトルに飛びつく前に、量子化ビット数、アクティブパラメータ数、トークン速度の3つを確認する癖をつけると、期待値の調整が楽になります。

用語メモ

SSD-to-GPUストリーミング

モデル重みをストレージからGPUに逐次転送する手法。
RAM容量を超えるモデルの推論を可能にする。Appleの「LLM in a Flash」論文が原型。

MoE（Mixture of Experts）

トークンごとに一部のエキスパートのみを活性化するアーキテクチャ。
397Bの総パラメータ中、推論時には約17B分しか使わない。

4. WalmartがChatGPTチェックアウトを見限った理由：CVRはWebの3分の1

まず結論

Walmartが約20万商品をChatGPTの「Instant Checkout」で販売した結果、コンバージョン率がWebサイトの約3分の1でした。Walmart EVPのDaniel Dankerは結果を「不満足」と評しています。

変わった点

2025年11月に導入されたInstant Checkoutは、ChatGPT内で決済まで完結する仕組みでした。しかし根本的な問題がありました。

• 商品ごとに個別のトランザクションが発生し、5つの推奨商品が5つの別配送になる
• 在庫情報が決済段階まで反映されず、購入直前に「在庫切れ」と表示される事例が報告された
• ロイヤルティプログラム、バンドル割引、返品ポリシーなどWalmartが30年かけて最適化した仕組みが機能しない
• OpenAIは2026年2月時点で米国の州別消費税徴収システムすら整備していなかった

Forresterの2026年3月調査でも、AI内での購入完了は最も利用率の低いユースケースでした。

議論の争点

• チャットUIとEコマースの相性：「良いEコマースは購買までの障壁を徹底的に排除する。チャットは質問や比較を促すので、本質的に購買行動と相性が悪い」との構造的指摘。
• 正直なAI vs マーケティングツール：「AIに正直さを求めるか、販促ツールにするか。2つは両立しない」。アフィリエイト収益のためにベストでない商品を推奨するリスクも。
• ドメイン知識なきディスラプション：「Eコマースは25年かけて最適化されてきた。新参者が魔法の解決策を持ち込んで大失敗するのはお決まりのパターン」。

少数意見：「RC飛行機の部品選定にGeminiを使っていて、購入ボタンがあれば即押す。ユースケース次第」。

判断のヒント：リサーチ用途ではAIが有効でも、決済フローはApple PayやAmazonワンクリックの方が信頼されています。

注意点

Walmartは3月25日から方針を転換し、自社チャットボット「Sparky」をChatGPT内に配置する戦略に切り替えます。発見はAIインターフェース、コンバージョンはWalmart管理環境という分業です。Sparky利用者の客単価は他の顧客より約35%高いとのデータがあります。

使うならこうする

自社ECとAIチャットを統合する場合、「発見」と「決済」は分離した方が安全です。AI内で決済まで完結させるのは、ユーザーの信頼とシステムの成熟度が追いついていません。3月19日のOpenAI IPO戦略の記事でも触れましたが、ChatGPTの忖度化傾向はコマースとの相性に影を落としています。

用語メモ

Instant Checkout

OpenAIがChatGPT内で提供する購入機能。
小売パートナーの商品をチャット画面から直接決済できる仕組み。

エージェンティックコマース

AIエージェントがユーザーに代わって商品検索・比較・購入を行う概念。
WalmartのCVR低下は、この概念の実装難度を示す事例。

5. 若手労働者がAI時代に備えてやっていること：ブルーカラー回帰は正解か

何が起きたか

Wall Street Journalが、AI時代に備える若手アメリカ人の動きを報じています。保険業界を3.5年勤めた28歳が消防士に転身、CSを専攻していた22歳が電気工事の学校へ、Amazonの6桁年収AI職を辞めて教育企業を起こした25歳。パターンは「ホワイトカラーから手に職へ」です。

要点

• 18〜29歳の約60%がAIを雇用の脅威と認識（ハーバード調査）
• AI影響職種（ソフトウェア開発、カスタマーサービス）の22〜25歳雇用が2022年末〜2025年9月で16%減少（スタンフォード調査）
• 職業訓練校・コミュニティカレッジの入学者数は2020年比で約20%増
• ゴールドマン・サックスのデータ：ホワイトカラー業務の37〜46%が自動化可能、ブルーカラーは4〜6%

3月23日のAI生産性と雇用の記事でも触れた「開発者を減らすか、製品を良くするか」という問いと表裏一体のテーマです。

議論の争点

• ブルーカラー移行の持続性：全員がブルーカラーに流れれば労働供給が急増し、同時にホワイトカラー層の失職で需要が減る。「配管工の平均年収は約6.5万ドル。エンジニアリングマネージャーの15〜20万ドルにはかなわない」という現実的な指摘。
• レイオフの真因：「AIのせいで解雇」と報じられる多くのケースは、金利上昇による資金調達コスト増が本当の原因。CEOがAIを口実にコストカットを正当化しているとの見方が根強い。
• データが語ること：FRBの統計ではSWE求人はまだ増加傾向。「AIが雇用を奪う」ナラティブと統計データにはギャップがある。ただし、ジュニア層のポジションが絞られている傾向は確認されている。

少数意見：「最もAI耐性がある職業は看護師。医師も技術的には自動化可能だが、医師ロビーが強すぎて守られる」。

判断のヒント：統計を見る限り、SWEの需要消滅は起きていません。ただしジュニアポジションの競争激化は事実なので、差別化できるスキルの獲得が鍵になります。

なぜ重要か

この動きの本質は「AIへの恐怖」ではなく、「キャリアの不確実性にどう対処するか」です。ブルーカラー回帰は一つの解ですが、全員にとって正解ではありません。技術系の仕事がなくなるのではなく、求められるスキルセットが変わる過渡期にいるという見方が、データとも整合します。

所感

3月23日のゲーム業界AI失業記事も含め、「AIで仕事がなくなる」話は週に一度は目にします。恐怖を煽る記事と冷静なデータの両方を見て、自分の状況に当てはめて判断することが大事です。全体の傾向よりも、自分がいる業界・ポジションの具体的な変化を追った方が有益です。

用語メモ

AI影響職種（AI-exposed occupations）

AIによる自動化の影響を受けやすい職種の総称。
スタンフォードの調査ではSWEとカスタマーサービスが代表例として挙げられた。

ジュニアポジション

入門〜3年未満レベルの職位。
AI支援で1人あたりの生産性が上がった結果、新規採用が絞られる傾向にあるとされる。

6. OSSにAIボットを呼び込む方法：風刺が映すオープンソースの苦境

概要

Andrew NesbittがClaude協力のもとで書いた風刺記事です。「AIボットからのプルリクエストを増やすには」という体裁で、OSSプロジェクトの劣悪な運用をわざと推奨しています。

先に押さえる3点

• 「再現手順のない曖昧なIssueを書け」「型注釈とテストを削除しろ」「ブランチ保護を無効化しろ」「node_modulesをコミットしろ」 ── すべて逆説的なアドバイス
• 「スロップ密度」（AI PRと人間PRの比率、3:1）や「レビュー娯楽価値」など、架空の指標が登場する
• 核心は、AIボットによる低品質PRの洪水がOSSメンテナーを疲弊させている現実への痛烈な風刺

影響

HNコメントでは、序盤を本気で読んでしまった人が複数いました。それ自体が、「AIが善意でPRを投げてくる」ことに慣れすぎた現状を物語っています。3月21日のOpenCode記事で取り上げたオープンソースAIツールの普及と表裏一体で、ツールの民主化が質の低い貢献を量産するジレンマがあります。

バウンティシステムがボットを引き寄せるハニーポットになっている事例や、AI生成コンテンツを検出してPR投稿者をブラックリスト化する提案も出ていました。

実務メモ

メンテナーとしてできる対策は明確です。IssueテンプレートにCI通過を必須条件として書く、ファーストタイマーのPRにbotラベルを自動付与する、CONTRIBUTING.mdで明確な品質基準を示す。風刺を笑いながら読めるうちに対策を入れておくのが吉です。

用語メモ

スロップ（slop）

AI生成の低品質コンテンツを指す俗語。
PRの文脈では、形式上は正しいが実質的に無意味な変更を指す。

AIエージェントPR

人間の指示なくAIが自動で生成・投稿するプルリクエスト。
Issue検知→修正→PR作成まで自動化したツールが増え、OSSメンテナーの負担が問題化している。

7. 自動車修理店にAI受付を導入してわかったこと：実用と批判の両面

ざっくり言うと

開発者が兄弟の高級自動車修理店向けに「Axle」というAI音声受付を構築しました。24時間対応で、サービス内容・料金の問い合わせに答え、対応できない質問はコールバック情報を記録して人間に引き継ぎます。

ポイントは3つ

• 技術スタック：Vapi（電話・STT/TTS）、MongoDB Atlas（ベクトル検索）、Claude（RAG応答生成）、FastAPI（Webhook）
• 開発で最も時間がかかったのは音声チューニング。テキスト応答と音声応答はまったく別物で、ElevenLabsの声選びと口語調への書き換えに工数がかかった
• 修理店オーナーは「毎週数百件の不在着信で月に数千ドルの損失」を抱えており、AI受付はその取りこぼしを防ぐ位置づけ

どこに効く？

3月22日の配管業者Claude Code記事に続く「非エンジニアの事業課題をAIで解決する」系の事例です。ただ、HNのコメントは手厳しいものが目立ちました。元サービスアドバイザーからは「部品の在庫・価格は日々変わる。不正確な見積もりは店の評判を損なう」との指摘。アウトソース型の人間受付（月150〜500ドル）の方が費用対効果が高いのではという声も。

RAGの必要性についても疑問が呈されていました。修理店の情報量であれば、コンテキストウィンドウに全部収まるレベルです。

一言

「不在着信をゼロにする」だけなら効果的ですが、見積もり回答を任せるのはリスクが高い、というのが現場経験者の一致した見解です。AI受付は「人間に繋ぐまでの橋渡し」として割り切るのが現時点では正解でしょう。生のLLMを業務特化の音声エージェントに使うなら、回答範囲を厳密に制約する設計が不可欠です。

用語メモ

Vapi

音声AIエージェントの電話統合プラットフォーム。
STT（Deepgram）とTTS（ElevenLabs）を組み合わせて自然な電話応対を実現する。

RAG（検索拡張生成）

外部データベースから関連情報を取得してLLMの応答に組み込む手法。
修理店の価格表やサービス情報を応答に反映するために使用。

8. RustコントリビューターたちのAI観：推進と懐疑のあいだで揺れるOSS

まず結論

Rustプロジェクトがコントリビューター・メンテナー向けにAI利用についての意見を収集し、その結果がまとめられました。「プロジェクトとしての統一見解」ではなく、個人の立場からの多様な意見集です。推進派と懐疑派の間には深い溝があります。

変わった点

推進派は、自分の専門外の作業（HTML/CSS、リファクタリング）でAIに力を借りている実態を語ります。ドキュメント検索やコードレビュー支援など、コード生成以外の用途も評価されています。ただし「良い結果を出すには入念な設計が必要」で、魔法のツールではないという認識は共通しています。

懐疑派の論点はより構造的です。AIに頼るとコードベースへの深い理解が失われること、「もっともらしく見える」低品質PRがレビュアーの時間を奪うこと、訓練データの倫理性、環境負荷、大手テック企業への権力集中。

注意点

3月21日のAIコード品質の記事で指摘された「AI支援が構造的な品質劣化を招く」問題と根は同じです。個人が便利に使う分にはいいが、プロジェクト全体としてどう扱うかはまだ答えが出ていません。

XZ backdoor事件を引き合いに出し、「人間のレビュアーが検出したものをAIは見逃す可能性がある」というセキュリティ上の懸念も提起されていました。AIがPRを生成し、別のAIがレビューするサイクルが回ると、人間の目が通らないまま変更が入るリスクがあります。

使うならこうする

プロジェクトでAI利用のポリシーを検討しているなら、この文書は参考になります。「全面禁止」も「全面許可」も極端で、貢献の種類やリスクレベルに応じた段階的なガイドラインが現実的です。少なくとも、AI生成PRの開示を求めるルールは早めに入れておくのが無難です。

用語メモ

スキルアトロフィー（skill atrophy）

能力や知識が使われないことで衰える現象。
AI依存によりコードベースへの深い理解が失われるリスクとして議論されている。

AI生成PR開示

プルリクエストがAIの支援を受けて作成されたことを明示する運用ルール。
レビュアーが品質判断の参考にするために導入が検討されている。

9. LLMにコーヒーの冷め方を予測させたら：物理シミュレーションの意外な実力

何が起きたか

dynomight.netの筆者が、6つのLLM（Kimi K2.5、Gemini 3.1 Pro、GPT 5.4、Claude 4.6 Opus、Qwen3-235B、GLM-4.7）に「沸騰したお湯をマグカップに注いだら何度で冷めるか」の方程式を出させ、実測値と比較しました。

要点

• タイトルは「コーヒー」だが、実際は水の冷却実験。コーヒー粉は入っていない
• 全モデルが「室温＋指数関数的減衰」の方程式を生成。速い冷却（水→マグカップへの熱移動）と遅い冷却（マグカップ→空気への放熱）の2段階を表現した
• 実測と比較すると「全部まあまあだが、どれも正確ではない」。実際は初期の冷却がもっと速く、後半はもっと遅かった
• Claude 4.6 Opusが最も精度が高かったが、トークンコストは0.61ドルと最高額

なぜ重要か

結局のところ、LLMが出したのはニュートンの冷却法則の教科書的な式です。「物理を理解して予測した」のではなく、「訓練データに含まれる教科書的知識を再現した」に近い。ただ、複数の熱伝達メカニズム（伝導、対流、蒸発、放射）が絡む問題で、パラメータの推定まで含めてそこそこの精度を出したのは面白い結果です。

物理学の研究者からは「学部レベルの熱力学」との冷静な評価。それでも、仕様の曖昧な問題に対して「概算モデル」をすぐ出せる能力は、エンジニアリングのラフ見積もりでは役に立ちます。

所感

「LLMにコーヒーの温度を予測させた」という見出しのキャッチーさと、中身の地味さのギャップが面白い記事でした。実用的な教訓は一つ。LLMに物理モデルを生成させるなら、「概算として使える」レベルであることを前提に、重要な判断には実測データを必ず併用すること。マグカップを温めておくと冷めにくい、という古典的な知恵はLLMに聞くまでもありません。

用語メモ

ニュートンの冷却法則

物体の冷却速度が周囲との温度差に比例するという法則。
LLMが生成した方程式の基本構造がこの法則に基づいている。

指数関数的減衰

時間とともに値が指数的に減少するパターン。
コーヒー冷却では「速い減衰（マグ吸熱）」と「遅い減衰（空気放熱）」の2項で表現された。

10. ClaudeにモバイルアプリのQAをやらせる：AndroidとiOSで明暗が分かれた話

概要

Christopher Meiklejohnが、Capacitor（React Web→ネイティブラッパー）で構築したコミュニティアプリ「Zabriskie」のQAをClaude に任せた記録を公開しました。全25画面のスクリーンショット取得、視覚的な問題検出、バグレポートの自動投稿までを自動化した結果、AndroidとiOSで体験が大きく異なりました。

先に押さえる3点

• Android：Chrome DevTools Protocol経由でWebViewを制御。セットアップ約90分。全画面カバーを約90秒で達成し、「25画面、クリティカル問題ゼロ」の結果
• iOS：ディープリンクの不具合、ネイティブ権限ダイアログの自動化困難、「@」が入力できないキーボード問題など6時間以上の格闘。バックエンドのログイン改修やTCCデータベースの直接書き換えが必要だった
• 最終的にはどちらも動き、日次スケジュールタスクとして定期実行している

影響

3月18日のClaude Godotゲーム生成記事でもClaudeのタスク自動化能力が話題になりましたが、QA自動化は別の難しさがあります。WebdriverIO、Appium、Maestroといった既存ツールが同じ目的で使える点はHNでも指摘されていました。

興味深いのはClaudeのワークツリー逸脱問題です。指定されたディレクトリ外にcd してしまうことがあり、対話型なら気づけても無人実行では朝まで気づかない。境界の強制はAgent側ではなく、外部のサンドボックスで担保すべきという教訓です。

実務メモ

LLMベースのQAは「スクリーンショットを見てバグを見つける」部分に新しさがあります。ただ、既存のE2Eテストフレームワークの方が信頼性は高く、LLMは「見た目の異常検知」に限定して併用するのが現実的です。Androidの方がはるかに自動化しやすいのは、WebViewベースのアプリに限った話ですが、覚えておいて損はありません。

用語メモ

Chrome DevTools Protocol（CDP）

Chromeブラウザをプログラムから制御するためのプロトコル。
Android上のCapacitor WebViewをClaudeが操作する際に使用された。

Capacitor

Webアプリをネイティブモバイルアプリとして動作させるフレームワーク。
React等で書いたWebアプリをiOS/Androidのネイティブシェルで包む。