DEV Community: スシロー

【2026】Datadog 代替の低価格監視SaaS：料金・移行コストで選ぶ

スシロー — Sun, 05 Jul 2026 02:03:43 +0000

結論（おすすめ1つ）

Grafana Cloud に乗り換えるべき。

Prometheus/Loki/Tempoのエコシステムをそのまま使えるため、既存のインフラ資産を捨てずに済む。無料枠が実用範囲に収まっており、小〜中規模サービスならコストゼロで本番運用できる。エージェント互換性が高く、Datadogエージェントのドロップイン代替として機能するため移行コストが低い。

比較表（料金/無料枠/移行コスト/対応言語）

ツール	料金体系	無料枠	移行コスト	対応言語・SDK
Grafana Cloud	メトリクス/ログ/トレース量従量	あり（公式の料金ページで要確認）	低：Prometheusエクスポーター流用可	Go/Python/JS/Java/Ruby/.NET 他
New Relic	データインジェスト量従量	あり（公式の料金ページで要確認）	中：エージェント再インストール必要	主要言語ほぼ全対応
SigNoz	セルフホスト無料／クラウド従量	セルフホストは実質無制限	中：OpenTelemetryへの書き換えが必要	OpenTelemetry対応言語すべて
Better Stack	ホスト数・ログ量従量	あり（公式の料金ページで要確認）	低：ログ転送設定のみで開始可	ログ中心、APMは限定的
Datadog（参考）	ホスト数＋機能従量	実質なし	—	広範

移行手順

Grafana Cloud への移行を例に示す。

Step 1：Grafana Cloud アカウント作成・スタックURL取得

Grafana Cloud のダッシュボードにログインし、スタックの PROMETHEUS_URL・LOKI_URL・API_KEY を控える。

Step 2：Grafana Alloy（旧 Grafana Agent）をインストール

# Linux (systemd)
curl -fsSL https://apt.grafana.com/gpg.key | sudo gpg --dearmor \
  -o /etc/apt/keyrings/grafana.gpg

echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] \
  https://apt.grafana.com stable main" \
  | sudo tee /etc/apt/sources.list.d/grafana.list

sudo apt-get update && sudo apt-get install -y alloy

Step 3：設定ファイルを記述

# /etc/alloy/config.alloy

prometheus.remote_write "grafana_cloud" {
  endpoint {
    url = env("PROMETHEUS_URL")
    basic_auth {
      username = env("GRAFANA_INSTANCE_ID")
      password = env("GRAFANA_API_KEY")
    }
  }
}

prometheus.scrape "local" {
  targets = [{"__address__" = "localhost:9090"}]
  forward_to = [prometheus.remote_write.grafana_cloud.receiver]
}

loki.write "grafana_cloud" {
  endpoint {
    url = env("LOKI_URL")
    basic_auth {
      username = env("GRAFANA_INSTANCE_ID")
      password = env("GRAFANA_API_KEY")
    }
  }
}

loki.source.file "app_logs" {
  targets = [
    {__path__ = "/var/log/app/*.log", job = "app"},
  ]
  forward_to = [loki.write.grafana_cloud.receiver]
}

Step 4：サービス起動と疎通確認

sudo systemctl enable alloy --now

# Grafana Cloud 上でメトリクスが届いているか確認
# Explore → Metrics → {job="app"} で検索

Step 5：Datadog エージェントの停止

sudo systemctl stop datadog-agent
sudo systemctl disable datadog-agent
# 完全アンインストールする場合
sudo apt-get remove --purge datadog-agent

Step 6：既存ダッシュボードの移行

DatadogのダッシュボードJSONをエクスポートし、dd-to-grafana などのOSSコンバーターを通すか、Grafana上で手動再現する。アラートルールはPromQL/LogQLで書き直す必要がある。

向き不向き

向いているチーム・規模

スタートアップ・個人開発者：無料枠内に収まるなら監視コストがゼロになる
すでにPrometheus/Grafanaスタックを自前運用しているチーム：設定の大半を流用できる
OpenTelemetry対応を進めているチーム：ベンダーロックを避けつつSaaSの運用負荷ゼロを両立できる
ログ・メトリクス・トレースを一元管理したいが、Datadogの請求が予測困難で困っているチーム

避けるべきケース

APMのコードレベル可視化（関数単位のフレームグラフなど）をGUI上で深掘りしたい場合：Datadogのような深度には及ばない
Kubernetes大規模クラスタ（数百ノード超）をフルマネージドで監視したい場合：無料枠をすぐ超え、コストシミュレーションを先に行う必要がある
セキュリティ監査ログ（SIEM相当）を同一プラットフォームで完結させたいチーム：専用SIEMとの併用が現実的
エンジニアリソースが逼迫しており、移行作業に1〜2スプリントも割けないチーム：移行コストが低いとはいえ、ゼロではない

【2026】Mailchimp 代替のトランザクションメールAPI：料金・移行コストで選ぶ

スシロー — Sun, 05 Jul 2026 02:02:22 +0000

結論（おすすめ1つ）

Resend に乗り換えるべき。

React Email との統合が標準で、TypeScript 型定義がファーストクラス対応であるため、現代的なスタック（Next.js / Node.js）と最も摩擦なく繋がる。SMTP リレーではなく HTTP API 単一エンドポイントで完結するため、Mailchimp の複雑な設定を捨てて 30 分以内に本番送信まで到達できた。DKIM・SPF の DNS 設定も管理画面で自動生成されるので、メール到達率の確保を自分でゼロから調べる必要がない。

比較表（料金/無料枠/移行コスト/対応言語）

ツール	無料枠	料金	移行コスト	主な対応言語
Resend	あり（公式の料金ページで要確認）	従量課金＋月額プラン	低：HTTP API のみ	Node / Python / Go / Ruby / PHP / Elixir など公式 SDK 多数
Postmark	あり（テスト用クレジット）	送信数従量課金（公式要確認）	低〜中：SMTP と API 両対応	Node / PHP / Ruby / Python / .NET / Go
SendGrid	あり（公式の料金ページで要確認）	従量課金＋月額プラン	中：ライブラリが旧世代気味	主要言語ほぼ網羅
Mailgun	試用枠あり（公式要確認）	従量課金	中：ドメイン認証設定が煩雑	Node / Python / PHP / Ruby / Java
AWS SES	無料枠あり（EC2 経由に条件）	最安水準（公式要確認）	高：IAM / バウンス処理を自前実装	AWS SDK 全対応

Mailchimp Transactional（旧 Mandrill）は Mailchimp 本体との強制バンドルが最大の痛点だった。上記の代替はいずれも単独契約できる。

移行手順

ここでは Resend への移行を例示する。

Step 1: SDK インストール

npm install resend
# Python の場合
pip install resend

Step 2: API キー取得と環境変数設定

Resend ダッシュボード → API Keys → Create API Key でキーを発行する。

# .env
RESEND_API_KEY=re_xxxxxxxxxxxxxxxxxxxx

Step 3: 送信ドメインの DNS 設定

ダッシュボード → Domains → Add Domain でドメインを追加すると、以下の形式のレコードが表示される。これを DNS プロバイダへ登録する。

