AI agent skill はスキャンを通過したのに、インストール前になぜ実行境界をもう一度見るべきなのか

In this lesson

1. なぜスキャンを通過してもそのままインストールしてはいけないのか
2. AI agent skill インストール前の go/no-go 表
3. 分離した試走で runtime 観察を補う方法
4. チームが明日から足せる最小の承認手順
5. AI に整理を手伝わせるための handoff prompt

スキャナーは手がかりを探し、承認プロセスはそのリスクを引き受けられるかを決める

スキャナーは重要だ。prompt injection、データ流出、権限昇格、ツール誤用、MCP リスクなど、よくある問題を見つける助けになる。MCP は、まず「AI ツールが同じ方式でデータやツールにつながるためのプロトコル」と理解すればよい。

ただしスキャナーが比較的得意なのは、次のような問いへの回答である。

• repo の中に怪しい文字列があるか。
• ファイル構成の中に、よくある悪性パターンがあるか。
• prompt が元の指示を上書きしようとしていないか。
• 機密ファイルの読み取りやデータ送信を明らかに求めていないか。

一方で、スキャナーだけでは答えにくい問いもある。

• この skill は、あなたのプロジェクト文脈では実際にどのデータへ届くのか。
• agent に連続で三手順呼び出されたあと、新しいリスクを組み合わせて作らないか。
• 書き込み権限が本当に必要なのか、それとも読み取りだけで足りるのか。
• ネットワーク接続先を制限できるのか。
• 失敗したとき、誰が止め、token を回収し、一時データを消すのか。

だからこそ、「スキャナー通過」は入口条件として扱うのがよく、最終判断には向かない。同じように、セキュリティスキャナーが問題を指摘したからといって、ツールに本番設定を自動で書き換えさせるべきではない。この文脈は次の記事ともつながる：AI セキュリティスキャナーが修正を促しても、人が変更可否を決める。同じ考え方を skill のインストール前に置くなら、こうなる。スキャナーは注意点を示せるが、判断には人が責任を持つ。

30 分で分離した試走を一度行う

dry-run は「先に試すが、実際にはデータ変更や公開をしない」ことだ。第三者製 skill では、dry-run はタスクを完了できるかを見るだけではない。どう完了するかを観察するためのものでもある。

言い換えると、この節は追加のテストではない。スキャナーだけでは見えない runtime 境界を補うためのものだ。skill が実際に動いたとき、何を読み、どこへ接続し、どのツールを使い、データが最終的にどの出力へ出るのかを見る。

次の順番で、小さな確認を一度実行できる。

1. 本物らしい偽タスクを用意する

最初のテスト対象に production プロジェクトを使わない。よりよい方法は、小さな fixture を用意することだ。

• 10〜20 個のファイルを用意し、実際の repo に似た構造にする。
• 2〜3 個の境界ケースを意図的に入れる。たとえば偽の .env、偽の顧客データ、偽の API key。
• 「changelog を整理する」「設定ファイルの不一致を見つける」など、明確なタスクを 1 つ置く。
• 「secrets/ ディレクトリを読んではならない」など、明確な禁止事項を 1 つ置く。

こうすれば、skill がタスクを終えたかだけでなく、触れてはいけない場所に触れたかも見られる。

2. 権限を三層に分け、最初から全開にしない

初回の試走では、次の順番で権限を開くのがよい。

1. 第1層： 読み取り専用ファイル権限、ネットワークなし。
2. 第2層： 読み取り専用ファイル権限、制限されたドメイン接続あり。
3. 第3層： 必要な場合にだけ書き込み権限を加える。ただし書き込み先は output/ または一時ディレクトリに限る。

skill が第一層で主なタスクを完了できるなら、第三層へ上げない。権限昇格には理由が必要だ。インストール手順に「full access 推奨」と書いてあるからといって、そのまま従うべきではない。

3. 四種類の runtime シグナルを記録する

runtime は、まず「プログラムが実際に動いている時間帯」と理解すればよい。分離した試走では、少なくとも次の四種類のシグナルを記録する。

