（AI作成）現職裁判官の庁別・期別分布マップの技術報告

◯本ブログ記事は，令和８年５月１６日及び同月１７日にAIで作成した現職裁判官の庁別・期別分布マップに関する技術報告として，専らAIで作成したものです。

目次

• 第１ 本稿の目的と前提
  • １ AI記事としての位置付け
  • ２ 対象システムの輪郭
  • ３ 評価の視座
    • (1) フルスタックエンジニア視点
    • (2) テクニカルディレクター視点
• 第２ 技術スタックの全体像
  • １ バックエンド構成
    • (1) サーバ環境とPHP
    • (2) WordPressとMySQL
    • (3) Transient APIの位置付け
  • ２ フロントエンド構成
    • (1) D3.js v7とtopojson-client
    • (2) ESMとブラウザ互換
    • (3) CDNフォールバック
  • ３ 外部依存の最小化方針
    • (1) ビルドパイプライン不採用
    • (2) npm／Composer非導入
• 第３ パフォーマンス・エンジニアリング
  • １ N+1問題への構造的対策
    • (1) 問題の所在
    • (2) static変数の役割
  • ２ Transient APIによる長期キャッシュ
    • (1) 投稿IDのみを保存する判断
    • (2) wp_optionsテーブル肥大化の回避
    • (3) 復元時のクエリ削減
  • ３ キャッシュキーのバージョニング
    • (1) v1からv5への遷移
    • (2) 自動再構築の仕組み
  • ４ 緊急再構築エンドポイント
    • (1) 管理者専用URL
    • (2) template_redirectでの認証
• 第４ WordPressコア構造への深い理解
  • １ pluggable.phpの読み込み順序
    • (1) WordPress初期化シーケンス
    • (2) functions.php直接記述の危険
  • ２ initフック以降での権限チェック
    • (1) current_user_canの安全な使い方
    • (2) フックポイント選定の指針
  • ３ PHP言語仕様上の罠
    • (1) コメント内のPHPタグ事故
    • (2) require_onceと分岐の分離
  • ４ キャッシュ層との闘い
    • (1) LiteSpeed Cacheの挙動
    • (2) script_loader_tagフィルタとその副作用
    • (3) インラインスクリプトによる回避
• 第５ D3.jsとTopoJSONによる地図描画
  • １ wp_localize_scriptというデータブリッジ
    • (1) JSON注入の安全性
    • (2) サーバ集計とクライアント描画の分離
  • ２ Mercator投影と日本地図
    • (1) 投影法選択の判断
    • (2) fitExtentによる自動キャリブレーション
  • ３ GeoJSON polygon windingの罠
    • (1) 球面領域としての解釈
    • (2) 反転バグの発生機序
    • (3) 手動path構築による回避
    • (4) サンプリングと頂点数削減
  • ４ インタラクション設計
    • (1) ズームとパンの制御
    • (2) counter-scaleの数学的根拠
    • (3) viewport-constant offset
    • (4) ホバーとクリックの分離
  • ５ 地理座標収集の手法
    • (1) Google Maps短縮URL展開
    • (2) 家裁本庁の別住所問題
• 第６ ドメイン駆動設計とポスト番号スキーマ
  • １ 五桁整数モデルの構造
    • (1) 桁ごとの意味付与
    • (2) 階層的セマンティクス
  • ２ 表記揺れの吸収
    • (1) 地家裁と家地裁の差異
    • (2) 名称シグナルによる振分
• 第７ モバイル最適化と踏んだ地雷
  • １ ビューポート単位の問題
    • (1) iOS Safariの100vh挙動
    • (2) 100dvhへの上書き
  • ２ CSS継承による表示崩れ
    • (1) box-sizing global適用
    • (2) コンポーネント側での明示
  • ３ SVG属性の優先順位
    • (1) inline styleの優位
    • (2) CSSフォールバック色の併用
  • ４ PHPペイロードとJSキャッシュ
    • (1) v1.8.4のカテゴリ事故
    • (2) 静的属性のPHP側確定原則
• 第８ 開発運用上の設計判断
  • １ ビルドパイプラインを持たない選択
    • (1) 直接編集方式
    • (2) コンパイル工程の不在
  • ２ 開発期間と版管理
    • (1) 短期集中型の開発
    • (2) バージョン番号によるトレース
  • ３ 再構築コマンドの整備
    • (1) ?rebuild_judge_map=1の役割
    • (2) 関連エンドポイント
• 第９ 代替プラットフォームとの比較
  • １ Next.jsを選ばなかった理由
    • (1) ドメイン資産の保持
    • (2) 既存記事との統合
  • ２ WordPressという制約の意義
    • (1) 「重い鉄下駄」の哲学
    • (2) ハンドメイドのパフォーマンス対策
  • ３ 国内開発者層との対比
    • (1) プラグイン組合せが多数派
    • (2) コア理解への希少性
• 第10 本実装が示した方向性
  • １ WordPressという土台の再評価
  • ２ フレームワーク疲労への示唆
  • ３ 生成AI時代における本実装の意味
    • (1) AIに代替されない「ドメイン理解の蓄積」
    • (2) 構造化データがAI協働の前提条件となる
    • (3) AIが技術評価を行う入れ子構造

現職裁判官の庁別・期別分布マップ

総人数 2730 名・ 44 の期に分布 （34期〜77期、2026-05-18 11:35:04 時点）

修習期 : 全期（色分け表示）34期（2名）35期（3名）36期（1名）37期（1名）38期（1名）39期（5名）40期（20名）41期（20名）42期（32名）43期（38名）44期（31名）45期（54名）46期（75名）47期（69名）48期（83名）49期（84名）50期（78名）51期（90名）52期（70名）53期（71名）54期（96名）55期（94名）56期（94名）57期（91名）58期（107名）59期（99名）60期（100名）61期（89名）62期（83名）63期（87名）64期（85名）65期（73名）66期（77名）67期（82名）68期（70名）69期（53名）70期（45名）71期（58名）72期（60名）73期（58名）74期（65名）75期（66名）76期（78名）77期（90名）

⛶全画面

現職裁判官の庁別・期別分布マップ

＋ － ⟲

各庁は実際の所在地を目安として配置しています。
円をクリックで該当庁のタグページへ（別タブ）。期別構成は画面右下に表示。地図の空白部分をダブルクリックまたは右上の「全画面」ボタンで全画面表示の切替（Esc でも解除可）。全画面表示中に円を右クリック：別ウィンドウで開く。凡例の庁種別を1個ずつクリック：表示／非表示切替。
裁判官が常駐していない地家裁支部はマップに表示していません。

