Kiro管理コンソールをCloudTrailで探ると統合基盤が垣間見えてきた

AWS の生成 AI コーディングアシスタント「Kiro」の Enterprise 向け機能として、2026年2月にユーザーアクティビティレポートが追加されました。このレポートを活用するにあたり、Kiro の管理コンソールに表示されるサブスクリプション情報を API で取得する方法を調査しました。管理コンソールの HTML ソースから通信先のエンドポイントを特定し、CloudTrail で実際の API 呼び出しを観測。発見した非公開 API に SigV4 署名でリクエストを送ったところ、Kiro と Q Developer を統合管理するサブスクリプション基盤の存在が見えてきました。

なお、本記事の検証は調査目的で期間限定で開設した AWS アカウント上で行っています。AdministratorAccess 権限を使用しており、永続運用を前提とした環境ではありません。

ダッシュボードの HTML ソースから手がかりを探す

まずはダッシュボードの HTML ソースを覗いてみます。ブラウザの開発者ツールで確認できる公開情報です。

CSP connect-src エンドポイント分析

Content Security Policy（CSP）の connect-src ディレクティブには、ダッシュボードが通信を許可されているエンドポイントが列挙されています。ブラウザの DevTools Console で amazonaws.com を含むエンドポイントだけを抽出すると、134個が見つかりました。

（キャプチャ: CSP connect-src から抽出した amazonaws.com エンドポイント一覧）

このうち、Kiro の管理に関連するエンドポイントを整理すると以下の通りです。

注目すべきは user-subscriptions です。17リージョンにエンドポイントが存在し、サブスクリプション管理の中核を担っていることが伺えます。しかし AWS の公式ドキュメントにはこのサービス名は登場しません。

内部コードネームの発見

HTML の meta[name="tb-data"] タグには、さらに興味深い情報が埋め込まれていました。

zornEndpoints、zornServicePrincipal というキーで zorn という文字列が登場します。user-subscriptions サービスの内部コードネームと推測されますが、この時点では正体がわかりません。もう1つ、tangerinebox という文字列も見つかりました。こちらは AWS コンソールのテレメトリ基盤です。

feature flags（33個）

meta[id="meta-features-json"] からは33個のフィーチャーフラグが見つかりました。全て enabled: true です。

Kiro 固有のフラグがたった2個しかありません。残りの31個は Q Developer やダッシュボード基盤のものです。Kiro が Q Developer の管理基盤をほぼそのまま共有していることを示唆しています。

CloudTrail で非公開 API を観測する

CSP 分析で通信先のサービスがわかったので、次は実際にどんな API が呼ばれているかを CloudTrail で確認します。

フィルタリング手法

AWS コンソールを開くと裏側で EC2 や ResourceGroup 等の大量の API が走るため、ノイズだらけになります。CSP 分析で通信先のサービス名がわかっているので、EventSource でフィルタしました。

aws cloudtrail lookup-events \
  --start-time "2026-02-18T18:28:00Z" \
  --end-time "2026-02-18T18:37:00Z" \
  --region us-east-1 \
  --output json \
  | jq '[.Events[] | select(.EventSource == "codewhisperer.amazonaws.com" or
    .EventSource == "user-subscriptions.amazonaws.com" or
    .EventSource == "q.amazonaws.com")]'

観測結果: 3サービス・14 API

ダッシュボードアクセス時（18:28-18:37 UTC）に39イベントを観測しました。うち Kiro 関連は3サービス14 API です。

codewhisperer.amazonaws.com（3 API）

user-subscriptions.amazonaws.com（3 API）

q.amazonaws.com（8 API）

SigV4 署名で API を呼び出す

なぜ普通に叩けないのか

通常の AWS サービスであれば aws <service> <operation> で呼び出せます。しかし user-subscriptions や q は AWS CLI にサービス定義が存在しない非公開サービスのため、CLI も SDK も使えません。

そこで、AWS の HTTP リクエスト認証の仕組みである SigV4（Signature Version 4） を自前で適用します。

通常: aws cli → SDK内部でSigV4署名 → HTTPリクエスト → AWSサービス
今回: Python → botocore.auth.SigV4Authで署名 → HTTPリクエスト → 非公開サービス

実装

パスベースの Coral API（POST /{OperationName} + JSON ボディ）として呼び出します。

from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest
import requests, json, boto3

session = boto3.Session(region_name='us-east-1')
creds = session.get_credentials().get_frozen_credentials()

url = "https://service.user-subscriptions.us-east-1.amazonaws.com/ListUserSubscriptions"
payload = json.dumps({
    "instanceArn": "arn:aws:sso:::instance/ssoins-XXXXXXXXXXXXXXXX",
    "maxResults": 1000,
    "subscriptionRegion": "us-east-1"
})

