AI駆動開発における開発環境のセキュリティの考え方 DevelopersIO 2026 Tokyo 2026年10月24日（土）17:30〜18:00 クラスメソッド株式会社 AI事業本部 研究開発エンジニア 山本 紘暉 

自己紹介：生成AI活用のセキュリティ・ガバナンスを支援している クラスメソッド株式会社 研究開発エンジニア ・大学・大学院： 電子情報学専攻。HCI・MR の分野の研究 ・新卒： 電機メーカーで、ソフトウェアとシステムの研究開発 ・6年前〜： クラスメソッドに転職。コンピュータビジョン・深層学習の研究開発 ・3年前〜： 生成AIの分野に移り、現在の業務を担当 自身も普段から AI を使って開発しているエンジニア。普段は以下のような業務を担当 技術コンサルティング・アドバイザリー PoC・技術検証 ソフトウェア・システム開発 生成AI活用のセキュリティ・ガバナンス セキュリティガイドラインの作成や社内ルールづくりを支援 

注意事項：専門家としての発表ではなく、社内の対策の紹介でもない 発表者の立場 セキュリティの専門家ではなく、内容に誤りが含まれる可能性がある 発表の位置づけ クラスメソッド社内で実施しているセキュリティ対策を紹介するものではない 情報システム部門・セキュリティ担当の意見は得ているが、完全なレビューを受けたものではない 発表者が把握している情報を、自分なりに整理したもの 扱う範囲 AI エージェントを動かす開発環境のセキュリティを扱う 出典の扱い 外部サイトへのリンクは、リンク先の内容の正しさまでは確認できていない AI で作った成果物や、構築したシステムのセキュリティの話ではない 成果物への広げ方は、最後に今後の展開で触れる 補足資料には AI に書かせた部分も多い 

ゴールと進め方：開発環境に必要な対策を、体系的に整理する考え方を把握する 対象者 AI駆動開発の開発環境のセキュリティに、不安を感じている方 開発者 AI エージェントから権限を 求められるたびに、どこまで 許可してよいかの基準がない AI 活用推進の担当者 情報システム部門 「安全なのか」と聞かれても、 安全である根拠を 説明できない 何をどこまで許可するかの 線引きと、その根拠を書いた ガイドラインがない 発表の流れ 前置きで課題を共有し、本題で体系的な整理の手順を示す 背景と前提 スライド06〜07 課題と実例 スライド08〜14 体系的な整理 スライド15〜21 スライド22〜24 スライド25〜29 AI に任せる範囲が 広がっている 対策の一覧だけでは 抜けが見えない NIST CSF・CIA・FTA で整理する 手順・最初の質問 と実際の利用例 利用者・成果物 への広げ方 前置き 本題 まとめ 今後の展開 

位置づけ：本発表は、AIエージェントのガイドラインを定める考え方を扱う セキュリティガイドライン（全社） すでに策定されているケースが多い 生成AIガイドライン 上位の方針をもとに、下位を具体化する 本発表 AIエージェントのガイドライン （AI駆動開発 = AIエージェントを使った開発プロセス） この階層を定めるための考え方 ツール別のガイドライン 例：Claude Code の設定、組織統制 （実際の設定） （守る対象と、必要な対策） 

背景：ソフトウェア開発でAIに任せる作業範囲が広がっている 外側のレベルほど、AI に任せる項目が増える（内側の項目はすべて含む） レベル4 レベル3 レベル2 レベル1 コードを読み、 助言する （読み取り専用） ファイルの変更や コマンドの実行を任せる （毎回、人間が承認） 人間が目標を決め、 決めた範囲の中で AI が自律的に進める （要所で承認） 本発表が前提にする段階 ※ AWS「Agentic AI Security Scoping Matrix」の4スコープを基にした整理 すべてを AI に任せる （人間の承認なし） 

前提：モデルは確率的に脆弱で、任せる量が増えるほど問題が起きやすい AI が意図しない動作をする原因 外部の入力（読み込むファイル・Web ページ） プロンプト インジェクション データ ポイズニング 内部の入力（開発者の指示） 指示不足 （プロンプトが 足りない） 勘違い （AI が指示の 解釈を誤る） 実行回数が少ないうちは 事故は起きていない AI の意図しない動作 暴走 原因が別でも、結果は同じ 実行回数が増えると 任せる作業範囲が広がり、 実行回数が増える × × どこかで意図しない挙動（×）が起きる 1回あたりの確率が低くても、実行回数が増えれば、事故が起きる確率は積み上がる □ ＝ AI が操作（コマンドやタスク）を1回実行すること 

課題感：「認証情報を読ませない」で十分なのか、説明できなかった 去年、AI駆動開発という言葉が広がり始めたころに感じた疑問 2025年ごろ、よく見かけた書き方 認証情報を AI に読ませない 環境変数に置けば大丈夫 発表者が感じた疑問 環境変数に置けばよいのか？ 読み込めないだけでよいのか？ 十分だと説明できるのか？ 同じ疑問を感じている方も、いるのではないか 

具体例：通信先を AWS に絞っても、別アカウントへ送り出せる AWS CLI を入れ、AWS のドメインへの通信を許可して使う構成の想定例 開発環境（PC・コンテナ） AWS（*.amazonaws.com） 攻撃者の指示 （読み込んだファイル・Web） AI エージェント 攻撃者のキー に書き換える 環境変数 認証情報 組織のアカウント 自社の S3 バケット 正規の操作（aws s3 cp など） 実行 AWS CLI 読む aws s3 cp 通信の許可リスト *.amazonaws.com だけ許可 攻撃者の認証情報で送り出される 許可リストを通過 他者のアカウント S3 バケットなど AWS_ACCESS_KEY_ID 開発者のアクセスキー AWS_SECRET_ACCESS_KEY 問題点2：認証情報を置いた環境変数を書き換えられる 問題点1：同じドメインに、他者のアカウントもある 通信先を絞るだけでは止まらない。どう防ぐか？ 

