「作れること」の価値が消える AI 時代に、SRE / プロダクション・エンジニアリングの重要性が上がる理由
integrated1453氏のポストが、すてぃお（@suthio_）氏の note 記事「『作れること』の価値が消えていくAI時代にソフトウェアエンジニアは何をやるべきか」に対して、SRE の視点からコメントし、98いいね、81ブックマーク、約12,600表示と反響を呼んでいます。
エンジニアにとって、より高度にSREをやっていくことの重要性が上がるという話だと思った。プロダクションで起こっている問題をデバッグして修正して再発防止するとか、それらを再現性高く実行できる仕組みを作るとか、SREがやる運用のエンジニアリングそのもの。まずは障害対応100本ノックしよう！笑 — integrated1453
元のすてぃお氏の投稿は552いいね、759ブックマーク、約87,900表示とさらに大きな反響です。すてぃお氏は adding Inc. 代表取締役で、元スタートアップ CTO。Claude Code の登場以降、AI 時代のエンジニア像について一貫した発信を続けています。
すてぃお氏の主張 — 「作れる」から「動かし続ける」へ
核心のテーゼ
すてぃお氏の一連の記事を横断する主張は明確です。
Claude Code を使い始めてから、僕の開発方法は根本的に変わりました。以前は「この処理を実装するのに3日くらいかかるな」と見積もっていたものが、今は適切な指示を出せば30分で形になる。
実装スキル単体の市場価値が低下し、求められるのは以下の能力だという主張です。
| 低下する価値 | 上昇する価値 |
|---|---|
| コードを書く能力 | コードを読んで検証する能力 |
| 実装の速さ | 仕様・制約の設計力 |
| 個別機能の開発 | 自己修復・自己改善するシステムの設計 |
| 技術力単体 | 技術力 × ビジネス力 |
すてぃお氏の提案する3つの方向性
- 「勝手に動き続ける仕組み」を作る: 修正する人ではなく、自己修復・自己改善するシステムの設計者になる
- コードは「読めるけど書けない」でいい: エンジニアの主要業務が「書く能力」から「読む能力」へ転換
- 事業成長にコミットする: 技術へのコミットメントよりも事業成長へのコミットメントが重要
integrated1453 氏の洞察 — これは SRE の話だ
integrated1453 氏のコメントの核心は、すてぃお氏の「動かし続ける仕組みを作る」という主張を、SRE（Site Reliability Engineering）のコンテキストに接続したことです。
SRE が担う「動かし続ける」
| すてぃお氏の表現 | SRE の対応する実践 |
|---|---|
| 自己修復するシステム | Self-healing infrastructure、自動ロールバック |
| 自己改善するシステム | ポストモーテムからの自動ガードレール生成 |
| 再現性高く実行できる仕組み | Infrastructure as Code、ランブック自動化 |
| プロダクションの問題をデバッグ | オブザーバビリティ、分散トレーシング |
| 再発防止 | SLO/SLI 定義、エラーバジェット管理 |
「作れること」の価値が下がるなら、「動かし続けること」の価値が相対的に上がる。これは論理的に自然な帰結です。
なぜ SRE は AI に置き換えられにくいのか
コード生成と運用の非対称性
AI コーディングツールが急速に進化する一方で、プロダクション環境の運用には AI が対処しにくい特性があります。
| 特性 | コード生成 | プロダクション運用 |
|---|---|---|
| 入力の予測可能性 | 高い（仕様→コード） | 低い（未知の障害パターン） |
| フィードバックループ | 即時（テスト通過/失敗） | 遅延（本番で数週間後に発現） |
| コンテキストの範囲 | ファイル/リポジトリ内 | インフラ全体 + ビジネスコンテキスト |
| 失敗のコスト | 低い（やり直し可能） | 高い（ダウンタイム、データ損失） |
| 判断の曖昧さ | 低い（正解が明確） | 高い（トレードオフの連続） |
gihyo.jp のインタビューでスリーシェイク代表の吉田拓真氏が述べているように、「パブリッククラウドが隆盛したときに『インフラエンジニアは死ぬ』と散々言われたが結局死ななかった」のと同様のパターンです。抽象化・自動化が進むほど、その裏側を理解し、壊れたときに対処できる人材の希少性が上がります。
AI SRE ツールの現在地
2026年時点で AI SRE ツールは急速に進化しています。
| ツール | 機能 |
|---|---|
| New Relic SRE Agent | テレメトリー分析、根本原因推論、修正 PR 自動生成 |
| Sherlocks.ai | 協調型インシデントレスポンス |
| Resolve.ai | 自動修復ワークフロー |
| Harness AI SRE | 検知→診断→修復の自動化パイプライン |
| AgentSRE | エージェント型 AI によるインシデント管理 |
しかしこれらのツールは SRE を 置き換える のではなく、増強する 設計です。InfoQ の報告によると、2026年の業界コンセンサスは「AI が推奨し、人間が承認し、システムが実行する」ハイブリッドワークフローです。
デスキリング問題 — AI 依存の落とし穴
AI が SRE の補助となる一方で、SigNoz のニュースレターは「AI は SRE を置き換えていない。デスキリングしている」と警鐘を鳴らしています。
デスキリングの仕組み
AI がインシデント対応の大部分を処理すると、人間の SRE は稀にしか発生しない高度な問題への対応能力を失います。これは1983年の認知心理学の研究に基づく知見で、自動化のパラドックスと呼ばれます。
| 領域 | 事例 |
|---|---|
| 医療 | AI 支援を使用した内視鏡医の無支援検出率が 28% → 22% に低下 |
| 航空 | 自動操縦依存パイロットの状況認識能力が低下。FAA が手動飛行時間を義務化 |
| SRE | AI がアラート分析・既知障害の自動修復を処理 → 人間は未知の障害に弱くなる |
「ネバースキリング」というさらに深刻な問題
既存の SRE がスキルを失う「デスキリング」以上に深刻なのは、**新入りの SRE が最初から深い実践経験を積む機会を持たない「ネバースキリング」**です。AI が Tier 1/2 の障害を全て処理すると、ジュニア SRE はいきなり Tier 3 の未知の障害に直面することになります。
対策 — 意図的な非効率性
SigNoz の記事は、FAA のパイロット訓練に倣い、自動化可能な事象でも意図的に人間が対応する「学習機会」を確保することを提案しています。
推奨されるアプローチ:
1. 定期的な「アナログドリル」: AI 支援なしでのインシデント対応訓練
2. 認知的関与の設計: 単なる承認者ではなく、AI と並行して問題に関与
3. ローテーション制: 自動化レベルを意図的に下げた期間を設ける
integrated1453 氏の「まずは障害対応100本ノックしよう！」は、まさにこのデスキリング対策を実践レベルで表現しています。
AI 時代の SRE に求められるスキル
従来の SRE スキル + 新しいスキル
| カテゴリ | 従来のスキル | AI 時代に追加されるスキル |
|---|---|---|
| オブザーバビリティ | メトリクス・ログ・トレースの設計 | AI テレメトリー分析の検証、LLM ワークロードの監視 |
| インシデント対応 | 障害の検知・対応・復旧 | AI 自動修復の監督、AI が対応できない障害のエスカレーション |
| 信頼性設計 | SLO/SLI 定義、エラーバジェット | AI エージェントの信頼性設計（ガードレール、権限制御） |
| 自動化 | IaC、CI/CD パイプライン | AI エージェントのワークフロー設計、プロンプトエンジニアリング |
| ポストモーテム | 根本原因分析、再発防止策 | AI 支援による分析の加速 + 人間の判断による妥当性検証 |
SRE が AI にもたらす2つの価値
LayerX のエンジニアブログが整理するように、SRE が AI にもたらす価値は2つの軸で整理できます。
| 軸 | 内容 | 例 |
|---|---|---|
| コンテキスト | AI がより良く動作するための下地 | テレメトリー収集、IaC によるコード化、ポストモーテムの整備 |
| ガードレール | AI の失敗を予防・回復するための保険 | 自動ロールバック、カナリアデプロイ、フィーチャーフラグ |
AI が生成するコードが増えるほど、そのコードを本番で安全に動かすための SRE の仕事は増えます。
実践ロードマップ — 明日から何をすべきか
SRE に興味がある開発者向け
integrated1453 氏の「障害対応100本ノック」を実践するための具体的なステップです。
| ステップ | アクション | リソース |
|---|---|---|
| 1. オブザーバビリティの基礎 | メトリクス・ログ・トレースの3本柱を理解する | SRE Book（Google） |
| 2. インシデント対応の訓練 | Game Day / Chaos Engineering を実施 | Gremlin、LitmusChaos |
| 3. ポストモーテムの習慣化 | 障害の根本原因分析と再発防止策を文書化 | Blameless ポストモーテムガイド |
| 4. IaC の習得 | Terraform / Pulumi でインフラをコード化 | HashiCorp Learn |
| 5. SLO/SLI の設計 | ユーザー視点の信頼性指標を定義 | OpenSLO |
既に SRE をやっている人向け
| アクション | 目的 |
|---|---|
| AI SRE ツールの評価 | 自チームのワークフローに適合するツールを選定 |
| デスキリング対策の導入 | AI なしでのインシデント対応ドリルを定期実施 |
| AI エージェントの信頼性設計 | AI が生成するコードのデプロイパイプラインにガードレールを設計 |
| LLM ワークロードの監視 | AI エージェント自体のオブザーバビリティを構築 |
まとめ
- 「作れること」の価値が低下し、「動かし続けること」の価値が上昇: AI がコード生成を加速する一方、プロダクション環境の運用には未知の障害パターン、ビジネスコンテキスト、トレードオフの判断力など AI が対処しにくい特性がある
- SRE はこの文脈で最も価値が上がる専門領域の一つ: プロダクションの問題のデバッグ、再発防止、再現性の高い仕組みの構築は、AI 時代においてもエンジニアリングの中核
- AI SRE ツールは SRE を置き換えるのではなく増強する: 2026年の業界コンセンサスは「AI が推奨、人間が承認、システムが実行」のハイブリッドワークフロー
- デスキリング問題に注意: AI 依存が進むと、稀にしか発生しない高度な障害への対応能力が失われる。「ネバースキリング」（新人が実践経験を積めない）はさらに深刻
- 「障害対応100本ノック」はデスキリング対策そのもの: 意図的に AI 支援なしで訓練する機会を確保することが、長期的なスキル維持に不可欠
- SRE が AI にもたらす価値は「コンテキスト」と「ガードレール」: AI が生成するコードが増えるほど、それを安全に動かすための SRE の仕事は増える
- 事業成長へのコミットメントと運用力の掛け合わせが差別化要因: すてぃお氏の「技術力 × ビジネス力」に、プロダクション運用の専門性を加えることが、AI 時代のエンジニアの生存戦略
参考
- integrated1453 — SRE の重要性に関するポスト
- すてぃお（@suthio_） — 「作れること」の価値が消えていく AI 時代にソフトウェアエンジニアは何をやるべきか
- すてぃお — Claude Code 時代のソフトウェアエンジニア生存戦略（note）
- すてぃお — AI 時代の理想的なエンジニア像は事業成長にコミットするエンジニア（note）
- すてぃお — コードは「読めるけど書けない」でいい時代になった（note）
- SigNoz — AI Isn’t Replacing SREs. It’s Deskilling Them.
- gihyo.jp — AI 時代のインフラエンジニアリングと SRE の価値（スリーシェイク吉田拓真氏）
- InfoQ — Human-Centred AI for SRE: Multi-Agent Incident Response
- LayerX — AI Workforce 事業部 SRE の現在とこれから
- chroju.dev — 2026年年頭時点における SRE EM の立場からの AI 雑感
- New Relic — SRE Agent: Assistive AI For Incident Response
- incident.io — 5 Best AI-Powered Incident Management Platforms 2026
- a16z — コーディングは死んだ。だが私たちはソフトウェアの黄金時代にいる（Business Insider Japan）