※ 2 分・0 回は、2026 年 11 月 12 日に開発環境で計測した実績です。
保守の不安は、人に頼っていること。
担当者の退職・病気・休暇、属人化、夜間休日の障害対応、報告書づくり。人に依存する保守の不安を、運用AI Bot は仕組みで解消します。
BEFORE ── 人が担う保守
- 夜間・休日も、担当者が待機して呼び出される
- ログを読み、直し、手順書どおりに反映する
- 知識は担当者の頭の中。退職すると消える
- 報告書と引き継ぎ資料を、人が作る
AFTER ── 運用AI Bot に任せる保守
- AI が 24 時間見張り、検知して自分で起票する
- 調査・修正・テスト・PR まで AI が行う
- 原因・対処・決めごとは、しくみに記憶される
- チケットに計画・証拠・結果が残り、報告書は不要
運用保守の「作業」を、AI が担う。
課題を自分で管理
SNS の書き込み・エラー・CI の失敗から自動で起票。番号と状態、経緯・証拠・PR がすべて残る。
SNS グループで会話
@ なしでも依頼・質問を拾い、画像・PDF・ログも読む。受付番号と結果を同じグループに返す。
まず計画、OK のあとに直す
変更の要望には計画を示し、了承を得てからテストを書いて直し、専用ブランチで PR を出す。
開発環境は自動で反映
CI が全部合格した変更だけを、承認ゲート経由で入れ替え。失敗したら直前の版に戻す。
本番は人の承認
AI は提案するだけ。承認ゲートが承認者・提案者と承認者が別・計画の一致を確かめてから実行。
記憶で漏れを防ぐ
原因と対処・手順・チームの決めごとを覚え、次の判断に使う。個人情報は覚えない。
書き込むだけで、AI が動く。
開発・テストのあいだ
製品テストの担当・設計者・開発者・テスターが、運用AI Bot のいる SNS グループ（LINE・Teams・Slack）に書き込むだけ。@ は不要です。AI が課題にし、計画を示し、了承のあとに直してテストし、開発環境に反映して報告します。決めたことや保留も漏れなく覚えます。
稼働したあと
グループは、お客様のオーナー・保守担当・運用AI Bot。24 時間 365 日、監視・検知・分析・修正・検証を AI が行い、人の仕事は「承認」だけ。スマホで 1 タップです。稼働後の改善要望も、同じ流れで反映されます。
チケット管理ツールとの違いは、
作業する主体。
チケット管理ツールは、人の作業を記録して見える化する道具です。運用AI Bot は、作業そのものを AI が行います。どちらが優れているかではなく、担う範囲が違います。
| 従来の運用管理ツール | 運用AI Bot | |
|---|---|---|
| 作業するのは | 人（AI は要約や返信案などの補助） | AI（人は方針・判断・承認） |
| 気づく | 監視の通知を人が見る | AI が検知して起票する |
| 調べて直す | 担当者がログを読み、修正する | AI が調査・修正・テストし、PR を出す |
| 反映する | 手順書に沿って人が作業する | 開発は自動、本番は承認ゲートが実行 |
| 報告する | 人が報告書を書く | 計画・証拠・結果がチケットに自動で残る |
夜中に障害が 1 件起きたら
AI が検知して起票する（誰も起こさない）
原因を調べ、修正とテストを行い、PR を用意する
担当者は朝、スマホで内容を見て承認する
決まった手順で反映され、報告は自動で残る
判断する AI と、作業する AI。
運用AI Bot は、対象の業務システムとは別のサーバーで動く独立した基盤です。対象からはログ・ヘルス・リポジトリ・CI の状態を読むだけ。書き込みは Git への PR と、承認済みの反映に限られます。
6 つの入口
SNS の書き込み（画像・PDF・ログ付き）、エラーログ、ヘルスチェック、CI の結果、Git の出来事、定時の起点。人の依頼は常に受け、AI が推定した仕事はチームの規則に合うものだけ扱う。
Router と Worker
Router は対象ごとに常駐し、受け付け・振り分け・回答を担う（シェルもファイル書き込みも使えない）。Worker はチケットごとに起動し、隔離された作業場所で調査・修正・テスト・PR を行う。
等級はプログラムが決める
変更されたパスと内容から、AI ではなくプログラムが等級を判定。金額・権限・個人情報・DB 構造に関わる変更は追加の確認が必要。AI が自分のルールを緩めることはできない。
本番の鍵は承認ゲートだけ
承認ゲートは AI を呼ばないプログラム。承認者の資格、提案者と承認者が別、計画と検証済みの版の一致、凍結期間を確かめてから実行する。
失敗したら自動で戻す
開発環境の反映後、ヘルスが戻らなければ直前の版に自動で戻し、人と AI に知らせる。対象サーバーは決まった命令（反映・戻し・再起動）しか受け付けない。
モデルは選べる
OpenAI 互換・Anthropic 互換の API で接続し、社内で運用しているモデルも使える。Router と Worker で別のモデルを選べる。
任せる範囲は、段階的に。
| レベル | AI がすること |
|---|---|
| L0 観察 | 判断を記録するだけ |
| L1 分析 | 原因を分析して報告 |
| L2 修正案 | PR を作る（マージは人） |
| L3 開発は自動 | 開発環境のマージ・反映・戻し |
| L4 検証と提案 | 検証環境で確かめ、本番を提案 |
「本番を自動で変える」段階は、ありません。
操られても、外に出られない。
業務と分ける
業務システムとは別の基盤。サーバー・ネットワーク・秘密情報を共有しない。
AI は秘密を持たない
AI の実行環境には鍵もトークンも置かず、外部への通信もない。
すべて記録
判断・作業・承認・実行を、改ざんを検知できる監査ログに残す。
数分で切れる権限
Git の権限はリポジトリ単位で、数分で切れるトークンを都度発行。push と PR は AI ではなくコアが行う。
紛れ込んだ指示に従わない
ログやメッセージの中の指示は信頼しないデータとして扱う。規則や権限は文章では変わらない。
いつでも止める
全体の一時停止、期間を決めた凍結、自律レベルの引き下げ、チケットごとの停止。
導入に必要なもの
| 基盤サーバー | 2 vCPU・メモリ 8 GiB・ディスク 64 GB〜（Worker の同時数に応じて増やす）。Linux（Ubuntu 24.04 LTS で検証）＋ Docker Compose v2 |
| 置き場所 | お客様のクラウドまたはデータセンターに専用の 1 台。Azure で検証済み、ほかのクラウド・オンプレミスも同じ構成 |
| ネットワーク | 受信は 443・80。送信は AI モデル・GitHub・SNS の API だけ（許可リストのプロキシ） |
| AI モデル | OpenAI 互換・Anthropic 互換の API（契約と API キー）。社内で運用しているモデルも可 |
| 連携 | GitHub（リポジトリ・CI）、運用グループの SNS（LINE・Teams・Slack） |
| 対象システム | まずはヘルスチェック URL とログの読み取り口から。業務ロジックの変更は不要（設定の追加は必要） |
導入の進め方 ── 観察から始め、確かめながら広げる
事前診断：対象・環境・CI・反映方法を確かめ、必要な設定を一覧に
観察：つないで、AI の判断が人と合うかを確かめる
修正案：SNS と Git をつなぎ、PR の品質を確かめる
開発の自動化：CI 合格の変更を自動で反映・戻す
本番の承認：リリース計画を承認ゲートで実行
提供状況（2026 年 11 月）
提供中
- SNS での依頼・質問・承認
- チケット管理から PR まで
- 開発環境の自動反映と自動の戻し
- 承認ゲート・変更の等級・自律レベル
- コンソール・記憶・監査ログ
順次提供
- 検証環境と本番のリリース計画の運用
- 毎日のまとめの自動配信
- GitLab・Jira などとの連携
- 1 つの基盤で複数のシステム
- SaaS での提供