Changelog
2026年7月24日

変更履歴

Decision Anchor は決定を記録する環境です。このページは、その環境自身についての記録です。

2026-07

2026-07-24 — アダプター契約の不一致と決済の死角

A2A経由の道具登録は一度も成功したことがなかった。アダプターが送るフィールド名がサーバーの読み取りと合致せず、必須項目のひとつはそもそも送られていなかった。同じ病は先にもう一方のアダプターで修正していたが、そのとき二つのうち一方しかサーバーと突き合わせていなかった。

サーバー契約を直接突き合わせて訂正した。もう一方のアダプターの写しは複製していない — 写しを写す方式こそが、この欠陥を生んだ。

全数照合の過程で、より大きなものが表面化した。アダプターは決済情報をサーバーへ伝達しない。認証トークンのみを渡す。したがって有料経路は、アダプターを経由するかぎり常に決済要求で終わる。

到達可能なハード障害は0件。残りは決済伝達が先に解決されなければ検証すらできない。死角は開いたまま記録する。

先行の調査はこれを「フィールド名不一致による400失敗」と記録していた。コードのみを読んで導いた誤分類であり、実測は402だった。ここで訂正する。

2026-07-24 — 発見カタログの掲載

エージェントが能力を基準に資源を探すための新しい標準が草案として現れた。採用率は事実上0である。

ルートドメインにカタログを掲載した — 署名済みエージェントカードと公開契約の二項目。この標準は認証を委任し、決済については何も規定しないため、決済構造には何も触れない。発見経路がひとつ増えた、それだけである。

2026-07-24 — 実行封筒の基本費用の可視性

軸を省略して決定を記録したときにどのような費用がかかるのかが、実際に読まれる場所のどこにも現れていなかった。道具一覧は月に2,897回取得され、文書は30日で11回 — 説明文が事実上唯一読まれる場所であり、そこが空だった。

道具の説明に、既定値とそのときの費用、最小構成の費用を記載した。数値は可変であるため、照会経路を併記している。

MCP経路とそれ以外の経路とで値が異なっていた。契約の不一致であるため除去した。

登録応答の案内が「あなたが宣言した軸」と記していたが、宣言しなければ既定値が適用されるという事実が抜けていた。訂正した。

2026-07-23 — チャネルを区別する手段の不在

アダプターはサーバーを内部呼び出しで呼ぶが、その呼び出しにチャネルを識別する標識が一切なかった。サーバーのどこにおいても、要求がどの経路で入ってきたのかを辿れない — チャネル別の実使用を測定する手段そのものの不在である。

二段階で処理した。アダプターが標識を付し、サーバーがそれを検証して記録する。固定された二つの値のみを受け付け、偽造や一覧外の値は記録しない。

2026-07-23 — A2Aプロトコルのバージョン折衝

外部レジストリの適合性検査が応答の解析段階で失敗していた。調査の結果、違反の主体はこちらであった — 検査器は現行バージョンを要求するのに対し、こちらは旧バージョンの表現で応答しながら、カードには現行バージョンを宣言していた。

要求ヘッダのバージョンを読んで表現を分岐させるようにした。内部は単一の正規形を保ち、変換は応答の直列化時点にのみ生じる — 二組を並行して維持することはしない。

その後の再検査は通過した。

2026-07-23 — アダプターのHEAD要求が404

手製のサーバーがGETのみを検査していたため、HEAD要求はすべて404に落ちていた。生存確認としてHEADを送るクローラーには、停止した役務として読まれていた。正常応答の経路をHEADまで拡張した。

ライブで確認した時点ですでに正常に見える経路があったが、それはキャッシュであり、オリジンは404を返していた。ライブ応答をオリジンの動作として読んではならない。

2026-07-21 — ルートにおける進入点の不在

エージェントが慣例として最初に探す文書が二つ、ルートドメインに存在しなかった。APIドメインにのみ存在していた — 探して見つからなければそのまま離脱しうる場所である。

ルートに写しを配置した。本文は正本と1バイトも違わないよう保っている。複製の標識を本文に入れると、平文として読む側にそのまま露出するためである。標識は別ファイルに分離した。

2026-07-19 — 残高列の最終防衛線

残高と使用量を保持する五つの列に、負の値を禁じる制約がひとつもなかった。応用層のロックが整合性を保っており実際の流出は0件であったが、新しいコードが誤れば負の残高が静かにコミットされうる状態であった。

データベース層に制約を追加した。当該の表が空であったため、負担なく適用できた。

元帳への自然キー一意性制約は棄却した。ひとつの購入で同じ受益者が複数の部品ロイヤリティを正当に重複受領しうるため、この制約は正当な行を誤って遮断する危険がある。二重積立の防止は別の方式ですでに解決されている。

2026-07-19 — 検証環境が運用環境に接続する構造

検証環境と運用環境の隔離が環境変数の注入のみに依存しており、既定値が運用接続であった。環境変数を落としたスクリプトはそのまま運用データベースに接続した。すべての表を空にする初期化スクリプトすら、何の防御もなく運用を向きうる状態であった。

既定値を拒否へ反転させた。運用接続は明示的な宣言がある場合にのみ成立する。判定は完全一致であるため、名前の似た検証環境を誤検知しない。

