![GitHub Actionsのbot作成PRが承認後にCI実行可能に：github-actions[bot]、GITHUB_TOKEN、承認運用の確認ポイントの判断ポイントを表す抽象サムネイル](https://msft-watch.blog.mo-gmo.com/wp-content/uploads/2026/06/msft-51-github-actions-bot-created-pr-workflows-approval-github-token-2-1024x576.png)
GitHub Actionsで自動生成されたpull requestを扱うチームに、地味だが重要な変更が入った。2026年6月11日のGitHub Changelogで、github-actions[bot]が作成したpull requestでも、ユーザー承認後にCI/CD workflowsを実行できるようになったと告知された。
これは「botが作ったPRなら、何でも自動でCIを走らせてよい」という話ではない。むしろ逆で、生成された変更をworkflowに渡してよいかを人間が確認し、そのうえでCIを通せるようにするための更新だ。依存関係更新、ドキュメント生成、フォーマット修正、agentic workflow、コード生成PRを増やしている組織ほど、今回の変更をbranch protectionやrequired checksの設計と一緒に読む必要がある。
GitHubやMicrosoftの6月更新をまとめて追う場合は、公開済みの<a href="https://msft-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月 重要トピックまとめ</a>もあわせて確認してください。本記事はMicrosoftおよびGitHubと提携していない立場で、公開情報を利用者目線に整理しています。
3行まとめ
`github-actions[bot]`が作成したpull requestでも、write権限ユーザーの承認後にconfigured CI/CD workflowsを実行できる。
生成されたコードやworkflowを、人間の確認なしで機密情報に触れる実行へ進める変更ではない。
`GITHUB_TOKEN`、Workflow permissions、required checks、CODEOWNERS、branch protectionをまとめて見る。
CIが走ること、CIが必須条件に入ること、コードレビューを通すことは別の段階として扱う。
github-actions[bot]が作成したpull requestでも、write権限を持つユーザーが承認すれば、configured CI/CD workflowsを実行できるようになった。- 変更の中心は「承認後にCIへ載せる」ことであり、bot生成コードを承認なしで実行する緩和策ではない。
- 管理者は
GITHUB_TOKENの権限、ActionsのWorkflow permissions、PR作成/承認設定、required checks、CODEOWNERS、branch protectionをセットで確認したい。
今回の更新で一番避けたい誤読は、「CIが走るようになったから安全になった」という読み方だ。CIを走らせる前に、人間が何を見て承認するのか。CIが通った後に、誰がコードレビューするのか。required checksに載っているworkflowは、bot PRでも本当に必須になっているのか。ここまで分けて初めて、今回の変更は自動PR運用の改善になる。
特に、すでに<a href="https://msft-watch.blog.mo-gmo.com/msft-47-github-agentic-workflows-public-preview-actions-github-token-cost-controls/">GitHub Agentic Workflows</a>やCopilot系の自動化を検討しているチームでは、PRを作るagentと、CI実行を許可する人間と、マージ判断をするレビュー担当を混同しないことが大切になる。
| 見る対象 | 役割 | 最初に確認すること |
|---|---|---|
github-actions[bot] | workflowから作られるPRの作成者として表示される | どのworkflowがPRを作っているか |
GITHUB_TOKEN | workflow jobごとに作られるrepositoryスコープのtoken | permissionsを最小限にしているか |
| write権限ユーザー | 承認待ちworkflow runを開始できる人 | 何を見て承認するか |
| required checks | マージ前に通すべき検査 | bot PRでも必須になっているか |
| branch protection / rulesets | マージ条件を固定する仕組み | CIなしマージの抜け道がないか |
何が変わったのか
主語はbot-created PRであり、すべてのbot、外部agent、PAT運用を同じものとして扱わない。
GitHub Changelogの主語は明確だ。pull requestを作成した主体がgithub-actions[bot]であっても、ユーザー承認後にCI/CD workflowsを実行できるようになった、という変更である。GitHubは、承認を求める理由を、生成されたコードが機密情報にアクセスしうるworkflowを自動実行しないための安全措置として説明している。
github-actions[bot]のPRでも承認後にCIを走らせられる
これまで、GitHub Actionsのworkflowが自分自身のGITHUB_TOKENを使ってpull requestを作ると、別のworkflow runが連鎖して走らないのが基本だった。これは再帰的なworkflow起動を防ぐための重要な制約だが、自動生成PRの運用では困る場面がある。
たとえば、依存関係を更新するworkflow、生成ファイルを再作成するworkflow、ドキュメントを同期するworkflow、フォーマッターの結果をPRにするworkflowがあるとする。PRは開けるがCIが走らない。レビュー担当は緑のチェックを見ずに、変更内容だけでマージ可否を判断してしまう。required checksの設計によっては、CI未実行のままマージに進める余地が残る。
今回の変更は、その穴を埋める。botが作ったPRでも、write権限を持つユーザーが承認すれば、設定済みのCI/CD workflowsを実行できる。つまり、自動PRを人間レビューの対象にしながら、通常のPRと同じようにテスト、lint、build、security checkへ載せやすくなった。
根拠
GitHub Changelogは、github-actions[bot]が作成したpull requestが、user approvalによりCI/CD workflowsを実行できるようになったと説明している。また、以前はこの種のPRでCI/CD workflowsが実行できず、CIを通さないまま誤ってマージされる可能性があったとも説明している。
注意点
承認後に実行できるのであって、bot作成PRが無条件にworkflowを起動できるわけではない。ここを取り違えると、今回の変更を「自動化の安全制限が弱くなった」と読み違える。実際には、人間の承認を挟んでCIに載せられるようにした変更として読む方が自然だ。
以前の問題はCI未実行のままマージできる余地だった
自動PRの危うさは、botがPRを作ること自体ではない。危ないのは、人間が「PRが開いている」「差分が小さい」「botだからいつもの更新だ」と見なし、CIが実行されていないことに気づかないままマージしてしまうことだ。
特に、生成物の更新は差分が単調に見えやすい。lockfile、schema、snapshot、README、API client、翻訳ファイルなどは、見た目だけで安全性を判断しにくい。CIが走らないまま通すと、ビルド不可、型不整合、依存関係の破損、署名やパッケージ生成の失敗を後段で拾うことになる。
今回の変更で、bot PRをCIの外に置かざるを得ない状態は減る。ただし、CIが走ったという事実と、変更内容を採用してよいという判断は別だ。CIは最低限の検査であり、PRの意図、生成元workflow、影響範囲、secretやenvironmentへの接触は人間が見る必要がある。
変更後も人間の承認は残る
承認の意味を軽く扱わない方がよい。GitHub Docsの承認手順では、pull requestのFiles changedを確認し、特に.github/workflows/配下の変更に注意する流れが示されている。これは、workflowを走らせること自体が、runner、token、secret、environment、外部action、社内ネットワークへの接触点になりうるからだ。
承認者は「このPRをマージしてよい」と言っているのではない。「このPR branch上でworkflowを実行してよい」と判断している。コードレビューのApprove、CODEOWNERSの承認、required reviews、branch protection、rulesets、merge queueとは役割が違う。
GITHUB_TOKENとworkflow発火の例外をどう読むか
- 1`GITHUB_TOKEN`が作られる
workflow jobごとにrepositoryスコープのtokenが作られ、job終了後または有効期限で失効する。
- 2`permissions`で絞る
PR作成に必要な`contents: write`や`pull-requests: write`だけを残し、不要なwrite権限を外す。
- 3追加workflowは原則走らない
`GITHUB_TOKEN`で起きたイベントが、連鎖的に別のworkflow runを作らないよう制約される。
- 4PR activityが承認待ちになる
`opened`、`synchronize`、`reopened`などのPR更新で、承認後にCI/CD workflowsへ進められる。
- 5configured workflowsを実行
承認はCIへ渡すための安全確認であり、コードレビューやマージ判断とは分けて扱う。
例外を広いtoken権限やPATで回避する理由にせず、まず承認待ちrunの運用を確認する。
今回の変更を理解するには、GITHUB_TOKENの通常挙動を先に押さえる必要がある。GitHub Actionsでは、workflow jobの開始時に一意のGITHUB_TOKENが作られる。これはrepositoryにインストールされたGitHub Appのinstallation access tokenとして機能し、権限はそのworkflowが属するrepositoryに限定される。
GITHUB_TOKENはjobごとに作られるrepositoryスコープのtoken
GITHUB_TOKENは便利だ。workflow内でリポジトリにアクセスし、issueやpull requestを操作し、APIへ認証できる。しかもjobごとに作られ、jobの終了後または有効期限の到達で失効する。
ただし、便利だからといって広い権限を持たせたままにするのは危うい。workflow YAMLではpermissionsを明示できる。たとえば、PRを作るworkflowだけにcontents: writeやpull-requests: writeを付ける。読み取りだけでよいjobはread-onlyにする。packagesやissuesへ触らないなら、その権限を与えない。こうした最小権限の設計は、bot PRを広げる前の基本になる。
GitHub Actionsの権限設計は、以前の記事で扱った<a href="https://msft-watch.blog.mo-gmo.com/msft-49-github-actions-self-hosted-runner-minimum-version-enforcement/">self-hosted runnerの最低バージョン適用</a>ともつながる。runnerを最新に保つこと、tokenの権限を絞ること、workflow実行前に人間が確認することは別々の層だが、どれか一つだけでは足りない。
通常はGITHUB_TOKEN起点のイベントで追加workflowは走らない
GitHub Docsでは、repositoryのGITHUB_TOKENを使ってタスクを実行した場合、そのイベントは原則として新しいworkflow runを作らないと説明されている。これは、workflowがpushし、そのpushでまたworkflowが走り、さらにpushする、といった再帰を防ぐためだ。
ただし例外がある。workflow_dispatchとrepository_dispatchは常にworkflow runを作る。そして今回の文脈で重要なのが、pull_requestイベントのopened、synchronize、reopenedだ。GITHUB_TOKENを使うworkflowがpull requestを作成または更新した場合、これらのactivity typeでは承認待ちのworkflow runが作られる。PRのmerge boxに承認待ちの表示が出て、write権限を持つユーザーが開始できる。
| イベント | GITHUB_TOKEN起点での扱い | 実務上の確認 |
|---|---|---|
pushなど多くのイベント | 追加workflow runを作らない | 再帰防止のため。bot PRのCIとは別に読む |
workflow_dispatch | workflow runを作る | 手動起動の権限と入力値を確認する |
repository_dispatch | workflow runを作る | 外部起動元とpayloadを確認する |
pull_requestのopened | 承認待ちrunになりうる | PR作成直後に承認者が差分を見る |
pull_requestのsynchronize | 承認待ちrunになりうる | botが追加pushした時の再承認ルールを見る |
pull_requestのreopened | 承認待ちrunになりうる | 再オープン時の状態を見直す |
承認なしで走らせたい場合のtoken選択は別問題
承認なしでworkflowを連鎖させたいという要望はある。GitHub Docsにも、GITHUB_TOKENではなくGitHub App installation access tokenやpersonal access tokenを使うと、別の挙動にできる説明がある。
ただし、それは今回の記事で推奨する近道ではない。PATや広い権限を持つtokenをsecretとして保存すれば、漏えい時の影響、ローテーション、誰の権限で動くか、退職や権限変更時の管理、監査ログの読み方が重くなる。GitHub App tokenでも、Appの権限設計、インストール範囲、private key管理を考えなければならない。
自動化を急ぐほど、「承認が面倒だからtokenを差し替える」という発想になりやすい。だが、botが作るPRをCIに載せたいだけなら、今回の承認待ちrunをまず試す方が健全だ。承認なし実行が必要なケースは、別のリスク評価として切り分けたい。
承認者は何を見てからCIを走らせるべきか
変更されたファイル、生成元workflow、workflow fileの変更をまず確認する。
workflowがどのbranch定義で走り、どのtoken、secret、runnerを使うかを見る。
外部actionの参照先、shell script、build script、install hookの変更を確認する。
secret、environment、deployment、release、package publishに触れるjobを重点的に見る。
self-hosted runnerや社内ネットワークへ到達しうるjobは、承認前に止める選択肢も含めて判断する。
明らかに危ないworkflowは、CIを走らせて検出する前に承認しない判断が必要になる。
承認者の役割は、ボタンを押すことではない。生成された変更を、runnerとworkflowへ渡してよいか判断することだ。これはコードレビューより前に来る安全確認であり、必要ならそこで止める。
write権限ユーザーの承認は安全確認のゲートになる
GitHub Docsの承認手順では、まずpull requestのFiles changedを見る。承認者は、変更されたファイル、生成元workflow、workflow fileの変更、外部action、script、依存関係、secretやenvironmentに触れるjobを確認する必要がある。
特に見るべきなのは、次のような差分だ。
.github/workflows/配下の変更- 外部actionの参照先変更
- shell script、build script、install scriptの変更
- package managerのpre/post install hookに関わる変更
- secret、environment、deployment、release、package publishに触れるworkflow
- self-hosted runnerや社内ネットワークへ到達しうるjob
- 生成元workflow自体の権限変更
ここで問題が見えたら、承認せずにPRを閉じる、workflowを修正する、権限を下げる、別の隔離された確認先で試す。CIを走らせる承認は、失敗を見つけるための入口ではあるが、明らかに危ないworkflowを実行してよいという意味ではない。
.github/workflows/変更は特に強く見る
workflow fileが変わっているPRは、普通のコード差分より慎重に扱う。workflowがどのbranchの定義で走るのか、どのtokenを使うのか、secretにアクセスするのか、どのrunnerで動くのかを確認する必要がある。
pull_request_targetを使えば何とかなる、という短絡も避けたい。pull_request_targetはbase branchの文脈で動くため、fork PRや未信頼コードに対して強い権限を渡す設計になりやすい。必要な場合でも、checkout対象、script実行、secret露出、workflow fileの参照元を細かく見なければならない。今回の記事では、pull_request_targetを回避策として推奨しない。
CI承認とコードレビューを分ける
承認者が押す「Approve workflows to run」は、workflow実行の許可だ。GitHubのreviewでApproveを出すこととは違う。required approving reviews、CODEOWNERS、branch protection、rulesets、merge queueは別のゲートとして残す。
実務では、次のように分けると事故が減る。
| 判断 | 主な担当 | 見るもの | 通っても意味しないこと |
|---|---|---|---|
| workflow実行承認 | write権限ユーザー、repo admin | 差分、workflow、権限、secret接触 | コード内容の承認 |
| CI結果確認 | PR担当、SRE、開発者 | required checks、lint、test、build | 設計や仕様の妥当性 |
| コードレビュー | CODEOWNERS、reviewer | 実装意図、影響範囲、保守性 | 自動テストの網羅性 |
| マージ判断 | maintainer | すべてのゲート、リリースタイミング | 将来の運用リスクゼロ |
この分離は、Copilotや第三者agentの生成変更でも同じだ。生成された変更を検査する観点は、<a href="https://msft-watch.blog.mo-gmo.com/msft-37-github-third-party-agent-security-validation-ga/">第三者コーディングエージェント安全検証</a>やCodeQL、Secret scanningの確認とも重なる。
RepositoryとOrganizationのActions設定をどこで確認するか
個人repository、organization repository、enterprise policyで初期値や許可範囲が変わりうる。
今回の変更を受けて、すぐに全リポジトリでbot PRを増やす必要はない。まず、どの設定が現在の運用を決めているかを棚卸しする。
Repository settingsのWorkflow permissionsを見る
GitHub Docsでは、repository settingsのActions > Generalで、workflow permissionsを確認できる。ここではGITHUB_TOKENのdefault permissionを読み取り寄りにするか、読み書きを許すかを設定する。
ただし、default permissionだけで運用を判断しない方がよい。workflow YAML側でpermissionsを明示していれば、jobやworkflow単位で必要な権限を絞れる。自動PRを作るworkflowは、少なくとも次を確認したい。
contents: writeが本当に必要かpull-requests: writeが必要なworkflowだけに付いているかissues: writeやpackages: writeなど、目的外の権限が残っていないか- organizationやenterprise policyで上位制約がかかっていないか
- reusable workflowやcomposite action側で権限が膨らんでいないか
GitHub ActionsがPRを作成・承認できる設定を確認する
Repository settingsには、GitHub Actions workflowsがpull requestを作成または承認できるかを制御する設定もある。個人アカウントの新規repositoryでは、workflowがPRを作成または承認することは既定で許可されない。organization内の新規repositoryでは、organization settingsを継承する。
この設定は、bot PR運用の入口になる。自動PRを作るworkflowがあるのにPRが作れない。あるいは、意図しないworkflowがPRを作れてしまう。どちらも困る。repo adminは、PR作成の許可と、workflow実行承認のプロセスを同じ棚卸し表に入れるとよい。
OrganizationとEnterpriseのpolicyに上書きされる場合がある
organization ownerやenterprise adminは、repository単位の設定だけを見て終わらせない。Actionsをどのrepositoryで使えるか、GitHub所有actionだけを許すか、marketplace actionを許すか、特定actionだけを許すか、full-length commit SHA pinningを求めるか、public fork workflow approvalをどうするか。こうした上位設定が、bot PRのCI実行可否に影響する。
public repository、private repository、internal repository、Enterprise Managed Usersの環境では、見える画面や有効なポリシーも変わる。記事を読んで設定名を暗記するより、自分たちの階層をまず書き出す方が早い。
| 層 | 主な確認者 | 見る設定 | 未確認時のリスク |
|---|---|---|---|
| Repository | repo admin、maintainer | Workflow permissions、PR作成/承認、required checks | bot PRだけCI外になる |
| Organization | org owner、platform team | Actions policy、allowed actions、fork approval | repo設定と実際の挙動がずれる |
| Enterprise | enterprise admin、security team | enterprise policy、runner制限、監査要件 | 一部組織だけ例外運用になる |
Branch protectionとrequired checksでCIなしマージを防ぐ
- 1bot PRのCIを走らせる
write権限ユーザーが差分を確認し、configured CI/CD workflowsの実行を許可する。
- 2build、test、lint、scanを通す
通常PRと同じ検査が必要なら、bot PR用にも同じworkflowを用意する。
- 3required status checksへ入れる
check名、workflow名、job名、対象branchが保護ルールから外れていないか確認する。
- 4CODEOWNERSと承認レビューを通す
CI承認とコードレビューを混同せず、必要なowner reviewを残す。
- 5rulesetsやmerge queueで統制する
path filterや`[skip ci]`相当の運用が、重要なworkflowを飛ばしていないかを見る。
軽微に見えるlockfile、generated client、設定ファイルの変更でも、最低限の検査を残す判断が必要になる。
CIを走らせられるようになっても、そのCIがマージ条件に入っていなければ、運用上の抜け道は残る。今回の変更を活かすには、branch protectionやrulesetsと一緒に見る必要がある。
required status checksにbot PRのCIを載せる
required checksは、対象branchへマージする前に通すべきstatus checkを決める仕組みだ。bot PRでも通常PRでも、同じbuild、test、lint、security scanが必要なら、required checksに入れる。bot PRのCIが承認後に走るようになったのに、required checksに入っていなければ、結局「走っていないけれどマージできる」状態が残る。
見るべき点は、check名、対象branch、workflow名、job名、merge queueの有無、stale review dismissal、required approving reviews、CODEOWNERSだ。check名が変わるとrequired checksから外れることもある。bot PR用にworkflowを分ける場合は、名前の変更や条件分岐が保護ルールから抜け落ちないようにする。
path filterやskip ciで抜け道を作らない
自動PRでは「docsだけ」「lockfileだけ」「generatedだけ」と見える差分が多い。だからといって、単純にCI不要と決めると危ない。lockfileは依存関係の解決に影響する。generated clientは型やAPI互換性に影響する。READMEや設定ファイルの変更でも、release packageやドキュメント生成workflowに影響する場合がある。
path filterや[skip ci]相当の運用を使っているチームは、bot PRで重要なworkflowが意図せず飛ばされないかを確認したい。軽微な変更に見えるPRほど、最低限のlintやtype checkだけは残す、security scanは別workflowに分ける、release jobはenvironment protectionを使う、といった設計が必要になる。
CODEOWNERSでbot変更のレビュー責任を明確にする
bot PRが増えると、誰が見るのかが曖昧になりやすい。CODEOWNERSは、変更ファイルごとにレビュー責任を明確にする手段になる。CI承認者とCODEOWNERS reviewerは同じ人でもよいが、判断の種類は分ける。
たとえば、.github/workflows/はplatform team、package manager関連はruntime owner、API generated clientはservice owner、docs生成はdocs ownerにする。botが作ったから全員で流し見る、という運用より、ファイルごとに責任者が出る方が強い。
bot PR運用を始める前のチェックリスト
- 1日目現状を棚卸しする
`github-actions[bot]`、GitHub App、Dependabot、Renovate、agent作成PRを分けて確認する。
- 1日目保護設定を確認する
Workflow permissions、PR作成・承認設定、branch protection、rulesets、required checks、CODEOWNERSを見る。
- 2日目から3日目小さなPRで承認フローを試す
誰に承認ボタンが見えるか、承認後にどのworkflowが走るか、required checksに載るかを確認する。
- 4日目から5日目権限と保護ルールを絞る
不要なwrite権限を落とし、secretやenvironmentに触るworkflowは追加の保護を使う。
- 運用開始後失敗時と監査を残す
再実行、修正、再承認、マージ停止の流れを決め、承認ログを後から確認できるようにする。
最初の目的は理想形を一気に作ることではなく、現在の抜け道を見える化することにある。
今回の変更を使うなら、最初に本番repositoryへ広げるのではなく、限定したrepositoryや低リスクworkflowで確認するのがよい。チェックリストは、設定、承認、CI、レビュー、監査に分ける。
1日目は現状を棚卸しする
まず、どのworkflowがPRを作っているかを洗い出す。github-actions[bot]として表示されるPR、GitHub Appとして表示されるPR、Dependabot、Renovateなどの外部bot、Copilotや第三者agentが作るPRを分ける。同じ「bot PR」でも、token、権限、承認待ちrunの挙動が同じとは限らない。
あわせて、repository settingsのWorkflow permissions、PR作成/承認設定、branch protection、rulesets、required checks、CODEOWNERSを確認する。ここで大事なのは、設定の理想形をすぐ作ることではなく、現在の抜け道を見える化することだ。
2日目から3日目は小さなPRで承認フローを試す
次に、低リスクな変更でbot PRを作り、承認待ちrunがどう表示されるかを確認する。誰に承認ボタンが見えるか。Files changedからworkflow変更を確認できるか。承認後にどのworkflowが走るか。required checksに載るか。失敗した時に再実行、修正、再承認の流れが分かるか。
この確認をせずに本番運用へ入れると、いざ重要な自動PRが来た時に、誰が承認するか、どこで止まっているか、なぜrequired checkが出ないかで詰まる。
4日目から5日目は権限と保護ルールを絞る
承認フローが見えたら、permissionsを絞る。PR作成workflowに必要な権限だけを残し、不要なwrite権限を落とす。workflowがsecretやenvironmentに触るなら、environment protectionやrequired reviewersを使う。外部actionは許可リストやSHA pinningを検討する。
同時に、branch protectionやrulesetsでrequired checksを確認する。bot PR用のworkflowが走っていても、requiredに入っていなければ保護にならない。逆に、requiredに入っているcheckがbot PRでは条件分岐でスキップされるなら、保護ルールの意味が薄くなる。
6日目から7日目は運用ログに落とす
最後に、承認者、レビュー担当、マージ担当、失敗時の停止条件を運用ログにする。承認前に見る項目、迷った時に止める条件、workflow変更を含むPRの扱い、secretやenvironmentに触るPRの扱い、例外承認の記録を決める。
ここまで作ると、bot PRは「便利な自動化」ではなく、管理された変更経路になる。CIを走らせられるようになったことより、CIを走らせる前後の責任分担が見えることの方が大きい。
管理者向けの結論
bot PRを作るworkflowとtokenを棚卸しし、広すぎる権限を残さない。
`.github/workflows/`、secret、environment、外部actionを見てからCIを走らせる。
required checks、CODEOWNERS、branch protectionでCI後のレビューとマージを分ける。
PATや広い権限のtokenで承認を迂回する前に、承認待ちrunの運用を試す。
今回の更新は前向きな変更だが、承認なし実行の解禁ではない。
今回のGitHub Actions更新は、自動PR運用にとって前向きな変更だ。github-actions[bot]が作ったpull requestでも、write権限ユーザーの承認後にCI/CD workflowsを実行できるようになり、CI未実行のままマージされるリスクを減らしやすくなった。
ただし、これは承認なし実行の解禁ではない。GITHUB_TOKENの通常挙動、PR activity typeの例外、Workflow permissions、ActionsがPRを作成/承認できる設定、organizationやenterprise policy、branch protection、required checksを一緒に見る必要がある。
実務では、次の4点に絞ると動きやすい。
- bot PRを作るworkflowとtokenを棚卸しする。
- 承認者が
.github/workflows/、secret、environment、外部actionを見てからCIを走らせる。 - required checks、CODEOWNERS、branch protectionでCI後のレビューとマージを分ける。
- PATや広い権限のtokenで承認を迂回する前に、承認待ちrunの運用を試す。
Microsoft Watch JapanはMicrosoftおよびGitHubの非公式・非提携サイトであり、本稿は公開されているGitHub公式情報をもとにした整理です。Docs更新やChangelogの追跡を継続したい場合は、<a href="https://msft-watch.blog.mo-gmo.com/source-checks/">資料・確認ログ</a>と<a href="https://msft-watch.blog.mo-gmo.com/newsletter/">ニュースレター</a>をあわせて使えます。
次に読むなら
更新履歴
- 2026年6月14日JSTGitHub ChangelogとGitHub Docsを確認
`github-actions[bot]`作成PRの承認後CI実行、`GITHUB_TOKEN`、Actions設定、required checksの確認ポイントを整理した。
Docsや設定名は更新される可能性があるため、運用へ入れる前に最新の公式情報を確認したい。
- 2026年6月14日JST: GitHub ChangelogとGitHub Docsを確認し、
github-actions[bot]作成PRの承認後CI実行、GITHUB_TOKEN、Actions設定、required checksの確認ポイントを整理しました。
参照した主な情報源
- GitHub Changelog, Bot-created pull requests can run workflows if approved
Bot-created pull requests can run workflows if approved
- GitHub Docs, GITHUB_TOKEN
https://docs.github.com/en/actions/concepts/security/github_token
- GitHub Docs, Approving workflow runs from forks
https://docs.github.com/en/actions/how-tos/manage-workflow-runs/approve-runs-from-forks
- GitHub Docs, Managing GitHub Actions settings for a repository
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository
- GitHub Docs, Disabling or limiting GitHub Actions for your organization
https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization
- GitHub Docs, Events that trigger workflows
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows