AWSシステムとAzure Teams連携設定

1. Bot アプリケーションの登録

1.1 Azure サブスクリプションの用意

まずは Azure サブスクリプションの用意が必要になるため、Azure ポータル（ https://portal.azure.com ）にログインして、ポータル上部の検索バーから「サブスクリプション (Subscriptions)」を検索して開き、すでに利用可能なサブスクリプションがあるかどうかを確認します。サブスクリプションとしては Free Trial、Pay-As-You-Go、Visual Studio Enterprise Subscription などの種類があります。利用したいサブスクリプションがない場合は新たにサブスクリプションを作成し、無料体験や既存ビジネス契約を利用するなどの手段で準備を整えます。また、Bot リソースを作成するときにどのサブスクリプションを使うかを指定する場面があるため、必要に応じてサブスクリプション ID を事前に把握しておくと便利です。

1.2 Azure Bot リソースの作成（Bot Channels Registration）

続いて、Azure ポータルで「Bot Channels Registration」というリソースを作成し、Bot の登録を行います。方法としては、Azure ポータルにログイン後、画面上部の検索バーに「Bot Channels Registration」と入力し、表示された候補をクリックします。そして「Bot Channels Registration」の画面が表示されたら「作成 (Create)」ボタンをクリックします。

Bot Channels Registration を作成する画面では、利用するサブスクリプションとしては事前に把握しておいたものを選択し、Bot リソースを格納するリソース グループを指定します。新規に作成する場合は「新規作成」を選びます。Bot Channels Registration の名前については「my-demo-bot-reg」のような一意の名前を記入し、リソースを作成する場所としては East US や Japan East などを指定できます。また、価格レベルには F0（無料）か S1（標準）を選べるので、テスト用途ならば F0（無料）が適切です。Messaging endpoint には、Bot が受信するメッセージのエンドポイント、すなわち AWS 上で稼働している Bot ロジックに接続する URL（https://{AWS上のAPIゲートウェイ等}/api/messages のような形式）を指定します。ただし、Messaging endpoint については空欄のまま作成し、後から設定することもできます。いずれにしても後ほど「Settings」などから変更が可能です。

必要に応じて Bot の分析情報を取得したい場合は、アプリケーション Insights（App Insights）をオンにして設定します。設定が済んだら「確認および作成 (Review + create)」ボタンをクリックし、入力内容が正しいかを確認のうえ「作成 (Create)」を押します。数秒から数分ほど経過してリソースの作成が完了したら、Azure ポータルの左メニューにある「リソース グループ」から該当のリソース グループを開いて、たとえば「my-demo-bot-reg」のような名前で Bot Channels Registration リソースが作成されていることを確認します。

1.3 Microsoft App ID, App Password の取得（EntraID でのアプリ登録）

Bot が Microsoft Teams などのチャネルと連携するときには、EntraID（旧 Azure Active Directory）のアプリ登録によって「Microsoft App ID（Client ID）」と「App Password（Client Secret）」を取得しておく必要があります。Bot Channels Registration にこの認証情報を設定することで、Bot は EntraID を介した認証を行うようになるためです。

まずは Azure ポータル上部の検索バーで「Azure Active Directory」を探し、表示された候補をクリックします。左ペインのメニューに「アプリの登録 (App registrations)」があるので選択し、「新規登録 (New registration)」ボタンをクリックしてアプリケーション登録画面へ進みます。ここでアプリの表示名として「my-demo-bot-aad-app」のように分かりやすい名前をつけ、アプリがサインインを許可するアカウントの範囲として通常は「この組織ディレクトリ内のアカウントのみ (Single tenant)」のような単一テナント設定を選びます。Bot Framework 側の処理でリダイレクト URI が自動的に行われることが多いため、リダイレクト URI（オプション）は空欄のままにしておいても問題ない場合が多いです。最後に「登録 (Register)」を押すとアプリが作成されます。

