AIエージェントの標準アーキテクチャ

01全社構成：エージェントの役割と共通基盤

購買、契約、営業、経理でエージェントを個別に作ると、同じ情報を別々に保存したり、同じ処理を二重に実行したりするおそれがあります。最初に誰が何を担当し、どのデータを正本とし、どの条件で次へ渡すかを設計します。

図1　全社のエージェント構成と共通基盤図を拡大 ↗

業務の境界と、引継ぎ条件を決める

エージェントは部門名だけで分けず、扱う情報、必要な権限、成果物、責任者が異なるかを見て分けます。例えば、購買は見積比較と発注案、契約は条項の確認、経理は請求照合を担当します。定型の計算や登録は通常のプログラムで処理し、すべてをAIエージェントにする必要はありません。

業務ワークフロー／オーケストレーションが処理順序と分岐を管理します。引継ぎには案件ID、入力・出力のデータ形式、根拠資料、完了条件、承認状態を定義します。失敗時の再試行、担当者への差戻し、停止する範囲も決めます。全社を一つの上位AIで動かす構成は必須ではなく、業務ごとに必要な連携を実装します。

共通基盤と、業務ごとの管理範囲を分ける

台帳には、担当業務、責任者、接続先、権限、利用中のモデル・Skillsの版、連携先を登録します。基盤の運用担当と、業務上の判断をする責任者を分け、複数部門にまたがる変更の承認者も決めておきます。

日々の改善を、必要な範囲に反映する

担当者の修正や実行ログから改善候補を作り、業務固有のSkillsと全社共通のルールを分けて更新します。共通部品を変える場合は、利用する各業務の評価ケースで影響を確認してから配布します。一部門の修正で、別部門の承認条件や参照権限まで変更しないようにします。

確認・差戻しの件数と誤りを測り、品質が基準を満たす処理から人の確認範囲を見直します。確認を減らすかどうかは業務責任者が判断し、必要な承認は残します。

02個別構成：AIエージェントと業務システム

担当者が依頼を入力すると、AIエージェントが業務システムからデータを取得し、文書を読み、処理を進めます。発注や契約送信など、承認が必要な操作の前で処理を止め、担当者に内容を確認してもらいます。

受注、在庫、会計、契約の正本は、既存システムで管理します。AIが在庫数や契約状態を確認するときは、そのシステムの最新データを取得します。

図2　AIエージェントの実行フローと継続改善サイクル図を拡大 ↗

AIエージェントの4つの処理

この処理は、LLMとランタイム（実行基盤）で動かします。LLMは文章の解釈や作業案の作成を担い、ランタイムが順序、状態保存、承認待ち、再試行、停止を管理します。必要量の計算や発注可否の判定など、決まったルールで処理できる部分はプログラムに持たせます。

初期構成では、業務の大枠をワークフローで固定し、文書の読み取りや比較などにAIを使います。処理を独立させる必要が出た段階で、複数エージェントへの分割を検討します。単純な構成から始める設計については、Anthropicの設計ガイドが参考になります。

Md・Skills・ナレッジ・DB・MCPの役割

Agent Skillsの仕様では、SKILL.mdを中心に、実行コード、参照資料、テンプレートなどをまとめられます。Skillsにはテスト用の業務例も添え、手順を変更した際に同じ入力で結果を確認できるようにします。変更履歴はGitで管理します。出典：Agent Skills仕様

担当者の修正を、次回の処理に反映する

例えば、担当者が「最安値でも納期を満たさない見積は選べない」と修正したら、その理由を記録します。比較手順に納期チェックを加え、過去の案件で期待どおりに動くかを確かめてから反映します。文書更新は検索用データへ、手順の修正はSkillsへ、承認条件の変更は設定と実行コードへ、それぞれ反映します。

この運用で更新するのは、参照文書、手順、設定です。LLMの再学習とは別の作業です。変更後の誤りや差戻しを記録し、担当者の確認を減らしてよい処理かどうかを判断します。

03詳細：各機能に使う技術と実装方法

画面にはReact、業務APIにはFastAPI、処理の順序と中断・再開にはLangGraphを使う構成例です。画面、実行制御、データ保存、外部接続を分けておくと、モデルや接続先を変更する際の修正範囲を限定できます。

図3　概要図に対応した技術スタックの実装例図を拡大 ↗

各技術の公式資料：React、FastAPI、Pydantic、LangGraphの永続化、Claudeのtool use、pgvector、OpenTelemetry、pytest、Docker。組み合わせ方と実装範囲は、本記事の構成例です。

