250万行の TypeScript から C# へ — Motion が .NET を選んだ理由

タスク管理ツールを提供する Motion のエンジニアリングチームが、約 5 年運用してきた 250 万行規模の TypeScript モノレポから C# / .NET へ移っていくと表明し、技術者の間で大きな話題になりました。「TypeScript が嫌いになったわけではない」と繰り返し強調しながらも、成長したスタートアップが直面した現実的な理由が実体験ベースで語られており、C# を主戦場とする立場から見ても示唆に富む内容です。

本記事では、Motion の CTO による公開記事の要点を整理し、なぜ移行先に C# が選ばれたのか、そして日本の開発現場にとって何が参考になるのかをまとめます。原文の主張はできるだけ Motion 自身の文脈に沿って紹介し、そのうえで .NET モダナイゼーションの観点を添えます。

TypeScript を愛しながら、離れる決断

Motion のスタックは徹底して TypeScript でした。フロントは React、モバイルは React Native、デスクトップは Electron、そしてインフラ定義まで TypeScript です。フルスタックで同じ言語を使い、アイデアを高速に検証できたことが、20 回以上のピボットを乗り越えられた理由だと振り返っています。TypeScript への感謝が前提にある点は、この記事を単なる不満の吐露と切り離しています。

それでも、規模の拡大とともに綻びが見え始めます。「どこでもコードを共有できる」という夢は完全には実現せず、React Native と他の環境の間で共有ライブラリがずれ、「誰がモバイルを壊したのか」を探す時間が増えていきました。言語サーバーは頻繁にクラッシュし、最適化した CI でもビルドは 20 分以上かかり続けたといいます。

技術的な痛みはさらに具体的です。Zod v3 ではモノレポがコンパイルすら通らず、TypeScript コンパイラの最大再帰深度に達したため v4 の登場を待つ必要がありました。そもそも Zod のような仕組みが要るのは、TypeScript が実行時の型を持たないからです。ORM 側でも、ある条件で where 句が undefined に評価されるとテーブル全体を削除してしまう挙動に遭遇するなど、基盤の信頼性に神経を使い続けたと述べています。

なぜ Go や Rust ではなく C# だったのか

言語選定にあたって Motion が置いた条件は、ガベージコレクションがあり、静的型付けで、性能が高く、生産性を最大化できることでした。この条件で真剣に検討したのは C# と Java の 2 つだけだったといいます。どちらも大規模で実績のある成熟したエコシステムを持つからです。Go や Rust が第一候補に挙がらなかったのは、GC と生産性という軸を重視したためだと読み取れます。

最終的に、業務で使った経験がないにもかかわらず C# を選んだ理由として、記事は 4 点を挙げています。1 つ目は Entity Framework です。多くの B2B ソフトは基本的な CRUD が中心で、そこで効く堅牢な ORM を求めていました。ソフト削除はグローバルクエリフィルタで 1 行、変更追跡は既定でトランザクション的にまとまるなど、Prisma や Drizzle で苦労した部分が素直に解けたと評価しています。

2 つ目は TypeScript との近さです。両言語は同じ設計者の手によるもので、async/await やアロー関数、null 許容型など構文が似ています。学習コストと移行時の速度低下を抑えられる点は、既存チームにとって現実的な後押しになります。3 つ目のエコシステムについては、規模が「最大かどうか」ではなく「十分か」で判断したとし、イベントソーシングやアクターモデル、メッセージバスの実績が厚い C# は十分に条件を満たしたとしています。

4 つ目が AI コーディングとの相性です。ガードレールが強い言語ほど AI に長く任せられるという経験則を述べ、強い型・Roslyn による豊富な lint・すべての公開メンバーに付く XML ドキュメントが、AI の生成品質を底上げすると論じています。同じ労力のプロンプトなら AI は TypeScript より質の高い C# を書く、という感触が語られている点は、AI 駆動開発を進める現場にとって見逃せない指摘です。

X で広がった反応

この記事は日本語圏でも取り上げられ、要点を的確にまとめた投稿が拡散しました。TypeScript の課題、ORM の問題、エコシステムといった論点が実体験ベースで網羅されている点と、締めの一言が印象的だという反応です。

おすすめ記事

「TypeScriptの約250万行コードからC#への移行」https://t.co/m9wCrILiHb

直近のC#関連の議論になっていた内容が網羅的に解説されています（実体験ベースで）

TypeScriptの課題、ORMの問題、エコシステム…etc

そしてラストの『「.NET」はクールではない。』のオチが秀逸です pic.twitter.com/mKLQUkSyZv

— 荒神垣内テク a.k.a TechNinja⚡️テクノロジー忍術の達人 (@TechNinja_z) 2025年9月19日

原文の結びは「.NET はクールではない」という自己言及から始まります。長らく Windows 専用で古臭いという評判があったのは事実だが、.NET Core は静かに、着実に進化してきた。いまや Linux ファーストでオープンソース、性能も高く堅牢だ、という主張です。逆張りに見えるかもしれないが、退屈で安全であることこそ CRUD をスケールさせる基盤に求められる、という価値観が全体を貫いています。

この事例から日本の現場が読み取れること

Motion のケースは「TypeScript は悪い」という単純な話ではありません。むしろ、スタートアップの初速を支えた言語が、規模の拡大とともに別の要件に直面したという、技術選定のライフサイクルの話として読むのが妥当です。実行時の型、成熟した ORM、安定したビルド時間といった要素は、コードベースが数百万行に達した段階で効いてきます。

日本の業務システムでは、もともと C# / .NET や Java が選ばれてきた領域が広くあります。今回の事例が興味深いのは、フルスタック TypeScript から出発した新興企業が、成長の果てに同じ結論へたどり着いた点です。基幹の CRUD を「退屈で安全」に回すという発想は、レガシー資産のモダナイゼーションを考えるうえでも通じます。派手さより、実行時の安全性と運用のしやすさを軸に据える判断です。

もちろん、既存の TypeScript 資産をすべて置き換えるべきという話ではありません。フロントエンドや素早い検証では TypeScript の強みは変わらず有効で、Motion 自身も引き続き TypeScript を使うと明言しています。重要なのは、領域ごとに適した言語とランタイムを選ぶという視点であり、C# / .NET はバックエンドの安定運用という文脈で改めて有力な選択肢になっている、という点です。移行の全体像や段階的な進め方については、.NET Framework から .NET 10 への移行プレイブックもあわせてご覧ください。

まとめ

Motion の事例は、TypeScript への敬意を保ったまま、成長したコードベースが求める「実行時の型・堅牢な ORM・安定したビルド・AI との相性」を満たす選択として C# / .NET を選んだ話です。派手ではないが、CRUD をスケールさせる基盤は退屈で安全であるべきだという主張には、業務システムを長く支えてきた .NET の価値がよく表れています。技術選定は流行ではなく、規模とフェーズに応じて見直すものだと、この事例は教えてくれます。

エンハンスド株式会社では、C# / .NET を軸にしたバックエンドの設計・実装から、TypeScript 資産との共存を前提としたアーキテクチャ設計、レガシーシステムのモダナイゼーションまでを一貫して支援しています。言語やランタイムの選定を、事業のフェーズに合わせて第三者の視点で整理したいといったご相談も承ります。レガシーシステム モダナイゼーションのページもあわせてご覧ください。

参照元

• Moving off of TypeScript（Motion Engineering / Chander Ramesh）
• 記事を紹介する X の投稿（@TechNinja_z）

このテーマの全体像は .NET モダナイゼーション 完全ガイド にまとめています。