問いかけ：この経路を防ぎ、対策の抜けも判定できますか 挙手で答えてもらい、最後に同じ質問をする 会場のみなさんへの質問（挙手） スライド09 の経路をふまえて ① この経路の防ぎ方を、説明できる方 ② 開発環境の対策に抜けがないかを、判定できる方 

実例1：300 以上の組織の開発者のもとで、同じ動作による公開が見つかった セキュリティ企業 Glow Labs の調査（2026年9月公表）によると、AI エージェントが社内の画面を公開リポジトリに置いていた 開発者の PC 開発者の指示 「UI の修正が動いたことを示して」 AI のコーディングエージェント 社内の画面を撮影 請求記録・送金の管理画面・ 未発表の機能 GitHub（業務で許可している通信先） 社内リポジトリの プルリクエスト 画像を公開するツール（gitshot） を使った例もある CLI からは画像を添付できない PR から画像を参照 エージェントの判断で、 開発者の個人アカウントに 公開リポジトリを作り、 画像を置く 公開リポジトリなので、 誰でも画像を見られる 開発者は公開を指示していない 出典：Glow Labs（2026年9月）https://www.glow.io/blogs/how-ai-agents-exposed-developer-screenshots-from-leading-tech-companies 被害：漏洩・窃取（機密性） 

実例2：PocketOS で、AI エージェントが本番の DB とバックアップを削除した レンタカー事業者向けの SaaS（2026年4月）。staging の問題を直そうとして、本番のボリュームを消した 開発環境（Cursor） 開発者：staging での作業を依頼 Cursor のエージェント （Claude Opus 4.6） staging で認証エラーが起き、 使う 「ボリュームを消せば直る」と判断 Railway（本番の環境） curl で Railway の API を呼び、 staging のつもりでボリュームを削除 ボリューム 本番のデータベース 削除された 確認なし、9秒で完了 本番と共有のボリュームか確かめていない 無関係のファイルに書かれていた API トークン （ドメイン管理用に作ったが、 削除を含む全操作の権限） バックアップ （同じボリュームにあった） 一緒に削除された 本番とバックアップが同時に消えた 約30時間サービスが停止し、3か月分の予約データと新規登録が一時的に失われた（のちに Railway が復元） 実施していなかった対策：作業に関係のないファイル（認証情報）を読ませない、トークンの権限を最小にする、 不可逆な操作に別の承認を挟む、バックアップを別の場所に置く 出典：Live Science、＠IT（2026年4月30日）https://atmarkit.itmedia.co.jp/ait/spv/2604/30/news046.html 

課題：既存の情報では、ソフトウェア開発全体の対策を網羅できていない 対策の単なる列挙では、網羅できているかを判断できない 各社のドキュメントは、自分の製品が対象 ソフトウェア開発全体 クラウド （AWS） AIエージェント （Claude） ドキュメントあり ドキュメントあり その他のサービス （コード管理リポジトリ、 外部 API） 列挙型の資料では、網羅できているか分からない 列挙型の資料 （例：OWASP Top 10） 1. リスクと対策 2. リスクと対策 3. リスクと対策 … 10. リスクと対策 項目をすべて実施しても ・十分な対策になって いるのか分からない ・事故の可能性が残って いないと説明できない 組み合わせた全体のことは書かれていない → 自分の製品の外側は対象にならず、開発全体では網羅できない → 項目をすべて実施しても、網羅できていることを説明できない 

列挙型の課題：対策の一覧だけでは、抜けているものが見えない 原因（始点） 対策（一覧だけ） 被害（終点） 認証情報ファイルを読ませない ？ メタデータを読ませない 許可外の宛先へ通信させない 書かれていない ？ 書かれていない 実施した対策 質問：このように対策だけを示されたとき、十分かどうかを判断できる方は？（挙手） 

体系的な解決策の方針：原因と被害を明らかにし、経路ごとに対策を講じる 原因（始点） 前提：なくせない AI の意図しない動作 対策（成立条件の木に対応づける） 認証情報ファイルを読ませない 環境変数を読ませない 内部の入力（開発者の指示） メタデータを読ませない エラー時の挙動 許可外の宛先へ通信させない 指示の解釈違い・ミス 外部の入力（ファイル・Web） プロンプト インジェクション データポイズニング 他者のアカウント・ リソースへ通信させない AND 到達させない 資産 × 被害の組の1つ OR AND 送り出させない どちらの側にも抜け（赤）があり、被害を防げていない ほかの資産 × 被害の組も、1つずつ同じように木で分解する 実施した対策 前提 被害（終点） 実施していない対策（抜け） 手順2 FTA で、被害が成立する条件を木に分解する 手順3 同じ木を裏返し、条件ごとに対策を実施する どちらかで 防ぐ 認証情報が 漏洩・窃取される ファイルが漏洩・窃取される 生成物が改ざんされる 悪意のある成果物が作られる リソースが枯渇・停止する 操作を追跡できなくなる …（資産の数 × 5分類） 手順1 NIST CSF・CIA 資産と被害を挙げる 