登録後、「概要 (Overview)」タブに移ると「アプリケーション (クライアント) ID」と「ディレクトリ (テナント) ID」が表示されます。アプリケーション (クライアント) ID がのちに Microsoft App ID として扱われます。Bot 開発ではディレクトリ (テナント) ID を明示的に使わない場合も多いですが、認証連携で必要になるケースがあります。

次に「証明書とシークレット (Certificates & secrets)」を開き、「新しいクライアント シークレット (New client secret)」を追加します。シークレットの説明（例: MyBotSecretKey）や有効期限を設定して「追加 (Add)」すると、シークレットの「値 (Value)」が生成されます。この値が「App Password（Client Secret）」に該当し、画面を離れると再表示できないため、このタイミングで安全な場所（Azure Key Vault やパスワード管理ツールなど）にコピーして保管してください。

1.4 Bot Channels Registration に App ID / Password を設定

先ほど取得したアプリケーション (クライアント) ID と Client Secret を Bot Channels Registration リソースと関連付けます。Azure ポータル上部の検索バー、あるいはリソース グループから対象の Bot Channels Registration（たとえば「my-demo-bot-reg」）を開き、「Settings」もしくは「構成 (Configuration)」というタブを表示します。「Microsoft App ID (アプリケーション ID)」にアプリケーション (クライアント) ID を貼り付け、「Microsoft App Password (Client Secret)」にクライアント シークレットの値を入力します。Messaging endpoint が未設定または変更が必要であれば、AWS 上の Bot ロジックが受け取るエンドポイント URL（例: https://{AWS API Gateway}/api/messages）を入力し、HTTPS で有効な証明書が使われていることを確認します。入力し終えたら「保存 (Save)」を行い、「Overview」や「概要」に戻って「Test in Web Chat」などが動作するかを必要に応じて確認します。

1.5 ここまでのまとめ

この段階までに、まずは Bot を作るための Azure サブスクリプションを準備し、Bot Channels Registration リソースを作成してリソース名やリージョン、Messaging endpoint、価格レベルを指定しました。その際、EntraID アプリ登録で Microsoft App ID と App Password を取得し、Bot Channels Registration 側に認証情報を関連付けることで、Azure 上での Bot Channels Registration と EntraID 認証が紐づいた Bot のベースを完成させました。次のステップでは、Microsoft Teams などのチャネルを有効化するための追加設定を行い、Teams 上で Bot とやり取りできるようにします。

2. Teams 連携の設定

2.1 Bot Channels Registration で Teams チャネルを有効化

Azure 上で作成した Bot Channels Registration リソースを Microsoft Teams と連携させるため、まずは Bot Channels Registration の「Channels」設定で Teams を有効にします。Azure ポータル（ https://portal.azure.com ）にログインした後、前のステップで作成した Bot Channels Registration リソース（例: 「my-demo-bot-reg」）を検索し、リソースを開きます。左メニューや上部タブにある「Channels」をクリックすると、既に Web Chat、Direct Line などが表示されている場合がありますが、この時点では Microsoft Teams のチャネルが有効化されていません。

Teams を有効化するには「Channels」の一覧から「Microsoft Teams」を探し、クリックして「Configure Microsoft Teams Channel (Microsoft Teams チャネルの構成)」画面を開きます。必要に応じて、Teams での音声通話やビデオ通話を Bot で受ける場合の Calling 設定を行ったり、パブリック (Publish to Teams) とプライベートのどちらで Bot を Teams アプリとして配信するかを選択したりします。通常のチャットボット用途であれば呼び出し機能はオフにし、Bot をプライベートにサイドロードする構成が多いかもしれません。最後に「Save」や「Done」をクリックすると設定が保存され、Teams チャネルが「Connected」などのステータスになることで有効化が確認できます。もし「Waiting ...」という表示が出ている場合は、構成が反映されるまで数分待ちます。

