ローカルとクラウドの担当を決める — 用途で振り分けるAI環境構築の逆引きガイド

手元でAIを動かす話には、ひとつの落とし穴がある。全部を手元に移そうとすることだ。移してみると、速度が足りない、品質が届かない、結局クラウドに戻る。そして「ローカルは使えなかった」という結論だけが残る。

現実的な答えは二択ではない。仕事ごとに置き場所を決めるという配分の問題になる。本記事では、用途から引ける形で振り分けの基準をまとめ、AI環境構築を始めるときの構成を3パターン示す。数値はすべて公式ソースで確認済みのものを使い、仮定値には仮定と明記する。

まず、二択で考えるのをやめる

判断を難しくしているのは、クラウドを1つの塊として見ていることだ。実際には、クラウドの中に大きな価格差がある。

いずれも100万トークンあたりで、2026年8月19日に各社公式ページから取得した値だ。出力単価で見ると、最上位と最下位で20倍以上ひらく。

つまり選択肢は「クラウドか手元か」ではなく、「クラウドの上位／クラウドの下位／手元」の3層になる。この3層で考え始めると、判断がはるかに楽になる。

なお Claude Sonnet 5 の $2 / $10 は、当初2026年8月31日までの導入価格として発表されたが、公式ページには9月1日に予定されていた引き上げは行われず標準価格になったと明記されている。Gemini 3.7 Flash の $0.75 / $3.75 は2026年12月31日までで、2027年1月1日から倍になる。単価は動くので、判断のたびに確認する。

用途から引く振り分け表

では何をどこに置くか。用途別に整理する。

この表の背後にある判断軸は2つに集約できる。その仕事は失敗しても安いか、そしてそのデータは外に出せるかである。

失敗しても安い仕事は、試行回数を稼げる手元が向く。1回で決めたい仕事は、品質の天井が高いクラウド上位が向く。データを外に出せないなら、他の条件に関係なく手元しかない。

いくつかの行について、判断の理由を補足しておく。

長い資料の読解をクラウドに置く理由は、入力量がそのままメモリ要求になるからだ。手元で長いコンテキストを扱うと、モデル本体とは別にキャッシュが膨らむ。一方クラウド側は、100万トークン規模のコンテキストを標準単価で扱える構成が用意されている。得意分野が構造的に分かれている箇所だと言える。

コード生成が2行に分かれている理由は、同じコード生成でも要求が違うためだ。定型的な補完や書式変換は、手元のモデルでも通る。対して、複数の条件を同時に満たす設計判断は多段の推論になり、途中で筋を見失いやすい。同じ名前の作業でも、中身で置き場所が変わる。

画像が2行に分かれている理由も同様で、量産と一発仕上げは別の仕事だ。10枚出して1枚選ぶ作り方は手元が圧倒的に有利になる。逆に1枚に品質を求める場面では、捨てる枚数が少ないので従量課金の不利が効かない。

判断の順序を決める

表を引くより先に、順序を決めておくほうが確実だ。上から順に見ていく。

1. その仕事にデータの外部送信の制約があるか。あるなら手元一択。ここで終わる
2. 制約がないなら、クラウドの下位ティアで足りないか試す。Luna や Flash 級で足りる仕事は驚くほど多い
3. 量が多くて金額が積み上がるなら、手元へ移す候補にする
4. 移す前に、品質要求を手元のモデルが満たすか小さく検証する

多くの人が2番を飛ばして4番へ行く。しかし前掲の表が示すとおり、クラウド内で下に降りるだけで20分の1になる。機材を買う前に試す価値がある。

2番を試すときのコツを書いておく。いきなり全部を下位に落とさず、1つの仕事だけで比べる。実際に金を払っている処理を1つ選び、同じ入力を上位と下位の両方に通して結果を見比べる。この比較は数分で終わり、費用もほとんどかからない。

