GitHub ActionsでAIエージェント作業ログを残す：job summary・artifacts・retentionの分け方

このテーマをもう少し広げて見るなら、GitHub ActionsでAI修正PRを作る前に：permissions・secrets・pull_request_targetの安全設計 と GitHub Agentic Workflowsを導入する前に：AI Engine・MCP・権限境界をGitHub Actionsで分ける も合わせて確認してください。ログに残す前に、AI agentへ渡す権限とsecrets境界を固める必要があるため。

3行まとめ

Summary

人間が読む短い結果を残します。

Artifacts

詳細ログ、差分、検証結果を保存します。

PR body

レビュー判断に必要な抜粋だけ置きます。

ログは多く残すより、読む場所と保存場所を分けます。

• GitHub ActionsでAIエージェントを動かすなら、stdoutだけに頼らず、job summary、artifacts、PR本文の3層にログを分けると、あとからレビューしやすくなります。
• job summaryには人間が読む短い要約、artifactsには詳細ログや差分、PR本文にはmerge判断に必要な抜粋だけを置きます。
• secretや本番ログをartifactへ残さないこと、retention-daysと削除運用を決めること、未検証項目を空欄にしないことが重要です。

本文の事実確認には、GitHub Actionsのworkflow commands、job summaries、artifacts、secure use、secrets関連の公式Docsを使っています。Xで伸びているAI agent CI、PR自動化、作業ログ運用の投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

3層

job summary、artifact、PR本文を分けます。

安全

secretや本番情報を残さない条件を決めます。

保存

retention-daysと削除運用を決めます。

YAML

最小workflow例へ落とします。

CIで動いたagentを、あとからレビューできる状態にします。

• AI agentログをjob summary、artifact、PR本文に分ける考え方
• GITHUB_STEP_SUMMARYへ人間向けの短い結果を残す方法
• actions/upload-artifactで詳細ログと差分を保存する方法
• secretや顧客ログをログ保存から外す設計
• retention-daysと削除運用を決める理由
• 最小workflow YAMLの形

AI agentをGitHub Actionsで動かすと、作業ログはすぐ長くなります。AIの思考過程に近いログ、実行コマンド、テスト結果、差分、スクリーンショット、未検証項目を全部stdoutへ流すと、reviewerは読む場所を失います。

ログは多く残すほど良いわけではありません。誰が何を読むためのログかを分けます。

前提知識

項目	内容	見方
Job summary		GITHUB_STEP_SUMMARYへMarkdownを書きます。
Artifacts		upload-artifactでファイルを保存します。
Retention		artifactの保存期間を設定できます。
Secure use		secret redactionは完全保証ではない前提で扱います。

ログ設計は便利さと情報漏えいリスクを一緒に見ます。

GitHub Actionsのworkflow commands公式Docsでは、stepからGITHUB_STEP_SUMMARY環境ファイルへMarkdownを書き込むことで、job summaryへ内容を追加できると説明されています。job summaryはGitHub Flavored Markdownに対応し、workflow runの画面で人間が読みやすい位置に表示されます。

GitHub Actionsのartifacts公式Docsでは、actions/upload-artifactとactions/download-artifactを使って、workflow内や後続確認のためにファイルを保存、共有できると説明されています。artifactにはretention-daysを指定できます。

一方で、GitHub Actionsのsecure useやsecrets関連Docsでは、secretを扱うときの注意も示されています。自動redactionだけに頼るのではなく、secretや本番情報をログへ出さない設計にします。

ログ設計はレビュー設計でもある

AI agentのCI実行は、成功か失敗かだけ見ても足りません。何を読ませたか、どのコマンドを実行したか、どこで止めたか、何を未検証として残したかが必要です。

条件

最初は、job summaryに短い要約、artifactにagent.logとcommands.log、PR本文にSummaryとTests runだけを残すところから始めます。慣れてからdiffやスクショを追加します。

注意点

artifactは便利ですが、保存する情報が増えるほど、情報漏えい、保存期間、コスト、削除運用の責任も増えます。

AI agentログを3層に分ける

