Claude Code 向けの DynamoDB MCP

Claude Code は、呼び出せる MCP サーバーさえ与えれば、あなたの DynamoDB のスキーマを読み取り、テーブルに対して実際のクエリを実行し、編集を提案できます。このガイドは接続を端から端まで扱います — 正確なコマンド、Claude Code が選択を迫るスコープの判断、ツールが実際に読み込まれたかを確かめる方法、そしてほとんどのセットアップが取り違えている部分 — エージェントが最終的にどの認証情報を握るのかです。

手短に言えば、ローカルの MCP サーバーとして動作する DynoTable に Claude Code を向ければ、AWS キーはエージェントではなく DynoTable に留まります。それを AWS の公式サーバーやコミュニティの npm/PyPI サーバーと比べたい場合は、 DynamoDB MCP サーバーの概要が真っ向から比較しています。

接続すると Claude Code に何ができるか

サーバーを接続すると、Claude Code はあなたのデータモデルを推測するのをやめ、実際に読み取り始めます。

テーブルとスキーマの探索 — テーブル一覧、キースキーマ、インデックス、そしてアイテムに実際に現れる属性（書き込んだつもりの属性ではなく）。
実際のクエリと Scan の実行 — Query、Scan、GetItem、そして PartiQL。その結果はあなたのクリップボードではなく、Claude Code の推論に直接返されます。
集計 — DynamoDB 自体がネイティブには実行できない件数、合計、グループ化。
編集の提案 — それらはあなたのテーブルではなく、レビュー可能なステージングエリアに着地します。

最後のひとつが設計の核心です。エージェントが提案し、あなたがコミットします。

始める前に

必要なものは 3 つです。

DynoTable のインストール — ダウンロードして、エージェントに見せたい AWS プロファイルを追加します。
MCP サーバーをオンにする — 設定 → MCP サーバー。デフォルトではオフです。 127.0.0.1 にのみバインドするため、マシンの外からは何も到達できません。
プロファイルを公開する — そのプロファイルの MCP セクションを開き、 MCP 経由で公開をオンにします。接続は 1 つのプロファイルの認証情報とリージョンに厳密に固定されるため、dev に配線したエージェントが prod を見ることは決してありません。

プロファイルの MCP セクションには、実際のポートを含む正確な接続コマンドが表示されます。

Claude Code にサーバーを追加する

プロジェクト内で次を実行します。ポートとプロファイルのスラッグは、そのペインに表示されるものに置き換えてください。

claude mcp add --transport http dynotable-prod "http://127.0.0.1:<port>/mcp?profile=prod"

--transport http は重要です。DynoTable は MCP を stdio ではなく streamable HTTP で話します。これを省くと、Claude Code は dynotable-prod をコマンドとして実行しようとして失敗します。

末尾の ?profile=prod は、DynoTable の承認プロンプトでどのプロファイルを要求しているかを事前選択します。これはヒントであって、認可ではありません — 接続の確認はやはりアプリ内で行います。

どのスコープで登録するか

Claude Code はサーバーを 3 か所のいずれかに書き込みます。そしてデータベース接続については、デフォルトはおそらくあなたが望むものではありません。

スコープ	フラグ	書き込み先	使いどころ
Local（デフォルト）	なし	ユーザー設定（このプロジェクトにスコープされる）	試してみるとき
User	`--scope user`	`~/.claude.json`	すべてのプロジェクトで使いたいとき
Project	`--scope project`	プロジェクトルートの `.mcp.json`	今回のケースでは使わない

--scope project は使わないでください。 そのファイルはコミットされるため、チームメイトが動かしていない 127.0.0.1:<port> のサーバーを配ってしまいます — 彼らの Claude Code はセッションのたびに接続を試みて失敗します。ポートもマシンごとに異なります。ここは local か user に留めましょう。

claude mcp add --scope user --transport http dynotable-prod "http://127.0.0.1:<port>/mcp?profile=prod"

接続を承認する

Claude Code が初めて接続すると、Claude Code ではなく DynoTable が、接続してくるクライアントの名前を示し、どのスコープを付与するかを尋ねる同意プロンプトを表示します。

読み取り専用 — スキーマ、クエリ、アイテムの読み取り。いかなる変更もありません。
読み取り＆ステージング — 上記に加えて、あなたが確認するための変更のステージング。それでも直接の書き込みは決してありません。
フルアクセス — 上記に加えて、ビューを開く、フィルター、エクスポート。ここでも 書き込みはやはりステージングを経由します。

まずは読み取り専用から始めましょう。クライアントは MCP ペインからいつでも取り消しや再承認ができ、スコープは呼び出しのたびに再チェックされます — つまり、狭める変更は次の再接続時ではなく即座に効きます。

実際に読み込まれたかを確認する

確認は 2 段階、この順で行います。

claude mcp list

これは設定済みのすべてのサーバーと、それがどのスコープから解決されたかを一覧します。 dynotable-prod が出てこないなら、add は別のスコープ、または別のプロジェクトディレクトリに書き込まれています。

次に、Claude Code のセッション内で:

/mcp

これはライブの接続状態と、サーバーが公開したツールを表示します。claude mcp list には出るのに /mcp で失敗と表示されるサーバーは、_実行時_の問題です — DynoTable が起動していない、ポートが変わった、あるいは接続が一度も承認されていない、のいずれかです。

