2年間のUnityを2ヶ月でFlutterへ。AI Agentが実装できるコードベースへの投資

はじめに#

こんにちは。StarleyでVPoEをしている shinofara です。Starleyブログの第一弾として、今の開発の話を書きます。

Cotomoを愛用いただいている方の中には、4月18日ごろから「なんか雰囲気変わった？」「前と少し違う気がする」と気づかれた方がいるかもしれません。できることは変わっていないのに、なんとなく体験が違う —— そう感じたとしたら、それは実際にCotomoのモバイルアプリを大きく変えたからです。

4月18日から徐々にFlutter版への切り替えをはじめ、このほど移行が完了しました。2年間Unityで動かしてきたアプリを、2ヶ月で作り直してリリースしました。

この記事で伝えたいのは、移行の苦労話でも、技術選定の優劣の話でもありません。どのような判断の背景があったか、そして結果としてどういう変化が起きたかを記録しておきたいと思います。

---

Cotomoが育てた2年間#

Cotomoは2024年2月にリリースした、日常会話に特化したおしゃべりAIです。「話したいことも、話せないことも。」をコンセプトに、日常的な雑談から悩み相談まで、ユーザーの気持ちに寄り添うサービスとして育ててきました。クライアントはUnityで実装されており、約2年間にわたって開発・運用してきました。

その2年間で積み上げたものは、少なくありません。

• リアルタイム音声会話（WebSocket）
• Apple・Googleサインイン、キャンディシステム、通知、ショップ
• クラッシュ計測・分析・行動ログなどの観測基盤
• ユーザーが作れるカスタムコトモと、カスタムコトモの公開 & 共有の仕組み
• おしゃべりモード（2025年9月リリース）
• ストーリーモード（2026年2月リリース）

累計200万ユーザーを突破し（プレスリリース）、売上も立てられるようになりました。Unityというプラットフォームのうえで、Cotomoは確かに育っていました。

---

フェーズが変わった、という話#

では、なぜ今なのか。Unityに問題があったからではありません。私たちのフェーズが変わった、というのが正確な理解だと思っています。

より多くのユーザーに届けるためには、UXを高め続けるサイクルを止めることができません。作って・触って・直すというループを、できるだけ速く回し続ける必要がある。その前提で「今の土台のままでいいのか」という問いが生まれました。

もうひとつ、同じ時期に重なったことがあります。AIの水準が変わり、開発スタイルの前提が変わってきていました。AIがコードを理解し、実装を進められる環境を整えることが、開発速度に直結する時代になっていた。そのための設計を、最初から選べるかどうかが問われていました。

この2つが重なって、「新しい土台を作るタイミングがある」という判断につながっていきました。

---

Flutterという選択#

この移行、一本道ではありませんでした。

Unityのままでいくかどうかは、チームのなかで何度も議論してきたテーマです。そして一度、挑戦しています。2025年の夏、Flutterへの移行検証を始めました。「まずやってみよう」という温度感で進めていたこともあり、体制が整わないまま検証段階で停止しました。一度止まった経験があると、もう一度というのは心理的に難しい。チームの誰もが「まだしばらくUnityでいく」と思っていました。

それでも、AIの成長スピードを見ながら「このままでいいのか」という問いは消えませんでした。VPoTが自ら手を挙げ、外部パートナーとの4名チームで走り始めました。

Flutterを選んだのは、技術として優れているからというよりも、私たちのワークフローに合っていると判断したからです。具体的には、こういうことです。FigmaのデザインがWIPの状態でも、実装を並行して走らせることができる。デザインが固まる頃には実装がほぼ終わっている状態に近づきました。デザイン→実装→確認→修正のサイクルを短く回しやすい構造があった。そして、AIがコードを読んで実装を進められる設計を、最初から選べた。

---

フルリプレイスと、2ヶ月という期限#

フルリプレイスはリスクのある判断です。私たちが最も意識したのは期限を先に決めることでした。

「2ヶ月」という数字は、これまでの社内でのAI Coding実績と、ゼロから作るとしたらという見立てから出てきたものです。いつ終わるかを最初に決めることで、何を捨て、何を残すかの判断基準が生まれます。