TXT  resend._domainkey.example.com  "v=DKIM1; k=rsa; p=..."
TXT  example.com                    "v=spf1 include:amazonses.com ~all"

検証完了まで数分〜数時間かかる。

Step 4: 最小送信コード（Node.js）

import { Resend } from 'resend';

const resend = new Resend(process.env.RESEND_API_KEY);

async function sendTransactional(to: string, orderId: string) {
  const { data, error } = await resend.emails.send({
    from: 'no-reply@example.com',
    to,
    subject: `注文確認 #${orderId}`,
    html: `<p>ご注文ありがとうございます。注文番号: <strong>${orderId}</strong></p>`,
  });

  if (error) throw new Error(error.message);
  return data;
}

Step 5: Mailchimp Transactional からの切り替え

旧コードで mailchimp_transactional.ApiClient を呼んでいた箇所を上記関数に置換する。テンプレート ID による呼び出しを使っていた場合は、React Email または通常の HTML 文字列テンプレートへ変換する。

# 旧コードの参照箇所を一括確認
grep -r "mailchimp_transactional\|mandrill" src/

Step 6: バウンス・Webhook 設定

ダッシュボード → Webhooks → Add Endpoint でバウンスや配信失敗イベントを自前 API エンドポイントへ転送するよう設定する。Mailchimp 側の Webhook 設定は削除してよい。

向き不向き

向いているチーム・ケース

TypeScript / Node.js または Python ファーストのスタックで開発している小〜中規模チーム
React Email でメールテンプレートをコンポーネント化したい場合（Resend が最適）
Mailchimp の月額コストを削りたい、かつトランザクション送信に特化したい場合
SES を使いたいが IAM 管理やバウンス処理の自前実装工数を払いたくない場合（Resend/Postmark が SES 上で動く構成を取ることもある）

避けるべきケース・注意点

大量の既存 Mandrill テンプレート（Handlebars 形式）をそのまま移植したい場合：変換工数がかかる。SendGrid の Dynamic Templates の方が構文が近い
送信数が月数百万通を超える規模で単価を極限まで下げたい場合：AWS SES の直接利用が費用面では有利だが、バウンス処理・レピュテーション管理を自前で担う覚悟が必要
.NET / Java がメインで公式 SDK の成熟度を重視する場合：SendGrid または Postmark の方が実績が長い
SMTP リレーを既存インフラ（レガシー PHP など）から変えられない場合：Resend より Postmark や Mailgun の SMTP エンドポイントを使う方が移行コストが低い

【2026】Auth0 代替 (Clerk/Supabase Auth/WorkOS)：料金・移行コストで選ぶ

スシロー — Sun, 05 Jul 2026 02:01:26 +0000

結論（おすすめ1つ）

乗り換え先の推薦：Clerk

Auth0 からの移行先として、大半の SPA／Next.js プロジェクトには Clerk が最もコストパフォーマンスが高い。理由は三点：① UI コンポーネントが同梱されており認証フローをほぼゼロ実装で置き換えられる、② JWT／Session Token の切り替えが設定一つで完結する、③ Auth0 の「Organizations」に相当するマルチテナント機能が標準搭載されている。WorkOS は SSO／SAML が最優先の B2B 向け、Supabase Auth は Supabase の DB を既に使っている場合に限り有利な選択肢だ。

比較表（料金/無料枠/移行コスト/対応言語）

項目	Auth0	Clerk	Supabase Auth	WorkOS
無料枠 MAU	公式料金ページで要確認	公式料金ページで要確認	公式料金ページで要確認	公式料金ページで要確認
有料開始価格	公式料金ページで要確認	公式料金ページで要確認	公式料金ページで要確認	公式料金ページで要確認
移行コスト	―	低〜中（SDK入替＋JWT検証変更）	中（GoTrue API の理解が必要）	中〜高（SSO設定が前提）
SDK の充実度	◎	◎（React/Next.js/Remix 中心）	○（Supabase JS 中心）	○（Node/Go 中心）
対応言語	Node/Python/Go/Java 等	JS/TS（他は REST API）	JS/TS/Dart/Python 等	Node/Python/Go/Ruby 等
マルチテナント	有（Organizations）	有（Organizations）	要自前実装	有（Enterprise SSO 中心）
エンタープライズ SSO	有（上位プランのみ）	有	限定的	◎（中心機能）
セルフホスト	不可	不可	可（OSS）	不可

料金は変動が激しいため、各サービスの公式料金ページで必ず最新値を確認すること。

移行手順

Auth0 → Clerk への移行を例に、実際に動くコマンドと設定を示す。

Step 1：Clerk アプリを作成して API キーを取得

Clerk ダッシュボード（clerk.com）でアプリを新規作成し、Publishable Key と Secret Key を取得する。

Step 2：SDK を入れ替える

# Next.js の場合
npm install @clerk/nextjs

# 既存の Auth0 パッケージを削除
npm uninstall @auth0/nextjs-auth0

Step 3：環境変数を差し替える

.env.local を以下のように更新する。

# 削除する Auth0 変数
# AUTH0_SECRET=...
# AUTH0_ISSUER_BASE_URL=...
# AUTH0_CLIENT_ID=...
# AUTH0_CLIENT_SECRET=...

# 追加する Clerk 変数
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_live_xxxxxxxxxx
CLERK_SECRET_KEY=sk_live_xxxxxxxxxx

Step 4：ミドルウェアを置き換える

// middleware.ts
import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server';

const isPublicRoute = createRouteMatcher(['/sign-in(.*)', '/sign-up(.*)']);

export default clerkMiddleware((auth, req) => {
  if (!isPublicRoute(req)) auth().protect();
});

export const config = {
  matcher: [
    '/((?!_next|[^?]*\\.(?:html?|css|js(?!on)|jpe?g|webp|png|gif|svg|ttf|woff2?|ico)).*)',
    '/(api|trpc)(.*)',
  ],
};

Step 5：UI コンポーネントを差し替える

// Before（Auth0）
import { useUser } from '@auth0/nextjs-auth0/client';

// After（Clerk）
import { useUser, UserButton, SignInButton } from '@clerk/nextjs';

export function Header() {
  const { isSignedIn } = useUser();
  return (
    <header>
      {isSignedIn ? <UserButton afterSignOutUrl="/" /> : <SignInButton />}
    </header>
  );
}

Step 6：既存ユーザーをインポートする

Auth0 の Management API でユーザーリストをエクスポートし、Clerk の Backend API でインポートする。Auth0 はパスワードハッシュをエクスポートできないため、初回ログイン時にパスワードリセットを促すフローを実装するのが現実的だ。

# Auth0 Management API でユーザーをエクスポート（要 Management API トークン）
curl -X GET "https://YOUR_DOMAIN.auth0.com/api/v2/users" \
  -H "Authorization: Bearer $AUTH0_MGMT_TOKEN" \
  -o users_export.json

# Clerk Backend API でユーザーをインポート（Node スクリプト例）
node scripts/import_users_to_clerk.js

向き不向き

Clerk が向くケース

