要点

  • draft-ietf-regext-balance-02は、ログイン中のEPPクライアントが利用可能残高、現金残高、与信枠、任意の実行下限と通知しきい値を照会する方式を定める。
  • 応答は自動処理に使える現在値を示すが、個々の仕訳、算定時点、為替レートの出所、規則の版、引当済み債務までは示さない。
  • その値が有料コマンドの許否に影響するなら、レジストリとレジストラは、当時の計算・規則・セッション・結果を結ぶ「資金状態証憑」を別途保存すべきである。これはIETF草案の要件ではない。

連休前、レジストラが大量の更新を流す。直前の残高照会はプラスだった。何件かは成功し、次の一件は資金条件で拒否された。運用担当にはEPPの取引IDがあり、経理には元帳があり、顧客対応には画面の数値がある。それでも、拒否時にどの引落し、引当て、換算レート、下限が効いたのかを一つの記録から説明できないことがある。

問題は計算式の誤りとは限らない。プロビジョニングを担う通信手順と、その背後にある会計システムの境界に証拠が落ちているのである。

REGEXT作業部会の提案は、この境界の表側を揃える。2026年8月14日公開の第02版は、現在ログインしているクライアントが自身の資金状態を取得する拡張を記述する。標準化過程を想定した作業部会Internet-Draftであり、まだRFCではない。特定レジストリへの導入を示す資料でもない。

独自ポータルやメール通知だけに頼らず、ドメインを操作する同じEPP接続で支払能力を確認できる意義は大きい。しかし、表示形式が共通になっても、判断理由まで共通の証拠になるわけではない。

利用可能額は履歴ではなく、計算された能力である

草案はbalanceAvailableをcreditLine + cashBalanceと定義する。現金残高はサーバー運営者がクライアントのために保有する資金、与信枠は運営者が認める信用である。料金は負、返金と入金は正、出金は負として表す。

単なる「残高」より精密な語彙だ。信用を考慮した支払能力と、顧客が負う未払残高を混同しない点も重要で、後者はこのマッピングでは使われない。

一方、XMLには現金残高を作った登録料、更新料、返金、入金、調整の明細がない。残高の基準時、締め済み期間、争点となっている請求の扱い、未計上だが引当て済みの処理も示されない。クライアントはサーバーが提示した値を読めるが、その応答だけで同じ値を再計算できない。

情報表示だけなら、この限定は不自然ではない。だが、作成や移管、更新を実際に止めるなら、残高は事業の制御面に入る。制御に使う値には、表示の簡潔さとは別に、後から追える由来が必要になる。

実行下限はゼロとは限らない

任意のexecutionLimitは、有料のクライアント取引を拒否し得る境界を示す。既定値は0.00だが、正にも負にも設定できる。

正の下限は、ゼロになる前に余力を残す仕組みだ。草案は、サーバー側から発生する自動更新などの取引を例に挙げる。表示上の利用可能残高が正でも、新しいコマンドに全額を使えるとは限らない。将来の自動処理に備えた余白が守られるからだ。

負の下限は逆に、残高がゼロを下回っても一定範囲で有料取引を許す。実際の許否は残高、下限、対象処理の価格を組み合わせて決まる。

応答は現在の下限を見せても、その設定過程は見せない。誰が承認したか、いつ変わったか、自動更新の引当額をどう見積もったか、商品別の差や障害時の例外があるかは分からない。

しかも残高照会は予約ではない。照会後に別セッションが資金を使うことも、帳簿が更新されることもある。残高以外の規則でコマンドが拒否される場合もある。したがって、照会成功を将来の受理保証として扱ってはならない。

低残高通知は受領の記録であって合意ではない

任意のnotificationThresholdを越えると、サーバーは低残高メッセージを生成できる。basedOnは実行下限と同じ基準でなければならない。通知だけ現金残高、停止だけ利用可能残高という見えにくいずれを防ぐためである。

メッセージはEPPのポーリングキューを使う。基本仕様により、キュー投入日時やメッセージIDが応答に入り、コマンドと応答にはクライアント側・サーバー側の取引IDが付く。クライアントは通常のpoll手順で確認する。草案は、しきい値を越えた時に一度通知し、照会のたびに繰り返さない構成を採る。

