Author

technews

世界の技術ニュースをリアルタイムでキャッチし、日本語でわかりやすく発信。AI・半導体・スタートアップから規制動向まで、グローバルテックシーンの「今」をお届けします。

GitHubで話題の「vphone-cli」は、Mac上でiPhoneを立ち上げる実験ツールだった

Apple SiliconのMac上で、仮想のiPhoneを起動するためのCLIツールがGitHubに公開されています。名前は vphone-cli。見た目は地味ですが、中身はかなり攻めています。iOS向けのファームウェアを準備し、パッチを当て、DFU復元を経て、カスタムファームウェアを入れ、最初の起動まで一気通貫で進められるようにしているからです。単なるデモではなく、研究用途や自動化テストまで視野に入った道具に見えます。

この手の話は、単に「面白い」で終わりません。AppleのVirtualization.framework、iOSの復元、AMFIやSIPの制約、さらにはSileoやTrollStoreまで出てくるので、macOSとiPhoneの境界がどこまで揺らされているのかを知る材料になります。元記事はREADME中心ですが、そこに書かれている内容だけでも十分に濃いです。

macOS 15+ の Mac で iPhone を起動するまでの流れ

vphone-cli は、Lakr233 が公開している公開リポジトリで、README には「Apple の Virtualization.framework を使って、PCC research VM infrastructure ിലൂടെ virtual iPhone を起動する」と書かれています。要するに、Macの上でiPhone相当の仮想マシンを動かすためのコマンドラインツールです。対応ホストは Apple Silicon の Mac で、macOS 15 以降、Xcode と iOS SDK も必要です。さらに、未署名バイナリに対して private な PV=3 entitlements を通すため、SIP/AMFI の緩和も求めています。

導入方法は2通りあり、Homebrew から brew install zqxwce/tap/vphone-cli で入れるか、リポジトリを --recurse-submodules 付きで clone して自前で build します。README では ./scripts/setup_tools.sh で依存関係や Python 仮想環境を整え、./scripts/build.sh で vphone-cli の署名、.app のバンドル化、vphoned のクロスコンパイルまで行う手順が示されています。起動後は .build/vphone-cli.app/Contents/MacOS/ に移動して vphone-cli --help を叩く想定です。

いちばん目を引くのは、vm create 一発で仮想機の作成から起動まで進められる点です。README では vphone-cli vm create myphone -V jb が例として載っており、これはダウンロード、パッチ、DFU restore、カスタムファームウェアのインストール、最初のブートまでをまとめて実行します。その後に vphone-cli vm launch myphone で起動します。もちろん、各工程を分けて手動で進めることもでき、fw prepare、fw patch、restore、cfw install、vm launch のように段階を追って操作できます。

--variant で選べるファームウェアの種類も細かいです。less は4 patches、2 phases で、iOS の mitigations を残す patchless に近い位置づけです。regular は42 patches、10 phases で AMFI、SSV、Img4、TXM の bypass を行い、dev は53 patches、12 phases で TXM entitlement/debug bypass が追加されます。jb は113 patches、14 phases で full jailbreak、初回起動時に Sileo と TrollStore を自動導入します。最も強い exp は141 patches、18 phases で、jailbreak の上に anti-VM-detection research patches を積んだものです。README には、詳細は research/0_binary_patch_comparison.md にあると案内されています。

起動後の接続も書かれています。jailbreak 構成なら SSH は ssh -p 22222 mobile@<vm-ip> で、パスワードは alpine。regular と dev では root@<vm-ip> になります。VNC は vnc://<vm-ip>:5901 です。仮想マシン関連のデータはすべて ~/.vphone/ 以下に置かれ、VM 本体、ダウンロードした IPSW、APFS seal-volume の素材、.deb パッケージ、Python の venv などが用途ごとに分かれています。VPHONE_ROOT や VPHONE_LIBRARY_ROOT のような環境変数で保存先を切り替えられるのも、研究用ツールらしい作りです。

