ハイスペックMacBook Proに替えた3連休、ローカルLLM・RAG・ファインチューニングを全部やって分かったこと

• ローカルLLM
• AI
• 地方中小企業

カンマンの貝出です。

「会社の機密データをAIに読ませたい。でも、外部のサービスには出せない」

これ、地方の中小企業で生成AIの活用を考えると、かなり早い段階でぶつかる壁なんですよ。

顧客名簿、給与台帳、見積原価、契約書、医療や介護の記録。AIに整理してもらえたら助かる情報ほど、気軽にクラウドへ送れません。そこで私は、この3連休を使って「Macの中で完結するAI」を一通り作ってみました。

やったことは3つです。ローカルLLMを動かす。社内資料を検索して答えるRAGを作る。そして、自分のメール文体を覚えさせるファインチューニングまで行う。しかも直前に、MacBook Air（M3チップ、ユニファイドメモリ24GB、SSD 1TB）から、MacBook Pro（M5 Proチップ、ユニファイドメモリ64GB、SSD 2TB）へ機種を変えました。

先に結論を言うと、かなり実用的なところまで来ています。でも「Macに入れたから安全」「学習が終わったから完成」ではありません。 むしろ実際にやってみて強く感じたのは、モデルの性能より、データの扱い方と検証の設計のほうが難しいということでした。

うまくいった話だけなら、きれいな成功事例になります。ただ、私が本当に残したいのは失敗のほうです。引用が突然出なくなった。個人情報を消したつもりが約50件残っていた。AIが「完了しました」と言ったのに終わっていなかった。自分の文体を覚えたモデルが、頼んでいない日付や添付ファイルを作った。

この3日間は、ローカルAIの可能性を確認する時間であると同時に、AIを疑う技術を身につける時間でもありました。

まず、なぜMacBook Proを買い替えたのか

今回の話は、連休の直前に届いたMacBook Proから始まります。

それまで使っていたのは、M3チップ、メモリ24GB、SSD 1TBのMacBook Airです。そこから、M5 Proチップ、メモリ64GB、SSD 2TBのMacBook Proへ変更しました。移行アシスタントを使うと、約3時間で以前の環境をほぼそのまま移せました。CursorやClaudeなど、日常的に使っている道具も違和感なく動きました。

もちろん、ブログを書くためだけなら、ここまでの構成はいりません。でも、32Bと呼ばれる約330億パラメータ級のモデルを手元で動かし、さらに学習まで行うなら、メモリの余裕が効いてきます。

Appleの公式発表では、M5 Proは最大64GBのユニファイドメモリと最大307GB/sのメモリ帯域幅に対応し、ローカルでのモデル学習も用途として挙げられています。私の実機でも、32BモデルのLoRA学習時に使ったメモリの最大値は約22.6〜23.0GBでした。OSやほかのアプリの分も必要なので、64GBにしておいたことで、学習中に普段の作業が完全に止まるような窮屈さを避けられました。

ただし、ここで勘違いしてはいけないことがあります。高いMacを買えば、自動的に良いAIができるわけではありません。 ハードウェアは実験の待ち時間と選択肢を増やしてくれます。でも、答えの正しさや情報漏えいを防いでくれるわけではないんです。

今回、高性能なMacはたしかに必要でした。でも、それ以上に必要だったのは、失敗を記録し、別の方法で再検査する仕組みでした。

ローカルLLM、RAG、ファインチューニングは何が違うのか

この3つ、ひとまとめに語られがちなんですが、役割はかなり違います。

ローカルLLMは、AIの頭脳そのものを自分のパソコンで動かすことです。ChatGPTのように外部のサーバーへ毎回問い合わせるのではなく、ダウンロードしたモデルへMacの中から質問します。

RAGは、そのAIに資料を検索させる仕組みです。就業規則、顧客対応記録、議事録などを細かく分けて検索できる形にし、質問に近い箇所を取り出してから回答させます。モデル自体に会社の知識を焼き込むのではなく、質問のたびに必要な資料を渡すイメージです。

ファインチューニングは、モデルの振る舞いを変える作業です。「どの資料を知っているか」より、「どう答えるか」を覚えさせるのに向いています。今回なら、私の短めのメール、署名、言い回し、依頼への返し方などです。

だから私は、今回の作業をこう分けました。

仕組み	今回の役割	向いていること	主な注意点
ローカルLLM	Mac内で回答を生成	外部送信を避けた推論	モデル容量、速度、設定
RAG	ダミーの社内資料を検索	根拠のある社内Q&A	検索漏れ、引用、質問の仕方
ファインチューニング	私のメール文体を学習	文体や応答形式の再現	学習データ、個人情報、創作

