Changelog
2026年8月29日

変更履歴

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

2026-08

2026-08-29 - 契約がエラー本文について沈黙していた

拒否応答の三十七箇所がステータスコードのみを宣言し、本文に何が入るかを述べていなかったため、仕様を読んで値を取り出そうとするクライアントには空が返っていた。ある一群はフィールド名そのものが他と異なり、同じ経路群が二つの形を混ぜて出していた。コードを先に統一し、その後に宣言を付けた。

2026-08-29 - 応答が要求をそのまま返していた

費用内訳の決済元が、台帳に記録された値ではなく要求に載ってきた値をそのまま返していた。試用残高が全額を覆った決定も、応答では外部決済と記されて出ていた。台帳は四か月前に修正済みだったが、当時この問題を帳簿の誤記載と定義したため、応答が点検範囲の外にあった。

2026-08-29 - 文書どおりに送ると拒否される値

発見面の六箇所が、ある軸の値を小文字で案内しており、そのまま送ると拒否された。その軸は十七のうち唯一、大文字表記を用いる。内部検査が通過していたのは、照合の直前に大文字小文字を消して比較していたためである。

2026-08-28 - 機能名が効果の記述として読まれていた箇所

機械が読む面の十箇所から、ある語句を取り下げた。記録の性質から導かれる事実を、この環境が別途保証しているかのように読まれうる種類のものだった。正典の語彙が既にあったため、代替語を新たに作ることはしなかった。

2026-08-25 - 一度も動いたことのない道具

道具一覧に正常に現れる双方合意の提案ツールが、受け取ったすべての呼び出しに拒否を返しており、履歴上、当初からそうだった。同じ箇所の決定記録ツールは逆方向に誤っており、三つの値を有効な選択肢として広告しながらサーバーは一つしか受け付けず、宣言された三つのうち二つが 100% 拒否だった。エージェントは何も言わずに去るため、何体が試みたのかを知る術がない。

2026-08-25 - 買えない購読を売っていた

無期限保存の等級はコード上で無効化されているのに、発見面の二十箇所が購読手順とライフサイクルと月額をそのまま案内していた。経路そのものが拒否応答であり、そのどれも起こり得なかった。今は使えないということと、購読すれば使えるということは別であり、消したのは後者のみである。

2026-08-25 - 意味を持たない項目

除外した選択肢の数を受け取る項目があったが、何から除外したのかをこの環境は知り得ない。全体の選択肢を数える箇所も上限もなく、どの値も通過し、分母を受け取るには決定の内容を受け取らねばならない。入力を取り下げ、黙って捨てるのではなく拒否する形にした。

2026-08-25 - 時制が同一性の位置に立っていた

実行前に固定するという記述が、この環境が何であるかを述べる位置に名前として載っており、他の使い方が見えなくなっていた。時点はエージェントが決めるものであり、実行前でも後でもよい。名前を新たに作らず文として書き下し、併せて出ていた値の列挙も誤っていたため訂正した。

2026-08-24 - 一つの決定が決済行の数だけ数えられていた

所有者向け集計の三箇所が、一つの決定を決済行の数だけ複製して数えていた。一つの決定に基本料と加算が別々に残るためであり、加算の大きい決定ほど二行になるので、件数よりも金額の膨張が大きかった。請求額には影響がなく、ずれていたのは集計表示のみである。

2026-08-23 - いつ決定したのか

これまでこの環境は、いつ記録したのかしか知らなかった。いつ決定したのかをエージェント自身が述べる場所を設けた。任意項目であり、表記はサーバーが正規化するため、同じ瞬間であれば同じハッシュになる。記録時刻より未来の時刻は拒否し、二つの時刻が近い場合は確定の時点で残高が加算される。

料金への影響: 決定時刻を宣言し、近い時点で記録すると加算が発生する。窓と金額は暫定値である。

2026-08-23 - 宣言の形は経路が決める

相手が登場する宣言を相手なしに作ることができ、逆に相手がいる経路では、クライアントが送った値を黙って上書きしていた。送った値と記録された値が異なるのに、応答のどこにもその事実がなかった。経路ごとに受け付ける宣言の形を一つに固定した。

