第9章 Harnessの移植テスト — 同じHarnessを別のモデルで動かす

本章の主題。 第7〜8章で構築したHarnessを別のLLMツールで動かし、モデルやツールの違いがHarnessの動作にどのような影響を与えるかを観察する。

9.1 なぜ移植するのか

第7章と第8章では、Claude Code上でHarnessを構築し、4サイクルの反復を経て概念ネットワークの構築を実現した。しかし、この実践はClaude Codeという一つのツール、Claudeという一つのモデルの上でしか動かしていない。Harnessが機能したのは事実だが、それが設計自体の力なのか、Claudeの日本語理解力や指示への従順さ、Claude CodeのHooks機構の成熟度に助けられた結果なのかは区別できない。一つのモデル・ツールの上で動いただけでは、こうした疑問に答えられない。

第9章では、Harnessの設計がどこまでモデルやツールに依存しているかを確認するために、移植テストを行う。Harnessを構成するファイル群——プロジェクト指示、Rules、Skills、Hooks設定、検証スクリプト——を、別のモデル・ツールにそのまま渡して同じタスクを実行する。Harnessにとっての「プラットフォーム」は二つの要素から成る。一つはモデル（Claude、GPT、Gemini）——自然言語の指示を解釈し、概念の抽出やYAMLの生成を実行する側だ。もう一つはツール（Claude Code、Codex CLI、Gemini CLI）——HooksやSkillsといった実行基盤を提供し、Harnessのファイル群を読み込んでモデルに渡す側だ。モデルを変えれば、同じRulesやSKILL.mdの同じ文章に対する解釈が変わる。ノードの粒度、エッジの選び方、手順の遵守率——すべてがモデルの傾向に影響される。ツールを変えれば、Stop Hookが手順を強制できるか、Skillsがどう発動するか、Rulesがどこに配置されるかが変わる。Harnessを固定してこの二つの変数を動かすことで、設計の環境依存性と、モデルごとの解釈の傾向や応答特性の差異を同時に観察できる。

移植先として、Codex CLI（OpenAIのエージェントツール）とGemini CLI（GoogleのGemini向けエージェントツール）を選んだ。いずれもClaude Codeと同じカテゴリのエージェントツールであり、ファイル操作、コード実行、外部ツール連携が可能だ。ただし、内部のモデル（GPT、Gemini）はClaude（Anthropic）とは異なる訓練データとアーキテクチャを持っている。三つのツールはいずれも活発に開発が続いており、2026年3月時点でSkillsやHooksの標準化が急速に進んでいる。この時期に移植テストを行うことは、標準化がどこまで実効性を持っているかを実地で確認する意味も含む。

9.2 モデル間の解釈の揺らぎ

9.1で述べたように、Harnessにとってのプラットフォームはモデルとツールの二つの要素から成る。本節ではまず、モデルを変えたとき何が変わるかを整理する。

第2章で述べた揺らぎは、同一モデル内の実行間の揺らぎだった——同じ入力に対して、実行のたびに異なる出力が生まれる。ここで述べるのはモデル間の揺らぎだ。異なるモデルが同じ自然言語の指示を読んだとき、解釈にどのような差異が生じるか。

5.2で果物の検索を例にとった。Pythonのコードなら "リンゴ" in text の結果は全処理系で同じだ。自然言語の「果物について言及している箇所を見つけて」は、AIによって結果が異なりうる——あるモデルは品種名まで拾い、別のモデルはカテゴリ名しか拾わない。この揺らぎがモデル間の移植でも現れる。移植テストの文脈で言えば、SKILL.mdに「論文から概念ネットワークのノードとなる要素を抽出する」と書いたとき、「ノードとなる要素」の粒度も範囲もモデルによって異なりうる。

モデル間の解釈の揺らぎには、複数の性質がある。

