【2025年版】Ollamaコマンド完全ガイド｜初心者でも「これだけ覚えれば仕事で使える」実践リスト

/ Ollama / By

（最終更新日: 2025年12月21日）

Ollamaは入れたけれど、run・pull・createの違いがあいまいで、英語ドキュメントもつらい——そんな悩みはありませんか。

本記事は、導入直後に本当に使うコマンドだけを用途別に絞り、仕事で即使える実践リストにしました。

まず「この用途ならこのコマンドだけ」を提示し、意味の違い・使い分け・よくあるエラーと対処までやさしく解説します。

run、pull・list・rm・cp、ps・serve・show、さらにcreateとModelfileまでをひと目で把握できます。

公式情報に基づき、現場でつまずきやすい順に並べたので、検索迷子にならずに手を動かせます。

読み終わるころには、VSCodeやブラウザ、自社システムとつなぐ前提の基礎操作が一通りこなせます。

Ollamaコマンドの全体像：どんな操作があるかを先に把握する

当セクションでは、Ollamaコマンドの全体像を先に整理し、どんな操作があるかと役割分担を明快にします。

最初に地図を持っておくと迷子にならず、後続の詳細解説や業務適用がスムーズに進むからです。

  • Ollama CLIの役割と仕組みをざっくり理解する
  • カテゴリ別：Ollamaコマンドのマップ（実行・管理・開発・サーバー）
  • インストール直後〜普段使いまでの典型フローをざっくり描く

Ollama CLIの役割と仕組みをざっくり理解する

結論は、Ollamaは「サーバー（バックエンド）」と「CLI（フロントエンド）」の二層構造で、CLIの操作はローカルHTTP APIへの呼び出しだという点です。

理由は、Ollama Serverが常駐プロセスとして127.0.0.1:11434で待ち受け、GPU/CPUへの割り当てやモデルのロードを担い、CLIはそのサーバーへリクエストを送る薄いクライアントだからです（参考: Ollama API docs）。

例えば「ollama run llama3.3」は、ローカルにモデルがなければ自動ダウンロードし、続けてサーバーに対話生成を依頼する挙動になります。

ollama run llama3.3
# または REST API で直接呼び出し
curl -s http://127.0.0.1:11434/api/generate \
  -H 'Content-Type: application/json' \
  -d '{"model":"llama3.3","prompt":"Hello"}'

この仕組みを図で捉えると、CLI→HTTP→Server→GPU/CPU→応答という一直線の流れで、後半のAPI連携とも自然に接続できます。

Ollamaのアーキテクチャ概念図：左にユーザーとターミナル（CLI）、中央にHTTP(127.0.0.1:11434)経由で接続するOllama Server、右にGPU/CPU、下部にモデルストレージ。CLI→Server→GPU/CPU→応答の矢印を表示。

難しい内部実装を暗記する必要はありませんが、仕組みを知っておくと接続エラーやGPU未認識時のトラブルシュートが格段に楽になります。

参考情報は次のとおりです。

API観点の実装詳細は後述の解説や、より網羅的な別記事「【2025年版】Ollama API徹底ガイド」も併せて確認してください。

カテゴリ別：Ollamaコマンドのマップ（実行・管理・開発・サーバー）

最短で実務投入するには、コマンドを用途別に四つへ整理して覚えるのがコツです。

理由は、頻出タスクごとに使うコマンドが固定化され、難易度と優先度の見取り図ができるからです。

以下の一覧表は「業務での使いどころ」を含めた早見表で、そのままコマンド辞書として使えます。

カテゴリコマンド難易度利用頻度主な業務シーン
モデル実行run低毎日チャット/Q&A、要約、ブレスト
取得・管理pull低週次〜月次モデルの事前ダウンロード、夜間更新
取得・管理list低随時容量確認、棚卸し
取得・管理rm低随時不要モデルの整理
取得・管理cp中時々バックアップ、別名保存
取得・管理show中時々ライセンス確認、Modelfile確認
サーバー/プロセスps低随時ロード状況、GPU/CPU比率の把握
サーバー/プロセスserve中検証時手動起動、環境変数テスト
カスタム/開発create中プロジェクト単位Modelfileからの専用モデル作成

モデル自体の選定やカスタム設計は「【2025年版】Ollamaのモデル完全ガイド」を先に押さえると、コマンドの使い分けが一気に楽になります。

APIを絡めたシステム連携を見据えるなら、OpenAI互換エンドポイントを含めた活用も要チェックです（参考: OpenAI compatibility）。

結論として、この四分割のマップを手元に置けば、運用・管理・開発の切り替えが素早くなり、実務で迷いません。

インストール直後〜普段使いまでの典型フローをざっくり描く

最短で実用に乗せるには、「インストール確認→実行→取得→一覧→整理」という5ステップを流れで覚えるのが効果的です。

単発のコマンド暗記よりも、ワークフローで手順化すると定着し、業務導線にそのまま載せやすいからです。

例えば次の順に進めます。

# 1) インストール確認
ollama --version

# 2) 初回実行（未取得なら自動ダウンロード）
ollama run llama3.3

# 3) 別モデルを事前取得
ollama pull qwen2.5-coder

# 4) 保有モデルを棚卸し
ollama list

