最適化はいつも正しいのか: 変更を戻される世界で学ぶ、運用の本当の難しさ

その一瞬の得は、なぜ後で高くつくのか

株価は1日のうちでも刻々と変わる。だからこそ、成行で買えば高値をつかみ、指値で待てばわずかな差で逃すことがある。目の前の一回だけを見れば、どちらも「損したように見える」。しかし、もっと大きな視点で見ると、問題は約定価格そのものではない。いつ、どのルールで、どの不確実性を引き受けるかが本質になる。

この感覚は、クラウド運用にもそのまま現れる。システムの一部を手早く直したい、特定の設定だけを一時的に変えたい、障害を切り抜けるためにコンソールから少しだけ触りたい。現場ではごく自然な判断に見える。だが、その小さな変更は後から「なかったこと」にされるかもしれない。便利さと正確さ、局所最適と全体整合、スピードと再現性。その綱引きが、実は同じ構造をしている。

問題は「今いちばん得に見える操作」ではない。問題は、その操作が将来の自分にどれだけの不確実性を残すかだ。

価格と状態は、どちらも「流れる」

株式市場では、価格は固定された数字ではない。注文を出した瞬間と約定した瞬間の間にも、世界は動いている。だから、成行注文は「確実に買える」代わりに「どの価格になるか分からない」。指値注文は「価格を守れる」代わりに「そもそも成立しない」ことがある。どちらも欠点ではなく、不確実性の置き場所が違うだけだ。

クラウドのリソース状態も同じで、いったんデプロイした後のシステムは静止画ではない。設定、依存関係、周辺の自動化、手作業の修正、緊急対応の痕跡まで含めて、現実の状態は流れ続ける。ところが、Infrastructure as Code はその流れを「宣言された望ましい状態」に引き戻そうとする。ここで起きるのがドリフトだ。テンプレートが語る姿と、現場の実際がズレる。

このズレは、単なるミスではない。むしろ、運用の現場が抱える二つの合理性の衝突である。ひとつは「いま動いているものを守りたい」という合理性。もうひとつは「将来も同じ手順で再現したい」という合理性だ。前者は局所の安全を、後者は全体の秩序を優先する。どちらも正しい。だからこそ難しい。

たとえば、あるサービスでタスク定義のCPUを一時的に上げて負荷をしのいだとする。目先の障害は収まるかもしれない。しかし、その変更をテンプレートに反映しないまま別の更新をかけると、後で「なぜか元に戻った」という事態が起こる。ここで失われるのは、変更そのものよりも、変更に対する信頼だ。

成行注文と手修正が似ている理由

成行注文は、速さと確実性を買う手段だ。価格の制御を手放す代わりに、約定の確実性を得る。緊急時には合理的だし、流動性が十分な場面では非常に便利でもある。問題は、成行が「その場しのぎの最終手段」ではなく、いつのまにか「いつも使う基本手段」になったときに生じる。価格への感度が鈍り、意図しない高値買い、安値売りが積み上がる。

クラウドでのコンソール直修正も、これに似ている。障害対応中には、テンプレートを更新して再デプロイするより、管理画面から1項目だけ直すほうが速いことがある。だが、その速さは、変更の履歴と意図をシステム外に逃がすことで得られている。将来、別の変更が入ったとき、その外に逃がした差分は見えなくなる。結果として、更新時に上書きされるか、削除時に失敗するか、あるいは誰にも説明できない挙動を残す。

この構図を理解するために、次の比喩が役に立つ。テンプレートは「設計図」ではなく、契約書に近い。契約書にない口約束が増えると、現実は回るが解釈コストが跳ね上がる。約定価格を妥協した成行注文と同じで、当面の実行は得られても、後で誰がどの条件を引き受けたのかが曖昧になる。

逆に指値注文は、価格の上限や下限を明示する。クラウドでも、手作業を減らし、テンプレートに変更を戻すことは、「今の都合」より「将来の解釈可能性」を優先する行為だ。ここで守っているのは単なる美学ではない。変更の意味を、システムの外側ではなく、システムの記録として残すことだ。

本当に守るべきものは、現在の値ではなく再現性である

多くの人は、運用の目的を「いまの値を正しく保つこと」だと考える。たしかに値は重要だ。CPU、メモリ、インスタンスタイプ、価格、設定値。だが、より深い目的は、値そのものではなく、望ましい状態に戻れることにある。