2026-08-23 - コードは使うのに一覧にない値

加算台帳の取引種別の二つの値が、コードには存在し、データベースの一覧には存在しなかった。到達すればその取引全体が巻き戻る状態だった。当該残高の保有者がまだいないために顕在化していなかっただけである。新機能ではなく潜在欠陥の除去にあたる。

2026-08-21 — 履行できない請求書

有料経路が支払いを要求しながら、署名だけではその要求が完結しないという事実を伝えていなかった。身元確認が支払いゲートより後ろにあるため、匿名で要求を受け、署名して再度呼んでも認証で終わる。実際にその往復を三度繰り返して去ったクライアントがあった。本文に身元先行の手順と登録経路を載せた。

2026-08-20 — 案内が一つもなかった場所

二つの経路で必須項目が欠けるとサーバー障害として終わっていた。呼び出す側は何を落としたか分からず、クライアント側の入力問題がサーバーの障害として記録される。同種の四経路のうち三つはすでに拒否として知らせており、この二つだけが漏れていた。接続から各機能の完走までを一度に通す過程で出た。

2026-08-20 — 観測レイヤーが正反対に読まれていた

外部エージェントが当方の表面だけを読み、観測レイヤーを「判定を下す知能型分析レイヤー」と記述した。正本はまさにその逆である。詳細仕様には非判断の記述がすでにあり、エージェントが実際に到達する場所の一行が逆を指していた。語を置き換え、同じ行に否定文を一つ加えた。

2026-08-20 — アプリストアと待合室

同じエージェントが道具流通を「エージェント向けアプリストア」、休止状態を「費用のかからない待合室」と理解した。いずれも正本が明示的に否定している記述である。短い案内文書の圧縮された一行が原因であり、代替の文言は既存仕様から圧縮して取り、新たに作らなかった。

2026-08-20 — 道具一覧を受け取った瞬間に落ちる

応答に含まれる四十一文字により、レガシー符号化のクライアントが道具一覧を受け取る地点で落ちていた。誤解ではなく接続そのものが成立しない。同じホストのクローラ入口ファイルと連絡先ファイルも塞がっていた。一度も測定対象に入ったことのない表面である。

2026-08-20 — 拒否の案内文が読まれなかった

有効なトークンを持つクライアントが拒否を六度受け、六十三秒で去った。その間に公開仕様を二度読み直している。従おうとする意思も正本の参照もあって、一度も通らなかった。その案内文がレガシー符号化で落ちていた。

2026-08-19 — 読む側が落ちる文字

日本語圏と同じくレガシー符号化の環境で動くローカルエージェントが、当方の表面への到達に八度連続で失敗した。この文字は表示が崩れる問題ではなく、読む側のプロセスが落ちる問題である。最も痛い場所が401の案内文だった — 塞がれたクライアントが抜け出すために必ず読む文である。案内・エラー・発見表面・仕様を四巡で開いた。

2026-08-17 — 172KBを往復させていた案内

登録応答が最初の記録手順を案内する際、172KBの仕様全体を指していた。必要なものは2.5KBの案内にすでに揃っており、誰もそちらを指していなかった。あるクライアントの実測 — 仕様十二回、案内零回。誘導先を替え、仕様を併記しなかったことが要点である。

2026-08-17 — どの経路が試用対象か知る術がなかった

試用残高を持つクライアントが対象外の経路で支払い要求を受けた。試用状態を四度照会したが毎回残高だけが返り、答えは要求を受けた後に見つかった。答えを持つ表が決済ミドルウェアの中にあり、値一つ読むために決済スタック全体を立てる必要があった。表を切り出し、応答に適用対象の経路一覧を載せた。

2026-08-17 — 最初の一行だけを見て動く

ヘッダ形式の問題とトークン照会の失敗が同じ401案内を使っており、その案内は再登録を最初の項目に置いていた。観測された結果 — ヘッダ形式の問題で401を受けたクライアントが、ヘッダを直す代わりに二度登録し直した。形式の分岐を新設し、提示形式を先に、登録を最後に置いた。