複数エージェントの連携を実装する

全社構成図の業務ワークフローと、個別エージェント内部の実行制御は、管理する範囲が異なります。業務間では案件IDと構造化した結果を渡し、各エージェントは自分のタスク計画と実行状態を管理します。小規模な構成では同じアプリケーション内に実装しても構いません。

この実装例では、Pydanticで引継ぎデータを検証し、PostgreSQLで案件と処理状態を関連付けます。別ワーカーへの依頼にはジョブキュー等を使い、操作IDで重複を防止します。共通のトレースIDで処理を追跡し、連携先にも依頼者と許可された操作範囲を伝え、受信側で権限を検証します。エージェント台帳は、最初はGitの設定ファイルやDBの管理表から始められます。

承認待ちの状態を保存し、後から再開する

承認が翌日になる仕事では、ブラウザやAPIの接続を維持し続ける設計は適しません。APIは案件IDを返し、ワーカーが処理を進めます。承認待ちになったら状態をDBに保存し、担当者の操作を受けて再開します。LangGraphのチェックポイントとinterruptは、この中断・再開に利用できます。実行待ちジョブの管理や業務上の承認権限は、アプリケーション側でも実装します。出典：LangGraph Interrupts

承認後の変更と二重発注を防ぐ

発注ツールを実行する直前に、入力形式、利用者とエージェントの権限、仕入先、数量、金額、承認対象の版をチェックします。承認後に宛先や金額が変わった場合は、元の承認を流用せず再承認に戻します。

操作ごとのIDと外部システムの受付結果も保存します。タイムアウトで送信済みか不明なときは、受付状態を照合してから再試行します。外部APIに重複防止機能がない場合は、照合または手動確認を挟みます。この照合処理は、チェックポイントの保存とは別に実装します。

接続権限・操作権限・承認を分けて管理する

MCPを採用する場合も、接続先の認証・認可と、業務上の承認は別に扱います。参照できる文書と実行できる操作は、依頼したユーザーに許可された範囲に制限します。MCPには認可仕様とセキュリティの実装指針があり、それらに加えて業務単位の制御が必要です。MCP Authorization／Security Best Practices

初期導入では、顧客ごとに実行環境・データ・資格情報を分けます。検索対象にも文書のアクセス権を適用し、取り込んだメールや文書の中の指示をシステム指示として扱わないようにします。監査には実行者・承認者・対象・結果を残し、分析用トレースでは秘密情報や不要な本文を記録しない設定にします。

04食品メーカーの例：小麦粉の調達と契約

小麦粉を使う食品メーカーで、購買担当者が「来月分の小麦粉を、在庫を見て手配して」と依頼する場面を考えます。製品名を固定せず、既存の生産・在庫・購買管理、文書管理、メール、電子契約の各システムにつなぎます。以下は架空の適用例です。

図4　食品メーカーの原料調達・契約に適用した構成例図を拡大 ↗

購買・契約・経理のエージェントを連携させる

上の構成を複数の担当業務に分ける場合、購買は数量と見積、契約は条項と差分、経理は発注・入荷・請求の照合を受け持ちます。各業務の成果物を、共通の案件IDで関連付けます。

図5　食品メーカーの部門をまたぐ業務フロー図を拡大 ↗

契約確認には仕入先、数量、価格、納期、契約案の版と見積の根拠を渡します。不備があれば購買へ差し戻し、条件が変われば再確認・再承認します。契約締結が発注の前提となる取引では、締結完了を待ってから発注します。経理では発注番号・入荷記録・請求書を照合し、不一致は担当者へ返します。支払の確定は別途承認を受けます。

小麦粉を10t調達する場合の処理

1. 必要量を計算する。仮に来月の使用予定が12t、安全在庫が2t、使用可能在庫が3t、必要納期までに届く確定発注残が1tなら、追加調達量は10tです。単位・基準日・既発注分をそろえ、プログラムで計算します。数量や品目が不明なら推測せず確認します。

   12t ＋ 2t − 3t − 1t ＝ 10t

2. 見積と規格書を照合する。メール・文書管理から候補を集め、単価、納期、原料規格、必要書類を同じ項目で比較します。認定仕入先かどうかは購買管理の情報で確認します。
3. 比較表・契約案・発注案を作る。採用候補の根拠と未確認事項を示します。既存契約との差分を抽出し、契約の新規締結・改定が必要な場合に契約案を作成します。
4. 人の承認後に、確定操作を行う。購買責任者が発注先・数量・金額を、必要に応じて品質担当者や法務担当者が条件を確認します。契約締結が発注の前提なら、締結完了を待って発注します。承認の順序と実行条件は業務ルールに合わせます。

