【2026年最新】ollama list入門ガイド：ローカルモデルの一覧確認・詳細パラメータ表示・ストレージ整理術

/ Ollama / By

（最終更新日: 2026年09月05日）

「Ollamaでいくつかモデルを試したけれど、現在ローカルPCにどのモデルが残っているかわからない」「ストレージの容量がいつの間にか圧迫されていて整理したい」と悩んでいませんか？

オープンソースLLM（大規模言語モデル）をローカル環境で手軽に動かせるOllamaでは、コマンド1つでモデルをダウンロードできる手軽さがある反面、気がつけば数十GB〜数百GBのディスク容量を消費してしまいがちです。そこで極めて重要になるのが、ローカル環境のモデル資産を正確に把握する「ollama list」コマンドです。

本記事では、2026年最新のOllama環境におけるollama list（またはollama ls）の基本操作から、出力項目（NAME / ID / SIZE / MODIFIED）の読み解き方、ollama showやollama psとの使い分け、さらに不要モデルの安全な削除・整理ワークフローまでをわかりやすく徹底解説します。

ollama listとは？何が分かるコマンドなのかをまず整理する

ローカルLLMを複数運用していると、どのモデルがどれだけのディスク容量を消費しているか把握することが不可欠です。まずはローカルAIの資産台帳となるollama listコマンドの役割と出力各項目の読み解き方を解説します。

ollama list / ollama ls の役割：ローカルAIモデルの“資産台帳”

ollama list（短縮形: ollama ls）は、現在作業中のマシン上にダウンロードされ、オフラインでも即座に実行可能なモデルの一覧を表示する基本コマンドです。

Dockerでいうdocker imagesに相当し、ローカル環境に存在するすべてのモデルとそのメタデータを瞬時に一覧化できます。

定期的にこのコマンドを実行してモデルの状況を点検することが、ストレージの健全性と安定したAI実行環境を保つための第一歩となります。

出力形式を理解する：NAME・ID・SIZE・MODIFIEDの意味を一気に把握

ターミナルでollama listを実行すると、標準で4つの列（カラム）が出力されます。

$ ollama list
NAME                    ID              SIZE      MODIFIED
llama4:latest           a8c9b312ef40    4.9 GB    2 days ago
deepseek-r1:8b          c5f14e7a8912    4.7 GB    5 days ago
qwen2.5:7b              d3e210fa6543    4.4 GB    2 weeks ago
nomic-embed-text:latest 0a10fc072a1f    274 MB    1 month ago

それぞれの列が持つ意味は以下の通りです。

NAMEはモデル名とタグを表し、IDはモデルファイル固有の識別ハッシュ、SIZEは実ディスク消費量、MODIFIEDはローカルで最後に更新・取得された相対日時を示します。

Ollama list output format explanation highlighting NAME, ID, SIZE, and MODIFIED columns.

NAMEの読み方：モデル名＋タグ（サイズ／用途）で用途と負荷をざっくり判断

NAME列は<モデル名>:<タグ>の形式で構成されており、コロン以降のタグによってパラメータ規模や量子化タイプが判別できます。

タグが省略された場合はデフォルトのlatestが適用されますが、:8b-instruct-q4_K_Mのように詳細な量子化形式が指定されるケースもあります。

タグを確認することで、手元のマシンスペック（VRAM容量）に適したモデルが導入されているかをひと目で判断できるようになります。

SIZEとMODIFIEDの読み方：ディスク容量と“古さ”を確認する指標

SIZE列は、そのモデルがローカルドライブ上で実際に占有しているファイルサイズをギガバイト（GB）やメガバイト（MB）単位で示します。

MODIFIED列はモデルがダウンロードまたは再ビルドされた日時を示しており、「数ヶ月間使っていない放置モデル」を特定する絶好の手がかりとなります。

肥大化したストレージを整理する際は、「SIZEが大きく、MODIFIEDが古いモデル」から優先的にチェックするのが鉄則です。

【基本操作】ollama listの実行からモデル詳細確認までの一連の流れ

単にモデルを一覧表示するだけでなく、各モデルの内部パラメータや実行中のメモリ展開状態まで正確に把握することで、開発や業務でのAI活用が劇的にスムーズになります。本章ではlistからshow、ps、runへと連携する実践ワークフローを解説します。

まずは実行してみる：Windows / Mac / Linux 共通の基本コマンド

Ollamaはクロスプラットフォームで設計されており、PowerShell、macOSのターミナル、LinuxのBashいずれでも同一のコマンドで動作します。

ollama listまたはollama lsを入力してEnterを押すだけで、ローカルキャッシュ内のモデルが瞬時にテーブル形式で描画されます。

サーバー起動中であれば数ミリ秒で応答が返るため、日々のモデル管理ルーティンとして手軽に実行できます。

Step-by-step workflow from ollama list to model inspection, execution, and cleanup.

モデルの詳細を確認する：ollama showでライセンスや量子化情報を見る

ollama listでモデルの存在を確認した後は、ollama show <モデル名>を使ってより詳細なメタデータを調査できます。

