🪵

GitHub Copilot coding agent の セッションログを深掘りしてみる

に公開
GitHub Actions
GitHub CLI
Observability
GitHub Copilot
Coding agent
tech

背景

以前、Copilot coding agent の PR description はカスタマイズできるのか？検証した という記事を書きました。その検証では PR description の制御に注目していましたが、当時は session log の見方までは十分に深掘りできていませんでした。

今回はその続きとして、自分が普段使いしている個人用リポジトリ上で動いた GitHub-hosted Copilot coding agent のログを見直し、gh agent-task --log だけでは見えない挙動をどこまで追えるかを調べました。

TL;DR

  • 公式の gh agent-task --log で session の流れは追えるが、内容はかなり抽象化されている
  • 実際の挙動を深掘るなら、対応する Actions の実行処理を gh run view --log で見る方がよい
  • この実行処理では、gh run view --log から report_progress、reply_to_comment、git push の結果、COPILOT_AGENT_PROMPT まで確認できた
  • この実行処理では、COPILOT_AGENT_PROMPT を見ることで、agent に渡っていた issue / PR / コメント文脈をかなり具体的に復元できた
  • そのため、単なる要約ではなく、「agent が何を見て判断し、何が実際に起きたか」まで追えた

gh agent-task --log が「session の要約」だとすると、gh run view --log は「agent が残した現場ログ」に近いです。

検証対象は、自分が管理しているリポジトリと、自分が確認権限を持つ session / run log に限っています。

公式ドキュメントではどこまで分かるか

GitHub 公式には、session 追跡手段として Tracking GitHub Copilot's sessions があり、gh agent-task list / gh agent-task view --log が案内されています。

また、Using the Copilot coding agent logs では、session log で agent の進捗や使用ツール、internal monologue を見られると説明されています。

一方で、GitHub-hosted coding agent の session をもっと raw に掘る方法として gh run view --log を使う話や、そこに COPILOT_AGENT_PROMPT が含まれる話までは、少なくとも自分が確認した範囲の公式ドキュメントでは見当たりませんでした。

補足すると、VS Code の Monitor agent usage with OpenTelemetry や、Copilot SDK の OpenTelemetry instrumentation for Copilot SDK のように、OpenTelemetry で agent の挙動を観察する手段もあります。今回はそれらではなく、GitHub-hosted coding agent が GitHub.com 上で実行した session を gh CLI から追う話を扱います。

gh agent-task --log と gh run view --log の違い

gh agent-task --log

こちらは公式が案内している session log です。

  • どの session が存在するかを追いやすい
  • session 名や PR 紐付けが分かりやすい
  • tool 呼び出しや要約された思考は見える

その反面、かなり抽象化されています。例えば、自分の観測では report_progress の内部結果や git push の詳細、Everything up-to-date のような低レベルな実行結果は出てきませんでした。

gh run view --log

こちらは Actions の実行処理に対応する full log です。

  • setup step から cleanup まで時系列で見える
  • report_progress や reply_to_comment の引数と結果が見える
  • git push の結果が見える
  • COPILOT_AGENT_SESSION_ID や COPILOT_AGENT_PREVIOUS_SESSION_IDS が見える
  • COPILOT_AGENT_PROMPT が base64 で残っている

session の「説明」ではなく、「実際に動いた痕跡」を読みたいならこちらの方が強いです。

調査の流れ

自分が使った流れは次の通りです。

gh agent-task view --repo <owner/repo> <pr-number>
gh run list --repo <owner/repo> --limit 100
gh run view <run-id> --repo <owner/repo> --log

まず gh agent-task view で対象 PR に紐づく session を見つけます。次に gh run list で対応する Copilot coding agent の Actions 実行処理を探し、最後に gh run view --log で詳細ログを読みます。

実際に見えたもの

gh run view --log では、少なくとも次のような情報が見えました。

  • report_progress
  • reply_to_comment
  • code_review
  • codeql_checker
  • git push -v origin ...
  • Everything up-to-date
  • COPILOT_AGENT_SESSION_ID
  • COPILOT_AGENT_PREVIOUS_SESSION_IDS
  • COPILOT_AGENT_PROMPT
  • session-log.sh https://api.business.githubcopilot.com/agents/sessions/...

ここまで見えると、session の雰囲気ではなく、かなり具体的な実行過程を追えます。

ケーススタディ: PR コメント対応の処理ログを1本追う

ここでは、ある PR に対するコメント対応の処理ログを1本追います。

  • title: Addressing comment on PR #...
  • event type: pull_request_comment

この実行処理は、PR に対して @copilot で「description を4セクション形式に更新してほしい」と再依頼した時のものです。

先にこのケースから分かったことを短くまとめると、次の通りです。

  1. agent は report_progress を使って PR description を更新しようとしていた
  2. report_progress に渡された prDescription 自体は、4セクション形式で生成されていた
  3. 一方で、run log 上で確実に確認できた git の結果は Everything up-to-date だった
  4. ユーザーから確認できる副作用としては reply_to_comment が残っていた

