Terraform や GitOps は、インフラ運用を安定させるための強力な仕組みです。
構成はコードで管理され、変更は履歴として残り、人手による作業は最小化されます。少なくとも設計上は、「何が起きたか」は追える状態になります。
ただ、現場で話を聞いていると、仕組みが整ったあとに「安心できない」という声が残ることがあります。トラブルが起きているわけではないのに、どこか落ち着かない。
この記事では、コード化と自動化が進んだにもかかわらず、なぜ不安が消えないのかを、Terraform × GitOps の構造から観測します。
コード化したのに、なぜ不安が消えないのか
「整った」という手応えと、どこか噛み合わない感覚
Terraform や GitOps を導入すると、インフラ運用の輪郭ははっきりしてきます。構成はコードで管理され、変更は差分として確認でき、反映の経路も整理される。以前のように、手順書の更新漏れや、人の記憶に頼った作業に不安を覚える場面は、確実に減っていきます。
多くの現場で、「昔と比べれば、かなり安心できるようになった」という実感が生まれるのも自然なことです。少なくとも、何が起きているのか分からないまま作業が進む、という状態からは離れています。
ただ、その一方で、仕組みが整ったあとに別の種類の違和感が残ることがあります。設計は破綻していない。レビューも通っている。過去に似た変更も問題なく進んできた。それでも、変更を前にしたときに、どこか気持ちが落ち着かない。
この「任せきれない」感覚は、明確なトラブルや失敗が原因ではありません。むしろ、平常運転が続いている状況で、ふと顔を出します。
変更前の一瞬に表れる、言語化されない引っかかり
たとえば、Terraform の plan を確認し、PR のレビューも終わり、技術的な論点は出尽くした状態。あとは apply するだけ、という場面です。
表面的には、これまでと同じ流れです。差分は理解できているし、構成も想定内。それでも、その直前に、誰かが少し考え込むような間が生まれることがあります。
「問題はないと思います」と言葉にはする。ただ、その言葉が、いつもより慎重になる。その理由をその場で説明できるわけではないけれど、過去の運用や、似た構成で起きた小さなトラブルが、断片的に頭をよぎっている。
結局、その変更は通ることが多く、実際に何も起きないことも多い。それでも、その一瞬の間だけが、記憶に残る。
この引っかかりは、コードが読めていないから生まれるものではありません。むしろ、コードが読めるからこそ、「この変更が運用に入ったあと」を自然に考えてしまう結果として現れます。
不安は、理解不足ではなく「考えすぎ」から生まれる
コード化や自動化が進むと、「分からないから怖い」という種類の不安は確実に減っていきます。plan を見れば変更内容は把握でき、影響範囲もある程度は想像できる。ブラックボックスだった作業が、言葉にできる形へと変わっていく。
それでも不安が消えないとしたら、それは理解が足りないからではありません。むしろ、分かってしまうからこそ、その先まで考えてしまう。
この変更が本番に入ったあと、運用はどう変わるのか。負荷が増えたとき、想定外の組み合わせが起きたとき、誰がどこまでを引き受けるのか。そうした問いが頭に浮かぶようになると、単に「コードが正しいかどうか」だけでは判断できなくなっていきます。
コード化したのに安心できない、という感覚は、仕組みが未熟だからではありません。仕組みの外側にある判断や責任の扱いが、まだ十分に整理されていないことへの、自然な反応なのかもしれません。
ここで起きているのは「慎重すぎる人の問題」ではなく、判断の前提が共有されないまま、考える責任だけが個人に残ってしまう構造です。
Terraform と GitOps が約束している「安心」とは何か
Terraform がもたらしたのは、「状態を説明できる」安心
Terraform が現場にもたらした変化は、とても実務的で、分かりやすいものでした。環境の構成がコードとして定義され、差分が事前に確認でき、意図した状態に収束させられる。
これにより、「今どうなっているのか分からない」「前回と何が違うのか説明できない」といった不安は大きく減っていきます。少なくとも、状態そのものについては、後から説明できるようになった。
ただし、Terraform が保証しているのは、あくまで「このコードを適用すれば、この状態になる」という点までです。その状態が今のシステムにとって本当に望ましいのか、どこまでを許容範囲と考えるのか、といった判断までは引き受けていません。
状態は揃う。でも、その状態をどう評価するかは、人の側に残されたままです。
GitOps が提供するのは、「変更経路が追える」という前提
GitOps もまた、約束している範囲は比較的はっきりしています。変更は Git に集約され、PR としてレビューされ、マージされた内容だけが反映される。誰が、いつ、どんな変更を行ったのかを後から追える。
この透明性は、属人化を防ぎ、運用を安定させるうえで大きな意味を持ちます。少なくとも、「誰が触ったのか分からない」という状態からは離れられる。
一方で、GitOps が保証しているのは、「正規のプロセスを通った変更である」という事実までです。その変更を今このタイミングで反映するべきかどうか、という判断自体は、やはりツールの外側に置かれています。
自動反映の前に、人が確認してしまう理由
GitOps の運用が定着してくると、変更の反映は驚くほど静かになります。PR がマージされ、特に操作をしなくても、環境は少しずつ更新されていく。
それでも、リリース前の定例ミーティングや、Slack のスレッドで、「これ、今日入って大丈夫でしたっけ」という一言が挟まれることがあります。
仕組みとしては問題ない。PR も通っている。それでも確認が入るのは、ツールが保証していない部分を、人が無意識に補おうとしているからです。
ツールが担保しているのは、「判断できる土台」まで
Terraform も GitOps も、信頼性を高めるための重要な仕組みです。ただし、それらが直接的に提供しているのは、安心そのものではありません。
状態が見える。履歴が追える。変更の経路が整理されている。そうした「判断ができる前提条件」を整えているにすぎない。
その前提の上で、「通す」「止める」「様子を見る」といった判断を下すのは、常に人です。もし仕組みが整ったあとも不安が残るとしたら、それはツールの期待値と、人が引き受けている判断の範囲が、どこかでずれているからかもしれません。
コードで決まること／人が決め続けていること
コードが決めているのは、「どう変わるか」という結果
Terraform の plan や、GitOps の差分を見れば、変更内容そのものはかなり具体的に把握できます。どのリソースが増え、どこが書き換わり、最終的にどの状態へ収束するのか。少なくとも、変更の結果については曖昧さが減っています。
この点で、コード化は運用を確実に前に進めました。人の記憶や勘に頼っていた頃と比べれば、「何が起きるか分からない」という不安は明らかに小さくなっています。
ただし、コードが答えてくれるのは、あくまで「こう変わる」という結果までです。その変化が、今このタイミングで受け入れるべきものなのか、どこまでを許容範囲と考えるのか、といった意味づけまでは行ってくれません。
状態は決まる。しかし、その状態をどう評価するかは、最初からコードの外側に置かれています。
「いつ入れるか」「どこまで許すか」は、毎回人が決めている
現場で行われている判断の多くは、明文化されていません。
レビューを通すかどうか。今この変更を反映するかどうか。想定外の影響が出た場合、それを「許容範囲」と呼ぶのか、「止めるべきだった」と振り返るのか。
これらは、コードレビューのチェック項目としては書きにくく、その場にいる人たちの経験や感覚、直近の出来事を踏まえて決められます。
それ自体は、決して悪いことではありません。システムの状態や組織の状況を無視した判断は、そもそも現実的ではないからです。
ただ、その判断は記録として残りにくい。PR は残ります。差分も追えます。しかし、「なぜ今回は通したのか」「どこまでを想定内としていたのか」という背景は、時間とともに薄れていきます。
マージ直前に生まれる迷いは、判断が可視化されていない証拠
PR の差分も確認し、技術的な指摘も一通り出尽くした段階で、なぜかマージに踏み切れないことがあります。
新しい構成でもなく、明確なリスクも見当たらない。それでも、「今じゃなくてもいいかもしれない」「もう一度だけ様子を見たい」という感覚が残る。
この迷いは、コードの問題ではありません。むしろ、コードがきちんと読めているからこそ生まれます。その変更が運用に入ったあと、どんな説明が必要になるか、どこまでの責任を引き受けることになるかが、頭の中に浮かんでしまうからです。
判断は確かに行われている。ただ、その判断がどこで、誰によって行われたのかは、仕組みの中には残らない。そのズレが、判断を重く感じさせます。
仕組みが洗練されるほど、境界線は見えにくくなる
Terraform や GitOps によって、変更の実行そのものは驚くほど滑らかになります。apply は速くなり、マージ後の反映も静かに進む。
その一方で、「ここから先は人が決めている」という境界線は、以前より意識されなくなります。仕組みが多くを肩代わりしてくれる分、判断の存在そのものが見えにくくなる。
コード化しているのに安心できないと感じるとしたら、それは仕組みが足りないからではありません。判断がどこにあり、誰が引き受けているのかが、十分に共有されていないだけかもしれません。
「誰が決めたのか」が消えていく瞬間
Terraform には plan があり、GitOps には PR がある
Terraform の運用では、apply の前に必ず plan を確認します。どのリソースが変わり、どこに影響が出そうかは、差分としてかなり具体的に見える。
GitOps の世界では、その変更が Git の PR として提出され、レビューされ、マージされたものだけが本番に反映されます。誰かが手元で apply するのではなく、仕組みが静かに実行していく。
この二つが揃うと、「変更は十分にチェックされている」という感覚が生まれます。実際、以前の手作業中心の運用と比べれば、確認プロセスは圧倒的に丁寧です。
plan を見て、PR を読んで、問題なさそうだと判断する。その一連の流れ自体は、かなり健全に見えます。
それでも、「誰が決めたのか」はどこにも残らない
ただ、Terraform × GitOps の運用を続けていると、ある点に気づきます。
plan には「何が変わるか」は書かれていますが、「この変更を今入れると決めた理由」は書かれていない。PR にはレビューコメントは残りますが、「このリスクは許容する」と合意した瞬間は、どこにも明示されません。
Terraform は状態を示しますが、判断はしません。GitOps は変更経路を整えますが、決定者を指し示すことはありません。
結果として残るのは、「正規のプロセスを通った変更だった」という事実だけです。そのプロセスの中で、誰が、どの時点で、「今回は通す」と腹をくくったのかは、時間とともに見えなくなっていきます。
GitOps が進むほど、「実行者」は消えていく
GitOps の特徴は、実行主体を仕組みに委ねる点にあります。PR がマージされれば、あとは自動的に反映される。誰かが apply ボタンを押す必要はありません。
これは、実行ミスを減らすという意味では非常に強力です。一方で、「誰が実行したのか」という問い自体を、あまり意味のないものにします。
すると残るのは、「では、誰が決めたのか」という問いです。しかしその問いに対する答えは、Terraform のコードにも、Git の履歴にも残っていない。
実行は自動化され、判断だけが人の頭の中に残り続ける。この分離構造が、後になって効いてきます。
障害対応の場で、遅れて立ち上がる問い
問題が起きていない間、この曖昧さはほとんど意識されません。
しかし、ひとたび障害が起きると、振り返りの場で必ず似た問いが出てきます。「この変更は、なぜこのタイミングで入れたのか」「その判断は、誰が引き受けていたのか」。
Terraform の差分は追えます。PR も見つかります。けれど、その変更を「今入れる」と決めた背景や、そのとき想定していたリスクの範囲は、どこにも書かれていない。
判断は確かに行われていたはずなのに、その痕跡だけが消えている。この状態が、説明を難しくし、「次はどう判断すればいいのか分からない」という不安を残します。
Terraform × GitOps が可視化するもの、可視化しないもの
この組み合わせは、「どう変えたか」を驚くほど明確にします。コードとして残り、履歴として追え、再現もできる。
一方で、「なぜ今変えたのか」「誰がそれを引き受けたのか」は、意識して残さない限り、自然には見えてきません。
Terraform × GitOps は、判断を不要にしたわけではありません。ただ、判断をコードの外側に追い出しただけです。
コード化したのに不安が消えないと感じるとしたら、それはこの非対称さに、現場がまだ慣れていないからなのかもしれません。
自動化が進むほど、説明責任が薄まる理由
Terraform × GitOps が生む「静かな安心」
Terraform と GitOps を組み合わせた運用が安定してくると、変更の反映はとても静かになります。plan を確認し、PR をマージすれば、あとは仕組みが淡々と状態を揃えていく。
誰かが深夜に apply する必要もなく、反映漏れを気にして Slack を追い続けることもない。変更はいつの間にか入り、特に何も起きなければ、そのまま日常に溶け込んでいきます。
この「何も起きない」感じは、確かに安心です。運用が成熟してきた証拠でもあります。
何も起きなかった変更は、語られなくなる
ただ、その静かさには副作用があります。
問題が起きなかった変更は、振り返られません。なぜその変更を入れたのか、どこまでを想定内としていたのか、といった話題は、次第に出なくなっていきます。
Terraform のコードと Git の履歴は残るものの、それらは「何をしたか」を示すだけで、「なぜそう判断したか」までは語ってくれません。
結果として、判断の背景は共有されないまま、次の変更へと流れていきます。
失敗したときに初めて求められる「説明」
状況が一変するのは、問題が起きたときです。
障害対応やポストモーテムの場では、「なぜこの変更を入れたのか」「そのとき、どこまでを想定していたのか」という説明が求められます。
しかし、その説明をしようとすると、言葉に詰まることがあります。判断は確かに行われていたはずなのに、その判断を支えていた前提や合意が、どこにも残っていない。
「当時は問題ないと思っていた」「以前も似た変更が通っていた」。そうした言葉は事実かもしれませんが、十分な説明にはなりにくい。
自動化は、説明責任を引き受けてはくれない
Terraform や GitOps は、実行を自動化します。ミスを減らし、再現性を高め、運用を安定させる。
ただし、「なぜそう判断したのか」を説明する役割までを肩代わりすることはありません。
むしろ、自動化が進むほど、説明が必要になる場面は減り、説明する力は鍛えられなくなっていきます。
その結果、いざ説明が必要になったときに、言葉が追いつかないという状況が生まれます。
SRE Workbook が警告する「責任の所在が曖昧なシステム」
SRE Workbook では、信頼性を維持するためには、責任の所在が明確であることが重要だと繰り返し述べられています。
それは、誰かを責めるためではありません。障害が起きたときに、学習し、次に活かすためです。
Terraform × GitOps の運用では、技術的な正しさと引き換えに、判断や責任が見えにくくなる瞬間があります。
自動化が進んだのに不安が残るとしたら、それは説明責任までを含めた設計が、まだ十分に言語化されていないからなのかもしれません。
コード化は「信頼」を代行できるのか
Terraform × GitOps では、レビューが信頼の中心に置かれる
Terraform と GitOps を前提とした運用では、コードレビューが非常に重要な位置を占めます。Terraform の差分を確認し、影響範囲を読み、Git の PR 上で議論を重ねる。
このプロセス自体は健全です。少なくとも、誰にも見られずに変更が入るという状況はなくなり、判断はオープンな場に引き出されます。
レビューを通った、という事実は、チームとしてその変更を受け入れた証拠でもあります。
それでも、レビューだけでは足りない瞬間がある
ただ、レビューが通ったことと、安心できることは、必ずしも同じではありません。
Terraform のコードは正しい。構成も一貫している。GitOps のフローにも問題はない。それでも、「この変更をこの先も引き受けられるか」という問いが、どこかに残ることがあります。
レビューでは、「動くかどうか」「設計として破綻していないか」は確認できます。しかし、「この変更を入れた結果、将来どんな運用を背負うことになるか」までは、なかなか議論されません。
コードレビューは、どうしても現在形の確認になりがちです。
信頼性は、コードの品質だけでは測れない
SRE の文脈で語られる信頼性は、単に「正しく動くコード」を意味しません。
どこまでならリスクを取るのか。どこから先は止めるのか。何か起きたときに、誰が説明し、誰が対応するのか。
そうした合意が、暗黙ではなく共有されている状態そのものが、信頼性の土台になります。
Terraform や GitOps は、その合意をコードとして表現することはできますが、合意そのものを自動生成することはできません。
コードが増えるほど、合意は見えなくなる
皮肉なことに、コード化が進み、仕組みが洗練されるほど、人と人の間で行われている合意は見えにくくなります。
PR には差分が並び、レビューコメントは技術的な指摘に寄っていく。その裏で、「ここまでは大丈夫」「ここからは慎重にいこう」といった感覚的な合意は、言葉にされないまま流れていきます。
結果として、「レビューを通したから信頼できる」という言葉だけが残り、信頼の中身は曖昧になります。
Terraform × GitOps が問うのは、レビューの外側にある信頼
Terraform × GitOps の運用は、コードとプロセスの信頼性を大きく高めました。
一方で、「誰がどこまで引き受けているのか」「何を前提に判断しているのか」といった関係性の部分は、意識しない限り言語化されません。
コード化は信頼を助けますが、信頼そのものを代行することはできません。
レビューが重く感じられるとしたら、それはコードの問題ではなく、合意の輪郭がまだ十分に共有されていないサインなのかもしれません。
この仕組みは、誰の安心を守っているのか
Terraform と GitOps が守ってくれる「安心」の正体
Terraform は、環境の状態をコードとして固定し、「意図しないズレが起きにくい」という安心を与えてくれます。GitOps は、変更経路を Git に集約し、「勝手に何かが変わらない」という安心をもたらします。
これらは間違いなく、運用にとって大きな前進です。少なくとも、誰かの手元の操作や記憶に依存した不安定さは、大きく減っています。
ただ、その安心が「誰の安心なのか」は、あまり意識されないまま使われていることが多い。
オペレーター、開発者、組織。それぞれの安心
オペレーターにとっての安心は、「夜中に手動作業をしなくていいこと」かもしれません。Terraform と GitOps によって、変更は計画的に行われ、突発的な対応は減っていきます。
開発者にとっては、「自分の変更が正しい手続きを踏めば、本番に届くこと」が安心につながります。PR を出し、レビューを受け、マージすれば反映される。その見通しの良さは、開発速度を支えています。
一方で、組織としての安心は少し違います。障害が起きたときに説明できるか。なぜその判断をしたのかを、後からでも語れるか。その問いに答えられる状態こそが、組織の安心です。
これら三つの安心は、必ずしも同じ方向を向いていません。
「止める判断」は、どこに置かれているか
Terraform × GitOps の運用がうまく回っているほど、「止める」という行為は目立たなくなります。PR が通り、仕組みが反映し、特に何も起きなければ、そのまま次へ進む。
では、その流れの中で、「今回は止めよう」と判断するのは誰なのか。どんな条件が揃えば止めていいのか。
その問いに即答できないとしたら、不安が残るのは自然なことです。
止める判断が個人の勇気や経験に依存している限り、Terraform × GitOps の安心は、どこか脆いままになります。
答えではなく、問いとして残したいこと
コード化は信頼性を保証しません。
Terraform や GitOps は、判断をしやすくする土台を整えてくれますが、判断そのものを引き受けてはくれません。
仕組みが増えるほど、「誰が何を守っているのか」を言語化しない限り、不安は形を変えて残り続けます。
あなたの Terraform × GitOps の運用では、この仕組みは、誰の安心を守っていますか。
まとめ
Terraform と GitOps は、インフラ運用を確実に前に進めました。
構成はコードで管理され、変更は履歴として残り、反映の経路も整理される。以前よりも「何が起きたか」を追いやすい状態になっている。そこに異論はありません。
それでも不安が消えないとしたら、足りないのはツールではなく、判断の輪郭なのかもしれません。
Terraform は状態を示しますが、判断はしません。GitOps は変更を実行しますが、決定者を示すわけではありません。判断や責任は、コードの外側に置かれたままです。
仕組みが整うほど、「誰が」「いつ」「何を引き受けたのか」は見えにくくなります。問題が起きてから初めて、その問いに向き合うことになる。
コード化は、信頼性を助けます。ただし、信頼そのものを代行することはできません。
あなたの Terraform × GitOps の運用では、この仕組みは、誰の安心を守っていますか。
