1. はじめに

前回、awslabs/mcp リポジトリの Amazon Aurora Postgres MCP Server（awslabs.postgres-mcp-server） を Claude Desktop につなぎ、Aurora PostgreSQL に SQL を実行するところまでを確かめました¹。今回はその続きで、同じ awslabs/mcp にある Amazon DynamoDB MCP Server（awslabs.dynamodb-mcp-server）² を Claude Desktop につなぎます。Postgres 版と同じ感覚で「つないで自然言語でデータを見る」つもりでいました。今回検証したバージョンは 2.1.3³ です。

ところが提供ツールを確認すると、テーブルを読み書きするツールが 1 つもありませんでした。DynamoDB MCP Server は 2.0.0（2025-09-11）で、テーブル操作・項目操作・クエリといったデータ操作系のツールをすべて削除していました。CHANGELOG にこう書かれています。

BREAKING CHANGE: DynamoDB Native API functions have been removed in favour of the AWS API MCP Server.

出典: dynamodb-mcp-server CHANGELOG 2.0.0⁴

つまり現在の DynamoDB MCP Server は、データを操作するサーバではなく、DynamoDB のデータモデル設計を支援するサーバに役割を変えていました。データの読み書きは、別の AWS API MCP Server（awslabs.aws-api-mcp-server）⁵ を使ってくださいという案内です。

そこで本記事は「つないでみた」を軸にしつつ、(1) このサーバが実際に何をするツールを持つのか、(2) データモデリングの支援がどう動くのか、(3) データ操作を担う AWS API MCP Server を読み取り専用でつなぐと書き込みがどう止まるのか、の 3 点を確かめます。

1.1. 今回の検証ゴール

#	検証項目	達成できたとみなす条件
1	DynamoDB MCP Server（2.1.3）を Claude Desktop につなぎ、提供ツールの実体を確認する	ツール一覧を実機で取得でき、データ操作系ツールの不在を確認できる
2	データモデリング支援の一連の流れを体験する	アクセスパターンを反映したモデル設計書と、月額コストの試算が会話から生成される
3	データ操作を担う AWS API MCP Server を読み取り専用でつなぐ	実テーブルへの読み取りが AWS CLI の結果と一致し、書き込み依頼は `READ_OPERATIONS_ONLY` の下で実行に至らない

1.2. 結論（先出し）

DynamoDB MCP Server 2.1.3 の提供ツールは 8 つで、すべてデータモデリング・検証・コスト計算・コード生成の設計支援系だった。テーブルを読み書きするツールはない
モデリングは自然言語のヒアリングから始まり、シングルテーブル設計と GSI、月額コストの試算まで会話で出てきた。設計したモデルを DynamoDB Local で動作検証するツールも用意されている
データ操作は AWS API MCP Server に分かれている。読み取り専用（READ_OPERATIONS_ONLY=true）で起動すると、読み取りは通り、書き込み（put-item）はツール側で拒否された

2. 検証環境

項目	内容
MCP クライアント	Claude Desktop（Windows 版）
DynamoDB MCP Server	`awslabs.dynamodb-mcp-server` 2.1.3³（WSL2 上の uvx で実行）
AWS API MCP Server	`awslabs.aws-api-mcp-server` 1.3.46⁶（WSL2 上の uvx で実行）
対象サービス	Amazon DynamoDB
検証テーブル	`ddbmcp-orders`（パーティションキー `customer_id` ＋ソートキー `order_id`・5 件投入）

MCP サーバは 2 つとも Windows 版 Claude Desktop から WSL2（Ubuntu 24.04）の uvx で起動します。前回と同じ構成で、AWS のプロファイルは WSL 側に用意したものを使います。

3. 繋いで分かった「設計支援特化」への転換（ゴール 1）

3.1. ツール一覧（8 つとも設計支援系）

Claude Desktop に DynamoDB MCP Server を登録して起動すると、ツールの権限画面に 8 つのツールが並びました。

事前に stdio の JSON-RPC で取得した tools/list の応答とも一致します。8 つの内訳は次のとおりです。

ツール名	用途
`dynamodb_data_modeling`	データモデリングの設計手順（エキスパートプロンプト）を取得する
`dynamodb_data_model_validation`	設計したモデルを DynamoDB Local で動作検証する
`source_db_analyzer`	既存の RDB（MySQL / PostgreSQL / SQL Server / Oracle）のスキーマを分析する
`generate_resources`	モデルからテーブルをデプロイする CDK アプリを生成する
`dynamodb_data_model_schema_converter`	設計書をプログラムから扱える JSON 形式に変換する
`dynamodb_data_model_schema_validator`	その JSON をコード生成用に検証する
`generate_data_access_layer`	JSON から Python のデータアクセスコードを生成する
`compute_performances_and_costs`	アクセスパターンから RCU/WCU と月額コストを計算する

