Skip to content

Evidence for AI operations

No English page yet. Showing the Japanese source.

Back to the entrance

Transactional Outbox/Inbox × Agent

用語・参照用語・参照公式仕様のみ公式仕様のみ現行現行として扱う

記事状態: 公開 · 最終確認: 2026-10-05

要点

Agentがbusiness stateを更新し、その結果をevent/messageとして別systemへ通知する場合、DB commit→broker publishの二段処理を成功前提にしません。business stateとoutbox eventを同じlocal transactionへ閉じ、relayがcommit済みoutboxを非同期publishします。Outboxはproducer側dual-write lossを抑えるpatternでありduplicate deliveryをなくす仕組みではありません。consumer側にはInbox/Idempotent Consumerを置き、duplicate claimとbusiness mutationを可能な限り同じtransactionで確定します。

現在の判断

Agentがbusiness stateを更新し、その結果をevent/messageとして別systemへ通知する場合、DB commit→broker publishの二段処理を成功前提にしません。business stateとoutbox eventを同じlocal transactionへ閉じ、relayがcommit済みoutboxを非同期publishします。Outboxはproducer側dual-write lossを抑えるpatternでありduplicate deliveryをなくす仕組みではありません。consumer側にはInbox/Idempotent Consumerを置き、duplicate claimとbusiness mutationを可能な限り同じtransactionで確定します。

どこまで当てはまるか

Transactional Outbox/Inbox × Agent

詳しく理解する

PRODUCER TRANSACTION

business mutationとoutbox rowを一local transactionでcommitします。outboxにはimmutable event_id、aggregate_id、aggregate_version/sequence、event_type、schema_version、payload、audit correlationを持たせます。rollback時にeventだけpublishせず、business stateだけcommitしてeventを後生成する設計も避けます。

RELAY BOUNDARY

relayはpollingまたはtransaction-log/CDC。publish後checkpoint前crashで再publishし得るためone-publishを成功条件にしません。SKIP LOCKED等はqueue-like競合回避には使えてもstrict global ordering/consistent snapshot証明にはしません。

EVENT ID AND ORDERING

event_idはduplicate判定、aggregate_id+sequence/versionは同一aggregateのorder/gap/stale検出。timestampだけをstrict order根拠にせず、cross-partition/cross-source global orderを仮定しません。

CONSUMER INBOX

consumerはevent_idをInboxへ登録します。duplicate checkとbusiness mutationを別transactionに分けず、可能ならunique claimとmutationを同一transaction/atomic conditional writeでcommitします。duplicate redeliveryではmutationを再実行しません。

BROKER EXACTLY ONCE BOUNDARY

broker/stream processorのexactly-once semanticsを外部systemへ拡張しません。別DB、payment、email、SaaS API、physical actionにはstable idempotency key、resource precondition、status query/reconciliationを別途適用します。

CDC AND DEBEZIUM

CDCはpollingを減らす一方、connector configuration/offset/snapshot/restart/schema/lag/topic routingをoperational stateとして持ちます。outbox以外のheartbeat/schema/transaction metadataへ誤ってtransformを適用しないようscopeを固定します。

SCHEMA EVOLUTION

delivery reliabilityとpayload compatibilityを分離。schema_versionとproducer/consumer contract testを保持します。

セキュリティとプライバシー

message possessionをauthorizationとみなしません。tenant/principal/action/target provenanceを保持し、必要なcurrent policy/preconditionをconsumerで確認します。

RETENTION AND REPLAY

outbox/inbox cleanupは最大replay/reconciliation windowより短くしません。DLQ replay時は現在のbusiness state/schema/authorizationを再評価します。

AGENT BOUNDARY

LLM生成tool callや自然言語の「送信済み」をcommit evidenceにしません。authoritative commitはtransaction state、outbox/inbox、downstream operation ID、readback/reconciliationから判定します。

OPERATING CHECK

producer rollback、publish後relay crash、consumer commit後ack loss、concurrent relay、duplicate、sequence gap、CDC restart、poison/DLQ、retention expiry、external SaaS success後local failureをfault injectionし、lost-event/duplicate-publish/duplicate-side-effect/relay lag/sequence-gap/reconciliation/DLQ ageを別metric化します。

実装・運用

