この記事の位置づけ

この記事では、最近よく見かける「AIに自分をゲーム風ステータス画面として描かせる」プロンプトを題材にします。
Note記事の執筆中に並行して執筆しました。
ただし、ここではエンタメとしての面白さだけではなく、技術的には何が起きているのかを分解します。

結論から申し上げると、この手のプロンプトは「画像生成の呪文」ではなく、次のような小さなパイプラインとして捉えた方が扱いやすくなります。

つまり、目的は「かっこいい画像を出すこと」だけではありません。
会話履歴や自己情報から抽出した特徴を、ゲームUIやキャラクター設計へどう写像するかが本体です。

TL;DR

自己診断画像プロンプトは、診断タスクと画像生成タスクを混ぜた複合タスクです。
「過去の会話から私を描いて」だけでは曖昧すぎるため、特徴抽出・変換ルール・UI制約を明示します。
画像内テキストは破綻しやすいため、長文を画像に入れず、短いラベルとUI要素に分割します。
有名作品の画風名に依存するより、画面設計・質感・構図・UIルールを言語化した方が再利用しやすくなります。
最終的には、プロンプトを「一文」ではなく、再利用可能な仕様書として扱います。

なぜ「自分を画像化する」プロンプトは面白いのか

LLMは、入力されたテキストからタスクの意図、条件、出力形式を推定します。
大規模言語モデルが少数例や自然言語の指示からタスクを実行できることは、GPT-3の few-shot learning の文脈でも議論されています。
ここで重要なのは、モデルが「命令文そのもの」だけでなく、文脈・例・制約から出力形式を形成する点です。

自己診断画像プロンプトでは、ユーザーの会話履歴や自己紹介が入力データになり、そこから「この人らしさ」が抽出されます。
その後、抽出された特徴が「種族」「ジョブ」「スキル」「ステータス」「称号」といったゲーム内概念に変換されます。

この構造は、ざっくり言えば次の写像です。

user_context
  -> personality_features
  -> symbolic_game_attributes
  -> visual_prompt
  -> generated_image

ここで失敗しやすいのは、personality_features から symbolic_game_attributes への変換ルールが曖昧な場合です。

たとえば「構造化思考が強い」という特徴を、ジョブにするのか、武器にするのか、スキルにするのか、UIカラーにするのかを決めないと、出力は雰囲気任せになってしまいます。

技術的には「プロンプト」ではなく「仕様」である

よくある失敗は、プロンプトを一つの長い文章として扱うことです。
しかし、実際には以下のように役割を分けた方が安定します。

層	役割
Context	会話履歴、プロフィール、好み、過去の出力傾向など、判断材料になる情報。
Analysis	特徴抽出、強み・弱みの整理、人物像の要約。
Mapping	特徴を種族、ジョブ、属性、武器、ステータス、スキルへ変換するルール。
Composition	画面レイアウト、文字量、UI、配色、構図、情報密度の指定。
Evaluation	出力後に破綻、類似性、文字崩れ、個性不足をチェックする観点。

OpenAIのプロンプトエンジニアリング資料でも、明確な指示、例示、出力形式の指定、制約の明示が重要な実践として扱われています。
したがって、自己診断画像プロンプトも「ノリで頼む」より「仕様として分ける」方が制御しやすくなります。

パイプラインとして設計する

Qiita向けに書くなら、次のような処理フローとして説明できます。

1. 特徴抽出

まず、ユーザーの自己情報を「直接画像に使う」のではなく、特徴量として抽出します。
ここで欲しいのは、文章としての自己紹介ではなく、変換可能な属性です。

{
  "thinking_style": "構造化・検証重視",
  "creative_style": "中二性と実用性の混在",
  "risk": "情報量を詰め込みすぎる",
  "visual_preference": "黒・赤・高コントラスト・ゲームUI",
  "growth_area": "継続運用と外部への見せ方"
}

2. 特徴量の正規化

抽出した特徴は、そのままだと画像生成に渡しにくくなります。
そこで、以下のようにゲーム内概念へ変換します。

抽出特徴	ゲーム概念への変換例	画像上の表現
構造化思考	ジョブ：魔導設計士 / スキル：構文結界	魔法陣、設計図、幾何学的なエフェクト
創作衝動	属性：混沌 / 固有スキル：生成暴走	赤い光、粒子、割れたUI
検証癖	称号：観測する審問官	片眼鏡、解析パネル、ログ表示
情報過多	弱点：過積載	UIを整理しないと破綻する、という制約に反映

3. UI制約を明示する

画像生成モデルは、自然言語の指示から視覚概念を構成します。
CLIPのような研究では、自然言語と画像の対応を学習することで視覚概念を扱う方向性が示されてきました。