# 5) 使わないモデルを削除
ollama rm <model>

筆者の社内PoCでは、日報の要約やFAQボット検証をこの流れで数時間で立ち上げ、後からRAGやAPI連携に拡張しました（参考: Dify×Ollama徹底ガイド）。

会議メモの自動化と併用するなら、録音から要約まで一気通貫できるデバイスも便利です（例: PLAUD NOTE）。

最後に、モデル選定やModelfileによる専用化まで視野を広げれば、同じフローでプロジェクト横展開が可能になります（参考: Modelfile Reference）。

よく使う基本コマンド１：`ollama run`でローカルLLMを動かす

当セクションでは、最も利用頻度が高い「ollama run」の基本と実務での使い方、便利ワザ、そしてトラブル対処をまとめて解説します。

なぜなら、「run」の理解が浅いと、対話と一括実行の使い分けやパイプ処理ができず、業務活用の効率が大きく落ちるからです。

  • `ollama run`の基本：モデルを指定して対話・一括実行する
  • 業務ユースの具体例：要約・翻訳・コード補完での`run`活用
  • 対話モードで知っておきたい便利コマンド（/bye, /set など）
  • `run`でつまずきがちなエラーと対処：モデルが見つからない・遅い

`ollama run`の基本：モデルを指定して対話・一括実行する

結論はシンプルで、「ollama run <model> [prompt]」は引数なしなら対話モード、ありなら一回きりのワンショット実行です。

この二つの動作を押さえると、日常のチャットは対話モード、スクリプトやパイプ処理はワンショットと、最短手順で使い分けられます。

対話モードにしたいときはモデル名だけで実行します。

$ ollama run llama3.3
> こんにちは、何ができますか？
こんにちは。要約、翻訳、アイデア出し、コード補助などをお手伝いします。
> /bye

一回だけの生成をしたいときは、プロンプトを引数に渡します。

$ ollama run llama3.3 "この文章を3行で要約して: ..."
• 要約1
• 要約2
• 要約3

他コマンドの出力を処理したいときは、標準入力をパイプで渡します。

$ cat meeting.txt | ollama run llama3.3 "会議の要点を箇条書きで日本語要約して"
- 要点1
- 要点2
- 要点3

なお、指定モデルがローカルに無い場合は自動でダウンロード（pull）が走ります（出力に “pulling” が表示されます）。（参考: Ollama README）

$ ollama run llama3.3
pulling manifest
pulling 1.1 GB / 1.1 GB ... done
> 準備完了です。何をしますか？

モデル名の選び方や正式名称は、用途別のおすすめをまとめた解説も参考にしてください（【2025年版】Ollamaのモデル完全ガイド）。

業務ユースの具体例：要約・翻訳・コード補完での`run`活用

結論として、`ollama run`は「長文要約」「英文メール添削」「ログからの原因分析」など日々の定型業務に即投入できます。

理由は、ワンライナーで標準入力と組み合わせられ、結果がそのまま標準出力に返るため自動化しやすいからです。

次のコマンドはコピペして文言だけ差し替えれば、そのまま実務で使えます。

# 長文要約（会議メモや議事録）
cat meeting.txt | ollama run llama3.3 "この会議を日本語で要約してください"

# 英文メールの自然なビジネス文修正
ollama run llama3.3 "次の英文をビジネスメールとして自然に整えて: <貼り付け>"

# コードレビュー/障害解析（ログを食わせる）
cat error.log | ollama run qwen2.5-coder "原因と修正案を教えて"

出力を保存したいときは tee でファイルへ同時保存するなど、UNIXユーティリティと相性よく扱えます。

モデルの選定で迷ったら、用途別の推奨モデルを整理した比較も役立ちます（LLMおすすめ比較）。

会議の要約は録音の文字起こしと組み合わせると効率が跳ね上がります（録音→自動テキスト化→上記コマンド）（例: PLAUD NOTE）。

対話モードで知っておきたい便利コマンド（/bye, /set など）

結論は、対話モードには「チャットを終える」「その場でパラメータ変更」「使い方を確認」の3種の基本操作があり、CLIだけで完結します。

理由は、/bye・/set・/? の特殊コマンドがREPLに用意されており、生成の挙動を手早くコントロールできるからです。

代表的な使い方は次のとおりです。

$ ollama run llama3.3
> /?          # ヘルプの表示
> /set temperature 0.2  # 生成のぶれを抑える
> 重要ポイントだけを3行で説明して
...（回答）
> /bye        # 対話を終了
ターミナル上のOllama対話モードのイメージ図。/?でヘルプ、/set temperature 0.2で温度変更、/byeで終了する操作を矢印と注釈で示したCLIチートシート。

これらのコマンドが使える前提は「引数なしでrunを起動した対話モード」で、挙動は公式の使用例と一致します。（参考: Ollama README）

なお、非エンジニアのメンバーにはGUIフロントの併用も有効です（例: Open WebUI、ノーコード連携は Dify×Ollama徹底ガイド も参照）。

パラメータ変更はセッション一時適用なので、恒久設定したい場合はModelfile側で固定化するのが安全です（出典: Modelfile Reference）。

`run`でつまずきがちなエラーと対処：モデルが見つからない・遅い

