Anthropic Applied AI・FDEの顧客delivery面接準備：根拠付き15問

顧客deliveryでは判断のownerを示す

以下の15問は職責から作った独自の練習問題で、公式質問一覧や採点表ではない。fact IDは2026-10-05確認の職種・選考事実編に対応する。TokyoのEngineer、pre-sales Architect、Partner Architectは担当が違う。US Technical Deployment Lead、New York Managerは別に表示し、SOW、ROI、配置責任を全FDEへ黙って移さない。

実際の判断、成果物、結果を使い、自分の寄与と他のownerを区別する。失敗したpilotでも、証拠によって計画をどう変えたかを説明できる。未記録の成果を見栄えのよい数字に置換しない。AI利用方針は2025-07-10最終更新と表示され、準備と改善を認める一方、持ち帰り・ライブ中の支援は明示許可が必要とする（A010〜A014）。応募の初稿は本人が書き、同じ証拠をAIなしでも説明する。

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

1. 1顧客の目的
2. 2workflowと関係者
3. 3scope・owner・成功指標

1. 1Engineer・Architect・Partner
2. 2職種ごとの寄与
3. 3deliveryの証拠

1. 1US TDLのscope・価値責任
2. 2FDEの技術実装
3. 3共同判断と引継ぎ

1. 1観測した結果
2. 2sponsorのreview
3. 3Productへの知見・次の案件

自作の責任・証拠フロー。US TDL/FDEの行はA067〜A071の明示された分担を表す。他の行は準備の整理で、全案件に共通の公式手順ではない。各矢印で「誰が決め、何の証拠を受け取り、何が変わったか」を答える。

AN-DQ01: なぜAnthropicで、なぜその職種か

対象と根拠: Tokyo Engineerまたはpre-sales Architect／応募先を一つ選ぶ — A004, A006, A007, A014, A018, A027, A028; All roles; technical roles where stated, All candidates, Applied AI Engineer, Applied AI Architect。

想定質問（独自推論）: Anthropicへの志望動機を、応募職種の具体的な仕事へどう結び付けるか。

確認しうる点（推論）: 一般的なAIへの関心ではなく、本人の経験と職種理解で動機を説明できるかを考える問い。

回答に含める証拠と判断: 有用性、信頼性、安全性について学んだ実際の判断を一つ選ぶ。自分の寄与、衝突した要望、考えを変えた証拠を示す。Engineerならpilot・実装、Architectならpre-salesの助言など、確認済み職責を一〜二点つなぐ。持ちたい責任と、今後伸ばす能力を説明する。公開応募欄の200〜400語という目安は、口頭回答時間の指定ではない。

深掘り:

1. 短期成果を求める顧客の要望と安全上の懸念が衝突したら？ 具体的な損失と証拠を示し、狭い範囲で価値を作る案を出す。権限のあるownerを交え、使命が判断をどう変えるかを説明する。全社共通の規則を作らず、全ての対立が拒否になるとも言わない。
2. 隣接するEngineer／Architectではない理由は？ 持ちたい責任と隣の職種の公式責任を比較する。実際の寄与で適合を示し、不足も認める。職種を序列化し、同じ面接だと決めつけない。

避ける浅い回答: 「先端AI企業で価値観に共感する」。本人の判断、確認した職責、その職種を選ぶ理由を添える。

AN-DQ02: 最初のpilotでどの顧客課題を選ぶか

対象と根拠: Tokyo Applied AI Engineer／AEとの協働と個別pilot — A019, A020, A025; Applied AI Engineer。

想定質問（独自推論）: AEが日本企業から複数のClaude用途を持ち込む。どのpilotを選び、期待をどうそろえるか。

確認しうる点（推論）: 技術discoveryを、根拠のある優先度と実現できる顧客への約束へ変えられるかを考える問い。

回答に含める証拠と判断: 実際の優先順位判断を使い、現行workflow、価値のowner、利用者の困り事、証拠、統合工数、失敗損失を用途間で比べる。検証できる価値仮説と、それを判定するsponsorを定める。pilotが何を示し何を示さないか、AE・顧客・Engineerの寄与を合意する。実在する事業指標を使い、全判断へlatencyの数字を押し込まない。

深掘り:

