iOS Simulator、macOSアプリ、Webアプリを「日本語のゴール記述」だけで自動テストできるOSSツール「harness」が、GitHubで165スターを突破した。LLMエージェントがUIを実際に操作し、引っかかった箇所をレポートする方式で、QA工程の人月コストを直撃する可能性がある。Swiftトレンドの上位に食い込んだ意味を、実装エンジニアの視点で読み解く。
何が起きたか
awizemann/harness は、自然言語で書いたゴールをLLMエージェントが解釈し、iOS Simulator・macOSアプリ・Webアプリを実際にクリック/タップしながらテストを実行するツールだ。スター数は165に到達し、Swift系リポジトリのトレンドに浮上している。
特徴は、テストスクリプトを書かずに「ログイン画面でメールアドレスを入力し、パスワードを忘れた場合のリンクが機能することを確認」といったプレーンな指示を与えるだけで、エージェントが画面要素を認識して操作・検証まで行う点だ。E2Eテストの世界でWeb向けにはBrowser UseやAnthropicのComputer Useが先行していたが、iOS SimulatorとmacOSネイティブアプリまで横串で扱える実装はまだ珍しい。
なぜこのニュースが重要か
QA自動化の文脈で、これまで定番だったのはAppium、XCUITest、Playwright、Detoxといったスクリプトベースのフレームワークだ。いずれも「要素のセレクタを指定する」「待機条件を書く」「assertを並べる」というコードが前提で、UI変更のたびにテストが壊れる「flaky test」問題と保守コストに悩まされてきた。
LLMエージェント方式は、この前提を覆す。要素IDが変わっても「ログインボタン」というセマンティクスでエージェントが探し直すため、UI微変更への耐性が高い。一方で、非決定的な挙動・実行時間・APIコストという新しい課題が出てくる。harnessが面白いのは、Web専用ではなくiOS/macOSという「アクセシビリティAPI経由でしか自動操作できない」領域に踏み込んでいることだ。Apple純正の XCTest や AXUIElement をLLMの「目と手」に接続する構造は、AndroidのUIAutomatorに対するMagicPodやAutifyの取り組みと比較しても新鮮味がある。
エンジニア視点・技術深掘り・実装影響
実装上の勘所をいくつか挙げておきたい。
1. UI認識のレイヤー設計
LLMエージェントがGUIを操作する方式は大きく二系統ある。スクリーンショットをVision LLMに渡してピクセル座標を返させる方式（Anthropic Computer Use系）と、アクセシビリティツリーを構造化テキストとして渡す方式だ。後者の方が安定するがプラットフォーム依存が強い。iOS SimulatorではXcodeの simctl と XCUIElementSnapshot 、macOSでは AXUIElementCopyAttributeValue 経由でツリーが取得できる。harnessがどちらのアプローチを採るかで、信頼性とコストのバランスが変わってくる。
2. CI統合時のコスト試算
仮にClaude SonnetクラスのAPIを使い、1テストシナリオあたり20〜50ステップ、各ステップでスクリーンショット込み数千トークンを消費すると、1ケース数十円〜数百円のオーダーになる。1000ケースをPRごとに回すと現実的でない。実運用では「クリティカルパスのみエージェントテスト、回帰はスクリプト」というハイブリッド設計が妥当だろう。
3. 決定性とリトライ戦略
LLMエージェントテストは同じ入力でも経路がブレる。Flaky判定のロジックを「N回中M回成功でgreen」とするか、エージェントの行動ログをハッシュして差分検出するかは、CIパイプライン側で工夫が要る。GitHub Actionsで回すなら、continue-on-error: true でレポート収集だけ先に走らせる運用が現実的だ。
4. セキュリティ境界
エージェントが本番に近い環境で操作する場合、誤って課金APIを叩く、メール送信ボタンを押すといった事故が起きうる。AnthropicもComputer Useのドキュメントでサンドボックス必須と明記している。harness導入時もSimulator/専用テナント前提が安全だ。
経営者/読者として次に取るべき動き
QA組織を抱える事業者にとって、検討すべきは「置き換え」ではなく「再配置」だ。テスト要員を減らす議論より、いまテストエンジニアが消費している時間のうち、シナリオ設計（人間が強い）と実行・回帰（LLMが代替可能）を分離する作業から始めるべきだろう。harnessのようなツールはまだ165スターのアーリーフェーズで、本番投入には早いが、PoC段階で触っておく価値はある。
非エンジニアが自然言語でテストを書ける点は、プロダクトマネージャやデザイナーが受け入れ検収に直接関与できることを意味する。仕様書とテストケースの距離が縮まり、「仕様書がそのまま実行可能」という方向に向かう。これは、TDDやBDDが20年かけてできなかった「ビジネスサイドと開発の言語統一」を、LLMが力技で実現しつつあるという話でもある。
OSSとしてのharnessがどこまで伸びるかは未知数だが、「LLMエージェント×ネイティブアプリQA」という座標自体は、今後12〜24ヶ月で複数のスタートアップと大手ベンダーが参入する激戦区になる。早めに自社のテスト資産を「LLMが読める形式」（Markdownのシナリオ集、明示的なAcceptance Criteria）に整理しておくことが、来るべき移行コストを下げる最大の準備になる。
動画でも詳しく
動画は記事冒頭の埋め込みからフル尺で視聴できます。