9/10

第9話「守る線を決める」

　一晩かけて、世界を分解した。

　といっても、物理的に何かを壊したわけじゃない。ダッシュボードの上で、世界が持つあらゆる機能を一覧にして、並べて、眺めた。それだけだ。

　リストは長かった。

　ステータス表示、スキル発動、経験値計算、レベルアップのバッチ処理、ダンジョン生成と管理、天候制御、農作物の生育記録、交易路の接続状態、魔物の行動制御、住人の基礎的な生命維持——そして、勇者の戦闘支援。

　全部で、百を超える項目が並んだ。

「ノード、これ全部が同時に落ちたことはあるか」

「えーと……全部は、ないと思います。同時に複数が止まったことは……」　少し間があった。「えーと、悠真さんが来た最初の日は、かなり多かった気がします」

「そうだな」

　俺は来た初日を思い出した。複数の問題が重なっていた。それでも世界は動き続けていた——何もかもが落ちたわけじゃなかった。重要な機能から順に優先されていたからだ。設計段階からそうなっていたか、あるいは俺が本能的にそうしていたか。

　ノードは言っていた。前任も、同じ結論に達していた、と。

　でも「本能的に」では、いつか間違える。だから今日は、明示的に決める。

「ノード、各機能が落ちたとき、何人の住人に影響が出るか、さっき頼んだデータはどうだ」

「えーと……スキル発動に関しては、全住人に関係します。数億規模です。レベルアップのバッチは……影響が出るまで時間差があるので、緊急度はやや低いです。ダンジョン生成は……」

「影響範囲と、影響が出るまでの速さ——両方で整理したい」

「……試みます」

　ノードが作業を始めた。俺は自分でも追加の分析をしながら、頭の中で機能を三つのグループに分け始めた。

　前の世界で俺がいたチームには、こういうときのための基準があった。どの機能をどれだけ高い精度で守るか——目標値を明示的に決める。完璧じゃなくていい。「この機能は一週間のうち何時間まで止まっていても許容できるか」を決める。それが決まれば、優先度がはっきりする。

　優先度が決まれば、リソースをどこに集中するかが決まる。

　そのことを、前の世界では「信頼性の目標値」と呼んでいた。

　　　　　　　　　　＊　＊　＊

　三時間ほどかけて、最初の整理ができた。

　グループは三つ。

　一番目——絶対に止められないもの。住民の生命維持に直結する基礎機能。呼吸、水の循環、地面の安定性。これらが落ちれば、地上の住人が直接死ぬ。戦闘中のスキル発動も同じ扱いだ——止まれば、戦っている者がその場で死ぬ。止まる前提で設計できない。

　二番目——できる限り止めたくないもの。非戦闘時のスキル使用、経験値計算、ダンジョン管理。止まると住人の日常が大きく乱れるが、一時的なら許容できる。ただし数時間を超えると、連鎖的な影響が出始める。

　三番目——一定の停止を許容できるもの。農作物の成長ログ更新、交易記録の整合性確認など。一日程度止まっても、致命的にはならない。

「……ノード、ちょっといいか」

「はい」

「勇者の戦闘支援。これはどのグループだと思う」

　ノードが少し止まった。

「えーと……わたしの感覚では、二番目だと思っていたんですが……」

「俺も最初そう思った」

「……違うんですか？」

　俺はリストの上の方を指した。

「勇者のスキルと耐久性は、直接、魔王戦に繋がっている。魔王が強くなれば、勇者が倒されるかもしれない。勇者が倒されれば——今の体制では、世界の危機レベルが跳ね上がる。それは連鎖的に全ての機能に影響する」

「……なるほど」

「勇者支援が落ちたとき、最初に死ぬのは勇者だけかもしれない。でも、世界全体への影響という意味では——一番目と同等か、それ以上の重みがある」

　俺はリストを見直した。

　勇者の戦闘支援を、一番目のグループの最上位に移す。

　これは感情的な判断じゃない。データを見れば分かる。勇者が活動しているとき、スキル発動の記録が全世界の安定指標と相関している。勇者が順調であれば、世界全体の負荷は安定傾向を示す。勇者の活動が止まると、急に各地で軽微なアラートが増え始める。

　前の世界でいえば、一番重要なサービスに設定される特別な保証——絶対に落とさない、と明言するためのレベル分け——それに当たるものだ。

　前の世界ではそれを、SLAと呼んでいた。

　守れなければ、他の全てが連鎖的に崩れる。だから、特別に扱う。

