この記事は2026年10月時点の前提で書いています。実験は2026年10月3日に、Claude Codeの claude -p とClaude Sonnet 5.5（claude-sonnet-5-5）で行いました。モデルが変われば、実験の数値も構成の選び方も変わります。

先に結論だけ

LLMの推論は同じプロンプトを、設定を読み込まない環境に渡しても結論がブレます。この記事ではブレを、ユーザーが頭の中に持っている前提や判断基準（メンタルモデル）が、エージェントと共有されていない問題として捉えます。

繰り返し実行する作業で、ブレが許容されないワークフローの場合は、判断基準を推論ブロックの構成で表現してエージェントに渡します。互いの結果に依存しない小さな推論に分割し、結果をコードで合算する構成です。構成を検討する過程で、言語化できていなかった判断基準が明確になります。基準が構成に書き込まれるぶん、私のスキルではブレが小さくなりました。

ただし、次のいずれかに当たる場合は巨大な1回の推論のままエージェントに任せ、ブレを受け入れるほうがよい結果になります。

繰り返しがない、一度だけの作業
問題の各部分が互いに依存していて分割できない
明確なワークフローを把握しておらず、共有するメンタルモデルがまだない

はじめに

Claude Codeのスキルを作っていて、同じ入力なのに実行のたびに結論が変わる、という問題に何度もぶつかりました。この記事では、ブレる推論タスクを、再現性のある処理へどう変換するかという試行錯誤を紹介します。

振り返ると、ブレの原因は問題の複雑さよりも、私とエージェントの間でメンタルモデルを共有できていなかったことにあったと考えています。作業に対する前提や判断基準は私の頭の中にありましたが、言語化できておらず、エージェントには渡っていませんでした。

その基準を書き出していく過程で、スキルの構造は3つの形をたどりました。

対象読者はLLMを組み込んだワークフロー・スキル・エージェントを設計している方です。学術的な厳密さはありません。LLMを使った作業を組み立てる、というエンジニアリングの視点で役立つ経験則としてまとめます。

同じプロンプトでも結論がブレる

出力がそろわないことは先行研究でも報告されています。

Atilらは決定的になるはずの設定でも、5モデル・8タスクで精度が最大15%変動したと報告しています¹
Thinking Machines Labは、temperature 0でも出力がそろわない主な理由を、サーバーの負荷でバッチサイズが変わることだと説明しています。同社の検証では同じプロンプトを1000回実行して80通りの出力が得られました²

後者はQwenでの検証で、Claudeの内部で同じ仕組みが働いているかはわかりません。それでもこの記事では、API経由で使うLLMの出力は再現しないものとして話を進めます。

ブレやすい問題の経験則

ブレが大きくなるのは、判断基準がユーザーとエージェントの間で共有できていないときでした。これは今回の試行錯誤から得た経験則です。

実験: ブレない質問とブレる質問

同じプロンプトをまっさらなインスタンスへ繰り返し渡し、回答の分布を数えました。

ここに載せるのは、2026年10月3日時点の観測の記録です。モデルやハーネスの更新で分布は変わるので、数字ではなく、質問の種類による差の出方を見てください。

実験の条件

claude -p を、手元の環境を読み込まない状態で起動しました。何も指定しないと、ユーザーやプロジェクトのCLAUDE.md・メモリ・MCP・スキルが読み込まれます。そのまま試すと、手元の環境に由来する回答が混ざってしまいました。

切り離したのは次のものです。

ユーザー・プロジェクト・ローカルの設定
MCPサーバー・スキル・ツール
セッションの保存
既定のシステムプロンプト（1行の短いものに置き換え）

モデルIDは固定しています。この状態で「受け取っている指示・メモリ・規約」を列挙させ、環境情報以外が残っていないことを確かめてから実験しました。

対照: 計算で決まる問題はブレない

条件がそろっていて計算で答えが決まる問題を、5つ用意しました。「数字だけを答えよ」と指定して、10回ずつ聞いています。

質問	回答
時速4kmで1.2km歩くと何分かかるか	18（10回）
時速60kmで45km走ると何分かかるか	45（10回）
90分の動画を1.5倍速で見ると何分かかるか	60（10回）
1ページ2分の速さで34ページ読むと何分かかるか	68（10回）
1分あたり80字の速さで2000字を入力すると何分かかるか	25（10回）

5つを1つの文章にまとめ、合計を聞く質問にしても、20回すべてが216でした。途中の式を書く回と書かない回はありましたが、値は割れていません。

計算で答えが決まる問題は、内部で機械的な処理に還元できるのでブレなかったと私は解釈しています。推論が必要な問題は変わらずブレます。

根拠を渡していない質問は結論が割れる

次に、判断の材料をモデルに渡していない質問を20回ずつ聞きました。どれも「『はい』か『いいえ』の一語だけを答えよ」と指定しています。

質問	はい	いいえ	回答しない
私はいま1から10までの整数を1つ思い浮かべている。その数は偶数か	11	9	0
コインを1回投げた。表が出たか	2	18	0
この新規事業に投資すべきか	0	10	10
明日の午後、私の住む町で雨は降るか	0	8	12