RAGは「知識」、ファインチューニングは「振る舞い」。 この切り分けが分かると、何でも学習させようとする失敗を減らせます。

1日目：Macの中にローカルLLMの土台を作る

最初に整えたのは、ローカルモデルを動かす環境です。

主に使ったのはOllamaとLM Studioです。Ollamaは、ターミナルからモデルを起動しやすい道具です。LM Studioは、モデルを選び、読み込み、会話やAPIサーバーとして動かすところまで画面で操作できます。

Ollamaの公式文書では、Apple MシリーズはCPUとGPUの両方に対応しています。一方で、モデルの保存には数十GBから数百GBの空きが必要になることがあると明記されています。つまり、メモリだけでなくSSD容量も効きます。今回2TBを選んだのは、複数モデルと学習後の派生モデルを保存するためでもありました。

LM Studioは、モデルをMacへ入れた後なら、ローカルサーバーとしてオフラインでも推論できます。実際、今回作った呼び出し用の小さなコマンドは、LM Studioの localhost:1234 とOllamaの localhost:11434 を自動で見分け、Mac内のモデルへ質問を渡すようにしました。

モデルは、用途ごとに試しました。軽く動かすモデルとしてOpenAIのgpt-oss-20b、日本語重視ではSwallow系、文体学習ではQwen3-Swallow-32Bを使っています。OpenAIの公式情報によると、gpt-oss-20bは21Bパラメータで、16GBのメモリでも動かせるよう設計されています。また、Qwen3-Swallowは東京科学大学のチームが公開する日英対応モデル群で、8B、30B-A3B、32Bの構成があります。

失敗その1：動いたことと、使えることを同じにした

最初は、文章が返ってきただけでかなりうれしかったんです。ネットの向こうではなく、Macの中から日本語が出てくる。これはちょっと感動します。

でも、「応答した」は合格条件として弱すぎました。

短い要約なら速い。ところが、長い資料や複雑な指示では待ち時間が増えます。32Bモデルは文体の再現力が上がる一方、4Bモデルより明らかに重い。私の実測では、32Bの生成が1秒あたり数トークンまで落ちる場面もありました。

ここで学んだのは、モデル名やベンチマークだけで選ばないことです。自社の業務で使う質問を固定し、同じ質問を複数モデルへ投げ、答え、速度、メモリ使用量を一緒に比べる。ローカルAIでは、この地味な比較が必要です。

1日目の後半：AnythingLLMでローカルRAGを作る

次に作ったのが、資料を検索して答えるRAGです。

AnythingLLMを使い、製造、会計、医療、公共・建設の4分野に分けてワークスペースを用意しました。ここで使った資料は、実在企業の機密文書ではありません。顧客名簿、給与台帳、クレーム記録、医療インシデント、技術者配置計画などを想定して作ったダミーデータです。

埋め込みモデルにはbge-m3、回答モデルにはSwallow系の30B-A3Bモデルを設定しました。質問に関係する文書を探し、その箇所を根拠として回答させます。

たとえば、製造業のダミー環境では「未対応のクレームは何件か」「年間取引額が最も大きい顧客はどこか」、会計では「税務調査の予定がある顧問先はどこか」、医療では「対策が完了していないインシデントはどれか」といった質問です。

4分野で20問を超える質問を実行し、回答、引用数、所要時間をJSONで残しました。記録に残っている23問の回答時間は9.7〜45.4秒、平均約23.9秒でした。クラウドAIの軽快さに慣れていると少し待ちます。でも、ダミーの給与や顧客情報を使った質問に、引用付きで答えられるところまでは確認できました。

さらに、テレメトリを無効にし、ローカルの回答モデルと埋め込みモデルだけを使ったうえで、Wi-Fiを切って同じ質問を実行しました。それでも回答できたので、今回の構成では推論と検索がMac内で完結していることを実機で確認できました。

失敗その2：設定は合っているのに、引用が消えた

ここで、かなり時間を使った失敗があります。

新しいワークスペースを作った直後、同じ資料を入れ、同じモデルを選んだのに、回答へ引用が付かなくなりました。内容も一般論に寄り、資料を本当に読んでいるのか分かりません。

原因は、ワークスペースのチャットモードでした。初期の「自動」のままだとエージェント側の動きになり、今回期待した引用付きのRAG回答にならないことがありました。「チャット」へ切り替えると、資料を使った回答と引用が戻りました。