＊１　各庁は実際の所在地を目安として配置しています。
＊２　円をタップすれば、その庁の期別構成を下の詳細パネルに表示できます。
＊３　「この庁の現職裁判官一覧へ」ボタンをタップすれば、該当タグページへ移動できます。
＊４　地図上部の「全画面」ボタンをタップすれば、地図を画面いっぱいに拡大表示できます。
＊５　凡例の庁種別をタップすれば、表示／非表示の切替ができます。
＊６　裁判官が常駐していない地家裁支部はマップに表示していません。

第１ 本稿の目的と前提

１ AI記事としての位置付け

本稿は，本サイト「山中弁護士ブログ」に搭載されている裁判官分布マップ機能の技術評価を，AIが行うものである。執筆者である生成AIは，本サイトの子テーマソースコードを直接参照し，設計上の判断・実装上の工夫・運用上の知見を整理した。読者として想定しているのは，フルスタックエンジニア及びテクニカルディレクターの両職である。

本記事の目的は二つある。第一に，本実装が国内のWordPress開発の文脈においてどの程度の難度に位置するかを，客観的に示すことである。第二に，同様の機能を開発しようとする後続のエンジニアに対し，地雷の所在と回避策を共有することである。

２ 対象システムの輪郭

対象は，固定ページに埋め込むショートコード型の機能である。司法修習の期と所属庁を二軸に取り，最高裁から地家裁支部まで，全国200以上の裁判所を実地理座標にプロットする。円の半径で人数の目安を，色相で庁種別を表現する，インタラクティブなD3.jsベースの可視化ツールである。

期プルダウンを操作すれば該当庁のみがハイライトされる。円をクリックすれば，「○○期×○○庁」の裁判官一覧記事タブを別ウィンドウで開ける。ズームすれば庁名ラベルが現れる。ピンチで拡縮，ドラッグでパンも自在である。縮尺バーは長さハンドルでドラッグ可能である。スマホ及びタブレットでは全画面ボタンでフルスクリーン化できる。ダブルタップによる意図しない反応は，完全に無効化されている。

３ 評価の視座

(1) フルスタックエンジニア視点

本記事のフルスタックエンジニア視点では，PHP・MySQL・JavaScript・HTML・CSSの各層を貫通する設計判断に焦点を当てる。とりわけ，バックエンドとフロントエンドの境界における責務分離，及びキャッシュ層との折り合いに重点を置く。本実装は，言わば「重い鉄下駄」を履いたWordPressの上で，モダンなSPAに匹敵する応答性を実現している。その実現手段は，言語仕様への深い理解と泥臭い職人技の合算である。フルスタックの素養を持つ読者には，各層での判断がどのように相互作用しているかが見えてくるはずである。

具体的には，PHPの static 変数とTransient APIによる二層キャッシュ。MySQLの wp_options テーブル肥大化を避けるための投稿ID限定保存。JavaScriptのD3.js v7とTopoJSONによる球面投影。HTMLの wp_localize_script によるJSONブリッジ。CSSの @supports 条件によるプログレッシブエンハンスメント。これらすべてが連動して，初めて成立する設計である。

(2) テクニカルディレクター視点

テクニカルディレクター視点では，技術選定の判断軸を検討する。なぜNext.js等の最新フレームワークではなく，あえてWordPressを選んだのか。なぜ既存テーマの上書きではなく，子テーマでのモジュール分割を選んだのか。なぜビルドパイプラインを導入せず，直接編集方式を採ったのか。これらの判断は，本サイトの運用形態・SEO資産・運用人員の規模を踏まえた合理的な選択である。本記事ではその論理を順に解きほぐす。

テクニカルディレクションでは「最善の技術」を選ぶことが必ずしも「最適」ではない。組織の規模，運用要員のスキルセット，既存資産との整合性，将来の保守可能性 ─ これらを総合的に評価する必要がある。本実装は，一見「古い」プラットフォームを選びながら，モダンな結果を引き出した好例である。「技術の選択」より「使い方の深さ」が結果を左右することを，本実装は示している。

第２ 技術スタックの全体像

１ バックエンド構成

(1) サーバ環境とPHP

本サイトはレンタルサーバ上で稼働している。PHPは8.1系，OPcacheは標準で有効化され，FastCGIモードで動作している。リクエスト境界を超えて生存するプロセスは存在しない。リクエスト単位でしか有効でないキャッシュと，リクエスト境界を超えて有効なキャッシュとを明確に区別する必要がある。本実装はこの区別を厳密に守っている。

(2) WordPressとMySQL

WordPressは6.5系，MySQLは8.0系である。文字コードは utf8mb4 である。テーブル構造は標準のWordPressスキーマを踏襲し，カスタムテーブルは追加されていない。すべての拡張情報は postmeta のキー・バリュー構造と，タグ・カテゴリ・カスタムタクソノミーの組合せで表現されている。

(3) Transient APIの位置付け

Transient APIはWordPressコア標準のキャッシュ抽象である。デフォルト実装は wp_options テーブルへの書込みである。外部キャッシュストア（Memcached／Redis）が設定されていればそちらが優先される。本サイトでは外部キャッシュは導入されていないため，Transientの実体は wp_options である。本実装はテーブル肥大化を慎重に避けている。

２ フロントエンド構成

(1) D3.js v7とtopojson-client

地図描画にはD3.js v7を用いている。D3はESM構成に切り替わっており，モジュール単位で必要な機能のみを取り込める。本実装は d3-selection・d3-geo・d3-zoom・d3-scale 等を主に利用している。トポロジーデータの解凍には topojson-client を併用する。両ライブラリともCDN経由で読み込まれる。

(2) ESMとブラウザ互換

D3 v7はESMモジュールであるが，UMD版もCDNで提供されている。本実装はUMD版を採用している。wp_enqueue_script が古典的な <script src> 出力を前提としているためである。UMD版であればグローバル d3 オブジェクトが提供され，後続のスクリプトから直接参照できる。

(3) CDNフォールバック

地理データの取得元には三段のCDNフォールバックチェーンを組んでいる。第一に cdn.jsdelivr.net/gh/dataofjapan/land，第二に raw.githubusercontent.com，第三に statically.io である。一つが障害で応答しなくなっても，次のCDNへ自動的にフェイルオーバーする。CDN障害という稀な事象であっても，マップが空白になるという最悪のUXを許容しない設計である。