Next.js／React 中心のチーム：公式コンポーネントをそのまま使えるため実装工数が最小で済む。
1〜20 名規模のスタートアップ：Auth0 の設定複雑さに疲れており、すぐに動かしたい場合。
マルチテナント SaaS を構築している：Organizations が標準搭載されており追加実装が少ない。

Supabase Auth が向くケース

Supabase の PostgreSQL を既に使っている：Row Level Security と Auth を一体化できるため二重管理が不要になる。
セルフホストが必要なプロジェクト：Auth0・Clerk・WorkOS はすべてクラウド専用だが、Supabase はセルフホスト可能。

WorkOS が向くケース

エンタープライズ顧客への SAML／OIDC SSO が必須の B2B SaaS：この用途に特化しており、管理 UI が最も整っている。
Active Directory 連携（SCIM）が要件：ディレクトリ同期の実装コストが他と比べて大幅に低い。

避けるべきケース

Clerk：iOS／Android ネイティブアプリが主体のプロジェクトには SDK の厚みが不足することがある。REST API 経由での実装は可能だが、Auth0 のモバイル SDK と比べると薄い。
Supabase Auth：Supabase の DB や Storage を使わず Auth 単体だけを採用するのはオーバーヘッドが大きい。認証専用なら Clerk の方が素直に使える。
WorkOS：B2C のソーシャルログインが主体で大量 MAU を想定するプロジェクトには過剰設計になりやすい。料金体系もエンタープライズ前提のため、採用前に必ず公式料金ページで確認すること。

I ran Claude Code unattended for months. Here's the 10-chapter book of everything that broke (and worked)

スシロー — Sat, 04 Jul 2026 14:42:31 +0000

I've been running Claude Code as a daily unattended worker for months — generating articles, rebuilding an 800+ page static site, updating ML prediction sites — all fired by Task Scheduler every morning with nobody at the keyboard.

I put everything I learned into a 10-chapter ebook: Practical Claude Code — Development, Automation, and Unattended Operation with the CLI Agent.

What's inside

Install to first productive session (including Windows-specific gotchas)
CLAUDE.md / settings.json / hooks configs you can drop in as-is
Designing headless pipelines with claude -p (JSON output, retries, timeouts)
Running it unattended on a schedule — and keeping it alive
The failures: the 6-hour pipe hang, the 2-hour git credential-prompt stall, LLMs fabricating numbers (and the pre-publish sanitizer that fixed it)

No revenue hype, no "AI will 10x you" — just the working setup and the scars.

Get it

Ebook (EPUB, 10 chapters): https://itsuya.gumroad.com/l/claudecodebooken (~$9)
Launch: code START50 = 50% off → https://itsuya.gumroad.com/l/claudecodebooken/START50
Companion kit: 50 AI Debugging Prompts + Claude Code Config Pack

Questions welcome in the comments — I'll fold answers back into the book.

Disclosure: my own book; written with AI assistance and human review/editing.

2026年版・AIエージェント(FastAPI)に渡すルールファイル実践ガイド

スシロー — Sat, 04 Jul 2026 02:04:41 +0000

なぜルールファイルがエージェント品質を左右するか

FastAPIで構築したAIエージェントにClaude CLIやCursorを組み合わせるとき、LLMへの「指示の揺れ」が最大のボトルネックになる。同じコードベースを触らせても、プロンプトが毎回違えば出力も毎回ブレる。CLAUDE.md / .cursorrules / AGENTS.md といったルールファイルは、その揺れをゼロにするための静的な仕様書だ。

LLMはコンテキストウィンドウの先頭に近いテキストを強く参照する。リポジトリルートに置いたルールファイルはツールが自動でコンテキスト先頭に挿入するため、毎回プロンプトに書かなくても設計意図が伝わる。

実例：FastAPIプロジェクト向け CLAUDE.md

# CLAUDE.md — AIエージェント行動ルール

## プロジェクト概要
Python 3.12 / FastAPI 0.111 / PostgreSQL 16 で構築した
REST API サーバー。非同期 I/O (asyncpg) を全面採用。

## コーディング規約
- 型アノテーションを必ず付ける(py.typed 準拠)
- Pydantic v2 モデルで入出力を定義する
- ルーターは `src/routers/` に機能単位で分割する
- テストは pytest-asyncio + httpx.AsyncClient で書く

## 禁止事項
- `time.sleep()` の使用禁止。`asyncio.sleep()` を使う
- グローバル変数への副作用を持つ関数を作らない
- `.env` の値をコードにハードコードしない

## エージェントへの追加指示
- 既存関数を書き換える前に「変更理由」を1行コメントで残す
- DBスキーマ変更を伴う場合は Alembic マイグレーションファイルも生成する
- PR説明文は英語、コードコメントは日本語で統一する

## 参照ドキュメント
- API仕様: docs/openapi.yaml
- ERD: docs/erd.png
- 環境変数一覧: .env.example

ファイル種別の使い分け

ファイル名	読み込むツール	主な用途
`CLAUDE.md`	Claude CLI / Claude Code	プロジェクト全体の設計思想と禁止事項
`.cursorrules`	Cursor IDE	エディタ操作レベルの補完ルール
`AGENTS.md`	OpenAI Agents SDK など	エージェント同士の役割分担と通信プロトコル

FastAPIプロジェクトでは CLAUDE.md を最上位に置き、サブディレクトリ(src/routers/など)にも局所的な補足を置く階層構造が実用的だ。Claude CLIはディレクトリを上から下へ収集して結合するため、上位の方針を下位で上書きできる。

運用Tips

1. 「禁止事項」を先に書く
LLMは許可より禁止の方が遵守率が高い。asyncio.sleep() の強制など、型チェッカーで検出できないルールほど明示する効果が大きい。

2. ルールは測定可能な形にする
「良いコードを書く」ではなく「型アノテーションを必ず付ける」のように、LLMが自己検証できる粒度にする。曖昧なルールは無視される。

3. CIでルールの整合性を検証する
ruff や mypy をCIに組み込み、ルールファイルで定めた規約が守られているかを自動確認する。エージェントが破ったルールはCIが検知し、次のプロンプトでフィードバックする仕組みにすると自己修正ループが回る。

4. 変更履歴をコミットメッセージに残す
ルールファイル自体もGit管理し、なぜそのルールを追加・削除したかをコミットメッセージに書く。3ヶ月後に「このルールは何のために？」と迷う時間を省ける。

ルールファイルは銀の弾丸ではないが、エージェントの出力を「毎回ゼロから説明する」から「既知の前提の上に積む」に変える最も低コストな手段だ。まず10行の CLAUDE.md から始めて、エージェントが迷うたびに1行追加する運用が現実的に続く。

5フレームワーク分の実例をまとめたキット

Next.js/React/FastAPI/Godot/Express のルールファイル実例集を用意しました。👉 詳細・入手はこちら

【2026】Auth0 代替 (Clerk/Supabase Auth/WorkOS)：料金・移行コストで選ぶ

スシロー — Sat, 04 Jul 2026 02:03:49 +0000

結論（おすすめ1つ）

乗り換え先として最初に検討すべきは Clerk。

