緑のチェックが付いた。その変更を公開していい？

この記事の目次

AIに修正してもらった変更を、GitHubで確認しています。テストには緑のチェック。差分も見て、問題なさそうです。

その後、AIがもう一か所だけ直しました。さっきの緑のチェックは、その追加の修正まで確認した結果でしょうか。

この記事は、AIとコードを作り、GitHubの変更提案や自動検査を使って公開する人に向けたものです。「テストをしましょう」の先にある、何を検査し、どの条件で反映を止め、誰が公開できるかを整理します。

AIの修正をGitHubから公開する前に**そのチェックは、今の変更を確かめた結果？**

修正・検査・反映を、別の仕事として見る

リポジトリは、コードと変更履歴などを管理する場所です。ブランチは、変更を分けて進めるための流れ。例えば公開用のmainとは別のブランチで、修正を作ります。

**プルリクエスト（PR）**は、その変更を取り込むための提案です。コミットは、変更を記録した単位で、どの状態を見ているかを識別できます。

CIは、変更に合わせてビルドやテストなどを自動実行する仕組みです。GitHub Actionsでは、実行する条件と処理をワークフローに記述します。

作る・検査する・反映するを分ける

修正を提案
ブランチとPRで差分を示す。
検査とレビュー
どの状態に何を確かめたかを見る。
マージして公開
取り込んだ変更と公開先を照合。

PR、検査の成功、公開の完了は、それぞれ別の状態です。

PRがあること、CIが実行されたこと、必要な検査が成功したこと、本番へ公開したことは、それぞれ違う状態です。まとめて「GitHubが緑だから大丈夫」と判断しません。

AIへの約束と、GitHubが止めるルールを分ける

AIへ「mainへ直接入れず、PRを作って」と伝えるのは、作業の方針です。実際にその操作を制限するには、GitHub側のルールと権限も確認します。

ルールセットでは、対象のブランチにPRや検査を要求する、削除や履歴の強制的な書き換えを制限する、といった条件を設定できます。ただし、ルールを作っただけでなく、適用状態、対象、回避できる相手も見る必要があります。GitHub公式：利用できるルール

方針を、実際に働く条件へつなげる

公開用ブランチのルール
作っただけでなく、適用された条件を見る。
対象と適用状態
どのブランチに、どの状態で効くか。
必要な手順
PR、承認、必須チェックの条件。
回避できる相手
管理者、アプリなどの例外を確認。

使える機能と運用する人数に合わせ、管理する検証環境で確かめます。

PRを必須にすることと、誰かの承認を必須にすることも別です。一人の開発では、自分のPRを自分で承認できない制約なども考え、実際に運用できる条件を選びます。AIのレビュー文が付いたことだけで、GitHubの要求する承認を満たしたとは判断しません。AIのレビューの合格が何を確かめた結果かは、AIレビューの合格の教材で扱います。

まず自分が管理する検証用のリポジトリで、対象の変更が本当に止まり、必要な手順を通れば進めるかを確かめます。この教材を読んだだけで、現在の公開リポジトリの設定を一括変更する必要はありません。

実行されたチェックと、必須のチェックは同じとは限らない

自動検査の一覧に緑の項目があっても、それが公開前に必要な検査をすべて含むとは限りません。テストがあるファイルだけ走る設定や、条件により省略するジョブもあります。

必須チェックは、反映の前に満たすと決めた検査です。どの名前のチェックを要求し、どのアプリからの結果を信用するか、現在の差分に対する結果かを確認します。

緑の項目を、3つの問いで見る

何を検査した？
ビルド、動作、権限などの実行内容。
どの差分の結果？
追加の修正後にも必要な結果があるか。
何が必須？
必要な名前と結果の出所、省略の扱いを確認。

検査が一つ成功したことだけで、必要な確認すべてを満たしたとは判断しません。

省略された、実行されなかった、検査が始まらなかった。これらを、必要な検査が成功したことへ自動で置き換えません。ワークフローの実行条件や、失敗を許容する設定も確認対象です。

緑のチェックに、何を確かめてもらった？

ビルドだけの成功と、権限やデータ操作まで試したテストの成功は違います。検査名だけでなく、実行した処理と、確認していない範囲を見ます。

古い差分の成功では、今の変更を確認したことにならない

次は、架空の検査記録です。change-Aとchange-Bは、コードの状態を表す仮の識別子。現在確認したいのはchange-Bで、必要な検査はbuildとtestです。

ローカルのNode.jsの練習用ファイルで試す想定です。GitHubへの通信や、実際のマージ・公開は行いません。

