第3章 Harness と Context Engineering — AIシステムの設計論

3.1 設計論の変遷 — Prompt から Context、そして Harness へ

AIを「うまく使う」ための概念は、ここ数年で急速に進化している。その変遷を追うことで、なぜ今この設計論が必要なのかが見えてくる。

始まりは2022年だった。GPT-3が広く使われ始め、「プロンプトの書き方次第で出力が劇的に変わる」ことが認知された。Chain-of-thought（思考の連鎖）、Few-shot learning（少数例示学習）など、プロンプトの書き方の技術が次々に開発され、「プロンプトエンジニア」という職種が登場した。2023年には年収6桁ドル（数千万円）の求人が話題になるほどの注目を集めた。この時期の前提は明快で、「プロンプトの文言を工夫すれば、AIの出力は最適化できる」というものだった。

ところが2024年に入ると、この前提が揺らぎ始めた。コンテキストウィンドウが4K〜16Kトークンから128K〜200Kトークンに拡大し、さらにGeminiでは100万トークン超に達したが、単に大量の情報を投入しても出力品質は向上しなかった。研究者はこの現象を「context rot（コンテキストの腐敗）」と呼んだ——情報を増やすほどモデルの注意が分散し、重要な情報が埋もれる。プロンプトをどれだけ工夫しても、コンテキストウィンドウの中身が雑然としていれば意味がない。問題は「何を書くか」ではなく「何をコンテキストに載せるか」だと気づく人が増え始めた。

この認識を決定的にしたのが、2025年中盤の出来事だった。Shopify CEOのTobi LütkeとAndrej Karpathy（OpenAI共同創業者、Tesla元AIディレクター）がX上でContext Engineeringの概念を公に支持し、用語が一気に普及した。Karpathyは「Context Engineeringとは、コンテキストウィンドウを次のステップに最適な情報で満たす、繊細な技術と科学だ」と定義した。Gartnerは2025年7月に「Context Engineeringは入り、Prompt Engineeringは出た」と明言。プロンプトの文言だけでなく、メモリ管理、RAG（検索拡張生成）、ツール定義、会話履歴の管理まで含めたコンテキスト全体の設計が、AIシステム構築の中心的な技術として確立された。

しかし、コンテキストの設計だけでも十分ではないことが、すぐに明らかになった。AIエージェントが本格的に使われ始めると、コンテキストウィンドウの中身をいくら最適化しても、モデルが手順をスキップしたり、指示を独自解釈したりする問題は消えなかった——第2章で述べた確率的制御の限界だ。コンテキストの「中身」の設計だけでは足りず、モデルの「外側」の制約やフィードバックループも設計する必要がある。

2026年2月、HashiCorp共同創業者のMitchell Hashimotoがブログ記事で「Harness Engineering」という用語を提唱し、この認識に名前が与えられた。数日後にOpenAIが「Harness engineering: leveraging Codex in an agent-first world」を公開し、AIエージェントのみで100万行のコードを生成した実験結果を報告。Martin Fowler（Thoughtworks）がこれを分析し、Harnessを3領域に整理した。「Context Engineering」「Architectural Constraints（決定論的制約）」「Garbage Collection（品質維持）」の三つだ。こうして、コンテキストの設計からモデルの外側のループ全体の設計へと、視野がもう一段広がった。

2022-2023  Prompt Engineering   「何を書くか」
              ↓
2024-2025  Context Engineering  「何をコンテキストに載せるか」
              ↓
2026-      Harness Engineering  「モデルの外側をどう設計するか」

この変遷が示しているのは、問題が解決されたのではなく、問題の所在が見えるようになってきたということだ。プロンプトの工夫で出力が改善したが限界に当たり、コンテキスト全体の設計で精度が上がったがそれでも確率的な揺らぎは消えず、モデルの外側に決定論的な制約を設計する必要に至った。各段階は前の段階を否定するのではなく、包含しつつ視野を広げている。本章では、この最新の設計論を整理する。

3.2 3つの概念の包含関係

