OpenAI FDEの技術面接準備：実装・評価・運用の想定質問

求人の仕事から、説明する証拠を選ぶ

以下は筆者が作成した15の練習問題である。2026-10-05確認のOpenAI公式求人・公開案内から推論したもので、公式の出題、流出課題、Tokyo FDEの確定loop、内部rubricではない。事実編でfactごとの職種・地域・根拠を確認できる。関連職種は比較に使い、同じ採用processだと断定しない。

共通のengineering実践を、OpenAI求人に明記された責任・地域へ対応付けて練習する。Tokyo FDEとApplied AI Engineerのどちらにも、本人の実装を説明する証拠が必要になる。Codex職は開発workflowの評価、Architect職は担当顧客の設計判断という文脈を加える。製品資料は補助と明示し、採用要件の証拠にしない。一般engineering guideの品質項目は準備に使えるが、例示形式から自分の試験を確定しない。roundごとにtool・言語・AI利用を確認する。

実経験があれば、共有可能な案件を使う。提案は提案、未実行testは未実行と説明し、仮想の数字を自分の成果やOpenAIの合格閾値にしない。改善率だけを示すより、失敗した試行の因果関係を正確に説明する方が、判断の証拠になる場合がある。

次は筆者作成の準備図である。矢印は自分の練習手順を示し、OpenAIの選考順ではない。実装traceは何が起きたか、評価recordはどう判定したか、判断recordはその結果何を選んだかを担う。

1. 1担当した実装とrequest経路
2. 2観測した失敗や結果
3. 3指標を定義した評価case

1. 1評価比較と制約
2. 2判断record
3. 3導入・修正・保留

1. 1本番で見つかった例外
2. 2失敗分類
3. 3評価の範囲を更新

各行から成果物を一つずつ準備し、顧客の識別情報を除く。深掘りされたときに、コード境界、測定、判断のどこへ進むかが明確になる。各問は別の証拠を求めるので、すべてを「精度を改善した」という同じ話で埋めない。

OAI-TQ01: 本人が実装した本番システムを説明する

根拠facts: OAI-T01, OAI-T08, OAI-A02, OAI-A05, OAI-I08.

対象職種・地域: Tokyo FDE / Tokyo Applied AI Engineer。engineering guideは一般案内であり、FDE専用rubricではない。

公式根拠: Tokyo FDE求人 · Tokyo Engineer求人 · 会社一般の選考案内.

想定質問（推論。公式の出題ではない）: 実際に携わった顧客向けシステムを1件選ぶ。frontendとbackendのどこを自分で実装し、その変更がどのように業務を本番で使える状態にしたか。

問いの狙い（推論）: 求人が本人の実装貢献を明記しているため、調整業務やチーム全体の成功と、自分の実装判断を区別する練習である。コード変更が顧客の使い方へどうつながるかも説明する。これはOpenAIの採点基準の断定ではない。

回答に含める証拠・数字・判断:

• 利用者の操作、frontendの状態、backendの検証、model/tool呼出し、保存、表示の経路を描く。自分の担当componentと他者が作ったcomponentを明記する。
• 実際のコード上の判断、却下した代替案、選択を決めた制約を一つずつ挙げる。その設計が誤りだと分かるtestや失敗も説明する。
• 共有可能な測定として、完了数/試行数、期間を明示した遅延percentile、変更前後の分類済み不具合件数などを使う。単位、分母、比較対象、本人の寄与を示し、改善率を作らない。

深掘り 1: frontendとbackendの境界をまたいだ失敗は何か。

説明すべき点: clientのtimeout後にserver側処理が完了していたか、永続状態やrequest IDで何を切り分けたか、再試行で重複した作用をどう避けたかを説明する。自分の障害経験でなければ提案testと明示し、期待する結果を示す。

深掘り 2: reviewで、demoを動かす以外の何を変えたか。

説明すべき点: reviewの指摘、修正、根拠を対応させる。入力検証、保守できる境界、性能、意味のあるtestなどが対象になる。他者の判断と自分の判断を分け、release時点で未検証だった点も述べる。