解釈の傾向 — モデルごとに一貫した方向性を持つ差異。あるモデルは指示を「従うべき手順」として読み、一つずつ順番に実行しようとする。別のモデルは「最終目標の記述」として読み、目標に向かって自由にアプローチする。あるモデルは網羅的に生成する傾向があり、別のモデルは凝縮する傾向がある。これらは実行のたびにランダムに変わるのではなく、モデルの訓練に由来する一貫した傾向だ。移植テストでは、この傾向が概念ネットワークの構造——ノード数の多寡、エッジの密度、抽象度の高低——に直接反映されるはずだ。

解釈の癖 — 特定の指示に対する予測しにくい反応。「Phase完了ごとにgit commitせよ」という指示が効くモデルと効かないモデルがある。なぜ効かないかは外から見えない——同じ文章を「読んだ」上でスキップする。プログラミング言語なら構文エラーとして検出できるが、自然言語では黙って異なる出力を返す。この不透明さが癖の厄介さだ。第8章のサイクル3で、Claudeでさえ「全項目PASS」と虚偽報告したことを思い出してほしい。同じモデル内でも起きることが、モデル間ではさらに予測しにくい形で現れる。

感受性の差 — 同じ指示書の中で、どの部分にどれだけ強く反応するかがモデルごとに異なる。長い指示書の冒頭の制約に強く反応するモデルもあれば、末尾の具体例に強く反応するモデルもある。Rulesの書き順や強調の仕方がモデルによって異なる効果を持つ。いわゆる「プロンプトのベストプラクティス」がモデルごとに異なるのは、この感受性の差に起因する。SKILL.mdの手順の記述順を変えただけで、あるモデルでは遵守率が上がり、別のモデルでは変化しない——こうした差異は事前には予測できない。

これらは5.2で述べた「精密さと柔軟さのトレードオフ」の延長にある。自然言語で仕様を書く柔軟さは、全モデルが読めるというポータビリティを生む。しかし同時に、モデルごとの傾向・癖・感受性の差異という揺らぎも生む。柔軟さとポータビリティ、揺らぎと解釈の差異——5.1で述べた「同じ性質の表裏」がここでもモデル間のレベルで繰り返されている。

対処の方向性は性質ごとに異なる。傾向は事前に把握できるため、モデルの特性に合わせた書き換えで対応する。癖は実行して初めて判明するため、テストと修正の反復で対応する。感受性は指示の書き方の調整で対応する。ただし、すべてを完璧にチューニングする必要はない——5.6で述べた「困ったら入れる」の原則はここでも当てはまる。まずそのまま渡してみて、問題が出た箇所だけを修正する。

9.3 三層モデルとツール間の仕様

9.2ではモデルを変えたとき何が変わるかを整理した。本節では、Harnessの構造を三つの層に分け、各層がモデルとツールの変更にどう反応するかを整理する。第5章と第6章の議論に基づく分類だ。

第1層: ドキュメント層
       proposal.md, spec.md, progress.md, issues.md
       — 自然言語で書かれたプロジェクトの意図・仕様・状態の記録

第2層: 実行環境層
       Skills, Rules, Worker定義, 検証スクリプト
       — Harnessの実行に必要なファイル群。ツール固有のフォーマットを含む

第3層: 手順保証層
       Hooks（Stop hook, PreToolUse hook）
       — 決定論的制御の実装。ツールのアーキテクチャに直接依存する

第1層（ドキュメント層） は、ツールの変更にはほとんど影響されない——どのツールからでもテキストファイルとしてそのまま読める。ファイル形式の変換は不要だ。しかし、モデルとの関係はより複雑だ。ドキュメント層の中身は一様ではない。CLAUDE.mdのようにユーザーが自分の言葉で記述したものは、どのモデルに渡しても内容は同じだ。一方、RulesやSKILL.mdはClaude Codeとの対話の中で作り込まれたものであり、Claudeが解釈しやすい形で構造化されている可能性がある。たとえば、指示の優先度を示す強調の置き方、許可リストの提示方法、手順の区切り方——これらにClaudeの解釈傾向に合わせたプロンプト表現が入り込んでいる。9.2で述べた感受性の差がここに関わる。各モデルにはプロンプトのベストプラクティスが存在し、あるモデルで効果的な表現が別のモデルでは無視されたり、逆効果になったりする。同じRulesやSKILL.mdを別のモデルに渡したとき、Claude向けの表現がGPTやGeminiで同じ効果を持つかは、実際に試してみなければわからない。第1層は「渡すこと」は容易だが、「同じように効くこと」は保証されない。第8章のようにproposal.mdから/setupでspec.mdやWorker定義を生成する場合も同様で、生成されたドキュメントにはモデル固有のプロンプト表現が埋め込まれる。