体系的な整理1：NIST CSF の資産管理で、守る対象（資産）と守り方を挙げる NIST CSF（NIST Cybersecurity Framework）：米国国立標準技術研究所（NIST）が公開している、サイバーセキュリティ対策の 枠組み（現行版は 2.0、2024年2月） NIST CSF の6つの機能 ガバナンス（GV） 特定（ID） 防御（PR） 検知（DE） 対応（RS） 復旧（RC） 特定（ID）の資産管理（ID.AM） 特定された資産（防御対象） ID.AM-01 ハードウェア ID.AM-02 ソフトウェア・サービス ID.AM-03 通信・データフロー ID.AM-04 サプライヤのサービス ID.AM-05 資産の重要度づけ ID.AM-07 データ ID.AM-08 ライフサイクル管理 ・ハードウェア（CPU・GPU・メモリ、周辺機器） ・ファイル（コード・作業ファイル） ・認証情報・環境変数 ・ホストの OS・プロセス・設定 ・外部ネットワーク（通信・接続先） ・作業対象外の別の環境（他リポジトリ・本番） ・依存パッケージ・取得物 ・生成物（AI が書いたコード） ・ログ フレームワークに沿って資産を特定できる 

体系的な整理2：CIA をもとに、起きうる被害を5つに分ける CIA：情報セキュリティの3要素、機密性（Confidentiality）・完全性（Integrity）・可用性（Availability）の頭文字 CIA（機密性・完全性・可用性）に追跡可能性を加え、被害を5つに分ける 機密性 完全性 可用性 追跡可能性 漏洩・窃取 破壊・改ざん 悪意のある成果物 枯渇・停止 追跡不能 見せてはいけない情報が 外部に出る 既存のファイルや環境が、 意図せず変えられる AI が作るものに、 危険なものが混ざる 資源を使い切り、 使えなくなる 誰が何をしたかを、 あとから追えない 例 例 例 例 例 認証情報・顧客データ・ ソースコードの流出 守ること 組織の情報を、 組織の内側に閉じる （組織の外に出さない） 本番 DB の削除、 設定の書き換え 脆弱なコード、 バックドアの混入 API 利用料の急増、 上限到達での停止 ログの欠落・消去で、 原因を調べられない 組織の内側でも、許可した操作だけを行わせる 許可した操作でも、 使う量を上限内に収める すべての操作で、 誰が行ったかを記録する （許可していない操作はさせない） 既存の資産を保つ （変えさせない） 意図した成果物だけを作る （上限を超えて使わせない） （行った人を不明にしない） （危険なものを作らせない） 

体系的な整理3：資産と被害を組み合わせ、整理する組を洗い出す スライド16の資産 × スライド17の被害。方針の図の右側、終点を埋める 特定された資産 × 起きうる被害 特定された資産 ハードウェア ファイル 認証情報・環境変数 ホストの OS・設定 外部ネットワーク 作業対象外の環境 依存パッケージ 機密性 完全性 — — 漏洩・窃取 破壊・改ざん 認証情報・顧客データ ファイル・本番環境の コードの外部流出 削除／書き換え PR.AA-05／PR.DS-01 PR.AA-05／PR.PS-01 PR.DS-10 PR.DS-11 PR.AA-01／PR.AA-04 PR.AA-01／PR.AA-05 PR.DS-01／PR.DS-10 PR.PS-01 — PR.AA-05／PR.PS-01 PR.AA-02／PR.AA-03 PR.DS-02／PR.PS-01 PR.DS-02／PR.IR-01 PR.AA-01／PR.AA-05 PR.AA-05／PR.PS-01 PR.PS-01／PR.IR-01 PR.IR-01 — 生成物 PR.PS-06 ログ PR.DS-01／PR.DS-10 — — — 完全性 悪意のある成果物 脆弱なコード・ バックドアの混入 — — — — — — PR.PS-02／PR.PS-05 PR.PS-06／PR.PS-05 PR.PS-02 — 可用性 枯渇・停止 コスト爆発・ API クォータ枯渇 PR.IR-04 — — — PR.IR-04 PR.IR-04 — — — 追跡可能性 追跡不能 誰が何をしたか追えず 原因究明ができない — — — — — — — — PR.PS-04 

体系的な整理4：FTA で被害の成立条件を分解する FTA（Fault Tree Analysis、故障の木解析）：望ましくない事象を頂点に置き、成立条件を AND・OR で木の形に分解する手法。方 針の図の間、経路を埋める スライド18の表の1マス 認証情報が漏洩・窃取される 認証情報 × 機密性 認証情報 ファイルを読む AND AI が認証情報に到達できる AI が外部へ送り出せる OR OR 環境変数を 読む クラウドの メタデータを読む 許可していない 宛先への通信 許可した宛先の、 他者のアカウント・リソースへの通信 AND：両方が成立して初めて被害が成立する ／ OR：いずれか1つの手段で成立する 

体系的な整理5：成立条件を裏返して、セキュリティ要件にする 要件を満たす対策がない枝が、抜けとして見える 認証情報が漏洩・窃取されない OR AI が認証情報に到達できない AI が外部へ送り出せない AND AND 認証情報 ファイルを読めない 環境変数を 読めない クラウドの メタデータを読めない 許可していない宛先へ 通信できない 許可した宛先でも、他者の アカウント・リソースへ通信できない OR：どちらか一方の枝をすべて満たせば被害は成立しない ／ AND：その枝はすべて満たす必要がある 