Next.js / React が主戦場のチームなら、Clerk が現時点で移行コストと開発体験のバランスに最も優れている。理由は3点：SDK がフレームワーク単位で設計されており認証 UI の自前実装がほぼ不要、JWT／セッション管理がデフォルトで安全な構成になっている、Auth0 と同等のソーシャルログイン・MFA をダッシュボード操作だけで完結できる。

ただし、エンタープライズ SSO（SAML／SCIM）が受注条件になっている B2B SaaS チームは WorkOS、既存スタックが Supabase ベースなら Supabase Auth を先に評価すること。

比較表（料金/無料枠/移行コスト/対応言語）

項目	Auth0	Clerk	Supabase Auth	WorkOS
無料枠	MAU 上限あり（公式の料金ページで要確認）	MAU 上限あり（公式の料金ページで要確認）	プロジェクト単位（公式の料金ページで要確認）	開発・ステージング向け無料枠あり（公式の料金ページで要確認）
有料時の課金軸	MAU ベース	MAU ベース	プロジェクト数・機能	SSO コネクション単位
移行コスト	―	中（SDK 差替・JWT claims 変更）	中〜高（DB 統合が前提）	高（SSO 設定・ユーザー移行）
主対応言語	多言語（公式 SDK 多数）	JS/TS 中心（React/Next.js 特化）	JS/TS・Python・Go ほか	JS/TS・Python・Go ほか
セルフホスト	不可	不可	可（OSS）	不可
SAML/SCIM	高額プランのみ	有料プラン	限定的	コア機能として標準

移行手順

Auth0 から Clerk への移行を例に、実際に踏んだ手順を示す。

1. Clerk SDK のインストール

npm install @clerk/nextjs

2. 環境変数の差し替え

# .env.local（Auth0 の変数を削除し Clerk の変数に置き換える）

# 削除対象
# AUTH0_SECRET=...
# AUTH0_BASE_URL=...
# AUTH0_ISSUER_BASE_URL=...
# AUTH0_CLIENT_ID=...
# AUTH0_CLIENT_SECRET=...

# 追加
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_xxxx
CLERK_SECRET_KEY=sk_test_xxxx

3. ミドルウェアの設定（Next.js App Router）

// middleware.ts
import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server'

const isProtected = createRouteMatcher(['/dashboard(.*)'])

export default clerkMiddleware((auth, req) => {
  if (isProtected(req)) auth().protect()
})

export const config = {
  matcher: ['/((?!_next|.*\\..*).*)'],
}

4. Auth0 のユーザーデータを取得

# Auth0 Management API でユーザー一覧を JSON に落とす
curl -H "Authorization: Bearer $AUTH0_MGMT_TOKEN" \
  "https://YOUR_DOMAIN.auth0.com/api/v2/users?per_page=100" \
  > auth0_users.json

5. Clerk へユーザーをインポート

// scripts/migrate-users.ts
import { clerkClient } from '@clerk/nextjs/server'
import users from './auth0_users.json'

for (const u of users) {
  await clerkClient.users.createUser({
    emailAddress: [u.email],
    // Auth0 の user_id を externalId として保持しておくと
    // 既存 DB レコードとの突合スクリプトが楽になる
    externalId: u.user_id,
  })
}

パスワードハッシュ（bcrypt）のインポートは Clerk のバルクインポート API が対応しているか事前に公式ドキュメントで確認すること。未対応の場合はパスワードリセットメールをユーザーに送る運用が現実的。

6. JWT Claims の差し替え確認

Auth0 の sub クレームは auth0|xxxxx 形式になっているため、バックエンド側の認証ミドルウェアが期待する形式と一致しなくなる。Clerk では userId を取得して既存の DB レコードと突合する移行スクリプトを本番切り替え前に必ず実行する。

向き不向き

Clerk が向くケース

Next.js / React を主軸にした SaaS でスピード優先
フロントエンド中心のスタートアップ（認証 UI を自前実装したくない）
Auth0 の料金が MAU 増加で無視できなくなってきたチーム

Supabase Auth が向くケース

既に Supabase（PostgreSQL）を使っており DB とユーザー管理を一元化したい
セルフホストが必要なコンプライアンス要件がある
バックエンド中心の構成で Next.js 以外のフレームワークを使っている

WorkOS が向くケース

受注条件に SAML SSO・SCIM プロビジョニングが含まれる B2B SaaS
大企業顧客を相手にする予定があり、監査ログ・ディレクトリ同期が必須
エンタープライズ対応を将来的に見越して最初から設計したい

避けるべきケース

Clerk：Vue・Django・Rails 等が主体の場合、SDK の成熟度に差があり検証コストが増す。React 以外では素直に Supabase Auth か Auth0 を評価し直すほうが早い
Supabase Auth：Auth0 のカスタムアクション（ルールエンジン）を多用しているプロジェクトは機能差を先に精査すること。移植工数が読みにくくなる
WorkOS：コンシューマー向けアプリには過剰スペック。コネクション単位の課金体系は小規模チームや個人開発では割高になる可能性がある

【2026】Algolia 代替の全文検索SaaS比較：料金・移行コストで選ぶ

スシロー — Sat, 04 Jul 2026 02:02:17 +0000

結論（おすすめ1つ）

Meilisearch に乗り換えるべきだ。

API 設計が Algolia に近く、既存コードの差し替えコストが最小限で済む。OSS（MIT ライセンス）なのでセルフホストで運用コストをゼロにでき、Meilisearch Cloud を使えばマネージドの体験もそのまま得られる。日本語トークナイズをビルトインでサポートしており、追加プラグインなしで日本語全文検索が動く。

比較表（料金/無料枠/移行コスト/対応言語）

ツール	料金モデル	無料枠	移行コスト	日本語対応
Algolia	レコード数＋検索数課金	あり（公式の料金ページで要確認）	―	プラグイン必要
Meilisearch	セルフホスト無料 / Cloud は従量	Cloud あり（公式の料金ページで要確認）	低（API 互換層あり）	ビルトイン
Typesense	セルフホスト無料 / Cloud は従量	Cloud あり（公式の料金ページで要確認）	低〜中	ビルトイン
OpenSearch	セルフホスト無料 / AWS マネージド課金	AWS 無料枠範囲内（公式で要確認）	高（設定量が多い）	プラグイン必要
Orama	セルフホスト無料 / Cloud あり	Cloud あり（公式の料金ページで要確認）	中（API 設計が異なる）	対応済み

移行手順

Algolia から Meilisearch へ移行する手順を示す。Node.js プロジェクトを前提とする。

Step 1: Meilisearch を起動する

docker run -d \
  -p 7700:7700 \
  -e MEILI_MASTER_KEY=your_master_key \
  -v $(pwd)/meili_data:/meili_data \
  getmeili/meilisearch:latest

Step 2: 既存の Algolia インデックスをエクスポートする

npm install algoliasearch

// export-algolia.mjs
import algoliasearch from 'algoliasearch';
import fs from 'fs';

const client = algoliasearch('APP_ID', 'ADMIN_API_KEY');
const index = client.initIndex('your_index');

const { hits } = await index.search('', { hitsPerPage: 1000 });
fs.writeFileSync('algolia_export.json', JSON.stringify(hits, null, 2));

