Amazon AI支援コーディングOA対策2026：バグ・AI・隠しテスト

見慣れないリポジトリが開かれ、いくつかのテストが失敗していて、AIアシスタントが指示を待っています。難しいのは、AIに「コードを直して」と頼むことではありません。システムを十分に理解したうえで、何を頼むか、答えが正しいか、そして隠しテストでまだ何を突かれうるかを判断することです。

これが、2026年の複数のAmazon候補者の報告で語られている新しい課題です。Amazonは、AI支援OAの共通形式を公式には発表していません。そこで本ガイドでは、公式のガイダンスと報告された体験談を分けたうえで、制限時間やリポジトリ、バグの数が変わっても役立つ準備方法を紹介します。

まずはPracHubのAmazonの実際の面接問題、特に最新のソフトウェアエンジニアリング基礎とコーディングの報告から始めてください。そのうえで、以下の手順を使ってそれらの問題をリポジトリレベルのデバッグ練習に変えていきます。

評価されるのは、原因の特定、生成された差分、最終的な根拠を、自分でしっかり管理できている候補者です。

結論

AmazonのAI支援コーディング課題は、プロンプトを書く競技ではなく、AIツールを使ったデバッグの評価として捉えてください。 最近の候補者の報告では、見慣れないコードベース、壊れた挙動、組み込みのアシスタント、そして公開または非公開のテストが挙げられています。正確な構成は職種や地域によって異なるようです。

最適な流れは次のとおりです。失敗を再現し、コードの経路をたどり、仮説を立て、範囲を絞った質問を1つし、差分を確認し、テストを実行し、仕様を自分で検証します。

使うのは、OAで明示的に提供または許可されているツールだけにしてください。Amazonの現在の新卒向けOAガイダンスは、ブラウザの操作が記録される場合があることを伝え、コピー＆ペーストを控えるよう注意を促しています。最終的な判断基準は、招待メールとOAの環境に書かれた指示です。

AmazonのAI支援コーディングOAとは？

AmazonのSDE向け公式選考ページには、職種ごとに異なるコーディング評価があると書かれており、正確な構成は招待メールで確認するよう案内されています。新卒向けページでは国ごとに形式が異なりうるとされ、SDE IIのページでは従来型の2問のコーディング課題が説明されています。

これとは別に、2026年の複数の候補者の報告では、AIアシスタントが組み込まれた新しいリポジトリ課題が語られています。報告で多く挙がるのは、既存のアプリケーションにある複数のバグを修正することと、テストスイートを通すことです。従来型のアルゴリズム問題とリポジトリ課題の両方が出たという候補者もいれば、順序やタイマー、テスト数が異なったという報告もあります。

実践的な結論： 報告されているリポジトリ形式に備えつつ、1人の候補者の数字を暗記することは避けてください。招待メールを、試験の仕様書として読んでください。

従来のDSA問題との違い

通常のコーディング問題では、簡潔な仕様が与えられ、アルゴリズムを設計します。リポジトリ課題では、一部だけ動いているシステムが与えられ、安全に変更を加える前に仕様を自分で復元する必要があります。

アルゴリズムの練習をやめてはいけません。候補者の報告によると、新しい課題は従来のコーディングと並んで出ることがあり、その後のAmazonの面接でもコーディングの基礎は問われます。PracHubのAmazonのソフトウェアエンジニア向けコーディング問題で、その練習も続けてください。

この課題が測っていると考えられるもの

Amazonは、この報告されている形式の採点基準を公表していません。課題の設計、堅牢でテスト済みのコードを重視する公式の姿勢、そして繰り返し語られる候補者の説明から考えて、以下のスキルは、確定した配点ではなく、準備の目標として妥当なものです。

共通しているのは、エンジニアリングを自分でコントロールすることです。AIは調査を速めてくれるかもしれませんが、原因の特定と提出するコードの責任は、あくまで自分にあります。