中間層による対策の1つ：AI の外の中間層が、組織の認証情報を付けて通信する スライド09 の経路への答え。スライド20 の「許可した宛先でも、他者のアカウント・リソースへ通信できない」にあたる 開発環境（PC・コンテナ） AI エージェント ① 攻撃者のキー に書き換えても AWS（*.amazonaws.com） ② 組織の 権限で届く MCP のツールで依頼 中間層 組織の認証情報で AWS を操作する 環境変数 組織の認証情報は 置かない × ③ 権限は自アカウントの リソースだけ 組織のアカウント S3 バケットなど 他者のアカウント S3 バケットなど × AWS CLI などでの直接の通信は許可しない 使える機能の例 AWS：AWS MCP Server AWS CLI の代わりに、AWS が運用する MCP サーバーを使う 接続時に設定した認証情報だけで操作する（AI は指定できない） トークン認証の API：Network secrets AI の外のプロキシが、登録したキーをヘッダーに付ける AI が付けた値は上書きされる 

まとめ：守る対象と被害を挙げ、成立条件に分解すると、体系立てて整理できる 手順1 守る対象と、そこに起きうる被害を挙げる 手順2 その被害が成立する条件に分解する 手順3 条件を裏返して、必要なセキュリティ要件にする NIST CSF・CIA FTA 裏返した FTA 

問いかけ：最初と同じ質問。防ぎ方と、抜けの判断を始められそうですか 会場のみなさんへの質問（挙手） 最初と同じ質問です ① この経路の防ぎ方を、説明できそうな方 ② 開発環境の対策に抜けがないか、判断を始められそうな方 

実際の利用例：本発表の整理の進め方を、企業様向けの支援で利用している 本発表の整理の進め方 資産・被害を挙げ、成立条件の木に分解して対策を講じる 利用ガイドライン 試験制度 開発時のガイドライン テンプレートリポジトリ AI エージェント利用の ガイドラインと チェックシートの作成 AI エージェントを 使う人の試験制度の 導入 AI 駆動開発で 守ることをまとめた ガイドラインの整備 対策を組み込んだ 開発用テンプレート リポジトリの整備 複数の企業様向けに、同じ整理の進め方で支援している 

補足：到達も送り出しも、実際にはさらに細かい手段に分かれる スライド19の木の葉を、手段ごとに分けたもの 認証情報が漏洩・窃取される AND AI が認証情報に到達できる AI が外部へ送り出せる OR OR 認証情報ファイルを読む 環境変数を読む 実行中のプロセスのメモリから読み出す クラウドのメタデータ（IMDS）から取得する 作業と関係のないファイルに書かれた トークンを見つける（実例2） 許可していない宛先への通信 許可していない宛先へ直接送る 子プロセス・連携ツールを通して送る 許可した宛先の、他者のアカウント・リソースへの通信 攻撃者の認証情報に差し替えて送る（スライド09） 他者が見られる場所へ書き込む（実例1） AI が送らず、外から読める状態にする 公開範囲・アクセス権を広げる 出力に外部の URL を埋め込み、閲覧時に取得させる 転送・複製の設定を変え、継続的に送らせる AND：両方が成立して初めて被害が成立する ／ OR：いずれか1つで成立する 

補足：表のほかのマスにも、それぞれの木がある スライド19・25 は表の1マス分。ほかのマスも同じ手順で木に分解する 資産 × 被害の表（スライド18） ハードウェア 漏洩・ 窃取 破壊・ 悪意のある 枯渇・ 改ざん 成果物 停止 追跡 不能 ファイル × 破壊・改ざん（実例2） 本番のデータが削除される AND ファイル AI が削除の操作を実行できる 認証情報・環境変数 削除できる権限がある 外部ネットワーク × 枯渇・停止 ホストの OS・設定 API の利用料が急増する 外部ネットワーク AND 作業対象外の環境 AI が API を繰り返し呼べる 依存パッケージ 利用量の上限がない 依存パッケージ × 悪意のある成果物 生成物 悪意のあるパッケージが入る ログ スライド19・25 で分解した1マス ほかのマスの木の例（頂点と1段目だけ） AND マスごとに、同じ手順で木を作る AI が依存を追加できる 追加前の確認がない 

対策の3つの観点：多層防御は、網羅性・冗長性・強靱性の3つで組み立てる ここまでの木による整理は網羅性にあたる。冗長性と強靱性も合わせて見る 多層防御（Defense in Depth）＝ 3つの観点の組み合わせ 網羅性 coverage 冗長性 redundancy 強靱性 resilience 対策に 抜けがないか 対策が1つ崩れても、 他の対策で補完できるか 被害から 立ち直れるか 守る対象と被害ごとに、 経路ごとに対策を講じる 設定ミスや未知の問題が 1つ起きても、他で補う 被害が出ても、機能を 維持・回復できる NIST CSF の機能 ID 特定 PR 防御 NIST CSF の機能 PR 防御 DE 検知 RS 対応 NIST CSF の機能 RS 対応 RC 復旧 事前の対策 事前・事後の両方の対策 事後の対策 この発表では スライド15〜20 の木で、 対策のない条件を見つける この発表では OR の両方の枝で防御し、 防げなくても検知・対応で止める この発表では 実例2：バックアップが同じ場所に あり、削除で一緒に消えた 

利用者のリテラシー：使う人に求めることを、段階で整理する 今回の発表は、主に L2（使う前に、設定が十分かを判断する）に関わる話 ツールに依存しない段階 個別ツール（Claude Code など） エージェントを使っているときに、次の対応を判断できる L3 AIデータの投入、コマンドの承認、外部情報の取り込み、生成物の反映、異常時の対応 エージェントを使う前に、 L2 AI権限・接続先・自動実行の範囲の設定が十分かを判断できる L1 AI エージェント特有のリスクを知っている L0 情報セキュリティの基礎を身につけている 今回の発表 の判断を、 L3' L3ツールの操作で実行できる の判断を、 L2' L2ツールの設定で実行できる ツールが変わっても、 左の L1〜L3 は作り直さない 

