業務AIエージェントの失敗を防ぐために — FDEとして現場で学んだ「AI 2割・決定論 8割」の設計
はじめに — FDE として現場で得た結論
私はこの1年あまり、FDE（Forward Deployed Engineer）として複数の企業に入り込み、人事部門と財務部門の業務AIエージェントを設計から本番運用まで担当してきました。会議室で要件を聞いて作るのではなく、現場の担当者の隣に座り、実際の業務の流れを観察しながら作る、という進め方です。
先日、エンタープライズ財務へのAI導入について書かれた記事（Varick Agents 創業者による投稿）を読み、その骨格には現場の実感としてほぼ同意しました。一方で、1点だけ明確に異なる意見を持っています。本記事では、私が実際に構築・運用してきた2つの業務AIエージェントを題材に、「何が機能し、何が機能しないか」を現場の一次経験から書きます。
要点は3つです。
- 業務AIエージェントの中身は、AI 2割・決定論的なコード 8割がちょうどいい。 間違えられない業務の判定は決定論で行い、AIは「AIにしかできない箇所」に限定する。
- 汎用AIアシスタントの全社配布だけでは、業務は自動化されない。 各社固有のフローを載せる部分に、結局エンジニアリングの労力がかかる。
- ただし「すべてバックグラウンドで自動実行」には反対。 現場の協力を得るには、AIの動作が見える UI と、人間の判断の余地を残した「共存の仕組み」が必要である。
エンタープライズAIの失敗率は高い
冒頭の記事が引用している統計は、私の現場感覚とも一致します。
冒頭の記事が引用する統計（Gartner・MIT NANDA）
（導入済み・導入予定は84%）
生成AIパイロット
エージェント型AIプロジェクト
導入率と成果のギャップがこれほど大きい理由を、私は「技術の問題ではなく、設計思想の問題」だと考えています。以下、実例で説明します。
汎用アシスタントの限界 — Claude Cowork を触ってみて
失敗パターンの1つ目は、Microsoft Copilot や Claude Cowork のような汎用AIアシスタントを全社配布すれば業務が自動化される、という期待です。
私も Claude Cowork を実際に試しました。第一印象として、どの業務にも共通するインタフェース（ファイル操作、資料作成、調査など）は非常によくできています。しかし、実際の業務に使おうとすると、各社固有の業務フロー・独自ルール・例外処理を、プロンプトやスキルファイルとして書き起こして渡す作業が必要になり、ここに相当の労力がかかります。これは業務とAIの両方を理解した人間が行う必要のある作業で、現場の担当者が片手間にできるものではありません。
| 汎用アシスタントが得意なこと | そのままでは難しいこと |
|---|---|
| ファイル操作・資料作成・調査など、どの業務にも共通する作業 | 各社固有の業務フロー・独自ルール・例外処理の反映 |
| 1人の作業を速くすること | 業務プロセスそのものの自動化 |
| 対話しながらの試行錯誤 | 監査に耐える判断根拠・操作履歴の追跡 |
これは私の一次的な感触ですが、公開情報とも整合します。Anthropic 自身が、Cowork の組織展開を「一度きりの導入ではなく、スキル整備・パイロット・段階展開を含む継続的なプログラム」と位置づけています。つまり、汎用アシスタントは「1人の作業を速くする道具」としては優秀でも、「業務プロセスそのものを自動化する仕組み」としてはそのままでは機能しない、というのが私の結論です。
また、監査対応が必須の財務業務では、AIの判断根拠と操作履歴を後から追跡できることが必須要件になりますが、汎用アシスタントはこの点でもまだ発展途上です。
実例1: 人事 — 勤怠チェックエージェント
ある企業の人事部門では、毎月初に約300名分の勤怠記録を人手でチェックしていました。打刻漏れ、乗務・勤務時間の不整合、承認状態の確認など、確認項目は30種類近くあり、担当者が数日かけて目視で行う業務です。
ここに構築したエージェントの設計は明確です。
- 判定の中核は 100% 決定論的なコード。 約30種類のチェックルールをすべて Python のルールエンジンとして実装し、同じ入力からは必ず同じ結果が出るようにしました。就業規則や労働基準法に根拠を持つルールばかりで、「なぜNGなのか」を全件、理由付きで説明できます。
- LLM は補助に限定。 チェック結果全体の総括レポートや担当者向けのアドバイスの文章生成、勤務名称の表記揺れの吸収といった、言葉の解釈・要約が必要な箇所にだけ使っています。
実はこのシステム、初期のプロトタイプでは LLM に勤怠データを直接判定させていました。しかし実測した結果は次の通りで、判定は決定論に置き換えました。
| 判定方式 | 処理時間（1人あたり） | 精度 | 特性 |
|---|---|---|---|
| ルールエンジン（決定論） | 約2秒 | 仕様通り 100% | 同じ入力なら必ず同じ結果。全件に理由を提示できる |
| LLM 直接判定（初期プロトタイプ） | 約18秒 | 約75% | 役職による除外や休日の扱いなど、細かい条件を安定して守れない |
「AIを使わない」という判断を、AIを実際に動かして計測した上で下したわけです。
業務効率化の効果は、導入前に工数ベースで試算しています。この確認作業は二重チェックを含めて複数名がかりで行われており、部門全体では毎月延べ100時間を超える工数がかかっていました。全体の約9割を占める修正不要なデータをエージェントが自動判別し、担当者は要修正箇所の確認だけに注力する運用に変えることで、作業時間は約50%削減できる試算です。
実例2: 財務 — 支払伝票の突合チェックエージェント
ある組織の財務部門では、会計システムに登録された支払伝票を承認する前に、添付された請求書や社内の申請情報と食い違いがないかを人手で突合していました。
ここでAIが本当に必要だったのは、たった1箇所です。様式がばらばらな請求書 — 写真で撮られたものも含む — から金額や取引先を読み取る部分。これは従来、人の目視でしかできなかった作業で、Vision 系の LLM が初めて可能にした領域です。
それ以外はすべて決定論にしました。
- 検算（小計＋税＝合計）、源泉徴収税の計算、マスタとの照合、日付や口座の正規化と比較 — すべて Python のコード。
- 読み取りが難しい書類を上位モデルに回すか、というエスカレーション判断すら決定論のルールで行い、AIには判断させません。
- 決定論の照合で不一致が残った場合のみ、LLM に「この2つの名称は同一の相手か」といった同一性判定をさせます。ただし LLM が返せるのは「同一（OK）」か「不確実（人へ）」だけで、NG の最終確定は絶対にAIにさせない設計です。
処理の流れを図にすると、AIが関与する箇所が2箇所に限定されていることが分かります。
flowchart TD
A["支払伝票 + 添付書類"] --> B["AI: Vision 読取<br/>様式不定の請求書から金額・取引先を抽出"]
B --> C["決定論: Python コード<br/>検算・源泉税計算・マスタ照合・日付/口座の正規化比較"]
C -->|"すべて一致"| D["OK として整理"]
C -->|"不一致が残る"| E["AI: 同一性判定<br/>この2つの名称は同一の相手か"]
E -->|"同一と判断"| D
E -->|"不確実"| F["人へエスカレーション<br/>判断材料を添えて最終確認"]
style B fill:#e0e7ff,stroke:#4f46e5
style E fill:#e0e7ff,stroke:#4f46e5
style C fill:#d1fae5,stroke:#059669
style F fill:#fef3c7,stroke:#b45309効率化の規模も試算しています。この帳票確認は月に数百件規模で発生し、部門全体で毎月数十時間の工数を要していました。修正不要な帳票をエージェントが自動判別することで、こちらも作業時間を約50%削減できる試算です。
コストの実測も共有します。AIの従量課金は請求書1枚あたり約1円。月あたりのAI費用は数百円のレベルで、システム全体のコストの95%以上はサーバの固定費でした。「AIエージェントはトークン費用が高い」というイメージは、決定論主体で設計すれば当てはまりません。
興味深いのは時間とコードの比率です。実行時間の9割以上は AI の画像読取が占める一方、判断ロジックのコード量は決定論が圧倒的多数を占めます。時間はAIが支配し、判断は決定論が支配する。 業務AIエージェントの現実は、この構図です。
設計原則: 決定論 → LLM → 人、の3段構え
2つのプロジェクトに共通する設計原則を一般化すると、こうなります。
flowchart TD
A["業務データ"] --> B["第1段: 決定論で解く<br/>計算・照合・ルーティング・ルール判定"]
B -->|"確定できる"| O1["自動で判定確定<br/>速い・安い・監査可能"]
B -->|"解釈が必要"| C["第2段: LLM に渡す<br/>様式不定の読取・表記揺れの同定・要約"]
C -->|"確信を持てる"| O2["結果を整理して提示"]
C -->|"不確実"| D["第3段: 人に渡す<br/>判断材料を揃えてエスカレーション"]
style B fill:#d1fae5,stroke:#059669
style C fill:#e0e7ff,stroke:#4f46e5
style D fill:#fef3c7,stroke:#b45309- まず決定論で解く。 計算、照合、ルーティング、ルール判定 — 業務の大半はここに入ります。速く、安く、監査可能で、同じ入力なら必ず同じ結果が出ます。
- 決定論で解けない「解釈」だけ LLM に渡す。 様式不定の書類の読取、表記揺れの同定、結果の要約。ここは LLM にしかできません。
- それでも不確実なものは人に渡す。 AIに無理に決めさせず、判断材料を揃えた上で人間にエスカレーションします。
体感的な比率で言えば、AI 2割・決定論 8割。そして間違いが許されない判定の中核に限れば、決定論 10割です。
冒頭の記事は「良いAIエージェントは、ほとんどAIではない（85%がコード、15%がモデル呼び出し）」と書いていますが、日本の現場で私が実装してきた比率もほぼ同じでした。
記事への異論: 「完全バックグラウンド」はやめたほうがいい
冒頭の記事と意見が分かれるのはここです。記事は「誰にもプロンプトされず、バックグラウンドで勝手に仕事が終わっているエージェント」を理想像として描いています。技術的にはその通り作れますし、効率だけを見ればそれが最適でしょう。
しかし、FDE として現場に入って痛感したのは、現場の担当者は自分の仕事がAIにすべて置き換わることを恐れているという事実です。完全自動化・完全バックグラウンドの「万能の仕組み」を作ろうとした瞬間、現場の協力は得られなくなります。そして現場の協力なしに、実際の業務フロー — SOP には書かれていない例外処理や暗黙の運用 — を仕組みに反映することはできません。業務AIエージェントの成否は、この現場知の取り込みで決まります。
だから私は、両プロジェクトとも意図的に「共存の仕組み」として設計しました。
| 共存の仕組み | 具体的な設計 |
|---|---|
| AIが何をしたかが見える UI | 判定結果を一覧で確認でき、1件ごとに「どのルールで、なぜこの判定になったか」「AIがどの書類から何を読み取ったか」を突き合わせて見られる |
| 実行のトリガーと最終判断は人間に残す | チェックの実行は担当者が対象を選んで指示し、結果の最終確認・承認は必ず人間が行う。エージェントは「確認済み」の記録は取るが、承認ボタンそのものは持たない |
| 人間の修正がシステムを育てる | 担当者の確認・修正の結果がルールの改善に反映され、精度が運用の中で上がっていく |
この設計にしてから、現場からは「仕事を奪われる」ではなく「面倒な部分が先に片付いている」という受け止めに変わりました。導入の技術的難易度よりも、この心理的な受容の設計のほうが、実は難しく、そして重要です。
FDE として学んだこと
最後に、現場に入り込む働き方そのものについて。冒頭の記事にも「文書化された SOP は現実をほとんど反映していない」とありますが、これは日本の現場でも全く同じでした。マニュアル上は一本道のプロセスが、実際には「この場合は担当者が直接メールする」「金額が小さければ別の処理に回す」といった例外の束でできています。
これを知る方法は1つしかありません。担当者の隣に座り、実際の操作を見せてもらうことです。要件定義書からは決して出てこない情報が、30分の観察から山ほど出てきます。私が構築した約30種類の勤怠チェックルールの多くは、リリース後に現場からの指摘を受けて追加・修正されたものです。業務AIエージェントは一度作って終わりではなく、現場と対話しながら育てるものだと考えています。
まとめ
- 業務AIエージェントの中身は、AI 2割・決定論 8割。間違えられない判定は決定論で行い、AIは「AIにしかできない解釈」に限定する。
- 汎用アシスタントの配布だけでは業務は自動化されない。各社固有のフローを仕組みに落とすエンジニアリングが本体である。
- 完全バックグラウンドの全自動は目指さない。AIの動作が見え、人間の判断が残る「共存の仕組み」が、現場の協力と現場知を引き出し、結果として精度と定着を生む。
AIエージェントという言葉は華やかですが、その実体は、現場の業務を正確に理解した上で組み上げる、地道なエンジニアリングです。そしてそれこそが、95% が失敗すると言われる領域で成果を出すための、私が知る唯一の方法です。
この記事についてのLinkedIn投稿でコメントや意見を共有できます。
LinkedInで議論する