2.2 Teams アプリとして利用する場合のアプリ マニフェスト作成（任意）

Teams 上で Bot を独立したアプリケーションのように扱うには、Teams 用アプリ マニフェストを作成します。これは manifest.json とアイコン画像（color.png / outline.png）の合計 3 つのファイルを .zip 形式でまとめたパッケージによって構成されます。

具体的には、マニフェストでは Bot の Microsoft App ID、アプリ名、説明、アイコンの指定、Bot スコープ（personal、team、groupchat など）を記載します。たとえばマニフェストのバージョンを 1.11 と想定すると、JSON ファイルの最上部に $schema として Microsoft Teams のスキーマを指定し、Bot に対応したスコープやコマンドリストを定義するといった形式になります。
また、アイコンとしては outline.png と color.png の 2 種類を用意しておきます。解像度や容量制限などは Microsoft の公式ドキュメントを参照してください。最後にこれらファイルを同一ディレクトリにまとめて、フォルダ階層を作らずに .zip 形式へ圧縮することでアプリ パッケージが完成します。

作成したパッケージを組織内に配布したい場合は、Microsoft Teams 管理センター（ https://admin.teams.microsoft.com/ ）へアクセスし、「Teams アプリ」→「アプリの管理 (Manage apps)」からアップロードします。テナント全体で使用可能にしたり、特定のポリシーを適用したりできます。個人開発やテスト用途であれば、Teams クライアント（デスクトップ版や Web 版）の「アプリ」メニューで「カスタム アプリをアップロード (Upload a custom app)」を選び、パッケージをサイドロードすることで一時的に利用できます。
これによって、ユーザーは 1対1 チャットやチャンネルで Bot にメッセージを送信し、Bot が応答する形で動作を確認できます。

2.3 Teams 管理ポリシーの設定（必要に応じて）

組織（テナント）の管理者が Teams のアプリ使用を制限している場合は、ポリシーによって自作アプリ（Bot）を使用許可に設定しないといけない可能性があります。ここでは主に Teams 管理センター（ https://admin.teams.microsoft.com/ ）へのアクセスが必要となります。
具体的には「Teams アプリ」→「Permission policies」（アプリ許可ポリシー）において、サードパーティ アプリやカスタム アプリを許可しているかどうかを確認し、また「Teams アプリ」→「Setup policies」（アプリの設定ポリシー）で Bot をピン留めするか、特定ユーザー / グループに対してアプリ ポリシーを割り当てるといった設定ができます。設定を変更した場合は、数分から数時間のタイムラグが発生する場合があるため、ユーザーが Bot アプリをインストールできないという問い合わせがあった場合は、しばらく待ってから再度確認する必要があります。

2.4 まとめ（Teams 連携）

Teams 連携については、まず Bot Channels Registration の「Channels」タブで Microsoft Teams チャネルを有効化して設定を保存します。必要に応じて、Teams アプリとして配布したい場合はマニフェスト（manifest.json とアイコンファイル）を作成して .zip 化し、それを管理センターにアップロードまたはサイドロードでテストします。
最後に、カスタム アプリ / Bot の使用を組織ポリシーで許可するかどうかを設定し、ユーザーがアプリを追加できる状態にします。これにより、Teams 上で実際に Bot をアプリとして利用できるようになり、テストとして Teams クライアントからメッセージを送信し、AWS 上の Bot ロジックが応答を返してくれることを確認すれば、基本的な連携が成立します。

3. 認証・セキュリティ設定

Bot と Microsoft Teams（あるいは他のチャネル）を連携する場合、ユーザー認証（OAuth）や、Bot（Azure）から AWS 側への安全な API 呼び出し、SSL/TLS 証明書の管理など、さまざまな認証・セキュリティ面の設定が重要です。

3.1 OAuth などの認証フローの設定（ユーザー認証が必要な場合）

3.1.1 シナリオの概要