本格的な移行開発を始めたのは2026年2月です。2ヶ月という期限は、常に「何を捨てるか」の判断を迫ってきます。

後回しにしたこと

• 一部のアニメーション細部
• パフォーマンスの極限チューニング

あえて変えたこと

• コード生成をAI前提に設計し直した

ゆずらなかったこと

• 音声会話の品質（これはCotomoの核心。妥協なし）
• 型安全性（曖昧な設計はAIが読みにくい）

「完璧なリプレイス」を目指すと終わりません。「期限内に届けられる最高の状態」を目指しました。

---

結果として変わったこと#

移行後、開発のペースに変化が出ています。ここで示す数字は「結果としてこうなった」という記録です。

Unity時代の週次マージPR数は平均約38件でした。Flutter移行後のクライアントは、安定稼働に入った3月以降で週平均193件 —— 約5倍という差が出ています。

ただし、この差をそのまま「生産性が5倍」と読むのは正確ではありません。Unityは既存コードベースへの追加開発が主体、Flutterは目的が明確な新規開発。その構造の違いがPR数に大きく影響しています。それを踏まえたうえで、それでも差は大きい。エンジニア1人あたりのスループットを見ると、Unity期間は約7 PR/週に対し、Flutter安定期は約31 PR/週と約4倍の差が出ています。

PRだけではなく、Linear上のIssue完了数でも同じ傾向が出ています。Unity時代の週次完了Issueは平均約23件。Flutter移行後の安定期（3月以降）は約122件——こちらも約5倍という数字になっています。

FlutterとAIの組み合わせでは、FigmaのWIPを読みながらUIの実装も同時に進められます。デザインが固まる頃には実装がほぼ終わっている、という状態に近づきました。

---

AI-Friendlyなコードベースとは何か#

移行の核心はここにあります。AIがコードを読み、AIが実装を進められるコードベースを作ること。 これはいまのAI活用の話ではなく、これから加速するAgent Coding時代への先行投資です。

そのために私たちが意識したのは、大きく三つのことです。まず、型が明確で副作用の場所が明示される設計を選びました。APIの仕様がコードに直接現れ、曖昧な型を排除することで、AIが推論できる文脈を常に保ちます。次に、CLAUDE.md や AGENTS.md といったファイルを用意しました。これらはAI Agentへの指示書で、「このリポジトリでどう動くか」「何を守るか」「どこを変えていいか」がファイルとして存在していれば、AIは毎回ゼロから推測しなくていい。そしてもうひとつが、コード生成を前提にした設計です。コードの多くは仕様から自動生成されます。AIが仕様を変えれば生成物が追従する —— 「AIが書いたコードをAIが修正する」ループを回しやすい構造を、最初から選びました。

---

Agentic Codingの現在と、その先#

AIによる開発は、将来の話ではありません。Flutterクライアントでは、今日この瞬間もコーディングエージェントがPRを実装し、レビューし、I18Nの修正を走らせています。

特に目立つのがDevinの貢献です。開始初週は人間とCLIのcoding agentによる実装が多かったのが、3月に入るとDevinが急加速。4月13日の週には1週間で192 PR（全体の80%）をマージしました。

リリースのペースも変わりました。Flutter移行後、v3.1.0の審査中に次のv3.1.5のビルドを同日に提出する、というサイクルが当たり前になっています。

今のコードベースを整えることは、AI Agentの実装速度への投資です。 これが、2年間動かしてきたUnityを手放して、2ヶ月でFlutterへ移行するという決断の、最も根本にある理由でした。

---

Flutter版になってから生まれた機能たち#

Flutter版で動いている機能のうち、いくつかはUnityからの移植ではなく、Flutter版になってから初めて作った機能です。

フォロー機能、マイページ、クリエイター画面、カスタムストーリー作成、そしてストーリーモード。これらはすべて、移行期間中あるいは移行後に新規で開発したものです。

