OS の AI に任せるか、自分で持つか — iOS 27 世代の機能境界を決める

4 つの問いを、実際の機能リストに当ててみる

抽象論のままだと判断は鈍ります。私が運用している癒し系アプリの機能を例に、先ほどの問いを実際に通してみます。

• 入力テキストの言語判定: 差別化に効かない／自前コストは小さいが OS 無償枠で十分／OS が変わっても表示は揺れない／Android にも標準 API がある。結論は委譲。迷う要素がありません。
• ユーザーの気分に合わせた言葉選び: 差別化の核そのもの／コストは中程度／ここが変わるとアプリの体験が壊れる／両 OS で同じ手触りが要る。結論は自前。無償でも OS には渡しません。
• 課金導線を出すタイミングの判定: 収益に直結／自前ロジックなので API は不要／OS の都合で挙動が変わるのは論外／事業データと不可分。結論は自前。そもそも委譲の候補に上げません。

並べてみると、判断が割れるのは真ん中の「個性に関わる処理」だけだと分かります。土台は委譲、収益は自前。この二つはほぼ自動で決まります。悩む時間は、中間層の見極めに集中させるのが効率的です。

Foundation Models 無償枠の線引きが効く理由

今回の無償開放には「初回ダウンロード 200 万未満」という条件が付きました。これは個人開発者を狙い撃ちにした、ありがたい線引きです。

私の運用しているアプリ群は累計では大きな数字になりますが、新作の初回ダウンロードは当然この枠に収まります。新しいアプリで AI 機能を試すコストが、実質ゼロになるわけです。これまでは「API コストが回収できるか分からないから AI 機能を見送る」という判断が普通にありました。その制約が外れる影響は小さくありません。

ただし、ここに罠があります。アプリが育って 200 万を超えた瞬間、無償枠から外れます。無償だからと OS の AI に深く依存した設計にしていると、成功した途端にコスト構造が崩れます。だから無償枠は「試すための入り口」と割り切り、課金が立つ層には最初から有料 API への切り替え経路を用意しておくことを推奨します。

委譲の損益分岐を、ざっくりした数字で見る

判断は数字で裏付けておくと迷いが減ります。要約機能を例に、自前 API と OS 委譲のコスト差をざっくり見積もってみます。

仮に 1 回の要約で入出力あわせて約 1,000 トークンを使い、外部 API の単価を 1,000 トークンあたり 0.3 円とします。月に 10 万回呼ばれる機能なら、月あたりおよそ 3 万円。これが OS の無償枠に収まれば、まるごと浮きます。個人開発の新作にとって、月 3 万円の固定費が消える意味は小さくありません。広告収益が立ち上がる前の時期ほど、この差は効いてきます。

逆に、月 1,000 回しか呼ばれない機能なら、API コストは月 300 円ほど。この規模なら、無償枠のために OS へ依存する設計の窮屈さを背負うより、有料 API で自由に作るほうが合理的です。300 円を惜しんで個性を OS に預けるのは、勘定が合いません。

委譲の旨味は、呼び出し回数が多い土台処理ほど大きく、回数の少ない個性的な処理ほど小さい——数字にすると、この傾向がはっきり見えてきます。だから私は、コストの重い高頻度処理から委譲を検討し、低頻度で個性に関わる処理は自前のまま握る、という優先順位をつけています。先ほどの 4 つの問いに、この「呼び出し頻度 × 単価」という物差しを一本足すと、判断がさらに揺るがなくなります。

OS 任せで 1 年後に後悔する典型パターン

実体験と周囲の事例から、後悔の形はだいたい決まっています。

// 後悔するパターン: OS の AI を UI に直接埋め込む
func summarize(_ text: String) async -> String {
    // OS の挙動・出力形式に画面が直結している
    let result = await SystemLanguageModel.default.summarize(text)
    return result.text   // 仕様が変わると画面が壊れる
}

