はじめに
システム開発において、AI エージェントによるコーディングが浸透しました。個人としても、業務や個人開発問わず AI エージェントなくては開発はできないと言って差し支えありません。
しかし、ことシステムの「運用」における AI の浸透は、開発と比較してまだまだ発展の余地があると感じます。
運用を実現するためのツール開発とその検証により、運用における AI 活用の現在地を分析してみます。
なお、この記事における「運用」とは、監視、アラート、アラートを受けての一次対応およびトラブルシュート、障害対応等、システムが安定して動作するために必要となりうる行い全般を指します。
AI による「開発」と「運用」の違い
開発と運用、この両者における違いのひとつは、ガードレールの成熟であると思われます。
開発におけるガードレール
開発タスクに関して、今まで多くの積み上げにより安全な開発とリリースが可能となっています。
例えば、ユニットテストとCI, コードレビューと Git flow による開発、staging 環境、リリースサイクルの自動化 & ロールバックの整備などが今まで積み上げられました。
AI の開発もこれらの恩恵を享受し、基本的に人間の振る舞いを模していれば適切なタイミングでコードレビューなどの人間の介在が挟まり、品質を担保した状態でリリースを迎えることができます。
また、開発タスクにおいては、成果物をパッケージしリリースするまでは、開発マシン上のコードベースにどのような変更が入っても現実世界に影響が及ぶことはありません。開発用マシンという、ある種のサンドボックスの中で開発タスクは行われていると言えます。
AI 開発で広く普及している claude code を使用する際に、 devContainer と --dengerously-skip-permission を活用してほぼ人間の介在を必要都しない自律開発を行っている方も多いのではないでしょうか。このような自律開発ができる背景には、開発はサンドボックス内で行われる振る舞いであること、成果物がリリースされるまでにガードレールが複数存在することが理由として考えられます。
運用におけるガードレール
運用タスクにおいてはどうでしょうか。わかりやすいガードレールの例でいうと、複数人でのダブルチェックが挙げられます。このガードレールはAIと協調して運用タスクを進める際でも有用です。
開発タスクとの決定的な違いとして、サンドボックス環境がデフォルトで存在しないという点です。運用タスクにおけるすべての作業は、基本的には実環境上で行われ、現実世界（ユーザー、または他の開発者）に影響を及ぼす可能性があります。[1]
運用タスクはその性質上、要件を満たすサンドボックス環境を用意することが難しく、これにより AI の自律的な運用を阻害しているのではないかと想像します。
ここまでのまとめ
ここまでの文章をまとめます。論点は2点です。
- 開発タスクにおいて、ガードレールの発達と、タスクの性質により強制されるサンドボックス環境が AI にとってフィットしたため、活用が進んでいる現状が確認できます。
- 運用タスクにおいても、これらの発達とともに AI による自律的な運用が普及すると想像します。
ガードレール、サンドボックスの運用タスクへの適用
開発タスクにおけるガードレール、サンドボックスに相当するものを運用タスクで同様に考えてみます。
人間が実行する運用タスクはどうだったか
今は人間がタスクを実行していると思いますが、我々はどうして運用タスクをこなすことができているのでしょうか？
以下の考慮や対策を実施されているのではないでしょうか。
- 実行してはいけないコマンドは権限により制御されている
- 気軽に実行していいコマンドと実行すべきでないコマンドを使い分けている
実行してはいけないコマンドは権限により制御されている
例えば sudoers、 MySQL ユーザー、IAM Role などの権限管理システムにより、そもそも実行できる範囲が明確に定められている環境が考えられます。
このような環境が整備されていれば、その権限の範囲内で AI は自律的にタスクを遂行できます。この環境は、サンドボックスに相当すると言えるのではないでしょうか。
もちろん、Read Only であれば何をやってもいいのかというとそうではなく、AWS SecretManager などから秘匿情報を参照できてしまい、原理的にはその秘匿情報を外部に送信できてしまう場合がありますね。
また、運用タスクの中には非可逆な変更を行うものも多くあるでしょう。
この対策は非常に有効ではありますが、この対策により全ての運用タスクを内包できるかというとそうではないことがわかります。
気軽に実行して良いコマンドと実行すべきでないコマンドを使い分けている
権限は大きめに与えられているが、システムへの理解が深いため実行すべきものやそうでないものを把握しているパターンです。これは熟練した運用者が暗黙で行っている振る舞いであると言えます。
端的に言えば、MySQL サーバ内で sudo systemctl stop mysql を打つべきではない、というものですね。
人間は、脳内にホワイトリストやブラックリストを持っており、その組み合わせにより実行するコマンドを決定しています。
このリストを、メンテナンス可能な粒度でスクリプトやツールに切り出し、AI に利用させることで、サンドボックス的運用が可能になるのではないでしょうか。
あるいは、人間と AI がダブルチェックをしつつコマンドを実行する、モブオペ形式で疑似サンドボックスを実現することも可能であると思います。
ダブルチェックをやってみた
実際に claude code に権限を渡したうえで、human-in-the-loop を厳密に行うことで運用タスクを任せてみたことがあります。
結論、このアプローチでは運用を楽にすることは難しいと感じました。
human-in-the-loop を行う際の人間への負荷はかなり大きいなと感じました。
claude code がコマンドを提案し、内容を確認し、実行する。このループの中で、目grepに失敗するとなにか想定外の影響が及んでしまうかもしれない、という状況はなかなか高負荷です。
この経験により、「human-in-the-loop の回数は少ないほうがいい」という知見を得ました。
human-in-the-loop を減らすには、手順書の作成では不十分です。レビューされ安全性が担保されたツールを、AIが実行するのみという構図に持ち込む必要があります。LLM の特性上、手順書通りに AI がコマンドを実行してくれる保証はどこにもありません。
ツールを作ってみた
AI とツールと言えば MCP Server ですね。作ってみました。[2]
設計思想として、「AI が使える MCP Server を作る」というアプローチではなく、「人間が運用に使うツールに MCP Server の実装を入れる」というアプローチを取っています。つまり、人間と AI が同じツールを用いて運用タスクを実行することを理想に掲げています。
以下は、「falco のメモリ使用率が異常に高くなるケースがあるため、ノードのメモリ使用率が高い場合、内訳を調査して falco を再起動する」という運用を任せた例です。
以下のような config を記述することで、運用ツールを定義することができます。[3]
- name: falco
params:
node:
description: The node to operate on
type: string
required: true
validate: []
subtools:
- name: check_mem_usage
script: |
IP=$(kubectl get node {{.node}} -o jsonpath='{.status.addresses[?(@.type=="InternalIP")].address}')
ssh ${IP} ps -eo pid,ppid,cmd,%mem --sort=-%mem |grep falco
params: {}
danger_level: ""
subtools: []
- name: restart
script: |-
IP=$(kubectl get node {{.node}} -o jsonpath='{.status.addresses[?(@.type=="InternalIP")].address}')
ssh ${IP} sudo systemctl restart falco-modern-bpf
この定義をすると、CLI として実行する場合以下のようなコマンドでツールを実行できます。
% operations exec falco_check_mem_usage --set node=example-node-001
MCP Server として claude code に組み込んだ場合、以下のような tool として使用可能となります。
このツールを利用して、claude code が各サーバのメモリ使用量が高くなる原因を調査し、サーバに ssh して systemctl restart falco-modern-bpf を実行することができています。
メリット
このツールのメリットとして、小さい運用ツールとしてパッケージングすることにより AI が自律的にツールを選択して実行してくれる点が挙げられます。
一枚の運用スクリプトであれば、特定の用途でのみ利用することができますが再利用性はありません。複数のツールを組み合わせて、例えば operations-cli を用いて運用スクリプトを組むなどすると、DRY な運用スクリプトを作成することが可能となります。
課題
MCP Server 特有の課題では、タイムアウトするオペレーションに対応できないというものがあります。現状同期的に実行しかできないため、考慮する必要があります。
運用ツールとしての課題を考えるとさらに多くの課題が見つかっています。
一つは、ツールの鮮度を保証できないことです。レビューを経てリリースされた副作用のない運用ツールが、年月を経ることで環境とマッチしなくなったり、意図せず副作用が生じるツールに変わってしまう可能性もあります。
このような事象に対応する方法として、実行履歴をグローバルなデータストアに保管し、最終実行から一定の期間が経ったツールに関しては human-in-the-loop を強制するといった手法が取れると考えています。
2つ目の課題として、ツールの実行結果の評価をオペレータに伝える手段がないことです。
例としてとあるシステムのメモリ使用率を確認するツールを実行し、20% という値をツールのアウトプットとして得たとして、この使用率が高いのか？低いのか？の判断をすることはできません。
例えば 対象のシステムは、通常は50%前後のメモリ使用率である という注釈を得られれば、次に仕様すべきツールを選択することがより簡単になるのではないかと思います。
最後に、ツールの実装が AI による運用の律速となる点が課題としてあげられます。
プラクティスが定まっていない運用に対し、試行錯誤をして精度を上げていく必要があるなか、ツールを書き終えないと運用が始められませんというのは少々無理があります。
前述した、権限管理によるサンドボックスにより、広いケースを対応しつつ、コーナーケースでツールを実装するといったアプローチが現状最適なのではないかと考えています。
まとめ
運用タスクを AI に自律的に実行してもらうために必要となる要素を検討し、その要素を充足するツールの実装によりその効果を検証しました。
結果、ある程度安心感を持って運用を AI に任せられるという結果を得ました。
今後の展開として、human-in-the-loop の効果的な活用と、ツールの拡充による運用範囲の拡大が見込めます。
Discussion