開発プロセスにおける「狭義の自動化（Automation）」と「広義の自動化（生成AI）」

はじめに

AI活用の議論をしていると、「それは自動化と何が違うのか」「AIに任せるとはどこまでを指すのか」という点が曖昧なまま話が進み、認識がずれることがよくあります。

本記事では、自動化とAIの関係を概念的に整理したうえで、開発プロセスを例に「狭義の自動化 / AI / 人間」の3者がどこを担うのかを AS-IS / TO-BE で可視化してみます。チーム内で共通言語を作る際の叩き台として使える形を目指しました。

自動化とAIの違い:代替するものが「手順」か「判断」か

まず出発点として、自動化を広く定義します。

広義の自動化 = 人間の作業を機械に代替させること

この定義に立つと、AIは自動化と対立する概念ではなく、広義の自動化の一部です。違いは代替する作業の性質にあります。

• 手順の自動化(狭義の自動化):ルールが書ける作業の代替。決定論的で、同じ入力なら必ず同じ結果になる。例:cron、CI/CD、構成管理ツール、設定ファイルの自動生成
• 判断の自動化(AI):ルールが書ききれない作業の代替。確率論的で、文脈によって出力が変わる。例:異常検知、text-to-SQL、文書要約

特性比較

観点	手順の自動化	判断の自動化(AI)
動作原理	事前定義ルールの忠実な実行	学習パターンに基づく推論
再現性	同じ入力なら必ず同じ結果	文脈・確率により出力が揺れる
想定外への対応	できない(エラー・停止)	ある程度できる(ただし誤りうる)
結果の保証	テストで保証できる	保証できない(誤り前提の設計)
失敗時の設計	リトライ・アラート	検証・人間レビュー・フォールバック

なぜ呼び分けるかというと、設計思想がまるで違うからです。手順の自動化は「保証できる自動化」であり、確実性が求められる処理に使えます。AIは「保証できない自動化」であり、誤りを前提に検証やレビューを組み込む必要があります。

AIエージェントの中の自動化:レイヤー構造で捉える

ここで一つ疑問が生じます。AIエージェントに作業をさせると、その過程でスクリプト実行やAPI呼び出しといった「手順の自動化」を自然にこなしている瞬間があります。AIと自動化は並列な分類ではなかったのか?

これは、2つを排他的な分類ではなく交互に積み重なるレイヤーとして捉えると綺麗に整理できます。

AIエージェントの動作は「判断 → 手順の実行 → 結果の観察 → また判断…」の往復です。AIの中に自動化が見えるのは、判断層が手順層を呼び出している瞬間を見ているからです。ネットワークに馴染みのある方なら、SDNのコントロールプレーン(判断)とデータプレーン(決定論的な転送)の関係を思い浮かべると近いイメージになります。

保証は「最も弱い層」に律速される

このレイヤー構造で重要なのが保証の考え方です。

個々のツール実行が決定論的でも、「どれを・いつ・どう呼ぶか」の判断が確率的なら、複合体全体は「保証できない自動化」として扱う

直列システムの信頼性が最も弱いリンクで決まるのと同じ理屈です。

AIの第三の顔:判断を手順に「固定化」できる

AIには「判断の自動化」に加えてもう一つ重要な能力があります。判断を手順に固定化(コンパイル)できること

AIにスクリプトやIaCコードを書かせた直後は確率的な成果物ですが、レビューとテストを通せば「保証できる自動化」に昇格し、以後は決定論的な資産として再利用できます。確率的な世界から決定論的な世界へ成果物を移せる──これが実務で最も価値の高い使い方だと考えています。

判断をAIへ寄せる前に:3つの前提整理

「同じ情報量なら、判断のばらつきは人間のほうが大きい。判断もAIに任せたほうが合理的では」という問いは自然に出てきます。この方向性には合理的な核がありますが、プロセス再設計に落とす前に3点だけ精密化しておく価値があります。

1. 誤りの構造が違う ── 人間の誤りは独立に起きるためばらつきが打ち消し合いますが、AIの誤りは相関し、全系が同方向に間違えうる(コモンモード故障)。冗長化しても同じバグを踏めば意味がない、という冗長設計と同じ発想で押さえる必要があります。
2. 人間の役割は消えるのではなく再定義される ── 「毎回判断する人」から「判断基準を明文化する人・不可逆な決定に責任を持つ人」へ。何を良しとするか(受け入れ基準・優先順位)は価値判断であり、また組織では判断の責任を負う主体が必要です。
3. 委譲の深さは検証コストで決まる ── 出力を機械的に検証できる領域はAIがやり切れます。失敗が不可逆で事後検証しかできない領域は、人間の判断が優れているからではなく責任と不可逆性のために人間ゲートが残ります。

