AIがエラーを自己修復する時代へ。Claude Codeで実現する次世代の運用自動化

朝起きて、昨夜発生していた28件のシステムエラーが消えている。誰かが徹夜で直したわけではない。AIがログを読み、原因を特定し、コードを修正して再デプロイを完了させていた。

これは今、開発環境で起きている現実だ。

開発者は「作る」フェーズから「AIに運用を自律修正させる」フェーズへ移行する。

その分岐点について深掘りする。

SNS運用を自動化しませんか？

ThreadPostなら、投稿作成・画像生成・スケジュール管理まで全てAIにお任せ。

無料で始める

AIエージェント運用の新常識。設定から修復までを自然言語で完結させる

AIエージェント運用は「いかに正確にタスクを実行させるか」から「壊れたAIをAI自身に直させる」自己治癒型へ移行している。

38本の定期実行ジョブ（cron）を稼働させているシステムで、外部ライブラリのアップデートにより28件のジョブが同時に停止した事例がある。

この事態を解決したのは「自己修復専用のAIエージェント」だ。

エージェントは失敗したジョブのログを収集し、エラーの共通パターンを分析する。

対象となるソースコードを読み取り、LLMで修正版を生成してファイルを書き換える。

翌朝、28件のエラーは0件になった。

この仕組みの肝は、AIに与える権限の抽象化と、修正範囲の限定にある。

「このファイル以外は触るな」という制約をプロンプトで課し、修正済みであることを示すマーカーをファイルに付与する。

AIによる無限ループや予期せぬ破壊を防ぎ、自律的な復旧を実現する。

また、AIエージェントの設定を自然言語で行うツールも存在する。

「毎朝9時にトレンド情報をまとめて通知して」と伝えるだけで、内部的なジョブ設定が自動生成される。

実行時の権限管理は、閲覧のみの「safe」、ファイル編集が可能な「edit」、全権限を持つ「full」といったラベルで管理される。

しんたろー：
28件のエラーをAIが勝手に直した事例を知ったときは驚いた。
僕もThreadPostの開発でcronジョブを回しているが、エラー通知が来るたびに手動で対応するのが日常だった。
自分で直すのではなく、「直し方をAIに教え込んでおく」という運用へのシフトを感じる。
開発者としての仕事が、コードを書くことから、AIの自律性を設計することに変わっていく。

開発者の新スキル。AIの思考を「観測」し「介入」するアーキテクチャ設計

Claude Codeには、ターミナルでの対話内容や実行したツールの詳細を、外部データ基盤に送信する機能がある。

OTLP（OpenTelemetry Protocol）という標準規格を用い、ログやトレース情報をリアルタイムで送信する。

AIの「思考プロセス」を構造化データとして蓄積できる。

このログをDatabricksのようなデータ基盤に流せば、SQLを使って「過去1週間で最も失敗したAIのタスクは何か」「どのプロンプトが原因でエラー率が上がったか」を分析できる。

AIエージェントの運用スタックは3つの層に進化している。

1層目は「ジョブの実行」。

2層目は「ログの構造化分析」。

3層目が「自律的なエラー修正」。

これからの開発者には、2層目と3層目を繋ぐ「フィードバックループ」を設計する能力が求められる。

Claude Codeの設定ファイルである ~/.claude/settings.json を調整して、テレメトリ機能を有効にする。

認証情報を安全に管理するためのスクリプトを用意し、トークンが切れても自動で更新されるように仕込む。

しんたろー：
Claude CodeのログをDatabricksに飛ばす設定を試した。
ログがテーブル形式で並び、SQLでAIの癖を分析できるようになった。
ターミナルの流れる文字を追うのは、時間の無駄に思えてくる。
自分の代わりに24時間働いてくれるエージェントを管理するには、計器パネルが必要だ。
1人開発だからこそ、こうした監視体制が武器になる。

ここまで読んだあなたに

今なら無料で全機能をお試しいただけます。設定後は完全放置でプロ品質の投稿を毎日生成。

無料で始める

実務への影響。開発フローの変革

開発フローを変えるには、AIエージェントに与える権限の「グラデーション設計」が必要だ。

まずは「閲覧のみ」の権限でログを分析させ、修正案をテキストで出させる。

修正案を人間が確認して、ワンクリックで適用する「Human-in-the-loop」の構成から始める。

システムが出力するログを「AIが読みやすい形」に整えることも重要だ。

標準出力に人間向けのメッセージを流すのではなく、JSON形式などで構造化し、エラーの根本原因を明示的に含める。

これだけで、自己修復エージェントの成功率は向上する。

AIに修正を依頼する際のプロンプト設計には、「制約」を盛り込む。

「修正対象はこのファイルのみ」「既存のロジックは変更せず、エラーハンドリングだけを追加せよ」「修正が終わったら末尾に特定のタグを追記せよ」といった具体的な指示だ。

しんたろー：
「AIに任せるのは怖い」という感覚は理解できる。
しかし、権限を段階的に開放していく設計にしてからは、AIの方が正確に直してくれる場面が増えた。
人間は疲れるし、深夜のバグ修正はミスも多い。
24時間冷静にログを分析し続けるAIを、いかに「安全な檻」の中で働かせるか。
その檻を作るのが、これからのメインの仕事になる。

AIエージェントの自己修復に関するFAQ

Q1: AIエージェントに自己修復を任せる際、誤った修正をしてシステムを壊さないか不安です。

修正範囲を極限まで限定するプロンプト設計が不可欠だ。「修正済みマーカー」をファイル内に埋め込み、一度修正した箇所をAIが二重に触らないようにガードをかける手法が有効である。本番環境のコードを書き換えさせる前に、サンドボックス環境でAIに修正を試行させ、テストが通ったものだけを本番に反映するパイプラインを構築する。最初は権限レベルを「safe（閲覧のみ）」から始め、AIが提示する修正案の精度を人間が評価する段階を経て、徐々に自動化の範囲を広げる。

Q2: ログをDatabricksなどの外部データ基盤に送る具体的なメリットは何ですか？

ターミナルのテキストログでは不可能な「横断的な分析」が可能になる。SQLを用いることで、複数のエージェント間で共通して発生しているエラーの相関関係を特定したり、特定のプロンプト変更後にエラー率がどう推移したかをグラフ化したりできる。AIの「思考の痕跡（トレース）」を長期保存できるため、数週間前に起きた挙動の原因を、後からデータに基づいて検証することも可能だ。エージェントのパフォーマンス改善やAPIコストの最適化を、データドリブンに行えるようになる。

Q3: 自己修復機能を導入するために、既存のシステムを大幅に書き換える必要がありますか？

「外付け」の監視エージェントとして導入するのが現実的だ。既存のシステムのログ出力先を、AIがアクセス可能な場所（クラウドストレージや共有ディレクトリ）に変更するだけで、第一歩は踏み出せる。そのログを定期的に読み取って「修正案を生成する」だけの専用ジョブを1つ追加する。システム本体に手を加えることなく、AIによる「運用アドバイザー」のような仕組みからスモールスタートし、信頼性が確認できた段階で、徐々にコードの自動書き換え権限を与えていくのがスムーズな導入パスだ。