analyze-github-action-logs

GitHub Action のログを分析する

指定したワークフローの最近の GitHub Actions の実行を取得して分析します。エージェント／ステップのパフォーマンスを確認し、無駄な作業やミスを特定して、実行可能な改善策を含むレポートを作成します。

入力

必要な項目は次のとおりです。

• workflow（必須）— ワークフローファイル名または ID（例：issue-triage.yml、deploy.yml）。
• repo（任意）— OWNER/REPO 形式の GitHub リポジトリ。既定値は withastro/astro です。
• count（任意）— 分析する最近の完了済み実行の数。既定値は 5 です。

ステップ 1：最近の実行を一覧表示する

ワークフローの最新の完了済み実行を取得します。--status=completed で絞り込みます。

gh run list --workflow=<workflow> -R <repo> --status=completed -L <count>

状況を把握できるよう、実行 ID、タイトル、ステータス（成功／失敗）、所要時間を一覧表示します。分析対象の実行を選びます。可能であれば成功と失敗を組み合わせ、より多くのステップが実行された実行を優先してください（実行時間が長いほど多くの段階を経ている傾向があり、短い実行は早期に終了している可能性があります）。

ステップ 2：ログを取得する

分析する各実行について、ログ全体を一時ファイルに保存します。

gh run view <run_id> -R <repo> --log > /tmp/actions-run-<run_id>.log

ステップ 3：ステップ／スキルの境界を特定する

各ログファイルを検索し、各ステップまたはスキルの開始と終了を示すマーカーを探します。マーカーはワークフローによって異なるため、次のようなパターンを確認してください。

• Flue スキルのマーカー：[flue] skill("..."): starting／completed
• GitHub Actions のステップマーカー：ログ出力内のステップ名の見出し
• カスタムマーカー：ワークフローで使われている START／END などの区切り文字

grep -n "skill(\|step\|START\|END\|starting\|completed" /tmp/actions-run-<run_id>.log | head -50

これをもとに、各ステップ／スキルに該当する行の範囲を特定します。また、結果を示すマーカーも探します。

grep -n "RESULT_START\|RESULT_END\|extractResult" /tmp/actions-run-<run_id>.log

注：ログファイルによっては、バイナリ／ヌルバイトが含まれていることがあります。必要に応じて grep -a を使用してください。

ステップ 4：各ステップを分析する（サブエージェントを使用）

実行された各ステップ／スキルについて、サブエージェントを起動してそのログ部分を分析させます。何千行ものログでコンテキストを圧迫しないようにするうえで、これは重要です。

各サブエージェントには、次の情報を渡してください。

1. ログファイルのパスと、そのステップに該当する行の範囲
2. ワークフローのスキル指示ファイルがある場合は、まずそれを読んで背景を把握するよう指示します
3. 実行タイトル／コンテキスト（何が行われていたかをサブエージェントが把握できるようにします）
4. 以下の分析基準

分析基準

各サブエージェントに、次の点を評価するよう指示してください。

1. 正確性 — ステップの最終結果／判定は正しかったですか？
2. 効率性 — どのくらい時間がかかりましたか？妥当な基準時間はどれくらいですか？どこで時間が無駄になりましたか？
3. ミス — 誤ったツール呼び出し、変更を加えずに再試行した失敗コマンド、不要な再ビルドなど。
4. 指示への準拠 — スキルの指示がある場合、エージェントはそれに従いましたか？どこで逸脱しましたか？
5. スコープの逸脱 — エージェントは別のステップで行うべき作業をしましたか？
6. 提案 — 見つかった問題を防ぐための、具体的で実行可能な変更。

各サブエージェントには、「概要」「時間分析」「見つかった問題（それぞれの推定浪費時間を含む）」「改善案」を含む構造化された回答を返すよう指示してください。

ステップ 5：レポートをまとめる

すべてのサブエージェントから回答を受け取ったら、調査結果を単一のレポートにまとめます。次の構成にしてください。

実行ごとの概要表

分析した実行ごとに、次の表を含めます。

ステップ／スキル	時間	結果	浪費時間	主な問題

複数にまたがるパターン

複数の実行または複数のステップにわたって発生した問題を特定します。これらは、最も改善効果の高い項目です。よく見られるパターンは次のとおりです。

• TodoWrite の乱用 — 自動実行中に、エージェントがタスクリストの管理に時間を費やす
• サーバー管理の失敗 — ポートの競合、プロセスの終了失敗、古いログファイル
• ツールの誤用 — gh の代わりに curl を使う、jq が見つからないなど
• スコープの逸脱 — あるステップが、別のステップで行うべき作業を実行する
• 不要な再ビルド — 変更がないのにパッケージを何度もビルドする
• テストのタイムアウト — 時間のかかる E2E／Playwright テストを実行し、タイムアウトする
• 指示違反 — エージェントが、指示で明示的に禁止されていることを行う
• 冗長な作業 — ファイルの再読み込み、検索の再実行、依存関係の再インストール

優先度順の推奨事項

すべての実行を通じた推定時間短縮量に基づいて、改善案に順位を付けます。各推奨事項には、次の内容を含めてください。

1. 変更内容 — 編集するファイルと、追加または変更する内容
2. 理由 — 対応するパターンと、実行記録から得られる根拠
3. 推定効果 — 1 回の実行あたりに短縮できる時間

出力

統合したレポート全体を提示してください。ワークフローやスキルのファイルは編集せず、調査結果と推奨事項のみを報告してください。適用する変更はユーザーが決定します。