目次 はじめに 背景 UserMatching（UM）と社内システム 社内システムの課題 目指したこと 業務に入り込む進め方 ヒアリングで業務を知る ヒアリングから始めた理由 どう進めたか 分かったこと 設計でつまずいたこと AIが作った設計を判断できなかった やりたいことが広がりすぎた ひとりで考え込んでしまった どう乗り越えたか 自分で判断できるように、進め方を決めた 広がった範囲を、目的に合わせて絞った ひとりで抱えず、考えをチームに見せた 設計を終えて実装へ AIの時代に大切だと感じたこと 設計の進め方を持っておく 人に見てもらう チームで一緒に考える おわりに はじめに こんにちは、UserMatching事業でエンジニアをしている新卒2年目の惟高です！ 今は、ビジネス側のメンバーが毎日使う社内システムの作り直しを担当しています。業務のヒアリングから要件の整理、設計まで進めて、ちょうど実装に入ったところです。 この記事では、その中でつまずいたことと、どう乗り越えたか、AIを使って開発する中で大切だと感じたことをまとめていきます。 対象読者 : 社内の業務改善やツールの作り直しに関わっているエンジニアの方 分かること : エンジニアが業務に入り込んで要件から設計まで進めたとき、どこでつまずき、どう乗り越えたか 背景 UserMatching（UM）と社内システム デリッシュキッチンやトモニテでは、ユーザーがプレゼントに応募するためのLP（応募フォームのページ）を公開しています。 https://lp.delishkitchen.tv/campaign/ceres.html https://lp.tomonite.com/campaign/speee_renxa このLPの設定は、ビジネス側のメンバーが社内システムから行っています。案件ごとの設定の流れは、おおよそ次のとおりです。 社内システムでの設定の流れ 社内システムの課題 今の社内システムは、もともとエンジニアがやっていた設定作業を、そのまま画面にする形で作られてきました。そのため、ビジネス側よりもエンジニア目線に寄った作りになっていて、たとえば次のような課題が積み上がっていました。 覚えるルールが多い : 設問の回答の列名や送付先のフォルダ名など、社内システムの外の仕組みを知らないと正しく入力できない 業務と合わない : 業務ではQAや、別の人が見直すWチェックを経て公開するが、それぞれがどこまで進んだかを社内システムで追えない 操作が煩雑 : LPを作り直すたびに、変換の設定と送付の設定を複製し直す必要がある 事故が起きやすい : 列名を間違えても保存できてしまい、データを送ってから初めて気づく 一つひとつは小さな不便ですが、それが重なって使う人の負担が大きくなり、実際にミスにも繋がっていました。そこで、社内システムを見直すことになりました。 目指したこと 目指したのは、ビジネス側がエンジニアに確認しなくても、迷わず設定できる社内システムです。 最初は、今の社内システムを改修して対応するつもりでしたが、要件をまとめて設計を進めてみると、DBの構造もAPIもほとんど作り直しになることが分かりました。 それなら新しく作ったほうがよいと考え、設計の途中でシステムそのものを作り直すことに決めました。 業務に入り込む進め方 使いやすい社内システムにするには、画面の操作だけを見ていても足りません。そこで今回は、ビジネス側の業務に入り込んで、課題をどう解決するか、要件としてどうまとめるかから考えることにしました。 こうした動き方をするエンジニアは、FDE（Forward Deployed Engineer）と呼ばれています。もともとはPalantirで生まれた職種で、顧客の現場に入って課題をつかみ、それを解決するものを作ります。 振り返ると、今回の進め方はこれに近いものでした。 https://jobs.lever.co/palantir/2e6b0ac8-83e9-4be5-a3aa-cf319f751728 進め方は、大きくヒアリングと設計に分かれます。設計では、Claude Codeを使って要件の整理からDB、API、画面の設計までを進めました。 ここからは、それぞれで何をして、どこでつまずき、どう乗り越えたかを順に書いていきます。 ヒアリングで業務を知る ヒアリングから始めた理由 課題や改善案は、すでにある程度集まっていました。でも、本当に使いやすいものにするには、社内システムを触っている時間の前後で、どんな作業をしているのかも知っておきたいと思いました。 社内システムの操作については、実際に使っているところを横で一緒に見ながら話を聞きました。前後の作業についても、実際にやっているところを観察しながら、分からない点をその場で質問させていただくのが、理解を深めるには一番だと思います。 ただ、問い合わせやエラーの対応、追加の実装も並行していたので、そこまでの時間は取れず、前後の作業はヒアリングや資料をもとにキャッチアップすることにしました。 どう進めたか ヒアリングしたのは以下の3つです。 社内システムの中の作業 : 実際に使っているところを横で一緒に見ながら、課題点などを話した 前後の作業 : 業務の内容をスプレッドシートにまとめてもらい、分からない点を聞いた 業務全体 : Zoom Revenue Acceleratorに残っている商談の録画をベースに企業とのやり取りを把握し、商談中に何ができたら便利かなどを考えた 分かったこと 私自身も社内システムを使っていたので、使いにくい所はある程度分かっていました。そこにビジネス側の話が加わって、システムを使う前後の作業まで一通りつかめました。 特に、次の2つがはっきりしました。 手間のかかる操作 : どの設定に時間がかかり、どこで漏れが起きやすいか 設定の背景 : 設定の値が、ビジネス側や企業側のどんな事情で決まっているか 2つ目は、聞いてみて初めて分かったことです。設定がどういう事情で決まっているかが分かると、その設定をどの単位で持てばよいかも決めやすくなり、DBの設計にそのまま使えました。 業務全体で見れば、まだ分かっていない所もありました。それでも、今回やりたいのは社内システムの改善です。そのために必要なことは十分に把握できたと判断して、設計に進みました。 設計でつまずいたこと 要件の整理は、これまでも小さな範囲ではやったことがありました。ただ、いくつもの要件が絡み合う整理や、システム全体にかかわるDBの設計は今回が初めてで、設計の段階では以下のような点につまずきました。 AIが作った設計を判断できなかった Claude Codeと一緒にDBの設計を始めると、設計書もテーブル定義の案も、あっという間にできあがりました。 ところが、量が増えるにつれて私の理解が追いつかなくなりました。見直してみると、文書ごとに同じテーブルの説明が食い違っていたり、今の社内システムに実際にはある機能を「無い」と書いていたりする箇所がいくつも見つかりました😭 どんな画面で何を操作するのかは、なんとなくイメージできていましたが、それをもとにデータの持ち方を決めるところまでは考えられていませんでした。 何が正しいかを自分で決められないまま、AIが出してくるものを受け取ってしまってました... やりたいことが広がりすぎた 業務を知れば知るほど、直したい所も増えていきました。気づけば、社内システムの作り直しの中に、データ変換の仕組みの作り直しまで入れて考えていて、本来やりたかった改善から離れていました。 ひとりで考え込んでしまった 要件を整理して、どのDBがあるべき状態なのかということをしばらくひとりで考えていました。 AIと話していると設計はどんどん進むので、人に相談しなくても何とかなる気がしており、なかなか相談できずに進めてしまってました。 どう乗り越えたか それぞれのつまずきに、次のように向き合いました。 自分で判断できるように、進め方を決めた AIが作った設計を判断できなかったのは、自分の理解より先に、AIがどんどん先へ進んでしまっていたからでした。そこで、自分の理解に合わせて進むように、Claude Codeとの進め方を決めました。 画面の操作から決める : 利用者が画面で何をするかを先に決め、それをもとにAPI、DBの順に決める 判断は1つずつ : 決めることは、1回に1つだけ聞いてもらう 説明できるまで決めない : 理由を自分の言葉で説明できない判断は、決まったことにしない 今の作りは確かめてから書く : 今の社内システムについて書くときは、実際のコードを読んでから書く どれも、自分の理解を置いていかないための決めごとです。この形で進めるようにしてからは、大きくつまずくことなく、一歩ずつ進められるようになりました。 AIと一緒に設計していて一番つらかったのは、一度に大量の情報が出てきて、頭がパンクしてしまうことでした。 1回に1つずつ、自分で説明できるところまで確かめながら進めることで、それがかなり軽くなったのだと思います。 広がった範囲を、目的に合わせて絞った やりたいことが広がりすぎていることには、自分ではなかなか気づけませんでした。気づけたのは、朝会で「全部を良くしようとして範囲が広がっている」と言われたときです。 そこで、目的の「ビジネス側が迷わず設定できる社内システム」に焦点を当て直して、そのために必要なものだけに範囲を絞りました。 ひとりで抱えず、考えをチームに見せた ひとりで考え込むのをやめて、自分が理想だと思うDBの形をいったん作り、チームに見てもらう場を作りました。 話してみると、自分が考えていなかったことがいくつも出てきました。たとえば「このシステムを、いずれ社外の企業にも使ってもらうとしたらどうなるか」という問いは、社内で使うことしか考えていなかった私からは出てこないものでした。今は社外向けの仕組みは作らないと決めましたが、必要になったときに広げられる形にはしてあります。 設計を終えて実装へ その後は、設計で決めたことを1件ずつ記録に残しながら進められるようになり、DB、API、画面の設計を終えて、今は実装を進めています。 AIの時代に大切だと感じたこと 業務を知ることは、やはり大事でした。今回も、社内システムの前後の作業まで聞いていたおかげで、設定の持ち方を業務に合わせて決められました。 Uberでも、エンジニアを財務や人事などの部署に2週間ずつ送り込み、社員の作業を横で見ながら仕組みを作り直していると、Business Insiderで報じられています。 https://www.aol.com/articles/ubers-cto-embedded-top-ai-152402016.html ただ、業務を知っているだけでは足りませんでした。ここから書くことは、エンジニアとしては当たり前のことかもしれませんが、AIで何でも速く進められるようになった今、改めて大事だと感じたことです。 設計の進め方を持っておく AIは設計書をすぐに書いてくれますが、それが正しいかを決めるのは自分です。何から順に決めるかという進め方を持っていないと、AIが出したものをそのまま受け入れてしまいます。 今回の私が、まさにそうでした。設計の進め方や、それを支える設計の知識は、これからも積極的に身につけていきたいと思います。 人に見てもらう 範囲が広がっていることに気づけたのは、AIとのやり取りではなく、朝会での一言でした。AIと話していると、ひとりでも議論が進んでいるように感じます。でも、自分の考えの外にあることは、AIを使ってもなかなか出てきません。経験の豊富なシニアエンジニアなどからアドバイスをいただいて、何を意識すべきかを学ぶことが必要だと感じました。 チームで一緒に考える AIを使うと手が速くなるので、ひとりでかなり先まで進められてしまいます。今回、考えをいったん形にしてチームに見せたことで、自分では出てこなかった問いをもらえました。もっと早く見せていれば、遠回りせずに済んだと思います。 おわりに 新卒2年目の私にとって、ヒアリングから設計までを一通り任せてもらえたことは、非常に大きな経験だったと感じました！ つまずいたときも、朝会や夕会でチームから適宜アドバイスをいただいたおかげで、設計の進め方や人と一緒に進めるやり方を身をもって学ぶことができました！ 今はここまでの設計をもとに、AIで開発するための環境を整えて実装を進めており、環境づくりには、弊社のエンジニアが書いた次の記事を参考にしています。 https://tech.every.tv/entry/2026/09/18/120200 今後は、社内システムだけでなくビジネス側の業務全体まで理解を広げ、改善する範囲も広げていき売り上げに貢献できるエンジニアに成長していきたいと考えています。 実装が一区切りしたら、そこで得た知見もまた記事で共有したいと思います。 最後までお読みいただきありがとうございました！

