翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 基本的な取り込みによるメッセージングコストの削減
<a name="iot-basic-ingest"></a>

基本的な取り込みを使用して、安全に [メッセージングコスト](https://aws.amazon.com/iot-core/pricing/)を発生させることなく、[AWS IoT ルールアクション](iot-rule-actions.md) でサポートされる AWS のサービス にデバイスデータを送信できます。基本的な取り込みでは、取り込みパスからパブリッシュ/サブスクライブのメッセージブローカーを除外することによってデータフローが最適化されます。

基本的な取り込みでは、デバイスまたはアプリケーションからメッセージを送信できます。メッセージには、最初の 3 つのレベルに `$aws/rules/rule_name` で始まるトピック名があり、ここで `rule_name` は呼び出す AWS IoT ルールの名前です。

基本的な取り込みのプレフィックス (`$aws/rules/rule_name`) を、ルールを呼び出すために使用するメッセージのトピックに追加するだけで、既存のルールを基本的な取り込みで使用することができます。例えば、`Buildings/Building5/Floor2/Room201/Lights` (`"sql": "SELECT * FROM 'Buildings/#'"`) などのトピックでメッセージによって呼び出される `BuildingManager` という名前のルールがある場合、トピック `$aws/rules/BuildingManager/Buildings/Building5/Floor2/Room201/Lights` でメッセージを送信することで、基本的な取り込みで同じルールを呼び出せます。

**注記**  
デバイスとルールでは、基本的な取り込みの予約されたトピックをサブスクライブできません。例えば、AWS IoT Device Defender メトリクスの `num-messages-received` メトリクスはトピックのサブスクライブをサポートしていないため、出力されません。詳細については、「[予約済みトピック](reserved-topics.md)」を参照してください。
パブリッシュ/サブスクライブブローカーで複数の受信対象にメッセージを配信することが必要な場合 (たとえば、他のデバイスとルールエンジンにメッセージを配信する場合)、AWS IoT メッセージブローカーを引き続き使用してメッセージ配信を処理する必要があります。しかし、基本的な取り込みトピック以外のトピックにメッセージを公開するようにしてください。

## 基本的な取り込みの使用
<a name="iot-basic-ingest-use"></a>

基本的な取り込みを使用する前に、デバイスまたはアプリケーションが、`$aws/rules/*` に対する発行アクセス許可を持つ[ポリシー](iot-policies.md)を使用していることを確認してください。または、ポリシーに `$aws/rules/rule_name/*` で個別ルールに対するアクセス許可を指定できます。それ以外の場合は、デバイスとアプリケーションは AWS IoT Core に対して既存の接続を引き続き使用できます。

メッセージがルールエンジンに到達すると、基本的な取り込みから呼び出されたルールと、メッセージブローカーサブスクリプションを通じて呼び出されたルールによる実装またはエラー処理に違いはありません。

基本的な取り込みで使用するためのルールを作成できます。以下に留意してください。
+ 基本的な取り込みトピックの最初のプレフィックス (`$aws/rules/rule_name`) は [topic(10 進数)](iot-sql-functions.md#iot-function-topic) 関数には使用できません。
+ 基本的な取り込みでのみ呼び出されるルールを定義する場合、`FROM` 句は `rule` 定義の `sql` フィールドのオプションです。これは、メッセージブローカーを使用してメッセージを送信する必要がある他のメッセージによりルールが呼び出される場合でも (例えば、他のメッセージが複数の受信対象に配信される必要があるため) 必要になります。詳細については、「[AWS IoT SQL リファレンス](iot-sql-reference.md)」を参照してください。
+ 基本的な取り込みトピックの最初の 3 つのレベル (`$aws/rules/rule_name`) はトピックの 8 つのセグメント長制限または 256 文字の文字数制限にカウントされません。それ以外の場合は、「[AWS IoT の制限](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#limits_iot)」で説明されているように、同じ制限が適用されます。
+ 無効なルールまたは存在しないルールを指定する基本的な取り込みトピックでメッセージが受信された場合は、エラーログは Amazon CloudWatch ログに作成され、デバッグに利用できます。詳細については、「」を参照してください[ルールエンジンのログエントリ](cwl-format.md#rule-engine-logs) `RuleNotFound` メトリクスが表示され、このメトリクスでアラームを作成できます。詳細については、「[ルールのメトリクス](metrics_dimensions.md#rulemetrics)」の「ルールメトリクス」を参照してください。
+ この場合でも、基本的な取り込みトピックに QoS 1 で発行できます。メッセージがルールエンジンに正常に配信された後、PUBACK を受信します。PUBACK の受信はルールのアクションが正常に完了したことを意味するわけではありません。エラーアクションを設定して、アクションの実行中にエラーを処理することができます。詳細については、「」を参照してください[エラー処理 (エラーアクション)](rule-error-handling.md)