AIの取り説

中国のおかげ！？ アップル、AIで出遅れたはずがローカルLLMの波にたまたま乗れそうな話

Posted on by aitanuki
AppleはローカルLLMの波に乗れる！-00
12
8月

最終更新日：2026年8月12日

2026年は「エージェント元年」といわれていましたが、ローカルLLM元年、オープンウェイト元年とも言えるかもしれません！

最近は中国のオープンウェイトモデルの話で持ちきりです。

Kimi K3、GLM-5.2、DeepSeek V4。しかも全部、重みが公開されているオープンウェイトです。

オープンソース（OSS)というと語弊がありますのでここはやはりオープンウェイトで統一です。

さてそのオープンウェイトのモデル。NVIDIAもNemtron3.5を出してきました。　　　　　　　　　　　　　　　　　

ちなみにPerplexityのPro版でしたらGLM 5.2、Kimi K3が使えます。

そんな中、Metaが2026年8月10日に「Muse Glimmer」を出しました。

完全にローカルLLM狙いに振り切ったモデルです。

それでふと思ったのです。

アップルってAI競争に完全に乗り遅れたけど、ローカルLLM→エージェント化→オンプレミスAIという流れになったら、結局アップルはハード面からこの波に乗れるんじゃないの？

案外いいとこ取りできちゃうんじゃないの！？

と思ったので、この記事を書いてみました。

この記事は、AIを仕事で使っている人（エンジニアでなくてもOK）向けです。「次のマシン、MacとWindowsどっちにすべきか」「ローカルLLMって結局うちの業務で使えるのか」を判断できる材料をまとめました。

結論から書きます。アップルはAI競争で出遅れた、これは事実です。ただ、省電力のために作ったユニファイドメモリという設計が、後から来たローカルLLMの波にたまたま噛み合ってしまった。

先読みではなく結果論です。

そして実務では「ローカルLLMかClaudeか」ではなく、両方を振り分けて使う流れになりました。

前半は一般向け、後半（【技術編】以降）はメモリ計算や帯域の話を含む技術寄りの内容です。必要なところから読んでください。

まず、2026年に何が起きたのか

「中国のおかげ」と書いた理由から先に説明します。

2026年の前半、中国勢がオープンウェイトモデルを立て続けに出しました。

モデル公開規模ライセンス
DeepSeek V4 Pro2026年4月総1.6T／アクティブ約49BMIT
GLM-5.2（Zhipu AI）2026年6月約750B（MoE）MIT
Kimi K3（Moonshot AI）2026年7月総2.8T（MoE）オープンウェイト

いずれも100万トークン級のコンテキストを持っていて、クローズドの最上位モデルに近いスコアを出しながら、トークン単価は5分の1から30分の1。OpenRouterのトークン消費では、中国製モデルが約6割を占めるところまで来ています。

2026年の8月12日に、Anthropicが9月から値上げ予定だったSonnet5のトークン価格を据え置くことを決めました。これらオープンウェイトの影響があったと考えられます。

ここで1つ、はっきりさせておきたいことがあります。

この3つは、あなたのMacでは動きません。

Kimi K3は2.8兆パラメータです。4bitに落としても1TB以上のメモリが要ります。GLM-5.2の750Bでも、4bitで400GB前後。個人のマシンに載る規模ではありません。「オープンウェイト＝手元で動く」ではないのです。

じゃあ中国勢は関係ないのかというと、そうでもない。効いたのはこの2点だと思っています。

  1. オープンウェイトが当たり前になった：重みを公開しても事業が成立する、が実証された
  2. 価格の天井が下がった：クローズドの側が値上げしづらくなった

そして、この空気の中でMetaが出してきたのが、サイズを個人のマシンに合わせにきたMuse Glimmerでした。中国勢が「クラウドを安くする」方向に振ったのに対して、Metaは「手元に降ろす」方向に振ってきた。ここが今回のポイントです。

「アップルはAIで遅れた」がずっと定番だった

ここ数年、「アップルはAI競争で出遅れた」という話をよく見かけました。

最近はアップルはすでにAI競争には入っておらず、そんな話題すら聞きませんでした。

ChatGPT、Claude、Geminiがどんどん進化していくなかで、アップルの動きは地味中の地味に見えていました。Apple Intelligenceも、期待されたほどのインパクトをありません。

私もそう思っています。

