Kiro 管理者向けのエンタープライズガバナンスおよび運用ガイド

所要時間8分

コンテンツレベル: 中級

この記事では Kiro Enterprise で用いられる概念、組織のガバナンス要件に従って Kiro を利用する際の主な考慮事項、および組織内で Kiro を設定・運用する方法について、Kiro 管理者向けのガイダンスを提供します。

本記事は Kiro Enterprise Governance and Operations Guide for Kiro Administrators の日本語訳です。

Kiro Enterprise では、AWS IAM Identity Center などの Identity プロバイダーを通じて組織内のユーザーサブスクリプション、アクセス制御、ガバナンス設定などを一元的に管理できます。
組織に Kiro を導入する場合、組織の管理者は、ユーザーが組織の要件に従って適切に Kiro を使用するための設定を理解しておくことが大切です。
この記事では、Kiro 管理者向けにこれらの設定をトピック別に説明します。

概念

Kiro では、ユーザーやリソースを管理するためにいくつかの概念があります。
このセクションでは、この記事で使用する概念について説明します。
Kiro で用いられる概念の一覧については Concepts を参照してください。

Kiro プロファイル

Kiro プロファイルは、特定の AWS アカウントとリージョンの Kiro Enterprise ユーザーのサブスクリプションや Kiro の設定を管理するための AWS リソースです。
Kiro プロファイルは、AWS アカウントおよびリージョンごとに 1 つだけ作成できます。つまり、同じアカウント内でも、リージョンごとに個別のプロファイルを作成できます。
ユーザー管理と Kiro 設定の構成は Kiro プロファイルごとに個別に行います。
また、Kiro の設定はプロファイルごとに個別に適用されるため、プロファイルごとに異なる設定を指定できます。
Kiro プロファイルはリージョンにつき 20 まで作成できます。

Kiro Enterprise ユーザー

Kiro Enterprise ユーザーは、Kiro コンソールを通じて Kiro のサブスクリプションティアが割り当てられたユーザーを指します。
Kiro Enterprise ユーザーは IAM Identity Center、または Okta、Microsoft Entra ID などの外部 Identity プロバイダーを通じて Kiro にアクセスできます。
この記事では、IAM Identity Center を利用して管理されるユーザーを対象とします。
AWS Builder ID または GitHub などのソーシャルログインプロバイダーを通じてサインインするユーザーは、有料サブスクリプションを利用している場合でも Kiro Enterprise ユーザーではなく個人サブスクライバーと見なされます。

Kiro 管理者

Kiro では、Kiro コンソールにアクセスが可能で、ユーザーのサブスクリプションと Kiro プロファイルの設定を管理できるユーザーが管理者と見なされます。
Kiro 管理者が使用する IAM アイデンティティには、Kiro コンソール上でユーザーサブスクリプションを管理し、Kiro 設定の操作を許可する IAM アクセス権限が必要です。
意図しない変更を防ぐため、Kiro 管理者と一般ユーザーの両方に適切な IAM アクセス許可を設定することが推奨されます。

ユーザーおよびグループのサブスクリプション

サブスクリプションは、IAM Identity Center のユーザーおよびグループに割り当てられます。
ここで注意しておきたいのは、Kiro ではグループサブスクリプションという概念は存在しないという点です。
グループをサブスクライブすると、そのサブスクリプションはグループ内の各ユーザーに適用されます。
このため、Kiro コンソールの Groups タブにはユーザーのサブスクリプションステータスは表示されません。
ユーザーのサブスクリプションステータスを確認するには、Subscriptions タブでサブスクリプションステータスを確認します。

Kiro 用に作成される IAM Identity Center の AWS マネージドアプリケーション

IAM Identity Center インスタンスを使用して Kiro をセットアップすると、ユーザーが Kiro を使用するための以下の AWS マネージドアプリケーションがインスタンス内に作成されます。
アプリケーション名には Kiro プロファイルを作成したリージョンが含まれます。

KiroProfile-[region]
Kiro Sign-In - KiroProfile-[region]

