真実の置き場所がズレると、システムは静かに壊れる

Jun 18, 2026

1 min read

2 views

88%

まず問いを変える: 何が壊れるのかではなく、どこに真実があるのか

プロダクトやインフラが壊れる瞬間は、たいてい派手ではありません。エラーが出る前に、もっと静かな異変が起きています。設定は変わったのに、記録は変わっていない。人は新しい事実を知っているのに、システムは古い事実を信じ続けている。このズレこそが、あとで高くつく。

ここで本当に問うべきなのは、単なる「変更管理」ではありません。真実の置き場所をどこに決めるかです。クラウドの世界では、それをテンプレートに置くのか、稼働中の実体に置くのかで、システムの運命が変わります。人間がコードを書かずにプロダクトを作る世界でも同じです。どのドキュメントが正式な記録なのかが曖昧だと、チームはすぐに別々の現実を生き始めます。

システムが壊れるのは、変化したからではない。真実の所在が一つでなくなったからだ。

この視点で見ると、インフラ運用とドキュメント設計は別物ではありません。どちらも、唯一の参照点を守る仕事です。

ドリフトは技術的な問題ではなく、記憶の問題である

クラウド環境でよく起きる失敗は、リソースが手で少しだけ直されることから始まります。緊急対応で一時的に値を変える。確認のために設定をいじる。動いたのでそのままにする。すると、管理上の正しい状態と、実際に動いている状態が乖離していきます。これがいわゆるドリフトです。

ドリフトの厄介さは、ただの不一致ではなく、未来の変更を歪めることにあります。次にスタックを更新した瞬間、テンプレート外で行われた手作業の変更は消えます。つまり、現場の判断で得られた貴重な修正が、正式な真実として保存されていない限り、更新時に上書きされるのです。

これは、いわば「身体は覚えているが、台帳には残っていない」状態です。あなたのチームが何をやったかを人の記憶に頼ると、再現性は一気に落ちます。夜中に誰かが頑張って直した事実は、翌朝には消えたことになりうる。そこで起きているのは単なる運用ミスではなく、記録システムの敗北です。

この問題はクラウドに限りません。たとえば営業資料の最新版がSlackの断片に散らばっていると、誰も正しい価格を説明できなくなる。仕様変更が口頭だけで共有されると、実装は過去を前提に進んでしまう。真実が複数の場所に分裂した瞬間、組織はゆっくりと自壊します。

人間がコードを書かないなら、代わりに何を書くべきか

コードを書かない開発という発想は、しばしば「人間は何もしなくてよい」という意味に誤解されます。実際には逆です。人間の役割は消えるのではなく、実装ではなく記録の設計に移るのです。

ここで重要なのが、AGENTS.mdを目次にし、docs/を正式な記録システムにするという考え方です。これは単なるファイル整理ではありません。プロジェクトの知識を、会話の流れから切り離して、構造化された単一の参照源に変える操作です。

たとえば、新しいメンバーが参加したとします。もし情報がチャットログと個人メモに散っていれば、彼らは「誰に聞けばいいのか」を学ぶところから始めなければならない。だが、AGENTS.mdが目次として機能し、docs/が正式な記録であれば、彼らはすぐに「どこを見れば真実にたどり着けるか」を理解できます。

これはCloudFormationの原則と驚くほど似ています。スタックの外で勝手にリソースを変えると、後で更新や削除が壊れる。ドキュメントの外で勝手に仕様を変えると、後で実装や意思決定が壊れる。どちらも本質は同じです。正式系の外で起きた変更は、やがて消えるか、壊れるか、混乱を残す。

ルールを増やすことより大事なのは、正式な記録の外で何も起きないようにすること。

この視点を持つと、AIを使った開発の評価軸も変わります。どれだけ速く作れるかではなく、どれだけ真実の整合性を保ちながら作れるかが重要になるのです。

一番危険なのは、速さではなく、見えない二重帳簿

多くのチームは、手作業の変更や口頭の合意を「柔軟性」と呼びます。確かに、短期的には便利です。急ぎの修正をすぐに入れられるし、厳密な手続きを通さなくても前に進めるからです。しかし、その便利さはしばしば、二重帳簿を生みます。

一つは、現実の帳簿です。実際に動いている設定、いまの挙動、現場で対応した事実。もう一つは、正式な帳簿です。テンプレート、ドキュメント、仕様書、運用手順。二つが一致している間は問題が見えませんが、いったんズレると、次の変更で必ず噴き出します。