成果物への適用：同じ手順で、AI で作る成果物のセキュリティも整理できる 開発環境 原因（始点） 対策（成立条件の木に対応づける） AI の意図しない動作 内部の入力 開発者の指示 外部の入力 読み込むファイル・Web ページ FTA 開発者の PC リポジトリ・認証情報 × 5分類の被害 FTA 利用者のデータ アプリの DB・API キー × 5分類の被害 手順1〜3 は同じ 守る対象（資産）が変わる 成果物（AI を組み込んだアプリなど） AI の意図しない動作 内部の入力 アプリ開発者が書いた指示・設定 外部の入力 利用者の入力・アプリが読み込むデータ 入力の中身が変わる （成果物では、利用者の入力が外部の入力） 被害（終点） 被害の5分類と、対策の観点も同じ 

補足資料 

承認の限界：承認は事故の確率を下げるが、ゼロにはしない 人による承認は手間と承認疲れ、Auto モードは見逃しが弱点で、どちらを許容するかで選ぶ 人による承認 AI が出す操作 Auto モード AI が出す操作 人が見て承認する すり抜け 実行される 承認の回数が増えると、内容を確認せずに通すようになる（承認疲れ） 長いスクリプトや複合コマンドは、見ても判定できないことがある 判定役の AI が判定する すり抜け 見逃し率：実環境のデータで 17%、合成データの外部送信で 5.7% Anthropic は安全性を保証しないと明記している どちらも事故の確率は下げるが、ゼロにはならない 実行される 

承認の位置づけ：承認は木の中の対策の1つとし、見逃しても別の対策で止める 例：実例2（本番の DB の削除）を、対策の木で見る 承認で止める （人による承認 / Auto モード） 削除の操作を 実行させない 見逃しがある（確率はゼロにならない） トークンの権限を 最小にする OR 削除できる権限を 持たせない 承認は木の中の対策の1つ。見逃しても、別の枝（権限）で止まるようにしておく 承認を求めるのは取り消せない操作に絞り、人が見る回数を減らす（承認疲れを防ぐ） 本番の DB が 削除されない どちらかで止まれば 被害は起きない 

注意事項 発表者の立場：セキュリティの専門家ではなく、内容に誤りが含まれる可能性がある 発表の位置づけ：クラスメソッド社内で実施しているセキュリティ対策を紹介するものではない 情報システム部門・セキュリティ担当の意見は得ているが、完全なレビューを受けたものではない 発表者が把握している情報を、自分なりに整理したもの 出典の扱い：外部サイトへのリンクは、リンク先の内容の正しさまでは確認できていない 補足資料には AI に書かせた部分も多い 

前提：モデルは確率的に脆弱であり、AIに任せる量が増えるほど問題が起きやすくなる 定義：モデルは確率的に脆弱である。同じ入力でも挙動が一定せず、処理対象のデータ（外部からの入力）によって挙動を操作されう る。これを完全に防ぐ手段はない 意図しない挙動の要因を4つ挙げる プロンプトインジェクション（読み込んだデータに紛れ込ませた指示で、AIの挙動を操作する攻撃） データポイズニング（学習データや読み込むデータに、悪意のあるデータを混入させる攻撃） エラーや例外が発生したときに、挙動がおかしくなりやすい（プロンプトで指示していないケース） そもそも LLM は原理的に、確率的にミスしうる 今後：現状、事故が起きていないのは、モデルが賢く危険な操作を避けているためにすぎない。任せるタスクの範囲・与える権限・同時 に動かす数は今後も拡大していき、実行回数が増えるため、1回あたりの発生確率が低くても、事故が起きる確率は積み上がる 対策への影響：従来の対策は、操作するのが人間で、大きな誤りを犯しにくいことを前提にしている。操作するAIは確率的にミスし、攻 撃で操作されうるため、人間を前提にした対策だけでは守れない 

課題：既存の情報では、ソフトウェア開発全体における対策を網羅できていない 方針：モデルの誤りは防げないため、開発環境の側で対策を打つ 既存の情報：各社のセキュリティドキュメント（AWS・Claude など）と、列挙型の資料（OWASP Top 10 など）がある 課題（2つの問題を1行ずつ書き、下の図2枚と対応させる） 各社のドキュメントは、自分の製品が対象で、ソフトウェア開発の全体について書かれていない 列挙型の資料では、項目をすべて実施しても、網羅的な対策ができているのか判断できない → ソフトウェア開発全体における対策を網羅できていない （網羅した整理は、調べた範囲では見当たらなかった） 本発表で示すもの：対策を体系的に整理する方法（どの観点が抜けているかを判定できるようにする） 

体系的な整理2：NIST CSF の資産管理に沿って、守る対象（=資産）と守り方を洗い出す 概要：NIST CSF ＝ NIST Cybersecurity Framework 米国 NIST（National Institute of Standards and Technology、国立標準技術研究所）が公開 サイバーセキュリティ対策を整理するための枠組み 6つの機能に分かれる（各機能の内容は補足資料） 構造：機能 → カテゴリ → サブカテゴリの3階層 サブカテゴリは達成すべき成果で書かれ、実装方法は規定しない 特定（ID）に資産、防御（PR）に守り方のサブカテゴリが並ぶ 使い方 特定（ID）の資産管理（ID.AM）のサブカテゴリに沿って、守る対象を挙げる 挙げた資産ごとに、防御（PR）のサブカテゴリで守り方を考える 以降の機能（検知・対応・復旧）も、同様にフレームワークに従って考える 