リポジトリデバッグの7ステップ

根拠、変更、結果を結びつけられる程度に、1回のサイクルを小さく保ちましょう。

1. 実装より先に仕様を読む

課題の説明、README、テストの実行コマンド、プロジェクト構成、公開テストに目を通します。期待される挙動を1文で書き出してください。失敗しているテストは根拠になりますが、それが要件のすべてとは限りません。

2. 失敗を1つ再現する

関連する最小のテストまたは操作を実行します。正確なアサーション、例外、ステータスコード、状態の不一致を記録してください。すべてが失敗している場合は、リポジトリ全体の修復をアシスタントに頼むのではなく、代表的な経路を1つ選びます。

3. 実行経路をたどる

リクエストや関数呼び出しを追って、エントリポイントからデータアクセスまでたどります。失敗しているシンボル、関連するモデルのフィールド、近くのテストを検索してください。route -> controller -> service -> repository のような短い経路を書き出します。

4. 仮説を立てる

何が間違っていると考えているか、どんな観察があればその仮説が否定されるかを書きます。そうすると場当たり的な編集を防げ、AIアシスタントに範囲の絞られた調査を頼めます。

5. 1つの仕事だけを頼む

アシスタントには、特定の経路を調べる、条件を説明する、最小のパッチを提案する、のいずれかを頼みます。要件、観察された失敗、関連するファイル、制約を含めてください。テストを通すためだけにテストを書き換えるよう頼んではいけません。

6. 差分を確認する

変更された行をすべて確認します。公開された挙動の変更、握りつぶされたエラー、重複したロジック、無関係なリファクタリング、存在しないAPI、広すぎる例外処理がないか見てください。自分で説明できない変更は元に戻します。

7. まず狭く、次に広く検証する

最初に、元の失敗を再実行します。次に周辺のテストを実行し、時間があれば全テストを実行します。最後に、サンプルでは見えなかった境界を1つ試します。

この考え方をさらに練習するには、PracHubの既存コードベース面接ガイドを使ってください。

より良いAIプロンプトの書き方

役に立つプロンプトは、判断を手放さずに不確実さを減らします。弱いプロンプトは自分の考えを隠してしまい、大きくてレビューしにくいパッチを招きます。

繰り返し使えるプロンプトの型は、状況 + 期待する挙動 + 観察された根拠 + 範囲 + 依頼する作業 + 制約です。返答を受け取ったら、コードは自分で確認してください。整った説明は証拠ではありません。

実例：AIが誤って判断しやすいバグ

ローンに出資するサービスがあるとします。公開テストは通常の送金を確認しますが、隠しテストでは、金額がゼロの場合、ローンの残額を超える金額の場合、片方のレコードへの書き込みだけが成功してもう片方が失敗する場合を試すかもしれません。

async function fundLoan(userId: string, loanId: string, amount: number) {
  const user = await users.find(userId);
  const loan = await loans.find(loanId);

  if (user.balance < amount) throw new Error("insufficient balance");

  user.balance -= amount;
  loan.funded += amount;
  await users.save(user);
  await loans.save(loan);
}

明らかなチェックはありますが、仕様が不完全です。優れた候補者は次のように問います。amount はゼロや負の値になりえるか。出資額がローンの残額を超えてもよいか。どちらかのエンティティが存在しない場合はどうなるか。2つの書き込みはアトミックでなければならないか。

範囲を絞ったプロンプトは、たとえば次のようになります。「出資サービスは正常系を通りますが、仕様では金額が正であること、過剰出資がないこと、部分的な状態更新がないことが求められています。このメソッドとそのリポジトリAPIを調べ、テストを変更せずにこれらの不変条件を守る最小の変更を提案してください。」

そのうえで、提案されたパッチを amount = 0、負の金額、ちょうど残額の金額、残額を1だけ超える金額、ユーザーの資金不足、存在しないエンティティ、永続化の失敗のシミュレーションで検証します。アシスタントはコードを提案できますが、確信を与えてくれるのは自分のテストだけです。

