診断ツールを作るとき、結果画面が「成績表」になる瞬間があります。
点数が出る。ランクが表示される。「ここが弱い」と指摘される。
技術的には簡単です。でも、それをやった瞬間、診断が「評価装置」になってしまう。
内省診断のアドバンス版を実装していたとき、この問題にどう向き合うかで、相当悩みました。
前提: 2つの診断の役割
内省力診断として、2つのアプローチを設計していました。
ベーシック診断: 質問票形式で、自分の傾向を知る（20問）
アドバンス診断: 自由記述で、一つの出来事を振り返る（LLM分析）
ベーシック診断については前編で書いたので、今回は**アドバンス診断（LLM分析型）**の実装判断に焦点を当てます。
実際のツール:
🔗 https://metacog-assess.tool.tielec.blog
これは、ユーザーが実際に内省した文章をLLMに分析させて、「ORIMDの各ステップをどう使っているか」を観測する、アドバンス診断の仕組みです。
最初に決めたこと: 観測であって、評価ではない
実装に入る前に、明確にしておきたかったことがあります。
LLMの役割は「採点者」ではなく「観測者」である
採点者モデル（やりたくなかったこと）
ユーザーの内省テキスト
↓
LLMが分析
↓
O: 8点、R: 6点、I: 4点、M: 7点, D: 9点
↓
「あなたの解釈可視化力は低いです。改善しましょう」
これは、わかりやすい。実装も簡単。
でも、点数で評価した瞬間、診断が成績表になる。
観測者モデル（やりたかったこと）
ユーザーの内省テキスト
↓
LLMが観測
↓
「今回の内省では、出来事を整理し、感情を言葉にした上で、
解釈と行動に進む流れが見られました。
一方で、意味づけの段階はあまり前面には出ていませんでしたが、
これは今回の出来事が実務的な判断を求める文脈だったためと考えられます。」
点数ではなく、プロセスの記述。
「良い/悪い」ではなく、「こう通過した」という記録。
ただ、「観測者として振る舞わせる」のは、理論で分かっていても、実装となると話は別でした。
プロンプト設計: 3回の改訂
LLMに「観測者として書いてください」と言うだけでは、うまくいきませんでした。
1回目（失敗）
以下のテキストを分析し、ORIMDの各ステップが
どの程度使われているかを評価してください。
生成されたコメント:
「事実把握は十分にできています」
「感情認知が不足しています」
「解釈の視点が弱いです」
...ダメだ。これは完全に採点者の言葉です。
2回目（まだ不十分）
以下のテキストを観測し、ORIMDの各ステップが
どのように使われているかを記述してください。
能力評価ではなく、プロセスの観測として記述すること。
少しマシになりましたが、まだ問題がありました。
「今回この視点は使われていませんでした」
この表現、一見中立的です。でもユーザーには「できていない」と読まれる可能性が高い。
3回目（禁止語彙の明示）
結局、使ってはいけない語彙の方向性を明示的に示す必要がありました。
# 概念的な例（実際のプロンプトは簡略化して記載）
system_prompt = """
あなたは内省プロセスの観測者です。
重要な制約:
1. 能力評価をしない
- 能力を示す表現を使わない
2. 使ってはいけない語彙の方向性:
- 欠如・不足を示す表現
- 優劣・強弱を示す表現
3. 使うべき語彙の方向性:
- 状態の記述（前面/背景など）
- 文脈依存を示す表現
4. すべての観測コメントに「文脈依存」の語彙を含める
"""
これで、ようやく「観測」らしい文言が生成されるようになりました。
「今回の内省では、この視点は前面には出ていませんでした。
出来事の性質上、他の視点が優先された可能性があります。」
ここが最も重要なポイントです。LLMに「中立的に書いて」と言うだけでは不十分で、具体的な語彙レベルでの制約が必要でした。
LLMを使ったプロダクト開発について、より実践的な知識を得たい方には以下の書籍が参考になります。
[📦 商品リンク: moshimo-book-BKl55]
UI設計: レーダーチャートをやめた理由
次に直面したのが、結果画面のUI設計です。
レーダーチャートの誘惑
最初、こんな画面を想像していました。
5軸のレーダーチャートで、各能力（O, R, I, M, D）をスコア化して表示する。
技術的には簡単です。見た目もわかりやすい。Chart.jsでもRechartsでも、すぐ実装できます。
でも、レーダーチャートは本質的に「比較」を促すUIなんです。
「Rが高い」「Iが低い」という読み方を、ほぼ必然的に生み出してしまう。
フロー表示への切り替え
結局、こういう表示に変更しました:
事実 → 感情 → 解釈 → 意味 → 決定
● ● ○ ○ ●
● 今回の重心
○ 今回は背景にあった視点
これは「点数」ではなく、「今回のプロセスの重心」を示すUIです。
そして、画面の冒頭と末尾に、こう書きました:
これは今回の出来事をどのように通過したかの記録です。
あなたの能力や傾向を評価するものではありません。
この釘の刺し方は、過剰に見えるかもしれませんが、実はこのくらいでちょうどいいと考えています。
内省ツールでユーザーを傷つけてしまったら、本末転倒ですから。
予期しなかった問題: R/D強調バイアス
実装がほぼ完成したところで、結果画面を改めて眺めていて気づきました。
UI上、RとDが色付きで目立っていて、O/I/Mは控えめになっている。
これだと**「感情と決断ができている人」「他は弱い」という無意識の序列読み**が起きるんじゃないか。
問題の構造
内省テキストを分析すると、実は:
- R（感情認知）: 「嬉しかった」「焦った」など、テキストに現れやすい
- D（意思決定）: 「次はこうする」など、明示的に書かれやすい
- O（事実）/I（解釈）/M（意味）: テキストに埋め込まれていて、観測しにくい
その結果、LLMの観測コメントがRとDに対して肯定的になりやすいという、構造的なバイアスがあったんです。
対処: 文脈依存を強調
これもプロンプト調整で対処しました:
"""
5. R（感情）とD（決定）について:
- これらはテキストに現れやすい性質があることを前提に
- 文脈上の自然さを示す表現を含める
例:
「今回の出来事では、この視点が自然に前面に出やすい文脈でした」
「この視点が前に出たのは、出来事の性質によるものと考えられます」
"""
こうすることで、RやDが前面に出ているのは、その人の能力ではなく、出来事の性質によるものという読み方を促せるようになりました。
実装の詳細（コード例）
参考までに、実際のプロンプト構造の概念を示します:
def generate_observation_comment(user_text: str, step: str) -> str:
"""
ユーザーの内省テキストから、特定のORIMDステップについて
観測コメントを生成する
注: これは概念的な例であり、実際の実装は簡略化しています
"""
system_prompt = """
あなたは内省プロセスの観測者です。
【禁止事項】
- 能力評価を示す表現
- 点数化や段階評価
- 優劣・強弱を示す表現
【必須表現】
- 文脈依存を示す表現
- 中立的な状態記述
- 可能性を示す表現
【特別ルール: 頻出する要素について】
テキストに現れやすい要素については、
その性質を文脈として説明すること
"""
user_prompt = f"""
以下の内省テキストについて、
{step}のステップがどのように使われているかを観測してください。
【内省テキスト】
{user_text}
"""
response = call_llm(system_prompt, user_prompt)
return response
このプロンプト構造は、3回の改訂を経てこの形になりました。
最初は「中立的に書いて」の一言だけでしたが、それでは全く不十分だったんです。
技術的判断のまとめ
アドバンス診断の実装で学んだこと:
1. LLMを「観測者」にするには、具体的な語彙制約が必要
抽象的な指示（「中立的に」「評価せず」）では不十分。
使ってはいけない語彙、使うべき語彙を、明示的にプロンプトに書く必要がありました。
2. UIは思想を体現する
レーダーチャートは技術的には簡単ですが、「比較」を促してしまいます。
フロー表示にすることで、「プロセスの通過」という思想を視覚的に表現できました。
3. 構造的バイアスは必ず存在する
テキスト分析では、書かれやすい要素（R, D）とそうでない要素（O, I, M）があります。
この構造的バイアスを意識し、プロンプトで補正する必要がありました。
4. 過剰なくらいの釘の刺し方
「これは評価ではありません」という文言を、冒頭と末尾、両方に入れました。
過剰に見えるかもしれませんが、誤読を防ぐにはこのくらいでちょうどいい。
トレードオフ: 何を選び、何を捨てたか
この設計には、明確なトレードオフがあります。
選んだもの
- ユーザーの心理的安全性
- 思想の一貫性
- 誤読の防止
捨てたもの
- わかりやすい点数表示
- 明確な優劣評価
- ゲーミフィケーション的な「成長感」
「診断」という言葉を使う以上、ユーザーは「評価されている」と感じやすい。
その前提で、評価にならないようにするには、相当な配慮が必要でした。
ベーシック診断とアドバンス診断の使い分け
2つの診断は、目的が異なります:
| ベーシック診断 | アドバンス診断 | |
|---|---|---|
| 形式 | 質問票（20問） | 自由記述 + LLM分析 |
| 対象 | 自分の傾向 | 一つの出来事 |
| 役割 | 地図 | 記録 |
| 主役 | 能力の配分 | プロセスの通過 |
| 出力 | レーダーチャート | フロー表示 |
ベーシック診断は「自分はどういう傾向があるか」を知るための地図。
アドバンス診断は「今回どう通過したか」を見るための記録。
どちらも、評価しないという思想は共通しています。
技術と倫理の交差点
この実装過程で一番強く感じたのは、技術的な判断が、そのまま倫理的な判断になるということでした。
レーダーチャートを使うかフロー表示にするか。
「使われていませんでした」と書くか「前面には出ていませんでした」と書くか。
これらは一見、些細な実装の違いに見えます。
でも、その選択がユーザーの自己認識に影響を与える可能性がある。
だからこそ、「迷ったときは、ユーザーの心理的安全性を優先する」という判断軸を、最初から最後まで持ち続けました。
リリース可能な状態へ
ここまでの調整を経て、アドバンス診断はリリースできる状態になりました。
完璧ではありません。まだ誤読される可能性はあるし、もっと良い表現があるかもしれません。
でも、「評価しない」という思想を、プロンプト・UI・文言のすべてに一貫させることはできたと思います。
おわりに
内省診断、特にアドバンス診断のようにLLMを使った分析型を作るということは、人の自己認識に影響を与えるツールを作るということです。
その責任を、プロンプトの一語一語、UIの一要素一要素に持ち込む必要がある。
LLMを使えば簡単に「診断っぽいもの」は作れます。
でも、それが人を傷つけないか、誤った自己認識を植え付けないか——その問いを持ち続けることが、何より重要だと思っています。
参考リンク
内省力を深めたい方には、体系的に学べる書籍もおすすめです。
[📦 商品リンク: moshimo-book-reflection-kumakura]
また、自己認識を深めるためにプロのコーチと対話することも効果的です。
[📦 商品リンク: moshimo-coachee-banner-728x90]
実際のツール: