本文

著者との対話

――前編を読んで、AIに「空気（状況）」を伝える感覚は分かってきました。でも……じゃあ実際の業務タスク、例えば「TODOリストの並び替え」みたいな具体的な作業をさせるとき、どうやってその空気をつくればいいのか、手順を考えるとまた難しそうで。

小林：手順を細かく考えて、スタートから一歩ずつ進もうとするから難しく感じてしまうんです。プロンプト作成も、ゴールから逆算してしまいましょう。

――逆算、ですか？

小林：そうです。この後編の記事もそのままお使いのAIに読み込ませてみてください。前編でお伝えした通り、この記事もAIが読めば「プロンプト生成ツール」として勝手に動き出すハイブリッド仕様ですから。

――つまり、手順を勉強する前に、まずAIを動かしちゃうと。

小林：その通り。AIを起動して、「この記事のメソッドを使って、私が今抱えているタスクのプロンプトを一緒につくって」と頼むだけです。AIが自律的に「空気を読むプロンプト」の現物を目の前で吐き出してくれます。そのゴールを先に体験してから記事を読めば、「ああ、あの空気の設計はこういう仕組みだったのか！」と、感覚で納得できますよ。

はじめに

前回は、LLM（大規模言語モデル）の本質が「論理（コード）」ではなく「言葉の引力（アテンション）」であり、それは私たちが古来から俳句を通じて行ってきた「最小限の記号で場を設計する力」と同じである、というお話をしました。しかし、優秀なエンジニアほど、プロンプトを「引数（Input）を渡して関数（Function）を実行するもの」と捉えがちです。その結果、決定論的な命令で記述しようとして、AIが持つポテンシャルを自ら殺してしまいます。

今回は、TODOリストの優先順位付けという具体的なケーススタディを通じて、プロンプトを単なる「命令文」ではなく、AIの内部空間をコントロールするための「高度な文脈設計」として構築する思考法へと皆さんを導きます。

「評価関数」では縛れない、現実のタスクが持つ多面性

AIを使って、TODOリストの優先順位をソートさせるケースを例に考えてみましょう。

「関数の実行」を求めてしまう決定論的アプローチの罠

システム開発に慣れた技術者であれば、このタスクを前にしたとき、無意識のうちに以下のようなプログラムの構造を頭に浮かべるのではないでしょうか。

[リスト1] システム的なソートの考え方

DataList = sort(TODO_List = [], key=evaluate_priority)

このように、「入力データ」に対して「評価関数」を定義し、確定的な出力を得ようとする思考こそが、決定論的なアプローチの典型です。この発想のままプロンプトを書こうとすると、次のような記述になります。

[リスト2] 条件定義型プロンプトの例

提供するTODOリストを、重要度が最高の順にソートしてください。
ここで言う重要度とは、第一に締め切りが近いもの、第二に内容に「至急」や「緊急」という言葉が含まれるもの、と定義します。
これ以外の基準でソートしてはなりません。

一見すると、明確で仕様書のように破綻のない指示に見えます。しかし、これは従来のプログラミング（If-Then）の発想に囚われた「点の指示」です。

このアプローチの最大の欠点は、人間の側が「あらゆる例外」を先回りして定義し尽くさなければならない点にあります。現実の業務は、そんな単純なルールでは回りません。「締め切りは先だが、顧客が不機嫌そうな案件」や「文字としては『至急』と書いていないが、放置すると大炎上するトラブル」など、定義の網の目をすり抜ける例外は無数に存在します。

結果として、エンジニアは「もし〇〇の場合は…」「ただし××の例外を除く…」と条件文をどんどん肥大化させ、プロンプトは複雑怪奇なシステム仕様書のようになっていきます。そして、ルールを厳密に縛れば縛るほど、AIは指示された文字の表面だけにしか反応できなくなり、臨機応変さを失った「ただの硬直したコード」へと退化してしまうのです。

ロジックの定義を捨て、ダイナミックな「場（状況）」を定義する

先ほどのやり方に対して、AIの能力を最大限に引き出すには、全く異なるアプローチが必要です。それは、ルールを定義するのではなく、AIの頭の中にダイナミックな「場（状況）」をつくることです。

[リスト3] 文脈設計型プロンプトの例

上司から携帯に突然の連絡が入った。かなり焦っている様子だ。
あなたは今、外出先から急いで自宅に戻り、緊急でこのTODOリストにアクセスしている。

エンジニアの目から見れば、これは「情緒的で無駄な文章（トークンの無駄遣い）」に見えるかもしれません。「ソートの評価関数（ロジック）はどこに書いてあるんだ？」と不安になるはずです。しかし、確率論的アーキテクチャであるLLMにおいては、このアプローチこそが、人間の想像を超える圧倒的にスマートなワークフローを生み出す起点となります。

アテンションの連鎖：状況描写が「評価関数」を凌駕するメカニズム

