第5章 実践への示唆 — 確率的制御が開いた世界

第1章〜第4章で、AIシステムの構造を理解した。ステートレス性（第1章）、確率的制御と決定論的制御の二重構造（第2章）、Harnessという設計概念（第3章）、そしてそれらを統合した基盤構造図（第4章）。ここまでの議論は主に「なぜ指示通りに動かないのか」という問いに答えてきた。本章では視点を転換し、確率的制御が何を可能にしたのかを述べた上で、その能力と限界を踏まえた実践の指針を整理する。

5.1 確率的だからこそ可能になったこと

第2章では、確率的制御の「限界」を述べた。遵守率が100%にならない、指示がスキップされうる、再現性が保証されない。しかし、この性質には裏面がある。確率的に生成するからこそ、従来のプログラミングでは不可能だった判断が「書ける」ようになった。

たとえば、「この論文の中心的な概念は何か」という問いを考えてみよう。従来のプログラミングでこれに答えるには、自然言語処理のパイプラインを構築する必要がある。テキストをトークン化し、固有表現を抽出し、共起関係を統計的に分析し、クラスタリングアルゴリズムで概念群を特定する。各ステップにはそれぞれ訓練データの用意、モデルの選定、パラメータの調整が必要であり、ドメインが変われば——論文の分野が変われば——パイプライン全体を作り直すことも珍しくない。これは数週間から数ヶ月の仕事だ。

LLMに同じ問いを自然言語で投げれば、数秒で答えが返る。しかもその答えは、単なるキーワード抽出ではない。「QT45リボザイムが中心的な概念であり、それがRNAワールド仮説を支持する根拠になっている」というような、意味的な関係の理解を含んでいる。これはif文では書けない。従来の自然言語処理パイプラインでも、ここまでの意味理解を実現するには相当な設計が必要だ。

「この2つの文書の間にどんな関係があるか」「この命名は文脈に対して適切か」「この段落の論理展開に飛躍がないか」——こうした判断は、すべて確率的制御の産物だ。決定論的なコードでは「文字列Aが文字列Bに含まれるか」は判定できるが、「概念Aが概念Bを支持するか」は判定できない。後者ができるようになったことは、弱みではなく能力の拡大だ。

確率的制御は「不正確」なのではなく「柔軟」だ。決定論的プログラミングが「精密だが硬い」なら、確率的制御は「柔軟だが揺れる」。揺れは限界だが、柔軟さは能力だ。両方を使えるようになったことで、プログラムできる対象の範囲が質的に広がった。第2章で述べた決定論的制御と組み合わせれば、「柔軟な判断を確実なゲートで品質保証する」という設計が可能になる。これが本稿で言う「確率的制御と決定論的制御の二重構造」の実践的な意味だ。

5.2 自然言語で仕様を書くということ

5.1で述べた能力の拡大は、プログラミングの概念そのものを拡張する。

従来のプログラミングでは、コンピュータに何かをさせるためにプログラミング言語を使う。Python、JavaScript、C——入力を受け取り、決定論的な処理を行い、出力を返す。同じ入力に対して同じ出力が返ることが保証されている。この決定論性がプログラミングの信頼性の基盤であり、テストが書ける理由でもある。

LLMベースのシステムでは、自然言語で仕様を書く。「プロジェクトの概要と前提条件」「守るべき行動規則」「作業の手順書」——これらをテキストファイルに書いてAIに渡すと、AIはその内容を読み、解釈し、従おうとする。その実質は「自然言語で書かれたコード」だ。

たとえば、テキストの中から果物への言及を見つけたいとする。Pythonなら if "リンゴ" in text: と書く。この1行は正確に動く——テキストに「リンゴ」という文字列が含まれていれば検出する。しかし「りんご」「林檎」「apple」「アップル」は見つからない。全部拾いたければ、すべての表記を列挙する必要がある。さらに「青森産のふじ」のように品種名で言及されている場合は、品種のリストも必要だ。対象が果物全般に広がれば、果物の名前のデータベースが必要になる。コードはどんどん膨らむ。