req = AWSRequest(method='POST', url=url, data=payload,
    headers={'Content-Type': 'application/json'})
SigV4Auth(creds, 'user-subscriptions', 'us-east-1').add_auth(req)
resp = requests.post(req.url, headers=dict(req.headers), data=req.body)
print(json.dumps(resp.json(), indent=2))

なお、14個の API のうち呼び出しに成功したのは user-subscriptions の ListUserSubscriptions のみでした。codewhisperer 系は 429 や UnknownOperation、q 系は 500 や UnknownOperation が返り、3サービスで異なる API プロトコルが混在していることがわかりました。

ListUserSubscriptions の実行結果

全ユーザーを横断取得

Kiro と Q Dev Pro の全ユーザーが1つのレスポンスで返ってきました。

KIRO_ENTERPRISE_PRO: 12ユーザー
  ACTIVE:   10人
  PENDING:   2人（未ログイン）

ダッシュボードの「User subscriptions」画面と完全に一致する情報です。Kiro 以外のサブスクリプションタイプ（Q_DEVELOPER_STANDALONE 等）も同じレスポンスに含まれていました。このアカウントの Identity Center には Kiro と Q Developer のサブスクリプションを登録していたため、両サービスの全ユーザー情報がまとめて返ってきた形です。

Kiro ユーザー一覧（マスク済み）

zorn の正体 — サブスクリプション統合基盤

HTML ソースから発見した謎の内部コードネーム zorn（zornEndpoints, zornServicePrincipal）の正体が、ここで明らかになりました。

zorn = user-subscriptions サービス。Kiro と Q Dev Pro のサブスクリプションを統合管理するバックエンド基盤でした。1つの API を叩くだけで、サービスの垣根を越えた全サブスクリプションが返ってきます。

CloudTrail の CreateAssignment / UpdateAssignment では Q_DEVELOPER_STANDALONE_PRO / Q_DEVELOPER_STANDALONE_PRO_PLUS という名前が使われるのに対し、ListUserSubscriptions では KIRO_ENTERPRISE_PRO という独自名が使われていました。同じサブスクリプションでも API 操作によって内部名が異なります。

Kiro と Q Developer のサブスクリプションの差異

レスポンスを比較すると、Kiro と Q Dev Pro のサブスクリプション体系にはいくつかの違いがありました。

Q Developer Pro には Q_DEVELOPER_BENEFIT という付帯サブスクリプションが自動付与されますが、Kiro ユーザーには付与されていません。Kiro と Q Dev Pro は別のサブスクリプション体系です。

割り当て方法を示す aggregatedSubscriptionType は、SSO グループ経由なら GROUP、個人割り当てとグループ割り当ての両方があれば INDIVIDUAL_AND_GROUP になります。後者は月末アップグレード記事で PRO → PRO+ に個人でアップグレードしたユーザーに該当します。

また、一部のサブスクリプションタイプでは lastActivityDate が記録されていましたが、Kiro ユーザー（KIRO_ENTERPRISE_PRO）は全員 null でした。Kiro 側の利用状況はこの API では追跡されていないようです。

Q_BUSINESS が全ユーザーに PENDING

Kiro のみ契約しているユーザーにも Q_BUSINESS: PENDING が割り当て済みでした。これは過去に Amazon Q Business の SSO 設定を試した際の残存データです。PENDING はライセンス枠が割り当て済みだがユーザーが一度もサービスにアクセスしていない状態を指します。

なぜ2つのサービスが共存しているのか

同一 Identity Center 内で Kiro と Q Dev Pro が共存し、1つの API で横断取得できるのは、CodeWhisperer → Q Developer → Kiro という段階的な移行に伴う仕様と推測されます。バックエンドの管理基盤（zorn）が複数のサブスクリプションタイプを統合管理しており、ダッシュボードの GUI だけがサービスごとに分離されている状態です。

まとめ

アーキテクチャの全体像

ダッシュボードの裏側では zorn（user-subscriptions）を中心に、codewhisperer、q の3サービスが連携する構成でした。

今回の検証は無保証の前提ですが、ListUserSubscriptions からコンソールの裏側にあるデータを直接確認でき、技術的な興味を満たす面白い結果となりました。

バックエンドでは Kiro と Q Developer Pro が統合されたデータ基盤（zorn）で管理されている仕組みが垣間見えたので、将来公式の管理 API が提供された際には、本記事で観測したデータ構造の答え合わせをしてみたいと思います。