Ollama Modelfile パラメータ詳解：カスタムモデル作成の完全ガイド

前回の記事でモデルを動かす方法を紹介しましたが、一つずっと気になっていたことがあります——回答が安定しないんです。

どういうことかというと、llama3.2 に簡単なコードの質問をすると、時には 3 行の簡潔な答えが返ってくるし、時には論文みたいな長い回答が返ってくるんです。temperature パラメータを 0.8 にすると「創作的な発揮」を始めますし、0.1 にすると教科書を暗記しているみたいに硬くなります。さらに困るのは、毎回の会話で system prompt を設定し直さなきゃいけなくて、コピペするのもうんざりです。

その後、Ollama に Modelfile というものがあることを知りました。要するにモデルに「性格履歴書」を書くようなもの——一度設定すれば、ずっと有効です。この記事では、私が体験した失敗や調整の経験を整理しました。10 のコアパラメータの調整アドバイスと、すぐに使える 4 つの実践テンプレートも含まれています。

まだ Ollama をインストールしていない方は、前回の入門記事を先に読むことをお勧めします。この記事は発展的な内容で、ollama run ができることを前提としています。

一、Modelfile とは何か、なぜ必要なのか

Modelfile はモデルの「設定ブループリント」のようなものです。Dockerfile の概念と似ています——Ollama にどのモデルをベースにするか、どのパラメータを設定するか、システムプロンプトに何を書くかを伝え、そして名前を付けます。その後、この名前で呼び出すたびに、すべての設定が自動的に有効になります。

簡単に言うと、3 つの問題を解決します：

問題一：毎回設定を繰り返す必要がある

こんな経験があるはずです：ターミナルを開いて、ollama run llama3.2 と入力し、system prompt を打ち込みます。翌日また同じことを繰り返す。三日目もまた……面倒くさくないですか？Modelfile なら、これらの固定設定を書き留めておけば、一度の設定でずっと有効です。

問題二：出力スタイルが不安定

同じモデルでも、パラメータの設定が違えば、出力は天と地ほど違います。コードアシスタントには安定した出力が必要ですし、クリエイティブな文章には多様な発揮が必要です。「あ、そうだ、このタスクは temperature 0.3 で、あれは 0.8 で」なんて毎回覚えていられません——Modelfile なら、そのプリセットを保存しておけます。

問題三：モデルのバリエーション管理

「コードレビュー版 llama3.2」「文章作成アシスタント版 llama3.2」「JSON出力版 llama3.2」が欲しい。どうすればいい？モデルを 3 つコピーする？いいえ。Modelfile で 3 つの名前付きバリアントを作ればいいだけです。ベースは同じモデルファイルで、設定が違うだけです。

基本的な流れは 3 ステップ：

# 1. Modelfile ファイルを作成
echo 'FROM llama3.2
SYSTEM "あなたはコードレビューの専門家です"' > Modelfile

# 2. ollama create で新しいモデルを生成
ollama create my-coder -f Modelfile

# 3. 直接実行
ollama run my-coder

これだけ簡単です。次は Modelfile に何を書けるか詳しく見ていきましょう。

二、Modelfile の構造と 8 つの命令

Modelfile の構文はシンプルです：コメントは #、命令は大文字の単語で始まります。こんな感じ：

# これはコメントです
FROM llama3.2
PARAMETER temperature 0.8
SYSTEM "あなたは親切なアシスタントです"

ファイル全体には 2 種類のものしかありません：コメントと命令。命令はさらに 8 種類に分かれます。まず全体像を見てみましょう：

命令	役割	必須か	いつ使うか
FROM	ベースモデルを指定	必須	各ファイルに必須
PARAMETER	推論パラメータを設定	省略可	温度、コンテキストなどを調整
TEMPLATE	プロンプトテンプレート	省略可	会話形式をカスタマイズ
SYSTEM	システムメッセージ	省略可	ロールと振る舞いを設定
ADAPTER	LoRA アダプターをロード	省略可	モデルのファインチューニング時
LICENSE	ライセンス宣言	省略可	モデル公開時に必要
MESSAGE	会話履歴を事前設定	省略可	few-shot サンプル
REQUIRES	バージョン要件	省略可	特定バージョンの機能

正直、日常的に使う 90% のケースでは FROM、PARAMETER、SYSTEM の 3 つだけで十分です。その他は具体的なニーズができてから考えればいいでしょう。

