管理ツールによる一括セットアップ
管理ツールを使って組織内の開発者端末に一括でセットアップするために利用できる、配信用スクリプトを提供しています。ご利用の管理ツールに応じて、カスタマイズしてご利用ください。
この機能を利用するには、Guard を有効化した基本サブスクリプションが必要です。詳しくは料金と請求を参照してください。
概要
一括セットアップは、管理者が管理ツール(Jamf、Intune、Ansible など)を使って、組織内の開発者端末に Takumi Guard のレジストリプロキシ設定を一括で配信する仕組みです。開発者自身がコマンドを実行したり、設定ファイルを編集する必要はありません。
以下の図は、一括セットアップの全体構成を示しています。
管理者がコンソールで Bot と管理用 API キーを作成し、セットアップスクリプトとともに管理ツール経由で各端末に配信します。各端末ではスクリプトが自動的に Guard API にトークン発行をリクエストし、npm・pip・uv・Poetry・Bundler・Go modules の設定ファイルを更新します。以降、各端末からのパッケージインストールは Guard レジストリプロキシを経由するようになります。
セットアップスクリプトによって発行されたトークンは、コンソールの Guard > トークン で一覧・管理できます。

セットアップは大きく 2 つのフェーズに分かれます。
- 準備:Takumi / Shisho Cloud コンソールで Bot を作成し、セットアップスクリプトをダウンロードします
- 配信:管理ツール用のラッパースクリプトを作成し、セットアップスクリプトと合わせて対象端末に配信します
前提条件
配信の前に、Takumi / Shisho Cloud コンソールで以下の設定を完了してください。
-
Bot を作成する:設定 > Bot ページの「ボットの追加」ボタンから作成してください

-
ロールを付与する:Bot に「Takumi Guard トークン発行者」ロールを付与してください

-
API キーを取得する:作成した Bot の詳細ページで「API キーの作成」ボタンから静的 API キーを作成し、安全に保管してください