担当者は、比較表、契約差分、発注案を、参照した資料と一緒に確認できます。送信後は発注番号、契約ID、未完了の処理を確認できます。納期や書類の不備で差し戻された理由は評価ケースに追加し、次回の検索・比較手順の改善に使います。

05導入：全体設計と共通部品・個別設定

状態保存、承認、システム接続、監査ログ、評価は、複数の案件で使える部品として用意します。顧客ごとに変更する業務ルールや帳票は、コード本体と分けて管理します。

全体設計を行い、最初に導入する業務を選ぶ

最初に、対象部門の業務フロー、既存システム、データの正本、権限、管理責任者を一覧にします。エージェントごとの担当範囲と引継ぎ条件を決め、共通基盤と個別設定を分けます。そのうえで、効果を測定でき、データと承認者がそろう一業務を選びます。将来の構成に含めたエージェントを、すべて同時に実装する必要はありません。

初回導入で共通のID、データ形式、監査・評価の方式を確かめ、次の業務へ広げます。追加時には、既存の権限、連携先、共通Skillsへの影響を評価します。

導入前に整備する標準モジュール

既存コネクタで接続できないシステムには、追加の接続処理が必要です。読み取れない文書の整備、独自帳票の作成、複雑な承認経路への対応も、個別に工数を見積もります。提案時には設定で対応する範囲と、追加開発する範囲を分けます。

業務設定をファイルで管理する

設定をコード本体から分離しておけば、基盤を顧客ごとに作り直す作業を減らせます。以下は概念例であり、稼働する製品の設定仕様ではありません。APIキーやトークンは設定ファイルに直書きせず、秘密情報管理サービスから参照します。

workflow: raw_material_procurement
skills:
  - quote_comparison@1.0
  - contract_diff@1.0
connectors:
  purchasing: customer_purchasing_api
  documents: customer_document_api
approvals:
  send_purchase_order: purchasing_manager
  send_contract: contract_approver
evaluation_set: procurement_acceptance_v1

Skills、承認条件、接続先、評価セットを一緒に記録することで、同じ条件で再検証できます。顧客のデータや固有ルールは顧客専用の管理範囲に置き、別の顧客へ再利用するのは共通化できるコード・手順・匿名化した評価パターンに限定します。

06導入スケジュール：8週間の計画例

この計画の前に、対象部門間の役割分担、データの正本、権限と承認、共通基盤、初回の対象業務を合意します。全体設計に必要な期間は部門数や既存環境で変わるため、以下の8週間とは別に見積もります。

全体設計後、1業務・既存システム2〜3接続を8週間で導入する計画例です。標準モジュールが利用でき、API利用許可、サンプルデータ、承認者、検証環境が揃っている場合を想定しています。顧客の業務責任者には週次の確認に参加してもらいます。期間は実績の平均ではなく、対象範囲と準備状況に応じて調整する目安です。

図6　標準モジュールを使う8週間の導入計画例図を拡大 ↗

本番移行前に確認すること

受入評価には、正しく処理できた割合だけでなく、誤った確定操作、根拠資料の欠落、人の確認・修正時間、一件当たり費用、処理時間を含めます。例えば「承認なしの送信が起きない」「権限外の文書が出力されない」「再実行で発注が重複しない」は必須の確認項目です。LLMによる自動採点は補助に使い、数値照合はコード、業務上の妥当性は担当者の評価と組み合わせます。参考：Anthropicのエージェント評価ガイド

予定どおりに基準を満たさなければ、対象の原料や処理範囲を縮めるか、修正して再評価します。APIが未提供、マスタが未整備、契約ひな形や承認規程が未確定の場合は、追加の準備期間を見込みます。前述の食品メーカー例は4種類のシステムを扱うため、初期は参照と下書きに必要な2〜3接続に絞ります。電子契約などの追加接続は、範囲と工数を確認して計画に加えます。

運用後の手順変更と承認の見直し

運用開始後も、修正・差戻し・障害を定期的に振り返ります。業務Skillsを変更したら、固定した評価セットと新しい例外ケースの両方で比較します。問題があれば前の版へ戻せるようにしておきます。

自動処理に切り替える候補は、条件が明確で、誤りがあっても影響の小さい操作です。業務責任者が変更を承認した後に、システムの承認条件を変更します。契約締結や高額発注の承認要否は、社内規程に従います。