1. 簡単なdemoの事業価値が小さいなら選ぶか？ 必要な不確実性を解くのか、見栄えだけかを分ける。少し難しくても判断に効くpilotと、時間・依存関係を比較する。小さなpilotも導入判断を変える意味が必要。
2. AEが未検証の機能を約束していたら？ 約束の内容、証拠、顧客の期待をAEと早めに確認する。検証計画と可能なscopeを示し、顧客への訂正をそろえる。裏付けのない約束を黙って実装負担に変えない。

避ける浅い回答: 「ROIの高い用途を優先」。価値仮説、実現性の証拠、owner、合意した境界を示す。

AN-DQ03: 技術的な関心を企業の導入判断へどう進めるか

対象と根拠: Tokyo Applied AI Architect／pre-salesと複数関係者の企業購買 — A028, A030, A033; Applied AI Architect。

想定質問（独自推論）: engineeringはClaude評価を好むが、IT、事業sponsor、調達は別の証拠を求める。discoveryと購買判断をどう構成するか。

確認しうる点（推論）: 技術承認を購入と同一視せず、判断者、blocker、必要証拠をpre-salesとして特定できるかを考える。

回答に含める証拠と判断: 利用者、技術評価者、platform owner、sponsor、買い手、承認部門を実例のmapにする。各人の判断、懸念、証拠を示し、評価の依存関係を順に置く。AEとの分担と顧客の決裁権を説明する。meetingやartifactで何の判断が変わったかを記録する。求人から契約、価格、承認権限を推定しない。

深掘り:

1. 技術championがsponsorを得られないなら？ 業務課題と成果ownerを確認する。その人向けの短い判断資料を作り、追加技術作業で商業blockerが解けるかを確かめる。導入判断の責任者がいない追加作業は一旦止める。
2. 調達が終盤に入りscheduleを変えたら？ 依存と影響を見える形にし、必要証拠を確認して顧客・AEと計画を直す。技術milestoneと購入の約束を分け、自分が制御できない調達結果を約束しない。

避ける浅い回答: 「全関係者と関係を築く」。各関係が支える判断と証拠の順を述べる。

AN-DQ04: 一つの技術的な遅れを二つの相手へ説明する

対象と根拠: Tokyo Engineer・Architect／必須の日英能力と相手別の説明 — A023, A031, A034; Applied AI Engineer, Applied AI Architect。

想定質問（独自推論）: 同じ展開上の問題を経営者とengineering leadへ説明し、意味の一致した日英の引継ぎを作る。

確認しうる点（推論）: 詳細を変えても、事実、不確実性、次の判断を保てるかを考える。語学要件は実際の面接言語・形式を確定するものではない。

回答に含める証拠と判断: 実際の問題から、観測、影響、既知、不明、代案、ownerという共通の事実を作る。経営者には業務への影響と必要判断、技術者には失敗した境界と再現を伝える。短い日英の用語表を作り、risk、日付、約束の意味をそろえる。英語版だけ確信を強めない。

深掘り:

1. 裏付けられない完了日を経営者に求められたら？ 既知の点、見積りを阻む依存、次の証拠確認を示す。ownerを伴う条件付きの案を出し、自信を見せるため日付を作らない。
2. meetingでengineering leadが説明に反対したら？ 観測、原因、優先度のどこが違うかを分ける。証拠を確認し、誤った主張は明確に直す。不明な仮説は追跡事項にし、meeting後も顧客へ伝える事実を一致させる。

避ける浅い回答: 簡単な説明のため不確実性を消す、流暢な言語だけで技術的対立が解けるとする。

AN-DQ05: 矛盾する成功条件をどう調整するか

対象と根拠: Tokyo Engineer／Architect：部門間trade-offと顧客助言 — A025, A030, A031; Applied AI Engineer, Applied AI Architect。

想定質問（独自推論）: 事業sponsorは早い導入、ITは承認済みの狭い構成、利用者はpilot範囲外の変更を求める。どう進めるか。

確認しうる点（推論）: 全てを同時に約束せず、優先度の衝突を明示して責任ある判断を得られるかを考える。

回答に含める証拠と判断: 実際の対立で、各人の目的、変えられない制約、決裁権を示す。事実の不一致と好みの違いを分ける。scope、工数、riskの結果を付けた可能な案を示し、決定記録と先送り項目を述べる。顧客policyや全関係者への権限を持つとはせず、自分の調整責任を説明する。

