FDEは、製品を提供する企業から顧客企業の現場に入り、顧客と共同でシステムや業務の課題を解決するエンジニアである。

　一般的な製品導入支援が、初期設定や操作説明、標準機能の展開を中心とするのに対し、FDEは顧客のコードやシステム、業務プロセスに踏み込む。顧客企業の担当者とともに設計や開発を進め、製品を実際の業務へ組み込む。

　CursorのFDEチームは、同社のAIコーディング製品を使い、長時間動作するAIエージェントや業務自動化の仕組み、SDKを利用したアプリケーションなどを顧客と共同開発している。

　FDEの仕事は、システムを作って終わりではない。導入した仕組みが現場で使われ、顧客企業が自ら運用、改善できる状態まで支援する。顧客の現場で見つけた課題や要望を自社の製品部門へ戻し、製品改善につなげる役割もある。

FDEとコンサルタント、SIer、常駐SEは何が違うのか

　FDEの役割は、ITコンサルタントやSIer、常駐SEと重なる部分がある。名称だけで明確に区別できるわけではないが、主な目的には違いがある。

　ITコンサルタントは、経営や業務上の課題を整理し、戦略や導入計画を立てる役割を担う。SIerは、定められた要件を基にシステムを設計、開発、導入する。常駐SEや準委任契約の技術者は、顧客が指定した開発や運用の作業を支援することが多い。

　一方、FDEは自社製品の技術的な知識を持ち、顧客と共同でユースケースを設計し、実装する。顧客ごとの課題を解決すると同時に、現場で得た知見を自社製品の機能やロードマップへ還元する点が特徴だ。

　ただし、FDEという名称であっても、実態が製品説明や要員補充にとどまる場合がある。情シスは肩書だけでなく、誰が課題を定義し、誰が開発し、契約終了後に何が自社へ残るのかを確認する必要がある。

FDEを依頼する価値がある案件とは

　Brunet氏は、FDEを配置すべきかどうかを判断する際、顧客のデジタル成熟度と製品のカスタマイズ性を確認すべきだと説明する。

　顧客企業に十分な技術者がいて、製品も標準設定のまま利用できるなら、詳しいドキュメントやセルフサービス型の導入環境があればよい。高度なFDEを投入しても、大きな効果は得にくい。

　顧客の技術力が十分でなくても、アカウント発行や定型的な設定だけで利用できる製品なら、一般的なSaaS導入支援で対応できる。操作研修や製品説明会をFDEに任せるのも、高度な人材の使い方としては適切ではない。

　FDEが価値を発揮するのは、標準機能を提供するだけでは解決できない案件だ。例えば、次のような場合が該当する。

　既存システムや社内データとの複雑な連携が必要な場合、AIエージェントを業務プロセス全体に組み込む場合、前例が少なく実装しながら要件を詰める必要がある場合である。短期間で試作と検証を繰り返し、効果を確認しながら仕組みを改善したい案件にも向いている。

　一方、単純にエンジニアが不足している、定型的な保守運用を外部に任せたい、解決したい課題が決まっていないといった案件は、FDEに適していない。

「人が足りないから代わりに作って」は危険信号

　FDEの利用を検討する情シスが注意すべきなのは、FDEを開発要員の補充として扱わないことだ。

　Brunet氏は、顧客から「自社のエンジニアが不足しているので代わりに開発してほしい」と言われた場合、FDEに適した案件かどうかを慎重に判断するという。

　FDEは実際に顧客のコードベースへアクセスし、設計や開発、設定を担当する。しかし、顧客から切り離された状態で作業を請け負うわけではない。

　顧客側の担当者が参加せず、FDEだけがシステムを構築すれば、設計思想や運用方法が社内に残らない。契約終了後に修正できず、導入した仕組みが停止する恐れもある。外部依存を減らすための取り組みが、新たなベンダーロックインを生むことになりかねない。

　Cursorでは、案件を始める前に、顧客企業から誰が実務チームに参加するのかを確認する。顧客側にも開発や検証を担う担当者を置き、FDEと共同で作業を進めることを重視している。

情シスはプロジェクトにどう関わるべきか

　FDEを利用しても、情シスの負担がなくなるわけではない。むしろ、FDEが短期間で成果を出すには、情シスが社内の情報や関係者をつなぐ必要がある。

　情シスは、現在のシステム構成やデータの所在、既存の連携関係をFDEへ説明する。必要なアクセス権限を調整し、セキュリティやデータガバナンスの要件も提示しなければならない。

　AIを業務へ組み込む場合、技術部門だけで課題を定義するのは難しい。実際の業務を担当する部門を巻き込み、現在の処理手順や例外対応、判断基準を明らかにする必要がある。

　新しい仕組みを導入すれば、従業員の業務や役割も変わる。Brunet氏は、最新技術を導入するだけで利用者への支援をしなければ、誰も使わなくなると指摘する。

　情シスには、FDEと業務部門、経営層の間に立ち、技術導入と業務変革を同時に進める役割が求められる。

経営層の支援がない案件は進まない

　FDEが顧客のシステムに入り、業務プロセスを変更するには、複数部門の協力が必要になる。データやシステムへのアクセス権限を取得するだけでも、社内調整に時間がかかる場合がある。

　CursorのFDEチームは、案件を選ぶ際、予算を決定する責任者や、社内で影響力を持つ推進者と連携する。会社の戦略目標に関係し、明確な投資対効果を期待できる案件に絞るためだ。