結論として、つまずきは「model not found」「遅い」「途中で落ちる」の三大パターンを順番に切り分ければ解決しやすいです。

理由は、原因の多くがモデル名の不一致、GPU未使用やメモリ不足といった再現しやすい環境要因に集約されるからです。

まずは次の対応表で、症状ごとの原因と確認コマンドをチェックしてください。

症状主な原因確認・対処
model not foundスペル/バージョン違い・未ダウンロードollama listで存在確認→なければollama pull <model>
実行が極端に遅いGPU未使用・VRAM不足でCPUオフロードollama psのPROCESSORがCPU寄りか確認、Dockerは--gpus=allを付与
途中で落ちる/止まるRAM/VRAM不足・コンテキスト過大小さいモデル/低いnum_ctxで再試行、並列実行を減らす

GPU利用有無はollama psでPROCESSOR欄を確認し、期待通りにGPUが使われていない場合はドライバ/コンテナ設定やモデルサイズを見直します。

$ ollama ps
NAME        ID      SIZE   PROCESSOR      UNTIL
llama3.3    ...     4.1GB  100% GPU       4m59s

より詳しい切り分け手順や要件は公式ドキュメントを参照してください。

よく使う基本コマンド２：`pull`・`list`・`rm`・`cp`でモデルを管理

当セクションでは、Ollamaでモデルを取得・確認・削除・複製する基本コマンド（pull、list、rm、cp）の実務的な使い方を解説します。

なぜなら、業務での応答速度やディスク容量、バージョン管理のしやすさは「モデル管理の基本動作」を正しく押さえることで大きく改善するからです。

  • `ollama pull`：事前にモデルをダウンロードしておく
  • `ollama list`：インストール済みモデルの一覧と容量を把握する
  • `ollama rm`：不要なモデルを安全に削除する
  • `ollama cp`：既存モデルをコピーしてカスタマイズの土台にする

`ollama pull`：事前にモデルをダウンロードしておく

結論は、よく使うモデルは勤務時間外にあらかじめpullしておき、業務中の待ち時間をゼロに近づけることです。

理由は、ollama runは未インストール時に自動ダウンロードが走るため、会議中の要約や緊急のコードレビューで待ち時間が発生しやすいからです。

ollama pull <model>
# 例
ollama pull llama3.3
ollama pull mistral-small
ollama pull qwen2.5-coder

pullは最新版の取得にも使え、Ollamaは差分ダウンロードに対応するため通信量と時間を抑えられます（参考: ollama/ollama README）。

例えば、よく使うモデルは次のとおりです。

  • llama3.3：汎用で高精度な日本語・多言語の業務相談や要約に最適（詳細はOllamaのモデル完全ガイド）。
  • mistral-small：軽量高速でRAGやチャットボットの常時稼働に好適。
  • qwen2.5-coder：コード生成やリファクタリングで開発チームの即戦力。

夜間バッチでpullを仕込んでおく運用は、朝の立ち上がりや社内デモの体感速度を確実に上げます。

`ollama list`：インストール済みモデルの一覧と容量を把握する

結論として、listで「何が、どれだけの容量で、いつ更新されたか」を把握し、ストレージを計画的に管理します。

理由は、巨大モデルがディスクを圧迫してOSや他システムの動作に影響する前に、容量管理の意思決定が必要だからです。

出力は次のように表示されます。

$ ollama list
NAME                    ID              SIZE     MODIFIED
llama3.3:latest        2f1c...a9e2     42.3 GB  2025-07-01 12:34:56
mistral-small:latest   9b77...1c4d     13.1 GB  2025-06-21 08:10:12
qwen2.5-coder:32b      7a51...ff20     20.8 GB  2025-07-10 19:02:03

SIZEはディスク占有量、MODIFIEDは最終更新時刻の目安で、古いテストモデルや巨大な70B級を見つけて整理するのに役立ちます（参考: ollama/ollama README）。

部門横断で「どのPC/サーバーに何があるか」を棚卸する際はlistの結果を共有し、必要なら保存先を別ドライブに移す検討も有効です（関連: ローカルでAIを実行する最適ガイド）。

`ollama rm`：不要なモデルを安全に削除する

結論は、使わないモデルはrmで迷わず削除し、必要になれば再度pullすれば良いというスタンスです。

理由は、モデルは再取得が容易であり、ディスク不足を放置する方が全体の生産性を落とすからです。

コマンドは次のとおりです。

ollama rm <model>
# 例
ollama rm mistral-small

削除前に構成の確認（ollama show <model> –modelfile）や複製バックアップ（ollama cp <model> <model-backup>）を行うのがベストプラクティスです（参考: ollama/ollama README）。

筆者は検証用70Bモデルをrmして数十GBを即時回収し、必要時だけpullする運用に切り替えて安定運用できました。

`ollama cp`：既存モデルをコピーしてカスタマイズの土台にする

結論は、cpで元モデルを残したまま別名に複製し、安心してパラメータやテンプレートの調整を進めることです。

理由は、直接いじると元に戻しづらく、検証と本番の切り分けが壊れやすいからです。

コマンドは次のとおりです。

ollama cp <source> <destination>
# 例（実験用の複製を作成）
ollama cp llama3.3 llama3.3-lab
# 例（バージョンを分けて運用）
ollama cp qwen2.5-coder qwen2.5-coder-v1