README には、SIP/AMFI の緩和方法や、Virtualization が使えない場合の条件、iOS セットアップ時に Japan や EU の地域を避ける必要があること、EXC_GUARD で落ちる場合の再パッチ方法まで載っています。さらに、ldid-procursus の既知の不具合として、特定の entitlements plist に整数0が入ると無限に書き込み続けてしまう問題も説明されていました。これは upstream では修正済みだが、タグ付きリリースにはまだ入っていないので、brew install --HEAD ldid-procursus と brew link --overwrite ldid-procursus で再ビルドするよう勧めています。最後には、外部制御用の vphone.sock まで用意され、スクリーンショット、タッチ、スワイプ、ハードキー、クリップボードを操作でき、AI駆動の E2E テストにも使えるとしています。

これは「iPhoneエミュレータ」ではなく、研究用の実機寄りツールだと思う

まず感じたのは、これを普通の意味での「エミュレータ」と見ると少しズレる、ということです。README の書き方を見る限り、vphone-cli はiPhoneを見た目だけ再現するおもちゃではありません。IPSW を取り込み、ブートチェーンをパッチし、DFU restore を通し、必要なら jailbreak まで載せる。つまり、Apple が本来想定していない経路をかなり丁寧に積み上げた研究基盤です。だからこそ、Virtualization.framework という公式APIを使いながら、周辺では SIP や AMFI の制約を外しにいく構図になっています。ここに、このツールの本気度が出ています。

一方で、ここまでやっても「万能」ではないのが面白いところです。README には、Virtualization が使えないハードでは動かないこと、Press home to continue で止まったら VNC でホームボタンを右クリックすること、地域設定を誤ると system apps が入らないことなど、かなり泥くさい注意点が並びます。私はここに、この分野の現実がよく出ていると思いました。最先端の話に見えて、実際には設定の一つ一つが足を引っ張る。だからこそ、完成品の便利さより、研究の再現性を上げる道具として価値があるのでしょう。

jb で Sileo と TrollStore まで自動導入するのは、かなり踏み込んでいる

vphone-cli が興味深いのは、単なるブート支援に留まらず、jb では Sileo と TrollStore を初回起動時に自動インストールする点です。これはかなり強い宣言です。仮想iPhoneを「起動できる」だけではなく、脱獄後の環境としてすぐ触れる状態まで持っていく。研究者や開発者から見れば、検証のたびに手作業で環境を組み直す時間を減らせるので、実験の回転が速くなります。

ただ、私はここに少し危うさも感じます。脱獄や bypass は、使い方次第でセキュリティ研究の道具にもなるし、保護回避の実装例にもなります。README が exp という、anti-VM-detection research patches を含む最上位の variant を用意しているのも象徴的です。これは悪意の表明ではなく、研究対象を広げるための設計だと思いますが、同時に「何を再現できるか」がそのまま「何を壊せるか」に近づく領域でもあります。公開リポジトリとして透明に置かれていること自体は健全ですが、読む側にも用途の線引きが求められるはずです。

自動化テスト基盤として見ると、vphone.sock の存在がいちばん効く

README の後半で目立つのは、外部制御用の host control socket vphone.sock です。スクリーンショット、タッチ、スワイプ、ハードキー、クリップボードを扱え、各操作のたびにインラインのスクリーンショットが返るとあります。これは単なる「リモート操作できます」以上の意味があります。GUI テストを回すとき、いま何が画面に出ているかを都度取り出せると、失敗の切り分けがかなり楽になるからです。

私はここが、このプロジェクトのいちばん実用的な顔だと思いました。仮想マシンの研究は、どうしても「動いた」「動かない」で終わりがちです。でも vphone-cli は、VM のライフサイクル管理だけでなく、操作の自動化と観測までまとめようとしている。AI-driven E2E testing という表現も、少し流行語っぽく見えるものの、実際には自然な方向です。画面の状態を取り出せて、操作も注入できるなら、アプリ検証の自動化にそのまま使えるからです。Apple の枠内でどこまでやれるかを押し広げる試みとしても、かなり筋がいいと思います。

README がここまで細かいのは、たぶん「使える人」を最初から絞っているからだろう