この構造は、金融会計よりも厄介です。なぜなら、数字の不一致ならすぐ気づけるのに対して、ソフトウェアや知識の不一致は、動いているように見える間は隠れ続けるからです。しかも、AIや自動化はその隠れたズレを一層見えにくくします。生成された文面はそれらしく見えますし、自動デプロイは静かに失敗します。だからこそ、「動いた」ことと「正しい」ことを分けて考える必要があります。

具体例を挙げましょう。あるサービスで本番障害が起き、緊急対応として手動でタイムアウト値を上げたとします。その場では復旧しますが、テンプレートを更新しなければ次の再デプロイで元に戻ります。別の例では、仕様変更がチャットで合意されただけで、docs/に正式化されないまま実装が進みます。後から別の人が見たとき、その変更は存在しなかったことになり、同じ議論を繰り返すことになります。

どちらも表面上は別問題に見えます。ですが根っこは同じです。記録されていない変更は、未来にとって存在しない。この厳しさを受け入れない限り、システムはいつか必ず自分の影に足を取られます。

では、どう設計すればよいのか: 正式系を一つにする

ここから得られる実践的な結論はシンプルです。組織には、変化が起きる場所ではなく、真実が確定する場所を一つ決める必要があります。クラウドならテンプレートや宣言的定義。知識管理ならdocs。運用ルールならそこに集約された手順書。重要なのは、そこで定義された内容だけが「正式」であると全員が理解していることです。

この設計を、私は正式系の単一化と呼びたいです。単一化とは、何でも一つにまとめることではありません。むしろ逆で、役割を分けることです。

入力の場: 人がアイデアや変更を出す場所
審議の場: 変更を検討し、判断する場所
正式化の場: 最終的に真実として固定される場所
実行の場: その真実に従ってシステムが動く場所

この分離ができていないと、チャットが仕様書になり、メモが運用基盤になり、手作業が履歴になります。結果として、誰も全体を追えなくなる。

逆に、正式化の場を明確にしておくと、変更はむしろ速くなります。なぜなら、皆が「どこを更新すればよいか」を知っているからです。変更のたびに、関連ドキュメントと宣言的定義を更新する習慣があれば、システムは遅くなるどころか、予測可能になります。予測可能性こそ、長期的な速度です。

ここで大切なのは、手作業を悪と見なすことではないという点です。緊急対応や探索的作業は必要です。ただし、それはあくまで暫定的な介入であり、最終的には正式系に反映されなければならない。そうでなければ、現実が先に進み、記録が追いつけなくなります。

Key Takeaways

真実の置き場所を決める すべての重要な変更について、「どこが正式な記録か」を明確にする。クラウドなら宣言的定義、知識ならdocs、運用なら手順書。
暫定対応を正式化する習慣を持つ 緊急時の手動修正やチャット上の合意は、必ず後で正式系に反映する。反映されない変更は、次の更新で消える可能性が高い。
AGENTS.mdは入口、docs/は本体にする 入口は案内、正式な記録は別に置く。目次と台帳を分けることで、新規参加者も既存メンバーも迷わなくなる。
「動く」より「再現できる」を重視する 目の前で動いた修正は価値があるが、それだけでは不十分。再デプロイ、再実行、再現時に同じ結果になることが重要。
二重帳簿を疑う 現実と記録が食い違っていないかを定期的に確認する。ズレは小さいうちに見つけた方が、修正コストが圧倒的に低い。

結論: 管理すべきは変更ではなく、記録の一貫性である

私たちはしばしば、システム運用を「いかに早く変えるか」の問題として捉えます。しかし本当に難しいのは、変化そのものではなく、変化した世界を一貫した形で記憶し続けることです。

クラウドのドリフトも、AI時代のドキュメント整備も、突き詰めれば同じ問いに行き着きます。現実は常に変わる。だからこそ、変化を受け止める正式な記録の骨格が必要だ。骨格が弱いと、どれだけ賢い自動化を入れても、どれだけ優秀な人が頑張っても、システムは静かにズレていきます。

優れたチームは、変化をなくすのではない。変化が起きても真実が分裂しないように設計する。

この発想に立つと、インフラもドキュメントも、単なる補助輪ではなくなります。どちらも、組織が現実と一致し続けるための記憶装置です。未来の失敗を減らしたいなら、まず変更を止めるのではなく、真実がどこに保存されるのかを見直すべきです。そこが定まったとき、初めてシステムは速く、強く、そして壊れにくくなります。