翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # 自動ワークフローを使用して Amazon Lex ボットの開発とデプロイを合理化する *Balaji Panneerselvam、Attila Dancso、Pavan Dusanapudi、Anand Jumnani、James O'Hara (Amazon Web Services)* ## 概要 Amazon Lex 会話ボットの開発とデプロイは、複数の機能、開発者、および環境を管理しようとする場合には困難になることがあります。Infrastructure as Code (IaC) 原則を使用する自動ワークフローは、このプロセスを合理化するのに役立ちます。このパターンは、以下のようにして Amazon Lex 開発者の生産性の向上と、効率的なボットライフサイクル管理の実現に寄与します。 + **複数の機能の同時開発を可能にする** - 自動ワークフローを使用すると、開発者はさまざまな機能を別々のブランチで並行して開発できます。その後、他の作業をブロックすることなく、変更をマージしてデプロイできます。 + **Amazon Lex コンソール UI を使用する** - 開発者は、使いやすい Amazon Lex コンソールを使用してボットをビルドおよびテストできます。その後、ボットはインフラストラクチャコードで記述され、デプロイされます。 + **複数の環境にまたがってボットを昇格させる** - ワークフローは、ボットバージョンの下位環境 (開発やテストなど) から本番環境までの昇格を自動化します。このアプローチにより、手動昇格のリスクとオーバーヘッドが軽減されます。 + **バージョン管理を維持する** - ボット定義は、Amazon Lex サービスだけでなく Git でも管理されます。これにより、バージョン管理と監査証跡が提供されます。または AWS マネジメントコンソール APIs のみを使用して保存されているボットを変更する場合とは異なり、変更は個々の開発者に追跡されます AWS。 チームは、Amazon Lex ボットのリリースプロセスを自動化することで、リスクと労力を軽減し、機能をより迅速に提供できます。ボットは、Amazon Lex コンソールで分離されるのではなく、バージョン管理下にとどまります。 ## 前提条件と制限事項 **前提条件** + ワークフローには、異なる環境 (開発、本番稼働、DevOps) AWS アカウント に対して複数の が含まれます。そのためには、アカウント管理とクロスアカウントアクセス設定が必要です。 + デプロイ環境またはパイプラインで利用可能な Python 3.9。 + ソース管理のためにローカルワークステーションに[インストール](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)および設定されている Git。 + AWS Command Line Interface (AWS CLI) コマンドラインまたは Python を使用して認証するように[インストール](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)および設定されています。 **制限事項** + **リポジトリアクセス** – ワークフローでは、継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインに、ソースコードリポジトリに変更をコミットするために必要なアクセス許可があることを前提としています。 + **初期ボットバージョン** – ツールでは、 AWS CloudFormation テンプレートを使用してボットの初期バージョンをデプロイする必要があります。ボットを自動ワークフローに引き継がせる前に、ボットの最初のイテレーションを作成し、リポジトリにコミットする必要があります。 + **マージの競合** – ワークフローの目的は同時開発を可能にすることですが、さまざまなブランチからの変更を統合するときにマージの競合が発生する可能性がまだあります。ボット設定の競合を解決するには、手動介入が必要になる場合があります。 **製品バージョン** + [Python 3.9](https://www.python.org/downloads/) 以降 + [AWS CDK v2 2.124.0](https://docs.aws.amazon.com/cdk/api/versions.html) 以降 + [AWS SDK for Python (Boto3)](https://docs.aws.amazon.com/pythonsdk/) 1.28 以降 ## アーキテクチャ 次の図は、ソリューションの高レベルアーキテクチャと主要コンポーネントを示しています。 ![\[Amazon Lex ボットの開発とデプロイを自動化するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/3c7f9d16-9708-43c4-afa6-9d804d6b9dad/images/cdc73e82-a777-4e88-8bf8-a73c9bacb47f.png) 主なコンポーネントは以下のとおりです。 + **Lex ボットリポジトリ** – Amazon Lex ボットの IaC 定義を保存する Git リポジトリ。 + **DevOps** – 開発およびデプロイプロセス用の CI/CD パイプラインおよび関連リソースを格納する AWS アカウント 専用の です。 + **パイプライン** – 新しいボットの作成、ボットの定義のエクスポート、ボット定義のインポート、ボットの削除など、ボットの開発とデプロイのライフサイクルのさまざまな段階を自動化する AWS CodePipeline インスタンス。 + **チケットボットとメインボット** – Amazon Lex ボットリソース。ここで、チケットボットは個々のチームまたは開発者によって開発される機能固有のボットで、メインボットはすべての機能を統合するベースラインボットです。 このアーキテクチャ図は、次のワークフローを示しています。 1. **メインボットをベースラインに設定する** – ワークフローの出発点は、開発 (Dev) 環境でメインボットをベースラインに設定することです。メインボットは、将来の開発と機能追加の基盤として機能します。 1. **チケットボットを作成する** – 新機能または変更が必要な場合、チケットボットが作成されます。チケットボットは基本的に、開発者がメインバージョンに影響を与えることなく操作できるメインボットのコピーまたはブランチです。 1. **チケットボットをエクスポートする** - チケットボットに対する作業が完了したら、Amazon Lex サービスからチケットボットがエクスポートされます。その後、チケットボットを含むブランチがメインブランチからリベースされます。このステップにより、チケットボットの開発中にメインボットに加えられた変更が確実に組み込まれ、潜在的な競合が軽減されます。 1. **リベースされたチケットボットをインポートして検証する** – リベースされたチケットボットは開発環境にインポートされ、メインブランチからの最新の変更で正しく機能することが検証されます。検証が成功すると、チケットボットの変更をメインブランチにマージするためのプルリクエスト (PR) が作成されます。 1. **チケットボットを削除する** – 変更がメインブランチに正常にマージされると、チケットボットは不要になります。チケットボットを削除して、環境をクリーンで管理しやすい状態に保つことができます。 1. **メインボットを開発環境にデプロイしてテストする** – 新機能や変更を含む最新のメインボットが開発環境にデプロイされます。ここでは、徹底的なテストを実施して、すべての機能が予期したとおりに動作することを確認します。 1. **メインボットを本番環境にデプロイする** – 開発環境でのテストが正常に完了すると、メインボットが本番環境にデプロイされます。このステップはワークフローの最終段階で、ここでエンドユーザーが新機能を利用できるようになります。 **自動化とスケール** 自動ワークフローにより、開発者はさまざまな機能を別々のブランチで並行して開発できます。これにより、同時開発が容易になり、チームが効果的にコラボレーションして、機能をより迅速に提供することが可能になります。相互に分離されたブランチにより、他の進行中の作業をブロックまたは妨害することなく、変更をマージしてデプロイできます。 ワークフローは、開発、テスト、本番などのさまざまな環境にまたがるボットバージョンのデプロイと昇格を自動化します。 Git などのバージョン管理システムにボット定義を保存することで、包括的な監査証跡が提供され、効率的なコラボレーションが可能になります。変更は個々の開発者まで追跡されます。これにより、開発ライフサイクル全体を通じて透明性と説明責任が確保されます。このアプローチでは、コードレビューも容易になるため、チームは本番環境にデプロイする前に問題を特定して対処できます。 AWS CodePipeline およびその他の を使用することで AWS のサービス、自動化ワークフローは増加するワークロードとチームサイズに合わせてスケーリングできます。 ## ツール **AWS のサービス** + [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、使い慣れたプログラミング言語を使用してコード内の AWS クラウド インフラストラクチャを定義し、それをプロビジョニングするためのオープンソースのソフトウェア開発フレームワークです CloudFormation。このパターンのサンプル実装では Python を使用します。 + [AWS CDK コマンドラインインターフェイス (AWS CDK CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) - Toolkit AWS CDK は、 AWS CDK アプリを操作するための主要なツールです。アプリケーションを実行し、定義したアプリケーションモデルを調査し、CDK によって生成された CloudFormation テンプレートを生成してデプロイします。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。このパターンでは、CloudFormation を使用し、Infrastructure as Code によって Amazon Lex ボット設定と関連リソースをデプロイします。 + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。このパターンでは、CodeBuild を使用してデプロイアーティファクトをビルドおよびパッケージ化します。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。このパターンでは、CodePipeline を使用して継続的デリバリーパイプラインをオーケストレーションします。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンドAWS のサービス を使用して を操作するのに役立つオープンソースツールです。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [Amazon Lex V2](https://docs.aws.amazon.com/lexv2/latest/dg/what-is.html) は、音声とテキストを使用してアプリケーションの会話インターフェイス (ボット) を構築 AWS のサービス するための です。 + [AWS SDK for Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html) は、Python アプリケーション、ライブラリ、またはスクリプトを と統合するのに役立つソフトウェア開発キットです AWS のサービス。 **その他のツール** + [Git](https://git-scm.com/docs) はオープンソースの分散型バージョン管理システムです。 **コードリポジトリ** このパターンのコードは、GitHub [management-framework-sample-for-amazon-lex](https://github.com/aws-samples/management-framework-sample-for-amazon-lex) リポジトリで入手できます。コードリポジトリには、以下のフォルダとファイルが含まれています。 + `prerequisite` フォルダ – 必要なリソースと環境を設定するための CloudFormation スタック定義 ( を使用 AWS CDK) が含まれています。 + `prerequisite/lexmgmtworkflow` フォルダ – スタック定義や Python コードを含む、Lex Management Workflow プロジェクトのメインディレクトリ。 + `prerequisite/tests` – ユニットテストが含まれています。 + `src` フォルダ – Amazon Lex ボット管理ラッパーとユーティリティを含むソースコードディレクトリ。 + `src/dialogue_lambda` – Amazon Lex ボットとの会話中にユーザー入力を傍受して処理するダイアログフック Lambda 関数のソースコードディレクトリ。 ## ベストプラクティス + **懸念事項の分離** + DevOps、開発、および本番環境間の責任の明確な分離を維持します。 + 環境 AWS アカウント ごとに個別の を使用して、適切な分離とセキュリティの境界を適用します。 + クロスアカウントロールと最小特権アクセス原則を使用して、環境間の制御されたアクセスを確保します。 + **コードとしてのインフラストラクチャ** + インフラストラクチャコードを定期的に見直し、ベストプラクティスと要件の変化に合わせて更新します。 + ソースコードリポジトリに対する明確なブランチおよびマージ戦略を確立する + **テストと検証** + パイプラインのさまざまな段階で自動テストを実装して、開発サイクルの早い段階で問題を特定します。 + Amazon Lex コンソールまたは自動テストフレームワークを使用し、ボットを上位環境に昇格させる前にボットの設定と機能を検証します。 + 本番環境または重要な環境へのデプロイのための手動承認ゲートを実装することを検討します。 + **モニタリングとログ記録 ** + パイプライン、デプロイ、ボットインタラクションのモニタリングおよびログ記録メカニズムを設定します。 + パイプラインイベント、デプロイステータス、ボットパフォーマンスメトリクスをモニタリングし、問題を迅速に特定して対処します。 + Amazon CloudWatch などの AWS のサービス、および を使用して AWS CloudTrail、一元的なログ記録とモニタリング AWS X-Ray を行います。 + 自動ワークフローのパフォーマンス、効率、および有効性を定期的に見直して分析します。 + セキュリティとコンプライアンス + 安全なコーディングプラクティスを実装し、Amazon Lex ボットの開発とデプロイのセキュリティ AWS のベストプラクティスに従います。 + 最小特権の原則に合わせて IAM ロール、ポリシー、およびアクセス許可を定期的に見直して更新します。 + セキュリティスキャンとコンプライアンスチェックをパイプラインに統合することを検討します。 ## エピック ### Amazon Lex ボット管理用の IaC を設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ローカル環境を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-amazon-lex-bot-development-and-deployment-using-an-automated-workflow.html) | AWS DevOps | | `devops` 環境でクロスアカウントロールを作成します。 | `devops` アカウントは、CI/CD パイプラインのホスティングおよび管理を担当します。CI/CD パイプラインが `dev` および `prod` 環境とやり取りできるようにするには、以下のコマンドを実行して `devops` アカウントにクロスアカウントロールを作成します。
cdk bootstrap --profile=devops

