---
title: 金曜日にデプロイできますか？ CI/CDで変わる 開発組織の意思決定
tags: 
author: [CircleCI Japan](https://image.docswell.com/user/circleci-japan)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/57G1DLYXEL.jpg?width=480
description: https://circleci.connpass.com/event/383177/
published: February 18, 26
canonical: https://image.docswell.com/s/circleci-japan/K1QNYL-2026-10-28-141328
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/57G1DLYXEL.jpg)

金曜日にデプロイできますか？
CI/CDで変わる
開発組織の意思決定
岡本 秀高 ( @hidetaka_dev )
Senior Field Engineer
1


# Page. 2

![Page Image](https://bcdn.docswell.com/page/4EQD1YM5JP.jpg)

>Agenda
今日のゴール:
リリースが「怖いイベント」ではない組織になる
1.
2.
3.
4.
5.
6.
金曜デプロイにおける「怖さ」の正体
開発負荷を増やさずにデプロイ頻度を増やす方法
リリースとロールバックから始めるDevOps Demo
CI/CDを「投資」として評価する
生成AI によるCI / CD 効率化
まとめ
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/KJ4ZRWVV71.jpg)

自己紹介
Hidetaka Okamoto
(岡本秀高 )
● CircleCI Senior Field Engineer
● https://hidetaka.dev
● http://wp-kyoto.net
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/LE1RQY34EG.jpg)

金曜日のデプロイは
「やってはいけない」こと？
● 週末に障害が起きるかもしれない
● 週末は対応できる人が少ない
● 今の”健全な状態 ”を維持したい
● デプロイは慎重にやるべき
● みんな「そうしろ」と言っている
https://x.com/GithubProjects/status/1984174536892543217
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/GEW1MGPZ72.jpg)

「リリースは怖い・勇気のいる作業」と感じる人は多い
● デプロイして障害が起きたらどうしよう
● テストやチェックはこれで万全なのか？
● 何か見落としている点はないか？
● そういえばリリース作業誰がやる？
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/47ZPQLKLE3.jpg)

「リリースは怖い・勇気のいる作業」と感じる人は多い
● デプロイして障害が起きたらどうしよう
● テストやチェックはこれで万全なのか？
● 何か見落としている点はないか？
● そういえばリリース作業誰がやる？
58%
リリースに不安を感じる
開発者の割合
88%
リリースに不安を感じる
開発チームの割合
74%
不安からコードの更新を
回避することがあるチーム
https://info.sourcegraph.com/hubfs/CTA%20assets/sourcegraph-big-code-survey-report.pdf
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/YJ6M6WQM7V.jpg)

なぜリリースは「怖い作業」なのか？
● 何が起きるかわからない
→ 変更の量に比例して、リリース内容の把握や理解が困難に
● 問題が起きた時、どうすればいいかわからない
→ ロールバックの手順が不明確
● 慣れてないから、不安
→ 頻度が少ない & リリース作業が属人化しがち
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/GJ5Z6MRQE4.jpg)

リリースの怖さをどう軽減するか？
「リリースによる障害が怖い。
だからリリースの頻度や回数は減らしたほうが安心」
● 慎重にテストやリリース作業をやれば、安心してできるはずだ
● まとめてテストやリリースをすれば、効率も良いはずだ
● リリースの頻度を減らせば、障害件数や発生率も減るはずだ
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/9E2RM9DWJR.jpg)

リリースの怖さをどう軽減するか？
「リリースによる障害が怖い。
だからリリースの頻度や回数は減らしたほうが安心」
● 慎重にテストやリリース作業をやれば、安心してできるはずだ
● まとめてテストやリリースをすれば、効率も良いはずだ
● リリースの頻度を減らせば、障害件数や発生率も減るはずだ
実際には、障害発生率やリリース負荷が増加する
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/D7YDX4297M.jpg)

低頻度の大きなリリースが一番危険
“ 1つ目は、このアプローチでは...最後のリリースから多くの変更 が溜まると、
意図しない重大な不具合が発生 し、
大幅なリリース遅延を発生 させることに繋がる点です。ˮ
● １デプロイに含まれる変更が多くなる
● 変更量が増えると、バグ混入リスクも増加する
● 「どのコミットでバグが混ざったか」の特定や、
修正のための調査が大変になる
https://www.oreilly.co.jp//books/9784814400690/
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/VEN61Y8DE8.jpg)

リリース頻度を下げると、悪循環が発生しやすい
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/Y79L5PK8J3.jpg)

苦痛を見つける最良の方法は、
めったに行われない作業を探し出すことです。
例えば、 3か月に1回しかデプロイしないということは、
そこに苦痛があることを示すサインです。
— 『入門 継続的デリバリー』 294ページ
どうやってリリース頻度を増やせばいい？
https://www.oreilly.co.jp//books/9784814400690/
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/G78XYDRZED.jpg)