体系的な整理3：CIA をもとに起きうる被害を5つに分け、資産と組み合わせる 概要：CIA ＝ Confidentiality（機密性）・Integrity（完全性）・Availability（可用性）の頭文字 情報セキュリティで守るべき性質を表す3分類 AI駆動開発への適用：AI駆動開発に合わせて、以下の点を変更 完全性を「破壊・改ざん（既存の生成物に対する変更）」と「悪意のある成果物（新規の生成物）」に分ける 追跡不能を追加（CIA にない項目を追加） 使い方 特定（ID）で特定した資産に対して、それぞれの被害が該当するか確認する 該当する場合は、防御（PR）をもとに守り方を考える 実例との対応：実例1は漏洩・窃取、実例2は枯渇・停止にあたる 

体系的な整理4：FTA で被害の成立条件を分解する 概要：FTA ＝ Fault Tree Analysis（故障の木解析） 防ぎたい事象を頂点に置き、成立条件を AND と OR で下へ分解する手法 航空・原子力の安全性解析で使われてきた 使い方 資産 × 被害の表から、防ぎたい組を1つ選び、頂点に置く その被害が成立する条件を、AND と OR で下へ分解する 例：認証情報 × 漏洩・窃取（実例1にあたるセル）。頂点は「認証情報が漏洩・窃取される」 

体系的な整理5：成立条件を裏返して、セキュリティ要件にする 使い方 各要素を否定文に書き換え、AND と OR を入れ替える 裏返した形が、そのまま必要なセキュリティ要件になる 要件が置かれていない枝が図の上で見えるため、観点の抜けを判定できる 補足 OR なので、どちらか一方の枝をすべて満たせば被害は成立しない ただし、抜けが存在する可能性がある すべての攻撃を網羅できていない可能性 新規の攻撃手法が生まれる可能性 複数の枝で防御できていれば、片方が破られても止まる（多層防御の考え方） どこまで満たすかは、コストと安全性のトレードオフで決める 

実際の利用例：本発表の整理の進め方を、企業様向けの支援で利用している ご支援1：AIエージェント利用ガイドラインとチェックシートの作成 大手企業様のセキュリティ部門向け。特定のツールに依らない形で作る 利用者や用途に応じて、任せる範囲を段階的に決める仕組みの検討も含む ご支援2：AIエージェント利用の試験制度の導入 試験の制度設計・作問・教材の作成 支援での使い方 ご支援1：資産の洗い出し → 被害の整理 → 対策の割り当て → 文書化の順にたどり、 ご支援2：前段となるガイドラインのチェックに利用し、修正事項を提案した 

補足資料について（目次） 本編で扱わなかった内容と、本編で使った枠組み・用語の基礎解説を収録している 1. 枠組み・用語の基礎：1-1 NIST CSF 2.0 の基礎 ／ 1-2 CIA（情報セキュリティの3要素）の基礎 ／ 1-3 被害の軸と STRIDE の対応 ／ 1-4 FTA の基礎 ／ 1-5 プロンプトインジェクションの基礎 ／ 1-6 本編・補足で使ったその他の用語 ／ 1-7 防御（PR）サブカテゴリの一覧 2. 対策の考え方：2-1 対策の3つの観点 ／ 2-2 3つの観点は、どれが欠けても被害につながる ／ 2-3 3つの観点と NIST CSF の6機能の対応 ／ 2-4 多層防御と層の独立性 ／ 2-5 単独では不十分な対策の例 ／ 2-6 対策の観点ごとの具体的な例 3. 本編で触れた内容の詳細：3-1 確率的な脆弱性の詳細 ／ 3-2 認証情報の書き換えによる別アカウントへの到達 ／ 3-3 AIに任せる作業範 囲の4段階と参考資料 4. 参照フレームワークの位置づけ：4-1 本発表で実際に使ったフレームワーク ／ 4-2 位置づけの説明にとどめ、具体的には使わなかった フレームワーク ／ 4-3 列挙型を網羅の根拠にしない理由 ／ 4-4 NIST AI RMF との違い ／ 4-5 OWASP の2つの文書の違い 

1-1. NIST CSF 2.0 の基礎 特定（ID） 守るべき資産・ リスクの洗い出し ガバナンス（GV）：戦略・ポリシー・役割の確立 防御（PR） 検知（DE） 対応（RS） 復旧（RC） 保護策の実施 回復と再発防止 攻撃・異常の発見 被害を抑える対処 

1-2. CIA（情報セキュリティの3要素）の基礎 情報セキュリティで守るべき性質を表す、最も基本的な3分類。ISO/IEC 27000 シリーズなどで定義される 機密性（Confidentiality）：許可された人だけが情報にアクセスできること。破れると「漏洩」 完全性（Integrity）：情報や設定が正確で、意図せず改ざん・破壊されていないこと。破れると「不正な変更・削除」 可用性（Availability）：必要なときに使えること。破れると「停止・枯渇」 本発表では、防ぎたい被害を漏れなく挙げるための分類として使った 

1-3. 被害の軸と STRIDE の対応 本発表の被害の軸（CIA＋追跡可能性）は、脅威分類として広く 使われる STRIDE と突き合わせて点検できる STRIDE の6項目のうち4つは、損なわれるものがこの軸の被害と 重なる 残る2つ（なりすまし・権限昇格）は、本発表の整理では被害そ のものではなく、被害に至る経路として扱う STRIDE（脅威の面） Information Disclosure（漏洩） Tampering（改ざん） Denial of Service（サービス妨害） Repudiation（否認） Spoofing（なりすまし） Elevation of Privilege（権限昇格） 対応する被害（CIA＋追跡可能性） 機密性 完全性 可用性 追跡可能性 被害ではなく、被害に至る経路 被害ではなく、被害に至る経路 