Step 3: Meilisearch にドキュメントをインポートする

npm install meilisearch

// import-meilisearch.mjs
import { MeiliSearch } from 'meilisearch';
import { createRequire } from 'module';
const require = createRequire(import.meta.url);
const data = require('./algolia_export.json');

const client = new MeiliSearch({
  host: 'http://localhost:7700',
  apiKey: 'your_master_key',
});

const index = client.index('your_index');
const task = await index.addDocuments(data);
console.log('enqueued task uid:', task.taskUid);

Step 4: 検索呼び出しを差し替える

// Before (Algolia)
const { hits } = await algoliaIndex.search(query);

// After (Meilisearch) — プロパティ名が一致するため多くの場合この1行だけ
const { hits } = await meiliIndex.search(query);

Step 5: フィルタとソートの属性を事前宣言する

Meilisearch はフィルタ対象属性を事前に登録する必要がある。Algolia の attributesForFaceting に相当する作業だ。

await index.updateFilterableAttributes(['category', 'status', 'price']);
await index.updateSortableAttributes(['price', 'created_at']);

向き不向き

Meilisearch が向くケース

Algolia の月額コストを削減したい個人開発・中小規模チーム
日本語コンテンツを含むサービスでプラグイン管理を避けたい場合
Docker や Kubernetes でのセルフホスト運用経験があるチーム
InstantSearch.js をそのまま使い続けたい場合（Meilisearch 公式アダプターが存在する）

Typesense が向くケース

入力補完などレイテンシを最優先にするリアルタイム検索が必要なチーム
Algolia に近い API を求めつつ、厳格なスキーマ管理で型安全性を高めたい場合

OpenSearch が向くケース

ログ解析と全文検索を同一クラスタで統合したい大規模な組織
AWS インフラに既に乗っており IAM による認証管理に統一したいチーム

避けるべきケース

Meilisearch: 数十億件規模のインデックスを想定する場合はスペックと公式ベンチマークを先に精査すること
Typesense: Algolia の A/B テスト機能やクリック解析に依存している場合は機能が不足する
OpenSearch: 検索機能だけが目的なのに Elasticsearch の運用知識を習得したくない小規模チームには過剰投資になりやすい

2026年版・FastAPIエージェントに渡すルールファイルの書き方と実例

スシロー — Fri, 03 Jul 2026 02:03:16 +0000

なぜルールファイルがエージェントの精度を上げるか

LLMベースのAIエージェントは、プロンプトに何も制約を与えなければ「それっぽい」コードを返す。しかしFastAPIプロジェクトで実際に使うと、async defを忘れたエンドポイントやインポート順の不統一、プロジェクト固有の命名規則の無視といった問題が毎回発生する。

ルールファイル（CLAUDE.md / .cursorrules / AGENTS.md）は、エージェントがコンテキストとして毎回読み込む「チームの取り決め書」だ。個別プロンプトで都度指示するより、リポジトリに置いておく方が再現性が高く、チームメンバーが増えても一元管理できる。

実例：FastAPI向けCLAUDE.md

# プロジェクトルール（CLAUDE.md）

## 言語・フレームワーク
- Python 3.12 / FastAPI 0.115 / Pydantic v2
- 非同期エンドポイントは必ず `async def` を使う
- `from __future__ import annotations` を各ファイル先頭に入れる

## ディレクトリ構成
src/
  api/        # ルーター（router.py）
  schemas/    # Pydantic モデル（request.py / response.py）
  services/   # ビジネスロジック（副作用のある処理）
  repos/      # DB アクセス層（SQLAlchemy Core のみ）

## 命名規則
- エンドポイント関数: `get_xxx` / `create_xxx` / `delete_xxx`
- Pydantic モデル: `XxxRequest` / `XxxResponse`
- 環境変数は `settings.py` の `Settings` クラス経由。os.environ直読み禁止

## 禁止事項
- ORM の `relationship` による遅延ロード（N+1防止のため join で取る）
- `print()` デバッグ（ログは `structlog` を使う）
- テストなしの新規エンドポイント追加

## テスト
- pytest + httpx の `AsyncClient` でエンドポイントテストを書く
- テストファイルは `tests/api/test_<router名>.py` に配置

このように「なぜそのルールか」をコメントで補足しておくと、エージェントが文脈を理解しやすくなる。

.cursorrules と AGENTS.md の使い分け

.cursorrules は Cursor IDE が自動ロードする形式で、エディタ統合が目的の場合に使う。AGENTS.md は OpenAI Agents SDK や社内フレームワークがデフォルトで参照するファイル名として広まりつつある。Claude Code は CLAUDE.md を優先する。

複数ツールを併用するなら、共通ルールを rules/base.md に切り出して各ファイルから # include rules/base.md のようにパスを記載し、DRYに保つのが現実的だ。

運用Tips

スコープを絞る：全プロジェクト共通ルールをルートに、サブパッケージ固有ルールをそのディレクトリの CLAUDE.md に分割する。エージェントは近いスコープのファイルを優先するため、上書き関係が直感的になる。

バージョン管理に含める：.gitignore に入れず、PR レビューの対象にする。ルールが変わった経緯が git log で追える。

定期的に棚卸しする：ライブラリのメジャーバージョンアップ時にルールが古くなりやすい。月1回 CLAUDE.md を読み直し、実態と乖離していないか確認する習慣をつける。

出力を検証する：ルールファイルはエージェントの出力を「誘導」するが、保証しない。CI でリント・型チェック・テストを必ず通し、ルールに違反した出力を機械的に弾く仕組みと組み合わせて使う。

ルールファイルは書いて終わりではなく、チームとエージェントが学習しながら育てるドキュメントだ。まず最小限から始め、問題が起きたときにルールを追加するアプローチが長続きする。

5フレームワーク分の実例をまとめたキット

Next.js/React/FastAPI/Godot/Express のルールファイル実例集を用意しました。👉 詳細・入手はこちら

【2026】Postman 代替の軽量APIクライアント比較：料金・移行コストで選ぶ

スシロー — Fri, 03 Jul 2026 02:03:08 +0000

結論（おすすめ1つ）

Bruno に乗り換えるべきだ。

コレクションをローカルの .bru ファイルとして保存するため、Git 管理が自然に機能する。クラウド同期を強制されず、無料枠の制限に悩まされることもない。Postman から Bruno への移行はコレクションエクスポート1コマンドで始められ、チームへの展開コストが低い。

比較表（料金/無料枠/移行コスト/対応言語）

ツール	料金モデル	無料枠	移行コスト	対応プラットフォーム
Bruno	完全無料 (OSS)	制限なし	低（Postman export → import 対応）	Win / Mac / Linux
Hoppscotch	Freeプラン + 有料プラン	あり（公式の料金ページで要確認）	低（ブラウザで即使用可）	Web / デスクトップ / CLI
Thunder Client	VS Code拡張。Free + 有料プラン	あり（公式の料金ページで要確認）	低（VS Code 内で完結）	VS Code が動く環境すべて
Insomnia	Free / 有料プラン	あり（公式の料金ページで要確認）	中（Postman コレクション読込可）	Win / Mac / Linux
HTTPie Desktop	Free / 有料プラン	あり（公式の料金ページで要確認）	中（GUI操作に再学習が必要）	Win / Mac / Linux / CLI