Kiro コンソールの Settings > Edit > Profile settings から、既存の Kiro プロファイルの名前を変更できます。
プロファイル名を変更すると対応する KiroProfile-[region] アプリケーション名も更新されますが、Kiro Sign-In - KiroProfile-[region] アプリケーション名は変更されません。

IAM Identity Center (IdC)

組織インスタンスとアカウントインスタンスの選択

Kiro ユーザー管理に IAM Identity Center を使用する場合、組織インスタンスまたはアカウントインスタンスのいずれかが選択できます。
組織インスタンスは、アカウントインスタンスの全ての機能に加えて組織全体の ID 管理機能を提供します。
これから組織全体に Kiro を展開する予定がある場合は組織インスタンスの使用を推奨します。

アカウントインスタンスを使用すると、組織インスタンスに関連付けられた Kiro プロファイルから独立した Kiro プロファイルを作成できます。
前述のとおり、Kiro コンソールで構成した設定は、Kiro プロファイルごとに個別に適用されます。
そのため、アカウントインスタンスを使用して Kiro プロファイルを作成することで、組織インスタンスに関連付けられたプロファイルに影響を与えることなく Kiro 設定の変更などをテストできます。

注意しておくべき点として、アカウントインスタンスから組織インスタンスへの変換、またはその逆に変換することはできません。
したがって、どちらのインスタンスで Kiro プロファイルを作成するかを決める前にユースケースを検討することを推奨します。

Kiro プロファイルと IAM Identity Center インスタンスのリージョン

Kiro では、Kiro プロファイルのリージョンと IdC のリージョンは別々に扱われ、両方のリージョンが一致している必要はありません。
Kiro プロファイルのリージョンと IdC のリージョンの一覧については、サポートされているリージョンを参照してください。

IAM Identity Center のリージョン： IAM Identity Center インスタンスを有効にしたリージョンです。このリージョンでユーザーのアイデンティティを管理します。
Kiro プロファイルのリージョン： Kiro プロファイルを作成したリージョンです。このリージョンにデータが保存されます。このリージョンは、IAM Identity Center インスタンスのリージョンと異なっていても問題ありません。

IdC を使用した Kiro のセットアップ

組織インスタンスを使用した Kiro のセットアップ (管理アカウント)

組織インスタンスを使用した Kiro のセットアップはシンプルです。
Kiro コンソールに移動し、Sign up for Kiro を選択してセットアップを開始します。

⚠️ 組織インスタンスがまだ作成されていない場合は、以下のメッセージが表示されます。この場合は IAM Identity Center コンソールで先に組織インスタンスを作成する必要があります。

Enter image description here

組織インスタンスが存在する場合は、次の画面が表示されます。Set up application as admin を選択してセットアップを完了します。

Enter image description here

Kiro コンソールにリダイレクトされたら、Manage users & groups (IAM Identity Center) に表示される ssoins-[your-id] の値が、IAM Identity Center インスタンス ID と一致することを確認します。

アカウントインスタンスを使用した Kiro のセットアップ (メンバーアカウント)

組織ですでに IdC 組織インスタンスを使用している場合でも、メンバーアカウントで Kiro をセットアップする際にアカウントインスタンスを使用して Kiro プロファイルを作成できます。
アカウントインスタンスを作成するには、まず組織インスタンスでアカウントインスタンスの作成を許可する必要があります。

メンバーアカウントでアカウントインスタンスを使用して Kiro プロファイルを作成する手順は次のとおりです。

Kiro コンソールのホームページに移動し、Onboard your team to Kiro を選択します。
Select your identity management source で、IAM Identity Center を選択します。
Set up application as admin を選択する代わりに、ユーザーの E メールアドレスを入力します。
1. アカウントインスタンスとそのユーザーがすでに存在する場合、Kiro のセットアップはそのまま完了します。
2. アカウントインスタンスが存在しない場合、Kiro はアカウントインスタンスと、入力した E メールアドレスを持つ IdC ユーザーを作成します。

Enter image description here

⚠️ 入力した E メールアドレスを持つ IdC ユーザーがアカウントインスタンスに存在しない場合、First/last name を入力すると、新しいユーザーが自動的に作成されます。

