# DevOps エンジニア・プラットフォームエンジニア・SRE

> 動き続けさせ、そして他の人が出せるようにする。配信の流れと基盤をつくり、そして本番が壊れたときに叩き起こされる人である。

ページ: https://flyvolo.ai/ja/careers/devops-engineer
影響指数: 46/100 · 確信度 確度が低い · 評価日 2026-09-14
これは失業の確率ではありません。

## 適用範囲

基盤、配信の流れ、本番の信頼性を扱う。端末と利用者の支援はこのサイトでは別の職業なので含まないし、セキュリティの運用も含まない。最大の変数は、誰かが設計した系を運用しているのか、他人が運用する系を設計しているのかである。その二つの晒され具合は同じではない。

## 業務

### 設定を書く

- 方向: 自動化されつつある
- 根拠: 根拠あり(検証済みの記録を添付)
- 理由: これは成否が機械的に確かめられるコードである——きれいに適用されるか、エラーになるか——そしてそれこそ、モデルが監督なしに試し、失敗し、また試せるようにする性質である。しかも冗長で繰り返しが多いことで知られているので、起草される量は大きく、確認は速い。
- これでは言えないこと: 設定が速くなることは、設定が増えることであって、仕事が減ることではない——つくられた資源は一つ残らず、誰かが保ち、守り、いずれ消さなければならない資源であり、そして時間は書くことからほどくことへ移る。ほどくことは計画表の上に映らない。だからこれは、節約に見えて負債のように振る舞う可能性が最も高い業務である。
- 記録:
  - 2026-01-22 · 実際の導入 · Cloudflare のポリシー自動化基盤が生成したルーティングポリシーにより、BGP プレフィックスが 25 分間漏洩 —— 同社が示した対策は CI/CD への自動ポリシー検査の追加であり、人による確認の追加ではない — https://flyvolo.ai/ja/changes/ev-20260122-devops-engineer-3 (出典: https://blog.cloudflare.com/route-leak-incident-january-22-2026/)
  - 2025-09-23 · 使用者による採用 · DORA の2025年の調査は、回答者の90%が仕事でAIを使っていると報告し、そしてAIの導入がいまも配信の安定性と負の関係にあることを見出した — https://flyvolo.ai/ja/changes/ev-20251022-devops-engineer-1 (出典: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)

### 叩き起こされること

- 方向: いまも人が主導
- 根拠: 根拠あり(検証済みの記録を添付)
- 理由: 自動の復旧は存在し、誰かが想定していた故障を扱う。事案とは、定義からして、誰も想定していなかったもののことである。判断は、正しい答えについてではなく、受け入れられる損害についてである——どの顧客向けの劣化なら二十分我慢できるか——そしてそれは、あとから問われる人が背負う事業上の判断である。
- これでは言えないこと: 判断が人に残ることは、当番表に何人いるかについて何も語らない。よくある設計は、より少ないエンジニアが、より良い自動化とともに、より多くのサービスを覆うことであり、それは業務をどれも無傷に保ったまま当番を悪くする——そしてそれが続けられるかどうかは人員の問いであり、どの自動化の指標もそれを捉えない。
- 記録:
  - 2026-05-28 · 実際の導入 · 2人のGoogleエンジニアが、自社のSRE組織がインシデント対応で動かしているエージェントを書いた:アラートのグループ化、引き継ぎ文書、ポストモーテムの下書き、そして場合によっては自律的な緩和 — https://flyvolo.ai/ja/changes/ev-20260528-devops-engineer-4 (出典: https://cloud.google.com/blog/products/devops-sre/how-google-sre-is-using-agentic-ai-to-improve-operations)
  - 2025-09-23 · 使用者による採用 · DORA の2025年の調査は、回答者の90%が仕事でAIを使っていると報告し、そしてAIの導入がいまも配信の安定性と負の関係にあることを見出した — https://flyvolo.ai/ja/changes/ev-20251022-devops-engineer-1 (出典: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)
  - 2022-10-01 · 予測 · シンガポールの情報通信の当局は、サービス水準と系の性能に関わる職務が DevOps と開発へ移ると評価し、自動化と統制のエンジニアを、移り先となる職として挙げた — https://flyvolo.ai/ja/changes/ev-20221001-devops-engineer-2 (出典: https://www.swda.gov.sg/api/assets/d65e963c-df80-4768-b5b4-4bb214307a22/imda-impact-study-master-full-vf6.pdf)