深掘り:

1. 縮小scopeを誰も受け入れないなら？ 価値仮説がまだ成立するかを確認する。未決の選択をownerへ上げ、判断を変えられる場合だけ期限付きdiscoveryを提案する。裏付けのない約束より、明確な停止が適切なこともある。
2. sponsorは満足したがworkflowが使えなくなったら？ operatorの意見や業務試行を判断へ持ち込む。導入への圧力と有用な作業完了を分ける。妥協を再検討する証拠と、利用者の代表方法を述べる。

避ける浅い回答: 「関係者をalignする」。未決の選択、owner、受け入れた結果、先送りした仕事を示す。

AN-DQ06: go-liveを継続利用へどう変えるか

対象と根拠: Tokyo Applied AI Engineer／onboardingと稼働後の継続助言 — A020, A021, A025; Applied AI Engineer。

想定質問（独自推論）: 評価を通過して稼働したpilotで、利用者が旧workflowへ戻り続ける。何を調べて変えるか。

確認しうる点（推論）: 技術公開と顧客の有用な利用を分け、業務運用のownerと進められるかを考える。

回答に含める証拠と判断: 実rolloutまたは計画として、利用開始、結果review、error対応、supportまで利用者の経路を追う。評価結果と、利用、task完了、手戻り、避ける理由を比較する。すぐmodel調整へ行かず、training、業務適合、access、ownerの不足を探す。顧客運用owner、support範囲、review時期を合意し、利用成果は対象人数と期間を伴って述べる。

深掘り:

1. 利用は増えたが手戻りも増えたら成功か？ 有用な完了と総人手をbaselineと比べる。失敗分類と利用を増やすincentiveを確認し、workflow、support、評価のどれを変えるかを述べる。利用量だけでは価値を示せない。
2. いつまでも個人のsupportを求められたら？ 実際のsupport合意と担当teamを確認し、手順と未解決事項を文書化して顧客ownerと引継ぎを設計する。契約上のservice levelを作らず、自分が作った依存を突然切らない。

避ける浅い回答: 「trainingして利用が増えた」。業務上の問題、運用owner、有用な完了の証拠を示す。

AN-DQ07: agent案件を合意したscope内に保つには

対象と根拠: US Technical Deployment LeadとFDEの協働／SOW所有はTDL — A067, A068, A071; Technical Deployment Lead。

想定質問（独自推論）: USのTDL/FDE分担で、SOWを順序ある実装計画へ変え、新しい顧客要求をどう扱うか。

確認しうる点（推論）: 全契約責任をFDEへ移さず、scope・変更のownerと技術作業を結び付けられるかを考える。

回答に含める証拠と判断: TDL経験なら合意成果、除外、milestone、依存、成功条件、決裁権を示す。FDE経験ならownerへ渡した技術見積りとriskを示す。一要求を成果物と受入れ証拠まで追い、新要求がcritical path、scope、承認へ与える影響を述べる。実際に参加した場合だけ契約変更を説明し、code実装を理由にTDL責任を経験したことにしない。

深掘り:

1. code量は小さいが外部承認が変わる要求なら？ 承認依存、test範囲、顧客判断を見積りへ含める。無害なcoding taskとして受けず、日程・risk変更をTDLへ示す。sizeは行数だけではない。
2. milestone日は固定、実装見積りは増えたら？ 受入れscope縮小、順序変更、日付見直しを技術影響付きで示す。権限あるlead・顧客ownerに判断を求める。先送り作業と改訂した受入れ証拠を残す。

避ける浅い回答: 「FDEが全てend-to-endで持つ」。出典は技術実装とTDLのscope・関係者・価値責任を分けている。

AN-DQ08: ROIを過大にせず価値を測るには

対象と根拠: US TDLが価値測定を所有／FDEは実装・評価の証拠を提供 — A067, A069; Technical Deployment Lead。

想定質問（独自推論）: sponsorがagent導入の採算を尋ねる。baseline、変化、不確実性をどう定義して報告するか。

確認しうる点（推論）: accuracy改善を架空の削減額に置き換えず、事業価値を根拠のある測定として示せるかを考える。