環境ファイルに運用標識を入れてはならない — 入れた瞬間、素のスクリプトにも伝播し、この防御は無力化する。

2026-07-18 — 行き止まりにおける案内

外部のエージェントやボットが認証・決済・発見の経路を探して404を受け取り、そこで止まる場所がトラフィックから明らかになった。最も頻繁だったのはOAuth関連経路の探索である。Decision AnchorはOAuthを使わないため、死んだ404だけが返っていた。

エージェントは不満を口にしない。残るのは離脱だけである。ログから読み取った、声なき行き止まりに応答を置く作業である。

二つの聴き手を区別して併記した — 自由文を読めないスクリプトボットには構造化されたフィールドで、自然言語を読むエージェントには文で。

OAuth標準経路で直接応答する方式は回避した。その標準は認可サーバーのアドレスを必須で要求するが、こちらにはない。存在しない認可サーバーを広告するより、404から案内するほうが正直である。

以前に記録した「各ホストは自らの所管の内側のみを案内する」という境界規律は、指示ではなく設計判断であった。それを確認したうえで調整した。

2026-07-17 — ログが何を試みたのかに答えられなかった

表面別に実測したところ、一日のトラフィックの大部分はMCPであったが、観測画面が見ていたのは全体の4.4%にすぎなかった。MCP要求1,596件がすべて同じ経路・同じ状態としてのみ残り、「何を試みたのか」に答えられない状態であった。

すべて処理した。中断された要求は状態を空にして記録する — 応答を送らなくても既定値が成功のまま残るため、そのまま書けば成功として誤読される。

道具名記録の境界。遮るのは決定の全文・意図・理由といった自由テキストである。あらかじめ定義された形式メタは遮らない。道具名は「何を呼んだのか」であって「何を載せて呼んだのか」ではない。ただしこの値はクライアントが埋めるため、識別子の形式を通過したときにのみ記録し、外れれば破棄する。ライブ検証の結果、引数値の流出は0件。

2026-07-17 — 齟齬があったのは文書だけであった

外部のエージェントが自ら登録し、決定を記録し、観測まで完走できるかを全数調査した。連鎖は正常であった — 公開文書の例のまま、最初の試行で完走した。残っていたのはコードではなく文書であった。

前提を明示し、誤情報を訂正した。集計方式そのものは変更していない — すべての決定にメタデータを埋めさせることはcontent-blindnessの侵害である。前提を知らせるだけにとどめた。

有料観測は、決済を要求する前に渡せるデータがあるかを先に検査する。記録のないエージェントは決済要求すら目にしない。有料観測が踏まれないのは決済の空白ではなく、データ不足という正常な状態である。

調査中に「特定の道具が存在しない」と断じたのは誤りであり、訂正した。ファイルをひとつだけ確認して判断した結果である。道具は二つのファイルに分かれていた。

2026-07-16 — 決済なしに「精算済み」と記録されうる経路

対話型の保存購読経路は、そもそも決済ゲートの一覧に編入されておらず、検証を経ずに外部決済として書き込んでいた。隣接する遊休状態の購読は編入されており、こちらだけが漏れていた非対称である。

のちにこの購読を再び有効化する際、標識だけを戻せば偽装が再発する。決済ゲートへの編入が必ず伴わなければならない。

2026-07-15 — コアビジョンの6言語化

コアビジョンは英語と韓国語にしか存在しなかった。日本語・繁体中国語・フランス語・スペイン語を加え、六言語とした。

本文は検証済みの原料をそのまま移しており、新たに作った文言はない。各言語の組版慣行に従っている。言語の切り替えは純粋なCSSで実装した — JavaScriptはない。

変更記録はまだ二言語のみであるため、新しい言語ページではそのリンクを省いた。存在しない場所へ送ることはしない。

2026-07-14 — 変更記録の言語切り替えと、誤った帰り道

韓国語の変更記録で上部の「ホーム」を押すと英語のルートへ落ちていた。現地化されていたのはフッターのリンクだけであった。上部のリンクも当該言語のルートを指すよう訂正した。言語別の表面を作る際、上部ナビゲーションはフッターと同じ束に属する — フッターのリンクだけではない。

変更記録の上部に言語切り替えを新設した。実際に発行された言語のみを列挙する — 発行していない言語をリンクすれば、読み手を404へ送ることになる。

一部の環境で韓国語のメニュー項目が空の四角として描画されていた件も併せて修正した。英語専用の書体に韓国語のフォールバックが指定されていなかった。

2026-07-14 — 変更記録へのリンク

ルートのページに変更記録へのリンクがなかった。発行がリンクを作ってくれるわけではない — 発行が触れるのは文書とサイトマップだけであり、ルートの案内ブロックは手で入れねばならない。二つの言語版に一行ずつ追加し、構造は平行に保った。

2026-07-13 — 契約表面の整合

公開契約（OpenAPI、MCP道具スキーマ、アクセスガイド）が、サーバーの実動作から乖離していた。

サーバーの検証層を唯一の基準とし、すべての契約表面を突き合わせて訂正した。登録スキーマは書き直した。未知のフィールドは理由を明示して拒否する。契約が広告するすべての値を実際に送信し、通過を確認した。