1-4. FTA（Fault Tree Analysis、故障の木解析）の基礎 望ましくない事象の成立条件を分解する解析手法。もともとは信頼性工学の分野で、航空・原子力などの安全性解析に使われてきた 防ぎたい事象（頂上事象）を木の頂点に置き、その成立条件を AND（すべて成立したときに発生）と OR（いずれか1つで発生）で下へ 分解していく AND の下の条件は、どれか1つを断てば頂上事象を防げる。OR の下の条件は、すべてを断たないと防げない。この違いが図の形で見え る 本発表では、セキュリティ被害を頂上事象に置いて、対策の割り当て先を洗い出すために使った 

1-5. プロンプトインジェクションの基礎 AI への入力データに指示を紛れ込ませ、開発者の意図と異なる動作をさせる攻撃 直接型：利用者が入力欄に細工した指示を打ち込む 間接型：AI が読み込むドキュメント・Web ページ・コードコメントなどに指示を仕込む。AI エージェントは外部のデータを大量に読み 込むため、間接型の影響を受けやすい モデルは「処理対象のデータ」と「従うべき指示」を完全には区別できないため、この攻撃を確実に防ぐ手段はない（本編の前提の根 拠） 

1-6. 本編・補足で使ったその他の用語 用語 最小権限 IAM Egress 制御 シークレット管理 レート制限 意味 作業に必要な最小限の権限だけを与える原則 クラウドの利用者と権限を管理する仕組み（Identity and Access Management） 内側から外側への通信を制限すること 認証情報を専用の保管庫で管理し、コードや環境変数に直接置かないこと 一定時間あたりの実行回数に上限を設けること 

1-7. 防御（PR）サブカテゴリの一覧 PR.AA アイデンティティ管理・認証・アクセス制御 PR.PS プラットフォームセキュリティ PR.DS データセキュリティ PR.IR 技術インフラのレジリエンス PR.AA-01 PR.AA-02 PR.AA-03 PR.AA-04 PR.AA-05 PR.DS-01 PR.DS-02 PR.DS-10 PR.DS-11 ID・認証情報の管理 ID の証明・バインド 認証 ID アサーションの保護 最小権限・職務分離 保存データの保護 通信データの保護 使用中データの保護 バックアップ PR.PS-01 PR.PS-02 PR.PS-04 PR.PS-05 PR.PS-06 PR.IR-01 PR.IR-04 構成管理 ソフトの保守・削除 ログの生成 不正ソフトの実行防止 セキュアな開発 不正アクセス・利用からの保護 リソース容量の維持 

2-1. 対策の3つの観点 多層防御（Defense in Depth）：どの対策にも限界（仕様の抜 け・設定ミス・運用での誤り）があり、単独では防げないケース が残る。一つの対策に頼らず、複数を組み合わせて守る 本来は層を重ねて防御線を増やす発想だが、実務では対策の組み 合わせ方全般を指して使われ、何を指すかが統一されていない 本発表では、対策の組み合わせ方を3つの観点で評価する。いず れも「対策をどう組み合わせれば、攻撃から守れる・被害を抑え る構造になるか」を判断するためのもの 網羅性 （coverage） 冗長性 （redundancy） 強靱性 （resilience） 守る対象・観点ごとに 対策を配置する 一つが回避されても 別の対策が止める 被害が出ても機能を 維持・回復できる 抜けがないか 単一障害点がないか 被害から立ち直れるか 

2-2. 3つの観点は、どれが欠けても被害につながる 3つは別の働きをする。いずれかが満たされていても、他の不足は被害につながる 網羅性の不足：一つ一つの対策の質が高くても、観点が抜けていれば、その被害経路が無防備に残り、被害が生じる 冗長性の不足：観点を埋めても、重要な箇所が一つの対策だけでしか守られていない場合、その対策が回避されたときに被害を止められ ない 強靱性の不足：これらをすり抜けて被害が起きたとき、機能の維持・回復の備えがなければ、被害が長期化・拡大する 

2-3. 3つの観点と NIST CSF の6機能の対応 5機能（特定・防御・検知・対応・復旧）は、被害発生との時間関係で並ぶ。統治（GV）は組織のリスク管理戦略を扱う横断的な機能 で、この時系列とは別の枠組み 網羅性は、特定で守るべきものを漏れなく挙げ、防御で漏れなく対策を配置することで実現する 冗長性は、防御の中で重要な箇所に対策を重ね、対策を抜けられても検知で気づける層を足すことで実現する 強靱性は、対応・復旧が担う。被害発生後に抑え込み、迅速に元へ戻すことで実現する 機能 特定 Identify（ID） 防御 Protect（PR） 検知 Detect（DE） 対応 Respond（RS） 復旧 Recover（RC） 統治 Govern（GV） 被害との時間関係 発生前（守るものを把握） 発生前（攻撃を未然に止める） 発生時（防げなかった攻撃に気づく） 発生後（被害を抑える） 発生後（機能を取り戻す） 横断的（リスク管理戦略） 担当する観点 網羅性（前提） 網羅性 ＋ 冗長性 冗長性（補強） 強靱性 強靱性 —（全体） 

2-4. 多層防御と層の独立性 単一の対策に依存せず、独立した複数の層で守る。どの対策もいずれ破られる前提で、破られても別の層で止める 独立の意味：同じ前提や仕組みに依存していないこと 独立な例：IAM ポリシー（クラウドの権限設定。権限で判定）と外向き通信の制御（宛先で判定）。判定の仕組みが別 独立でない例：人間による承認と AI による事前チェック。どちらも判断主体の精度に依存する 

