（最終更新日: 2025年12月29日）
気づけばOllamaのモデルが増えすぎて、何がどれか分からない。容量も心配——そんなモヤモヤ、ありませんか？
本稿は“台帳”となるollama listに絞り、今あるモデルを一目で把握し、ムダを見つけ、安全に片づける力を身につけます。
ターミナルに不慣れでも大丈夫。手順どおりに進めれば、事故なくスッキリ整理できます。
基本の実行から詳細確認、要らないモデルの見極めと削除、用途別の残し方、日々の管理ルーチン、容量と速度のバランスまで網羅。
現場運用の知見を凝縮し、限られたマシン資源で“使える”ローカルAI環境を保つ現実的なワークフローを一緒に作りましょう。
ollama listとは？何が分かるコマンドなのかをまず整理する
当セクションでは、Ollamaの基本コマンドである「ollama list（ollama ls）」が何を示し、どのように読み解くべきかを体系的に説明します。
なぜなら、ローカルに蓄積されるAIモデルは“資産”であり、一覧の正しい理解が整理・更新・削除といった実務判断の出発点になるからです。
- ollama list / ollama ls の役割：ローカルAIモデルの“資産台帳”
- 出力形式を理解する：NAME・ID・SIZE・MODIFIEDの意味を一気に把握
- NAMEの読み方：モデル名＋タグ（サイズ／用途）で用途と負荷をざっくり判断
- SIZEとMODIFIEDの読み方：ディスク容量と“古さ”を確認する指標
ollama list / ollama ls の役割：ローカルAIモデルの“資産台帳”
結論として、ollama list は「ローカルで今すぐ使えるモデルの資産台帳」を表示するコマンドです。
理由は、単なるファイルの羅列ではなく、モデルの識別子やサイズ、更新日時などガバナンスに必要なメタデータを横断的に提示するからです。
具体例として、Dockerの「docker images」に近い感覚で捉えると理解が進みますし、CLIの正式名称は「ollama list（短縮形 ollama ls）」で、Ollama公式のCLIリファレンスにも一覧表示の仕様が明記されています（参考: CLI Reference – Ollama）。
再度の要点は、資産台帳として把握できるからこそ、組織はセキュリティ監査・容量計画・バージョン統制を一貫して運用できるということです。
出力形式を理解する：NAME・ID・SIZE・MODIFIEDの意味を一気に把握
まず押さえるべき結論は、4列（NAME／ID／SIZE／MODIFIED）を読めば、モデルの正体・完全性・容量負荷・新しさが一望できるという点です。
理由は、NAMEが「どのモデルか」、IDが「バイナリの一意性」、SIZEが「ストレージ圧迫度」、MODIFIEDが「更新の鮮度」をそれぞれ示すためです。
たとえば以下の実行結果では、どのモデルを残し、どれを棚卸しするかを視覚的に判断できます。
$ ollama list
NAME ID SIZE MODIFIED
llama3.2:3b 9876abcd 1.4 GB 2025-12-20 10:31:22
deepseek-r1:7b a1b2c3d4 4.2 GB 2025-12-18 08:05:10
gemma3:4b 55aa7788 2.6 GB 2025-12-10 21:12:44
図解では、容量判断の起点となるSIZE列を強調して確認すると実務で迷いにくくなります。
まとめると、4列の意味をセットで理解することが、後段の「モデル削除」や「更新判断」を素早く行う最短ルートです（参考: CLI Reference – Ollama）。
NAMEの読み方：モデル名＋タグ（サイズ／用途）で用途と負荷をざっくり判断
結論は、NAMEは「モデル名:タグ」で構成され、タグが“規模や用途”を示すため、用途適合と負荷の目安を即座に掴めます。
理由として、タグには7bや70bのようなパラメータ規模や、instruct・coderといった用途指向が含まれることが多いからです。
具体例は次の一覧が分かりやすく、手元のインベントリを読むときの早見表として使えます（出典: Ollama Model Library）。
| 例のNAME | タグの意味 | 性格／用途の目安 |
|---|---|---|
| llama3.2:3b | 約3B規模 | 軽量で対話・要約の下支えに適する |
| llama3.3:70b | 約70B規模 | 高品質な汎用対話に強く、リソース要件は高め |
| deepseek-r1:7b | 約7B＋推論強化 | 論理推論やコード解析に強み |
| qwen2.5-coder:7b | コーディング特化 | 多言語コード補完・修正に向く |
| gemma3:4b | 約4B規模 | 軽快でバックエンド組み込みに好適 |
さらに深掘りした全体像やモデル選びは、整理済みのガイドも参照すると最短です（関連: 【2025年版】Ollamaのモデル完全ガイド、LLMベンチマーク完全ガイド、DeepSeek R1の性能徹底分析）。
SIZEとMODIFIEDの読み方：ディスク容量と“古さ”を確認する指標
結論として、SIZEは容量圧迫度、MODIFIEDは更新鮮度の指標であり、削除候補の洗い出しと更新優先度の判断に直結します。
理由は、ローカル運用ではSSDやNASの残容量がボトルネックになりやすく、また古いモデルの放置は品質やセキュリティの観点でリスクになるからです。
具体例として、軽量モデルは700MB〜数GB程度に収まる一方、上位モデルは量子化しても数十GB規模になることがあり、運用開始前に容量計画が必要です。
MODIFIEDが数カ月前のままなら、改めてpullして更新有無を確認する運用ルールを設けると、インシデント予防と性能維持に役立ちます。
要するに、SIZEで「重い」を見抜き、MODIFIEDで「古い」を見抜くことが、健全なモデル資産管理の基本動作です（参考: CLI Reference – Ollama）。
コマンドの相互関係や一連の実務フローは、ハンズオン形式のまとめも合わせて確認すると効率的です（関連: 【2025年版】Ollamaコマンド完全ガイド）。
【基本操作】ollama listの実行からモデル詳細確認までの一連の流れ
当セクションでは、ollama listの実行から、出力で分かること、ollama showでの詳細確認、ollama runによる動作テストまでの基本フローを解説します。
この流れを押さえると、ローカルにあるモデル資産を正しく把握し、商用利用の可否や品質を短時間で確認できるようになるためです。
- まずは実行してみる：Windows / Mac / Linux 共通の基本コマンド
- よくある疑問1：ollama listではどんな情報が確認できますか？
- モデルの詳細を確認する：ollama showでライセンスや量子化情報を見る
- 実行とテスト：ollama runで“本当に使える状態か”をその場で確認
まずは実行してみる：Windows / Mac / Linux 共通の基本コマンド
結論はシンプルで、最初の一歩はターミナルで「ollama list」を実行することです。
このコマンドはローカルのOllamaサーバー（デフォルトでポート11434）に問い合わせ、すぐ使えるモデルの一覧を返すためです。
WindowsはPowerShellやWindows Terminal、macOSやLinuxはターミナルを開き、次のいずれかを実行します。
# 実行
ollama list
# 省略形
ollama lsもし「connect ECONNREFUSED」などの接続エラーが出たら、サーバープロセスの起動状況を確認します。
# サーバー稼働確認（共通）
curl http://localhost:11434/api/version
# Linux（systemd）
sudo systemctl status ollama
# Windows（PowerShell）
Get-Service Ollama
# macOS（前景起動の例。終了はCtrl+C）
ollama serve「command not found」と表示される場合はOllama自体が未導入なので、手順に従ってインストールしてください（参考: 【2025年版】Ollamaインストール完全ガイド）。
ここまで問題なく出力できれば、次のセクションで一覧の読み方を押さえましょう。
よくある疑問1：ollama listではどんな情報が確認できますか？
結論として、ollama listで見えるのは「ローカルに完全ダウンロード済みで、即使用可能なモデルのみ」です。
これはクラウド上のカタログではなく、あなたの環境にある“実体”のインベントリを返すからです。
出力にはNAME・ID・SIZE・MODIFIEDが並び、NAMEは「モデル名:タグ」、IDはモデルのハッシュ、SIZEはディスク占有、MODIFIEDは最終更新日時を意味します。
| カラム | 意味 | 例 |
|---|---|---|
| NAME | モデル識別子（名前:タグ） | llama3.2:3b |
| ID | モデルの一意ハッシュ | 2f1a8c… |
| SIZE | ディスク上の容量 | 2.1 GB |
| MODIFIED | 最終更新日時 | 2 days ago |
たとえば次のように表示されます。
NAME ID SIZE MODIFIED
llama3.2:3b 2f1a8c… 2.1 GB 2 days agoしたがって、この一覧は「今すぐ走らせられる資産の台帳」であり、詳細仕様は次のセクションで確認します（参考: CLI Reference）。
モデルの詳細を確認する：ollama showでライセンスや量子化情報を見る
結論として、商用利用や運用要件の判断は「ollama show <model>」でライセンスや量子化方式、コンテキスト長を確認してから行うのが安全です。
理由は、ollama listでは型番やサイズは分かっても、Licenseやパラメータの詳細、Modelfileの設定までは分からないためです。
代表的な使い方は次のとおりです。
# 主要情報（License/Parameters/Quantization/Contextなど）
ollama show llama3.2:3b
# Modelfile全文（ベースモデルやSYSTEM指示の確認）
ollama show llama3.2:3b --modelfile筆者は業務利用検討のたびにまずshowでLicenseを確認し、社内規定に合致しないものは検証対象から外す運用にしています。
特に再配布や商用可否、クレジット表記の要件はモデルごとに異なるため、導入前に読み飛ばさないことが重要です。
この一手間でコンプライアンスリスクを回避できるため、意思決定の前に必ず確認しましょう（参考: CLI Reference）。
実行とテスト：ollama runで“本当に使える状態か”をその場で確認
結論は、「一覧に出ている名前をそのままollama runに渡せば、その場で対話テストできる」です。
理由は、NAMEに表示される識別子が、そのまま実行可能な呼び出し名（model:tag）になっているためです。
たとえば軽量モデルを日本語で試す場合は次のとおりです。
ollama run llama3.2:3b
# 例：日本語で簡単に質問
> 日本語で自己紹介を30文字以内で。
こんにちは、軽量で速いLlama 3.2です。まずは短い日本語プロンプトを投げ、応答速度やトーンを体感し、必要なら別モデルでも同じ質問で比較します。
オプションや他コマンドとの組み合わせは解説記事にまとめているので、併せて参照すると効率的です（参考: 【2025年版】Ollamaコマンド完全ガイド）。
【整理術】ollama listで“いらないモデル”を見分けて安全に削除する
当セクションでは、ollama listで“いらないモデル”を見分け、安全に削除するための実践手順と判断基準を解説します。
理由は、ローカルLLMは数GB〜数百GBの容量を消費しやすく、無計画な削除は環境破壊への不安を招く一方、正しい手順なら短時間で復元できるからです。
- よくある疑問2：不要なOllamaモデルを安全に削除する手順は？
- 削除候補の探し方：SIZEが大きい・MODIFIEDが古いものからチェック
- よくある疑問3：複数バージョンがあるとき、どれを残せばいい？
- 削除前の最終確認：プロジェクト依存関係とバックアップの考え方
よくある疑問2：不要なOllamaモデルを安全に削除する手順は？
結論は、実行中のモデルがないことを確認してから「ollama rm <model>」を実行し、必要になったら「ollama pull <model>」で復元するのが安全策です。
理由は、rmはローカルのモデルファイルを消すだけで、同じ名前のモデルは後から再取得できるため取り返しがつかない操作ではないからです（参考: CLI Reference）。
手順は次のとおりです。
# 1) 実行中のモデルを確認
ollama ps
# 2) 使っていないモデルを削除
ollama rm llama3.2:3b
# 3) 復元が必要になったら再取得
ollama pull llama3.2:3b私は過去にVision用途の大きなモデルを一度削除し、後日必要になった際にpullし直して10分ほどで復旧できたため、安心して整理を続けられました。
なお、削除前に対話セッションや連携アプリを終了しておくと安全で、rmの仕様は公式ドキュメントでいつでも確認できます（参考: CLI Reference）。
削除候補の探し方：SIZEが大きい・MODIFIEDが古いものからチェック
結論は、まず「SIZEが極端に大きいモデル」と「MODIFIEDが古く最近触っていないモデル」から削除候補にすることです。
理由は、これらを優先するとディスクを一気に空けやすく、かつ使用頻度が低いものを的確に選べるからです。
下図のように、ollama listのSIZEとMODIFIEDを見比べると候補がすぐ浮かび上がります。
以下の簡易ルールを目安にすると迷いません。
| ストレージ残容量 | 削除優先 | 簡易ルール例 |
|---|---|---|
| 20%未満 | 70B級など特大モデル | SIZE >= 15GBやMODIFIEDが90日以上前を優先 |
| 20〜40% | 中型モデル＋古い世代 | SIZE 5〜15GBでMODIFIEDが60日以上前 |
| 40%以上 | 重複バージョンの整理 | 用途が重なる中間サイズを間引き |
# 一覧を表示
ollama list- SIZEが5GB以上の中大型モデルから検討する。
- MODIFIEDが60〜90日以上前のエントリを候補にする。
- 似た用途の重複バージョンがある場合は一方に絞る。
判断に迷うときは一覧を開きながら用途をメモし、重複や休眠モデルを落としていくと効率的です（参考記事: Ollamaコマンド完全ガイド）。
よくある疑問3：複数バージョンがあるとき、どれを残せばいい？
結論は「軽量＋高性能の2本立てを残し、中間サイズは用途が被るなら削除」し、「世代は新しいものを優先」することです。
理由は、2本立てにすると日常の軽快さと勝負所の性能を両立でき、保守・容量計画もシンプルになるからです。
具体例としては、軽量は llama3.2:3b や gemma3:4b、高性能は llama3.3:70b を残し、用途が被る中位モデルを間引くと運用が安定します。
世代は Llama 3.3 > 3.1 > 2 の順で新しいものを優先し、Gemma 3やDeepSeek-R1など2025年時点の代表格も最新ビルドを基本とします。
モデル選定の背景や特徴は一覧で俯瞰できるので、必要に応じて整理方針を見直してください（参考記事: Ollamaのモデル完全ガイド）。
削除前の最終確認：プロジェクト依存関係とバックアップの考え方
結論は、rmの前に「依存の洗い出し」と「最低限のバックアップ」を行えば、動作不良と復旧遅延を防げます。
理由は、スクリプトや外部ツールにモデル名がハードコードされていると削除後に連鎖的なエラーが起きるためです。
具体的には、リポジトリ全体を検索しモデル名の参照有無を確認し、重要モデルはshowの情報をファイルに吐き出しておくと復元が早くなります。
# 依存の有無を検索（例）
grep -R "llama3.2:3b" ./
# 重要モデルのメタ情報を保存
date +%F > model_inventory.txt
ollama show llama3.3:70b >> model_inventory.txt私はVSCode連携スクリプトでモデル名を固定していたことに気づかず、削除後に補完が動かなくなり、検索で参照箇所を直して解消した経験があります。
このひと手間で事故をほぼ防げるので、毎回のチェックを運用ルールに組み込みましょう（参考: CLI Reference）。
【モデル構成のベストプラクティス】用途別に「残すモデル」を決める
当セクションでは、用途別に残すべきローカルLLMの選び方と、ollama listを見やすく保つ整理術を解説します。
理由は、モデルを闇雲に増やすとディスクと意思決定コストが膨らみ、運用速度と品質が同時に低下するからです。
- よくある疑問4：初心者が最低限入れておくべきおすすめモデルは？
- 用途ごとのモデル整理方針：軽量モデルと高性能モデルをどう使い分けるか
- よくある疑問5：自分のPCのディスク容量や用途に合わせた残し方の目安
- EmbeddingやVisionなど“見えにくい必須モデル”の扱い
よくある疑問4：初心者が最低限入れておくべきおすすめモデルは？
まずは「汎用チャット」「軽量チャット」「コーディング支援」「Embedding」の4本だけを揃えれば十分です。
業務の大半はこの4用途に収まり、過不足の少ないスターター構成で学習と検証のスピードが上がります。
以下の表を参考に、同系統で重複を作らないことを意識して選んでください。
| 用途 | 推奨モデル | 目安サイズ（ディスク） |
|---|---|---|
| 汎用チャット | llama3.3:70b（Q4系） | 40〜50GB前後 |
| 軽量チャット | llama3.2:3b または gemma3:4b | 2〜4GB前後 |
| コーディング支援 | deepseek-r1:7b または qwen2.5-coder:7b | 4〜8GB前後 |
| RAG用Embedding | nomic-embed-text | 0.6〜1.0GB前後 |
セットアップは次のコマンドで最小構成を揃えられます。
ollama pull llama3.3:70b
ollama pull llama3.2:3b # または: ollama pull gemma3:4b
ollama pull deepseek-r1:7b # または: ollama pull qwen2.5-coder:7b
ollama pull nomic-embed-textこの4本がollama listに並んだ状態が“理想のスターター環境”で、細部の比較は「モデルの選び方」を解説した内部記事も参照してください（参考: Ollama Model Library、関連記事: 【2025年版】Ollamaのモデル完全ガイド）。
用途ごとのモデル整理方針：軽量モデルと高性能モデルをどう使い分けるか
同一用途で「軽量（速い・安い）」と「高性能（正確・安心）」の2段構えに限定すると、実務は圧倒的に回しやすくなります。
使い分け基準が明確だと毎回のモデル選択に迷わず、ollama listも短く保てます。
著者の現場運用例は「平日は軽量モデル中心、レビューや社内ドキュメント生成のときだけ高性能モデルに切り替え」です。
コマンドはエイリアス名で統一しておくと切り替えが簡単です。
# 例：日常
ollama run chat-light # 実体: llama3.2:3b など
# 例：重要作業
ollama run chat-pro # 実体: llama3.3:70b など基本操作の復習やショートカットは解説記事がまとまっています（関連記事: 【2025年版】Ollamaコマンド完全ガイド）。
体系的に学びたい場合はオンライン講座の活用も手です（参考: DMM 生成AI CAMP）。
よくある疑問5：自分のPCのディスク容量や用途に合わせた残し方の目安
残す本数は「空きストレージ」「VRAM」「RAM」の3点から逆算して決めるのが安全です。
巨大モデルはVRAMに収まり切らないと極端に遅くなるため、スペックに見合うサイズへ絞るだけで体感性能が大きく改善します。
次の目安表を超えない範囲で構成し、迷ったら軽量モデル優先で構いません。
| 条件 | 現実的な構成目安 |
|---|---|
| 空きストレージ < 100GB | 70B級は最大1本に絞るか見送り、軽量×2〜3本＋Embeddingに限定 |
| 空きストレージ 100〜200GB | 70B×1本＋軽量×2本＋Embeddingで合計120GB以内を目標 |
| VRAM 8〜16GB | 3B〜14BのQ4を中心に運用 |
| VRAM 24〜32GB | 27B〜32B級までが現実的 |
| VRAM 48〜64GB | 70B級も実用域 |
サイズは定期的に確認し、膨らんだら整理します。
ollama list
# 不要なら
ollama rm <model>大きいモデルをプルする前にハードウェア要件を必ず確認し、余力の範囲で増やす運用を徹底しましょう（参考: Ollama GitHub Repository、Ollama Releases）。
EmbeddingやVisionなど“見えにくい必須モデル”の扱い
対話に直接使わないEmbeddingやVisionモデルは、RAGやOCR系ワークフローの“裏方”なので安易に削除しないでください。
例えば社内検索の精度はEmbeddingに依存し、領収書処理の自動化はVision対応モデルを前提に組んでいることが多いです。
用途が曖昧にならないよう「社内用モデルカタログ」を用意し、モデル名・用途・依存システム・ライセンスを1枚で見える化します。
| モデル名 | 用途 | 依存システム | ライセンス |
|---|---|---|---|
| nomic-embed-text | RAG検索 | ナレッジBot | Apache-2.0 |
| llama3.2-vision:11b | OCR補助 | 経理精算 | 要確認 |
RAGの基礎やEmbedding選定は内部記事がまとまっています（関連記事: 【2025年版】Ollama Embeddings徹底ガイド、RAG構築のベストプラクティス）。
整理の最後に依存を再確認してから削除コマンドを実行する癖を付ければ、業務停止のリスクを最小化できます（参考: Tools models · Ollama Search）。
【運用ワークフロー】ollama listを起点にしたモデル管理ルーチンを設計する
当セクションでは、ollama listを起点に「点検・記録・運用・廃棄」までを一気通貫で回すモデル管理ルーチンの作り方を解説します。
なぜなら、ローカルAIは導入が容易な反面、モデルの肥大化やバージョン混在が起きやすく、一覧と台帳がないと運用コストが急増するからです。
- 毎月15分の“棚卸しタイム”を作る：定期的なlistでの点検
- 台帳ドキュメントの作り方：listの結果をNotionやスプレッドシートに転記
- モデルライフサイクル：pull → list → show/run → rm の一連の流れを標準化
- Modelfileで社内専用モデルを作り、listで識別しやすくする
毎月15分の“棚卸しタイム”を作る：定期的なlistでの点検
結論として、月1回の15分で「ollama list」を眺める棚卸しタイムを設けるだけで、容量枯渇やモデル混在の大半を未然に防げます。
理由は、NAME/ID/SIZE/MODIFIEDという最小限の指標だけで古さ・重さ・重複を即時に判別でき、意思決定が一気に進むからです。
具体例として、私は以下の2コマンドを起点に棚卸しを始めます。
ollama list
# 不要判定後に削除
ollama rm <model-name-or-tag>私の棚卸しTODOは次の通りです。
- 合計SIZEとサーバー残容量の差分確認（閾値80％超で削減計画）
- MODIFIEDが前回点検から90日超の旧モデルをリスト化
- プロジェクト終了済みの専用モデルを候補抽出（台帳と突合）
- ID不一致（想定と違うビルド）を検出し、再取得か隔離
- 命名規約から外れた名前を修正キューへ
- ライセンスの商用可否が未確認のものをレビュー行き
稼働中の重いモデルは削除対象から除外するため、並行してollama psも確認します（参考: CLI Reference）。
この短い習慣を月例の会議前に固定すると、現場の運用負荷が下がり意思決定も速くなります。
より詳しいコマンドの使い分けは「【2025年版】Ollamaコマンド完全ガイド」も参照してください。
台帳ドキュメントの作り方：listの結果をNotionやスプレッドシートに転記
結論は、ollama listのテキストをNotionやGoogleスプレッドシートに貼る“モデル台帳”を作り、全員で共有することです。
理由は、誰が・どのプロジェクトで・どのモデルを使っているかを可視化でき、削除や更新判断が属人化しないからです。
実務では、毎月の棚卸し後にテキストを保存してから台帳へ貼り付けます。
# 点検日のスナップショットを保存
ollama list > models_2025-08.txt台帳の項目例は次の通りです。
- モデル名（NAME）
- タグ（例: 7b/70b/instruct など）
- 用途（chat/code/rag-qa 等）
- プロジェクト名／環境（dev/stg/prod）
- オーナー（担当者・連絡先）
- ライセンス要件（商用可・注意点）
- サイズ（SIZE）／ID（短縮）
- 最終確認日（MODIFIED転記）
- 配置先（ホスト名・GPU）
- 備考（性能所感・注意事項）
ライセンスや仕様の細部はollama showで確認し、台帳へ根拠を記載します（参考: CLI Reference）。
モデルの種類やタグの意味は「【2025年版】Ollamaのモデル完全ガイド」を併読すると設計がぶれません。
チームでの共通理解を早めるために、以下のような列構成のテンプレ画像を共有ドキュメントに埋め込むのもおすすめです。
運用ガイドラインの社内研修を短期で整えるなら、体系的に学べるオンライン講座の活用も有効です（例: DMM 生成AI CAMP）。
モデルライフサイクル：pull → list → show/run → rm の一連の流れを標準化
結論は、モデルの導入から廃棄までを「pull → list → show/run →台帳更新→ rm」という標準手順に固定し、誰がやっても同じ結果になるようにすることです。
理由は、評価抜けやライセンス未確認のまま本番投入される事故をプロセスで防げ、監査対応も一貫するからです。
具体的な標準コマンドは次の通りです。
# 1. 取得
ollama pull llama3.3:70b
# 2. 追加を確認
ollama list
# 3. 詳細の検査と簡易動作確認
ollama show llama3.3:70b
ollama run llama3.3:70b
# 4. 使途決定を台帳へ反映（手作業/自動化）
# 5. 不要になったら削除
ollama rm old-model:7b受け入れ基準は「品質所感・得意/不得意・推奨用途・ライセンス可否・リソース要件」を台帳に必ず残すこととし、例外運用をなくします。
この流れは視覚化すると定着が速いので、下図のフローチャートをチーム手順書に貼り付けてください。
各コマンドの仕様とオプションは公式を参照してください（参考: CLI Reference、参考: APIドキュメント）。
Modelfileで社内専用モデルを作り、listで識別しやすくする
結論は、Modelfileで作る社内モデルに「company-用途-サイズ-量子化」の命名規約を与え、ollama list上で即識別できるようにすることです。
理由は、共有環境で誰が見ても社内資産と分かり誤削除を防げるほか、台帳突合や検索性が大幅に上がるからです。
例として以下のModelfileと作成コマンドを用います。
# Modelfile（一例）
FROM llama3.3:70b
SYSTEM """
あなたは社内QAアシスタントです。
回答は箇条書き中心、ソースが不明な場合は要確認と記載。
"""
PARAMETER temperature 0.2
# 社内命名規約：mycorp-qa-70b-q4
ollama create mycorp-qa-70b-q4 -f Modelfileコロンはタグの区切りに使われるため、社内命名はハイフンで統一するとlist時の視認性が上がります。
命名規約は手順書と台帳に明文化し、「ollama create徹底解説」「Ollamaコマンド完全ガイド」とセットで周知します。
Modelfileとcreateの正式な仕様は公式を確認してください（参考: CLI Reference）。
【応用編】ディスク容量とパフォーマンスを意識したローカルLLM運用
当セクションでは、ディスク容量とパフォーマンスを意識したローカルLLM運用の実務ポイントを解説します。
なぜなら、モデルは数十〜数百GBの重い資産であり、ハードウェア条件と運用設計を誤ると速度低下やストレージ逼迫が起きるためです。
- ハードウェアとモデルサイズの関係：大きいモデルほどlistに“重い資産”として並ぶ
- 容量が厳しいときの現実解：大モデルはクラウド（Ollama Cloud等）に逃がす選択肢
- セキュリティ視点：listに載るモデル＝社内データ処理の“責任範囲”
- トラブルシューティング：listに期待したモデルが出ない／削除できないとき
ハードウェアとモデルサイズの関係：大きいモデルほどlistに“重い資産”として並ぶ
結論は、ollama list のSIZE列と手元マシンのVRAM/RAM目安を突き合わせ、モデルを“持ち過ぎない”判断を徹底することです。
理由はシンプルで、VRAMに収まらないモデルはメインメモリへ退避しPCIe越しにアクセスするため、推論が数倍〜数十倍遅くなるからです（参考: Ollama GitHub）。
実務の目安としては、7B〜14Bは一般的なGPUやApple Silicon Macで現実的、70Bは48〜64GB級VRAMか大容量ユニファイドメモリ、400B級はマルチGPUサーバーが必要です（参考: Ollama CLI Reference）。
例えば SIZE が数十GBの70Bモデルが並んでいれば、マシン側もそれに見合うVRAMやメモリ帯域を備えているかを必ず点検します。
より詳しい選定と高速化の勘所は、社内導入向けに整理した【2025年最新版】OllamaをGPUで高速化する完全ガイドも参考にしてください。
容量が厳しいときの現実解：大モデルはクラウド（Ollama Cloud等）に逃がす選択肢
結論として、ローカルは中〜小型モデルに絞り、超大型はOllama Cloudなどへ“逃がす”ハイブリッド構成が合理的です。
理由は、ローカルストレージやGPUを圧迫する巨大モデルを抱え込むより、必要時だけクラウドの計算力を借りた方がTCOと運用負荷を抑えられるからです。
実装の考え方はシンプルで、ローカルにはllama3.3:70bやgemma3:27b等を置き、Llama 4 400B級だけクラウドへ委譲します（参考: Ollama Cloud）。
Ollama CloudにはFree/Pro/Maxと“プレミアムリクエスト”枠があり、超コストなモデルを必要なときだけ使えるため在庫（ローカルのSIZE）を増やさずに済みます（参考: Ollama Cloud）。
社内ツール連携の観点では、エンドポイントの扱いを理解しておくと移行が滑らかなので、まずは【2025年版】Ollama API徹底ガイドで基礎を押さえると安心です。
セキュリティ視点：listに載るモデル＝社内データ処理の“責任範囲”
結論は、ollama list に並ぶモデルはすべて「社内情報を処理し得る主体」とみなし、ガバナンス対象として管理することです。
理由は、Ollamaサーバーはデフォルトで認証を持たず、ポート11434を外部へ露出すると第三者が推論やモデル操作に触れるリスクがあるからです。
対策は、OLLAMA_HOSTを127.0.0.1に限定し、VPNやFWで到達性を絞り、前段にリバースプロキシでTLSと認証を掛けることです（出典: UpGuard: Securing Exposed Ollama Instances）。
あわせて、モデルIDの整合とライセンス適合性を定期監査し、listが“承認済みモデル台帳”として機能する体制を整えます。
安全運用の全体像は【2025年最新】生成AIのセキュリティ完全解説やプロンプトインジェクション対策ガイドも参考にしてください。
トラブルシューティング：listに期待したモデルが出ない／削除できないとき
結論は、「ネットワーク・ストレージ・コマンド指定・実行中プロセス」の4点を順に潰せば大半は解決します。
理由は、listに出ないのは未完了のpullや容量不足、削除できないのは名前ミスか実行中でロックされているケースが多いからです。
Q1: pullしたのに出ない→回線・空き容量・途中失敗を確認し、再pullします。
# ダウンロードのやり直しとサイズ確認
ollama pull llama3.3:8b
ollama list
# ディスク残量（Linux/Macの例）
df -hQ2: rmで消せない→正しいNAME:TAGかを見直し、実行中なら停止してから削除します。
# 実行中モデルの確認と停止
ollama ps
ollama stop llama3.3:8b
ollama rm llama3.3:8b素早く確認するためのチェックリストを用意しました。
| 観点 | 確認内容 |
|---|---|
| 容量 | df -hで空き容量、SIZE列の大きい順に整理 |
| 名前 | NAME:TAGのスペルとタグ一致を再確認 |
| 実行中 | ollama psで稼働確認→stop後にrm |
| ネットワーク | 再pullやVPN/プロキシ設定の見直し |
基本操作の復習は【2025年版】Ollamaコマンド完全ガイドと公式リファレンスも参照してください（参考: Ollama CLI Reference）。
まとめと次の一歩
本記事では、ollama listでモデル資産を見える化し、show/ps/rmと連携して安全に整理、用途別の“残すモデル”設計と定期ルーチンで容量と性能を両立する実践手順をまとめました。
増やすより賢く選ぶ——いま台帳管理を始めれば、ローカルLLMはチームの生産性を継続的に押し上げます。
まずは環境でollama listを実行し、5分棚卸し→残す/削除/追加（必要ならOllama Cloud活用）を決めましょう。
次の一歩には実務書が近道です：生成AI 最速仕事術／生成AI活用の最前線。
