SERVICE

ITソリューション事業／ FDE

当社は、FDE をサービスとして提供しています。

FDE（Forward Deployed Engineer）として、お客様の開発や業務に入り込み、何を正しいとするか（正本）を定義し、
AI と人が担う仕組みとして組み込むところまでを担います。

DEFINITION

常駐型の FDE と、当社の FDE

FDE という言葉は、客先に常駐して開発や作業を代わりに担う役割の意味で使われることもあります。当社の FDE は、働く場所ではなく、お客様に何を残すかで定義しています。

	一般的な常駐型の FDE	当社の FDE
主な役割	客先に常駐し、決められた要件に沿って開発や作業を代わりに担う	お客様の業務と開発に入り込み、業務のルール（正本）を定義して仕組みにする
仕事の起点	提示された要件や仕様書	今の業務の棚卸しと、ルール・基準（正本）の定義
AI と人の分担	人が主に開発・作業し、AI は補助の道具として使う	ルールで決まる処理はコードに、決まらない処理の推論は AI に任せ、人が確かめて確定する
支援のあとに残るもの	納品されたシステムと、仕様書などのドキュメント	定義したルール（正本）と仕組みがお客様の側に残り、日々の運用の中で育っていく

TWO TYPES

FDE の 2 つの種類

開発の基盤をつくる FDE と、定型業務を効率化する FDE があります。

01
AI 駆動開発基盤の構築
お客様の開発チームに入り、AI エージェントが実装し、人が要所で判断する開発の基盤をつくります。AI にさせてはいけないことは、ルールを増やすのではなく、API による責務の分離と権限で構造として決めます。そのうえで、変更ごとの自動チェックとリスクに応じた人のレビューを、開発の流れに組み込みます。
- 責務の分離（API）
- 権限の分離
- 自動チェック（CI）
- リスクに応じたレビュー（HITL）
- 並列で動く AI エージェント
このページで詳しく
▶ 01 AI 駆動開発基盤の構築（構造で決めること・進め方・AIOps）
02
非エンジニアの定型業務の効率化
AI で解決することから始めません。生産性の向上から逆算して、業務フロー、部門ごとの責務の境界、システムの変更、マニュアルの設計のうち、何が適切かを見極めます。
- 業務フロー
- 部門ごとの責務の境界
- システムの変更
- マニュアルの設計
- AI の組み込み
AI は、ルールが整っていないところで動かすとハルシネーションが増え、確かめ直す手間でかえってコストが上がります。ルールを先に整え、答えが一つに決まらない処理にだけ AI を使います。
このページで詳しく
▶ 02 定型業務の効率化（進め方と、精度を上げる領域の例）

FDE 01

FORWARD DEPLOYED ENGINEER

AI 駆動開発基盤の構築

お客様の開発チームに入り、AI エージェントが実装し、人が要所で判断する開発の基盤を、お客様のリポジトリと開発の流れに合わせて組み込みます。実装・テスト・一次レビューは AI エージェントが担い、変更のリスクに応じて人のレビューと承認を挟みます。

FOUNDATION

AI 駆動開発の基盤で整えること

ルールを増やすのではなく、AI にさせてはいけないことを構造で決めます。そのうえで、AI と人が同じ確認を通る開発の基盤をつくります。

01
責務を分ける
サービスと API で責務を分け、サービスどうしは API の仕様だけでつなぎます。
02
権限で閉じる
本番のデータ・ログ・認証情報は、エージェントの権限の外に置きます。
03
同じ確認を通す
AI と人のどちらが書いた変更にも、同じ自動チェックをかけます。
04
人が確かめる所を決める
リスクの高い変更（課金・権限・本番データ・外部連携）は、人のレビューを必須にします。
05
本番は人が動かす
マージ・デプロイ・本番の操作は、人の明示的な指示でのみ行います。

PROCESS

AI 駆動開発の進め方

エージェントが自律的に進める区間と、人が判断する区間（HITL）を工程ごとに分けています。

担当者
01
課題の定義
受入条件・スコープ・リスクを書く
AI
02
実装
課題ごとに並列で実装し、担当サービスの中で、API の仕様に沿って書く
AI
03
クロスレビュー
別のエージェントが差分を確認し、指摘を修正する
AI
04
CI ゲート
リスクに応じた検証。失敗した箇所はエージェントが修正
担当者
05
HITL レビュー
リスクの高い変更（課金・権限・本番データ・外部連携）は人のレビュー必須
担当者
06
本番反映
merge・deploy・migration・apply は人の明示指示でのみ実行

