プロジェクトとAPIキー
サインアップ、プロジェクト作成、APIキー管理、環境の分離。
プロジェクトとAPIキー
JamJet Cloudは、すべてのテレメトリー、ガバナンス、承認データをプロジェクト単位で整理します。プロジェクトは論理的な境界であり、すべてのスパン、ポリシー決定、予算制限、監査イベントは必ず1つのプロジェクトに属します。APIキーはプロジェクトへのアクセスを許可し、SDKが必要とする唯一の認証情報です。
サインアップ
app.jamjet.devで無料アカウントを作成できます。クレジットカードは不要です。無料プランでは、テレメトリー、ガバナンス、監査証跡、ネットワークグラフを含む完全なダッシュボードにすぐにアクセスでき、ローリング保持期間が設けられています。
サインアップ後、プロジェクト画面に移動し、最初のプロジェクトを作成できます。
プロジェクト
プロジェクトは、JamJet Cloud内のすべてを管理する最上位のグループです。一般的なパターン:
- サービスごとに1つのプロジェクト。 推論API、バックグラウンドジョブランナー、社内チャットツールがそれぞれ独自のプロジェクトを持ちます。スパンは分離され、コストは個別に集計され、ポリシーは独立してスコープ設定されます。
- 環境ごとに1つのプロジェクト。 単一のサービスに
my-app-dev、my-app-staging、my-app-prodのプロジェクトを設定します。これは開発トラフィックを本番環境の監査ログから分離する最もシンプルな方法です。 - チームごとに1つのプロジェクト。 ガバナンスの責任がチームごとに異なる大規模組織で有用です。各チームが独自のポリシー、予算、メンバー名簿を管理します。
プロジェクトは階層構造ではありません。サブプロジェクトやワークスペースは存在しません。複数のプロジェクト間でコストを集計する必要がある場合は、各プロジェクトからスパンをエクスポートして外部で集計するか、プロセスコンテキスト経由で設定されるスパンごとのenvironmentおよびserviceタグを使用できます。
APIキー
APIキーは、SDKをJamJet Cloudに対して認証します。各キーは正確に1つのプロジェクトにスコープされます。キーは、プロジェクト内の設定 → APIキーで生成します。キーはjj_xxxxxxxxxxxxのような形式です。
キーは作成時に一度だけ表示されます。すぐにコピーして保存してください。紛失した場合は、新しいキーを作成し、古いキーを無効化してください。
環境による分離
環境を分離する最も確実な方法は、環境ごとに専用のキーを作成し、それぞれを異なるプロジェクト(または同じプロジェクト — SDKはenvironmentをスパン属性として送信しますが、プロジェクトを分けることでフィルタリングが容易になり、保持設定も独立します)に向けることです。
典型的な設定:
JAMJET_API_KEY_DEV→my-app-devプロジェクトJAMJET_API_KEY_STAGING→my-app-stagingプロジェクトJAMJET_API_KEY_PROD→my-app-prodプロジェクト
各デプロイ先で環境変数に適切なキーを設定します。SDKはデフォルトでJAMJET_API_KEYを読み取りますが、init()/configure()時に明示的に渡すこともできます。
ダウンタイムなしでのキーローテーション
キーを安全にローテーションするには3ステップのプロセスを踏みます:
- 新しいキーを作成します(設定 → APIキー)。新しいキーは即座に有効になります。
- 新しいキーをデプロイします。すべてのインスタンスが完全に再起動するまで、古いキーと新しいキーが同時に使用されます — 両方とも有効です。
- 古いキーを無効化します(設定 → APIキー)。すべての稼働中のインスタンスが新しいキーを取得したことを確認してから実行してください。無効化は即座に反映されます。
ステップ3の前に古いキーを無効化しないでください。部分的なロールアウト、カナリアデプロイ、段階的な再起動など、すべてがオーバーラップ期間に対応できます。
メンバーと役割
プロジェクトメンバーは設定 → メンバーで管理します。メールアドレスでチームメンバーを招待できます。役割の割り当てにより、プロジェクト内で閲覧・操作できる範囲が制御されます：
- Owner — プロジェクトの削除や請求設定を含む、すべての権限。
- Admin — 請求とプロジェクト削除を除く、すべての権限。メンバー管理が可能。
- Member — すべてのテレメトリの閲覧、承認リクエストへの対応、ガバナンス（ポリシー、予算、エージェント）の管理が可能。メンバー管理は不可。
- Read-only — テレメトリと監査証跡の閲覧のみ。リクエストの承認やガバナンス設定の変更は不可。
役割名と正確な権限は、ダッシュボードの成熟に伴い変更される可能性があります。現在の定義については、プロジェクト内の設定 → メンバーページを参照してください。
Member以上の役割を持つチームメンバーは、保留中の承認リクエストを承認または却下できます。専用の承認者役割はありません。承認権限を制限する必要がある場合は、オブザーバーにはRead-onlyを、承認を信頼できるメンバーにのみMemberを付与してください。