AI・テクノロジー

196回のツール呼び出しでMD5を完走する——LLMの「長距離状態追跡」はどこまで可能なのか

docker agent

• 15 min read
Share

はじめに：なぜ「長い手順」はLLMの弱点なのか

大規模言語モデル（LLM）は、1ステップの処理だけを見れば驚くほど正確です。しかし、互いに依存し合う多数のステップを連結して実行する「長い手順」では状況が一変します。各ステップの誤差が次のステップへと伝播していく「誤差のカスケード」が発生するためです。単発の質問応答では見えないこの問題は、ツールを連続呼び出しするエージェント型AIに固有の課題といえます。

この壁を定量的に示したのが「確率の壁」です。1ステップの成功確率がpのとき、nステップすべてが成功する確率はp^nで表されます。1ステップ99%（p=0.99）の精度でも、196ステップ連結すれば0.99^196≒0.14、つまり成功確率は約14%まで低下します。さらに精度が95%（p=0.95）なら0.95^196≒4×10^-5とほぼゼロです。1ステップずつはほぼ完璧なモデルでも、長い手順ではどこかで必ず失敗する——この「p^nの壁」こそが、長い手順をLLMの弱点にしている根本原因です。

さらにSinha et al.（2025）は、モデルが自分自身の過去の誤りに「自己条件付け」して、さらに誤りやすくなることを指摘しています。一度間違った状態をコンテキストに取り込むと、その誤った状態を前提に次の推論を行うため、誤差が雪だるま式に増幅されるのです。

既存のエージェントベンチマークは、この問題を十分に測定できていません。終端での成否は判定できても、「指示の解釈ミス」と「状態追跡の失敗」が混在して誤りの原因を特定できず、正しい中間状態と照合する対照群もありません。モデルが幻覚した最終回答でごまかせる余地が残されている点も問題です。

そこで本研究は、1つの問いに絞って検証します——LLMは正確な中間状態を、多数のツール呼び出しをまたいで保持し続けられるのか。この問いに答えるため、解釈の余地がなく・ビット単位で正解を照合でき・ステップ数を自由に伸ばせる「テスト問題」として、MD5の計算が採用されました。次のグラフは、ステップ数nに対する成功率p^nの減衰を示したものです。

xychart-beta
    title "ステップ数nに対する成功率 p^n の減衰"
    x-axis "ステップ数 n" [1, 50, 100, 150, 196]
    y-axis "成功率" 0 --> 1
    line "p=0.99" [1.0, 0.61, 0.37, 0.22, 0.14]
    line "p=0.95" [1.0, 0.08, 0.01, 0.0004, 0.00004]

MD5が「完璧なテスト問題」である理由

MD5とは何か（暗号学的ハッシュ関数の基礎）

MD5（Message-Digest Algorithm 5）は、1992年にRonald RivestがRFC 1321として定義した、128ビットの暗号学的ハッシュ関数です。任意の長さの入力を512ビットのブロックに分割し、4つの32ビット語（a, b, c, d）を64ラウンドにわたって撹拌することで、固定長のダイジェストを出力します。各ラウンドは、F/G/H/Iと呼ばれる非線形関数、mod 2³²での加算、左方向へのビット回転を組み合わせた「加算-回転-XOR」構造になっています。

このアルゴリズム最大の特徴はアバランシェ効果です。入力を1ビットだけ変えると出力が大きく変化するように設計されているため、結果の「推測」や「補間」が事実上不可能で、正解を得るには計算を1ステップずつ追いかけるしかありません。なお、MD5自体は2004年に衝突耐性が破られており、現在はセキュリティ用途に推奨されません（CRYPTRECもSHA-256以上を推奨）。本研究ではハッシュとしての安全性ではなく、あくまで「正確な逐次計算」を測るテストベッドとして利用しています。

なぜハッシュ計算が「LLMの弱点の直撃」なのか

MD5計算は、LLMエージェントの弱点をこれ以上なく突く題材です。まず解釈が自明である点が重要です。入力や手順に曖昧さが一切ないため、失敗の原因をすべて「簿記（bookkeeping）」つまり中間状態の保持ミスに帰着できます。