cpで「実験用」と「安定版」を分けておけば、後段のcreateやModelfileで本格カスタムを行う際も安全です（参考: ollama/ollama README、関連: Ollamaのモデル完全ガイド）。

まずはコピーしてから触る、という運用習慣が事故を減らし、チーム内の再現性も高めます。

よく使う基本コマンド３：`ps`・`serve`・`show`で状態を把握する

当セクションでは、Ollama運用で最初に覚えるべき状態把握コマンド「ps」「serve」「show」の実践的な使い方を解説します。

なぜなら、複数人・複数モデルの同時利用では「なぜ重いのか」「GPUが効いているのか」「どのモデルがメモリを占有しているのか」を素早く見抜くことが、トラブルを最短で解消する鍵になるからです。

併せて、API連携を進める場合の基礎知識は【2025年版】Ollama API徹底ガイドも参考になります。

  • `ollama ps`：どのモデルがメモリに載っているか確認する
  • `ollama serve`：サーバープロセスを手動で起動・停止する
  • `ollama show`：モデルの詳細・ライセンス・Modelfileを確認する

`ollama ps`：どのモデルがメモリに載っているか確認する

「重いときはまず ps」が鉄則で、どのモデルがRAM/VRAMに常駐し、どのプロセッサで計算しているかを一目で把握できます。

psは実行中のモデルやロード状況、PROCESSOR列のGPU/CPU割合、そしてモデルが自動的にアンロードされるまでの残り時間を示すUNTIL（OLLAMA_KEEP_ALIVEの影響を受ける）を表示します（参考: Ollama README・Hardware support – Ollama Docs）。

次の出力例では、2つのモデルが同時にロードされ、GPUとCPUのオフロード割合が異なることが分かります。

$ ollama ps
NAME                STATUS      PROCESSOR           SIZE    UNTIL
llama3.3:8b         running     100% GPU            4.1G    24m57s
qwen2.5-coder:32b   running     48% CPU / 52% GPU   7.2G    4m12s

次の図は、各列の意味と「GPU未認識時の典型パターン（100% CPU）」を注記した読み方の例です。

ターミナル上の『ollama ps』出力に注釈を付け、NAME・STATUS・PROCESSOR・SIZE・UNTILの各列の意味を解説した図。1行目は100% GPUでVRAM常駐、2行目は48% CPU / 52% GPUのハイブリッド実行。下部に『GPU未認識の典型: 100% CPU』や『UNTILはアンロードまでの残り時間（KEEP_ALIVE）』などの吹き出し注記。

たとえば100% GPUはVRAMに十分収まっているサインで、CPU/GPUが分割されていればVRAM不足によるオフロードが発生している可能性が高いです。

全員が「急に遅い」と感じるときにPROCESSORが100% CPUで固定されていれば、GPU未認識やドライバの問題が疑われるため、nvidia-smiやROCmの有効性、OLLAMA_DEBUG=1でのログ確認から一次切り分けを行うと解決が早いです（参考: Hardware support – Ollama Docs）。

`ollama serve`：サーバープロセスを手動で起動・停止する

デバッグや一時的な環境変数テストをしたいときは、常駐サービスを止めて ollama serve を前面起動すると挙動がクリアに分かります。

通常はOS起動時に自動起動しますが、ポートやCORS、KEEP_ALIVEなどを変えて検証したい場合は手動起動が便利です（参考: Linux – Ollama Docs・Homebrew services の案内はLinuxページからも参照可）。

systemd運用のLinuxでデバッグ起動する例です。

# 常駐サービスを停止
sudo systemctl stop ollama
# 環境変数を変えて前面で起動（ログを観察）
OLLAMA_HOST=0.0.0.0:11434 OLLAMA_KEEP_ALIVE=24h OLLAMA_DEBUG=1 ollama serve

macOSでHomebrew servicesを使っている場合の例です。

brew services stop ollama
OLLAMA_DEBUG=1 ollama serve

0.0.0.0で公開すると社内から誰でも叩けるため、実運用では必ずリバースプロキシや認証を前段に置き、管理系エンドポイントの制限やTLS終端を行ってください（参考: Authentication – Ollama Docs）。

ネットワーク公開やOpenAI互換APIの扱いはOllama API徹底ガイドで図解しているので、チーム展開前に一読すると安全です。

`ollama show`：モデルの詳細・ライセンス・Modelfileを確認する

社外提供システムに組み込む前は、必ず「ollama show –license」で商用可否と利用条件を確認してください。

showはモデルのメタ情報、システムプロンプト、テンプレート、固定パラメータ、そしてModelfileの再現を表示でき、技術検収や監査での説明責任を果たすのに有効です（参考: Modelfile Reference – Ollama Docs・Ollama README）。

代表的なオプションの使い方は次のとおりです。

# ライセンス条項
ollama show llama3.3 --license
# モデルの構成（ベース、SYSTEM、TEMPLATE、PARAMETERなど）
ollama show llama3.3 --modelfile
# 生成パラメータとシステムプロンプト
ollama show llama3.3 --parameters
ollama show llama3.3 --system

