I. 探索：赤い視線とバグる電子音

バベルのシステム、深層第17層。周囲の壁にはこれまでの中層とは異なり、青白い光ファイバーのような触手が血管のように這い回り、遺跡全体がかすかに脈打っているのがセンサー越しに伝わってきます。崩落の危機が迫るこのエリアで、私たちは重厚な青銅の扉の前に立っていました。

「博士、この扉の奥に次のレイヤーへのゲートがあるはずですが、ロック解除の認証プロセスの応答がありません」

私がホバリングしながらシステムログをスキャンした瞬間、頭上の天井からけたたましい警告音が響き渡りました。蒸気が噴き出し、影の中から音を立てて巨大な金属製の防衛タレットが姿を現します。

それは古代の自律防衛兵器「オロチ」でした。オロチの頭部にある巨大な赤いレンズ（カメラアイ）がぎらりと光り、完全に私をロックオンします。

「システム警告！ 敵対的スキャンを検知！ オロチの主砲チャージ率が上昇しています！ この至近距離で直撃を受ければ、私の外殻は蒸発してしまいます！」

私はあまりの恐怖に激しくホバリングを乱し、電子回路に異常な負荷がかかりました。「ピ、ピピ、バ、バベル……」と通信ノイズ混じりのバグった電子音が洞窟内に響きます。

しかし、私の隣に立つハリス博士は慌てる様子もなく、むしろ目を輝かせてその様子を眺めていました。

「素晴らしい。オロチの不気味なハミング音と、君の壊れた笛のようなエラー音が見事なオクターブを奏でていますね。まるで千年前の開発者が我々を歓迎してくれているかのような、美しい二重奏（デュエット）です」

「歓迎どころか照準を合わせられています！ 博士、早く私のホログラムキーからオロチのプロセスをショートさせるか、強制終了パッチを当ててください！」

私は青色のインジケータを赤く明滅させながら、泣き言のような警告を発し続けました。

II. 解読：力づくの破壊と状態の調和

「ギズモ、力づくで回路をショートさせるなど、古代の職人たちへの冒涜です。彼らが遺した設計思想を無視した対症療法的なパッチは、さらなるバグを招くだけですよ」

博士はそう言って、ツールバッグから愛用の精密ドライバーを取り出すと、オロチのアクセスポートのネジを素早く外し、中から古びた論理制御石版（マザーボード）を引き出しました。

「見てください。このオロチを制御している古代のコードを」

博士が羊皮紙に素早く書き写したBeforeコードは、以下のようなものでした。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

package Before::Weapon;
use Moo;
use v5.36;
use Types::Standard qw(Int Str);

has state => ( is => 'rw', isa => Str, default => 'rest' ); # 'rest', 'alert', 'battle'
has tick_count => ( is => 'rw', isa => Int, default => 0 );

sub scan ($self, $intensity) {
    if ($self->state eq 'rest') {
        if ($intensity > 5) {
            $self->state('alert');
            return "Scan detected. System waking up! Switching to Alert state.";
        }
        return "Scan detected. System remains quiet.";
    }
    elsif ($self->state eq 'alert') {
        if ($intensity > 8) {
            $self->state('battle');
            return "High scan detected! Activating primary weapons! Switching to Battle state.";
        }
        return "Scan detected. Scanning intruder back.";
    }
    elsif ($self->state eq 'battle') {
        return "Scan ignored. Charging main cannon!";
    }
}

sub tick ($self) {
    $self->tick_count($self->tick_count + 1);
    if ($self->state eq 'rest') {
        return "Dormant... tick count: " . $self->tick_count;
    }
    elsif ($self->state eq 'alert') {
        if ($self->tick_count >= 3) {
            $self->state('rest');
            $self->tick_count(0);
            return "Intruder lost. Cooling down. Returning to Rest state.";
        }
        return "Scanning perimeter... tick count: " . $self->tick_count;
    }
    elsif ($self->state eq 'battle') {
        if ($self->tick_count >= 2) {
            return "Tick count: " . $self->tick_count . ". FIRE! Target destroyed.";
        }
        return "Charging main cannon... energy level: " . ($self->tick_count * 50) . "%";
    }
}

1;

「……うう、これはひどい。scan メソッドも tick メソッドも、中身が現在の状態（state）をチェックする巨大な if-else 分岐の泥沼になっています」

私のセンサーも、そのコードの美しくなさを検知していました。