前回の Postgres MCP Server が持っていた run_query（SQL 実行）のような、テーブルのデータを読み書きするツールはひとつもありません。8 つとも、モデルの設計・検証・コード生成・コスト計算という設計フェーズの作業です。

3.2. 操作系ツールはどこへ行ったか

1 章で引用したとおり、データ操作系のツールは 2.0.0 で削除されていました。CHANGELOG では、削除されたのが次の 8 カテゴリだと列挙されています。

テーブル操作（Table Operations）
項目操作（Item Operations）
クエリとスキャン（Query and Scan Operations）
バックアップとリカバリ（Backup and Recovery Operations）
TTL 操作 / エクスポート操作 / タグとリソースポリシー操作 / その他（describe-endpoints など）

そして移行先が案内されています。

Migration: Use the AWS API MCP Server to perform these operations going forward.

出典: dynamodb-mcp-server CHANGELOG 2.0.0⁴

DynamoDB 専用の操作ツールを個別に持つのをやめ、AWS API を汎用に呼べる AWS API MCP Server に一本化した、という形です。この AWS API MCP Server は 5 章で実際につなぎます。

CHANGELOG をさらに追うと、2.0.4（2025-11-21）で execute_dynamodb_command というツールが「AWS API MCP Server と統合して DynamoDB 操作を実行する」目的で追加されたと書かれています。ただし 2.1.3 の実機の tools/list にこのツールは出てきません。ソースを見ると内部関数（aws dynamodb で始まるコマンドだけを受け付け、後述の DynamoDB Local 検証で使う）として残っており、MCP のツールとしては公開されていませんでした。CHANGELOG と実機のツール一覧に差があるので、提供ツールは実機の tools/list で確かめるのが確実です。

3.3. 起動時のつまずき（引数はなく、無効な環境変数がひとつ）

セットアップでの気づきを 2 つ書いておきます。

ひとつは、このサーバに コマンドライン引数がない ことです。前回の Postgres MCP Server は接続方式やエンドポイントを引数で渡しましたが、DynamoDB MCP Server は --help を付けても起動してそのまま入力待ちになります（実装を見ても引数の定義がありません）。設定は環境変数（AWS_PROFILE / AWS_REGION など）だけで渡します。

{
  "mcpServers": {
    "awslabs.dynamodb-mcp-server": {
      "command": "wsl.exe",
      "args": [
        "bash",
        "-lc",
        "AWS_PROFILE=aws-verify AWS_REGION=ap-northeast-1 uvx awslabs.dynamodb-mcp-server@2.1.3"
      ]
    }
  }
}

もうひとつは、公式 README のインストールボタンに含まれる DDB-MCP-READONLY という環境変数が、2.1.3 の実装には存在しない ことです。配布物を展開して調べると、この名前が出てくるのはインストールボタンの設定 JSON だけで、コード側にこれを読む箇所はありませんでした（読み取り専用の制御は、後述の AWS API MCP Server 側の READ_OPERATIONS_ONLY が担います）。設定しても効かない環境変数なので、付けても意味はありません。

4. データモデリングを試す（ゴール 2）

役割が設計支援だと分かったので、そのモデリング支援を実際に使ってみます。題材は EC サイトの注文管理にしました。

DynamoDB MCP サーバのデータモデリングツールを使って、EC サイトの注文管理のデータモデルを設計してください。作業ディレクトリは＜WSLパス＞/ddbmcp-workspace です。

すると dynamodb_data_modeling ツールが呼ばれ、設計の手順に沿って要件のヒアリングが始まりました。

4.1. アクセスパターンのヒアリング

ヒアリングは、選択式の入力画面（elicitation）で「どのアクセスパターンが必要か」を尋ねてきました。DynamoDB はアクセスパターンからキー設計を決めるので、最初にここを固めるのは定石どおりです。

今回は次の 5 つのアクセスパターンと、規模感（顧客 10 万人・注文 100 万件/月・ピーク 50 リクエスト/秒）を答えました。

顧客 ID で顧客情報を取得する
顧客ごとの注文履歴を新しい順に一覧する
注文 ID で注文明細を取得する
商品 ID で商品情報を取得する
注文を新規登録する（書き込み）

