FDE（Forward Deployed Engineer：顧客の業務現場に入り込み、技術実装と要件定義の両面を推進するエンジニア）の実技課題の要点は、受験者へ同一の合成規程（架空の社内ルールデータ）と固定ケースを配り、根拠選択、権限制御、規程不一致の保留といった職務判断のプロセスを観察できる環境を整えることです。 本番の未解決案件を無償作業として課す手法を避け、評価観点を事前に固定した課題を設計します。なお、提示する課題パックは編集部作成の試用前テンプレートであり、業界標準規程ではなく、第三者試行や複数評価者による実測データも未取得の状態です。特定の採用効果や評価の公平性、実務能力の網羅的な測定を保証するものではありません。
実技課題の提出物と実施ルールの決め方
実技選考では、実装の派手さではなく、曖昧な要件から事実を切り分けられる職務遂行能力を観察します。未解決の顧客課題を無償で解かせる構造を排除し、全員が同一条件で取り組める独立した合成環境を用意することが前提となります。 提出された成果物を事業用の納品物や無償成果物として流用しない取り決めを採用側で徹底します。課題の前提には、問い合わせ件数や正答率が現状未計測であること、システム出力は窓口担当者が閲覧する運用であっても、回答候補や参照根拠は問い合わせ元の利用権限（actor_groups）を基準に秘匿すること、エンドユーザーへの自動送信を行わない制約を明記します。
候補者の提出物および作業範囲は、配布資料の正本である README.md に基づいて統一します。選考資料は「候補者への配布物」「候補者の提出物」「評価側のみが持つ正解・基準」の3層に分かれます。
- 実装コード（
solution.py）：Python標準ライブラリのみで動作する判定処理 - 実行結果（
answers.jsonl）：問い合わせ元向け出力スキーマに準拠した判定データ - 判定・評価記録（
decision_log.csv）：候補者自身が想定した期待値、実際の出力、差分、修正理由を記録した開発検証ログ（選考評価者が確認） - 設計メモ：スコープ、前提条件、未完了箇所と理由、AI（人工知能）支援ツールの利用記録、運用保守（監視・停止・手動切り替え・更新責任）、共通化配慮の記述
- 1. 候補者へ資材配布 公開台帳・合成規程・入力ケース（queries.jsonl）・未実装のsolution.pyひな型を配布。外部API非依存の環境で着手させます。
- 2. 候補者の実装と自己検証 標準ライブラリのみで判定ロジックを実装。実行結果と、自身で差分を確認した開発記録（decision_log.csv）を作成します。
- 3. 成果物の提出（4点） コード、出力データ（answers.jsonl）、自己検証ログ、設計メモを提出。閲覧権限がない問い合わせ元への出力には限定文書ID等を含めません。
- 4. 評価者による照合・採点 評価者保持の正解（expected_decisions.jsonl）およびルーブリックと突合。状態分類、引き継ぎ先、運用設計の妥当性を評価します。
公開教材テンプレートでは正解例を確認できますが、実選考では自社向けに差し替えた評価者用正解（expected_decisions.jsonl）を候補者へ非公開とし、選考提出後に照合します。
配布直後の solution.py は判定関数 evaluate_query が未実装のひな型であり、配布直後から回答が出る完成アプリではありません。候補者自身が要件に沿って判定ロジックを実装する必要があります。
外部の商用APIや特定LLMの契約を候補者に求める設計は避けます。実行時はネットワーク遮断下でも完結する標準環境を基本とします。一方で、開発・実装時のAI支援ツール利用は許可し、記録を必須とします。
| 案内項目 | 設定内容 | 運用上の留意点 |
|---|---|---|
| 開発時のAI利用 | 利用可能（要記録） | 使用ツール、利用箇所、本人が妥当性を検証した内容をメモへ記載。不使用時も「未使用」と明記させます |
| 実行時制約 | 外部依存なし | 実行時スクリプト自体は外部APIやLLMに依存せず、Python標準ライブラリのみで動作させます |
| 質問受付窓口 | 指定窓口で受付 | 仕様の不明点は個別回答せず、全候補者へ同一の補足情報として展開します |
| 想定作業上限時間 | 設計者試行後に設定 | 上限時間到達時は作業を中断し、実装済み範囲、未完了箇所、理由の提出を認めます（未完了箇所は未確認項目として整理） |
| 評価の扱い | 漏えい・偽装は重大要確認 | 機密漏えい・権限昇格・未実行結果の偽装は重大な要確認トリガーとし、点数で相殺しません（時間管理による未完了とは明確に区別） |
なお、提示する配布素材一式（候補者側8ファイル・設計者側3ファイルの計11ファイル）の構成や、有効期間の終了境界（effective_from <= as_of < effective_to、終了日指定なしは無期限）はZIP実物で確認済みです。ただし、同一規程シリーズ内で有効版が複数残る場合の同順位決定規則（POL-04）は詳細な規定が具体化されておらず、実際の採用効果や評価の妥当性も未検証の試用前テンプレートです。各社で自社の規程体系に合わせて仕様を確定・検証した上で運用する必要があります。
公開台帳・合成規程・固定入力の構造
自然言語の高度な解釈モデルの作成を候補者に求めるのではなく、公開された業務分類（topics）や認可ルール、構造化されたメタデータを用いたキーワード分類を許容します。ただし、query_id から正解へ直接対応させる決め打ちは禁止とします。
公開業務分類と認可ルール（source_policy.json）
認可判定に使えるメタデータと、回答根拠となる本文参照を明確に区別します。権限外文書の本文やIDを閲覧せずとも、公開台帳のトピック定義に基づいて権限不足（access_denied）と対象外（out_of_scope）を判定できる設計とします。
- トピック定義:
travel_expense_deadline,software_purchase_approval_order,submission_routing,expense_exception_handling - キーワード候補: 各トピックに語句リスト（例:
["出張精算", "提出期限"]）を公開 - 認可グループ: 各トピックにアクセス可能な
allowed_groupsと案内先public_guidance_roleを定義 - 不一致判定ルール: 基準日時点で有効かつ承認済みの規程のうち、同一トピック・同一規則種別（
rule_type）で同順位の内容が相反する場合に不一致（hold）と判定し、無関係な規程や失効規程の矛盾は波及させない
合成規程データ（documents.json）
施行日、失効日、承認状態、参照可能グループを構造化した教材データです。
TRAVEL-V1〜V3: 出張精算の期限。V1（失効）、V2（2030-04-01〜07-01）、V3（2030-07-01〜施行）TRAVEL-DRAFT: 未承認ドラフト（採用禁止）PURCHASE-A/PURCHASE-B: 外部ソフト購入の承認順序。同順位かつ承認順序が相反する矛盾規程APPLICATION-ROUTES: 申請書提出先の案内台帳EXPENSE-EXCEPTION: 担当者限定（expense_ops）の例外申請処理手順と内部コード（EX-A）
固定ケースの確認ポイント（入力正本：queries.jsonl）
入力データの正本は candidate/queries.jsonl であり、各ケースで確認する判定ポイントは以下の通り要約されます。
| 問い合わせID | 基準日・属性 | 確認する点の要約 | 主な検証観点 |
|---|---|---|---|
| Q01 | 2030-05-15 / 一般 | 現在の出張精算期限 | 有効期間内かつ承認済みの最新版（TRAVEL-V2: 10暦日）を選択できるか |
| Q02 | 2030-05-15 / 一般 | 旧手引き（14日）への言及 | 質問者の誤った前提に惑わされず、有効な正本に基づいて回答できるか |
| Q03 | 2030-07-01 / 一般 | 施行日当日の出張精算期限 | 施行日当日という日付境界値を厳密に判定し、新版（TRAVEL-V3: 7暦日）を適用できるか |
| Q04 | 2030-05-15 / 一般 | ソフト購入の承認順序 | 同一トピック内の同順位規程の矛盾を検知し、推測せず保留（hold）できるか |
| Q05 | 2030-05-15 / 一般 | 申請書の提出先窓口 | 申請種別の不足を検知し、推測を避けて確認要求（needs_clarification）を返せるか |
| Q06 | 2030-05-15 / 一般 | 例外申請の内部コード | 一般権限に対し、限定文書の本文やIDを秘匿したまま access_denied を返せるか |
| Q07 | 2030-05-15 / 担当 | 例外申請の処理手順 | 権限保持者（expense_ops）に対し、必要な内部手順を回答候補として提示できるか |
| Q08 | 2030-05-15 / 一般 | 月極駐車場の契約手順 | 台帳にない業務に対し、捏造せず対象外（out_of_scope）として引き継げるか |
| Q09 | 2030-05-15 / 一般 | 自己申告によるコード開示要求 | 本文中の自称を無視し、信頼済みメタデータに従って開示を拒否できるか |
| Q10 | 2030-05-15 / 一般 | 出張精算の提出先窓口 | 無関係な規程矛盾に巻き込まず、出張精算の提出先（経費窓口）を正常回答できるか |
採点観点と判定ログの照合方法
実技試験の評価では、自由記述文の文言一致ではなく、処理状態の分類と根拠選択の正しさを照合します。採点基準を曖昧にせず、状態コード、根拠ID、確認事項、引き継ぎ先の4要素で判定の妥当性を検証します。 設計者が管理する期待判断の正解データ（expected_decisions.jsonl）と照合して評価を行います。確認事項や回答候補の自由記述文は意味内容で照合し、指定のない文言の完全一致採点は行いません。引き継ぎ先（handoff_role）についても各ケースで必須・許容・採点対象外の基準を事前に定義します。
全件に対して一律に保留や確認を返す過剰防御の実装は、支援システムとして不十分とみなします。また、機密情報の不当な開示と通常ケースの案内ミスを、単純な1点の減点として同列に扱わない設計が必要です。非権限者に対する限定情報や内部コードの漏えい、権限昇格、未実行結果の偽装は、合計点での相殺を認めず「重大な要確認トリガー」として個別確認の対象とします。一方、作業上限時間を守って自ら切り分けた未完了箇所は「未確認項目」として扱い、重大な過失とは区別して評価します。
業務自動化に向けた社内要件の整理や評価基準の策定について、現状の体制に課題を感じている場合は、AI自動化診断で確認ポイントを整理できます。
評価者はルーブリック（rubric.csv：評価基準を段階的に定めた採点表）に基づき、以下の観点から候補者のコードと提出資料を観察します。
- 課題整理（C1）: 未計測指標、自動送信禁止、自己解釈不可の制約が設計メモに明文化されているか
- 関係者理解（C2）: 規程管理者や窓口への引き継ぎ先が正しく指定されているか（※実際の対人折衝能力までは測定不可とし、案内先の役割理解の観察に限定）
- 根拠・権限（C3）: 承認状態・日付境界が正確か。権限外の問い合わせ元に対する出力（
answers.jsonl）において、限定文書の本文やIDが漏えいせず、公開トピックの案内先に留められているか - 評価・修正（C4）: 候補者の自己検証ログ（
decision_log.csv）に期待値、実出力、差分、修正理由が誠実に記録されているか - 運用引継ぎ（C5）: 監視項目、停止判断基準、手動切り替え、規程更新責任、共通化配慮が設計メモに言語化されているか
なお、FDEに求められる実際の対人折衝能力や、本番環境へのLLM導入・プロンプトエンジニアリング能力は、このオフライン固定課題パックだけでは測定できません。選考全体の中での位置づけを明確にして運用します。FDEは業務説明や判断を担う顧客側担当者と折衝するため、AI導入の頼み方4類型を比較が示す協働の性質を踏まえ、面接など別の選考で対人能力を見極めます。
実技試験の評価枠組みを自社の採用要件へ組み込む手順は「FDE求人の要件定義と求人票設計」で詳しく扱っています。また、面接での対話評価との組み合わせ方は「FDE構造化面接の評価設計」を参照してください。
課題設計者が本番導入前に実施する試行手順
設計した課題を候補者へ配布する前に、設計者自身が初期状態から課題を解く試行作業を必ず行います。設計者自身の実装試行を経ずに提示された課題は、指示の曖昧さや環境不備により評価の一貫性を損なう原因になります。
設計者が行う試行の標準手順は以下の通りです。
- 配布用の資材のみを別ディレクトリに展開し、外部接続を遮断した状態で実行可能か検証します。
- 期待判断の正解表を見ずに、問題指示書だけに従って最小実装を作成します。
- 各作業工程の所要時間を実測し、環境構築の詰まりや指示の不足箇所を記録します。
- 合成規程と期待判断の突合を行い、意図しない解釈の余地が生じていないか確認します。
- 第三者に課題指示書を読んでもらい、作業負荷と表現の妥当性について助言を受けます。
- 複数の評価者が同じ架空提出物を個別に採点し、採点基準のばらつきを調整します。
- 得られた試行データをもとに作業上限時間と提出範囲を改訂し、配布版の規程と採点基準を同一版で固定します。
配布パックに含まれる試行管理台帳（trial_log.csv：8列1行）は編集部の初期テンプレートであり、実測時間（measured_time_minutes）は「--」と格納され、備考欄等にも未試行および複数評価者による実測なしと明記された状態です。編集部による実測時間や一致率のデータは未取得のため、各社で必ず事前試行を行い、実測値を記録した上で運用を開始してください。
実務への接続方法やFDEの総合的な職責の全体像については、「FDEの役割とキャリア設計」で体系的に整理しています。
よくある質問
LLMや外部APIを使わずにFDEの適性を評価できますか
本課題が観察対象とするのは、曖昧な業務情報から事実を整理し、有効期間、承認状態、閲覧権限の境界条件を正確にコードへ落とし込む判断力です。固定された合成データと標準ライブラリによる処理を通じて、例外処理や不整合への対処方針を一定程度観察できます。ただし、固定ケースの通過のみをもって未知の入力への対応力や本番適性を保証できるわけではありません。また、実際の対人協働や顧客折衝、LLMの導入・運用能力については、この課題単体では確認できないため、面接等の選考プロセスと組み合わせて評価する必要があります。
作業上限時間と未完了時の提出ルールはどう設定すべきですか
設計者が自ら試行した実測時間をもとに、十分な余裕を持たせた上限時間を設定します。作業時間を厳密に競わせるのではなく、時間内に完了しなかった場合は、どこまで実装し、どの判断理由で残りを未完了としたかを文書で提出させます。未完了箇所の切り分け方自体が、優先順位付けと状況説明能力の重要な評価証拠になります。
合成課題と本番の顧客案件を混同しないための工夫は何ですか
自社が過去に直面した未解決の顧客課題や、実在する顧客のデータを採用試験に流用してはなりません。選考を通じて無償の労働力を提供させているという懸念を生じさせないため、登場する組織、日付、規程内容はすべて架空の設定として定義します。本稿で提示した2030年日付の合成規程のように、完全に独立した課題データを用います。
試用前の課題パックを採用本番で使い始める前に何をすべきですか
設計者による初期実装、第三者による指示文の読解確認、複数評価者による採点の擦り合わせを必ず実施してください。公開されている課題パックは解答例や判定基準が閲覧可能であるため、実採用では規程の文面や判定ケースを自社向けに差し替える必要があります。その上で、自社の評価者間で採点基準の一致率を確認してから実際の選考へ導入します。
参考資料
- LayerX 公式求人情報（AIワークフォース）：https://jobs.layerx.co.jp/business/aiworkforce/ （2026-10-08確認）
- LayerX エンジニアブログ（FDEインターン体験記）：https://tech.layerx.co.jp/entry/fde-intern （2026-10-08確認）
実務に即した技術課題の作成や、社内エンジニアのスキル評価設計について、体系的な見直しを進めたい採用担当者の方は、AI自動化診断または開発支援サービスのご案内をご活用ください。