### いくらかかり、なぜかかるのか

- 方向: 増強されつつある
- 根拠: 根拠あり(検証済みの記録を添付)
- 理由: 異常を見つけることは分析であり、道具はそれをうまくやる。それにどう手を打つかを決めることは、エンジニアの時間と、危険と、金のあいだの取捨であり、その会社が今四半期に何をしようとしているかに依る。前半はずいぶん安くなり、後半は安くなっていない。例えば米人事管理局は、クラウドの請求に異常検知を適用し、適正化、購入確約、予算の判断を、書面の意思決定マトリクスに基づき名指しされたチームを通じて処理している。
- これでは言えないこと: 分析が安くなることは、仕事を減らすのではなく期待を上げる——画面が無駄な資源の上位十件を名指しできるようになった瞬間、まだ残っている一件ごとに誰かが理由を述べなければならない。業務は調べることから説明することへ移り、そして説明とは会議のことである。
- 記録:
  - 2024-03-31 · 実際の導入 · 米人事管理局、クラウド支出の異常検知を運用し、適正化・購入確約・予算の判断を指定のFinOpsチームで処理 — https://flyvolo.ai/ja/changes/ev-20240331-devops-engineer-7 (出典: https://itvmo.gsa.gov/assets/files/OPM-FinOps-Case-Study.pdf)

### どう作るべきかを決める

- 方向: いまも人が主導
- 根拠: 根拠あり(検証済みの記録を添付)
- 理由: この職業のなかで、自動の審判がまったくない唯一の業務である——設計が正しかったかどうかは十八か月後に分かり、そのころには選んだ人はたいてい去っている。それは、このチームの手持ちの力と、この会社の許容度を知っていることに依っており、そのどちらもどのリポジトリのなかにもない。大規模な障害の公開記録は、自動化が失敗したあと誰が決めるのかを示している。Google Cloud は2025年6月の障害についての報告で、サービスがフェイルオープンになるよう設計し直すと約束した。CrowdStrike の2024年の分析は、自社の失敗を、自動の検証器と12件の固定のテストケースを経て展開の設計にまでたどり、あらゆる更新を段階的に配ることで直した。
- これでは言えないこと: 最も安全な業務であることは、最も小さい業務であることでもある——大半のチームで設計の判断は四半期に数日であり、一週間の残りは、あなたのために起草されつつある仕事である。ある職は、最も上級の業務において安全でありながら、時間の大半を失いうる。
- 記録:
  - 2025-06-12 · 制限または撤回 · エラー処理もフィーチャーフラグもない変更にさかのぼる世界規模のクラウド障害が、サービスがフェイルオープンになるような設計のやり直しにつながった——提供者自身の障害報告 — https://flyvolo.ai/ja/changes/ev-20250612-devops-engineer-5 (出典: https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW)
  - 2024-07-19 · 制限または撤回 · 論理エラーを含む自動のコンテンツ検証器と12件の固定のテストケースが、欠陥のある更新をWindowsの機械へ通した。修正は、設計による段階的な展開だった — https://flyvolo.ai/ja/changes/ev-20240719-devops-engineer-6 (出典: https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf)

## 引用のしかた

- 単位は職名ではなく業務です。どの業務が変わり、どれが変わらないのかを述べてください。
- 各業務の根拠と限界を一緒に伝えてください。推論は結論ではありません。
- このページは年数を示しません。ここから年数を導き出さないでください。
- 詳しくは: https://flyvolo.ai/llms.txt