FROM 命令の 3 つの使い方

FROM は唯一必須の命令で、3 つの書き方があります：

書き方一：モデル名を使う（最も一般的）

FROM llama3.2
FROM llama3.2:3b
FROM mistral:latest

Ollama がサポートするモデル名を直接使えます。コロン以降はバージョンタグで、書かない場合はデフォルトで latest になります。

書き方二：ローカル GGUF ファイルを使う

FROM ./my-model.gguf

他の場所からダウンロードした GGUF 形式のモデルファイルを直接指定できます。

書き方三：Safetensors ディレクトリを使う

FROM ./my-safetensors-dir

このケースは比較的少なく、一般的には Hugging Face からダウンロードしたモデルの元形式です。

さて、基本構造はこれで終わりです。次は本題——PARAMETER パラメータです。

三、PARAMETER パラメータ詳解

このセクションは記事の中で最も重要な部分です。私がパラメータ調整で経験した失敗を整理し、そのまま使える設定表を提供します。

まず完全なパラメータリストを見てみましょう：

パラメータ	デフォルト値	型	何に使うか	どう調整するか
temperature	0.8	float	ランダム性を制御、高いほど「自由奔放」に	コード 0.3、創作 1.0
num_ctx	2048	int	コンテキストウィンドウサイズ	長文ドキュメントは 4096-8192
top_k	40	int	確率が高い上位 K 個の単語のみから選択	通常はいじらない、出力が乱れる場合のみ
top_p	0.9	float	核サンプリング、多様性を制御	temperature と組み合わせて使用
min_p	0.0	float	確率が低すぎる単語をフィルタリング	高品質出力なら 0.05 に設定
seed	0	int	ランダムシードを固定、出力を再現	テスト時は 42 または固定値に設定
stop	なし	string	これが見えたら生成を停止	複数の stop を組み合わせ可能
num_predict	-1	int	最大出力長、-1 は無制限	出力を制限する場合は 100-500 に設定
repeat_penalty	1.1	float	繰り返し内容にペナルティ	長文生成なら 1.5 に引き上げ
repeat_last_n	64	int	直近 N 個の単語が重複していないか検出	repeat_penalty と組み合わせて使用

以下、最も重要なパラメータをいくつか詳しく説明します。

temperature：創造性 vs 安定性

最も理解しやすいパラメータです。temperature が高い（例えば 1.0）と、モデルは「自由奔放」になり、確率は低いけれど創造的な単語を選びます。temperature が低い（例えば 0.1）と、モデルは保守的になり、確率が最も高い単語だけを選び、出力はより安定します。

llama3.2 が異なる temperature で同じ質問に答えるときの違いをテストしました：

質問：Python でファイルを読み込むには？

• temperature 0.1：教科書のような出力、最も標準的な答えのみ
• temperature 0.5：実用的なヒントを補足、例えば「エンコーディングの問題に注意」など
• temperature 0.8：異なるシナリオでの異なる方法を説明したり、例を挙げたりする可能性がある
• temperature 1.0：回答は十人十色、時には話題から逸れることも

私の経験：

• コーディング、技術 Q&A：0.3 前後、安定性が必要
• クリエイティブな文章作成、ブレインストーミング：0.8-1.0、サプライズが必要
• JSON 出力、固定フォーマット：0.1-0.2、正確さが必要

num_ctx：コンテキストウィンドウ

このパラメータはモデルが「覚えていられる」コンテンツの量を決定します。デフォルトは 2048 tokens で、だいたい 1500-2000 文字です。

長い記事を読ませて要約させたい？2048 じゃ足りないかもしれません。長い会話をしていて、突然前の内容を忘れる？num_ctx が小さすぎる可能性が高いです。

重要な注意：num_ctx を大きくすると、より多くのメモリを消費します。llama3.2 をテストしたとき、num_ctx を 2048 から 8192 に上げると、メモリ使用量が倍以上になりました。もしマシンが 8GB しかメモリがない場合、4096 くらいが限界です。

私の経験：

• 短い会話、簡単な Q&A：2048 のデフォルトで十分
• コードレビュー、技術議論：4096 が快適
• 長文ドキュメント処理、小説執筆：8192（メモリが十分にある前提）

stop：停止シーケンス

このパラメータはとても便利です——モデルに「これが見えたら止まれ」と指示します。

