この記事の主張はかなりはっきりしています。
「Local AI should be the default（ローカルAIをデフォルトにすべき）」、つまりAI機能はまず端末内で完結する形にしよう、という話です。
率直に言うと、これはかなり筋がいい考えだと思います。
最近のソフトウェア界隈では、ちょっとした機能でも「とりあえずLLMに投げる」みたいな流れが強いですが、そのノリで何でもクラウドに送ってしまうと、便利さの裏でかなり大きな代償を払うことになります。
著者がまず問題視しているのは、クラウドAIへの依存がソフトウェアを脆くすることです。
たとえば、AI機能がOpenAIやAnthropicのAPIに依存しているとします。すると、その機能は次のようなものに左右されます。
要するに、ただの「要約ボタン」だったはずなのに、いつの間にか分散システムになってしまうわけです。
これは笑い話っぽいけれど、実際かなり重要です。便利な機能を追加したつもりが、裏側では障害ポイントがどんどん増えていく。個人的には、ここがこの記事の一番のキモだと思います。
さらに、ユーザーの文章やデータを第三者のAIに送ると、プライバシー面の負担も一気に増えます。
こういう話が全部ついて回るようになります。
著者はこれを、「2,000語のプライバシーポリシーを書いて信頼を得る」より、「そもそも送らない」ほうがよほど良いと表現しています。これはかなり本質的な指摘ではないでしょうか。
著者が面白いのは、ただクラウドAIを批判するだけでなく、今の端末はもう十分高性能だと強調している点です。
スマホの中には、昔では考えられないくらい強いチップが入っています。しかもApple製品にはNeural Engineという、AI処理向けの専用ハードウェアまである。
それなのに、アプリが何かを要約するたびに、わざわざ遠くのサーバーまでJSONを取りに行くのは、たしかに妙です。
ここでのポイントは、「ローカルAIはクラウドAIの完全な代用品ではない」ということ。
でも、すべての用途が“世界中の知識が必要な超AI”である必要はないんですよね。
たとえば、
こういう用途なら、むしろローカルAIのほうが向いていることが多い、というのが著者の考えです。
これはかなり納得感があります。AIを「賢い検索エンジン」として使う場面ばかり想像すると見誤るけれど、実際にはデータ変換機としての役割のほうがずっと多いのです。
著者は自分のプロジェクト The Brutalist Report を例に挙げています。
これは昔ながらのウェブデザインに着想を得たニュースアグリゲーターで、今回それ用のiOSクライアントを作ったそうです。
そのクライアントでは、見出しを高密度に並べた一覧表示や、余計な装飾をそぎ落としたリーダーモードがあり、さらに任意で「intelligence view」として記事要約を生成できるようにしています。
ここで重要なのが、その要約はAppleのローカルモデルAPIを使って端末上で生成されることです。
つまり、
という世界です。
これは地味にすごいです。
AIというと、つい「大きなクラウドサービスを使うもの」という空気がありますが、実際はこういう端末内完結の機能こそ、ユーザーにとって自然で気持ちいいと思います。
著者も、AIを全部クラウドでやる流れがかなり当たり前になってしまっているので、業界としてその感覚を逆転させる必要がある、と述べています。
この記事では、Appleのエコシステムで使えるツールにも触れています。
著者によると、Appleはこの1年でかなり力を入れていて、開発者がローカルAIモデルを簡単に使えるようにしているとのことです。
コード例では、FoundationModels を使って、SystemLanguageModel.default からローカルの言語モデルを呼び出しています。
もちろん、技術に詳しくない人にはコードの細部は追わなくて大丈夫です。大事なのは、
という流れが、サーバーを介さずに完結することです。
長い文章を扱うときは、記事を10,000文字くらいずつに分割して、それぞれを短く要約し、最後にそれらをまとめる方法も紹介されています。
このあたりは実務っぽくていいですね。ローカルAIは万能ではないけれど、工夫すればかなり使える、という現実的な話です。
この記事で特に面白いのは、Appleの新しい流れとして、AI出力をただの文字列ではなく、typed data（型付きデータ）として扱う点を評価しているところです。
普通は「JSONを返して」とAIにお願いして、うまくJSONが壊れていないか祈る、という雑な運用になりがちです。
でも著者は、Swiftのstructで出力形式を定義し、そこにAIが値を入れる形のほうがずっと良いと言っています。
たとえば、
tldr は1文bullets は3〜7個の箇条書きkeywords はキーワード一覧のように、先にデータ構造を決めてしまうわけです。
これ、地味だけどかなり大事です。
AIを「雰囲気で使う」から「アプリの部品として扱う」に変える発想だからです。個人的には、ここはかなり未来っぽいです。
AIがふわっとした文章生成マシンから、ちゃんとアプリに組み込める部品になっていく感じがあります。
著者は最後に、よくある反論にも答えています。
それは 「でもローカルモデルはクラウドモデルほど賢くない」 というものです。
答えはシンプルで、その通り。でも、それが何か？ です。
ここはかなり気持ちいい返しです。
ほとんどのアプリ機能は、シェイクスピア級の創作力や、量子力学の完全理解なんて求めていません。必要なのは、せいぜい次のような仕事です。
こうした作業なら、ローカルモデルで十分に優秀なことが多い。
逆に、ローカルモデルを「インターネット全部の代わり」にしようとすると失敗します。著者が言っているのは、そこを履き違えるな、ということです。
著者の結論はかなり明快です。
最後の 「Stop shipping distributed systems when you meant to ship a feature.」
つまり、「機能を作りたかっただけなのに、分散システムを送り出すのはやめよう」という一文は、かなり刺さります。
個人的にも、これはAI時代のソフトウェア設計で忘れたくない視点だと思います。
AIがあるからといって、何でも外部APIに投げるのは、たしかに手っ取り早い。でもその手軽さの裏で、プライバシー、コスト、障害、運用、信頼の問題をまとめて背負い込むことになる。
だからこそ、ローカルAIをまず標準にするという考え方は、かなり現実的で、しかもユーザーにやさしいのではないでしょうか。