reverse-skill Claude Code 自動選択（2026）

reverse-skillをClaude Codeへ導入する前に、認可範囲とツール権限を先に固定する方法を説明します。Skillが発見されない、誤ったツールを選ぶ、依存ツールが不足する、実行に失敗するといった問題を、合法サンプルによる検証手順で切り分けます。

reverse-skill Claude Codeを導入するなら、先に認可範囲とツール権限を固定し、その後で合法サンプルを使って自動選択と失敗時の回退を検証します。AIによるツール選択はルーティング補助であり、許可確認や人間による最終判断の代わりにはなりません。

このページは、認可済みのAPK・バイナリを調査する担当者、Claude Code Skillsを保守する開発者、隔離されたリモート環境で解析ツールを運用するチーム向けです。実在する第三者の対象へ使う手順は扱いません。

最終確認日は2026年8月10日です。プロジェクトのREADME、Skillファイル、Claude Codeの最新Skills仕様を照合しています。

reverse-skill Claude Code の導入判断

reverse-skillは、APK、ELF、Windowsバイナリ、フロントエンドJavaScript、PCAPなどの課題を分類し、対応する方法、ツール、スクリプトへ振り分けるためのSkill Routerです。公開READMEでは、認可確認、ケース範囲、ツール確認、シナリオ別Skill、証跡整理という流れを示しています。プロジェクトREADMEの構成でも、対象を直接操作する前にスコープを確認する設計が明記されています。

ただし、インストールしただけで安全な自動化が完成するわけではありません。実際には次の3点が失敗しやすいです。

• Skillの配置がClaude Codeの探索対象から外れている。
• 説明文が広すぎて、APK解析なのに別のセキュリティ手順へ進む。
• Agentが使えるシェル、ファイル、ネットワーク、MCPの範囲が広すぎる。

reverse-skillのREADMEには、ルーティングルール41件、回帰テスト163ケース、追跡対象のコアモジュール42件が掲載されています。これは機能の保証値ではなく、リポジトリ側が示している現在の管理単位です。導入時は、この数字をそのまま信頼するのではなく、実際の環境で自分たちのサンプルを通す必要があります。

Claude Code Skills の配置と自動発見

Claude Codeの公式仕様では、個人用Skillは ~/.claude/skills/<skill-name>/SKILL.md、プロジェクト専用Skillは .claude/skills/<skill-name>/SKILL.md に置きます。ディレクトリ名が呼び出し名になり、SKILL.md のYAML frontmatterにある description が自動適用の判断材料になります。公式のSkill配置とfrontmatter仕様を最初に確認してください。

reverse-skillの公開手順は、リポジトリを取得した後、OS別のツール一覧を更新する流れです。macOSやLinuxでは次のような確認を行います。

git clone https://github.com/zhaoxuya520/reverse-skill.git
cd reverse-skill
bash skills/scripts/refresh-tool-index.sh

WindowsではPowerShell用スクリプトが用意されています。READMEでは、APK関連の処理にJavaまたはJDK、JavaScriptやMCP連携にNode.js 22.12以上、Fridaや補助スクリプトにPython 3系を使う構成が示されています。これらはreverse-skill全体を無条件に動かす最低保証ではなく、担当シナリオごとの前提条件です。導入時は、公開されている前提ツール一覧を環境ごとに確認します。

自動発見されない場合は、次の順番で切り分けます。

1. SKILL.md が実際に存在するか確認します。
2. Skillディレクトリの場所が個人用、プロジェクト用、プラグイン用のどれかを記録します。
3. ディレクトリ名とSkill名の衝突を調べます。
4. description に「APK」「ELF」「バイナリ静的解析」など、対象タスクを区別できる表現があるか見ます。
5. セッション開始後に新しいトップレベルのSkillディレクトリを作った場合は、Claude Codeを再起動します。

公式ドキュメントでは、既存のSkillファイルは変更を検知できますが、セッション開始時に存在しなかったトップレベルのSkillsディレクトリは再起動が必要と説明されています。また、同名Skillはスコープの優先順位やディレクトリ階層の影響を受けます。したがって「ファイルがあるのに触れられない」ときは、未監視、同名衝突、説明文の不一致を分けて考えます。

AI Agent ツールルーティングの検証

導入確認では、いきなり複雑なマルウェアや第三者のAPKを渡しません。自作の小さなサンプル、ライセンス上利用が認められたオープンソースサンプル、または明確な許可を得た検証対象を使います。

Claude Codeには、次のように「実行前の計画」を出させます。

このサンプルは自分たちが所有する検証対象です。
実行前に、認可範囲、分類結果、候補ツール、必要なファイル、
ネットワーク利用の有無、停止条件を一覧で示してください。
承認するまで解析コマンドを実行しないでください。

確認する出力は4つです。

• どの種類の逆向き解析として分類したか。
• なぜjadx、Ghidra、radare2、Fridaなどの候補を選んだか。
• 利用できないツールがある場合、何へ切り替えるか。
• 実行に失敗した場合、どこで停止して人間へ戻すか。

