守る

権限・安全性・管理を確認する

300件の公開項目

• EA · EA-012AI製品「公称能力 vs 実効能力」辞典「ベンダーが公称する能力は、モデルまたはサービスが対応する技術的範囲を示す。特定組織での実効能力は、製品面、契約・plan、地域、管理設定、identity/permission、tool/data、runtime capacity、quota/cost、業務受入試験を通過した範囲に限る。」
• EA · EA-013AI失敗事例・事故解剖大全AI事故はモデルが誤った瞬間だけを指すものではない。業務上の事故は、モデル・データ・ツール・製品制御・人間確認・通常のソフトウェア基盤の複数層を通って成立する。公開事例は各製品の現在の失敗率を示すものではなく、どの防護線が必要かを学ぶための事例として扱う。
• 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-015AI監査・証跡設計大全AIシステムの監査可能性は、単一ログの有無ではなく、control/admin、identity/auth、data/retrieval、model request/result、tool/action、human approval/override、artifact/config/model provenance の各planeを横断して、業務上必要な事象を再構成できることとして扱う。
• EA · EA-016AI評価・Evals実践編EvalsはAIの「点数表」ではなく、業務上の成功条件を実行可能なテストへ変換し、変更による改善と回帰を検知する運用機構として扱う。生成AIやagentでは最終発話だけでなく、成果物、環境state、tool side effect、権限違反を評価する。Golden setは固定された万能正解集ではなく、provenance、version、coverage、criticalityを持つliving artifactとして管理する。高い
• 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-020AIアーキテクチャ・パターン集AIアーキテクチャは、Single-agentかMulti-agentかという一問だけでは決まらない。制御を誰が握るか、状態と知識をどこに置くか、外部ツールをどの境界から呼ぶか、同期・非同期・batchのどの実行形態を使うか、人間承認と復旧をどこに置くかを分けて設計する。
• EA · EA-021AIアンチパターン集AIアンチパターンは、特定技術を使うこと自体ではなく、有効な技術を責務や適用条件を無視して万能化するところから生じる。長いコンテキスト、RAG、Agent、会話memoryはいずれも有用だが、正本、権限、状態、検証、復旧まで一つの層へ背負わせると、性能・安全性・監査性・費用のどこかで破綻しやすい。技術名ではなく、責務分離と失敗包絡で診断する。
• 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-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-027業界別版業界別AI運用は、共通のAI統制を業界ごとに作り直すことではない。共通Coreの上に、適用法令・規制主体、保護データ、用途、意思決定や物理的影響、専門家監督、変更管理、証跡をIndustry Profileとして重ねる。同じ医療・金融・教育という名称でも、組織の法的地位、地域、データ、用途によって必要な統制は変わるため、業界名だけで可否やリスクを決めない。
• EA · EA-028AI教育・社内導入カリキュラム社内AI教育は、全員へ同じ製品操作を教えるだけでは不十分である。共通Coreを維持しつつ、利用者のrole、technical knowledge、扱うdata、task impact、利用するsystemに応じて学習到達点を分ける。受講完了と安全に業務利用できる能力は分離し、知識問題だけでなくsafe/unsafe input判別、source verification、confidential-data handling、exter
• EA · EA-029Enterprise AI運用テンプレート集運用テンプレートはAI統制を自動的に成立させるものではなく、判断・証拠・変更・未解決事項を再現可能に残すための器である。共通Coreを用意しつつ、法域・業界・組織・providerに応じて項目をtailorする。PASS/完了の記入だけでなく、根拠となるsource、eval、承認、readbackを結び付ける。
• 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-034Knowledge／RAG工学専門編Enterprise RAGは検索機能ではなく、権限付き知識の派生物を継続的に生成・検索・検証・削除するライフサイクルとして扱う。検索品質、権限、鮮度、根拠提示、安全性は別々に測定する。RAGが回答へ根拠を与えても、取得漏れ、古いindex、権限同期遅延、poisoned knowledge、unsupported synthesisは残り得るため、retriever・generator・citation・lifecycleを分離して評
• 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-040Enterprise AI Coreそのものの標準化「Enterprise AI Core」は既存の単一国際標準の名称ではなく、本辞典がベンダー中立の運用比較面として定義するprofileである。ISO/IEC 22989・23053・42001、NIST AI RMF/GAI Profile、TEVV資源、OpenTelemetry等の既存標準・枠組みを置換せず、能力・境界・状態・証拠・統制・ライフサイクルをcrosswalkする。provider固有機能とtenant実挙動は別レイヤ
• EA · EA-041AI Control Plane大全AI Control Plane大全
• 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-044Delegated AuthorizationDelegated Authorization
• 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-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-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-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-052AgentOps／AI-SRE“AgentOps/AI-SRE is best treated as conventional SRE extended with AI-specific outcome and trajectory measurements. Availability and latency remain necessary but are insufficient: production agents also need task/end-sta
• 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-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-057Shadow AI発見編「Shadow AIの発見は、未承認AIを一度のスキャンで完全列挙する機能ではない。SSE/CASB、endpoint/process、browser/IDE、cloud/SaaS/API auditなど複数の観測面から“観測された利用”を集め、承認台帳と突合して初めて運用上のShadow AI inventoryになる。アプリへの通信観測、実際のprompt内容観測、機密データ露出の確認は別の証拠レベルとして扱う。」
• EA · EA-058Prompt／Instruction Configuration Management「Promptやsystem instructionは単なる文章ではなく、本番挙動を変える構成資産としてversion管理する。再現・監査に必要なのはprompt本文だけではなく、実行時に解決されたprompt revision、model、generation設定、tool/retrieval/policy等の組合せである。`production`のようなaliasは運用に便利だが、監査ログにはalias名だけでなく実際に参照したim
• 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-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-063AI Privacy Engineering「AIのプライバシー対策は、PIIを見つけて黒塗りすることだけではない。まず業務目的に不要な個人情報を取得・検索・転送・保持しない。必要な情報には、検出、仮名化、削除、暗号化などを目的に応じて使い分ける。『検出されなかった』『anonymizeという関数を通した』ことだけで匿名化済みとは判断できない。識別可能性は周辺情報や復元鍵、外部データとの結合でも変わるため、入力、RAG、tool、memory、出力、ログまで処理面ごとに確認する必
• 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-065AI × Records Management／eDiscovery「AI会話・生成物・Agent実行は、AIで生成されたという理由だけで一律に記録または廃棄対象になるわけではない。記録性は組織の業務・法令・保存方針に従ってartifact単位で判断し、legal holdやeDiscoveryでは、会話、memory、監査ログ、成果物などの実際の保存先を把握して保全・検索・export範囲を確認する。ユーザー画面からの削除、検索不能、provider側retention終了は同じ事象ではない。製品のc
• 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-068Semantic Layer × AI「Enterprise AIの分析では、LLMを生のデータベースschemaへ直接接続するより、組織が定義したmetrics・dimensions・relationships・access rulesを持つsemantic layerを介在させると、AIが推測しなければならない業務意味を減らし、定義をversion管理・監査・評価しやすくできる。これは回答正確性の保証ではない。semantic model自体の誤り・不足・陳腐化、権限設
• 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-073Forms／Handwriting／Barcode AI「紙帳票をAIへ取り込む処理はOCRだけではない。文字認識、キーと値の対応、チェック状態、手書き判定、バーコード形式とpayload復号を別々に検証する必要がある。読み取れた文字やQRコードは、それだけで業務上の真正性や安全性を保証しない。原画像と抽出結果のprovenanceを保持し、正規化・検証・認可・必要な人手確認を後段に置く。」
• EA · EA-074Translation／Localization AI「企業向け翻訳AIは、モデルの一般翻訳品質だけで選ばない。用語資産の適用方式、言語ペア・modeごとの可用性、locale処理、監査可能なversioningを独立して確認する。TranslationとLocalizationは重なるが同一ではなく、自然な訳文が正しいlocale実装を保証するわけではない。」
• 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-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-087Kubernetes／Private AI「KubernetesはPrivate AIの共通control planeになり得、KServe等によりLLMを含むmodel servingを構成できる。ただしGPU driver/device plugin、network enforcement、model/runtime互換性、capacity、patching、observabilityは組織側の責任となる。『private』は配置場所ではなく、identity・networ
• 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-090Air-gapped AI「Air-gapped AIは、モデルを一度持ち込んでネットワークを切れば完成するものではない。閉域内で推論・RAGを実行できることに加え、モデル、コンテナ、依存package、データ、脆弱性情報を検証付きで持ち込み、内部repositoryから更新・rollback・監査できる供給線が必要である。物理mediaは更新経路であると同時にattack surfaceでもある。」
• 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-093Quota／Rate-limit Engineering「Rate limitはエラー処理ではなくcapacity controlである。admission、queue、server hint、bounded retry、fallbackを一つの制御系として設計する。」
• EA · EA-094AI Latency／SLO工学「AI性能はtokens/secだけでは測れない。利用者が必要な結果を得るまでのjourneyをSLO化し、queue・retrieval・model・tool・retry・approvalを分解してtail latencyを管理する。」
• 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-096Process Mining → AI化「Process Miningは、情報システムに残るevent dataから実際に実行されたprocessの経路・逸脱・性能を分析し、AI化候補を経験則だけで選ばないための観測基盤になり得る。ただしevent logは業務全体の完全な写像ではなく、発見された頻出経路やbottleneckだけからAI導入の妥当性・因果効果を結論してはならない。multi-object業務ではcase-centric flatteningの歪みも評価する。
• 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-098Human-AI Interaction設計 — confidence、根拠表示、訂正、承認、undo等のAI特有UIを、能力限界・不確実性・可逆性・人間統制の観点から設計する。「AI特有のUIでは、結果を見せるだけでなく、何ができるか・何を根拠にしたか・どこに不確実性があるか・誤ったときにどう訂正/却下/復旧できるかを設計する。confidenceは正答確率とは限らず、根拠表示も正しさの保証ではない。外部作用を伴うAgentでは、承認対象を固定し、実行後のundoまたは補償手段まで含めて人間統制を設計する。」
• EA · EA-099Accessibility / Inclusive AI — AI出力・AI操作面を障害特性／支援技術／代替表現／訂正可能性まで含めて設計・検証する「AIはcaption、alt text、音声・テキスト変換などを通じてaccessibilityを拡張できるが、自動生成された代替表現の存在だけではaccessibleとは言えない。基礎UIのaccessibility、assistive-technology interoperability、AI生成内容の意味的品質、利用者による訂正・選択・fallbackを分離して検証し、障害当事者を含む実利用評価で確認する。」
• EA · EA-100日本語・日本業務特有のAI問題 — 敬語、縦書き、和暦、帳票、住所、人名、表記揺れ、日本語OCRを「日本語対応」の一語で潰さず、業務データ型・文書レイアウト・文字体系・社会言語的適切性ごとに検証する「日本語を生成できることと、日本の業務データを正確に処理できることは別である。住所の表記揺れ、人名の異体字、縦書きや帳票レイアウト、和暦、敬語などは独立した失敗条件を持つ。重要項目は生成モデルのもっともらしさだけで確定せず、公的・業務上の参照データ、決定的な変換規則、文書種別ごとの評価、人による訂正を組み合わせる。」
• EA · EA-101AI規制・標準Crosswalk「NIST AI RMF、ISO/IEC 42001、EU AI ActはAIリスク管理に関係するが、任意フレームワーク、管理システム規格、法令であり、相互に同等ではない。」
• EA · EA-102著作権・営業秘密・知財編「米国著作権局はAI出力の保護を人間の寄与に基づき事実ごとに判断する分析を示している。営業秘密は秘密性を維持する合理的努力を含む要件がある。日本での結論やprovider契約は別確認が必要。」
• EA · EA-103生成物Provenance／C2PA等「C2PA 2.4は署名付きmanifest、assertion、signer identity、validationを定義し、改ざん検知可能な来歴を表現する。来歴の存在は、内容の真実・安全性・AI利用の完全な証明ではない。」
• EA · EA-104AI Supply-chain Security「SLSAはprovenanceとattestationの表現・検証を支えるが、artifactの安全性や品質を単独では保証しない。OpenSSF Scorecardは対象OSS repositoryの時点別check結果であり、全展開の保証ではない。」
• EA · EA-105AI生成コードSecurity「生成コードは、通常のコードと同じく解析・依存関係・secret・license・テスト・人手レビューを通す。CodeQL/Scorecardは検査部品であり、生成コードの安全性・適法性を保証しない。」
• EA · EA-106Automated AI Red Team「PyRITとgarakは生成AI/LLMのリスクprobeを自動化するOSS部品である。probeが通過したことは安全性の証明ではなく、対象・version・fixture・設定に依存する。」
• 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-109役割別AI技能体系「NIST NICEは役割・知識・技能・role-based trainingを整理する枠組みである。本書の一般社員/power user/管理者/developer/auditorのAI技能分解は、NICEを参照した運用提案であり、NICEの公式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-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-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-117Deep Research／AI Research Provenance「W3C PROV-OはEntity・Activity・Agentとused/generated/association等で調査来歴を表す標準語彙である。来歴は検証可能性を高めるが、引用の正しさ、一次資料性、sourceの真偽、研究結論の正確さそのものを保証しない。」
• 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-120Transaction／High-impact Action Guardrails「EU AI Act Article 14は高リスクAIのhuman oversightとして、能力・限界の理解、automation biasへの注意、override/reverse、safe stop等を規定する。企業の全transactionを自動的に同一の高リスク分類へ置く根拠ではなく、実運用では法域・用途・権限・不可逆性を別途分類する。」
• EA · EA-121異種LLMマルチエージェント「AutoGen原著は複数agent、LLM/human/toolの組合せ、相互作用のプログラムを示す。異種LLM構成はその実装候補だが、異種化だけで品質・安全・費用対効果が保証されるわけではなく、task別比較が必要である。」
• EA · EA-123Model Debate／Deliberation「Multiagent Debate原著は複数LLM instanceの複数round提案・反証が特定taskの推論/factualityを改善し得ると報告した。debateの合意は外部証拠・独立検証・人間監督の代替ではなく、業務適用には反証・abstain・費用上限が必要である。」
• EA · EA-124Judge／Critic分離「LLM-as-a-judge研究は、特定benchmarkで人間選好との高い一致を報告する一方、position・verbosity・self-enhancement biasと推論限界も明示する。generator/critic分離は評価設計の一案であり、客観的正解・安全性・法的適合の自動保証ではない。」
• EA · EA-125Generator–Verifier「Process supervision研究は、MATHの特定条件で中間stepへの検証が有効であると報告する。Generator–Verifierはruntime safetyの設計候補だが、verifier passは任意業務の正しさ・副作用なし・法的適合を保証せず、specと独立評価が必要である。」
• EA · EA-126Planner–Executor異種化「Plan-and-Solve研究はplan→subtask executionの構造と特定推論taskでの比較結果を示す。Planner–Executor異種化は費用・権限分離の設計候補であり、planの完全性、executorの安全性、外部actionの可逆性を自動保証しない。ReActのようなinterleavingも代替設計である。」
• 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-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-134LangGraph「LangGraphの公式Docsは、LLM stepと決定的stepを組み合わせる低レベルorchestrationとして、persistence・durable execution・streaming・human-in-the-loop等を記載している。これらは制御基盤の仕様候補であり、LLMの正しさ、side effectの安全性、全deploymentのSLAを自動保証しない。」
• 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-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-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-155Temporal「TemporalはLLMではなく、Workflow Executionの状態・Event History・Replay・Activity・Signal・timeout/retryを用いて長時間処理を耐障害化するdurable execution基盤である。公式Docsはsize/throughput・determinism等の限界を含み、author-maintained issueにはretry時の既成功Activity再実行に関す
• 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-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-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-213Unstructured／Document ETLUnstructuredは文書を要素へ分解し、その要素からRAG向けchunkを構成するOSS部品を提供する。抽出方式や依存によって読み順・表・来歴の結果が変わるため、元素材に照合した評価と権限継承を経てindexへ投入する。変換の成功だけで正確性や無通信性を判断しない。
• EA · EA-217DeepgramDeepgramの音声対話では、API世代・model・入力形式を固定し、文字列の確定、発話終了、生成、実再生、業務操作の認可を分けて管理する。
• 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-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-238PII検出・匿名化・Redaction部品PII検出器とredaction/anonymization処理は、入力から識別子を見つけて変換するための部品であり、それだけで「匿名化済み」「規制適合」「再識別不能」を保証するものではない。検出対象、言語、文脈、データ形式、しきい値、変換方式、復元鍵・対応表、ログやキャッシュなどの残存コピーを分けて設計・検証する。
• EA · EA-239Content Safety／Moderation Model・APIContent Safety／Moderation APIは、入力や出力を「安全／危険」と最終決定する認可機構ではありません。特定のモデル、taxonomy、threshold、対応modalitiesと言語の下で、ポリシー判断に使う分類信号を返す部品です。組織側では、この信号をどの条件でblock、allow、transform、human reviewへ接続するかを別に定義します。
• EA · EA-240Structured Output／Schema ValidationStructured OutputやJSON Schemaは、LLM出力を機械処理しやすい構造へ制約し、parse/schema failureを減らすための境界です。schema適合を、内容の真偽、業務妥当性、認可、最新状態、副作用の安全性と同一視しません。
• 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-001個人版／法人版クロスウォーク — plan/organization/modeをデータ保護・保持・管理権限・利用可能性・課金/上限・高度機能の条件に分解して比較する。「個人向けと法人向けAIの差は、使えるモデルや機能の数だけでは決まらない。データが学習に使われる既定値、保持・削除、管理者権限、接続先の認可、契約ごとの課金方式、管理対象ID、地域や段階的ロールアウトまでを分けて確認する。同じ製品名・同じモデル名でも、実際に使える能力やデータ境界はaccount、workspace、contract、mode、regionによって変わり得る。」
• 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-004非LLM AI総合編 — OCR、画像認識、音声認識・合成、翻訳、埋め込み、reranker、分類・回帰・異常検知、画像/動画等の専用AIを、LLM中心の会話/生成系と混同せず運用契約・評価器・実行基盤で整理するためのprovider-neutral taxonomy「『非LLM AI』は、古いAIや小さなモデルだけを指す言葉ではない。企業システムではOCR、音声認識、音声合成、画像認識、翻訳、埋め込み、reranker、分類・回帰・異常検知など、特定の入力を特定の型の出力へ変換する専用AIが今も独立した運用部品として使われる。これらの内部実装はLSTM、Transformer、NMT、場合によってはLLMを含み得るため、『LLMかどうか』と『専用部品かどうか』は別に確認する。選定時に重要なのは、入
• 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-009BOUNDED_CLOSEFor self-hosted LLMs, pin the model artifact and license, tokenizer/template, quantization, runtime release/commit, serving contract, accelerator/driver, network/egress, authentication/logging, and rollback artifact. Tre
• EA · EA-010Edge AI／完全オフライン運用編 — on-device / edge / local / offline / air-gapped を分離し、端末推論から完全オフライン運用までの成立条件を定義する「オンデバイス推論は完全オフライン運用の必要条件になり得るが、十分条件ではない。完全オフラインは、モデル、runtime、accelerator/driver、アプリケーション、認証・ライセンス、更新、telemetry、外部サービスまで含む対象system boundaryにruntime network dependencyがないことを実測して初めて主張できる。air-gappedはさらに強く、単なるoffline modeやegr
• 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-236ReBAC／Authorization Graph：OpenFGA・SpiceDBReBAC/Authorization Graphは、relationshipに基づくpermission decisionを中央化する仕組みであり、外部identity/session revocation、source-of-truth同期、application enforcementまで自動的に保証するものではありません。OpenFGA/SpiceDBではmodel/schema、relationship data、condit
• 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-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-248CDCでAI Knowledgeを更新するChange Data Capture（CDC）は、databaseの変更をAI/RAG knowledgeへ低遅延で届ける経路として利用できます。ただし、CDCを導入しただけでsource databaseからretrieval indexまでexactly-onceに一致するわけではありません。 CDC transportと、document/chunk/embedding/search indexへのmaterialization
• 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-1005外部STATE正本を使うAI定期実行のstale locator／cursor rollback境界外部STATEは再開の正本になり得るが、それだけで安全にはならない。cursorは対象identityとgenerationに結び付け、stale writerを拒否する。task-body versionや業務revision IDをpersisted-state schema identityの代替にしない。migrationのparse成功をsemantic correctnessと同一視しない。STATE rollbackを既発
• EA · EA-1009AI SRE障害調査のevidence-grounded diagnosis／誤診・棄権評価「AI SREは障害原因を自動的に特定できる」と一般化しない。安全な表現は、「特定の観測・tool・fault distributionの下ではAI agentが障害診断と修復を実行できる例があるが、本番利用では証拠追跡、誤診評価、棄権、権限制御、変更後検証を独立して設計・評価する必要がある」である。
• EA · EA-1010Prompt CacheをAI運用へ組み込む境界Prompt CacheはLLM入力prefixの再処理を減らし、latencyとinput costを改善し得るoptimization layerです。ただし、cache hitは会話memory、正本、監査証跡、同一出力の保証ではありません。cache missやexpiryが発生しても業務が正しく動く設計を基準にしてください。
• EA · EA-1011AI Use-Case Coverage「Enterprise AIの用途管理では、Actor、Task、Function、Sector、Modality、Autonomy、Riskを分離して用途プロファイル化すると、単一カテゴリでは失われる利用コンテキストと統制要件を追跡しやすい。これはNIST AI RMFのcontext mappingおよびOECDの多次元AI分類と整合する運用設計であるが、両機関がこの七軸schema自体を標準として規定しているわけではない。」
• EA · EA-1200AIの公平性・有害バイアス・disparate impactをどう評価するか「公平性指標を満たしたためAIは公平である」と断定しません。安全な表現は、「定義した母集団・期間・意思決定・属性・metricの範囲で観測された格差と不確実性を評価した。結果は当該条件下の証拠であり、他の集団、期間、法域、用途での公平性や法的適合を自動的に保証しない」です。
• EA · EA-1202Training-data Production／Curation／Annotation／Split Governance「データを大量に集めれば性能が上がる」「重複排除すればprivacy問題が解決する」「annotation agreementが高ければ正解」「train/testを分ければcontaminationはない」と一般化しません。
• EA · EA-1204AI Intervention Feedback Loops／Performative Prediction／Selective Labels「再学習すればfeedback loopは解消する」ではなく、「AIの予測や業務判断が次の観測データを変える場合、通常の再学習は過去policyの選択を再生産する可能性がある。decision/exposureとlabel availabilityを記録し、performative shift、selective labels、外生的shiftを分離して評価する」と記述します。
• 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-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-173Weights & Biases Weave：AIアプリケーションのトレーシング・評価・運用観測「Weights & Biases Weaveは、AIエージェントやLLMアプリケーションの実行をトレースし、評価・フィードバック・性能／費用観測へ接続するための基盤として利用できる。ただし、記録されたtraceはinstrumentationと送信条件の範囲での観測であり、実行の完全性を自動的に保証しない。評価結果もdataset、scorer、model、prompt等のversionと適用範囲に依存する。Enterprise利用で
• 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-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-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-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-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-232キューとメッセージブローカーでAI Agentを非同期に動かすキューは、依頼を受け付ける処理と、AIや外部ツールで実行する処理を時間的に分離します。待ち行列に入れたことは、業務が完了したことではありません。また、再配信や再試行は通常の故障回復経路です。Agentがメール送信や発注を行う場合は、メッセージの配送保証と、業務上の作用を一度に抑える制御を分けて設計します。
• EA · EA-233Edge WorkersをAIと業務システムの接着層として使うEdge Workerは、AIへの依頼を受け付け、認証、入力検査、接続先の選択、webhook、応答の転送を行う薄い接着層として利用できます。利用者に近い場所で動いても、モデルや原本データが遠ければ、全体の応答が速くなるとは限りません。長時間処理や業務状態の保存を一回のHTTP処理へ押し込まず、実行時間、永続化、認可、依存障害の境界を明示します。
• EA · EA-249ETL・ELTからAIの知識索引まで更新の成立を追うETLは取り出したデータを変換してから読み込み、ELTは読み込んだ後の基盤で変換します。AIの知識更新では、その後にも解析、分割、embedding、索引公開、権限の反映があります。取込ジョブが成功しただけで、検索や回答が最新・正確・閲覧可能になったとは判断できません。原本から検索可能な版まで、何がどこまで反映されたかを追います。
• EA · EA-250AIが使うデータの契約とスキーマ変更を管理するデータ契約は、作る側と使う側が、項目、型、意味、品質、更新、権限、変更手順を共有する約束です。AIが入力をそれらしく解釈しても、契約違反が直ったことにはなりません。項目名や型の互換性と、金額・時刻・対象集団等の意味の互換性を分け、変更の影響を検索、prompt、tool、評価データまで追います。
• EA · EA-252Data Lineage／ProvenanceをAI回答までつなぐAI回答のcitation、execution trace、data lineageは同一ではありません。 citationは回答からsourceを参照する表示、traceはLLM・retrieval・tool等の実行経路、lineageはsource artifactから派生artifactまでのderivationです。監査・再現・影響分析に使う場合は、この三者をstable identifierで接続します。
• 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-256KMS／HSM／Envelope Encryption for AIKMS/HSMはAI workloadのroot/key material保護と監査可能なcryptographic gateに有効です。ただし、KMS/HSMを利用しているだけでprompt、application memory、DEK cache、logs、vector data、tool actionまで自動的に安全になるとは扱いません。
• 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-258Private Networking／Private EndpointでAIを閉域化するPrivate Endpoint／PrivateLink／Private Service Connectは、AI serviceへpublic internetを経由しないprivate pathを提供できます。ただしendpointを作成しただけでend-to-endの閉域化が完成するとは扱いません。
• 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-266署名・Attestation・SLSAでAI Artifactを検証するAI Artifactの検証では、artifact bytesのdigest、署名者/issuer、attestation subject、provenance predicate、builder/workflow identityをconsumer policyに照らして確認します。
• 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-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-277Data Masking／Tokenization before LLM「LLM前のmasking/tokenizationは機微データ露出を減らすcontrolであり、匿名化や漏えい防止の保証ではありません。必要データだけを送り、検出漏れ、tokenのlinkability、再識別鍵・mapping、quasi-identifier、ログ／cache、出力側を別々に管理します。可逆tokenの復元はLLMから分離した認可済み境界で行います。」
• EA · EA-278Privacy-preserving Computation × AIPrivacy-preserving computationは一つのcontrolではありません。DP、MPC/FHE、federated/remote computation、TEEは異なる境界を保護します。攻撃者、保護対象、許可output、trust assumption、parameter、verification evidenceを明示し、単一PETから匿名性やend-to-end confidentialityを推定しません
• 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-281Tenant Isolation for Multi-tenant AI「認証由来のテナント文脈を全データ・操作経路へ渡し、保存先と実行主体の認可を強制して分離する」。一方、「テナントIDをプロンプトに書けば分離済み」「索引を分ければ全経路が安全」「専用GPUなら会話やログも分離済み」とはしない。
• EA · EA-282Row／Column-level Security × AI Analytics「実行主体とデータ基盤のポリシーで取得可能な行・列を制限し、AI入力と下流出力にも同じ権限を保つ」。一方、「プロンプトに権限を書けば十分」「RLSがあれば列も匿名化される」「結果0件ならフィルタを外す」「DB設定済みなので出力全体も安全」とはしない。
• EA · EA-283Cache Isolation／Cross-user Leakage対策「再利用を許す範囲を明示し、類似度とは独立した認可区画と失効制御を、保存・検索・同時要求の全経路で強制する」。一方、「IDをプロンプトへ混ぜれば分離済み」「類似度を上げれば漏えいしない」「TTLがあるので権限失効も即時」「修正PRがマージ済みだから全配備が安全」とはしない。
• EA · EA-284Approval UX for High-impact AI Actions「特定の操作と条件を人が確認し、その決定と実行内容を照合する承認経路を設計する」。一方、「人が押せば安全」「通知したので承認済み」「一度承認すれば変更後も許可」「interruptがあるので副作用は一度だけ」とはしない。
• EA · EA-285Human Escalation Policy／Handoff Design「停止範囲と責任者を定め、受領・判断・結果・再開を証拠で接続する」。一方、「メールしたので引継ぎ完了」「担当名があるので着手済み」「人の返答を受ければ無条件に再開」「判断を渡したのでAI側の責任は終了」とはしない。
• EA · EA-286Human Queue／Workbasket for AI Exceptions「案件を永続化し、配送・所有・判断・結果反映を分けて追跡する人の作業台を設計する」。一方、「投入できれば解決済み」「visibility timeoutで人の作業も一度だけ」「担当名があれば認可済み」「DLQへ移せば業務完了」「先頭ページが空なら未処理0件」とはしない。
• EA · EA-288Privileged Access Management for Agents「実行主体・対象・操作・期間を限定し、取得から終了までの特権利用を検証可能にする」。一方、「短期トークンなので安全」「人向けPIMをそのままエージェントにも適用可能」「権限を外せば全実行が瞬時に停止」「秘密が見えなければ万能ツールでも問題ない」とはしない。
• EA · EA-289Break-glass／Emergency Access for AI SystemsBreak-glass／Emergency Access for AI Systems
• 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-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-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-506リース失効・タイムアウト・キャンセル後に残る「ゾンビ外部操作」をどう封じるかリース失効・heartbeat timeout・キャンセルは、スケジューラ上の所有権や待機を終わらせるための制御であり、旧実行主体の停止や既送信の外部副作用の取消しを一般には保証しない。可能な対象では単調なgeneration/fencing tokenをmutation境界で原子的に検証し、対応しない外部副作用ではstable operation identity、providerのdocumented idempotency、結果r
• 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-511Risk- and Uncertainty-Aware Human Escalation Router「高影響または高不確実なAI操作では、人間承認の有無だけでなく、承認対象となるexact effect、レビュー担当者の現在権限、要求の期限、resume時の対象状態とauthorizationを結び付けて検証する。承認待ちの容量不足は自動承認で解消せず、backpressureまたはfail-closedを用いる。普遍的なしきい値や、人間介在そのものによる安全性向上は仮定しない。」
• EA · EA-512AIメモリの削除伝播を検証するAIメモリの削除は、削除APIが成功した時点では完了と判定できません。元データ、会話要約、埋め込み、索引、検索キャッシュ、複製、バックアップへ対象がどこまで伝播したかを調べ、各保存面の削除状態と検証証拠を対応させる必要があります。読取時の不在、物理領域の回収、バックアップの失効は別の証明です。本項は削除要求から復元後の再照合までの運用を扱います。埋め込み残留の詳細はEA-513、訂正後の再計算はEA-514に接続します。
• EA · EA-513派生AIデータの消去と埋め込み・索引の残留管理原文を削除しても、その原文から作ったチャンク、埋め込み、索引、要約、評価用コピーまで消えたとは限りません。派生AIデータの消去では、元データとの依存関係、削除操作が及ぶ単位、検索からの不可視化、保存領域の回収、バックアップからの再導入、再生成を別々に管理します。EA-512が削除要求全体の伝播と証拠を扱うのに対し、本項は派生表現と保存層の残留を扱います。
• EA · EA-514AIメモリの訂正伝播と古い派生データの修復AIメモリの訂正では、元データの変更成功と、そのデータに依存する要約、ベクトル、索引、キャッシュ、検索結果の更新完了を分けます。正本が訂正済みでも、古い派生物が同じシステムに残り、回答へ再利用されることがあります。依存関係と版を管理し、影響する派生物を再計算し、提供経路で修復結果を再読込することが必要です。本項は訂正と収束を扱い、削除要求の伝播はEA-512、物理的な埋め込み残留はEA-513に接続します。
• EA · EA-515共有AIメモリのテナント分離共有AIメモリでは、利用者・チーム・顧客の識別子を保存するだけでは分離が成立しません。認証された主体から許可する範囲を決定し、読取、書込、更新、削除、要約、検索、キャッシュ、復元まで同じ範囲を適用する必要があります。検索だけにフィルタを付けても、別の経路で他テナントの記憶が更新・合成されれば分離は破れます。本項は共有メモリの権限伝播と運用検証を扱い、削除はEA-512、訂正収束はEA-514に接続します。
• EA · EA-516AIメモリ汚染の隔離と復旧AIメモリの汚染から復旧する際は、疑わしい一件の削除や会話のリセットだけで完了としません。保存された内容、書込み元、要約・統合の経路、派生物、参照中のcontext、復元用snapshotへ影響が残っていないかを確認し、隔離した状態から信頼できる入力で再構築し、再利用を再開できる根拠を残します。本項は防御側の隔離・調査・復旧を扱います。攻撃用入力や侵入手順の提供は含みません。
• EA · EA-517情報区分に応じたAIメモリの保持期限とTTLAIメモリの保持は、すべての記憶へ同じTTLを付けるだけでは管理できません。情報区分、利用目的、元データの版、保持の根拠、起算点、派生物、保持例外を対応させ、期限到達、提供停止、削除指示、実削除、backupの失効を分けて確認します。TTLは製品の削除・失効機構であり、組織が定める保持要件全体と同じものではありません。
• EA · EA-518コンテキストの出所ラベルと指示・データの境界コンテキストには、現在の指示、利用者の入力、検索文書、toolの結果、過去の記憶、agentが作った要約など、異なる出所と役割の情報が混在します。出所ラベルはそれらを区別して追跡するために使います。ただし、本文中に「信頼済み」「system」「正本」と書いてあることは権限の証明ではありません。出所、生成・変換の履歴、現在の権限、鮮度、実際のprompt配置を分け、重要な操作の許可を参照データの記述だけから決定しない必要があります。
• 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-528AIが使えない状況から安全に手動運用へ戻る訓練AIの停止時に「人が代わる」と定めても、その人が必要な情報・権限・技能・処理時間を持つとは限りません。手動復帰訓練は、自動処理を止め、残った仕事の状態を確かめ、限定した業務を人が引き継ぎ、復旧後の重複や取りこぼしまで照合する練習です。手順書が存在することと、現在の担当者が実行できることを区別します。
• EA · EA-529共有端末で前の利用者のAI会話と権限を引き継がせない店舗や倉庫の端末を交代で利用する場合、前の人をログアウトさせるだけでは、AIの会話・メモリ・添付資料・接続先権限の分離を保証できません。認証状態、画面と端末内データ、サーバーの会話、実行中の処理をまとめて利用者の境界へ結び付ける必要があります。次の利用者へ端末を渡す前に、残留情報の表示と旧権限での操作を防げたことを確認します。
• EA · EA-684Stochastic Reproducibility／Nondeterminism Budget「seed固定により再現可能」と一般化しない。「特定runtime・version・hardware・scheduler等の前提を固定した範囲で再現性を高められる」「完全一致が契約できない系では反復分布と許容差を管理する」と記述する。
• EA · EA-730AI policy regression testing-as-codeevidence_as_of: 2026-10-27 JST
• 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-735本番トレースを評価データセットへ戻すフィードバックループ「本番traceは評価データセットの有力な入力であり、versioned datasetへ昇格して回帰評価へ戻せる。ただし代表性、PII、redaction、version混在、rare-event欠落をcontrolし、trace-derived setだけを完全な品質保証とみなさない。」
• EA · EA-737Differential Privacyで評価テレメトリを保護するAIシステムの評価telemetryには、失敗率、拒否率、品質指標、ツール実行結果、エラー分類、利用パターンなど、運用改善に必要な情報が含まれます。一方、評価対象が実ユーザーの入力や希少な失敗事例に由来する場合、識別子を削除するだけでは個人・組織・機密事象の推定可能性を十分に抑えられないことがあります。Differential Privacy（DP）は、個々のレコードや寄与の有無によって公開統計がどの程度変わり得るかを数学的に制約し、集
• EA · EA-738AI評価の昇格判定に統計的信頼性ゲートを入れる「候補モデルの平均スコアが高い」だけでは昇格根拠として弱い。比較対象と評価単位を固定し、差の大きさと不確実性を示し、事前定義した実用上の最小差および安全性の非交渉条件を満たしたときに昇格させる。信頼区間や有意差は本番性能の保証ではなく、定義した評価設計の下で観測差をどこまで信頼できるかを判断する材料である。
• EA · EA-739Human annotation QA／disagreement adjudication for AI evaluationAI評価で人間注釈を使う場合、単一ラベルを「正解」として保存するだけでは評価品質を監査できません。rubricとannotator trainingを版管理し、複数annotatorの独立判断、agreement/disagreement、adjudication、rubric改訂、最終ラベルまでのprovenanceを残します。特に主観的・境界的な評価では、disagreementは単なる誤差ではなく、曖昧な指示、edge case、
• EA · EA-741Evaluation dataset lineage／ownership／provenance contract「評価データは、dataset/versionの識別子とdigestだけでなく、source・derivation・作成/承認責任・rubric・split・利用runを追跡し、後から評価結果の再現と影響範囲の逆引きができるようにする。PROV-O、MLflow、OpenLineage等はその一部を実装するための基盤になり得るが、権利・同意・削除・case-level approvalまで自動的に保証するものではない。」
• EA · EA-743Tail-risk／rare catastrophic case evaluation sampling「平均品質評価とは別に、発生頻度が低くても被害が大きいfailure modeをtail-risk評価として管理し、重大caseを意図的に厚く検証する。oversampled suiteの失敗率はそのまま実運用の発生率ではない。母集団riskを推定する場合はsampling probabilityを追跡できる確率設計と適切な補正を用い、重大failureのrelease判断は平均scoreで相殺しない。」
• EA · EA-744Regulatory locale × evaluation requirement crosswalk「AI評価は世界共通の技術testをcoreとして再利用しつつ、法域・用途・system classification・operator role・適用日などで変わる要求をversioned regulatory overlayとして追加する。overlayは法的適用を自動決定するものではなく、承認済みapplicability判断をcontrol/test/evidenceへtraceするために使う。内部evalのPASSを法定con
• EA · EA-745Privacy-preserving synthetic evaluation data「synthetic dataなので個人情報を含まず安全」とは表現しません。安全な表現は、「synthetic evaluation dataは元データの直接配布を減らせるが、privacyは自動的には保証されない。utility、memorization/re-identification risk、DP等のformal guaranteeを分離して評価し、用途に応じたprivacy/utility gateを設ける」です。
• EA · EA-747GPU health diagnostics→自動quarantine/drain/remediation「GPU health automationは、診断signalを直接rebootへ結び付けず、detect・classify・quarantine・drain・remediation・再診断・recoveryを明示的な状態遷移として管理する。critical GPU faultでは新規割当停止に加えて既存workloadの安全な退避を検討し、mass quarantine用circuit breaker、drain/remediati
• EA · EA-748分散AI workloadのgang scheduling＋topology-aware placement「分散AI workloadでは、必要pod群が同時に実行可能かを扱うgang/admission controlと、rack・node・accelerator/fabric localityを扱うtopology-aware placementを分離して設計する。aggregate GPU数だけでは実配置可能性を保証できず、topology localityを強めれば常に性能が上がるわけでもない。workloadの固定/elastic
• EA · EA-751KV-cache-aware routingを使うLLM serving control planeLLM servingのroutingは、単純なround-robinや現在負荷だけでなく、各workerに再利用可能なKV cache prefixがどれだけ存在するかと、prefill/decodeの進行中負荷を同時に評価できる。NVIDIA DynamoのKV-aware routerは、workerごとのprefix overlapとactive loadを組み合わせ、再計算するprefill量を減らしつつcache-rich
• EA · EA-753Confidential AI inferenceとremote attestationの信頼境界「remote attestationに成功すればConfidential AI inferenceは安全」とは断定しない。「CPU/GPU/driver/firmware/workload policy等のattestation evidenceをversioned policyで検証し、許可状態に一致した場合だけsecretや暗号化資産をreleaseすることで、機密AI workloadの実行環境に対する信頼境界を強化する」とする
• EA · EA-754LLM inference admission controlとoverload sheddingLLM inference admission controlとoverload shedding
• 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 · EA-957RAG削除を「要求送信」で完了扱いしないRAGや検索基盤の削除は、削除APIが成功応答を返したことだけで完了と判定してはいけません。少なくとも「削除要求を受理したこと」「管理面で対象ジョブや資源が消えたこと」「検索・取得面で対象データが再び返らないこと」を別の状態として記録し、必要に応じて派生物や外部保存先も個別に確認します。
• EA · CORE-01状態を持つAIの運用契約この章の仕事は、LLMを「会話を返すもの」から「状態を持つ業務に参加するもの」へ移すときに必要な最小契約を定義することである。
• EA · CORE-02検索・記憶・出典の対応付けこの章は、「モデルへ入れられる量」「必要根拠を見つける能力」「見つけた根拠を使う能力」「sourceに忠実な生成」「sessionを越えて保持されるmemory/state」を分離し、企業AIのsource利用を検証可能な契約にする。
• 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-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-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-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-02OpenAI / GPT：検索・記憶・出典の対応付けこの文書は、CORE-02のQ-C02-001..004をGPT/OpenAIの現行surfaceへ対応づける。対象はChatGPTのCompany Knowledge／apps with sync／Projects／Memoryと、OpenAI APIのfile search／Retrieval／data controlsである。公開仕様、既存のprovider-neutral研究・local実験、本研究の分析を分離し、公開仕様だけで
• 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-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-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-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 · PM-NOTEBOOKLM-CORE-02NotebookLM：検索・記憶・出典の対応付けThis supplement answers only REQ-NLM-20260909-001 and Q-NLM-SCOPE-001..004. Consumer/Workspace Gemini Notebook, Workspace admin controls, Gemini Notebook Enterprise, source ingestion, chat/notes, Studio artifacts and dow
• 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-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
• 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.