比べる観点は品質の総合点ではなく、その仕事で必要な水準を満たすかの一点でよい。分類なら正解率、書式変換なら形式の崩れ、要約なら落としてほしくない情報が残っているか。満たしているなら下位で確定してよく、そこで判断は終わる。

この検証を省くと、根拠のない安心のために10倍以上の単価を払い続けることになる。上位モデルを使っているという事実は、上位が必要だという証拠ではない。

損益分岐を計算しておく

コストを理由に移すなら、分岐点を出しておきたい。式は単純で、初期投資 ÷ 月あたりの削減額 = 回収月数になる。

前提を置く。1日30回、1回あたり入力8,000トークン・出力2,000トークンの仕事。月30日で入力7.2Mトークン・出力1.8Mトークン。為替は1ドル150円と仮定する。手元側は300Wで1日2時間の稼働とし、電力の目安単価31円/kWhで月558円。GPUに15万円を投じたと仮定する。

なお電力の目安単価は公益社団法人 全国家庭電気製品公正取引協議会が示す値で、同協議会も明記しているとおり実際の料金は契約する小売電気事業者により異なる。

最安ティア相手では、手元のほうが高い。電気代558円に対してクラウドが540円だからだ。上位モデルを常用しているなら1年程度で回収できるが、その場合も同じ品質が手元で出るかという別の問いが残る。

この表の読み方で大事なのは、回収月数が長い側を見ることだ。約119ヶ月という数字が出たら、それは「10年使えば元が取れる」という意味ではない。機材の寿命やモデルの世代交代を考えれば、実質的に回収できないと読むべきだろう。数字が三桁になった時点で、コストは移設の理由にならない。

逆に、13ヶ月という数字は現実的な範囲に入る。ただしこの前提は上位モデルを毎日30回使うという想定であり、使用量が半分なら回収も倍かかる。自分の実際の使用量で計算し直すことを勧める。式さえ持っていれば、前提を差し替えるだけで済む。

この計算の詳しい組み立てはクラウドAIの請求書を見てローカルAIを考え直す（2026-08-24 公開）で扱っている。

必要な容量を計算する

手元に移すと決めたら、次は容量だ。ここは計算で出る。

必要バイト数 = パラメータ数 × 1パラメータあたりのビット数 ÷ 8

ビット数は量子化形式で決まる。よく使われる Q4_K_M の実ビット数は 4.8944 で、名前の4より2割ほど大きい。この式が正しいことは、公式の実測表2件と突き合わせて確認できる。

公式モデルカードに必要メモリが明記されている例では、gpt-oss-20b が「16GBのメモリで動く」とされている。ここが1つの目安になる。

計算の詳細と、コンテキスト長が効くKVキャッシュの扱いは手元のVRAMで動くモデルを見積もる（2026-08-25 公開）で扱った。

見積もりの段階でよくある取り違えを1つ挙げておく。MoE 構造のモデルは、総パラメータとアクティブパラメータの2つが併記される。メモリに載せる必要があるのは総パラメータのほうで、アクティブパラメータは生成速度に効く数字だ。「アクティブ3Bだから軽い」と考えて落とすと、実際には10倍以上のメモリを要求されて起動しない。計算量とメモリ量は別の話になる。

予算別の3構成

構成の考え方を3つ示す。価格は変動が大きいので書かない。

構成A: 既存機で始める。すでにGPUを持っているなら、まずそれで動かす。8GBでも8B級のモデルは動く。追加投資ゼロで、自分の仕事に何が足りないかが分かる。ここを飛ばして買うのが一番高くつく。

構成B: 単体GPUを足す。足りないと分かってから、必要な容量を基準に選ぶ。注意点として、上位モデルほど容量が大きいとは限らない。現行では、下位モデルの16GB構成が上位モデルの12GBを上回る例がある。格付けではなく容量の数字を直接見る。

構成C: 統合メモリ機。単体GPUで届かない容量が要るとき、または静音性と省スペースを優先するときの選択肢になる。メモリ帯域は構成により120GB/sから819GB/sまで幅がある。後から増設できないので、買う時点で必要量を決めきる。