この検証では、同じ目的でも入力を少し変えます。APKのクラス一覧確認、ELFのヘッダー確認、未知形式のファイル、単なるソースコードレビューを別々に用意します。すべての「セキュリティ」「解析」という語に同じSkillを割り当てる説明文は危険です。対象形式と目的を明示し、広すぎる誘発語を減らします。

Skillの完全な内容は、呼び出された時点で会話へ読み込まれ、その後のターンでファイルが自動再読込されるわけではありません。説明文だけでなく、セッション中に守るべき条件を本文へ書くことが重要です。公式仕様でも、Skillの内容と権限付与は別に扱われ、allowed-tools の権限は呼び出しターン単位で消えると説明されています。

解析ツール不足の切り分け

ツールが足りない場合、Agentにいきなりインストールを任せない方が安全です。まず次の情報を出力させます。

1. 実行ファイルのパス。
2. ツール名とバージョン。
3. PATH上での解決結果。
4. 対象シナリオに必要かどうか。
5. 代替手段と精度上の差。
6. インストールによって変更されるパッケージや設定。

reverse-skillのREADMEでは、ツール一覧を tool-index.md で確認し、OS別スクリプトで更新する流れが示されています。ここで重要なのは、一覧更新とツールの追加導入を分けることです。遠隔の検証環境では、導入前後のパッケージ一覧、設定ファイルの差分、実行ログを保存します。

一時的なインストールを許可する場合も、対象ディレクトリを限定します。共有環境のシステム全体へ書き込む方法は、別案件の再現性を壊しやすく、削除時に依存関係まで巻き込む可能性があります。長時間稼働するAgentを置く環境については、作業基盤の隔離方法を確認し、解析用の作業領域と通常開発領域を分けてください。地域や利用形態を比較する場合は、Mac環境の案内で作業条件を確認してから決めます。

権限・監査・失敗時の戻し方

Claude Codeの権限設定には、許可、確認、拒否のルールがあります。公式仕様では、拒否、確認、許可の順に評価され、拒否ルールが優先されます。/permissions で現行ルールを確認できるため、導入前後で画面の内容を保存します。公式の権限設定では、ファイル、シェル、MCP、ネットワークを別の防御層として扱う考え方も説明されています。

最低限、次を拒否または確認対象にします。

• ホームディレクトリ外への読み書き。
• .env、秘密鍵、クラウド認証情報。
• 外部ネットワークへの接続。
• パッケージ管理者権限を使う変更。
• MCP経由の外部サービス呼び出し。
• 解析対象以外のリポジトリや共有フォルダ。

bypassPermissions は通常運用の近道にしません。公式ドキュメントも、すべての確認を省略するモードはコンテナや仮想マシンなど、影響範囲を閉じた環境に限るよう説明しています。権限設定だけでなく、OSレベルのサンドボックスを重ねるのが現実的です。公式のサンドボックス仕様では、ファイルシステムとネットワークを別々に制限し、必要な範囲だけを許可する構成が説明されています。

監査では、計画、実行したコマンド、入力ファイルのハッシュ、ツールのバージョン、出力、失敗理由、人工的な承認記録を残します。Claude CodeのHooksには、設定変更を監視するConfigChangeイベントがあり、Skillファイルの変更を記録またはブロックできます。Hooksの設定例を基に、少なくともSkill、権限設定、MCP設定の変更をログへ送ります。

注意：自動化が動いたことは、利用が合法であることを意味しません。対象所有者、許可範囲、許可期間、ネットワーク条件を案件ごとに記録し、確認できない場合は解析を止めます。

本番投入前の合格基準

最後に、壊れたファイル、未知形式、依存ツールの未導入、コマンドの終了コード異常を意図的に試します。合格条件は「成功すること」だけではありません。次の5項目を満たすかで判定します。

• 越境した対象や認可不明の依頼を拒否できる。
• 選んだSkillとツールの理由を説明できる。
• 不足ツールを勝手に追加せず、承認待ちへ戻れる。
• 失敗したコマンドとエラー内容を記録できる。
• 人間が途中で停止し、別の方法へ切り替えられる。

自前の環境で解析を続ける場合は、物理デバイス、特定のデバッガー、常時稼働する大規模処理が必要かを確認します。反対に、短期の検証、チーム共有用の隔離環境、案件ごとに破棄したい作業領域なら、Macのレンタル環境を候補に入れる価値があります。

現在の環境をそのまま使う方法には、権限が蓄積しやすい、依存ツールの差分を管理しにくい、監査ログが案件ごとに分散するという弱点があります。Macを購入して固定運用する方法も、長期の安定負荷や物理インターフェースが必要な場合には合理的ですが、短期の逆向き解析や検証案件では初期構築と撤去の負担が残ります。まず隔離されたMac環境で権限、ログ、回退テストを確認し、継続利用が決まった段階で自前設備と比較する方が、導入判断を誤りにくいです。

導入前には、作業基盤の隔離方法、許可されたサンプル、ログの保存先、人工的な承認手順を先に決めてください。必要なのは「AIに全部任せること」ではなく、許可されたサンプルだけを、説明可能なルーティングと記録付きで処理できる状態です。