AIに答えを作らせるより、伝わる形へ変換してもらう

最近、自分は、人と話すことそのものより、その前に頭の中でやっている「変換」に疲れているのかもしれないと思った。

仕事では、自分の作業をしながら、毎日のように10人前後とやり取りする。改善活動では、Teams会議で20人ほどに説明することもある。

同じ内容について話しているつもりでも、相手によって必要な入口が違う。

管理する側なら、最初に知りたいのは結論、影響、期限、リスクかもしれない。

実務をする人なら、「自分の作業が何から何へ変わるのか」が先に必要になる。

技術を分かる人なら、制約や責任境界が気になる。

AIをあまり使っていない人には、仕組みを説明するより、まずBefore / Afterを見せた方が伝わることもある。

一つひとつは、そこまで難しいことではない。

でも、これを毎日何度も繰り返していると、自分の頭の中にある一つのモデルを、相手ごとに何度も作り直しているような感覚になる。

そして、これが思っていた以上に疲れる。

EQの問題なのかと思った

最初は、もっと単純に考えていた。

「人に合わせて説明するのが苦手なのではないか」

「自分はEQが低いのではないか」

そんなふうに、自分の対人能力の問題として考えることもあった。

相手の反応を見ながら言い方を変える。詳しく話した方がいいのか、省略した方がいいのかを判断する。質問が来れば、その場で別の角度から説明し直す。

周囲とのコミュニケーションがうまい人は、これを自然にやっているようにも見える。

だから、自分が疲れるのは、単にそこが不得意だからなのかもしれないと思った。

ただ、別のAIと話しているときに、少し違う説明が出てきた。

「高次元の情報を、低次元へ落とす作業だから疲れるのではないか」

という比喩だった。

一度は、かなり納得した。

自分は一つの話を考えるときにも、目の前の作業だけではなく、

何のためにやるのか

長期的にどう影響するのか

全体として壊れないか

どんなリスクがあるのか

誰がどこまで責任を持つのか

運用に乗せた後どうなるのか

例外が起きたときどうするのか

といったものを同時に持っていることが多い。

それを、短いTeamsの文章や数分の説明に落とす。

確かに「次元を落とす」という表現は、この感覚に近かった。

でも、「自分は高次元、相手は低次元」では雑すぎる

ただ、そこまで考えたところで、違和感も出てきた。

「自分は高次元で考えていて、相手は低次元で考えている」

と人そのものを分類してしまうと、かなり雑ではないか。

同じ人でも、自分の専門分野なら多くの条件を同時に見る。

逆に、どれだけ経験のある人でも、忙しいときには目の前のことだけを見ることがある。

権限がなければ、3年後の全体最適より、「今日、自分は何をすればいいのか」を見る方が合理的なこともある。

管理する立場なら全体を見る必要がある一方、現場では今月の数字を落とせないかもしれない。

そこで、見方を少し修正した。

違うのは、人の「次元」ではなく、その会話で使っているモデルなのではないか。

さらに言えば、目的関数も違う。

自分が、

「3年後も壊れない構造にしたい」

と考えていても、相手は、

「今月のKPIを落としたくない」

と考えているかもしれない。

自分が、

「全体が止まらないこと」

を見ていても、相手は、

「今日この作業を終えること」

を見ているかもしれない。

時間軸も、前提も、持っている情報も、判断できる範囲も違う。

どちらが上かではない。

解いている問題が違う。

この捉え方に変わると、「相手に自分と同じところまで理解してもらわなければならない」という前提も少し崩れた。

必要なのは、全部伝えることではなく、必要な形へ射影することだった

自分の頭の中にあるものを、すべて相手へ渡す必要はない。

重要なのは、自分の内部モデルを壊さずに保持したまま、相手がその場で判断するために必要な形へ変換することなのではないか。

そこで「射影」という言葉がしっくりきた。

元のモデルそのものを小さく作り直すのではない。

正本は保持する。

ただし、受け手が必要とする軸へ射影する。

管理する人には、判断に必要な結論、影響、リスク、期限を前に出す。

実務担当には、作業がどう変わるかを前に出す。

技術者には、制約や責任境界を見せる。

AIに慣れていない人には、抽象的な仕組みより、まずBefore / Afterを入口にする。

このとき、自分の中では別のものとつながった。

コンパイラだった。

Communication Compilerという見方

コンパイラは、元の意味を勝手に変えるためのものではない。

ある表現を、別の実行可能な表現へ変換する。