さらに、32ビット加算の桁上がりやビット回転など「大きな数の正確な算術」は、LLMが最も苦手とする領域の代表格です（Lee et al. 2024）。にもかかわらず、出力はビット単位で正解と照合できるため、幻覚や記憶で答えをごまかす余地がありません。加えて、ブロックを増やすだけで要求されるステップ数を無限に伸ばせる点が、この問題を「困難度のダイヤル」として理想的なものにしています。実行すべき依存ステップ数を任意に調整できるため、状態追跡の限界を正確に測れるのです。

実験設計：196回の従属的ツール呼び出し

この実験は、7つのプリミティブツール（基本演算を1つずつ担う関数群）と、それらを呼び出す「ドライバーLLM」で構成されます。プリミティブは、パディングと16語への分割を行うprepare_message、初期状態を返すinitial_state、ラウンド定数を取り出すget_step_constants、非線形関数を計算するcompute_f_and_g、32ビット語を撹拌するmix_step、状態を加算するadd_states、16進文字列へ変換するto_hex_digestの7つです。ドライバーは4つの32ビット語(a,b,c,d)を自身のコンテキスト内に保持しながら、ツールを正しい順序で呼び続けます。

正規の完了は「セットアップ2回＋64ラウンド×3回＋ファイナライズ2回」の計196回の呼び出しで、誤って172回で終了した場合は即座に失敗と判定されます。入力は55バイト以下の単一512ビットブロックに限定し、既知ベクトル"abc"などメモ化でごまかせる入力を除外して評価します。

sequenceDiagram
    participant D as ドライバーLLM
    participant T as プリミティブツール
    D->>T: prepare_message / initial_state（セットアップ2コール）
    loop 64ラウンド（各3コール）
        D->>T: get_step_constants → compute_f_and_g → mix_step
        T-->>D: 更新後の(a,b,c,d)
    end
    D->>T: add_states / to_hex_digest（ファイナライズ2コール）
    T-->>D: 128ビットダイジェスト

正解判定はビット単位の照合で行われます。RFC 1321準拠のスクラッチ実装を用意し、エージェントの全コールを「グリーン/レッドトレース」として1対1で突き合わせるのが基本設計です。さらに最初の発散点を実アルゴリズムに注入し、「この1回だけスリップしていれば最終ダイジェストはXXになるはず」という反実仮想ダイジェストを生成して、誤りの伝播経路を分離します。

評価指標 内容
成功率 正解ダイジェストを返したランの割合
最初の発散ラウンド トレースが赤に変わる最初の位置
コール数乖離 スキップ・重複・早期停止の検出
演算別パス率 各プリミティブ演算が正しく計算できた割合

モデルにはOpenAIのオープンウェイトMoE（Mixture of Experts、専門化された複数の小規模ネットワークを入力に応じて切り替える構成）であるgpt-oss-120bを使用します。総パラメータ約117Bに対してトークンごとに活性化するのは約5.5Bで、エキスパート重みはMXFP4（約4.25bit）量子化されています。ドライバーはtemperature 0・短い固定システムプロンプト・コンテキストキャッシュ有効で動作させますが、temperature 0でも量子化サービス上ではビット単位の決定論性は保証されないため、サービスの経路（エンドポイント）も実験セルの一部として記録し、各セルを分布として扱ってNを報告しています。

結果1：ドライバー単体でも「完了したラン」の多数派で完走

まず確認すべき事実は、最もシンプルな構成（ドライバーが自分のコンテキスト内で状態を保持し、計算は正しい実装のツールに委ねる）でも、196回のツール呼び出しを完走できることです。gpt-oss-120bは総パラメータ約117B・活性パラメータ約5.5BのMoE（Mixture of Experts、タスクに応じて専門化された経路を選択するモデル構造）ですが、4つの32ビット語(a,b,c,d)を全コールにわたって保持し、ダイジェストを出力したランの多数派でビット単位の正解に一致しました。1ステップ99%の精度でも196ステップ連結で成功率が約14%に落ちるというp^nの壁は、「文脈を管理すれば」原理的な限界ではないことを示しています。

ただし成績は利用するサービス経路（エンドポイント）で激変します。下表のとおり、Groq系は22ランすべて誤ダイジェストで0%だったのに対し、Fireworks系は34ラン中21ラン成功（62%）でした。さらに両系とも各71ランがダイジェストを一切出力しませんでした（ループ・早期停止・中断による）。

