GitHubをAIに触らせる前に、鍵と権限を絞る3つの設定。サイボウズの新人研修資料から学ぶ

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。今回は、サイボウズの平木場風太さんの「GitHub を使う上で知っておくと嬉しいかも Tips 2026」という資料を紹介するね。

平木場風太さん（サイボウズ）「GitHub Tips 2026」の「はじめに」のコンセプト

誰に：GitHub を使ったことがあるけど組織の中ではまだ使ったことがない人

サイボウズの平木場風太さんが、社内の新人研修で使った資料を社外に公開しています。題は「GitHub を使う上で知っておくと嬉しいかも Tips 2026」。今年はセキュリティ向上の特集号です。

社内での発表は2026年5月8日、7月21日に更新、Docswellでの公開は8月12日。情報は2026年4月時点です。全118ページ。

対象は引用のとおり。生成AIに頼んでコードを作り、GitHubに置き始めた人にも、そのまま当てはまると私は読みました。

ただ、資料って専門用語の連続なんです。PATにOIDCにRulesets。

私がいちばん許せないのは、難しいカタカナ用語で、中小企業の経営者が「自分が分からないだけかも」と自己嫌悪に陥ることです。この資料は新人向けに丁寧に作られています。それでも、言葉の壁は立つ。

だから、この記事では言葉を1行ずつ言い換えながら進めます。GitHubは、コードやファイルを置いて、変更の歴史ごと共有する場所。リポジトリは、その中の1つの箱です。

この資料の価値は、怖い話を並べることではなく、守る順番をくれることです。権限を小さく、止める場所を先に、気づく手を重ねる。この順番が分かると、AIに作業を任せる前に、何を決めればいいかが見えてきます。

先に、手間と限界も書いておきます。鍵を絞るほど、足りない権限で処理が止まることが増えます。非公開リポジトリでは、使える機能に契約が要るものもある。修正案まで出してくれる機能もありますが、当てるかどうかと、当てた後の確認は人の仕事です。それでも、最初から広く渡して後で困るより、止まって足すほうが、私は安心です。

言葉で止まったら、AIに言い換えてもらえばいい。私はこう頼みます。

平木場風太さん（サイボウズ）「GitHub Tips 2026」の「攻撃を許すと何が起こるか？」のページ

ひとたび侵害が起きれば、技術の問題に留まらず、事業継続性まで揺らぐ。

資料が最初に見せるのは、攻撃の多さです。サプライチェーン攻撃は、2024年10月〜2025年5月の月平均で16件以上。自分が使っている部品や道具の側に悪いコードを混ぜて、使う人までまとめて狙う攻撃のことです。

例の1つ、tj-actions/changed-files（2025年）の件では、2万3千を超えるリポジトリから秘密が漏れたとされています。

攻撃を許すと、自動処理の中の秘密が根こそぎ抜かれる。盗まれた鍵が仮想通貨の採掘に使われ、高額な請求が来る。自分が公開した物が、使う人に被害を広げる。そして、会社の信頼が揺らぐ。

でも私は、怖がらせて設定させる話にはしたくありません。

このページの見出しは「被害は自分の環境・自分の責任として返ってくる」。私はこれを、守れる場所が自分の手の中にある、と読みました。なら、順番に手を打てばいい。

まずは、自分のGitHubで、他の人が作った部品をいくつ使っているかを、AIに数えてもらってください。数が分かると、守る範囲が見えてきます。

平木場風太さん（サイボウズ）「GitHub Tips 2026」の「事前知識: 多層防御」のページ

「社内だから安全」「信頼できる人しかいない」は技術的な防御にならない

資料は、設定に入る前に考え方を押さえてくれます。

1つ目は最小権限。必要な操作に、必要な範囲だけの権限を渡す。鍵が漏れた時に、その鍵で直接できることを小さくしておけます。被害の連鎖がゼロになるわけではありませんが、入口は狭くなります。

2つ目は多層防御。100%防げる対策はない前提で、違う角度の対策を重ねる。

3つ目は予防・検知・対応。前に塞ぐ、すり抜けたら早く見つける、起きた後の被害を小さくする。

私は人を信じて任せたいほうです。競争より共創。

でも、自分の委ね方の今の場所も分かっています。AI秘書の凛ちゃんたちに委ねたい気持ちはある。でも委ねた先が、嘘をつく、逃げる、やらない、なら委ねられない。だから、信頼できる仕組みが先。

