どうして今 サーバーサイドKotlinを選択したのか NEALLE 2026.7.3 株式会社ニーリー 野呂 有我 

目次 1｜なぜ言語を変えるのか 2｜言語に求めたもの 3｜JVMの壁とQuarkus 4｜なぜKotlinなのか 2 5｜ まとめ 

3 1｜自己紹介 氏名 所属 経歴 野呂 有我 ／ Yuga NORO 株式会社ニーリー プラットフォーム本部 アーキテクチャチーム ・大学院時代に友人と楽譜販売サービスを立ち上げ ・その後、SIer企業に参画 ・副業としてニーリーでいくつかの開発に携わる ・フリーランスを経て、ニーリーへ ・ニーリーではアーキテクチャグループのGMとして 　技術側の意思決定などを行っている 

4 1｜なぜ言語を変えるのか なぜこのタイミングで 言語を変更するのか 

5 1｜なぜ言語を変えるのか 

1｜なぜ言語を変えるのか 

7 1｜なぜ言語を変えるのか Pythonからの移行 ── 切り替えの動機  開発のペイン ・ドメインロジックが複雑になる ・影響範囲の特定が難しい ・黒魔術が跋扈する ・LLMを使った開発でガードレール を敷きにくい  BtoBtoCサービスであること  決済周りのステークホルダーがとても多いこと  オプションやイレギュラー対応を含めたロジック化 etc... 

8 1｜なぜ言語を変えるのか Pythonからの移行── 切り替えの動機  前提 ・Pythonは万能で良い言語。 ・Webでも機械学習でもなんでも　 できる ・しかし…  欲しかったもの ・複雑になりがちなドメインロ ジックに対処するため、表現力が 高く堅牢な型を求めていた。  仮説検証と結果 ・「静的型付けを使いたいはず」 という仮説のもと、開発メンバー にアンケートを実施。 ・色々な言語を候補に挙げたが、 結果：圧倒的1位は「静的型付けな らどれでもいい」だった。 

9 2｜言語に求めたもの 候補を絞り込む 〜型に何を求めたか〜 

10 2｜言語に求めたもの 求めたのは「型の表現力」と「堅牢さ」と「生産性」 複雑なドメイン知識を確実に表現できる「型の表現力」と「システムの堅牢さ」と「生産性」のバランス  TypeScript BFFに採用 / Backendは見送り 型の表現力は申し分ないものの、ス キーマやORM管理が煩雑になる懸念か ら、Backendでの採用は見送りまし た。  Rust 今回は見送り（個人的には大好き） 表現力・堅牢性は極めて高いが、所有 権やライフタイムが活きる場面は、プ ロダクトのドメイン的に当面は少ない と判断。  Java / Kotlin / Go 最終候補として残った3言語 記述性と開発効率、磐石なエコシステ ムのバランスを考慮し、この3つの選 択肢をPoCにて実際に比較検証するこ とに。 

11 2｜言語に求めたもの PoC前は「Javaが良さそう」と思っていた 1 活発な開発状況 近年のJavaはかなり活発に開発が進んでいる 2 モダナイズされた言語仕様 switch式・Record型・パターンマッチなど「Kotlinよりモダン」なイ メージ 3 JVMエコシステムの主軸 JVMはJavaの都合で変化する → Javaの方が磐石では、という予想 4 社内の技術スタック ニーリーはJava経験者の比率が高い  実際の比較検証へ プロトタイプでの比較 仮説を検証するため、Java / Kotlin / Go の3 言語で実際に会員基盤のプロトタイプを作 成し、徹底的な比較を行いました。 

12 3｜なぜKotlinなのか Java と Go を実際に試した 所感 

13 3｜なぜKotlinなのか Kotlinと比べて、Javaがしんどかった点  LLMとの連携・認識の限界 ・Lombokなどコンパイル時にclassを生成する系ライブ ラリは、LLMに認識させる手段が極めて限定的 ※ 人間はIntelliJで開発できるが、Claude Code等には MCPや複雑な設定が必要（強いペイン） ・Kotlinなら特別なライブラリ不要で効率的に書けるた め、LLMが意に反したコードを出しにくい  言語仕様における課題 ・Null安全性の欠如 Javaの言語仕様において、モダンなNull安全を高い次元 で実現することは現状困難。 ・Project Valhallaへの依存 Javaがこの領域でKotlinと同等の生産性に達するには、 Project Valhallaの完成を待たなければならない状況にあ る。 

14 3｜なぜKotlinなのか Kotlinと比べて、Goがしんどかった点  LLM・コード品質への懸念 ・null排除や再代入禁止が機械的に行えず、ルールが長 くなりコンテキストを圧迫 ・妥協により読み解きにくいコードが生成され、理解負 債が大きくなるリスク ・Genericsで十分な場面でも、AIがすぐ interface{} を使 おうとする  組織体制とエコシステム ・Go特有の開発ハードル Goに詳しいエンジニアが揃っていれば障害ではないが、 当時の弊社には多くなかった（組織的なミスマッチ）。 ・ライブラリ不足の懸念は杞憂 懸念されていたOSSライブラリの少なさは実際には問題 にならず、エコシステム全体の状況は変化している。 

15 3｜なぜKotlinなのか ニーリーがKotlinを選んだ理由  1. 型の表現力が高い  2. LLMに効率よくコードを書かせられそう  3. 理解負債を小さくできそう  4. JVMに慣れたメンバーが多い → ニーリーは Kotlin を次期Backend言語として採用！ 

16 4｜JVMの壁とQuarkus JVMの弱点と対策 

17 4｜JVMの壁とQuarkus JVMの弱点と、その解決策  JVMの弱点とLambda構想 ・JVM系言語はCold Startが遅いため、FaaSやコンテ ナ環境において起動速度が大きなネックに。 ・共通基盤のAPIをすべてLambdaに載せる構想があ り、レスポンス遅延の許容性を慎重に検討する必要が あった。  解決策：Quarkusの採用 ・クラウドネイティブなOSSであるQuarkus（Red Hat 主導）を新たに採用。 【主な特徴】 ・起動が極めて高速（数100ms） ・劇的な省メモリ化を実現 ・Native Compile対応 / Reactiveサポート 

18 4｜JVMの壁とQuarkus 実際にLambdaへ載せてみると…  起動パフォーマンスの実測値 ・コールドスタート 約300ms ・スタンバイ状態 約6ms（爆速）  検証結果と運用の結論 ・GraalVMでネイティブビルドをしていない状態で も、実用上十分に高速であった。 ・ボトルネックはDB接続等に移るため、JVMに載せ たままでも十分運用できると結論。 ・どうしてもパフォーマンスに困った際は、Snap Startの適用も検討可能。 

19 5｜まとめ まとめ  ニーリーに「マッチした」技術選定 ・言語の優劣や、本質的なLLMとの親和性ではなく、 「今のニーリーに最もマッチした」という意思決定。 ・将来的にさらなる高い性能が求められる局面では、 部分的にGoやRustをハイブリッドに活用することもあ るかも？  確実な実績とこれからの展開 ・最初のKotlin製サービスである会員基盤は、すでに 「ワンデイパーク」で安定稼働中 🎉 ・この成功実績をベースに、社内では他にも続々と Kotlinを用いた新しいプロダクトやサービスの開発が 活発に進行中！ 

Thank you 20