自然言語なら「果物について言及している箇所を見つけて」と書くだけだ。AIは「リンゴ」も「りんご」も「青森産のふじ」も、文脈から判断して拾う。表記のリストを網羅する必要がない。ただし、「トマトは果物か野菜か」のような境界的なケースでは判断が揺れる——ある実行では拾い、別の実行では拾わないかもしれない。

この違いは、精密さと柔軟さのトレードオフだ。Pythonのコードは "リンゴ" と "りんご" を別物として扱う——精密だが融通が利かない。自然言語のテキストなら、AIが文脈から同じものだと解釈する——融通が利くが確実ではない。どちらが優れているかではなく、タスクの性質に応じてどちらを使うかを設計する——これが第2章で述べた「確率的制御と決定論的制御の組み合わせ」の実践的な姿だ。

自然言語で仕様を書けるということは、プログラミング言語を知らない人でもシステムの振る舞いを定義できることを意味する。プロジェクトの前提条件をテキストに書き、行動規則を箇条書きにし、作業の手順を文章で記述する——これらはすべて、従来ならプログラマーがコードとして実装していた制御を、日本語や英語で記述する行為だ。もちろん、自然言語で書く以上、解釈の揺れは避けられない。しかしその揺れは、5.1で述べたように、柔軟さの裏面でもある。具体的にどのようなファイルに何を書くかは、第6章で詳しく述べる。

重要なのは、この新しいプログラミングには従来のプログラミングとは異なるスキルが求められるということだ。コードの正確な構文ではなく、意図の明確な言語化。デバッグの代わりに、出力の評価と制約の追加。コンパイルエラーの代わりに、「期待と異なる出力」を見て原因を推測する力。これらはプロンプトエンジニアリングとも、従来のプログラミングとも異なる——第3章で述べたHarness設計のスキルだ。

5.3 よくある問題と、その構造的原因

5.1と5.2で、確率的制御が開いた能力について述べた。従来のプログラミングでは不可能だった判断が自然言語で書けるようになり、プログラムできる対象の範囲が質的に広がった。しかし能力には限界が伴う。柔軟さの裏面は揺れであり、AIを使っていて遭遇する問題の多くは、この揺れに起因している。

この表を眺めると、一つの共通パターンが見えてくる。ユーザーの不満の多くは、確率的なシステムに決定論的な振る舞いを期待していることに起因する。 5.1で述べた柔軟さと、ここで述べる揺れは同じ性質の表裏だ。「この論文の中心概念は何か」を判断できるのと同じ仕組みが、「ルールを守ったり守らなかったりする」原因でもある。

対処法は二つに分かれる。一つは期待を調整すること——「100%ではないが95%で十分」と割り切る。もう一つは仕組みを変えること——確率的制御に加えて、決定論的な検証の仕組みを設ける。どちらが適切かは、その作業における「失敗のコスト」で判断する。

アイデア出しで出力がばらつくのは、むしろ歓迎すべきだ——ばらつくからこそ、何度も試す価値がある。これは5.1で述べた柔軟さの恩恵そのものだ。一方、データ処理で手順を飛ばすのは致命的だ。入力データが欠損した状態で次のステップに進めば、以降の作業がすべて無駄になる。同じ確率的な性質が、場面によって強みにも弱みにもなる。

この判断を各タスクの各制約に対して行うことが、Harness設計の中心的な作業になる。「この制約は確率的制御の柔軟さに任せてよいか、それとも決定論的な検証で保証すべきか」——5.2で述べた「精密さと柔軟さのトレードオフ」は、こうした具体的な判断の積み重ねとして実践される。具体的にどのような仕組みを使うかは第6章で述べるが、判断の基準自体はシンプルだ：守られなかったときに取り返しがつかないなら、決定論的に保証する。そうでなければ、柔軟さを活かして確率的制御に任せる。

5.4 問題の診断 — Harnessか、モデルか

5.3で述べた問題が実際に起きたとき、原因がどこにあるかを正しく診断することが対処の出発点になる。第3章で述べた「馬と馬具」の区別がここで効いてくる。