エンドポイント 完了ランの成功率 内訳
Groq系 0%（22ラン中0成功） 誤ダイジェスト22ラン
Fireworks系 62%（34ラン中21成功） 誤ダイジェスト13ラン

重要なのは、同じ重み・同じプロンプト・同じ入力でも経路次第でこの差が生まれることです。つまり難しさは「単一ステップの演算能力」ではなく、「ターンをまたいで状態を維持し続けること」にあります。

失敗ランの分析もこれを裏付けます。各ツール呼び出しを正解と1対1で照合するグリーン/レッドトレースによれば、ツール自体は常に正しいのです。トレースが赤に変わるのは、ドライバーが誤って運んだ32ビット語をツールに渡した瞬間であり、その後はその汚染が以降のラウンドへ伝播し続けます。最も頻度の高い新規エラーは、状態更新時のローテーション適用ミス（(a,d,c,b)←(d,c,b,new_b)）です。

結果2：算術オラクルを外す（ドライバー＋ワーカーの2エージェント構成）

結果1の構成は、計算部分を正しい実装のツールに委ねていました。つまり加算・XOR・ビット回転などの「算術」は、事実上オラクル（常に正解を返す外部装置）に依存していました。ここからその算術オラクルを剥がし、すべてのプリミティブをLLM自身に置き換えるのが2番目の実験です。

すべてのプリミティブをLLMに置き換える

7つのプリミティブ（prepare_message, initial_state, get_step_constants, compute_f_and_g, mix_step, add_states, to_hex_digest）の一つひとつを、thinking対応の高速エンドポイントで動く「ステートレスなワーカーLLM」が単発で計算します。ワーカーも同じgpt-oss-120bですが、状態は一切持ちません。temperature 0.7で3サンプルを採取し、多数決で決まった値をドライバーへ返します（同数なら追加ラウンド）。ワーカーのコンテキストは毎回破棄され、状態を保持するのはドライバーだけです。CPU実装は計測・検証用の「双子」としてのみ存在し、値を供給しない——つまり完全にスクラッチでの計算です。

sequenceDiagram
    participant D as ドライバーLLM（状態保持）
    participant W as ワーカーLLM（ステートレス）
    Note over D: (a,b,c,d)を保持
    loop 各ラウンド
        D->>W: プリミティブ計算を依頼（3サンプル）
        W-->>D: 多数決値を返す（同数時は追加）
    end
    D-->>D: ローテーションで状態更新

ワーカーの弱点：modular wrap-around（法の剰余ミス）

ワーカーの特徴的なエラーは、modular wrap-around（法の剰余ミス）です。MD5の加算はmod 2^32（32ビットを超えたら剰余を取る）で行われますが、ワーカーは正しい未簡約の和まで推論できているのに、2^32を引く回数を誤ります（1回引くべきところを2回引く、など）。ただし推論途中の大きさ比較で自力修正することも多く、残りは3サンプルの多数決が除去します。ワーカーの算術は確率的で自己限定的な誤りであり、多数決でほぼ消せるのです。

ここで注目すべきは、全プリミティブを置換しても失敗の主因がワーカーの算術ではないことです。ワーカーの演算をすべて現場で正しい値に修正しても、ドライバーが状態をスリップさせたランは成功しません。逆に、ドライバーの状態が正しい限り、ワーカーの算術エラーは多数決が吸収します。つまり2つの誤り源は独立であり、より難しいのは状態追跡だという結論が浮かび上がります。

誤り源 性質 対処
ワーカー（算術） 確率的・自己限定的（modular wrap-around） 3サンプル多数決でほぼ除去可能
ドライバー（状態追跡） 決定的に伝播する 多数決では救えないボトルネック

成功を決める2つのレバー（いずれも重みは変えない）

実験の結論は明快です。モデルの重みは一切変えず、コンテキストの持ち方だけで196コールの完走可否が決まります。論文が特定した「レバー」は次の2つです。

レバー1：モデル自身の推論をコンテキストに残す