function evidence(head, required, results) {
  if (!head || !required.length) return "検査条件が未確認";
  const current = required.map(name =>
    results.find(r => r.name === name && r.commit === head));
  if (current.some(result => !result)) return "必要な記録が足りない";
  if (current.some(result => result.state !== "success")) return "検査は未完了";
  return "この差分の検査記録がそろった";
}
const required = ["build", "test"];
const old = required.map(name => ({ name, commit: "change-A", state: "success" }));
const fresh = required.map(name => ({ name, commit: "change-B", state: "success" }));
console.log("古い成功:", evidence("change-B", required, old));
console.log("今の成功:", evidence("change-B", required, fresh));
console.log("testがない:", evidence("change-B", required, fresh.slice(0, 1)));

古い成功: 必要な記録が足りない
今の成功: この差分の検査記録がそろった
testがない: 必要な記録が足りない

必要な項目がそろっているかと、どの差分の結果かを分けて見ています。この例は「成功」の状態だけを照合する練習です。実際のGitHubには、検査の状態や対象コミットの種類について仕様があり、そのすべてを再現するコードではありません。

記録がそろったことは、コードが安全だという保証でもありません。実際には、検査元、検査内容、レビュー、反映先なども確認します。

同じ緑の表示でも、足りない確認は違う

前の差分が成功している

今の変更への確認は別

追加の修正後に必要な検査があるかを見ます。古い成功の表示だけで終えません。

必要な検査がない

成功と数えない

実行条件や省略、名前の設定を調べます。チェックの不在を、問題なしへ置き換えません。

今の検査記録がそろった

確認した内容を見て次へ

検査した範囲と出所、レビュー、反映先も確認します。全体の安全が保証されたという意味ではありません。

架空の検査記録の比較です。GitHubの全マージ条件を判定する機能ではありません。

検査する処理にも、使える権限がある

CIは、ただコードを眺める場所ではありません。依存を取得し、プログラムやテストを実行することがあります。その処理が秘密や公開権限を使えると、検査するコードの影響も広がります。

例えば次は、GitHub ActionsのGITHUB_TOKENに、リポジトリの内容を読む権限を指定する設定の一部です。完成したワークフローではなく、権限を読むための最小例です。

permissions:
  contents: read

readは、このトークンでの読み取りを示します。これだけで、処理が外部へ通信できなくなるわけでも、別に渡した秘密が見えなくなるわけでもありません。ジョブが必要とする権限と、秘密を受け取る範囲は別に見ます。GitHub公式：Actionsの安全な利用

検査する仕事と、公開する権限を分ける

検査のジョブ
必要な読み取りと実行。不要な秘密や公開権限を渡さない。
公開のジョブ
許可した対象・条件で、必要な公開権限を使う。

トークンの権限、別に渡す秘密、実行するコードと通信を合わせて確認します。

検査と公開の処理を分け、公開に必要な権限をすべての検査へ広げないようにします。外部から来たPRのコードや設定を、強い権限や秘密がある処理でそのまま実行しない設計も重要です。

「外部PRでも検査したいから」と、実行条件や秘密への制限を安易に緩めません。使うイベント、チェックアウトするコード、実行するスクリプト、参照する設定を合わせて確認します。レビューを起動する場所の考え方はAIに任せる権限の教材も参考になります。

検査に使う外部部品が、秘密の露出につながった事故

分類：事故の公表。 tj-actions/changed-filesでは、2025年3月の侵害により、ワークフローのログへ秘密が出る問題が報告されました。管理者の3月22日公開の当事者アドバイザリと、GitHubの公表情報に記録されています。

これは、すべてのGitHub Actions利用者に漏えいがあったという意味ではありません。ここでは悪性コードや秘密を読み出す手順を転載せず、利用していた部品と実行した時期・内容を調べる必要がある事例として扱います。

アプリ本体だけでなく、検査する道具も外部の部品です。誰の、どの内容を、どんな権限で実行するかを考えます。

SHAで固定することと、固定した内容を信頼すること

Actionのタグは、同じ名前でも参照先が変わる可能性があります。完全なコミットSHAで指定するのは、どのコミットを使うかを固定するための方法です。GitHub公式：外部Actionの利用

ただし、固定する相手の提供元や内容が信頼できるかは別です。問題を含むコミットを固定すれば、その問題も残ります。また、Actionの中で実行時に外から取得するスクリプトやイメージまで、同じ指定で固定されたとは限りません。

固定した対象と、まだ変わり得るものを見る

Action本体のコミット
提供元と内容を確認し、完全なSHAで識別する。
実行時に取得する部品
別のスクリプトやイメージの取得元と指定も見る。

本体の固定だけで、実行時のすべての外部取得まで固定されたとは限りません。

