結論
中小企業のAI導入では、モデル選定より先に、現場の業務・評価条件・失敗時の戻し方を決めることが重要です。そのための進め方として、顧客の現場に入り、課題発見から実装・本番運用まで一貫して担うFDE（Forward Deployed Engineer）の考え方が使えます。
この記事では、熊本の中小企業を想定しつつ、地域を問わず再利用できるAI導入の実装チェックリストをまとめます。AIチャットボット、社内RAG、文書作成支援などに共通する内容です。
FDE方式とは
OpenAIはForward Deployed Engineerについて、顧客と共に課題を発見し、技術的なスコープを整理し、システム設計、構築、本番展開、利用定着まで担う役割として説明しています。Palantirも、エンジニアが課題へできるだけ近づき、現場のフィードバックを機能へ反映するForward Deployed Engineeringを紹介しています。
通常の受託開発との違いを単純化すると、次のようになります。
| 観点 | 仕様受領型 | FDE方式 |
|---|---|---|
| 開始点 | 決まった要件 | 現場の課題・業務観察 |
| 成果 | 納品 | 本番で使われる状態 |
| 改善材料 | 追加要望 | 利用ログ・誤答・現場の声 |
| 担当範囲 | 実装中心 | 発見、設計、実装、定着 |
FDEは職種名として使われることも、プロジェクトの進め方として使われることもあります。中小企業では専任のAI担当者を採用するのが難しいため、必要な期間だけ外部FDEと組む形も現実的です。
Step 1：業務を「入力・判断・出力」に分ける
最初にツールを選ばず、対象業務を次の形式で1枚にします。
| 項目 | 確認内容 |
|---|---|
| 入力 | 誰が、どこから、何を受け取るか |
| 判断 | どのルールや経験で判断しているか |
| 出力 | 誰に、何を、どの形式で返すか |
| 例外 | 人に戻す条件は何か |
| 頻度 | 1日・1週間に何件あるか |
| 制約 | 個人情報、機密情報、期限、権限 |
たとえばECの問い合わせ対応なら、入力は顧客の質問、判断材料は商品情報・配送条件・返品規程、出力は回答文です。例外として、クレーム、決済、個人情報を含む問い合わせは担当者へ戻す、と決められます。
この分解をすると、AIに任せる部分と、従来どおり人が判断する部分を分けやすくなります。
Step 2：受け入れ条件を先に決める
「便利になった」では評価が揺れます。試作前に、確認できる条件を決めます。
- 対象質問に対して根拠付きで回答できる
- 根拠がない場合は推測せず「分からない」と返す
- 対象外の質問を人へ引き継げる
- 個人情報や機密情報を回答へ混ぜない
- 担当者が参照文書を更新できる
- 応答時間と利用費が許容範囲に収まる
数値目標は業務ごとに異なります。最初から高い自動化率を置くより、20〜50件程度の代表的な質問セットを作り、正答・部分正答・誤答・回答拒否を人が確認できる形にする方が安全です。
評価データの最小形式は、たとえば次のようにできます。
{
"id": "faq-001",
"question": "返品期限はいつまでですか？",
"expected_source": "return-policy-v3",
"must_include": ["到着後7日以内"],
"must_not_include": ["返金を保証します"],
"handoff_required": false
}
本番前後で同じ質問セットを流せば、プロンプトや参照文書の変更による劣化も検知しやすくなります。
Step 3：小さなアーキテクチャで試す
社内文書検索や問い合わせチャットの最小構成は、次の4層で考えられます。
- UI層：Webチャット、社内画面、フォーム
- 制御層：認証、入力検査、プロンプト、ツール実行
- 知識層：商品情報、規程、FAQ、ベクトル検索
- 観測層：会話ログ、参照元、評価、エラー、費用
PoCの段階から観測層を外さないのがポイントです。回答本文だけ保存しても、なぜその回答になったか検証できません。最低限、以下を記録します。
type AiInteractionLog = {
requestId: string;
occurredAt: string;
useCase: "customer_support" | "internal_search" | "drafting";
retrievedDocumentIds: string[];
model: string;
latencyMs: number;
inputTokens?: number;
outputTokens?: number;
outcome: "resolved" | "handoff" | "abandoned" | "error";
reviewerRating?: "good" | "partial" | "bad";
};
個人情報をログへ残す必要があるかは別途判断します。残さなくてよい情報は収集しない、閲覧権限と保存期間を決める、という順序が基本です。
Step 4：人へ戻す経路を実装する
生成AIは確率的に文章を作るため、誤答をゼロにはできません。そこで「自信が低いとき」だけでなく、業務ルールで人へ戻す条件を作ります。
- 決済、契約、法務、医療など高リスクな内容
- 個人情報を含む依頼
- 参照文書が取得できなかった場合
- 複数文書の記載が矛盾する場合
- 同じ質問が繰り返された場合
- ユーザーが担当者対応を希望した場合
引き継ぎ時には、会話全文をただ送るより、「質問」「参照した文書」「AIが試した回答」「引き継ぎ理由」をセットにすると、担当者の確認時間を減らせます。
Step 5：本番後の改善ループを作る
週次で確認する指標は、利用回数だけでは不十分です。
| 分類 | 指標例 |
|---|---|
| 利用 | 会話数、利用者数、継続利用率 |
| 品質 | 解決率、誤答率、回答拒否率、根拠表示率 |
| 業務 | 対応時間、引き継ぎ件数、手直し時間 |
| 顧客 | 離脱箇所、繰り返し質問、未充足ニーズ |
| コスト | 1会話あたりAPI費、運用工数 |
改善は次の順に行うと原因を追いやすくなります。
- 参照文書の不足・重複・古さを直す
- 検索条件とチャンク設計を調整する
- プロンプトと出力形式を調整する
- UIと人への引き継ぎを改善する
- 必要ならモデルを変更する
最初からモデル変更へ飛ぶと、データ品質や業務設計の問題が残ったままになりがちです。
現場訪問が効く場面
オンラインヒアリングだけでは、紙で残している理由、担当者が画面を切り替える順番、口頭で補っている判断が見えにくいことがあります。特に次の場合は現場確認が有効です。
- 紙、Excel、メール、基幹システムをまたいでいる
- 業務手順書と実際の運用が違う
- ベテラン担当者の暗黙知が多い
- AI導入に不安を持つ利用者がいる
- 経営者と現場で期待する成果がずれている
現場で見た結果、「AIを入れる前に情報の置き場所を統一する」が最初の改善になることもあります。それもFDE方式の重要な成果です。
導入前チェックリスト
- 対象業務を1つに絞った
- 入力・判断・出力・例外を整理した
- 代表質問と期待回答を用意した
- 参照データの所有者と更新担当を決めた
- 入力禁止情報を決めた
- 人へ戻す条件を決めた
- ログ項目と保存期間を決めた
- 成功指標と中止条件を決めた
- 本番後の改善担当と頻度を決めた
熊本でのAI・FDE導入支援
Bear Gate Love Corp.では、熊本県内への訪問に対応し、課題整理、試作、実装、導入後の改善まで代表が直接支援しています。熊本市内は迅速に日程を調整します。
サービス内容と進め方は、熊本のAI・FDE導入支援ページにまとめています。最初の相談は無料です。
参考資料
この記事は、上記の公式情報と実務で一般に必要となるAIシステムの設計・運用観点をもとに構成しました。個別の業務では、扱うデータ、法令、契約、利用サービスの仕様に応じた確認が必要です。