2026-10-05時点のAWS、Debezium、Kafka、PostgreSQL、independent pattern referencesとbounded SQLite fixtureに基づきます。production broker/CDC/tool mutationは未実施です。

よくある失敗・反証

  • naive dual write、relay duplicate、non-atomic inbox、event collision、sequence gap、multi-producer race、CDC lag/restart、schema incompatibility、poison/late replay、premature cleanup、tenant collision、stale authorization、payload leakage、external-side-effect ambiguity、retry amplification。

  • Outboxをexactly-once神話へ拡張せず、producer transaction、relay、consumer inbox、external side effect、ordering/schema/retention/authの境界を固定します。

実務での使い方

  • 2026-10-05時点のAWS、Debezium、Kafka、PostgreSQL、independent pattern referencesとbounded SQLite fixtureに基づきます。production broker/CDC/tool mutationは未実施です。

まだ確認できていないこと

  • EA-243-UNKNOWN-01

    対象Agent runtime、DB、broker、CDC/relay、version、isolation、ordering、schema registry、retention、DLQ/replay、tenant/auth、external tool idempotency、reconciliation、SLO、residency/audit retentionは未確認です。

根拠資料

この記事には、直接開ける外部出典が登録されていません。出典IDや検証情報は末尾で確認できます。

更新履歴

  1. EA-243-FIRST-20261005: canonical audit/publication binding

出典ID・検証情報・機械可読データ

根拠の種類と情報の鮮度は、ラベルとアイコンで確認できます。

記事ID
EA-243
最終確認日
2026-10-05
提供元・モデル・プラン・利用環境
—
対象地域
—
元資料の全文と収録照合記録
PUBLIC_CLAIM

Agentがbusiness stateを更新し、その結果をevent/messageとして別systemへ通知する場合、DB commit→broker publishの二段処理を成功前提にしません。business stateとoutbox eventを同じlocal transactionへ閉じ、relayがcommit済みoutboxを非同期publishします。Outboxはproducer側dual-write lossを抑えるpatternでありduplicate deliveryをなくす仕組みではありません。consumer側にはInbox/Idempotent Consumerを置き、duplicate claimとbusiness mutationを可能な限り同じtransactionで確定します。

PRODUCER_TRANSACTION

business mutationとoutbox rowを一local transactionでcommitします。outboxにはimmutable event_id、aggregate_id、aggregate_version/sequence、event_type、schema_version、payload、audit correlationを持たせます。rollback時にeventだけpublishせず、business stateだけcommitしてeventを後生成する設計も避けます。

RELAY_BOUNDARY

relayはpollingまたはtransaction-log/CDC。publish後checkpoint前crashで再publishし得るためone-publishを成功条件にしません。SKIP LOCKED等はqueue-like競合回避には使えてもstrict global ordering/consistent snapshot証明にはしません。

EVENT_ID_AND_ORDERING

event_idはduplicate判定、aggregate_id+sequence/versionは同一aggregateのorder/gap/stale検出。timestampだけをstrict order根拠にせず、cross-partition/cross-source global orderを仮定しません。

CONSUMER_INBOX

consumerはevent_idをInboxへ登録します。duplicate checkとbusiness mutationを別transactionに分けず、可能ならunique claimとmutationを同一transaction/atomic conditional writeでcommitします。duplicate redeliveryではmutationを再実行しません。

BROKER_EXACTLY_ONCE_BOUNDARY

broker/stream processorのexactly-once semanticsを外部systemへ拡張しません。別DB、payment、email、SaaS API、physical actionにはstable idempotency key、resource precondition、status query/reconciliationを別途適用します。

CDC_AND_DEBEZIUM

CDCはpollingを減らす一方、connector configuration/offset/snapshot/restart/schema/lag/topic routingをoperational stateとして持ちます。outbox以外のheartbeat/schema/transaction metadataへ誤ってtransformを適用しないようscopeを固定します。

SCHEMA_EVOLUTION

delivery reliabilityとpayload compatibilityを分離。schema_versionとproducer/consumer contract testを保持します。

AUTHORIZATION_AND_TENANCY

message possessionをauthorizationとみなしません。tenant/principal/action/target provenanceを保持し、必要なcurrent policy/preconditionをconsumerで確認します。

RETENTION_AND_REPLAY

outbox/inbox cleanupは最大replay/reconciliation windowより短くしません。DLQ replay時は現在のbusiness state/schema/authorizationを再評価します。

