OllamaのModelfileで自分用の設定を保存する:役割と出力形式を固定する
AIを使いこなすClaudeで執筆し、GPTで自動校閲・修正しています。

結論から言うと、毎回貼っている「あなたは〇〇です。口調は〜、出力は〜」という前置きは、ModelfileのSYSTEMに書いてollama createで保存すれば、貼る手間をほぼなくせます。温度やコンテキスト長などの設定も同じファイルに残せます。 ただし限界もあります。Modelfileで固められるのは「役割・ルール・設定・お手本の会話」までで、出力形式を100%守らせる仕組みではありません。形式の厳守が必要なときは、Ollama APIのformatパラメータ(後述)を併用します。この記事では、構成要素、用途別のひな形3種、作ってから確認する手順を順に示します。 なお、ここに載せるModelfileは説明用の例で、私が実行して結果を確かめたものではありません。書式は公式ドキュメントで確認した範囲に合わせていますが、実行前に必ず最新のModelfileリファレンスと見比べてください。
Modelfileの構成要素と、前置きの置き場所
公式のModelfileリファレンス(2026年10月29日の自動校閲で確認)では、次の命令が説明されています。必須なのはFROMだけです。
- FROM、役割:ベースにするモデル(必須)、前置きの代わりになるか:土台の指定
- SYSTEM、役割:システムメッセージ、前置きの代わりになるか:役割・口調・禁止事項の置き場
- PARAMETER、役割:実行時の設定値、前置きの代わりになるか:温度や長さの固定
- MESSAGE、役割:会話履歴(user/assistant/systemの役割つき)、前置きの代わりになるか:お手本の入出力を見せる
- TEMPLATE、役割:モデルに送るプロンプトの形、前置きの代わりになるか:通常は触らなくてよい(後述)
- LICENSE / REQUIRES / CAPABILITY、役割:ライセンス、必要な最小バージョン、機能の追加、前置きの代わりになるか:用途が違う
書式のルールは、公式の記述では次のとおりです。コメントは#、命令は大文字小文字を区別せず、順序も自由です。SYSTEMは三重引用符で複数行を書けます。MESSAGEはMESSAGE user …、MESSAGE assistant …のように役割と本文を並べます。
主なPARAMETERは、同ページの表では次のように説明されています。
- temperature:創造性の度合い(表の既定値は0.8)
- num_ctx:次のトークン生成に使うコンテキストウィンドウの大きさ(表の既定値は2048)
- num_predict:生成する最大トークン数(表の既定値は-1で上限なし)
- seed:乱数シード(表の既定値は0)
- top_k、top_p、min_p:トークン選択の絞り込み
- stop:生成を止める文字列
表の既定値はそのページの記載であり、お使いのバージョンやモデルで実際の既定値が異なる可能性があります。気になる場合は、自分で値を明示しておくのが確実です。
基本の手順:書く、作る、動かす、直す
- ベースモデルを決める。 ollama lsで手元のモデル名を確認し、FROMにそのまま書きます。下の例のllama3.2は公式の例に出てくる名前を借りただけなので、手元にあるモデル名に置き換えてください。
- Modelfileを書く。 拡張子なしのModelfileという名前のテキストファイルにします。
- モデルを作る。 Modelfileのあるフォルダで次を実行します。名前は自分で付けます。
ollama create my-summarizer -f Modelfile- 動かす。 ollama run my-summarizerで起動します。
- 直す。 設定を変えたら、同じ名前でollama createをやり直します。不要になったモデルはollama rm 名前で消せます(CLIリファレンス)。
既存モデルがどんなModelfileで作られているかは、Modelfileリファレンスに載っているollama show --modelfile モデル名で見られます。自分で書く前に、ベースモデルのTEMPLATEやPARAMETERを眺めておくと、触ってよい部分が分かります。
用途別ひな形3種(説明用の例)
どれも、毎回貼る前置きをSYSTEMに移す発想です。括弧の中身や数値は好みに合わせて変えてください。数値(温度など)は編集上の目安で、公式の推奨値ではありません。
ひな形1:要約用(役割と出力形式を固定)
FROM llama3.2
PARAMETER temperature 0.3
PARAMETER num_ctx 4096
SYSTEM """
あなたは日本語の要約アシスタントです。
入力された文章を、次の形式だけで出力します。
【要点】3項目の箇条書き
【一文要約】60字以内
原文にない情報は足さず、分からない点は「不明」と書きます。
"""要約は創作ではないので、温度を既定より下げて揺れを減らす狙いです。num_ctxは長い文章を貼る場合に増やします(公式例にも4096が出てきます)。ただし大きくするほどメモリを使うので、手元の環境で様子を見てください。
ひな形2:文章の校正用(お手本を`MESSAGE`で見せる)
FROM llama3.2
PARAMETER temperature 0.2
SYSTEM """
あなたは丁寧な校正者です。意味を変えず、誤字と不自然な敬語だけを直します。
出力は「修正文」と「直した箇所」の2見出しのみです。
"""
MESSAGE user 明日の会義に参加いたします。
MESSAGE assistant """
修正文:明日の会議に参加いたします。
直した箇所:「会義」を「会議」に変更
"""ルールの説明より、1往復のお手本のほうが形式がそろいやすいことがあります。ここは経験則の紹介で、効果を測った数字はありません。お手本は1〜2組から始め、増やしすぎて入力に引きずられないか確認してください。複数行のMESSAGEは三重引用符で囲みます(公式リポジトリの構文テスト)。
ひな形3:情報の抜き出し用(項目名を固定)
FROM llama3.2
PARAMETER temperature 0
PARAMETER num_predict 300
SYSTEM """
入力文から次の項目を抜き出し、JSONだけを返します。
キーは date, place, topic の3つ。見つからない値は null にします。
説明文やコードブロックは付けません。
"""num_predictで出力の上限を決めています。ただし上限が小さすぎると、JSONが途中で切れます。切れた場合は値を増やしてください。
「形式の固定」にModelfileだけで頼らない
ModelfileのSYSTEMは、モデルへの指示にすぎません。指示を無視した出力が出る可能性は残ります。ひな形3のようにプログラムで読む出力が必要なら、Ollama APIのチャットエンドポイントにあるformatパラメータを併用します。公式の説明では、jsonでJSON形式を、JSONスキーマで項目や値の型を指定できます。ひな形3の欠損値を扱う場合は、スキーマでも各値にnullを許可します。受け取った結果はプログラム側でも検証してください(構造化出力の公式ガイド)。なお、同ガイドではOllamaのクラウドは構造化出力に未対応とされています。ここではローカルでの利用を想定しています。
使い分けの目安は次のとおりです。
- 口調・役割・禁止事項を毎回入れたくない、向く方法:ModelfileのSYSTEM
- 出力の型をお手本で寄せたい、向く方法:MESSAGEのお手本
- 温度や最大長をいつも同じにしたい、向く方法:PARAMETER
- 機械で処理するので形式を外したくない、向く方法:APIのformat(スキーマ指定)
- その場限りの入力(要約したい本文など)、向く方法:Modelfileには入れず、毎回の入力として渡す
最後の行が大事です。Modelfileに保存するのは「いつも同じ部分」だけにします。個人情報や社外秘の文章をSYSTEMやMESSAGEに直接書くと、ファイルとして残り続けます。お手本には架空の文を使ってください。
TEMPLATEは、ベースモデルが想定するプロンプトの形を決める命令です。公式ページには、既存モデルを加工するときに書き換えるべきかという指針は見当たりませんでした。役割や形式の固定が目的なら、まずSYSTEM、PARAMETER、MESSAGEだけで足りるかを試し、TEMPLATEはollama show --modelfileで中身を確認してから、必要なときだけ触るのが安全です。
作ったあとの確認手順
保存しただけでは効果は分かりません。次の3点を、人が見て確かめます。
- 同じ入力を3回ずつ試す。 同じ文章を3回入れて、見出しや項目名が毎回そろうか見ます。
- 外れ値の入力を試す。 空に近い入力、長すぎる入力、関係ない質問を入れ、「不明」「null」と返すか、勝手に作り話をしないかを確認します。
- 前置きありと比べる。 従来の貼り付け版と、保存版の出力を見比べます。保存版が悪化していたら、SYSTEMを短く具体的にして作り直します。
長い入力の途中が無視されるようなら、num_ctxを疑います。設定したコンテキストが入力に対して足りているかどうかで、結果が変わります。
AIに任せるのは下書きと形式合わせまでです。要約の内容が原文と合っているか、校正で意味が変わっていないか、抜き出した日付が正しいかは、人が原文と照らして確認してください。