項目	内容	見方
job summary		人間向けの短い結果、実行コマンド、未検証。
artifact		詳細ログ、diff、test output、screenshots。
PR body		reviewerがmerge判断に使う抜粋。
workflow log		標準出力。secretや長文は残しすぎない。

すべてをstdoutやPR本文に詰め込まないようにします。

AI agentログは、3層に分けます。

層	置くもの	読む人
job summary	結果、主要コマンド、未検証、artifactリンク	reviewer、PR author
artifact	詳細ログ、diff、test output、screenshots	詳細確認する人
PR本文	merge判断に必要な抜粋	reviewer、owner
workflow log	実行ログ、エラー、step出力	CI調査する人

job summaryは入口

job summaryは、長いログの代わりではありません。レビューの入口です。「何が起きたか」「どこを見れば詳細があるか」を短く示します。

artifactは保管先

artifactは、詳細ログや成果物の保管先です。AI agentの全文ログ、test output、diff、スクリーンショットを残すならartifactへ分けます。

PR本文は判断材料

PR本文は、詳細ログの貼り付け場所ではありません。Summary、Tests run、Not run、Risksのように、人間がmerge判断で見る項目へ絞ります。

job summaryには人間が読む要約を残す

Result

成功、失敗、途中停止。

Commands

実行した主要コマンド。

Not run

未実行と理由。

Links

artifactやPRへのリンク。

job summaryは、長文ログではなくレビュー入口です。

job summaryには、レビュー前に読む短い情報を残します。

入れる項目

項目	内容
Result	success、failed、stopped、needs review
Scope	触ったpathや対象Issue
Commands	実行した主要コマンド
Not run	未実行の確認と理由
Risks	secret、外部通信、権限変更の有無
Links	artifact、PR、workflow run

書き込み例

{
  echo "### AI agent run"
  echo ""
  echo "- Result: needs review"
  echo "- Tests run: npm run typecheck, npm test -- LoginForm"
  echo "- Not run: E2E"
  echo "- Artifact: agent-run-logs"
} >> "$GITHUB_STEP_SUMMARY"

summaryに長文を入れない

AI agentの全文ログをsummaryへ入れると、reviewerは読まなくなります。summaryは短く、詳細はartifactへリンクします。

artifactsには詳細ログと差分を保存する

項目	内容	見方
agent.log		agentの作業ログ。secretは除外。
commands.log		実行コマンドと結果。
diff.patch		レビュー対象の差分。
test-results		テストログ、スクショ、レポート。

artifactは便利ですが、保存する情報を絞ります。

artifactには、あとから確認する詳細情報を保存します。

ファイル	内容
agent.log	agentの作業ログ。secretや本番情報は除外
commands.log	実行コマンド、結果、失敗理由
diff.patch	レビュー対象の差分
test-results/	テストログ、JUnit、coverage、スクショ
not-run.md	未実行項目と理由

artifact名を固定する

artifact名が毎回違うと探しにくくなります。agent-run-logs、test-results、diff-patchのように、用途ごとに固定します。

詳細ログを圧縮しすぎない

tarやzipにまとめると便利ですが、reviewerが中身を見づらくなる場合があります。最初は、agent.log、commands.log、diff.patchのように分けます。

保存前にredactionする

artifactへ保存する前に、secret疑い、顧客情報、本番payload、内部URLを除外します。GitHubのmaskingだけに頼らず、保存対象を作る段階で絞ります。

PR本文にはレビュー判断用の抜粋だけ置く

1. 1要約

   何を変えたか。

2. 2検証

   通った確認と未実行。

3. 3リスク

   残る判断材料。

4. 4リンク

   artifactやworkflow runへ誘導。

PR本文は詳細ログ置き場ではなく、merge判断の入口です。

PR本文には、artifactの全文ではなく、reviewerが最初に見る抜粋だけを置きます。

PR本文の項目	内容
Summary	何を変えたか
Tests run	実行した確認
Not run	未実行と理由
Risks	残るリスク
Artifact links	詳細ログへの導線

これはAIエージェントPRテンプレートで扱った考え方と同じです。PR本文は判断入口、artifactは詳細確認先です。

PR本文に貼らないもの

