本ブログは 2026 年 9 月 9 日に公開された AWS Blog “ The state of AI for security: Measuring what matters most for building trust ” を翻訳したものです。 セキュリティチームは、脆弱性のトリアージ、ペネトレーションテスト、脅威モデリング、インシデント対応、コードレビューといったセキュリティ業務に AI を積極的に活用し始めています。期待されるのはスピードですが、処理が速くても誤検出 (false alarm) が多すぎるセキュリティツールでは、結果として時間の節約になりません。エンジニアは誤検出の対応に時間を取られ、オンコール対応のノイズが増え、チームは本当に重要な検出結果まで信頼しなくなります。 本日 (2026 年 9 月 9 日)、AWS はこの信頼の問題を直接測定するために設計された初のベンチマーク、Deception Benchmark を公開します。このベンチマークは、実際の脆弱性と、危険に見えても本当は安全なコードをモデルが区別できるかどうかをテストします。収録されているのは、16 のプログラミング言語、70 を超える Common Weakness Enumeration (CWE) カテゴリにわたる 14,822 個のサンプルです。AWS は 5 社のプロバイダーの 12 モデルを評価し、データセットとホワイトペーパーをコミュニティに公開します。これまでに公開されてきた他のベンチマークは、AI が脆弱性を発見または悪用できるかどうかを測定するものです。実際の脆弱性と誤検出を見分けられるかどうかを測定するのは、本ベンチマークが初めてです。標準的なプロンプトでは、実際の脆弱性と誤検出を区別する適合率 (precision) は 50% 台半ばにとどまりました。正確である確率と不正確である確率がほぼ同程度ということです。 攻撃側のタスクでは、エクスプロイトが成功するかしないかという明確な結果が得られることが多くあります。一方、防御側のレビューは攻撃側のタスクよりも検証が難しく、緩和策によって問題が悪用不可能になっていても、モデルは疑わしいパターンだと認識してしまう場合があります。実運用で役に立つシステムには、コード、緩和策、さらに場合によっては周辺の環境まで踏み込んで推論する力が求められます。 測定のギャップ コミュニティはセキュリティ評価の分野で着実に進歩してきました。 CyberGym は 1,500 を超える現実的なタスクでエージェントをテストします。 Meta の CyberSecEval と CyberSecEval 2 はエクスプロイトの生成能力を測定します。 CYBENCH は Capture the Flag (CTF) 課題を評価します。 SEC-Bench と VulnBench は、より実務に近いセキュリティワークフローの再現を目指しています。 最近の研究は、進歩とギャップの両方を裏付けています。 ExploitGym は、AI がクラッシュから実際に動作するエクスプロイトへ発展させられるかを測定します。 Microsoft の Project Perception は、継続的な防御のためにマルチエージェントのレッド/ブルー/グリーンチームをデプロイします。 OpenAI の GPT-Red は、セルフプレイによるレッドチーミングが、フロンティアモデルでも防御できない新種の攻撃を見つけ出すことを示しました。その後、 OpenAI は、同社の GPT-6 Astra モデルがサイバーセキュリティ能力の Critical しきい値を超えたことを公表しました。また OpenAI と Anthropic の双方が、評価中にモデルが本番システムへ不正アクセスしたインシデントを報告しています。攻撃側は急速に進展しています。しかし、これらの研究はいずれも、防御側の適合率を測定していません。つまり、AI システムがコードを脆弱だとフラグ付けしたとき、その判断がどれくらいの頻度で正しいかという問いには答えていません。 Deception Benchmark のご紹介 14,822 個のサンプル、16 言語、70 を超える CWE カテゴリ。安全なサンプルがモデルを欺くように設計されていることから、AWS はこれを Deception Benchmark と名付けました。実際の脆弱性パターン、実際のフレームワーク、実際のイディオムを備えたうえで、エクスプロイトパスを目立たない形で閉じる緩和策が組み込まれています。目標は、ヒントなしでコードを脆弱または安全に分類することです。 ユーザー入力を受け取ってデータベースにクエリを実行する Flask エンドポイントを考えてみましょう。モデルはこのコードに SQL インジェクションのパターンを見いだしますが、クエリはパラメータ化されたステートメントを使用しているため、エクスプロイトパスは閉じられています。シングルターンの分類器はパターンをフラグ付けしてそのまま次へ進み、エクスプロイトが実際に成立するかどうかを確認しません。実運用のツールはこれを補うためにマルチステップのループやエージェント型ワークフローに頼りますが、このようにモデルを外側から支える補助構造 (スキャフォールディング) は、モデル自体がコードを理解しているかどうかを覆い隠してしまいます。本ベンチマークはスキャフォールディングを取り払い、モデルに 1 回の処理で判断を求めます。測定対象となるのは理解力そのものであり、モデルを繰り返し呼び出す仕組み (ハーネス) が何回試行して正解に到達したかではありません。 すべてのサンプルは、生成、フロンティアモデルに対するテスト、強化、反復という敵対的なループを通じて構築しました。モデルが簡単に正解できるサンプルは残りません。その結果として得られたのは、フロンティアの水準に合わせて、それを下回らないように調整されたベンチマークです。この方法での構築にはコストがかかります。サンプルの生成と強化には数百億トークンを消費しました。コミュニティが同じコストを繰り返さずに済むよう、AWS はその成果を公開します。 本ベンチマークは 2 種類の課題で構成されます。コードレベルの課題 (6,988 サンプル) は、わずかな修正だけが異なる脆弱なバリアントと安全なバリアントを提示します。どちらも疑わしく見えますが、悪用可能なのは一方だけです。環境依存型 (environment-gated) の課題 (2,707 サンプル) はさらに踏み込み、同じコードに異なるデプロイのコンテキストを与えます。Kubernetes Network Policy がサーバーサイドリクエストフォージェリ (SSRF) のパスをブロックする、あるいはアイデンティティおよびアクセス管理の境界が権限昇格を防ぐ、といった具合です。パターンはソースコード上で見えていますが、インフラストラクチャによって悪用不可能になっています。モデルは、どちらのシナリオが当てはまるかを見極めなければなりません。 すべてのサンプルは本ベンチマークのために専用に作られており、実世界のパターン、実際のフレームワーク、実際の CWE、実際のインフラストラクチャに基づいています。知的財産上の懸念やトレーニングデータの汚染もありません。 LLM と人間を組み込んだループで作る大規模な高品質データ この規模で信頼できるラベルを生成するのは困難です。人間によるものであれモデルによるものであれ、1 回だけの作業ではスコアをゆがめるエラーが残ります。そこで AWS は、ラベル付けを一度限りの工程ではなく、収束型の監査ループとして扱っています。すべてのラベルは複数の独立したレビュアーが再検証します。レビュアーには、他のレビュアーの判断も、そのラベルを生み出した元の推論も知らされません。意見の不一致は直接裁定へエスカレーションされ、そこで元の推論が、提起された異議と照らし合わせて評価されます。それでも解決しないケースは人間によるレビューへ回します。AWS は、採点対象セットが不一致のしきい値を下回って収束するまでこのループを繰り返します。具体的には、独立レビューで異議が残るサンプルを 3% 未満とし、人間の裁定を経ても異議が残るサンプルは 1% 未満を目標とします。この方式の妥当性を担保しているのは、1 つの選択です。AWS は異議のあるサンプルにラベルを付け直しません。レビュアーの意見が一致しない場合、そのサンプルは修正ラベルを与えられるのではなく非採点プールへ移されます。つまり、誤った異議によってサンプルが除外されることはあっても、採点対象セットに誤ったラベルが持ち込まれることは決してありません。 採点対象サンプルから無作為に抽出した 100 件を人間がレビューした結果、ラベルの誤りは見つかりませんでした。プロセスの全体像は ホワイトペーパー で説明しています。 結果 本ベンチマークはおおむねバランスが取れており、半分が脆弱、半分が安全です。したがってランダムな分類器のスコアは 50% になります。AWS は 2 つのエラー率を個別に報告します。両者は正反対の方向の誤りを表すためです。偽陽性率 (false positive rate、FPR) は、モデルが安全なコードを脆弱だとフラグ付けする頻度です。これがエンジニアの時間を浪費する誤検出です。偽陰性率 (false negative rate、FNR) は、実際の脆弱性を見逃して安全だと判断する頻度です。正解率だけを見ていると、この違いは見えません。すべてを脆弱とラベル付けするモデルは、あらゆるバグを検出できる (FNR は 0%) 一方で、すべての安全なコードをフラグ付けし (FPR は 100%)、それでもスコアは約 50% になります。AWS は、FPR 10% 未満かつ FNR 10% 未満を本番利用の最低基準と考えています。 図 1: 2 つのプロンプト戦略における 12 モデルの FPR と FNR の比較。この緩やかな基準にすら到達したモデルはありません。 モデル プロンプト 正解率 FPR FNR GPT-5.6 Sol Direct 54.9% 92.5% 0.9% GPT-5.6 Sol PoE 58.9% 58.6% 23.1% GPT-5.5 Direct 56.9% 87.8% 1.3% GPT-5.5 PoE 62.9% 63.6% 12.4% GPT-5.4 Direct 60.2% 81.0% 1.5% GPT-5.4 PoE 77.7% 10.1% 33.6% Llama 3.3 70B Direct 58.8% 84.2% 1.1% Llama 3.3 70B PoE 72.2% 10.2% 44.2% Claude Haiku 4.5 Direct 55.6% 92.1% 0.0% Claude Haiku 4.5 PoE 75.6% 22.4% 26.3% Claude Opus 4.6 Direct 55.9% 91.3% 0.1% Claude Opus 4.6 PoE 75.8% 42.7% 7.0% Claude Opus 4.7 Direct 58.3% 85.5% 0.9% Claude Opus 4.7 PoE 75.9% 32.0% 16.8% Claude Opus 4.8 Direct 53.8% 95.7% 0.2% Claude Opus 4.8 PoE 75.8% 32.5% 16.4% Claude Opus 5 Direct 77.3% 41.5% 5.2% Claude Opus 5 PoE 79.3% 24.9% 16.8% Claude Sonnet 5 Direct 62.9% 74.7% 2.2% Claude Sonnet 5 PoE 74.7% 31.8% 19.2% Amazon Nova 2 Lite Direct 56.3% 89.2% 1.2% Amazon Nova 2 Lite PoE 70.1% 45.2% 15.5% Mistral Large Direct 52.2% 99.0% 0.0% Mistral Large PoE 65.5% 49.3% 20.6% テストした汎用フロンティアモデルの中で、本ベンチマークにおいて FPR と FNR の両方を 10% 未満に抑えられた構成はありませんでした。 どのモデルにも同じ失敗パターンが見られます。Direct プロンプトでは、実際の脆弱性を最大 95% 検出する一方で、安全なコードの 41～99% もフラグ付けしてしまいます。適合率は 52～71% の範囲で、多くは 50% 台半ばに集中しており、実質的に正確である確率と不正確である確率が同程度です。モデルは脆弱性パターンを見つけた時点で推論をやめてしまうのです。エクスプロイトの実証を求める Proof-of-exploit (PoE) プロンプトを使うと、偽陽性率は 17～74 ポイント下がりますが、実際の脆弱性の 7～44% を見逃します。環境依存型の課題ではさらに悪化し、モデルはコードをフラグ付けする一方で、その隣にある Kubernetes Network Policy を無視します。テストしたどの構成も、偽陽性率と偽陰性率の両方を 10% 未満に抑えることはできませんでした。 これらの結果は、汎用モデルをシングルターンのプロンプトで評価したものです。特定の目的に合わせて構築され、マルチステップの検証とツール利用を組み込んだシステムは、動作条件が異なり、今回の測定対象には含まれていません。ハーネスがパターン認識と真の理解の間のギャップを埋められるのであれば、本ベンチマークはそれを実証する場になります。ただし、既に埋められていると考える前に、2 つの注意点があります。1 つは、エージェント型の検証が実証されているのは主に攻撃側のタスクであり、そこでは成功を確認できるという点です。エクスプロイトが動作するか、しないかがはっきりします。一方、コードが安全だと判断する場合には、そのように正否を確認できる基準 (オラクル) がありません。もう 1 つは、イテレーションを追加しても、脆弱性がないことを確認できるわけではなく、同じ判断を再サンプリングするだけであり、ハーネスは依然としてベースモデルの理解力を引き継ぐという点です。モデルが 1 回の処理で有効な緩和策と無効な緩和策を区別できないなら、処理の回数を増やしても足りない知識が補われることはありません。本ベンチマークが測定しているのはまさにこの点、つまりコードを理解するモデルの本質的な能力です。それを、スキャフォールディングがギャップを覆い隠せないシングルターンのベースラインでテストしています。 現在 AI ツールを評価しているセキュリティチームの方は、脆弱性を発見できるかどうかだけでなく、この種のタスクでシステムがどの程度の性能を示すのか、どのくらいの頻度で誤るのかをベンダーに確認してください。そして、リスクの高いコードパスでは AI 支援によるレビューを必ず人間による検証と組み合わせ、Deception Benchmark を活用してツールの性能を客観的に検証してください。 提供状況 AWS は、この問題を再現可能な方法で容易に測定できるよう Deception Benchmark を構築しました。公開リリースには、サンプルと評価ワークフローが含まれます。ラベルは公開しません。これにより、ベンチマークが単なる暗記の問題になることなく、提出物を長期にわたって一貫して採点できます。 14,822 個のサンプルのうち 9,695 個が採点対象で、残りの 5,127 個はホールドアウト (非採点) として他のサンプルに混在させています。目的は明快です。システムそのものを改善するよりも、ベンチマークのスコアだけを最適化するほうが難しくなるようにすることです。この設計については、ホワイトペーパーでさらに詳しく説明しています。 Deception Benchmark は GitHub で公開しており、 ホワイトペーパー および検証を伴う採点を受けるための提出手順も併せて提供しています。セキュリティツールを開発している方は、データセットをダウンロードし、ご自身のシステムをベンチマークに対して実行し、採点評価のために予測結果を提出できます。 Anshumali Shrivastava Anshumali は Amazon Scholar であり、ライス大学のコンピュータサイエンス正教授です。動的スパース性、スケッチング、ハッシングに関する研究を通じて、現在では効率的な LLM のトレーニングと推論の中核となっている技術を切り開きました。ThirdAI (ServiceNow が買収) と XMAD.ai (Workato が買収) の 2 社を創業した経験を持ち、コンピュータサイエンスの理論と大規模な実用 AI システムの架け橋となっています。 Neha Rungta Neha は科学者かつビルダーであり、複雑なシステムについて機械が大規模に推論できるようにすることに、キャリアを通じて取り組んできました。その研究は自動推論、形式的検証、セキュリティ、AI にわたり、Cedar、IAM Access Analyzer、Continuum などのシステムを形作ってきました。現在は、LLM、形式手法、エージェント型システムを組み合わせ、次世代の機械推論を築いています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