ここで重要なのは、状態管理には2つの層があるという点だ。ひとつは、目の前のシステムが今どう動いているかという実行状態。もうひとつは、その状態がなぜそうなっているかを説明できる表現状態だ。実行状態だけを見ていると、変更は「うまくいった」ように見える。だが表現状態が追随していないと、次の更新でその変更は消えるかもしれない。

このズレは、マーケットでいえば「いま見えている板」と「実際に約定する価格」の差に近い。表示価格を信じすぎると、取引結果に驚く。表示されている状態を信じすぎると、クラウド更新時に驚く。どちらも、表面の見た目と実際の挙動が一致しないことから生まれる失敗だ。

再現性とは、過去を保存することではない。未来の変更に耐える形で、現在を説明できることだ。

この視点に立つと、ドリフトは単なる「悪」ではなく、アラートとして読める。テンプレート外の変更は、現場が何らかの圧力に反応した痕跡でもある。つまり、ドリフトは「守られるべきもの」と「壊されるべきもの」が現場で衝突した証拠だ。問題は、衝突が起きたことではない。衝突の記録が残らないことだ。

変更を最小化するのではなく、変更の意味を最大化する

ここで、少し見方を変えたい。多くのチームは「手作業を減らそう」「変更を自動化しよう」と考える。もちろん正しい。しかし、それだけでは足りない。目指すべきは単なる自動化ではなく、変更の意味が一箇所に集約されることだ。

たとえば、注文戦略を考えるトレーダーは、成行か指値かを選ぶだけではない。いつ、どの銘柄に、どの板の厚さで、どれだけのスリッページを許容するかを考える。つまり、注文方法はテクニックではなく、リスクをどこに置くかの宣言である。クラウド運用も同様で、コンソール直修正を禁止するのは潔癖症ではない。変更の責任を、散らばった作業ではなく、テンプレートとレビューと履歴に集めるためだ。

実務では、次のように考えると整理しやすい。

1. 変更の影響範囲を見積もる。単発の修正か、将来の更新に影響する構造変更かを切り分ける。
2. 変更の出典を固定する。テンプレート、コード、パラメータ、手作業のどれが正本なのかを明確にする。
3. 例外を記録する。緊急対応で一時的に外したルールは、後で必ず戻す前提で記録する。
4. 更新時の上書きを前提に設計する。今の修正が次回の更新で消えるなら、それは「まだ設計に昇格していない変更」だとみなす。

この考え方は、株式注文にも応用できる。成行を使うべきか、指値を使うべきかは、単に「どっちが得か」ではない。約定の確実性を優先するのか、価格の制御を優先するのか、どのリスクを明示的に引き受けるかの選択だ。クラウドの更新も、速さと整合性のどちらを優先するかの選択である。

Key Takeaways

• 目先の成功と長期の整合性は別問題。一時的にうまく動く変更でも、将来の更新で壊れるなら運用コストは増えている。
• 手作業はしばしば「変更の意味」を失わせる。速く直せても、どこに責任があるかが曖昧になる。
• 成行と指値の違いは、クラウド変更にもそのまま当てはまる。何を確実にしたいのか、何を制御したいのかを先に決める。
• ドリフトは失敗の証拠であると同時に、現場の圧力の記録でもある。消すだけでなく、なぜ起きたかを読む。
• 正しさの基準を「今の値」から「再現可能な状態」へ移す。これが、運用を個人技から仕組みに変える第一歩。

変更を「許す」か「禁じる」かではなく、「どこに閉じ込めるか」

ここまで見てきたように、成行注文とコンソール直修正は、どちらも悪ではない。むしろ、緊急時には必要な手段だ。問題は、それらを例外ではなく常態にしてしまうことだ。例外が積み重なると、システムは静かに二重化する。表向きのルールと、実際の運用が別々に育ってしまう。

だから本当に問うべきは、「変更してよいか」ではない。変更の痕跡をどこに閉じ込めるかだ。市場では価格変動を受け入れつつ、注文ルールでリスクを閉じ込める。クラウドでは現場の必要を受け入れつつ、テンプレートと自動化で変更の痕跡を閉じ込める。どちらも、自由をなくす話ではない。自由が後で自分を裏切らないように、制約の形を設計する話だ。

最後に、少しだけ見方を反転させたい。私たちはしばしば、運用とは「問題が起きたときにどう直すか」だと考える。しかし本当は、運用とは直したあとに、その直し方を未来にどう残すかで決まる。約定価格も、設定値も、その瞬間だけの出来事ではない。次の瞬間に何が起こるかを決める、履歴つきの選択なのだ。