課題
ERPパッケージで基幹システムを構築・運用されているお客様から、2つのご相談をいただきました。
- 照会のたびに、画面と項目名を覚えなければならない。受注・売上・在庫・予算を見るのに、メニューをたどり、検索条件の項目名を知っている必要がある。標準にない集計が欲しくなるたび、帳票を1本追加開発していた
- ワークフロー承認で、添付PDFと申請内容を目視で突合していた。見積番号、金額、数量——承認者が1項目ずつ目で追う。人によって見る深さが違い、転記ミスが後工程で発覚することもあった
ユースケース① ― 対話形式によるデータ抽出・参照
「今月の受注一覧を見せて」「大阪営業所の当初予算と最新見通しの差異は？」「この結果をExcelで出力して」。日本語のまま聞くと、エージェントが自分で適切な検索ツールを選び、ERPのREST APIを呼び、表にして返します。画面遷移も、項目名の知識も要りません。
- 販売管理（見積／受注／出荷／売上）、購買管理（発注／入荷／仕入）、在庫管理、販売購買に対応
- 会計側も、予算・見通し・業績管理まで同じ画面から照会できます
- 結果はExcel／CSVで出力。件数の多いデータは、画面ではなくファイルで受け取れます
- ERP側の権限をそのまま尊重します。指示した方が参照権を持たないデータは、出力対象になりません
ユースケース② ― ワークフロー承認チェック
承認ノードに到達した時点でエージェントが起動し、添付PDF（正本）とシステム上の伝票を、会社ごとに定義されたルールで項目単位に照合します。一致か、不整合か。不整合なら、どの項目のどの値が違うのかを明示して承認者に返します。
AIは、チェック結果を返すだけです。承認・差戻しの判断は、これまで通り承認者が行います。AIが自動で承認することはありません。
「安心して使える」ための、3つの設計
この案件でいちばん時間をかけたのは、機能ではなくここでした。
| 論点 | やったこと | なぜ |
|---|---|---|
| AIに件数を作らせない | ERPから取得した行は、AIに渡す前にシステム側で表に整形。AIにはその表を逐語でコピーさせるよう、プロンプトで強制しています | 「該当は42件です」とAIが数え間違える、あるいは作文することを、構造的に防ぐため |
| 個人情報は項目単位でマスク | 管理者が指定した列だけを、セル単位で復元可能なトークンに置き換え。AIはマスク済みの表しか見ません。表示の直前に復元します | 文脈からの推測に頼らず、どの列を守るかを人が決められるようにするため |
| 会社ごとに完全分離 | 会社ごとのERP接続先とトークンを保持し、すべての検索に会社の識別子を付与。承認チェック用のエージェントは、使えるツールを限定して通常のツール群から分離しています | 1つの基盤を複数社で使っても、データも判断ルールも混ざらないようにするため |
加えて、エージェントは読み取り専用です。ERPのデータを更新することはありません。取得したデータをAI側のデータベースに書き込むこともしません。
規模と構成
| 機能数 | 34機能（システム管理・テナント管理・エンドユーザーの3ロール） | |
| 画面数 | 34画面 | |
| ERP連携ツール | 13種（伝票検索8・財務検索3・突合1・帳票出力1） | |
| 管理API | 40以上 | |
| 技術構成 | FastAPI（非同期）／ OpenAI Agents SDK ／ React・TypeScript・Vite ／ PostgreSQL（pgvector）／ AWS S3・Lambda ／ Terraform | |
| 成果物 | 設計書 全21章（アーキテクチャ・データモデル・権限マトリクス・個人情報マスキング設計・エラーコード一覧・ライセンス一覧・ユースケース別フローチャート） | |
その後 ― 音声入力のご提案
運用が見えてきた段階で、「毎回プロンプトを手で打つのが負担」という声をいただきました。そこで、日本語に特化した音声認識モデルをローカルに載せる構成をご提案しています。
- 既存サーバに同居させます。新規GPUの追加は不要です（INT8で1〜2GBのVRAM、CPUのみでも4〜8コアで動作します）
- 短い指示なら1〜3秒でテキスト化。話してすぐ、レポートの実行へ進めます
- 音声も社外に出しません。音声認識APIの従量課金も発生しません
- 業務用語の誤認識は、社内用語の辞書とLLMによる正規化の2層で吸収します
