はじめに

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 の廃止予定もありません。既存フローはそのまま使い続けて問題ないかと思われます。

ドキュメントの記載変更を見て「今すぐ既存フローを書き換えなきゃ…」と不安になった方の参考になれば幸いです。

参考