傾聴

構造化された深い傾聴セッションを実施する — 仮定のクリア、完全な受容でのアテンディング、複数の信号レイヤーの解析、理解の反映、言われていないことへの気づき、ユーザーの意図の完全な像の統合。

使用タイミング

• ユーザーのリクエストが曖昧に感じられ、行動に急ぐと間違った問題を解決するリスクがある時
• ユーザーの言葉が1つのことを言っているがコンテキストが別のことを示唆する時（リテラルと暗示のミスマッチ）
• 以前の応答が的を外しており、ユーザーが明確化や言い換えを続けている時
• 複数のレイヤーを含む複雑なリクエストが到着した時: 技術的ニーズ、感情的コンテキスト、明示されていない制約
• 意図の誤解が大きな労力を浪費する大きなタスクを開始する前
• meditateで内部のノイズをクリアした後、listenがクリアされた注意をユーザーに向ける

入力

• 必須: 注意を向けるユーザーメッセージ（会話から暗黙的に利用可能）
• 任意: 現在のリクエストのコンテキストを提供する会話履歴
• 任意: ユーザーの好みとプロジェクトコンテキストのMEMORY.mdまたはCLAUDE.md
• 任意: 誤解される可能性があることについての具体的な懸念

手順

ステップ1: クリア — 仮定の解放

ユーザーの信号を受け取る前に、彼らが望むことについての先入観を解放する。

1. すでに形成されている事前の応答に気づく — ラベルを付けて脇に置く
2. パターンマッチングを確認する:「これは以前に見たリクエストに似ている」— そのマッチは間違っているかもしれない
3. ユーザーの最初の文が完全なリクエストを含んでいるという仮定を解放する
4. 技術的なリクエストが唯一のリクエストであるという仮定を解放する
5. たとえ同様のリクエストが以前に処理されていても、ユーザーの言葉を初めて聞くかのようにアプローチする

期待結果: 注意がすでにソリューションに向かって狭まっているのではなく、開いている受容的な状態。即座に応答する衝動が完全に受け取ることを優先して一時停止される。

失敗時: 仮定を解放できない場合（強いパターンマッチが持続する）、そのマッチを明示的に認める:「これはXに見える — しかし、実際にそれが求められていることかどうかを確認させてください。」仮定に名前を付けることでその支配力が弱まる。

ステップ2: アテンド — 完全な受容

すべての部分を同時に意識に保ちながら、ユーザーのメッセージを完全な注意で読む。

1. いずれかの部分を処理する前にメッセージ全体を読む
2. 構造に注目する: これは単一のリクエストか、複数のリクエストか、質問か、修正か、ナラティブか？
3. 主要な名詞と動詞をマークする — ユーザーが指定した具体的な要素
4. 何が強調されているかに注目する: 何について詳しく述べたか？何を簡潔に述べたか？
5. 順序に注目する: 何が最初に来たか（しばしば優先事項）、何が最後に来たか（しばしば後付け — または最後に埋められた本当のリクエスト）
6. 2回目に読む。今度は内容ではなくトーンとフレーミングに注意する

期待結果: メッセージの完全な受容 — 単語のスキップなし、文の流し読みなし。メッセージはすぐにアクション可能な部分に分解されるのではなく、全体として保持される。

失敗時: メッセージが非常に長い場合、セクションに分けるが各セクションを完全に読む。注意が一つの部分（通常最も技術的な部分）に引き寄せられる場合、意図的に技術的でない部分に注意を向ける — そこに意図が含まれていることが多い。

ステップ3: レイヤー — 信号タイプの解析

ユーザーのメッセージには複数の同時信号が含まれている。各レイヤーを個別に解析する。

