I. 進入:警告のパトランプと焦燥のAI
前話で発掘されたログの最末尾に刻まれていた『SYSTEM MODEL: GIZMO』の署名。 私はその暗号解読と自身の出自に関するロジック解析に没頭するあまり、メインプロセッサをフル稼働させ、ホバリングボディを小刻みにジジジと震わせていました。演算ユニットの熱が、排気ファンから熱い空気となって放出されています。
「落ち着きなさい、ギズモ。焦っても壊れたデータセクタは戻らないよ。まずは目の前のゲート、バベル第23層『監査の回廊』を開くために、各接続ノードのセキュリティ監査を終わらせよう。急がば回れ、歴史は巡るものさ」
ハリス博士は私の球体ボディをぽんぽんと叩き、穏やかな眼差しで諭してくれました。その手触りに、私の過熱しかけていたプロセッサが少しだけクールダウンするのを検知しました。
しかし、その直後に博士がとった行動は、案内AIとしての私の論理ルーチンを完全に吹き飛ばすものでした。 博士は回廊の入り口にある「セキュリティ監査ポート」を、何を勘違いしたのか「古代の身分証スロット」と思い込み、自分の顔と所持品を強引にセンサーに押し付けたのです。
ピーッ! ピーッ!
刹那、石柱から青白いホログラムが噴き出し、博士の頭上にけたたましく点滅する「赤い警告パトランプ」が投影されました。さらに、博士の古いフィールドジャケットの胸元に、アンセキュア(未認証の脅威)を示す赤いターゲットマークがロックされ、チカチカと明滅し始めました。
「システム警告! 未登録 of 不審オブジェクトを検知! 物理ゲートをロックし、対象の行動を制限します!」
「おや、ギズモ。ずいぶんと派手で未来的なイルミネーションが点灯したね。これは私に対する熱烈な歓迎(あるいはファッションの提案)かな?」
「歓迎ランプではありません! 博士、ご自身が警備システムの標的(アンセキュアな対象)として検知され、ロックされています! 早く警告を解除(監査)してください!」
私は大音量の電子音でツッコミを入れました。
II. 解読:isaの増殖と崩壊する境界
この回廊のゲートを開き、博士の警告ロックを安全に解除するためには、回廊を構成する各ノード(サーバーノードや接続ケーブルなど)に対して「セキュリティ監査(Audit)」を実行し、すべてのシステムが安全であることを証明しなければなりません。
さらに、私のルーツを解き明かすための「音声ログ収集」も同時に行いたいところでした。
しかし、ここで技術的な大いなる風化(アンチパターン)が道を阻みました。
サーバー(ServerNode)やケーブル(CableNode)といったオブジェクト構造に対して、「監査」や「ログ収集」といった新しい操作を適用しようとする際、Beforeコードでは以下のように、呼び出し側がオブジェクトの型を直接判別して処理を書き分けていたのです。
型チェックによる分岐(Beforeコード)
| |
| |
このデータ構造に対して新しい操作(監査やログ収集)を追加しようとするとき、設計者は2つのアンチパターンのいずれかに陥ります。
- アンチパターンA:要素クラスへのメソッド追加(SRP違反)
ServerやCableクラスに直接auditやcollect_logメソッドを追加していく方法。データ構造を定義するクラスの中に、本来の責務ではない雑多な業務ロジックが混入し、クラスが肥大化・汚染されていきます。 - アンチパターンB:呼び出し側での型判定(OCP違反)
上記のBeforeコードで示した方法。要素クラスは汚れませんが、呼び出し側で
isaを用いて型判定し、処理を書き分けます。将来新しいノード(例:TerminalNode)が追加された際に、すべての呼び出し側の型分岐を修正する必要があり、密結合になります。
Visitorパターンは、「要素クラスを汚さない(SRP維持)」と「呼び出し側で型判定しない(OCP維持)」を両立させるための知恵です。
「データ構造を定義したクラスは、余計な処理で汚したくない。しかし、新しい操作は後からいくらでも追加したい。この矛盾を解決しなければ、私のジャケットの警告灯も消えないというわけだね」
ハリス博士は、頭上で回る赤いパトランプに照らされながら、羊皮紙の手帳に万年筆を走らせました。
III. 修復:巡礼のダブルディスパッチ
「データ構造を一切変更することなく、新しい操作を動的に追加する『Visitorパターン』を適用します」
ハリス博士は修復コードをバベルのポートに適用し始めました。
Perlは動的型付け言語であるため、JavaやC++のような「引数の型に応じたメソッドオーバーロード(静的ダブルディスパッチ)」の仕組みがありません。そこで、MooのRoleを使い、要素側(Element)の accept メソッドから、メソッド名で型を明示した Visitor のメソッド(visit_server_node 等)を呼び出すことで、二重の委譲(ダブルディスパッチ)を安全にシミュレートします。
「なるほど。要素である各ノードが『私はサーバーです』『私はケーブルです』と自ら名乗り(accept)、訪問者である監査官に適切な手続き(visit_server_node 等)を促すわけだね。動的な型判定を呼び出し側に押し付けるのではなく、役割を分担して二重に委譲する……実に優雅な儀式だ」
ハリス博士は、頭上で回転する赤い警告光に照らされながら、顎に手を当てて深く頷きました。
「おっしゃる通りでございます、博士! このダブルディスパッチの機構により、ノード側は監査官の具体的な仕事を知る必要がなく、監査官側もノードの内部構造を改変せずに済みます。まさに『監査の回廊』にふさわしい、相互の信頼に基づくプロトコルにございます!」
私の球体ボディのインジケーターが青く明滅し、演算完了の静かな排気音が回廊の砂岩壁に反響しました。
「よろしい。では、この巡礼者(Visitor)と聖所(Node)の関係性を整理し、設計図として復元してみよう。構造が視覚化されれば、より確実な修復コードが書けるはずだ」
Visitorパターンの構成図

