デモにおけるAIエージェントの処理プロセスと機能詳解：設計・調達エージェントの制御フローと実装デザイン

電子部品の自動調達デモ「Agent Parts Hub」を題材に、設計エージェント（MCP）と調達エージェント（REST）が実行する全34回のツール呼び出しや制御フロー、判断ロジックを専門家向けに詳細に解説した技術解説資料です。
緩和ラダーによる部品選定、是正ポリシーに基づくBOM解析、2段階の見積・発注と冪等性の確保、さらにLLMエージェントへの移行に向けた決定論的ポリシーとガードレールの設計手法を体系的に網羅しています。

Transcript

1. デモにおける AIエージェントの 処理プロセスと機能 詳解 設計エージェント（MCP）／調達エージェント（REST）の制御フロー・ツール呼び出し・判断ロジッ ク・ガードレール 対象：ソフトウェア／インフラ／調達DXの専門家 対象コード：agent-ec-proto v0.1.0
2. サマリー：2つのエージェント、34回のツール呼び出し、人の介入1回 数値はデモ1回分（build=200、データ初期状態）の監査ログから集計 27 7 0.42 ms 1回 MCP tools/call REST 呼び出し MCP 平均処理時間 人の操作 設計エージェント 調達エージェント サーバ内処理（監査ミドルウェア計 承認上限超過の注文を list_categories 1 / search_parts 13 / get_part 13 bom/analyze 2 / quotes 1 / orders 3 / watchlists 1 測） コンソールで承認 REST 平均 4.71 ms このデモのエージェントは「LLMの推論部分を決定論的ポリシーに置き換えた参照実装」です。 • ツール呼び出しの順序・引数・判断分岐は、LLMエージェントが行うべき処理をコードで固定したもの（再現性のある評価ベースライ ン） • サーバ（Agent Parts Hub）側の機能は本番相当：パラメトリック検索、互換判定、BOM解析、見積、冪等発注、承認、監査 • 本書では「実際に何が呼ばれ、何を根拠に判断したか」をトレースとコードで示し、LLM化する場合の置換点も明示する Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） 2
3. 全体シーケンス 左から右へ時間が進みます。設計エージェントはMCP、調達エージェントはREST、人はコンソールを使用 人（購買責任者） 設計エージェント 承認 → confirmed お題・要求仕様 initialize / tools/lis list_categories Agent Parts Hub 調達エージェント search_parts ×1 get_part ×13 BOM CS (17行) MCP: 検索・詳細（27回） REST: 解析・見積・発注 bom/analyze × 是正 quotes → order (冪等・409) watchlists ※ 横位置は相対的な順序。設計エージェントの成果物（BOM CSV）が調達エージェントの入力になる（ファイル受け渡し） t 3 s 2 V Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） 3
4. エージェントの構成要素と実装の対応 一般的なエージェント・アーキテクチャの要素に、デモのコードを対応づけたもの 要素 役割 設計エージェント 調達エージェント 目標・入力 何を達成するか REQUIREMENTS（13要求）＋LEGACY（4行） BOM CSV ＋ build=200 計画（Plan） 手順の決定 要求ごとに 厳格→緩和 の条件ラダーを順に試す 解析→是正→再検証→見積→発注→監視 の固定パイプライン 行動（Tools） 外部への作用 MCP: list_categories / search_parts / get_part REST: /bom/analyze /quotes /orders /watchlists 観測（Observe） 結果の取り込み structuredContent（JSON） JSON ＋ RFC 9457 problem+json 判断（Policy） 分岐の基準 最初にヒットした最安・在庫充足品／RoHS確認 フラグ別の是正テーブル（後述） 記憶（Memory） 状態の保持 agents/out/design_bom.csv procurement_report.json / final_bom.csv ガードレール 逸脱の防止 スコープ：閲覧＋BOM解析のみ（発注ツール不可視） 承認上限 ¥100,000、冪等キー、スコープ Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） 4
5. 設計エージェントの制御ループ 設計 agents/design_agent.py の run() を擬似コード化したもの design_agent.py（要約） mcp = Mcp("demo-design-key") list cats = mcp.call("list_categories") # initialize → initialized → tools/ # 属性辞書（単位・role）を取得 for ref, qty, cat, ladder, memo in REQUIREMENTS: need = qty * build # 例: R1-R8 → 8×200 = 1,600 for level, params in enumerate(ladder): continue d = mcp.call("get_part", mpn=chosen["mpn"]) if not d["compliance"]["rohs"]: warn(...) # 適合性確認 bom.append(ref, chosen.mpn, qty, memo + 緩和段数) # 旧製品からの流用4行（検査は調達側） write_csv("agents/out/design_bom.csv", bom) min_available=必要数 でフィルタし、指定数量 の価格ブレーク単価で昇順。先頭を採用。 # 厳格 → 緩和 r = mcp.call("search_parts", category=cat, params=params, min_available=need, qty=need, sort="price", limit=3) if r["items"]: chosen = r["items"][0]; break else: bom.append(未選定) # 人の判断へエスカレーション bom += LEGACY 選定基準は「在庫制約つき最小価格」 緩和ラダーで探索を制御 条件を一段ずつ外して再検索。どの段で決まっ たかをBOMの備考に残し、後で人が評価できる ようにする。 LLM化するなら 要求文→REQUIREMENTS の生成と、緩和の 順序づけをLLMに任せ、検索・価格計算はツー ルに残すのが定石。 Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） 5
6. 要求仕様の表現：制約の「緩和ラダー」 設計 1要求＝カテゴリ＋条件リスト。条件はSI表記の文字列のまま渡し、サーバ側で正規化する Ref 員数 カテゴリ Level 0（厳格） Level 1 Level 2 U1 1 mcu core=Cortex-M33, flash≥256k, ram≥64k flash≥256k, ram≥64k — U3 1 ldo vout=3.3, iout≥0.3, vin_max≥6, iq≤60u iq 条件を除外 — U4 1 opamp channels=2, gbw≥10M, io_type=RRIO RRIO を除外 — R1-R8 8 resistor 10k, package=0603, tolerance≤1 package=0402 tolerance≤5 R9-R10 2 resistor 4.7k, package=0603 パッケージ不問 3.3k〜5.6k, 0603 C1-C12 12 mlcc 100n, ≥16V, X7R, 0402 パッケージ不問 100n, ≥10V J1 1 connector type=usb_c_receptacle — — search_parts の引数（R1-R8, Level 0） {"category":"resistor","params":{"resistance":{"eq":"10k"}, "package":{"eq":"0603"},"tolerance":{"max":1}}, "min_available":1600,"qty":1600,"sort":"price","limit":3} Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） 今回の実行では全13要求が Level 0 で確定 在庫・価格は架空データの乱数に依存。データを変える と緩和が発生する。 6
7. MCPセッションとツール呼び出し（実データ） 設計 プロトタイプは MCP 2025-06-18 の初期化手順に準拠した最小実装（JSON-RPC 2.0 / Streamable HTTP の POST） JSON-RPC の往復（要約） // structuredContent.items[0]（U1） → {"method":"initialize","params":{...}} ← {"protocolVersion":"2025-06-18", "capabilities":{"tools":{"listChanged":false}}, "serverInfo":{"name":"agent-parts-hub",...}, "instructions":"list_categories → search_parts → ..."} + ヘッダ Mcp-Session-Id {"mpn":"TEMCCO25664-P4", "manufacturer":"Tsubame Electronics", "lifecycle":"ACTIVE", "available":5359, "unit_price":163.85, "lead_time_weeks":8} // applied_filters（正規化後） {"flash":{"min":256000.0},"ram":{"min":64000.0}} → {"method":"notifications/initialized"} ← 202 → {"method":"tools/list"} ← tools: list_categories, search_parts, get_part, find_alternates, check_inventory, analyze_bom, get_lifecycle_notices (7件／スコープで絞込) → {"method":"tools/call","params":{"name":"search_parts", "arguments":{"category":"mcu",...}}} ← {"content":[{"type":"text","text":"{...}"}], "structuredContent":{"total":7,"items":[...]}, "isError":false} 専門家向けの注意点（既知の課題） • "256k" は SI の k（×1000）で解釈される。flash は 262,144 （KiB）で保存しているため結果は正しいが、2進接頭辞（Ki/ Mi）の明示が望ましい • tools/call 以外（initialize・tools/list）は監査ログ対象外 • place_order の annotations が idempotentHint=true・ destructiveHint=false 固定。書き込み系は見直しが必要 Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） 7
8. 設計エージェントの実トレース（search_parts 13回） 設計 監査ログ（audit テーブル）から抽出。ms はサーバ内処理時間。各検索の直後に get_part を1回呼ぶ # category 主な条件（Level 0） 採用MPN 単価¥ 在庫 ms 1 mcu Cortex-M33, flash≥256k, ram≥64k TEMCCO25664-P4 163.85 5,563 3.5 2 buck vin_max≥17, iout≥1, vref=0.8 OPBK2723-D8 89.75 799 0.3 3 ldo 3.3V, iout≥0.3, vin_max≥6, iq≤60µ KSLD200033-R8 27.92 1,513 0.4 4 opamp 2ch, GBW≥10M, RRIO MMOA8228-B2 47.89 3,867 0.3 5 inductor 4.7µH, Isat≥1.5A OPPL4472-R7 21.11 3,367 0.2 6 schottky Vr≥30, If≥1, Vf≤0.5 OPSD4274-H6 6.50 575 0.3 7 mosfet N, Vds≥30, Id≥4, Rds≤30m OPMF868-M7 13.42 3,456 0.3 8 resistor 10k, 0603, ±1% HPRC0603F103-F2 1.30 5,918 0.4 9 resistor 4.7k, 0603 NFRC0603F472-L5 1.40 13,412 0.4 10 mlcc 100n, ≥16V, X7R, 0402 HPCC0402X7104-B2 8.50 12,765 0.5 11 mlcc 10µ, ≥10V, 0805 HPCC0805X7106-H7 1.66 6,881 0.5 12 crystal 16MHz, ±20ppm SCXT7500-C2 37.60 5,551 0.5 13 connector USB-C receptacle NFCN2414-A8 19.76 5,318 0.3 初回の3.5 msはキャッシュ未作成（在庫集計）のため。以降は TTL 30秒のキャッシュが効く。※ 架空データ Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） 8
9. 調達エージェントの処理パイプライン 調達 agents/procurement_agent.py の run()。各段の出力が次段の入力になる直列パイプライン 1. Load 2. Analyze 3. Remediate 4. Re-verify 5. Quote BOM CS 17行 POS bom/analyze 是正テーブル 適用 POS bom/analyze POS /quotes 6. Order 7. Retry 8. Conflict 9. Watch POST /order Idem-Key 同一Keyで 別Keyで 再送 再発注→409 POS watchlists 段 実際の結果（デモ1回分） Analyze 17行中14行OK。要対応: U5(EOL), Q2(EOL), U6(NOT_FOUND)。準備率 82.4% / リスクスコア 22.6 Re-verify 準備率 100% / リスクスコア 5.9 Quote / Order ¥246,212（税込）→ status=pending_approval（上限 ¥100,000 超過）。再送は同一 order_id、別Keyは 409 s V T T T T Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） 9
10. 是正ポリシー（判断テーブル） 調達 analyze_bom の status / flags と suggested_alternates だけで分岐する。人の確認が必要な補正は備考で明示 条件（解析結果） アクション 根拠となるデータ デモでの適用 status=not_found かつ did_you_mean あり 先頭候補に置換（要設計者確認） difflib による類似度≥0.8 の型番 U6: MMOA524O-P9 → MMOA5240-P9 status=not_found かつ候補なし 行を除外し設計へ差し戻し — なし 最上位の drop_in に置換 互換判定 key/ge/le とスコア U5→MMLD015025-C3, Q2→KSMF2856D4 status=risk かつ条件を満たす候補なし 据え置き（バックオーダー許容） lead_time_weeks なし flags に NRND（status=ok） 今回は購入、監視登録 PCN/EOL 通知 D2: OPSD5158-B8 その他フラグ（SINGLE_SOURCE 等） 情報として保持（是正しない） flags U1: EXPORT_CONTROLLED ほか status=risk（EOL/LTB/STOCK_SHORT）かつ drop_in 候補の在庫≥必要数 設計上のポイント 置換を「是正テーブル」という明示的なポリシーにしておくと、LLMに判断させる場合でも出力をこの表で検証（ガード）できる。 Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） 10
11. BOM解析（analyze_bom）の内部ロジック サーバ サーバ側 services.Store.analyze_bom。エージェントは結果を解釈するだけで計算はしない analyze_bom（要約） 指標 是正前 是正後 need = ceil(qty_per_board × build × (1 + attrition/100)) # 例: R1-R8 = ceil(8 × 200 × 1.02) = 1,632 準備率 82.4% 100% flags: lifecycle ∈ {NRND, LTB, EOL} → そのまま付与 リスクスコア 22.6 5.9 available < need かつ lead_time ≥ 12週 → STOCK_SHORT → LONG_LEAD 要対応行 3 0 source = broker_verified eccn ≠ EAR99 drop_in 候補なし → NON_FRANCHISED_SOURCE → EXPORT_CONTROLLED → SINGLE_SOURCE status = risk if {EOL, LTB, STOCK_SHORT} ∩ flags else ok line_risk = min(100, LC_RISK[lifecycle] + 40·STOCK_SHORT + 10·SINGLE_SOURCE) LC_RISK = NEW 5, ACTIVE 0, NRND 40, LTB 70, EOL 100 not_found = 100 risk_score = mean(line_risk) readiness_% = ok行数 / 全行数 × 100 Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） なぜサーバ側で計算するか • 計算・規則は決定論的にサーバで一元化し、エージェン ト（将来はLLM）に数値計算をさせない • REST と MCP の両方から同じ結果になる • 解析結果に代替候補を同梱し、往復回数（ツール呼び出 し数）を減らす 11
12. 代替候補の判定とスコアリング サーバ find_alternates／analyze_bom 内部で共通。key=一致、ge=同等以上、le=同等以下 を満たすと drop_in 互換判定（要約） conditional は自動置換しない for c in same_category(target): if c.lifecycle in {EOL, LTB}: continue if any(key 属性が不一致): continue 劣る属性がある候補（例：Vds 20V < 30V）は差分を列挙 して返すだけ。調達エージェントの是正テーブルは dev = ge 属性で下回る ∪ le 属性で上回る drop_in のみを採用するため、設計レビューが必要な置換 imp = ge 属性で上回る ∪ le 属性で下回る は自動で起きない。 match = drop_in if not dev else conditional score = 100 − 15·|dev| + 2·|imp| − 0.3·LC_RISK + (10 if 在庫≥必要数 else −20) − min(10, 3·価格比) + (3 if 別メーカー) 候補（Q2: TEMF8073-F4, EOL, 必要204） 判定 改善点 在庫 スコア KSMF2856-D4 drop_in Id 20→30A, Rds 8.8→7.5mΩ 2,095 112.8 KSMF3281-H9 drop_in Rds 8.8→8.1mΩ 393 112.6 OPMF152-L5 drop_in Id 20→30A, Rds 8.8→7.5mΩ 1,342 112.3 Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） 12
13. 見積（create_quote）のアルゴリズム サーバ 数量の丸め → 倉庫引当 → 価格ブレーク → 送料・税 → 24時間有効の見積として永続化 create_quote（要約） 項目 デモの値 倉庫優先順 = JP向け: 東京→大阪→シンガポール 小計 ¥223,828.80 # 集約出荷：1倉庫で全数を満たせるならそこだけ 送料 ¥0（¥10,000以上） 消費税 ¥22,383 合計 ¥246,211.80（表示 ¥246,212） order_qty = max(moq, qty) を order_multiple に切り上げ single = first(w for w in 優先順 if 在庫[w] ≥ 残数) for w in ([single] if single else 優先順): take = min(残数, 在庫[w]); 割当; 残数 −= take 残数 > 0 → バックオーダー（EOLでリードタイム無しなら409） unit = 価格ブレーク(order_qty) # 1/10/100/1000/5000 東京DC 13行 / 大阪DC 3行 / シンガポールHUB 1 出荷 行 shipping = 0 if subtotal ≥ ¥10,000 else ¥800 × 出荷数 tax = round((subtotal + shipping) × 0.10) valid_until = now + 24h 価格・在庫は見積時点で確定 検索結果（as_of）は参考値。発注直前に create_quote を取り直すよう llms.txt と instructions で指示してい る。 Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） 13
14. 発注（place_order）の安全機構 サーバ 冪等性・二重発注防止・承認上限・在庫引当を1トランザクションで処理 place_order / decide_order（要約） 呼び出し 結果 with lock: if (agent, Idempotency-Key) が既存 → 同じ Order を返す IdempotencyKey 1回目 uuid-A 200: SO-xxxx（pending_approval） 再送（通信断想定） uuid-A 同じ SO-xxxx を返す 別Keyで同じ見積 uuid-B 409 Quote already ordered Key なし — 400 Idempotency-Key required quote 期限切れ → 409 "Quote expired" hint:再見積 同一 quote に有効な注文あり → 409 "Quote already ordered" for 割当 in quote: 在庫(qty−reserved) を再確認 不足 → rollback, 409 "Stock changed" reserved += 割当数 # 引当 status = pending_approval if total > approval_limit else confirmed INSERT orders (UNIQUE(agent, idem_key)) decide_order(approve): # 人（admin スコープ） approve → confirmed reject → rejected ＋ 引当解除（reserved −= 割当） 承認上限は「主体」に紐づく API キー（主体）ごとに approval_limit を持つ。調達エー ジェントは ¥100,000、設計エージェントは発注スコープ 自体を持たない。 Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） 14
15. ガードレール：権限・可視性・エラー設計 エージェントが「できること」と「見えること」をサーバ側で制限する 主体（APIキー） スコープ tools/list に見えるツール 承認上限 design-agent catalog:read, bom:analyze 7（create_quote・place_order は不可視） — procurement-agent ＋quote:write, order:write, lifecycle:watch 9 ¥100,000 purchasing-manager *（承認を含む全権） 9 上限なし スコープ外の呼び出し（実応答） HTTP/1.1 403 application/problem+json {"title":"Insufficient scope", "status":403, "detail":"'design-agent' に 'quote:write' • せよ」の hin • • 人の承認フローを利用してください"} t 未知の属性・演算子・値は 400 と有効値一覧の hint を返し、エー ジェントの自己修正を促す • Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） MCP のツールエラーは isError=true＋structuredContent に problem 本文（JSON-RPC エラーにしない） 権限がありません", "hint":"調達エージェント用キー、または レート制限：キー単位 300回/分。429＋Retry-After＋「キャッシュ llms.txt と initialize の instructions で推奨手順を自己記述 15
16. 観測性：監査ログとコンソール 全 REST（/v1/*）と MCP tools/call を、主体・経路・操作・結果・処理時間で記録 主体 経路 操作 回数 design-agent MCP tools/call:list_categories 1 design-agent MCP tools/call:search_parts 13 design-agent MCP tools/call:get_part 13 procurement-agent REST POST /v1/bom/analyze 2 procurement-agent REST POST /v1/quotes 1 procurement-agent REST POST /v1/orders procurement-agent REST POST /v1/lifecycle/watchlists 3（200, 200, 409） 1 MCP 平均 0.42 ms／REST 平均 4.71 ms（サーバ内処理、ネットワ ーク除く） 本番では OpenTelemetry のトレースIDをエージェントのステップと相関させ、「どの推論がどの呼び出しを生んだか」を追跡可能にする。 Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） 16
17. LLMエージェントへの置き換え：何をLLMに、何をツールに残すか 確率的な判断と決定論的な計算を分離するのが基本方針 処理 デモの実装 LLM化した場合 ツール／サーバに残すもの 要求の抽出 REQUIREMENTS を手書き 回路仕様・自然文→条件リストを生成 属性辞書（list_categories）で検証 緩和の判断 固定ラダー 設計意図に沿って緩和順を決める 緩和段数をBOMに記録 候補の選択 最安・在庫充足の先頭 複数候補から理由付きで選択 価格・在庫・互換判定の計算 是正 是正テーブル 例外時に説明文を生成・人に相談 是正テーブルで出力を検証 発注 固定パイプライン 見積比較・分納判断 冪等・承認上限・引当 ReAct ループへの対応 ツール結果は「データ」として扱う Thought（緩和するか）→ Action（search_parts）→ カタログの説明文などツール結果に含まれる文字列を指示として 解釈しない（プロンプトインジェクション対策）。 Observation（structuredContent）を繰り返す。デモはこのルー プの軌跡を固定したもの。 Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） 17
18. 既知の制約と次の一手 プロトタイプから本番相当へ進めるための技術課題 領域 現状（v0.1.0） MCP 仕様 2025-06-18 の initialize／Mcp-Session-Id 方式 認可 固定APIキー＋スコープ OAuth 2.1。MCP 認可仕様（RFC 9207 の iss 検証、CIMD）に準拠 エージェント間連携 CSV ファイル受け渡し A2A 等のエージェント間プロトコルでタスクとして受け渡し 決済 月次一括請求のみ AP2 等の署名付きマンデートで「誰が何を承認したか」を否認不能に 単位 k=1000 固定 Ki/Mi（2進接頭辞）と UCUM 等の単位コード ツール注釈 書き込み系も idempotentHint=true place_order は destructive・非冪等扱い＋Key 必須を明記 次の一手 2026-07-28 仕様（ステートレス化：_meta での版・能力通知、Mcp-Method／Mcp-Name ヘッダ、tools/list の ttlMs）へ移行 MCP 2026-07-28 の変更点は公式ブログ（blog.modelcontextprotocol.io, 2026-07-28）による。 Agent Parts Hub ｜ エージェント処理プロセス詳解（専門家向け） 18