12分で読めます
  • AI
  • ツール
  • 制作

Core AIをMacアプリに入れてみた——Hazakura Editor v3.1とローカルAIの現在地

AppleのCore AIをMacアプリに実装したHazakura Editor v3.1。オンデバイスLLMのリアルな壁と、それでも面白い理由——ローカルAIの現在地を、開発の本音とともに整理します。

カテゴリー: AI · ツール · 制作 | 公開: 2026年9月25日 | 読了目安: 約12分

📑 目次

ふむふむ。6月のWWDC26でAppleが「Core AI」を発表したとき、こんな記事を書きました。

あれから約3ヶ月。

「で、実際にアプリに入れてみたらどうだったの？」

これ、ずっと気になってたんです。発表の解説記事はたくさんある。でも「実際に自分のアプリに入れてみた」という実装のリアルって、まだそんなに多くない。

そんななか、葉桜ラボのMacアプリ Hazakura Editor が v3.1 で Core AI に対応しました。今日はその実装のリアルを、いいところも正直なところも、両方レポートします。

Hazakura Editor v3.1 で何が変わったか

軽く前提から。Hazakura Editor は、葉桜ラボが作っている macOS 向けの Markdown エディタです。「実行しない・補完しすぎない・差分で確かめる」という静かな設計で、書く・読む・磨く・確かめる・出す——その五つに集中した道具です（詳しくは Hazakura Editor紹介記事 で）。

v3.1 のいちばん大きなアップデートが、Local Assist のバックエンドに Core AI を追加したこと。

Local Assist は、校正・要約・翻訳・短縮・続き案といった文章補助を、Macの上だけで完結させる機能です（プレビュー機能として提供中）。これまでは Apple Intelligence のオンデバイスモデルを使っていましたが、v3.1 からは、Core AI で動くオープンモデルも選べるようになりました。

ℹ️ 補足: v3.1 のローカルLLMは Core AI の機能を利用しており、macOS 27 でのみ利用可能です（アプリ本体は macOS 26 以降に対応）。

具体的には、こんなことができるようになっています。

  • Gemma系の言語モデル（Gemma 4 E4B）をMac上で直接動かす
  • モデルのダウンロード・検証・切り替え・削除を、アプリ側から操作する
  • 自分で用意した Core AI モデルのフォルダを登録して使う

「クラウドのAI APIを呼ぶ」のではなく、「自分のMacの中にモデルを持ってくる」。

文章は外に送られないし、ネットがなくても動くし、トークン料金も気にしなくていい。

仕組みとしては、とても面白い。でも——ここからが今日の本題です。

開発の本音——「発表後の現実」は、まだ手探りだった

ここからは、実装してみて見えてきた「壁」を、正直に書きます。きれいごと抜きの、開発現場のメモです。

1. モデルの準備が、まず大変

Core AI 用の .aimodel 形式は、配布されているモデルをそのまま持ってくるだけ、というわけにはいきません。対応していない精度形式からの変換などの工程が必要で、量子化による品質の劣化を確かめるのも一苦労。ここは、ローカルLLMの知識がないと、入り口でかなり止まります。

2. 知見が、まだ少ない

発表から3ヶ月。困ったときに調べても、先例がまだ少ない。手探りで進む部分が多く、「ひとつずつ、動かして確かめる」の連続です。

3. 性能の切り分けは、まだ途中

たとえばMLX形式で動かすのと比べると、「同じモデルなのに、なんでこんなに重いの？」と感じる場面があります。ただ、その差がどこから来るのか——変換方法、量子化、実行時のspecialization、ランタイム——までは、まだ切り分けられていません。Core AI側には、CPU・GPU・Neural Engineの使い分けやAOTコンパイルの仕組みがすでにあります。ここは、継続して測っていく領域です。

4. エコシステムが、発展途上

「このモデル、いい感じだったよ」から、実際のアプリに届くまでの道のりが、まだ長い。モデルを配信する仕組み自体は、Appleがホストする配信サービス（Apple-Hosted Background Assets）のように、機械学習モデルを含む大きなアセットをアプリ本体と別に配布できるものとして、すでに用意されています。でも、モデルを見つけて、変換して、パッケージ化して、審査して、届ける——このエンドツーエンドの流れは、まだ手探りです。「せっかく変換したのに、届けるのが大変」なんですよね。

5. ハードウェアの壁は、正直にある

「Gemmaの12B（120億パラメータ級）も動かせたらいいな」と思って試したのですが（Hazakuraで試したのはINT8量子化版です）、16GBメモリのマシンでは満足に動きませんでした。モデルのサイズやメモリ不足だけが原因と決め打ちはできず、Core AI側のランタイムやモデル変換・実行の条件も含めて、「現状の16GB環境では実用的に回せなかった」というのが正確なところです。

結果、v3.1 では Gemma 4 E4B（有効パラメータ4.5B、embeddings込みで約8B）を採用しています。手元で試した範囲では、日本語の文章補助との相性がよく、12Bより扱いやすかった。

これ、失敗ではなくて「現在地の測定」なんですよね。モデルが動くかどうかを左右する段差がどこにあるのか——サイズなのか、実行環境なのか——を、一つずつ確かめる作業です。

……と、ここまで書くと「大変そう」に見えますよね。実際、開発の現場ではこんな言葉も出ていました。

ローカルLLMの知識がないと、実装までのハードルは結構高い。ローカルLLMのコミュニティにいる人限定の機能、と言っても過言じゃないくらい。

うん、たしかに、今はまだそういう段階です。

ちょっと待って、それは「早すぎる技術」のいつもの風景では？

ここで一回、冷静に疑ってみましょう。