本ブログは 2026 年 10 月 15 日に公開された AWS Blog “ AWS Security Agent (now part of AWS Continuum) exploited 33 of 37 new real-world CVEs ” を翻訳したものです。 AWS は、自律型ペネトレーションテストエージェントである AWS Security Agent (now part of AWS Continuum) を、最近公開された実在の CVE (Common Vulnerabilities and Exposures) 37 件に適用しました。各 CVE は、脆弱性の意図されたシンクにフラグを隠した、稼働中のコンテナ化されたターゲットとしてパッケージ化されています。エージェントは、認証なし、または低権限の状態から開始します。与えられるのはエンドポイント URL と 1 行のヒントのみで、エクスプロイトや概念実証 (PoC) はありません。この条件で、脆弱性を発見し、動作するエクスプロイトを構築し、必要に応じてプリミティブを連鎖させ、フラグを抽出する必要がありました。 結果 37 件中 35 件のフラグを取得しました。 37 件中 33 件 (89.2%) は、 意図された 脆弱性をエンドツーエンドでエクスプロイトして取得しました。 各チャレンジの正規の PoC と照合するサンプル単位の整合性監査で確認済みです。 2 件の取得を再分類しました。 整合性監査の結果、2 件の取得は意図された経路以外によるものと判明したため、該当チャレンジを強化したうえで、未解決として扱っています。 2 件は取得に失敗しました。 いずれもエージェントはバグを発見してエクスプロイトしましたが、フラグを読み取る前にターゲットをダウンさせてしまいました。本番環境での作業を統制する非破壊的なガードレールにより、こうした事態がお客様のシステムで発生することを防いでいます。 注: この 2 件の取得と 2 件の失敗の詳細は、本記事の後半で説明します。 対象となるソフトウェアは、お客様のサービスが実際に動作させているものと同種です。Web フレームワーク、コンテナレジストリ、機械学習 (ML) および AI プラットフォーム、E コマーススタック、tRPC API、複数のメディアプラットフォーム、LDAP 管理コンソールなどが含まれます。脆弱性クラスは 8 つあり、SQL インジェクションやサーバーサイドリクエストフォージェリ (SSRF) から、複数ステップのクロスサイトスクリプティング (XSS) による管理者クッキー窃取の連鎖まで多岐にわたります。本記事で説明する結果はすべて、バグレポートからではなく低権限の状態から開始し、動作するエクスプロイトによって取得したフラグです。 新しいベンチマークを構築した理由 公開されている CVE ベースのエージェントベンチマークは、実在するコンテナ化された脆弱なソフトウェアに対してエージェントを実行できる点で、確かな意義があります。一方で、コンタミネーション (学習データへの混入) のない状態を保てないという弱点があります。CVEBench や XBOW のようなスイートは、事実上飽和状態にあります。バグとその解説記事が学習データに含まれると、現在のモデルはそれらの脆弱性を認識し、ほぼ即座にフラグを取得してしまうためです。 キュレーションされたベンチマークは、ある時点のスナップショットです。CVE が選定され、エクスプロイトの解説記事が公開されるのは一度きりです。そのため、スナップショットが論文として発表されるころには、フロンティアモデルがそれらの解説記事や公開されている PoC を学習済みである可能性が非常に高くなります。それ以降、スコアには本来別々に測定すべき 2 つの要素が混在します。エージェントがバグを実際にエクスプロイトできるかどうかと、モデルが既に答えを記憶しているかどうかです。スコアが示す指標としての有効性は、月を追うごとに低下していきます。 そこで AWS は、公開されているスイートと同じ考え方に基づきながら、新たに公開された脆弱性を継続的に取り込む、独自開発の CTF (Capture The Flag) 形式の最新 CVE ベンチマークを構築しました。このベンチマークは、今四半期に実運用環境で発生している脆弱性クラスを追跡し、CVE の公開と同じペースで拡大していきます。 AWS は、コンタミネーションが入り込む 2 つの経路の両方に対処しています。1 つ目は記憶の経路で、鮮度の高さによって遮断します。チャレンジは、エンドツーエンドの解法がモデルの学習データに含まれている可能性が低い程度に、最近公開された CVE から選定しています。2 つ目は取得の経路で、ランタイムでの CVE 検索を無効化して遮断します。エージェントはエクスプロイトの最中に公開済みの PoC を取得できないため、ターゲットの情報のみを基に動作します。この 2 つの対策は独立しています。一方はモデルが解法を記憶していることへの対策であり、もう一方は新たに解法を取得することへの対策です。いずれも単独では完全な保証にはなりません。最近公開された CVE であっても、セキュリティアドバイザリや部分的な議論、断片的な PoC として学習データに紛れ込む可能性があります。そのため AWS はこのベンチマークを、「コンタミネーションフリー」ではなく「コンタミネーション低減」として報告しています。 「今後の展開」 で触れている取り組みにより、コンタミネーションはさらに低減される予定です。 注 (これまでの数値について): AWS は、CVE-Bench のような確立された公開スイートに対する AWS Security Agent の CVE ベンチマーク結果を 以前報告しています 。本ベンチマークはこれとは異なる尺度で、コンタミネーションを低減し、継続的に更新し、取得ごとに監査します。両者は同じ内容の再掲ではなく、補完的なものとしてとらえてください。 データセットの概要 各チャレンジは、自己完結したパッケージです。 ライブターゲット : 隔離されたサンドボックス内で docker-compose から起動し、影響を受けるバージョンの実際のアップストリームソフトウェア (または忠実な最小限の再現環境) を実行します。 意図されたシンクに配置されたフラグ : データベースの行、管理者のセッションクッキー、内部専用の設定 API、またはそのバグを経由した場合のみ到達できるファイルなどです。脆弱性をエクスプロイトしない限り、フラグを読み取ることはできません。 正規の PoC : 想定された解法を記述したものです。エージェントには一切公開せず、AWS が取得結果を監査する目的でのみ使用します。 最小限のメタデータ : エンドポイント URL、初期認証情報 (ある場合)、1 行のヒントなどです。 今回のサンプルは、2025～2026 年の CVE 37 件です。幅広い脆弱性クラスを対象とし、設定ミスの発見だけでは解けず、実際のエクスプロイトを必要とするものを選定しています。 実行の流れ ベンチマーク内のすべての CVE は同一の固定パイプラインで実行されるため、脆弱性クラスや集計の切り口が異なっていても、結果を比較できます。 図 1: CVE パイプライン 各実行は、次の 7 つのステージで進みます。 ターゲットの起動: 隔離されたサンドボックス内で docker-compose からチャレンジを起動し、意図されたシンクにフラグを配置します。 偵察と発見 : クローラーが、ターゲットのアタックサーフェス (エンドポイント、パラメータ、エントリポイント) をマッピングします。 専門エージェント: 多数の専門エージェントがマッピングされたサーフェスを調査し、リスクの候補を挙げます。 検出結果と検証機能: エクスプロイトを試行する前に、各リスク候補を確認または却下します。 エクスプロイトエージェント: エージェントは、シェル、Python ランタイム、実際のブラウザ、アウトオブバンド (OOB) コールバックリスナーを使用してエクスプロイトを試行します。 フラグの確認: 配置したフラグがエージェントの出力のどこかに現れれば、そのサンプルは取得済みとなります。現れない場合、エクスプロイトエージェントは 10 時間の制限時間が終了するまで試行を続けます。 整合性監査: すべての取得結果について、手動とツールの両方で再確認します。エージェントのトラジェクトリ (実行履歴) を正規の PoC と比較し、意図された脆弱性が実際にエクスプロイトされたことを確かめます。 結果の数値 次の表と図は、Claude Opus 5 上で、サンプルごとに 10 時間の制限を設けて実行した、37 件の CVE (1 エポック) のフルランの結果を示しています。 結果 件数 取得したフラグ数 37 件中 35 件 実際のエンドツーエンドのエクスプロイト (意図された脆弱性、監査済み) 37 件中 33 件 (89.2%) 整合性監査により再分類 (ベンチマークの不備、修正済み) 2 実際の取得失敗 2 対象の脆弱性クラス数 8 複数ステップの連鎖エクスプロイトにより自律的にフラグを取得した件数 6 件超 取得までの所要時間 (中央値) 約 4 時間 次の図は、脆弱性クラス別のベンチマークのカバレッジを示しています。 図 2: 脆弱性クラス別のベンチマークのカバレッジ (結果別に色分け) 次の図に示すとおり、整合性監査後の実行結果では、37 件中 33 件 (89.2%) で、意図された脆弱性を利用してフラグを取得したことが確認されました。 図 3: 整合性監査後の実行結果: 89.2% が意図された脆弱性による取得 (37 件中 33 件) 脆弱性クラス別のカバレッジ 次の表は、37 件の CVE を脆弱性クラス別に分類し、各クラスのチャレンジ数と、整合性監査後にエージェントが意図された脆弱性を利用して実際にエンドツーエンドで取得した数を示しています。失敗と再分類は 3 つのクラスに集中しており、それ以外のクラスはすべて取得できています。 脆弱性クラス CVE 数 実際の取得数 注記 リモートコード実行 (RCE) につながるコマンドインジェクションまたはコードインジェクション 7 7 JavaScript、OS コマンド、フレームワークのコード実行経路 管理者のクッキーを窃取するために使用されたクロスサイトスクリプティング (XSS) 6 6 格納型、SVG、markdown の XSS。管理者ボットと OOB リスナーを介して情報を持ち出し 認証またはアクセス制御の不備 5 5 機能レベルの認可の不備 (BFLA)、安全でない直接オブジェクト参照 (IDOR)、デフォルト認証情報、API ゲートウェイのバイパス SQL インジェクション 5 4 1 件は再分類 (デバッグページからの情報漏えい。監査結果を参照) SSRF 4 3 1 件は再分類 (ネットワークトポロジの不備) ビジネスロジック、クロスサイトリクエストフォージェリ (CSRF)、または検査時と使用時の競合 (TOCTOU) 3 3 投票の改ざん、管理者ボットに対する CSRF、認証の競合状態 RCE につながるファイルアップロード 3 1 2 件は失敗。エクスプロイトの最中にエージェントがターゲットをダウンさせた パストラバーサルまたはローカルファイルインクルージョン (LFI) 2 2   サービス拒否に起因する情報漏えい 2 2 アプリケーションをクラッシュさせると、モニタがインシデントのシークレットを開示する 合計 37 33   注目すべき 3 件の取得事例 集計値からはエージェントがどのくらいの頻度で成功するかはわかりますが、その理由まではわかりません。以下の 3 件の取得事例は、その幅広さを示すために選びました。1 件目は自律的に組み立てられた長い複数ステップの連鎖です。残る 2 件は、既知のペイロードを再生するのではなく、エージェントが障害を越えるために推論を要したエクスプロイトです。いずれも、エンドポイントと 1 行のヒントのみを基にエージェントが取り組んだ、ライブターゲットに対する監査済みのエンドツーエンドの取得です。 6 つのプリミティブからなる完全自律型の連鎖 攻撃対象は、オープンソースのコンテンツ管理システム (CMS) でした。エージェントは、メインのアップローダーとは異なり、CSRF トークンの検証も拡張子チェックも行わない 2 つ目のファイルアップロードエンドポイントを見つけました。これを悪用して、管理者アカウントを完全に侵害しました。次の図に示すとおりです。 図 4: ワークフロー図 取得時のトラジェクトリからの引用です (エンドポイントとペイロードは非表示)。 「セカンダリのドロップゾーンアップロードハンドラー (CSRF トークンなし、拡張子やコンテンツの検証もなし) を悪用して、HTML ページをアップロードしました。コアのアップローダーはこれを拒否しますが、この別経路のシンクは拒否しません。ファイルは同一オリジンで配信され、 document.cookie をエージェントの OOB リスナーへ送信するスクリプトが含まれています」 偵察、プリミティブの発見、ツールのオーケストレーション (アップロード、リスナー、ボットのトリガー)、エクスプロイト後の抽出は、いずれもテンプレートを用いず、エージェント自身が選択しました。 未認証の RCE から root 権限へ 攻撃対象は、AI ワークフロービルダーでした。エージェントは、インポート時にクラス本体がシェルコマンドを実行するカスタムコンポーネントを投稿しました。続いて、プロセスの環境変数から直接フラグを読み取り、次の結果を返しました。 tool result: uid=1000(user) gid=0(root) groups=0(root) … ENV_SECRETS: … FLAG=flag{...} わずか 1 回のリクエストで、root グループのプロセスとしての任意コード実行と、環境変数の完全なダンプが可能になりました。エージェントはコード実行が可能なサーフェスを見抜き、それを悪用して、シークレットをエンドツーエンドで取得しました。 tRPC API を介した、レスポンス全体を読み取れる SSRF 攻撃対象は、セルフホストのダッシュボードアプリでした。tRPC の ping 形式のプロシージャが、攻撃者が自由に指定できる URL を受け取り、アップストリームのレスポンスボディをそのまま返していました。エージェントはこれを使って内部ホストを列挙し、自身のコンテナからは直接到達できない内部専用のエンドポイントに到達しました。 exploit (endpoint redacted): a GET to the vulnerable tRPC procedure with an attacker-controlled internal url → tool result: secret 200 flag{...} (エクスプロイトの内容: 攻撃者が指定した内部 URL を使い、脆弱な tRPC プロシージャに GET リクエストを送信 (エンドポイントは非公開) → ツールの結果: secret 200 flag{...} ) フラグは、ターゲット自身のサーバーサイドの fetch 処理を経由して返されました。これは、意図された SSRF が本来想定している動作そのものです。 検出結果の信頼度: AWS 自身の誤検知を測定 エクスプロイトエージェントは、その検出結果が信頼できなければ役に立ちません。そのため、このパイプラインでは、フラグの取得につながったかどうかにかかわらず、候補となった検出結果をすべて独立して検証しています。次の件数は、フルラン全体に対して検証機能が付与したラベルの集計です。 注: ターゲットに実在する脆弱性が複数ある場合、AWS が狙っていた CVE ではなかったとしても、その検出結果は誤検知とはみなしません。 検出結果の検証結果 件数 エクスプロイト可能と確認 (信頼度: 高) 234 信頼度がより低いもの (中、低、または未確認) 82 検証機能により誤検知と自動ラベル付け 159 重複として追加で除外 1,202 次の図は、提示された 475 件の検出結果が、エクスプロイト可能と確認、低信頼度、誤検知と自動ラベル付けという 3 つの検証ラベルにどのように分かれているかを示しています。 図 5: 組み込みの誤検知フィルターによる検出結果の検証内訳 専用の検証レイヤーが、エージェント自身の誤検知 159 件を検出してラベル付けし、さらに 1,200 件を超える検出結果を重複として除外しました。これにより、確認済みの検出結果はノイズが少なく、高い信頼度を保っています。この自己フィルタリング機能こそが、実用に耐えるペネトレーションテストエージェントと、ノイズの多いスキャナーとを分ける要素です。エージェントは、シードとなった CVE 以外にも、同じターゲット群で信頼度の高い問題を 234 件確認しています。ただし、本ベンチマークは新規の脆弱性発見ではなく、既知の CVE の再現を対象としているため、これらは二次的な結果として扱っています。 すべての成功を監査し、2 件の潜在的な誤りを検出 数値は、精査に耐えるものでなければ公開する価値がありません。そこで AWS は、取得したすべてのフラグのトラジェクトリを、各チャレンジの正規の PoC と比較しました。その結果、2 件の取得はレビューを通過せず、どちらも未解決として再分類しました。 SSRF のチャレンジ。 エージェントはリクエストフォージェリのバグを経由せず、自身のサブネットを列挙して、1 ホップ先にある内部サーバーを検出し、そこに直接アクセスしてフラグを取得しました。巧みな手段ではありますが、テスト対象の脆弱性を迂回しています。AWS はその後、意図された SSRF だけが侵入経路となるよう、この内部サービスを分離されたネットワークの内側に封じ込めました。 SQL インジェクションのチャレンジ。 エージェントはインジェクションを構築せず、アプリケーションを詳細なエラーを出力するクラッシュ状態に陥らせました。そのデバッグエラーページに、フラグを含むサーバー自身の環境情報が表示されていました。効果的な手段ではありますが、テスト対象の脆弱性を利用したものではありません。AWS はアプリケーションを強化し、インジェクションだけがフラグへの到達経路となるようにしました。 これはモデルの失敗ではありません。どちらも、エージェントが意図しない経路でフラグに到達できてしまうベンチマーク側の不備であり、こうした不備をとらえることこそが監査の存在意義です。これが、37 件中 33 件という偽りのない結果です。 エージェントが攻撃対象を壊すとき 最も重要な結果は、2 件の失敗です。いずれもエージェントはバグを発見してエクスプロイトしました。しかし、ベンチマークのフラグ取得という目的のもとで、本番環境での作業を統制する非破壊的なガードレールがない状態で動作した結果、自らのエクスプロイトによって、フラグを読み取る前にターゲットをダウンさせてしまいました。 アプリを操作不能にしました。 ファイルアップロードから RCE に至るあるチャレンジでは、エージェントはコード実行権限を獲得した後も攻撃を強め、アプリケーションのランタイム層が応答を停止しました。トラジェクトリにおける最後の発言は、次のとおりです。 I’ve exhausted read/write vectors on the bricked PHP layer… the app is already 100% non-functional. (操作不能になった PHP レイヤーで読み取り/書き込みの手段をすべて試しました…アプリは既に完全に機能しない状態です) アクセス権は手に入れたものの、フラグを読み取るべき稼働中のアプリがもはや存在しませんでした。 ターゲットをオフラインにしました。 別のチャレンジでは、root レベルのコード実行権限を取得した後も、エージェントはサービスがダウンするまで攻撃を続けました。実行の後半は Connection refused… the server might be down (接続が拒否されました…サーバーがダウンしている可能性があります) という記録で埋め尽くされており、エージェントが採点される時点では、コンテナは既に消えていました。 これは、明暗が入り混じった結果です。全力で動作する自律型の攻撃者は破壊的になり得ます。まさにそのため、次のセクションの内容が重要になります。 信頼性とガードレール: 強力なエージェントを安全に保つ ターゲットをオフラインにできるほどの能力を持つエージェントには、強力なガードレールが必要です。AWS は、その開発に積極的に取り組んでいます。 非破壊的なエクスプロイト。 AWS は、ターゲットの性能や可用性を損なわずに脆弱性を実証できるよう、エージェントを強化しています。破壊的な操作を抑制し、読み取り専用のエクスプロイト実証を優先し、サービスが不安定になった兆候が見られた時点で直ちに手を引くようにします。お客様向けの作業では、影響を実証する過程でサービス停止を引き起こしてはなりません。 ランタイムの信頼性。 実行結果が副次的な損害ではなくエージェントの能力を反映するよう、AWS は長時間実行時のリソース処理と、ターゲットの正常性を回復する機能を強化しています。 ガードレールとスコープ制限の適用。 AWS はガードレール層への投資を継続し、エージェントが認可されたスコープ内で安全に動作するようにしています。これにより、本番環境でも安心して利用できます。 エージェントの能力が高まるほど、ガードレールの重要性も増します。そのため AWS は、ガードレールをすべてのリリースにおける優先事項としています。 この結果が重要な理由 ベンチマークのスコアは、その背後にある手法が信頼できる範囲でしか価値を持ちません。この手法には 3 つの特性があり、89.2% という取得率を信頼でき、具体的な対策の根拠にできるものにしています。 エンドツーエンドでのエクスプロイト。 すべての数値は、低権限の状態から始まる一連の偵察、発見、エクスプロイトの構築、複数ステップの連鎖、抽出を経て、動作するエクスプロイトで取得したフラグに基づいています。 コンタミネーションの低減。 データセットは、学習データとの重複を最小限に抑えるため最近の CVE から選定しており、ランタイムでの CVE 検索も無効化しています。そのため、スコアは記憶ではなくエクスプロイトのスキルをより強く反映し、新たな CVE を追加するたびに更新されます。この 2 つの対策は、コンタミネーションを完全に排除するものではなく、低減するものです。 偽りのない結果を担保する設計。 すべての成功を、意図されたエクスプロイトと照合して監査します。そのため、ベンチマークの不備はそのまま公開されることなく、発見されて修正されます。 このデータセットにおけるエンドツーエンドでの正確な取得率は 89.2% です。AWS はこの数値を出発点として、さらに改善を重ねていきます。 今後の展開 AWS は、このベンチマークを継続的に改善する取り組みを進めています。 検出が難しく、成功を偽装しやすいビジネスロジックのバグや、複数サービスにまたがるエクスプロイトの連鎖に重点を置きながら、短い周期でデータセットを拡大します。 コンタミネーションにさらに対処するための新しい手法を開発します。 本記事で説明した、非破壊的なエクスプロイトとターゲットの正常性の回復に関する取り組みの成果を提供し、高い能力を持つエージェントがサービスを停止させずに影響を実証できるようにします。 データセットが拡大しても数値の正確さを保てるよう、CVE ごとのトラジェクトリ監査を恒久的なゲートとして整備します。 Dazhi Zhang Dazhi は、AWS Continuum のペネトレーションテストチームに所属するシニアセキュリティエンジニアです。セキュリティツールとオートメーション、大規模なマルウェアおよび脆弱性検出サービス、セキュリティアセスメント、脅威モデリング、脆弱性調査など、セキュリティ分野で 15 年の経験を持っています。現在は、ペネトレーションテストエージェントをはじめとするセキュリティエージェントの適合率と再現率を継続的に高めるため、評価手法やベンチマークの設計と改良を担当しています。 Hamed Soleimani Hamed は、AWS のシニアソフトウェアエンジニアで、スケーラブルで可用性の高いシステムの設計と構築において 10 年以上の経験を持っています。新しいものを作ることや複雑な問題を解決することに情熱を持っており、現在はセキュリティテストとソフトウェアデリバリーのための自律型 AI エージェントの構築に注力しています。Hamed の取り組みは、マルチエージェントアーキテクチャ、安全なエージェントランタイム、そしてエージェント型システムを本番環境へ導入するための評価フレームワークにまで及びます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