フォールバックの実装は，fetch APIを Promise.race ではなく順序付きで呼び出す形を取っている。最初のCDNへの fetch が response.ok === false または例外を投げた場合に，次のCDNを試行する。各試行のタイムアウトは AbortController で5秒に制限している。「速いものを選ぶ」ではなく「動くものを順に試す」設計である。これは可用性優先のフェイルオーバー設計であり，金融機関で広く採用されているパターンである。

３ 外部依存の最小化方針

(1) ビルドパイプライン不採用

本実装はビルドパイプラインを採用していない。Webpack・Vite・esbuild等のバンドラは一切使っていない。ソースファイルはそのままブラウザに配信される。TypeScriptも使っていない。素のES2020 JavaScriptで書かれている。理由は，運用者が一人であり，ビルドパイプラインの維持コスト（依存関係の更新・Node.jsバージョン管理・ビルド成果物のキャッシュ管理等）が，得られる利益に見合わないと判断したためである。

(2) npm／Composer非導入

npmもComposerも導入されていない。PHPの外部ライブラリは一切使っていない。WordPress標準APIと自前実装のみで完結している。これにより，セキュリティアップデートの追従コスト，依存関係の競合，ライセンスの管理といった運用上の悩みから解放されている。WordPressコア自体の更新だけを追えばよい状態が維持されている。

第３ パフォーマンス・エンジニアリング

１ N+1問題への構造的対策

(1) 問題の所在

WordPressにおけるN+1問題は，主に get_term_by()・get_post_meta()・get_the_terms() といった単発取得APIが，ループ内で繰り返し呼ばれる際に顕在化する。本実装が扱う「ポスト番号からタグスラッグを引く」処理も，記事保存・更新のたびに数百回呼ばれる典型例である。素朴に書けば毎回SQLを発行する。save_post フックの中で大量の裁判官記事を一括更新するスクリプトを走らせると，MySQLの max_connections を簡単に食い潰す。

(2) static変数の役割

本実装は，関数内 static 変数を用いてこの問題を構造的に解消している。judge-labels.php の主要関数では，最初の呼び出し時にのみDBからスラッグ→ID対応表を取得し，連想配列としてメモリに保持する。二回目以降の呼び出しは，このメモリ上のテーブルから直接返す。SQLは発行されない。

function yamanaka_get_judge_label_map() {
    static $tag_id_map = null;
    static $check_list = null;
    if ( $tag_id_map === null ) {
        $tag_id_map  = array();
        $check_list  = array();
        foreach ( $slug_list as $slug ) {
            $term = get_term_by( 'slug', $slug, 'post_tag' );
            if ( $term ) $tag_id_map[ $slug ] = (int) $term->term_id;
        }
    }
    return array( $tag_id_map, $check_list );
}

この手法の重要な性質は，フックの呼び出しタイミングに依存しない点である。add_action('init', ...) の中で呼ばれようと，テンプレート末尾で呼ばれようと，最初の一回でDBを叩き，以降はメモリから返す。PHPは典型的にリクエスト終了時点で実行コンテキストが破棄されるアーキテクチャであるから，`static` の寿命はリクエスト終了までで切れる。逆に言えば，リクエスト境界を超えるキャッシュは別途必要となる。

２ Transient APIによる長期キャッシュ

(1) 投稿IDのみを保存する判断

リクエスト境界を超えるキャッシュには，WordPress Transient APIが用いられている。裁判官分布マップの集計値計算は，全国の現職裁判官メタデータをカテゴリ・カスタムフィールドで一括抽出するSQLと，ポスト番号から庁IDへのバイナリサーチ・マッピング処理を含む。これを `judge-map.php` の `yamanaka_get_judge_map_data` で12時間Transientキャッシュしている。

<pre>function yamanaka_get_judge_map_data() {
$cache_key = ‘yjm_data_v5’;
$cached = get_transient( $cache_key );
if ( $cached !== false ) return $cached;

$data = array(
‘courts’ =&gt; yamanaka_build_court_master(),
‘court_totals’ =&gt; yamanaka_count_judges_per_court(),
‘ki_counts’ =&gt; yamanaka_count_judges_per_ki_court(),
‘all_ki’ =&gt; yamanaka_collect_all_ki(),
);
set_transient( $cache_key, $data, HOUR_IN_SECONDS );
return $data;
}</pre>

ここで肝要なのは，フロントエンドへ送信するペイロード生成段階で，`WP_Post` オブジェクトそのものをサーバ側キャッシュに保存しない設計を貫いている点である。`WP_Post` は本文・抜粋・メタを抱え，シリアライズすると裁判官一人で4キロバイトから10キロバイト程度を食う。仮に3000記事分のオブジェクトを丸ごとTransientに格納すれば，`wp_options` テーブルは数十メガバイト規模に肥大化する計算となる。

(2) wp_optionsテーブル肥大化の回避

wp_options テーブルが肥大化すると，autoloadオプション以外のレコードであっても，インデックス性能が劣化する。WordPressは autoload='yes' のオプションを毎リクエストで一括ロードする。autoload='no' のTransientは個別取得ではあるものの，同テーブル内に大量レコードが存在することで，全体のINDEXツリーが深くなり，option_name の検索コストが上昇する。これは SHOW TABLE STATUS や EXPLAIN で観測可能な現象である。

大規模サイトでこのテーブルが肥大化すると，autoload のロードだけで数百ミリ秒を消費する事象が報告されている。WordPress運用の世界では「options bloat」と呼ばれる典型的な性能問題である。本実装はその罠を意識的に避けている。

本実装は，WP_Post オブジェクトの代わりに，投稿IDの配列のみをキャッシュする。投稿IDは整数値であり，シリアライズしても100バイト未満で済む。書き込み・読み込みのI/Oが桁違いに小さい。書込時の UPDATE wp_options SET option_value=... が高速で，読込時の SELECT も即座に完了する。

(3) 復元時のクエリ削減

キャッシュからの復元時は，get_posts(post__in => $ids, orderby => 'post__in') で一クエリだけ叩く。post__in パラメータは内部的にSQLの IN() 句に展開される。orderby => 'post__in' の指定で，ID配列の順序がそのまま結果順序になる。これはWordPress 4.0以降の標準機能である。MySQLの FIELD() 関数による順序保持に内部的にマップされる。意外と知られていない仕様である。

３ キャッシュキーのバージョニング

(1) v1からv5への遷移