エージェントの権限は段階に分けます（編集・テスト／コミット・PR ／マージ・デプロイ・本番操作）。マージ・デプロイ・本番操作は人の明示的な指示でのみ行い、自律的に連鎖させません

AUTOMATED CHECKS

変更ごとの自動チェック

AI と人のどちらが書いたコードにも、同じ確認をかけます。ツールはお客様の環境に合わせます（図は一例）。

01
変更
AI エージェントやエンジニアがコードを変更する
02
リスクを分類
リスクを段階で分類し、分類できない変更は最も厳しい基準で扱う
03 CI（例: GitHub Actions）
型の検査・静的解析
単体テスト（Vitest）
実データベースでの結合テスト
影響する画面の E2E（Playwright）
秘密情報・脆弱性の検査
04
AI による画面確認
AI 操作用のブラウザで人と同じ手順で操作。PC とスマートフォンの画面幅で表示を確認
05
人のレビュー
課金・権限・本番データ・外部連携の変更は必須
06
マージ
すべての確認を通過してからマージする

STRUCTURE

構造

AI にさせてはいけないことを、構造で決める

AI にさせてはいけないことを、ルールとして読ませるのではなく、構造で決めます。どこで決め、エージェントから見るとどうなるかを示します。

構造で決めること	どこで決めるか	エージェントから見ると	こうなる
責務の分離	サービスごとのコードとデータベース、公開 API の仕様（OpenAPI）	サービスどうしは API の仕様だけでつながる。ほかのサービスのデータベースへの接続先は持たない	境界を越える実装が動かない
権限の分離	エージェントの権限と、本番の権限を分ける	エージェントが届くのは、担当のコードと開発・テスト用のデータまで	本番のデータ・ログに届かない
認証情報の置き場所	秘密情報の保管庫（Secret Manager など）	本番の環境が実行するときにだけ読み込む。エージェントの環境には本番の値がない	コードにもプロンプトにも入らない
判断の前提	設計判断の記録（ADR）と、型・スキーマ	構造で決めきれない判断の理由と、値の形を、実装やレビューのときに参照する	判断の理由が引き継がれる

AIOps × 開発

ルールを増やすのではなく、構造で AI にできないことを決める

上の構造は、一度つくって終わりではありません。AI エージェントに開発を任せるとき、大切なのはコーディングのルールを増やすことではありません。ルールは読み落とされることがあり、増えるほど互いに食い違います。AI にさせてはいけないことは、構造でできないようにします。サービスと API で責務を分け、サービスどうしは API の仕様（OpenAPI など）だけでつなぎます。ほかのサービスのデータベースには、接続先も認証情報も持たせません。本番のデータベースやログ、認証情報には、エージェントの権限では届きません。本番への反映は、人の明示的な指示でのみ行います。レビューで見つかった失敗も、ルールの追記だけで済ませず、責務の分け方・API の仕様・権限といった構造の見直しに戻します。

具体例をコードで見る

01
責務を分ける
サービスと API で責務を分けてエージェントが触れる範囲を決める
02
権限で閉じる
本番のデータやログ、認証情報にはエージェントの権限ではアクセスできない
03
仕様でつなぐ
サービスどうしは、API の仕様だけでつなぐ。仕様にないことは、そもそもできない
04
失敗を構造に戻す
失敗はルールの追記だけで済ませず、責務の分け方や API の仕様、権限の見直しにつなげ、人が判断して取り込む

↺ 次の課題も、同じ構造の中でエージェントが実装する。守らせたいことは、読ませるのではなく、構造で止める

