独自開発した CLI ツールを、特定の顧客企業の中だけで使ってもらいたい。公開 npm には出せないが、社内の開発者にも一般ユーザー端末にも、できるだけ摩擦なく届けたい。対象は macOS・Windows で、将来は Linux も視野に入れる。これは、エンタープライズ領域でプラットフォームエンジニアリングを担うと必ず突き当たる課題です。

一見すると「ソースコードをパッケージングして渡すだけ」に見えますが、実務はそう単純ではありません。各 OS は未署名の実行ファイルを厳格にブロックします（Apple Gatekeeper、Windows Defender SmartScreen）。改ざんを検知できる署名プロトコルを通し、そのうえで顧客単位でアクセスを制御・監査できる配布網を用意する必要があります。つまり、ビルド・署名・配布の三層を一本のパイプラインとして設計しないと、どこかで必ず運用が破綻します。

この記事では、独自開発の npm 製 CLI ツールを特定顧客にセキュアに配るためのパイプラインを、ビルド方式の選定から、macOS / Windows の署名自動化、プライベートな配布チャネル、サプライチェーンの堅牢化まで通して設計します。あわせて、Azure Trusted Signing の地理制約や ISMS・APPI など、日本のエンタープライズ特有の論点も整理します。なお、ツールの仕様や提供地域・価格は変動が激しいため、本記事は 2026 年 5 月時点の調査に基づく整理であり、採用前には各公式ドキュメントで確認日基準の再確認をおすすめします。

全体像 — ビルド・署名・配布の三層

設計を始める前に、解くべき問題を三層に分けて見通しておきます。

• ビルド: CLI を「Node.js ランタイム前提の npm パッケージ」のまま配るか、ランタイムごと固めた「単一実行バイナリ」にするか。起動速度・配布サイズ・署名との相性が、この選択でほぼ決まります。
• 署名: macOS は Developer ID 署名と公証（Notarization）、Windows は Authenticode 署名が事実上の必須要件です。署名なしでは OS のセキュリティゲートを越えられず、ユーザーに不快な警告が出ます。
• 配布: プライベート npm レジストリ、Homebrew Tap、MDM、エンタイトルメント配信のどれを主経路にするか。顧客の環境（Node.js があるか、MDM を運用しているか、閉域か）で最適解が変わります。

重要なのは、これらが独立した選択肢ではなく、相互に依存している点です。たとえば「単一バイナリ化」を選ぶと macOS では .pkg でラップしないと公証チケットをステープルできず、その .pkg を配るなら MDM や Cloudsmith が候補になる、という具合に連鎖します。以降、層ごとに掘り下げていきます。

flowchart TD
    A[Git リポジトリ] --> B[CI ビルド]
    B --> C[npm ci / test / audit]
    C --> D[bundle / compile]
    D --> E[SBOM / SHA256 / provenance]
    E --> F1[Private npm package]
    E --> F2[Windows EXE / MSI]
    E --> F3[macOS PKG]

    F2 --> G1[signtool / Azure Trusted Signing]
    F3 --> G2[codesign + notarytool + stapler]

    G1 --> H1[Intune Win32]
    G2 --> H2[Intune / Jamf macOS]
    F1 --> H3[Private npm registry]
    G1 --> I[Cloudsmith / Amazon S3 例外経路]
    G2 --> I

    H1 --> J[管理対象 Windows 端末]
    H2 --> K[管理対象 macOS 端末]
    H3 --> L[開発者 / IT 管理者]
    I --> M[顧客側の例外配布]

ビルド方式の選定 — 単一バイナリか ncc か

最初の分岐は、Node.js ランタイムを顧客環境に前提できるかどうかです。

顧客に Node.js があり（または配布できる）、対象が主に開発者なら、@customer-scope/cli のようなスコープパッケージとしてプライベートレジストリ経由で配るのが最もシンプルです。配布物は数 MB と小さく、npm update -g で更新でき、後述する provenance や SBOM との相性も良好です。半面、Node.js のバージョン不整合や、node-gyp を使うネイティブアドオンのビルド問題を背負います。

一般ユーザー端末や、ランタイム非依存を求める厳格な管理端末を含むなら、単一実行バイナリ化が選択肢に入ります。2026 年時点の主な手段は次の四つです。

