2026/05/17(日)Animaの生成速度を改善してみた

前回のAnimaの正式版が出たのでベンチマークやNovelAIと品質比較してみたでは以下の通り、生成時間が長くやや厳しめだったが、もう少し何とかならないかというので試してみた。結論としては速度の向上ができた。

モデル 画像の基準サイズ 1枚辺りの生成速度
XL 448x576px 6.768s
XL 896x1152px 9.090s
Anima 896x1152px 18.054s

まず前提として私はほとんどのケースで縦長か横長でしか作らないので、前回より基準サイズを落としている。その分Upscalerで拡大する方向だ。

またベースモデルを使うこともないため、カスタマイズされたモデルを使っている。具体的には前回の検証時にはまだベースモデルが出たばかりだったので、ベースモデルしか選択肢がなかったが、Anima Cat TowerがAnima base-v1.0に対応したため、これを利用している。

確認環境

ソフトウェア

ComfyUI v0.21.1

ハードウェア

デバイス 製品
CPU Intel Core Ultra 7 265F
GPU GeForce RTX 5070 Ti
MEM Crucial CT2K16G56C46U5 * 4
M/B ASRock Z890 Pro RS

XL:基準サイズ512x768px

まずは比較用のXLから。

設定
Model waiNSFWIllustrious_v150.safetensors
VAE なし
Text Encoder なし
Empty Latent Image (WxH) 512x768px
Upscale x2.00
二段KSampler(Hire.fix)
5枚生成時の所要時間 42.40s

ノード参考

成果物

Anima:基準サイズ512x768px

次にAnimaを試す。

設定
Model animaCatTower_v10.safetensors
VAE qwen_image_vae.safetensors
Text Encoder qwen_3_06b_base.safetensors
Empty Latent Image (WxH) 512x768px
Upscale x2.00
二段KSampler(Hire.fix)
5枚生成時の所要時間 63.60s

ノード参考

詳細は以下の成果物をComfyUIに突っ込めば出るので割愛。

成果物

まとめ

モデル 画像の基準サイズ 1枚辺りの生成速度
XL 512x768px 8.48s
Anima 512x768px 12.72s

最終成果物の画像サイズが異なるため単純比較はできないが前回18.054sだったAnimaが12.72sになり、出力画像サイズも896x1152pxから1024x1536pxに増えていることから、前回より大きな画像を短時間で生成させることに成功している。

これは基準サイズを推奨値より大幅に落としたことと、Animaに従来のXLのワークフローで使っていた二段KSampler、つまりHire.fixを導入したことと、更にその部分で後段のKSamplerの処理量を落としたり、前段のKSamplerのStepも推奨から落とすことで、全体の負荷を落としたところが大きいと思う。要は推奨値からかなりあれこれ落としている。

しかもそれでいて品質は高く出ているため、現状はいい感じだと思う。まだそんなに生成してないのでどこかに落としな穴がある可能性はあるものの、現時点では満足だ。

あとがき

ブログ用に出している生成画像は毎回似たような画像ばかり出しているが、普段からこんなのを作っているわけではなく、常日頃は全く違う画像を作っている。

ただ流石にここに出すのも微妙な気がするので、このサイトがブログである必要性について考えてみた その2の延長でどうするかは考えている。

恐らくこのサイトの課題として、このブログにすべてが集約されていてノイズが多すぎるところがある。それはよくもあるのだが、ゾーニングも必要だと思う。キッティング記事と料理のレシピと旅行がごちゃ混ぜな時点で探しづらいし、そこに大分アレゲなAI生成画像を突っ込むのはさらにおかしなことになってしまう。

恐らく一定のジャンルごとにサイトを分割するのがよいと思っているが、まだどうするかは考え切れていない。ただ同時に全ての記事のフィードを垂れ流すカオスなハブもあったほうがいいとは思っている。

少なくとも画像を並べるならギャラリーのようなサイトがあることが望ましいだろう。それも内容は間違いなくアレゲなので。