「わかりました」　ノードが静かに言った。「勇者さんが、世界でいちばん守られるべき……」

「守られるべき、というより、守る必要がある、だな」　俺は少し言い直した。「感情の話じゃない。構造の話だ」

「……構造、ですか」

　　　　　　　　　　＊　＊　＊

　昼前に、セレスが来た。

「悠真くん、また作業してるの？」　空色の髪を揺らしながら、ウィンドウを覗き込んだ。「あら、今日もお天気がいいわねぇ——って、ここは管理層だから関係ないんだったわね」

「昨日も来てましたよね」

「ええ。でも今日は別件よ」　セレスは少し表情を変えた。「昨日の話の続きもあって。あなたが「守る線を決める」って言っていたでしょ。だから、少し情報を持ってきたの」

「聞きます」

　セレスがウィンドウの端に触れた。新しいデータが浮かんだ。

「わたしは天候の担当だから、全域の状態を広く見られるの。で、昨日からずっと気になっていたんだけど——」　セレスが少し間を置いた。「場所によって、劣化の速さが全然違うのよ」

「どういうことですか」

「早く落ちている場所と、ゆっくりな場所がある。早い場所には、共通点があるみたい」

　俺はデータを開いた。

　セレスが指差した先には、劣化速度のグラフがあった。全域を地図に重ねると、濃い色になっている場所が見えた。一か所だけ特に濃い。

「あそこは」

「魔王の城がある方角ね」　セレスは穏やかに言った。「あの周辺の機能は、他の地域より三倍くらい早く劣化している。原因は……わたしにはわからないけど、ずっとそう」

　俺は少し考えた。

　魔王の城の周辺。そこで何かが、世界の基盤を早く消耗させている——

　今は仮説の段階だ。でも、データが示している以上は無視できない。

「他には」

「全体の傾向として、北の山脈地帯が比較的安定しているわ。あと、ダンジさんが担当しているダンジョン群も、ここ最近は落ち着いている。あなたが直したからだと思うけど」

「ダンジが頑張った部分も大きいです」

「そうね」　セレスが少し笑った。「あの方、意地っ張りだけど真面目よ。ちゃんと見ているわ、わたし」

　俺はデータをメモに書き加えた。

「一つ聞いていいですか」

「どうぞ」

「セレスさんは——天候の担当として、今後何があっても安定していますか」

　セレスが少し目を丸くした。それから、静かに頷いた。

「わたしは大丈夫よ。天候の制御は、基盤の中でも一番シンプルな設計だから。前任の方も、ここだけは丁寧に作ってくださっていたみたい」

「良かった」

「あら、心配してくれてたの？」

「データとして、安定しているプロセスがあると分かると助かります」

「……ふふ」　セレスが少し笑った。「素直じゃないわねぇ」

　俺は特に何も言わなかった。

　　　　　　　　　　＊　＊　＊

　セレスが帰ってから、カルクが来た。

　急ぎ足、というか、バタバタした気配だった。

「失礼します！」　細身の青年が、数式の浮かんだベストを揺らしながら飛び込んできた。「悠真さん、聞いてください、計算が——計算が合わないんです！　0.003ズレてるんです！」

「落ち着け。何が」

「勇者さんの経験値です！」　カルクが手に持ったそろばん状のものをガチャガチャと弾いた。「バッチ処理の結果と、リアルタイムの仮計算の値が、ずっと0.003ポイントずれていて、僕は……正しい数字を出したいのに……」

「0.003は誤差範囲じゃないのか」

「違います！　0.003は許容できません！　設計上の誤差は0.001未満のはずで、0.003はもう……三倍なんです……三倍……」

　俺はため息をついた。カルクはこういう男だ。でも、問題意識は正しい。

「ちょっと待て。実際に何が起きてる」

「えーと……」　カルクが深呼吸した。「勇者さんが魔物を倒したとき、その場で表示されるステータスの経験値と、翌朝のバッチで確定する経験値が、微妙にずれています。今まではもっと小さいズレだったんですが、最近大きくなってきていて……」

「最近、というのはどのくらい前から」

「……一週間くらい前から少し大きくなって、昨日今日でまた少し広がっている、という感じです」

　俺は少し考えた。

　リアルタイムの仮計算と、深夜のバッチで永続化される値——この二段階の処理は世界の設計上、もともと存在するものだ。多少のズレは想定の範囲内で作られているはずだが、それが広がっているとすれば、どこかに問題がある。

