Tech Memo

1. はじめに：美しき「トイル撲滅」の裏で

少し前、私は「Amazon Q Developer等の生成AIを活用し、毎月発生していた泥臭いAWSのコスト分析を自動化した」という、意気揚々とした社内のテックブログを書いた。

それまでは、毎月スプレッドシートやAWS Cost Explorerとにらめっこし、数時間かけてデータの集計や変動要因の特定、報告用スライドの作成を行っていた。その作業がAIの導入によって、わずか「10分のプロンプト実行と確認」だけで終わるようになったのだ。
「これでトイルは撲滅された。データは自動で分析され、美しいレポートとして共有される。誰でも簡単にコスト状況を把握できる。全員でコスト意識を持つチームになれるはずだ」
と、私は確信していた。

しかし、現実は残酷だった。自動化から数ヶ月が経った今、私たちのチームから 「コストの番人」 は完全に消え去り、その仕組み自体も静かに「形骸化」という名の死を迎えた。

2. 自動化の皮肉（Ironies of Automation）：摩擦が消えて、関心も消えた

「自動化して楽になればなるほど、人間は中身を理解できなくなり、いざというときの対応が余計に難しくなる」。SREやシステム運用の世界でよく言われる 「自動化の皮肉（Ironies of Automation）」 というパラドックスだ。

今回私たちが直面したのは、まさにこの現象のFinOps版だった。

手作業で泥臭くコストデータを集めていた頃は、そこにはたしかに「摩擦（Friction）」が存在していた。

• 「なぜかこのマイクロサービスのData Transferコストが先月より20%増えている」
• 「このタグの付いていないリソースは誰が作ったものだろう？」

データを手動で整理するプロセスの中で、脳に負荷がかかり、疑問が生まれ、それをインフラの構成変化やアプリケーションのリリースと自然に結びつけることで、説明責任を果たすことができていた。
つまり、手作業という摩擦こそが、コストに対する解像度を高め、「オーナーシップ」を育むためのタッチポイント（接点）だったのだ。

AIによる自動化は、この摩擦をきれいに消し去ってくれた。AIが自動で要約した「今月のAWSコストレポート」というスマートなMarkdownテキストが作成され、レポートの転記作業は一瞬で終わるようになった。
しかし、摩擦が完全に失われた結果、データはただの「景色」になった。誰も、その数字の背景にあるアーキテクチャの変更や無駄に対して疑問を持たなくなってしまったのだ。

3. 「全員の責任」は「誰の責任でもない」という冷たい現実

自動化を進める際、私は「一部のメンバー（かつての私）がコストの番人として抱え込むのではなく、誰でも分析結果を読める状態を作ることで、全員が当事者になれる」と理想を掲げていた。

しかし、現実はこうだった。

• 届けるべき場所に届いていない
  週次の進捗レポートにコストとサービスレベル（SLO）の枠を設け、必死に情報を取り込み続けたが、日々の開発や意思決定の流れの中で、その情報が自然に読まれ、議論される導線までは作れていなかった。
• もともと書かれず、見られてもいない
  レポートへの転記やコメントをいくら呼びかけても、メンバーから自発的な書き込みは生まれなかった。結局、自動化されたAIの分析結果からデータを引っ張ってきて、レポートに取り込み、整備する作業は「私」が一人でやり続けることになった。

「自動化したから誰でもできる」というのは幻想だった。自動化は作業をラクにしたかもしれないが、関心を持たせるための仕組みや「読んでもらう時間の確保」が組織に存在しなければ、結局は特定のエンジニアが裏で泥臭くレポートをメンテナンスし続けるだけだ。トイルの形が変わっただけで、本質的な「属人化と疲弊」は何も解決していなかったのだ。

実際、この「泥臭いレポートへの取り込みと分析」の手を止めた途端、コスト確認は月次のみになり、結果として、チームは重大なコスト超過（バジェットオーバー）に月末まで気づかず、翌月の月初になってようやく気づくという事態を招いてしまった。

4. なぜ「巻き込み」に失敗したのか？ —— 組織ダイナミクスと精神論の限界

メンバーを「巻き込む」ことの難しさについて、私はひとつの壁にぶつかっていた。それは、個人の意識の問題というより、チームとして当事者意識が生まれる構造を作れていなかったことにある。

開発チームにはそれぞれ優先順位があり、機能開発、障害対応、問い合わせ対応など、日々向き合うべき仕事がある。その中で「コスト意識を持ちましょう」「レポートを書きましょう」と呼びかけても、業務フローの中に組み込まれていなければ、追加の確認作業として埋もれてしまう。
どれだけスマートなAIレポートを用意しても、それを「いつ、誰が、何の判断に使うのか」が決まっていなければ、情報は行動につながらない。

AIは分析データの要約（WhatやHowの一部）は代行してくれる。しかし、「この無駄なコストを削減するためにリソースを削除しよう」と意思決定し、実行に移す主体（Who）にはなれない。
自動化によって「番人」という明示的な担当者を実質的にチームから排除し、個人の善意に責任を分散させたことで、コストに対するアクションを起こすトリガーそのものが消失してしまった。

5. そもそも「トイルの本質」とは何だったのか？ —— 認知の摩擦とチームの共通認識

この手痛い失敗から、私は「トイルの本質」について考え直す機会を得た。

トイルの本質

