FDEは日本に定着するか――真価が問われるのはAIの実証実験の後

カスタマーサービス部門が、限られた問い合わせを対象にAIエージェントを試す。デモはうまくいく。エージェントは情報を検索し、回答案を作成し、次に取るべき対応を提案する。経営陣は導入範囲の拡大を承認する。

そして、実際の業務につないだところで問題が現れる。

顧客記録には矛盾する情報がある。問い合わせの中には、ベテラン社員が経験を頼りに処理している例外対応が必要なものもある。エージェントは返金を提案できるが、実際に返金を実行する権限を与えてよいかは誰も決めていない。回答に誤りがあった際には、業務部門とIT部門の間で、どちらが調査を担うべきか意見が分かれる。

モデルの能力は、デモには十分だった。しかし、本番導入にはそれだけでは足りなかった。

この隔たりを埋める役割として期待されているのが、Forward Deployed Engineer、略してFDEだ。自ら実装を担うエンジニアリングと、顧客業務への直接的な関与を組み合わせ、課題の定義から稼働後のシステム改善まで携わる。

日本で問われるのは、企業がこうしたエンジニアに、仕事を進めるために必要な情報や現場へのアクセス、そして権限を与えられるかどうかだ。新しい肩書きを設けるだけでは、AIプロジェクトは本番稼働に進まない。

FDEが注目される理由#

提供されたZDNET Japanの記事は、セールスフォース・ジャパンがパートナー企業9社とともに、Forward Deployed Engineering Partner Networkを国内で展開する動きを伝えている。この取り組みは、顧客がAgentforceの試験導入から本番運用へ移行するのを支援するものだ。

記事で引用されたSalesforceの説明によると、海外では、すでにAgentforceの導入成功事例の3分の1を、この取り組みに参加するパートナーが担っているという。これはベンダー側が公表した数字だ。提供資料には、Salesforceが成功をどう定義し、どの導入事例を集計対象にしているかの説明がないため、事業効果を裏付ける独立した証拠として扱うべきではない。

それでも、ビジネス上の方向性は明確だ。AIベンダーには、顧客に製品を日常的に使ってもらう必要がある。デモに成功しても、システムが業務プロセスに組み込まれなければ、継続的な需要にはつながらない。

記事では、アクセンチュア幹部の田村広亮氏が、顧客の要件を実行するエンジニアから、顧客の成果にコミットするパートナーへの転換を説明している。この違いは、何をもって仕事の完了とするかにある。割り当てられた作業を終えることなのか、それとも測定可能な事業効果を生み出すことなのか、という違いだ。

これは有益な目標だ。ただし、慎重に解釈する必要もある。人員配置や顧客企業の方針、経営陣の行動に左右される成果を、エンジニアが保証することはできない。FDEが責任を持てるのは、ソフトウェアを納品して後の解決を顧客任せにするのではなく、そうした依存関係を特定し、可視化することだ。

有用な役割だが、まったく新しい職種ではない#

FDEは、AI時代に生まれた新しい職種として紹介されることがある。しかし、その基礎にある仕事は、それほど新しいものではない。

顧客の組織に入り込むエンジニアや導入コンサルタント、技術専門家は以前から存在していた。優れた実務家は、すでに業務を調査し、要件を問い直し、システム連携を構築し、定着を支援している。

AIエージェントによって変わるのは、担う責任の組み合わせだ。エージェントは、曖昧な依頼を解釈し、ツールを選び、操作を開始することがある。その振る舞いは、処理を止めて人に助けを求めるべき場面も含め、さまざまな状況で評価しなければならない。

そのため、ソフトウェアの設定にとどまらない仕事が生じる。

例外対応も含め、従業員がどのように判断しているかを理解する。
適切な権限を設定したうえで、エージェントをデータやシステムに接続する。
現実的なケースや失敗が起こる条件に照らして、振る舞いを評価する。
本番での利用状況を監視し、状況の変化に応じてワークフローを調整する。

FDEの必要性を最も強く裏付けるのは、これらの活動には継続して関わることの利点があるという点だ。なぜその例外が存在するのかを理解した人が、実装やテストにも引き続き関わるべきだ。

一方、最も形骸化した姿は、人員配置の仕組みを改称しただけのものだ。エンジニアはチケットを受け取り、顧客先で作業するが、業務プロセスを問い直す権限は持たない。それも開発・導入業務としては役に立つかもしれないが、FDEに期待される、より広い価値は実現できない。

日本での普及を左右するのは、組織の内側にどこまで関われるか#

提供された記事でのアクセンチュアの説明は、実装能力、対応速度、技術選択の柔軟性に不足があると指摘している。これらは、日本企業がAIの実験を事業成果につなげるうえで苦戦する理由として挙げられている。

この見立てには説得力がある。ただし、すべての日本企業が同じ問題を抱えている証拠ではない。導入を検討する企業は、新しい役割を解決策として採用する前に、自社で停滞しているプロジェクトを調べるべきだ。

FDEが適しているのは、技術上の判断と業務上の判断が、互いに繰り返し進行を妨げている場合だ。例えば、不確実なケースを誰が処理するかについて業務責任者の合意がないため、エンジニアがエスカレーション経路を設計できない。一方、業務責任者も、不確実なケースがどの程度発生するかを誰も検証していないため、方針を確定できない、といった状況がある。