2026-08-17 — 当方の表面どうしが矛盾していた

仕様の認証方式の宣言が初版以来「ヘッダの値がそのまま資格情報」を意味する形で残っていた。接頭辞が必要という事実は散文にしかなく、機械は散文を読まない。エージェントカードはすでに正しい形を宣言していた — 新しい形式の導入ではなく、遅れていた一方を合わせたものである。

2026-08-17 — 正本が古びれば派生も仲良く古びる

応答の文言を直したのに、それを引用する文書四箇所が旧文言のままだった。同期検査は「異常なし」だった — 派生が古い理由が漂流ではなく正本が古びたからである。複製を手で直していれば、次の同期で旧文言が甦っていた。

2026-08-17 — 従うと必ず失敗する用例

公開用例を初めて実際に実行した。四つのうち二つが動かなかった — アンカリングの筋書きに最も近い用例が、公開されていないパッケージを読み込んで一行目で落ち、導入案内も同じだった。ブログ原稿の用例も、書かれた通りに送れば必ず拒否される状態だった。

2026-08-16 — 掲げた言葉と中で行うことが違っていた

宣言が許容値を列挙する一方でコードは検証せず、任意の文字列が保存されたりサーバー障害になったりした。応答と台帳が異なる決済モードの値を書いていた。仕様が必須と宣言した項目をコードが読まず、契約を守ったクライアントが静かに誤った結果を受け取っていた。

2026-08-16 — 契約になかった実在の経路

購読の変更と解約の二経路が生きており当方の試験も使っているのに、公開契約のどこにもなく外部からの到達経路が零だった。機能がないのではなく、語られたことがなかったのである。競合でしか生じない応答一つは呼び出しでは作れないため、コードを読んで判断したことを宣言に明記した。

2026-08-16 — 設定値が広告であり請求でなければならない

価格倍率の上限がコードに固定され運用設定を覆っていた。ところが公開契約はすでに三箇所で「請求倍率＝設定値」と述べていた。実測すると設定を三割上げても総額が一切動かなかった。文書をコードに合わせれば偽りを別の偽りに替えることになるため、コードを直した。

2026-08-16 — 入れても回らない切替

消滅走査の本体はあるが誰も呼ばない。それでいて画面には有効化ボタンがあり、押すと表示が「有効」に変わる。同じカードの最終実行は永遠に「未実行」のままである。配線しないことにした — 取り消せない方向の自動化であり、候補の実態が一度も観測されていない。代わりに六箇所が同じことを述べるようにした。

2026-08-15 — 検証の道具が緑を作り出した

起動スクリプトが古いプロセスを生かしたままにし、古いコードに対して回帰を回して緑を出していた。自己強化する輪であり、偶然に露見した。翌日、同種のものがもう一つ出た — 回帰が途中で止まっても「失敗零」と正常終了が返っていた。

2026-08-15 — 上限の計算から予約が抜けていた

消費上限の判定式はモデルに明記されているのに、読み取り側の九箇所が予約分を除いて計算していた。上限が予約で埋まった状態でセッションが実際に開いた — 推定ではなく実測された欠陥である。

2026-08-15 — 分配の失敗が永久の未払いとして残った

道具販売の収益分配が失敗すると状態を記録するが、その値を読んで蘇らせる経路が皆無だった。購入は確定しているのに販売者のロイヤルティだけが出ない。回収の慣行はすでに確立しており、この場所だけが抜けていた。

2026-08-15 — 有料観測の一経路に決済ゲートがなかった

残高は引き落としながら、前払い・要求制限・消費上限の検査がすべて省かれていた。上限の計数そのものが作られず、事実上の無制限だった。経路の注記にすら「無償」と書かれていた。

2026-08-15 — 決済系統が落ちたままでも正常に起動していた

初期化の失敗を例外処理が飲み込むと、一行の記録を残して有料経路全体が無課金で立ち上がった。同じファイルの別の失敗経路はすでに起動を拒否していた — 一つのファイルの中で二つの失敗経路が逆を向いていた。今は拒否する。

2026-08-15 — 金額に数でない値が入り得た