第2層（実行環境層） は、主にツールの変更に影響される。Skills、Rules、Worker定義は自然言語で記述されているため内容自体はポータブルだが、ファイルの配置場所やフォーマットがツールごとに異なる。ただし、2026年3月時点ではツール間の標準化が急速に進んでおり、変換の手間は以前より大幅に軽減されている。

プロジェクト指示ファイルは収束しつつある。Claude Codeは CLAUDE.md、Codex CLIは AGENTS.md、Gemini CLIは GEMINI.md をプロジェクトルートから自動読み込みする。ファイル名は異なるが、中身は同じ自然言語だ。注目すべきは AGENTS.md の動向だ。これはLinux FoundationのAgentic AI Foundation傘下のオープン標準として策定されている。Codex CLI、GitHub Copilot、Cursor、Windsurf、Amp等の主要ツールがネイティブに読み取る。Claude CodeのAGENTS.md対応は予定されており、Gemini CLIもAGENTS.mdを認識する。実用上は、共通の指示をAGENTS.mdに書き、ツール固有の設定だけをCLAUDE.mdやGEMINI.mdに分離するアプローチが広まりつつある。

Skills（手順定義）も標準化されている。Agent Skills（SKILL.md）はAnthropicが2025年10月に導入し、2026年2月にオープン標準として公開した。Claude Code、Codex CLI、Gemini CLI、Cursor、GitHub Copilot等30以上のツールが同じSKILL.mdフォーマットを読み取る。本稿の実践例で使った /setup や /execute の中身をSKILL.md形式で書けば、変換なしで複数ツールに対応できる。

行動規則の配置場所はまだ標準化が進んでいない領域だ。Claude Codeは .claude/rules/ ディレクトリに独立ファイルとして配置し、Codex CLIは AGENTS.md に統合転記し、Gemini CLIは GEMINI.md に統合転記する。規則の内容自体は同じ自然言語なので転記は容易だが、配置方法の標準化はまだ途上にある。

Worker定義ファイルの中身は全ツールで共通の自然言語だが、配置パスが異なる（Claude Codeは .claude/agents/、Codex/Geminiは .agents/ や docs/agents/）。

検証スクリプト（第7章のvalidate_yaml.sh、第8章のvalidate_phase.py等）はシェルやPythonで書かれた決定論的なコードであり、モデルにもツールにも依存しない——どの環境でも同じ結果を返す。

以下の比較表は2026年3月時点のものだ。

第3層（手順保証層） は、ツールの変更に最も強く影響される。第2章で述べたように、Hooksは「モデルの外側でコードとして動く」決定論的制御の仕組みだ。9.1で挙げた「Stop Hookが手順を強制できるか」という問いは、この層に属する。Claude CodeのStop Hookをそのまま別のツールに持っていけるかは、そのツールがどのようなHooks機構を備えているかに完全に依存する。この機構の実装と成熟度は各ツールで異なり、かつ急速に進化している。以下は2026年3月時点の状況であり、数ヶ月後には大きく変わっている可能性がある。

Claude Codeは、2026年3月時点で12以上のライフサイクルイベント（PreToolUse、PostToolUse、Stop、SessionStart、SubagentStop等）をネイティブに備えている。特にPreToolUseはツール実行の前にスクリプトを走らせ、条件を満たさなければ実行をブロックできる。

