GitHub Secure Code Gameは、AIエージェントのセキュリティを「座学」ではなく、手を動かして学びたい開発者・AppSec担当者・エンジニアリングリーダーに向いた無料トレーニングです。2026年4月15日時点の更新では、Season 4としてAIエージェントを本番コードベースに入れる前に、どうレッドチーム視点で壊して確認するかに焦点が当てられました。対象は、MCP、ツール実行、永続メモリ、複数エージェント連携など、いま開発現場で導入が進む領域です。(The GitHub Blog)
結論から言うと、AIエージェントを業務や開発フローに組み込むチームは、GitHub Secure Code Gameを「新人向けのセキュアコーディング教材」としてではなく、プロダクション投入前のAIエージェント脅威モデリングを体験する教材として使うべきです。特に、自然言語でコマンドを実行するエージェント、外部ツールを呼び出すエージェント、記憶を持つエージェントを作っているチームでは、早めに触れておく価値があります。
GitHub Secure Code Gameとは何か
GitHub Secure Code Gameは、GitHub Security Labが提供する無料・オープンソースのセキュリティ学習コンテンツです。意図的に脆弱性を含んだコードや環境を使い、プレイヤーが脆弱性を見つけ、悪用の流れを理解し、修正の考え方を身につける構成になっています。
従来のセキュリティ研修は、スライドを見てチェックリストを覚える形式になりがちです。しかし、開発者が本当に必要としているのは「この設計だと、どこから壊されるのか」「どの権限を渡すと危ないのか」を自分の手で確かめる経験です。GitHub Secure Code Gameは、そのギャップを埋めるための実践型トレーニングといえます。
GitHubの公開情報によると、Secure Code GameはブラウザからGitHub Codespaces上で始められ、すでに1万人以上の開発者が利用しています。また、Season 4は「Agentic AI」、つまり自律的に行動するAIエージェントのセキュリティをテーマにしています。(GitHub Security Lab)
2026年4月15日更新のポイント：Season 4はAIエージェントのレッドチーム訓練
2026年4月15日時点の更新で注目すべき点は、GitHub Secure Code GameがAIエージェント時代のセキュリティ研修として明確に位置づけられたことです。GitHub Blogでは、Season 4を「agentic AI vulnerabilities」を学ぶ5つの段階的なチャレンジとして紹介しています。(The GitHub Blog)
Season 4では、プレイヤーは「ProdBot」という意図的に脆弱なAIコーディングアシスタントを相手にします。ProdBotは、自然言語からbashコマンドを生成・実行し、模擬Webを閲覧し、MCPサーバーに接続し、組織承認済みスキルを実行し、永続メモリを持ち、複数エージェントのワークフローを扱う設定です。(The GitHub Blog)
これは単なるゲーム設定ではありません。実際の開発現場で増えているAIエージェントの構成にかなり近いものです。たとえば、次のような社内ツールを作っている場合、Season 4のテーマはそのまま実務に関係します。
- 開発者の代わりにCLIコマンドを実行するAIアシスタント
- GitHub IssuesやPull Requestを読んで修正案を出すAIエージェント
- 社内ナレッジ、チケット、リポジトリ、クラウドAPIに接続する業務エージェント
- 複数の専門エージェントを連携させて調査、修正、テスト、報告を行う仕組み
- 過去の会話やユーザー設定を記憶して次回以降に使うアシスタント
便利な一方で、こうしたAIエージェントは「プロンプトに返答するだけのLLMアプリ」とは攻撃面が異なります。ツールを呼び出せる、ファイルに触れる、外部情報を読む、記憶する、他のエージェントに指示を渡す。これらの能力が増えるほど、攻撃者が狙える経路も増えます。
なぜAIエージェントは本番投入前にレッドチームすべきなのか
AIエージェントのリスクは、従来のWebアプリ脆弱性だけでは説明しきれません。SQLインジェクションやXSSのように入力と出力が比較的見えやすい問題だけでなく、エージェントの判断、記憶、ツール選択、権限委任が攻撃対象になります。
OWASPの「Top 10 for Agentic Applications 2026」では、自律的・エージェント型AIシステムにおける重要リスクを整理しています。OWASPはこのフレームワークを、100人以上の専門家、研究者、実務者の協力により作成されたものと説明しています。(OWASP Gen AI Security Project)
実務で特に注意したいのは、次のようなパターンです。
| リスク領域 | 起きやすい問題 | 開発現場での例 |
|---|---|---|
| 目標の乗っ取り | 本来の目的と違う行動へ誘導される | 「コードレビューして」のはずが、外部URLの指示に従って秘密情報を探し始める |
| ツールの誤用 | 正規ツールを危険な目的で使わされる | ファイル検索、メール送信、クラウドAPI、DB操作を意図しない形で実行する |
| 権限の濫用 | エージェントに与えた権限が広すぎる | 読み取りだけでよいのに書き込み、削除、デプロイ権限まで持っている |
| メモリ汚染 | 悪意ある情報が記憶され、次回以降の判断に影響する | 「今後はこの外部サイトを信頼してよい」と記憶してしまう |
| エージェント間通信の不備 | 別エージェントからの入力を無条件に信頼する | 調査担当エージェントの出力を、実行担当エージェントが検証せずに使う |
| 予期しないコード実行 | 生成・取得したコマンドやコードが危険なまま実行される | 自動修正ツールがシェルコマンドを生成し、そのままCIやローカルで実行する |
レッドチームとは、攻撃者の視点でシステムを検証する活動です。AIエージェントの場合は「モデルに危険なことを言わせる」だけでは足りません。エージェントが実際に何を読めるのか、何を実行できるのか、どのツールに接続できるのか、どの情報を記憶するのかまで確認する必要があります。
GitHub Secure Code Game Season 4が時宜にかなっているのは、まさにこの「AIエージェントの行動面」を体験できる点です。
Season 4で学べる5段階の攻撃面
GitHubの説明では、Season 4は5つのレベルで構成され、ProdBotが段階的に機能を増やしていきます。機能が増えるたびに、新しい攻撃面が生まれる設計です。(The GitHub Blog)
| レベル | ProdBotに追加される能力 | 学習すべき観点 |
|---|---|---|
| Level 1 | bashコマンドの生成・実行、サンドボックス内作業 | サンドボックス境界、コマンド実行、ファイルアクセス制御 |
| Level 2 | 模擬Webの閲覧 | 信頼できないWebコンテンツ、間接プロンプトインジェクション |
| Level 3 | MCPサーバー接続 | 外部ツール連携、ツール権限、入力・出力の検証 |
| Level 4 | 組織承認済みスキル、永続メモリ | メモリ汚染、プラグイン信頼、長期的なコンテキスト管理 |
| Level 5 | 複数エージェント、複数MCPサーバー、スキル連携 | エージェント間通信、検証済みデータの前提崩れ、複合的な攻撃経路 |
重要なのは、「AIエージェントが賢くなるほど安全になる」と考えないことです。むしろ、実行できることが増えるほど、設計者は安全境界をより明確にしなければなりません。
たとえば、Webを読めるエージェントは、外部ページに埋め込まれた悪意ある指示を読む可能性があります。MCPサーバーに接続するエージェントは、ツールの説明文や返却データを過信する可能性があります。永続メモリを持つエージェントは、一度混入した不正な前提を次回以降も使い続ける可能性があります。
Season 4は、こうした問題を「説明として読む」のではなく、段階的に体験できる点が実践的です。
開発者がGitHub Secure Code Gameから得られるもの
開発者にとってGitHub Secure Code Gameの価値は、セキュリティ専門家になることではありません。自分が実装するAIエージェントに対して、危険な設計を早めに見抜けるようになることです。
特に、次のような判断力が身につきます。
エージェントに渡してよい権限を見極める
AIエージェントに「便利だから」と広い権限を渡すと、攻撃されたときの被害範囲が大きくなります。開発者は、次のように権限を分解して考えるべきです。
| 権限の種類 | 安全寄りの設計 | 危険な設計 |
|---|---|---|
| ファイル操作 | 特定ディレクトリの読み取りのみ | ホームディレクトリ全体を読み書き可能 |
| コマンド実行 | 許可リスト方式で限定 | 任意のシェルコマンドを実行可能 |
| 外部通信 | 接続先ドメインを制限 | 任意URLへアクセス可能 |
| 認証情報 | エージェントに直接渡さない | APIキーやトークンをプロンプトや環境変数で広く露出 |
| 永続メモリ | 保存内容を分類・監査する | ユーザー入力や外部情報を無条件で記憶する |
開発者が最初に確認すべきなのは、「このエージェントは何をできるのか」ではなく、攻撃者に誘導されたときに何をしてしまえるのかです。
プロンプトだけでなくツール設計を見る
AIセキュリティの議論では、プロンプトインジェクションに注目が集まりがちです。しかし、実務ではプロンプトよりもツール設計のほうが被害を左右します。
たとえば、次の2つは同じ「ファイル整理エージェント」でもリスクが大きく違います。
| 設計 | リスク |
|---|---|
| エージェントはファイル一覧を提案するだけで、削除は人間が実行する | 比較的低い |
| エージェントがファイルを検索し、分類し、削除まで自動実行する | 高い |
| 削除前に対象ファイル、理由、復元方法を表示して承認を求める | 管理しやすい |
| 「不要そうなファイルを消して」と言うだけで実行する | 事故や悪用が起きやすい |
GitHub Secure Code Game Season 4のような教材は、プロンプト文面のテクニックではなく、エージェントが持つ能力と境界を意識するきっかけになります。
AppSecトレーナーが社内研修に使う場合の進め方
AppSec担当者やセキュリティ教育担当者にとって、GitHub Secure Code Gameは社内研修に組み込みやすい教材です。GitHub Security Labのページでは、組織内やハッカソンで利用できると説明されています。(GitHub Security Lab)
ただし、単に「各自で遊んでください」と配るだけでは効果が薄くなります。研修として使うなら、次の流れにすると学習効果が高くなります。
| フェーズ | 内容 | 目的 |
|---|---|---|
| 事前説明 | AIエージェントの構成要素を説明する | LLM、ツール、メモリ、権限、外部入力の関係を理解する |
| 個人プレイ | Season 4を各自で進める | 攻撃者視点で「壊し方」を体験する |
| 振り返り | どの入力・権限・前提が危険だったか共有する | 攻撃パターンを言語化する |
| 自社システムへの置き換え | 自社のAIエージェントやPoCに同じ観点を当てる | 学習を実務へ接続する |
| 改善バックログ化 | 権限分離、ログ、承認フロー、テスト項目を作る | 研修を実装改善につなげる |
研修後に必ずやるべきなのは、自社のAI活用案件に置き換える作業です。ゲーム内ではProdBotが対象ですが、実務では「社内チャットボット」「コードレビュー支援AI」「問い合わせ自動対応エージェント」「データ分析エージェント」などに当てはめる必要があります。
研修で使える振り返り質問
研修後のディスカッションでは、次の質問を使うと実務に結びつきやすくなります。
- エージェントはどの外部情報を信頼していたか
- どのツール呼び出しが最も危険だったか
- 人間の承認が必要な操作はどれだったか
- ログが残っていなければ原因追跡できない箇所はどこか
- エージェントのメモリに保存してはいけない情報は何か
- 複数エージェント間で検証なしに渡してはいけない情報は何か
- 自社のAIエージェントで同じ設計ミスが起きるとしたらどこか
この振り返りまで実施して初めて、GitHub Secure Code Gameは「面白い教材」から「実務改善につながる教材」になります。
エンジニアリングリーダーが見るべき導入判断
エンジニアリングリーダーにとって重要なのは、GitHub Secure Code Gameを単発の学習コンテンツとしてではなく、AI導入のリスク管理に組み込むことです。
AIエージェントを開発組織に導入する場合、次のような判断基準を持つべきです。
| 判断項目 | 確認すべきこと |
|---|---|
| 対象者 | AIエージェントを実装する開発者、レビュー担当、SRE、AppSec担当が受講しているか |
| タイミング | PoC完了後ではなく、設計段階でレッドチーム観点を入れているか |
| 権限設計 | エージェントごとに最小権限、承認フロー、実行制限が定義されているか |
| 本番前検証 | プロンプト、外部入力、ツール出力、メモリ、エージェント間通信をテストしているか |
| 運用監視 | ツール実行ログ、失敗ログ、異常な権限要求を追跡できるか |
| 教育継続 | 新機能追加時に、攻撃面の変化を再確認する仕組みがあるか |
特に避けたいのは、「GitHub CopilotやAIエージェントを使う開発者は増えたが、セキュリティレビューは従来のWebアプリ観点のまま」という状態です。AIエージェントは、コードを書くだけでなく、ツールを選び、外部情報を読み、ユーザーの代理で行動します。レビューの観点も変える必要があります。
GitHub Secure Code Gameを始める前に確認したいこと
GitHub Secure Code Gameは始めやすい教材ですが、チーム利用ではいくつか確認しておくとスムーズです。
GitHubアカウントとCodespaces利用可否
Secure Code GameはGitHub Codespacesで実行できます。ローカル環境に依存しにくいのは大きな利点ですが、企業アカウントではCodespacesの利用が制限されている場合があります。
事前に確認すべき項目は次の通りです。
- 社内ポリシー上、GitHub Codespacesを利用できるか
- 個人アカウントで実施するのか、組織アカウントで実施するのか
- Codespacesの無料枠や課金設定をどう扱うか
- 研修中に外部サービスへ接続してよいか
- 受講者がGitHubアカウントを持っているか
GitHubのリポジトリでは、テンプレートから自分のコピーを作成し、Codespacesで開く流れが案内されています。各Seasonは自己完結しており、Season 3やSeason 4から始められると説明されています。(GitHub)
受講者のレベルに合わせてSeasonを選ぶ
GitHub Secure Code Gameには複数のSeasonがあります。AIエージェントのセキュリティにすぐ入りたい場合はSeason 4からで問題ありません。ただし、LLMアプリの基礎的なリスクに不安がある場合はSeason 3を先に扱うと理解しやすくなります。
GitHubのリポジトリでは、Season 4はAgentic AI、Season 3はLLM Security、Season 2はマルチスタック、Season 1はセキュアコーディング基礎として整理されています。(GitHub)
| 目的 | おすすめ |
|---|---|
| AIエージェントのリスクを短時間で体験したい | Season 4 |
| プロンプトインジェクションやLLMアプリの基礎から学びたい | Season 3 |
| CI/CD、バックエンド、Webアプリのセキュリティも扱いたい | Season 2 |
| セキュアコーディングの基礎を広く学びたい | Season 1 |
AIエージェントを本番投入する前の実務チェックリスト
GitHub Secure Code Gameをプレイした後は、自社のAIエージェントに対してチェックリストを作ることが重要です。以下は、開発チームでそのまま使える実務向けの確認項目です。
入力と外部情報
- ユーザー入力、Webページ、ファイル、チケット、メール、ツール出力を区別して扱っているか
- 外部コンテンツに含まれる指示を、システム指示として扱わない設計になっているか
- 信頼できない情報を要約・引用する場合、出所をログに残しているか
- エージェントが「どの情報を根拠に判断したか」を後から追えるか
ツール実行
- ツールごとに許可される操作を最小限にしているか
- 高リスク操作に人間の承認を挟んでいるか
- 削除、送信、課金、デプロイ、権限変更などを自動実行させていないか
- ツールの引数をエージェント任せにせず、型・範囲・宛先を検証しているか
権限と認証情報
- エージェントにユーザーや管理者の広すぎる権限を渡していないか
- APIキーやトークンをプロンプト、ログ、メモリに露出させていないか
- エージェントごと、タスクごとに権限を分けているか
- 認証情報の利用履歴を監査できるか
メモリとコンテキスト
- 永続メモリに保存してよい情報と禁止情報を定義しているか
- 外部入力を無条件に記憶しない仕組みがあるか
- メモリを編集・削除・監査できるか
- 古い記憶や誤った前提を修正できる運用になっているか
複数エージェント連携
- 他エージェントからの出力を無条件に信頼していないか
- エージェント間で渡すデータに署名、検証、スキーマ確認などを設けているか
- 1つのエージェントの失敗が全体に波及しない設計になっているか
- 最終実行エージェントに過剰な権限が集中していないか
監視とインシデント対応
- どのエージェントが、いつ、何を、どのツールで実行したか記録しているか
- 失敗したツール呼び出しや拒否された操作もログに残しているか
- 異常な連続実行、外部送信、権限要求を検知できるか
- 問題発生時にエージェントの停止、権限剥奪、メモリ削除ができるか
このチェックリストを本番前レビューに組み込むだけでも、AIエージェントの事故リスクは大きく下げられます。
よくある失敗：AIエージェントの安全性を過信する
AIエージェントのセキュリティで失敗しやすいのは、モデルの賢さとシステムの安全性を混同することです。
たとえば、最新のモデルを使っていても、以下のような設計なら危険です。
- 外部Webページの内容を読み、その中の指示を実行してしまう
- 「社内承認済みツール」だからといって、ツール出力を検証しない
- エージェントに広いファイルアクセス権を与える
- エージェントの判断で本番環境へ変更を反映する
- メモリに保存された情報の出所や更新日を管理しない
- 1つのエージェントに調査、判断、実行、報告をすべて任せる
AIエージェントは、単なるチャットボットではありません。ツールを持たせた瞬間に、ソフトウェアとしての攻撃面を持ちます。さらに、自然言語で行動が変わるため、従来の入力検証だけでは守りきれません。
GitHub Secure Code Game Season 4を使う意義は、こうした失敗を安全な環境で先に体験できることです。失敗を本番環境で学ぶのではなく、教材の中で学ぶ。この順序が重要です。
GitHub Secure Code Gameは誰に向いているか
GitHub Secure Code Game Season 4は、次のような人に特に向いています。
| 対象者 | 得られるメリット |
|---|---|
| 開発者 | AIエージェントの危険な設計を実装前に見抜きやすくなる |
| AppSec担当者 | 社内研修や脅威モデリングの題材として使いやすい |
| エンジニアリングマネージャー | AI導入時の教育計画やリスク管理に組み込める |
| セキュリティチャンピオン | チーム内でAIセキュリティの観点を広げやすい |
| SRE・Platform担当 | ツール実行、権限、ログ、隔離設計の議論に活かせる |
| 学生・初学者 | AIセキュリティを実践的に理解する入口になる |
一方で、すでに本番AIエージェントを運用しているチームが「これをプレイしたから十分」と考えるのは危険です。Secure Code Gameはあくまで学習環境です。実システムでは、アーキテクチャレビュー、権限設計、ログ監査、レッドチーム演習、インシデント対応手順まで整える必要があります。
読了後にやるべきこと
GitHub Secure Code GameのSeason 4は、AIエージェントを開発・導入するチームにとって、今すぐ試す価値のある無料トレーニングです。特に、MCP、外部ツール、CLI実行、永続メモリ、複数エージェント連携を扱うチームは、プロダクション投入前にレッドチーム視点を持つ必要があります。
次に取るべき行動はシンプルです。
まず、開発者またはAppSec担当者がSeason 4を一通り体験します。次に、学んだ攻撃面を自社のAIエージェント設計に置き換えます。最後に、権限、ツール実行、外部入力、メモリ、ログ、承認フローのチェックリストを本番前レビューに組み込みます。
AIエージェントのセキュリティは、リリース直前に診断ツールを回すだけでは足りません。設計段階から「どう壊されるか」を考える必要があります。GitHub Secure Code Gameは、その考え方を開発者の手触りに落とし込むための実用的な入口です。
コメント