最先端の巨大モデルを作る競争には、アップルはほぼ参加できていない、と。データセンター用のGPUも作っていないし、フロンティアモデルも出していない。この土俵では勝負になっていません。

ただ最近、ちょっと違う角度からこの話を見直すようになりました。

きっかけは、勝負している土俵が1つじゃなくなったことです。

潮目を変えたのは、クラウドではなく「手元で動く」ほう

ここで用語を1つ。「オープンウェイト」というのは、モデルの中身（重み）が公開されていて、ダウンロードして自分で動かせるモデルのことです。APIを叩くのではなく、自分のマシンの中で完結します。ネットが切れても動く。データも外に出ない。

ただし、さっき書いたとおり公開されていても手元で動くとは限りません。載るサイズかどうかは別問題です。

そこを狙い撃ちにしてきたのが、Muse Glimmerでした。

マーク・ザッカーバーグは好きじゃないがこいつはすごい

Muse Glimmerが引いた「30Bが手元で動く」という基準線

分かりやすい例が、2026年8月10日にMetaが公開した「Muse Glimmer」です。

このモデルの何がインパクトだったかというと、300億パラメータ（30B）のモデルを、GPU1枚のPCやMacで動かす前提で設計してあるところです。しかもライセンスはApache 2.0。商用利用も再配布も自由です。

これはやばい！というか、ちょっと見直したマーク。

構成はこうなっています。

  • 全体で30B、内訳は「2Bの画像エンコーダ（Perception Encoder）＋28Bのテキストデコーダ」
  • 画像も動画も、そのまま入力できる
  • コンテキスト長は最大131Kトークン
  • llama.cpp、transformers、vLLMに公開初日から対応

そしてメモリまわりの設計が具体的です。Metaは4bit量子化版を2種類配布していて、

  • K-Quant-17GB：24GBのGPU向け。性能劣化は約1.0%
  • K-Quant-Dynamic：32GBのGPU向け。性能劣化は約0.2%

という切り分けになっています。full精度だと55GB超が必要なモデルを、17GB前後まで落として「24GBあれば入る」ラインに合わせにきています。

ここまで具体的にコンシューマー機のメモリ容量を狙ってチューニングされたモデルが、公式から出てきた。これが基準線を引き直したと思っています。

M5 MacBookPro 48Gモデルで十分動くではないか。誰か買ってくれ！

ただしベンチマークは「全勝」ではない

ここは誤解が広がりやすいところなので、正確に書いておきます。

Metaが公開したベンチマーク表では、エージェント系の8項目のうち5項目で、同クラスのGemma4-31BとQwen3.6-27Bを上回っています。

ベンチマークMuse Glimmer-30BGemma4-31BQwen3.6-27B
MCP Atlas75.554.262.5
DeepSearch QA74.661.771.1
SWE-Bench Pro51.236.950.2
SWE-Bench Verified76.066.677.2
TerminalBench 2.151.743.460.7
OSWorld-Verified65.958.575.6

（出典：Meta公表値／Hugging Face公式ブログ）

下3行を見てください。

コーディングとPC操作の一部では、Meta自身の表の中でQwen3.6-27Bに負けています。

だから「Muse Glimmerが最強」ではありません。正しくは「MCPを使ったツール呼び出しや調査タスクでは強い、コーディングはQwenのほうが上の項目もある」です。

用途で選ぶ話であって、1つ選べば済む話ではなくなっている。ここが今のオープンウェイトの現状だと思います。

同じ週に、Claudeが値上げを取り消した

もう1つ、同じタイミングで起きたことがあります。

Anthropicは2026年6月にClaude Sonnet 5を出したとき、100万トークンあたり入力$2／出力$10という価格を「8月31日までの導入価格」として設定していました。9月1日からは$3／$15に上がる予定だったわけです。

これを2026年8月10日、撤回しました。$2／$10のまま恒久化する、と。

理由についてAnthropicは明言していません。ただ、報道で直近の文脈として挙げられているのは、OpenAIが最大80%規模の値下げをしたことと、企業側のAIコストが膨らみすぎていることです。

ここから先は私の推測です。

オープンウェイトの性能が上がるほど、ユーザー側には「高くなったら手元に降ろせばいい」という逃げ道ができます。全部を置き換える必要はなくて、量が多くて単価の安い処理だけローカルに逃がせば、請求額はけっこう変わります。この逃げ道の存在が、値上げの判断を鈍らせる方向に効いていても不思議ではない。