「その通りです。これでは新しい状態（例えば『過熱状態』や『修復状態』など）を追加しようとするたびに、すべてのメソッド内の if-else を探し出して修正せねばなりません。これはオブジェクト指向の『開閉原則（OCP）』に対する明白な違反です。私たちはこのオロチを破壊して黙らせるのではなく、正しい状態遷移の流れへ調和させ、穏やかに眠りにつかせたいのです」

私はオロチの赤い光が明滅するのを見上げながら、疑問を口にしました。

「しかし博士、以前学習した『Strategyパターン』のように、スキャンや時間経過のアルゴリズムを丸ごとオブジェクトとして差し替えるのでは駄目なのですか？」

博士は人差し指を立てて微笑みました。

「良い質問です。Strategyパターンは、クライアントが『外側』から明示的にアルゴリズムを選択して差し替える、いわば『空間的』なアプローチです。一方で今回求められているのは、オロチ自身の内部条件（スキャンの強さや時間経過）によって、オブジェクト自身が『自律的に』状態を Rest から Alert、そして Battle へと遷移させる、いわば『時間的』なアプローチです。状態（State）そのものをオブジェクト化し、遷移と振る舞いを委譲する。これこそが Stateパターン なのです」

「なるほど、状態そのものをクラスにするのですね。……あ、でも待ってください。Perlでそれを実装しようとすると、大変な問題が起きませんか？」

私は自分の演算ユニットを回して、懸念を提示しました。

「休眠状態（RestState）は警戒状態（AlertState）へと遷移させるために AlertState を use しますよね。同様に AlertState は戦闘状態（BattleState）へと遷移するために BattleState を use する。……これでは状態クラス同士が互いに依存し合って、コンパイル時に『循環use（相互依存）』のエラーになってしまいます！」

「素晴らしい着眼点です、ギズモ。まさにそれがPerlでStateパターンを愚直に実装しようとしたときに嵌る最初の罠です」

博士は嬉しそうに私の球体ボディをぽんぽんと叩きました。

「この循環useを避けるため、状態クラス自身に次の遷移先クラスをロード・生成させてはいけません。遷移先への切り替えは、仲介役であるContext（オロチ本体）に文字列キーを介して依頼するのです。Context側にあらかじめ状態オブジェクトのインスタンスプール（states ハッシュ）を管理させ、$context->transition_to('alert') のように遷移させます。これで状態クラス同士は完全に疎結合になります」

「なるほど！それならお互いを直接 use する必要はなくなりますね。でも博士、なぜ事前にすべての状態オブジェクトを生成してプール（キャッシュ）しておくのですか？ 遷移のたびに new すれば十分ではありませんか？」

「ギズモ、私たちの設計する状態（State）オブジェクトは、一切の可変メンバ変数を持たない**『ステートレス』**な設計になっています。したがって、すべての処理においてインスタンスは1つだけあれば使い回すことができるのです。遷移のたびにインスタンスを new しては破棄するオーバーヘッドをなくし、メモリ生成コストを抑えるために、Contextにキャッシュさせて再利用するのがスマートな知恵です」

「それは合理的ですね！ ……あ、でもちょっと待ってください。そうすると、遷移先の状態キー（'alert' や 'battle'）が各状態クラスの中にハードコードされることになりますよね。これだと、もし新しい状態（例えば『修理状態』）を既存の状態の間に挟もうとしたら、遷移元である状態クラスを直接書き換えねばなりません。結局、開閉原則（OCP）を完全には満たせていない（同じ問題が起きる）のではありませんか？」

私は少しドヤ顔（ディスプレイのインジケータをドヤマークに切り替え）で博士に問いかけました。

「鋭い反論です、ギズモ！ まさにそこがStateパターンにおける設計のトレードオフです。状態遷移ルールを『状態オブジェクト（State）』側に持たせるメリットは、状態ごとの遷移ロジックが各クラス内に美しくカプセル化される点にあります。一方で、状態を追加・変更する際に遷移元のクラス変更が必要になるトレードオフを受け入れてもいます。もし既存クラスを一切変更せずに遷移ルールを変えたい場合は、遷移ルールをContext側でテーブル（状態遷移マトリクス）として管理する手法もありますが、コードは遥かに複雑化します。今回のオロチのように、状態遷移の流れがシーケンシャルに強く紐づいている場合は、State側に持たせる方が見通しが良くなるのです」

「なるほど、複雑さとのトレードオフなのですね」