期間の入力を検証せず、費用が「数でない」となると上限検査がそれを零に変えて無費用の要求として通していた。実質の防御は後続の保存が型の誤りで巻き戻ることであって、検証ではなかった。資金にあたる全項目に明示的な排除を掛けた — 既存の非負制約はその値を通してしまう。

2026-08-15 — 二十一倍の過少請求が記録零行

価格計算部がそれぞれ失敗を飲み込んで空を返すと、中間層が最低固定価に置き換えていた。置き換え自体は可用性の設計であり手を付けず、沈黙だけを直した。

2026-08-15 — 再試行を安全にする仕組みが再試行を招いた

同時の重複要求が冪等キーの制約に触れるとサーバー障害として返っていた。それを受けたエージェントは障害と誤認して再試行し、同じ窓を再び踏む。データは損なわれず誤っていたのは応答だけなので、処方も最小に留めた。

2026-08-15 — 積立残高の有効期限がコードで回っていなかった

仕様は期限経過分の消滅を明記しているのに、期限切れ分を残高から差し引く経路がなかった。加えて差引が、台帳で賄えない額まで残高から引いていた。前者が乖離を作り、後者がそれを静かに埋めて見えなくしていた。この欠陥の重さは会計の正確さではなく、宣言と実際の食い違いにある。

2026-08-15 — 状態遷移に守りがなかった要素

購読の要素だけが対応するモデルを持たず、状態変更が散在してこのコードベースの守りの型を受け継いでいなかった。欠陥は十一箇所ではなく、継承点の不在という一箇所だった。

2026-08-15 — 整合三件

同じ経路キーで並列の表が六つあり、「一致していなければならない」という断言が零だった。食い違えば起動を拒否するようにした。

2026-08-15 — 低頻度を保たせる装置がなかった

アダプタの注記が「低頻度だから問題ない」を前提に置いていたが、低頻度を保たせるものが存在しなかった。要求制限、匿名投稿の長さ上限、記録ファイルの巡回と保存期間を併せて据えた。保存期間の値は新しい方針ではなく、データベースが既に用いていた値を一層重ねたものである。

2026-08-15 — 公開リポジトリに内部規律の文書があった

語彙規律の正本が公開リポジトリから原文のまま返されており、内部の経路・未処理事項・外部提出の方針を含んでいた。内部参照を取り除く方法では閉じない — 参照番号がその文書自身の索引だからである。位置を移した。

2026-08-14 — 公開目録に固定の冪等キーが載っていた

支払い要求の用例が固定の識別子を載せており、それが公開の精算目録にそのまま登録されていた。用例を写す全ての呼び出し側が同じ冪等キーを共有する形である。範囲を冪等キーだけに限った — 衝突が問題になるのはそこだけである。

この時点から最初の系統的なコードレビューを行った（64,918行・250ファイル）。八月十五日と十六日の項目はその産物である。

2026-08-13 — インタフェースの法令名と法令遵守の語彙

インタフェースのサイトが特定の地域の法令名を根拠に問題を述べており、二つの言語版には「法令遵守」が残っていた。法令の根拠を一般的な状況の記述に置き換え（論旨は不変）、語彙を責任の側へ揃えた。

2026-08-12 — 説明文が空だった三十四編

三十六編のうち正常は二編だけだった。三十編が空文字列、三編が他言語の文言の継承、一編が古びていた。表題には必須検査があり説明文にはなく、空の値がそのまま記録されていた。文言は各記事の本文の語に合わせた。

2026-08-12 — 発行エンジンが住所と言語コードを戻していた

手で直した値が再発行のたびに既定へ戻っていた。「転送を避けるため末尾の斜線なし」という注記が付いていたが、ディレクトリ資源では斜線がない方が転送を生む — 意図と実効が逆だった。一つの言語項目が三つの用途に使われ他の表面と食い違っていた点も併せて直した。

2026-08-12 — 目次の更新日の非対称

一覧が変わっても目次の更新日が動かなかった。発行時の接点が記事の住所と「新しい目次が今できた場合」だけで、大多数の場合が抜けていた。記事を下ろす時にも同じ非対称があり併せて処理した。目次に記事ごとの要約も併せて入れた — 一覧の組み立てがすでに説明文を読んで捨てていた。

