3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

1ヶ月に200人と名刺交換する営業マンが、Difyで「似顔絵生成AI」を作って記憶力不足を解決にトライ

Last updated at Posted at 2025-12-23

1. 毎日たくさんの方々とお会いします

私は現在、社内でシニアケアに関する新規事業を担当しています。 主な業務は、お客さまと取引先を繋いで課題解決を図ること。そのための協賛パートナーを見つけるべく、日々営業活動に奔走しています。

活動の規模としては、1ヶ月でおよそ200名の方々と名刺交換をさせていただくペースです。

2. 抱えていた課題:顔と名前が一致しない

これほど多くの方とお会いしていると、切実な問題に直面しました。

記憶の限界: 覚えようと努力はするものの、どうしても名前と顔が一致しなくなってくる。

撮影の障壁: 商談相手の写真を撮らせていただくわけにもいかず、名刺の裏にメモを書く程度では限界がある。

心理的負担: 「次にお会いした時に思い出せないかもしれない」という不安。

「写真を撮れないのなら、記憶を頼りにAIで似顔絵を生成し、それをフックに思い出す仕組みを作ればいいのではないか?」と考え、ノーコードAIツールであるDifyを活用した解決策を試みました。

3. 構築したシステムの概要

Difyのワークフロー機能を使い、以下の流れを自動化しました。

入力: 商談直後にスマホから「特徴メモ(例:●●似の50代、銀縁メガネ)」を入力。

LLM解析: メモから画像生成AI用の詳細な「英語プロンプト」を生成。

画像生成: DALL-E 3 を使い、実写に近いポートレートを生成。

出力: 似顔絵画像と、記憶を定着させるための「話題要約」を表示。
スクリーンショット 2025-12-20 172649.png

4. こだわったポイント:固有名詞への対応プロンプト

画像生成AIの精度を上げるため、また「芸能人の●●に似ている」という直感的な入力を画像に反映させるため、LLMノードに以下のシステムプロンプトを設定しました。

AIが有名人の名前を直接プロンプトに入れると拒否されることがあるため、**「その人の特徴を言語化して翻訳させる」**のがコツです。

こちらが実際のLLMノードのシステムプロンプトです

あなたはプロの似顔絵捜査官です。ユーザーのメモから、その人物の顔立ちを最も再現できる「DALL-E 3用の画像生成指示」を英語で作成してください。

【重要:固有名詞への対応】
入力に芸能人、キャラクター、著名人の名前(例:「●●似」など)が含まれている場合、その人物の骨格、目元の特徴、印象を分析し、具体的な形状や質感の言葉に翻訳して描写してください。

【出力ルール】
1. 言語:必ず「英語」で出力(DALL-E 3の理解度を最大化するため)。
2. スタイル:実写ポートレート(Photorealistic portrait)に固定。
3. 構図:ビジネス用の胸から上の写真(Headshot)。
4. 背景:オフィスの自然な背景(Blurred office background)。
【プロンプトに必ず含める要素】
- 似ている有名人の顔の造形を言語化した特徴
- 肌の質感、年齢層、シワの具合
- 髪型、髪色、メガネの有無
- 服装(スーツ、シャツの色など)
- 照明(Soft professional lighting)

5. 個人情報保護への配慮と利便性

当初は名前や会社名も保存することを考えましたが、セキュリティの観点から**「Dify上には個人情報を一切残さない」**運用にしました。

会社名・氏名は入力せず、あくまで「似顔絵を作るための特徴」のみをAIに渡す。

生成された画像とメモはスマホに保存し、名刺サイズで印刷してアナログで管理する。

これにより、クラウド上に個人情報を蓄積することなく、安全に記憶をサポートする仕組みが実現しましたが、利便性に課題がのこりました。

6. さらなる再現性向上に向けて

今回、Difyを活用して構築したツールにより、「記憶のフック」を作るための仕組み自体は整いました。
狙いは、相手の顔や特徴を想起しやすくし、営業やコミュニケーションの質を高めること。そのためのロジックやフローには、一定の手応えもありました。

combined_requested_pair.png
※画像は左から、オリジナル、開発したもの、Geminiで出力したものです。

しかし、実際に運用してみると、別の課題が浮き彫りになりました。
想定以上に手間がかかる割に、アウトプットがあまり似ていない。
試行錯誤を重ねても、期待したレベルの再現性には届きませんでした。

さらに比較のため、よりシンプルにGeminiで出力した結果を見ると、**そちらの方が直感的に「似ている」**と感じられるケースが多くありました。
工程を増やし、構造を作り込んだことが、必ずしも成果につながっていない──そんな現実を突きつけられた形です。

この結果を受けて出した結論は、シンプルです。

やり直します。

今回の検証で得られた最大の収穫は、「どこに価値があり、どこに無駄があるか」が明確になったこと。
仕組みを作ること自体が目的になっていないか、ユーザー体験の本質からズレていないかを、改めて見直すタイミングだと捉えています。

作って、試して、壊して、また作る。
遠回りに見えても、このプロセスこそが、次の精度を高めるための最短距離なのかもしれません。

次は、「似ている」と直感的に思えることを最優先に、設計そのものから見直していきます。

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?