最大のレバーは、モデルが中間作業を書き出す専用の推論チャンネル（OpenAI Harmony形式の"analysis"チャンネル）を次ターンへフィードバックし続けることです。このチャンネルを剥がすと、同一モデル・同一プロンプト・同一入力でも大半のランが、196ステップ中の最初の12〜24ステップでループか早期終了に陥ります。決定的なのは、同じトークンをバイト単位で可視のassistantメッセージへ移し替えても失敗する点です。推論が「モデルの作業記憶」として存在すること自体が本質であり、トークンが見えているだけでは足りません。これはNye et al.（2022）のスクラッチパッドの発見（中間作業を外部化しないと多段計算はできない）を、サービス時間で再現したものと言えます。加えて、reasoningフィールドを入力にエコーしないスタックはHTTP 400で要求を拒否するため、同じ重みでも経路（プロバイダの配管）次第で挙動が変わります。

レバー2：ワーカーの算術を多数決で信頼化

もう一つは、self-consistency（Wang et al. 2023）を「プリミティブ単位」に適用することです。同一の演算をワーカーに3サンプルさせ、多数決で値を確定します。thinking effortを高く保てばドライバーの状態保持は安定し、ワーカーの剰余算ミス（modular wrap-around）もサンプル数を増やすほど消えていきます。結論は「思考を保持せよ、そして投票せよ（keep the thinking, and vote）」の一言に集約されます。

レバー 対象となる失敗 メカニズム
推論のコンテキスト保持 ドライバーのループ・早期終了（12〜24ステップ以内） analysisチャンネルを作業記憶として毎ターン維持
プリミティブ単位の多数決 ワーカーのmodular wrap-around 3サンプルの自己無矛盾性で確率的誤差を除去 
flowchart LR
    D["ドライバー<br/>（状態を保持）"] -->|プリミティブ呼び出し| W["ワーカー<br/>（3サンプル多数決）"]
    W -->|確定値を返す| D
    D -. "analysisチャンネルを<br/>次ターンへフィードバック" .-> D

失敗の解剖：どこで、なぜ落ちるのか

成功したランと失敗したランは、どこで分かれるのか。実験ではエージェントの全ツール呼び出しを、RFC 1321準拠のスクラッチ実装が生成する正解トレースと1対1で照合し（グリーン/レッドトレース）、最初に正解から外れた「発散点」を特定したうえで、失敗を起源別に分類しています。その結果、失敗の実態は次の3つの起源に整理できます。

失敗の3つの起源（ドライバー／ワーカー／サービス）

失敗の大半を占めるのは、ドライバー（状態保持）由来のミスです。最も頻度が高いのは状態更新のローテーション適用ミスで、MD5の1ラウンドが終わるたびに4つの32ビット語を (a,d,c,b) ← (d,c,b,new_b) の順で入れ替える並べ替えを誤ってしまいます。加えてステップの脱落・重複、196コールで完了すべきところを172コールで早期終了するケースもあります。これらは一度起こると正しい状態へ戻れないため、以降のラウンドすべてを汚染し、最終ダイジェストを狂わせます。状態追跡こそがボトルネックであることを、この分布自体が示しています。

これに対し、ワーカー（算術）由来の失敗はmodular wrap-around（法の剰余ミス）です。32ビット加算の和から2^32を引く回数を誤るエラーで、確率的かつ自己限定的であり、3サンプルの多数決でほぼ除去できます。3つ目はサービス（コンテキスト）由来で、モデルの推論チャンネルを次ターンにエコーしない経路で発生する全滅型の崩壊です。all-or-nothingの性質を持ち、ほぼすべてのランが最初の12〜24ステップ以内にループか早期終了します。

起源 具体例 性質 影響
ドライバー（状態） ローテーション適用ミス、ステップ脱落・重複、196→172早期終了 決定的に伝播 失敗の大半を占めるボトルネック
ワーカー（算術） modular wrap-around（2^32の減算回数ミス） 確率的・自己限定的 多数決でほぼ除去可能
サービス（コンテキスト） reasoningチャンネル未エコー all-or-nothing 12〜24ステップ以内に全滅

ここで鍵になるのが反実仮想注入です。最初の発散点を実アルゴリズムに注入し、「この1回だけスリップしていたら最終ダイジェストはXXになるはず」という反実仮想の値をあらかじめ計算しておきます。これにより、各失敗ランはほぼ例外なく「単一の起源エラー」を持ち、その汚染が以降のラウンドへ伝播して失敗に至ることが確認できました。誤りが複数箇所で同時に起きるのではなく、最初の1スリップが決定的なのです。

