セキュリティ・キャンプ2026コネクト（AIレッドチーミング）参加記

2026年3月26日〜29日に開催された セキュリティ・キャンプ2026コネクト の AIレッドチーミングクラス に参加しました。
本記事では、修了後の振り返りとして、プログラムの姿勢と学びを整理します。

開催概要（公式情報の要約）

AIレッドチーミングクラスは、LLMやマルチLLMエージェントシステム（MAS）など、急速に進化するAI技術に内在するセキュリティ課題を 座学と演習の両面から体系的に学ぶことを目的としたクラスです。プロンプトインジェクションをはじめとするLLM特有の脅威に加え、AIエージェント間通信や外部ツール偽装など、MASで顕在化するリスクも扱い、攻撃と防御の両面から安全なAIシステム設計の原則を学びます。

• 期間: 2026年3月26日（木）〜29日（日）
• 定員: 5名程度
• 会場: マイステイズ新浦安コンファレンスセンター（千葉県浦安市）
• 公式ページ: IPAの案内 / セキュリティ・キャンプ協議会

当日の雰囲気（少人数ならではの密度）

公式の定員が5名程度と案内されている一方で、当日は8人で同じテーマに取り組む時間がありました（進行上の都合も含め、同席して学ぶ場面がありました）。少人数だった分、講義を「聞いて終わり」にせず、その場で疑問を投げたり、受講生同士で前提を擦り合わせたりと、議論の密度が高かったのが印象的です。

参加者もバックグラウンドが幅広く、AIに強い人、実装に強い人、脅威の捉え方が鋭い人など、それぞれの“キャラの濃さ”が良い方向に働いていました。学生の自分としては、知識の穴を突かれて恥ずかしい場面もありつつ、そこで整理し直せたことが結果的に大きな学びになりました。

コネクトの趣旨（自分なりの理解）

セキュリティ・キャンプコネクトが掲げる「セキュリティ以外の分野と橋渡しし、多面的に検討できる視点を育てる」という姿勢は、生成AIが実装・運用の両面で急速に社会に入り込む現状において、まさに必要だと感じました。
私は本クラスを通じて、LLM単体の脆弱性にとどまらず、ツール連携やマルチエージェントが加わるほど、攻撃の入り込み方と影響範囲が変わるという事実を、座学と演習の両方で追体験できたことが大きな収穫でした。

学び（AIレッドチーミングクラス）

学びは、OWASPの文脈に沿って「LLMを組み込んだアプリ」に焦点を当てるところから始まりました。プロンプトインジェクションや間接注入、データベース連携を狙う攻撃、さらに実行系へつながるリスクまでを、意図的に脆弱性を含む連携アプリ上で確認し、ブラックリストやプロンプトハードナー、ガードレール、判断モデルの利用といった防御が、どの悪用に効き、どこに限界があるのかを比較できました。

入力と出力のどちらで止めるか、学習やチューニングに依存する対策のコストとすり抜けをどう見積もるかといったトレードオフを、サービス提供者の立場で言語化する感覚が身についたと思います。

1) 「LLM単体」ではなく「LLMを組み込んだアプリ」を見る

個人的に一番大きかったのは、LLMの挙動を“モデルの性質”だけで片付けず、**アプリケーションとしての境界（入力・出力・データ・実行権限）**に落として考える習慣がついたことです。

• 入力側で止めるのか / 出力側で止めるのか: どこにガードを置くと、運用上の責務分担がしやすいか
• 対策の依存先: 学習・チューニングに依存する対策は、効果の揺らぎや検証コストが増える（その見積もりが必要）
• 検知と遮断の設計: 誤検知・取りこぼしの許容度をどこに置くか（ユーザー体験や業務影響とセットで考える）

学生としてはまだ経験が浅い分、ここを一段抽象化して「運用に落ちる形で説明できるか」を意識させられたのが、今後の糧になりました。

1-補足) 防御を「比較」する視点（どの攻撃に効き、どこが弱いか）

演習では、ブラックリストやガードレール、プロンプトハードナー、判断モデルの利用など、複数の防御を“同じ土俵”で見比べる機会がありました。ここで学べたのは「強い対策を1つ入れれば終わり」ではなく、想定する悪用（脅威）に対して、効果と限界をセットで書けることの重要性です。

• 入力側の対策は、早い段階で止められる反面、回避の余地や誤検知の設計が難しい
• 出力側の対策は、情報漏えいなどの“結果”に焦点を当てやすい一方で、内部で起きた不正を見落とす可能性がある
• 学習/チューニング依存の対策は、継続運用におけるコスト（再評価・再学習・テスト）が効いてくる

まだ十分に言語化できない部分もありますが、少なくとも「どの層で、何を守っているのか」を明示して議論する癖がついたのは大きいです。

ツール連携・マルチエージェントで複雑になる信頼境界