SREにおいて、トイルは「撲滅すべき無駄な作業」である。しかし、「作業のトイル（泥臭いデータの集計や取り込み）」を撲滅する過程で、人間がシステムやコストに関わる「認知の摩擦（考えるきっかけ）」まで一緒に捨ててしまった。これが、今回の振り返りにおける最大の学びである。

データを集計してレポートを作るのはトイルだ。しかし、データを解釈し、「なぜコストが増えたのか」と問いを立てて意思決定することは、トイルではなく「エンジニアリング」そのものである。当然ながら、その意思決定のオーナーシップまでは、AIは肩代わりしてくれない。

そしてもう一つ、極めて重要な学びがある。それは、 「トイルは個人が勝手に感じるものではなく、チーム全体の共通認識に昇華して解消すべきものである」 ということだ。
私一人が「レポートへの取り込み作業はトイルだから、AIで自動化して効率化しよう」と裏でサイレントに進めてしまったことで、チームにとっては「なぜそのデータが必要だったのか」「その自動化によって自分たちがどのような認知的な役割（意思決定）を引き継ぐべきなのか」という共通認識が失われてしまった。

SREが一人でサイレントにトイルを撲滅するヒーローになってはいけない。それはただの「属人化した自動化」であり、そのSREがいなくなった瞬間に破綻する。「何をトイルとして機械に任せ、何をチームの共通アテンション（認知）として残すか」をメンバーとすり合わせるプロセスこそが、トイル削減の本来の姿であるべきだったのだ。

6. 私たちはどうすべきだったのか？ —— 「誰かがやるだろう」を防ぐ役割と通知の設計

週次でレポートを作成していたのだから、本来であればゾンビリソースの発生に「気にしていれば気づけた」はずだった。しかし、現実は「誰かがやるだろう」という傍観者効果（責任の分散）によって、全員がそのボールをスルーしてしまった。

もし私が過去に戻ってFinOpsのプロセスを設計し直すなら、メンバーの「自主的なコスト意識」に期待するだけではなく、「誰がボールを拾うか」を仕組みとして明確にする設計にシフトするだろう。

① アラートの「オーナーシップ」と「ルーティング」の設計

Slackやドキュメントに全体レポートを投下して「誰かが気づいてくれる」ことを期待するのは、FinOpsにおける最も危険なアンチパターンだ。

• リソース作成者へのダイレクトな通知（ルーティング）
  全体チャンネルへのブロードキャストをやめ、放置されているリソースのタグ（OwnerやCreatedBy）から作成者を自動で特定し、本人に対して「このリソースが3日間放置されていますが、削除してよいですか？」と直接通知する仕組みを作るべきだった。当事者に直接ボールを渡せば、「誰かがやってくれるだろう」という責任の分散を避けやすくなる。

② 「コスト・オンコール（持ち回り制当番）」による傍観者効果の排除

インフラの障害対応にオンコール（当番）があるように、週次のコストレポートの確認にも「当番（コスト・パイロット）」をローテーションで割り当てるべきだった。

• 週次レポートの確認と、検出されたゾンビリソースの確認・削除作業を、その週の当番が責任を持って完了させる。
• 役割を明示的に一人に集中させることで、「誰も責任を持たない」状態をシステムとして排除する。

③ 開発プロセス（ゲートキーパー）への組み込み

それでも対応されないゾンビリソースや予算超過が発生した場合は、SREの「エラーバジェットポリシー」と同様に、チームのガバナンスとして扱うべきだった。たとえば、「予算超過時は、開発スプリントの優先順位をコスト最適化タスクに切り替える」というプロセスルールをあらかじめチームで合意しておく。これならば、コストの問題は個人の気づきではなく、チームの意思決定プロセスに乗る。

④ 「SREリエゾン（一時的なチームジョイン）」による関心の接続

開発と運用の関心が自然に分かれてしまうことも、今回の形骸化の背景にあった。この壁を越えるためには、SREが「インフラ担当」として孤立するのではなく、各開発チームに一定期間試験的にジョインする「SREリエゾン（組み込み型SRE）」の体験を作るべきだった。

• 開発スプリントにSREがメンバーとして入り、一緒にプロダクトコードを書き、開発側のコンテキストや苦痛を共有する。
• 開発者と顔の見える関係を築くことで、インフラやコストを「他の誰かの仕事」から「自分たちのプロダクトの品質」へと昇華させ、お互いのドメインに自然と越境し合える空気感（スピリット）を初期段階から育む。

7. おわりに：この孤独な取り組みを供養する

トイル（Toil）を撲滅することは間違いなくSREのアプローチとしては正しいことだ。しかし、トイルを消し去ることで「その作業がもたらしていた人間への認知や関心」まで一緒に消し去っていないか、常に警戒しなければならない。

FinOpsの本質はツールではなく、 「文化（Culture）」 だ。そしてその文化は、個人の善意だけでは維持できない。適切なガバナンスと、システム的なガードレールという「骨組み」があって初めて、文化は形骸化せずに生き続ける。

このFinOpsの取り組みをなんとか軌道に乗せようと一人で試行錯誤してきたが、今こうして一歩立ち止まり、この経験をひとつの「供養」とする。

これからこのインフラを引き継いでいく誰かや、同じように「コストの自動化」の罠に苦しむSREにとって、この記事が少しでも次のステップへのヒントになれば幸いだ。
私たちは、AIという強力なパートナーを手に入れた。次は、人間側がそれをどう使うかが問われる。