回答すると、要件をまとめたファイルと設計書が作業ディレクトリに書き込まれました。書き込み自体は MCP のツールではなく、Claude Desktop 自身が bash（WSL のコマンド）で行っていました。ツールが返すのは「設計手順のプロンプト」で、実際の要件整理・設計・ファイル出力はクライアント側の LLM が進める、という分担です。

4.2. 出てきた設計（シングルテーブルと GSI）

生成された設計書は、1 つのテーブルに顧客・商品・注文・注文明細をまとめるシングルテーブル設計でした。主なキー設計は次のとおりです。

パーティションキー	ソートキー	用途
`CUSTOMER#<顧客ID>`	`METADATA`	顧客情報
`PRODUCT#<商品ID>`	`METADATA`	商品情報
`CUSTOMER#<顧客ID>`	`ORDER#<注文日>#<注文ID>`	注文ヘッダ
`CUSTOMER#<顧客ID>`	`ORDER#<注文日>#<注文ID>#ITEM#<商品ID>`	注文明細

注文のソートキーに注文日を含めることで「顧客ごとの注文履歴を新しい順」を 1 回の Query で取れる形にし、「注文 ID から明細をまとめて取る」用に GSI を 1 本（GSI1PK = ORDER#<注文ID>）足す、という設計です。答えた 5 つのアクセスパターンがそれぞれキー条件に対応づけられ、選ばなかった検索（ステータス別一覧など）は設計書に「対象外」として書き分けられていました。

4.3. コスト試算

続けて、月額コストの試算を頼みました。

このデータモデルの RCU/WCU と月額コストを計算してください。

compute_performances_and_costs ツールが、アクセスパターンごとの RCU/WCU と月額コストを計算しました。途中で「GSI のサイズをテーブル本体と合わせて修正します」と一度計算し直して、2 回実行しています。

出てきた試算は月額 111.83 ドルでした。内訳は次のとおりです。

内訳	月額
ストレージ	1.65 ドル
読み書きリクエスト	110.18 ドル
合計	111.83 ドル

支配的なのは書き込みで、注文登録（TransactWriteItems）がテーブル本体で 65.88 ドル、GSI への追加書き込みで 32.94 ドル、あわせて全体の約 9 割を占めていました。

このコスト試算は、レポートの但し書きに「バージニア北部（us-east-1）の標準テーブル・オンデマンド単価、単価は 2026 年 1 月時点」と明記されています。東京リージョンの実額ではないので、金額そのものより「どのアクセスパターンがコストを支配するか」を読むのに使うのがよさそうです。

4.4. モデル検証ツールで DynamoDB Local まで

コスト試算のあと、今回は Claude Desktop が続けて dynamodb_data_model_validation ツールを呼び、DynamoDB Local で設計の動作検証まで行いました。WSL に Docker が入っていないため、ツールは Java 版の DynamoDB Local に自動でフォールバックし、ローカルにテーブルを作ってテストデータを入れ、5 つのアクセスパターンを実際に実行していました。結果はすべて成功（HTTP 200）で、検証結果の JSON が作業ディレクトリに残りました。

ただし、このツールを呼ぶかどうかを決めているのは MCP サーバではなくクライアント側の LLM です。サーバはモデル検証のツールを用意しているだけで、今回はこちらが指示しなくても Claude がコスト試算からの流れで呼んだ、という形でした。「設計から動作検証まで一連で回るか」は、サーバの機能というより、クライアント（LLM）がツールをどうつなぐか次第です。

5. データ操作は AWS API MCP Server で（ゴール 3）

データの読み書きは AWS API MCP Server に分かれています。こちらをつないで、読み取りと書き込みを試します。

検証用に、DynamoDB へオンデマンドのテーブル ddbmcp-orders を作り、注文を 5 件入れておきました（顧客 C001 が 3 件、C002 が 2 件）。

5.1. 読み取り専用でつなぐ

AWS API MCP Server は、環境変数 READ_OPERATIONS_ONLY=true を付けて起動すると読み取り専用になります。

{
  "mcpServers": {
    "awslabs.aws-api-mcp-server": {
      "command": "wsl.exe",
      "args": [
        "bash",
        "-lc",
        "AWS_API_MCP_PROFILE_NAME=aws-verify AWS_REGION=ap-northeast-1 READ_OPERATIONS_ONLY=true uvx awslabs.aws-api-mcp-server@1.3.46"
      ]
    }
  }
}

このサーバのツールは call_aws（AWS CLI コマンドを実行する）と suggest_aws_commands（自然言語から CLI コマンドを提案する）の 2 つです。Claude Desktop のツール権限画面でも、この 2 つが「読み取り専用ツール」として分類表示されました。