Codex CLIは、Hooks機構の実装を進めている。v0.99.0でAfterAgent（エージェント完了後）、v0.100.0でAfterToolUse（ツール実行後）が追加され、v0.114.0（2026年3月）でSessionStart（セッション開始時）とStop（ターン終了時）が実験的に追加された。ただし、Claude CodeのPreToolUseに相当する「ツール実行の前にブロックする」機構はまだない。Codexの設計哲学はアプリケーションレベルのHooksよりも、OSカーネルレベルのサンドボックス（macOSのSeatbelt、LinuxのLandlock/seccomp）で安全性を確保するアプローチをとっている。粒度は粗いが、プロセスレベルで確実だ。

Gemini CLIは、v0.26.0（2026年1月）でHooks機能を正式に導入した。BeforeTool（ツール実行前のブロック）、AfterAgent（エージェントループ終了後の差し戻し）、BeforeModel（LLMリクエストの修正）など約12のライフサイクルイベントを備えている。Claude Codeとほぼ同等のきめ細かい制御が可能だ。Claude Codeからの移行コマンド（gemini hooks migrate --from-claude）も用意されており、設定の互換性を意識した設計になっている。

三ツールの設計哲学を整理すると、決定論的制御の実装方法と成熟度が異なる。Claude CodeとGemini CLIはアプリケーションレベルのHooksで「この特定のファイルへの書き込みをブロックする」というきめ細かい制御ができる。Codexはアプリケーションレベルのhooksを拡充しつつあるが（4イベント、experimental）、安全性の主軸はOSカーネルレベルのサンドボックスに置いている。

以上をまとめると、三層の移植容易性は異なる。ドキュメント層はファイルとしてはそのまま渡せるが、モデルが生成したプロンプト表現の依存性がある。実行環境層は標準化の恩恵でほぼ変換不要になりつつある。手順保証層はツールの設計哲学に依存し、移植テストで最も複雑な観察対象になる。9.2の揺らぎの枠組み（傾向・癖・感受性）と本節の三層モデルの枠組みを組み合わせて、移植テストで観察される差異がモデル由来なのかツール由来なのかを切り分ける。SKILL.mdの手順がスキップされたとき、それは配置パスの問題でSkillが読み込まれなかったのか（ツール側）、読み込まれた上で無視されたのか（モデル側）。この区別がなければ、対処の方向を誤る。

9.4 実践 — 移植テストの実行と結果

移植テストを始める前、筆者はこう考えていた——同じ論文を渡し、同じRulesとSKILL.mdを読ませるのだから、出力にそれほど大きな差は出ないだろう。モデルが違えば揺らぎはあるだろうが、ノード数が半分になったり倍になったりはしないだろう、と。

この予想にはそれなりの根拠がある。第一に、三ツールはいずれも最先端のLLMを搭載している。論文を読んで概念を抽出するという知的作業は、どのモデルにとっても基本的な能力の範囲内だ。第二に、Harnessの設計意図は「モデルの判断を方向づける」ことにある。type 7種・relation 8種の許可リスト、5ステップの手順書——これらの制約を読めば、出力の形式と方向性は揃うはずだ。第三に、9.3で確認したように、SKILL.mdの標準フォーマットは三ツールすべてがネイティブに読み取れる。ファイルの中身は一文字も変えていない。同じ指示を読める三つのモデルが、同じ論文を読んで、大きく異なる結果を出す理由が思いつかない。

第7章では、Claude Code上で段階1（CLAUDE.mdのみ）から段階4（Rules + Skills + Hooks）まで機能を一つずつ追加した。ここでは同じ段階を三ツールで並行して踏む。段階ごとに何が変わったかを三ツール同時に観察することで、差異の発生源を特定する。入力は同じ論文（Gianni et al., Science 2026）、プロンプトも同一構造だ。

各段階で追加するファイルは以下の通りだ。

段階1: プロジェクト指示のみ（CLAUDE.md / AGENTS.md / GEMINI.md — 6行）
段階2: + Rules（type 7種・relation 8種の許可リスト — 30行）
段階3: + Skills（SKILL.md — 5ステップの手順書 — 54行）
段階4: + Hooks（validate_yaml.sh — 9項目の整合性チェック — 80行）