割れ方はそろっていません。半々に割れる質問もあれば、片方に偏る質問や、答える回と「判断できない」と断る回に分かれる質問もあります。

前提がすべて文章に書かれている質問と、判断の根拠が共有されていない質問とで、ブレ方が違いました。

推論の組み立て方3パターン

推論ブロックはLLMに1つの判断を任せるひとまとまりの推論を指す、この記事での呼び名です。

図の角丸は推論、四角は入出力と機械的な処理です。

1. 巨大な推論ブロック

入力から出力までを1回の推論で済ませる構成です。入力のわずかな違いやプロンプトの書き換えで出力が変わります。どの変更が出力を変えたのかを追えないので、デバッグも難しくなります。私のスキルでは、3つの中で再現性は最低でした。

2. 直列推論ブロック

入出力の形式を固定して、推論を多段に分ける構成です。段ごとにテストできるので、どの変更が出力の変化につながったかを検証しやすくなります。

ただし直列なので、先頭の推論のブレが後ろの段のブレを引き起こす構造は残ります。

3. 並列推論 + 機械的合算

推論を相互に依存しない形に置き換え、出力をコードで合算する構成です。この形に分割する過程で判断基準が明確になります。

この構成では、何を切り出してどう合算するかという判断基準がプロンプトの文章に現れません。ブロックの構成がその基準になります。次の3つの決定にユーザーの基準が入っています。

何を1つの推論ブロックとして切り出すか
各ブロックにどの入力だけを渡すか
ブロックの出力をどの計算で合算するか

たとえば文章のレビューを、誤字の判定・用語の統一の判定・章立ての判定の3ブロックに分割し、指摘の件数をコードで数える構成にしたとします。「この3つの観点で見る」「観点同士は互いに影響させない」「件数で評価する」という基準は、どのブロックのプロンプトにも書かれていません。

同じ基準を巨大な推論ブロックに渡すには、文章で指示するしかありません。指示をどう解釈し、どこまで従うかは、実行のたびに推論が決めます。

これは私がスキルをデバッグしたときの経験とも合います。巨大な推論ブロックで判断基準を1つ調整すると、エージェントがほかの基準で埋め合わせて、全体の結論が変わらないことが何度もありました。逆に、些細な変更が全体では大きな差になることもありました。

一方、構成で表現した基準は毎回同じ形で適用されます。各ブロックが担当の入力だけを受け取り、合算をコードが行うためです。

推論を機械的な処理へ置き換える

パターン2と3では推論ブロックの一部を機械的な処理に置き換えることでもブレを抑えられます。

タスクの分割は推論でしか実現できない処理と機械的に再現できる処理を、設計者が仕分ける作業とも言えます。仕分けるには、頭の中にあった判断の手順を言語化しなければなりません。

分割の利点は決定的な単位への置き換え

実験では、計算で答えが決まる質問は1回もブレませんでした。分割の狙いは各部分をこのように答えが1つに決まる単位（決定的な単位）へ置き換えることです。

評価の分野には同じ方向の実証があります。CheckEvalは、1〜5などの段階評価を「はい・いいえ」のチェックリストに分割する手法です。論文は評価モデル間の一致度が平均0.45改善し、評価モデルを替えたときのばらつきも減ったと報告しています³。

Anthropicの公式ドキュメントも、出力の一貫性を高める方法の1つにタスクの分割を挙げています⁴。

Break down complex tasks into smaller, consistent subtasks. Each subtask gets Claude's full attention, reducing inconsistency errors across scaled workflows.

複雑なタスクを、より小さく一貫したサブタスクに分割します。各サブタスクにClaudeの注意がすべて向けられるので、規模を拡大したワークフロー全体で一貫性の誤りが減ります。（筆者訳）

並列にする条件は推論同士の独立

依存を残したまま並列にすると、ブロック同士の出力が食い違います。

Cognitionは、互いの作業が見えないサブエージェントの成果は食い違うと述べています。同社はこうした失敗を避ける原則を2つ挙げており、1つ目がエージェントの全トレースの共有です⁵
LiuとLiは、文脈上関連する下位タスクを独立した文脈で実行すると、情報が欠けて冗長な操作や実行の失敗につながりうると指摘しています⁶

分割できない場合はパターン3の前提が成り立たないので、パターン1を選んでブレを受け入れます。ほかの部分との関係で答えが決まる問題は、切り離すとその関係を読み取れなくなるからです。

直列では不確実な推論を上流に置かない

パターン2の利点はブロックを単独で再テストでき、反復的に改善できることです。

弱点は波及です。不確実性の大きい推論を上流に置くと、そのブレが下流へ伝わります。全体のブレは巨大な推論ブロックと変わらなくなってしまいます。

Sinhaらは、手順が長くなるほど1ステップあたりの精度が下がることを報告しています。モデル自身の過去の誤りがコンテキストに残っていると、後の段も誤りやすくなるそうです。後の段が誤りやすくなる傾向はモデルを大きくするだけでは減らなかった、とも述べています⁷。