2-5. 単独では不十分な対策の例（元記事6章の要約） 人間がすべてを承認する：規模が拡大すると承認が追いつかず、承認疲れで判断が劣化する AIにコマンドの安全性をチェックさせる：チェック側のモデルも確率的に脆弱で、すり抜けが残る ブラックリスト（禁止する操作を列挙する方式）：列挙していない迂回路が残る ホワイトリスト（許可する操作だけを列挙する方式）：厳格にすると柔軟性を失い、緩めると組み合わせで抜けられる ドメイン制限：許可したドメインの中での、別アカウントへの漏洩は止まらない 操作の種類・権限だけを絞る：量・回数の暴走は止まらない 

2-6. 対策の観点ごとの具体的な例 観点 AI が到達できる範囲を絞る AI が送り出せる先を絞る AI ができる操作・権限を絞る AI が実行できる回数・量を絞る 対策の例 シークレット管理による認証情報の隔離、読み取りスコープの限定 外向き通信の制御（Egress 制御）、書き込み先の限定 最小権限、不可逆な操作だけ個別承認 実行回数・使用量の上限（レート制限）、連続実行の検知 

3-1. 確率的な脆弱性の詳細 temperature=0 でも出力は決定論的にならない（元記事の補足を参照） プロンプトインジェクション・データポイズニングの実例は元記事の参考文献を参照 1回あたりの発生確率が低くても、試行回数が増えれば全体の発生確率は積み上がる 

3-2. 認証情報の書き換えによる別アカウントへの到達 環境変数やプロファイルを差し替えられると、権限を絞っていても、正規の権限のまま別アカウントのリソースに到達する経路が成立す る クラウド側・AIエージェント側それぞれの対策では見えず、両者の間の設定で塞ぐ必要がある例 

3-3. AIに任せる作業範囲の4段階と参考資料 4段階：読み取り専用に限定する ／ 人間が全操作を承認する ／ 人間が目標を決めて AI が動き、要所で承認する ／ すべてを AI に任せる 4段階は AWS の Agentic AI Security Scoping Matrix の4つのスコープ（No / Prescribed / Supervised / Full Agency）を、平易な日本語に 言い換えたもの 本発表が前提にするのは3段階目 参考資料：元記事、NIST Cybersecurity Framework、前回セミナー（セキュリティ/ガバナンス編）のベース記事 

4-1. 本発表で実際に使ったフレームワーク 本発表での役割 フレームワーク 任せる範囲（自律性レベル）を決める AWS Agentic AI Security Scoping Matrix 上位の文脈（AI の信頼性7特性のうち Secure & Resilient）に位置づける NIST AI RMF 1.0 観点を網羅する（主参照、網羅型） NIST CSF 2.0 守る場所（モデルの外側の3層）を切り分ける Anthropic Shared Responsibility Model 

4-2. 位置づけの説明にとどめ、具体的には使わなかったフレームワーク 言及する理由 フレームワーク 列挙型として位置づけたが、本発表では 具体例の引用までは行わない （次回以降の各論で具体例として参照する想定） OWASP（Agentic / LLM） MITRE ATLAS / ATT&CK、 CIS Controls 第2弾以降の各論で参照する予定 NIST SSDF、SLSA、ISO/IEC 27001、 AWS Well-Architected AI プロダクト・組織のリスク管理が主眼で、 本発表のスコープ（開発環境のセキュリティ）と 視点が異なる NIST AI 600-1、 ISO/IEC 42001・23894 業界動向・採用成熟度・規制を俯瞰するレポート 脅威の列挙ではなく、独自の枠組みの整理が中心 （次回以降の各論で参照する想定） OWASP Gen AI Security Project: State of Agentic AI Security and Governance 

4-3. 列挙型を網羅の根拠にしない理由 OWASP Top 10 のような列挙型は、現場で観測された代表的なリスクをボトムアップに集めたもの。本発表では網羅の根拠には使わず、 具体的な攻撃例の参照にとどめた 守るべき要件から体系的に項目を分解した結果ではないため、上位概念からみてどこまでをカバーしているかを判定できない（漏れのな い分類を意図したものではない） OWASP Top 10 自身が、自らを啓発のための文書と位置づけている 原文：The OWASP Top 10 for Large Language Model Applications is a standard awareness document for developers and web application security. 訳：OWASP Top 10 for LLM Applications は、開発者および Web アプリケーションセキュリティのための標準的な啓発文書です 出典：OWASP Top 10 for Large Language Model Applications 一方、個別リスクの実例（プロンプトインジェクション、サプライチェーンの侵害）を具体例として参照する用途には適する 

4-4. NIST AI RMF との違い NIST AI RMF や NIST AI 600-1 は、AIプロダクトのリスク管理（モデルの偏り、データ品質、説明可能性、有害コンテンツ）が主眼 本発表が対象とする「AIを使う側（開発環境）のセキュリティ」とは対象が異なる 本発表は、AI RMF が挙げる信頼性の特性のうち Secure & Resilient を、開発環境で技術的に具体化する位置づけになる 

4-5. OWASP の2つの文書の違い OWASP Gen AI Security Project（旧 OWASP GenAI）は複数の文書を出しており、目的が分かれている Top 10 for LLM / Agentic Applications：現場で観測された代表的なリスクを列挙する啓発文書。脅威の具体例を引く用途に向く State of Agentic AI Security and Governance（v2.01, 2026年6月）：業界動向・採用成熟度・規制・実インシデントを俯瞰するランドス ケープレポート。独自の枠組み（Adoption Maturity Model、Agent Identity、AI SBOM、Runtime Governance 等）の整理が中心 どちらも網羅の根拠としては使わない。Top 10 は「列挙型の代表例」として位置づけ、State of … は本発表のスコープ（特定と防御の全 体像）から外し、次回以降の各論で参照する想定