cdk deploy LexMgmtDevopsRoleStack -c dev-account-id=2222222222222 -c prod-account-id=333333333333 --profile=devops
| AWS DevOps | | `dev` 環境でクロスアカウントロールを作成します。 | `dev` アカウントがこのロールを引き受けられるようにするために必要なアクセス許可を持つ IAM ロールを `devops` アカウントに作成します。CI/CD パイプラインは、このロールを使用して、Amazon Lex ボットリソースのデプロイや管理などのアクションを `dev` アカウントで実行します。IAM ロールを作成するには、以下のコマンドを実行します。
cdk bootstrap --profile=dev

cdk deploy LexMgmtCrossaccountRoleStack -c devops-account-id=1111111111111 --profile=dev
| AWS DevOps | | `prod` 環境でクロスアカウントロールを作成します。 | `prod` アカウントがこのロールを引き受けられるようにするために必要なアクセス許可を持つ IAM ロールを `devops` アカウントに作成します。CI/CD パイプラインは、このロールを使用して、Amazon Lex ボットリソースのデプロイや管理などのアクションを `prod` アカウントで実行します。
cdk bootstrap --profile=prod

cdk deploy LexMgmtCrossaccountRoleStack -c devops-account-id=1111111111111 --profile=prod
| AWS DevOps | | `devops` 環境にパイプラインを作成します。 | Amazon Lex ボットの開発ワークフローを管理するには、以下のコマンドを実行して `devops` 環境にパイプラインを設定します。
cdk deploy LexMgmtWorkflowStack -c devops-account-id=1111111111111 -c dev-account-id=2222222222222 -c prod-account-id=333333333333 --profile=devops
| AWS DevOps | ### メインボットのベースラインを確立する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | メインボットの初期バージョンを定義します。 | メインボットの初期バージョンを定義するには、`BaselineBotPipeline` パイプラインを[トリガー](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-triggers)します。このパイプラインは、CloudFormation テンプレートで定義されている基本的なボット定義をデプロイし、メインボット定義を .json ファイルとしてエクスポートし、メインボットコードをバージョン管理システムに保存します。 | AWS DevOps | ### 機能開発ワークフローを実装する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | チケットボットを作成し、機能を開発してテストします。 | `TicketBot` は、機能ブランチにある既存のメインボット定義からインポートされる新しいボットインスタンスです。このアプローチにより、メインボットの最新の機能と設定が新しいボットに含まれることが保証されます。チケットボットの初期バージョンを定義するには、`CreateTicketBotPipeline` パイプラインをトリガーします。このパイプラインは、バージョン管理システムに新しい機能ブランチを作成し、メインボットに基づいて新しいチケットボットインスタンスを作成します。 | Lex ボット開発者 | | チケットボット機能を開発してテストします。 | 機能を開発してテストするには、 にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) で Amazon Lex コンソールを開きます。詳細については、Amazon Lex ドキュメントの「[コンソールを使用したボットのテスト](https://docs.aws.amazon.com/lexv2/latest/dg/test-bot.html)」を参照してください。`TicketBot` インスタンスにより、ボットの機能を追加、変更、または拡張して新機能を実装できるようになりました。例えば、インテント、発話、スロット、ダイアログフローを作成または変更できます。詳細については、Amazon Lex ドキュメントの「[インテントの追加](https://docs.aws.amazon.com/lexv2/latest/dg/add-intents.html)」を参照してください。 | Lex ボット開発者 | | チケットボット定義をエクスポートします。 | エクスポートされたボット定義は、基本的にボットの設定と機能を JSON 形式で表現したものです。チケットボット定義をエクスポートするには、`ExportTicketBotPipeline` パイプラインをトリガーします。このパイプラインは、チケットボット定義を .json ファイルとしてエクスポートし、チケットボットコードをバージョン管理システムの機能ブランチに保存します。 | Lex ボット開発者 | | 最新のメインブランチから機能ブランチをリベースします。 | 新機能の開発中に、別の開発者またはチームがメインブランチに他の変更を加えた可能性があります。これらの変更を機能ブランチに組み込むには、Git `rebase` オペレーションを実行します。このオペレーションは基本的に、メインブランチからの最新のコミットに加えて機能ブランチからのコミットをリプレイすることで、機能ブランチに最新の変更がすべて含まれるようにします。 | Lex ボット開発者 | | リベースされたチケットボットをインポートして検証します。 | 機能ブランチをリベースしたら、それをチケットボットインスタンスにインポートする必要があります。このインポートにより、既存のチケットボットがリベースされたブランチからの最新の変更で更新されます。リベースされたチケットボットをインポートするには、`ImportTicketBotPipeline` パイプラインをトリガーします。このパイプラインは、バージョン管理システムの機能ブランチにあるチケットボット定義 .json ファイルを `TicketBot` インスタンスにインポートします。 | Lex ボット開発者 | | リベースされたボット定義を検証します。 | リベースされたボット定義をインポートしたら、その機能を検証することが重要です。新機能が予期したとおりに動作し、既存の機能と競合しないことを確認する必要があります。この検証では、通常、ボットをさまざまな入力シナリオでテストし、レスポンスを調べて、ボットが意図したとおりに動作することを検証します。検証は、次のいずれかの方法で実行できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-amazon-lex-bot-development-and-deployment-using-an-automated-workflow.html) | Lex ボット開発者 | | 機能ブランチをメインブランチにマージします。 | 分離された `TicketBot` インスタンスで新機能を開発してテストしたら、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-amazon-lex-bot-development-and-deployment-using-an-automated-workflow.html) | Lex ボット開発者、リポジトリ管理者 | | 機能ブランチとチケットボットを削除します。 | 機能ブランチがメインブランチに正常にマージされたら、ソースコードリポジトリから機能ブランチとチケットボットを削除します。機能ブランチとチケットボットを削除するには、`DeleteTicketBotPipeline` パイプラインをトリガーします。このパイプラインは、開発プロセス中に作成された一時的なボットリソース (チケットボットなど) を削除します。このアクションは、リポジトリをクリーンな状態に保ち、将来の機能ブランチとの混同や競合を防ぐのに役立ちます。 | Lex ボット開発者 | ### メインボットを保守する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 最新のメインボット定義を `dev` 環境にインポートします。 | メインブランチの最新のメインボット定義を `dev` 環境にインポートするには、`DeployBotDevPipeline` パイプラインをトリガーします。このパイプラインは、承認時に git タグも作成します。 | AWS DevOps | | 最新のメインボット定義を `prod` 環境にインポートします。 | メインブランチの最新のボット定義を `prod` 環境にインポートするには、前のタスクのタグリファレンスをパラメータとして指定して `DeployBotProdPipeline` パイプラインをトリガーします。このパイプラインは、特定のタグの最新のボット定義を `prod` 環境にインポートします。 | AWS DevOps | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Amazon Lex ボットを別の にデプロイする場合 AWS アカウント、ツールサービスには、それらのアカウントのリソースにアクセスするために必要なアクセス許可が必要です。 | クロスアカウントアクセスを付与するには、IAM ロールとポリシーを使用します。ターゲットアカウントに IAM ロールを作成し、必要なアクセス許可を付与するロールにポリシーをアタッチします。次に、Amazon Lex ボットがデプロイされているアカウントからそれらのロールを引き受けます。詳細については、Amazon Lex ドキュメントの「[インポートに必要な IAM アクセス許可](https://docs.aws.amazon.com/lexv2/latest/dg/import.html#import-permissions)」と「[Lex V2 でボットをエクスポートするために必要な IAM アクセス許可](https://docs.aws.amazon.com/lexv2/latest/dg/export.html#export-permissions)」を参照してください。 | ## 関連リソース + [Amazon Lex V2 でのボットのインポート](https://docs.aws.amazon.com/lexv2/latest/dg/import.html) + [CodePipeline でパイプラインを開始する](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-about-starting.html) + [Amazon Lex V2 ボットの使用 V2 ](https://docs.aws.amazon.com/lexv2/latest/dg/building-bots.html)