Bun は Apple の JavaScriptCore を基盤に Zig で実装されており、コールドスタートが速いのが最大の魅力です。bun build --compile は追加依存なしに全 OS 向けのクロスコンパイルもこなします。実 CLI での縮小効果も大きく、約 14 万 weekly download の rulesync では、Deno compile から Bun へ移行して darwin-arm64 のバイナリが 565 MB から 62.8 MB へ、おおよそ 9 分の 1 に縮んだと報告されています（ただしこの差の大半は tree-shaking と minify の効果で、事前バンドルすれば Deno との差は縮まります）。なお x64 向けには 2013 年以降の AVX2 命令を前提とした SIMD 最適化が既定で入るため、古い CPU をサポートするなら bun-windows-x64-baseline などのベースラインビルドを選び、Illegal instruction エラーを避ける必要があります。

注意したいのは、Bun のコード署名まわりで 2026 年に回帰（特定バージョンで macOS arm64 が SIGKILL される事象）が報告されている点です。署名の安定性と公式サポートを最優先するなら、Node.js SEA か Deno compile が優位です。Node.js SEA は useCodeCache と useSnapshot を false にしないとクロスプラットフォーム生成でクラッシュする制約があり、現状 CommonJS 中心ですが、コアへのビルド統合が進んでいます。既存の pkg ワークフローからの移行で単一バイナリを作りたい場合は、後継の @yao-pkg/pkg を使います。