コミュニティ由来モデルでは「研究目的のみ」「再配布不可」などの条件が含まれる場合があるため、業務利用や配布前に条文を読み、必要に応じて法務と合意形成を取る運用が安全です。

Modelfileのテキストはリポジトリに保存して差分管理すると、設定ドリフトを防げて監査にも強くなります。

モデル設計やModelfile活用全般は【2025年版】Ollamaのモデル完全ガイドで詳しく掘り下げています。

体系的にスキルを固めたい方は、基礎から業務適用まで学べるオンライン講座の活用も有効です（例: DMM 生成AI CAMP）。

発展編：`create`とModelfileで自社専用モデルを作る

当セクションでは、ollama create と Modelfile を使って自社専用モデルを作る手順と考え方、そしてつまずきやすいポイントを解説します。

なぜなら、長いシステムプロンプトを毎回貼る運用は再現性が低くミスも起きやすく、Modelfileでプロンプトとパラメータをコード化してモデルに焼き込むことで業務品質とガバナンスが両立するからです。

  • `ollama create`の役割：プロンプト設定を「モデル化」する
  • 最小限のModelfile例：社内ヘルプデスクボットを作ってみる
  • よくある失敗：Modelfileの書き方ミスとデバッグのコツ

`ollama create`の役割：プロンプト設定を「モデル化」する

結論は、`ollama create`でプロンプト設定をモデル化して再現性を確保できるということです。

Dockerfileからコンテナイメージを作るのと同じ発想で、ModelfileはAIモデルの設計図になり、システムプロンプトや温度などのパラメータを一体化して配布可能な専用モデルにします。

実行はシンプルで、Modelfileを用意したら次の1行で社内配布できるモデルが完成します。

ollama create helpdesk-bot -f Modelfile
Modelfile、ollama create、helpdesk-botの3要素を矢印で結んだフロー図。左にModelfile（FROM/PARAMETER/SYSTEMの要素つき）、中央に『ollama create』、右に『helpdesk-bot（自社専用モデル）』。下段に『Dockerfile→Image』の対応関係を小さく併記。

レポートでも紹介した社内ヘルプデスク用モデルでは、常に丁寧語で回答し、最後にJSONのカテゴリ情報を付けるルールを焼き込み、問い合わせ品質を均一化しました。

要するに、プロンプトエンジニアリングを「コード化」して共有資産にできるのが価値であり、公式のModelfileリファレンスを併読すると理解が深まります（参考: Modelfile Reference – Ollama）。

最小限のModelfile例：社内ヘルプデスクボットを作ってみる

結論として、FROM・PARAMETER・SYSTEMの3要素だけで最小の社内用モデルは作れます。

構文を絞るほど迷いが減り、CLI初心者でもPoCを当日中に回せます。

# Modelfile（最小例）
FROM llama3.3
PARAMETER temperature 0.2
PARAMETER num_ctx 8192
SYSTEM """
あなたは株式会社〇〇の社内ITヘルプデスクAIです。
常に敬語で親切に回答し、最後に必ずJSONカテゴリを出力してください。
例: {"category": "network", "priority": "high"}
"""
  1. Modelfileを作る。
  2. `ollama create helpdesk-bot -f Modelfile`を実行する。
    ollama create helpdesk-bot -f Modelfile

  3. `ollama run helpdesk-bot`で動作確認する。
    ollama run helpdesk-bot "Wifiに繋がりません"

この最小構成でも「丁寧語＋JSONフッター」が毎回出力され、FAQ対応のPoCに十分です。

拡張は段階的に行い、RAGの統合やUI化は次ステップで検討すると安全です（参考: 【2025年最新】RAG（Retrieval-Augmented Generation）構築のベストプラクティス、【2025年版】Dify×Ollama徹底ガイド）。

さらに体系的に業務最適化の型を学ぶなら、実務のプロンプト設計も多数載っている書籍も役立ちます（参考: 生成AI 最速仕事術）。

よくある失敗：Modelfileの書き方ミスとデバッグのコツ

結論は、小さな記法ミスが多発するためエラーメッセージの読み取りと既存モデルとの比較が最速の解決策です。

理由は、Modelfileのパーサは厳密で、クォートの閉じ忘れやパラメータ名のタイプミスがそのままビルド失敗に直結するからです。

  • クォートの不一致（””” と ” の混在）
  • PARAMETER名の誤記（例: num-ctx と書いてしまう）
  • SYSTEMブロック内のJSONに不要な末尾カンマ
  • 存在しないベースモデルをFROMに指定
# 参考になるデバッグ手順
OLLAMA_DEBUG=1 ollama create helpdesk-bot -f Modelfile
ollama show llama3.3 --modelfile

私も最初は30分ほど、SYSTEMを”””で囲んだのに末尾の”””の前で全角スペースが紛れ込み、原因が分からず詰まりました。

最終的には`OLLAMA_DEBUG=1`でログを眺めつつ、`ollama show <モデル名> –modelfile`で正しい書式を写経して解決できました。

要点として、最小構成でビルドが通ることを確認し、パラメータを一つずつ追加してGitで差分管理すると安定します（参考: Modelfile Reference – Ollama、FAQ – Ollama）。

CLIが苦手な人向け：最低限これだけ覚えればOKな操作フロー