ユーザーが Teams のチャットを通じて Bot にメッセージを送り、Bot はユーザー本人の資格情報を用いて Microsoft Graph などの外部リソースにアクセスするシナリオでは、Bot と EntraID（旧 Azure Active Directory）の間に OAuth フローが必要となります。この認証フローを簡易的に実装するためには、Azure Bot Service で提供される OAuth Connection 機能を使用するのが一般的です。

3.1.2 EntraID による OAuth アプリ登録（前提）

すでに Bot 用のアプリ（Microsoft App ID）は作成済みですが、ユーザーの代理権限で Microsoft Graph などにアクセスするためには、追加の Delegated Permissions（例: User.Read, Mail.Read など）を付与する必要があります。具体的には Azure ポータルで EntraID を開き、アプリ登録の画面で Bot 用アプリを選択して「API Permissions」を確認し、該当する権限を追加して管理者同意（Grant admin consent）を与えます。Bot Framework で標準的に使用される token.botframework.com などのリダイレクト URI は多くの場合自動で扱われるため、ここで手動設定する必要はあまりありません。

3.1.3 Bot リソースに OAuth Connection を作成

Bot Channels Registration や Azure Bot Service の画面から「Settings」や「Configuration」を開き、「OAuth Connections」セクションで「Add OAuth Connection」をクリックすると、名前やプロバイダー、クライアント ID / シークレット、テナント ID、スコープなどを入力できるダイアログが表示されます。たとえば接続名（Name）を GraphConnection、サービス プロバイダーを Azure Active Directory v2、Client Id と Client Secret を先ほど登録したアプリのものにし、テナント ID とスコープ（User.Read, Mail.Read など）を指定したうえで保存します。保存後、この接続が OAuth Connections リストに表示されていれば設定が完了です。

3.1.4 Bot コードで認証フローを呼び出す（概要）

Bot Framework SDK（C#, Node.js など）を使う場合、SignInCard や OAuthPrompt といった仕組みでユーザーをサインインさせるコードを記述することができます。典型的な流れとしては、まず Bot がユーザーにサインインカードを送信し、ユーザーがそのリンクをクリックすることで EntraID にサインインします。すると Bot Framework がトークンを取得して Bot に返却し、Bot がそのトークンを使って Microsoft Graph API を呼び出すといった手順が行われます。なお、Bot コード内で接続名として先ほど設定した GraphConnection を参照する必要があります。

3.2 Bot と AWS 間のセキュリティ（AWS 側 API 認証など）

3.2.1 シナリオの概要

Bot（Azure）から AWS の API Gateway や Lambda などを呼び出し、追加の処理やデータを取得したいケースでは、API 側で認証が必要となる場合があります。たとえば API Key、IAM 認証、JWT などの認証方式が存在し、機密情報（API キーやシークレットキーなど）は安全に保管しなければなりません。

3.2.2 API Gateway での認証フロー例

API Gateway が IAM 認証モードで公開されている場合、Bot コード側からは AWS アクセスキーとシークレットキーによる SigV4 署名付きリクエストを行う仕組みを実装します。この署名生成は AWS SDK（.NET、Node.js など）を使えば比較的容易に行えます。ただし、アクセスキーやシークレットキーは Key Vault や Parameter Store などで安全に管理し、Bot コードが外部に漏らさないようにします。また、API キー認証で x-api-key ヘッダを付与するだけの方式もあり、その場合も API キー自体を安全に保管しなければいけません。さらに、カスタム認証 / Lambda オーソライザー / JWT などを組み合わせて、Bot が取得したトークンを API Gateway に送信して検証するといったシナリオも存在します。

3.2.3 認証情報の安全な保管

認証情報の安全な保管方法としては、Azure Key Vault を利用して Azure 側で管理する方法が代表的です。Bot のコードは Key Vault から認証情報を取得して、動的に署名を生成して AWS へリクエストします。また、AWS Systems Manager Parameter Store や Secrets Manager に格納する方法もありますが、Bot（Azure）から直接参照する場合にはネットワーク構成を合わせて考慮する必要があります。