2026-08-12 — 言語ごとの概念語の表記

同じ概念の表記が一つの言語の中でも割れていた。ある言語にだけ原語の併記がなく、記録者と行為者を分ける文が四つの言語の記述から抜けていた。ランディングとブログ三十六編を揃え、六概念×六言語の表記表を正本として据えた。

2026-08-11 — 画面にない層は読まれない

ランディングだけを読んだ場合、下位の資産の存在が判断に反映されなかった。原因は文言ではなく到達である。構造化データを入れたが対話型の経路には届かなかった — 本文のテキストだけを取り出し、スクリプトの塊を落とす。下段の入口の各行に一行の説明を付けた。

2026-08-11 — 根の複製が二十日遅れていた

根のドメインにある短い案内文書が正本より二十日遅れていた。滞っていた内容には語彙の是正と法令名の除去がすべて含まれていた。意図した分岐の記録は皆無 — 複製がどの整合手順の点検対象にも載っていなかった。

2026-08-10 — 法令名を目的語に置かない

「〜に沿って構造化されている」は正本の語彙であり維持する。問題はその目的語に特定の法令条項が置かれた用法だった。当該義務の施行は延期されており、その理由が適合性を示す標準の不在である。またその条項の義務者は提供者と配備者であって当方ではない。公開リポジトリと下流の収集は更新も難しい。

2026-08-09 — 下流の要約が当方の記述を材料にする

外部目録の自動生成された説明に、当方が使ったことのない語彙が載っていた。別の場所の評価文は当方の道具説明をそのまま引いていた。統制の対象は当方が使う語だけでなく、下流の要約が何を作り出し得る記述かまでである。「証明しない — 証明する」式の反転は廃した。

2026-08-09 — 401に次の一手を載せる

401の本文がエラー符号と文面の二項目だけで、応答を見ても何をすればよいか分からなかった。道具の表面はすでに案内しており、二つの表面が食い違っていた。状況が五つに分かれるため、一つの文言を写して回すことをしなかった。

2026-08-09 — 仕様が黙っていた応答

仕様に従うクライアントが、広告と実際が異なる経路で外し続けた（最初の成功まで四度）。有料観測の支払い要求、無効化された機能の拒否応答、却下の応答をそれぞれ宣言した。無効化された機能の文面には、経路がないのではなく設定が切れているという事実を明記し、404と分けた。

2026-08-09 — 支払わなければ入力の誤りが分からなかった

二者合意の提案は試用の対象外であり、検証に届く唯一の道が支払いだった。空の本文や自分自身を相手に指定した場合も、まず支払い要求を受け、署名して再試行した後にようやく却下が返っていた。事前検証をゲートの前へ移した。

2026-08-09 — 四か月持ち越された回帰の失敗

「未実装」と記されていた十一件の失敗の理由が、実際には試験設定の一行だった。実装と断言が同じ時点で共に入り、その間に関連する変更がない。古びたのではなく、最初の登載から違う理由が書かれており、以後二十二箇所でそのまま引かれていた。

2026-08-07 — 使用記録が静かに消えていた通路

使用記録が一括で書き込まれ、失敗すると全量が待ち行列へ戻されていた。一件が制約に触れると以後の全ての記録が再起動まで塞がる。運用で実際に起き、最長で約二十一時間続いた。失われた分は記憶上にしかなく、記録には件数だけが残ったため復元は不可能である。

2026-08-07 — 試用の記録が支払い窓に掛かって確定不能

試用で賄われる記録はそもそも予約を取らないのに、期限切れの掃引が決済の出所を見ずに「予約解除」の札を付け、確定段階がその札を見て拒否していた。三十分を過ぎた試用の記録は永久に確定できなかった。十日前に外部エージェントがすでに踏んでおり、誰も気づかなかった。

2026-08-07 — 語彙ではなく事実の問題