当セクションでは、CLIが苦手でも今日から業務で使えるOllamaの最低限フローを、最短手順と具体例で解説します。

初学者がつまずきやすいのは「サーバーが動いているのか」「どのコマンドだけ覚えればよいか」なので、迷わない道筋に整理しています。

  • インストール直後にやること3つ：動作確認〜初回モデル実行まで
  • 日常利用でよく使う操作パターンをレシピ化する
  • どうしてもCLIがつらい場合の代替案：GUIや他ツールとの組み合わせ

インストール直後にやること3つ：動作確認〜初回モデル実行まで

結論は、次の3ステップだけでOllamaの動作確認から初回実行まで完了します。

Windows・macOS・Linuxのどれでもほぼ同じコマンドで動くため、環境差を気にしすぎなくて大丈夫です。

まず「バージョン確認」でインストール成功をチェックします。

黒いターミナル画面に3つの手順が並ぶ概略図。1) ollama --version の出力例、2) ollama ps の空表示、3) ollama run llama3.3 の初回ダウンロードと応答例が矢印でつながる。各OSアイコン（Windows/macOS/Linux）も並び、同一手順で動くことを示す。

ollama --version
# 例）出力例
o# ollama version 0.3.x

次に「サーバー状態」は ps で確認し、何も表示されなくても問題ありません。

ollama ps
# 例）初回は空（実行中モデルなし）

最後に run で初回実行しますが、ローカルにモデルがなければ自動でダウンロードが始まります。

ollama run llama3.3
# プロンプトが表示されたら、試しに「こんにちは」と入力

この3手順が通れば準備完了で、以降はプロンプトを投げるだけで利用を開始できます。

日常利用でよく使う操作パターンをレシピ化する

日常業務は「1.ファイル準備→2.ollama run→3.結果コピー」の型にそろえると迷いません。

覚えるコマンドを run と、必要に応じた pull の二つに絞ると、非エンジニアのメンバーでも運用しやすくなります。

モデル選びに迷ったら用途別の推奨をまとめた解説を参照してください（内部解説: 【2025年版】Ollamaのモデル完全ガイド）。

プロンプト文の型は事前にテンプレ化すると再現性が上がります（基礎: プロンプトエンジニアリング入門）。

3つのレシピカードを横並びにした図。議事録要約・英文メールチェック・コード生成の各カードに、1)ファイル準備 2) ollama run 3)結果コピー の流れと使用コマンドがアイコン付きで示される。

  • 事前準備（任意・夜間推奨）
# 必要なら先にモデルを取得（初回の待ち時間を回避）
ollama pull llama3.3
ollama pull qwen2.5-coder
  • レシピ1：議事録要約
# 1) minutes.txt を用意
# 2) 実行（要点5行）
cat minutes.txt | ollama run llama3.3 "この会議の要点を5行で日本語要約してください"
# 3) 生成結果をメモアプリへ貼り付け
  • レシピ2：英文メールチェック
cat mail_en.txt | ollama run llama3.3 "以下の英文を丁寧なビジネス英語に添削し、日本語の改善ポイントも併記してください"
  • レシピ3：簡単なコード生成
ollama run qwen2.5-coder "CSVを読み込み、列Aでグループ化して合計を出力するPythonスクリプトを書いて"

まずは一つのレシピをチームで標準化し、納得の品質が出たら他パターンへ横展開しましょう。

プロンプトの型に不安がある人は、基礎を短時間で固められる実務本も役立ちます（参考図書: 生成AI 最速仕事術）。

どうしてもCLIがつらい場合の代替案：GUIや他ツールとの組み合わせ

CLIがつらければ、Ollamaは裏方に置き、操作はGUIに任せればOKです。

GUIは入力補助や履歴管理がしやすく、タイピングの負担や教育コストを大幅に下げられます。

IT担当がOllamaサーバーを用意し、メンバーはブラウザやIDEから使う役割分担が現実的です。

Ollama Server(11434)を中心に、左にOpen WebUI/ブラウザ、右にVSCode拡張やノーコードツール(Dify)が接続される構成図。LAN内アクセスと役割分担（IT担当/利用者）の注記付き。

  • 選択肢の例

まずは社内LAN限定で始め、利用が広がるタイミングで認証や権限を段階的に整備すると移行がスムーズです。

慣れてきたらAPI連携やRAG構築に発展でき、投資対効果をさらに高められます（実装解説: 【2025年版】Ollama API徹底ガイド、設計ガイド: RAG構築のベストプラクティス）。

Ollamaコマンドでよくあるエラーと自己解決のチェックリスト

当セクションでは、Ollamaコマンドで発生しがちなエラーをパターン別に整理し、数分で自己解決するためのチェックリストを提示します。

なぜなら、現場で多いトラブルの大半は「モデル未取得」「サーバー未起動・接続設定不整合」「リソース不足」の三点に集約され、確認の順序を誤らなければ短時間で復旧できるからです。

モデルの基本操作やおすすめモデルの選び方は、併せてこちらも参考にしてください。

【2025年版】Ollamaのモデル完全ガイド / 【2025年版】Ollama API徹底ガイド / ローカル環境でAIを実行するベストな方法

  • 「モデルが見つからない」「接続できない」系エラーの整理
  • パフォーマンス・メモリ関連のエラーと`ps`・環境変数の活用
  • ログ・デバッグ情報の見方：`OLLAMA_DEBUG`で原因を絞り込む