3つの概念は対立するものではなく、入れ子構造になっている。

Prompt Engineeringは「指示文をどう書くか」。Context Engineeringは「コンテキストウィンドウ全体をどう組み立てるか」。Harness Engineeringは「モデルの外側のループ全体をどう設計するか」。それぞれ前者を包含しつつ、視野を広げている。

第2章で述べた確率的制御と決定論的制御の対比は、この図の中に明確に位置づけられる。Context Engineeringは確率的制御の質を最大化する領域であり、Architectural Constraintsは決定論的制御を提供する領域だ。両方を含むHarness Engineering全体が、本稿の設計論の射程である。

3.3 Harness（ハーネス）とは何か

Harnessは元々「馬具」を意味する。馬の力を人間が制御し、有用な方向に導くための装備一式——手綱、くつわ、鞍、ベルトなどの総体だ。

AI文脈では、LLMという強力だが確率的で予測困難な「馬」を、Hooks、ツール管理、コンテキスト制御、権限管理といった「馬具一式」で制御し、有用な仕事をさせる仕組みのことだ。

この比喩にはいくつかの重要な含意がある。

第一に、馬具は馬の力を殺すものではない。良い馬具は馬の能力を最大限に引き出しつつ、暴走を防ぐ。締めすぎれば馬は動けないし、緩すぎれば制御できない。これは第2章で述べた「自由度の配置」そのものだ。AIに対してすべてをガチガチに制約すれば安全だが、AIの柔軟な判断力——曖昧な指示を解釈する能力、創造的な解決策を提案する能力——が失われる。逆に何も制約しなければ、AIは自由に動くが、手順をスキップしたり意図と異なる方向に進むリスクが高まる。

第二に、馬具は一つの道具ではなく、複数の道具の組み合わせだ。手綱は方向を制御し、くつわは速度を制御し、鞍は騎手の安定を確保する。それぞれが異なる役割を持ち、組み合わさって全体として機能する。AIのHarnessも同様で、CLAUDE.mdがプロジェクトの前提を伝え、Rulesが行動規則を定義し、Skillsが手順を標準化し、Hooksが必須条件を検証する。どれか一つで十分なのではなく、複数の仕組みが組み合わさることで初めてモデルを実用的に制御できる。

第三に、馬具は馬を知る人間が設計する。馬の体格、気性、用途に合わせて馬具を選び、調整する。同じ馬でも、荷物を運ぶのか、競走するのかで馬具は変わる。AIのHarnessも、モデルの特性（何が得意で何が苦手か）とタスクの性質（創造的作業か、手順遵守が必要か）に合わせて設計する必要がある。汎用的な「正解のHarness」はなく、プロジェクトごとに設計するものだ。

最後に、同じ馬でも馬具次第で大きく結果が変わる。2026年2月のOpenAIの実験では、同じモデルでもHarnessの設計を改善するたびに生産性が大きく向上した。初期はHarnessが未整備で生産性が低かったが、環境設計、ツール統合、フィードバックループを段階的に改善することで、最終的にAIエージェントだけで100万行のコードを生成する成果に至った。モデルのパラメータは変わっていない——変わったのはHarnessだけだ。「AIの性能が悪い」と感じたとき、問題がモデルではなくHarnessにある可能性は常に検討すべきだ。

3.4 Context Engineering が解決する問題

Context Engineeringが対象とするのは、コンテキストウィンドウの中身をどう組み立てるかだ。これは確率的制御の世界の話である。コンテキストの質を上げれば、モデルの判断精度は上がるが、保証はされない。では、コンテキストウィンドウの中には何が入っているのか。

プロンプト（Prompt）

プロンプトは、ユーザーがAIに送る指示文だ。Context Engineeringの中で最も原始的で、最も直接的な構成要素である。3.1節で述べたように、2022〜2023年のPrompt Engineering時代には、ここが唯一の設計対象だった。

