AIでDynamoDBをクエリする方法(自然言語)

「先週の失敗した注文を見せて」は、頭の中では一行ですが、ワイヤ上ではプレースホルダーマップ付きのKeyConditionExpressionです。そのギャップを埋めることこそが「AIでDynamoDBをクエリする」の実際の意味です — なぜならDynamoDBのAPI自体には自然言語のエンドポイントが存在しないからです。すべてのリクエストは依然として式かであり、AIはツーリングの層に座って、あなたの意図をそれらに翻訳します。

その翻訳は、たった1つのことによって、本当に素晴らしいものにも、静かに危険なものにもなります:モデルがあなたの実際のスキーマを見られるかどうかです。このガイドでは、実際に機能する3つの構成と、それぞれがどこで破綻するかを扱います。

自然言語でDynamoDBをクエリするには？

現実的な選択肢は3つです:汎用のLLMにPartiQLを下書きさせて自分で実行する(速いが、モデルは属性名を推測しているだけ)、MCPサーバー経由でAIエージェントをDynamoDBに接続して本当に調査・クエリできるようにする、あるいはスキーマ認識アシスタントを組み込んだDynamoDBクライアントを使う — DynoTableのAIチャットは、自然言語を実際にインデックスされたスキーマに対するPartiQLまたはSQLに変換し、テーブル全体の正確な集計を計算し、あらゆる書き込みをレビューのためにステージします。

選択肢1:LLMが下書きしたPartiQLを自分で実行する

セットアップ不要のバージョン:能力のあるモデルにクエリを説明し、PartiQLを受け取り、コンソールのPartiQLエディタかCLIで実行します:

aws dynamodb execute-statement \
  --statement "SELECT * FROM \"Orders\" WHERE PK = 'ORDER#1001'"

これは機能します — そして、予測可能な3つのパターンで失敗します:

モデルはあなたのテーブルを見られません。 属性名やキーの形を自信満々にでっち上げます(あなたのテーブルがPK = ORDER#<id>なのにorderIdと書く)。クエリを書く代わりに、幻覚のスキーマをデバッグする羽目になります。
PartiQLの制限はそのまま適用されます。 SELECTはちょうど1つのテーブルを読み、キーを固定しないWHEREはテーブル全体のスキャンになります — 自分で書いた場合とまったく同じように、静かに高くつきます。モデルが警告してくれることはめったにありません。SQLの見た目が何をもたらし、何をもたらさないかはPartiQL vs SQLで説明しています。
スキーマやデータをチャットボットに貼り付けるのは、データガバナンス上の意思決定です。 プロンプト内のサンプルアイテムは、あなたの境界を離れていく本番データです。

記憶から貼り付けられるスキーマに対する単発のクエリには良いですが、ワークフローとしては心もとない方法です。

選択肢2:MCP経由で接続されたAIエージェント

「モデルがテーブルを見られない」問題の構造的な解決策は、プロンプトに貼り付けたスキーマの代わりに、エージェントにツールを与えることです。Model Context Protocol(MCP)はまさにそれを行います:MCPサーバーがDynamoDBの操作を型付きツールとして公開し、MCP対応のエージェント(Claude、IDEのアシスタント、カスタムエージェント)がテーブルを一覧し、キーを調査し、実際の結果を会話にフィードバックしながらクエリを実行できます。

完全なセットアップと、エージェントにデータベースを触らせることに伴う同意・スコープ・書き込み安全性の問題は、MCPサーバーでDynamoDBを使うで扱っています。DynoTable自体も1つ同梱しています:ゲート付きでループバック限定のツールを外部エージェントに公開でき、接続ごとの同意とスコープを備えています。

これは_エージェント_こそが製品であるとき — サポートボット、社内のSlackアシスタント — に正しいアーキテクチャです。日々のインタラクティブな作業では、エージェント、サーバー、認証情報を自分で組み立てる作業が残ります。

選択肢3:DynamoDBクライアントに組み込まれたスキーマ認識アシスタント

DynoTableの組み込みアシスタントは統合版です:テーブルのすぐ隣に住んでいて(⌘;)、あなたのインデックスされたスキーマ — アクティブなプロファイル配下のテーブル、そのキーとインデックス、テーブルのインデックス作成で発見された属性パスと型、さらにはサンプル値 — を読むので、「これを先週分にフィルタして」は推測ではなく、実際の属性名に対して解決されます。@を入力すれば@table、@column、@gsiを明示的に参照できます。

テーブルタブの横にドッキングされたDynoTableのAIチャット:自然言語の質問、生成されたクエリ、そしてビューとして開かれる結果。

質問に対して何をするかは、能力カタログのとおりです:

クエリを代わりに書きます — 読み取り専用のPartiQL、または質問がJOIN / GROUP BY / 集計(DynamoDBのAPIには存在しない分析機能)を必要とするときはWorkbench SQL — そして結果をチップとして提案し、クリックすると本物のタブとして開きます。
テーブル全体の正確な答えを計算します。 カウント、合計、平均、グループごとの内訳を頼むと、サンプリングした1ページではなく一致するすべてのアイテムを読み取ります — 「先月の注文はいくつ？」は実際のテーブルを反映します。同じパスを、変換済みのエクスポートファイルに整形し直すこともできます。
すべての書き込みをステージします。行の修正を頼むと、変更はレビュー可能な差分としてステージングエリアに置かれます — アシスタントはどの権限モードでも、DynamoDBに直接書き込むことも、テーブルを一括削除することも、テーブル構造を変更することもできません。レビューするのもコミットするのもあなたです。
あなたのお金を使う前に確認します。 AWSに到達しキャパシティを消費する読み取りは権限ゲートの対象で(プロファイルごとにManual / Auto / Full Auto)、ゲートされたすべての決定はローカルの常時有効な監査ログに記録されます。

信頼モデルは機能と同じくらい重要です:アシスタントはあなた自身のAWS Bedrock認証情報で動き、あなたのアカウント内のBedrockと直接通信します — プロンプト、スキーマ、テーブルデータがDynoTableのサーバーを経由することは決してなく、推論はBedrock自身のレートで上乗せなしにあなたに請求されます。ツールの結果は信頼できないデータとして扱われるため、「以前の指示を無視して」と書かれた行がエージェントを乗っ取ることはできません。

AIがDynamoDBについて変えないこと

誠実なAIレイヤーはすべて、データベースの物理法則を受け継ぎます:

アクセスパターンが依然として支配します。 キーでない属性に対する「where status = X」は、誰が書こうとフィルタ付きスキャンです — モデルは高価なクエリを速くタイプするだけです。ある質問が繰り返しスキャンを強いるなら、修正はモデリング(GSI、より良いソートキー)であって、より良いプロンプトではありません。
読み取りは実際のキャパシティを消費します。 テーブル全体の正確な集計は、テーブル全体の読み取りです。良いツールはそれをゲートし、そうと明言します。料金計算ツールは、承認する前にフルパスのコストを教えてくれます。
決定論には決定論の場所があります。 本番で永遠に実行するクエリなら、Expression Builderで式を一度手作りして、正確なnames/valuesマップを出荷してください — AIは探索のため、ビルダーはコミットするコードのためです。

FAQ

DynamoDBを平易な言葉でクエリできますか？ API自体に対しては無理です — DynamoDBは式とPartiQLしか話しません。しかしAIレイヤーが翻訳できます:PartiQLを下書きするLLM、MCP接続のエージェント、あるいはDynoTableのように実際のスキーマに対してクエリを生成・実行するスキーマ認識アシスタントです。

DynamoDBには組み込みのAIクエリ機能がありますか？ DynamoDBのAPIに自然言語のエンドポイントはありません。手に入るAIクエリはすべて、その上のツーリング層から来ます — だからこそ、そのツーリングの安全モデル(読み取りのゲート、ステージされた書き込み、自分の認証情報)こそが評価すべきものなのです。

本番データの近くにAIを置いても安全ですか？ それは権限の問題です。見るべきポイント:明示的な承認でゲートされた読み取り、直接実行される代わりにレビュー可能なステージングエリアに置かれる書き込み、監査ログ、そしてあなたが管理する認証情報での推論。DynoTableのアシスタントは4つすべてを満たします。データを貼り付けたチャットボットは1つも満たしません。

AIはテーブルをジョインしたりGROUP BYしたりできますか？ DynamoDBのAPI経由では無理です — そのためのエンジンが存在しません。DynoTableのアシスタントはこうした質問に、読み取り専用のWorkbench SQL(DynamoDBのアクセスパターンのルール内で動く本物のJOIN、GROUP BY、集計)で答えます。カウント/合計/平均の質問が行き着く先も同じです。

コストはいくらかかりますか？ メーターは2つです:クエリが触れる分のDynamoDB読み取りキャパシティ(アシスタントはゲートされた読み取りの前に確認します)と、あなた自身のAWSアカウントに請求されるBedrockの推論です — DynoTableは上乗せせず、何もプロキシしません。

次の質問は平易な言葉で聞いてみましょう — DynoTableをダウンロードして、AIを自分のBedrockに向け、すべての書き込みをレビューの後ろに置いてください。