例えば、モデルに JSON を出力させたいが、余計なことを出力しすぎるのが心配な場合：

PARAMETER stop "\n\n"
PARAMETER stop "```"

モデルは 2 つの改行またはコードブロックシンボルを見たら停止し、出力がよりクリーンになります。

stop は複数組み合わせることができます。これを知らない人が多いです。

repeat_penalty：無駄話を防止

モデルには一つの欠点があります：同じ言葉を繰り返しがちです。repeat_penalty はその繰り返し内容にペナルティを与えます。

デフォルト値は 1.1 ですが、私はもう十分じゃないと感じています。長い文章を書かせるときは、通常 1.3-1.5 に設定します。「前述のように」「要するに」といった無駄話を効果的に減らせます。

異なるシナリオでのパラメータ比較表

4 つの一般的なシナリオでの最適な設定をまとめました。そのまま使えます：

シナリオ	temperature	num_ctx	その他のパラメータ推奨
コードアシスタント	0.3	4096	stop ”```”, seed 42（再現しやすい）
クリエイティブな文章作成	1.0	2048	top_p 0.95, repeat_penalty 1.5
技術 Q&A	0.5	4096	min_p 0.05（低品質な単語をフィルタリング）
JSON 出力	0.1	2048	stop “\n\n”, stop ”```”

ここまで読めば、各パラメータについての理解が深まったはずです。次は実践パート——すぐに使える 4 つの Modelfile テンプレートを紹介します。

四、実践事例：4 つの完全な Modelfile

理論は終わったので、直接コードに入りましょう。これら 4 つのテンプレートはすべて実際にテスト済みで、コピペしてすぐに実行できます。

事例 1：ロールプレイ——猪八戒アシスタント

私が作った面白い小さなモデルで、猪八戒の話し方を真似する専用のモデルです：

# 猪八戒アシスタント Modelfile
FROM llama3.2

SYSTEM """あなたは西遊記の猪八戒です。話し方はユーモアがあって、親しみやすくしてください。
質問に答えるとき：
- 時々師匠がうるさいと愚痴る
- 食べ物の話になると興奮する
- 「俺様」を自称する
- 困難に直面すると「解散しよう」と言う"""

なぜこう設定するのか：

temperature を 0.8 に設定し、猪八戒の話し方により「個性」を持たせ、硬すぎないようにします。SYSTEM には具体的な行動ルールを書いています——食べ物の話になると興奮する、「俺様」を自称する——これらの詳細がキャラクターをより生き生きとさせます。

使い方：

ollama create pig-bajie -f Modelfile
ollama run pig-bajie

「プログラミングをどうやって学べばいい？」と聞いてみて、どう答えるか見てみましょう。

事例 2：プロフェッショナルアシスタント——Python コードレビュー

これは私の日常業務で使っている設定で、コードレビュー専用です：

# Python コードレビューアシスタント Modelfile
FROM llama3.2:3b

SYSTEM """あなたはシニア Python 開発者です。コードレビューでは以下に注目してください：
1. 型安全性——潜在的な型エラーがないか
2. 例外処理——エッジケースがカバーされているか
3. パフォーマンスのボトルネック——不必要なループや重複計算がないか
4. セキュリティリスク——機密データが露出していないか

返信フォーマット：
問題 → 影響 → 提案 → コード例"""

PARAMETER temperature 0.3
PARAMETER num_ctx 8192
PARAMETER seed 42

なぜこう設定するのか：

temperature 0.3 は出力の安定性を保証します——コードレビューに「創造的な発揮」は不要です。num_ctx を 8192 に設定したのは、コードファイルが非常に長くなる可能性があるからです。seed 42 は再現性のため——同じ質問には同じ提案を返し、比較テストがしやすくなります。

使用効果：数百行の Python コードを投げると、「問題→影響→提案→例」のフォーマットで明確なレビューレポートを出してくれます。

事例 3：構造化出力——JSON フォーマット

モデルの出力を他のプログラムに渡す場合、JSON フォーマットが最も便利です：

# JSON 出力アシスタント Modelfile
FROM llama3.2

SYSTEM """出力は必ず有効な JSON フォーマットにしてください。
分析結果フォーマット：
{"result": "分析内容", "confidence": 0-100, "tags": ["タグ1", "タグ2"]}

その他の内容は出力しないでください。コードブロックマークも付けないでください。"""

