翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # AWS DevOps Agent の機能の設定 AWS DevOps エージェント機能は、エージェントの機能を既存のツールやインフラストラクチャに接続することで拡張します。これらの機能を設定して、包括的なインシデント調査、自動対応ワークフロー、DevOps エコシステムとのシームレスな統合を可能にします。 以下の機能は、DevOps エージェントの有効性を最大化するのに役立ちます。 + **AWS EKS アクセスセットアップ** - パブリック EKS 環境とプライベート EKS 環境の両方で、Kubernetes クラスター、ポッドログ、クラスターイベントのイントロスペクションを有効にします。 + **Azure 統合** - Azure サブスクリプションと Azure DevOps 組織を接続して Azure リソースを調査し、Azure DevOps デプロイをインシデントに関連付ける + **CI/CD パイプライン統合** - GitHub パイプラインと GitLab パイプラインを接続してデプロイをインシデントと関連付け、調査中のコード変更を追跡する + **MCP サーバー接続** - Model Context Protocol を使用して外部オブザーバビリティツールとカスタムモニタリングシステムを接続することで調査機能を拡張 + **マルチアカウント AWS アクセス** - インシデント対応中に組織全体のリソースを調査するようにセカンダリ AWS アカウントを設定する + **Telemetry Source Integration** - Datadog、Dynatrace、Grafana、New Relic、Splunk などのモニタリングプラットフォームを接続して、包括的なオブザーバビリティデータアクセスを実現 + **チケット作成とチャット統合** - ServiceNow、PagerDuty、Slack を接続してインシデント対応ワークフローを自動化し、チームのコラボレーションを可能にする + **Webhook 設定** - 外部システムが HTTP リクエストを通じて DevOps エージェント調査を自動的にトリガーできるようにします。 + **Amazon EventBridge 統合** - 調査と緩和ライフサイクルイベントを Amazon EventBridge ターゲットにルーティングすることで、 AWS DevOps エージェントをイベント駆動型アプリケーションに組み込みます。 チーム固有のニーズと既存のツールスタックに基づいて、各機能を個別に設定できます。インシデント対応ワークフローにとって最も重要な統合から開始し、必要に応じて追加機能に拡張します。 # パブリックプレビューから一般提供への移行 パブリックプレビュー中に AWS DevOps エージェントを使用した場合は、GA リリース前に IAM ロールを更新する必要があります。このガイドでは、アカウントのモニタリングロールとオペレーターロールの更新について説明します。 ## 変更点 1. [プレビュー中のオンデマンドチャット履歴にアクセスできなくなります](#on-demand-chat-history-from-public-preview) 1. [新しい マネージドポリシーは、プレビュー中に利用可能なポリシーを置き換えます](#new-managed-policies) 1. [エージェントスペースには、古い IAM Identity Center アプリケーションアクセススコープがある可能性があります](#reconnect-iam-identity-center-if-applicable) ## パブリックプレビューからのオンデマンドチャット履歴 GA リリースでは、チャット履歴のアクセスコントロールを強化するための追加のセキュリティ対策が導入されています。これらの変更により、パブリックプレビュー期間 (2026 年 3 月 30 日以前) のオンデマンドチャット履歴にアクセスできなくなります。公開プレビュー中に作成された調査ジャーナルや調査結果は影響を受けません。**この変更は、オンデマンドチャット会話にのみ適用されます。** ## 新しい管理ポリシー GA の場合、 はプレビュー時代のポリシーを置き換える新しい管理ポリシー AWS を提供します。 | ロールタイプ | 削除 | Add | | --- | --- | --- | | モニタリング | AIOpsAssistantPolicy マネージドポリシー | AIDevOpsAgentAccessPolicy マネージドポリシー | | オペレーター (IAM および IDC) | インラインポリシー | AIDevOpsOperatorAppAccessPolicy マネージドポリシー | さらに、オペレータロールには更新された信頼ポリシーが必要であり、IDC オペレータロールには新しいインラインポリシーが必要です。 ### 前提条件 + DevOps エージェントロールが設定されている AWS アカウントへのアクセス (プライマリアカウントとすべてのセカンダリアカウント) + ロール、ポリシー、信頼関係を変更する IAM アクセス許可 + エージェントスペース ID、 AWS アカウント ID、リージョン (DevOps エージェントコンソールで表示) ### ステップ 1: モニタリングロールを更新する プライマリアカウントと各セカンダリアカウントのモニタリングロールを更新します。これらは、エージェントスペースの **Capabilities** タブで設定されたプライマリ/セカンダリソースロールです (プライマリ/セカンダリロールの例: `DevOpsAgentRole-AgentSpace-3xj2396z`)。 1. DevOps エージェントコンソールで、エージェントスペースに移動し、**機能**タブを選択します。 1. プライマリ/セカンダリソース ( など`DevOpsAgentRole-AgentSpace-3xj2396z`) のモニタリングロールを見つけ、**編集**を選択します。 1. アクセス**許可ポリシー**で、 `AIOpsAssistantPolicy` AWS 管理ポリシーを削除します。 1. アクセス**許可の追加**、**ポリシーのア**タッチ、`AIDevOpsAgentAccessPolicy`管理ポリシーのアタッチを選択します。 1. インラインポリシーを編集し、その内容を以下に置き換えて、アカウント ID を置き換えます。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCreateServiceLinkedRoles", "Effect": "Allow", "Action": [ "iam:CreateServiceLinkedRole" ], "Resource": [ "arn:aws:iam:::role/aws-service-role/resource-explorer-2.amazonaws.com/AWSServiceRoleForResourceExplorer" ] } ] } ``` 1. モニタリングロールの信頼ポリシーは変更を必要としません。以下と一致することを確認します。 ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "aidevops.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "" }, "ArnLike": { "aws:SourceArn": "arn:aws:aidevops:::agentspace/*" } } } ] } ``` + 各セカンダリアカウントのモニタリングロールに対してステップ 2～6 を繰り返します。 ### ステップ 2: オペレーターロールを更新する (IAM) 1. DevOps エージェントコンソールで、**アクセス**タブを選択し、オペレーターロールを見つけます。 1. IAM コンソールで、オペレーターロールから既存のインラインポリシーを削除します。 1. アクセス**許可の追加**、**ポリシーのアタッチ**、`AIDevOpsOperatorAppAccessPolicy`管理ポリシーのアタッチを選択します。 1. **信頼関係**タブを選択し、**信頼ポリシーの編集**を選択します。信頼ポリシーを以下に置き換え、アカウント ID、リージョン、エージェントスペース ID を置き換えます。 ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "aidevops.amazonaws.com" }, "Action": ["sts:AssumeRole", "sts:TagSession"], "Condition": { "StringEquals": { "aws:SourceAccount": "" }, "ArnEquals": { "aws:SourceArn": "arn:aws:aidevops:::agentspace/" } } } ] } ``` ### ステップ 3: オペレーターロールを更新する (IDC) DevOps エージェントで IAM Identity Center を使用する場合は、各 IDC オペレーターロールを更新します。 1. IAM コンソールで、 **ロール**に移動し、 を検索`WebappIDC`して DevOps エージェント IDC ロール ( など) を検索します`DevOpsAgentRole-WebappIDC-`。 1. 各 IDC ロールについて: a. 既存のインラインポリシーを削除します。 b. アクセス**許可の追加**、**ポリシーのアタッチ**、`AIDevOpsOperatorAppAccessPolicy`管理ポリシーのアタッチを選択します。 c。**信頼関係**タブを選択し、**信頼ポリシーの編集**を選択します。信頼ポリシーを以下に置き換え、アカウント ID、リージョン、エージェントスペース ID を置き換えます。 ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "aidevops.amazonaws.com" }, "Action": ["sts:AssumeRole", "sts:TagSession"], "Condition": { "StringEquals": { "aws:SourceAccount": "" }, "ArnEquals": { "aws:SourceArn": "arn:aws:aidevops:::agentspace/" } } }, { "Sid": "TrustedIdentityPropagation", "Effect": "Allow", "Principal": { "Service": "aidevops.amazonaws.com" }, "Action": "sts:SetContext", "Condition": { "StringEquals": { "aws:SourceAccount": "" }, "ArnEquals": { "aws:SourceArn": "arn:aws:aidevops:::agentspace/" }, "ForAllValues:ArnEquals": { "sts:RequestContextProviders": [ "arn:aws:iam::aws:contextProvider/IdentityCenter" ] }, "Null": { "sts:RequestContextProviders": "false" } } } ] } ``` d。アカウント ID を置き換えて、次のアクセス許可を持つ新しいインラインポリシーを作成します。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowDevOpsAgentSSOAccess", "Effect": "Allow", "Action": [ "sso:ListInstances", "sso:DescribeInstance" ], "Resource": "*" }, { "Sid": "AllowDevOpsAgentIDCUserAccess", "Effect": "Allow", "Action": "identitystore:DescribeUser", "Resource": [ "arn:aws:identitystore:::identitystore/*", "arn:aws:identitystore:::user/*" ] } ] } ``` ## IAM アイデンティティセンターを再接続する (該当する場合) パブリックプレビュー中に作成されたエージェントスペースには、IAM Identity Center アプリケーションが古いアクセススコープで設定されている場合があります。GA の場合、正しいスコープは です**`aidevops:read_write`**。IAM Identity Center アプリケーションに以前のスコープ (**`awsaidevops:read_write`**) がある場合は、IAM Identity Center を切断して再接続する必要があります。 ### IAM Identity Center アプリケーションの範囲を確認する方法 次の AWS CLI コマンドを実行して、IAM Identity Center アプリケーションのスコープを確認します。アプリケーション ARN は、**「アプリケーション**」の IAM Identity Center コンソールにあります。 ``` aws sso-admin list-application-access-scopes \ --application-arn arn:aws:sso:::application// ``` 出力には正しいスコープ が表示されます**`aidevops:read_write`**。 ``` { "Scopes": [ { "Scope": "aidevops:read_write" } ] } ``` スコープに が表示されている場合は**`awsaidevops:read_write`**、古いものです。以下の手順に従って更新します。 ### IAM Identity Center を再接続する方法 AWS マネージド IAM アイデンティティセンターアプリケーションのアクセススコープを直接更新することはできません。切断して再接続する必要があります。 1. AWS DevOps エージェントコンソールで、エージェントスペースに移動し、**アクセス**タブを選択します。 1. IAM Identity Center 設定の横にある**切断**を選択します。 1. 切断を確認します。 1. **Connect** を選択して、IAM Identity Center を再度セットアップします。サービスは、正しいスコープを持つ新しい IAM Identity Center アプリケーションを作成します。 1. IAM Identity Center コンソールでユーザーとグループを新しいアプリケーションに再割り当てします。 **重要** 切断すると、IAM Identity Center ユーザーアカウントに関連付けられた個々のユーザーチャットとアーティファクト履歴が削除されます。ユーザーは再接続後に再度ログインする必要があります。 ## 検証 すべてのステップを完了した後: 1. DevOps エージェントコンソールに戻り、エージェントスペース**アクセス**タブにアクセス許可エラーが表示されないことを確認します。 1. オペレーターウェブアプリをテストして、正しくロードおよび機能することを確認します。 1. IDC を使用する場合は、ユーザーがオペレーターエクスペリエンスを認証してアクセスできることを確認します。 ## トラブルシューティング **移行後のアクセス許可拒否エラー** + `AIOpsAssistantPolicy` が削除され、モニタリングロールにアタッチ`AIDevOpsAgentAccessPolicy`されていることを確認します。 + 古いインラインポリシーが削除され、オペレーターロールに`AIDevOpsOperatorAppAccessPolicy`アタッチされていることを確認します。 + 演算子の信頼ポリシーに が含まれていることを確認します`sts:TagSession`。 + すべてのプレースホルダー値 (``、``、``) を実際の値に置き換えたことを確認します。 **セカンダリアカウントが機能しない** + 各セカンダリアカウントのモニタリングロールは個別に更新する必要があります。各アカウントにログインし、ステップ 1 を繰り返します。 **IDC 認証の失敗** + IDC 信頼ポリシーに `sts:AssumeRole`/`sts:TagSession` ステートメントと `TrustedIdentityPropagation`ステートメントの両方が含まれていることを確認します。 + インラインポリシーが `sso:ListInstances`、`sso:DescribeInstance`、および で作成された`identitystore:DescribeUser`ことを確認します。 **移行後にオンデマンドチャット履歴が欠落している** + GA リリース後は、パブリックプレビュー期間のオンデマンドチャット履歴にアクセスできません。これは、GA で導入されたセキュリティ対策の強化による予想される動作です。調査ジャーナルやパブリックプレビューの結果は影響を受けません。 # AWS EKS アクセス設定 AWS DevOps Agent は、パブリッククラスターとプライベートクラスターの両方に対して読み取り専用`kubectl`コマンドを実行して、Amazon EKS クラスターの問題を調査することができます。任意の数の EKS クラスターを同じエージェントスペースに接続できます。 接続すると、エージェントはリソースの説明、ポッドログの取得、クラスターイベントの検査、ノードの状態の確認など、クラスターの運用上の問題の診断に役立ちます。エージェントは、クラスター内のリソースを作成、変更、または削除することはできません。 ## 前提条件 EKS アクセスを設定する前に、EKS クラスターの認証モードに EKS API が含まれていることを確認してください。これは、[Amazon EKS コンソール](https://console.aws.amazon.com/eks)の**アクセス**タブで確認できます。モードに EKS API が含まれていない場合は、続行する前に が実行するモードを選択します。 ## セットアップ これらのステップは、アクセスエントリを作成するクラスターごとに [Amazon EKS コンソール](https://console.aws.amazon.com/eks)から完了する必要があります。IAM ロール ARN は、エージェントスペース (「」を参照[エージェントスペースの作成](getting-started-with-aws-devops-agent-creating-an-agent-space.md)) の**「機能 > クラウド > プライマリソース > 編集**」にあります。 1. **アクセス**タブに移動します。認証モードがすでに EKS API と表示されている場合は、アクセスエントリを追加できます。それ以外の場合は、EKS API を含むモードを選択します。 1. アクセスタブから、新しい IAM アクセスエントリを作成します。プライマリクラウドソースの IAM ロール ARN をコピーし、アクセスエントリの IAM プリンシパルとして入力します。**[次へ]** をクリックします。 1. Managed AWS **AmazonAIOpsAssistantPolicy** アクセスポリシーを選択し、アクセススコープの**クラスター**を選択します。(または、エージェントが特定の名前空間にのみアクセスできるようにする場合は、目的の **Kubernetes 名前空間**を選択します）。**ポリシーの追加**をクリックし、**次へ**をクリックします。 1. 変更を確認し、正しいアクセスエントリポリシーと IAM ロールが選択されていることを確認し、**「作成**」をクリックしてアクセスエントリを作成します。 EKS アクセスが正しく設定されていることを確認するには、オペレーターアプリに移動して新しい調査を開始し、「デフォルトの名前空間にすべてのポッドを一覧表示する」や「クラスターに最近のイベントを表示する」など、クラスターについてエージェントに質問します。 ## トラブルシューティング エージェントがクラスターに到達できない場合は、セットアップダイアログに表示される正しい IAM ロール ARN がアクセスエントリで使用されており、**AmazonAIOpsAssistantPolicy** アクセスポリシーがアタッチされていることを確認します。 # Azure の接続 Azure 統合により、 AWS DevOps エージェントは Azure 環境内のリソースを調査し、Azure DevOps パイプラインのデプロイを運用上のインシデントに関連付けることができます。Azure を接続することで、エージェントは Azure インフラストラクチャを可視化し、 AWS と Azure リソースの両方で根本原因分析を実行できます。 Azure 統合は、2 つの独立した機能で構成されています。 + **Azure リソース** – エージェントが仮想マシン、Azure Kubernetes Service (AKS) クラスター、データベース、ネットワークコンポーネントなどの Azure クラウドリソースを検出して調査できるようにします。エージェントは Azure リソースグラフを使用して、インシデント調査中にリソースをクエリします。 + **Azure DevOps** – エージェントが Azure DevOps リポジトリとパイプライン実行履歴にアクセスできるようにします。エージェントは、コードの変更とデプロイをインシデントと関連付けて、潜在的な根本原因を特定するのに役立ちます。 各機能は AWS アカウントレベルで登録され、個々のエージェントスペースに関連付けることができます。 ## 登録方法 AWS DevOps Agent は、Azure に接続するための 2 つの方法をサポートしています。 + **管理者の同意** – Azure テナントで AWS DevOps Agent Entra アプリケーションを承認する、合理化された同意ベースのフロー。コンソールでは、これは**管理者の同意**オプションとして表示されます。この方法では、Microsoft Entra ID で管理者の同意を実行する権限を持つアカウントでサインインする必要があります。 + **アプリケーション登録** – アウトバウンド ID フェデレーションを使用してフェデレーション ID 認証情報を使用して独自の Entra アプリケーションを作成するセルフマネージド型アプローチ。コンソールでは、これは**アプリ登録**オプションとして表示されます。この方法は、アプリケーション設定をより詳細に制御する必要がある場合や、管理者の同意許可がない場合に適しています。 どちらの方法も同じ機能を提供します。同じ AWS アカウント内で 1 つまたは両方の方法を使用できます。 ## 既知の制限事項 + **管理者の同意: Azure テナントごとに 1 つの AWS アカウント** – 各 Azure テナントは、DevOps AWS DevOps Agent Entra App を一度に 1 つの AWS アカウントにのみ関連付けることができます。同じテナントを別の AWS アカウントに関連付けるには、まず既存の登録を解除する必要があります。 + **アプリ登録: 登録ごとに一意のアプリケーション** – アプリ登録ごとに異なるアプリケーション (クライアント ID) を使用する必要があります。同じクライアント ID で複数の設定を登録することはできません。 + **Azure DevOps: ソースコードアクセス** – Azure DevOps 統合は、ソースコードがホストされている場所に関係なく、パイプライン実行履歴へのアクセスを提供します。ただし、実際のソースコードにアクセスするには、サポートされているソースプロバイダー ( など) を介してリポジトリを個別に接続する必要があります[GitHub の接続](connecting-to-cicd-pipelines-connecting-github.md)。Bitbucket でホストされているソースコードは、Azure DevOps 統合から直接アクセスすることはできません。 ## トピック + [Azure リソースの接続](connecting-azure-connecting-azure-resources.md) + [Azure DevOps の接続](connecting-azure-connecting-azure-devops.md) # Azure リソースの接続 Azure リソースの統合により、 AWS DevOps Agent はインシデント調査中に Azure サブスクリプション内のリソースを検出して調査できます。エージェントは、リソース検出に Azure リソースグラフを使用し、Azure 環境全体のメトリクス、ログ、および設定データにアクセスできます。 この統合は、 AWS アカウントレベルで Azure を登録し、特定の Azure サブスクリプションを個々のエージェントスペースに関連付けるという 2 つのステップのプロセスに従います。 ## 前提条件 Azure リソースを接続する前に、以下を確認してください。 + AWS DevOps エージェントコンソールへのアクセス + ターゲットサブスクリプションにアクセスできる Azure アカウント + 管理者の同意方法: Microsoft Entra ID で管理者の同意を実行するアクセス許可を持つアカウント + アプリ登録方法の場合: フェデレーティッド ID 認証情報を設定するアクセス許可を持ち、 AWS アカウントで[アウトバウンド ID フェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-federation.html)が有効になっている Entra アプリケーション **注:** エージェントスペース内から登録を開始することもできます。**セカンダリソース**に移動し、**追加**をクリックして **Azure** を選択します。Azure Cloud がまだ登録されていない場合は、コンソールが最初に登録を案内します。 ## 管理者の同意による Azure リソースの登録 管理者同意メソッドは、 AWS DevOps Agent マネージドアプリケーションで同意ベースのフローを使用します。 ### ステップ 1: 登録を開始する 1. AWS マネジメントコンソールにサインインし、 AWS DevOps エージェントコンソールに移動します。 1. **機能プロバイダー**ページに移動する 1. **Azure Cloud** セクションを見つけて **Register** をクリックします。 1. **管理者の同意**登録方法を選択する ### ステップ 2: 管理者の同意を完了する 1. リクエストされているアクセス許可を確認する 1. クリックして続行 — Microsoft Entra 管理者同意ページにリダイレクトされます 1. 管理者の同意を実行するアクセス許可を持つユーザープリンシパルアカウントでサインインする 1. AWS DevOps Agent アプリケーションを確認して同意する ### ステップ 3: ユーザー認可を完了する 1. 管理者の同意後、承認されたテナントのメンバーとして ID を検証するユーザー認可を求められます。 1. 同じ Azure テナントに属するアカウントでサインインする 1. 認可後、成功ステータスで AWS DevOps エージェントコンソールにリダイレクトされます。 ### ステップ 4: ロールを割り当てる 以下の [Azure ロールの割り当て](#assigning-azure-roles)を参照してください。メンバーを選択するときに **AWS DevOps エージェント**を検索します。 ## アプリ登録による Azure リソースの登録 アプリ登録メソッドは、フェデレーティッド ID 認証情報を使用して独自の Entra アプリケーションを使用します。 ### ステップ 1: 登録を開始する 1. AWS DevOps エージェントコンソールで、**機能プロバイダー**ページに移動します。 1. **Azure Cloud** セクションを見つけて **Register** をクリックします。 1. **アプリ登録**方法を選択する ### ステップ 2: Entra アプリケーションを作成して設定する コンソールに表示される手順に従って、次の操作を行います。 1. AWS アカウントでアウトバウンド ID フェデレーションを有効にする (IAM コンソールで、**アカウント設定** → **アウトバウンド ID フェデレーション**に移動) 1. Microsoft Entra ID で Entra アプリケーションを作成するか、既存のアプリケーションを使用します。 1. アプリケーションでフェデレーション ID 認証情報を設定する ### ステップ 3: 登録の詳細を入力する 登録フォームに以下を入力します。 + **テナント ID** – Azure テナント識別子 + **テナント名** – テナントの表示名 + **クライアント ID** – 作成した Entra アプリケーションのアプリケーション (クライアント) ID + **対象者** – フェデレーティッド認証情報の対象者識別子 ### ステップ 4: IAM ロールを作成する コンソールから登録を送信すると、IAM ロールが自動的に作成されます。これにより、 AWS DevOps エージェントは認証情報を引き受けて を呼び出すことができます`sts:GetWebIdentityToken`。 ### ステップ 5: ロールを割り当てる 以下の[「Azure ロール](#assigning-azure-roles)の割り当て」を参照してください。メンバーの選択時に作成した Entra アプリケーションを検索します。 ### ステップ 6: 登録を完了する 1. AWS DevOps エージェントコンソールで設定を確認する 1. **送信**をクリックして登録を完了します ## Azure ロールの割り当て 登録後、Azure サブスクリプションへの読み取りアクセスをアプリケーションに付与します。このステップは、管理者の同意方法とアプリ登録方法の両方で同じです。 1. Azure Portal で、ターゲットサブスクリプションに移動します。 1. **アクセスコントロール (IAM)** に移動する 1. **Add** > **Add role assignment** をクリックします。 1. **リーダー**ロールを選択し、**次へ** をクリックします。 1. **メンバーの選択**をクリックし、アプリケーション (管理者の同意のための **AWS DevOps エージェント**、またはアプリ登録のための独自の Entra アプリケーション) を検索します。 1. アプリケーションを選択し、**レビュー \$1 割り当て** をクリックします。 1. (オプション) エージェントが Azure Kubernetes Service (AKS) クラスターにアクセスできるようにするには、次の AKS アクセス設定を完了します。 **セキュリティ要件:** サービスプリンシパルには、**リーダー**ロール (およびオプションで以下に示す AKS 読み取り専用ロール) のみを割り当てる必要があります。リーダーロールは、エージェントを読み取り専用オペレーションに制限し、間接的なプロンプトインジェクション攻撃の影響を制限するセキュリティ境界として機能します。書き込みまたはアクションのアクセス許可を持つロールを割り当てると、プロンプトインジェクションの爆発範囲が大幅に増加し、Azure リソースが侵害される可能性があります。 AWS DevOps Agent は読み取りオペレーションのみを実行します。エージェントは Azure リソースを変更、作成、または削除しません。 ### AKS アクセス設定 (オプション) #### ステップ 1: Azure Resource Manager (ARM) レベルのアクセス **Azure Kubernetes Service Cluster ユーザーロール**をアプリケーションに割り当てます。 Azure ポータルで、**サブスクリプション** → サブスクリプションの選択 → **アクセスコントロール (IAM)** → **ロールの割り当ての追加** → **Azure Kubernetes サービスクラスターユーザーロールの選択** → アプリケーション (管理者同意用の **AWS DevOps エージェント**、またはアプリ登録用の独自の Entra アプリケーション) への割り当てに移動します。 これは、サブスクリプション内のすべての AKS クラスターを対象としています。特定のクラスターに限定するには、代わりにリソースグループまたは個々のクラスターレベルで を割り当てます。 #### ステップ 2: Kubernetes API アクセス クラスターの認証設定に基づいて 1 つのオプションを選択します。 **オプション A: Azure Role-Based Access Control (RBAC) for Kubernetes (推奨)** 1. まだ有効になっていない場合は、クラスターで Azure RBAC を有効にする: Azure Portal → AKS クラスター → **設定** → **セキュリティ設定** → **認証と認可** → **Azure RBAC** を選択する 1. 読み取り専用ロールの割り当て: Azure Portal → **サブスクリプション** → サブスクリプションの選択 → **アクセスコントロール (IAM)** → **ロールの割り当ての追加** → **Azure Kubernetes Service RBAC Reader** の選択 → アプリケーションへの割り当て これは、サブスクリプション内のすべての AKS クラスターを対象としています。 **オプション B: Azure Active Directory (Azure AD) \$1 Kubernetes RBAC** クラスターが既にデフォルトの Azure AD 認証設定を使用していて、Azure RBAC を有効にしない場合は、これを使用します。これには、クラスターごとの`kubectl`セットアップが必要です。 1. 次のマニフェストを として保存します`devops-agent-reader.yaml`。 ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: devops-agent-reader rules: - apiGroups: [""] resources: ["namespaces", "pods", "pods/log", "services", "events", "nodes"] verbs: ["get", "list"] - apiGroups: ["apps"] resources: ["deployments", "replicasets", "statefulsets", "daemonsets"] verbs: ["get", "list"] - apiGroups: ["metrics.k8s.io"] resources: ["pods", "nodes"] verbs: ["get", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: devops-agent-reader-binding subjects: - kind: User name: "" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: devops-agent-reader apiGroup: rbac.authorization.k8s.io ``` 1. をサービスプリンシパルのオブジェクト ID ``に置き換えます。これを見つけるには: Azure Portal → Entra ID → Enterprise Applications → search for the application name (**AWS DevOps Agent** for Admin consent, or your own Entra application for App Registration)。 1. を各クラスターに適用します。 ``` az aks get-credentials --resource-group --name kubectl apply -f devops-agent-reader.yaml ``` **注:** ローカルアカウントのみ (Azure AD なし) を使用するクラスターはサポートされていません。この機能を使用するには、クラスターで Azure AD 統合を有効にすることをお勧めします。 ### 最小特権のカスタムロール (オプション) アクセスコントロールを強化するには、広範なリーダーロールではなく、 AWS DevOps Agent が使用するリソースプロバイダーのみを対象とするカスタム Azure ロールを作成できます。 ``` { "Name": "AWS DevOps Agent - Azure Reader", "Description": "Least-privilege read-only access for AWS DevOps Agent incident investigations.", "Actions": [ "Microsoft.AlertsManagement/*/read", "Microsoft.Compute/*/read", "Microsoft.ContainerRegistry/*/read", "Microsoft.ContainerService/*/read", "Microsoft.ContainerService/managedClusters/commandResults/read", "Microsoft.DocumentDB/*/read", "Microsoft.Insights/*/read", "Microsoft.KeyVault/vaults/read", "Microsoft.ManagedIdentity/*/read", "Microsoft.Monitor/*/read", "Microsoft.Network/*/read", "Microsoft.OperationalInsights/*/read", "Microsoft.ResourceGraph/resources/read", "Microsoft.ResourceHealth/*/read", "Microsoft.Resources/*/read", "Microsoft.Sql/*/read", "Microsoft.Storage/*/read", "Microsoft.Web/*/read" ], "NotActions": [], "DataActions": [], "NotDataActions": [], "AssignableScopes": [ "/subscriptions/{your-subscription-id}" ] } ``` ## サブスクリプションとエージェントスペースの関連付け アカウントレベルで Azure を登録したら、特定のサブスクリプションを エージェントスペースに関連付けます。 1. AWS DevOps エージェントコンソールで、エージェントスペースを選択します。 1. **機能**タブに移動する 1. **「セカンダリソース**」セクションで、**「追加**」をクリックします。 1. **Azure** を選択する 1. 関連付ける Azure サブスクリプションのサブスクリプション **ID** を指定します。 1. **追加**をクリックして関連付けを完了します 複数のサブスクリプションを同じエージェントスペースに関連付けることで、Azure 環境全体でエージェントを可視化できます。 ## Azure リソース接続の管理 + **接続されたサブスクリプションの表示** – **機能**タブの**セカンダリソース**セクションには、接続されたすべての Azure サブスクリプションが一覧表示されます。 + **サブスクリプションの削除** – エージェントスペースからサブスクリプションを切断するには、**セカンダリソース**リストでサブスクリプションを選択し、**削除**をクリックします。これはアカウントレベルの登録には影響しません。 + **登録の削除** – Azure Cloud 登録を完全に削除するには、**「機能プロバイダー**」ページに移動し、登録を削除します。最初にすべてのエージェントスペースの関連付けを削除する必要があります。 # Azure DevOps の接続 Azure DevOps 統合により、 AWS DevOps エージェントは Azure DevOps 組織のリポジトリとパイプライン実行履歴にアクセスできます。エージェントは、コードの変更とデプロイを運用上のインシデントと関連付けて、潜在的な根本原因を特定するのに役立ちます。 **注:** Azure DevOps パイプラインは、Azure Repos、GitHub、または Bitbucket のソースコードを使用できます。Azure DevOps 統合は、ソースプロバイダーに関係なく、パイプライン実行履歴へのアクセスを提供します。ただし、調査中に実際のソースコードにアクセスするには、 などのサポートされている統合を通じてリポジトリを個別に接続する必要があります[GitHub の接続](connecting-to-cicd-pipelines-connecting-github.md)。Bitbucket のソースコードは、この統合を通じて直接アクセスすることはできません。 この統合は、 AWS アカウントレベルで Azure DevOps を登録し、特定のプロジェクトを個々のエージェントスペースに関連付けるという 2 つのステップのプロセスに従います。 ## 前提条件 Azure DevOps を接続する前に、以下を確認してください。 + AWS DevOps エージェントコンソールへのアクセス + リポジトリとパイプライン履歴を含むプロジェクトが少なくとも 1 つある Azure DevOps 組織 + Azure DevOps 組織にユーザーを追加するアクセス許可 + 管理者の同意方法: Microsoft Entra ID で管理者の同意を実行するアクセス許可を持つアカウント + アプリ登録方法の場合: フェデレーティッド ID 認証情報を設定するアクセス許可を持ち、 AWS アカウントで[アウトバウンド ID フェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-federation.html)が有効になっている Entra アプリケーション **注:** エージェントスペース内から登録を開始することもできます。**Pipelines** セクションに移動し、**追加**をクリックして **Azure DevOps **を選択します。Azure DevOps がまだ登録されていない場合は、コンソールが最初に登録を案内します。 ## 管理者の同意による Azure DevOps の登録 管理者同意の方法では、 AWS DevOps エージェントマネージドアプリケーションで同意ベースのフローを使用します。 ### ステップ 1: 登録を開始する 1. AWS マネジメントコンソールにサインインし、 AWS DevOps エージェントコンソールに移動します。 1. **機能プロバイダーページ**に移動する 1. **Azure DevOps **セクションを見つけ、**登録**をクリックします。 1. プロンプトが表示されたら**、Azure DevOps 組織名**を入力します。 ### ステップ 2: 管理者の同意を完了する 1. クリックして続行 - Microsoft Entra 管理者の同意ページにリダイレクトされます 1. 管理者の同意を実行するアクセス許可を持つユーザープリンシパルアカウントでサインインする 1. AWS DevOps Agent アプリケーションを確認して同意する ### ステップ 3: ユーザー認可を完了する 1. 管理者の同意後、承認されたテナントのメンバーとして ID を検証するユーザー認可を求められます。 1. 同じ Azure テナントに属するアカウントでサインインする 1. 認可後、成功ステータスで AWS DevOps エージェントコンソールにリダイレクトされます。 ### ステップ 4: Azure DevOps でアクセス権を付与する 以下の [Azure DevOps でのアクセス権の付与](#granting-access-in-azure-devops)を参照してください。ユーザーを追加するときに **AWS DevOps エージェント**を検索します。 ## アプリ登録による Azure DevOps の登録 アプリ登録は、Azure リソースと Azure DevOps の間で共有されます。Azure リソースのアプリ登録をすでに完了している場合は、[「Azure DevOps でのアクセス権の付与](#granting-access-in-azure-devops)」に進むことができます。 ### ステップ 1: ADO アプリの登録を開始する 1. AWS DevOps エージェントコンソールで、**機能プロバイダー**ページに移動します。 1. **Azure Cloud** セクションを見つけて **Register** をクリックします。 1. **アプリ登録**方法を選択する ### ステップ 2: Entra アプリケーションを作成して設定する コンソールに表示される手順に従って、次の操作を行います。 1. AWS アカウントでアウトバウンド ID フェデレーションを有効にする (IAM コンソールで、**アカウント設定** → **アウトバウンド ID フェデレーション**に移動) 1. Microsoft Entra ID で Entra アプリケーションを作成するか、既存のアプリケーションを使用します。 1. アプリケーションでフェデレーション ID 認証情報を設定する ### ステップ 3: 登録の詳細を入力する 登録フォームに以下を入力します。 + **テナント ID** – Azure テナント識別子 + **テナント名** – テナントの表示名 + **クライアント ID** – Entra アプリケーションのアプリケーション (クライアント) ID + **対象者** – フェデレーティッド認証情報の対象者識別子 ### ステップ 4: IAM ロールを作成する コンソールから登録を送信すると、IAM ロールが自動的に作成されます。これにより、 AWS DevOps エージェントは認証情報を引き受け、 を呼び出すことができます`sts:GetWebIdentityToken`。 ### ステップ 5: 登録を完了する 1. AWS DevOps エージェントコンソールで設定を確認する 1. **送信**をクリックして登録を完了します ### ステップ 6: Azure DevOps でアクセス権を付与する 以下の[「Azure DevOps でのアクセス権の付与](#granting-access-in-azure-devops)」を参照してください。ユーザーを追加するときに、アプリ登録中に作成した Entra アプリケーションを検索します。 ## Azure DevOps でのアクセス権の付与 登録後、アプリケーションに Azure DevOps 組織へのアクセス権を付与します。このステップは、管理者の同意方法とアプリ登録方法の両方で同じです。 1. Azure DevOps で、**組織設定** > **ユーザー** > **ユーザーの追加** に移動します。 1. アプリケーション (管理者の同意のための **AWS DevOps エージェント**、またはアプリ登録のための独自の Entra アプリケーション) を検索します。 1. アクセスレベルを **Basic** に設定する 1. **プロジェクトに追加**で、エージェントがアクセスするプロジェクトを選択します。 1. **Azure DevOps グループ**で、**プロジェクトリーダー**を選択します。 1. **追加**をクリックして完了します **セキュリティ要件:** **Project Readers** グループのみを割り当てます。読み取り専用アクセスは、エージェントを読み取り専用オペレーションに制限し、間接的なプロンプトインジェクション攻撃の影響を制限するセキュリティ境界として機能します。書き込みまたはアクションのアクセス許可を持つグループを割り当てると、プロンプトインジェクションのブラスト半径が大幅に増加し、Azure DevOps リソースが侵害される可能性があります。 ## プロジェクトとエージェントスペースの関連付け アカウントレベルで Azure DevOps を登録したら、特定のプロジェクトをエージェントスペースに関連付けます。 1. AWS DevOps エージェントコンソールで、エージェントスペースを選択します。 1. **機能**タブに移動する 1. **「パイプライン**」セクションで、**「追加**」をクリックします。 1. 利用可能なプロバイダーのリストから **Azure DevOps** を選択する 1. 利用可能なプロジェクトのドロップダウンからプロジェクトを選択する 1. **追加**をクリックして関連付けを完了します ## Azure DevOps 接続の管理 + **接続されたプロジェクトの表示** – **機能**タブの**パイプライン**セクションには、接続されたすべての Azure DevOps プロジェクトが一覧表示されます。 + **プロジェクトの削除** – エージェントスペースからプロジェクトを切断するには、**パイプライン**セクションでプロジェクトを選択し、**削除**をクリックします。 + **登録の削除** – Azure DevOps 登録を完全に削除するには、**「機能プロバイダー**」ページに移動し、登録を削除します。最初にすべてのエージェントスペースの関連付けを削除する必要があります。 # CI/CD パイプラインへの接続 CI/CD パイプライン統合により、 AWS DevOps Agent はデプロイをモニタリングし、調査中にコードの変更を運用上のインシデントに関連付けることができます。CI/CD プロバイダーを接続することで、エージェントはデプロイイベントを追跡し、 AWS リソースに関連付けて、インシデント対応中に潜在的な根本原因を特定できます。 AWS DevOps Agent は、2 ステップのプロセスを通じて一般的な CI/CD プラットフォームとの統合をサポートします。 1. **アカウントレベルの登録** – CI/CD プロバイダーを AWS アカウントレベルで 1 回登録します。 1. **エージェントスペース接続** – 組織のニーズに基づいて、特定のプロジェクトまたはリポジトリを個々のエージェントスペースに接続します。 このアプローチにより、各スペースでモニタリングされるプロジェクトをきめ細かく制御しながら、複数のエージェントスペース間で CI/CD プロバイダー登録を共有できます。 ## サポートされている CI/CD プロバイダー AWS DevOps Agent は、次の CI/CD プラットフォームをサポートしています。 + **GitHub** – AWS DevOps Agent GitHub アプリを使用して [GitHub.com](http://GitHub.com) からリポジトリを接続します。 GitHub + **GitLab** – [GitLab.com,](http://gitlab.com)マネージド GitLab インスタンス、またはパブリックにアクセス可能なセルフホスト GitLab デプロイからプロジェクトを接続します。 **トピック** + [GitHub の接続](connecting-to-cicd-pipelines-connecting-github.md) + [GitLab の接続](connecting-to-cicd-pipelines-connecting-gitlab.md) # GitHub の接続 GitHub 統合により、 AWS DevOps Agent はコードリポジトリにアクセスし、インシデント調査中にデプロイイベントを受信できます。この統合は、GitHub のアカウントレベルの登録と、特定のリポジトリを個々のエージェントスペースに接続するという 2 つのステップのプロセスに従います。 AWS DevOps Agent は、GitHub.com (SaaS) インスタンスと GitHub Enterprise Server (セルフホスト) インスタンスの両方をサポートしています。 ## 前提条件 GitHub を接続する前に、以下を確認してください。 + AWS DevOps エージェント管理コンソールへのアクセス + 管理者権限を持つ GitHub ユーザーアカウントまたは組織 + アカウントまたは組織に GitHub アプリをインストールする認可 GitHub Enterprise Server の場合、以下も必要です。 + HTTPS 経由でアクセス可能な GitHub Enterprise Server インスタンス (バージョン 3.x 以降) + GitHub Enterprise Server インスタンスの HTTPS URL (例: `https://github.example.com`) + (オプション) GitHub Enterprise Server インスタンスがパブリックにアクセスできない場合のプライベート接続 ## GitHub の登録 (アカウントレベル) GitHub は AWS アカウントレベルで登録され、そのアカウントのすべてのエージェントスペース間で共有されます。 AWS アカウントごとに 1 回だけ GitHub を登録する必要があります。 ### ステップ 1: パイプラインプロバイダーに移動する 1. AWS マネジメントコンソールにサインインする 1. AWS DevOps エージェントコンソールに移動する 1. **機能**タブに移動する 1. **「パイプライン**」セクションで、**「追加**」をクリックします。 1. 利用可能なプロバイダーのリストから **GitHub** を選択する GitHub がまだ登録されていない場合は、最初に登録するように求められます。 ### ステップ 2: 接続タイプを選択する GitHub アカウント/組織を登録する」画面で、ユーザーとして接続するか組織として接続するかを選択します。 + **ユーザー** – ユーザーネームとプロファイルを持つ個人 GitHub アカウント + **組織** – 複数のユーザーが一度に複数のプロジェクトでコラボレーションできる共有 GitHub アカウント GitHub Enterprise Server インスタンスに接続する場合は、**GitHub Enterprise Server **の使用チェックボックスをオンにし、インスタンスの HTTPS URL (例: ) を入力します`https://github.example.com`。 GitHub Enterprise Server インスタンスがパブリックにアクセスできない場合は、オプションでプライベート接続を設定して、 AWS DevOps Agent がインスタンスに安全に到達できるようにします。詳細については、「[プライベートにホストされたツールへの接続](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md)」を参照してください。 **注記** ** URL に `/api/v3`または末尾のパスを含めないでください。基本 URL のみを入力します。 ### ステップ 3: GitHub アプリを設定する **送信**をクリックして、アプリのセットアッププロセスを開始します。次のステップは、GitHub.com と GitHub Enterprise Server のどちらに接続するかによって異なります。 #### GitHub.com の場合 1. GitHub にリダイレクトされ、 AWS DevOps Agent GitHub アプリがインストールされます。 1. アプリをインストールするアカウントまたは組織を選択します。 1. アプリを使用すると、 AWS DevOps Agent は、デプロイイベントなど、接続されたリポジトリからイベントを受信できます。 #### GitHub Enterprise Server の場合 GitHub Enterprise Server は GitHub App Manifest フローを使用します。これにより、インスタンスに新しい GitHub App が自動的に設定されます。これには、GitHub Enterprise Server インスタンスへの 2 つのリダイレクトが含まれます。 1. ブラウザが GitHub Enterprise Server インスタンスのGitHub アプリの作成」ページにリダイレクトされます。 1. アプリ名があらかじめ入力されています。必要に応じて名前を自由に変更できます。**GitHub アプリの作成**をクリックします。 1. AWS DevOps エージェントにリダイレクトされ、マニフェストコードをアプリケーションの認証情報と交換します。 ### ステップ 4: リポジトリを選択してインストールを完了する 1. GitHub アプリ**のインストールと認可**ページが表示されます。 1. アプリがアクセスできるようにするリポジトリを選択します。 + **すべてのリポジトリ** – 現在および将来のすべてのリポジトリへのアクセスを許可します。 + **リポジトリのみを選択する** – アカウントまたは組織から特定のリポジトリを選択します。 1. **Install & Authorize** をクリックします。 1. AWS DevOps エージェントコンソールにリダイレクトされ、GitHub がアカウントレベルで登録済みとして表示されます。 ## エージェントスペースへのリポジトリの接続 アカウントレベルで GitHub を登録したら、特定のリポジトリを個々のエージェントスペースに接続できます。 1. AWS DevOps エージェントコンソールで、エージェントスペースを選択します。 1. **機能**タブに移動する 1. **パイプライン**セクションで、**追加** をクリックします。 1. 利用可能なプロバイダーのリストから **GitHub** を選択する 1. このエージェントスペースに関連するリポジトリのサブセットを選択する 1. **追加**をクリックして接続を完了します 組織のニーズに応じて、異なるリポジトリのセットを異なるエージェントスペースに接続できます。 ## GitHub アプリについて AWS DevOps エージェント GitHub アプリ: + リポジトリへの読み取り専用アクセスをリクエストする + デプロイイベントおよびその他のリポジトリイベントを受信します + AWS DevOps エージェントによるコード変更と運用インシデントの関連付けを許可する + GitHub 設定を使用していつでもアンインストールできます GitHub Enterprise Server の場合、GitHub アプリは登録時にインスタンスに自動的に作成されます。アプリのリポジトリアクセスを管理したり、**設定 > アプリケーション > インストールされた GitHub Apps** を使用してアンインストールしたりできます。アプリ定義を完全に削除するには、**設定 > デベロッパー設定 > GitHub Apps** に移動します。 ## GitHub 接続の管理 + **リポジトリアクセスの更新** – GitHub アプリがアクセスできるリポジトリを変更するには、GitHub アカウントまたは組織設定 (または GitHub Enterprise Server インスタンス設定) に移動し、インストールされている GitHub アプリに移動し、 AWS DevOps エージェントアプリ設定を変更します。 + **接続されたリポジトリの表示** – AWS DevOps エージェントコンソールで、エージェントスペースを選択し、機能タブに移動して、パイプラインセクションの接続されたリポジトリを表示します。 + **GitHub 接続の削除** – GitHub をエージェントスペースから切断するには、パイプラインセクションで接続を選択し、**削除**をクリックします。GitHub アプリを完全にアンインストールするには、GitHub アカウントまたは組織設定からアンインストールします。GitHub Enterprise Server の場合、GitHub アプリは登録時にインスタンスに直接作成されるため、オプションで以下の両方を実行してアプリを完全にクリーンアップできます。 + **アプリをアンインストール**する – **設定 > アプリケーション > インストールされた GitHub アプリ**に移動し、アプリで**設定**をクリックしてアンインストールします。 + **アプリの削除** – **設定 > デベロッパー設定 > GitHub **アプリに移動し、アプリを選択し、**詳細**タブに移動して、**GitHub アプリの削除**を選択します。**警告:** GitHub アプリの削除は永続的であり、元に戻すことはできません。削除した場合は、 AWS DevOps エージェントコンソールの最初から GitHub Enterprise Server を再登録して、新しいアプリケーションを作成する必要があります。 # GitLab の接続 GitLab 統合により、 AWS DevOps Agent は GitLab Pipelines からのデプロイをモニタリングし、インシデント対応中に因果調査を通知できます。この統合は、GitLab のアカウントレベルの登録と、特定のプロジェクトを個々のエージェントスペースに接続する 2 つのステップのプロセスに従います。 ## GitLab の登録 (アカウントレベル) GitLab は AWS アカウントレベルで登録され、そのアカウントのすべてのエージェントスペース間で共有されます。個々のエージェントスペースは、エージェントスペースに適用する特定のプロジェクトを選択できます。 ### ステップ 1: パイプラインプロバイダーに移動する 1. AWS マネジメントコンソールにサインインする 1. AWS DevOps エージェントコンソールに移動する 1. **機能プロバイダー**ページに移動する (サイドナビゲーションからアクセス可能) 1. **Pipeline** の**「利用可能な**プロバイダー」セクションで **GitLab** を検索し、**登録**をクリックします ### ステップ 2: GitLab 接続を設定する GitLab 登録ページで、以下を設定します。 **接続タイプ** – 人として接続するかグループとして接続するかを選択します。 + **Personal** (デフォルト) – ユーザー名とプロファイルを持つ個々の GitLab ユーザーアカウント + **グループ** – GitLab では、グループを使用して 1 つ以上の関連プロジェクトを同時に管理します。 **GitLab インスタンスタイプ** – 接続先の GitLab インスタンスのタイプを選択します。 + **GitLab.com** (デフォルト) – パブリック GitLab サービス + **パブリックにアクセス可能なセルフホスト型 GitLab** – ** GitLab セルフホスト型エンドポイントの使用**チェックボックスをオンにし、GitLab インスタンスへの URL を指定します。 **注記** ** 現在、パブリックにアクセス可能な GitLab インスタンスのみがサポートされています。 **アクセストークン** – GitLab 個人用アクセストークンを提供します。 1. 別のブラウザタブで、GitLab アカウントにログインします。 1. ユーザー設定に移動し、**アクセストークン**を選択する 1. 次のアクセス許可を持つ新しい個人用アクセストークンを作成します。 + `read_repository` – リポジトリコンテンツにアクセスするために必要です + `read_virtual_registry` – 仮想レジストリ情報にアクセスするために必要です + `read_registry` – レジストリ情報にアクセスするために必要です + `api` – 読み取りおよび書き込み API アクセスに必要です + `self_rotate` - トークンのローテーションに必要です。この機能は現在、 AWS DevOps エージェントではサポートされていませんが、後日サポートされます。これで を追加すると、今後新しいトークンを作成する必要がなくなります。 1. トークンの有効期限を現在の日付から最大 365 日に設定します。 1. 生成されたトークンをコピーする 1. AWS DevOps エージェントコンソールに戻る 1. トークンを「アクセストークン」フィールドに貼り付けます。 ### ステップ 3: 登録を完了する **(オプション) タグ** – 組織の目的で GitLab 登録に AWS タグを追加します。 **次へ**をクリックして設定を確認し、**送信**をクリックして GitLab 登録プロセスを完了します。システムはアクセストークンを検証し、接続を確立します。 ## エージェントスペースへのプロジェクトの接続 アカウントレベルで GitLab を登録したら、特定のプロジェクトを個々のエージェントスペースに接続できます。 1. AWS DevOps エージェントコンソールで、エージェントスペースを選択します。 1. **機能**タブに移動する 1. **パイプライン**セクションで、**追加**をクリックします。 1. 利用可能なプロバイダーのリストから **GitLab** を選択する 1. エージェントスペースに関連する GitLab プロジェクトを選択する 1. **保存 **をクリックします。 AWS DevOps エージェントは、GitLab Pipelines からのデプロイについてこれらのプロジェクトをモニタリングし、因果調査を通知します。 ## GitLab 接続の管理 + **アクセストークンの更新** – アクセストークンの有効期限が切れるか、更新する必要がある場合は、アカウントレベルで GitLab 登録を変更することで、 AWS DevOps エージェントコンソールで更新できます。 + **接続されたプロジェクトの表示** – AWS DevOps エージェントコンソールで、エージェントスペースを選択し、機能タブに移動して、パイプラインセクションで接続されたプロジェクトを表示します。 + **GitLab 接続の削除** – GitLab プロジェクトをエージェントスペースから切断するには、パイプラインセクションで接続を選択し、**削除**をクリックします。GitLab 登録を完全に削除するには、まずすべてのエージェントスペースから削除してから、アカウントレベルで登録を削除します。 # MCP サーバーの接続 Model Context Protocol (MCP) サーバーは、外部オブザーバビリティツール、カスタムモニタリングシステム、運用データソースからのデータへのアクセスを提供することで、 AWS DevOps Agent の調査機能を拡張します。このガイドでは、MCP サーバーを AWS DevOps エージェントに接続する方法について説明します。 ## 要件 MCP サーバーを接続する前に、サーバーが次の要件を満たしていることを確認してください。 + **ストリーミング可能な HTTP トランスポートプロトコル** – ストリーミング可能な HTTP トランスポートプロトコルを実装する MCP サーバーのみがサポートされています。 + **認証のサポート** – MCP サーバーは OAuth 2.0 認証フローまたは API キー/トークンベースの認証をサポートしている必要があります。 ## セキュリティに関する考慮事項 MCP サーバーを AWS DevOps エージェントに接続するときは、次のセキュリティ面を考慮してください。 + **ツールの許可リスト – ** MCP サーバーからすべてのツールを公開するのではなく、エージェントスペースが必要とする特定のツールのみを許可リストに登録する必要があります。[エージェントスペースごとにリストツールを許可する方法については、「エージェントスペースでの MCP ツールの設定](#configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers)」を参照してください。 MCP ツールの最大長は 64 です。 + **プロンプトインジェクションリスク** – カスタム MCP サーバーは、プロンプトインジェクション攻撃のリスクを高める可能性があります。詳細については、[「プロンプトインジェクション保護: AWS DevOps エージェントセキュリティ](aws-devops-agent-security.md)」を参照してください。 + **読み取り専用ツールとアクセス –** 読み取り専用 MCP ツールのみを許可リストに登録し、認証情報が読み取り専用アクセスのみを許可されていることを確認します。 プロンプトインジェクションと責任共有モデルの詳細については、[AWS DevOps エージェントセキュリティ](aws-devops-agent-security.md)「」を参照してください。 **注記** MCP サーバーがプライベートネットワーク上にある場合は、「」を参照してください。 [プライベートにホストされたツールへの接続](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md) ## MCP サーバーの登録 (アカウントレベル) MCP サーバーは AWS アカウントレベルで登録され、そのアカウントのすべてのエージェントスペース間で共有されます。個々のエージェントスペースは、各 MCP サーバーから必要な特定のツールを選択できます。 ### ステップ 1: MCP サーバーの詳細 1. AWS マネジメントコンソールにサインインする 1. AWS DevOps エージェントコンソールに移動する 1. **機能プロバイダー**ページに移動する (サイドナビゲーションからアクセス可能) 1. **利用可能な**プロバイダーセクションで **MCP サーバー**を検索し、**登録**をクリックします 1. **MCP サーバーの詳細**ページで、次の情報を入力します。 + **名前** – MCP サーバーのわかりやすい名前を入力します。 + **エンドポイント URL** – MCP サーバーエンドポイントの完全な HTTPS URL を入力します。 + **説明** (オプション) – サーバーの目的を特定するのに役立つ説明を追加します。 + **動的クライアント登録を有効にする** – AWS DevOps エージェントが MCP サーバーの認可サーバーに自動的に登録できるようにする場合は、このチェックボックスをオンにします。 1. **[次へ]** をクリックします。 **注記** ** MCP サーバーエンドポイント URL は、アカウントの AWS CloudTrail ログに表示されます。 ### ステップ 2: 認可フロー MCP サーバーの認証方法を選択します。 **OAuth クライアント認証情報** – MCP サーバーが OAuth クライアント認証情報フローを使用している場合: 1. **OAuth クライアント認証情報**の選択 1. **[次へ]** をクリックします。 **OAuth 3LO (Three-Legged OAuth)** – MCP サーバーが認証に OAuth 3LO を使用している場合: 1. **OAuth 3LO **を選択する 1. **[次へ]** をクリックします。 **API キー** – MCP サーバーが API キー認証を使用する場合: 1. **API キー**の選択 1. **[次へ]** をクリックします。 ### ステップ 3: 認可設定 選択した認証方法に基づいて追加の認可パラメータを設定します。 **OAuth クライアント認証情報の場合:** 1. **クライアント ID** – OAuth クライアントのクライアント ID を入力します。 1. **クライアントシークレット** – OAuth クライアントのクライアントシークレットを入力します。 1. **Exchange URL** – OAuth トークン交換エンドポイント URL を入力します。 1. **Exchange Parameters** – サービスで認証するための OAuth トークン交換パラメータを入力します。 1. **スコープの追加** – 認証用の OAuth スコープの追加 1. **[次へ]** をクリックします。 **OAuth 3LO の場合:** 1. **クライアント ID** – OAuth クライアントのクライアント ID を入力します。 1. **クライアントシーク**レット – OAuth クライアントで必要な場合は、OAuth クライアントのクライアントシークレットを入力します。 1. **Exchange URL** – OAuth トークン交換エンドポイント URL を入力します。 1. **認可 URL ** - OAuth 認可エンドポイント URL を入力します 1. **コードチャレンジのサポート ** - OAuth クライアントがコードチャレンジをサポートしている場合は、このチェックボックスをオンにします 1. **スコープの追加** – 認証用の OAuth スコープの追加 1. **[次へ]** をクリックします。 **API キーの場合:** 1. API キー名を入力する 1. リクエストに API キーを含むヘッダーの名前を入力します。 1. API キーの値を入力する 1. **[次へ]** をクリックします。 ### ステップ 4: 確認して送信する 1. すべての MCP サーバー設定の詳細を確認する 1. **送信**をクリックして登録を完了します 1. AWS DevOps エージェントは MCP サーバーへの接続を検証します 1. 検証に成功すると、MCP サーバーはアカウントレベルで登録されます。 ## エージェントスペースでの MCP ツールの設定 アカウントレベルで MCP サーバーを登録したら、そのサーバーのどのツールを特定のエージェントスペースで使用できるかを設定できます。 1. AWS DevOps エージェントコンソールで、エージェントスペースを選択します。 1. **機能**タブに移動する 1. **MCP サーバー**セクションで、**追加** 1. このエージェントスペースに接続する登録済み MCP サーバーを選択します。 1. エージェントスペースで使用できるように、この MCP サーバーのツールを設定します。 + **すべてのツールを許可する** – MCP サーバーからすべてのツールを使用できるようにします + **特定のツールの選択** – 許可リストを作成するツールを選択できます。 1. **追加**をクリックして、MCP サーバーをエージェントスペースに接続します。 AWS DevOps Agent は、このエージェントスペースの調査中に MCP サーバーから許可リストに登録されたツールを使用できるようになりました。 ## MCP サーバー接続の管理 **認証情報の更新** – 認証情報を更新する必要がある場合は、MCP サーバーを再登録する必要があります。 AWS DevOps エージェントコンソールの **Capability Providers** ページに移動し、MCP サーバーを見つけ、アクティブな関連付けを削除して、**登録解除**をクリックします。次に、新しい認証情報で MCP サーバー**を登録**し、エージェントスペースと必要な関連付けを再作成します。 **接続された MCP サーバーの表示** – エージェントスペースに接続されているすべての MCP サーバーを表示するには、エージェントスペースを選択し、**機能**タブに移動して **MCP サーバー**セクションを確認します。選択したツールをここで更新することもできます。 **MCP サーバー接続の削除** – MCP サーバーをエージェントスペースから切断するには、MCP サーバーセクションで**サーバー**を選択し、**削除**をクリックします。MCP サーバー登録を完全に削除するには、まずすべてのエージェントスペースから削除してから、アカウントレベルの登録を削除します。 ## 関連トピック + AWS DevOps エージェントのセキュリティ + エージェントスペースのセットアップ + プロンプトインジェクション保護 # 複数の AWS アカウントを接続する セカンダリ AWS アカウントを使用すると、 AWS DevOps Agent は組織内の複数の AWS アカウントのリソースを調査できます。アプリケーションが複数のアカウントにまたがる場合、セカンダリアカウントを追加すると、エージェントはインシデント調査中にすべての関連リソースを可視化できます。アプリケーションを構成するアカウントとリソースへのアクセスを増やすと、調査の精度が向上します。 ## 前提条件 セカンダリ AWS アカウントを追加する前に、以下があることを確認してください。 + プライマリアカウントの AWS DevOps エージェントコンソールへのアクセス + セカンダリ AWS アカウントへの管理アクセス + セカンダリアカウントでロールを作成する IAM アクセス許可 ## セカンダリ AWS アカウントの追加 以下のステップに加えて、 を使用してセカンダリアカウント[AWS DevOps エージェント CLI オンボーディングガイド](getting-started-with-aws-devops-agent-cli-onboarding-guide.md)をプログラムで追加できます。 ### ステップ 1: セカンダリアカウント設定を開始する 1. AWS マネジメントコンソールにサインインし、 AWS DevOps エージェントコンソールに移動します。 1. エージェントスペースを選択する 1. **機能**タブに移動する 1. **クラウド**セクションで、**セカンダリソース**サブセクションを見つけます。 1. **追加**をクリックします ### ステップ 2: ロール名を指定する 1. **ロールの名前**フィールドに、セカンダリアカウントで作成するロールの名前を入力します。 1. この名前に注意してください。セカンダリアカウントでロールを作成するときに再度使用します。 1. コンソールで提供されている信頼ポリシーをコピーし、スクラッチスペースに保存します。 ### ステップ 3: セカンダリアカウントにロールを作成する 1. 新しいブラウザタブを開き、セカンダリ AWS アカウントの IAM コンソールにサインインします。 1. **IAM >** **ロール** > **ロールの作成**に移動する 1. **カスタム信頼ポリシー**の選択 1. ステップ 2 からコピーした信頼ポリシーを貼り付ける 1. **[次へ]** をクリックします。 ### ステップ 4: AWS 管理ポリシーをアタッチする 1. アクセス**許可ポリシー**セクションで、**AIOpsAssistantPolicy** を検索します。 1. **AIOpsAssistantPolicy** 管理ポリシーの横にあるチェックボックスをオンにします。 1. **[次へ]** をクリックします。 ### ステップ 5: ロールに名前を付けて作成する 1. **ロール名**フィールドに、ステップ 2 で指定したのと同じロール名を入力します。 1. (オプション) ロールの目的を特定するのに役立つ説明を追加します。 1. 信頼ポリシーとアタッチされたアクセス許可を確認する 1. **ロールの作成** をクリックします。 ### ステップ 6: インラインポリシーをアタッチする 1. IAM コンソールで、先ほど作成したロールを見つけて選択します。 1. アクセス**許可**タブに移動する 1. アクセス**許可の追加** > **インラインポリシーの作成** をクリックします。 1. **JSON** タブに切り替える 1. ステップ 2 で保存したポリシーを貼り付ける 1. IAM コンソールの JSON エディタにポリシーを貼り付ける 1. **[次へ]** をクリックします。 1. インラインポリシーの名前を指定します (DevOpsAgentInlinePolicy」など）。 1. **ポリシーの作成** をクリックします。 ### ステップ 7: 設定を完了する 1. プライマリアカウントの AWS DevOps エージェントコンソールに戻る 1. **次へ**をクリックしてセカンダリアカウント設定を完了します 1. 接続ステータスが**アクティブ**と表示されることを確認する ## 必要なポリシーについて AWS DevOps Agent では、セカンダリアカウントのリソースにアクセスするために 3 つのポリシーコンポーネントが必要です。 + **信頼ポリシー** – プライマリアカウントの AWS DevOps エージェントがセカンダリアカウントのロールを引き受けることを許可します。これにより、アカウント間の信頼関係が確立されます。 + **AIOpsAssistantPolicy (AWS 管理ポリシー)** – セカンダリアカウントのリソースを調査するために AWS DevOps Agent が必要とするコア読み取り専用アクセス許可を提供します。このポリシーは によって維持 AWS され、新機能が追加されると更新されます。 + **インラインポリシー** – エージェントスペース設定に固有の追加のアクセス許可を提供します。このポリシーは、エージェントスペースの設定に基づいて生成され、特定の統合または機能のアクセス許可が含まれる場合があります。 プライマリアカウントでは、 AWS DevOps エージェント IAM ロールがセカンダリアカウントで作成されたロールを引き受けることができる必要があります。 ## セカンダリアカウントの管理 + **接続されたアカウントの表示** – **機能**タブで、**セカンダリソース**サブセクションは接続ステータスを持つすべての接続されたセカンダリアカウントを一覧表示します。 + **IAM ロールの更新** – アクセス許可を変更する必要がある場合は、セカンダリアカウントのロールにアタッチされたインラインポリシーを更新します。変更は即時適用されます。 + **セカンダリアカウントの削除** – セカンダリアカウントを切断するには、**セカンダリソース**リストでセカンダリアカウントを選択し、**削除**をクリックします。これにより、セカンダリアカウントの IAM ロールは削除されません。 # テレメトリソースの接続 AWS DevOps エージェントには、テレメトリソースに接続する 3 つの方法があります。 ## 組み込みの双方向統合 現在、 AWS DevOps Agent は、以下を可能にする 2 方向統合が組み込まれた Dynatrace ユーザーをサポートしています。 + **トポロジーリソースマッピング** - AWS DevOps Agent は、DevOps Agent がホストする Dynatrace MCP サーバーを介して利用可能なエンティティと関係で AWS DevOps Agent Space Topology を強化します。 + **自動調査トリガー** - Dynatrace ワークフローは、Dynatrace 問題からインシデント解決調査をトリガーするように設定できます。 + **テレメトリのイントロスペクション** - AWS DevOps Agent は、 AWS DevOps Agent がホストする Dynatrace MCP サーバーを介して問題を調査する際に、Dynatrace テレメトリをイントロスペクションできます。 + **ステータスの更新** - AWS DevOps Agent は、主要な調査結果、根本原因分析、生成された緩和計画を Dynatrace ユーザーインターフェイスに発行します。 双方向統合の詳細については、「」を参照してください。 + [Dynatrace の接続](connecting-telemetry-sources-connecting-dynatrace.md) ## 組み込みの 1 方向統合 現在、 AWS DevOps エージェントは、 AWS CloudWatch、Datadog、Grafana、New Relic、Splunk ユーザーを組み込みの 1 方向統合でサポートしています。 **セキュリティのベストプラクティス:** 組み込みの 1 方向統合の認証情報を設定する場合は、API キーとトークンの範囲を読み取り専用アクセスに設定することをお勧めします。 AWS DevOps Agent はこれらの認証情報をテレメトリイントロスペクションにのみ使用し、テレメトリプロバイダーへの書き込みアクセスは必要ありません。 AWS CloudWatch 組み込みの 1 方向統合は、追加のセットアップを必要とせず、以下を有効にします。 + **トポロジーリソースマッピング** - AWS DevOps エージェントは、設定されたプライマリクラウドアカウントとセカンダリ AWS クラウドアカウントを介して利用可能なエンティティと関係で DevOps エージェントスペーストポロジーを強化します。 + **テレメトリイントロスペクション** - AWS DevOps Agent は、プライマリおよびセカンダリの AWS クラウドアカウント設定中に提供された IAM ロール (複数可) を介して問題を調査する際に、Introspect AWS CloudWatch テレメトリを使用できます。 Datadog、Grafana、New Relic、Splunk の組み込みの 1 方向統合では、以下を設定して有効にする必要があります。 + **自動調査トリガー** - Datadog、Grafana、New Relic、Splunk イベントは、 AWS DevOps Agent ウェブフックを介して AWS DevOps Agent インシデント解決調査をトリガーするように設定できます。 + **テレメトリイントロスペクション** - AWS DevOps エージェントは、各プロバイダーのリモート MCP サーバーを介して問題を調査する際に、Datadog、Grafana、New Relic、Splunk テレメトリをイントロスペクションできます。 一方向統合の詳細については、以下を参照してください。 + [DataDog の接続](connecting-telemetry-sources-connecting-datadog.md) + [Grafana の接続](connecting-telemetry-sources-connecting-grafana.md) + [New Relic の接続](connecting-telemetry-sources-connecting-new-relic.md) + [Splunk の接続](connecting-telemetry-sources-connecting-splunk.md) ## Bring-your-ownテレメトリソース Prometheus メトリクスを含む他のテレメトリソースについては、ウェブフックと MCP サーバー統合の両方に対する AWS DevOps Agent のサポートを活用できます。 bring-your-own 統合の詳細については、以下を参照してください。 + [Webhook による DevOps エージェントの呼び出し](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md) + [MCP サーバーの接続](configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers.md) # Dynatrace の接続 ## 組み込みの双方向統合 現在、 AWS DevOps Agent は、以下を可能にする 2 方向統合が組み込まれた Dynatrace ユーザーをサポートしています。 + **トポロジーリソースマッピング** - AWS DevOps Agent は、Dynatrace 環境から利用可能なエンティティと関係で DevOps Agent Space Topology を強化します。 + **自動調査トリガー** - Dynatrace ワークフローは、Dynatrace 問題からインシデント解決調査をトリガーするように設定できます。 + **テレメトリのイントロスペクション** - AWS DevOps Agent は、 AWS DevOps Agent がホストする Dynatrace MCP サーバーを介して問題を調査する際に、Dynatrace テレメトリをイントロスペクションできます。 + **ステータスの更新** - AWS DevOps Agent は、主要な調査結果、根本原因分析、生成された緩和計画を Dynatrace ユーザーインターフェイスに発行します。 ## オンボーディング ### オンボーディングプロセス Dynatrace オブザーバビリティシステムのオンボーディングには、次の 3 つの段階があります。 1. **Connect** - アカウントアクセス認証情報を設定し、必要なすべての環境を使用して Dynatrace への接続を確立します。 1. **有効** - 特定の Dynatrace 環境を持つ特定のエージェントスペースで Dynatrace をアクティブ化する 1. **Dynatrace 環境を設定する** - ワークフローとダッシュボードをダウンロードして Dynatrace にインポートし、ウェブフックの詳細を書き留めて、指定されたエージェントスペースで調査をトリガーします。 ### ステップ 1: 接続する Dynatrace 環境への接続を確立する #### 設定 1. **機能プロバイダー**ページに移動する (サイドナビゲーションからアクセス可能) 1. Telemetry の**「利用可能な**プロバイダー」セクションで **Dynatrace** を検索し、**Register** をクリックします。 **** 1. **詳細なアクセス許可を使用して、Dynatrace で OAuth クライアントを作成します。** 1. [「Dynatrace ドキュメント](https://docs.dynatrace.com/docs/shortlink/aws-devops-agent)」を参照してください。 1. 準備ができたら、次へを押します 1. 複数の Dynatrace 環境とそれ以降のスコープを、DevOps エージェントスペースごとに特定の環境に接続できます。 1. OAuth クライアント設定から Dynatrace の詳細を入力します。 + **クライアント名** + **クライアント ID** + **クライアントシークレット** + **アカウント URN** 1. [次へ] をクリックします。 1. 確認して追加する ### ステップ 2: を有効にする 特定のエージェントスペースで Dynatrace をアクティブ化し、適切なスコープを設定する #### 設定 1. エージェントスペースページからエージェントスペースを選択し、詳細の表示を押します。 1. 機能タブを選択する 1. Telemetry セクションを見つけ、Add キーを押します。 1. Dynatrace のステータスが「登録済み」であることがわかります。add をクリックして、これをエージェントスペースに追加します。 1. Dynatrace 環境 ID - この DevOps エージェントスペースに関連付ける Dynatrace 環境 ID を指定します。 1. 1 つ以上の Dynatrace エンティティ IDs を入力します。これは、DevOps エージェントが最も重要なリソースを検出するのに役立ちます。例としては、サービスやアプリケーションなどがあります。**不明な場合は、削除を押します。** 1. 確認して保存を押します 1. Webhook URL と Webhook Secret をコピーします。これらの認証情報を [Dynatrace に追加するには、Dynatrace のドキュメント](https://docs.dynatrace.com/docs/shortlink/aws-devops-agent)を参照してください。 ### ステップ 3: Dynatrace 環境を設定する Dynatrace のセットアップを完了するには、Dynatrace 環境で特定のセットアップ手順を実行する必要があります。[Dynatrace ドキュメント](https://docs.dynatrace.com/docs/shortlink/aws-devops-agent)の指示に従ってください。 #### サポートされているイベントスキーマ AWS DevOps Agent は、ウェブフックを使用した Dynatrace からの 2 種類のイベントをサポートします。サポートされているイベントスキーマを以下に示します。 ##### インシデントイベント インシデントイベントは、調査をトリガーするために使用されます。イベントスキーマは次のとおりです。 ``` { "event.id": string; "event.status": "ACTIVE" | "CLOSED"; "event.status_transition": string; "event.description": string; "event.name": string; "event.category": "AVAILABILITY" | "ERROR" | "SLOWDOWN" | "RESOURCE_CONTENTION" | "CUSTOM_ALERT" | "MONITORING_UNAVAILABLE" | "INFO"; "event.start"?: string; "affected_entity_ids"?: string[]; } ``` ##### 緩和イベント 緩和イベントは、次のステップの調査の緩和レポートの生成をトリガーするために使用されます。イベントスキーマは次のとおりです。 ``` { "task_id": string; "task_version": number; "event.type": "mitigation_request"; } ``` ## 削除 テレメトリソースは、エージェントスペースレベルとアカウントレベルで 2 つのレベルで接続されます。これを完全に削除するには、まずそれを使用するすべてのエージェントスペースから削除してから、登録を解除する必要があります。 ### ステップ 1: エージェントスペースから削除する 1. エージェントスペースページからエージェントスペースを選択し、詳細の表示を押します。 1. 機能タブを選択する 1. Telemetry セクションまで下にスクロールします。 1. Dynatrace を選択する 1. 削除を押す ### ステップ 2: アカウントから登録解除する 1. **機能プロバイダー**ページに移動する (サイドナビゲーションからアクセス可能) 1. **現在登録**されているセクションまでスクロールします。 1. エージェントスペース数がゼロであることを確認します (他のエージェントスペースで上記のステップ 1 を繰り返しない場合）。 1. Dynatrace の横にある登録解除を押します # DataDog の接続 ## 組み込みの 1 方向統合 現在、 AWS DevOps Agent は、組み込みの 1 方向統合で Datadog ユーザーをサポートし、以下を有効にします。 + **自動調査トリガー** - Datadog イベントは、 AWS DevOps エージェントウェブフックを介して AWS DevOps エージェントインシデント解決調査をトリガーするように設定できます。 + **テレメトリイントロスペクション** - AWS DevOps Agent は、各プロバイダーのリモート MCP サーバーを介して問題を調査する際に、Datadog テレメトリをイントロスペクションできます。 ## オンボーディング ### ステップ 1: 接続する アカウントアクセス認証情報を使用して Datadog リモート MCP エンドポイントへの接続を確立する #### 設定 1. **機能プロバイダー**ページに移動する (サイドナビゲーションからアクセス可能) 1. テレメトリの**「利用可能な**プロバイダー」セクションで **Datadog** を検索し、**登録**をクリックします **** 1. Datadog MCP サーバーの詳細を入力します。 + **サーバー名** - 一意の識別子 (例: my-datadog-server) + **エンドポイント URL** - Datadog MCP サーバーエンドポイント。エンドポイント URL は、Datadog サイトによって異なります。以下の Datadog サイトエンドポイント表を参照してください。 + **説明** - オプションのサーバーの説明 1. [次へ] をクリックします。 1. レビューして送信 #### Datadog サイトエンドポイント MCP エンドポイント URL は、Datadog サイトによって異なります。サイトを識別するには、Datadog にログインしたときにブラウザの URL を確認するか、[「Datadog サイトへのアクセス](https://docs.datadoghq.com/getting_started/site/#access-the-datadog-site)」を参照してください。 | Datadog サイト | サイトドメイン | MCP エンドポイント URL | | --- | --- | --- | | US1 (デフォルト) | datadoghq.com | https://mcp.datadoghq.com/api/unstable/mcp-server/mcp | | US3 | us3.datadoghq.com | https://mcp.us3.datadoghq.com/api/unstable/mcp-server/mcp | | US5 | us5.datadoghq.com | https://mcp.us5.datadoghq.com/api/unstable/mcp-server/mcp | | EU1 | datadoghq.eu | https://mcp.datadoghq.eu/api/unstable/mcp-server/mcp | | AP1 | ap1.datadoghq.com | https://mcp.ap1.datadoghq.com/api/unstable/mcp-server/mcp | | AP2 | ap2.datadoghq.com | https://mcp.ap2.datadoghq.com/api/unstable/mcp-server/mcp | #### Authorization 次の方法で OAuth 認可を完了します。 + Datadog OAuth ページでユーザーとして を承認する + ログインしていない場合は、許可、ログイン、認可 をクリックします。 設定すると、Datadog はすべてのエージェントスペースで使用可能になります。 ### ステップ 2: を有効にする 特定のエージェントスペースで DataDog をアクティブ化し、適切なスコープを設定する #### 設定 1. エージェントスペースページからエージェントスペースを選択し、表示の詳細を押します (エージェントスペースをまだ作成していない場合は、「」を参照してください[エージェントスペースの作成](getting-started-with-aws-devops-agent-creating-an-agent-space.md))。 1. 機能タブを選択する 1. Telemetry セクションまで下にスクロールします。 1. 追加を押す 1. Datadog を選択する 1. 次へ 1. 確認して Save キーを押します。 1. Webhook URL と API キーをコピーする ### ステップ 3: ウェブフックを設定する Webhook URL と API キーを使用して、Datadog を設定して、アラームなどから調査をトリガーするようにイベントを送信できます。 DevOps エージェントによって送信されるイベントを使用できるようにするには、ウェブフックに送信されるデータが以下で指定されたデータスキーマと一致していることを確認してください。このスキーマに一致しないイベントは、DevOps エージェントによって無視される場合があります。 メソッドとヘッダーを設定する ``` method: "POST", headers: { "Content-Type": "application/json", "Authorization": "Bearer ", }, ``` 本文を JSON 文字列として送信します。 ``` { eventType: 'incident'; incidentId: string; action: 'created' | 'updated' | 'closed' | 'resolved'; priority: "CRITICAL" | "HIGH" | "MEDIUM" | "LOW" | "MINIMAL"; title: string; description?: string; timestamp?: string; service?: string; // The original event generated by service is attached here. data?: object; } ``` Datadog [https://docs.datadoghq.com/integrations/webhooks/](https://docs.datadoghq.com/integrations/webhooks/) を使用してウェブフックを送信します (承認を選択せず、代わりにカスタムヘッダーオプションを使用することに注意してください）。 詳細: [Datadog リモート MCP サーバー](https://www.datadoghq.com/blog/datadog-remote-mcp-server/) ## 削除 テレメトリソースは、エージェントスペースレベルとアカウントレベルで 2 つのレベルで接続されます。これを完全に削除するには、まず、それが使用されているすべてのエージェントスペースから削除してから、登録を解除する必要があります。 ### ステップ 1: エージェントスペースから削除する 1. エージェントスペースページからエージェントスペースを選択し、詳細の表示を押します。 1. 機能タブを選択する 1. Telemetry セクションまで下にスクロールします。 1. Datadog を選択する 1. 削除を押す ### ステップ 2: アカウントから登録解除する 1. **機能プロバイダー**ページに移動する (サイドナビゲーションからアクセス可能) 1. **現在登録**されているセクションにスクロールします。 1. エージェントスペース数がゼロであることを確認します (他のエージェントスペースで上記のステップ 1 を繰り返しない場合）。 1. Datadog の横にある登録解除を押します # Grafana の接続 Grafana 統合により、 AWS DevOps Agent はインシデント調査中に Grafana インスタンスからメトリクス、ダッシュボード、アラートデータをクエリできます。この統合は、Grafana のアカウントレベルの登録と、個々のエージェントスペースへの接続という 2 つのステップのプロセスに従います。 セキュリティを向上させるために、Grafana 統合は読み取り専用ツールのみを有効にします。書き込みツールは無効になっており、有効にすることはできません。つまり、エージェントは Grafana インスタンスからデータをクエリおよび読み取ることができますが、ダッシュボード、アラート、注釈などの Grafana リソースを作成、変更、または削除することはできません。詳細については、「[Security in AWS DevOps Agent](https://docs.aws.amazon.com/devopsagent/latest/userguide/aws-devops-agent-security.html)」を参照してください。 ## Grafana の要件 Grafana を接続する前に、以下を確認してください。 + Grafana バージョン 9.0 以降。一部の機能、特にデータソース関連のオペレーションは、API エンドポイントがないため、以前のバージョンでは正しく動作しない場合があります。 + HTTPS 経由でアクセス可能な Grafana インスタンス。パブリックネットワークエンドポイントとプライベートネットワークエンドポイントの両方がサポートされています。プライベートネットワーク接続では、Grafana インスタンスをパブリックインターネットアクセスなしで VPC 内でホストできます。詳細については、「[プライベートにホストされたツールへの接続](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md)」を参照してください。 + 適切な読み取りアクセス許可を持つアクセストークンを持つ Grafana サービスアカウント ## Grafana の登録 (アカウントレベル) Grafana は AWS アカウントレベルで登録され、そのアカウントのすべてのエージェントスペース間で共有されます。 ### ステップ 1: Grafana を設定する 1. AWS マネジメントコンソールにサインインする 1. AWS DevOps エージェントコンソールに移動する 1. **機能プロバイダー**ページに移動する (サイドナビゲーションからアクセス可能) 1. Telemetry の**「利用可能な**プロバイダー」セクションで **Grafana** を検索し、**登録**をクリックします **** 1. **Grafana の設定**ページで、次の情報を入力します。 + **サービス名** (必須) – 英数字、ハイフン、アンダースコアのみを使用して、Grafana サーバーのわかりやすい名前を入力します。例えば、`my-grafana-server`。 + **Grafana URL** (必須) – Grafana インスタンスの完全な HTTPS URL を入力します。例えば、`https://myinstance.grafana.net`。 + **サービスアカウントアクセストークン** (必須) – Grafana サービスアカウントアクセストークンを入力します。トークンは通常、 で始まります`glsa_`。サービスアカウントトークンを作成するには、Grafana インスタンスに移動し、**管理 > サービスアカウント**に移動し、ビューワーロールを使用してサービスアカウントを作成し、トークンを生成します。 + **説明** (オプション) – サーバーの目的を特定するのに役立つ説明を追加します。例えば、`Production Grafana server for monitoring`。 1. (オプション) 組織の目的で登録に AWS タグを追加します。 1. **[次へ]** をクリックします。 ### ステップ 2: Grafana 登録を確認して送信する 1. Grafana 設定の詳細をすべて確認する 1. **送信**をクリックして登録を完了します 1. 登録が成功すると、Grafana は機能プロバイダーページの**現在登録**されているセクションに表示されます。 ## エージェントスペースへの Grafana の追加 アカウントレベルで Grafana を登録したら、個々のエージェントスペースに接続できます。 1. AWS DevOps エージェントコンソールで、エージェントスペースを選択します。 1. **機能**タブに移動する 1. **テレメトリ**セクションで、**追加** をクリックします。 1. 利用可能なプロバイダーのリストから **Grafana** を選択する 1. **保存 **をクリックします。 ## Grafana アラートウェブフックの設定 Grafana コンタクトポイントを介してウェブフックを送信することで、アラートが発生したときに AWS DevOps エージェント調査を自動的にトリガーするように Grafana を設定できます。ウェブフック認証方法と認証情報管理の詳細については、「」を参照してください[Webhook による DevOps エージェントの呼び出し](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md)。 ### ステップ 1: カスタム通知テンプレートを作成する Grafana インスタンスで、**アラート > コンタクトポイント > 通知テンプレート**に移動し、次の内容の新しいテンプレートを作成します。 ``` {{ define "devops-agent-payload" }} { "eventType": "incident", "incidentId": "{{ (index .Alerts 0).Labels.alertname }}-{{ (index .Alerts 0).Fingerprint }}", "action": "{{ if eq .Status "resolved" }}resolved{{ else }}created{{ end }}", "priority": "{{ if eq .Status "resolved" }}MEDIUM{{ else }}HIGH{{ end }}", "title": "{{ (index .Alerts 0).Labels.alertname }}", "description": "{{ (index .Alerts 0).Annotations.summary }}", "service": "{{ if (index .Alerts 0).Labels.job }}{{ (index .Alerts 0).Labels.job }}{{ else }}grafana{{ end }}", "timestamp": "{{ (index .Alerts 0).StartsAt }}", "data": { "metadata": { {{ range $k, $v := (index .Alerts 0).Labels }} "{{ $k }}": "{{ $v }}", {{ end }} "_source": "grafana" } } } {{ end }} ``` このテンプレートは、Grafana アラートを AWS DevOps Agent が期待するウェブフックペイロード構造にフォーマットします。アラートラベル、注釈、ステータスを適切なフィールドにマッピングし、すべてのアラートラベルをメタデータとして含めます。 **注:** このテンプレートは、グループ内の最初のアラートのみを処理します。Grafana は、デフォルトで複数の発射アラートを 1 つの通知にグループ化します。各アラートが個別に送信されるようにするには、 でグループ化するように通知ポリシーを設定します`alertname`。さらに、このテンプレートはラベル値または注釈の特殊な JSON 文字をエスケープしません。アラートラベルと`summary`注釈に二重引用符や改行などの文字が含まれていないことを確認すると、無効な JSON が生成されます。 ### ステップ 2: ウェブフックコンタクトポイントを作成する 1. Grafana でアラート **> コンタクトポイント**に移動し、**コンタクトポイントの追加**をクリックします 1. 統合タイプとして **Webhook** を選択する 1. AWS DevOps Agent ウェブフックエンドポイントへの **URL** の設定 1. **オプションのウェブフック設定**で、ウェブフックタイプに基づいて認証ヘッダーを設定します。詳細については、[「Webhook 認証方法](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md)」を参照してください。 1. カスタムテンプレートを使用するように **Message** フィールドを設定します。 `{{ template "devops-agent-payload" . }}` 1. **コンタクトポイントの保存** をクリックします。 ### ステップ 3: コンタクトポイントを通知ポリシーに割り当てる 1. **アラート > 通知ポリシー**に移動する 1. 既存のポリシーを編集するか、新しいポリシーを作成します。 1. 作成したウェブフックコンタクトポイントにコンタクトポイントを設定する 1. **ポリシーの保存** をクリックします。 一致するアラートが発生すると、Grafana はフォーマットされたペイロードを AWS DevOps エージェントに送信し、これにより自動的に調査が開始されます。 ## 制限事項 + **ClickHouse データソースツール** – ClickHouse データソースツールは現在サポートされていません。 + **プロアクティブインシデント防止** – は現在 Grafana ツールを使用し[プロアクティブインシデント防止](working-with-devops-agent-proactive-incident-prevention.md)ません。サポートは今後のリリースが予定されています。 ### Amazon Managed Grafana に関する考慮事項 [Amazon Managed Grafana](https://aws.amazon.com/grafana/) (AMG) を使用している場合は、次の制限に注意してください。 + **Webhook コンタクトポイントはサポートされていません** – AMG は現在、アラート設定で Webhook コンタクトポイントをサポートしていません。AMG を使用してアラートウェブフックを AWS DevOps エージェントに直接送信することはできません。詳細については、[「Amazon Managed Grafana でのコンタクトポイントのアラート](https://docs.aws.amazon.com/grafana/latest/userguide/v9-alerting-explore-contacts.html)」を参照してください。 + **サービスアカウントトークンの有効期限** – AMG サービスアカウントトークンの最大有効期限は 30 日です。トークンをローテーションし、有効期限が切れる前に AWS DevOps Agent で Grafana 登録を更新する必要があります。認証情報を更新する方法については、[「Grafana 接続の管理](#managing-grafana-connections)」を参照してください。AMG トークンの制限の詳細については、[「Amazon Managed Grafana のサービスアカウント](https://docs.aws.amazon.com/grafana/latest/userguide/service-accounts.html)」を参照してください。 ## Grafana 接続の管理 + **認証情報の更新** – サービスアカウントトークンの有効期限が切れるか、更新する必要がある場合は、機能プロバイダーページから Grafana を登録解除し、新しいトークンに再登録します。 + **接続されたインスタンスの表示** – AWS DevOps エージェントコンソールで、エージェントスペースを選択し、機能タブに移動して、接続されたテレメトリソースを表示します。 + **Grafana の削除** – エージェントスペースから Grafana を切断するには、テレメトリセクションでそれを選択し、**削除**をクリックします。登録を完全に削除するには、まずすべてのエージェントスペースから削除してから、機能プロバイダーページから登録を解除します。 # New Relic の接続 ## 組み込みの 1 方向統合 現在、 AWS DevOps Agent は、組み込みの 1 方向統合で New Relic ユーザーをサポートし、以下を有効にします。 + **自動調査トリガー** - New Relic イベントは、 AWS DevOps エージェントウェブフックを介して AWS DevOps エージェントインシデント解決調査をトリガーするように設定できます。 + **テレメトリのイントロスペクション** - AWS DevOps Agent は、各プロバイダーのリモート MCP サーバーを介して問題を調査する際に、New Relic テレメトリをイントロスペクションできます。 ## オンボーディング ### ステップ 1: 接続する アカウントアクセス認証情報を使用して New Relic リモート MCP エンドポイントへの接続を確立する New Relic MCP ツールを有効にするには、New Relic でフルプラットフォームユーザー (ベーシック/コアではない) を使用してください。 #### 設定 1. **機能プロバイダー**ページに移動する (サイドナビゲーションからアクセス可能) 1. Telemetry の**「利用可能な**プロバイダー」セクションで **New Relic** を検索し、**登録**をクリックします **** 1. 手順に従って New Relic API キーを取得します。 1. New Relic MCP サーバー API キーの詳細を入力します。 + **アカウント ID:** 上記で取得した New Relic アカウント ID を入力します。 + **API キー:** 上記の API キーを入力します。 + New Relic アカウントの場所に基づいて、**米国または欧州のリージョン**を選択します。 1. 追加をクリックします。 ### ステップ 2: を有効にする 特定のエージェントスペースで New Relic をアクティブ化し、適切なスコープを設定する #### 設定 1. エージェントスペースページからエージェントスペースを選択し、表示の詳細を押します (エージェントスペースをまだ作成していない場合は、「」を参照してください[エージェントスペースの作成](getting-started-with-aws-devops-agent-creating-an-agent-space.md))。 1. 機能タブを選択する 1. Telemetry セクションまで下にスクロールします。 1. 追加を押す 1. New Relic を選択する 1. 次へ 1. 確認して保存を押します 1. Webhook URL と API キーのコピー ### ステップ 3: ウェブフックを設定する Webhook URL と API キーを使用して、New Relic を設定して、アラームなどから調査をトリガーするようにイベントを送信できます。ウェブフックの設定の詳細については、[「変更追跡ウェブフック](https://docs.newrelic.com/docs/change-tracking/change-tracking-webhooks/)」を参照してください。 DevOps エージェントによって送信されるイベントを使用できるようにするには、ウェブフックに送信されるデータが以下に指定されたデータスキーマと一致していることを確認してください。このスキーマに一致しないイベントは、DevOps エージェントによって無視される場合があります。 メソッドとヘッダーを設定する ``` method: "POST", headers: { "Content-Type": "application/json", "Authorization": "Bearer ", }, ``` 本文を JSON 文字列として送信します。 ``` { eventType: 'incident'; incidentId: string; action: 'created' | 'updated' | 'closed' | 'resolved'; priority: "CRITICAL" | "HIGH" | "MEDIUM" | "LOW" | "MINIMAL"; title: string; description?: string; timestamp?: string; service?: string; // The original event generated by service is attached here. data?: object; } ``` New Relic [https://newrelic.com/instant-observability/webhook-notifications](https://newrelic.com/instant-observability/webhook-notifications) を使用してウェブフックを送信します。認可タイプにベアラートークンを選択するか、認可を選択せずに をカスタムヘッダー`Authorization: Bearer `として追加できます。 詳細については、[https://docs.newrelic.com/docs/agentic-ai/mcp/overview/](https://docs.newrelic.com/docs/agentic-ai/mcp/overview/) を参照してください。 ## 削除 テレメトリソースは、エージェントスペースレベルとアカウントレベルで 2 つのレベルで接続されます。これを完全に削除するには、まずそれを使用するすべてのエージェントスペースから削除してから、登録を解除する必要があります。 ### ステップ 1: エージェントスペースから削除する 1. エージェントスペースページからエージェントスペースを選択し、詳細の表示を押します。 1. 機能タブを選択する 1. Telemetry セクションまで下にスクロールします。 1. New Relic を選択する 1. 削除を押す ### ステップ 2: アカウントから登録解除する 1. **機能プロバイダー**ページに移動する (サイドナビゲーションからアクセス可能) 1. **現在登録**されているセクションにスクロールします。 1. エージェントスペース数がゼロであることを確認します (他のエージェントスペースで上記のステップ 1 を繰り返しない場合）。 1. New Relic の横にある登録解除を押します # Splunk の接続 ## 組み込みの 1 方向統合 現在、 AWS DevOps Agent は、組み込みの 1 方向統合で Splunk ユーザーをサポートし、以下を有効にします。 + **自動調査トリガー** - Splunk イベントは、 AWS DevOps Agent ウェブフックを介して AWS DevOps Agent インシデント解決調査をトリガーするように設定できます。 + **テレメトリイントロスペクション** - AWS DevOps Agent は、各プロバイダーのリモート MCP サーバーを介して問題を調査する際に、Splunk テレメトリをイントロスペクションできます。 ## 前提条件 ### Splunk API トークンの取得 Splunk を接続するには、MCP URL とトークンが必要です。 ### Splunk 管理者のステップ Splunk 管理者は、次の手順を実行する必要があります。 + [REST API アクセス](https://docs.splunk.com/Documentation/SplunkCloud/latest/RESTTUT/RESTandCloud)を有効にする + デプロイで[トークン認証を有効にします](https://help.splunk.com/en/splunk-cloud-platform/administer/manage-users-and-security/9.2.2406/authenticate-into-the-splunk-platform-with-tokens/enable-or-disable-token-authentication)。 + 新しいロール「mcp\$1user」を作成すると、新しいロールには機能は必要ありません。 + MCP サーバーの使用が許可されているデプロイのすべてのユーザーにロール 'mcp\$1user' を割り当てます。 + ユーザー自身にトークンを作成するアクセス許可がない場合は、対象者を「mcp」として承認されたユーザーのトークンを作成し、適切な有効期限を設定します。 ### Splunk ユーザーステップ Splunk ユーザーは、次のステップを実行する必要があります。 + アクセス許可がある場合は、Splunk 管理者から適切なトークンを取得するか、自分でトークンを作成します。トークンの対象者は「mcp」である必要があります。 ## オンボーディング ### ステップ 1: 接続する アカウントアクセス認証情報を使用して Splunk リモート MCP エンドポイントへの接続を確立する #### 設定 1. **機能プロバイダー**ページに移動する (サイドナビゲーションからアクセス可能) 1. Telemetry の**「利用可能な**プロバイダー」セクションで **Splunk** を検索し、**「登録**」をクリックします。 **** 1. Splunk MCP サーバーの詳細を入力します。 + **サーバー名** - 一意の識別子 (my-splunk-server など) + **エンドポイント URL** - Splunk MCP サーバーエンドポイント: `https://.api.scs.splunk.com//mcp/v1/` + **説明** - オプションのサーバーの説明 + **トークン名** - 認証用のベアラートークンの名前。 `my-splunk-token` + **トークン値** 認証のベアラートークン値 ### ステップ 2: を有効にする 特定のエージェントスペースで Splunk をアクティブ化し、適切なスコープを設定する #### 設定 1. エージェントスペースページからエージェントスペースを選択し、表示の詳細を押します (エージェントスペースをまだ作成していない場合は、「」を参照してください[エージェントスペースの作成](getting-started-with-aws-devops-agent-creating-an-agent-space.md))。 1. 機能タブを選択する 1. Telemetry セクションまで下にスクロールします。 1. 追加を押す 1. Splunk を選択する 1. 次へ 1. 確認して Save キーを押します。 1. Webhook URL と API キーをコピーする ### ステップ 3: ウェブフックを設定する Webhook URL と API キーを使用して、 アラームなどから調査をトリガーするイベントを送信するように Splunk を設定できます。 DevOps エージェントによって送信されるイベントを使用できるようにするには、ウェブフックに送信されるデータが以下で指定されたデータスキーマと一致していることを確認してください。このスキーマに一致しないイベントは、DevOps エージェントによって無視される場合があります。 メソッドとヘッダーを設定する ``` method: "POST", headers: { "Content-Type": "application/json", "Authorization": "Bearer ", }, ``` 本文を JSON 文字列として送信します。 ``` { eventType: 'incident'; incidentId: string; action: 'created' | 'updated' | 'closed' | 'resolved'; priority: "CRITICAL" | "HIGH" | "MEDIUM" | "LOW" | "MINIMAL"; title: string; description?: string; timestamp?: string; service?: string; // The original event generated by service is attached here. data?: object; } ``` Splunk [https://help.splunk.com/en/splunk-enterprise/alert-and-respond/alerting-manual/9.4/configure-alert-actions/use-a-webhook-alert-action](https://help.splunk.com/en/splunk-enterprise/alert-and-respond/alerting-manual/9.4/configure-alert-actions/use-a-webhook-alert-action) でウェブフックを送信する (承認なしで選択し、代わりにカスタムヘッダーオプションを使用することに注意してください) ### 詳細はこちら: + Splunk の MCP サーバードキュメント: [https://help.splunk.com/en/splunk-cloud-platform/mcp-server-for-splunk-platform/about-mcp-server-for-splunk-platform ](https://help.splunk.com/en/splunk-cloud-platform/mcp-server-for-splunk-platform/about-mcp-server-for-splunk-platform) + Splunk Cloud Platform REST API のアクセス要件と制限: [https://docs.splunk.com/Documentation/SplunkCloud/latest/RESTTUT/RESTandCloud ](https://docs.splunk.com/Documentation/SplunkCloud/latest/RESTTUT/RESTandCloud) + Splunk Cloud Platform で認証トークンを管理する: [https://help.splunk.com/en/splunk-cloud-platform/administer/manage-users-and-security/9.3.2411/authenticate-into-the-splunk-platform-with-tokens/manage-or-delete-authentication-tokens ](https://help.splunk.com/en/splunk-cloud-platform/administer/manage-users-and-security/9.3.2411/authenticate-into-the-splunk-platform-with-tokens/manage-or-delete-authentication-tokens) + Splunk Web を使用したロールの作成と管理: [https://docs.splunk.com/Documentation/SplunkCloud/latest/Security/Addandeditroles ](https://docs.splunk.com/Documentation/SplunkCloud/latest/Security/Addandeditroles) ## 削除 テレメトリソースは、エージェントスペースレベルとアカウントレベルで 2 つのレベルで接続されます。完全に削除するには、最初にそれを使用するすべてのエージェントスペースから削除してから、登録を解除する必要があります。 ### ステップ 1: エージェントスペースから削除する 1. エージェントスペースページからエージェントスペースを選択し、詳細の表示を押します。 1. 機能タブを選択する 1. Telemetry セクションまで下にスクロールします。 1. Splunk を選択する 1. 削除を押す ### ステップ 2: アカウントから登録解除する 1. **機能プロバイダー**ページに移動する (サイドナビゲーションからアクセス可能) 1. **現在登録**されているセクションにスクロールします。 1. エージェントスペース数がゼロであることを確認します (他のエージェントスペースで上記のステップ 1 を繰り返しない場合）。 1. Splunk の横にある登録解除を押します # チケット発行とチャットへの接続 AWS DevOps エージェントは、チームの既存のコミュニケーションチャネルに参加することで、チームのメンバーとして機能するように設計されています。DevOps エージェントを ServiceNow や PagerDuty などのチケット発行およびアラームシステムに接続して、インシデントチケットから調査を自動的に開始し、既存のワークフロー内のインシデント対応を加速して、意図した復旧時間 (MTTR) を短縮できます。DevOps エージェントを Slack などのチームコラボレーションシステムに接続して、チャットチャネルで DevOps エージェントからアクティビティの概要を受信することもできます。 チケット発行とチャット統合の接続については、以下を参照してください。 + [PagerDuty の接続](connecting-to-ticketing-and-chat-connecting-pagerduty.md) + [ServiceNow の接続](connecting-to-ticketing-and-chat-connecting-servicenow.md) + [Slack の接続](connecting-to-ticketing-and-chat-connecting-slack.md) # PagerDuty の接続 PagerDuty の統合により、 AWS DevOps Agent はインシデント調査と自動対応中に PagerDuty アカウントからインシデントデータ、オンコールスケジュール、サービス情報にアクセスして更新できます。この統合では、OAuth 2.0 を使用して安全な認証を行います。 **重要** ** AWS DevOps エージェントは、新しい PagerDuty OAuth 2.0 (スコープ付き OAuth) のみをサポートします。リダイレクト uri を使用するレガシー PagerDuty OAuth はサポートされていません。 ## PagerDuty の要件 PagerDuty を接続する前に、以下を確認してください。 + OAuth クライアント ID とクライアントシークレットを持つ PagerDuty アカウント + PagerDuty アカウントのサブドメイン (たとえば、PagerDuty URL が の場合`https://your-company.pagerduty.com`、サブドメインは `your-company`) ## PagerDuty の登録 PagerDuty は AWS アカウントレベルで登録され、そのアカウントのすべてのエージェントスペース間で共有されます。 ### ステップ 1: PagerDuty でアクセスを設定する 1. AWS マネジメントコンソールにサインインする 1. AWS DevOps エージェントコンソールに移動する 1. **機能プロバイダー**ページに移動する (サイドナビゲーションからアクセス可能) 1. **「コミュニケーション**」の**「利用可能な**プロバイダー」セクションで **PagerDuty** を検索し、**「登録**」をクリックします。 1. **PagerDuty の「アクセスの設定**」ページのガイド付きセットアップに従います。 **サービスリージョンとサブドメインを確認します。** + **アカウントスコープ** – PagerDuty リージョン (**米国**または**欧州**) を選択し、PagerDuty サブドメインを入力します。たとえば、PagerDuty URL が の場合`https://your-company.pagerduty.com`、 と入力します`your-company`。 **PagerDuty で新しいアプリを作成します。** + 別のブラウザタブで PagerDuty にログインし、**統合 > アプリ登録**に移動します。 + **OAuth 2.0 スコープド OAuth **を使用して新しいアプリケーションを作成する + **「アクセス許可**」で、最低限必要なスコープ `incidents.read`、`incidents.write`、および を付与します。 `services.read` + **イベント統合**を有効にして、 AWS DevOps Agent と PagerDuty 間の双方向通信を許可する **OAuth 認証情報を設定します。** + アクセス**許可の範囲** – 最低限必要な範囲は、`incidents.read`、`incidents.write`、 です。 `services.read` + **クライアント名** – OAuth クライアントのわかりやすい名前を入力します。 + **クライアント ID** – PagerDuty アプリ登録から OAuth クライアント ID を入力します。 + **クライアントシークレット** – PagerDuty アプリ登録から OAuth クライアントシークレットを入力します。 ### ステップ 2: PagerDuty 登録を確認して送信する 1. PagerDuty 設定の詳細をすべて確認する 1. **送信**をクリックして登録を完了します 1. 登録が成功すると、PagerDuty は機能プロバイダーページの**現在登録**されているセクションに表示されます。 ## エージェントスペースへの PagerDuty の追加 PagerDuty をアカウントレベルで登録したら、個々のエージェントスペースに接続できます。 1. AWS DevOps エージェントコンソールで、エージェントスペースを選択します。 1. **機能**タブに移動する 1. **「コミュニケーション**」セクションで、**「追加**」をクリックします。 1. 利用可能なプロバイダーのリストから **PagerDuty** を選択する 1. **保存 **をクリックします。 ## PagerDuty 接続の管理 + **認証情報の更新** – OAuth 認証情報を更新する必要がある場合は、機能プロバイダーページから PagerDuty を登録解除し、新しい認証情報で再登録します。 + **接続の表示** – AWS DevOps エージェントコンソールで、エージェントスペースを選択し、機能タブに移動して、接続された通信統合を表示します。 + **PagerDuty の削除** – PagerDuty をエージェントスペースから切断するには、コミュニケーションセクションでそれを選択し、**削除**をクリックします。登録を完全に削除するには、まずすべてのエージェントスペースから削除してから、機能プロバイダーページから登録を解除します。 ## Webhook のサポート AWS DevOps エージェントは PagerDuty V3 ウェブフックのみをサポートします。以前のウェブフックバージョンはサポートされていません。 PagerDuty V3 ウェブフックサブスクリプションの詳細については、PagerDuty デベロッパードキュメントの[「Webhooks Overview](https://developer.pagerduty.com/docs/webhooks-overview#webhook-subscriptions)」を参照してください。 # ServiceNow の接続 このチュートリアルでは、ServiceNow インスタンスを AWS DevOps エージェントに接続して、チケットの作成時にインシデント対応調査を自動的に開始し、主要な検出結果を元のチケットに投稿できるようにします。また、特定のチケットのみを DevOps エージェントスペースに送信するように ServiceNow インスタンスを設定する方法と、複数の DevOps エージェントスペース間でチケットルーティングを調整する方法の例も含まれています。 ## 初期セットアップ 最初のステップは、 AWS DevOps が ServiceNow インスタンスにアクセスするために使用できる OAuth アプリケーションクライアントを ServiceNow に作成することです。 ### ServiceNow OAuth アプリケーションクライアントを作成する 1. インスタンスのクライアント認証情報システムプロパティを有効にする 1. フィルター検索ボックス`sys_properties.list`で検索し、Enter キーを押します ( オプションは表示されませんが、Enter キーを押すと機能します）。 1. 新規を選択する 1. 名前を `glide.oauth.inbound.client.credential.grant_type.enabled`、値を true に追加し、型を true \$1 false ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/devopsagent/latest/userguide/images/09ed6d5ff911.png) 1. フィルター検索ボックスから System OAuth > Application Registry に移動します。 1. 「新規」 >「新しいインバウンド統合エクスペリエンス」 >「新しい統合」 >OAuth - クライアント認証情報付与」を選択します。 1. 名前を選択し、OAuth アプリケーションユーザーを「問題管理者」に設定し、「保存」をクリックします。 ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/devopsagent/latest/userguide/images/aeff4c127f7c.png) ### ServiceNow OAuth クライアントを AWS DevOps エージェントに接続する 1. このプロセスは 2 つの場所で開始できます。まず、**Capability Providers** ページに移動し、**Communication** で **ServiceNow** を見つけ、**Register** をクリックします。または、作成した DevOps エージェントスペースを選択して、機能 → 通信 → 追加 → ServiceNow に移動し、登録をクリックします。 1. 次に、先ほど作成した OAuth アプリケーションクライアントを使用して、DevOps Agent が ServiceNow インスタンスにアクセスすることを許可します。 ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/devopsagent/latest/userguide/images/3db5a9aafc5f.png) + 次のステップに従い、ウェブフックに関する結果情報を保存します。 **重要** この情報は再度表示されません ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/devopsagent/latest/userguide/images/80d0a319f87e.png) ### ServiceNow ビジネスルールを設定する 接続を確立したら、ServiceNow でビジネスルールを設定して、DevOps エージェントスペース (複数可) にチケットを送信する必要があります。 1. アクティビティサブスクリプション → 管理 → ビジネスルールに移動し、新規をクリックします。 1. 「Table」フィールドを「Incident [incident]」に設定し、「Advanced」チェックボックスをオンにして、挿入、更新、削除後にルールを実行するように設定します。 ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/devopsagent/latest/userguide/images/6f2a7370e2c0.png) 1. 「詳細」タブに移動し、次のウェブフックスクリプトを追加し、ウェブフックシークレットと URL を指定された場所に挿入して、送信をクリックします。 ``` (function executeRule(current, previous /*null when async*/ ) { var WEBHOOK_CONFIG = { webhookSecret: GlideStringUtil.base64Encode('<<< INSERT WEBHOOK SECRET HERE >>>'), webhookUrl: '<<< INSERT WEBHOOK URL HERE >>>' }; function generateHMACSignature(payloadString, secret) { try { var mac = new GlideCertificateEncryption(); var signature = mac.generateMac(secret, "HmacSHA256", payloadString); return signature; } catch (e) { gs.error('HMAC generation failed: ' + e); return null; } } function callWebhook(payload, config) { try { var timestamp = new Date().toISOString(); var payloadString = JSON.stringify(payload); var payloadWithTimestamp =`${timestamp}:${payloadString}`; var signature = generateHMACSignature(payloadWithTimestamp, config.webhookSecret); if (!signature) { gs.error('Failed to generate signature'); return false; } gs.info('Generated signature: ' + signature); var request = new sn_ws.RESTMessageV2(); request.setEndpoint(config.webhookUrl); request.setHttpMethod('POST'); request.setRequestHeader('Content-Type', 'application/json'); request.setRequestHeader('x-amzn-event-signature', signature); request.setRequestHeader('x-amzn-event-timestamp', timestamp); request.setRequestBody(payloadString); var response = request.execute(); var httpStatus = response.getStatusCode(); var responseBody = response.getBody(); if (httpStatus >= 200 && httpStatus < 300) { gs.info('Webhook sent successfully. Status: ' + httpStatus); return true; } else { gs.error('Webhook failed. Status: ' + httpStatus + ', Response: ' + responseBody); return false; } } catch (ex) { gs.error('Error sending webhook: ' + ex.getMessage()); return false; } } function createReference(field) { if (!field || field.nil()) { return null; } return { link: field.getLink(true), value: field.toString() }; } function getStringValue(field) { if (!field || field.nil()) { return null; } return field.toString(); } function getIntValue(field) { if (!field || field.nil()) { return null; } var val = parseInt(field.toString()); return isNaN(val) ? null : val; } var eventType = (current.operation() == 'insert') ? "create" : "update"; var incidentEvent = { eventType: eventType.toString(), sysId: current.sys_id.toString(), priority: getStringValue(current.priority), impact: getStringValue(current.impact), active: getStringValue(current.active), urgency: getStringValue(current.urgency), description: getStringValue(current.description), shortDescription: getStringValue(current.short_description), parent: getStringValue(current.parent), incidentState: getStringValue(current.incident_state), severity: getStringValue(current.severity), problem: createReference(current.problem), additionalContext: {} }; incidentEvent.additionalContext = { number: current.number.toString(), opened_at: getStringValue(current.opened_at), opened_by: current.opened_by.nil() ? null : current.opened_by.getDisplayValue(), assigned_to: current.assigned_to.nil() ? null : current.assigned_to.getDisplayValue(), category: getStringValue(current.category), subcategory: getStringValue(current.subcategory), knowledge: getStringValue(current.knowledge), made_sla: getStringValue(current.made_sla), major_incident: getStringValue(current.major_incident) }; for (var key in incidentEvent.additionalContext) { if (incidentEvent.additionalContext[key] === null) { delete incidentEvent.additionalContext[key]; } } gs.info(JSON.stringify(incidentEvent, null, 2)); // Pretty print for logging only if (WEBHOOK_CONFIG.webhookUrl && WEBHOOK_CONFIG.webhookSecret) { callWebhook(incidentEvent, WEBHOOK_CONFIG); } else { gs.info('Webhook not configured.'); } })(current, previous); ``` **機能プロバイダー**ページから ServiceNow 接続を登録する場合は、ServiceNow インシデントチケットを調査する DevOps エージェントスペースに移動し、機能 → 通信を選択し、機能プロバイダーページで登録した ServiceNow インスタンスを登録する必要があります。これで、すべてを設定する必要があり、発信者が「問題管理者」に設定されているすべてのインシデント ( AWS DevOps OAuth クライアントに付与したアクセス許可を模倣するため) は、設定された DevOps エージェントスペースでインシデント対応調査をトリガーします。これをテストするには、ServiceNow で新しいインシデントを作成し、インシデントの発信者フィールドを「問題管理者」に設定します。 ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/devopsagent/latest/userguide/images/4c7d24a85f88.png) ### ServiceNow チケットの更新 トリガーされたすべてのインシデント対応調査中、DevOps エージェントは主要な検出結果、根本原因分析、緩和計画の更新を元のチケットに提供します。エージェントの検出結果はインシデントのコメントに投稿され、現在、タイプ `finding`、、`cause``investigation_summary`、`mitigation_summary`、および調査ステータスの更新 (例: `AWS DevOps Agent started/finished its investigation`) のエージェントレコードのみを投稿します。 ## チケットルーティングとオーケストレーションの例 ### シナリオ: DevOps エージェントスペースに送信されるインシデントのフィルタリング これは簡単なシナリオですが、インシデントソースを追跡するために ServiceNow でフィールドを作成するには、ServiceNow でいくつかの設定が必要です。この例では、SNOW フォームビルダーを使用して新しいソース (u\$1source) フィールドを作成します。これにより、インシデントソースを追跡し、それを使用して特定のソースから DevOps エージェントスペースにリクエストをルーティングできます。ルーティングは、Service Now ビジネスルールを作成し、「When」トリガーと「Filter Conditions」を設定するタブで実行します。この例では、フィルター条件を次のように設定します。 ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/devopsagent/latest/userguide/images/fac7a186beee.png) ### シナリオ: 複数の DevOps エージェントスペースにインシデントをルーティングする この例では、緊急度が 、カテゴリが `1`、またはサービスが の場合に DevOps エージェントスペース B で調査をトリガーし`AWS`、サービスが `Software` `AWS`、ソースが の場合に DevOps エージェントスペース A で調査をトリガーする方法を示します`Dynatrace`。 このシナリオは 2 つの方法で実現できます。ウェブフックスクリプト自体を更新して、このビジネスロジックを含めることができます。このシナリオでは、ServiceNow ビジネスルールを使用してこれを実現する方法を示し、透明性を高め、デバッグを簡素化します。ルーティングは、2 つの Service Now ビジネスルールを作成することで実現されます。 + ServiceNow for DevOps エージェントスペース A でビジネスルールを作成し、条件ビルダーを使用して条件を作成し、指定した条件に基づいてのみイベントを送信します。 ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/devopsagent/latest/userguide/images/bca2f3928bf0.png) + 次に、ServiceNow for AgentSpace B で別のビジネスルールを作成します。このビジネスルールは、サービスが AWS でソースが Dynatrace の場合にのみトリガーされます。 ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/devopsagent/latest/userguide/images/bc29e4db1a76.png) これで、指定された条件に一致する新しいインシデントを作成すると、DevOps エージェントスペース A または DevOps エージェントスペース B の調査がトリガーされ、インシデントルーティングをきめ細かく制御できるようになります。 # Slack の接続 インシデント対応調査の主要な検出結果、根本原因分析、生成された緩和計画を使用して、選択した Slack チャネルを更新するように AWS DevOps エージェントを設定できます。 ## [開始する前に] エージェントスペースに追加する前に、Slack を DevOps エージェントに登録する必要があります。 AWS DevOps エージェントを Slack と統合するには、次の要件を満たす必要があります。 + サードパーティーアプリケーションをインストールして認可できる Slack ワークスペースにアクセスできる + AWS DevOps Agent が通知を送信する Slack チャネルを特定している ## Slack と AWS DevOps エージェントの統合を登録する ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/devopsagent/latest/userguide/images/4034f56fad96.png) 1. AWS DevOps エージェントコンソールの **Capability Providers** ページから、**「Communication**」の**「Available** providers」セクションで **Slack** を見つけ、**「Register**」をクリックします。 1. **登録**ボタンを選択します。 1. ワークスペースの AWS DevOps エージェントアプリケーションを承認するには、Slack にリダイレクトされます。 1. Slack 認可ページで、組織レベルではなくワークスペースに直接 をインストールします。 1. ドロップダウンからワークスペースを選択します。エンタープライズグリッドを選択しないでください。 1. 組織の必要に応じてワークスペースごとに をインストールします。 1. リクエストされたスコープを確認し、**統合**を許可するをクリックします。 1. 認可後、 AWS DevOps エージェントコンソールに戻ります。 ## Slack を DevOps エージェントスペースに関連付ける (複数可) DevOps エージェントスペースに Slack を登録したら、それを DevOps エージェントスペース (複数可) に関連付けることができます。 1. 設定した AgentSpace の **Capabilities** タブから、**Communications** > **Slack** に移動します。 1. **Slack の追加**を選択する 1. チャネル ID を入力する 1. **Create** を選択して Slack 設定を完了します。 **注記** ** エージェントのボットユーザーは、メッセージを投稿する前にプライベートチャネルに追加する必要があります。 **重要** ** Slack アプリをアンインストールすると、Slack アプリを再インストールできなくなる可能性があります。Slack アプリをアンインストールしないでください。 # Webhook による DevOps エージェントの呼び出し Webhook を使用すると、外部システムが AWS DevOps エージェント調査を自動的にトリガーできます。これにより、インシデントが発生したときに HTTP リクエストを送信できるチケットシステム、モニタリングツール、およびその他のプラットフォームとの統合が可能になります。 ## 前提条件 ウェブフックアクセスを設定する前に、以下があることを確認してください。 + AWS DevOps エージェントで設定されたエージェントスペース + AWS DevOps エージェントコンソールへのアクセス + ウェブフックリクエストを送信する外部システム ## ウェブフックタイプ AWS DevOps エージェントは、次のタイプのウェブフックをサポートしています。 + **統合固有のウェブフック** – Dynatrace、Splunk、Datadog、New Relic、ServiceNow、Slack などのサードパーティー統合を設定すると自動的に生成されます。これらのウェブフックは特定の統合に関連付けられ、統合タイプによって決定される認証方法を使用します。 + **汎用ウェブフック** – 特定の統合の対象ではないソースから調査をトリガーするために手動で作成できます。汎用ウェブフックは現在 **HMAC** 認証を使用しています (ベアラートークンは現在利用できません）。 + **Grafana アラートウェブフック** – Grafana は、ウェブフックのコンタクトポイントを通じてアラート通知を AWS DevOps エージェントに直接送信できます。カスタム通知テンプレートを含むセットアップ手順については、[「Grafana の接続](connecting-telemetry-sources-connecting-grafana.md)」を参照してください。 ## Webhook 認証方法 ウェブフックの認証方法は、関連付けられている統合によって異なります。 **HMAC 認証** – 以下によって使用されます。 + Dynatrace 統合ウェブフック + 一般的なウェブフック (特定のサードパーティー統合にリンクされていない) **ベアラートークン認証** – 以下によって使用されます。 + Splunk 統合ウェブフック + Datadog 統合ウェブフック + New Relic 統合ウェブフック + ServiceNow 統合ウェブフック + Slack 統合ウェブフック ## ウェブフックアクセスの設定 ### ステップ 1: ウェブフック設定に移動する 1. AWS マネジメントコンソールにサインインし、 AWS DevOps エージェントコンソールに移動します。 1. エージェントスペースを選択する 1. **機能**タブに移動する 1. **Webhook** セクションで、**Configure** をクリックします。 ### ステップ 2: ウェブフック認証情報を生成する **統合固有のウェブフックの場合:** サードパーティー統合の設定を完了すると、ウェブフックが自動的に生成されます。ウェブフックエンドポイント URL と認証情報は、統合セットアッププロセスの最後に提供されます。 **汎用ウェブフックの場合:** 1. **ウェブフックの生成** をクリックします。 1. システムは HMAC キーペアを生成します 1. 生成されたキーとシークレットを安全に保存する - 再度取得することはできません 1. 提供されたウェブフックエンドポイント URL をコピーする ### ステップ 3: 外部システムを設定する ウェブフックエンドポイント URL と認証情報を使用して、 AWS DevOps エージェントにリクエストを送信するように外部システムを設定します。特定の設定手順は、外部システムによって異なります。 ## ウェブフック認証情報の管理 **認証情報の削除** – ウェブフック認証情報を削除するには、ウェブフック設定セクションに移動し、**削除**をクリックします。認証情報を削除すると、ウェブフックエンドポイントは新しい認証情報を生成するまでリクエストを受け入れなくなります。 **認証情報の再生成** – 新しい認証情報を生成するには、まず既存の認証情報を削除してから、新しいキーペアまたはトークンを生成します。 ## ウェブフックの使用 ### Webhook リクエスト形式 調査をトリガーするには、外部システムがウェブフックエンドポイント URL に HTTP POST リクエストを送信する必要があります。 **バージョン 1 (HMAC 認証):** ヘッダー。 + `Content-Type: application/json` + `x-amzn-event-signature: ` + `x-amzn-event-timestamp: <+%Y-%m-%dT%H:%M:%S.000Z>` HMAC 署名は、SHA-256 を使用してシークレットキーでリクエスト本文に署名することで生成されます。 **バージョン 2 (ベアラートークン認証):** ヘッダー。 + `Content-Type: application/json` + `Authorization: Bearer ` **リクエスト本文:** リクエスト本文には、インシデントに関する情報を含める必要があります。 ``` json { "title": "Incident title", "severity": "high", "affectedResources": ["resource-id-1", "resource-id-2"], "timestamp": "2025-11-23T18:00:00Z", "description": "Detailed incident description", "data": { "metadata": { "region": "us-east-1", "environment": "production" } } } ``` ### コードの例 **バージョン 1 (HMAC 認証) - JavaScript:** ``` const crypto = require('crypto'); // Webhook configuration const webhookUrl = 'https://your-webhook-endpoint.amazonaws.com/invoke'; const webhookSecret = 'your-webhook-secret-key'; // Incident data const incidentData = { eventType: 'incident', incidentId: 'incident-123', action: 'created', priority: "HIGH", title: 'High CPU usage on production server', description: 'High CPU usage on production server host ABC in AWS account 1234 region us-east-1', timestamp: new Date().toISOString(), service: 'MyTestService', data: { metadata: { region: 'us-east-1', environment: 'production' } } }; // Convert data to JSON string const payload = JSON.stringify(incidentData); const timestamp = new Date().toISOString(); const hmac = crypto.createHmac("sha256", webhookSecret); hmac.update(`${timestamp}:${payload}`, "utf8"); const signature = hmac.digest("base64"); // Send the request fetch(webhookUrl, { method: 'POST', headers: { 'Content-Type': 'application/json', 'x-amzn-event-timestamp': timestamp, 'x-amzn-event-signature': signature }, body: payload }) .then(res => { console.log(`Status Code: ${res.status}`); return res.text(); }) .then(data => { console.log('Response:', data); }) .catch(error => { console.error('Error:', error); }); ``` **バージョン 1 (HMAC 認証) - cURL:** ``` #!/bin/bash # Configuration WEBHOOK_URL="https://event-ai.us-east-1.api.aws/webhook/generic/YOUR_WEBHOOK_ID" SECRET="YOUR_WEBHOOK_SECRET" # Create payload TIMESTAMP=$(date -u +%Y-%m-%dT%H:%M:%S.000Z) INCIDENT_ID="test-alert-$(date +%s)" PAYLOAD=$(cat < ### 200 を受信しない場合 200 とウェブフックが受信したメッセージは、認証に合格し、システムが確認および処理するためにメッセージがキューに入れられたことを示します。200 ではなく 4xx を取得する場合、認証またはヘッダーに問題がある可能性があります。認証のデバッグに役立つ curl オプションを使用して手動で送信してみてください。 ### 200 を受信しても調査が開始されない場合 原因として、ペイロードの変形が考えられます。 1. タイムスタンプとインシデント ID の両方が更新され、一意であることを確認します。重複するメッセージは重複排除されます。 1. メッセージが有効な JSON であることを確認します。 1. 形式が正しいことを確認する ### 200 を受け取り、調査が直ちにキャンセルされた場合 ほとんどの場合、その月の上限に達しています。必要に応じて AWS 、連絡先に連絡してレート制限の変更を依頼してください。 ## 関連トピック + [エージェントスペースの作成](getting-started-with-aws-devops-agent-creating-an-agent-space.md) + [DevOps エージェントウェブアプリとは](about-aws-devops-agent-what-is-a-devops-agent-web-app.md) + [DevOps エージェント IAM アクセス許可](aws-devops-agent-security-devops-agent-iam-permissions.md) # AWS DevOps エージェントと Amazon EventBridge の統合 調査および緩和ライフサイクル中に発生するイベントを使用して、 AWS DevOps エージェントをイベント駆動型アプリケーションと統合できます。 AWS DevOps エージェントは、調査または緩和の状態が変化したときにイベントを Amazon EventBridge に送信します。その後、これらのイベントに基づいてアクションを実行する EventBridge ルールを作成できます。 たとえば、次のアクションを実行するルールを作成できます。 + 調査が完了したら、 AWS Lambda 関数を呼び出して調査結果を処理します。 + 調査が失敗またはタイムアウトしたときに Amazon SNS 通知を送信します。 + 新しい調査の作成時にチケットシステムを更新します。 + 緩和アクションが完了したら、 AWS Step Functions ワークフローを開始します。 ## EventBridge が AWS DevOps エージェントイベントをルーティングする方法 AWS DevOps Agent は EventBridge のデフォルトイベントバスにイベントを送信します。その後、EventBridge は作成したルールに対してイベントを評価します。イベントがルールのイベントパターンと一致すると、EventBridge は指定されたターゲットにイベントを送信します。 次の図は、EventBridge が AWS DevOps エージェントイベントをルーティングする方法を示しています。 ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/devopsagent/latest/userguide/images/eventbridge-integration-how-it-works.png) 1. AWS DevOps Agent は、調査または緩和ライフサイクルの状態が変更されたときに EventBridge のデフォルトイベントバスにイベントを送信します。 1. EventBridge は、作成したルールに対してイベントを評価します。 1. イベントがルールのイベントパターンと一致する場合、EventBridge はルールで指定されたターゲットにイベントを送信します。 ## AWS DevOps エージェントイベント AWS DevOps エージェントは、以下のイベントを EventBridge に送信します。すべてのイベントはソース を使用します`aws.aidevops`。 ### サポートされている調査イベント | detail-type | 説明 | | --- | --- | | Investigation Created | エージェントスペースに調査が作成されました。 | | Investigation Priority Updated | 調査の優先度が変更されました。 | | Investigation In Progress | 調査がアクティブな分析を開始しました。 | | Investigation Completed | 調査は検出結果で正常に終了しました。 | | Investigation Failed | 調査でエラーが発生しました。完了できませんでした。 | | Investigation Timed Out | 調査が最大許容期間を超えました。 | | Investigation Cancelled | 調査は完了前にキャンセルされました。 | | Investigation Pending Triage | 調査は、アクティブな分析が開始される前にトリアージを待っています。 | | Investigation Linked | 調査が関連するインシデントまたはチケットにリンクされました。 | ### サポートされている緩和イベント | detail-type | 説明 | | --- | --- | | Mitigation In Progress | 緩和アクションが開始されました。 | | Mitigation Completed | 緩和アクションが正常に終了しました。 | | Mitigation Failed | 緩和アクションでエラーが発生しました。完了できませんでした。 | | Mitigation Timed Out | 緩和アクションが最大許容期間を超えました。 | | Mitigation Cancelled | 緩和アクションは完了前にキャンセルされました。 | 詳細なフィールドの説明とイベント例については、「」を参照してください[AWS DevOps エージェントイベントの詳細リファレンス](integrating-devops-agent-into-event-driven-applications-using-amazon-eventbridge-devops-agent-events-detail-reference.md)。 ## AWS DevOps エージェントイベントに一致するイベントパターンの作成 EventBridge ルールは、イベントパターンを使用してイベントを選択し、ターゲットにルーティングします。イベントパターンは、処理するイベントの構造と一致します。イベントパターンを作成して、イベントフィールドに基づいて AWS DevOps エージェントイベントをフィルタリングします。 次の例は、一般的なユースケースのイベントパターンを示しています。 **すべての AWS DevOps エージェントイベントを照合する** 次のイベントパターンは、 AWS DevOps エージェントからのすべてのイベントに一致します。 ``` { "source": ["aws.aidevops"] } ``` **調査イベントのみの一致** 次のイベントパターンでは、プレフィックス一致を使用して、調査ライフサイクルイベントのみを選択します。 ``` { "source": ["aws.aidevops"], "detail-type": [{"prefix": "Investigation"}] } ``` **完了イベントと失敗イベントのみを一致させる** 次のイベントパターンは、完了したまたは失敗した調査と緩和策のイベントと一致します。 ``` { "source": ["aws.aidevops"], "detail-type": [ "Investigation Completed", "Investigation Failed", "Mitigation Completed", "Mitigation Failed" ] } ``` **特定のエージェントスペースのイベントを照合する** 次のイベントパターンは、特定のエージェントスペースからのイベントに一致します。 ``` { "source": ["aws.aidevops"], "detail": { "metadata": { "agent_space_id": ["your-agent-space-id"] } } } ``` イベントパターンの詳細については、*Amazon EventBridge ユーザーガイド*の「[Amazon EventBridge イベントパターン](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html)」を参照してください。 ## Amazon EventBridge アクセス許可 AWS DevOps Agent ではEventBridge にイベントを配信するための追加のアクセス許可は必要ありません。イベントはデフォルトのイベントバスに自動的に送信されます。 EventBridge ルール用に設定したターゲットによっては、特定のアクセス許可を追加する必要がある場合があります。ターゲットに必要なアクセス許可の詳細については、[「Amazon EventBridge ユーザーガイド」の「Amazon EventBridge のリソースベースのポリシー](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html)*EventBridge*」を参照してください。 ## 追加の EventBridge リソース EventBridge の概念と設定の詳細については、*Amazon EventBridge ユーザーガイド*の以下のトピックを参照してください。 + [EventBridge イベントバス](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html) + [EventBridge イベント](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html) + [EventBridge イベントパターン](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html) + [EventBridge ルール](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html) + [EventBridge ターゲット](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html) # AWS DevOps エージェントイベントの詳細リファレンス AWS サービスからのイベントには、、`source`、、`detail-type``account`、 `region`などの一般的なメタデータフィールドがあります`time`。これらのイベントには、サービスに固有のデータを含む`detail`フィールドも含まれます。 AWS DevOps エージェントイベントの場合、 `source`は常に `aws.aidevops`であり、 は特定のイベント`detail-type`を識別します。 ## 調査イベント 次の`detail-type`値は調査イベントを識別します。 + `Investigation Created` + `Investigation Priority Updated` + `Investigation In Progress` + `Investigation Completed` + `Investigation Failed` + `Investigation Timed Out` + `Investigation Cancelled` + `Investigation Pending Triage` + `Investigation Linked` `source` および `detail-type`フィールドには、 AWS DevOps エージェントイベントの特定の値が含まれているため、以下が含まれます。すべてのイベントに含まれる他のメタデータフィールドの定義については、「*Amazon EventBridge イベントリファレンス*」の「[イベントの構造](https://docs.aws.amazon.com/eventbridge/latest/ref/overiew-event-structure.html)」を参照してください。 以下は、調査イベントの JSON 構造です。 ``` { . . ., "detail-type" : "string", "source" : "aws.aidevops", . . ., "detail" : { "version" : "string", "metadata" : { "agent_space_id" : "string", "task_id" : "string", "execution_id" : "string" }, "data" : { "task_type" : "string", "priority" : "string", "status" : "string", "created_at" : "string", "updated_at" : "string", "summary_record_id" : "string" } } } ``` **`detail-type`** イベントのタイプを識別します。調査イベントの場合、これは前述のイベント名の 1 つです。 **`source`** イベントを生成したサービスを識別します。 AWS DevOps エージェントイベントの場合、この値は です`aws.aidevops`。 **`detail`** イベント固有のデータを含む JSON オブジェクト。`detail` オブジェクトには、次のフィールドが含まれます。 + `version` (文字列) – イベント詳細のスキーマバージョン。現在 `1.0.0`。 + `metadata.agent_space_id` (文字列) – イベントが発生したエージェントスペースの一意の識別子。 + `metadata.task_id` (文字列) – タスクの一意の識別子。 + `metadata.execution_id` (文字列) – 実行実行の一意の識別子。実行が調査に割り当てられたときに表示されます。 + `data.task_type` (文字列) – タスクのタイプ。値: `INVESTIGATION`。 + `data.priority` (文字列) – 優先度。値: `CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`MINIMAL`。 + `data.status` (文字列) – 現在のステータス。値: `PENDING_START`、`IN_PROGRESS`、`COMPLETED`、、`FAILED`、`TIMED_OUT`、`CANCELLED``PENDING_TRIAGE`、。 `LINKED` + `data.created_at` (文字列) – タスクが作成されたときの ISO 8601 タイムスタンプ。 + `data.updated_at` (文字列) – タスクが最後に更新されたときの ISO 8601 タイムスタンプ。 + `data.summary_record_id` (文字列) – 調査結果を含むサマリーレコードの識別子。完了した調査の概要が生成された場合に含まれます。この識別子を使用してレコードタイプが のジャーナルレコードを検索することで、 AWS DevOps Agent API を通じて概要コンテンツを取得できます`investigation_summary_md`。 **例: 調査完了イベント** ``` { "version": "0", "id": "12345678-1234-1234-1234-123456789015", "detail-type": "Investigation Completed", "source": "aws.aidevops", "account": "123456789012", "time": "2026-03-12T18:10:00Z", "region": "us-east-1", "resources": [ "arn:aws:aidevops:us-east-1:123456789012:agentspace/8f6187a7-0388-4926-8217-3a0fe32f757c" ], "detail": { "version": "1.0.0", "metadata": { "agent_space_id": "8f6187a7-0388-4926-8217-3a0fe32f757c", "task_id": "a1b2c3d4-5678-90ab-cdef-example11111", "execution_id": "b2c3d4e5-6789-01ab-cdef-example22222" }, "data": { "task_type": "INVESTIGATION", "priority": "CRITICAL", "status": "COMPLETED", "created_at": "2026-03-12T18:00:00Z", "updated_at": "2026-03-12T18:10:00Z", "summary_record_id": "d4e5f6g7-6789-01ab-cdef-example44444" } } } ``` **例: 調査失敗イベント** ``` { "version": "0", "id": "12345678-1234-1234-1234-123456789016", "detail-type": "Investigation Failed", "source": "aws.aidevops", "account": "123456789012", "time": "2026-03-12T18:10:00Z", "region": "us-east-1", "resources": [ "arn:aws:aidevops:us-east-1:123456789012:agentspace/8f6187a7-0388-4926-8217-3a0fe32f757c" ], "detail": { "version": "1.0.0", "metadata": { "agent_space_id": "8f6187a7-0388-4926-8217-3a0fe32f757c", "task_id": "a1b2c3d4-5678-90ab-cdef-example11111", "execution_id": "b2c3d4e5-6789-01ab-cdef-example22222" }, "data": { "task_type": "INVESTIGATION", "priority": "CRITICAL", "status": "FAILED", "created_at": "2026-03-12T18:00:00Z", "updated_at": "2026-03-12T18:10:00Z" } } } ``` ## 緩和イベント 次の`detail-type`値は緩和イベントを識別します。 + `Mitigation In Progress` + `Mitigation Completed` + `Mitigation Failed` + `Mitigation Timed Out` + `Mitigation Cancelled` `source` および `detail-type`フィールドには、 AWS DevOps エージェントイベントの特定の値が含まれているため、以下が含まれます。すべてのイベントに含まれる他のメタデータフィールドの定義については、「*Amazon EventBridge イベントリファレンス*」の「[イベントの構造](https://docs.aws.amazon.com/eventbridge/latest/ref/overiew-event-structure.html)」を参照してください。 以下は、緩和イベントの JSON 構造です。 ``` { . . ., "detail-type" : "string", "source" : "aws.aidevops", . . ., "detail" : { "version" : "string", "metadata" : { "agent_space_id" : "string", "task_id" : "string", "execution_id" : "string" }, "data" : { "task_type" : "string", "priority" : "string", "status" : "string", "created_at" : "string", "updated_at" : "string", "summary_record_id" : "string" } } } ``` **`detail-type`** イベントのタイプを識別します。緩和イベントの場合、これは前述のイベント名の 1 つです。 **`source`** イベントを生成したサービスを識別します。 AWS DevOps エージェントイベントの場合、この値は です`aws.aidevops`。 **`detail`** イベント固有のデータを含む JSON オブジェクト。`detail` オブジェクトには、次のフィールドが含まれます。 + `version` (文字列) – イベント詳細のスキーマバージョン。現在 `1.0.0`。 + `metadata.agent_space_id` (文字列) – イベントが発生したエージェントスペースの一意の識別子。 + `metadata.task_id` (文字列) – タスクの一意の識別子。 + `metadata.execution_id` (文字列) – 実行実行の一意の識別子。実行が緩和に割り当てられたときに表示されます。 + `data.task_type` (文字列) – タスクのタイプ。値: `INVESTIGATION`。 + `data.priority` (文字列) – 優先度。値: `CRITICAL`、`HIGH`、`MEDIUM`、`LOW`、`MINIMAL`。 + `data.status` (文字列) – 現在のステータス。値: `IN_PROGRESS`、`COMPLETED`、`FAILED`、`TIMED_OUT`、`CANCELLED`。 + `data.created_at` (文字列) – タスクが作成されたときの ISO 8601 タイムスタンプ。 + `data.updated_at` (文字列) – タスクが最後に更新されたときの ISO 8601 タイムスタンプ。 + `data.summary_record_id` (文字列) – 緩和結果を含むサマリーレコードの識別子。完了した緩和策の概要が生成された場合に含まれます。この識別子を使用してレコードタイプが のジャーナルレコードを検索することで、 AWS DevOps Agent API を通じて概要コンテンツを取得できます`mitigation_summary_md`。 **例: 緩和完了イベント** ``` { "version": "0", "id": "12345678-1234-1234-1234-12345678901c", "detail-type": "Mitigation Completed", "source": "aws.aidevops", "account": "123456789012", "time": "2026-03-12T18:20:00Z", "region": "us-east-1", "resources": [ "arn:aws:aidevops:us-east-1:123456789012:agentspace/8f6187a7-0388-4926-8217-3a0fe32f757c" ], "detail": { "version": "1.0.0", "metadata": { "agent_space_id": "8f6187a7-0388-4926-8217-3a0fe32f757c", "task_id": "a1b2c3d4-5678-90ab-cdef-example11111", "execution_id": "c3d4e5f6-7890-12ab-cdef-example33333" }, "data": { "task_type": "INVESTIGATION", "priority": "CRITICAL", "status": "COMPLETED", "created_at": "2026-03-12T18:00:00Z", "updated_at": "2026-03-12T18:20:00Z", "summary_record_id": "e5f6g7h8-7890-12ab-cdef-example55555" } } } ``` **例: 緩和失敗イベント** ``` { "version": "0", "id": "12345678-1234-1234-1234-12345678901d", "detail-type": "Mitigation Failed", "source": "aws.aidevops", "account": "123456789012", "time": "2026-03-12T18:20:00Z", "region": "us-east-1", "resources": [ "arn:aws:aidevops:us-east-1:123456789012:agentspace/8f6187a7-0388-4926-8217-3a0fe32f757c" ], "detail": { "version": "1.0.0", "metadata": { "agent_space_id": "8f6187a7-0388-4926-8217-3a0fe32f757c", "task_id": "a1b2c3d4-5678-90ab-cdef-example11111", "execution_id": "c3d4e5f6-7890-12ab-cdef-example33333" }, "data": { "task_type": "INVESTIGATION", "priority": "CRITICAL", "status": "FAILED", "created_at": "2026-03-12T18:00:00Z", "updated_at": "2026-03-12T18:20:00Z" } } } ``` # 販売されたログとメトリクス 販売された Amazon CloudWatch メトリクスとログを使用して、エージェントスペースとサービスオペレーションをモニタリングできます。このトピックでは、 AWS DevOps Agent がアカウントに自動的に発行する CloudWatch メトリクスと、任意の送信先に配信するように設定できる販売ログについて説明します。 ## 提供された CloudWatch メトリクス AWS DevOps エージェントは、アカウントの Amazon CloudWatch にメトリクスを自動的に発行します。これらのメトリクスは、設定なしで使用できます。これらを使用して、使用状況のモニタリング、運用アクティビティの追跡、アラームの作成を行うことができます。 ### サービスにリンクされたロール このサービスのアカウントで Amazon CloudWatch メトリクスを公開するために、 AWS DevOps エージェントは[サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html) **AWSServiceRoleForAIDevOps** サービスにリンクされたロールを自動的に作成します。API を呼び出す IAM ロールに適切なアクセス許可がない場合、リソースの作成は InvalidParameterException で失敗します。 **重要** 2026 年 3 月 13 日より前に AgentSpace を作成したお客様は、**AWSServiceRoleForAIDevOps** サービスリンクロールを手動で作成して、 AWS DevOps エージェントの CloudWatch メトリクスを自分のアカウントで公開する必要があります。 ### サービスにリンクされたロールを手動で作成する (既存のお客様向け) 次のいずれかを行います。 + IAM コンソールで、DevOps エージェントサービスの下に **AWSServiceRoleForAIDevOps** ロールを作成します。 **AWS DevOps ** + AWS CLI から、次のコマンドを実行します。 ``` aws iam create-service-linked-role --aws-service-name aidevops.amazonaws.com ``` ### 名前空間 すべてのメトリクスは `AWS/AIDevOps`名前空間の下に発行されます。 ### ディメンション すべてのメトリクスには、次のディメンションが含まれます。 | ディメンション | 説明 | | --- | --- | | AgentSpaceUUID | エージェントスペースの一意の識別子。アカウント内のすべてのエージェントスペースのメトリクスを集計するには、CloudWatch の数式を使用するか、ディメンションフィルターを省略します。 | ### メトリクスのリファレンス | メトリクス名 | 説明 | Unit | 発行頻度 | 有用な統計 | | --- | --- | --- | --- | --- | | ConsumedChatRequests | エージェントスペースが消費したチャットリクエストの数。アカウントの合計数を取得するには、すべてのAgentSpaceUUIDディメンションで SUM 統計を使用します。 | カウント | 5 分ごと | 合計、平均 | | ConsumedInvestigationTime | エージェントスペースでの調査の実行にかかった時間。 | 秒 | 5 分ごと | 合計、平均、最大 | | ConsumedEvaluationTime | エージェントスペースでの評価の実行にかかった時間。 | 秒 | 5 分ごと | 合計、平均、最大 | | TopologyCompletionCount | トポロジ処理の完了数。 AWS DevOps エージェントは、オンボーディング中の最初の作成、手動更新、またはスケジュールされた毎日の更新のいずれからでも、トポロジの処理が完了すると、このメトリクスを出力します。 | カウント | イベント駆動型 (各完了時に発行) | Sum、SampleCount | ### CloudWatch コンソールでのメトリクスの表示 1. [CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch/)を開きます。 1. ナビゲーションペインで、**[Metrics]** (メトリクス)、**[All metrics]** (すべてのメトリクス) の順に選択します。 1. **AWS/AIDevOps** 名前空間を選択します。 1. エージェントスペースのメトリクスを表示するには、**AgentSpace で** を選択します。 **注記** ** これらのメトリクスに CloudWatch アラームを作成して、使用量がしきい値を超えたときに通知を受け取ることができます。たとえば、 でアラームを作成して`ConsumedChatRequests`、チャットリクエストの消費量をモニタリングします。 ## 前提条件 ログ配信を設定する前に、以下があることを確認してください。 + AWS DevOps エージェントコンソールにアクセスできるアクティブな AWS アカウント + CloudWatch Logs 配信 APIs のアクセス許可を持つ IAM プリンシパル + (オプション) Amazon S3 バケットまたは Amazon Data Firehose 配信ストリームをログ送信先として使用する予定の場合 ## 提供されるログ AWS DevOps Agent は、エージェントスペースとサービス登録が処理するイベントを可視化する販売ログをサポートします。提供されたログは、Amazon CloudWatch Logs インフラストラクチャを使用して、任意の宛先にログを配信します。 販売ログを使用するには、配信先を設定する必要があります。次の送信先がサポートされています。 + **Amazon CloudWatch Logs** – アカウントのロググループ + **Amazon S3** – アカウントの S3 バケット + **Amazon Data Firehose** – アカウントの Firehose 配信ストリーム ### サポートされているログのタイプ 1 つのログタイプがサポートされています: `APPLICATION_LOGS`。このログタイプは、サービスが発行するすべての運用イベントを対象としています。 ### ログイベントタイプ 次の表は、 AWS DevOps Agent がログに記録するイベントをまとめたものです。 | [Event] (イベント) | 説明 | ログレベル | | --- | --- | --- | | 受信したエージェントのインバウンドイベント | エージェントは統合ソースによってトリガーされ、インバウンドイベント (PagerDuty インシデントイベントなど) を受け取ります。 | 情報 | | エージェントインバウンドイベントがドロップされました | インバウンドイベントは、エージェントが処理する前にドロップされました。ログには理由 (不正な形式のデータなど) が含まれます。 | TBD | | エージェントアウトバウンド通信の失敗 | サードパーティー統合へのアウトバウンド通信に失敗しました。ログには、タスク ID と送信先識別子 (認証エラーなど) が含まれます。 | TBD | | キューに入れられたトポロジの作成 | トポロジ作成ジョブが処理のためにキューに入れられました。 | 情報 | | トポロジの作成が開始されました | トポロジ作成ジョブの処理が開始されました。 | 情報 | | トポロジの作成が完了しました | トポロジ作成ジョブの処理が完了しました。このイベントは、最初の作成、更新、および毎日の更新に適用されます。 | 情報 | | リソース検出に失敗しました | トポロジの作成中にリソース検出でエラーが発生しました。 | エラー | | サービス登録に失敗しました | サービス登録で回復不可能な障害が発生する | エラー | | Webhook の検証が失敗する | Devops エージェントによって受信されたウェブフックが予想されるスキーマと一致しない場合 | エラー | | 関連付けの検証ステータスの更新 | エージェントスペースの関連付け (通常、プライマリ/セカンダリアカウント) の場合、検証ステータスは有効から無効に変わり、その逆も同様です (たとえば、サービスでは想定できない不正な形式のロールが原因など）。 | エラー/INFO | ### アクセス許可 AWS DevOps エージェントは、[CloudWatch 販売ログ (V2 アクセス許可)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-vended-logs-permissions-V2.html) を使用してログを配信します。ログ配信を設定するには、配信を設定する IAM ロールに次のアクセス許可が必要です。 + `aidevops:AllowVendedLogDeliveryForResource` – エージェントスペースリソースのログ配信を許可するために必要です。 + CloudWatch Logs 配信 APIs のアクセス許可 (`logs:PutDeliverySource`、`logs:PutDeliveryDestination``logs:CreateDelivery`、、および関連するオペレーション）。 + 選択した配信先に固有のアクセス許可。 各送信先タイプに必要な完全な IAM ポリシーについては、*Amazon CloudWatch Logs ユーザーガイド*の以下のトピックを参照してください。 + [CloudWatch Logs に送信されたログ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-CloudWatchLogs.html) + [Amazon S3 に送信されたログ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-S3.html) + [Firehose に送信されたログ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-Firehose.html) ### ログ配信の設定 (コンソール) AWS DevOps Agent は、ログ配信を設定するために AWS マネジメントコンソールに 2 つの場所を提供します。 + **サービス登録設定ページ** – サービスレベルのイベントのログ配信を設定します。これらのログは、サービス ARN (`arn:aws:aidevops:::service/`) をリソースとして使用します。 + **エージェントスペースページ** – 個々のエージェントスペースに固有のイベントのログ配信を設定します。これらのログは、エージェントスペース ARN (`arn:aws:aidevops:::agentspace/`) をリソースとして使用します。 #### サービス登録のログ配信を設定するには 1. AWS マネジメントコンソールで AWS DevOps エージェントコンソールを開きます。 1. ナビゲーションペインで **[設定]** を選択します。 1. **Capability Providers** **>** **Logs** タブで、**Configure** を選択します。 1. **送信先タイプ**で、次のいずれかを選択します。 1. **CloudWatch Logs** – ロググループを選択または作成します。 1. **Amazon S3** – S3 バケット ARN を入力します。 1. **Amazon Data Firehose** – Firehose 配信ストリームを選択または作成します。 1. **追加設定** – *オプション*で、次のオプションを指定できます。 1. **[フィールド選択]** で、送信先に配信するログのフィールド名を選択します。[アクセスログフィールド](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logs-reference.html#BasicDistributionFileFormat)と、[リアルタイムアクセスログフィールド](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logging.html#standard-logging-real-time-log-selection)のサブセットを選択できます。 1. (Amazon S3 のみ) **[パーティショニング]** で、ログファイルデータをパーティション分割するパスを指定します。 1. (Amazon S3 のみ) **[Hive 互換ファイル形式]** でチェックボックスをオンにして、Hive 互換 S3 パスを使用できます。これにより、Hive 互換ツールへの新しいデータのロードを簡素化できます。 1. **[出力形式]** で、希望する形式を指定します。 1. **[フィールド区切り文字]** で、ログフィールドを区切る方法を指定します。 1. **[保存]** を選択します。 1. 配信ステータスが**アクティブ**になっていることを確認します。 #### エージェントスペースのログ配信を設定するには 1. AWS マネジメントコンソールで AWS DevOps エージェントコンソールを開きます。 1. 設定するエージェントスペースを選択します。 1. **設定** タブで、**設定** を選択します。 1. **[送信先タイプ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-vended-logs-permissions-V2:~:text=sts%3AAssumeRole%22%0A%20%20%20%20%7D%0A%20%20%5D%0A%7D-,Logging%20that%20requires%20additional%20permissions%20%5BV2%5D,-Some%20AWS%20services)**で、次のいずれかを選択します。 1. **CloudWatch Logs** – ロググループを選択または作成します。 1. **Amazon S3** – S3 バケット ARN を入力します。 1. **Amazon Data Firehose** – Firehose 配信ストリームを選択または作成します。 1. **追加設定 – \$1オプション** \$1 では、次のオプションを指定できます。 1. **[フィールド選択]** で、送信先に配信するログのフィールド名を選択します。[アクセスログフィールド](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logs-reference.html#BasicDistributionFileFormat)と、[リアルタイムアクセスログフィールド](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logging.html#standard-logging-real-time-log-selection)のサブセットを選択できます。 1. (Amazon S3 のみ) **[パーティショニング]** で、ログファイルデータをパーティション分割するパスを指定します。 1. (Amazon S3 のみ) **[Hive 互換ファイル形式]** でチェックボックスをオンにして、Hive 互換 S3 パスを使用できます。これにより、Hive 互換ツールへの新しいデータのロードを簡素化できます。 1. **[出力形式]** で、希望する形式を指定します。 1. **[フィールド区切り文字]** で、ログフィールドを区切る方法を指定します。 1. **[保存]** を選択します。 1. 配信ステータスが**アクティブ**になっていることを確認します。 ### ログ配信の設定 (CloudWatch API) CloudWatch Logs API を使用して、プログラムでログ配信を設定することもできます。動作しているログ配信は、次の 3 つの要素で構成されます。 + **DeliverySource** – ログを生成する AWS DevOps エージェントスペースリソースを表します。 + **DeliveryDestination** – ログが書き込まれる送信先を表します。 + **配信** – 配信ソースを配信先に接続します。 #### ステップ 1: 配信ソースを作成する [PutDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html) オペレーションを使用して配信ソースを作成します。 AWS DevOps エージェントスペースリソースの ARN を渡し、 をログタイプ`APPLICATION_LOGS`として指定します。 次の例では、エージェントスペースの配信ソースを作成します。 ``` { "name": "my-agent-space-delivery-source", "resourceArn": "arn:aws:aidevops:us-east-1:123456789012:agentspace/my-agent-space-id", "logType": "APPLICATION_LOGS" } ``` 次の例では、 サービスの配信ソースを作成します。 ``` { "name": "my-service-delivery-source", "resourceArn": "arn:aws:aidevops:us-east-1:123456789012:service", "logType": "APPLICATION_LOGS" } ``` #### ステップ 2: 配信先を作成する [PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html) オペレーションを使用して、ログの保存先を設定します。Amazon CloudWatch Logs、Amazon S3、または Amazon Data Firehose を選択できます。 次の例では、CloudWatch Logs の送信先を作成します。 ``` { "name": "my-cwl-destination", "deliveryDestinationConfiguration": { "destinationResourceArn": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/aidevops/my-agent-space" }, "outputFormat": "json" } ``` 次の例では、Amazon S3 送信先を作成します。 ``` { "name": "my-s3-destination", "deliveryDestinationConfiguration": { "destinationResourceArn": "arn:aws:s3:::my-aidevops-logs-bucket" }, "outputFormat": "json" } ``` 次の例では、Amazon Data Firehose の送信先を作成します。 ``` { "name": "my-firehose-destination", "deliveryDestinationConfiguration": { "destinationResourceArn": "arn:aws:firehose:us-east-1:123456789012:deliverystream/my-aidevops-log-stream" }, "outputFormat": "json" } ``` **注記** ** クロスアカウントでログを配信する場合は、送信先アカウントで [PutDeliveryDestinationPolicy](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestinationPolicy.html) を使用して配信を承認する必要があります。 CloudFormation を使用する場合は、以下を使用できます。 + [Delivery](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-delivery.html) + [DeliveryDestination](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverydestination.html) + [DeliverySource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverysource.html) `ResourceArn` は `AgentSpaceArn` であり、`APPLICATION_LOGS` はサポートされているログタイプとして `LogType` にする必要があります。 #### ステップ 3: 配信を作成する [CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) オペレーションを使用して、配信ソースを配信先にリンクします。 ``` { "deliverySourceName": "my-agent-space-delivery-source", "deliveryDestinationArn": "arn:aws:logs:us-east-1:123456789012:delivery-destination:my-cwl-destination" } ``` #### AWS CloudFormation 次のリソースで AWS CloudFormation を使用してログ配信を設定することもできます。 + [AWS::Logs::DeliverySource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverysource.html) + [AWS::Logs::DeliveryDestination](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverydestination.html) + [AWS::Logs::Delivery](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-delivery.html) `ResourceArn` を AWS DevOps エージェントスペースまたはサービス ARN に設定し、 `LogType` を に設定します`APPLICATION_LOGS`。 ### ログスキーマのリファレンス AWS DevOps エージェントは、すべてのイベントタイプで共有ログスキーマを使用します。すべてのログイベントがすべてのフィールドを使用するわけではありません。 次の表に、ログスキーマのフィールドを示します。 | フィールド | タイプ | 説明 | | --- | --- | --- | | event\$1timestamp | Long | イベントが発生した時刻の Unix タイムスタンプ | | resource\$1arn | String | イベントを生成したリソースの ARN | | optional\$1account\$1id | String | AWS ログに関連付けられた アカウント ID。 | | optional\$1level | String | ログレベル: INFO、WARN、 ERROR | | optional\$1agent\$1space\$1id | String | エージェントスペースの識別子。 | | optional\$1association\$1id | String | ログの関連付け識別子。 | | optional\$1status | String | トポロジオペレーションのステータス。 | | optional\$1webhook\$1id | String | Webhook 識別子。 | | optional\$1mcp\$1endpoint\$1url | String | MCP サーバーエンドポイント URL | | optional\$1service\$1type | String | サービスのタイプ: DYNATRACE、DATADOG、、GITHUBSLACK、SERVICENOW。 | | optional\$1service\$1endpoint\$1url | String | サードパーティー統合のエンドポイント URL。 | | optional\$1service\$1id | String | ソースの識別子。 | | request\$1id | String | AWS CloudTrail またはサポートチケットと関連付けるためのリクエスト識別子。 | | optional\$1operation | String | 実行されたオペレーションの名前。 | | optional\$1task\$1type | String | エージェントバックログタスクタイプ: INVESTIGATIONまたは EVALUATION | | optional\$1task\$1id | String | エージェントバックログタスク IDAgentバックログタスク識別子。 | | optional\$1reference | String | エージェントタスクからのリファレンス (Jira チケットなど）。 | | optional\$1error\$1type | String | エラータイプ | | optional\$1error\$1message | String | オペレーションが失敗した場合のエラーの説明。 | | optional\$1details | 文字列 (JSON) | オペレーションパラメータと結果を含むサービス固有のイベントペイロード。 | ### ログ配信の管理と無効化 ログ配信は、 AWS マネジメントコンソールの AWS DevOps エージェントコンソールから、または CloudWatch Logs API を使用して、いつでも変更または削除できます。 #### ログ配信の管理 (コンソール) 1. AWS マネジメントコンソールで AWS DevOps エージェントコンソールを開きます。 1. **設定**ページ (サービスレベルのログの場合) または特定の**エージェントスペース**ページ (エージェントスペースレベルのログの場合) に移動します。 1. **設定**タブ (エージェントスペースレベルのログの場合) または**機能プロバイダー** **>** ****ログタブ (サービスレベルのログの場合) で、変更する配信を選択します。 1. 必要に応じて設定を更新し、**保存**を選択します。 **注:** 既存の配信の送信先タイプを変更することはできません。送信先タイプを変更するには、現在の配信を削除し、新しい配信を作成します。 #### ログ配信を無効にする (コンソール) 1. AWS マネジメントコンソールで AWS DevOps エージェントコンソールを開きます。 1. **設定**ページ (サービスレベルのログの場合) または特定の**エージェントスペース**ページ (エージェントスペースレベルのログの場合) に移動します。 1. **設定**タブ (エージェントスペースレベルのログの場合) または**機能プロバイダー** **>** ****ログタブ (サービスレベルのログの場合) で、削除する配信を選択します。 1. **削除**を選択して確認します。 #### ログ配信を無効にする (API) API を使用してログ配信を削除するには、次の順序でリソースを削除します。 1. [DeleteDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDelivery.html) を使用して配信を削除します。 1. [DeleteDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDeliverySource.html) を使用して配信ソースを削除します。 1. (オプション) 配信先が不要になった場合は、[DeleteDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDeliveryDestination.html) を使用して配信先を削除します。 **重要** ** ログを生成するエージェントスペースリソースを削除した後 (エージェントスペースを削除した後など）、ログ配信リソースを削除する必要があります。これらのリソースを削除しない場合、孤立した配信設定が残る可能性があります。 ## 料金 AWS DevOps エージェントは、提供されたログの有効化には課金しません。ただし、選択したログ配信先によっては、配信、取り込み、ストレージ、またはアクセスに対して料金が発生する場合があります。料金の詳細については、**「Amazon CloudWatch 料金表」の「ログ」タブの「Vended** **Logs**」を参照してください。 [Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/pricing/) 送信先固有の料金については、以下を参照してください。 + [Amazon CloudWatch Logs 料金](https://aws.amazon.com/cloudwatch/pricing/) + [Amazon S3 料金](https://aws.amazon.com/s3/pricing/) + [Amazon Data Firehose 料金](https://aws.amazon.com/kinesis/data-firehose/pricing/) # プライベートにホストされたツールへの接続 ## プライベート接続の概要 AWS DevOps エージェントは、カスタムモデルコンテキストプロトコル (MCP) ツールやその他の統合を使用して拡張できます。これにより、エージェントはプライベートパッケージレジストリ、セルフホスト型オブザーバビリティプラットフォーム、内部ドキュメント APIs「」を参照[AWS DevOps Agent の機能の設定](configuring-capabilities-for-aws-devops-agent.md))。これらのサービスは、多くの場合、パブリックインターネットアクセスが制限されているか、パブリックインターネットアクセスがない [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide) 内で実行されます。つまり、 AWS DevOps Agent はデフォルトでそれらにアクセスできません。 AWS DevOps Agent のプライベート接続を使用すると、パブリックインターネットに公開することなく、VPC で実行されているサービスにエージェントスペースを安全に接続できます。プライベート接続は、MCP サーバー、セルフホスト型の Grafana または Splunk インスタンス、GitHub Enterprise Server や GitLab Self-Managed などのソース管理システムなど、プライベートエンドポイントに到達する必要がある統合と連携します。 **注記** ** プライベートにホストされたツールが VPC 内から AWS DevOps エージェントにアウトバウンドリクエストを行う場合、このトラフィックは VPC エンドポイントを使用して保護し、 AWS ネットワーク内に留まることもできます。たとえば、これはウェブフックイベントを介して DevOps エージェントをトリガーするツールで使用できます (「」を参照[Webhook による DevOps エージェントの呼び出し](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md))。詳細については、「[VPC エンドポイント (AWS PrivateLink)](aws-devops-agent-security-vpc-endpoints-aws-privatelink.md)」を参照してください。 ### プライベート接続の仕組み プライベート接続は、 AWS DevOps Agent と VPC 内のターゲットリソースとの間に安全なネットワークパスを作成します。 AWS DevOps Agent は、Amazon [VPC Lattice ](https://docs.aws.amazon.com/vpc-lattice/latest/ug/)を使用して、この安全なプライベート接続パスを確立します。VPC Lattice は、基盤となるネットワークインフラストラクチャを管理することなく、VPCs、アカウント、コンピューティングタイプ間のアプリケーション間の通信を接続、保護、モニタリングできるアプリケーションネットワークサービスです。 プライベート接続を作成すると、以下が発生します。 + ターゲットサービスへのネットワーク接続を持つ VPC、サブネット、および (オプションで) セキュリティグループを指定します。 + AWS DevOps Agent は、サービスマネージド[リソースゲートウェイ](https://docs.aws.amazon.com/vpc/latest/privatelink/resource-gateway.html)を作成し、指定したサブネットに Elastic Network Interface (ENIs) をプロビジョニングします。 + エージェントはリソースゲートウェイを使用して、プライベートネットワークパス経由でターゲットサービスの IP アドレスまたは DNS 名にトラフィックをルーティングします。 リソースゲートウェイは AWS DevOps エージェントによって完全に管理され、 アカウント ( という名前) の読み取り専用リソースとして表示されます`aidevops-{your-private-connection-name}`。設定または保守する必要はありません。VPC で作成されるリソースはENIs のみです。これらの ENIs はプライベートトラフィックのエントリポイントとして機能し、 サービスによって完全に管理されます。インターネットからのインバウンド接続は受け付けず、独自のセキュリティグループを介してトラフィックを完全に制御できます。 ### セキュリティ プライベート接続は、複数のセキュリティレイヤーで設計されています。 + **パブリックインターネットへの露出なし** — AWS DevOps Agent とターゲットサービス間のすべてのトラフィックは AWS ネットワーク上にとどまります。サービスにパブリック IP アドレスやインターネットゲートウェイは必要ありません。 + **サービスマネージドリソースゲートウェイ** – サービスマネージドリソースゲートウェイは、アカウント内で読み取り専用です。 AWS DevOps エージェントのみが使用でき、他のサービスやプリンシパルがそのエージェントを介してトラフィックをルーティングすることはできません。これは、すべての VPC Lattice API コールを記録する [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/) ログで確認できます。 + **セキュリティグループ、ルール** – 所有および管理しているセキュリティグループを通じてENIs へのインバウンドトラフィックとアウトバウンドトラフィックを制御します。セキュリティグループを指定しない場合、 AWS DevOps Agent は定義したポートを対象とするデフォルトのセキュリティグループを作成します。 + **最小特権のサービスにリンクされたロール** – AWS DevOps エージェントは、[サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html)を使用して、必要な VPC Lattice と Amazon EC2 リソースのみを作成します。このロールは、 でタグ付けされたリソースに限定`AWSAIDevOpsManaged`されており、アカウントの他のリソースにアクセスすることはできません。 **注記** ** 組織に VPC Lattice API アクションを制限する[サービスコントロールポリシー (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) がある場合、サービスマネージドリソースゲートウェイはサービスにリンクされたロールを介して作成されます。SCPsサービスにリンクされたロールに必要なアクションを許可していることを確認します。 ### アーキテクチャ 次の図は、プライベート接続のネットワークパスを示しています。 ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/devopsagent/latest/userguide/images/7cd6182e6b8d.png) このアーキテクチャの詳細は以下のとおりです。 + AWS DevOps エージェントは、ターゲットサービスへのリクエストを開始します。 + Amazon VPC Lattice は、VPC のサービスマネージドリソースゲートウェイを介してリクエストをルーティングします。独自の VPC Lattice リソースを使用した高度なセットアップについては、[「既存の VPC Lattice リソースを使用した高度なセットアップ](#advanced-setup-using-existing-vpc-lattice-resources)」を参照してください。 + VPC の ENI はトラフィックを受信し、ターゲットサービスの IP アドレスまたは DNS 名に転送します。 + セキュリティグループは、ENIsを介して許可されるトラフィックを管理します。 + ターゲットサービスの観点から、リクエストは VPC 内の ENIs のプライベート IP アドレスから送信されます。 ## プライベート接続を作成する プライベート接続は、 AWS マネジメントコンソールまたは CLI AWS を使用して作成できます。 **注記** ** VPC Lattice では、次のアベイラビリティーゾーンはサポートされていません: `use1-az3`、`usw1-az2`、`apne1-az3`、、`apne2-az2`、`euc1-az2``euw1-az4``cac1-az3`、、`ilc1-az2`。 ### 前提条件 プライベート接続を作成する前に、以下があることを確認します。 + **アクティブなエージェントスペース** – アカウント内に既存のエージェントスペースが必要です。アカウントをお持ちでない場合は、「[AWS DevOps エージェントの開始方法](getting-started-with-aws-devops-agent.md)」を参照してください。 + **プライベートにアクセス可能なターゲットサービス** – MCP サーバー、オブザーバビリティプラットフォーム、またはその他のサービスは、リソースゲートウェイがデプロイされている VPC の既知のプライベート IP アドレスまたは DNS 名で到達可能である必要があります。サービスは、リソースゲートウェイサブネットからルーティング可能である限り、同じ VPC、ピア接続された VPC、またはオンプレミスで実行できます。サービスは、接続の作成時に指定したポートで、最小 TLS バージョン 1.2 の HTTPS トラフィックを提供する必要があります。 + **VPC 内のサブネット** – ENIs が作成されるサブネットを 1～20 個特定します。高可用性を実現するには、複数のアベイラビリティーゾーンのサブネットを選択することをお勧めします。これらのサブネットには、ターゲットサービスへのネットワーク接続が必要です。VPC Lattice では、アベイラビリティーゾーンごとに 1 つのサブネットを使用できます。 + **(オプション) セキュリティグループ** – 特定のルールでトラフィックを制御する場合は、ENI にアタッチするセキュリティグループ IDs を最大 5 つまで準備します。 ENIs セキュリティグループを省略すると、 AWS DevOps Agent はデフォルトのセキュリティグループを作成します。 プライベート接続はアカウントレベルのリソースです。プライベート接続を作成したら、同じホストに到達する必要がある複数の統合とエージェントスペースで再利用できます。 ### コンソールを使用してプライベート接続を作成する 1. AWS DevOps エージェントコンソールを開きます。 1. ナビゲーションペインで、**機能プロバイダー**を選択し、**プライベート接続**を選択します。 1. **[新しい接続を作成する]** を選択します。 1. Name には****、 など、接続のわかりやすい名前を入力します`my-mcp-tool-connection`。 1. **VPC** の場合は、リソースゲートウェイ ENIs がデプロイされる VPC を選択します。 1. **サブネット**の場合は、1 つ以上のサブネット (最大 20) を選択します。少なくとも 2 つのアベイラビリティーゾーンでサブネットを選択することをお勧めします。 1. **IP アドレスタイプ**で、ターゲットサービスの IP アドレスのタイプ (`IPv4`、`IPv6`、または ) を選択します`DualStack`。 1. (オプション) ** IPv4 アドレスの数**で、IP アドレスタイプに IPv4 またはデュアルスタックを選択した場合は、リソースゲートウェイの ENI ごとに IPv4 アドレスの数を入力できます。デフォルトは、ENI あたり 16 個の IPv4 アドレスです。 1. (オプション) **セキュリティグループ**で、既存のセキュリティグループ (最大 5) を選択して、ターゲットサービスに到達できるトラフィックを制限します。選択しない場合、デフォルトのセキュリティグループが作成されます。 1. (オプション) **ポート範囲**には、ターゲットアプリケーションがリッスンする TCP ポートを指定します (例: `443`または `8080-8090`)。最大 11 個のポート範囲を指定できます。 1. **ホストアドレス**には、ターゲットサービスの IP アドレスまたは DNS 名 (例: `mcp.internal.example.com`または ) を入力します`10.0.1.50`。サービスは、選択した VPC から到達可能である必要があります。DNS 名を選択する場合は、選択した VPC から解決可能である必要があります。 1. (オプション) **証明書パブリックキー**で、指定したホストアドレスがプライベート認証機関によって発行された TLS 証明書を使用している場合は、証明書の PEM エンコードされたパブリックキーを入力します。これにより、 AWS DevOps Agent はターゲットサービスへの TLS 接続を信頼できます。 1. **[接続を作成]** を選択します。 接続ステータスが**進行中の作成**に変わります。このプロセスには最大 10 分かかる場合があります。ステータスが**アクティブ**に変わると、ネットワークパスの準備が整います。 ステータスが**「作成**」に変わった場合は、以下を確認します。 + 指定したサブネットには使用可能な IP アドレスがあります。 + アカウントが VPC Lattice サービスクォータに達していません。 + 制限付きの IAM ポリシーは、サービスにリンクされたロールによるリソースの作成を妨げません。 **注記** ** これらのステップは、機能プロバイダーの登録`Create a new private connection`時に を選択して実行することもできます。詳細については、[「機能プロバイダーとのプライベート接続を使用する](#use-a-private-connection-with-a-capability-provider)」を参照してください。 ### CLI AWS を使用してプライベート接続を作成する 次のコマンドを実行して、プライベート接続を作成します。プレースホルダーの値を独自の値に置き換えます。 ``` aws devops-agent create-private-connection \ --name my-mcp-tool-connection \ --mode '{ "serviceManaged": { "hostAddress": "mcp.internal.example.com", "vpcId": "vpc-0123456789abcdef0", "subnetIds": [ "subnet-0123456789abcdef0", "subnet-0123456789abcdef1" ], "securityGroupIds": [ "sg-0123456789abcdef0" ], "portRanges": ["443"] } }' ``` レスポンスには、接続名と のステータスが含まれます`CREATE_IN_PROGRESS`。 ``` { "name": "my-mcp-tool-connection", "status": "CREATE_IN_PROGRESS", "resourceGatewayId": "rgw-0123456789abcdef0", "hostAddress": "mcp.internal.example.com", "vpcId": "vpc-0123456789abcdef0" } ``` 接続ステータスを確認するには、 `describe-private-connection` コマンドを使用します。 ``` aws devops-agent describe-private-connection \ --name my-mcp-tool-connection ``` ステータスが になると`ACTIVE`、プライベート接続を使用する準備が整います。 ## 機能プロバイダーとのプライベート接続を使用する プライベート接続を使用するには、機能プロバイダーの登録中にプライベート接続にリンクできます。プライベート接続で使用できるサポート対象の機能には、`GitHub`、、`GitLab``MCP Server`、 などがあります`Grafana`。このステップは、 AWS マネジメントコンソールまたは CLI AWS を使用して実行できます。 **注記** ** 機能プロバイダーを登録すると、 AWS DevOps Agent はエンドポイントに到達可能で応答していることを検証します。登録を完了する前に、ターゲットサービスが実行されていて、接続を受け入れていることを確認します。 ### コンソールを使用して機能プロバイダーとのプライベート接続を使用する AWS DevOps エージェントコンソールでは、「プライベート接続を使用してエンドポイントに接続する」オプションを選択して、登録中にプライベート接続を機能にリンクできます。 ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/devopsagent/latest/userguide/images/a2a7ffb70ffe.png) 1. AWS DevOps エージェントコンソールを開き、エージェントスペースに移動します。 1. **「機能プロバイダー**」セクションで、**「登録**」を選択します。 1. プライベート接続で使用する機能タイプの**登録**を選択します。 1. 登録の詳細ビューで、プライベート接続を使用して接続するエンドポイント URL を入力します (例: `https://mcp.internal.example.com`)。 1. **プライベート接続を使用してエンドポイントに接続する**を選択します。 1. 接続するエンドポイント URL に対応する既存のプライベート接続を選択するか、**新しいプライベート接続を作成する**を選択します。 1. 機能プロバイダーの登録プロセスを完了します。 ### AWS CLI を使用して機能プロバイダーとのプライベート接続を使用する 引`private-connection-name`数を含めることで、プライベート接続に機能を登録できます。以下は、`my-mcp-tool-connection`プライベート接続を使用して API キー認可で MCP サーバーを登録する例です。プレースホルダーの値を独自の値に置き換えます。 ``` aws devops-agent register-service \ --service mcpserver \ --private-connection-name my-mcp-tool-connection \ --service-details '{ "mcpserver": { "name": "my-mcp-tool", "endpoint": "https://mcp.internal.example.com", "authorizationConfig": { "apiKey": { "apiKeyName": "api-key", "apiKeyValue": "secret-value", "apiKeyHeader": "x-api-key" } } } }' \ --region us-east-1 ``` ## プライベート接続を検証する プライベート接続が**アクティブ**状態になり、機能プロバイダーによって利用されたら、 AWS DevOps Agent がターゲットサービスに到達できることを確認します。 1. AWS DevOps エージェントコンソールを開き、エージェントスペースに移動します。 1. 新しいチャットセッションを開始します。 1. プライベート接続でバックアップされた統合を使用するコマンドを呼び出します。たとえば、MCP ツールが内部ナレッジベースへのアクセスを提供する場合は、そのナレッジベースを必要とする質問をエージェントに依頼します。 1. エージェントがプライベートサービスから結果を返すことを確認します。 接続が失敗した場合は、以下を確認してください。 + **VPC Lattice 制限** - リソースゲートウェイやその他の [VPC Lattice クォータ](https://docs.aws.amazon.com/vpc-lattice/latest/ug/quotas.html)制限に達していないことを確認します。 + **セキュリティグループルール** – ENIs にアタッチされたセキュリティグループが、サービスがリッスンするポートでアウトバウンドトラフィックを許可していることを確認します。また、サービスのセキュリティグループがターゲットポートでインバウンドトラフィックを許可していることを確認します。VPC CIDR 範囲内の VPC Lattice データプレーン IPs からトラフィックが到着します。セキュリティグループ参照 (ENI セキュリティグループをソースとして許可) を使用するか、VPC CIDR からのインバウンドを許可できます。 + **サブネット接続** — 選択したサブネットがサービスにトラフィックをルーティングできることを確認します。サービスが別のサブネットで実行されている場合は、ルートテーブルがそれらの間のトラフィックを許可していることを確認します。 + **サービスの可用性** – サービスが実行されており、予想されるポートで接続を受け入れていることを確認します。 + **サポートされていないアベイラビリティーゾーン** - サブネットがサポートされているアベイラビリティーゾーンにあることを確認します。を実行して`aws ec2 describe-subnets --subnet-ids --query 'Subnets[*].[SubnetId,AvailabilityZoneId]'`、上記のサポートされていないアベイラビリティーゾーンと照合します。 ## プライベート接続を削除する 未使用のプライベート接続は、 AWS マネジメントコンソールまたは CLI AWS を使用して削除できます。 ### コンソールを使用してプライベート接続を削除する 1. AWS DevOps エージェントコンソールを開きます。 1. ナビゲーションペインで、**機能プロバイダー**を選択し、**プライベート接続**を選択します。 1. 削除するプライベート接続の**アクション**メニューを選択し、**削除**を選択します。 プライベート接続のステータスは「接続の削除」と表示され、 AWS DevOps Agent は VPC からマネージドリソースゲートウェイと ENI を削除します。 ENIs 削除が完了すると、接続はプライベート接続のリストに表示されなくなります。 ### CLI AWS を使用してプライベート接続を削除する ``` aws devops-agent delete-private-connection \ --name my-mcp-tool-connection ``` レスポンスは ステータスを返します`DELETE_IN_PROGRESS`。 AWS DevOps Agent は VPC からマネージドリソースゲートウェイと ENIs を削除します。削除が完了すると、接続はプライベート接続のリストに表示されなくなります。 ## 既存の VPC Lattice リソースを使用した高度なセットアップ 組織がすでに Amazon VPC Lattice を使用していて、独自のリソース設定を管理している場合は、セルフマネージドモードでプライベート接続を作成できます。 AWS DevOps エージェントがリソースゲートウェイを作成する代わりに、ターゲットサービスを指す既存のリソース設定の Amazon リソースネーム (ARN) を指定します。 このアプローチは、次の場合に便利です。 + リソースゲートウェイとリソース設定ライフサイクルを完全に制御したい。 + 複数の AWS アカウントまたはサービス間でリソース設定を共有する必要があります。 + 詳細なトラフィックモニタリングには、VPC Lattice アクセスログが必要です。 + hub-and-spokeのネットワークアーキテクチャを実行します。 AWS CLI を使用してセルフマネージドプライベート接続を作成するには: ``` aws devops-agent create-private-connection \ --name my-advanced-connection \ --mode '{ "selfManaged": { "resourceConfigurationId": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-0123456789abcdef0" } }' ``` VPC Lattice リソースゲートウェイとリソース設定の設定の詳細については、[「Amazon VPC Lattice ユーザーガイド](https://docs.aws.amazon.com/vpc-lattice/latest/ug/)」を参照してください。 ## 関連トピック + [VPC エンドポイント (AWS PrivateLink)](aws-devops-agent-security-vpc-endpoints-aws-privatelink.md) + [MCP サーバーの接続](configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers.md) + [AWS DevOps Agent の機能の設定](configuring-capabilities-for-aws-devops-agent.md) + [AWS DevOps エージェントセキュリティ](aws-devops-agent-security.md) + [DevOps エージェント IAM アクセス許可](aws-devops-agent-security-devops-agent-iam-permissions.md)