flowchart LR
    A["単一の起源エラー<br/>（例: ローテーション適用ミス）"] --> B["汚染された32ビット語を<br/>次ラウンドへ伝播"]
    B --> C["誤ったダイジェスト<br/>（ビット単位で不一致）"]
    A -. "反実仮想注入で<br/>1スリップ時の値を特定" .-> C

「40→48スキップ」という奇妙な指紋

失敗ランにだけ出現する、位置固定の連続スキップがあります。ラウンド40〜47（一部のランでは24〜31）を丸ごと飛ばし、39から48へジャンプして短いブロックでダイジェストを確定させるパターンです。ランダムなスリップなら飛ばす位置はばらつくはずですが、このパターンは一定で、16ラウンド単位のブロックの「後半を丸める」という規則的な挙動を示します。失敗ラン7件のみに出現し、成功ランでは0件という偏りも含め、モデルファミリーの再現可能な指紋（signature）の候補とみなされています。単発の偶然ではなく、モデルの内部処理に由来する再現性のある癖である可能性が高いのです。

この研究が意味すること：LLMは「運転席」に座れるのか

196回の従属的ツール呼び出しを経てMD5の正しいダイジェストを返せたという事実は、LLMエージェントの役割分担に関する前提を塗り替えます。従来、長い手順の「正確さ」はモデルに任せるのではなく、人間か手書きの制御コードが担保するものとされてきました。本研究は、文脈を適切に管理すればLLM自身が中間状態を保持し、最後まで計算を「運転」できることを実証した点に意味があります。

実務への示唆：長距離の「正確さ」が要る仕事

会計・簿記の締め処理、法務・コンプライアンスのワークフロー、調達・照合パイプラインなど、中間状態を逐語保存しなければならない業務は実務に多数存在します。これらは1ステップずつは単純でも、前ステップの結果が必ず次へ引き継がれる点で、本研究のMD5計算と構造が同じです。従来の処方箋は、決定木・ワークフローグラフ・有限状態機械などの「手書きコントローラー」にLLMを閉じ込め、葉タスクだけを任せるというものでした。本研究の答えは、状態保持を外部に追い出すのではなく、推論チャンネルの保持と算術の多数決という文脈設計でLLM自身に運転させることです。

観点 従来の手書きコントローラー 本研究のアプローチ
状態の保持 外部コード（決定木・FSM等）が管理 LLM自身がコンテキスト内で管理
LLMの役割 葉タスク（個別計算）のみ 全体の進行と状態の運転
変更への追従 制御構造の書き換えが必要 重みを変えない文脈設計で対応
検証の容易さ コードのテストに依存 ダイジェストのビット単位照合

次のステップ：自己管理エージェントへ

ドライバー/ワーカー分割は、あくまで同じ重みのモデルを2役に分解した設計です。両方の役割を同一モデルが果たせたのだから、単一エージェントへの統合が自然な次の一手となります。具体的には、コンテキストを自己編集するツール——スクラッチ領域への書き込み・読み戻し・圧縮・不要物の破棄——を与える方向性です。

flowchart LR
    subgraph 現状: 2エージェント分解
        D["ドライバー（状態を保持）"] --> W["ワーカー（算術を計算）"]
        W --> D
    end
    subgraph 次の一手: 単一エージェントへ
        A["自己管理エージェント（状態＋算術＋編集）"]
        M["コンテキスト自己編集<br/>書込・読戻し・圧縮・破棄"]
        A --> M
    end
    現状 --> 次の一手

これはMemGPT（Packer et al., 2023）が提唱した、オペレーティングシステムのメモリ管理に着想を得てコンテキストと外部メモリをページングするアーキテクチャの思想と接続します。本研究の貢献は、その自己管理が「正確な状態を長ホライズンで保持できるか」を、4つの32ビット語という最小構成でビット単位の検証可能なテストベッドにした点にあります。残る課題は、この最小構成から、より大きく雑然とした実世界の分岐ワークフローへの一般化です。

よくある質問

