
macOS 27(Golden Gate) から、OS 標準のターミナル上でオンデバイス AI(Apple Foundation Models)を直接呼び出せる公式 CLI コマンド fm が搭載されました。「追加ソフトも API 課金もなしでローカル LLM が動くなら、もうクラウドの有料 AI は要らないのでは?」と期待する声も見かけます。
しかし、背後で動いているモデルのパラメータ規模とコンテキスト上限を冷静に解剖すると、知識質問や長文執筆に使えば激しいハルシネーション(もっともらしい嘘)を起こす一方、まったく別の領域でとてつもない実用性を秘めていることが分かります。
結論からお伝えすると、fm は賢い相談相手ではなく 「API 代 0 円・外部送信ゼロで動く『正規表現の超進化版』」 として使い倒すのが正解です。本記事では、型保証 JSON 変換・ローカル画像 OCR・クラウド AI 送信前の個人情報マスキングという 3 つの実務パイプライン と、絶対に使ってはいけない境界線を整理します。
-
Google AI ProとUltra(5x・20x)の選び方|週間制限の実測とChatGPT・Claude比較 : 高度な設計・推論・長文執筆を担うクラウド最上位モデル(Gemini 4 Argon 等)の選び方と実測データです。
-
NVIDIA『Dory 1.0-4B』と32MB音声AI『Woof』|ループ推論とブラウザ完結術 : 小規模パラメータのエッジ AI が得意な領域と、手元の Mac 母艦で活用する勘所を解説しています。
-
Google AI週間クォータ消費を半減!SQLite×RAMDiskで500記事運用を高速化した記録 : クラウド AI の貴重なクォータを温存するためにローカル検索・前処理を組み合わせる実践記録です。
-
AI開発はアセンブラとRustどっちが速い?LLVM形式検証と純Rust製Cranelift導入術 : 自作の純 Rust 製 CLI ツールと AI 開発を高速に回すための基盤設計をまとめています。
-
macOS 27 標準コマンド
fmで具体的に何ができ、どこからが限界なのかを正確に把握したい方 -
ログ整理や画像 OCR を API 課金 0 円・通信ラグなし でシェルスクリプトや Rust ツールに組み込みたい方
-
確定申告や明細などの機密テキストを 安全にマスキングしてからクラウド AI へ渡したい 方
標準コマンドfmとクラウド最上位AIの役割比較
まず最初に押さえておきたいのは、OS 標準の fm と、Gemini 4 Argon High などのクラウド最上位 AI は「競合するライバル」ではなく、得意分野が正反対の分業パートナー だという点です。
| 比較項目 | macOS 27 標準コマンド fm |
クラウド最上位 AI(Gemini 4 Argon 等) |
|---|---|---|
| 稼働モデル規模 | AFM 3 Core(約 3B・2bit 量子化) / Advanced(20B MoE・活性 1〜4B) |
数千億〜兆クラス相当の最先端推論モデル |
| コンテキスト上限 | 最大 4,096 〜 8,192 トークン (入出力合計・日本語数千文字程度) |
数十万〜100 万トークン超 (大規模コードや複数記事の一括読解可) |
| 通信・API コスト | 完全オフライン・API 代 0 円 (何回ループ実行しても無制限) |
外部通信あり・月額プランまたは従量課金 |
| プライバシー耐性 | 端末外へのデータ送信ゼロ (生明細・スクショの直接処理に最適) |
機密性の高い生個人情報は事前マスクが安心 |
| 最適な役割分担 | 定型 JSON 抽出・ローカル OCR・個人情報検閲 | 高度なシステム設計・事実調査・長文執筆 |

ターミナルから無料で AI が呼べるなら、調べ物もブログの下書きも全部こいつに任せたらええんじゃないんか?