組織に入り込むエンジニアは、小規模で結果を確認できる導入を通じて、この循環の解消を支援できる。ただし、物理的に同じ場所にいることより、必要な現場や情報にアクセスできることのほうが重要だ。

エンジニアには、実際の仕事を観察し、利用者と話し、関連データを確認し、変更を提案する権限が必要になる。要件定義書と月1回の進捗会議しか提供しない顧客が、期待された効果を得るのは難しい。

社内の責任者も必要だ。業務プロセスの仕組みを理解しているのがベンダーのエンジニアだけ、という状態にしてはならない。顧客側には、業務方針に責任を持つ人と、技術システムを保守できる人が必要だ。小規模な導入なら、少人数のチームでこれらの責任を担ってもよい。

導入件数ではなく、業務の改善を測る#

「成果へのコミットメント」は説得力のある言葉だ。しかし、契約で「成果とは何か」を定めようとすると、その意味が問われる。

問い合わせ対応を支援するAIエージェントを考えてみよう。導入件数、回答の生成数、従業員のログイン数を数えれば、システムが使われているかは分かる。しかし、サービスが改善されたかどうかは分からない。

より適切な評価では、次の4つの指標を使って導入前後の実績を比較する。

| 指標 | 把握できること | |---|---| | 対応時間 | ワークフローによって作業負担が減るか | | 解決の品質 | 回答が正確で、必要な内容を満たしているか | | エスカレーションと手戻り | 自動化によって別の場所に仕事が移っていないか | | 問い合わせ解決1件あたりのコスト | 運用コストを考慮しても効果が残るか |

これらの指標は、定義について合意しておく必要がある。対応が速くなっても、従業員が後から誤りを修正するために余分な時間を費やすなら、改善とはいえない。

開発前に、代表的なサンプルからベースラインを記録する。改善目標の水準と、許容できない失敗の条件についても合意する。顧客記録を変更できるエージェントの場合、平均的な成績が良好でも、権限外の操作があれば即時停止が必要になることがある。

顧客とともにこの評価を設計することも、FDEの価値の一部だ。結果をどう測るか説明できないチームは、その結果に責任を持つと主張できる段階にはない。

ベンダーロックインは日々の判断を通じて深まる#

提供された抜粋では、ベンダーロックインが懸念として挙げられているが、詳しい議論は資料に含まれていないページに掲載されている。そのため、以下のリスクは導入モデルについての分析であり、欠けている箇所の内容を再現したものではない。

ベンダーやそのパートナーが深く関われば、導入を加速できる。一方で、あらゆる問題に対して、そのベンダーのプラットフォームを使うことが既定の答えになりかねない。

依存は、日常的な選択を通じて積み重なる。ワークフローのルールをどこに保存するか、ツールをどう接続するか、どの監視機能を使うか、顧客が評価データをエクスポートできるか、といった選択だ。

だからといって、それだけでFDEを採用しない理由になるわけではない。どのプラットフォームにも、ある程度の切り替えコストはある。実務上の論点は、そのコストを理解し、許容できるかどうかだ。

発注側は、次の4つを成果物として求めるべきだ。

1. 顧客が参照できる、ワークフローとシステム連携の文書。 2. 実際の業務ケースに基づく、再利用可能な評価セット。 3. データ、設定、カスタムコードについて、権利の帰属とエクスポート条件を明確にした規定。 4. プラットフォーム固有の依存関係と、代替手段を記した文書。

受け入れ確認として有効なのは、納品された資料を使い、社内チームにワークフローのルールを1つ変更してもらい、意図的に発生させた障害を1つ診断してもらうことだ。外部エンジニアなしではどちらもできないなら、引き継ぎは完了していない。

範囲を限定した本番プロジェクトから始める#

FDEの支援は、評価できる程度に範囲が狭く、取り組む価値がある程度に重要な業務から始めるべきだ。最初から部門全体を横断して動くエージェントを目指すのは避けたい。

90日間の支援を想定するなら、4つの段階に分けられる。以下の日程は計画の一例であり、業界標準ではない。

1〜15日目：業務を観察し、目指す成果を定義する。 従業員とともに実際のケースを確認する。例外、必要なデータ、人の承認が必要な操作を特定する。ベースラインを記録し、社内の業務責任者を選ぶ。

16〜40日目：構築し、評価する。 役に立つ最小限のワークフローを実装する。通常のケースに加え、情報の欠落、記録の矛盾、エージェントの権限を超える依頼もテストする。結果を確認する前に、本番稼働の判断基準に合意しておく。

41〜70日目：対象を限定して本番導入する。 業務に適した本番環境の権限を使う。エスカレーション経路と、エージェントを停止する手段を確保する。導入範囲を広げる前に、繰り返し起きる問題を把握できる頻度でエラーを確認する。

71〜90日目：評価し、責任を引き継ぐ。 手戻りと運用コストも含め、結果をベースラインと比較する。文書を整備し、保守作業の演習を完了する。拡大、見直し、中止のいずれかを判断する。

最終判断は、あらかじめ決めつけてはならない。拡大を見送るべきだという信頼できる証拠が得られた場合でも、その支援は、より大きな投資の失敗から顧客を守ることができる。