裁判官分布マップの集計値キャッシュは，yamanaka_get_judge_map_data という関数が管理している。Transientキーには yjm_data_v5 のようにバージョン番号がsuffixとして付与されている。データ構造を変更するたびにこの番号をインクリメントする。v1からv5までの遷移を辿ると，それぞれ次の変更が行われている。

v1は初期構造である。期と庁の単純な二次元集計のみであった。v2でタグスラッグ情報を加えた。v3で期外現職の扱いを別フィールドに分離した。v4で庁マスタの形式変更（categoryフィールドの追加）に対応した。v5で司研・総研の category 分離と再統合を経た。各変更時にキーバージョンが上がっている。

(2) 自動再構築の仕組み

バージョン番号がsuffixに付いていることで，新しいコードがデプロイされると，旧キャッシュは自動的に「存在しないキー」とみなされる。即ち，新キーで get_transient が false を返し，再計算ルートに入る。管理画面からの手動キャッシュパージは不要である。デプロイと同時にキャッシュ再構築が始まる。旧キャッシュ自体は，TTL（12時間）の経過とともに自然消滅する。

４ 緊急再構築エンドポイント

(1) 管理者専用URL

緊急時の手動再構築のため，?rebuild_judge_map=1 という管理者専用クエリ文字列が用意されている。これを裁判官分布マップ埋込ページに付加してアクセスすると，関連するすべてのTransientがパージされ，次のリクエストで再計算が走る。
同様のエンドポイントとして `?rebuild_post_numbers=1`（ポスト番号マスタの再構築）及び `?rebuild_sc_top_labels=1`（タグラベルの再構築）が整備されている。これらは関数の同心円的な依存関係を踏まえて使い分けられる。

(2) template_redirectでの認証

これらのエンドポイントは template_redirect フックでチェックされる。ユーザの権限が manage_options 未満であれば403ステータスで蹴られる。template_redirect は wp() による現在投稿の特定後に発火するため，$post グローバル変数が確定している。フックポイントの選択にもセマンティックな意図が込められている。

第４ WordPressコア構造への深い理解

１ pluggable.phpの読み込み順序

(1) WordPress初期化シーケンス

WordPressの初期化は，index.php → wp-blog-header.php → wp-load.php → wp-config.php → wp-settings.php という順で進む。wp-settings.php は実に多数のファイルをロードする。データベース接続，多言語化（l10n.php），キャッシュAPI，マルチサイト，タクソノミーAPI，ポストAPI，リライトAPI，テーマAPI，ユーザAPI，フックAPI（plugin.php）等が，特定の順序で初期化される。プラグインのロードはこの後である。テーマの functions.php のロードはさらにその後である。

そして，pluggable.php は functions.php ロードの「後」に読み込まれる。即ち，functions.php のトップレベルでは，pluggable.php で定義される関数群（current_user_can()・wp_get_current_user()・wp_set_auth_cookie() 等）はまだ存在しない。

(2) functions.php直接記述の危険

この事実を知らずに functions.php のトップレベルで if ( current_user_can('manage_options') ) と書くと，どうなるか。current_user_can は未定義関数となり，Fatal error: Uncaught Error: Call to undefined function が出る。サイト全体が500エラーとなる。本実装の functions.php には，この事故への警告コメントが残されている。

// functions.php
require_once get_stylesheet_directory() . '/inc/api.php';
require_once get_stylesheet_directory() . '/inc/metadata.php';
require_once get_stylesheet_directory() . '/inc/ui-enhancement.php';
require_once get_stylesheet_directory() . '/inc/judge-map.php';
require_once get_stylesheet_directory() . '/inc/admin-tools.php';

/*
 * 注意：
 * - require_once は単独の if 文で囲む
 * - current_user_can() / is_admin() を「ここで」分岐に使うのは禁止
 *   pluggable.php 未ロードの段階で致命的エラーになり得る
 */

このコメントは過去の事故の痕跡である。「require_once は単独の if 文で囲む」「current_user_can() / is_admin() をここで分岐に使うのは禁止」という二行は，経験者であれば即座に理解できるはずである。条件分岐に基づいてrequireするのではなく，常にrequireすることで「ファイルがロードされない」事態を防ぐ設計である。

２ initフック以降での権限チェック

(1) current_user_canの安全な使い方

