（最終更新日: 2025年12月23日）
ollama run は触ったけれど、Modelfile や ollama create の狙いが腑に落ちず、結局サンプルを貼って動かすだけになっていませんか。
本記事は、create と pull／run の違いをまず整理し、最低限覚える書き方と考え方を平易に示し、業務ですぐ使える雛形と判断軸を手渡します。
さらに、モデル名やタグの付け方、自動化の仕組みへの組み込み、よくあるエラーの直し方、ローカルとクラウドの使い分けまでを一気に俯瞰します。
2025年の仕様に合わせ、現場での検証とベストプラクティスを踏まえて解説するので、今日から自信を持って運用に組み込めます。
ollama create と pull / run の違いを最初に整理する
当セクションでは、ollama create と pull / run の役割の違いと使い分けを最初に明確化します。
この整理を最初に行う理由は、三つのコマンドの意図を混同すると、無駄なダウンロードや設定の重複、運用上の混乱が起きやすいからです。
- ollama create は何ができるコマンドか？
- ollama pull / run との関係をDockerになぞらえて理解する
- GPUがなくても ollama create は使えるか？
ollama create は何ができるコマンドか？
結論として、ollama create は「Modelfileからモデルをビルドし、ローカルレジストリに名前付きモデルとして登録する」ためのコマンドです。
ベースモデルにシステムプロンプトやPARAMETER、TEMPLATE、ADAPTER（LoRAなど）を束ねて一つの再利用可能なモデルイメージにします。
なお「createしないと使えないのか」という疑問に対しては、公式ライブラリのモデルは pull → run だけでそのまま使えると覚えておくと安心です。
# 公式モデルの取得と一時実行
ollama pull llama3
ollama run llama3一方で組織で使い回す設定を固定化したい場合は、Modelfileを作って create しておくと配布や再現性が楽になります。
# 例：社内共通のシステムプロンプトやパラメータを固めてビルド
ollama create acme/helpbot:v1 -f ./Modelfile詳細仕様は公式ドキュメントのCLI参照とModelfileリファレンスを確認すると確実です（参考: CLI Reference – Ollama、Modelfile Reference – Ollama）。
併せて操作の全体像は、当メディアの解説も役立ちます（参考: 【2025年版】Ollamaコマンド完全ガイド）。
ollama pull / run との関係をDockerになぞらえて理解する
要点は、Dockerの pull / run / build にそれぞれ ollama の pull / run / create が対応すると理解すると直感的です。
両者は「レジストリから取得（pull）→一時実行（run）→定義からビルド（create/build）」というワークフロー設計を共有します。
対応関係は次の通りです。
- Docker pull ⇔ Ollama pull（モデル/イメージの取得）
- Docker run ⇔ Ollama run（イメージからコンテナ/モデルを実行）
- Docker build ⇔ Ollama create（Dockerfile/Modelfileから新しいイメージを構築）
図で俯瞰すると定着が早まります。
この比喩を押さえると、「まずpullでベースを落として、使うだけならrun、組織の標準設定を固めたいならcreate」という判断が素早くできます（参考: CLI Reference – Ollama）。
さらにAPI連携やツール統合の観点は、実装記事が参考になります（参考: 【2025年版】Ollama API徹底ガイド）。
GPUがなくても ollama create は使えるか？
結論は「はい、GPUがなくても create は使えます」であり、ビルド自体はCPUのみでも可能です。
ただし推論速度はハードウェアに強く依存するため、7BクラスでもCPUオンリーでは応答が遅くなる点を前提に計画するべきです。
個人や小規模チームなら、7BをQ4量子化で使う前提でRAM 16GB以上と近年のマルチコアCPUを目安にし、長文処理は待ち時間が伸びると想定するのが現実的です。
Safetensorsからの取り込み時に-qでQ4_K_Mなどの量子化を指定してビルドすると、サイズとメモリ消費を抑えつつ配布が容易になります。
# 例：Safetensorsから取り込みつつ4bit量子化してビルド
ollama create my-7b-q4 -f ./Modelfile -q q4_K_M量子化・インポートの正確なオプションは公式のImport/Modelfileドキュメントを確認し、CPU運用の勘所は詳説記事も参照してください（参考: Importing a Model – Ollama、Modelfile Reference – Ollama、OllamaはCPUだけでどこまで使える？）。
Modelfileの基本構造と最低限おさえるべき命令
当セクションでは、Modelfileの基本構造と最低限おさえるべき命令を、実務の観点から順を追って説明します。
理由は、Modelfileの書き方がそのままモデルの品質・安定性・再現性に直結し、誤設定の多くがテンプレートやパラメータの理解不足に起因するからです。
- Modelfile はどう書けばよい？全体像をざっくり把握する
- FROM命令：ベースモデルとインポート元の選び方
- SYSTEM命令：社内専用アシスタントの“人格”を定義する
- PARAMETER命令：精度・創造性・リソース消費を制御する
- TEMPLATE命令：チャット形式とモデル学習形式の“橋渡し”
- ADAPTER・LICENSE：エンタープライズで効いてくる拡張命令
Modelfile はどう書けばよい？全体像をざっくり把握する
結論は、ModelfileはDockerfileと同様に上から順に命令を書き、最低限必要なのはFROMだけです。
Ollamaは命令ごとにレイヤーを作りマニフェストにコミットするため、記述順と依存関係がそのまま挙動に反映されます（参考: Modelfile Reference – Ollama）。
よく使うのは FROM / SYSTEM / PARAMETER / TEMPLATE / ADAPTER / LICENSE の6種で、このセットを把握すればほとんどの業務要件をカバーできます。
全体像は次の模式図のとおりで、上から下へ流れるパイプラインを意識すると理解が早いです。
最小構成と、実務で使う基本構造のミニ例は次のとおりです。
# 最小例（必須はFROMのみ）
FROM llama3:latest
# 実務の基本構造ミニ例
FROM llama3:latest
SYSTEM """
あなたは社内ヘルプデスクのアシスタントです。
不明点は不明と明言し、根拠資料を提示します。
"""
PARAMETER temperature 0.2
PARAMETER num_ctx 8192
PARAMETER stop "<|eot_id|>"
正式な構文・既定値は公式リファレンスを参照すると安全です（参考: Modelfile Reference – Ollama）。
FROM命令：ベースモデルとインポート元の選び方
結論として、FROMは唯一の必須命令であり、ここで何を指定するかが後続の互換性・品質・サイズをほぼ決めます。
継承元によってトークナイザーやテンプレート、量子化の前提が変わるため、ミスマッチは性能劣化やエラーの原因になります（参考: Importing a Model – Ollama）。
公式モデル継承の例です。
FROM llama3:latest
ローカルGGUFからのインポート例です。
FROM ./models/mistral-7b-instruct-v0.3.Q4_K_M.gguf
Safetensorsディレクトリからのインポート例です。
FROM ./finetuned-model/
まずは公式ライブラリの llama3 / mistral / gemma で慣れ、社内でフル/LoRA微調整が整ったらSafetensors取り込みと量子化を検討すると滑らかです（参考: Modelfile Reference – Ollama、Importing a Model – Ollama）。
ベースモデルの選び方や代表モデルは、こちらも参考になります：【2025年版】Ollamaのモデル完全ガイド。
SYSTEM命令：社内専用アシスタントの“人格”を定義する
要点は、SYSTEMで役割・制約・出力形式を具体化すると、回答の安定性と再現性が劇的に向上することです。
同じベースモデルでもSYSTEMの粒度しだいでハルシネーション率やフォーマット遵守率が大きく変わります。
実務では「ペルソナ→ルール→出力形式」の順で短く明確に書くのが定石です（参考: Modelfile Reference – Ollama）。
例として、筆者が運用している「資格試験システムのFAQボット」の抜粋です。
SYSTEM """
あなたは国家資格試験の受験案内専任アシスタントです。
必ず根拠URL（公式サイト）を提示し、不明な点は「確認が必要」と明記します。
出力形式：
- 回答（2〜3文）
- 根拠リンク（箇条書き）
"""
プロンプト設計の基本を押さえたい方は、プロンプトエンジニアリング入門や、ハルシネーション低減の観点でAIハルシネーション対策の全手法も併読すると理解が深まります。
PARAMETER命令：精度・創造性・リソース消費を制御する
結論として、PARAMETERは精度と創造性、速度とメモリのトレードオフをコントロールするダイヤルです。
temperatureやtop_p/top_kは語の分布を、num_ctxやnum_predictはVRAM消費と応答速度を左右します。
コード生成や業務QAは低温度（0.1〜0.3）かつ広めのコンテキスト（8192以上）にすると安定します。
企画・コピーなどのクリエイティブ用途は温度高め（0.7〜1.0）と適度なtop_p（0.8〜0.95）が伸びやすいです。
用途別おすすめの早見表を次の図にまとめました。
パラメータの正式な意味や既定値は公式仕様で確認してください（参考: Modelfile Reference – Ollama）。
TEMPLATE命令：チャット形式とモデル学習形式の“橋渡し”
結論は、TEMPLATEがモデルの学習フォーマットと一致していないと、指示無視・暴走・文字化け的出力などの性能劣化が発生することです。
近年のInstructionモデルは固有のチャットテンプレートで学習されており、不一致は会話終端や役割タグの解釈ズレを引き起こします。
Llama 3のテンプレート例は次のとおりです。
TEMPLATE """{{ if .System }}<|start_header_id|>system<|end_header_id|>
{{ .System }}<|eot_id|>{{ end }}{{ if .Prompt }}<|start_header_id|>user<|end_header_id|>
{{ .Prompt }}<|eot_id|>{{ end }}<|start_header_id|>assistant<|end_header_id|>
{{ .Response }}<|eot_id|>"""
公式モデルは自動検出されるため、基本的にはテンプレートをいじらない方が安定です（参考: Modelfile Reference – Ollama）。
一方、外部GGUFや独自フォーマット導入時は、Hugging Faceのモデルカード等でテンプレートを確認し、完全一致で記述してください。
筆者の失敗談として、Llama 3で停止トークンと区切りタグを混在させたところ、会話が閉じず延々と出力が続いたことがあり、テンプレートの微妙なズレが原因でした（参考: Ollama English Docs – Modelfile）。
ADAPTER・LICENSE：エンタープライズで効いてくる拡張命令
結論として、ADAPTERはLoRA等の特化知識を重ね、LICENSEは法的前提を明記するため、監査・コンプライアンスで強力に効きます。
アダプタはベースモデルと同一アーキテクチャ・バージョンで作られている必要があり、互換性が崩れると適用できません（参考: Modelfile Reference – Ollama）。
ADAPTERの指定例です。
ADAPTER ./adapters/medical-lora.safetensors
LICENSEに条文やURLを明記しておくと、法務レビューや監査時の確認が迅速化し、運用の透明性が高まります。
特に医療・金融等では審査負荷を下げやすく、OSSライセンスの可否を社内Wikiの表とセットで管理する運用が実務的です。
詳細は公式仕様を参照してください（参考: Modelfile Reference – Ollama）。
実務でそのまま使える Modelfile テンプレ集
当セクションでは、あらゆる現場でそのまま流用できる Modelfile テンプレートを目的別に提示し、設定意図まで解説します。
なぜなら、現場では“最初の一枚”がないと設計の勘所を外しがちで、温度やコンテキスト長などの初期値の差が品質に直結するからです。
- 既存モデルをベースにした汎用チャットボットの作り方
- 社内RAGバックエンド向けモデル：コンテキスト重視の設計
- コードレビューBot：決定論的かつ厳しめに動かす設定例
- 社外クラウドLLMと連携するゲートウェイ的モデル設計
既存モデルをベースにした汎用チャットボットの作り方
既存モデルから派生させるなら、llama3:latest をベースに SYSTEM と PARAMETER を固定するのが最短です。
理由は、学習済みのチャット挙動を活かしつつ、社内ルールや出力形式だけを上書きする方が安全で速いからです。
以下は日本語汎用アシスタントの実用テンプレで、SYSTEMで日本語回答と安全ガイドラインを固定し、PARAMETERで温度とコンテキストを整えるのが最短経路です。
FROM llama3:latest
PARAMETER temperature 0.3
PARAMETER top_p 0.9
PARAMETER top_k 40
PARAMETER num_ctx 8192
PARAMETER num_predict -1
PARAMETER seed 42
PARAMETER stop "<|eot_id|>"
SYSTEM """
あなたは日本語で回答する汎用業務アシスタントです。
不明な場合は「不明です」と述べ、仮定で断定しない。
社外秘や個人情報は出力に含めない。
回答は「要点→根拠→次のアクション」の順で簡潔に。
必要なら箇条書きを使う。
"""ビルド後は API/CLI から同名モデルを呼べますので、手順はOllama API徹底ガイドも併せて確認してください。
命令語やパラメータの仕様は公式ドキュメントを参照してください（参考: Modelfile Reference）。
社内RAGバックエンド向けモデル：コンテキスト重視の設計
RAG用途では、モデルは長い文脈を安全に活かし、出典を明示する設計が必要です。
理由は、検索や再ランキングはフレームワークが担う一方で、モデル側が引用ルールや長文耐性を欠くと、ハルシネーションや過剰な要約が起きるからです。
次のように、モデル側とフレームワーク側の責務を分けて考えると設計が安定します。
- モデル側（Ollama/Modelfile）: PARAMETER num_ctx 16384〜を確保し、SYSTEMで「必ず根拠の出典リンクやドキュメントIDを明記」などのルールを固定。
- フレームワーク側（LangChain/LlamaIndex）: ベクタDB検索、再ランキング、チャンク設計、引用元マッピング、メタデータの注入を担保。
アーキテクチャの全体像は次の図のとおりです。
num_ctx の上げ幅や stop 設定はハードウェアとテンプレート依存のため、本番前に負荷試験と品質試験を分けて行うことを推奨します（参考: Modelfile Reference）。
RAGの実装全体はRAG（Retrieval-Augmented Generation）構築のベストプラクティスで手順を詳しく解説しています。
ハルシネーション対策の観点も合わせて評価観点を用意してください（参考: AIハルシネーション対策の全手法）。
コードレビューBot：決定論的かつ厳しめに動かす設定例
コードレビューBotは、低温度・適切な停止トークン・長めのコンテキストを前提に、決定論的に動くよう設計します。
なぜなら、指摘の一貫性と再現性が価値であり、創作性はむしろノイズになるからです。
例えば次のテンプレートは codellama をベースに、厳しめのトーンと出力構造を固定します。
FROM codellama:7b-instruct
PARAMETER temperature 0.1
PARAMETER top_p 0.95
PARAMETER num_ctx 8192
PARAMETER stop "<|user|>"
PARAMETER stop "<|end|>"
SYSTEM """
あなたは社内のシニアコードレビュアーです。
規約違反の指摘は厳密に、修正案は最小差分のコードで提示してください。
出力は「概要／違反箇所と根拠／修正案／改善提案」の順に記載してください。
"""社内で実装した際、最初は temperature 0.7 のままで“優しいアドバイス”ばかりになり、違反の見落としが続出しました。
そこで温度を0.1に下げ、stopを追加し、チェックリストをSYSTEMに明記すると、指摘の粒度と網羅性が大幅に安定しました。
コードレビュー運用のTipsはCodeRabbit とは？などの専用ツール解説も参考になります（参考: Modelfile Reference）。
社外クラウドLLMと連携するゲートウェイ的モデル設計
高難度だけをクラウドに渡す“ゲートウェイ設計”は、コストと品質のバランスを最適化します。
理由は、ローカルで要約・前処理・ルーティングを行うと、不要な外部トークン消費が減り、機密テキストの露出も最小化できるからです。
ローカル側は短時間で動く軽量パラメータと判定用SYSTEMを持たせ、出力にROUTEとSUMMARYを返すように決めておきます。
次のテンプレは、要約と難易度判定に特化したゲートウェイモデルの例です。
FROM llama3:latest
PARAMETER temperature 0.2
PARAMETER top_p 0.9
PARAMETER num_ctx 4096
SYSTEM """
あなたは前処理ゲートウェイです。
ユーザ入力を要約し、難易度をA/B/Cで判定し、次の形式で返してください。
ROUTE: local または cloud
SUMMARY: 3行以内の要約
理由: ROUTEの根拠を1行で
"""アーキテクチャは下図のようにルーティングノードで分岐し、クラウド結果とローカル結果をAPI層で統合します。
API連携やOpenAI互換エンドポイントの扱いはOllama API徹底ガイドと公式の互換ドキュメントを確認してください（参考: OpenAI compatibility – Ollama）。
本格運用に向けてプロンプト設計や評価の体系を短期間で身につけたい方は、実務直結のオンライン学習DMM 生成AI CAMPの基礎コースを活用すると習得が加速します。
ollama create コマンドの構文・オプションと実行フロー
当セクションでは、ollama create コマンドの構文、主要オプション、内部の実行フロー、そしてAPI経由での自動化までを体系的に説明します。
なぜなら、createの理解が不十分だと命名の混乱や量子化の非効率、ストレージ逼迫、CI/CDの形骸化といった問題が実運用で必ず顕在化するからです。
- 基本構文：ollama create <MODEL_NAME> -f <Modelfile>
- 量子化オプション -q：自前モデルを配布可能なサイズにする
- コマンド実行時の内部挙動をざっくり理解する
- API経由でのモデル作成：CI/CDに組み込む
基本構文：ollama create <MODEL_NAME> -f <Modelfile>
結論として、ollama create は MODEL_NAME と -f を明示し、namespace/model:tag 命名に統一することが再現性と運用性を最大化します。
この形式は組織内の識別とバージョン管理を容易にし、タグ未指定時に自動付与される latest との衝突や事故を避けやすくなります。
たとえば部門別×環境別にタグを切ると、同じベースでも用途ごとの差分を安全に展開できます。
ollama create acme/finance-bot:dev -f modelfiles/finance.modelfile
ollama create acme/finance-bot:stg -f modelfiles/finance.modelfile
ollama create acme/finance-bot:prod -f modelfiles/finance.modelfile-f はModelfileの所在を明確化し、リポジトリ内で複数定義を運用するときの取り違えを防ぐうえで必須級です。
命名規則のベストプラクティスは次の表を参考にプロジェクト開始時に固定化すると混乱が減ります（詳細なフラグ仕様は公式CLIリファレンスを参照すると確実です（参考: CLI Reference – Ollama））。
| 観点 | 推奨形式 | 例 | 運用メモ |
|---|---|---|---|
| フル識別子 | team/purpose-env:version | mlops/code-reviewer-prod:v1.0 | team=組織や部門、purpose=用途、env=dev|stg|prod |
| 派生管理 | basePurpose-variant | finance-bot-audit | variantに用途差分を短く付記 |
| タグ運用 | semver or yyyymmdd | :v1.2.3 / :2025-07-01 | latestは人間向けテスト専用に限定 |
コマンド全体の復習や関連操作はまとめ記事も併読すると理解が早まります（参考: 【2025年版】Ollamaコマンド完全ガイド）。
量子化オプション -q：自前モデルを配布可能なサイズにする
結論として、-q/–quantize でFP16/FP32モデルを Q4_K_M や Q8_0 に量子化すれば、配布サイズとメモリ使用量を大幅に削減できます。
これによりノートPCや社内端末への展開が容易になり、ネットワーク転送やストレージの負担も抑えられます。
実行はシンプルで、Modelfileを保ったまま量子化レベルを付与してビルドします。
ollama create mymodel-quant -f Modelfile -q q4_K_MQ4_K_M はサイズ対品質のバランスが良く、Q8_0 は劣化を最小化したいサーバー運用向けの選択肢です（参考: Importing a Model – Ollama）。
変換時間は7B規模で数分〜十数分が目安で、CPUのみでも可能ですがGPUやApple Siliconでは短縮が見込めます。
ハードウェア選定に迷う場合はCPU運用の実情とGPUのコスパ比較も確認すると判断が速くなります（参考: OllamaはCPUだけでどこまで使える？）。
| 入力形式 | -q 指定 | 変換後サイズの目安 | 推奨ハードウェア | 用途 |
|---|---|---|---|---|
| FP16 7B | q4_K_M | 約4〜6GB | VRAM 8〜16GB / Apple Mシリーズ16GB | 全社員ノートPC配布 |
| FP16 7B | q8_0 | 約8〜10GB | VRAM 16〜24GB | 劣化極小の社内API |
| FP32 13B | q4_K_M | 約8〜9GB | VRAM 12GB+ / MシリーズPro | 標準業務アシスタント |
コマンド実行時の内部挙動をざっくり理解する
結論として、create 実行時は「Modelfileパース → FROM解決 → レイヤー構築/量子化 → マニフェスト登録」の順に進み、Docker同様のレイヤー共有によってディスク効率が高く保たれます。
理由は、OllamaがマニフェストでメタデータとブロブのSHA256ハッシュを管理し、同一コンテンツを重複保存しない設計だからです。
たとえば FROM llama3 を基点に SYSTEM や PARAMETER の差分だけが新レイヤー化され、同じベースを使う派生モデルが多数あっても巨大ファイルは複製されません。
外部GGUFやSafetensorsを取り込む場合は、そのファイルが新規ブロブとして格納され、-q が指定されていれば量子化が同時に走ります。
処理完了後、マニフェストがコミットされて MODEL_NAME にひも付き、すぐに ollama run やAPIから利用可能になります。
ストレージ構造のイメージは次の図を参考にすると直感的に把握できます。
API経由でのモデル作成：CI/CDに組み込む
結論として、POST /api/create を使えば Modelfile の変更をトリガに自動ビルドとスモークテストを回すCI/CDを簡潔に構築できます。
APIファーストにすることで手作業の環境差分を排し、ステージングから本番への昇格を再現可能な形で管理できます。
最小のリクエストは name と modelfile と stream を指定するだけで動作します（参考: Ollama API docs）。
{
"name": "my-custom-model",
"modelfile": "FROM llama3\nSYSTEM \"You are a helpful assistant.\"",
"stream": false
}GitHub Actions では Modelfile の差分を検知して /api/create を叩き、直後に smoke test を実行するのが定石です。
name: Build Ollama Model on Modelfile change
on:
push:
paths:
- Modelfile
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build on staging
run: |
curl -sS http://stg-ollama:11434/api/create \
-H "Content-Type: application/json" \
-d @- << 'JSON'
{"name":"acme/finance-bot:stg","modelfile":"$(sed 's/\"/\\\"/g' Modelfile)"}
JSON
- name: Smoke test
run: curl -sS http://stg-ollama:11434/api/generate -d '{"model":"acme/finance-bot:stg","prompt":"ping"}'
- name: Promote to prod
if: success()
run: |
curl -sS http://prod-ollama:11434/api/create \
-H "Content-Type: application/json" \
-d @- << 'JSON'
{"name":"acme/finance-bot:prod","modelfile":"$(sed 's/\"/\\\"/g' Modelfile)"}
JSONステージングが緑なら同一のModelfileと名前で本番にも適用し、コミットIDを記録してドリフトを防止します。
API設計や実装の全体像は解説記事も併読すると設計判断が加速します（参考: 【2025年版】Ollama API徹底ガイド）。
モデル名・タグ付け・バージョン管理のベストプラクティス
当セクションでは、Ollamaで作るカスタムモデルのモデル名、タグ付け、バージョン管理の実務ベストプラクティスを解説します。
なぜなら、ollama create でモデルを量産するときに命名やタグの一貫性がないと、運用コストと障害リスクが急増するからです。
- モデル命名規則：誰が見ても役割が分かる名前にする
- Modelfile はアプリコードと同じリポジトリで管理する
- ローカルと本番で異なるPARAMETERをどう管理するか
モデル命名規則：誰が見ても役割が分かる名前にする
結論として、MODEL_NAMEは「namespace/purpose-env:version」の規則で統一し、誰が見ても役割が分かる命名にするのが最適です。
Ollama自体も namespace/model:tag 形式を推奨し、タグ未指定時は latest が付与されるため、再現性と衝突回避に役立ちます（参考: CLI Reference – Ollama）。
私の現場では「saiteki/code-reviewer-prod:v1.2」のように組織名・用途・環境・バージョンを含め、Slackでの会話でも一目で役割と成熟度が伝わるようにしています。
例えば次のようにビルドします。
ollama create saiteki/code-reviewer-prod:v1.2 -f Modelfile個人利用なら「taro/summarizer-local:v0」や「taro/rag-dev:2025-07」のような簡易版でも十分効果があります。
命名とタグ運用の基礎は、あわせて「Ollamaのモデル完全ガイド」も参照すると全体像が掴みやすいです。
Modelfile はアプリコードと同じリポジトリで管理する
結論として、ModelfileはバックエンドAPIのコードと同じリポジトリで管理し、通常のブランチ戦略とPRレビューに乗せます。
理由は、Modelfileがアプリの振る舞いを決める設計資産であり、コードと一体で差分レビュー・テスト・リリースができるからです。
別リポに分けると同期漏れやリリース順序のズレが起きやすく、障害時の原因特定が遅れます。
私が運用する資格試験システム開発では、SYSTEM文の一文変更でもPRを立ててレビュワーが意図を確認し、合意形成を必須としています。
PRにはModelfileのdiff、モデル名のタグ更新、CIからの ollama create 実行ログを添付し、必要ならAPI経由の自動ビルドも使います（手順は「Ollama API徹底ガイド」が参考になります）。
結果として、誰が何を変えたかが履歴に残り、SYSTEM変更もPRレビュー対象という運用文化が品質と説明責任を底上げします。
ローカルと本番で異なるPARAMETERをどう管理するか
結論として、環境変数でSYSTEMやテンプレートを動的挿入するのではなく、環境別のModelfileを用意し共通部分をsharedで管理する方法が安全で再現性に優れます。
理由は、宣言的な差分がGitで明確に追えるため、CI/CDやロールバックが容易で、レビュー品質も維持できるからです。
構成例は次のとおりです。
modelfiles/
shared/
base.modelfile # FROMや共通SYSTEM、共通TEMPLATE
dev/
coding-assistant.modelfile # 開発: temperature=0.8, num_predict=128
stg/
coding-assistant.modelfile # 検証: temperature=0.3, num_predict=256
prod/
coding-assistant.modelfile # 本番: temperature=0.1, num_predict=512ビルドはタグで環境を明示します。
ollama create acme/coding-assistant-dev:v0.9 -f modelfiles/dev/coding-assistant.modelfile
ollama create acme/coding-assistant-stg:v0.9 -f modelfiles/stg/coding-assistant.modelfile
ollama create acme/coding-assistant-prod:v1.0 -f modelfiles/prod/coding-assistant.modelfile以下の図のように「shared→環境別」のレイヤー関係を意識しておくと、温度やnum_predictのチューニングが安全に進みます。
PARAMETERの意味やデフォルトは公式リファレンスで確認し、環境ごとの差分を明示的に管理します（参考: Modelfile Reference – Ollama）。
よくあるエラーとトラブルシューティング
当セクションでは、ollama create 実行時と作成後のチャット運用で起こりがちなエラーの原因と対処法を体系的に解説します。
なぜなら、エラーはModelfileの書式・参照パス・テンプレート不一致・メモリ制約の4領域に集中し、原因を特定できれば短時間で復旧できるからです。
- Modelfile の構文エラー・命令ミス
- FROM で指定したモデル・ファイルが見つからない
- TEMPLATE不整合による“挙動おかしい系”トラブル
- VRAM不足・メモリ不足によるビルド/推論失敗
Modelfile の構文エラー・命令ミス
createが失敗する大半は、命令名のタイポや値の型不一致、クォート漏れといったModelfileの書式ミスです。
Modelfileはパーサが厳格にチェックするため、FORMなどのスペルミス、PARAMETERの数値に文字列を入れる、SYSTEM/TEMPLATEのクォート未閉などが即時にエラー化します。
典型的には、先頭数行に原因の鍵が出るため「どの命令の何行目か」をまず確認します。
例えば次のようなエラー表示は、命令名のスペルミスが原因です。
error: parse Modelfile: unknown instruction "FORM" at line 1
| FORM llama3:latest
| ^^^^
修正のコツは「命令は大文字・引数は値の型を正しく」「複数行文字列は必ず閉じる」を徹底することです。
FROM llama3:latest
PARAMETER temperature 0.2
SYSTEM """
あなたは社内向けヘルプデスクです。
"""
初動チェックは次の順で行うと迅速です（命令スペル→クォート閉じ→PARAMETER型→重複命令の有無→末尾の余計な空白・タブ）。
# Quick checklist (read-only)
- FROM のスペルと最上段配置
- SYSTEM/TEMPLATE の """ が開閉対
- PARAMETER に数値/小数の型崩れなし
- stop 等の複数指定は行ごとに分離
- 行頭/行末の不可視文字を削除
命令の正式な仕様と型の定義は公式のModelfileリファレンスを参照してください（参考: Modelfile Reference – Ollama）。
FROM で指定したモデル・ファイルが見つからない
「見つからない」系は、ベースモデル未取得かローカルパスの相対指定ミスが原因で発生します。
FROMで公式モデルを指定した場合はローカルに無ければ自動取得されますが、GGUFやsafetensorsディレクトリを相対パスで参照する場合、その基準は「Modelfileの置き場所」です。
よくあるのはVS Codeで開いたフォルダと、ターミナルでの実行ディレクトリがズレているケースです。
エラー例は次の通りで、実体ファイルの解決に失敗しています。
error: open ./models/mistral-7b.Q4_K_M.gguf: no such file or directory
対処はModelfileからの相対パスを見直すか、絶対パスを使い、-fでModelfileを明示して実行します。
ollama create my-mistral -f ./modelfiles/Modelfile
# Modelfile 例
# FROM ./models/mistral-7b.Q4_K_M.gguf
Dockerのビルドコンテキスト発想で「参照はModelfile基準」と覚えると迷いませんし、CLIの使い方は以下も参考になります（参考: Importing a Model – Ollama、参考: CLI Reference – Ollama、関連: 【2025年版】Ollamaコマンド完全ガイド）。
TEMPLATE不整合による“挙動おかしい系”トラブル
createは通るのに「指示に従わない・ユーザー役まで勝手に生成・文字化け」の多くは、学習時のチャット形式とTEMPLATEの不一致が原因です。
各モデルは固有のチャットテンプレートで学習されており、Llama系とMistral系では区切りトークンやロールの記述が異なります。
症状と確認ポイントは次の対応表が役に立ちます。
| 症状 | 疑うべきポイント | 確認項目 |
|---|---|---|
| ユーザー役まで勝手に生成する | TEMPLATEのassistant区切りとstop未設定 | assistant開始・終了トークンとPARAMETER stopの有無 |
| 指示に従わない/回答が逸れる | 学習形式とテンプレ不一致 | モデルカード記載のチャットテンプレに一致しているか |
| 文字化け/タグが露出する | 特殊トークンの欠落・改行位置 | 区切りトークンの完全一致と改行の有無 |
| 応答が途切れる/止まらない | assistant終了トークン・stop設定 | TEMPLATE末尾とstopの整合性 |
Llama 3系の例では、以下のようなTEMPLATEを用いると整合が取れます。
TEMPLATE """{{ if .System }}<|start_header_id|>system<|end_header_id|>
{{ .System }}<|eot_id|>{{ end }}{{ if .Prompt }}<|start_header_id|>user<|end_header_id|>
{{ .Prompt }}<|eot_id|>{{ end }}<|start_header_id|>assistant<|end_header_id|>
{{ .Response }}<|eot_id|>"""
モデルカードのテンプレートと照合し、必要ならTEMPLATEとPARAMETER stopを上書きしてください（参考: Modelfile Reference – Ollama）。
テンプレートの流れを図で確認すると原因特定が速くなります。
VRAM不足・メモリ不足によるビルド/推論失敗
OOMで落ちる場合は「量子化を強める・モデルを小さくする・num_ctxを縮める・実行環境を強化する」の順に手を打つのが現実解です。
VRAMは重みとKVキャッシュで消費が増え、特にnum_ctxを上げると二乗近く効いて推論が失敗しやすくなります。
代表的なエラーは次の通りで、GPU/システムRAMいずれでも発生します。
CUDA out of memory / failed to allocate memory for compute buffer
fatal: not enough memory to load model
対処例としては-q q4_K_Mでの量子化ビルドや、Modelfile側でnum_ctxを抑制する設定が有効です。
# 例：量子化して再ビルド
ollama create my-model -f Modelfile -q q4_K_M
# 例：コンテキストを抑える
PARAMETER num_ctx 4096
どうしても足りない場合は小規模モデルへの切替やCPU運用の検討、あるいは一時的にOllama Cloudを使う選択もあります（参考: Cloud – Ollama、関連: OllamaはCPUだけでどこまで使える？）。
量子化とインポート手順の詳細は公式ドキュメントがわかりやすいので、実行前に目を通すと再発防止になります（参考: Importing a Model – Ollama）。
ローカルLLMとクラウドLLM・有料サービスの使い分け戦略
当セクションでは、ローカルLLMとクラウドLLM・有料サービスをどう使い分けるかの判断基準と実務構成を解説します。
理由は、コスト・応答品質・同時接続・コンプライアンスのトレードオフを見誤ると、運用コストが膨らみ品質も不安定になりやすいからです。
- ローカルだけでは厳しくなる境界ラインを知っておく
- GPUマシン・クラウドインスタンスの選び方
- MLOps基盤・ベクタDB・モニタリングSaaSとの組み合わせ
ローカルだけでは厳しくなる境界ラインを知っておく
結論は、月間トークン量・同時接続数・必要品質の三点が一定ラインを超えたらハイブリッド運用へ切り替えるべき、です。
理由は、単一マシンのVRAM/メモリやI/Oがボトルネックになり、長文推論や高度なコーディング支援で品質低下や待ち行列が発生するためです。
具体的には、目安として「月間1,000万トークン超」「ピーク同時接続10超」「長文32kトークン級の推論頻度が高い」のいずれかに該当したら、クラウド併用でスパイクと高難度を逃がす構成が安定します。
判断の全体像は次の図のように、用途と負荷の分岐で整理します。
コスト面では、同じ処理量でもローカルの初期投資と電力で年額が抑えられ、ピークだけクラウドへ逃がすハイブリッドが最小化を狙えます。
例えば次の簡易比較表は、1,000万トークン/月・ピーク同時接続5想定の概算TCOです。
| 構成 | 初期/固定 | 変動費(月) | 年間概算 | 補足 |
|---|---|---|---|---|
| クラウドAPIのみ | なし | $150〜$300 | $1,800〜$3,600 | レート制限とコストスパイクに注意（参考: Skywork ai） |
| ローカルのみ | 約$1,500 | $10〜$20（電力） | $1,620〜$1,740 | 品質/ピーク耐性はハード依存（参考: Ollama CLI） |
| ハイブリッド | 約$1,500 | $50〜$120 | $2,100〜$2,940 | ピークと長文のみクラウドで品質と待機時間を両立（参考: Ollama Cloud） |
チーム別の推奨は「開発者3人＝ローカル中心7B〜14B」「10人＝ローカル14B中心＋クラウド長文」「50人＝社内推論サーバー＋クラウドSoTA」の順で拡張を検討します。
最終的には平常時をローカルで最適化し、スパイクと高難度だけをクラウドに逃がすのが費用対効果の最適解になりやすいです。
- 参考: Skywork ai
- 参考: Ollama Cloud
- 参考: Ollama CLI
より詳しいローカル実行の勘所は、ローカル環境でAIを実行するベストな方法も参照ください。
GPUマシン・クラウドインスタンスの選び方
結論は、モデル規模に対してVRAM（もしくはユニファイドメモリ）を先に決め、次に拡張性とコストを比較する順番が最短です。
理由は、7B/14B/30Bで必要VRAMが段階的に増え、ボトルネックの大半がメモリ帯域と容量で決まるためです。
代表パターンは「7B=8GB級」「14B=12〜16GB級」「30B=24GB級」で、オンプレGPU、主要クラウドGPU、Mac Studio/Mシリーズの三択でTCOを見比べます。
下表は最小構成の一例で、個別要件に応じてCPUやストレージを積み増します。
| モデル規模 | 推奨VRAM/メモリ | オンプレ例 | クラウド例 | Mac例 |
|---|---|---|---|---|
| 7B | 8GB〜 | RTX 4060 | A10G単発/低頻度 | M2/M3 16GB |
| 14B | 12〜16GB | RTX 4070/4080 | L4/A10G | M3 Pro |
| 30B | 24GB〜 | RTX 4090/6000 Ada | L40S/A100短時間 | M3 Max/Studio |
視覚化すると、VRAMとモデル規模の対応は次のように右肩上がりです。
量子化やコンテキスト拡張の影響も踏まえ、詳細なモデル別要件はOllamaのモデル完全ガイドを確認すると安全です。
- 参考: Modelfile Reference
- 参考: Ollama Download
MLOps基盤・ベクタDB・モニタリングSaaSとの組み合わせ
結論は、運用を見据えるなら「モデルレジストリ＋監視＋RAG基盤＋観測」を最初から疎結合に設計し、ローカルとクラウドを相互に差し替え可能にしておくべきです。
理由は、組織が成長するとモデル更新・品質回帰・ドリフト検知・問い合わせ監査が必須化し、単体のローカル運用だけでは追従が難しくなるためです。
実装は、LangChain/LlamaIndexをオーケストレーターに、Pinecone等のベクタDBとログ/評価SaaSを組み合わせ、推論先をOllamaローカルかクラウドAPIに切替えるアーキテクチャが実務的です。
全体像は次の図の通りで、ゲートウェイでルーティングし、観測はプロンプトと応答を匿名化して計測します。
本気でRAGを回すなら、検索・埋め込み・評価まで一体運用できる専用SaaSを検討し、ビジネスKPIから逆算してSLOを定義するのが近道です。
- 参考: Ollama OpenAI互換API
- 参考: Ollama CLI
RAGの要点はRAG構築のベストプラクティス、MLOpsの比較はMLOpsツール徹底比較、API連携の実装はOllama API徹底ガイドが参考になります。
社内のスキル育成には、体系的に学べるDMM 生成AI CAMPや実務志向のAidemyの活用も検討すると早道です。
開発・業務フローに「ollama create」をどう組み込むか
当セクションでは、Modelfileを軸に「ollama create」を開発・業務フローへ組み込む実践パターンを解説します。
理由は、モデル定義の変更が品質・コスト・コンプライアンスに直結するため、アプリ同様の運用管理が不可欠だからです。
- 小さく始める：個人開発〜チーム内パイロットの進め方
- CI/CDに組み込んで“インフラの一部”として扱う
- ガバナンス・コンプライアンスとどう折り合いをつけるか
小さく始める：個人開発〜チーム内パイロットの進め方
結論は「一ユースケース×一チーム」で素早く検証し、勝ち筋を定義してから横展開することです。
小さく始めると、ユースケース固有の前提や社内用語に起因する誤動作を早期に発見し、安価かつ安全に改善を回せます。
実務ロードマップは「ModelfileをGit管理→ollama createでビルド→IDEや社内Botから接続」の順で進めると迷いません（参考: CLI Reference – Ollama）。
たとえばコードレビューBotのPoCでは、次のように作業します。
git add Modelfile
git commit -m "feat: team reviewer SYSTEM and params"
ollama create team-codereview:v0 -f Modelfile
ollama run team-codereview:v0接続先はローカルのOpenAI互換APIとして扱えるため、VS Code拡張やSlack連携の設定が容易です（手順の全体像は「【2025年版】Ollama API徹底ガイド」が参考になります）。
著者も大手企業でのマーケ業務自動化において、まずは一部署特化の小規模PoCから始めたことで、運用上の落とし穴と成果条件を迅速に明確化できました。
CI/CDに組み込んで“インフラの一部”として扱う
結論として、Modelfileの変更はアプリケーションコードと同等に扱い、CI/CDでテストとデプロイを自動化すべきです。
理由は、モデルの挙動がSystem/Template/Parameterで大きく変わるため、再現性と回帰防止が欠かせないからです。
具体例として、PR作成時にテスト用Ollamaサーバーで /api/create を叩き、回帰プロンプトセットで自動評価します（参考: API Reference – Ollama）。
モデル作成の自動ジョブは次の一行で十分に開始できます。
curl -s -X POST http://localhost:11434/api/create -H "Content-Type: application/json" -d '{"name":"tech-code-reviewer:pr-123","modelfile":"FROM codellama:7b-instruct\nPARAMETER seed 42\nSYSTEM \"You are a strict reviewer.\"","stream":false}'簡易回帰テストは「固定プロンプトに対し、期待される出力の一部を含むか」を判定するだけでも有効です。
# prompts.txt に「入力,期待語句」を列挙
while IFS=',' read -r prompt expect; do
out=$(curl -s http://localhost:11434/api/generate -H "Content-Type: application/json" -d "{\"model\":\"tech-code-reviewer:pr-123\",\"prompt\":\"$prompt\",\"stream\":false}" | jq -r '.response')
echo "$out" | grep -q "$expect" || { echo "NG: $prompt"; exit 1; }
done < prompts.txtなお再現性確保には seed、応答安定化には temperature/top_p を固定すると効果的です（出典: Modelfile Reference – Ollama）。
ガバナンス・コンプライアンスとどう折り合いをつけるか
結論は、ポリシーベースの設計で権限と責務を明確化し、Modelfileで禁止事項とライセンスを明示することです。
LLMは微細な設定差で出力が変わるため、誰がModelfileを変更できるか、レビュー/承認者は誰かの線引きが欠かせません。
実務では「Code OwnersでModelfileを必ずレビュー」「NGワードと内部ポリシーURLをSYSTEMに明記」「LICENSE命令で出自を可視化」をルール化します（参考: Modelfile Reference – Ollama）。
例として、以下のようにポリシーを埋め込みます。
SYSTEM """
あなたは社内向けAIです。
以下を厳守してください：
- 社外秘・個人情報を出力しない。
- 事実不明時は不明と回答する。
- 社内AIポリシー：https://intranet/policies/ai
- NGワード一覧：https://intranet/policies/ng-words
"""
LICENSE "Apache-2.0 (Base: llama3), Company Policy Addendum"著者は公的機関向けシステムでも同様にポリシー起点での設計を徹底し、審査や監査の通過率と変更管理の透明性を高めました。
運用設計の詳細は「【2025年版】Ollamaコマンド完全ガイド」や「Ollamaのモデル完全ガイド」も併せて参照してください。
体系的に社内人材のスキルアップを進める場合は、実務カリキュラムが整った学習サービスの活用も有効です（例: DMM 生成AI CAMP）。
まとめ：Modelfileで自社仕様を最短実装し、まずは小さく回す
本記事では、create と pull/run の違い、Modelfileの要点（命令・テンプレ・PARAMETER）、タグ設計とCI/CD、さらにトラブル対応とローカル／クラウド併用の勘所を実務目線で整理しました。
大事なのは「小さく作って早く回す」こと。Modelfileに自社ルールをコード化すれば、部門別の派生モデルを安全・低コストで量産できます。
次の一歩は、少人数チーム向けにGPUマシンやMシリーズMacを1台用意し、テンプレModelfile＋CI/CDでパイロット開始。処理量が増えたらOllama Cloudや商用LLM、ベクタDBを段階的に併用しましょう。
知見の定着には 生成AI 最速仕事術、事例研究には 生成AI活用の最前線、資料化は Gamma が有効です。いま、小さく始めて次のスケールへ。