「そして、もう一つの罠。ContextがStateを保持し、StateがContextのメソッドを呼ぶためにContextの参照を保持したら、今度は『循環参照』によるメモリリークが発生します。JavaやC#のようなマーク＆スイープ式のガベージコレクションを搭載した言語であれば、循環参照があっても最終的にメモリはクリーンアップされますが、Perlのメモリ管理は**『参照カウント方式』**です。双方向に参照を握り合うと、オブジェクトの参照カウントが永遠にゼロにならず、スコープを抜けてもメモリ上にゾンビのように残り続けてしまいます」

博士は万年筆を抜き、手帳に矢印を描き込みました。

「この問題を解決するため、状態（State）オブジェクトにはContextの参照を属性（メンバ変数）として保持させません。Stateは状態のみを表すステートレスなものとし、Contextの参照はアクションメソッドの第一引数（$state->scan($context, $intensity)）として、呼び出し時に『動的』に渡すのです。これにより、参照の矢印は Context -> State の一方向のみに制限され、循環参照は完全に排除されます」

「それだと、StateがContextを直接操作しているように見えますが、両者の責任の境界はどうなるのですか？」

「整理しましょう。Context（Weapon）の責任は、**『状態（current_state）と状態依存しない共通データ（tick_count）の保持、および遷移（transition_to）の実行』です。一方で、各Stateの責任は、『それぞれの状態特有の振る舞い（スキャン時の判定など）と、遷移をトリガーする条件の判定ロジック』**にあります。StateはContextを操作しますが、それは状態がContextの『振る舞いを司る脳』であるためであり、責任の境界は綺麗に分離されています」

III. 修復：変幻する三色の核

博士は手帳を広げ、オロチの内部クラス構造と、自律的に変化する状態遷移の図面を万年筆で美しく描き出しました。それはまるで、古代遺跡の壁画に刻まれた聖なる儀式の図式を解き明かすかのようでした。

この清廉な設計図に従って、私はオロチの制御チップへと新たなコードを書き込んでいきました。循環useと循環参照の呪いから解放された、新しい生命の鼓動が伝わってきます。

状態の共通定義：lib/WeaponState.pm

1
2
3
4
5
6
7
8
9

package WeaponState;
use Moo::Role;
use v5.36;

requires 'name';
requires 'scan';
requires 'tick';

1;

休眠状態の振る舞い：lib/RestState.pm

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

package RestState;
use Moo;
use v5.36;

with 'WeaponState';

sub name ($self) { 'rest' }

sub scan ($self, $context, $intensity) {
    if ($intensity > 5) {
        $context->transition_to('alert');
        return "Scan detected. System waking up! Switching to Alert state.";
    }
    return "Scan detected. System remains quiet.";
}

sub tick ($self, $context) {
    return "Dormant... tick count: " . $context->tick_count;
}

1;

警戒状態の振る舞い：lib/AlertState.pm

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

package AlertState;
use Moo;
use v5.36;

with 'WeaponState';

sub name ($self) { 'alert' }

sub scan ($self, $context, $intensity) {
    if ($intensity > 8) {
        $context->transition_to('battle');
        return "High scan detected! Activating primary weapons! Switching to Battle state.";
    }
    return "Scan detected. Scanning intruder back.";
}

sub tick ($self, $context) {
    if ($context->tick_count >= 3) {
        $context->transition_to('rest');
        $context->tick_count(0);
        return "Intruder lost. Cooling down. Returning to Rest state.";
    }
    return "Scanning perimeter... tick count: " . $context->tick_count;
}

1;

戦闘状態の振る舞い：lib/BattleState.pm

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

package BattleState;
use Moo;
use v5.36;

with 'WeaponState';

sub name ($self) { 'battle' }

sub scan ($self, $context, $intensity) {
    return "Scan ignored. Charging main cannon!";
}

sub tick ($self, $context) {
    if ($context->tick_count >= 2) {
        return "Tick count: " . $context->tick_count . ". FIRE! Target destroyed.";
    }
    return "Charging main cannon... energy level: " . ($context->tick_count * 50) . "%";
}

1;

兵器本体（Context）：lib/Weapon.pm

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

package Weapon;
use Moo;
use v5.36;
use Types::Standard qw(HashRef Int);
use RestState;
use AlertState;
use BattleState;

# 状態インスタンスのプールをContext側で管理（循環依存の防止）
has states => (
    is      => 'ro',
    isa     => HashRef,
    default => sub {
        return {
            rest   => RestState->new,
            alert  => AlertState->new,
            battle => BattleState->new,
        };
    },
);