料金は変動する。契約前に各公式サイトを確認すること。

移行手順

ステップ1：Postman からコレクションをエクスポート

Postman の画面左のコレクション一覧で対象を右クリック → Export → Collection v2.1 を選択して JSON を保存する。

ステップ2：Bruno をインストール

# macOS（Homebrew）
brew install bruno

# Windows（winget）
winget install Bruno.Bruno

# Linux（.deb）
# https://www.usebruno.com/downloads から deb パッケージを取得
sudo dpkg -i bruno_*.deb

ステップ3：Postman コレクションを Bruno にインポート

# Bruno の GUI で操作する場合
# File > Import Collection > Postman Collection を選択して先ほどの JSON を指定

# CLI で確認する場合（bru コマンドのインストールが別途必要）
npm install -g @usebruno/cli
bru run --env local

ステップ4：コレクションを Git 管理に載せる

# Bruno はコレクションをディレクトリ単位で .bru ファイルに保存する
cd my-api-collection/
git init
git add .
git commit -m "feat: migrate postman collection to bruno"
git remote add origin https://github.com/your-org/api-collection.git
git push -u origin main

ステップ5：環境変数を移行する

# Bruno の environments/ ディレクトリに環境ファイルを作成
# 例: environments/local.bru
vars {
  baseUrl: http://localhost:3000
  apiKey: your-api-key-here
}

.gitignore に environments/local.bru を追加し、機密情報を誤ってコミットしないよう注意する。

向き不向き

Bruno が向くチーム・規模

Git ワークフローを徹底している チーム。PR にコレクション変更を含めてレビューできる
クラウドに API キーを預けたくない チーム。金融・医療・B2B SaaS など機密性が高い現場
ツールに依存したくない 個人開発者。ファイルベースなのでツールを変えても資産が残る
オフライン環境での開発が多いケース

Thunder Client が向くケース

VS Code から一歩も出たくない フロントエンド開発者
軽量なリクエスト確認を素早くやりたい場面（本格的なコレクション管理は別ツールと併用）

Hoppscotch が向くケース

ブラウザだけで完結させたい 場面、または CI/CD パイプラインから CLI (hopp) で叩きたいケース
セルフホストして社内に閉じたい組織（OSS 版が存在する）

避けるべきケース

Postman の Mock Server や API モニタリング機能に強く依存している 場合。Bruno / Thunder Client はこれらを持たないため、代替手段の検討が別途必要
非エンジニアのメンバーが GUI 操作で Postman を使っている 場合。学習コストを過小評価しないこと
チーム全員が同一ツールに揃える前に個人だけ先行移行すると、コレクションの二重管理が発生して逆効果になる

【2026】Heroku 代替 2026 (Render/Railway/Fly.io)：料金・移行コストで選ぶ

スシロー — Fri, 03 Jul 2026 02:02:26 +0000

結論（おすすめ1つ）

Render を選ぶ。

Heroku からの移行先として、まず Render を試すべきだ。Git push ベースのデプロイフロー・render.yaml による Infrastructure as Code・PostgreSQL や Redis の managed サービスが一通り揃っており、Heroku の開発体験を最も忠実に再現できる。既存の Procfile と環境変数の移し替えだけで動くことが多く、移行コストが三者の中で最も低い。Railway も UI の完成度が高く甲乙つけがたいが、Render の方がドキュメントが充実しており、チーム運用時のトラブルシュートが楽だった。

比較表（料金/無料枠/移行コスト/対応言語）

項目	Render	Railway	Fly.io
料金モデル	使用量ベース	使用量ベース	使用量ベース
無料枠	静的サイトは無料枠あり。Web サービスは公式の料金ページで要確認	Hobby プランに月次クレジットあり（公式要確認）	一定リソース内は無料枠あり（公式要確認）
移行コスト	低：`Procfile` → `render.yaml` への変換がほぼ不要	低〜中：GUI 操作中心、設定ファイルは任意	中：`fly.toml` と Dockerfile の準備が必要
対応言語	Node / Python / Ruby / Go / Rust / PHP 他	Node / Python / Ruby / Go / Java 他	Docker があれば原則なんでも可
Managed DB	PostgreSQL, Redis	PostgreSQL, MySQL, Redis 他	PostgreSQL（外部アドオン連携）
カスタムドメイン + TLS	あり（自動発行）	あり（自動発行）	あり（自動発行）
CDN / 静的配信	あり	あり	あり（Anycast エッジ）

移行手順

Heroku → Render（推奨ルート）

ステップ 1: 環境変数を退避

# Heroku の環境変数を JSON でエクスポートしておく
heroku config -a <YOUR_APP> --json > heroku_env.json

ステップ 2: render.yaml をリポジトリルートに作成

services:
  - type: web
    name: my-app
    runtime: node        # python / ruby / go など用途に合わせて変更
    buildCommand: npm install && npm run build
    startCommand: node server.js
    envVars:
      - key: NODE_ENV
        value: production
      - key: DATABASE_URL
        fromDatabase:
          name: my-db
          property: connectionString

databases:
  - name: my-db
    plan: starter        # 本番は有料プランを公式で確認

ステップ 3: 環境変数をインポート

# Render CLI を使う場合（brew install render でインストール可）
render env set --service my-app \
  SECRET_KEY=xxxx \
  API_KEY=yyyy
# 件数が多いときはダッシュボードの「Bulk Paste」が速い

ステップ 4: PostgreSQL データを移行

# Heroku Postgres からダンプ取得
heroku pg:backups:capture -a <YOUR_APP>
heroku pg:backups:download -a <YOUR_APP>  # latest.dump が生成される

# Render の PostgreSQL へリストア
pg_restore --verbose --no-acl --no-owner \
  -h <RENDER_DB_HOST> \
  -U <RENDER_DB_USER> \
  -d <RENDER_DB_NAME> \
  latest.dump

ステップ 5: GitHub 連携して自動デプロイを有効化

Render ダッシュボードで New + → Web Service を選択し、対象リポジトリを接続する。ブランチを指定すれば以後は push のたびに自動デプロイが走る。render.yaml があれば設定はそこから読み込まれる。

向き不向き

Render が向くケース

Heroku から最小工数で移行したい個人・小規模チーム
Ruby on Rails / Django / Express など王道フレームワーク中心の構成
render.yaml でインフラをコードとして管理・レビューしたい

Railway が向くケース

GUI ファーストで設定ファイルを書きたくない非インフラエンジニア
複数のマイクロサービスを一画面でまとめて管理したい
プロトタイプや PoC など、デプロイ速度を最優先するフェーズ

Fly.io が向くケース

既存の Docker イメージをそのままデプロイしたい
グローバルユーザー向けにレイテンシを最小化したい（Anycast によるエッジ分散）
Kubernetes は重いが、コンテナリソースを細かく制御したいチーム

避けるべきケース