プロンプトの役割は「モデルに何をしてほしいかを言語で伝えること」だ。「このデータを分析して」「レポートを書いて」「コードのバグを見つけて」——これらはすべてプロンプトだ。プロンプトの質は依然として重要であり、Context Engineeringがプロンプトを否定するわけではない。ただし、プロンプト単体で解決できる範囲には限界がある。

たとえば、「先月の売上データを分析してレポートを書いて」というプロンプトは、それ自体としては明確だ。しかし、モデルは売上データを持っていない。データがコンテキストに含まれていなければ、モデルは汎用的な「売上分析レポートの書き方」を返すだけだ。プロンプトの質ではなく、コンテキストに何が載っているかが問題になる。

システムプロンプト

システムプロンプトは、ユーザーのプロンプトとは別に、コンテキストウィンドウの最上部に配置される指示文だ。AI提供者が設定する基本的な振る舞いの定義（安全性のガイドライン、応答スタイルなど）と、ユーザーやアプリケーション開発者が設定するカスタム指示が含まれる。第2章で述べた通り、コンテキスト内で最も強い確率的影響力を持つ。

チャットUIで直接見えることは少ないが、Claude.aiの「プロジェクト」機能やClaude Codeの「CLAUDE.md」は、実質的にシステムプロンプトの一部としてコンテキストに注入される仕組みだ。

メモリ管理

第1章で述べた通り、LLMはステートレスであり、会話をまたいだ記憶を持たない。メモリ管理はこの制約を補うための仕組みだ。

短期記憶は、現在の会話履歴そのものだ。会話のターンが重なるたびに履歴がコンテキストに蓄積される。3.5節で述べる「対話の蓄積」はこの仕組みの上に成り立っている。

長期記憶は、過去の会話から抽出された情報を外部データベースに保存し、新しい会話の開始時に関連情報を検索・注入する仕組みだ。ユーザーから見ると「以前の会話を覚えている」ように見えるが、実際にはシステムが裏側で検索と注入を行っている。

メモリ管理の設計上の課題は、何を覚え、何を忘れるかの選別だ。すべての過去の会話をコンテキストに入れるとウィンドウが溢れる。かといって重要な前提を注入し忘れると、「昨日話したことを覚えていない」という問題が起きる。この選別の質がAIの応答品質を大きく左右する。

RAG（検索拡張生成）

RAG（Retrieval-Augmented Generation）は、モデルの訓練データに含まれていない知識を、外部ソースから検索してコンテキストに注入する仕組みだ。

LLMの知識には訓練データのカットオフがある。たとえば2025年5月までのデータで訓練されたモデルは、それ以降の出来事を知らない。また、組織内の非公開ドキュメントや、特定分野の専門データはそもそも訓練データに含まれていない。RAGはこれらの情報をリアルタイムに検索し、コンテキストに追加することで、モデルが最新の、あるいは特定領域の知識に基づいた応答を生成できるようにする。

RAGの設計上の課題は、検索の精度と注入する情報の量のバランスだ。関連性の低い情報を大量に注入すると、3.1節で触れた「context rot」が起きる。逆に情報が不足すれば、モデルは訓練データに基づく不正確な回答を返す。「何を検索し、どのくらいの量をコンテキストに載せるか」の設計がRAGの質を決める。

ツール定義

モデルが外部ツール（ファイル操作、Web検索、データベースクエリなど）を使えるようにするための定義だ。各ツールの名前、説明、パラメータ、使い方がテキストとしてコンテキストに注入される。モデルはこの定義を読んで、「どのツールを、いつ、どう使うか」を確率的に判断する。

ツール定義の記述が曖昧だと、モデルは適切なツールを選べなかったり、パラメータを間違えたりする。逆に、定義が詳細すぎると、コンテキストウィンドウの容量を圧迫する。3.3節で述べた「馬具は馬を知る人間が設計する」の原則がここにも当てはまる。

出力フォーマット

モデルの応答をどの形式で返すかの指定だ。「JSON形式で返せ」「Markdown表で整理しろ」「3段落以内でまとめろ」のような指示が、コンテキストの一部として機能する。

