SaaSインフラをAI中心で構築した経験から、従来の自分の思考を再評価し、AIと適切な距離感で開発を進めることの重要性について考察します。
数ヶ月前、私は自分のSaaSのために新しいインフラを構築する必要がありました。従来のPHP＋MySQLの組み合わせは、もはや目的に合わなくなっていたのです。新しいLLM（大規模言語モデル）を活用する絶好の機会だとワクワクしながら、本来のソフトウェアエンジニアの役割は一旦横に置き、プロダクトマネージャーのように振る舞いました。Claude（AIチャット）とベストプラクティスについて対話し、自分でも調べては計画を練り直し――何度もやりとりを重ね、最終的にGoとClickhouseを選びました。
実際にコーディングを始める段階になると、Claudeに頼み、自分の現行インフラ、新インフラ、目指すものやその理由などをまとめた大きく複雑なMarkdownファイルを作成してもらいました。
それを全部Cursor Notepadsに入れて、プロンプトを打ち始めます。Cursorはコードを書き、私はそれを構築しテストする。全体的には満足でした。コードベースが最もきれいだったわけではありませんが、動いているように見えます。私が重視していたのはスピードであり、コードの整然さではありませんでした。SaaSのビジネス顧客から「特定のデータが必要」と言われていて、この新しいインフラでしかそれが実現できない状況だったのです。さらに、リリースを待っている見込み顧客も複数おり、完成の連絡を待っています。毎日リリースが遅れるごとに、お金を失っている感覚がありました。
しかし、数週間が経つと、徐々に綻びが見えてきます。日々、完成に近いと思っては新たな問題が見つかり、何日も足止めされる。その繰り返しで苛立ってきました。
「GoもClickhouseも初めて触るのだから、時間がかかるのは仕方ない」と自分に言い聞かせていましたが、問題は続き、苛立ちは増していきます。Cursorも以前ほど助けになりません。エラーメッセージを貼ると修正案は返ってくるのですが、どこか別の箇所でまた何かが壊れます。問題が複雑になるほど、LLMからまともな解答を得るのは難しくなります。
そこで自分の目でコードをじっくり見て理解しようと試み始めました。私は15年の経験を持つソフトウェアエンジニアで、学生時代にはC++やJavaも学んできました。だからGoファイルで何が起きているかおおまかには分かります。しかし、GoやClickhouseのベストプラクティスとなると全く知見がありません。
そこで、これらについて地道に勉強を始めました。ドキュメントを読んだり記事を読んだり、YouTubeでClickhouseの動画を観てみたり。Claudeにもより深い質問を投げ、回答を吟味するようになりました。
ある朝、Cursorが自動生成したコードをじっくり観察してみようと決めました。最終成果物を全く見ずに“盲目的”にプロンプトを書いていたわけではないのですが、とにかくスピード重視で、腰を据えてコードレビューしたことがなかったのです。
なので、「コードレビュー会」をやってみた結果――恐怖体験が始まりました。
同じディレクトリに、似た名前のサービスファイルが2つ。どちらも明らかに似たような役割。でもメソッド名が違う。プロパティ名も統一されていない。「WebAPIprovider」と「webApi」、まったく同じパラメータなのに…。同じメソッドが複数ファイルに重複して宣言されている。コンフィグファイルの呼び出し方もバラバラ。
一貫性ゼロ、全体設計もなし。まるで10人のジュニア〜中堅エンジニアにGitなしで同時に部屋に閉じ込めて書かせたみたいなカオス。
「LLMsには十分コンテキストを与えていましたよ」と問いたくなるかもしれませんが、Geminiの広いコンテキストウィンドウを活用し、類似ファイルを参照指定するなど工夫はしていました。それでも足りなかったのです。
ここで明らかになったのは、アプローチを変える必要があるということ。私は何よりソフトウェアエンジニアです。自分自身のスキルを活かさないのは愚かだと思い直しました。GoとClickhouseも勉強し直し、一度猛スピードで進める手を止めて、ファイルを丁寧に見直しつつコードを書き直しています（全部じゃなく、吐き気を催す部分だけ）。言語こそ違えど、「どうしたいか」「どう整理すべきか」は自分の中で明確になっています。
少し立ち止まった結果、デバッグも容易になりました。速度こそ落ちたかもしれませんが、「自分で書いたはずなのに中身が分からない」妙な感覚はなくなりつつあります。LLMも引き続き使っていますが、「このパラメータ名を全部リネームして」とか「この擬似コードをGoで書き直して」みたいな単純作業に使っています。
いちばん大変だったのは“AIを使いたくなる衝動”を抑えること。最高のツールが手元にあり、10ファイルなんか一瞬で書けてしまう。それを使わずにいることは「時間を無駄にしてる」気がしてなりません。そのとき気づいたんです。**自分の脳みそを使わなくなっていたことに。**無意識のうちに何でもAIに頼る癖がついてしまっていました。
ペンとノートを使わなくなり、新機能の設計さえも、真っ先に「o4-mini-high（AI）に聞こう」となってしまう。これが本当にイヤで、やめる決意をしました。
AIによる影響を心配してはいます。でも「仕事を奪われる懸念」ではなく、「知的鋭さ」や「設計力」「きれいで機能的なコードを書く力」が損なわれることを、心配しています。
そこで、思い切ってAI利用を大幅に制限し始めました。最初の設計やファーストドラフトは必ず自分の頭で行い、分からなければ「これで良いか？この命名規則は適切か？ここの仕上げ方は？」くらいをLLMに確認しています。
ただ、ゼロから新しいものを書かせたり、アイディアや新しい設計を丸投げすることはやめました。設計は自分の役割、私はシニア開発者、LLMはアシスタントです。
アプローチを変えたことで、LLMに対して苛立ちを感じなくなりました。期待値が下がったぶん、上手くいくと純粋に嬉しくなります。効果的な使い方を模索しつつ、学習ツールとしてLLMは非常に優秀なので、Goの上達やスキルアップに活用。その知識で実装しています。
ただ、「非エンジニア」は逆にAI時代になって困るのでは？とさえ思います。ノーコードツールなら人間の常識で設計されているぶん、機能は限定されても構造は多少分かりやすいですし。
“Vibe coding”、つまり“コーディング経験ゼロでAIに任せる開発”は、プロトタイプレベルならともかく、本番向けシステムを作るには「破滅のレシピ」です。
Cursorでコーディングする非エンジニアの辛さは、容易に想像できます。意味不明なコードの壁、エラーの山をコピペしても、返されるのは更にカオスなコードや間違いで、どんどん収拾がつかなくなる。最後には直せなくなる――そんな状況です。
「最新のモデル使えよ！」「Cursorルール使えよ！」「Redditで見た15ステップワークフローをやれ！」……そんな声が思い浮かびます。
全部試しました。でもAIにしかできないこと、今はまだ無理なことが確実にあるんです。
全てのツールやワークフローをくまなく試したわけではないですが、この経験を通じて実感があります。信じられないなら、Clickhouse未経験者が、100万行以上のテーブル群をまたぐ複雑なクエリ生成をLLMに丸投げして、しかも限られたRAM上でメモリエラーなく動かそうとしてみてください。
全SQLスキーマを渡しても、最新マニュアルを参照しても、業務要件やインフラ制約を細かく伝えても、Geminiでもo4-mini-highでもo3でもSonnet 3.7でも、現状不可能です。
そして、長時間かけてAI向けセットアップをしても、「土台は家だけど上はトランプタワー」みたいな仕組みしか作れないのなら、その手間に本当に見合うのか？さらにモデルの動作が安定しないので「完璧なワークフロー」が見つかっても、すぐ使えなくなったり微妙にズレることもしばしば。
私は新技術好きのアーリーアダプターで、AIにも大いに期待し、熱心に追っています。でも今の段階は「すごく良さそうに見えるけど、実は“惜しい”レベルでしかなく、むしろ私たちを馬鹿にしてしまう危うさすらある」そんなフェーズです。
この感覚は不思議です。目的地に行くのに、徒歩も選べる一方、ハンガリー語と古典ギリシャ語でしか操作できない巨大宇宙船も選べる。手探りで何とか飛ばせるかもしれないけど、果たして歩いた方が楽だったんじゃないか？と最後は思ってしまう。
さらに厄介なことに、世の中ベンチマークや影響力のあるインフルエンサーが「魔法のシャベル」を売りつけ、次から次へとAI製品企業は“エージェント”だの“違う仕組みだ”と煽ってきます。
時にはLLM提供側にも、ガスライティングされている気すらします。AI系サブレディットを見れば、同じモデル同じプロンプトなのに正反対の体験談が日々並びます。十分に長くAIでコーディングをすると分かりますが、ある日は天才、翌日はバカみたい……。
GPUを絞っているのか？制御不能なのか？一体どうなってるのか？