開発プロセスで可視化する:AS-IS / TO-BE

以上の整理を、開発プロセス6工程(要件定義〜運用・保守)に適用してみます。各工程を「狭義の自動化 / AI / 人間」の3者でどう分担しているか・していくかの比率です。

数値は一般的な到達水準を想定した叩き台です。組織の実態に合わせて調整してください。

AS-IS:現在の典型的な分担

工程	自動化	AI	人間
要件定義	0	15	85
設計	5	20	75
実装	30	20	50
試験	25	15	60
リリース	20	5	75
運用・保守	30	10	60

自動化はCI/CD・構成管理・監視など既存資産の範囲に留まり、AIは下書き支援。注目すべきは、自動化資産を人間が個別に手作りしてきたため、カバー範囲の拡大が人手に律速されているという構造です。

TO-BE:AIが自動化を生産し続ける前提の分担

工程	自動化	AI	人間	人間ゲート
要件定義	5	55	40	① 受け入れ基準の確定
設計	15	65	20	─
実装	45	50	5	─
試験	55	35	10	─
リリース	45	25	30	② 本番反映のGo/No-Go
運用・保守	40	40	20	③ 重大インシデントの意思決定

TO-BEのポイントは、単にAI比率を増やすことではありません。AIの成果物を固定化し続けることで自動化の比率が拡大する構造にすることです。AI領域は固定化により自動化領域へ移り続けるため、この境界は静的ではなく時間とともに動きます。人間は3つのゲート(基準の確定・Go/No-Go・重大時の意思決定)に集中します。

3者は何を担うか

工程	狭義の自動化(決定論)	AI(確率的判断)	人間
要件定義	受付フォーム・定型チェック	ヒアリング整理、文書化、矛盾検出	優先順位と受け入れ基準の確定
設計	標準パターンの自動適用	方式比較、詳細設計、パラメーター設計	制約提示、方式の最終選定
実装	パイプライン実行、静的検査	コード・設定の生成、修正	ほぼなし(検証基準の整備)
試験	回帰テストの常時実行	テスト設計・生成、結果分析	受け入れ基準の定義
リリース	デプロイパイプライン、ロールバック手順	判定材料の収集、リスク分析	Go/No-Goの決定と責任
運用・保守	監視、既知パターンの自動復旧	未知事象の原因分析、対処案の提示	重大インシデントの意思決定、対外説明

原則はシンプルです:確実に再現したい処理は自動化へ、状況に応じた判断はAIへ、基準の設定と責任は人間へ。

自動化は誰が作るのか:4つの活動で区分する

TO-BEでは自動化そのものもAIが生産します。ただし「自動化を作る」を分解すると、主体が異なる4つの活動があります。

活動	内容	主体
① 実装	スクリプト・IaCコード・テストコードの生成	AIが完遂(レビューを経て資産化)
② 設計	何を自動化するかの対象選定・優先順位	AI提案+人間承認(ROIとリスクの投資判断)
③ プロセス統一	チーム間の手順のばらつき解消・規約統一	人間主導(AI支援)
④ 保守	資産の陳腐化(ドリフト)検出・棚卸し・更新	AIが主導

特筆すべきは③です。標準化の合意形成は「判断の正しさ」の問題ではなく**「納得と権限」の問題です。AIがどれだけ正しい標準案を出しても、チーム間の合意そのものは代替できません。AIにできるのは現状差分の可視化と標準案のドラフトまで。「判断はAIへ」という原則を突き詰めても、委譲できずに残るのは判断ではなく合意**だ、というのが個人的に面白い発見でした。

移行の考え方

1. AI→自動化の固定化ループを回す:AIの成果物をレビューを経て自動化資産へ昇格させ続け、自動化のカバー範囲拡大が人手に律速されない体制を作る
2. 判断基準とプロセスの明文化が前提投資:基準が暗黙知のまま、手順がチームごとにばらばらのままではAIに委譲できない。標準化の合意形成(人間の仕事)が最初のボトルネックになる
3. 人間ゲートは「責任と不可逆性」で絞る:人間の判断が優れているからではなく、責任の所在と取り返しのつかなさでゲートの配置を決める

まとめ

• AIは広義の自動化に含まれる。違いは代替するものが「手順」か「判断」か
• 判断と手順は排他的分類ではなく、交互に積み重なるレイヤー。複合体の保証は最も弱い層に律速される
• AIは判断するだけでなく、判断を手順に固定化して「保証できる自動化」へ昇格させられる
• 人間の役割は「毎回判断する人」から「基準を設定し、不可逆な決定に責任を持つ人」へ
• AIに委譲しても最後まで残るのは、判断ではなく合意形成

この整理が、AI活用の議論で認識を揃える際の叩き台になれば幸いです。