固定した後も、新しい修正を取り込む流れが必要です。更新の提案とレビュー、検査、実行した内容をたどれるようにします。通知と更新PRの違いや本番確認は、依存更新の教材へつながります。

「固定した」は、確認した範囲の説明にもなる。

Action本体を固定したのか、そこから取得する別の部品も確認したのか。何を調べたかと、まだ変わり得るものを分けておくと、過信を防げます。

公開リポジトリの実践から、方針を選ぶ

2026年10月21日公開のmayabotさんの公開リポジトリ保護の記事では、ルールセット、秘密の検出、Actionの固定、更新などを役割ごとに整理しています。これは運用の実践報告として参照します。

本教材では、原記事のmainへ直接pushする方針をそのまま採用せず、PRを通じて差分と検査を確かめる流れで説明しています。守りの設定は、作業する人や権限、使える機能に合わせて選び、実際の適用結果を確かめます。

SECURITY.mdなどで非公開の報告経路を案内する場合も、その窓口が実際に使えるかを確認します。存在しない窓口を文章だけで案内したり、秘密を含む詳細を公開Issueへ貼るよう促したりしません。

自分のリポジトリでは、3つの役割で確かめる

作る人：差分と検査対象をそろえる

AIが変えたファイル、依存、ワークフローや権限の差分を見ます。検査後に追加の変更があれば、その状態への検査があるかを確認します。AIの要約だけで、含まれる変更の範囲を確定しません。

検査する人：実行条件と結果を見る

どのイベントで、どのコードと設定を使い、どの検査を実行したかを確認します。省略や未実行、失敗を許容した条件がないかも見ます。秘密や強い権限が不要な検査へ渡っていないかを調べます。

管理・公開する人：適用ルールと反映先を確認する

ルールの対象、適用状態、必須チェック、回避できる相手を設定で確かめます。すべてを一人で兼ねる場合も、その区別は残します。マージと公開を分け、公開したリリースと実際のURL・動作を照合します。

検査の結果から、公開した結果まで

同じ差分を確認
検査とレビュー後の追加変更も照合。
反映条件を確認
必要なルールと権限を満たしたか。
公開先で確認
意図したリリース、URL、主要な動作を見る。

マージだけで公開完了にせず、実際の反映先を確かめます。

設定ファイルを置いただけで、効いたことにはしない。

ルールや検査は、対象の変更で実際に働くかを見ます。条件が足りないときに止まることと、正しい手順で進めることの両方を、管理する検証環境で確かめます。

公開へ進める前に確かめる

差分： 公開するコードの状態と、検査・レビューの対象を照合した。
必須検査： 必要な検査が実行され、その結果・出所・未確認範囲を説明できる。
強制ルール： 対象ブランチ、適用状態、必須チェック、回避できる人やアプリを確認した。
権限と秘密： 検査と公開の仕事を分け、不要な権限や秘密を渡していないことを確認した。
外部部品： Actionの提供元と固定した内容、実行時の取得先、更新の確認方法を整理した。
公開結果： マージしただけでなく、意図したリリースと公開先の動作を確かめた。

次は、公開する中身と運用へ

公開前の確認でサービス全体を見ます。部品の更新は依存管理、秘密の露出が疑われる場合は異常時の対応へ進みます。

一次資料と参考記事

情報確認日：2026年10月24日。ルールやActionsの機能・プラン・状態の扱いは、利用する環境の公式資料で確認してください。

mayabotさん：AIと作る公開リポジトリの守り方 — 役割ごとの保護策を整理した実践報告。本文の検査記録は独自の架空例です。
GitHub公式：ルールセットで利用できるルール — PR・検査・回避権限などの仕様。
GitHub公式：Actionsの安全な利用 — 最小権限、信頼できないコード、外部Actionと秘密。
GitHub公式：ワークフロー構文 — 実行条件と権限。
changed-files当事者のアドバイザリ、GitHub Advisory Database — 2025年3月の問題と対応範囲。

書いた人

月ねこ｜Tsukineko

マーケティングの現場から、AIをつくり、仕事で使う側へ。実際に試したことや、つまずいたことを、図解と具体例で伝えています。

プロフィール・発信先 →著作権・利用条件 →

この記事のURL：https://nekoai-lab.github.io/ai-security-playbook/learn/github-guards/

続けて読む

シリーズ · 全14記事のうち9記事目

次に読むAIレビューが合格した。その結果を、どこまで信じていい？AIに書かせたコードを別のAIにレビューさせ、合格でマージを決めている人へ。1回の合格が保証しないこと、ぶれの確かめ方、確認項目と使い回しのルールを、再現実験の数字で考える。

読む順番・ルートを見る

AIで作って公開する基本

アプリの仕組みの教材へ戻る →

この教材のソース・修正提案 ↗