つまり、description 更新を意図した動きは見える一方、処理ログから確実に確認できる結果はコメント返信だった、と整理できます。

1. agent が見ていた入力文脈

COPILOT_AGENT_PROMPT を decode すると、agent が何を見ていたかが分かります。

この実行処理では、単に「今回のコメント」だけではありませんでした。prompt には次が含まれていました。

  • 現在の PR title
  • 当時の PR description
  • 元 issue の prompt
  • 過去のユーザーコメント
  • 過去の Copilot の返信
  • 今回の新しいコメント

つまり agent は、「前回も description 更新を依頼され、自分は更新したと返信したが、今回また description だけ更新してほしいと言われている」という会話履歴ごとの文脈を受け取っていました。

2. agent の判断

処理ログの中には、agent 自身の判断がそのまま出ていました。

The user wants me to update the PR description to the specified format.
I already did this in the previous session, but they're asking again.
Let me use report_progress to update the PR description again with the proper format.

少なくともこの時点で、agent 自身は「今回の主操作は report_progress による PR description 更新だ」と認識しています。

3. report_progress に渡された内容

その直後、report_progress が呼ばれています。ここで渡されていた prDescription は、ちゃんと4セクション形式でした。

## 概要
README の `## GitHub Project Daily Sync` セクションの `### 注意` に...

## 変更内容
- `README.md` の `### 注意` セクション末尾に以下の項目を追記:
  - `context/github-project-sync-profiles.json` が存在しない場合、スクリプトはエラーで終了します

## 影響範囲
- `README.md`

## テスト
未実施: ドキュメントのみの変更のため

Closes #19

つまり、「フォーマットに従った本文を生成する能力」は実際にありました。

4. ただし git 的には何も変わっていない

ところが report_progress の result を見ると、内部では git push が走り、結果はこうなっていました。

Pushing to https://github.com/<owner>/<repo>
= [up to date] ...
Everything up-to-date
Progress reported successfully.

コード変更がないので、git 的には空です。つまり、少なくとも観測できる範囲ではコード差分も commit も増えていません。

5. 最後に確実に起きているのはコメント返信

その後に実行されているのが reply_to_comment です。

reply: PR descriptionを概要・変更内容・影響範囲・テストの4セクション構成に更新しました。

そして最終要約でも、agent はこう述べています。

PR descriptionを指定のフォーマット（概要・変更内容・影響範囲・テスト）に更新しました。
コード変更はなく、PR説明文のみの更新です。

この処理ログから分かったこと

このケースで重要だったのは、agent がそうしようとしたこと と、実際に観測できた副作用 を分けて見られた点です。

  • 意図として見えたもの: report_progress による PR description 更新
  • 確実に観測できたもの: Everything up-to-date と reply_to_comment

この分け方をしておくと、「agent はどこで判断し、どこで期待通りに反映されなかったのか」を切り分けやすくなります。

COPILOT_AGENT_PROMPT を見る意味

今回の調査で、session 改善に直接使えそうだと感じたのがここです。

COPILOT_AGENT_PROMPT を見ると、その実行処理が単に「何をしたか」だけでなく、「何を見て判断したか」まで追えます。

例えば今回のケースでは、次のことが分かりました。

  • 初回の実行処理は issue 起点だった
  • 後続の実行処理は PR 起点だった
  • コメント対応の実行処理では、前回までの会話履歴も引き継がれていた

この差が分かると、「なぜ今回の実行処理はそう判断したのか」を session 単位で説明しやすくなります。さらに、期待した動作とズレた時に、

  • issue の書き方が足りなかったのか
  • PR description に残っていた文脈が影響したのか
  • コメントで追加した指示がどう取り込まれたのか

を見直せるので、次回の issue 文面や PR コメントの書き方を改善する材料にもなります。

注意点

  • agent-task 自体が public preview なので、ログ構造や環境変数名は将来変わる可能性があります
  • prompt には PR 本文やコメント履歴が入るので、機密情報の扱いには注意が必要です
  • gh run view --log や prompt の確認は、自分が管理するリポジトリと、権限のある session / run log だけを対象にする前提で見るのが安全です

まとめ

公式の gh agent-task --log は session を追う入口として十分便利です。ただ、session を本気で観察したいなら、それだけでは足りませんでした。

GitHub-hosted coding agent の場合、対応する Actions の実行処理を gh run view --log で見ると、report_progress、reply_to_comment、git push 結果、COPILOT_AGENT_PROMPT まで含む raw に近いログを追えます。

Copilot coding agent を運用していて「なぜこう動いたのか」を知りたいなら、gh agent-task --log だけで止めず、gh run view --log まで見る価値があります。

特に、agent が意図したこと と 確実に起きた副作用 を分けて見たい時には有効でした。

参考

Discussion