概要​

「管理ツールによる一括セットアップ」では、各エコシステムの設定を、パッケージマネージャーの CLI（npm config set、poetry config、go env -w など）を実行して行います。しかし、管理ツールによるセットアップスクリプトの実行方法によっては、これらの CLI を呼び出せない場合があります。たとえば、SYSTEM 権限での実行や環境変数が制限された環境では、CLI の場所を解決するための PATH が引き継がれないことがあります。

今回追加した直接編集モードでは、CLI を実行する代わりに、設定ファイル（~/.npmrc など）を直接編集して設定を反映します。これにより、CLI が PATH 上に存在するかどうかに依存せず、Guard の設定を適用できます。

設定の検出方法や書き込み対象となるファイルは通常のモードと変わらず、変更されるのは設定の反映方法のみです。Guard の設定は既存の設定に追加・更新され、Guard 以外の設定は保持されます。バックアップおよびロールバックの動作も通常どおり行われます。

利用方法​

新しいセットアップスクリプト v0.7.0 は以下から取得できます。

• macOS / Linux: https://shisho.dev/releases/takumi-guard-setup-0.7.0.sh
• Windows: https://shisho.dev/releases/takumi-guard-setup-0.7.0.ps1

直接編集モードを有効にするには、スクリプト実行時に TG_DIRECT_WRITE 環境変数を設定してください。組織ユーザートークンの発行と Guard の設定をまとめて行う場合でも、発行済みの組織ユーザートークンを使用する install サブコマンドを利用する場合でも指定できます。

# 組織ユーザートークンの発行と Guard の設定をまとめて行う場合
TG_DIRECT_WRITE=true TG_BOT_API_KEY="..." ./setup.sh <BOT_ID> <USER_IDENTIFIER>

# 発行済みの組織ユーザートークンを使用して Guard の設定のみを行う場合
TG_DIRECT_WRITE=true ./setup.sh install <TOKEN>

TG_DIRECT_WRITE を設定しない場合は、これまでどおり CLI を利用して設定を行います。詳しくは、管理ツールによる一括セットアップガイドの設定ファイルを直接編集するモードを参照してください。

組織向け機能を利用する​

Takumi Guard の組織向け機能（一括セットアップ、インストールログの検索など）を利用するには、Takumi サブスクリプションの契約と Guard の有効化が必要です。

1. https://cloud.shisho.dev/hello/takumi にアクセスし、サインインしてください
2. 組織を登録し、Takumi サブスクリプションを契約してください
3. 画面左のサイドバーから Guard > 設定 にアクセスしてください
4. 「有効化する」ボタンをクリックして Guard を有効化してください

有効化が完了したら、管理ツールによる一括セットアップガイドに従ってセットアップを進めてください。

概要​

「管理ツールによる一括セットアップ」は、Jamf、Intune、Ansible などの管理ツールを通じてセットアップスクリプトを配布し、開発者による個別操作なしに、各端末へ対応するパッケージマネージャーの設定を書き込む仕組みです。

これまで対応していたエコシステムは npm・PyPI・RubyGems の 3 種類でしたが、今回のリリースより Go モジュールが 4 つ目の対応エコシステムとして追加されます。

Go モジュール向けの Guard 設定についても、他のエコシステムと同様の手順で、管理ツールを通じて各端末へ一括展開できます。

利用方法​

新しいセットアップスクリプト v0.6.0 は以下から取得できます。

• macOS / Linux: https://shisho.dev/releases/takumi-guard-setup-0.6.0.sh
• Windows: https://shisho.dev/releases/takumi-guard-setup-0.6.0.ps1

手順は以下の通りです。なお、Bot および API キーをすでに作成済みの場合は、ステップ 3 から開始してください。

1. Takumi / Shisho Cloud コンソール（設定 > ボット）で Bot を作成し、「Takumi Guard トークン発行者」ロールを付与してください
2. Bot の API キーを生成してください
3. 上記の URL からセットアップスクリプト v0.6.0 をダウンロードしてください
4. お使いの管理ツール（Jamf、Intune、Ansible など）でラッパースクリプトを作成し、対象端末に配信してください

詳しい手順や最新のラッパースクリプト例は管理ツールによる一括セットアップガイドを参照してください。

組織向け機能を利用する​

Takumi Guard の組織向け機能（一括セットアップ、インストールログの検索など）を利用するには、Takumi サブスクリプションの契約と Guard の有効化が必要です。

1. https://cloud.shisho.dev/hello/takumi にアクセスし、サインインしてください
2. 組織を登録し、Takumi サブスクリプションを契約してください
3. 画面左のサイドバーから Guard > 設定 にアクセスしてください
4. 「有効化する」ボタンをクリックして Guard を有効化してください

有効化が完了したら、管理ツールによる一括セットアップガイドに従ってセットアップを進めてください。

概要​

Guard の感染可能性の通知は、ダウンロードしたパッケージが後から悪性であると判明した際にチームへ通知する機能です。これまでは、通知パイプラインが正しく動作しているかを確認するには、実際のアドバイザリが公開されるのを待つ必要がありました。今回のリリースにより、テスト通知をオンデマンドで送信し、Webhook URL に正常に送信できるか、署名シークレットが正しく設定されているか、メールを正常に受信できるかなどを即座に確認できます。

感染可能性の通知 の設定画面で、テスト対象の送信先（登録済みの Webhook エンドポイント、確認済みのメールアドレス、またはその両方）を選択し、テスト通知を送信 をクリックしてください。

