cc-audit: Claude Code の skill と MCP を入れる前に監査する

AI coding workflow でだんだん厄介になっているのは、「tool に接続できるか」よりも、

他人が作った skill、hook、MCP server、plugin を自分の環境に本当に入れてよいのか

という判断です。

第三者 artifact を試し始めると、すぐに次のような不安が出てきます。

環境変数や API key、SSH key を外へ送らないか;
tool 権限を広く取りすぎていないか;
crontab や authorized_keys を触るような永続化処理がないか;
説明文、schema、install script に prompt injection 的な仕込みがないか。

今日メモしておきたい ryo-ebata/cc-audit は、まさにこの入口を扱う project です。発想はかなり明快です。

先に入れてから祈るのではなく、先にスキャンしてから入れる。

GitHub repository page、README、releases page、GitHub API を 2026-07-02 時点で確認すると、この project は現在およそ 22 stars、1 fork。主言語は Rust、license は MIT。repository 作成日は 2026-01-24、直近の公開 code push は 2026-07-02 です。最新 release は v3.2.14 で、公開日は 2026-02-02 です。

Project overview

項目	内容
Repository	ryo-ebata/cc-audit
位置づけ	AI coding artifact 向け静的セキュリティ監査ツール
Stars	22
Forks	1
主言語	Rust
Repository 作成日	2026-01-24
直近の公開 code push	2026-07-02
Latest version	v3.2.14
Release date	2026-02-02
Code license	MIT
中心の考え方	skill、hook、MCP などをインストール前に deterministic に監査する

これは「skill をどう書くか」ではなく「まず自分を守る」ための tool です

cc-audit の良さは、AI coding ecosystem の安全問題をかなり具体的に切っているところです。

README 冒頭でも、これは Security auditor for Claude Code skills, hooks, and MCP servers だと明言されています。つまり、また別の marketplace でも、巨大な agent platform でもなく、

第三者 artifact が自分の workflow に入る直前の地点

を見ています。

この切り方はかなり実務的です。多くのリスクは model 本体から来るというより、あなたがどの script、config、tool boundary をローカルに持ち込むかから来るからです。

リスクの見立てがかなり現実的です

README にあるリスク分類は、かなりそのまま実運用の不安に対応しています。

Data exfiltration;
Privilege escalation;
Persistence;
Prompt injection;
Overpermission.

どれも、第三者の skill や MCP server を何本か試したことがあればすぐ想像できます。

重要なのは、cc-audit がそれを「注意して使いましょう」で終わらせていないことです。流れとしてはかなり明快です。

artifact を取得する;
ルールベースで静的スキャンする;
severity と risk score を確認する;
そのうえで install するか、CI に通すか、repo に入れるかを決める。

review の勘や marketplace の雰囲気だけに頼るより、ずっと扱いやすいです。

skill directory だけを見ているわけではありません

2 つ目の実用ポイントは、監査対象が単一 skill directory に閉じていないことです。

README の現在の説明では、少なくとも次のような対象が含まれています。

skills;
hooks;
MCP 設定;
Docker 関連;
dependencies;
subagents;
plugins.

コマンド面もかなり分かりやすいです。

cc-audit check ./my-skill/
cc-audit check --type mcp ~/.claude/mcp.json
cc-audit check --type docker ./
cc-audit check --type dependency ./
cc-audit check --all-clients

この設計だと、「skill 単体の検査」だけでなく、

AI coding workflow 全体のローカル入口に置く監査レイヤー

として使いやすくなります。

特に --all-clients はかなり実用的です。今は Claude だけでなく Cursor、Windsurf、VS Code など複数 host を並行で使う人が多く、どの client に何がぶら下がっているか把握しにくくなりがちだからです。

LLM 判断ではなく、再現可能なルールを重視しています

この手の tool で大事なのは、

判定が再現できるか

だと思います。

cc-audit はその点でかなり筋が通っています。README から読み取れるのは、LLM に曖昧な安全判断を任せるのではなく、静的ルールベースで artifact を評価する方針です。

出力もかなり工程向きです。

ルール ID;
severity;
risk score;
fail exit code;
JSON / HTML / SARIF / Markdown 出力。

この形なら、

ローカルの事前チェック;
Git hook;
CI;
セキュリティレポート;
repository の gate

に自然に組み込めます。

「なんとなく危なそう」ではなく、「どのルールに引っかかったか」で話せるのはかなり大きいです。

install 前だけで終わらず、drift と runtime 側まで見ています

多くの security tool は最初のスキャンだけで終わりがちですが、cc-audit はそこから少し先まで見ています。

README で特に目につくのは次のあたりです。

baseline / drift detection;
MCP pinning;
remote repository scanning;
proxy mode;
watch mode;
CVE vulnerability scanning.

ここで大事なのは feature 数ではなく、

risk は初回 install 時だけでなく、その後の更新や runtime にもある

という前提を持っていることです。

最初は無害に見えた artifact でも、後から権限、script、dependency、設定が変われば話は別です。baseline、pinning、proxy を置いているのは、その変化まで追いたいからだと思われます。

どんな人に向くか

特に相性が良さそうなのは次のような人です。

第三者の Claude Code skill、hook、MCP server をよく試す;
複数の AI coding client を並行運用している;
artifact の導入を経験ではなくプロセスで管理したい;
監査結果を hook や CI に流し込みたい;
agent toolchain の supply-chain risk を気にしている。

自作の小さな script だけをたまに使う人には、すぐ必須ではないかもしれません。ただ、community artifact を増やし始めた瞬間に、この種の「先に監査する」tool はかなり効いてきます。

まとめ

ryo-ebata/cc-audit の面白さは、安全を大きく語ることではなく、問題をかなり具体的に切っている点です。

第三者 artifact をローカルへ入れてよいか;
install 前に止められるリスクは何か;
判定結果を engineering の gate に変えられるか。

もっと大きな agent platform を作るのではなく、

AI coding artifact が workflow に入る前に、再現可能で自動化しやすい安全診断を挟む

という小さくて重要な役割に集中しているのが良いです。

多くの agent tool が「さらに何ができるか」を増やしているなら、cc-audit が扱っているのはむしろ、

そもそも何を入れてはいけないのか

という問題です。