$ ollama show deepseek-r1:8b
  Model
    architecture        qwen2
    parameters          8.2B
    context length      131072
    embedding length    3584
    quantization        Q4_K_M

  Parameters
    stop    "<|im_start|>"
    stop    "<|im_end|>"

  License
    MIT License

コンテキスト長（context length）や量子化レベル（quantization）、ライセンス情報などを確認できるため、開発プロジェクトの要件に合致しているかを厳密に検証できます。

実行中モデルの確認：ollama psでVRAMメモリ展開状況を把握する

「保存されているモデル」と「現在メモリ（VRAM/RAM）にロードされているモデル」は異なります。現在アクティブなモデルを調べるにはollama psを使用します。

$ ollama ps
NAME              ID              SIZE      PROCESSOR    UNTIL
deepseek-r1:8b    c5f14e7a8912    5.2 GB    100% GPU     4 minutes from now

どのモデルがGPUメモリを占有しているか、自動アンロードまでの残り時間が何分かが表示されるため、メモリ枯渇によるクラッシュを未然に防止できます。

Ollama model ledger sheet comparing stored models on disk vs active loaded models in memory.

実行とテスト：ollama runで“本当に使える状態か”をその場で確認

モデルが正しく動作するか確認したい場合は、ollama run <モデル名>を実行します。

すでにローカルにダウンロードされているため再取得の待機時間は発生せず、即座に対話プロンプトが起動します。

簡単な指示を与えてレスポンス速度と日本語の出力精度をテストし、日常使いに適したモデルかを検証しましょう。

【整理術】ollama listで“いらないモデル”を見分けて安全に削除する

数百GBに達するローカルモデルを無計画に放置すると、PC全体のストレージを圧迫し動作不良の原因となります。本章では、使わなくなったモデルを安全に見極め、プロジェクトへの影響を避けてクリーンアップする手順を解説します。

削除候補の探し方：SIZEが大きい・MODIFIEDが古いものからチェック

ディスクを整理する際は、ollama listの出力結果から以下の条件に当てはまるモデルを抽出します。

1つ目は「検証目的で一度だけ試した巨大モデル（14B〜70Bクラスで10GB以上消費）」、2つ目は「MODIFIEDが数ヶ月以上前で後継バージョンが既にリリースされている旧世代モデル」です。

これらをリストアップすることで、数分間の作業で数十ギガバイト以上のディスク空き容量を奪還できます。

Criteria matrix for selecting Ollama models to delete based on size, age, and usage frequency.

安全な削除手順：ollama rmコマンドと実行前チェックリスト

削除するモデルが決定したら、ollama rm <モデル名>を実行します。

$ ollama rm llama3:8b
deleted 'llama3:8b'

削除コマンドには確認プロンプトが出ないため、実行前に「本当に削除してよいモデル名か」「外部スクリプトやDify等の連携ツールで参照されていないか」を必ず再確認しましょう。

Pre-deletion checklist covering API dependencies, active sessions, and custom Modelfiles.

複数バージョン重複時の整理方針：最新タグと固定タグの使い分け

同じモデルファミリーで複数のタグ（例: latest、q4_K_M、q8_0）を並行して保持していると、ディスク容量を二重に消費します。

日常の検証用にはデフォルトのlatestを残し、開発や再現性重視のタスクには特定の量子化タグを残すといった明確なルールを設けましょう。

重複した中間検証モデルをこまめに間引くことで、無駄なディスク消費を徹底的に排除できます。

プロジェクト依存関係とModelfileバックアップの考え方

自作のシステムプロンプトやパラメータを組み込んだカスタムモデル（Modelfileから作成したモデル）を削除する際は、元となるModelfileのテキストファイルを必ずGit等で保管しておきます。

Modelfileさえ残っていれば、後からollama create <名前> -f Modelfileでいつでも同一構成を再構築可能です。

大元のバイナリは削除してディスクを空けつつ、設定資産だけを軽量にバックアップする運用が最もスマートです。

【モデル構成のベストプラクティス】用途別に「残すモデル」を決める

すべてのモデルを最新・最大サイズで保持する必要はありません。日常的なチャット用、高度な推論用、コード補完用など、役割ごとに最適なモデルを選別して常備することが推奨されます。本章では2026年最新のモデルポートフォリオ戦略を提示します。

2026年のローカルAI環境では、モデルごとの得意領域がより明確化しています。

汎用的なタスクと長文コンテキストにはLlama 4、数学・論理的推論やコード生成にはDeepSeek-R1、高精度な日本語処理にはQwen 2.5、軽量・高速応答にはGemmaが選ばれています。

用途に応じた代表モデルを各1つずつ揃えることで、ローカル環境の対応力を最大化できます。

軽量モデルと高性能モデルの2段構え（Two-Tier）戦略

実務で推奨されるのが、常時高速に動かせる「日常用軽量モデル（3B〜8B）」と、時間をかけて高度な思考を行わせる「高精度推論モデル（14B〜32B以上）」の2段構え運用です。

Two-tier local AI model strategy: Lightweight fast responder vs deep reasoning powerhouse.

