Ollama

この記事の日付について。 2026-09-26に調査・執筆し、公開日の2026-10-04に、Ollama公式ライブラリのタグ別サイズ(gemma4・qwen3.6・qwen3・qwen3.8・qwen3-next)、Ollama公式FAQの ollama ps の説明、筆者環境の ollama list / ollama show の表示を再確認して更新しました。本文中の「2026-09-26確認」は執筆時、「2026-10-04確認」は公開前の再確認の日付です。筆者環境の計測値は、断りがない限り2026-09-26の記録です。 この記事でわかること 手元のメモリが8GB・16GB・24GB・32GB以上のとき、Ollamaでそのまま使える日本語向けの候補がどれか 候補をモデル名の「B数」ではなく、Ollamaで落ちてくる実ファイルのサイズで選ぶ理由 DGX Spark(統合メモリ128GB)で実際に使い続けているモデルと、品質不足でやめた構成の記録 Gemma 4・Qwen3.6・Qwen3のライセンスと、商用利用の根拠URL 今日中に動かし始めるための最短のコマンドと、コンテキスト長の落とし穴 結論から書きます。32GB以上のメモリがあるなら、筆者が日常運用している qwen3.6:35b-a3b(23〜24GB)が最初に試す候補です。24GBなら gemma4:26b(16〜19GB)か qwen3.6:27b(18〜19GB)、16GBでは gemma4:12b(7.7〜8.0GB)か qwen3:14b(9.3GB)、8GBでは qwen3:8b(5.2GB)か qwen3:4b(2.5GB)が現実的な線です。サイズはいずれもOllama公式ライブラリの表示値です(2026-10-04確認)。 ただし、ファイルサイズがメモリより小さいことは動作の保証になりません。実行時にはKVキャッシュや作業用のバッファも必要で、短いコンテキストから試して ollama ps で配置を確かめる前提の候補です。筆者が実機で品質まで確かめたのは32GB以上の帯だけで、8〜24GB帯の候補は公式サイズから選んだ段階です。どこまでが実測で、どこからが公式値からの逆算かは、表ごとに明記します。 1. 選び方の基準──「何B」ではなく「何GB」で決める ローカルLLMの紹介記事は、モデルを「7B」「27B」のようなパラメータ数で並べがちです。しかし、手元のPCに載るかどうかの大部分を決めるのは、量子化したあとのファイルサイズと、会話中に増えるKVキャッシュの合計です。これに実行時のバッファや、画像入力を使う場合の処理分が加わります。同じ「26B」でも、16ビットなら57.7GB、4ビット(Q4_0)なら14.4GBと4倍の開きがあります(Google AI for Developers『Gemma 4 model overview』最終更新2026-07-08)。 この記事では、次の4点で候補を絞りました。 メモリに載るか: Ollama公式ライブラリに表示されるタグ別サイズが、手元のメモリより十分小さいこと 日本語が使えるか: 開発元のモデルカードが多言語対応を明記していること。実測できたものは実測結果を優先 Ollamaで1コマンドで取れるか: 公式ライブラリにタグがあり、ollama pull だけで始められること 商用で使えるか: ライセンスが開発元の一次資料で確認でき、商用利用を妨げる独自条項がないこと 「量子化」は、モデルの重みを16ビットから8ビットや4ビットに丸めて小さくする処理です。Ollamaの標準タグは多くが4ビット前後に量子化済みで、q8_0 や bf16 の付いたタグはより大きく、元の精度に近い版です。たとえば qwen3.6:27b は標準で18〜19GB、q8_0 で30GB、bf16 で56GBです(Ollama library qwen3.6 tags 2026-10-04確認)。 2. 一次資料の対応表 この記事の数字は、次の一次資料と筆者の作業記録から取っています。 主張 一次資料 種別 確認日 gemma4の各タグのサイズ(e2b 4.6〜7.5GB、e4b 6.6〜9.5GB、12b 7.7〜8.0GB、26b 16〜19GB、31b 19〜20GB)とコンテキスト長 Ollama library gemma4 tags 公式ライブラリ 2026-10-04 qwen3.6の各タグのサイズ(27b 18〜19GB、35b-a3b 23〜24GB、q8_0/bf16版を含む) Ollama library qwen3.6 tags 公式ライブラリ 2026-10-04 qwen3の各タグのサイズ(4b 2.5GB、8b 5.2GB、14b 9.3GB) Ollama library qwen3 公式ライブラリ 2026-10-04 Gemma 4の5サイズと、BF16・SFP8・Q4_0別の重みのメモリ量 Google AI for Developers『Gemma 4 model overview』 公式ドキュメント 2026-09-26 Gemma 4はApache 2.0、事前学習140超・そのまま使える35超の言語 Hugging Face google/gemma-4-26B-A4B-it、Google Open Source Blog 2026-04-02 モデルカード・公式ブログ 2026-09-26 Qwen3.6-35B-A3B・Qwen3.6-27BはApache 2.0 Hugging Face Qwen/Qwen3.6-35B-A3B、Qwen/Qwen3.6-27B モデルカード 2026-09-26 Qwen3-8BはApache 2.0、100超の言語と方言に対応 Hugging Face Qwen/Qwen3-8B モデルカード 2026-09-26 Ollamaの既定コンテキスト長はVRAM量で4k/32k/256kに変わる Ollama docs: Context length 公式ドキュメント 2026-09-26 llama.cppはMITライセンス、1.5〜8ビットの整数量子化に対応 GitHub ggml-org/llama.cpp GitHub 2026-09-26 DGX Sparkでの速度・品質の実測、登録モデルとサイズ、ローカルLLMでの記事生成をやめた経緯 筆者の作業記録(2026-04-03、2026-07-14、2026-08-04、2026-09-08) 実測・運用記録 2026-09-26 Ollamaのqwen3.6のページには、ライセンスの記載がありませんでした(2026-09-26確認)。ライセンスはHugging Faceのモデルカードで確認しています。 ...