セットアップ中に Kiro がアカウントインスタンスを作成する場合、そのインスタンスは Kiro プロファイルと同じリージョンに作成されます。
別のリージョンにアカウントインスタンスを作成したい場合は、Kiro をセットアップする前にそのリージョンにアカウントインスタンスを作成しておく必要があります。

組織インスタンスとアカウントインスタンスの両方に同じ E メールアドレスのユーザーが存在する場合

組織インスタンスとアカウントインスタンスの両方に同じ E メールアドレスのユーザーが存在する場合、ユーザーの E メールアドレスを入力すると次の画面が表示されます。

Enter image description here

この場合、以下のように組織インスタンス・アカウントインスタンスのどちらを使って Kiro をセットアップするか選択できます。

Continue を選択すると、Kiro は組織インスタンスに関連付けられます。
Switch User を選択してセットアップを続行すると、Kiro はアカウントインスタンスに関連付けられます。

⚠️ 両方のインスタンスに同じ E メールアドレスのユーザーが存在するにもかかわらず上記の画面が表示されない場合は、ページの再読み込み、またはブラウザのキャッシュを削除をお試しください。

Kiro に関連するリソースが作成されるアカウント・リージョン

複数のリージョンまたはアカウントに Kiro プロファイルを作成する際は、次の点に留意してください。

各プロファイルでは、IdC ユーザーを個別にサブスクリプションに登録できます。
Kiro プロファイルは、Kiro をセットアップしたアカウントに作成されます。
AWS マネージドアプリケーションは、Kiro に関連付けられた IdC インスタンス内に作成されます。

どのリソースがどのリージョン・アカウントに作成されるかを理解しておくことが重要です。
ただし、構成によってはこれらの関係が少し複雑になることがあるため、次のような 2 つのシナリオで各リソースが作成されるリージョンを見ていきましょう。

シナリオ 1: 同じアカウント内に複数のプロファイルを作成する

ここでは以下のような状況を想定します。

アカウント A は AWS 組織の管理アカウントとします。
us-east-1 には、組織インスタンスと Kiro プロファイルがすでに作成されています。
組織インスタンスには、Kiro サブスクリプションが割り当てられた IdC ユーザー A が存在します。

この場合、アカウント A では eu-central-1 などの別のリージョンに新しい Kiro プロファイルを作成できます。
新しいリージョンで Kiro プロファイルを作成する際は、IAM Identity Center ではアカウントごとに作成できるインスタンスが 1 つに限られるため、Kiro のセットアップ時に既存の組織インスタンスを使用する必要があります。

eu-central-1 リージョンで Kiro コンソールを開き、セットアップを完了します。
これにより次のリソースが作成されます。

eu-central-1 リージョンの Kiro プロファイル。
IdC リージョン (us-east-1) の組織インスタンス内の AWS マネージドアプリケーション:
- KiroProfile-eu-central-1
- Kiro Sign-In - KiroProfile-eu-central-1

Kiro のセットアップが完了すると、eu-central-1 の Kiro プロファイルを使って組織インスタンス内のユーザーとグループをサブスクライブできるようになります。
us-east-1 のプロファイルで既にサブスクライブされている ユーザー A に対して、eu-central-1 の Kiro プロファイルを使って新規にサブスクライブすることも可能です。

IdC ユーザーを複数のプロファイルでサブスクライブする利点の 1 つは、クレジットプランの上限がプロファイルごとに個別に適用されることです。
us-east-1 の Kiro プロファイルでログインした際に使用したクレジットは、eu-central-1 の Kiro プロファイルでサブスクライブしている Kiro サブスクリプションのクレジット使用量にはカウントされません。
このように、同じユーザーを複数のプロファイルでサブスクライブすると、ユーザーはユースケースに応じてプロファイルを切り替えて使用することができます。
ただし、同じユーザーを 2 つのプロファイルでサブスクライブすると、両方のサブスクリプションに対して料金が発生することに注意してください。

シナリオ 2: メンバーアカウントに Kiro プロファイルを作成する