機材の選び方はAIのために買うなら何から買うか（2026-08-29 公開）で詳しく扱っている。電気代は最上位と下位で月800円ほどの差にしかならず、選定の主要因にはならないというのがそこでの結論だ。

3つの構成のうち、構成Aの価値は繰り返し強調しておきたい。何が足りないかを知らずに買うのが、最も高くつく。1か月使ってみれば、足りないのが容量なのか速度なのか品質なのかが具体的に分かる。容量なら次の構成が決まるし、品質ならそもそも手元向きの仕事ではなかったという結論になる。

そして構成Aを試した結果、買わずに済むことがある。分類や書式変換しかしないなら、既存の8GBで完結する。機材の話をするときに「買わない」という結論を選択肢から外さないほうが、判断は健全になる。

実行環境と接続を決める

モデルと機材が決まったら、動かし方を決める。

主要な実行環境は llama.cpp の llama-server、Ollama、LM Studio、vLLM で、いずれも OpenAI互換のエンドポイントを提供している。したがってクライアント側は接続先を差し替えるだけで、ローカルとクラウドを切り替えられる。

この性質は AI環境構築において決定的に重要だ。最初から切り替え点を作っておけば、後で配分を変えるのが安くなる。逆に特定の環境に密結合させると、乗り換えのたびに書き直しになる。

道具をモデルに持たせるなら、MCP という選択肢がある。サーバー側は Tools / Resources / Prompts の3種類を提供する設計で、道具の実装をアプリケーションから切り離せる。ただし仕様版 2026-07-28 で Sampling と Logging が非推奨になっているので、版を確認してから設計する。詳細はローカルLLMのツール呼び出しを実務に繋ぐ（2026-08-26 公開）にまとめた。

ライセンスを最後に確認しない

移設の作業で最も後回しにされやすく、そして最も痛いのがライセンスの確認だ。

具体例を挙げる。FLUX.1 [dev] は、生成物の商用利用は §2(d) で明確に許可されている一方、モデルの利用自体は §2(b) で非商用に限定されている。モデルカードの要約だけを読むと、この分岐を見落とす。収益を伴う用途なら、Apache 2.0 の FLUX.1 [schnell] を選ぶか、商用ライセンスを申請するかになる。

言語モデル側では、gpt-oss 系や Qwen3 系が Apache 2.0 で公開されている。ただしオープンウェイト全般が Apache 2.0 なわけではないので、使うモデルごとに確認する必要がある。音声側では Qwen3-TTS が Apache 2.0 で、0.6B と 1.7B の2サイズ、日本語を含む10言語に対応している。

確認を先にやるべき理由は単純で、後から気づくと作り直しになるからだ。モデルを選び、動かし方を組み、大量に生成した後でライセンスの制約に気づけば、そのすべてが無駄になる。逆に最初に確認していれば、選択肢が1つ減るだけで済む。確認のコストは常に前倒しのほうが安い。

確認するときは、モデルカードの要約文ではなくリポジトリのライセンスファイル本体を開く。この手順の重要性は挿絵をローカル画像生成でまかなう（2026-08-27 公開）で詳しく扱った。

長時間ジョブの設計を先に決める

最後に、運用の話をひとつ。手元で回す処理は長時間ジョブになりやすい。

音声化の例で言うと、7,708字の記事が56チャンクに分割された。分割はチャンク単位の再開に対応しておらず、途中で失敗すると進捗が全損する。この制約を知らずに走らせると、数時間を失う。

対処は運用側で吸収できる。1本ずつ実行し、失敗時の巻き戻り範囲を限定する。他のプロセスとGPUを取り合わないよう、同時実行を避ける。実行を切り離し、接続が切れても続くようにする。

