Anthropic Applied AI・FDEの技術面接準備：根拠付き15問

求人を選び、一つの判断を説明する

以下は公式に公表された面接問題ではなく、職責から作った想定質問である。問いの狙いも編集上の推論で、公開された採点基準ではない。fact IDは2026-10-05確認の職種・選考事実編に対応する。内部の選考順や合格閾値は仮定していない。

実装の主な参照先はTokyo Applied AI Engineer。Tokyo Architectは明示的にpre-salesである。London FDEやSydney Engineerに基づく問は対象を付記する。LondonのMCP責任をTokyoで確定した試験内容にしない。回答は実際に寄与したprojectで作る。prototypeやオフライン演習までならその範囲を述べ、架空の本番成功例を使わない。

候補者のAI利用方針は2025-07-10最終更新と表示される（A010〜A014）。準備や表現の改善は認められるが、持ち帰り課題・ライブ面接は明示許可なしにAIを使わない。AIなしでも練習し、課題ごとの許可範囲を確認する。一般の調べ物許可は、この境界を変えない。

入出力契約、評価、回復、関係者の判断には会社間で共通する実務がある。職責の事実によって強調する責任を選び、Anthropic独自の手法を作らない。

1. 1応募求人とfact ID
2. 2自分のproject証拠
3. 3判断と退けた代案

1. 1判断
2. 2評価と失敗例
3. 3実装と回復
4. 4ownerと引継ぎ

1. 1AIなしの練習
2. 2深掘りで制約を変える
3. 3不足する証拠を補う

自作の準備フローで、Anthropicの選考ラウンドではない。入力、権限、測定、失敗時の動きをつなぐと、技術的な判断を説明できる。深掘りで制約が変わったら、変更する判断と、まだ必要な証拠を分ける。

AN-TQ01: 手作業の振り分け業務のどこへClaude pilotを置くか

対象と根拠: Tokyo Applied AI Engineer／日本企業のpilot — A006, A019, A020, A025; All roles; technical roles where stated, Applied AI Engineer。

想定質問（独自推論）: 日本企業が依頼を人手で分類している。最初にClaudeで支援する工程と、そのarchitectureをどう決めるか。

確認しうる点（推論）: 複雑なagent構成を先に選ばず、曖昧な顧客要望を小さく検証できる実装へ落とせるかを確かめるための問いである。

回答に含める証拠と判断: 実際に観察したworkflowを使い、入力項目、担当者の判断、後続システム、件数、誤分類の損失を示す。権限のある入力を受け、担当者が検査できる提案を返す最小interfaceを描く。AIなしのbaseline、改善する判断、停止条件を決める。誰がpilotの境界に合意し、何の統合を後へ送ったかまで説明する。記録された件数・期間だけを実績に使い、作った例は演習と明示する。

深掘り:

1. sponsorが最初から全工程の自律agentを求めたら？ 達成したい結果と指定された実装方式を分ける。影響が大きい操作を特定し、提案だけのpilotと自動実行を比較する。権限拡大に必要な証拠、sponsorの判断、未解決の依存関係を記録する。
2. 一部署だけで成功したら横展開できるか？ 次の部署の入力分布、利用者、失敗損失を比較する。最初のcohortで成立した前提、再検証する点、展開の判断者を示す。一部署の成功を全体の準備完了に拡張しない。

避ける浅い回答: 「agentを作りpromptを最適化する」で止める。業務、baseline、権限、検証する判断が見えない。

AN-TQ02: 導入判断に使う評価suiteへ何を入れるか

対象と根拠: Tokyo Engineer／Architect：顧客用途に固有の評価 — A018, A020, A030; Applied AI Engineer, Applied AI Architect。

想定質問（独自推論）: demoでは役に立つpilotを、顧客が導入判断に使える評価suiteへどう変えるか。

確認しうる点（推論）: 説得力のあるdemoと、実際のworkflow・失敗損失を覆う証拠を区別できるかを考える問い。

回答に含める証拠と判断: 実際の評価setについて、抽出期間、caseの出所、利用できるdata、期待結果、reviewer、判断不一致の扱いを示す。頻出caseと低頻度でも損失が大きい失敗を分ける。現行業務と比較し、割合だけでなく分母と件数を出す。根拠がある場合は不確実性の幅も述べる。平均scoreを展開許可とせず、合否を決めたownerと判断を説明する。