この README は、一般向けにわかりやすく見せるより、最初から相当詳しい人に向けて書かれています。Apple Silicon、macOS 15+、Xcode、iOS SDK、SIP/AMFI、DFU restore、SHSH、APFS clone、ldid、TrollStore。知らない単語が多くても、文脈で追えるようにはなっていますが、気軽な入門書ではありません。私はこれを、あえて正しいと思います。曖昧な期待を持って触ると環境構築で止まるので、最初から「これは研究用で、しかも要求が多い」と明示したほうが親切です。

同時に、この厳しさはプロジェクトの将来像も示している気がします。~/.vphone/ にデータを閉じ込め、バンドルを portable に保ち、CLI から create/import/export/clone を回せるようにしているのは、単発のデモではなく、繰り返し実験するための土台を作ろうとしているからでしょう。iPhone の仮想化は、これまで断片的なツールの寄せ集めになりがちでした。そこを一つの操作体系にまとめようとした点に、このリポジトリの面白さがあります。完成度よりも、問題の置き方がはっきりしている。だからこそ、技術者には強く刺さるのだと思います。

参考: GitHub - Lakr233/vphone-cli

同じ著者の記事

Orbifyのデモが示した、地図を「歩く」体験の作り方

3Dの地図や空間表現は珍しくなくなったが、実際に触って気持ちいいデモはまだ多くない。Orbifyの「Demo 2 - v72」は、Gaussian-splat という描画手法を使ったナビゲーションの見せ方を、ブラウザ上でどう成立させるかに焦点を当てたページだ。今回はそのデモページに何が置かれているのかを整理しつつ、単なる技術デモ以上の意味があるのかを見ていく。見た目は軽いが、裏側にはかなりはっきりした狙いがあるように読める。 元記事は、Orbify のウェブデモ「Demo 2 - v72」をそのまま公開したページだ。ページ中央では「Navigation Reimagined. Preparing Demo 2 - v72…」という文言が出ており、読み込み中は 0% から始まって「Loading Orbify scene」と表示される。つまり、完成品の紹介というより、まずはこの体験をブラウザで動かすこと自体を見せる作りになっている。 デモの説明には「interactive Gaussian-splat navigation visualization」とある。Gaussian splat

papoo.work

「漏れた情報」だけで攻撃が走る時代に、OSSの守り方は変わるのか

オープンソースのセキュリティ対応は、これまで「欠陥の詳細をしばらく伏せておけば、その間に利用者へ安全に直せる」という前提で回ってきました。Anil Madhavapeddy氏は、その前提がLLMや自律エージェントの登場で崩れつつある、と書いています。この記事は、OCamlのHTTPライブラリ `cohttp` のパッチ作業を起点に、公開前でも攻撃の兆候が走り出した現実を示し、OSSメンテナがどう守りを組み替えるべきかを考えるものです。単なる「AIで攻撃が速くなった」という話ではなく、公開・非公開・修正・配布の境界そのものが揺れている、というのが芯にあります。 著者はその日、OCaml向けの `cohttp` 6.3.0 に対するセキュリティ修正を出したと説明しています。内容は path traversal、つまり本来たどれないはずのパスにアクセスさせる脆弱性です。普通なら、こうした修正はまず私的に直し、影響を受ける利用者へ伝え、最後に公開アドバイザリを出す流れになります。ところが今回は、PR を開いてからほんの数分で、実運用中の自分のWebサーバーログに、そのバグの典型パターンを試す

papoo.work

SamsungのPIMが見せた「メモリの中で計算する」現実味と厄介さ

SamsungがHot Chips 2026で示したのは、メモリをただの保管場所ではなく、計算の場としても使うProcessing-in-Memory、いわゆるPIMの具体像だった。LPDDR5Xの中にMAC演算器を入れつつ、外からは通常のメモリチップのように扱える、というのが肝だ。発想自体は昔からあるが、今回は理論ではなく、実装と運用の面倒さまでかなり踏み込んでいる。面白いのは、性能の話より先に、OSやキャッシュとの相性の悪さがはっきり見えてくるところにある。 元記事が紹介しているSamsungのLPDDR5X-PIMは、見た目こそ通常のLPDDR5X-9600チップだが、16 banksそれぞれにPIM blockを持たせた設計になっている。DRAMは内部で bank に分かれていて、通常は memory controller が bank を選び、row を開き、column access strobe、つまり CAS 命令でデータを読む。だがPIMでは、その bank にぶら下がった演算ブロックが内部帯域を直接使う。外部バスに縛られないので、16 banks全体で理論上 614

