B2B調達エージェントとは、購買要求の受付からPO（発注書）発行までの一連の業務を、AIエージェントが自律的に判断・実行する仕組みである。 本記事はタイ製造業の調達担当者・情報システム責任者に向けて、RFQ生成・サプライヤー選定・見積比較・PO発行までを自律実行する設計手順を解説する。最終的に「人間は例外承認だけ行えばよい」状態を目指し、調達リードタイム短縮とバイヤー工数削減を両立させる。

B2B調達エージェントは「RPA + チャットボット」の発展形ではない。複数のツール（ERP・サプライヤーAPI・メールクライアント）を自律的に呼び分け、見積取得→比較→承認依頼→PO発行までを目標達成型で完遂する。ここでは従来の調達業務との違いと、タイ製造業ならではの要件を整理する。

従来の調達業務はワークフロー型である。バイヤーがRFQ作成→3社見積依頼→Excelで比較表作成→上司承認→ERPでPO発行、という固定手順を人間が回す。RPAは「Excelの転記」レベルの自動化に留まり、見積依頼文面のサプライヤー個別チューニングや、欠品時の代替部品検討といった判断は人間が引き取っていた。

AIエージェントは目標達成型である。「型番X-201を2000個、納期4週間以内、予算50万バーツ以内」というゴールを与えると、過去の取引データから候補サプライヤー上位3社を選び、メール文面をそれぞれの言語・取引慣行に合わせて生成し、回答を解析して比較表を作る。例外（予算超過・納期不適合・新規サプライヤー）のみ人間にエスカレートする設計が可能になる。

タイ製造業の調達自動化には、日本本社にはない3つの要件がある。

1. 多通貨対応: 部品は中国（CNY）、原材料はオーストラリア（AUD）、現地サプライヤー（THB）、本社経由の特殊部品（JPY）が混在する。為替レートを取得して比較可能な単位に正規化する仕組みが必須になる。
2. 多言語サプライヤー対応: タイ語・英語・中国語・日本語のメールが混在する。サプライヤー側の使用言語に合わせた見積依頼を生成し、返信を構造化データに変換する処理が要る。
3. AEO・通関要件の自動チェック: タイのAuthorized Economic Operator制度では、輸入部品のHSコード・原産地・関税分類を購買時点で記録する必要がある。発注前にこれらの項目が揃っているか自動検証する仕組みを組み込む。

EEC（東部経済回廊）の進展で、タイ製造業は調達リードタイム短縮と多通貨対応の両立を迫られている。一方、調達経験のあるバイヤーの採用は難しく、既存人員での対応を余儀なくされている。AIエージェントによる自動化は、この需給ギャップを埋める現実的な選択肢として位置づけられる。

タイ製造業では、部品調達リードタイムが製品出荷リードタイムを決定する。日系自動車部品メーカーや電子機器メーカーはジャストインタイム生産を維持するため、サプライヤーへの見積依頼から発注確定までを数日以内に完了させる必要がある。

人手依存の調達では、バイヤー1人あたり同時並行で扱えるRFQは20件程度が現実的な上限とされる。緊急案件や複雑部品が重なるとここがボトルネックになり、製造ラインの停止リスクが高まる。エージェント化により、定型RFQはバイヤーの介入なしで完結し、バイヤーは交渉や新規ソーシングといった高付加価値業務に集中できる。

タイ製造業の調達先は地理的に分散している。中国深圳の電子部品サプライヤー、マレーシアの樹脂メーカー、日本本社経由の特殊部品、タイ現地の汎用部材。それぞれ通貨・言語・取引慣行が異なる。

人手では、見積比較時に為替レート換算を都度行い、サプライヤーごとに使い分けるメールテンプレートを管理し、納期表記（"Within 4 weeks" "30営業日" "4週間以内"）を統一する作業が発生する。エージェントは為替APIから当日レートを取得し、見積金額をベース通貨（THBまたはUSD）に正規化し、納期を「カレンダー日数」に統一して比較表を生成できる。手作業ではどうしても揺らぐ「比較条件の統一」を機械的に担保できる点が、エージェント化の大きな価値である。

調達エージェントの導入は、いきなりエージェント実装から始めない。 基幹システムとの連携設計とサプライヤーマスタの整備が、プロジェクト全体の成否を左右する。ここでは前提となる準備項目を整理する。

調達エージェントは単独で動かない。既存のERP（SAP、Oracle、Microsoft Dynamics、現地ERP）や購買管理システム（Coupa、Ariba、自社開発システム）と双方向で連携する必要がある。

最低限必要な連携は3つに分類できる。

ERP側のAPI整備が不十分な場合は、読み取り専用レプリカや中間DBを経由する設計を検討する。エージェントが直接ERPの書き込みAPIを叩くと、誤発注時のロールバックが難しくなる。PO発行は「下書き作成 → 人間最終承認 → ERP書き込み」の3段階に分け、書き込み権限はラスト1ステップだけに絞るのが安全である。

エージェントの判断品質は、入力データの品質に直接依存する。導入前に以下を整備する。

• サプライヤーマスタ: 取引履歴、得意分野、対応通貨・言語、リードタイム実績、品質スコア
• 部品カタログ: 型番、代替部品、HSコード、原産地、最終購入価格、推奨サプライヤー
• 過去取引データ: 直近2〜3年のPO履歴。価格交渉履歴は特に重要

これらのデータが揃わない状態でエージェントを動かすと、「過去に取引のない新規サプライヤーを選んでしまう」「代替部品を提案できない」といった失敗が起きる。データ整備は調達部門と情報システム部門の合同プロジェクトとして、エージェント実装より前に着手するのが望ましい。