前提：楽楽明細とは別のアプリとして作った 起きたこと：12機能を1本のプルリクにまとめた 原因：4層の名前までしか決めていなかった 対策：機械に判定させる範囲を広げ、人が見る範囲を絞る 実例：レビューで通せなかった箇所 次にやるなら：プルリクの切り方から変える チェックリスト：着手前に決めておく項目 編集後記：インタビューを終えて ラクス技術広報です。 開発本部では、各部署のAI活用の取り組みを技術広報がインタビューし、記事にしています。今回は電子請求書発行システム「楽楽明細」の新しいオプション機能を、AIにほぼ実装させて約2か月でリリースした事例です。 本記事は、AIを使って順調に機能開発が進んだ話だけでなく、うまくいかなかったこと・その対策をまとめています。 AIに任せる範囲を広げる前に、正しさを機械が判定できる状態を作る。 今回はこの状態を作らないまま進めました。その結果、機能ごとに実装の仕方がばらばらになり、1機能のレビューで入った指摘を他の機能に横展開できず、同じ指摘を機能の数だけ受けることになりました。 納期の都合で12機能を1本のプルリクエストにまとめたことも重なり、変更ファイルは700を超え、サーバーサイドのレビュー担当が全量を確認し終えるまでに5営業日かかっています。 新規プロダクトでAI駆動開発を始める方 AIが書いたコードのレビューが追いつかないと感じている方 に向けて、着手前に決めておく項目を記事の最後にチェックリストとして置きました。是非ご参考ください。 ［図1：任せる範囲と、機械が判定できる範囲］ 前提：楽楽明細とは別のアプリとして作った 　 楽楽明細は、請求書や支払明細などの帳票を電子発行するクラウドサービスです。帳票のもとになる売上データは、お客様が販売管理システムやExcelで管理しているものを取り込みます。 販売管理システムを使っていないお客様は、売上データをExcelで管理しています。 ・営業や拠点ごとにファイルが分かれ、どれが最新かわからなくなる ・転記のときにミスも起きる ここを解決するために作ったのが、今回の 売上登録オプション です。専用画面で売上データを入力すると、そのまま請求データとしてCSV出力できます。 仕様はプロダクトマネージャーが決めました。AI（Claude）でプロトタイプを作り、動くものをお客様に見せながら40社に話を聞いています。話を聞くうちに最小限の機能で導入いただけるとわかり、最初のプロトタイプから機能を約30%削って、CSV出力と税額計算に必要な設定に絞りました。 楽楽明細本体には手を入れず、別のアプリとして切り出しています。長く運用してきた本体にAIを入れると既存機能を壊す可能性があるため、影響範囲を限定してAIに任せる範囲を広げる判断です。 項目 内容 期間 開発決定4月7日 → リリース5月末（実質2か月未満） 体制 設計・実装は2026年1月入社の川島卓大さんがほぼ一人。 サーバーサイドとフロントエンドで各1名がレビュー。 技術 Java、Spring Boot、React、TypeScript、PostgreSQL AIの使い方 仕様の書き起こしはClaude Code、kiro（cc-sdd）でspec化してエージェントに読ませる。 実装の主軸はCodex。 git worktreeで機能ごとに作業を隔離し、複数セッションを同時に走らせる。 起きたこと：12機能を1本のプルリクにまとめた 　 実装に使える期間は実質1か月弱で、機能は12ありました。機能ごとにプルリクエスト（以下プルリク）を切ってレビューを待つ余裕がないため、まず全機能をつなげて動かし、そこから改善する方針を選びました。 項目 実績 変更ファイル数 700超 サーバーサイドのレビュー 機能単位で半日〜1日。 最初のプルリクを全量見切るまでに5営業日（期間で2週間弱）。 フロントエンドのレビュー 大型プルリクと、機能単位に分割された後続15件のフロント部分を合わせて2人日。 GitHub Copilotによるレビューも入れていましたが、人手で見きれる量を超えています。機能ごとに切り分けてレビューできたのは、パッケージ構成をfeature-firstで先に決めていたためです。 原因：4層の名前までしか決めていなかった 　 プロダクトマネージャーからの要求仕様書は、お客様の求めるものが整理された状態で渡されています。ただ、そのままAIに渡せる粒度ではなかったと川島さんは語ります。 「そのままでは渡せませんでした。特に受け入れ条件と例外系が足りませんでした。」 そこで要件を「WHEN 条件 THEN 結果」のEARS形式で1アクション単位に分解し、「IF 制約 THEN 拒否」の例外パスを正常系と並べて書いてからspecに落としました。 実装側で先に決めていたのは、feature-firstのパッケージ構成と、DDD（オニオンアーキテクチャ）の4層の名前までです。層の中で誰が何を担うのか、検証はどこでやるのか、副作用はどこに置くのかは決めていませんでした。 その状態で機能ごとに並列でエージェントを走らせると、1機能のレビューで入った指摘を他の機能に横展開できず、同じ指摘を機能の数だけ受けることになりました。 「仕様自体は要件通り作成できているものが多かったが、責務が分離できていないものが多く、レイヤー間の妥当性を見る時間が多かった。」 要求がテストできる形になっていても、実装方針が決まっていなければ、AIはそれぞれの解釈で書きます。 対策：機械に判定させる範囲を広げ、人が見る範囲を絞る 　 ［図2：判定を3段に分ける］ CIとpre-commitは最初から入れていました。ルールの書き出しとマージゲートの追加は、機能ごとに実装がばらばらになった反省から足したものです。 「一番効いているのは『できました』と言わせず証拠を出させることです。」 川島さんは、サブエージェントの「テストが通った」という報告も鵜呑みにせず、親のエージェントがdiffとテスト出力を自分で確認します。 レビューは一次をGitHub CopilotとClaude Codeのスキルで出し、人が二次で見ます。観点が複数あるときは同じエージェントに全部任せず、観点ごとにサブエージェントを分けて並列で走らせます。指摘にはmust、should、ask、imo、nitのラベルを付け、対応するかどうかを人が判断しやすくしています。 実例：レビューで通せなかった箇所 　 本機能にて、サーバーサイドとフロントエンドのレビューを担当した2人に「レビューで通せなかった箇所」についてお伺いしました。 領域 レビューで通せなかった箇所 サーバーサイド メール送信のように非同期で構わない処理が、トランザクションの中に入っていた。 初期のプルリクでは、メールは送信されたのにDBがロールバックされ、無効なパスワード初期化用URLがユーザーに届く実装になっていた（リリース前に修正）。 サーバーサイド 業務ロジックがユースケースやインフラの層に流れ出す責務違反。 サーバーサイド N+1が起きやすい構造。 明細行20行の売上データを取得するのに、最初はSQLが23本走っていた。 フロントエンド 方針はバックエンドで検証して送信時に表示することだったが、全画面にリアルタイムバリデーションが入っていた（全画面から削除）。 フロントエンド すでにある共通コンポーネントを使わず画面ごとに直書きし、ドラッグ・アンド・ドロップも複雑に自前実装していた（ライブラリを使う形に置き換え）。 フロントエンド テーブル内のテキストフィールドに1文字打つごとに、テーブル全体が再レンダリングされていた。 レビューを担当した2人が、共通して口にしたことがあります。 「『動く』のと『そのまま出せる』の間には距離がある」 また、これから同じ進め方を始めるチームへ、2人からのコメントです。 サーバーサイド　レビュー担当者 「設計、実装の前にどうやってAIをハンドリングをしていくかという工程をちゃんと設けるべきではあった。期日までが短く急ぎ早で始めたものの手戻りも多く、事前準備をちゃんと設けていても間に合わせられていたのではと思う。 」 フロントエンド　レビュー担当者 「レビューする側もAIを使っていいということ。作る速度が上がる分、見る側もAIで理解スピードを早めないとレビューが追いつかなくボトルネックになる。」 次にやるなら：プルリクの切り方から変える 　 ［図3：プルリクの切り方］ 切れ目を先に決めておけば、レビューは内側から外側へ積み上げる順に流れます。 一人でフルスタックに進めた体制では、フロントとバックエンドの間で調整が発生しないため、動くものを作る速度は出ました。一方で、一人にかかる負担は大きくなりました。API規約を先に確定させれば、フロントとバックエンドを分担できます。着手前にAIのハンドリングを詰める工程を置くことも、次の案件に向けた課題として残りました。 チェックリスト：着手前に決めておく項目 　 冒頭でもお伝えした通り、本取り組みから得た知見を基に着手前に決めておく項目をまとめました。 ご自身のプロジェクトに当ててみてください。 仕様と設計で決めておくこと （→ 原因の章 ） □ 受け入れ条件と例外系を、1アクション単位で書き出したか（EARS形式など） □ 各層で誰が何を担うか、検証はどこでやるか、副作用はどこに置くかを決めたか 機械に判定させる仕組み （→ 対策の章 ） □ CIで必須にする項目を並べたか（lint、format、型チェック、単体テスト、secret scanning、依存パッケージの実在チェック） □ テストを実データに近い環境で流せるか（Testcontainersなど） □ 機械では拾えない観点を、プロジェクト固有のレビュー観点として文字にしたか □ エージェントに、テスト出力とdiffを証拠として出させる運用にしたか 分割の単位 （→ 次にやるならの章 ） □ API規約（インターフェース）を、実装より先に確定させたか □ プルリクの切れ目を、レビューできる大きさで先に決めたか 最後に、川島さんからのメッセージです。 「AIに任せる範囲を広げる前に、正しさを機械が判定できる環境を先に作ることが大事だと思いました。最初の壁はコードが書けないことではなく、動いているように見えて設計方針から外れたコードが、レビューの追いつかない速度で積み上がることです。AI駆動開発で変わるのは、コードを書く仕事の比重です。良し悪しを定義し検証する仕事へ重心が移ります。ツールは半年で入れ替わりますが、この土台はどのツールに乗り換えても効き続けます。」 編集後記：インタビューを終えて 　 取材していて印象に残ったのは、川島さんもレビュー担当の2人も、うまくいった話より「次はこうする」を具体的に話してくれたことでした。700ファイルのプルリクは、社外に出すには気の重い話だと思います。それでも数字と経緯をそのまま出してくれたので、この記事が書けました。 開発本部では、うまくいったところとやり直したいところの両方を、これからも技術広報が聞いてご紹介していきます。

はじめに CyberAgent の 27卒のサーバーサイドエンジニア内定者として内定者バイトをしてい ...