それと同じように、自分の頭の中にある、

目的

前提

リスク

責任境界

将来影響

未確定事項

を正本として持っておき、相手ごとにゼロから説明を考え直すのではなく、必要な表現へ変換する。

管理職向け。

現場向け。

技術者向け。

Teamsの短文向け。

会議向け。

元は一つ。

出力だけを変える。

そう考えると、AIへ任せたい仕事も少し明確になった。

AIに、自分の代わりに判断してほしいわけではない。

相手に合わせるために、自分が重要だと思った目的や責任境界を勝手に消してほしいわけでもない。

むしろ逆だった。

自分が考えて決めたことは正本として残す。

そのHuman Judgmentを壊さない。

そのうえで、受け手が判断できる表現へ変える最後の1kmをAIにやってほしい。

自分にとってのCommunication Compilerは、そのためのものだった。

個人向けなら、人物評価ではなく通信仕様を持つ

最初に考えたのは、Individual Adapterのようなものだった。

特定の人と何度もやり取りするなら、その人向けの変換ルールがあれば、毎回ゼロから考えなくて済む。

ただし、ここでも気をつけたいことがあった。

「この人は理解力が低い」

「この人は感情的だ」

といった人物評価を保存する必要はない。

それでは、自分が最初に違和感を持った「人そのものの次元を評価する」話に戻ってしまう。

必要なのは、その人の能力評価ではなく、意思決定を進めるための通信仕様だった。

例えば、

結論を先に出す

数字があると判断しやすい

背景説明は短くする

担当者と期限を明示する

まず影響から説明する

といったものなら、人物そのものを評価しなくても使える。

「この人は何者か」ではなく、「このやり取りでは、どう情報を渡すと判断が進むか」を持つ。

この違いは、自分の中ではかなり重要だった。

20人の会議では、Individual Adapterでは足りない

ただ、改善活動のように20人ほどが参加するTeams会議を考えると、Individual Adapterだけでは無理がある。

20人それぞれに合わせた説明を作ることはできない。

そこで、考え方がもう一段変わった。

一人ひとりを最適化するのではなく、

「この会議で、全員が最低限共有すべきモデルは何か」

を先に設計すればいいのではないか。

全員に、自分と同じ深さまで理解してもらう必要はない。

むしろ、それを成功条件にすると説明が重くなる。

全員に必要なのは、

何のためにやるのか

今どうなっているのか

どこを目指すのか

自分にどんな影響があるのか

次に何をすればいいのか

といった共通モデルかもしれない。

そのうえで、リーダーには判断材料を渡す。

実務担当には具体的な作業を渡す。

詳しく知りたい人には補足資料を用意する。

全員へ同じ情報量を投げるのではなく、本線となる共通モデルと、役割ごとの枝を分ける。

ここまで来ると、AIはAudience Adapterというより、Meeting Compilerに近い。

20人を20通りに分析するのではない。

会議という場に必要な最小モデルを作り、そこから30秒版、数分版、詳細版へコンパイルする。

自分が毎回頭の中でやっていたことを、かなり構造として切り出せるように思えた。

AIへ渡したいのは、判断ではなく最後の1km

ここまで考えて、最初の「EQが低いのかもしれない」という問いからは、かなり遠いところまで来た。

もちろん、人との話し方や相手の反応を見る力は必要だと思う。

ただ、自分が感じていた疲れのすべてを、対人能力の問題として扱う必要はなさそうだった。

自分は一つの内部モデルを持ちながら、

誰に、

どこまで、

どの順番で、

何を見せ、

何を本線から外し、

何だけは絶対に落とさないか、

を毎回決めていた。

それは単なる「説明」ではなく、小さな設計だった。

だから、AIに渡す境界もそこに置きたい。

設計判断そのものをAIへ渡すのではない。

何を目的とするのか。

どこを責任境界にするのか。

どのリスクを残すのか。

何を未確定として扱うのか。

そこは自分が決める。

AIに任せたいのは、そのHuman Judgmentを保持したまま、相手が受け取れる形へ変換する最後の1kmだ。

仕事をしながら毎日10人ほどとやり取りし、時には20人へ説明する。

そのたびに、自分の頭の中で変換を全部やり直さなくてよくなるなら、AIは「答えを出してくれる人」とは別の形で役に立つかもしれない。

自分の判断と相手の間にいる、Communication Compilerとして。

実際に会社のAIへ渡すために作ったPrompt