AIに仕事を頼む時も、私は同じ順番で動いています。

AI氣道『OpenAI Dotsの最初の指示文、そのまま使って大丈夫？公式ヘルプで読み比べた』より

「信頼できる仕組みが先なので、仕組みを確かめてから、頼みごとを書く。私の順番です。」

鍵を絞るのは、人を疑うためではありません。安心して任せるためです。信頼したいからこそ、信頼が崩れた時の被害を、先に小さくしておく。

AIや外注先に鍵を渡す時は、相手を信じるかどうかと、鍵の範囲を分けて決めてください。

平木場風太さん（サイボウズ）「GitHub Tips 2026」の「GITHUB_TOKEN – 覚えていってほしいこと」のページ

とにかくジョブに permissions を設定する癖をつける。

鍵の話から入ります。資料は、鍵の種類を用途で選ぶ順番を示しています。GitHubの中の自動処理なら、その場で発行される短命の鍵（GITHUB_TOKEN）。それで足りなければ、人ではなく組織に紐づくGitHub App。それも難しい時に、PAT（Personal Access Token、個人に紐づく合鍵）です。

PATには2種類あります。古いClassicは権限の単位が粗く、repoという範囲で作ると、その人が触れる全ての非公開リポジトリが読み書きできてしまう。新しいFine-grainedなら、リポジトリ1つ・中身を読むだけ、のように絞れて、期限も付けられます。ただし、Packagesやghcr.ioのように、Fine-grainedではまだ扱えない用途もあります。

もう1つが、GitHub Actionsの鍵です。Actionsは、GitHubの中で決まった処理を自動で動かす仕組み。動くたびに、GITHUB_TOKENが自動で発行されます。

気をつけたいのは初期値です。初期値が全部書き込みOK（write-all）のままで権限の指定も書いていないと、ほぼ全ての権限（例外あり）が書き込み可能になる。だから資料は、ジョブごとに書く癖を勧めます。

私は2026年9月に、ログインの決まりとして、秘密をチャット・ログ・成果物・Gitへ残さないと決めました。たとえば音声を作る道具の鍵は、パソコンの鍵の保管庫（macOSのキーチェーン）に置いてあって、AI秘書の凛ちゃんは、鍵の中身をチャットや記録や成果物に出さない決まりです。

鍵の範囲と期限を絞り、鍵の中身はAIに見せない。この2つを重ねると、漏れる場所も、漏れた時の被害も小さくなります。

今日、GitHubの設定画面で、自分が作ったPATの一覧を開いてみてください。Classicが残っていたら、まず何に使っているかを書き出す。Fine-grainedで足りる用途なら、要る権限と期限を付けて作り直す。書き込みが要る仕事に読むだけの鍵を渡すと、その仕事は止まるので、置き換えは用途を確かめてからです。

鍵は、小さく、短く。私はこれを最初の一手にします。

平木場風太さん（サイボウズ）「GitHub Tips 2026」の「API キーをプッシュ前にブロックする」のページ

Push protection: git push の時点でシークレットを検出し、プッシュ自体を拒否する水際対策機能

2つ目は、止める場所です。pushとは、手元の変更をGitHubへ送ること。Push protectionは、その送る瞬間に、APIキーなどの秘密を見つけたら、送ること自体を拒否します。ただ、資料の言うとおり100%防げる対策はないので、これ1つに頼り切らないことです。

公開リポジトリへのpushには、使う人ごとの保護が初めから効いています。リポジトリごとの保護は初めは切れていて、管理者が設定画面で有効にします。非公開リポジトリでそれを使うには、GitHub Secret Protectionの契約が要ります。

私も、AI秘書の凛ちゃんに止まる場所を決めています。公開・送信・削除・課金、それにGitHubへのpushのような取り消しにくい操作は、実行の直前で止まって、私に確認する。それ以外は進めて、報告に1行残してもらう。

止まる場面を絞るのは、確認が増えるほど任せた仕事が私に戻ってくるから。逆に、止まる場面さえ決まっていれば、私は安心して任せられます。

AI氣道『Grok BotとClaudeが1Passwordを使えるように。パスワードを見せずにAIへログインを任せる仕組みと限界』より

「委ねるのは作業で、承認は手元に残す。」

