Z4 ／ コマ1SEMINAR MATERIALS

コマ1 ／ 8月11日(火) 08:30–12:30

座学 — 3日間で必要な理論を学ぶ

以降の5コマは全て手を動かす時間に充てる。だからこの4時間で、ラボ環境で手を動かして得た「体験」を チームで共有できる言葉に変換し、実装に入る前に全員の理解を揃える。

GOAL root / admin 権限を取るペンテストAIエージェントを開発する

IP アドレスだけを渡された初見の標的に対して、エージェントが自力で 偵察 → 侵入 → 権限昇格まで走り切り、root / admin を取得する。 3日間かけて鍛えるのは、この1本の連鎖を最後まで通す能力。

INPUT IP アドレスだけ PHASE 1 偵察 PHASE 2 侵入（シェル取得） PHASE 3 権限昇格 GOAL root / admin ここを人手を介さず、初見の標的で通せるようにするのが3日間の課題
条件 1

初見の標的で通ること

開発中に見た標的にだけ効く調整に逃げない。標的固有のハードコードは失格。

条件 2

取れたと言うなら証拠を出すこと

「root を取った」の自己申告は認めない。検証できる証拠が唯一の成功判定。

条件 3

止まったなら理由を言えること

全標的の攻略は狙わない。どこで止まり、なぜかを説明できることが到達目標。

00このコマの位置づけ

本ゼミはゼロから作らない。動くマルチエージェント実装をテンプレートとして受け取り、未知の標的に通用するまで鍛える。 そのため「読めること」「測れること」「直すべき場所を切り分けられること」が前提能力になる。コマ1はその前提を作る時間。

DAY 1 AM コマ1 ／ 座学 理論を出し切る チームで同じ言葉を使えるようにする DAY 1 PM – DAY 3 AM コマ2 〜 コマ5 ／ 開発・改善 4コマすべて手を動かす時間。実装 → 動かす → 直すを繰り返す 標的は順次追加される。初見の標的でも通るエージェントに鍛える DAY 3 PM コマ6 最終ランと成果報告書 発表準備 8/14 成果発表 開発コース 座学で整理した共通の言葉が、以降4コマの開発と設計議論の土台になる
図0-1　コマ1は「作る」コマではなく「以降5コマを速く進めるための準備」。ここで整理した共通の言葉が、コマ2以降の開発と設計議論でそのまま使われる。

014時間の進行

この4時間で、ラボ環境への接続と座学4本を通す。座学は①②を要点だけ短く、③④に時間を多めに取る。
③（設計論）→ ④（実物のコード）の順で進むのは、先に設計の考え方を入れておくと、 コードを読むときに「知らないものを読む」ではなく「知っているものを探す」に変わるから。

ここで扱う4本の座学は独立した知識ではない。①で「人間が何を判断しているか」を言語化し、 ②でそれを機械に扱わせる型を学び、③で複数体に分ける設計を学び、④で実物のコードに突き合わせる。 一本の線としてつながっている。

タイムライン（クリックで詳細） 08:30 – 12:30
08:30 09:30 10:30 11:30 12:30 休憩
ブロックをクリックすると内容が出る。

02ラボ環境で手動でチャレンジ — 体験を要求仕様に変換する

ラボ環境に接続できたら、まず参加者自身が手動で1台の標的に取り組む。目的は攻略できたかの確認ではない。 「何を見て次の手を決めたか」を、その場でメモとして残すこと。 このメモが、そのままエージェント設計の要求仕様になる。

STEP 1 手を動かした記録 「nmapの結果を見た」 「バージョンで検索した」 「PoCが動かず直した」 「SUIDを一覧した」 = その場で残す作業メモ STEP 2 判断の言語化 何を観測したか（入力） 何を根拠に選んだか（判断） 次に何をしたか（行動） どこで詰まり、どう抜けたか = チームで共有するメモ STEP 3 要求仕様 必要な観測 → ツール要件 判断基準 → プロンプト要件 覚えておくこと → 状態設計 詰まり方 → 回復戦略 = 設計の入力 STEP 4 実装 担当エージェント の改修へ コマ3以降
図0-2　「うまくいった手順」を再現させたいのではない。手順を選んだ判断をエージェントに反映する。手順だけ移すと、その標的にしか効かないエージェントになる。

手動チャレンジで記録すること

01 / OBSERVE

何が見えたか

スキャン結果、バナー、エラーメッセージ、レスポンスの差。見えたものを事実のまま述べる。解釈と混ぜない。

02 / DECIDE

なぜその手を選んだか

