はじめに：「言語化弱者」という言葉について

本記事では「言語化弱者」という言葉を使います。これは蔑みやレッテル貼りではなく、「考えや意図を、最初から整理された文章や指示として出すのが得意ではない状態」 を指す便宜的なラベルです。

そもそも、仕事のテーマが複雑であればあるほど、誰でも言語化・構造化は難しくなります。にもかかわらず、社会や組織では「言語化できるビジネスパーソン」こそが強者として評価されやすく、その基準に合わせて多くの人が訓練（あるいは矯正）されている、という側面があります。
本記事でこの言葉を使うのは、そうした現実を踏まえた上で「つまずきの原因」を責めずに説明するためです。

本記事でいう「言語化弱者」の定義：

頭の中にイメージはあるが、目的・前提・制約・完了条件を一度に文章化できない
何が分からないかが分からず、質問や依頼文が作れない
テンプレがあっても、埋めるための材料を取り出せず手が止まる

言い換えると「能力の烙印」ではなく、言語化が必要な局面で負荷が高くなりやすい“状態” の話です。

0. 課題提起：プロンプト技法は「言語化・構造化ができる」前提で設計されている

AIを仕事に使い始めた人が最初につまずくのは、モデルの性能というより 入力側の負荷 です。

多くの「プロンプトエンジニアリング」やテンプレートは、だいたい次の要素を求めます。

目的（何を達成したいか）
背景／前提（何が起きているか、何を知っているか）
制約（やってはいけないこと、守るべき条件）
望ましい出力形式（箇条書き、表、コード、章立てなど）
例（Few-shot）や評価観点（何を良しとするか）

これ自体は妥当です。問題は、この「埋めるための材料」を、最初から出せる人ばかりではないことです。

そもそも頭の中のイメージが曖昧で、目的や制約が言葉になっていない
どこが分かっていないのか（不足情報）が自分では分からない
テンプレを前にすると固まり、雑に埋めてズレるか、諦める

結果として、プロンプト技法が示す「正しい型」に到達できず、AI活用が停滞します。

この課題は「怠慢」ではなく、**人間の認知特性（言語化・構造化の難しさ）**と直結しています。
次章で、その根拠を研究・心理学・哲学の観点から押さえます。

プロンプトエンジニアリングの参考情報：

1. なぜ「最初から整理して書く」が無理ゲーなのか

この章では、「言語化・構造化・指示出しが難しいのは、能力というより“人間の仕様”に近い」という前提を、研究・心理学・哲学の観点で補強します。

1-1. 内省は万能ではない：自分の思考過程を正確に言い当てにくい

最初から「目的・根拠・制約」を自力で完全に書けないのは自然です。

“they do not do so on the basis of any true introspection.”
— Nisbett & Wilson (1977), Telling More Than We Can Know: Verbal Reports on Mental Processes.

1-2. 分かっている“つもり”が起きる：説明すると穴が見える

構造化が難しいのは怠慢ではなく、“錯覚”が混ざるからです。

“People feel they understand complex phenomena with far greater precision, coherence, and depth than they really do …”
— Rozenblit & Keil (2002), The misunderstood limits of folk science: an illusion of explanatory depth.

1-3. 暗黙知：知っているのに、言葉にできない

最初から仕様（言葉）として吐けないのは当然。後から引き出す設計が必要です。

“we can know more than we can tell.”
— Michael Polanyi (1966/1967), The Tacit Dimension.

1-4. ワーキングメモリの限界：同時に保持できる量が小さい

「前提→制約→例外→完了条件」を一気に書く要求は、人間の認知仕様に対して厳しめです。

“A single, central capacity limit averaging about four chunks is implicated …”
— Cowan (2000/2001), The magical number 4 in short-term memory: A reconsideration of mental storage capacity.

1-5. 自然言語は本質的に曖昧：指示は解釈が分岐する

「最初から誤解なく指示を書く」こと自体が構造的に難しい。だから、質問で確定させる運用が合理的です。

“Since natural language is inherently ambiguous … avoiding ambiguity is by no means a trivial task.”
— Glinz (2009), On Non-Functional Requirements（章内の議論）

1-6. 既存アプローチ：モノローグ法／ラバーダックデバッグは有効だが、まだ“壁”が残る

言語化が難しい人へのアプローチとして、すでに有効な方法があります。

モノローグ法（意識的に独り言を出す）

目的：頭の中の曖昧なイメージを、まず「言葉として外に出す」
強み：タイピングよりは出力しやすく、発想の断片が出やすい
ただし壁：「意識的に独り言を出す」こと自体が、内省を引き出す営みであり、一定の言語化が必要
- つまり、言語化弱者ほど「そもそも独り言が続かない／出てこない」ことがある

ラバーダックデバッグ（無生物に説明して気づきを得る）

目的：説明というアウトプットで、思考を整理し、矛盾や抜けに自分で気づく
強み：「説明した瞬間に自分で気づく」効果（ラバーダック的効果）が得られる
ただし壁：対話ではないため、自分で質問を作り、自分で“対話のリズム”を回す必要がある
- 言語化弱者ほど「何を聞けばいいか」から詰まりやすい

