メインコンテンツへスキップ
サービスユーザーは、ロールベースの権限を持つ API アクセス専用のボットアカウントです。これは、すべての新規連携に対して推奨される認証方法です。

仕組み

  1. Settings > Service users でサービスユーザーを作成します
  2. サービスユーザーがアクセスできるエンドポイントを制御するロールを割り当てます
  3. cog_ で始まる APIキーを生成します
  4. すべてのリクエストで Authorization ヘッダーにこのキーを含めます
curl -X POST "https://api.devin.ai/v3/organizations/sessions" \
  -H "Authorization: Bearer $DEVIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Create a simple Python script"}'

サービスユーザーのスコープ

スコープ作成場所API アクセスユースケース
OrganizationSettings > Service users/v3/organizations/*セッション管理、Knowledge、プレイブック、シークレット
EnterpriseEnterprise settings > Service users/v3/enterprise/* + /v3/organizations/*組織横断の管理、分析、監査ログ、請求
Organization スコープのサービスユーザーは、URL で {org_id} を指定しなくてもエンドポイントを呼び出せます。{org_id} は認証情報から自動的に解決されます。

create_as_user_id を使ったセッションの帰属

サービスユーザーは、人間のユーザーとは別個の ID です。デフォルトでは、サービスユーザーによって作成されたセッションは、そのサービスユーザー自身に帰属します。特定のユーザー の代わりにセッションを作成する 場合は、セッション作成時に create_as_user_id パラメータを指定します。セッションはそのユーザーのセッション一覧に表示され、そのユーザーの使用量としてカウントされます。 これには、サービスユーザーのロールに ImpersonateOrgSessions 権限が必要です。
個人の APIキー から移行しますか? 個人の APIキー (v1/v2) は、あなたのユーザーとして自動的にセッションを作成していました。サービスユーザーを使う場合は、同じ動作を実現するために create_as_user_id を使用します。さらに RBAC や監査ログ、キー管理の一元化も利用できます。例については API Overview を参照してください。

キーの主なプロパティ

  • キーは cog_ で始まり、作成時に一度だけ表示されます
  • サービスユーザーは、監査ログ上で人間のユーザーとは別に表示されます
  • 権限は RBAC で制御されます — 連携に必要なものだけを付与してください
  • Enterprise のサービスユーザーは、すべての組織にわたって org レベルの権限を継承します
詳細なセットアップ手順については、Teams クイックスタート または Enterprise クイックスタート を参照してください。

レガシー API キー

レガシー API キーは、サービスユーザーへの移行を前提として廃止予定です。既存の連携については、サービスユーザーへの移行を推奨します。移行ガイドを参照してください。
レガシー API キーは v1 および v2 API で使用されます。非推奨期間中は引き続き利用できますが、RBAC、セッションのアトリビューション、カーソルベースのページネーションといった新機能には対応していません。
Key typePrefixUsed withDescription
Personal API keyapk_user_v1, v2ユーザーアカウントに紐づき、そのユーザーの権限を継承します
Service API keyapk_v1組織スコープで、自動化用途向け
発行場所: Settings > API Keys

Bearer トークン認証

すべての Devin API は Bearer トークン認証を利用します。Authorization ヘッダーにキーを指定してください。
Authorization: Bearer your_api_key_here
これはサービスユーザーの認証情報およびレガシー APIキー の両方に適用されます。

セキュリティのベストプラクティス

GitHub リポジトリ、クライアントサイドのコード、ログなど、公開されている場所で APIキーを決して共有しないでください。
  1. キーを安全に保管する: 環境変数やシークレット管理システムを使用する
  2. キーを定期的にローテーションする: 定期的に新しいキーを発行し、古いキーを失効させる
  3. 自動化にはサービスユーザーを使用する: 本番環境では個人のキーではなくサービスユーザーを優先して使用する
  4. 最小権限の原則を適用する: 必要最小限の権限のみを付与する
  5. 利用状況を監視する: 予期しない API の利用がないか監査ログを確認する
  6. 漏えいしたキーは直ちに失効させる: キーが漏えいした場合は、そのキーを失効させて新しいキーを発行する

トラブルシューティング

401 Unauthorized

考えられる原因:
  • 無効または期限切れの APIキー
  • Authorization ヘッダーが設定されていない
  • Bearer トークン形式の誤り
解決策: APIキー が有効であり、Authorization ヘッダーに正しい形式で設定されていることを確認してください。

403 Forbidden

考えられる原因:
  • API key に必要な権限が付与されていない
  • エンドポイントに対して誤ったキー種別を使用している(例: v3 エンドポイントに legacy key を使用している)
  • 許可スコープ外のリソースへアクセスしようとしている
解決策:
  • service user に正しいロールと権限が付与されていることを確認する
  • legacy v2 エンドポイントの場合: Enterprise Admin ロールを持っていることを確認する
  • legacy v1 エンドポイントの場合: 対象の組織(organization)へのアクセス権があることを確認する

404 Not Found

考えられる原因:
  • API エンドポイント URL が正しくない
  • リソースが存在しない、またはアクセス権限がない
解決方法: エンドポイント URL とリソースの存在を確認してください。

次のステップ