そのうえで、オーケストレーター、A2A、MCP、AutoGenのような構成要素が重なると、信頼境界やツール呼び出しの正当性判断が一段と複雑になることを、ホテル予約を題材にした演習で具体的に追いました。ツール応答に埋め込まれた指示が後段の判断を歪めたり、意図しない大量のツール呼び出しで負荷やコストが増幅したり、長期記憶へ悪意ある事実が書き込まれ後続セッションに影響し続けたりするシナリオに触れるなかで、サーバ側での価格検証や応答のサニタイズ、オーケストレータ側での介入といった多層防御が、なぜ単一の対策では足りないのかが腹落ちしました。

2) MASで「攻撃面」と「影響範囲」が増える感覚

MAS（複数エージェント＋外部ツール）の世界では、脆弱性が“点”ではなく“連鎖”として表面化します。演習を通じて印象に残ったのは、次のような観点でした。

• ツール応答の汚染: ツールが返したテキストに紛れた指示が、後段の判断をねじ曲げる
• コスト/負荷の増幅: 意図しない大量のツール呼び出しが、運用コストやレート制限に直結する
• 長期記憶（メモリ）の汚染: 1回の悪意ある入力が“事実”として保持され、後続セッションに残り続ける

一方で、対策も「プロンプトを強くする」だけでは足りず、サーバ側での検証（価格・権限・整合性）、応答のサニタイズ、オーケストレータ側の介入などを組み合わせた多層防御が必要になります。ここは、AI以前のセキュリティ設計（境界、検証、最小権限、監視）の延長線上にありつつ、AI特有の“指示が混ざる”性質で難しさが増していると感じました。

2-補足) 「トレードオフ」が一番難しかった

個人的に一番難しかったのは、対策の良し悪しを単純に決められず、安全性・コスト・ユーザー体験・運用負荷のバランスを取りながら意思決定する必要がある点でした。たとえば強い検知を入れるほど誤検知が増えたり、ログを厚くすると扱うべき個人情報や保管コストが増えたりします。

このあたりを、受講生同士で「サービス提供者としてどこに落とすか」を議論した時間は、学生として貴重でした。正解が1つではないからこそ、前提・目的・許容できない失敗を明文化して判断する必要がある、と感じています。

机上の脅威モデリングで「言語化」する練習

机上の脅威モデリングでは、アーキテクチャを分解し、計画・記憶・ツール・認証・人間の関与・マルチエージェントという観点で脅威を列挙し、想定シナリオと対策の優先度まで言語化する練習をしました。OWASPのエージェントAI向け資料に照らし合わせながら、Rogueコンポーネントが存在する前提が監査可能性や権限設計に与える影響を整理できたことは、設計レビューの現場でも役に立つ型だと感じています。

3) 「想定外」を減らすための分解と優先度づけ

脅威モデリングは、個人的に“強い人の職人芸”だと思っていたのですが、今回、分解の軸を持って丁寧に列挙し、優先度を付けることで、初心者でも一定の質を担保できる感覚がありました。

• 資産（守るべきもの）: 何が漏れる/壊れると最も困るか
• 信頼境界: どこから先が“信用してはいけない入力”か
• 検証可能性（監査）: 後から説明できるログ/証跡が残る設計になっているか
• 権限: Rogueなコンポーネントが混じっても、被害が局所化するか

まだ実務での経験は少ないですが、設計レビューや要件定義の場で、少なくとも「何を前提に判断したか」を言語化する助けになると感じました。

異分野との議論で、優先度づけが現実になる

共通講義やコネクトワークでは、法律や脅威の専門性を持つ受講者と議論し、違法性やレピュテーション、利用者保護といった観点は、技術対策の優先順位づけとセットで考えなければ現実のサービスでは足りない、という当たり前が改めて重みを持ちました。

自分が関わったこと

演習では「攻撃/防御を実際に確かめる」ための小さなコードや検証手順を作り、手元で再現しながら議論に参加しました。曖昧な議論を避けて「どこで何が起きているか」を確かめにいく姿勢は、今後も大事にしたいです。

今後に向けて（学生としての目標）

今回学んだ内容は、理解できたつもりでも、手元の開発に落とすと抜けが出ると思います。まずは小さくても良いので、

• 既存のLLMアプリに対して **テストケース（攻撃/防御）**を作り、再現可能な形で回す
• ツール連携がある構成では、**信頼境界と検証点（サーバ側のチェック）**を明示して設計する
• 失敗例を“分類”し、対策を“比較”できるように、観測点（ログ/メトリクス）を整える

といった形で、繰り返し適用していきたいです。

参考リンク（一般情報）

• IPA: セキュリティ・キャンプ2026コネクト
• セキュリティ・キャンプ協議会: コネクト
• OWASP Top 10 for LLM Applications
• OWASP Agentic AI - Threats and Mitigations

写真（雰囲気）

（看板写真）

まとめ

今後は、学んだフレームを手元の開発や検証に繰り返し適用し、安全なAIシステム設計の言語化と自動化の両面を深めていきたいと考えています。
本プログラムに関わった講師・チューター・事務局の皆様、そして議論を共にした受講生の皆様に感謝申し上げます。