本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第1弾として、開発・運用アーキテクチャの全体像について解説する記事です。
「作る仕組み（構成管理・CI/CD・テスト・レビュー・開発環境）」と「動かし続ける仕組み（監視・ログ・SLO・インシデント・SRE）」をひとつながりのライフサイクルとして扱います。DevOps と SRE の普及で開発と運用の境界は消え、別の仕事として設計するのはもう古いのが2026年の前提です。本記事はカテゴリ全16記事の全体地図として機能します。
このカテゴリの全記事一覧・各記事で学べるポイントは以下のページにまとめています。
本記事のテーマについてさらに詳しく知りたい方は『ITアーキテクチャのセオリー』も参考にしてみてください。
そもそも開発運用アーキテクチャとは何か
工場の生産ラインを想像してください。製品を設計する部門と、生産ラインを動かし続ける部門が完全に分離していたら、「設計通りに作れない」「ラインが止まっても設計部門は知らない」という問題が頻発します。両者を一本のラインとして統合するのが現代の工場経営です。
開発運用アーキテクチャも同じ発想です。コードを書く仕組み（構成管理・CI/CD・テスト・レビュー）と、動かし続ける仕組み（監視・ログ・SLO・インシデント対応）をひとつながりのライフサイクルとして設計する領域です。
もし開発と運用がバラバラなら、リリースのたびに「出したい開発」対「止めたい運用」の綱引きが発生し、障害時には責任の押し付け合いが繰り返されます。
なぜ開発と運用を一体で設計するのか
同じコードが開発から本番まで一直線で流れる
構成管理 → CI → デプロイ → 監視までが単一のパイプラインで繋がっています。どこで切っても、片側だけ最適化する意味がないと言えるほどに一体化しているのが現代のソフトウェアです。
同じ指標で評価する時代になった
DORAの4指標（デプロイ頻度・リードタイム・MTTR・変更失敗率）は、開発スピードと運用安定性を同じ式で測ることを前提にしています。片方だけ改善しても、数値は動きません。
AI時代は「コードで運用」が前提
IaC・GitOps（Git を起点に運用を自動化）が主戦場になり、運用は開発と同じスキルセットで回ります。手動 SSH で設定ファイルをいじる運用は、AI 時代には負債です。
「開発」と「運用」の二分法は、組織図の残像。実務ではもう一本の川になっています。
この章で扱うライフサイクル全体
この章は左から右へ読むと、1つのアプリケーションが「コードになって、届いて、動き続ける」までの全工程が並んでいます。各記事は単独でも読めますが、DevOps・SREの全体像 を最初に通すと、なぜこの並びなのかが腑に落ちます。
なぜこの順番なのか
全15記事は4つのフェーズ＋2つの横断テーマに分かれています。
- 開発フェーズ（構成管理→開発環境→レビュー→テスト→CI）：コードを書いて品質を担保するまでの流れ
- リリースフェーズ（デプロイ戦略）：品質を担保されたコードを本番へ届ける
- 運用フェーズ（監視→ログ→SLO→インシデント対応）：本番で動き続ける仕組み
- 継続改善フェーズ（SREプラクティス）：運用の知見を開発に還元し、サイクルを回す
- 横断テーマ（ドキュメンテーション・チケット管理）：全フェーズを貫くプロセス基盤
この4フェーズは一方通行ではなく循環しています。運用で見つかった問題が開発に戻り、SREプラクティスが開発プロセスを改善する。DORA 4指標は、この循環の速度と品質を同じ式で測るための道具です。
記事の並び
| 記事 | 扱う段階 |
|---|---|
| DevOps・SREの全体像 | 章全体の地図 |
| 構成管理 | Git・ブランチ戦略 |
| 開発環境とローカル実行 | 開発者体験 |
| コードレビュー | PR 運用 |
| テスト設計 | 自動テスト戦略 |
| CICD | パイプライン設計 |
| デプロイ戦略 | Canary・Blue-Green |
| 監視とオブザーバビリティ | メトリクス・トレース |
| ログ設計 | 構造化ログ |
| SLOとSLI | 信頼性目標 |
| インシデント対応 | オンコール・ポストモーテム |
| SREプラクティス | 継続改善・Toil 削減 |
| ドキュメンテーション | 横断・長寿命 |
| チケット・プロジェクト管理 | 横断・意思決定 |
決めるべきこと①：開発プロセス系
| 項目 | 選択肢の例 |
|---|---|
| Gitホスティング | GitHub・GitLab・Bitbucket |
| ブランチ戦略 | GitHub Flow・Trunk Based・GitFlow |
| CI/CD | GitHub Actions・GitLab CI・CircleCI |
| テストピラミッド | 単体／結合／E2E の比率 |
| レビュー方針 | 2人承認・CODEOWNERS・マージキュー |
| 開発環境 | Docker Compose・Dev Container・クラウドIDE |
| ドキュメント置き場 | リポジトリ内 md・Notion・Confluence |
決めるべきこと②：運用系
| 項目 | 選択肢の例 |
|---|---|
| 監視ツール | Prometheus・Datadog・New Relic |
| ログ基盤 | CloudWatch Logs・Loki・Splunk |
| 分散トレース | OpenTelemetry・Jaeger・X-Ray |
| SLO/SLI定義 | 可用性99.9%・p99（遅い方から1%を除いた応答時間）レイテンシ等 |
| アラート条件 | 静的閾値／異常検知／SLOバーンレート |
| 通知先 | PagerDuty・Slack・Opsgenie |
| オンコール体制 | 24/7・営業時間のみ・週次ローテ |
| エラーバジェット運用 | 超過時にリリース凍結するか |
決めるべきこと③：リリース・横断系
| 項目 | 選択肢の例 |
|---|---|
| デプロイ戦略 | Blue-Green・Canary・ローリング |
| Feature Flag | LaunchDarkly・Unleash・自前 |
| ロールバック方針 | 自動・手動・不可 |
| バックアップ | 頻度・保存期間・世代管理 |
| リストア訓練 | 年次・四半期・月次 |
| 容量計画 | 自動スケール・手動見直し |
| チケット運用 | Jira・Linear・GitHub Projects |
サービス種別×成熟度の段階表
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
開発・運用の投資水準はサービス種別で大きく変わるのが実務の姿です。MVP に金融並みの SRE を敷くのも、決済システムに手動デプロイを残すのも、どちらも事故のもとです。
| サービス種別 | SLO | デプロイ | 監視 | オンコール | 年間運用コスト |
|---|---|---|---|---|---|
| 社内ツール | 99% | 手動 or 軽い CD | CloudWatch 標準 | 業務時間のみ | 数万円 |
| 一般B2C Web | 99.9% | CD 自動 + Canary | Datadog 無料枠 / Grafana Cloud | 兼任2〜3名 + PagerDuty | 数十万円 |
| B2B SaaS | 99.95% | 日複数回 / Feature Flag | Datadog / New Relic | 専任SRE 2〜3名 | 数百万円 |
| 金融・決済 | 99.99% | 段階リリース厳格 | SIEM + UEBA + APM | 24/7 SRE + SOC | 数千万円〜 |
| 通信・電力 | 99.999% | 四半期・年次 | エンタープライズ統合基盤 | Follow-the-Sun | 数億円〜 |
可用性 99.9% と 99.99% では構築コストが数倍違うのが実務の感覚です。業務部門と数値で合意しない限り、「できるだけ高く」は破産への道です。100%は目標ではない、これが章全体を貫く思想です。
SLO は業務部門と数値で合意するもの。「止まらない」という言葉では永遠に噛み合いません。
運用設計の3本柱
運用を支える中核は 監視・ログ・分散トレース の3つで、これを統合して扱う考え方が オブザーバビリティ（Observability＝未知の問題を後から調査できる状態にする設計思想）です。どれか1つでも欠けるとシステムはブラックボックスになります。
| 柱 | 役割 | 代表ツール |
|---|---|---|
| 監視（Monitoring） | 数値で状態を可視化 | Prometheus・Datadog・CloudWatch |
| ログ（Logging） | 出来事を文字で記録 | Loki・Splunk・CloudWatch Logs |
| 分散トレース（Tracing） | リクエストの経路を追跡 | Jaeger・Tempo・X-Ray |
現在の標準は OpenTelemetry（監視データの標準仕様）で統一送信し、Grafana や Datadog で横串で見るパターンです。ツール選定より、計装を標準化することが最初の分岐点になります。
SREの核心 — 「壊れてよい量」を数値で合意する
SRE の中核は、SLOと エラーバジェット（SLO を守れる範囲の「壊してよい量」）の2つに尽きます。SLO を「月間可用性 99.9%」と定めれば、月に約43分は止まってよい計算になり、その時間がエラーバジェットです。
予算の範囲内ならリリースを攻め、超過したらリリース凍結して安定化に集中する──これが「速度と信頼性を同じ指標で回す」SRE のやり方です。
| 概念 | 意味 |
|---|---|
| SLI | 実測値（応答時間・成功率など） |
| SLO | 内部で合意した目標値 |
| SLA | 顧客との契約（未達で補償発生） |
| エラーバジェット | SLO を守れる範囲で「壊してよい量」 |
100%可用性は不可能。数値で合意して、開発速度と信頼性をトレードオフする──これが SRE 思想の核心です。
DORA 4指標 — チームの健康診断
Google の DevOps Research & Assessment が、強いチームと弱いチームの差を4つの数値に絞って示したのが DORA です。開発速度と運用安定性を同じ式で測る、というのがこの章を束ねる思想の根拠になっています。
| 指標 | Elite（上位10%） | Low |
|---|---|---|
| デプロイ頻度 | 日に複数回 | 月1未満 |
| 変更リードタイム | 1時間未満 | 1ヶ月超 |
| MTTR（平均復旧時間） | 1時間未満 | 1ヶ月超 |
| 変更失敗率 | 0〜15% | 46〜60% |
詳細と改善の優先順位は次の記事「DevOps・SREの全体像」で扱います。この章の各記事は、どれかのDORA指標を動かすためのピースとして読むのが実践的です。
やってはいけないこと
各論記事で触れた禁じ手のうち、章レベルで押さえるべき核心をまとめます。
| 禁じ手 | なぜダメか |
|---|---|
| 監視・ログを後から追加 | 障害時に原因特定不能、数日の手探り |
| 静的閾値（CPU 80%）だけでアラート | 負荷変動で誤検知、SLO バーンレートに切り替え |
| 100%可用性を目標化 | コスト無限大、エラーバジェットで速度を買う |
| ベテラン1人で障害対応 | 退職時に崩壊、Runbook のコード化は必須 |
| ポストモーテムで犯人探し | 情報隠蔽、Blameless（非難しない）が鉄則 |
| Feature Flagなしで大規模リリース | Knight Capital 2012年（45分で4.4億ドル損失）のパターン |
| DB変更とコードデプロイを同時 | expand/contract で分離、ロールバック可能に |
| SRE看板だけで手作業運用 | Toil 50%超は危険水域、手が変わらなければ SRE ではない |
| 開発チームが運用を知らないまま出荷 | 本番で初めて壊れる、オンコール参加が最短の教材 |
| CIを回すだけでゲートにしない | 落ちても merge できれば飾り、ブロッキングが前提 |
| 「開発プロセスは現場が自由に決めればいい」と放任 | 人を増やすほど事故が増える逆相関に陥る |
| 「障害はゼロにできるはず」と完璧を追う | MTTRの短縮に投資する方が信頼性も経済性もよくなる |
開発・運用は「作り終わった後」ではなく「作り始める前」に決めるもの。後付けは10倍コストです。
AI判断軸
| AI有利 | AI不利 |
|---|---|
| 構造化ログ（JSON）・OpenTelemetry | 人間向けの自然文ログ |
| IaC／GitOps で宣言的に管理 | 手動SSHでの運用作業 |
| Runbook が Markdown で Git 管理 | Confluence・口伝で散在 |
| Prometheus・標準メトリクス | 独自の監視スキーマ |
- 開発プロセスと運用を一体で設計する — DORAで同じ式で測れる
- 監視・ログ・SLOを最上流で決める — 後付けは10倍コスト
- SLOとエラーバジェットで速度と信頼性を合意 — 100%は目標ではない
- 機械可読な運用データを作る — 構造化ログ／IaC／Markdownランブック
機械可読な運用データがAI活用の前提条件
AIに運用タスクを任せるには、AIが読める形式でデータが存在する必要があります。具体的には構造化ログ（JSON）・IaCコード・Markdownのランブック・OpenTelemetryのメトリクスです。これらがすべてGitやAPIで取得可能な状態であれば、AIは障害検知→原因特定→復旧提案→実行の一連を自動化できます。
逆に、手順書がConfluenceの画像付きページやSlackの過去ログにしか存在しない場合、AIはそれを参照できません。DevOps設計の段階で「すべてのプロセスと知識をコードまたは構造化テキストで管理する」と決めることが、AI時代の運用自動化への最短路です。
DORA指標の改善をAIが直接支援する
デプロイ頻度・変更リードタイム・変更失敗率・MTTR（平均復旧時間）の4指標は、CIパイプラインとGitログから自動計測できます。AIはこれらの指標を解析し、「プルリクエストのサイズが大きい週はデプロイ頻度が落ちている」「特定のサービスの変更失敗率が高い」といったパターンを検出して改善提案を出せます。
筆者メモ — 「監視なし」と「DevOpsチーム」、どちらも地雷
運用現場でよく語られる典型事例を2つ紹介します。
1つ目は監視なし運用。監視もメトリクスもない本番環境を引き継ぎ、深夜の障害通知に SSH で潜って top と tail -f を勘で眺める、結局3時間手探りで原因特定、という話は珍しくありません。ダッシュボードがあれば5分で気づける問題に数時間かかるのは、運用設計を「後でやる」と決めた瞬間に確定する未来です。2017年2月の AWS S3 大規模障害（us-east-1）も、デバッグ作業でのコマンド打ち間違いで広範な SaaS が停止した典型例で、手動運用の地雷踏みを業界全体に突きつけた事件でした。
2つ目はDevOpsチーム地雷。専任の DevOps チームを立てて「DevOps 化」を掲げる組織は、数か月でほぼ確実に新しいサイロが生まれます。開発チームは「DevOps チームに任せた」、DevOps チームは「開発が CI を直してくれない」、結局壁が一つ増えただけ──という顛末は、業界でアンチパターンの代表格として知られます。DevOps は役割の再分配ではなく壁の解体の話で、ここを読み違えると本命の改善はまるで進みません。
どちらも「人に頼る」か「組織で解決しようとする」の二択で事故っていて、解はコードとプロセスで設計することに尽きます。
まとめ
本記事は開発・運用アーキテクチャの全体像について、開発と運用を一体で扱うDevOps/SRE・DORA 4指標・SLO+エラーバジェット・AI時代の機械可読な運用データまで含めて解説しました。如何だったでしょうか。
開発と運用を一体で設計し、監視・ログ・SLOを最上流で決め、エラーバジェットで速度と信頼性を合意し、機械可読な運用データを作る。これが2026年の開発・運用アーキテクチャの現実解です。
次回はDevOps・SREの全体像（DORA 4指標と組織戦略）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は DORA - DevOps Research and Assessment も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（54/89）