Bot の作成と API キーの発行手順の詳細はこちらも参照してください。
セットアップスクリプト
トークンの発行とパッケージマネージャーの設定を行うセットアップスクリプトを提供しています。お使いのプラットフォームに合わせてダウンロードしてください。
- macOS / Linux: https://shisho.dev/releases/takumi-guard-setup-0.10.3.sh
- Windows: https://shisho.dev/releases/takumi-guard-setup-0.10.3.ps1
対象端末には curl がインストールされている必要があります(macOS および Linux の場合)。
使い方
セットアップスクリプトは、実行したユーザーの設定ファイルのみを変更します。組織内の全ユーザーに一括展開する場合は、後述の配信例のラッパースクリプトを使用してください。
セットアップスクリプトを以下のように実行してください。API キーは環境変数 TG_BOT_API_KEY で渡してください。
TG_BOT_API_KEY="shisho_apikey_..." ./setup.sh <BOT_ID> <USER_IDENTIFIER>
各パラメータの意味は以下の通りです。
| パラメータ | 説明 |
|---|---|
TG_BOT_API_KEY | (環境変数)Bot の API キー |
BOT_ID | Takumi / Shisho Cloud コンソールの Bot ID |
USER_IDENTIFIER | デバイスやユーザーを識別するユニークな値 |
TG_DIRECT_WRITE | (任意の環境変数)パッケージマネージャーの事前検証をせず、設定ファイルへ直接書き込みます。詳しくはこちらを参照してください |
対象を限定したい場合は、第 3 引数でスコープを指定してください。
TG_BOT_API_KEY="..." ./setup.sh BOT_ID USER_IDENTIFIER npm,rubygems
| スコープ | 設定されるパッケージマネージャー |
|---|---|
npm | npm, pnpm, yarn(v2+), bun |
pypi | pip, uv, poetry |
rubygems | Bundler |
golang | Go modules |
packagist | Composer |
Poetry は、スクリプトによるユーザー単位の設定だけでは保護が有効になりません。別途、リポジトリごとの設定が必要です。詳しくは、Python パッケージマネージャー Poetry を利用する場合を参照してください。
参考:USER_IDENTIFIER の決め方
USER_IDENTIFIER は、デバイスやユーザーを識別する文字列です。組織内で一貫した命名規則を決めておくことを推奨します。
文字種の制約は以下の通りです。
- 使用可能な文字:
a-z,A-Z,0-9,-,_,.,@,+ - 文字数: 4〜255 文字
以下の例を参考に、組織に合った識別子を選んでください。
| 例 | 値 | 説 明 |
|---|---|---|
| デバイスのシリアルナンバー + OS ユーザー名 | C02X1234_jdoe | デバイス BIOS のハードウェアシリアルナンバーを使用 |
| 資産管理 ID + 社員 ID | ASSET0042_EMP12345 | 組織で管理している ID を使用 |
| MDM のデバイス ID + OS ユーザー名 | a401c7d0_jdoe | MDM ツールが割り当てるデバイス ID を使用 |
選択した識別子が組織内でユニークであることを確認してください。一部の識別子(シリアルナンバーなど)は、自作 PC や仮想マシンなどの環境では空になったり、デバイス間でユニークでない場合があります。各デバイスとユーザーを確実に区別できる値を使用してください。
参考:詳細な挙動
初回実行時
セットアップスクリプトがトークンを発行し、既存の設定ファイルのタイムスタンプ付きバックアップ(例:~/.npmrc-backup-20260408-162351)を作成してから、Guard の設定を追記します。既存の Guard 以外の設定は変更されません。
トークンが上書きされるケース
セットアップスクリプトは、Guard が管理対象とするすべての設定ファイルを確認し、既存のトークンを検出した場合はそのトークンを検証します。また、設定ファイルごとに異なる複数のトークンが存在する場合は、それらすべてのトークンを検証します。
検出されたすべてのトークンが、以下のいずれかの条件に該当する場合、新しい組織ユーザートークンを発行し、既存のトークンをその新しいトークンで上書きします。一方で、有効かつ指定された組織に紐づく組織ユーザートークンが 1 つでも存在する場合は、そのトークンを再利用します。
- メール認証トークンである場合
- 存在しないトークンである場合
- 無効化(失効)されたトークンである場合
- 別の組織で発行されたトークンである場合
上書き前には、各設定ファイルのタイムスタンプ付きバックアップが作成されます。
再実行時
有効な組織ユーザートークンを検出して再利用するため、上記のケースを除き、新しいトークンは発行されません。また、既に Guard が設定済みのツールはスキップされます(変更もバックアップも行 われません)。スコープの増分追加にも対応しています。たとえば、先に npm スコープで実行し、後から pypi スコープを追加できます。
パッケージマネージャーの事前検証
セットアップスクリプトは、Guard の設定を行う前に、対象となるすべてのパッケージマネージャーを一つずつ確認します。以下のいずれかに該当する場合、そのパッケージマネージャーに対して Guard の設定を行います。
- パッケージマネージャーの設定ファイルが存在する
- パッケージマネージャーの CLI が利用可能
また、設定対象となるパッケージマネージャーが一つでも見つかった場合にのみ、必要に応じて組織ユーザートークンを発行します。一方で、設定対象が一つも見つからない場合は、トークンの発行や設定の変更を行わずにセットアップを終了します。
これにより、Guard の保護対象となるパッケージマネージャーを利用していない端末に対するトークン発行を防ぎ、不要な課金の発生を抑制します。
事前検証を行わずに Guard を設定する方法も用意しています。詳しくは「事前検証をせずに設定する」を参照してください。
手動ロールバック
セットアップスクリプトは、設定ファイルを変更する前にタイムスタンプ付きの永続バックアップを作成します(例:~/.npmrc-backup-20260408-162351)。Guard の設定を元に戻したい場合は、このバックアップファイルを元のファイル名にコピーしてください(例:cp ~/.npmrc-backup-20260408-162351 ~/.npmrc)。
端末の入れ替えや従業員の退職などで不要になったトークンは、Takumi / Shisho Cloud コンソールから失効させてください。詳しくは組織ユーザートークンの失効を参照してください。
パッケージマネージャーに別のレジストリ(プライベート npm レジストリなど)が既に設定されている場合、セットアップスクリプトは既存のレジストリ設定を Guard のレジストリで上書きします。上書き前にタイムスタンプ付きのバックアップファイルが作成されますが、念のため、配信前に対象端末で使用中のレジストリ設定を確認してください。
配信例
セットアップスクリプトの配信方法は、利用する管理ツールや OS によって異なります。ここでは、代表的な OS やトークン発行方針に応じた配信例を紹介します。なお、以下のラッパースクリプトはあくまでサンプルです。利用する環境や運用に合わせて適宜修正してください。
- 端末あたり1トークン発行: 端末ごとにトークンを発行します。端末上のいずれかのアカウントに有効なトークンが存在しないかを確認したうえで、存在する場合は再利用し、存在しない場合だけ新しくトークンを 1 つ発行したうえで、端末上の各開発者アカウントに対して同じトークンで設定します。
- 端末のユーザー毎に個別トークン発行: (端末, ユー ザー)の組ごとにトークンを発行します。1 台の端末に複数の開発者アカウントが存在する環境(共用ワークステーション、MDM が作成する管理者アカウントと利用者アカウントが併存する端末、IdP が発行するアカウントとビルトインローカルアカウントが併存する端末など)では、同じ端末でアカウント数分のライセンスを消費することになります。
いずれのラッパースクリプトも、有効なトークンを検出した場合は再利用するため、定期実行はどちらのモデルでも安全です。
実際の環境では、管理用のサービスアカウントや、Takumi Guard の設定対象としたくないユーザーを除外したい場合があります。そのような場合は、ラッパースクリプト側で対象ユーザーを絞り込むことで対応できます。
macOS / Linux の例:
# 特定のユーザー名をスキップ
case "$USER_NAME" in
corp-admin|service-account|Guest) continue ;;
esac
Windows の例:
# 特定のユーザー名をスキップ
$Skip = @('corp-admin', 'Guest', 'defaultuser0')
if ($Skip -contains $UserName) { continue }
同様の方法で、対象ディレクトリや所属グループによる絞り込みも実装できます。たとえば、macOS / Linux では /Users/dev-* や /home/dev-* 配下のユーザーのみを対象にしたり、id -Gn "$USER_NAME" | grep -q developers を利用して特定のグループに所属するユーザーのみを対象にしたりできます。Windows でも、Get-CimInstance Win32_GroupUser などを利用して同様の制御が可能です。
macOS
管理ツールによるスクリプト実行は通常 root 権限で行われるため、以下のラッパースクリプトがユーザーごとに切り替えながら、各開発者の環境へセットアップを行います。配信方法については、Jamf Pro のスクリプト実行機能