エージェント・連携・プロトコル

API・MCP・ツール連携

156件の公開項目

• EA · EA-012AI製品「公称能力 vs 実効能力」辞典「ベンダーが公称する能力は、モデルまたはサービスが対応する技術的範囲を示す。特定組織での実効能力は、製品面、契約・plan、地域、管理設定、identity/permission、tool/data、runtime capacity、quota/cost、業務受入試験を通過した範囲に限る。」
• EA · EA-014AIレッドチーム／耐障害運用編Prompt injection / agent hijackingへの耐性はmodel-only refusalではなく、system containmentとrecoveryの問題として扱う。外部文書、Web、メール、RAG、connector、MCP/tool等のuntrusted inputがprivileged action/dataと同一decision loopへ入ることを前提に、least privilege、deter
• EA · EA-016AI評価・Evals実践編EvalsはAIの「点数表」ではなく、業務上の成功条件を実行可能なテストへ変換し、変更による改善と回帰を検知する運用機構として扱う。生成AIやagentでは最終発話だけでなく、成果物、環境state、tool side effect、権限違反を評価する。Golden setは固定された万能正解集ではなく、provenance、version、coverage、criticalityを持つliving artifactとして管理する。高い
• EA · EA-018AI省エネ・モデルルーティング編「モデルルーティングは、すべての要求を最上位モデルへ送る代わりに、要求ごとの必要能力や組織ポリシーに応じて候補を選び、品質条件を満たす範囲で費用・遅延・計算資源を最適化する制御層として利用できる。ただし、公開benchmarkやベンダー公称の節約率は自組織workloadの保証値ではない。候補model、価格、tool/context対応、region、cache、fallbackが変われば効果も変わるため、固定baselineに対する
• EA · EA-019AI業務パターン・カタログAI業務パターンは、特定製品の機能名やプロンプト例ではなく、「何を正本として、どの入力から、どの権限で、どこまでAIに任せ、誰が承認し、何をもって完了とするか」を再利用可能な型として記述する。
• EA · EA-020AIアーキテクチャ・パターン集AIアーキテクチャは、Single-agentかMulti-agentかという一問だけでは決まらない。制御を誰が握るか、状態と知識をどこに置くか、外部ツールをどの境界から呼ぶか、同期・非同期・batchのどの実行形態を使うか、人間承認と復旧をどこに置くかを分けて設計する。
• EA · EA-021AIアンチパターン集AIアンチパターンは、特定技術を使うこと自体ではなく、有効な技術を責務や適用条件を無視して万能化するところから生じる。長いコンテキスト、RAG、Agent、会話memoryはいずれも有用だが、正本、権限、状態、検証、復旧まで一つの層へ背負わせると、性能・安全性・監査性・費用のどこかで破綻しやすい。技術名ではなく、責務分離と失敗包絡で診断する。
• EA · EA-024AI調達・選定ガイド法人向けAIの調達では、モデル性能や月額料金だけを比較しても不十分である。契約、データ保持・所在地、ID管理、監査ログ、SLA、API継続性、課金meter、機能成熟度、終了時のexport・削除条件まで別々に確認する。公開資料で確認できる機能の存在と、自社plan・tenant・地域・契約で実際に利用できる条件を分離し、証拠のない項目はUNKNOWNのまま残して契約文または受入試験で閉じる。
• EA · EA-030AI能力の継続観測所AI能力の観測値は、モデル名だけに帰属する固定値ではない。モデル識別子、評価課題、実行環境、tool/scaffold、採点器、利用条件、実行日を組にして記録し、同一method versionの系列内で比較する。benchmarkやharnessを改訂した場合は旧系列と新系列をbridge runで接続し、method changeをmodel improvementと混同しない。
• EA · EA-032マルチモーダル業務設計編「multimodal supported」を一つのboolean capabilityとして扱わない。業務設計単位を MODALITY_ROUTE = source modality → normalization/extraction → model-visible representation → reasoning/generation → output modality → tool/external action とし、入力
• EA · EA-033GUI Agent / Computer Use Control ProfileGUI agent / computer-use運用では、automation surfaceを一括りにせず、structured API/tool or MCP、structured browser/page-aware automation、vision GUI browser、full desktop GUIを分離する。業務要件を満たす範囲で最もstructuredなsurfaceを優先し、GUIはfallbackまたはvisua
• EA · EA-036AI長期作業・状態管理専門編「長期作業型AIを成立させる鍵は、巨大なcontext windowを一つ保持することではない。実務では、成果物の正本、実行checkpoint、会話session、圧縮・要約された作業context、外部システムの副作用、run/version/provenanceを別の状態として管理し、再開時にそれらの整合を確認する必要がある。checkpointやsessionは復旧を助けるが、外部副作用の二重実行、schema/model/to
• EA · EA-037AIチーム／AI組織論「複数AIを組み合わせれば自動的に性能が上がるわけではない。独立して並列化できる高価値taskではmulti-agentが有効な場合がある一方、共有contextや依存関係が多いtaskではcoordination costとfailure surfaceが増える。AIチームは役割・権限・state所有・handoff・成果物・停止条件を明示したcontractとして設計し、single-agentまたはworkflow baselin
• EA · EA-038AI＋従来ソフト協調論AIにすべてを実行させず、意味解釈や計画をAIへ、厳密な計算・検証・検索・状態更新を従来ソフトへ返す。従来ソフトも正しさを自動保証しないため、型付き入力、権限、transaction/lock、idempotency、postcondition、readbackを実行契約として固定し、AIの成功宣言ではなく実システムからの再取得で閉じる。
• EA · EA-039AI機能分解・部品辞典「Enterprise AIは製品名や『Agent』という一語で比較せず、推論、検索、RAG、記憶・状態、実行、オーケストレーション、検証・ガードレール、Identity、観測、モダリティ、人間承認などの部品へ分解して扱う。これは唯一の標準分類ではなく、責任・権限・状態・障害・コスト・証拠を追跡するための運用上の共通語彙である。各provider製品は、この共通部品へversionとavailability gate付きでmapping
• EA · EA-042Agent Registry／CatalogAgent Registry/Catalogは、AI agentやtoolを発見・管理するための資産台帳であり、掲載されていること自体は実行権限、identity、現在の可用性、安全性を保証しない。registry metadataとruntime、IAM、承認状態を別々に観測し、version・owner・identity・endpoint・lifecycleのdriftを継続的に照合する。
• EA · EA-043Agent Identity／Non-Human IdentityAgent Identity／Non-Human Identity
• EA · EA-045AI Credential BrokerAI Credential Brokerは、agentへ長期credentialを配布する仕組みではなく、agent/workload identityとauthorizationを確認したうえで、必要なtarget・scope・期間に限定したcredentialを発行・交換する、またはbroker側でcredentialを注入して代理実行する統制パターンとして扱う。SPIFFE、OAuth Token Exchange、Vault等は
• EA · EA-047Agent Policy Enforcement「Agentの禁止操作や許可条件は、LLMの自己判断だけでなく、実行経路上のPolicy Enforcement Pointで強制し、外部Policy Decision Pointにsubject・resource・action・contextを評価させる構成が取れる。OpenID AuthZEN Authorization API 1.0はPDP/PEP間の相互運用境界を標準化している。一方、AI固有のtool意味論やdelegati
• EA · EA-049Browser Agent専門編「Browser Agentは、Web APIがない／十分でない画面操作を自動化できる一方、ブラウザ制御protocolそのものはagentの意図・権限・安全性を保証しない。企業運用ではWebコンテンツを非信頼入力として扱い、session/credential、action policy、network・file境界、監査、最終業務状態の検証をモデル外の制御層に分離する。WebArenaやWorkArena等の成績は比較評価には使える
• EA · EA-051AI Telemetry標準編“OpenTelemetry and W3C Trace Context provide a strong interoperability substrate for AI telemetry, but AI-specific semantic conventions remain an evolving layer. As of 2026-09-14, OpenTelemetry’s GenAI conventions have m
• EA · EA-053AI Incident Response「AI Incident Responseは既存のサイバーIRを置き換える別制度ではない。2026年時点の有力な実務方向は、既存IRへAIシステムの観測性・制御性・version provenance・model/data/tool/agent経路の分析を追加することである。ただしAI固有incident managementの標準化は進行中であり、特定のtaxonomyやreporting schemaを普遍的完成標準として扱うべきで
• EA · EA-055Agent Replay／Forensics「Agentのforensicsはtrace保存だけでは完成しない。後から因果列を再構成できるprovenanceと、外部副作用を隔離したcontrolled replayを分けて設計する。LLM・retrieval・外部toolを含む実行では、同じ入力から同じ出力が得られるとは限らないため、replayは『当時の事実の再構成』と『現在条件での再実行』を明確に区別する。」
• EA · EA-056AI Asset Inventory／AI-SBOM「AI Asset Inventoryでは、SPDXやCycloneDXのAI/ML対応BOMを供給網の機械可読スナップショットとして利用できる。ただし、それだけで企業内のAI利用を完全に棚卸しできるわけではない。prompt、外部API、MCP/tool、RAG corpus、provider-side deploymentなど、実行時に変化する依存をRuntime Asset Registryで補完し、UNKNOWNを明示したまま継
• EA · EA-059Canary／A-B／Feature Flag for AI「AIの段階投入では、modelやprompt等の構成をversionで固定する層と、その構成へtrafficを割り当てるflag/canary層を分ける。Feature flagはroutingの仕組み、canaryはblast radiusを制限して段階的に昇格・中止する運用、A/Bは比較実験であり、同じものではない。既存のprogressive-delivery基盤はAIにも利用できるが、昇格判定には通常の可用性・遅延・costだ
• EA · EA-060AI Dependency Compatibility Matrix「Enterprise AIの互換性は、単一のアプリversionやSDKのsemverだけでは管理できない。model IDとlifecycle、provider API revision、SDK／Agent framework、MCP protocol revisionとcapability、tool schema、prompt、retrieval、policy、evalなどが独立に変化するため、運用上は実際に検証した組合せをCom
• EA · EA-062Data Residency／Sovereign AI「データレジデンシーは『リージョンを選べばすべてがその地域に留まる』という単一機能ではない。保存、推論、ルーティング、ログ、監視、バックアップ、検索/grounding、エージェント実行などで適用範囲が異なり、provider・model・deployment type・featureごとに確認が必要である。Sovereign AIはさらに法的管轄、運用統制、供給網、技術的自律性などを含み得るため、Data Residencyと同義に扱
• EA · EA-070Document Intelligence大全「企業AIの文書入力は、LLMへPDFを渡す処理だけで完結しない。OCR、レイアウト、表、フォーム、業務field抽出は独立したDocument Intelligence層として実装でき、主要cloudはversioned processor/APIを提供している。ただし文字認識・構造抽出・業務field抽出・最終回答は別々の品質段階であり、一段の成功を後段の正確性へ外挿してはならない。」
• EA · EA-071Speech AI大全「Speech AIはSTTやTTSの単体機能ではなく、認識、話者分離、turn-taking、Agent/tool実行、音声合成、interrupt処理までを含む実時間経路として評価する。各機能のavailabilityと品質はmodel、language、region、API modeで異なるため、provider名だけで能力を一般化しない。WER、自然性、会話latency、task success、安全性は別指標として測る。」
• EA · EA-080Synthetic Data編「Synthetic dataは実データへの直接アクセスを減らし、開発・試験・共有の選択肢を増やせる。ただし“synthetic”という生成由来だけでは匿名性やprivacyを保証しない。Enterprise運用では、生成器・source cohort・privacy mechanismをversion固定し、utility、downstream validity、privacy attack、fairnessを独立評価してreleas
• EA · EA-082Embedding／Reranker比較辞典"Embedding models and rerankers are versioned retrieval components, not invisible properties of the LLM. Their quality depends on corpus, task, chunking, filters, index configuration and evaluation target. Public benchma
• EA · EA-085Streaming／Event-driven AI“Event-driven AI replaces polling with event-triggered execution, but safe operation depends on delivery semantics more than model capability. Assume events can be duplicated, delayed, reordered, replayed, or forged; ver
• EA · EA-086Serverless AI Architecture「Serverless AIは、小規模・断続的・event-drivenなAI処理で常時稼働基盤を減らせる有力な実装形である。ただし実行時間、再試行、重複配送、quota、GPU/region、cold pathはproviderごとに異なる。外部side effectを伴う処理ではdurable stateとidempotencyを設計契約に含める。」
• EA · EA-089Local AI Cluster「複数のPC/Mac/GPUを束ねるLocal AI Clusterは、単体では収まらないモデルの分散推論または複数requestの共有処理を可能にし得る。ただし総RAM/VRAMの加算だけでは性能を予測できず、runtime対応、network topology、scheduler、failure domainを実測する必要がある。consumer向けdistributed runtimeにはexperimental/security
• EA · EA-091Multi-cloud AI「Multi-cloud AIは可用性と選択肢を増やせるが、provider間の意味的・運用的同一性を保証しない。routeごとにcapability、data boundary、policy、評価、監査を固定する。」
• EA · EA-092AI Disaster Recovery／BCP「AIのDRはAPIの切替ではなく、依存関係・状態・品質・policyを含む業務継続設計である。別providerが存在するだけではBCPにならない。」
• EA · EA-095AI Chargeback／Showback — 部署・workflow・Agent単位の費用可視化・配賦「AI費用のshowback/chargebackは、トークン数だけでなく、provider請求データとworkflow実行telemetryを突合し、direct cost・shared/idle cost・unallocated costを分離して設計する。FOCUSやOpenCostは正規化・配賦の有力な基盤だが、Agent/workflow単位の会計帰属は組織固有のidentity mappingとversioned alloc
• EA · EA-097Task Mining / Desktop Activity Mining → AI化“Task Mining can complement process-level event-log analysis by observing how selected desktop tasks are actually executed and by surfacing variants, friction and possible automation candidates. Its recordings may contai
• EA · EA-099Accessibility / Inclusive AI — AI出力・AI操作面を障害特性／支援技術／代替表現／訂正可能性まで含めて設計・検証する「AIはcaption、alt text、音声・テキスト変換などを通じてaccessibilityを拡張できるが、自動生成された代替表現の存在だけではaccessibleとは言えない。基礎UIのaccessibility、assistive-technology interoperability、AI生成内容の意味的品質、利用者による訂正・選択・fallbackを分離して検証し、障害当事者を含む実利用評価で確認する。」
• EA · EA-103生成物Provenance／C2PA等「C2PA 2.4は署名付きmanifest、assertion、signer identity、validationを定義し、改ざん検知可能な来歴を表現する。来歴の存在は、内容の真実・安全性・AI利用の完全な証明ではない。」
• EA · EA-110社内AI Policyテンプレート集「NIST AI RMFは任意利用のGovern/Map/Measure/Manageとcontextual Profilesを示し、ISO/IEC 42001:2023は組織のAI管理システム要求事項を示す。本書の禁止入力・承認・agent外部連携テンプレートは、これらを参照して作る組織別運用提案であり、標準本文そのものでも一律の法的義務でもない。」
• EA · EA-111Business Task Benchmark Library「Inspectはdataset・solver・scorer・agent/tool・sandboxを組み合わせる評価実装の選択肢である。企業の業務品質を示すbenchmark libraryは、業務fixture、権限境界、禁止副作用、採点基準、human reviewを組織側で定義して初めて成立し、Inspectの既成eval数だけでは業務保証にならない。」
• EA · EA-112Reproducibility／Determinism研究「再現性は環境境界を伴う契約である。PyTorch 2.14 Docsもrelease・commit・platform・CPU/GPU間の完全再現を保証せず、seedとdeterministic optionで特定環境の非決定性を減らす設計を示す。これをhosted LLMの文字列一致保証へ外挿してはならない。」
• EA · EA-113Email Agent安全運用「Gmail APIはmessages.sendとdrafts.sendを別methodとして提供するため、draft→検査→明示承認→sendという制御点を設計できる。ただし、APIの存在は宛先正確性、承認、DLP、法的適合、送信後回収を保証しない。」
• EA · EA-114Spreadsheet Agent安全運用「Sheets API v4はセル値・書式・保護範囲などを操作でき、batchUpdateはrequest検証と一括適用を提供する。ただし、同時編集の影響があり、APIのatomicityは式の意味正確性、再計算結果、業務上の正しさを保証しない。」
• EA · EA-115Document Fidelity研究「Google Docs APIは文書を構造要素、text run、画像、書式、header/footer/footnoteとして扱う。したがってdocument fidelityは内容・構造・書式・描画を分解して検証すべきだが、このAPI仕様だけでDOCX/PDF/Slides間の視覚的同一性や変換完全性を保証できない。」
• EA · EA-117Deep Research／AI Research Provenance「W3C PROV-OはEntity・Activity・Agentとused/generated/association等で調査来歴を表す標準語彙である。来歴は検証可能性を高めるが、引用の正しさ、一次資料性、sourceの真偽、研究結論の正確さそのものを保証しない。」
• EA · EA-121異種LLMマルチエージェント「AutoGen原著は複数agent、LLM/human/toolの組合せ、相互作用のプログラムを示す。異種LLM構成はその実装候補だが、異種化だけで品質・安全・費用対効果が保証されるわけではなく、task別比較が必要である。」
• EA · EA-122Mixture-of-Agents「MoA原著はlayeredな複数LLMと出力統合を提案し、特定benchmarkでの改善を報告する。ただし、同じ構成が全業務・全providerで優越する証拠ではなく、品質・相関誤り・遅延・token費用・judge biasを含む比較が必要である。」
• EA · EA-129Model diversity engineering「Model diversity engineeringは、複数LLMの異なる出力を比較・集約し、相関した誤りを減らせるかを測る設計論である。Mixture-of-Agents等の研究結果は特定benchmark条件のもので、モデルを増やせば業務品質・安全性・費用対効果が上がるという保証ではない。」
• EA · EA-130Multi-LLM routing「Multi-LLM routingは、入力や品質要求に応じて候補LLMを選択し、費用・品質・遅延を調整する研究／実装パターンである。FrugalGPTやRouteLLMは条件付きの研究結果を示すが、数値を任意の業務や現行製品へ外挿せず、可用性・プライバシー・fallbackを別途検証する。」
• EA · EA-131OpenAI Agents SDK「OpenAI Agents SDKの公式Docsは、agent、tool、handoff、guardrail、session、human-in-the-loop、tracing等のruntime構成を示している。これはOpenAI系実装の仕様証拠であり、プラン・地域・組織設定・production安全性・業務品質の保証ではない。」
• EA · EA-132Google ADK「Google ADKは、agent・tool・multi-agent/graph workflow・evaluation・deploymentを扱うGoogleの現行開発frameworkとして公式Docsに記載されている。ADKの仕様記述は、GeminiやWorkspace製品の全プラン・地域・組織での利用可否、言語間の同等性、production保証を意味しない。」
• EA · EA-133Microsoft Agent Frameworkは「後継だからそのまま移れる」とは限らないMicrosoft Agent FrameworkはAutoGenとSemantic Kernelの公式後継であり、.NET / Python 1.0はproduction-readyである。ただし後継関係を完全互換と読み替えず、Goなどpreview surface、言語別feature gap、migration test、state/tool/telemetry境界を別途確認する。
• EA · EA-137PydanticAI「Pydantic AIの公式資料は、型付きPython agent loop、tools、structured output、複数model接続、streaming・durable execution・instrumentationを実装要素として示す。型検証やdurabilityの記載は、LLMの真偽・認可・外部action安全性・全providerの同一性を保証しない。」
• EA · EA-138Mastra「Mastraの現行Docsは、TypeScript上のagent・workflow・tool・memory・Studio・observabilityを案内している。これは実装要素の存在根拠であり、全provider・plan・regionでの利用可否、業務品質、権限安全性、production SLOの保証ではない。」
• EA · EA-140AutoGen史AutoGen史
• EA · EA-141Semantic Kernel史「Semantic Kernelは、Microsoftの公式資料でmodel-agnosticなopen-source SDK、agent、function calling、plugins、複数言語を備える系譜として記録されている。現行repoはMicrosoft Agent Frameworkへの移行・後継を案内しているが、完全互換、即時廃止、全組織での可用性、production保証は別途確認が必要である。」
• EA · EA-142AWS Strands Agents「Strands Agentsの公式Docsは、AWS発のPython/TypeScript open-source SDKとして、tool、hook、context、execution limit、observability、multi-agent pattern、複数model/cloudの実装入口を示している。SDKの機能記載は、各model・cloud・契約・regionでの可用性やproduction安全性を保証しない。」
• EA · EA-143AWS Bedrock AgentCore「Amazon Bedrock AgentCoreの公式Docsは、agentのdeploy/operate基盤としてRuntime、Memory、Gateway、Identity、Browser、Code Interpreter、Observability、Evaluationsを案内している。各primitiveの存在と、特定account・region・IAM・model・契約での可用性、評価結果の妥当性、production S
• EA · EA-144IBM watsonx Orchestrate「IBM watsonx Orchestrateの公式資料は、複数agentの発見・接続・統合・評価・統治を行うcontrol planeと、ADK／LangGraph import／AI Gateway／human approval等の経路を案内している。機能存在は、契約・plan・region・RBAC・互換性・業務品質・SLAの保証ではない。」
• EA · EA-145ServiceNow AI Agents「ServiceNow AI Agent Studioの公式Docs（Australia release、2026-03-12更新）は、AI agent/agentic workflowの作成・管理・テスト・監視、execution log、manual/automated evaluation、AI Guardian、analyticsを記載している。Otto AI Agentsのinstall等の前提があり、release・tena
• EA · EA-146Salesforce Agentforce「Salesforceの公開Agentforceページは、CRM等の業務データを使うAgent Builder、subagents/actions/instructions、Agent Script、observability、MCP support、multi-agent orchestrationを機能として説明している。ただし、edition・org・region・権限・契約による可用性、性能、安全性、費用、実業務の自律actio
• EA · EA-150n8n「n8nの公式Docsは、chat modelと1つ以上のtoolを接続するAI Agent nodeをworkflow内で使えると説明し、n8n 1.82.0から旧agent type設定を非推奨、v1を3.0で削除予定としている。公式READMEはself-host/cloud、custom code、human approval、observability、RBAC/auditとSustainable Use/Enterprise
• EA · EA-154Pipedream「Pipedreamの公式サイトとDocsは、AI agentとAPIの間にmanaged auth、prebuilt tools/triggers、raw proxy、MCPを置くConnectを説明し、workflow・event/concurrency・source-available component registryも案内している。企業向けConduitは同サイトでearly accessと記載されるため、plan・proj
• EA · EA-157MCP互換性は「対応済み」だけでは判定できない「MCP対応」は単独では互換性の証拠にならない。protocol revision、SDK、実際のwire revision、Gatewayのsupported revisions、下流target、authorization/trust/auditを分離して確認する。2026-07-28は2025-eraとwire behaviorが異なり、SDKのmajor versionだけから実通信revisionを推定してはならない。
• EA · EA-158A2Aは「つながる」だけでは相互運用にならないA2A 1.0はagent間のdiscovery、message、Task、Artifact、streaming/pushを共通化するprotocol contractである。ただし「A2A対応」だけでは相互運用の十分条件ではない。interfaceごとのprotocol version/binding、Agent Card trust、request authorization、tenant isolation、Task/Artifa
• EA · EA-159AG-UI「AG-UIは、agentic backendとユーザー向けfrontendの間を、HTTP／WebSocket等の上にイベント駆動・双方向で接続するプロトコルである。イベント仕様1.0は当該資料でDraftと表示されているため、採用時は版・SDK・再接続・認可・表示安全性を個別に確認する。」
• EA · EA-160OpenAPI／Function Calling「OpenAPI 3.1.0はHTTP APIの機械可読なインターフェース記述であり、function callingはproviderのモデルがアプリケーションへ外部処理の呼出しを要求する実行境界である。OpenAPIをfunction toolへ写像することは可能な設計選択だが、版・operation・schema・認証・実行結果・side effect policyを別途固定し、同一仕様とは扱わない。」
• EA · EA-161Webhook／Event protocol「WebhookはHTTP等による通知・受信の配置であり、全実装に共通する配送保証ではない。CloudEvents v1.0.2はevent context/data、specversion、source/id、format、protocol bindingを定義するが、exactly-once、順序、retry、署名、認証、業務処理の原子性は個別契約として設計・検証する。」
• EA · EA-162OAuth／OIDC × Agent「OAuth 2.0は限定的なHTTPリソースアクセスの委任、OIDCはOAuth上でEnd-Userの認証結果とclaimsを扱うidentity layerである。Agent運用では、human／workload／service identity、resource/audience、scope、delegation chain、tool action、approvalを別々に結び付ける必要があり、OAuth／OIDCの成功だけではa
• EA · EA-163SCIM × AI「SCIM 2.0（RFC 7643/7644）は、Users／Groups等のidentity resourceをHTTPでプロビジョニング・管理する標準である。AIでは、人員異動をAgentやtool accessへ反映する設計の基盤になり得るが、agent資産・権限・token・memoryの無効化までをSCIMが保証するわけではない。」
• EA · EA-171Arize PhoenixArize Phoenix is documented as an open-source AI observability and evaluation platform built on OpenTelemetry and OpenInference. Its documented surface includes traces for model calls, retrieval, tool use and custom logi
• EA · EA-213Unstructured／Document ETLUnstructuredは文書を要素へ分解し、その要素からRAG向けchunkを構成するOSS部品を提供する。抽出方式や依存によって読み順・表・来歴の結果が変わるため、元素材に照合した評価と権限継承を経てindexへ投入する。変換の成功だけで正確性や無通信性を判断しない。
• EA · EA-214DoclingDoclingはPDF、Office、画像等を共通構造へ変換し、Markdown・HTML・JSON等へ出力する。表・読み順・OCRの品質は素材と設定に依存するため、元素材との照合を行う。内部表現のJSON保存は変換後の構造を保持する手段であり、原文の完全復元や正確性の保証ではない。offline運用にはモデル準備と通信制御を別途確認する。
• EA · EA-215LlamaParse／高精度Document Parsing APILlamaParseはtier・versionを選び文書を構造化する専用APIです。素材の複雑さに応じたtier選択と、ページ・表・数値・来歴の評価を分けます。job完了だけで全ページ成功と判断しません。
• EA · EA-217DeepgramDeepgramの音声対話では、API世代・model・入力形式を固定し、文字列の確定、発話終了、生成、実再生、業務操作の認可を分けて管理する。
• EA · EA-220Telephony API × Voice Agent電話向けVoice Agentでは、番号・SIP・call leg/media stream、providerごとのcodec、実再生/破棄、認証、human handoffをAIモデルから分けて確認する。
• EA · EA-221Transactional Email API × AgentAgentのdraftを送信操作へ変換する際は、全recipientと本文・添付の承認、domain認証、重複防止、配送event、suppressionを個別に追跡する。
• EA · EA-222Slack／Teams／ChatをAgentの業務面にするチャット上の入力・承認・通知・handoffを業務操作へ安全に接続できるか。署名やボタン押下だけを本人認可・最終承認へ転用しない。
• EA · EA-223Calendar／Scheduling API × Agentfree/busyから候補を作った後、時間帯・参加者・招待副作用・競合・再試行をどう管理するか。空き時間確認だけで予約確定や全員承諾を宣言しない。
• EA · EA-685Coding AgentのDependency Hallucination／Slopsquatting防御AIが生成した依存パッケージ名は導入候補として扱います。存在確認、正常なhash、provenance、既知脆弱性scanのいずれも単独では安全性を保証しません。導入前の承認identityと、実際に取得するartifactのidentity・bytesを結び付けて確認する運用が必要です。この運用は設計上の提案であり、特定製品の防御率を実証したものではありません。
• EA · EA-005MCP実践辞典 — Model Context Protocolを「共通コネクタ」ではなく、server/client/host、transport、authorization、tool capability、server trust、supply chain、auditを分離した企業運用契約として整理する「MCPは、AIアプリケーションと外部のデータやツールを共通形式で接続するためのprotocolであり、接続先やツールの安全性を自動的に保証する仕組みではない。2026-07-28仕様ではstateless化とOAuthのhardeningが進み、HTTP接続ではresource-bound tokenや段階的scope取得を扱える。しかし、どのMCP serverを信用するか、どのtoolをmodelへ見せるか、実行をpolicyや人
• EA · EA-239Content Safety／Moderation Model・APIContent Safety／Moderation APIは、入力や出力を「安全／危険」と最終決定する認可機構ではありません。特定のモデル、taxonomy、threshold、対応modalitiesと言語の下で、ポリシー判断に使う分類信号を返す部品です。組織側では、この信号をどの条件でblock、allow、transform、human reviewへ接続するかを別に定義します。
• EA · EA-242Saga／Compensating Action × AgentAgentの複数副作用を「失敗したら逆操作する」だけでSagaとみなしません。各stepを事前にcompensable/pivot/retriableへ分類し、forward resultとdownstream operation IDをdurableに記録します。UNKNOWNは照会/reconciliationしてから回復方向を決め、compensation自体もidempotent・再試行可能・監査可能にします。補償はACID r
• EA · EA-002Microsoft AI系統編 — Microsoft Copilot / Copilot Studio / Microsoft Foundry / GitHub Copilot / Microsoft Graph・SharePoint・Teamsを「一つの製品」ではなく相互接続する複数のAI運用面として記述するための境界地図「Microsoftの法人向けAIは、一つのCopilot製品ではなく、複数の運用面が接続した系統として見る方が安全である。Microsoft CopilotはMicrosoft 365の権限とGraphを使う利用者面、Copilot Studioは業務エージェントを組み立てるmaker面、Microsoft Foundryはモデル・ツール・実行・観測を扱うpro-code面、GitHub Copilotは開発者向けの別管理面を持つ。こ
• EA · EA-003Apple Intelligence／オンデバイスAI編 — Apple Intelligence、Foundation Models、Private Cloud Compute、App Intents、Core ML/Vision、MLXを「AppleのAI」という一枚岩ではなく、実行場所・開発者API・privacy boundary・action integration・古典ML/研究基盤に分解する運用地図「AppleのAI運用は『オンデバイスかクラウドか』の二択では捉えにくい。Apple Intelligenceには端末上で動くFoundation Modelと、より大きな処理をPrivate Cloud Computeへ送る経路があり、2026年のFoundation Models frameworkはさらに他のモデル提供者を共通APIへ接続できる。Private Cloud Computeは通常のクラウド推論とは異なるstatele
• EA · EA-006Agent-to-Agent／マルチエージェント編 — A2A v1.0、framework内handoff/subagent/orchestration、MCPとの役割差を横断し、委譲・context・identity/authorization・失敗伝播・human approval・評価を別契約として整理する「マルチエージェントは、複数のAIを並べれば自動的に賢くなる仕組みではない。まず『どう接続するか』と『誰が仕事を割り振り、誰が最終判断を持つか』を分けて考える必要がある。A2Aは異なるエージェント同士が能力を発見し、taskやartifactを交換するための相互運用protocolであり、manager、handoff、parallel workflowなどのorchestration方式そのものを決めない。MCPも別の層で、主にage
• EA · EA-007AI連携・自動化ツール大全Treat workflow automation as an execution and authority boundary. Record credential owner, trigger, connector/action version, side-effect class, retry/idempotency contract, DLP/policy scope, execution evidence, audit ret
• EA · EA-008BOUNDED_CLOSECompare low-cost API use with an as-of ledger that separates list price, free allowance, trial credit, quota/rate limit, cache/batch/tool charges, region, data-use terms, and migration-to-paid conditions. Re-read the pro
• EA · EA-234Secrets Management × AgentAgentのSecrets Managementは、秘密を保存するだけでは不十分です。raw secretをmodel contextやagent-generated codeへ直接渡さず、必要なidentity・destination・operationへ限定して権限を仲介する設計を基準にします。
• EA · EA-235Policy Engine実装：OPA／CedarAgentのauthorizationをmodel instructionへ委ねません。OPA/RegoやCedarなどのPolicy Engineは、AIの外側でtool/action実行前にdecisionを行い、application/tool gatewayがそのdecisionを強制する構成で使用します。
• EA · EA-237DLP／CASB／SSEで生成AI利用を統制するDLP/CASB/SSEは生成AI利用の可視化、data classification、access control、inline block/redactionを強化できます。ただし「DLP導入済み」を、すべてのprompt、response、file、tool、MCP経路が保護されている証明として扱いません。
• EA · EA-241Agent Idempotency／重複実行防止Agentの重複実行防止は、promptで同じtoolを二度呼ばないと指示するだけでは成立しない。timeout、network disconnect、SDK retry、queue redelivery、webhook replay、double click、model/tool retryがあるため、副作用を持つ操作にはstableなbusiness operation identityとdurableな重複判定が必要である。ide
• EA · EA-243Transactional Outbox／Inbox × AgentAgentがbusiness stateを更新し、その結果をevent/messageとして別systemへ通知する場合、DB commit→broker publishの二段処理を成功前提にしません。business stateとoutbox eventを同じlocal transactionへ閉じ、relayがcommit済みoutboxを非同期publishします。Outboxはproducer側dual-write lossを抑
• EA · EA-244Durable Execution／Workflow Replay for AIDurable Executionは長時間のAgent workflowのstate/progressをdurable history/checkpointへ残し、failure後に復元・継続する実行方式です。ただし外部API・tool・payment・email・database mutation等のside effectがexactly-onceになることを意味しません。
• EA · EA-247Retry Budget／Backoff／Fallback CorrectnessRetryは各layerの「最大N回」ではなく、original user/workflow requestに対するend-to-end budgetとして管理します。budgetにはtotal downstream attemptsだけでなく、wall-clock deadline、token/compute/API cost、side-effect riskを含めます。
• EA · EA-1209Perplexity／Sonar Product-surface Operating ProfilePerplexityを法人運用する際は、Web/SaaSの検索・研究体験、EnterpriseのSpaces・組織管理・コネクタ、開発者向けSearch API、Agent API、旧Sonar Chat Completionsを同じ製品面として扱わない。2026年10月20日時点で、Perplexity公式ドキュメントは新規開発にAgent APIを推奨し、Sonar Chat Completionsのサポートは2026年9月27日に
• EA · EA-1210DeepSeek API／Open-weight Deployment Operating Profile「DeepSeekはopen sourceなので自社内だけで動く」「DeepSeek APIと公開weightは同じモデル」「model nameを固定すればversionも固定される」「OpenAI互換なのでOpenAI APIと同じ挙動」と一般化しない。
• EA · EA-1211Qwen Model-family／Managed API／Local Deployment Operating Profile「Qwen3を導入した」ではなく、「2026-10-20時点でAlibaba Cloud Model Studioのregion/scope Xにおけるmodel ID Yをprotocol Zで利用」または「Qwen公式repository/revision Rのweightをruntime/version Q、quantization Nでself-host」と記述し、managed serviceとopen-weight arti
• EA · EA-1212Mistral Platform／Open-weight Operating Profile「Mistralの運用条件はprovider名ではなく、surface・model/version・weight artifact・license・runtime・region/data-processing条件を分離して確認する。」 「open-weightであること、APIで提供されること、同じmodel family名であることを、同一の契約・runtime・data boundaryの証拠として扱わない。」
• EA · EA-1214Gemma Open-weight Model-family Operating Profile「GemmaはApache 2.0のGoogle製open modelで、ローカルなら安全に使える」ではなく、「採用するGemma family/variant/revisionごとにlicense、weight hash、runtime、quantization、capabilityを固定する。Gemma 4は現行公式model cardでApache 2.0だが、旧familyには別Termsの対象があり、self-host時のse
• EA · EA-1218AgentWorld — 長期マルチエージェント協調ベンチマークAgentWorld は複数AIエージェントの長期協調を評価する研究ベンチマークである。既存GX provenanceでは arXiv:2609.31590、50ラウンド超、3〜20エージェント、採集時点の最良系タスク成功率52.0%が記録されている。
• EA · EA-175PromptfooPromptfooはLLM/AIアプリの評価・red-teamを構成可能なOSS harnessである。pass/failやred-team scoreは、固定したtest corpus、assertion、grader、target、Promptfoo version、plugin/strategyの範囲で得られた観測であり、品質・安全性・法令適合・本番SLOの包括保証ではない。機密用途では実際のegressとdeployment m
• EA · EA-184OSWorld系OSWorld系は、実際のデスクトップ環境でGUI・OS・アプリケーションを操作するcomputer-use agentを評価するベンチマーク群である。企業で結果を参照する場合、「OSWorld」という名称や単一スコアだけでは比較条件を特定できない。OSWorld 1.x、OSWorld-Verified、OSWorld-V2を分離し、V2ではrelease manifestが固定するcode、task files、task asset
• EA · EA-224CRM API × Agent — 書き込み成功を業務上の成功と誤認しない「CRM APIをAgentから操作できること」と「業務上正しく一度だけ更新できたこと」は別です。成功判定はHTTP statusだけでなく、record identity、部分失敗、権限・tenant validation、rate limit/timeout、再試行の冪等性、重要field/associationのreadbackを含めて設計します。providerがtransactional primitiveを提供しても、その原
• EA · EA-225Project／Issue Tracker API × AgentProject/Issue Tracker API連携では、Agentの記憶ではなく外部チケットのIDと現在状態を仕事台帳の照合先にする。ただし、一覧取得の途中失敗・権限・ページ分割、書き込み後の不明な結果、Webhook未達を別々に扱う。承認は対象と変更フィールドに結び付け、結果を再読込する。PyGithub 2.10.0の模擬通信による実SDK検査では、遅延ページ取得、途中例外、省略フィールドと空配列の違い、およびUTC以外のsin
• EA · EA-226Customer Support／Ticketing API × AgentCustomer Support／Ticketing API連携では、分類・回答草案・人への引継ぎ・顧客への送信・状態更新を別の操作として管理する。内部メモは公開範囲を明示し、承認した本文と対象を送信前に照合する。更新競合の制御は各リクエストの実際のペイロードで確認し、応答後もチケット状態を再読込する。古い利用者報告には、SDKの別リクエストによる部分変更や、HTTP200後に意図した変更が確認できなかった例がある。今回のZenpy2.
• EA · EA-227E-signature APIをAI/Agent文書業務へ接続する際の送信・署名状態・権限・証跡境界「AIが署名文書を生成・API送信できること」と「正しい当事者が意図した文書へ有効に署名し、必要な証跡が保存されたこと」は別です。不可逆な送信前に文書version/hash、recipient、environment、権限、承認を固定し、送信response、署名状態、最終文書を別々にreadbackします。test mode、webhook受信、access removalを、それぞれ法的成立、exactly-once処理、全消去の
• EA · EA-228Push Notification API × Agent：通知送信を業務実行と誤認しないための設計Push Notification APIの送信成功は、利用者への表示・閲覧・承認・業務完了の証明ではありません。Agentから通知を送る場合は、通知をauthoritative stateへの案内として設計し、recipient、event ID、TTL、priority、collapse、rate、sensitivityを制御します。重複・順序逆転・遅延・非表示・throttlingをfailure envelopeへ含め、重要な処
• EA · EA-229WhatsApp／SMS Business Messaging × Agent「エージェントはWhatsApp/SMS送信を実行できるが、送信APIの成功は配送・閲覧・業務成果を保証しない。会話window、template eligibility、同意・停止、重複防止、provider-side identifier、非同期status、reconciliationを独立した制御として実装し、チャネル・契約・地域固有の条件を実環境で確認する。」
• EA · EA-232キューとメッセージブローカーでAI Agentを非同期に動かすキューは、依頼を受け付ける処理と、AIや外部ツールで実行する処理を時間的に分離します。待ち行列に入れたことは、業務が完了したことではありません。また、再配信や再試行は通常の故障回復経路です。Agentがメール送信や発注を行う場合は、メッセージの配送保証と、業務上の作用を一度に抑える制御を分けて設計します。
• EA · EA-253Data Catalog／Metadata Catalog × AIData CatalogをAI/Agentのcontext sourceにする場合、検索結果をそのまま正本データや実行権限として扱いません。 Catalogから取得したcontextには、可能な範囲でentity identity、source locator、metadata revision/freshness、owner、glossary/term、lineage、quality、authorization境界を残します。
• EA · EA-254Event Schema Registry × AgentEvent Schema RegistryはAgentのevent contract gateとして有効ですが、`compatibility PASS`をbusiness semantics、全consumerのruntime成功、publish権限、Agent action安全性の保証として扱いません。
• EA · EA-255Feature Store × Generative AIFeature StoreはGenerative AIやAgentへ低遅延のstructured contextを供給できます。ただし、`feature retrieval success`を値の最新性、point-in-time correctness、回答正しさ、または業務action権限の保証として扱いません。
• EA · EA-259Agent Egress Control／Network PolicyAgent egress controlは、private endpointやVPC接続の有無だけで判定せず、Agent runtimeから外部destinationへ出る実際のpathを制御します。
• EA · EA-260API ManagementをAgent Tool層に置くAgentからtool APIへ到達する経路にAPI Management/API Gatewayを置くと、認証、公開route/tool、rate/quota、protocol/schema、監査を集中しやすくなります。
• EA · EA-261AIサービス間通信をService Mesh mTLS化AI/Agentサービス間のeast-west通信をservice meshで捕捉すると、workload identity付きmTLSによる相互認証と通信暗号化を集中できます。ただしmTLS成立をleast-privilege authorization、全経路のmesh化、application-level安全性とは同一視しません。
• EA · EA-263Model／Prompt／Agent Artifact Registry「登録物の版、来歴、評価、承認、実際の取得物を結び付ける基盤として利用できる」。一方、「登録済みだから安全」「エイリアス名が同じなら内容も同じ」「ハッシュ一致で業務品質まで証明済み」とはしない。
• EA · EA-267Reproducible Runtime／Dependency Lock for AgentAgent runtimeの再現性では、source revisionとdependency lockだけでなく、runtime/container digest、OS/architecture、toolchain、build instructions、再現性に影響するenvironment、model/API/tool/prompt設定のversion/digestを固定します。
• EA · EA-270Explicit State Machine vs Free-form Agent Loopstate machine採用だけでexactly-onceや正当性は保証されず、free-form loopもtermination・権限・checkpoint・readbackを明示すれば統制できる。
• EA · EA-271AI SLO／Error Budget運用AI/Agentの信頼性運用では、単一の「成功率」やprovider uptimeをSLOと同一視せず、利用者が経験するcritical journeyごとにSLI、SLO target、budgeting method、window、error-budget policyを固定します。error budgetは観測された失敗を許容する枠であり、品質保証や免責ではありません。
• EA · EA-288Privileged Access Management for Agents「実行主体・対象・操作・期間を限定し、取得から終了までの特権利用を検証可能にする」。一方、「短期トークンなので安全」「人向けPIMをそのままエージェントにも適用可能」「権限を外せば全実行が瞬時に停止」「秘密が見えなければ万能ツールでも問題ない」とはしない。
• EA · EA-499Agentへ委譲する権限の範囲と失効Agentへの作業依頼は、利用者や委譲元の全権限を渡すことではありません。現在の実行主体、誰のために動くか、許可された操作と対象、引数、期限、再委譲の条件を明示し、重要な効果の直前に現在の権限を照合します。委譲の履歴が残っていることと、今その操作を許可してよいことは別です。長時間の処理では、開始時の許可、更新・失効、非同期で残った仕事まで管理します。
• EA · EA-500Agentの能力契約を検証するAgentが能力を公開していることと、その能力を利用者の期待どおりに実行できることは別です。能力契約の検証では、宣言、入出力schema、protocolと版、認証・認可、呼出し状態、業務上の効果を分けて確認します。同じ名前のskillやtool、同じJSON構造だけから、取消、重複実行、失敗、完了の意味まで同じと推定しません。
• EA · EA-501Agent Side-Effect Compensation：AIエージェントの外部副作用を「巻き戻し」ではなく検証可能な補償として扱う「補償はundoではなく新しい副作用である。元操作の結果を照合し、現在の回復権限・対象状態・後続変更・冪等性を再検証した上で実行し、最終的な業務／システム状態をreadbackする。不可逆な作用はrollbackと呼ばず、containmentまたはforward recoveryとして扱う。」
• EA · EA-504Agent Causality Graph／Action ReconstructionAIエージェントのaction reconstructionでは、traceを重要な相関証拠として使うが、完全なeffect ledgerとはみなさない。durable decision/action identity、authority/policy version、workflow/tool/provider operation ID、外部targetのauthoritative readbackを結合し、trace coverag
• EA · EA-507Agent Delegation Depth／Recursion Guard「max turnsを設定すれば再帰問題は解決する」「A2Aがdelegation cycleを防止する」とは断定しません。安全な表現は、「agent delegationにはdepth、fan-out、turn/tool/cost/deadline、cycle/no-progress、side-effectを別々のbudgetとして持たせ、root operationからchildへ残量を継承し、機械的terminationとcanc
• EA · EA-516AIメモリ汚染の隔離と復旧AIメモリの汚染から復旧する際は、疑わしい一件の削除や会話のリセットだけで完了としません。保存された内容、書込み元、要約・統合の経路、派生物、参照中のcontext、復元用snapshotへ影響が残っていないかを確認し、隔離した状態から信頼できる入力で再構築し、再利用を再開できる根拠を残します。本項は防御側の隔離・調査・復旧を扱います。攻撃用入力や侵入手順の提供は含みません。
• EA · EA-519プロバイダー間で能力契約と意味の同等性を確認するモデルやAPIを切り替える際、toolの名前とJSONの形を揃えるだけでは、同じ仕事を同じ条件で実行できると証明できません。プロバイダーをまたぐ能力契約では、呼出しと結果の対応、実行主体、入出力の意味、権限、終了・失敗、再試行、外部効果を明示し、対応できない差を失わずに扱います。意味の同等性は、対象操作・版・入力範囲・観測条件を指定した検証結果として記録します。
• EA · EA-732AI compliance obligation→machine-readable control mapping「machine-readable mappingは追跡・差分検出・評価連携を支援するが、mappingまたはOSCAL schema conformanceだけで法令・契約への準拠を証明するものではない。」
• EA · CORE-01状態を持つAIの運用契約この章の仕事は、LLMを「会話を返すもの」から「状態を持つ業務に参加するもの」へ移すときに必要な最小契約を定義することである。
• EA · CORE-03タスク分解と処理工程CORE-03は、複合taskを検証可能なstageへ分け、stage間の入出力、intermediate artifact、retry、verification、parallel/serial、transaction境界を定義する。目的は「一発でやらせない」という標語ではなく、失敗を局所化し、再実行で完了済み工程や外部状態を壊さず、local passとend-to-end successを分けて判定できるpipeline contr
• EA · CORE-04モデル・ツール・情報源・状態の選択本章のroutingは、taskを実行するmodel、tool、source、state経路を、検証可能な契約へ照合して選ぶ操作である。model名、価格、quota、connector、画面、edition、surface capabilityはProduct Mappingへ、承認者、利用可否、予算・latency・riskの数値閾値はOrganization Overlayへ送る。CORE-02のretrieval/memory定
• EA · CORE-05エージェントの副作用・復旧・人への引継ぎCORE-05は、AIが外部状態を変更する前後のread/write境界、permission scope、dry-run、confirmation、idempotency、compensation、undo、human escalation、action evidenceを定義する。目的は「人が承認した」「toolがsuccessを返した」を安全・完了とみなさず、意図した対象・操作・差分と外部最終状態を照合し、失敗時に停止・修復・引継
• EA · CORE-06プロンプトと設定の管理CORE-06は、promptと周辺configurationを再構成・比較・承認・release・rollbackできるversioned entityとして管理する。目的は「prompt文字列は同じ」「昨日と同じmodel名」を再現性の証拠とせず、実際のbehaviorを変える構成要素とenvironment差を一つのrelease lineageへ結ぶことである。
• EA · PM-CLAUDE-CORE-01CLAUDE：状態を持つAIの運用契約This mapping binds Anthropic Messages, Message Batches and Claude Agent SDK session, resume, fork, hook and file-checkpoint surfaces to CORE-01. Provider dialogue/session state is not the canonical business task record.
• EA · PM-CLAUDE-CORE-03CLAUDE：タスク分解と処理工程CORE-03のstage、artifact、handoff、parallel/serial、resume/retry、verification、transaction境界をClaude Agent SDK/Claude Codeの公開surfaceへ対応づける。会話session、subagent、tool result、hook、permission、filesystem、外部systemを同一状態として扱わない。S063 Froz
• EA · PM-CLAUDE-CORE-04CLAUDE：モデル・ツール・情報源・状態の選択CORE-04のmodel / tool / source / state routing、fallback、batch、observability契約をClaude API、Message Batches、service tier、Claude Agent SDKへ対応づける。Claude.ai、Claude API、Agent SDK、Claude Code CLI、Bedrock、Google Cloud、Managed Agen
• EA · PM-CLAUDE-CORE-05CLAUDE：エージェントの副作用・復旧・人への引継ぎCORE-05のread/write境界、scoped permission、確認、receipt/readback、idempotency、補償、undo、human escalationをClaude API tools、MCP connector、Claude Agent SDK／Claude Codeへ対応づける。modelのtool_use、permission allow、hook通知、tool result、file ch
• EA · PM-CLAUDE-CORE-06CLAUDE：プロンプトと設定の管理CORE-06のversioned configuration bundle、declared/effective差、environment diff、canary、rollbackをClaude API、Claude Agent SDK、Claude Codeへ対応づける。対象はsystem prompt、settingSources、settings/CLAUDE.md/skills、model/effort、tools、struc
• EA · PM-GEMINI-CORE-03GEMINI：タスク分解と処理工程CORE-03のstage、artifact、parallel/serial、retry、verification、transaction境界をGemini系の公開surfaceへ対応づける。Gemini Appsのchat/Gem、Gemini API、ADK、Vertex AI/Google Cloudの実行基盤を同一機能として扱わない。公開仕様、author-maintained issue、CORE-03のlocal LangG
• EA · PM-GEMINI-CORE-04GEMINI：モデル・ツール・情報源・状態の選択CORE-04のmodel / tool / source / state routing契約を、Gemini Apps、Gem、Gemini API、ADK、Vertex AIへ対応づける。各surfaceのmodel名、tool、state、batch、quotaを一つの自動routerとみなさず、公開仕様、公開failure signal、組織観測を分離する。価格・quota・tenant設定・内部routingはcurrent値
• EA · PM-GEMINI-CORE-05GEMINI：エージェントの副作用・復旧・人への引継ぎCORE-05のread/write境界、confirmation、idempotency、recovery、undo、human escalationを、Gemini Apps、Gemini API、ADK、Vertex AI系runtimeへ対応づける。公開機能の存在を、trusted approval、exactly-once、external readback、完全undo、tenant採用の証拠へ昇格しない。CORE-05のl
• EA · PM-GEMINI-CORE-06GEMINI：プロンプトと設定の管理CORE-06のconfiguration bundle、version、digest、lineage、environment diff、canary、rollbackを、Gemini Apps/Gems、Gemini API、Vertex AI Prompt Managementへ対応づける。UIの保存、prompt version、model名、restore機能の存在を、composite release bundle、backe
• EA · PM-GPT-CORE-04OpenAI / GPT：モデル・ツール・情報源・状態の選択CORE-04のmodel / tool / source / state routing契約を、OpenAI API、Responses、Chat Completions、Batch、background mode、Agents SDKへ対応づける。ChatGPT UI、API endpoint、SDK default、application-owned routerを別surfaceとして扱い、価格・quota・tenant設定・内
• EA · PM-GPT-CORE-05OpenAI / GPT：エージェントの副作用・復旧・人への引継ぎSource: OpenAI, Human-in-the-loop, [ ; accessed 2026-09-08; sections Marking tools that need approval / How the approval flow works / Automatic approval decisions / Long-running approvals. New source EXT-C05-001.
• EA · PM-GROK-CORE-01GROK：状態を持つAIの運用契約This mapping binds xAI Responses, stored continuation, deferred Chat Completions, Batch API, function calling, ZDR and the official Python SDK to CORE-01. Provider response, request, batch and tool-call states are runtim
• EA · PM-GROK-CORE-03GROK：タスク分解と処理工程This mapping binds xAI Responses, function/tool calling, Multi-Agent, Remote MCP, context compaction, WebSocket mode, deferred requests and Batch to the existing CORE-03 contract. Provider continuation, tool-loop complet
• EA · PM-GROK-CORE-05GROK：エージェントの副作用・復旧・人への引継ぎCORE-05のproposal、permission、confirmation、execution、receipt/readback、idempotency、compensation、undo、human escalationを、xAI Responses／Chat、client-side function、server-side tool、Remote MCP、deferred／Batchへ対応づける。modelのtool call
• EA · PM-GROK-CORE-06GROK：プロンプトと設定の管理CORE-06のversioned composite configuration、declared/effective差、environment diff、canary、rollbackをxAI APIへ対応づける。対象はrequest message、model/alias、sampling/reasoning parameter、client/server/MCP tool、Collection/file source、struc
• EA · ORG-CORE-03組織での適用：タスク分解と処理工程組織固有の承認、実行surface、artifact、retry、保持、監視の値をCoreとProduct Mappingから分離する。既知なのは、業務Geminiへのfile sync・API・直接統合は禁止され、chatへのsynthetic prompt投入とGem構築試験は可能候補という境界である。製品defaultや公開issueから組織値を補完しない。
• EA · ORG-CORE-04組織での適用：モデル・ツール・情報源・状態の選択組織固有のroute owner、approved model/surface、risk/loss budget、fallback、state handoff、監視値をCore/Product Mappingから分離する。既知の境界は、業務Geminiへのfile sync・API・直接統合は禁止、synthetic promptによるchat試験とGem構築試験は可能候補、というものである。公開product defaultやcomm
• EA · ORG-CORE-05組織での適用：エージェントの副作用・復旧・人への引継ぎ組織固有のapproved action surface、permission、approver、risk threshold、idempotency、receipt/readback、undo、recovery、incident ownerをCore/Product Mappingから分離する。既知の境界は、業務Geminiへのfile sync・API・直接統合は禁止、Gemini chatへのsynthetic prompt投入と
• EA · ORG-CORE-06組織での適用：プロンプトと設定の管理組織固有のapproved configuration surface、owner、approver、version ledger、source policy、release/canary/rollback、retentionをCore/Product Mappingから分離する。既知の境界は、業務Geminiへのfile sync・API・直接統合は禁止、chatへのsynthetic prompt投入とGem構築試験は可能候補、とい
• EA · SOURCE_REGISTRY根拠資料と検証記録No new external source or experiment was promoted. PUBLICATION_GATE_CENSUS.md and evidence/INT-PUB-GATE-022/PUBLICATION_GATE_CENSUS.json classify the remaining publication routes. DOI 10.1016/j.scico.2026.103530 / PII S0