生成 AI は毎日使っているのに、知識そのものは数年前で止まっている自覚がありました。Gemini や Claude を私生活で触っているのですが、どちらも「だいたい分かっている」つもりになっていて、実際には用語の意味も課金の仕組みも説明できない、という状態です。そこで、キャッチアップすべき項目を洗い出したラーニングパスを自分用に作り、端から潰していくことにしました。
構成は 4 レイヤー・15 ステップで、項目数は 60 ほどです。利用者編から始めて、協働者編・開発者編・運用者編へ進みます。進め方は「まず自分で手を動かして調べる・検証する」「詰まったところや調べきれなかったところを AI に補ってもらう」「ワークログに残す」の 3 つを項目ごとに繰り返します。
前回の利用者編②では、ファイルのアップロードや指示文の保存で AI を自分の文脈に引き込む領域を扱いました。今回の利用者編③は、チャット UI を離れて、目的に応じた専用の環境やサービスを用意する領域で、利用者編としては最終回になります。ローカル LLM、画像・動画生成、そして自分が課金している Claude の機能の棚卸し、の順で見ていきます。この記事は、そのワークログを清書したものです。個人的に勉強して、個人的にまとめただけのものなので、網羅的な解説になっていない可能性が大いにあります。また、生成 AI まわりは動きが速く、とくに今回はモデルの提供終了や製品の統合が進行中のものを扱うので、記載の内容はすべて 2026-09 時点のものになります。
下の表が今回のやることリストです。私と同じような状況にある人は、ぜひこの順番で自分でもタスクをこなしてみることをオススメします。
| 項目 | タスク |
|---|---|
| ローカル LLM | 【調べる】量子化・GGUF・推論ランタイムの関係と、手元の PC で動くモデルの目安を説明できるようにする 【動かす】小型モデルを 1 つ動かし、同じ文章の要約をクラウドのモデルと比べる |
| 画像・動画生成 | 【調べる】3 社の画像・動画生成モデルの現状を整理する 【動かす】ブログのアイキャッチ画像を生成する |
| Claude の機能の棚卸し | 【調べる】課金しているベンダーの製品一覧から、まだ触れていない機能を洗い出す 【動かす】洗い出した機能を 1 つ動かす |
ローカル LLM
業務ではセキュリティの都合で、Claude・Gemini・GPT のようなクローズドモデルを使えないことがあると聞いていました。その場合の選択肢になるのがオープンウェイトモデルなので、どんなモデルがあるのかと、自分の PC で動かすには何が必要なのかを、実際に動かすところまで調べてみました。
オープンウェイトモデルの見取り図
まず主なオープンウェイトモデルを表にしました。以前の記事の「生成 AI サービスの見取り図」で挙げたモデルも含めています。特徴の列は AI に書かせたものを裏取りして短く丸め、ライセンスの列は公式のモデルカードやライセンス本文で確認した 2026-09 時点の内容です。
| モデル | 開発元 | ライセンス(2026-09 時点) | 特徴 |
|---|---|---|---|
| gpt-oss | OpenAI | Apache 2.0 | 推論特化。20b は 16GB メモリで動く設計 |
| Llama 4 | Meta | 独自(Llama 4 Community License) | 派生モデルのベースとして広く使われる |
| Gemma 4 | Apache 2.0(Gemma 3 以前は独自) | 端末向けの小型サイズが揃う | |
| Qwen3.5 | Alibaba | Apache 2.0 | 日本語を含む多言語とコーディングに強い |
| DeepSeek V4 | DeepSeek | MIT | 低コストで高性能。推論特化の R1 で注目された |
| Kimi K3 | Moonshot AI | 独自(Kimi K3 License) | 100 万トークンの長いコンテキスト |
| Mistral 3 系 | Mistral AI | Apache 2.0(Medium 3 は研究用) | MoE 構造を早くから採用 |
| Swallow | 東京科学大学 / 産総研 | ベース(Llama / Gemma)に準拠 | Llama などに日本語で継続事前学習 |
| ELYZA | ELYZA(KDDI グループ) | ベース(Llama 3)に準拠 | Llama 3 ベースの日本語モデル |
| PLaMo | Preferred Networks | 1B / 2B は Apache 2.0、8B 以上は独自 | ゼロから学習した国産モデル |
ライセンスを調べてみると、「Apache 2.0 や MIT で自由に使えるもの」「事業規模で線を引く独自ライセンスのもの(Llama・Kimi・PLaMo)」「研究用のもの」の 3 種に分かれていました。事業規模の線は Llama が月間 7 億ユーザー、Kimi が年商 2,000 万ドル、PLaMo が年商 10 億円と会社ごとに違います(Llama 4 Community License・PLaMo Community License について)。個人で使う分にはどれも問題ありませんが、業務に導入するときに効くのはこの線です。また、同じ系列でも世代やサイズでライセンスが変わります。Gemma は 4 から Apache 2.0 になり(Gemma 4: Expanding the Gemmaverse with Apache 2.0)、PLaMo は 1B / 2B だけが Apache 2.0 です。「モデル名=ライセンス」で覚えると 1 年で古びるので、使う直前にモデルカードの license 欄を見るのが確実です。Swallow や ELYZA のような日本語モデルは、ベースにしたモデルのライセンスをそのまま引き継いでいます。
量子化・GGUF・推論ランタイム
オープンウェイトモデルを手元で動かすには、3 つの用語を押さえておく必要がありました。
- 量子化(Quantization):モデルを軽量化して、少ない VRAM やメモリで動かす技術。モデルの重みは通常 16 ビットの浮動小数点数(FP16)で保存されており、これを INT8 や INT4 に変換して圧縮する
- GGUF:
llama.cppというオープンソースプロジェクトから生まれた、ローカル環境向けのファイル形式(拡張子.gguf)。量子化したモデルを 1 ファイルで配布するのに使われる - 推論ランタイム:モデルファイルを読み込んで、実際に計算とテキスト出力を行うプログラム。
llama.cpp本体のほか、それを包んだ Ollama や LM Studio、サーバー向けの vLLM などがある
Ollama と LM Studio はどちらも llama.cpp をバックエンドに持つ現役のツールで、違いは CLI とローカル API サーバー寄り(Ollama)か、GUI 寄り(LM Studio)かの性格差です。
必要なメモリの見積もり
「8B のモデルを 4 ビット量子化すると 8GB 程度の VRAM が必要」という目安はよく見かけるのですが、計算式があるはずだと思って調べました。必要メモリは次の 3 項の和で近似できます。
- 重み ≒ パラメータ数 × 1 パラメータあたりのバイト数。FP16 は 2 バイト、Q8 は約 1 バイト、Q4_K_M は約 0.6 バイト。8B × 0.6 ≒ 4.9GB
- KV キャッシュ ≒ 2 × 層数 × KV ヘッド数 × ヘッド次元 × バイト数 × コンテキスト長。Llama 3.1 8B なら 8K コンテキストで約 1GB、128K なら 16GB
- 作業領域:計算バッファやランタイム分で 0.5〜1.5GB 程度
「8B Q4 + 8K コンテキスト」は 4.9 + 1 + 1 ≒ 7GB で、8GB VRAM が目安になる、という計算でした。長いコンテキストを設定すると急に動かなくなるのは KV キャッシュの項が効いているためです。速度のほうは、生成が 1 トークンごとに重みを全部読み直すのでメモリ帯域で決まり、「トークン/秒 ≒ 帯域 ÷ 重みのバイト数」が上限になります。GPU 非搭載の PC の DDR4 メモリと RTX 4060 では帯域が 7 倍ほど違うので、「ローカル LLM には GPU が大事」の中身は演算力よりも帯域のようです。
LM Studio で動かしてみた
手元の PC は RAM 16GB で GPU 非搭載です。まず LM Studio Bionic を入れてみました。LM Studio と同じ会社が 2026-07 に出したエージェントアプリで、チャットだけでなくコーディングなどのタスクも頼めるもので、ちょうど 2026-09-15 に日本語 UI に対応したところでした。モデルを入れようとすると「Full GPU Offload Possible」「Partial GPU Offload Possible」「Likely too large for this machine」のような表示が出て、動くかどうかの目安を自動判定してくれます。上の見積もりをアプリ側でやってくれている表示です。
最初に Gemma 4 E2B Instruct Q4_K_M を入れたところ、アプリが動かなくなりました。より小さい Gemma 3 1B Instruct QAT に替えると動きましたが、かなりもっさりしていて、ハルシネーションもひどい状態でした。その後もう一度 Gemma 4 E2B を試すと今度は動いたので、以前の記事「利用者編①」の全文(約 14,000 字)を渡して要約してもらいました。所要時間は 16 分 49 秒です。最初の「こんにちは」への応答にも 5 分かかりました。同じプロンプトを Gemini 3.1 Pro に投げると約 20 秒でした。
さらに、より細かい情報が取れる LM Studio 本体に切り替えて同じ要約をさせたところ、明らかに速くなりました。表示された数字は生成速度 5.00 tok/sec、生成トークン数 712、初回トークンまで 87.35 秒です。約 14,000 字はトークンに直すと 1 万前後なので、読み込み側は 110〜120 tok/s、生成側は 5 tok/s、合計で 3 分 50 秒ほどになります。3 つの出力を並べたのが下の表です。
| 軸 | Gemma 4 E2B(Bionic) | Gemma 4 E2B(LM Studio 本体) | Gemini 3.1 Pro |
|---|---|---|---|
| 所要時間 | 16 分 49 秒 | 3 分 50 秒 | 20 秒 |
| 章の網羅 | 6 章のうち「音声対話」を丸ごと落とした | 6 章すべて+次回予告 | 6 章すべて+次回予告 |
| 数値 | 検証の数値(思考トークン 6.2 倍・所要時間 4.7 倍など)をすべて落とした | 同左 | 「5〜6 倍」に丸めた |
| 一般化 | 1 回の観測結果だけで法則と断言してしまう | 同左 | 観測のまま書いた |
| 体裁 | 冒頭と末尾にチャットの定型文が混ざる | 要約のみ | 要約のみ |
今回の要約タスクでは、小型モデルによる「捏造」ではなく「脱落」が目立ちました。このような要約では「嘘を書かれる」より「書いていないことに気づけない」ほうが厄介です。もう 1 つ意外だったのは、同じモデル・同じ重みでも、アプリが違うと出力の質が変わったことです。Bionic はエージェントなので、ツール定義や作業指示を含む長いシステムプロンプトが毎回先頭に入り、それが速度や口調に影響したのではと推測しています。「モデルの品質」はアプリの設定込みで見ないと信用できないという気付きが得られました。
結論として、この PC でも LM Studio でなら「Gemini の 10 倍以上待ち、章の欠落や過剰な一般化を許容できるなら、ローカル LLM は使える」というところです。つまり利用は厳しいので、GPU を積んだ PC を買いましょう、ということになります。
画像・動画生成
画像や動画の生成モデルは自分で使う機会がないのですが、Nano Banana や Sora のようにモデル名だけはよく耳にしていて、どの会社が何を出しているのかが気になっていました。普段使っている 3 社を軸に現状を整理し、ブログのアイキャッチを 1 枚作るところまでやってみました。
3 社の現状
| OpenAI | Anthropic | ||
|---|---|---|---|
| 画像 | Nano Banana 2 | ChatGPT Images 2.5 | なし |
| 動画 | Gemini Omni 1.1 Flash / Veo 3.1 | なし | なし |
2026-09 時点で、3 社のうち画像と動画の両方を出しているのは Google だけです。Google はかつて Imagen という画像モデルを持っていましたが 2026-08 に終了し、Nano Banana に移行しました(Nano Banana 2)。動画は Veo 3.1 と、その後継にあたる Gemini Omni 1.1 Flash が並走していて、Veo の終了日はまだ出ていないようです。OpenAI は画像を ChatGPT Images 2.5(2026-09)として続けており、@Sketch で自分が描いた絵を入力にすることもできます(Introducing ChatGPT Images 2.5)。かつての DALL·E は 2026-05 に API が終了しています。動画のほうは Sora がありましたが、アプリは 2026-04 に、API も 2026-09 に終了しました。Anthropic は画像も動画も出しておらず、Claude が作れるのは Artifacts での SVG や HTML までです。なお、Nano Banana 2 は Gemini 本体の画像出力機能(Gemini 3.1 Flash Image)で、独立した画像モデルの系列ではなくなったようです。
3 社以外では、次の名前をよく見かけます。
- Midjourney:芸術性とリアルな描写が特徴
- Stable Diffusion:ローカル環境でも動かせる
- Adobe Firefly:学習データに著作権上問題のない画像などのみを使用
- にじジャーニー:アニメ・イラスト特化
Firefly については、テレビ番組で生成画像のクレジットに出ているのを見たことがあり、その理由が分かりました。Adobe は学習データを Adobe Stock・オープンライセンス・パブリックドメインに限定していると明記していて、有料プランには第三者から著作権侵害を訴えられたときに Adobe が防御費用を持つ IP 補償が付いています(Adobe Firefly FAQ)。ローカル LLM のときは「業務で使えるか」の判断軸としてモデルのライセンスを考えましたが、画像生成では学習データの出所や補償に軸足が移るようです。なお、聞いたことがなかったのですが、ローカルで動かすなら Stable Diffusion より FLUX.2 や Qwen-Image が主流になっているそうです。
アイキャッチを作ってみた
普段使いの Claude では画像を生成できず、他に有料プランを持っているのは Google なので、Nano Banana 2 を使いました。ただ、画像モデルにどういうプロンプトを書けばよいのかが分からなかったので、Claude Code に記事の見出しと要旨を渡してプロンプトを考えてもらいました。画像モデルへのプロンプトは「被写体・構図・スタイル・光・テキストの有無・アスペクト比」を英語で並べる定型があるようだったので、それを踏襲しました。生成した画像は、本ブログ記事のアイキャッチに設定しました。
Claude の機能の棚卸し
普段は Claude Code しか使っておらず、他に何が使えるのかを知りませんでした。利用者編の締めとして、課金している Claude の製品一覧を公式から引き、ここまでの記事で扱った項目に当てはめて、まだ触れていない機能を洗い出しました。
Claude 側で未体験だったもの
Claude のウェブ版の UI には、次の 4 つが並んでいました。
- プロジェクト:特定の役割や知識を与えた専用 AI アシスタント。以前の記事「利用者編②」のカスタム AI の項目で扱いました
- Artifacts:チャット画面の横に開く専用の作業スペース。以前の記事「利用者編①」の Artifacts / Canvas の項目で扱いました
- スケジュール済みタスク:毎時〜毎月の頻度で、特定の指示を実行させる機能。プロジェクトを指定して実行させることもできます。未体験
- Cowork:Claude Code のエージェントとしての実行能力を、コーディング以外のナレッジワークに開放したもの。未体験
Cowork はデスクトップ版と Web 版があり、デフォルトでは Anthropic 側の環境で実行されるエージェントです。PC を閉じていても続けてほしい長時間のリサーチや、コネクタ経由で外部 SaaS のデータを横断的に扱うタスクに向いているとされています(ローカル環境で実行するモードもあります)。
ちょうど調べていた 2026-09-16 に、Cowork とチャットが 1 つの Claude に統合されるというアナウンスがありました(Claude Cowork and chat are now one Claude)。ロールアウトは順次で、この記事を書いている時点では私のアカウントにはまだ Chat / Cowork を切り替える UI が残っています。公式ブログを読む限り、今後は短いチャットでも長時間のリサーチでも、同じ UI 体験で指示を出せるようになるということでしょう。統合してシンプルになるのはよいことだと思います。
スケジュール済みタスクを動かしてみた
せっかくなので、Cowork の機能であるスケジュール済みタスクを 1 本作りました(Claude Cowork で定期的なタスクをスケジュール設定する)。統合後は会話から自然言語で作れるようですが、私のアカウントはまだ統合前なので、手動のフォームから作る形でした。作ったのは、毎朝生成 AI のニュースのサマリを作って投稿するタスクです。実行場所は手元の PC ではなくクラウドなので、PC が起動していなくても動きます。手元のファイルやアプリに触れる権限を渡すわけではないので、権限の心配をそれほどしなくてよいのも楽でした。
おわりに
ローカル LLM や画像・動画生成のモデルは、自分で使う機会はなくても名前だけはよく聞くので、今回まとめて整理できたのは収穫でした。とくに LM Studio で実際に動かしてみたことで、量子化やパラメータ数、必要メモリの見積もりが数字として理解できました。利用者編はこれで終わりですが、終わってみると、コネクタのように網羅できていないトピックも残っています。自作のラーニングパスは 1 周するだけでは網羅性に難があるので、いつか再走してロードマップの完成度を高めていくつもりです。
次は協働者編①として、コーディングエージェントを手元の開発ワークフローに組み込むところから入る予定です。


コメント