Mac Studio 64GBでローカルLLMの自動化を1週間試して、本番運用をやめた話
Mac Studio 64GBでローカルLLMによる記事制作の自動化を1週間試し、本番運用を見送った経緯と、64GBでも足りなかった条件を振り返ります。
Mac Studio 2025(M4 Max上位構成、メモリ64GB、SSD 1TB)を仕事のメインマシンにしています。この記事は、そのMac Studioでローカルにモデルを動かし、記事制作を自動で回す仕組みを作って試した話です。
結論を先に書くと、この取り組みは1週間ほどの構築とテストで終わりました。記事制作の本番運用には進めず、現在はローカルLLMを日常的に使っている場面はありません。何が起きて、なぜそこで止まったのかを、当時の体験に沿って振り返ります。
この挑戦で解きたかった面倒
着手した理由は、プライバシーやコストではありませんでした。自動化という仕組みを自分の手元で確かめてみたい、という技術的な興味が先にありました。AIエージェントをコードベースで組み、Pythonのファイル群としてワークフローを組み立てていく過程そのものに関心があったからです。
具体的には、記事制作という繰り返しの作業をAIエージェントに任せられないかと考えました。編集ワークフロー全体をOpenAIのSDK(Content Agent SDK)で構築し、企画から本文執筆、編集までを自動で回せる仕組みを作りました。
狙いは、記事1本を手作業で作る手間を、AIエージェントによる自動化に置き換えることでした。自分のマシン上でモデルを動かし、ワークフローとして組み立てていく過程そのものを確かめてみたい、という関心が出発点です。
Mac Studio 64GBで実際に起きたこと
試したモデルはQwen 3.6の27Bと35Bでした。動かしてみると、64GBのメモリは「全然足りなかった」というのが率直な感触です。
27Bクラスのモデルでも「ギリ読み込める」程度で、常にメモリスワップが発生している状態でした。35Bも試しましたが、今回の取材ではその挙動をこれ以上具体的には記録していません。
読み込み時間そのものは特に気になりませんでした。一方で応答速度については、「遅いっちゃ遅かったかもしれない」という体感で、はっきり快適とは言えない状態。
Qwen 3.6自体は日本語が不自然ではなく、モデルの質としては悪くない印象ですが、それを実用的なワークフローとして動かすには、Mac Studio 64GBというメモリ容量はぎりぎりで、余裕のある構成ではなかったというのが正直なところです。
ここで切り分けておきたいのは、この「足りなかった」という感触が、Mac Studioというマシン全体の性能不足を指すものではないという点です。あくまでローカルLLMをメモリに載せて動かし続けるという特定の用途において、64GBという容量が窮屈だったという話であり、Mac Studio自体の処理能力や普段の作業への評価とは別物です。この区別は、後の章でもう一度触れます。
記事1本の生成にかかった時間と、いちばん重かった検証コスト
構築したワークフローで記事は実際に生成できました。ただし6,000字程度の記事1本を作るのに、1〜2時間かかることがありました。
この1〜2時間には、再実行や出力チェック、手直しまで含まれています。リポジトリに残っている実行ログを見ると、完成までに約12〜29分で終わった例もある一方で、見出し不足や文字数不足、人手確認フラグ、モデルのアンロードによって途中で止まった例も残っていました。つまり、うまくいけば短時間で終わることもありましたが、そうならない実行が一定数あり、そのやり直しを含めた総時間が1〜2時間だったということです。
検証作業の中でいちばん手間だったのは、生成された文章の事実確認でした。原因は一つに絞れるものではなく、入力にない情報をもっともらしく補ってしまうケースと、入力にある事実を取り違えたり数字を曖昧にしたりするケースの両方が起きていました。
具体的にどの誤りが出たかは、今となっては明確には思い出せません。ただ、生成された記事は「公開する敷居値は超えなかった」という感触だけは当時から一貫していました。
事実確認という作業が重かったのには理由があります。誤りの種類が一つに絞れなかったことがそのまま効いていて、入力にない情報を補ってしまうケースと、入力にある事実を取り違えるケースの両方が起きるとなると、チェックする側は「どこか一箇所を重点的に見ればいい」というやり方ができません。結局、生成された文章を頭から終わりまで、事実の出どころが確認できるかどうか一文ずつ疑ってかかる必要があり、この総当たりの確認作業そのものが、記事1本あたりの検証コストを押し上げていました。記事を丸ごと自動化することがこのメディアに向かなかったのは、この事実確認の性質によるところが大きいと考えています。
この品質の問題を、モデルの能力不足だとは考えていません。Qwen 3.6自体は日本語として不自然ではなく、モデルとしての質は悪くありませんでした。うまくいかなかったのは、そのモデルをどう使うか、つまり編集ワークフロー側、ハーネス側の設計(コンテキスト)だったと捉えています。プロンプトの与え方や工程の切り方、途中でどこを人間の確認に戻すかといった仕組みの部分に改善の余地があったということで、モデルの責任という話ではありません。ハーネス側を洗練させればもっと品質良く使えた可能性はあると思っていますが、それには相応の時間コストがかかるとも感じています。
当時はその時間コストをかけてまで検証を続ける判断はせず、いったんこの取り組みをやめました。
Windows(RTX 4090)機でも試してみた
Mac Studioから着手した理由は、普段使いの主力機であることに加えて、LM StudioのAPIサーバーをローカルで運用する経験がまだなかったことでした。まずは慣れた環境で全体を組んでみたい、という理由です。
その後、Windows 11デスクトップ(Core i7-13700F、メモリ80GB、RTX 4090 24GB)でも同じようにLM StudioのAPIサーバーを立てて、同じ編集ワークフローを回してみました。感触としては「早くはなかった、遅かった」というもの。
編集ワークフロー全体の生成にかけると、実用的な速度には届かず、1時間程度かかることもあれば、3時間経っても終わらないこともありました。3時間経っても終わらないというのは、エラーで止まっているわけではなく、生成処理そのものがずっと回り続けている状態でした。
なぜ遅かったのかについては、正直なところ切り分けができていません。「ビデオメモリが足りなかったんじゃないかな」という感覚はありましたが、これはあくまで自分の推測であり、原因をそこに断定できるほどの検証はしていません。ここは体感の速さの印象として書くにとどめ、原因の特定はしないでおきます。
Mac Studioと違うマシン、違うOSで同じワークフローを回してもやはり実用速度には届かなかった、という結果自体は事実として残ります。ただし、その遅さの理由まで踏み込んで比較しようとすると、GPUのビデオメモリなのか、それ以外の要因なのか、当時の自分は検証していません。原因を推測で断定してしまうと、この記事の他の部分で守っている「確認できた事実だけを書く」という前提が崩れてしまうため、ここは体感の記録にとどめています。
なぜ本番運用に進めなかったのか
このAIワークフローを「毎日使っていた」と言える期間は、実際には存在しません。リポジトリを構築してテストしていた期間は約1週間で、その先の記事制作の本番運用には進みませんでした。
進めなかった理由は、Mac Studio・Windowsどちらの環境でも、生成にかかる時間と、その後の事実確認という検証コストが釣り合わなかったからです。記事1本を作るたびに1〜2時間かけて生成し、さらにその内容を人間が事実確認する手間まで足すと、手作業で書くのとどちらが早いのか怪しくなってきます。
一方で、ローカルLLM以外の普段の仕事、つまりブラウザや開発、複数アプリを並行して動かすような作業では、Mac Studio 64GBで困ることは基本的にありません。定着しなかったのはローカルLLMを使った自動化という用途だけで、マシンそのものの普段使いには不満がない、という点は分けて書いておきたいところです。
もっと現実的な次の一歩は何か
今回、企画から本文までを一気に自動化しようとしたのは、期待値としては欲張りすぎていたと思います。次に何かを試すなら、範囲を絞る必要があると感じています。
もし一つだけ先に自動化を成功させるとしたら、企画と下調べ・一次情報のリサーチだと考えています。理由は、それ以外の工程、たとえば構成や本文初稿、分類・タグ付けまでをまとめてAIに任せてしまうと、一次情報の裏付けが薄いまま文章量だけが増える「水増しコンテンツ」になりやすいと感じているからです。
これは、次に試してみたいという見通しであって、実際にその範囲を試して成功した、という話ではありません。企画・下調べ・リサーチに絞ったとしても、うまくいく保証はまだ何もない状態です。
ただし、このプロジェクトを一通り実践することによって得られた経験として、先ほど挙げたように、ハーネスとコンテキストの管理によって解消できる算段がつき始めており、適切な文脈を補える環境が用意できれば、現実には近づいていること。そして、LM Studioのオープンウェイトモデルを使うことがChatGPTやCodexのようにうまく意図をくみ取ってなんでもやってくれると勘違いしていたことを補正する良いきっかけになりました。
向いてない人
記事制作のように、高い頻度と高い品質を同時に求められる仕事でローカルLLMを使いたい人には、今回試した構成はあまり向いていなかったというのが実感です。生成にかかる時間と事実確認の手間を考えると、手作業のほうが早く済む場面が多くありました。
同じように、生成された文章を毎回自分で事実確認するという検証作業に時間をかけたくない人にも向いていません。この検証コストこそが、今回自分がいちばん重く感じた部分でした。
Mac StudioをローカルAI動作環境として買わない選択肢
ローカルでLLMを使う予定がないなら、メモリを増やさず、今のパソコン作業やクラウドのAIをそのまま使えばいいというのが、この経験を踏まえた考えです。64GBという構成そのものは、ローカルLLM以外の普段の仕事では困らない容量であり、それ以上を狙う理由はローカルLLMを使うかどうかに直結しています。
つまり、ローカルLLMを使わない読者にとっては、メモリを積み増す判断は今回の話とは切り離して考えてよい、と思います。
メモリを積むなら、という条件付きの話
一方で、ローカルLLM前提でMac Studioの構成やメモリを考えるなら、可能な範囲でメモリを多めに確保しておく、という考え方自体は今も持っています。27Bクラスのモデルでも常時メモリスワップが発生していた経験からすると、64GBは余裕のある容量ではありませんでした。
ただし、これはあくまでローカルLLMを使う前提かつ予算が許す場合の話であり、用途と予算のバランスで判断する必要がありますね。
ここまで書いてきたことを整理すると、Mac Studio 64GBという同じ一台のマシンの中で、評価が真っ二つに分かれています。
ブラウザや開発環境、複数アプリを並行して動かすような普段の仕事では、このマシンに不満を感じたことはありません。困っていたのは、あくまでローカルLLMをメモリに載せて動かし続け、それを記事制作の自動化という形で使い続けようとした場面だけでした。この二つを分けずに「ローカルLLMで重かったからMac Studioは力不足だ」とまとめてしまうと、実際に起きたこととずれてしまいます。
重かったのは常時AIモデルを読み込んだ状態を維持しながら生成と検証を繰り返すという使い方であって、マシンそのものの処理能力ではありません。ここを混同すると、普段の作業のために必要以上のメモリ容量を選んでしまったり、逆にローカルLLMを試したい人が今の構成のままで足りると判断してしまったりします。どちらも実感とは異なります。
もう一つ整理しておきたいのは、しんどかったのはメモリの窮屈さそのものよりも、その先にある検証コストだったという点です。メモリスワップが起きている状態でAIモデルを動かし、生成された記事を毎回読み返して事実確認をする。この事実確認という工程は、モデルの性能やメモリ容量をいくら積んでも消えるものではなく、生成物を人間の目でチェックし続けるという性質の面倒でした。メモリ不足はその負担を増幅させる一因ではありましたが、根本の原因ではなかったというのが、振り返っての実感です。
これから同じようなことを試そうとする読者に向けて、判断の分かれ目になりそうな条件を書いておきます。まず、普段の仕事がブラウザや開発、複数アプリの並行利用にとどまり、ローカルLLMを使う予定が今のところないなら、Mac Studio 64GBという構成のままで困ることはないはずです。この場合はメモリを積み増す理由がないので、今回の話は自分には関係のない話として読んでもらって構いません。
一方で、ローカルLLMを使った自動化を試してみたいという関心があるなら、まず考えてほしいのは、生成出力を毎回自分で事実確認する作業を引き受けられるかどうかです。AIモデルがもっともらしく情報を補ってしまったり、事実を取り違えたりすることは起こり得るという前提に立ち、その確認作業に時間を割いたり、AI制御を構築するスキルがあるかどうかが、メモリ容量そのものよりも先に考えることであると思います。
そのうえでなお試したいという場合には、可能な範囲でメモリを多めに確保しておくという考え方は今も有効だと思っています。ただし、それはあくまでローカルLLMを使う前提での話であり、普段の仕事だけを考えるなら不要な投資になります。自分がどちらの使い方をしたいのかを先に決めてから、メモリ容量を考えるという順番を崩さないことが、今回の一週間から持ち帰れる教訓だと考えています。
まとめ
Mac Studio 64GBでローカルLLMの自動化ワークフローを組み、1週間ほど構築とテストを重ねましたが、記事制作の本番運用には進まず、現在ローカルLLMを日常的に使っている場面はありません。止まった理由は、生成にかかる時間そのものよりも、生成された文章を毎回事実確認するという検証コストでした。
4つの問いに沿って振り返ると、消える予定だった面倒は記事制作の手作業でしたが、実際には事実確認という新しい面倒に置き換わっただけでした。使い始めるまでの時間は、記事1本あたり再実行込みで1〜2時間というもので、快適に使い始められる状態ではありませんでした。ローカルLLMを使わなくなった条件は、事実確認の手間と公開できる品質の敷居値が、自動化で得られる利点を上回ったことです。その結果、現在ローカルLLMを日常的に使っている場面はゼロです。買い替え後の旧機器の処分については、今回はMac StudioとWindows機という既存2台の運用の話にとどまり、買い替え自体が発生していないため、この記事の実体験の範囲では扱えません。
ローカルLLM以外の普段の仕事では、Mac Studio 64GBは今も不満なく使えています。ローカルLLMを使う予定がなければ、今の構成のままで十分だというのが、この1週間の結果から言えることです。