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

本記事について

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

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

このカテゴリの他の記事

開発と運用をひとつに束ねる理由

同じコードが開発から本番まで一直線で流れる

構成管理 → CI → デプロイ → 監視までが単一のパイプラインで繋がっています。どこで切っても、片側だけ最適化する意味がないと言えるほどに一体化しているのが現代のソフトウェアです。

同じ指標で評価する時代になった

DORA（DevOps Research and Assessment＝Google が発表している開発チーム調査）の4指標（デプロイ頻度・リードタイム・MTTR・変更失敗率）は、開発スピードと運用安定性を同じ式で測ることを前提にしています。片方だけ改善しても、数値は動きません。

AI時代は「コードで運用」が前提

IaC（Infrastructure as Code＝インフラをコードで定義）・GitOps（Git を起点に運用を自動化）が主戦場になり、運用は開発と同じスキルセットで回ります。手動 SSH で設定ファイルをいじる運用は、AI 時代には負債です。

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

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

flowchart TB
    subgraph DEV["開発"]
        VCS[構成管理] --> ENV[開発環境] --> REV[コードレビュー] --> TEST[テスト] --> CI[CI]
    end
    subgraph REL["リリース"]
        DEPLOY[デプロイ戦略]
    end
    subgraph OPS["運用"]
        OBS[監視・<br/>Observability] --> LOG[ログ] --> SLO[SLO/SLI] --> INC[インシデント対応]
    end
    subgraph IMP["継続改善"]
        SRE[SREプラクティス]
    end
    subgraph CROSS["横断"]
        DOC[ドキュメンテーション]
        TICKET[チケット運用]
    end
    DEV --> REL --> OPS --> IMP
    CROSS -.-> DEV
    CROSS -.-> OPS
    classDef dev fill:#dbeafe,stroke:#2563eb;
    classDef rel fill:#fef3c7,stroke:#d97706;
    classDef ops fill:#fae8ff,stroke:#a21caf;
    classDef imp fill:#dcfce7,stroke:#16a34a;
    classDef cross fill:#f0f9ff,stroke:#0369a1;
    class DEV,VCS,ENV,REV,TEST,CI dev;
    class REL,DEPLOY rel;
    class OPS,OBS,LOG,SLO,INC ops;
    class IMP,SRE imp;
    class CROSS,DOC,TICKET cross;

この章は左から右へ読むと、1つのアプリケーションが「コードになって、届いて、動き続ける」までの全工程が並んでいます。各記事は単独でも読めますが、DevOps・SREの全体像 を最初に通すと、なぜこの並びなのかが腑に落ちます。

記事の並び

記事	扱う段階
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（Service Level Objective＝内部で合意した信頼性目標）と エラーバジェット（SLO を守れる範囲の「壊してよい量」）の2つに尽きます。SLO を「月間可用性 99.9%」と定めれば、月に約43分は止まってよい計算になり、その時間がエラーバジェットです。

予算の範囲内ならリリースを攻め、超過したらリリース凍結して安定化に集中する──これが「速度と信頼性を同じ指標で回す」SRE のやり方です。

概念	意味
SLI（Service Level Indicator）	実測値（応答時間・成功率など）
SLO（Service Level Objective）	内部で合意した目標値
SLA（Service Level Agreement）	顧客との契約（未達で補償発生）
エラーバジェット	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 できれば飾り、ブロッキングが前提

開発・運用は「作り終わった後」ではなく「作り始める前」に決めるもの。後付けは10倍コストです。

AI時代の視点

AI 駆動開発が前提になると、この領域はAIが読み書きできる形で整っているかどうかが、もうひとつの実力差になります。構造化ログ・IaC / GitOps・Markdown のランブックが揃っていれば、AI エージェントが障害解析のファーストレスポンダーとして機能します。逆に Confluence に口伝で散らばった運用知識や、人間向けの自然文ログは、AI 時代に急速に負債化します。

