さとうです。
初ブログとして、先日社内勉強会で登壇させて頂いた資料の共有をしたいと思います。
資料の全編はこちらからご確認いただけます。
ブログでは資料の内容を紹介させてください！
イントロ
みなさん、SQLは得意でしょうか？私は苦手です。
普段プログラムを書く人がSQLの実装となると苦戦することもあるかもしれません。
個人的に、SQLの馴染みにくさの1つに宣言型の言語という特徴があると考えています。
あるべき状態を宣言的に記載する必要がありますから、正しいデータのあり方を理解できていないと表現のしようがありません。
逆説的に、正しいデータのあり方を人間が正しく理解してコンテキストとして提示できればAI駆動で開発をすることは十分に可能であるとも考えていました。
その具体的な手法としてAWS MCP Serverを使いText-to-SQLを開発に応用できないか検証したところ、結果的に仕様駆動開発になって効果や成立条件を理解するきっかけになった…という話をしたいと思います。
ここで重要なのが、AIと人間の責任分解(分業)ではなく責任共有と考えることです。
用語整理
Text-to-SQLとは？
読んで字のごとく、自然言語からSQLを生成する技術の総称です。
特定の技術スタックを指すものではないことに注意してください。
一般的にはBIの文脈で自然言語から洞察を得るための技術として語られることが多いですが、開発者にとっても有用な技術と考えています。
Text-to-SQLを実現するにはAIエージェントにテーブルのメタデータなどのテクニカルコンテキストを与えることも勿論ですが、それと同時にSQLのユースケースやデータの意味合い、加工の順番やロジックなどの仕様を記載したビジネスコンテキストを与えることが重要です。このコンテキストが曖昧または不足していると、ハルシネーションのリスクも大きくなります。
データカタログに情報を集約するなど方法は考えられますが、現時点ではビジネスコンテキストを生成AIが能動的に理解することは原理上難しいものと考えます。
ですので、プロンプトないしドキュメントでそれらを補うのは人間の仕事になります。
AWS MCP Serverとは？
re:Invent2025でAWS MCP Serverのプレビュー版が発表されましたが、この資料で言うところのAWS MCP Serverはそちらではなく、AWSが提供しているローカル版のAWS API MCP Serverを指しています（以後、AWS MCP ServerはAWS API MCP Serverを指しているものと理解してください）。
いずれにせよ重要なのは、AWS MCP Serverを活用することでText-to-SQLに必要なテクニカルコンテキストを与える作業が楽になるということです。
具体的にはRedshiftのスキーマやテーブルを読ませたりSQLでクエリを発行してテーブルのデータを調べるといった作業を自律的に行わせることができ、これらから得られる情報をプロンプトから与える手間を省略することができます。
Text-to-SQLを実践してみた
実際にText-to-SQLの発想を開発で応用可能か、検証してみました。
検証に使用したもの
検証に使用するクエリはRedshiftで複雑な計算を要する比較的複雑なもので、それに対応するDFD(Data Flow Diagram)や仕様書などのドキュメントを用意しました。
開発の進め方
開発にはAIエージェントとしてKiro CLIを使用しました。
AWS MCP ServerでRedshiftのテクニカルコンテキストを収集し、仕様などのビジネスコンテキストはプロンプトやファイルから与える形です。
仕様の取り決めは人間が行う一方、実際の開発はほぼAIに任せています。
クエリに構文レベルのエラーがないか、戻り値が空になっていないかなどの最低限のテストもAIに実施させていますが、テスト用のモック版のクエリ作成を別途指示することで人間がテスト結果を再現可能な状態としています。
AWS MCP Serverの仕様についての注意点
なお、これはAWS MCP Serverの仕様ですがToolとしてWriteモード(書き込み操作)が実装されていないため、MCP Serverを経由して書き込み操作を行うようなことはできません。
ですので、書き込み系のロジックはCTEを使った検証などの工夫が必要となります。
Redshiftの認証はプロファイルからIAM認証される仕様となっており、IAM認証されたDBユーザに対して権限付与が別途必要な点は注意してください。
結果と考察
結果
AIが開発した成果物に対して仕様書との整合性チェックや計算結果の妥当性検証などを実施したところ、その結果は極めて正確なものでした。
処理結果の明らかな不備は0件で、むしろ仕様書の不備についてのフィードバックを受ける結果となりました。
考察
結果から思ったことは、人間がエンジニアリングを発揮するフィールドが実装から、ドキュメントやプロンプトなどの自然言語にシフトしているというものです。
現状の生成AIはその原理から入力するコンテキストの巧拙にアウトプットの品質が左右されるという認識はありましたが、それを実感する結果となりました。
その一方で、非機能的な要求を含めて全ての仕様を完全に言語化することは現実的に難しいという制約もあります。
言語化が漏れた部分のハンドリングに対する責任の所在が人間にあることは明確ですので、レビュワーである人間にもエンジニアリングの知見が求められることは本質的に変わらないと思っています。
「AIが出力した内容を鵜呑みにして人間はドキュメントだけを作っていればいい」ということにはなりません。
バイブコーディング vs. 仕様駆動開発
結果を振り返ると、結果的に取り組んでみたことは仕様駆動開発的な思想だったのではないかということです。
考えておきたいのは、同じAI駆動の開発でもバイブコーディングと仕様駆動開発のどちらを志向するのか、ということです。どちらがいい悪いではありません。
仕様に沿った厳密なドキュメントが求められる開発シーンでは有用ですが、正確性をさておいてコンセプトを実証することが主眼に置かれている開発シーンでは適合しない開発スタイルだと思いました。
注意事項
責任ある生成AIの利用を
本記事で紹介するText-to-SQLを実際の開発に適用する場合、顧客やサービスオーナーなどのステークホルダーと合意を得ることが前提です。
生成AIの利用自体に対する許諾もそうですが、開発環境へのデータの持ち出しが発生する場合はその許可も必要になるでしょう。
所属会社のガイドラインや規約があれば必ず事前に確認するようにしましょう。
まとめ
まとめは資料の通りですが、エンジニアリングを発揮するための表現手段が生成AIの発達で自然言語にシフトしていることを年々実感しています。
この資料について社内で「低級言語から高級言語が主流になった流れと、高級言語から自然言語への移行は同じような流れかもしれない」という感想も頂き、大変興味深いものでした。
技術要素の抽象化が進んだからこそ、原理原則を理解することの重要性を感じています。
今年もたくさん生成AIを使うことになると思いますが、進化が楽しみです。
佐藤 航太郎(執筆記事の一覧)
エンタープライズクラウド部 クラウドモダナイズ課
2025年1月入社で何でも試したがりの雑食系です。
