モデル・サービス・契約

料金・提供条件・モデル選択

201件の公開項目

• EA · EA-012AI製品「公称能力 vs 実効能力」辞典「ベンダーが公称する能力は、モデルまたはサービスが対応する技術的範囲を示す。特定組織での実効能力は、製品面、契約・plan、地域、管理設定、identity/permission、tool/data、runtime capacity、quota/cost、業務受入試験を通過した範囲に限る。」
• EA · EA-013AI失敗事例・事故解剖大全AI事故はモデルが誤った瞬間だけを指すものではない。業務上の事故は、モデル・データ・ツール・製品制御・人間確認・通常のソフトウェア基盤の複数層を通って成立する。公開事例は各製品の現在の失敗率を示すものではなく、どの防護線が必要かを学ぶための事例として扱う。
• EA · EA-015AI監査・証跡設計大全AIシステムの監査可能性は、単一ログの有無ではなく、control/admin、identity/auth、data/retrieval、model request/result、tool/action、human approval/override、artifact/config/model provenance の各planeを横断して、業務上必要な事象を再構成できることとして扱う。
• EA · EA-017AIコスト工学／ROI編token/list priceはEnterprise AIの総原価の一部にすぎない。比較単位は、固定したquality gateを通過した「accepted outcome 1件あたりのend-to-end cost」とし、model usageだけでなくtool/retrieval、storage/runtime、人間確認、失敗・再実行、observability/governance、固定費配賦を分離記録する。
• EA · EA-018AI省エネ・モデルルーティング編「モデルルーティングは、すべての要求を最上位モデルへ送る代わりに、要求ごとの必要能力や組織ポリシーに応じて候補を選び、品質条件を満たす範囲で費用・遅延・計算資源を最適化する制御層として利用できる。ただし、公開benchmarkやベンダー公称の節約率は自組織workloadの保証値ではない。候補model、価格、tool/context対応、region、cache、fallbackが変われば効果も変わるため、固定baselineに対する
• EA · EA-019AI業務パターン・カタログAI業務パターンは、特定製品の機能名やプロンプト例ではなく、「何を正本として、どの入力から、どの権限で、どこまでAIに任せ、誰が承認し、何をもって完了とするか」を再利用可能な型として記述する。
• EA · EA-022AI移行・乗り換え辞典AIの移行は、モデル名やAPI endpointの置換だけでは完結しない。instruction/prompt semantics、conversation/session state、memory/profile state、files/retrieval/index、tools/integration schemas、identity/permission/consent、workflow/agent/runtime、eval/au
• EA · EA-023ベンダーロックイン回避設計ベンダーロックイン低減は「完全なvendor neutrality」ではなく、lock-in surfaceを小さく可視化し、交換時に再構築する範囲を限定する設計として扱う。実装原則は PORTABLE CORE + EXPLICIT ADAPTERS + ISOLATED EXTENSIONS + EXTERNALIZED STATE + INDEPENDENT EVAL/AUDIT。
• EA · EA-024AI調達・選定ガイド法人向けAIの調達では、モデル性能や月額料金だけを比較しても不十分である。契約、データ保持・所在地、ID管理、監査ログ、SLA、API継続性、課金meter、機能成熟度、終了時のexport・削除条件まで別々に確認する。公開資料で確認できる機能の存在と、自社plan・tenant・地域・契約で実際に利用できる条件を分離し、証拠のない項目はUNKNOWNのまま残して契約文または受入試験で閉じる。
• EA · EA-025小規模事業者／一人法人版小規模事業者版はEnterprise統制の省略版ではなく、専任管理者がいない環境でも維持できる少数の高価値controlへ圧縮する運用profileとして扱う。最低限の境界は、業務用identity/MFA、投入データ規則、vendor card、高影響操作のhuman checkpoint、cost ceiling、recovery kitの6つとする。
• EA · EA-026部門別実践版部門別AI運用は、営業用・人事用・法務用と別々のAIを並べることではない。共通のデータ境界、権限、正本、承認、評価、証跡のCoreを持ち、部門ごとに「何を正本とするか」「何をAIへ入れてよいか」「どの判断を人間が引き受けるか」「どの外部作用を承認するか」「何を証拠として残すか」を上書きする。部門名だけで安全性は決まらず、task、data、decision impact、external actionの組合せでgateを決める。
• EA · EA-029Enterprise AI運用テンプレート集運用テンプレートはAI統制を自動的に成立させるものではなく、判断・証拠・変更・未解決事項を再現可能に残すための器である。共通Coreを用意しつつ、法域・業界・組織・providerに応じて項目をtailorする。PASS/完了の記入だけでなく、根拠となるsource、eval、承認、readbackを結び付ける。
• EA · EA-030AI能力の継続観測所AI能力の観測値は、モデル名だけに帰属する固定値ではない。モデル識別子、評価課題、実行環境、tool/scaffold、採点器、利用条件、実行日を組にして記録し、同一method versionの系列内で比較する。benchmarkやharnessを改訂した場合は旧系列と新系列をbridge runで接続し、method changeをmodel improvementと混同しない。
• EA · EA-031AIアップデート互換性研究AI更新の互換性は、単一のversion番号やAPI疎通ではなく、wire/API、schema/tool、instruction、model behavior、state/storage、interoperability/protocol、operational、economic、governance/auditの九つの変更面を分離して評価する。API requestが成功することはWIRE_API_COMPATの一部しか確立しない。
• 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-039AI機能分解・部品辞典「Enterprise AIは製品名や『Agent』という一語で比較せず、推論、検索、RAG、記憶・状態、実行、オーケストレーション、検証・ガードレール、Identity、観測、モダリティ、人間承認などの部品へ分解して扱う。これは唯一の標準分類ではなく、責任・権限・状態・障害・コスト・証拠を追跡するための運用上の共通語彙である。各provider製品は、この共通部品へversionとavailability gate付きでmapping
• EA · EA-040Enterprise AI Coreそのものの標準化「Enterprise AI Core」は既存の単一国際標準の名称ではなく、本辞典がベンダー中立の運用比較面として定義するprofileである。ISO/IEC 22989・23053・42001、NIST AI RMF/GAI Profile、TEVV資源、OpenTelemetry等の既存標準・枠組みを置換せず、能力・境界・状態・証拠・統制・ライフサイクルをcrosswalkする。provider固有機能とtenant実挙動は別レイヤ
• EA · EA-042Agent Registry／CatalogAgent Registry/Catalogは、AI agentやtoolを発見・管理するための資産台帳であり、掲載されていること自体は実行権限、identity、現在の可用性、安全性を保証しない。registry metadataとruntime、IAM、承認状態を別々に観測し、version・owner・identity・endpoint・lifecycleのdriftを継続的に照合する。
• EA · EA-046AI Gateway大全AI GatewayはAI trafficを共通のcontrol/enforcement pointへ集約する実装パターンとして扱う。単一の標準化済み製品カテゴリではない。共通Coreでは routing/fallback、provider/model abstraction、credential/auth boundary、rate/quota/budget control、AI-specific telemetry、policy h
• EA · EA-048Sandbox／Code Interpreter運用「AIによるコード実行は、モデル機能ではなくuntrusted workload executionとして管理する。container、gVisor型sandbox、microVMは隔離強度・互換性・運用コストが異なり、いずれも単独で完全な安全性を保証しない。Enterprise運用ではnetworkとsecretをdefault-denyにし、filesystem・syscall/device/capability・CPU/memor
• EA · EA-049Browser Agent専門編「Browser Agentは、Web APIがない／十分でない画面操作を自動化できる一方、ブラウザ制御protocolそのものはagentの意図・権限・安全性を保証しない。企業運用ではWebコンテンツを非信頼入力として扱い、session/credential、action policy、network・file境界、監査、最終業務状態の検証をモデル外の制御層に分離する。WebArenaやWorkArena等の成績は比較評価には使える
• EA · EA-050Desktop Agent／AI-RPA編「Desktop Agent／AI-RPAは、従来RPAをAIで置き換えた単一カテゴリではない。API、structured UI automation、vision/reasoning computer useは異なる失敗様式を持つ実行経路であり、同じidentity・policy・machine isolation・audit境界の下で使い分ける。GUI操作が可能であることは、業務ルール上正しいこと、権限上許可されること、再現可能で
• 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-054AI Kill Switch／Rollback設計「AIのKill Switchは、単一の『全停止ボタン』よりも、異常部分を最小単位で隔離し、必要に応じて全体停止へ拡大できる制御面として設計する方が実務的である。Rollbackにはknown-good revisionの保持とversion provenanceが必要だが、モデルやworkflowの切戻しは、既に外部世界へ生じた副作用を自動的に取り消すものではない。2026年時点で、model・prompt・workflow・tool
• EA · EA-055Agent Replay／Forensics「Agentのforensicsはtrace保存だけでは完成しない。後から因果列を再構成できるprovenanceと、外部副作用を隔離したcontrolled replayを分けて設計する。LLM・retrieval・外部toolを含む実行では、同じ入力から同じ出力が得られるとは限らないため、replayは『当時の事実の再構成』と『現在条件での再実行』を明確に区別する。」
• EA · EA-058Prompt／Instruction Configuration Management「Promptやsystem instructionは単なる文章ではなく、本番挙動を変える構成資産としてversion管理する。再現・監査に必要なのはprompt本文だけではなく、実行時に解決されたprompt revision、model、generation設定、tool/retrieval/policy等の組合せである。`production`のようなaliasは運用に便利だが、監査ログにはalias名だけでなく実際に参照したim
• 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-061AI向けData Classification「AI向けデータ分類は、従来の機密区分を捨ててAI専用ラベルへ置き換える作業ではない。既存の正式な分類を起点に、prompt、retrieval、tool、memory、output、logというAI固有のデータ移動面へ分類情報を伝播し、必要に応じて再検出・再評価する。自動検出結果は有力なsignalだが、完全な分類やcomplianceの証明ではない。classification、authorization、destination p
• EA · EA-062Data Residency／Sovereign AI「データレジデンシーは『リージョンを選べばすべてがその地域に留まる』という単一機能ではない。保存、推論、ルーティング、ログ、監視、バックアップ、検索/grounding、エージェント実行などで適用範囲が異なり、provider・model・deployment type・featureごとに確認が必要である。Sovereign AIはさらに法的管轄、運用統制、供給網、技術的自律性などを含み得るため、Data Residencyと同義に扱
• EA · EA-064AI Data／Memory Lifecycle専門編「Enterprise AIのmemory lifecycleは『覚える／忘れる』の二値ではない。session/raw event、派生summary、durable memory、revision、retrieval index、application state、logなどに別々のretentionとdelete semanticsが存在し得る。delete/resetを運用要件にする場合は、対象scopeとartifact、期待
• EA · EA-066Identity-aware／ACL-aware RAG「RAGで元データの権限を守るには、文書にACLを付けて保存するだけでは足りない。検索時の利用者を識別し、その時点で有効な権限と照合して、許可された文書・チャンクだけをLLMのコンテキストへ渡す必要がある。さらに、元データの権限変更が検索インデックスへ反映されるまでには遅延があり得るため、ACL同期の鮮度も認可状態の一部として監視する。『ログイン済み』『検索結果では非表示』『RAG対応』はいずれも、元データと同じアクセス境界が保たれてい
• EA · EA-067Knowledge Freshness Engineering「RAGの鮮度は、データソースの更新時刻やインデックス同期成功だけでは判定できない。更新・削除が検出され、検索可能な表現へ反映され、キャッシュや検索結果を経て、最終回答が新しい状態へ追随するまでの各段階を測定する。incremental sync、TTL、CDC、再indexはそのための手段であり、それぞれの製品・connectorが同じ反映保証を持つとは限らない。」
• EA · EA-069Knowledge Graph × LLM「Knowledge Graph/GraphRAGは、文書間のentity・relationshipを構造化し、vector similarityだけでは扱いにくいmulti-hopやcorpus-levelの探索を補完できる。ただしgraphがLLMから生成される場合、そのnode/edge/summaryは原典から派生した推論・索引artifactであり、正しさは自動保証されない。導入時はprovenance、ACL、freshne
• 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-072Vision／Video AI大全「Vision AIは単一能力ではない。OCR、検出、localization、caption、visual reasoning、retrieval、moderation、video temporal analysisを能力単位で評価し、model/API revisionとsource locatorを保持する。専用Vision APIのstructured detector outputとMLLMの自然言語理解は補完関係にあり、片方
• EA · EA-074Translation／Localization AI「企業向け翻訳AIは、モデルの一般翻訳品質だけで選ばない。用語資産の適用方式、言語ペア・modeごとの可用性、locale処理、監査可能なversioningを独立して確認する。TranslationとLocalizationは重なるが同一ではなく、自然な訳文が正しいlocale実装を保証するわけではない。」
• EA · EA-075Geospatial AI「Geospatial AIは、LLMに位置知識を持たせることではない。座標参照系、地物、道路網、時刻、移動制約、衛星・航空観測などの空間データを、専用の地理空間処理・最適化系とAI reasoningへ接続する運用領域である。AIの自然言語推論と、地図・経路・空間演算が返す検証可能な結果を分離し、source、CRS、time、resolution、constraints、provenanceを保持する。地理空間foundation
• EA · EA-077Classical ML × Generative AIclassifiers/regressors/forecast models remain independent prediction services; LLM handles interpretation, orchestration and explanation around typed outputs.
• EA · EA-078Solver／Rule Engine × LLMLLM-to-formalization/typed-input adapter plus deterministic solver/policy engine. Preserve solver status, constraint model, policy version, feasibility/optimality state and validation evidence.
• EA · EA-079Digital Twin × AI「Digital Twinは、AI Agentが現実の設備や運用へ作用する前に候補判断を仮想環境で検証するための一つの境界として利用できる。ただし、Digital Twinは現実そのものではない。安全性は、モデルに含まれる制約、状態の鮮度、校正、simulation engine、scenario変換の正しさに依存する。したがって『simulationで成功したから安全』ではなく、『どの状態・モデル・条件で何を試し、何が未検証か』を証跡
• EA · EA-080Synthetic Data編「Synthetic dataは実データへの直接アクセスを減らし、開発・試験・共有の選択肢を増やせる。ただし“synthetic”という生成由来だけでは匿名性やprivacyを保証しない。Enterprise運用では、生成器・source cohort・privacy mechanismをversion固定し、utility、downstream validity、privacy attack、fairnessを独立評価してreleas
• EA · EA-081Fine-tuning／Adapter／Distillation大全「モデル適応には、教師付きfine-tuning、LoRA等のparameter-efficient tuning、量子化併用PEFT、distillationなど異なる経路がある。これらは学習・配備artifactとfailure surfaceが異なるため、“カスタマイズ済み”を一括して扱わない。採用時はbase model、method、training data、artifact、evaluation、availabilityを
• 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-083Semantic／Prompt Cache“Prompt/context caching can reduce repeated-prefix processing cost and latency without reusing an old answer, while semantic response caching may skip inference by reusing an answer for a similar request. The latter ther
• EA · EA-084Batch AI“For non-urgent independent workloads, provider batch APIs can trade interactive latency for lower unit cost and higher bulk throughput. Treat batch as an asynchronous job system with explicit manifests, item IDs, reconc
• EA · EA-086Serverless AI Architecture「Serverless AIは、小規模・断続的・event-drivenなAI処理で常時稼働基盤を減らせる有力な実装形である。ただし実行時間、再試行、重複配送、quota、GPU/region、cold pathはproviderごとに異なる。外部side effectを伴う処理ではdurable stateとidempotencyを設計契約に含める。」
• EA · EA-088GPU／NPU Capacity Planning「GPU/NPU capacityは、acceleratorの公称性能やVRAMだけでは決まらない。モデルartifact、precision/quantization、contextとconcurrency、KV cache、runtime、parallelism、interconnect、SLAを固定した実測単位で設計する。公開benchmarkはhardware/software構成を比較する重要な入口だが、別workloadの性
• 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-093Quota／Rate-limit Engineering「Rate limitはエラー処理ではなくcapacity controlである。admission、queue、server hint、bounded retry、fallbackを一つの制御系として設計する。」
• EA · EA-102著作権・営業秘密・知財編「米国著作権局はAI出力の保護を人間の寄与に基づき事実ごとに判断する分析を示している。営業秘密は秘密性を維持する合理的努力を含む要件がある。日本での結論やprovider契約は別確認が必要。」
• EA · EA-107Enterprise AI成熟度モデル「NIST AI RMFとISO/IEC 42001はAIリスク管理・管理システムの基礎を与えるが、ここで示す成熟度段階はそれらの公式段階ではなく、本書の運用提案である。」
• EA · EA-108AI Center of Excellence運用論「AI CoEという名称・標準権限をNIST/ISOが直接定義しているわけではない。本書では、両者が示す組織的リスク管理・policy/process・継続改善を提供する運用モデルとしてCoEを提案する。」
• 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-116Coding Agent運用大全「GitHub Copilot cloud agentはtaskからrepository作業・PR作成へ接続でき、管理者有効化、repository opt-out、Actions minutes/AI credits等のgateを伴う。Code scanningは別の検出・SARIF/CodeQL層であり、agent生成コードの正しさ・安全性・license適合・merge可否を自動保証するものではない。」
• EA · EA-118Meeting AI Governance「Google Meet REST APIは会議spaceのaccess/moderation、録音・文字起こし設定、member/co-host、attendanceとartifact取得を扱う。これは会議AIの技術的control pointであり、参加者同意、法的適合、要約品質、tenantでの実効可用性を自動保証しない。Meet dataを性能評価へ用いない旨の公式注意もある。」
• EA · EA-119Voice Agent業務運用「Twilio Programmable Voiceの公式Docsは発着信、録音、transcription、AI agent/予約の実装入口を示す。これは音声業務の技術的control pointの証拠であり、本人確認、同意、ASR精度、予約成功、法的適合、human handoffを保証しない。」
• EA · EA-128Adversarial multi-LLM「Adversarial multi-LLMは、攻撃側LLMを用いて対象LLMの有害応答や漏えい等を探索する研究ベースの評価方式である。研究例はあるが、異種化だけで網羅性・安全性・企業tenantでの再現を保証しない。」
• 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-135CrewAI「CrewAI公式Docsは、agent/crew/flow、状態、guardrail、memory、observability等の実装要素を記載し、Enterprise項目としてconsole/RBAC/connectorsも案内している。実際の利用可否・権限・plan/region・安全性は機能ごとにゲート確認が必要で、Docsの機能存在は業務保証ではない。」
• EA · EA-136LlamaIndex Workflows「LlamaIndex Workflowsの公式Docsは、Pydantic event、型付きstep、実行・停止・timeout・streaming・context storeを使うworkflow構成を示している。型が検証されても、LLM出力の真偽、権限、安全な外部action、production性能は別途検証が必要である。」
• EA · EA-138Mastra「Mastraの現行Docsは、TypeScript上のagent・workflow・tool・memory・Studio・observabilityを案内している。これは実装要素の存在根拠であり、全provider・plan・regionでの利用可否、業務品質、権限安全性、production SLOの保証ではない。」
• 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-147Copilot Studio「Microsoft LearnのCopilot Studio overview（2026-08-22更新）は、agent・workflow・agent flow・connector・human reviewを一つのlow-code studioで組み合わせ、harness差による能力・課金差、analytics/evaluations、RBAC・cost管理を説明している。tenant・license・environment・conn
• EA · EA-148Google Workspace Studio「Google公式HelpはWorkspace Studioを、Geminiを用いてWorkspaceと一部の他アプリをstarter/step型flowで自動化する機能として説明している。管理者によるGemini有効化、edition・app access・approval・第三者データ共有の条件があり、add-onによるcustom step拡張は2026-09-03更新Docsでlimited previewである。実行品質・監査
• EA · EA-149UiPath agentic automation「UiPathの公式Agents Docsは、agentを確率的・適応的な判断系、RPA robotを決定論的な実行系として対比し、両者と人を組み合わせるagentic automationを説明している。公式Docsの現行導線にはMaestro、Studio Web、connectors、data residency、評価・trace系の項目があるが、製品・license・region・workspace・modelの可用性と実測安全
• 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-151Zapier AI／Agents「Zapierの公式Agentsページは、company knowledgeを与えたspecialized agentが複数appで作業し、activityを監視できる構成を示す。公式トップページにはmanaged connection、app/domain controls、RBAC/SCIM、audit API、log streaming等のenterprise機能が掲げられているが、plan・tenant・connection・実
• EA · EA-152Make「Makeの公式ページは、app・data source・AI modelをvisual/code/promptでつなぎ、AI agents・workflowsをMCP等で構築・管理するvisual automation platformとして説明している。security/complianceやintegration数は公式ページの現行訴求であり、plan・region・MCP・権限・実測品質・費用は別途確認が必要である。」
• EA · EA-153Workato「Workatoの公式Docsは、Agent Studio・enterprise skills・knowledge・guardrailsと、MCPのComposer/Registry/Gateway/Runtime、connectivity・identity・auditability・billing/usageを企業AIのcontrol/execution planeとして案内している。これは公開機能導線の確認であり、license・t
• 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-156Airflow／Dagster／Prefect「Airflow 3.3.1はschedule・task・dependency・retry・timeoutを持つDag実行、Dagsterはasset/lineage/observability中心のdata orchestration、Prefect 3はPython flowのstate・retry・timeout・deploymentを公式Docsで説明している。これらはAgentの確率的判断を支える非LLMの実行・データ制御面と
• 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-160OpenAPI／Function Calling「OpenAPI 3.1.0はHTTP APIの機械可読なインターフェース記述であり、function callingはproviderのモデルがアプリケーションへ外部処理の呼出しを要求する実行境界である。OpenAPIをfunction toolへ写像することは可能な設計選択だが、版・operation・schema・認証・実行結果・side effect policyを別途固定し、同一仕様とは扱わない。」
• 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-164LiteLLM「LiteLLMは、Python SDKとProxy Serverを通じて複数LLM providerを共通インターフェースへ寄せ、routing／retry／fallback、認証、ログ、guardrail、spend管理等を提供すると公式リポジトリで説明している。provider互換性、品質、価格、データ処理、fallback安全性はrelease・model・設定単位で再確認する。」
• EA · EA-165OpenRouter「OpenRouterは、複数model/providerへのAPIアクセスを一つのrequest形状へ寄せ、tool callingではproviderの実装に応じて透過・変換・YAML化を行うと文書化している。Auto Routerのallow／exclude／cost tier等はroute制御であり、モデル品質・価格上限・データ境界・SLOの保証ではない。」
• EA · EA-166AI Gateway群「AI Gateway群は、複数providerへの接続を集約し、routing／fallback、認証、rate limit、logging、cost、cache、policy等を実装するcontrol-plane群である。LiteLLM、OpenRouter、Vercel、Cloudflareの公式資料は機能境界が異なるため、共通機能と製品固有の実装・契約・版・地域・設定を分離して評価する。」
• 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-216OSS OCRスタック比較OCRは文字認識、layout・表処理、PDF再生成の役割を分けて選定します。文字の存在だけで読み順や数値を正しいと判断せず、モデルと設定を固定し、業務素材のgoldenへ照合します。
• EA · EA-218ElevenLabs Audio／Voice AgentsElevenLabsのTTS・STT・dubbing・sound・Voice Agentはmodelと製品ごとに評価し、接続権限、声素材の権利、商用条件、再生と保持を分ける。
• EA · EA-220Telephony API × Voice Agent電話向けVoice Agentでは、番号・SIP・call leg/media stream、providerごとのcodec、実再生/破棄、認証、human handoffをAIモデルから分けて確認する。
• EA · EA-685Coding AgentのDependency Hallucination／Slopsquatting防御AIが生成した依存パッケージ名は導入候補として扱います。存在確認、正常なhash、provenance、既知脆弱性scanのいずれも単独では安全性を保証しません。導入前の承認identityと、実際に取得するartifactのidentity・bytesを結び付けて確認する運用が必要です。この運用は設計上の提案であり、特定製品の防御率を実証したものではありません。
• EA · EA-239Content Safety／Moderation Model・APIContent Safety／Moderation APIは、入力や出力を「安全／危険」と最終決定する認可機構ではありません。特定のモデル、taxonomy、threshold、対応modalitiesと言語の下で、ポリシー判断に使う分類信号を返す部品です。組織側では、この信号をどの条件でblock、allow、transform、human reviewへ接続するかを別に定義します。
• EA · EA-001個人版／法人版クロスウォーク — plan/organization/modeをデータ保護・保持・管理権限・利用可能性・課金/上限・高度機能の条件に分解して比較する。「個人向けと法人向けAIの差は、使えるモデルや機能の数だけでは決まらない。データが学習に使われる既定値、保持・削除、管理者権限、接続先の認可、契約ごとの課金方式、管理対象ID、地域や段階的ロールアウトまでを分けて確認する。同じ製品名・同じモデル名でも、実際に使える能力やデータ境界はaccount、workspace、contract、mode、regionによって変わり得る。」
• 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-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-235Policy Engine実装：OPA／CedarAgentのauthorizationをmodel instructionへ委ねません。OPA/RegoやCedarなどのPolicy Engineは、AIの外側でtool/action実行前にdecisionを行い、application/tool gatewayがそのdecisionを強制する構成で使用します。
• 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-011Enterprise AIベンチマーク実験室Enterprise AIの評価は、公開leaderboardの単一scoreやmodel単体の比較だけで受入可否を決めず、実際に使うmodel・prompt・retrieval・tools・permissions・runtime・agent scaffoldを含む **System Under Test (SUT)** を、再現可能なfixtureとversion固定したgraderで測る。agentでは最終結果だけでなく、tool
• EA · EA-1010Prompt CacheをAI運用へ組み込む境界Prompt CacheはLLM入力prefixの再処理を減らし、latencyとinput costを改善し得るoptimization layerです。ただし、cache hitは会話memory、正本、監査証跡、同一出力の保証ではありません。cache missやexpiryが発生しても業務が正しく動く設計を基準にしてください。
• EA · EA-1201Explainability／Interpretability／Explanation Fidelity「AIが判断理由を説明できる」と一括して表現せず、「特定の説明手法により、定義された対象・参照条件の下でモデル挙動の一部を説明または近似できる。説明の忠実性、安定性、理解可能性、適用範囲は別途検証が必要」と記述します。
• EA · EA-1203Predictive ML／Classical MLOps Production Lifecycle「定期的に再学習すればモデル劣化を防げる」「feature storeを使えばleakageはなくなる」「driftを検知すれば精度低下が分かる」と一般化しません。
• EA · EA-1205Model Privacy Attack Evaluation／Membership Inference／Inversion／Extraction学習済みAIモデルは、通常の推論APIとして提供されていても、学習データへの参加有無を推定するmembership inference、学習データの属性・代表情報を推定するmodel inversion/reconstruction、target modelの機能や知的財産を複製するmodel extraction/model theftの対象になり得る。これらは目的・必要アクセス・成功指標が異なるため、同じ「情報漏えい」として一括評価
• EA · EA-1208AI Supplier Warranty／Indemnity／Liability Allocation「ベンダーがAI出力を保証する」「著作権侵害はすべてベンダー負担」「enterprise契約なので責任はベンダーへ移転済み」と一般化しない。
• 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-1213Llama Open-weight Model-family Operating Profile「Llamaはオープンソースなので自由に使える」「Llama 4なら10M context」「self-hostすれば自動的にデータは外へ出ない」と一般化しない。
• 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-1215NotebookLM Workspace／Source／Sharing／Grounding Operating Profile「NotebookLMはsourceだけを使うのでhallucinationしない」「citationがあるので検証済み」「Chat Viewならsourceは見えない」とは記述しない。「指定したNotebook/source set/account surfaceでgrounded outputを生成し、重要claimはcitation passageと原sourceをreadbackして検証する。sharing、sync、priva
• EA · EA-172BraintrustBraintrustは、生成AI／エージェントの実験・評価と本番トレースを接続し、品質、失敗、コスト、レイテンシ等を継続的に検証するための運用基盤として利用できる。導入効果は、評価設計、計装範囲、データ境界、tenant／plan設定、組織固有の運用統制に依存するため、製品機能の存在を品質保証やコンプライアンス保証へ外挿してはならない。
• EA · EA-174MLflow：Tracking・Tracing・Registry・artifact accessを別の運用境界として管理するMLflowはTracking、Registry、Tracing等を統合できるが、運用上はTracking Server、backend store、artifact store、authentication/authorization、trace export、model promotionを別の境界として管理する。artifact access方式やtrace export先によってcredential/data boundaryが
• EA · EA-176DeepEvalDeepEvalは、LLM/AIアプリをtest case・dataset・metric・traceに基づいて評価し、pytest/CIへ組み込めるlocal-firstのOSS evaluation frameworkである。end-to-end、trajectory、componentなど複数scopeを扱えるが、多くのmetricはLLM-as-a-judgeであり、pass/failは固定したdataset・metric・jud
• EA · EA-178Inspect AIInspect AIはmodelやagentをtask、solver、scorer等の構成で評価するframeworkである。実行結果を読む際は正誤、実行error、採点不能を区別し、得点とcoverageを併記する。frameworkと評価task集のrevisionも区別して保存する。
• EA · EA-179HELM — Enterprise AI運用での評価・再現性境界HELMはStanford CRFMのfoundation-model評価frameworkで、scenario・model interface・metric・artifactを標準化し複数leaderboardを再現可能に扱います。ただし単一の普遍的HELM scoreはなく、結果はsuite・scenario・dataset revision・model/provider ID・prompt/adaptation・metric・HE
• 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-229WhatsApp／SMS Business Messaging × Agent「エージェントはWhatsApp/SMS送信を実行できるが、送信APIの成功は配送・閲覧・業務成果を保証しない。会話window、template eligibility、同意・停止、重複防止、provider-side identifier、非同期status、reconciliationを独立した制御として実装し、チャネル・契約・地域固有の条件を実環境で確認する。」
• EA · EA-231Object StorageをAI正本層にするObject Storage can serve as the canonical byte/evidence layer for AI workflows when the design binds each important artifact to an immutable version identity and content digest, uses provider-supported conditional writes
• EA · EA-250AIが使うデータの契約とスキーマ変更を管理するデータ契約は、作る側と使う側が、項目、型、意味、品質、更新、権限、変更手順を共有する約束です。AIが入力をそれらしく解釈しても、契約違反が直ったことにはなりません。項目名や型の互換性と、金額・時刻・対象集団等の意味の互換性を分け、変更の影響を検索、prompt、tool、評価データまで追います。
• EA · EA-257Confidential Computing／TEE × AIConfidential Computing／TEEは、定義したthreat modelの範囲でAI workloadのdata-in-useと実行環境をhost/operatorから隔離し、remote attestationをsecret/key releaseの条件にできます。 ただし、TEEやattestation PASSだけでapplication code、GPU、side channel、availability、pro
• EA · EA-260API ManagementをAgent Tool層に置くAgentからtool APIへ到達する経路にAPI Management/API Gatewayを置くと、認証、公開route/tool、rate/quota、protocol/schema、監査を集中しやすくなります。
• 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-271AI SLO／Error Budget運用AI/Agentの信頼性運用では、単一の「成功率」やprovider uptimeをSLOと同一視せず、利用者が経験するcritical journeyごとにSLI、SLO target、budgeting method、window、error-budget policyを固定します。error budgetは観測された失敗を許容する枠であり、品質保証や免責ではありません。
• EA · EA-272Model／Tool Health Check設計「health checkが成功した」は、そのprobeが定義した時点・地点・契約を満たしたことだけを意味する。モデル品質、全tool、全tenant、end-to-end業務成功、将来の可用性を保証しない。
• EA · EA-273AI Change Freeze／Maintenance WindowChange freezeは選択した変更リスクを減らす統制であり、信頼性や完全なimmutabilityを保証しません。freeze、maintenance window、emergency exceptionを別の監査可能な状態として管理し、AI固有のchange surfaceを列挙して、変更後はauthoritative stateとbehaviorをreadbackします。
• EA · EA-276AI Restore Drill／Disaster Recovery ExerciseDR drillは復旧手順を検証する証拠であり、将来の災害時成功を保証しません。AIシステムではinfra起動だけでなく、複数stateの整合性、model/tool/retrieval/policyを含むcritical journey、副作用隔離、failback/reprotectを検証し、観測したRTO/RPOと未検証条件を残します。
• EA · EA-279Consent／Purpose Limitation × AI Data Use「AIで個人データを使えるかは、同意の有無だけでは決まらない。目的、処理段階、法的根拠、再利用互換性、通知、権利処理を法域と実装境界ごとに確認し、承認済みpurposeをruntimeのdata-flow gateへ投影する。UNKNOWNを同意済み・互換ありと推測しない。」
• EA · EA-280Retention Policy for AI Conversations／Artifacts「保存先と派生先ごとに保持・利用停止・削除・確認の条件を定め、実行証拠を残す」。一方、「学習に使われないので保存もされない」「応答を消したので全派生物も消えた」「30日なら全製品・全契約で適合」とはしない。
• EA · EA-326モデル評価設計モデル評価は、対象modelだけでなくdataset、slice、metric、judge、baseline、run configurationをversion固定して比較する。全体平均だけで合否を決めず、重大sliceの回帰を独立して確認する。providerの評価サービスは実行基盤であり、組織固有の安全性や適合性を自動的に証明するものではない。
• EA · EA-399AI Quality Degradation Detection／品質劣化検知「drift detectorが反応したのでモデル品質が低下した」「eval scoreが維持されているので本番品質は安全」とは表現しません。安全な表現は、「固定回帰評価とfresh production sample、segment別品質、安全性、業務KPI、latency/cost、変更履歴を継続監視し、複数signalとreadbackで劣化候補を検出する。検出後はmodelだけでなくprompt、retrieval、tool、p
• EA · EA-440障害時フォールバック階層Enterprise AIのフォールバックは「失敗したら別モデルへ送る」だけでは成立しません。障害の種類を判定し、再試行、別capacity/deployment、別region、別provider/model、機能縮退、durable queueまたは人手移管を、品質・データ所在・権限・副作用の制約付きで順序化します。
• EA · EA-475AI PC・NPUの調達判断AI PCやNPUの調達は、公称演算性能や「AI対応」という表示だけでは判断できません。対象アプリケーション、モデル、精度形式、入力長、同時実行、OS、runtime、ドライバ、実行プロバイダの組を固定し、実際の処理先、品質、応答時間、消費電力、メモリ、保守条件を確認して選びます。NPUが搭載されていること、利用可能であること、選択したこと、対象処理がNPUで実行されたことは異なります。
• EA · EA-476通信断を前提にしたAI運用Offline-First AI Operationsは、ネットワークが切れてもモデルを実行できることだけを意味しません。通信断中に利用できるモデル・データ・権限・保存容量を明確にし、古い情報で許してよい処理と停止すべき処理を分け、再接続後に権限と状態を照合してから外部への変更を解放する運用です。推論の継続、業務行為の許可、キューの配送、外部状態の整合は別の成立条件です。
• EA · EA-480Insurance AI Operating Model／保険AI運用モデル保険AIの運用モデルは、一般AIガバナンスを共通controlとして再利用しつつ、保険法令、consumer outcome、use-case別risk、third-party model accountability、decision/appeal/correction evidence、regulatory examination evidenceをjurisdiction別のsector overlayとして統合する。具体的な義務
• EA · EA-500Agentの能力契約を検証するAgentが能力を公開していることと、その能力を利用者の期待どおりに実行できることは別です。能力契約の検証では、宣言、入出力schema、protocolと版、認証・認可、呼出し状態、業務上の効果を分けて確認します。同じ名前のskillやtool、同じJSON構造だけから、取消、重複実行、失敗、完了の意味まで同じと推定しません。
• 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-505Retry Storm / Circuit Breaker / Nested Retry Budget Composition「agentのrequest_limitだけでproviderへの総attempt数が保証される」とは表現しません。「retryを完全に排除すべき」とも表現しません。公開可能な主張は、複数層のretryは負荷を増幅し得るため、retry domainを列挙し、観測可能な層ごとにownerと有限budgetを定め、重複retryを抑制し、backoff/jitter、breaker/backpressure、attempt telemet
• EA · EA-506リース失効・タイムアウト・キャンセル後に残る「ゾンビ外部操作」をどう封じるかリース失効・heartbeat timeout・キャンセルは、スケジューラ上の所有権や待機を終わらせるための制御であり、旧実行主体の停止や既送信の外部副作用の取消しを一般には保証しない。可能な対象では単調なgeneration/fencing tokenをmutation境界で原子的に検証し、対応しない外部副作用ではstable operation identity、providerのdocumented idempotency、結果r
• EA · EA-517情報区分に応じたAIメモリの保持期限とTTLAIメモリの保持は、すべての記憶へ同じTTLを付けるだけでは管理できません。情報区分、利用目的、元データの版、保持の根拠、起算点、派生物、保持例外を対応させ、期限到達、提供停止、削除指示、実削除、backupの失効を分けて確認します。TTLは製品の削除・失効機構であり、組織が定める保持要件全体と同じものではありません。
• EA · EA-519プロバイダー間で能力契約と意味の同等性を確認するモデルやAPIを切り替える際、toolの名前とJSONの形を揃えるだけでは、同じ仕事を同じ条件で実行できると証明できません。プロバイダーをまたぐ能力契約では、呼出しと結果の対応、実行主体、入出力の意味、権限、終了・失敗、再試行、外部効果を明示し、対応できない差を失わずに扱います。意味の同等性は、対象操作・版・入力範囲・観測条件を指定した検証結果として記録します。
• EA · EA-520Effective Instruction Contract Envelope「system instructionを設定した」ことと「そのinstructionが実行時に常に強制された」ことを同一視しない。監査可能なのは、組織が管理するinstruction revision、観測可能なprovider/model/runtime/configuration、明示したcomposition、指定した評価条件で得たbehavioral evidenceである。hidden provider instruction
• EA · EA-521Cross-provider Schema Loss Accounting Envelope「Structured Outputsを使えばJSON Schemaどおりになる」「三providerで同じschemaを使える」とは表現しない。安全な表現は、「各providerのdocumented subsetと実効strictnessをversion付きで確認し、canonical schemaからprovider schemaへの変換差分を記録し、生成後にcanonical constraintを再検証する。表現不能な重要co
• EA · EA-526自動化の例外処理が人の処理能力を超えないように設計するAIが処理できなかった仕事を人へ送れば、安全に運用できるとは限りません。人へ渡る件数、難しさ、再処理、担当者の空き時間を合わせて測り、受付量を制御する必要があります。自動化の成功率が上がっても、元の仕事量が増えたり、難しい案件だけが残ったりすると、人の待ち行列は増えます。例外処理の負荷モデルは、この出口の容量を見積もり、期限超過・見落とし・形式的な承認を防ぐための設計です。
• EA · EA-683Evaluation Set Aging / Refresh / Contamination“Benchmark scores are versioned observations, not timeless model properties. Preserve benchmark-release, item/scorer/harness provenance and inference conditions. A refresh or item correction starts a new comparison revis
• EA · EA-684Stochastic Reproducibility／Nondeterminism Budget「seed固定により再現可能」と一般化しない。「特定runtime・version・hardware・scheduler等の前提を固定した範囲で再現性を高められる」「完全一致が契約できない系では反復分布と許容差を管理する」と記述する。
• EA · EA-732AI compliance obligation→machine-readable control mapping「machine-readable mappingは追跡・差分検出・評価連携を支援するが、mappingまたはOSCAL schema conformanceだけで法令・契約への準拠を証明するものではない。」
• EA · EA-733Provider障害シグナルをAIルーティングへ安全に使う「公開statusを自動fallbackの唯一の根拠にする」のではなく、「公開status、利用組織に関連するhealth signal、自前telemetry/probeをscope付きで統合し、hysteresisと段階的failbackを伴うrouting policyへ入力する」と表現する。provider statusが正常であることは個別tenantの正常性を保証しない。
• EA · EA-734Versioned evaluation datasets and reproducible PoV→production gates「versioned evaluation datasetを使えば本番品質が保証される」とは書きません。安全な表現は、「評価データ、対象構成、評価器、閾値、実行条件を版管理し、同じ判定手順を再実行できる状態を作ることで、PoVから本番昇格までの判断を追跡・比較しやすくする」です。再現性は評価手続の再実行可能性を指し、provider内部状態や確率的出力の完全同一を保証しません。
• EA · EA-738AI評価の昇格判定に統計的信頼性ゲートを入れる「候補モデルの平均スコアが高い」だけでは昇格根拠として弱い。比較対象と評価単位を固定し、差の大きさと不確実性を示し、事前定義した実用上の最小差および安全性の非交渉条件を満たしたときに昇格させる。信頼区間や有意差は本番性能の保証ではなく、定義した評価設計の下で観測差をどこまで信頼できるかを判断する材料である。
• EA · EA-750Spot/preemptible GPUの中断前提設計とcheckpoint経済性「Spot/preemptible GPUは中断と再取得待ちを通常系として設計し、周期checkpointを主手段、provider通知をbest-effortの追加退避signalとして扱う。採否は時間単価だけでなく、失われるcompute、checkpoint I/O、restart/reload、capacity再取得、fallback、期限リスクを含む実効費用で判断する。」
• EA · EA-798非同期Batch inferenceを独立execution tierとして設計する運用非対話・大量のLLM推論は、同期APIとは別の非同期Batch execution tierとして管理できる。Batchは低価格・高throughputに向く一方、queue、partial failure、expiry、cancellation、retry、result reconciliationを伴う。submit成功を処理完了とみなさず、immutable input manifest、provider job ID、reque
• EA · CORE-01状態を持つAIの運用契約この章の仕事は、LLMを「会話を返すもの」から「状態を持つ業務に参加するもの」へ移すときに必要な最小契約を定義することである。
• EA · CORE-02検索・記憶・出典の対応付けこの章は、「モデルへ入れられる量」「必要根拠を見つける能力」「見つけた根拠を使う能力」「sourceに忠実な生成」「sessionを越えて保持されるmemory/state」を分離し、企業AIのsource利用を検証可能な契約にする。
• 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 · CORE-07評価データと公開前の評価契約CORE-07は、候補configurationを本番投入前に何に対して、どの証拠で、どのsliceごとに合否判定したかを再構成できる評価契約を定義する。単一benchmark、平均score、model名、judgeの自然文だけをrelease根拠にしない。
• 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-02CLAUDE：検索・記憶・出典の対応付けCORE-02のpermission-aware retrieval、memory lifecycle、source binding、bounded long-context反証をClaudeの現行公開surfaceへ対応づける。Claude enterprise search／connectors、Messages APIのsearch-result・citations・Files、MCP connector、client-side
• 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-CLAUDE-CORE-07CLAUDE：評価データと公開前の評価契約CORE-07のdataset、scorer/judge、holdout、slice gate、release evidenceを、Anthropicの評価設計guidance、Console prompt improver/evaluator、Message Batches、structured outputs、Agent SDK/Claude Codeおよびauthor-maintained cookbookへ対応づける。公開仕様・
• EA · PM-GEMINI-CORE-02GEMINI：検索・記憶・出典の対応付けこの文書は、CORE-02で閉じていないprovider実装・provider実機残差をGemini用のProduct Mappingへ渡すための境界票である。ここで仕様意図、OSS版、issue観測をGemini製品の安全性・可用性・tenant実測へ昇格させない。Q-C02-001/002とAUD-C02-008の残差だけを扱い、新テーマは追加しない。
• 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-01OpenAI / GPT：状態を持つAIの運用契約This mapping binds the provider's response, conversation, background execution, webhook, Agents SDK session, result, and RunState surfaces to CORE-01. It does not treat provider persistence as the authoritative business
• EA · PM-GPT-CORE-03OpenAI / GPT：タスク分解と処理工程CORE-03のstage、artifact、handoff、parallel/serial、resume/retry、verification、transaction境界を、OpenAI APIとOpenAI Agents SDKの現行公開surfaceへ対応づける。ChatGPT会話、Responses API、Conversations API、Agents SDK、application-owned workflowを同一run
• 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-GPT-CORE-06OpenAI / GPT：プロンプトと設定の管理CORE-06のconfiguration bundle、version/approval lineage、environment diff、canary/rollback契約をOpenAI APIとAgents SDKへ対応づける。対象はResponses APIのinput/instructions、廃止予定のreusable prompt objects、Agents SDK v0.22.0のPrompt/Agent/RunCon
• EA · PM-GPT-CORE-07OpenAI / GPT：評価データと公開前の評価契約CORE-07のgolden dataset、holdout、scorer/judge registry、slice-level AND gate、release/rollback evidenceをOpenAIのDatasets、Evals、Graders、Agent evals、Prompt optimizerおよびopenai/evals OSSへ対応づける。公開仕様と固定OSSだけを対象とし、実tenant、非公開dataset
• 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-02GROK：検索・記憶・出典の対応付けThis mapping binds xAI Collections, Collections Search, Files and ZDR to the existing CORE-02 contract. It does not treat collection membership, an API-key permission, an application-supplied metadata filter, a citation
• 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-04GROK：モデル・ツール・情報源・状態の選択CORE-04のmodel / tool / source / state routing、fallback、service capacity、cost/error observability契約をxAI APIへ対応づける。model alias/date pin、retired-slug redirect、search/tool、Priority/Default、rate limit、online/deferred/Batch、SD
• 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 · PM-GROK-CORE-07GROK：評価データと公開前の評価契約CORE-07のgolden dataset、scorer/judge、holdout、slice/tail gate、release evidenceを、Grok 4.6 announcement/model card、xAI APIのBatch/structured-output/model identity、author-maintained Grok Build、独立benchmark methodologyへ対応づける。公開b
• EA · ORG-CORE-02組織での適用：検索・記憶・出典の対応付けこの票は、組織・tenant・契約・管理設定・実測値をEnterprise AI CoreやGemini Product Mappingへ混入させないための空の受け皿である。未提供の値を既定値、製品仕様、匿名報告から補完しない。
• 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 · PROVENANCE_POLICY出典の来歴と根拠の扱い本辞典は、チャット本文、S001〜S063、packet、registerを、それだけで外部知識の原典とは扱わない。これらは編纂容器・研究記録・中間成果物になり得る。外部情報を含むclaimは、容器を越えて原著者・原組織・原資料まで遡れることを公開条件とする。
• 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
• EA · INTEGRATION_READINESS_AUDIT統合時の整合性と残る制約INTEGRATION_READINESS_AUDIT-INT-022: final gate census grants CONDITIONAL_CLEARANCE_FOR_ASSEMBLY. IR-001/002/005/006/007/008 are closed or non-blocking under their existing canonical-input and layer-separation controls.
• EA · PUBLICATION_GATE_CENSUS公開判定と未解決事項APPROVED_FOR_PUBLICATION_WITH_DISCLOSED_RESIDUALS