Jetpacker Intro
AI機能を作る前に決めるべき3つの軸——Jetpackerシリーズの本当の価値は実装例じゃない
結論
このJetpackerシリーズの導入記事は、個別の実装コードよりも「実行場所（デバイス／クラウド／ハイブリッド）」「複雑度（単発推論／エージェント的ワークフロー）」「統合方式（アプリ内／システム機能）」という3つの意思決定軸を先に整理している点に価値がある。AI機能をどう作るかより先に「どこで・どれくらい複雑に・どう統合するか」を決めるべきだ、という順番の提示そのものが、この記事の一番の実用性だと考えている。
背景
Jetpackerはオープンソースの旅行プランニングアプリで、Material Design UIを使った実務レベルのAI統合サンプルとして公開されている。このシリーズは全5部構成で、本記事はその総論にあたる。以降の記事（オンデバイス編、クラウド・ハイブリッド編、AppFunctions編、エージェント編）はすべてこの3軸のどこかに位置づけられる形で書かれている。
問題点
生成AI機能をアプリに組み込もうとするとき、多くのチームは「とりあえずクラウドAPIを叩く」か「とりあえずオンデバイスモデルを試す」のどちらかから始めてしまいがちだ。しかし実行場所の選択は複雑度や統合方式の選択と独立ではない。たとえば「システム機能として公開する（AppFunctions）」を選ぶなら、その関数はエージェントから呼ばれる前提で設計する必要があり、単発のオンデバイス推論とは求められる堅牢性が違う。軸を分けずに議論すると、要件定義の段階で話がかみ合わなくなる。
何故？
Jetpackerが機能ごとに実行場所を使い分けている理由を見ると、この3軸モデルの妥当性がわかる。
旅程サマリー・経費抽出・音声日記: プライバシーとオフライン耐性が最優先→オンデバイス（ML Kit GenAI API、Gemini Nano）
場所Q&A・レビュー下書き・チャット翻訳: 世界知識や広いコンテキストが必要、またはコストとカバレッジのバランスが必要→クラウドまたはハイブリッド（Firebase AI Logic）
予約代行アシスタント: 複数ステップにまたがる自律的な処理が必要→A2UIとADKによるエージェント的ワークフロー
つまり「機能の性質」から逆算して3軸それぞれの答えが決まっており、逆に言えば軸を先に決めずに実装から入ると、後から実行場所を変更するコストが跳ね上がる。
対応内容
シリーズ全体の構成は次の通り。
導入と全体像（本記事）
ML Kit GenAI APIとGemini Nanoによるオンデバイス実装
Firebase AI Logicによるクラウド・ハイブリッド実装
AppFunctionsによるシステム統合
A2UIとADKによるアプリ内エージェントワークフロー（続報予定）
AppFunctions APIは、Jetpackerの機能をアプリ外（システムレベルのインテリジェンス機能）から呼び出せるようにする層として位置づけられており、単体の機能追加ではなく「露出範囲を広げるレイヤー」として扱われている点も、3軸モデルの「統合方式」の具体例として読める。
まとめ
このシリーズを読む順番として、実装が気になる人ほど2〜4話から読み始めがちだが、それは遠回りだと思う。先にこの導入記事で3軸を自分のプロダクトに当てはめ、各機能がどのマスに入るかを紙に書き出してから各論に進んだほうが、結果的に手戻りが少ない。特に「統合方式」の軸は後からの変更コストが一番高い（アプリ内機能をAppFunctions化するには公開範囲やセキュリティ設計をやり直す必要がある）ため、最初に決め打ちすることを勧めたい。
参考: Build Intelligent Android Apps: Introduction to Jetpacker
