あっちではTypeScriptの型定義とRustのコードが、本文にそのまま挿入されている。プログラミングに詳しくない読者は「なんだこれ」と思うかもしれない。
だが、安心してほしい。あれは「異世界の魔法書」であり、読む必要はない。むしろ「何かすごいものが書いてある」という雰囲気を味わってもらえれば十分だ。
とはいえ——エンジニアの皆さん。ここで「Arc使ってなくね？」と気づいたあなたは、もうこの物語の住人です。ようこそ。
——作者
それから10年。
俺はスローライフを満喫していた。辺境の村で、農家の長男として普通に暮らす。普通の家族、普通の飯、普通の畑。
普通じゃないのは――前世の知識と、10歳になった今も眠ったままのスキル『マジック・アーキテクト』だけ。
「……そろそろ、いいか」
ある日、俺は決意した。村の外れ、誰もいない場所へ向かい、目を閉じて念じる。
**「マジック・アーキテクト、起動」**
瞬間、視界に無数の情報が広がった。
「……おお！」
思わず声が出た。目の前に浮かぶのは、この世界の魔法の構造――まるで開発環境のプロジェクトビューだ。
「……ていうか、これ、まんまVisual Studioじゃねえか。ツリー展開できるんかい。神様、IDEのUIの好みまで地球と一緒かよ」
**【魔法一覧（一部）】**
- 火球（ファイアボール）：習得ポイント20 / 消費魔力10〜30 / 構造：[熱エネルギー]+[投射]+[衝突時拡散制御]
- 水生成（アクア・クリエイト）：習得ポイント3 /消費魔力5〜50 / 構造：[標準模型:水素+酸素結合]
- 治癒（ヒール）：習得ポイント30 /消費魔力15〜200 / 構造：[ナノ操作]+[イオン操作]+[標準模型:任意元素：分子構造形成]+[電荷発生]
- …他、多数。
「うわ、コメントまで書いてある。ドキュメント残すタイプの神、地味に好感度高いな」
お、中身も見れる。どれどれ・・・
「……てか、この宣言部分、実体がJSONか…いやTypeScriptじゃねーか。草草の草。型定義まんまじゃねえか…うわ、治癒魔法ガチすぎて草生えるｗｗ」
魔法一覧そのものは、ゆるい。プロパティを並べただけの、設定ファイルみたいな軽さだ。構造を書くだけなら、これで十分なんだろう。
そのままスクロールしていたら、リストの隅に、明らかに毛色の違う一行を見つけた。
- 星破壊（デス・スター）：習得ポイント200万 / 消費魔力860兆5000億 / 構造：超複雑ノードグラフ（ノード数、目算で数千）
「……は？」
思わず手を止めた。ノードを開いてみる。展開された構造図は、画面いっぱいに広がる配線の塊だった。ノードからノードへ、矢印が無数に絡み合っている。
「いや、ノードなんすけど。これ、めちゃ効率悪くないすか？」
ひとつひとつ辿ってみる。同じ計算を、別のノードで二回やっている箇所がある。エネルギーを変換してから戻して、また変換し直している箇所もある。経由地が多すぎて、最終的な出力に対して、無駄に魔力を食っている構造だ。
「……これ、俺がリファクタしたら、たぶん7割でいけるな」
技術者として、見過ごせる図ではなかった。
「860兆5000億かけて星一個か。それ、正味の仕事量で言ったら、もったいなさすぎるって…つかこれ使えるやついるのか？」
……いや、待て。リファクタして7割に削ったところで、それでも専用ノードはエネルギー変換を直接やる時点で、結局高い側のレイヤーに乗っている。
そう思い、デス・スター級は、放っておくことにした。
ひとまず、俺は元の一覧へ戻った。火、水、風、土、光、闇。あらゆる魔法の内部構造が、ソースコードのように展開されていく。
「で、これが……低レベル層？」
さらに深く潜ると、もっと素朴な関数群が現れた。うなる。設計思想、しっかりしてる。
物質生成関数：引数（陽子, 電荷, 中性子, 量）→ 指定物質を生成
- 位置制御関数：引数（対象, 座標）→ 対象を移動
- 運動制御関数：引数（対象, 速度ベクトル）→ 対象に運動を与える
- エネルギー変換関数：引数（種類, 量）→ 指定エネルギーを発生
開いてみるか…
「……お、急に重くなった。ソース見たらほぼC#…いやRustじゃねえかこれ！型もメモリもガチガチに固めてやがる…」
なるほどな、と思った。設定はTypeScriptで気軽に書けても、実行ロジック――物理現象そのものを起こす部分は、軽い言語じゃ書けない。当たり前だ。実際に世界を動かす層なんだから、安全性とパフォーマンスを天秤にかけたら、こうなるのだろう。
そうして、コードを見ていると、気付いた。
「……いや、このコード、`Arc`使ってなくね？ あ、でも――」
俺は思い出した。このコードを書いたのが誰かを。
「……まぁ、あの神様だしな」
納得した。それ以上追及しないことにした。だってあの神様だし。
コピペで書いて単に消し忘れたのだろう――普通にあり得る。いや、むしろ**それしかねぇ**までがあの女神だ。
さらにスクロールすると、一番底に、ぽつんとテキストファイルが一枚あった。
「……は。最下層、MIT宣言あって草。律儀かよ」
著作権表示と、無保証の一文。誰でも一度は見たことのある、あの定型文だ。
「神様、世界作るのにオープンソースの精神まで踏襲してたのか……多分無保証書きたくってBSDじゃなくMITにしたんだろうなぁ…」
---
「……お。なんだこの価格設定」
各関数の消費魔力に目を留めて、俺は眉をひそめた。
物質生成関数――異常に安い。元素をひとつ組み上げるのに、魔力がほとんど要らない。捨て値だ。一方で、エネルギー変換関数――発熱や圧力を直接起こすやつは、桁が二つ三つ違う。バカ高い。
「……これ、設計ミスってないか？ 物質を作るのがタダ同然で、熱を出すのが高い、って」
道理で、火球の消費魔力が高いわけだ。あれは[熱エネルギー]だの[圧縮]コンポーネントを直接呼んでる。この世界の魔法使いは、火を出すたびに、その高い熱を律儀に"買って"いるのだ。
だったら、答えはひとつしかない。
物質生成、マジ強えだろ。専用ノードを最適化する手間をかけるより、安いレイヤーだけ積み重ねて同じ結果を出す方が、結局いつも勝つ。
そして、もう一つ。設計をみて、思いついたことがあった。あったが、それはまだ、試さないことに決めた。
「さて…熱が欲しいなら、熱を買うな。熱を"出す物質"を作って、あとは物理と化学にタダ働きさせろ、ってね」
燃えるもの、爆ぜるもの、崩壊するものを、捨て値で生成する。エネルギーの発生そのものは、物理法則が無料でやってくれる。魔力コストは、物質を作る分だけ。
それは、火薬の発想であり――そして、核の発想である。
「……これだ」
ウケる。アクア・クリエイトは、つまるところ『物質生成関数』に水素と酸素を渡してるだけのラッパー関数にすぎない。笑えるのが、標準模型レベルで素粒子から組む、なんてとんでも物理をやってるのに元素召喚が超低コスト。しかも陽子と中性子の数を別々に指定できるから、中性子の数を変えるだけで、同位体まで作り分けられる仕様だ。
「ならっ、と…まずは基本から。水素原子、生成。酸素、生成。……結合」
ぽつん、と手のひらに水滴が生まれた。アクア・クリエイトを、関数の直叩きで再現した。同じ結果。だが俺は、それを素粒子レベルで組み上げた。つまり――**引数さえ変えれば、水以外の何でも作れる。**
俺の指が、中性子の数を渡す引数の上で止まる。
「……陽子はそのまま、中性子の数だけ動かせば、同位体は好きに選べるのか。じゃあ、たとえば陽子の数を二桁の後半まで上げて……核分裂する側の重い元素を、純度100％で出せる、と」
技術者の悪い癖だった。「指定できる」と書いてある引数を、試さずにいられる人種ではなかった。
そして、もうひとつ気づく。低レベル層の『位置制御関数』に『加速度制御関数』。座標へ向けて対象を動かす。これを中心に向けて一斉に呼べば――それは、爆縮だ。ものを内向きに一斉に押し込む。言葉の意味そのまんま。専用の魔法なんていらない。「動かす関数」を内向きに揃えて呼ぶだけ。
重い元素を、純度100％で。中心へ、一斉に。
前世で散々読んだ、地球の暗黒史の知識が、最悪の形で一本の線を結ぶ。
ただし、移動や加速の制御はそれなりにコストが高い。”このまま”では求めるレベルは到底できそうにない。
なるほど…ね。でも、圧縮を魔力で直接やるのが高いだけで、圧縮させること自体は別に魔力でやらなくていいんだよな。物質生成はタダなんだから、爆ぜる原素を呼んで、圧縮そのものを物理に外注すればいい。
硝酸アンモニウムなら、組成は水素・窒素・酸素三つ。どれも、空気中にいくらでも転がってる元素だ。わざわざ生成関数で呼ぶ必要もない。
「空気中の窒素と酸素を捕まえて、あとは水素も…と。結合」
水素と酸素を結合させて水を作ったのと、手順は何も変わらない。引数を変えて、組む元素を変えただけ。手のひらの上に、白い結晶がさらさらと積もっていく。硝酸アンモニウムだ。教科書に載っている、ごく普通の化学式どおりに。
「なるほどなるほど……」
思わず笑みが浮かぶ。
「テラー・ウラム型って、二段構成だったっけ。たしか。一段目で二層点火して、その圧力で二段目着火。Wikiでみた気がするやつ。まぁレンズは試行錯誤すりゃ作れるっしょ」
中身がどう繋がるかは、物理が勝手にやってくれる。俺はただ、正しい順番で正しい引数を渡すだけ。設計図なんていらない。APIには仕様書がついている。
「……このAPI、入力バリデーション、ちゃんとしてんのかな？」
それは、世界に対して投げかけてはいけない問いだった。
---
この話と、2.5話で最も重要なのは、「物質生成がタダで、エネルギー変換がバカ高い」 という価格設定の歪みに健一が気づく瞬間である。
これは現実の技術開発でもよくある話だ。
「高いエネルギーを直接使う」より「低コストな材料で代替する」方が効率的。石油を燃やすのも、結局は「化学エネルギーを熱に変換している」に過ぎない。
健一はこの「当たり前」を、異世界の魔法に適用しただけだ。だが、その「当たり前」が、次回、最悪の形で結実する。
そして彼は最後にこう呟く——「このAPI、入力バリデーション、ちゃんとしてんのかな？」
これは、すべてのエンジニアが一度は抱いたことのある、最も悪質な疑問である。
——作者