この種の設計は音声に限らない。画像の量産でも、大量のファイル変換でも同じだ。長い処理は、失敗を前提に組む。実例は手が塞がっている時間に読ませる（2026-08-28 公開）に記録した。

3Dプリントの現場での配分

モノを作る側の具体的な配分を示す。

設計データを扱う相談は手元。取引先から預かった図面なら要件になる。アイデア出しや技術調査はクラウド上位でよい。機密性が低く、質が成果に直結する。

商品写真の背景や説明図は手元の画像生成。枚数が要り、当たり外れが大きい。販売ページの主要ビジュアルは、1枚の質が売上に効くのでクラウドを使う判断もありうる。

印刷の失敗検知は手元一択。カメラ画像を常時外部へ送るのは通信量の面で現実的でない。作業中の技術文書の音声化も手元が向く。長いので従量課金と相性が悪い。

こうして並べると、手元とクラウドが競合していないことが分かる。それぞれが得意な領域を持っていて、重なりは思ったより小さい。

もう一段具体的に、1つの制作工程で両方を使う例を書いておく。ある部品を設計して売るまでの流れなら、こうなる。仕様の検討と技術調査はクラウド上位。形状のパラメータを振って試す段階は手元。寸法を含む図面が絡んだ時点で手元に固定する。商品説明文の下書きはクラウド下位で足り、写真の背景生成は手元。販売ページの主要ビジュアルだけクラウドに戻す。

この流れを見ると、切り替えが工程の途中で何度も発生することが分かる。だからこそ、接続先を差し替えられる形で組んでおくことが効いてくる。切り替えのたびに設定を書き換える構成だと、面倒が先に立って結局どちらか一方に寄る。

作ったものを売る側の実務については、値付けや制度対応を含めて3Dプリントで何を売るかを先に決める（2026-08-17 公開）で整理している。AIの配分と商売の設計は、別々に決めるより一緒に見たほうが辻褄が合う。

まとめ — 3層で考え、順序で決める

本記事の要点を整理する。

• 選択肢は二択ではなく「クラウド上位／クラウド下位／手元」の3層。下位まで降りると出力単価が20分の1以上になる
• 振り分けの軸は「失敗しても安いか」と「データを外に出せるか」の2つ
• 判断の順序は、データ制約 → 下位ティアで足りるか → 量が多いか → 品質検証
• 損益分岐は初期投資 ÷ 月あたり削減額。上位常用なら約13ヶ月、最安ティア相手なら回収不能
• 必要容量はパラメータ数 × ビット数 ÷ 8 で計算できる
• 実行環境はすべて OpenAI互換なので、切り替え点を最初に作っておく
• ライセンスは最後ではなく最初に確認する。モデル利用と生成物利用は別条項のことがある
• 長時間ジョブは失敗を前提に設計する

AI環境構築で失敗するのは、手元に全部を移そうとしたときだ。移すべき仕事だけを移す。そのために必要なのは高価な機材ではなく、用途を分類する目のほうだった。分類さえできていれば、既存の機材で始められる仕事が必ずいくつか見つかる。

最後に、この配分が固定ではないことも書いておきたい。クラウドの単価は下がり続けているし、手元で動くモデルの品質も上がっている。今日の最適解は半年後の最適解ではない。だからこそ、切り替え点を作っておくことに価値がある。配分を変えるのが安ければ、状況が動いたときに追随できる。

覚えておくべきは、個別のモデル名でも製品名でもない。用途を2つの軸で分類し、順序に従って判断し、切り替えられる形で組む。この手順だけが、技術の入れ替わりを超えて残る。

出典・参考

• Anthropic「Pricing」（Claude APIの公式単価表）
• OpenAI「API Pricing」（GPT-5.6の公式単価表）
• Google「Gemini API Pricing」（Gemini各モデルの公式単価表）
• llama.cpp「quantize README」（量子化形式ごとのビット数とファイルサイズ）
• 全国家庭電気製品公正取引協議会「よくある質問」（電気料金の目安単価 31円/kWh）

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.