ハクソク

世界を動かす技術を、日本語で。

数ヶ月間LLMを使ってコーディングした後、再び自分の頭を使うことにします

2025年5月16日原文(albertofortin.com)

概要

  • AIを活用したSaaSインフラ刷新の体験談を紹介
  • GoとClickhouseへの移行で直面した課題と学びを強調
  • LLM（大規模言語モデル）を使った開発の落とし穴と限界を指摘
  • エンジニア自身のスキル活用とAIの賢い使い方を提案
  • ノンコーダーやAI推進派への警鐘と現状のAI開発環境への疑問を提示

AI時代におけるSaaSインフラ刷新の現実と気づき

新インフラ構築の背景とAI活用開始

  • 従来の PHP+MySQL構成 がSaaS要件に合わず、刷新を決断すること
  • 最新の LLM活用 に期待し、プロダクトマネージャー視点で要件整理・計画立案を行うこと
  • Go+Clickhouse の技術スタックを選定し、CursorやClaudeなどのAIツールを積極的に導入すること
  • コード品質よりも スピード重視 で開発を進め、顧客要望への迅速対応を優先すること
  • 開発の遅れが 直接的な機会損失 に繋がる状況でプレッシャーを感じること

LLM活用による開発の落とし穴

  • 開発初期は順調だが、 問題が次々と発生 し、進捗が停滞すること
  • エラー修正をAIに依存すると、 別の箇所で新たな不具合 が発生しやすい現象
  • 問題が複雑になるほど、 LLMの解決力が低下 する傾向を確認すること
  • コード全体を見直すと、 命名規則や設計の一貫性欠如、重複実装、設定ファイルの扱いのバラつき等が発覚すること
  • 十分なコンテキストを与えても、 AI生成コードの統一性確保が困難 であること

自分の技術力を再評価し、アプローチを転換

  • GoやClickhouseのベストプラクティス を自主的に学習し直すこと
  • コードレビューを徹底し、 品質の低い部分を手動でリファクタリング すること
  • LLMの利用範囲を限定 し、単純作業や言語変換など補助的な用途に絞ること
  • 計画や設計、主要な実装は 自身の頭脳と経験を活用 すること
  • AI依存による思考力低下 に気づき、ペンと紙や自力設計を重視する姿勢に回帰すること

LLM利用のバランスとノンコーダーへの懸念

  • 期待値を下げて LLMを学習・補助ツールとして活用 すること
  • コーディング未経験者がAIだけで開発することの 危険性と限界 を指摘すること
  • ノーコードツールと比較し、 AI生成コードの構造的な脆弱性 や混乱のリスクを警告すること
  • コードの意味が分からず、 エラー連鎖に陥る体験 の再現性を問題視すること

AI推進派・AIツールの現状への疑問

  • 最新モデルやワークフローを試しても、根本的な限界が残ること
  • 大規模データや複雑クエリなど、 AIが対応しきれないケース の存在を強調すること
  • 一貫性のない挙動やパフォーマンスの不安定さ が、実運用の障害となること
  • AIツールの導入・運用コストが高い場合、 本末転倒な結果 になる懸念
  • ベンチマークやインフルエンサーによる 過剰な期待煽り、LLM提供者による体験のばらつきへの疑問を呈すること

結論：AIは「魔法の杖」ではない

  • AI技術への期待と興奮 は持ちつつも、現状は「良いが完璧ではない」段階であること
  • 自己の思考力・設計力の維持 と、AIの適切な使い方のバランスを取ることの重要性
  • 「AIに頼り切る開発」は 混乱や品質低下のリスク を伴うため、 人間の主導性 を忘れないこと
  • 未来の進化に期待しつつ、現状のAI開発環境に対しては 冷静な目線で活用すること

Hackerたちの意見

それ、すごく共感できる。今でもLLMをたくさん使ってるけど、今は2つのルールを守ってる。* 深い考えを彼らに委ねないこと。例えば、難しいデザインの問題を考えるときは、自分でやる。* 彼らが生成したコードはしっかりレビューして修正する。行ごとに確認して徹底的に編集するよ。彼らが生成するものは冗長だったり、過剰に防御的だったりすることが多いからね。プロンプトでこれを修正できるかどうかは関係ない。将来のメンテナンス性を自分が責任持ちたいから。「バイブコーディング」（生成されたコードを気にしないこと）は、なんか嫌な感じがする。このアプローチはいい気分にさせてくれる。そして、繰り返しになるけど、今でもたくさん使ってて、コーディングがずっと速くなったよ。

└

生成されたコードを深くレビューして修正する。行ごとに確認して徹底的に編集する。これが問題なんじゃない？これをしなきゃいけないなら、時間を節約できてるの？

└

あらゆる深い分析をAIに委任しているけど、それは具体的な実装ステップや検証基準を持った詳細な計画をデータに基づいた再現可能なレポートで作成するためだよ（つまり、「このJSONデータを生成するスクリプトと、このデータをレンダリングするための別のスクリプトを生成して」）。計画には特定の目標があり、それがレポートに反映される（「移行した合計は100%であるべき」）。これはまだ反復的なプロセスで、生成物や計画はエッジケースを見逃すことがあるから、一般的に計画はそういうものなんだ。計画を立てるのに1時間か2時間かかるけど、私がやると一日中かかることもあるし、場合によっては数日かかるかもしれない。ADHDの脳が退屈に反発するからね。AIは、ただその場でやってしまうときには素晴らしい仕事をすることがあるし、時にはタスクを指示して一発でやってしまうこともあるけど、詳細な計画があるときに最も効果的に機能する。さらに、計画書を指さして「そうして」と言えるのは本当に満足感があるよ。

