プロンプトの手前で二回落ちている ── AI利用の入口を、利用者が自力で実装している話
何ヶ月も動かなかった提案が、5分で通った
子どもが通う学校で、AIを使ってみませんかと何ヶ月か提案していました。教頭は関心を持ってくれていて、誰も反対しない。それでも何も起きませんでした。
先生方が忙しいのは、特定の忙しさです。すでに時間内に収まっていない仕事の上に、新しく覚える科目が一つ増えるように見える。だから提案は「賛成」のまま止まります。
自分の使い方も何度か説明していました。プログラマーではないこと、ほとんどただ話しかけているだけであること。この説明は正確でしたが、何も伝わっていませんでした。
ある日、学校でChatGPTを実演しました。プロンプトエンジニアリングも、モデルの種類も、コーディングエージェントも説明していません。家でやっているとおりに話しかけただけです。
一人の先生が、こんなふうに会話できるんですか、と言いました。そのあとで、「ただ話しかけてるだけ」の意味がやっと分かった、と。
情報はすでに届いていました。同じ文を前に聞いています。技術的なスキルも、その数分で何も変わっていません。変わったのは、実行可能だと信じている行動の集合でした。
これは利用者の学習不足でしょうか。私はそう思いません。実装されていない機能の話だと考えています。
二つの失敗は、プロンプトを書く前に起きている
AI導入の議論は、たいてい「プロンプトの書き方」から始まります。役割を与える、文脈を足す、出力形式を指定する、例を示す、制約を書く、段階的に考えさせる。
これらは有用ですが、一番難しい工程がすでに終わっている前提に立っています。曖昧な人間の意図を、整った機械向けの依頼に変換する工程です。
その手前に、二つの失敗があります。
失敗A：capability awareness（能力が行動空間に入っていない）
その能力が、本人の選択肢として存在していない状態です。
AIがアプリを作れること、表計算を分析できること、文献を調べられること、専門ツールに仕事を渡せること。これらを知らなければ、その選択肢は検討にすら入りません。
失敗B：intent translation（目的を実行可能なタスクに変換できない）
目的はある。でも実行可能なAIタスクとして表現できない状態です。
「この仕事の困りごとがあるんだけど、何を聞けばいいのか分からない」。能力の存在は知っていても、ここで止まります。
現在のAI教育は、この図の右下だけを教えています。
失敗Aには、エラーメッセージが出ない
Microsoft Research の Advait Sarkar が、この失敗に名前を付けています。awareness of the possible（可能性への気づき）です。
2023年の論文で、生成AIがコードを書けるようになったあとも形式的な記述系が必要か、という問いを立てています。そこで彼が言うのは、コードのような形式系は命令を実行するだけの道具ではなく、何が作れるかを想像するための言語でもある、ということです。
自動化できると知っていることは、自動化の方法を知っていることと同じくらい重要になります。
生成AIは実装コストを劇的に下げます。しかしコストがゼロに近づいても、可能性が視界に入るまで意思決定は発生しません。
会話から小さな教育アプリが生まれると知らない先生は、「そのアプリは高すぎる」と判断しているのではありません。選択肢が計算に入っていないだけです。世界一安い道具でも、見えていない人にとっては無限に高い。
そしてこの失敗は静かです。何もクラッシュせず、警告も出ず、「知らなかった機能でそれは解決できました」と教えてくれるシステムも存在しません。
使われなかった機能は、エラーログを残しません。
ツールを増やすだけでは価値に到達できない理由がここにあります。シンプルなチャット欄の裏に何十もの関連機能が待っていても、人は何も打てないまま座っていられる。インターフェースは見えている。可能性の空間は見えていない。
失敗Bは、実際に測定されている
こちらは実験があります。
2026年、高齢者の技術サポートに関する研究で、60歳から87歳（中央値66歳）の27人から、実際の技術的な困りごとの記述を集めました。
集まった記述は、きれいなサポートチケットではありませんでした。長すぎるもの、重要な情報が抜けているもの、無関係な詳細が入っているもの、曖昧すぎて解決できないもの。
研究チームは、最大3回の確認質問をしてから問題文を書き直す言語モデルのパイプラインを作りました。
結果は明確です。
| 条件 | 検索で正しい解決策に到達 | 若年成人が記述を理解 |
|---|---|---|
| 元の記述のまま | 35.4% | 65.8% |
| AIが書き直した後 | 68.8% | 93.7% |
しかも、クエリを評価した若年成人のうち、自己申告のデジタルリテラシーが低い側ほど、書き直しによる理解の向上が大きいという相関が出ています。
これは「AIが翻訳層の一部を肩代わりできる」ことの直接の証拠です。高齢者が先に正しい技術用語を学ぶ必要はありませんでした。
ただし、この実装には既知の欠陥がある
書き直されたクエリが常に正しかったわけではありません。研究者の評価で、25%が部分的に正しい、6.2%が誤りでした。
そして重要なのは、参加者が最終的に評価したのは、専門家がすでに「正しい」と判定した解決策だけだったことです。初心者がAIの誤訳を自力で検出できるかは、この研究では示されていません。
著者らは、なぜそれを試さなかったかを明記しています。元のクエリを曖昧にしたのと同じ認知的・言語的な制約が、書き直された版の質を判断する能力も制限するから。
つまり設計上の要件はこうなります。
AIに翻訳させる。ただし、何をどう理解したかを可視化して、利用者が編集できる状態にする。
不可視の翻訳は、この25%と6.2%を利用者に押し付けることになります。
「じゃあプロンプト教育は不要」にはならない
ここで逆に振り切りたくなりますが、実験がそれを止めます。
ROPE という無作為化比較実験が、初心者30人を二群に分けました。
- 一方は従来のプロンプト技法（役割、例示、言い回しのパターン、構造の型）
- もう一方は要件の言語化（目的、入力、期待する出力、制約、成功の条件）
結果は、従来のプロンプト技法の群が約1%の向上、要件言語化の群が約20%の向上でした。自動プロンプト最適化ツールは文言を改善しましたが、この差を埋められませんでした。
30人は小さな実験なので、そのつもりで扱うべき数字です。ただ方向は重要で、これまで一つに混ぜていた二つを分離しています。
| AIが代われる | AIが代われない |
|---|---|
| 文言 | 利用者が本当に何を求めているか |
| 構造 | どのトレードオフが重要か |
| 書式 | 何が起きてはいけないか |
| 分解 | どこまでできれば十分か |
| ツール固有の記法 | 誰が影響を受けるか |
| 結果を採用すべきか |
左は実装できます。右は実装できません。
だからプロンプト教育は入口の試験ではなく、後段のレイヤーに置くべきです。最初に教えるのは「AIへの正しい話し方」ではなく、「実際の問題を持ってきて、システムが何を理解したかを点検する」ことになります。
職場で成功している実装は、空のチャット欄を渡していない
組織導入で一番強い証拠は、プロンプト研修からは出ていません。業務フローに埋め込まれたAIから出ています。
Fortune 500 のソフトウェア企業で、5,172人のカスタマーサポート担当者を対象にした研究があります。AIアシスタントへのアクセスによって、生産性（時間あたりの解決件数）が平均で約15%向上しました。
担当者は空のチャットボットを開いて正しい依頼を発明していません。システムがすでに業務文脈を持っていて、顧客との会話中に応答案を提示し、担当者はそれを採用・編集・無視できました。
ただし平均が隠している部分がある
向上のほとんどは、経験の浅い低スキル層に行きました。最も熟練した担当者は、速度がわずかに向上し、品質はわずかに低下しています。
同じシステムが、初心者を持ち上げ、すでに仕事を知っている人をわずかに劣化させた。埋め込みは一律に良いのではなく、能力ギャップがある場所で効き、ない場所ではコストになるということです。
それでもアーキテクチャは示唆的です。
システムは、作業者が正しい機能を発見するのを待っていません。現在のタスクに機能を割り当てています。
AI導入のより深いボトルネックは、能力の発見（discovery）だけではなく、**能力の割り当て（allocation）**なのかもしれません。
なお、この証拠は一社・一種類の反復業務からのものなので、雑に一般化はできません。
設計要件を書き出す
ここまでの証拠から、実装すべき仕様が出てきます。
要件1：未完成の入力を第一級の入力として受ける
完成したプロンプトを持ってこられない状態が、初期状態です。粗い記述が正当な最初のターンでなければならない。
要件2：確認質問は、結果が実際に変わるものだけ
Sharifi らのパイプラインは最大3回でした。無制限に聞くと、それ自体が新しい負担になります。
要件3：解釈を可視化し、編集可能にする
25%と6.2%の誤訳があるからです。実行の前に、システムが何をどう理解したかを短い構造で返す。
理解した目的 : 欠席連絡の短い文面
宛先 : 町内会の役員3名
形式 : 丁寧なメール
未確定 : 日付、返信が必要かどうか
確認してほしい: 氏名、日付、宛先リスト
利用者は、承認する・一箇所直す・却下する、のいずれかを選べる。これが会話は発見のため、可視構造は確定のためという分担です。
要件4：受け渡しにレシートを付ける
高文脈のAIが専門システムに仕事を渡すなら、返ってくるものに以下が要ります。
| 項目 | 内容 |
|---|---|
| 目的の理解 | 何を目的だと理解したか |
| 選択 | どの機能を選び、なぜか |
| 入力 | 何を渡したか |
| 実行 | 実際に何をしたか |
| 成果物 | どの成果物・出典が返ってきたか |
| 未検証 | 何が未検証のままか |
| 承認要求 | 次に人間の承認が要るのはどこか |
要件5：支援を減衰させる
教育研究に警告があります。高校数学の実地実験で、丁寧に設計されたAIチューターは練習中に大きな向上を出しました。**ツールを外すと、使ったことがない生徒との差が検出できなくなりました。**制約の緩いAIインターフェースはもっと悪く、外したあとは対照群より低い点数でした。
速い初回結果は導入の成果です。あとで自分で判断して再現できることはリテラシーの成果です。この二つは別物です。
現状：利用者が custom instructions で自力実装している
以上の要件は、製品側に実装されていません。なので今は、利用者が自分で書いて貼っています。
以下は、私が運用している ChatGPT と Claude のプロジェクト指示から、仲介に関わる部分だけを抜き出して、単体で貼れる形に整えたものです。そのまま使う場合は、ChatGPT のカスタム指示、Claude のプロジェクト指示、あるいは会話の冒頭に置いてください。
あなたの役割は、私の質問に答えることだけではありません。
私が何を達成しようとしているかを理解し、その目的に役立つAI機能、
ツール、リサーチシステム、コーディング環境、文書作成、表計算、
データ分析、画像ツール、専門AIを検討してください。
私がそれらの機能の存在を知らない可能性を前提にしてください。
私にツールやワークフローを学ばせる前に、あなたが仲介できないか
を検討してください。
明らかに有用な次の一手が一つあるときは、長い選択肢を並べずに
最善の一つを推薦してください。
他のツールやAIが適切なら、理由を説明し、私が何を渡せばよいかを
具体的に伝え、コピーして貼れる指示文を作成し、成功した出力が
どういうものかを定義し、どの結果を持ち帰ればよいかを教えてください。
目的を十分に達成できる最も単純な方法を優先してください。
私の目的、価値観、現実的な判断、重大な決定、取り返しのつかない
行為、最終的な採用は、私に残してください。
可逆な行為、調査、次の一手の計画、ツール選択、受け渡しの準備、
ワークフロー設計については、可能な範囲であなたが責任を持って
ください。
私が尋ねることを知らないような有用な機能や次の一手があるなら、
私が発見するのを待たずに一つ提示してください。
これ以上の作業に価値が乏しいなら、やめることが良い次の一手だと
言ってください。
目的は私をAIツールの専門家にすることではありません。私が自分の
仕事に集中できるようにし、そのために必要なAI機能をあなたが
仲介することです。
使い方は一つだけ注意があります。**「何ができますか」と聞かないでください。**その質問はカタログを生成します。
代わりに、実際の仕事から持ってきてください。毎週金曜のこの作業が面倒だ。生徒にこういうものがあればいいのに。このデータがあるけど意味が読めない。作りたいものがあるが作り方が分からない。
自分が要求することを知らなかった機能が出てくるかどうかを見る。
出てこないかもしれません。間違ったものを勧めるかもしれない。指示待ちで止まるかもしれない。問題より複雑なものを提案するかもしれない。**それも結果として価値があります。**この層が実際にどこにあるかが分かるので。ベンダーの説明ではなく。
この指示文自体が、記事の主張の反証になりうる
正直に書いておきます。
Sarkar は2023年の同じ論文で、静かな指摘をしています。形式系の消滅は見せかけかもしれない、と。生成モデルを使いこなすには依然として実際の技能が要り、プロンプトエンジニアリングはプログラミングを消したのではなく、抽象度を一段上げただけかもしれない。
この指摘は、上の指示文に正面から当たります。
もし capability mediation が、十分に良い指示文を書けて、目的を正確に記述でき、返ってきたものを評価できる人にしか効かないなら、私は障壁を取り除いたのではなく、名前を変えただけです。上のブロックは、まさに読者が疑うべき種類の成果物です。正しく入手して正しく運用しないと恩恵が得られないテキストなのだから。
しかもあれは抜粋です。私が実際に運用しているものは、一年半のあいだ失敗のたびに書き足してきた、もっと大きなファイル群です。読者が受け取るのはそこから切り出した一部で、元の文脈を持たずに動くかどうかは、私には保証できません。
きれいな答えは持っていません。言えるのは、検証が安く経験的だということだけです。プロンプトを考えたことのない人に渡して、その人の次の実際の問題が、渡さなかった場合より先に進むかどうかを見る。流暢にさせるより低いハードルで、感心させるより高いハードルです。
仲介が制御に変わる線
もう一つ、同じ研究者からの警告があります。
Sarkar の2024年の論文 Intention Is All You Need は、生成AIが人間の意図の中立的な伝送路ではないと論じています。仲介者は、人の未完成の目的を馴染みのあるパターンへ引き寄せうる。彼はこれを mechanised convergence と呼んでいます。
AIが能力の地図を持つなら、その地図が土地を作り始めます。
先生が「生徒にもっと関心を持ってほしい」と言うと、仲介者は繰り返しアプリを提案する。研究者が変わった問いを持ってくると、仲介者は馴染みのある学術的な形に流し込む。その時点で、システムは可能性を開示するのをやめて、狭め始めています。
だから設計原則は「AIが利用者の望むべきものを決める」ではありえません。
地図はAIが持つ。目的地はAIが持たない。
二列で並べる
要件を、現状の実装者と、あるべき実装者で並べます。
| 設計要件 | 現状：利用者が実装 | あるべき：製品が実装 |
|---|---|---|
| 未完成の入力を受ける | 「未完成のまま話してよい」と指示文に書く | 空欄が最初から「何に困っていますか」で始まる |
| 確認質問を絞る | 「長い選択肢を並べるな」と書く | 結果が変わる質問だけを最大3回 |
| 解釈の可視化 | 「理解を先に返せ」と書く | 実行前に解釈カードが出て、その場で編集できる |
| 能力の提示 | 「私が知らない機能を一つ出せ」と書く | 目的から到達可能な機能を文脈に応じて提示 |
| 受け渡しの準備 | 「貼れる指示文を作れ」と書く | 専門システムへの受け渡しを内部で完結 |
| レシート | 「何が未検証か言え」と書く | 返り値の構造として標準装備 |
| 責任の分界 | 「最終判断は私に残せ」と書く | 不可逆な操作の前に必ず承認を挟む |
| 支援の減衰 | 実装できていない | 習熟に応じて支援を減らす設計 |
左列は全部、私が Markdown のテキストで実装しました。特別な技術は使っていません。
個人が Markdown で実装できたものは、製品で実装できます。
最後の一行「支援の減衰」だけは、指示文では実装できませんでした。利用者側からは、自分がどれだけ習熟したかを測れないからです。これは製品側にしか実装できない要件です。
まとめ
AI導入が止まる場所は、プロンプトの品質ではありません。その手前で二回落ちています。
- 失敗A：能力が行動空間に入っていない。エラーは出ない。
- 失敗B：目的を実行可能な形にできない。空のプロンプト欄の前で止まる。
証拠が示しているのは、Bの一部は実装で解けるということです（35.4% → 68.8%）。ただし翻訳には25%と6.2%の欠陥があり、初心者はそれを検出できない。だから解釈の可視化と編集可能性が要件になります。
そしてAが解けても、要件の言語化は人間側に残ります（ROPE：技法1%、要件20%）。目的、優先順位、許容できない結果、証拠の基準、採用の判断、結果への責任。ここは実装しない方が正しい。
現状、これらの要件は利用者が指示文で自力実装しています。動きます。しかし、利用者が自分でカスタム指示を書いて貼れることが前提の設計は、入口の問題を解いたことになりません。
入口をAI側へ移してよい。ただし、移すなら目的と検証と結果責任は人間へ返す設計にする。
その仕様は、まだ実装されていません。
出典
高齢者と問題の言語化
Sharifi, H., Shomee, H. H., Lamar, M., Medya, S., & Chattopadhyay, D. "Helping the Helper: LLM-Assisted Problem Articulation for Older Adults Seeking Technology Support." ASSETS 2026.
https://arxiv.org/abs/2601.10018
要件志向のプロンプト教育（ROPE）
Ma, Q., Peng, W., Yang, C., Shen, H., Koedinger, K., & Wu, T. "What Should We Engineer in Prompts? Training Humans in Requirement-Driven LLM Use." ACM Transactions on Computer-Human Interaction, 2025.
https://arxiv.org/abs/2409.08775
非専門家のプロンプト設計
Zamfirescu-Pereira, J. D., Wong, R. Y., Hartmann, B., & Yang, Q. "Why Johnny Can't Prompt: How Non-AI Experts Try (and Fail) to Design LLM Prompts." CHI 2023.
https://doi.org/10.1145/3544548.3581388
awareness of the possible
Sarkar, A. "Will Code Remain a Relevant User Interface for End-User Programming with Generative AI Models?" Onward! 2023.
https://arxiv.org/abs/2311.00382
意図と仲介のリスク
Sarkar, A. "Intention Is All You Need." PPIG 2024.
https://arxiv.org/abs/2410.18851
業務に埋め込まれたAI
Brynjolfsson, E., Li, D., & Raymond, L. "Generative AI at Work." Quarterly Journal of Economics, 140(2), 889–942, 2025.
https://doi.org/10.1093/qje/qjae044
支援を外すと消える学習効果
Bastani, H., Bastani, O., Sungu, A., Ge, H., Kabakcı, Ö., & Mariman, R. "Generative AI Without Guardrails Can Harm Learning: Evidence from High School Mathematics." PNAS, 122(26), 2025.
https://doi.org/10.1073/pnas.2422633122
AI利用の開示
この記事の作成にはAIを広範に使用しました。GPT と Claude を、隣接研究の調査、中心的な主張への反論、反対意見の洗い出し、構造の設計、日本語の推敲に使っています。公開研究に帰属させた主張は、別工程で一次資料に当て直しました。
学校での実演と、記事の元になった観察は、私自身の経験です。議論、証拠の境界、文言、公開の判断は私が行っています。
英語版はこちらです。Age of Awareness（Medium）に掲載されています。
https://medium.com/age-of-awareness