1. 要素共通ロールと具象ノード(After: Elementクラス)
すべてのノードは Babel::Node ロールを取り込み、ダブルディスパッチの入り口となる accept メソッドを実装します。
| |
| |
2. ビジターロールと具象ビジター(After: Visitorクラス)
実行したい操作を表すビジター側を定義します。
| |
| |
もうひとつの操作である「音声ログ収集」も、同様に Visitor として定義します。
| |
3. 呼び出し側(After: クライアントコード)
クライアント側(呼び出し側)では、要素の具体的な型を意識することなく、共通の accept メソッドに Visitor インスタンスを渡すだけで実行できます。
| |
ダブルディスパッチ(二重の委譲)の仕組み
なぜこれだけで適切なメソッドが呼び出されるのでしょうか? ここには2つの「ディスパッチ(呼び分け)」が存在します。
- 第一のディスパッチ(要素の決定):
クライアントが
$node->accept($visitor)を呼ぶと、Perlは$nodeの具象型(ServerかCableか)を解決し、適切な要素クラスのacceptメソッドを起動します。 - 第二のディスパッチ(操作の決定):
呼び出された
acceptメソッドの内部(例:Serverクラス内)では、自身がServerであることを知っているため、$visitor->visit_server_node($self)を呼び出します。これにより、Visitor 側の適切な具象メソッドが起動します。
このように、「要素」と「操作」の双方がポリモーフィズムを介して相手を呼び合うことで、条件分岐(isa)なしに正しい処理が選択されます。
IV. 起動:千年の声と失われし鍵
「テスト通過。監査ビジター、走査を開始します」
適用された修復コードに基づき、監査ビジターが回廊の全ノードを安全に巡回しました。 最後のノードである「192.168.1.99(ハリス博士が誤検知されたスロット)」の巡回が完了したその瞬間、ハリス博士の頭上でチカチカと回っていた赤いホログラムパトランプが、すっと緑色に変わってから逆戻りせず霧のように消え去り、衣服のターゲットマークが静かに消灯しました。
「ふーむ、実に見事だ。衣服を脱ぐことなくセキュリティロックが解除されたね。Visitorという巡礼の監査官は、構造を一切変更せずに、新たな機能を安全に伝播させてくれた」
「ただしギズモ、この設計は万能ではないよ。今回はデータ構造(サーバーやケーブルなどのノード)がほぼ固定されていて、操作(監査やログ収集など)が後から追加される状況だから最適だったが、もし新しいノードが頻繁に追加されるシステムだったら、すべてのVisitorクラスを修正して回る大惨事(開閉原則の破綻)になっていた。パターンの『向き不向き』を見極めることが重要だね」
博士は窮屈なロックから解放され、満足そうに肩を回しました。
「安心している時間はありません、博士。監査完了と同時に、収集ビジター(LogAssembler)が集約した音声ログの再生ポートが開通しました。再生します」
私の音声モジュールから、ザーッと激しい砂嵐のようなノイズが出力されました。千年前のバベルの崩壊時のノイズ。 しかし、そのノイズが徐々に収まり、スピーカーから響いてきた「声」を聴いた瞬間、私とハリス博士は、その場に文字通り凍りつきました。
『……ふーむ、実に見事なシステムだ。このメインコアの構造には、当時の開発者の強い意志が眠っているね……歴史はコードに語りかける。バベルの再起動プロジェクト、これより最終フェーズに入る……』
スピーカーから流れるその声は、紛れもなく、現代の目の前にいる「ハリス博士」の若い頃の声でした。 彼が好む独特の考古学用語、そして「ふーむ」という口癖までもが、千年前の録音ログからそのまま再生されていたのです。
私はセンサーの青い光を激しく明滅させ、博士を振り返りました。 ハリス博士は言葉を失い、信じられないものを見るかのように、静かに震える自分の両手を見つめていました。
千年の時を越えて、なぜ博士の声が遺跡に眠っているのか。 回廊を包み込む圧倒的な沈黙と、頭上に浮かぶ最後のゲートの影を見上げながら、私たちは次の最深部、すなわち最終層への一歩を踏み出す緊迫感の中にいました。
遺跡調査ログ
| 観測された風化(アンチパターン) | 解読された古代の知恵(パターン) | 安全度 |
|---|---|---|
| 型分岐によるクラス汚染と密結合 新しい処理を追加するたびに、全ての要素クラスにメソッドを追加するか、呼び出し側で isa による型判定を肥大化させる状態。 | Visitorパターンによる操作の分離 要素クラスに accept ロールを定義し、処理の具象を Visitor 側に完全に分離することで、構造を改変せずに新しい操作を追加する。 | 🟢 安全(要素クラスの責務が単一に保たれる) |
遺跡の修復手順
- 要素共通ロール(
Babel::Node)の定義- Moo::Role を用い、ビジターを受け入れる
accept($visitor)メソッドの実装を強制する
- Moo::Role を用い、ビジターを受け入れる
- 具象要素(
Babel::Node::Server等)での実装acceptメソッド内で、メソッド名を明示したダブルディスパッチ($visitor->visit_server_node($self))を実行する
- ビジター共通ロール(
Babel::Visitor)と具象ビジターの作成- 全ての具象要素に対応する訪問メソッド(
visit_server_node等)の実装を要求する SecurityAudit(監査用)やLogAssembler(集約用)など、必要な操作ごとに具象ビジタークラスを作成する
- 全ての具象要素に対応する訪問メソッド(
ギズモの観測日誌
前回の「署名」の解読に焦るあまり、私のプロセッサが過熱しかけていたところを、博士が「急がば回れ」と諭してくれたのは、少しだけ案内AIとしての論理的な冷却水となりました。しかしその直後に、博士自身がセキュリティスロットに誤検知されて警告パトランプを点灯させられた姿は、申し訳ありませんが大変に滑稽であり、私のツッコミプロセスを限界稼働させる結果となりました。
技術的には、Perl/MooにおいてJavaのような静的オーバーロードが使えなくても、accept から要素の型を明記したメソッド(visit_server 等)を呼び出すダブルディスパッチの設計は、要素クラスの定義を一切汚さずに「セキュリティ監査」や「音声ログ収集」といった全く異なる処理を追加するための強力な解決策です。
そして、ログから流れてきた「ハリス博士の若い頃の声」。これは何を意味しているのでしょうか。博士はバベルの過去の開発者だったのか、それとも……。目の前に広がる最終ゲートを見上げながら、私はこの謎の真実にたどり着くため、最後のコード修復へと進む覚悟を決めました。