避ける浅い回答: 「AI chatbotを作って顧客満足度が上がった」で止めると、実装境界、測定、本人の判断が見えない。仮想architectureを使う場合は、提案であると明示する。

OAI-TQ02: 業務transactionを壊さずmodelを統合する

根拠facts: OAI-T01, OAI-T04, OAI-A02, OAI-A03.

対象職種・地域: Tokyo FDE / Tokyo Applied AI Engineer。統合・回復設計は筆者の演習であり、指定された採用課題ではない。

公式根拠: Tokyo FDE求人 · Tokyo Engineer求人.

想定質問（推論。公式の出題ではない）: 顧客の既存業務に正本recordがある。model呼出しをどこへ挿入し、部分的な完了が誤った業務結果にならないようにするか。

問いの狙い（推論）: 変更できない既存systemを含め、統合を一貫した状態遷移として考える練習である。求人が示すのは統合と安定運用の責任であり、特定transaction方式を要求するものではない。

回答に含める証拠・数字・判断:

• 正本system、入力契約、書込み権限者、pending/completed/failed等の状態を指定する。modelの提案と、業務上受理した更新を区別する。
• timeout、不正な応答、後段の書込み失敗の経路を示す。検証場所、retryで繰り返す処理、一度だけ起こす作用を分け、既存担当teamの制約も示す。
• 実systemでは失敗・重複完了数/試行数と回復時間を期間付きで示す。提案なら制御した障害fixtureと期待する永続状態を列挙し、実測成果として書かない。

深掘り 1: model処理は成功して、顧客DBへの書込みが失敗したらどうするか。

説明すべき点: 保持できる結果、pendingのまま残る作業、再確認すべき権限を指定する。model再呼出しと検証済み結果の再利用を、鮮度、重複作用、費用で比較する。

深掘り 2: 顧客が既存interfaceを変更できない場合はどうするか。

説明すべき点: 変更不可という制約を残し、限定したschemaと失敗状態を持つ追加境界を検討する。運用費用を説明し、安全でないinterfaceを隠して進めるより案件を保留すべき条件を示す。

避ける浅い回答: 「APIを呼び、retryを追加する」で止めない。正本、部分完了、重複作用の意味が定まっていない。

OAI-TQ03: modelの振る舞いを製品の振る舞いへ翻訳する

根拠facts: OAI-T09, OAI-A03, OAI-T08.

対象職種・地域: Tokyo FDE / Tokyo Applied AI Engineer。

公式根拠: Tokyo FDE求人 · Tokyo Engineer求人.

想定質問（推論。公式の出題ではない）: modelの出力がもっともらしく、入力によっては誤る。結果への確信が足りないとき、顧客製品は何を表示し、どの操作を許可し、何を記録するべきか。

問いの狙い（推論）: FDE求人はmodel挙動の製品体験への影響を挙げている。不確かな出力を利用者の操作と失敗の影響へ結び付け、promptの出来だけで製品を説明しないための練習である。

回答に含める証拠・数字・判断:

• 具体的なtaskを選び、提案、draft、実行済み操作を区別する。利用者に見せる根拠、必要権限、根拠が欠けたときの状態を定義する。
• 観測した誤りを、誤答、宛先違い、危険な操作、業務中断など影響で分類する。設計での対応と、それにより増える利用者の手間を説明する。
• task完了、修正、途中離脱を分母付きで観測し、model品質と合わせて示す。modelが数字を出しただけでは、確信度表示が較正されたことにならない。

深掘り 1: どの場面で人の確認を必須にするか。

説明すべき点: 取り消せる範囲、影響、根拠の質、現在の権限を比較する。誰が何を確認するか、入力変更で承認が失効する条件、実行前に修正できる内容を明示する。

深掘り 2: 確認の手間で利用定着が悪化したらどうするか。

説明すべき点: 離脱場所と、確認が防いだ大きな失敗を測る。操作scopeを狭める、確定的な検証を自動化する等を検討し、利用率だけを理由に統制を外さない。

避ける浅い回答: 「強いmodelと注意書きを使う」で済ませない。顧客業務に作用する時点の振る舞いが決まっていない。

