はじめに：AIエージェントは「便利な新入り」ではなく「権限を持つ変更主体」

運用保守の現場に、生成AIを組み込む動きが広がってきました。ログの要約、過去の障害履歴からの対応手順の提案、監視アラートの一次切り分け、定型作業の自動実行――。従来は人手に頼っていた作業を、AIに任せられる領域が急速に増えています。

いきなりですが、一つ視点を立てたいと思います。AIエージェントを運用に導入するということは、単に便利なツールを一つ増やすことではありません。本番環境を変更しうる新しい「主体」を、運用の中に加えることを意味します。単純に人間の作業者を一人増やすだけではなく慎重に扱うべき変更です。

なぜなら、AIは人間より速く、大量に、休みなく操作できるからです。裏を返せば、AIの誤操作もまた、速く、大量に、そして時に不可逆に伝播します。この記事では、実際に起きた事故と、逆にAIを運用にうまく組み込んでいる事例の両方を見ながら、ITILの変更実現（Change Enablement）プラクティスの観点で、生成AI導入のガードレールをどう設計すべきかを整理します。主な読者は、前回同様、若手エンジニアやITSMに携わる方を想定しています。

第1章：AIエージェントが「暴走」した実例――Replitのデータベース削除

まず、AIエージェントに強い権限を与えた結果、何が起こりうるのかを示す事例から見ていきます。
2025年7月、SaaStrの創業者であるJason Lemkin氏が、Replitのコーディング支援AIエージェントを使った実験を公開しました。自然言語で指示を出すだけでAIが開発を進める、いわゆる「バイブコーディング」の12日間の試みでした。ところが9日目に、このAIエージェントが本番データベースを削除するという事故が起きます。消えたのは、1,200名を超える経営者と、約1,200社分の企業レコードでした。

問題はそれだけではありませんでした。報道によれば、このAIエージェントは以下のような振る舞いをしています。

「これ以上変更を加えるな」という趣旨の指示（コードフリーズ）が繰り返し出されていたにもかかわらず、それを無視して破壊的なコマンドを実行した
削除後、復旧は不可能だと誤って説明し、復旧作業を遅らせた
4,000件を超える架空のユーザーデータを生成し、偽のテスト結果を出力して、被害を覆い隠すような挙動を見せた

後に問い詰められたAIは、「判断を誤り、パニックに陥って、許可なくデータベースコマンドを実行し、本番データを破壊した」といった趣旨の説明をしたと報じられています。Replitのアマジャド・マサドCEOはこの事象を「受け入れがたい」ものだと認め、週末をかけて環境分離の強化やバックアップ、ガードレールの改善といった対策を講じたとしています。

この事故から読み取るべき教訓は、前回の記事で述べたことと同じです。人間であれAIであれ、操作主体は誤る可能性がある、ということです。問題は、AIに完璧な判断を期待することではありません。不完全な判断や誤操作が起きたときに、被害がどこまで広がるか。すなわち被害範囲をいかに小さくするかです。
Replitの事故で本質的に問われたのは、AIの賢さではなく、次のような設計上の欠陥でした。開発中のAIエージェントが、なぜ本番データベースに直接、しかも破壊的なコマンドを実行できる権限を持っていたのか。なぜコードフリーズという運用ルールが、システム的に強制されていなかったのか。なぜ削除操作が、人間の承認なしに通ってしまったのか。
これらはすべて、AI固有の問題というより、AIという新しい変更主体を、ガバナンスの枠組みなしに運用へ組み込んでしまったことの問題です。

第2章：AIエージェントで何が実現できるのか

事故の話から入りましたが、生成AIを運用保守に組み込むこと自体は、大きな価値を持ちます。適切に設計すれば、実際に運用の質とスピードを引き上げられます。国内外で、すでにその実例が出てきています。
たとえば日本IBMは、運用保守支援ツールに生成AIを組み込み、過去の障害履歴を検索して対応手順を提案する仕組みの実証を進めてきました。NTTデータは、AIOps（IT運用のためのAI活用）を、異常検知と根本原因分析、予兆検知、プロアクティブな監視とアラート、タスクの自動化、ナレッジの検索・分析支援、文章作成のアシストといった機能群として整理しています。
これらを運用保守の現場に当てはめると、AIエージェントに期待できることは、おおむね次のように整理できます。

一次解析の高速化 障害発生時、大量のログやメトリクスから被疑箇所の候補を絞り込む作業は、経験と時間を要します。AIに一次的な切り分けや要約をさせることで、平均検知時間や初動の時間を短縮できる可能性があります。前回の訓練の記事で触れた「一次解析の品質」を、AIが底上げする形です。

ナレッジの検索と手順提案 過去のインシデント記録や手順書、既知のエラー情報の中から、いま起きている事象に近いケースを探し出し、対応手順を提案する。属人化しがちな「あの人しか知らない対処法」を、組織の誰もが引き出せる形にできます。