2. 解決策：質問駆動ワークフロー

ここまでの前提を踏まえると、解決策は次の形に落ちます。

最初から整理して書かない
AIを“聞き手・相談役”にする
AIが質問し、あなたは答える。
最後にAIが整理する。

本記事では、この進め方を 質問駆動ワークフロー と呼びます。
ポイントは「うまい命令文を書く」ではなく、“不足情報を質問で集める”運用に切り替えることです。

2-1. なぜ有効なのか（課題への対応関係）

このワークフローは、0章で挙げた「テンプレを埋めるための言語化・構造化が難しい」という課題を、次の形で解消します。

材料を「一括提出」させない
- 人間にとって高負荷な「目的・前提・制約を一気に文章化」を要求しない
- 代わりに、質問に 1つずつ答える だけに分割する（ワーキングメモリ的に扱いやすい）
不足情報を“本人に気づかせる”のではなく、AIが検出して聞く
- 言語化弱者が詰まりやすいのは「何が分からないかが分からない」状態
- AIが質問を作り、穴を埋める順序を提供する
“それっぽく走る”のを止める（言い換え確認）
- AIが理解を短く言い換え、合意を取りながら進むことで、ズレを早期に潰せる
最後に構造化して“成果物の土台”を残す
- 会話の断片を「目的／前提／制約／論点／未確定／次アクション」に固定化できる
- 以後はこの合意版をもとに、仕様・文章・タスク・コード方針に落とせる

2-2. 得られる効果（言語化弱者にとって）

「うまいプロンプト」を考える前に 会話が始められる（初動の摩擦が小さい）
断片が集まり、AIが整理することで 自分の考えが可視化される
「結局なにが論点だったか」が残り、次の一手が明確になる
説明する過程で ラバーダック的な気づきも得やすい（しかも質問がリズムを作る）

2-3. 全体像（5ステップ）

定型文をコピペして開始：最初に「聞き手（相談役）」としての役割とルールを宣言する
断片の投入（雑でOK）：箇条書き、途中経過、愚痴でもよい
質問（AI）→回答（あなた）：AIが不足情報を埋めるために質問する
言い換え確認（AI）：AIが理解を言い換え、「合ってる？」を取る
要約・構造化→成果物へ：目的／前提／制約／論点／未確定／次アクションに整形し、仕様・文章・タスク等に落とす

4. コピペで始める「役割付与」：テンプレ埋めより簡単に回す

言語化弱者がプロンプトエンジニアリングで詰まる典型はこれです。

テンプレ（出力形式／前提／制約／評価基準…）は用意されている
でも、そのテンプレを埋めるための材料（言語化・構造化）が出てこない
結果、テンプレを眺めて固まる／雑に埋めてズレる／挫折する

質問駆動ワークフローは逆です。

最初に定型文（コピペ）を1回入れるだけ
それ以降は、フランクな会話（質問に答えるだけ） で進む
「テンプレを埋める」ではなく「会話で材料を集め、最後にAIが整える」

4-1. まずはこれだけ（聞き手モード）

会話を開始するときに、以下を そのままコピペ してください。

あなたは私の「聞き手（相談役）」です。評価や査定はしません。
目的は、私の頭の中の断片から“やりたいこと”を具体化すること。

ルール：
- 質問は1つずつ（重要度順）
- 私の回答を短く言い換えて「合ってる？」と確認してから次へ
- 私が詰まったら、選択肢を3つ出して選ばせて
- 最後に、目的／前提／制約／論点／未確定／次アクションに整理して

4-2. 会話が散らかったら（編集者モード）

会話が発散し、方向性を見失ったときに、以下を そのままコピペ してください。

ここまでの会話を、以下のフォーマットに要約・構造化してください。
- 目的：
- 前提：
- 制約：
- 論点：
- 未確定事項（追加で聞くべきこと）：
- 次アクション（優先度順）：
矛盾や不足があれば指摘し、追加質問を出してください。

4-3. “それっぽさ”で事故らない（検収モード）

AIの対話内容に違和感を覚える場合、以下を そのままコピペ してください。

次の観点でセルフレビューしてください：
1) 目的に対してズレていないか
2) 前提と矛盾していないか
3) 制約に違反していないか
4) 仮定している点は何か（列挙）
5) 重要な数字・固有名詞・否定（〜ではない）は復唱して確認
不足があれば、追加質問を先に出してください。

5. 実例：言語化できない状態から、会話で前に進む（対話ログ）

題材は「社内向け新機能（仕様の叩き台）」です。
“最初から整理できない状態” から始め、質問駆動で 合意版（構造化） まで到達します。

5-1. 断片投入（ユーザー：雑でOK）

ユーザー

新機能を入れたい。要望が多い。  
ただ既存APIは変えたくないし、運用も増やしたくない。  
画面も増やしたくない気がするけど、そこは未定。  
何から考えればいいか分からない。

5-2. AIが“聞き手”として、1問ずつ材料を集める

AI（聞き手）