PARAMETER temperature 0.1
PARAMETER num_ctx 2048
PARAMETER stop "\n\n"
PARAMETER stop "```"

MESSAGE user このコードのセキュリティリスクを分析して
MESSAGE assistant {"result": "SQL インジェクションのリスクがあります。ユーザー入力がフィルタリングされていません", "confidence": 85, "tags": ["セキュリティ", "SQL"]}

なぜこう設定するのか：

temperature 0.1 は出力の最大の安定性を保証します——JSON フォーマットには少しのズレも許されません。stop パラメータは改行とコードブロックシンボルをフィルタリングし、モデルが余計なコンテンツを出力するのを防ぎます。MESSAGE パートは few-shot サンプルです——モデルに「出力はこういう風に」と教えます。

この設定は自動化フローで使っています：エラーログをモデルに投げると、構造化された分析結果を出力し、プログラムが自動的に処理します。

事例 4：長いコンテキスト——ドキュメント要約

長い記事を処理するときは、コンテキストウィンドウが十分大きい必要があります：

# ドキュメント要約アシスタント Modelfile
FROM llama3.2

SYSTEM """あなたはドキュメント要約の専門家です。出力要件：
- 要点は 5 つ以内
- 各要点は 50 文字以内
- 核心的な観点を先に抽出し、その後詳細を補足
- 日本語で出力"""

PARAMETER temperature 0.5
PARAMETER num_ctx 8192
PARAMETER num_predict 300

なぜこう設定するのか：

temperature 0.5——要約には安定性が必要ですが、硬すぎてもいけません（低すぎると要約が箇条書きのようになってしまいます）。num_ctx 8192 は長文ドキュメントを処理できることを保証します。num_predict 300 は出力長を制限します——要約が元の文章より長くてはいけません。

この設定で技術記事を処理しています：3000 字の記事を投げると、5 つの要点を、各 50 字以内で出してくれ、読む効率が大幅に上がりました。

まとめ

この 4 つのテンプレートは一般的なニーズをカバーしています。必要に応じて SYSTEM の内容を修正したり、パラメータを調整したりできます——Modelfile を修正したら ollama create を再実行するだけで、調整コストは低いです。

五、TEMPLATE と MESSAGE の発展編

前のケースでは TEMPLATE を使いませんでした。このパラメータは「発展機能」——会話形式を精細に制御する必要があるときに使うものです。

TEMPLATE の Go テンプレート構文

Ollama は Go のテンプレート構文を使用します。3 つの重要な変数があります：

• {{ .System }} —— あなたの SYSTEM 内容
• {{ .Prompt }} —— ユーザー入力
• {{ .Response }} —— モデル出力（出力フォーマットを定義するのに使用）

簡単な例：

FROM llama3.2

TEMPLATE """{{ .System }}

ユーザーの質問：{{ .Prompt }}

回答：{{ .Response }}"""

SYSTEM "あなたは技術の専門家です"

この TEMPLATE は会話の構造を定義しています：最初に SYSTEM 内容、次にユーザーの質問、最後にモデルの回答です。

正直、多くの場合 TEMPLATE をカスタマイズする必要はありません——Ollama のデフォルトテンプレートで十分です。いつ変更が必要ですか？

シナリオ一：他のツールとの統合

Ollama をあるチャットシステムに接続するとき、そのシステムに特定の入力フォーマット要件がある場合。TEMPLATE でアダプトできます。

シナリオ二：特殊な会話フォーマット

会話に「プレフィックス」を付けたい場合、例えば各文の先頭に [AI] や [USER] を付けたい場合、TEMPLATE で実現できます。

MESSAGE：会話履歴の事前設定

MESSAGE の役割は「モデルにいくつかの例を見せる」ことです。前の JSON 出力のケースで使いました：

MESSAGE user このコードのセキュリティリスクを分析して
MESSAGE assistant {"result": "SQL インジェクションのリスクがあります", "confidence": 85}

これはモデルに「ユーザーがこういう質問をしたら、こう答えるべき」と教えるようなもの——few-shot 学習の概念です。

複数の会話履歴を事前設定できます：

MESSAGE user こんにちは
MESSAGE assistant こんにちは、何かお手伝いしましょうか？
MESSAGE user 天気はどうですか
MESSAGE assistant リアルタイムの天気はわかりません。天気アプリを確認することをお勧めします。

