概要 ― 作って届けて動かし続ける一本の流れ ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第1弾として、開発・運用アーキテクチャの全体像について解説する記事です。

「作る仕組み（構成管理・CI/CD・テスト・レビュー・開発環境）」と「動かし続ける仕組み（監視・ログ・SLO・インシデント・SRE）」をひとつながりのライフサイクルとして扱います。DevOpsとSREの普及で開発と運用の境界は消え、別の仕事として設計するのはもう古いのが2026年の前提です。本記事はカテゴリ全16記事の全体地図として機能します。

このカテゴリの全記事一覧・各記事で学べるポイントは以下のページにまとめています。

開発運用アーキテクチャ（DevOps/SRE）記事一覧 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-index-devops/

本記事のテーマについてさらに詳しく知りたい方は『ITアーキテクチャのセオリー』も参考にしてみてください。

そもそも開発運用アーキテクチャとは何か

工場の生産ラインを想像してください。製品を設計する部門と、生産ラインを動かし続ける部門が完全に分離していたら、「設計通りに作れない」「ラインが止まっても設計部門は知らない」という問題が頻発します。両者を一本のラインとして統合するのが現代の工場経営です。

開発運用アーキテクチャも同じ発想です。コードを書く仕組み（構成管理・CI/CD・テスト・レビュー）と、動かし続ける仕組み（監視・ログ・SLO・インシデント対応）をひとつながりのライフサイクルとして設計する領域です。

もし開発と運用がバラバラなら、リリースのたびに「出したい開発」対「止めたい運用」の綱引きが発生し、障害時には責任の押し付け合いが繰り返されます。

なぜ開発と運用を一体で設計するのか

第一に、同じコードが開発から本番まで一直線で流れるからです。構成管理→CI→デプロイ→監視までが単一のパイプラインで繋がっており、どこで切っても片側だけ最適化する意味がないと言えるほど一体化しているのが現代のソフトウェアです。

第二に、同じ指標で評価する時代になったからです。DORAの4指標（デプロイ頻度・リードタイム・MTTR・変更失敗率）は、開発スピードと運用安定性を同じ式で測ることを前提にしています。片方だけ改善しても数値は動きません。

第三に、AI時代は「コードで運用」が前提だからです。IaC・GitOps（Gitを起点に運用を自動化）が主戦場になり、運用は開発と同じスキルセットで回ります。手動SSHで設定ファイルをいじる運用は、AI時代には負債です。

「開発」と「運用」の二分法は組織図の残像で、実務ではもう一本の川になっています。

この章で扱うライフサイクル全体

この章は左から右へ読むと、1つのアプリケーションが「コードになって、届いて、動き続ける」までの全工程が並んでいます。全15記事は4つのフェーズ＋2つの横断テーマに分かれます。

• 開発フェーズ（構成管理→開発環境→レビュー→テスト→CI）：コードを書いて品質を担保するまでの流れ
• リリースフェーズ（デプロイ戦略）：品質を担保されたコードを本番へ届ける
• 運用フェーズ（監視→ログ→SLO→インシデント対応）：本番で動き続ける仕組み
• 継続改善フェーズ（SREプラクティス）：運用の知見を開発に還元し、サイクルを回す
• 横断テーマ（ドキュメンテーション・チケット管理）：全フェーズを貫くプロセス基盤

この4フェーズは一方通行ではなく循環しています。運用で見つかった問題が開発に戻り、SREプラクティスが開発プロセスを改善する。DORA 4指標は、この循環の速度と品質を同じ式で測るための道具です。

記事の並び

この章で決めること

各記事で詳しく扱いますが、決めるべき項目を先に一覧しておくと地図として機能します。

• 開発プロセス系：Gitホスティング（GitHub等）、ブランチ戦略（GitHub Flow / Trunk Based）、CI/CD（GitHub Actions等）、テストピラミッドの比率、レビュー方針（承認数・CODEOWNERS）、開発環境（Docker Compose / Dev Container）、ドキュメント置き場
• 運用系：監視ツール（Prometheus / Datadog）、ログ基盤、分散トレース（OpenTelemetry）、SLO/SLI定義、アラート条件（静的閾値かSLOバーンレートか）、通知先とオンコール体制、エラーバジェット運用
• リリース・横断系：デプロイ戦略（Blue-Green / Canary）、Feature Flag、ロールバック方針、バックアップとリストア訓練、容量計画、チケット運用（Jira / Linear / GitHub Projects）