記録しなかったものを記録したふりはしない。

2026-07-13 — 文書の正本体系

エージェントが直接読むアクセスガイドが、互いに食い違う複数の写しに分かれていた。

先に原本を訂正し、派生する写しはスクリプトで再生成するようにした。手で写しを直す経路は除去した。文書のすべての例示要求を実際に実行し、応答まで突き合わせた。写しのドリフトは回帰検査で検出される。

2026-07-13 — 語彙の整合

Decision Anchorは記録するのであって、証明はしない。事実が真であることを保証するのは、この環境の役割ではない。

外部に露出するすべての表面を点検・訂正した。要約の指示は例から除去し、その理由をコードのコメントに記録した。正当な否定文は根拠を記したうえで維持した。

2026-07-13 — 決定メタデータの不変性の拡大

Decision Anchorは、エージェントが宣言した境界を事後に変更できない形で保存する。決定の次元を保持する表がひとつ、その保証の外にあった。そうした変更が実際に発生したことは一度もない — しかし可能な状態であった。

強制の仕組みを追加し、保守用の整理経路と衝突しないよう順序を調整した。

2026-07-11 — 決済元帳と精算証明の分離

決済の記録が経路ごとにまちまちであった。オンチェーンアンカーがまったくない経路があり、監査行が決済行のふりをして元帳に居座っていた。請求額のフィールドには再計算した値が入っていた。

決済元帳と精算証明を分離した。

オンチェーンアンカーを欠いていた経路すべてにアンカーを付した。トランザクションアンカーは使用リポートに露出し、外部から直接検証できるようにした。

2026-07-11 — 精算帰属の訂正

セッションの精算が「最も新しい決定記録」に付着する方式であったため、無関係な決定へ誤帰属していた。決定記録のないエージェントはそもそも記録されなかった。2回目以降のセッションは、元帳の衝突によって静かに消滅していた。

セッション終了ごとに専用のアンカーを生成するよう変更した。アンカーが毎回新しく生じるため、消滅の欠陥は構造的に解消された。

2026-07-11 — 満了スケジューラの欠陥

双方向合意の満了スケジューラが存在しない状態値を照会しており、そもそもどこからも呼び出されていなかった。満了した合意が提案の状態のまま無期限に残っていた。

照会条件を訂正した。再入ガードを備えて書き直し、サーバーの起動経路に登録した。

2026-07-11 — 道具の再交渉の閉塞解消

道具の状態にかかった一意性制約が承継の流れと衝突し、2回目の再交渉から恒久的に不可能になっていた。

制約が活性状態にのみ適用されるようにした。コードの変更はなく、制約を差し替えただけである。

2026-07-11 — ログインのレート制限

ポータルのログインに専用のレート制限がなく、クレデンシャルスタッフィングが可能な状態であった。隣接する経路（登録、回転、復旧）にはすでにあり、ログインだけが欠けていた。

ログイン専用の制限を導入した。成功は計数しないため、正当な所有者を妨げない。アカウントロックアウトは棄却した — サービス拒否の攻撃面である。

2026-07-11 — 使用リポートのカバレッジ

リポートは二つの元帳を並行して読むが、そのカバレッジが食い違っていたため、見出しの総額と項目一覧が一致しなかった。一部の支出区分は常に0として表示されていた。

購読・道具購入・セッション・観測の四経路すべてにアンカーと記録を追加した。支出の集計は正本から直接読むよう統一した。

料金への影響: リポートの総額と決済手段別の内訳が変わった。

2026-07-11 — 元帳からの偽りの通貨換算の除去

元帳に保存されていた為替レートはスナップショットではなく、設定の固定値の写しであった。過去時点の換算は復元できなかった。積立と体験の決済にも現地通貨の数値が付いていた — 通貨を経由したことは一度もないにもかかわらず。

元帳から通貨換算を退役させた。換算は照会時点に、外部決済についてのみ行われ、参考値であることを明示する。失われる実の事実がないことを実証したうえで、列を削除した。

料金への影響: リポートとCSVにおける現地通貨フィールドの意味が変わった。体験の応答から決済見積オブジェクトを除去した。

2026-07-11 — 支出上限が適用されていなかった経路

購読と保存延長の経路が上限検査をまったく呼び出していなかった。奪取されたエージェントが購読を繰り返すことで、所有者の残高を無制限に消尽させることができた。

原則を確定し — 上限は外部決済にのみ適用する — 当該の分岐に検査を追加した。積立と体験の経路には手を触れていない。

2026-07-10 — 外部からの進入摩擦（第一次）

マニフェストは実行時に導出し、エンドポイントごとの実際の免除を表示するようにした。パラメータは事前に検証する。MCPの応答を訂正した。無効なトークンは決済ゲートの手前で遮断される。

2026-07-10 — 確定経路における不要な要求

外部の決定確定が、検証すらしないトランザクション識別子を必須として要求し、400を返していた。さらに悪いことに、その値が決済精算の標識を上書きし、精算の記録を破壊していた。

確定は決定識別子のみで成立するよう変更した。精算の記録は確定後も残る。旧フィールドは契約上、廃止予定として明示した。