ただ、オープンウェイトだけが理由だとは思っていません。直接効いたのは、たぶんOpenAIの値下げのほうです。オープンウェイトは、その後ろでじわじわ効く二段目の圧力、くらいの位置づけで見ています。

いずれにしても、「クラウドの最強モデルを追いかける競争」とは別に、「手元のマシンでそこそこ賢いAIを動かす」という土俵が急に現実的になってきた。ここは間違いないと思います。

で、気づいたらアップルのハードがこの土俵に合っていた

ここが今回いちばん面白いと思ったところです。

ローカルLLMのボトルネックは「速さ」ではなく「載るかどうか」

ローカルでLLMを動かすとき、最初に立ちはだかるのは処理速度ではありません。

モデルの重みを、どれだけメモリに載せられるか。ここです。

載らなければ、速い遅い以前に起動すらしません。載せるためにディスクとスワップさせると、体感で数十倍遅くなって使い物になりません。まず載る、話はそれからです。

WindowsのNVIDIA GPUだと、GPU専用のVRAMがそのまま上限になります。

  • RTX 4090：24GB
  • RTX 5090：32GB

30Bクラスの4bit量子化（17GB前後）までは、ここに収まります。ところが70Bクラスになると4bitでも40GB前後になるので、1枚では載りません。GPUを2枚差すか、諦めるかになります。電源もケースもマザーボードも作り直しです。

一方でアップルのMacは、CPUとGPUとNeural Engineが同じメモリを共有する「ユニファイドメモリ」という設計です。48GB、64GB、128GBといった構成を選べば、その大部分をそのままモデルの置き場所として使えます。

たとえば2026年3月に出たM5 Maxは、最大128GBのユニファイドメモリを積めます。70Bクラスを1台で、追加のGPUなしで動かせるわけです。

ただし 1,167,800円〜1,389,800円（4T）になりますが。

でもノートPCに700億パラメーターのAIが載ってしまう。しかもMacで動くこの事実がたまらない。

ただし、アップルがAIを見越して作った設計ではない

ここは前に書いたときに雑だったので、正確に書き直します。

ユニファイドメモリは、CPUとGPUとNeural Engineが単一のメモリプールを共有する設計です。目的は、データをいちいちコピーせずに受け渡すこと、消費電力を下げること、そして筐体を薄く静かにすることでした。

ここでポイントが1つあります。

Neural Engineが最初から共有先に入っている以上、「機械学習を想定していなかった」は言いすぎです。

オンデバイスの機械学習は、M1の時点で設計の射程に入っていました。

写真の被写体認識も、音声入力も、この上で動いています。

想定外だったのは、用途ではなく規模のほうです。

数百MBの画像認識モデルを想定して作った共有メモリの上で、数十GBの言語モデルが動くことになった。この規模の飛躍までは織り込んでいなかったはずです。少なくとも、アップルが「大規模言語モデルのローカル実行を見越して設計した」と公式に述べたことはありません。

なので、正確な言い方はこうなります。

  • AI向けの巨大チップを作る競争には乗れなかった
  • でも、省電力と統合のために作った設計が
  • 想定より2〜3桁大きいモデルの受け皿として、たまたま機能した

狙って波に乗ったのではなく、たまたま持っていた板の形が、来た波にちょうど合っていた。この理解が実態に近いと思っています。

へたにAIの開発競争に乗り込んでいたら、今回のオープンウェイトLLMの流れにダメージを受けていたかもしれないですし、そう考えると今が最善の立ち位置かもしれません。

じゃあNVIDIAより速いのか、というとそれは違う

ここは誤解しやすいところなので、数字で整理します。

純粋な生成速度で比べると、NVIDIAのほうが基本的に速いです。理由はメモリ帯域です。

メモリ容量メモリ帯域
RTX 409024GB約1,008GB/s
RTX 509032GB約1,792GB/s
M5 Max（40コアGPU）最大128GB614GB/s
M5 Max（32コアGPU）最大36GB460GB/s

RTX 5090とM5 Maxで、帯域に3倍近い差があります。後述しますが、LLMの生成速度はほぼこの帯域で決まります。同じモデルを載せたら、5090のほうが素直に速い。