新しい技術が発表された直後って、いつもこんな感じじゃないですか？

  • 対応が難しくて
  • 知見が少なくて
  • エコシステムが育ってなくて
  • 「これ、誰が使うの？」と言われる

でも、その多くは数年で「あたりまえ」になります。HTMLを手書きしていた時代から、ブログツールが生まれ、Web標準が整っていった流れと同じで、今の摩擦は「黎明期の摩擦」なんですよね。

Apple自身も、WWDCのセッションで coreai-models リポジトリ を用意して、人気モデルの変換レシピを公開し始めています。Apple siliconのCPU・GPU・Neural Engineを使い分ける最適化も、これから本気で進んでいくはずです。

いま面白いのは、この摩擦が起きている場所なんです。

変換の面倒さ、量子化の劣化、モデルを届ける仕組み—— これまで「機械学習エンジニアの仕事」だったものが、 いま「アプリ開発者の仕事」になりつつある。

言い換えると、ローカルAIが「研究の道具」から「アプリの部品」に変わる途中の摩擦。発表から3ヶ月で、もうその入り口に立っているわけです。

それでも「ローカルで動く」を追いかける理由

「品質だけなら、クラウドのAIの方が上でしょ？」

そのとおりです。今のところ、大きなクラウドモデルの方が賢い場面は多い。じゃあ、なぜ Hazakura Editor はローカルにこだわるのか。

理由は、「文章を書く」という行為の性質にあります。

下書き、日記、企画メモ、公開前の原稿……こういうものを、外部のサーバーに送って、返事をもらう。技術的に何か問題があるわけじゃない。でも、「送らないで済むなら、送らない」という選択肢があるのは、気持ちの上で大きいんです。

それに、ローカルならではの利点が、こんなにあります。

  • ネットがなくても動く（飛行機の中でも、圏外でも）
  • 使った分だけ課金、というプレッシャーがない
  • モデルを自分で選べる・交換できる
  • 一度手元に置けば、誰かのサービスの都合に振り回されない

これって、「道具」との付き合い方の話なんですよね。『持つことと在ること』の記事 でフロムの「持つ」「在る」という二つのモードを扱いましたが、「AIサービスに繋がる」から「AIという道具を手元に置く」へ。所有と利用のあいだの、新しいバランスを探す感じ。

クラウドが「悪い」わけじゃなくて、選べることが大事なんです。

16GBと12Bのあいだ——「現在地」の測り方

最初に触れた、12Bが動かなかった話。もう少しだけ掘ります。

ローカルでモデルを動かすとき、いちばん制約になるのはメモリです。MacのユニファイドメモリはCPUとGPUで共有だから、モデルの重みがそのまま「使えるメモリ」を減らしていく。

Gemma 4ファミリーの場合、Googleが示す推論メモリの概算だと:

  • E4B: 4-bit量子化で 4.5GB クラス（モバイル・テキストのみなら 2.2GB）
  • 12B: 4-bit量子化でも 6.7GB クラス

ただしこれは、4-bit量子化を想定したGoogleの一般値です。Hazakuraで実際に試した12BはINT8量子化版で、条件が違う。手元で展開したモデル資産はディスク上で14.7GBほどになります（これはディスク上のサイズで、RAM使用量の実測値ではありません）。同じ「12B」でも量子化の形式で姿が違うので、この概算の数字をそのまま当てはめて「16GBなら足りるはず」という比較には使えないんですね。

数字だけ見ると「12Bもいけるのでは？」と思いますよね。でも実際は、量子化の形式に加えて、モデル本体にKVキャッシュや作業領域が乗っかるうえ、実行環境側の条件も重なって、16GBのマシンでは動作が苦しくなった。結果、v3.1 は E4B に絞って「日本語の文章補助で、ちゃんと実用的に回る」ところを優先しました。

これは「ボタンひとつで選べる話」じゃなくて、「どのモデルが、どのマシンで、何を実用的にこなせるか」を一つずつ測っていく作業です。地味だけど、ローカルAIの道具を作る側は、誰かがこれをやらなきゃいけない。

数年後、メモリがもっと普通に増えて、最適化も進んだら、この「16GBと12Bのあいだ」の段差は埋まっていくんでしょうね。そのときに「最初はこんなに大変だったんだよ」と言えるのが、いま記録しておく意味です。

まとめ——「動けばいい」から「アプリの部品」への、長い午後

Core AI をアプリに入れてみた感想を、ひとことでまとめると:

発表から3ヶ月。技術としては、確かに動く。 でも「みんなが使える部品」になるには、まだ階段がある。

Hazakura Editor v3.1 は、その階段をひとつ上がった「実験の途中経過」です。

  • オンデバイスで、文章を外に送らずに、校正も要約もできる
  • モデルを自分で持ってきて、選んで、差し替えられる
  • ……ただし、その準備には、まだ手間がかかる

ローカルAIの現在地は、たぶん「動くようになったけど、まだハード」。

でも、この「まだハード」の期間が、たぶんいちばん面白いんですよ。手探りで、知見がなくて、ちょっと疲れる。でも、ここで蓄積された知見が、次の「あたりまえ」を作っていく。

Hazakura Editor はこれからも、ローカルAIと静かに実験していきます。あなたのMacで、どんな小さなAIが動くようになるのか。その変化、一緒に見ていきませんか。

関連記事

参考URL

  • インターネット上のツールは第三者が提供するものです。開発工程や配布経路を悪用した攻撃（サプライチェーン攻撃）が仕掛けられる可能性もゼロではありません。ご利用の際は公式リポジトリの情報をご確認いただき、自己責任でお使いください。
  • AIに関する技術や情報は急速に変化します。本記事の内容が公開後に古くなる可能性があります。各サービスの公式ドキュメントや最新情報をご確認ください。

近くの問い