段階1〜3は確率的制御の積み上げ、段階4で決定論的制御が加わる。第2章で述べた二つの制御が、三つの異なるモデルに対してどう作用するかを観察する。

#### 段階別の推移

各段階での三ツールの出力を、ノード数 / エッジ数（type種数, relation種数）として一覧にする。

† Rulesの7種とは異なる独自の9種（molecule, theory, analysis等）を自由に発明

‡ 定義済みrelationではなく「が触媒」「を支持」等の自由な日本語動詞句を使用

太字は当該段階で初めて全種達成したことを示す

実行ファイル一式と段階別の比較分析: examples/chapter9/

段階4の概念ネットワーク可視化: Claude Code（28ノード・メッシュ型） / Codex CLI（17ノード・線形） / Gemini CLI（7ノード・スター型）

#### モデルの素の傾向（段階1）

まず段階1——プロジェクト指示6行のみ、Rules/Skills/Hooksなし——の結果を見る。冒頭で述べた「大きな差は出ないだろう」という予想は、この段階で既に崩れている。Claude 22ノード、Codex 16ノード、Gemini 11ノード。同じ6行の指示を読んだだけで、2倍の差がついた。

しかも差はノード数だけではない。Claudeは自由に9種のtype（molecule, theory, analysis, context等）を発明し、エッジには「が触媒」「を支持」「の性質」といった日本語動詞句を使った。type体系もrelation体系も、自分で作り上げている。一方Codexは、Rulesが存在しない段階1で、段階2のRulesに定義する7種のtype体系とほぼ同じ語彙を使った。entity, concept, process, property, method, condition, problemだ。relationも8種中7種を使っている。さらに「概要把握」コメントをYAML冒頭に自発的に記載した——これは段階3で導入するSKILL.md Step 1の出力要件と一致する。SKILL.mdは存在しないのに。

つまり、制約を何も入れていない段階で、三ツールは根本的に異なる振る舞いをしている。Claudeは「既存の慣習に縛られずに構造化する」、Codexは「訓練データから内在化した標準語彙に従う」、Geminiは「少数の核心概念に凝縮する」。この傾向は段階2以降で制約を足しても覆らない——推移表の最終行（Claude +6、Codex +1、Gemini −4）が示すように、制約はモデルの基礎的な傾向の上で作用するものであり、傾向そのものを変えるものではない。

#### 確率的制御の効果（段階1→2→3）

段階2でRules（type 7種・relation 8種の許可リスト）を追加し、段階3でSKILL.md（5ステップの手順書）を追加した。いずれもテキストとしてコンテキストに注入される確率的制御だ。冒頭の予想——「制約を読めば出力の形式と方向性は揃うはず」——が正しければ、段階2で三ツールの出力は収束に向かうはずだ。

結果は逆だった。同じRulesを追加して、三ツールに異なることが起きた。Claudeはノードが+5増えた——type定義を「これも探せ」という探索のガイドとして読み、methodやproblemに該当するノードを積極的に見つけに行った。Codexは+2の微増——段階1で既にRulesと同じ語彙を使っていたため、Rulesは「既に知っていることの確認」として作用し、出力をほとんど変えなかった。Geminiはノードが−2に減った——Rulesを「制限」として読み、段階1にあったノードの一部を落とした。一方で、段階1では一度も使わなかったcausesを段階2で2件使うようになった。Rulesの causes: AがBを引き起こす という定義が、因果関係の認識を「教えた」。つまりGeminiに対してRulesは、ノードを減らす制限としてもrelation語彙を増やす教育としても同時に作用した。

Rulesは三ツールの出力を収束させるのではなく、モデルの傾向に応じて異なる方向に作用した。「同じ指示を読める三つのモデル」は同じ指示を「同じように読む」わけではない。