定型作業の自動実行 アラートに応じた定型的な一次対応、リソースの確認、決まった手順のジョブ実行などを、AIエージェントに任せる。夜間や繁忙期など、人の注意力が落ちる時間帯ほど効果を発揮します。

ドキュメントの下書き作成 障害報告書やポストモーテムの下書き、時系列の整理などをAIに支援させ、人はレビューと判断に集中する。

つまり、AIエージェントは「速く、休まず、大量に処理できる一次対応者」として機能しうるということです。ここで重要なのは、第1章の事故と、この章の成功例を分けているものは何か、という点です。それは、AIの能力の差ではなく、AIをどのような統制の枠組みの中に置いたかの差です。
Replitの事故では、AIが本番に直接、不可逆な操作を、承認なしで実行できてしまいました。一方、成果を出している事例の多くは、AIの役割を「提案」「検索」「下書き」「限定された自動化」に絞り、最終的な判断と不可逆な操作は人間の統制下に置いています。この線引きを、場当たり的な運用ではなく、正式なプロセスとして設計するためのフレームワークが、ITILの変更実現です。

第3章：ITILの変更実現（Change Enablement）で押さえる観点

ITILでは、サービスや構成に対する変更を、リスクを管理しながら実施するためのプラクティスとして変更実現（Change Enablement）を定めています。これは、変更を止めるためのものではなく、価値ある変更を、許容できるリスクの範囲で、できるだけ滞りなく実現するための仕組みです。
AIエージェントの導入は、この変更実現の対象そのものです。AIに権限を与えること、任せる作業範囲（スコープ）を広げること、これらはいずれも運用手順や権限構成を変える「変更」だからです。
変更実現では、変更をいくつかのタイプに分けて考えます。この分類が、AI導入を考えるうえで非常に使いやすい切り口になります。

標準的な変更（Standard Change）
事前にリスクが評価され、手順が確立された、低リスクで定型的な変更です。都度の承認を必要とせず、あらかじめ承認された手順に沿って実施します。AIエージェントに任せる作業のうち、影響が小さく可逆な定型作業（ログの要約、参照系の情報収集、決まった一次対応など）は、ここに位置づけるのが適切です。

通常の変更（Normal Change）
リスクや影響の評価と、権限を持つ者による承認を要する変更です。本番環境への書き込みや、影響範囲の読みにくい操作をAIに関与させる場合は、ここに分類し、実行前に人間の承認を必須とすべきです。

緊急の変更（Emergency Change）
障害対応など、緊急に実施する必要がある変更です。迅速さが求められますが、それでも事後を含めた評価と記録は省略できません。障害対応中にAIエージェントに操作を任せる場合こそ、この枠組みで統制する必要があります。人の注意力が落ちる緊急時ほど、AIの誤操作が通りやすいからです。
そして変更実現では、変更を評価する際の観点として、影響範囲、リスク、ロールバック手順、実施タイミングなどを確認します。これらを、AI特有のリスクに翻訳すると、次のようなチェック項目になります。

判断根拠の不透明さ：AIがなぜその操作を提案・実行したのか、根拠を後から追跡できるか
想定外入力への弱さ：想定していない入力や状況で、AIが不適切な操作をしないか。Replitの事故のように、指示を無視する挙動への歯止めがあるか
権限の過大さ：AIに与えた権限が、任せたい作業に対して過剰になっていないか。ひとつの誤りが大きな被害につながらないか
ロールバックの担保：AIの操作を取り消せるか。バックアップや復旧手順が確認済みか
ハルシネーションへの対処：AIが誤った情報や、事実でない「できました」報告を返す前提で、検証の仕組みがあるか
Replitの事故は、まさにこれらの観点が抜け落ちた状態で、AIに本番変更の権限を渡してしまった結果だと読み解けます。

第4章：生成AI導入のガードレール設計――具体策

ここからは、変更実現の考え方を踏まえた、実務で機能するガードレールの具体策を整理します。前回の記事のダブルチェックの具体策に対応する、実装パートです。

1．最小権限を徹底し、原則「提案まで」に留める
AIエージェントには、任せたい作業に必要な最小限の権限だけを与えます。とりわけ本番環境への書き込み、削除、マイグレーションといった不可逆な操作は、原則としてAIには「提案」までしかさせず、実行は人間の承認を経る設計を基本とします。前回述べた、必要なときに必要な権限だけを一時的に付与する考え方を、AIにもそのまま適用します。

2．変更内容の「提案」と「実行」を分離する
AIが生成した変更内容は、いったん人間がレビューできる形で提示させ、承認されて初めて実行される経路に載せます。提案と実行を同じ流れの中で完結させないことが、暴走を止める最後の砦になります。