• agentの長い全文ログ
• secret疑いがあるログ
• 顧客情報を含むtest output
• 大量のスクリーンショット
• CIの全stdout

artifactリンクの扱い

artifactは権限のある人だけが見られる場合があります。公開repoや外部contributorを含む運用では、誰が見られるかも確認します。

secretや本番情報をログへ残さない

Secrets

token、cookie、private key。

Prod data

顧客ログ、DB dump、本番payload。

Internal URL

公開repoでは詳細な内部URLを避けます。

Credentials

cloud keyやdeploy tokenを含めません。

GitHubのmaskingだけに頼らず、保存前に除外します。

AI agentログ運用で一番危ないのは、あとから読むために保存したログへsecretや本番情報が混ざることです。

残さない情報

情報	理由
API key、token、cookie	認証情報そのもの
private key、証明書	漏えい時の影響が大きい
本番DB dump	顧客情報を含む可能性
顧客ログ	個人情報や契約情報を含む可能性
deploy payload	本番操作情報を含む可能性
内部URL	公開repoでは扱いに注意

secret maskingを過信しない

GitHubのsecure use関連Docsでは、secret値は変換されると自動redactionが保証されない場合があることが説明されています。だから、artifactへ入れる前にログを選別します。

保存を止める条件

次の条件に当たったらartifact保存を止めます。

• secret疑いの文字列がある
• 本番ログや顧客情報が混ざっている
• 外部APIのpayloadがそのまま残っている
• .envやcredential fileを含んでいる
• agentが許可外のpathを読んでいる

retention-daysと削除運用を決める

項目	内容	見方
短期検証		1から7日で十分な一時ログ。
PRレビュー		レビュー期間に合わせた保存。
監査		必要なら別の承認済み保管先へ移します。
削除		不要artifactを削除する運用を決めます。

artifactを残すほど、情報管理とコストの責任も増えます。

artifactには保存期間があります。GitHub Docsでは、actions/upload-artifactでretention-daysを指定できることが説明されています。AI agentログでは、必要な期間だけ残します。

保存期間の考え方

用途	例
短期確認	1から7日
PRレビュー	レビュー期間に合わせる
リリース前確認	リリース完了まで
監査	承認済みの保管先へ移す

何でも長期保存しない

AI agentログには、意図せず内部情報が混ざる可能性があります。長期保存が必要なら、artifactではなく、アクセス制御された監査ログ基盤や承認済みストレージへ移します。

削除運用も決める

不要になったartifactを削除する運用も必要です。GitHub Docsにはworkflow artifactの削除に関する案内があります。チームでは、PR close後、release後、期限超過時の削除方針を決めます。

workflow YAMLの最小例

項目	内容	見方
GITHUB_STEP_SUMMARY		Markdown summaryを書き込みます。
upload-artifact		ログと差分をartifact化します。
retention-days		保存期間を指定します。
permissions		必要なscopeだけ与えます。

ログ保存workflowも、permissionsとsecretを小さくします。

最小workflowは、summary、artifact、retentionを分けます。

name: ai-agent-log-demo

on:
  workflow_dispatch:

permissions:
  contents: read

jobs:
  agent:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Prepare log files
        run: |
          mkdir -p agent-logs
          echo "agent result: needs review" > agent-logs/agent.log
          echo "npm run typecheck: pass" > agent-logs/commands.log
          git diff > agent-logs/diff.patch

      - name: Add job summary
        run: |
          echo "### AI agent run" >> "$GITHUB_STEP_SUMMARY"
          echo "- Result: needs review" >> "$GITHUB_STEP_SUMMARY"
          echo "- Tests run: npm run typecheck" >> "$GITHUB_STEP_SUMMARY"
          echo "- Not run: E2E" >> "$GITHUB_STEP_SUMMARY"

      - name: Upload logs
        uses: actions/upload-artifact@v4
        with:
          name: agent-run-logs
          path: agent-logs/
          retention-days: 7

実運用ではredactionを先に入れる

この例は最小形です。実運用では、artifact upload前にsecret疑いの検査、保存対象のallowlist、不要ファイルの除外を入れます。

permissionsは広げない