papoo.work

Rust向け埋め込みDB「TurboKV」が見せる、軽量でも欲しい機能を詰め込む設計

Rustで使える埋め込み型のkey-value storeとして、TurboKVというライブラリがGitHubで公開されています。単に「速いDBです」で終わる話ではなく、非同期API、batchの原子性、range scan、耐久性の切り替え、圧縮、バックグラウンドcompactionまで含めて、かなり実戦的な機能をひと通り揃えているのが目を引きます。Rustで小さく始めたいが、あとから保存方式や一貫性で困りたくない、という人には気になる存在です。今回はそのREADMEを軸に、何を目指したDBなのかと、そこから見える設計の匂いを追います。 TurboKVは「A fast, simple, and embedded key-value store for Rust」と名乗る、非同期の埋め込み型データベースです。READMEでは、atomic batches、ordered range scans、configurable durability、compression、background compaction を備えると説明されています。つまり、単純な `get` / `put` だけの

papoo.work

TencentがHy4 previewを公開した理由

Tencentが自社の大規模言語モデル「Tencent Hy4 preview」を公開し、同時にオープンソース化した。単に新しいAIモデルを出したという話ではなく、770Bという巨大な総パラメータ数、49Bのアクティブパラメータ、100万トークン超の長い文脈処理を前面に押し出しているのが特徴だ。しかも用途は研究室のデモではなく、coding、office work、scientific researchのような実務寄りの場面に置かれている。Tencentがこのモデルをどう位置づけ、どこで使わせようとしているのかを見ると、いまの生成AI競争の焦点がかなりはっきりしてくる。 Tencentの発表によると、Hy4 previewは次世代のlarge language modelで、総パラメータ数は770B、実際に推論時に動くactive parametersは49B、context windowは100万トークンを超える。要するに、モデル全体としてはかなり大きいが、常時全部を動かすわけではなく、必要な部分だけを使って計算効率を確保する設計だと読める。Tencentはこのモデルを、実際の生産性

papoo.work

ローカルで音源を分ける「StemDeck」がやっていること

音楽の制作や練習で、ボーカルだけ抜き出したい、ドラムだけ消したい、あるいはベースの動きを追いたい、という場面は珍しくありません。GitHub に公開された StemDeck は、そうした用途に向けた stem separation ツールです。クラウドに音源を上げず、自分のPCの中だけで処理を完結させる点を強く打ち出しています。最近の音声AIは便利さと引き換えにアップロード前提になりがちですが、そこに違和感を持つ人にはかなり刺さる作りだと思いました。 StemDeck は、音楽ファイルをいくつかの“stem”に分けるためのデスクトップ向けプラットフォームです。対応している入力は MP3、WAV、FLAC、OGG/Opus、MP4、M4A で、YouTube の URL を貼り付けて使うこともできます。分割できるのは最大 6 系統で、ボーカル、ドラム、ベース、ギター、ピアノ、other に切り分けます。見た目は DAW 風のマルチトラックミキサーになっていて、各 stem を mute や solo で切り替えたり、音量を調整したり、波形を拡大表示したり、区間ループをかけたり、そのまま個

papoo.work

LLMの“記憶”を、会話ログではなく分析状態として扱う発想

LLMに長時間の作業をさせると、途中まで積み上げた前提を忘れたり、いったん否定したはずの仮説をまた持ち出したりする。今回取り上げる記事は、その不安定さをどう抑えるかを考えた末に、著者が「記憶」を会話履歴ではなくプログラム解析の問題として捉え直した話だ。単なるメモリ強化の工夫ではなく、Datalog というルールベースの仕組みまで作ってしまったところが面白い。しかもそれを、脆弱性調査の実務にかなり近い形で組み立てている。 著者はここ数か月、脆弱性調査向けに LLM agent を試していた。大きなコードベースを歩き回ったり、見慣れないサブシステムを説明したり、攻撃面を探したりする用途では、LLM はかなり頼れるようになってきたという。ただ、調査が数時間単位に伸びると、同じ問題が何度も起きた。モデルが、すでに否定された仮説を再び提案したり、間違いだと分かった前提に基づいて推論し続けたりするのだ。人間が「それは違う」と伝えても、その前提にぶら下がっていた他の結論まで自動では消えない。 最初は、こうした混乱を減らすために memory system を探っていた。一般的な方法は、古い会話や観察