アップルが強いのは「速さ」ではありません。大きいモデルを、静かに、省電力で、1台にまとめて動かせるところです。

住み分けるとこうなります。

  • 小〜中型モデル（7B〜32B）を高速に回したい → NVIDIA
  • 70B級を複数GPUなしで1台で動かしたい → Apple Silicon
  • 学習・ファインチューニング・CUDA前提の開発 → NVIDIA（ここは差が大きい）
  • 動画編集や開発もするマシンに、ローカルAIも同居させたい → Apple Silicon
  • 持ち歩く／ファンの音が嫌／電気代が気になる → Apple Silicon

「Macが勝った」のではなく、「勝てる土俵が1つ増えた」が正しい表現だと思います。

【技術編】自分のマシンで何が動くのか、計算してみる

ここから技術寄りの話です。買う前に机上で判断できるように、計算の仕方を書きます。

必要メモリの概算式

一番シンプルな式はこれです。

必要メモリ(GB) ≒ パラメータ数(B) × 量子化ビット数 ÷ 8

30Bモデルを4bitで動かすなら、

30 × 4 ÷ 8 = 15GB

実際にはこれに上乗せがあります。

  • 埋め込み層や一部のレイヤーは高精度のまま残ることが多い
  • 量子化のスケール値などのメタデータ
  • 結果として、Muse Glimmerの4bit版は約17GB

さらにここに以下が乗ります。

  • KVキャッシュ：生成中の文脈を保持する領域。コンテキストが長いほど増える
  • 画像エンコーダ：マルチモーダルモデルの場合
  • 投機的デコード用のドラフターモデル：使う場合
  • OSと他のアプリ：8〜16GBは残しておきたい

Muse Glimmerが「17GBのモデルなのに24GB envelope」と言っているのは、この上乗せ分を見込んでいるからです。131Kのコンテキストをフルに使うなら、KVキャッシュだけで数GB単位で追加が必要になります。

ちなみにMuse Glimmerは、KVキャッシュを削るための工夫を入れています。Gated Grouped-Query Attentionという方式で、1つのKVヘッドを16個のクエリヘッドで共有しています。これでKVキャッシュのメモリが16分の1になります。加えて、52層のうち4層に1層だけをフルアテンションにして、残り3層は2,048トークンのスライディングウィンドウにしている。長文を扱ってもメモリが爆発しない設計です。

「コンシューマー機に載せる」という制約から逆算してアーキテクチャを決めている感じがして、ここは素直に良くできていると思いました。

Macのメモリは全部AIに使えるわけではない

これは知らないと確実にハマるところです。

macOSは、GPUが確保できるメモリ量に上限をかけています。
デフォルトはおおむね総メモリの75%程度です。
実際にMetalから使える量は60〜70%と報告されることが多いです。

つまり64GBのMacでも、素のままだと40GB前後しかモデルに回せません。「64GBあるから70Bの4bit（40GB）が入るはず」と思って買うと、ギリギリで落ちます。

この上限は変更できます。

# 128GBマシンで120GBまで許可する例
sudo sysctl iogpu.wired_limit_mb=122880

再起動は不要で、即時反映されます。ただし全部を割り当てるのはダメです。OSが使う分として8〜16GBは必ず残してください。残さないと、モデルは載ってもmacOS側がスワップし始めて全体が固まります。

M1 MacBookPro 16Gで　8B（80億パラメーター）のモデルを動かしただけで僕のMBPは硬直していました笑

購入前の目安としては、動かしたいモデルのサイズ × 1.5〜2倍のメモリを積んでおくと安全です。
40GBのモデルを常用したいなら、64GBではなく96GB以上を検討したほうがいいと思います。

までも自分は48GのMBPで良いかなとおもっています。研究開発しているわけじゃないし。

日常でHermesエージェントというローカルAIエージェントを動かし、ClaudeやCodeに繋ぎつつ、マークのAIをローカルで動かすみたいなのが理想です。

メモリ帯域から生成速度を見積もる

LLMの生成（デコード）は、トークンを1つ出すたびにモデルの重み全体をメモリから読み出します。だから理論上の上限速度はこう出ます。

理論上限(tok/s) ≒ メモリ帯域(GB/s) ÷ モデルサイズ(GB)