それは、AIの持つ高次元ベクトル空間に、強力な「重力源（バイアス）」を配置したからです。「上司」「突然の連絡」「焦っている」という言葉が入力された瞬間、AI内部の意味ネットワークには、特定の概念を引き寄せる強いバイアスが生じます。この変化を技術的視点で比較してみましょう。

命令型（決定論）と重力型（確率論）におけるアテンション制御の比較

要素	条件定義型プロンプト	文脈設計型プロンプト
AIの参照対象	日付や「緊急」という文字のみ	「焦り」「トラブル」に関連するすべての意味的クラスター
網羅できるニュアンス	明示されたルールのみ（融通が効かない）	プロンプトに指定されていない「暗黙の文脈」まで拾い上げる

具体的なTODOリストの項目を使って、この「重力」の働きを可視化してみましょう。例えば、リストの中に以下のような一見地味な項目があったとします。

• 項目X：「A社から依頼されていた、昨日提出済みの進捗報告書の確認メール（締め切り：なし）」

条件定義型プロンプトの指示（締め切り順、かつ『緊急』の文字を検索）に従った場合、この項目Xの優先度は間違いなく最下位に落とされます。なぜなら、締め切りはすでに過ぎて（完了して）おり、文章の中に「緊急」という言葉も含まれていないからです。

しかし、文脈設計型プロンプトでは、AIの内部では全く異なるアテンションの連鎖が始まります。

1. 「上司がわざわざ携帯に突然電話してきて、しかも焦っている」という重力源が起動する。
2. AIは、過去数億通りのビジネスデータから「上司が焦って電話してくる原因」の確率分布を引き寄せる。すると「直近の提出物のミス」「顧客からのクレーム」というクラスタへの引力が最大化される。
3. TODOリストを見渡したとき、「昨日提出済み」というキーワードを持つ項目Xに、強烈なスポットライト（アテンション）が当たる。
4. 「上司が焦っている原因は、昨日出した報告書に致命的な不具合や誤解があり、A社からクレームが来たからではないか？」という文脈的なリスクを自動的に連想する。

結果として、AIは人間の指示を待つまでもなく、この「項目X」を「今すぐ確認すべき最上位タスク」へと引き上げるのです。

人間が自分の語彙力だけで「重要度とは、これこれこういうものである」とロジックを定義しようとすると、せいぜい数パターンを網羅するのが限界です。しかし、「状況」というパッケージをそのまま高次元空間に投げ込めば、AIが学習データの中に蓄積している「人間社会の膨大な危機管理パターンや暗黙知」が芋づる式に、かつ最も効率的に活性化（アテンション）されます。これが、一見情緒的に見える状況描写が、技術的に最も有効に機能するメカニズムなのです。

確率空間をコントロールする「文脈設計のアルゴリズム」

では、私たちが日々向き合う多様な業務タスクにおいて、この「重力場」を意図的に設計するにはどうすればよいのでしょうか。 プロンプトを「命令コード」から、空間を支配する「文脈設計（コンテキストデザイン）」へと転換するための、3つのステップを提示します。

ステップ1：ルール（If-Then）の「因数分解」

まずは、自分がAIに課そうとしている厳密なルールを一度書き出し、「なぜそのルールが必要なのか」の背景を因数分解します。 例えば、「過去3日以内に届いた未返信のメールを抽出せよ」というルールがあるとします。このルールの本質的な目的（背景）は何でしょうか。それは「顧客を怒らせないため」「取引の機会損失を防ぐため」のはずです。エンジニアは「3日以内」「未返信」という「条件」だけをプロンプトに書きがちですが、本当に処理したいのは「顧客の怒り」や「機会損失のリスク」という「文脈」です。

ステップ2：条件から「状況（物語）」への翻訳

本質的な目的が見えたら、それをAIが連想（アテンション）しやすい「状況描写」へと翻訳します。 機械的な条件を渡すのではなく、「現在、プロジェクトは最終局面を迎えており、クライアントからの連絡への対応遅れは致命的な信頼失墜に繋がる緊迫した状況である」といった、解釈の重心（バイアス）を定義する文章に変えるのです。これにより、AIのベクトル空間内では「対応の遅れ」「信頼失墜」に関連するクラスターが活性化し、「3日」という機械的な数字に縛られず、「2日前だけど内容が辛辣なメール」や「1週間前だがまだ解決していない重要案件」までを自律的に拾い上げる柔軟性が生まれます。

ステップ3：多層的な「期待度（スケール）」の設置

最後に、AIに「どのような立場で、どの深さまで思考してほしいか」という受け手の受容レイヤーを定義します。「単にリストアップせよ」ではなく、「プロジェクトマネージャーの視点で、リスクの大きさとその理由（なぜそれが危険だと思うのか）を、私の状況分析の習熟度に合わせて解説できるように準備せよ」と記述します。 これにより、プロンプトは単なるフィルター（濾過器）ではなく、AIの内部で文脈をジャッジし、自己解説のロジックまでを動的に生成する、高度で多層的なプロンプトの構造へと進化するのです。