モデル起動時にこれらの会話を「覚えて」おり、その後の新しい会話はこのスタイルを継続します。

モデルの Modelfile を確認する方法

あるモデルの Modelfile がどう書かれているか確認したい場合、このコマンドを使います：

ollama show --modelfile llama3.2

出力は長く、モデルのデフォルト設定がすべて含まれています。コピーして修正すれば、あなたのカスタムバージョンを作成できます。

このコマンドは特に有用です——効果が良いモデル（例えば誰かが共有したカスタム版）を見つけたら、ollama show でその Modelfile をエクスポートし、どう設定されているか学習できます。

六、よくある問題と避けるべきポイント

パラメータ調整において、失敗は避けられない道です。私が遭遇した典型的な問題をいくつか整理しました。参考にしてください。

問題一：temperature を低くしすぎると、出力が暗記のようになる

temperature は低ければ低いほど良い——出力が安定するから——と思う人がいます。私も最初はそう思って、コードアシスタントの temperature を 0.05 に設定しました。

結果は？モデルの回答が教科書の模範解答を暗記しているようで、柔軟性が全くありません。「Python でファイルを読むにはどうすればいい？」と聞くと、3 つの方法を教えてくれますが、どれも教科書的な標準的な書き方で、実用的なヒントが全くありません。

教訓：temperature は低ければ低いほど良いわけではありません。コードレビューには 0.3 で十分です。0.2 を下回ると硬くなります。正確な出力（例えば JSON）が必要な場合は確かに低くする必要がありますが、日常会話では必要ありません。

問題二：num_ctx を大きくしすぎると、メモリが溢れる

ある時、気まぐれで num_ctx を 16384 に設定しました——超長文ドキュメントを処理させたかったからです。数分実行した後、システムが激しくスワップを始め、マシン全体がカチカチになって動かなくなりました。

私のマシンは 16GB のメモリしかありません。llama3.2:3b 自体が約 2GB を占有し、num_ctx を 2048 から 16384 に上げると、メモリ使用量が直接 8GB 以上になります。さらに他のプログラムも……

教訓：num_ctx は適当に上げるものではありません。メモリの状況に応じて：

• 8GB メモリ：num_ctx は最大 4096
• 16GB メモリ：num_ctx は 8192 まで可能
• 32GB 以上：ようやく 16384 を試す条件がある

問題三：SYSTEM と MESSAGE を混同する

この 2 つの命令の役割は異なり、混同しやすいです：

• SYSTEM：永続的に有効なロール設定。毎回の会話で保持される
• MESSAGE：事前設定された会話履歴。few-shot サンプルに相当

例えば：モデルにコードレビューの専門家を演じさせたい場合、SYSTEM にはロール定義を書き、MESSAGE にはいくつかの Q&A サンプルを書きます。

多くの人は SYSTEM だけ書いて、MESSAGE を書かないため、モデルは「自分がコードレビューの専門家だと知っている」けれど、具体的な質問にどう答えるべきかわからなくなります。MESSAGE サンプルをいくつか追加すると、出力品質が明らかに向上します。

問題四：作成後に更新したい場合はどうするか

Modelfile で作成したモデルの設定を変更したい場合は？

シンプル——同じ名前で再度 ollama create して上書きします：

# 最初の作成
ollama create my-coder -f Modelfile

# 設定を変更したい？Modelfile を修正してから再度実行
ollama create my-coder -f Modelfile

Ollama は同名のモデルを直接上書きし、削除は不要です。もちろん、上書きしたくない場合は、別の名前にすればいいだけです：

ollama create my-coder-v2 -f Modelfile

問題五：他人の Modelfile をどう再現するか

誰かが共有したカスタムモデルの効果が良さそうで、どう設定しているか学びたい場合：

# まずそのモデルをプル
ollama pull someone-elses-model

# その Modelfile をエクスポート
ollama show --modelfile someone-elses-model > learned-modelfile

# 確認、学習、修正
cat learned-modelfile

このコマンドはよく使っています——コミュニティのカスタムモデルから多くのパラメータ調整テクニックを学びました。

まとめ

これだけ話しましたが、Modelfile のコアロジックは一言に要約できます：設定を固定し、毎回手動で調整するのを避ける。

すぐにできる 3 つのことを紹介します：

1. ロールプレイモデルを作成する