LLMに対する「オールイン」な考え方が理解できない。自分はiOS開発者で、今まで通りそれを続けてる。今の違いは、デザインに基づいて一回限りのビューを素早く生成するためにLLMを使うこと。これはアプリのコアビューでも、コア機能でも、重要なものでもない。新機能を紹介するビューとか、ウィジェットのインストール方法とか、ランダムなことだ。これまでは複雑さに応じて30〜60分かかってたのが、今は5分で済む。アプリのランディングページを作るときにも使ってる。ウェブ開発が嫌いで、LLMはそれが得意だと思う。なぜなら、ソフトウェア開発に関するトレーニングデータの90%がそれに関連してるから。だから、大きな変更を加えて手動でレビューして、他のプロジェクトと同じようにgitにコミットしてる。人々が数時間も完全に道を外れて大きな問題にぶつかり、再スタートするのは信じられない。代わりに、計画的なアプローチを使って常に前進することができるのに。

└

人々はブログや動画のために「オールイン」みたいな愚かなことをする。ニュアンスや合理主義は、エンゲージメントを得られない。

└

まさに私の考え。これに関してはオールオアナッシングな考え方が多いみたい。私にとって価値があるのは、平凡で繰り返しの作業を簡素化し、自動化する能力。自分が設計した小さな関数やインターフェースを実装することや、ドキュメントやテストを最新の状態に保つためのリンティングツールを作ることなど。これらはすべて、私の時間を無限に節約し、かなりの精神的安定をもたらしてくれた。

└

LLMに対する「オールイン」メンタリティが理解できないな。ちょっと辛口で皮肉っぽく言うと（この特定の投稿についてじゃなくて一般的にね）、結局コンテンツを生み出すだけなんだよね。人々に話題を提供する。自分の個性を絶対的なもので定義するけど、実際の世界は無限のグラデーションで成り立ってる。何かに「オールイン」して、その素晴らしさについて書く。1ヶ月後には「なんでこれをやめることにしたか」って、その「オールイン」したことについて書いて、どれだけホッとしたか、良くなったかを語る。ほんとに疲れ切ったギミックだよ。「なんでSQLを捨ててNoSQLにしたか、もう振り返らない」 「なんでNoSQLが俺を裏切ったか」 「FlakeyCoの私たちがこの新しいJavaScriptフレームワークにオールインしてる理由！」 「なんでその新しいJavaScriptフレームワークを捨てたか」 この同じ退屈なサイクルがここで何度も繰り返されてるけど、なぜかみんなそれに引っかかるんだよね。作成者が悪い判断をしてる可能性が高いっていう大きな指標だし、あまり信じるべきじゃない人だと思う。普通の人は、何かに「オールイン」する必要があるって感じるんじゃなくて、合理的な判断を使ってるから、日常生活でLLMを何度も活用してるよ。それでも、実際のコードにはほぼゼロパーセントしか貢献してないけど、素晴らしいリソースではあるんだ。

└

さまざまなツールの有用性は、その人と問題によるよ。異なる問題に取り組む2人の仮定の人を考えて、例えばCursorが役立つかどうかを見てみよう。もしあなたが： * 10年のPython開発者 * 非常に大きくて複雑なPythonコードベースでほぼ全ての作業をしている * そのコードベースに完璧に調整されたPyCharm IDEを何年も使っている * バグに対する耐性が非常に低い（安定した製品で、急いで壊す余地がない） なら：LLMはあなたを10倍にはしないよ。CursorのようなIDEは、使い方を学ぶまでの間、あなたを非常に遅くする可能性が高い。もしあなたが： * 1年のJS（React、Next.jsなど）開発者 * 新しいアイデアでほぼゼロから始める * 以前のIDEの好みがあまりない * バグに対する耐性が高く、ただ出荷して試したい なら：LLMはあなたを10倍にするよ。CursorのようなIDEは、すぐにあなたをすごく速くしてくれる。

└

LLMの能力を過大評価するのは、探求しているときには自然なことだよ。約2年間、スタックオーバーフローの部分的な代替や短いコードスニペットを得るために使ってきた。Claudeコードが出たときは、責任を増やしていったけど、結局混乱しちゃって、今はどこがうまくいかないか理解して、アイデアやアドバイスのためにLLMをもっと使うようになった。この流れは結構一般的だと思う。

└

いろんなことをやってるよ、iOSやウェブも含めて。君が言ったように、LLMの結果は二つの間でかなり違う。LLMの出力がコンパイルすらできるかどうかも信じられないし、動くかどうかなんてなおさら。昨晩も、CMVideoFormatDescriptionGetCameraIntrinsicMatrixっていうAPIを使うように言われたんだけど、そのAPIは存在しないからね。トリッキーなSwift 6の並行処理のことを扱うときに、かなり深い穴を掘るのも得意だった。一方で、最初の試みでうまく動くNext.jsアプリを丸ごと生成してくれた。結局、すべてはそのトレーニングデータ次第だね。

└

LLMを使ってタスクを分解することができるよ。君が言ったように、シンプルでトレーニングデータに解決策があるタスクは時間を節約できる。世の中のほとんどのコードは接着剤みたいなものだから、統合や構成に関するトレーニングデータがたくさんあるんだ。これを全体として捉えれば、ほとんどの開発作業を30-60分から5分に短縮できるかもしれない。

└

私の経験に似ていて、小さなタスクにはうまく機能して、検索の代わり（ほとんどの場合）や多くのボイラープレート作業をこなしてくれる。すごく複雑なプロジェクトが一つあって、これにはLLMを使えないし、使わない方がいいと感じてる。さらに、できるだけ一回のセッションでコードを生成する方が良いと思う。他のLLMやセッションを試すと、すぐに劣化してしまうから。そうなると、重複した関数や行き止まりのコードが見えてくる。

Hacker Newsで議論の続きを見る