第4章 AIシステム基盤構造図

ここまでの内容を一つの図に統合する。

LLMはステートレスであり、毎回コンテキストウィンドウの中身だけを見て応答を生成する(第1章)。その生成プロセスは確率的であり、テキストによる指示は「影響」を与えるが「強制」はできない。確実な制御が必要な場面では、モデルの外側で動く決定論的な仕組み(Hooks)を設計する。この二つの制御を「どこに何を置くか」が、AIを使いこなすための設計判断だ(第2章)。この設計全体を包む枠組みがHarness Engineeringだ。コンテキストウィンドウの中身を最適化するContext Engineeringと、モデルの外側に決定論的な制約を置くArchitectural Constraintsの両方を含む(第3章)。

以下の構造図は、これらの概念がシステム全体の中でどう配置されているかを示したものだ。上からユーザー、Harness(確率的制御+決定論的制御)、モデル層(ユーザーが変更できない領域)の順に並んでいる。

ユーザー (Human) 意図の発生源 → 自然言語入力 → 最終判断者 テキスト入力 Harness(馬具) モデルの「外側」を包む制御・支援の仕組みの総体 Context Engineering の対象領域(確率的制御) システムプロンプト 付加 + メモリ注入 (外部DB検索) + コンテキスト ウィンドウ組み立て イベントループ(オーケストレーション層) ① モデルに入力を送信 ② モデルが出力を生成 テキスト応答 ⑥「完了」と判断(確率的) ⑦ Stop Hook(決定論的) 未達→②へ 差し戻し 達成→終了許可 ツール呼出し要求 ③ PreToolUse Hook ④ ツール実行 ⑤ PostToolUse Hook ②へ戻る 外部ガードレール層 入出力の安全性チェック 外部永続化層 ファイルに状態を書き出し 確率的制御 決定論的制御 (Hooks) モデル層(変更不可) Harnessの内側(モデルを包む) Harnessの外側(モデルそのもの) モデル層(推論エンジン) ★ Harnessではない ★ すべての出力が確率的 ★ コンテキストウィンドウ(有限) System Prompt Memory (注入) 会話履歴 今回の入力 ← 上限を超えると古い部分が切り落とされる (auto-compact) → Transformer(自己回帰生成) トークン₁ → トークン₂ → … → トークンₙ  各ステップで確率分布からサンプリング パラメータ: 訓練完了後は固定 → ステートレス(会話で変化しない) 内部ガードレール (Constitutional AI, RLHF) → Harnessではない

実用上のポイント: この構造図は「問題が起きたときの診断マップ」として使える。AIの出力がおかしいと感じたら、まずコンテキストウィンドウの中身を疑う(Context Engineeringの問題)。情報は十分なのに指示通り動かないなら、確率的制御の限界を疑う(Hooksの導入を検討)。Harnessを整えても改善しないなら、初めてモデル自体の限界を疑う。上から順に確認していくことで、最も効率的に問題の所在を特定できる。