気づけばこのブログも2021年から時が止まっていた。 LLMの進化によるインフラ運用の変化があまりに面白く（かつ怖く）、久しぶりに技術的な思考整理としてここに書き残しておこうと思う。
この記事は、コネヒト Advent Calendar 2025 - Adventar 3日目のエントリーです。
ソフトウェア開発における現在地
LLMの進化における開発フェーズの進展がすごいスピードで進んでいる。 一時期は、LLMの進化によりエンジニアが不要になるのでは？という話もあったが、現在地はそう簡単でもないというのを個人的には感じている。
当初のイメージだと下記だったが、現実のベストプラクティスは少し違う形に落ち着いたきたように思う。
- 人間:「xxな機能を実装したい」
- LLM:「わかりました。やります」
- n分後「実装が終わりました」
- 人間「完璧だ！マージしてデプロイ」
何が違うかというと、1の実行計画を適切に細分化し、LLMが行う作業を出来るだけ言語化することで人間の指示通りの成果物を得るというのが現在地点のベストプラクティスのように感じている。 もちろん、その実行計画の言語化もLLMを活用することでその部分のスピードアップは確実に出来ている。
つまり、LLMが今活躍している分野は、こんなところか。
- 膨大な既存コードやドキュメントから必要な情報を見つけ出す
- 人間の脳みそを言語化してLLMにコンテキストに渡せる文章として出力する
- そのコンテキストを元に、人間では出せないスピードでコーディングを行う
これだけでも人間の行っていた開発はだいぶ楽になっているが、人間の脳みその言語化がクリティカルパスになるという構造なので、ドメイン知識や開発経験が豊富なシニアエンジニアの方がLLMによる恩恵をより受けやすいというのはそのとおりだと思っている。 最近の記事だが、この記事を見て妙に納得した。 https://note.com/yuichiro826/n/n285026b11564
インフラ領域（IaC）ではどうか
さて本題に入るが、ここまでソフトウェア開発の話をしてきたがインフラ領域においてはどうだろうか? ここからは自分の経験談に基づく話で、もっとうまく活用できている人も当然にいると思うので一個人の意見として読んでもらえればと思う。
インフラをIaCで管理しているケースにおいては、ソフトウェア開発と同じアプローチでLLMにコードを書いてもらうフェーズまでは問題なく出来る。 筆者は、Terraformでインフラ管理をすることが多いが、Claude 4.5 sonnet等の最新のモデルを使えば、既存コードのコンテキストを理解したうえで、適切なコードを書いてくれるという感覚がありこれはもう十分に実用的だ。
LLMが書いたコードで terraform plan をしてもあまりエラーになる事例は多くない。
以前のモデルでは、学習データが古くTerraform Versionの古い定義を用いてエラーになることがたまにあったが、既存のVersionをコンテキストで与えることでそのエラーがほとんど出ることはなくなってきた。
つまり、IaC管理している領域においてはLLMによるインフラ構築/運用のコストはかなり下がったと考えてよいだろう。
CLI操作と「教習所の教官」のような感覚
クラウドインフラ領域におけるもう一つの作業としてCLIやGUIを使ったクラウドインフラのオペレーションがある。
インフラエンジニアであれば、admin相当のロールをもっていることが多いと思うので、ローカルのCLI実行権限をLLMに渡して勝手に作業させるのは現時点では難しいと感じている。 それは誤操作がそのままサービスダウンに繋がる点が一番大きい。LLMがオペミスしたからサービス落ちましたとは誰も言えないからだ。
それでもLLMを使った最適化が出来ないかと、Runbook作成をLLMの力を借りながらやり、それを人間がチェックし、LLMにRunbookの実行コマンドも任せながら一つ一つ人間がチェックするというフローを何回か繰り返したときがある。もちろん本番ではなく開発環境においてだ。 その時に、実行は人間がやっても変わらなくないかという感覚に襲われた。
そして、ハンドルをLLMに握らせた場合と、自分でコマンド実行する場合で、実行/説明責任は同じだが、どうしても前者の方が注意が散漫になるケースがあった。これは私の特性かもしれないし人間の性なのかもしれない。 コマンドを一つ一つチェックする頭と自分で実行する頭は何か違うのかもしれず、後のナレッジとしての自分への残り方も異なる気がしている。
当然だが、実行/説明責任は人間にあり、コマンドをRunbookからコピペする時間と認知コストは減るが、コマンドを一つずつ確認する負荷はゼロにはならない点で、自分の感覚としてこの作業をLLMに任せることに大きな価値を感じられなかった。 ハンドルをLLMに握らせてしまうことで、意図せぬコマンドをエージェントモードで実行してしまうのではないかみたいな一種の恐怖が常に隣り合わせにあるイメージ。座席の隣で教習生を見守る教官のようなヒヤヒヤ感とでも言おうか。
スクリプト化とナレッジ活用のジレンマ
一つ一つの作業のチェックが大変だしあらゆるコストがかかるので、それを解決するために一連の作業をスクリプト化しようと次は考える。 これは、ワークフローを作ると同義で、Runbookに則って一コマンドずつ実行することとワークフローを手動で実行することは決められたフローを行う点では同義だ。もちろん手動実行は常にオペミスのリスクをはらむので、出来るだけワークフローを自動実行した方がより安全なオペレーションが出来る。 LLMにスクリプト化させて、そのスクリプトを完璧にレビューするフローが最高だと思いつつ、そこまで重厚でないオペレーションに対して、毎回スクリプト化してレビューを挟むのは少々腰が重いと個人的には感じる。
実行ログをLLMにドキュメント化してもらいナレッジとして活用することはインフラ作業においても後からどんどん複利的な効果がでると思うのでこれはできるだけインフラ作業のフローにも組み込んでいくべきだろう。 現在はRunbookに残したログを次回のRunbook作成時にLLMにコンテキストとして与えることをしている。 実行をLLMに任せればこの部分のナレッジ化をLLMに任せられることは大きなメリットになりうるが、それよりも誤操作へのリスクが今は上回っている。
責任分界点と今後の展望
LLM活用と聞くとエージェンティックな動きをどうしても頭の中では期待してしまう。しかし、実際はワークフロー作りのサポートまでが今の主戦場かなと個人的には思っている。もちろんこれは自分の観測範囲での話なので、もっと攻めのインフラを行っている現場も世の中にはあるとは思っており、それを否定するものではない。 まぁ、ただこんなことを書きながらも、コマンド実行した先やGUIで何かをコミットした先のクラウドインフラに起こるオペレーションは抽象化されており、実行後の世界はクラウド任せというのは事実でハンドルをもてる世界がインフラエンジニアとしては減ってきているのは間違いないと感じている。
クラウドのコミットの先の世界では責任分界モデルで実行/説明責任がクラウド側にあることが大きくそこは作業者の負担にあまりならないようになっている。このことを考えたときに、結局は、LLMにエージェンティックな作業をどこまで任せられるのかは実行/説明責任をどこまでLLMに委ねられるかという個人というよりは開発組織なりでの境界を作ることがより一層のクラウドインフラにおけるLLM活用進展の鍵なのかもしれないと最後に思った。
もちろん、各クラウドベンダーが開発を進めているであろう自然言語でクラウドリソースを思い通りに操れたり、障害調査や復旧を勝手にしてくれるようなエージェントの精度が上がってくれば、全く違う未来がそう遠くないうちにやってくるかもしれないという希望を個人的には夢見ているが。