なぜMD5なのですか？衝突耐性は破られているのに。

MD5はハッシュとしての安全性ではなく、「正確な逐次計算」を測る測定器として使っています。アバランシェ効果（入力を1ビット変えると出力が大きく変わる性質）により、ダイジェストは推測や補間が不可能で、正解にたどり着くには1ステップずつ計算するしかありません。しかも結果をビット単位で照合できるため、状態追跡能力だけを純粋に測定できます。MD5の暗号利用が非推奨な点は、この研究の論点とは無関係です。

成功率はどのくらいですか？

現行コーパスでは、ダイジェストを出力して完了したランに限れば多数派が正解です。ただしエンドポイントによって0%（Groq系）から62%（Fireworks系）まで大きく変わり、モデルの推論チャンネル（中間計算を保持する専用の出力領域）を次ターンに維持できる経路かどうかが決定的です。なお、これらの数値は凍結前のコーパスに基づくもので、著者らはN≥20の固定グリッドでの確定を予定しています。

この結果はgpt-oss-120b特有のものですか？

実験はこのモデルを主対象にしていますが、成功を左右した2つのレバー（推論のコンテキスト保持と多数決）はいずれも重みを変更しない「文脈設計」であり、モデル非依存の原則として提示されています。同じモデルでもサービスの経路次第で崩壊する事実は、能力ではなく文脈こそが本質であることの傍証になっています。

実務ではどう使えますか？

長い従属ワークフローをLLMエージェントに任せる際の設計指針として使えます。具体的には、①モデルの推論チャンネルを次ターンに必ずフィードバックする、②壊れやすいプリミティブ演算はLLMの多数決で信頼化する、③状態を持つ「ドライバー」と計算する「ワーカー」を分離する、の3点です。会計・法務・照合系の自動化において「LLMにどこまで運転させるか」を判断する材料になります。

コードやデータは公開されていますか？

現時点ではarXivの論文（6ページ・CC BY 4.0・2026年8月2日投稿）のみで、公開リポジトリは確認できていません。実験の全リクエスト・応答・ツール呼び出し・ワーカーサンプル（推論含む）はJSONLで記録されSQLiteに索引付けされており、再現・分析の土台は整えられています。

まとめ

196回の従属的ツール呼び出しをまたいでMD5（RFC 1321で定義された128ビットのハッシュ関数）を完走できた事実は、長い手順がLLMにとって原理的な壁ではないことを示しています。1ステップ99%の精度でも196ステップ連結すれば成功確率は約14%に落ちる「p^nの壁」は、コンテキストの管理次第で実際に越えられます。活性パラメータ約5.5Bのgpt-oss-120bが、4つの32ビット語(a,b,c,d)を全行程にわたって保持し、正しいダイジェストを返したのはその正の証拠です。

成功を分けたのはモデルの重みではなく文脈の設計でした。ひとつは、モデル自身の推論を専用の推論チャンネルとして次ターンにフィードバックし続けることです（これを剥がすと同一モデル・同一プロンプトでも最初の12〜24ステップ以内に崩壊します）。もうひとつは、ワーカーLLMの3サンプル多数決（self-consistency）で、mod 2^32の剰余算など壊れやすい演算を信頼化することです。言葉にすれば「思考を保持せよ、そして投票せよ」となります。

残る失敗は少数かつ機械的で、その一部は再現可能な指紋を示しています。失敗の大半はドライバーの状態保持ミス（状態更新のローテーション適用ミスなど）が占め、ワーカー側の算術ミスは多数決でほぼ除去でき、推論チャンネルを維持できないサービス経路では全滅的な崩壊が起きます。失敗ランにだけ出現する「ラウンド40〜47を丸ごとスキップして39から48へジャンプする」挙動は、モデルファミリー固有の規則的な指紋として観測されました。

この結果は、「長く正確な処理は手書きのコントローラー（決定木やワークフローグラフ）に追い出す」という従来の常識への反証であり、いつか自らのコンテキストを読み書き・圧縮して管理するエージェント（MemGPT型の自己管理）に向けた第一歩となります。会計・法務・照合系など中間状態の逐語保存が必要な実務で、LLMにどこまで「運転席」を任せられるかを判断する材料になるでしょう。

参考資料

関連記事