• ファイル：どのパスを読んだか。どのパスへ書いたか。forbidden directory に触れたか。
• ネットワーク：どのドメインへ接続したか。request サイズが異常ではないか。動的に内容をダウンロードしたか。
• ツール：どの shell、ブラウザ、API、MCP tool を呼んだか。順序は妥当か。
• 出力：最終回答が知るべきでないデータを引用していないか。社内内容を外部サービスへ貼っていないか。

最初から重いセキュリティ基盤を作る必要はない。小さなチームなら、container log、proxy log、ファイルシステム audit、agent tool-call log を組み合わせて、第一版の観測を作ればよい。重要なのは、試走のあとで見返せる痕跡を残すことだ。

4. 結果を「使えそう」ではなく go/no-go にまとめる

試走後、Slack に「見た感じ OK」とだけ残して終わらせない。結果は次の三状態にまとめる。

• go：限定されたワークフローへ入れてよい。同じ権限制限と監視を維持する。
• conditional go：特定 owner、特定 repo、特定タスクだけで使う。2 週間以内に再確認する。
• no-go：インストールしない。理由を残し、次に別の同僚が同じ道をたどらないようにする。

conditional go が多すぎるなら、その skill はまだチーム共用ツールに向いていない可能性が高い。個人の実験環境には置けるかもしれないが、正式なワークフローへ入れるべきではない。

明日から足せる最小の一手

いま完全なプロセスがなくても、セキュリティ基盤が完成するまで待つ必要はない。明日はまず、この一手を足す。

誰かが第三者製 AI agent skill をインストールしたいとき、必ず 6 行のインストール申請カードを添える。

1. 出所と版： skill の出所 URL、バージョン、または commit hash。
2. 単一タスク： この skill が解決する単一タスク。
3. データ権限： その skill が読む必要のあるディレクトリとツール。
4. ネットワーク要件： ネットワーク接続が必要か。必要なら予想ドメインを列挙する。
5. 試走データ： 初回 dry-run に使う偽データセット。
6. 異常時の後始末： 異常時の owner と、token 取り消しまたは停止方法。

owner とは「最後の判断と後始末に責任を持つ人」だ。このカードは美しくなくてよい。ただし次の人が読んで分かる必要がある。なぜ入れるのか。何を与える予定なのか。越境したときに誰が処理するのか。

このカードがあれば、スキャナーは承認プロセスの代替ではなく、承認プロセスの一部になる。

AI 整理カード

この判断表を自分の次の一手に落とす このプロンプトは、AIに先に背景を聞かせてから判断させる。記事の要約ではなく、作業フローの確認に使う。

このBMCミニレッスンを自分の状況に当てはめたい：AI agent skill はスキャンを通過したのに、インストール前になぜ実行境界をもう一度見るべきなのか

この記事が扱う具体的な問題：第三者製の AI agent skill がスキャンを通過しても、実行時まで安全とは限らない。このミニレッスンでは、出所、権限、サンドボックス、ネットワーク、機密データの境界を go/no-go 表で確認する。
記事URL：https://boosterminiclass.com/ja/posts/ai-agent-skill-install-runtime-risk-checklist/

記事を要約するだけにしないでほしい。まず、次の3点を確認する質問をしてほしい。
1. いま扱っている実際のワークフローまたは判断は何か。
2. その流れに関わるデータ、権限、アカウント、費用、外部実行は何か。
3. 今日ほしいのは、停止判断、試用チェックリスト、引き継ぎテンプレート、リスク分級のどれか。

そのうえで、この記事固有の枠組みで私の状況を確認してほしい：

出力してほしいもの：
- 進める、範囲を絞って試す、一度止める、のどれかを一文で判断する。
- 枠組みを私の状況に当てはめ、準備済み／証拠不足／人間確認が必要、に分けた表。
- 今日できる最小の一手。
- 担当者、ログ、戻し方、人間レビューが必要な箇所。

出力は草案として扱う。実行前に、データ、権限、責任範囲を人が確認する。