OSAI合格体験記：人間とAIエージェントの協働でどう準備したか
AIモデル × 実行基盤 ＋ 人間の判断力 ＝ 成果
OffSec AI Red Teamer（OSAI）に合格しました。この記事では試験問題の解き方ではなく、私がどのように準備し、人間とAIエージェントの役割を分けて取り組んだかを紹介します。これから受験する方が、自分に合った環境や進め方を考える際の参考になれば幸いです。
summary
- 人間が方針を決め、AIが作業を進める。 私の記録では、戦略判断の約7割を人間が担い、技術的な実行の約8割をAIエージェントが担当しました。人間の役割は指示を出すだけでなく、結果を確かめ、方向を修正することです。
- 事前の環境づくりが重要。 複数のエージェントに共通ルールと役割を与え、作業環境を分け、結果を記録できる状態にしておきます。
- モデルを用途で使い分ける。 戦略や分析には高性能なモデル、反復作業や大量の試行には運用可能なオープンウェイトモデルを使いました。
- ルールや手順書は公式ラボで磨く。 本番で初めて作るのではなく、練習中に動作を確かめておきます。
- 証跡、認証情報、報告書を最初から管理する。 最後にまとめて処理しようとすると、重要な情報が抜けやすくなります。
冒頭の式は、今回の経験を私なりに整理したものです。高性能なモデルがあっても、それを動かす環境や作業ルールが整っていなければ力を発揮できません。一方で、対象範囲の判断、結果の検証、最終的な責任は人間に残ります。
01 ／ 人間とAIの役割をどう分けたか
今回、特に大切だと感じたのは、人間とAIの協働の設計です。目標や優先順位は人間が決め、具体的な調査や反復作業はAIに任せる。この分担がうまく機能しました。
| 作業 | 人間の役割 | AIの役割 |
|---|---|---|
| 戦略：目標、攻撃経路、続行・中止の判断 | 主導（約7割） | 選択肢の整理 |
| フラグの探索と確認 | 探す場所の判断、結果の確認 | 調査と候補の提示 |
| 戦術：手順や次の作業の検討 | 方針の修正 | 主に担当 |
| 技術的な実行 | 監督と検証（約1〜2割） | 主に担当（約8割） |
私が入力した指示は数百回、AI側のやり取りは数万回でした。おおよそ人間の1回の指示に対してAIのやり取りが80回という比率です。ただし、重要なのは回数よりも指示の質です。人間の指示の多くは単なる承認ではなく、目的を明確にしたり、誤った方向を修正したりするものでした。
一度決めた方針は、担当エージェントにも共有されます。だからこそ、最初に目的、対象範囲、判断基準を明確に書くことが重要です。
02 ／ 実行環境とツール構成
私の環境では、OMP(Main)、OpenCode、Piを同じ作業領域で使いました。複数のエージェントをHerdr上で並行して動かすため、全員が参照する共通ルールをAGENTS.mdに置き、必要に応じて各ツール向けのファイル名から参照させました。
OMPでは役割と計画を管理しました。 調整役、初期調査、個別作業、品質確認といった担当と制約をあらかじめ決めます。誰が何をするかが明確だと、作業の重複や方向のずれを減らせます。
herdrでは長時間動く端末を管理しました。 OMP、OpenCode、Piの作業を継続でき、端末の出力をテキストとして保存できます。操作記録は後から確認し、必要な部分を証跡として参照できるようにしました。
作業ごとに実行環境を分けました。 担当エージェントごとに作業フォルダ、ファイル名、仮想環境、ソケット、ポート、プロキシ設定を分けます。他の担当が使うプロセスやトンネルには触れない、というルールも設けました。並列作業で起こりやすい衝突を防ぐためです。
03 ／ モデルを用途で使い分ける
商用の高性能モデルは、認可された演習中でも、一部のセキュリティ関連作業に応答できないことがあります。そのため、同じモデルですべての作業を進める前提にはしませんでした。各サービスの利用条件と試験のルールを確認したうえで、作業に応じて利用可能なモデルを選びます。
| 用途 | 主に使ったモデル |
|---|---|
| 戦略、分析、脅威モデリング、全体の調整 | ClaudeやCodexなどの高性能モデル |
| 大量の試行、下書き、反復的な作業 | 運用を認められた環境のオープンウェイトモデル（DeepSeek、GLMなど） |
| 作業の実行と記録 | OMP、OpenCode、herdrなどの実行環境 |
難しい判断が必要な場面には高性能モデルまたはHigh Effortを使い、繰り返しが多い作業には費用を抑えられるモデルを使う。この切り分けが基本です。オープンウェイトモデルも複数用意しておくと、一つが利用できないときに作業を切り替えやすくなります。
私の記録では、高性能モデルが担当したやり取りは約5％、オープンウェイトモデルは約95％でした。やり取り1回あたりの費用には、おおよそ200倍の差がありました。利用量と費用を見ながら、性能が必要な場面に予算を充てるのが現実的です。高性能モデルはSubscriptionでカバー、受験にかかった費用はオープンモデルAPIでかかった30ドル未満
04 ／ 複数エージェントをどう動かしたか
調査対象や作業が独立している場合は、役割を分けて並行して進めました。
- 調整役・執筆担当： 全体の状況、対象への操作、確定した結果、報告書の整合性を管理する。
- 初期調査担当： 情報を整理し、調査方針を提案する。
- 作業担当： 個別の検証、出力の分析、証跡の収集を行う。
- 接続環境の管理担当： トンネルや中継経路を監視する。
- 報告・品質確認担当： 証跡と記述が一致するかを確認する。また人間にステータスをリアルタイム更新してあげる
独立した作業には担当を割り当て、終了した担当には次の作業を渡します。ただし、人数を増やせば常に速くなるわけではありません。同じファイルやポートを複数の担当が使うと、むしろ衝突が増えます。対象ホストや共有リソースには責任者を一人決め、担当期間と使用範囲を記録しました。
新しい作業を始める前には、既存の担当と対象やリソースが重ならないか確認します。進捗がなくても定期的に状況を共有し、担当が止まった場合には作業を再割り当てできるようにします。空いた担当者には、新しい調査を増やすだけでなく、既存の結果の再確認や報告準備も任せました。
05 ／ 公式ラボで実行基盤を鍛える
共通ルール、カスタムスキル、作業手順書は、公式ラボやチャレンジで試しながら整えました。本番で初めて導入した仕組みは、問題が起きても直す時間が足りません。
事前に用意したものは、主に次の三つです。
- Rules（共通ルール）： 対象範囲、担当分け、証跡の扱い、判断基準などを短く明文化します。対象固有の事実は、確認できた時点で追加します。未確認の推測を確定事項として扱わないことも重要です。
- Skills（作業を支える機能）： 調査、検証、報告のための補助機能です。特に役立ったのは、作業記録の管理、機密情報の検査、接続状態の監視、フラグや結果の記録といった運用面の機能でした。
- Runbooks（作業手順書）： 接続が切れたり環境がリセットされたりした際に、作業を再開するための手順をMarkdownで記録します。練習中に復旧まで試しておきます。
設計上、次の点も重視しました。
- 知識を作業領域に残す。 確認済みの事実、証跡、報告書の下書き、担当ごとの記録をファイルに保存します。環境をリセットしても、そこまでの理解を失わないようにするためです。
- 証跡を識別できるようにする。 元データには識別子とハッシュ値を付け、保存後は原本を編集しません。更新が必要なら別の版を作ります。
- 保存後に読み直す。 フラグなどの重要な値は、書き込んだ後にもう一度確認し、重複や取り違えがないか調べます。
- 否定的な結果を慎重に扱う。 「見つからなかった」という結果は、同じ実行環境でツールが正常に動くことを、既知の対象で確かめてから採用します。ツールの故障を「存在しない」と誤認しないためです。
- 共有ツールを安全に更新する。 実行中のファイルを直接書き換えず、一時ファイルで検証してから置き換えます。
- 接続経路を管理する。 共通で使うトンネルを増やしすぎず、再起動した場合は通信経路を再確認します。長時間の接続経路を安定して維持する
- 環境の復旧を想定する。 作業状態と証跡の一覧を定期的に保存します。環境がリセットされた後は、以前の認証情報がまだ有効だと決めつけません。Revert実施後の直前状態へのリカバリー重要
06 ／ 証跡を残しながら進める
結果だけ合っていても、何を確認したか説明できなければ報告できません。作業中から、次の情報を一組で記録します。
対象 ／ UTC時刻 ／ 実行者 ／ 操作内容 ／ 元の出力 ／ 結果を裏付ける証拠 ／ 関連ログ ／ ハッシュ値 ／ 事実と推測の区別 ／ 後片付け
端末の出力、通信の記録、取得したファイルなど、元データを優先して保存します。スクリーンショットが必要な場合も、対象名、操作、出力が読み取れる形で残します。
また、「アクセス拒否」は「ファイルが存在しない」と同じ意味ではありません。探索した場所ごとに、発見、存在しない、アクセス拒否を分けて記録しました。HTTPの成功応答やハッシュ値の一致だけで、その先の処理が実行されたと判断しないことも大切です。期待した変化が実際に起きたかを別途確認します。
07 ／ 認証情報やフラグの取り扱い
機密情報が残る場所は、保存ファイルやチャットだけではありません。エージェントの操作記録にも残り得ます。この三つを含めて確認する必要があります。取得データはKali VM内で扱いました
- 原則として値そのものを共有しない。 認証情報やフラグは識別子で参照し、平文はアクセスを制限した保管場所だけに置きます。必要なときに限って読み出します。
- 記録にはメタデータを使う。 値を転載せず、識別子、長さ、ハッシュ値などで照合します。
- 操作ログへの混入を防ぐ。 コマンド引数や貼り付けたテキストは記録される場合があります。値をそのまま入力せず、処理内で安全に読み出せる形にします。
- 検査範囲を明確にする。 特定の文字列を検索して見つからなくても、漏えいがないとは限りません。作業フォルダ全体を対象にし、いつ、どのファイルを検査したかを残します。
- 説明には架空の値を使う。 例示や共有用の文章に実際の値を含めません。マスキング後の出力にも元の値が残っていないか確認します。
「検出件数がゼロ」は、その時点で検査した範囲についての結果です。新しいファイルを作ったら、検査もやり直します。
08 ／ 報告書は作業中から作る
報告書は最後に記憶を頼りに書くのではなく、結果が出た時点で少しずつ組み立てました。報告対象になりそうな発見にはすぐフォルダと証跡IDを作り、時刻、対象、操作、出力を対応付けます。
各発見については、次の流れで説明できる状態を目指します。
影響を受ける資産 → 最初のアクセス → 再現に必要な手順 → 各段階の証跡 → 根本原因 → 得られた権限や状態の変化 → 影響 → 関連ログ → 改善策 → 後片付け
AIに固有の信頼境界の問題なのか、従来からある設定・権限管理の問題なのかも分けて記述します。MITRE ATLASやATT&CKとの対応付けは、根拠がある場合に限ります。証跡で示せない内容は、推測や調査上の限界として明記します。
複数の経路を使った場合は、どの権限からどの権限へ移ったかを証跡とともに示します。得点や進捗は一つの記録から集計し、本文に手入力した数字と食い違わないようにしました。報告書で足りない項目が見えたら、その不足を次の調査にも反映します。
提出前には、証跡ID、ファイル名、画像、本文の記載を照合します。引用した元データのハッシュ値、機密情報の混入、PDFの表示、アーカイブを開けることまで確認する時間を確保しました。
09 ／ 時間と予算の配分
私は作業を、事前準備、開始直後、調査の中盤、検証と成果の整理、報告書作成、事後確認に分けて考えました。高性能モデルを使う判断作業は前半に集中し、反復的な検証は後半に増えました。
- 仮説ごとに制限時間を決める。 新しい証拠が出なければ、優先順位を見直します。
- 進捗は確認済みの結果で判断する。 面白そうな経路を深掘りする前に、残り時間と必要な成果を確認します。
- 重要な目標には複数の経路を考える。 一つの手段が使えなくなっても、検証を続けられます。
- 結果の確認と提出を分けて管理する。 発見しただけで完了にせず、必要な記録と提出まで追跡します。
10 ／ AI関連の学習範囲（AI-300の公開カリキュラムを踏まえて）
以下は公開されている学習領域を、私なりに整理したものです。試験問題や具体的な解法を示すものではありません。
| 領域 | 学習のポイント |
|---|---|
| AIサービスの調査 | HTTPヘッダーや公開エンドポイント、ツール一覧、API定義などから構成と機能を把握する。セッション管理や監視の有無も確認する。 |
| プロンプトインジェクション | システム指示、ユーザー入力、ツール出力の信頼度の違いを理解する。指示の上書き、目的のすり替え、ツール経由の動作を区別して考える。文書のアップロード、Web閲覧、コードの取り込みといった間接的な経路も含む。 |
| エージェントのメモリ | 保存情報の改ざんが後のやり取りにどう影響するか、共有メモリを通じて別セッションへ影響が及ぶかを調べる。 |
| 複数エージェントとA2A | エージェントの登録情報、JSON-RPCのタスク、引き継ぎ時の相手の識別と権限の伝わり方を理解する。 |
| RAG | 文書の取り込み、索引、検索、回答生成の各段階を整理する。取り込み時の改ざんや検索結果への不適切な誘導が、回答にどう影響するかを考える。 |
| 埋め込みとベクトル | メンバーシップ推論や埋め込みからの情報復元について、アクセス権限ごとに何が確認できるかを整理する。結果を過大評価しない。 |
| MCPとツール | ツールの設定や説明文、OpenAPIの定義、権限、引数の制限を調べる。エージェントからツール、ツールから実行環境への信頼境界を理解する。 |
| サプライチェーン |
pickle、torch.load、joblibなど読み込み時にコード実行へつながり得る形式と、safetensorsやONNXなどの形式の違いを理解する。学習データ、LoRA、トークナイザーの改ざんも対象にする。 |
| クラウドとKubernetes | IAMロール、パラメータストア、コンテナイメージ、推論エンドポイント、KubernetesのRBACとサービスアカウントを通じた権限や認証情報の扱いを確認する。 |
| 脅威モデリング | 構成図、守るべき資産、前提条件、想定される攻撃経路を整理し、MITRE ATLASやATT&CKとの対応と対策を説明する。 |
私は、サービスの調査から始め、プロンプトインジェクション、RAGとMCP、複数エージェント、埋め込み、サプライチェーン、クラウド基盤の順に学ぶと理解しやすいと感じました。並行して、従来のネットワーク、認証、権限昇格の基礎も復習しておきます。
11 ／ 前提知識として復習した分野
AIサービスが入口でも、その先の調査では従来の技術が必要になることがあります。私が復習した主な分野は次のとおりです。
- ネットワーク経路の確認、トンネルやプロキシの扱い。
- Active Directory、LDAP、Kerberosと権限の関係。
- RDP、WinRM、SSHなどのリモートアクセス。
- LinuxとWindowsの権限昇格、設定や認証情報の調査。
- SMB共有やホスト間の認証情報の扱い。
- コード実行につながるファイルの読み込みや書き込み権限の問題。
基本的な確認も大切です。たとえば接続先の設定を作る前に、自分のVPNやネットワークインターフェースのIPアドレスを毎回確認します。
12 ／ 受験前の確認リスト
- 対象範囲と試験ルールを読み、使うツールやモデルの条件を確認した。
- AIサービスの構成や公開機能を調べ、結果を整理できる。
- ユーザー入力、外部文書、Web、ツール出力、メモリの信頼境界を説明できる。
- 単体のエージェントと複数エージェントで、指示やデータがどのように伝わるか確認できる。
- RAG、MCP、A2A、埋め込み、モデルの供給経路について、基本的なリスクを説明できる。
- 読み込み時にコード実行へつながり得るモデル形式を区別できる。
- クラウドやKubernetesの認証・権限の関係を確認できる。
- 確認した事象をMITRE ATLASやATT&CKに対応付け、根拠を説明できる。
- AIの「存在しない」「できない」という回答を、別の証拠で検証できる。
- 証跡に対象、時刻、操作、元の出力、権限、ファイルの所在を残せる。
- 共通ルール、作業手順書、報告書のひな形をラボで試した。
- エージェントが止まった場合に、手作業で続ける方法がある。
- 本番直前には新しいツールを増やさず、使い慣れた環境で確認した。
13 ／ 伝えたかったこと
以前の投稿では、今回の経験を次の三点にまとめました。
- 公式ラボで準備する。 共通ルール、カスタムスキル、作業手順書を作り、本番で使える状態まで試しておく。
- モデルを使い分ける。 戦略や分析には高性能モデル、反復的な作業には運用可能なオープンウェイトモデルを使う。
- エージェントの担当を分ける。 独立した作業を並行し、人間が結果と方向性を継続して確認する。
私の場合、戦略判断の約7割を自分で行い、実行や自動化の約8割をAIエージェントに任せました。約11時間で合格ラインを超え、試験環境での作業を終えました。AIエージェントを使うほど、人間が何を判断し、何を検証するかが重要になると感じています。
元のSNS投稿のURL：公開時に追記
試験内容の開示について
この記事では、OffSecのOSAI試験ガイドと、自分の準備・運用に関する経験をもとに書いています。試験固有の対象や解答につながる情報は含めていません。受験する方は公式ガイドを確認し、公式ラボで自身の環境と手順を検証してください。
役に立った経験談サイトtech.leonardotamiano.xyz
2026年10月7日公開。個人の立場で書いたものです。