おわりに — 思考をぶつけること、構造を知ること

本稿で述べたこと

本稿は、LLMベースのAIシステムを「使いこなす」ために必要な構造的理解を、ユーザーの視点から整理した。全体を貫く二つの軸がある。

第一の軸は構造の理解だ。LLMはステートレスであり、毎回がコンテキストウィンドウの中身だけを見た白紙からのスタートである（第1章）。出力はすべて確率的であり、テキストによる指示は「影響を与える」が「強制する」ことはできない。確実な制御にはモデルの外側に決定論的な仕組みが必要だ（第2章）。この二つの制御を統合する枠組みがHarnessであり、Context Engineeringがコンテキストの質を最大化し、Architectural Constraintsが決定論的なゲートを提供する（第3章）。これらを一枚の図に統合したのが基盤構造図だ（第4章）。

第二の軸は対話の実践だ。AIの出力品質はコンテキストウィンドウの中身で決まり、対話はそのコンテキストの主要な供給源である。「答えを引き出す」のではなく「思考をぶつける」ことで、コンテキストが自分の文脈で満たされ、AIの出力は自分の状況に特化したものになる（第3章）。

構造から実践へ、実践から発見へ

構造の理解は、それ自体が目的ではない。実践のための基盤だ。

第5章で述べたように、確率的制御は従来のプログラミングでは不可能だった判断を可能にした——同時に、その柔軟さの裏面として揺れや限界も伴う。この両面を理解すれば、対処が明確になる——プロンプトの文言を工夫するのではなく、仕組みの設計を変える。第6章のHarness機能群（CLAUDE.md、Rules、Skills、Hooks、Agents）はそのための道具であり、第7章のシンプルな課題を通じて、ゼロから段階的に組み立てる方法を示した。

第8章で抽出した設計原理——反復サイクル、意図の文書化、構造化、外部永続化、satisficingによる完了判断——は、特定のツールや課題に依存しない。そして第9章の移植テストは、これらの原理が別のモデル・ツールでどう機能するかを段階的に検証した。

第9章で得られた知見は、本稿の議論に新たな奥行きを加えた。第2章では確率的制御と決定論的制御を「どちらをどこに配置するか」の設計判断として論じた。しかし移植テストは、同じ制約がモデルの傾向によって異なる機能を持つことを明らかにした。同じRulesがClaudeには探索のガイド、Codexにはデフォルトの確認、Geminiには制限と教育の二方向として作用する。同じHooksがClaudeには品質向上の刺激、Codex/Geminiには行動の萎縮として作用する。「何を配置するか」だけでなく「それがこのモデルにどう作用するか」まで含めた設計判断が必要だ——これは第2章の枠組みの拡張であり、実践を通じて初めて見えてきた知見だ。

本稿で述べなかったこと

本稿が扱ったのは「ユーザーが設計できる範囲」——すなわちHarnessだ。モデル自体の内部構造（Transformerのアテンション機構の詳細、訓練手法の差異、ファインチューニングの技術）は意図的に省略している。ユーザーが変更できない領域の詳細は、使いこなしの文脈では優先度が低いからだ。

ただし、第9章の移植テストは「モデルの内側」と「Harnessの外側」の境界が想定より複雑であることを示唆している。Codexが訓練データからナレッジグラフの語彙を内在化していた事実は、モデルの事前知識がHarnessの効果に直接影響することを意味する。Harnessの設計者が変更できないのはモデルのパラメータだが、モデルの傾向を知ることはHarness設計の質を上げる。第3章で述べた「馬を知る人間が馬具を設計する」という比喩の「馬を知る」部分が、移植テストによって具体的な手法として示された——段階1（制約なし）でモデルの素の傾向を観察し、そこから段階的に制約を足していく。

また、AIの倫理的問題、社会的影響、法的責任の所在についても扱っていない。これらは重要な問題だが、本稿の射程——「構造を知って使いこなす」——とは別の議論が必要になる。

本稿で繰り返し強調した「確率的制御の限界」は、現時点でのアーキテクチャに基づく議論だ。モデルの推論能力が向上し、指示への遵守率が上がれば、確率的制御だけで十分な範囲は広がるだろう。しかし、確率的生成という原理そのものが変わらない限り、「100%の遵守が必要な場面では決定論的制御が要る」という構造は残り続ける。

変化する技術、変わらない原理

AI関連の技術は急速に変化している。本稿で述べたClaude Code、Codex CLI、Gemini CLIの具体的な機能は、数ヶ月後には大きく変わっているかもしれない。新しいツールが登場し、今のツールの一部は廃れるだろう。第9章の比較表は2026年3月時点のスナップショットであり、各ツールのHooks機能やSkills標準化は急速に進化している。