次に、上記の組織に属する メンバーアカウント B の us-east-1 で Kiro をセットアップする場合を考えます。
この場合、既存の組織インスタンスを使用するか、アカウント B に新しいアカウントインスタンスを作成して Kiro に関連付けるかの 2 つの選択肢があります。
この例では、アカウント A の既存の組織インスタンスを使用しましょう。

アカウント B で us-east-1 リージョンの Kiro コンソールでセットアップを完了すると次のリソースが作成されます。

メンバーアカウント B の us-east-1 リージョンの Kiro プロファイル。
IdC リージョンの組織インスタンス内の AWS マネージドアプリケーション:
- KiroProfile-us-east-1
- Kiro Sign-In - KiroProfile-us-east-1

AWS マネージドアプリケーションは Kiro プロファイルごとに作成されることに注意してください。
管理アカウントの アカウント A の IdC コンソールを確認すると、同名のアプリケーションが作成され、それぞれの Owning account ID の値が アカウント A と アカウント B に対応していることを確認できます。

セットアップが完了すると、組織インスタンスの IdC ユーザーを、アカウント B の Kiro プロファイルでサブスクライブできます。
もちろん、このプロファイルで ユーザー A をサブスクライブすることもできます。

最後に、テストの目的で、アカウント B のアカウントインスタンスを使用して eu-central-1 に Kiro をセットアップする場合を考えましょう。
アカウント B で eu-central-1 リージョンの Kiro コンソールでセットアップを完了すると、次のリソースが作成されます。

メンバーアカウント B の eu-central-1 リージョンの Kiro プロファイル。
IdC リージョンの アカウントインスタンス 内の AWS マネージドアプリケーション:
- KiroProfile-eu-central-1
- Kiro Sign-In - KiroProfile-eu-central-1

アプリケーションは組織インスタンスではなくアカウントインスタンス内に作成されます。
IdC ユーザーはアカウントインスタンス内で個別に管理されるため、IdC ユーザーと Kiro サブスクリプションを組織インスタンスとは別に管理できます。

Kiro のセットアップ時に既存の IAM Identity Center インスタンスが検出されないのはなぜですか?

IdC インスタンスがすでに存在するアカウントで Kiro をセットアップすると、その既存のインスタンスに接続するオプションが表示されます。
このオプションが表示されない場合、セットアップに使用している IAM アイデンティティに Kiro プロファイルの作成に必要なアクセス許可がない可能性があります。
これらのアクセス許可がない、または必要なアクションの一部が AWS organizations のサービスコントロールポリシー (SCP) によって拒否されている場合、そのインスタンスは検出されません。

どのアクションが拒否されているかを確認するには、ブラウザの開発者ツールが有用です。

ブラウザの開発者ツールを開き、Network タブに移動します。
ネットワークログをクリアして記録を開始します。
Kiro のセットアップを進めます。
Status 列で、失敗したリクエスト、またはステータスコードが 4xx か 5xx のリクエストを確認します。
リクエストをクリックし、Preview または Response タブを確認してエラーの原因を調査します。

例えば、次のネットワークログエントリは組織内の SCP が sso:ListInstances を拒否しているため、組織インスタンスを検出できないことを示しています。

{"__type":"AccessDeniedException","Message":"User: arn:aws:iam::[Account ID]:[IAM Identity] is not authorized to perform: sso:ListInstances on resource: arn:aws:sso:::instance/* with an explicit deny in a service control policy: arn:aws:organizations::[Account ID]:policy/[Organization ID]/service_control_policy/[Policy ID]"}

グループに割り当てたサブスクリプションがユーザーのステータスに反映されないのはなぜですか?

Kiro サブスクリプションがすでに割り当てられているグループにユーザーを追加した場合、Kiro コンソールのサブスクリプションステータスに反映されるまでに最大 24 時間かかることがあります。
一方、すでにユーザーが存在するグループを新規にサブスクライブした場合、通常は短時間で反映されます。

アクセス制御

サブスクリプションを割り当て可能なユーザーを制限する

サブスクリプションを割り当て可能なユーザーを制限したい場合、そのユーザーが使用する IAM アイデンティティまたはアクセス許可セットに、q:CreateAssignment を拒否する IAM ポリシーをアタッチします。
AWS organizations 全体で同様の制限をする場合、q:CreateAssignment を拒否する SCP が利用できます。

