/コマンド で明示実行する Command があるSKILL.md は「AIへの業務マニュアル」みたいなもので、自然言語で手順を書いておくのがポイントgenerate.py は標準ライブラリだけで書かれており、外部ライブラリなしでも動かせる設計CHARACTERS に足していけば拡張できる元記事は、Claude Codeの Skill を使って、自宅のGPUサーバーで動く ComfyUI に画像生成を依頼する仕組みを作る話です。
ざっくり言うと、
という流れです。
これ、地味に見えてかなり便利そうです。
なぜなら、チャットで雑に頼むだけで、自分の手元の環境が画像生成マシンとして動くからです。
私はこういう「普段使いの会話から、裏でちゃんと実行される」仕組みが好きで、かなり実用的だと思います。
記事では最初に、RunPodのようなクラウドGPUの「ちょっと面倒なところ」が挙げられています。
たとえば、
このへん、使ったことがある人には「あるある」ではないでしょうか。
便利なのは間違いないんだけど、使うたびに小さなストレスが積み重なるんですよね。
元記事の主張はかなり明快で、
「自分のGPUがあるなら、自分のGPUを使えばいい」
という話です。
これはすごく素朴だけど強いです。
特に画像生成って、「毎回しっかり課金してまで使う」というより、思いついた瞬間に1枚出したい場面が多いので、従量課金の心理的ブレーキがないのはかなり大事だと思います。
この記事では、以下のような前提が示されています。
特に重要なのはGPUのVRAMです。
VRAMは、GPU専用のメモリみたいなものです。画像生成ではここをかなり使います。
元記事では、SDXLなら12GBほぼ必須という前提で話が進みます。
ここはかなり現実的だと思います。画像生成は「動くかどうか」より「どれだけ快適か」の差が大きく、VRAMが足りないと一気に苦しくなるからです。
記事の面白いところは、単なる理論ではなく、2026年4月時点のGPU市場のしんどさまで触れていることです。
たとえば、
筆者の結論はかなりはっきりしていて、
中古のRTX 3060 12GBを狙うのが現実的
とのことです。
ただし、マイニング酷使品には注意、というコメントもあります。
このあたり、夢のある話だけで終わらず、ちゃんと現実も見ているのが好印象でした。
ComfyUI自体はWindowsでもLinuxでも動きます。
元記事では、構成ごとの難易度をこんなふうに整理しています。
ここは初心者向けの入口としてもわかりやすいです。
最初はWindowsのゲーミングPCで試して、慣れてきたらLinuxやVMに移る、という流れが自然だと思います。
筆者はUbuntuの専用VMにComfyUIを常駐させているそうで、かなり本格派です。
正直、こういう構成は「やりすぎ」感もあるけど、Claude Codeから常時呼び出す前提なら理にかなっているとも思います。
この記事のキモは、構成を3層に分けている点です。
SKILL.md に、「こういう依頼が来たら、こう解釈して、こう実行する」というルールを書く層です。
要するに、AI向けの業務マニュアルです。
これはかなり言い得て妙で、人間の新人に渡す手順書とほぼ同じ発想です。
generate.py がここです。
この「実務」の部分をPythonで持ちます。
実際に画像を作るComfyUIです。
GPUが働く本丸ですね。
この分離がいいのは、
というところです。
こういう分割は地味だけど強いです。
私は、AI周りの自動化は「全部AIに任せる」より「役割分担を明確にする」ほうが安定すると思っています。この記事はその好例です。
Claude Codeには、独自機能を追加する仕組みとして Skill と Command がある、というのが記事の説明です。
/comfyui のように明示的に呼ぶ元記事では両方を用意しています。
これ、かなり実用的な判断だと思います。
自然言語は楽だけど、たまに意図を取り違えることがある。
一方でコマンドは確実だけど、少しだけ手間がある。
両方あると気分で使い分けられるので、かなり使い勝手が良さそうです。
SKILL.md は「業務マニュアル」記事で紹介されている SKILL.md は、こんな役割を持ちます。
generate.py を実行するつまり、Claude Codeに対して
「あなたはこういう係です」
と説明する文書です。
ここがかなり面白いところで、Skill設計って結局はAIに仕事を振るための社内マニュアルづくりなんですよね。
プログラミングというより、運用設計・ドキュメント設計に近い。
この感覚は、今後のAI活用でかなり重要になる気がします。
generate.py の役割generate.py は、ComfyUIに画像生成の依頼を投げるPythonスクリプトです。
ポイントは、外部ライブラリを使わず、Python標準ライブラリだけで書いていること。
これはかなり親切です。環境構築で詰まりにくいからです。
やっていることは、だいたい以下です。
この流れはシンプルですが、実用上は十分です。
正直、画像生成の自動化って凝った仕掛けより、こういう単純で壊れにくい構成のほうが長持ちすると思います。
記事では、変更ポイントが3つに絞られています。
COMFYUI_URL
http://127.0.0.1:8188CHARACTERS
build_workflow()
この「変更する場所を最小限にする」設計はかなり大事です。
こういう自動化ツールって、最初は動いても後で保守が面倒になりがちですが、触る場所が少ないと継続しやすいんですよね。
記事では、キャラクター表現の鍵として LoRA が出てきます。
LoRAは、ざっくり言うと
「元のモデルに、特定キャラや画風のクセを後から足す追加ファイル」
のようなものです。
元記事では、LoRAを探す場所として civitai.com が紹介されています。
Stable Diffusion系ではかなり有名なコミュニティサイトですね。
また、ベースモデルとしては以下が挙げられています。
このあたりはかなり“沼”ですが、記事では SDXL系で、アニメ寄りなら waiIllustrious が有力という流れです。
個人的には、モデル選びは本当に沼だと思います。
でも逆に言うと、一度自分の好みの組み合わせが決まると、かなり快適になります。
「このモデルなら大体こういう絵になる」という安心感は、AI画像生成ではかなり大きいです。
元記事の完成イメージはこうです。
generate.py secretary "office, gentle smile, looking at viewer, warm light" のように実行これ、地味だけどかなり便利です。
「画像を作る」という作業が、アプリを開いて設定してクリックする行為ではなく、自然な依頼文に変わるからです。
ここが一番の価値だと思います。
ツールを増やす話ではなく、作業を言葉に戻しているんですよね。
これはAI時代っぽい発想で、かなり好きです。
記事では、さらに応用アイデアも触れられています。
このへんまで行くと、ただの画像生成を超えて、キャラ制作の自動ラインみたいになってきます。
やりすぎると完全に趣味の工場になるけど、そういうのが楽しい人にはたまらないはずです。
率直に言うと、この記事の面白さは「Claude Codeで画像生成できる」という表面より、
AIへの依頼を、手順書とスクリプトに分解して運用しているところにあります。
AIツールって、つい「何でもやってくれる魔法」に見えがちです。
でも実際は、何をどうやってやるかを丁寧に設計したほうが強い。
この記事はその感覚をかなりうまく形にしていると思います。
あと、自宅GPUにこだわる姿勢もいいです。
クラウドの便利さを認めつつ、それでも「自分のマシンで回したい」と言い切るのは、かなり筋が通っています。
技術趣味としても、所有感としても、これは確かに楽しい。
この元記事は、Claude CodeのSkillを使って、自宅のComfyUIサーバーに画像生成を自動発注する仕組みを作る方法を紹介しています。
ポイントは、
という流れを作ることです。
「AIに絵を描かせる」だけなら珍しくないですが、
自分のローカル環境に常駐させて、言葉だけで動かすところに、この話の気持ちよさがあります。
個人的には、こういう「AIを日用品にする」方向の工夫はかなり面白いと思います。
派手なデモより、日々の使い勝手を底上げする仕組みのほうが、結局長く残る気がするからです。