🔖

生成AIを使って、職務SNS用プロフィール画像を生成してみよう

に公開
テーマ「この春、始めたこと」
workflow
ChatGPT
画像生成 AI
Dify
falai
tech

※この記事は、"生成AIを使って、どうやってプロダクトを組み立てていくかの試行を提示すること"を目的としています※

はじめに

転職に使うSNSとかブログページに、自分のアイコンを作ろうと思いました。
2年くらい前には、有料サービスを使って、同じようなものを作った。
ただ、現在では、画像生成AI使えば自分でできるよね?
そう考えました。

まず、3つの方向性があった

わたし🧍‍♀️「自分の写真をもとにした画像アイコン作る、専用のカスタムGPT作れないかな?」
ChatGPT🤖「できないこともないけど、実現するには、こんな方向性があるかな。」

1. カスタムGPTそのまま

  • 一番手軽
  • ChatGPT内だけで完結できる
  • ただし画像制御は弱い

特に、

  • 顔保持
  • identity preservation
  • 毎回の生成ブレ

あたりに問題あり。

2. カスタムGPT + API連携

  • GPT Actions
  • 外部API
  • 中継サーバ　(画像系は必須)

を組み合わせる方向。

しかし、ここで気が付く。

わたし🧍‍♀️「外部API使うならば、フロントは、カスタムGPTよりDifyの方が使いやすくないか?」

ChatGPT🤖「Difyはかなり相性いいです」

3. 外部WebApp + GPT

最終的にはこちらへ寄っていった。

  • Dify
  • workflow
  • API orchestration
  • fal.ai

を組み合わせる構成。

転職ポートフォリオ画像用途と考えると、「こんなの作って」「あんなのがいい」とか自己主張が膨らむことが考えられたので、フロントはLLM必須。そうなると、 workflow型の方が自然だった。

つまり、GPT単体というより、"「対話」と「画像処理」を分離する" 方向だった。

Dify + fal.ai で組んでみることにした

最初のWorkflow構成

START
 ↓
フォーム入力
 ↓
LLM（prompt生成）
 ↓
HTTP Request（fal.ai）
 ↓
画像URL返却

入力として持たせたもの

  • platform
  • industry
  • impression
  • input_image

Difyのフォームでアップロードされた画像は、外から見えなかった

422エラー祭りの開催

わたし🧍‍♀️「422エラーだー」 「直らないー」「なんでー」

JSON? Header? Body? 変数?　どれだどれだ。
ChatGPT🤖へ、 HTTP Request のデバッグ情報を投げる。

ChatGPT🤖「あー、これ、 Failed to download the file ですね」

ひとことで終了。

ファイルがダウンロードできない

つまり、 HTTP Requestそのものではなく、

Dify Upload の画像URLを、 fal.ai側が取得できていなかった

のが原因だった。

ChatGPT🤖 「Cloudflare R2とかSupabase StorageとかS3へ一回外出しして、 公開URL化しましょう」

わたし🧍‍♀️ 「。。自分用のプロフィール画像を作りたいだけなのに、そんなめんどくさいことしたくないー。」

こういう場合は、とりあえず、全体構成を見直してみる。

fal workflowで組んでみることにした

fal.ai の画面を見ていたら、Workflow があった

そこで、 fal.ai 側の画面を見ていたら、 Workflow機能があった。

わたし🧍‍♀️「あれ? workflowある。これ使える?」
ChatGPT🤖 「使える。本命かもしれない。」

ChatGPTによる、fal Workflow講座

わたし🧍‍♀️「ところでさ、falのworkflowってなんだと思う?」
ChatGPT🤖「fal Workflowは、 Request Input と Model と Response を繋いでいく感じです」

例えば、

  • Request Input
  • FLUX.1 Kontext [pro]
  • Response

を配置する。

そのあと、

  • Request Input の image_url_field
  • FLUX.1 Kontext [pro] の image_url

を繋ぐ。

次に、promptを書く。

最後に、

  • Response の image

を繋ぐ。

みたいな流れになります。

HTTP Request を自分で組むというより、 「画像入力を持ったWorkflowを組む」というとわかりやすいかもしれません。

わたし🧍‍♀️「fal Workflowって、ノードつないでいくタイプなんだねえ。楽でいいねえ。」
わたし🧍‍♀️「一つのシステムの中で完結したほうが、管理しやすいし。」

では、作ってみる

最初は、 FLUX.1 Kontext [pro] を使ってみることにした。

最初は FLUX.1 Kontext [pro] を使った

わたし🧍‍♀️ 「あれ、写真ができた」

出てきたのは、

  • 写真補正
  • 別人化
  • “綺麗な証明写真”

寄りだった。

ChatGPT🤖「では、イラストっぽく、promptを変えてみましょう」

promptを調整してみる。

すると今度は、 顔そのものが変わり始めた。

わたし🧍‍♀️「顔が変わった。。。」
わたし🧍‍♀️「そうではない。イラストが欲しい。」
ChatGPT🤖「ではもっとpromptを調整しますか?」
わたし🧍‍♀️「いや、モデルを調整したほうがいいだろう?!」

実際にやりたかったことは × 写真改善 〇 職務SNS向けイラスト化
という話が、全く、伝わっていなかったことに気が付く。

ChatGPT🤖

モデル 得意そうな方向
Nano Banana 2 半イラスト・SNSアイコン
FLUX.1 Kontext [pro] 写真改善・高品質写真
OpenAI GPT Image 汎用画像生成

わたし🧍‍♀️「bananaにしよう。」

Nano Banana 2に変えた

実際作ったWorkflowはこんな感じ

まとめ

今回やってみて、 一番影響が大きかったのは、 promptよりモデル側だった。

FLUX.1 Kontext は、

  • 写真補正
  • プロフィール写真改善

方向へ強く寄る。

一方 Nano Banana 2 は、 最初から、

  • SNSアイコン
  • 半イラスト化

方向の空気を持っていた。

あと、 単純に画像生成をするだけなら、 下手に Dify を挟むより、 画像生成AI側だけでかなり完結していた。

少なくとも fal.ai Workflow は、

  • image input
  • workflow
  • model切り替え

あたりが最初から揃っていたので、 かなり自然だった。

もちろん、 これは fal.ai が強かっただけかもしれない。

ただ、 今回かなり満足してしまったので、 しばらく他を触る気は起きない気がする。

Discussion