5日も前に出しておきながら、堂々とレベル5だと主張

3つのコードブロックが完全一致、おまけにイースターエッグの名前まで

9月11日、Minitap が Google の Artemis リポジトリを調査し、自社の mobile-use と一致する3つのコードブロックを特定した。Android デバイスの接続実装から WhatsApp のシナリオに至るまで、Alice、Bob、Charlie に新年の挨拶を送らせるエージェントのクリーンアップ手順やコメントまで一致している。バージョン番号は 3.6.3 で止まり、作者欄は3人の Minitap エンジニアの名前から「somew1nd」と、ある Outlook のメールアドレスに置き換えられていた。

「Hopper」という名前自体が Minitap チームが仕込んだプライベートなイースターエッグだ。チームのあるメンバーが Minecraft のファンで、軽い気持ちで使ったものだった。Google のリポジトリも同じ名前、同じ指示文を採用しており、作者はそれを見て「very familiar」と率直に語っている。

旧バージョンにはバグも残っていた。ヘルパーがまず結果ファイルを出力し、次のサイクルで自分が書き込んだばかりのファイルを読み込むとそのままエラーになるというものだ。Minitap は両方のコードで同じ失敗を再現しており、その後 Artemis 側はそのバグを修正した。

一度の force push で、3行のクレジット表示が消し飛ばされた

2026年8月、Artemis リポジトリで force push が行われ、package ファイルから Pierre-Louis Favreau、Jean-Pierre Lo、Nicolas Dehandschoewercker の3人の名前が削除され、別の作者の名前が書き込まれた。GitHub のアクティビティ記録にはこのプッシュの痕跡が残っているが、main ブランチからは旧バージョンが既に消えており、通常の利用者がリポジトリを開いても、書き換え後の状態しか見えない。

Minitap が GitHub のアクティビティ記録を調べたところ、commit の中で変更されたのはこの3行のクレジット表示だけで、他の 228 ファイルは元のままだった。Git はこの旧 commit を detached（どのブランチにも属さない状態）としてマークしている。すなわち、かつて存在していたものの、アクティブなブランチからの参照がなくなり、ガベージコレクションで回収される可能性があるということだ。

package ファイル内の author フィールドは npm が読み取るメタデータであり、下流で npm install を実行すれば、クレジット表示はパッケージにそのまま引き継がれる。既存の author フィールドに名前を追加するだけでは元の著者と新しい名前が併存してしまうため、フィールドごと上書きする形が選ばれたと見られる。

Apache 2.0 ライセンスの第4条は、再配布時に以下のことを要求している。元の著作権表示、クレジット表示を保持すること、および変更を加えたファイルに明示的な表示を行うこと。書き換えられた3行の名前は、帰属の証明であると同時に、ライセンスが保持を義務付けている内容でもある。

ライセンスには明記されているが、このルールは軽視されがち

Apache 2.0 は、コードの流用・商用利用・別名での公開を認めている。ただし、出典を抹消することは認めていない。第4条には、再配布時に著作権表示と帰属表示を保持し、改変箇所を明示することが明記されている。また、上流に NOTICE（ライセンスに付随する帰属表示用のファイル）が存在する場合、そこに記載された名前も併せて引き継がなければならない。

Minitap はこの問題を2つの側面に分けて論じている。1つ目はエンジニアリング上の慣例だ。fork（他人のコードリポジトリを自分の管理下にコピーして開発を継続すること）は GitHub 上に自動的に元のリンクが残り、取り込んだ側のコピーにはコメントで出典を明記でき、README（プロジェクトの概要説明ファイル）にはどの部分がどこから来たかを示せる。2つ目は法的義務だ。こうした保持行為の一部は Apache 2.0 第4条で義務として規定されており、単なる礼儀の問題ではない。Minitap 自身の言い回しはこうだ。「工学的慣例もあれば、ライセンス上の要件もある。ルールを守ることは大会社の恩恵ではなく、条項に最初から書かれていることだ」と。

帰属情報は単なる法的義務ではない。新たな開発者が原作者を見つけ、特定の設計判断の意図を理解し、バグを報告し、修正を投稿する手がかりとなる。コントリビューターに「このものを私は作った」という記録を残し、新しいプロジェクトに対しても自身の貢献を明示する場を与える。

そもそも保守担当者は issue への返信や PR のレビュー、プロジェクトの運用に時間を費やしている。大企業が彼らのコードを再公開した後、さらに「名前を元に戻してくれ」と要求しに回らなければならない——このコストは、オープンソースのエコシステムがコントリビューターに追加で課している負担だ。

メール4通のやり取りの後、ランキングのトップは依然として Minitap 以外の名前

