ガバナンス・監査・コンプライアンス

規則・責任・証跡・適用範囲

147件の公開項目

• 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-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-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-030AI能力の継続観測所AI能力の観測値は、モデル名だけに帰属する固定値ではない。モデル識別子、評価課題、実行環境、tool/scaffold、採点器、利用条件、実行日を組にして記録し、同一method versionの系列内で比較する。benchmarkやharnessを改訂した場合は旧系列と新系列をbridge runで接続し、method changeをmodel improvementと混同しない。
• EA · EA-032マルチモーダル業務設計編「multimodal supported」を一つのboolean capabilityとして扱わない。業務設計単位を MODALITY_ROUTE = source modality → normalization/extraction → model-visible representation → reasoning/generation → output modality → tool/external action とし、入力
• EA · EA-033GUI Agent / Computer Use Control ProfileGUI agent / computer-use運用では、automation surfaceを一括りにせず、structured API/tool or MCP、structured browser/page-aware automation、vision GUI browser、full desktop GUIを分離する。業務要件を満たす範囲で最もstructuredなsurfaceを優先し、GUIはfallbackまたはvisua
• EA · EA-036AI長期作業・状態管理専門編「長期作業型AIを成立させる鍵は、巨大なcontext windowを一つ保持することではない。実務では、成果物の正本、実行checkpoint、会話session、圧縮・要約された作業context、外部システムの副作用、run/version/provenanceを別の状態として管理し、再開時にそれらの整合を確認する必要がある。checkpointやsessionは復旧を助けるが、外部副作用の二重実行、schema/model/to
• EA · EA-037AIチーム／AI組織論「複数AIを組み合わせれば自動的に性能が上がるわけではない。独立して並列化できる高価値taskではmulti-agentが有効な場合がある一方、共有contextや依存関係が多いtaskではcoordination costとfailure surfaceが増える。AIチームは役割・権限・state所有・handoff・成果物・停止条件を明示したcontractとして設計し、single-agentまたはworkflow baselin
• EA · EA-038AI＋従来ソフト協調論AIにすべてを実行させず、意味解釈や計画をAIへ、厳密な計算・検証・検索・状態更新を従来ソフトへ返す。従来ソフトも正しさを自動保証しないため、型付き入力、権限、transaction/lock、idempotency、postcondition、readbackを実行契約として固定し、AIの成功宣言ではなく実システムからの再取得で閉じる。
• EA · EA-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-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-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-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-055Agent Replay／Forensics「Agentのforensicsはtrace保存だけでは完成しない。後から因果列を再構成できるprovenanceと、外部副作用を隔離したcontrolled replayを分けて設計する。LLM・retrieval・外部toolを含む実行では、同じ入力から同じ出力が得られるとは限らないため、replayは『当時の事実の再構成』と『現在条件での再実行』を明確に区別する。」
• 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-061AI向けData Classification「AI向けデータ分類は、従来の機密区分を捨ててAI専用ラベルへ置き換える作業ではない。既存の正式な分類を起点に、prompt、retrieval、tool、memory、output、logというAI固有のデータ移動面へ分類情報を伝播し、必要に応じて再検出・再評価する。自動検出結果は有力なsignalだが、完全な分類やcomplianceの証明ではない。classification、authorization、destination p
• EA · EA-063AI Privacy Engineering「AIのプライバシー対策は、PIIを見つけて黒塗りすることだけではない。まず業務目的に不要な個人情報を取得・検索・転送・保持しない。必要な情報には、検出、仮名化、削除、暗号化などを目的に応じて使い分ける。『検出されなかった』『anonymizeという関数を通した』ことだけで匿名化済みとは判断できない。識別可能性は周辺情報や復元鍵、外部データとの結合でも変わるため、入力、RAG、tool、memory、出力、ログまで処理面ごとに確認する必
• EA · EA-065AI × Records Management／eDiscovery「AI会話・生成物・Agent実行は、AIで生成されたという理由だけで一律に記録または廃棄対象になるわけではない。記録性は組織の業務・法令・保存方針に従ってartifact単位で判断し、legal holdやeDiscoveryでは、会話、memory、監査ログ、成果物などの実際の保存先を把握して保全・検索・export範囲を確認する。ユーザー画面からの削除、検索不能、provider側retention終了は同じ事象ではない。製品のc
• EA · EA-068Semantic Layer × AI「Enterprise AIの分析では、LLMを生のデータベースschemaへ直接接続するより、組織が定義したmetrics・dimensions・relationships・access rulesを持つsemantic layerを介在させると、AIが推測しなければならない業務意味を減らし、定義をversion管理・監査・評価しやすくできる。これは回答正確性の保証ではない。semantic model自体の誤り・不足・陳腐化、権限設
• EA · EA-070Document Intelligence大全「企業AIの文書入力は、LLMへPDFを渡す処理だけで完結しない。OCR、レイアウト、表、フォーム、業務field抽出は独立したDocument Intelligence層として実装でき、主要cloudはversioned processor/APIを提供している。ただし文字認識・構造抽出・業務field抽出・最終回答は別々の品質段階であり、一段の成功を後段の正確性へ外挿してはならない。」
• 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-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-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-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-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-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-113Email Agent安全運用「Gmail APIはmessages.sendとdrafts.sendを別methodとして提供するため、draft→検査→明示承認→sendという制御点を設計できる。ただし、APIの存在は宛先正確性、承認、DLP、法的適合、送信後回収を保証しない。」
• EA · EA-114Spreadsheet Agent安全運用「Sheets API v4はセル値・書式・保護範囲などを操作でき、batchUpdateはrequest検証と一括適用を提供する。ただし、同時編集の影響があり、APIのatomicityは式の意味正確性、再計算結果、業務上の正しさを保証しない。」
• EA · EA-115Document Fidelity研究「Google Docs APIは文書を構造要素、text run、画像、書式、header/footer/footnoteとして扱う。したがってdocument fidelityは内容・構造・書式・描画を分解して検証すべきだが、このAPI仕様だけでDOCX/PDF/Slides間の視覚的同一性や変換完全性を保証できない。」
• EA · EA-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-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-127Researcher–Writer異種化「WebGPTとSelf-RAGは、検索/取得・参照収集・生成/反省を連携させる研究例である。Researcher–Writer分離は来歴と責任境界を明確にする実装提案だが、別modelにするだけで一次資料性、引用の正しさ、真偽、最新性、法的適合は保証されない。」
• 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-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-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-159AG-UI「AG-UIは、agentic backendとユーザー向けfrontendの間を、HTTP／WebSocket等の上にイベント駆動・双方向で接続するプロトコルである。イベント仕様1.0は当該資料でDraftと表示されているため、採用時は版・SDK・再接続・認可・表示安全性を個別に確認する。」
• 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-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-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-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-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-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-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-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-1012AI Use-Case Coverage Census／未充足セル・過密セル検出「Coverage Censusは、version固定した多軸プロファイル上でEA・実運用ユースケースの分布を観測し、未充足・過密・分類不能を探索する。空セルは自動的に不足や新規導入必要性を意味せず、過密セルも自動的に重複を意味しない。各signalは用途、actor、risk、evidence、代替手段を確認してdispositionする。」
• 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-1208AI Supplier Warranty／Indemnity／Liability Allocation「ベンダーがAI出力を保証する」「著作権侵害はすべてベンダー負担」「enterprise契約なので責任はベンダーへ移転済み」と一般化しない。
• EA · EA-1218AgentWorld — 長期マルチエージェント協調ベンチマークAgentWorld は複数AIエージェントの長期協調を評価する研究ベンチマークである。既存GX provenanceでは arXiv:2609.31590、50ラウンド超、3〜20エージェント、採集時点の最良系タスク成功率52.0%が記録されている。
• EA · EA-178Inspect AIInspect AIはmodelやagentをtask、solver、scorer等の構成で評価するframeworkである。実行結果を読む際は正誤、実行error、採点不能を区別し、得点とcoverageを併記する。frameworkと評価task集のrevisionも区別して保存する。
• 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-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-259Agent Egress Control／Network PolicyAgent egress controlは、private endpointやVPC接続の有無だけで判定せず、Agent runtimeから外部destinationへ出る実際のpathを制御します。
• EA · EA-266署名・Attestation・SLSAでAI Artifactを検証するAI Artifactの検証では、artifact bytesのdigest、署名者/issuer、attestation subject、provenance predicate、builder/workflow identityをconsumer policyに照らして確認します。
• 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-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-280Retention Policy for AI Conversations／Artifacts「保存先と派生先ごとに保持・利用停止・削除・確認の条件を定め、実行証拠を残す」。一方、「学習に使われないので保存もされない」「応答を消したので全派生物も消えた」「30日なら全製品・全契約で適合」とはしない。
• EA · EA-285Human Escalation Policy／Handoff Design「停止範囲と責任者を定め、受領・判断・結果・再開を証拠で接続する」。一方、「メールしたので引継ぎ完了」「担当名があるので着手済み」「人の返答を受ければ無条件に再開」「判断を渡したのでAI側の責任は終了」とはしない。
• EA · EA-290AI Configuration Drift DetectionAI Configuration Drift Detection
• 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-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-511Risk- and Uncertainty-Aware Human Escalation Router「高影響または高不確実なAI操作では、人間承認の有無だけでなく、承認対象となるexact effect、レビュー担当者の現在権限、要求の期限、resume時の対象状態とauthorizationを結び付けて検証する。承認待ちの容量不足は自動承認で解消せず、backpressureまたはfail-closedを用いる。普遍的なしきい値や、人間介在そのものによる安全性向上は仮定しない。」
• EA · EA-520Effective Instruction Contract Envelope「system instructionを設定した」ことと「そのinstructionが実行時に常に強制された」ことを同一視しない。監査可能なのは、組織が管理するinstruction revision、観測可能なprovider/model/runtime/configuration、明示したcomposition、指定した評価条件で得たbehavioral evidenceである。hidden provider instruction
• 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-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-736Locale・script・region-aware AI evaluation matrix「BCP 47/CLDRを用いてlanguage・script・regionの評価軸を正規化し、実利用分布とリスクに応じて評価セルを分離する。locale tagやlikely-subtagはcoverage設計の補助であり、品質・文化適合性・法域適合性を自動的に保証しない。」
• 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-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-758multimodal media cacheのUUID衝突・tenant隔離evidence_as_of: 2026-10-27 JST
• EA · EA-759speculative decodingを負荷に応じて切り替えるadaptive運用evidence_as_of: 2026-10-27 JST