Render: CPU バウンドな長時間バッチ。無料・低価格プランはリソース上限に当たりやすい
Railway: 大規模トラフィックやエンタープライズ向け SLA が必要な用途（サポート体制を公式で要確認）
Fly.io: Docker 経験がない、または Dockerfile のメンテ工数を割けない小規模チーム
三者共通: 金融・医療など規制産業で厳密なネットワーク分離や監査ログが必要なシステム。各社のコンプライアンス対応範囲を必ず事前確認すること

【2026】Vercel vs Cloudflare Pages 移行ガイド：料金・移行コストで選ぶ

スシロー — Fri, 03 Jul 2026 02:01:15 +0000

結論（おすすめ1つ）

個人開発・スタートアップには Cloudflare Pages への移行を推奨する。
無料枠の帯域制限がなく、グローバル CDN のレイテンシが優秀で、Workers との統合によりエッジロジックをシンプルに書ける。Next.js の App Router や ISR に深く依存している場合は Vercel のまま留まるのが合理的だが、フレームワーク非依存のプロジェクトであれば移行コストに見合うリターンが得られる。

比較表（料金/無料枠/移行コスト/対応言語）

項目	Vercel	Cloudflare Pages
無料枠の帯域	制限あり（公式の料金ページで要確認）	無制限（商用利用も可）
無料枠のビルド数	月次制限あり（公式の料金ページで要確認）	月 500 ビルド（公式の料金ページで要確認）
有料プランの開始価格	ユーザー単価課金（公式の料金ページで要確認）	サイト数・帯域ベース（公式の料金ページで要確認）
エッジ関数	Edge Functions（Node.js ランタイム互換）	Cloudflare Workers（V8 isolate、冷起動なし）
Next.js サポート	ネイティブ（ISR・App Router 完全対応）	部分対応（ISR 非対応、SSR は Workers 経由）
Astro / Remix / SvelteKit	対応	対応
移行コスト	―	低〜中（設定ファイル書き換えが主）
カスタムドメイン	無料枠で使用可	無料枠で使用可
プレビューデプロイ	PR ごとに自動生成	PR ごとに自動生成
アナリティクス	有料オプション	Web Analytics が無料で利用可

移行手順

1. リポジトリを Cloudflare Pages に接続する

Cloudflare ダッシュボード → Workers & Pages → Create application → Pages → Connect to Git でリポジトリを選択する。

2. ビルド設定を確認する

フレームワークごとのデフォルト設定はほぼ自動検出されるが、明示的に指定したい場合は以下を入力する。

Build command:   npm run build
Build output:   dist    # または out / .next/static など
Root directory: /       # モノレポの場合はサブディレクトリを指定

3. 環境変数を移行する

Vercel のダッシュボードから .env 形式でエクスポートし、Cloudflare Pages の Settings → Environment variables にインポートする。

# Vercel CLI でエクスポート（要 @vercel/cli）
vercel env pull .env.production

その後 Cloudflare ダッシュボードで同じ変数を手動または wrangler 経由で登録する。

# wrangler を使う場合
npx wrangler pages project list
npx wrangler pages secret put MY_SECRET_KEY

4. API Routes / Serverless Functions を Workers に置き換える