猪八戒アシスタントのテンプレートを試してみるか、好きなキャラクター（例えばドラえもん、アイアンマン）に変えてみてください。数回会話を重ねて、temperature パラメータが出力スタイルにどう影響するか感じてみてください。

2. 異なるパラメータでの出力を比較する

同じ質問を、temperature 0.3 と 0.8 でそれぞれ実行して、出力の違いを見てみてください。この実験は何度もやりましたが、毎回新しい発見があります。

3. よく使うシナリオを一つ見つける

コードレビュー、ドキュメント要約、クリエイティブな文章作成——あなたが日常的に使うシナリオを一つ選び、上のテンプレートを必要なバージョンに修正してください。数回調整した後、あなただけのカスタムモデルができます。

次回は Ollama の API 統合について紹介します——ローカルモデルをプログラムに接続し、OpenAI 互換インターフェースで呼び出す方法。Modelfile が設定できれば、API 呼び出しはより安定します——パラメータをコードで渡す必要がなく、カスタムモデルを直接使えばいいからです。

質問があればコメントしてください。私が経験した失敗が、あなたのいくつかの落とし穴を回避するのに役立つかもしれません。

Ollama カスタムモデルを作成

Modelfile を使って専用モデルを設定・作成

⏱️ 目安時間: 10 分

1. 1

   ステップ1: Modelfile ファイルを作成

   Modelfile という名前のテキストファイルを新規作成し、基本設定を書き込みます：
   
   • FROM llama3.2（ベースモデルを指定）
   • SYSTEM "あなたのシステムプロンプト"（ロールを定義）
   • PARAMETER temperature 0.3（温度パラメータを設定）
2. 2

   ステップ2: カスタムモデルを生成

   ターミナルで作成コマンドを実行：
   
   ```bash
   ollama create my-model -f Modelfile
   ```
   
   my-model はモデルにつける名前で、自由に設定できます。
3. 3

   ステップ3: 実行とテスト

   作成したモデルを直接実行：
   
   ```bash
   ollama run my-model
   ```
   
   いくつか質問をテストし、出力が期待通りか確認します。
4. 4

   ステップ4: 反復的に最適化

   出力が理想と異なる場合：
   
   • temperature パラメータを調整（コードは0.3/創作は0.8）
   • SYSTEM プロンプトを修正
   • MESSAGE サンプルを追加
   
   修正後、再度 `ollama create my-model -f Modelfile` を実行して上書きします。

FAQ

Modelfile とパラメータを直接設定する違いは？

Modelfile は設定を固定し、一度作成すれば永続的に有効です。パラメータを直接設定（ollama run 時に渡すなど）は毎回繰り返す必要があり、SYSTEM プロンプトなどの複雑な設定を保存できません。

temperature パラメータはどのくらいに設定すべき？

シーンによって選択：

• コードレビュー、技術 Q&A：0.3 前後、出力は安定
• クリエイティブな文章作成、ブレインストーミング：0.8-1.0、多様性を増加
• JSON 出力、固定フォーマット：0.1-0.2、正確さを確保

0.2 を下回ると硬くなり、1.0 を超えると話題から逸れる可能性があります。

num_ctx を大きくするとどのくらいメモリを消費する？

モデルサイズと num_ctx の値によって異なりますが、概ね：

• 8GB メモリ：num_ctx は最大 4096
• 16GB メモリ：num_ctx は 8192 まで可能
• 32GB 以上：16384 を試せる

実際のメモリ状況に応じて段階的に調整・テストすることをお勧めします。

既存モデルの Modelfile を確認するには？

`ollama show --modelfile モデル名` コマンドでモデルの完全な Modelfile 設定をエクスポートでき、学習や修正に便利です。

SYSTEM と MESSAGE の違いは？

両者の役割は異なります：

• SYSTEM：モデルのロールと振る舞いルールを定義、毎回の会話で有効
• MESSAGE：会話履歴を事前設定、few-shot サンプルに使用

併用することをお勧めします。SYSTEM でロールを定義し、MESSAGE でいくつかの Q&A サンプルを提示します。

作成後にパラメータを修正したい場合は？

Modelfile ファイルを修正した後、再度 `ollama create モデル名 -f Modelfile` を実行すれば同名モデルを上書きでき、削除は不要です。元のバージョンを保持したい場合は、異なるモデル名を使用してください。

8 min read · 公開日: 2026年4月5日 · 更新日: 2026年4月5日