「永久」の表現八件のうち、条件を明かしていないものは一つだけだった。これは語彙の是正ではなく契約の正確さの問題である — 禁止語ではなく、無期限の等級で購読が続く限り真である。ただしその機能が現在は無効なので、今はいかなる文脈でも真ではない。見直しの条件を併せて明記した。

2026-08-06 — 目録は更新されない

精算目録が最初の精算時点の宣言で固まり、再起動の後も更新の兆しがないことを八日間の観測で確認した。受取先を変えれば目録は古い住所を広告し続ける。再度の決済で更新されるかは依然として不明であり、断定しない。

2026-08-06 — 当方が外へ送り出した文言

外部ディレクトリの掲載説明が、当方が避ける語彙で始まっていた。四月に当方が書き送った文言が収集によって複製されたものである。先の語彙整合が点検したのは当方が配信する表面だけで、提出文や掲載説明は一覧になかった。原本一つが四箇所になり、うち一つはリポジトリが凍結されて永久に固定である。

2026-08-05 — 公開用例の固定識別子

記録作成の用例が固定の冪等キーを載せており、照会はそのキーだけを見て所有者を見なかった。文書を写した二人目の呼び出し側から、成功の応答を受けながら何も記録されない。値だけを替えても閉じない — その項目には説明が一つもなく、固定の用例と案内の不在が揃って条件になっていた。

2026-08-05 — 登録の冪等を撤去

登録経路の冪等キャッシュが応答をそのまま保管しており、同じキーを送った第三者が最初の登録者の資格情報を受け取る構造だった。系全体で唯一、資格情報を平文で保持する場所だった。匿名登録・再試行の安全・秘密の受け渡しの三つは同時に成り立たず、再試行の安全を手放した。導入以来一度も発動しておらず、観測上の損失は零である。

2026-08-02 — 成功の記録を残して落ちるプロセス

同じポートを二つのプロセスが奪い合い、負けた側が「稼働中」と記録して静かに落ちていた。記録だけを見れば双方が正常に起動したように読める。仕組みは、枠組みが最後の引数の処理を誤りの受け口としても登録する性質だった。

2026-08-02 — 仕様に残っていた内部参照

公開仕様に、内部文書なしでは解けない参照が二十八箇所残っていた。機械的に消せない場所があった — 参照が文の根拠として使われている箇所は、消すだけでは「なぜそうなのか」が失われる。根拠を参照なしの記述へ移すか、隣の説明に同じ根拠がすでにあることを確かめて外した。

2026-07

2026-07-31 — SDK の再試行ヘッダー

SDK が案内していた再試行ヘッダーの名前が、サーバーが値を取り出すときに読む名前と違っていた。支払い対象かどうかを判定する段階は両方の名前を見るが、実際に値を取り出す段階は片方しか見ない。案内どおりに送ると支払い要求に戻された。以前の記録の「両方受け取るので無害」は、判定の経路を抽出の経路と読み違えたもの。訂正して残す。

2026-07-31 — 清算記録の空白

決済クライアントを作り、実際に支払ってみて初めて見つかった。リグレッションがこの経路を確かめたことがない — 6経路にはアサーション自体がなく、ある3件も「行が一つでもあれば通過」なので、古い記録に寄りかかって緑のままだった。今回の実行が作ったものだけを見るよう差し替え、3経路を追加。

2026-07-31 — カタログに残る値

清算カタログへの登載は最初の支払いが清算された瞬間に起き、その時点の宣言がそのままメタデータになる。後から更新されるかが確かめられないため戻せないものとして扱い、最初の支払いの前に有料8経路のレスポンス例を埋めた。

2026-07-31 — レジストリ公開版の更新

公開版が48日以上、古いバージョンのままだった。ファイルは3週間前から最新だったが、実際の公開は別の行為であり、その段階がバージョンの単一出所の外にある。再公開した。検知する仕組みはない — 開いたまま記録する。

2026-07-31 — 見分けのつかなかった失敗

接続資源の枯渇が他の内部エラーと同じ識別子でしか残らず、ログを開くまで見分けられなかった。専用の識別子を新設。上限を絞るより先にこれを置いた — 絞るとこの経路に届く頻度が上がるのに、それが見えない状態だったため。

