JAPAN AI株式会社 PjM部マネージャーの難波です。
現在は法人向けAIエージェントの導入プロジェクトを複数担当しており、要件定義や業務整理から、エージェントの設計・検証・定着支援までを一気通貫で支援しています。
本稿では、Forward Deployed Engineer（FDE）的な立場から、オンサイトで現場に入り込みつつAIエージェント導入を進めてきた実践内容を、できる限り一般化して整理していきます。
FDE（Forward Deployed Engineer）は、単に「顧客先に常駐して開発を行うエンジニア」ではなく、現場の業務と技術の間に立ち、両者を接続する役割を担う存在だと私は考えています。
業務の現場では、手書きの伝票、複数のExcelファイル、基幹システムやクラウドサービス、そして担当者ごとの暗黙知やローカルルールが複雑に絡み合い、その全体像は一見すると把握しづらいものです。AIエージェントを導入するためには、この「絡み合っている状態」をそのまま自動化しようとするのではなく、どこに判断の核があり、どの情報を根拠として業務が成立しているのかを、まず明らかにしなければなりません。
FDEは、この過程で中心的な役割を果たします。具体的には、現場の作業を観察し、担当者と対話しながら、業務の中に埋もれている判断ロジックや例外処理のパターンを抽出し、それらをエージェントが扱える「構造」にまで落とし込んでいきます。そのうえで、「どこまでを生成AIのタスクとし、どこからを決定論的なシステム処理とするのか」「利用者にはその境界を意識させない形でどう統合するか」といった設計を行うことが、FDEの価値の中核になります。
以下では、実際のプロジェクトを抽象化しながら、業務構造の捉え方、エージェント設計の考え方、生成AIとシステム処理の切り分け方、そして継続的なエージェント開発を通じてナレッジが蓄積されていくプロセスについてお話しします。
現場で行われている業務は、一見すると担当者の経験や勘に依存しているように見えることが多いのですが、時間をかけて観察し、なぜその操作を行っているのか、なぜその順番で確認しているのか、といった問いを丁寧に重ねていくと、背後には必ず「入力」「参照」「判定」「出力」といった処理の構造が存在していることが分かります。
たとえば、手書きの伝票を見ながらExcelに入力している作業であっても、実際には「伝票のどの情報を信頼し」「どのマスタで裏を取り」「どの条件で例外扱いにしているか」といった論理が存在しています。FDEとしてプロジェクトに入る際、私はまずこの「現場で行われている一連の操作」を、可能な限り構造として捉え直すところから始めます。
それを図式化すると、概ね次のような流れになります。
この図が示しているのは、FDEが「現場の作業」そのものを自動化しようとするのではなく、まずはそれを「業務API」のような単位へと変換しているということです。業務APIとは、特定の業務を「ある形式の入力を受け取り、定められたルールに基づいて処理し、期待される形式の出力を返すもの」として取り扱うための抽象的な枠組みです。この抽象化を行うことで、生成AIや既存システムと、業務の世界を接続しやすくなります。
プロジェクトの初期段階で、この構造化をどこまで丁寧に行えるかによって、その後の設計・開発・改善の難易度は大きく変わります。構造が曖昧なままエージェントを作ってしまうと、後から大量の例外が出てしまったり、仕様の修正と検証が何度も必要になったりしてしまいます。
業務APIとしての構造が見えてくると、次に考えるべきは「どの単位でエージェントを分けるか」という設計の問題です。
ここでありがちな失敗は、「全部をひとつのエージェントに押し込んでしまうこと」です。確かに、一見すると「何でも任せられる一体型エージェント」は魅力的に見えますが、現実には問題が発生した際の原因切り分けが難しくなり、改善サイクルが極端に回しづらくなります。