隠しテストが通常確認すること

すべての要件を、少なくとも正常ケース、境界ケース、失敗ケースに1つずつ落とし込みましょう。

隠しテストは、たいていなぞなぞではありません。公開された例では十分にカバーされていない要件や、エンジニアリング上の不変条件を表したものです。PracHubのコーディングテストの隠しテストケースのガイドには、より広い境界のチェックリストがあります。

最も時間を無駄にする5つのミス

再現する前にプロンプトを打つ。 実際の失敗がわからないと、アシスタントは表面的なパターンから推測するだけになります。

一度に多くを変えすぎる。 複数ファイルにまたがるリファクタリングでは、どの編集がバグを直し、どの編集がデグレを生んだのかわかりにくくなります。

コードに合わせてテストを編集する。 課題が明示的にテストの誤りだと述べていない限り、テストと書かれた仕様は、取り除く障害ではなく満たすべき根拠です。

公開テストが通ったことを信じ込む。 正常系だけのスイートでは、認可、ロールバック、境界、冪等性の不具合を見逃すことがあります。

練習問題： Debug a Node.js car-rental backend: leaked cars, missing new cars, lost edits (Amazon · ソフトウェアエンジニア)

許可されていない外部ツールを使う。 練習では合法的なツールなら何を使ってもかまいませんが、本番のOAではAmazonとテスト提供元が許可しているリソースだけを使ってください。非公開の試験内容を外部のサービスに貼り付けてはいけません。

7日間の準備プラン

診断とアルゴリズムの練習には、PracHubのAmazonの問題ハブを使ってください。その後の行動面接の段階に向けては、技術面の準備とあわせて、AmazonのLeadership Principlesの質問とAmazon OAのWork Simulationガイドにも取り組みましょう。

PracHubの実際の問題で練習する

ここに挙げるのはAmazonの問題集に実在する記録であり、実際のOAを予測するものではありません。OAに言及している出典の報告を優先し、そのうえでPracHubに保存されているテクニカルスクリーニング、オンサイト、持ち帰り課題のラウンドを使っています。表には保存されているラウンドをそのまま示しており、根拠のラベルを付け替えることはしていません。

問題文が実際に求めていること

Q1. Highest Average-Salary Team in an Org Chart
問題集の根拠：Amazon、テクニカルスクリーニング、中級。 組織図で平均給与が最も高いチーム。ある会社の報告系統は、1つの階層構造になっています。すべての従業員は、一意の整数のid、名前、整数の給与、そして managerid（報告先の人物のid）を持っています。ちょうど1人の従業員（CEO）だけが managerid = null で、上司がいません。

Q2. Merge Overlapping Time Ranges
問題集の根拠：Amazon、テクニカルスクリーニング、中級。 重なる時間範囲のマージ。あなたは共有会議室の予約管理を行うバックエンドを作っています。これまでに入ったすべての予約は、整数のタイムスタンプ（エポック秒）のペア [start, end] として記録されており、start <= end です。

Q3. Caesar Cipher with Translation-Table Optimization
問題集の根拠：Amazon、テクニカルスクリーニング、中級。 シーザー暗号を実装してください。文字列 text と整数 shift が与えられたとき、すべてのアルファベット文字を、大文字小文字を保ったまま shift の分だけ前方に回転させ、アルファベットの末尾を超えたら先頭に戻した新しい文字列を返します。アルファベット以外の文字はそのままにします。

Q4. Detect and Break a Cycle in a Singly Linked List
問題集の根拠：Amazon、テクニカルスクリーニング、中級。 単方向連結リストの先頭が与えられます。このリストには、循環がある場合とない場合があります。リストのどこかで、あるノードの next ポインタが以前のノードに戻り、ループを作っていることがあります。次の2つを行ってください。1. リストに循環が含まれるかどうかを検出する。2.