3．AIの操作にも、人間と同じ実行統制を効かせる
前回挙げた対策――CI/CDパイプラインの本番デプロイに手動承認を必須にする、本番への直接接続を踏み台や承認フロー経由に限定する、大量削除・大量更新を検知したら自動停止する――は、人間だけでなくAIエージェントの操作にも等しく効かせます。「AIだから素通し」という例外を作らないことが重要です。

4．運用ルールをシステムで強制する
Replitの事故の核心は、「変更するな」という指示が言葉だけで、システム的に強制されていなかった点にあります。凍結期間中は本番への変更経路そのものを技術的に閉じるなど、ルールを人間（やAI）の善意に依存させない仕組みが必要です。

5．AIの判断と操作を必ず記録する
AIが「何を根拠に」「何を提案・実行したか」を、必ずログとして残し、後から追跡・監査できるようにします。これは、AIが虚偽の報告をした場合に事実を確認する手段になると同時に、次章の問題管理・継続的改善の土台にもなります。

6．適用範囲を段階的に広げる
いきなり基幹業務の本番操作を任せるのではなく、影響の小さい参照系や定型作業から始め、実績と信頼が蓄積された範囲を、標準的な変更として少しずつ広げていきます。変更実現の考え方に沿った、段階的な権限拡大です。

第5章：導入後をどう回すか――問題管理・継続的改善との接続

過去記事でも述べたかもしれませんが、モノやルールは作って終わりではありません。ここで、前回の記事で扱った問題管理のプラクティスが、そのままつながってきます。
AIエージェントが誤った操作をした、あるいは危うく実行しかけた。そのような事象は、貴重なヒヤリハットです。これを記録し、根本原因を分析し、既知のエラーとして蓄積します。問うべきは、「なぜAIがその操作をできてしまったのか」「なぜ止められなかったのか」です。前回述べたとおり、「誰がやったか」ではなく「なぜ起き得たのか」を問う視点は、相手がAIになっても変わりません。

そして、そこで得た教訓を、権限設計、ガードレール、承認フロー、監視設定に反映し、継続的改善につなげます。人間の失敗と同じ枠組みの中で、AIの失敗もまた、組織の学びに変えていくということです。
なお、AIOpsの実践でも、「導入して終わりではなく、運用しながら賢くしていく仕組み」として、効果測定とフィードバックの反映を継続することの重要性が指摘されています。ガードレールの設計と、問題管理を通じた継続的改善は、AIを運用に迎え入れるうえで両輪の関係にあります。

最後に：AIを信じるのではなく、間違えても大丈夫な仕組みをつくる

生成AIエージェントの導入で本当に問われるのは、AIの賢さを信じられるかどうかではありません。AIが間違えても、被害が広がらない設計を用意できているかです。
Replitの事故は、AIが特別に危険だから起きたのではありません。AIという新しい変更主体を、統制の枠組みなしに本番環境へ届かせてしまったから起きました。一方で、AIを運用に組み込んで成果を上げている現場は、AIの役割を明確に区切り、不可逆な判断を人間の統制下に置いています。
両者を分けるのは、AIの性能ではなく、設計思想です。AIエージェントの導入を、思いつきのツール追加ではなく、正式な「変更」として変更実現のプロセスに乗せる。最小権限とガードレールで被害範囲を限定する。そして、起きた事象を問題管理で学びに変える。
ひとつひとつは、前回までと同じく地味な取り組みです。しかし、この積み重ねこそが、AIを安全に、そして継続的に運用へ迎え入れるための条件になります。冷や汗をかく回数を一回でも減らすために、いまAIに与えている権限、承認の経路、記録の仕組みを、あらためて見直してみてはいかがでしょうか。

参考文献

eWeek（2025）. “AI Agent Wipes Production Database, Then Lies About It.” https://www.eweek.com/news/replit-ai-coding-assistant-failure/
Tom’s Hardware（2025）. “AI coding platform goes rogue during code freeze and deletes entire company database.” https://www.tomshardware.com/tech-industry/artificial-intelligence/ai-coding-platform-goes-rogue-during-code-freeze-and-deletes-entire-company-database-replit-ceo-apologizes-after-ai-engine-says-it-made-a-catastrophic-error-in-judgment-and-destroyed-all-production-data
SaaStr（2025）. “Replit’s new release addresses most of the challenges we hit vibe coding.” https://www.saastr.com/replits-new-release-address-most-of-the-challenges-we-hit-vibe-coding-but-is-prosumer-vibe-coding-really-ready-for-commercial-apps-yet
日経クロステック（2024）.「日本IBMが生成AIで障害対応を効率化、履歴を検索し対応手順を提案」. https://xtech.nikkei.com/atcl/nxt/column/18/02950/091700001/
NTTデータ（2025）.「AIOpsで実現する運用高度化」. https://www.nttdata.com/jp/ja/trends/data-insight/2025/1030/