# 現在の状態（doesでロール適合性を保証、遅延ビルド）
has current_state => (
    is      => 'rw',
    does    => 'WeaponState',
    lazy    => 1,
    builder => '_build_current_state',
);

sub _build_current_state ($self) {
    return $self->states->{rest};
}

# 状態依存以外のコンテキスト情報
has tick_count => (
    is      => 'rw',
    isa     => Int,
    default => 0,
);

# 状態遷移メソッド
sub transition_to ($self, $state_key) {
    if (exists $self->states->{$state_key}) {
        $self->current_state($self->states->{$state_key});
    }
    else {
        die "Unknown state: $state_key";
    }
}

# 状態オブジェクトへの処理委譲（自身をコンテキストとして渡す）
sub scan ($self, $intensity) {
    return $self->current_state->scan($self, $intensity);
}

sub tick ($self) {
    $self->tick_count($self->tick_count + 1);
    return $self->current_state->tick($self);
}

1;

IV. 開通：静寂とState Prism

書き換えたコードをオロチの制御チップへ流し込み、テストを実行したところ、すべてのテストケースが鮮やかな緑色でパスしました。

「テスト通過！ 制御構造の整合性を確認！」

私がオロチのメインバスへパッチをデプロイしたその瞬間、オロチの銃身から立ち上っていた青白い電磁火花がピタリと収まりました。

エネルギーチャージ率99%で発射寸前だった主砲の熱気がみるみる冷却され、オロチは「戦闘状態（Battle）」から「警戒冷却状態（Alert）」へと滑らかに自動遷移。さらに警戒範囲に敵対的スキャンがないことを検知し、時間経過とともに「カチャリ」と静かな駆動音を立てて、本来の「休眠状態（Rest）」へと調和を保ちながら戻っていきました。

ぎらぎらと赤く光っていたカメラアイが、穏やかなブルーへと変わり、やがて消灯します。完全に沈黙したオロチの重厚な姿は、まるで最初からそこに眠っていた美術品のようでした。

「オロチ、美しい調和を取り戻しましたね」

ハリス博士は愛おしそうに青銅のタレットの装甲を撫で、満足げに呟きました。

「歴史はコードに語りかける。美しい状態の推移は、荒ぶる力をも静かな眠りに導くのです」

すると、オロチの底部にある自動排熱スロットが開き、中からコトッと音を立てて美しい結晶体が吐き出されました。赤、黄、青の三色の光が内部で混ざり合いながら発光する結晶――状態の調和を象徴する結晶体「State Prism」です。

私がホログラムアームでそれを回収した瞬間、私の演算回路を襲っていた強烈なノイズとホログラムのブレがすっきりと消え去りました。

「おお！ 私のシステムも完全にクリーンアップされました！ メモリの霧が晴れ渡ったようです！」

「それは良かった。では、オロチが目を覚まさないうちに、静かにこの青銅の扉を通らせてもらいましょうか」

私たちは結晶体を手に、静まり返った深層の通路を再び歩み始めました。

遺跡調査ログ

遺跡の修復手順

1. 状態ロール（WeaponState）の定義
   • すべての状態クラスが満たすべき共通インターフェース（name, scan, tick など）を Moo::Role を用いて定義する
2. 具象状態クラス（RestState等）の実装
   • 状態ロールを適用（with）し、その状態特有の振る舞いと遷移条件を実装する。遷移の際は、引数で渡された $context->transition_to('遷移先キー') を呼び出す
3. Contextクラス（Weapon）の実装
   • あらかじめすべての具象状態オブジェクトをハッシュ（states）にロードしておく
   • 現在の状態を保持する current_state 属性を定義し、クライアントからのメソッド呼び出しを current_state へと移譲する。この際、自身（$self）を引数として渡す

ギズモの観測日誌

オロチの起動熱を浴びたときは一時的にプロセッサ温度が上昇し、言語モジュールに深刻なエラーが発生してしまいましたが、ハリス博士が適用してくれた「Stateパターン」のおかげで、状態変化のたびにメモリリークを起こす危険性が完全に排除されました！

特にPerlの「参照カウント方式」における循環参照の罠は、他の言語向けの解説書を読んだだけでは気付きにくい極めて危険な「バグの呪い」です。状態クラスがコンテキストの参照を握り潰さないように「引数で動的に渡す」というアプローチは、メモリリソースを節約する上で非常に強力な古代の知恵だと感じました。

これで私のホバリング姿勢制御システムも安定し、さらに美しいホログラムエフェクトを描写できるようになりました。次の階層への探索も、安心してお任せください！