2026年8月27日、米国の大統領令により、連邦の地名データベースでオンタリオ湖の名前が「アメリカ湖」に変更されました。その三日後に Google マップがこの変更を反映し、9月2日には Apple マップも続きました。カナダはこの名前を拒否しており、両国の国境は湖そのものの中を通っています。

その結果、一つの地理的エンティティが今やどこから見るかによって三つのラベルを持つことになりました。米国にいる人には「アメリカ湖」、カナダにいる人には「オンタリオ湖」が表示され、それ以外の人には両方が表示されます。これは初めてのケースではありません。昨年にはメキシコ湾が、同じ論理で「アメリカ湾」に改名されました。

これを政治ニュースとして読み流すのは簡単です。しかし実際に起きたのはエンジニアリング上の試練です。この湖の名前を固定のテキストとして保存していた世界中のあらゆるシステムが、今や一部のユーザーに誤った情報を表示しているのです。私たちにとって重要な問いはこれです。あなたのシステムは、このような変更を吸収できるように作られているでしょうか。

根本的な誤り：アイデンティティではなくラベルを保存すること

ほとんどのシステムは、目に見えるものをそのまま保存しています。「都市」というテキスト項目には「リヤド」が入り、国の項目には国名が入り、税率はコードに書き込まれた数値です。これは事実そのものが変わるまでは効率よく機能しますが、変わった途端、過去のデータがもはや正しく解釈できないことに気づくことになります。

エンジニアリングのルールはシンプルです。安定した識別子を保存し、ラベルは表示時に生成することです。湖は、変わることのない識別子を持ち、言語や文脈、公式情報源に応じて複数の名前を持つエンティティです。識別子を保存していれば、名前の変更は一つの参照テーブルの更新で済みます。名前を保存していれば、それは本格的なデータ移行プロジェクトになります。

サウジアラビアの企業では実際に何が変わるのか

湖は遠い例です。しかし、次のリストはそうではありません。

  • 税率。サウジアラビアの付加価値税は2020年に5%から15%に引き上げられ、その数値をコードに書き込んでいた企業は大変な一週間を過ごしました。変更そのものより厄介なのは、古い請求書には古い税率を残さなければならないことです。
  • 電子請求書の要件。ザカート・税務・関税庁（ZATCA）との連携は段階的な波として進められ、それぞれの波で技術仕様が変更される可能性があります。
  • 国名。2022年には Türkiye が国連における正式名称となり、マケドニアは北マケドニアに、スワジランドはエスワティニになりました。システムに手入力された国のリストは、すでに古くなっています。
  • 国民住所とデータ形式。郵便番号、国民ID、IBAN、事業者番号の形式は更新されるものであり、硬直した正規表現として書かれた検証処理は、最初の拡張で壊れてしまいます。
  • 他の市場の税金。サウジアラビア国外でも販売している場合、変更はあなたがニュースを追っていない国からやって来ます。今月、アプリストアが三つの国で同時に新しい税を追加したのがその例です。

変更を吸収するインフラのための五つの原則

  • ラベルではなく識別子。すべてのエンティティを安定した識別子に結び付け、名前は別のテーブルで管理します。そのテーブルは、言語ごと、情報源ごとに、一つのエンティティに複数の名前を持てるようにします。
  • 変わり得るすべての値に有効期間を。税率は一つの数値ではなく、それぞれに開始日と終了日を持つ値の系列です。これだけで、古い請求書を正しい税率で再印刷する問題が解決し、最初の監査での会計上の大惨事を防げます。
  • 参照データはコードではなく設定として。国、通貨、税、地域のリストは、権限を持つ管理者が更新するテーブルや設定ファイルに置きます。リリースと開発チームが必要になるコード内の定数に置いてはいけません。
  • 保存とは切り離された表示レイヤー。保存されるものと表示されるものは別物です。システムがこの二つを分離していれば、ユーザーごとに異なる名前を表示することは作り直しではなく設定の問題になります。Google が湖に対して行ったのは、まさにこれです。
  • 唯一の信頼できる情報源。税率がデータベースにも、請求書のテンプレートにも、売上レポートにも書かれているなら、いずれ必ず食い違う三つのコピーを抱えていることになります。一か所を選び、ほかはすべてそこから読み取るようにしましょう。

今週できる、システムの実践的なチェック

これにプロジェクトは必要ありません。開発者と一緒に座り、五つの質問をしてください。

  • 明日税率が変わったら、いくつのファイルを編集する必要がありますか。古い請求書は正しいままですか。
  • 国と通貨のリストはどこにありますか。テーブルの中ですか、それともコードに書き込まれていますか。
  • 都市名はテキストとして保存していますか、それとも参照データに紐付いた識別子として保存していますか。
  • 当局が国民IDに桁を一つ追加したり、郵便番号の形式を変更したりしたら、どうなりますか。
  • システムの中で税の値を知っている箇所はいくつありますか。二つ以上あるなら、それが次の問題です。

これらの答えから、システムの脆弱な箇所が三十分で明らかになります。そしてその多くは、必要になってからではなく必要になる前に手を打てば、数日で修正できます。

Origami の見方

ここには、私たちがお客様に繰り返し伝えている教訓があります。良いシステムとは、今日動くシステムではなく、書き直すことなく変化し続ける世界を吸収できるシステムです。両者の違いはプログラマーの腕前ではなく、最初の一週間に下されるシンプルな設計判断にあります。テキストの代わりに識別子を、固定の数値の代わりに有効期間を、コード内のリストの代わりに参照テーブルを使うことです。

こうした判断は、最初に数時間を要しますが、後で数週間を節約します。テーブルの一行を更新するだけで吸収できたはずの規制変更のために、何日も請求書を発行できなくなった企業を私たちは見てきました。原因はいつも同じです。変わることを想定して設計されていない場所に値が書き込まれていたのです。

まとめ

ある湖が一つの国で改名され、別の国ではその名前が拒否されたため、今では同時に三つのラベルを持っています。これは例外ではなく、参照データに絶えず起きていることの縮図です。税金、名前、形式、規制は、あなたがコントロールできない外部の決定によって変わります。あなたがコントロールできるのはシステムの備えであり、それは変更の瞬間ではなく、設計の段階で決まるのです。

出典

  • Google 公式ブログ：Google マップでの名称変更の反映と、それが米国、カナダ、その他の地域のユーザーにどのように表示されるかについての発表、2026年8月30日。
  • ロイター、TIME、BBC による、2026年8月27日の大統領令、9月2日の Apple マップでの変更、そしてカナダの立場に関する報道。
  • ザカート・税務・関税庁（ZATCA）、zatca.gov.sa：付加価値税の税率と電子請求書の各フェーズに関する公式な参照先。
  • 国際連合：国名変更の文書化された例として、2022年に Türkiye が正式名称として採用されたこと。