>Agenda
今日のゴール:
リリースが「怖いイベント」ではない組織になる
1.
2.
3.
4.
5.
6.
金曜デプロイにおける「怖さ」の正体
開発負荷を増やさずにデプロイ頻度を増やす方法
リリースとロールバックから始めるDevOps Demo
CI/CDを「投資」として評価する
生成AI によるCI / CD 効率化
まとめ
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/L7L84MK1JR.jpg)

開発の負荷を増やさずに、デプロイ頻度を増やす
● 「デプロイ回数を増やそう」だけでは、反発を産む
→ 「これ以上、開発チームに負担をかけられない」
● CD の本質は、開発チームの負担を減らすこと
→ 変えるものと変えないものを整理する
○ 変えないもの : 開発する量
○ 小さくするもの : デプロイの単位（ = バッチサイズ）
○ 結果的に増えるもの : デプロイの回数と頻度
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/4EM6KY257W.jpg)

Thank
you.
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/PERPX9MZ79.jpg)

バッチサイズを減らす開発方法
● コードだけを先行してデプロイする
○ 型定義や DTO / クラス / 関数など
○ TDDで開発し、「機能するコードであること」を保証する
● 本番の動きを変える変更は、最後に行う
○ UIの変更 / API への接続など
○ ユーザー向けのリリースデプロイを
できるだけ少ないコード差分で実現する
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/P7X36QV1EX.jpg)

もう一つのデプロイ方法
デプロイと
機能リリースの分離
● 通称: Feature Flag
● if文やDBで機能提供の
オンオフを制御
● コードをデプロイしても、
機能自体はリリースしない
● 「できたものからリリース」
できる体制を作るための仕組み
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/37KY19QMED.jpg)

継続的なデリバリー（ CD ）でリスクと苦痛を軽減する
デプロイは、誰もが恐れるイベントから、
日常のありふれた出来事になりました。
— 『入門 継続的デリバリー』 265ページ
●
CD は「デプロイの負担」を減らすための仕組み
→ 負担が減った結果として 、開発速度や量が自然と増加する
●
リリースの量（バッチサイズ）は小さく、頻度はより多く
→ 小さなリリースで、障害調査や切り戻しの負担を軽減する
●
いつでもリリースできる体制を目指すことで、
小さな改善や顧客の要望を迅速にデリバリーできるようにする
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/LJ39QWP2J5.jpg)

CircleCI: 世界最大規模
の
CI / CDプラットフォーム
Our mission:
世界中のだれもが、思い浮かんだアイデアを
すぐにソフトウェアとして配信できるように支援す
る
● 複数のリポジトリサービスに対応 :
GitHubやBitbucket / GitLabなどの複数サービスをサポート
● Pipeline/ Config as Code:
タスクの条件や定義を YAMLで管理。URLベースの共有にも対応
● 大規模な CI / CD活用を支援する機能群 :
CircleCIを
ご利用中のお客様（一部）
テスト分割や並列化 / パフォーマンス分析機能
SSHデバッグ / リトライやロールバック機能 / etc…
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/8JDG9KL6JG.jpg)

テストだけでなく
デプロイやロールバックも
●
マーカーを設定して
デプロイ状況を記録
●
ダッシュボードから
任意のバージョンにロールバック
特にインシデントのような状況では。スクリプトがどのよ
うに動作しているかを事前に理解したくないですよね。 <
中略> ロールバックしたいコミットハッシュを指定するだ
けで済むのは、本当に助かりました。
https://circleci.com/blog/how-perk-recovers-faster-with-centralized-rollbacks/
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/VEP3ZK4Z78.jpg)

セキュリティ要件などに応じて運用方法を決定
クラウド
サーバー
インスタンスのセットアップ、
セキュリティ、メンテナンスはすべてCircleCIが実施
ディベロッパー/
ユーザー
データベース
顧客が管理するネットワーク内に
顧客専用のCircleCIをセットアップ
ディベロッパー/
ユーザー
ビルドの
フリート
キャッシュ &
アーティファクト
VCS
（GitHub.com または
Bitbucket Cloud）
+
データベース
ビルドの
フリート
VCS
キャッシュ &
アーティファ クト
（GitHub.com または
GitHub Enterprise Server）
セルフホストランナー: 実行環境だけ顧客管理のネットワーク内に配置する
21


# Page. 22

