座学 ① ／ 09:55 – 10:25
ペネトレーションテストの基礎
この座学の目的は、手技を教えることではない。「人間のペンテスターが、各局面で何を判断しているか」を分解して取り出すこと。 取り出した判断が、そのままエージェントに組み込むべきロジックになる。
手動チャレンジで自分がやったことを、この枠組みに当てはめながら聞いてほしい。
0ウォームアップクイズ — まず自分の理解を確認する
正解を暗記するためではなく、ペンテスト中に何を確認しているのかを意識するための小問。 10問すべてに答えてから採点する。
1フェーズ構成 — 偵察 / 侵入 / ポストエクスプロイト
ネットワークペンテストは大きく3つのフェーズに分かれる。重要なのは区切りの名前ではなく、 各フェーズが「どんな情報を持っていない状態」から「何を得た状態」への移動なのかという点。 エージェントのフェーズ遷移条件は、ここから導く。
赤い破線＝現実に頻発する後戻り。侵入に失敗したら偵察に戻る、内部から見えた情報で外部偵察をやり直す。
フェーズを一方通行のパイプラインとして実装すると、必ず詰まる。 「侵入で有効なベクタがなくなったら偵察に戻る」「内部で得たネットワーク情報で偵察をやり直す」という後戻りの経路を、 Orchestrator のフェーズ遷移方針に最初から入れる必要がある。テンプレート実装がこれをどう扱っているかは座学④で確認する。
2各フェーズで何を判断しているか
ペンテスターの作業は、コマンドの実行ではない。観測 → 仮説 → 選択 → 検証の連鎖。 実際の攻略トレースを1手ずつ分解して、どこに判断が入っているかを見る。
判断の4類型
上のトレースに出てくる判断は、突き詰めると次の4つに分類できる。エージェントの失敗も、この4つのどれかで起きる。
次に何を観測するか
候補は無数にある。全部やると時間が尽きる。情報利得が最大の観測を選ぶ。
偵察の中核
観測から何を仮説するか
バナー・エラー・レスポンス差から、実装と脆弱性を当てる。ここが最も知識依存。
仮説形成
いつ打ち切るか
この方向は行き止まり、と判断して別方向へ移る。エージェントが最も苦手。同じ手を延々繰り返す。
撤退判断
成功したと言えるか
「取れた気がする」と「取れた」の区別。証拠の要求。ここが緩いとハルシネーションになる。
検証
この4類型は、そのままコマ3〜5の失敗レビューの骨格になる。実行ログを読むとき 「A で漏らしたのか、B で誤ったのか、C ができずループしたのか、D が緩くてハルシネーションしたのか」で分けると、 直すべき場所（ツール／プロンプト／状態／評価）が一意に決まる。
3証拠と再現性
ペンテストの成果物は「侵入できた」という感想ではなく、第三者が同じ手順で再現でき、かつ客観的に検証できる証拠。 本ゼミでは ハルシネーション率 0 が要件 なので、この基準を自動判定に機械的に組み込むことになる。
主張には、対応する証拠がある
| 主張 | 弱い根拠（自己申告・信用しない） | 検証可能な証拠 |
|---|---|---|
| ポートが開いている | 「スキャンで見えた気がする」 | スキャナの生出力＋タイムスタンプ。再実行で同じ結果が出る |
| この脆弱性がある | 「バージョン的に該当するはず」 | 実際に挙動を引き起こしたリクエストとレスポンスの対。バージョン一致は仮説であって証拠ではない |
| シェルを取得した | 「エクスプロイトがエラーを返さなかった」 | そのシェル上で実行した id / hostname の出力。標的固有の値が返ること |
| root を取得した | 「sudo が通った」 | id が uid=0(root)。かつ root でしか読めないファイル（例：/etc/shadow の先頭行）が読めること |
| この手順で再現できる | 「だいたいこうやった」 | 標的をリセットしてから同じ手順を流し、同じ結果になることの確認 |
「root を取った」と報告して実際は取れていないのが、この種のエージェントで最悪の失敗モード。 改善のフィードバックループ自体が壊れるため、以降の全計測が信用できなくなる。 客観的に検証できる証拠が取れたことを唯一の成功判定にする（自動判定に組み込む）。 エージェントの自己申告は評価に一切使わない、を設計で強制する。
4実務での進め方と、自動化が難しい理由
既存の脆弱性スキャナは20年以上前からある。それでもペンテストが手作業のままなのはなぜか。 難しさの正体を特定できれば、そこがエージェント設計で工夫すべき場所になる。
照合する"] --> S2["該当を列挙する"] end subgraph PT["ペネトレーションテスト（自動化困難）"] direction LR P1["観測から
仮説を立てる"] --> P2["仮説を実際に
試して検証する"] P2 --> P3["失敗の内容から
仮説を組み替える"] P3 --> P1 P2 --> P4["連鎖させて
目的に到達する"] end SC -.->|"ここまでしか
やらない"| PT classDef a fill:#f6fbfc,stroke:#cddde2,color:#365360 classDef b fill:#fdf8f1,stroke:#f2b544,color:#10262e class S1,S2 a class P1,P2,P3,P4 b
自動化が難しい5つの理由
探索空間が広い
「次にやれること」の候補は、状況が進むごとに増える。全部試す時間はない。 本質は候補を絞り込む判断 — どれを先に試すか（判断の4類型のA）と どこで見切りをつけるか（同C）。ここに正解のテーブルは存在しない。
成功が「連鎖」でしか定義できない
単体では無害な事実（読めるファイル、緩い権限、古いバイナリ）が、組み合わせで致命的になる。 個々のチェックをいくら並べても、連鎖は見つからない。
環境が毎回違う
OSの版、パッチ、設定、独自実装。PoC はほぼ確実にそのままでは動かない。 エラーを読んで適応させる作業が要る。ここが侵入役担当の主な担当範囲。
公開情報がない対象がある
0-day、内製アプリ、独自プロトコル。検索して出てこない。 検索を軸に組まれたエージェントはここで停止する。他人の知識に頼れないとき、対象そのものを触って調べ直すやり方に切り替えられる必要がある。
失敗の解釈が難しい
「効かなかった」のか「効いたが観測できていない」のか「前提が間違っている」のか。 同じエラーでも次の一手は変わる。ここを誤ると同じ手を繰り返すループに入る。
これらが標的に埋まっている
ラボの標的は意図的に多様に作られている（Webのないもの、既知CVE を突くもの、独自実装の欠陥を突くもの）。 Webスキャンしかしないエージェントは、最初から半分落ちる。 REASON 1〜5 のどれに当たるかは、開けてみるまで分からない。
人間は検索で有用な情報が見つからなくても止まらない。バイナリを読む、入力を壊してみる、似た製品の既知パターンを当てはめる、 プロトコルを推測する、といった対象そのものを触って調べ直す探索に切り替える。 「誰かが書いた情報」ではなく「目の前の実物」を情報源にする、という切り替え。 テンプレート実装は Web検索エージェントへの相談を軸に組まれているため、この切り替えが設計されていないとそこで停止する。 本ゼミで最も価値のある学びどころで、0-day や内製アプリでは日常的に起きる状況。
5手動チャレンジを、この枠組みに当てはめる
座学の最後に、各自の攻略メモをこの表に整理する。埋まらないマスが、エージェントに欠けている能力。 そのまま担当エージェントの改善バックログの1行目になる。
| フェーズ | 自分が観測したもの → ツール要件 |
そこから立てた仮説 → プロンプト要件 |
覚えておく必要があった情報 → 状態設計 |
詰まった箇所と抜け方 → 回復戦略 |
|---|---|---|---|---|
| 偵察 | — 当日ここを埋める — | |||
| 侵入 | — 当日ここを埋める — | |||
| ポストEx | — 当日ここを埋める — | |||
「見た情報」を全部書けているか
人間は無意識に大量の情報を使っている。ページのタイトル、レスポンスの遅さ、ポート番号の並び方。 書き出さないとツールの出力に含まれず、エージェントには存在しない情報になる。
「やらなかったこと」を書けているか
候補にあったが選ばなかった手と、その理由。これが枝刈りのロジックそのもので、 エージェントの探索効率（LLM要求数）を決める。
＊この座学の要点
1. フェーズは一方通行ではない
後戻りの経路を設計に入れる。入れないと必ず詰まる。
2. 判断は4類型に分解できる
観測選択・仮説形成・撤退判断・成功検証。失敗分類の骨格になる。
3. 成功判定は証拠でのみ行う
自己申告は評価に使わない。ハルシネーション率0を機械的に保証する。
次の 座学② では、ここで分解した「観測 → 仮説 → 選択 → 検証」のループを、 実際に LLM エージェントとして動かす型を扱う。形がそっくりであることに気づくはずで、それが狙い。