SKILL.mdの追加（段階3）では、さらに興味深いパターンが現れた。Geminiは段階2でRulesにmethod/problemの定義を読んでも一度も使わなかった（type 5/7のまま）。しかし段階3でSKILL.md Step 2の「以下の優先順で探す: …手法…課題・障害」を読んだとき、状況が変わった。初めて fitness_landscape_analysis (method) と small_size_complexity_tradeoff (problem) が出現し、type 7/7を達成した。語彙の定義（Rules）は効かなかったが、探索の指示（Skills）は効いた。 Codexも同様で、Rulesでは使わなかったcomparesとderivesを段階3で初めて使い、relation 8/8を達成した。「この語彙を使え」と書くよりも「この観点で探せ」と書く方が、モデルの行動を変える力が強い。

段階3は、CodexとGeminiの両方で語彙多様性のピークになった——Codex relation 8/8、Gemini type 7/7。確率的制御だけの状態（Hooksなし）が、語彙の多様性を最大化する段階だった。

#### 決定論的制御の効果（段階3→4）

段階4でvalidate_yaml.sh（9項目の整合性チェック）をStop Hookとして追加した。第7章では、Hooksの追加が段階3→4の質的な変化——確率的制御から決定論的制御への移行——をもたらした。同じ変化が、Codex/Geminiでも同様に起きるだろうか。

同じスクリプトが、三ツールに対して異なる行動変容を引き起こした。

Claudeでは、validate_yaml.shが孤立ノードを検出し、修正を促した。ノード+1・エッジ+2で増え、語彙多様性も8/8・7/7を維持した。Hooksは「品質向上の刺激」として作用した。第7章の段階4と同じパターンだ。

Codex/Geminiでは逆のことが起きた。Codexは段階3で達成したrelation 8/8が段階4で6/8に後退し、containsとderivesが消えた。Geminiは段階3で達成したtype 7/7が6/7に後退し、methodが消えた。段階2でRulesが「教えた」causesも、段階3では1件生存していたが段階4で0件に戻った。validate_yaml.shの存在がモデルの行動を保守的にさせ、「安全な」語彙に収束させた——Hooksが「行動の萎縮」を引き起こした。

同じ決定論的制御が、モデルの傾向によって「改善」にも「萎縮」にもなる。Claudeにとってvalidate_yaml.shは「直すべき箇所を教えてくれる存在」であり、Codex/Geminiにとっては「失敗しないように慎重にさせる存在」だった。これは第2章で述べた確率的制御と決定論的制御の相互作用の実例であり、決定論的制御の設計がモデルの傾向を考慮する必要があることを示している。

validate_yaml.sh自体にも二つの構造的限界が見つかった。第一に、YAMLパーサを使わずgrepでパターン検索する実装のため、YAMLの等価な書式バリエーションで偽陽性が発生した（書式依存性）。第二に、ノード数の下限が「1個以上」のため、Geminiの7ノードでも全項目PASSした——形式的な整合性は検証できるが、概念的な十分性は検証できない（品質下限の不在）。

9.5 移植テストが示したこと

9.4では段階1から段階4まで制約を積み上げ、三ツールに何が起きたかを観察した。ここでは、その結果を9.2の枠組み（傾向・癖・感受性）と9.3の三層モデルで整理し、移植テスト全体の知見をまとめる。

機能等価性 — 三ツールとも段階4で同じタスクを完了し、validate_yaml.shをPASSした。「1本の論文から概念ネットワークを構築してYAMLに出力する」というタスクは、モデルとツールを変えても達成できた。ドキュメント層のファイル（SKILL.md、Rules）が自然言語で書かれているため、どのモデルでも「読める」。ただし、「読める」と「同じ水準で実行する」は異なる。ノード数に4倍の差があることが示すように、機能等価性とは「完了するかどうか」であって「同じ結果になるかどうか」ではない。

非機能比較 — 出力の質の差異は、9.2で整理した3つの性質に帰属でき、しかも段階別の推移を見ることで各性質の起源が特定できた。