一方で、プロンプトはコンパイラの命令のように厳密ではありません。
そのため、UIを作らせる場合は、文字量・配置・優先順位を強く制限する必要があります。

注意
「ステータス画面にたくさん日本語を入れる」は、見た目としては魅力的ですが、生成画像では崩れやすくなります。
画像内に入れる文字は、名前、種族、ジョブ、Lv、スキル名程度に絞ってください。
詳細な診断文は、画像ではなく記事本文やキャプション側に逃がした方が安定します。

最小構成のプロンプトテンプレート

まずは、LLMに「設計」と「画像生成指示」を分けさせます。
これにより、生成前にどの特徴がどの表現に変換されたかを確認できます。

あなたは、LLMによる特徴抽出と画像生成プロンプト設計を行うアシスタントです。

目的：
ユーザーの会話履歴・自己情報から特徴を抽出し、
それをRPG風キャラクターUIに変換してください。

手順：
1. ユーザーの特徴を5〜8個に要約してください
2. 各特徴を、種族・ジョブ・属性・武器・衣装・スキルへ写像してください
3. 画像内に表示する文字を短く整理してください
4. 最後に、画像生成AIへ渡す完成プロンプトを出力してください

制約：
- 画像内の日本語は短いラベル中心とすること
- 長文説明は画像に入れないこと
- 特定作品名の画風指定に依存しないこと
- 「なぜその設定になったか」が追えるようにすること
- 美化しすぎず、弱点や偏りもキャラクター性に変換すること

出力形式：
## 特徴抽出
- ...

## ゲーム概念への写像
- ...

## 画像内テキスト
- ...

## 画像生成プロンプト
...

疑似コードで見る実装イメージ

アプリケーションとして組むなら、プロンプトを一発で投げるより、処理段階を分けた方がよくなります。
たとえば、次のような疑似コードになります。

def build_self_diagnosis_image_prompt(user_context: str) -> dict:
    features = extract_features(user_context)
    normalized = normalize_features(features)
    game_profile = map_to_game_profile(normalized)
    ui_spec = build_ui_spec(game_profile)
    image_prompt = compose_image_prompt(game_profile, ui_spec)

    return {
        "features": features,
        "game_profile": game_profile,
        "ui_spec": ui_spec,
        "image_prompt": image_prompt,
    }


def extract_features(user_context: str) -> list[dict]:
    """
    会話履歴や自己紹介から、画像化に使える特徴だけを抽出する。
    例：思考傾向、創作傾向、好きな色、弱点、行動パターン。
    """
    pass


def map_to_game_profile(features: list[dict]) -> dict:
    """
    特徴をゲーム内概念へ写像する。
    例：構造化思考 -> 魔導設計士、検証癖 -> 解析者、情報過多 -> 過積載スキル。
    """
    pass

この分割のメリットは、生成結果が失敗したときに原因を切り分けられる点です。

キャラクターが自分っぽくない
→ extract_features か map_to_game_profile が弱いです。
UIが崩れる
→ build_ui_spec が過密です。
画像が凡庸
→ compose_image_prompt の視覚指定が弱いです。

評価観点を先に作る

画像生成は主観評価になりやすくなります。
そこで、最低限の評価軸を作っておくと改善しやすくなります。

評価軸	確認内容	低い場合の修正
本人らしさ	会話傾向や好みが反映されているか	特徴抽出を再実行し、外見・武器・スキルに再写像する
視認性	画像内テキストが読みやすいか	表示項目を減らし、短いラベルにする
一貫性	種族・ジョブ・衣装・背景が矛盾していないか	属性と世界観を1つに絞る
非量産性	よくある美形キャラで終わっていないか	シルエット、武器形状、種族特徴を強める
再利用性	他のユーザーにも使えるテンプレになっているか	個別情報と汎用ロジックを分離する

失敗モードと対策

失敗1：かっこいいが、誰にでも当てはまる

原因は、特徴抽出が弱いことです。
「私っぽくして」ではなく、「会話履歴から特徴を5〜8個抽出し、それぞれを外見・衣装・武器・スキルへ変換する」と指示してください。

修正指示：
一般的なファンタジーキャラではなく、
抽出した各特徴がどの視覚要素に反映されたかを明示してから再設計してください。

失敗2：情報量が多すぎてUIが壊れる

原因は、画像内に文章を入れすぎていることです。
画像はラベル、本文は記事側に分けてください。

修正指示：
画像内の表示項目を「名前・種族・ジョブ・Lv・固有スキル3つ」に減らしてください。
説明文は入れず、短い日本語ラベルだけにしてください。