01
API の仕様で、サービスの境界を守らせる
これまで別の機能のデータベースを直接読む実装が入り、機能どうしが絡み合う。レビューのたびに指摘する。
AI を組み込むとサービスごとにデータベースを分け、ほかのサービスとは公開 API の仕様（OpenAPI）だけでつなぐ。各サービスは、ほかのサービスのデータベースへの接続先も認証情報も持たないので、境界を越える実装は書いても動かない。
境界を越える実装は、動かない
```
# API の仕様（勤怠サービスの公開分）GET /attendance/monthly-summaryresponse: MonthlySummary # 仕様にない項目は返らない# 呼び出す側（請求サービス）+ const s = await attendance.getMonthlySummary(staffId, month)// 勤怠のデータベースへの接続先は持たない
```
02
本番のデータとログに、エージェントが届かない
これまで不具合を調べるために、本番のデータやログを AI に見せたくなる。
AI を組み込むとエージェントの権限は、担当のコードとテスト用のデータまで。本番のデータベース・ログ・認証情報は別の権限にあり、エージェントからは読めない。調査は、AI が書いた集計スクリプトを人が本番の環境で実行し、結果だけを渡す。
守らせたいことを、読ませずに構造で止める
```
# エージェントの権限（例）読み書きできる: 担当サービスのコード、テスト用のデータ読めない: 本番のデータベース、本番のログ、認証情報実行できない: マージ・デプロイ・本番の変更（人の明示的な指示のみ）
```
03
認証情報は、エージェントの環境に置かない
これまで「API キーをコードに書かない」とルールに書いても、急ぎの修正で書かれてしまうことがある。
AI を組み込むと認証情報は秘密情報の保管庫（Secret Manager など）に置き、本番の環境が実行するときにだけ読み込む。エージェントの環境には本番の認証情報が入っていないので、コードにもプロンプトにも書きようがない。
ルールを守らせるのではなく、守るしかない構造にする
```
# 本番の環境の設定（例）DATABASE_URL: 保管庫から実行時に読み込むAPI_KEY: 保管庫から実行時に読み込む# エージェントの環境本番の認証情報: なし（開発用の値だけ）
```

SAFE BY DESIGN

怖いところは AI にやらせず、コードを作らせる

個人情報や秘密情報を AI に直接見せたり、本番を AI に直接操作させたりはしません。AI に渡すのはデータの形（項目名とダミーの例）だけで、AI にはそれを扱うコードとスクリプトを作らせます。人がレビューし、データがある環境の中で実行します。AI がなければ書ききれない量のスクリプトで、データを外に出さない運用をつくります。

AI に直接やらせないこと

本番のデータベースのデータを、エージェントに見せる
API キーなどの秘密情報を、コードやプロンプトに書く
エージェントに本番の操作を任せる

代わりに AI に作らせるもの

スキーマから、匿名化したテストデータを作るスクリプト
ログの個人情報を自動でマスクする処理
秘密情報が混ざっていないかを検査する CI の仕組み

AI がコードを作る
データの形とダミーの例だけを見る
人がレビューする
処理の中身と出力を確かめる
お客様の環境で実行
データはこの環境から出ない
AI が受け取るもの
テストと CI の結果、スキーマなどの構造情報だけ

コードやテスト、仕様書の変更は、必ず人がレビューしたうえで取り込みます。本番環境での操作は、人が明示的に指示したときのみ実行します（HITL）。コードは説明のための例です。

FDE 02

FORWARD DEPLOYED ENGINEER

非エンジニアの定型業務の効率化

営業・事務・カスタマーサポートなど、エンジニアではない方が日々行う定型業務が対象です。業務の棚卸しから運用の中で正本を育てるところまでを、下の 5 つの手順で進めます。

HOW WE WORK

業務ロジック

定型業務の効率化の進め方

商談のフェーズ、取引先の名寄せ、割引の承認など、正しい扱いが場面によって変わる業務を例に、進め方を示します。例は CRM（顧客管理）の業務です。

進め方