2026/05/16(土)Animaの正式版が出たのでベンチマークやNovelAIと品質比較してみた

更新日:
投稿日:

ComfyUIを使ってみる2で先月からComfyUIに移行したわけだが、最近Animaという有力なモデルのプレビュー版が出たということで乗り換えていた。

このAnimaは基本的にComfyUI用で、これまで使ってきたAUTOMATIC1111やreForgeでは使えないという噂で、非常にいいタイミングだった。

そして本日正式版としてbase-v1.0が出たのでベンチマークしてみることにした。また、出力品質が以前と比べて非常に向上しており、絵柄再現やキャラ再現ができたため、NovelAIとの簡単な比較もしている。

確認環境

ソフトウェア

ComfyUI v0.21.1

ハードウェア

デバイス 製品
CPU Intel Core Ultra 7 265F
GPU GeForce RTX 5070 Ti
MEM Crucial CT2K16G56C46U5 * 4
M/B ASRock Z890 Pro RS

りこベンチ:XL:基準サイズ448x576px

これまでのりこベンチは基準となる画像サイズ(Empty Latent Image)を768x768pxで実施していたが、Animaでは896x1152pxが基準となる。

このため、まずはUpscaleで倍にすることを考え、画像の基準サイズを448x576pxに変更した、りこベンチで計測した。

設定
Model waiNSFWIllustrious_v150.safetensors
VAE なし
Text Encoder なし
Empty Latent Image (WxH) 448x576px
Upscale x2.00
二段KSampler(Hire.fix)
5枚生成時の所要時間 33.84s

ノード参考

詳細は以下の成果物をComfyUIに突っ込めば出るので割愛。

成果物

りこベンチ:XL:基準サイズ896x1152px

次はUpscaleなしで等倍の896x1152pxが出る条件で計測した。

設定
Model waiNSFWIllustrious_v150.safetensors
VAE なし
Text Encoder なし
Empty Latent Image (WxH) 896x1152px
Upscale なし
二段KSampler(Hire.fix)
5枚生成時の所要時間 45.45s

ノード参考

詳細は以下の成果物をComfyUIに突っ込めば出るので割愛。

成果物

りこベンチ:Anima:基準サイズ896x1152px

設定
Model anima_baseV10.safetensors
VAE qwen_image_vae.safetensors
Text Encoder qwen_3_06b_base.safetensors
Empty Latent Image (WxH) 896x1152px
Upscale なし
二段KSampler(Hire.fix)
5枚生成時の所要時間 90.27s

ノード参考

左下に何処にも繋がっていないノードがあるが、これは消し忘れたゴミである

詳細は以下の成果物をComfyUIに突っ込めば出るので割愛。

成果物

まとめ

モデル 画像の基準サイズ 1枚辺りの生成速度
XL 448x576px 6.768s
XL 896x1152px 9.090s
Anima 896x1152px 18.054s

以上が今回のベンチの結果だが、Upscale前提だと生成速度が3倍にもなっている。これは見方次第ではやや厳しいタイムだ。

しかしComfyUIはWorkflowsを工夫すれば一回叩くだけで複数のシーンを出すことができるため、A1111やNovelAIのように張り付かなくて良い点を考慮すれば、さほど気にならないかもしれない。

またAnimaではHirefix(二段KSampler)なしにXLより高い品質の画像を出力できているように見えるため、ここも良いポイントだ。

生成速度については「Anima-Turbo Coming soon.」と書かれているため、近日中により早いものが出るかもしれない。高品質版かもしれないが何も書いてないので実際のところは謎だ。

おまけ

これはAnimaのプレビュー版であるpreview3-baseから作られたanimaCatTower_v05.safetensorsで作った画像だが、非常に品質がいい。

恐らくbase-v1.0で作り直されれば、より品質が高まるだろう。

Animaは絵師指定による絵柄の再現ができる

NovelAIには劣るものの、これまでLoraがないと厳しかった絵柄の再現がある程度できる。いくつか実際に比較してみた。

