生成AIは運用の切り札か、劇薬か 〜 AIOps時代に求められる“賢い使い分け” / 20260219-itmedia-ai-operation

2026年2月19日に開催された @IT Operator Live での発表資料です。

IT と 生成AIの根本的な違について歴史から紐解いていますので、ご一読いただければと思います。
(発表後にWAFの開発者の方にご意見いただきましたが、ほぼ異論が無いとのことで、少なくとも的外れではないという感触でした。)

発表の数日後に「ハーネスエンジニアリング」という概念を知ったので、この発表では決定論化するための悩みについて書いていますが、補遺ページを追加しておきました。

(運用設計ラボ合同会社 波田野 裕一)

Transcript

1. 生成AIは運用の切り札か、劇薬か 〜 AIOps時代に求められる“賢い使い分け” @IT Operator Live 運用設計ラボ合同会社 シニアアーキテクト 波田野 裕一 2026-02-19 Operation Lab 運用設計ラボ 1
2. 運用設計ラボ合同会社 シニアアーキテクト 波田野 裕一 インプットご支援 AWS Samurai 2017 (個人) AWS Community Hero AWS Samurai 2020 (CLI専門支部) 科学的工学的な考え方に基づく講義とワークショップで 30年先も活きる運用設計スキルを身に付ける 世界で最もAWS APIの仕様に忠実なeラーニングで 10年先も活きるAWSスキルを身に付ける 現場での実践ご支援 日本MSP協会 特別会員 アウトプットご支援 運用設計支援 よろず相談 ホワイトペーパー/ガイドライン策定支援 ホワイトペーパやガイドラインの制作や内製をご支援いたします。 Operation Lab 運用設計ラボ 2
3. 概要 生成AI活用は運用業務を変革する一助になり得る一方で、使い方によっては 「逆効果を招く」劇薬です。現場の業務特性、スキルレベル、スピードと品質 のバランスなど、幾つかの判断軸をもって賢く活用する必要があります。 本講演では、生成AIの特性を踏まえ、活用すべき領域と避けるべき領域、上手 くマッチするパターンを整理し、AI時代に運用者に求められるスキルや、暗黙 知を表出させるためのAI活用についてもお話します。 Operation Lab 運用設計ラボ 3
4. アジェンダ 序. ITとAIの違い、説明できますか? 1. 生成AIの弱み、強み 2. IT運用の特性と生成AIの特性 3. スキルレベルと生成AIの活用 4. IT運用業務における生成AIの活用 Operation Lab 運用設計ラボ 4
5. 序. ITとAIの違い、説明できますか? Operation Lab 運用設計ラボ 5
6. IT と AI の違い?? (ここでは生成AI) 比べるものではないのでは...? と思うかもしれませんが、歴史から辿ってみましょう Operation Lab 運用設計ラボ 6
7. 序. ITとAIの違い、説明できますか? ITとは何か? Information Technology データの処理と配布のためのコンピューターシステム、ソフトウェア、ネットワーク の開発、保守、使用に関わる技術 (出典: Merriam-Webster辞典 翻訳) (日本語では)「情報通信技術」 • 「情報」は特に「コンピューター」を意味する。 • 「通信」は「インターネット」を意味することが多い。 ITとは「コンピューターとインターネットに関する技術」の総称である。 Information Technology (1952) 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020 年代 年代 年代 年代 年代 年代 年代 年代 年代 年代 (出典: Merriam-Webster辞典) Operation Lab 運用設計ラボ 7
8. 序. ITとAIの違い、説明できますか? [歴史] 1930-1950年代 (ITの黎明期: 研究技術の時代) • コンピューターは、もともと「電子計算機」として誕生し、発展してきた。 • そのため、情報科学やシステム工学は、数理論理学に大きく依拠して発展してきた。 チューリングマシンの考案 (1936) 現在のコンピューターの数学的モデル (今でも教科書の重要項目) ノイマン型コンピューターの稼動 (1951) 商用コンピューターの登場 (1951) 現在のコンピューターアーキテクチャ コンピューターの商用利用開始 Information Technology (1952) 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020 年代 年代 年代 年代 年代 年代 年代 年代 年代 年代 (出典: Merriam-Webster辞典) Operation Lab 運用設計ラボ 8
9. 序. ITとAIの違い、説明できますか? 数理論理学とは • 「推論の方法とその正しさ」に関する学問 • 数学における推論を形式化し、その推論自体を数学の対象とする取り組み 推論 利用可能な情報(前提や証拠)から、規則、過去事例やメンタルモデルに基づいて、 結論や新しい情報を導く思考過程 基礎的な成果 ブール値 真(True)と偽(False) 論理関数 AND OR NOT 論理回路の例 (フリップフロップ回路) (出典: 日本電気技術者協会) Operation Lab 運用設計ラボ 9
10. 序. ITとAIの違い、説明できますか? 参考: 数理論理学の主要4分野 公理的集合論 集合論の数学的な基盤 証明論 構文論、データ構造 (直感的集合なベン図に対して意味論的集合)̲ モデル理論 形式言語、形式手法 計算理論 (再帰理論) アルゴリズム 計算量 Operation Lab 10 運用設計ラボ
11. 序. ITとAIの違い、説明できますか? 数理論理学における推論 数学的な「推論」は、全て「演繹的推論」となる 推論 利用可能な情報(前提や証拠)から、規則、過去事例やメンタルモデルに基づいて、 結論や新しい情報を導く思考過程 演繹 諸前提から論理の規則にしたがって 必然的に結論を導き出すこと。 Operation Lab 11 運用設計ラボ
12. 序. ITとAIの違い、説明できますか? 演繹的推論の構造 数理論理学における「推論」は、全て「演繹的推論」となる 演繹の基本構造 前提 演繹的推論 結論 すべての人間は死ぬ ソクラテスは人間である ソクラテスは死ぬ 抽象度が高い 具体化する条件を定める 具体化する 演繹では、前提が同一であれば、必ず結論は同じになる (必然的) Operation Lab 12 運用設計ラボ
13. 序. ITとAIの違い、説明できますか? ITにおける推論の基本構造 ITは、数理論理学を基に誕生・発展してきた 演繹の基本構造 前提 演繹的推論 結論 ITの基本構造 Input 関数 (システム) Output ITでも、前提が同一であれば、必ず結論は同じになる (必然的) Operation Lab 13 運用設計ラボ
14. 序. ITとAIの違い、説明できますか? ITはなぜ「強力なツール」なのか? ITは「正しい論理」を、ひたすら「正しく実行」できる 1回正しく動いた論理は、100万回でも正しく動く + 人手を離れて、地道に動作し続ける ITの基本構造 Input 関数 (システム) Output Operation Lab 14 運用設計ラボ
15. 序. ITとAIの違い、説明できますか? AIとは何か? Arti cial Intelligence コンピューターシステムやアルゴリズムが知的な人間の行動を模倣する能力 (出典: Merriam-Webster辞典 翻訳) (日本語では)「人工知能」 数理論理学がベース Information Technology (1952) Arti cial Intelligence (1955) 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020 年代 年代 年代 年代 年代 年代 年代 年代 年代 年代 (出典: Merriam-Webster辞典) Operation Lab 15 fi fi 運用設計ラボ
16. 序. ITとAIの違い、説明できますか? [歴史] 1950-1960年代 (AIの黎明期: 研究技術の時代) • コンピューターの商用化に引き続き、1950年代後半に「人工知能」への期待が高まった。 • しかし、トイ・プロブレム(おもちゃの問題)しか解けず、失望が拡がる。 コンピューター資源が貧弱 ロジックとデータの投入作業(人の工数) > AIの回答の量と質 第1次AIブーム (1950年代後半 推論・探索の時代 1960年代) 1970年代は 「AI冬の時代」 Arti cial Intelligence (1955) 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020 年代 年代 年代 年代 年代 年代 年代 年代 年代 年代 (出典: Merriam-Webster辞典) Operation Lab 16 ～ fi 運用設計ラボ
17. 序. ITとAIの違い、説明できますか? [歴史] 1970-1990年代 (ITの発展期: 民生化の時代) • 主に研究機関・学術機関でネットワークが利用されるようになってきた。 • 90年代初頭にハードウェアが汎用化し、民生市場でも入手が容易になった。 数理論理学がベース TCP/IPの登場 (1969) (例)ネットマスクは論理演算(AND) インターネットの基礎技術の誕生 リレーショナルDBの登場 (1970) 数理論理学から誕生 DOS/Vの登場 (1990) 専用ハードウェアが不要なOSの登場 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020 年代 年代 年代 年代 年代 年代 年代 年代 年代 年代 (出典: Merriam-Webster辞典) Operation Lab 17 運用設計ラボ
18. 序. ITとAIの違い、説明できますか? [歴史] 1970-1990年代 (AIの停滞期: 民生化の時代) • 1970年代初頭に登場した「エキスパートシステム」が1980年代に期待を集めるようになる。 • 生産管理、医療診断、投資判断、人事などで導入が進むも、次第に失望が拡がる。 ロジックとデータの投入作業(人の工数) > AIの回答の量と質 数理論理学がベース エキスパートシステムの登場 (1970) 1970年代は 「AI冬の時代」 第2次AIブーム (1980年代 1990年代前半) 知識の時代 再び 「AI冬の時代」 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020 年代 年代 年代 年代 年代 年代 年代 年代 年代 年代 (出典: Merriam-Webster辞典) Operation Lab 18 ～ 運用設計ラボ
19. 序. ITとAIの違い、説明できますか? [歴史] 1990-2000年代 (ITの発展期: 通信の時代) • Windows95により、TCP/IPの基盤が整い、常時接続環境が急速に普及した。 • 2000年代半ばにクラウドが登場し、「持たないIT」を実現し普及し続けている。 TCP/IPの普及 数理論理学がベース Windows95の登場 (1995) インターネット高速通信の普及ヘ 常時接続サービスの登場 (2000) 「持たないIT」の普及へ パブリッククラウドの登場 (2006) 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020 年代 年代 年代 年代 年代 年代 年代 年代 年代 年代 (出典: Merriam-Webster辞典) Operation Lab 19 運用設計ラボ
20. 序. ITとAIの違い、説明できますか? パブリッククラウドは「運用の論理化」の究極の形 パブリッククラウドは 「正しい論理」を、ひたすら「正しく実行」することの積み重ね 1回正しく動いた論理は、100万回でも正しく動く + 公開APIを介して誰でも使えるようにした ITの基本構造 Input 関数 (システム) Output AWSでは、数百のAPIで、数万のアクションを実行できる Operation Lab 20 運用設計ラボ
21. 序. ITとAIの違い、説明できますか? [歴史] 2000年頃までAIは上手くいっていなかった • 数理論理学をベースとしたITは、商用機の登場からクラウドの登場へと順調に発展。 • 数理論理学をベースとしたAIは、挫折と停滞を繰り返していた。 数理論理学がベース Information Technology (1952) 順調に発展 Arti cial Intelligence (1955) 停滞を繰り返す 第1次AIブーム 1970年代は 「AI冬の時代」 第2次AIブーム 再び 「AI冬の時代」 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020 年代 年代 年代 年代 年代 年代 年代 年代 年代 年代 (出典: Merriam-Webster辞典) Operation Lab 21 fi 運用設計ラボ
22. 序. ITとAIの違い、説明できますか? [歴史] 2000年代 (AIの転換期: 数理統計学の導入) • 2002年に、ベイズ推定を利用した「ベイジアンフィルター」が論文化される。 • 迷惑メールの「特徴」を「確率統計的」に分類することで、効果的にフィルターできる。 「論理で決める仕組み」だったITに「統計で決める仕組み」が入ってきた 数理論理学がベース Information Technology (1952) 順調に発展 Arti cial Intelligence (1955) 停滞を繰り返す 数理統計学がベース ベイジアンフィルター (2002) 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020 年代 年代 年代 年代 年代 年代 年代 年代 年代 年代 (出典: Merriam-Webster辞典) Operation Lab 22 fi 運用設計ラボ
23. 序. ITとAIの違い、説明できますか? 数理統計学とは • 「数学的な見方でデータを捉える」学問 • 確率理論(推定や仮説検定などの手法)を用いてデータの法則性を導き出す 推測統計学 母集団から抽出した標本の情報を用いて、確率的(頻度的)に母集団の情報を推測する 多変量解析 ベクトルや行列を使ってデータの関連性を探索する Operation Lab 23 運用設計ラボ
24. 序. ITとAIの違い、説明できますか? 数理統計学における推論 統計的な「推論」は、全て「帰納的推論」となる 帰納的推論 複数の特殊事実から一般的、普遍的法則性を導出する推論 帰納 個々の特殊な事実や命題の集まりからそこに共通する性質や関係を取り出し， 一般的な命題や法則を導き出すこと Operation Lab 24 運用設計ラボ
25. 序. ITとAIの違い、説明できますか? 数理論理学と数理統計学の特徴 数理論理学がベース 数理統計学がベース トップダウンアプローチ 演繹的推論 ボトムアップアプローチ 前提 すべての人間は死ぬ 結論 抽象度が高い 帰納的推論 Aさんの結論 ユーザーは申請スキルが低い。(仕方ない) Bさんの結論 ユーザーに申請ガイドが必要。(改善すべき) 抽象化する Aさんの推論 推論 ソクラテスは人間である 推論 Bさんの推論 具体化する条件を定める 抽象化する条件をさがす 具体度が高い ユーザ1は申請に時間が掛かる。 結論 ソクラテスは死ぬ 具体化する 前提が同一であれば、必ず結論は同じになる (必然的) 具体例 ユーザ2は申請にミスが多い。 ユーザ3は申請方法を理解していない。 帰納では、結論は同じになるとは限らない (蓋然的) Operation Lab 25 運用設計ラボ
26. 序. ITとAIの違い、説明できますか? 数理論理学と数理統計学の特徴 (1. 決定性) 数理論理学がベース トップダウンアプローチ 数理統計学がベース 演繹的推論 ボトムアップアプローチ 決定的 Input 関数 (システム) 帰納的推論 非決定的 Output1 Output Input ベイズ推定 Output2 Output3 前提が同一であれば、必ず結論は同じになる (必然的) 帰納では、結論は同じになるとは限らない (蓋然的) 1回正しく動いた論理は、100万回でも正しく動く 原理的に一定の確率で期待した答を返さない (参考) 99.8%は意外と低い精度 OCRで100万文字中、2千文字の誤判定 アラート400万通中、8千通の誤判定 演繹よりも「誤判定の発見」に手間がかかることもある Operation Lab 26 運用設計ラボ
27. 序. ITとAIの違い、説明できますか? 数理論理学と数理統計学の特徴 (2. 収斂と発散) 数理論理学がベース トップダウンアプローチ 演繹的推論 数理統計学がベース ボトムアップアプローチ 帰納的推論 多くの選択肢がある 前提 前提条件で絞り込む 結論 多様な結論 + 確率 推論 推論で演繹的に絞り込む 推論 多様な推論が可能である 収斂 具体例 発散 結論 Operation Lab 27 運用設計ラボ
28. 序. ITとAIの違い、説明できますか? [歴史] 2010年代 (AIの勃興期: 機械学習の登場) • 2012年に、ディープラーニング(深層学習)による機械学習が脚光を浴びる。 • ニューラルネットワーク(人間の脳細胞を模倣)により、パターン学習を行う。 データの投入と学習(人の工数) < AIの回答の量と質 数理論理学がベース 第3次AIブーム (2012 2022年頃) 機械学習の時代 数理統計学がベース ベイジアンフィルター (2002) 推測統計学の活用 ディープラーニング (2012) 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020 年代 年代 年代 年代 年代 年代 年代 年代 年代 年代 (出典: Merriam-Webster辞典) Operation Lab 28 ～ 運用設計ラボ
29. 序. ITとAIの違い、説明できますか? 機械学習の何がすごいのか? 情報量が一定のボリュームを超えると 「人間が気付けない特徴」を発見できる可能性が急激に上昇する (例: 画像での人物判定など) 情報が膨大 情報が少ない 人間が気付けない特徴 を発見 限定された条件の組合せ 無制限の条件の組合せ 機械学習 Operation Lab 29 運用設計ラボ
30. 序. ITとAIの違い、説明できますか? [歴史] 2020年代-現在 (AIの民生化: 生成AIの登場) • 2022年に、ChatGPTが登場し、一気に普及する。 • 機械学習との大きな違いは、汎用性とインタラクティブ性が極めて高いこと。 数理論理学がベース 第4次AIブーム (2022年頃〜) 生成AIの時代 数理統計学がベース ベイジアンフィルター (2002) 推測統計学の活用 ディープラーニング (2012) 多変量解析の発展 生成AI (2022) 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020 年代 年代 年代 年代 年代 年代 年代 年代 年代 年代 (出典: Merriam-Webster辞典) Operation Lab 30 運用設計ラボ
31. 序. ITとAIの違い、説明できますか? まとめ: ITとAIの違い AIはITの上で動作しているが、その性質は全く真逆 IT AI (生成AI) 数理論理学がベース 数理統計学がベース トップダウンアプローチ ボトムアップアプローチ 演繹的推論 帰納的推論 決定的 非決定的 前提が同一であれば、必ず結論は同じになる (必然的) 帰納では、結論は同じになるとは限らない (蓋然的) 1回正しく動いた論理は、100万回でも正しく動く 原理的に一定の確率で期待した答を返さない 収斂 発散 演繹的に結論を絞り込む 多様な結論 + 確率 Operation Lab 31 運用設計ラボ
32. 1. 生成AIの弱み、強み Operation Lab 32 運用設計ラボ
33. 1. 生成AIの弱み、強み 生成AIの特徴 生成AIは、非決定的で(基本構造として)発散する 数理統計学がベース 結論 多様な結論 + 確率 推論 多様な推論が可能である 具体例 発散 ボトムアップアプローチ 帰納的推論 帰納では、結論は同じになるとは限らない (蓋然的) 原理的に一定の確率で期待した答を返さない 非決定的 Operation Lab 33 運用設計ラボ
34. 1. 生成AIの弱み、強み 生成AIの弱み:「非決定的」 生成AIは、非決定的で(基本構造として)発散する 生成AIは、非決定的なため「100%」を求めることは不可能 Output1 数理統計学がベース ボトムアップアプローチ Input 生成AI Output2 Output3 帰納的推論 帰納では、結論は同じになるとは限らない (蓋然的) 原理的に一定の確率で期待した答を返さない 生成AIに「ロジック」を組み込む動きもあるが 「ロジックの選択」をどうするかという問題は残る。 人がロジックを選択すれば精度は上がるが、適切な選択が可能か? AIが「ロジックを確率的に選択」すれば、確率論から逃れられない。 生成AIは「非決定的」という弱みとセットで考える必要がある Operation Lab 34 運用設計ラボ
35. 1. 生成AIの弱み、強み 事後追加: ハーネスエンジニアリングという考え方 この発表(2026-02-19)をした2・3日後に 「ハーネスエンジニアリング」という概念 を知りました。 「ハーネス」(harness: 馬具や鞍) によって、 生成AIの出力を制約する 生成AIに「ロジック」を組み込む動きもあるが 「ロジックの選択」をどうするかという問題は残る。 人がロジックを選択すれば精度は上がるが、適切な選択が可能か? AIが「ロジックを確率的に選択」すれば、確率論から逃れられない。 ハーネスで制約した範囲での出力しか許さない考え方 (より「決定的」に近づけるための仕組みづくり) Operation Lab 35 運用設計ラボ
36. 1. 生成AIの弱み、強み 生成AIの弱み:「非決定的」の補完が不可欠 生成AIは、非決定的で(基本構造として)発散する 生成AIは、非決定的なため「100%」を求めることは不可能 100% 補完 演繹的推論 80% 100%との差は 人が埋める 60% 60〜80%まで 底上げはできる Output1 Input 生成AI Output2 Output3 帰納的推論 0% 演繹的で決定的であれば、放置しても上手く動き続けるが 帰納的で非決定的であると、完全な手離れは難しい Operation Lab 36 運用設計ラボ
37. 1. 生成AIの弱み、強み 生成AIの強み:「発散」 生成AIは、非決定的で(基本構造として)発散する 生成AIは、発散的なため個人や組織の思考では気付けない視点を獲得し得る 結論 多様な結論 + 確率 推論 多様な推論が可能である 具体例 発散 演繹的推論 人間の内部 帰納的推論 人間の外部 2018-10-26 ITmedia様イベント ITシステム運用、AIの普及で「変わる領域」「変わらない領域」 Operation Lab 37 運用設計ラボ
38. 1. 生成AIの弱み、強み 生成AIとのつきあい方 生成AIは、非決定的で(基本構造として)発散する 生成AIマネジメントが重要 短所のマネジメント 長所のマネジメント 100%を求められるところは「論理」で闘う 人の論理や直感で気付きにくいところで活かす 精度や品質が低いところを生成AIで底上げする 統計的・確率的に高い結論(一般論)を得るために活かす (非決定的でもやらないよりましな所) 生成AIに案出し(非決定的)させ、人が決定する。 大量の仮説検証や暗黙知の形式知化の支援をさせる。 Operation Lab 38 運用設計ラボ
39. 1. 生成AIの弱み、強み 生成AI利用のアンチパターン 生成AIは、非決定的で(基本構造として)発散する 生成AIマネジメントができていない 短所による悪影響 長所による悪影響 生成AIへの過剰な信頼 説明できないアウトプットの大量生産 決定的な仕事をしてきた人の排除 レビューや承認の滞留 集団浅慮からAI浅慮へ (不合理な判断の頻発) 「生成AIが劇薬」 となってしまう 業務品質の大幅な低下と遅延 (事業継続性の低下) Operation Lab 39 運用設計ラボ
40. 1. 生成AIの弱み、強み 参考: 生成AIの正しい(?)イメージ 生成AIは、非決定的で(基本構造として)発散する こういうイメージを持っておくと痛い目に遭いにくい 優秀だけど暴走しがち(発散)で 責任は取ってくれない(非決定的) 低価格の外注エンジニア 生成AIマネジメントが重要 「ドラえもんのひみつ道具」に似て、使い方次第 (のび太のように使い方を間違えると泣くことに...) Operation Lab 40 運用設計ラボ
41. (参考) 生成AIの活用のコツ Operation Lab 41 運用設計ラボ
42. (参考) 生成AIの活用のコツ 参考: 生成AI活用のコツ (入力) どんな入出力も、入力の品質以上の出力は得られない 論理的な プロンプト Output1 Input 生成AI Output2 Output3 論理的な 取捨選択 演繹的推論 帰納的推論 演繹的推論 決定的 非決定的 決定的 収斂 発散 収斂 生成AIの回答が 決定的・収斂しやすい 論理的な質問をする 生成AIの得意な領域に 質問分野や内容を絞り込む (生成AIの使い分け) 生成AIの一連の回答から 人が論理的に収斂させた結論 を得る Operation Lab 42 運用設計ラボ
43. (参考) 生成AIの活用のコツ 参考: 生成AI活用のコツ (入力: インタビュー形式の活用) 質問のためのインタビューを生成AIにさせる 論理的な プロンプト Output1 インタビュー 生成AI Input Output2 Output3 論理的な 取捨選択 演繹的推論 帰納的推論 演繹的推論 決定的 非決定的 決定的 収斂 発散 収斂 生成AIの質問から 決定的・収斂しやすい 論理的な質問を導き出す 生成AIの得意な領域に 質問分野や内容を絞り込む (生成AIの使い分け) 生成AIの一連の回答から 人が論理的に収斂させた結論 を得る Operation Lab 43 運用設計ラボ
44. (参考) 生成AIの活用のコツ 参考: 生成AI活用のコツ (出力) どんな出力も、最終責任は人が引き受ける 論理的な プロンプト Output1 Input 生成AI Output2 Output3 論理的な 取捨選択 演繹的推論 帰納的推論 演繹的推論 決定的 非決定的 決定的 収斂 発散 収斂 生成AIの回答が 決定的・収斂しやすい 論理的な質問をする 生成AIの得意な領域に 質問分野や内容を絞り込む (生成AIの使い分け) 生成AIの一連の回答から 人が論理的に収斂させた結論 を得る Operation Lab 44 運用設計ラボ
45. 序. ITとAIの違い、説明できますか? 参考: 生成AI活用のコツ (分担) 生成AI トップダウンアプローチ ボトムアップアプローチ 多くの選択肢がある 前提条件で絞り込む 結果責任を 人が負う 多様な結論 + 確率 分析結果を基に ロジックをブラッシュアップする 推論で演繹的に絞り込む 多様な推論が可能である ロジックを立てて、 モデルやデータを分析する 収斂 ロジックで 入力品質を担保 発散 Operation Lab 45 運用設計ラボ
46. 序. ITとAIの違い、説明できますか? 参考: 日本の組織には「演繹的なアプローチ」が欠けている トップダウンアプローチ ボトムアップアプローチ 現場が何しているのか わからない 多くの選択肢がある 現場から 提案が無い 経営層 前提条件で絞り込む 多様な結論 トップダウンアプローチ が存在しない 共通認識がない 整合・連携もしない 無邪気に 生成AIを入れて大丈夫か? 断絶 サイロ化 推論で演繹的に絞り込む 多様な推論が可能である 現場の努力 現場が何をすべきか わからない 収斂 運用要員 ボトムアップアプローチ が発散している 運用要員 2020-01-21 ITmedia様イベント これからの「運用管理」の話をしよう 発散 Operation Lab 46 運用設計ラボ
47. 2. IT運用の特性と生成AIの特性 Operation Lab 47 運用設計ラボ
48. 2. IT運用の特性と生成AIの特性 よくある「運用でよろしく」 これは「企画業務」 ではないので 「運用業務」でしょう 開発担当 企画担当 これは「開発業務」 ではないので 「運用業務」でしょう 開発終了し 担当がいない システム は?! この時点で外堀は埋まってる それは「運用業務」じゃない と思うんだけどなぁ... システムの内容も知らないし 専門性も遠いけどやるはめに 運用担当 運用技術を磨いてきたはずなのに「なんでも屋」さんになっている... Operation Lab 48 運用設計ラボ
49. 2. IT運用の特性と生成AIの特性 企画 vs. 開発 vs. 運用 企画担当 企画からリリースまでが仕事 全く同じプロジェクト は存在しない 全く同じリリース プロジェクト型業務 毎回やり方が違う 成果に区切り(リリース)があるので 開発担当 非再現的な業務 特徴が目に付きやすい リリースからサービス廃止までが仕事 非プロジェクト型業務 運用担当 毎回結果が違う 非反復的な業務 成果に区切りが無いので 特徴が目に付きにくい 毎回やり方が違う運用 は維持できない 毎回結果が違う運用 は評価されない 反復的な業務 再現的な業務 + 「24時間365日」の活動 が期待されている Operation Lab 49 運用設計ラボ
50. 2. IT運用の特性と生成AIの特性 IT運用の特性 (数理論理学と相性が良い) 演繹の基本構造 前提 演繹的推論 結論 ITの基本構造 関数 Input (システム) Output 1回正しく動いた論理は、100万回でも正しく動く リリースからサービス廃止までが仕事 非プロジェクト型業務 運用担当 成果に区切りが無いので 特徴が目に付きにくい 毎回やり方が違う運用 は維持できない 毎回結果が違う運用 は評価されない 反復的な業務 再現的な業務 + 「24時間365日」の活動 が期待されている Operation Lab 50 運用設計ラボ
51. 2. IT運用の特性と生成AIの特性 参考: IT運用の特性とレジリエンス (障害対応) 演繹の基本構造 前提 演繹的推論 結論 ITの基本構造 関数 Input (システム) Output 1回正しく動いた論理は、100万回でも正しく動く リリースからサービス廃止までが仕事 非プロジェクト型業務 運用担当 成果に区切りが無いので 特徴が目に付きにくい 物理的な障害は不可避 回復力・復元力 (レジリエント) 反復的な業務 再現的な業務 + 2025-09-04 レジリエントな運用の話を ITmedia様でさせていただきました 「24時間365日」の活動 が期待されている Operation Lab 51 運用設計ラボ
52. 2. IT運用の特性と生成AIの特性 IT運用の設計 (数理論理学と相性が良い) 演繹の基本構造 前提 演繹的推論 結論 ITの基本構造 関数 Input (システム) Output 1回正しく動いた論理は、100万回でも正しく動く あるべき運用業務 1. 人が理解しやすい業務である。 2. システムが扱いやすい業務である。 3. 論理的に正しいことを検証している。 人材がスケールする 業務がスケールする 工数を最大活用できる • ドキュメント化工数を必要最小限にできる。 • 中途・新人の戦力化に時間がかからない。 • 環境変化への対応が比較的容易にできる。 • Whyが失われにくいので硬直化を避けやすい。 • ツール製品を導入したときに効果が出やすい。(連携しやすい) 適切な運用設計がされている 52 Operation Lab 52 運用設計ラボ
53. 2. IT運用の特性と生成AIの特性 IT運用の設計 (あるべき運用 vs. ありがちな運用) 演繹的推論による運用設計 演繹的推論によらない運用設計 あるべき運用業務 ありがちな運用業務 1. 人が理解しやすい業務である。 人材がスケールする 1. 人が理解しやすい業務ではない。 人材がスケールしない 2. システムが扱いやすい業務である。 業務がスケールする 2. システムが扱いやすい業務ではない。 業務がスケールしない 3. 論理的に正しいことを検証している。 3. 論理破綻・矛盾による無駄・無意味が多い。 工数を最大活用できない 工数を最大活用できる 適切な運用設計がされている 適切な運用設計がされていない • ドキュメント化工数を必要最小限にできる。 • ドキュメント化工数が膨大になる。 • 中途・新人の戦力化に時間がかからない。 • 中途・新人の戦力化に時間がかかる。 • 環境変化への対応が比較的容易にできる。 • 環境変化への対応に遅れがちになる。 • Whyが失われにくいので硬直化を避けやすい。 • Whyが失われると硬直化に繋がる。 • ツール製品を導入したときに効果が出やすい。(連携しやすい) • ツール製品を導入しても効果が出にくい。(連携しにくい) 2021-08-24 ITmedia様イベント 積年の課題を解決 - 「運用変革を阻むもの」の正体と、「明日からどうするか」より引用改変 53 Operation Lab 53 運用設計ラボ
54. 2. IT運用の特性と生成AIの特性 IT運用業務の特性 (演繹的推論との関係による分類) ドキュメント の有無 Step1 有 演繹的推論での対応が可能 突発具合 計画可能 (1月前に確定) Step2 演繹的推論での対応が可能 起因組織 内部 定時作業 演繹的推論での対応が可能 Step3 外部 申請作業 演繹的推論での対応が可能 (繁忙時は精度低下) 突発 (即時対応) 緊急作業 演繹的推論での対応が可能 (練度によって精度は低下) 無 演繹的推論での対応は不可能 属人/専門作業 演繹的推論での対応は不可能 2010-12-16 ThinkIT 現場視点からの運用方法論 第3回 明日の運用現場のために - 運用フレームワークという視点 より引用改変 Operation Lab 54 運用設計ラボ
55. 2. IT運用の特性と生成AIの特性 IT運用業務の特性 (各業務の属性) 定 常 運 用 非 定 常 運 用 計画 ベース 定時作業 発生予測 可能 申請作業 発生予測 可能 緊急作業 発生予測 不可能 変動要因 外部 手順化 可能 平準化 不可能 スキル 中〜 演繹的推論での対応が可能 (練度によって精度は低下) 属人/専門作業 発生予測 不可能 変動要因 外部 手順化 不可能 平準化 不可能 スキル 中〜 演繹的推論での対応は不可能 実績 ベース 変動要因 内部 手順化 可能 平準化 可能 スキル 低 演繹的推論での対応が可能 変動要因 外部 手順化 可能 平準化 可能 スキル 低 演繹的推論での対応が可能 (繁忙時は精度低下) 2009-11-26 Internet Week 2009 運用方法論 から引用改変 Operation Lab 55 運用設計ラボ
56. 2. IT運用の特性と生成AIの特性 IT運用業務における生成AIの活用 定 常 運 用 定時作業 演繹的推論での対応が可能 演繹的推論が基本 申請作業 生成AIでブラッシュアップする 演繹的推論での対応が可能 (繁忙時は精度低下) 余地は有る 非 定 常 運 用 演繹的推論での対応が可能 (練度によって精度は低下) 緊急作業 属人/専門作業 生成AIの活用対象となり得る 演繹的推論での対応は不可能 Operation Lab 56 運用設計ラボ
57. 3. スキルレベルと生成AIの活用 Operation Lab 57 運用設計ラボ
58. 3. スキルレベルと生成AIの活用 (再掲)生成AI活用のコツ どんな入出力も、入力の品質以上の出力は得られない 論理的な プロンプト Output1 Input 生成AI Output2 Output3 論理的な 取捨選択 演繹的推論 帰納的推論 演繹的推論 決定的 非決定的 決定的 収斂 発散 収斂 生成AIの回答が 決定的・収斂しやすい 論理的な質問をする 生成AIの得意な領域に 質問分野や内容を絞り込む (生成AIの使い分け) 生成AIの一連の回答から 人が論理的に収斂させた結論 を得る Operation Lab 58 運用設計ラボ
59. 3. スキルレベルと生成AIの活用 エンジニアの言語能力レベルと生成AI 言語能力以上の出力は、生成AIから得られない トップエンジニア 論理的な プロンプト シニアエンジニア レベル3 説得力 納得感のある説得ができる ミドルエンジニア (ローミドル除く) レベル2 論述力 相手にわかりやすく説明する レギュラーエンジニア レベル1 読解力 文章や言葉を正確に読み取り ジュニアエンジニア 業務レベルでの生成AI活用にはミドルエンジニア以上の言語能力、スキル、経験が必要 Operation Lab 59 運用設計ラボ
60. 3. スキルレベルと生成AIの活用 知識領域と生成AI オフラインの知識は、生成AIから得られない 社会知識 専門知識 社会一般の知識 専門領域の知識 情報が豊富。広く使える。 情報が限定的。業界業種で使える。 生成AIの知識領域 知識には3つの領域がある (一般に) オフライン知識領域 業務知識 企業内の知識 情報が希少。企業内のみで使える。 Operation Lab 60 運用設計ラボ
61. 3. スキルレベルと生成AIの活用 知識レベルと生成AI 生成AIは、オンラインで得られる知識の宝庫 社会知識 専門知識 社会一般の知識 専門領域の知識 情報が豊富。広く使える。 情報が限定的。業界業種で使える。 生成AIの知識領域 社会知識と専門知識が豊富な人ほど便益を受けやすい ただし、生成AIは「非決定的」という弱みを忘れてはいけない 原理的に一定の確率で期待した答を返さない Operation Lab 61 運用設計ラボ
62. 3. スキルレベルと生成AIの活用 生成AIはローミドルエンジニア以下の仕事を奪う 生成AIは、ローミドル以下のエンジニアを 代行できる可能性が高まっている トップエンジニア 演繹的な仕事 シニアエンジニア 帰納的な仕事 優秀だけど暴走しがち(発散)で 責任は取ってくれない(非決定的) 低価格の外注エンジニア ミドルエンジニア (特にローミドル) レギュラーエンジニア 競合 ジュニアエンジニア 演繹的な仕事ができる人の価値は上昇し 帰納的な仕事しかできない人の価値は下落していく Operation Lab 62 運用設計ラボ
63. 3. スキルレベルと生成AIの活用 参考: 近未来のエンジニア組織 生成AIは、ローミドル以下のエンジニアを代行するため (極端な場合) トップエンジニアとシニアエンジニアだけの組織になる トップエンジニア 演繹的な仕事 シニアエンジニア 帰納的な仕事 ミドルエンジニア (ハイミドルのみ) 生成AI 演繹的な仕事ができる人の価値は上昇し 帰納的な仕事しかできない人の価値は下落していく Operation Lab 63 運用設計ラボ
64. 4. IT運用業務における生成AIの活用 Operation Lab 64 運用設計ラボ
65. 4. IT運用業務における生成AIの活用 IT運用業務における生成AIの活用 定 常 運 用 非 定 常 運 用 定時作業 演繹的推論が基本 申請作業 生成AIでブラッシュアップする余地は有る 緊急作業 属人/専門作業 生成AIの活用対象となり易い Operation Lab 65 運用設計ラボ
66. 4. IT運用業務における生成AIの活用 IT運用業務における生成AIの活用 (属人/専門作業) 定 常 運 用 定時作業 障害原因の探索支援 2015年頃、ベイズ推定を利用した例があり、現在はクラウド各社が注力中 ブラックボックス化したツールのリバースエンジニアリング 申請作業 「作った人より高いスキルが必要で、時間も掛かり、評価されない」に対する救世主 暗黙知の形式知化 悪い意味での「属人化」を解消する特効薬に成り得る 非 定 常 運 用 緊急作業 属人/専門作業 ブレーンストーミング 副作用がほとんど無く、すぐ実践しやすい。発散の効果を実感しやすい。 生成AIの活用対象となり易い Operation Lab 66 運用設計ラボ
67. 4. IT運用業務における生成AIの活用 IT運用業務における生成AIの活用 (演繹からの発散) 定 常 運 用 非 定 常 運 用 定時作業 演繹的推論が基本 申請作業 生成AIでブラッシュアップする余地は有る 緊急作業 属人/専門作業 生成AIで意図的に発散させる Operation Lab 67 運用設計ラボ
68. 4. IT運用業務における生成AIの活用 IT運用業務における生成AIの活用 (演繹からの発散: 例) 演繹的推論が基本 定 常 運 用 非 定 常 運 用 生成AIでブラッシュアップする余地は有る 定時作業 定時作業のレビューとブラッシュアップ レポートのコメント案生成 申請作業 申請作業のレビューとブラッシュアップ ツールのレビューとブラッシュアップ 緊急作業のレビューとブラッシュアップ 緊急作業実績の分析と改善案生成 緊急作業 属人/専門作業 生成AIで意図的に発散させる Operation Lab 68 運用設計ラボ
69. 4. IT運用業務における生成AIの活用 IT運用業務における生成AIの活用 (まとめ) 演繹的推論が基本 定 常 運 用 非 定 常 運 用 生成AIでブラッシュアップする余地は有る 定時作業 定時作業のレビューとブラッシュアップ レポートのコメント案生成 申請作業 申請作業のレビューとブラッシュアップ ツールのレビューとブラッシュアップ 緊急作業のレビューとブラッシュアップ 緊急作業実績の分析と改善案生成 緊急作業 属人/専門作業 障害原因の探索支援 暗黙知の形式知化 ブレーンストーミング ブラックボックス化したツールのリバースエンジニアリング 生成AIの活用対象となり易い Operation Lab 69 運用設計ラボ
70. まとめ Operation Lab 70 運用設計ラボ
71. まとめ まとめ: IT運用は演繹的推論が基本 + 生成AIで帰納的補強 演繹の基本構造 前提 演繹的推論 結論 ITの基本構造 関数 Input Output (システム) 1回正しく動いた論理は、100万回でも正しく動く 反復的な業務 再現的な業務 運用担当 生成AIの特性 帰納的推論 非決定的なため「100%」を求めることは不可能 + 「24時間365日」の活動 が期待されている 発散的なため個人や組織の思考では気付けない視点を獲得し得る 集団浅慮からAI浅慮へ (不合理な判断の頻発) リスク 業務品質の大幅な低下と遅延 (事業継続性の低下) Operation Lab 71 運用設計ラボ
72. まとめ 参考: 日本の組織は先ず「演繹的なアプローチ」に比重を置くべき トップダウン(演繹的)アプローチがきちんとできているから 生成AI(ボトムアップ/帰納的アプローチーがきちんと機能する トップダウンアプローチ ボトムアップアプローチ 現場が何しているのか わからない 多くの選択肢がある 現場から 提案が無い 経営層 前提条件で絞り込む コッチが 共通認識がない 整合・連携もしない 先ず大事 多様な結論 トップダウンアプローチ が存在しない 無邪気に 生成AIを入れて大丈夫か? 断絶 サイロ化 推論で演繹的に絞り込む 多様な推論が可能である 現場の努力 現場が何をすべきか わからない 収斂 運用要員 ボトムアップアプローチ が発散している 運用要員 2020-01-21 ITmedia様イベント これからの「運用管理」の話をしよう 発散 Operation Lab 72 運用設計ラボ
73. 参考: 過去の発表資料 過去の発表資料は OpsLab.jp というサイトに置いてあります。 https://www.opslab.jp/publish/ Operation Lab 73 運用設計ラボ
74. Operation 運用設計Lab http://www.operation-lab.co.jp/ Operation Lab 74 運用設計ラボ