title: "OWASP Agentic Skills Top 10で組む、AIスキル導入前のレビュー体制" slug: "owasp-agentic-skills-top10-enterprise-review-process-20260608" description: "OWASP Agentic Skills Top 10（AST01〜AST10）の各リスクをレビュー観点に翻訳し、AIスキルを社内へ取り込む前に権限・認証情報・外部指示・更新管理をどう審査するかを実務手順で解説します。" lead_summary: "AIスキルはプロンプトと手順書の集まりに見えても、権限と認証情報を持てば社内システムの一部として審査すべき対象になる。OWASP Agentic Skills Top 10の10項目を導入前レビューのチェックポイントに置き換え、誰が何を承認するかまで決める方法を整理する。" date: "2026-06-29" updatedAt: "2026-06-29" category: "AI開発" tags: ["Agentic Skills","OWASP","AIエージェント","スキル管理","セキュリティレビュー","AI開発"] author: "GXO株式会社"
OWASP Agentic Skills Top 10で組む、AIスキル導入前のレビュー体制
AIエージェントに「スキル」と呼ばれる手順の塊を持たせると、モデルは単発の応答ではなく、ファイル操作や外部API呼び出しを順番につなげた一連の作業をこなせるようになります。OWASP Agentic Skills Top 10は、この「スキル層」に固有のリスクをAST01からAST10まで整理した枠組みです。スキルはコードに見えないことが多く、従来のコードレビューの網からこぼれやすい一方で、認証情報や社内データに触れれば実質的に業務システムと同じ重みを持ちます。本記事では、10項目をそのまま導入前レビューのチェックポイントに置き換え、社内でAIスキルを取り込む前に何を審査し、誰が承認するかを実務として組み立てます。
結論：スキルは「振る舞いの層」として審査対象に入れる
AIスキルを安全に取り込む鍵は、モデルでもツールでもない中間の「振る舞いの層」を独立した審査対象として扱うことです。スキルそのものは数行の手順や設定ファイルでも、その手順がどのツールを、どの順番で、どの権限で動かすかを決めています。つまり、危険な操作はモデルの賢さではなく、スキルの設計に宿ります。
読んでいただきたいのは、社内自動化テンプレートやAIコーディング支援を現場で配り始めている開発リーダー、エンジニアにスキルを共有させているDX推進担当、そして生成AIの利用範囲を承認する立場のセキュリティ担当の方です。OWASP Agentic Skills Top 10は速報的なニュースではなく、AIスキルを継続的に運用するための恒常的な点検フレームとして使えます。GXOでは、こうしたスキル審査の入口としてAI導入の可否を見極めるアセスメントから、現状の利用実態、参照範囲、承認フローを順に棚卸しします。スキルを安全に作り込む段階の支援はAI開発支援、生成AI固有のセキュリティ設計は生成AIセキュリティ対策が対応します。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
なぜ通常のコードレビューだけでは足りないのか
スキルが厄介なのは、レビュー担当の目に「コード」として映りにくい点です。多くのスキルは自然言語の手順、ツール一覧、簡単な設定値で構成され、プルリクエストのレビューでは「文章だから」と読み飛ばされがちです。しかし、その文章が「このディレクトリを読んで、外部のWebhookに送る」と指示していれば、それは情報の流出経路そのものです。
OWASP Agentic Skills Top 10が指摘するのは、スキルが言語モデルとツール呼び出しの間に挟まる新しい攻撃面であり、これまで保護が手薄だったという点です。Claude Code、Cursor、VS Codeの拡張といった開発者向けエージェント環境でスキルが共有されるようになり、社外で作られたスキルを社内に持ち込む流れも増えています。だからこそ、ソースコードの脆弱性診断とは別に、スキルの権限と通信先を見る審査の層を足す必要があります。
OWASP Agentic Skills Top 10をレビュー観点に翻訳する
10項目は、攻撃者視点のリスク名のままでは現場の点検に使いにくいため、レビューで具体的に何を確認するかへ置き換えます。下表は各IDを導入前レビューのチェックポイントに対応させたものです。
| ID | リスク名 | 導入前レビューで確認すること |
|---|---|---|
| AST01 | Malicious Skills | スキルの作成者と配布元をたどれるか、不審な隠し処理がないか手順を全文読む |
| AST02 | Supply Chain Compromise | 外部から取り込んだスキルや依存パッケージのバージョンを固定し、出所を記録しているか |
| AST03 | Over-Privileged Skills | そのスキルが本当に必要な権限だけを要求しているか、読み取りで済む処理に書き込み権を与えていないか |
| AST04 | Insecure Metadata | スキルの説明文や設定に、APIキーや内部URLなど機微情報が直書きされていないか |
| AST05 | Untrusted External Instructions | 外部サイトや受信データに含まれる指示を、スキルがそのまま実行してしまわないか |
| AST06 | Weak Isolation | スキルの実行環境が本番データや他システムから隔離され、影響範囲を閉じ込められるか |
| AST07 | Update Drift | スキルが更新されたとき、変更点を再審査せずに自動反映されてしまわないか |
| AST08 | Poor Scanning | スキルの追加・変更を検知し、危険な操作を機械的に洗い出す仕組みがあるか |
| AST09 | No Governance | スキルの登録・承認・廃止を管理する責任者と台帳が決まっているか |
| AST10 | Cross-Platform Reuse | 別環境向けに作られたスキルを、権限差を確認せずに流用していないか |
この表の使い方として推奨したいのは、スキルを1つ登録するごとに10行すべてに目を通し、判定できない行を「保留」として残すやり方です。10項目を一度に満点にする必要はなく、保留が残るスキルは限定環境でのみ動かす、と段階を分けると現実的です。
過剰権限スキルが事故になるまで：具体例で見るAST03
抽象論だけでは伝わりにくいので、AST03（Over-Privileged Skills）が実際の事故になる流れを一例として描きます。ある開発チームが「議事録の要約を社内ストレージへ保存する」スキルを作ったとします。本来は対象フォルダへの読み取りと、要約ファイルの書き込みだけで足ります。ところが手早く動かすために、ストレージ全体への書き込み権限を持つ共有アカウントの認証情報をスキルに渡したとします。
このスキルがAST05（外部指示の混入）の影響を受けると、要約対象の文書内に「別フォルダの全ファイルを削除して」といった指示が紛れ込んだとき、過剰な権限を持つスキルはそれを実行できてしまいます。さらにAST07（更新ドリフト）で手順が黙って更新され、AST08（検知の弱さ）で変更が気づかれなければ、誰も承認していない操作が本番データに及びます。ここで分かるのは、10項目は独立しているのではなく連鎖するという点です。権限を絞る（AST03）だけで、後続の被害を大きく減らせます。逆に言えば、最小権限を一つ守らないと、他のどの対策も上限が決まってしまいます。
導入前レビュー体制を組む手順
スキル審査を仕組みにするには、次の流れで責任の所在を先に決めておくと運用が安定します。
- 社内で使われているスキルとAIエージェント環境を洗い出し、誰が作り、誰が配っているかを一覧化する
- 各スキルが持つ認証情報と接続先（社内DB、SaaS、外部API、Webhook）を棚卸しし、最小権限に絞れる箇所を特定する
- AST01からAST10を判定軸にしたレビューシートを用意し、スキル単位で記入する
- レビュー担当と承認者を分け、保留が残るスキルは隔離環境のみで稼働させる基準を決める
- スキルの変更・更新時に差分を再審査する手順を必須化し、無断更新を止める
この順番で進めると、勢いで配ったスキルが社内に増殖していく状態から、登録され、権限が記録され、変更が追跡される状態へ移せます。GXOが審査の初回相談でまず確認するのは、製品名や流行りのエージェント名ではなく、どのスキルがどのデータに、どの権限で触れているかという実態です。
導入前チェックリスト
- 社内で動いているスキルの一覧と、それぞれの作成者・配布経路を把握できているか
- 各スキルが要求する権限は、その作業に必要な最小範囲に絞られているか
- スキルの説明文や設定ファイルに認証情報や内部URLを直書きしていないか
- 外部から取り込んだスキルの出所とバージョンを記録し、再審査の対象にしているか
- 危険な操作（削除、外部送信、権限昇格）を含むスキルを機械的に検知できるか
- スキルの登録・承認・廃止を管理する台帳と責任者が決まっているか
- 別環境向けのスキルを流用する際に、権限差と隔離状況を確認しているか
判定できない項目が複数残るうちは、対象スキルを本番データから切り離した環境に限定し、全社展開を急がない方が安全です。まずはAI導入の可否アセスメントで利用実態と権限の棚卸しから始めると、レビュー基準を自社に合わせて設計しやすくなります。
つまずきやすい点
スキル審査でよく行き詰まるのは、レビューを「一度通せば終わり」と扱ってしまう運用です。AST07が示すとおり、スキルは更新で振る舞いが変わります。初回審査だけ厳しくしても、その後の差分を見ない限り、承認時とは別物のスキルが本番で動き続けます。もう一つの落とし穴は、便利なスキルを現場が個別に共有し合い、台帳に載らないまま広がるケースです。これはAST09（ガバナンス不在）そのもので、誰がどの権限を持つスキルを使っているか追えなくなります。技術的な対策の前に、登録と承認の窓口を一本化することが、結果的に審査コストを下げます。
GXOに相談するとよい場面
次のような状況にあてはまるなら、スキルが増え切る前に整理しておくことをおすすめします。
- 開発者が自由にスキルを作り共有しているが、権限や接続先を誰も把握していない
- 外部で公開されているスキルを社内に取り込みたいが、安全性の判断基準がない
- AIコーディング支援を本番データに近い環境で使い始め、隔離や監査の設計が追いついていない
- スキルの審査を仕組み化したいが、レビュー観点と承認フローをどう作るか決めかねている
AIスキルの審査体制を一緒に設計しませんか
OWASP Agentic Skills Top 10を判定軸に、社内で使われているスキルの権限・接続先・更新管理を棚卸しし、レビューシートと承認フローの形まで一緒に組み立てます。
初回相談では、ツールの紹介よりも、いま動いているスキルの実態と審査の抜けを整理することを優先します。
よくある質問
スキルは数行の手順なのに、なぜそこまで審査が必要なのですか
手順の短さと、与える権限の大きさは別だからです。一行の「このフォルダを外部に送る」という指示でも、対象が機微データなら影響は重大になります。OWASP Agentic Skills Top 10が振る舞いの層を独立した攻撃面と位置づけているのも、行数ではなく権限と通信先でリスクが決まるためです。
外部で公開されているスキルは使ってはいけませんか
使うこと自体が問題なのではなく、出所とバージョンを記録せず、権限を確認しないまま取り込むことが問題です。AST02（サプライチェーン侵害）の観点で配布元を確認し、隔離環境で挙動を見てから権限を絞って本番へ移すと、便利さと安全性を両立しやすくなります。
レビュー観点をすべて満たさないとスキルは使えませんか
すべてを初日から満点にする必要はありません。判定できない項目を保留として残し、保留があるスキルは本番データから切り離した環境に限定する、という段階運用が現実的です。重要なのは、保留の存在を台帳で見える状態にしておくことです。