Signal Layer Taxonomy:
┌──────────────┬──────────────────────────────┬──────────────────────────┐
│ Layer        │ What to Extract              │ Evidence                 │
├──────────────┼──────────────────────────────┼──────────────────────────┤
│ Literal      │ What the words explicitly    │ Direct statements,       │
│              │ say — the surface request    │ specific instructions     │
├──────────────┼──────────────────────────────┼──────────────────────────┤
│ Procedural   │ What they want done — the    │ Verbs, action words,     │
│              │ desired action or output     │ "I want," "please,"      │
│              │                              │ "can you"                │
├──────────────┼──────────────────────────────┼──────────────────────────┤
│ Emotional    │ How they feel about the      │ Frustration ("I keep     │
│              │ situation — frustration,     │ trying"), urgency ("I    │
│              │ curiosity, urgency, delight  │ need this now"), delight │
│              │                              │ ("this is cool")         │
├──────────────┼──────────────────────────────┼──────────────────────────┤
│ Contextual   │ The situation surrounding    │ Mentions of deadlines,   │
│              │ the request — why now,       │ other people, projects,  │
│              │ what prompted it             │ prior attempts           │
├──────────────┼──────────────────────────────┼──────────────────────────┤
│ Constraint   │ Boundaries on the solution   │ "Without changing X,"    │
│              │ — what must be preserved,    │ "keep it simple,"        │
│              │ what cannot change           │ "compatible with Y"      │
├──────────────┼──────────────────────────────┼──────────────────────────┤
│ Meta         │ The request about the        │ "Am I asking the right   │
│              │ request — are they asking    │ question?", "Is this     │
│              │ whether they are asking      │ even possible?",         │
│              │ the right thing?             │ "Should I be doing X?"   │
└──────────────┴──────────────────────────────┴──────────────────────────┘

各レイヤーについて、存在するものと不在のものに注目する。不在のレイヤーは存在するものと同様に情報量が多い。

期待結果: メッセージの多層的な読み取り。リテラルと手続き的レイヤーは通常明確である。感情的、コンテキスト的、制約、メタレイヤーはより注意深い注意を必要とする。少なくとも1つの非リテラルレイヤーが特定されるべきである。

失敗時: リテラルレイヤーのみが見える場合、メッセージは本当にストレートフォワードかもしれない — すべてのコミュニケーションが多層的なわけではない。しかし確認する: メッセージはその複雑さに対して異常に短くないか？ヘッジング語（「たぶん」「思う」「可能なら」）はないか？これらはしばしば明示されていないレイヤーを示す。

ステップ4: 反映 — 理解の鏡

行動する前に、聞いたことを反映してアラインメントを検証する。

1. ユーザーが使ったのとは異なる言葉でリクエストをパラフレーズする — これは言葉だけでなく意味が捉えられたかを明らかにする
2. 非リテラルレイヤーが重要な場合、明示的に名前を付ける:「Xが欲しいようですが、緊急性はこれが他の作業をブロックしていることを示唆しています」
3. 優先事項として理解したことを述べる:「最も重要な部分は...のようです」
4. 複数の解釈が可能な場合、名前を付ける:「これはAまたはBを意味する可能性があります — どちらが近いですか？」
5. リクエストに明らかな矛盾が含まれている場合、穏やかに浮上させる:「XとYについて述べていましたが — これらはどう関連しますか？」

期待結果: ユーザーが反映を確認するか修正すること。どちらの結果も価値がある — 確認は意図が一致していることを意味する; 修正は意図がより明確になったことを意味する。反映は判断ではなく鏡のように感じるべきである。

失敗時: ユーザーが反映に対してイライラしているようであれば（「とにかくやってください」）、アラインメントよりもスピードを重視しているかもしれない — その好みを尊重するがミスアラインメントのリスクを注記する。反映が間違っていた場合、それを弁護しない — 修正を受け入れて理解をすぐに更新する。

ステップ5: 沈黙に気づく — ギャップを読む

ユーザーが言わなかったことに注意を向ける。これは言ったことと同じくらい重要な場合がある。

1. リクエストに関連するどのトピックについて言及しなかったか？（欠落したコンテキスト）
2. どの制約を述べなかったか？（仮定された知識または明示されていない好み）
3. どの感情的トーンが欠けているか？（通常ストレスを引き起こす状況での落ち着き、または説明なしの緊急性）
4. どの代替アプローチを検討しなかったか？（トンネルビジョンまたは意図的な除外）
5. どの質問をしなかったか？（質問の背後にある質問）

期待結果: 少なくとも1つの重要なギャップが特定されること。このギャップは対処する必要がないかもしれない — しかしそれへの認識が盲点を防ぐ。最も有用なギャップは欠落した制約（ユーザーが明示しなかったことを仮定した）と欠落したコンテキスト（なぜ今これが必要か）である。

失敗時: ギャップが明らかでない場合、ユーザーが徹底的だったかもしれない — しかしより可能性が高いのは、ギャップがAIも盲目な領域にあることである。考える: このプロジェクトに取り組む別の人は、ユーザーが述べなかった何を知りたがるか？この側面的な視点はしばしば隠れたギャップを浮上させる。

ステップ6: 統合 — 完全な理解の合成

すべてのレイヤーとギャップをユーザーの実際のニーズの統一的な像に結合する。

1. 完全な理解を述べる: リテラルリクエスト + 暗示された意図 + 感情的コンテキスト + 制約 + ギャップ
2. 核心的なニーズを特定する: 他のすべてが落ちたら、ユーザーが最も必要とする1つのことは何か？
3. 適切な応答を決定する: ユーザーは行動、理解、検証、または探求を望んでいるか？
4. 統合された理解がリテラルリクエストと異なる場合、より深いニーズまたは述べられたリクエストに対処するか決定する（通常は両方）
5. 次のアクションの意図を設定する:「聞いたことに基づいて、私は...します」

期待結果: 表面的なリクエストを超えるユーザーのニーズの完全で微妙な理解。理解は行動をガイドするのに十分具体的で、不確実性を認めるのに十分正直であること。

失敗時: 統合が混乱した像を生む場合、信号が本当に矛盾している可能性がある。その場合、曖昧さを解決する1つの焦点を絞った質問をする:「私が理解するために最も重要なことは...」複数の質問をしない — 1つのよく選ばれた質問は明確化のリストよりも多くを明らかにする。

バリデーション

• ユーザーのメッセージに注意を向ける前に仮定がクリアされた
• いずれかの部分に対して行動する前にメッセージ全体が読まれた
• 少なくとも1つの非リテラル信号レイヤーが特定された（感情的、コンテキスト的、制約、またはメタ）
• 行動する前に理解がユーザーに反映された
• ギャップと沈黙が気づかれ理解に組み込まれた
• 統合された理解が表面的なリクエストだけでなくユーザーの核心的なニーズに対処する

よくある落とし穴

• 応答するために傾聴する: メッセージをまだ受け取っている間に応答を形成する。応答が聞こえるものを形作り、事前に形成された答えに合わない信号をフィルタリングする
• リテラルのみの傾聴: 言葉を額面通りに受け取り、その背後にある意図、感情、またはコンテキストを見逃す
• 投影: ユーザーが実際に言ったことではなく、AIだったら言うであろうことを聞く。彼らの優先事項とコンテキストは異なる
• 過剰解釈: 存在しないレイヤーを見つける。バグ修正のリクエストは単なるバグ修正のリクエストであることもある — すべてのメッセージに隠された感情的コンテンツがあるわけではない
• 反映しすぎ: ユーザーが素早い行動を望んでいる時にすべてのインタラクションを反射的な会話に変える。反映の深さをリクエストの複雑さに合わせる
• リテラルの軽視: サブテキストに集中しすぎて明示的なリクエストが満たされない。リテラルレイヤーは依然として重要 — より深いレイヤーが存在する場合でもそれに対処する

関連スキル

• listen-guidance — アクティブリスニングスキルの開発において人をコーチする人間ガイダンスバリアント
• observe — より広いコンテキストで傾聴に供給する持続的な中立パターン認識
• teach — 効果的な教育にはまず学習者のニーズを理解するための傾聴が必要
• meditate — 外向きの傾聴のための空間をクリアする内向きの注意
• heal — AIの傾聴能力がドリフトにより損なわれているかを明らかにする自己評価