ここからは具体的な実装手順を3ステップで解説する。リファレンス実装では、調達リクエストの構造化から始め、サプライヤー選定エージェントを設計し、最後に見積比較とPO発行を自動化する。各ステップで「どこまでエージェントに任せ、どこから人間が関わるか」を明確にする。

購買要求（PR: Purchase Request）が「Excelに自由記述」「メール本文に箇条書き」といった非構造化データで届くと、エージェントは処理できない。最初のステップは、PRを構造化スキーマに正規化することである。

最低限必要な項目は次のとおり。

非構造PRはLLMで構造化する。タイ語・英語・日本語の混在文をLLMに渡し、上記スキーマでパースさせる。パース失敗時（必須項目が抜けている、数値が不明瞭）は人間にエスカレートし、回答後にスキーマへ反映する流れを組む。

構造化された調達リクエストを受けて、候補サプライヤーを選定するエージェントを設計する。選定ロジックは「過去取引履歴 + 部品カタログの推奨 + 制約条件」の組み合わせで決める。

Tools the agent can call:
  - search_suppliers(item_code, quantity, currency, delivery_date) → 候補リスト
  - get_supplier_history(supplier_id, item_code) → 過去取引実績
  - get_supplier_capacity(supplier_id, delivery_date) → 納期適合性
  - calculate_score(supplier_id) → 総合スコア

エージェントは目標（例: 「予算と納期を満たす上位3社を選定」）を受け取り、上記ツールを必要な順で呼び出して候補リストを返す。プロンプトには「過去2年で品質トラブルがあったサプライヤーは候補に含めない」「単一サプライヤー依存を避けるため異なる地域から最低1社を含める」といった調達ポリシーを記述する。

新規サプライヤーをエージェントが自律的に追加することは禁止する。新規追加は調達部門の責任者が承認するフローとし、エージェントは候補提案のみを行う。

選定された候補サプライヤーに見積依頼を送信し、回答を収集して比較表を作る。最後にPO発行を行う。

「発注決定」のHITL基準は明文化しておく。例として「100万バーツ未満かつ既存サプライヤー上位3社なら自動承認、それ以外は人間承認」のような閾値で運用する。基準を曖昧にすると、エージェントが境界事例で停止し、運用負荷が下がらない。

本番運用に乗せた後、よく発生する失敗パターンが2つある。HITL設計の不備と、監査ログの不足である。どちらもPoC段階では見えにくく、運用開始後に問題化しやすい。

HITLの設計でよくある失敗は、「全件人間承認にしてしまい自動化の意味がなくなる」と「自動化しすぎて誤発注を検知できない」の両極である。

設計の指針は「金額・サプライヤー実績・例外フラグの組み合わせで分岐する」こと。例えば次のような閾値設定が現実的である。

• 50万バーツ未満 + 既存サプライヤー + 予算内 → 自動承認
• 50万〜200万バーツ → 課長承認（Slack通知 + ボタンクリックで承認）
• 200万バーツ以上、または新規サプライヤー、または予算超過 → 部長承認
• 緊急時（製造ライン停止リスク）の特例承認パス → 別ルート

エスカレーション通知は、承認者の業務リズムに合わせて設計する。製造業の管理職は会議が多くメール返信が遅れがちなので、Slack・LINE・Microsoft Teamsへの通知に加え、未承認のまま一定時間（例: 6時間）経過した案件は次の承認者に自動転送する仕組みを入れると、リードタイムが安定する。

タイのAuthorized Economic Operator制度では、輸入関連の取引履歴を一定期間保管し、税関の調査に応じて提示する義務がある。AEO認定企業（または認定を目指す企業）が調達エージェントを導入する場合、以下のログを構造化された形で保管する必要がある。

加えて、サプライヤーの担当者情報・取引履歴を扱う場合はタイPDPA（個人情報保護法）の対象となる。データ最小化（不要な個人情報をエージェントに渡さない）と、保管期限後の自動削除を設計に組み込む。

調達エージェントのROIは「コスト削減」だけで測ると過小評価される。次の3軸で測定するのが現実的である。

導入初期はバイヤー工数削減が見えやすい指標になる。半年〜1年で「機会損失抑制」（緊急対応のリードタイム短縮、欠品リスクの低下）の効果が顕在化する。「ガバナンス工数の削減」は最も遅れて表れる効果で、監査周期に合わせて測ることになる。

KPIは経営層が経営報告で扱える単位（年間コスト削減額、調達リードタイム平均など）に集約しておくと、追加投資の判断がしやすい。

B2B調達エージェントは「全自動の魔法」ではなく、人間が例外対応に集中するための仕組みである。タイ製造業がこの仕組みを導入するには、ERP連携設計・サプライヤーマスタ整備・HITL閾値の明文化・AEO/PDPA対応の監査ログ設計を、エージェント実装前に固める必要がある。

最初の一歩としては、調達カテゴリを1つ（例: 汎用消耗品、特定部品ファミリー）に絞り、3〜6ヶ月のPoCで「バイヤー工数」「リードタイム」「例外発生率」を測定するのが現実的である。PoCで指標が改善した段階で、他カテゴリへ展開する形が、運用リスクを抑えながら効果を積み上げられる。

調達自動化は単発のIT投資ではなく、調達戦略の再設計を伴う取り組みである。情報システム部門だけで進めず、調達部門・経営層を巻き込んだ体制で進めることが成功の前提となる。