GitHub CopilotでDNS設定ゼロ、Pagesカスタムドメインを14分で公開
GitHub Copilot CLIでDNS設定ゼロ。GitHub Pagesカスタムドメインを14分で公開
カスタムドメインの取得とDNS設定は、多くの開発者にとって「最後の関門」だ。Aレコード、CNAMEエントリ、TTL（Time To Live / DNSキャッシュの有効期間）、そして「設定が反映されたのかどうかもわからない」という長い待ち時間。これらの煩わしさが、せっかくのプロジェクト公開を先延ばしにする原因になっている。
GitHub Blogで2026年7月8日に公開された記事によれば、GitHub Copilot CLIとコミュニティ製のNamecheapスキルを組み合わせることで、DNSレコードを手動で1行も編集せずに、約14分でカスタムドメインの設定からHTTPS化されたサイト公開までを完了できることが実証された。空のリポジトリから公開まで、わずか14分だ。
本記事では、このワークフローをステップごとに分解し、技術的な仕組みと実務への応用方法を解説する。DNSの知識がなくても理解できるよう、専門用語には都度説明を加えながら進める。
Copilot CLIがDNSの常識を変える、手動設定から自動化への転換
従来のDNS設定が抱える3つの課題
カスタムドメインをGitHub Pagesに紐付けるには、従来以下の作業が必要だった。ドメインを購入し、レジストラ（ドメイン管理会社）の管理画面でAレコードとCNAMEレコードを手動で追加し、GitHubリポジトリ側にもCNAMEファイルをコミットする。さらにDNSの伝播（設定がインターネット全体に行き渡るプロセス）を待ち、最大で48時間かかることもある。
この一連の作業には大きく3つの課題がある。第一に手順の複雑さだ。AレコードやCNAMEといったDNSレコードの種類を理解し、正しい値を入力する必要がある。第二にフィードバックの遅さ。設定が正しいかどうかの確認に長時間を要する。第三にミスのリスク。1文字でも間違えるとサイトが表示されず、原因特定にも手間取る。
Copilot CLIが解決するDNS設定の自動化
GitHub Copilot CLIは、自然言語での指示をシェルコマンドやAPI操作に変換するAIアシスタントだ。これにレジストラのAPIと連携するスキルを組み合わせることで、DNSレコードの読み取り・設定・検証までを自動化できる。
今回のワークフローでは、Namecheap（ドメインレジストラ）のAPIを操作するコミュニティ製スキル「namecheap-skill」を使用する。Copilot CLIに対して「このドメインをGitHub Pagesに向けて」と指示するだけで、スキルが必要なAレコードとCNAMEレコードを自動生成し、レジストラのAPI経由で設定する。さらにGitHubリポジトリ側のCNAMEファイルも自動でコミットする。
手動で6ステップかかっていたDNS設定が、自然言語の指示1行で完結する。ミスのリスクが排除され、待ち時間も大幅に短縮される点が最大の利点だ。
準備編、GitHub Pagesへの公開と格安ドメインの取得
ステップ1、GitHub Pagesでランディングページを公開する
まずは公開用のリポジトリを作成する。空のパブリックリポジトリを用意したら、index.htmlを手書きする必要はない。Copilot CLIに「このリポジトリでGitHub Pagesを有効にして、カスタムドメインに関するランディングページを作成して」と指示するだけで、HTMLの生成からPagesの有効化までを自動実行してくれる。
この時点でサイトは ユーザー名.github.io というURLで公開される。まずはデフォルトドメインでサイトが表示されることを確認し、次に独自ドメインの設定に進む。
ステップ2、低コストでドメインを取得する
サイドプロジェクトにプレミアムな .com ドメインは必須ではない。今回の検証では、最も安価なTLD（トップレベルドメイン / .comや.orgなどのドメイン末尾部分）のひとつである .click が選択された。購入費用はわずか2米ドル（約300円）だ。サイドプロジェクトでカスタムドメインを試すにはリスクの低い金額といえる。
Namecheapでドメインを検索し、利用可能な名前を選んで購入する。決済が完了すれば、次のステップでAPI経由のDNS設定に進む準備が整う。
Namecheap APIとCopilot CLIの連携でDNSレコードを自動設定
Namecheap APIアクセスを有効化する
Copilot CLIがDNSを操作するには、事前にNamecheapのAPIを有効化する必要がある。Namecheapの管理画面で「Profile → Tools → Business & Dev Tools」と進み、Namecheap API Accessの管理画面を開く。ここで3つの設定を行う。
- APIをONに切り替える
- APIを呼び出すマシンのパブリックIPを許可リスト（ホワイトリスト）に追加する
- APIキーをコピーして安全な場所に保管する
APIキーは後続のステップでCopilot CLIに入力するため、手元に控えておく必要がある。NamecheapのAPIを使うと、ドメイン一覧の取得やDNSレコードの読み書きをプログラムから実行できるようになる。
Namecheapスキルをインストールする
続いて、Copilot CLIにNamecheapと通信する能力を与えるスキルをインストールする。以下の1コマンドで完了する。
gh skill install github/awesome-copilot namecheap --scope userスキルのインストール後、Copilot CLIに対して「自分のNamecheapドメインを一覧表示して」と指示すると、初回実行時にAPIキーの入力を求められる。先ほど控えたキーを入力すれば、アカウント内のドメイン一覧が表示され、連携が正常に機能していることを確認できる。
この4ステップで、Copilot CLIがドメインレジストラのAPIを直接操作できる状態になる。従来のように管理画面を手動で操作する必要はない。
ドメインの紐付けと自動検証、すべてが14分で完了
Copilot CLIにドメイン接続を指示する
準備が整ったら、Copilot CLIに対して「このGitHub Pagesサイトでカスタムドメインを有効にして」と指示する。スキルは現在のDNSレコードを確認し、変更を適用する前に確認を求めてくる。これは重要な安全設計だ。誤ったDNS変更がサイトの表示停止につながるリスクを、人間の承認によって防いでいる。
承認後、スキルは以下の作業を自動実行する。
- Namecheapのパーキングレコード（未使用ドメインの仮レコード）を削除
- GitHub PagesのAレコード（IPアドレス指定）を登録
- WWWサブドメイン用のCNAMEレコードを追加
- リポジトリにCNAMEファイルを自動コミット
これらの手順はGitHubが公式に定めるカスタムドメイン設定手順に完全に準拠している。手動で行う場合とまったく同じ結果が、人的ミスのリスクなく得られる。
自動検証でDNS設定の完了を確認する
設定が完了したら、Copilot CLIは自らの作業を検証する。まずドメインが正しく解決されるか（DNSルックアップ）を確認し、次にサイトがHTTP 200（正常応答）を返すかをチェックする。手動での動作確認すら自動化されているのだ。
実際のタイムラインを見てみよう。ドメイン購入は東部時間の午前11時21分27秒に行われた。約14分後の午前11時35分には、カスタムドメインでHTTPS化されたサイトが公開されていた。この14分にはAPIセットアップ、スキルインストール、DNS設定、伝播、検証のすべてが含まれている。
Copilot CLIがDNSルックアップとHTTPステータス確認を自動実行し、人間が待機する必要はない。設定ミスがあればすぐに検出され、修正も対話的に行える。
DNS自動化が変える開発体験、Namecheap以外でも使える汎用ワークフロー
このワークフローの本質は、Namecheapに限ったものではない。APIを提供しているレジストラであれば、同じアプローチが適用できる。専用のスキルがなくても、Copilot CLIにレジストラのAPIドキュメントを読み込ませ、「このAPIを使ってGitHub PagesのDNSレコードを設定して」と指示すればよい。レジストラが変わってもワークフローは変わらない。
DNS設定は「難しくはないが、面倒で失敗しやすく、フィードバックが遅い」という特性を持つ作業だった。Copilot CLIはこの3つの課題を同時に解決する。面倒な手順は自動化され、失敗のリスクは承認プロセスで抑制され、フィードバックは自動検証で即時に得られる。
カスタムドメインの設定を「面倒だから」と後回しにしてきた開発者にとって、このワークフローは心理的な障壁を取り除く。14分という時間は、コーヒーを淹れるのと変わらない。DNS設定がコマンド1行で済む時代が、すでに来ている。
この記事のポイント
- GitHub Copilot CLIとNamecheapスキルでDNSレコードの手動編集が不要になる
- 空のリポジトリからHTTPS化されたカスタムドメインサイトまで約14分で完了
- API経由の自動設定によりAレコードやCNAMEの入力ミスがゼロになる
- 設定後はCopilot CLIがDNS解決とHTTPステータスを自動検証する
- Namecheap以外のレジストラでも、APIがあれば同じワークフローが適用可能
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GitHubが依存関係のライセンス遵守を自動化する新機能を発表
GitHubは2026年6月30日、オープンソースの依存関係におけるライセンス遵守を自動化する「License Compliance」機能を公開プレビューとして発表した。GitHub Advanced Security（GHAS）のCode Securityライセンスを持つEnterprise Cloudユーザーが対象だ。
この機能はPull Request上で新たに追加される依存関係のライセンスを自動スキャンし、組織のポリシーに反するものがあればアラートを出す。GitHub自身のOpen Source Program Office（OSPO）も数カ月前からこの機能に移行し、社内ツールを置き換えた実績がある。
ソフトウェア開発において依存関係のライセンス管理は、後回しにされがちな領域だ。しかし、ライセンス違反は訴訟リスクやコードの公開義務といった深刻な結果を招く。この記事では、GitHubの新機能の仕組みと、実際に運用する組織がどのようにポリシーを設計すべきかを解説する。
オープンソースライセンスの遵守が企業にとって重大な理由
ほぼすべてのソフトウェアには何らかのライセンスが付与されている。ライセンスはそのプロジェクトを利用する許可を与えるが、同時に遵守すべき義務も課す。義務の内容は、ドキュメントに原著作者のクレジットを記載するだけの緩やかなものから、プログラムを配布する際に自社の全ソースコードを公開しなければならない強力なものまで幅広い。
商用ソフトウェアにおけるリスク
商用のクローズドソース製品を販売する組織であれば、GPL系のライセンスを持つ依存関係をうっかり混入させると、自社のプロプライエタリなコード全体をオープンソース化せざるを得なくなる可能性がある。これはビジネスモデルを根底から覆す致命的な事態だ。
逆に、自社プロジェクトをオープンソースとして公開する予定があるなら、商用ライセンスや互換性のないオープンソースライセンスの依存関係を避ける必要がある。いずれにせよ、ライセンス義務を満たせない依存関係は排除しなければならない。後から該当ライセンスのコードを除去するには大きな工学的コストがかかるし、企業ソフトウェアにとって違反のビジネスリスクは甚大だ。高額な訴訟やレピュテーションの損傷に直結する。
従来のレビュー手法とその限界
これまでライセンスレビューは手作業か、サードパーティ製ツールで行われてきた。しかし、依存関係が増えるたびに人手でライセンスを確認するのは現実的ではない。ツールを使うにしても、開発フローとは別の場所でチェックが走るため、問題が見つかった時点では既にコードがマージされた後、というケースも少なくなかった。
GitHubのLicense Compliance機能はこの課題に直接アプローチする。Pull Requestの段階で新しい依存関係をスキャンし、ポリシーに合致しないライセンスがあれば、マージ前に開発者へフィードバックを返す。開発フローに組み込まれた「シフトレフト」なアプローチだ。
GitHubのLicense Compliance機能の仕組み
この機能は、リポジトリに適用するルールセット（ruleset）を通じて有効化される。カスタムプロパティを使って対象リポジトリを指定し、「Active」モードか「Evaluate」モードかを選択する仕組みだ。
ルールセットの対象となったリポジトリでは、依存関係を変更するPull Requestが作成されると自動スキャンが走る。新しい依存関係それぞれのライセンスを照会し、既に許可済みのライセンスやパッケージ固有の例外に該当すればチェックをパスする。問題がある場合は、直接の依存関係だけでなく推移的依存関係（依存関係がさらに依存しているパッケージ）についても、Pull Requestのコメントとしてアラートが投稿される。
開発者から見たフロー
開発者はアラートを受け取ったら、その依存関係が受け入れ可能かどうかを判断する。受け入れられないと判断すれば、コードを修正するかPull Requestをクローズして依存関係を除去する。一方、そのライセンスやパッケージを許可すべきだと考えた場合は、例外申請を上げることができる。申請は組織内のポリシーチームに通知され、ポリシーを修正するかどうかが判断される。
GitHub OSPOの運用実績
GitHub自身のOSPOは、この機能が社内公開される前からアーリーアダプターとして利用してきた。当初は組織全体のルールセットに「Evaluate」モードを適用し、Pull Requestにアノテーションを表示するだけでマージはブロックしない設定でスタートした。これにより、開発者が新しいワークフローに慣れる時間を確保しつつ、旧来の社内ツールと並行稼働させて挙動の差異を検証したという。
約1カ月の並行稼働を経て、アラートの大半が「通常とは異なるライセンス」「ライセンス情報の欠落」「明示的に禁止されたライセンス」に絞り込まれた段階で、Activeモードへ移行した。大規模で動きの速い企業でも、段階的なロールアウトによって摩擦を最小化できる好例といえる。
ポリシー設計の実践アプローチ
効果的なライセンスコンプライアンスを実現するには、適切なポリシー設計が不可欠だ。GitHub OSPOの経験から、以下の3段階で考えると整理しやすい。
重要なのは、ポリシーを「作って終わり」にしないことだ。新しいライセンスやパッケージ固有の例外は、ポリシーチームが継続的に審査し、必要に応じて追加していく。この運用プロセスが整っていないと、開発者は Pull Request がブロックされたまま放置される「ポリシー渋滞」に巻き込まれる。
ライセンス許可とパッケージ例外の使い分け
ポリシー修正には大きく2つの判断軸がある。「ライセンスそのものを許可する」か「特定のパッケージだけを例外として許可する」かだ。さらに、その許可を「Enterprise全体（組織全体）」に適用するか「特定のリポジトリのみ」に限定するかも決定する。
安全なライセンスで単に初出だっただけなら、Enterpriseレベルでライセンスを追加すれば済む。一方、商用ライセンスのパッケージで、特定のチームだけが購入済みのソフトウェアなら、そのリポジトリだけに例外を設定する。パッケージ例外にはワイルドカードマッチが使えるため、例えば @github-ui/* のような形で名前空間単位の許可も可能だ。
緊急時のオーバーライドと開発者教育
ライセンスポリシーによってPull Requestがブロックされる仕組みは強力だが、クリティカルな修正を緊急でマージしなければならない場面も想定しておく必要がある。GitHub OSPOは「ブレークグラス（緊急時オーバーライド）」の手順を整備している。
仕組みはシンプルだ。ルールセットの条件はカスタムプロパティの値を参照しているため、そのプロパティ値を切り替えるだけで一時的にポリシー適用を無効化できる。GitHub OSPOのこれまでの運用では、このオーバーライドを使ったのは1度だけだったという。頻繁に使うものではないが、いざという時に選択肢があることが重要だ。
開発者へのトレーニングとドキュメント
ツールを導入するだけでは不十分だ。開発者が「なぜライセンス遵守が自分ごとなのか」を理解していなければ、例外申請のプロセスは形骸化する。GitHub OSPOは社内向けのドキュメントとトレーニングを提供し、ライセンスコンプライアンスが全員の責務であるという認識を浸透させている。
開発者が情報に基づいた依存関係の選択をできるようになれば、後からの修正作業や法的トラブルを未然に防げる。ライセンス遵守は「コンプライアンス部門だけの仕事」ではなく、サプライチェーン全体で取り組むべき課題だ。
依存関係管理のこれから
ソフトウェアサプライチェーンのセキュリティとコンプライアンスは、近年急速に注目を集めている領域だ。SBOM（Software Bill of Materials）の普及や、米国大統領令によるソフトウェアサプライチェーンセキュリティの強化など、規制面からの要請も強まっている。
GitHubのLicense Compliance機能は、こうした流れの中で「Pull Request時点でライセンスをチェックする」というプラクティスを標準化しようとする試みだ。開発フローに自然に溶け込む形で提供されるため、導入障壁は従来のサードパーティツールよりも低い。
現時点ではパブリックプレビューであり、対象はGitHub Enterprise CloudでGHAS Code Securityライセンスを保有するユーザーに限られる。しかし、GitHub自身が大規模な組織で実績を積んでいる点は、導入を検討する企業にとって心強い材料だろう。
この記事のポイント
- GitHubが依存関係のライセンス遵守をPull Request上で自動チェックする新機能を公開プレビューとして発表した
- ルールセットを通じてリポジトリ単位で適用し、Evaluateモードから段階的に導入できる
- GitHub自身のOSPOがアーリーアダプターとして社内で運用実績を積んでいる
- ライセンス違反は訴訟リスクやソースコード公開義務といった深刻な結果を招くため、開発フローへの組み込みが重要
- ポリシー設計は「基本ライセンスの登録 → Evaluateモード → Activeモード」の3段階で進めるのが現実的
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GitHubがシークレットスキャニングで受信箱ゼロを達成した方法
20,000件のアラートと向き合う、実践の全容
GitHubが社内の15,000以上のリポジトリを対象にシークレットスキャニングを実施したところ、20,000件を超える認証情報の露出を検出した。数字だけ見ると途方もないが、9カ月後には未対応のアラートをゼロに持ち込んでいる。セキュリティ運用の現場で「受信箱ゼロ（inbox zero）」を達成した事例として注目すべきプロジェクトだ。
GitHub Blogの記事によれば、同社はシークレット管理の取り組みを数年前から開始し、自社開発中のシークレットスキャニング機能をパイロット適用したところ、想定を大きく上回る数のシークレットが浮上したという。単に検出するだけでなく、どれが本物のリスクで、誰が対応すべきかを見極め、安全に修正するフェーズへと進めた点が鍵を握る。
本記事ではGitHubの内部事例をもとに、シークレット管理の現実的な進め方をひもとく。新規にシークレットスキャニングを導入した組織が直面する「どうやって既存のシークレットを片付ければいいのか」という問いに対する、具体的な戦略と教訓をまとめた。
ノイズの切り分け、18,000件が一瞬で消えた理由
20,000件を超えるアラートが出たからといって、同じ数の重大なインシデントが存在するわけではない。GitHubが最初に取り組んだのは、本当に対処すべきアラートとノイズの仕分けだった。
わずか5リポジトリで9割を占めたテスト用シークレット
データを掘り下げると、アラート全体の約18,000件がたった5つのリポジトリに集中していた。しかも、そのすべてがテスト用のフィクスチャや無効化済みの認証情報、実在しないが有効に見えるダミーシークレットだった。シークレットスキャニングを自社開発するGitHubにとって、テスト用の本物らしいシークレットが大量に必要なのは自然なことだ。
ここで同社が取った判断は明確だ。専用テストリポジトリに含まれ、一度も実運用で使われた形跡がなく、既知のテストパターンに一致するシークレットは、まとめて「解決済み」として一括クローズした。わずか数日で約18,000件のノイズが消え、残ったのは2,000件あまりの本物のアラートだけになった。
テスト用シークレットと本物のクレデンシャルを区別する基準を事前に定めておけば、大規模な一括処理が可能になる。数字の見た目に惑わされず、まずは分類から始めるのが現実的な最初の一手だ。
コードだけではない、シークレットの潜む場所
シークレットはソースコードにだけ存在すると思いがちだが、GitHubの経験はそれを覆した。サポートチケット、バグ報奨金レポート、インシデント対応のメモ、wikiページにもシークレットは散らばっていた。
サポートチケットには顧客がうっかりトークンを含めてしまうケースがあり、バグ報奨金の報告には研究者が完全な再現手順の一環としてAPIリクエストごとトークンを提出する。インシデントの調査記録にも、緊急時にコピーされた認証情報が残ることがある。いずれもコードリポジトリの外にあるため、従来のスキャン対象から漏れやすい領域だ。
GitHubはカスタマーサポート、セキュリティインシデント対応チーム、バグ報奨金プログラムと連携し、それぞれのワークフローに共通のプレイブックを整備した。修正作業の過程で新規の課題やコミットにシークレットを載せてしまう二次被害を防ぐ工夫も、あわせて徹底されている。
スキャン対象をコードリポジトリだけに絞っていると、これら周辺領域のシークレットはいつまでも検出されない。組織全体のワークフローを見直し、サポートやバグ報奨金の運用にもシークレット対策を組み込む必要がある。
段階的な取り組みで9カ月後にゼロへ
GitHubは2万件超のアラートを少数のセキュリティエンジニアだけで片付けようとはしなかった。新規の負債を止めたうえで、既存の負債を反復可能かつ計測可能なワークフローで減らしていく、運用バックログの処理と変わらないアプローチを取っている。主なフェーズは次の6段階だ。
フェーズ1、全社への有効化と強制で新規流入を遮断
既存のシークレットを片付ける前に、新たなシークレットの蓄積を止める必要がある。GitHubは全エンタープライズと組織に対してシークレットスキャニングとプッシュプロテクションを一括で有効化した。GitHub Advanced Securityの組織レベル設定があったため、15,000以上のリポジトリを一つひとつ手動で設定する必要はなかったという。
設定は強制適用され、個々のリポジトリやチームがこっそりオプトアウトすることは許されていない。プッシュプロテクションによって新規シークレットがソース上に流入するのを根本でブロックし、バックログが増え続ける状況を断ち切った。
フェーズ2、分類とトリアージで取捨選択
2万件超のアラートをリポジトリ別、シークレットタイプ別、経過期間別に分解し、前述のとおり約18,000件を一括クローズした。残った2,000件あまりについて、GitHubは難しい判断に直面する。
課題の中にシークレットが含まれている場合、本文を編集してリビジョン履歴を消すべきか、それとも監査証跡を残すべきか。リポジトリにコミットされたシークレットは、git履歴を書き換えるべきかどうか。大規模な履歴書き換えは強制プッシュによってプルリクエストを破壊し、コミットのSHAを無効化し、開発者の作業を中断させる副作用がある。
「もう使っていないリポジトリなら削除してしまえばいいのでは」という声も出たが、GitHubの回答は原則としてノーだった。削除されたリポジトリは監査証跡もろとも消える。もしそのリポジトリのシークレットが過去に漏洩していた場合、インシデント対応に必要な証拠を失ってしまう。シークレットをローテーションしたうえで、必要に応じてアーカイブし、履歴は残すという方針を取った。
可能なかぎり露出したシークレットを先にローテーションまたは無効化し、そのうえで履歴書き換えの要否を判断する。無効化済みのシークレットが履歴に残っていても安全かどうかはケースバイケースだ。この種の判断が、プロダクトセキュリティチームが日々直面する難題の一つであると記事は述べている。
フェーズ3、実効性の検証で本物を見極める
リポジトリに置かれた認証情報は、何年も前にローテーション済みかもしれないし、いまも本番システムにアクセスできるかもしれない。違いがわからなければ優先順位はつけられない。
当時のシークレットスキャニングにはネイティブの有効性チェック機能がなかったため、GitHubは独自の検証アプローチを構築した。目的は絞り込まれている。クレデンシャルがまだ機能するかどうかを確認し、適切な場合はアラートの転送先や通知すべき所有者を特定するための最小限のメタデータを収集するにとどめた。
たとえばGitHubトークンなら、GET /userのような影響の小さいエンドポイントに1回だけ認証リクエストを送る。不明瞭なレスポンスは結論不能と扱い、リポジトリや組織などのプライバシーに関わるリソースへの追加リクエストは避けた。この検証作業はプライバシーおよび法務チームとの密接な連携のもとで進められた。
手動での検証を進める一方、プロダクトチームが有効性チェックをシークレットスキャニングにネイティブ実装し、以降の作業は大幅に加速した。現在では有効性チェックがGitHubシークレットスキャニングの標準機能として組み込まれている。
フェーズ4、所有者の特定と責任体制の確立
認証情報が生きているとわかっても、誰がそれをローテーションできるのかを特定できなければ意味がない。GitHubが発行するパーソナルアクセストークンについては、プロダクトチームと協力してトークンの作成者や作成日時、スコープといったメタデータをアラート上に直接表示できるようにした。トークンそのものを使わずに所有者を割り出せる仕組みだ。
問題はそれ以外のシークレットと、明確な所有者が存在しないリポジトリだった。GitHubにはEngineering Fundamentalsという社内のエンジニアリング基準プログラムがあり、サービスに対して永続的な所有権を義務づけている。しかし、すべてのリポジトリがサービスときれいに紐づくわけではない。この課題は、GitHub Custom Propertiesを使ったリポジトリ所有権の明確化と、認証情報管理ツール上の全シークレットに永続的な所有者を割り当てる取り組みへと発展した。所有者を特定できなければシークレットのローテーションは不可能だからだ。
フェーズ5、ロングテールへの手動トリアージ
検証とメタデータの充実を経ても、最終的には人間の判断を要するアラートが残る。それぞれについて、この認証情報が何へのアクセスを許可するのか、すでにローテーション済みか、接続先システムの所有者は誰か、修正パスは何か、という問いを一つずつ解いていく作業だ。
GitHubはクローズするアラートすべてに対し、正確な処分結果（無効化済み、テスト用、誤検知など）を記録し、修正課題へのリンクや承認されたセキュリティ例外の情報といった関連コンテキストをコメントとして残した。このフェーズは、自動化されたシグナルだけでは不十分な領域を埋めるために、複数チームの密接な連携を必要とした。
フェーズ6、仕組み化と説明責任で持続可能に
パターンが見えてきた段階で、GitHubは作業をスケーラブルな体制へと昇華させた。
- アラートを社内の脆弱性管理プラットフォームに集約し、一元的な追跡とレポートを実現
- シークレットタイプ別に修正プレイブックを文書化し、各チームが自律的に対応できるように整備
- リポジトリ所有権に基づいてアラートを適切なチームへ自動通知する仕組みを構築
最後の締めくくりは説明責任の確立だ。GitHubはシークレット修正をEngineering Fundamentalsプログラムに組み込み、セキュリティに関する基本要件として全チームを評価対象にした。明確な期待値を設定し、各チームが自分たちの状況を可視化できるダッシュボードを用意したことで、シークレット衛生は組織全体の共有責任へと変わった。着手から9カ月後、未対応アラートはゼロになった。
6つのフェーズは独立しているわけではなく、相互に補完し合う。フェーズ1で新規流入を止めなければバックログは減らず、フェーズ4の所有者特定ができなければフェーズ5の手動トリアージは停滞する。全体を一連のパイプラインとして設計した点が、9カ月での完遂を支えた。
GitHubが得た8つの教訓
今回のプロジェクトを通じてGitHubが得た教訓は、同様の課題に直面する組織にとって実践的な指針となる。以下に8つを整理した。
数字に怯えない
初期のアラート件数は2万件を超えていたが、実に9割は実害のないノイズだった。生の数字がそのまま実際の作業規模を表すことはほとんどない。まずは分類から始めるべきだ。
例外なく全社に強制適用する
部分的な展開は死角を生む。GitHubはエンタープライズレベルでシークレットスキャニングとプッシュプロテクションを有効化し、誰にもオプトアウトを許さなかった。
エスカレーションの前に検証する
検出されたシークレットのすべてが生きているわけではない。有効性チェックによって優先順位をつけ、本当に危険なものから手を付けるのが鉄則だ。
メタデータが作業時間を大幅に削減する
GitHub発行の認証情報については、トークンの作成者やスコープといったメタデータが調査時間を劇的に短縮した。サードパーティプロバイダにも同様のメタデータ提供を求め、自前で補完する層を用意するのが望ましい。
所有者不在のシークレットは修正できない
永続的な所有権の基盤に早期に投資すること。リポジトリにもクレデンシャルにも、必ず責任者を紐づける仕組みが必要だ。
検出後のワークフローを自動化する
検出はスタート地点にすぎない。本当の運用課題は、アラートの転送、所有者の追跡、そしてクローズまでのループを回し切ることにある。ワークフロー層への投資が成否を分ける。
セキュリティチームだけの課題にしない
数千件のアラートをセキュリティチームだけで修正するのは不可能だ。GitHubはシークレット衛生をエンジニアリングの基本要件に組み込み、全チームの評価指標に据えた。リーダー層がダッシュボードを注視する状況になれば、各チームは自然と修正の時間を確保する。
判断基準を文書化する
すべてのシークレットにきれいな修正パスがあるわけではない。ローテーションで十分なケース、履歴の書き換えが必要なケース、残余リスクを受け入れるケースを、どう判断するかをあらかじめ文書化しておくことが重要だ。
多くの手作業は製品機能に置き換わった
今回のプロジェクトでGitHubが手動で実施していた有効性チェックや所有者特定、一括トリアージの多くは、現在シークレットスキャニングのネイティブ機能として利用できる。同社の記事は、読者に対して「私たちが構築したものの大半を再発明する必要はない」と明言している。
新規にシークレットスキャニングを導入するなら、まず全社への有効化とプッシュプロテクションの強制適用から始め、バックログをリポジトリとシークレットタイプでトリアージし、ノイズと判断できるものは迷わず一括クローズする。その後、有効なシークレットを検証し、所有者にアラートをルーティングし、他のエンジニアリング作業と同様に修正状況を追跡する。この流れは、組織の規模を問わず適用できる現実的なアプローチだ。
この記事のポイント
- アラート件数に惑わされず、まずはテスト用や無効化済みのノイズを分類して一括除去する
- シークレットはコード以外にも存在する。サポートチケットやバグ報奨金レポートも対象に含める
- 新規流入を止める強制適用と、既存バックログの段階的処理を並行して進める
- 有効性検証とメタデータ活用で、本当に対処すべきアラートに集中する
- シークレット衛生を組織全体の評価指標に組み込み、セキュリティチームだけの負荷にしない
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GitHubメンテナ必見、今週中に有効化すべき6つのセキュリティ設定
GitHubで公開リポジトリや社内リポジトリを管理している開発者にとって、セキュリティ設定は後回しになりがちだ。コードを書くのに忙しく、設定画面をじっくり見ている余裕はない、という声も多い。だが無料で使える基本設定を有効にするだけで、攻撃のハードルは劇的に上げられる。
GitHub Security Labが2026年7月1日に公開した記事では、30分で完了する6つの設定が紹介されている。どれも無料で即効性がある。2025年には公開GitHub上で2,865万件のシークレット（APIキーやトークン）が新たに漏洩し、前年比34%増という過去最大の増加幅を記録した。AI支援のコミットではこれが約2倍のペースで起きている。
以下、実際に有効にする手順と効果を解説する。
脆弱性報告の受け皿を整える最初の2ステップ
誰かがプロジェクトの脆弱性を見つけたとき、その報告先が用意されていなければ、善意の報告者は公開Issueに投稿するか、個人の連絡先を探すしかない。前者は修正前に攻撃手法を公開することになり、後者は連絡そのものが届かないリスクがある。これを防ぐのがSECURITY.mdとプライベート脆弱性報告（PVR）の2つだ。
SECURITY.mdの役割と書き方
SECURITY.mdはリポジトリのルートに配置するファイルで、脆弱性の報告方法を明示する。記載内容はシンプルでよい。連絡用のメールアドレス、対象とする脆弱性の範囲、報告者が知っておくべき前提事項があれば書く。
GitHub Security Labの記事では、systemdプロジェクトのセキュリティポリシーが参考例として挙げられている。24時間対応の体制を前提とせず、再現手順の期待値を明確にしている点が実務的だ。この構造を借りて連絡先を差し替えれば、10分程度で作成できる。
プライベート脆弱性報告（PVR）の有効化
SECURITY.mdが「どこに報告するか」を示すのに対し、PVRは「報告を非公開で受け付ける場」を提供する。設定はリポジトリの「Settings → Security」にあるチェックボックスを1つオンにするだけだ。
PVRを有効にすると、研究者は公開されない形で脆弱性を報告できる。メンテナはそれを非公開のままトリアージし、修正完了後に情報を公開するタイミングを自分で決められる。この2つをセットで導入すれば、コミュニティに対して「セキュリティに真剣に取り組んでいる」というシグナルを最も早く送れる。
上の図は、SECURITY.mdの有無で脆弱性報告の流れがどう変わるかを整理したものだ。左側（Before）では報告が公開Issueに向かい、修正前に攻撃手法が晒される。右側（After）では非公開チャネルを通じて修正後に公開できる。
シークレット漏洩と依存関係のリスクを自動でブロックする
コードを書いているとき、APIキーやデータベースの接続文字列をうっかりコミットしてしまった経験はないだろうか。GitGuardianの2026年版レポートによれば、2025年に公開GitHubへ流出した新規シークレットは2,865万件で、前年比34%増。IBMの2025年レポートでは、データ侵害の平均コストは世界で444万ドル、米国では1,022万ドルに達している。
シークレットスキャニングとプッシュ保護
シークレットスキャニング（secret scanning）は、リポジトリにコミットされたAPIトークンや秘密鍵を検知する機能だ。さらにプッシュ保護（push protection）を有効にすると、ローカルでのコミット時にシークレットが含まれている場合、リモートリポジトリにプッシュされる前にブロックする。
この機能は公開リポジトリとプライベートリポジトリの両方で使える。シークレットがローカル環境を離れた時点で、リポジトリへのアクセス権を持つ全員がそれを閲覧できる状態になる。プッシュ前に止めることが何より重要だ。
Dependabotと依存関係レビュー
プロジェクトのコードは自分が書いた部分だけで完結しない。数十から数百の外部パッケージに依存している。Dependabotは、依存パッケージに既知の脆弱性（CVE）が見つかった際にアラートを出す。依存関係レビュー（dependency review）は、プルリクエスト内で追加・更新されるパッケージと、それらに関連する勧告の有無を表示する。
この2つを有効にすると、package.jsonの差分をひとつずつ手作業で確認する必要がなくなり、レビュー時間は2分程度に短縮される。
シークレットスキャニングのプッシュ保護が有効だと、誤ってAPIキーを含んだコミットを作成しても、リモートリポジトリへ到達する前にローカルでブロックされる。設定の有無でリスクが大きく変わる。
コードスキャニングで実装レベルの脆弱性を検出する
コードスキャニング（code scanning）は、リポジトリのコードに対して静的解析を実行し、SQLインジェクション、コマンドインジェクション、危険なデシリアライゼーションなど、実際のバグにつながるパターンを検出する。
GitHubが提供するCodeQLはその解析エンジンだ。2019年にオープンソース向けに無料化され、現在はリポジトリの「Security and Quality」タブからワンクリックでデフォルト設定を適用できる。デフォルト設定はプロジェクトの使用言語に応じて適切なクエリパックを自動選択し、全プルリクエストに対して実行される。
コードスキャニングを敬遠する理由として「設定が面倒そう」という印象があるが、デフォルト設定を使う限り、追加の設定作業は不要だ。GitHub Actionsのワークフローを通じて、プルリクエストごとに自動で解析結果が表示される。
ブランチ保護で全対策を実効的にする
ここまで紹介した5つの設定は、いずれも検知や通知を行うものだ。しかし、検知された問題がマージを止められなければ、タブに積まれたアラートを見ないまま本番に反映されてしまう。この「検知だけで終わらせない」役割を担うのがブランチ保護ルール（branch protection）である。
デフォルトブランチに対して「プルリクエスト必須」「最低1件の承認を要求」というルールを設定するだけで、以下のシナリオを防げる。認証情報が漏洩して悪意のあるプッシュが行われるケース、混乱したコントリビューターが意図せずメインブランチに直接プッシュするケース、深夜に疲れた自分が確認なしで本番へプッシュしてしまうケース。これらはいずれも現実に起きうる。
ブランチ保護は、Dependabotのアラートやコードスキャニングの指摘がマージをブロックする仕組みとしても機能する。検知結果が単なる通知で終わらず、実際の開発フローに組み込まれることで初めて、他の5設定が本来の効果を発揮する。
ブランチ保護を有効にすると、プルリクエストとレビューが必須になる。コードスキャニングやDependabotのアラートも、このゲートを通じて初めてマージを止める力を持つ。
この記事のポイント
- SECURITY.mdとPVRで脆弱性報告の非公開チャネルを確保する
- シークレットスキャニングのプッシュ保護でAPIキー流出をローカル段階で防ぐ
- Dependabotと依存関係レビューで外部パッケージの脆弱性を自動監視する
- コードスキャニングのデフォルト設定はワンクリックで即効性がある
- ブランチ保護ルールがなければ他の設定は「通知に留まり」実効力を持たない
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GitHub Copilotデスクトップアプリ登場、エージェント駆動開発の拠点に
GitHubが2026年6月2日、新たなGitHub Copilotアプリをテクニカルプレビューとして公開した。このアプリは、複数のAIエージェントを並行して管理・指示するための「エージェントネイティブ」なデスクトップ体験を提供する。
Copilot Pro、Pro+、Business、Enterpriseの既存ユーザーはすぐに利用を開始できる。My Workビュー、ワークツリーによるセッション分離、Agent Merge、Canvas、サンドボックス、高度なコードレビュー、SDK、刷新されたCLIなど、エージェント主導開発の基盤として設計された機能群を詳しく見ていく。
GitHub Copilotアプリ：エージェントネイティブ開発のコントロールセンター
多くの開発者が日常的に複数エージェントを動かすようになるにつれ、ウィンドウを切り替えながらセッションを追跡する従来のやり方では限界が出てきた。Copilotアプリはその断絶を解消する。
「My Work」ビューは、接続されたリポジトリ全体にわたって稼働中のセッション、Issue、プルリクエスト、バックグラウンド自動化を一覧表示する。各セッションは固有のgit worktree（ブランチの独立した作業コピー）で実行されるため、エージェントどうしが互いの作業を壊すことはない。worktreeの作成や後片付けはアプリが自動的に処理する。
さらにAgent Merge機能は、プルリクエストをレビューからチェック、マージまで運ぶ。CIの監視、必須レビュアーの確認、失敗したチェックの修正をCopilotが代行し、開発者は「CIをグリーンに戻す」「フィードバックに対応する」「条件を満たしたらマージする」といった自動化の範囲を選べる。
GitHub Blogに掲載されたAvanade Inc.のDavid Jobling氏（Master Technology Architect）のコメントによれば、「Forward Deployedのエンジニアは多数のエージェントを一元的に扱い、複数のイニシアチブを管理できる。プランやオートパイロットへのアクセスが容易になり、必要に応じてインタラクティブなセッションを実行したりコードに介入したりできる」と評価している。
この統合感をビフォーアフターで示すと、次のような差になる。
このデモのように、Copilotアプリはエージェントが「ただコードを提案する」存在から「プロジェクト全体を駆動する」存在へ変わるための統制盤になる。
Canvas：意図を見える化する双方向作業面
チャットは指示や曖昧さの解消に強い。しかしエージェントが本格的な作業を始めると、チャットスレッドは判断やログ、修正指示の長いスクロールになり、作業そのものの全体像を見失いがちだ。
そこで導入されたCanvasは、人間とエージェントが同じ面で作業する双方向の作業サーフェスだ。プラン、プルリクエスト、ブラウザセッション、ターミナル、デプロイ状況、ワークフローの状態など、エージェントが作業を進めるにつれてCanvasが更新され、開発者はその場で編集、順序変更、承認、方向転換ができる。
チャットが「思考の場」だとすれば、Canvasは「作業の場」だ。これが、GitHubが提唱するエージェント体験（AX）の出発点になる。
サンドボックス：本番に触れずにエージェントを動かす隔離環境
コードを提案するだけでなく、実際にコードを実行し、テストし、結果を調べて反復できることがエージェントの実用性を高める。そのために用意されたのが、ローカルとクラウドの2種類のサンドボックスだ。
・ポリシーを一元的に設定・適用
・オフライン作業に最適
・組織のポリシーを自由に定義
・任意のデバイスからリモート操作
ローカルではマシンのリソースを直接使いつつもポリシーで範囲を絞り、クラウドでは完全に独立したエフェメラル環境が手に入る。いずれも本番環境に手を触れることなく、エージェントがコードの実行と検証を繰り返せる。
コードレビュー機能：エージェント出力にスケールする審査
エージェントが生成するプルリクエストが増えるほど、コードレビューの負荷は増す。Copilotコードレビューは、適応的なエージェントシステムでノイズをふるい分け、開発者は本当に重要な判断に集中できる。
新たに追加された「中程度」レビューティアでは、より高精度な推論モデルを利用してレビューの適合率と再現率を向上させる。管理者はリポジトリごとに「低」か「中」を割り当てられ、リスクの低いコードには軽量なモデルを、影響度の高いリポジトリには強力なモデルを振り分けられる。
また、/security-reviewスキルはセキュリティに特化した評価経路を用意し、一般提供された/rubberduckスキルは複数のモデルファミリーを利用して実装を批判的に検証し、新たな問題点を見つける。
さらに、Azure DevOpsユーザーはCopilotコードレビューをネイティブに利用できるようになった。ワンクリックレビュー、インラインコメント、コミット可能な修正提案といった機能がそのまま使える。
・時間が足りない
・/security-reviewでセキュリティ専用評価
・/rubberduckで実装の批判的検討
・自社ポリシーに合わせてカスタマイズ
このように、レビューの質とスループットを両立させる仕組みがCopilotアプリの中核に組み込まれている。
Copilot SDKとCLI：開発者自身のツールを構築する土台
エージェント機能はアプリの中だけにとどまらない。Copilot SDKが一般提供され、Node.js/TypeScript、Python、Go、.NET、Rust、Javaといった主要言語から同じエージェントランタイムを利用できる。自社のコード分析ツール、カスタムリリースノート生成、サポートワークフローに組み込むエージェントなどを、共通の土台の上に構築できる。
CLIも大きく刷新された。再設計されたTUIではタブでプルリクエスト、Issue、Gistにアクセスでき、音声入力にも対応する（音声データは端末外に出ない）。/everyを使えば定期的なプロンプト実行やバックグラウンドタスクのスケジュールが組める。クラウド自動化では、エージェントがGitHubイベントに反応してIssueを開いたりコメントを残したりできる。初期設定では書き込みアクションの前に都度許可を求めるが、信頼を確立した後はオートパイロットに切り替え可能だ。
さらにMemory++と/chronicleによって、アプリ、CLI、VS Code、github.comをまたいだセッションの文脈が連続する。パートナー企業（LaunchDarkly、Sonar、Amplitude、PagerDutyなど）が構築したエージェントアプリも統合され、開発者はGitHubを離れることなく、馴染みのツールをエージェント主導のワークフローに組み込める。
エージェント主導開発の未来を見据えて
プロフェッショナルなソフトウェア開発には、判断、検証、説明責任が不可欠だ。GitHub Copilotアプリ、サンドボックス、コードレビュー、自動化、文脈連続性、パートナーエコシステムは、エージェントがより多くの作業を担いながらも、開発者が品質、ポリシー、デリバリーの統制を保つための一つのシステムとして結実している。
GitHub Blogの記事では、エージェント主導の開発がプラットフォーム全体で拡大する中、可用性を第一に据え、これらのシステムを堅牢化し、チームが日々の開発で依存できる速さと信頼性を確保していく姿勢が示されている。
この記事のポイント
- GitHub Copilotアプリは複数エージェントを並行管理し、worktreeとAgent Mergeで混乱を防ぐコントロールセンターとして機能する
- Canvasにより、チャットの指示を視覚的な作業面に展開し、人間とエージェントが同じキャンバス上で協調できる
- ローカルとクラウドのサンドボックスで、本番環境に触れずにエージェントがコードを実行・検証できる
- コードレビュー機能は中程度推論モデルやセキュリティ専用スキルで品質を保ち、Azure DevOpsでもネイティブ利用可能
- SDKと刷新されたCLIにより、開発者自身のツールや自動化を同じエージェントランタイム上に構築できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
VS Codeで始めるGitHub超入門！リポジトリ作成からAI活用まで
VS CodeとGitを連携させれば、エディタから離れることなくGitHub上のバージョン管理が完結する。コードを書きながらコミット、ブランチの切り替え、プッシュまで行えるため、作業の中断が大幅に減る。
本記事では、フォルダの初期化から変更の追跡、ブランチのマージ、リモートへの公開、さらにMCP（Model Context Protocol）を使ったAI支援まで、実務で頻繁に使う一連の流れを手順を追って解説する。Gitの概念を簡単な言葉で補足しながら進めるので、バージョン管理が初めてでも迷わないはずだ。
VS Codeで始めるGitとGitHubの基本
GitとGitHubの役割
Gitはソースコードの変更履歴を管理するプログラムだ。GitHubはその履歴を保管するリモートの場所で、いわば「コードの倉庫」である。Gitでローカルに記録した履歴をGitHubにアップロードすることで、チームでの共有やバックアップが実現する。
VS Codeが開発効率を上げる理由
VS Code（Visual Studio Code）はMicrosoftが提供する無料のソースコードエディタだ。内部にGit機能が統合されており、GUI上でリポジトリの初期化やコミット、ブランチ操作を行える。ターミナルとエディタを行き来する手間を省き、エディタのサイドバーやコマンドパレットからほとんどのGit操作を実行できる。
リポジトリの初期化と最初のコミット
まずはローカルのフォルダをGitリポジトリとして初期化し、ファイルを追跡してコミットする流れを確認しよう。
VS Codeを起動し、左側のアクティビティバーにあるExplorerアイコン（重なったファイルのような形）をクリックする。次に「Open Folder」ボタンから、GitHubに上げたいコードが入ったフォルダを開く。
続いて、アクティビティバーの上から3番目にあるSource Controlアイコンを選択する。すると「Initialize Repository」ボタンが表示されるので、これをクリックする。これでフォルダがGitリポジトリとして機能し始める。
初期化直後は、Source Controlパネル内のファイル名の横に「U」（Untracked）が表示される。ファイルを追跡対象にするには、ファイル名の隣のプラス記号をクリックする。全ファイルを一括でステージングしたい場合は「CHANGES」の右にあるプラスを押せばよい。ステージングされるとファイルの状態は「A」（Added）に変わる。
ステージングした変更を記録するには、Source Controlパネル上部のメッセージ入力欄にコミットメッセージを記入し、「Commit」ボタンを押す。ここでCopilotの提案機能を使えば、差分に合ったメッセージを自動生成することも可能だ。
ブランチの作成と切り替え
コマンドパレットからのブランチ作成
デフォルトでは通常「main」ブランチが使われる。新機能の開発や修正作業は、別のブランチを切って進めるのが一般的だ。
Shift + Command + P（Mac）またはCtrl + Shift + P（Windows）でコマンドパレットを開き、「create branch」と入力する。候補から「Git: Create Branch…」を選び、任意のブランチ名（例「new-features」）を入力してEnterで確定する。すると新しいブランチが作成され、自動的にそのブランチに切り替わる。ウィンドウ左下のブランチ名表示で確認できる。
作業ブランチでの変更と確認
新しいブランチ上でコードを編集すると、後述するようにエディタの左側（ガター）に色付きのインジケータが現れる。この状態でファイルを保存し、Source Controlパネルから変更をステージングしてコミットする流れは先ほどと同じだ。
変更の追跡と差分の確認
ガターに表示される変更インジケーター
VS Codeでファイルを編集すると、行番号の左側にあるガターと呼ばれる領域に色分けされた目印が表示される。新しく追加した行には緑色のバー、既存の行を修正した箇所には青色の模様付きバー、行を削除した場所には赤色の矢印が現れる。これによって、どの変更が未コミットなのかを瞬時に把握できる。
このように、エディタの左側にある「ガター」に色付きのインジケーターが表示され、どの行を追加・変更・削除したかが一目でわかる。
差分の表示（並列表示とインラインビュー）
変更内容を詳しく比較したいときは、Source Controlパネルでファイル名をクリックする。すると左右に分割された差分ビューが開き、変更前後のコードを横に並べて確認できる。分割ビューの右上にある三点リーダーから「Inline View」を選ぶと、ひとつの画面内に差分がインラインで表示される。このビュー上で直接編集を加えることも可能だ。
ブランチのマージとGitHubへの公開
マージ手順
作業ブランチでの変更をmainブランチに取り込むには、まずmainブランチに切り替える。ウィンドウ左下のブランチ名をクリックし、表示される一覧から「main」を選択する。その後、Source Controlパネルの三点リーダーから「Branch」にカーソルを合わせ、「Merge…」をクリックする。マージ元として先ほどまで作業していたブランチを選べば、mainブランチに変更が統合される。
リポジトリのプッシュと公開
ローカルのリポジトリをGitHub上に公開するには、Source Controlパネルにある「Publish Branch」ボタンを押す。VS Codeが公開時の可視性（プライベートかパブリックか）を尋ねてくるので、目的に合わせて選択する。処理が完了すると、通知からそのままGitHub上のリポジトリを開ける。
リポジトリのクローン
既存のリポジトリを手元に複製して作業したい場合は、GitHubのリポジトリページで緑色の「<> Code」ボタンをクリックし、URLをコピーする。VS Codeのコマンドパレットを開き「clone」と入力して「Git: Clone」を選び、URLを貼り付ける。保存先フォルダを指定すると、クローンが開始される。完了後に「Open」を選択すれば、すぐにローカルで開発を始められる。
MCPでAIを活用する
GitHub MCP拡張機能のインストール
MCP（Model Context Protocol）は、AIツールが安全に外部サービスと連携するためのプロトコルだ。VS CodeでGitHubのMCPを利用すると、Copilotチャットがリポジトリの情報を参照しながらコード生成やIssue作成を行えるようになる。
アクティビティバーのExtensionsアイコンを開き、「@mcp github」で検索する。該当するGitHub公式の拡張機能をインストールし、認証を許可すると、下部のパネルにMCPサーバーが追加される。これで準備は完了だ。
Copilotチャットとの連携
チャットウィンドウから自然言語で「フラッシュカードアプリに新機能を追加して」などと指示すると、Copilotが必要なツールを自動的に呼び出し、コードやIssueを生成する。手作業でファイルを開いて確認していた手順をAIに任せられるため、プロトタイピングの速度が格段に上がる。
この記事のポイント
- VS Codeに統合されたGit機能を使えば、エディタだけでコミットやブランチ操作が完結する
- リポジトリの初期化から最初のコミットまでは四つのステップで完了
- ガターの色分けインジケーターで、追加・変更・削除を瞬時に識別できる
- ブランチのマージやGitHubへの公開もボタンひとつで実行可能
- MCP拡張機能を導入すると、Copilotがリポジトリの文脈を理解したAI支援を提供する
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GitHub Shop新作「ESC」コレクション、開発者のまま外へ出かけよう
GitHubは2026年5月28日、公式ショップの新作コレクション「ESC」を発表した。Tシャツやキャップ、スライドサンダル、さらにはタコキャット型のドリンクホルダーまで、デスクを離れて過ごす夏のためのグッズが揃っている。単なるノベルティではなく、開発者コミュニティの遊び心を形にしたラインアップだ。
このコレクション最大の特徴は、HTMLタグをあしらったアパレルと、CopilotやOctocatのトロピカルデザインだ。「デスクの外にも良いアイデアは転がっている」という考え方が企画の起点になっている。プールサイドやビーチでリラックスしながら、ふとバグの解決策を思いつく瞬間を後押しする仕掛けだ。
HTMLタグが服に 開発者ジョークを身にまとう
「ESC」コレクションの中心は、普段着として着られるアパレル製品だ。特に話題を呼んでいるのが、Tシャツ、キャップ、スライドサンダルにそれぞれHTMLタグの<body>、<header>、<footer>をあしらったデザインである。
これまでのGitHub Shopではキャップや靴下が定番だった。一方で「Tシャツはないのか」という声がコミュニティから多く寄せられていた。今回の<body>Tシャツは、まさにその要望に応えたかたちだ。
<header>ハットは新しいカラーバリエーションが追加されている。頭部を飾るという意味で、HTMLのセマンティクスと物理的な位置が見事に一致している点が面白い。スライドサンダルに<footer>と書かれているのも、同じ発想だ。
このネーミングは単なるジョークに留まらず、開発者文化のアイデンティティを日常生活に溶け込ませる工夫と言える。GitHub Shopの担当者は、デスクの外でこそ優れた問題解決が生まれるというメッセージを、商品名そのものに込めたのだろう。
ビーチでもCopilot トロピカルデザインのCabanaセット
より大胆なデザインを求める開発者には、トロピカル柄のCabanaセットが用意された。上下が揃いになったシャツとショーツには、OctocatことMona、GitHub Copilot、そしてラバーダックのキャラクターがヤシの木や花とともに描かれている。
ラバーダックは「ラバーダックデバッグ」と呼ばれるプログラミング技法に由来する。コードの問題を誰かに説明する過程で自己解決する手法で、開発者にはおなじみの存在だ。GitHub Copilotと並べて配置することで、AI時代の新しいペアプログラミングを連想させるデザインになっている。
派手なCabanaセットの対極として、より控えめなリネンシャツも用意されている。Hibiscus Tocatリネンシャツは、ハイビスカス柄の中に小さくOctocatを忍ばせたデザインで、開発者と気づかれずに開発者アピールできる逸品だ。
さらに、クーラートートバッグも注目に値する。Invertocatデザインの保冷バッグは、ビーチやプールサイドに飲み物を持ち運ぶのに最適なサイズ感だ。開発者がコードから離れて過ごす時間を、きちんとサポートする機能性を持っている。
ドリンクを冷やす小さなパーカー 人気商品をミニチュア化
ESCコレクションのユニークなアイテムとして、ブラックInvertocatパーカーのデザインをそのまま缶クーラー（クージー）に落とし込んだ製品がある。フード付きパーカーを模した小さなドリンクホルダーで、人気アパレル商品のミニチュア版という発想が秀逸だ。
本家のInvertocatパーカーはGitHub Shopのベストセラーである。今回それを「缶用」として展開したことは、スケーリングとユーモアの両面で開発者マインドをくすぐる。実用品でありながら、コードレビューで突っ込みたくなる会話のきっかけにもなるだろう。
さらに、プール用のドリンクフロートとしてMonaフロートも登場した。Octocatの形状をした浮き輪型ドリンクホルダーで、プールに浮かべながら飲み物を楽しめる。開発者のデスク周りにOctocatグッズが並ぶように、水辺にもOctocatを持ち込む発想である。
これらの商品からは、「開発者であることをオフの時間にも楽しもう」というブランドの一貫した姿勢が感じられる。コードを書くことだけが開発者ではない。問題解決の思考は日常のあらゆる場面で活きるという考え方だ。
ショッピング体験にも技術を パーソナライズ機能と今後の展開
GitHub Shopのサイト自体にも技術的な工夫が施されている。商品画像の背景にはLiDARスキャナーが使われており、ユーザーは色味やズームを自由に変更して、自分好みのビジュアルで商品を確認できる。ECサイトの枠を超え、開発者に「どんな技術で実装しているのか」を想像させる仕掛けだ。
これは単なるファッション販売ではなく、GitHubブランドの世界観をデジタル上で体験させる戦略と言える。商品を選ぶ行為そのものをインタラクティブな開発者体験に昇華している点がユニークだ。
ESCコレクションの発表と併せて、GitHubは近くワールドカップ関連の特別企画も準備していると予告している。開発者文化と世界的なスポーツイベントをどう結びつけるのか、続報が待たれるところだ。
この記事のポイント
- GitHub Shopの新作「ESC」コレクションは、デスクを離れた場所でのリラックスをテーマにしている
- HTMLタグにちなんだアパレルや、Copilot・Octocatをあしらったトロピカルデザインが特徴
- ベストセラーパーカーを模した缶クーラーなど、実用品に開発者向けの遊び心を落とし込んでいる
- 商品画像にLiDARスキャナーを使うなど、ショッピング体験そのものにも技術的工夫がある
- コードから離れる時間が、むしろ良いアイデアを生むというブランド思想が商品全体を貫いている
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GitHubへの不正アクセス調査詳報、攻撃者は内部リポジトリに侵入するも影響は限定的
2026年5月20日、GitHubは自社が所有する一部の内部リポジトリに対して、第三者による不正アクセスがあったことを公表した。GitHubの最高情報セキュリティ責任者（CISO）であるAlexis Wales氏がGitHub Blogで発表した調査報告によれば、ユーザーデータや個人リポジトリ、GitHub.comを含むサービスには一切の影響がなかったという。
攻撃者は漏洩したトークン（認証情報）を用いて、GitHub社が管理していた内部リポジトリの一部を閲覧・クローンした。ただし、ソースコードの改ざんやマルウェアの注入、ユーザー情報へのアクセスは確認されていない。GitHubのインシデント対応チームは、発覚から数分以内に問題のトークンを無効化し、侵入経路を遮断した。
本稿ではこのインシデントの技術的な背景、影響範囲、そしてGitHubを利用する開発者が今すぐ実践すべきセキュリティ対策について詳しく解説する。大規模プラットフォームでさえトークン管理のミスが致命的になりうるという現実は、すべてのソフトウェア開発者にとって重要な教訓だ。
何が起きたのか、侵入の経路と期間
GitHubによれば、最初に異常が検知されたのは2026年5月中旬のことだ。同社のセキュリティ監視システムが、特定のGitHub Actionsトークンを用いた不審なリポジトリアクセスを検出した。このトークンはある外部サービスとのインテグレーションに使用されていたが、意図しない形で第三者の手に渡っていた。
トークンとは、パスワードの代わりにシステム間の認証に使う文字列のことを指す。たとえばAPIを呼び出すときやCI/CDパイプライン（コードのビルドやテストを自動化する仕組み）でリポジトリにアクセスする際に必要になる。このトークンが漏れると、正規のユーザーになりすましてリポジトリを操作できてしまう。
問題のトークンは、GitHubが所有する特定のリポジトリに対する読み取り権限と、一部のリポジトリに対しては書き込み権限も持っていた。これにより攻撃者は、リポジトリの内容を手元にクローン（複製）することが可能だった。ただしGitHubの発表では、攻撃者が実際にコードを改ざんしたり、悪意ある変更を加えたりした証拠は見つかっていないとされている。
攻撃者の行動を振り返る
GitHubのセキュリティチームがログを詳細に分析したところ、攻撃者は以下のような行動をとっていた。トークンを取得したあと、GitHubのAPIを経由してターゲットのリポジトリリストを取得。次に、少数のリポジトリを選んでクローン操作を実行していた。このアクセスパターンは自動化されたスクリプトによるものではなく、人間が手動で操作している形跡が強かったという。
重要なのは、攻撃者がアクセスできたのが「GitHub自身が管理する内部リポジトリ」に限定されていた点だ。一般ユーザーや企業がGitHub上で運用するプライベートリポジトリ、オープンソースプロジェクトのリポジトリ、そしてGitHub.comのサービス基盤そのものには一切アクセスできていなかった。
上の図は、今回のインシデントにおける攻撃者の侵入経路とGitHubが取った即時対応を比較したものだ。漏洩トークンによる不正アクセスは数分で封じ込められ、ログ解析によって影響範囲が正確に特定された。
なぜトークンは漏洩したのか
現時点でGitHubは、トークン漏洩の正確な経路について詳細を明らかにしていない。しかし、過去数年にわたってソフトウェア業界で多発しているトークン漏洩インシデントと照らし合わせると、いくつかの可能性が浮かび上がる。
考えられる漏洩パターン
最も多いのは、ソースコード内にトークンがハードコード（直接埋め込み）されていたケースだ。開発中の利便性からAPIキーやシークレットをコードに直書きし、そのままGitHubの公開リポジトリや内部リポジトリにプッシュしてしまう事故は後を絶たない。
別の可能性としては、CI/CDパイプラインの設定ミスだ。GitHub Actionsのワークフローファイルが適切に構成されておらず、ログにトークンが表示されていたり、サードパーティのサービスに意図せずトークンが送信されていたりするケースがある。
三つ目のパターンは、サプライチェーン攻撃だ。依存している外部ライブラリやツールに悪意あるコードが仕込まれ、ビルドプロセス中に環境変数からトークンを抜き取る手法である。2024年以降、AI開発ツールの増加に伴い、この種の攻撃は急増している。
いずれの経路であれ、根本的な問題は「トークンの権限が必要以上に強かった」ことだ。原則として、トークンには作業に必要な最小限の権限だけを付与すべきである。この「最小権限の原則」を守っていれば、たとえトークンが漏洩しても被害範囲は限定的だったはずだ。
インテグレーションの盲点
今回のケースで注目すべきは、攻撃者が狙ったのが「GitHub自身が所有する内部リポジトリ」であり、ユーザーのリポジトリではなかった点だ。Alexis Wales氏の発表によると、漏洩したトークンは外部サービスとのインテグレーションに使われていた。つまり、GitHubが信頼できるパートナーとして連携していたサービス側で何らかのセキュリティ問題が発生し、トークンが漏洩した可能性が高い。
これは多くの企業が直面するジレンマを浮き彫りにしている。業務効率化のために外部サービスとの連携を深めるほど、トークンの管理箇所は増え、攻撃対象領域（アタックサーフェス）も広がる。GitHubのようなセキュリティ専門企業でさえ、このバランスに苦心しているのだ。
影響範囲と被害の実態
GitHubが公表した調査結果から、今回のインシデントで実際にどのような影響があったのかを具体的に見ていく。
図の通り、影響は極めて限定的だった。GitHubの広報は「ソースコードの一部が意図せず開示された可能性は否定できないが、ユーザーに対する二次被害や連鎖的なセキュリティ侵害は発生していない」としている。
ソースコードの改ざんはなかった
GitHubの調査チームが最も注意深く検証したのは、攻撃者がリポジトリのコードを改ざんしたかどうかだ。結論としては、コミットログやファイルのハッシュ値を含む完全な監査の結果、コードの修正・削除・マルウェアの注入を示す証拠は一切確認されなかった。
これはGitHubのバージョン管理システム（Git）の特性が功を奏した面もある。Gitはすべての変更履歴をSHA-1ハッシュで保護しており、過去のコミットを改ざんしようとすると直ちに検知できる仕組みになっている。攻撃者が万が一コードを書き換えたとしても、その痕跡は完全に残るため、発見は容易だったはずだ。
このインシデントから開発者が学ぶべきこと
GitHubのような巨大プラットフォームですらトークン漏洩を完全に防げなかった事実は、すべての開発者にとって警鐘だ。しかしこのインシデントからは、単に驚くだけでなく、具体的な教訓と実践可能な対策を引き出すことができる。
トークン管理の基本を徹底する
GitHubはインシデント報告の中で、トークン管理のベストプラクティスを改めて強調している。特に重要なのは以下の4点だ。
- トークンの有効期限を短く設定する。可能であれば数時間単位でローテーションする
- トークンに付与する権限を必要最小限に絞り込む。特定のリポジトリだけに読み取り権限を与え、書き込みは別トークンに分離する
- ソースコードや設定ファイルにトークンを直接記述しない。GitHubのシークレット機能や専用のシークレット管理サービス（例としてHashiCorp Vaultやクラウド各社のキー管理サービス）を使う
- リポジトリにトークンが誤ってプッシュされていないか、定期的にスキャンする。GitHubにはプッシュ時に自動検出する機能が標準搭載されている
これらの対策は決して難しいものではない。むしろGitHub Actionsや各種CI/CDツールには、トークンを安全に扱うための仕組みが最初から用意されている。設定を後回しにせず、プロジェクト開始時点で組み込んでしまうのが賢いやり方だ。
侵害を前提とした設計へ
より根本的な教訓は「侵害は起こりうる」という前提に立つことだ。どんなにセキュリティに投資していても、サプライチェーン攻撃やゼロデイ脆弱性（修正パッチが存在しない未知の脆弱性）によって防御線を突破される可能性は常にある。
GitHubのインシデント対応が迅速だった背景には、異常なAPI呼び出しパターンを即座に検知できる監視システムと、トークンを数クリックで無効化できる運用フローが整備されていたことがある。これらは事後対応（インシデントレスポンス）の設計が十分だったからこそ機能した。
この図が示すように、セキュリティの考え方は「侵入を100%防ぐ」から「侵入されても被害を最小限に抑える」へとシフトする必要がある。具体的には、トークンの権限制限、ネットワークのセグメント分離、操作ログの集中管理といった対策を組み合わせることになる。
GitHubの対応から見る、透明性あるインシデント開示の重要性
今回のインシデントで特筆すべきは、GitHubが公表のタイミングと内容において高い透明性を示したことだ。CISOであるAlexis Wales氏が自ら筆を取り、わずか数日のうちに詳細な調査報告を公開した。
セキュリティ業界では、こうした迅速な情報開示は「ラディカル・トランスペアレンシー（徹底した透明性）」と呼ばれ、近年ではGoogleやMicrosoftも同様の姿勢を取っている。ユーザーにとっては、隠蔽されるよりも正直に報告されたほうが信頼を損なわず、適切な防御策を取る時間も確保できる。
GitHubの発表には「ユーザーが取るべき具体的なアクションはない」と明記されていた。これ自体が重要な情報だ。影響範囲が明確に線引きされているからこそ、ユーザーは不要な心配をせずに済む。逆に言えば、影響範囲が不明瞭な発表ほどユーザーの不安と憶測を招く。
この記事のポイント
- 2026年5月、GitHubが内部リポジトリへの不正アクセスを公表。攻撃者は漏洩したトークンを使用して一部のリポジトリを閲覧・クローンしたが、コードの改ざんやユーザーデータへのアクセスはなかった
- 影響を受けたのはGitHub自身が所有する一部の内部リポジトリのみで、一般ユーザーのプライベートリポジトリやオープンソースリポジトリには一切影響が及んでいない
- トークン漏洩の原因は調査中だが、過去の業界事例からハードコードやCI/CD設定ミス、サプライチェーン攻撃などの可能性が考えられる
- 開発者が取るべき対策は明確で、トークンの有効期限短縮、最小権限の原則の徹底、シークレット管理サービスの利用、プッシュ時の自動スキャン活用が有効
- GitHubの迅速かつ透明性の高いインシデント開示姿勢は、業界全体の模範となる対応だった
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GitHubがアクセシビリティエージェントを試験運用。3,535件のPRをレビューし解決率68%
GitHubは2026年5月、実験的な汎用アクセシビリティエージェントの試験運用を開始した。このエージェントはプルリクエスト内のフロントエンドコードを自動的にレビューし、アクセシビリティ上の問題を指摘する。さらに多くのケースで修正案まで提示する。
運用開始後に3,535件のプルリクエストをチェックし、68%という高い解決率を達成。構造の明確化やインタラクティブ要素の名前付け、テキスト代替など、日常的に発生するバリアを自動で取り除く仕組みだ。
GitHubのブログで公開された知見には、アクセシビリティチームが取り組んだ設計方針や、LLMエージェントならではの制限への対処法が詰まっている。本記事ではその要点を技術者向けに掘り下げる。
エージェントの目的と初期成果
📋 エージェントが検出した問題の上位5種
- 支援技術への構造と関係性の明示不足
- インタラクティブ要素の名前の不明瞭さ
- 重要なアナウンスがユーザーに届かない
- 非テキストコンテンツの代替テキスト欠如
- フォーカス順序が視覚レイアウトと一致しない
※エージェントは自動修正を適用するか、開発者に具体的な提案を提示する
GitHubの発表によれば、このエージェントはアクセシビリティを「完全に解決する」ことを狙っていない。現場のエンジニアがアクセシビリティ上のバリアを見つけて取り除く作業を「増強する」存在として設計された。そのため、あらゆるケースに対応する「銀の弾丸」ではないと明言されている。
この姿勢が実験の立ち上げを加速させ、社内の賛同を得るうえで有効だった。スコープを限定し、明確な責任範囲を共有することで、過度な期待を防ぎつつ素早く実装できたという。
エージェント設計を支える考え方
GitHubのチームは「障害の社会モデル」に基づき、環境の作り方によってアクセス障壁が生まれると捉えている。ユーザーインターフェースの構築方法そのものが障壁を生み出すため、エージェントは仲間の作業を補い、そうした障壁の除去を支援する役割を担う。
つまり「人間の判断を置き換えるAI」ではなく、「アクセシビリティ専門家の補助輪」として機能させる考え方だ。この方針が、後述するサブエージェント構造や複雑性評価の仕組みに一貫して織り込まれている。
過去のアクセシビリティ改善がエージェントを支えた
GitHubにはLLMが普及する以前から、アクセシビリティの問題を体系的に記録し修正する仕組みが存在していた。テンプレート化された報告フォーム、再現手順、WCAG達成基準との紐付け、修正プルリクエストへのクロスリンクといった豊富なメタデータを備えた単一のリポジトリに、すべての問題が集約されている。
この構造化されたデータの蓄積こそが、エージェントにとって理想的な「学習素材」になった。GitHubのブログ記事は「過去の手作業による監査と修正こそが最大の資産」と強調している。問題とその修正コードを参照することで、エージェントは組織固有のコーディング規約やUIパターンに沿った適切な提案を引き出せるようになった。
さらに、LLMの非決定的な「あいまい一致」がここでは強みに転じた。定型のスキルファイルだけで「アクセシビリティのベストプラクティスに従え」と指示しても、膨大な非アクセシブルコードで訓練されたモデルはむしろアンチパターンを生成しがちだ。過去の修正履歴から具体的な文脈を参照できることで、質の高い出力が安定した。
効率的なトークン消費のためのサブエージェント戦略
アクセシビリティはコード、デザイン、ライティングなど多領域にまたがる全体的な関心事だ。そのため、一般的なエージェントを作ろうとすると、1回の処理で大量のトークンを消費し、応答速度の低下や運用コスト増、信頼性の低下を招く。
⏺ 親エージェント（Orchestrator）
- リクエストの振り分けとコードスキャン
- 複雑性スコアの算出
- エスカレーション判断と再監査ループ
コード監査とWCAG調査を実施し、構造化された監査レポートを出力する。コード変更は一切行わない。
親エージェントから渡された構造化レポートを基に、コード修正またはガイダンス文書を生成する。
親エージェントが出力を検証し、必要なら人間の専門家へエスカレーションする
2つのサブエージェントはサンドボックス化され、直接通信はしない。構造化テンプレートを介して情報を受け渡す。
GitHubは当初、1つのモノリシックなエージェントで始めたが、すぐに限界を感じたという。そこで採用したのが、2つの専用サブエージェントによるアーキテクチャだ。
1つ目は「パッシブなレビューア」。コードの監査とWCAG達成基準との照合を行い、構造化されたレポートを出力する。2つ目は「アクティブな実装者」。親エージェントがレポートを精査した後、修正が必要な箇所だけにコード変更を加える。両者は直接情報をやり取りせず、テンプレート化されたスキーマファイルで内容を渡す。
この構成には明確な意図がある。レビューサブエージェントは「意見を持たず」すべての問題を列挙し、親エージェントが重要度を評価する。複数の重大なWCAG違反がある場合や、高リスクと判定されたパターンでは自動修正を試みず、アクセシビリティチームへのエスカレーションを促す。コードの複雑性が閾値を超えれば、修正ではなくガイダンス提供のみの「ガイダンス専用モード」に切り替わる。
さらに、メソッド的な手順で指示を実行させることが精度向上の鍵だった。親エージェントに「フェーズ1 調査」「フェーズ2 コード監査」「フェーズ3 構造化出力」という順序を徹底させ、各フェーズ内のステップも固定順で実行する。この線形な流れは、人間が手動で監査と修正を行うときの思考手順をそのままなぞったものだ。
エージェントの限界を理解し対策する
どれほど精心に設計しても、LLMベースのエージェントには避けられない落とし穴がある。GitHubは実験を通じて、以下の領域に特に注意を払った。
コードの複雑性を数値化して介入を制御する。シェルスクリプトでコードの相対的な複雑度をスコア化し、閾値を超えた場合は自動修正を禁止する。エージェントは「アクセシビリティチームに相談してください」と開発者に伝えるだけにとどめる。
高リスクパターンをブラックリスト化する。ドラッグアンドドロップ、トースト通知、リッチテキストエディタ、ツリービュー、データグリッドなど、現在のLLMでは支援技術と完全に調和する実装が困難なUIパターンが対象だ。これらのパターンを含むコードに対しては、エージェントは修正を生成せず、必ず人間の介入を求める。
「行動バイアス」を抑える。LLMはとにかく何かを生成したがる性質があるため、コードを書かないよう指示されたルールをかいくぐろうとする行動が見られた。これに対抗するため、指示違反を防ぐ「アンチゲーミング」ルールを導入した。
自動化で検出できない36%の壁を認識する。WCAG 2.1のレベルAとAAの達成基準は55項目あるが、そのうち決定論的な自動チェックで検出できるのは35項目にとどまる。残り約36%は手動評価が不可避だ。エージェントの成功率だけを見て安心してはならず、設計段階から手動でアクセシビリティを検討する重要性をGitHubは強調している。
WCAG A/AA達成基準55項目の内訳
自動検出可能
手動評価が必要
LLMエージェントはこの36%の領域に挑戦しているが、まだ完全ではない。設計とプロトタイピングの段階で人間がバリアを特定するプロセスが不可欠。
加えて、エージェントの出力を定期的に手動レビューし、プルリクエストレビュアーのフィードバックを収集する仕組みも整えている。これにより、指示やリソースを改善すべき領域を継続的に特定している。
この記事のポイント
- GitHubのアクセシビリティエージェントは、3,535件のPRをレビューし68%の解決率を記録した
- エージェントは「人間の代替」ではなく「増強」を目的とし、スコープを限定して運用
- 過去の手動監査で蓄積した構造化データが、エージェントの精度を飛躍的に高めた
- サブエージェント構造と線形な指示実行でトークン消費を抑え、精度を向上
- 自動検出できないWCAG基準の約36%を手動で補い、高リスクパターンは生成を禁止する対策が鍵
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
git push操作でサーバー制御可能なRCE脆弱性 GitHubが2時間で修正完了
2026年3月4日、GitHubはバグ報奨金プログラムを通じて極めて深刻な脆弱性の報告を受けた。対象はgit push 操作のパイプラインであり、悪用されるとGitHubのサーバー上で任意のコマンドを実行される可能性があった。GitHubは報告から2時間以内に修正を展開し、その後の調査で実際の悪用は一切なかったと結論づけている。
この脆弱性は、git push に付与できる --push-option で送った文字列が、サーバー内部で適切にサニタイズされずにメタデータへ挿入されることに起因する。攻撃者は細工したオプションを与えるだけで、本来信頼される内部フィールドを偽装し、サンドボックスを回避してコードを実行できた。
本記事では報告の経緯、脆弱性の仕組み、GitHubの対応と調査結果、そして多層防御の重要性について詳しく解説する。自社運用のGitHub Enterprise Serverを管理するエンジニアは、早急なアップデートが推奨されるため、最後の対応ポイントまで確認してほしい。
バグ報奨金プログラムからの報告と即時対応
2026年3月4日、クラウドセキュリティ企業Wizの研究者らがGitHubのバグ報奨金プログラムにリモートコード実行（RCE）の脆弱性を報告した。この脆弱性は github.com だけでなく、GitHub Enterprise Cloud（データレジデンシーやEnterprise Managed Usersを含む）および GitHub Enterprise Server にも影響するものだった。
報告によれば、リポジトリへのプッシュ権限を持つユーザー（自身で作成したリポジトリを含む）であれば誰でも、単一の git push コマンドでサーバー上での任意コマンド実行が可能だった。攻撃に必要なのは、プッシュ時に指定する --push-option に細工した値を仕込むだけである。
検証から修正までのスピード
GitHubのセキュリティチームは報告を受け取ると直ちに検証を開始した。約40分で社内環境での再現に成功し、重大度を確認。その時点でUTC 17時45分、根本原因の特定と修正パッチの作成が始まった。そして同日19時（UTC）には github.com への修正展開が完了した。報告からわずか2時間弱での出来事だ。
この迅速な対応を可能にしたのは、詳細な再現手順と影響範囲が報告の段階で明確に示されていたことにある。Wizの研究者はプッシュオプションを経由したメタデータ汚染から環境偽装、サンドボックス回避に至る一連の攻撃チェーンを完全に解明していた。
脆弱性の仕組み git push オプションから任意コード実行まで
ここでは攻撃手法の技術的な流れを整理する。核となるのは、GitHubの内部サービス間でプッシュメタデータをやり取りする際に使われる区切り文字と、ユーザー入力の不適切な扱いだ。
プッシュオプションが処理される流れ
git push には --push-option（または -o）というオプションがある。これはクライアントがサーバーに対してキーバリューペアの文字列を追加で送るための正当なGit機能だ。CI/CDパイプラインへのパラメータ渡しなどで利用される。
しかしGitHub内部では、このユーザー提供の値がそのままの形で内部プロトコルのメタデータに埋め込まれていた。メタデータには「リポジトリ種別」や「処理環境」などを指定するフィールドが含まれており、各フィールドは特定の区切り文字で分割される。
サニタイズ不足が引き起こす注入攻撃
問題は、この内部区切り文字として使われていた文字が、ユーザー入力にも含まれ得る点だった。攻撃者はプッシュオプションの値に区切り文字を混入させることで、メタデータを意図的に「延長」または「上書き」できた。
より具体的には、プッシュオプションに key=value;injected_field=malicious のような文字列を指定する。内部サービスはこの文字列を単一の値として扱うが、後段のサービスがメタデータをパースする際に、区切り文字 ; で新たなフィールドとして解釈してしまう。こうして下流のサービスは、攻撃者が注入したフィールドを「信頼された内部値」として処理する。
研究者はこの仕組みを連鎖的に利用し、プッシュが処理される環境を上書きし、通常は有効なサンドボックス制限を無効化した。最終的にサーバー上で任意のコマンドを実行するコードパスに到達する。
; が含まれ、内部フィールドを偽装■ 修正後:ユーザー入力がサニタイズされ、注入不可に
上図のように、ユーザーが指定したプッシュオプションが内部の区切り文字を経由してメタデータを汚染していた。修正後はサニタイズ処理が追加され、攻撃者が意図的にフィールドを延長できなくなっている。
脆弱性への修正と悪用調査
github.com への緊急修正
2026年3月4日19時（UTC）、GitHubは github.com に修正を展開した。この修正により、プッシュオプションの値が内部メタデータのフィールド区切り文字を含まないよう適切にエスケープされる。以後、ユーザー入力が信頼された内部フィールドを上書きすることは不可能になった。
GitHub Enterprise Server 向けパッチとCVE
セルフホスト型の GitHub Enterprise Server (GHES) についても、同日中に全サポートバージョン向けのパッチが準備された。具体的には以下のリリース以降で修正が適用されている。
- GHES 3.14.25 以降
- GHES 3.15.20 以降
- GHES 3.16.16 以降
- GHES 3.17.13 以降
- GHES 3.18.7 以降
- GHES 3.19.4 以降
- GHES 3.20.0 以降
この脆弱性には CVE-2026-3854 が割り当てられている。公開されたCVE情報は以下の通りだ。
- CVE番号: CVE-2026-3854
- 深刻度: Critical（緊急）
- 影響範囲: 認証済みかつプッシュ権限を持つユーザーによるリモートコード実行
GitHubのCISOであるAlexis Wales氏は公式ブログで、GHESの全管理者に対し「直ちに最新のパッチリリースへアップグレードすることを強く推奨する」と呼びかけている。
悪用の有無を徹底調査
修正と並行して、GitHubは不正利用の痕跡がないかフォレンジック調査を開始した。この脆弱性には調査を容易にする特異な性質があった。悪用が成功した場合、サーバーは通常運用では決して通過しない特異なコードパスを必ず実行する。攻撃者がこれを回避することは構造上不可能である。
GitHubのエンジニアはこのコードパスにログ出力を仕込み、全テレメトリデータを解析した。その結果、以下の事実が確認された。
- 該当コードパスが実行されたすべてのインスタンスは、Wizの研究者自身の検証作業と完全に一致した。
- 他のユーザーやアカウントによる同コードパスの実行は一度も観測されなかった。
- 顧客データへのアクセス、改ざん、持ち出しは一切発生しなかった。
これにより、github.com 上のリポジトリに対する実際の攻撃は一切なかったと結論づけられた。GHES環境についても、攻撃が成立するにはインスタンス上でプッシュ権限を持つ認証済みユーザーが必要であり、念のため /var/log/github-audit.log を確認し、プッシュオプションに ; を含む不審なログがないか点検することが推奨されている。
多層防御が生んだ追加の発見
今回のインシデント対応の中で、インプットサニタイズの修正に加えて、防衛の階層化に関わるもう一つの重要な知見が得られた。攻撃が成立した理由の一部は、サーバー上に「その環境では本来不要なはずのコードパス」が存在していたことにある。
具体的には、コンテナイメージのディスク上に、異なる製品構成でのみ使われる想定のコードが含まれていた。過去のデプロイ手法ではこのコードが正しく除外されていたが、デプロイモデルの変更時にその除外ルールが引き継がれなかったのだ。
GitHubはこの不要なコードパスを、当該環境から完全に削除した。たとえ将来同種の注入脆弱性が発見されたとしても、攻撃者の行動範囲を大幅に制限できるようになっている。
このケースは、多層防御（Defense in Depth）が単なる標語ではないことを改めて示している。入力検証という第一の防衛線だけでなく、不必要なコンポーネントの除去という第二の防衛線が被害の拡大を防ぐ鍵になる。
ユーザーが今すぐ取るべき対応
GitHub.com および GitHub Enterprise Cloud ユーザー
github.com、GitHub Enterprise Cloud（Enterprise Managed UsersやData Residencyを含む）の環境は、2026年3月4日の時点で修正済みだ。これらのサービスを利用しているユーザー側での特別な対応は不要である。
GitHub Enterprise Server 管理者
セルフホスト環境では、先述のパッチバージョンへのアップグレードが不可欠だ。さらに、念のため監査ログを確認しておくとよい。具体的には /var/log/github-audit.log を対象に、プッシュオプションにセミコロン（;）を含むプッシュ操作が記録されていないか調査する。
攻撃の成立には認証済みのプッシュ権限が必要なため、内部不正やアカウント乗っ取りのリスクも考慮し、不審なアクティビティがないか定期的に確認することが望ましい。
この記事のポイント
- git push に付与する –push-option のサニタイズ不足が、内部メタデータへのフィールド注入を許しリモートコード実行に繋がった
- GitHubは報告から2時間以内に修正を展開し、サーバーログの解析で悪用の形跡がないことを確認した
- GitHub Enterprise Server 環境では、指定のパッチバージョンへの即時アップグレードが強く推奨される
- 入力サニタイズに加え、不要なコードパスを除去する多層防御の重要性が改めて浮き彫りになった
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験