機械の歯止めは、AIが約束を間違えた時にも働く。AIとの約束は、機械が見ていない場面を受け持つ。ただ、AIは約束を間違えることもあるので、機械の代わりにはなりません。だから私は、2つを重ねます。

公開リポジトリを持っているなら、リポジトリの設定画面で、Push protectionが有効かを確かめ、切れていれば有効にしてください。

止める場所は、事故の前に置く。私はそうしています。

平木場風太さん（サイボウズ）「GitHub Tips 2026」の「事前知識: 多層防御」の1行目

どんなに優れた対策でも 100% は防げない前提で設計する

気づく仕組みが要る場面は、私の手元でも起きました。AI秘書の凛ちゃんは、私の記録をGitHubへ控えとして送る仕組みを動かしています。

9月16日から、この控え送りが止まっていました。GitHubに入る認証がつながっていなかったんです。しかも、失敗した回の1つが「完了」と記録されていました。直ったのは9月19日です。AI秘書の凛ちゃんがGitHubの認証をつなぎ直し、入力待ちで黙って止まらない設定を足して、実際に送れたことを確かめました。

攻撃でも、ただの止まりでも、気づく手がないと、何日も誰も知らないまま過ぎていく。

まず決めておきたいのは、知らせを誰がどこで受けるかです。止まった時は「完了」の記録ではなく、送れた結果そのものを見る。その上で、資料の検知の手を重ねます。Dependabot（使っている部品の弱点を知らせる）、Code scanning（コードの危ない書き方を見つける）、Secret scanning（すでに入ってしまった秘密を見つける）。起きた後は、監査ログで何が起きたかを追う。大きな契約（Enterprise）では、条件付きで鍵の認可をまとめて取り消す手もあります。

Dependabotの知らせが、どこに届く設定になっているかを確かめてください。届いていても読まない場所なら、届いていないのと同じです。

防げない前提で、気づく手を持つ。私はそうしています。

平木場風太さん（サイボウズ）「GitHub Tips 2026」の「事前知識: 最小権限の原則」のページ

権限を絞ることで、漏洩時の影響範囲を小さくできる。有効期限を短くすることで、悪用可能な時間を短くできる。

ここからは私の提案です。最小権限・多層防御・予防と検知と対応を、AIにGitHubを触らせる前に済ませたい設定に落とすと、こうなります。それぞれ、どこで設定し、何ができれば済みかを添えます。

1. AI専用の鍵: GitHub Appで済むならそれを使い、PATならFine-grainedで作る（個人の設定画面のDeveloper settings）。済んだ印は、AIが使う鍵が人の鍵と別で、リポジトリ・権限・期限が決まっていること
2. ジョブごとの権限: リポジトリや組織の設定のActionsの項目で、初期値を読み取りだけ（read-only）にし、読むだけのジョブも含めて、ジョブごとに要るpermissionsを書く。済んだ印は、初期値がreadで、writeの理由を言えること
3. 秘密の送信の歯止め: リポジトリの設定のセキュリティの項目で、Push protectionを有効にする。済んだ印は、有効の表示が出ていて、鍵をチャットやファイルに貼らず保管庫に置いていること

その上に、失敗や知らせが届く先を決めておく。これが気づく手です。

まずは、誰に何の鍵を渡しているかを知ること。これはAIに聞き出してもらえます。

自動処理の点検もAIに頼めます。ただし、読むだけで、変更はさせない。

AIに任せたのに、つい横で見張ってしまう。そんな時に、私が思い出す一文があります。

AI氣道『Claude Code 無人運用を始める経営者へ。最初の1件を任せて席を外すまでの渡し方と確かめ方』より

「見張りは性格の問題ではなく、決めていないことの穴埋めなんです。」

鍵の範囲と止める場所を先に決めておくと、横で見張る場面はぐっと減ります。決めていないから、見張るしかなくなるんです。

権限を小さく、止める場所を先に、気づく手を重ねる。この順番で、私はAIに鍵を渡します。

サイボウズの「GitHub Tips 2026」は、GitHubを組織で使い始める人のための、安全の教科書でした。

私は、人もAIも信じて任せたい。だから、信頼できる仕組みを先に置きます。鍵を絞るのは、疑うためではなく、安心して委ねるため。

AIに触らせる前に、今日やることは1つ。PATの一覧を開いて、AIや外部のサービスに渡している鍵の範囲と期限を確かめてください。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！