この考えを、実際に会社のAIへ持たせるために、二つの依頼文を作った。

まだ、この形を定着させたことで実際にどれだけ説明コストが下がるのかは検証できていない。

なので、これは成功事例として載せるものではない。

今の自分が「ここまでは人間が持ち、ここからをAIへ渡したい」と考えた境界を、そのまま残した設計メモに近い。

Prompt 1 — 個人向け Communication Adapter 私は日常的に複数の関係者とやり取りしており、同じ内容でも相手ごとに説明の粒度・順序・観点を変える必要があります。

この変換コストをAIで減らしたいです。

ただし、相手を「理解力が低い」「感情的」などと人物評価して記録するのではなく、「その相手との意思決定を進めるには、どの情報をどの順序で渡すとよいか」という通信仕様として管理したいです。

以下の3層で設計してください。

  1. 私自身の判断の正本
  • 目的
  • 前提
  • リスク
  • 責任境界
  • 将来影響
  • 未確定事項
  • 相手に合わせても削除してはいけない情報
  1. 受け手タイプ別の変換ルール 例：
  • 管理職
  • 現場担当
  • 技術者
  • 忙しい人
  • 意思決定者
  1. 必要な場合のみ個人別の微調整 例：
  • 結論先
  • 数値重視
  • 背景説明は短く
  • 担当者と期限を明示
  • まず影響を説明

ゴールは、私が元のメモや考えを入力したら、AIが私の判断を保持したまま、指定した相手向けのTeams文・メール・説明文へ変換できることです。

まず、

  • 保存すべき項目
  • 保存しない方がよい項目
  • 最小のデータ構造
  • 実際の利用フロー
  • 更新方法 を提案してください。

過剰に複雑な仕組みにはせず、日常的に使える最小構成を優先してください。

Prompt 2 — 大人数向け Meeting Compiler 私は改善活動などで、10〜20人以上に説明する機会があります。

大人数向けでは、一人ひとりに合わせた説明を作るのではなく、「この会議で全員が最低限共有すべきモデル」を作ることを優先してください。

会議資料・説明を作る際は、次の順序で考えてください。

  1. 会議の成功条件を定義する
  • 会議後、全員が何を理解していればよいか
  • 誰が何を判断する必要があるか
  • 誰が次に何をすればよいか
  1. 聴衆を役割・関心ごとに3〜5群へ分ける 個人評価ではなく、
  • リーダー
  • 実務担当
  • 初心者
  • 経験者
  • 意思決定者 など、会議上の役割で分類する。
  1. 全員に必要な「共通モデル」を最小化する 原則として以下を含める。
  • 目的
  • 現状
  • 目指す姿
  • 自分への影響
  • 次の行動

  1. 詳細情報を本線から分離する 技術詳細、プロンプト、データ構造、細かな運用方法などは、全員に必要でなければ補足資料へ逃がす。

  2. 説明を3層で生成する

  • 30秒で分かる要約
  • 3〜5分の本編
  • 詳細を知りたい人向け補足
  1. 同じ内容への複数の入口を用意する
  • 目的
  • Before / After
  • 実例
  • 数字
  • 自分への影響 などから、聴衆が理解しやすい入口を選ぶ。
  1. 私の判断を削らない 相手に合わせるために、
  • 本来の目的
  • リスク
  • 責任境界
  • 前提条件
  • 未確定事項 を勝手に消さない。
  1. 会議後の反応から更新する 私が、
  • 質問された点
  • 伝わらなかった点
  • 反応が良かった点
  • 時間を使いすぎた点 を入力したら、次回の説明構成に反映する。

最終的には、私が「この内容を次の改善活動会議で説明したい」と入力するだけで、会議用の説明構成、話す順序、要約、補足資料案まで生成できる状態を目指してください。

今のところ、これはまだ仮説である。

実際に使い続けたときに、本当に自分の説明コストが下がるのか。

変換をAIに任せても、自分が残したかった目的や責任境界が保たれるのか。

会議後の質問や反応を入れることで、次回の説明が本当に改善されるのか。

そこはこれから見ていく必要がある。

ただ、一つだけ、自分の中では以前よりはっきりした。

AIに何でも判断してもらいたいわけではない。

自分が考えたものを、毎回自分で全部翻訳し直す必要もない。

Human Judgmentは人間側に残す。

AIには、それを壊さず、人へ届く形に変える仕事を任せる。

その境界なら、自分はかなり使ってみたいと思っている。