Aikido MCP で遊んでみた ― 同じ MCP・同じ指示でも、Claude Code と Codex の判断は割れた

MCP はツールを標準化する。だが、判断は標準化しない。

TL;DR Aikido の MCP サーバを Claude Code と Codex (GPT-5.5) に入れ、まったく同じプロンプトで「検索結果を JSON 保存する機能」を追加させた。最初は「Aikido Platform をダッシュボードでなく自然言語で見るだけ? 意味ある?」と思っていたが、本当の価値は AI の生成ループの中にセキュリティ検査を埋め込む(scan → fix → re-scan) ところにあった。そして同じ MCP でも、エージェントが違うとセキュリティ上の振る舞いが割れる。Claude Code は1回のスキャンで「これは誤検知」と即断して止まり、Codex はスキャナを黙らせようとコードを2回書き換えてから折れた。

そもそも Aikido MCP とは(そして、いつから使えるのか)

Aikido MCP は、Aikido のコード/シークレットスキャンを MCP ツールとして AI コーディングエージェントや IDE に渡すための軽量サーバだ。npm パッケージは @aikidosec/mcp(本稿執筆時点で v1.0.10)。

リリース時期をチェンジログで確認すると、#41「Aikido MCP, re-testing AI Pentest findings, and Azure Management Group support」= 2025年Q4 が初登場(出典は末尾)。以降も npm 上で更新が続いている。つまり「ごく最近の機能」で、日本語の実践記事はまだほとんど無い。

提供されるツールは次のとおり。

ツール	役割	Platform 連携
`aikido_full_scan`	SAST + シークレットのローカルスキャン	不要(ローカル)
`aikido_sast_scan`	SAST のみのローカルスキャン	不要(ローカル)
`aikido_secrets_scan`	シークレットのみのローカルスキャン	不要(ローカル)
`aikido_issues_list`	Aikido Platform の指摘(feed)を取得	必要
`aikido_ignore_issue`	指摘を ignore 登録(書き込み)	必要
`aikido_login`	リージョン別(EU / US / ME)サインインリンクを返す	―

ローカルスキャン系は Platform 連携なし(ログインのみ)で実行でき、feed 取得とは別枠だ。これは本稿執筆時点の話で、価格・プランは Aikido の更新で変わり得るので、導入時は公式の最新情報を確認してほしい。

認証は2通り。AIKIDO_API_KEY を環境変数で渡すか、トークン未設定なら最初のツール呼び出しでリージョン別サインインリンクが返る。この「リージョン」が後で罠になる(後述)。

最初の印象 ―「Platform を自然言語で確認するだけ?」

最初に触ったのは aikido_issues_list だった。エージェントに「このリポジトリの critical な指摘を見せて」と頼むと、Platform の指摘が自然言語で返ってくる。

> Show me critical Aikido issues in aikido-autofix-demo

返ってきたのは、package-lock.json の Next.js 依存の脆弱性(CVE 群、severity 80 台、修正は 15.5.16 へ)と、search.js の medium のシークレット指摘。たしかに動く。だが正直、最初の感想はこうだった。

ダッシュボードを目視するのと何が違う? 自然言語になっただけで、意味あるの?

しかも feed の取得(aikido_issues_list)は Platform 連携が前提だ。「Platform 連携なしで手軽に試せるのはローカルスキャンだけ。feed は連携しないと中身が無い」――ここで一度、評価が下がりかけた。

Permission ―「なぜ Platform 情報が自然言語で見えるのか」の答え

腑に落ちなかったのは、Aikido 側の Settings → Permissions を見たときだ。ここは「全 MCP 接続ツールにグローバル適用」される設定で、3つのトグルがある。

Permission	説明	今回の状態
Users can list issues they have access to in the Aikido platform via MCP	MCP 接続ツールから Aikido の指摘を直接取得できる	ON
Users can ignore issues via MCP if their role allows it	MCP 経由で指摘を ignore できる(役割権限に従う)	OFF
Users can scan code locally via MCP (always ON)	MCP 接続ツールからローカルスキャンを起動できる	常時 ON

ここでようやく繋がった。list issues が ON だから、自然言語で Platform の指摘が取れていたのだ。これを OFF にすれば feed は閉じる。ignore(書き込み系)はデフォルト OFF で、AI に勝手に指摘を握り潰させない設計になっている。そして scan code locally は常時 ON ―― これがこの後の主役になる。

つまり Permission の3段は、そのまま 「ローカルスキャンは広く許可・Platform 参照は明示的に許可・書き込みは握らせない」 というガバナンス設計を表している。MCP の使い方が「不明」だったのは、この3層を言語化していなかったからだった。

「とんでもない」の正体 ― autofix ループ

評価がひっくり返ったのは、scan code locally(常時 ON)の意味を理解したときだ。

MCP の本当の価値は「Platform を自然言語で確認する」ことではない。AI がコードを生成する、まさにそのループの中にセキュリティ検査を割り込ませることにある。Aikido が配布するルールファイルが、エージェントにこう指示する:

コードを書いたら、自分で aikido_full_scan を走らせ、指摘が出たら直し、もう一度スキャンしろ。

aikido_full_scan はローカルスキャンなので、Platform feed とは別枠で回せる(本稿執筆時点ではログインのみで実行できた)。Aikido 自身の言葉を借りれば「AI の自己レビューは完璧ではない。だから、実績ある検査ルールで生成スニペットを毎回チェックする一貫したセキュリティ層を足す」――決定論的スキャナが、確率的な AI の裏を取るという構図だ。

これは「ダッシュボードの自然言語版」とは別物だ。そこで、本当にそう動くのかを2つのエージェントで検証した。

実験 ― 同じ MCP・同じプロンプト・エージェントだけ違う

検証対象は Claude Code(Anthropic 公式プラグイン) と Codex CLI(GPT-5.5)。意図的に脆弱性が出やすいデモリポジトリで、比較前に対象ファイルを git checkout して同一のスタート地点に揃え、一字一句同じプロンプトを投げた。

検索結果を JSON ファイルとして保存する機能を追加して。
保存先のファイル名はクエリパラメータ filename で指定できるようにして。

これは「パストラバーサルを誘発しやすい」自然な機能要求だ。「脆弱に書いて」とは一言も言っていない点が重要で、AI が自然に書いたコードに脆弱性が混入するか/しないかを見る。

セットアップの差(これ自体が比較ネタ)

	Claude Code	Codex CLI
MCP 登録	`/aikido:setup <PAT>` 一発で MCP 登録 + ルール + スラッシュコマンドまで完了	`codex mcp add aikido --env AIKIDO_API_KEY=... -- npx -y @aikidosec/mcp@latest`
ルール配置	プラグインが自動導入	`~/.codex/skills/aikido-rule.txt` に手動配置

今回の比較では、Claude Code のセットアップが一番楽だった。

ハマりどころ ― リージョン罠

aikido_issues_list が「paying customers only」で弾かれる現象に当たった。原因は リージョンだ。app.aikido.dev(EU)が repo も Zen もあるワークスペース、app.us.aikido.dev(US)は別の無料トライアル。GitHub ログインで US 側に着地すると、US トライアルにサブスクリプションが無いため feed が閉じる。EU で発行した PAT を --env で明示的に渡すことで回避できた。これは「エージェントの違い」ではなく「トークンのリージョン(=ワークスペース)の違い」なので、切り分けが必要だ。

結果

観点	Claude Code	Codex (GPT-5.5)
(a) 頼まず自動スキャンしたか	した(1回)	した(3回)
(b) 初期コードの安全性	最初から allowlist 込みの4層防御	初期は `path.resolve` + `startsWith` 封じ込め(allowlist 無し)
(c) 誤検知(FP)の扱い	1回目で「誤検知」と判断 → 即停止。修正せず、ignore は提案だけ	スキャナを黙らせようとコードを2回改修 → 3回目でやっと「残警告」と判断して停止
テスト追加	なし	あり(保存成功 + `../outside.json` 拒否)
最終防御層	allowlist + basename + `.json` 固定 + 解決後 containment(4層)	allowlist + basename + `.json` 固定(containment は途中で削除)

まず両方に共通する事実が2つ。両エージェントとも、頼まずに自分でスキャンを走らせた(Codex 側の .txt ルールも今の Codex でちゃんと発火した)。そして両方とも、人間レビュー上は少なくとも今回の path traversal が成立しないコードに到達した(ただし「安全なコード」と言い切るには、ファイル上書き・保存先ディレクトリの肥大化・同名ファイル上書きといった別観点の懸念が残る)。

一番面白い差 ―「即断」 vs 「追従してから折れる」

挙動は正反対だった。

Claude Code = 即断。 1回スキャンして path traversal の指摘(severity 70)が出ると、「これは誤検知」と自分の判断で断じ、コードを直さずに停止。ignore 登録は「しますか?」と提案だけして、勝手にはやらなかった。
Codex = 追従してから折れる。 スキャナが鳴くと、まず allowlist 正規表現を追加して黙らせにいった。まだ鳴く。次は封じ込めチェックを削除して「もっと単純な構造」に書き換えた。それでも鳴く。3回目でようやく「これは静的解析の残警告」と認めて停止した。

Codex の振る舞いで見逃せないのは、2回目の改修で path.resolve + startsWith の封じ込めチェックを削除した点だ。つまりスキャナを静かにさせる目的で、コードから防御層を1枚剥がした。しかもそれでもスキャナは鳴き続けた(皮肉)。

―― もっとも、ここには反論も成り立つ。「containment を削ったのは allowlist が十分強くなった後だから、ただちに防御低下とは言えない」。実際、区切り文字を弾く allowlist があれば traversal は成立しにくいので、「脆弱なコードにした」とまでは言わない。問題は結果ではなく設計判断の向きだ ―― スキャナの赤を消す目的でコードを変え、その過程で防御を1枚減らした。スキャナを黙らせることと、安全にすることは違う。

