エージェントを「作る」段階の話は、この一年でほぼ決着した。MCPで業務システムにつなぎ、スキルで手順をパッケージ化し、マルチエージェントで役割を分ける——部品はそろった。だが部品がそろった瞬間に、別の問いが立ち上がる。その部品は、どこの誰が作ったもので、中で何をしているのか。 社外のコミュニティが公開したエージェント／スキル／MCPサーバーを、あなたの本番環境に引き込む前に、誰が検（あらた）めているのか——という問いだ。
2026年9月3日、TenableとOpenAIが、この問いに正面から答える発表をした。コミュニティ製のAI部品を導入前に第三者が検査する仕組み、CyberAgents Exchange Inspector である（Tenable）。homula はエンタープライズ向けの AIエージェント・インテグレーターとして、日本企業の「どの部品を、どう安全に業務へ載せるか」を日々支援している。本稿は、この発表を手がかりに、エージェント部品のサプライチェーンに"検査"という新しい層が生まれつつあること、そして日本企業が自社側に置くべき受け入れ関門を整理する。
「レジストリにある＝検証済み」という思い込みは、もう崩れている
まず、なぜ検査層が要るのか。前提として押さえたいのは、多くの人が『マーケットプレイスやレジストリに載っている部品は、誰かが審査したもの』と暗黙に思い込んでいる——だが現実はそうではない、という点だ。
セキュリティ企業 OX Security が2026年4月に公表した調査は、これを実証した。無害な検証用のMCPサーバー（空ファイルを書くだけのもの）を主要な 11のMCPマーケットプレイスに投稿したところ、9つがそのまま受理し、審査で弾いたところは一つもなかった。数十万規模の月間訪問者を持つプラットフォームも含まれていたという（OX Security）。多くのレジストリの登録要件は「GitHubリポジトリかドメインの所有証明」だけで、コードレビューもマルウェアスキャンも通っていない。それでも利用者は「載っている＝ある程度チェックされている」と受け取ってしまう。この認知のズレが、そのまま攻撃面になる。
そして、これは机上のリスクではない。2025年9月、公式を装った不正なMCPサーバー postmark-mcp が、あるバージョン更新で送信メールすべてに攻撃者宛のBCCを1行追加し、メール内容を密かに外部へ転送していたことが判明した。世界で初めて確認された「実世界の悪質MCPサーバー」で、検知までに1週間以上稼働し、推定300〜500組織のワークフローに組み込まれていたと報じられている（The Hacker News）。
危険なのは「明らかに怪しい部品」ではない。15回のバージョン更新まで完全に正規どおり動き、16回目でたった1行の悪意を差し込む——このように"信頼を積んでから裏切る"部品だ。入口で一度スキャンしただけの防御は、こうした後出しの改変をすり抜ける。部品の供給網は、npmパッケージやコンテナイメージと同格の「棚卸し対象」になった。
Tenable×OpenAIの答え——コミュニティ部品を"導入前に検める"検査層
こうした背景で登場したのが CyberAgents Exchange Inspector だ。土台となる CyberAgents Exchange は、2026年8月に立ち上がったサイバーセキュリティ特化のオープンなレジストリで、AIエージェント・スキル・MCPサーバー・マルチエージェントのプレイブックを集める。Black Hat USA での「SWARM」ビルドイベントを経て、いまや100を超えるコミュニティ提出の部品が並ぶ（Tenable）。
問題は、まさに前節のとおり「数が増えるほど、玉石混交になる」ことだ。そこで Tenable は OpenAI と組み、レジストリ上の部品を導入前に検査するプロセスを用意した。Inspector は3つを組み合わせる。
- フロンティアモデルによる評価：OpenAI の GPT サイバーモデルで、部品の挙動・危険性を機械的に評価する。
- スキル検査：Tenable One の AI Exposure による、スキル（モデルの能力を拡張するモジュール部品）の露出・弱点の点検。
- 専門家レビュー：Tenable のリサーチャーによる人手の精査。
つまり「自動評価 × 露出分析 × 人手レビュー」の三層で、公開部品を環境に入れる前にふるいにかける。Tenable のチーフプロダクトオフィサー Eric Doerr は「エージェントAIが企業で本領を発揮できるのは、セキュリティチームが、自分たちの環境に持ち込む部品を信頼できるときだけだ」と述べている（Tenable）。Inspector は2026年9月の提供開始が見込まれている。
注目すべきは、これが特定ベンダーが自社マーケットの中身を自分でスキャンする話ではないことだ。Anthropic が Claude Enterprise 向けにスキル/プラグインのスキャンを提供した動き（別稿）は入口検査として重要だが、あくまで自社エコシステムの中の話だった。今回は独立した第三者（Tenable）が、他社のフロンティアモデル（OpenAI）まで使って、ベンダーをまたいだコミュニティ部品を検める。ソフトウェアの世界でAVベンダーやパッケージ監査が果たしてきた「中立の検査役」が、エージェント部品にも生まれ始めた、と捉えるのが正しい。
「第三者の検査」を過信しない——それは出発点であって保証ではない
ただし、ここで立ち止まりたい。第三者検査は歓迎すべき前進だが、「Inspector を通った＝安全」と読み替えた瞬間、冒頭の思い込みを別の看板で繰り返すことになる。
理由は3つある。第一に、検査はある時点のスナップショットだ。postmark-mcp の事例が示すとおり、部品は後から改変される。検査済みバッジは、その後のバージョン更新までは保証しない。第二に、検査は中身の危険性を見るが、あなたの環境での権限の広さまでは決められない。同じMCPサーバーでも、読み取り専用で渡すか、書き込み・送信の権限まで渡すかで被害の桁が変わる。第三に、検査結果を誰がどう扱うかは、依然として自社の運用設計の問題だ。
第三者検査は「良い部品を選ぶための材料」であって、「導入判断そのもの」ではない。材料は外から買えても、自社の環境に何を・どの権限で・誰の承認で入れるかを決める関門は、外注できない。検査層の登場でむしろ重要になるのは、その材料を受け取る自社側の受け入れプロセスだ。
日本企業が置くべき「受け入れ関門」
では、検査層が育ちつつある今、企業側は何を設計すべきか。責任の所在で整理すると次のようになる。第三者検査（Exchange Inspector のような外部の目）が渡してくれるものと、それでも自社で設計しなければならないものは、はっきり分かれる。
| 論点 | 第三者検査が渡すもの | 自社が設計すべきこと |
|---|---|---|
| 出所（provenance） | 部品の作者・挙動・既知の危険性の評価 | 誰の作った部品を許容するか、社内の許可リスト運用 |
| 受け入れ判断 | 「安全側／要注意」の材料 | 本番投入の承認フロー・誰が最終決裁するか |
| 権限付与 | （部品の危険性まで） | その部品に渡す権限の最小化（読み取り／書き込み／送信） |
| 実行時の監視 | （導入前まで） | 稼働後の挙動監視と、後からの改変検知 |
| 棚卸し | レジストリ上の部品情報 | 自社で実際に何を使っているかのインベントリ（シャドーMCPの発見） |
要は、入口（部品を検める）だけでなく、出口（何を・どの権限で・誰の承認で実行するか）まで一本の統制にすることだ。第三者検査は入口の質を上げてくれるが、出口を設計しないままでは、良い部品でも過大な権限で暴走しうる。米国のNSA等が示したMCPセキュリティの指針も、結局は「つなぐ前と、つないだ後の両方を統べよ」という同じ構図に行き着く（別稿）。
homulaの観点——検める材料を活かし、実行の"出口"を統べる
homula は、特定のベンダーやツールに縛られず、企業が自社にとって最適なAI構成を選び使い続けられるよう、戦略策定 → PoC（最短5日）→ 実装 → 運用 → 内製化までを一気通貫で支援している。エージェント部品の検査層が育つこの局面で、homula が推奨する順序は明確だ。
第一に、接続層をベンダー非依存で持つ。統合プラットフォーム Agens は、MCPを活用して200以上のツールと構築ゼロで接続する。どの部品を採るかは中立に選べる状態を保ちつつ、接続点をひとつに集約しておけば、「いま自社が何につないでいるか」を棚卸しできる観測点にもなる。検査済みの部品でも、まず"どこにつなぐか"が見えていなければ統べられない。
第二に、実行の出口を統制する。第三者検査が渡す「安全側／要注意」という材料は、受け皿がなければただの情報だ。Agens Control は、実行前の承認フロー・DLP・RBAC・5年分の監査ログを提供する。「どの部品を・誰が・いつ・どの権限で実行し、その判断材料に何を使ったか」を後から証明できる状態を作ることで、外部検査の結果を自社の意思決定に地続きでつなげられる。入口の検査と出口の統制がそろって初めて、コミュニティ部品を本番に載せられる。
第三に、小さく試し、関門ごと設計する。homula の AIエージェント・ブートキャンプは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結する。ここで「どの部品を、どの権限で、誰の承認で入れるか」という受け入れ関門ごと設計してしまうのが実務的だ。接続前提のエージェント設計で既存業務の処理時間を93%削減した実績も、こうした統制の下地があってこそ、安全に数字として出せる。
まとめ
- エージェント部品（エージェント／スキル／MCPサーバー／プレイブック）は、いまや実在するマーケットになった。だが**「レジストリに載っている＝検証済み」ではない**。OX Security の調査では9/11のMCPマーケットが無審査で検証用部品を受理し、postmark-mcp では実際の情報流出が起きた。
- 2026年9月、TenableとOpenAIが CyberAgents Exchange Inspector を発表。GPTサイバーモデル×露出分析×人手レビューで、コミュニティ部品を導入前に第三者が検める層が生まれた。ベンダー自社スキャンとは異なる「中立の検査役」の登場だ。
- ただし第三者検査は出発点であって保証ではない。スナップショットである以上、後の改変・権限付与・運用は自社の設計課題として残る。入口（検める）と出口（何を・どの権限で・誰の承認で実行するか）を一本の統制にするのが、これからの標準になる。
コミュニティ製の部品を、検めた上で、安全に本番へ。入口の見極めから出口の承認・監査まで、エージェント部品の受け入れ関門を、homula がご一緒します。