出力フォーマットの指定は、プロンプトの一部として書くこともあるし、システムプロンプトに含めることもある。形式が明確に定義されているほど、モデルの出力は安定する。これは確率的制御の中では比較的遵守率が高い部類に入る——形式的な制約はモデルにとって解釈の余地が少ないからだ。

Context Engineeringが解決するのは「何を知っているか」の問題

ここまでの構成要素を整理すると、Context Engineeringの本質は「モデルが適切な判断をするために必要な情報を、適切な量と構成でコンテキストウィンドウに載せること」だ。

AIの応答品質が悪いとき、多くの場合はモデルの能力不足ではなく、コンテキストの問題である。必要な情報が欠けている、不要な情報でノイズが多い、情報の順序が不適切——これらを最適化するのがContext Engineeringだ。プロンプトの文言を改善するだけでは解決しない問題の多くは、コンテキスト全体の設計を見直すことで改善される。

3.5 対話はContext Engineeringの実践である

3.4節ではContext Engineeringの構成要素を整理した。システムプロンプト、メモリ、RAG、ツール定義——これらは主にシステム開発者やツール提供者が設計する領域だ。では、エンドユーザーはContext Engineeringとは無縁なのか。そんなことはない。

はじめにで述べた「思考をぶつける」というアプローチは、Context Engineeringの最も原始的で、最も誰にでも実践可能な形だ。自分の頭の中にある文脈を、モデルのコンテキストウィンドウに転写する行為に他ならない。

3.4節で述べたContext Engineeringの構成要素を、対話の視点から見直してみよう。ユーザーがAIに思考をぶつけるとき、実際に起きていることは以下の通りだ：

• ユーザーの発言がコンテキストウィンドウに追加される（プロンプトに相当）
• 前のターンでの議論がすべて履歴として残る（短期記憶に相当）
• ユーザーが「前回の会話で述べたが...」と明示的に情報を持ち込む（長期記憶の手動注入に相当）
• ユーザーがファイルやデータを貼り付ける（RAG的な外部知識の注入に相当）

つまり、対話を通じてユーザーは——意識しているかどうかに関わらず——コンテキストウィンドウの中身を設計している。「何を話すか」「どの順番で話すか」「何を省略するか」のすべてがContext Engineeringの判断だ。

ここで重要なのは、対話の質 = コンテキストの質 = 出力の質という連鎖だ。AIの出力品質はコンテキストウィンドウの中身で決まり、対話はそのコンテキストの主要な供給源である。つまり、対話の質を上げることは、直接的にコンテキストの質を上げることであり、直接的に出力の質を上げることだ。

では、質の高い対話——つまり質の高いコンテキストの供給——には何が必要か。効果的なインプットには以下の4つの要素が含まれている。

目的（Why）: なぜこれをやりたいのか。「レシピデータを構造化したい」ではなく「レシピ間の関係性をネットワークとして可視化し、食材の組み合わせパターンを発見したい」の方が、AIは適切な構造を提案できる。

文脈（Context）: 現在の状況、制約条件、これまでに試したこと。「うまくいかない」ではなく「Phase 2まで完了したが、ノード数が500を超えた時点で可視化が破綻した」の方が、AIは的確な対処を返せる。

自分の仮説（Hypothesis）: 自分はどう考えているか。「どうすればいい？」ではなく「チャンクに分割して処理するアプローチが良いと思うが、重複ノードの処理が問題になりそうだ」の方が、AIはその仮説の妥当性を検証し、見落としを指摘できる。

判断基準（Criteria）: 何をもって成功とするか。「良い感じにして」ではなく「正確性が最優先、速度は二の次でよい。研究用なので再現可能性が重要」の方が、AIはトレードオフの判断を適切にできる。

これら4要素が対話の中でどう機能するか、異なる分野の例で見てみよう。

例1: 文章執筆

弱いインプット:
  「ブログ記事を書いて。テーマはAI。」