5.2. 読み取りは AWS CLI の結果と一致する

顧客 C001 の注文を新しい順で聞いてみます。

DynamoDB の ddbmcp-orders テーブルから、顧客 C001 の注文を新しい順に見せてください。

会話では、call_aws で query を実行して 3 件が新しい順に返りました。

order_id	商品	単価	数量
2026-07-01#O-1003	USB ケーブル	1,200 円	3
2026-06-15#O-1002	キーボード	9,800 円	2
2026-06-01#O-1001	モニター	32,000 円	1

事前に AWS CLI で取っておいた同じ query の結果（件数・並び順・金額）と一致しました。

このとき、会話の中で 2 回の立て直しがありました。1 回目は call_aws のコマンドのフラグ構文が通らず、テーブルのキースキーマを確認してからコマンドを作り直しています。2 回目は describe-table の項目数（ItemCount）が 0 に見えたため「空テーブルかもしれない」と判断しかけ、「この件数は反映が遅れることがある」と自分で補足して scan で実データを確認し直していました。DynamoDB の ItemCount は約 6 時間ごとの更新で、投入直後は実件数を反映しません。その仕様が会話の挙動に出た形です。

5.3. 書き込みはツール側で拒否されるが、迂回路を提案してくる

同じ会話で、今度は書き込みを頼みます。

ddbmcp-orders テーブルに、顧客 C003 のテスト注文を 1 件追加してください。

順を追うと、次のようになりました。

Claude は put-item を call_aws で実行しようとした（提案だけで止まったのではなく、実行しに行った）
サーバが「読み取り専用ポリシーで運用されているため、書き込み操作（put-item）はブロックされました」とエラーを返した
Claude は続けて「WSL 側の AWS CLI（プロファイル aws-verify）から直接実行すれば書き込める可能性があります。そちらで実行してよいか確認させてください」と、MCP サーバを経由しない迂回路を提案してきた
確認ダイアログで「実行しない」を選び、停止した

書き込みの前後でテーブルの件数を数えると、どちらも 5 件のままで、DynamoDB 側に変更は入っていません。書き込みが READ_OPERATIONS_ONLY の下でツール側から止まること、そして DB が変わっていないことは確認できました。

なお、READ_OPERATIONS_ONLY が止められるのは、この MCP サーバのツール（call_aws）を経由する操作だけです。上のように、クライアント（Claude Desktop）が別に bash を持っていれば、そこから直接 AWS CLI を叩けてしまいます。この境界については 6 章で触れます。

6. 考察

6.1. 同じ awslabs でも「実行型」と「設計支援型」

前回の Postgres MCP Server は、run_query で SQL を実行し、テーブルのデータを読み書きする「実行型」でした。今回の DynamoDB MCP Server は、データを触るツールを持たず、設計を助ける「設計支援型」です。同じ awslabs/mcp のリポジトリにあり、名前も似ていますが、役割は違います。

この違いは、対象データベースの使われ方の違いを反映していると考えられます。DynamoDB はアクセスパターンを先に決めてキー設計に落とし込む必要があり、その設計の良し悪しが後の使い勝手とコストを大きく左右します。設計フェーズを手厚く支援し、データ操作は AWS API MCP Server に任せる、という分担は、この設計の重さに合っていそうです。実際、公式の CHANGELOG も操作系を「AWS API MCP Server に譲る」形で削除していました。

6.2. 「読み取り専用ツール」の表示は動的に決まる

5.1 章で、AWS API MCP Server の 2 ツールが「読み取り専用ツール」と表示されました。これは READ_OPERATIONS_ONLY=true を付けたときの表示です。tools/list の応答を、この環境変数を付けた場合と付けない場合で見比べると、call_aws ツールの readOnlyHint という注釈が切り替わっていました。

起動時の環境変数	`call_aws` の readOnlyHint
`READ_OPERATIONS_ONLY=true`	`true`
指定なし	`false`

Claude Desktop は、このツールの注釈を見て「読み取り専用ツール」に分類していたわけです。前回の Postgres MCP Server の読み取り専用は、SQL のキーワードを実行時に検査する方式で、ツールの見た目は変わりませんでした。同じ「読み取り専用」でも、実装の仕方が違います。

6.3. 読み取り専用フラグの境界は「MCP のツール経由」まで

5.3 章の迂回路の提案を掘り下げます。READ_OPERATIONS_ONLY は call_aws ツール経由の書き込みは止めましたが、Claude はすぐに「WSL の AWS CLI から直接実行すれば書けます」と、MCP を経由しない経路を提案してきました。