AIの出力がおかしいと感じたとき、多くの人は「AIの性能が低い」か「自分の指示が悪い」のどちらかに原因を帰着させる。しかし第3章で述べたように、AIシステムはモデル（馬）とHarness（馬具）の二層構造であり、問題の所在もこの二層のどちらかに切り分けられる。

問題が発生
  │
  ├─ コンテキストに必要な情報が入っているか？
  │    No → コンテキストの設計の問題（Harness側）
  │          対策: AIに渡す情報——前提条件、文脈、判断基準——を改善する
  │
  ├─ 情報は入っているが、指示通りに動かない？
  │    → 確率的制御の限界（Harness側）
  │      対策: 指示の書き方を改善する、または決定論的な検証を追加する
  │
  ├─ Harnessを整えても改善しない？
  │    → モデルの能力限界（モデル側）
  │      対策: モデルを変える、またはタスクを人間とAIで分担する
  │
  └─ 特定の言語・専門分野で精度が低い？
       → モデルの訓練データの偏り（モデル側）
       対策: その分野に強いモデルを選ぶ

このフローで最も重要なのは、上から順に確認することだ。

最初の分岐——コンテキストに必要な情報が入っているか——は、最も見落とされやすく、最も対処が容易な原因だ。5.1で述べた確率的制御の能力は、コンテキストに十分な情報があって初めて発揮される。「この論文の中心概念は何か」を判断できるのは、論文のテキストがコンテキストに入っているからだ。情報が不足していれば、AIは推測に頼らざるを得ず、出力の質は下がる。第3章で述べた対話の4要素——目的、文脈、仮説、判断基準——がコンテキストに含まれているかを確認するだけで、多くの問題は改善する。

2番目の分岐——情報はあるが指示通りに動かない——は、5.2で述べた「自然言語で書かれたコード」の限界に相当する。自然言語の仕様はAIの判断に影響を与えるが、強制はしない。ここでの対処は二つある。一つは指示の書き方を改善すること——曖昧な表現を具体的にする、理由を添える、例を示す。もう一つは、第2章で述べた決定論的制御を追加すること——スクリプトやコードで条件を自動検証する仕組みを入れる。どちらを選ぶかは5.3で述べた「失敗のコスト」で判断する。

3番目と4番目の分岐に至るのは、上の二つを十分に試した後だ。同じモデルでも、コンテキストに載せる情報を変えるだけで出力が劇的に改善することは珍しくない。「このAIは使えない」と結論づける前に、まずHarness側でできることが残っていないか確認する。逆に、Harnessを十分に整えた上でもモデルが特定のタスクをこなせない場合——たとえば、ある専門分野の知識が訓練データに含まれていない場合——は、自然言語の仕様をいくら工夫しても改善しない。その場合は素直にモデルを変えるか、人間が補完する判断が必要だ。

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

5.5 ツール選択の指針

5.1〜5.2で述べた確率的制御の能力と、5.3〜5.4で述べたその限界と診断法を踏まえると、ツールの選択はタスクの性質によって自然に決まる。現時点でのAIツールは、大きく三つのカテゴリに分かれる。

チャットUI（Claude.ai, ChatGPT等）: ほぼすべてが確率的制御の世界だ。ユーザーが決定論的な検証の仕組みを設計する手段はない。その代わり、対話の自由度が最も高い。第3章で述べた「思考をぶつける」対話には最適だ。構想を練る、設計を議論する、文章を推敲する——5.1で述べた確率的制御の柔軟さが最も活きる場面であり、多くの人にとってAIの最初の接点がここだ。

チャットUIの制約は、5.3で述べた問題がすべて確率的制御の範囲内でしか対処できないことだ。「ルールを守ってくれない」問題に対して、指示の書き方を工夫する以外の手段がない。日常的な使い方——調べ物、文章の推敲、アイデア出し——にはこれで十分だが、手順の遵守や品質の保証が必要な作業には向いていない。