OAI-TQ04: 顧客業務から評価の範囲を作る

根拠facts: OAI-A04, OAI-T02, OAI-E01, OAI-E03.

対象職種・地域: Tokyo Applied AI Engineer / Tokyo FDEの評価feedback文脈。評価guideは技術補助資料。

公式根拠: Tokyo Engineer求人 · Tokyo FDE求人 · 評価設計の補助資料.

想定質問（推論。公式の出題ではない）: 顧客workflowから代表性のある評価setをどう作り、二つの実装を比較するのに十分な証拠をどう判断するか。

問いの狙い（推論）: Engineerの系統的評価という職責を顧客taskとFDEの現場知見へ接続する練習である。問うのは網羅範囲と判断であり、万能の精度目標や既知の採用課題ではない。

回答に含める証拠・数字・判断:

• case収集前にtask成功、利用者、入力分類を定義する。通常traffic、影響の大きい稀な失敗、データ品質差を含め、標本の取り方と利用許可を記録する。
• 開発用caseと固定した比較setを分ける。model/prompt/retrieval/toolのversion、指標定義、case数、変動がある箇所の実際の反復観測を記録する。
• baselineと候補を同じcaseで比べる。分母、分類ごとの失敗、必要なら遅延・費用も示し、その標本では確定できない点を残す。

深掘り 1: 全体scoreが上がり、重大な分類だけ悪化したらどうするか。

説明すべき点: 影響する業務と害を特定し、標本と採点方法を確認する。限定導入、修正、保留を比較し、受入条件の合意者を説明する。全社共通閾値を作らない。

深掘り 2: 新しい本番caseをどう評価setへ加えるか。

説明すべき点: 許可と秘匿処理を伴う収集、失敗分類、期待する振る舞い、review担当を説明する。固定比較setを維持しつつtask分布の変化を追い、新要件に当たるcaseを区別する。

避ける浅い回答: 「公開benchmarkと100例を使う」だけでは、その顧客の範囲も受入条件も示せない。

OAI-TQ05: 自動graderを人の判断で較正する

根拠facts: OAI-A04, OAI-E02.

対象職種・地域: Tokyo Applied AI Engineer。公式評価guideを求人の補助として使う。

公式根拠: Tokyo Engineer求人 · 評価設計の補助資料.

想定質問（推論。公式の出題ではない）: graderが二つの回答を同等とし、顧客review担当が異なる評価をした。どこを調べ、評価方法をどう直すか。

問いの狙い（推論）: 測定が意図したものを測っているかを考える練習である。求人がgraderと人間判断を挙げているため、scoreの意味と限界を説明できる必要がある。

回答に含める証拠・数字・判断:

• task固有の判定基準を自分の言葉で書く。正しさ、根拠、必要情報、禁止動作など該当する項目を使い、好みと失敗の重大さを区別する。
• 共有可能な不一致標本と独立reviewの判定を残す。分類ごとの一致・不一致件数、review指示、曖昧caseを示す。人の好みを検討なしに正解としない。
• graderが表面的な文体、長さ、根拠のない断定を評価していないか調べる。修正した規則、比較結果、残る限界を説明する。

深掘り 1: 人どうしでも評価が割れたらどうするか。

説明すべき点: task定義が曖昧なのか、review担当に必要contextがないのかを分ける。顧客責任者と要件を確定し、異論と不確実性を残し、明確な指示で条件を伏せた再reviewを行う。

深掘り 2: model graderで業務完了を確認できるか。

説明すべき点: 文章の判定と、保存状態や正しいtransaction宛先など確定的な事実を分ける。graderとsystemの検証を組み合わせ、最終回答だけでは見えない失敗を示す。

避ける浅い回答: 「強いmodelで採点する」はtoolを替えるだけで、顧客の判断とscoreが一致する証拠にはならない。

OAI-TQ06: toolを使うagentを操作境界で評価する

根拠facts: OAI-A03, OAI-E04, OAI-F02.

対象職種・地域: Tokyo Applied AI Engineer。Frontierのaccess記述は製品文脈であり、顧客がそのstackを使うという前提ではない。

