はじめに：同じ言葉が通じても、同じ理解をするとは限らない
ファンタジーの世界では、人間とエルフ、ドワーフなどが同じ言語を話していても、寿命や文化、価値観の違いから、互いの考え方を理解できないことがあります。
同じ言葉を理解できることと、同じように世界を認識していることは、必ずしも一致しません。
これは架空の世界に限った話ではありません。
これまで私たちは、文章を読んで理解し、書かれた内容に基づいて判断する存在として、主に人間を想定してきました。
しかし、生成AIが登場した現在、その前提は大きく変わりつつあります。
人間が書いた文章を読み、そこから要求を解釈し、プログラムを実装したり、設計を検討したりするAIが存在しています。
私たちは今、同じ言語を扱える、人間とは異なる情報処理の仕組みを持った相手と、日常的にコミュニケーションを取るようになりました。
では、ここで一つ疑問が生じます。
人間が理解しやすい文章は、AIにとっても理解しやすいのでしょうか。
人間にとって読みやすく、思わず続きを読みたくなるような文章の構造は、AIに対しても同じ効果を持つのでしょうか。
あるいは、AIにはAIの情報処理に適した、まったく別の文章構造が存在するのでしょうか。
本記事では、人間にとっての「物語性」という情報の伝え方に注目し、それがAIへの指示文とどのように異なるのかを考えていきます。
最終的には、ソフトウェア開発における可読性や保守性の考え方も踏まえ、実務でどのように両者を使い分けるべきかを検討します。
なお、本記事では「良い感じにして」といった曖昧な指示の問題は解決済みとし、同じ要件を十分に伝えている場合でも、文章の構成によって出力品質が変わるのかを主題とします。
1. 人間はなぜ物語を通じて情報を理解するのか
小説や映画などを考えると、人間が物語を好むこと自体は珍しい話ではありません。
しかし、物語は単に娯楽を提供するだけの存在なのでしょうか。
例えば、ある人物が他者を裏切り、その結果として周囲からの信頼を失い、孤立してしまう物語を考えてみます。
読者は、実際に誰かを裏切ることなく、他者との信頼関係が崩れる過程を疑似体験できます。
あるいは、危険な状況で主人公が誤った判断を下し、思わぬ結果を招く物語であれば、読者は自分自身が危険を負わずに、その判断の問題点を考えることができます。
こうした性質から、物語を社会的な状況や因果関係をシミュレーションする仕組みとして捉える研究があります。
人間にとって、他者の意図を推測し、出来事の原因を理解し、将来の結果を予測することは、生存や社会生活に深く関わる能力です。
物語を理解する際にも、こうした認知機能が利用されていると考えられます。
もっとも、「物語を好むこと自体が、生存のために進化した専用の本能である」とまでは断定できません。
物語の理解には、言語能力、記憶、因果推論、社会的認知、感情など、複数の仕組みが関わっています。
重要なのは、物語性が単なる文章の装飾ではなく、人間の認知機能と深く結びついた情報の提示方法であるという点です。
読みやすいだけでなく、読む必要性を感じさせる
例えば、次のような技術文書があったとします。
在庫予約機能は、注文手続き中の商品数量を一時的に確保する機能です。予約には有効期限を設定し、期限切れの場合は在庫を解放します。
必要な情報は説明されています。
一方、次のような書き方もできます。
ECサイトで残り1点の商品を、2人のユーザーが同時に購入しようとしたら、どうなるでしょうか。
適切な制御がなければ、在庫数を超えた注文を受け付けてしまう可能性があります。
これを防ぐために、注文手続き中の商品数量を一時的に確保する在庫予約機能を設けます。
また、購入を途中でやめたユーザーが在庫を占有し続けないよう、予約には有効期限を設定します。
後者では、機能を説明する前に、その機能が必要になる状況を提示しています。
読み手は「なぜ在庫を予約する必要があるのか」という疑問を持ち、その答えとして機能の説明を受け取ります。
ここには、
状況 → 問題 → 解決手段 → 結果
という、物語にも見られる因果関係の構造があります。
この構成は、単に説明を理解しやすくするだけではありません。
読み手に「この先の情報を知る必要がある」と感じさせる働きも期待できます。
文章の読みやすさには、少なくとも次の三つの側面があると考えられます。
- 読みやすい：情報を処理する負担が少ない。
- 理解しやすい：情報の意味や関係性を把握できる。
- 読みたくなる：その情報を知ることに動機が生まれる。
これらは関連していますが、同じものではありません。
特に技術ドキュメントでは、正確な情報を提示するだけでなく、読み手がその情報の必要性を認識できることにも価値があります。
ただし、既に機能を理解しているエンジニアが特定のパラメータを調べる場合、こうした導入は不要かもしれません。
物語性もまた、目的に応じて利用するべき情報設計の一つなのです。
2. AIも同じように物語を必要としているのか
ここで、文章の受け手を人間からAIに変えてみます。
現在の大規模言語モデル（LLM）は、人間が作成した大量の文章から学習しており、物語や因果関係を扱うことができます。
しかし、人間と同じ仕組みで文章を理解しているわけではありません。
人間は、自身の経験や感情、身体感覚、社会生活で獲得した知識などと文章を結びつけて理解します。
一方、LLMは入力されたトークンと文脈を計算処理し、学習したパターンや関係性に基づいて出力を生成します。
人間にとって重要な「興味を持つ」「共感する」「続きが気になる」といった要素が、AIにも同じように作用すると考える根拠はありません。
そこで、人間向けの物語性を二つに分けて考えてみます。
A. 認知や感情への働きかけ
読み手の関心を引き、期待や疑問を生じさせ、文章を読み進める動機を形成する構造です。
人間向けの小説や記事、教育コンテンツなどでは重要になります。
しかし、AIに実装を依頼する場合、続きを読みたくなる演出そのものが出力精度に寄与するとは限りません。
B. 因果関係や判断の背景を伝える構造
問題が発生した原因、解決したい目的、過去の経緯、判断の理由などを説明する構造です。
こちらはAIにとっても有用です。
例えば、
APIの処理を高速化してください。
という要求よりも、
アクセス集中時にデータベースへの読み取りが増加し、APIの応答時間が悪化しています。データの整合性を維持しながら、読み取り負荷を削減する方法を検討してください。
という要求のほうが、適切な改善案を得やすい可能性があります。
ただし、これは物語の形式そのものがAIに有効だからとは限りません。
目的や因果関係など、判断に必要な情報が追加されているためです。
ここは区別する必要があります。
3. 同じ要件なら、人間向けの説明とAI向けの指示で差が出るのか
ここからは、情報量をできるだけ揃えた場合を考えてみます。
例えば、ECサイトの在庫予約機能をAIに実装させるケースです。
A. 自然な説明文として記述する
ECサイトでは、同じ商品に複数のユーザーが同時に注文を行うことがあります。
在庫数を超えて注文を受け付けないよう、Node.js、TypeScript、PostgreSQLを用いて在庫予約機能を実装してください。
注文手続き中は商品数量を予約し、15分以内に注文が確定しなければ予約を解放します。注文が確定した場合は予約数量を確定在庫引当に移行してください。
同時購入時の在庫超過を防止し、処理失敗時にも整合性を維持する必要があります。
実装例、排他制御の説明、テストケースを提示してください。
B. AI向けに構造化する
# 目的
ECサイトの在庫予約機能を実装する。
# 技術スタック
- Node.js
- TypeScript
- PostgreSQL
# 要件
- 注文手続き中の商品数量を予約する
- 予約の有効期限は15分
- 期限切れの予約を解放する
- 注文確定時は確定在庫引当に移行する
- 同時購入時の在庫超過を防止する
- 処理失敗時も在庫の整合性を維持する
# 出力
- 実装例
- 排他制御の説明
- テストケース
両者が伝えている主要な要件は同じです。
ここで重要なのは、自然文だから劣っている、構造化されているから優れている、と簡単には結論づけられないことです。
しかし、構造の違いによって、それぞれ異なる利点が生まれます。
自然文では、要件同士の関係や背景を一続きの文章として表現できます。
一方、構造化された文章では、目的、条件、成果物を独立した項目として確認できます。
要求が複雑になった場合、後者は条件の抜け漏れを確認したり、部分的に修正したりしやすくなります。
AIにとっても、重要な条件を識別しやすくなる可能性があります。
ただし、実際にどちらが高精度かは、モデルや課題によって変わります。
文章の構造が違えば、必ず出力精度に差が出るということではなく、差が生じる可能性のある要因が存在すると捉えるべきでしょう。
4. AI向けの構造化が有利になりやすい分野
特に、明確な条件に従った処理を要求する場合、構造化された指示が有効になると考えられます。
厳密な条件に従う処理
Web APIのバリデーション、データ変換、ログの分類などでは、個々の条件が明確であることが重要です。
例えば、ユーザー登録APIの入力条件を指定する場合です。
# 検証条件
- メールアドレスは必須
- メールアドレスの形式を検証する
- パスワードは12文字以上
- 登録済みメールアドレスは拒否する
# HTTPステータス
- 入力不正：400
- 重複：409
- 正常登録：201
これらの条件を物語的な文章にする必要性は高くありません。
むしろ、条件を一覧化したほうが、人間にとってもAIにとっても確認しやすいでしょう。
自動化された大量処理
AIの出力を他のプログラムが受け取る場合も、同様です。
ログ解析結果をJSONで出力するのであれば、自然言語による説明よりも、必要なフィールドやデータ形式を明示することが重要です。
このような用途では、JSON Schemaなどによる出力形式の制約を併用する方法も考えられます。
つまり、AIに特化した文章構造が有効になるのは、情報を理解させることより、明確な条件に従って処理させることが主目的となる場合です。
5. 物語的な文脈がAIにも有効になる分野
一方、単純な条件の列挙だけでは不足する場面もあります。
特に、設計判断や問題分析など、複数の選択肢から適切なものを判断する場合です。
アーキテクチャの検討
例えば、次の指示を考えます。
ECサイトの注文処理をマイクロサービス化してください。保守性と可用性を重視してください。
要求自体は明確ですが、そもそもマイクロサービス化が妥当なのかを検討する余地がありません。
一方、次のように背景を説明すると、判断に必要な情報が増えます。
現在のECサイトは単一のWebアプリケーションとして稼働しています。
注文処理の機能追加が増え、商品管理や会員管理に関係しない修正でも、システム全体をデプロイする必要が生じています。
ただし、開発チームは少人数であり、運用基盤を複雑化させることには慎重です。
この状況で、注文処理をマイクロサービスとして分離するべきか、モジュラーモノリスを維持するべきかを比較してください。
判断基準は、保守性、デプロイ独立性、運用負荷、障害時の影響範囲です。
この文章には、現在の状況、問題、制約、解決したい目的があります。
物語的な因果関係が存在することで、AIは単なる実装方法ではなく、設計そのものの妥当性を検討できます。
ただし、この効果を文章の物語性だけに帰属させることはできません。
判断に必要な情報量も増えているためです。
ここで重要なのは、物語的な説明に含まれる因果関係や経緯が、AIの判断材料として機能する場合があるという点です。
障害分析
障害の原因調査でも、出来事の時系列や因果関係が重要です。
例えば、
10:00 新バージョンをデプロイ
10:05 APIの応答時間が増加
10:08 DB接続数が上限に到達
10:12 一部リクエストがタイムアウト
10:20 ロールバック
10:25 応答時間が正常化
といった情報です。
この場合、時系列そのものが問題の理解に必要な情報となります。
単なるエラー一覧に変換すると、原因を考察するための情報を失う可能性があります。
人間とAIのどちらに対しても、出来事の関係性を保持することには価値があります。
6. 実務では両方を組み合わせる場面が多い
ここまでの話を踏まえると、人間向けの物語性とAI向けの構造化を、必ずしも対立するものとして扱う必要はありません。
例えば、既存システムのリファクタリングを依頼する場合です。
背景
現在のWebアプリケーションでは、認証処理と業務ロジックが密結合になっています。
そのため、認証方式を変更するたびに複数の業務処理へ修正が波及し、回帰テストの範囲も広がっています。
今回は認証処理の責任範囲を整理し、将来の認証方式の変更に対応しやすくすることを目指します。
要件
- 既存APIの外部仕様は変更しない
- 認証処理と業務ロジックの依存を減らす
- 認証方式の変更が業務ロジックに波及しない構造にする
- 不要な抽象化や設計パターンの導入は避ける
- 既存テストを維持する
- 変更の影響範囲を説明する
背景によって、なぜその変更が必要なのかを伝える。
要件によって、何を満たす必要があるのかを明示する。
これなら、人間が読んでも設計意図を理解しやすく、AIにとっても判断条件を参照しやすい文章になります。
背景は物語的に、要求は構造的に。
この使い分けは、実務における一つの有効な方針ではないでしょうか。
7. モデルに特化した最適化は、どこまで必要なのか
ここまで、文章構造とAIへの伝わりやすさを考えてきました。
では、さらに踏み込んで、AIモデルごとに最適な指示文を作るべきでしょうか。
現在のLLMは、モデルごとに性能や入力処理の特性が異なります。
そのため、同じ指示文であっても結果が変わることはあります。
長いコンテキストにおける情報の配置が、回答精度に影響するという研究もあります。
こうした違いを踏まえれば、モデル固有の最適化によって精度が向上する可能性はあります。
しかし、ここで考慮したいのがソフトウェア開発における可読性と保守性です。
プロンプトも保守する必要がある
ソースコードでは、実行速度だけを追求することが最善とは限りません。
複雑な最適化によって可読性が低下すれば、修正や検証が難しくなります。
特定の実行環境に依存した実装であれば、環境変更時の負担も大きくなります。
AIへの指示文についても、同じことが考えられます。
例えば、あるモデルで高精度な結果を得るために、特殊な記述順序や独自の表現を大量に導入したとします。
その結果、次のような問題が生じるかもしれません。
- 人間が指示の意味を理解しにくくなる
- 要件変更時に修正箇所を特定しにくくなる
- 別のモデルでは期待どおりに機能しなくなる
- モデル更新時に再調整が必要になる
- 特殊な記述の効果を検証しにくくなる
これは、モデルに対する局所的な最適化が、システム全体の保守性を損なう構図です。
そのため、実務では最初からモデル固有の記述方法を追求するよりも、人間にとって明確で、修正しやすい指示文を基本とする方針が合理的だと考えます。
もちろん、特殊な最適化が必要な場面もある
例えば、1日に大量の問い合わせを分類するシステムでは、わずかな精度向上やトークン削減でも大きな効果があります。
このような場合には、モデル固有の最適化に十分な価値があるかもしれません。
一方、日常的な開発支援や設計相談では、わずかな精度差よりも、意図が明確で修正しやすいことのほうが重要になる場合があります。
つまり、モデル固有の最適化を否定するのではなく、その効果と保守コストを比較する必要があります。
8. 人間にとって読みやすいことは、AIにとっても価値があるのか
ここで、一つ重要な違いがあります。
人間にとって読みやすい文章が、必ずしもAIにとって最適とは限りません。
しかし、人間にとって読みやすいこと自体が、AIを活用するシステム全体にとっての価値になり得ます。
例えば、あるプロンプトの指示内容に問題があった場合、人間がその原因を特定し、修正できなければなりません。
指示文が過度に複雑化していると、問題の特定や修正が難しくなります。
また、複数人でプロンプトを管理する場合、他の担当者が内容を理解できる必要があります。
これはソースコードの可読性とよく似ています。
コンピューターが解釈できるのであれば、コードがどれほど読みにくくてもよい、とは通常考えません。
それと同様に、AIが適切に処理できるのであれば、人間が理解できない指示文でもよい、とは必ずしも言えないでしょう。
ただし、プロンプトはソースコードと異なり、同じ入力から常に同じ出力が得られるとは限りません。
したがって、可読性に加えて、期待する結果を検証できることも重要です。
9. 結局、何を最適化するべきなのか
ここまでの話を整理すると、文章の最適化対象は、単に「AIが高精度な回答を出せること」だけではありません。
少なくとも、次のような観点が必要です。
| 評価軸 | 重視する内容 |
|---|---|
| 出力精度 | 要件を満たす結果が得られるか |
| 安定性 | 条件が変化しても適切に機能するか |
| 可読性 | 人間が文章の意味を理解できるか |
| 保守性 | 要件変更に対応しやすいか |
| 移植性 | 異なるモデルでも利用できるか |
| 効率性 | トークン数や実行コストは適切か |
| 検証可能性 | 出力が要求を満たしているか確認できるか |
ここで、あえて人間の物語性へ話を戻します。
人間向けの文章においては、必要な情報を正しく伝えるだけでなく、その情報を読みたくなるように構成することにも価値があります。
一方、AI向けの指示では、そのような動機づけを必要としない代わりに、目的や条件を明確に識別できる構造が求められます。
つまり、両者は同じ自然言語を利用していても、最適化したい情報処理の性質が異なっています。
これは、単なる文章術の違いではありません。
情報を受け取る主体の特性に合わせて、情報の提示方法を設計するという問題なのです。
まとめ：同じ言葉を使うからこそ、違いを意識する
ファンタジーの世界で、人間とエルフが同じ言語を話せたとしても、互いの寿命や文化、価値観の違いまで消えるわけではありません。
相手が何を大切にし、どのような経験に基づいて判断するのかを理解しなければ、言葉が通じていても誤解は生じます。
現実における人間とAIの関係も、ある意味ではこれに似ています。
私たちは同じ言語を利用してAIへ指示を出しています。
しかし、人間が文章を理解する際に利用する認知機能と、AIが入力を処理する仕組みは同じではありません。
人間に対しては、物語性を利用することで、情報の必要性を感じさせ、因果関係を理解しやすくすることができます。
AIに対しては、目的、制約、判断条件、出力形式を明確に整理することで、要求に沿った処理を期待できます。
また、設計判断や障害分析のように、背景の因果関係が重要な場面では、両方の構造を組み合わせることが有効です。
そのうえで、モデル固有の最適化をどこまで追求するべきかについては、ソースコードと同じように可読性や保守性を考慮する必要があります。
私自身は、まず人間が読んでも意図を理解できる文章を作り、AIに必要な条件を明確に構造化し、実測によって必要性が確認された場合にのみ特殊な最適化を加える、という方針が実務的だと考えています。
同じ言葉が通じることと、同じ伝え方が最適であることは違う。
そして、その違いを理解したうえで、人間とAIの双方にとって扱いやすい情報の構造を考えることが、これからの技術文書やプロンプトの設計には必要なのではないでしょうか。
参考資料
- OpenAI — Prompt engineering
- Anthropic — Prompting best practices
- Liu et al. (2024) — Lost in the Middle: How Language Models Use Long Contexts
- Mar & Oatley (2008) — The Function of Fiction is the Abstraction and Simulation of Social Experience
※本記事は、既存の研究や技術的知見をもとにした考察です。提示した指示文の比較は説明用の例であり、モデルごとの出力精度を実測した結果ではありません。