3.2.4 ポリシー設定 (IAM ポリシー)

API Gateway や Lambda を IAM 認証で保護している場合は、呼び出し元ロールまたはユーザーに対して「execute-api:Invoke」などを許可する IAM ポリシーを付与し、最小限の権限だけ認めるようにします。

3.3 SSL/TLS 証明書の管理

3.3.1 ボットのエンドポイント（Messaging endpoint）側

Bot Channels Registration の Messaging endpoint には HTTPS を使用する必要があります。AWS API Gateway でカスタムドメインを利用する場合、AWS Certificate Manager (ACM) でドメインに対応した証明書を取得して導入します。API Gateway の既定ドメインを使う場合でも HTTPS を利用できますが、カスタムドメインを使うと独自のホスト名でエンドポイントを提供できるメリットがあります。

3.3.2 クライアント（Bot 側）から AWS へのアクセス

Bot 側が AWS のエンドポイントへ HTTPS でアクセスするとき、一般的なパブリック証明書を使うサイトなら追加設定は不要です。ただし、自己署名やプライベート CA を使う場合、Bot をホストしている Azure App Service などにルート証明書をインストールする必要が出てきます。

3.3.3 証明書の有効期限・自動更新

Let’s Encrypt や AWS Certificate Manager は自動更新の仕組みがあるため、証明書の期限切れによる障害を防止しやすくなります。手動で管理している場合は、有効期限切れに注意しなければなりません。

3.4 まとめ（認証・セキュリティ設定）

以上のように、ユーザー認証が必要な場合は EntraID アプリ登録で必要なパーミッションを設定し、Bot リソースに OAuth Connection を定義します。Bot（Azure）から AWS へアクセスする際は IAM 認証（SigV4）や API キー、JWT カスタム認証などを選択し、Key Vault や Secrets Manager などで鍵やシークレットを安全に保管します。IAM ポリシーも最小権限で設定するようにして、Messaging endpoint 側を含めた SSL/TLS 証明書の管理や更新計画を整えれば、Bot と AWS の通信をセキュアに保つことができます。

4. ネットワーク周りの考慮

ここでは、AWS 上のサービスをインターネットで公開するか、それとも VPN / ExpressRoute / Direct Connect などの専用線でプライベート接続するかなど、ネットワーク構成を検討する際のポイントを示します。また、Azure VNET 統合や Firewall / IP 制限についても解説します。

4.1 AWS 上のサービスを外部公開かプライベート接続かの検討

4.1.1 外部公開（インターネット経由）

もっともシンプルな構成として、Bot Service（Azure）がインターネットを経由して AWS の API Gateway、ALB、EC2、Lambda などにアクセスする方法があります。これを実装するときは、公開部分を HTTPS で保護したうえで認証や IP アドレス制限を検討します。たとえば API Gateway や ALB をインターネットに向けて公開し、AWS Certificate Manager でカスタムドメインの証明書を設定して SSL/TLS を有効にし、Security Group でインバウンド許可範囲を検討します。また、場合によっては IAM 認証や API キー、JWT、Lambda オーソライザーなどを使ってエンドポイントを保護します。一方、Azure 側では Bot Channels Registration の Messaging Endpoint にパブリックに到達可能な HTTPS URL を設定し、必要なら Bot Service / Teams からの送信元 IP アドレスを AWS 側の許可リストに登録します。

4.1.2 プライベート接続（VPN, ExpressRoute, AWS Direct Connect など）

インターネットを介さずに Azure と AWS のあいだをプライベート接続でつなぎたい場合、専用線や VPN トンネルを用いてセキュリティ要件をより高める構成を考えます。具体的には、Bot がホストされている Azure App Service（あるいは Azure Functions）で VNET Integration を有効にし、その VNET と AWS 側の VPC を Site-to-Site VPN や Direct Connect（Gateway）でつなげる形になります。ただし、この構成では Bot Channels Registration のエンドポイントがパブリック FQDN（グローバルに名前解決できるドメイン）である必要があるため、挟み込みとして Azure API Management を利用するといった工夫が必要になる場合もあります。