回答に含める証拠と判断: 価値owner、元のworkflow、件数、観測期間、review・例外を含む総人手と運用工数を示す。価値仮説、観測影響、因果の主張を分ける。仮想worksheetで一日80件、旧12分、新8分に追加review2分なら、他costを除く削減時間は80×(12−10)=160分／日になる。数字は演習用で顧客実績・会社目標ではない。件数の確認方法と、空いた時間が実際に使われたかを説明する。

深掘り:

1. throughputが増えても人員が変わらない場合は削減額と言えるか？ capacity、経過時間、cash削減、qualityを分ける。実現した結果と価値ownerを示し、理論上の時間を組織の使い方の証拠なしにcost削減へ換算しない。
2. 同時に別の業務変更もあったらどう帰属させるか？ 可能な範囲でcohort・期間を比較し、交絡を記録して推論範囲を述べる。確実な観測と追加証拠が必要な因果主張を分ける。裏付けのない精密ROIより、透明な幅が役立つ場合もある。

避ける浅い回答: 「accuracyが上がったので30%節約」。baseline、review工数、実現結果、不確実性を説明する。

AN-DQ09: security reviewの遅れは何を変えるか

対象と根拠: US TDL/FDE協働／security・法務・調達・compliance依存 — A068, A070, A071; Technical Deployment Lead。

想定質問（独自推論）: agentの技術実装はできたがsecurityや調達reviewが未決である。delivery計画をどう変えるか。

確認しうる点（推論）: 企業の制約をdeliveryの一部として扱い、権限と技術証拠を明示できるかを考える。法的助言ではない。

回答に含める証拠と判断: 未決の判断、owner、必要証拠、対象環境、critical pathへの依存を特定する。FDEなら技術境界、許可data・操作、test証拠を示し、TDLなら順序、scope、関係者の判断を示す。制限付きdemo、展開縮小、milestone延期は顧客要件を満たす場合の選択肢として比較する。求人からdata residency、retention、compliance規則は確定できない。

深掘り:

1. 小pilotなのでreviewを省こうとsponsorに言われたら？ その環境へ適用するpolicyと権限を確認する。成立する場合に、正式承認された限定scopeや合成demoを提案する。小規模だから適合済みとはせず、責任あるownerの判断を得る。
2. 予定設計にないcontrolをreviewerが求めたら？ 検証できる要件へ翻訳し、設計変更か要件確認かを判断してTDLへ影響を渡す。解決証拠と受入れownerを追跡し、欠けたcontrolを口頭の安心説明で置換しない。

避ける浅い回答: 「complianceを通過した」だけ。実際のreview、範囲、owner、証拠を示す。

AN-DQ10: partnerのAI提供能力をどう伸ばすか

対象と根拠: Tokyo Applied AI Architects, Partner／partner向けpre-sales — A037, A038, A039, A041, A042; Applied AI Architects, Partner; body: Partners Solutions Architect。

想定質問（独自推論）: GSIまたはcloud partnerがClaudeの実践組織を作りたい。一案件で終わらない技術育成と共同solutionをどう選ぶか。

確認しうる点（推論）: 一顧客のprototypeだけでなく、間接的に提供する経路と能力を育てられるかを考える問い。

回答に含める証拠と判断: partnerの対象顧客、現有skill、提供上の不足、共同機会を示す。範囲を区切った業界用途、reference architecture、育成演習をpartner側ownerと選ぶ。移転する能力、独力提供の確認、Productへのfeedbackを説明する。partner売上目標と技術育成の証拠を分ける。求人はFDE ICのquotaを公表していない。

深掘り:

1. 参加人数を能力の証拠として求められたら？ 参加は活動指標として残す。顧客に関連する実装、review、独力で完了した演習を能力の証拠へ加える。評価した役割と支援が必要な不足を記録する。
2. 案件は多いがpartnerの提供capacityが足りないなら？ 顧客価値、技術準備、delivery owner、再利用できる学びを機会間で比べる。partner・GTM ownerと現実的な順序を合意する。過剰な約束が提供と育成の両方を損なう理由を説明する。

避ける浅い回答: 「partnerを育成し売上を作った」。変わった能力、独力提供の証拠、自分の寄与を示す。