深掘り:

1. 顧客がaccuracy一つを求めたら？ 全体値と分母を示した上で、重大なsliceと許容できない結果を添える。除外したcase、曖昧なcaseの判定者、平均値では免除できない失敗条件を説明する。
2. Salesが選んだdemoだけでsuiteを作っていたら？ demo用のsetと表示し、代表case・厳しいcaseを別に集める。最終holdoutへの調整を避ける。選定biasを記録し、広い証拠が揃うまで待つ導入判断を示す。

避ける浅い回答: 「accuracyが上がった」だけで終える。case選定、分母、失敗分類、判断基準がない。

AN-TQ03: 既存基盤への統合障害をどう切り分けるか

対象と根拠: Tokyo Applied AI Engineer／既存企業基盤への統合 — A021, A025; Applied AI Engineer。

想定質問（独自推論）: prototypeでは動いたClaudeが顧客の既存システムにつなぐと失敗する。どのように原因を分けて解消するか。

確認しうる点（推論）: 全てをモデルの問題にせず、失敗した境界と担当者を特定して進められるかを考える問い。

回答に含める証拠と判断: 実際のinterface図と機微情報を伏せた失敗traceを示す。入力・schema、identity・権限、上流の稼働、モデル出力、後続の書込みを分ける。再現方法、最小の切分けtest、owner、修正確認を説明し、記録があれば影響件数と期間を示す。再現の必要性だけでアクセス範囲や本番data持出しを広げない。

深掘り:

1. 顧客の本番logを入手できない場合は？ 許可された匿名化例、または顧客が実施する診断を依頼する。同じ形の合成入力で再現し、fixtureが示せる結論と未確認の本番条件を分ける。本番で検証済みとはしない。
2. 回避策にservice accountの権限拡大が必要なら？ 不足する操作とresourceを特定し、限定的な権限変更と設計変更を比較する。顧客の権限ownerを交え、必要操作の成功と範囲外操作の拒否を確認する。暫定策かも記録する。

避ける浅い回答: 「promptを改善した」で済ませる。requestがどの境界で止まったかの証拠が必要。

AN-TQ04: 小さなPython実装と失敗を説明できるか

対象と根拠: Tokyo EngineerのPython準備／一般技術面接の案内。確定した試験課題ではない — A002, A003, A012, A013, A022; All roles; technical roles where stated, All candidates, Applied AI Engineer。

想定質問（独自推論）: オフライン演習として、顧客recordから検証済み結果へ変換する処理を作り、不正recordと重複入力の扱いを説明する。

確認しうる点（推論）: Pythonへの習熟を、data契約、読めるcode、境界caseの判断として示せるかを考える。これは独自の練習課題。

回答に含める証拠と判断: 実装前に入力型、許容field、validation error、出力時の動きを定義する。慣れた標準libraryで小さく作り、正常、field欠落、型違い、重複をtestする。重複排除の場所、部分成功の可否も説明する。AIなしで声に出して練習し、資料lookupとAI許可を分ける。Colab/CodeSignalは一般ページの例で、この問題が出るという意味ではない。

深掘り:

1. 一件の失敗でも正常recordを残したいと言われたら？ recordごとのstatusとerror表現、順序、呼出し側のretryを定める。失敗recordが消えず見えることを示し、元の全件成功／失敗契約を変えた理由を説明する。
2. 入力がmemoryに収まらなくなったら？ 実測sizeと必要な順序を確認し、streaming、上限付きbatch、重複排除の外部stateを比較する。memoryと時間、回復のtrade-offを述べ、該当volumeを試さずscaleを実証したことにしない。

避ける浅い回答: library名を並べ、入力、error、test、計算量を説明しない。調べ物可を理由に評価中のAI利用へ広げない。

AN-TQ05: promptを直し続けるのを、いつ止めるか

対象と根拠: Tokyo Engineerのprompting／London FDEの高度なprompting背景 — A006, A019, A048; All roles; technical roles where stated, Applied AI Engineer, Forward Deployed Engineer。

想定質問（独自推論）: 特定の依頼群で顧客solutionが繰り返し失敗する。prompt変更、入力の改善、システム設計の変更をどう選ぶか。

