求人票から読むFDE ―― 肩書きが六つに割れた職種の見分け方
2026/9/25 01:00
「FDE」という一つのラベル、六つの実態
2026年のFDE求人を見渡して最も目立つのは、同じ役割が少なくとも六種類の異なる肩書きで募集されていることです。Forward Deployed Engineer、Forward Deployed Software Engineer、Solutions Engineer、Applied AI Engineer、Deployment Engineer——名前は違っても、仕事の中身は重なっています。
問題は逆も真であることです。同じ「FDE」というラベルを使っていても、実際に任される範囲は求人ごとに大きく異なります。肩書きだけで応募を決めると、入ってから「思っていた仕事と違う」となりかねません。
なぜ肩書きが割れたのか
FDEという名称を広めたのはPalantirですが、その後このモデルを採用した企業はそれぞれ異なる出自を持っていました。SaaS企業はソリューションエンジニアリングの系譜から、AIラボはリサーチ寄りの応用エンジニアリングから、コンサルは実装能力を持つコンサルタントから、それぞれこの役割に到達しています。
結果として、同じ仕事を指すのに各社の既存の語彙が使われ続けています。これは新しい職種が成立する過程ではよくある現象で、名前が収束するにはもう少し時間がかかります。
だからこそ、読むべきはタイトルではなくスコープの記述です。求人票の本文には、その会社がこの役割をどう捉えているかがかなり正直に現れます。
肩書きは会社の歴史を表しているだけで、あなたの仕事を表してはいない。
時間配分から見る実像
求人票の記述を集計すると、FDEの時間配分はおおむね顧客対応が60%、デプロイ固有のコードが30%、社内業務が10%という割合になるとされています。
この数字は重要です。実装が中心の職種だと思って入ると、実態は顧客と向き合う時間が過半を占めることになります。従来のソフトウェアエンジニアの座席というより、顧客の中に埋め込まれたプロダクト兵に近いと言えます。
逆に、この配分を好ましいと感じるなら適性は高いです。作ることと話すことのどちらも手放したくない人にとって、これほど適した職種は他にありません。
求人票のどこを読むべきか
第一に、顧客接点の深さです。「常駐」「オンサイト」「顧客のチームに埋め込む」といった表現があるか、それとも「顧客の声を参考に開発する」程度なのかで、仕事の性質は全く変わります。
第二に、コードの行き先です。書いたコードが顧客固有のものとして残るのか、本体プロダクトに還元されるのか。後者の仕組みがある企業は、FDEを使い捨ての実装要員とは見ていないサインです。
第三に、成果の定義です。納品で終わるのか、定着や継続利用までが評価対象なのか。ここが曖昧な求人は、入社後に評価基準でもめる可能性があります。
自分はどの系統に向いているか
実装力を武器にしたい人は、プロダクトへの還元があるタイプのFDEを選ぶと、自分の仕事が資産として積み上がります。
顧客の業務を読み解くことに手ごたえを感じる人は、顧客対応比率が高いタイプの方が伸びます。このタイプはFDEから事業開発や起業へ進むルートも見えやすくなります。
どちらにも強いレベルでなくても問題ありません。重要なのは、自分がどちら寄りかを自覚して、それに合うスコープの求人を選ぶことです。
タイトルではなく、任される範囲で選ぶ
FDE市場はまだ名称が固まっていないだけで、求められていること自体ははっきりしています。顧客の現場で課題を定義し、動くものを作り、使われる状態まで持っていくことです。
求人票を読むときは、肩書きと年収レンジだけでなく、任される範囲と成果の定義まで見る。それだけで、入ってからのすれ違いは大きく減らせます。
OTHER
その他記事一覧
求人票から読むFDE ―― 肩書きが六つに割れた職種の見分け方
2026年のFDE求人で最も目立つのは肩書きの分裂です。1つの役割が少なくとも六種類のタイトルで募集され、同じ「FDE」でも任される範囲は大きく異なります。求人票を集計すると顧客対応60%・デプロイ固有のコード30%・社内業務10%という配分が見えてきます。タイトルではなくスコープで見極めるための実務的な読み方を解説します。
【2026年版】FDE市場の現在地 ―― 巨大テックが「職種」に数千億円を投じ始めた
FDE（Forward Deployed Engineer）は2026年、話題の職種から巨額投資の対象へと段階を変えました。AWSは6月にFDE専門組織に10億ドル、Microsoftは7月に約6,000人を顧客に常駐させる25億ドル規模の新事業を発表。求人数は前年比四桁の伸びを示し、日本でも市場が立ち上がり始めています。数字で追うFDE市場の現在地と、小さな事業者にとっての意味を整理します。
FDEを入れたのにスケールしない ―― 4つの失敗パターンと段階設計
FDE型の体制を導入したのに、最初の1件から2件目・3件目へ広がらない。この問題の原因は担当者の能力ではなく、ほぼ例外なく仕組み側にあります。属人化、負荷集中による疲弊、知見の非還元、内製と外部委託の判断ミス——実務で頻出する4つの失敗パターンと、6〜12か月の段階設計の組み方を整理します。
中小企業は「社内FDE」を育てるほうが早い ―― 採用競争に参加しないという選択
日本のFDE求人は2026年春時点で約35件、提示年収は900万〜2,500万円超が中心レンジ。中小・非IT企業がこの争奪戦に参加して勝つのは現実的ではありません。自社の業務を知っている人にAIで自動化を作れる力を持たせる——「社内FDE」という選択肢と、その育成の段階設計を解説します。
AI導入の95%が成果を出せない ―― FDEが埋めているのはどのギャップか
MITのNANDAイニシアチブは2025年のレポートで、企業の生成AIパイロットの95%が測定可能なビジネスインパクトを生んでいないと報告しました。しかし失敗しているのはAIそのものではなく、AIと業務の間にある層です。FDEが埋めている4つのギャップと、小さな組織でも同じ構造が使える理由を解説します。
なぜ今FDEが注目されるのか ── AI時代の需要構造を読み解く
2024〜2026年にかけて、OpenAI・Anthropic・SalesforceなどがFDE（Forward Deployed Engineer）の大量採用に動き、日本でも求人が急増しています。背景にあるのは生成AIの「汎用性と現場適合の非対称性」です。FDEブームの需要構造を解説します。
非エンジニアからFDEになれるか ── 越境キャリアの入口設計
FDE（Forward Deployed Engineer）は実装力が土台の職種ですが、ITコンサル・PM・業務部門出身者にも現実的な参入ルートがあります。非エンジニア・越境層がFDEを目指す際の強み・弱みと、AI時代ならではのキャッチアップ戦略を解説します。
FDEのプロジェクトはこう進む ── 課題発見から定着までの実務フロー
FDE（Forward Deployed Engineer）のプロジェクトは、ヒアリング→課題定義→高速プロトタイピング→本番展開→定着・改善という流れで進みます。従来のウォーターフォール型開発とは別物の、現場密着型の実務フローをフェーズごとに解説します。
Webサイト改修提案を「論証可能」にする6つの分析レンズ
Webサイトの改修提案をしても、「なぜその改修が必要なのか」をクライアントに説明できないと採用されません。デザイン評価だけ、データだけ、主観コメントだけ、という一点集中の提案では説得力が出ません。DesiaがWebサイト提案を作る際にチェックしている「6つの分析レンズ」を公開します。
Robloxゲーム開発の落とし穴 ── 「板1枚問題」と「目的不明瞭問題」を事前に防ぐ設計原則
Robloxゲーム開発を始めた多くのクリエイターが「セッション時間が伸びない」「リテンションしない」という課題に直面します。この裏にある「板1枚問題」と「目的不明瞭問題」という2つの設計ミスと、それらを防ぐためのアセットドライブンデザイン思想を公開します。
AIで作るアプリUI動画素材の使い分け ── Lottie / Three.js / Renoise
WebサービスやアプリのUIを動んず「静止だと伝わらない」というケースで、動画・アニメーション素材の制作ニーズが高まっています。Lottie、Three.js、Renoiseの3つのツールはそれぞれ得意領域が違うため、実際に何を作るかによって選択が変わります。Desiaの実例をもとに使い分けを解説します。
Claudeスキル設計の500行制限 ── スキルが肥大化したら必ず分割するべき理由
Claudeのスキル機能([SKILL.md](http://SKILL.md))を使い始めた多くのユーザーが陥るのが、「スキルファイルが肥大化していく」問題です。最初は100行だったスキルが、機能追加・例外処理の追加で500行・1000行と膨らみ、ある日「スキルが動かなくなる」「Claudeが指示を読まない」という事態が起きます。Desiaが実務で確立した「500行制限」の原則と、3つの分割パターンを公開します。
デザイン品質を保つAI3スキル分業設計 ── アートディレクター・デザイナー・QAをスキルで分ける
AIによるUIデザイン生成は、プロンプト1本で完結しません。「アートディレクション」「デザイン生成」「品質QA」という3つの役割を1人のAIで兼ねさせると必ずどこかで品質が破綻します。Desiaが実務で確立したdesign-art-director/ai-ui-prompt-gen/design-qa-reviewerの3スキル分業設計と、それを統合するオーケストレーターのノウハウを公開します。
地方企業が東京の競合に勝つためのローカルSEO・AEO戦略
「東京の競合と比べてSEOで不利だ」という相談を、地方企業からよく受けます。確かに被リンク数も発信ボリュームも東京企業に分があります。しかしローカルSEO・AEO・Google Business Profileを組み合わせれば、地方企業のほうが圧倒的に有利な領域があります。Desiaが秋田から実証してきた地方企業の差別化戦略を公開します。
GA4とSearch Consoleの「見られないレポート問題」を解決する標準フロー ── 月次から年次までの4段階ステップアップ
Web制作案件を納品して終わりではなく、その後の運用フェーズで「結局GA4もSearch Consoleも見てもらえていない」という事態が頻発します。Desiaが標準フロー化したGA4・Search Consoleレポートのハンドオーバー手順を公開します。月次の3指標ダッシュボードから年次戦略提案まで、4段階のステップアップで運用に乗せるノウハウです。
業務AIセキュリティの基本 ── プロンプトインジェクションから機密情報を守る3レイヤー対策
ChatGPTやClaudeを業務で使い始めると、必ず話題になるのが「セキュリティ大丈夫?」という懸念です。特に最近は「プロンプトインジェクション」という攻撃手法が知られるようになり、AIに業務データを渡すリスクが論点になっています。Desiaが実務で運用している、業務AIセキュリティの基本(信頼境界・機密情報の取り扱い・検出と対応)の3レイヤー対策を公開します。
プロンプト過剰最適化問題 ── AIツールごとの適切な詳しさとは
Claudeやv0、Figma Makeを使い始めた点、「プロンプトを詳しく書けば書くほど良い出力が出る」と考えてしまうわなけではありません。しかし詳しすぎるプロンプトはむしろ出力品質を下げることがあります。Desiaが7つのAIツールごとにチューニングした「適切な詳しさ」のガイドを実例とあわせて公開します。
Claudeで「ナレッジが流れない組織」を作る5つのレイヤー設計
ChatGPTやClaudeを業務で使い始めた企業の多くが、「便利なやり取りが個人の中に閉じてしまい、組織のナレッジにならない」という壁に当たります。Desiaが自社運用とクライアント支援で確立した、Claudeを「組織の知的資本」に変えるための5レイヤー設計を解説します。
Notionで「公開と非公開」を両立させる構造設計 ── ストックDBと公開DBの分離戦略
Notionをコンテンツ管理ツールとして使っている企業で必ず突き当たるのが、「Notion Sites公開時に閲覧者がフィルターを変更できてしまう」問題です。Desiaがクライアント案件で確立した「ストックDBと公開DBの分離戦略」と、運用負荷を最小化する設計のコツを共有します。
Figmaプロトタイプの「擬似インタラクション」設計術 ── 入力フォーム・条件分岐ボタンを作る
Figmaのプロトタイプには「テキスト入力」も「条件分岐（if文）」もありません。それでも実案件では、入力可能なフォームや「全項目入力後にボタンが活性化する」演出が求められます。Desiaが現場で確立した擬似インタラクション設計の3つのテクニックを公開します。
Webコンサル提案書を作る前に知っておきたい「無料で使える分析ツール」の組み合わせ
Webサイトのコンサル提案書を作る際、有料分析ツール（Similarweb、Ahrefs有料版等）に頼り切ると、案件単価次第ではコストが合いません。Desiaが実運用している「無料・低コストツールの組み合わせ」だけで、競合分析からSEO/AEO戦略、Gamma連携の提案書生成までを完結させる方法を共有します。
業種別BIダッシュボードのKPI設計テンプレート ── Looker Studioで失敗しないための設計原則
Looker Studioでダッシュボードを作ろうとして「何を載せればいいか分からない」と止まる経験はないでしょうか。Desiaが10業種超の案件で蓄積したKPI設計テンプレートと、絶対に外せない設計原則を整理しました。クライアント提出物として通用するダッシュボードを作るための実践ガイドです。
コードからFigmaへ、戻す側のベストプラクティス ── Manus / Claude Code / v0 出力をデザインデータ化する
ManusやClaude Code、v0で生成したサイトコードをFigmaに「編集可能なデザインデータ」として戻したい、というニーズが急増しています。Desiaが多くの試行錯誤を経て確立した、安全に運用できる「コード→Figma反映ワークフロー」を、5つの原則と8フェーズのプロセスに整理しました。
高齢者向けアプリUI設計のリアル ── 80代でも迷わず使える設計原則とは
医療・福祉領域のアプリ案件で必ず直面するのが「高齢者向けUI」の難しさです。Desiaでは在宅酸素療法を利用する80代以上の患者向けLINEミニアプリを設計する中で、一般的なアクセシビリティガイドラインだけでは足りない、実装現場ならではの設計原則を確立してきました。本稿では、その核となる8つの原則を共有します。
広告レポートを毎朝Slackで自動配信する仕組み ── GAS × Claude API × Slack の作り方
「広告レポートの作成に毎週半日取られている」「分析コメントを書くのが地味に大変」というご相談をよく頂きます。Desiaでは、Google Apps Script（GAS）とClaude API、Slack Incoming Webhookを組み合わせ、広告KPIのレポートを毎朝自動でSlackに配信する仕組みを実運用しています。月額わずか100〜150円で構築できる、その実装の核心を公開します。
AI UIツール7種を使い分ける実務者向けガイド ── Relume / Stitch / Figma Make / v0 / Bolt / Lovable / Manus
「結局、どのAI UIツールを使えばいいですか？」というご質問を本当によく頂きます。Desiaでは複数のクライアント案件で全主要ツールを使い込んだ結果、それぞれが得意とする領域が明確に分かれていることが分かりました。本稿では、目的別の使い分けと、実務でハマりやすい落とし穴を整理します。
AI時代のWebサイト立ち上げで失敗しないための「上流設計」3ステップ
「とりあえずAIツールでサイトを作ってみよう」と着手して、後から構成のやり直しに陥るケースをよく見ます。AIによるサイト生成が当たり前になった今だからこそ、実はサイトマップ・情報設計・コンテンツ設計という「上流工程」の質が成果物の出来を決めます。本稿では、Desiaが実際の制作現場で固めてきた、AI時代に通用する上流設計の3ステップを公開します。
View more →