そこが一番危ない落とし穴なんです!裏側で動いているのはメモリ消費を極限まで削った超小型モデルなので、知識を聞くと平気で架空の話をでっち上げます。でも「目の前の短い文章を整える部品」として使うと抜群に優秀なんですよ。
macOS標準コマンドfmの基本仕様と動作要件
実務パイプラインを組む前に、macOS 27(Golden Gate)に標準搭載された fm の基本的な仕組みとハードウェア条件を確認しておきましょう。
初回セットアップと主要サブコマンドの全体像
Ollama や LM Studio のような外部ランタイムを別途インストールする必要はなく、macOS 27 のターミナルを開けば最初から /usr/bin 系コマンド感覚で呼び出せます。初回のみ管理者権限でライセンス同意を行い、対応状況を確認します。
# 初回のみ利用規約への同意を実行
sudo fm license
# 現在の Mac でオンデバイスモデルが利用可能か確認
fm available
用意されている主要サブコマンドは驚くほど実務的で、UNIX のパイプ処理(|)や自作プログラムとの連携を前提に設計されています。
-
fm respond: 単発のプロンプト応答を実行します。標準入力からのパイプ受け渡しや--schema・--image指定に対応した中核コマンドです。 -
fm schema: 出力を強制したい JSON スキーマ(型定義)を生成・検証します。 -
fm count-tokens: 渡したいテキストが上限トークン数を超えていないかを事前計測します。 -
fm serve:127.0.0.1:1976などのローカルポートで OpenAI 互換のローカル HTTP API サーバー を起動し、Rust や Python 等のアプリから高速に叩けます。 -
fm chat/fm available/fm license: 対話モードの起動、ハードウェア対応確認、初回規約同意を行います。
稼働するAFMモデル構造とトークン上限の制約
コマンドの背後で動いているのは、Apple 独自のオンデバイス言語モデル Apple Foundation Models(AFM) です。搭載チップとユニファイドメモリ容量に応じて、主に 2 種類のモデルが自動選択されます。
1 つ目は M1 / M2 世代などで標準となる AFM 3 Core で、約 30 億(3B)パラメータの Dense(密)モデルを 2bit 量子化 によって極小サイズへ圧縮したものです。2 つ目は M3 以降かつメモリ 12GB 以上の環境を目安に稼働する AFM 3 Core Advanced で、総パラメータ数は約 200 億(20B)ありながら、推論時には 1B〜4B 分のエキスパートのみを活性化させる MoE(Mixture of Experts:疎構造) を採用し、省メモリと応答速度を両立しています。
ただし、OS 常駐プロセスとして普段の作業を邪魔しないよう設計されているため、一度に扱えるコンテキスト上限は 入出力合計で最大 4,096 〜 8,192 トークン(日本語で数千文字程度)に厳しく制限されています。
Neural Engine必須とIntel機の壁
もうひとつ明確な物理条件として、fm は Apple シリコン(M1 以降)に内蔵された専用 AI 演算回路 Neural Engine(ANE) にハードウェア直結で最適化されています。
そのため、どれほどメモリを 64GB 積んで快適に動いている Intel 搭載 Mac であっても(OpenCore Legacy Patcher 等を適用した環境を含め)、ANE 非搭載のため fm available の段階で非対応となり動作させることはできません。
正規表現の超進化版として輝く実務パイプライン
「実質 1B〜4B クラスで、一度に数千文字しか読めない」と聞くとガッカリするかもしれません。しかし、発想を 180 度切り替えて grep や sed、正規表現だけでは書ききれない「表記揺れのあるテキストや画像」を型通りに整える 『正規表現の超進化版』 としてパイプラインに組み込むと、他のツールでは代替できない 3 つの武器になります。
スキーマ指定によるAPI代0円のJSON構造化抽出
スクリプトから小規模なローカル LLM を呼ぶとき、従来は「余計な挨拶文が混ざる」「勝手にキー名が変わって JSON パースが落ちる」という問題が悩みの種でした。fm は Foundation Models Framework の Guided Generation(構造化出力強制) にネイティブ対応しています。
あらかじめ fm schema で JSON の型を定義し、fm respond --schema schema.json で生ログを流し込めば、自然言語のブレを完全に封じ込めて 100% 型保証された JSON だけを返してくれます。
# 生の作業メモやログから「日付・カテゴリ・重要キーワード3つ」を型保証JSONで抽出
cat raw_note.txt | fm respond --schema note_schema.json \
"本文から日付(YYYY-MM-DD)・分類カテゴリ・重要キーワード3個を抽出してください"
たとえば数百件の雑多なメモやシステムログから「日付・カテゴリ・重要キーワード 3 つ」を抜き出してローカルの SQLite へ自動格納する前処理を回しても、API 代は 0 円・ネットワーク通信ラグもゼロ です。クォータ残量を一切気にせず for ループや Rust 製バッチから何千回でも叩けるのは圧倒的な強みです。
Vision連携で外部送信ゼロのローカル画像OCR
2 つ目の武器は、Apple の画像解析基盤である Vision framework と直結したマルチモーダル入力です。
# スクリーンショット内のエラー文言や領収書項目を外部送信ゼロで抽出
fm respond --image Screenshot.png --schema error_schema.json \
"画像内のエラーコードと発生箇所のファイル名を抽出してください"
ダイアログのスクリーンショットや書類の撮影画像を --image で渡すだけで、画像を外部のクラウドサーバーへ 1 バイトも送信することなく、端末内だけでエラー文言の抽出や自動フォルダ振り分け、リネーム処理が完結します。
クラウドAI送信前のローカル個人情報マスキング
3 つ目にして個人開発者や家庭の実務で最も頼りになるのが、クラウド最上位 AI へデータを渡す前段の「ローカル検閲官(マスキング処理)」 です。
確定申告の控除書類、銀行やクレジットカードの利用明細、医療費通知、介護保険の案内などを Gemini 4 Argon High に読み込ませて制度検算や仕訳相談をしたい場面は多々あります。しかし、氏名・住所・口座番号・被保険者番号などがそのまま書かれた生テキストをクラウドへ投げるのには心理的な抵抗が伴います。
確定申告書類・銀行明細・医療通知などの生テキストや画像を用意します。
外部通信ゼロの fm で氏名・住所・口座番号等を [氏名A] 等へ伏せ字化します。
安全な匿名化データを Gemini 4 Argon High に渡し、複雑な税務検算や設計を行います。
正規表現だけでは拾い漏らしやすい「漢字の氏名」や「表記揺れのある住所・店舗名」も、言語構造を理解する fm に数千文字ずつ通せば文脈に沿って綺麗に [氏名] [口座番号] へと置換できます。機密を守りながらクラウド最上位 AI の頭脳をフル活用できる、極めて実践的な組み合わせです。