Minitap が提出したスコアはランキングに反映されず、問い合わせメールにも返信がない。数字だけが残った。

AndroidWorld のランキングで最後に mobile-use のスコアが掲載されたのは 91.4% で、最終確認日は 2025年12月。その後 Minitap は 94.8% を提出し、さらに自社測定の 100% も提出した。2回のフォローアップメールとそれまでの2回の提出を含め、合計4通のメールを送信したが、1通も返信がなかった。9月11日時点で、ランキングの mobile-use の欄は 91.4% のまま、Artemis は 99.1% を表示している。前者は元プロジェクトが最後に掲載されたスコア、後者を取り込んだ側のスコアだ。Minitap は同時に、AndroidWorld のランキング自体が「結果は自己申告であり、独立した検証を経ていない」と明記していることを指摘している。この限定は Minitap が自己申告した 100% にも同様に適用される。つまりこれはサードパーティによる再検証を経たメーカースコア（モデル提供元が独自に測定・公表したスコア）ではなく、自己申告のスコアだ。

Artemis 自体の比較図にも mobile-use は含まれていない。図には同点の DroidRun、および名称は似ているが本件とは無関係な MadeAgents のプロジェクト MobileUse のみが記載されている。Minitap は、同じく AndroidWorld を走行している元プロジェクトがこの図で完全に省略されている点を指摘している。

検証可能な観察点は3つある。ランキング掲載者が 94.8% と 100% のスコアを追記掲載するかどうか。Artemis の README が 9月12日以降に mobile-use へのクレジット表示を追加するかどうか。AndroidWorld 運営者が「結果は独立検証を経ていない」という限定について何らかの説明を行うかどうか。

自分で確認したい方へ。3セットのリンクを順にチェック

Minitap はすべての証拠を公開資料としており、読者がリンクを開いて検証できる。まず minitap.ai/blog の原文を開き、次に GitHub の commit 履歴を確認する——この順で進めれば迷わない。

まず Minitap が minitap.ai/blog に公開した原文を開き、一番下までスクロールすると並列リンクの2組が表示される。Artemis のデバイス接続コード vs. mobile-use のデバイス接続コード、そして Artemis の Hopper プロンプト vs. mobile-use のプロンプトだ。両ファイルをそれぞれ開いてプロンプトのテキストを照合する。Minitap は「word for word（逐語的一致）」と表現しており、目でざっと確認できる。WhatsApp の例にも対応するリンクがある。Artemis の messaging example と mobile-use の example を比較し、Alice、Bob、Charlie に「Happy New Year」を送るデモのコメントやクリーンアップ手順が並べられている。次に author リストの書き換えを確認する。mobile-use 側には Pierre-Louis Favreau、Jean-Pierre Lo、Nicolas Dehandschoewercker の3人の名前が揃っている。一方、書き換え後の Artemis 版では作者が Outlook のメールアドレス付き「somew1nd」になっており、commit 全体を通じて変更されたのは author リストのみだった。

さらに踏み込むには、GitHub のアクティビティ記録で、2026年8月の force-push によるこの書き換えが Minitap の9月の調査より前に発生したことを確認できる。

force-push は Git の共同作業において履歴を上書きする。そのため「事後的に旧版をまだ閲覧できるか」は、force-push 前にリポジトリが fork されていたか、どこかで参照されていたかに依存する。Minitap が提示する detached バージョン 3.6.3 は、まさにこうした残存痕跡だ。

旧バグもまだ再現可能だ。mobile-use の旧 commit をチェックアウトし、元のブログの手順通りに再現スクリプトを実行すれば、あの同じエラーメッセージを確認できる。この手順は依存パッケージのインストールや Android デバッグ環境の設定に抵抗がない読者に適している。

最後に率直に認めるべき点がある。上記の観察はすべて Minitap 自身がまとめた資料と、GitHub で現在も閲覧可能な commit 履歴に基づくもので、第三者による独立監査は存在しない。コードの一致が「実質的類似」に該当するかの判断は法的な評価を要するし、Apache 2.0 第4条のクレジット保持義務が満たされていたかも裁判所の判断に委ねられる。Google からの公開回答は現時点までない。

もしあなたがエンジニアでない場合でも、できることはある。Google の次の README の更新を待つか、Pixel Test Engineering チームからの何らかの公式発表を待つことだ。オープンソースの係争において、リポジトリの README に1行書き加えたり、Credit 段落を追加したりすることは、最低限コストの低い釈明のシグナルである。README が 9月11日以降に mobile-use への出典を追加するかどうか——ここは注視しておきたいポイントだ。追加されれば、Google がこの関係を何らかの形で認めた可能性が高まる。それまでは、追加しないという事実自体が、ドキュメントレベルでの回答をまだ意図していないことを示している。