強いインプット:
  「AI駆動の研究開発について、技術者でない人向けの記事を書きたい。
   自分の経験として、LLMのステートレス性を理解したことで
   ワークフロー（作業の流れ）の設計が根本的に変わった。この『構造を知ることで
   使い方が変わる』という体験を、読者にも追体験させたい。
   想定読者はAIを日常的に使っているが仕組みは知らない層。
   専門用語は初出時に必ず説明する方針で。」

後者には目的（追体験させたい）、文脈（自分の経験）、判断基準（読者層、専門用語の扱い）が含まれている。AIはこの情報から、記事の構成、語り口、具体例の選び方まで適切に判断できる。

例2: データ分析

弱いインプット:
  「売上データを分析して。」

強いインプット:
  「先月の売上が前年比15%減だった。営業チームは『季節要因』と
   言っているが、自分は新規顧客の獲得率が落ちているのが
   本質的な原因だと思っている。data/sales_2025.csv に月次データが
   ある。新規 vs 既存顧客の売上比率の推移を出して、
   自分の仮説が正しいかどうか検証してほしい。」

後者には仮説（新規顧客獲得率の低下）と反論（季節要因という別の説明）が含まれている。AIは仮説を検証する方向で分析を組み立てつつ、季節要因も併せて検討できる。

例3: 問題解決

弱いインプット:
  「PythonでエラーになるのでFixして。」

強いインプット:
  「FastAPIのエンドポイントで、リクエストボディが大きい時だけ
   タイムアウトする。小さいリクエストは正常。ログを見ると
   バリデーション段階で止まっている。Pydanticモデルに
   ネストした配列があるので、そこで計算量が爆発している
   のではないかと疑っている。モデル定義は models/order.py にある。」

後者には文脈（いつ起きるか）、仮説（Pydanticのネスト配列）、判断を助ける情報（ファイルの場所）がある。AIは闇雲にコードを修正するのではなく、仮説を検証するポイントに集中できる。

共通するパターン: 3つの例すべてで、強いインプットには「自分はこう考えている」が含まれている。AIに答えを丸投げするのではなく、自分の思考を起点にしている。これが「答えを引き出す」と「思考をぶつける」の実質的な違いだ。

しかし、ここまでの例は「1回のインプットの質」の静的な比較だ。実際にはもっと重要なことがある——対話を重ねることで、コンテキストウィンドウに文脈が蓄積され、出力の質が動的に変わっていくということだ。

例4: 対話の蓄積が出力を変える

同じ「レポートを書いて」という指示でも、それまでの対話の量で結果がまったく違う。

【ターン1 — コンテキストが空に近い状態】

  人間: 「先月の売上データを分析してレポートを書いて。」
  AI:   「売上データの分析レポート
         1. 概要：先月の売上は...
         2. 傾向：前月比で...
         3. 推奨事項：...」

  → 汎用的で表面的。どの会社にも当てはまるような内容。
     AIはデータの背景も、分析の目的も、読み手も知らない。

【ターン1〜4 — 対話を通じてコンテキストが蓄積される】

  人間: 「先月の売上が前年比15%減だった。」
  AI:   「15%減は大きい。業界全体の傾向か、御社固有の問題か？」
  人間: 「業界は横ばい。うちだけ落ちている。営業チームは
         季節要因と言っているが、自分は新規顧客の獲得率が
         落ちているのが本質だと思う。」
  AI:   「新規 vs 既存の切り分けは重要。データはあるか？」
  人間: 「ある。もう一つ気になるのは、4月に値上げしたこと。
         新規が減ったのは値上げのせいかもしれない。」
  AI:   「値上げと新規獲得率の相関は検証できそうだ。
         既存顧客の継続率はどうか？」
  人間: 「既存は維持できている。だから値上げ自体は
         既存客には受け入れられたが、新規の入り口で
         ハードルになっている可能性がある。」