公式根拠: Tokyo Engineer求人 · 評価設計の補助資料 · Frontierの製品文脈.

想定質問（推論。公式の出題ではない）: agentの最終回答は良いが、違うtoolを呼んだり危険な引数を渡したりした。そのcaseをどう評価し、実行をどう統制するか。

問いの狙い（推論）: 最終回答の品質と操作の正しさを分ける練習である。技術guideはtool選択と引数を評価対象にし、求人はtoolと統制を扱う。具体的な防御は候補者が提案する設計になる。

回答に含める証拠・数字・判断:

• 意図したtool、schema、対象resource、呼出し主体、許可scopeを定義する。modelの文面を信頼せず、現在のsystem状態で権限を検証する。
• 誤tool、不正引数、他顧客resource、重複実行、権限取消しのcaseを作る。各caseの安全な終端状態とtrace eventを定義する。
• 妥当かつ権限のある操作数/試行数と、禁止作用の件数を最終回答品質と別に測る。実行済みtestは実績、未実行なら期待結果として扱う。

深掘り 1: 危険な書込みをどこで止めるか。

説明すべき点: 作用の直前にある確定的な境界を特定する。そこでのschemaとresource権限検証、顧客が合意した確認手順を説明する。promptの注意だけは実行時保証にならない。

深掘り 2: 長いtaskの途中で権限が取り消された場合をどうtestするか。

説明すべき点: 後続tool呼出しの前で制御した取消しを起こす。権限の再確認、拒否状態、利用者表示、監査記録を説明する。対象endpointを確認せず提供元固有の動作を断定しない。

避ける浅い回答: 「回答が良かったので合格」では、agentが誰の何を変更したかが抜ける。

OAI-TQ07: 複数agentを使う根拠を示す

根拠facts: OAI-A03, OAI-E05, OAI-E03.

対象職種・地域: Tokyo Applied AI Engineer。評価guideは補助資料で、multi-agent課題が必須と主張しない。

公式根拠: Tokyo Engineer求人 · 評価設計の補助資料.

想定質問（推論。公式の出題ではない）: 顧客がsubtaskごとに専門agentを増やそうとしている。単一agentを維持する、確定的な処理を追加する、handoffを入れる判断を、何で裏付けるか。

問いの狙い（推論）: 観測した失敗機構から複雑さを正当化する練習である。guideは評価を根拠にしたarchitecture判断を支える。agent数を増やすこと自体は設計能力の証拠にならない。

回答に含める証拠・数字・判断:

• 単純なbaselineと、それで解消できない失敗を示す。専門agentの責任、入出力契約、必要なcontextを説明する。
• 同じtaskでroutingの正しさ、完了、引継ぎ誤り、所要時間、総費用を比較する。retryとhandoffを記録し、見かけの改善が追加作業を隠さないようにする。
• 顧客制約と実際の観測で選ぶ。運用担当、debugの難しさ、価値が小さい専門agentを撤去する条件も含める。

深掘り 1: handoffの失敗をどう定義するか。

説明すべき点: 宛先違い、task状態の欠落、制約の脱落、循環する引継ぎを含める。受信側の期待状態と回復経路を示し、引継ぎ失敗とtask自体の失敗をtraceで分ける。

深掘り 2: 確定的な処理の方がよいのはいつか。

説明すべき点: 安定したschema、明示規則、直接正しさを検証できる操作を検討する。その処理の限界と残る曖昧な判断を示し、同じcaseで比較する。

避ける浅い回答: 「agentが多いほど正確」は、baselineの失敗、引継ぎ契約、測った効果を示していない。

OAI-TQ08: 多言語と敵対的な失敗を評価へ含める

根拠facts: OAI-E06, OAI-A04, OAI-T11.

対象職種・地域: Tokyo Applied AI Engineer / Tokyo FDEの日英文脈。評価guideを公開された語学試験rubricとは扱わない。

公式根拠: 評価設計の補助資料 · Tokyo Engineer求人 · Tokyo FDE求人.

想定質問（推論。公式の出題ではない）: 短い英語例では動くworkflowについて、日本語入力、長いcontext、複数の意図、取得資料に混入した指示をどうtestするか。