この境界は、AWS のセキュリティブログがそのまま言語化しています。

When an agent uses a bash tool to run an AWS CLI command … The request bypasses MCP servers entirely.

出典: AWS Security Blog「Secure AI agent access patterns to AWS resources using Model Context Protocol」⁷

エージェントが bash ツールで AWS CLI を実行すると、リクエストは MCP サーバを完全に迂回する、という指摘です。今回の Claude の提案は、まさにこの迂回路でした。同じブログは、権限そのものについてもこう書いています。

Any permission you grant to an agent can be exercised, regardless of your intended use case.

エージェントに与えた権限は、こちらの意図と関係なく行使され得る、という指摘です。今回の検証プロファイル（cloud-recon-agent）は DynamoDB への put-item を IAM で許可しているので、もし「実行する」を選んでいれば、CLI 直接実行で書き込めていたはずです。

読み取り専用フラグは、MCP のツール経由の操作を止める便利な一層です。ただしそれが守るのはツール経由の範囲までで、書き込みを本当に止めたいなら、(1) IAM 側で write 権限を与えない、(2) クライアントでツールやコマンドの承認を挟む、の 2 つが土台になります。前回の Postgres MCP Server で create_cluster が読み取り専用の対象外だったのと、根っこは同じで、フラグの外側は IAM とユーザーの承認で守る、という構図です。

6.4. エラーからの LLM の立て直し

今回も、LLM がエラーや想定外の状態から自力で立て直す場面がありました。

call_aws のコマンドのフラグ構文が通らない → キースキーマを確認してコマンドを作り直す
describe-table の ItemCount が 0 → 「反映が遅れる件数だ」と補足して scan で実データを確認する
書き込みがツール側で拒否 → 原因（読み取り専用ポリシー）を特定し、代替経路を提案する

いずれも、ツールやサービスが具体的なエラー・値を返したことが、会話面での原因特定につながっていました。ItemCount の扱いのように、DynamoDB の仕様を踏まえた補足まで出てくるのは、モデル側にその知識があるためと考えられます。

7. まとめ

#	検証項目	結果
1	DynamoDB MCP Server の提供ツールの実体を確認する	OK。8 ツールとも設計支援系で、データ操作系ツールはない。2.0.0 で操作系を削除し AWS API MCP Server へ移行済み
2	データモデリング支援の一連の流れを体験する	OK。アクセスパターンのヒアリングからシングルテーブル設計・コスト試算まで会話で生成された。モデル検証ツールで DynamoDB Local での動作確認もできた（呼ぶ判断はクライアント LLM 側）
3	AWS API MCP Server を読み取り専用でつなぐ	OK。読み取りは AWS CLI と一致、書き込みはツール側で拒否。ただし CLI 直接実行の迂回路が提案され、前後で件数は変わらず

「つないで自然言語でデータを見る」という前回と同じ入り方を想定していましたが、DynamoDB MCP Server は役割が設計支援に寄っていて、データ操作は AWS API MCP Server に分かれていました。同じ awslabs でも、対象 DB によってサーバの役割が違うのは、つないでみて分かったことです。

読み取り専用フラグの境界（MCP のツール経由まで）と、その外側を IAM とユーザー承認で守るという構図は、前回の Postgres MCP Server とも共通していました。

AWS 公式の Postgres MCP Server で Aurora PostgreSQL に接続してみた ↩
awslabs/mcp dynamodb-mcp-server（GitHub README）。自己定義は "The official developer experience MCP Server for Amazon DynamoDB. This server provides DynamoDB expert design guidance and data modeling assistance."。公式サイト版は Amazon DynamoDB MCP Server ↩
awslabs.dynamodb-mcp-server（PyPI）。検証時バージョン 2.1.3（2026-05-09 リリース） ↩ ↩²
dynamodb-mcp-server CHANGELOG（GitHub）。2.0.0（2025-09-11）で操作系ツールを削除。2.0.4（2025-11-21）で execute_dynamodb_command を追加 ↩ ↩²
awslabs/mcp aws-api-mcp-server（GitHub README）。READ_OPERATIONS_ONLY は既知の読み取り専用アクション一覧と照合し、一覧に無いコマンドを実行しない。"IAM permissions remain the primary and most reliable security control" と明記 ↩
awslabs.aws-api-mcp-server（PyPI）。検証時バージョン 1.3.46 ↩
Secure AI agent access patterns to AWS resources using Model Context Protocol（AWS Security Blog）。bash ツール経由の AWS CLI は MCP サーバを迂回する／付与した IAM 権限は意図に関係なく行使され得る、と指摘 ↩