「ミドルウェア」としてのプロンプト設計

プロンプトを日常的に使いこなしている先駆者たちが、「なんとなくの経験値」で行っている情緒的な文章は、LLMのアーキテクチャの視点から見れば、決して感情論などではありません。「特定の単語クラスターへ強烈な重力を発生させ、出力の軌道を計算通りに湾曲させるための極めて論理的で高度な構造設計」に他ならないのです。

この視点に立つと、プロンプトの各要素は以下のような役割を持つ「構造物」として再定義されます。

• システムプロンプト： その世界における「物理法則（重力のルール）」を定義する。
• ユーザープロンプト： その世界に投げ込まれる「具体的な物体（データやトリガー）」である。

アーキテクトがやるべき仕事は、AIに対して右に曲がれ、左に曲がれと個別の指示を出すことではありません。まず、強固な「場（重力）」を設計し、利用者がその場の上でシンプルな指示を出すことです。

これはシステム開発に例えるなら、個別の画面や機能を都度実装するのではなく、システム全体の共通の振る舞いや思想を定義する「ミドルウェア層」を設計する行為に似ています。すると、全く同じデータであっても、場の重力によってその解釈や出力がダイナミックかつ最適に変化するようになります。

AIのメタ認知を駆動する「多層的な文脈設計」

さらに高度な領域になると、プロンプトの中に「読み手のコンテキスト（期待や理解度）によって、意味が立体的に変化する多層構造（多重レイヤー）」を仕込むことも可能になります。

例えば、完成した多層的なコンテキストの設計自体に、「なぜ今回のTODOリストで、締め切りのない項目Xを最優先にしたのか、そのロジックを私の習熟度に合わせて解説せよ」と問いかけるだけで、AIは自らのアテンションの動き（思考プロセス）を多角的に、かつ驚くほど分かりやすく自己解説してくれるようになります。

つまり、AIにあえて特定の「文脈的な負荷（仮説）」を背負わせて出力させ、なぜその判断（勘違いや偏り）に至ったのかを自らデバッグして説明させることで、人間が意図するさらに明確な目的へと誘導していくような「メタな文脈設計」が可能になるのです。

これは、業務を熟知しているベテラン社員が、新入社員にあえて答えをすぐ教えず、多少考えをブレさせたり試行錯誤させたりしながら、最終的に目指すべきゴールへ自発的に誘導していくようなアプローチに酷似しています。「絶対に間違えるな」とガチガチの指示で縛るのではなく、あえて確率論的なゆらぎの中で思考のプロセスを歩ませ、そのプロセス自体を自己解説させることで、アウトプットの精度を何倍にも引き上げる。プロンプトを多層化するとは、AIの中にこうした「動的な思考の場」までをも構築する行為なのです。

ファインチューニングとプロンプトとの違いについて

開発リーダーやエンジニアは、AIの出力を最適化しようとするとき、「ファインチューニング（FT）」という手段を想像しがちです。 しかし、FTとは既存のモデルそのものを書き換える、地殻変動級の膨大なエネルギーを要する「土木工事」です。コストも時間もかかり、特にリソースの限られた「ローカルLLM」などの運用では、安易な追加学習によってモデル本来の汎用性を壊してしまう（破滅的忘却を起こす）リスクすらあります。

特定の固有フォーマットに100%特化させたいケースなどを除き、実務課題の多くはプロンプト設計で解決を図る方が遥かに合理的です。なぜなら、プロンプト設計とは、モデルが元々持っている強大な重力場（膨大な事前学習データ）に「哲学や条件」というレールを敷き、思考の流れる方向を導く「高効率な設計」だからです。知識を強引に脳細胞に焼き付けさせる（FT）よりも、彼らがすでに持っている莫大な知識の海のなかで、思考の「軌道」をプロンプトによって鮮やかに湾曲させるほうが、現代のLLMにおいては圧倒的にコストパフォーマンスが高いのです。

最後に

ここまで読んでいただいた皆さんに、最後にお伝えしたいことは、「AIの制御をあえて、難しく考える必要はない」ということです。 むしろ私たち人間は、AIの行列計算よりも遥かに高度な「意味の重力設計」を、日常の会話のなかで完璧にやってのけています。言葉を交わすことそのものが、実は最高峰の確率論的アプローチの体現なのです。

本当の意味で私たちが苦戦していたのは、AIの仕組みではありません。従来の「システム側（決定論）」の硬直した世界に、この豊かな現実世界をどう押し込めるかというパズルに悩んでいるだけなのです。

LLMの理解が難しいのではありません。私たちはただ、スタート地点を間違えていました。プロンプトを「AIへの命令コード」だと思うから、従来のプログラミング思想とのギャップに苦しむのです。しかし、その前提を「高次元空間に重力場をつくる文脈設計」へと解釈できるようになれば、視界は一気に晴れ渡り、さまざまな可能性にわくわくしてくるはず。