10月16日、Sergio De Simoneが「Instagram Modernized Its UI with an AI-Native Architecture, Cutting Token Costs by 33%」と題した記事を公開した。InstagramがAndroid UIをJetpack Composeへ移行し、AIエージェントが扱いやすい「AIネイティブアーキテクチャ」を構築することでトークンコストを33%削減した取り組みは、「AIにコードを書かせやすい設計とは何か」という問いに対する実践的な回答として注目に値する。
「AIに書かせやすいコード」を設計する、という発想の転換
この事例の核心は、単なるUIフレームワーク移行ではない。AIエージェントがコードを書く際の「最小抵抗経路」を、正しい実装に向けて設計するという考え方だ。
InstagramのエンジニアはAndroid DirectのUIを、従来のAndroid ViewシステムからJetpack Composeへ移行した。その過程で得た最大の教訓がこれだ：
AIエージェントは自然と最小抵抗の経路をたどる。だから設計は、その経路が正しく高品質なコードへつながるようにし、悪い設計判断は表現しにくく、コストが高くなるようにすべきだ。
つまり、AIに個々のコンポーネントを移行させる「場当たり的なアプローチ」ではなく、アーキテクチャ自体を「AIが正しく実装しやすい構造」にすることが重要だという。AIツールが最小抵抗経路を取ることで生じる「微妙なバグ、技術的負債、パフォーマンスの劣化」を防ぐためだ。
具体的には、以下の2点を重視している：
- 状態管理の境界、予測可能な振る舞い、開発パターンを明確にすることで、AIが正しい実装を自然に選べる構造にする
- コンテキスト依存を最小化する——コードベース固有の知識を前提とせず、確立されたベストプラクティスや一般的なパターンを使うことで、AIがより信頼性の高い結果を出せるようにする
移行結果：コード量半減、コストも大幅削減
この方針のもとで実施したJetpack Compose移行の結果は以下の通りだ：
| 指標 | 改善幅 |
|---|---|
| UIコード量 | 50%削減 |
| AIエージェントの実行時間 | 35%短縮 |
| エージェントセッションあたりのトークンコスト | 33%削減 |
| エンジニアとエージェント間のやりとり回数 | 32%削減 |
移行は既存の機能開発を止めずに進められた。AI支援ワークフローを標準化し、チーム全体でアーキテクチャの一貫性を保つことも徹底した。
パフォーマンス計測の落とし穴
移行で最大の課題となったのが、パフォーマンスの退行をどう検知するかだ。チームが注目した本番指標は3つ：Time to Interact（画面が操作可能になるまでの時間）、Time to Fully Load（全コンテンツが読み込まれるまでの時間）、スクロールパフォーマンス（スクロールの滑らかさ）。
これらはすべて本番環境でのランタイム計測であり、移行済みのCompose UIとレガシーUIをA/Bテストで比較できる仕組みを整えた。
一つの重要な知見は、画面全体をComposeに移行し終えるまで、パフォーマンスを正確に評価できないという点だ。レガシーのViewが一部でも残っていると、計測値が歪む。このため、Compose UIコンポーネントはRecyclerViewとLazyColumnの両方に対応しつつ、実行時にフィーチャーフラグで切り替えられる設計にした。最終的には、レガシーのRecyclerViewをComposeネイティブのLazyColumnに置き換えている。
また、Composeはアプリセッションごとに一度だけランタイムウォームアップコストが発生する仕組みのため、他のCompose画面はそのコストを再度払わずに済む。結果として、アプリ全体の起動パフォーマンスにも波及的な改善が見られた。
Jetpack Composeの採用がAIコーディング支援との相性の観点からも語られ始めている点は、今後のAndroid開発の方向性を示す事例として参考になる。Googleの公式ブログもあわせて参照されたい。
詳細はInstagram Modernized Its UI with an AI-Native Architecture, Cutting Token Costs by 33%を参照していただきたい。