何を尋ねるか

役に立つプロンプトは、DynamoDB の豆知識ではなく_あなた自身_のデータを必要とするものです。

「このプロファイルにはどんなテーブルがあり、それぞれのキースキーマはどうなっていますか?」
「顧客 c#4182 の直近 30 日間の注文をすべて見つけて、ステータスの内訳をまとめてください。」
「この Query が何も返しません — テーブルのキースキーマを読んで、理由を教えてください。」
「orders の status ごとにアイテムを数えてください。」（DynamoDB がネイティブには答えを持たない集計です。）
「この 3 件のアイテムの status を cancelled にしてください。」 — これは確認用に 3 つの差分をステージングし、あなたがコミットするまで何も書き込みません。

Claude Code は最初の 4 つが得意で、5 つ目が安全なのは、まさにコミットのステップがあなたのものだからです。

なぜ Claude Code に AWS 認証情報を渡してはいけないのか?

失敗したときの影響範囲に歯止めがないからです。よくあるアドバイス — AWS のアクセスキーとシークレットを保持する MCP サーバーを動かす — は、エージェントのプロセスにそれらのキーの IAM 権限をフルに与えてしまい、その手前に DynamoDB 固有のレビューステップは何もありません。

問題はモデルが悪意を持っていることではありません。MCP のツール結果が信頼できない入力である ことです。エージェントが読み取る行、ドキュメント、ウェブページには、命令が含まれうります。それがプロンプトインジェクションであり、あなたのキーを保持する書き込み可能なサーバーに対してそれが成功すれば、あなたのテーブルに直接作用しえます。

DynoTable を経由させれば、その両方が取り除かれます。

あなたの AWS 認証情報がエージェントに届くことは決してありません。 DynoTable がプロファイルを保持し、Claude Code は AWS ではなく DynoTable と対話します。エージェントのプロセス内のどこからも、あなたのキーは読み取れません。
直接書き込むツールは存在しません。 権限でゲートされているのではなく — そもそも無い のです。乗っ取られたエージェントが読み取り＆ステージングでできる最大のことは、あなたが読む差分を提案することだけです。

トラブルシューティング

claude mcp list に出てこない。 別のディレクトリから local スコープで追加しています。 --scope user を付けて実行し直してください。

一覧には出るが、/mcp で失敗と表示される。 順に確認します。DynoTable は起動していますか、 設定 → MCP サーバーはまだオンですか、URL のポートは今も有効なものですか、そしてアプリ内で接続を承認しましたか?

接続はできているのに、ツールがない。 要求している内容を公開しないスコープで接続が承認されているか、プロファイルが 1 つも公開されていません。プロファイルの MCP 経由で公開を確認してください。

接続はできたが、見えているテーブルが違う。 接続は ?profile= のヒントに関わらず、あなたが承認したプロファイルに紐づきます。MCP ペインで取り消して、接続し直してください。

アップデート後に何も動かない。 クライアントをリロードしてください — Claude Code はセッションのあいだツール一覧をキャッシュします。

よくある質問

Claude Code を DynamoDB に接続するには?

DynoTable をインストールし、設定 → MCP サーバーでサーバーをオンにし、エージェントに見せたい AWS プロファイルを公開してから、そのプロファイルの MCP セクションに表示される endpoint を使って claude mcp add --transport http を実行します。希望するスコープで DynoTable 内の接続を承認すれば、Claude Code は AWS 認証情報を一切保持することなく、スキーマを読み取り、テーブルにクエリを実行できます。

Claude Code は私の DynamoDB テーブルに書き込めるか?

DynoTable を経由する限り、直接には書き込めません。呼び出せるコミット用のツールが存在しないからです — 読み取り＆ステージングまたはフルアクセスでは、エージェントは変更をステージングできますが、それはアプリ内でレビュー可能な差分として現れ、あなたがコミットしたときにのみ書き込まれます。書き込み可能な AWS キーを設定したコミュニティの MCP サーバーは別の話で、そちらはあなたのテーブルに直接書き込めます。

claude mcp add ではどのスコープを使うべきか?

local（デフォルト）または --scope user を使ってください。--scope project は避けましょう。コミットされる .mcp.json に書き込まれ、チームメイトが動かしていないループバックのポートを配ってしまうからです。

Claude Code に AWS のアクセスキーは必要か?

いいえ。DynoTable があなたの AWS プロファイルを保持し、DynamoDB の呼び出しを自ら行うため、キーは DynoTable のプロセス内に留まります。Claude Code はローカルの MCP endpoint とだけ対話します。コミュニティの MCP サーバーは一般に、エージェントの環境にキーを必要とします。

本番の DynamoDB へのアクセスを Claude Code に与えても安全か?

機微でないテーブルへの読み取りアクセスは低リスクです。本当の問題は書き込みアクセスです。MCP のツール結果は信頼できない入力であり、プロンプトインジェクションがエージェントを操作しうるからです。接続は読み取り専用に保つか、すべての変更を人間のレビューステップ経由でルーティングして、操作されたエージェントにできることを、あなたが読む差分の提案だけに限りましょう。