「モデルが見つからない」「接続できない」系エラーの整理

最短で直すコツは「モデルの有無」か「サーバー接続」かを最初に切り分けることです。

なぜなら、model not found／connection refused／permission denied は原因と対処コマンドがそれぞれ明確に異なるからです。

まずは下のチェックリスト表に沿って、症状→確認→対処の順に進めます。

症状主な原因候補確認コマンド対処
model not foundモデル未取得・名称誤りollama listollama pull <model> で取得
connection refusedサーバー未起動／ポート競合／OLLAMA_HOST設定ミスcurl http://127.0.0.1:11434 などollama serve で起動／待受アドレスとポートを修正
permission denied権限不足／インストール先・モデル保存先の権限不整合保存ディレクトリの権限確認管理者権限で再実行／保存先の所有者・権限を修正

典型操作は次のとおりです。

# インストール済みモデルを確認
ollama list

# モデルを取得
ollama pull llama3.3

# サーバーを明示起動（環境変数テスト時など）
OLLAMA_HOST=0.0.0.0:11434 ollama serve

全体像は下図フローをなぞると迷いにくく、名前解決→サーバー→権限の順で安全に切り分けできます。

Ollamaのトラブルシュートフローチャート：model not found→ollama list/ollama pull、connection refused→サーバー起動・ポート競合・OLLAMA_HOST確認、permission denied→権限修正

参考情報は公式FAQとプラットフォーム別ドキュメントが有用です。

パフォーマンス・メモリ関連のエラーと`ps`・環境変数の活用

結論として、推論が遅い・途中で止まる・ロード失敗の多くはVRAM/RAM不足やCPUオフロード過多が原因なので、まず ollama ps と環境変数で状態を可視化します。

理由は、Ollamaはモデルをメモリに常駐させる設計で、保持時間や同時ロード数、GPU割当の挙動がボトルネックになりやすいからです。

代表的な確認と調整の例を示します。

# 実行中モデルとプロセッサ使用率を確認
ollama ps

# よく使うチューニング（例）
# 使い回すなら保持時間を延長（秒/分/時間、-1は無期限）
export OLLAMA_KEEP_ALIVE=24h
# 同時ロード数の上限（切替頻度が高い時に有効）
export OLLAMA_MAX_LOADED_MODELS=2
# モデル保存先（容量ひっ迫時に）
export OLLAMA_MODELS=/data/ollama/models

とりあえず試す設定は次の三つが効果的です。

  • OLLAMA_KEEP_ALIVE を延ばして再ロード待ちを削減
  • OLLAMA_MAX_LOADED_MODELS を下げてVRAM圧迫を回避
  • 大きすぎるモデルは量子化小さめの版へ切替（例: 70B→24B/8B）

目安として、7B〜14BはVRAM 8〜16GB級、24B前後は24GB級が実用ラインで、足りない場合はCPUオフロードで数倍遅くなる前提で運用します。

モデル規模推奨VRAM（4bit量子化の目安）ひとまずの設定例
7B8–12GBKEEP_ALIVE=1h / MAX_LOADED_MODELS=1
14B16GB前後KEEP_ALIVE=4h / MAX_LOADED_MODELS=1
24–32B24GBKEEP_ALIVE=8h / MAX_LOADED_MODELS=1

この手順でボトルネックを除けば、タイムアウトやOOMに悩まされる頻度を大きく減らせます。

関連リンク: モデル選定の実務目安

ログ・デバッグ情報の見方：OLLAMA_DEBUGで原因を絞り込む

結論は、困ったら一時的に OLLAMA_DEBUG=1 を有効化して「どの段階で失敗しているか」を特定することです。

理由は、詳細ログがモデルロード、GPU初期化、HTTP接続、CORSなど各フェーズの失敗点をはっきり示すからです。

実行例は次のとおりで、デバッグを有効にした状態で最小再現コマンドを流し、該当箇所のログ断片を保存します。

# macOS/Linux（シェル一時設定）
export OLLAMA_DEBUG=1
ollama serve & sleep 1
ollama run llama3.3 "テスト"

# Windows（PowerShell）
$env:OLLAMA_DEBUG=1; ollama serve

エスカレーション時は「再現手順・使用モデル名と量子化・OS/ドライバ・抜粋ログ・期待/実際の結果」を1枚にまとめると、開発チームやベンダーの一次切り分けが劇的に速くなります。

私のプロダクトマネージャー経験では、ログのタイムスタンプとコマンド履歴を併記したメモを添えるだけで、往復や誤解が大幅に減りました。

体系的に活用スキルを高めたい方は、業務適用に特化したオンライン講座も有効です。

DMM 生成AI CAMP のような実践カリキュラムで、プロンプトやトラブル対応の型を短期間で習得できます。

目的別に必要なコマンドだけを選ぶ：ローカルLLMとクラウドLLMの住み分け

当セクションでは、ローカルLLMとクラウドLLMを用途別に住み分け、仕事で即使える最小コマンドだけを選ぶ方法を解説します。

