GitHub Copilotを使用してログを分析する方法
Visual Studio CodeのGitHub Copilotを使用すると、大量のログからエラーを抽出し、時系列を整理して、障害の原因候補と追加調査の手順をまとめることができます。例えばWindowsプラットフォームサポートのブログ記事「GitHub Copilot を利用して、更新プログラムの適用に失敗する状況の調査を実施する」では、実際にCopilotを用いてログを分析し、原因候補の特定と追加調査の手順を整理する過程が紹介されています。
本記事では、収集したログを専用のワークスペースで分析する方法を解説します。
ログには、ユーザー名、端末名、IPアドレス、アクセストークン、接続文字列、顧客データなどの機密情報が含まれることがあります。所属組織の規程とGitHub Copilotの契約を確認し、入力が許可されていない情報は収集時または分析前に削除してください。
ログ分析にCopilotを使用する利点
障害調査では、複数のログに記録された事象を時刻やIDで関連付ける必要があります。Copilotに関連ファイルを参照させることで、次のような作業を効率化できます。
- エラー、警告、終了コードの抽出
- 障害発生前後の時系列の整理
- 複数ログに共通するプロセスID、相関ID、パッケージ名などの追跡
- エラーコードやスタックトレースから原因候補を列挙
- 調査結果の要約と追加確認項目の作成
- 解析用スクリプトや検索コマンドの作成
ただし、Copilotの回答は調査の出発点です。推測を事実として扱わず、元のログと製品の公式ドキュメントで裏付けることが大切です。
事前準備
1. 分析の許可範囲を確認する
ログを収集する前に、次の点を確認しておくと安心です。
- 対象システムのログを取得してよいか
- 所属組織の規程上、外部のAIサービスへ送信できるデータか
- ログに含まれるデータが、利用するGitHub Copilotのプランと機能に適用される契約条件、プライバシー文書、データの取り扱い方針に適合しているか
- 利用するGitHub Copilotのアカウントとプランが組織で承認されているか
- 保存場所、保存期間、分析後の削除方法が決められているか
- インシデント対応中の場合、証拠保全の要件がないか
確認時は、データの利用目的、保存場所と保存期間、モデル改善への利用、サブプロセッサー、削除方法などが、ログの機密区分、個人情報保護、契約上の制限、データ所在地の要件を満たすかを確認するとよいでしょう。これらはプランや使用する機能によって異なり、変更される可能性があるため、実際に適用される最新の文書を参照することをおすすめします。
組織の管理下にあるログを、個人契約のCopilotへ入力しないでください。詳しくはGitHub Copilotを扱う際の情報漏洩対策を参照してください。
2. ログを収集する
問題の調査を行う際は様々なログや構成情報を組み合わせる必要があります。例えば、以下のようなログは問題の調査に必要な構成情報やログを一括で取得するのに役立ちます。
- TSSで収集したWindows Updateやアプリケーションインストールなどのログ
- collect.exeで収集したVisual Studioや.NET Frameworkのインストールログ
- Azure PipelinesやGitHub Actionsなどのビルドログ
ログが収集できたら、調査専用のフォルダーを作成して関連するログをコピーするのがおすすめです。Copilotのエージェント、エージェントが生成したスクリプト、利用者自身の操作によって、ファイルが変更、上書き、削除される可能性があるためです。元のログは読み取り専用の場所へ保管し、Copilotからアクセスできないようにすると安全です。これにより、分析をやり直す場合や、調査結果を元の記録と照合する場合にも、収集時の完全なログを使用できます。インシデント対応などで証拠保全が必要な場合は、組織の手順に従って原本のハッシュ値、取得日時、取得元なども記録しておくとよいでしょう。
3. 匿名化や整形の必要性を判断する
匿名化や整形が必要かどうかは、利用するGitHub Copilotのプランと機能に適用されるデータの取り扱い方針、および所属組織の情報管理規程の両方に基づいて判断するとよいでしょう。規程上、対象データをそのまま扱うことが認められている場合でも、調査に不要な情報は送信しないというデータ最小化の考え方が有効です。
匿名化が必要な場合は、分析用のコピーから不要な機密情報を削除するか、一貫したダミー値に置換する方法があります。匿名化によって調査に必要な情報まで失われる場合は、勝手に加工せず、情報管理者や調査責任者へ許可された方法を確認するのが安全です。
匿名化前のログをGitHub CopilotなどのリモートAIへ渡し、匿名化を依頼しないでください。匿名化の回答が返される前に、未加工のデータがサービスへ送信される可能性があるためです。また、AIによる匿名化には、機密情報の検出漏れ、値の不完全な置換、必要な情報の誤削除が生じる可能性があります。
匿名化には、処理内容を確認できるローカルスクリプトや、組織で承認された専用ツールを使用することをおすすめします。AIを使用する場合は、モデル、処理、ログ、テレメトリを含めてデータが端末外へ送信されないローカル環境であることの確認が欠かせません。処理後は、秘密情報スキャンや定義済みパターンによる検査に加え、人による抜き取り確認も行うと安心です。
| 情報 | 置換例 |
|---|---|
| ユーザー名 | USER_001 |
| 端末名 | HOST_001 |
| IPアドレス | IP_001 |
| メールアドレス | USER_001@example.invalid |
| アクセストークン、Cookie、秘密鍵 | 値全体を削除 |
| 接続文字列 | サーバー名や資格情報を削除 |
異なるログ間の関係を追跡できるように、同じ値は同じダミー値へ置換すると分析しやすくなります。置換前後の対応表を作成する場合は、分析フォルダーの外に保存し、Copilotから参照できないようにするのが安全です。
ログをGitリポジトリ内へ置く場合は、分析を始める前にログのパスを.gitignoreへ追加しておくと安心です。ただし、.gitignoreはCopilotからの除外設定ではなく、誤ってGitへコミットすることを防ぐための対策です。
Visual Studio Codeで分析する手順
- Visual Studio Codeを開き、File > Open Folderから分析用フォルダーだけを開きます。
- ワークスペースにログと調査に必要な資料だけが含まれていることを確認します。
- GitHub Copilot Chatを開き、エージェントを使用できるモードを選択します。
- 最初に、ログの変更や削除を行わず、読み取り専用で調査するよう指示します。
- 分析の目的、障害が発生した時刻、タイムゾーン、正常時との違い、既知のエラーコードを伝えます。
- Copilotが実行しようとするコマンドと参照するファイルを確認し、必要な操作だけを承認します。
- 回答に示された行を元のログで確認し、原因候補と確認済みの事実を分けて記録します。
最初のプロンプトには、次のように目的と出力形式を明示します。
このフォルダー内のログを読み取り専用で分析してください。ファイルの変更、削除、
外部サービスへの送信は行わないでください。
目的:
- 2026-09-19 14:20（JST）前後に発生したインストール失敗の原因候補を調べる
- 複数ログの時刻をJSTへそろえて時系列を作成する
出力:
1. 確認できた事実（ファイル名と行番号を付ける）
2. 原因候補（根拠と確信度を付ける）
3. 情報が不足している点
4. 次に実行する確認手順
「変更しない」「外部へ送信しない」というプロンプトは重要ですが、それだけで操作を防止できるわけではありません。AIは指示を誤って解釈したり、調査に必要だと判断して意図しないツールを選択したりする可能性があります。プロンプトはセキュリティ境界として扱わず、次のガードレールを併用することが大切です。
- 元のログをCopilotからアクセスできない読み取り専用の場所に保管する
- 分析用アカウントとプロセスに、対象フォルダーの読み取りなど必要最小限の権限だけを与える
- ファイルの書き込みや削除、ターミナルコマンド、MCPツールを自動承認しない
- 外部通信が不要な場合は、使用できるツールやMCPサーバーを無効化し、可能であればネットワーク側でも通信先を制限する
- 操作の対象、コマンド、引数、送信先を人が確認してから実行を承認する
プロンプトによる制約、ツールとOSによる技術的な制限、人による承認を組み合わせることで、いずれか一つが機能しなかった場合の影響を抑えます。
目的を伝えて調査計画を任せる
現在のエージェント型モデルは、調査対象を確認し、仮説を立て、必要な検索や集計を選び、得られた結果に応じて次の手順を変更できます。人間が最初から検索語や調査順序を細かく指定すると、指示した範囲だけで調査を終え、モデルが発見した別の手掛かりを追跡できない場合があります。
そのため、具体的な操作手順ではなく、次の情報を伝えて調査計画の作成と実行を任せると、エージェントの能力を活かしやすくなります。
- 調査の目的と、最終的に判断したいこと
- 障害が発生した時刻、症状、正常時との違いなどの既知情報
- 参照してよいファイルと、実行してよい操作
- ファイルを変更しない、外部通信を行わないなどの制約
- 根拠となるファイル名と行番号、反証、確信度を示すなどの完了条件
- 情報が不足した場合は推測で補わず、追加情報を要求すること
例えば、ファイル形式とタイムゾーンの把握、エラーの抽出、時系列の作成、共通IDによる関連付け、原因仮説の検証などは、必須の手順として指示するのではなく、目的を達成するためにエージェント自身が選択できるようにします。ログが大きい場合も、対象範囲の絞り込み、検索コマンド、集計用スクリプトなど、適切な方法をエージェントに計画させます。
人間は、最初に権限と禁止事項を設定し、提示された計画が目的に合っているかを確認する役割を担うとよいでしょう。調査中は、同じ操作の繰り返し、根拠のない仮説への固執、対象範囲からの逸脱が見られた場合に軌道修正すると、エージェントの自律性と安全性を両立できます。エージェントが生成したスクリプトやコマンドは、実行前に内容、対象、出力先を確認することをおすすめします。
分析結果を検証する
Copilotの分析が完了したら、次の項目を確認するとよいでしょう。
- 引用されたファイル名、時刻、行番号が実際のログと一致している
- タイムゾーンや時刻のずれが補正されている
- エラーの原因と、後続して記録された結果を混同していない
- 「事実」「推測」「追加確認が必要な事項」が区別されている
- エラーコードの意味を製品の公式ドキュメントで確認している
- 正常な端末や過去の正常ログとの比較が行われている
- 分析のために作成したファイルに機密情報が再出力されていない
分析後は、組織の保存規程に従ってログ、チャット履歴、生成したスクリプト、調査メモを保管または削除するとよいでしょう。
まとめ
GitHub Copilotのエージェント機能を利用すると、複数のログを横断した検索、時系列の整理、原因仮説の立案と検証を効率化できます。現在のエージェント型モデルの能力を活かすには、調査手順を細かく指定するのではなく、目的、既知情報、制約、完了条件を伝え、調査計画を任せることが重要です。
一方で、ログには機密情報が含まれる可能性があり、AIは指示や分析を誤ることがあります。安全で信頼できる調査にするため、次の点を意識することをおすすめします。
- GitHub Copilotと所属組織の両方のデータ取り扱い方針を確認する
- 元のログを保全し、Copilotから分離した分析用コピーを使用する
- 匿名化が必要な場合は、リモートAIへ渡す前にローカルまたは承認済みの手段で処理する
- プロンプトだけに頼らず、最小権限、ツール制限、ネットワーク制御、人による承認を組み合わせる
- Copilotの回答を結論として扱わず、元のログと公式情報を使って人が検証する
Copilotに調査の探索能力を発揮させながら、データ、権限、最終判断は人間が管理することが、安全で効果的なログ分析の基本です。