Builder ID とソーシャルログインをブロックする (IAM Identity Center によるサインインのみを許可する)

AWS Builder ID とソーシャルログインでは、それぞれ次のエンドポイントを使用します。

AWS Builder ID: https://view.awsapps.com/start
ソーシャルログイン: https://kiro-prod-us-east-1.auth.us-east-1.amazoncognito.com

Kiro 利用者に IAM Identity Center 経由でのサインインを必須とさせたい場合、プロキシやファイアウォールといったご利用の組織のネットワーク制御を構成して、これらのエンドポイントをブロックします。
なお、これらのエンドポイントをブロックすると Builder ID およびソーシャルログインによる新規サインインは防ぎますが、すでにサインイン済みのユーザーは引き続き使用できることに注意してください。

⚠️ view.awsapps.com をブロックすると、Amazon QuickSight など、Builder ID を使用する他のサービスにも影響が発生する可能性があります。このエンドポイントをブロックする前に、サービスへの影響を確認してください。

特定のドメインに対する `web_fetch` を許可または拒否する

Kiro IDE v1 および Kiro CLI v3 では、ドメインごとに web_fetch へのアクセスを制御できる capability ベースのアクセス許可（Permission）が導入されました。
次のアクセス許可の例では、docs.aws.amazon.com へのアクセスは許可、kiro.dev へのアクセスはユーザー確認を求め、aws.amazon.com へのアクセスを拒否します。

rules:
  - capability: web_fetch
    effect: allow
    match:
      - docs.aws.amazon.com
  - capability: web_fetch
    effect: ask
    match:
      - kiro.dev
  - capability: web_fetch
    effect: deny
    match:
      - aws.amazon.com

アクセス許可の完全な構文については Kiro ドキュメントの Permission を参照してください。
また、アクセス許可を使用するには各クライアントに構成ファイルを配置する必要があります。

Webtool を制限する

Kiro コンソールで Web search and web fetch tools をオフにすると、クライアントレベルで web_search と web_fetch の使用が制限されます。
Web search and web fetch tools の設定はデフォルトで有効になっており、Kiro プロファイルごとに適用されます。

また、capability ベースのアクセス許可ルールで両方のツールを effect: deny に設定することでブロックする方法もあります。

rules:
  - capability: web_fetch
    effect: deny
  - capability: web_search
    effect: deny

ただし、アクセス許可ルールは各クライアントで構成する必要があるため、プロファイルのすべてのユーザーにこの制限を適用するには Kiro コンソールの設定を使用することを推奨します。

組織承認済みの MCP サーバーのみを許可する

デフォルトでは、ユーザーは Kiro クライアントで任意の MCP サーバーを使用できます。
ユーザーの MCP サーバーの使用を制限したい場合、MCP を完全に無効にするか、MCP レジストリで承認済みの MCP サーバーの一覧を指定する方法があります。

MCP を完全に無効にする

MCP を完全に無効にする場合、Kiro コンソールで Settings > Shared settings に移動し、Model Context Protocol (MCP) を Off に切り替えます。
MCP を Off にすると、クライアント側ではすべての MCP サーバーが無効となり、エージェントでは MCP ツールを利用できなくなります。
/mcp コマンドには MCP has been disabled by your administrator と表示されます。

MCP レジストリ許可リストを指定する

ユーザーが使用できる MCP サーバーを制御するには、許可するサーバーを一覧にした JSON ファイル（許可リスト）を作成し、そのファイルを HTTPS 経由で提供して URL を Kiro プロファイルに追加します。

Kiro コンソールを開きます。
Settings を選択します。
Shared settings で、Model Context Protocol (MCP) が On であることを確認します。
MCP Registry URL フィールドで、Edit を選択します。
MCP レジストリの JSON ファイルの URL を入力します。
Save を選択します。

