1. FDEは、顧客と一緒に実装を進める役割
Palantirは、2019年の公式記事で、製品の共通機能を開発する役割と、顧客に製品を導入・カスタマイズするForward Deployed Software Engineer（FDSE）の役割を分けて説明しています。後者は、顧客の目標に対して技術をどう使うかを考える立場です。
2026年10月29日に確認した同社の採用ページでも、顧客と直接協働し、個別のアプリを開発し、構想から導入まで担う仕事が挙げられています。FDEはこのような役割を指す呼び方ですが、ここで確認したのはPalantirの説明であり、すべての会社の職務範囲が同じとは限りません。
中小企業の依頼に置き換えるなら、「日報をまとめる画面を作ってほしい」という注文の前に、現場で何を記録し、誰がどう直し、何の判断に使っているかを実装担当と確かめる進め方です。現場に入ることは、承認なしに本番の設定やデータを変えることではありません。業務を知ることと、操作の権限を持つことは分けて決めます。
2. 顧問・受託開発との違いは、名前より担当範囲で比べる
顧問でも実装まで担う契約があり、受託開発でも業務の聞き取りや導入後の改善を行う会社があります。「顧問は話すだけ」「受託は仕様書どおりに作るだけ」と一律には分けられません。
次の表は業界全体の分類ではなく、依頼先との打ち合わせで使う比較の観点です。
| 依頼の形 | 確かめたいこと | 見積り・依頼書に残すこと |
|---|---|---|
| 相談・助言を中心に頼む | 課題整理の後、設定や開発は誰が行うか | 提案の成果物、実装担当への引き継ぎ、対象外の作業 |
| 作るものを決めて開発を頼む | 現場確認や仕様変更をどこまで含めるか | 作る範囲、受け入れ条件、追加変更の費用・決め方 |
| 現場での確認と実装を続けて頼む | 誰と業務を確認し、どの段階で範囲を決め直すか | 確認の機会、変更の承認者、成果物と保守の担当 |
何を作るかが明確なら、範囲を決めた開発が候補になります。反対に、部署ごとに手順が違い、仕様を決めるために実際の仕事を見る必要があるなら、業務確認と試作を同じ担当に頼む方法を検討できます。まだ改善する業務自体が決まらない場合は、まず相談や棚卸しに区切る選択もあります。
社内で作るか外へ頼むかは内製・外注の判断基準、公的窓口との分担は伴走支援と実装支援の使い分けで扱っています。
3. 中小企業が現場での実装を依頼する手順
最初の業務と、使える状態の条件を決める
「全社のAI化」では広すぎます。「日報の転記から週報を作る工程」など、入力から確認まで追える業務に絞ります。今の資料、困る場面、例外、結果を見る人を実装担当と確認します。
完成の条件も、画面の有無ではなく仕事の流れで書きます。たとえば「元の日報を開ける」「訂正前後が区別できる」「未確認の行を週報へ入れない」「担当者が承認してから使う」といった条件です。既存ソフトの機能で足りると分かれば、独自開発をせず設定や手順の変更へ切り替えることもできます。
任せる操作と、社内に残す判断を分ける
| 工程 | 実装担当へ依頼する作業の例 | 社内で決めること |
|---|---|---|
| 業務の確認 | 入力元・転記先・例外を整理する | どの手順を正とするか、どの資料を共有できるか |
| 試作 | 個人情報や機密情報を含まない例で画面や連携を作る | 想定する例外が含まれるか、作る範囲を変えるか |
| 利用準備 | 権限、履歴、重複処理、停止時の戻し方を整える | 本番操作の許可、利用開始の可否、確認担当 |
| 利用開始後 | 不具合の修正、手順や設定の更新 | 変更の優先順位、追加費用、保守を続ける範囲 |
資料の共有を認めたことを、その資料を外部のAIへ入力する許可と一緒にしません。使うサービスと情報の範囲は顧客情報を生成AIへ入力するときの確認手順も参考に、別に合意します。ログイン情報を依頼書へ書かず、作業に必要な権限と、終了時に解除する担当を決めてください。
小さく使い、変更と引き継ぎを記録する
試作を現場担当者に見てもらい、通常の仕事で使えるかを確かめます。例外が見つかったら、今回直すものと保留するものを分けます。AIの下書きを採用するか、登録や送信を認めるかは、社内の担当者が判断します。
契約の終わりには、ソースや設定の保管先、管理者、手順、残った不具合、保守窓口を引き継ぎます。「作った人しか動かせない」状態を避けるため、変更を頼む方法と、手作業へ戻す方法も確認します。具体的な保守項目はAIで作った業務ツールを使い続けるための確認点にまとめています。
4. 想定シナリオ：部署ごとに違う日報を週報へまとめる
以下は架空の会社の、未実施の活用例です。
総務担当者が各部署の日報を集め、週報へ転記しているとします。実装担当が作業を確認すると、同じ「完了」でも部署によって意味が違い、提出後の訂正も別メールで届いていました。
この場合、最初から集計画面だけを作ると、意味の違う件数や古い内容をまとめるおそれがあります。先に部署の責任者と、完了の定義、訂正を受け付ける場所、どの版を週報へ使うかを決めます。
試作する画面は「日報の番号・部署・対象日・版・元の記録・確認状況」を並べ、未確認と訂正中を分ける一覧を想定します。決まった項目の集計には通常の自動化を使い、自由記述の要約が必要ならAIの下書きを別欄に置きます。画面の例は次のようになります。
| 日報 | 元の記録の状態 | 一覧での扱い | 人が行うこと |
|---|---|---|---|
| 営業部・当日分 | 初版に対する訂正が届いた | 訂正中として集計を保留 | 元の版と訂正内容を確かめ、採用する版を決める |
| 製造部・当日分 | 完了の意味が未合意 | 定義の確認待ち | 部署責任者が集計に含める条件を決める |
| 総務部・当日分 | 担当者が内容を確認済み | 確認済みの版を集計対象にする | 週報へ反映する前に承認する |
実装担当は、画面を作るだけでなく、訂正が来たときに古い版をどう外すか、同じ日報を再処理しても重複しないかを確認する仕組みを整えます。現場担当者は、元の日報と週報を見比べ、集計条件と要約を確認します。自動で取引先へ送る工程は、この依頼には含めません。
聞き取りから作業を整理する参考として、公開済みの業務ヒアリングとマニュアル作成の事例があります。日報連携を実装した事例としてではなく、業務の確認方法を見るために参照してください。集計の方法を選ぶ際は表計算の集計を自動化する方法も参考になります。
5. 費用と期間は、現場確認・実装・保守に分けて聞く
FDEという名称だけから、費用や完成日数は決められません。見積りでは、業務の確認、試作、既存ソフトへの接続、権限の設定、利用者の確認、保守を分け、どこまで料金に含むかを聞きます。訪問の回数、オンラインで対応する範囲、ソフト利用料、社内の確認時間も比較に入れます。
日報の例なら、集計表の設定で足りる場合と、訂正履歴を持つ一覧や複数システムとの連携を作る場合では作業が変わります。最初の業務確認を終えた時点で、実装する範囲と次の費用を判断する区切りを設けると、調査の途中で依頼が際限なく広がるのを防ぎやすくなります。
日程は「資料・権限の準備→試作→現場での確認→修正→利用開始」の工程ごとに、担当者と確認日を合意します。社内の定義が未確定なら、画面の完成だけを約束せず、先に決める事項とその担当を残します。金額の比較はAI導入の費用の記事へ、全体の始め方はAI業務改善ガイドへ進んでください。
hirostaでは、業務の整理から試作、仕組みづくり、定着、保守までをプランに応じて支援しています。掲載中のサービスでは、構築・保守はスタンダード・プロが対象で、スターターは試作と相談・見直しまでです。プロの定期訪問は広島県内を対象とし、回数は契約で決めます。最新の範囲はサービス・料金、開発や連携の対象はシステム開発で確認でき、業務が決まっていなくても相談窓口へお話しいただけます。
6. FDEへの関心と、実際の求人・導入実績は分けて読む
レバテックが実施し、レバレジーズが2026年6月30日に公表した調査では、FDEに興味があるという回答は68.3％、今後の需要が増えると思うという回答は72.0％でした。調査は2026年5月26〜28日のインターネット調査で、対象は20〜59歳のITエンジニア、有効回答は243名です。
これは回答者の関心と将来予測です。国内の求人数の実測、中小企業の導入率、費用対効果を示す数字ではありません。Palantirの職務説明も、日本の中小企業が同じ条件で採用・契約できることを示すものではありません。
依頼先を選ぶときは、肩書きの流行より、自社の業務を理解する時間があるか、実装する担当が決まるか、利用開始後の修正と引き継ぎまで合意できるかを確かめましょう。