papoo.work

AWS Cognitoに3週間振り回された開発者の告白

スタートアップで認証機能を組み込むとき、AWS Cognitoを選んだらどうなるのか。元記事は、その答えをかなり辛辣に書いた体験記だ。筆者は「AWSの中にあるから便利そう」「最初の50,000 MAUは無料」という理由で採用したものの、実際にはドキュメントの分かりにくさ、Amplify v6の破壊的変更、ローカル開発のしづらさ、Hosted UIの自由度の低さに次々と悩まされたという。単なる愚痴ではなく、認証基盤を選ぶときに何を重く見るべきかまで踏み込んでいるのが、この文章の面白いところだ。 筆者は、スタートアップの認証をAWS Cognitoで実装し始めてから3日ほどで違和感を覚えた。手順通りに進めているのに、パスワード再設定の画面が期待と違う場所へ飛んでしまう。ドキュメントを十二のタブで開き、コード例を写し、解説動画まで見たのに直らない。すでにAuth0やFirebase Auth、さらには自前のJWT実装まで触った経験がある筆者ですら、Cognitoは別物だったという。 不満の中心は、まずドキュメントにある。AWSの説明は、エンタープライズ向けの設計思想、フロントエンド開発者向け

papoo.work

OpenAI Python SDKがHTTPX2へ移ったことで、何が変わるのか

OpenAIのPython SDKが、内部のHTTPクライアントをHTTPX2へ切り替えた。ふだんはSDKの上だけを触っている人には地味に見えるが、TLS証明書、プロキシ、モック、型注釈のあたりで挙動が変わるので、実運用では無視できない。しかも今回は「そのまま動く部分」と「移行が必要な部分」がかなりはっきり分かれている。公式ドキュメントとしては珍しく、互換性を保ちながらも、古い前提を少しずつ切り替えていく姿がよく見える内容だ。 元記事は、OpenAI Python SDKが同期・非同期のHTTPクライアントにHTTPX2を使うようになったと説明している。HTTPX2は`openai`と一緒に自動で入るが、以前の`httpx`パッケージはもう同梱されない。つまり、SDKを普通に使うだけなら、特別な追加インストールは必要ない。`OpenAI`や`AsyncOpenAI`を`http_client`なしで作る、いわゆるデフォルトの使い方では、既存のAPI呼び出し、レスポンスのパース、streaming、認証、リトライ、数値で指定するtimeoutはそのまま動く、と明記されている。 一方で、以

papoo.work

Claude がやたら使う言葉から見えるもの

AI の文章は、内容だけでなく言い回しにも癖が出ます。今回の元記事は、Claude が特定の語をかなり強く好んでいるのではないか、という観察を扱っています。単なる雑談ではなく、モデルの振る舞いを言葉の側から見る試みなので、AI の出力を日常的に読む人ほど面白いはずです。しかも、こうした語の偏りは、生成AIが「賢く見える」仕組みそのものにもつながっています。 元記事は、Claude が出力する文章の中で、ある種の語彙が異様に頻出しているのではないか、という問題意識から始まります。著者は、その偏りを確かめるために、Claude の文章を観察し、どんな単語や表現が何度も現れるかを追っています。ここでの「load-bearing vocabulary」という言い方は、文章を支えるというより、文章の骨格になっている語、あるいは文の雰囲気を決めてしまう語、というニュアンスです。 記事の中心にあるのは、Claude がただ情報を並べるのではなく、特定の語を足場にして話を組み立てているように見える、という発見です。人間の文章でも口癖はありますが、Claude の場合はそれがかなり露骨に見える。たとえば

papoo.work