はじめに こんにちは、タイミーでエンジニアをしている徳富( @yannKazu1 )です。 タイミーではメインサービスのバックエンドを Rails で開発しています（Go を採用しているプロダクトもありますが、本記事では Rails を前提とします）。 突然ですが、皆さんのチームでは CI の待ち時間、気になっていませんか？ 「Push した、コーヒー淹れた、戻ってきた、まだ回ってる……」みたいな経験は、開発者なら一度はあるのではないでしょうか。 本記事では、そんな状況を改善するために GitHub Actions 上のテスト実行パイプラインで取り組んだ 3 つの高速化テク を紹介します。どれも「知っていれば明日から試せる」くらいの温度感なので、気軽に読んでいただければと思います。 1. キャッシュの保存先を GitHub Cache から S3 に移行 課題: actions/cache が安定して速くない 最初にぶつかった壁が actions/cache の速度でした。 vendor/bundle （数百 MB〜1 GB 超）の save/restore でやたら時間がかかることがあり、リストアだけで数分待たされる場面がちょくちょくありました。これはセルフホストランナーに限った話ではなく、GitHub ホステッドランナーでも起きます。 実際、公式リポジトリにも Extremely slow cache on self-hosted from time to time という Issue が立っていて、セルフホスト・GitHub ホステッド問わず同様の報告が寄せられています。 さらに私たちの場合、 AWS 上のセルフホストランナー を使っているのでなおさらです。 actions/cache のバックエンドは Azure Blob Storage のため、セルフホストランナーからだとインターネット経由のアクセスになり、スループットが 約 20 MB/s まで落ちる ケースも報告されています（ Actuated Blog ）。突発的に遅いうえに経路も遠い——これでは安定した速度は望めません。 容量面でも、リポジトリあたり 10GB の制限があります。また、7 日間アクセスのないキャッシュは自動削除されます。その結果、ブランチが増えるとすぐに上限に達し、必要なキャッシュが消えてしまうのも地味にストレスでした。 解決策: runs-on/cache で S3 をバックエンドに そこで [runs-on/cache](https://github.com/runs-on/cache) を導入し、キャッシュの保存先を 同一リージョン（東京）の S3 バケット に切り替えました。 前述のとおり、セルフホストランナーで  actions/cache  を使うとスループットが ~20 MB/s まで落ちるケースがあります。一方  runs-on/cache  は同一リージョンの S3 を使えるため、200 MiB/s 以上 のスループットが出ます（ 公式ドキュメント ）。単純計算で 10 倍近い改善 です。 actions/cache とインターフェースがそのまま同じなので、 uses: を差し替えて環境変数を 1 つ足すだけで移行できました。 # .github/actions/setup-ruby-with-s3-cache/action.yml - name : Restore cache uses : runs-on/cache@v4.2.3-r2 env : RUNS_ON_S3_BUCKET_CACHE : your-gha-cache-bucket with : path : "**/vendor/bundle" key : bundle-v1-${{ runner.os }}-${{ inputs.ruby_version }}-${{ hashFiles('Gemfile.lock') }} restore-keys : | bundle-v1-${{ runner.os }}-${{ inputs.ruby_version }}- bundle-v1-${{ runner.os }}- なぜ runs-on/cache を選んだか S3 をキャッシュバックエンドにする方法は他にもあります（ tespkg/actions-cache 、 whywaita/actions-cache-s3 、自前の aws s3 cp スクリプトなど）。その中で runs-on/cache にした決め手はこのあたりです。 環境変数 1 つで切り替え : RUNS_ON_S3_BUCKET_CACHE を設定するだけで S3 バックエンドに切り替わる 自前実装が不要 : 圧縮・展開・キャッシュキーのマッチング・フォールバックなど、地味にめんどくさい部分を全部やってくれる 容量無制限 : S3 なので 10GB の制限もキャッシュの自動削除もなし キャッシュキーの設計 キャッシュキーは 3 段階のフォールバック構造にしています。 bundle-v1-Linux-3.3.6-<Gemfile.lock のハッシュ> ← 完全一致（最速） bundle-v1-Linux-3.3.6- ← Ruby バージョン一致 bundle-v1-Linux- ← OS のみ一致 完全一致しなくても、部分一致したキャッシュをリストアして bundle install すれば差分の gem だけで済みます。ゼロからインストールするより圧倒的に速いので、新しいブランチでもほぼキャッシュが効く状態を維持できます。 OIDC 認証で安全に S3 にアクセス AWS へのアクセスには OIDC 認証 を使っています。長期的なアクセスキーをシークレットに保存しなくて済むので、セキュリティ面でも安心です。 - name : Configure AWS credentials uses : aws-actions/configure-aws-credentials@v6 with : role-to-assume : arn:aws:iam::123456789012:role/your-gha-role aws-region : ap-northeast-1 2. マイグレーション結果をまるごとキャッシュ 課題: 毎回のマイグレーションが地味に重い テストジョブは毎回データベースをセットアップします。ここで問題になったのが、マイグレーション数が数百を超えてくると rails db:create db:schema:load だけで 数分かかる ということ。 「schema:load だからすぐ終わるでしょ？」と思いきや、テーブル数が多いとそうでもないんですよね。 解決策: MySQL のデータディレクトリごと S3 にキャッシュ 発想を変えて、 マイグレーション済みの MySQL データディレクトリ ( /var/lib/mysql ) をまるごと S3 にキャッシュ することにしました。要は「マイグレーション済みの DB をそのまま持ってくれば、マイグレーション自体を省略できるよね」という作戦です。 仕組みの全体像 【キャッシュの生成】 【キャッシュの利用】 master ブランチ feature ブランチ db/migrate/** 変更 テストジョブ起動 or 毎日定時 │ │ ▼ ▼ S3 からキャッシュをリストア MySQL 起動 → ./tmp/mysql_data に展開 │ │ ▼ ▼ rails db:create db:migrate MySQL 起動（データマウント済み） │ │ ▼ ▼ ./tmp/mysql_data を S3 に保存 rails db:migrate（差分のみ） │ ▼ テスト実行 キャッシュの生成: master で定期的に焼き直す master ブランチでマイグレーションファイルが変更されたとき、または毎日定時に、専用のワークフローがキャッシュを更新します。 # .github/workflows/update-migration-cache.yml on : push : branches : [ master ] paths : - 'db/migrate/**' - 'db/schema.rb' - '.github/workflows/update-migration-cache.yml' - '.github/actions/migration-hash/**' schedule : - cron : '0 2 * * *' # 毎日 UTC 2:00（JST 11:00）に実行 workflow_dispatch : # 手動実行も可能 やっていることはシンプルです。 MySQL コンテナを起動（データディレクトリを ./tmp/mysql_data にマウント） rails db:create db:migrate でフルマイグレーション実行 ./tmp/mysql_data をまるごと S3 にアップロード - name : Run database migration run : bundle exec rails db:create db:migrate - name : Save migration cache uses : runs-on/cache/save@v4.2.3-r2 env : RUNS_ON_S3_BUCKET_CACHE : your-gha-cache-bucket with : path : ./tmp/mysql_data key : test-${{ runner.os }}-${{ runner.arch }}-mysql${{ steps.migration-hash.outputs.mysql_version }}-${{ runner.environment }}-db-migration-${{ steps.migration-hash.outputs.hash }} キャッシュキーの設計: 何をキーに含めるかが大事 キャッシュキーには地味に気を使っています。 test-Linux-X64-mysql8.0.28-self-hosted-db-migration-<db/schema.rb のハッシュ> │ │ │ │ │ OS ARCH MySQL Ver ランナー環境 スキーマハッシュ ポイントは db/schema.rb のハッシュを含めていること。 マイグレーションの内容が変われば schema.rb も変わる ので、自動的に新しいキャッシュが生成されます。MySQL バージョンやアーキテクチャもキーに入れているのは、バイナリ非互換でハマらないための保険です（一度やらかしました……）。 キャッシュの利用: Composite Action で再利用しやすく キャッシュの利用ロジックは Composite Action に切り出して、RSpec だけでなく Steep（型チェック）など他のワークフローからも使い回しています。 # .github/actions/setup-mysql/action.yml - name : Create MySQL data directory run : mkdir -p ./tmp/mysql_data - name : Restore migration cache id : cache-hit-check uses : runs-on/cache/restore@v4.2.3-r2 env : RUNS_ON_S3_BUCKET_CACHE : your-gha-cache-bucket with : path : ./tmp/mysql_data key : test-${{ runner.os }}-${{ runner.arch }}-mysql${{ mysql_version }}-${{ runner.environment }}-db-migration-${{ hash }} - name : Start MySQL service with docker compose run : docker compose -f compose.ci.yml up -d mysql8 Docker Compose では、リストアしたデータディレクトリをそのままボリュームマウントします。 # compose.ci.yml services : mysql8 : volumes : - ./tmp/mysql_data:/var/lib/mysql MySQL が起動すると、キャッシュ内のデータファイルがそのまま認識されるので、 マイグレーション済みのデータベースが即座に使える 状態になります。 テストジョブでの分岐: キャッシュがあれば差分だけ 各テストジョブでは、キャッシュがヒットしたかどうかで処理を分岐しています。 - name : RSpec run : | if [ "${{ steps.setup-mysql.outputs.cache_hit }}" == "true" ] ; then echo "Using cached migration data, running incremental migration" bundle exec rails db:migrate # ← ブランチ固有の差分だけ else echo "No cache found, running schema load" bundle exec rails db:create db:schema:load fi キャッシュヒット時 : master のマイグレーション済みデータが復元されているので、 db:migrate で差分だけ適用。たいていは数秒で終わります キャッシュミス時 : MySQL バージョンアップ直後などキャッシュがない場合は db:schema:load にフォールバック この仕組みのおかげで、並列のテストジョブそれぞれで数分かかっていた DB セットアップが数秒になりました。体感で一番効果が大きかった施策かもしれません。 3. CI 用 MySQL のパフォーマンスチューニング 課題: デフォルト設定の MySQL が意外とボトルネック テスト環境の MySQL をデフォルト設定のまま使っていたのですが、ある日ふと気づきました。テストでは各テストケースごとに BEGIN / ROLLBACK やテーブルのクリーンアップが走るので、 書き込みが尋常じゃない量になっている んですよね。 デフォルト設定だと、コミットのたびにディスクへの fsync が走ります。本番では安全のために必要ですが、テスト環境では……正直、オーバースペックです。 解決策: テスト環境に限定して、耐久性よりパフォーマンスを優先する CI 専用の compose.ci.yml で、 データ耐久性を思い切って犠牲にして、書き込みパフォーマンスを最大化 しました。 # compose.ci.yml services : mysql8 : image : ${MYSQL_IMAGE} command : > mysqld --innodb-flush-log-at-trx-commit=0 --sync-binlog=0 --skip-innodb-doublewrite environment : MYSQL_ALLOW_EMPTY_PASSWORD : "yes" ports : - "3306:3306" volumes : - ./tmp/mysql_data:/var/lib/mysql 各パラメータの解説 innodb-flush-log-at-trx-commit=0 InnoDB のログ書き込み動作を制御するパラメータです。 値 動作 用途 1（デフォルト） コミットのたびにログをディスクに fsync 本番環境（ACID 完全準拠） 2 コミットのたびに OS バッファに書き込み、 fsync は毎秒 レプリカなど 0 ログの書き込みも fsync も毎秒のバッチ処理 テスト環境 テストで 1 秒以内にクラッシュリカバリが必要な場面はないので、 0 にして コミットごとの fsync オーバーヘッドを完全に排除 しています。 sync-binlog=0 バイナリログ（レプリケーション用）の同期タイミングです。 値 動作 1（デフォルト） コミットごとにバイナリログを fsync 0 OS のファイルシステムキャッシュに任せる テスト環境ではレプリケーションを使わないので、バイナリログを sync_binlog=0 にし、同期を OS のキャッシュに任せることでコミットごとの fsync を省いています。 skip-innodb-doublewrite InnoDB の doublewrite バッファを無効化します。これは書き込み途中のクラッシュに備えて全ページを 2 回書く安全機構なのですが、テスト環境では不要です。無効化すれば 書き込み I/O が大幅に減ります 。 注意: 本番では絶対にやらないでください 念のため書いておきますが、上記の設定は データの耐久性・整合性を犠牲にしています 。 innodb-flush-log-at-trx-commit=0 : クラッシュで最大 1 秒分のトランザクションが消える sync-binlog=0 : クラッシュでバイナリログが不完全になる可能性 skip-innodb-doublewrite : 部分書き込みでデータ破損のリスク テスト環境は「テストが通ればデータは捨てる」使い捨ての世界なので、これらのリスクは許容しています。くれぐれも本番には適用しないように！ まとめ 施策 何をキャッシュ/最適化しているか 効果 S3 キャッシュ vendor/bundle （Gem パッケージ） ダウンロード高速化・容量制限の解消 マイグレーションキャッシュ マイグレーション済み MySQL データ DB セットアップ時間を数分→数秒に MySQL チューニング fsync・doublewrite の無効化 テスト中の書き込み I/O を削減 CI の高速化に近道はなくて、結局はボトルネックを一つずつ潰していくしかありません。 DB のデータ耐久性は不要なので無効化する。マイグレーションは毎回ゼロからやる必要がないのでキャッシュする。キャッシュの保存先は、ネットワーク的に近い場所に置く。こうした「当たり前だけど意外とやっていない」割り切りが、大きな高速化につながりました。 同じような課題を抱えるチームの参考になれば嬉しいです。

はじめに NTT西日本の鴨下です。 2025年末に、OSCP、OSCP+に合格しました。 以前からずっと興味のあった資格でしたが、同時に「かなり難しい資格」というイメージも強く、自分に本当に取れるのかはずっと半信半疑でした。これまで自分が受けてきた資格は、どちらかというと座学中心で、知識を問うものが多かったです。その中でOSCPは、実際に手を動かして侵入し、権限昇格し、証跡を残してレポートを書くという、かなり実務寄りの資格です。OffSecの公式情報でも、OSCPは脆弱性の特定、悪用、権限昇格、文書化までを含むハンズオン試験として案内されています。 だからこそ、単なる知識試験ではなく、「自分が本当に攻撃者視点で考えて動けるのか」を確かめる意味でも挑戦したいと思っていました。結果として、合格はできましたが、振り返るとかなり泥臭い道のりでした。特に1回目は0点で不合格を経験しており、最初から順調だったわけではありません。この記事では、そんな自分の実体験をもとに、勉強の進め方、本番で困ったこと、そしてこれから受験する人に伝えたいことをまとめます。 私が受験したタイミングでは、OSCP試験に合格することで従来からあるOSCPと、資格に有効期限があるOSCP+を同時に取得することができました。本記事では、どちらの資格についてもOSCPと表現させていただきます。 本記事は2025年12月時点の情報に基づきます。 対象読者 この記事は、次のような人を想定しています。 OSCPをこれから受けようと思っている人 座学中心の資格は持っているが、実技資格は初めての人 HTBやCTFの経験は少しあるが、Boot2Root形式に慣れていない人 PEN-200（OffSecのペネトレーションテストコース）、Challenge Lab、Proving Groundsをどう活用すべきか悩んでいる人 1回試験に落ちたあと、何を変えればよいのか知りたい人 特に、自分と同じように「ペネトレーションテストが未経験に近い状態から学習を始めた人」には、かなり近い感覚で読んでもらえると思います。 目次 はじめに 対象読者 目次 1. 背景 2. 勉強開始時の状況 3. 学習の進め方 3-1. 全体の流れ 3-2. モジュールラボは軽視しないほうがよい 3-3. Proving Groundsの活用はかなり重要 3-4. メモの取り方はチートシートよりObsidianでのWriteup蓄積を重視 3-5. 初動の探索はRustScanを実行 3-6. Webサービスが見えたらFeroxbusterを実行 3-7. シェル取得後はLinPEASとWinPEASを使用して探索 4. 受験の実体験 4-1. 1回目の受験では0点 4-2. 2回目で変えたこと 4-3. 2回目の試験当日の流れ 5. 困ったこととアドバイス 5-1. 試験中に困ったこと 5-2. レポートで困ったこと 5-3. これから受ける人への具体的なアドバイス まとめ 謝辞 参考資料・出典 執筆者 商標 1. 背景 OSCPはOffensive Security Certified Professionalの略で、OffSecが提供する実践型のペネトレーションテスト資格です。現在の試験は、3台の単体マシンで合計60点、3台構成のActive Directory（以下、AD）セットで40点、合計100点満点で採点されます。 ​ 単体マシンは1台20点で、初期侵入10点と権限昇格10点の部分点があります。ADセットは2台のクライアントと1台のドメインコントローラーで構成され、AD全体で40点です。合格ラインは70点で、たとえばAD 40点に加えて単体マシンの攻略を組み合わせる形で到達できます。 ​ 試験後にはレポート提出が必要で、OffSecはPDF形式で、攻撃の説明、実行したコマンド、コンソール出力、スクリーンショットを含む報告書を求めています。つまり、試験は「侵入できるか」だけではなく、「再現可能な形で証跡を残せるか」まで含めて評価されます。 ​ 2. 勉強開始時の状況 勉強を始めたのは2025年7月でした。Learn One（OffSecのサブスクリプションプラン）の受講期限が12月末までだったので、実質半年で仕上げる必要がありました。今振り返ると、ちゃんと1年かけて準備できていれば、もっと精神的にも余裕があったと思います。 スタート時点で、セキュリティスキル的には完全な初心者だったわけではありません。LPIC（Linux Professional Institute Certification）の合格経験もあり、Linuxの基本操作にはそこまで困りませんでした。ただし、Kali Linuxは使ったことがなく、Boot2Root形式の「1台のマシンに侵入して、リバースシェルを取り、権限昇格してフラグを回収する」という流れの問題は未経験でした。Parrot OSというペネトレーションテスト専用のLinuxでHTB Academyをやり込んだことはありましたが、あれは学習としては非常に役立つ一方で、OSCP本番のような「完全ノーヒントで足がかりを見つける」こととは少し違います。CTFにも多少触れていましたが、OSCPに直結する形式に慣れていたとは言えませんでした。 自分が特に苦手だったのは、Windowsの権限昇格とADでした。ADの知識はほぼゼロに近く、登場する概念の多くが初見でした。逆にLinux側は、操作面ではまだ入りやすかったです。この「何が分かっていて、何が分からないか」を早めに自覚できたのは、後から考えると大きかったです。 3. 学習の進め方 3-1. 全体の流れ 自分は、だいたい次の流れで勉強しました。 7月から9月：PEN-200のモジュールラボ 10月：Challenge Labs 10月から12月：Proving Grounds Practice 11月中旬：1回目受験 12月：2回目受験 平日は多いときで仕事のあとに4時間ほど、休日は多いときで6時間ほど勉強していました。毎日必ずやったわけではありませんが、3日以上空けたことはありません。半年しかなかったので、とにかく継続を切らさないことは意識していました。 3-2. モジュールラボは軽視しないほうがよい これから受ける人に最初に伝えたいのは、ペネトレーションテスト未経験ならPEN-200のモジュールラボをちゃんとやった方がいい、ということです。OffSecはPEN-200をOSCP取得に向けた基礎コースとして位置づけており、実践的な攻撃と列挙の土台を学ぶ前提になっています。 ​ 正直、最初は「早く実戦っぽいことをやりたい」と思っていました。でも、後から振り返ると、モジュールラボを通して「OSCPでは何が問われるのか」「どういう観点で攻略すべきか」を把握できたのは大きかったです。特に自分のように、Windows PrivEscやADに苦手意識がある人ほど、基礎を一度体系的に踏んでおいた方が後で楽になります。 3-3. Proving Groundsの活用はかなり重要 私が受講させていただいていたLearn OneプランにはProving Grounds Practiceが利用できる権限が付属しており、これがかなり役に立ちました。自分はEASYを50台くらい、残り30台をIntermediateで進めて、NetSecFocus Trophy Roomに記載されているProving Grounds Practiceのラボは全部やりました。 docs.google.com これをやって一番変わったのは、「脆弱性の知識が増えた」こと以上に、「攻略の流れが少しずつ自分の中にできた」ことです。1台目、2台目、3台目のころは、何を見ればいいのかも曖昧でした。でも数をこなしていくと、最初に何を列挙するか、Webならどこを見るか、SMBなら何を確認するか、ユーザーが取れたあとに何を疑うか、という順番が少しずつ固まってきます。OSCPではこの「流れ」が本当に大事でした。 3-4. メモの取り方はチートシートよりObsidianでのWriteup蓄積を重視 技術的な運用面でいうと、自分はよくある「専用のコマンドチートシート」をまとめることはしませんでした。その代わり、攻略したChallenge LabsやProving Grounds Practiceの各マシンの「Writeup（自分なりの攻略メモ）」を、ひたすらObsidianに書き溜めていきました。 なぜチートシートを作らなかったかというと、OSCPの本番で問われるのは「コマンドの文法や使い方」ではなく、「なぜその状況で、そのコマンドを使うという判断に至ったのか」という思考プロセスだからです。完全ノーヒントの中で初見のマシンを攻略しなければならない試験において、単なるコマンドの羅列をまとめたチートシートを準備しても、本番では対応しきれない場面が多いと感じました。 とはいえ、長時間の試験中に「あのツール、どんなオプションを付けたっけ？」と過去の記憶を頼りにする場面は当然あります。だからこそ検索性は大事なのですが、そこでObsidianの検索機能がかなり活きました。自分が過去に悩んで攻略したWriteupから検索をかけることで、「こういう列挙結果が出たから、このコマンドを使った」という文脈ごと引っ張り出すことができたからです。 文脈とコマンドをセットで振り返れる点と、素早く情報を引き出せる検索性を両立できたので、試験中の迷いを減らす上でこの運用は非常に良かったです。 3-5. 初動の探索はRustScanを実行 探索ツールでよく使っていたのはRustScanでした。 -- オプションを用いることでNmapのオプションをそのまま渡せるのが便利、かつ高速なので、まずこれを回して全体像をつかむという流れを固定化していました。 さらに、ファイルにアウトプットする -oN オプションも使って、後から見返せるようにしていました。本番では、1回見た結果を頭だけで保持するのはかなり厳しいですし、コマンドの実行結果がすぐに画面外へ流れてしまいます。そのため、自分は「最初にRustScanを回して、結果を保存して、全体像をつかんで分析する」という流れを意識していました。 3-6. Webサービスが見えたらFeroxbusterを実行 Webサービスが見つかった場合には、ディレクトリ探索ツールとして Feroxbuster を使っていました。 数あるディレクトリ探索ツールの中でこれを使っていた最大の理由は、新しく見つかったディレクトリに対して、自動で並行して再帰探索を進めてくれるからです。また、実行状況を保存してくれるため、プロセスを一度止めても前回の途中から再開できるという機能があり、これも長時間の試験の中で複数の調査を並行して行う際に非常に便利でした。 ワードリストとしては directory-list-2.3-large.txt や common.txt をよく使っていました。 Webサービスが見つかった場合には、最初から派手な脆弱性探しをするより、まず「どこが公開されているのか」を正確に把握することが大事だと感じています。管理画面、古いバックアップ、アップロード機能、開発用ディレクトリ、APIっぽいエンドポイントなど、見えているものを丁寧に拾うだけで足がかりにつながることがあります。1回目の受験ではここが雑でしたが、2回目はFeroxbusterの便利さも活かしつつ「見えているものを全部確認する」という意識が強くなっていて、その違いは初期侵入のスピードにおいてかなり大きかったと思います。 3-7. シェル取得後はLinPEASとWinPEASを使用して探索 シェルが取れた後は、LinuxならLinPEAS（Linux Privilege Escalation Awesome Script）、WindowsならWinPEAS（Windows Privilege Escalation Awesome Script）を回すようにしていました。もちろん、これだけで終わりではなく、出力された内容を見ながら自分で掘る必要はありますが、網羅的に権限昇格の糸口を洗うための初動としてはかなり有効でした。 特に自分はWindows PrivEscが苦手だったので、何を見ればよいかの抜け漏れを減らす意味でも、この運用は効果がありました。長時間の試験では集中力が落ちるので、「取れたら必ずやる」というルールを決めておく方が安定します。ツールの出力を眺めるだけでなく、サービス権限、スケジュールタスク、レジストリ、資格情報、ファイル配置などを自分で追う入口にする、という使い方でした。 4. 受験の実体験 4-1. 1回目の受験では0点 1回目の受験は、11月中旬でした。結果は0点でした。今だから書けますが、かなりショックでした。 このとき痛感したのは、「Proving Grounds PracticeやChallenge Labsで見た手法が、そのまま本番で再利用できるわけではない」ということです。似たようなサービスや似たような構成が出ても、入口の見つけ方も違うし、必要な発想も違うことがあります。自分はその時点で、ラボを20台くらいしかやっておらず、しかも自力で最後まで攻略できたのは1台か2台くらいでした。つまり、知識として見たことはあっても、身体で覚えるほどには反復できていなかったわけです。 1回目の敗因を今の自分なりに整理すると、主に次の2つでした。 ラボ攻略経験が少なすぎたこと マシン攻略の流れが自分の中で固まっていなかったこと 本番では、最初の足がかりを探すだけで躓きました。何から疑うべきか、どこまで調べたら「見落としはない」と言えるのか、その感覚がまったくできていなかったです。1回目は、知識不足というより、実践攻略の流れができていなかった、という負け方だったと思います。 4-2. 2回目で変えたこと 2回目までの間に、自分は3つのことを明確に変えました。 攻略するラボ（Proving Grounds Practice）の量を増やしたこと 攻略の流れを決めたこと ADセットから触る戦略を取ったこと まず、攻略したラボの数は20台くらいから80台くらいまで増やしました。これはかなり効きました。単に「似た問題に当たった」からではなく、見方そのものが変わってきます。サービス一覧を見た瞬間に、どの調査を優先するかが少しずつ速くなりました。 次に、自分の中で攻略フローを作りました。最初に何をやるか、初期侵入が取れないときにどこまで戻るか、権限昇格で何を確認するか、そういう順番を決めておくと、本番で焦っても思考が飛びにくくなります。OSCPは長時間試験なので、地力だけでなく、実践的な攻略の流れを把握しているかがかなり重要です。 たとえば、最初にRustScanでポートを確認し、主要サービスごとに調査対象を切り分け、WebがあればFeroxbuster、SMBなら共有確認、シェル取得後はLinPEASかWinPEAS、というように、自分の中で分岐を固定化していました。完璧なフローではなくても、「次に何をするか」が決まっているだけで、本番の不安はかなり減ります。 最後に、ADセットを最初に触る方針にしました。OffSecの試験ではADセットが40点なので、ここを先に取れると合格に一気に近づきます。 自分の場合、この方針はかなり良かったです。精神面でも大きく、先に大きな配点を確保できると、残りの単体マシンに対して落ち着いて向き合いやすくなりました。 ​ 4-3. 2回目の試験当日の流れ 2回目は、朝から部屋を片づけたり、必要なものを整えたりして、10時に試験を開始しました。環境はデスクトップPC1台、モニタ1台で、メモはObsidianに取り、スクリーンショットもそこに整理していきました。複数モニタでも受験自体は可能ですが、自分は1枚で進めました。 結果としては、試験開始12時間ほどかけて合格ラインに到達できました。 14時ごろ：ADセット完了、40点 15時ごろ：単体マシン1台完了、20点 22時ごろ：単体マシン2台目完了、20点で80点の合格ラインに到達 ここだけ見ると順調ですが、実際はその間にかなりしんどい時間がありました。特に、回答が長時間止まった時間帯は精神的にかなりきつかったです。「また落ちるかもしれない」「ここまで来たのにフラグが取れない」という焦りがどんどん強くなります。 このとき一番大事だったのは、落ち着くことでした。勢いで新しいツールを増やしたり、根拠の薄い仮説を追いかけたりすると、かえって悪化します。自分は「必ず見落としがあるはず」と考えて、ツールの実行結果や列挙結果を最初から見直しました。すると、そこに糸口がありました。本番で詰まったときに必要なのは、丁寧に戻ることだと強く感じました。 また、技術的な運用で地味に役立ったのが、リバースシェルの管理です。試験ではMetasploitのExploit、Auxiliary、PostモジュールとMeterpreterは1台のみに制限されますが、exploit/multi/handler と msfvenom は全ターゲットに対して使えます。 そのため、自分は multi/handler を使って同一ポートで複数シェルを待ち受けたり、取得したシェルをバックグラウンドに回したりして、リバースシェルを整理していました。これはかなり便利で、特に複数台をまたいで作業するときに「今どのシェルがどのマシンのものか」を崩しにくくなります。 ​ その後、翌2時ごろまでは食事や休憩、翌4時ごろまではスクリーンショットの確認などを進めました。翌4時から8時までは就寝し、8時から9時でレポート用の見直し、最後に未攻略マシンへ再挑戦しましたが、足がかりを見つけたところでタイムアップでした。 5. 困ったこととアドバイス 5-1. 試験中に困ったこと 一番困ったのは、やはり進捗が止まったときのメンタルでした。OSCPは「技術試験」であると同時に、「長時間、あきらめずに続ける試験」でもあります。 自分からの具体的なアドバイスは3つです。 詰まったら、むやみに手法を増やすより列挙結果を見直す。 何分悩んだら一度戻る、という基準を事前に決める。 大きく詰まったら、一度席を離れて頭をリセットする。 自分は外にご飯を食べに行ったのが良かったです。外に出るだけで気持ちが切り替わるし、「もう一回、最初から丁寧に見よう」という状態に戻れました。部屋の中で焦り続けるより、短くても意識的にリセットする方が結果的に前に進めることがあります。 技術面で補足すると、詰まったときほど「新しい武器」を探したくなりますが、実際には最初に取ったメモ、保存したスキャン結果、Web列挙の出力、PEASツールの出力の中に見落としがあることが多いです。だからこそ、結果をきちんと保存しておく運用が重要でした。1回見て終わりではなく、戻れる状態を作っておくことが、本番では有効でした。 5-2. レポートで困ったこと レポートで一番不安だったのは、「ちゃんとルール通りで壊れていないファイルが提出できるか」でした。OffSecは、攻撃手順と証跡を含むPDFレポートを .7z にまとめ、指定のファイル名で提出するよう求めていて、提出前にはPDFの体裁確認やMD5による整合性確認も案内しています。 ​ 自分はKali上でPDFを作成できるSysReptor（ペネトレーションテスト向けレポート作成ツール）を使うつもりでしたが、試験後の24時間でインストールも含めてやろうとしたので、そこは反省点でした。結果的にSysReptor自体はかなり使いやすく、導入して良かったです。ただ、これは間違いなく事前に入れておくべきでした。本番後の24時間は、レポートの中身に集中した方がいいです。 あと、どこまで詳しく書くべきかは迷いました。そこは公式Discordに書かれている質問の履歴を参考にしながら調整しました。試験当日に慌てないためには、次の3つを強くおすすめします。 スクリーンショットは侵入のたびに確実に取る。 入力したコマンド履歴だけでなく、その実行結果も一緒に残す。 レポート作成ツールは事前に準備して、最低1回は試す。 OffSecは、証跡不足やスクリーンショット不足があると減点または0点になる可能性があると明記していて、proof.txtやlocal.txtは元の場所で cat や type を使って対話的シェル上で表示し、その内容とIPアドレスが分かるスクリーンショットを残す必要があります。 ​ 5-3. これから受ける人への具体的なアドバイス 最後に、これから受験する人に伝えたいことをまとめると、具体的には以下のようになります。 ペネトレーションテスト未経験なら、モジュールラボを軽視しない。 Proving GroundsのEASYは可能な限り多く取り組む。 Intermediateも、少なくともNetSecFocus Trophy Roomに載っているものは可能な限り多く取り組む。 「1台ごとの攻略」より、「攻略の流れを固める」ことを意識する。 本番中は最後まで諦めない。 特に最後は本当に大事だと思います。答えまでの道筋は、だいたい列挙結果やツールの出力の中にあります。見つからないときは「何もない」のではなく、「まだ見えていない」ことが多いです。自分も、精神的にかなり沈んだ時間帯がありましたが、そこから見直して糸口を見つけました。焦って雑に探すより、落ち着いて丁寧に見る方が前に進めます。 自分の実感としては、「使えるツールをたくさん知っていること」より、「いつ、何のために使うかが決まっていること」の方が重要でした。RustScan、Feroxbuster、LinPEAS、WinPEAS、multi/handlerのような定番ツールでも十分対応できると感じました。 まとめ OSCPに合格して、素直にうれしかったです。ずっと憧れていた資格だったので、合格通知を見たときは達成感がありました。 ただ、同時に強く思ったのは、OSCPはゴールではなく入口だということです。PEN-200はOffSec自身も基礎的なペネトレーションテスト技能を学ぶためのコースとして位置づけており、OSCP合格後もさらに上位の実践資格へ進める構成になっています。 実際、自分も「OSCPを取れば一人前になれる」というより、「OSCPを取ったことで、自分にまだ足りないものがよく分かった」と感じました。 ​ それでも、この資格には取る意味があります。座学だけでは得にくい、列挙の大切さ、証跡の残し方、詰まったときの立て直し方、そして最後まで諦めない姿勢を、自分の手で学べるからです。これから受ける人には、完璧な状態でなくてもいいので、とにかく手を動かして、数をこなして、自分の中で攻略の流れを作ってほしいです。 謝辞 最後に、このような挑戦の機会を与えてくださった関係者の皆様に、心より感謝申し上げます。日々の業務や学習を支えていただいたことで、最後まで諦めずに走り切ることができました。また、試験期間中に協力してくれた家族にも本当に感謝しています。長時間の受験とレポート作成に集中できたのは、周囲の理解と支えがあったからこそでした。この合格は自分一人の力だけで得られたものではなく、支えてくださった皆様のおかげだと感じています。 参考資料・出典 本記事を執筆するにあたり、以下のサイトを参考にしました。 docs.google.com 執筆者 鴨下 将成（NTT西日本 セキュリティ＆トラスト部所属） 社内セキュリティ業務に携わっています。 好きな食べ物はラーメンです。 OSCP、CISSP、GPEN、GREM、GCFE、CEH、情報処理安全確保支援士 商標 OSCP（Offensive Security Certified Professional）、PEN-200、OffSecは、Offensive Securityの商標または登録商標です。 Windows、Active Directoryは、Microsoft Corporationの商標または登録商標です。 Kali Linuxは、Offensive Securityの商標です。 Parrot OSは、Parrot Securityの商標です。 Nmapは、Insecure.Com LLCの登録商標です。 MetasploitおよびMeterpreterは、Rapid7, Inc.の商標または登録商標です。 Obsidianは、Obsidian.mdの商標です。 Hack The Box（HTB）は、Hack The Box Ltdの商標です。

2026 年 6 月 8 日週、 AWS IoT Device SDK for Swift が一般公開されました。 Swift Server Workgroup (SSWG) のメンバーである私は、これに注目しています。この SDK は、macOS、iOS、tvOS、Linux の Swift 開発者に本番環境で利用できる MQTT 5 接続、デバイスシャドウ、ジョブ、フリートプロビジョニングを提供します。 皆さんなら、この SDK を使用して何を構築しますか? サーバー上の Swift はここ数年で成熟し、現在では IoT デバイスにも適用されています。これは、Swift をエッジで実行するという幅広いトレンドにつながっています。例えば、 WendyOS は物理 AI 向けのオープンソースのオペレーティングシステムで、NVIDIA Jetson や Raspberry Pi ハードウェアにアプリケーションをデプロイするためのファーストクラスの Swift サポートを提供しています。サーバーサイドの Swift、IoT、エッジコンピューティング間で、数年前にはほとんどの人が驚いたであろう複数の場所にこの言語が登場しています。 それでは、2026 年 6 月 8 日週の AWS ニュースを見ていきましょう。 見出し Amazon RDS for SQL Server が Bring Your Own Media をサポート – オンプレミス環境から SQL Server アプリケーションを移行するお客様は、Amazon RDS 上の Microsoft の License Mobility プログラムを通じて、Software Assurance を含む既存の Microsoft SQL Server ライセンスを再利用できるようになりました。BYOM は AWS License Manager と統合されており、ライセンスの使用状況とコンプライアンスを追跡できます。 さらに表示 Amazon Cognito がマルチリージョンレプリケーションのサポートを開始 – 認証情報、ユーザープール設定、フェデレーション設定などのユーザーとマシンの ID データを、スタンバイリージョンのセカンダリユーザープールにほぼリアルタイムで同期できるようになりました。プライマリリージョンで障害が発生しても、サインインしたユーザーは再認証することなく引き続きアプリケーションにアクセスでき、登録ユーザーは既存の認証情報でサインインできます。マルチリージョンレプリケーションは、16 のリージョンにわたる Essentials または Plus 機能階層のユーザープールのアドオンとして利用できます。  さらに表示 OpenAI の GPT-5.5、GPT-5.4、Codex の Amazon Bedrock での一般提供を開始 – Amazon Bedrock の本番ワークロードで GPT-5.5 と GPT-5.4 を使用できるようになりました。また、AWS 全体で既に使用しているのと同じセキュリティ、ガバナンス、運用制御を使用して、AI を活用したソフトウェア開発でコーデックスを構築できます。GPT-5.5 は OpenAI の最も高性能なモデルで、エージェンティックコーディング、データ分析、多段階の自律タスクに長けています。Codex は、Codex App、Codex CLI、および Visual Studio Code、JetBrains、Xcode との IDE 統合を通じて利用できます。価格は OpenAI のファーストパーティー料金に一致し、使用回数は既存の AWS コミットメントに反映されます。  さらに表示 2026 年 6 月 1 日週のリリース 2026 年 6 月 1 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Amazon Bedrock に OpenAI および Anthropic互換 API 用の CloudWatch メトリクスを追加 – CloudWatch メトリクスを使用して、bedrock-mantle エンドポイントへの推論トラフィックをモニタリングできるようになりました。これには、推論カウント、入出力トークンの合計、アカウント、プロジェクト、モデル、プロジェクトおよびモデルの細分性におけるクライアントエラー数が含まれます。 Amazon Bedrock が OpenAI と Anthropic 互換の API 向けに最適化された再設計されたコンソールを発表 – モデルカタログ、並列比較、プロジェクトベースの編成、コードスニペットがあらかじめ入力されたプロジェクト対応ドキュメントなどを使用して、コンソールワークフローを一新しました。 Amazon Bedrock AgentCore Identity が AWS Secrets Manager による独自のシークレットの持ち込みのサポートを開始 – お客様は AgentCore ID 認証情報プロバイダの既存の AWS Secrets Manager シークレット ARN を参照できるようになり、カスタム CMK、タグ付け戦略、自動ローテーションを含むシークレットガバナンスの完全な所有権が実現しました。 AWS Step Functions に AgentCore を利用したエージェント推論ステップを追加 – Amazon Bedrock AgentCore のマネージドハーネスとの統合により、Step Functions ワークフローに AI エージェント推論ステップを追加できるようになりました。複数のエージェントを並行して実行したり、順番に実行したり、人間による承認を追加したり、すべてのエージェントの決定を追跡したりできます。 Amazon EKS と Amazon EKS Distro が Kubernetes バージョン 1.36 のサポートを開始 – Kubernetes 1.36 では、ユーザー名前空間が GA に昇格され、変更されたアドミッションポリシー、インプレースポッドレベルのリソースの垂直スケーリング、リソースヘルスステータスレポートが導入されました。EKS が利用可能なすべての地域で利用できます。 Amazon ECS マネージドインスタンスが AWS Trainium と AWS Inferentia のサポートを開始 – Inferentia2、Trainium1、Trainium2 の各インスタンスタイプで ECS マネージドインスタンスのキャパシティプロバイダーを作成し、Amazon ECS にすべてのアクセラレーターリソースをワークロードに自動的に割り当てることができるようになりました。 Amazon Quick が MCP 接続の VPC 接続のサポートを開始 – 企業のお客様は、プライベートにホストされているモデルコンテキストプロトコル (MCP) サーバーを VPC 経由で Amazon Quick に接続できるようになりました。これにより、インターネットに公開されることなく、独自のアプリケーションや内部ツールに安全にアクセスできるようになります。 AWS Cost and Usage Report 2.0 が Athena と Redshift の統合のサポートを開始 – CUR 2.0 のエクスポートは、サポート対象のインフラストラクチャテンプレート、テーブル定義、データロード手順とともに、選択したクエリエンジンに最適な形式で自動的に配信されます。 Amazon Location Service が公共交通機関とインターモーダルルーティングを発表 – Routes API では、交通手段とインターモーダルという 2 つの新しい移動モードがサポートされるようになりました。これにより、13 の地域にわたって、公共交通機関と徒歩、車、タクシー、レンタルのセグメントを組み合わせて旅行を計画できます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 今後の AWS イベント AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント 、 AWS Summits や AWS Community Days を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 2026 年 6 月 8 日週のニュースは以上です。2026 年 6 月 15 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – seb 原文は こちら です。