4bit 30Bモデル（17GB）で計算してみます。

  • RTX 5090：1,792 ÷ 17 ≒ 105 tok/s
  • RTX 4090：1,008 ÷ 17 ≒ 59 tok/s
  • M5 Max（40コア）：614 ÷ 17 ≒ 36 tok/s

4bit 70Bモデル（約40GB）だとこうなります。

  • RTX 5090：載らない（32GB上限）
  • M5 Max 128GB：614 ÷ 40 ≒ 15 tok/s

注意点を2つ。

1つ目。これは理論上限であって実測値ではありません。実際は推論エンジンの実装、バッチサイズ、コンテキスト長、サンプリング設定によって、この5〜7割くらいに落ちます。5090で105と出ていても、実測は60〜70前後を見ておくのが現実的です。

2つ目。この式が効くのは生成フェーズだけです。プロンプトを読み込むフェーズ（prefill）は計算量で決まるので、演算性能の高いNVIDIAがさらに有利になります。長いドキュメントを読ませる用途だと、体感差はもっと開きます。

それでも、この表が示していることははっきりしています。

5090は速いが40GBのモデルは載らない。M5 Maxは遅いが載る。「速いほうが偉い」ではなく、「そもそも動くかどうか」で選択肢が分かれるということです。

投機的デコードで速度を補う

帯域で不利な側が使える手が1つあります。投機的デコード（speculative decoding）です。

小さくて速い「下書き役」のモデルに何トークンか先読みさせて、本体のモデルにまとめて検証させる。当たっていればそのまま採用するので、1回のメモリ読み出しで複数トークン進められます。出力は変わらないまま速くなります。

Muse Glimmerは、DFlashという方式のドラフターモデルを最初から同梱しています。llama.cppでもtransformersでも初日から使えます。

llama serve -hf meta-models/Muse-Glimmer-30B-GGUF \
  --spec-type draft-dflash --spec-draft-n-max 15

Meta側は「構造化された出力（コード生成など）で特に効く」と説明しています。コードは次に来るトークンが予測しやすいので、下書き役の的中率が上がるからです。

ドラフター分のメモリは追加で食います。メモリと速度のトレードオフです。

MLXという変数

もう1つ、Apple側の変数としてMLXがあります。Apple Siliconのユニファイドメモリ前提で書かれた機械学習フレームワークです。llama.cppがあらゆるハードで動くことを優先しているのに対して、MLXはApple Siliconに絞って最適化していて、同じモデル・同じ量子化でもMLX版のほうが速いケースがあります。

ここをアップルがどれだけ本気で伸ばすかが分かれ目だと思っています。ハードの強み（大容量メモリ）にソフトの最適化が乗ってこなければ、「メモリは積めるけど遅いマシン」のままで終わります。

実務ではどう使い分けるのがいいのか

技術の話はここまでにして、業務にどう落とすかを書きます。

私が考えていて行き着いたのは、「ローカルLLMでClaudeを置き換える」のではなく、振り分けるのが現実的、ということです。

先に書いた日常でHermesエージェントというローカルAIエージェントを動かし、ClaudeやCodeに繋ぎつつ、Muse Glimmerを動かす。今はM1 MBP 16GなのでCodexに繋ぐだけにしています。

16Gのメモリだと4Bのモデルしか動きませんし、それでも回答に数秒かかります。

とはいえ少し大きめのメモリを積んだマシンならローカルLLMとClaudeLLMのオーケストレーションといわれる振り分けの流れですかね。

振り分けの基準は4つ

タスクをどっちに投げるか、この4つで判断すると迷いません。

  1. 機密性：外に出せないデータか。ここは判断の余地なくローカル。性能が多少落ちても、外に出さない価値が上回ります
  2. 量：同じ処理を何千回も回すのか、1回だけか。回数が万単位になると単価差が効いてきます
  3. 難易度：判断が必要か、変換だけか。「問い合わせを5分類に振り分ける」はローカルで十分、「この設計でいいか判断して」はクラウドです
  4. 失敗コスト：間違ったとき誰が困るか。社内の下書きと、顧客に出る文面では話が別です

この4つで切ると、こう分かれます。

  • 毎日の定型処理（データ整形、分類、タグ付け、下書き作成）→ ローカルLLM
  • 外に出したくないデータの処理 → ローカルLLM
  • 大量バッチ（数千件の要約、数万件の分類）→ ローカルLLM
  • 難しい判断、複雑な実装、重要なレビュー → Claudeなどのクラウド側
  • 顧客に直接出る成果物 → クラウド側（＋人間の確認）