なるほどねぇ!いきなり全部を外の AI に送るのが怖かった明細や医療費の書類も、手元の Mac の中で名前や番号を黒塗りにしてから相談すれば安心じゃね!

家の外に秘密を出さない口の堅い門番さんが、最初から OS の中に住んでくれているようなものだニャ。
絶対に使ってはいけない用途と母艦投資の考え方
便利な fm ですが、万能薬と勘違いして専門外の仕事をさせると手痛い失敗を招きます。使ってはいけない領域と、ハードウェア投資の判断基準を明確にしておきます。
知識質問でのハルシネーションと長文読解の限界
絶対に避けるべきなのは、事実確認(ファクトチェック)や一般的な知識質問 に fm を使うことです。実質 1B〜4B クラスの極小パラメータには百科事典のような知識を保持する余裕がなく、たとえば「夏目漱石の小説について教えて」と尋ねただけでも、実在しない架空の小説タイトルとそれらしいあらすじを堂々と捏造するレベルの激しいハルシネーションを起こします。
また、コンテキスト上限が 4,096〜8,192 トークン しかないため、長大な設計ドキュメントや複数の MDX 記事ファイルをまとめて読み込ませる用途、論理的な飛躍を許さない記事執筆やアーキテクチャ設計にはまったく向きません。
買い替え判断の基準と母艦移行時の快適コスト
現在 Intel 世代の Mac(64GB メモリの 27 インチ 5K iMac 等)を快適に使っている方にとって、「この fm コマンドを使うためだけに、今すぐ Apple シリコン搭載機へ買い替えるべきか?」と問われれば、答えは明確に NO(これ単体が買い替えの決定打にはならない) です。
ただし、今後 OS サポートや開発環境の世代交代に合わせて Apple シリコン搭載の Mac mini などへ母艦をセパレート移行した際には、数ギガバイト〜数十ギガバイトのメモリを常時占有する外部ローカル LLM を自分で管理しなくても、OS 標準の軽量部品として最初から fm が使える恩恵は確実に効いてきます。
- コンパクト母艦(Mac mini 標準構成〜上位 Pro 構成:約 10 万〜30 万円台想定)を毎日 8 時間 × 5 年間(約 14,600 時間)の開発・日常作業で使い倒した場合 : 1 時間あたりの快適コストは 約 7 円〜25 円前後 に収まり、手元のディスプレイ資産を活かしたまま Neural Engine 直結のローカル前処理と高速ビルド環境が手に入ります(推論)。