セットを本番のように解く

1. まず4問すべてを読む。 それぞれの難易度を見積もり、コードを書き始める前に取り組む順番を決めます。
2. 解法は見ない。 エディタを開く前に、不変条件、計算量の目標、3つのエッジケースを書きます。
3. タイマーは1つだけ使う。 最後の5分は、境界、同値、規模、出力形式のテストのために残しておきます。
4. 失敗のパターンを記録する。 問題名だけでなく、崩れた不変条件や見逃したエッジケースを記録します。

Amazon AI支援コーディングOAのFAQ

AI支援のリポジトリ課題は、いまやAmazonのSDE向けOAのすべてに含まれますか？

それを確認できる公開のAmazonのページはありません。SDE I、新卒、インターン、一部のSDE IIの選考を含め、2026年の複数の候補者が受けたと報告していますが、形式はさまざまです。招待メールに書かれた構成に従ってください。

バグや隠しテストはいくつありますか？

候補者の報告によって、バグの数もテストの数も異なります。1つの数字に合わせて準備するのはやめましょう。リポジトリに欠陥が2つでも複数でも通用する、デバッグと検証の流れを繰り返し練習してください。

組み込みのアシスタントはAmazon Qですか？

そう決めつけないでください。AmazonにはAmazon Q Developerの公開ドキュメントがありますが、それだけではOAに組み込まれたアシスタントの正体や機能は確認できません。OAの画面に表示されるインターフェースとヘルプの記載に従ってください。

OAの最中にChatGPTやClaudeなどの外部AIを使えますか？

OAの指示で明示的に許可されている場合だけです。Amazonの新卒向けOAガイダンスには、ブラウザの利用が記録される場合があり、コピー＆ペーストは避けるよう書かれています。安全な基本ルールは、組み込みのアシスタントと、自分が受けるOAで明示的に許可されているリソースだけを使うことです。

AIのパッチが公開テストを通した場合はどうすればよいですか？

差分を確認し、仕様を自分でテストしてください。不正な入力、境界、永続化、認可、リトライ、隣接する挙動を確認します。実装の一部をツールが生成したとしても、提出する実装に責任を負うのは自分です。

すべてのテストケースに通れば、面接に進めますか？

Amazonは、この報告されている課題について共通の合格ラインや配点を公表していません。公式のOAのページでは、コーディング、問題解決、仕事の志向を問う質問、その他の職種ごとのセクションを含む、より幅広い評価が行われると説明されています。必須のセクションはすべて丁寧に完了させてください。

まとめ

2026年のAmazon AI支援コーディングOAが変えたのはインターフェースであり、エンジニアリングの水準ではありません。要件を理解し、見慣れないコードを読み進め、欠陥を切り分け、説明できる小さな変更を加え、それが正常系の先でも動くことを示す力は、変わらず必要です。

2つの練習を並行して進めましょう。アルゴリズムの速さにはPracHubのAmazonのコーディング問題を使い、デバッグ、テスト、選考全体を通した判断力の練習には、最新のAmazonの面接の報告と解答つきの解説を使います。目標は、AIを有能に見せることではありません。自分がエンジニアとして主導権を握っていることを示すことです。

出典と参考資料

• Amazon Jobs: Online Assessment Prep for SDE Roles（SDE職向けオンラインアセスメント対策）
• Amazon Jobs: SDE II Online Assessment Prep（SDE IIのオンラインアセスメント対策）
• Amazon Jobs: Software Development Interview Topics（ソフトウェア開発の面接トピック）
• Candidate discussion: Amazon SDE I AI-assisted repository format（候補者の議論：AmazonのSDE IにおけるAI支援リポジトリ形式）
• Candidate report: SDE I Graduate OA, London, July 2026（候補者の報告：SDE I新卒OA、ロンドン、2026年7月）