前職では固定資産管理パッケージの導入プロジェクトに8年間いました。インフラの設計・構築・運用を担当し、最後の数年は6名のチームのリーダーでした。
あの現場の品質保証は、手順書とダブルチェックでした。作業手順を書き、レビューし、当日は2人で画面を見ながら読み上げて実行する。真面目な仕組みだし、実際に事故は少なかった。
ただこの方式には構造的な上限があります。品質が「その日の担当者の注意力」に乗っている。手順書は運用が変わるたびに腐るし、ダブルチェックは常に2人分の時間を食う。そして何より、うまくいっている限り誰も改善しない。事故が起きて初めて手順書に赤字が増える。
「インフラをコードで管理して、人がミスできない仕組みをつくる」というのは、この経験の裏返しです。人に気をつけさせるのをやめて、そもそも間違った状態を作れないようにする。今はTerraformでインフラをコードに落とし、SLI/SLOで「どこまで守るか」を先に数字で決める、という形で同じことをやっています。
で、ここからが最近考えていることです。
いま調査・設計・実装・レビューのほぼ全工程でClaude Codeを使っています。使い始めて驚いたのは速さより、自分が8年間やってきた「手順書を書く」仕事に、やっていることがかなり近いことでした。
エージェントに仕事を任せるとき、結局やるのは、前提を書き、やってはいけないことを書き、判断に迷ったときの基準を書くことです。手順書と違うのは、読み手が疲れないこと。同じ指示に対して、だいたい同じ品質で返ってくること。逆によく似ているのは、曖昧に書けば曖昧な結果が返ってくるところです。「よしなにやっといて」で事故るのは、人間もAIも変わりませんでした。
そう考えると、SREの仕事自体はあまり変わっていないのかもしれません。人の注意力に依存しない仕組みをつくる、という点では同じで、対象が「人の運用」から「人とエージェントが混ざった運用」に広がっただけです。ガードレールをどこに置くか、どこまでAIで通してよくて、どこから人間が見るのか。SLOで信頼性の線を引いてきたのと同じ議論を、今度は開発プロセスに対してやることになる。
まだ答えは出ていません。ただ「AIで速くなりました」で終わらせず、なぜ速くなったのか・どこが危ないのかを説明できる形にしていくのが、しばらくの自分のテーマだと思っています。