　現場の一担当者だけが推進する案件では、業務部門が協力せず、必要なデータを得られないまま止まる恐れがある。FDEを導入する際は、経営層が目的を理解し、必要な人員と権限を用意することが欠かせない。

契約前に確認したい5つの質問

　情シスは、FDEとの契約を決める前に、少なくとも次の5点を確認したい。

　1つ目は、解決すべき業務課題が具体的かどうかだ。「生成AIを活用したい」といった抽象的な目標では、開発するものや優先順位を決められない。どの業務にどれだけ時間がかかっているのか、何を改善したいのかを明らかにする必要がある。

　2つ目は、顧客側の担当者を誰にするかだ。情シスだけでなく、業務部門の責任者や現場担当者も参加できる体制が望ましい。

　3つ目は、成功をどの数値で測るかだ。処理時間や問い合わせ件数、作業人数、エラー件数など、導入前の状態を測定し、目標値を決める。

　4つ目は、コードや設計書、運用手順などの成果物が誰に帰属し、どのような形で引き渡されるかである。FDEが離れた後に、自社で保守や修正ができる状態を契約に含める必要がある。

　5つ目は、契約終了後に誰が運用と改善を担うかだ。担当者や運用体制を決めないまま導入すれば、せっかく構築した仕組みが使われなくなる可能性がある。

「FDEを2人、6カ月」の契約では成果が曖昧になる

　Brunet氏は、「FDEを2人、6カ月間提供し、自由に使ってもらう」といった人月中心の契約は失敗しやすいと説明する。

　投入する人数や期間だけを決めると、顧客はFDEを自由に依頼できる開発要員と捉えやすい。細かな改修や個別対応が積み重なり、本来解決すべき課題を見失う恐れがある。

　必要なのは、何を解決するためのプロジェクトなのかを定めることだ。例えば、問い合わせ対応の工程をAIエージェントで自動化し、平均解決時間を短縮するといった目的を設定する。

　一方で、開始前に作業内容を細かく固定し過ぎるのも適切ではない。FDEは、顧客のデータや業務プロセスを確認しながら設計を進めるため、途中で新たな問題や改善案が見つかることがある。

　解決する課題と成果指標は明確にしつつ、具体的な実装方法や作業範囲には一定の柔軟性を残す必要がある。

導入効果を「AIの利用料」だけで判断しない

　FDEが構築したAIエージェントや自動化システムは、利用料や計算資源のコストが高く見える場合がある。

　Brunet氏は、1日2000ドルの費用がかかるAIエージェントについて相談された例を紹介した。そのAIエージェントは、故障した設備へ適切な担当者を派遣するために使われていた。

　AIエージェント単体の費用だけを見れば高額に感じる。しかし、適切な技術者を最初から派遣できれば、設備の停止時間や再訪問、出張費、人件費を削減できる。総額で見れば投資に見合う可能性がある。

　Brunet氏は、FDE案件が生み出す価値を「売り上げの増加」「コストの削減」「リスクの軽減」の3つに整理する。

　情シスも、AIのライセンス費用やAPI利用料だけでなく、従来業務にかかっていた人件費、機会損失、障害や誤判断のリスクを含めて評価する必要がある。

FDE側が「できない」と言えるかも確認する

　優れたFDEは、顧客から依頼された案件を全て引き受けるわけではない。

　Brunet氏は、Cursorが適切な製品ではないと判断した場合、顧客に率直に伝えるという。製品に合わないユースケースを無理に実装しても、十分な成果を出せず、最終的には信頼を損なうためだ。

　反対に、製品が適する領域と適さない領域を明確に説明できれば、専門家としての信頼を得られる。情シスはFDEを選ぶ際、どのような案件を断るのか、適用範囲をどこまで明確にしているかも確認したい。

　製品研修や全社展開、一般的なチェンジマネジメント、定型的なシステム構築は、SIerやコンサルティング会社と分担できる。FDEが全てを担うのではなく、各社の得意分野を組み合わせることが重要だ。

FDEを使っても自走できない企業の共通点

　FDEを利用しても、顧客企業の体制が整っていなければ成果は残らない。

　経営層の支援がない、業務部門が参加しない、情シスに全てを押し付ける、成功指標を決めないといった案件は失敗しやすい。

　外部技術者の人数だけで契約し、設計書や運用手順の作成を後回しにする場合も注意が必要だ。FDEが離れた後に、導入した仕組みを理解する人がいなくなる。

　Brunet氏は、案件の設計、実装、検証、効果測定の全てに顧客を参加させるべきだと説明する。FDEは顧客を支援する存在であり、顧客に代わって全てを行う存在ではない。

FDEの目的は外部依存ではなく自走

　FDEの価値は、優秀なエンジニアを一定期間借りることではない。自社だけでは実装が難しい初期段階を共同で乗り越え、情シスや業務部門がその後の運用と改善を担える状態をつくることにある。

　FDEを単なる開発要員として扱えば、社内に知識が残らず、契約終了後にシステムを維持できなくなる。外部依存を解消するはずのプロジェクトが、別の外部依存を生むことにもなりかねない。

　情シスは、FDEへ何を任せるかだけでなく、自社が何を担うかを明確にする必要がある。課題を定め、人員を配置し、成果を測定し、運用を引き継ぐところまで設計して初めて、FDEを利用する意味が生まれる。

本稿は、AI Engineerが2026年7月15日に公開した動画「Forward Deployed Engineering at Cursor－Pauline Brunet」を基に作成しました。