しかし、本稿の議論のうち、技術の変化に依存しない部分がある。

LLMがステートレスであること——これはアーキテクチャの原理であり、ユーザーとの会話でパラメータが変わらない限り変わらない。出力が確率的であること——これは自己回帰生成の原理であり、サンプリングが残る限り変わらない。コンテキストウィンドウに上限があること——これは計算資源の物理的制約であり、ウィンドウが広がっても消えるものではない。

これらの原理に基づく設計判断——「どこを確率的に任せ、どこを決定論的に守るか」「何をコンテキストに載せ、何を外部化するか」「いつ自由にし、いつ固めるか」——は、具体的なツールが変わっても有効だ。

そして第9章が加えた知見——同じ制約がモデルの傾向によって異なる効果を持つ——もまた、特定のモデルやツールに依存しない原理だ。将来のモデルが現在のClaude、GPT、Geminiとは異なる傾向を持つとしても、「まず素の傾向を観察し、制約がそのモデルにどう作用するかを段階的に検証する」というアプローチは有効であり続ける。

ツールの使い方は変わる。モデルの傾向も変わる。設計原理は残る。本稿が提供したいのは、最後のものだ。

AIとの向き合い方

はじめにで述べた問いに戻る。AIを使いこなす上で最も重要なのは何か。

それは対話であり、構造の理解だ。

対話は、コンテキストウィンドウを自分の思考で満たす行為だ。十分な目的、文脈、仮説、判断基準を持ってAIにぶつけることで、AIの応答精度は劇的に上がる。これは技術的な工夫ではなく、知的な作業への向き合い方の問題だ。

構造の理解は、問題が起きたときに「なぜそうなるのか」を構造的に診断し、適切な対処を選ぶための基盤だ。プロンプトの文言を闇雲に調整するのではなく、問題の所在（コンテキスト不足なのか、確率的制御の限界なのか、モデル自体の能力不足なのか）を特定し、適切な層で対処する。第9章の移植テストで筆者自身が体験したように、「同じ指示を渡せば同じように動くだろう」という直感すら、構造を知ることで初めて疑える。

多くの人がAIに対して感じる「不満」や「不信感」の多くは、このアーキテクチャの性質を知らないことに起因している。「AIが悪い」のでも「自分のプロンプトが悪い」のでもなく、確率的システムに決定論的な結果を期待していた——というミスマッチが原因であることが多い。

この構造を理解した上で、確率的制御と決定論的制御の境界線をどこに引くか、そしてAIに何をぶつけるか——それがAIを「使いこなす」ための出発点になる。

そして、ここに本稿の二つの軸が合流する。Harness設計は「構造の理解」に基づく技術的な作業に見えるかもしれない。しかし実際には、Harness設計そのものが対話を通じて行われる。「この手順はHooksで強制すべきか、Rulesで十分か」「コンテキストに何を載せ、何を外部化すべきか」「Workerをどう分割すべきか」——これらの設計判断は、AIとの対話の中で具体化し、洗練されていく。自分の意図と制約をAIにぶつけ、AIの応答から構造を発見し、その構造をまたAIにぶつける。本稿自体がこのプロセスで作られたように、Harnessもまた対話の中から生まれる。

つまり、対話と構造の理解は別々の能力ではなく、一つのループだ。構造を知るから適切な問いが立てられ、対話から新しい構造が見えてくる。このループを回し続けることが、AIを「使いこなす」ということの本質だと、筆者は考えている。

用語集

