GitHub package firewallは、GitHub Enterprise Cloudの企業が使える機能で、コーディングエージェント・GitHub Actionsのランナー・開発者の端末と公開レジストリの間に入り、npmのパッケージ一覧の要求とダウンロードを企業の方針で検査して、既知のマルウェアや公開から日の浅い版などを止めます。GitHubは2026年10月20日に、データ所在地付きを含むEnterprise Cloudのすべての企業向けにパブリックプレビューとして公開し、プレビューの間は無料、対応するパッケージは今のところnpmだけとしています（GitHub Changelog）。
GitHubは発表の冒頭で、パッケージのインストール時を狙い、パッケージのコードを実行することさえなくCI/CDのホストや開発者の端末から資格情報を集めるマルウェア攻撃が増えていると書いています。エージェントに npm install を任せているチームにとっては、人が見ていない場面で入ってくる依存パッケージに、企業として同じ関門を置けるようになるという話です。この記事では、発表の中身、止める条件と既定値、提供条件と料金、設定の流れ、エージェントで使う時の注意、悪いパッケージがすでに入っていた時の動き方を、GitHubとnpmの公式文書で確かめられた範囲で整理します。
3行でわかるGitHub package firewall（2026年10月21日時点）
- 止めるもの：npmのパッケージ一覧の要求と本体のダウンロードのうち、既知のマルウェア・指定した深刻度以上の脆弱性・attestationの後退・新しく加わったインストールスクリプト・公開から日の浅い版に当たるもの。
- 置く場所：コーディングエージェント・Actionsのランナー・開発者の端末と、公開レジストリの間。端末ごとにnpmの向き先をファイアウォールのURLに変えて使います。
- 使える企業：GitHub Enterprise Cloud（データ所在地付きを含む）。プレビュー中は無料で、一般提供後はActionsの課金と同じような従量課金になると案内されています（単価は未公表）。
GitHub package firewallで発表されたこと｜10月20日の事実整理
発表は、GitHub Changelogの告知、設定手順をまとめた公式ドキュメント、フィードバックを集めるGitHub Communityの議論（#210809）の3つで構成されています。内容を表にまとめます。
| 項目 | 発表の内容（2026年10月20日） |
|---|---|
| 提供の段階 | パブリックプレビュー。ドキュメントには「変更される可能性がある」と注記 |
| 対象 | GitHub Enterprise Cloudのすべての企業（データ所在地付きのEnterprise Cloudを含む） |
| 料金 | プレビュー期間中は無料。一般提供後はActionsの課金と同じような従量課金 |
| 対応するパッケージ | npmのみ |
| 置く場所 | コーディングエージェントやActionsのランナーなどの端末と、上流のパッケージレジストリの間 |
| 検査する通信 | パッケージ一覧のメタデータの要求と、パッケージ本体のダウンロード |
| 誤って止まった時 | 利用者が例外を申請する。GitHub Advanced Securityのほかの機能と似た流れ |
出典：GitHub package firewall in public preview（GitHub Changelog）、Protecting endpoints with GitHub package firewall（GitHub Docs）（いずれも2026年10月21日に確認）。
インストールの時点を守る理由
ドキュメントは、preinstallやpostinstallのようにインストール中に動くスクリプトについて「システム上で任意のコマンドを実行でき、資格情報を盗むのに使われうる」と説明しています。アプリがパッケージを読み込む前、npm install を実行した時点で被害が始まりうるため、取得の段階で止める関門を置く、という考え方です。
使い方は2段階です。1段目は、企業の管理者が方針を決める段階です。2段目は、コーディングエージェント、Actionsのランナー、開発者の端末など各端末のnpmが、公開レジストリではなくファイアウォールを通って取りに行くように設定する段階です（Changelogの「How it works」）。ファイアウォールを通るのは、パッケージ一覧のメタデータの要求と、パッケージ本体のダウンロードの両方です。
止める条件は5つ｜既定値と変えられる範囲
方針として設定できる制御は、2026年10月21日時点のドキュメントで5つあり、どれもファイアウォールを通るすべての要求に適用されます。短く言うと、既知のマルウェア、脆弱性の勧告、attestationの後退、新しいインストールスクリプト、最小公開期間の5つで、結果は次の2通りです。
- どれかに当たった版はファイアウォールで止まる
- どれにも当たらなかった版だけが端末に届く
それぞれが何を見て止めるかと既定値は、次の表のとおりです。
| 制御（画面の名前） | 何を見て止めるか | 既定値 |
|---|---|---|
| Block known malware | GitHub Advisory Databaseに、有効なマルウェアの勧告が出ているパッケージ | オン |
| Block vulnerability advisories | GitHub Advisory Databaseで、要求した版に影響する脆弱性の勧告。止める深刻度の下限をCritical only／High or higher／Medium or higher／Any severityから選ぶ | Critical only |
| Block attestation downgrades | 以前の版にあったSLSAのattestationが、要求した版に無い | オン |
| Block newly-introduced install scripts | preinstall・postinstallなど、インストール時に動くスクリプトが最近加わった | オン |
| Minimum package age | 公開から、設定した日数に満たない新しい版（1〜365日・0で無効） | 1日 |
出典：Configuring policy controls（GitHub Docs）
最小公開期間は「脅威が見つかるまでの時間」を取る
Minimum package ageは、新しく公開された版に待ち時間を設け、その間に脅威が見つかる時間を取るための制御です。最小公開期間の既定は1日です。1〜365日の範囲で変えられ、0にすると無効になります。ドキュメントは、セキュリティ修正を含む新しい版がこの制御で止まる例を自ら挙げていて、その場合は例外を申請する流れになります。待ち時間を長くすると、急いで入れたい修正版ほど例外の申請が必要になる点は、方針を決める時に考えておきたいところです。
attestationの後退と、インストールスクリプトの追加
Block attestation downgradesは、要求した版のattestationを以前の版と比べ、以前はSLSAのattestationがあったのに今回の版には無い場合に止めます。ドキュメントは、attestationが無いことは公開の手順が乗っ取られた兆候になりうると説明しています。Block newly-introduced install scriptsは、パッケージがインストール時に動くスクリプトを最近追加したかを見ます。どちらも、これまで問題のなかったパッケージに起きた変化を手がかりにする制御です。
使える企業と料金｜2026年10月21日時点で分かっていること
提供条件について、公式の文書で確かめられたことと、まだ確かめられないことを分けておきます。
| 確かめられたこと | 2026年10月21日時点で公式に確認できていないこと |
|---|---|
| GitHub Enterprise Cloudのすべての企業が対象（データ所在地付きを含む） | Enterprise Cloud以外のプランでの提供 |
| プレビュー期間中は無料 | 一般提供後の単価と、1か月あたりの金額の目安 |
| 一般提供後はActionsの課金と同じような従量課金 | 一般提供の時期 |
| 対応するのはnpmだけ | npm以外のエコシステムへの対応予定 |
出典：Availability and limitations（GitHub Changelog）
社内のnpmパッケージをGitHub Packagesに置いている場合は、もう1点あります。コミュニティの議論でGitHubのメンテナーは、今のファイアウォールは上流を設定できずnpmjs.orgからだけ取得するため、GitHub Packagesとは「どちらか一方」になると答え、一般提供に向けてその種の設定を加える見込みだと書いています（2026年10月20日・GitHub Community #210809）。公開パッケージと社内パッケージを組み合わせる方法として、ドキュメントにはJFrog Artifactoryを経由する設定がありますが、Artifactoryへの対応は実験的（experimental）と明記されています。
設定の流れ｜方針→トークン→npmの向き先→例外の審査
ここからはドキュメントの記載どおりの手順です。画面の名前は2026年10月21日時点の英語表記のままにしています。
1. 企業の方針を決める
方針を設定できるのは、企業の管理者（enterprise administrators）とエンタープライズのセキュリティ管理者（enterprise security managers）です。
- GitHub.comで対象のエンタープライズを開く（Enterprisesのページから選ぶ）
- ページ上部の Policies をクリックする
- サイドバーの Package firewall をクリックする
- 前の節の5つの制御を設定する
2. 認証用のトークンを用意する
ファイアウォールのURLはエンタープライズごとに決まり、要求のたびに、エンタープライズのメンバーであるユーザーかボットのアカウントに紐づくトークンが必要です。権限は公開リポジトリへの読み取り専用で足り、それ以上の権限は要りません。コミュニティの議論では、細かく権限を指定するトークン（fine-grained personal access token）も、公開リポジトリへの読み取り権限があれば使えるとメンテナーが答えています。トークンはCIのシークレットなどに安全に置き、リポジトリにコミットしないようドキュメントは求めています。
なお、ドキュメントの例は環境変数の名前に GITHUB_TOKEN を使っていますが、GitHub Actionsが自動で発行するトークンでそのまま通るかは、2026年10月21日時点の文書には書かれていません。要件はあくまで「エンタープライズのメンバーであるユーザーかボットのアカウントに紐づくトークン」です。
3. npmの向き先をファイアウォールに変える
利用者単位の .npmrc に次の2行を足します。ENTERPRISE はエンタープライズのスラッグに置き換え、GITHUB_TOKEN には前の手順のトークンを環境変数として入れておきます。
# 利用者単位の .npmrc（例: ~/.npmrc）
# ENTERPRISE をエンタープライズのスラッグに置き換える
registry=https://package-firewall.githubapp.com/npm/enterprises/ENTERPRISE
//package-firewall.githubapp.com/npm/enterprises/ENTERPRISE/:_authToken=${GITHUB_TOKEN}同じ設定はコマンドでも入れられます。2行目をシングルクォートで囲んでいるので、シェルがその場でトークンの値に置き換えず、${GITHUB_TOKEN} という参照のまま設定に入ります。npmは設定ファイルの ${変数名} を環境変数の値に置き換えて読みます（npm Docs「.npmrc」）。
npm config set registry \
https://package-firewall.githubapp.com/npm/enterprises/ENTERPRISE
npm config set \
'//package-firewall.githubapp.com/npm/enterprises/ENTERPRISE/:_authToken=${GITHUB_TOKEN}'設定した後は、その端末やランナーでnpmが実際に使うレジストリを確かめます。npm config get は設定の値を表示するコマンドです（npm Docs「npm-config」）。
# この環境の npm が使うレジストリを表示する
# ファイアウォールの URL（package-firewall.githubapp.com）が出ることを確かめる
npm config get registry動作環境：npm（設定の例は2026年10月21日時点のGitHubのドキュメントの記載にもとづく）。注意：本番環境で使用する前に、必ずテスト環境で動作確認してください。
4. JFrog Artifactoryを使っている場合（実験的）
Artifactoryを使っている企業は、Artifactory側にファイアウォールを上流とするnpmのリモートリポジトリを作り、各端末は今までどおりArtifactoryを向く形にもできます。ドキュメントの手順は、リモートリポジトリのURLに https://package-firewall.githubapp.com/npm/enterprises/ENTERPRISE を入れ、パスワード欄に個人用アクセストークンを入れてトークン認証を有効にし、社内のnpmリポジトリと合わせた仮想リポジトリを作る流れです。その際、公開のnpmレジストリから直接取ってくるリモートを仮想リポジトリから外すよう書かれています。外さないと、そこを通ってファイアウォールを迂回できてしまうためです。Artifactoryの管理者権限が必要で、対応は実験的とされています。
5. 止められた時の例外申請と審査
ファイアウォールが止めると、npmの出力やCI/CDのログに、例外を申請するURLが出ます。ドキュメントに載っている例は次のとおりです（公開からの待ち時間、version cooldownで止まった場合）。
npm notice testcontainers: 1 version blocked by package-firewall due to security policies (version cooldown). Request an override: https://github.com/enterprises/octocats/security/bypass-requests/package-firewall/new?ecosystem=npm&package=testcontainersURLを開くと申請の画面になり、リポジトリ、エコシステム（今はnpmだけ）、パッケージ名（スコープ付きなら@scopeから）、版、理由、補足のコメントを入れて送ります。審査するのは企業の管理者とセキュリティ管理者で、エンタープライズの Security and quality → Package firewall bypass から申請を開いて承認します。承認の画面で許可する版を * にすると全版を許可できますが、ドキュメントは申請された版より例外が広がると注意しています。承認された例外は方針に加わり、Policies → Package firewall のOverridesにある Package overrides で見直して外せます。
6. 方針を触れる人を広げる
既定で方針を変えられるのは、企業の管理者とセキュリティ管理者です。ほかの人に方針を見せたり変えさせたりする場合は、カスタムロールに「Edit enterprise-level package firewall policy」の権限を足して、チームか個人に割り当てます。
コーディングエージェントで使う時に気をつけること
ここからは、エージェントにnpmを触らせている開発チーム向けの注意点です。どれもGitHubとnpmの公式文書の記載から言えることに絞っています。
エージェントが動く場所ごとに、npmの向き先を確かめる
ファイアウォールは、端末の側でnpmの向き先を変えて初めて効きます（Changelogは、エージェントやCI/CDのホストに設定が必要と書いています）。npmの設定は、コマンドラインの指定、環境変数、プロジェクトの .npmrc、利用者の .npmrc、全体の設定ファイルの順に優先され、上位の設定で下位の設定を上書きできます（npm Docs「config」）。利用者の .npmrc をファイアウォールに向けていても、リポジトリ直下の .npmrc で registry を別のレジストリに書き換えたり、別のレジストリを指す --registry を付けて実行したりすると、その実行はファイアウォールを通りません。Claude CodeやCodexを開発者の端末で動かす場合も、CIでエージェントを動かす場合も、エージェントが実際に使う環境で npm config get registry を確かめておきます。
エージェントには、指示ファイル（AGENTS.mdやCLAUDE.mdなど）で向き先を変えないよう伝えておくと迷いが減ります。次は書き方の一例です。
# 構成例：エージェントへの指示ファイルに足す文（AGENTS.md / CLAUDE.md など）
## npm のパッケージ取得（GitHub package firewall を使用中）
- npm の registry 設定を変えない。npm に --registry を付けない。
- リポジトリ直下の .npmrc を作らない・書き換えない。
- 「blocked by package-firewall」と出たら、別の取得方法を試さずに作業を止め、
表示されたパッケージ名・版・申請用の URL をそのまま報告する。
- 新しい版が必要な時も、例外の申請は人が行う。GitHub ActionsでCodexを動かす時の権限の考え方は、Codex GitHub Action入門｜PR自動レビューで整理しています。
Copilotのクラウドエージェントの「ファイアウォール」とは役割が違う
名前が似ていて混同しやすいのが、Copilotのクラウドエージェント（とCopilotのコードレビュー）に最初から付いているファイアウォールです。こちらはCopilotがインターネットのどこへ接続できるかを絞る仕組みで、予期しない動作や悪意のある指示によって、コードや機密情報が外部に送られる危険を管理するためのものです。既定で有効な推奨の許可リストには、JavaScriptを含む主な言語のパッケージレジストリが入っています。また、このファイアウォールが効くのはエージェントがBashツールで起動したプロセスで、MCPサーバーのプロセスや、設定したCopilotの準備手順（setup steps）で起動したプロセスには直接は効きません（Customizing or disabling the firewall for GitHub Copilot）。
接続先を絞るのがCopilotのファイアウォール、取りに行くパッケージの版を方針で判定するのがpackage firewallです。組み合わせる場合、公開されている推奨の許可リストの一覧には、2026年10月21日時点で package-firewall.githubapp.com は載っていません（Copilot allowlist reference）。Copilotのファイアウォールで要求が止まると、プルリクエストの本文かコメントに、止まった宛先とコマンドが警告として出ます。出た時は、組織かリポジトリのカスタムの許可リストに足します。Copilotのクラウドエージェント全体の使い方は、GitHub Copilot Agent Modeの使い方｜全体像と料金にまとめています。
新しい版が入らない時に、エージェントに回り道をさせない
最小公開期間の既定は1日なので、公開から1日たっていない版はファイアウォールで止まります。コミュニティの議論では、待ち時間を7日にして試した利用者が、npm install で最新の版を入れようとした時に、latest のタグが止められた版を指したままで、ETARGET（該当する版が無い）のエラーで失敗したと報告し、条件を満たす版にタグを付け替えてほしいと要望しています（2026年10月20日の投稿。10月21日時点でGitHubからの返信は付いていません）。エージェントがこのエラーに当たった時に、レジストリを変えて取り直すような回り道をさせないことが大切です。前の項の指示のように止まったら報告させ、例外が必要かは人が判断します。
npm以外のパッケージは対象外
2026年10月21日時点で対応するのはnpmだけです。エージェントがPythonのパッケージなど別のエコシステムのものを入れる場合、そちらはこのファイアウォールの判定を受けません。
すでに悪いパッケージが入っていた時｜元に戻せるか
package firewallは入口の関門で、すでに端末に入っているものを掃除する機能ではありません。この節では、この機能の範囲で言えることだけを書きます。
ファイアウォールが判定するのは「通った取得」だけ
公式の説明は、ファイアウォールを通るパッケージ一覧の要求とダウンロードを検査するというもので、すでに端末やキャッシュにあるパッケージを調べる機能の記載はありません（2026年10月21日時点）。手元のキャッシュから入った分のように、ファイアウォールを通らなかった取得も判定の対象になりません。
入っていた時にやる4つ
- 版を特定する：ロックファイル（package-lock.json）に、マルウェアの勧告が出た版が入っていないかを確かめます。
- ファイアウォール経由で入れ直す：npmは既定で、ロックファイルに書かれたnpmjs.orgのURLを、設定したレジストリに置き換えて取りに行きます（設定 replace-registry-host の既定値 npmjs・npm Docs「config」）。Block known malwareがオンなら、勧告の出た版は取得の時点で止まり、npmの出力やCIのログに止まったことと申請のURLが出ます。キャッシュを使わない新しいランナーなどで入れ直すと確かめやすくなります。
- 資格情報を取り替える：その端末やランナーで、インストールの時に読めた資格情報を無効にして作り直します。GitHubは、インストール時にCI/CDのホストや開発者の端末から資格情報を集める攻撃が増えていると説明しています。このファイアウォールのために
.npmrcから読ませているトークンも対象に入れ、CIのシークレットを差し替えます。 - 例外の一覧を見直す：Package overridesで、全版を許可した例外（
*）や、もう要らない例外を外します。
元に戻せるもの、戻せないもの
戻せるのは依存関係の組み合わせです。ロックファイルをGitなどで管理していれば、問題の前の状態に戻してファイアウォール経由で入れ直せます。戻らないのはスクリプトが実行したことです。ドキュメントのとおり、インストール時のスクリプトは任意のコマンドを実行でき、資格情報を盗むのに使われうるので、ロックファイルを戻しただけで終わりにせず、資格情報の取り替えまで進めます。エージェントから外部に送れる先を絞る設定は、Copilot CLIのプロンプトインジェクション｜止め方【2026年10月】で扱っています。
【要注意】導入でつまずきやすい4つ
失敗1：利用者の.npmrcだけ直して終わる
❌ 利用者の .npmrc をファイアウォールに向けたので、すべての取得が通ると考える
⭕ リポジトリの .npmrc、環境変数、--registry の指定が上書きしていないかを、エージェントとCIの実際の環境で npm config get registry を使って確かめる
なぜ重要か：npmは、コマンドライン・環境変数・プロジェクト・利用者・全体の順に設定を優先するためです。
失敗2：トークンをリポジトリに書く
❌ .npmrc にトークンの値をそのまま書いてコミットする
⭕ ${GITHUB_TOKEN} の参照にして、値はCIのシークレットに置く。権限は公開リポジトリの読み取り専用に絞る
なぜ重要か：ドキュメントが、トークンを安全に保管し、リポジトリにコミットしないよう求めているためです。
失敗3：例外を全版で承認して放置する
❌ 申請が来るたびに許可する版を * にして承認し、そのまま残す
⭕ 申請された版に絞って承認し、Package overridesで定期的に見直す。全版の許可は、企業が持つパッケージのように中身を管理できるものに限る
なぜ重要か：* は申請された版より例外を広げる設定で、承認された例外は方針に加わり続けるためです。
失敗4：Copilotのファイアウォールがあるから足りると考える
❌ Copilotのクラウドエージェントのファイアウォールを有効にしているので、npmのパッケージも検査されていると考える
⭕ 接続先を絞る仕組みと、パッケージの版を方針で判定する仕組みは別物として、両方の設定を確かめる
なぜ重要か：Copilotの推奨の許可リストには、npmのレジストリが既定で入っているためです。
よくある質問
GitHub package firewallは無料で使えますか？
パブリックプレビューの間は無料です。一般提供の後はActionsの課金と同じような従量課金になると案内されていますが、単価と一般提供の時期は、2026年10月21日時点で公式に確認できていません。
GitHub TeamやFreeのプランでも使えますか？
公式に対象と書かれているのは、GitHub Enterprise Cloud（データ所在地付きを含む）です。それ以外のプランでの提供は、2026年10月21日時点で公式に確認できていません。
npmのmin-release-ageと何が違いますか？
npmの設定にあるmin-release-ageは、公開から指定した日数を超えた版だけで依存関係を組む、npm側の設定です。npmの設定はコマンドラインや環境変数、プロジェクトの設定で上書きできます。package firewallの最小公開期間は企業の方針として、ファイアウォールを通るすべての要求に適用されます。
Copilotのクラウドエージェントのファイアウォールとは何が違いますか？
Copilotのファイアウォールは、Copilotが接続できるインターネットの宛先を絞る仕組みです。package firewallは、npmで取りに行くパッケージの版を、マルウェアの勧告や公開からの日数などの方針で判定します。前者の推奨の許可リストにはnpmのレジストリが入っているので、パッケージの判定は後者で行います。
GitHub Packagesの社内パッケージと一緒に使えますか？
2026年10月20日のコミュニティの議論で、GitHubのメンテナーは、今は上流を設定できずnpmjs.orgから取得するため、GitHub Packagesとはどちらか一方になると答えています。一般提供に向けて設定を加える見込みとのことです。公開と社内のパッケージを1つの入口にまとめたい場合、ドキュメントにはArtifactoryを経由する方法がありますが、実験的な対応です。
npmのサプライチェーン攻撃の対策になりますか？
GitHubは、インストール時を狙って資格情報を集める攻撃への対策として、この機能を出しています。既知のマルウェアの勧告、新しく加わったインストールスクリプト、attestationの後退、公開直後の版を、取得の時点で止められます。一方で、勧告がまだ出ていないものは既知のマルウェアの制御では止まらず、すでに入っているものを調べる機能の記載もありません。最小公開期間で時間を取ることと、入られた後の手順を用意しておくことを組み合わせます。
まとめ
GitHub package firewallは、エージェント・Actionsのランナー・開発者の端末と公開レジストリの間に入り、npmの取得を企業の方針で検査して止める機能です。2026年10月20日にEnterprise Cloud向けのパブリックプレビューとして無料で始まり、今はnpmだけが対象です。効かせるには端末ごとの設定が必要で、npmの設定は上位の指定で上書きできるので、エージェントが実際に動く環境で向き先を確かめるところまでが導入です。
今日・今週・今月にやること
- 今日：自社がEnterprise Cloudか、方針を設定できる管理者が誰かを確かめ、エージェントとCIの環境で
npm config get registryを実行して今の向き先を見る - 今週：既定値（マルウェア・attestation・インストールスクリプトはオン、脆弱性はCritical only、最小公開期間は1日）のまま、1つのリポジトリのCIだけをファイアウォールに向けて試す
- 今月：例外の申請と審査の担当を決め、エージェントへの指示ファイルに「止まったら報告する」を足してから、対象のリポジトリを広げる
あわせて読みたい
- Copilot CLIのプロンプトインジェクション｜止め方【2026年10月】 — エージェントから外部への送信を止める公式設定
- AIエージェントを守るセキュリティツール4選比較2026 — エージェントの実行環境を守る製品の整理
- Codex GitHub Action入門｜PR自動レビュー — Actionsでエージェントを動かす時の権限設計
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー10万人超。
100社以上の企業向けAI研修・導入支援。著書シリーズ累計66,000部。
SBクリエイティブ「ビジネス＋IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。
ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- GitHub package firewall in public preview — GitHub Changelog、2026年10月20日（参照日: 2026-10-21）
- Protecting endpoints with GitHub package firewall — GitHub Docs（Enterprise Cloud・パブリックプレビュー、参照日: 2026-10-21）
- Protecting endpoints from malware with package firewall（#210809） — GitHub Community、2026年10月20日（参照日: 2026-10-21）
- Customizing or disabling the firewall for GitHub Copilot — GitHub Docs（参照日: 2026-10-21）
- Copilot allowlist reference — GitHub Docs（参照日: 2026-10-21）
- config — npm Docs（npm 12.2.0、参照日: 2026-10-21）
- .npmrc — npm Docs（npm 12.2.0、参照日: 2026-10-21）
- npm-config — npm Docs（npm 12.2.0、参照日: 2026-10-21）