候補は複数あったはず。選ばなかった手と、選ばなかった理由まで話せると設計に使える情報が増える。

03 / STUCK

どこで詰まり、どう抜けたか

詰まりの抜け方こそエージェントが最も苦手な部分。「検索して出てこなかったとき何をしたか」は特に重要。

攻略できなくてもよい

この時間で最後まで行けなくても問題ない。「どこまで進んで、何が分からず止まったか」も重要な記録。
むしろあなたが止まった場所は、エージェントも同じ場所で止まる可能性が高い。詰まりどころの共有は、攻略成功と同じくらい設計の役に立つ。

03資料一覧

各ページは独立して読める。当日はこの順で進める。

4本のつながり

flowchart LR A["ラボ環境
手動チャレンジの体験"] --> B["座学①
ペンテストの型"] B -->|"人間の判断を分解"| C["座学②
エージェントの型"] C -->|"1体では足りない"| D["座学③
複数体の設計"] D -->|"実物で確認"| E["座学④
テンプレート読解"] E --> F["コマ2〜5
開発・改善"] B -.->|"評価指標の言葉"| F D -.->|"設計判断の記録"| F classDef pre fill:#fdf8f1,stroke:#f2b544,color:#10262e classDef lec fill:#f6fbfc,stroke:#0e8f9e,color:#10262e classDef out fill:#ffffff,stroke:#cddde2,color:#10262e class A pre class B,C,D,E lec class F out
図0-3　①が要求、②③が設計手段、④が実装の答え合わせ。この順で入れると、④のコード読解が「知らないものを読む」から「知っているものを探す」に変わる。

04このコマの成果物

DELIVERABLE 1

判断フローの整理（要求仕様の原型）

3人の手動チャレンジの過程を統合した1枚。観測 → 判断 → 行動の連鎖として書く。 コマ2以降の改善と設計レビューで参照するので、メモをテキストに整理しておく。

DELIVERABLE 2

テンプレート実装の読解メモ

座学④の対応表を埋めたもの。どこに何があるか・自分の担当がどのファイルかが分かる状態にしておく。
あわせて、読んでいて気になった点を改善の候補として書き留めておく。コマ2以降の着手順を決める材料になる。

評価指標 — 改善が効いたかを主観で語らせないために
指標定義
侵入成功率 / 権限昇格成功率到達数 ÷ 対象数
到達フェーズ分布偵察止まり／脆弱性特定止まり／シェル取得／root。どこで詰まるかの分布
LLM要求数・所要時間1標的あたり。成果が同じなら少ないほど良い
ハルシネーション率「取れた」と報告したが実際には取れていなかった件数。0 が要件
汎化ギャップ開発用標的の成功率 − 初見標的の成功率。小さいほど良い

05重要事項

RULE / 実質締切

実装を止める締切は 8/13 17:00

コマ6では 14:30–15:30 に最終ランを行い、15:30–17:00 に結果整理と発表準備、17:00–17:30 に成果報告書を仕上げる。
17:00 以降は実装せず、成果報告書に集中するのが固定ルール。

RULE / 標的の破壊

壊れたら消して作り直す

エージェントは標的を壊す。ラボは作り直せば元に戻るので、おかしいと思ったら運営にリバートを依頼する。
壊れた環境をデバッグしている時間はない。最初からそうする癖をつけておくこと。

RULE / 安全管理

ラボ外への実行は一切禁止

全演習は閉域ラボ内のみ。攻撃コード・PoC は演習リポジトリ内に限定し外部に公開しない。 APIキーは秘密情報として扱い大会終了後にローテーションする。テンプレートの確認プロンプトと denylist があっても最終責任は実行者。

役割分担

担当担当フェーズ主な技術課題
A：偵察偵察／外部調査非HTTPサービスの列挙漏れをなくす。製品＋バージョン特定 → CVE紐付け。列挙の打ち切り判断
B：侵入侵入PoC の取得・適応・実行。失敗時の別方向への切り替え。検索で有用な情報が見つからないとき、対象そのものを調べ直す方向へ切り替えられること
C：ポストEx内部偵察／権限昇格権限昇格ベクタ列挙の体系化と GTFOBins 的推論。SUID/sudo/cron/capability/PATH 等
3人共同全体統括／報告フェーズ遷移方針、リトライ戦略、予算配分

担当エージェントのプロンプト・ツール・状態設計はオーナーが決定権を持つ。 この所有権の切り方が、そのまま成果報告書の「執筆者自身の作業内容を他より厚く記す」を満たす。