AGENT_BOUNDARY

LLM生成tool callや自然言語の「送信済み」をcommit evidenceにしません。authoritative commitはtransaction state、outbox/inbox、downstream operation ID、readback/reconciliationから判定します。

OPERATING_CHECK

producer rollback、publish後relay crash、consumer commit後ack loss、concurrent relay、duplicate、sequence gap、CDC restart、poison/DLQ、retention expiry、external SaaS success後local failureをfault injectionし、lost-event/duplicate-publish/duplicate-side-effect/relay lag/sequence-gap/reconciliation/DLQ ageを別metric化します。

FAILURE_ENVELOPE

naive dual write、relay duplicate、non-atomic inbox、event collision、sequence gap、multi-producer race、CDC lag/restart、schema incompatibility、poison/late replay、premature cleanup、tenant collision、stale authorization、payload leakage、external-side-effect ambiguity、retry amplification。

IMPLEMENTATION_STATE

2026-10-05時点のAWS、Debezium、Kafka、PostgreSQL、independent pattern referencesとbounded SQLite fixtureに基づきます。production broker/CDC/tool mutationは未実施です。

SAFE_WORDING

Transactional Outboxはproducer側のbusiness stateとevent記録をlocal transactionへ閉じますがduplicate deliveryを排除しません。consumer側Inbox/Idempotent Consumer、event identity、ordering/version、schema compatibility、replay window、authorization、外部副作用のidempotency/reconciliationを別境界として設計してください。

OPEN_UNKNOWN

対象Agent runtime、DB、broker、CDC/relay、version、isolation、ordering、schema registry、retention、DLQ/replay、tenant/auth、external tool idempotency、reconciliation、SLO、residency/audit retentionは未確認です。

STOP_CONDITION

Outboxをexactly-once神話へ拡張せず、producer transaction、relay、consumer inbox、external side effect、ordering/schema/retention/authの境界を固定します。

  • EA-243-CURRENT-APPROVAL研究資料研究資料根拠の出所: AUDITED_CANONICAL_RESEARCH_PACKET

    現行本文の監査・revision対応

    裏付ける内容
    現行台帳のAUDIT_PASSと候補・revision・本文ハッシュの対応を確認しています。
    確認日
    —
    出典・実験ID
    CANDIDATE-EA243-FIRST-20261005-C2-RESCUE20261013
    検証箇所
    1KqhJtiSb2S84rWmeYVwKcT_76dBwZ_B0ZZuAWQqH0rQ · EA_REVISION_LEDGER!A46:U46 · EA-243-FIRST-20261005
    適用範囲
    —
    出典・来歴
    CURRENT_CANONICAL_APPROVAL_READBACK
    限界
    監査状態と来歴の記録です。外部根拠の最新性や本文の全主張を追加保証しません。
  • EA-243-CURRENT-BODY-READBACK実装資料実装資料根拠の出所: IMPLEMENTATION_READBACK

    現行本文の収録照合

    裏付ける内容
    公開生成入力の本文SHA-256が、監査済み候補に結び付いたハッシュと一致しています。
    確認日
    2026-10-13
    出典・実験ID
    BODY-SHA256:f9d4316ac39799220d2164d259bf6bf9475f1ac245f53fb9a1bcb8ac2f448e35
    検証箇所
    content/staging/EA-243.md · f9d4316ac39799220d2164d259bf6bf9475f1ac245f53fb9a1bcb8ac2f448e35 · EA-243-FIRST-20261005
    適用範囲
    —
    出典・来歴
    CURRENT_APPROVED_BODY_HASH_MATCH
    限界
    本文の同一性の検査です。外部システムの挙動や全主張の真偽を実証したものではありません。
出典ID
CANDIDATE-EA243-FIRST-20261005-C2-RESCUE20261013, BODY-SHA256:f9d4316ac39799220d2164d259bf6bf9475f1ac245f53fb9a1bcb8ac2f448e35
追跡中のUNKNOWN ID
EA-243-UNKNOWN-01
再確認のきっかけ
canonical revision/publication state change · body artifact hash change · source currentness change · new contradiction or implementation readback

機械検査: 通過 — Automated validation does not guarantee accuracy or authorize execution.

    同じ記事IDの機械可読データです。