InstagramはネイティブなAIアーキテクチャを採用してユーザーインターフェースを近代化し、トークンコストを33％削減しました。

Instagram Directは、Androidのユーザーインターフェースを従来のAndroid ViewシステムからJetpack Composeへ移行し、AIネイティブなUIコードベースを構築しました。これにより、AIコーディングエージェントが理解・修正・保守しやすくなりました。Instagramのエンジニアによると、この移行によってUIのコード量は50％削減され、各AIエージェントセッションのトークンコストも33％低減したとのことです。

Instagramのエンジニアが強調した重要なポイントは、「AIネイティブなアーキテクチャを設計することで大きなメリットが得られる」ということです。個々のコンポーネントを逐一移行させるような断片的なアプローチではなく、根本的なアーキテクチャが正しい実装を生み出しやすいかどうかを評価することに重点を置くべきです。実際、彼らが指摘するように、「AIツールはしばしば最も抵抗の少ない経路を選択するため」、その結果として「隠れたバグや技術的負債、性能の低下」が生じる可能性があります。

Instagramのエンジニアたちは、AI向けに最適化されたコードベースとは、状態管理や予測可能な動作、開発パターンにおいて適切なアーキテクチャ境界を確立し、AIエージェントにとって「最小抵抗経路」が最良の変換結果へとつながるようなものだと説明しています。彼らの目標は、単に設計上の欠陥をAIで補うことに留まるのではなく、AIエージェントが実際にどのようにコードを修正するかを理解した上でコードベースを設計することです。

AIエージェントは本来、最も抵抗の少ない経路を選ぶため、設計段階でその経路が最終的に正しく高品質なコードを生成し、同時に不十分な設計判断が実現困難で高いコストを伴うものとなるよう配慮することが重要です。

もう一つの重要な原則は、コンテキスト依存を極力減らすことです。つまり、AIエージェントが特定のコードベースに関する知識に依存せず、検証済みのベストプラクティスや馴染み深いパターンを優先することで、より信頼性の高い結果を導き出せるようにすることです。

今回の移行は、チーム全体の通常業務に影響を与えることなく円滑に完了し、移行中もエンジニアは新機能のリリースを継続できました。AI支援によるワークフローはすでに標準化されており、一貫性が向上するとともに、社内共通のアーキテクチャ規約やベストプラクティスと整合性を保つことが可能になっています。

この手法により、Jetpack Compose への移行によって UI コード量が 50% 削減されるとともに、AI エージェントの実行時間が 35% 短縮され、各エージェントセッションあたりのトークンコストが 33% 削減され、エンジニアとエージェント間のやり取り回数も 32% 減少しました。

大きな課題の一つは、移行によってパフォーマンスが低下しないようにすることでした。チームは、画面を開いてから利用可能になるまでの時間であるインタラクション応答時間、すべての画面コンテンツが読み込まれるまでの完全ロード時間、そして画面コンテンツのスクロールの滑らかさを測定するスクロール性能という、三つの重要なプロダクション指標に重点を置きました。

本番環境では、これらの指標はランタイムモニタリングによって追跡され、A/B テストを実施して、移行後の Compose UI と従来の UI を比較し、移行がパフォーマンスに与える影響を評価できるようにしています。

Instagram のエンジニアが得た重要な知見の一つは、パフォーマンスを信頼性高く評価するためには、画面全体を Compose に移行してからでなければならず、パフォーマンス測定結果に歪みを生じさせる可能性のある残存する View コンポーネントを排除する必要があるということです。

つまり、Compose UI コンポーネントはそのフレームワーク自体から抽象化されるべきであり、同時に RecyclerView や LazyColumn との互換性も維持しなければなりません。さらに重要なのは、A/B テストを実施するために、ランタイム時に機能フラグを用いてこれら二つ間で切り替えられるようにすることです。

最終的に、チームは従来の RecyclerView（当初は新しい Compose コンポーザブルを収容するコンテナとして残されていたもの）を、リストの効率的な描画に特化した Compose のネイティブソリューションである LazyColumn に置き換えました。

最後に付け加えると、今回の移行はアプリケーションの他の部分の起動性能も向上させました。その一因は、Compose のランタイムでのプリウォーム処理のオーバーヘッドが各アプリケーションセッションで一度だけ発生するため、他の Compose ベースの画面は既に初期化されたランタイム環境を利用でき、再度そのオーバーヘッドを負担する必要がない点にあります。

原文リンク：https://www.infoq.com/news/2026/10/instagram-compose-migration/