【ターン5 — コンテキストが豊かな状態で同じ指示】

  人間: 「これを踏まえてレポートを書いて。」
  AI:   「売上減少の構造分析レポート

         エグゼクティブサマリー：
         先月の売上前年比15%減は季節要因ではなく、
         新規顧客獲得率の低下が主因と考えられる。
         4月の価格改定以降、既存顧客の継続率は維持
         されている一方、新規獲得数が減少している。

         検証すべき仮説：
         1. 価格改定が新規顧客の参入障壁になっている
         2. 既存顧客への値上げ受容と新規への価格感度の乖離
         ...

         推奨データ分析：
         - 価格改定前後の新規問い合わせ数の推移
         - 競合との価格比較
         - 新規顧客の離脱ポイント（どの段階で離脱しているか）」

  → 具体的で、この会社のこの状況にしか当てはまらない内容。
     仮説の構造、検証の方向性、必要なデータまで特定されている。

ターン1とターン5で、指示の文言（「レポートを書いて」）は変わっていない。変わったのはコンテキストウィンドウの中身だ。ターン1〜4の対話がすべて履歴としてコンテキストに残っているので、AIはそれを踏まえた出力を生成できる。

これが「対話を続けることの価値」の正体だ。対話は雑談ではなく、コンテキストウィンドウを自分の思考で満たしていく作業だ。自分の仮説、判断根拠、試行錯誤の履歴——これらが蓄積されるほど、AIの出力は自分の状況に特化したものになる。1回の完璧なプロンプトを書こうとするよりも、対話を通じてコンテキストを育てる方が、結果的に良い出力に到達しやすい。

これらの要素を対話の中でコンテキストウィンドウに蓄積することで、AIの出力精度は向上していく。ただしウィンドウには上限があるので、非常に長い対話では初期の文脈が失われる（第1章で述べたauto-compact）。失われてからでは遅いので、対話の中で重要な結論や判断が出たら、その時点でファイルに書き出しておく——外部永続化層の活用だ。auto-compactは予告なく起きるため、「後でまとめて書き出そう」は危険である。外部ファイルへの書き出しを仕組みとして設計する方法については、第6章のHarnessの各機能（Rulesで意図を伝え、Skillsで手順を標準化し、Hooksで確実に守らせる）で具体的に述べる。

実用上のポイント: 「AIが何をしてくれるか」ではなく「AIに何をぶつけるか」を考える。出力の質は入力の質で決まる。十分なインプットなしに良い出力を期待するのは、空のコンテキストウィンドウに高品質な応答を求めるようなものだ。

3.6 Harnessの境界 — 何が「馬具」で何が「馬」か

3.3節でHarnessを「馬具」に喩えた。ここでは、その比喩をもう一歩進めて、何がHarnessで何がモデルなのか、その境界はどこにあるのかを明確にする。この区別は、「自分が改善できる範囲」と「自分には変えられない範囲」を理解するために不可欠だ。

Harness側（ユーザーが設計できる領域）

左側に並んでいるのは、すべてユーザーが自分の手で設計・配置・調整できるものだ。

「オーケストレーション層」は、モデルの呼び出しとその結果の処理を制御するループ全体を指す。モデルに何を入力し、出力をどう処理し、次に何を入力するか——この流れの設計だ。「Context Engineering」は3.4節で述べた通り、コンテキストウィンドウの中身の設計だ。「Hooks / ツール実行」は第2章で述べた決定論的制御にあたる。「外部ガードレール」は、モデルの入出力に対する安全性チェックをモデルの外側で行う仕組みだ。「外部永続化」は、ステートレスなモデルの限界を補うためにファイルやデータベースに状態を書き出す仕組みである。

これらに共通するのは、モデルの外側で動くということだ。モデルのパラメータに一切触れることなく、モデルを取り巻く環境を設計することで、AIの振る舞いを制御する。

モデル側（ユーザーが変更できない領域）

右側に並んでいるのは、ユーザーからは変更できないものだ。

「Transformer本体」は、LLMの推論エンジンそのものだ。入力されたトークン列から次のトークンの確率分布を計算する、モデルの核心部分である。「パラメータ（固定）」は、第1章で述べた通り、訓練完了後に固定されてユーザーとの対話では変化しない数千億個の数値だ。「自己回帰生成」は、トークンを一つずつ順番に確率的に生成する仕組みで、第2章で述べた確率的な性質の根源だ。「内部ガードレール」は、Constitutional AIやRLHFといった訓練手法によってモデル自体に組み込まれた安全性の振る舞いであり、Harnessとは異なりモデルの一部として確率的に作用する。

