jadx-ai-mcp: JADX の逆コンパイル結果を MCP 経由で LLM に渡すプラグイン
Plugin for JADX to integrate MCP server
ひと目でわかる
- これは何？
- JADX に MCP サーバを組み込み、逆コンパイル済みのコードを Claude などの LLM から直接読ませるためのプラグイン。導入前に確認すべきは、MCP サーバ側のリポジトリが別に存在する二段構成という点だ。
- 誰に向いている？
- 既に JADX で APK を開いてクラス単位の読解を進めており、その作業を LLM に肩代わりさせたい人には向く。GUI を介さず CLI だけで静的解析を回したい場合や、逆コンパイル結果を外部の LLM に送れない案件では選ばない方がよい。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 17 日前です。
- 何の言語で書かれている？
- 主に Java です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
JADX の画面と LLM の間にある断絶を埋める
Android の APK を読むとき、JADX はクラス一覧と逆コンパイル済みの Java ソースを表示する。読者はそこから疑わしい箇所を自分で探し、呼び出し関係をたどり、文字列や定数を突き合わせる。この作業は LLM に向いている種類の処理だが、JADX の画面の中身をそのまま LLM に渡す手段が長らく無かった。コピーしてチャットに貼る方法では、クラスをまたぐ参照をたどるたびに手作業が発生する。
jadx-ai-mcp はこの断絶を Model Context Protocol (MCP) で埋める。README の説明では、JADX のプラグインとして動き、MCP を通じて Claude などの LLM と通信する。対象は APK の静的解析、脆弱性の調査、逆コンパイル結果の読み解きだと明記されている。想定読者は、ペネトレーションテストや VAPT の文脈で APK を読む実務者、あるいはリバースエンジニアリングを日常的に行う開発者だ。モバイルアプリのコードレビューを LLM に補助させたいが、ファイルを手で貼り付ける段取りには戻りたくない、という動機が前提にある。
プラグインと MCP サーバが別リポジトリに分かれている理由
構成を把握する上で最初に押さえるべき点は、このプロジェクトが単体で完結しないことだ。README のバッジは jadx-ai-mcp と jadx-mcp-server という二つのリポジトリの contributors を並べて表示しており、前者は JADX 側に読み込ませるプラグイン、後者は Python 側の MCP サーバという役割分担になっている。README の要件表示も Java 11+ と Python 3.10+ の両方を挙げており、言語の異なる二つの部品を揃える必要があることが読み取れる。
データの流れはこうだ。JADX が APK を逆コンパイルしてクラスやメソッドの情報を保持し、プラグインがそれを MCP のツールとして公開する。LLM 側は MCP サーバに接続し、サーバが JADX 側のプラグインとやり取りする。つまり LLM が直接ファイルを読むのではなく、JADX が既に解析済みの状態を問い合わせる形になる。この設計の利点は、逆コンパイルの負荷を JADX に任せたまま、LLM には必要なクラスだけを引かせられる点にある。欠点は、二つのプロセスのどちらかが落ちると全体が止まることだ。README にも「まだ開発の初期段階であり、バグやクラッシュ、論理エラーを想定してほしい」という趣旨のコメントが HTML コメントとして残っている。
導入手順で実際に触るファイルとコマンド
この記事の材料には README の冒頭部分しか含まれておらず、インストール手順の全文は確認できない。したがって、ここに書けるのはリポジトリの構造と表示から読み取れる範囲に限られる。確実に言えるのは次の点だ。JADX 側にはプラグインを配置する必要があり、Python 側では jadx-mcp-server を動かす必要がある。Java は 11 以上、Python は 3.10 以上が要件として README に明示されている。
MCP サーバの登録は、利用する LLM クライアントの設定ファイルにサーバの起動コマンドを書く形になる。Claude Desktop であれば claude_desktop_config.json の mcpServers にエントリを追加するのが一般的な手順だが、jadx-ai-mcp がどのキー名を想定しているかは手元の材料からは特定できない。リモートホスト対応は v6.4.0 ではなく v6.3.0 のリリースで「Remote Host Support」として入っている。JADX と MCP サーバを別マシンに置く構成を取るなら、このバージョン以降が必要になる。バージョン間の互換性、特にプラグインとサーバの組み合わせについては、リポジトリのリリースノートと Read The Docs (jadx-ai-mcp.readthedocs.io) を確認するのが早い。推測でバージョンを混ぜると、ツールの一覧が片側から見えないといった形で表面化する。
v6.4.0 で検索基盤に手が入ったことの意味
リリース一覧を見ると、v6.4.0 には「Search Infrastructure Overhauled」という副題が付いている。検索基盤の作り直しだ。逆コンパイル結果を LLM に読ませる作業では、どのクラスやメソッドを引っ張ってくるかの精度がそのまま回答の質になる。巨大な APK ではクラス数が数万に達することもあり、全文をコンテキストに載せる方法は現実的でない。検索の絞り込みが甘ければ、LLM は無関係なクラスを読んで的外れな指摘を返す。
この副題は、そうした検索側の問題が実際に表面化し、作り直しが必要になったことを示唆する。ただし、何がどう変わったのか、どの程度改善したのかは材料からは分からない。リリースノートの本文を読まない限り、v6.3.x から v6.4.0 に上げるべきかどうかは判断できない。バージョン番号だけを見て「改善された」と受け取るのは避けた方がよい。検索の挙動を変える変更は、既存のプロンプトや手順の前提を崩すことがある。
APK を外部 LLM に送る構成が許されない場面
最も見落とされやすい制約は、解析対象のコードが LLM 側に渡るという点だ。MCP の設計上、LLM はツールを呼び出して JADX が保持するクラスやメソッドの情報を取得する。つまり逆コンパイル結果の一部が、少なくとも LLM を提供するサービスの側に送られる。社内規定や契約で解析対象のコードを外部に出せない場合、この構成はそのままでは使えない。
もう一つの限界は対象範囲だ。README が挙げているのは APK の静的解析であり、ネイティブコードの解析や動的な挙動の観測は射程に入っていない。JADX 自体が DEX を Java に戻す道具である以上、難読化で Java 層が壊れているアプリや、処理の大半が .so にあるアプリでは、LLM に渡せる情報そのものが乏しくなる。また、このプロジェクトはまだ初期段階だと README 自身が断っており、解析結果をそのまま報告書に転記できる品質を期待するのは早い。LLM の指摘は候補であって、最終的な判断は人が行う前提で使うべきだ。
MCP を使わない場合との違い
比較対象として分かりやすいのは、JADX の出力をそのままテキストとして LLM に読ませる方法だ。jadx にはコマンドライン版があり、APK から Java ソースを一括で書き出せる。書き出したディレクトリをエディタで開き、LLM のコーディング支援機能に読ませる、という手順が考えられる。この方法の利点は、追加のプラグインも Python 側のサーバも要らず、既存のツールだけで完結することだ。
違いは問い合わせの粒度にある。一括書き出しでは、LLM はファイルシステム上のテキストを読む。どのファイルを読むかは LLM 自身か利用者が選ぶことになり、JADX が内部に持つクラス構造や参照関係の情報は失われる。jadx-ai-mcp は JADX の解析済み状態に対してツール経由で問い合わせるため、クラスやメソッドの単位で必要な情報を引ける。逆に、一括書き出しの方が扱いやすい場面もある。解析対象が小さく、書き出したソースをそのまま読ませた方が早い場合や、MCP に対応したクライアントを持っていない場合は、無理にこのプラグインを挟む理由はない。
Apache-2.0 と二つのリポジトリの保守コスト
ライセンスは Apache-2.0 で、リポジトリの表示からも README のバッジからも確認できる。商用利用を含めて比較的自由度の高い条件だが、実際に配布物へ組み込む場合は NOTICE ファイルの扱いなど確認すべき項目がある。ここでは法的助言はできないので、条件の解釈は自組織の判断で行ってほしい。
保守の観点で効いてくるのは、先に述べた二段構成だ。JADX 本体の更新、jadx-ai-mcp の更新、jadx-mcp-server の更新という三つの流れを追う必要がある。リリースは v6.3.0 が 2026-03-29、v6.4.0 が 2026-05-28、v6.4.1 が 2026-08-06 と、数か月間隔で続いている。活発ではあるが、その分だけ追従の手間も発生する。特に JADX 本体が内部 API を変えた場合、プラグイン側が動かなくなる可能性がある。解析対象の APK を長期の案件で扱うなら、動作を確認したバージョンの組み合わせを固定しておき、更新は別のタイミングで検証する方が安全だ。
編集部の結論
既に JADX で APK を開いてクラス単位の読解を進めており、その作業を LLM に肩代わりさせたい人には向く。GUI を介さず CLI だけで静的解析を回したい場合や、逆コンパイル結果を外部の LLM に送れない案件では選ばない方がよい。導入前に、jadx-ai-mcp と jadx-mcp-server のバージョン対応表、Java 11+ と Python 3.10+ の両方を満たす環境、そして v6.3.0 で入ったリモートホスト対応の設定方法を確認しておくこと。
コミュニティノート