はじめに
Amazon Connectのコンタクトフローでは、Lambda関数を呼び出して外部データを取得し、その戻り値をフロー内で参照するという使い方が一般的です。
従来、Lambda関数の戻り値は $.External.attributeName というJSONPathで参照していました。
ところが、公式ドキュメントのコンタクト属性一覧ページを確認したところ、JSONPathリファレンスが $.LambdaInvocation.ResultData.attributeName に変わっていました。
「両者の記法に動作上の差があるのか？」「既存フローの $.External はそのまま使えるのか？」が気になったので、実際にコンタクトフローを構築して検証してみました。
本記事の情報は2026年4月時点のものです。
最新情報については公式ドキュメントをご確認ください。
前提条件
- Amazon Connectインスタンスの初期設定（受架電可能な状態）が完了していること
- AWS Lambdaの基本的な知識があること
先に結論
$.External と $.LambdaInvocation.ResultData はどちらも同じデータを参照でき、機能的な差異は確認できませんでした（以下、確認した項目）。
- プロンプトの再生ブロックでの値の参照
- コンタクト属性の確認ブロックでの条件分岐
- コンタクト属性の設定ブロックでのコピー
1. 何が変わったのか
ドキュメント間の記載比較
公式ドキュメントを横断的に確認したところ、ページによって記載が異なっていました。
| ドキュメントページ | 記載されているJSONPath |
|---|---|
| コンタクト属性一覧（英語版） | $.LambdaInvocation.ResultData.attributeName |
| 属性の参照方法（英語版） | $.External.AttributeKey |
| Lambda関数チュートリアル（英語版） |
$.External.Name など |
| Lambda属性の保存方法（英語版） | $.External.attributeName |
英語版・日本語版ともに同じ状態であり、コンタクト属性一覧ページのみが新しい記法になっています。
従来の記法
$.External.attributeName
Lambda関数が { "customerName": "田中太郎" } を返した場合、$.External.customerName で参照していました。
新しい記法
$.LambdaInvocation.ResultData.attributeName
同じ戻り値を $.LambdaInvocation.ResultData.customerName で参照する形です。
背景: 非同期Lambda実行の登場
Amazon ConnectのLambda関数ブロックには、非同期実行モードが追加されています。非同期実行では、Lambda呼び出し後すぐに次のブロックへ進み、結果は「Lambda 結果をロード」アクションで後から取得します。
この際、$.LambdaInvocation.InvocationId で非同期実行のリクエストIDを参照できます。したがって、$.LambdaInvocation という名前空間は、この非同期実行の仕組みとともに導入されたものと考えられます。
2. 検証してみた
2.1 構築環境
- AWS リージョン：東京（
ap-northeast-1）
2.2 検証内容
以下の項目について、旧記法（$.External）と新記法（$.LambdaInvocation.ResultData）の両方で値を参照できるかを確認します。
| # | 検証項目 | $.External での参照パス | $.LambdaInvocation での参照パス | 確認したいこと |
|---|---|---|---|---|
| 1 | プロンプトの再生 | $.External.customerName |
$.LambdaInvocation.ResultData.customerName |
Lambda戻り値をテキスト読み上げで参照できるか |
| 2 | コンタクト属性の確認 | タイプ「External」で条件分岐 | タイプ「Lambda Invocation」で条件分岐 | 条件分岐ブロックで参照できるか |
| 3 | コンタクト属性の設定 | タイプ「External」からコピー | タイプ「Lambda Invocation」からコピー | ユーザー定義属性へのコピーができるか |
2.3 Lambda関数の準備
検証用に、シンプルなキーバリューペアを返すLambda関数を作成します。
- 関数名：
任意の文字列 - ランタイム：
Python 3.14 - アーキテクチャ：
x86_64 - 実行ロール：
デフォルトロール - ソースコード
def lambda_handler(event, context):
return {
"customerName": "テスト太郎",
"accountId": "ACC-12345",
"balance": "10000"
}
上記Lambda関数を対象のAmazon Connectインスタンスへ追加します。
2.4 コンタクトフローの作成
$.External 記法と $.LambdaInvocation 記法の比較を1つのフローで検証します。全体の構成は以下のとおりです。
検証1: プロンプトの再生
①「AWS Lambda関数」ブロック
- アクションを選択：
Lambdaを呼び出す - 関数のARN：
作成したLambda関数 - 実行モード：
同期モード - タイムアウト：
3秒 - レスポンスの検証：
文字列マップ
②「プロンプトの再生」ブロック
1つのプロンプトブロック内で、$.External 記法と $.LambdaInvocation 記法の両方を並べて読み上げます。
- テキスト読み上げまたはチャットテキスト：
手動で設定 - 次として解釈：
テキスト - 読み上げるテキスト：
検証1 External記法 お名前: $.External.customerName
検証1 LambdaInvocation記法 お名前: $.LambdaInvocation.ResultData.customerName
検証1 External記法 アカウントID: $.External.accountId
検証1 LambdaInvocation記法 アカウントID: $.LambdaInvocation.ResultData.accountId
検証1 External記法 残高: $.External.balance
検証1 LambdaInvocation記法 残高: $.LambdaInvocation.ResultData.balance
検証2: コンタクト属性の確認
③「コンタクト属性を確認する」ブロック（$.External 記法）
- 確認する属性：
- 名前空間：
外部 - キー：
customerName
- 名前空間：
- 条件：
- 次と等しい：
テスト太郎
- 次と等しい：
④「プロンプトの再生」ブロック
- ③の条件一致時に「External記法 External タイプでの条件分岐に成功しました。」と読み上げ
⑤「コンタクト属性を確認する」ブロック（$.LambdaInvocation 記法）
- 確認する属性：
- 名前空間：
Lambda呼び出し - キー：
結果データ - 属性：
customerName
- 名前空間：
- 条件：
- 次と等しい：
テスト太郎
- 次と等しい：
⑥「プロンプトの再生」ブロック
- ⑤の条件一致時に「LambdaInvocation記法 Lambda Invocation タイプでの条件分岐に成功しました。」と読み上げ
検証3: コンタクト属性の設定
⑦「コンタクト属性の設定」ブロック（$.External 記法）
- ユーザー定義済み：
copiedByExternal - 動的(外部)：
customerName
⑧「コンタクト属性の設定」ブロック（$.LambdaInvocation 記法）
- ユーザー定義済み：
copiedByLambdaInvocation - 動的(Lambda呼び出し)：
- キー：
結果データ - 属性：
customerName
- キー：
⑨「プロンプトの再生」ブロック
- コピーした値を読み上げて確認
検証3 コンタクト属性の設定。
External記法でコピーした値:
$.Attributes.copiedByExternal
LambdaInvocation記法でコピーした値:
$.Attributes.copiedByLambdaInvocation
3. 動作確認
$.External 記法と $.LambdaInvocation 記法の両方で、Lambda関数の戻り値を正しく参照できるか、2.2検証内容をもとにテストしました。
3.1 動作確認結果
| 検証項目 | $.External | $.LambdaInvocation.ResultData |
|---|---|---|
| プロンプトの再生 | ⭕ | ⭕ |
| コンタクト属性の確認（条件分岐） | ⭕ | ⭕ |
| コンタクト属性の設定（ユーザー定義へコピー） | ⭕ | ⭕ |
テストの結果、3項目すべてにおいて $.External 記法と $.LambdaInvocation 記法の両方で正しく値を参照できることを確認しました。プロンプトの再生・コンタクト属性の確認・コンタクト属性の設定のいずれでも、読み上げ内容や分岐結果、コピーされた値に差異はありませんでした。
3.2 チャット表示例
4. 既存フローへの影響は？
AWSサポートに確認したところ、$.External と $.LambdaInvocation.ResultData は同一のデータを参照するエイリアスであり、同期実行・非同期実行・ネストされたJSONレスポンスのいずれにおいても機能的な差異はないとのことです。また、$.External が今後非推奨や廃止になる予定もないとの回答を得ています（2026年4月7日付）。
本記事では同期実行に絞って検証しましたが、上記の回答より非同期実行やネストされたJSONレスポンスにおいても同様に動作するとのことです。
したがって：
-
既存フローの改修は不要
-
$.Externalは引き続き動作し、廃止予定も現時点ではなし
-
-
非同期実行固有の属性（
$.LambdaInvocation.InvocationIdなど）は$.LambdaInvocation名前空間で参照する
といった結果となりました。
まとめ
本記事では、Amazon Connectの公式ドキュメントでLambda関数の戻り値を参照するJSONPathが $.LambdaInvocation.ResultData に変更されていた件について、AWSサポートへの確認と実際のコンタクトフロー構築による検証を行いました。
結論として、執筆時点では$.External と $.LambdaInvocation.ResultData に動作上の差異はなく、$.External の廃止予定もありません。既存フローはそのまま使い続けて問題ないかと思われます。
ドキュメントの記載変更を見て「今すぐ既存フローを書き換えなきゃ…」と不安になった方の参考になれば幸いです。