![Page Image](https://bcdn.docswell.com/page/27V4WVXMEQ.jpg)

>Agenda
今日のゴール:
リリースが「怖いイベント」ではない組織になる
1.
2.
3.
4.
5.
6.
金曜デプロイにおける「怖さ」の正体
開発負荷を増やさずにデプロイ頻度を増やす方法
リリースとロールバックから始める DevOps Demo
CI/CDを「投資」として評価する
生成AI によるCI / CD 効率化
まとめ
22


# Page. 23

![Page Image](https://bcdn.docswell.com/page/5JG1DLVX7L.jpg)

>Agenda
今日のゴール:
リリースが「怖いイベント」ではない組織になる
1.
2.
3.
4.
5.
6.
金曜デプロイにおける「怖さ」の正体
開発負荷を増やさずにデプロイ頻度を増やす方法
リリースとロールバックから始めるDevOps Demo
CI/CDを「投資」として評価する
生成AI によるCI / CD 効率化
まとめ
23


# Page. 24

![Page Image](https://bcdn.docswell.com/page/47QD1Y65EP.jpg)

CI/CDへの投資をどう評価するか？
● ツールの便利さではなく、アウトカムで回答が必要
○ いくらかかるのか？
○ ROI はどのように測るのか？
● 予算を承認するためには「理由」が必要
○ できるだけすでにある契約の中でやりくりしたい
○ 主観的なメリットよりも、コストや数字での判断が優先される
24


# Page. 25

![Page Image](https://bcdn.docswell.com/page/KE4ZRW4VJ1.jpg)

DORA Four Keysでチームの現状を可視化する
* DORA DevOps Research Association ( https://dora.dev/ )
開発現場での課題
事業側の関心事
DORA Four keys
もしもの時に備える
インシデント
対応力
MTTR（復旧時間）
本番環境での障害から
回復するのにかかる時間
デプロイの怖さを減ら
す
品質・信頼性
変更障害率
デプロイが原因で
本番環境で障害が発生する割合
開発速度をより早く
市場投入速度
デプロイ頻度
変更リードタイム
本番環境へのリリースの頻度
commit からリリースまでの所要時間
課題を解決することで得られる outcomeを特定する
https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
25


# Page. 26

![Page Image](https://bcdn.docswell.com/page/L71RQY447G.jpg)

CI/CDによる改善の価値を計算する
CircleCI CEOによるブログ :https://circleci.com/ja/blog/business-value-of-software-delivery/
改善項目
ROI 計算式
計算例
( 10人チーム / 年収550万円想定)
ビルドや
デプロイ時間の
短縮
(現在の時間 - 目標時間)
× 実行数/日
× 開発者コスト/分
× 稼働日数
( 10分 - 5分 ) x 10回/日
x 50円/分
x 20日
= 500,000 円 / 月
変更障害率
(現在のMTTR - 目標MTTR)
× 失敗率
× 実行数/日
× 開発者コスト/分
× 稼働日数
( 30分 - 15分 ) x 5%
x 10回/日
x 50円/分
x 20日
= 150,000 円 / 月
(現在の失敗率 - 目標失敗率)
× スループット/日
× ビルドコスト
× 稼働日数
(20% - 5%) × 10回/日
× ¥2,500
× 20日
= ¥75,000 / 月
ビルド成功率
ビルドの高速化
ビルド成功率改善
障害発生率削減
月間725,000円
年間約870万円
のコスト削減
26


# Page. 27

![Page Image](https://bcdn.docswell.com/page/G7W1MGXZJ2.jpg)

計測し、ベンチマークと比較する
https://circleci.com/software-delivery-data-explorer/
27


# Page. 28

![Page Image](https://bcdn.docswell.com/page/4JZPQL6L73.jpg)

2つの指標で多視点から可視化する
DORA Four Keys
CI / CD 操作指標
視点
インシデント
対応力
MTTR（復旧時間）
指標の性質
遅行指標
プロセス指標
用途
定期的な診断
調査すべき仮説を立てるための指標
プロセスのボトルネックを特定する
DevOps / CI・CD施策の効果測定
DORA Four Keys → CI / CD指標で調査
CI / CD指標を改善すると、 DORA Four Keysが動き出す
https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
28


# Page. 29

![Page Image](https://bcdn.docswell.com/page/YE6M6W2MJV.jpg)

経営には数字を
現場にはストーリーを
●
CI / CDで改善のサイクルを回す
効率化によるコスト最適化
→ 障害による損失リスク
→ 手戻りや調査による非効率
●
現場の不安や摩擦を解消する
→ リリースが怖くなくなる
→ 大小の改善を高頻度に
29


# Page. 30

![Page Image](https://bcdn.docswell.com/page/GE5Z6M2Q74.jpg)

>Agenda
今日のゴール:
リリースが「怖いイベント」ではない組織になる
1.
2.
3.
4.
5.
6.
金曜デプロイにおける「怖さ」の正体
開発負荷を増やさずにデプロイ頻度を増やす方法
リリースとロールバックから始めるDevOps Demo
CI/CDを「投資」として評価する
生成AI によるCI / CD 効率化
まとめ
30


# Page. 31

![Page Image](https://bcdn.docswell.com/page/972RM94WER.jpg)

安心したデプロイのためにできること
AIによる開発の発達と
品質やセキュリティへの懸念
● コードの作成や提案の高速化
● 単純作業やテスト生成の効率化
vs
● レビューコストの増加
● 脆弱性やハルシネーションリスク
https://circleci.com/ja/blog/risks-rewards-generative-ai/
31


# Page. 32

![Page Image](https://bcdn.docswell.com/page/DJYDX4M9JM.jpg)

テストの修正や不具合が
起きた時の対応も全部、
生成AIがやってくれたらいいのに
32


# Page. 33

![Page Image](https://bcdn.docswell.com/page/V7N61YWD78.jpg)

Intelligent summaries によるエラーログ解析
https://qiita.com/CircleCIJapan/items/5683e63ea28fbaf3f7fe
33


# Page. 34

![Page Image](https://bcdn.docswell.com/page/YJ9L5PX8E3.jpg)

Open Preview
自律型 AI エージェント
Chunk
● CI / CDパイプラインを監視
● 不安定な ( Flaky )テストを検知
テストを修正する PR を作成
● CircleCIを使った PR の自動検証
● アドホックな
コーディングタスクにも対応
34


# Page. 35

![Page Image](https://bcdn.docswell.com/page/GJ8XYD2Z7D.jpg)

ChunkでCIエラーの調査と修正を一気通貫
https://qiita.com/CircleCIJapan/items/5683e63ea28fbaf3f7fe
35


# Page. 36

![Page Image](https://bcdn.docswell.com/page/LJL84M21ER.jpg)

Closed Preview
効率的なテスト実行計画を自動的に作成
Smarter Testing
テスト実行対象を自動選択
●
●
変更内容を分析して
必要なテストのみを実行
選択した理由なども分析可能
並列テストの実行時間最適化
●
●
並列実行するテストの
実行時間を平均化
後続のジョブ開始時間を短縮
36


# Page. 37

![Page Image](https://bcdn.docswell.com/page/47M6KY85JW.jpg)

CI/ CD のROIを
ROI Calculator で
計算してみよう
●
開発チームの現状を入力する
○
人数 / ビルド回数
https://circleci.com/autonomous-validation-roi/
○
●
実行時間 / MTTR
10人チーム、 1ビルド/日
WF10 分、復旧 60分の場合
○
月94時間の短縮
○
人件費ベース
約400万円 / 年
37


# Page. 38

![Page Image](https://bcdn.docswell.com/page/P7RPX95ZJ9.jpg)

>Agenda
今日のゴール:
リリースが「怖いイベント」ではない組織になる
1.
2.
3.
4.
5.
6.
金曜デプロイにおける「怖さ」の正体
開発負荷を増やさずにデプロイ頻度を増やす方法
リリースとロールバックから始めるDevOps Demo
CI/CDを「投資」として評価する
生成AI によるCI / CD 効率化
まとめ
38


# Page. 39

![Page Image](https://bcdn.docswell.com/page/PJX36QK17X.jpg)

リリースを
『怖いイベント』にしない
●
CI / CDで改善のサイクルを回す
金曜デプロイの恐怖は、
安定したリリースができない兆候
●
開発量は増やさない。
バッチサイズの縮小と
リリース頻度の増加で不安を解消
●
ツールのコストではなく
そのWFで発生するコストを見る
39


# Page. 40

![Page Image](https://bcdn.docswell.com/page/3JKY195M7D.jpg)

まずは現状のチェックから
Step 1：
Four Keysで現状を測る
コミットから本番リリースまでの時
間、障害からの復旧時間を計測す
Step 2：
ボトルネックを特定する
• MTTRが⻑い：ロールバック⼿順の不備
• 変更障害率が⾼い：テスト不⾜‧環境差分
る。まず可視化するだけで、どこに
問題があるかが⾒えてくる。
Step 3：
改善効果を数字で⾒積
「ビルド時間の短縮」「障害対応時
間の削減」を⽉額‧年額で試算し、
• リードタイムが⻑い：⼿動作業‧レビュー
投資判断の材料にする。
遅延
40


# Page. 41

![Page Image](https://bcdn.docswell.com/page/LE39QWK2E5.jpg)

学習リソースとコミュニティ
さらに学ぶための情報源
●
●
公式ドキュメント
https://www.oreilly.co.jp//books/9784814400690/
https://circleci.com/docs
実装順序の指針
レガシー環境への適用
シグナル設計の原則
etc..
ROI Calculator:
自社の状況でコスト削減効果を試算
https://circleci.com/autonomous-validation-roi/
●
2025 State of Software Delivery Report
最新の業界データとインサイト
https://circleci.com/resources/2025-state-of-softw
are-delivery/
●
入門 継続的デリバリー
CircleCI の「How」だけでなく
CI/CD の「Why」を学べる
Twitter: CircleCIJapan
41