LogoCreatorは、Together AIの画像モデルでブランドロゴを生成し、ブランドキットまで書き出せるNext.js製のWebアプリだ。GitHubスターは8,400で、公式ホスト版が logo-creator.io で動いている。この手の「AIロゴジェネレーター」は無数にあるが、実装が丸ごと読めるものは多くない。

そしてソースを読んでみると、READMEに書かれている技術スタックと実装が2箇所で食い違っていた。さらにコード内コメントには、画像モデルに言うことを聞かせるための試行錯誤が、日付と比較結果つきで残っていた。この記事ではリポジトリをcloneして、その中身を確認する。数値・引用はすべて2026年8月23日時点の実測である。

LogoCreatorの全体像。READMEと実装の食い違い2箇所、LICENSEファイルが全履歴で不在、コミット数の月別推移
リポジトリをcloneしてコードとgit履歴を確認した全体像（出典: Nutlope/logocreator・2026-08-23時点）
30秒でわかる LogoCreator（2026年8月23日時点）
  • ・正体：Together AIの画像モデルでロゴを作るNext.js（App Router）製Webアプリ。★8,400。
  • ・実装の要：ロゴ種別で3つのモデルを投げ分ける。文字入りはGoogleのflash-image-3.1、文字なしはFLUX.2-pro。
  • ・READMEとの差：READMEは「生成FLUX.2 pro／編集FLUX.1 Kontext」だが、Googleモデルへの言及が無く、編集も実際はFLUX.2-pro。
  • ・学べること：hexに色名を添える、否定形を使わない、背景の平坦さを明示する——プロンプト設計の理由がコメントに残っている。
  • ・注意：LICENSEファイルが全123コミットの履歴で一度も存在しない。「オープンソース」を名乗るが再利用の許諾は明示されていない。

この記事では画像生成モデルを使うアプリの実装としてLogoCreatorを扱います。モデル本体の仕組みや量子化・ローカル実行の基礎は LLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版 をご覧ください。

LogoCreatorとは——アカウント不要のAIロゴ生成をNext.jsで実装したOSS

READMEの説明は1行で、「ブランドに使えるロゴを数秒で設計し、ブランドキットとして書き出せる、無料でアカウント不要のオープンソースAIロゴ生成器」とある。構成はこうだ。

層 採用技術
フレームワーク Next.js（App Router）+ TypeScript
UI Radix UI プリミティブ + Tailwind CSS
画像生成 Together AI 経由の各種モデル（後述）
参照画像の読み取り meta-llama/Llama-4-Maverick-17B-128E-Instruct-FP4（Vision）
レート制限（任意） Upstash Redis
認証（任意） Clerk
生成API Edge Runtime

Upstash と Clerk は任意で、無い場合はアカウントレスのBYOK（利用者が自分のAPIキーを持ち込む）方式で動く、とREADMEに明記されている。実際に .env.example に必須なのは TOGETHER_API_KEY だけだ。

手元で動かす

セルフホストの手順はREADMEの通りで、必要なのはNode 20.9以上とpnpm、そしてTogether AIのAPIキーだけになる。

# 1) 取得して依存を入れる
git clone https://github.com/Nutlope/logocreator
cd logocreator
pnpm install

# 2) APIキーを設定する（Clerk / Upstash は任意なので空でよい）
cp .env.example .env.local
# .env.local を開いて TOGETHER_API_KEY= に自分のキーを入れる

# 3) 起動する
pnpm dev

.env.example に並ぶ5つの変数のうち、UPSTASH_REDIS_REST_URL / UPSTASH_REDIS_REST_TOKEN はレート制限、NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY / CLERK_SECRET_KEY は認証用で、いずれも未設定のまま起動できる。

開発は「2024年に作られ、2026年に作り直された」

git履歴を見ると、このリポジトリは連続して開発されてきたわけではない。

# 月別のコミット数を数える
git log --format="%ad" --date=format:"%Y-%m" | sort | uniq -c

結果は、2024年10月に20コミット、11月に52コミットで一気に作られたあと、2025年は年間4コミットでほぼ停止。そして2026年6月から8月にかけて47コミットが集中している。最新コミットは2026年8月3日の「Merge pull request #26 from Luffixos/v2」で、v2としての作り直しだったことが分かる。全123コミット。

