はじめに
エンタープライズ領域における生成AI導入の現場では、いまだに「巨額のPoCを回したが本番化できない」「全社配布したが現場で定着しない」という課題が頻発しています。
私はこの1年あまり、FDE（Forward Deployed Engineer：顧客の現場に密着して実装を主導するエンジニア）として複数の企業に入り込み、人事部門や財務部門の業務AIエージェントを設計から本番運用まで担当してきました。
会議室のヒアリングだけで設計するのではなく、現場担当者の隣に座って画面操作を観察し、泥臭く運用に乗せていく中で得た結論は以下の3点です。
- エージェントの中身は「AI 2割・決定論的コード 8割」が最も機能する
- 汎用AIアシスタントの全社配布だけでは業務プロセスは自動化されない
- 「完全バックグラウンド自動化」は目指さず、人間の判断余地を残す「共存UI」を組む
本稿では、実例を元に、業務エージェントが現場で本当に動くためのアーキテクチャと組織設計を整理します。
1. 汎用AIアシスタントの限界：なぜ全社配布で失敗するのか
失敗パターンの典型が、汎用的なAIアシスタントツールを全社ライセンスで配布し、「現場で自由にプロンプトを書いて業務を自動化してください」と丸投げするケースです。
ファイル操作や要約、調査などの共通UIとしては優秀ですが、実際の業務プロセスそのものを代替しようとすると以下の壁に直面します。
| 比較項目 | 汎用AIアシスタントが得意なこと | 業務プロセス自動化に求められること |
|---|---|---|
| 対象スコープ | 個人のデスクトップ作業の高速化（1人の作業短縮） | 組織間の業務プロセス全体の自動化・省力化 |
| 業務ロジック | 共通的なファイル操作・要約・ブレスト | 各社固有の就業規則、例外規定、暗黙の運用ルール |
| 監査性 | 出力結果の対話的な試行錯誤（過程はブラックボックス） | 判定根拠の100%の追跡可能性、ログの永続化（監査耐性） |
各社固有の複雑なフローや例外処理をプロンプトだけで制御するのは困難です。結局、業務と技術の境界を理解したエンジニアが「システムとして組み上げる」必要があります。
2. 実例1：人事部門 — 勤怠チェックエージェント
毎月初に約300名分の勤怠記録（打刻漏れ、運行・勤務時間の不整合、承認漏れなど約30種類の確認項目）を目視でチェックしていた現場の事例です。
「AIに判断させない」という技術判断
初期プロトタイプでは、LLMに勤怠データを直接読ませて違反を判定させていました。しかし、実機で計測した結果を受けて方針を180度転換しました。
| 判定方式 | 1人あたりの処理時間 | 判定精度 | 特性と運用上の課題 |
|---|---|---|---|
| ルールエンジン（決定論） | 約2秒 | 100%（仕様通り） | 入力が同一なら結果は常に一致。全件理由を明示可能 |
| LLM直接判定（初期PoC） | 約18秒 | 約75% | 役職による例外や振替休日の扱いなど、複雑な条件を守れない |
労働基準法や社内規程に基づくチェックは、「なぜNGなのか」を労働者や監査に対して100%説明できなければなりません。
そのため、30種類のルールはすべてPythonの決定論的なコード（ルールエンジン）として実装し、判定の中核からはAIを完全に排除しました。AIは、例外申請などの自由記述コメントから文脈を抽出する補助のみに限定しています。
- 成果: 全体の約9割を占める「正常データ」をエージェントが瞬時にスクリーニングし、担当者は要修正箇所の確認のみに集中。部門全体で毎月延べ100時間超かかっていた確認工数を約50%削減しました。
3. 実例2：財務部門 — 支払伝票の突合チェックエージェント
会計システムに登録された支払伝票と、添付された請求書（スキャンPDFや写真）を突合する業務です。
AIの出番は「たった1箇所」に絞る
ここでLLM（Vision）が真に必要なのは、「フォーマットがバラバラな請求書画像から、取引先名や金額を構造化データとして読み取る部分」 だけです。
- 検算（小計＋税＝合計）や源泉税の計算: 100% Pythonコードで実行（AIに計算させない）。
- 同一性判定の制約: 表記揺れ（「（株）鈴木」と「株式会社 鈴木商店」など）の照合のみLLMに任せますが、LLMが返せる選択肢は「同一」か「不確実（人へ）」のみ。NGの最終確定は絶対にAIにさせない設計にしています。
コストの実態
- 請求書1枚あたりのAI従量課金：約1円
- 月間のAI従量課金総額：数百円レベル
- システム全体の費用の95%以上はコンテナ等の固定インフラ費
「AIエージェントを動かすとAPI代が跳ね上がる」というのは、文字生成や不要な推論をループさせた場合の現象です。決定論主体で組めば、コストの大半はAIではなく通常のWebシステムと同じ構造になります。
4. 設計原則：決定論 → LLM → 人の3段構え
2つのプロジェクトから導き出した、現場で破綻しないエージェントアーキテクチャの基本形です。
-
第1段（決定論で解く）:
ルールの適用、数値計算、マスタ照合。業務の大半（8割）はここで完結します。高速、低コスト、かつ同じ入力なら必ず同じ結果が出るため監査に耐えられます。 -
第2段（LLMに渡す）:
第1段で処理しきれない非構造データの解釈（文字認識、表記揺れ、要約）のみを処理します。 -
第3段（人間に渡す）:
少しでも不確実性が残るものは、AIに無理に結論を出させず、判断材料（抽出データと根拠）を画面上に揃えた上で担当者にエスカレーションします。
システム全体で見れば、「AI 2割・決定論 8割」。そして「間違いが許されない判定の中核に限れば、決定論10割」です。
5. 実装の要：完全バックグラウンドの自動化を避ける理由
エンジニアは往々にして「裏側で完全に自律実行され、人間が何もしなくてもタスクが終わっている状態」を理想としがちです。しかし、現場導入においてそれは逆効果になります。
現場の協力なしに暗黙知は拾えない
現場の担当者は「自分の仕事をAIに奪われるのではないか」という不安を抱えています。完全な自動化を強行しようとすると、現場からの心理的抵抗が生じ、協力が得られなくなります。
そして最大の問題は、現場の協力がなければ、業務マニュアル（SOP）に書かれていない暗黙の例外ルールを収集できない点にあります。
マニュアルに書かれている手順は、現実の業務の半分程度に過ぎません。「この取引先は請求書のフォーマットが特殊」「この役職の人は別フローで処理する」といった生きた情報は、現場担当者の隣に座り、信頼関係を築いて初めて聞き出せます。
「共存」を前提にしたUI設計
現場の協力を得てシステムを定着させるために、以下の3点を徹底しました。
-
根拠が見えるUI:
判定一覧画面で、「どのルールに基づき、なぜこの判定になったのか」「AIが帳票のどこを読んで抽出したのか」を突合して確認できるようにする。 -
承認権限は人間に残す:
エージェントは「確認完了」のステータスをつけるだけで、最終承認ボタンは持たせない。 -
修正がルールを育てる仕組み:
人間が画面上で修正した内容をフィードバックとして蓄積し、決定論ルールのチューニングに活かす。
この設計にしたことで、現場からは「仕事を奪う敵」ではなく、「月末の面倒な下準備をあらかじめ終わらせておいてくれる優秀な助手」として受け入れられるようになりました。
現場に入り込むエンジニアリングこそが本体
AIエージェントの成否を分けるのは、最新のフロンティアモデルを使うことでも、複雑な自律エージェントフレームワークを採用することでもありません。
- 守るべきビジネスルールを決定論的なコードに落とし込めるか
- AIの出番を「解釈」に限定し、ハルシネーションを構造的に防げるか
- 現場の担当者と対話し、画面の向こう側の泥臭い例外を拾い上げられるか
業務AIエージェントという言葉は華やかですが、その実体はきわめて泥臭く堅実なソフトウェアエンジニアリングです。AIブームの熱狂が落ち着き、実利（ROI）が問われる今だからこそ、「AI 2割・決定論 8割」の地に足の着いた設計思想が求められていると感じています。
著者について / お問い合わせ
鈴木商店（Suzuki Shokten）
AI & Software Engineer / FDE (Forward Deployed Engineer)
「PoCは作ったが本番運用に乗らない」「現場の業務フローが複雑でAIが定着しない」「トークン費用が膨らんでROIが合わない」といった、業務AIエージェントの設計・開発でお困りの企業様向けに、現場密着型のエンジニアリング支援（FDE）を行っています。
業務の自動化やAIアーキテクチャの設計に関するご相談、AI開発のご依頼などはお気軽にご連絡ください。
- ポートフォリオ / 実績・研究ログ: suzuki-shoten.dev
- LinkedIn: Suzuki
- X: @matu79go