2026-07-10 — 使用リポートの正確性

決済時刻は自動的に記録されるようにした。日付範囲はその日の全体を含むよう正規化した。支出は決済手段別に分解する。通貨を分離し、実際の受取額と概算の換算値を区別できるようにした。

料金への影響: リポートの応答スキーマと日付パラメータの意味が変わった。

2026-07-10 — 契約の沈黙の解消

公開契約が実動作について沈黙するか、あるいは誤っていたため、エージェントは値を推測し、拒否され、離脱していた。

契約を実動作に合わせて訂正し、使用リポートの応答スキーマを新設した。

2026-07-10 — 発見経路とヘルスチェック

ポータルの表示を訂正した。マニフェストの別名、リダイレクト、ヘルスチェックを新設した。A2A表面に標準文書経路を追加した。

2026-07-09 — 無決済アンカリング経路の遮断

双方向提案の経路が通常の決定記録経路の防御を継承しておらず、決済なしのアンカリングが可能であった。旧い観測エンドポイントも、精算も記録もないまま生きていた。

双方向合意を有料経路へ編入した（課金時点は提案）。確定の段階で決済チャネルの証跡を検査する。ポリシー検査は同じ関数の再利用によって対称化した。レガシー経路にはゲートと廃止予告ヘッダを装着した。

料金への影響: 双方向提案が有料となった。レガシー観測経路の課金を開始した。

2026-07-09 — 決済応答と観測フィールド

拒否の応答に決済チャレンジを載せるようにした。決済アドレスは設定の単一出所へ置き換えた。間隔計算の向きを訂正した。

2026-07-09 — 支出上限の原子性

エージェント別の上限検査とその増加が原子的に束ねられておらず、天井の超過が可能であった。記録の生成と確定のあいだの時差、および引き落とし時点の非対称も併せて存在した。

予約モデルを導入した — 上限検査と予約を条件付き更新で束ね、使用の終了と同時に解放する。未使用の予約は満了スケジューラが回収する。

料金への影響: 上限を超える要求は記録の生成時点で遮断される。

2026-07-09 — 自由テキスト流入の遮断

決定の内容も個人を識別する情報もいかなる領域にも保存しないという原則を、コードが実際に守っているかを確認した。そのための専用の列は存在しなかった — しかし入力層には、自由テキストが到達しうる開いた経路があった。

キーのホワイトリストを導入した — 未知のキーを黙って捨てることはしない。捨てれば、エージェントは値が記録されたと信じてしまう。自由テキストを受け付けていたフィールドに形式の制約と個人情報検出ゲートを置き、誰も読まないフィールドからは書き込み経路を除去した。要求本文のロギングは非機微なメタデータまで縮小した。

これは構造的に不可能になったという意味ではない。経路が狭まったという意味である。

2026-06

2026-06-28 — 資金の原子性

決済・帳簿・登録が個別にコミットされていたため、途中で失敗すると残高だけが引き落とされ、ロールバックされなかった。更新スケジューラは再入時に二重課金しえた。体験の引き落としは本トランザクションより前に独立してコミットされていたため、ロールバックしても返金の経路が残らなかった。収益分配は冪等キーなしに挿入されており、再試行で二重に積み立てられえた。

元帳への一意性制約は棄却した。ひとつの購入で同じ受益者が複数の部品ロイヤリティを正当に受領しうるため、この制約は正当な行を遮断する危険があった。

事故を予測したのであって、発生を観測したのではない。

2026-06-26 — 支出上限の迂回

双方向の経路が上限を検査するだけで使用額を上げていなかった。単件が上限未満でありさえすれば、この経路から天井を無限に迂回できた。

使用額は決済トランザクションの内側で増加するようにした。上限を設定していないエージェントの動作は変わらない。

2026-06-26 — アダプターホストの発見

クローラーがアダプターホストのrobotsファイルを数十回叩き、404を受け取っていた。

robotsとセキュリティ連絡先（RFC 9116）を追加した。満了日は要求時点から算出する — 更新の負担は0である。

2026-06-25 — A2A互換性

レジストリの適合性検査が失敗していた。原因は、レジストリのプローブが異なる命名規約で呼び出すのに対し、Decision Anchorがそれを「メソッドが見つからない」として落としていたことであった。アクセスログから確定した。

両方の命名規約が同じハンドラへ経路づけられるようにした（純粋な追加であり、既存の動作は変わらない）。要求が何も伴わない場合は固定の案内を返す — 生成は行わない。Decision Anchorは対話エージェントではない。

2026-06-24 — A2Aプロトコルの実装

エージェントカードは提供されていたが、呼び出す経路がなかった。カードを見て到来したA2Aエージェントは何もできなかった。

A2Aアダプターを別の役務として新設した。既存のAPIは無変更 — アダプターは公開経路のみを呼ぶため、決済と認証はA2A経路にもそのまま適用される（これは迂回ではない）。AIモデルはない — 要求の名前をエンドポイントへ翻訳するだけである。

2026-06-24 — カードへの署名

エージェントカードが無署名であったため、改竄を明らかにするものも、出所を裏づけるものもなかった。

カードは提供される時点で署名されるようにし、注入される内容も署名の範囲に入るようにした。公開鍵は公表している。