このコードは動きますが、OS の出力形式に UI が直結しています。次の iOS で要約の長さや書式が変わると、画面のレイアウトが崩れます。私は別の機能で似た失敗をして、OS アップデートのたびに表示が揺れる状態に陥りました。

対策は、間に薄い境界を一枚挟むことです。

// 委譲しても、自分のドメイン型で受ける
protocol SummaryProvider {
    func summary(of text: String) async throws -> Summary
}
 
struct Summary {           // アプリが定義する安定した型
    let headline: String
    let body: String
}
 
// OS 実装はこの裏に隠す。差し替えも Android 対応も、この層でだけ起きる
struct OSFoundationProvider: SummaryProvider { /* ... */ }
struct RemoteAPIProvider: SummaryProvider { /* ... */ }

SummaryProvider という自分の言葉で受けておけば、中身が OS でも有料 API でも、画面側は何も知らずに済みます。委譲はしても、依存は隠す。この一枚があるだけで、OS の仕様変更も Android 展開も、影響をこの層に閉じ込められます。

境界が効いているかは、差し替えテストで確かめる

SummaryProvider のような境界を一枚挟んだら、それが本当に効いているかを確かめておきます。確かめ方は単純で、OS 実装を別の実装に差し替えても画面が一切変わらないことを、テストで保証します。

// テスト用のダミー実装。OS にも API にも依存しない
struct StubSummaryProvider: SummaryProvider {
    func summary(of text: String) async throws -> Summary {
        Summary(headline: "テスト見出し", body: "テスト本文")
    }
}
 
// 画面のロジックが Provider の中身を知らないことを保証する
func test_summaryView_doesNotDependOnBackend() async throws {
    let provider: SummaryProvider = StubSummaryProvider()
    let summary = try await provider.summary(of: "任意の入力")
    #expect(summary.headline == "テスト見出し")
    // ここで OS 固有の型が一切登場しないことが、境界が効いている証拠です
}

このテストが OS の型に一切触れずに通るなら、境界は機能しています。逆に、テストを書こうとして OS 固有の型が必要になったら、それは依存が画面まで漏れているサインです。私はこの「テストが書けるか」を、境界の健全性を測る一番安い物差しにしています。設計が正しいかは、差し替えられるかどうかで分かります。

Android も視野に入れるなら、抽象層はいつ挟むか

iOS だけで完結するなら、境界は最小限で構いません。ですが将来 Android にも出す可能性が少しでもあるなら、判断は変わります。

ここで悩ましいのは、抽象層を「いつ」挟むかです。最初から両 OS 対応を見越して厚い抽象を作ると、iOS だけで終わったときに無駄が残ります。逆に後から挟もうとすると、OS の型が画面のあちこちに染み出していて、剥がすのに苦労します。

私の判断は、差別化に効く処理だけは最初から自前のドメイン型で受け、土台の処理は Android 展開を決めた時点で抽象を足す、という二段構えです。核だけ守っておけば、移植の判断は後からでも間に合います。全機能を最初から両対応にしようとして、結局リリースが遅れるほうが、個人開発では損だと感じています。

個人開発者の現実的な落としどころ

全部を抽象化するのもまた過剰です。テキスト要約のような土台の処理まで丁寧に境界を引くと、開発が止まります。私の落としどころは、こうです。

差別化に効かない土台の処理は、境界を薄くして OS に直接委ねる。アプリの個性に関わる処理は、必ず自前のドメイン型で受けて中身を隠す。収益に直結する判断は、OS の AI には一切渡さず、自分のデータとロジックで持つ。

この三段の方針で、便利さと移植性のバランスが取れています。OS の進化に乗りながら、アプリの核は自分の手元に残す。それが個人開発で長く戦うための、私なりの境界線です。

手始めに、あなたのアプリの AI 機能を紙に書き出し、それぞれに先ほどの 4 つの問いを当ててみてください。委ねてよいものと、握るべきものが、驚くほどはっきり分かれるはずです。