Claude Codeと進めるシステム保守：エラーログ調査とコード読解の実践フロー
1. はじめに：AIは「属人化」を解消するチームメイトだ
こんにちは、divxの黒真典です。
私は、仕事の質は個人の力だけでなく、チーム全体の連携や協調性が良いことによって向上すると信じています。
しかし、「保守」の現場はどうしても「あの人しか仕様を知らない」といった属人化が起きやすい場所でもあります。これは、チーム連携を阻害する大きな課題です。
divxはAIの利用を積極的に推進していますが、私はこのAIこそ、保守の「属人化」という課題に取り組むための最強のチームメイトになると考えました。
AIに「文脈」を共有し、チームの一員としてログを読ませ、コードを解読させる。 そうすることで、ベテランの頭の中にあった知識を、チーム全員がアクセスできる形に変えていくことができます。
今日は、私がチームの連携を保つために、AIをどのように保守業務に巻き込んでいるか、その具体的なフローと検証のプロセスをお話しします。
2. 保守業務の「困難」にAIと向き合う
保守の現場では、日常的に多くの「困難」に直面します。 特に、システム全体に影響を及ぼすような大規模なアクセス集中（例えば、人気ECサイトのタイムセールや、SaaSの基幹機能へのリクエスト集中時）が日常的に発生する大規模プロジェクトでは、その困難は質・量ともに増大します。
なぜなら、こうしたシステム規模とトラフィックの大きさが、以下の問題を引き起こすからです。
ログの「量」が爆発する 「アラートが飛んできた！」その瞬間、1秒間に数千行もの
ログが複数のコンポーネントから同時に吐き出されていることも珍しくありません。
サービス全体に影響が出ているかもしれない状況で、これを人間の「気合」や「経験」
だけで特定するのは限界があります。仕様の「複雑さ」が属人化を生む 機能追加や改修を重ねるうち、ドキュメントは古くなり、
仕様の全体像は「過去の担当者」の頭の中にしか存在しない…という状況
が生まれます。この「属人化」こそが、チームの生産性を阻害する最大の要因です。
この「人間の処理能力を超える膨大なログ」と「属人化してしまった複雑な仕様」。 これらこそ、AIの最も得意とする領域だと私は判断しました。
AIは、人間なら何時間もかかる（あるいは見落としてしまう）膨大なログデータから、瞬時に異常なパターンを検出してくれます。 また、AIは、ブラックボックス化したコードを読み解き、仕様を「分析」してくれる優秀なアシスタントにもなります。
「気合」で立ち向かうのではなく、AIという新しい技術を駆使して「まず動いてみる」 これこそが、大規模システムの保守という「困難」に対する、私たちの取り組みです。
3. 実践フロー：AI（Claude Code）と進める「エラー調査」
まさに先日、私たちが担当するプロジェクトで、セクション2でお話ししたような「大規模なアクセス集中」（システム全体の規模）を起因とする深刻なエラーが発生しました。 今回は、その調査で実際にAIを活用した際のフローを紹介します。
このフローは、日常的なアプリケーションエラーはもちろん、今回のようなログが膨大になる深刻な障害調査であればあるほど、AIの解析能力が活きてきます。
ちなみに、このプロセスを導入してから、私の体感ですが、従来30分〜1時間かかっていた原因の一次切り分けが、10分程度に短縮されるケースも出てきました。これは「個人の経験」だけに頼らず、「AIとの協調」で調査を高速化するアプローチです。
Step 1：状況把握（エラーと時間帯の確認）
まず、アラートをトリガーに、事象の一次切り分けを行います。 「いつ」「どのシステムで」「どんな」エラーが出たのかを確認します。ここで「エラーの発生時刻」が、後のログ追跡における重要なアンカーポイントになります。
Step 2：証拠収集（CloudWatchログの特定）
発生時刻を元に、AWSのCloudWatchで該当時間のログを調べます。 やみくもに全部見るのではなく、エラーが出ているサービスや、関連しそうなコンテナのログに絞り込みます。 そして、その周辺の「関連ありそうなログ」をコピーします。
Step 3：AIへの「依頼」（最重要）
ここが最大のポイントです。 コピーしたログをAI（Claude Code）にコンテキスト（文脈）を欠いたまま「これ直して」と丸投げしても、期待する回答は得られません。それではAIを「ツール」としてしか使えていません。
AIを「チームメイト」として扱うため、「文脈」をしっかり共有します。divxには「育成好きないい人」が多いですが、AIに対しても同じ姿勢が重要です。
（私が実際にAIに投げたプロンプト例）
私は今、[システム名] の保守をしています。 以下のエラーログは、[時刻] にAWS CloudWatchから取得したものです。
[ここにコピーしたログを貼り付ける]
まず、このログから「どのようなエラー」が発生しているか、要約してください。 また、このエラーがシステムにとって「致命的な問題か」あるいは「無視してもよい警告か」を判断してください。
Step 4：AIとの「仮説検証」（仕様の確認と原因特定）
AIは、人間なら見落とすようなログのパターンを瞬時に解析し、エラーの概要を提示してくれます。
私はシステムの仕様を知っていますが、自分の理解が正しいか、あるいは何か見落としがないか「確認」するために、AIに検証パートナーになってもらいます。
（追加のプロンプト例）
なるほど、[AIが指摘したエラー] が原因のようですね。
私は、このシステムは「[自分の理解している仕様やロジック]」という前提で動作していると理解しています。
このエラーログは、私のこの理解と矛盾しますか？
矛盾する場合、どのログが私の理解と異なる挙動を示していますか？
私の理解が正しいとして、このエラーが発生する「根本原因」として最も可能性が
高いものを3つ挙げてください。
このように、AIを「こちらの仮説をインプットとして受け取り、データ（ログ）と照合してフィードバックを返す、優秀な分析エンジン」として使います。
Step 5：AIによる「解決案」の提示
原因の仮説が立ったら、次は「行動」です。
（追加のプロンプト例）
原因の仮説を理解しました。 その中でも「仮説1」が最も可能性が高そうです。
この問題を解決するための「具体的な修正コード」または「AWSの設定変更手順」を提示してください。
Step 6：AIによる「報告」の準備
無事に解決の目処が立ったら、最後は「チームへの共有」です。 チームの連携は、情報共有の速さと正確さで保たれます。 これもAIに手伝ってもらいます。
（追加のプロンプト例）
解決案をありがとう。 この一連の「エラー発生から解決までの流れ」を、チームに報告するための報告書（マークダウン形式）を作成してください。
以下のフォーマットに従ってください。
発生事象：
発生時刻：
影響範囲：
原因：（Step4で壁打ちした内容）
暫定対応：
恒久対応案：（Step5で提示された内容）
ここまでAIと仮説検証を行えば、エラー調査にかかる時間は劇的に短縮され、かつチームへの共有もスムーズになります。
4. 【応用】AIと解読する「ブラックボックスシステム」
エラー調査だけでなく、「仕様書のないコード」を読み解く時もAIは強力なアシスタントになります。これは「属人化」の解消に直結します。
私は、保守で引き継いだ見知らぬコードを読む時、まずそのコードをAIに渡してこう聞きます。
（コード読解のプロンプト例）
このコード（言語名）の役割と処理フローを、新規メンバーのオンボーディング資料として使えるレベルでステップバイステップで説明してください。 また、この関数が呼び出している他の関数との関連性を、Mermaid記法で図示してください。
こうすることで、コードの全体像を「まず動いて」掴むことができます。 そして、AIが生成したこの説明文自体が、チームの新しい「ドキュメント」になるのです。
5. まとめ：AIをチームの連携に組み込もう
保守は「現状維持」ではありません。 AIという新しい技術を駆使して、過去の資産（ログやコード）を「分析」し、システムをより良く「改善」していく、継続的な取り組みの場です。
そして何より、AIを「チームメイト」として活用することで、「属人化」という保守現場の大きな課題に立ち向かうことができます。
膨大なエラーログを前に、もう時間を溶かす必要はありません。 まずはそのログをコピーして、AIという優秀な「チームメイト」に、「これどう思う？」と話しかける「小さな行動」から始めてみませんか？
あなたの保守業務が、より効率的でチーム連携を強めるプロセスに変わるはずです。
