Stable Diffusion系でいうCheckpointは、画像生成の土台になる主要なモデル重みです。Checkpointを替えると、得意な画風・人物表現・写真寄りかイラスト寄りかなど、生成全体の傾向が大きく変わります。
一方、LoRAは土台のCheckpointへ追加する軽量なアダプターです。ネット上で見つけたファイルを片っ端から追加するのではなく、モデル世代、配布元、形式、ライセンス、推奨VAEやLoRA互換性まで確認する方が安全です。
Checkpoint・LoRA・VAEは役割が違う
| 要素 | 主な役割 | 先に確認すること |
|---|---|---|
| Checkpoint | 生成全体の土台 | モデル世代・配布元・ライセンス |
| LoRA | 特定特徴を追加・調整 | ベースモデル互換・推奨weight |
| VAE | 潜在表現と画像の変換 | Checkpoint内蔵か、推奨VAEがあるか |
LoRAについてはLoRAとは？で「利用」と「学習」まで分けて解説しています。
Checkpointは「モデル名」だけでは判断できない
同じStable Diffusion系でも、SD1.5、SDXL、Stable Diffusion 3などは同じ構成ではありません。Checkpointに合わせて解像度、LoRA、ControlNet等の周辺モデル、WebUI側の対応状況も確認する必要があります。
つまり「人気Checkpointだから自分のLoRAも使える」とは限りません。先に自分が使いたいモデル世代を決め、その世代に対応したCheckpointと追加モデルを揃える方がトラブルを減らせます。
single-fileとDiffusers形式の違い
Hugging Face Diffusersの現行ドキュメントでは、モデルは複数フォルダに分かれたDiffusers形式のほか、重みを1ファイルにまとめたsingle-file形式でも扱えます。AUTOMATIC1111やComfyUIではsingle-fileのCheckpointを扱う場面が多く、拡張子として.safetensorsや.ckptを見かけます。
「Checkpoint＝必ずckpt拡張子」という意味ではありません。Checkpointという役割と、safetensors/ckptという保存形式を分けて理解してください。
safetensorsとckptなら何が違う？
Hugging Faceは、Pythonのpickleを使う古いckpt/binファイルには悪意あるコードを含められる危険があるとして、可能な場合はsafetensorsを推奨しています。safetensorsはテンソルを安全に保存・読み込みする目的で設計された形式です。
そのため、同じ配布元・同じモデル内容でsafetensors版が正式提供されているなら、安全面ではそちらを優先する理由があります。ただしsafetensorsなら配布物の権利や内容まで保証されるわけではありません。配布元・モデルカード・ライセンスの確認は別に必要です。
追加前にモデルカードで6項目を見る
- ベースモデル・世代（SD1.5 / SDXL等）
- ライセンスと商用利用条件
- 推奨解像度
- 推奨VAEの有無
- 推奨プロンプト・設定
- 更新履歴と配布元
特に商用サイトで生成画像を使う場合、「ダウンロードできる＝商用利用可能」と判断しないことが重要です。モデル本体と、追加するLoRA等の条件をそれぞれ確認します。
Checkpointを増やしすぎるとストレージも圧迫する
フルCheckpointはLoRAより大きくなりやすく、複数世代・複数バージョンを保存すると容量を消費します。ローカルならSSD、クラウドなら契約ストレージを先に見積もります。
ConoHa AI Canvasは2026年9月時点で任意Checkpointの追加に対応し、プランごとのストレージは30GB / 100GB / 500GBです。クラウド側の保存容量も含めた比較はStable Diffusionクラウドサービスの選び方で整理しています。
Checkpointを変えるときは条件を固定して比較する
Checkpointの違いを見たいなら、seed、プロンプト、Sampler、Steps、解像度などをできるだけ固定し、Checkpointだけ変えて比較します。LoRAやControlNetまで同時に変えると、どの要素が結果を変えたのか分からなくなります。
最初から「おすすめモデルランキング」で決めるより、自分が必要とする写真・イラスト・商品画像などの用途で同条件比較する方が再現性があります。
WebUI側がそのモデル世代に対応しているか確認する
Checkpointファイルがあっても、利用中のWebUIやノードがそのモデル構造に対応していなければ動きません。AUTOMATIC1111とComfyUIでは対応モデルやワークフローの広がり方も異なります。UI選びはAUTOMATIC1111とComfyUIの違いで確認してください。
Checkpointを比較するときの記録表
同じプロンプトでもCheckpointを変えると構図・画風・文字の出方などが変わることがあります。比較ではSeed、解像度、Sampler、Steps、VAE、LoRAの有無をできるだけ揃え、モデル名・バージョン・配布URL・生成日時を記録します。モデル固有の推奨設定がある場合は、共通条件の比較と推奨条件での比較を分けると判断しやすくなります。
拡張子が.safetensorsでも、配布元の信頼性や商用利用条件が保証されるわけではありません。Hugging Faceの公式資料は、古い.ckptがpickle由来の安全上の問題を持ち得るため、可能ならsafetensors形式を選ぶよう説明しています。ただし形式だけで出所確認を省略しないでください。
導入前に、モデルカードのライセンス、禁止用途、派生モデルの扱い、学習元の説明、対応するUI・必要VRAMを確認します。Webサイトの商用素材に使う場合は、モデルの許諾と生成サービス側の利用条件を両方保存しておくと、後から差し替える際にも確認できます。
Checkpointを選ぶ5ステップ
- 用途を1つ決める：写真、イラスト、商品ビジュアルなど、まず評価対象を固定します。
- モデル世代を決める：手持ちLoRAやWebUIとの互換性からSD1.5、SDXL等の系統を絞ります。
- 配布元とライセンスを確認する：商用利用、禁止用途、派生モデル条件を保存します。
- 同一条件で生成する：Seed、解像度、Sampler、Stepsを固定し、Checkpointだけ変更します。
- 採用モデルを少数に絞る：用途別に基準モデルを決め、バージョンと取得元を記録します。
この順番なら「人気だから追加する」ではなく、自分の用途に必要かを先に判断できます。特にWebサイト運営では、毎回モデルを変えるより、用途ごとに基準Checkpointを固定した方がアイキャッチや記事画像のトーンを再現しやすくなります。
更新版へ入れ替えるときは旧版をすぐ消さない
同じモデルの新バージョンが出ても、既存画像の再現性が維持されるとは限りません。新旧を同じプロンプト・Seedで比較し、必要な過去案件を再生成できることを確認してから整理します。ファイル名だけでなく、モデル名、バージョン、ハッシュ、配布URLを残すと、後から「どのモデルで作った画像か」を追跡しやすくなります。
Checkpoint周辺のファイルを役割別に整理する
| 種類 | ざっくりした役割 | 置き換える範囲 |
|---|---|---|
| Checkpoint | 画像生成の中心モデル | 土台全体 |
| LoRA | 特徴の追加・微調整 | 差分 |
| VAE | 潜在表現と画像の変換に関係 | 色・質感等へ影響する場合 |
| Control系 | ポーズ・輪郭等の条件付け | 生成条件 |
モデル追加前の安全チェック
- 公式・信頼できる配布元か
- SD1.5/SDXL等の対応系統が合うか
- ライセンスと商用条件を確認したか
- 可能ならsafetensors形式やハッシュ情報を確認したか
- ファイル容量と保存先に余裕があるか
モデルファイルは大きく、数を増やすほど「どれを使ったか」が分からなくなります。ファイル名を変えるだけでなく、配布ページURL、取得日、ライセンス、ハッシュをメモしておくと後から確認できます。
Checkpointを変えるとLoRAの効き方も変わる
LoRAはどの土台でも同じ結果になるとは限りません。ベース系統や学習元との相性があり、Checkpointを変更すると同じLoRA強度でも出力が大きく変わることがあります。比較するときは一度にCheckpointとLoRAとプロンプトを全部変えず、1要素ずつ動かします。
「人気モデル」より自分の用途で固定する
モデル探しを続けると、生成よりダウンロードと比較に時間を使いがちです。Web運営なら「写真系」「イラスト系」など用途ごとに基準Checkpointを少数固定し、必要なときだけLoRAを追加する方が再現性と管理性を保ちやすくなります。
まとめ
CheckpointはStable Diffusion系画像生成の土台となる主要なモデル重みです。LoRAとは役割が違い、ファイル形式とも別概念です。追加前はモデル世代、ライセンス、VAE、WebUI対応、保存容量を確認し、同じモデルなら可能な範囲でsafetensorsを優先します。数を集めるより、用途に合う少数を条件固定で比較する方が管理しやすくなります。
コメント