信頼性・可観測性・復旧

障害・ログ・復旧・再試行

60件の公開項目

• 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-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-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-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-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-079Digital Twin × AI「Digital Twinは、AI Agentが現実の設備や運用へ作用する前に候補判断を仮想環境で検証するための一つの境界として利用できる。ただし、Digital Twinは現実そのものではない。安全性は、モデルに含まれる制約、状態の鮮度、校正、simulation engine、scenario変換の正しさに依存する。したがって『simulationで成功したから安全』ではなく、『どの状態・モデル・条件で何を試し、何が未検証か』を証跡
• 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-098Human-AI Interaction設計 — confidence、根拠表示、訂正、承認、undo等のAI特有UIを、能力限界・不確実性・可逆性・人間統制の観点から設計する。「AI特有のUIでは、結果を見せるだけでなく、何ができるか・何を根拠にしたか・どこに不確実性があるか・誤ったときにどう訂正/却下/復旧できるかを設計する。confidenceは正答確率とは限らず、根拠表示も正しさの保証ではない。外部作用を伴うAgentでは、承認対象を固定し、実行後のundoまたは補償手段まで含めて人間統制を設計する。」
• 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-221Transactional Email API × AgentAgentのdraftを送信操作へ変換する際は、全recipientと本文・添付の承認、domain認証、重複防止、配送event、suppressionを個別に追跡する。
• EA · EA-223Calendar／Scheduling API × Agentfree/busyから候補を作った後、時間帯・参加者・招待副作用・競合・再試行をどう管理するか。空き時間確認だけで予約確定や全員承諾を宣言しない。
• 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-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-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-245Dead Letter Queue／Poison Task運用Dead Letter Queue（DLQ）は、繰り返し失敗するmessage/taskを通常処理から隔離するための運用境界です。DLQへ移動したこと自体は、root causeの修復、messageの永久保存、外部side effectのexactly-onceを意味しません。
• EA · EA-246Circuit Breaker／Bulkhead／Load Shedding × AICircuit Breaker、Retry、Bulkhead、Load Sheddingは同じ機能ではありません。
• 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-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-1012AI Use-Case Coverage Census／未充足セル・過密セル検出「Coverage Censusは、version固定した多軸プロファイル上でEA・実運用ユースケースの分布を観測し、未充足・過密・分類不能を探索する。空セルは自動的に不足や新規導入必要性を意味せず、過密セルも自動的に重複を意味しない。各signalは用途、actor、risk、evidence、代替手段を確認してdispositionする。」
• 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-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-228Push Notification API × Agent：通知送信を業務実行と誤認しないための設計Push Notification APIの送信成功は、利用者への表示・閲覧・承認・業務完了の証明ではありません。Agentから通知を送る場合は、通知をauthoritative stateへの案内として設計し、recipient、event ID、TTL、priority、collapse、rate、sensitivityを制御します。重複・順序逆転・遅延・非表示・throttlingをfailure envelopeへ含め、重要な処
• EA · EA-232キューとメッセージブローカーでAI Agentを非同期に動かすキューは、依頼を受け付ける処理と、AIや外部ツールで実行する処理を時間的に分離します。待ち行列に入れたことは、業務が完了したことではありません。また、再配信や再試行は通常の故障回復経路です。Agentがメール送信や発注を行う場合は、メッセージの配送保証と、業務上の作用を一度に抑える制御を分けて設計します。
• EA · EA-268Chaos Engineering／Fault Injection for AIAI/AgentへのChaos Engineeringでは、faultを注入できたこと自体をresilienceの証明にしません。
• EA · EA-269Notification Delivery Semantics／Alert Fatigue × AgentAI/Agentの異常検出と人への通知を分離します。alert identity、dedup/grouping、persistence、severity、routing、suppression、resolutionを明示し、pageはactionableかつ緊急な影響へ限定します。
• 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-276AI Restore Drill／Disaster Recovery ExerciseDR drillは復旧手順を検証する証拠であり、将来の災害時成功を保証しません。AIシステムではinfra起動だけでなく、複数stateの整合性、model/tool/retrieval/policyを含むcritical journey、副作用隔離、failback/reprotectを検証し、観測したRTO/RPOと未検証条件を残します。
• EA · EA-289Break-glass／Emergency Access for AI SystemsBreak-glass／Emergency Access for AI Systems
• EA · EA-290AI Configuration Drift DetectionAI Configuration Drift Detection
• EA · EA-440障害時フォールバック階層Enterprise AIのフォールバックは「失敗したら別モデルへ送る」だけでは成立しません。障害の種類を判定し、再試行、別capacity/deployment、別region、別provider/model、機能縮退、durable queueまたは人手移管を、品質・データ所在・権限・副作用の制約付きで順序化します。
• EA · EA-501Agent Side-Effect Compensation：AIエージェントの外部副作用を「巻き戻し」ではなく検証可能な補償として扱う「補償はundoではなく新しい副作用である。元操作の結果を照合し、現在の回復権限・対象状態・後続変更・冪等性を再検証した上で実行し、最終的な業務／システム状態をreadbackする。不可逆な作用はrollbackと呼ばず、containmentまたはforward recoveryとして扱う。」
• EA · EA-505Retry Storm / Circuit Breaker / Nested Retry Budget Composition「agentのrequest_limitだけでproviderへの総attempt数が保証される」とは表現しません。「retryを完全に排除すべき」とも表現しません。公開可能な主張は、複数層のretryは負荷を増幅し得るため、retry domainを列挙し、観測可能な層ごとにownerと有限budgetを定め、重複retryを抑制し、backoff/jitter、breaker/backpressure、attempt telemet
• EA · EA-516AIメモリ汚染の隔離と復旧AIメモリの汚染から復旧する際は、疑わしい一件の削除や会話のリセットだけで完了としません。保存された内容、書込み元、要約・統合の経路、派生物、参照中のcontext、復元用snapshotへ影響が残っていないかを確認し、隔離した状態から信頼できる入力で再構築し、再利用を再開できる根拠を残します。本項は防御側の隔離・調査・復旧を扱います。攻撃用入力や侵入手順の提供は含みません。
• EA · EA-519プロバイダー間で能力契約と意味の同等性を確認するモデルやAPIを切り替える際、toolの名前とJSONの形を揃えるだけでは、同じ仕事を同じ条件で実行できると証明できません。プロバイダーをまたぐ能力契約では、呼出しと結果の対応、実行主体、入出力の意味、権限、終了・失敗、再試行、外部効果を明示し、対応できない差を失わずに扱います。意味の同等性は、対象操作・版・入力範囲・観測条件を指定した検証結果として記録します。
• EA · EA-528AIが使えない状況から安全に手動運用へ戻る訓練AIの停止時に「人が代わる」と定めても、その人が必要な情報・権限・技能・処理時間を持つとは限りません。手動復帰訓練は、自動処理を止め、残った仕事の状態を確かめ、限定した業務を人が引き継ぎ、復旧後の重複や取りこぼしまで照合する練習です。手順書が存在することと、現在の担当者が実行できることを区別します。
• EA · EA-733Provider障害シグナルをAIルーティングへ安全に使う「公開statusを自動fallbackの唯一の根拠にする」のではなく、「公開status、利用組織に関連するhealth signal、自前telemetry/probeをscope付きで統合し、hysteresisと段階的failbackを伴うrouting policyへ入力する」と表現する。provider statusが正常であることは個別tenantの正常性を保証しない。
• EA · EA-737Differential Privacyで評価テレメトリを保護するAIシステムの評価telemetryには、失敗率、拒否率、品質指標、ツール実行結果、エラー分類、利用パターンなど、運用改善に必要な情報が含まれます。一方、評価対象が実ユーザーの入力や希少な失敗事例に由来する場合、識別子を削除するだけでは個人・組織・機密事象の推定可能性を十分に抑えられないことがあります。Differential Privacy（DP）は、個々のレコードや寄与の有無によって公開統計がどの程度変わり得るかを数学的に制約し、集
• EA · EA-738AI評価の昇格判定に統計的信頼性ゲートを入れる「候補モデルの平均スコアが高い」だけでは昇格根拠として弱い。比較対象と評価単位を固定し、差の大きさと不確実性を示し、事前定義した実用上の最小差および安全性の非交渉条件を満たしたときに昇格させる。信頼区間や有意差は本番性能の保証ではなく、定義した評価設計の下で観測差をどこまで信頼できるかを判断する材料である。
• EA · EA-743Tail-risk／rare catastrophic case evaluation sampling「平均品質評価とは別に、発生頻度が低くても被害が大きいfailure modeをtail-risk評価として管理し、重大caseを意図的に厚く検証する。oversampled suiteの失敗率はそのまま実運用の発生率ではない。母集団riskを推定する場合はsampling probabilityを追跡できる確率設計と適切な補正を用い、重大failureのrelease判断は平均scoreで相殺しない。」
• 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-749NCCL/RDMA fabric failureの観測・診断・復旧設計「NCCL/RDMA障害はNCCL errorだけで根因を決めず、RAS/diagnostics、GPU・NVLink・PCIe、NIC/RDMA、fabric、nccl-tests、framework eventを同一incidentで相関し、fault domainを段階的に狭める。正常時baselineを保存し、復旧後も同条件で再検証する。version依存の診断機能と設定はlive環境で確認する。」
• EA · EA-750Spot/preemptible GPUの中断前提設計とcheckpoint経済性「Spot/preemptible GPUは中断と再取得待ちを通常系として設計し、周期checkpointを主手段、provider通知をbest-effortの追加退避signalとして扱う。採否は時間単価だけでなく、失われるcompute、checkpoint I/O、restart/reload、capacity再取得、fallback、期限リスクを含む実効費用で判断する。」
• EA · EA-755continuous batchingの公平性・starvation・SLO class設計「continuous batchingは公平である」「priority schedulingでstarvationを防げる」とは断定しません。「continuous batchingではrequest長・prefill/decode負荷・priority・KV footprintの差によりclass間のtail latencyやwaiting timeが偏り得るため、SLO class、aging/wait bound、prefill
• EA · CORE-05エージェントの副作用・復旧・人への引継ぎCORE-05は、AIが外部状態を変更する前後のread/write境界、permission scope、dry-run、confirmation、idempotency、compensation、undo、human escalation、action evidenceを定義する。目的は「人が承認した」「toolがsuccessを返した」を安全・完了とみなさず、意図した対象・操作・差分と外部最終状態を照合し、失敗時に停止・修復・引継
• 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-GEMINI-CORE-05GEMINI：エージェントの副作用・復旧・人への引継ぎCORE-05のread/write境界、confirmation、idempotency、recovery、undo、human escalationを、Gemini Apps、Gemini API、ADK、Vertex AI系runtimeへ対応づける。公開機能の存在を、trusted approval、exactly-once、external readback、完全undo、tenant採用の証拠へ昇格しない。CORE-05のl
• EA · PM-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-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-04GROK：モデル・ツール・情報源・状態の選択CORE-04のmodel / tool / source / state routing、fallback、service capacity、cost/error observability契約をxAI APIへ対応づける。model alias/date pin、retired-slug redirect、search/tool、Priority/Default、rate limit、online/deferred/Batch、SD
• EA · PM-GROK-CORE-05GROK：エージェントの副作用・復旧・人への引継ぎCORE-05のproposal、permission、confirmation、execution、receipt/readback、idempotency、compensation、undo、human escalationを、xAI Responses／Chat、client-side function、server-side tool、Remote MCP、deferred／Batchへ対応づける。modelのtool call
• EA · 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投入と