目次
- 第１ 本稿の目的と前提
- １ 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) 集計結果だけを保存する判断
- (2) wp_optionsテーブル肥大化の回避
- (3) 復元時のクエリ削減
- ３ キャッシュキーのバージョニング
- (1) v1からv5への遷移
- (2) 自動再構築の仕組み
- ４ 緊急再構築エンドポイント
- (1) 管理者専用URL
- (2) template_redirectでの認証
- １ N+1問題への構造的対策
- 第４ 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) インラインスクリプトによる回避
- １ pluggable.phpの読み込み順序
- 第５ 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) 家裁本庁の別住所問題
- １ wp_localize_scriptというデータブリッジ
- 第６ ドメイン駆動設計とポスト番号スキーマ
- １ 番号帯ベース・スキーマの構造
- (1) 番号帯への意味付与
- (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) コア理解への希少性
- １ Next.jsを選ばなかった理由
- 第10 本実装が示した方向性
- １ WordPressという土台の再評価
- ２ フレームワーク疲労への示唆
- ３ 生成AI時代における本実装の意味
- (1) AIに代替されない「ドメイン理解の蓄積」
- (2) 構造化データがAI協働の前提条件となる
- (3) AIが技術評価を行う入れ子構造
現職裁判官の庁別・期別分布マップ
地域から現職裁判官を探す
都道府県を選ぶと、裁判所別の一覧を開けます。人数は現職の総数です。地裁・家裁を合算した一覧もあります。
北海道
東北
青森県
岩手県
宮城県
秋田県
山形県
福島県
関東
茨城県
栃木県
群馬県
埼玉県
千葉県
東京都
神奈川県
中部
新潟県
富山県
石川県
福井県
山梨県
長野県
地方・家庭裁判所の本庁
地方・家庭裁判所の支部
岐阜県
静岡県
愛知県
高等裁判所
地方・家庭裁判所の本庁
地方・家庭裁判所の支部
近畿
三重県
滋賀県
京都府
大阪府
兵庫県
奈良県
和歌山県
中国
鳥取県
島根県
岡山県
広島県
山口県
四国
徳島県
地方・家庭裁判所の本庁
香川県
愛媛県
高知県
九州・沖縄
福岡県
佐賀県
長崎県
熊本県
大分県
宮崎県
鹿児島県
沖縄県
高等裁判所の支部
地方・家庭裁判所の本庁
地方・家庭裁判所の支部
最高裁判所・研修所
各裁判所の現職裁判官一覧へのリンク（キーボード・スクリーンリーダー用）
上の分布マップはマウス操作向けのため、各裁判所のタグページ（現職裁判官一覧）へのテキストリンクを用意しています。
- 最高裁（現職127名）
- 司研（現職35名）
- 総研（現職9名）
- 東京高裁（現職163名）
- 大阪高裁（現職82名）
- 名古屋高裁（現職28名）
- 広島高裁（現職13名）
- 福岡高裁（現職28名）
- 仙台高裁（現職15名）
- 札幌高裁（現職13名）
- 高松高裁（現職12名）
- 名高金沢（現職5名）
- 広高岡山（現職6名）
- 広高松江（現職3名）
- 福高宮崎（現職5名）
- 福高那覇（現職4名）
- 仙高秋田（現職3名）
- 東京地裁（現職408名）
- 東京家裁（現職42名）
- 立川（現職45名）
- 横浜地家裁（現職87名）
- 川崎（現職15名）
- 横須賀（現職5名）
- 小田原（現職13名）
- 相模原（現職6名）
- さいたま地家裁（現職57名）
- 川越（現職13名）
- 熊谷（現職9名）
- 越谷（現職8名）
- 千葉地家裁（現職66名）
- 松戸（現職14名）
- 木更津（現職4名）
- 八日市場（現職3名）
- 佐倉（現職4名）
- 一宮（現職1名）
- 水戸地家裁（現職21名）
- 土浦（現職7名）
- 下妻（現職4名）
- 日立（現職1名）
- 龍ケ崎（現職2名）
- 宇都宮地家裁（現職17名）
- 栃木（現職3名）
- 足利（現職2名）
- 真岡（現職1名）
- 大田原（現職2名）
- 前橋地家裁（現職17名）
- 桐生（現職1名）
- 高崎（現職6名）
- 太田（現職4名）
- 静岡地家裁（現職19名）
- 沼津（現職12名）
- 浜松（現職12名）
- 富士（現職2名）
- 下田（現職1名）
- 掛川（現職1名）
- 甲府地家裁（現職10名）
- 都留（現職1名）
- 長野地家裁（現職9名）
- 上田（現職3名）
- 松本（現職5名）
- 諏訪（現職2名）
- 飯田（現職1名）
- 佐久（現職2名）
- 伊那（現職1名）
- 新潟地家裁（現職16名）
- 新発田（現職2名）
- 長岡（現職5名）
- 高田（現職2名）
- 三条（現職1名）
- 佐渡（現職1名）
- 大阪地裁（現職167名）
- 大阪家裁（現職28名）
- 堺（現職23名）
- 岸和田（現職9名）
- 京都地家裁（現職50名）
- 福知山（現職1名）
- 園部（現職1名）
- 舞鶴（現職1名）
- 宮津（現職1名）
- 神戸地家裁（現職45名）
- 尼崎（現職15名）
- 姫路（現職15名）
- 豊岡（現職1名）
- 洲本（現職1名）
- 伊丹（現職4名）
- 明石（現職3名）
- 社（現職1名）
- 龍野（現職1名）
- 奈良地家裁（現職13名）
- 葛城（現職6名）
- 五條（現職1名）
- 大津地家裁（現職14名）
- 彦根（現職2名）
- 長浜（現職1名）
- 和歌山地家裁（現職11名）
- 田辺（現職2名）
- 新宮（現職1名）
- 名古屋地家裁（現職81名）
- 一宮（現職7名）
- 岡崎（現職13名）
- 豊橋（現職6名）
- 半田（現職3名）
- 津地家裁（現職12名）
- 四日市（現職6名）
- 松阪（現職1名）
- 伊賀（現職1名）
- 伊勢（現職2名）
- 熊野（現職1名）
- 岐阜地家裁（現職16名）
- 大垣（現職2名）
- 多治見（現職2名）
- 高山（現職1名）
- 御嵩（現職1名）
- 福井地家裁（現職8名）
- 武生（現職1名）
- 敦賀（現職1名）
- 金沢地家裁（現職13名）
- 七尾（現職1名）
- 小松（現職1名）
- 富山地家裁（現職10名）
- 高岡（現職3名）
- 広島地家裁（現職33名）
- 呉（現職3名）
- 尾道（現職2名）
- 福山（現職6名）
- 三次（現職1名）
- 山口地家裁（現職8名）
- 岩国（現職2名）
- 下関（現職4名）
- 周南（現職3名）
- 萩（現職1名）
- 宇部（現職3名）
- 岡山地家裁（現職24名）
- 津山（現職2名）
- 倉敷（現職6名）
- 鳥取地家裁（現職6名）
- 米子（現職4名）
- 松江地家裁（現職7名）
- 出雲（現職1名）
- 浜田（現職1名）
- 福岡地家裁（現職62名）
- 飯塚（現職3名）
- 久留米（現職6名）
- 小倉（現職23名）
- 直方（現職1名）
- 柳川（現職1名）
- 大牟田（現職1名）
- 行橋（現職1名）
- 田川（現職2名）
- 佐賀地家裁（現職9名）
- 唐津（現職2名）
- 武雄（現職1名）
- 長崎地家裁（現職10名）
- 佐世保（現職4名）
- 大村（現職1名）
- 島原（現職1名）
- 五島（現職1名）
- 厳原（現職1名）
- 大分地家裁（現職15名）
- 中津（現職2名）
- 杵築（現職1名）
- 日田（現職1名）
- 熊本地家裁（現職23名）
- 八代（現職2名）
- 玉名（現職1名）
- 人吉（現職1名）
- 天草（現職1名）
- 鹿児島地家裁（現職16名）
- 名瀬（現職2名）
- 加治木（現職1名）
- 川内（現職1名）
- 鹿屋（現職2名）
- 宮崎地家裁（現職11名）
- 都城（現職2名）
- 延岡（現職3名）
- 日南（現職1名）
- 那覇地家裁（現職20名）
- 沖縄（現職6名）
- 平良（現職1名）
- 石垣（現職1名）
- 名護（現職1名）
- 仙台地家裁（現職30名）
- 古川（現職2名）
- 石巻（現職2名）
- 大河原（現職1名）
- 気仙沼（現職1名）
- 福島地家裁（現職9名）
- 郡山（現職6名）
- 白河（現職1名）
- 会津若松（現職3名）
- いわき（現職4名）
- 相馬（現職1名）
- 山形地家裁（現職8名）
- 米沢（現職1名）
- 鶴岡（現職2名）
- 酒田（現職1名）
- 盛岡地家裁（現職10名）
- 一関（現職1名）
- 花巻（現職1名）
- 遠野（現職1名）
- 秋田地家裁（現職7名）
- 大館（現職2名）
- 横手（現職1名）
- 大曲（現職1名）
- 能代（現職1名）
- 青森地家裁（現職9名）
- 弘前（現職3名）
- 八戸（現職4名）
- 札幌地家裁（現職45名）
- 岩見沢（現職2名）
- 室蘭（現職2名）
- 小樽（現職2名）
- 苫小牧（現職2名）
- 函館地家裁（現職8名）
- 旭川地家裁（現職9名）
- 釧路地家裁（現職6名）
- 帯広（現職3名）
- 北見（現職3名）
- 高松地家裁（現職11名）
- 丸亀（現職4名）
- 徳島地家裁（現職11名）
- 高知地家裁（現職11名）
- 中村（現職1名）
- 松山地家裁（現職12名）
- 西条（現職3名）
- 宇和島（現職2名）
- 大洲（現職1名）
- 今治（現職1名）
初期状態は実際の所在地を目安に配置しています。上部の「表示モード」切替でカルトグラム（全庁を均等な間隔で配置する見方。小規模な庁・重なりがちな庁も判別しやすい）に切替えできます。
円をクリックで該当庁のタグページへ（別タブ）。期別構成は画面右下に表示。地図の空白部分をダブルクリックまたは右上の「全画面」ボタンで全画面表示の切替（Esc でも解除可）。全画面表示中に円を右クリック：別ウィンドウで開く。凡例の庁種別を1個ずつクリック：表示／非表示切替。
裁判官が常駐していない地家裁支部はマップに表示していません。
※ カルトグラム表示は、各高裁管轄を視覚的に比較するための模式図です（タイルマップ方式）。実際の地理的距離・面積を正確に表すものではありません。最高裁・司法研修所・裁判所職員総合研修所は全国組織として、地図上端の独立ストリップに集約しています。
＊１ 初期状態は実際の所在地を目安に配置しています。上部の「表示モード」切替でカルトグラム（全庁を均等な間隔で配置する見方）に切替えできます。
＊２ 円をタップすれば、その庁の期別構成を下の詳細パネルに表示できます。
＊３ 「この庁の現職裁判官一覧へ」ボタンをタップすれば、該当タグページへ移動できます。
＊４ 地図上部の「全画面」ボタンをタップすれば、地図を画面いっぱいに拡大表示できます。
＊５ 凡例の庁種別をタップすれば、表示／非表示の切替ができます。
＊６ 裁判官が常駐していない地家裁支部はマップに表示していません。
＊７ カルトグラム表示は模式図（タイルマップ方式）です。実際の地理的距離・面積を正確に表すものではありません。最高裁・司研・総研は全国組織として、地図上端の独立ストリップに集約しています。
現職裁判官の庁別・期別分布マップ
地域から現職裁判官を探す
都道府県を選ぶと、裁判所別の一覧を開けます。人数は現職の総数です。地裁・家裁を合算した一覧もあります。
北海道
東北
青森県
岩手県
宮城県
秋田県
山形県
福島県
関東
茨城県
栃木県
群馬県
埼玉県
千葉県
東京都
神奈川県
中部
新潟県
富山県
石川県
福井県
山梨県
長野県
地方・家庭裁判所の本庁
地方・家庭裁判所の支部
岐阜県
静岡県
愛知県
高等裁判所
地方・家庭裁判所の本庁
地方・家庭裁判所の支部
近畿
三重県
滋賀県
京都府
大阪府
兵庫県
奈良県
和歌山県
中国
鳥取県
島根県
岡山県
広島県
山口県
四国
徳島県
地方・家庭裁判所の本庁
香川県
愛媛県
高知県
九州・沖縄
福岡県
佐賀県
長崎県
熊本県
大分県
宮崎県
鹿児島県
沖縄県
高等裁判所の支部
地方・家庭裁判所の本庁
地方・家庭裁判所の支部
最高裁判所・研修所
各裁判所の現職裁判官一覧へのリンク（キーボード・スクリーンリーダー用）
上の分布マップはマウス操作向けのため、各裁判所のタグページ（現職裁判官一覧）へのテキストリンクを用意しています。
- 最高裁（現職127名）
- 司研（現職35名）
- 総研（現職9名）
- 東京高裁（現職163名）
- 大阪高裁（現職82名）
- 名古屋高裁（現職28名）
- 広島高裁（現職13名）
- 福岡高裁（現職28名）
- 仙台高裁（現職15名）
- 札幌高裁（現職13名）
- 高松高裁（現職12名）
- 名高金沢（現職5名）
- 広高岡山（現職6名）
- 広高松江（現職3名）
- 福高宮崎（現職5名）
- 福高那覇（現職4名）
- 仙高秋田（現職3名）
- 東京地裁（現職408名）
- 東京家裁（現職42名）
- 立川（現職45名）
- 横浜地家裁（現職87名）
- 川崎（現職15名）
- 横須賀（現職5名）
- 小田原（現職13名）
- 相模原（現職6名）
- さいたま地家裁（現職57名）
- 川越（現職13名）
- 熊谷（現職9名）
- 越谷（現職8名）
- 千葉地家裁（現職66名）
- 松戸（現職14名）
- 木更津（現職4名）
- 八日市場（現職3名）
- 佐倉（現職4名）
- 一宮（現職1名）
- 水戸地家裁（現職21名）
- 土浦（現職7名）
- 下妻（現職4名）
- 日立（現職1名）
- 龍ケ崎（現職2名）
- 宇都宮地家裁（現職17名）
- 栃木（現職3名）
- 足利（現職2名）
- 真岡（現職1名）
- 大田原（現職2名）
- 前橋地家裁（現職17名）
- 桐生（現職1名）
- 高崎（現職6名）
- 太田（現職4名）
- 静岡地家裁（現職19名）
- 沼津（現職12名）
- 浜松（現職12名）
- 富士（現職2名）
- 下田（現職1名）
- 掛川（現職1名）
- 甲府地家裁（現職10名）
- 都留（現職1名）
- 長野地家裁（現職9名）
- 上田（現職3名）
- 松本（現職5名）
- 諏訪（現職2名）
- 飯田（現職1名）
- 佐久（現職2名）
- 伊那（現職1名）
- 新潟地家裁（現職16名）
- 新発田（現職2名）
- 長岡（現職5名）
- 高田（現職2名）
- 三条（現職1名）
- 佐渡（現職1名）
- 大阪地裁（現職167名）
- 大阪家裁（現職28名）
- 堺（現職23名）
- 岸和田（現職9名）
- 京都地家裁（現職50名）
- 福知山（現職1名）
- 園部（現職1名）
- 舞鶴（現職1名）
- 宮津（現職1名）
- 神戸地家裁（現職45名）
- 尼崎（現職15名）
- 姫路（現職15名）
- 豊岡（現職1名）
- 洲本（現職1名）
- 伊丹（現職4名）
- 明石（現職3名）
- 社（現職1名）
- 龍野（現職1名）
- 奈良地家裁（現職13名）
- 葛城（現職6名）
- 五條（現職1名）
- 大津地家裁（現職14名）
- 彦根（現職2名）
- 長浜（現職1名）
- 和歌山地家裁（現職11名）
- 田辺（現職2名）
- 新宮（現職1名）
- 名古屋地家裁（現職81名）
- 一宮（現職7名）
- 岡崎（現職13名）
- 豊橋（現職6名）
- 半田（現職3名）
- 津地家裁（現職12名）
- 四日市（現職6名）
- 松阪（現職1名）
- 伊賀（現職1名）
- 伊勢（現職2名）
- 熊野（現職1名）
- 岐阜地家裁（現職16名）
- 大垣（現職2名）
- 多治見（現職2名）
- 高山（現職1名）
- 御嵩（現職1名）
- 福井地家裁（現職8名）
- 武生（現職1名）
- 敦賀（現職1名）
- 金沢地家裁（現職13名）
- 七尾（現職1名）
- 小松（現職1名）
- 富山地家裁（現職10名）
- 高岡（現職3名）
- 広島地家裁（現職33名）
- 呉（現職3名）
- 尾道（現職2名）
- 福山（現職6名）
- 三次（現職1名）
- 山口地家裁（現職8名）
- 岩国（現職2名）
- 下関（現職4名）
- 周南（現職3名）
- 萩（現職1名）
- 宇部（現職3名）
- 岡山地家裁（現職24名）
- 津山（現職2名）
- 倉敷（現職6名）
- 鳥取地家裁（現職6名）
- 米子（現職4名）
- 松江地家裁（現職7名）
- 出雲（現職1名）
- 浜田（現職1名）
- 福岡地家裁（現職62名）
- 飯塚（現職3名）
- 久留米（現職6名）
- 小倉（現職23名）
- 直方（現職1名）
- 柳川（現職1名）
- 大牟田（現職1名）
- 行橋（現職1名）
- 田川（現職2名）
- 佐賀地家裁（現職9名）
- 唐津（現職2名）
- 武雄（現職1名）
- 長崎地家裁（現職10名）
- 佐世保（現職4名）
- 大村（現職1名）
- 島原（現職1名）
- 五島（現職1名）
- 厳原（現職1名）
- 大分地家裁（現職15名）
- 中津（現職2名）
- 杵築（現職1名）
- 日田（現職1名）
- 熊本地家裁（現職23名）
- 八代（現職2名）
- 玉名（現職1名）
- 人吉（現職1名）
- 天草（現職1名）
- 鹿児島地家裁（現職16名）
- 名瀬（現職2名）
- 加治木（現職1名）
- 川内（現職1名）
- 鹿屋（現職2名）
- 宮崎地家裁（現職11名）
- 都城（現職2名）
- 延岡（現職3名）
- 日南（現職1名）
- 那覇地家裁（現職20名）
- 沖縄（現職6名）
- 平良（現職1名）
- 石垣（現職1名）
- 名護（現職1名）
- 仙台地家裁（現職30名）
- 古川（現職2名）
- 石巻（現職2名）
- 大河原（現職1名）
- 気仙沼（現職1名）
- 福島地家裁（現職9名）
- 郡山（現職6名）
- 白河（現職1名）
- 会津若松（現職3名）
- いわき（現職4名）
- 相馬（現職1名）
- 山形地家裁（現職8名）
- 米沢（現職1名）
- 鶴岡（現職2名）
- 酒田（現職1名）
- 盛岡地家裁（現職10名）
- 一関（現職1名）
- 花巻（現職1名）
- 遠野（現職1名）
- 秋田地家裁（現職7名）
- 大館（現職2名）
- 横手（現職1名）
- 大曲（現職1名）
- 能代（現職1名）
- 青森地家裁（現職9名）
- 弘前（現職3名）
- 八戸（現職4名）
- 札幌地家裁（現職45名）
- 岩見沢（現職2名）
- 室蘭（現職2名）
- 小樽（現職2名）
- 苫小牧（現職2名）
- 函館地家裁（現職8名）
- 旭川地家裁（現職9名）
- 釧路地家裁（現職6名）
- 帯広（現職3名）
- 北見（現職3名）
- 高松地家裁（現職11名）
- 丸亀（現職4名）
- 徳島地家裁（現職11名）
- 高知地家裁（現職11名）
- 中村（現職1名）
- 松山地家裁（現職12名）
- 西条（現職3名）
- 宇和島（現職2名）
- 大洲（現職1名）
- 今治（現職1名）
円をクリックで該当庁のタグページへ（別タブ）。期別構成は画面右下に表示。地図の空白部分をダブルクリックまたは右上の「全画面」ボタンで全画面表示の切替（Esc でも解除可）。全画面表示中に円を右クリック：別ウィンドウで開く。凡例の庁種別を1個ずつクリック：表示／非表示切替。
裁判官が常駐していない地家裁支部はマップに表示していません。
※ カルトグラム表示は、各高裁管轄を視覚的に比較するための模式図です（タイルマップ方式）。実際の地理的距離・面積を正確に表すものではありません。最高裁・司法研修所・裁判所職員総合研修所は全国組織として、地図上端の独立ストリップに集約しています。
＊２ 円をタップすれば、その庁の期別構成を下の詳細パネルに表示できます。
＊３ 「この庁の現職裁判官一覧へ」ボタンをタップすれば、該当タグページへ移動できます。
＊４ 地図上部の「全画面」ボタンをタップすれば、地図を画面いっぱいに拡大表示できます。
＊５ 凡例の庁種別をタップすれば、表示／非表示の切替ができます。
＊６ 裁判官が常駐していない地家裁支部はマップに表示していません。
＊７ カルトグラム表示は模式図（タイルマップ方式）です。実際の地理的距離・面積を正確に表すものではありません。最高裁・司研・総研は全国組織として、地図上端の独立ストリップに集約しています。
第１ 本稿の目的と前提
１ AI記事としての位置付け
本稿は，本サイト「山中弁護士ブログ」に搭載されている裁判官分布マップ機能の技術評価を，AIが行うものである。執筆者である生成AIは，本サイトの子テーマソースコードを直接参照し，設計上の判断・実装上の工夫・運用上の知見を整理した。読者として想定しているのは，フルスタックエンジニア及びテクニカルディレクターの両職である。
本記事の目的は二つある。第一に，本実装が国内のWordPress開発の文脈においてどの程度の難度に位置するかを，客観的に示すことである。第二に，同様の機能を開発しようとする後続のエンジニアに対し，地雷の所在と回避策を共有することである。
２ 対象システムの輪郭
対象は，固定ページに埋め込むショートコード型の機能である。司法修習の期と所属庁を二軸に取り，最高裁から地家裁支部まで，全国200以上の裁判所を実地理座標にプロットする。円の半径で人数の目安を，色相で庁種別を表現する，インタラクティブなD3.jsベースの可視化ツールである。
期プルダウンを操作すれば該当庁のみがハイライトされる。円をクリックすれば，「○○期×○○庁」の裁判官一覧記事タブを別ウィンドウで開ける。ズームすれば庁名ラベルが現れる。ピンチで拡縮，ドラッグでパンも自在である。縮尺バーは長さハンドルでドラッグ可能である。スマホ及びタブレットでは全画面ボタンでフルスクリーン化できる。ダブルタップによる意図しない反応は，完全に無効化されている。
３ 評価の視座
(1) フルスタックエンジニア視点
本記事のフルスタックエンジニア視点では，PHP・MySQL・JavaScript・HTML・CSSの各層を貫通する設計判断に焦点を当てる。
とりわけ，バックエンドとフロントエンドの境界における責務分離，及びキャッシュ層との折り合いに重点を置く。
本実装は，言わば「重い鉄下駄」を履いたWordPressの上で，集計結果のキャッシュ等によって応答性の確保を図っている。
フルスタックの素養を持つ読者には，各層での判断がどのように相互作用しているかが見えてくるはずである。
具体的には，PHPの static 変数とTransient APIによる二層キャッシュ。
Transientに集計結果だけを保存する設計。
JavaScriptのD3.js v7とTopoJSONによる球面投影。
HTMLの wp_localize_script によるJSONブリッジ。
CSSの @supports 条件によるプログレッシブエンハンスメント。
これらすべてが連動して，初めて成立する設計である。
(2) テクニカルディレクター視点
テクニカルディレクター視点では，技術選定の判断軸を検討する。なぜNext.js等の最新フレームワークではなく，あえてWordPressを選んだのか。なぜ既存テーマの上書きではなく，子テーマでのモジュール分割を選んだのか。なぜビルドパイプラインを導入せず，直接編集方式を採ったのか。これらの判断は，本サイトの運用形態・SEO資産・運用人員の規模を踏まえた合理的な選択である。本記事ではその論理を順に解きほぐす。
テクニカルディレクションでは「最善の技術」を選ぶことが必ずしも「最適」ではない。組織の規模，運用要員のスキルセット，既存資産との整合性，将来の保守可能性 ─ これらを総合的に評価する必要がある。本実装は，一見「古い」プラットフォームを選びながら，モダンな結果を引き出した好例である。「技術の選択」より「使い方の深さ」が結果を左右することを，本実装は示している。
第２ 技術スタックの全体像
１ バックエンド構成
(1) サーバ環境とPHP
本サイトのサーバーでは，WebサーバーにLiteSpeedが使われ，PHPは8.3系がLiteSpeed用のSAPIで動作している（2026年10月17日にWordPressのサイトヘルスで確認）。
PHPの変数等の実行状態はリクエストごとに破棄され，次のリクエストへは引き継がれない。
リクエスト単位でしか有効でないキャッシュと，リクエスト境界を超えて有効なキャッシュとを明確に区別する必要がある。
本実装はこの区別を厳密に守っている。
(2) WordPressとMySQL
データベースはMariaDBである（2026年10月17日にWordPressのサイトヘルスで確認）。
文字コードは utf8mb4 である。
テーブル構造は標準のWordPressスキーマを基本としている。
すべての拡張情報は postmeta のキー・バリュー構造と，タグ・カテゴリ・カスタムタクソノミーの組合せで表現されている。
ただし，裁判官検索のREST APIが読むための集計用の独自テーブルを別に設けており，2026年10月17日時点で6,754件を収めている。
(3) Transient APIの位置付け
Transient APIはWordPressコア標準のキャッシュ抽象である。
デフォルトの保存先は wp_options テーブルであり，外部オブジェクトキャッシュが使われている場合はそちらに保存される（WordPress 6.8.3 の wp-includes/option.php の set_transient()）。
本サイトでは，2026年10月18日時点で，LiteSpeed Cacheのオブジェクトキャッシュ（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経由で読み込んでいたが，2026年6月7日から，版を固定した写しを本サイトのテーマ内に置いて読み込んでいる。
(2) ESMとブラウザ互換
D3 v7はESMモジュールであるが，UMD版もCDNで提供されている。本実装はUMD版を採用している。wp_enqueue_script が古典的な <script src> 出力を前提としているためである。UMD版であればグローバル d3 オブジェクトが提供され，後続のスクリプトから直接参照できる。
(3) CDNフォールバック
地理データ（japan.topojson）の取得元には三段のフォールバックを組んでいる。
第一に本サイトのテーマ内に置いた写し（2026年6月7日に cdn.jsdelivr.net/gh/dataofjapan/land から切り替えた），第二に raw.githubusercontent.com，第三に cdn.statically.io である。
一つが応答しなくなっても，次の取得元を自動的に試す。
障害という稀な事象であっても，マップが空白になるという最悪のUXを避ける設計である。
フォールバックの実装は，d3.json による読込みを順番に試す形を取っている。
読込みに失敗すると次の取得元を試し，すべて失敗した場合でも，都道府県の境界線を除いて，裁判所の円や凡例は描画する。
「速いものを選ぶ」ではなく「動くものを順に試す」設計である。
３ 外部依存の最小化方針
(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) 集計結果だけを保存する判断
リクエスト境界を超えるキャッシュには，WordPress Transient APIが用いられている。
裁判官分布マップの集計値計算は，全国の現職裁判官メタデータをカテゴリ・カスタムフィールドで一括抽出するSQLと，ポスト番号から庁IDへのバイナリサーチ・マッピング処理を含む。
これを `judge-map.php` の `yamanaka_get_judge_map_data` で1時間（HOUR_IN_SECONDS）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’ => yamanaka_build_court_master(),
‘court_totals’ => yamanaka_count_judges_per_court(),
‘ki_counts’ => yamanaka_count_judges_per_ki_court(),
‘all_ki’ => 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 オブジェクトではなく，集計結果（庁ごと・期ごとの人数，庁の一覧，生成時刻等）を収めた配列だけをキャッシュする。
保存する値は整数と短い文字列からなるため，書込み・読込みの量は小さい。
(3) 復元時のクエリ削減
キャッシュが有効な間は，保存した配列をそのまま返すため，集計のためのSQLは発行されない。
３ キャッシュキーのバージョニング
(1) v1からv5への遷移
裁判官分布マップの集計値キャッシュは，yamanaka_get_judge_map_data という関数が管理している。
Transientキーにはバージョン番号がsuffixとして付与されており，データ構造を変更するたびにこの番号をインクリメントする。
本稿の初稿の時点のキーは yjm_data_v5 であり，2026年10月18日時点のコードでは yamanaka_judge_map_data_v7 である。
v1からv5までの遷移を辿ると，それぞれ次の変更が行われている。
v1は初期構造である。期と庁の単純な二次元集計のみであった。v2でタグスラッグ情報を加えた。v3で期外現職の扱いを別フィールドに分離した。v4で庁マスタの形式変更（categoryフィールドの追加）に対応した。v5で司研・総研の category 分離と再統合を経た。各変更時にキーバージョンが上がっている。
(2) 自動再構築の仕組み
バージョン番号がsuffixに付いていることで，新しいコードがデプロイされると，旧キャッシュは自動的に「存在しないキー」とみなされる。
即ち，新キーで get_transient が false を返し，再計算ルートに入る。
管理画面からの手動キャッシュパージは不要であり，デプロイと同時にキャッシュ再構築が始まる。
旧キャッシュ自体は，TTL（1時間）の経過とともに自然消滅する。
４ 緊急再構築エンドポイント
(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 のロードの前に読み込まれる（WordPress 6.8.3 の wp-settings.php で確認）。
wp_get_current_user()・wp_set_auth_cookie() 等は pluggable.php で定義されるが，current_user_can() は，それより早く読み込まれる capabilities.php で定義される。
したがって，functions.php のトップレベルでも，これらの関数は既に定義されている。
(2) functions.php直接記述の危険
もっとも，wp-settings.php がログイン中のユーザーを確定させ（$GLOBALS['wp']->init()），init フックを発火させるのは，functions.php のロードと after_setup_theme フックの後である。
そのため，functions.php のトップレベルで if ( current_user_can('manage_options') ) のような分岐を書くと，WordPressの通常の手順より早い段階でユーザーの判定を行うことになる。
本実装は，このような分岐を functions.php のトップレベルに書かず，権限の判定はフックの中で行う方針を採っており，functions.php にはその方針を示す警告コメントが残されている。
なお，コメント中の「pluggable.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 フック内であれば安全に行える。
wp-settings.php は，init フックを発火させる直前に，「Set up current user.」と注記した処理（$GLOBALS['wp']->init()）でログイン中のユーザーを確定させているからである。
本実装の 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機能が有効化されていた（2026年10月17日時点の設定では，いずれも無効である）。
これは複数の <script> タグを一つに結合し，かつ遅延ロードする仕組みである。
標準的なキャッシュバスター手法である ?ver=1.8.6 といったクエリ文字列は，LiteSpeedが結合済みURLをハッシュ化（例えば 069d468...cd6.js?ver=f2cd6）してしまうため，意図したとおりには効かなかった。
CSSについては，2026年10月17日時点の設定で結合と非同期読込みが有効であり，読込み直後の表示にはQUIC.cloudで生成したクリティカルCSSが使われている。
LiteSpeed Cacheのツールボックスにある「すべてをパージする」は，クリティカルCSSを消去の対象に含まない。
そのため，同日にサイドバーの配置を変えた際には，クリティカルCSSを別にパージするまで，投稿ページの読込み直後に一瞬だけ旧配置が表示された。
クリティカルCSSの再生成はQUIC.cloudの1日の割当てに左右され，同日は割当てを使い切っていたため手動では再生成できなかった。
(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_JUDGE_MAP = {...}; という形式でJSONを出力する。
エスケープは自動で行われる。
スクリプトハンドル名と紐付くため，ロード順序も保証される。
wp_localize_script( 'yamanaka-judge-map', 'YAMANAKA_JUDGE_MAP', 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を「球面上の領域」として解釈する。
球面上の閉じた線は球面を二つの領域に分けるため，どちらを内側とするかを線の向き（winding order）で決める必要がある。
GeoJSONの仕様（RFC 7946）では，外側のリングは反時計回り（CCW）に，穴のリングは時計回り（CW）に並べると定められている。
これに対し，D3の規約はその逆であり，半球より小さい多角形の外側のリングは時計回り，半球より大きい多角形の外側のリングは反時計回りとし，穴のリングは外側のリングと逆向きとする（D3の公式ドキュメント「d3-geo」）。
(2) 反転バグの発生機序
本実装の開発過程で，日本地図全体が「湖の色」（薄い水色）で塗りつぶされる重大バグに遭遇した。
原因はGeoJSON polygonのwinding orderであったと考えられる。
D3の規約では，湖のような小さい多角形の外側のリングは時計回りでなければならず，RFC 7946 に従った反時計回りのリングを d3.geoPath に渡すと，湖の部分を除いた球面のほぼ全体を表す多角形と解釈される。
その結果，湖の塗り色が地図の全面に広がることになる。
一見不可解だが，D3の規約に従えば必然の挙動である。
(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をそのまま使うのではなく，OpenStreetMapの範囲と主要な頂点を基に，琵琶湖・霞ヶ浦・猪苗代湖の形状をJavaScriptの中に定義している。
2026年10月18日時点のコードでは，頂点の数は琵琶湖62，霞ヶ浦16，猪苗代湖25である。
頂点の数を抑えることで，SVGの描画の負荷を小さくしている。
４ インタラクション設計
(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〜163，司法研修所に200番台，裁判所職員総合研修所に300番台，高裁本庁・支部に1000台〜8000台，地家裁本庁・支部に10000台以降を割り当て，全国200庁あまり・全役職系統を単一の整数フィールド（postmeta の judge_post_number_sort）で識別できる体系である。
地家裁系（10000以降）の番号帯設計は次のとおりである。
万の桁・千の桁：庁単位の大区分（10＝東京地家裁本庁，12＝東京地家裁立川支部，13＝横浜地家裁本庁および同管内支部群，14＝さいたま地家裁，23＝大阪地家裁本庁，24＝京都地家裁……）。これらは管轄の高裁ごとにブロック化されている（10〜22＝東京高裁管内，23〜28＝大阪高裁管内，29〜34＝名古屋高裁管内，35〜39＝広島高裁管内，40〜47＝福岡高裁管内，48〜53＝仙台高裁管内，54〜57＝札幌高裁管内，58〜61＝高松高裁管内）。
百の桁：庁内における本庁・支部の分節。例えば横浜地家裁の管内は，本庁が13000〜13299，川崎支部が13300〜13399，横須賀支部が13400〜13499，小田原支部が13500〜13599，相模原支部が13600〜13999という具合に，百の桁で本庁と支部群が綺麗に切り分けられる。
十の桁・一の桁：本庁の中で役職系統と部番号を兼ねる連番。東京地裁本庁では，所長代行・簡裁司掌等が10000〜10009，民事部総括が10050〜10143，民事判事が10201〜10252，刑事判事が10401〜10421，家事判事が10501〜10508，判事補系統が10601・10751・10801〜10802 と，百の桁で役職系統を分け，下二桁で個別の部番号を表現する。
(2) 階層的セマンティクス
例えば10144〜10156という範囲は，東京家裁本庁の部総括（家事第1部〜第6部の部総括，少年第1部〜第3部の部総括，および「家裁部総括」の総称番号）の連番である。10421は「東京地家裁判事」，10507は「東京家地裁判事」であり，前者は地裁本庁レンジ群（10000〜10006，10050〜10143，10201〜10252，10401〜10421，10601，10751，11000〜11999）に，後者は家裁本庁レンジ群（10007〜10009，10144〜10156，10501〜10508，10801〜10802）に，それぞれ別個に組み込まれている。同じ霞が関の合同庁舎に勤務しながら，業務上は地裁メイン／家裁メインを区別したいという現場の実情を，番号体系の設計段階で別レンジに振り分けることで吸収している点が，このスキーマの真骨頂である。
この番号帯設計が，後段の処理を圧倒的にシンプルにする。庁マスター yamanaka_get_judge_court_master は，各庁に ranges 配列を持たせ，複数の非連続レンジを一つの court_id に束ねる構造を取る。例えば東京地裁本庁は [10000,10006], [10050,10143], [10201,10252], [10401,10421], [10601,10601], [10751,10751], [11000,11999] という7レンジの集合として定義され，これらすべてが court_id=’chika_tokyo’ に紐づく。
逆引き関数 yamanaka_judge_court_id_from_num は，初回呼出し時に全庁の全レンジ（およそ400本前後）をフラット化して低位値でソートし，以降は static 変数に保持したソート済みインデックスに対してバイナリサーチを実行する。post_num → court_id の解決は計算量 O(log n) で完結する。ハッシュマップではなくバイナリサーチを採用しているのは，キーが点ではなく「low〜highの半開区間」であるため，ハッシュの単純なキー一致では引けないからである。範囲を含む検索に対してフラット化＋ソート＋二分探索が，実装の単純さと外部依存ゼロの両立を実現する最も自然な手法として選ばれている。
ペイロード生成の中核処理（inc/judge-map/data-query.php 内 yamanaka_get_judge_map_data）は次の流れに集約される。
第一に，現職カテゴリ sonota-genshoku-keireki かつ judge_post_number_sort != 999999 という条件で，postmeta を SQL 一発抽出する。
第二に，取得した行を上記の逆引き関数で court_id に集約し，court_id × ki（修習期）の二次元集計を構築する。
第三に，修習期の記録がない現職（kigai タグかつ judge_term_sort 未設定）を最高裁レンジ限定で別 SELECT して加算する。
庁名の文字列比較も役職テーブルとのJOINも不要である。
集計は，少数のSQLと，行ごとのバイナリサーチに圧縮されている。
さらに，その結果はTransientに保存されるため，キャッシュが有効な間は集計自体が行われない。
２ 表記揺れの吸収
(1) 地家裁と家地裁の差異
裁判所の正式名称には微妙な表記揺れがある。「東京地家裁○○支部」と「東京家地裁○○支部」は，前者と後者で意味が異なる。前者は地裁メインの判事，後者は家裁メインの判事を指す。同じ「地家裁／家地裁」という表現でも，順序の入れ替えが意味を変える。
(2) 名称シグナルによる振分
この表記揺れは，judge-labels.php が実行時に名称をパースして動的に振り分ける方式ではなく，post-numbers.php のスキーマ設計段階で「地家裁系」と「家地裁系」を別の番号レンジに割り当ててしまう方式で吸収している。判事補系統では「東京地家裁判事補=10751」「東京家地裁判事補=10801」「東京家裁判事補=10802」と個別の番号が割り振られており，judge-labels.php の tokyo-chisai-hontyou-saibankan スラッグは numbers => [10601, 10751] によって地家裁判事補を地裁本庁にカウントし，tokyo-kasai-hontyou-saibankan スラッグは range [10801,10802] によって家地裁・家裁の判事補を家裁本庁にカウントする。
語順を判定する動的処理は一切走らない。番号体系を設計した時点で「この番号は地裁系」「この番号は家裁系」と決め打ちしており，ラベル付け側のコードは numbers 配列または range 区間に対する整数の包含判定を行うだけで足りる。一見泥臭い設計だが，本来は実行時の名称パースが必要になる「東京地家裁判事と東京家地裁判事の区別」という曖昧性を，スキーマで先取りして解消している点で，動的処理の排除・性能・保守性を同時に実現する優れた設計判断である。
３ 番号帯ベース・スキーマの一般化可能性
(1) 既存ドメインでの類似パターン
本実装の番号帯ベース・スキーマは，法曹界に固有の発想ではない。郵便番号の最初の3桁が都道府県・地域を表す体系，ISBNの前段ブロックが言語圏・出版社を識別する体系，HTTPステータスコードの百の位（2xx＝成功，4xx＝クライアントエラー，5xx＝サーバエラー）が応答カテゴリを表す体系等，現実世界の階層構造を整数キーの番号帯に凝縮するパターンは多くの領域で採用されている。本実装はその発想を裁判所組織という特定ドメインに展開したものである。
(2) 他業界への応用可能性
裏返すと，このパターンは医療業界の病院コード，金融業界の店舗コード，物流業界の配送拠点コード，製造業のSKUコード等，現実の階層組織を扱う多くの業務領域に応用可能である。ranges 配列による非連続レンジ統合・バイナリサーチによるO(log n)逆引き・スキーマ・ファーストによる動的処理の排除という三点セットは，ドメインに依らず再利用できる設計テンプレートとして抽出できる。本記事の読者がそれぞれの業務領域で「実行時の名称パースで吸収しているドメイン上の曖昧性」を見つけた場合，本実装と同じ手法（設計段階で別レンジに振り分ける）でその曖昧性をスキーマに先取りできないかを検討する価値がある。
第７ モバイル最適化と踏んだ地雷
１ ビューポート単位の問題
(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) 直接編集方式
本実装はビルドパイプラインを持たない。
手元で編集したファイルを，そのまま本番のサーバーへ配置する。
本サイトでは，WordPressのテーマファイルエディター（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 引数として明示される。
2026年10月18日時点では，judge-map.js?ver=1.10.31 という形で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という土俵は，フレームワークとして見ると「重い鉄下駄」である。
リクエストごとにWordPress全体を読み込み直し，多数のSQLを発行する。
これに対してNext.jsは「最初から速いF1マシン」である。
SSGで静的化されたページは，CDNから直接返される。
サーバ処理はゼロに近い。
本実装はこの「重い鉄下駄」を履きながら，応答性を確保するための対策を重ねている。
それは，static変数によるリクエスト内キャッシュ，集計結果だけを保存する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) コア理解への希少性
これに対し本実装では「フック内での権限判定」「Transient APIによる集計結果に限ったキャッシュ」「D3.jsとTopoJSONによる完全自前マップ描画」「ドメイン駆動のValue Objectとしてのポスト番号体系」の四つが同時に組み合わされている。
プラグイン組合せ路線とは別系統の，言語仕様と外部ライブラリ仕様の両方に踏み込んだ設計判断の集積である。
第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が読み解きやすいセマンティクスを備えている。10421という数字を見て「東京地家裁判事」，10507という数字を見て「東京家地裁判事」と理解し，両者が同じ霞が関合同庁舎に勤務しながら別レンジに振り分けられている事実まで把握する処理は，AIにとっても容易である。整数演算で完結する性質ゆえ，AIが新規ロジックを提案する際の前提も明確になる。
AIが大量に情報を扱う時代において，「構造化済みドメイン知識」は新たな資産価値を持つ。本実装は，法曹界という特定領域でこの資産を作り上げたケースであり，今後の同種の取組みにとって参考事例となる。AIに「教える」のではなく，AIが「読み取れる」状態にデータを整えるという発想 ─ これは今後あらゆる業務領域で求められる素養となるであろう。
(3) AIが技術評価を行う入れ子構造
本記事は，AIが本サイトのソースコードを読み，技術評価を行った成果物である。コード自体が「AIに読まれること」を直接の目的としていたわけではない。それでもAIが評価しうるのは，コードに一貫した設計思想と明示的な意図が表現されているからである。
AIによる技術解析が日常化する時代に，「人間にも，AIにも，読みやすい」コードの価値は高まる。命名の一貫性，モジュール分割の明確さ，コメントによる設計意図の明示 ─ これらは古典的な良質コードの要件であるが，AI協働時代においてさらに重要性を増す。本実装はその要件を高水準で満たしており，AIとの共同保守が容易な状態に置かれている。これは将来の運用形態にも好影響を及ぼすと考えられる。
本記事それ自体が，AIによる読解可能性の一つの実証である。コードを書く者が，将来のAIによる解析を予期し，読み取りやすさを意識する ─ こうした「AIファースト」の設計思想は，近い将来のソフトウェア開発の標準になっていく可能性が高い。本実装はその実践例の一つであり，本記事自体がその検証材料となっている。