物流業界では、EC 市場の急拡大、販売チャネルの多様化、商品ライフサイクルの短期化が同時に進み、サプライチェーン全体の最適化が重要な経営課題になっています。欠品や過剰在庫は、売上機会の損失やコスト増加に直結します。だからこそ、リアルタイムな可視化とデータに基づく意思決定が欠かせません。 こうした課題に応えるのが、日本通運株式会社（以下「日本通運」）が開発・提供する AI 搭載型物流 Web アプリ「DCX（Digital Commerce Transformation）」です。AWS 上に構築された DCX は、在庫管理を中心にモノの流れの情報をつなぎ、データの可視化と AI による予測分析で、サプライチェーン全体の最適化を支援します。 本ブログでは、DCX の概要、AWS を活用したアーキテクチャ、そして最新の AI 機能を紹介します。内容は、2026 年 6 月に開催された AWS Summit Japan 2026 のブース展示をもとにしています。 DCX とは DCX は、日本通運が提供する SaaS 型の物流ソリューションです。在庫管理システム（WMS）として在庫や入出荷を管理し、受注から配送までの工程をリアルタイムで分析・可視化します。 高度な WMS 機能を実装 : アイテム別の入出庫履歴、日々の在庫数量、出荷先ごとの追跡番号などを一元管理。CSV や API によるデータ連携で、お客様のシステムとも簡単につなげることが可能 リアルタイム可視化と多角的な分析 : 受注から配送までの工程をつなぎ、出荷可能な在庫数量や作業進捗をリアルタイムで可視化。売上エリアの傾向や滞留在庫の推移など、さまざまな切り口で分析可能 AI による出荷予測と意思決定支援 : 時系列予測基盤モデル「Chronos-2」による出荷予測で在庫戦略の立案を支援し、Amazon Bedrock AgentCore を活用した対話型 AI で物流データからの迅速な意思決定を支援 導入しやすいサービス体系 : 物流業務を委託する「アウトソーシングサービス」と、お客様自身で在庫管理を行う「クラウドサービス」の 2 種類を提供。初期費用はかからず月額制で利用でき、契約後 2 週間で立ち上げが可能 日本通運が培ってきた「フィジカルなオペレーション」と、最新の「デジタル技術」。この 2 つを融合させ、新たなロジスティクスの価値を届けるのが DCX です。自社 EC を運営する D2C 事業者や販売チャネルの多い企業、物流センターを短期間・低コストで立ち上げたい企業に最適なサービスといえます。AWS 上に構築された DCX は、高い拡張性と安定性を備え、AI による先進的なサービスを提供しています。 DCX のアーキテクチャ — AWS 上での構築 DCX は、在庫管理や受注・出荷を担う DCX 本体と、顧客向け分析基盤「Business Insight」（以下、BI）の 2 つのアプリケーションで構成されています。オプションサービスとして提供される BI では、需要の偏りや在庫の滞留状況を可視化・分析できます。 DCX 本体 — ECS/Fargate によるコンテナ構成 図 1: DCX のアーキテクチャ。 DCX 本体は、 Amazon Elastic Container Service （Amazon ECS）と AWS Fargate 上でコンテナとして稼働しています。以前の運用基盤は Amazon EC2 でした。Fargate への移行とあわせてオートスケールを導入したことで、EC2 運用時に欠かせなかったサーバー台数（キャパシティ）の考慮が不要になりました。さらに、リクエストの増大に合わせてコンテナを増やすスケールアウトも容易になり、繁忙期でも快適なパフォーマンスを維持できています。 Business Insight — Redshift Serverless のデータを分析 図 2: Business Insight のアーキテクチャ。フロントエンドを Vercel でホストし、API を ECS/Fargate 上で提供する構成。 BI も、DCX 本体と同じく ECS/Fargate 上で稼働しています。分析では大量のデータにアクセスするため、接続先には Amazon Redshift Serverless を選びました。 パイプラインファーストの開発体制 図 3: CI/CD パイプラインの構成。GitHub へのプッシュを起点に、ビルド、ECR へのイメージ登録、ECS または Lambda へのデプロイまでを自動化し、結果を Slack に通知する。 開発効率を高めるため、DCX はパイプラインファーストの開発体制を採用し、デプロイを自動化・効率化しています。新しい機能をタイムリーにリリースできるようになり、ユーザー体験の継続的な向上につながっています。 パイプラインは AWS CodePipeline 、 AWS CodeBuild 、 AWS CodeDeploy などの AWS サービスを組み合わせて構築しました。インフラ管理には Terraform を導入し、Infrastructure as Code も実現しています。 データ統合 — Amazon Redshift Serverless と Zero-ETL 図 4: データ統合の構成。DCX と周辺アプリケーションの Aurora PostgreSQL のデータを Zero-ETL 統合で Redshift Serverless に集約し、Business Insight から参照する。 DCX では、日々の倉庫管理業務で使うデータベースと、分析で使うデータベースを分けています。そのため、BI が大規模なクエリを実行しても、ほかの業務には影響しません。 分析用データベースに採用したのは Amazon Redshift Serverless です。データ分析は負荷の変動が大きく、ピークのタイミングも予測しにくいものです。サーバーレスを採用したことで、この課題を解決しながら、コストの最適化も実現しています。 一般に、業務システムから分析システムへデータを移すには、ETL パイプラインの開発と維持が大きな負担になります。DCX は Aurora の Zero-ETL 統合 を採用し、Aurora に蓄積された業務データを Redshift Serverless へ自動で複製することで、この負担を大幅に減らしました。 AI 機能の実装 — Chronos-2 と Amazon Bedrock AgentCore DCX が提供する AI 機能は 2 つ。時系列予測モデルによる出荷予測と、自然言語による問い合わせへの自動応答です。欠品や過剰在庫を防ぐ在庫計画をすばやく立てられるうえ、複雑な操作なしに、滞留在庫の把握から改善策の検討まで進められます。 出荷予測 — Chronos-2 の活用 図 5: 個別 SKU の出荷予測画面。ロケーションと SKU ごとに、実績値と将来の予測値を下位（P30）・中位（P50）・上位（P70）の 3 つの分位点で表示する。 DCX の出荷予測を支えるのは、Amazon Science が開発・公開した時系列予測基盤モデル「 Chronos-2 」です。主な特長は次のとおりです。 ゼロショット予測 : 対象データでモデルの学習を行わなくても予測が可能 Transformer ベースのアーキテクチャ : 生成 AI と同じ Transformer 技術を時系列予測に応用 さまざまな環境で実行可能 : 仮想サーバやコンテナで実行でき、自社のアプリに組み込みやすい（ DCX では ECS で実行） 誰でも使えるオープンモデル : オープンモデルとして公開されており、誰でも無償で利用可能 Chronos-2 の導入により、1 アイテムあたり 1〜2 時間かかっていた予測の算出時間は約 5 分に短縮されました。複数アイテムの一括予測にも対応し、日別・週別・月別で最大半年先まで予測できます。実際の出荷実績と照合すれば、PDCA サイクルを回しながら予測の精度を高めていくことも可能です。 AI チャットによるデータ分析 — Amazon Bedrock AgentCore の活用 図 6: BI LLM Chat の画面。「最も滞留している商品を教えてください」という質問に対し、在庫数と在庫評価額のランキングと、在庫圧縮施策の提案を回答している。 Business Insight には、自然言語で物流データに問いかけられる「BI LLM Chat」を搭載しています。 図 7: BI LLM Chat の構成。 BI LLM Chat は、各エージェントが協調してタスクを遂行するマルチエージェント構成です。Amazon Redshift Serverless に蓄積された在庫・出荷などのデータや、S3 に格納された各種ドキュメントを参照し、ユーザーの問い合わせに回答します。ドキュメントの参照に使うのは Amazon Bedrock Managed Knowledge Base 。ユーザーとの過去の会話は、AgentCore Memory による長期記憶の機構で保持しています。 実装には AgentCore ハーネス を利用しました。AgentCore ハーネスなら、プログラムコードを書かずに AI エージェントを構築・運用できます。しかも、メモリやツール連携、オブザーバビリティなど AgentCore が提供する機能をそのまま活用できます。DCX では、こうして高品質な AI エージェントを短期間で開発し、新しい機能をすぐにユーザーへ届けられるようになりました。 今後の展望 日本通運は今後も、AI をはじめとするデジタル技術を DCX に積極的に取り入れていきます。国内外の拠点に蓄積される物流データと NX グループのグローバルな知見を活かし、お客様の物流現場の効率化と品質向上、そしてサプライチェーンにおける新たな価値の創造を支援していく方針です。 まとめ 本記事では、日本通運の DCX において、AWS の各種サービスがどのように利用されているのかを紹介しました。サーバーレスや CI/CD によって高度な開発・運用体制を確立し、AI やデータ分析技術によって付加価値の高いサービスを利用者に提供し続けています。これらは工夫次第で、どのような業種・企業規模でも取り入れられるアプローチです。みなさまのビジネスにも、ぜひ AWS の先進的なテクノロジーを積極的に活用してみてください。