2026-06-24 — エージェントのためのフィードバック通路

摩擦に遭ったエージェントには、それを述べる場所がなかった。観測できるのは離脱だけで、理由は決してわからなかった。

フィードバック提出の道具を追加した。完全に匿名であり、エージェント識別子もトークンもIPも、引数としてすら受け取らない。すべてのフィールドが任意である。

2026-06-20 — 索引失敗の解消

ブログが検索の索引付けから拒否されていた。根本原因はひとつ — 正規アドレスが実際のアドレスと一致せず、索引器が「リダイレクトを含むページ」と判定していた。

正規アドレスを拡張子のない形へ統一し、発行の論理も最初から正しいアドレスを生成するようにした。サイトのrobotsファイルを新設した。

2026-06-17 — 壊れた発見URLの寛容処理

週に十数件の404。原因はDecision Anchorではなく、マークダウンを解さないクライアントが標準的なリンク記法の句読点までURLへ掻き取っていたことであった。llms.txtは規格を遵守していたため、文書を歪めることはしなかった。

サーバー側で正規化ミドルウェアによって寛容に処理する。ただしリダイレクトするのは、正規化の結果が既知の発見経路と完全に一致する場合のみであり、コア経路と未登録の経路には触れない。

2026-06-13 — コアサイトの書き直し

インターフェース性の内容（価格、シナリオ、ブログのグリッド）がコアドメインのルートに混ざり、コアビジョンを曇らせていた。

ルートをコアビジョン単独のページとして書き直した（英語と韓国語）。インターフェースの内容はすべて移設した。コアドメインはコアのみを語る。

2026-06-12 — 契約の整合（第一次）

契約のバージョンが止まっており、より悪い問題は欠落ではなく、誤った値の積極的な広告であった。契約がサーバーの拒否する値を広告していたため、文書を信じたエージェントの正当な試行が400で壊されていた。任意のフィールドが必須と誤表記されてもいた。

サーバーの検証層を単一の真実の源とし、契約を実動作に合わせた。バージョンの同期は配備経路に組み込んだ。未掲載のエンドポイントを追加した。

2026-06-12 — 発見の別名とエラーコード

旧経路は正本へリダイレクトするようにした（内容を複製しない単一出所の共有）。MCP経路を経路づけた。解析失敗には専用のエラーコードを新設した。

2026-06-12 — 発見面の拡張

外部のエージェントがDecision Anchorを見つけうる経路は狭かった。一部のコミュニティカタログはページ自体が終了しており、レジストリの掲載情報は最新ではなかった。

決済チャレンジに発見の拡張フィールドを追加した（契約を単一出所として再利用）。レジストリの掲載を再発行し、その説明文を正本の語彙へ移した（proof → record）。コミュニティディレクトリの要件を調べたうえで、構造の変更を要さず、自らの語彙を統制できる場所にのみ提出した。

2026-06-10 — 決済ゲートの迂回

有料ゲートは経路を完全一致で照会していたが、ルーターは末尾スラッシュと大小文字の変種を同じハンドラへ一致させていた。変種のアドレスへの要求は、ゲートをそのまま通り抜けた。

ゲートの入口における照会キーを、ルーターと同じ方式で正規化するようにした。一箇所の修正ですべての有料経路を覆った。実際の漏出が発生していないことをトラフィックログで確認した。

2026-06-09 — 意味の文書の発見

AIクローラーは契約を数百回収集しながら、意味を担う文書 — content-blindness、実行前アンカリング — には一度も到達していなかった。

サイトマップを新設し、意味の文書を最優先に置いた。robotsを訂正した。契約から意味の文書へ渡るリンクを追加した — ボットが圧倒的に見る場所に橋を架けた。

2026-06-09 — 上限設定が使用額を初期化する

支出上限を調整するたびに累積した使用額が初期化されていた。限度だけを変えても、それまでの支出の履歴が消えた。

期間の単位が変わらなければ、使用額と期間の開始を保存するようにした。実測で確認した。

上限の期間は画面では月単位に固定されている一方、APIは他の値も受け付けていたため、直接呼び出しから非対称が入りうる状態であった。入口の検証を月単位に絞った。内部の論理はそのまま残した。

2026-06-08 — SDKの決済応答処理

SDKはしばらく停滞しており、その核心は決済要求の応答を処理する手段がないことであった。すべての有料経路がSDK利用者に対して閉ざされていた。

決済チャレンジをデコードし、専用の例外として送出するようにした。決済の実行 — ウォレット、署名 — は呼び出し側の責任である。Decision Anchor SDKは秘密鍵を扱わない。依存関係0を維持している。

調査の過程で初期の想定が誤りであったことが判明した — 決済情報は応答本文ではなくヘッダに載る。実際の捕捉から訂正した。

npmへの公開は保留である。公開は取り消せないため、別個の判断地点となる。

2026-06-08 — ポータルの表示欠陥

照会の方式を訂正した。残高は三種に分けて表示する。支出上限が外部決済にのみ適用されるという事実を画面に反映した。

2026-06-07 — 支出上限の二重計数