許可リストを有効にすると、その Kiro プロファイルを使用するすべてのユーザーに適用されます。
本番環境の適用前に動作を確認したい場合、テスト用の AWS アカウントにアカウントインスタンスと Kiro プロファイルを作成し、そこで MCP レジストリ URL を指定する方法があります。
MCP レジストリ設定は Kiro プロファイルごとに適用されるため、プロファイルを分けることで他のプロファイルに影響を与えずに動作を検証できます。

API キー

API キーは CI/CD パイプラインや自動化スクリプトでヘッドレス認証を行うために使用されます。
このセクションでは、API キーを適切に管理するために必要な事項について説明します。

API キーを作成する

Kiro プロファイルで API キーの生成が有効になっている場合、Kiro サブスクリプションを持つすべてのユーザーが API キーを作成できます。
API キーは、ユーザーおよび Kiro プロファイルに固有となっています。
別のユーザーが作成した API キーは表示されず、同じユーザーが異なる Kiro プロファイルで作成したキーはプロファイル別に保持されます。
Kiro 管理者であっても別のユーザーのキーを一覧表示することはできません。

API キーを無効にする

ユーザーが API キーを生成できないようにするには、Kiro コンソールで Enable users to generate API keys をオフにします。
API キーを無効にするとユーザーは新しい API キーを生成できなくなり、既存のすべての API キーも無効になります (反映されるまでには時間がかかります)。
これは Kiro プロファイル全体に適用されます。プロファイル内の一部のユーザーに対してのみ API キーを無効にすることはできません。
一部のユーザーにのみ API キーを許可するには、別の Kiro プロファイルに対象ユーザーを分離することを検討してください。

API キー使用時のクレジット消費

Kiro は API キーを作成したユーザーに関連付けます。
キーを使用して消費されたクレジットは、そのキーを作成したユーザーのサブスクリプションクレジットから差し引かれます。
ユーザーがクレジット上限に達すると、Overages が有効になっている場合を除き、そのユーザーのキーは使用できなくなります。

API キーが漏洩した場合の対処方法

API キーが漏洩した場合、キーを生成したユーザーに、Kiro Web 上でそのキーを削除して代わりのキーを生成するよう依頼してください。
API キーは自動的には失効せず、キーを削除できるのはそのキーを生成したユーザーだけです。
何らかの理由でユーザーがキーを削除できない場合は、代わりに IdC ユーザーを無効にする方法もあります。
ただし、この方法では反映されるまでには時間がかかるため、キーを直接削除することを推奨します。

データ管理

Kiro はさまざまな種類のデータを処理します。
データを適切に管理するには、データがどのように処理・保存されるかを理解することが重要です。

データの保管

Kiro はリクエストに対して新しい返信を作成するために、質問、応答、コードなどの追加コンテキスト、およびリクエストのメタデータを保存します。
状況によっては、不正使用の検出のためにデータを保存します。
また、Kiro コンソールでプロンプトログまたはユーザーアクティビティレポートを有効にすると、Kiro はレポートとログイベントを配布するために必要なデータも保存します。
Kiro Enterprise ユーザーの場合、これらのデータはサービス改善には使用されません。

テレメトリとコンテンツ収集

テレメトリには、使用状況データ、エラー、クラッシュレポート、パフォーマンスメトリクス等が含まれます。
Kiro Enterprise ユーザーの場合、サービス改善を目的としたテレメトリおよびコンテンツ収集は自動的にオプトアウトされます。
この設定をオプトアウトしても、Kiro コンソールでユーザーアクティビティレポート有効・無効化の設定には影響はありません。
テレメトリで収集されるデータの詳細については、収集されるテレメトリの種類を参照してください。

クロスリージョン推論でデータが処理されるリージョン

Kiro は Amazon Bedrock を基盤としており、クロスリージョン推論を使用して AWS リージョン間にトラフィックを分散し、推論のパフォーマンスと信頼性を向上させます。
クロスリージョン推論はデフォルトで有効になっており、無効にすることはできません。

重要なのは、クロスリージョン推論によってデータの保存先が変わることはないという点です。
Kiro が別のリージョンでリクエストを処理する場合でも、データは Kiro プロファイルのリージョンに保存されます。

Global クロスリージョン推論