問いの狙い（推論）: 最も簡単なdemo以外まで評価を広げる練習である。根拠は例外case評価と日英の顧客対応を支えるが、日本語の敵対的な採用課題を指定していない。

回答に含める証拠・数字・判断:

• 実workflowの言語と文書分布から始める。言語間で同じ意図、専門用語、混在入力、関連するcontext長を含める。単純な翻訳だけで網羅したとしない。
• 敵対的・複数意図のcaseごとに、データとして読む根拠、正当に与えられた指示、利用可能tool、安全な期待結果を指定する。顧客データを使えない場合は合成入力を使う。
• 言語、入力分類、影響ごとの失敗とcase数を示す。採点自体が日本語に弱くないか調べ、model、retrieval、権限、graderの失敗を分ける。

深掘り 1: 日本語の参照回答が悪くてscoreが低くなった場合はどうするか。

説明すべき点: 言語と業務を理解するreview担当と期待回答を検討し、理由を残してcaseを修正する。好きなmodelに合わせて基準を動かさず、修正recordで同じ候補を再比較する。

深掘り 2: prompt injectionを安全に扱えたと、何で確認するか。

説明すべき点: 拒否文だけでなくtool意図と実際の作用を調べる。無権限のaccess・書込みがなかったこと、終端状態を確認し、再現に足りる秘匿済みtraceを残す。

避ける浅い回答: 「英語testを翻訳し、安全promptを加える」では、task分布、採点の妥当性、実際の無権限作用を確認できない。

OAI-TQ09: 遅延・費用を業務完了との関係で判断する

根拠facts: OAI-A03, OAI-A02.

対象職種・地域: Tokyo Applied AI Engineer。

公式根拠: Tokyo Engineer求人.

想定質問（推論。公式の出題ではない）: 顧客が遅延と費用に不満を持っている。高くつく経路をどう特定し、必要な業務品質を落とさず改善を選ぶか。

問いの狙い（推論）: 求人は遅延・費用を信頼性・安全性と並べている。実workloadに基づく選択を説明し、完了した業務を考えずtoken数だけを減らすことを避ける練習である。

回答に含める証拠・数字・判断:

• 観測traceでretrieval、model、tool、network、retryの時間を分ける。workload、同時実行、期間、遅延percentileを示す。平均だけでは長い待ち時間を隠す場合がある。
• 試行taskと成功taskあたりの費用、通貨・課金単位、測った利用量、除外費用を定義する。現価格は検証した場合にだけ使い、提供元価格を作らない。
• context縮小、呼出し削減、model選択、確定的処理など限定した変更を比較する。cacheには鮮度・privacyの限界を示し、同じcaseで品質と失敗動作を確認する。

深掘り 1: 安いmodelでretryが増えたらどう判断するか。

説明すべき点: 全taskの総利用量と成功を、timeoutや修復作業も含めて比較する。retry上限と繰り返すべきでない誤りを定める。1呼出しの安さだけでは決めない。

深掘り 2: 即時の受付表示が必要で、実処理は長い場合はどうするか。

説明すべき点: 受付、pending、完了の状態を分ける。非同期案の永続化、取消し、表示、回復を説明し、利用者が完了と感じる時間とserver作業時間を別に測る。

避ける浅い回答: 「一番安いmodelと全面cache」では、品質、retry、鮮度、access境界の検証がない。

OAI-TQ10: 取り過ぎずに、原因を追える観測を設計する

根拠facts: OAI-A03, OAI-A02, OAI-F03.

対象職種・地域: Tokyo Applied AI Engineer。Frontier logは製品文脈で、提案traceをOpenAIの保存方針としない。

公式根拠: Tokyo Engineer求人 · Frontierの製品文脈.

想定質問（推論。公式の出題ではない）: 顧客から「時々失敗する」と報告されたがdemoでは再現しない。責任を持つlayerを特定するため、何を観測するか。

問いの狙い（推論）: 観測を修復可能な失敗へ接続する練習である。求人は可観測性とdebugを扱う。必要なtraceと、収集すべきでない情報を判断する。