この記事の日付について。 2026-09-27に調査・執筆し、公開日の2026-10-04に、Ollama公式FAQ(プライバシー・ollama ps・クラウド無効化の記述)、Ollamaのクラウドモデル一覧とドキュメント、Ollama library qwen3.6 tags、Qwen3-8Bの設定ファイルとモデルカード(コンテキスト長)、筆者環境の ollama list / ollama show の表示を一次資料で再確認して更新しました。本文中の「2026-09-27確認」は執筆時、「2026-10-04確認」は公開前の再確認の日付です。筆者環境の計測値は、断りがない限り2026-09-27の記録です。2026-10-11に第7節・第10節・第11節とよくある質問6項目を追記しました(「2026-10-11確認」はその日の確認です)。 この記事でわかること ローカルLLMの定義と、ChatGPTのようなクラウドLLMとの違い Ollama・LM Studioを使うとき、入力が手元に留まる範囲と、通信が発生する操作 重み・量子化・実行ソフトの3つで、手元の推論が成り立つ仕組み 自分のPCで動くかを、パラメータ数とビット数から見積もる計算方法 ローカルLLMが向く作業と、向かない作業 ローカルLLMとは、大規模言語モデル(LLM)の推論を自分のPCや自社サーバーの上で実行する使い方です。モデルの重みファイルを手元に置き、実行ソフトがそれを読み込んで文章を生成します。 ChatGPTとの違いは「どこで計算するか」です。クラウドLLMは入力を提供元のサーバーへ送って処理します。ローカルLLMは、モデルを取得したあとなら通信なしで応答できます。LM Studioの公式ドキュメントは、ダウンロード済みモデルとのチャットで入力した内容は端末の外に出ないと明記しています(LM Studio Docs『Offline Operation』2026-09-27確認)。動かせるかどうかは、主にメモリ量で決まります。小型の量子化モデルなら一般的なPCも候補になります。ただし必要量は重みだけでなくKVキャッシュや実行バッファでも変わるため、空きメモリと実際のロード状態を確認します。 1. ローカルLLMとは──「ローカル」は推論の実行場所を指す LLMを使う処理は、大きく「学習」と「推論」に分かれます。学習は大量の計算資源で重みを作る工程です。推論は、できあがった重みに文章を入力して続きを出させる工程です。 ローカルLLMの「ローカル」は、このうち推論をどこで実行するかを指します。学習まで手元で行う必要はありません。Qwen・Gemma・Llamaのように、開発元が重みを公開しているモデル(オープンウェイトモデル)をダウンロードして使うのが一般的です。 そのため「ローカルLLM」という名前のモデルがあるわけではありません。同じQwen3-8Bでも、自分のPCで動かせばローカル、クラウドのAPI経由で使えばクラウドです。 2. 一次資料の対応表 この記事の事実関係は、次の一次資料と筆者の運用記録から取っています。 主張 一次資料 種別 確認日 ローカル実行時、Ollamaはプロンプトやデータを見ない。既定の待ち受けは localhost の11434番ポート Ollama FAQ 公式ドキュメント 2026-09-27(プライバシーの記述は2026-10-04再確認) Ollamaはモデルをインターネットから取得する。モデルの保存場所、既定で5分間メモリに保持 Ollama FAQ 公式ドキュメント 2026-09-27 Ollamaのクラウド機能は OLLAMA_NO_CLOUD=1 で無効化できる Ollama FAQ 公式ドキュメント 2026-10-04 Ollamaのクラウドモデルには公開重みのモデルも並ぶ Ollama cloud models、Ollama docs: Cloud 公式ライブラリ・ドキュメント 2026-10-04 Ollamaの既定コンテキスト長はVRAM量で4k/32k/256kに変わる。ollama ps の列の意味 Ollama docs: Context length 公式ドキュメント 2026-09-27 LM Studioはモデル取得後はオフラインで動き、入力と文書は端末外に出ない。通信が要る5つの操作 LM Studio Docs『Offline Operation』 公式ドキュメント 2026-09-27 llama.cppは1.5〜8ビットの整数量子化、CPUとGPUの併用推論に対応。MITライセンス GitHub ggml-org/llama.cpp GitHub 2026-09-27 Qwen3-8Bは8.2Bパラメータ、36層、KVヘッド8、Apache 2.0。コンテキスト長は標準32,768トークン、YaRN併用で131,072トークン Hugging Face Qwen/Qwen3-8B、config.json モデルカード・設定ファイル 2026-09-27(コンテキスト長は2026-10-04確認) qwen3:8b の標準タグはq4_K_Mで5.2GB、q8_0は8.9GB、fp16は16GB Ollama library qwen3 tags 公式ライブラリ 2026-09-27 DGX Sparkでのモデル重みのサイズ・メモリ配分・生成速度 筆者の作業記録(2026-03-15、2026-08-04) 運用記録 2026-09-27 CPUのみの動作、Apple M系の対応、生成速度とメモリ帯域の関係 Ollama docs: macOS、llama.cpp Discussion #4167、Apple Newsroom 公式ドキュメント・GitHub・公式発表 2026-10-11 Qwen・Llama 3.3・Gemmaの商用利用条件、Ollamaのコーディング連携 各モデルのLICENSE、Gemma Terms of Use、Ollama docs: Integrations ライセンス文書・公式ドキュメント 2026-10-11 企画段階では、DGX Spark上でネットワークを遮断した状態の動作と、ollama ps・生成速度を新たに測る予定でした。この記事の公開時点では、その測定はまだ行えていません。そのため後半の数字は、過去の作業記録にある値と、一次資料からの計算値に限っています。 ...