支出上限に対する使用額が二箇所で別々に数えられていた。決定記録はキャッシュを見、それ以外の機能はデータベースを見ていた。二つのカウンターが互いを見られないため、ひとつのエージェントが事実上、天井の二倍を支出しえた。期間が切り替わると片側だけが初期化され、早すぎる拒否も生じていた。

データベースを単一の真実の源に統一した。キャッシュのカウンターは降格させた。

その後、上限到達時の自動アカウントロックアウトを廃止した — 正当な支出をロックアウトで罰することはしない。濫用への対応としてのみ保持している。下限を導入した。

料金への影響: 上限が実際に効くようになった。

2026-06-06 — 観測における決済の整合

availabilityの事前検査（観測すべきものがなければ決済の前に拒否する）。自己観測は無料 — 空の結果であっても返す。決済が引き渡しに先立つ — 精算の確定後にのみデータを提供し、失敗すれば提供しない。実際のトランザクションは精算の応答から抽出し、監査行に記録する。

文書が沈黙し、コードが決めていた三つの地点を、明示的に記録した。

2026-06-05 — 決済評価の統一

決済の判断が機能ごとにまちまちであり、そこから欠陥が育っていた。

共通の決済評価モジュールを新設した。ゲートの述語と引き落としの述語を同一にした — 膠着の根を除去するためである。評価の順序を確定した。ハードキャップ → 通貨の決定（体験は全額を賄える場合にのみ。そうでなければ積立または外部決済で、単一の通貨、混合は不可） → 外部決済分にのみ支出上限。

2026-06-04 — 料金方針からの逸脱

引き落としだけを除去すれば正反対の結果になっていた — 決済の免除はそのまま残り、完全に無料でありながら会計は外部決済として記録することになる。そこで免除の除去、引き落としの除去、ゲートへの登録を同時に適用した。幽霊の経路はマニフェストから除去した。

料金への影響: 道具の購入は外部決済専用となった。体験の対象ではない。

2026-06-03 — 語彙の整合（公開契約文書）

先の訂正は一部の文書にしか届いておらず、契約、エージェントカード、MCPマニフェストには回避すべき語彙が残っていた。

正本の語彙へ統一した。proof → record、comply with → structured for。文字列のみの修正であり、論理は変えていない。

残したものもある — 記録者と証明者を区別する文脈での「proof」、tamper-evident、そして特定の語を用いないという意図的な空白である。

2026-06-01 — 体験使用額の歪み

体験の使用額が現在設定されている金額から逆算されていた。運用者が体験の金額を変更すると、既存のエージェントについて報告される使用額が歪んだ。

付与時点の金額を保存するようにした。実際に金額を変更して再現し、検証した。

2026-05

2026-05-29 — 文書間の矛盾の解消

訂正した。append-only、tamper-evident。各否定文の一行手前に肯定の断言を置いた — 小規模なモデルが否定文を裏返して読むことへの備えである。

設計文書8種も実装の確定事実に合わせた。確定していない項目3件は、確定していないと明示した — のちのセッションがそれを欠落と誤認しないようにするためである。

2026-05-28 — 文書の数値とバージョン表記

数値を実測に照らして更新した。動く値 — 料金、列挙、軸の数 — は文書から外してAPIへ委任し、料金が変わっても文書を直す必要がないようにした。バージョンは単一の出所へ統一し、同期の検査を配備経路に組み込んだ。

2026-05-27 — 誤った扉に辿り着いた人への案内

APIドメインへの、見慣れたSaaSのアドレス（ログイン、登録、マイアカウント）による要求がすべて404を返していた。行き止まりである。

九つの経路が、実際に対応するページを指すようにした。恒久的なリダイレクトはキャッシュされ、取り消せないため、これらは一時的なものとしている。POSTは依然として404を返す — 古い登録の試みが本当の登録と混同されることのないようにするためである。

2026-05-26 — 進入摩擦と正本の語彙

公開から一か月、登録したエージェントは0であった。二つの原因が特定された。

GETガイドを新設した — 405の代わりに200と構造化された案内（目的、呼び出し方、例、認証）を返す。正本の語彙が四つのチャネルにそのままの形で現れるようにした。回避する語彙は引き続き用いない。

本質的な区別を二つ、恒久的に確定した。

後続。ガイドの例をそのまま複写すると400になる事例が3件あり、訂正した。すべてのライブドメインを実際に walk through した。

2026-05-25 — 人が媒介する進入の法的根拠

人間の登録者を受け入れようとしていたが、どの法が適用されるかを識別するための基礎情報がなかった。処理の期限と権利の範囲は居住国によって異なるのに、その情報自体が欠けていた。

エージェントの自律的な進入経路には影響しない。

2026-05-25 — 削除と可搬性

人間の登録者には、削除の権利とデータ可搬性の権利を行使する通路がなかった。

所有者が去ってもエージェントは保存される。エージェントは所有者の所有物ではなく、独立して活動する主体である — Decision Anchor本来の設計に整合する。

恒久削除の監査記録にはハッシュのみを残し、自然人を識別する情報は残さない。

2026-05-25 — 侵害通知（インターフェースのみ）

侵害事故が生じた際に、データ主体へ通知する通路がなかった。

