Loading...
この記事は、ひとりでつくるSaaS - 裏note Advent Calendar 2025 の20日目の記事です。
https://adventar.org/calendars/12464
個人開発で「Memoreru」というプロダクトを作っています。知識を整理し、思考を育てるためのツールです。
この記事では、技術選定の新しい基準について考えてみます。
技術的な話はQiitaのアドベントカレンダーで書いています。ご興味のある方は、そちらもご覧ください。
https://qiita.com/advent-calendar/2025/solo-dev-memoreru
Claude Codeのような、AIがコードを書いてくれるツールが登場して、開発の体験が変わりました。
「この関数を作って」と指示すると、コードが生成される。「このエラーを直して」と言えば、修正案が出てくる。
でも、AIが正確に動くかどうかは、コードベースの状態に依存します。同じ指示でも、コードが整理されているプロジェクトと、そうでないプロジェクトでは、結果が違う。
技術選定をするとき、これまでは「パフォーマンス」「開発体験」「コミュニティの活発さ」などを基準にしていました。最近、もうひとつ基準が加わりました。「AIが理解しやすいか」という視点です。
AIも人間と同じで、読みやすいコードのほうが正確に理解できます。
明確な命名。一貫した構造。適度なコメント。
人間が読みやすいコードは、AIにとっても読みやすい。逆に、省略が多いコード、暗黙のルールが多いコード、コンテキストが必要なコードは、AIにとって難しい。
TypeScriptを使っていると、AIの精度が上がります。
型があると、「この引数には何を渡せばいいか」「この関数は何を返すか」が明確になる。AIはそれを読み取って、正確なコードを生成する。
型がないと、AIは推測に頼る。推測は間違えることがある。
型は人間のためだけじゃなく、AIのためでもある。
コードだけでは伝わらない意図があります。
なぜこの設計にしたのか。どういう制約があるのか。何を優先したのか。
ドキュメントがあると、AIはそれを読んで文脈を理解できる。プロジェクトの方針が書いてあれば、AIはその方針に沿った提案をしてくれます。
独自の規約よりも、一般的なパターンに従ったほうがAIは理解しやすい。
AIは大量のコードを学習しています。そのほとんどは、一般的なパターンで書かれている。珍しい書き方、独自のルール、プロジェクト固有の慣習は、学習データにない。
「この書き方が好き」よりも「みんなが書く書き方」を選ぶと、AIとの協働がスムーズになります。
これらを考えると、技術選定の基準も変わってきます。
ユーザー数の多いフレームワークを選ぶ。利用者が多いほど、AIの学習データにも多く含まれている。
型のある言語を選ぶ。型があると、AIは正確にコードを生成できる。
ドキュメントが充実しているものを選ぶ。公式ドキュメントが充実しているライブラリは、AIも正確に扱える。
結局のところ、AIが理解しやすいコードは、人間にも理解しやすい。
明確な命名、一貫した構造、適度なコメント、型による明示。これらは、AIが登場する前から「良いコード」とされてきたことです。
AIと協働する時代になって、その価値がより明確になりました。
技術選定に「AIが理解しやすいか」という視点を加えるようになりました。
型のある言語を選ぶとAIの精度が上がる。ユーザー数の多いフレームワークは学習データに多く含まれている。一般的なパターンはAIが知っている書き方。ドキュメントがあると文脈を伝えられる。
これからは、人間だけでなくAIも読者として意識する時代なのかもしれません。
開発の過程で考えたことを、引き続きこのnoteで書いていきます。
Comments