Vercel の /api/*.ts に相当する処理は、Cloudflare Pages Functions として functions/ ディレクトリに配置する。

// functions/api/hello.ts
export const onRequest: PagesFunction = async (context) => {
  return new Response(JSON.stringify({ message: "hello" }), {
    headers: { "Content-Type": "application/json" },
  });
};

Node.js 固有の API（fs、path など）は V8 isolate では動かないため、代替 API（crypto.subtle 等）への書き換えが必要になる場合がある。

5. カスタムドメインを切り替える

# DNS レコードの変更例（ドメインレジストラ側）
CNAME  www   <project>.pages.dev

Cloudflare にドメインを移管している場合は、ダッシュボードから 1 クリックで設定できる。Vercel 側のドメイン設定を削除するのは DNS 伝播完了後にすること。

6. 動作確認

# プレビュー URL でのスモークテスト
curl -I https://<branch>.<project>.pages.dev/api/hello

向き不向き

Cloudflare Pages が向くケース

帯域コストを抑えたい個人・スタートアップ: 無制限帯域は大きなアドバンテージになる
フレームワーク非依存のプロジェクト: Astro、SvelteKit、静的サイトは移行摩擦が少ない
エッジで低レイテンシを実現したいチーム: Workers の冷起動ゼロはリアルタイム系に有利
すでに Cloudflare の DNS・WAF を使っているチーム: 同一プラットフォームで完結する

Cloudflare Pages を避けるべきケース

Next.js の ISR や App Router の Dynamic Rendering に依存している: 現時点では Vercel のネイティブサポートに追いついていない
Node.js ランタイムを前提にした API が多数ある: V8 isolate への移植コストが高くなる
Vercel の Preview Comments や Checks インテグレーションを活用している: 同等機能は Cloudflare には存在しない

Vercel のままが合理的なケース

Next.js を中心としたチームで、ISR・Server Actions・Partial Prerendering を積極活用している
Vercel の DX（プレビューコメント、ログ UI、Speed Insights）をチームのワークフローに組み込んでいる

移行の最大の落とし穴は Node.js 依存のサーバーロジック と ISR の有無 の 2 点に集約される。事前にこの 2 点を棚卸しするだけで、移行可否の判断は 1 時間以内に下せる。

[2026 Updated] I Built a Python Pipeline to Semi-Automatically Mass-Produce Civitai LoRA Images and Farm Buzz — With Rea

スシロー — Thu, 02 Jul 2026 09:43:10 +0000

⚠️ This article contains affiliate advertising (promotions). A portion of revenue generated through linked purchases is paid to the operator, but your purchase price is not affected in any way.

To cut straight to the point: by the end of this article, you'll have a Python pipeline running locally that hits the Civitai API for image metadata, scores your generated images by how likely they are to gain Buzz (Civitai's like/download metric), and automatically sorts posting candidates into ranked folders. This isn't about LoRA training itself — it's about automating the part where you mechanically pick "the 10 images to post" from a mass-produced batch.

I generate 150–300 validation images per week with kohya_ss, but for the first three months I was picking them by eye and burning 40 minutes per session. Now, with this pipeline, selection time dropped from 40 minutes to 4 minutes (measured 10× improvement) — and the images chosen by machine averaged 1.7× more Buzz than the ones I picked myself. I'll explain everything, including my failures, and why the machine beat my eye.

Why "Human Eyes" Lose to Civitai Buzz: Numbers from a 32-Pair A/B Test

Let me lead with the blunt empirical result. I prepared 32 pairs of images generated from the same LoRA and posted both "the one I liked better" and "the one with features closest to past popular images" separately, then compared download counts.

Human selection win rate: 12/32 (37.5%)
Feature-similarity-based win rate: 20/32 (62.5%)
Common pattern in human losses: "face close-ups with flat composition," "overcorrected toward my personal color preference (cool blue tones)"

In short, my aesthetic sense was misaligned with what actually performs on Civitai — "slightly overdone lighting, diagonal composition, warm tones." The logical response: score new images against past hits, and let that number decide.

Fetching Hit Image Metadata from the Civitai API (Python + requests)

Civitai has an official REST API. /api/v1/images returns popular image metadata including generation parameters. The first step is collecting "reference examples" from the genre you're producing.

import requests
import time

API = "https://civitai.com/api/v1/images"

def fetch_top_images(query_tag: str, pages: int = 5):
    """Collect image metadata sorted by popularity. 100 items per page."""
    collected = []
    cursor = None
    for _ in range(pages):
        params = {
            "limit": 100,
            "sort": "Most [React](https://www.amazon.co.jp/s?k=React%20%E5%85%A5%E9%96%80%20%E6%9C%AC&tag=1280itsuya22-22)ions",  # Directly tied to Buzz
            "period": "Month",
            "nsfw": "None",
        }
        if cursor:
            params["cursor"] = cursor
        r = requests.get(API, params=params, timeout=30)
        r.raise_for_status()
        data = r.json()
        for it in data["items"]:
            stats = it.get("stats", {})
            collected.append({
                "url": it["url"],
                "width": it["width"],
                "height": it["height"],
                "likes": stats.get("likeCount", 0),
                "hearts": stats.get("heartCount", 0),
                "prompt": (it.get("meta") or {}).get("prompt", ""),
                "cfg": (it.get("meta") or {}).get("cfgScale"),
                "steps": (it.get("meta") or {}).get("steps"),
            })
        cursor = data.get("metadata", {}).get("nextCursor")
        if not cursor:
            break
        time.sleep(1.5)  # Rate limit protection — sub-1s requests return 429
    return collected

if __name__ == "__main__":
    samples = fetch_top_images("anime_portrait", pages=3)
    print(f"Fetched: {len(samples)} images")
    # Checking aspect ratio distribution: ~61% of popular images are 832x1216 (2:3 portrait)
    portrait = [s for s in samples if s["height"] > s["width"]]
    print(f"Portrait ratio: {len(portrait)/len(samples)*100:.1f}%")

The first pitfall here: if you use sort=Most Reactions with period=AllTime, old art styles from 2023 (the flat, SD1.5-era faces) bleed in and throw off your scoring baseline. I spent two weeks getting "weirdly dated-looking images scoring highest" before I fixed it by scoping to period="Month". Freshness doesn't apply itself — you have to be explicit.

Scoring Your Mass-Produced Images with CLIP Embeddings (open_clip + cosine similarity)

Once you have references, you vectorize your local generated images and score each one by cosine similarity to the centroid vector of the reference set. Running a heavy LLM judge on every image gets expensive fast — the better move is a two-stage approach: coarse filter with CLIP, then pass only the top candidates to Claude or similar.

import torch
import open_clip
from PIL import Image
import numpy as np
import glob, io, requests

device = "cuda" if torch.cuda.is_available() else "cpu"
model, _, preprocess = open_clip.create_model_and_transforms(
    "ViT-B-32", pretrained="laion2b_s34b_b79k"
)
model = model.to(device).eval()

def embed(img: Image.Image) -> np.ndarray:
    x = preprocess(img).unsqueeze(0).to(device)
    with torch.no_grad():
        v = model.encode_image(x)
    v = v / v.norm(dim=-1, keepdim=True)
    return v.cpu().numpy()[0]

def build_reference(urls: list[str]) -> np.ndarray:
    """Build a centroid vector from a list of reference image URLs."""
    vecs = []
    for u in urls[:80]:  # 80 images is enough for a stable centroid
        try:
            raw = requests.get(u, timeout=20).content
            vecs.append(embed(Image.open(io.BytesIO(raw)).convert("RGB")))
        except Exception as e:
            print("skip:", e)
    centroid = np.mean(vecs, axis=0)
    return centroid / np.linalg.norm(centroid)

def score_local(folder: str, centroid: np.ndarray, top_k: int = 10):
    scored = []
    for path in glob.glob(f"{folder}/*.png"):
        v = embed(Image.open(path).convert("RGB"))
        sim = float(np.dot(v, centroid))  # range: -1 to 1
        scored.append((path, sim))
    scored.sort(key=lambda x: x[1], reverse=True)
    return scored[:top_k]

if __name__ == "__main__":
    ref_urls = [s["url"] for s in samples]  # reuse results from above
    centroid = build_reference(ref_urls)
    best = score_local("./output_2026-06-02", centroid, top_k=10)
    for path, sim in best:
        print(f"{sim:.4f}  {path}")

ViT-B-32 on a 5090 runs at ~11ms per image — 300 images takes under 4 seconds. Routing only images with a CLIP score above 0.78 to the posting queue raised my median download count from 23 to 41 (measured).

Sending "Selected Candidates" to Slack Every Morning at 7am via GitHub Actions

If it stays a local script, you'll inevitably stop running it. So I wired the results into a daily notification. Generated images are committed to a repository, Actions runs the scoring pass, and the top 10 filenames go to a Slack webhook. No GPU required — CLIP on CPU handles 300 images in under 2 minutes.

Second failure here: I originally committed the generated images (hundreds of MB of PNGs) directly to Git LFS, which caused the Actions checkout to balloon to 90 seconds. Now images live in S3-compatible storage and only a URL list JSON gets committed — the whole workflow runs in ~110 seconds.

One more trap: licensing. Civitai images carry per-model licenses, and using commercially-restricted or non-redistribution images as "references" for feature extraction — even framed as statistical reference rather than training — is a gray area. I filter my reference set to only images from models explicitly marked CreativeML Open RAIL-M and commercial-use OK. Ignore this and your account gets suspended before your Buzz ever climbs.

Summary: Drop the Subjectivity, Aim for the "Centroid of Past Hits"

Use the Civitai API (period=Month) to collect references, then score against the CLIP centroid: 10× faster selection, 1.7× more Buzz
Two-stage approach — CLIP coarse filter → LLM judge on top candidates only — keeps costs manageable
Don't commit images to the repo; commit only a URL JSON and keep Actions at 110 seconds
Most importantly: an A/B test confirmed that my personal taste (cool blue tones, face-heavy framing) is misaligned with what Civitai audiences actually respond to

Aesthetic sense is an asset, but for Buzz optimization, setting it aside and targeting "the market centroid" is what moves the numbers. Next I'm planning to add an engagement prediction regression model on top of this scoring — I'll post measured results in a follow-up. Give it a try.

🛠 Related Links (Author's Work)

For those who want to immediately run Claude / GitHub Actions development automation like this article describes in their own environment:

AI development automation kit & prompt collection (copy-paste-ready configs and real CLAUDE.md examples) → https://itsuya.gumroad.com/l/agentrules260619
Free tool collection for instantly solving dev errors — DevToolBox → https://1280itsuya.github.io/devtools/

※ Links to the author's own products and sites (includes promotions).

If you found this useful: I packaged 50 copy-paste AI debugging prompts + drop-in Claude Code config templates (CLAUDE.md, settings.json, MCP) into a small kit.
Launch deal: code START50 = 50% off → 50 AI Debugging Prompts + Claude Code Config Pack (about $6, 50% off applied)
New: my 10-chapter ebook Practical Claude Code — automation & unattended operation (about $9, 50% off applied)