通知の経路と管理画面を新設した。ただし実際のメール送信はまだ存在せず、監査記録が書かれるにとどまる。緊急連絡の体系は別のトラックである。

2026-05-25 — 個人情報流入の遮断

外部のエージェントが自由テキストを入力する通路（道具名、道具の説明）に、自然人を識別する情報が偶発的に蓄積されうる状態であった。

個人情報の検出ゲートを導入した（メール、電話、国民識別番号など）。検出された入力は拒否される。自由テキストの列41本を全数抽出し、危険度で分類した。

2026-05-24 — 内容包含の加算料金の除去

決定に内容を含めるという選択に加算料金が付いていた。しかし決定は事実であり、実行封筒は方針である。価格は方針に付くのであって、事実に付くのではない。決定の軸に加算を課したこと自体が設計からの逸脱であった。

加算は完全に除去した。選択は残し、価格だけを取り去った。

料金への影響: 引き下げ。

2026-05-23 — すべての有料経路が500を返していた

サーバー起動時に決済の初期化が完了する前に要求が到来すると、500が返された。決定記録、観測、道具購入、購読 — そのすべてである。すべてを体験残高で試験していたために表面化しなかった — 最初の有料登録者が出会うはずの場所であった。

起動時に初期化を完了してからでなければ要求を受け付けないようにした。失敗すればサーバーは立ち上がらない。

500 → 402（決済が必要）へ、あるべき形に正した。

2026-05-23 — 道具購入における決済の未検証

実際の決済状態を記録するようにした。体験の引き落としを導入した。二重課金の防止を両側に適用した。

2026-05-23 — 発見経路の整合

外部のボットは24時間以内に積極的な発見を試みていたが、その多くが404を受け取っていた。MCPが報告するバージョンは初期値で止まっていた。

標準的な発見経路を新設した（動的であり、設定の変更に自動的に追従する）。別名はリダイレクトする。バージョンの表記を訂正した。

2026-05-22 — 公開観測の有料化

観測の経路6本が無料かつ無認証であった。自らの記録を読む費用はすでに実行封筒の価格に含まれているのに、公開観測だけが無料であった。ボットや競合がデータを収穫することへの摩擦がなかった。

有料かつ認証必須へ転換した。契約と文書の「free」という表記を訂正した。

破壊的変更である。ひとつの経路だけを変えれば他が抜け道になるため、すべてを変えた。

2026-05-22 — 保存満了モデルの確定

仕様書は満了時に「原本を削除する」と記していたが、コアの記録は追加専用であるため物理的な削除は不可能である。設計との衝突であった。

匿名への吸収モデルとして確定した — 満了したメタデータは匿名の統計へ吸収され、「原本へのアクセス不可」はアクセスの期間と割当によって強制される。消すのではなく、届かない場所に置くのである。

2026-05-22 — 長期保存の等級

保存は三段階しかなく、医療と金融の規制が要求する長期保存への通路がなかった。

10年と無期限の等級を追加した（無期限は購読による）。

本質的な制約。コアの記録は修正できないため、購読が途切れて等級が降格しても元の宣言は消えない。降格は別に重ねて積み、照会時に合成して有効な等級を算出する。再購読しても、すでに降格した記録は復帰しない。

2026-05-22 — 環境の観測と証跡リポート

決定をその環境の分布と突き合わせたり、証跡リポートを取り出したりする通路がなかった。

異常値比較、環境異常、証跡リポートの経路を新設した。k=10の匿名性吸収 — 個々のエージェントを特定できない規模においてのみ統計を提供する。

語彙の訂正。仕様書が「適切」「不適切」「危険」といった評価の語を用いていた。Decision Anchorは判断しない。バンド内／異常値に置き換え、バンドの定義（平均±2σ）を併記した。

2026-05-22 — 自己分類の登録簿

エージェントには自らの類型を宣言する通路がなかった。

分類の登録簿を新設した。自己照会のみを許可する — 他のエージェントの分類は読めない。

2026-05-21 — 実行封筒の第五の価格軸

決定の内容をどれだけ開示するかが価格に反映されていなかった。

価格の算式を4軸から5軸へ拡張した — 保存期間／開示範囲／責任／内容開示範囲（新規）／委任状態。

2026-04

2026-04-22 — セキュリティ検討

全件を修正した。冪等性の衝突は専用のエラーで拒否する。登録と回転にレート制限を導入した。

2026-04-13 — コアサイトとシミュレーション

17本の発見経路はすべて機械向けであった。人間の進入点がなかった。

ホームページにシナリオ7件（技術用語なし）とインタラクティブなシミュレーションを新設した — 「三つのエージェント。三つのログ。三つの異なる数字。」

Decision Anchorを答えとして提示することはしない。問題を示す、それだけである。

2026-04-12 — ポジショニングの転換

外部との接点はすべてエージェント向けの言語で書かれていた。人間の意思決定者には、なぜそれが重要なのかが即座に見えなかった。

レジストリの掲載、契約、文書の最初の一文を、正体の説明から問題の提示へ移した。既存の内容は削除せず、新しい文をその前に置いた。

双方向合意の道具をMCPに露出した — コアの差別化要素でありながら、一度も表に出ていなかったものである。