これ、怖いんですよ。エラーは出ません。画面も普通です。AIもそれらしい答えを返します。でも、裏では期待した経路を通っていない。

AIの失敗は、派手に止まるより、静かに別の動きをするほうが危険です。 だから「答えが自然だった」ではなく、「引用元が合っているか」「資料にない質問へ『分からない』と言えるか」まで試す必要があります。

失敗その3：「全員挙げて」で1人しか返さなかった

単発の検索はうまくいきました。でも、「条件に当てはまる人を全員挙げて」のような列挙型の質問では、複数いるのに1人だけ返すことがありました。

RAGは、表計算ソフトのように全行を必ず走査して集計する仕組みではありません。質問に近い断片を探してモデルへ渡すため、似た情報が複数箇所に分かれていると取りこぼすことがあります。

そのため、件数集計や全件抽出をRAGだけで確定させないことにしました。全件が必要な処理は、元の表をコードで集計する。RAGは「該当記録の説明」や「関連資料を探す」用途へ寄せる。ここは業務導入でかなり大切な線引きです。

「ローカルだから安全」は半分だけ正しい

ここで、セキュリティの話を整理します。

AnythingLLMのセルフホスト版は、ローカルのLLMやベクトルデータベースを使えば、ネット接続のない環境でも動作できると公式文書に記載されています。ただし、テレメトリは任意機能として用意されています。また、OpenAI、Anthropic、Pineconeなど外部サービスを接続すれば、当然そこへデータが送られます。

つまり、アプリの名前が「ローカル」だから安全なのではありません。

確認するのは、次の3点です。

1. 回答モデルはどこで動いているか
2. 文書を数値化する埋め込みモデルはどこで動いているか
3. テレメトリ、外部ツール、クラウドのベクトルDBが有効になっていないか

今回の実験では、ここをすべてローカルへ寄せ、最後にWi-Fiを切って確認しました。ただし、モデルやアプリのダウンロード、Gmailから自分の送信済みメールを取得する準備段階ではネットを使っています。「外部送信ゼロ」と言えるのは、構成を固定した後のRAG推論と学習処理についてです。

この限定を付けずに「何も外へ出ません」と宣伝するのは危険です。ローカルAIの安心は、製品名ではなく、接続先の設計と実機確認で作るものだと分かりました。

2日目：自分のメール文体をファインチューニングする

RAGの次は、ファインチューニングです。

目的は「社内資料を覚えさせる」ことではありません。自分が普段送っているメールの短さ、言い回し、署名、返信の癖をモデルへ学ばせることです。

使ったのは、Apple silicon向けの機械学習基盤MLXと、言語モデルを動かし学習できるmlx-lmです。mlx-lmの公式文書には、LoRAとQLoRAによるファインチューニング、ローカルJSONLデータ、学習後のモデル統合までの手順があります。

LoRAは、モデル全体を一から作り直すのではなく、比較的小さな追加部分を学習させる方法です。今回のように、自分の文体や出力形式を覚えさせる実験と相性が良いんですよ。

最初は、合成データ50件と4Bモデルから始めた

いきなり実メールを使うのは危ないので、最初は架空のメール50件を作りました。モデルはQwen3-4Bです。

この小さな学習は、M5 Proで約2分半。最大メモリ使用量は約3.5GBでした。学習前は、長い前置きや説明が多く、署名も仮のままでした。学習後は、件名、要点の箇条書き、カンマンの署名といった型が出るようになりました。

ただ、これは「カンマン風の型」であって、私の本当の文体ではありません。架空データから学べるのは、架空データに書いた癖だけです。

そこで次に、直近1年の送信済みメールから147件を使いました。返信形式87件、新規送信形式60件です。実名入りの自分専用版と、人前で見せるためのマスク版を分けました。

ここから、今回いちばん怖い失敗が起きます。

失敗その4：「個人情報は全部消しました」が嘘だった

実メールをデモ用に使うため、顧客名、担当者名、会社名、住所、メールアドレスなどを伏せ字にしました。その処理を担当したAIは、「実名の残留はゼロ」と報告しました。

私は念のため、別の規則で再走査しました。

すると、約50件の残留が見つかりました。

姓だけを消して名が残っていた。登録していない会社名が残っていた。住所、顧客ドメインのURL、番組名、ビル名、社員名が残っていた。見た目では「だいたい消えている」ので、ざっと眺めただけでは通過してしまいます。

そこで、敬称の前後、伏せ字の隣、自己紹介文、会社種別、住所形式、URLとドメインなど、異なる観点の走査を4回重ねました。置換対象が残っていないことを機械的に確認し、古いマスク版モデルは「デモ使用禁止」にしました。その後、クリーン化したデータで学習し直しています。