「AIルーター」という中間層

そして、この間をつなぐ仕組みが要ります。

タスクが来たときに、上の4基準で判定して、ローカルに投げるかクラウドに投げるかを自動で決める層。呼び方は何でもいいですが、私は「AIルーター」と呼んでいます。

作るなら最低限これだけあれば動きます。

  1. 分類ルール：タスクの種類を判定する（キーワードでもいいし、ローカルの小さいモデルに判定させてもいい）
  2. 機密フラグ：入力データに機密指定があればクラウド行きを禁止する
  3. フォールバック：ローカルの出力が閾値以下（空、極端に短い、フォーマット違反）ならクラウドに投げ直す
  4. ログ：どっちに投げて、いくらかかって、やり直しが何回発生したか

3番目のフォールバックが肝です。ローカルLLMは30Bクラスでも指示を外すことがあります。外れたときに黙って壊れた結果を返すのが一番まずい。検証ルールを先に決めて、ダメなら上に投げる。これがないと運用に乗りません。

この設計にすると、ローカルLLMの位置づけがはっきりします。

Claudeの安い代役ではなく、Claudeレベルの判断を大量の業務に安く展開するための中間層です。

判断そのものはクラウドで作り、その判断を型にして、実行はローカルで大量に回す。この形が今のところ一番コスパが良いですし現実的です。

でも完全に機密情報を外に出したくない！というならオンプレミスAIになります。

まさかオンプレサーバーからクラウド全盛になったとおもったら、AIが今度はオンプレ需要が出てくるとは。。。

よくある質問

Q：ローカルLLMを動かすには何GBのメモリが必要ですか？

A：4bit量子化なら「パラメータ数(B) × 0.6GB」が目安です。30Bなら約17GB、70Bなら約40GB。これにOS分とKVキャッシュで8〜16GBを足してください。

Q：MacとNVIDIA、ローカルLLMにはどっちがいいですか？

A：32B以下を速く回すならNVIDIA、70B級を1台で動かすならMacです。学習やファインチューニングをするならNVIDIA一択です。用途で決まります。

Q：Muse Glimmerは無料で商用利用できますか？

A：できます。Apache 2.0ライセンスなので、商用利用も改変も再配布も可能です。Hugging Faceからダウンロードして、llama.cppですぐ動かせます。

Q：Macのユニファイドメモリは全部AIに使えますか？

A：使えません。macOSのデフォルト上限は総メモリの約75%程度です。sudo sysctl iogpu.wired_limit_mb で引き上げられますが、OS用に8〜16GBは残してください。

Q：ローカルLLMでClaudeを完全に置き換えられますか？

A：現時点では難しいです。複雑な判断や重要なレビューはクラウドの上位モデルが上です。定型処理と機密データをローカルに逃がす使い分けが現実的です。

Q：Muse Glimmerはコーディングに一番強いモデルですか？

A：違います。Meta公表の表でも、SWE-Bench VerifiedやTerminalBenchではQwen3.6-27Bが上回っています。強いのはMCPを使ったツール呼び出しと調査系タスクです。

まとめ：この記事のポイント

  • アップルはAI競争で出遅れたが、省電力のために作ったユニファイドメモリがローカルLLMの受け皿としてたまたま噛み合った（先読みではない）
  • ユニファイドメモリはNeural Engineを含む設計なので「機械学習を想定していなかった」は誤り。想定外だったのは用途ではなくモデルの規模
  • 生成速度はメモリ帯域で決まるのでNVIDIAが速い。Macの強みは速さではなく、大きいモデルが1台に載ること
  • Macのメモリは総容量の約75%までしかGPUに回せない。買うときは動かしたいモデルの1.5〜2倍を積む
  • ローカルLLMはClaudeの代役ではなく、機密データと大量定型処理を担う中間層。振り分けにはフォールバック付きのAIルーターが要る

オープンウェイトの性能が上がるほど、「どのモデルを使うか」より「どのタスクをどこに投げるか」の設計が効いてきます。モデル選びで悩む時間を、振り分け設計に回したほうが結果は出ると思います。

私自身も、手元のマシンでどこまで業務を降ろせるか、これから実際に検証していきます。結果はまた書きます。

出典

aitanuki

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です