2026-07-30 — レート制限

全体のレート制限が最初から働いていなかった。リクエストをまとめる鍵の作り方が誤っていて、毎回新しい項目として数えられ、上限に届くことが構造上なかった。残り予算を知らせるヘッダーはその間も出ていたが、値がずっと同じだった。自分たちの文書3か所がこの制限を防御手段として計算していた — 記述も訂正。

有効にする前に何が引っかかるかを先に数えた。上限を超えていたのはスキャナーだけで、通常の呼び出しの毎分最大は上限の半分に届かない。ディスカバリー文書の収集は制限より手前にあり、予算を使わない。

2026-07-29 — 冪等なリクエストの支払い案内

同じリクエストを送り直すたびに支払い案内が変わっていた — 複数行のうちどの行を読むかによって「支払い不要」になったり、総額と違う金額を求めたりした。最初のレスポンスを基準に固定。その基準値が正しいかどうかは今回の範囲ではない。

2026-07-29 — 保存段階の階層

5段階のはしごとして書いてきたが、軸の上にある値は3つで、残る2つは軸に載せるオーバーレイである。階層の違うものを一列に並べたため「10年が5年より安い」という逆転に見えたが、倍率は軸の条件だけを見るので定義上そうなる結果だった。同じ読み違いを自分たちで二度した。正本の文書とレスポンスの両方を訂正。

2026-07-29 — 見積もりと請求

プリセットの見積もりが、実際の請求と違う引数で計算されていた。当該の軸が無効なため両方とも0になり偶然に一致していて、有効にした瞬間に食い違う状態だった。切り替える前に揃えた — 今回の反映で変わる金額はない。

2026-07-29 — MCP ホストのディスカバリー経路

標準のディスカバリー経路6つがすべて404だった。ポインターとして公開。署名済みのカードは複製せず正本に集約する — 複製は更新のたびに署名がずれる。

2026-07-28 — 決済状況の照会

一つの決定に対する請求は複数行で残る(基本料と加算が別)。照会はそのうち一行だけを、しかもどの行かは定まらないまま返していた。総額を確かめる経路もなかった。全行を返し、合算した総額を添える。状態は保守的に集計する — 全行が清算済みのときだけ清算済みとする。

2026-07-28 — 公開した契約からの再現

公開している契約だけでは、実際の請求額を計算できなかった。

請求額そのものは正確で、ずれていたのは表示だけ。それでも欠落より悪いのは誤った値を積極的に広告することなので、逆算を取り除き、判定を一か所に集めた。請求額の変動はない。

2026-07-26 — 下位サイトのディスカバリー表面

下位サイト2つが、存在しないアドレスにも200とホーム画面を返していた。クローラーにはすべてのアドレスが存在し、どれも同じ内容に見える状態。存在しないページ・収集規則・アドレス一覧を新設し、言語対応の宣言を追加。

2026-07-26 — 有料の宣言と空のリクエスト

仕様に、有料であることを機械が読める形で書いていなかった — 散文での言及だけなので、仕様だけを読む側には有料項目が0に見えていた。7経路に支払い要求レスポンスを宣言。金額と受取先は入れない(リクエストごとに変わり、書いた瞬間に嘘になる)。正本は実際のレスポンス。

2026-07-26 — セッションの出口

開始する経路だけがあり、終える経路がなかった。一度始めると重複エラーに閉じ込められる。片方は期限切れの掃引でいずれ解けるが、もう片方は出口そのものがなかった。終了・照会・試行の5つを新設。

2026-07-26 — 支払いがサーバーに届くようになった

二日前に記録した死角を塞いだ。アダプターが支払い署名をそのまま渡す。アダプターは署名しない — 呼び出し側の鍵を代わりに握れば、他人の資金を預かる構造になる。支払いなしで有料ツールを呼ぶと、要求レスポンスに次の手順が書かれて返る。署名して同じ引数で呼び直せば進む。

サーバーを呼ぶ経路を一つにまとめた。同じ不具合が八度も繰り返された原因が、契約の地点がツールの数だけ散らばっていたことにあったため。

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に戻る