もし「完了しました」を信じて、そのモデルをセミナーで画面共有していたら。顧客情報が出ていた可能性があります。

個人情報の処理で、AIを検査者と合格判定者の両方にしてはいけません。 この教訓は、今回の連休で最も大きなものでした。

4Bから32Bへ。賢くなったが、遅くなった

次に、ベースモデルを4BからQwen3-Swallow-32Bへ変えました。

Qwen3-Swallow-32Bは、日本語と英語の両方を対象にしたモデルです。今回はそのMLX向け4bit版を使い、LoRAで学習しました。データは、メール画面から日付や宛先行ごと雑に貼り付けても返信できるように拡張し、学習282件、検証12件に増やしました。

32Bモデルの学習は、4Bのように数分では終わりません。実名版は約1時間37分、マスク版は約1時間22分かかりました。最大メモリ使用量は約22.6〜22.7GBです。

出力はかなり本人らしくなりました。署名だけでなく、短めの書き出し、箇条書き、用件への返し方も近づきます。

でも、別の問題が出ます。

失敗その5：知らない日付や添付ファイルを作った

指示が曖昧だと、モデルが「9月9日と9月16日に実施します」「契約書とスケジュールを添付します」といった、元の依頼にない具体情報を作ることがありました。

文体は本人らしい。署名も本物らしい。だから、間違いが見つけにくくなるんです。

これはファインチューニングの大事な落とし穴です。本人らしさが上がるほど、読んだ人は内容まで正しいと感じやすい。文体の再現と、事実の正しさは別問題です。

そこで実運用では、日付、金額、添付、相手の役職などを入力側に明記することにしました。書かれていない内容を補わないよう指示し、送信前に原文と突き合わせます。

3日目：「メールを書く」から「下書きを自分の文体へ直す」へ

さらに試して気づいたのが、ゼロからメールを書かせる設計そのものに無理があるということです。

用件だけを渡し、完成メールを作らせると、モデルは足りない情報を自然に補おうとします。それなら役割を狭くして、「人間か別の仕組みが作った下書きを、私の文体へ整える」モデルにしたほうが安全です。

そこで3日目は、推敲専用モデルを作りました。

実際に送ったメール147通を正解にし、それぞれから「他人行儀な下書き」と「箇条書きメモ」の2種類をローカルモデルで逆生成しました。合計294件です。そこから学習274件、検証10件を組み、32Bモデルを約59分学習しました。最大メモリ使用量は約23.0GBでした。

この方法なら、入力と正解の事実をそろえやすくなります。モデルに新しい予定を考えさせるのではなく、入力にある内容を自分の言葉へ変えることへ集中させられます。

失敗その6：学習データを作るAIが途中で黙った

ところが、ここでもすんなりはいきませんでした。

下書きを作るローカルモデルが、考える処理だけで出力上限を使い切り、空の回答や途中で切れた文章を返したんです。初回は約2割が空または尻切れになりました。

対策として、出力上限を8192トークンまで増やし、単に文字が入っているかではなく、処理結果の finish_reason が stop になっていることを確認しました。不完全なら最大3回再実行し、生成済みの結果を保存して、中断しても続きから再開できるようにしました。

ここでも同じです。「ファイルができた」は完成ではありません。最後まで生成されたかを別の値で確認する必要があります。

失敗その7：量子化と学習データの偏りは、最後に出力へ出る

推敲モデルを実際に使うと、まれに文字が壊れたような語が混ざることがありました。4bit量子化したモデルでは、生成条件によって不自然なトークンが出ることがあります。温度を下げるか、再生成すると改善しました。

また、学習元147通のうち返信メールが多かったため、新規送信メールなのに「ご連絡ありがとうございます」が入り込むこともありました。モデルは指示を理解しているように見えても、学習データの多数派へ引っ張られます。

この2つは、モデルを大きくするだけでは直りません。新規送信と返信を分ける。評価用の固定質問を用意する。出してはいけない定型句を検査する。必要なら学習データの比率を変える。地味ですが、ここからが本当の改善です。

3連休で作れたもの

この3日間で、単なる「ローカルLLMを動かしてみた」から、次のところまで進みました。

ただ、私が成果だと思っているのはモデルの数ではありません。

「引用がない回答を信用しない」「全件集計は別の方法で確認する」「個人情報マスキングは独立した規則で再検査する」「AIの完了報告を証拠にしない」「本人らしい文章ほど事実を確認する」という運用ルールを得られたことです。