この経緯は記事を読むうえで重要になる。READMEと実装の食い違いは、v2で中身を入れ替えたときにREADMEが追随しなかった結果と読めるからだ。

読者の3つの問いへの答え
① 何ができる：ロゴ生成・編集・ブランドキット書き出しをTogether AI経由で行うWebアプリを、自分の環境に丸ごと立てられる。② 何を解決する：画像生成アプリを作るときの「プロンプトの組み立て方」「モデルの投げ分け」「APIキーの守り方」が実例として手に入らない問題。③ 何を代替できる：有料のAIロゴサービスを自分のキーで代替できる。ただしライセンスが無いため事業への転用は代替にならない——後述。

READMEと実装が食い違う——文字入りロゴはGoogleのモデルへ行く

READMEの「Tech stack」節はこう書いている。

・FLUX.2 pro on Together AI for generation, with FLUX.1 Kontext for edits

ところが app/api/generate-logo/route.ts の実際のリクエスト構築はこうなっている。

ロゴ種別によるモデル投げ分け。文字ありはflash-image-3.1、429なら再試行、最後はFLUX.2-proへフォールバック
generate-logo と edit-logo のモデル選択（出典: app/api/generate-logo/route.ts・app/api/edit-logo/route.ts）
ロゴ種別 文字を含むか 実際に呼ばれるモデル
icon-name（アイコン＋社名） 含む google/flash-image-3.1
wordmark（ワードマーク） 含む google/flash-image-3.1
monogram（モノグラム） 含む google/flash-image-3.1
emblem（エンブレム） 含む google/flash-image-3.1
icon（アイコン単体） 含まない black-forest-labs/FLUX.2-pro（guidance: 7）
abstract（抽象マーク） 含まない black-forest-labs/FLUX.2-pro（guidance: 7）
ロゴの編集 — black-forest-labs/FLUX.2-pro
READMEにGoogleのモデルは1文字も出てこない。だが文字入りロゴ——つまり多くの利用者が最初に作る「アイコン＋社名」——は、実際にはGoogleのモデルで生成されている。

切り替えた理由はコメントに書かれている

なぜ変えたのかも、コードのすぐ上に理由が残っている。要約するとこうだ。

・文字を含む種別は社名を1文字ずつ埋め込む必要があり、Gemini Flash Imageは文字描画が確実で、「モノグラムにする」といった構造指示への追従もIdeogramより良く、レイテンシはIdeogramの約半分だった。2026年7月10日の横並び比較で選定した
・文字を含まないマーク（アイコン・抽象）は、仕上がりの洗練度でFLUX.2-proが依然として勝つのでそのまま残している
・編集については、2026年7月13日の比較で FLUX.1-kontext の pro も max も入力画像をほとんど変えずに返してきたのに対し、FLUX.2-pro は指示された編集（全角大文字化・色替え・ロックアップの再配置・非正方形サイズ）を実際に適用した。しかも安い（1枚あたり $0.03 対 $0.04）

READMEが古いのは事実だが、コード側には「いつ・何と比べて・なぜ選んだか」が残っている。この種の記録がある実装は珍しく、モデル選定の判断材料としてそのまま読む価値がある。

Together上での実測制約もコメントにある

同じコメント群には、Together AI上で実際に叩いて分かった制約も並ぶ。2026年7月13日時点の記録として、flash-image-3.1 は正方形のみ（512 / 1024 / 2048 / 4096）、image_url 入力を受け付けない、JPEGバイトを返す、バーストに対するレート制限が厳しい、と書かれている。コード内のガード群はこの制約に対応するために存在する、という説明もついている。

FLUX.2-pro側については、guidance パラメータは受け付けるが steps は受け付けないことを実際に確認した、とある。ブランドマークではプロンプトと色への追従を強めたいので guidance: 7 を指定する、という判断だ。

レート制限への対処も具体的だ。文字入り生成が429で失敗した場合、1,200〜2,000ミリ秒のランダムな間隔を空けて1回だけ再試行し、それでも駄目ならFLUX.2-proへ落とす。コメントは「文字の描画は弱くなるが、バッチの途中でエラーを出すよりはロゴが出るほうがまし」と理由を書いている。

プロンプト設計の知見がコメントに残っている