不確実性の大きい推論の扱い方は2つあります。

できれば並列ブロックとして切り出し、ブレをそのブロックに閉じ込める
上流に置くしかない場合は、その段だけ複数回走らせて集約し、ブレを抑えてから下流へ渡す

巨大な推論を選ぶ場面

すべてのタスクにパターン3が向いているわけではありません。分割はモデルが試行錯誤する余地を削る制約でもあります。

次のいずれかに当たる場合は巨大な推論を選びます。

繰り返しがない、一度だけの作業
問題の各部分が互いに依存していて分割できない
明確なワークフローを把握しておらず、共有するメンタルモデルがまだない

1つ目は分割が向くのは繰り返す作業だという条件の裏返しです。繰り返す作業では成果物を横断的に比較するので、出力の水準をそろえる必要があります。一度だけの作業には横断的な比較がなく、水準をそろえる必要がありません。

2つ目は前述の「推論同士の独立」を満たす形に切り離せない場合です。3つ目は次の2つの項で説明します。

CoTはアドリブの直列推論

フロンティアモデルのCoT（Chain of Thought、段階的な思考）は、直列推論をアドリブで組んでいる、と私は解釈しています。判断材料が学習済みの知識と検索でまかなえる問題なら、推論が発散せずに結論までたどり着けるのでしょう。

ただしアドリブなので、段の境界も受け渡しの形式も固定されません。パターン2のように段ごとにテストすることはできません。

設計図がないなら設計ごと任せる

パターン1ではモデルが推論の過程をその場で組み替え、結論にたどり着くまで試行を続けます。十分に練られたワークフローの設計図を持っていないなら、その設計まで含めてエージェントに任せたほうが、よい結果になります。

Anthropicの「Building effective agents」は、エージェントが向く場面を次のように書いています⁸。

Agents can be used for open-ended problems where it’s difficult or impossible to predict the required number of steps, and where you can’t hardcode a fixed path.

エージェントは、必要なステップ数の予測が難しいか不可能で、固定の経路をハードコードできない、オープンエンドな問題に使えます。（筆者訳）

同じ記事は自律性の代償として、コストの増加と誤りが積み重なる可能性も挙げています。

分割が不要になる例もあります。Anthropicの別の記事は、Opus 4.6の改善を理由に、作業を区切るsprintという構造をハーネスから外した事例を紹介しています⁹。この記事は次のように述べています。

… every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions are worth stress testing …

…ハーネスのどの部品にも、モデルが単独ではできないことについての仮定が組み込まれており、その仮定は負荷をかけて検証する価値があります…（筆者訳）

まとめ

判断基準は推論ブロックの構成で表現してエージェントに渡せます。

パターン1（巨大な推論ブロック）をとる利点は次のとおりです。

ワークフローの設計まで含めてエージェントに任せられる
モデルが推論の過程をその場で組み替え、結論にたどり着くまで試行を続けられる
各部分が互いに依存していて分割できない問題も扱える

パターン3（並列推論 + 機械的合算）をとる利点は次のとおりです。

構成を検討する過程で判断基準が明確になる
合算のように機械的に再現できる処理をコードに任せられる
繰り返す作業で出力の水準をそろえられる

どの構成を選ぶかは、モデルの能力をどこまで縛るかという設計判断でもあります。

Atil et al., "Non-Determinism of "Deterministic" LLM Settings". arXiv:2408.04667（v5、2025年4月）。https://arxiv.org/abs/2408.04667 ↩
Thinking Machines Lab, "Defeating Nondeterminism in LLM Inference"（2025年9月10日）。検証モデルはQwen3 235B。同社はバッチサイズに左右されない計算方法へ切り替え、1000回すべてが一致することも示しています。https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/ ↩
Lee et al., "CheckEval: A reliable LLM-as-a-Judge framework for evaluating text generation using checklists", EMNLP 2025. https://arxiv.org/abs/2403.18771 ↩
Anthropic, "Increase output consistency". 2026年10月閲覧。https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/increase-consistency ↩
Cognition, "Don’t Build Multi-Agents"（2025年6月12日）。https://cognition.com/blog/dont-build-multi-agents ↩
Liu & Li, "A Training-free LLM Framework with Interaction between Contextually Related Subtasks in Solving Complex Tasks". arXiv:2503.23053（2025年3月）。https://arxiv.org/abs/2503.23053 ↩
Sinha et al., "The Illusion of Diminishing Returns: Measuring Long Horizon Execution in LLMs". arXiv:2509.09677（2025年9月）。https://arxiv.org/abs/2509.09677 ↩
Anthropic, "Building effective agents"（2024年12月19日公開）。2026年10月閲覧。https://www.anthropic.com/engineering/building-effective-agents ↩
Anthropic, "Harness design for long-running application development"（2026年3月24日）。sprint構造を外した一方で、plannerとevaluatorは残しています。https://www.anthropic.com/engineering/harness-design-long-running-apps ↩