旧来定番だった vercel/pkg は新規採用すべきではありません。2024 年 1 月にリポジトリがアーカイブされ（最終 5.8.1）、/tmp/pkg/* 経由のローカル権限昇格を許す CVE-2024-24828 が未修正のまま残っています。

判断を一言でまとめると、起動速度とサイズなら Bun、署名の安定性と公式サポートなら Node SEA か Deno、Node ランタイムを前提できて保守性を取るなら ncc + 同梱ランタイム、という整理になります。どの方式でも、ロックファイル（package-lock.json または bun.lock）をピン留めし、CI では npm ci や bun install --frozen-lockfile を徹底して、決定論的ビルドを担保することが前提です。

macOS — 署名・公証・ステープルと「YARA スキャンの嵐」

macOS では、署名・公証されていないバイナリを社内の開発者が実行しようとすると Gatekeeper にブロックされます。Apple Silicon（arm64）では未署名バイナリはカーネルに SIGKILL されるため、最低限の ad-hoc 署名すら必要です。

さらに見落とされがちなのが、macOS Sequoia (15) 以降で報告されている「YARA スキャンの嵐」です。署名・公証済みのバイナリは secassessment レイヤーが信頼をローカルキャッシュするため、二回目以降の起動が瞬時に終わります。ところが未公証の巨大バイナリ（Bun ベースの CLI が約 190 MB に達した例が報告されています）は、起動のたびにキャッシュが無効化され、ディスク上の全体に対するフル YARA スキャンが強制されます。CLI をエージェントループや CI ランナーから高速に呼び続けると、syspolicyd の CPU 使用率が持続的に 150〜200% に達し、trustd や WindowServer まで巻き込んで端末全体が発熱・低速化します。これは Apple の公証スタンプを埋め込まない限り根本的に解消しません。CLI バイナリこそ公証が要る、という強い動機です。

GitHub Actions の macOS ランナー上で、署名から公証・ステープルまでを非インタラクティブに完結させる流れは次のとおりです。

1. 一時キーチェーンの構築: GitHub Secrets に Base64 で格納した Developer ID Application（バイナリ署名用）と Developer ID Installer（インストーラー署名用）の 2 つの .p12 をデコードしてインポートします。security create-keychain で隔離キーチェーンを作り、security set-keychain-settings -t 7200 で自動ロックによるハングを防ぎ、security set-key-partition-list でパスフレーズ入力ダイアログを抑制します。
2. Hardened Runtime での署名: コンパイル済みバイナリ（Mach-O）に対し、codesign --force --options=runtime --timestamp --entitlements entitlements.plist --sign "Developer ID Application: ..." で署名します。--options=runtime（Hardened Runtime）の付与が公証の前提です。Bun や Node (V8) は実行時に JIT メモリを要求するため、entitlements に com.apple.security.cs.allow-jit などを定義しておく必要があります。
3. インストーラーへのラップ: コマンドラインの単一バイナリには公証チケットをステープルできません。そこで pkgbuild でコンポーネントパッケージを作り、productbuild で配布用 .pkg にまとめ、productsign --sign "Developer ID Installer: ..." でインストーラー署名を付けます。
4. 公証とステープル: xcrun notarytool submit ... --wait で Apple の公証サービスへ送り、検証完了まで CI を同期ブロックします（altool は廃止済みで notarytool が現行）。承認されたら xcrun stapler staple でチケットをパッケージ本体に永続的に埋め込みます。これで、インターネットから隔離された社内環境でも Gatekeeper がローカル検証を通し、警告なしでインストールできます。

Apple Developer Program（年 99 ドル）の Developer ID 証明書が前提です。

Windows — Authenticode 署名と Azure Trusted Signing の地理制約

Windows での最大の障壁は、実行時に出る SmartScreen 警告（「WindowsによってPCが保護されました」）です。回避には Authenticode 署名が事実上の前提になります。

ここで近年大きく状況が変わりました。まず証明書の格。2024 年 8 月に Microsoft が Trusted Root Program から EV コード署名の OID を削除し、SmartScreen は EV と OV を同等に扱うようになりました。どちらも即時の信頼バイパスは得られず、ダウンロード実績でレピュテーションを蓄積する方式です。つまり、通常のソフト配布で EV を選ぶ実益はほぼ消えました（カーネルモードドライバ署名には依然 EV が必要）。次に秘密鍵の保管。2023 年 6 月以降、CA/Browser Forum の規約改定で、公的に信頼されるコード署名証明書の秘密鍵は FIPS 140-2 Level 2 以上（または Common Criteria EAL4+）相当の HSM またはハードウェアトークン内での生成・保管が義務化されました。物理 USB トークンは CI/CD のクラウドランナーから直接アクセスできないため、自動化と相性が悪くなりました。

そこで台頭したのが Azure Trusted Signing（旧称 Azure Code Signing、2026 年に Artifact Signing へ改称）です。署名のたびに Microsoft の信頼ルートから有効期限の極めて短い使い捨て証明書（24〜72 時間有効）を動的に発行する方式で、ユーザーは秘密鍵も証明書期限も管理しません。GitHub Actions とは OIDC キーレス認証で連携でき、signtool に /dlib で連携 DLL を読ませると、実行バイナリ全体ではなくローカル計算したハッシュ（digest）だけを Azure に送る、高速で安全な署名が成立します。Microsoft 自身の署名チェーンを使うため、SmartScreen のレピュテーション蓄積も速いとされています。

ただし日本の組織には重大な制約があります。Azure Trusted Signing の GA 提供地域は、執筆時点で「米国・カナダの組織または個人、および EU・英国の組織」に限定されており、日本企業・個人開発者は現状そのままでは利用が困難です。したがって日本では、OV 証明書（DigiCert・Sectigo・GlobalSign 等）の秘密鍵を Azure Key Vault の HSM に格納し、AzureSignTool や signtool で CI から署名するのが現実解になります。あるいは Google Cloud KMS の HSM に Sectigo 等の証明書を載せて CNG プロバイダー経由で署名する構成も取れます。

調達計画でもう一点織り込むべきは証明書の有効期間短縮です。CA/Browser Forum の Ballot CSC-31 により、2026 年 3 月 1 日以降、公的に信頼されるコード署名証明書の最大有効期間が 39 か月から 460 日（約 15 か月）に短縮されます。複数年の前払い割引は消えるため、更新サイクルを前提にした運用へ切り替える必要があります。

signtool sign /fd SHA256 /tr http://timestamp.acs.microsoft.com /td SHA256 /f cert.pfx tool.exe
signtool verify /pa /v tool.exe

/fd SHA256 と RFC 3161 タイムスタンプ（/tr と /td）の付与は必須です。タイムスタンプがあれば、証明書の有効期限が切れた後も署名の検証可能性が維持されます。

配布チャネル — レジストリ・Homebrew・MDM・エンタイトルメント

署名済みの成果物を、顧客企業へどう届けるか。導入の摩擦とアクセス制御のバランスで、複数チャネルを使い分けるのが現実的です。

プライベート npm レジストリ

顧客に Node.js 開発スタックがあるなら最も親和性が高い経路です。ツールは独自スコープ（@customer-scope/cli）で初期化し、.npmignore を厳密に制御して内部 API キーや環境変数ファイルがパッケージに混入しないようサニタイズします。顧客側は .npmrc にレジストリのエンドポイントと認証トークンをバインドすれば、通常の npm ツールチェーンに透過的に統合できます。

レジストリの候補は性格がかなり違います。AWS CodeArtifact は IAM 資産に寄せられますが、認証トークンの標準有効期間が 12 時間と短く、自動化前提です（東京 ap-northeast-1 を選べます）。Azure Artifacts は feed / view / pipeline identity の権限設計が細かく、Azure DevOps と Entra ID を使う組織と相性が良好です。GitHub Packages は GitHub Actions と密結合する一方、認証が PAT classic 依存などの制約を受けます。閉域や顧客ごとのブランド配信を重視するなら Cloudsmith も候補です。

公開・配置を管理するアカウントには、フィッシング耐性のあるパスキー（YubiKey、Windows Hello、Touch ID）での MFA を強制し、CI の自動化アカウントにはレガシートークンではなくリソースを絞った細粒度アクセストークン（Granular Access Token）を割り当てます。

Homebrew プライベート Tap

macOS 開発者が多い顧客では、自動更新性を最大化できる経路です。顧客 Organization 内にプライベートリポジトリ（homebrew-tap）を作り、GitHub Releases に署名済みバイナリの .tar.gz を置きます。非公開リポジトリの取得は通常の cURL では 404 になるため、Tap に GitHubPrivateRepositoryReleaseDownloadStrategy を定義した独自ダウンロード戦略を追加し、Formula で接続プロトコルを上書きします。各ユーザーには読み取り専用の PAT を発行し、シェル設定で HOMEBREW_GITHUB_API_TOKEN を宣言してもらえば、brew install / brew upgrade だけで導入と更新が回ります。mislav/bump-homebrew-formula-action をパイプラインにフックすれば、リリース時の Formula 更新（SHA256 再計算とコミット）も自動化できます。

MDM（Intune / Jamf）

顧客が管理端末を MDM で統制している場合、これが配布の本命になります。署名・公証はどのチャネルでも必須要件になる点は変わりません。

Microsoft Intune では、Windows は IntuneWinAppUtil.exe で .intunewin 形式に変換した Win32 アプリとして登録し、サイレントインストール（例: msiexec /i app.msi /qn）と検出ルールを整えます。割り当ては Required / Available / Uninstall を選べます。macOS は「macOS app (PKG)」または「Line-of-business app（managed PKG）」として配布しますが、managed LOB PKG には Developer ID Installer 署名が必須です。これはランタイムバイナリに付ける Developer ID Application とは別の証明書で、ここを取り違えてデプロイに失敗する事例が多いので注意します。

Jamf Pro では、Developer ID Installer 署名済みのフラット .pkg をポリシーまたは Self Service で配布します。外部リソースに依存せず全コンテンツを含めること、pre / postinstall スクリプトは sh / bash / zsh で最小限にすることが推奨されます。

エンタイトルメント配信と例外経路

顧客ごとに分離したアクセス制御を、アカウント管理なしで実現したいなら、Cloudsmith のプライベートブロードキャストでブランド化ポータルを用意し、顧客単位のエンタイトルメントトークンで閲覧・取得を制御する方法があります。契約終了や漏洩時にはトークンを即時失効でき、ダウンロード活動も顧客単位で監査できます。

顧客ネットワークが Intune 非対応だったり境界で隔離されていたりする場合の例外経路として、Amazon S3 / CloudFront の署名付き URL（期限・IP を絞れる）や共有ファイルサーバも使えます。Amazon S3 を使う場合は CloudTrail と server access log で監査証跡を残します。Object Lock を有効にしたバケットは server access log の宛先にできないため、成果物バケットとログバケットは分けます。

将来の Linux — GPG 署名リポジトリ

将来 Linux を加えるなら、未署名バイナリの素置きではなく、OS 標準パッケージマネージャーの監査基準を満たすリポジトリを構築します。RPM は CI 上で rpmsign を使い、社内 GPG 秘密鍵でヘッダーとペイロードに署名します。顧客側の .repo に gpgcheck=1 と repo_gpgcheck=1 を指定すれば、DNF / YUM が公開鍵を取得してパッケージの整合性を検証します。Debian 系は _gpgorigin 署名を debsig-verify で照合させます。これでサプライチェーン上の改ざんを締め出せます。

オフライン・エアギャップ環境では、Verdaccio をキャッシュとして使い必要パッケージを持ち込む方法もありますが、ランタイムも依存も 1 ファイルに含む単一バイナリ + 署名済み .pkg / .intunewin が最も運用しやすい、というのが結論です。

配布チャネルを表にまとめると次のようになります。

サプライチェーンの堅牢化

npm エコシステムは依存が多層に重なるため、悪意あるパッケージ混入（Package Poisoning）や依存関係錯乱（Dependency Confusion）の標的になりやすく、ビルド・配布段階の防御が最優先事項になります。2025 年の Shai-Hulud ワームをはじめ、現実の攻撃が続いている領域です。

• 脆弱性スキャン（SCA）: CI の冒頭で npm audit を強制実行し、Critical / High を検出したら非ゼロで異常終了させます。Snyk、Trivy、Grype なども組み合わせ、Dependabot / Renovate で依存を継続更新します。Renovate のクールダウン機能で、新バージョンを一定期間寝かせてから採用すれば、公開直後の汚染パッケージを踏むリスクを減らせます。
• 決定論的ビルド: ロックファイルをコミットし、CI では npm ci（または bun install --frozen-lockfile）で凍結インストールします。package-lock.json と package.json が不一致なら npm ci は失敗します。CLI のような配布アプリでは、publish される依存ツリーを固定する npm-shrinkwrap.json の活用余地もあります。
• ビルド来歴（provenance）: npm provenance（Sigstore + SLSA）を使い、npm publish --provenance でソースリポジトリ URI・コミットハッシュ・ビルド手順を含む検証可能な来歴を生成します。GitHub Actions では actions/attest-build-provenance で SLSA provenance を OIDC トークンに紐付けて残せます。ただし、2026 年には有効な provenance を持つ悪意あるパッケージの事例もあり、provenance だけでは不十分で、ビルド環境の隔離（SLSA Build L3）まで進めるのが望ましいです。
• SBOM: セキュリティ用途の CycloneDX とライセンス / コンプライアンス用途の SPDX が二大標準です。Syft が多言語・両形式に対応した定番で、syft dir:. -o cyclonedx-json -o spdx-json のように両形式を一度に出力できます。CRA 自体は特定のフォーマットやバージョンを義務付けてはおらず、ドイツの BSI TR-03183 などの補助ガイダンスが CycloneDX 1.6 以降または SPDX 3.0.1 以降を事実上の目安として示しています。

CLI ツール自体のコンプライアンスも単体テストで担保します。-h / --help と -v / --version を全サブコマンドに実装し、終了コードは成功時 0 / 異常時に非ゼロを返し、出力先が TTY か判定したうえで NO_COLOR / FORCE_COLOR を尊重し、SIGINT / SIGTERM を捕捉して一時ファイルをクリーンアップする、といった作法です。これらは顧客の自動化スクリプトや CI を壊さないための必須要件です。

日本のエンタープライズ特有の論点

ここまでの設計に、日本の顧客企業ならではの制約を重ねます。

第一に、すでに述べた Azure Trusted Signing の地理制約です。Windows 署名で第一候補にしたいサービスが、日本組織では現状そのまま使えません。当面は OV 証明書 + Azure Key Vault が現実解で、将来 Trusted Signing が日本で GA されたら移行を検討する、という前提でロードマップを引きます。

第二に、ISMS（ISO/IEC 27001:2022）と APPI（個人情報保護法）です。ISMS 監査では操作ログ・USB 利用ログ・Web アクセス履歴の自動収集が求められ、配布する CLI も資産管理の対象になりえます。CLI が個人情報を扱うなら、データの保存場所と越境移転に配慮し、CodeArtifact なら東京リージョンを選びます。

第三に、国産 MDM の存在です。顧客が CLOMO・LANSCOPE・SKYSEA・BizMobile Go! などを使っている場合、Intune / Jamf 前提のフローとは異なる配布手順（独自の配布サイトや .pkg / .msi のプッシュ）が必要になりえます。いずれにせよ顧客 IT 部門は、サイレントインストール対応、署名・公証済みであること、社内プロキシや変更管理プロセス（CAB 承認）への適合を求める傾向が強く、ここを満たせるかが導入可否を分けます。

まとめ

最後に、私が推奨する標準構成（ベストプラクティス）を一つの形に示します。迷ったらここを出発点にしてください。

• 配布は二層に分ける
  • 開発者・IT 管理者: プライベート npm レジストリ（スコープ配布）
  • 一般ユーザー・管理端末: 署名済みインストーラを MDM（Intune / Jamf）で配る
  • 運用性・監査性・更新制御のバランスが最も良い構成
• ビルドは要件で選ぶ
  • 開発者向け: ncc でバンドルし、ランタイムは LTS を別管理する
  • 完全なランタイム非依存が要るときだけ単一バイナリ化する
  • 単一バイナリは署名安定性を優先して Node SEA か Deno、速度とサイズを最優先で安定版をピンできるなら Bun
• 署名は必須要件として CI に組み込む
  • macOS: Developer ID 署名 + Hardened Runtime + 公証 + ステープル（CLI は .pkg にラップ）
  • Windows: OV 証明書を Azure Key Vault に格納して signtool で署名（日本組織の場合。Trusted Signing は GA 地域外のため）
• サプライチェーンは初日から基準線を引く
  • npm ci とロックファイル固定、npm audit、provenance、SBOM を CI に組み込む
  • 余裕が出たら SLSA Build L3 まで引き上げる
• 全体を 1 本の CI パイプラインに集約する
  • 同一コミットから各チャネルの成果物を生成する

技術的な要点も改めて整理します。

• 独自開発 CLI の社内配布は、ビルド・署名・配布の三層を一本のパイプラインとして設計する問題で、各層は相互に依存している。
• ビルド方式は、起動速度とサイズなら Bun、署名安定性と公式サポートなら Node SEA か Deno、Node ランタイムを前提できて保守性を取るなら ncc + 同梱ランタイム。vercel/pkg は CVE 未修正のため新規採用不可。
• macOS は Developer ID 署名 + Hardened Runtime + 公証 + ステープルが必須。単一バイナリは .pkg にラップしてステープルする。未公証バイナリは Sequoia 以降の「YARA スキャンの嵐」で端末を巻き込むため、公証は避けて通れない。
• Windows は Authenticode 署名が前提。Azure Trusted Signing が本命だが GA 地域が限定され、日本組織は当面 OV 証明書 + Azure Key Vault が現実解。証明書有効期間は 2026 年 3 月以降 460 日上限に短縮される。
• 配布は単一チャネルに寄せず、開発者にはプライベートレジストリ、管理端末には MDM、例外には Cloudsmith / Amazon S3、将来の Linux には GPG 署名リポジトリ、と用途別に二層化する。
• サプライチェーンは provenance・SBOM・npm audit・決定論的ビルドを基準線にし、SLSA Build L3 まで段階的に引き上げる。
• 日本固有の論点として、Trusted Signing の地理制約、ISMS / APPI、国産 MDM、顧客 IT 部門の制約を最初から織り込む。

最後に改めて強調すると、この領域はツールの仕様や提供地域・価格の変動が激しく、特に署名サービスの対応地域や証明書ポリシーは短期間で書き換わります。本記事は 2026 年 5 月時点の見取り図として、採用前には必ず確認日基準で一次情報を当たってください。

以上、独自開発の npm 製 CLI ツールを特定顧客にセキュアに配るためのビルド・署名・配布パイプラインを設計した、現場からお送りしました。

参考情報

• Node.js Single Executable Applications
• Bun: Single-file executable
• Deno compile
• Azure Trusted Signing ドキュメント
• Microsoft Intune ドキュメント
• npm provenance statements
• SLSA / Sigstore / Syft