失敗3：有名作品の模倣に寄りすぎる

原因は、画風指定が具体的すぎることです。
公開用テンプレでは、作品名ではなく構成要素に分解した方が安全で、応用もしやすくなります。

修正指示：
特定作品名の画風ではなく、
「高精細な王道ファンタジーRPGカード」「重厚な装飾UI」「水彩厚塗り風の質感」
のように、構図・質感・UI要素として再記述してください。

学問的補足：これは「自己理解」ではなく「自己モデルの生成」である

ここで注意したいのは、LLMが本当の意味でユーザーの内面を理解しているわけではない点です。
LLMは、与えられた文脈から、もっともらしい特徴表現を生成しています。
したがって、出力されたキャラクターは「真の自分」ではなく、「入力情報から構成された自己モデル」と見た方がよくなります。

ただし、それでも価値はあります。
人間は、自分の特徴を直接言語化するより、比喩や物語、ゲームUIを通した方が認識しやすい場合があります。

つまり、この手法は心理診断そのものではなく、自己説明のためのインターフェースとして使うのが妥当です。

実用上の位置づけ
AI自己診断画像は、心理検査ではありません。
しかし、会話履歴から抽出した特徴を、種族・職業・スキル・ステータスに変換することで、自分の強みや偏りを別の表現体系で眺めるためのUIにはなります。

完成版：Qiita向けの技術記事用プロンプト

ここまでの内容を踏まえると、Qiita記事内で紹介するテンプレは次のようにするとよくなります。

あなたは、LLMの特徴抽出と画像生成プロンプト設計を行うアシスタントです。
以下のユーザー情報をもとに、自己診断画像生成用のプロンプトを設計してください。

# 目的
ユーザーの会話履歴・プロフィール・趣味嗜好を分析し、
RPG風ステータス画面として画像化するためのプロンプトを作成してください。

# 手順
1. ユーザーの特徴を5〜8個に要約してください
2. 各特徴を、ゲーム内概念へ写像してください
   - 種族
   - ジョブ
   - 属性
   - 武器
   - 衣装
   - 固有スキル
   - ステータス値
3. 画像内に表示する文字を短く整理してください
4. UIレイアウトを設計してください
5. 最後に、画像生成AIに渡す完成プロンプトを出力してください

# 変換ルール
- 強みはスキル・称号・武器に変換してください
- 弱点は制約・呪い・未解放スキルに変換してください
- 好みの色は属性色・背景色・エフェクトに反映してください
- 思考傾向はジョブや戦闘スタイルに反映してください
- 情報量は画像内に詰め込みすぎないでください

# 画像制約
- 画像内テキストは短い日本語ラベル中心とすること
- 長文説明は入れないこと
- 左側に全身キャラクターを配置すること
- 右側にステータスUIを配置すること
- 装飾枠、属性エフェクト、ゲーム画面風UIを含めること
- 特定作品名の画風指定に依存しないこと
- 高精細で、破綻しにくい構図とすること

# 出力形式
## 特徴抽出
## ゲーム概念への写像
## 画像内テキスト
## 画像生成プロンプト
## 失敗した場合の修正指示

まとめ

自己診断画像生成は、一見すると流行りのネタです。
しかし技術的に見ると、LLMによる特徴抽出、記号体系への写像、画像生成プロンプトへの変換、UI制約、評価ループが含まれています。

プロンプトの本質は、単語を詰め込むことではありません。
モデルに何を見て、何を抽出し、何に変換し、どの形式で出力するかを渡すことです。

だから、自己診断画像プロンプトを安定させたいなら、「かっこよく描いて」では足りません。

仕様として分けます。
変換ルールを書きます。
UIの情報量を制御します。
評価観点を持ちます。

ここまでやると、自己診断画像は単なる遊びではなく、LLMと画像生成AIを使った小さな情報設計の実験になります。

参考資料

OpenAI, “Best practices for prompt engineering with the OpenAI API.”
OpenAI Developers, “Prompt engineering / message roles and instruction following.”
Jason Wei et al., “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models,” arXiv, 2022.
Tom B. Brown et al., “Language Models are Few-Shot Learners,” NeurIPS, 2020.
Alec Radford et al., “Learning Transferable Visual Models From Natural Language Supervision,” ICML, 2021.
OpenAI Cookbook, “GPT Image Generation Models Prompting Guide,” 2026.
OpenAI, “Improving Image Generation with Better Captions,” DALL·E 3 technical report.

※この記事は、エンタメ系の自己診断画像プロンプトを、Qiita向けに技術・設計観点で再構成したものです。
心理診断・適性検査としての妥当性を主張するものではありません。