テスト通知にはテスト用の内容が使用されるため、受信者が実際のインシデントと誤認することはありません。

• Webhook: 実際の感染可能性の通知と同じ構造のペイロードが送信されますが、type は guard.test_notification（実際の通知では guard.malicious_package_detected）となり、data ブロックには is_test: true が含まれます。アドバイザリ ID は TEST- で始まります。
• メール: 実際の感染可能性の通知と同じ構成のメールが送信されますが、冒頭に テスト通知 バナーが表示され、悪性パッケージは検出されていないことが明記されます。

Webhook ペイロードの例​

テスト通知の Webhook リクエストは、実際の通知と同じ構造です。type と is_test フィールドにより、本番のアラートと区別できます。

{
  "type": "guard.test_notification",
  "timestamp": "2026-05-12T04:00:00Z",
  "data": {
    "advisory": {
      "advisory_id": "TEST-...",
      "package_name": "@takumi-guard/evil-test-package",
      "...": "..."
    },
    "affected_downloads": [{ "...": "..." }],
    "summary": { "...": "..." },
    "is_test": true
  }
}

is_test フィールドはテスト通知にのみ含まれ、値は true に設定されます。実際の悪性パッケージ通知ではこのフィールド自体が含まれないため、自動化処理の中でテスト通知を確実にフィルタできます。

利用方法​

1. Takumi / Shisho Cloud コンソールで Guard > 設定 を開き、感染可能性の通知 セクションに移動します。
2. テスト対象の送信先（Webhook、メール、またはその両方）を選択します。
3. テスト通知を送信 をクリックします。
4. Webhook エンドポイントやメールの受信箱を確認し、テスト通知が正常に届いていることを確認します。

具体的な手順や、テスト通知の Webhook ペイロードおよびメール本文の例については、感染可能性の通知のユーザーガイドを参照してください。

Go プロジェクトで go get・go mod download・go build を Takumi Guard 経由でルーティングすることで、CI や開発環境に届く前に悪性モジュールをブロックできるようになりました。

概要​

Takumi Guard は、パッケージマネージャーと上流レジストリの間に位置するセキュリティプロキシです。すべてのインストールリクエストを GMO Flatt Security の脅威データベースと照合し、悪性パッケージをブロックします。

今回のリリースにより、npm・Python・Ruby のユーザーが利用していた保護機能が Go エコシステムでも利用可能になりました。

• パッケージブロック: 悪性モジュールをコードの取得前にブロック
• ダウンロード追跡: 認証済みユーザーのインストール履歴を記録
• 感染可能性の通知: ダウンロードしたモジュールが後から悪性であると判明した際に通知

Takumi Guard は標準の GOPROXY プロトコルに対応しているため、ツールチェーン側の変更は不要で、GOPROXY を Takumi Guard に向けるだけで利用できます。

利用開始​

以下の手順は匿名で利用できます。アカウント登録は不要です。

Go ツールチェーン​

すべてのモジュール取得を Takumi Guard 経由にルーティングするには、環境変数を 1 行設定するだけです。

go env -w GOPROXY=https://golang.flatt.tech

モジュールメタデータはブロックリスト適用のため Takumi Guard を経由しますが、モジュールアーティファクト（.zip）のダウンロードは proxy.golang.org に透過的にリダイレクトされるため、ダウンロード速度に影響はありません。

GitHub Actions​

flatt-security/setup-takumi-guard-golang Action を利用してください。ブロックのみであればアカウントもトークンも不要です。

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: "1.23"
      - uses: flatt-security/setup-takumi-guard-golang@v1
      - run: go build ./...

組織レベルのダウンロード追跡と感染可能性の通知を利用する場合は、bot-id を追加し id-token: write 権限を付与してください。Action が OIDC → 短期トークン交換を自動で行うため、CI に長期シークレットを保存する必要はありません。詳細は Go モジュールのクイックスタートを参照してください。

動作確認​

セットアップ後、ブロック対象として用意してある無害なテストモジュール github.com/flatt-security/hola-takumi-go のバージョン v0.1.0 をインストールしてみてください。

cd $(mktemp -d) && go mod init verify-takumi-guard && go get github.com/flatt-security/hola-takumi-go@v0.1.0

Takumi Guard が正しく動作していれば、go get は次のエラーで失敗します。

go: github.com/flatt-security/hola-takumi-go@v0.1.0: reading https://golang.flatt.tech/github.com/flatt-security/hola-takumi-go/@v/v0.1.0.info: 403 Forbidden

詳しくは、Go モジュールクイックスタートの「動作確認」を参照してください。

ユーザー登録で更に多くの機能を（無料）​

メールアドレスを登録すると、ダウンロードしたモジュールが後から悪性であると判明した際に通知が届くようになります。無料で利用できます。

ステップ 1: メールアドレスを登録します。

curl -X POST https://golang.flatt.tech/api/v1/tokens \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com", "language": "ja"}'

ステップ 2: ウェルカムメール本文に直接記載された API キーを確認します。リンクのクリックは不要です。

ステップ 3: トークンを ~/.netrc に追記して、Go ツールチェーンが取得時に認証情報を送るようにします。

echo "machine golang.flatt.tech login token password tg_anon_xxxxxx" >> ~/.netrc
chmod 600 ~/.netrc

Go ツールチェーンは GOPROXY サーバーに対して .netrc 経由の HTTP Basic 認証を使います。ユーザー名は無視され、トークンはパスワード欄に記述します。これでインストール履歴が記録され、ダウンロードしたモジュールが後から悪性であると判明した際に通知が届くようになります。