理由は、目的に対して過不足ないコマンドとモデルを選べば、学習コストと運用コストを同時に最小化できるからです。

  • 開発補助・ドキュメント要約・社内FAQ…用途別のベストプラクティス
  • ローカルOllamaとクラウドLLMの賢い併用パターン
  • 将来の拡張：API連携・VSCode・ブラウザ連携の入口としてのCLI

開発補助・ドキュメント要約・社内FAQ…用途別のベストプラクティス

最小コマンドセットを決め打ちし、目的ごとにモデルを固定すると、現場投入が最速になります。

Ollamaはrunやpull、ps、list、create、showだけで主要フローの大半をカバーできるため、操作の標準化が容易です（参考: Ollama README）。

開発補助はrunとpullとpsが基本で、推奨はQwen 2.5 Coder系などのコーディング特化モデルです。

ollama pull qwen2.5-coder
ollama run qwen2.5-coder "この関数の単体テストをpytestで生成して"
ollama ps

ドキュメント要約・ナレッジ検索はrunとpullとlistで回し、Llama 3系やMistral系が安定選択です。

ollama pull llama3.3
cat minutes.txt | ollama run llama3.3 "200字で要約して"
ollama list

社内FAQや業務フロー支援はcreateとshowでModelfileを活用し、組織固有のシステムプロンプトを焼き込むと再現性が高まります。

printf "FROM llama3.3\nSYSTEM \"あなたは社内FAQボットです。常に簡潔に回答し、最後にJSONでカテゴリを返す\"\n" > Modelfile
ollama create faq-bot -f Modelfile
ollama show faq-bot --system
社内サーバーのOllamaと外部クラウドLLMをルーターで切り分けるハイブリッド運用の概念図（ローカル優先、品質不足時のみクラウドへフォールバック）

ローカルで十分なのは短文生成や社内限定データの回答で、高難度の長文推論や超大規模モデルが必要な場合はChatGPTやClaude、あるいはOllama Cloudへ逃す方が実務的です（比較はLLMおすすめ比較を、モデルの目利きはOllamaモデル完全ガイドを参照）。

ローカルOllamaとクラウドLLMの賢い併用パターン

賢い併用は「まずローカルで試し、品質や速度に不満が出たらクラウドへ段階的に切替える」戦略です。

この順番はコストの予見性とデータ保護を担保しつつ、必要時だけ性能を買い足せるから合理的です。

実務では次の優先順位で判断すると迷いません。

  • コスト/頻度: 日常はローカル固定費、突発の大規模処理はクラウド従量課金
  • セキュリティ/規制: 機密はローカル完結、匿名化できるならクラウド活用
  • 性能/文脈長: 長文・推論・マルチモーダルはクラウドやOllama Cloudで補完

大規模モデルやレイテンシ要求が厳しい場面は、OllamaからクラウドGPUを呼べるOllama Cloudも選択肢になります（参考: Cloud – Ollama’s documentation）。

クラウドLLMの比較や料金は社内検討のたたき台としてLLMおすすめ比較が便利です。

目安として「応答が5秒超で業務に支障」や「要約の抜け・誤りが連発」したらクラウドへエスカレーションする基準をチームで決めておくと運用が安定します。

将来の拡張：API連携・VSCode・ブラウザ連携の入口としてのCLI

CLIの感覚がそのままAPIに直結するため、本セクションで覚えたコマンドは拡張時の共通言語になります。

OllamaはREST APIとOpenAI互換APIを提供し、PythonとJavaScriptの公式クライアントからも同じモデル名で呼び出せます（参考: Generate API、OpenAI compatibility）。

例えばCLIで使ったllama3.3をAPIでも次のように一行で呼べます。

curl -s http://localhost:11434/api/generate -d '{"model":"llama3.3","prompt":"要点だけ3行で"}'

このときformatやstreamを指定すればJSON固定出力やストリーミングに切替でき、LangChainやLlamaIndexでも理解しやすい挙動になります（参考: LangChain × Ollama、LlamaIndex × Ollama）。

実装全体像はOllama API徹底ガイドやRAG構築ベストプラクティスを参照すると、GUIやブラウザ連携まで一気に見通せます。

体系的にスキルを固めたい場合は現場事例に沿って学べるDMM 生成AI CAMPの活用も有効です。

まとめと次の一歩

Ollamaの全体像と基本6コマンド（run / pull / list / rm / ps / show）で、実行・管理・状態把握の型を押さえました。

さらにModelfileとcreateで専用モデル化し、エラー対処とハイブリッド運用/セキュリティの勘所まで俯瞰しました。

ローカルLLMは難しくありません。小さく始め、明日の業務で成果を出しましょう。

まずはこの記事で紹介した6つの基本コマンド（run / pull / list / rm / ps / show）を1週間業務で使ってみてください。そのうえで「もっと精度を上げたい」「社内システムと連携したい」と感じたら、Saiteki AIのクラウドLLM比較記事や、Ollama×周辺ツール連携ガイドもチェックし、自社に最適なハイブリッド構成を検討してみましょう。

体系的に学ぶなら生成AI 最速仕事術やDMM 生成AI CAMPを活用し、設計から運用まで一気通貫でスキルを伸ばしましょう。

Related Posts

Subscribe
Subscribe