確認しうる点（推論）: promptingを万能の修理手段にせず、比較実験で原因を見つける姿勢を考える問い。

回答に含める証拠と判断: 実際に調べた失敗について、入力、期待結果、失敗分類、固定した比較caseを示す。一度に一変数を変え、改善case、回帰、latency、作業量を記録する。証拠不足、曖昧なtask、不可能な要求、モデル外の実行失敗を区別する。prompt変更を止めた証拠と代案の合意者を述べる。

深掘り:

1. 長いpromptでdemoだけ改善し、他で悪化したら？ 同じcaseで比較し、変更した指示と回帰sliceを記録する。task分割や決定的なvalidationを候補にし、許容するtrade-offを合意する。悪化例を隠さない。
2. 顧客の最新事実をモデルが知らない場合は？ 証拠がない問題と指示に従わない問題を分ける。権限のある情報源と「証拠不足」を返す方法を検討し、retrievalや顧客側lookupとprompt変更を比較する。これは設計の提案で、Anthropicの製品defaultを断定するものではない。

避ける浅い回答: 「動くまで繰り返した」。比較条件と、promptでは解けなかった失敗を示す。

AN-TQ06: model・promptの変更をどう本番へ出すか

対象と根拠: Tokyo Applied AI Engineer／最近の本番LLM経験は優遇条件 — A021, A024; Applied AI Engineer。

想定質問（独自推論）: 稼働中の顧客workflowでmodelまたはpromptを更新する。本番反映判断と回帰時の回復をどう設計するか。

確認しうる点（推論）: 一度の展開成功だけでなく、変更管理と観測できる回復まで本番経験として説明できるかを考える問い。

回答に含める証拠と判断: 実際の変更について、入力、prompt、設定、評価caseのversionを示す。前のrelease、変更理由、quality・cost・latencyの測定差、合意した本番移行条件を述べる。限定展開、監視owner、戻す構成、拡大を止める条件を説明する。本番未反映の変更ならlocal検証と本番の証拠を分ける。

深掘り:

1. オフライン評価は改善したが利用者が不満を示したら？ 本番の利用群と評価set、workflow変更、発生時期を比較する。許可されたtraceで代表的な不満を調べ、qualityと使い勝手を分ける。前の構成を保持し、不足sliceを補うまで拡大しない。
2. rollbackすると新機能を失う場合は？ incident影響、対象cohort、新機能の利益、代案を顧客の判断ownerへ示す。暫定運用と連絡を説明する。戻せる変更でも判断を明示する。

避ける浅い回答: 「常に最新modelを使う」。顧客workloadに対する本番反映の証拠が必要。

AN-TQ07: 顧客の依頼が急増したらどう設計するか

対象と根拠: London FDE／本番アプリとscaleした展開 — A043, A048; Forward Deployed Engineer。

想定質問（独自推論）: 顧客内のアプリがpilot件数では動くが、急増時にlatency・budget目標を外す。どう調査し設計を変えるか。

確認しうる点（推論）: 展開のscaleをworkloadの形、resource制約、利用者への結果とつなげて考える問い。

回答に含める証拠と判断: 実際の環境で測ったピーク到着数、同時実行、入出力size、latencyの分位点、error件数、costの単位を示す。経路を待ち時間、model、tool、後続serviceへ分ける。受付上限、call削減、非同期化、適切な結果のcacheなどを比較し、各案で失うものを述べる。代表的なloadを試してからcapacityを主張する。

深掘り:

1. 平均latencyは良いが少数の利用群が長く待つなら？ tail、対象request群、利用者への影響を示す。queueや遅い依存先をその群で調べる。平均で隠さず、群別の上限や経路を選ぶ。
2. 合意したcapacityを超えた依頼はどう見せるか？ queue、拒否、縮小した処理のどれかを明示し、待ち時間上限と回復方法を決める。作業を保持し、重複した副作用を防ぐ。顧客ownerと許容する縮退を決め、全件完了したように見せない。

避ける浅い回答: 「infrastructureを増やす」。実際のbottleneckとquality・cost・応答性のtrade-offを示す。

AN-TQ08: 顧客MCP serverの境界は何か

対象と根拠: London FDE／本番MCP artifact。公開された試験課題ではない — A043, A044, A045; Forward Deployed Engineer。

