DevOpsを始める

文書基準: 2026年8月

概要

従来のIT組織では、開発チーム（Dev）がコードを書き、運用チーム（Ops）がサーバーを管理します。開発チームは早く機能をリリースしたいと考え、運用チームは安定性を維持したいと考えるため、対立が生じます。デプロイは数週間に一度で、障害が発生すると互いに責任を押し付け合う構造です。

DevOpsは、この壁を取り払う文化であり実践方法です。開発者が運用まで全部行うのではなく、開発と運用が互いの業務に可視性を持ち協力して、より速く安定的にサービスを提供することです。

DevOpsではないもの

❌ 開発者がサーバー管理まで全部行うこと
❌ 特定のツールを使えばDevOpsであるということ
❌ チーム名を「DevOpsチーム」に変えること

DevOpsの核心的な価値

自動化 — 反復作業（ビルド、テスト、デプロイ、インフラ構成）を自動化して人為的ミスを減らします。
可視性 — 開発者もプロダクション環境のメトリクス、ログ、エラーを直接見ることができ、問題を素早く把握します。
フィードバックループ — デプロイ後のユーザー反応とシステム状態を素早く確認し改善します。
小さな単位でのデプロイ — 大きな変更を一度にデプロイする代わりに、小さな変更を頻繁にデプロイしてリスクを減らします。

なぜクラウドでDevOpsなのか

オンプレミスではサーバー購入に数週間かかり、環境構成が手動のため自動化が困難です。クラウドはDevOpsを実現するための最適な環境です。

インフラをコードで — APIでインフラを作成/削除できるためIaCが可能です。
環境の複製 — プロダクションと同一のテスト環境を数分以内に作成できます。
マネージドサービス — CI/CD、モニタリング、ロギングを自前で構築しなくても済みます。
従量課金制 — テスト環境を使用するときだけ起動し、終わったら削除してコストを削減します。

GitOps

GitOpsは、DevOpsの実践方法の一つで、Gitリポジトリをインフラとアプリケーションの単一の真実の情報源（Single Source of Truth）として使用します。特にKubernetes環境において標準的なデプロイ方式として定着しています。K8sの宣言的マニフェスト（YAML）と、GitOpsの「Gitに宣言された状態＝クラスタの状態」という哲学が自然に合致するためです。

インフラ/アプリの変更 = Gitにコミット → エージェントが検知 → クラスタに自動反映
ロールバック = Gitヒストリーから以前のコミットに戻す
監査 = Gitログがそのまま変更履歴
ドリフト検知 = クラスタの状態がGitと異なれば自動復旧

プラットフォームエンジニアリング

DevOpsが成熟すると、開発者が直接インフラを扱うことがかえって負担になります。プラットフォームエンジニアリングは、開発者がセルフサービスでインフラを利用できるように内部プラットフォームを構築することです。

開発者: 「デプロイボタン一つでプロダクションに上げたい」
プラットフォームチーム: CI/CD、モニタリング、セキュリティを抽象化した内部プラットフォームを提供

開発者は本来の業務（コード作成）に集中し、プラットフォームチームは安全で効率的なデプロイ経路を提供します。

開発者が運用に参加すると良い点

障害対応速度 — コードを書いた人がログを見れば、原因を最も早く把握できます。
設計品質の向上 — 運用の負担を直接感じることで、運用しやすいコードを書くようになります。
フィードバック速度 — デプロイ後にメトリクスを直接確認することで、改善の方向を素早くつかめます。

SLI、SLO、エラーバジェット

DevOps/SREにおいて「サービスが十分に安定しているか？」を体系的に定義するフレームワークです。SLI（測定指標）→ SLO（目標値）→ SLA（契約）の関係で構成され、エラーバジェットによってデプロイ速度と安定性のバランスを取ります。

AIエンジニアリングとDevOps (MLOps / LLMOps)

生成AIや従来型MLモデルが現代のクラウドアプリケーションの中核要素となるにつれ、既存のコードデプロイパイプライン(DevOps)だけでなく、データセット、プロンプトテンプレート、モデル評価を自動化するMLOps / LLMOpsとの有機的な統合が不可欠になっています。

よくある間違い

「DevOpsチーム」を作っておいて既存のサイロを維持 — DevOpsは文化であり、チーム名ではありません。開発チームと運用チームの間にもう一つの壁ができるだけです。
自動化なしでツールだけ導入 — Jenkins/ArgoCDをインストールしても、手動承認・手動デプロイが残っていれば効果がありません。反復作業から自動化してください。
プロダクションと異なるテスト環境で検証 — 環境の違いによる障害が繰り返されます。IaCで同一環境を複製してください。

チェックリスト

コードコミットからプロダクションデプロイまで自動化されたパイプラインが存在するか？
開発者がプロダクションのメトリクスとログを直接確認できるか？
デプロイ頻度、リードタイム、変更失敗率、復旧時間（DORA 4 Metrics）を測定しているか？