こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの第 5 回レポートです。シリーズの背景や全体像については、 初回の大阪・事業会社編レポート をご覧ください。 大阪・名古屋に続き、2026 年 4 月 27 日は広島にて、AI を自社の業務に活かしたい企業のエグゼクティブ・情報システム部門の皆様をお迎えし、「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 」と題したイベントを開催しました。 イベントの流れ 当日はまず、Amazon Web Services Japan のソリューションアーキテクト木村 友則から「AWS で一歩先へ！生成 AI 時代のビジネス変革の打ち手」と題したオープニングセッションをお届けしました。生成 AI が「アシスタント」から「仕事を任せられる」存在へと進化してきた流れ、人手不足という社会課題に対して AI エージェントが果たせる役割、そして AI コーディングツールの Kiro と AI エージェントプラットフォームの Amazon Quick を、デモを交えてご紹介しています。セッションの詳細については 初回の大阪・事業会社編のレポート をご覧ください。 写真: ソリューションアーキテクト木村によるオープニングセッション AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、パネルディスカッションへと進みました。ここからは、中小企業のお客様への生成 AI 導入を支援されたパートナー企業様に、その現場で得られた知見をお話しいただきました。 事例紹介：株式会社エイチビーソフトスタジオ様 〜「完璧を待たず、まず触ってみる」現場に寄り添う生成 AI 導入支援〜 事例紹介は 株式会社エイチビーソフトスタジオ 様です。愛媛県松山市を拠点に、全社員が完全リモートで業務を行い、スタッフ全員がエンジニアという企業です。システム開発・スマートフォンアプリ開発・Web システム開発などを手がけられ、使い勝手とデザイン性にこだわったアプリケーションの制作や、障害に強いサーバー設計・運用を得意とされています。同社のサービスサイトには「小さく作るを繰り返す」という開発スタイルが掲げられており、AWS を活用したクラウド環境の構築支援も提供されています。当日は AWS 木村 (営業) がモデレーターを務め、代表取締役の影浦 義丈 様に、実際に手がけられた中小企業向けの生成 AI 導入支援についてパネルディスカッション形式でお話しいただきました。 きっかけは、属人化した問い合わせ対応 今回ご紹介いただいたのは、社員 10〜50 名程度の中小企業のお客様に対する、生成 AI を活用したナレッジ共有・業務効率化の導入支援プロジェクトです。 きっかけは、お客様社内での問い合わせ対応に多くの時間が割かれていたことでした。質問が特定の人に集中し、回答の品質も人によってばらつく。多くの企業が抱える「詳しい人に聞かないと分からない」という状態です。影浦様は「お客様に対するサポートも含め、何とかしたいというのが取り組みのきっかけでした」と振り返られました。 立ちはだかった 3 つの壁 ― 期待値・ルール・データ 実際に取り組みを進める中では、大きく 3 つの壁に直面したといいます。 1 つめは 期待値の壁 です。生成 AI に対する社内の温度感に差があり、影浦様は「トップの方は『ゴーゴー』という感じなんですけれども、現場の方は『何のためにやるのか分からない』という気持ちを持たれている場合もある」と語られました。その一方で、「AI を導入すれば何とかなる」「AI を入れれば 100% の結果が返ってくる」という、高すぎる期待値が生まれてしまうこともあったといいます。 2 つめは ルールの壁 です。生成 AI を活用する上で、どこでデータが処理されるべきかといったガバナンスの考え方や社内ルールが、そもそも全くない状態でした。 3 つめは データの壁 です。生成 AI 活用のベースになるノウハウやナレッジが、そもそもドキュメント化されていない。あるいはドキュメントにはなっていても、ファイル形式や保存場所がバラバラだったり、古い状態のまま更新されていなかったりと、活用の準備が整っていない状態でした。 3 つの壁をどう乗り越えたか これらの壁に対する影浦様の実際のアプローチをお話いただきました。 AI への期待値の壁を乗り越えるために、実際に AI に触れてもらい、何ができて何ができないかを肌感をもって理解してもらうことに取り組まれました。ただ、「ツールをポンとお渡しして『やってください』と言っても、なかなか難しい」と感じられたため、社員の皆様に向けたハンズオンを定期的に開催し、生成 AI への理解を高める機会を作りました。あわせて、活用のノウハウがどうしても各人それぞれに蓄積されてしまうという課題に対しては、各自の使い方や「結果が良かった・悪かった」を発表してもらう場を設け、QA を通じて全社的にノウハウを蓄積していく方法をとり、その実施にあたっての支援も行ったということです。 ルールの壁については、いきなり「まずはルールを作ってください！」とお伝えしてもプロジェクトが進みづらい、という前提に立ち、まず影浦様が叩き台となる基準を用意し、それをベースにお客様とやり取りしながら細かく積み立てて運用ルールを作っていかれました。 そして特徴的だったのが、データの壁への対処です。ドキュメント化されていない属人的なノウハウを「ゼロから文章を書いてください」と言ってもなかなか書けない。そこで影浦様が試したのが、 AI でインタビューをさせて、ドキュメントの種を引き出す という方法でした。継続的に改善するには、人のインタビュアーを常に用意するのは難しい。そこで AI を活用してインタビューからドキュメント化までを一貫して行える仕組みを構築したといいます。このとき影浦様が強調されたのは、ツールの新しさそのものではなく使い手の側でした。「生成 AI を結局利用するのは人間なので、人間がどれだけ詳細な指示を与えられるか。これが肝になってくると思います」。AI をうまく動かすためのドキュメントづくりを、AI 自身に手伝わせる。データが整理しきれていない中でも、まず一歩を踏み出すための現実的な工夫です。 取り組みの成果と、残る課題 取り組みの結果、問い合わせ対応の時間が削減され、特定の人への負荷集中が緩和されました。加えて、回答品質のばらつきの是正など、いくつかの成果を得ることにつながりました。 またさらなる成果として、ドキュメント化の「文化」が根づき始めた、という点もありました。それまでは様々な知見が暗黙知になりがちでしたが、AI への取り組みを続けるなかで、少しずつドキュメントに残し、展開していこうという文化につながりつつあるということです。この文化が広がっていくことで、他の業務でも「生成 AI を使ってみたい」という社員様が新しく出てくるなど、新たなユースケースの創出にもつながり始めています。 一方で、文化の定着には時間がかかること、AI の回答精度を上げながら改善し続ける必要があること、勉強会はやっているものの個人ごとの定着度や使い方にばらつきが残ることなど、継続的なフォローの重要性も語っていただきました。 参加者へのアドバイス ― 「触ってみないと分からない」 AI は進化も早く、また企業の課題も様々であるため、AI の活用方法の見定めには「やはり触ってみないと分からないことが多い」と述べられたうえで、「データにしてもセキュリティのルールにしても、完璧に全て揃えてからではなく、今あるもので、まず小さく始めて触ってみることが大切」と述べていただきました。 また、生成 AI の社内展開について、「個人で進めるのではなく、ハンズオンや勉強会、共有会のような場で、全社的に・チームでノウハウを共有しながら進めていただくと、取り組みが定着しやすくなる」と語られました。 写真: 株式会社エイチビーソフトスタジオ 影浦様、AWS 木村 (営業) によるパネルディスカッション まとめ セッション後には参加者同士のグループワーク・ディスカッションやネットワーキングの時間を設け、自社の AI 活用における課題について活発な議論が交わされました。アンケートでは「他業種の方のお話を聞く機会が少ないため大変参考になった」「少人数で密に意見交換ができた」といった、参加者同士の交流を評価する声を多くいただきました。参加者の皆様も、ご自身に近い背景を持つ地元企業の取り組みを情報交換したり、その場で相談しあったりできており、AWS もその輪に参加させていただけてとても有意義な時間だったと感じております。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした広島編に続き、次回は福岡編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に自社の眠るデータを価値に変えたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#1/8）開催レポート AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 大阪編（#2/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 名古屋編（#3/8）開催レポート AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 名古屋編（#4/8）開催レポート 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

はじめに 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の商標です。

この記事では、ミイダスのエンジニアチームがAI駆動開発にどう取り組んでいるかをご紹介します。 使っているツールやAI利用にあたっての原則、現場の変化、そしてまだ課題として残っていることまで、できるだけ具体的にお伝えします。 「実際のところ、どんな開発環境なんだろう？」と気になっている方に、少しでもリアルな姿が届けば嬉しいです。