Skip to Content
Docs08. コーディングエージェント保守・運用フェーズでの活用
中級se-practicemaintenanceoperations更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

保守・運用フェーズでの活用

この記事の目的

稼働中システムの保守・運用フェーズで、AI コーディングエージェントコードベースを読み、ファイルを編集し、コマンドを実行して検証するループで開発タスクを遂行する Agent。コード補完と異なり「タスク単位の委任」を受けられる。を障害調査・影響調査コードやデータへの変更が、システムのどこに波及するかを事前に洗い出す作業。レガシー保守で特に重要。AI コーディングエージェントは波及範囲の「当たり付け」に使えるが、動的呼び出しやコード外連携(バッチ・DB トリガ・外部システム)を追い切れないため、「影響なし」の保証には使わない。と修正案・過去経緯の復元・ドキュメント追従・定型保守の自動化に使い分けられるようになります。あわせて、保守フェーズ特有の最重要論点である「本番データ・本番環境を扱う境界線」を引けるようになることを目指します。この記事は「保守対象のシステムを保守するために使う」話で、Agent システム自体の運用(05-operations)とは区別します。

対象読者

  • 稼働中の企業システムの保守・運用(障害対応・改修・問い合わせ対応)を担当する SE
  • 保守作業に AI を取り入れたいが、本番データ・本番環境の扱いで慎重になっている運用担当

前提知識

本文

概要: 保守での使いどころと分担

保守・運用では、反復する調査・改修・記録を調査の補助と定型作業の自動化の候補にできます。下表は本記事の役割分担案であり、各作業の効率向上を保証するものではありません。本番に関わる稼働システムを扱うため、情報と操作の範囲を先に決め、効果とレビュー負荷を測ります。

保守の作業エージェントの役割(発散・下書き)人が握ること・境界線
障害調査ログ/スタックトレース解析・再現手順の推定原因の確定・恒久対策の決定
改修影響調査・修正案の下書き修正の採否・本番反映の判断
過去経緯の調査履歴/チケットからの背景復元経緯の裏取り・意思決定
ドキュメント追従改修に合わせた設計書更新の下書き記載の正しさの確認
定型保守の自動化反復作業の委任・スクリプト化自動化範囲・失敗時の扱い

なお、Agent システム自体の可観測性トレース・メトリクス・ログといった外部出力から、システム内部で何が起きたかを説明できる性質。Agent では技術メトリクスに加えて品質シグナルの設計が必要になる。・インシデント対応は 05-operations が正本です。本記事は「保守対象システムの保守に使う」話に絞ります。

障害調査

障害対応でエージェントが効くのは、調査の初動を速める使い方です。

  • ログ・スタックトレースの解析支援: エラーログやスタックトレースを渡し、原因の候補・関連しそうな箇所を挙げさせます。人が読み解く前の当たり付けに向きます
  • 再現手順の推定: 症状から再現手順の仮説を立てさせ、調査の入口にします。ただし推定であり、実際に再現するかは人が確かめます
  • 原因の確定は人: エージェントの原因候補は仮説です。もっともらしいが誤った原因を断定することがあり、それを恒久対策の根拠にすると誤った修正を入れます。原因の確定と対策の決定は、証拠(ログ・再現・コード)に基づいて人が行います
  • 機微情報に注意: 本番ログには個人情報・業務データが含まれます。渡す前にマスキングし、経路が許容されるかを確認します(企業システム環境の制約と対応)

改修の影響調査と修正案

  • 影響調査: 改修対象の変更が波及する範囲を洗い出させます(影響調査の勘所と限界は レガシーコード理解と仕様復元 が正本)。保守では「小さな改修が思わぬ所に波及する」ことが多く、当たり付けに有用です
  • 修正案の下書き: 修正コードの案を生成させます。ただし保守対象の設計思想・既存の慣習に合うかは人が確認し、動くことでなく設計に沿うことを基準にレビューします
  • 本番反映は人の判断: 修正の採否・リリース判断・切り戻し計画は人が握ります。エージェントは修正案と影響範囲の整理を助けるに留めます

過去経緯の調査

保守では「なぜこの実装なのか」を知ることが、安全な改修の前提になります。

  • 背景の復元: コミット履歴・課題管理チケット・関連ドキュメントを渡し、実装の背景・過去の経緯の仮説を立てさせます。散在する記録の要約に向きます
  • 裏取りが要る: 復元された経緯は仮説です。過去の障害対応・業務上の都合など、記録に残らない理由もあります。重要な経緯は、当時の関係者や一次記録で裏を取ります
  • 「地雷」の発見: 「触ると危なそうな箇所」の指摘に使えます。ただし指摘の有無にかかわらず、改修前の影響調査とテストは省きません