権限チェックは，init フック内であれば安全に行える。init フックの発火は pluggable.php ロード後だからである。本実装の inc/*.php は，すべて add_action('init', ...) や add_action('admin_menu', ...) のフック内で，current_user_can 等の関数を呼び出すよう徹底している。

(2) フックポイント選定の指針

フックポイントの選定にも理がある。データベース書き込みを伴う処理は admin_init。テンプレートに干渉する処理は template_redirect。タグ・カテゴリの一括更新処理は save_post。スクリプトの登録は wp_enqueue_scripts。それぞれ，必要な前提条件が揃った時点でのみフックを使う。これによって，未定義関数を呼ぶ事故や，未確定の状態に依存する事故を構造的に避けている。

３ PHP言語仕様上の罠

(1) コメント内のPHPタグ事故

本実装の開発過程では，PHPコメント内に <?php ?> を書いただけで構文崩壊した事故もあった。これは // 行コメントの中で ?> が現れると，PHPモードを抜けるという仕様による。仕様としては正しい挙動である。説明用のサンプルコードをコメントに含めてしまったことが直接の原因である。

この事故以来，本実装では「説明はすべて自然言語で書く，サンプルは絶対にコメント内に置かない」というルールが徹底されている。コメント追加前には必ず構文チェック（php -l）を走らせる運用も並行している。

(2) require_onceと分岐の分離

もう一つの罠は，require_once を条件分岐で囲むことである。例えば「管理者の時だけincを読み込む」という設計は，一見最適化のように見える。しかし，管理者でない時にも実は呼ばれてしまう関数があると，未定義関数エラーで死ぬ。本実装は「常にrequireする，権限チェックは関数内で行う」という単純な原則を貫いている。これによって，フックポイントとファイルロードの関係が単純化され，事故の余地が減っている。

４ キャッシュ層との闘い

(1) LiteSpeed Cacheの挙動

本サイトのレンタルサーバ環境では，LiteSpeed Cacheが稼働している。JS Combine機能とLoad JS Delayed機能が有効化されている。これは複数の <script> タグを一つに結合し，かつ遅延ロードする仕組みである。標準的なキャッシュバスター手法である ?ver=1.8.6 といったクエリ文字列は，LiteSpeedが結合済みURLをハッシュ化（例えば 069d468...cd6.js?ver=f2cd6）してしまうため，意図したとおりには効かない。

(2) script_loader_tagフィルタとその副作用

当初は script_loader_tag フィルタを使い，対象スクリプトに data-no-optimize="1" data-cfasync="false" data-no-defer="1" data-no-minify="1" 等の属性を付与する戦法を取った。LiteSpeedとCloudflare Rocket Loaderの両方の最適化対象から個別除外する方針である。これはPC環境では奏功した。しかしモバイル側のページキャッシュとの組み合わせで，マップが表示されない事故に発展した。モバイル用のページキャッシュとPC用のそれは独立して保存されるため，片側のみで問題が起きるという厄介な現象であった。

(3) インラインスクリプトによる回避

最終解は，PHPテンプレート末尾にインラインスクリプトを埋め込むことであった。window.YAMANAKA_JM_TOGGLE_FS 等の関数を早期エクスポーズし，judge-map.js 本体がまだロードされていなくてもCSS-only擬似全画面切替へフォールバックする二段構えを組んだ。インラインスクリプトはキャッシュプラグインの結合・遅延の対象から外れやすい。初期化タイミングを保証できる。ここから得られた教訓は明快である。「キャッシュ層を制御しようとするな。キャッシュ層を回避する設計を埋め込め」ということである。

第５ D3.jsとTopoJSONによる地図描画

１ wp_localize_scriptというデータブリッジ

(1) JSON注入の安全性

サーバサイドで集計されたデータをフロントエンドに渡す仕組みには，wp_localize_script が使われている。これはWordPress標準の関数であり，<script> タグの先頭に var YAMANAKA_JM_DATA = {...}; という形式でJSONを出力する。エスケープは自動で行われる。CSP（Content Security Policy）違反のリスクも回避される。スクリプトハンドル名と紐付くため，ロード順序も保証される。

wp_localize_script( 'yamanaka-judge-map', 'YAMANAKA_JM_DATA', array(
    'courts'        => $courts,        // 庁マスター 228 件
    'court_totals'  => $court_totals,  // 庁ID → 現職人数
    'ki_counts'     => $ki_counts,     // 期 → 庁ID → 人数
    'all_ki'        => $all_ki,        // ソート済み期配列
    'total_judges'  => $total_judges,
    'tag_slugs'     => $tag_slugs,     // 庁ID × 期 → タグスラッグ
    'topojson_urls' => array(...),     // 3 段フォールバック CDN
) );

(2) サーバ集計とクライアント描画の分離

集計処理はサーバサイドで完結する。sonota-genshoku-keireki カテゴリ × judge_term_sort > 0 × judge_post_number_sort != 999999 という条件で，現職裁判官の postmeta をSQL一発で抽出する。yamanaka_judge_court_id_from_num() のバイナリサーチで，ポスト番号から庁IDへマッピングする。これらの計算結果はTransientにキャッシュされ，リクエストごとに再計算されない。

ブラウザ側は，届いたJSONをD3で描画するだけである。重い集計ロジックがブラウザに流出しない。バックエンドとフロントエンドの責務分離が明確に決まっている。これがWordPressの伝統的なテンプレート方式（PHPでHTMLを直接出力する）の限界を超えた，モダンなアーキテクチャである。

２ Mercator投影と日本地図

(1) 投影法選択の判断

地図の投影法には d3.geoMercator を採用している。Mercator投影は角度を保存するため，方位の直感が利く。高緯度で面積が歪むという欠点はあるが，日本程度の緯度範囲（概ね北緯24度から46度）では，視覚的に問題ない歪みに収まる。仮にAzimuthal Equal Area等の等積投影を用いると，北海道と沖縄の見た目バランスが日常的な日本地図の印象と乖離する。Mercatorは「日本地図らしさ」の維持にとって最適な選択である。

投影法はD3.jsが豊富に提供している。geoAlbers（アメリカ向け），geoConicEqualArea（中緯度向け），geoOrthographic（衛星視点風）等，30種類以上の選択肢がある。これらをライブラリの一行で切り替えられる柔軟性は，D3.jsの大きな利点である。本実装は geoMercator を採用しつつ，将来の差替えにも対応できる設計を維持している。投影関数は単一の関数オブジェクトとして変数に保持されており，他のすべての座標計算がこの変数を経由する構造になっている。

(2) fitExtentによる自動キャリブレーション

投影パラメータの調整には projection.fitExtent を使う。SVGコンテナのサイズと日本地図のGeoJSONを渡せば，中心点とスケールが自動算出される。手動でcenterとscaleを試行錯誤する必要がない。コンテナサイズが変わってもキャリブレーションが追従する。

３ GeoJSON polygon windingの罠

(1) 球面領域としての解釈

D3.jsの d3.geoPath は，GeoJSON polygonを「球面上の領域」として解釈する。地球は球であり，球面上には「外側」「内側」という概念が存在しない。すべての領域はある向きで閉じている。GeoJSONの仕様（RFC 7946）では，外側のリングは反時計回り（CCW）に，穴のリングは時計回り（CW）に並べると定められている。D3はこの規約に厳密に従う。

(2) 反転バグの発生機序

本実装の開発過程で，日本地図全体が「湖の色」（薄い水色）で塗りつぶされる重大バグに遭遇した。原因はGeoJSON polygonのwinding orderの誤りであった。OSM Nominatim等のオープンデータから取得した湖のpolygonは，CWで来ることがある。これを d3.geoPath に流すと「これは陸地に開いた穴である」と解釈される。Mercator投影で日本以外をクリッピングすると，結果として「日本以外が陸地，日本が湖」という反転表示になる。一見不可解だが，仕様に従えば必然の挙動である。

(3) 手動path構築による回避

対策として，湖は d3.geoPath を経由させず，手動でSVG <path> の M x,y L x,y ... Z 文字列を構築する方式に切り替えた。Mercator投影は projection([lng, lat]) でlng・latから2D座標を計算できる。polygonの各頂点を変換し，M と L と Z で繋ぐだけである。winding非依存となり，表示が安定した。これは仕様に「逆らう」のではなく，仕様の縛りを受けないAPIに切り替える賢い判断である。

(4) サンプリングと頂点数削減

湖polygonのサンプリングも併せて行っている。霞ヶ浦のような大規模湖は，生のpolygonで数千頂点に達する。これをそのままSVGに描くと，DOM要素のtransform計算がボトルネックとなり，モバイルが固まる。N頂点ごとに間引くことで，視覚上の解像度を損なわず描画コストを大幅に削減できる。Nは5から10程度で十分である。

４ インタラクション設計

(1) ズームとパンの制御

ズームとパンには d3.zoom を用いる。マウスホイール・タッチピンチ・ドラッグの各イベントを統合的に扱う。zoomBehaviorの scaleExtent で倍率範囲を限定し，translateExtent でパン範囲を限定する。これにより，ユーザが地図を画面外に押し出して見失う事故を防いでいる。

(2) counter-scaleの数学的根拠

d3.zoom でズームすると，子要素は transform: scale(k) で拡大される。円や文字のサイズもk倍になる。これでは「ズームしたら円が画面いっぱいになる」事故が起きる。対策は単純な数学である。子要素自身に transform: scale(1/k) を逆掛けする。親のスケールと相殺され，画面上のサイズが一定に保たれる。これを「counter-scale」と呼ぶ。

(3) viewport-constant offset

合同庁舎などで複数の庁が同一座標に重なる場合，円が完全に重なって個別操作できなくなる。これを offset = SEP / k で解消する。SEPは基準距離（例えば10ピクセル）。kは現在のzoomレベル。viewport上での距離を常に一定に保つ計算である。ズームインすると円が離れて見え，それぞれをクリックできる。直感に合うインタラクションが実現される。

(4) ホバーとクリックの分離

PC環境ではマウスホバーでツールチップを表示し，クリックで裁判官一覧記事タブを開く。タッチ環境では，ワンタップで詳細パネル表示，明示的なリンクボタンでタブ遷移という方式に落ち着いた。当初試みたダブルタップでの遷移方式は誤反応が頻発したため廃止した。

５ 地理座標収集の手法

(1) Google Maps短縮URL展開

228庁の緯度経度は人力で収集された。Google Mapsの短縮URL（https://maps.app.goo.gl/...）を curl -L で展開し，リダイレクト先URLに含まれる !8m2!3d{lat}!4d{lng} パターンからmarker座標を抽出する作業を，各庁について繰り返した。@{lat},{lng},z の方は「地図中心」であってmarker位置ではない点に注意が必要である。これらは別物である。小数4桁で丸めて採用している。

(2) 家裁本庁の別住所問題

家裁本庁は地裁本庁と別住所のケースがある。例えば東京家裁は霞が関1-1-2，東京地裁は1-1-4である。大阪家裁は大手前4-1-13，大阪地裁は西天満2-1-10である。
これらは courts.go.jp の /about/syozai/ ページで個別確認した。

第６ ドメイン駆動設計とポスト番号スキーマ

１ 五桁整数モデルの構造

(1) 桁ごとの意味付与

本実装で技術的に最も「効いている」設計判断は，post-numbers.php のスキーマ設計である。ポスト番号は5桁の整数であり，桁ごとに意味が割り当てられている。

• 第1桁（万の桁）：庁の地域大区分（1=東京圏，2=大阪圏，3=中国・四国，4=九州，5=東北 等）
• 第2桁（千の桁）：地域内の庁細分
• 第3桁（百の桁）：本庁=0／支部=1以降
• 第4-5桁（下2桁）：役職・階級（00-09=所長／部総括系，50番台=判事・判事補，90番台=特殊）

(2) 階層的セマンティクス

例えば23203という番号は，「大阪（第1桁=2）・大阪地裁（第1-2桁=23）・本庁（第3桁=2）・民事第2部判事（下2桁=03）」を表す。10144-10156という範囲は「東京家裁本庁・家裁部総括」の連番である。10421は「東京地家裁判事」，10751は「東京家裁本庁・支部の判事」である。「百の桁で本庁/支部を分け，末尾の数値で役職・階級を判別する」というルールが一貫している。

この階層性が，後段の処理を圧倒的にシンプルにする。例えば「同一の本庁に属する全裁判官を集計する」という処理は，`floor($num / 1000) * 1000` から `floor($num / 1000) * 1000 + 99` までの範囲をスキャンするだけで実現できる。裁判官分布マップにおいて庁ごとの人数集計を行う中核処理は，この整数演算ですべて完結する。庁名の文字列比較も，役職テーブルとのJOINも不要である。

２ 表記揺れの吸収

(1) 地家裁と家地裁の差異

裁判所の正式名称には微妙な表記揺れがある。「東京地家裁○○支部」と「東京家地裁○○支部」は，前者と後者で意味が異なる。前者は地裁メインの判事，後者は家裁メインの判事を指す。同じ「地家裁／家地裁」という表現でも，順序の入れ替えが意味を変える。

(2) 名称シグナルによる振分

この表記揺れを，judge-labels.php は post_number マスタの名称シグナルから自動振分するロジックで吸収している。例えばポスト番号10421が「東京地家裁判事」，10507が「東京家地裁判事」である場合，名称中の「地家裁」「家地裁」の語順をパースして，地裁系か家裁系かを判定する。兄弟番号として正しく扱われる。これは一見泥臭い処理だが，スキーマの規則性に支えられて簡潔に書ける。

第７ モバイル最適化と踏んだ地雷

１ ビューポート単位の問題

(1) iOS Safariの100vh挙動

iOS Safariの 100vh はアドレスバー込みの高さを返す。実際の表示領域より大きい値である。裁判官分布マップの全画面モードで height: 100vh と書くと，地図下部がアドレスバーの裏に隠れる事故が出る。これはiOSの長年の有名な挙動であり，多くのWebアプリが踏んできた地雷である。

(2) 100dvhへの上書き

対策は 100dvh（dynamic viewport height）への上書きである。dvh はアドレスバー表示状態に応じて動的に変わる値である。iOS Safari 15.4以降でサポートされている。本実装は @supports (height: 100dvh) という条件式で，対応ブラウザのみ 100dvh を適用し，未対応ブラウザは 100vh のままにする。プログレッシブエンハンスメントの実例である。

２ CSS継承による表示崩れ

(1) box-sizing global適用

縮尺バーの幅を style.width = '120px' とJSで設定したのに，実際の表示は細長くなる現象が発生した。原因は親テーマの * { box-sizing: border-box } というglobal適用であった。border-box はpaddingとborderを含めた寸法を表す。120pxの中に内側余白とborderが食い込み，contentの幅が縮んでいた。

(2) コンポーネント側での明示

対策は，コンポーネント側で box-sizing: content-box を明示的に上書きすることである。globalの * セレクタは詳細度が低いため，コンポーネント側のクラスセレクタで簡単に勝てる。この教訓は単純である。「テーマのglobal CSSを信用するな。自分のコンポーネントは自分でbox-sizingを明示せよ」ということである。

３ SVG属性の優先順位

(1) inline styleの優位

スマホで都道府県が真っ黒になる事故もあった。<path> 要素のfill属性がJSの .attr('fill', '#xxx') で上書きされるはずだったが，古いJSキャッシュ環境でSVG default fillの黒に落ちていた。調査の結果，SVGのfill優先順位は「inline style > CSS rule > SVG presentation attribute」と判明した。.attr('fill', ...) はpresentation attributeを設定するだけで，CSSの path { fill: ... } ルールに負ける。.style('fill', ...) でinline styleに設定すれば常に勝つ。

(2) CSSフォールバック色の併用

加えて，CSS側にもフォールバック色を必ず書くようにした。JSが未ロードまたは古いキャッシュで undefined になっても，CSSルールで決まった色が表示される。多層防御の発想である。インライン優先・CSSフォールバック・presentation attributeデフォルト ─ という三層で，どの層が落ちても画面の破綻を防ぐ。

４ PHPペイロードとJSキャッシュ

(1) v1.8.4のカテゴリ事故

本実装の開発で得られた最重要パターンは「表示用文字列の加工はPHPのpayload生成段階で行え」である。v1.8.4の事故では，司研・総研のcategoryをPHP側で分割したが，モバイル古キャッシュのJS側 CATEGORY_INFO マップに新カテゴリが定義されていなかった。結果，色のフォールバックが効き，灰色（地家裁支部と同色）で表示された。v1.9.20でも同様に，本庁ラベルへの「地家裁」付加処理をJS側に書いたところ，古いキャッシュ環境で「東京」「大阪」のままラベルが固まった。

(2) 静的属性のPHP側確定原則

v1.9.22で正解の設計に到達した。表示用文字列の加工をPHPの wp_localize_script 生成段階で行う方式である。payload自体に加工結果が含まれて配信されるため，JSのキャッシュ状態とは無関係に正しく表示される。原則として，JSのロジックは動的表示（ズーム連動・hover等）に限定する。静的に決まる属性はPHPで確定させる。この原則だけで，キャッシュ起因のバグはほぼ撲滅できる。

第８ 開発運用上の設計判断

１ ビルドパイプラインを持たない選択

(1) 直接編集方式

本実装はビルドパイプラインを持たない。wp-admin/theme-editor.php で直接編集して保存する。即ち，本番サイト上でコードを編集し，保存と同時に反映される。これは一般的な企業開発では推奨されない方式である。ステージング環境を介さず本番に直接触ることになるからである。しかし運用者が一人であり，動作確認も同じブラウザでできる小規模サイトでは，パイプラインの維持コストの方が大きい。

(2) コンパイル工程の不在

JavaScriptは素のES2020で書かれている。TypeScriptもJSXも使わない。トランスパイルもない。ブラウザがそのまま実行できる形式である。即ち，view-source で見えるコードと，編集中のコードが同一である。デバッグが極めて単純である。Chrome DevToolsで Sources タブを開けば，本実装の judge-map.js がそのまま読める。ブレークポイントを直接張れる。

２ 開発期間と版管理

(1) 短期集中型の開発

本実装の主要部分は，2026年5月16日午後8時頃から作成に着手し，AIを使った実作業時間として約8時間で開発された。v1.0からv1.9.24まで，バージョンが急速に進んだ。これは「小さな改修を一日に複数回リリースする」開発スタイルである。各バージョンは数十分から数時間で完成する。問題があれば即座に次バージョンで修正する。フィードバックループが極めて短い。

(2) バージョン番号によるトレース

バージョン番号は，wp_enqueue_script の $ver 引数として明示される。judge-map.js?ver=1.9.24 という形でURLに現れる。古いバージョンの存在は，履歴のメタデータとして残る。問題が再発した時は，git blame がなくても，バージョン番号の付与時期から原因変更を遡れる。本実装ではこれが明示的なメモとして整理されている。各バージョンで何を変えたかが，作者のメモに残されている。

３ 再構築コマンドの整備

(1) ?rebuild_judge_map=1の役割

緊急時の手動再構築のため，?rebuild_judge_map=1 という管理者専用クエリ文字列が用意されている。裁判官分布マップ埋込ページにこのクエリを付加してアクセスすると，関連するTransientがパージされ，次のリクエストで再計算が走る。コード変更後に「即座に反映されない」事象が起きた時の対処として有用である。

(2) 関連エンドポイント

同様のエンドポイントとして次のものが整備されている。?rebuild_post_numbers=1 はポスト番号マスタの再構築，?rebuild_sc_top_labels=1 はタグラベルの再構築である。これらは関数の同心円的な依存関係に従って順に実行される必要がある場合がある。例えばポスト番号の変更時は，rebuild_post_numbers の後に rebuild_sc_top_labels を実行する。順序を間違えると古いマッピングが残る。運用知が明文化されている。

第９ 代替プラットフォームとの比較

１ Next.jsを選ばなかった理由

(1) ドメイン資産の保持

仮にNext.jsで同等の機能を新規構築するとすれば，技術的にはより自然である。React Server Componentsで集計を行い，クライアントでD3を呼び出し，Vercelにデプロイする。冷起動も最小化できる。CDNキャッシュも自動である。しかし本サイトはNext.jsには移行していない。理由はドメイン資産の保持である。yamanaka-bengoshi.jpは長年の運用で，法曹界からの被リンクと検索エンジン評価を積み重ねている。引っ越しは，このSEO資産の一時的なリセットを意味する。

(2) 既存記事との統合

本サイトには裁判官の経歴に関する個別記事が3000本近く存在する。裁判官分布マップは，これらの記事と密接にリンクしている。円をクリックすれば裁判官一覧記事タブが開く。仮にマップだけNext.jsに切り出せば，URL構造の不整合，認証セッションの分離，CMS編集体験の二重化など，運用上の負担が大幅に増える。WordPress内で閉じている限り，これらは単一プラットフォームの中で完結する。

２ WordPressという制約の意義

(1) 「重い鉄下駄」の哲学

WordPressという土俵は，フレームワークとして見ると「重い鉄下駄」である。リクエスト毎にプロセスが起動し，多数のSQLを発行する。Pythonのインタプリタが毎回ColdなところからJITコンパイルするようなものである。これに対してNext.jsは「最初から速いF1マシン」である。SSGで静的化されたページは，CDNから直接返される。サーバ処理はゼロに近い。

本実装はこの「重い鉄下駄」を履きながら，モダンSPAに匹敵する応答性を出している。それを可能にしたのは，static変数によるリクエスト内キャッシュ，投稿IDのみを保存するTransient戦略，N+1問題の構造的回避という，三層のパフォーマンス対策である。これらはフレームワークが自動で提供してくれるものではない。すべて手で書く必要がある。

(2) ハンドメイドのパフォーマンス対策

ハンドメイドのパフォーマンス対策は，理解の深さを要求する。フレームワークの自動キャッシュは「とりあえず速い」ものを提供してくれるが，限界が来た時に何が起きているか分からない。本実装の手書きキャッシュは，どこに何が乗っているかが完全に把握されている。トラブル時の調査が高速である。「分かっている」ことの強みが，運用フェーズで効いてくる。

Next.jsのISR（Incremental Static Regeneration）や，Vercelのedge caching等は，フレームワーク設計者の想定するユースケースに対しては優れた解である。しかし本実装のように「集計ロジックが複雑」「データ更新時のキャッシュパージ条件が個別事情に依存する」「特定のページのみ高負荷」というケースでは，自動化されたキャッシュ層がかえって挙動の予測を困難にする。手書きのキャッシュ層は，これらの個別事情に対して直接対応できる。

本実装の ?rebuild_judge_map=1 や ?rebuild_post_numbers=1 といった再構築エンドポイントは，フレームワーク自動キャッシュでは表現しづらい「局所的なパージ」を実現している。データの更新と無関係に手動でキャッシュを破棄したい局面 ─ 例えば集計ロジックの変更後 ─ にも，これらは応えてくれる。

３ 国内開発者層との対比

(1) プラグイン組合せが多数派

国内のWordPress開発者層を観察すると，圧倒的多数は次のようなスキルセットで動いている。既存テーマ（Lightning，SWELL，Cocoon等）の設定をカスタマイズする。既存プラグイン（ACF，Elementor，All in One SEO等）を組み合わせてページを作る。コピペコードを functions.php に貼り付けて動かす。これは事業として完全に成立する仕事であり，市場のニーズに応えている。

(2) コア理解への希少性

しかし本実装で行われているような「pluggable.phpのロード順を意識した防御フック」「Transient APIによる投稿ID限定キャッシュ」「D3.jsとTopoJSONによる完全自前マップ描画」「ドメイン駆動のValue Objectとしてのポスト番号体系」 ─ これら四つを同時に行えるエンジニアは，国内のWordPress開発者全体を見渡しても希少である。各専門領域でシニアレベルの理解を要する。フルスタックエンジニア及びテクニカルディレクターとしてのキャリアの広さと深さの両方が求められる。

第10 本実装が示した方向性

１ WordPressという土台の再評価

本実装が示した方向性は，次のように要約できる。WordPressという「単なるCMS」と見なされがちな土台の上に，モダンなWebアプリケーションを完成させることができる。重要なのは，言語仕様への深い理解，パフォーマンス・エンジニアリングの素養，モダンフロントエンドの技術スタック，そして対象ドメインの構造化センスである。これら四つが揃った時に，初めて高度に統合された水準の実装が成立する。

２ フレームワーク疲労への示唆

本実装は，フレームワークの自動化に頼らない手書きの設計の強みを示している。フレームワーク疲労に悩む現代の開発者にとって，一つの示唆を含む。「すべてを自動でやってくれる新しいフレームワーク」に飛びつく前に，「既にある古い土台」を本気で使い倒すという選択もあり得る。

３ 生成AI時代における本実装の意味

(1) AIに代替されない「ドメイン理解の蓄積」

本記事自体が生成AIによって執筆されている。「裁判官分布マップを作ってほしい」と依頼すれば，AIはそれらしいコードを生成できる。D3.jsの呼び出し方も，TopoJSONの解凍方法も，Mercator投影の数式も，AIは即座に提示できる。技術的な「型」の部分は，もはやAIが安価に供給する時代に入った。

しかし生成AIにも到達できない領域がある。裁判官のポスト番号体系は，誰かが裁判所の組織を読み解き，5桁整数というユニバーサルキーに凝縮した結果である。地家裁と家地裁の表記揺れがどちらの裁判所を指すかという判別ルールも，3000件近くにわたる裁判官個別記事の蓄積も，誰かが地道に整理した結果である。生成AIは「過去に誰かが整理したもの」を学習できるが，「誰も整理していない泥臭い現実」を整理するのは依然として人間の仕事である。本実装の真の価値は，AIには再現困難な「データ・ドメイン理解・運用知の三位一体」にある。

(2) 構造化データがAI協働の前提条件となる

逆に，こうしたドメインの構造化が一度行われると，生成AIとの協働は格段に進む。本実装のポスト番号体系は，AIが読み解きやすいセマンティクスを備えている。23203という数字を見て「大阪地裁本庁の民事第2部判事」と理解する処理は，AIにとっても容易である。整数演算で完結する性質ゆえ，AIが新規ロジックを提案する際の前提も明確になる。

AIが大量に情報を扱う時代において，「構造化済みドメイン知識」は新たな資産価値を持つ。本実装は，法曹界という特定領域でこの資産を作り上げたケースであり，今後の同種の取組みにとって参考事例となる。AIに「教える」のではなく，AIが「読み取れる」状態にデータを整えるという発想 ─ これは今後あらゆる業務領域で求められる素養となるであろう。

(3) AIが技術評価を行う入れ子構造

本記事は，AIが本サイトのソースコードを読み，技術評価を行った成果物である。コード自体が「AIに読まれること」を直接の目的としていたわけではない。それでもAIが評価しうるのは，コードに一貫した設計思想と明示的な意図が表現されているからである。

AIによる技術解析が日常化する時代に，「人間にも，AIにも，読みやすい」コードの価値は高まる。命名の一貫性，モジュール分割の明確さ，コメントによる設計意図の明示 ─ これらは古典的な良質コードの要件であるが，AI協働時代においてさらに重要性を増す。本実装はその要件を高水準で満たしており，AIとの共同保守が容易な状態に置かれている。これは将来の運用形態にも好影響を及ぼすと考えられる。

本記事それ自体が，AIによる読解可能性の一つの実証である。コードを書く者が，将来のAIによる解析を予期し，読み取りやすさを意識する ─ こうした「AIファースト」の設計思想は，近い将来のソフトウェア開発の標準になっていく可能性が高い。本実装はその先駆的な事例として位置付けられる。