実験的 (experimental) と表示されているモデルおよび capability については、Kiro がGlobal クロスリージョン推論を使用して、パフォーマンス、スループット、キャパシティの可用性を向上させる場合があります。
これらのモデルおよび capability に対する推論リクエストは、Kiro プロファイルのリージョン以外も含め、世界中の商用 AWS リージョンで処理される場合があります。
クロスリージョン推論と同様に、Global クロスリージョン推論はデータの保存先リージョンに影響しません。つまり、データは Kiro プロファイルのリージョンに保存されます。
Global クロスリージョン推論を無効化したい場合、experimental モデルおよび capability の使用を避けるようにしてください。

不正使用の検出

Kiro は Amazon Bedrock を使用するため、Bedrock の不正検出メカニズムが Kiro におけるすべてのモデル利用に適用されます。
それに加えて、Kiro は不正使用の検出のために次の機能を提供します。

Kiro Free Tier ユーザーに限り、Kiro はサービス利用規約または利用ポリシーに違反するアクティビティを検出するために、入力を最大 60 日間保存する場合があります。これは Kiro Enterprise ユーザーには適用されません。
OpenAI GPT モデルについては、分類子フラグ付きトラフィックは自動化されたオフライン不正使用検出のために最大 30 日間保持されます。トラフィックは、推論リクエストが処理されたリージョンに保存されます。これは Kiro Enterprise ユーザーにも適用されます。

コードリファレンス

Kiro は、オープンソースプロジェクトも学習元の一部としています。
そのため、Kiro が提案するコードが公開されているコードと類似する場合があります。
Kiro IDE では、コードリファレンスログによって公開されているコードと類似する提案を確認できます。
Kiro 管理者は、Kiro コンソールでリファレンスを伴うコード提案をオフにできます。
他のコンソール設定と同様に、この設定は Kiro プロファイルごとに適用されます。

カスタマーマネージドキー (CMK) で Kiro プロファイルを暗号化する

Kiro はデフォルトで AWS Key Management Service (AWS KMS) の AWS 所有キーを使用して保存データを暗号化しますが、データ暗号化に CMK を使用することもできます。
Kiro 管理者は、Kiro コンソールで Kiro プロファイル用の CMK を設定できます。
CMK は次の要件を満たす必要があります。

対称キーのみがサポートされます。
キーを構成する IAM プリンシパルに、IAM アクセス許可が設定されている必要があります。
q.amazonaws.com が次のアクションを実行できるようにキーポリシーを設定する必要があります。

{
      "Effect": "Allow",
      "Principal": {
        "Service": "q.amazonaws.com"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:GenerateDataKey*",
        "kms:DescribeKey",
        "kms:CreateGrant"
      ],
      "Resource": "*"
    }

CMK を設定するには、Kiro プロファイルの Settings を開き Encryption key を有効にして、既存の CMK を選択する、もしくは新しい CMK を作成します。
設定後に Kiro が指定した CMK を使用していることを確認したい場合、MCP Registry URL に URL を入力してプロファイルを更新し、AWS CloudTrail で Decrypt API コールを検索します。
CloudTrail イベントの詳細より、userAgent が q.amazonaws.com であること、および requestParameters.keyId がキーの ARN と一致することが確認できます。
これらの値は、Kiro がキーを使用して MCP Registry URL を復号したことを示しています。

  "userAgent": "q.amazonaws.com",
  "requestParameters": {
    "encryptionAlgorithm": "SYMMETRIC_DEFAULT",
    "keyId": "arn:aws:kms:<region>:<account-id>:key/<your-key-id>"
    ...
  }

⚠️ MCP Registry URL を指定すると、上述した通りユーザーが利用できる MCP サーバーが制限される点に注意してください。Decrypt API コールを確認できたら、忘れずに URL をクリアして制限を解除してください。

CMK の対象外となるデータ

Kiro でプロンプトログ・ユーザーアクティビティレポートを有効化すると、指定した S3 バケットにそれぞれのデータが記載されたファイルを保存します。
Kiro プロファイルに構成した CMK ではこれらのファイルは暗号化されません。
S3 は、デフォルトでサーバー側の暗号化を使用してこれらを暗号化します。
これらのファイルも CMK で暗号化したい場合には、Kiro プロファイルの CMK とは別に送信先 S3 バケットに CMK を設定する必要があります。