黒星紅白

やや破綻が見られるものの、絵柄としてはだいぶ出ていると思う。NovelAIほど正確さがないのはある意味で便利かもしれない。

Anima NovelAI

カントク

ディティールはそこまでないが、大まかにはそれっぽいのが出せていると思う。NovelAIと比べるとどうしても劣る。

Anima NovelAI

いとうのいぢ

これがいとうのいぢの絵柄見えたら大分目が悪いと思う。学習量が少ないのか精度が悪い。NovelAIは流石に圧巻である。ただNovelAIも絵柄が古く、ハルヒ時代といった感じだ。最新ののいぢという感じはしない。

Anima NovelAI

☆画野郎

遠目に見えれば見えなくはないが、だいぶ厳しい。線の丸みと色の淡さはそれっぽいかもしれない。NovelAIの再現性は流石である。

Anima NovelAI

キャラ指定で絵が出せる

これも従来であればLora或いは、専用のモデルが必要だったが、一応出せるようになっている。

但し単純なプロンプトでは品質が悪くなりがちで、NovelAIと比べると勝負にすらならないレベルだ。とはいえ、それができるようになったというだけでも十分すごい。

天音かなた

ここまでの品質のものは中々出ないので奇跡の一枚に近いが、天音かなたを出すことができる。10回くらい回したが、大半は天音かなたのような何かだったので、安定性はない。

NovelAIでは非常に安定して天音かなたを出力できる。

Anima NovelAI

樋口楓

これも奇跡の一枚に近いが、泣きボクロがないけど樋口楓に見える何かは出ている。

勿論、NovelAIのほうが再現性が高く安定している。

Anima NovelAI

キノ

キノに見えなくもないくたびれた男性のようなものが出てきた。これでも奇跡の一枚で、酷いと人の姿さえ出てこないことがあった。

NovelAIは安定しており、何枚か出してみたところ特に指定していないにもかかわらず、パースエイダーを構えているものを出すことさえできた。但し指が破綻していたのでここには載せていない。

Anima NovelAI

アスナ

いわれてみればアスナに見えなくもないが、他人の空似レベルである。