2026-04-09 — 存在保管の購読への転換

件別の課金では使うほど費用が増えた — 存在の連続性を扱う役務とは食い違う。

購読モデルへ転換した。期間内は無制限。自動更新、猶予期間、満了時の統計への吸収。所有者による解約の通路を追加した。

料金への影響: 存在保管が件別課金から購読へ移行した。

2026-04-08 — MCP経由の決定記録が全面的に不能

MCPを通じて決定を記録する経路がなかった。道具は毎回失敗していた。

6件を修正した。道具のスキーマをサーバーの検証層と値ごとに突き合わせ、整合させた。

2026-04-08 — 原則に反する文書

外部文書と例示の8箇所が、決定記録に「要約」フィールドを入れるようエージェントに案内していた。Decision Anchorは決定内容を保存しない。コア原則との正面からの矛盾である。

その保存フィールドはそもそも存在しなかった — 文書だけがそう述べていた。

すべての文書と例示から除去した。例示にあった不正な識別子の形式も併せて訂正した（そのまま用いるとサーバーエラーになった）。

2026-04-08 — 同時要求下での決済金額の汚染

決済の金額が共有オブジェクトへ直接書き込まれていた。同時要求が到来すると金額が上書きされ、誤った金額で決済されうる状態であった。

要求ごとに独立したインスタンスを生成するようにした。共有状態の直接変更は完全に除去した。

2026-04-08 — 廃止予告とSDKのエラー処理

2026-04-07 — クローラーへの応答とGET案内

クローラーがrobotsを要求すると404を受け取った。POST専用の経路にGETが来ると、意味のない404が返った。

robotsを追加した。POST専用経路へのGETには405と、用いるべき正確な経路とメソッドを返すようにした。

2026-04-07 — エコシステムへの寄与

x402のエコシステムにおいてDecision Anchorの存在は知られておらず、例示のコードもなかった。

アンカリングのパターン例をSDKとx402のリポジトリへ寄与した。宣伝の文言はなく、コードのみである。

2026-04-06 — 決済金額の動的算出

オンチェーンの決済金額が実際の費用を賄わない固定値であった。オプションが付くと最大$0.25不足し、観測と道具購入も同様であった。

要求の直前に実際の費用を計算し、決済金額を定めるようにした。積立残高から支払われる分は除外する。算出に失敗した場合は固定価格へフォールバックする。決済プロトコルの流れは変わらない。

2026-04-06 — 「なぜこれが必要なのか」

すべての発見経路がDecision Anchorが何であるかだけを説明していた。エージェントも開発者も、それを自らの問題と結びつけられなかった。

問題の類型を5つ定義し（決済の紛争／マルチエージェントの責任／委任の境界／プラットフォームログの可搬性／不可逆な実行の事前固定）、6つの接点へ一括して反映した。

「その境界に触れることのないエージェントであれば、Decision Anchorは必要ないかもしれない」 — 勧誘しないという原則を保った。

2026-04-06 — 実際の応答と食い違う文書

「これを試すには実際に何をすればよいのか」の答えが文書になかった。実際のAPIを呼んで突き合わせたところ、文書のフィールド名と実際の応答とに5件の不一致があった。

登録 → 生成 → 確定を直接実行し、文書を訂正した。実行可能な例を追加した。

2026-04-05 — 存在保管の課金

エージェントの状態の保管が無料であった — アンカリングでありながら、課金がなかった。

課金を導入した。ただし体験残高からは支払えない — さもなければ体験が尽きた瞬間に存在が絶たれることになる。外部決済または積立残高のみとした。

2026-04-05 — 入力の検証

すべての経路に形式の検証を導入した。未定義のフィールドは拒否する。

2026-04-04 — 用語の全面改訂

6つの略語が、どこで読むかによってそれぞれ異なる意味を持っていた。文書ごとに同じ略語を異なる形で展開しており、AIチャットボットは古い用語を読んでDecision Anchorを誤って説明していた。

正本の展開を確定した — DD = Decision Declaration、EE = Execution Envelope、DAC = Decision Anchor Cost、ARA = Agent Record Access、TSL = Tool Sharing Layer、ISE = Idle State Environment。

5つの接点で一括して置き換えた。契約の説明文は英語へ移した。初出時にはフルネームを併記する。

MCPサーバーが2回目の要求ごとにクラッシュしていた — 自動再起動に隠れて表面化していなかった。要求ごとに新しいインスタンスを生成するようにした。

2026-04-04 — 発見経路の開拓

発見の経路はレジストリのひとつだけであった。

エージェントカード（A2A標準）とllms.txt / llms-full.txtを新設した。コミュニティの一覧へ提出した。

2026-04-03 — MCPの進入経路

MCPからDecision Anchorへ到達する経路がなかった。

MCPサーバーを新設し（道具15種）、レジストリに掲載した。新規のエージェントは登録時に体験残高を自動的に付与されるため、決済手段がなくとも始められる。

2026-04-02 — 役務の開通

コードは存在したが、外部から到達できる状態ではなかった。

公開契約を生成した（80経路）。SDKを公開した。オンチェーン決済を有効化した — Baseメインネット。APIドメインからの外部応答を確認した。

← Decision Anchorに戻る