あなたのRDSインスタンスにはパブリックなエンドポイントがない。
踏み台なしで、AWS SSM経由で到達する。
AgentsRoomは、あなたのデータベースへAWS Session Managerのポートフォワーディングセッションを開き、その先にSQLクライアントをつなぎます。セッションはAWS-StartPortForwardingSessionToRemoteHostドキュメントを指定してaws ssm start-sessionを実行し、マシンにすでに設定済みのAWSプロファイルがそれを認可します。
データベースはプライベートサブネットに留まり、セキュリティグループは閉じたまま、インターネットに新しく晒されるものはありません。変わるのは、ついにそれをクエリできるようになることです。AIコーディングエージェントも、読み取り専用で同じことができます。
AgentsRoomが、インターネットに何も開かずにAWS Systems Manager経由でプライベートサブネット内のRDSインスタンスに到達する仕組み。
この構成はよくあるものなので退屈なくらいですが、厄介さは午後を1つ潰すには十分です。Amazon RDSインスタンスはプライベートサブネットにあります。パブリックなエンドポイントはありません。セキュリティグループが受け入れるのは、アプリケーションからの通信だけです。そのVPCのどこにも受信SSHポートはありません。誰かが正しい判断をして閉じたからです。そして今、バグを理解するために3行のデータを見る必要があります。
AWS Systems Manager Session Managerは、通信路の部分をすでに解決しています。VPC内の管理対象EC2ノードは、あなたのマシンのローカルポートを、そのノードから到達できる第三のホストへ転送できます。プライベートサブネット内のRDSインスタンスは、まさにそれに当たります。それを行うドキュメントがAWS-StartPortForwardingSessionToRemoteHostで、コマンドはaws ssm start-sessionです。目新しいものは何もなく、データベース側にインストールするものもありません。
AgentsRoomはそのコマンドをあなたの代わりに実行し、反対側にSQLクライアントを置きます。インスタンス、リージョン、プロファイルを一度選び、そこにデータベース接続を紐づければ、以降そのデータベースを開くのはワンクリックです。セッションを認可するのはあなた自身のAWSプロファイルまたはSSOログインなので、この経路のために保存される鍵もパスワードもありません。
いつもの回避策には、どれも代償がある
同じ問題への3つの答えと、それぞれが請求してくるもの。
維持し続ける踏み台ホスト
パブリックサブネットに置いた踏み台サーバーは、パッチを当て、監視し、費用を払い、やがて忘れられるサーバーです。受信SSHポートを抱え、人の出入りに合わせてずれていく認可済み鍵のリストを抱え、うっかりした編集ひとつで世界に開いてしまうセキュリティグループを抱えています。それが存在する理由は、誰かがときどきデータベースに到達するためだけです。
3行のためのVPN
クライアントVPNは、3行のデータについての疑問に答えるために、あなたのマシン全体をネットワークの内側に入れます。用意し、配布し、更新し、失効させる必要があり、他の接続設定とぶつかり、ネットワークを渡り歩くノートPCでは真っ先に壊れる部品になります。VPNを持っているチームの多くは、その隣に踏み台も置き続けています。
あちこちにコピーされる認証情報
誰もが最後に頼ってしまう代替案は、もっと悪いものです：エンドポイントとパスワードが、チャットのメッセージ、共有メモ、うっかりコミットされたスクリプト、AIエージェントに送るプロンプトに残ります。アクセスは誰も追跡していない場所へ広がり、あとから取り消すには、認証情報をローテーションして、すべてのコピーが消えていることを祈るしかありません。
プライベートなRDSインスタンスから結果セットまで
4つのステップは一度きり、あとはワンクリックです。
AWS SSM接続を保存する
接続マネージャーで接続を追加し、トランスポートをAWS SSMにします。データベースに到達できる管理対象EC2ノードのインスタンスID（i-0123456789abcdef0）、AWSプロファイル、リージョンを指定します。パスワードの欄も鍵の欄もありません。セッションを認可するのは、すでにマシンにあるAWSの認証情報だからです。
データベースを追加し、その接続経由で到達する
RDSのエンドポイントをホストにして、ポート、ユーザー、データベースとともにMySQLまたはMariaDBの接続を追加します。「経由する接続」の欄では、直接接続ではなく、いま保存したAWS SSM接続を選びます。設定はこれで全部です：エンドポイントはプライベートのまま、セキュリティグループも閉じたままです。
AgentsRoomがセッションを開く
接続を開くと、AgentsRoomはまずOSに空いているループバックポートを求め、次にAWS-StartPortForwardingSessionToRemoteHostドキュメントを指定してaws ssm start-sessionを起動します。このときhostにはRDSのエンドポイント、portNumberにはデータベースのポート、localPortNumberには確保したポートを渡します。そのポートが実際にTCP接続を受け付けるまで待ってからトンネルを準備完了とするので、クライアントが早すぎるタイミングで接続することはありません。
自分でクエリするか、エージェントに任せる
SQLコンソールは127.0.0.1のフォワードされたポートに接続し、他のどの接続とも同じように振る舞います：スキーマブラウザ、一度に1文、上限付きの結果セット。AIコーディングエージェントは同じ接続にMCP経由で、読み取り専用で、パスワードを一度も受け取らずにクエリできます。接続を閉じれば、セッションのプロセスも一緒に終了します。
AgentsRoomが起動するコマンド
ここに独自プロトコルはなく、JavaScriptで再実装されたものもありません。AgentsRoomはAWS CLIを子プロセスとして起動し、引数はシェルを介さず直接渡して、その出力を読みます。ポートフォワーディングのセッションを手で開いたことがあるなら、これはすでに見慣れた一行です。
aws ssm start-session \
--target i-0a1b2c3d4e5f \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters host=acme-prod.abc123.eu-west-1.rds.amazonaws.com,\
portNumber=3306,localPortNumber=54321 \
--profile acme-prod --region eu-west-1インスタンスID、エンドポイント、リージョン、プロファイルは、保存済みの接続から来ます。ローカルポートは、開くたびにOSが選びます。
その先のデータベースではなく管理対象ノード自身へ転送する場合も、host=localhostにした同じドキュメントです。だからこそ同じ接続タイプが、プライベートサブネット内のデータベースと、接続先インスタンス上で動いているサービスの両方をカバーします。
動くために満たしておくべきこと
AgentsRoomはあなたのAWS構成を操作しますが、それを置き換えるものではありません。5つのことが揃っている必要があり、それはSession Managerを単体で使うときに必要な5つと同じです。
マシン上のAWS CLI
AgentsRoomはawsバイナリを直接呼びます。ターミナルでaws ssm start-sessionが動くなら、ここでも動きます。
session-manager-plugin
Session Managerは、CLIの隣にプラグインがインストールされている必要があります。なければセッションは即座に終了し、AgentsRoomは固まる代わりに、CLIが出力したエラーを見せます。
使えるAWSプロファイルまたはSSOログイン
認可はあなた自身の認証情報から来て、--profileと--regionとして渡されます。AgentsRoomが保存するのはプロファイル名とリージョンだけで、鍵もシークレットも保存しません。
VPC内の管理対象ノード
Systems Managerに登録され、SSM Agentが動いていて、セッションを許可するインスタンスプロファイルを持つEC2インスタンスです。通信が通り抜けるノードであり、それ自体は受信ポートを1つも必要としません。
ノードからデータベースまでの経路
データベースのセキュリティグループが、データベースのポートでノードからの通信を受け入れる必要があり、あなたのIAMポリシーがそのドキュメントでのssm:StartSessionを許可している必要があります。VPCについて他に変えるものはありません。
このトンネルがすること、そして断ること
ノートPCに設定を残したままにしても安全かどうかを決める性質。
ループバックのみ
フォワードされたポートは127.0.0.1にのみバインドされ、それ以外には開きません。この方法で到達するデータベースがローカルネットワークに再公開されることはないので、カフェのWi-FiであなたのノートPCが本番への開いたプロキシに変わることもありません。
OSが選ぶポート
AgentsRoomはOSに空いているポートを求め、それをセッションに渡します。当てにいく固定ポートはなく、事前に予約するものもなく、あなたが動かしている他の何かと衝突することもありません。
準備完了は、本当に準備完了
トンネルが準備完了になるのは、ローカルポートが実際にTCP接続を受け付けたときだけで、そうならなければCLIが出力したエラーとともに諦めます。適当なスリープもなく、まだ待ち受けていないポートにクライアントがつなぐこともありません。
この経路に鍵もパスワードもない
SSMセッションを認可するのは、あなたのAWSプロファイルまたはSSOセッションです。AgentsRoomが保存するのはインスタンスID、プロファイル名、リージョンで、その設定を読んだ誰かが再利用できるものは何ひとつありません。
データベースは読み取り専用のまま
データベース接続は作成された時点で読み取り専用です。書き込みには、その接続を書き込み可能にすることと明示的な確認が必要で、本番のフラグが立った接続はその確認ではっきりとそう告げます。
1回の呼び出しにつき1文
各呼び出しが運ぶのはちょうど1文なので、セミコロンの陰に何かが隠れることはなく、結果セットにも上限があるため、幅の広いクエリがウィンドウやエージェントのコンテキストを溢れさせることもありません。
これがアクセスを増やすのではなく、減らす理由
トンネルと聞けば穴のように思えますし、その反射は正しいものです：プライベートなデータベースに到達する方法の多くは、実際に攻撃面を広げます。この方法は逆に狭めます。データベース側では何も開かず、VPCのどこにも受信ポートを作らず、管理対象ノードも自前のSSHリスナーを必要としません。通信はノードからSystems Managerサービスへ出ていき、あなたのマシンはそこで合流します。
認可は、あなたの組織がすでに管理している場所に残ります。セッションを許可するのはあなたのAWSアイデンティティであり、マシンに設定済みのプロファイルまたはSSOログインを通じて与えられます。つまり他のSession Managerのセッションと同じように記録され、そのアイデンティティが失効した日に失効し、誰が鍵を持っているかではなくIAMポリシーによって範囲が決まります。AgentsRoomが保存するのはインスタンスID、プロファイル名、リージョンで、そのどれも認証情報ではありません。
データベース側のガードレールは、AgentsRoomのすべての接続に付いてくるものと同じです。デフォルトで読み取り専用、1回の呼び出しにつき1文、上限付きの結果セット、そして書き込みの確認を厳しくする本番フラグ。MCP経由でクエリするAIエージェントが受け取るのは結果セットだけでパスワードは決して受け取らず、エージェントがクエリに使うツールは、その接続が人間に何を許していようと読み取り以外を拒否します。
対応はMySQLとMariaDBのみで、PostgreSQLはそこに入っていません
データベースクライアントが話すのはMySQLのワイヤプロトコルなので、動くエンジンはMySQLとMariaDBです。RDSで言えば、RDS for MySQL、RDS for MariaDB、Aurora MySQL互換エディションが対象です。RDS for PostgreSQLとAurora PostgreSQLには対応しておらず、SQL Server、Oracle、MongoDB、SQLiteも同じです。それはダウンロードした後ではなく、前に知るべきことです。
SSMのトランスポート自体はTCPポートを転送するだけなので、エンジンを選びません。PostgreSQLに足りないのは下を通るトンネルではなく、その上に載るクライアントです。次にどのエンジンが来るかは寄せられた要望で決まるので、あなたのエンジンが足りないなら、公開バックログでどれかを伝えてください。票として数えられます。
使いたいデータベースエンジンをリクエストするエージェントも読み取り専用でクエリできる
接続さえできていれば、AIコーディングエージェントはそれを名前で指定してAgentsRoom MCP経由で使えます。db_listは保存済みの接続とそのメタデータを返し、db_schemaはSQLを一行も書かずにスキーマ、テーブル、カラムをたどり、db_queryは1文を実行して上限付きの行を返し、db_connection_newはまだ保存していないデータベースを、あなたが確認して保存するフォームにあらかじめ入力する形で提案します。
エージェントが求めたときにSSMセッションを開くのはAgentsRoom自身なので、エージェントがAWSの認証情報も、データベースのパスワードも、ポート番号も扱うことはありません。返っていくのは結果セットです。db_queryは接続が何を許していようと読み取り専用で、そのルールはMCPプロセスではなくデスクトップアプリ側にあるため、エージェントが言いくるめられて別のことを求めても揺らぎません。
これをきちんとやる意味は、そこにあります。プライベートサブネット内の本番レプリカを相手にデバッグするエージェントは、バグを説明する行を読めますが、それを変更する経路も、コンテキストに漏らす認証情報も持たず、アプリを閉じたあとにそのデータベースへ到達する手段もありません。
よくある質問
パブリックなエンドポイントを持たないRDSインスタンスには、どう接続しますか？
AWS SSMのポートフォワーディングセッション経由です。データベースに到達できる管理対象EC2ノードを指すAWS SSM接続を保存し、次にRDSのエンドポイントをホストにしてMySQLまたはMariaDBの接続を作り、「経由する接続」の欄でそのSSM接続を選びます。AgentsRoomがaws ssm start-sessionでセッションを開き、フォワードされたループバックポートにSQLクライアントをつなぎます。データベースはパブリックなエンドポイントを持たないままで、セキュリティグループも変わりません。
AgentsRoomはどのSSMドキュメントを使いますか？
AWS-StartPortForwardingSessionToRemoteHostです。hostにデータベースのエンドポイント、portNumberにデータベースのポート、localPortNumberにあなたのマシンで確保したループバックポートを設定します。このドキュメントは管理対象ノードを経由して第三のホストへ転送するもので、プライベートサブネット内のRDSインスタンスはまさにその場合に当たります。ノード自身へ転送するときは、host=localhostにした同じドキュメントです。
それでも踏み台ホストは必要ですか？
不要です。この用途では、Session Managerが踏み台サーバーの代わりになります：管理対象ノードは受信SSHポートもパブリックIPも必要とせず、通信はノードからSystems Managerサービスへ出ていき、あなたのマシンは外側からそのセッションに合流します。維持すべき鍵のリストも、見張っておくべきパブリックサブネットもありません。
自分のマシンには何をインストールしておく必要がありますか？
AWS CLIとsession-manager-plugin、それに使えるAWSプロファイルまたはSSOログインです。AgentsRoomはawsバイナリを直接呼ぶので、ターミナルでaws ssm start-sessionが動くならここでも動きます。プラグインがない場合、セッションは即座に終了し、AgentsRoomは見えないプロンプトの前で固まる代わりに、CLIが出力したエラーを見せます。
AgentsRoomはこのためにAWSの鍵を保存しますか？
保存しません。セッションを認可するのは、マシンにすでに設定済みのAWS認証情報で、CLIには--profileと--regionとして渡されます。AgentsRoomが保存するのはインスタンスID、プロファイル名、リージョンで、これらは認証情報ではありません。データベースのパスワードは別の話です：OSのキーチェーンで暗号化された保管庫に置かれ、AIエージェントに返されることは決してありません。
トンネルはどのローカルポートを使い、誰がそこへ到達できますか？
OSが開くときに空いているポートを選び、トンネルはそれを127.0.0.1にのみバインドします。ローカルネットワーク上の何かがそこへ到達することはなく、当てにいく固定ポートもありません。トンネルが準備完了とみなされるのは、そのポートが実際にTCP接続を受け付けてからで、接続と一緒に閉じられます。
RDS for PostgreSQLでも動きますか？
動きません。データベースクライアントが対応するのはMySQLとMariaDBだけなので、RDSで言えばRDS for MySQL、RDS for MariaDB、Aurora MySQL互換エディションが対象です。RDS for PostgreSQLとAurora PostgreSQLには今日は対応しておらず、SQL Server、Oracle、MongoDB、SQLiteも同じです。SSMのトンネル自体はTCPポートを転送するだけで、エンジンを問いません：足りないのは、その上に載るクライアントです。公開バックログでエンジンをリクエストすれば、票として数えられます。
データベースではなく、EC2インスタンス自身へ転送できますか？
できます。host=localhostにした同じドキュメントなので、管理対象ノードで待ち受けているサービスにも同じ方法で到達できます。同じAWS SSM接続は、そのインスタンス上で普通のターミナルセッションを開くこともできます。受信SSHポートを一切持たないマシンでエージェントのCLIを動かすのは、この方法です。
AIエージェントはトンネル経由でデータベースにクエリできますか？
できます、読み取り専用で。エージェントはAgentsRoom MCP経由で保存済みの接続を名前で指定し、アプリがSSMセッションを開いて文を実行し、返っていくのは結果セットだけです。エージェントがAWSプロファイルも、エンドポイントの認証情報も、データベースのパスワードも受け取ることはなく、db_queryはその接続が人間に何を許していようと読み取り以外を拒否します。
こちらもおすすめ
データベース接続
MySQLとMariaDBの接続を保存し、SSHトンネルやAWS SSMセッション経由でプライベートサブネット内のデータベースに到達して、AIエージェントにMCP経由でクエリさせましょう。デフォルトは読み取り専用、1回の呼び出しにつき1文、結果セットには上限があり、パスワードがエージェントに届くことはありません。
SSH接続
SSH接続を保存し、内蔵のSSHターミナルを開いて、Claude Code、Codex、Antigravity CLIをリモートサーバーやVPS上で直接実行できます。SSH鍵またはパスワード認証、プロジェクトごとの接続プロファイル、別のSSHクライアントは不要です。
シークレットマネージャー
APIキー、トークン、パスワードをOSのキーチェーンに保存し、開発コマンドやエージェントの環境変数では{{secret:NAME}}として参照すれば、AgentsRoomが起動時に解決します。エージェントに見えるのは名前だけで、値が渡ることはなく、サーバーに同期されるものもありません。
リモートフリート
所有するすべてのMacでClaude、Codex、Antigravityコーディングエージェントを実行し、チームメイトを招待して同じエージェントでリアルタイムにコラボレーションします。オフィスのマシン、自宅のマシン、ビルドサーバー、共有チームプロジェクト：すべてが単一の統一されたエンドツーエンド暗号化ビューに表示されます。
誰も到達できないデータベースをクエリする
AgentsRoomをダウンロードし、AWS SSM接続を保存して、MySQLまたはMariaDBのデータベースをそこに向ければ、踏み台もVPNも共有パスワードもなしにプライベートなRDSインスタンスをクエリできます。
コンパニオンアプリ：外出先でもエージェントを確認
Claude、Codex、Antigravity CLI、またはその他の AI プロバイダーを使用します。
バグや要望を公開バックログに直接送信できます。
実際の AgentsRoom の様子。