これらはAI提供者（Anthropic、OpenAI、Google等）が設計・訓練する領域であり、ユーザーが直接操作することはできない。

この区別が実用上なぜ重要か

ユーザーの立場からすると、Harnessが自分の影響を及ぼせる範囲であり、モデルはAI提供者の領域である。自分が設計・最適化できるのはHarnessの部分であり、モデルそのものを変えることはできない。

この区別を知らないと、問題が起きたときに対処を間違える。具体例を二つ見てみよう。

例1: コンテキスト汚染 — 最も身近な問題

長い会話を続けていると、AIの応答の質が徐々に落ちてくることがある。最初のうちは的確だった回答が、途中から見当違いになったり、前に言ったことと矛盾したりする。「AIの性能が不安定だ」と感じるかもしれないが、多くの場合これはモデルの問題ではなく、コンテキストウィンドウの中身が雑然としてきたことが原因だ。

第1章で述べた通り、会話が長くなるとコンテキストウィンドウには過去のやり取りが蓄積される。試行錯誤の過程で出た間違った方向性、撤回した仮説、不要になった中間成果——これらがすべてコンテキストに残り、モデルの注意を分散させる。3.1節で触れた「context rot（コンテキストの腐敗）」が、一つの会話の中でも起きるのだ。

この問題に対する最もシンプルな対処は、会話を新しいチャットに移すことだ。現在の会話で得られた結論や重要な前提だけをまとめ、新しいセッションでそれをインプットとして渡す。ステートレスなモデルにとって、「前の会話の続き」も「新しい会話に必要な情報を渡された初回」も、原理的に同じだ。違うのは、コンテキストウィンドウの中身が整理されているかどうかだけである。

これはHarness設計そのものだ。コンテキストウィンドウの中身を最適化する——すなわちContext Engineeringの実践であり、特別なツールや技術を使わずとも、今すぐ実行できる。重要な結論をファイルに書き出しておけば、新しいセッションへの引き継ぎはさらに確実になる（外部永続化）。

例2: ハルシネーション — Harness側にまだ手がある

「AIが事実と異なることを言う（ハルシネーション）」という問題に対して、「プロンプトで『嘘をつくな』と書く」のはHarness側の対策（確率的制御）だ。それで改善しない場合に「このAIはダメだ」と結論づけるのは、モデル側に問題を帰属させている。しかし、実際には「RAGで正確な情報をコンテキストに注入する」「出力をファクトチェックするスクリプトをHookで実行する」など、Harness側でできることがまだ残っている場合が多い。

問題の所在を診断する

二つの例に共通するのは、問題の原因がどこにあるかを正しく診断することの重要性だ。例1のコンテキスト汚染は、純粋にHarness側（コンテキスト管理）の問題であり、モデルには何の責任もない。例2のハルシネーションは、モデルの確率的生成に起因する部分もあるが、Harness側で大幅に軽減できる。どちらの場合も、「AIがおかしい」で思考を止めると、自分で対処できる範囲を見逃すことになる。

逆に、モデル側に起因する問題——たとえばモデルが特定の言語や専門分野に弱い——は、Harnessをどう設計しても根本的には解決しない。その場合はモデル自体を変える（別のモデルを使う）判断が必要になる。

実用上のポイント: 「AIの性能が悪い」と感じたとき、まずHarness側でできることが残っていないかを検討する。最も手軽なのは会話を新しいチャットに切り替えてコンテキストを整理することだ。それでも改善しなければ、RAGやHooksなどより高度なHarness設計を検討する。同じモデルでも、Harnessの設計次第で大きく性能が変わる。Harnessを十分に設計した上でなお問題が残るなら、それは初めてモデル側の限界を疑うべきタイミングだ。