想定質問（独自推論）: agentが業務システムの操作を必要とするとき、MCP serverの境界をどう設計して検証するか。

確認しうる点（推論）: toolを並べるだけでなく、契約と権限が限定された本番artifactとして考えられるかを問う推論。

回答に含める証拠と判断: 実例または仮想と明示した操作について、callerのidentity、許可resource、入力schema、出力、error、副作用を示す。readとwriteを分け、顧客の承認範囲へアクセスを結び、人の判断が必要な場所を述べる。validation、timeout、重複排除、機微情報を除いた観測を説明し、許可操作と別resourceへの拒否操作を示す。独自の設計観点で、Anthropicの実装defaultではない。

深掘り:

1. writeした可能性のあるcallがtimeoutしたら？ 観測できるoperation IDと、安全に完了照会できるかを示す。不明と失敗を分け、重複排除や照合なしに副作用を再実行しない。利用者への表示と不明状態を解決するownerを述べる。
2. 取得文書が別の操作をagentへ指示したら？ 文書をdataとして扱い、元のtaskと権限境界を維持する。tool境界で操作を独立に検証し、拒否testを示す。悪意ある内容を特権controlへ移さず、安全な結果を残す。

避ける浅い回答: 「MCPで何にでもつながる」。許可する契約と拒否する操作を具体化する。

AN-TQ09: sub-agentを分ける価値はどこにあるか

対象と根拠: London FDE／本番sub-agent artifact — A006, A045, A048; All roles; technical roles where stated, Forward Deployed Engineer。

想定質問（独自推論）: 調査、draft、承認を含む顧客workflowを、いつsub-agentへ分け、いつ単純な経路に保つか。

確認しうる点（推論）: 独立して進められる作業と測定できる利益に基づいて分け、最終結果のownerを保てるかを考える問い。

回答に含める証拠と判断: 単純なbaselineから始め、各taskの入力、権限、出力契約、依存関係を描く。並行できる工程と、他の結果や承認を待つ工程を分ける。同じworkloadでquality、経過時間、call数、調整失敗を比較する。不一致を検査し、作業を終了させるcomponentを示す。agentの数が増えれば性能も上がるとはしない。

深掘り:

1. 二つのsub-agentが逆の提案を返したら？ それぞれの証拠と不確実性を残す。workflowに応じ、決定的な整合check、証拠review、人の判断を決める。三つ目の生成意見だけで証拠が強くなるとはしない。
2. 一つが終盤で失敗したら全体を再開するか？ 有効な保存済み出力、失敗した依存関係、上限付きretryか明示的な部分結果を特定する。完了したwriteを繰り返さない。証拠が古くなり中間結果を使えなくなる条件も述べる。

避ける浅い回答: 「並列agentで速くなる」。baseline、調整cost、不一致の責任者が必要。

AN-TQ10: 再利用するagent skillをどうまとめるか

対象と根拠: London FDEのagent skill／US Engineerの再利用asset — A045, A046, A061; Forward Deployed Engineer, Applied AI Engineer, Enterprise Tech。

想定質問（独自推論）: 顧客で役立った手順をagent skillや同等の実行assetへまとめる。何を含め、限界をどう検証するか。

確認しうる点（推論）: 成功promptのcopyではなく、利用契約、証拠、保守を備えた再利用の仕組みとして考える問い。

回答に含める証拠と判断: 説明可能な手順を一つ選び、利用者、開始条件、入出力、必要環境、許可操作、失敗対応、ownerを記す。共通の指示・testと、顧客固有ID・秘密を分ける。実行すべきcase、断るcase、情報を求めるcaseを示す。依存先と合わせてversionを残し、変更reviewを定める。特定のskill file形式やAnthropic内部repoは仮定しない。

深掘り:

1. 別顧客の承認規則が違っても使えるか？ policyとして入力する部分と、変えてはならない動作を分ける。新しい顧客ownerに変更後の契約を確認してもらい、該当caseを再評価する。文章を再利用できても権限を再利用できるとは限らない。
2. 利用回数は多いが失敗率が不明なら成功か？ 利用と正しさを分ける。許可された結果sample、失敗分類、保守責任、取り下げ条件を決める。削減工数は測定した場合だけ示し、downloadやcall数だけでqualityを主張しない。