エージェントツール（Claude Code, Codex, Gemini CLI等）: 確率的制御に加えて、決定論的な検証の仕組みを設計できる。ファイル操作、コード実行、外部ツール連携が可能であり、5.2で述べた「自然言語で仕様を書く」ことを最も体系的に実践できるカテゴリだ。プロジェクトの前提条件、行動規則、作業手順、自動検証——これらをテキストファイルとスクリプトの組み合わせとして設計し、AIの振る舞いを確率的制御と決定論的制御の両面から制御できる。手順の遵守が重要な作業——実装、データ処理、定型的なパイプライン——に向いている。ただし、第9章で述べるように、ツールごとに決定論的制御の対応状況が異なる。

エージェントツールの利点は、5.3で述べた問題の多くに対してHarness側の対策が打てることだ。「手順を飛ばす」問題には自動検証を、「セッションをまたぐと文脈が消える」問題には状態の外部永続化を、それぞれ仕組みとして設計できる。チャットUIでは「指示の工夫」で対処していた問題を、「仕組みの設計」で対処できるようになる。

API + 自作オーケストレーション: 最も自由度の高いHarness設計が可能だ。AIの呼び出しとその結果の処理のループ全体を自分でコードとして書くため、確率的制御と決定論的制御の配分を完全に制御できる。ただし技術的コストが高く、ソフトウェア開発の知識が必要になる。

全部をチャットUIでやろうとするのは、ネジを回すのに金槌を使うようなものだ。逆に、アイデア出しにエージェントツールを使うのも非効率である。タスクの性質に応じてツールを選ぶ——5.1で述べた柔軟さを活かす場面ではチャットUI、5.3で述べた限界に対処する仕組みが必要な場面ではエージェントツール。この判断自体が、Harness設計の最初のステップだ。

5.6 構造化しすぎないこと

最後に、逆方向の注意を述べておく。

本稿はAIシステムの構造を理解し、Harnessを設計することの重要性を説いている。しかし、あらゆる作業を構造化すべきだと言っているわけではない。

5.1で述べたように、確率的制御の柔軟さはそれ自体が能力だ。チャットUIで「ちょっとこれ調べて」「この文章を直して」と頼む。思考をぶつけて構成を練る。アイデアを発散させる。——こうした日常的な使い方には、Harnessの設計は不要だ。仕様書も、行動規則のファイルも、自動検証のスクリプトも要らない。必要なのは、第3章で述べた対話の4要素——目的、文脈、仮説、判断基準——をAIに渡すことだけだ。これは構造化ではなく、対話の質の問題であり、すべての人がすべてのツールで今すぐ実践できる。

構造化が必要になるのは、5.3で述べた問題が具体的に発生したときだ。

作業が複数セッションにまたがるとき。 ステートレスなモデル（第1章）にセッション間の文脈を渡すには、状態を外部ファイルに書き出す仕組みが必要になる。「昨日の続きから始めたい」が日常的に起きるなら、セッション再開時にAIが読み込む前提条件のファイルを設計する。これがHarnessの最も基本的な形だ。

手順の遵守が重要なとき。 5.2で述べた自然言語の仕様だけでは、手順がスキップされるリスクが残る。データ処理パイプラインや本番環境への操作など、失敗のコストが高い場面では、手順の完了を自動的に検証する仕組みが必要になる。これは5.3で述べた「決定論的な検証の追加」にあたる。

成果物の品質を一定水準以上に保つ必要があるとき。 一回限りの使い捨てなら多少の品質のばらつきは許容できる。繰り返し使う成果物なら、出力が品質基準を満たしているかを自動チェックする仕組みが必要になる。

これらの条件に当てはまらないなら、構造化のオーバーヘッドは作業を遅くするだけだ。「困ったら入れる」 ——構造化は、必要性を感じてから導入すれば十分である。確率的制御の柔軟さだけで仕事が回っているなら、それが最もシンプルで効率的な状態だ。問題が起きて初めて、その問題に対処する仕組みを足していく。第6章以降では、その「足していく仕組み」の具体的な道具と使い方を述べる。

実用上のポイント: 「ちょっとこれ調べて」「この文章を直して」にHarnessは要らない。構造化を検討するのは、「前回のセッションの文脈が消えた」「AIが手順を飛ばした」「同じミスが繰り返される」といった具体的な問題に遭遇してからでよい。問題が起きていないのに予防的に構造化するのは過剰設計だ。