「何でもローカル LLM でやろう」として何十万円もメモリを盛るより、手元は OS 標準の軽い fm に任せて、難しい頭脳労働はクラウドの最上位 AI に任せる方が財布にも優しいわい!

まさに適材適所ですね!背伸びして巨大なローカルモデルを回すための過剰投資を避けられるのも、OS 標準コマンドならではのメリットです。
まとめ:最上位AIとの分業設計と導入プロンプト
macOS 27 標準の fm コマンドは、クラウド AI を置き換える存在ではなく、「手元の泥臭い前処理(JSON 型変換・画像 OCR・個人情報マスク)を 0 円かつ外部送信ゼロで片付ける OS 標準の配管部品」 です。思考・設計・執筆は Gemini 4 Argon High などの最上位モデルに任せ、定型前処理だけをローカルの fm に切り出す分業体制が最もスマートに機能します。
ご自身の Mac 環境や手元の作業に合わせて安全な自動化スクリプトを組む際は、以下のプロンプトをコピーして Gemini 4 Argon(または同等以上の最上位 AI) に貼り付け、事前調査と設計合意を行ってから導入してみてください。
以下の技術検証記事のURLを読み込み、記事内で解説されている「macOS 27標準CLI『fm』の仕様・トークン上限(4,096〜8,192)・得意領域(Guided Generationによる型保証JSON抽出/VisionローカルOCR/クラウド送信前の個人情報マスキング)と限界」を正確に前提として把握してください。
参照URL: https://lab.chihouzakki.com/blog/review/macos-27-local-llm-fm-cli-json-schema-ocr-limit-guide/
【私の現在の環境とやりたいこと】
・使用Mac / OSバージョン:(例:Mac mini M4 Pro / メモリ64GB / macOS 27)
・自動化したい手元のデータ:(例:毎月のクレカ明細テキストの個人情報マスク、スクショ画像のOCR整理、作業ログのSQLite格納など)
いきなりコードを生成せず、まず以下を順番に進めてください。
1. 私の環境で `fm available` やトークン上限(count-tokensによる分割処理)に引っかかる箇所がないかの事前確認項目を提示する
2. 「ローカルの fm に任せる前処理」と「クラウド最上位AIに任せる高度推論」の安全な2段階パイプライン構成案(JSONスキーマ案を含む)を提示し、私と合意をとる
3. 合意後に、エラーハンドリング(空白・上限超過・同名ファイル上書き防止)を備えた実装スクリプトを作成する
▲ 面倒なJSON整形や個人情報の黒塗りはOS標準の番人に任せて、人間も猫様もゆっくり休みましょう

