AIと長文の対話を重ねて設計や資料作成を進めていると、最初は調子が良かったのに、途中から初期の前提を忘れたり、まだ決まっていない仕様を勝手に決めつけて突っ走ったりする現象に直面します。
これはAIの性能が低いからではなく、自然言語のチャットというインターフェースの構造的な問題です。AIとの対話において情報がすべて連続ベクトルとして扱われていると、利用時に見落としや誤解が生じます。そこで「情報整理用スキーマ」を使うように指示すると、AIはその時々の状況に応じてスキーマを使用するようになります。これによって不明点、仮置き、分岐などが人間とAIの間で互いに追えるようになるため、誤解がほとんど生じなくなり、情報の更新も確実になります。
本記事では、タスクを「制約充足問題」として捉え、AIの脳内にある曖昧な前提をスキーマとして外出しさせて制御する、地味だけれど実務ではほぼ必須となるプロンプト技術を解説します。
1. 連続ベクトルの限界 〜「推測の混入」と「Lost in the Middle」〜
通常のチャット画面でAIに作業を依頼するとき、私たちは自然言語のテキストを投げかけます。しかし、情報がすべてフラットな「連続ベクトル」として処理される環境には、2つの大きな罠があります。
-
情報が少ないときの「推測の暴走」
たとえば「資料を作って」「管理表を設計して」とだけ伝えたとします。本来であれば、誰向けなのか、分量はどれくらいか、トーンはどうするかといった前提条件（引数）が必要です。しかしLLMは、情報が足りないときにエラーで止まるのではなく、「不足している情報を統計的な推測（思い込み）で勝手に補完して作業を開始する」という性質を持っています。 -
情報が多いときの「Lost in the Middle」
ならば最初から大量の前提条件を詰め込めばいいかというと、そう単純ではありません。長大なテキストを一度に渡したり対話が長引いたりすると、文脈の中間にある重要な条件を見落とす「Lost in the Middle（中間情報の喪失）」が発生し、情報を有効に使えなくなります。
さらに深刻なのが、対話を往復するうちに「人間が指示した真実（確定事項）」と「AIが勝手に挟み込んだ推測」が連続ベクトルの中で混ざり合ってしまうことです。一度これが起きると、人間側もAI側も「どこまでが合意した事実で、どこからがAIの勝手な仮置きなのか」の区別がつかなくなり、対話が破綻します。
2. LLMの本質は「制約充足問題（CSP）」〜まず「型」を決める〜
LLMを使っていて「とても良い動きをする」と感じるのは、複数の条件を与えてそれらをすべて同時に満たす解を出させるとき、つまり「制約充足問題（CSP: Constraint Satisfaction Problem）」を解かせているときです。
タスクを1つの「関数」と見なしたとき、そこに渡す「項目（Attribute）と値（Value）のセット」が『制約（Constraint）』になります。AIを正確に動かすには、常に以下の3つを問いかける構造が必要です。
- 制約は何か？（どんな項目と値が必要か）
- 充足しているか？（条件を満たす情報は揃っているか）
- 信頼度はどの程度か？（それは確定した事実か、それとも推測か）
しかし、ここで多くの人がやってしまう失敗が、「項目（Attribute）の『型（Type）』が決まっていないのに、いきなり制約充足問題を解かせようとすること」です。
プログラムの関数と同じで、引数の値には「型」のバリエーションがあります。
- 単一の数値や文字列（スカラー）なのか？
- 複数の候補から選ぶ選択肢（Enum）なのか？
- 複数要素のリストや、1対多の別テーブル構造なのか？
- 構造化データ（JSONなど）なのか？
引数の値がどういった「型」を持つのかによって、後続の処理や設計はまったく別物になります。型のバリエーションが残ったままAIに回答を生成させるのは、仕様が未定のままコーディングを始めるようなものです。
まずはAIに必要な項目（Attribute）と「その型（Type）」を推測させ、人間が確認して土俵を固めることで、初めてAIは制約充足問題を正しく解けるようになります。
3. 『仮置き・分岐・不明』の制御とHITL（人間介入）の基準
では、すべての項目と値が100%確定するまでAIに作業をさせてはいけないのでしょうか？ 実務では、未確定の要素を残したまま議論を進めたい場面が多々あります。
そこで重要になるのが、各項目の状態（State）を分類し、「そのまま進めてよい仮置き」と「立ち止まって人間が介入（HITL: Human-in-the-Loop）すべき分岐・不明」を切り分けることです。
-
確定（Confirmed）：
型も値も合意済みの状態。信頼度100%の「制約」として扱う。 -
そのまま進めてよい「仮置き（Provisional）」：
値の「型」が決まっており、単なる「名前だけ（プレースホルダー）」の問題である場合。後続の全体構造に影響しないため、未充足（仮置き）のラベルを貼ったまま処理を続けてよい。 -
立ち止まるべき「分岐（Branching）・不明（Unknown）」→ HITLの発動：
「型そのものが未定」である場合や、「仮置きの内容によって後続の展開が大きく分岐する」場合。ここでAIに勝手な推測をさせると手戻りが発生するため、処理を一旦ストップし、HITL（人間への確認と意思決定）を行う。
いま自分がどの状態にいるのかを振り返り、AIの暴走を抑止するための外部メモリが「情報整理用スキーマ」です。
4. 実践ケーススタディ：「変更管理とルールの有効管理」の設計
具体例として、業務システム等でよくある「変更管理の履歴と、ルールの有効管理」の仕組みをAIと一緒に考えるケースを見てみましょう。
初期状態として、人間から以下の7つの項目名だけを提示したとします。
【人間の初期オーダー】
「変更管理の履歴とルールの有効管理をしたい。『変更前、変更後、理由、対応、確認、付加情報、有効無効』という項目を考えている。それぞれの型はまだ不明なのだけど、どう処理しようか？」
もしスキーマを使わずにこれを投げると、AIはすべての項目を勝手に「単一のテキスト」や「単純なフラグ」だと推測し、ありがちなフラットな表を作ってしまいます。
一方、情報整理用スキーマを使うよう指示されたAIは、いきなり結論を出さず、まず「型の推測と状態の切り分け」をスキーマとして提示します。
Step 1：AIによる初期スキーマの提示（現在地の可視化）
| Attribute（項目） | Type（型の候補） | Value（内容・制約） | State（状態・信頼度） | 制御・次アクション |
|---|---|---|---|---|
| 変更前 / 変更後 | 案A: 単純テキスト 案B: 構造化データ(JSON等) |
変更内容の差分 | 分岐（型未定） | 【HITL】 検索性重視か構造保持かで型が変わるため要確認 |
| 理由 | 案A: 自由記述テキスト 案B: 区分値（選択肢） |
変更の背景・目的 | 分岐（型未定） | 【HITL】 後から集計・再利用するか確認 |
| 対応 | テキスト または タスクリスト | 変更に伴う処置 | 仮置き（未充足） | このレコード内の記録として一旦仮置きで進行可 |
| 確認 | 承認ステータス / 履歴 | 変更の妥当性確認 | 仮置き（未充足） | 同上（ローカルな手続きとして仮置き） |
| 付加情報 | （型不明） | 補足データ全般 | 不明（未充足） | 【HITL】 何を入れる想定か、型の定義が必要 |
| 有効無効 | 案A: フラグ 案B: 期間・状態導出 |
ルールが現在有効か | 分岐（影響大） | 【HITL】 レコード再利用の根幹に関わるため要確認 |
Step 2：スキーマを通じた人間の思考展開（HITLによる制約伝播）
このスキーマ（一覧表）を目の前に置かれることで、人間側は個別の項目に場当たり的に答えるのではなく、全体のバランス（制約の組み合わせ）を見ながら一気に型を確定させることができます。
たとえば、スキーマを見ながら人間はこう考え、AIに返答します。
-
「付加情報」の型決め：
ここはそもそも「型が不明な雑多な情報」を受け止める場所だから、何でも受けられる JSON型 にしよう。 -
「変更前・変更後」への波及：
もし変更前後に複雑な構造データが必要になったら「付加情報（JSON）」のほうに入れればいい。そう割り切れば、「変更前・変更後」自体は検索性を最優先して 単純なテキスト型 にするのがベストだ（これで2つの項目を分ける意味が明確になる）。 -
「対応・確認」の位置づけ：
この2つは「今回の変更レコード単体」で完結する話だから、凝った構造にはせず、レコード内の管理項目としてシンプルに処理しよう。 -
「理由・有効無効」のRDB最適化：
一方で、ルールの有効性や変更理由は「過去レコードの検索やルールの再利用」で確実に使いたい。だからここはJSONなどに逃がさず、RDBでクエリやインデックスが効きやすい定型にしよう。
Step 3：スキーマの更新と「制約充足」の実行
人間がこの方針を伝えると、AIはスキーマを以下のように更新します。
| Attribute（項目） | Type（確定した型） | Value（役割・設計方針） | State（状態） |
|---|---|---|---|
| 付加情報 | JSON型 | 型不明・非定型データをすべて吸収する器 | 確定（充足） |
| 変更前 / 変更後 | 単純テキスト型 | 検索性を最優先（構造データは付加情報へ分離） | 確定（充足） |
| 理由 | 区分値＋テキスト（RDB列） | レコード再利用・抽出のためRDBで扱いやすい形 | 仮置き（分岐） |
| 有効無効 | Boolean / 状態列（RDB列） | 有効ルールの高速な抽出・再利用のためRDB標準型 | 確定（充足） |
| 対応 / 確認 | 単一レコード内属性 | このレコード固有のローカルな履歴として保持、疎結合 | 仮置き（進行可） |
ここまで整理されれば、理由以外の主要な項目の「型」と「役割分担（なぜその型にするのかという制約）」がすべて充足した状態になります。「対応・確認」の詳細な型がまだ仮置きであっても、このテーブルの列の問題であり、全体のテーブル構造がブレることはありません。
この後は理由について記入と検索で活用しやすい型を決めてしまえば、AIは一発で意図通りの設計（制約充足問題の解）を出力してくれます。
5. おわりに：派手さはないが、AI活用でほぼ必須の「状態管理」
プロンプトエンジニアリングというと、一発で完璧な出力を引き出す「魔法のフレーズ」のような派手なテクニックが注目されがちです。
しかし、実際の業務や複雑な設計において本当に効くのは、今回紹介したように「AIに情報整理用スキーマを使わせ、不明点・仮置き・分岐を互いに追跡できるようにする」という、極めて地道な状態管理のアプローチです。
【普段のプロンプトに添える指示の例】
作業を開始する前に、タスクを「制約充足問題」として捉え、必要な引数（Attribute）と推測される型（Type）を洗い出してください。
現時点での「設定値（Value）」と「状態・信頼度（State：確定／仮置き／分岐／不明）」を情報整理用スキーマ（表形式）として出力し、後続の処理が分岐する項目や型が未定の項目については、勝手に推測して進めず私に確認（HITL）を求めてください。
この「型を決め、状態をスキーマに固定し、分岐点だけ人間が判断する」というサイクルを回すだけで、AIの見落としや勝手な思い込みは劇的に減り、手戻りのない確実なアップデートが可能になります。派手さはありませんが、AIを実務の頼れるパートナーにするために、ぜひ取り入れてみてください。