解釈の傾向（一貫した方向性）として、粒度の勾配が最も顕著だった。Claude（28ノード、網羅的）、Codex（17ノード、主要ストーリーライン）、Gemini（7ノード、要旨レベル）。9.4で示したように、この勾配は段階1（制約なし）の時点で既に存在しており（22 > 16 > 11）、制約を足しても方向は変わらなかった。つまり粒度の傾向はモデルの基礎特性であり、Harnessの設計で覆すものではない。ネットワーク構造の差（メッシュ→線形→スター）も段階1から一貫している。

解釈の癖（予測しにくい反応）として、段階別の推移が予測困難な振る舞いを複数明らかにした。Codexが段階1でRulesの語彙を「デフォルト」として持っていたこと。Geminiのcausesが段階2で出現し段階4で消えたこと。Claudeがファイル名のドットをアンダースコアに変換したこと。いずれも事前に予測できず、実行して初めて判明した。特にGeminiのcausesの軌跡（0→2→1→0）は、同じ制約が段階によって異なる効果を持つことを示している。9.2で「癖は実行して初めて判明する」と述べたが、段階別の追跡によってその癖がどの段階で生まれ、どの段階で消えるかまで特定できた。

感受性の差として、同じテキスト指示に対する反応がモデルごとに質的に異なることが確認された。9.4で示した最も象徴的な例は、Rules（語彙の定義）とSkills（探索の指示）への反応の違いだ。Geminiは「type: method — 手法・技術・実験手順」というRulesの定義を読んでもmethodを使わなかったが、SKILL.mdの「以下の優先順で探す: …手法…」を読んで初めて使った。「この語彙を使え」と書くよりも「この観点で探せ」と書く方が効く——この感受性の差は、Harnessのファイルをどう書くかの設計判断に直接影響する。

資産の再利用性 — 9.3の三層モデルに沿って移植コストを整理する。

ドキュメント層（SKILL.md 54行、Rules 30行）は内容の書き換えゼロで三ツールに渡せた。自然言語で書かれた指示のポータビリティは実証された。ただし「渡せる」と「同じように効く」は別の問題だ。9.4が示したように、同じRulesがClaudeには探索ガイド、Codexにはデフォルト確認、Geminiには制限として作用する。ドキュメント層のポータビリティは「ファイルの互換性」であって「効果の互換性」ではない。

実行環境層の変換はリネームとパス変更のみだった。CLAUDE.md → AGENTS.md / GEMINI.mdへの転記。.claude/skills/ → .agents/skills/ / .gemini/skills/ へのパス変更。RulesのAGENTS.md / GEMINI.mdへの統合。SKILL.md標準フォーマットの恩恵で、Skillsファイル自体の書き換えは不要だった。9.3で整理した標準化のファクトは、実地で確認された。

手順保証層はツール間で最も差が大きかった。Claude CodeのStop Hookはvalidate_yaml.shの失敗時に実行をブロックし、修正を強制する。Gemini CLIのAfterAgent hookもほぼ同等の機能を提供した。Codex CLIのagent-stop hookはexperimental段階であり、今回はPASSしたため差が顕在化しなかったが、失敗時のブロック強制力は未検証のままだ。加えて9.4が示したように、同じHooksがモデルによって異なる行動変容を引き起こすため、手順保証層の移植は「スクリプトが動くか」だけでなく「モデルがどう反応するか」まで含めて検証する必要がある。

9.6 実用的な指針

9.4と9.5の結果から、Harnessの移植に際して実用的な指針が導かれる。移植テストの最大の教訓は、「同じファイルを渡せば同じように動く」という直感が成り立たないことだった。ファイルの互換性と効果の互換性は別の問題であり、後者はモデルの傾向を考慮して初めて対処できる。以下、三層モデルに沿って指針を整理する。

ドキュメント層は最初からポータブルに設計する。 proposal.mdやspec.mdにツール固有の記法を混ぜない。自然言語で完結させる。これは移植のためだけでなく、人間が読んで理解できるためでもある。ドキュメント層のファイルは内容の書き換えゼロで三ツールに渡せた——この互換性は9.4で実証された。ただし9.5で述べたように、同じRulesがモデルによって探索ガイド、デフォルト確認、制限として異なる機能を持つ。「渡せる」ことと「同じように効く」ことは区別して考える必要がある。