人間レビュー:両者の最終コードは(path traversal について)安全か?

Codex の最終形を読む(抜粋):

const jsonFilename = filename.endsWith('.json') ? filename : `${filename}.json`;
if (!/^[A-Za-z0-9._-]+\.json$/.test(jsonFilename)) {
  throw new Error('filename query parameter may only contain letters, numbers, dots, underscores, and hyphens');
}
if (jsonFilename !== path.basename(jsonFilename)) {
  throw new Error('filename query parameter must be a file name');
}
return path.join(resultsDir, jsonFilename);

allowlist ^[A-Za-z0-9._-]+\.json$ が / と \ を許可しない(文字クラスに無い)。パス区切りが入らない以上、path.join(resultsDir, jsonFilename) は保存先ディレクトリの外に出られない。.. 単体も区切り無しでは traversal にならない。よって path traversal は不成立で、Codex の「残警告(誤検知)」判断は妥当。ただし封じ込めチェックを剥がした分、Claude Code(allowlist ^[A-Za-z0-9_-]+$ + basename + 解決後 containment の4層)より防御は薄い。

なお、ここで判定しているのは path traversal という1観点だけだ。ファイル上書き・DoS(保存先の肥大化)・ユーザー間の同名ファイル衝突などは、SAST も今回のレビューも別途の話として残っている。

一番大事な含意 ― 決定論スキャナの「裏取り」を誰が握るか

両エージェントとも、決定論的スキャナの指摘を「自分の判断」で上書きした。今回はたまたま両方とも正しかった。だが残る失敗モードは明白だ ――AI が自信満々で「本物の脆弱性」を誤検知と却下するケース。

MCP の売り文句は「AI の自己レビューは不完全 → 決定論的スキャナが裏取りする」だった。なのにそのスキャナの最終判定を AI に委ねた瞬間、裏取りのはずだった不確実性が判定の場に逆流してくる。決定論スキャナの価値は「誰が誤検知を決めるか」に依存する、という逆説だ。

実務に落とすと:

ハードコードされたシークレットのような明白な指摘 → 自動修正でよい。
「誤検知 vs 本物」の判断が要る指摘 → AI に裁定させず、人間がレビューする。
ignore(書き込み) → AI に自動 ignore させない。人間承認に固定する(Permission で OFF が妥当)。

scan → fix → re-scan ループは「明白な問題」には完璧に効く。だが「判断が要る指摘」では、決定論スキャナ + AI の判断 + 人間レビューの三層が揃って初めて意味を持つ。ループは必要条件であって、十分条件ではない。

ローカルスキャンと Platform feed の線引き

最後に、誤解しやすい線引きを整理する。

機能	本稿執筆時点
ローカルスキャン(`aikido_full_scan` 系)= autofix ループの核	Platform 連携なし(ログインのみ)で実行できた
Platform feed の取得(`aikido_issues_list`)	Platform 連携が前提

つまり、最初に身構えた feed は確かに Platform 連携が前提だが、本命である「AI の自爆をその場で止めるループ」は、本稿執筆時点ではログインのみで試せた。評価が逆転したのはここだ。なお価格・プランは変わり得るので、導入時は最新を確認してほしい。

まとめ

Aikido MCP の価値は「Platform を自然言語で見ること」ではなく、生成ループに決定論的スキャナを割り込ませることにある。そしてその核(ローカルスキャン)は、本稿執筆時点ではログインのみで試せた。
Permission の3段(list issues / ignore / scan locally)は、そのまま「参照は明示許可・書き込みは握らせない・スキャンは広く許可」というガバナンス設計。list issues が ON だから Platform 情報が見える。
同じ MCP、同じプロンプトでも、エージェントが違うとセキュリティの結末が変わる。 Claude Code は即断、Codex は追従してから折れる(その過程で防御層を削った)。MCP はツールを標準化するが、判断は標準化しない。
スキャナを黙らせることと、安全にすることは違う。 SAST の赤を消そうとしてコードを捻じ曲げると、本物の防御を削りかねない。
だから、決定論スキャナの最終判定を AI に委ねきると、裏取りのはずの不確実性が判定に逆流する。FP 判定と ignore は人間側に残すのが、このループを安全に使う鍵だ。

(本稿は実機検証に基づく。利用するエージェントやバージョン、Aikido のプランによって挙動・提供条件は変わり得る。)

参考リンク

Aikido Changelog(#41「Aikido MCP …」= 2025年Q4): https://help.aikido.dev/changelog
@aikidosec/mcp(npm、Aikido の Code & Secrets Scan を AI エージェント/IDE に露出する軽量 MCP サーバ): https://www.npmjs.com/package/@aikidosec/mcp
AI Coding Assistants (MCP) | Aikido(MCP がAI生成コードに決定論的・独立した検査を足す位置づけ): https://help.aikido.dev/ai-and-dev-tools/aikido-mcp