プライベートモジュール​

公開モジュールは Takumi Guard 経由で取得し、プライベートモジュール（社内 GitHub Organization など）は Takumi Guard を経由せず VCS から直接取得する構成を推奨します。Go 標準の GOPRIVATE 環境変数を使ってください。

go env -w GOPROXY=https://golang.flatt.tech
go env -w GOPRIVATE=github.com/your-org/*,*.internal.your-corp.com

GOPRIVATE にマッチしたモジュールは、既存の git 認証情報で VCS から直接取得され、プロキシを経由しません。詳しくは Go モジュールクイックスタート を参照してください。

組織全体での運用​

チームで Takumi Guard を運用する場合、インストール履歴の検索、組織ユーザートークンの一元管理、感染可能性通知の Webhook 配信 などの組織向け機能が利用できます。Guard を有効化した Takumi サブスクリプションでご利用ください。

1. https://cloud.shisho.dev/hello/takumi にアクセスしてサインインします。
2. 組織を登録し、Takumi のサブスクリプションを開始します。
3. サイドバーから Guard > Settings に移動します。
4. 「Enable」をクリックして Guard を有効化します。

Guard を有効化したら、Go モジュールクイックスタート に従って CI や開発者端末を設定してください。

GitHub Actions から長期の組織ユーザートークンのみを利用する場合は、お支払いの登録は不要です。組織登録時にお支払い画面が表示されますが、スキップして問題ありません。Guard ページから GitHub Organization を登録するだけで、組織ユーザートークンを発行できます。

概要​

本ポータルは、開発者と Guard の組織ユーザートークン API の間に立つ小さな Web アプリケーションです。各開発者は、自社の IdP でポータルにサインインし、自身の user_identifier に紐づく tg_org_ トークンをポータル上で発行します。発行直後に画面に表示される平文を、その場で .npmrc や CI ランナーのシークレットなど必要な箇所に貼り付ければ、以降はその設定から Guard と直接通信できるようになります。

この構成では、Bot のクレデンシャル自体はポータル側にのみ保持されます。これにより、各開発者は自身が利用するトークンだけを各自で扱えばよく、Takumi Guard の契約を担当する管理者側も、Shisho Cloud の Bot のクレデンシャルを開発者一人ひとりの端末や CI 環境に配布する必要がありません。

全体の流れを次の図に示します。

本ポータルは、管理者向けセットアップスクリプト（Bot のクレデンシャル込みのセットアップを MDM 経由で管理対象端末に一斉配信する用途）と、Takumi API（CI/CD や入退社処理からトークン操作を完全に自動化する用途）のちょうど中間にあたる選択肢として位置づけられます。開発者自身がトークンを払い出す運用にしたい一方で、Bot のクレデンシャルを MDM で全端末に配るのは難しい、あるいは望ましくないという環境に適しています。

ポータルに表示される機能は、ポータル側の設定値ではなく、紐づけた Bot に付与されている Guard ロールから自動的に決まります。Bot が organization/takumi_guard_token_issuer ロールを持つ場合は発行ボタンのみの画面となり、organization/takumi_manager ロールを持つ場合は、各開発者が自身のトークン一覧と取り消し操作も併せて利用できる画面となります。ロールの切り替えは Guard 側だけで完結し、次回のページ読み込みから挙動に反映されるため、ポータル本体の再デプロイは必要ありません。

トークンを発行すると、平文のトークンがメタデータと併せて 一度だけ 表示されます。ページを閉じたあとはポータル側でも復元できないため、開発者はその場で必要なツールの設定に貼り付けるか、改めて取り消したうえで再発行する必要があります。

一覧・取り消しを有効にした場合も、各開発者が画面から確認・取り消しできるのは 自身のトークンに限られます。組織オーナーであっても、他者のトークンを操作するための画面は用意していません。一覧・取り消しのどちらでも user_identifier を二重にフィルタしており、まず Guard API 側にプレフィックスを渡して呼び出し元のトークンに絞り込み、さらにポータル側でも完全一致を確認しています。リクエストに token_id を改ざんしても、呼び出し元が所有していないトークンへは到達できない設計です。

利用方法​

リポジトリには、Google Cloud Run + Identity-Aware Proxy + Secret Manager 構成でのデプロイ例が同梱されています。この構成を採用する場合は、以下の手順でデプロイできます。

1. Shisho Cloud のコンソールで Bot を作成し、用途に応じて organization/takumi_guard_token_issuer ロール（発行のみ）または organization/takumi_manager ロール（発行・一覧・取り消し）を付与する。発行された Bot ID（BT01…）と API キーを控えておく。
2. リポジトリをクローンし、examples/cloudrun/ 配下の README に従ってデプロイする。
3. 公開された URL を開発者に共有する。各開発者は IdP でサインインしたあと、数クリックで自身のトークンを払い出し、一度だけ表示される平文をその場で必要なツールの設定に貼り付ければよい。

Google Cloud IAP 以外の IdP と連携させたい場合や、Cloud Run 以外の環境にデプロイしたい場合は、internal/auth/ 配下に 4 メソッドの Authenticator インターフェースを実装した認証アダプターを各自で追加したうえで、ご利用の環境に合わせてデプロイしてください。同梱の IAP / Basic アダプターをそのまま実装例として参考にできます。

補足: 位置づけ​

本リポジトリは「参考実装」としての公開であり、マネージドプロダクトではありません。社内で最低限のレビューは経ていますが、本番環境で運用する前には、貴組織のセキュリティ要件と照らし合わせたうえで必ず検証し、必要に応じて改変してからご利用ください。ソースコードは MIT ライセンスのもと、github.com/flatt-security/takumi-guard-portal-example で公開しています。

概要​

コンソールからのトークン発行は4 月のリリースで対応済みで、新規メンバーへの個別の払い出しといった都度の運用に向いています。一方、組織が拡大し、入退社時の発行・取り消しや漏洩時のクレデンシャル切り替えといった作業を仕組み化したくなると、コンソールではなくスクリプトから扱える経路が必要になります。

今回追加した次の 4 つのエンドポイントにより、トークンのライフサイクル全体を Takumi API から扱えるようになりました。

• POST /o/{org_id}/guard/org-user-tokens で任意の user_identifier を指定して新しいトークンを発行する
• GET /o/{org_id}/guard/org-user-tokens でトークンを一覧する（user_identifier のプレフィックスやステータスによる絞り込みに対応）
• DELETE /o/{org_id}/guard/org-user-tokens/by-id/{token_id} で管理 ID を指定してトークンを取り消す
• POST /o/{org_id}/guard/org-user-tokens/probe で平文のトークンがまだ有効かつ自組織のものかを確認する

いずれのエンドポイントも、標準の Authorization: Bearer ヘッダで認証します。指定する値はボットの API キー と ボット ID をコロン (:) で連結した文字列で、いずれも下の 利用例 手順 1 でボット作成時に取得できます。

Authorization: Bearer shisho_apikey_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:BT01XXXXXXXXXXXXXXXXXXXXXXXX

必要な権限は、人間のユーザーが同じ操作をコンソールから行う場合と同じです。発行には organization/takumi_guard_token_issuer、取り消しには organization/takumi_manager など、用途に応じて組織ロールを使い分けてください。

利用例​

1. Shisho Cloud のコンソールで 設定 → ボット → ボットを追加 からボットを作成し、用途に応じた組織ロール（organization/takumi_guard_token_issuer または organization/takumi_manager）を付与しましょう。

2. ボットに対して API キーを発行し、API キーとボット ID の両方 をお使いの自動化ツールのシークレットとして保存します。API に渡すクレデンシャルは、両者をコロン (:) で連結した shisho_apikey_…:BT01… の形式です。

3. 次のように呼び出すと、新しいトークンを発行できます。

   curl -sS https://api.cloud.shisho.dev/v1/o/$ORG/guard/org-user-tokens \
     -H "Authorization: Bearer $BOT_API_KEY:$BOT_ID" \
     --json '{"user_identifier": "alice-laptop"}'
   

詳細な API 仕様​

ここまでの手順は、もっとも簡単な利用例の一つにすぎません。発行・一覧・取り消し・有効性確認の各エンドポイントは、お使いの自動化ツールや、既存のオンボーディング・退職処理に合わせて、自由に組み合わせて利用できます。

各エンドポイントのリクエスト・レスポンスの詳細スキーマやバリデーションルール、エラーレスポンスの形式については、OpenAPI ドキュメントを参照してください。ユーザー識別子の命名例や失効方法など、運用上の詳細はトークンの管理を参照してください。

概要​

v0.5.0 では、セットアップスクリプトに 5 つのプリミティブサブコマンドが追加されました。それぞれのサブコマンドが、これまで 1 つの呼び出しに固まっていたセットアップ処理の中の 1 ステップを担うため、管理者側で自由に組み合わせて配信フローを設計できるようになっています。

Bot の API 認証情報が必要なのは verify と issue のみです。そのため、各開発者のシェル側には API キーを渡さず、discover や install だけをそれぞれのシェル内で動かす設計も可能になっています。標準出力・標準エラー・終了コードの詳細はサブコマンドモードの I/O コントラクトを参照してください。

それぞれのサブコマンドの呼び出し例は以下の通りです。

# precheck -- 端末上に設定対象が存在するか判定する（API 呼び出しなし）
./setup.sh precheck

# discover -- 端末上のローカル設定から既存の Guard トークンを列挙する
./setup.sh discover

# verify -- トークンの状態を Guard API に問い合わせる（bot 認証情報が必要）
TG_BOT_ID=BTxxxxxxxxxxxxxxxxxxxxxxxxxxx \
TG_BOT_API_KEY=shisho_apikey_xxxxxxxxxxxxx \
  ./setup.sh verify tg_org_xxxxxxxxxxxxxxxxx

# issue -- 新しいトークンを発行する（bot 認証情報が必要）
TG_BOT_ID=BTxxxxxxxxxxxxxxxxxxxxxxxxxxx \
TG_BOT_API_KEY=shisho_apikey_xxxxxxxxxxxxx \
  ./setup.sh issue acme-laptop-042

# install -- 取得済みのトークンを各パッケージマネージャーの設定に書き込む
./setup.sh install tg_org_xxxxxxxxxxxxxxxxx
./setup.sh install tg_org_xxxxxxxxxxxxxxxxx npm,pypi

補足: 「端末あたり 1 トークン」配信例の公開​

これまでのセットアップスクリプトは「端末 × ユーザー」単位で 1 トークンを発行する設計でした。1 台の端末に複数の開発者アカウントが同居する環境（複数のエンジニアが交代で利用する共用ワークステーション、MDM 管理用アカウントと開発者本人のアカウントが共存するノート PC、IdP 経由でプロビジョニングされたアカウントと端末ローカルアカウントが併存する環境など）では、消費ライセンス数が物理的な端末数を超えやすく、ライセンス計画とのズレが発生していました。

v0.5.0 では、上記のサブコマンドを組み合わせて構築した「端末あたり 1 トークン」の配信スクリプト例を新たに公開しました。このラッパーは、端末上の各ユーザープロファイルを順に走査して既存の有効なトークンを探し、見つかった場合は再利用、見つからない場合のみ 1 つだけ新しいトークンを発行したうえで、その同じトークンを端末上の全開発者アカウントに配布します。

具体的なスクリプトは配信例（端末あたり 1 トークン）を参照してください。これまでの配信例（端末のユーザー毎に個別トークン）もそのまま残っており、どちらの配信例も有効なトークンを検出した場合は再発行を行わずに再利用するため、Jamf や Intune、Ansible などの管理ツールから定期実行しても安全です。

補足: 後方互換性​

v0.4.x からアップグレードする場合、管理者側の追加作業は不要です。v0.5.0 以前の BOT_ID USER_IDENTIFIER [SCOPES] という 3 つの位置引数による呼び出しはそのまま動作し、標準出力のログ・終了コード・バックアップとロールバックの挙動を含めて、出力はこれまでと完全に同じです。ユーザー単位モデルで過去に発行したトークンも引き続き有効で、次回実行時に再利用されます。どのタイミングで「端末あたり 1 トークン」のラッパーに切り替えても、端末上にすでに存在する有効なトークンを検出して再利用するため、移行時にライセンスが無駄に消費されることはありません。

概要​

Takumi Guard の提供する Action（例: flatt-security/setup-takumi-guard-npm）及び Shisho Cloud Action は、実行時、Actions ランナーから取得できる OIDC トークンを用いて Shisho Cloud / Takumi の認証情報を取得しています。この処理では、トークン署名の検証のために、GitHub が提供する token.actions.githubusercontent.com への一時的な通信が必要です。

2026 年 5 月 19 日に、当社のトークン交換サービスから上記の GitHub エンドポイントへ間欠的に到達できない時間帯が観測されました。その結果として一部のお客様 GitHub Actions ワークフローで認証エラーが発生したことを確認しています。

今回のリリースでは、ネットワーク環境及び token.actions.githubusercontent.com が提供する JWKS（JSON Web Key Set）のキャッシュロジックを改善しました。結果として、二点の間で一時的に通信が失敗しても、ワークフロー側に影響が出にくくなっています。

必要な対応​

お客様側で必要な対応は、特にありません。 flatt-security/shisho-cloud-action および flatt-security/setup-takumi-guard-* 系の Actions を利用しているすべてのワークフローが、自動的にこの改善の影響を受けます。

補足​

不安定な挙動が継続してみられる場合は、可能な限り参考となる情報を添付の上、サポート窓口にお問い合わせください。

概要​

これまでは、クレジット上限に余裕があるにもかかわらずクロールが早期に終了し、未発見のページや API が残ることがありました。今回のアップデートにより、設定したクレジット上限をより有効に活用して、より多くのページや API を発見できるようになりました。

クレジット消費への影響​

クロールによるクレジット消費量が増加します。たとえば、上限を 30 クレジットに設定していた場合、以前は約 10 クレジット程度の消費で終了することがありましたが、今後はより上限に近い量を消費する可能性があります。

引き続き、クレジット消費量が設定した上限を超えることはありません。

推奨される対応​

ブラックボックス診断に設定しているクレジット上限を確認してください。従来の消費傾向を前提に上限を設定していた場合、意図した予算を超過する可能性があります。必要に応じて上限値を調整してください。また、クロールの網羅性を高めたい場合は、クレジット上限を初期値よりも少し大きく設定することを推奨します。上限に余裕を持たせることで、より多くのページや API を発見できるようになります。

Bundler を使用する Ruby プロジェクトで、Takumi Guard 経由でインストールをルーティングすることで、CI や開発環境に届く前に悪性パッケージをブロックできるようになりました。

概要​

Takumi Guard は、パッケージマネージャーと上流レジストリの間に位置するセキュリティプロキシです。すべてのインストールリクエストを GMO Flatt Security の脅威データベースと照合し、悪性パッケージをブロックします。

今回のリリースにより、npm・Python ユーザーが利用していた保護機能が Ruby エコシステムでも利用可能になりました。

• パッケージブロック: 悪性な gem をコード実行前にブロック
• ダウンロード追跡: 認証済みユーザーのインストール履歴を記録
• 感染可能性の通知: ダウンロードした Gem が後から悪性であると判明した場合に通知

利用開始方法​

以下のいずれも、アカウント登録不要で匿名のまま利用できます。

Bundler​

Takumi Guard 経由で bundle install をルーティングする設定です。設定行を 1 つ追加するだけで、すべてのインストールリクエストがプロキシを通過するようになります。

bundle config set --global mirror.https://rubygems.org https://rubygems.flatt.tech/

Gemfile の変更は不要で、透過的にプロキシを通じてすべてのインストールリクエストが処理されます。

GitHub Actions​

ワークフローに 1 行追加するだけで導入できます。

steps:
  - uses: actions/checkout@v4
  - uses: flatt-security/setup-takumi-guard-rubygems@v1
  - run: bundle install

認証や感染可能性の通知を含む詳細なセットアップ手順は RubyGems クイックスタートガイド をご覧ください。

検証方法​

セットアップが完了したら、検証用・無害なブロック済み gem hola-takumi のバージョン 0.1.0 をインストールしてみてください。

cd $(mktemp -d) && printf 'source "https://rubygems.org"\ngem "hola-takumi", "0.1.0"\n' > Gemfile && bundle install

Takumi Guard が正しく動作していれば、Bundler は以下のエラーでインストールに失敗します。

Fetching gem metadata from https://rubygems.flatt.tech/.
Could not find gem 'hola-takumi (= 0.1.0)' in rubygems repository
https://rubygems.org/ or installed locally.

詳しい手順は RubyGems クイックスタートの「セットアップの確認」 を参照してください。

メール登録してより便利に（無料）​

メールアドレスを登録すると、ダウンロードした Gem が後から悪性であると判明した場合に通知が届きます。無料で利用できます。

ステップ 1: メールアドレスを登録する

curl -X POST https://rubygems.flatt.tech/api/v1/tokens \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com", "language": "ja"}'

ステップ 2: ウェルカムメールから API キーを取得する。API キーはメール本文に直接記載されています。リンクをクリックする手順は不要です。

ステップ 3: トークンでパッケージマネージャーを設定する（ステップ 2 で取得したトークンを使用）

bundle config set --global mirror.https://rubygems.org https://token:tg_anon_xxxxxx@rubygems.flatt.tech/

以降のインストールが追跡され、ダウンロードしたパッケージに問題が見つかった場合に通知が届きます。

組織単位での管理も可能​

チームで Takumi Guard を運用するなら、管理ツールによる一括セットアップ、インストールログの検索、組織ユーザートークンの一元管理、感染可能性の Webhook 通知 など、組織単位での運用を効率化する機能がまとめて利用できます。Takumi サブスクリプション（Guard 有効化）で始められます。

1. https://cloud.shisho.dev/hello/takumi にアクセスし、サインインする
2. 組織を登録し、Takumi サブスクリプションを契約する
3. 画面左のサイドバーから Guard > 設定 にアクセスする
4. 「有効化する」ボタンをクリックして Guard を有効化する

有効化が完了したら、管理ツールによる一括セットアップガイドに従ってセットアップを進めてください。

なお、GitHub Actions の Bot トークン 利用だけなら決済は不要です。組織登録時に決済画面が表示されてもそのままスキップして、Guard ページから GitHub 組織を登録するだけで Bot ID を取得できます。

機能概要​

これまで脆弱性検証機能は、Takumi のブラックボックス診断で検出された脆弱性のみを対象としていました。 本アップデートにより、Takumi による診断結果に紐づかない脆弱性についても、手動で検証タスクを作成して再現検証を実行できるようになりました。

これにより、以下のようなユースケースに対応できます。

• バグバウンティプログラムで報告された脆弱性の妥当性確認
• 第三者の脆弱性診断レポートに含まれる指摘事項の検証

提供範囲​

本機能は、すべての Takumi byGMO ユーザにご利用いただけます。

使い方の詳細は 脆弱性検証 のドキュメントをご覧ください。

概要​

今回のアップデートにより、組織ごとに以下の通知先を設定できます。

• Webhook エンドポイント: 組織に登録済みの Webhook から選択します。
• メールアドレス: 組織のメール許可リストで確認済みのアドレスから選択します。

どちらか一方、両方、またはいずれも使用しない、のいずれの設定も可能です。設定した通知先には同じ通知ペイロードが送信されるため、Webhook 経由で Slack や PagerDuty に転送したり、共有メールアドレスでインシデント対応フローに載せたりと、既存の運用に合わせて組み込めます。

利用方法​

Shisho Cloud/Takumi 管理コンソールで「Guard > 設定」を開き、感染可能性の通知 セクションから設定してください。

• Webhook をドロップダウンから選択します。一覧が空の場合は、先に Webhook 設定ページから登録してください。
• 確認済みのメールアドレスをドロップダウンから選択します。一覧が空の場合は、先にメール許可リストへアドレスを追加し、確認を完了してください。
• 保存すると、以降のダウンロードに対して設定が反映されます。

通知が送信される条件や配信の仕組みについては、感染可能性の通知のユーザーガイドを参照してください。

補足​

• 通知先の保存以降に発生したダウンロードのみが対象です。通知先を変更しても、過去のダウンロードに対して改めて通知が送信されることはありません。
• メール認証トークンに対する従来の通知は、これまで通り、登録したメールアドレス宛に行われます。なおメール認証トークンをShisho Cloud 組織に紐づけることはできません。

概要​

コンソールからの発行は、日常的な運用のなかで必要に応じて個別にトークンを発行したいケースに適しています。たとえば、新しくチームに加わったメンバーが初日から利用を開始する場合や、短期の業務委託メンバー向けに発行する際に活用できます。

発行直後には、新しいトークンとあわせて npm・PyPI 向けのセットアップコマンドが表示されるため、受け取った側もすぐに利用を開始できます。

Guard API 経由の発行フローはこれまで通り利用でき、構成管理ツールや MDM を使った大規模配布には引き続き最適な選択肢です。

利用方法​

1. Takumi / Shisho Cloud コンソールで Guard > トークン に移動してください。
2. トークン発行 をクリックしてください。
3. ユーザー識別子 を入力して 発行 をクリックしてください。

トークンのシークレットは発行時に 一度だけ 表示されます。必ず発行直後にコピーして、安全な場所に保管してください。

ユーザー識別子の命名例や失効方法など、詳細はトークンの管理を参照してください。

概要​

診断レポートを、フォーマットされた表紙付きの PDF ファイルとしてダウンロードできます。オフラインでの共有や、診断記録のアーカイブに活用できます。

利用開始方法​

完了済みの診断レポートページで 「PDFレポートを発行」 ボタンをクリックし、表紙の言語を選択します。PDF の生成が完了すると、メールでダウンロードリンクが送付されます。

詳しくはブラックボックス診断のドキュメントまたはホワイトボックス診断のドキュメントをご覧ください。

機能概要​

脆弱性検証機能は、特定の脆弱性に対して以前と同じ攻撃シナリオを再実行します。 修正をデプロイした後に本機能を実行することで、対策が有効に機能しているかを検証することができます。

アプリケーション診断報告書の「脆弱性を検証する」ボタンから、対象の脆弱性を選択して実行します。

検証結果は 「脆弱性なし」 または 「脆弱性あり」 の判定として、理由とともに表示されます。

前提条件​

1件以上の脆弱性が検出された、完了済みのブラックボックス診断結果が必要です。GitHub連携等の追加設定なしで利用可能です。

提供範囲​

本機能は、ブラックボックス診断をご利用のすべての Takumi byGMO ユーザにご利用いただけます。

詳しくは 脆弱性検証 のドキュメントをご覧ください。

概要​

大規模なチームでは、個々の開発者マシンに Takumi Guard をセットアップするのに時間がかかります。一括セットアップ機能は、npm・pip・uv・Poetry に対して Guard レジストリプロキシを設定するスクリプトを提供し、トークンの発行とクレデンシャルの設定を自動的に処理します。

セットアップスクリプトによって発行されたトークンは、Takumi / Shisho Cloud コンソールの Guard > トークン で一覧・管理できます。

利用方法​

以下の図は、一括セットアップの全体構成を示しています。

手順は以下の通りです。

1. Takumi / Shisho Cloud コンソール（設定 > ボット）で Bot を作成し、「Takumi Guard トークン発行者」ロールを付与する
2. Bot の API キーを生成する
3. Guard > 設定 からセットアップスクリプトをダウンロードする
4. お使いの管理ツール（Jamf、Intune、Ansible など）でラッパースクリプトを作成し、対象端末に配信する

詳しい手順は管理ツールによる一括セットアップガイドを参照してください。

主な特徴​

マルチエコシステム対応​

npm・pip・uv・Poetry を 1 回のスクリプト実行でまとめて設定できます。開発者がどのパッケージマネージャーを使っていても、個別に手順を用意する必要はありません。

冪等な実行​

同じスクリプトを複数回実行しても安全です。初回実行時にトークンを発行し、設定ファイルを更新しますが、再実行時には既存のトークンを検出して再利用し、設定済みのツールはスキップします。管理ツールから定期的に配信しても問題ありません。

段階的なスコープ追加​

最初は npm のみを対象にセットアップし、後から PyPI を追加するといった段階的な導入が可能です。追加時にも既存の設定は維持されます。

# 初回：npm のみセットアップ
TG_BOT_API_KEY="..." ./setup.sh BOT_ID USER_ID npm

# 後日：PyPI を追加（npm の設定はそのまま維持）
TG_BOT_API_KEY="..." ./setup.sh BOT_ID USER_ID pypi

バックアップ作成​

設定ファイルを変更する前に、タイムスタンプ付きの永続バックアップを自動的に作成します（例：~/.npmrc-backup-20260408-162351）。万が一 Guard の設定を元に戻したい場合は、バックアップファイルをコピーするだけで復旧できます。

留意事項​

メール認証トークン（tg_anon_…）で既に Guard を利用しているユーザーを、組織ユーザートークン（tg_org_…）にまとめることはできません。メール認証トークンと組織ユーザートークンは独立した認証方式であり、既存のメール認証トークンは引き続きそのまま利用できますが、一括セットアップで発行される組織ユーザートークンとは別のものです。

組織での利用を始める​

Takumi Guard の組織向け機能（一括セットアップ、インストールログの検索など）を利用するには、Takumi サブスクリプションの契約と Guard の有効化が必要です。

1. https://cloud.shisho.dev/hello/takumi にアクセスし、サインインする
2. 組織を登録し、Takumi サブスクリプションを契約する
3. 画面左のサイドバーから Guard > 設定 にアクセスする
4. 「有効化する」ボタンをクリックして Guard を有効化する

有効化が完了したら、管理ツールによる一括セットアップガイドに従ってセットアップを進めてください。

概要​

パッケージインストールログは、組織全体のパッケージダウンロードの検索可能な監査証跡を提供します。各ログエントリには、タイムスタンプ、パッケージ名とバージョン、エコシステム（npm / PyPI）、ダウンロードを開始した主体（プリンシパル）、許可またはブロックされたかのステータスが記録されます。

悪意あるパッケージが報告された際に、どのパイプラインがいつインストールしたかを迅速に特定できます。

利用方法​

Takumi / Shisho Cloud コンソールの Guard > ログ から利用できます。

主な機能​

パッケージ名による検索​

パッケージ名を入力して、組織全体でそのパッケージがいつ・誰によってインストールされたかを検索できます。バージョンを指定しての絞り込みにも対応しています。特定のパッケージに脆弱性が報告された際などに、影響範囲の特定に活用できます。

エコシステムの切り替え​

npm と PyPI を切り替えて検索できます。組織で利用しているパッケージマネージャーに応じて、対象のエコシステムを選択してください。

日付範囲の指定​

24 時間・7 日間・14 日間のプリセット、またはカスタム範囲で検索期間を絞り込めます。現時点では検索可能な範囲は過去 14 日間までですが、今後可能な限り拡張していく予定です。

プリンシパルとステータスの確認​

各ログエントリには、ダウンロードを開始した主体（組織ユーザートークンの識別子、匿名トークンなど）と、ブロックリストによってダウンロードが許可されたか・ブロックされたかのステータスが表示されます。ブロックされたダウンロードも記録されるため、ブロックリストが実際に機能していることを確認できます。

今後の展望​

検索条件をより柔軟にし、さまざまな観点からログを絞り込めるよう改善を進めていきます。

また、SIEM をはじめとする法人向けセキュリティソリューションを利用されているお客様向けに、ログ全量をリアルタイムにストリーム配信する仕組みも検討しています。ご要望やユースケースがありましたら、アカウントマネージャーまでお知らせください。

変更内容​

Yarn クライアントのみを対象に、ロックファイル内に対するメタデータ書き換えの挙動を変更しました。具体的には、メタデータ配信時に、tarball dist URLs を Takumi Guard レジストリの URL に書き換えるように変更されました。

変更背景​

Yarn v1 は tarball dist URLs を lockfile 内に含める挙動を取り、Yarn v2+ クライアントは、レジストリから得られるパッケージメタデータファイル内の tarball dist URLs とレジストリURLに乖離がある場合に lockfile 内に __archiveUrl フィールドを追加します。この挙動により、yarn 実行時にロックファイルのみが参照されるシナリオで、yarn クライアントが Takumi Guard を迂回する挙動をとる場合がございます。

変更の影響範囲​

npm・pnpm・Bun 等への影響​

影響はありません。

Yarn v1 への影響: 新規パッケージの追加・更新時に有​

yarn.lock のエントリに、従来のアップストリームレジストリ URL ではなく Takumi Guard のレジストリ URL が記録されるようになります。 これは他パッケージマネージャの利用時には起こらない挙動ですが、Yarn v1 においてのみ発生します。これはロックファイル経由の依存解決シナリオで、安定してブロック対象パッケージのインストールを防止するために必要な変更でございますので、ご理解いただけますと幸いです。

Yarn v2–v4（Berry）への影響: 無​

既存の yarn.lock 内の __archiveUrl フィールドが、次回のパッケージ更新時に削除されるようになります。この点以外には、既知の影響はありません。

概要​

「一部だけ診断」モードでは、まず対象アプリケーションをクロールして機能を洗い出し、その後に診断する機能・観点を選択して診断を実行します。

自動クロールは、複雑なステップが必要なエンドポイント等を見落とすことがあります。今回追加した手動編集機能を使うと、クロール完了後にその結果を調整したうえで診断に進めます。これにより、自動クロールでは到達できなかった機能・エンドポイントも診断対象に含めることができます。

編集ページでは、以下の操作が可能です。

• 既存機能へのエンドポイント追加: クロール済みの機能に、不足しているエンドポイントを追加します
• 既存機能からのエンドポイント削除: クロールで検出されたが診断対象として不要なエンドポイントを除外します
• 新規機能の追加: クロールで検出されなかった機能を、エンドポイントとあわせて追加します

利用開始方法​

本機能は Takumi によるブラックボックス診断機能にてご利用いただけます。

詳しくはブラックボックス診断のドキュメントをご覧ください。

背景​

ソフトウェアサプライチェーンへの脅威は深刻さを増しています。LiteLLM の侵害事案（外部リンク）や axios の侵害事案（弊社によるまとめ）に見られるように、広く利用されているパッケージであっても攻撃の対象となりえます。こうした状況を受け、Takumi Guard へのニーズは増加しており、可能な限りの貢献を果たすべく、大規模環境への対応を強化しています。

多数の GitHub Actions ジョブが単一トークンを共有する大規模環境では、ピーク時に従来の 10,000 回/分のレートリミットに到達し、429 Too Many Requests エラーが発生するケースがありました。最大規模の CI パイプラインでも Takumi Guard を摩擦なく利用できるよう、今回レートリミットを引き上げました。

変更内容​

GitHub Actions/Bot トークンのレートリミットウィンドウを 60 秒から 10 秒に短縮し、ウィンドウあたりのリクエスト数（10,000 回）は維持しました。これにより、実効スループットが約 60,000 回/分に向上しています。

ご利用者様側での対応は不要です。変更は自動的に適用されています。

組織での利用を始める​

Bot トークンを利用して GitHub 組織単位で Takumi Guard を導入するには、以下の手順で設定してください。

1. https://cloud.shisho.dev/hello/takumi にアクセスし、サインインする
2. 組織を登録する。決済画面が表示されますが、本機能の利用に決済は不要です
3. 画面左のサイドバーから Guard ページにアクセスする
4. 保護対象の GitHub 組織名を入力する。組織に紐づく Bot ID が発行されます

5. GitHub Actions ワークフローにセットアップステップを追加します。具体的には、以下の 3 点を変更してください。
   • permissions に id-token: write を追加する（OIDC に必要）
   • contents: read など、ワークフローに必要な他の権限を追加する
   • flatt-security/setup-takumi-guard-npm@v1 アクションを Bot ID 付きで追加する

設定が完了すると、GitHub Actions ワークフローからのパッケージリクエストが Bot トークンで認証され、引き上げ後のレートリミットが適用されます。

詳細​

レートリミットの全体については制限事項・注意事項をご覧ください。