プロローグ
これは、生成 AI という強大な力に魅了された私が、一度は主体性を失いかけながらも、再び自分の足で歩き出すまでの物語です。
第 1 幕 「全能」 ～ AI となら何でもできる～
旅の始まり
SQL チューニングができるエンジニアってかっこいいですよね。SQL チューニングができるとわかると、その人の魅力が 3 割増しに見えてきます。
そんな憧れのスキルを身につける機会が、唐突に訪れました。Azure のデータベース資格である DP-300 の学習を始めたのです。その試験範囲に SQL のパフォーマンスの最適化も含まれています。生成 AI の助けを借りれば、案外すぐものになるかもしれません。
どうせなら今流行りの AI エージェントを作ってみよう。AI に自律的にデータベースを操作させれば、ボトルネックの特定から改善案の提示まで全自動化できるはずだ。そう考えた私は、AI と共に歩む SQL チューニングの旅に出ることにしました。
最強のツールを求めて
まずは既存のツールを探してみましたが、私のニッチな要望（実行計画を LLM が解釈しやすい形に加工して分析させたい）を満たすものは見つかりませんでした。
「ないなら作ればいい。私には AI がついている」
そう考え、SQL Server のチューニングに特化した MCP サーバーを自作することに決めました。AI に指示さえ出せば、専門的な知識が必要なツール開発もあっという間に終わるはずです。
約束された勝利
作りたいのは、クエリの実行履歴から高コストなクエリを取得したり、実行計画のサマリを取得したりするツール群です。さらに、それらを活用してパフォーマンス分析を行う GitHub Copilot 用カスタムエージェントも定義します。
コーディングは GitHub Copilot に任せます。こういうのを作りたいと伝えた後に仕様について何往復かやり取りをしてゴーサインを出したら、あっという間に実装が進んでいきます。素晴らしい。
この調子なら、当初の想定よりも短期間で完成しそうです。輝かしい未来の到来は、ほぼ約束されたも同然に思えました。どんどん進めていきましょう。
第 2 幕 「暗雲」 ～"正解"がわからない～
仕様が決められない
開発を進めていく中で、判断に困る場面が出てきました。
例えば、この MCP サーバーの肝となるのは、実行計画の巨大な XML の中からチューニングに役立つ情報をどういう基準で抽出してどんな形式のレスポンスにするかです。1MB を超えることもある XML を、数十 KB 程度の JSON にして返します。情報損失を前提に、優先度の高い情報の線引きが必要です。
GitHub Copilot は賢いので、仕様に曖昧な点があると事前に詳細の確認をしてくれます。こういう時は、自分が SQL をチューニングする立場だったとしてどんな情報が欲しいかを想像して判断すればいいでしょう。
しかし、知識も経験もないので半分ぐらい勘で答えるしかありません。そもそも、質問の中で登場した用語の意味さえもよくわかっていない状況です。
レビューができない
カスタムエージェントの定義ファイルを作成していくときのことです。AI に与える各種の指示は、以下のようなフィードバックのループを回すことで徐々に質を高めていきます。
- 実際に動かしてみる
- そのアウトプットをレビューして改善点を洗い出す
- 与えた指示の何が悪かったのかを分析する
- 指示を改善する
しかし、この中のステップ 2 のレビューを行うことができませんでした。もっともらしい出力のため、すべて正しいように見えてしまいます。実際、内容は概ね的を射ているはずです。ですが、改善の余地がないわけもありません。
普段の業務で AI に指示を出すときには、そんなことは起きません。自分の中で成果物のイメージがすでにできているので、それと照らし合わせて出力の良し悪しを判断できます。妥当なので受け入れるか、問題があるのでやり直すかの二択です。どちらとも言えないという選択肢は存在しません。
そう考えると、クエリの最適化のプロンプトを改善する場合なら、どう改善すればいいのかの自分なりの正解をあらかじめ用意しておく必要があります。ですが、それを自力で導き出すスキルがないのです。
AI に AI の正誤を聞く
このようにして自分で判断することに困った現代人が次にやることは何でしょうか。
そうです、AI に質問するでしょう。例に漏れず、私は ChatGPT を開き、いま直面している問題について相談します。すると、数秒待つだけでわかりやすい解説をしてくれました。疑問がみるみる氷解していきます。
これで問題は解決したので、私はまた鼻歌まじりで開発作業を再開したのでした。
第 3 幕 「疎外」 ～私はただの伝書鳩～
思考停止の伝言ゲーム
その後も継続的に AI に相談しながら開発を進めていました。最初は設計や仕様についての対等な相談相手という立ち位置のつもりでした。しかし、やり取りを繰り返すうちに、自分で調べて考えるより AI の回答をそのまま受け入れたほうが早いし精度も高いだろうと思い始めました。
そして、最終的には半ば思考停止状態でほぼ全ての判断を AI に委ねるようになりました。そんな現状に対して違和感を覚えることはありましたが、このやり方が効率的で理にかなっているのだと言い聞かせ、心の声に耳を傾けませんでした。
ChatGPT や Claude に仕様を決めてもらい、それを GitHub Copilot に伝える。GitHub Copilot から実装上の方向性や要件について確認を依頼されたときには、その内容を ChatGPT に伝えて回答を受け取り、それをまた GitHub Copilot に返す。
いつの間にか、私は単なる AI の使いっぱしりに成り果てていたのです。開発プロセスにおいて、情報を受け渡すだけの役割しか担っていません。もはや関与していないも同然です。少なくとも何の付加価値も生んでいません。
完璧な進捗グラフ
その間もみるみるうちに機能は着実に拡充されていきます。Git のコミット履歴だけを見たら開発は順調そのものです。
問題点を挙げるとしたら、その改修の方向性が正しいのか間違っているのか、もはやよくわからなくなってきたというだけです。自分がここにいる意味って何だろう、そんな疑問が脳裏をよぎることがあるというだけです。
疎外される開発者
厳密には不正確かもしれませんが、ただただ AI の言うとおりに行動して人間としての主体性や創造性を全く発揮していないこの状況は、疎外1と形容してよいと思います。
この単語は、学生時代に世界史か何かの教科書で「資本主義によって労働者が非人間的な境遇に追いやられている」といった文脈で知りました。自分には無縁だと思っていたその言葉が、急に生々しいリアリティを帯びてきました。
ただ、救いはあります。資本家と労働者の関係とは異なり、AI は私から主体性を強制的に奪い取ったわけではありません。私はある種の合理的な判断によって、自らの主体性を自分から AI に委ねたのです。その委譲が無意識のうちに行われたので、あたかも AI に人間性を奪われたように感じてしまっただけです。人間が主体性を保持し続けるという選択肢も確かに存在しているのです。
第 4 幕 「回帰」 ～失った主体性を取り戻す～
砂上の楼閣
ここまで思い至って、ようやく私は我に返りました。今やるべきなのは AI に言われるがままに MCP サーバーを作って戯れることではありません。そんなことをするより、学ぶべき基礎が山ほどあります。
- RDBMS の構成
- SQL アンチパターン
- B-Tree のデータ構造
- Nested Loop と Hash Join と Merge Join の違い
- Table Scan, Index Scan, Index Seek, Key Lookup の違い
結局、こうした本質的な内容を腰を据えて勉強することが億劫なので、変に楽をしようとして AI に丸投げして逃げていただけだったのです。
よく言われていることですが、AI の性能は使い手/作り手のスキルレベルに大きく依存します。常識的に考えて、SQL チューニングをやったことないどころか RDBMS の基本知識すら知らない人が、SQL チューニングの専門家であるカスタムエージェントをまともに作れるとは思えません。
「基礎まで」学ぶ
とはいえ、最初に MCP サーバーという動くものを作るという応用から学習を始めるアプローチが間違っていたとも思いません。本当に問題だったのは、基礎をおろそかにしたまま応用に固執していたことです。
生成 AI の登場によって、基礎をすっ飛ばして応用的な内容から学習を行うトップダウン的なアプローチが容易になりました。従来の積み上げ型の学習に比べて、最初に全体像や活用事例のイメージを掴んだうえで知識を有機的に結び付けながら学習を進められるので、格段に知識の吸収効率が高まります。
一方で、応用の上澄みだけ知ってわかった気になって満足してしまう危険があります。また、そもそもの基礎知識がないので AI の内容を無批判に受け入れてしまいがちです。
だからこそ重要なのは、AI のもっともらしい説明に疑問を持って掘り下げていく姿勢です。「基礎から学ぶ」のではなく「基礎まで学ぶ」時代になりつつあります。植物が根を下に伸ばしていくように、学習も下に下にと掘り下げていきましょう。強固な根を張っているからこそ、上に成長して花を咲かせることができるのです。
大いなる力と責任
幸か不幸か、生成 AI は我々に大きな力を与えました。制御しきれなくなるほどの巨大な力を、特別な資格も要求せず等しく全員に。そして、システム開発の世界において、その力を使わないという選択肢はもはや存在しません。
我々は、その重みを改めて自覚しなければなりません。sudo コマンド実行時に表示される「With great power comes great responsibility.」という一節を思い出してください。大いなる力には、大いなる責任が伴うのです。
「AI がやったことだから知りません」なんて無責任な態度は許されません。なぜそのような仕様・設計を選択したのかを自らの言葉で説明する責任があります。AI が書いたコードにバグがあれば、それはコミットしたあなたの責任です。
エンジニアの復権
AI を使えば誰でも動くシステムを作れるようになった現在において、IT エンジニアに何が求められるでしょうか。
技術面に関しては、確かな技術知識や経験をもとに AI の手綱を握ってその性能を最大限に引き出す能力が必要です。それができず AI に従うだけなのであれば、存在価値がありません。
一方では、これはエンジニアにとって厳しい時代になったと言えます。システムを作ることそれ自体の価値が大きく低下したので、それ以外のどんな付加価値が提供できるのかを追求し続けなければならなくなったからです。日々の学習の重要性は増したと言っていいでしょう。
しかし、他方では明るい希望もあります。生成 AI という大いなる力を思う存分に活用できたなら、プロダクトの量も質も格段に向上します。疎外されている場合ではありません。エンジニアとしての仕事は、今までよりももっとクリエイティブで楽しいものにできるはずです。
エピローグ
今回の SQL チューニングの AI エージェント作成の取り組みは、残念ながら現時点でうまくいっていません。愚かにも基礎を軽視して AI を妄信してしまいました。
でも、後悔はしていません。こうして AI との向き合い方や日々の学習について考え直す機会を得られたからです。それに、実行計画を集約する MCP サーバーというアイディア自体は今でも悪くないと思っています。
また強くなって、リベンジします。