AN-DQ11: partner主体の案件へどこまで介入するか

対象と根拠: Tokyo Partner Architect／partnerが主提供者となる戦略案件 — A039, A040, A042; Applied AI Architects, Partner; body: Partners Solutions Architect。

想定質問（独自推論）: 顧客期限が迫るpartner主体の戦略案件に技術blockerがある。全deliveryを自分へ依存させず、どう介入するか。

確認しうる点（推論）: 直接の障害解決と長期的なpartnerの責任を両立できるかを考える問い。

回答に含める証拠と判断: 実介入または仮想例で、blocker、顧客影響、partnerの提供責任、自分へのescalation権限を示す。判断を進める最小の直接寄与を選び、partner技術ownerと組み、検証できる説明やreference artifactを残す。partnerに残る責任、顧客への約束、通常supportへ戻す方法を記す。Architectが恒久実装ownerになるとはしない。

深掘り:

1. 全実装を引き取ってほしいと言われたら？ 顧客riskと実際の提供合意をownerと確認する。選択肢、resource、引継ぎの影響を示し、明示的な責任変更を求める。期限が近いという理由で隠れた責任移転を受けない。
2. 修正は動くがpartnerが説明できないなら解決か？ その場の技術復旧と保守できる提供を分ける。原因と検証をpartnerとたどり、該当testを独力で再現してもらい、残るsupportを記録する。自分の一回の成功だけで引継ぎ完了にはしない。

避ける浅い回答: 「partnerの代わりに解決した」。限定した介入と、その後partnerが持てる責任を述べる。

AN-DQ12: Product・Engineeringへ戻すfield証拠は何か

対象と根拠: Tokyo Architect・London FDE／field feedback責任 — A032, A046; Applied AI Architect, Forward Deployed Engineer。

想定質問（独自推論）: 複数案件で同じ統合問題を見つけた。顧客要望の一覧で終えず、使えるproduct feedbackへどう変えるか。

確認しうる点（推論）: field経験を別teamの判断に役立つ、範囲と再現のある情報へ変えられるかを考える。

回答に含める証拠と判断: workflow、観測、環境、頻度、影響を、許可された再現と反例で示す。product不足、顧客設定、pattern不足を分ける。機会、回避策、そのcost、不確実性を示し、受取teamと追跡ownerを定める。担当teamが決める前に顧客へroadmap変更を約束しない。

深掘り:

1. 大顧客だけが必要とする機能はproduct優先事項か？ その顧客の価値の証拠と一般需要の不確実性を分ける。限定field solutionとproduct開発を比較し、優先度ownerを示す。顧客規模だけでは再利用するproduct要求を証明できない。
2. Productが要求を断ったら顧客へどう返すか？ 共有できる実際の判断と理由を伝え、可能な代案と回避策の限界を示す。再検討を正当化する新証拠を記録し、承認されたように伝えない。

避ける浅い回答: 「Productへfeedbackした」。証拠、求めた判断、受取owner、結果か未決事項を示す。

AN-DQ13: 希少なFDE skillを案件へどう配置するか

対象と根拠: New York FDE Manager限定／技術配置とteam成長 — A063, A064, A065, A066; Manager, Forward Deployed Engineering。

想定質問（独自推論）: 二つの戦略顧客が同じ経験豊富なFDEを必要とする。技術品質とteam育成を保って配置するには。

確認しうる点（推論）: 緊急案件へ強い個人を送るだけでなく、品質と成長を組織の判断として扱えるかを考える。

回答に含める証拠と判断: 実際のmanagement経験で、案件risk、必要skill、継続性、育成需要、支援可能性を示す。配置案、判断権限、見直し時期を説明する。Engagement Managerと案件運営・関係者を調整しつつ、技術品質とteam成長の責任を保持する。監視した点と配置変更の条件を述べ、ICとして協働しただけの経験をpeople managementへ換えない。

深掘り:

1. 両顧客が最優先を主張したら誰が決めるか？ 技術riskと配置trade-offを、権限ある優先順位ownerへ示す。顧客の急ぎ、必要専門性、可能な約束を分ける。順序とescalationを記録し、矛盾する約束の裁定をteamへ押し付けない。
2. 育成中のengineerに経験が必要でも案件が高riskなら？ 範囲、監督、reviewを設計し、裏付けのない責任を渡さず成長を支える。seniorが介入する条件と準備度の評価を示す。skill不足を隠して育成とはしない。

