設計エージェントが仕様から部品を選び、調達エージェントが見積・発注するところまで

資料の構成

背景：顧客接点の変化、流通の付加価値の移り変わり
方針：対象ユーザー、6つの設計原則
4層アーキテクチャと、互換判定のルールを持たせた属性辞書
APIとMCPツールの一覧
デモ結果と運用画面のスクリーンショット
品質保証と管理の仕組み
3段階の移行計画、3か月のPoC計画
本開発に進むかどうかの判断基準
本番化で置き換えるもの

1. AIエージェント専用 電子部品E 開発方針とプロトタイプ 人が巡回するECから、設計・調達AIエージェントがAPI/MCPで照会・取引するプラットフォームへ プロトタイプ「Agent Parts Hub」（1,000品目） C 2026年11月
2. エグゼクティブサマリー 競争軸は「画面での集客」から「機械が正確に理解できるデータ」と「実効的な取引機能」へ移る 1,000 9 4層 3か月 品目・12カテゴリ（架空） MCPツール（RESTも同等） データ〜チャネルの基盤 閲覧系PoC → 本開発判断 顧客はAIエージェントになる 設計AIは仕様から部品を選び、調達AIはBOMを検証して見積・発注する。人は監視と承認に回る。 データを「機械可読」に作り直す 型番を主キーに、SI単位で正規化した属性と互換ロール（key/ge/le）を持たせ、代替判定を自動化する。 閲覧系から段階的に移行する Phase1 閲覧API/MCP → Phase2 キャッシュ・BOM解析 → Phase3 発注・決済連携。PoCのKPIで本開発を判断。 Agent Parts Hub ｜ 開発方針 2
3. 顧客接点の変化：人のサイト巡回からAIのAPI照会へ 同じ「部品を探して買う」行為でも、相手が機械になると求められるものが根本から変わる 従来：人がWebサイトを巡回 これから：AIがAPIで照会 • 検索窓・カテゴリ画面で候補を絞り込む • 仕様（数値条件）でパラメトリック照会 • データシートPDFを人が読んで比較 • 正規化された属性を機械が直接比較 • 在庫・価格は画面で目視確認 • 在庫・価格をリアルタイムに一括照会 • 代替品探しは経験と手作業 • 互換ルールで代替品を自動判定 • UI・SEO・広告で集客し囲い込む • データ品質と取引機能で選ばれる Agent Parts Hub ｜ 開発方針 3
4. 流通の付加価値は「掲載」から「取引の実効性」へ 検索・掲載はAIが代替できる。代替できないのは品質保証・物流・決済・ライフサイクル管理 真贋確認・品質保証 PCN / EOL 管理 正規流通経路、CoC、ブローカー品の検査成績をデ BOM型番を監視登録し、変更通知・LTBを機械通知 ータで提示 一括請求 集約物流 エージェント発注を月次で集約し、購買部門の処理 を削減 倉庫引当を最適化し、出荷回数と送料を抑える 代替提案 コンプライアンス Form/Fit/Function互換を根拠付きで返し、設計レビ RoHS・REACH・ECCN・原産国を属性として保持 ューを短縮 Agent Parts Hub ｜ 開発方針 4
5. 対象ユーザー：2種のAIエージェントと、承認する人 プロトタイプでは3つの主体ごとにAPIキーと権限（スコープ）を分けた 設計AIエージェント 調達AIエージェント 購買責任者（人） 閲覧・BOM解析 ＋見積・発注（上限¥100,000） 承認・監視 demo-design-key demo-procurement-key demo-admin-key • 回路要求を数値条件に変換 • BOMを解析しリスクを検出 • コンソールでトラフィックを監視 • search_parts で在庫品から選定 • EOL品をdrop-in互換品に置換 • 上限超過の注文を承認／却下 • 条件を段階的に緩和して再検索 • 見積→冪等キー付きで発注 • エージェント視点のJSONを確認 • BOM（型番×員数）を出力 • PCN/EOL監視を登録 • 例外（型番不明など）を判断 Agent Parts Hub ｜ 開発方針 5
6. 開発方針：6つの設計原則 「人が見やすい」ではなく「機械が誤解しない・安全に取引できる」を基準に判断する 01 02 03 型番（MPN）起点 SI正規化＋互換ロール 次の行動を示すエラー BOMの主キーは型番。不明型番は表記揺 値は基本SI単位。属性ごとに key/ge/le を RFC 9457形式。hint に「次に呼ぶべきツ れ候補（did_you_mean）を返す 定義し代替判定を機械化 ール」を書く 04 05 06 安全な書き込み 1ロジック・複数チャネル すべてを記録・可視化 Idempotency-Key必須。承認上限を超え REST・MCPは同じサービス層を呼ぶ。 全呼び出しを監査ログ化し、人はコンソ たら人の承認待ち スキーマはPydanticで一元管理 ールで監視する Agent Parts Hub ｜ 開発方針 6
7. 4層構造のAPI基盤 下位層ほど資産として長く使い、上位層ほど入れ替えやすくする L4 チャネル層 プロトタイプの技術選定 REST（OpenAPI）｜ MCP（HTTP/stdio）｜ llms.txt ｜ 運用コンソール L3 取引層 見積・集約出荷 ｜ 発注（冪等・承認上限）｜ 一括請求 ｜ EOL監視 L2 サービス層 パラメトリック検索 ｜ 代替品（FFF互換）｜ BOM解析 ｜ キャッシュ • FastAPI（REST/OpenAPI） • Pydantic v2（共通スキーマ） • MCP：JSON-RPC 2. • SQLite（カタログ・取引） • デモエージェント×2 L1 データ層 PIM型カタログ（SI単位・属性辞書）｜ 倉庫別在庫 ｜ 変更通知 ｜ 監査ログ MCPはSDKの改版に左右されないよう、initialize / tools/list / tools/call を直接実装。ツールの入力スキーマはPydanticから自動生成し、RESTと定義を 共有する。 0 Agent Parts Hub ｜ 開発方針 7
8. データモデル：PIM／JEP30を参考にした属性辞書 属性に「単位」と「互換判定上の役割」を持たせることで、代替品選定を機械が根拠付きで行える カテゴリ key（一致必須） ge（同等以上） le（同等以下） チップ抵抗 resistance, package power tolerance, tempco MLCC capacitance, dielectric, package voltage tolerance LDO vout, package iout, vin_max dropout, iq MOSFET channel, package vds, id rds_on マイコン core, pins, package flash, ram, freq — drop-in 判定ルール key属性がすべて一致 ＋ ge属性は同等以上 ＋ le属性は同等以下 → Form/Fit/Function 互換。 劣る属性がある候補は conditional（要設計レビュー）として差分を列挙する。 Agent Parts Hub ｜ 開発方針 8
9. APIとMCPツール：同じ機能を2つの入口で提供 エージェントは tools/list で自分の権限内のツールだけを発見する MCPツール REST エンドポイント 用途 スコープ Phase list_categories GET /v1/categories 属性辞書（単位・役割）の取得 catalog:read 1 search_parts POST /v1/parts/search パラメトリック検索（SI表記可） catalog:read 1 get_part GET /v1/parts/{mpn} 詳細・価格表・倉庫別在庫・トレーサビリティ catalog:read 1 check_inventory POST /v1/inventory 最大50型番の在庫一括照会 catalog:read 1 find_alternates GET /v1/parts/{mpn}/alternates FFF互換の代替候補と差分 catalog:read 2 analyze_bom POST /v1/bom/analyze コスト・在庫充足・EOL・単一ソース bom:analyze 2 get_lifecycle_notices GET /v1/lifecycle/notices PCN / EOL / LTB 通知 catalog:read 2 create_quote POST /v1/quotes 価格ブレーク・倉庫引当・集約出荷 quote:write 3 place_order POST /v1/orders 冪等キー付き発注・承認フロー order:write 3 自己記述：/openapi.json ・ /llms.txt ・ /.well-known/agent-card.json ／ 認証：X-API-Key（本番は OAuth 2.1 client credentials） Agent Parts Hub ｜ 開発方針 9
10. デモシナリオ：仕様から発注まで、人の操作は承認1回 IoTセンサーノード基板 × 200台。設計エージェントはMCP、調達エージェントはRESTを使用 1. 仕様→選定 2. BOM解析 3. 是正 4. 見積 5. 発注 6. 人が承認 13行を選定 17行中3行が EOL品を 条件緩和も 要対応 互換品へ置換 ¥246,21 （税込） 上限超過で 承認待ち コンソールで 承認 自動で実施 EOL2・型番1 型番を補正 3倉庫集約 二重発注なし EOL監視登録 82%→100% 22.6→5.9 約4 ms 10 / 10 BOM準備率（是正前→後） リスクスコア（0〜100） 検索・詳細照会の応答（手元計測） 自動テスト合格 2 Agent Parts Hub ｜ 開発方針 10
11. 人の役割は「見る・承認する」：運用コンソール エージェントの全呼び出し（REST/MCP）をリアルタイムに表示し、上限超過の注文だけを人が判断する ① KPI 掲載品目・在庫・REST/MCP呼出数・キャッシュヒット率・承認待ち ② トラフィック どのエージェントが、どの経路で、何を呼び、結果はどうか ③ 承認 承認上限を超えた注文を承認／却下（引当の解除まで連動） ④ エージェント視点 MCPツールを直接呼び、エージェントが受け取るJSONを確認 Agent Parts Hub ｜ 開発方針 11
12. 品質保証とガバナンス：AIに任せる範囲を設計で決める エージェントの自律性を上げるほど、権限・記録・例外処理の設計が重要になる 権限（スコープ） 承認上限 閲覧・BOM解析・見積・発注をキー単位で分離。設計エージェ エージェントごとの上限額。超過は pending_approval とし、 ントは発注ツール自体が見えない 人の判断を必須に 冪等性 トレーサビリティ Idempotency-Key で通信断・再試行による二重発注を防止。同 流通経路（メーカー直／正規代理店／検査済ブローカー）、 一見積の重複発注は409 CoC、デートコードを属性で返す 監査ログ レート制限 全呼び出しを主体・経路・操作・結果・応答時間で記録 キー単位300回/分。429時は Retry-After と「キャッシュせよ」 のhint Agent Parts Hub ｜ 開発方針 12
13. 段階的移行：閲覧系から始め、取引系は最後に 既存ECを止めずに、エージェント向けの入口を横に増やしていく Phase 1 1〜3か月 Phase 2 4〜6か月 Phase 3 7〜12か月 閲覧系API / MCP 負荷分散・設計支援 取引連携 • カタログ・在庫・価格の照会 • 属性辞書とSI正規化 • llms.txt・OpenAPI公開 • 限定パートナーで検証 k Agent Parts Hub ｜ 開発方針 • キャッシュ／CDNで照会負荷を吸 収 • 代替品・BOM解析の提供 • PCN/EOL監視とwebhoo • データ欠損の補完運用 • 見積・発注API（冪等・承認） • 与信・決済・一括請求 • ERP/購買システム連携 • OAuth 2.1・SLA策定 13
14. PoC計画（3か月）：閲覧系の検証 プロトタイプを出発点に、実データ・実エージェントで「選ばれるデータか」を測る 1か月目 データ整備 API/MCP公開 エージェント接続 計測・改善 2か月目 3か月目 主要5カテゴリ・実品目を属性辞書へ移行 閲覧系を限定公開（認証・監査付き） 社内設計者＋協力顧客2〜3社のAIから接続 検索ヒット率・欠損・誤判定を週次改善 評価・判断 Go/No-Go判断 体制案：PM 1 ／ バックエンド 2 ／ データ整備 1〜2 ／ 営業・技術サポート（協力顧客窓口）1 Agent Parts Hub ｜ 開発方針 14
15. 本開発への判断基準（PoC終了時） 「AIに選ばれるか」と「運用できるか」の両面で判断する 観点 KPI 合格の目安 データ品質 主要属性の充足率／単位正規化エラー率 95%以上／0.5%未満 判断の分岐 Go：Phase 2へ。対象カテゴリを拡 検索有効性 エージェント照会のヒット率（0件率） 0件率 10%未満 代替品の妥当性 drop-in候補を技術者が承認した割合 90%以上 性能 照会応答 p95 ／ キャッシュヒット率 300ms以内／60%以上 大し、キャッシュ基盤を本番化 条件付き：データ整備を延長（属性 辞書・欠損補完に集中） 見送り：既存ECのデータ公開（フィ ード提供）に留める 利用 運用 エージェント経由の見積依頼数・接続社数 人の介入が必要だった割合（型番不明・承認 等） 月100件・3社以上 20%未満、傾向が改善 ※ 目安値は叩き台。協力顧客との合意で確定する Agent Parts Hub ｜ 開発方針 15
16. プロトタイプから本番へ：置き換えるもの・残すもの サービス層のロジックとスキーマは残し、周辺の基盤を差し替える設計にしてある 領域 プロトタイプ 本番 データストア SQLite（架空1,000品目） PostgreSQL＋検索エンジン、PIM・在庫連携 キャッシュ プロセス内TTLキャッシュ Redis／CDN（在庫は短TTL・カタログは長TTL） 認証・認可 固定APIキー＋スコープ OAuth 2.1 client credentials、組織別与信 MCP JSON-RPC最小実装（HTTP/stdio） 公式SDK準拠のリモートMCP＋認可 取引 見積・発注・承認（DB内完結） ERP・決済・物流WMSとの連携 通知 webhook URLの記録のみ PCN/EOLのイベント配信・再送制御 残す資産：属性辞書（taxonomy）・Pydanticスキーマ・サービス層（検索／代替／BOM／見積）・テスト・エージェント向け規約 Agent Parts Hub ｜ 開発方針 16
17. 次のアクション 1 2 3 4 対象カテゴリの決定 協力顧客の選定 データ整備の着手 プロトタイプの社内公開 PoCで扱う主要5カテゴリと実品 設計／調達でAIを使い始めている 既存ECの品目データを属性辞書 社内設計者がMCPで接続し、使 目数を決める 2〜3社に声をかける へ変換し、欠損を把握する い勝手を検証する