ストーリーモードは4月上旬からクライアント実装が本格化し、開始画面・ストーリールーム・WebSocket接続・音声再生・シーン画像生成が、1〜2週間のあいだに50本以上のPRで積み上がりました。マイページはUIからAPI繋ぎこみまでほぼ1日。フォロー機能にいたっては、関連PRのすべてがAI Agentによる実装です。

---

数字の話をもう少しすると、こうなります。サーバー側のAPIとクライアントを合わせると、今年に入ってからのマージPRは5,700件を超えています。1〜2月は週130〜200 PRで推移していたものが、Flutterが本格化した3月以降は週350〜450 PRに増えています。

PR数やスループットだけでなく、実際にどれだけのコードが動いているかも見ておきたい。直近10週間のコード増減を日次で出すとこうなります。平日は毎日数万行から十数万行が追加され、週末は自然に静かになる。4月15日や5月29日のように削除が追加を上回る日もある —— それは大規模なリファクタリングが走った日です。

これを見て「すごい」と感じるか「本当に動くのか」と疑うかは、人によって分かれると思います。ただ実際に動いています。ユーザーの手元で、今日も動いています。

Human engineerがやっていることは、「何を作るか」の判断、設計の意図をコードベースに刻むこと、AIが生成したコードをレビューして「これでいい」あるいは「ここは違う」を言うこと。AIにはまだ難しい、実機でしか確認できないチューニングを直接触ること。

役割の分担が変わっています。速度が変わっています。

---

速く進む、ということの裏側#

速く進む分、本来なら数ヶ月後・数年後にやってきたかもしれない問題が、すぐにやってきます。技術的負債は、人間だけで書いていた頃より早く積み上がります。

だからこそやり続けなければならないことが二つあります。ひとつは、最初から備えること。AI-Friendlyな設計やコンテキストの整備は、一度やれば終わりではなく、コードベースが成長するたびに更新し続けるものです。もうひとつは、リファクタリングを止めないこと。Codexが夜中に動いて技術的負債を整理し、朝にはPRが上がっている——そういう状態を作ることが、速度を持続させる上で重要だと感じています。実際にその実験も始めています。

速く進む、ということは、立ち止まらずに整え続けるということでもあります。

---

エンジニアの守備範囲が変わる#

「プロジェクト一人」「Mini PdM」「オーナーシップを持った開発」 —— こういった言葉が、AI時代のエンジニアリングを語る文脈でよく登場するようになりました。

実際にこの状態になってみて思うことがあります。思いを持った人が、その思いで進めていくという感覚は、本当に大事だということ。ただ、これは楽ではありません。担当する範囲が、エンジニアリングだけに留まらなくなります。プロダクトの方向性を考え、ユーザー体験を判断し、優先順位を決め、AIへの指示を書き、生成物をレビューする。プロジェクトマネジメントの領域まで自然に広がっていきます。

そしてAI疲れという感覚も、おそらく現実としてあります。常にAIと会話し、アウトプットを読み続け、判断を評価し続ける——これは新しい種類の認知負荷です。コードを書く疲れとは質が違う。

エンジニアとして何を楽しみとするか、どこにエネルギーを注ぐかは、改めて考え直す時期に来ているかもしれない——そう感じています。

---

現在、エンジニアを探しています。

仕事の範囲は、Flutter・Web・サーバー・インフラをまたぐフルスタックです。「自分はここだけ」ではなく、ユーザー体験を起点に必要な領域に踏み込んでいける方を想定しています。Flutterの経験がなくても、AIを使いながらキャッチアップしていただける環境です。

開発ではDevin・Cursor Pro・Claude Code Max・Codexといったツールを日常的に使っています。「AIをどう使うか」を考え続けることが、そのまま仕事になります。

チームは海外比率70%超の多様なメンバーで構成されており、エンジニア間の公用語は日本語です。累計200万ユーザーを超えたCotomoで、正解のない体験づくりに向き合っています。

こういう方と話したいです。要件が整うのを待たず、曖昧なまま引き取ってAIと一緒に解像度を上げていくことに面白さを感じる人。「どうしたらユーザーに喜んでもらえるか」を判断軸に動ける人。

興味があれば、ぜひ話しましょう。

---

Starley VPoE / shinofara