{"meta":{"title":"トラブルシューティングのワークフロー","intro":"GitHub Actionsのツールを使用して、ワークフローをデバッグできます。","product":"GitHub Actions","breadcrumbs":[{"href":"/ja/actions","title":"GitHub Actions"},{"href":"/ja/actions/how-tos","title":"方法"},{"href":"/ja/actions/how-tos/troubleshoot-workflows","title":"ワークフローをトラブルシューティングする"}],"documentType":"article"},"body":"# トラブルシューティングのワークフロー\n\nGitHub Actionsのツールを使用して、ワークフローをデバッグできます。\n\n## 初期のトラブルシューティングの提案\n\nワークフロー実行に失敗した場合、トラブルシューティング方法はいくつかあります。\n\n> \\[!NOTE]\n> GitHub Copilot Free サブスクリプションを使用している場合、これは毎月のチャット メッセージの制限にカウントされます。\n\n### GitHub Copilot の使用\n\n失敗したワークフローの実行に関する GitHub Copilot を使用してチャットを開くには、次のいずれかを実行できます。\n\n* マージ ボックスで失敗したチェックの横にある \\[****] をクリックし、\\[** エラーを説明**] をクリックします。\n* マージ ボックスで、失敗したチェックをクリックします。 ワークフロー実行の概要ページの上部にある \\[**エラーの説明** クリックします。\n\nこれにより、 GitHub Copilotが表示されたチャット ウィンドウが開き、問題を解決するための手順が提供されます。\n\n### ワークフロー実行ログの使用\n\n各ワークフローの実行では、表示、検索、ダウンロードできるアクティビティ ログが生成されます。 詳しくは、「[ワークフロー実行ログの使用](/ja/actions/how-tos/monitor-workflows/use-workflow-run-logs)」をご覧ください。\n\n### デバッグ ログを有効にする\n\nワークフロージョブあるいはステップが期待どおりに動作しない理由を診断する上で、十分な詳細がワークフローのログになかった場合、追加のデバッグロギングを有効化できます。 詳しくは、「[デバッグ ログを有効にする](/ja/actions/how-tos/monitor-workflows/enable-debug-logging)」をご覧ください。\n\nワークフローで特定のツールまたはアクションを使う場合は、デバッグまたは詳細ログ オプションを有効にすると、トラブルシューティングのためのより詳細な出力を生成できます。\nたとえば、npmは `npm install --verbose`、gitは `GIT_TRACE=1 GIT_CURL_VERBOSE=1 git ...` を使用できます。\n\n## 請求エラーの精査\n\nActions の使用には、[ワークフロー アーティファクト](/ja/actions/tutorials/store-and-share-data)のランナーの時間 (分) とストレージが含まれます。 詳しくは、「[GitHub Actions の課金](/ja/billing/concepts/product-billing/github-actions)」をご覧ください。\n\n### 予算の設定\n\nActions の予算を設定すると、課金またはストレージのエラーが原因で失敗したワークフローのブロックをすぐに解除できることがあります。 設定した予算額に達するまで、追加の分数とストレージ使用量が課金されます。 詳細については、「[従量制課金製品の支出を管理するための予算を設定する](/ja/billing/how-tos/set-up-budgets)」を参照してください。\n\n## メトリックを使用した GitHub Actions アクティビティの確認\n\nメトリックを使用してワークフローの効率と信頼性を分析するには、「[GitHub Actions メトリックの表示](/ja/actions/how-tos/administer/view-metrics)」を参照してください。\n\n## ワークフロー トリガーのトラブルシューティング\n\n最初に、ワークフローが手動で無効になっていないことを確認します。 [ワークフローの無効化と有効化](/ja/actions/how-tos/manage-workflow-runs/disable-and-enable-workflows) を参照してください。 無効なワークフローは、そのトリガーに応答しません。\n\nワークフローの `on:` フィールドをレビューすることで、ワークフローをトリガーするために想定されることを理解できます。 詳しくは、「[ワークフローをトリガーする](/ja/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow)」をご覧ください。\n\n使用できるすべてのイベントの一覧については、「[ワークフローをトリガーするイベント](/ja/actions/reference/workflows-and-actions/events-that-trigger-workflows)」をご覧ください。\n\n### 発火イベント条件\n\n一部のトリガー イベントは、既定のブランチ (つまり `issues`、`schedule`) からのみ実行されます。 既定のブランチの外部に存在するワークフロー ファイル バージョンは、これらのイベントではトリガーされません。\n\npull request にマージの競合がある場合、`pull_request` アクティビティではワークフローは実行されません。\n\nコミット メッセージにスキップ注釈が含まれている場合、`push` または `pull_request` アクティビティでトリガーされるワークフローはスキップされます。 詳しくは、「[ワークフロー実行をスキップする](/ja/actions/how-tos/manage-workflow-runs/skip-workflow-runs)」をご覧ください。\n\n### 予期しない時間に実行されるスケジュールされたワークフロー\n\nスケジュールされたイベントは、 GitHub Actions ワークフロー実行の負荷が高い期間中に遅延する可能性があります。\n\n高負荷時間には、毎時の初めが含まれます。 負荷が十分に高い場合、キューに登録されたジョブの一部が削除される可能性があります。 遅延の可能性を減らすために、Ⅰ時間の中の別の時間帯に実行されるようワークフローをスケジューリングしてください。 詳しくは、「[ワークフローをトリガーするイベント](/ja/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule)」をご覧ください。\n\n### フィルター処理と差分の制限\n\n一部のイベントでは、カスタマイズ可能なブランチ、タグ、パスによるフィルター処理が可能です。 フィルター条件が適用されてワークフローがフィルターで除外される場合、ワークフロー実行の作成はスキップされます。\n\nフィルターには特殊文字を使用できます。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet)」をご覧ください。\n\nパス フィルター処理の場合、差分の評価は最初の 300 ファイルに制限されます。 フィルターによって返される最初の 300 ファイルと一致しないファイルが変更された場合、ワークフローは実行されません。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/actions/reference/workflows-and-actions/workflow-syntax#git-diff-comparisons)」をご覧ください。\n\n## ワークフロー実行のトラブルシューティング\n\nワークフロー実行には、ワークフローがトリガーされ、ワークフロー実行が作成された後に発生したすべての issue が含まれます。\n\n### ジョブ条件のデバッグ\n\nジョブが予期せずスキップされた場合、またはスキップされることが想定されていたときに実行された場合は、式の評価を表示して、その理由を確認することができます。\n\n1. ワークフロー実行でジョブをクリックします。\n2. ジョブのメニューからログ アーカイブをダウンロードします。\n3. `JOB-NAME/system.txt` ファイルを開きます。\n4. `Evaluating`、`Expanded`、および`Result`行を探します。\n\n`Expanded`行には、`if`条件に置き換えられた実際のランタイム値が表示され、式が`true`または`false`に評価された理由が明確になります。\n\n詳しくは、「[ジョブ条件式ログの表示](/ja/actions/how-tos/monitor-workflows/view-job-condition-logs)」をご覧ください。\n\n### ワークフローの取り消し\n\n[UI](/ja/actions/reference/workflows-and-actions/workflow-cancellation) または [API](/ja/rest/actions/workflow-runs?apiVersion=2022-11-28#cancel-a-workflow-run) による標準の取り消しが期待どおりに処理されない場合は、実行中のワークフロー ジョブに対して取り消されない条件付きステートメントが構成されている可能性があります。\n\nこのような場合、API を利用して実行を強制的に取り消すことができます。 詳しくは、「[ワークフロー実行の REST API エンドポイント](/ja/rest/actions/workflow-runs?apiVersion=2022-11-28#force-cancel-a-workflow-run)」をご覧ください。\n\n原因のひとつとして、ステータスチェック機能が取り消し時でもを返す場合が考えられます。\n`cancelled()` 関数の逆関数である `${{ !cancelled() }}` を使う方法もあります。\n\n詳細については、「[条件を使用してジョブの実行を制御する](/ja/actions/how-tos/write-workflows/choose-when-workflows-run/control-jobs-with-conditions)」および「[ワークフローの実行をキャンセルする](/ja/actions/how-tos/manage-workflow-runs/cancel-a-workflow-run)」を参照してください。\n\n## ランナーの問題解決\n\n### ランナーラベルを定義する\n\nGitHubホストランナーは、[](/ja/actions/reference/runners/github-hosted-runners#standard-github-hosted-runners-for-public-repositories) リポジトリで保持される`actions/runner-images`を利用します。\n\n大規模なセルフホステッド ランナーには、一意のラベル名を使うことをお勧めします。 ラベルが既存のプリセット ラベルのいずれかと一致する場合、どの一致するランナー オプションでジョブが実行されるかが保証されず、ランナーの割り当てに関する issue が発生する可能性があります。\n\n### セルフホステッド ランナー\n\nセルフホスト ランナーを使用する場合、そのアクティビティを見て、一般的な問題を診断できます。\n\n詳しくは、「[自己ホストランナーのモニタリングとトラブルシューティング](/ja/actions/how-tos/manage-runners/self-hosted-runners/monitor-and-troubleshoot)」をご覧ください。\n\n### セキュリティ スキャナーによってフラグが設定されたランナー IP アドレス\n\nGitHubホストランナーは、共有インフラストラクチャから動的に割り当てられた IP アドレスを使用します。 これらの IP アドレスは、Meta API ( `actions` キーや `actions_macos` キーなど) を介して発行されます。 詳細については、「[メタデータ用 REST API エンドポイント](/ja/rest/meta/meta#get-github-meta-information)」を参照してください。\n\nサード パーティの脅威インテリジェンス サービス、IP 評判スキャナー、またはファイアウォール ベンダーは、これらの IP アドレスに \"悪意のある\" または \"疑わしい\" としてフラグを付ける場合があります。 基になるインフラストラクチャは共有されるため、同じインフラストラクチャの他のユーザーからのアクティビティは、これらのアドレスに割り当てられた評判スコアに影響を与える可能性があります。\n\nGitHub はサードパーティの IP 評判リストを制御せず、その正確性や更新頻度についてコメントすることはできません。 IP アドレスが GitHubホストランナーに属しているかどうかを確認するには、Meta API によって返される IP 範囲を確認します。\n\nMicrosoft所有 IP アドレスに関するセキュリティ上の懸念がある場合は、[Microsoft Security Response Center (MSRC)](https://msrc.microsoft.com/report/)に報告してください。\n\n## ネットワークのトラブルシューティングの提案\n\n以下のネットワークの問題については、サポートが限定されます。\n\n* あなたのネットワーク\n* 外部ネットワーク\n* サード パーティ製システム\n* 一般的なインターネット接続\n\nGitHubのリアルタイム プラットフォームの状態を表示するには、[GitHub状態](https://githubstatus.com/)を確認します。\n\nその他のネットワーク関連の問題については、organization のネットワーク設定をレビューし、アクセスしているサード パーティ サービスの状態をレビューします。 問題が解決しない場合は、ネットワーク管理者に連絡してサポートを受けることを検討してください。\n\n問題が不明な場合は、 GitHub のサポートにお問い合わせください。 サポートへの連絡方法の詳細については、「[GitHub Support へのお問い合わせ](/ja/support/contacting-github-support)」を参照してください。\n\n### DNS\n\nドメイン ネーム システム (DNS) の構成、解決、またはリゾルバーの問題が原因で問題が発生する可能性があります。 使用できるログやベンダーのドキュメントをレビューするか、管理者に問い合わせて追加のサポートを受けることをお勧めします。\n\n### ファイアウォール\n\nファイアウォールによってアクティビティが禁止される可能性があります。 このような問題が発生した場合は、使用できるログやベンダーのドキュメントをレビューするか、管理者に問い合わせて追加のサポートを受けることをお勧めします。\n\n### プロキシ\n\n通信にプロキシを使うとアクティビティが失敗する可能性があります。 使用できるログやベンダーのドキュメントをレビューするか、管理者に問い合わせて追加のサポートを受けることをお勧めします。\n\nプロキシを利用するためのランナー アプリケーションの構成については、「[ランナーでのプロキシサーバの使用](/ja/actions/how-tos/manage-runners/use-proxy-servers)」を参照してください。\n\n### サブネット\n\n仮想クラウド プロバイダーや Docker ネットワーク内など、使用中のサブネットや既存のネットワークとの重複により問題が発生する可能性があります。 このような場合は、ネットワーク トポロジと使用中のサブネットをレビューすることをお勧めします。\n\n### 証明書\n\n自己署名またはカスタムの証明書チェーンおよび証明書ストアが原因で問題が発生する可能性があります。 使用中の証明書の有効期限が切れておらず、現在信頼されているかどうかをチェックできます。 証明書は `curl` または同様のツールを使って検査できます。 使用できるログやベンダーのドキュメントをレビューするか、管理者に問い合わせて追加のサポートを受けることもできます。\n\n### IP リスト\n\nIP 許可リストまたは拒否リストにより、想定される通信が中断される可能性があります。 問題がある場合は、使用できるログやベンダーのドキュメントをレビューするか、管理者に問い合わせて追加のサポートを受ける必要があります。\n\nGitHubホストランナーによって使用される IP アドレスなど、GitHubの IP アドレスについては、[GitHubの IP アドレスについて](/ja/authentication/keeping-your-account-and-data-secure/about-githubs-ip-addresses) を参照してください。\n\n静的 IP アドレスは、 GitHubホスト型の大規模ランナーで使用できます。 詳細については、「[より大きなランナーを管理する](/ja/actions/how-tos/manage-runners/larger-runners/manage-larger-runners)」を参照してください。\n\n### オペレーティング システムとソフトウェア アプリケーション\n\nファイアウォールやプロキシに加えて、追加のソフトウェア パッケージのインストールなど、 GitHubホストランナーに対して実行されるカスタマイズにより、通信が中断される可能性があります。 使用できるカスタマイズ オプションの詳細については、「[GitHubホストランナーのカスタマイズ](/ja/actions/how-tos/manage-runners/github-hosted-runners/customize-runners)」を参照してください。\n\n* セルフホステッド ランナーの場合は、「[セルフホステッド ランナー リファレンス](/ja/actions/reference/runners/self-hosted-runners)」で必要なエンドポイントの詳細を確認します。\n\n* WireGuard の構成については、「[WireGuard を使用してネットワーク オーバーレイを作成する](/ja/actions/how-tos/manage-runners/github-hosted-runners/connect-to-a-private-network/connect-with-wireguard)」を参照してください。\n\n* OpenID Connect (OIDC) の構成の詳細については、「[OIDC とともに API ゲートウェイを使用する](/ja/actions/how-tos/manage-runners/github-hosted-runners/connect-to-a-private-network/connect-with-oidc)」を参照してください。\n\n### GitHub でホストされるランナー向けの Azure プライベート ネットワーク接続\n\n構成した Azure Virtual Networks (VNET) 設定内で GitHub ホストランナーを使用すると、問題が発生する可能性があります。\n\nトラブルシューティングのアドバイスについては、[](/ja/organizations/managing-organization-settings/troubleshooting-azure-private-network-configurations-for-github-hosted-runners-in-your-organization) ドキュメントの [](/ja/enterprise-cloud@latest/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/troubleshooting-azure-private-network-configurations-for-github-hosted-runners-in-your-enterprise)GitHub Enterprise Cloud を参照してください。"}