ドキュメントの追従

保守で最も形骸化しやすいのが、改修に設計書が追従しない問題です。ここは自動化の効果が見えやすい領域です。

  • 改修とセットで更新: コード改修に合わせて、設計書・手順書の更新ドラフトを生成させます。「コードは直したが設計書は古いまま」を減らせます
  • 記載の正しさは人が確認: 生成された更新は、改修内容と一致しているかを人が確認します。もっともらしいが実装とズレた記述が入ることがあります
  • 正本をテキストに寄せると効く: 設計書がテキスト(Markdown)に寄っているほど、改修と同じ流れで更新・差分レビューできます(要件定義・設計工程での活用の「正本をテキストに寄せる」段階論)

定型保守作業の自動化

繰り返しの保守作業は、委任・自動化の対象です(自動化・業務効率化パターンを保守文脈に適用)。

  • 反復作業の委任: 定型的なログ集計・設定変更の下書き・軽微な一括修正などを委任し、人はレビューに回ります
  • 失敗時の扱いを決める: 自動化するほど、失敗したときの検知・切り戻し・通知を先に設計します。保守は稼働システムが対象のため、「静かに壊れる」自動化が最も危険です
  • 自動化範囲を保守文脈で絞る: 影響が可逆で検証しやすい作業から自動化します。本番に不可逆な影響を与える操作は、自動化より人の承認(Human-in-the-Loop 設計)を挟みます

本番データ・本番環境を扱う境界線

保守フェーズの最重要論点が、本番との距離です。ここは工程の効率化より安全が優先します。

  • 本番データを安易に渡さない: 調査のために本番データ・本番ログをエージェントに渡す前に、マスキング・匿名化・経路の許容性を確認します。「調査が速くなる」より「顧客データが契約外の経路に出ない」が優先です(権限・秘密情報・破壊的操作への対策)
  • 本番環境への操作は分離する: エージェントに本番環境への操作権限を持たせないのが基本です。調査は読み取り・非本番の複製で行い、本番反映は人が承認して実行します
  • 境界線を契約と経路で引く: 何を渡してよいか・どの操作を許すかは、顧客との契約とツールの提供形態で決まります(詳細は 企業システム環境の制約と対応)

実務での注意点

アンチパターン

  • 障害の原因候補を確定原因として扱う → もっともらしい誤った原因で誤った恒久対策を入れる → 原因の確定は証拠(ログ・再現・コード)に基づき人が行う
  • 本番データを確認せず渡す → 個人情報・業務データが契約外の経路に出る → マスキングと経路確認を渡す前に必ず行う
  • エージェントに本番環境の操作権限を渡す → 不可逆な事故のリスク → 調査は読み取り・複製で行い、本番反映は人が承認して実行する
  • 復元した経緯を裏取りせず改修根拠にする → 記録に残らない事情を見落とす → 重要な経緯は関係者・一次記録で裏を取る
  • 失敗時設計なしに保守作業を自動化する → 稼働システムが静かに壊れる → 検知・切り戻し・通知を先に設計し、可逆な作業から自動化する

チェックリスト

  • 障害の原因確定・恒久対策の決定を、証拠に基づき人が行っている
  • 本番データ・本番ログを渡す前に、マスキングと経路の許容性を確認した
  • エージェントに本番環境への操作権限を与えず、本番反映は人が承認している
  • 復元した経緯・原因を仮説として扱い、重要なものは裏を取っている
  • 改修とセットで設計書を更新し、記載の正しさを人が確認している
  • 保守作業の自動化に、失敗時の検知・切り戻し・通知を組み込んだ

関連トピック

参考資料

  • Application card: GitHub Copilot Chat  — 生成コード・説明の誤り、機微な処理でのレビューとテストに関する提供者の説明。本記事の保守業務への割り当ては独自の設計案です(アクセス日: 2026-09-10)
  • NIST SP 800-218: Secure Software Development Framework  — PW.7/PW.8 のコード検証、RV.3 の原因分析・再発防止。Agent に固有の効率向上を示す資料ではありません(アクセス日: 2026-09-10)

TODO・未確認事項

なし

レガシーコード理解と仕様復元企業システム環境の制約と対応(閉域網・監査・持ち込み承認)