用語説明
LLMLarge Language Model（大規模言語モデル）。大量のテキストで訓練されたAIモデル
ステートレス状態を持たないこと。会話による内部状態の変化がない
コンテキストウィンドウ1回のやり取りでモデルが「見える」範囲。有限
auto-compactコンテキストウィンドウの上限を超えた際に古い部分を切り落とすこと
トークンモデルが処理するテキストの最小単位（単語や単語の断片）
Transformer現在のLLMの基盤となるニューラルネットワークのアーキテクチャ
確率的制御テキストベースの指示によるモデルへの影響。100%の遵守は保証されない
決定論的制御コード実行による強制。Hooksなど。100%確実に動作する
Harnessモデルの外側を包む制御・支援の仕組みの総体（馬具）
Context Engineeringコンテキストウィンドウの中身を最適化する設計手法
Harness EngineeringHarnessのループ全体を設計する手法
CLAUDE.mdClaude Codeでセッション開始時に自動読み込みされるプロジェクト指示ファイル
AGENTS.mdLinux Foundation Agentic AI Foundation傘下のオープン標準プロジェクト指示ファイル。Codex CLI、GitHub Copilot、Cursor等がネイティブに読み取る
Rules.claude/rules/に配置する行動規則ファイル。確率的制御
Skills.claude/skills/に配置するワークフロー（作業の流れ）定義。SKILL.mdとサポートファイルで構成。手動呼び出し＋自動発動に対応
SKILL.mdAgent Skillsオープン標準のファイルフォーマット。Claude Code、Codex CLI、Gemini CLI等30以上のツールが同一フォーマットを読み取る
Hooksエージェントの動作中の特定イベントに紐づくスクリプト実行の仕組み。決定論的制御
Stop Hookモデルが「完了」と判断したタイミングで発動するHook。条件未達なら完了をブロックして差し戻す
PreToolUse Hookモデルがツール（ファイル書き込み等）を使おうとした瞬間に発動するHook。条件を満たさなければツール実行自体をブロックする
MCPModel Context Protocol。AIと外部ツール・データソースを接続する標準プロトコル
Agentsタスクを分割して複数のモデルインスタンスに委任する仕組みの総称。Task Tool / Subagents（階層型）とAgent Teams（チーム型）の二つの実装がある。コンテキスト分離と並列実行を実現する
Lead / WorkerTask Tool / Subagentsにおける役割分担。Leadが全体を統括しタスクを割り振り、Workerが個別タスクを独立したコンテキストで実行する
TaskツールClaude CodeでWorkerエージェントを起動するための仕組み。最大10並列。決定論的なプロセス生成
SubagentsClaude Codeにおける特化型エージェント定義。Worker定義にモデル選択やツール制限を加えたもの。Gemini CLIでも同名の実験的機能がある
Agent TeamsClaude Codeの実験的機能（2026年2月〜）。メールボックスによるピアツーピア通信と共有タスクリストを持つ協調型マルチエージェント。コンテキストウィンドウは分離されたまま、明示的なメッセージのみを共有する
TeammateAgent Teamsにおける個々のエージェント。独立したコンテキストウィンドウを持ち、メールボックスを通じて他のTeammateやTeam Leadと直接メッセージを交換できる
proposal.mdプロジェクトの意図・目的・方針を記述する提案書。AIへのインプットの構造化
三層モデルHarnessの構造を移植可能性の観点で整理した分類。ドキュメント層（自然言語の意図・仕様）、実行環境層（Skills/Rules/Worker定義のファイル配置）、手順保証層（Hooksの決定論的制御）の三層。第9章で導入
Satisficing「最適解ではなく、十分に良い解を受け入れる」意思決定原理（Herbert Simon）。AI駆動プロジェクトでは、完了基準を提案書に定義しHooksで強制する
Codex CLIOpenAIのエージェントツール。GPTモデルを搭載し、OSカーネルレベルのサンドボックスを安全性の主軸とする設計哲学を持つ
Gemini CLIGoogleのGemini向けエージェントツール。Claude Codeとほぼ同等のアプリケーションレベルHooksを備え、migrate --from-claudeによる設定移行をサポートする
RAGRetrieval-Augmented Generation。外部知識を検索してコンテキストに注入する手法
Constitutional AI訓練時にモデルに組み込まれる安全性の振る舞い
RLHFReinforcement Learning from Human Feedback。人間のフィードバックによる強化学習

参考文献

Harness Engineering

Context Engineering

「Context Engineeringとは、コンテキストウィンドウを次のステップに最適な情報で満たす、繊細な技術と科学だ」

「Prompt Engineeringよりcontext engineeringという用語が好きだ。LLMがタスクを解ける状態にするための全文脈を提供する技術を、より適切に表現している」

アーキテクチャ・基礎理論

ツール・プロトコル

Harnessの実証実験

ツール間比較・標準化

Vibe Coding

反復的開発と科学的方法

移植テストの題材

本稿について

本稿は、AI駆動研究開発の実践を通じて得られた知見をもとに構成されている。LLMのアーキテクチャ（ステートレス性、確率的生成）から出発し、Harnessの設計原理、具体的な機能の使い方、タスク特性に応じた設計判断、ツール間の移植可能性まで、全9章で体系的に論じた。

理論的な正確さよりも、ユーザーが「なぜそうなるのか」を構造的に理解し、実践に活かせることを優先した。各章末の「実用上のポイント」は、構造の理解を日常の使い方に接続するための手がかりとして配置している。

本稿自体が「はじめに」で述べた対話モデルで作られている。筆者がAIとの対話の中で構造を発見し、対話の過程で章立てや概念整理が生まれた。最初から「この内容を書こう」と決まっていたわけではなく、対話の中で構造が明らかになっていった。

著者: 渡部匡己（自然科学研究機構 基礎生物学研究所）

最終更新: 2026-03-16

← 第9章 Harnessの移植