直す

障害の切り分けと復旧を調べる

137件の公開項目

• 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-020AIアーキテクチャ・パターン集AIアーキテクチャは、Single-agentかMulti-agentかという一問だけでは決まらない。制御を誰が握るか、状態と知識をどこに置くか、外部ツールをどの境界から呼ぶか、同期・非同期・batchのどの実行形態を使うか、人間承認と復旧をどこに置くかを分けて設計する。
• EA · EA-021AIアンチパターン集AIアンチパターンは、特定技術を使うこと自体ではなく、有効な技術を責務や適用条件を無視して万能化するところから生じる。長いコンテキスト、RAG、Agent、会話memoryはいずれも有用だが、正本、権限、状態、検証、復旧まで一つの層へ背負わせると、性能・安全性・監査性・費用のどこかで破綻しやすい。技術名ではなく、責務分離と失敗包絡で診断する。
• EA · EA-028AI教育・社内導入カリキュラム社内AI教育は、全員へ同じ製品操作を教えるだけでは不十分である。共通Coreを維持しつつ、利用者のrole、technical knowledge、扱うdata、task impact、利用するsystemに応じて学習到達点を分ける。受講完了と安全に業務利用できる能力は分離し、知識問題だけでなくsafe/unsafe input判別、source verification、confidential-data handling、exter
• 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-053AI Incident Response「AI Incident Responseは既存のサイバーIRを置き換える別制度ではない。2026年時点の有力な実務方向は、既存IRへAIシステムの観測性・制御性・version provenance・model/data/tool/agent経路の分析を追加することである。ただしAI固有incident managementの標準化は進行中であり、特定のtaxonomyやreporting schemaを普遍的完成標準として扱うべきで
• EA · EA-055Agent Replay／Forensics「Agentのforensicsはtrace保存だけでは完成しない。後から因果列を再構成できるprovenanceと、外部副作用を隔離したcontrolled replayを分けて設計する。LLM・retrieval・外部toolを含む実行では、同じ入力から同じ出力が得られるとは限らないため、replayは『当時の事実の再構成』と『現在条件での再実行』を明確に区別する。」
• EA · EA-058Prompt／Instruction Configuration Management「Promptやsystem instructionは単なる文章ではなく、本番挙動を変える構成資産としてversion管理する。再現・監査に必要なのはprompt本文だけではなく、実行時に解決されたprompt revision、model、generation設定、tool/retrieval/policy等の組合せである。`production`のようなaliasは運用に便利だが、監査ログにはalias名だけでなく実際に参照したim
• EA · EA-064AI Data／Memory Lifecycle専門編「Enterprise AIのmemory lifecycleは『覚える／忘れる』の二値ではない。session/raw event、派生summary、durable memory、revision、retrieval index、application state、logなどに別々のretentionとdelete semanticsが存在し得る。delete/resetを運用要件にする場合は、対象scopeとartifact、期待
• EA · EA-066Identity-aware／ACL-aware RAG「RAGで元データの権限を守るには、文書にACLを付けて保存するだけでは足りない。検索時の利用者を識別し、その時点で有効な権限と照合して、許可された文書・チャンクだけをLLMのコンテキストへ渡す必要がある。さらに、元データの権限変更が検索インデックスへ反映されるまでには遅延があり得るため、ACL同期の鮮度も認可状態の一部として監視する。『ログイン済み』『検索結果では非表示』『RAG対応』はいずれも、元データと同じアクセス境界が保たれてい
• EA · EA-068Semantic Layer × AI「Enterprise AIの分析では、LLMを生のデータベースschemaへ直接接続するより、組織が定義したmetrics・dimensions・relationships・access rulesを持つsemantic layerを介在させると、AIが推測しなければならない業務意味を減らし、定義をversion管理・監査・評価しやすくできる。これは回答正確性の保証ではない。semantic model自体の誤り・不足・陳腐化、権限設
• 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-079Digital Twin × AI「Digital Twinは、AI Agentが現実の設備や運用へ作用する前に候補判断を仮想環境で検証するための一つの境界として利用できる。ただし、Digital Twinは現実そのものではない。安全性は、モデルに含まれる制約、状態の鮮度、校正、simulation engine、scenario変換の正しさに依存する。したがって『simulationで成功したから安全』ではなく、『どの状態・モデル・条件で何を試し、何が未検証か』を証跡
• 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-090Air-gapped AI「Air-gapped AIは、モデルを一度持ち込んでネットワークを切れば完成するものではない。閉域内で推論・RAGを実行できることに加え、モデル、コンテナ、依存package、データ、脆弱性情報を検証付きで持ち込み、内部repositoryから更新・rollback・監査できる供給線が必要である。物理mediaは更新経路であると同時にattack surfaceでもある。」
• 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-098Human-AI Interaction設計 — confidence、根拠表示、訂正、承認、undo等のAI特有UIを、能力限界・不確実性・可逆性・人間統制の観点から設計する。「AI特有のUIでは、結果を見せるだけでなく、何ができるか・何を根拠にしたか・どこに不確実性があるか・誤ったときにどう訂正/却下/復旧できるかを設計する。confidenceは正答確率とは限らず、根拠表示も正しさの保証ではない。外部作用を伴うAgentでは、承認対象を固定し、実行後のundoまたは補償手段まで含めて人間統制を設計する。」
• EA · EA-100日本語・日本業務特有のAI問題 — 敬語、縦書き、和暦、帳票、住所、人名、表記揺れ、日本語OCRを「日本語対応」の一語で潰さず、業務データ型・文書レイアウト・文字体系・社会言語的適切性ごとに検証する「日本語を生成できることと、日本の業務データを正確に処理できることは別である。住所の表記揺れ、人名の異体字、縦書きや帳票レイアウト、和暦、敬語などは独立した失敗条件を持つ。重要項目は生成モデルのもっともらしさだけで確定せず、公的・業務上の参照データ、決定的な変換規則、文書種別ごとの評価、人による訂正を組み合わせる。」
• EA · EA-109役割別AI技能体系「NIST NICEは役割・知識・技能・role-based trainingを整理する枠組みである。本書の一般社員/power user/管理者/developer/auditorのAI技能分解は、NICEを参照した運用提案であり、NICEの公式AI職種分類ではない。」
• EA · EA-112Reproducibility／Determinism研究「再現性は環境境界を伴う契約である。PyTorch 2.14 Docsもrelease・commit・platform・CPU/GPU間の完全再現を保証せず、seedとdeterministic optionで特定環境の非決定性を減らす設計を示す。これをhosted LLMの文字列一致保証へ外挿してはならない。」
• EA · EA-114Spreadsheet Agent安全運用「Sheets API v4はセル値・書式・保護範囲などを操作でき、batchUpdateはrequest検証と一括適用を提供する。ただし、同時編集の影響があり、APIのatomicityは式の意味正確性、再計算結果、業務上の正しさを保証しない。」
• EA · EA-130Multi-LLM routing「Multi-LLM routingは、入力や品質要求に応じて候補LLMを選択し、費用・品質・遅延を調整する研究／実装パターンである。FrugalGPTやRouteLLMは条件付きの研究結果を示すが、数値を任意の業務や現行製品へ外挿せず、可用性・プライバシー・fallbackを別途検証する。」
• EA · EA-135CrewAI「CrewAI公式Docsは、agent/crew/flow、状態、guardrail、memory、observability等の実装要素を記載し、Enterprise項目としてconsole/RBAC/connectorsも案内している。実際の利用可否・権限・plan/region・安全性は機能ごとにゲート確認が必要で、Docsの機能存在は業務保証ではない。」
• EA · EA-138Mastra「Mastraの現行Docsは、TypeScript上のagent・workflow・tool・memory・Studio・observabilityを案内している。これは実装要素の存在根拠であり、全provider・plan・regionでの利用可否、業務品質、権限安全性、production SLOの保証ではない。」
• 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-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-161Webhook／Event protocol「WebhookはHTTP等による通知・受信の配置であり、全実装に共通する配送保証ではない。CloudEvents v1.0.2はevent context/data、specversion、source/id、format、protocol bindingを定義するが、exactly-once、順序、retry、署名、認証、業務処理の原子性は個別契約として設計・検証する。」
• EA · EA-171Arize PhoenixArize Phoenix is documented as an open-source AI observability and evaluation platform built on OpenTelemetry and OpenInference. Its documented surface includes traces for model calls, retrieval, tool use and custom logi
• EA · EA-221Transactional Email API × AgentAgentのdraftを送信操作へ変換する際は、全recipientと本文・添付の承認、domain認証、重複防止、配送event、suppressionを個別に追跡する。
• EA · EA-222Slack／Teams／ChatをAgentの業務面にするチャット上の入力・承認・通知・handoffを業務操作へ安全に接続できるか。署名やボタン押下だけを本人認可・最終承認へ転用しない。
• 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-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-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-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-244Durable Execution／Workflow Replay for AIDurable Executionは長時間のAgent workflowのstate/progressをdurable history/checkpointへ残し、failure後に復元・継続する実行方式です。ただし外部API・tool・payment・email・database mutation等のside effectがexactly-onceになることを意味しません。
• EA · EA-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-1009AI SRE障害調査のevidence-grounded diagnosis／誤診・棄権評価「AI SREは障害原因を自動的に特定できる」と一般化しない。安全な表現は、「特定の観測・tool・fault distributionの下ではAI agentが障害診断と修復を実行できる例があるが、本番利用では証拠追跡、誤診評価、棄権、権限制御、変更後検証を独立して設計・評価する必要がある」である。
• EA · EA-172BraintrustBraintrustは、生成AI／エージェントの実験・評価と本番トレースを接続し、品質、失敗、コスト、レイテンシ等を継続的に検証するための運用基盤として利用できる。導入効果は、評価設計、計装範囲、データ境界、tenant／plan設定、組織固有の運用統制に依存するため、製品機能の存在を品質保証やコンプライアンス保証へ外挿してはならない。
• 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-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-500Agentの能力契約を検証するAgentが能力を公開していることと、その能力を利用者の期待どおりに実行できることは別です。能力契約の検証では、宣言、入出力schema、protocolと版、認証・認可、呼出し状態、業務上の効果を分けて確認します。同じ名前のskillやtool、同じJSON構造だけから、取消、重複実行、失敗、完了の意味まで同じと推定しません。
• 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-730AI policy regression testing-as-codeevidence_as_of: 2026-10-27 JST
• 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-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-01状態を持つAIの運用契約この章の仕事は、LLMを「会話を返すもの」から「状態を持つ業務に参加するもの」へ移すときに必要な最小契約を定義することである。
• EA · CORE-03タスク分解と処理工程CORE-03は、複合taskを検証可能なstageへ分け、stage間の入出力、intermediate artifact、retry、verification、parallel/serial、transaction境界を定義する。目的は「一発でやらせない」という標語ではなく、失敗を局所化し、再実行で完了済み工程や外部状態を壊さず、local passとend-to-end successを分けて判定できるpipeline contr
• EA · CORE-05エージェントの副作用・復旧・人への引継ぎCORE-05は、AIが外部状態を変更する前後のread/write境界、permission scope、dry-run、confirmation、idempotency、compensation、undo、human escalation、action evidenceを定義する。目的は「人が承認した」「toolがsuccessを返した」を安全・完了とみなさず、意図した対象・操作・差分と外部最終状態を照合し、失敗時に停止・修復・引継
• EA · CORE-06プロンプトと設定の管理CORE-06は、promptと周辺configurationを再構成・比較・承認・release・rollbackできるversioned entityとして管理する。目的は「prompt文字列は同じ」「昨日と同じmodel名」を再現性の証拠とせず、実際のbehaviorを変える構成要素とenvironment差を一つのrelease lineageへ結ぶことである。
• EA · PM-CLAUDE-CORE-03CLAUDE：タスク分解と処理工程CORE-03のstage、artifact、handoff、parallel/serial、resume/retry、verification、transaction境界をClaude Agent SDK/Claude Codeの公開surfaceへ対応づける。会話session、subagent、tool result、hook、permission、filesystem、外部systemを同一状態として扱わない。S063 Froz
• EA · PM-CLAUDE-CORE-04CLAUDE：モデル・ツール・情報源・状態の選択CORE-04のmodel / tool / source / state routing、fallback、batch、observability契約をClaude API、Message Batches、service tier、Claude Agent SDKへ対応づける。Claude.ai、Claude API、Agent SDK、Claude Code CLI、Bedrock、Google Cloud、Managed Agen
• EA · PM-CLAUDE-CORE-05CLAUDE：エージェントの副作用・復旧・人への引継ぎCORE-05のread/write境界、scoped permission、確認、receipt/readback、idempotency、補償、undo、human escalationをClaude API tools、MCP connector、Claude Agent SDK／Claude Codeへ対応づける。modelのtool_use、permission allow、hook通知、tool result、file ch
• EA · PM-CLAUDE-CORE-06CLAUDE：プロンプトと設定の管理CORE-06のversioned configuration bundle、declared/effective差、environment diff、canary、rollbackをClaude API、Claude Agent SDK、Claude Codeへ対応づける。対象はsystem prompt、settingSources、settings/CLAUDE.md/skills、model/effort、tools、struc
• EA · PM-GEMINI-CORE-03GEMINI：タスク分解と処理工程CORE-03のstage、artifact、parallel/serial、retry、verification、transaction境界をGemini系の公開surfaceへ対応づける。Gemini Appsのchat/Gem、Gemini API、ADK、Vertex AI/Google Cloudの実行基盤を同一機能として扱わない。公開仕様、author-maintained issue、CORE-03のlocal LangG
• EA · PM-GEMINI-CORE-04GEMINI：モデル・ツール・情報源・状態の選択CORE-04のmodel / tool / source / state routing契約を、Gemini Apps、Gem、Gemini API、ADK、Vertex AIへ対応づける。各surfaceのmodel名、tool、state、batch、quotaを一つの自動routerとみなさず、公開仕様、公開failure signal、組織観測を分離する。価格・quota・tenant設定・内部routingはcurrent値
• EA · PM-GEMINI-CORE-05GEMINI：エージェントの副作用・復旧・人への引継ぎCORE-05のread/write境界、confirmation、idempotency、recovery、undo、human escalationを、Gemini Apps、Gemini API、ADK、Vertex AI系runtimeへ対応づける。公開機能の存在を、trusted approval、exactly-once、external readback、完全undo、tenant採用の証拠へ昇格しない。CORE-05のl
• EA · PM-GEMINI-CORE-06GEMINI：プロンプトと設定の管理CORE-06のconfiguration bundle、version、digest、lineage、environment diff、canary、rollbackを、Gemini Apps/Gems、Gemini API、Vertex AI Prompt Managementへ対応づける。UIの保存、prompt version、model名、restore機能の存在を、composite release bundle、backe
• EA · PM-GPT-CORE-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-05OpenAI / GPT：エージェントの副作用・復旧・人への引継ぎSource: OpenAI, Human-in-the-loop, [ ; accessed 2026-09-08; sections Marking tools that need approval / How the approval flow works / Automatic approval decisions / Long-running approvals. New source EXT-C05-001.
• EA · PM-GPT-CORE-06OpenAI / GPT：プロンプトと設定の管理CORE-06のconfiguration bundle、version/approval lineage、environment diff、canary/rollback契約をOpenAI APIとAgents SDKへ対応づける。対象はResponses APIのinput/instructions、廃止予定のreusable prompt objects、Agents SDK v0.22.0のPrompt/Agent/RunCon
• EA · PM-GPT-CORE-07OpenAI / GPT：評価データと公開前の評価契約CORE-07のgolden dataset、holdout、scorer/judge registry、slice-level AND gate、release/rollback evidenceをOpenAIのDatasets、Evals、Graders、Agent evals、Prompt optimizerおよびopenai/evals OSSへ対応づける。公開仕様と固定OSSだけを対象とし、実tenant、非公開dataset
• EA · PM-GROK-CORE-04GROK：モデル・ツール・情報源・状態の選択CORE-04のmodel / tool / source / state routing、fallback、service capacity、cost/error observability契約をxAI APIへ対応づける。model alias/date pin、retired-slug redirect、search/tool、Priority/Default、rate limit、online/deferred/Batch、SD
• EA · PM-GROK-CORE-05GROK：エージェントの副作用・復旧・人への引継ぎCORE-05のproposal、permission、confirmation、execution、receipt/readback、idempotency、compensation、undo、human escalationを、xAI Responses／Chat、client-side function、server-side tool、Remote MCP、deferred／Batchへ対応づける。modelのtool call
• EA · PM-GROK-CORE-06GROK：プロンプトと設定の管理CORE-06のversioned composite configuration、declared/effective差、environment diff、canary、rollbackをxAI APIへ対応づける。対象はrequest message、model/alias、sampling/reasoning parameter、client/server/MCP tool、Collection/file source、struc
• EA · 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
• 用語 · IDX-C04-033429 retry / semantic fallback split利用回数の制限を受けた後に待つこととAIの製品や種類/AIが使う操作機能/参照する資料契約を変える代わりの手段への切り替えを分離
• 用語 · IDX-C07-027aggregate/pass@1 / critical slice gate split公開aggregateとtail、repeat variance、known regression、unsafe/over-refusalを分離
• 用語 · IDX-C03-008必要時分解executor不能、risk、side effect、作成・保存した成果物、failure isolationが追加stageを正当化する時だけ分解する
• 用語 · IDX-C05-039async result availability / human acceptance splitdeferred/Batch 進み具合・single retrievalと承認、external completion、incidentを分離
• 用語 · IDX-C01-040batch drained / business completion splitnum_pending=0内のsuccess/errorとcancel済みpartial resultを受入判定から分離
• 用語 · IDX-C04-027batch terminal / per-request acceptance splitbatch終了とunorderedな個別succeeded/errored/canceled/expired、業務受入を分離
• 用語 · IDX-C06-024code rollback / release rollback splitprior 操作の確定復元とdependency・deployment・evaluation・実物を開き直して確かめることを含むrelease 操作や変更を元に戻すことを分離
• 用語 · IDX-C06-012構成可観測性declared、exported、現在の-実物を開き直して確かめること、behavior-observedのどこまで取得できるかをsurface別に記録する
• 用語 · IDX-C07-010deterministic check / model judge splitexact/schema/rule failureとAIの製品や種類-based preference scoreを別判定し、judgeを版・calibration対象にする
• 用語 · IDX-C02-011診断制限retrieved chunks等が観測不能でretrieval/generation原因を確定できない状態
• 用語 · IDX-PROV-003二重provenance同じ命題に本研究の実測と外部資料がある場合、観測結果・外部仕様/比較・本研究の分析を別relation rowとして保持する構造
• 用語 · IDX-C07-017evaluator infrastructure errorソフト同士がやり取りする窓口/harness/parser/timeoutをcandidate不正解から分離する評価状態
• 用語 · IDX-C07-002過去の失敗を、次の確認に使う以前起きた障害、失敗しかけた例、悪いと分かっている回答を、再発を防ぐための確認例として残したものです。
• 用語 · IDX-C04-009循環fallback防止代わりの手段への切り替え graphのroute visited集合、attempt/wall-clock budget、同一error hashで再入を検出・停止する
• 用語 · IDX-C05-031file checkpoint / external rollback split追跡対象local fileのrewindとBash・remote・subagent・conversation・external effectを分離
• 用語 · IDX-C01-035file rewind / effect rollback splittracked local file復元とBash・directory・remote/external effectの補償を分離
• 用語 · IDX-C01-016同じ操作を二重にしないための決め方もう一度試すとき、どの操作を再実行するか、重複をどう見分けるか、先に何を確認するかを決めておくことです。
• 用語 · IDX-C03-021session ack消失再送session appendが操作の確定済みでもackを失った場合、pending inputの再送で重複し得るfailure class。dedup/実物を開き直して確かめることを要求する
• 用語 · IDX-C03-005並列書込競合複数stageが同じ作成・保存した成果物/external record/版へ競合writeするfailure
• 用語 · IDX-C05-015復旧失敗残差compensationが失敗または部分成功したとき、元操作の外部effectを消去済みとせず証拠と残留riskを保持する状態
• 用語 · IDX-C04-010request単位・試行単位の分離一つのbusiness requestと内部再実行/代わりの手段への切り替え attemptを別ID/集計にし、cost/log/callback/incident増幅を観測する
• 用語 · IDX-C04-020retryとfallbackの分離同route再試行とAIの製品や種類/AIの提供元/endpoint変更を別eventにし、response開始、visited route、capability loss、wall-clockでloopを止める
• 用語 · IDX-C03-003再実行単位failure後に再実行してよい最小stageと、そのidempotency/実物を開き直して確かめること条件
• 用語 · IDX-C02-043retry抑止孤立memorycancel/partial 操作の確定でactive recordだけ残り、same-fact 再実行がhash dedupされてhistory/message等の欠落を修復しない状態
• 用語 · IDX-C06-009rollback証拠連鎖failed release、target bundle/environment、dependency/schema compatibility、受付・受領の記録/実物を開き直して確かめることを結ぶ回復記録
• 用語 · IDX-C01-008AI側の処理の進み具合AIや実行システム側で、処理中・失敗・終了などを示す状態です。出来上がったものを仕事として受け入れてよいかとは別です。
• 用語 · IDX-C04-024SDK fallback trigger / capability equivalence splitprimary failure時代わりの手段への切り替え optionの存在と能力・現在の状態・品質同値を分離
• 用語 · IDX-C01-029session backend / task record split開発用の道具一式 history 裏側の保存・処理システムとcanonical Operating あらかじめ決めた取り決めを別所有・別復旧対象にする
• 用語 · IDX-C01-015副作用宣言primary/secondary effect、操作の確定 point、reversibility、blast radius、recoveryを表すrecord
• 用語 · IDX-C07-004slice別合否overall平均では上書きできないtask/risk slice別threshold、critical failure、variance条件
• 用語 · IDX-C02-008旧版復活superseded/archive 参照する資料が現在の判断へ再混入するfailure
• 用語 · IDX-C03-035WebSocket continuation / durable recovery splitconnection内現在の状態、error eviction、25分上限とdurable task recoveryを分離
• 用語 · IDX-C02-022score 0候補露出本文以外の付随情報 maskで順位を落としても、retrieverの返却集合へ拒否候補が残るpath-scoped failure
• 道具 · TOOL-0022OpenTelemetrytrace・metric・logを計装・収集・出力する道具群です。
• 道具 · TOOL-0206Vectorsource・transform・sinkに使うobservability data pipelineです。
• 手段 · METHOD-0028Agents SDKで外部操作前に人の承認を挟む重要なtool実行を中断し、人が承認または拒否した後に再開します。
• 手段 · METHOD-0285Playwrightのtraceで失敗したテストの経緯を調べる
• 手段 · METHOD-0289Dockerのログから検証コンテナーの失敗箇所を調べる
• 手段 · METHOD-0297Bashでパイプラインの失敗を終了codeへ反映する
• 手段 · METHOD-0339GNU Parallelで独立jobの失敗と再実行対象を記録する
• 原典 · SRC-EVID-REF-0021Get StartedPythonのテスト作成・実行と失敗結果の読み方を説明します。
• 原典 · SRC-EVID-000142Human-in-the-loopツール実行を中断し、承認・拒否後に再開するSDKの経路です。