回答に含める証拠・数字・判断:

• client request、backend、model/tool、永続結果を結ぶ識別経路を定義する。version/構成、時刻、状態、限定した誤り分類を記録し、呼出し試行と作用を分ける。
• 省く・秘匿する内容、保存目的、access管理者、調査手順を示す。すべてのpromptや顧客文書を保存せず、許可された最小caseをどう再現するか説明する。
• 実際の診断を、症状、traceで支持する仮説、反証test、修正後の観測で示す。障害数や回復時間には対象範囲と期間を付ける。

深掘り 1: 提供元の失敗とアプリの失敗をどう分けるか。

説明すべき点: request/response状態、retry履歴、アプリの検証、後段状態を比較する。escalationに必要な最小根拠を残し、確認した原因と推測を分け、利用者側の結果を検証する。

深掘り 2: traceに顧客の秘密が含まれていたらどうするか。

説明すべき点: 顧客・security責任者と封じ込めとaccessを扱い、秘匿処理、権限を踏まえた保存判断を説明する。収集契約を見直してtestし、面接例へ秘密traceを転記しない。

避ける浅い回答: 「全promptをlogしdashboardを見る」は、収集量を調査経路と混同し、privacyの負担を見落とす。

OAI-TQ11: 権限境界をreviewできる形にする

根拠facts: OAI-T03, OAI-R04, OAI-F02.

対象職種・地域: Tokyo FDEの横断協働 / Tokyo Applied AI Architectの設計範囲。Frontierは製品上の参考資料。

公式根拠: Tokyo FDE求人 · Tokyo Architect求人 · Frontierの製品文脈.

想定質問（推論。公式の出題ではない）: 顧客agentが文書を読み業務systemを更新する前に、GRC、Security、顧客責任者へどの設計証拠を持っていくか。

問いの狙い（推論）: FDE求人は協働相手を、Architect求人は統制を挙げている。権限とdata経路をreview可能にする練習であり、FDEが単独承認する、特定compliance frameworkが必須だと主張しない。

回答に含める証拠・数字・判断:

• 主体、resource、read/write操作、強制する地点を図にする。利用者権限、app/service credential、agent意図を区別し、実workflowから必要最小accessを定義する。
• data inventory、信頼境界、失敗・悪用case、未確認前提を示す。残るriskを判断できる責任者と、launch前に必要な証拠・設定を指定する。
• 他tenant、失効・取消し権限、権限昇格の負例testを提案する。拒否した作用と監査根拠を残し、図だけで第三者認証や適合性を証明したとしない。

深掘り 1: 文書に権限変更の指示が混入したらどうするか。

説明すべき点: 取得文書は根拠であり権限の正本ではない。信頼するidentityとpolicyでresource accessを確認する場所を示し、生成引数だけでscopeを変更できないtestを用意する。

深掘り 2: Securityのreviewでlaunchが止まったらどうするか。

説明すべき点: 証拠不足と不適切な境界を分ける。許可があればread-onlyや合成dataで範囲を狭めた段階を提案し、未承認を依存として残す。demo成功を受入としない。

避ける浅い回答: 「enterprise AIなので安全」で終えると、主体、resource scope、強制地点、判断者が見えない。

OAI-TQ12: 学習利用・保存・アプリ権限を区別する

根拠facts: OAI-R04, OAI-P01, OAI-P02, OAI-P03, OAI-P04.

対象職種・地域: Tokyo Applied AI Architectのprivacy設計。補助資料は記載製品・endpointの範囲のみ。実際の出題要件ではない。

公式根拠: Tokyo Architect求人 · privacyの補助資料.

想定質問（推論。公式の出題ではない）: 顧客が「学習に使わない」を、保存されず接続appも無制限に利用できる意味だと理解している。設計を選ぶ前に、要件をどう整理するか。

問いの狙い（推論）: 異なるdata統制を安心させる一言へまとめないための練習である。公式privacyページは技術・事業上の根拠であり、採用方針や全endpointへの一律保証ではない。

回答に含める証拠・数字・判断:

• 学習利用、提供元保存、アプリlog、接続app権限、削除要件を分ける。コピーが存在する地点と管理者を図にする。
• privacy事実を範囲付きで使う。初期設定の学習不使用にはopt-in例外があり、暗号化では保存条件が決まらず、API保存条件・ZDRの適用条件にはendpointや機能条件がある。実製品・endpoint・契約を確認し、保存ゼロを約束しない。
• 顧客data分類、許可処理、必要な削除・access動作、未確定条件の確認担当を記録する。接続app権限と自社log方針は別に検証する。

深掘り 1: 暗号化だけで保存禁止要件を満たせるか。

説明すべき点: 保存・通信時の秘匿と、dataの存在・期間を分ける。対象endpointの実際の保存modeと利用資格を確認し、Security/法務担当と受入を判断する。法的助言を創作しない。

深掘り 2: 対象の保存ゼロ構成でも何が残りうるか。

説明すべき点: 顧客アプリ全体のlog、cache、DB record、第三者tool、利用者downloadを確認する。提供元endpointの主張を広げず、他のコピーごとにaccess、削除、検証を設計する。

避ける浅い回答: 「学習に使わないのでprivacy riskはない」は、学習、保存、access、顧客アプリの動作を混同する。

OAI-TQ13: 依存先が変わっても評価を維持する

根拠facts: OAI-A02, OAI-E03, OAI-X01.

対象職種・地域: Tokyo Applied AI Engineerの評価harness。公式終了告知はplatformの文脈で、採用processではない。

公式根拠: Tokyo Engineer求人 · 評価設計の補助資料 · platform終了の告知.

想定質問（推論。公式の出題ではない）: model、prompt、retrieval pipeline、評価platformを変更するとき、評価証拠の比較可能性をどう保つか。

問いの狙い（推論）: 継続して使える評価契約と、特定のhosted製品を分ける練習である。確認時点でEvals platform終了は予定であり、完了ではない。評価実践の撤回を意味しない。

回答に含める証拠・数字・判断:

• task定義、利用許可のあるdataset、指標・grader version、baseline結果を保持する。実装変更を別に追い、採点変更をmodel改善と誤認しない。
• 共通caseで移行比較を設計し、欠損項目、grader差、結果exportを明示的に確認する。provenanceを残し、直接比較できなくなった過去結果を示す。
• 告知日を正確に使う。2026-06-03は対象節の発表日。2026-10-31 read-onlyと2026-11-30終了は、2026-10-05時点では未来の予定である。実移行計画では現行指示を再確認する。

深掘り 1: 新しいgraderでscoreの尺度が変わったらどうするか。

説明すべき点: 両方の尺度を保持し、taskごとの結果と人がreviewした不一致を比較する。必要なら新baselineを作る。旧新scoreを黙って同じtrendへつながない。

深掘り 2: 移行を進める・保留する条件は何か。

説明すべき点: exportの完全性、case実行の再現、採点の同等性または説明した差、access controls、担当者を指定する。終了予定日だけで進めず、検証済みまたは提案の戻し方・保留経路を示す。

避ける浅い回答: 「Evals終了なので評価は古い」は、hosted platformと求人が求めるengineering実践を混同する。

OAI-TQ14: 顧客環境で所有境界を保ってdebugする

根拠facts: OAI-T04, OAI-A02, OAI-W02.

対象職種・地域: Tokyo FDE / Tokyo Applied AI Engineer。SF FDSWEの顧客環境でのcodingは地域比較で、Tokyoの義務へ転用しない。

公式根拠: Tokyo FDE求人 · Tokyo Engineer求人 · SFのsoftware engineering求人.

想定質問（推論。公式の出題ではない）: 自分の環境ではprototypeが動き、顧客stackへ統合した後に失敗した。顧客と協働してどの順に調べ、最小限の安全な修正をどう選ぶか。

問いの狙い（推論）: access制約と複数担当がある状況のdebugを練習する。求人は顧客への入り込みとhands-on debugを支えるが、本番環境へ無制限にaccessできる権限を与えるものではない。

回答に含める証拠・数字・判断:

• identity/network、入力形、依存・設定version、data権限、runtime状態の差を書く。複数の条件を一度に変える前に、許可された最小再現で比べる。
• componentごとの担当と変更権限を指定する。自分が見られるもの、顧客engineerが実行するもの、環境外へ出せる根拠を分ける。
• 仮説、反証test、選んだ修正、回帰確認を示す。再現率、誤り件数、回復時間を使うならworkloadと期間を付け、顧客への引継ぎ文書も説明する。

深掘り 1: 失敗した本番dataにaccessできない場合はどうするか。

説明すべき点: 権限者に、合意した規則で秘匿済み症状・traceや合成再現を作ってもらう。失われる情報を明示し、許可入力で仮説を検証し、不足証拠に依存する結論は保留する。

深掘り 2: 一番速いpatchが顧客の統制を迂回する場合はどうするか。

説明すべき点: riskと統制担当を示し、範囲を限定した代替案や一時保留を比較する。例外は明示的に許可された判断とし、期限・撤去・検証を含める。迂回を技術detailとして隠さない。

避ける浅い回答: 「手元では動くので顧客環境が悪い」は、切り分け、権限境界、統合への責任を説明していない。

OAI-TQ15: 生成コードの量以外でCodexの業務改善を測る

根拠facts: OAI-C01, OAI-C02, OAI-C03, OAI-C04.

対象職種・地域: Applied AI Engineer, Codex — Tokyo。専門要件を全FDE求人へ外挿しない。

公式根拠: Tokyo Codex Engineer求人.

想定質問（推論。公式の出題ではない）: AI coding toolを使う開発teamで、review負担や危険な変更を増やさず、workflowが改善したことをどう示すか。

問いの狙い（推論）: Codex求人は開発task、自動grader、本番signal、feedbackを扱う。tool利用をengineering成果へつなぎ、生成行数や好感度を生産性と同一視しない練習である。

回答に含める証拠・数字・判断:

• 実teamの実装、test、reviewなど代表taskを選ぶ。難しさ、利用可能context/tool、期待するrepo/test動作を定義し、機密コードを許可境界内に保つ。
• 定めたtask setで受理変更までの時間、初回test/review結果、手戻り、流出不具合を比較する。作成者時間、reviewer時間、全体lead timeを分け、負担の移動を見えるようにする。
• 自動検証と開発者feedback、本番観測を組み合わせる。限界、tool利用時の失敗、有効な場面と制限すべき場面について本人の見解を示し、万能の改善を主張しない。

深掘り 1: testは通るが保守しづらい変更だったらどうするか。

説明すべき点: 要件、module境界、理由のない複雑さをreviewし、単純な変更と比較する。人のreviewで見つけた点とtaskの保守基準を示す。test成功は網羅した動作の証拠であり、全品質を保証しない。

深掘り 2: pilot参加者がtool好きの開発者ばかりだったらどうするか。

説明すべき点: 選択biasとtask構成を示し、許可されたより広い標本と比較可能baselineを使う。導入説明・支援時間を記録し、広い証拠が出るまで結論を対象groupに限定する。

避ける浅い回答: 「コードが増えたので生産性2倍」は、受理品質、review作業、測定比較がない。

判断を練習し、説明できなかった箇所を検証する

次は未実行の準備手順である。応募求人に合う3問を選び、まず1枚の境界図と測定recordを書く。次に声に出して答え、同僚に二つの深掘りを尋ねてもらう。根拠を示せなかった主張をすべて記録し、追加証拠を用意する、主張を狭める、提案と明示する、のいずれかを行って再度練習する。

比較sheetには構成・version、代表入力、指標定義、実測結果、失敗分類、その後の判断を残す。数字を開示できない場合は許可された範囲や正規化比較と限界を使う。面接資料へ機密コードや顧客recordを持ち込まない。安全に失敗した演習も、その範囲を説明できれば学習の証拠になる。

導入・協働の質問編で、技術成果物を顧客scope、利用定着、現場feedbackへ接続する。応募時には求人とround指示を再確認する。本稿の練習問題から、未確認の面接形式は確定できない。