このリポジトリの最大の学習価値は、画像モデルに意図通り描かせるための工夫が、すべて理由つきでコメント化されている点にある。

プロンプト設計の5つの工夫。色名を添える、否定形を使わない、hexを部位に紐づける、背景の平坦さを明示、媒体を指定
ソースコメントに残っていたプロンプト設計の判断（出典: app/api/generate-logo/route.ts）

hexコードは色名を添えて渡す

generate-logo/route.ts の冒頭には、24色の色名とRGB値のテーブル（NAMED_COLORS）が置かれている。white / black / gray / crimson / amber / lime / emerald / teal / sky blue / navy / indigo / magenta / brown など、日常語として通る色名だけが並ぶ。

利用者が選んだhexは colorName() でユークリッド距離が最小の色名に変換され、プロンプトには blue (exact hex #2F6FF5) の形で入る。コメントの理由はこうだ——「モデルは裸のhexよりも『blue (#2F6FF5)』のほうがはるかに確実に従う。これはカラーピッカーで選ばれた任意の色にも効く」。

任意の色をユーザーに選ばせるUIを持ちながら、モデルには常に「よく知っている色名」を添えて渡す。カラーピッカーを持つ画像生成アプリなら、そのまま流用できる考え方だ。

「no text」と書かず、肯定形で描写する

文字を含まないロゴを作るとき、素直に書けば「テキストなし」と指示したくなる。だがこのコードはそうしていない。

代わりに「文字が入るはずだった場所を、きれいな図形と余白で構成した純粋な図的シンボルとして描く」という趣旨の肯定形の文を入れる。コメントは理由を「FLUXは記述したものに注意を向けるのであって、禁止には向かない。だから『no text』は禁止でなく図形のみの描写として述べる」と説明している。

否定形を肯定形に書き換えるのは画像生成プロンプトの基本則として語られるが、実装のどこで、どんな文面に置き換えているかまで読める例は貴重だ。

hexは「ブランドカラー」でなく具体的な部位に結ぶ

色の指定文も工夫されている。「ブランドカラーは青」という抽象的な役割で渡すのではなく、ロゴのどの部分がその色なのかを名指しする。ロゴ種別ごとに対象が定義されていて、icon-name なら「アイコンと社名テキストの両方」、emblem なら「シンボルと文字と枠線」といった具合だ。

コメントは、これがBlack Forest Labs（FLUXの開発元）のガイダンスに沿ったものだと書いている——hexコードは具体的な対象に紐づけたときに最もよく保持される。

平坦なスタイル（Minimal・Geometric・Luxury・Mascot・Hand-drawn・Retro）では「すべての塗りは単色で平坦」と指定し、3DとGradientのときだけ「同じ色の明暗による奥行きは可」と緩める分岐も入っている。

参照ロゴのアップロードは「真似させない」ように設計されている

既存ロゴを参考にしたいという要望に応える機能もあるが、その実装は模倣を防ぐ方向に制約が掛かっている。app/api/read-reference/route.ts はアップロードされた画像をVisionモデル（meta-llama/Llama-4-Maverick-17B-128E-Instruct-FP4）に渡し、JSONだけを返させる。プロンプトの要求はこの4項目だ。

・description：マークの構成・形・モチーフ・全体の雰囲気を240字以内の1文で。ただし社名を述べたり、ロゴ内の文字を書き起こしたりしてはいけない
・styleGuess：8つのスタイル定数のうち、最も近い1つを厳密に選ぶ
・dominantColor：最も目立つブランドカラーを6桁hexで。グレースケールや多色で支配色が無ければ "auto"
・keywords：短い形容詞を3〜6語の配列で

「社名と文字を書き起こすな」という制約が効いていて、返ってくるのは文字情報を落とした形の記述になる。これを生成プロンプトへ渡す側でも「この参照の構成・形・全体の雰囲気からインスピレーションを得つつ、コピーではなくオリジナルのマークを設計せよ」という一文で包んでいる。

参照画像機能は「似せる」実装にも「似せない」実装にもできる。このリポジトリは後者を選び、Vision側とプロンプト側の二重で制約を掛けている。

背景の「完全な平坦さ」が後段の処理を守っている

もうひとつ、実装上の依存関係が明かされているのが背景の指定だ。プロンプトには毎回「完全に均一で平坦な単色の背景。フレーム全体で一様で、ヴィネット・グラデーション・影・テクスチャは無し」という文が入る。

理由は美観ではない。コメントいわく、FLUXはマークの背後に微妙なヴィネットや柔らかいグラデーションを足したがるが、それが入るとブランドキット書き出し時の「端からのflood-fillによる背景除去」が壊れるからだ。実際 app/hooks/use-brand-kit.ts は透明化した結果の透明率を測り、6%を超えたかどうかでSVG化の経路を切り替えている。

プロンプトの1文が後段の画像処理パイプラインの前提条件になっているという構造で、生成AIをアプリに組み込むときの依存の作り方として参考になる。

スタイルの説明文に色を入れない

styleLookup には8つのスタイル（Minimal / Geometric / Gradient / Mascot / Hand-drawn / Luxury / Retro / 3D）の説明文が並ぶが、どれも形と技法しか書いていない。コメントに理由がある——「スタイルは形式と技法のみを記述する。色はユーザーのブランドカラーから来るので、『手描き風の青いロゴ』がセピア色になったりしないように」。

同様に、平坦なスタイルでは「Flat 2D vector logo, built from solid-color shapes with crisp, clean edges」という媒体の指定を先頭に置く。これを書かないと Minimal / Geometric / Luxury が陰影付きや写真的な仕上がりで返ってくる、と実測が書かれている。文字を含む種別の場合は Google のモデルが担当するが、この媒体指定は共通で入る。日本語を含む文字描画そのものの精度を比較したい場合は Qwen-Image完全ガイド：日本語ポスター・UIの文字描画が最強のオープンウェイトT2Iモデル解説 が参考になる。

ブランドキット書き出しは、生成のあとの「もう半分」

LogoCreatorがオープンソース ロゴ生成ツールとして単なるデモに留まっていないのは、生成した画像をそのまま使える資産に変換する後段を持っているからだ。app/lib/svg-export.ts と app/hooks/use-brand-kit.ts を読むと、ここも実装判断がコメント化されている。

工程 実装
背景のキーイング 画像の不透明な四隅だけをサンプリングして背景色の基準を作る。透明な角のRGBはたいてい (0,0,0) で、基準を黒へ引っ張ってしまうため
許容幅 判定の許容値は広めに取る。「ノイズを含む白」はかなりばらつくため
SVG化 imagetracerjs でオンデバイスにトレースする。pathomit: 24 で微小パスを落とし、背景のスペックルを消す
読み込み方 imagetracerjs は約3.2MBあり、SVG書き出しをクリックしたときにしか要らないので遅延読み込みして初期バンドルから外す
透明背景の維持 透明入力（ブランドキットの切り抜き）は、白ではなくクロマキー色に一度フラット化してからトレースし、キー色のレイヤーを除去する。こうすると背景の矩形が焼き付かず、文字の「アナ」（counter hole）も本物の穴として残る
アルファの扱い アンチエイリアスの半透明ピクセルが背景と混ざらないよう、アルファをハードエッジ化してからトレースする
出力の形 <svg viewBox="0 0 w h"> を固定の width/height 無しで出力する。ファビコン枠にもCSSサイズ指定の <img> にも印刷用紙にも、そのまま伸縮できるように

「自動トレースであって手描きのベクターではない」ことを正直にラベル表示するというコメントもある。スケールには耐えるがデザイナー品質のパスではない、という但し書きだ。生成AIの出力を製品に組み込むときの表示の誠実さとして、参考になる姿勢だと思う。

さらに、AIによる商品モックアップ生成では明るいロゴには暗い面を割り当てる分岐が入っている。白いロゴを白い名刺や白い壁に印刷すると見えなくなるため、という理由がコメントに書かれていた。生成物のプレビューまで含めて、実際に使われる場面を想定した作りになっている。

LogoCreatorの費用防御——APIキーを枯らさないための多層構造

自分でデプロイする側にとって現実的な関心は「公開したらAPIキーが溶けないか」だろう。このリポジトリはそこに複数の層を入れている。

無防備なデプロイとの対比。401拒否、atomic INCR、偽装できないIPヘッダ、data URLのみ許可
各APIルートに実装された費用・悪用防御（出典: app/api/ 配下の各route.ts）
防御 実装
無防備な本番デプロイの拒否 NODE_ENV === "production" かつ BYOKキー無し・Clerk無効・Upstash無しなら401を返し、オーナーのサーバーキーを使わせない。ローカル開発では適用しない
無料枠の超過防止 署名済みユーザーの消費はRedisの INCR で原子的に行う。並列の派生リクエストが枠を超過できない
失敗時の返却 生成が失敗したら DECR で消費分を戻す
匿名利用者の識別 x-vercel-forwarded-for（プラットフォーム由来で呼び出し側が偽装できない）でIPを取る。コメントに「偽装された x-forwarded-for では効かない」と明記
画像入力の制限 編集・参照読み取りはインラインのdata URLのみ受け付け、任意の http / file URLを拒否する。「そうしないとモデル側のバックエンドが我々の代わりにサーバーサイドでそのURLを取りに行ってしまう」
ペイロード上限 編集は約5MB、参照読み取りは約4MBで打ち切る

無料枠の定数は app/lib/credits.ts にあり、FREE_CREDITS = 2（1クレジット＝画像1枚）。コメントは「この配分は一度きりの歓迎ギフトであって、補充される枠ではない。補充するとオーナーのキーが遅い蛇口になってしまう」と設計意図を書いている。

SSRF対策が本気で書かれている

最も作り込まれているのは app/api/import-brand/route.ts だ。これはウェブサイトのURLからブランド名・アクセントカラー・既存ロゴを引いてフォームを埋める機能で、AIもクレジットも使わない純粋なHTML/メタデータ解析だが、外部URLを取りに行く以上SSRFの入口になる。

そこで、ループバック・プライベート・リンクローカル・クラウドメタデータの各ホストを拒否する判定が実装されている。しかもIPv4リテラルだけでなく、

・IPv6のループバック・ユニークローカル・リンクローカル
・:: 圧縮とドット付きIPv4末尾を含むIPv6リテラルの展開
・IPv4-mapped（::ffff:/96）・NAT64（64:ff9b::/96）・6to4（2002::/16）が埋め込むIPv4の抽出
・リダイレクト後のURLに対する再チェック

まで扱う。169.254.x.x（リンクローカル＋クラウドのメタデータエンドポイント）を明示的に弾いているのも実務的だ。加えて、候補アイコンごとのタイムアウトとリクエスト全体の予算が設定されていて、クライアントが15秒で中断したあともサーバーが働き続けないようにしている。

自分のプロジェクトに移植するなら
「ユーザーが入力したURLをサーバーが取りに行く」機能は、AI機能の有無に関係なくSSRFの典型的な入口になる。IPv4のプライベートレンジだけを弾く実装では不十分で、IPv6のマッピング経路とリダイレクト後の再チェックが抜けやすい。このファイルはその2点を両方カバーしているので、実装例として読む価値がある。

ライセンスが無い——「オープンソース」を名乗るリポジトリの注意点

最後に、使う前に必ず確認しておきたい点がある。このリポジトリにはライセンスファイルが無い。

ライセンスの実測。全123コミット中LICENSEが存在したコミットは0、package.jsonとREADMEにも記載なし、スターは8,400
全履歴を走査した結果（出典: git log --all --diff-filter=A による確認・2026-08-23時点）

READMEに書かれていないだけ、という可能性を潰すために全履歴を走査した。

# LICENSE 相当のファイルが「追加された」コミットを全履歴から探す
git log --all --diff-filter=A --name-only --format="%h %ad" --date=short \
  -- '*LICENSE*' '*COPYING*'
# → 出力なし（一度も存在しない）

# 追跡ファイル全体を確認する
git ls-files | grep -i "licen\|copying"
# → 出力なし

結果は、123コミットのどの時点にもLICENSE/COPYINGファイルが存在しない。package.json に license フィールドは無く（"private": true のみ）、READMEにもライセンスの記載は無い。

ライセンスが明示されていないコードは、既定では著作権者に権利が留保される。クローンして読む・手元で動かすのは実務上問題になりにくいが、フォークして自社サービスとして提供する、コードを取り込んで再配布するといった用途は、作者に確認するまで許諾されていると考えるべきではない。「An open source AI logo generator」と自称していても、OSIの定義を満たすライセンスが付いていない状態はそれとは別問題だ。

なお、これはこのリポジトリ特有の話ではない。同じ作者（Nutlope）の他のリポジトリを見ると、hallmark や llamacoder、aicommits のようにMITが明示されているものと、llama-ocr・llamatutor・turboseek のようにライセンス表記が無いものが混在している。Together AIのデモアプリ群という性格上、ライセンス整備が一律ではないと理解しておくのが実態に近い。

学習用途としての価値は変わらない

ライセンスの話は再利用の可否についてのものであって、このリポジトリの学習価値を下げるものではない。むしろ、モデル選定の比較記録・プロンプト設計の理由・費用防御の設計判断がここまで残っているコードベースは多くない。画像生成をアプリに組み込む予定があるなら、app/api/generate-logo/route.ts の1ファイルを読むだけでも得るものがある。

同種の生成AIツールをローカル側で組み立てたい場合は、ノードベースで組む ComfyUI カスタムノード入門2026｜ComfyUI Managerでの導入・依存解決・安全な選び方 の方向とは設計思想が異なる。LogoCreatorはホスト型APIを前提に、プロンプト側で品質を作り込むタイプの実装だ。

flowchart TD A["利用者の入力
社名・スタイル・ロゴ種別・色"] --> B["プロンプト組み立て"] B --> B1["hex → 色名変換
24色の最近傍テーブル"] B --> B2["否定形を肯定形へ書き換え"] B --> B3["背景の平坦さを明示"] B --> C{"文字を含む種別か"} C -- 含む --> D["google/flash-image-3.1"] C -- 含まない --> E["FLUX.2-pro（guidance:7）"] D -- "429" --> F["1.2〜2.0秒待って1回再試行"] F -- 失敗 --> E D --> G["画像を返す"] E --> G G --> H["ブランドキット書き出し
端からのflood-fillで背景除去 → SVG化"]

まとめ

LogoCreator の要点（2026年8月23日時点）
・正体：Together AI経由でロゴを生成するNext.js製Webアプリ。★8,400、Clerk/Upstashは任意
・READMEと実装の差2箇所：文字入りロゴはgoogle/flash-image-3.1（READMEに記載なし）、編集はFLUX.2-pro（READMEはFLUX.1 Kontext）
・選定根拠がコード内に：2026-07-10の比較でIdeogramから切替、2026-07-13の比較でKontextが編集を適用しなかったことと単価差（$0.03対$0.04）を記録
・プロンプト設計：hexに色名を添える／否定形を肯定形にする／hexを部位に紐づける／背景の平坦さを明示（後段の背景除去を守るため）／媒体を指定する
・費用防御：無防備な本番構成は401、無料枠はatomic INCRと失敗時返却、偽装不可のIPヘッダ、画像入力はdata URLのみ
・SSRF対策：IPv6のNAT64・6to4・IPv4-mappedまで分類し、リダイレクト後も再チェック
・注意：LICENSEファイルが全123コミットで一度も存在しない。読む・動かすを超える利用は作者への確認が要る

このリポジトリを読んで一番役に立ったのは、生成されるロゴそのものより「なぜそう書いたか」がコメントとして残っていることだった。モデルを比較した日付、却下した選択肢、単価の差、実際に叩いて分かったAPIの制約。通常はチームの中に消えていく判断が、そのままコードに書かれている。

一方でREADMEはv2の作り直しに追随できておらず、技術スタックの記述は現状と食い違っている。READMEを読んで理解した気になると、実際に呼ばれているモデルを取り違える。OSSを評価するときはREADMEと実装を突き合わせる、という原則がそのまま当てはまる例だった。

参照ソース

・Nutlope/logocreator（公式リポジトリ） — README・.env.example・git履歴（全123コミット）。★8,400の確認元
・app/api/generate-logo/route.ts — モデル投げ分け、24色の色名テーブル、プロンプト設計のコメント、無料枠の消費と返却
・app/api/edit-logo/route.ts — 編集がFLUX.2-proである根拠と、FLUX.1 Kontextとの比較記録（$0.03対$0.04）
・app/api/import-brand/route.ts — SSRF対策。IPv6の展開とNAT64・6to4・IPv4-mappedの分類、リダイレクト後の再チェック
・app/lib/credits.ts — FREE_CREDITS = 2 と「補充しない」設計意図