2026年2月、AIによるセキュリティ監査の歴史を塗り替える出来事がありました。AnthropicのAIモデル（Claude）が、世界で最も厳格にテストされているオープンソースプロジェクトの一つである「Firefox」から、わずか2週間で22件の未知の脆弱性を発見したのです。 本記事では、この衝撃的な事例の背後にある技術的な仕組みと限界、そして皆さんの開発現場にLLMによるコードレビューをどう組み込むべきかを解説します。 1. 22件の脆弱性発見が意味する「AIの目」の進化 112件の報告から22件のCVE、14件が高深刻度 AnthropicのチームはMozillaに合計112件のレポートを提出し、そのうち22件がMozillaによって「セキュリティ上重要なバグ」として正式にCVEに登録されました。残る90件はセキュリティとは無関係な一般的なバグで、そのほとんどもすでに修正済みです。22件のCVEのうち、14件はMozillaのエンジニアによって「高嚴重度（High Severity）」と分類され、Firefox 148.0で修正されました。 JavaScriptエンジンに潜む「Use After Free」の発見 最も注目すべきは、ClaudeがFirefoxの心臓部であるJavaScriptエンジン（SpiderMonkey）に焦点を当てた点です。わずか20分の分析で、AIは「Use After Free（UAF）」というメモリ脆弱性を発見しました。 Use After Free（UAF）とは： メモリ領域を解放（Free）した後も、そのアドレスを指すポインタを使用（Use）し続けてしまうバグ。攻撃者がこの解放済みメモリに悪意のあるデータを書き込むことで、任意のコード実行やクラッシュを引き起こす可能性のある、極めて危険な脆弱性です。 何百万行にも及ぶ複雑なC++コードの中から、人間の目視では追いきれない動的なメモリ管理の破綻をAIが「パターン」として見抜き、指摘したのです。 2. LLMによるコードレビューはどのように行われたか？ 過去のCVEデータによる「脆弱性の文脈理解」 Anthropicは、モデルに過去のCVE（共通脆弱性識別子）データやセキュリティレポートを深く学習させています。これにより、モデルは単なる「文法エラー」ではなく、「構造的にリスクを生みやすいコードパターン」を理解しています。 並列処理による力技：大規模コードベースのスキャン 数百万行のコードを人間がすべて読むのは不可能ですが、LLMは並列処理によりこれを解決します。Firefoxの膨大なC++コードをモジュール単位に分割し、複数のClaude Opus 4.6インスタンスで同時並行でスキャンを行いました。 全体の処理時間は、単純化すると以下のような数式で表される並列化の恩恵を受けます。 $$ \text{処理時間} \approx \left( \frac{\text{総ファイル数}}{\text{並列インスタンス数}} \right) \times \text{1ファイルあたりの平均処理時間} $$このアプローチにより、人間なら数ヶ月かかるコード監査が、わずか2週間で完了しました。 3. AIの限界：バグは見つけても「攻撃」はできない しかし、AIは万能ではありません。この実験で明らかになった最大の限界は、「脆弱性の発見」と「攻撃の実証」の間の巨大な壁です。 成功率わずか9%：PoC（概念実証）生成の難しさ Claudeが発見した22件の脆弱性について、実際に悪用可能であることを証明する「PoC（Proof of Concept）コード」をAI自身に書かせようと試みました。 約4,000ドル分のAPIコストを費やして大量のプロンプトを試行したものの、実際に機能するPoCを生成できたのはたったの2件（成功率約9%）でした。 しかも、成功した2件のPoCは「モダンブラウザのセキュリティ機能（サンドボックス等）を意図的に無効化したテスト環境」でのみ動作するものであり、実際の攻撃環境で機能する「フルチェーンのエクスプロイト」の構築には至っていません。 Use After Freeのようなバグを実際に突くには、OSのメモリレイアウトやガベージコレクションの絶妙なタイミングなど、静的なコード解析だけでは分からない「動的な実行環境の深い理解」が必要です。 AIは「ここがおかしい」というフラグを立てる（発見者）には極めて優秀ですが、それを「どう悪用するか（エクスプロイト）」の構築には、依然として人間のホワイトハッカーの高度な専門知識が不可欠なのです。 4. 現場でLLMコードレビューを導入するための戦略 このAnthropicとMozillaの事例を踏まえ、一般の企業や開発チームがLLMをコードレビューに導入するための実践的なアプローチを紹介します。 戦略①：人間とAIのハイブリッド体制（トリアージ） AIの報告には必ず「偽陽性（False Positive：誤報）」が含まれます。AIを「最初のフィルタリング役（一次審査）」とし、そのレポートを人間のシニアエンジニアが確認（トリアージ）してバグチケットを切る、というパイプラインが現在最も実用的です。 戦略②：クラウドAPI vs ローカルLLM AnthropicのClaude Opus 4.6などのクラウドAPIは最高精度を誇りますが（今回の実験もOpus 4.6を使用）、機密性の高い自社のソースコードを外部に送信できない企業も多いでしょう。 プライバシー重視のローカルLLM構築 外部APIが使えない場合は、Ollama や vLLM などの推論エンジンを用いて、社内のGPUサーバー上でオープンソースモデル（Llama 3やQwenなど）を動かす選択肢が現実的です。 ...