こうした決定はADR（アーキテクチャ決定記録）として残す運用まで含めて、この章のテーマです。

サービス種別×成熟度の段階表

※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。

開発・運用の投資水準はサービス種別で大きく変わるのが実務の姿です。MVPに金融並みのSREを敷くのも、決済システムに手動デプロイを残すのも、どちらも事故のもとです。

可用性99.9%と99.99%では構築コストが数倍違うのが実務の感覚です。SLOは業務部門と数値で合意するもので、「できるだけ高く」「止まらない」という言葉では永遠に噛み合いません。

運用設計の3本柱とSREの核心

運用を支える中核は監視（数値で状態を可視化、Prometheus・Datadog）・ログ（出来事を文字で記録、Loki・CloudWatch Logs）・分散トレース（リクエストの経路を追跡、Jaeger・X-Ray）の3つで、これを統合して扱う考え方がオブザーバビリティ（未知の問題を後から調査できる状態にする設計思想）です。どれか1つでも欠けるとシステムはブラックボックスになります。現在の標準はOpenTelemetryで統一送信し、GrafanaやDatadogで横串で見るパターンで、ツール選定より計装を標準化することが最初の分岐点です。

SREの中核は、SLOとエラーバジェットの2つに尽きます。用語を整理すると、SLIは実測値（応答時間・成功率）、SLOは内部で合意した目標値、SLAは顧客との契約（未達で補償発生）、エラーバジェットはSLOを守れる範囲の「壊してよい量」です。SLOを「月間可用性99.9%」と定めれば月に約43分は止まってよい計算になり、予算の範囲内ならリリースを攻め、超過したらリリース凍結して安定化に集中する──100%可用性は不可能という前提で、開発速度と信頼性を数値でトレードオフするのがSRE思想の核心です。

DORA 4指標 — チームの健康診断

GoogleのDevOps Research & Assessmentが、強いチームと弱いチームの差を4つの数値に絞って示したのがDORAです。開発速度と運用安定性を同じ式で測る、というこの章を束ねる思想の根拠になっています。

詳細と改善の優先順位は次の記事「DevOps・SREの全体像」で扱います。この章の各記事は、どれかのDORA指標を動かすためのピースとして読むのが実践的です。

AI判断軸 ― 機械可読な運用データを作る

機械可読な運用データがAI活用の前提条件

AIに運用タスクを任せるには、AIが読める形式でデータが存在する必要があります。具体的には構造化ログ（JSON）・IaCコード・Markdownのランブック・OpenTelemetryのメトリクスです。これらがすべてGitやAPIで取得可能な状態であれば、AIは障害検知→原因特定→復旧提案→実行の一連を自動化できます。

逆に、手順書がConfluenceの画像付きページやSlackの過去ログにしか存在しない場合、AIはそれを参照できません。DevOps設計の段階で「すべてのプロセスと知識をコードまたは構造化テキストで管理する」と決めることが、AI時代の運用自動化への最短路です。

DORA指標の改善をAIが直接支援する

デプロイ頻度・変更リードタイム・変更失敗率・MTTRの4指標は、CIパイプラインとGitログから自動計測できます。AIはこれらの指標を解析し、「プルリクエストのサイズが大きい週はデプロイ頻度が落ちている」「特定のサービスの変更失敗率が高い」といったパターンを検出して改善提案を出せます。

やってはいけないこと

各論記事で触れる禁じ手のうち、章レベルで押さえるべき核心を6つに絞ります。

なお「障害はゼロにできるはず」と完璧を追うのも誤りです。MTTR（復旧の速さ）に投資する方が、信頼性も経済性も良くなります。

筆者メモ — 「監視なし」と「DevOpsチーム」、どちらも地雷

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 も合わせて参考にしてください。

それでは次の記事も閲覧いただけると幸いです。