ログ保存だけならcontents: readで足りる場合があります。PR作成、コメント投稿、artifact削除などを入れると必要scopeが変わるため、jobごとに分けます。

導入初週の進め方

1. 1日目

   job summaryだけを追加します。

2. 2日目

   agent.logとcommands.logをartifact化します。

3. 3日目

   diff.patchとtest-resultsを分けます。

4. 5日目

   secret混入チェックを入れます。

5. 7日目

   retention-daysと削除運用を決めます。

最初から全ログ保存にせず、読むログから整えます。

最初の1週間は、保存するログを増やすより、読めるログを作ります。

1日目: job summaryだけ追加する

AI agent workflowの最後に、Result、Tests run、Not run、Risksだけsummaryへ書きます。

2日目: agent.logとcommands.logをartifact化する

詳細ログをartifactへ分けます。summaryにはartifact名だけを置きます。

3日目: diff.patchとtest-resultsを分ける

diffとテスト結果を別ファイルにします。reviewerが必要なものだけ見られるようにします。

5日目: secret混入チェックを入れる

artifact保存前に、tokenらしい文字列、.env、顧客ログ、本番payloadがないかを確認します。

7日目: retention-daysと削除運用を決める

PRレビュー用途なら短め、監査用途なら承認済み保管先へ移すなど、目的ごとに保存期間を決めます。

失敗時に見直す条件

長すぎる

PR本文やsummaryが読まれません。

未検証不明

Not runが残っていません。

secret疑い

artifact保存を止めます。

保存過多

retentionと削除が必要です。

ログは残すだけでなく、読めて安全であることが大事です。

AI agentログ運用で次の状態が出たら、設計を見直します。

失敗	見直すこと
summaryが長すぎる	artifactへ分ける
Not runがない	summaryとPR本文に固定する
artifactが巨大	保存対象を絞る
secret疑い	uploadを止める
PR本文が長い	artifactリンクに分ける
retentionが長い	用途別に短くする

読まれないログは役に立たない

大量のログを残しても、reviewerが読めなければ意味がありません。summaryは短く、artifactは用途別に分けます。

保存しない勇気も必要

secretや顧客情報が混ざる可能性が高いログは、artifact化しないほうが安全です。必要ならredacted版だけ作ります。

FAQ

全部保存

最初の選択肢にはしません。

summaryのみ

詳細確認にはartifactも必要です。

secret mask

完全保証として扱いません。

PR本文

詳細ログではなく抜粋にします。

迷ったら、誰が何を読むためのログかに戻ります。

AI agentログは全部artifactに残すべきですか

全部はおすすめしません。詳細確認に必要なログだけを残し、secretや本番情報が混ざる可能性があるものは除外します。

job summaryだけで十分ですか

短いPRなら十分な場合もあります。ただし、失敗調査やレビュー証跡が必要なら、artifactに詳細ログを分けます。

secret maskingがあるなら安全ですか

完全保証として扱わないほうがよいです。変換されたsecretやログ内の派生値がredactionされない可能性があります。保存前に除外します。

retention-daysは何日にすべきですか

用途次第です。PRレビュー用途なら短く、監査用途なら承認済み保管先へ移す設計にします。最初は7日程度から始めると見直しやすいです。

PR本文にartifactの中身を貼るべきですか

貼りすぎないほうがよいです。PR本文には判断に必要な抜粋だけを置き、詳細はartifactへ分けます。

---

次に読むなら

参照した主な情報源

• https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions
• https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts
• https://github.com/actions/upload-artifact
• https://docs.github.com/en/actions/managing-workflow-runs/removing-workflow-artifacts
• https://docs.github.com/en/actions/reference/security/secure-use
• https://docs.github.com/en/actions/concepts/security/secrets

次に読むなら

更新履歴

1. 2026年5月31日

   GitHub Actions workflow commands、job summaries、artifacts、secure use、secrets公式Docsを確認して初版を作成しました。

導入時には最新Docsと組織のretention設定を確認してください。

• 2026年5月31日: GitHub Actions workflow commands、job summaries、artifacts、secure use、secrets公式Docsを確認し、初版を作成しました。