01
業務を棚卸しする
業務フローと、部門ごとの責務の境界を書き出します。生産性の向上から逆算して、業務フロー・責務の境界・システムの変更・マニュアルの設計・AI のうち、何を変えるのが適切かを測ります。AI から始めることはしません。
02
正本を定義する
どれがルールで、その処理がどのルールから来ているかを決め、1 か所に置きます。たとえば商談フェーズの定義と各フェーズで必須の項目、取引先の正式名称と名寄せのルール、割引の承認基準です。入力に頼ると間違えやすいところほど、先に正本にします。
03
決定論と非決定論に分岐させる
定型業務の中でも、ルールで答えが一つに決まる処理と、答えが一つに決まらない処理があります。処理ごとにどちらかを見極めて分岐させ、決定論の処理はルールとコードで確実に処理し、AI は非決定論の処理だけに使います。
決定論で処理する
ルールで答えが一つに決まる。ルールとコードで、毎回同じ結果を出す
商談フェーズごとの必須項目のチェック（入力規則）
見積の割引率に応じた承認ルート（承認プロセス）
地域・業種によるリードの担当者の割り当て
契約の更新日が近い取引先への期日通知
処理ごとに分岐する← →
非決定論で処理する（AI）
答えが一つに決まらない。AI が推論し、結果は正本に照らして確かめる
名刺やメールの署名からのリード情報の読み取り（登録済みの取引先と照合）
表記の揺れがある会社名の名寄せの候補
商談メモや通話記録の要約と、次のアクションの下書き
問い合わせ（ケース）の分類と回答案（ナレッジを参照）
処理のフロー
どちらの処理も同じ正本を参照します。AI の結果は正本に照らして確かめ、食い違うものだけを人が判断します。
本当にコストを下げるなら、処理の入力をどう受け取るかから設計します。
紙やメール、自由記述のまま受け取ると、その先はすべて AI の推論と人の確認に頼ることになり、確認の手間が残ります。入力の段階で項目と形が決まったデータとして受け取れれば、その先を決定論で処理できる範囲が広がります。フォームの設計やシステム間の連携など、入力そのものを変えるところから見直します。
AI を業務に組み込むうえで大切なのは、どこで人が確かめるか（HITL）です。
AI の結果をすべて人が見直すと、AI を入れた意味がなくなります。人が一度も見なければ、誤りがそのまま業務に流れます。正本と食い違うもの、確からしさが低いものだけを人に回す。その境目を、処理ごとに決めて設計に入れます。
04
正本を参照する形で組み込む
ルールで処理する部分も AI も、同じ正本を参照するように組み込みます。AI の結果は正本に照らして確かめ、確からしさの低いものや食い違うものは、人が判断して確定します（HITL）。
正本の定義と、精度を上げる領域の例を見る例を閉じる
※ 例は、CRM（顧客管理）の業務で示しています。
AS-ISTO-BE
読み取りの精度
AS-IS
名刺やメールの署名を手で入力し、表記の揺れや入力ミスが残ることがある。
TO-BE
正本：項目と形の定義
会社名・氏名・役職・連絡先の項目と形を先に定義し、AI の読み取り結果をそれに照らして確かめてから登録する。
入力の正確さ
AS-IS
同じ会社が別の名前で登録され、取引先やリードが重複することがある。
TO-BE
正本：登録済みの取引先
登録済みの取引先と照らし合わせ、名寄せの候補を確からしさ付きで示す。担当者は確かめて登録する。
ミスの検知
AS-IS
お客様から届いた注文書と見積を目で突き合わせると、金額や条件の食い違いを見落とすことがある。
TO-BE
正本：価格表と見積
注文書を AI が読み取り、見積と価格表に照らして一件ずつ突き合わせ、食い違うものを示す。
漏れの補正
AS-IS
商談メモの書き方が人によってばらつき、決裁者や次のアクションが抜けることがある。
TO-BE
正本：フェーズごとの必須項目
記録するときに、フェーズごとに必要な項目のうち足りないものを AI がその場で聞き取り、そろえる。
内容の質
AS-IS
問い合わせへの回答の質が、担当者によってばらつく。
TO-BE
正本：ナレッジと商品情報
ナレッジと商品情報に沿った回答案を AI が出す。元にない内容は書かせない。
精度を上げる領域は、業務の流れのここにある
既存の処理業務の流れ
取り込む
名刺・メールの署名
登録する
リード・取引先
突き合わせる
見積と受注
記録する
商談の活動
書き出す
問い合わせへの回答
AI精度を上げる層
読み取りの精度
入力の正確さ
ミスの検知
漏れの補正
内容の質
正本 ── 何を正しいとするかを、期待する出力から逆算して一つずつ定義する
項目と形の定義
会社名・氏名・役職・連絡先などの項目と形
登録済みの取引先
取引先の正式名称と、名寄せのルール
価格表と見積
価格表、割引の承認基準、承認済みの見積
フェーズごとの必須項目
商談フェーズの定義と、各フェーズでそろえる項目
ナレッジと商品情報
承認済みのナレッジ記事と、商品・契約の情報
人（HITL）確かめて確定する
HITLAI の結果は、担当者が正本に照らして確かめ、登録・提出を決める。正本と食い違うものや確からしさの低いものは、人の判断に回す
05
運用の中で正本を育てる
例外や差し戻しを記録し、正本とマニュアルを更新します。対応を重ねるほど、ルールで処理できる範囲と AI の精度が上がっていきます（AIOps）。