AWS MCP Serverで実践するText-to-SQL

Transcript

1. AWS MCP Serverで実践するText-to-SQL 気付いたら仕様駆動開発になっていた話 2025年12月16日 エンタープライズクラウド本部 Kotaro.S @社内勉強会
2. 自己紹介 2
3. 1. イントロ 2. 用語整理 3. Text-to-SQLを実践する 4. 考察 5. 注意事項とTips アジェンダ 3
4. 1. イントロ 2. 用語整理 3. Text-to-SQLを実践する 4. 考察 5. 注意事項とTips アジェンダ 4
5. SQLは得意ですか？😊 1. イントロ 5
6. 安心してください。私は苦手です😊 1. イントロ 6
7. 個人的なSQLに関する経験値（前提） 「書けなくはないけど、とても得意とは言えない（むしろ苦手） 」 基本的な集計用途の構文は自力で書ける（SELECT/WHERE/GROUP BY/JOINなど） トランザクションや正規化などのRDBMSの基礎的な概念は理解している 1. イントロ 7
8. 個人的に苦手なポイント: プログラムは考え方が違う（宣言型vs.手続き型） セルコが正しく言い当てたように、SQLの考え方を習得するときに最大の障壁となるのが、私たちが慣れ親しんだ手続き型言語の考 え方です。 具体的に言えば、代入・分岐・ループを基本的な処理単位として、システム全体をこの基本的な処理へ分割する発想です。 同様に、ファイルシステムもまた、大量データをレコードという小さな単位に分割して扱います。どちらにも共通しているのは、複 雑な処理を単純な処理の組み合わせと見なす還元論的な考え方です。 SQL の考え方は、ある意味でその対極を行きます。SQL には代入やループなどの手続きは一切現れませんし、データもレコードで はなく、もっと複合的な集合の単位で扱われます。 　言ってみれば、SQL とリレーショナル・データベースの発想は、どちらかとい うと全体論的なのです。 SQL を無理やり手続き的に組もうとすると、読むに堪えない長大で複雑な SQL になるか、安易にプロシージャとカーソルに手を出 して、慣れ親しんだ手続き型の世界へ舞い戻ることになります。 https://mickindex.sakura.ne.jp/database/db_laws.html 1. イントロ 8
9. 開発で使用する時に個人的に難しいと思うこと 「書きながら考える」は通用しない（あるべきデータの状態を理解していないと書きにくい） 普段書くことが殆どないので、シンプルにSQLの実装は大変（学習コストが高い） （SIer的には）要求理解と実装を両立するのは時間的な制約も気になる 1. イントロ 9
10. 発想: あるべき状態を考えることに注力して 実装はAIに任せればいいでは？ （ ✕ : 責任分解 〇: 責任共有） 1. イントロ 10
11. 💡 Text-to-SQLという考え方があるらしい 1. イントロ 11
12. MCP ServerでText-to-SQLを試したら 結果的に仕様駆動開発の理解が 進んだ話をします🫶 1. イントロ 12
13. 1. イントロ 2. 用語整理 3. Text-to-SQLを実践する 4. 考察 5. 注意事項とTips アジェンダ 13
14. Text-to-SQLとは？ SQLを発行し、洞察を得るという一連のプロセスを自然言語だけでできるようにする技術の総称 https://cloud.google.com/blog/ja/products/databases/techniques-for-improving-text-to-sql/ 主にBIツールやRAGなどのビジネスレイヤとDWHなどの技術レイヤの緩衝材として期待される(主観) 概念なので、特定のソリューションや技術スタックを指すものではない 2. 用語整理 14
15. Text-to-SQLに必要なもの 自然言語からSQLを生成するために必要なもの 1. AIエージェントとLLM 2. AIエージェントがSQLを投げるインターフェース（APIのラッパースクリプトなど） 3. テクニカルコンテキスト（存在するスキーマやテーブル、カラムの情報） 4. ビジネスコンテキスト（テーブルに存在するデータの性質を説明するもの） 5. ビジネスロジック（SQLで実現したいこと） → 2と3を言語化するのは大変。MCP Serverで解決できる → 4と5は人間の仕事（AIに丸投げで正解を出せる可能性は低い） 2. 用語整理 15
16. MCP Server(Model Context Protocol Server)とは？ AI(LLM)が外部のツールやデータを呼び出すための仲介となるプロトコル Resource: ナレッジベースへのアクセスの仲介 Prompt: 再利用可能なプロンプトの提供 Tool: 実際の操作(API呼び出しなど)を仲介 Text-to-SQLで活用するという意味では、Toolが重要 JDBCやAPI経由でSQLを実行できたり、データカタログにアクセスできたり、LLMが扱いやすい 形で戻り値を返してくれたり 2. 用語整理 16
17. 最近のAWSのMCP Server事情 re:Invent 2025で「AWS MCP Server」のプレビュー版が発表された https://aws.amazon.com/jp/about-aws/whats-new/2025/11/aws-mcp-server/ 一方で、発表以前からAWSはGitHubでローカル版のMCP Serverを公開していた AWS API MCP Server https://awslabs.github.io/mcp/servers/aws-api-mcp-server AWS Knoledge MCP Server https://awslabs.github.io/mcp/servers/aws-knowledge-mcp-server → この資料では、後者のうちAWS API MCP ServerをAWS MCP Serverと呼んでいる （前者が今後スタンダードになっていくと思われるので、今後に期待） 2. 用語整理 17
18. AWS MCP Serverを経由してRedshiftにアクセスするイメージ ※引用: https://aws.amazon.com/jp/blogs/news/accelerating-sql-analytics-with-amazon-redshift-mcp-server/ 2. 用語整理 18
19. 1. イントロ 2. 用語整理 3. Text-to-SQLを実践する 4. 考察 5. 注意事項とTips アジェンダ 19
20. 試してみたこと Redshiftに存在する複数のテーブル(億単位のレコード)から統計データを作成する 人間はDFDとSQLの仕様書を作成する AIはSQLの実装および単体テスト(サブクエリ単位の結果検証)を行う AIがテストした内容は人間が再現可能な状態とし、人間目線で妥当性の検証を行う 要件定義 設計 実装 単体テスト テスト結果の妥当性検証 人間 〇 〇 〇 AI 〇 〇 3. Text-to-SQLを実践する 20
21. 処理の複雑さのイメージ（DFD） ※ イラスト化したもの 3. Text-to-SQLを実践する 21
22. 仕様書のイメージ 過程のテーブル毎に選択カラム、抽出条件、グルーピング条件、名寄せ条件など 実装レベルの条件を詳細に定義する データ項目 値・式 column_A A.column_A, B.column_A, C.column_A column_B D.columnB(A/B/C.XXXから名寄せ) column_C D.column_C(A/B/C.XXXから名寄せ) column_D "XXX" (固定値) column_E グルーピング後のcolumn_Eの合計 導出元テーブル テーブルA (A) テーブルB (B) テーブルC (C) 名寄せテーブル (D) 選択条件 (なし) グルーピング条件 column_A, D.column_B, D.column_C 3. Text-to-SQLを実践する 22
23. 開発の流れ ※Kiro CLI(claude-opus-4.5)を利用 1. 人間: DFDと仕様書（抽出条件やグルーピング条件）を固める 2. 人間: 仕様書をMarkdownで成形し、Kiro CLIが読み取り可能な状態にする 3. AI: 仕様書で言及されているテーブルのメタデータをAWS MCP Server経由で読み取る 4. AI: 仕様書とテーブルのメタデータを総合して、SQLを実装する 5. AI: 実装したSQLの単体テスト用のコードを生成して検証する(テーブル単位で作成) 6. 人間: AIの実装内容とテスト結果の妥当性を検証する 3. Text-to-SQLを実践する 23
24. 開発のイメージ 3. Text-to-SQLを実践する 24
25. AWS MCP Serverの仕様についての補足 Writeモードが2025年12月現在では実装されていない。 実行可能な命令はSELECTなど読み取り専用 書き込み系のロジックは一時テーブル(CTE)を使って検証させる Redshiftの認証はAWS MCP Serverに渡すプロファイル経由でIAM認証となる いつWriteモードが実装されるかもわからないので、DBユーザにはSELECT権限だけ与えると安全 ※参考: https://aws.amazon.com/jp/blogs/news/accelerating-sql-analytics-with-amazon-redshift-mcp-server/ ※Kiro CLIのmcp.jsonの設定内容 { "mcpServers": { "awslabs.redshift-mcp-server": { "command": "uvx", "args": ["awslabs.redshift-mcp-server@latest"], "env": { "AWS_PROFILE": "<AWS CLIのプロファイル名>", "AWS_REGION": "ap-northeast-1", "FASTMCP_LOG_LEVEL": "INFO" }, "disabled": false, "autoApprove": [] } } } 3. Text-to-SQLを実践する 25
26. プロンプトの例(抜粋) テストの粒度と完了条件を明示して、テーブル単位でテスト用のSQLを生成させる <仕様書>.mdはRedshiftでデータを加工するSQLの設計を定義したドキュメントです。 このドキュメントに沿って、PL/pgSQLを実装してください。 以下の指示を必ず守ってください。 Redshiftで実際にクエリをしながら妥当性を検証のうえ作成してください。 【ドキュメントには書かれていない仕様】 ・出力するテーブルは、処理前にデータがあればTRUNCATEする仕様にしてください（常に上書き） ・pl/pgsqlは、全て1つのトランザクションにまとめてください 【pl/pgsqlの引数】 ・スキーマ名(schema_name) 【入出力のマッピング】 ドキュメントの入出力は、以下のスキーマにあるテーブルと読み替えてください。 <テーブルの論理名と物理名のマッピング> 【テスト要件】 ① 単体テスト：実装したクエリが設計書の要件を満たしていることを確認してください。 ② 結合テスト：①のクエリを1つのクエリとして結合し、全体として機能することを確認してください。 ③ ①の累計レコードと②の累計レコードが一致することを確認してください。 ※書き込みについて あなたにテーブルの書き込みは許可されていません。 PL/pgsqlにはINSERT INTO~などの書き込み操作が必要と想定されますが、各テストは読み取り専用で実施してください。 書き込みについてはテスト不要です。 【テストに通過しなかった場合の作業内容】 テストに通過しなかった場合、設計書の「グルーピング条件」については実装と設計書を特に許可なく修正しても構いません。 それ以外の修正については、修正する前に一度確認を入れてください。 ただし、修正した内容はテスト結果のサマリに記載してください。 3. Text-to-SQLを実践する 26
27. 人間がやったAIのアウトプットの妥当性検証の例 SQLが仕様書の内容通りの実装になっているかのレビュー 単体テストのSQLの計算結果が想定通りか（何件かサンプリングして手計算するなど） 設計～実装～テストまでの1サイクルを回した結果 人間がドキュメンテーションに注力した結果、AIの実装結果は極めて正確なものだった 人間が実装を修正した箇所はログの文面やコメントなど軽微なもののみで、処理結果の不備は0件 逆に、実装から仕様書への逆フィードバックが1件（仕様書からグルーピング条件が1件漏れていた） 3. Text-to-SQLを実践する 27
28. 1. イントロ 2. 用語整理 3. Text-to-SQLを実践する 4. 考察 5. 注意事項とTips アジェンダ 28
29. 任せてわかった、AIの守備範囲 ビジネス要件を押さえて、仕様を言語化できれば実装はAIに任せてもいいと確信できる結果になった 人に任せることと本質的には同じ(任せる側が成果物に対して責任を持てること) 人間が責任を持つべきこと ドキュメンテーション ビジネス要件を踏まえた処理条件の 言語化 機能面のレビュー 要求や要件を満たしているか 非機能面のレビュー パフォーマンス、堅牢性、保守性 AIに任せてもいいこと 実装(それに関するトラブルシュート) 精緻なドキュメントを必要とする 静的テスト 構文チェックなど、Linter的な役割 動的テスト プロセスごとにテスト用のコードを 都度書かせて再現性を持たせる 4. 考察 29
30. そうはいっても、限界はある 仕様を完全に言語化することは難しい 実装はAIに任せられるという安心感があれば、言語化に時間を割く意思決定ができる 仕様が流動的だと、成果物も流動的になる危うさ 仕様の流動性が低い（要件が明確で、変動するリスクも低いこと）が適用する条件かもしれない 仕様の言語化や非機能面のレビューで人間に一定の知見が必要になることは変わらない AWS MCP Serverの有用性 テクニカルコンテキスト（構成やテーブルの型・制約）の収集をAWS MCP Serverに任せられた ビジネスコンテキストの蓄積や収集には、専用のデータカタログサービスが必要かも Glue Data Catalogはテクニカル面のメタストアという性格が強い 4. 考察 30
31. バイブコーディング vs. 仕様駆動開発 (自覚していなかったが)実践したことは、要するに仕様駆動開発的な思想だったのでは？ 仕様駆動開発をしていたつもりが、バイブコーディングになっていたということにならないように 「どちらが優れているか」ではなく 「どちらが求められているのか」 の見極めは重要 要求や要件が明確な開発では、今回話した内容がハマりやすい(銀の弾丸ではない) 4. 考察 31
32. 1. イントロ 2. 用語整理 3. Text-to-SQLを実践する 4. 考察 5. 注意事項とTips アジェンダ 32
33. 注意喚起: 責任ある生成AIの利用を セキュリティ規約を遵守し、顧客やサービスオーナーなどの関係者と合意を得ること ※例として、以下のようなもの 1. 社内で利用が許可されたサービス(学習に使用されないことが担保されている)だけを利用する 2. 開発に生成AIを利用する場合、必ず顧客またはサービスオーナーの許諾を貰う 3. クライアントワークなどで社内にデータを持ち出す場合、必ずデータの持ち出しに対する許諾を貰う 注意事項とTips 33
34. Tips(1): 仕様書がExcel方眼紙だったらどうするの？ pdf化してGemini3.0にMarkdownへの変換を依頼するとほぼ修正不要の精度で変換できる Workspace環境など社内で利用が許可された環境でするように(野良はだめぜったい) Tips(2): どれくらい要件が明確だったら適用できるの？ 今回の事例で使用した仕様書の特徴をAIに要約してもらった 注意事項とTips 34
35. まとめ AIエージェント × MCP Server × ドキュメンテーションでText-to-SQLな開発ができる Not 責任分解, but 責任共有(こいつがやったんです！と言ってもAIは責任をとってくれない) エンジニアの役割がビジネス要求の言語化と成果物の品質保証にシフトしている気がする 実装する楽しさがAIに持って行かれている感じがするのはちょっとかなしい(お気持ち) おわりに 35