これは警報疲れを抑える。しかし、確認できるのはメッセージの配送と処理までだ。経理担当が理解したこと、入金したこと、残高計算に同意したこと、後の拒否時にも同じしきい値だったことは証明しない。

「届いた」「人が認識した」「内容に同意した」「不足を直した」は別々の事実である。キューの確認記録に、それ以上の意味を持たせるべきではない。

通貨内訳にはレートの来歴がない

複数通貨を扱う場合、現金残高を通貨別に分解できる。各要素は通貨、金額、換算レート、参照通貨での換算額を持ち、その合計がcashBalanceと一致しなければならない。方式は直接表示で、元通貨の一単位にレートを掛けて参照通貨額を得る。

これにより、利用者は提示された足し算を確認できる。ISO 4217の通貨コードも単位の取り違えを防ぐ。だが、レート提供者、観測時刻、丸め規則の版、市場データ障害時の代替値は応答にない。残高自体にも明示的な基準時刻がない。

下限から十分離れていれば影響は小さい。境界に近いと、換算のわずかな差が更新一括処理の可否を決める。通貨インフラが名前空間の運用を左右するのに、その依存関係を後で検証できない。

EPPを為替取引基盤にする必要はない。ただし、実際に制御を働かせたレートの出所と時刻は、権限のある証拠システムに残すべきだ。

機密性が調査資料を分断する

草案は財務情報を機密とし、ログイン中のクライアントだけにアクセスを限定する。他社の現金や与信枠を見せないための正しい原則である。

同時に、障害調査では記録が分かれる。接続代行会社はセッションを知るが資金を所有しない。経理は仕訳を知るがコマンド順を知らない。レジストリは下限規則を知るが、元帳全体を共有できない。各主体が部分的な真実だけを持つ。

全面公開でも、EPPへの元帳複製でもなく、契約当事者だけが扱える狭い証憑が必要だ。詳細な帳簿より少ない情報で、残高画面より多くを証明する設計にできる。

判断に使った資金状態を固定する

私は、残高に関する規則が有料EPPコマンドを警告、許可、拒否した時に「資金状態証憑」を生成することを提案する。これはガバナンス上の提言であり、Internet-Draftの要件ではない。

まず、認証されたクライアント、セッションまたはセキュリティ文脈、残高応答のclTRIDとsvTRID、取得時刻、参照通貨、利用可能残高、現金残高、与信枠、実行下限、通知しきい値を結ぶ。複数通貨なら、各金額、適用レート、出所、観測時刻、丸め規則を保存する。

次に、EPP外の根拠を参照する。変更不能な元帳スナップショットまたは明細参照、重要な未処理の借方・貸方、自動更新の引当て、政策版、暫定例外である。商取引の全明細をコピーする必要はなく、ハッシュや管理された参照で完全性を守ればよい。

最後に、対象コマンドを固定する。オブジェクト種別、料金の根拠、要求時刻、判断時刻、結果、EPP結果コード、クライアントとサーバーの取引IDを残す。資金以外が原因なら明記し、照会から判断までに残高が変わったなら両方を保持する。

これで「資金不足だった」という説明を検証可能な時系列に変えられる。並行実行、換算、引当て、計上遅れ、政策変更のどこに差が生じたかを双方が特定できる。

プロトコルを小さく保ち、組織の記憶は失わない

このマッピングは照会専用で、check、create、delete、renew、transfer、updateに残高固有の処理を定めない。料金体系の違いをEPPに押し込まない、妥当な境界である。

危険なのは不足したXMLではなく、標準化された数字が支援窓口や自動化にとって唯一の真実となり、成立条件が保存されないことだ。表面が統一されるほど、内部規則の差は見えにくくなる。

第02版は中心語をbalanceからbalance availableへ改め、basedOnを加え、名前空間を0.3へ更新した。「利用可能」は会計残高ではなく、条件付きの操作能力であることをよく表している。次に必要なのは、その条件が決定権を行使した瞬間を記憶することだ。

出典