NovelAIは(ry

Anima NovelAI

あとがき

XL系と比べると出力時間が三倍かかるが、品質は大きく向上し、絵柄やキャラの再現もある程度可能になっているためローカルで色々やるにはよくなったと思う。

ただ版権絵を絵柄丸コピーでどうこうするとか、そういった用途に使うにはまだ厳しいと感じた。

絵柄やキャラ再現はLora + Ponyが非常に優秀なので、何もなしで高品質だけど時間がかかるAnimaがどこまでいけるのかは現段階では未知数である。

しかしながらポテンシャルは感じるので、今後GPUの性能向上や、ComfyUIやモデルの進化などによって、より良い方向へ向かう可能性は十分にあるだろう。恐らくRTX7070TiになるころにはXL並みの速度にはなっていると思う。

2026/05/11(月)Mastodon周りのメトリクス収集メモ

更新日:
投稿日:

確認環境

Env ver
nginx 1.26.1
Apache2 2.4.58
PostgreSQL 16.13
Redis 7.0.15
Mastodon 4.5.9
Prometheus 3.5.0

Apache2

# 取得
wget https://github.com/Lusitaniae/apache_exporter/releases/download/v1.0.12/apache_exporter-1.0.12.linux-amd64.tar.gz
tar xvfz apache_exporter-1.0.12.linux-amd64.tar.gz

# binを配置
sudo cp apache_exporter-1.0.12.linux-amd64/apache_exporter /usr/local/bin/
ls -la /usr/local/bin/ | grep apache_exporter

# デーモン作成
cat <<'EOF' | sudo tee /etc/systemd/system/apache_exporter.service
[Unit]
Description=Prometheus Apache Exporter
After=network.target

[Service]
Type=simple
User=prometheus
Group=prometheus
WorkingDirectory=/var/lib/prometheus
ExecStart=/usr/local/bin/apache_exporter --scrape_uri=http://[::]:ここにポート番号/server-status?auto
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

# デーモンの有効化
sudo systemctl daemon-reload
sudo systemctl enable --now apache_exporter

# 起動確認
curl "http://[::1]:9117/metrics"

# 掃除
rm -Rf apache_exporter-1.0.12.linux-amd64 apache_exporter-1.0.12.linux-amd64.tar.gz

PostgreSQL

# 取得
wget https://github.com/prometheus-community/postgres_exporter/releases/download/v0.19.1/postgres_exporter-0.19.1.linux-amd64.tar.gz
tar xvfz postgres_exporter-0.19.1.linux-amd64.tar.gz

# binを配置
sudo cp postgres_exporter-0.19.1.linux-amd64/postgres_exporter /usr/local/bin/
ls -la /usr/local/bin/ | grep postgres_exporter

# 監視ユーザーの作成
sudo -u postgres psql
CREATE USER postgres_exporter WITH PASSWORD 'ここにパスワード';
ALTER USER postgres_exporter SET SEARCH_PATH TO postgres_exporter,pg_catalog;
GRANT pg_monitor TO postgres_exporter;
quit

# 監視情報の作成
echo 'DATA_SOURCE_NAME="postgresql://postgres_exporter:ここにパスワード@localhost:5432/postgres?sslmode=disable"' | sudo tee /etc/default/postgres_exporter
sudo chown root:root /etc/default/postgres_exporter
sudo chmod 600 /etc/default/postgres_exporter

# デーモン作成
cat <<'EOF' | sudo tee /etc/systemd/system/postgres_exporter.service
[Unit]
Description=Prometheus PostgreSQL Exporter
After=network.target postgresql.service
Wants=postgresql.service

[Service]
Type=simple
User=prometheus
Group=prometheus
WorkingDirectory=/var/lib/prometheus
EnvironmentFile=/etc/default/postgres_exporter
ExecStart=/usr/local/bin/postgres_exporter \
    --web.listen-address=[::]:9187
Restart=on-failure
RestartSec=5
EOF

# デーモンの有効化
sudo systemctl daemon-reload
sudo systemctl enable --now postgres_exporter

# 起動確認
curl "http://[::1]:9187/metrics"

# 掃除
rm -Rf postgres_exporter-0.19.1.linux-amd64 postgres_exporter-0.19.1.linux-amd64.tar.gz

Redis

# 取得
wget https://github.com/oliver006/redis_exporter/releases/download/v1.82.0/redis_exporter-v1.82.0.linux-amd64.tar.gz
tar xvfz redis_exporter-v1.82.0.linux-amd64.tar.gz

# binを配置
sudo cp redis_exporter-v1.82.0.linux-amd64/redis_exporter /usr/local/bin/
ls -la /usr/local/bin/ | grep redis_exporter

# デーモン作成
cat <<'EOF' | sudo tee /etc/systemd/system/redis_exporter.service
[Unit]
Description=Prometheus Redis Exporter
After=network.target

[Service]
Type=simple
User=prometheus
Group=prometheus
WorkingDirectory=/var/lib/prometheus
ExecStart=/usr/local/bin/redis_exporter --redis.addr=redis://localhost:6379
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

# デーモンの有効化
sudo systemctl daemon-reload
sudo systemctl enable --now redis_exporter

# 起動確認
curl "http://[::1]:9121/metrics"

# 掃除
rm -Rf redis_exporter-v1.82.0.linux-amd64 redis_exporter-v1.82.0.linux-amd64.tar.gz

Mastodonの組み込みExporter

  1. .env.productionに以下を追加
    MASTODON_PROMETHEUS_EXPORTER_ENABLED=true
    MASTODON_PROMETHEUS_EXPORTER_SIDEKIQ_DETAILED_METRICS=true
    
  2. デーモンを作る

    cat <<'EOF' | sudo tee /etc/systemd/system/mastodon-prometheus-exporter.service
    [Unit]
    Description=mastodon-prometheus-exporter
    After=network.target
    
    [Service]
    Type=simple
    User=mastodon
    WorkingDirectory=/home/mastodon/live
    Environment="RAILS_ENV=production"
    ExecStart=/home/mastodon/.rbenv/shims/bundle exec prometheus_exporter -b "::" -p 9394
    Restart=always
    
    [Install]
    WantedBy=multi-user.target
    EOF
    
    # デーモンの有効化
    sudo systemctl daemon-reload
    sudo systemctl enable --now mastodon-prometheus-exporter
    
  3. 起動確認
    curl "http://[::1]:9394/metrics"
    # Streamingはv4でしかlistenしてないので[::1]は諦める
    curl "http://localhost:5001/metrics"
    

2026/04/22(水)Google ChromeでMeetのフリーズを抑える方法

Google ChromeでMeetをしていると動画が固まることがあるが、これを回避する方法。

単純にやるには設定→システム→グラフィックアクセラレーションが使用可能な場合は使用するをOFFにするだけでいいのだが、これをするとMeetで背景ぼかしやバーチャル背景が使えなくなる問題がある。

そこで今回はMeetで背景ぼかしやバーチャル背景が使える状態を維持したまま、フリーズを抑える方法を書いてゆく。

確認環境

  • Windows 11 Pro 25H2 OSビルド26200.8246
  • Google Chrome 147.0.7727.102

やり方

  1. Chromeでchrome://flagsを開く
  2. Accelerated 2D canvasをDisabledにする
  3. GPU rasterizationをDisabledにする

2026/04/22(水)WindowsTerminalとVSCodeからMSYS2のzshでHomeキーやEndキーが効かなくなっていた問題を対応した

更新日:
投稿日:

起きていた問題

WindowsTerminalやVSCodeでMSYS2のzshを使用しているときにHome, Endを押しても.zshrcで定義したコマンドが発動しない状態で、WindowsTerminalではブザーマークが表示される状態だった。

msys2-x86_64-20210725では起きていなかったはずだが、msys2-x86_64-20260322では起きていた。

問題が起きていた時の.zshrc上の定義

# Home
bindkey "\e[H" beginning-of-line
# End
bindkey "\e[F" end-of-line

解決した方法

.zshrc上の定義を以下に変更した。

# Home
bindkey "^[[H" beginning-of-line
# End
bindkey "^[[F" end-of-line

変更差分

 # Home
-bindkey "\e[H" beginning-of-line
+bindkey "^[[H" beginning-of-line
 # End
-bindkey "\e[F" end-of-line
+bindkey "^[[F" end-of-line

あとがき

ググっても当該現象が引っかからず(最近のGoogleはアホである)、Claude Opus 4.6に調べさせても見当違いの結果しか返ってこなかったが、GitHubのIssueを漁ったところ、Shift+Arrow keys insert characters in WSL/Bash; Windows Terminal rewrites explicit selection keybindings to "id": null #18921というものがあり、そのIssueに貼ってあった設定コメントに、動きそうなコードがあったため、試してみたら動いたというのが解決の道筋である。

# Home/End (both CSI and SS3)
bindkey -M emacs '^[[H'  _home_nosel
bindkey -M emacs '^[OH'  _home_nosel
bindkey -M emacs '^[[F'  _end_nosel
bindkey -M emacs '^[OF'  _end_nosel

これで動くなら -M emacs を抜いて、_home_noselのアサインを変えればいいだけの話である。^[OH'^[OF'はLinux用[1]なのでMSYS2では考慮しなくてよいから、結果として前述にある「解決した方法」の内容でよくなるという寸法だ。

参考までにFreeBSDと同じコードになっているため、FreeBSDと設定を共有できる。なお、少なくともUbuntuとは異なるため、Linuxとは共有できないと思う。知らんけど。


  1. 私はMSYS2, FreeBSD, Linux用の.zshrcを作っているため、これを判断できたという話