AI時代に有利	AI時代に不利
構造化ログ（JSON）・OpenTelemetry	人間向けの自然文ログ
IaC / GitOps で宣言的に管理	手動SSHでの運用作業
Runbook が Markdown で Git 管理	Confluence・口伝で散在
Prometheus・標準メトリクス	独自の監視スキーマ
PR・Issue が意思決定の履歴	Slack スレッドに議事が流れる

AI が読めるログを書く。AI が実行できるランブックを書く。次世代の運用は、そこから始まります。

よくある勘違い

この章は誤解されやすい領域が多く、特に非エンジニア職から見ると「作る人の話」と「運用する人の話」が混ざっているように見えます。代表的な誤解を整理します。

開発プロセスは現場が自由に決めればいい

ブランチ戦略・PR 運用・CI ゲートが整備されていないチームは、人を増やすほど事故が増える逆相関に陥ります。アーキテクトが設計する対象です。

監視・ログは後から足せばよい

後付けすると必要なイベントが記録されていないため、障害時に数日の手探りが発生します。設計段階で決めるのが10倍安い、と覚えておきます。

100%の可用性を目指すべき

100% は物理的に不可能で、目指すこと自体がコスト無限投資を招きます。SLO（例：99.9%）を定めて「壊れてよい量」を工学管理するのが SRE の核心です。

障害はゼロにできるはず

障害はゼロにできません。MTTR（Mean Time To Recovery＝平均復旧時間）の短縮に投資するほうが、結果として信頼性も経済性も良くなります。

DevOpsとは専任の「DevOpsチーム」を作ること

逆効果です。DevOps は開発と運用の壁を壊す文化であって、新しい壁を作る行為ではありません。専任チームを作った瞬間に DevOps は形骸化します。

「作り終わった後ではなく作り始める前」に決める。それが章全体の鉄則です。

筆者メモ — 「監視なし」と「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 は役割の再分配ではなく壁の解体の話で、ここを読み違えると本命の改善はまるで進みません。

どちらも「人に頼る」か「組織で解決しようとする」の二択で事故っていて、解はコードとプロセスで設計することに尽きます。

最終的な判断の仕方

開発・運用アーキテクチャで問われているのは作って届けて動かし続ける一本の流れを、アーキテクトが引き受けるかどうかです。開発プロセスを現場任せにしたり、監視・ログを後付けしたりすると、片側だけ最適化して反対側が崩れる事故が必ず起きます。DORA の4指標が開発と運用を同じ式で測ることを前提にしている通り、この領域は一体で設計するほかないと割り切るのが実務的な出発点です。

もう一つの軸は、AIが読み書きできる形に揃えること。構造化ログ・IaC / GitOps・Markdown のランブックが揃っていれば、AI エージェントは障害解析のファーストレスポンダーとして機能します。逆に Confluence に散らばった口伝知識や自然文ログは、AI 時代に急速に負債化します。

選定の優先順位

1. 開発プロセスと運用を一体で設計する — DORA で同じ式で測れる
2. 監視・ログ・SLOを最上流で決める — 後付けは10倍コスト
3. SLOとエラーバジェットで速度と信頼性を合意 — 100% は目標ではない
4. 機械可読な運用データを作る — 構造化ログ／IaC／Markdown ランブック

「作って届けて動かし続ける」、その一本の流れをアーキテクトが引き受ける、それが本質です。

まとめ

本記事は開発・運用アーキテクチャの全体像について、開発と運用を一体で扱うDevOps/SRE・DORA 4指標・SLO+エラーバジェット・AI時代の機械可読な運用データまで含めて解説しました。如何だったでしょうか。

開発と運用を一体で設計し、監視・ログ・SLOを最上流で決め、エラーバジェットで速度と信頼性を合意し、機械可読な運用データを作る。これが2026年の開発・運用アーキテクチャの現実解です。

次回はDevOps・SREの全体像（DORA 4指標と組織戦略）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

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