モデル

モデルとして Auto を選択した場合、Kiro は許可リストにあるモデルのみを使用しますか?

いいえ。
モデルで Autoが選択されている場合、Kiro は、許可リストにあるモデルだけでなく、Kiro プロファイルのリージョンで利用可能な他のモデルにもリクエストをルーティングする場合があります。
使用するモデルを厳密に制御したい場合には、許可リストから Auto を除外し、許可する特定のモデルのみを含めます。

特定のリージョンで利用できないモデルがある

モデルの可用性は国やリージョンによって異なる場合があります。
モデルごとの可用性や使用できるリージョンについては Modelを参照してください。

その他

ユーザーのクレジット消費量を追跡する

Kiro ではユーザーのクレジット消費量を確認する方法をいくつか提供しています。
ダッシュボードの Credits consumed メトリクスは、サブスクリプションティア別の使用量を追跡するのに役立ちます。このメトリクスは 1 時間ごとに更新されます。
ユーザーごとの内訳を確認したい場合は、ユーザーアクティビティレポートを有効にして、S3 バケットに保存される CSV ファイルの Credits_Used 列を確認します。
UserId 列と User_Email 列には、それぞれ IAM Identity Center のユーザー ID と E メールアドレスに対応します。

Kiro について公開されている SLA はありますか?

Kiro には SLA がありません。
Kiro の使用には、Kiro ライセンスに記載されているとおり、AWS カスタマーアグリーメントおよび AWS サービス条件が適用されます。

トピック: セキュリティ、アイデンティティ、コンプライアンス開発者用ツール AWSでのジェネレーティブAI
タグ: AWS IAM アイデンティティセンター Kiro
言語: 日本語

サポートエンジニア

Ogawa_F

公開済み 1ヶ月前122ビュー

コメントはありません

Kiro 管理者向けのエンタープライズガバナンスおよび運用ガイド

概念

Kiro プロファイル

Kiro Enterprise ユーザー

Kiro 管理者

ユーザーおよびグループのサブスクリプション

Kiro 用に作成される IAM Identity Center の AWS マネージドアプリケーション

IAM Identity Center (IdC)

組織インスタンスとアカウントインスタンスの選択

Kiro プロファイルと IAM Identity Center インスタンスのリージョン

IdC を使用した Kiro のセットアップ

組織インスタンスを使用した Kiro のセットアップ (管理アカウント)

アカウントインスタンスを使用した Kiro のセットアップ (メンバーアカウント)

Kiro に関連するリソースが作成されるアカウント・リージョン

シナリオ 1: 同じアカウント内に複数のプロファイルを作成する

シナリオ 2: メンバーアカウントに Kiro プロファイルを作成する

Kiro のセットアップ時に既存の IAM Identity Center インスタンスが検出されないのはなぜですか?

グループに割り当てたサブスクリプションがユーザーのステータスに反映されないのはなぜですか?

アクセス制御

サブスクリプションを割り当て可能なユーザーを制限する

Builder ID とソーシャルログインをブロックする (IAM Identity Center によるサインインのみを許可する)

特定のドメインに対する web_fetch を許可または拒否する

Webtool を制限する

組織承認済みの MCP サーバーのみを許可する

API キー

API キーを作成する

API キーを無効にする

API キー使用時のクレジット消費

API キーが漏洩した場合の対処方法

データ管理

データの保管

テレメトリとコンテンツ収集

クロスリージョン推論でデータが処理されるリージョン

Global クロスリージョン推論

不正使用の検出

コードリファレンス

カスタマーマネージドキー (CMK) で Kiro プロファイルを暗号化する

モデル

モデルとして Auto を選択した場合、Kiro は許可リストにあるモデルのみを使用しますか?

特定のリージョンで利用できないモデルがある

その他

ユーザーのクレジット消費量を追跡する

Kiro について公開されている SLA はありますか?

関連するコンテンツ

特定のドメインに対する `web_fetch` を許可または拒否する