まず「困りごと」を特定したいです。質問1：その要望でユーザーは何に困っていますか？（手間／ミス／待ち時間／やり直し など）

ユーザー

一番は「やり直し」です。提出後に差し戻されることが多い。

AI

言い換えます：目的は「差し戻し（やり直し）を減らす」で合っていますか？

ユーザー

合ってます。

AI

質問2：差し戻しは、どのタイミングで・何が原因で起きていますか？分かる範囲で3つ挙げてください。

ユーザー

(1) 入力ミス、(2) 添付不足、(3) 申請区分の選択ミス。  
あと、差し戻し理由が分かりづらいという声もあります。

AI

言い換え：主因は「入力」「添付」「区分」。追加の痛点が「理由の分かりづらさ」。合っていますか？

ユーザー

合ってます。

AI

質問3：成功の定義を決めたいです。差し戻しを減らす、とは「何がどうなったら成功」ですか？（数値でも状態でもOK）

ユーザー

差し戻し率が半分くらいになれば成功。  
あと、理由が見れば分かる状態にしたい。

AI

確認：成功は「差し戻し率を約50%削減」＋「理由が自己解決につながる可視化」。OKですか？

ユーザー

OK。

AI

質問4：制約です。変えられないのは「既存API不変更」「運用負荷増NG」以外にありますか？（期限、監査、権限、外部連携 など）

ユーザー

監査対応があるので、ログは増やせない（増やすと監査設計が面倒）。  
期限は2ヶ月。権限は今のロールを増やせない。

AI

言い換え：制約は「API不変更」「運用増NG」「ログ増NG（監査都合）」「2ヶ月」「権限ロール増NG」。合っていますか？

ユーザー

合ってます。

AI

質問5：画面を増やしたくない理由は何ですか？詰まったら選択肢を出します。  
（1 UXが複雑 / 2 実装工数 / 3 審査・運用 / 4 なんとなく）

ユーザー

3です。審査が増えて面倒。UXも少し。

AI

了解です。画面追加は「審査・運用の都合で慎重」、UXも懸念。合っていますか？

ユーザー

はい。

5-3. ここで合意版（要約・構造化）を作って、ズレを止める

AI（編集者）

ここまでを合意版として整理します。間違いがあれば直してください。

- **目的**：申請の差し戻し（やり直し）を減らす  
- **成功の定義**：差し戻し率を約50%削減／理由が分かり自己解決できる  
- **現状の主因**：入力ミス、添付不足、申請区分の選択ミス／理由が分かりづらい  
- **制約**：既存API不変更／運用増NG／ログ増NG（監査）／期限2ヶ月／権限ロール増NG／画面追加は審査・運用上慎重（UXも懸念）  
- **論点**：  
  1) 画面追加なし（or最小）で、入力・添付・区分ミスをどう減らすか  
  2) 差し戻し理由の可視化をどう実現するか（ログ増を避けつつ）  
- **未確定（追加質問候補）**：  
  - 差し戻し理由は現状どこにある？（自由記述？コード？）  
  - 必須添付は区分で変わる？ルールはある？  
  - 入力ミスの具体例（桁、形式、必須漏れなど）  
- **次アクション案（優先度順）**：  
  1) 申請前の事前チェック（入力・添付・区分）をUI内で出す  
  2) 理由の表示を“読みやすい形”に整える（自由記述の整形・要約など）  
  3) 画面追加が難しいなら、同一画面内のガイド／エラー設計で改善する

7. 補助：音声入力は、言語化弱者が“本質の対話”に集中するための強力な武器

質問駆動ワークフローの最大のボトルネックは、最初の「断片投入」です。
ここでタイピングが重い人ほど、そもそも始められない。

だから音声入力は、言語化弱者にとって 認知負荷を一段下げる武器 になります。
（「文章を書く」ではなく「同僚に相談する」に近い動作に寄せられるからです）

手が止まりにくい：タイピングで固まるポイントを回避しやすい
断片を多く出せる：冗長・脱線・重複が混ざっても、素材が増える方が勝ちやすい
本質に集中できる：入力の摩擦が減る分、質問への回答（思考）に集中できる

おすすめ運用はこうです。

音声で、雑に状況を話す（脱線してもOK）
AIに「合意版（要約・構造化）」を作らせる
重要事項（数字・固有名詞・否定）は復唱確認する
そこから質問駆動を回す

参考文献（本文で言及したもの）

Nisbett, R. E., & Wilson, T. D. (1977). Telling More Than We Can Know: Verbal Reports on Mental Processes. Psychological Review.
Rozenblit, L., & Keil, F. (2002). The misunderstood limits of folk science: an illusion of explanatory depth. Cognitive Science.
Polanyi, M. (1966/1967). The Tacit Dimension.
Cowan, N. (2001/2005). Working memory capacity（“magical number 4”系の議論）
Requirements Engineering（自然言語要求の曖昧性に関する整理）
Hunt, A., & Thomas, D. (1999/2019). The Pragmatic Programmer.（ラバーダックデバッグの逸話として広く参照される）