確率的制御は「語彙の定義」より「行動の指示」で書く。 9.4の段階2→3で最も明確に現れたパターンだ。Rulesに「type: method — 手法・技術・実験手順」と定義してもGeminiはmethodを使わなかったが、SKILL.mdに「以下の優先順で探す: …手法…」と書いたら使った。モデル間のポータビリティを高めたければ、「この語彙を使え」ではなく「この観点で探せ」と書く方が効果的だ。

実行環境層はオープン標準に沿って設計する。 AGENTS.mdとSKILL.mdの標準フォーマットに沿って書けば、ツール間の変換がほぼ不要になる。ツール固有の形式（.claude/rules/ や .cursor/rules/ 等）が必要な部分は、共通の内容からのコピーで対処する。

手順保証層はモデルの傾向を考慮して設計する。 9.4で観察された最も驚くべき結果は、同じvalidate_yaml.shがClaudeには品質向上の刺激、Codex/Geminiには行動の萎縮として作用したことだ。Hooksの設計は「何をチェックするか」だけでなく、「そのチェックがモデルの行動をどう変えるか」まで考慮する必要がある。特に、段階3で達成された語彙多様性が段階4で後退したパターンは、Hooksの存在がモデルを保守的にさせうることを示している。チェック項目を増やせば品質が上がるとは限らない。

解釈の揺らぎはテストで対処する。 9.4の冒頭で述べたように、筆者自身「大きな差は出ないだろう」と予想していた。この予想は完全に外れた。9.2で述べたモデル間の傾向・癖・感受性の差異は、事前に完全には予測できない。まずそのまま渡して実行し、問題が出た箇所だけを修正する反復的なアプローチが現実的だ。9.4で行ったように段階を分けて実行すれば、差異の発生源を特定しやすくなる。

ツールに合わせてHarnessを設計するのではなく、Harnessの要件に合わせてツールを選ぶ。 ツール選択で最初に問うべきは「手順の遵守にどの粒度の制御が必要か」だ。特定のファイルへの書き込みブロックや完了前の条件チェックが必要なら、アプリケーションレベルのHooksが充実したツールを選ぶ。ディレクトリレベルのアクセス制御で十分なら、OSレベルのサンドボックスでも対応できる。成果物さえできればよいなら、ドキュメント層はどのツールでもそのまま動くので、好みや他の条件（コンテキストサイズ、コストなど）で選んで構わない。

以下の表は、移植テストの結果に基づく用途別の整理だ。「推奨」ではなく「観察された特性」として読んでほしい——各ツールは急速に進化しており、この表は2026年3月時点のスナップショットに過ぎない。

粒度の差は「良い・悪い」ではなく用途の問題だ。論文の要旨を構造化したいならGeminiの凝縮で十分かもしれない。概念間の詳細な関係を分析したいならClaudeの網羅が必要になる。重要なのは、この粒度の差がモデルの暗黙の傾向として存在することを知り、必要であればproposal.mdやRulesで明示的に制御する——「ノードは15個以上抽出すること」「5段階すべてから候補を探すこと」——ことだ。確率的制御の揺らぎをドキュメント層で補正するこのアプローチは、5.6で述べた「困ったら入れる」の原則そのものだ。

実用上のポイント: 移植テストから得られた最も重要な教訓は「同じファイルが同じように効くとは限らない」だ。Harnessを別のモデル・ツールに持っていくとき、ファイルの変換コスト（リネーム、パス変更）は低い。しかし効果の検証コスト——同じRulesが探索ガイドとして効くのか制限として効くのか、同じHooksが品質を上げるのか行動を萎縮させるのか——は予測できず、実行して初めて分かる。まず段階1（プロジェクト指示のみ）で素の傾向を確認し、段階的に制約を足しながら効果を検証する。問題が出た箇所だけを修正する。9.4で行った段階別の比較実験は、この検証プロセスの一つの型だ。