DeepSeek Harness (DSH) のiOS版、通称dsh-iosが公開わずか2日でGitHubトレンド入りし、130スターを獲得した。チャット画面からiPhone実機やシミュレーターを直接操作できる21種類のエージェントツールを備え、モバイル開発とQAの構造を根本から揺さぶり始めている。phoneとAIが直結する新しいレイヤーの誕生だ。

何が起きたか

GitHubに公開されたZSeven-W/dsh-iosは、DeepSeek Harness (DSH) のプラグインとして動作するiOS制御ツールだ。特徴は、AIとの会話コンテキストの中に「生きているiOSシミュレーター」と「USB接続されたiPhone実機」を直接組み込める点にある。

搭載されるのは21種類のエージェントツール。ボタンタップ、画面上のテキスト読み取り、Xcodeプロジェクトのビルド、アプリの起動・終了といったモバイル開発の日常作業を、自然言語のプロンプトから連鎖的に実行できる。公開から2日で130スターというペースは、ニッチな開発者ツールとしては明確に速い。単なるスクリプト自動化ではなく、LLMエージェントがphoneを「見て、触って、判断する」ループを閉じたことが、モバイル開発者コミュニティの琴線に触れた。

なぜこのニュースが重要か

このニュースの本質は「iOSという最も閉じたプラットフォームに、OSSのAIエージェントが手を突っ込んだ」という事実にある。

これまでモバイルのUIテスト自動化は、XCUITest、Appium、Maestroといった専用フレームワークの世界だった。テストシナリオはコードかDSLで記述し、壊れやすく、メンテナンスコストが高い。ボタンのIDが変わればテストが落ちる。一方でdsh-iosは、LLMが画面のテキストや状態を読み取り、意図ベースで操作する。「ログイン画面でテスト用アカウントでサインインして、通知設定を開いて」と書けば、多少UIが変わっても文脈で動く。

この差は決定的だ。QAエンジニアが書いてきたテストコードの半分は、UI変更への追従作業だった。エージェントがphoneを直接叩ける世界では、その工数は消える。しかもDSHはDeepSeek系OSS、つまりクローズドな米国勢を経由しない選択肢が現場に降りてきた意味も大きい。GPT-5やClaudeのAPIコストを気にせず、社内サーバーでモバイル開発ループを回せる目処が立った、と読むべきだ。

技術的な深掘り

21ツールという数字を、私は仕様書の観点から解釈する。iOSの実機操作に必要な最小プリミティブは、おそらく「タップ座標指定」「テキスト入力」「スクリーンショット取得」「OCR/アクセシビリティツリー読み取り」「アプリ起動」「ビルド実行」「ログ取得」あたりだ。これを21個に分解しているということは、単なるプリミティブではなく、build_and_installやread_visible_textのような「意味のある粒度」でツールを設計している可能性が高い(推定)。

エージェント設計の要諦は、ツール粒度をLLMの推論トークン数と合わせることだ。粗すぎるとエラー時の復旧ができず、細かすぎるとステップ数が爆発する。21という数字は、経験的にちょうど良いレンジに収まっている。

もう一つ注目すべきは「USB-connected iPhone」というワードだ。シミュレーターだけでなく実機を巻き込む設計は、libimobiledeviceやideviceinstallerのようなOSSスタックの上に載っていると想定される。ここがWindows/Linuxでも動くなら、Apple税を払わずにCI/CDにモバイル実機テストを組み込む道が開ける。地味だが、この一点だけでエンタープライズの検証コストは桁で変わる。

経営者として次に取るべき動き

第一に、自社のモバイルQA工数を数字で棚卸しすること。手動テスト、リグレッションテスト、シナリオ更新に何人月かかっているか。dsh-ios系のエージェントで代替可能な比率は、推定で30〜50%に達する。この試算を今週中に始めるべきだ。

第二に、DeepSeek系OSSを「使えるか」を評価する社内基準を作ること。米国クローズド勢のAPI依存はコストとガバナンスの両面でリスクだ。中国発OSSのライセンス、モデルの重み、通信先を検証するチェックリストを整備しておかないと、現場が勝手に導入して統制不能になる。

第三に、この週末、エンジニアに一度dsh-iosを触らせること。130スターの段階で試すのが最も学習効率が高い。半年後にレポートで知るより、今リポジトリをcloneして動かした知見が、来期のQA予算配分を決める。