「バッチの処理時間は伸びているか」

「……そういえば」　カルクが目を見開いた。「昨日、いつもより30秒くらい遅かったです。でも完了はしているので、問題ないと思っていたんですが——」

「処理時間が伸びると、仮計算との差分期間が長くなる。その間に住人が追加で経験値を積むと、ズレが生まれやすくなる」

「……！」　カルクが固まった。「そういうことか……計算の問題じゃなくて、タイミングの問題……」

「計算は合ってる。タイミングが少しずれ始めている」

「……それなら……」　カルクが急に静かになって、何かを計算し始めた。数式が体の周囲に浮かんだ。「処理の分割を……もう少し細かくすれば……」

「今すぐ触るな」

「えっ」

「さっき守る優先度を整理した。バッチの根本修正は、今の段階では慎重にやる。まず状況を把握してから」

「でも0.003が……」

「誤差が広がっているペースはわかるか」

「……一日で約0.0005ずつ広がっています」

「なら、緊急ではない。ただし見ておく必要はある。カルク、今日から毎日、その数字を報告してくれ。広がるペースが変わったら教えてほしい」

「……わかりました」　カルクが渋々頷いた。「0.003が0.01になったら、絶対に直してください」

「その前に手を打つ」

「……約束ですよ」

　カルクが帰っていった。その背中に数式が揺れていた。

　俺はメモに追記した。——勇者の経験値ズレ、バッチ処理時間の微増。監視継続。深層の未分類ログ確認は後回し。

　　　　　　　　　　＊　＊　＊

　夕方、俺は改めてリストを眺めた。

　一番目のグループの最上位——勇者の戦闘支援。それだけは今日決まった。

　守ると決めた線にリソースを集中する。線を守り続けられている間は、余裕のある部分に手を入れて根本を直しに行く。

　線を決めることで、どこに全力を出さないかが決まる。それは、諦めではない。

「ノード」

「はい」

「勇者の戦闘支援に関する全データを、今後リアルタイムで監視する専用のウィンドウを用意したい」

「……えーと、可能だと思いますが……データを引っ張れるかどうか、やってみます」

「頼む。スキル発動数、ヒット率、魔王戦時のレスポンス速度——それと、今カルクが言っていた経験値バッチの処理時間も入れてくれ」

「わかりました」

　ノードが動き始めた。

　ダッシュボードの一角に、新しいウィンドウが生まれ始めた。勇者専用の監視窓。そこに数字が流れ始める。

　俺はその数字を見ながら、地上のことを考えた。

　今この瞬間、アリアはどこかで剣を振っているかもしれない。魔物と戦っているかもしれない。仲間と野営しているかもしれない。そのどれも、ダッシュボードの数字でしか見えない。でも、数字の先で誰かが動いている。

　その誰かのために、守る線を決めた。

　完璧な保護はできない。でも、ここは絶対に守る——と決めた場所を守り続けることは、できる。

「ノード、ウィンドウの右上、アラート閾値を設定してくれ」

「えーと……どのくらいで鳴らしますか？」

「スキル発動数が通常の七割を下回ったとき。レスポンス速度が二倍を超えたとき。バッチ処理時間が五分を超えたとき」

「……わかりました」

　数字が設定された。

　ウィンドウに、静かな緑の色が灯った。今のところ、正常だ。

　俺はそれを眺めながら、一行だけメモに書き加えた。

　——今日から、守る線が決まった。

お読みいただきありがとうございます。

【今回のIT用語】

SLO（Service Level Objective）：「信頼性の目標値」のことです。「この機能は一週間のうち何時間まで停止を許容するか」「レスポンスは何秒以内に返すか」といった具体的な目標値を設定します。全てのサービスを完璧に守ることはできないため、何をどこまで守るかを明示的に決めることで、リソースと優先度を合理的に配分できます。悠真が世界の機能を三つのグループに分けて整理したのがこの考え方です。なお、SLOと組み合わせて使う「許容できる停止の余裕（エラーバジェット）」については前話で解説しています。

SLA（Service Level Agreement）：SLOよりもさらに重い「約束」の水準で、「ここだけは絶対に守る」と明言するための基準です。悠真が勇者の戦闘支援を最優先グループの最上位に置いたのは、その機能が世界全体の連鎖に直結するためです——まさにこの「絶対に守る」レベルに相当すると判断しました。

次話「わざと壊してみる」もよろしくお願いします。

感想・ブックマークいただけると励みになります。