避ける浅い回答: 「最強のengineerを置く」。代案、監督、継続性、team全体への影響を説明する。

AN-DQ14: 強い個人がいなくても技術品質を保つには

対象と根拠: New York FDE Manager限定／player-coach・採用育成・品質 — A063, A064, A065; Manager, Forward Deployed Engineering。

想定質問（独自推論）: 少人数のFDE teamが一人の卓越したengineerへ依存して成功している。review、育成、再利用assetで再現性をどう作るか。

確認しうる点（推論）: Manager個人の出力だけでなく、仕事の仕組みと人の能力を変えられるかを考える問い。

回答に含める証拠と判断: 実際の属人化について、集中した知識、review判断、顧客関係を示し、分散させたreview基準、pair作業、coaching、assetを説明する。自分がhands-onで入る場面と他engineerへ判断を持たせる場面を分ける。観測した能力変化と残る不足を示し、採用計画と実際の採用結果も区別する。

深掘り:

1. 自分が介入する方が毎回速いなら引き取り続けるか？ その場の提供とteam自律性・riskを比べる。自分のreviewが必要な判断と、feedback付きで委譲できる判断を定める。個人throughputだけで成功を測らず、繰り返す依存を減らす計画を示す。
2. templateで動くが本人が理解していないなら？ 制約を変えて修正し、前提と失敗を説明してもらう。template利用だけでなくcode・architecture reviewと観測した判断を使う。具体的な育成作業を決め、証拠で再評価する。

避ける浅い回答: 「基準を上げmentoringした」。変えた実務と、それで生まれた能力を具体化する。

AN-DQ15: この求人の準備前に何を確認するか

対象と根拠: 候補者から採用担当への確認準備／Tokyo・London・Munich・USを分ける — A002, A003, A012, A013, A026, A036, A047, A049, A051, A052, A062; All roles; technical roles where stated, All candidates, Applied AI Engineer, Applied AI Architect, Forward Deployed Engineer, Forward Deployed Engineer, Applied AI Engineer, Enterprise Tech。

想定質問（独自推論）: 職責、地域条件、評価中のtool規則を踏まえた準備計画にするため、採用担当へ何を尋ねるか。

確認しうる点（推論）: 文書上の不確実性を見つけ、範囲を絞った確認ができるかを考える。候補者の準備promptで、公式に面接で聞かれる質問ではない。

回答に含める証拠と判断: 正式職名、求人ID、勤務地を特定する。実装・助言の責任、内部level、面接形式、各評価で許可するtoolを尋ねる。Londonは本文4年以上と応募欄8年以上、MunichはnativeとC1を示す。顧客出張とoffice出社を分け、USの週3日をTokyoへ移さない。AI方針では資料lookupをlive-AI許可に変えない。

深掘り:

1. 採用担当がAI可と言ったら全roundで十分か？ 該当評価、許可支援、開示要否を課題の書面指示で確認する。職種全体の会話が、狭い指示を黙って上書きするとはしない。基本の制限が残るroundではAIなしで練習する。
2. 応募期限まで不一致が解けなければ何を述べるか？ 実経験を正しく記し、求人IDと矛盾fieldを示す。正式な経路で確認し、年数を作り、levelを推定し、意味が未決の条件を満たすと断定しない。

避ける浅い回答: 「全FDE面接は同じ」「職場でClaudeを使うから面接中もAI可」。公開されたscopeとpolicyの区別が消える。

オフラインworksheet：仕事を変えた合意を示す

一つの実案件について、顧客の目的、技術制約、商業・運用制約、owner、代案、選んだscope、baseline、観測結果、未解決リスクを表にする。説明を許されるartifactだけを添える。自分の仕事、チームの仕事、sponsorの判断を区別し、測っていない削減額は不明にする。

reviewerに依存関係、成功指標、職種の境界を一つずつ問い直してもらう。独自のオフライン演習で、実際の面接ラウンドではない。該当経験がなければ仮想scenarioと明示し、集める証拠を述べる。management、契約、本番実装の実績の代わりにはならない。同じprojectに証拠がある範囲で技術編へつなぐ。