こんにちは。fjm2uです。昨年の11月からAi Workforce事業部のFDE（Forward Deployed Engineer）チームでインターンさせていただいております。
この記事では、Ai Workforce事業部のFDEチームへの応募を検討している方向けに、FDEという仕事の特徴と、インターンとして実際に経験した「現場での課題解決がプロダクト改善につながる」流れを紹介します。
FDEの業務
FDEの詳細は以下の記事でも紹介されていますので、そちらをご参照ください。
note.com blog.allstarsaas.com note.layerx.co.jp
私が理解しているFDEとは、お客様の業務を理解しながら、プロダクトをテコとして短期間で顧客課題の根本解決を行い、その経験で得た知見をプロダクトの改善に繋げる職種です。 そして、そのプロダクト改善がはずみ車となり、次回はもっと早く・深く顧客課題を解決することが可能となります。
FDEに主に求められているのは、
- 知らないドメインへの業務理解の質（広さ、深さ、スピード）
- 業務の課題を根本的に解決するための提案力
- 提案を具体的な実装に落とし込む開発力
- チーム内・お客様とのコミュニケーション能力
です。求められる幅が広い職種ですが、だからこそインターンでも日々成長を実感できる環境です。
Ai WorkforceのFDEチームの実態
現在は、FDEチームの中でも開発中心の方・顧客案件中心の方で分かれている印象です。
開発中心の方は、プロダクトでFDEが利用する部分を中心とした開発を担当されています。開発の難易度が高く、実装のボリュームも大きいです。
顧客案件中心の方は、プロダクトを利用してお客様の課題解決を行い、DS（Deployment Strategist：顧客の業務設計や導入支援を担う職種）と一緒にお客様との商談に参加します。この過程でお客様の現場に出向くこともあります。
情報管理は徹底されており、チーム内でもアサインされていない案件のデータなどは見えません。ただ、チーム内の定期ミーティングではプロダクトのTipsや改善の知見が常に共有され、常にフィードバックループが回っています。
Ai Workforce FDEチームで働く魅力
- 情報の質と透明性が高い
- 若手でも、意見を出しやすい雰囲気がある
- 先端技術の動向を踏まえた流動的な事業環境がある
- 相談しやすい人が多く、OJTで力をつけられる
実際、どんなことをしたのか
ここからは、私が参加したトライアル案件を例に、FDEの仕事が実際にどう進むのかを紹介します。
FDEとDSの先輩方と、トライアル案件に参加しました。トライアル案件は、お客様が本番導入の可否を判断するために、プロダクトを実務に近い形で試す取り組みです。
やったことの概要
大量の資料から必要な情報を正確に抽出・分類し、特定形式のレポートとしてまとめるという業務でした。1件あたり数十ページに及ぶ資料もあり、業界の専門知識がないとそもそも着手すら難しい内容です。人手でやると膨大な時間がかかるうえに、分類や判定の判断には業務ドメインへの深い理解が求められるタスクでした。
やったことの詳細
以前に別のFDEの方が作った成果物をベースに、FDEとDSの先輩方と基本3人チームで案件に取り組みました。案件の中心は、精度向上のサイクル（プロンプトを調整し、その結果を評価し、また調整する）の繰り返しでした。
1. 正解データの作成
精度評価の基盤として、受領サンプル全件の正解データを手作業で作成しました。元資料から値を一つ一つ確認し、正解データ自体の不整合も発見・報告し、お客様と認識をすり合わせました。地道な作業ですが、この作業がなければ精度を測ることすらできず、案件の土台として重要でした。
2. プロンプト調整
別のFDEの方が作成したプロンプトを改善しました。資料には専門用語や独特のフォーマットが多く、文脈によって分類結果が変わりうる項目も少なくありません。同じプロンプトでも資料が変わると誤分類が発生しました。不正解パターンを一つずつ分析し、Few-shot例の追加や分類ルールの構造化を繰り返すことで、幅広い資料に対応できるよう調整していきました。
最初の時点で8割以上は正しく処理できている状態から、残りの不正解パターンを一つずつ潰して精度を引き上げていく作業です。最後の数%が最も手強く、この数%とずっと戦っていました。
3. ワークフローの修正・構築
ワークフローとは、Ai Workforce上で構築する処理パイプラインのことです。ノードと呼ばれる処理単位を組み合わせて定義し、LLMによる情報抽出・分類、Pythonによる計算処理などノードにはいくつかの種類があります。プロンプトもノードの中に組み込まれています。
情報抽出ロジックの修正、エラーハンドリング、出力項目名の統一など、案件に合わせたワークフローの修正を行いました。要件に合わせた新しいワークフローも作成しました。
4. 精度評価と自動化の試み
プロンプト調整以上に時間がかかったのが精度評価でした。正解データとの照合・集計をすべて手作業で行っていたため、「調整→評価」の1サイクルに大きなコストがかかっていました。案件の途中で自動評価スクリプトの開発に着手しましたが、時間的制約もあり、案件中に使えるレベルには達しませんでした。
この課題感はプロダクトへのフィードバックとしてチーム内に共有しました。そして案件を終えた今、自動で精度評価するための仕組みを作っています。まさにFDEモデルの「現場→プロダクト改善」のループを経験しています。
5. 商談への同席
先輩方と一緒にお客様との定例会に参加しました。
案件を通じての学び
「正しい出力」から「正しい問い」へ
案件参加前の私は、ワークフローの改善は「正しい出力を出すこと」とぼんやり考えていました。しかし正解データを作成する過程で、正解の定義が一意に定まらないケースがありました。そこで「そもそも正解とは何か」をお客様とすり合わせなければ、いくら精度を追っても意味がないことに気づきました。技術だけでなく、ドメイン知識の深さがソリューションの品質を左右することを実感しました。
評価駆動という方法論
案件中の最大の反省は、精度評価の仕組みを後回しにしたことでした。手動で評価していたため、「プロンプトを修正したら再評価」というサイクルのたびに大きな時間を取られ、調整のスピードが上がりませんでした。もし最初に自動評価の仕組みを整えていれば、同じ期間でもっと多くの調整サイクルを回せたはずです。
この経験から、まず評価の仕組みを整えてから開発に入るという方法論を自分の中に持つことができました。ソフトウェア開発におけるTDD（テスト駆動開発）の考え方に近いですが、LLMを使った案件では特に重要だと感じています。通常のソフトウェアは同じ入力に対して同じ出力を返しますが、LLMの出力には揺れがあり、「本当に良くなったのか」を定量的に測れないと、調整が勘になってしまいます。だからこそ、評価の自動化が先に来るべきだったのです。
プロジェクトの中での動き方
3人チームで案件を進める中で、技術以外の動き方も学びました。商談では先輩方にフォローいただきながらチームとして対応し、定例会ではネクストアクションを毎回確認することでプロジェクトを着実に前に進める。こうした「チームの一員としての立ち回り」は、一人で開発しているだけでは得られなかった経験です。
プロダクトがあったからこそ
この案件は、プロダクトなしでは到底こなせない難易度でした。LLMの不確実性をプロダクトが吸収してくれること、複雑で長い処理でも安定して動作すること。この2つがあったからこそ、少ない工数で高品質な成果物を出すことができました。
さらに、以前のFDEの方が別案件で得た知見がプロダクトに蓄積されていたおかげで、ゼロからではなく「積み上げ」の上で仕事ができました。記事の前半で書いたはずみ車を、インターンの立場でも実感できた経験でした。
トライアルの結果、お客様から 「作業時間が大幅に削減できそうだ」 という評価をいただきました。自分が関わったプロジェクトでこうしたフィードバックを直接聞けたのは、大きなやりがいでした。
さいごに
1.5ヶ月ほど、学業・プライベートでやる事が多く、お休みをいただいてました。お休みをいただく際も復帰した際も、チームの方々は温かかったです。良い環境だと思います。
復帰してみると、移動等でFDEチームのインターンが私1人になってしまっていて、なんか寂しいので募集要項を貼っておきます。以下からご連絡お待ちしております！