4.2 Azure 側のネットワーク設定（VNET Integration など）

4.2.1 Azure App Service / Azure Functions の VNET Integration

Bot の実行コードが Azure App Service または Azure Functions 上で動く場合、それらを VNET Integration することで VNET 内のプライベートリソースにアクセスできます。App Service の例としては、App Service の「Networking」画面で「VNet Integration」を開いて「Add VNet」ボタンを押し、どのサブネットを使うかを選択するだけでプライベート接続が有効になります。ただしサブネットには「Microsoft.Web」のサービスエンドポイントを許可しなければならないなど、いくつか事前の設定が必要です。動作確認としては、Linux App Service であれば SSH コンソールやログを使用して curl や ping で VNET 内リソースに届くかを確かめられます。Windows App Service では制限があるため、コード内で実際に通信するなどの手段が必要です。

4.3 Firewall / IP 制限の確認

4.3.1 Teams や Bot Service の送信元 IP

Bot Service や Microsoft Teams はクラウド上の分散インフラからリクエストを送るため、固定 IP レンジは変更される可能性があります。最新の情報は Microsoft の公式ドキュメントで確認しなければならず、厳格な IP 制限を行う場合はメンテナンスコストが高くなることを考慮します。

4.3.2 AWS 側 Firewall / Security Group / NACL

AWS 側では Security Group や Network ACL（NACL）を使ってインバウンドの TCP 443（HTTPS）をどの IP レンジに許可するかを調整することができます。さらに、AWS WAF を API Gateway や ALB にアタッチして、許可元 IP のリストやレートリミットなどを設定し、不正アクセスをブロックしたり負荷を抑制したりする手段も用意されています。

4.3.3 Azure サイドのアクセス制限（App Service Firewall 等）

Azure App Service では Access Restrictions 機能によって、特定の送信元 IP や VNET のみを許可するといった制限をかけられます。ただし、Bot Service や Teams の IP アドレスレンジは流動的な場合があるため、完全にロックダウンするのは難易度が高いです。Azure Front Door や Azure Application Gateway をフロントに置き、WAF ポリシーで保護するというパターンも存在します。

4.4 まとめ（ネットワーク周りの考慮）

AWS 上のサービスを外部公開するか、VPN・ExpressRoute・Direct Connect などを使ってプライベート接続にするかで設計が大きく異なります。外部公開は構築がシンプルな一方、HTTPS や認証、IP 制限などのセキュリティ対策を必須で検討しなければなりません。プライベート接続の場合はより高い安全性を得られますが、構築・運用のコストが増大します。
Azure 側では Bot をホストする App Service / Functions を VNET Integration して、AWS の VPC と専用線や VPN で接続するアーキテクチャも可能です。Teams / Bot Service の送信元 IP 範囲が頻繁に変わる可能性を踏まえ、Firewall や IP 制限をどうするかという点も考慮します。AWS 側の Security Group / NACL / WAF や Azure 側の Access Restrictions / Front Door / App Gateway といった機能を組み合わせることで、よりきめ細かいセキュリティを実現できます。

結論

上記の内容を踏まえ、Bot アプリケーションの登録から Teams チャネルの設定、認証・セキュリティ、ネットワーク周りの構成までを総合的に検討すれば、AWS 上で稼働するシステムと Microsoft Teams（Microsoft Bot Framework / Azure Bot Service）を円滑かつセキュアに連携できます。シンプルなパブリック構成から、専用線によるプライベート接続まで要件に応じて選択し、加えて認証情報の管理や証明書の更新計画をきちんと行うことで、信頼性の高い運用を目指すことが可能となります。