翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # カスタムラベル付けワークフロー 以降のトピックでは、カスタムラベル付けテンプレートを使用した Ground Truth ラベル付けジョブの設定について説明します。カスタムラベル付けテンプレートを使用すると、カスタムワーカーポータル UI を作成してデータのラベル付けに使用できます。テンプレートは、HTML、CSS、JavaScript、[Liquid テンプレート言語](https://shopify.github.io/liquid/)、[Crowd HTML 要素](https://docs.aws.amazon.com/sagemaker/latest/dg/sms-ui-template-reference.html)を使用して作成できます。 ## 概要: Ground Truth でカスタムラベル付けワークフローを初めて作成する場合は、必要な手順の概要を以下で確認してください。 1. *ワークフォースのセットアップ* – カスタムラベル付けワークフローを作成するために、ワークフォースが必要になります。このトピックでは、ワークフォースの設定について説明します。 1. *カスタムテンプレートの作成* – カスタムテンプレートを作成するために、入力マニフェストファイルのデータをテンプレート内の変数に正しくマッピングすることが必要になります。 1. *Lambda 関数を使用したオプションの処理* – 入力マニフェストのデータをワーカーテンプレートに追加する方法や、ワーカー注釈をジョブの出力ファイルに記録する方法をを制御します。 また、カスタムラベル付けテンプレートの使い方をわかりやすく示した 3 つのエンドツーエンドのデモもあります。 **注記** 以下のリンクから参照できる例に、注釈前と注釈後の Lambda 関数が含まれています。これらの Lambda 関数はオプションです。 + [デモテンプレート: `crowd-bounding-box` を使用したイメージの注釈](sms-custom-templates-step2-demo1.md) + [デモテンプレート: `crowd-classifier` を使用したラベル付けインテント](sms-custom-templates-step2-demo2.md) + [Amazon SageMaker Ground Truth を使用してカスタムデータラベリングけワークフローを構築する](https://aws.amazon.com/blogs/machine-learning/build-a-custom-data-labeling-workflow-with-amazon-sagemaker-ground-truth/) **Topics** + [概要:](#sms-custom-templates-overview) + [ワークフォースのセットアップ](sms-custom-templates-step1.md) + [カスタムワーカータスクテンプレートの作成](sms-custom-templates-step2.md) + [Liquid を使用してオートメーションを追加する](sms-custom-templates-step2-automate.md) + [を使用したカスタムラベル付けワークフローでのデータの処理 AWS Lambda](sms-custom-templates-step3.md) + [デモテンプレート: `crowd-bounding-box` を使用したイメージの注釈](sms-custom-templates-step2-demo1.md) + [デモテンプレート: `crowd-classifier` を使用したラベル付けインテント](sms-custom-templates-step2-demo2.md) + [API を使用してカスタムワークフローを作成する](sms-custom-templates-step4.md) # ワークフォースのセットアップ このステップではコンソールを使用して、使用するワーカータイプを設定し、そのワーカータイプに必要なサブ選択項目を設定します。[開始方法: Ground Truth を使用して境界ボックスラベル付けジョブを作成する](sms-getting-started.md) のセクションでこの時点までステップを既に完了していること、および **[Custom labeling task]** (カスタムラベル付けタスク) を **[Task type **] (タスクのタイプ) として選択したことを前提としています。 **ワークフォースを設定するには** 1. 最初に、**[Worker types]** (ワーカータイプ) からオプションを選択します。現在、次の 3 種類を使用できます。 + **[Public]** (一般) では、Amazon Mechanical Turk による独立系請負業者のオンデマンドワークフォースを使用します。支払いはタスクごとに行います。 + **[Private]** (プライベート) では、組織内にとどめる必要のあるデータを処理するために従業員または請負業者を使用します。 + **ベンダー**は、 AWS Marketplace 経由で利用可能なデータラベリングサービスの提供を専門とするサードパーティーベンダーを使用します。 1. **[Public]** (一般) オプションを選択した場合は、**[number of workers per dataset object]** (データセットオブジェクトあたりのワーカー数) を設定するよう求められます。同じオブジェクトに対して同じタスクを複数のワーカーで実行すると、結果の精度が向上する可能性があります。デフォルトは 3 です。必要とする精度に応じて数を上げたり下げたりすることができます。 また、ドロップダウンメニューを使用して** [price per task]** (タスクごとの価格) を設定するように求められます。メニューは、タスクを完了するのにかかる時間に基づいて価格ポイントを推奨します。 これを決定するには、**[Private]** (プライベート) ワークフォースを使用して最初にタスクの簡単なテストを実行することをお勧めします。このテストによって、実際にタスクの完了にかかる時間を見積もることができます。その後、見積もりが **[Price per task]** (タスクあたりの料金)メニューに収まる価格帯を選択できます。平均時間が 5 分を超える場合は、タスクを小さい単位に分割することを検討します。 ## 次へ [カスタムワーカータスクテンプレートの作成](sms-custom-templates-step2.md) # カスタムワーカータスクテンプレートの作成 カスタムラベル付けジョブを作成するには、ワーカータスクテンプレートを更新し、マニフェストファイルの入力データをテンプレートで使用される変数にマッピングし、出力データを Amazon S3 にマッピングする必要があります。Liquid オートメーションを使用する高度な機能の詳細については、「[Liquid を使用してオートメーションを追加する](sms-custom-templates-step2-automate.md)」を参照してください。 以降のセクションで、各手順について説明します。 ## ワーカータスクテンプレート *ワーカータスクテンプレート*は、Ground Truth でワーカーのユーザーインターフェイス (UI) をカスタマイズするために使用するファイルです。ワーカータスクテンプレートは、HTML、CSS、JavaScript、[Liquid テンプレート言語](https://shopify.github.io/liquid/)、[Crowd HTML 要素](https://docs.aws.amazon.com/sagemaker/latest/dg/sms-ui-template-reference.html)を使用して作成できます。Liquid はテンプレートを自動化するために使用されます。Crowd HTML Elements は、一般的な注釈ツールを含めるために使用され、Ground Truth に送信するロジックを提供するために使用できます。 次のトピックでは、ワーカータスクテンプレートを作成する方法について説明します。Ground Truth ワーカータスクテンプレートの例のリポジトリは、[GitHub](https://github.com/aws-samples/amazon-sagemaker-ground-truth-task-uis) で確認できます。 ### SageMaker AI コンソールでベースワーカータスクテンプレートを使用する Ground Truth コンソールのテンプレートエディタを使用して、テンプレートの作成を開始できます。このエディタには、事前に設計された多数のベーステンプレートが含まれています。HTML および Crowd HTML Element コードの自動入力をサポートしています。 **Ground Truth カスタムテンプレートエディタにアクセスするには、次の手順を実行します。** 1. 「[ラベル付けジョブの作成 (コンソール)](sms-create-labeling-job-console.md)」の手順に従います。 1. 次に、**カスタム**をラベル付けジョブの**タスクタイプ**に選択します。 1. **[次へ]** を選択すると、**[カスタムラベル付けタスクの設定]** セクションのテンプレートエディタと基本テンプレートにアクセスできます。 1. (オプション) **[Templates]** (テンプレート) のドロップダウンメニューから基本テンプレートを選択します。テンプレートを最初から作成する場合は、ドロップダウンメニューから **[Custom]** (カスタム) を選択して、最小スケルトンのテンプレートを使用します。 次のセクションでは、コンソールでローカルに開発されたテンプレートを視覚化する方法について説明します。 #### ワーカータスクテンプレートをローカルで視覚化する コンソールを使用して、受信したデータをテンプレートがどのように処理するかをテストする必要があります。テンプレートの HTML 要素とカスタム要素がどのように表示されるかをテストするには、ブラウザを使用します。 **注記** 変数は解析されません。コンテンツをローカルで表示するときに、変数をサンプルコンテンツに置き換える必要があります。 次のコードスニペットの例は、カスタムな HTML 要素を描画するために必要なコードを読み込みます。これは、テンプレートのルックアンドフィールをコンソールではなく任意のエディタで開発する場合に使用します。 **Example** ``` ``` ### シンプルな HTML タスクのサンプルの作成 これで、ベースとなるワーカータスクテンプレートが作成されました。このトピックで、シンプルな HTML ベースのタスクテンプレートを作成していきます。 以下は、入力マニフェストファイルの入力例です。 ``` { "source": "This train is really late.", "labels": [ "angry" , "sad", "happy" , "inconclusive" ], "header": "What emotion is the speaker feeling?" } ``` HTML タスクテンプレートで、入力マニフェストファイルの変数をテンプレートにマッピングする必要があります。サンプル入力マニフェストの変数は、**task.input.source**、**task.input.labels**、および **task.input.header** の構文を使用してマッピングされます。 以下は、ツイートを分析するシンプルな HTML ワーカータスクテンプレートの例です。すべてのタスクは ` ` 要素で開始および終了します。標準の HTML `
` 要素と同様に、すべてのフォームコードはそれらの間に記述します。Ground Truth は、注釈前 Lambda を実装しない限り、テンプレートで指定されたコンテキストから直接ワーカーのタスクを生成します。Ground Truth または [前注釈 Lambda](sms-custom-templates-step3-lambda-requirements.md#sms-custom-templates-step3-prelambda) によって返される `taskInput` オブジェクトは、テンプレートの `task.input` オブジェクトです。 シンプルなツイート分析タスクでは、`` 要素を使用します。以下の属性は必須です。 + *name* - 出力変数の名前。ワーカー注釈は、出力マニフェストでこの変数名に保存されます。 + *categories* - JSON 形式の配列による考えられる回答。 + *header* - 注釈ツールのタイトル。 `` 要素には、少なくとも次の 3 つの子要素が必要です。 + ** - 上記の `categories` 属性に指定されたオプションに基づいてワーカーが分類するテキスト。 + ** - ツールの [詳細な手順の表示] リンクから表示できる手順。これを空白のままにすることはできますが、より良い結果を得るための適切な手順を提供することをお勧めします。 + ** - ツールのサイドバーに表示される、タスクのより簡単な説明。これを空白のままにすることはできますが、より良い結果を得るための適切な手順を提供することをお勧めします。 このツールのシンプルなバージョンを下に示します。変数 **\$1\$1 task.input.source \$1\$1** により、入力マニフェストファイルのソースデータが指定されます。**\$1\$1 task.input.labels \$1 to\$1json \$1\$1** は配列を JSON 表現に変換するための変数フィルターの例です。`categories` 属性は JSON である必要があります。 **Example サンプル入力マニフェスト のJSON で `crowd-classifier` を使用する例** ``` {{ task.input.source }} Try to determine the sentiment the author of the tweet is trying to express. If none seem to match, choose "cannot determine." Pick the term that best describes the sentiment of the tweet. ``` Ground Truth ラベル付けジョブ作成ワークフローでコードをエディタにコピーアンドペーストしてツールをプレビューするか、[CodePen でこのコードのデモ](https://codepen.io/MTGT/full/OqBvJw)を試すことができます。 [https://codepen.io/MTGT/full/OqBvJw](https://codepen.io/MTGT/full/OqBvJw) ## 入力データ、外部アセット、タスクテンプレート 以下のセクションでは、外部アセットの使用、入力データ形式の要件、注釈前 Lambda 関数の使用を検討するタイミングについて説明します。 ### 入力データ形式の要件 入力マニフェストファイルを作成してカスタムな Ground Truth ラベル付けジョブで使用するする場合、データを Amazon S3 に保存する必要があります。入力マニフェストファイルは、カスタム Ground Truth ラベル付けジョブを実行するのと同じ AWS リージョン に保存する必要があります。さらに、カスタムラベル付けジョブの Ground Truth での実行に使用する IAM サービスロールへのアクセスが可能な任意の Amazon S3 バケットに保存できます。 入力マニフェストファイルは、改行区切りの JSON または JSON 行形式を使用する必要があります。各行は、標準の改行 **\$1n** や **\$1r\$1n** で区切られています。各行も、有効な JSON オブジェクトである必要があります。 さらに、マニフェストファイルの各 JSON オブジェクトには、`source-ref` または `source` のいずれかのキーが含まれている必要があります。キーの値は、次のように解釈されます。 + `source-ref` - オブジェクトのソースは、値に指定された Amazon S3 オブジェクトです。オブジェクトがイメージなどのバイナリオブジェクトである場合、この値を使用します。 + `source` - オブジェクトのソースが値です。オブジェクトがテキスト値の場合は、この値を使用します。 入力マニフェストファイルの書式化の詳細については、「[入力マニフェストファイル](sms-input-data-input-manifest.md)」を参照してください。 ### 注釈前の Lambda 関数 オプションで、*注釈前 Lambda* 関数を指定して、ラベル付けの前に入力マニフェストファイルからデータをどのように処理するかを管理できます。`isHumanAnnotationRequired` キーと値のペアを指定した場合は、注釈前の Lambda 関数を使用する必要があります。Ground Truth が注釈前 Lambda 関数を JSON 形式のリクエストに送信すると、次のスキーマが使用されます。 **Example `source-ref` キーと値のペアで識別されるデータオブジェクト** ``` { "version": "2018-10-16", "labelingJobArn": arn:aws:lambda:us-west-2:555555555555:function:my-function "dataObject" : { "source-ref": s3://input-data-bucket/data-object-file-name } } ``` **Example `source` キーと値のペアで識別されるデータオブジェクト** ``` { "version": "2018-10-16", "labelingJobArn" : arn:aws:lambda:us-west-2:555555555555:function:my-function "dataObject" : { "source": Sue purchased 10 shares of the stock on April 10th, 2020 } } ``` `isHumanAnnotationRequired` を使用する場合に予想される Lambda 関数からのレスポンスを次に示します。 ``` { "taskInput": { "source": "This train is really late.", "labels": [ "angry" , "sad" , "happy" , "inconclusive" ], "header": "What emotion is the speaker feeling?" }, "isHumanAnnotationRequired": False } ``` ### 外部アセットの使用 Amazon SageMaker Ground Truth カスタムテンプレートを使用すると、外部スクリプトやスタイルシートを埋め込むことができます。例えば、次のコードブロックは、`https://www.example.com/my-enhancement-styles.css` にあるスタイルシートをテンプレートに追加する方法を示しています。 **Example** ``` ``` エラーが発生した場合は、元のサーバーがアセットを含む正しい MIME タイプとエンコードヘッダーを送信していることを確認します。 例えば、リモートスクリプト用の MIME とエンコードタイプは `application/javascript;CHARSET=UTF-8` です。 リモートスタイルシート用の MIME と エンコードタイプは `text/css;CHARSET=UTF-8` です。 ## 出力データとタスクテンプレート 以下のセクションでは、カスタムラベル付けジョブからの出力データと、注釈後の Lambda 関数の使用を検討するタイミングについて説明します。 ### 出力データ カスタムラベル付けジョブが完了すると、ラベル付けジョブの作成時に指定された Amazon S3 バケットにデータが保存されます。データは `output.manifest` ファイルに保存されます。 **注記** *labelAttributeName* はプレースホルダー変数です。出力では、ラベル付けジョブの名前、またはラベル付けジョブの作成時に指定したラベル属性名のいずれかになります。 + `source` または `source-ref` – 文字列またはワーカーにラベル付けを要求する S3 URI。 + `labelAttributeName` – [注釈後の Lambda 関数](sms-custom-templates-step3-lambda-requirements.md#sms-custom-templates-step3-postlambda)から統合されたラベルコンテンツを含むディクショナリ。注釈後の Lambda 関数が指定されていない場合、このディクショナリは空になります。 + `labelAttributeName-metadata` – Ground Truth によって追加されたカスタムラベル付けジョブのメタデータ。 + `worker-response-ref` – データが保存されるバケットの S3 URI。注釈後の Lambda 関数が指定されている場合、このキーと値のペアは存在しません。 この例の JSON オブジェクトは読みやすい形式になっています。実際の出力ファイルでは、JSON オブジェクトは 1 行で記述されます。 ``` { "source" : "This train is really late.", "labelAttributeName" : {}, "labelAttributeName-metadata": { # These key values pairs are added by Ground Truth "job_name": "test-labeling-job", "type": "groundTruth/custom", "human-annotated": "yes", "creation_date": "2021-03-08T23:06:49.111000", "worker-response-ref": "s3://amzn-s3-demo-bucket/test-labeling-job/annotations/worker-response/iteration-1/0/2021-03-08_23:06:49.json" } } ``` ### 注釈後 Lambda を使用してワーカーの結果を統合する デフォルトでは、Ground Truth は Amazon S3 で未処理のワーカーレスポンスを保存します。レスポンスの処理方法を細かく制御するには、*[後注釈 Lambda 関数]* を指定します。例えば、複数のワーカーが同じデータオブジェクトにラベル付けしている場合、後注釈 Lambda 関数を使用して注釈を統合できます。後注釈 Lambda 関数の作成の詳細については、「[後注釈 Lambda](sms-custom-templates-step3-lambda-requirements.md#sms-custom-templates-step3-postlambda)」を参照してください。 後注釈 Lambda 関数を使用する場合は、`CreateLabelingJob` リクエストの [https://docs.aws.amazon.com//sagemaker/latest/APIReference/API_AnnotationConsolidationConfig.html](https://docs.aws.amazon.com//sagemaker/latest/APIReference/API_AnnotationConsolidationConfig.html) で指定する必要があります。 注釈の統合の仕組みの詳細については、「[注釈統合](sms-annotation-consolidation.md)」を参照してください。 # Liquid を使用してオートメーションを追加する カスタムテンプレートシステムは、オートメーションに [Liquid](https://shopify.github.io/liquid/) を使用します。これはオープンソースのインラインマークアップ言語です。Liquid では、一重波括弧とパーセント記号で囲まれたテキストは、制御フローやイテレーションなどを実行する 1 つの手順またはタグになります。**二重波括弧で囲まれたテキストは、値を出力する 1 つの変数または*オブジェクト*です。 最も一般的な Liquid の使用法としては、入力マニフェストファイルからのデータを解析して、関連する変数を抽出し、タスクを作成します。Ground Truth は、前注釈の Lambda が指定されていない限り、タスクを自動的に生成します。Ground Truth または [前注釈 Lambda](sms-custom-templates-step3-lambda-requirements.md#sms-custom-templates-step3-prelambda) によって返される `taskInput` オブジェクトは、テンプレートの `task.input` オブジェクトです。 入力マニフェストのプロパティは、`event.dataObject` としてテンプレートに渡されます。 **Example マニフェストデータオブジェクト** ``` { "source": "This is a sample text for classification", "labels": [ "angry" , "sad" , "happy" , "inconclusive" ], "header": "What emotion is the speaker feeling?" } ``` **Example 変数を使用したサンプル HTML** ``` {{ task.input.source }} ``` 上記の `labels` プロパティに ` | to_json` が追加されている点に注意してください。これは入力マニフェスト配列を JSON 形式に変換するためのフィルターです。可変フィルターについては次のセクションで説明します。 次のリストには、テンプレート入力データの処理を自動化するのに便利な 2 種類の Liquid タグが含まれています。以下のタグタイプのいずれかを選択すると、Liquid のドキュメントにリダイレクトされます。 + [フロー制御](https://shopify.github.io/liquid/tags/control-flow/): `if/else`、`unless`、`case/when` のようなプログラミングロジック演算子が含まれています。 + [イテレーション](https://shopify.github.io/liquid/tags/iteration/): FOR LOOP などのステートメントを使用して、コードのブロックを繰り返し実行できます。 Liquid 要素を使用して FOR LOOP を作成する HTML テンプレートの例については、GitHub で [translation-review-and-correction.liquid.html](https://github.com/aws-samples/amazon-sagemaker-ground-truth-task-uis/blob/8ae02533ea5a91087561b1daecd0bc22a37ca393/text/translation-review-and-correction.liquid.html) を参照してください。 詳細とドキュメントについては、[Liquid のホームページ](https://shopify.github.io/liquid/)を参照してください。 ## 可変フィルター 標準の [Liquid フィルター](https://shopify.github.io/liquid/filters/abs/)とアクションに加えて、Ground Truth には追加のフィルターがいくつか用意されています。フィルターを適用するには、パイプ (`|`) 文字を変数名の後ろに配置してからフィルター名を指定します。フィルターは次の形式で連鎖できます。 **Example** ``` {{ | | }} ``` ### 自動的なエスケープおよび明示的なエスケープ デフォルトでは、変数テキストと HTML との間の混乱を避けるために、入力はエスケープされた HTML になります。`escape` フィルターを明示的に追加すると、エスケープ処理の完了しているテンプレートのソースをユーザーが読み取ることをより明確に指定できます。 ### escape\$1once `escape_once` を使用すると、既にエスケープしたコードは確実に再度エスケープされなくなります。これにより、例えば、& は & になりません。 ### skip\$1autoescape `skip_autoescape` は、コンテンツが HTML として使用されるよう設計されている場合に便利です。例えば、いくつかの段落のテキストとイメージが境界ボックスの詳細な手順にある場合です。 **`skip_autoescape` の使用は慎重に** テンプレートにおけるベストプラクティスは、`skip_autoescape` を使用して関数コードやマークアップを渡さないようにすることです。ただし、渡す内容を厳重に管理できることが確実な場合を除きます。ユーザー入力を渡している場合は、ワーカーをクロスサイトスクリプティング攻撃に対して開放している可能性があります。 ### to\$1json `to_json` は、JSON (JavaScript Object Notation) に供給する内容をエンコードします。オブジェクトを供給している場合は、シリアル化されます。 ### grant\$1read\$1access `grant_read_access` は S3 URI を使用し、そのリソースに対する存続期間の短いアクセストークンを使用する HTTPS URL にエンコードします。これにより、通常であればパブリックにアクセス可能でない、S3 バケットに保存された写真、音声、または動画オブジェクトをワーカーに表示できるようになります。 ### s3\$1presign `s3_presign` フィルターは `grant_read_access` フィルターと同様に機能します。`s3_presign` は Amazon S3 URI を使用し、そのリソースに対する存続期間の短いアクセストークンを使用する HTTPS URL にエンコードします。これにより、ワーカーに公開していない S3 バケットに保存されている写真、音声、動画などのオブジェクトをワーカーに表示できるようになります。 **Example 変数フィルターの** Input ``` auto-escape: {{ "Have you read 'James & the Giant Peach'?" }} explicit escape: {{ "Have you read 'James & the Giant Peach'?" | escape }} explicit escape_once: {{ "Have you read 'James & the Giant Peach'?" | escape_once }} skip_autoescape: {{ "Have you read 'James & the Giant Peach'?" | skip_autoescape }} to_json: {{ jsObject | to_json }} grant_read_access: {{ "s3://amzn-s3-demo-bucket/myphoto.png" | grant_read_access }} s3_presign: {{ "s3://amzn-s3-demo-bucket/myphoto.png" | s3_presign }} ``` **Example** Output ``` auto-escape: Have you read 'James & the Giant Peach'? explicit escape: Have you read 'James & the Giant Peach'? explicit escape_once: Have you read 'James & the Giant Peach'? skip_autoescape: Have you read 'James & the Giant Peach'? to_json: { "point_number": 8, "coords": [ 59, 76 ] } grant_read_access: https://s3.amazonaws.com/amzn-s3-demo-bucket/myphoto.png? s3_presign: https://s3.amazonaws.com/amzn-s3-demo-bucket/myphoto.png? ``` **Example 自動分類テンプレートの** このシンプルなテキスト分類サンプルを自動化するには、ツイートテキストを変数に置き換えます。 以下のテキスト分類テンプレートには、自動化が追加されています。変更および追加は太字で表示されています。 ``` {{ task.input.source }} Try to determine the feeling the author of the tweet is trying to express. If none seem to match, choose "other." Pick the term best describing the sentiment of the tweet. ``` 以前のサンプルにあったツイートテキストは、オブジェクトに置き換えられています。`entry.taskInput` オブジェクトは `source` (または前注釈 Lambda で指定する別の名前) をテキストのプロパティ名として使用し、これは二重波括弧で囲まれていることから直接 HTML に挿入されます。 # を使用したカスタムラベル付けワークフローでのデータの処理 AWS Lambda このトピックでは、カスタムラベル付けワークフローを作成するときに、オプションで [AWS Lambda](https://aws.amazon.com/lambda/) 関数をデプロイする方法について説明します。カスタムラベル付けワークフローで使用する Lambda 関数は 2 種類あります。 + *前注釈 Lambda*: この関数は、ラベル付けジョブに送信された各データオブジェクトをワーカーに送信する前に開始し、前処理します。 + *注釈後 Lambda*: ワーカーがタスクを送信すると、この関数は結果を処理します。データオブジェクトごとに複数のワーカーを指定する場合、この関数に注釈を統合するロジックが含まれる場合があります。 Lambda と Ground Truth を初めて使用する場合は、このセクションのページを以下のように使用することをお勧めします。 1. まず、「[前注釈と後注釈の Lambda 関数をテストするLambda 関数を使用する](sms-custom-templates-step3-lambda-requirements.md)」 を確認します。 1. 次に、「[Ground Truth AWS Lambda で使用するために必要なアクセス許可を追加する](sms-custom-templates-step3-lambda-permissions.md)」の ページを使用して、Ground Truth カスタムラベル付けジョブで注釈前と注釈後の Lambda 関数を使用するためのセキュリティ要件と権限要件について学習します。 1. 次に、Lambda コンソールにアクセスするか、Lambda の API を使用して関数を作成する必要があります。関数の作成方法については「[Ground Truth テンプレートを使用して Lambda 関数を作成する](sms-custom-templates-step3-lambda-create.md)」 セクションで確認できます。 1. Lambda 関数のテスト方法については、「[前注釈と後注釈の Lambda 関数をテストする](sms-custom-templates-step3-lambda-test.md)」を参照してください。 1. 前処理と後処理の Lambda 関数を作成したら、Ground Truth コンソールでカスタム HTML のコードエディタの後に表示される **[Lambda functions]** (Lambda 関数) セクションからそれらを選択します。`CreateLabelingJob` API リクエストでこれらの関数を使用する方法については、「[ラベル付けジョブを作成 (API)](sms-create-labeling-job-api.md)」を参照してください。 前注釈と後注釈の Lambda 関数の例を含むカスタムラベル付けワークフローのチュートリアルについては、「[デモテンプレート: `crowd-bounding-box` を使用したイメージの注釈](sms-custom-templates-step2-demo1.md)」ドキュメントを参照してください。 **Topics** + [前注釈と後注釈の Lambda 関数をテストする](sms-custom-templates-step3-lambda-requirements.md) + [Ground Truth AWS Lambda で使用するために必要なアクセス許可を追加する](sms-custom-templates-step3-lambda-permissions.md) + [Ground Truth テンプレートを使用して Lambda 関数を作成する](sms-custom-templates-step3-lambda-create.md) + [前注釈と後注釈の Lambda 関数をテストする](sms-custom-templates-step3-lambda-test.md) # 前注釈と後注釈の Lambda 関数をテストする このセクションでは、前注釈と後注釈の Lambda 関数に送信されるリクエストの構文と、Ground Truth でカスタムラベル付けワークフローを実行するために必要な応答構文について学習します。 **Topics** + [前注釈 Lambda](#sms-custom-templates-step3-prelambda) + [後注釈 Lambda](#sms-custom-templates-step3-postlambda) ## 前注釈 Lambda ラベル付けタスクがワーカーに送信される前に、前注釈の Lambda 関数をオプションで呼び出すことができます。 Ground Truth は、Lambda 関数に JSON 形式のリクエストを送信し、ラベル付けジョブとデータオブジェクトに関する詳細を提供します。 JSON 形式のリクエストの例を次に 2 つ示します。 ------ #### [ Data object identified with "source-ref" ] ``` { "version": "2018-10-16", "labelingJobArn": "dataObject" : { "source-ref": } } ``` ------ #### [ Data object identified with "source" ] ``` { "version": "2018-10-16", "labelingJobArn": "dataObject" : { "source": } } ``` ------ 次のリストに、前注釈リクエストスキーマを示します。各パラメータの詳細は以下のとおりです。 + `version`(文字列): Ground Truth で内部的に使用されるバージョン番号です。 + `labelingJobArn`(文字列): ラベル付けジョブの Amazon リソースネーム (ARN) です。この ARN は、`DescribeLabelingJob` のようなGround Truth ス API オペレーションを使用するときにラベル付けジョブを参照するために使用できます。 + `dataObject` (JSON オブジェクト): キーには、入力マニフェストファイルから、または Amazon SNS から送信された 1 つの JSON 行が含まれます。マニフェストの JSON 行オブジェクトのサイズは最大 100 キロバイトで、さまざまなデータを含むことができます。非常に基本的な画像注釈ジョブでは、`dataObject` JSONには注釈を付けるイメージを指定する `source-ref`キーのみが含まれる場合があります。データオブジェクト (テキスト行など) が入力マニフェストファイルに直接含まれている場合、データオブジェクトは `source` で識別されます。検証ジョブまたは調整ジョブを作成する場合、この行には、前のラベル付けジョブのラベルデータとメタデータが含まれる場合があります。 次の各タブに、前注釈リクエストの例を示します。これらのリクエストの例の各パラメータの説明は、タブ付きテーブルの下にあります。 ------ #### [ Data object identified with "source-ref" ] ``` { "version": "2018-10-16", "labelingJobArn": "arn:aws:sagemaker:us-west-2:111122223333:labeling-job/" "dataObject" : { "source-ref": "s3://input-data-bucket/data-object-file-name" } } ``` ------ #### [ Data object identified with "source" ] ``` { "version": "2018-10-16", "labelingJobArn": "arn:aws:sagemaker::111122223333:labeling-job/" "dataObject" : { "source": "Sue purchased 10 shares of the stock on April 10th, 2020" } } ``` ------ 代わりに、Ground Truth には、次のような形式の応答が必要です。 **Example 想定される戻りデータの** ``` { "taskInput": , "isHumanAnnotationRequired": # Optional } ``` 前の例では、`` には、カスタムワーカーテンプレートに必要な*すべての*データが含まれている必要があります。手順が常に同じである境界ボックスタスクを実行している場合は、単にイメージファイルの HTTP(S) または Amazon S3 リソースであることがあります。これが感情分析タスクであり、さまざまなオブジェクトに各種の選択肢がある場合には、文字列としてのオブジェクト参照、文字列の配列としての選択肢になります。 **`isHumanAnnotationRequired` の意義** デフォルト値が `true` に設定されるため、この値は任意です。明示的な設定の主なユースケースは、このデータオブジェクトを人間のワーカーによるラベル付けから除外する場合です。 マニフェストに複数のオブジェクトがあり、それらの中に人間の注釈を必要とするものと必要としないものがある場合は、`isHumanAnnotationRequired` 値を各データオブジェクトに含めることができます。注釈前 Lambda にロジックを追加して、オブジェクトに注釈が必要かどうかを動的に判断し、それに応じてこのブール値を設定できます。 ### 前注釈 Lambda 関数の例 次の基本的な前注釈 Lambda 関数は、最初のリクエストから `dataObject` の JSON オブジェクトにアクセスし、`taskInput` パラメータで返します。 ``` import json def lambda_handler(event, context): return { "taskInput": event['dataObject'] } ``` 入力マニフェストファイルが `"source-ref"` を使用してデータオブジェクトを識別すると仮定して、この注釈前 Lambda と同じラベル付けジョブで使用されるワーカータスクテンプレートには、`dataObject` を取り込むために以下のような Liquid 要素を含める必要があります。 ``` {{ task.input.source-ref | grant_read_access }} ``` 入力マニフェストファイルが `source` を使用してデータオブジェクトを識別する場合は、ワーカータスクテンプレートは、以下を使用して `dataObject` を取り込むことができます。 ``` {{ task.input.source }} ``` 次の注釈前 Lambda の例には、`dataObject` で使用されたキーを識別するロジックが含まれており、Lambda の return ステートメントで `taskObject` を使用してそのデータオブジェクトをポイントします。 ``` import json def lambda_handler(event, context): # Event received print("Received event: " + json.dumps(event, indent=2)) # Get source if specified source = event['dataObject']['source'] if "source" in event['dataObject'] else None # Get source-ref if specified source_ref = event['dataObject']['source-ref'] if "source-ref" in event['dataObject'] else None # if source field present, take that otherwise take source-ref task_object = source if source is not None else source_ref # Build response object output = { "taskInput": { "taskObject": task_object }, "humanAnnotationRequired": "true" } print(output) # If neither source nor source-ref specified, mark the annotation failed if task_object is None: print(" Failed to pre-process {} !".format(event["labelingJobArn"])) output["humanAnnotationRequired"] = "false" return output ``` ## 後注釈 Lambda すべてのワーカーがデータオブジェクトに注釈を付けたとき、または [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_HumanLoopConfig.html#SageMaker-Type-HumanLoopConfig-TaskAvailabilityLifetimeInSeconds](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_HumanLoopConfig.html#SageMaker-Type-HumanLoopConfig-TaskAvailabilityLifetimeInSeconds) に達したときのいずれか早い方で、Ground Truth はそれらの注釈を注釈後 Lambda に送信します。この Lambda は一般に、[注釈統合](sms-annotation-consolidation.md) に使用されます。 **注記** 統合後の Lambda 関数の例については、[aws-sagemaker-ground-truth-recipe](https://github.com/aws-samples/aws-sagemaker-ground-truth-recipe) GitHub リポジトリの [annotation\$1consolidation\$1lambda.py](https://github.com/aws-samples/aws-sagemaker-ground-truth-recipe/blob/master/aws_sagemaker_ground_truth_sample_lambda/annotation_consolidation_lambda.py) を参照してください。 次のコードブロックには、注釈後のリクエストスキーマが含まれています。各パラメータの説明は、下の箇条書きにあります。 ``` { "version": "2018-10-16", "labelingJobArn": , "labelCategories": [], "labelAttributeName": , "roleArn" : , "payload": { "s3Uri": } } ``` + `version` (文字列): Ground Truth で内部的に使用されるバージョン番号です。 + `labelingJobArn` (文字列): ラベル付けジョブの Amazon リソースネーム (ARN) です。この ARN は、`DescribeLabelingJob` のようなGround Truth ス API オペレーションを使用するときにラベル付けジョブを参照するために使用できます。 + `labelCategories` (文字列のリスト): コンソールで指定した、またはラベルカテゴリ設定ファイルに含まれるラベルカテゴリとその他の属性が含まれます。 + `labelAttributeName` (文字列): ラベル付けジョブの名前、またはラベル付けジョブの作成時に指定したラベル属性名のいずれかです。 + `roleArn` (文字列): ラベル付けジョブの作成時に指定する IAM 実行ロールの Amazon リソースネーム (ARN) です。 + `payload` (JSON オブジェクト): `s3Uri` を含む JSON キー。Amazon S3 内のそのデータオブジェクトの注釈データの場所を特定します。次の 2 番目のコードブロックは、この注釈ファイルの例です。 次のコードブロックは、注釈後リクエストの例を示しています。このサンプルリクエストの各パラメータの説明は、コードブロックの下にあります。 **Example 注釈後 Lambda リクエストの** ``` { "version": "2018-10-16", "labelingJobArn": "arn:aws:sagemaker:us-west-2:111122223333:labeling-job/labeling-job-name", "labelCategories": ["Ex Category1","Ex Category2", "Ex Category3"], "labelAttributeName": "labeling-job-attribute-name", "roleArn" : "arn:aws:iam::111122223333:role/role-name", "payload": { "s3Uri": "s3://amzn-s3-demo-bucket/annotations.json" } } ``` **注記** データオブジェクトで作業するワーカーがいない場合、`TaskAvailabilityLifetimeInSeconds` に達すると、データオブジェクトは失敗としてマークされ、注釈後 Lambda の呼び出しの一部として含まれません。 次のコードブロックには、ペイロードスキーマが含まれています。これは、注釈後 Lambda リクエストの `payload` JSON オブジェクトの `s3Uri` パラメータで示されるファイルです。例えば、前のコードブロックが注釈後の Lambda リクエストの場合、次の注釈ファイルの場所は `s3://amzn-s3-demo-bucket/annotations.json` になります。 各パラメータの説明は、下の箇条書きにあります。 **Example 注釈ファイルの** ``` [ { "datasetObjectId": , "dataObject": { "s3Uri": , "content": }, "annotations": [{ "workerId": , "annotationData": { "content": , "s3Uri": } }] } ] ``` + `datasetObjectId` (文字列): ラベル付けジョブに送信する各データオブジェクトに Ground Truth が割り当てる一意の ID を指定します。 + `dataObject` (JSON オブジェクト): ラベル付けされたデータオブジェクト。データオブジェクトが入力マニフェストファイルに含まれており、`source` キー (文字列など) によって特定されている場合は、`dataObject` にデータオブジェクトを特定する `content` キーが含まれます。それ以外の場合、データオブジェクトの場所 (リンクや S3 URI など) は、`s3Uri` で特定されます。 + `annotations` (JSON オブジェクトのリスト): このリストには、その `dataObject` にワーカーから送信された注釈ごとに 1 つの JSON オブジェクトが含まれます。注釈を送信したワーカーを特定するために使用できる一意の `workerId` を含む単一の JSON オブジェクト。`annotationData` キーには次のいずれかが含まれます。 + `content` (文字列): 注釈データが含まれます。 + `s3Uri` (文字列): 注釈データの場所を特定する S3 URI が含まれます。 次の表に、さまざまなタイプの注釈のペイロードに表示されるコンテンツの例を示します。 ------ #### [ Named Entity Recognition Payload ] ``` [ { "datasetObjectId": "1", "dataObject": { "content": "Sift 3 cups of flour into the bowl." }, "annotations": [ { "workerId": "private.us-west-2.ef7294f850a3d9d1", "annotationData": { "content": "{\"crowd-entity-annotation\":{\"entities\":[{\"endOffset\":4,\"label\":\"verb\",\"startOffset\":0},{\"endOffset\":6,\"label\":\"number\",\"startOffset\":5},{\"endOffset\":20,\"label\":\"object\",\"startOffset\":15},{\"endOffset\":34,\"label\":\"object\",\"startOffset\":30}]}}" } } ] } ] ``` ------ #### [ Semantic Segmentation Payload ] ``` [ { "datasetObjectId": "2", "dataObject": { "s3Uri": "s3://amzn-s3-demo-bucket/gt-input-data/images/bird3.jpg" }, "annotations": [ { "workerId": "private.us-west-2.ab1234c5678a919d0", "annotationData": { "content": "{\"crowd-semantic-segmentation\":{\"inputImageProperties\":{\"height\":2000,\"width\":3020},\"labelMappings\":{\"Bird\":{\"color\":\"#2ca02c\"}},\"labeledImage\":{\"pngImageData\":\"iVBOR...\"}}}" } } ] } ] ``` ------ #### [ Bounding Box Payload ] ``` [ { "datasetObjectId": "0", "dataObject": { "s3Uri": "s3://amzn-s3-demo-bucket/gt-input-data/images/bird1.jpg" }, "annotations": [ { "workerId": "private.us-west-2.ab1234c5678a919d0", "annotationData": { "content": "{\"boundingBox\":{\"boundingBoxes\":[{\"height\":2052,\"label\":\"Bird\",\"left\":583,\"top\":302,\"width\":1375}],\"inputImageProperties\":{\"height\":2497,\"width\":3745}}}" } } ] } ] ``` ------ 注釈後 Lambda 関数には、リクエストに含まれるすべての注釈をループしてアクセスするための次のようなロジックが含まれている場合があります。すべての例については、[aws-sagemaker-ground-truth-recipe](https://github.com/aws-samples/aws-sagemaker-ground-truth-recipe)GitHub リポジトリの [annotation\$1consolidation\$1lambda.py](https://github.com/aws-samples/aws-sagemaker-ground-truth-recipe/blob/master/aws_sagemaker_ground_truth_sample_lambda/annotation_consolidation_lambda.py) を参照してください。この GitHub の例では、独自の注釈統合ロジックを追加する必要があります。 ``` for i in range(len(annotations)): worker_id = annotations[i]["workerId"] annotation_content = annotations[i]['annotationData'].get('content') annotation_s3_uri = annotations[i]['annotationData'].get('s3uri') annotation = annotation_content if annotation_s3_uri is None else s3_client.get_object_from_s3( annotation_s3_uri) annotation_from_single_worker = json.loads(annotation) print("{} Received Annotations from worker [{}] is [{}]" .format(log_prefix, worker_id, annotation_from_single_worker)) ``` **ヒント** データに対して連結アルゴリズムを実行する場合は、 AWS データベースサービスで結果を保存するか、処理された結果を Ground Truth に戻すことができます。Ground Truth に返すデータは、ラベル付けジョブの設定中に出力用に指定された S3 バケット内の統合注釈マニフェストに保存されます。 代わりに、Ground Truth には、次のような形式の応答が必要です。 **Example 想定される戻りデータの** ``` [ { "datasetObjectId": , "consolidatedAnnotation": { "content": { "": { # ... label content } } } }, { "datasetObjectId": , "consolidatedAnnotation": { "content": { "": { # ... label content } } } } . . . ] ``` この時点で、S3 バケットに送信している、`datasetObjectId` 以外のすべてのデータが `content` オブジェクトに配置されます。 `content` で注釈を返すとき、これにより、ジョブの出力マニフェストに次のようなエントリが生成されます。 **Example 出力マニフェストでのラベル形式の** ``` { "source-ref"/"source" : "", "": { # ... label content from you }, "-metadata": { # This will be added by Ground Truth "job_name": , "type": "groundTruth/custom", "human-annotated": "yes", "creation_date": # Timestamp of when received from Post-labeling Lambda } } ``` カスタムテンプレートとその収集データは複雑な特性を持つ可能性があるため、Ground Truth ではデータの詳細な処理は行いません。 # Ground Truth AWS Lambda で使用するために必要なアクセス許可を追加する Ground Truth で AWS Lambda を作成および使用するには、次の一部またはすべてを設定する必要があります。 + を使用して注釈前および注釈後の Lambda 関数を作成し AWS Lambda、ラベル付けジョブの作成時にそれらを選択するためのアクセス許可を IAM ロールまたはユーザー (総称して IAM エンティティ) に付与する必要があります。 + ラベル付けジョブが設定されたときに指定された IAM 実行ロールには、注釈前と注釈後の Lambda 関数を呼び出すためのアクセス許可が必要です。 + 注釈後の Lambda 関数では、Amazon S3 にアクセスするためのアクセス許可が必要な場合があります。 以下のセクションでは、IAM エンティティを作成し、前述したアクセス許可を付与する方法について学習します。 **Topics** + [AWS Lambda 関数を作成および選択するアクセス許可を付与する](#sms-custom-templates-step3-postlambda-create-perms) + [AWS Lambda 関数を呼び出すアクセス許可を IAM 実行ロールに付与する](#sms-custom-templates-step3-postlambda-execution-role-perms) + [注釈にアクセスするための注釈後の Lambda アクセス許可を付与する](#sms-custom-templates-step3-postlambda-perms) ## AWS Lambda 関数を作成および選択するアクセス許可を付与する 注釈前および注釈後の Lambda 関数を開発するために詳細なアクセス許可を必要としない場合は、 AWS 管理ポリシーをユーザーまたはロール`AWSLambda_FullAccess`にアタッチできます。このポリシーは、すべての Lambda 機能を使用するための広範なアクセス許可と、Lambda がやり取りする他の AWS サービスでアクションを実行するためのアクセス許可を付与します。 セキュリティに敏感なユースケースのより詳細なポリシーを作成するには、「 AWS Lambda デベロッパーガイド」の[「Lambda のアイデンティティベースの](https://docs.aws.amazon.com/lambda/latest/dg/access-control-identity-based.html) IAM ポリシー」のドキュメントを参照して、ユースケースに合った IAM ポリシーを作成する方法を確認してください。 **Lambda コンソールを使用するポリシー** Lambda コンソールを使用するアクセス許可を IAM エンティティに付与する場合は、「 AWS Lambda デベロッパーガイド」の[「Lambda コンソールの使用](https://docs.aws.amazon.com/lambda/latest/dg/security_iam_id-based-policy-examples.html#security_iam_id-based-policy-examples-console)」を参照してください。 さらに、ユーザーが AWS Serverless Application Repository Lambda コンソールの を使用して Ground Truth スターターの注釈前および注釈後の関数にアクセスしてデプロイできるようにするには、関数をデプロイ*``*する を指定し (ラベル付けジョブの作成に使用した AWS リージョンと同じである必要があります）、次のポリシーを IAM ロールに追加する必要があります。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "serverlessrepo:ListApplicationVersions", "serverlessrepo:GetApplication", "serverlessrepo:CreateCloudFormationTemplate" ], "Resource": "arn:aws:serverlessrepo:us-east-1:838997950401:applications/aws-sagemaker-ground-truth-recipe" }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": "serverlessrepo:SearchApplications", "Resource": "*" } ] } ``` ------ **Ground Truth コンソールで Lambda 関数を表示するためのポリシー** ユーザーがカスタムラベル付けジョブを作成しているときに、IAM エンティティに Ground Truth コンソールで Lambda 関数を表示するためのアクセス許可を付与するには、エンティティには、「[Amazon SageMaker Ground Truth コンソールを使用するための IAM アクセス許可を付与する](sms-security-permission-console-access.md)」で説明されているアクセス許可が必要です。これには、「[カスタムラベル付けワークフローのアクセス許可](sms-security-permission-console-access.md#sms-security-permissions-custom-workflow)」セクションで説明されているアクセス許可を含みます。 ## AWS Lambda 関数を呼び出すアクセス許可を IAM 実行ロールに付与する IAM 管理ポリシー [AmazonSageMakerGroundTruthExecution](https://console.aws.amazon.com/iam/home?#/policies/arn:aws:iam::aws:policy/AmazonSageMakerGroundTruthExecution) をラベル付けジョブの作成に使用される IAM 実行ロールに追加すると、このロールには、関数名に次の文字列のいずれかを含む Lambda 関数を一覧表示して呼び出すアクセス許可があります: `GtRecipe`、`SageMaker`、`Sagemaker`、`sagemaker`、または`LabelingFunction`。 注釈前または注釈後の Lambda 関数名に前の段落の用語のいずれかが含まれていない場合、または `AmazonSageMakerGroundTruthExecution` 管理ポリシーの用語よりも詳細なアクセス許可が必要な場合は、次のようなポリシーを追加して、注釈前と注釈後関数を呼び出すための実行ロールアクセス許可を追加できます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "lambda:InvokeFunction", "Resource": [ "arn:aws:lambda:us-east-1:111122223333:function:", "arn:aws:lambda:us-east-1:111122223333:function:" ] } ] } ``` ------ ## 注釈にアクセスするための注釈後の Lambda アクセス許可を付与する [後注釈 Lambda](sms-custom-templates-step3-lambda-requirements.md#sms-custom-templates-step3-postlambda) で説明したように、注釈後 Lambda リクエストには、Amazon S3 内の注釈データの場所が含まれます。この場所は、`payload` オブジェクトの `s3Uri` 文字列で特定されます。注釈を取り込みながら処理するには、シンプルなパススルー関数の場合でも、注釈後の [Lambda 実行ロール](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)に必要なアクセス許可を割り当てて、Amazon S3 からファイルを読み取る必要があります。 Lambda を設定し、Amazon S3 の注釈データにアクセスするにはいくつかの方法があります。2 つの一般的な方法は次のとおりです。 + Lambda 実行ロールが、注釈後 Lambda リクエストの `roleArn` で特定された SageMaker AI 実行ロールを引き受けることを許可します。この SageMaker AI 実行ロールは、ラベル付けジョブの作成に使用されるロールで、注釈データが格納されている Amazon S3 出力バケットにアクセスできます。 + Lambda 実行ロールに、Amazon S3 出力バケットに直接アクセスするためのアクセス許可を付与します。 次のセクションでは、これらのオプションを設定する方法について説明します。 **SageMaker AI 実行ロールを引き受けるためのLambda 権限を付与する** Lambda 関数が SageMaker AI 実行ロールを引き受けるようにするには、Lambda 関数の実行ロールにポリシーをアタッチし、SageMaker AI 実行ロールの信頼関係を変更して、Lambda がそれを引き受けられるようにする必要があります。 1. Lambda 関数の実行ロールに[次の IAM ポリシーをアタッチ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)し、`Resource` で特定された SageMaker AI 実行ロールを引き受けます。`222222222222` を [AWS アカウント ID](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html) に置き換えます。`sm-execution-role` を引き受けるロールの名前に置き換えます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::222222222222:role/sm-execution-role" } } ``` ------ 1. SageMaker AI 実行ロールの[信頼ポリシーを変更](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-managingrole_edit-trust-policy)し、以下の `Statement` を含めます。`222222222222` を [AWS アカウント ID](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html) に置き換えます。`my-lambda-execution-role` を引き受けるロールの名前に置き換えます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::222222222222:role/my-lambda-execution-role" }, "Action": "sts:AssumeRole" } ] } ``` ------ **S3 へのアクセス権限を Lambda 実行ロールに付与する** 次のようなポリシーを注釈後の Lambda 関数の実行ロールに追加して、S3 読み取り権限を付与できます。*amzn-s3-demo-bucket* を、ラベル付けジョブの作成時に指定した出力バケットの名前に置き換えます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*" } ] } ``` ------ Lambda コンソールで Lambda 実行ロールに S3 読み取りアクセス許可を追加するには、以下の手順を使用します。 **S3 読み取りアクセス許可を注釈後 Lambda に追加するには以下の手順に従います。** 1. Lambda コンソールの [**[Functions]** (関数) ページ](https://console.aws.amazon.com/lambda/home#/functions)を開きます。 1. 注釈後関数の名前を選択します。 1. **[設定]** を選択して、**[アクセス許可]** を選択します。 1. **[Role name]** (ロール名) を選択すると、IAM コンソールで新しいタブにそのロールの概要ページが開きます。 1. **[Attach policies]** (ポリシーをアタッチ) を選択します。 1. 次のいずれかを行います。 + **`AmazonS3ReadOnlyAccess`** を検索して選択し、アカウント内のすべてのバケットとオブジェクトを読み取るアクセス許可を関数に付与します。 + より詳細なアクセス許可が必要な場合は、**[Create policy]** (ポリシーの作成) をクリックし、前のセクションのポリシー例を使用してポリシーを作成します。ポリシーを作成したら、実行ロールの概要ページに戻る必要があります。 1. `AmazonS3ReadOnlyAccess` 管理ポリシーを使用した場合は、**[Attach policy]** (ポリシーのアタッチ)を選択します。 新しいポリシーを作成した場合は、Lambda 実行ロールの概要ページに戻り、作成したポリシーをアタッチします。 # Ground Truth テンプレートを使用して Lambda 関数を作成する Lambda 関数は、Lambda コンソール、、または AWS SDK を使用して AWS CLI、任意のサポートされているプログラミング言語で作成できます。以下の各オプションの詳細については、 AWS Lambda デベロッパーガイドを参照してください。 + コンソールを使用して Lambda 関数を作成する方法については、「[コンソールで Lambda 関数を作成する](https://docs.aws.amazon.com/lambda/latest/dg/getting-started-create-function.html)」を参照してください。 + を使用して Lambda 関数を作成する方法については AWS CLI、[「 コマンドラインインターフェイスでの AWS Lambda AWS の使用](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-awscli.html)」を参照してください。 + 任意の言語で Lambda を使用する方法についての詳細は、目次の該当するセクションを選択して参照してください。例えば、 AWS SDK for Python (Boto3)で Lambda を使用する場合は、[[Working with Python]](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html) (Python を使用する) を選択します。 Ground Truth は AWS Serverless Application Repository 、(SAR) *レシピ*を通じて注釈前および注釈後のテンプレートを提供します。以下の手順を使用して、Lambda コンソールでGround Truth レシピを選択します。 **Ground Truth SAR レシピを使用して、注釈前と注釈後の Lambda 関数を作成します。** 1. Lambda コンソールの [**[Functions]** (関数) ページ](https://console.aws.amazon.com/lambda/home#/functions)を開きます。 1. **[Create Function]** (関数を作成) を選択します。 1. **[Browse serverless app repository]** (Serverless Application Repository の参照) を選択します。 1. 検索ボックスに、**aws-sagemaker-ground-truth-recipe** と入力してそのアプリを選択します。 1. **[Deploy]** (デプロイ) を選択します。アプリのデプロイには数分かかることがあります。 アプリがデプロイされると、2 つの関数、`serverlessrepo-aws-sagema-GtRecipePreHumanTaskFunc-` と `serverlessrepo-aws-sagema-GtRecipeAnnotationConsol-` がLambda コンソールの **[Functions]** (関数) セクションに表示されます。 1. これらの関数のいずれかを選択し、カスタムロジックを**[Code]** (コード) セクションに追加します。 1. 変更が完了したら、**[Deploy]** (デプロイ) を選択し、デプロイします。 # 前注釈と後注釈の Lambda 関数をテストする Lambda コンソールで、注釈前と注釈後の Lambda 関数をテストできます。Lambda を初めて使用する場合は、 AWS Lambda デベロッパーガイドのコンソールで *Lambda 関数を作成する*のチュートリアルを使用し、Lambda 関数をコンソールでテストまたは[呼び出す](https://docs.aws.amazon.com/lambda/latest/dg/getting-started-create-function.html#gettingstarted-zip-function)方法を学習できます。このページのセクションを使用して、 AWS Serverless Application Repository (SAR) を通じて提供される Ground Truth 注釈前テンプレートと注釈後テンプレートをテストする方法について説明します。 **Topics** + [前提条件](#sms-custom-templates-step3-lambda-test-pre) + [注釈前 Lambda 関数をテストする](#sms-custom-templates-step3-lambda-test-pre-annotation) + [注釈後 Lambda 関数をテストする](#sms-custom-templates-step3-lambda-test-post-annotation) ## 前提条件 このページで説明されているテストを使用するには、次の操作を行う必要があります。 + Lambda コンソールへのアクセスと、Lambda 関数を作成して呼び出すためのアクセス許可が必要です。これらのアクセス許可の設定方法については、「[AWS Lambda 関数を作成および選択するアクセス許可を付与する](sms-custom-templates-step3-lambda-permissions.md#sms-custom-templates-step3-postlambda-create-perms)」を参照してください。 + Ground Truth SAR レシピをデプロイしていない場合は、「[Ground Truth テンプレートを使用して Lambda 関数を作成する](sms-custom-templates-step3-lambda-create.md)」の手順を使用してデプロイします。 + 注釈後の Lambda 関数をテストするには、Amazon S3 にサンプル注釈データを含むデータファイルが必要です。簡単なテストでは、次のコードをコピーしてファイルに貼り付け、`sample-annotations.json` として保存し、[このファイルを Amazon S3 にアップロード](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html)します。このファイルの S3 URI を記録しておきます。注釈後の Lambda テストを設定する際にこの情報が必要です。 ``` [{"datasetObjectId":"0","dataObject":{"content":"To train a machine learning model, you need a large, high-quality, labeled dataset. Ground Truth helps you build high-quality training datasets for your machine learning models."},"annotations":[{"workerId":"private.us-west-2.0123456789","annotationData":{"content":"{\"crowd-entity-annotation\":{\"entities\":[{\"endOffset\":8,\"label\":\"verb\",\"startOffset\":3},{\"endOffset\":27,\"label\":\"adjective\",\"startOffset\":11},{\"endOffset\":33,\"label\":\"object\",\"startOffset\":28},{\"endOffset\":51,\"label\":\"adjective\",\"startOffset\":46},{\"endOffset\":65,\"label\":\"adjective\",\"startOffset\":53},{\"endOffset\":74,\"label\":\"adjective\",\"startOffset\":67},{\"endOffset\":82,\"label\":\"adjective\",\"startOffset\":75},{\"endOffset\":102,\"label\":\"verb\",\"startOffset\":97},{\"endOffset\":112,\"label\":\"verb\",\"startOffset\":107},{\"endOffset\":125,\"label\":\"adjective\",\"startOffset\":113},{\"endOffset\":134,\"label\":\"adjective\",\"startOffset\":126},{\"endOffset\":143,\"label\":\"object\",\"startOffset\":135},{\"endOffset\":169,\"label\":\"adjective\",\"startOffset\":153},{\"endOffset\":176,\"label\":\"object\",\"startOffset\":170}]}}"}}]},{"datasetObjectId":"1","dataObject":{"content":"Sift 3 cups of flour into the bowl."},"annotations":[{"workerId":"private.us-west-2.0123456789","annotationData":{"content":"{\"crowd-entity-annotation\":{\"entities\":[{\"endOffset\":4,\"label\":\"verb\",\"startOffset\":0},{\"endOffset\":6,\"label\":\"number\",\"startOffset\":5},{\"endOffset\":20,\"label\":\"object\",\"startOffset\":15},{\"endOffset\":34,\"label\":\"object\",\"startOffset\":30}]}}"}}]},{"datasetObjectId":"2","dataObject":{"content":"Jen purchased 10 shares of the stock on Janurary 1st, 2020."},"annotations":[{"workerId":"private.us-west-2.0123456789","annotationData":{"content":"{\"crowd-entity-annotation\":{\"entities\":[{\"endOffset\":3,\"label\":\"person\",\"startOffset\":0},{\"endOffset\":13,\"label\":\"verb\",\"startOffset\":4},{\"endOffset\":16,\"label\":\"number\",\"startOffset\":14},{\"endOffset\":58,\"label\":\"date\",\"startOffset\":40}]}}"}}]},{"datasetObjectId":"3","dataObject":{"content":"The narrative was interesting, however the character development was weak."},"annotations":[{"workerId":"private.us-west-2.0123456789","annotationData":{"content":"{\"crowd-entity-annotation\":{\"entities\":[{\"endOffset\":29,\"label\":\"adjective\",\"startOffset\":18},{\"endOffset\":73,\"label\":\"adjective\",\"startOffset\":69}]}}"}}]}] ``` + [注釈にアクセスするための注釈後の Lambda アクセス許可を付与する](sms-custom-templates-step3-lambda-permissions.md#sms-custom-templates-step3-postlambda-perms) の指示を使用して、注釈後 Lambda 関数の実行ロールに、ラベル付けジョブの作成に使用する SageMaker AI 実行ロールを引き受けるためのアクセス許可を付与する必要があります。注釈後 Lambda 関数は、SageMaker AI 実行ロールを使用して注釈データファイル、S3 にある `sample-annotations.json` にアクセスします。 ## 注釈前 Lambda 関数をテストする Ground Truth AWS Serverless Application Repository (SAR) レシピをデプロイしたときに作成された注釈前 Lambda 関数をテストするには、次の手順に従います。 **Ground Truth SAR レシピの注釈前 Lambda 関数をテストする** 1. Lambda コンソールの [**[Functions]** (関数) ページ](https://console.aws.amazon.com/lambda/home#/functions)を開きます。 1. Ground Truth SAR レシピからデプロイされた注釈前関数を選択します。この関数の名前は、`serverlessrepo-aws-sagema-GtRecipePreHumanTaskFunc-` と同様の名前になります。 1. **[Code source]** (コードソース) セクションで、**[Test]** (テスト) の横にある矢印を選択します。 1. **[Configure test event]** (テストイベントを構成する) を選択します。 1. **[Create new test event]** (新しいテストイベントの作成) オプションを選択したままにします。 1. **[Event template]** (イベントテンプレート) で、**[SageMaker Ground Truth PreHumanTask]** を選択します。 1. テストに**イベント名**を付けます。 1. **[作成]** を選択します。 1. 再度 **Test** (テスト) の横にある矢印を選択すると、作成したテストが選択されて表示されます。これはイベント名のドットで識別できます。選択されていない場合は、選択します。 1. **[Test]** (テスト) を選択して、テストを実行します。 テストを実行した後、**[Execution results]** (実行結果) を表示できます。**[Function logs]** (関数ログ) に、次のような応答が表示されます。 ``` START RequestId: cd117d38-8365-4e1a-bffb-0dcd631a878f Version: $LATEST Received event: { "version": "2018-10-16", "labelingJobArn": "arn:aws:sagemaker:us-east-2:123456789012:labeling-job/example-job", "dataObject": { "source-ref": "s3://sagemakerexample/object_to_annotate.jpg" } } {'taskInput': {'taskObject': 's3://sagemakerexample/object_to_annotate.jpg'}, 'isHumanAnnotationRequired': 'true'} END RequestId: cd117d38-8365-4e1a-bffb-0dcd631a878f REPORT RequestId: cd117d38-8365-4e1a-bffb-0dcd631a878f Duration: 0.42 ms Billed Duration: 1 ms Memory Size: 128 MB Max Memory Used: 43 MB ``` この応答では、Lambda 関数の出力が必須の注釈前応答構文と一致していることがわかります。 ``` {'taskInput': {'taskObject': 's3://sagemakerexample/object_to_annotate.jpg'}, 'isHumanAnnotationRequired': 'true'} ``` ## 注釈後 Lambda 関数をテストする Ground Truth AWS Serverless Application Repository (SAR) レシピをデプロイしたときに作成された注釈後の Lambda 関数をテストするには、次の手順に従います。 **Ground Truth SAR レシピ注釈後の Lambda 関数をテストする** 1. Lambda コンソールの [**[Functions]** (関数) ページ](https://console.aws.amazon.com/lambda/home#/functions)を開きます。 1. Ground Truth SAR レシピからデプロイされた注釈後関数を選択します。この関数の名前は、`serverlessrepo-aws-sagema-GtRecipeAnnotationConsol-` と同様の名前になります。 1. **[Code source]** (コードソース) セクションで、**[Test]** (テスト) の横にある矢印を選択します。 1. **[Configure test event]** (テストイベントを構成する) を選択します。 1. **[Create new test event]** (新しいテストイベントの作成) オプションを選択したままにします。 1. **[Event template]** (イベントテンプレート)で、**[SageMaker Ground Truth AnnotationConsolidation]** を選択します。 1. テストに**イベント名**を付けます。 1. 指定されたテンプレートコードを次のように変更します。 + `roleArn` の Amazon リソースネーム (ARN) を、ラベル付けジョブの作成に使用した SageMaker AI 実行ロールの ARN に置き換えます。 + `s3Uri` の S3 URI を、Amazon S3 に追加した `sample-annotations.json` ファイルの URIに置き換えます。 これらの変更を行った後、テストは次のようになります。 ``` { "version": "2018-10-16", "labelingJobArn": "arn:aws:sagemaker:us-east-2:123456789012:labeling-job/example-job", "labelAttributeName": "example-attribute", "roleArn": "arn:aws:iam::222222222222:role/sm-execution-role", "payload": { "s3Uri": "s3://your-bucket/sample-annotations.json" } } ``` 1. **[作成]** を選択します。 1. 再度 **Test** (テスト) の横にある矢印を選択すると、作成したテストが選択されて表示されます。これはイベント名のドットで識別できます。選択されていない場合は、選択します。 1. **[Test]** (テスト) を選択して、テストを実行します。 テストの実行後、**[Function Logs]** (関数ログ) に「`-- Consolidated Output --`」セクションが表示されます。これには、`sample-annotations.json` に含まれるすべての注釈のリストが掲載されています。 # デモテンプレート: `crowd-bounding-box` を使用したイメージの注釈 Amazon SageMaker Ground Truth コンソールでタスクタイプとしてカスタムテンプレートを使用することを選択した場合は、**[Custom labeling task panel]** (カスタムラベル付けタスクパネル) が表示されます。そこで、複数の基本テンプレートから選択することができます。テンプレートは最も一般的なタスクを表しており、カスタマイズしたラベル付けタスクのテンプレートを作成するときに役立つサンプルを提供します。コンソールを使用していない場合や、追加の情報が必要な場合、さまざまなラベル付けジョブタスクタイプのデモテンプレートのリポジトリについては、「[Amazon SageMaker AI Ground Truth Sample Task UIs](https://github.com/aws-samples/amazon-sagemaker-ground-truth-task-uis)」を参照してください。 このデモは、**[BoundingBox]** テンプレートを使用して行います。このデモンストレーションは、タスクの前後にデータを処理するために必要な AWS Lambda 関数でも機能します。上記の Github リポジトリで、 AWS Lambda 関数と連携するテンプレートを検索するには、テンプレート`{{ task.input. }}`で を探します。 **Topics** + [スターターの境界ボックスカスタムテンプレート](#sms-custom-templates-step2-demo1-base-template) + [独自の境界ボックスカスタムテンプレート](#sms-custom-templates-step2-demo1-your-own-template) + [マニフェストファイル](#sms-custom-templates-step2-demo1-manifest) + [前注釈の Lambda 関数](#sms-custom-templates-step2-demo1-pre-annotation) + [後注釈 Lambda 関数](#sms-custom-templates-step2-demo1-post-annotation) + [ラベル付けジョブの出力](#sms-custom-templates-step2-demo1-job-output) ## スターターの境界ボックスカスタムテンプレート 以下が、スターターの境界ボックステンプレートです。 ```

Use the bounding box tool to draw boxes around the requested target of interest:

  1. Draw a rectangle using your mouse over each instance of the target.
  2. Make sure the box does not cut into the target, leave a 2 - 3 pixel margin
  3. When targets are overlapping, draw a box around each object, include all contiguous parts of the target in the box. Do not include parts that are completely overlapped by another object.
  4. Do not include parts of the target that cannot be seen, even though you think you can interpolate the whole shape of the target.
  5. Avoid shadows, they're not considered as a part of the target.
  6. If the target goes off the screen, label up to the edge of the image.
 Use the bounding box tool to draw boxes around the requested target of interest. ``` カスタムテンプレートでは [Liquid テンプレート言語](https://shopify.github.io/liquid/)を使用します。二重波括弧で囲まれたそれぞれの項目は 1 つの変数です。注釈前 AWS Lambda 関数は という名前のオブジェクトを提供する必要があり`taskInput`、そのオブジェクトのプロパティにはテンプレート`{{ task.input. }}`の としてアクセスできます。 ## 独自の境界ボックスカスタムテンプレート 例として、動物の写真が多数あり、以前のイメージ分類ジョブによって、イメージ内の動物の種類を知っているとします。境界ボックスを設定しているとします。 スターターサンプルには、3 つの変数 `taskObject`、`header`、および `labels` があります。 各変数は、境界ボックスのさまざまな部分で示されることになります。 + `taskObject` は、注釈を付ける写真の HTTP(S) URL または S3 URI です。追加された `| grant_read_access` はフィルターで、S3 URI を、そのリソースに対するアクセス存続期間が短い HTTPS URL に変換します。HTTP(S) URL を使用している場合、これは必要ありません。 + `header` は写真の上にあるテキストで、"Draw a box around the bird in the photo" のようにラベル付けされます。 + `labels` は配列で `['item1', 'item2', ...]` のように表されます。これらはワーカーが、描画するさまざまなボックスに対して割り当てることができるラベルです。1 つまたは複数持つことができます。 それぞれの変数名は、前注釈 Lambda からのレスポンスの JSON オブジェクトから取得されます。上記の名前は提案にすぎないため、わかりやすい変数名を使用してください。それによって、チームでのコードの読みやすさが向上します。 **必要時のみ変数を使用する** フィールドが変わらない場合、テンプレートからその変数を削除してそのテキストに置き換えることができます。それ以外の場合は、マニフェストの各オブジェクトにおいてそのテキストを値として繰り返すか、前注釈の Lambda 関数にコーディングする必要があります。 **Example : 最終的なカスタム境界ボックステンプレート** このテンプレートは、シンプルにするために、1 つの変数、1 つのラベル、および非常に基本的な手順を使用します。マニフェストの各データオブジェクトに "animal" プロパティがあるとして、その値はテンプレートの 2 つの部分で再利用できます。 ```

Draw a bounding box around the {{ task.input.animal }} in the image. If there is more than one {{ task.input.animal }} per image, draw a bounding box around the largest one.

The box should be tight around the {{ task.input.animal }} with no more than a couple of pixels of buffer around the edges.

If the image does not contain a {{ task.input.animal }}, check the Nothing to label box.

Draw a bounding box around the {{ task.input.animal }} in each image. If there is more than one {{ task.input.animal }} per image, draw a bounding box around the largest one.

 ``` テンプレート全体で `{{ task.input.animal }}` を再利用します。マニフェストに大文字で始まる動物名がすべて含まれている場合は、`{{ task.input.animal | downcase }}` を使用して、Liquid の組み込みフィルターのいずれかを小文字で表示する必要がある文に組み込むことができます。 ## マニフェストファイル マニフェストファイルは、テンプレートで使用している変数値に合わせる必要があります。前注釈 Lambda でマニフェストデータをある程度変換できますが、変換が不要であれば、エラーの発生するリスクはより低いままで Lambda の実行速度は速くなります。テンプレートのマニフェストファイルの例を次に示します。 ``` {"source-ref": "", "animal": "horse"} {"source-ref": "", "animal" : "bird"} {"source-ref": "", "animal" : "dog"} {"source-ref": "", "animal" : "cat"} ``` ## 前注釈の Lambda 関数 ジョブのセットアップの一環として、マニフェストエントリを処理してテンプレートエンジンに渡すために呼び出すことができる AWS Lambda 関数の ARN を指定します。 **Lambda 関数に名前を付ける** 関数に名前を付ける場合のベストプラクティスとして、`SageMaker`、`Sagemaker`、`sagemaker`、または `LabelingFunction` の 4 つの文字列のいずれかを関数名の一部として使用します。これは、注釈前と注釈後の両方の関数に適用されます。 コンソールを使用している場合、アカウントが所有する AWS Lambda 関数がある場合、命名要件を満たす関数のドロップダウンリストが表示され、いずれかを選択できます。 この非常に基本的な例では、追加の処理を行わずにマニフェストからの情報をそのままパススルーしています。このサンプルの前注釈関数は Python 3.7 用に書かれています。 ``` import json def lambda_handler(event, context): return { "taskInput": event['dataObject'] } ``` マニフェストからの JSON オブジェクトは、`event` オブジェクトの子として提供されます。`taskInput` オブジェクト内のプロパティはテンプレートの変数として使用できるため、`taskInput` の値を `event['dataObject']` に設定するだけで、マニフェストオブジェクトからテンプレートにすべての値が個別にコピーされることなく渡されます。テンプレートにさらに値を送信する場合は、それらを `taskInput` オブジェクトに追加できます。 ## 後注釈 Lambda 関数 ジョブのセットアップの一環として、ワーカーがタスクを完了したときにフォームデータを処理するために呼び出すことができる AWS Lambda 関数の ARN を指定します。これは、必要なだけシンプルにすることも複雑にすることもできます。取り込みながら統合とスコアに対応する場合は、選択したスコアアルゴリズムや統合アルゴリズムを適用できます。raw データを保存してオフライン処理する場合、これはオプションです。 **後注釈 Lambda にアクセス許可を付与する** 注釈データは、`payload` オブジェクトの `s3Uri` 文字列で指定されたファイルにあります。注釈を取り込みながら処理するには、シンプルなパススルー関数の場合でも、注釈ファイルを読み取ることができるように、Lambda に対して `S3ReadOnly` アクセス権を割り当てる必要があります。 Lambda を作成するためのコンソールページで **[Execution role]** (実行ロール) パネルまでスクロールします。**[Create a new role from one or more templates]** (1 つ以上のテンプレートから新しいロールを作成します)を選択します。ロールに名前を付けます。**[ポリシーテンプレート]** ドロップダウンから **[Amazon S3 object read-only permissions]** (Amazon S3 オブジェクトの読み取り専用アクセス権限) を選択します。Lambda を保存すると、ロールが保存されて選択されます。 Python 2.7 での例を次に示します。 ``` import json import boto3 from urlparse import urlparse def lambda_handler(event, context): consolidated_labels = [] parsed_url = urlparse(event['payload']['s3Uri']); s3 = boto3.client('s3') textFile = s3.get_object(Bucket = parsed_url.netloc, Key = parsed_url.path[1:]) filecont = textFile['Body'].read() annotations = json.loads(filecont); for dataset in annotations: for annotation in dataset['annotations']: new_annotation = json.loads(annotation['annotationData']['content']) label = { 'datasetObjectId': dataset['datasetObjectId'], 'consolidatedAnnotation' : { 'content': { event['labelAttributeName']: { 'workerId': annotation['workerId'], 'boxesInfo': new_annotation, 'imageSource': dataset['dataObject'] } } } } consolidated_labels.append(label) return consolidated_labels ``` 後注釈 Lambda は、イベントオブジェクトでタスク結果のバッチを受信することがよくあります。このバッチは、Lambda が繰り返す必要のある `payload` オブジェクトになります。返すものは [API 規約](sms-custom-templates-step3.md)を満たしているオブジェクトです。 ## ラベル付けジョブの出力 ジョブの出力は、指定したターゲット S3 バケットの、ラベル付けジョブの名前から命名されたフォルダにあります。`manifests` というサブフォルダにあります。 境界ボックスタスクの場合、出力マニフェストにある出力は、以下のデモのようになります。この例は、出力のためにクリーンアップされました。実際には、レコードごとに 1 行が出力されます。 **Example : 出力マニフェストの JSON** ``` { "source-ref":"", "