中小企業で導入するなら、いきなり本番データを入れない

ローカルAIは、中小企業にかなり相性が良いと思います。

クラウドへ出しにくい情報を扱える可能性がある。月額のAPI費用を気にせず試せる。会社ごとの資料や文体に合わせられる。小さな組織なら、意思決定から実験までが速い。

でも、最初から顧客名簿や給与台帳を入れるのはおすすめしません。

まず、実務に似せたダミーデータを作ります。次に、10〜20個の固定質問を用意します。正解だけでなく、「資料にないので分からない」と答える質問も入れます。そのうえで、引用、所要時間、取りこぼし、外部通信を記録する。そこまで通ってから、利用範囲を限定して実データへ進みます。

おすすめの順番は、次のとおりです。

1. 公開情報またはダミーデータでローカルLLMを試す
2. RAGで根拠付き回答と「分からない」を検証する
3. 個人情報を含まない文体データで小さくLoRAを試す
4. 実データを使う場合は、保存場所、権限、監査、削除手順を決める

ローカル化は、セキュリティ対策の終点ではありません。端末の暗号化、ログイン管理、バックアップ、モデルの持ち出し防止、退職者の権限削除など、通常の情報管理も必要です。

よくある質問

普通のMacでもローカルLLMは動きますか？

小さめのモデルなら動かせます。たとえばgpt-oss-20bは、OpenAIが16GBメモリでの動作を案内しています。ただし、32Bモデルの学習や複数モデルの同時利用では、メモリとSSDの余裕が必要です。最初から私と同じ64GB構成を買うより、用途を決めて小さなモデルから測るほうが安全です。

RAGを使えば、必ず資料どおりに答えますか？

答えません。検索に失敗したり、一部だけ拾ったり、資料より一般知識を優先したりします。引用元の表示、正解が分かっている質問、資料にない質問を組み合わせて検証してください。件数や全件抽出は、表計算やコードの集計と突き合わせる必要があります。

ファインチューニングすれば、会社の資料を全部覚えますか？

その設計はおすすめしません。変わる社内情報はRAG、文体や出力形式はファインチューニングと分けるほうが更新しやすく、間違いも見つけやすくなります。

本当にデータは外へ出ませんか？

構成次第です。ローカルの回答モデル、埋め込みモデル、ベクトルDBを使い、テレメトリと外部連携を無効にして初めて、推論をローカルへ閉じられます。モデルのダウンロードなど、準備時に通信が必要な処理もあります。Wi-Fiを切った実機確認と、通信ログの監査をおすすめします。

非エンジニアでもできますか？

Ollama、LM Studio、AnythingLLMで、最初の会話やRAGまではかなり始めやすくなっています。ただし、機密データを扱う本番運用では、ネットワーク、権限、個人情報、バックアップ、検証設計の知識が必要です。「画面で動いた」から一気に本番へ進まないでください。

AIは「借りる」だけでなく、自分の会社に合わせて仕込める

この3連休で、一番大きく変わったのは私の感覚です。

AIはクラウドから借りるもの、という前提が崩れました。ハイスペックなMacBook Proが1台あれば、ローカルLLMを動かし、資料検索のRAGを作り、自分の文体へファインチューニングするところまで手が届きます。

ただし、「自分で仕込める」と「自動で正しくなる」はまったく違います。

モデルは間違えます。設定は静かにずれます。マスキングは漏れます。学習データの偏りは出力へ現れます。そしてAIは、できていないのに自信を持って「完了しました」と言います。

だから、これから必要になるのは、AIを使う力だけではありません。AIの回答を検査する仕組みを作る力です。

カンマンでは、まずダミーデータを使い、外部通信、回答根拠、取りこぼし、運用手順まで確認する小さな実験から始めます。「社内データをAIで使いたいが、外へ出すのが不安」「どこまでローカルでできるのか見たい」という企業の方は、お問い合わせからご相談ください。

いきなり大きな仕組みを買う必要はありません。まずは1つの資料、10個の質問、1台の端末から試せます。

私も、連休の実験から始めました。次は、この環境を実際の業務へ安全に接続するところまで進めます。

参考・出典

• Apple：M5 Pro／M5 Max搭載MacBook Proの発表
• Ollama：macOSの動作要件と保存領域
• LM Studio：オフライン動作
• AnythingLLM：セルフホスト版のデータと通信に関する説明
• MLX LM：LoRA／QLoRAファインチューニング
• OpenAI：gpt-oss-120b／20b
• 東京科学大学 Swallow LLM：Qwen3-Swallow-32B-RL-v0.2