簡単な要約や翻訳は軽量モデルで瞬時に処理し、アーキテクチャ設計や難解なデバッグ時のみ推論モデルを呼び出します。

この棲み分けを行うことで、マシンスペックを浪費せず快適なレスポンスを維持できます。

Structured model catalog template categorizing models by role, parameters, and VRAM requirements.

PCスペック（VRAM/ディスク容量）に合わせた保持モデルの目安

ハードウェアスペックに応じた推奨モデルサイズとディスク容量の目安は以下の通りです。

搭載メモリ/VRAM 推奨モデルサイズ 代表モデル例 目安消費容量
8GB 〜 16GB 3B 〜 8Bクラス qwen2.5:7b, gemma2:9b 10GB 〜 20GB
16GB 〜 32GB 8B 〜 14Bクラス deepseek-r1:8b, qwen2.5:14b 25GB 〜 50GB
32GB 〜 64GB+ 32B 〜 70Bクラス deepseek-r1:32b, llama4 60GB 〜 150GB+
Hardware specification mapping to model size tiers and VRAM consumption thresholds.

EmbeddingやVisionなど“見えにくい必須モデル”の管理術

チャット用モデルだけでなく、RAG（検索拡張生成）システムで使用するEmbeddingモデル（例: nomic-embed-text）や画像認識用のVisionモデル（例: llava、minicpm-v）もollama listに表示されます。

これらのモデルはサイズが数百MB〜数GBと控えめですが、外部アプリケーションと強く紐づいていることが多いため、誤って削除しないよう注意が必要です。

モデル一覧を定期確認し、プロジェクトで継続利用している補助モデルを保護リストとして把握しておきましょう。

大規模モデル運用の応用テクニック：保存先ドライブ変更とセキュリティ

CドライブのSSD容量が足りない場合や、ローカルモデルをWebUIやチーム内で共有する場合には、追加の設定が必要です。本章では保存先ドライブの移行手順と、外部アクセスをセキュアに保つための設定ポイントを解説します。

OLLAMA_MODELS環境変数でSSD/外付けドライブへ保存先を移行する手順

デフォルトでは、OllamaはOSのメインドライブ（WindowsならC:\Users\<ユーザー>\.ollama\models、Mac/Linuxなら~/.ollama/models）にモデルを保存します。

保存先を高速な外付けNVMe SSDや大容量Dドライブに変更するには、環境変数OLLAMA_MODELSを設定します。

Windows環境ではシステム環境変数にOLLAMA_MODELS=D:\ollama_modelsを追加し、Linux/macOS環境ではexport OLLAMA_MODELS="/Volumes/FastSSD/ollama_models"をシェル設定に追加してOllamaサービスを再起動します。

移行後にollama listを実行し、移行先ドライブでモデル一覧が正常に読み込まれることを確認しましょう。

モデルのライフサイクル管理：定期的なアップデートとキャッシュ整理

モデル提供元が重みやプロンプトテンプレートを修正した場合、ollama pull <モデル名>を再実行することで最新版に上書き更新されます。

Ollama model lifecycle flow: pull, list inspection, run evaluation, and prune or remove.

アップデートによって古いハッシュのファイルが残骸として蓄積するのを防ぐため、定期的にモデルの再取得と不要版のollama rmを行い、ディスク容量の最適化を維持しましょう。

Hybrid architecture diagram illustrating local Ollama instances connected to cloud APIs and external storage.

LAN内公開・API連携時のポート11434セキュリティ設定

Ollamaはデフォルトで127.0.0.1:11434にバインドされ、ローカルマシン内からのアクセスのみを許可しています。

同一ネットワーク内の別PCやタブレットからWebUI経由でアクセスさせる場合は、環境変数OLLAMA_HOST=0.0.0.0を設定します。

ただし、未認証のままLAN全体や外部インターネットに開放すると、第三者によって無制限にモデルを実行されマシンリソースを占有される危険があります。

外部公開を行う際は、リバースプロキシ（NginxやCaddy）によるベーシック認証やファイアウォールによるアクセス制限を必ず併用してください。

Network security architecture diagram for Ollama API port 11434 with firewall and authentication proxy.

まとめ

Ollamaのモデル一覧を確認するollama listは、限られたローカルマシンのリソースを最大限に活用し、快適なAI実行環境を維持するために欠かせない司令塔コマンドです。

出力項目の意味を正しく把握し、ollama showでの詳細確認やollama psでのメモリ監視、そしてollama rmによる計画的なクリーンアップを組み合わせることで、ストレージの枯渇を防ぎながら最新モデルの性能をフルに引き出すことができます。

まずはターミナルを開いてollama listを実行し、現在のPCに眠っているモデル資産を今すぐ棚卸ししてみましょう！

【成果持ち帰り型3週間】

研修だけで終わらせない！「自社専用AI」定着パッケージ

「社員がAIを使えない」「自社商材に合わない」を解決。講師がその場で実務用にカスタマイズ。月額10万円〜。

詳細はこちら →

自社に最適なローカルAI環境を構築し、セキュアで高効率な業務DXを実現していきましょう。

Related Posts

Subscribe
Subscribe