避ける浅い回答: 「promptをtemplateに保存した」。範囲、権限、失敗test、更新ownerまで必要。

AN-TQ11: そのworkflowで許容できない失敗は何か

対象と根拠: Tokyo Engineer・London FDE／信頼性と安全性の責任 — A007, A018, A044, A048; All roles; technical roles where stated, Applied AI Engineer, Forward Deployed Engineer。

想定質問（独自推論）: 平均qualityが良くても本番へ進めない失敗を、顧客workflowに対してどう定義しtestするか。

確認しうる点（推論）: 安全性・信頼性を実際の結果に結び付く本番移行条件へ変えられるかを考える。会社の採点表ではない。

回答に含める証拠と判断: 影響される人、data、操作を特定し、誤提案、権限外の開示、重複write、回復不能などを損失で分類する。各testの観測と、安全な終了結果を定める。モデルの提案と、applicationの権限check・人の判断を分ける。本番反映のownerとblockerを除く証拠を示し、全riskをaccuracy一つへ縮めない。

深掘り:

1. 納期のため顧客が口頭でriskを受け入れたら？ 具体的な結果、判断者の権限、顧客の適用要件を確認する。限定releaseやreview gateを提案し、未解決条件を残す。自分の権限を超える点はescalationし、急ぎを許可と扱わない。
2. まれな有害caseを安定して再現できない場合は？ 観測した証拠と不明なmechanismを残す。範囲を区切った検証や保守的なcontrolを加え、未確認事項、監視、停止計画を述べる。小sampleで出ないことを不存在の証拠にしない。

避ける浅い回答: 「safety best practiceに従う」。禁止する結果、testの観測、判断者を説明する。

AN-TQ12: 稼働後にworkflowが止まったら何をするか

対象と根拠: Tokyo Engineerの稼働後助言／London FDEの本番提供 — A021, A043, A044; Applied AI Engineer, Forward Deployed Engineer。

想定質問（独自推論）: 展開後、顧客workflowが途中で止まる。serviceを戻し、完了した作業を正しく把握するため何をするか。

確認しうる点（推論）: requestの再実行だけでなく、state、責任、安全な回復まで運用支援として説明できるかを考える。

回答に含める証拠と判断: 実際のincident、または机上scenarioと明示した例で、意図、完了工程、不明な副作用、影響利用者を許可された証拠から再構成する。緩和策、顧客incident owner、retry上限、照合を説明する。service復旧、data修復、恒久修正を区別し、既知の場合だけ時間と件数を出す。失敗を回帰setへ戻す。

深掘り:

1. 上流callは失敗したが後続systemが変わった可能性があるなら？ 対象operationと、安全な完了照会方法を特定する。不明作業は照合まで見える未解決状態に保つ。設計上使えるidempotency・重複排除を利用し、上流errorをwriteなしの証拠にしない。
2. 暫定策で手動reviewが必要になったら？ 手順、queue owner、処理capacity、escalation・終了条件を書く。担当者を育成し、代表的な回復を一件確認して恒久修正の優先度を合意する。緩和策は運用状態で、incidentが消えたことではない。

避ける浅い回答: 「restartして解決した」。復旧、dataの正しさ、原因、追跡ownerを分ける。

AN-TQ13: code-review workshopで顧客実装をどう変えるか

対象と根拠: Sydney Applied AI Engineer／workshop・code review。Tokyoの同一職責とは未確認 — A054, A055, A056; Applied AI Engineer。

想定質問（独自推論）: 本番評価と統合を改善する必要があるprototypeについて、顧客engineeringチーム向けhands-on workshopを設計する。

確認しうる点（推論）: 顧客が保守できないdemoで終えず、確認した技術変更と能力移転を残せるかを考える問い。

回答に含める証拠と判断: 実workshopまたは計画と明示した例で、参加者の出発点、codeの範囲、観測できる学習目標、利用dataを示す。小さな変更、code review、顧客が独力で実行するtestを設計する。残るartifact、保守owner、理解の確認方法を述べる。成果を出す場合は参加人数と正しく独力実行できた人数を分ける。

深掘り:

1. 上級者は理解したが運用担当は理解していないなら？ 実行・debugする役割を確認する。その人たちに演習、文書、ownerを合わせ、失敗への独力対応を確認する。上級者の承認を運用能力の証拠にしない。
2. workshop中に全て修正してほしいと言われたら？ 緊急blockerと合意した学習目標を分ける。移転できるpatternを一つ優先し、追跡作業と責任を残す。その場の修理と、次の変更を顧客が保守できることのtrade-offを説明する。

避ける浅い回答: 「trainingをした」。その後顧客が何をでき、その事実をどう確認したかを示す。

AN-TQ14: 何を繰り返し使える展開patternにするか

対象と根拠: London FDE・US Enterprise Tech Engineer／展開知識の再利用 — A046, A061; Forward Deployed Engineer, Applied AI Engineer, Enterprise Tech。

想定質問（独自推論）: 顧客実装が成功した後、どの技術要素を再利用patternへ変え、何を顧客固有として残すか。

確認しうる点（推論）: private codeの持出しや過剰なframework化を避け、前提、評価、保守を残して一般化できるかを考える。

回答に含める証拠と判断: 再利用を許可されたartifactを選び、domain前提、統合、設定、評価case、顧客の機微情報を分ける。一般性を確かめる二つ目の用途、必要依存先、失敗を説明する。文書recipe、library、templateを保守負担まで比較する。記録された場合だけ再利用の成果を示し、保守ownerと取り下げ条件を定める。

深掘り:

1. 一顧客でしか使っていないのにframeworkへ変えるか？ 前提を明示した限定recipeとして記録する。他の用途で何を確かめれば抽象化を正当化できるかを示し、一件の成功で一般性を主張しない。小さなartifactの方が保守しやすい場合もある。
2. 二顧客目で非互換の動作が必要なら？ 設定差、domain制約の違い、前提違反のどれかを確かめる。共通の抽象化が正しさを隠すならpatternを分ける。分割した証拠を示し、適用境界を更新する。

避ける浅い回答: 「全部一般化した」。一般化しなかったものと理由を示す。

AN-TQ15: 導入architectureを薦める前に何を聞くか

対象と根拠: Tokyo Applied AI Architect／明示的なpre-sales。API・Claude for Work — A028, A029, A030, A033; Applied AI Architect。

想定質問（独自推論）: Claude APIとClaude for Workを同時に検討する企業で、独自統合が必要な要望と、別の導入経路が合う要望をどう見分けるか。

確認しうる点（推論）: 全顧客にcustom codeを仮定せず、利用者、system、証拠からpre-salesの技術助言を組み立てられるかを考える。

回答に含める証拠と判断: 利用者、task、system、data境界、administrator、買い手、期待成果を整理する。従業員workflowと顧客向け製品統合を分け、各案で必要な製品動作・controlを現行docsや担当teamへ確認する項目として列挙する。用途別評価と実装ownerを提案する。求人からfeature同等性、license、data条件、展開機能を作らない。

深掘り:

1. 経営者が一製品で全用途を満たしたいと言ったら？ workflowごとの要件、統合、control依存と、各案で不足する証拠を示す。cost・複雑さは測定か推定かを明示する。全て解けると約束せず、小さな評価を提案する。
2. pre-salesの提案が自分の権限外の実装詳細に達したら？ 記録した要求と未解決の技術問いをEngineerやProduct ownerへ渡す。owner、前提、顧客の期待を引継ぎに残す。まだ検証が必要な主張を把握することも技術的な信頼につながる。

避ける浅い回答: 「開発者はAPI、他はWork」。利用者だけでは統合、control、価値の要件を決められない。

オフライン演習：技術回答を検証できる形にする

応募求人に合う問を一つ選ぶ。一枚に入出力の境界、自分の寄与、baseline、評価の分母と期間、失敗例、選んだ代案、本番反映／停止判断を書く。説明を許されるartifactとして機微情報を伏せた図、testの構成、判断記録などを一つ添える。顧客の秘密を開示しない。

AIなしで主回答を3分にまとめ、reviewerにどちらかの深掘りを選んでもらい、一つの制約を変える。独自の未実行の練習方法であり、3分は練習設定でAnthropicの面接時間ではない。根拠を示せなかった点を記録する。本番AIのcontrolで評価と権限を見直し、顧客delivery編では職種固有の責任を移さず練習する。