新世代の Claude は他社のツール層で「誰も定義していない欄」を書き足す——本紙は出所と直し方を突き止め、調達で測るべき数字はモデル単体の点数ではなくなったと判断した

本稿の要点

8 月下旬、ある中国語の転載が SNS で出回った。エージェント開発ツールを作る Pi の開発メモによれば、新世代の Claude を Claude Code 以外のツール層につなぐと、`requireUnique`、`matchCase`、`oldText2` のような、相手側に存在しない引数を勝手に生成するという。同じ日、二人の評価者が同じ匿名モデルに同じ問題集を解かせ、58.4% と約 63% という結果を得た。二人とも差の原因を「ツール層の違い」に求めた。本紙は前夜、この二件を一つの判断にまとめた。モデルとツール層は切り離せず、測りにくいだけでなく、乗り換えると実際に性能が落ちる。仕組みは、モデルの事後学習が自社ツールの定義に過剰適合していることだ、という判断である。

本稿はこの判断を分解して検証し直した。結論は三層になる。第一層：出所の並べ方が間違っていた。 三つの引数名は 8 月 22 日の新情報ではない。Pi の作者の一人 Armin Ronacher 氏が 7 月 4 日にブログに書いた文の一部で、本紙は 7 月に収録済みだったが、前夜の判断はこれを引いていなかった。「19 セッション、prefill が 72% から 88% 減った」という数字は、外部の貢献者が 8 月 15 日に出したプルリクエストにあるもので、ボットに「承認済みの貢献者ではない」として自動で閉じられ、一度もマージされていない。第二層：仕組みは前夜の記述より具体的で、しかも直せる。 モデルが書き足す欄は、相手側ツールの命名様式を使いながら、Claude Code のツールの規則を持ち込んでいる。観察した当人の説明は「自社の欄名を覚えた」ではない。「自社のツール層が寛容すぎて、余分な欄は黙って捨てられるので、訓練中に一度も減点されなかった」というものだ。この読みから直接出てくるのは、直し方がツール層の側にあるということだ。厳格モードのスイッチ一つか、未知の欄を除く一行のコードで済む。第三層：4.6 ポイントの差は使えないが、同じ記録にもっと大きな使える数字がある。 問題数 113 での標本誤差はそれ自体が 4.6 ポイントで、二つのスコアの差はちょうど誤差の中に収まる。一方、58.4% の側の公開記録には、113 回の試行のうち 11 回がモデルの 3 回連続のツール呼び出し不返答で中断したと書いてある。モデルとツール層の相性を示すのはこちらの数字で、二人の評価者の差の 2 倍にあたる。

本稿の道筋は六段階ある。

① まず出所を正す。二本の線は、7 月の同じブログ記事と、マージされなかった一本のプルリクエストに行き着く。

② 「引数の発明」で実際に何が起きたかを説明する。ツール定義とは何か、二社の編集ツールの形、書き足された欄がなぜその形になるのか。

③ ベンダー自身の説明を見る。一社は「モデルをこのツールで訓練した」と文書に書いて数字まで出し、もう一社の文書にはその一文がない。

④ 4.6 ポイントを外し、同じ記録の 11 回に差し替える。

⑤ 最も強い反論に正面から当たる。スイッチ一つで直るなら、なぜ調達の話になるのか。反論は半分は成り立つ。成り立たない半分は時間差である。

⑥ では「モデル×ツール層」という調達単位は具体的にどんな形をしていて、誰に何を求めるべきか。

この話は夕刊には載っていない。前夜に収録したばかりの判断だからだ。本稿が前夜の判断に足したものは三つあり、いずれも指し示せる。一つ目に、「同じ日に、無関係な二つの情報源が同じ現象にぶつかった」という前提を攻め、この前提は持たなかった。 同じ日でも二つの情報源でもなく、7 月のブログが一度転載され、8 月の外部プルリクエストがベンダーのメモと取り違えられていた。二つ目に、4.6 ポイントの分母を分解した。 分母は 113 問で、標本誤差がちょうど 4.6 ポイントになる。したがってこの差は「ツール層に影響があるか」について何の情報も持たない。代わりに置いたのが、同じ記録にある 11 回の形式エラーによる中断だ。三つ目に、この判断を覆す条件を固定した。 Pi の元のツール定義で厳格モードを有効にしても編集の成功率が明らかに劣ると誰かが測れば、本稿の「直せる」という絞り込みは誤りとなり、前夜のより強い版が復活する。

上の図は、本紙がコーディングエージェントの流れを追ってきた地図である。本稿が扱うのは分岐の右側の経路、つまり「ツール層とモデルは切り離せない」という主張だ。この主張が、名前と出所と直し方のそろった仕組みを得たのは今回が初めてである。

ここだけ読む場合：ツール層ベンダーに問う項目には標準形ができた。「モデルごとにどのツール定義を使うか、厳格モードの初期値はオンかオフか、新モデルの公開から何日でその行を埋めるか」の三点である。

出所を正す：8 月 22 日に同時に見つかったのではなく、7 月のブログが二度転載されていた

前夜の判断を支えていたのは「同じ日に、無関係な二つの情報源」という骨組みだった。成り立つには、二つの情報源が互いに独立し、どちらも新しくなければならない。調べると、どちらの条件も満たしていなかった。

出所を並べ直すと、三つのことが変わる。第一に、仕組みの側の出所は「中国語の又聞き」から、一次のブログと GitHub の issue 一件に格上げされる。その issue #6278 は 7 月 3 日に立てられており、ブログより一日早い。第二に、数字の側の出所は「ベンダーの自己申告」から「外部貢献者のサンプル拡張で、ベンダーは受け入れていない」に格下げされる。もはや Pi の主張としては使えず、どのベンダーの測定としても使えない。第三に、台湾のある書き手が 8 月 23 日にこの話を整理した際、「マージ済みの Pi のドキュメントでこの三つの欄名は確認できなかった」とすでに書いていた。見つからなくて当然だった。三つの名前は Pi のドキュメントではなく、Ronacher 氏のブログにある。

この節の教訓は、誰の転載が間違っていたかではない。「同じ日にぶつかった」という形の証拠で最初に確かめるべきは、いつでも日付である。

「引数の発明」で何が起きたのか：ツール定義、二社の編集ツール、そして寛容すぎる訓練場

出所が片づいたところで、仕組みの中身に入る。まず三つの言葉を定めておく。

ツール定義：モデルにツールを呼ばせる前に、JSON 形式の説明でツール名、受け取る引数、各引数の型を伝える。モデルが返すツール呼び出しはこの説明に合っていなければならず、合わなければツール層は受け取りを拒むか、意図を推測するしかない。

Claude Code の編集ツール：Anthropic の公式ツールリファレンスによれば、名前は Edit で、引数は `file_path`、`old_string`、`new_string` と、任意の `replace_all` の四つ。規則として `old_string` はファイル内にちょうど一回だけ現れなければならない。複数回現れるなら、前後の文脈を長く含めるか、`replace_all` を真にする。

Pi の編集ツール：Pi の 3 月末のリリースノートによれば、`path` と配列 `edits` を受け取り、配列の各項目は `oldText` と `newText` を持つ。命名はキャメルケースで、一度に複数の編集を送れる。

では、モデルは何を書き足したのか。Ronacher 氏が挙げた欄は `type, id, kind, unique, requireUnique, matchCase, in_file, forceMatchCount, children, notes, cost, oldText2, newText2, oldText_2, newText_2` と、もう一つ `event.0.additionalProperties` である。この並びを上の二つの定義と突き合わせると、形ははっきりしている。

• 命名は Pi 流だ。 `oldText2` や `newText_2` は、Pi の `oldText` と `newText` に番号を振ったもので、Claude Code の `old_string` ではない。モデルは自社の欄名を持ち込んでいない。
• 規則は Claude Code 流だ。 `unique`、`requireUnique`、`forceMatchCount` はどれも「この文字列が何回現れるべきか」を言っている。これは Claude Code の編集ツールの中核の規則で、Pi の定義にはこの概念がない。

言い換えると、モデルが持ち込んだのは自社ツールの字面ではなく、自社ツールの習慣である。一度に複数を送る習慣、「この箇所は一意であること」を表明する習慣がまずあり、モデルはこの二つの習慣を相手側の命名様式で書き出した。前夜に書いた「自社ツール定義への過剰適合」より範囲が狭く、検証もしやすい。

Ronacher 氏自身の説明は、さらに一段深い。同氏によれば、Claude Code の編集ツールは「silently filters out unexpected keys and it does not use `strict` mode either」。余分な欄は黙って捨てられ、厳格モードも使われていない。続けて「If reinforcement learning happens in a harness like that, or a simulation of one, then slightly malformed tool calls can still complete the task and receive reward」と書く。強化学習がこうしたツール層の中で行われるなら、少し形式の崩れた呼び出しでもタスクを完了でき、報酬を得られる。結論は一文である。「The harness fully absorbs the error and there is little gradient against inventing an alias, adding a stray field or using a nearby parameter name」。ツール層が誤りを吸収しきるため、別名の発明、余分な欄の追加、似た引数名の使用を抑える力が訓練中にほとんど働かない。

この説明からは確かめられる推論が三つ出てくる。三つとも観察と合っている。一つ目の予測は、古いモデルにはこの癖がなく新しいモデルにはある、というものだ。事後学習が自社ツール層に寄るほど強まる副作用だからである。Ronacher 氏の観察は「both Opus 4.8 and Sonnet 5 show it but none of the older models」で、同じ会社の最新二機種に出て、旧機種には出ていない。二つ目の予測は、形式を強制すれば癖は消える、というものだ。同氏は「Obviously one could turn on `strict` sampling in Anthropic and the problem should go away」と書いている。三つ目の予測は、自社のツール層の中では癖がまったく見えない、というものだ。そこではもともと余分な欄が捨てられる。この点を測ったデータはまだない。ただ、この現象を見つけたのが Claude Code の利用者ではなく第三者のツール層の作者だった理由は、これで説明がつく。

発生率については、issue に一人の利用者のセッションでの測定がある。「about 20% of a particular edit call responses were malformed this way」、つまりある種の編集呼び出しの約 2 割が形式を外れていた。これは単一のセッション、単一の利用者、単一のモデルの数値で、母集団の数値ではない。本稿ではこの数字から倍率を導かない。

ベンダー自身の説明：一社は「訓練に使ったツール」を文書に書いて数字を示し、もう一社にその一文はない

仕組みが訓練の場の寛容さにあるなら、次に見るべきはモデルを作る側の言い分である。前夜の判断は「モデルは自社のツール定義で訓練されている」を Pi 側の推測として書いた。実際には、ベンダー自身が文書に書いている例がある。

OpenAI の GPT-5.1 プロンプトガイドの原文は「GPT-5.1 has been post-trained on specific tools that are commonly used in coding use cases」である。GPT-5.1 はコーディングでよく使われる特定のツールで事後学習されており、名指しされているのは `apply_patch` と `shell` だ。同じ文書は数字も出している。「In testing, the named function decreased apply_patch failure rates by 35%」。同じ機能の関数を自前で書かず、OpenAI が定義したツール型を使うと、テストで `apply_patch` の失敗率が 35% 下がったという。公式 API ドキュメントは、このツールの対応モデルを GPT-5.1 から GPT-5.5 までとしている。

この一文が重要なのは、前夜の「推測」をベンダーの自己申告に変え、しかも訓練に使ったツールの形とそうでない形の差を数字で添えているからだ。Ronacher 氏のもう一つの観察もこれで説明がつく。「So far, the Codex models I tested did not show this type of regression」、同氏が試した Codex モデルには同じ退行が出ていない。本紙の読みでは、OpenAI は訓練に使ったツールの形を API 上の誰でも使える型として公開しており、第三者のツール層がそれにつなげば、モデルが訓練された形そのものになる。Anthropic が訓練に使った編集の形は Claude Code の中にあり、第三者のツール層は初期設定ではそれを使わない。

Anthropic 側で本紙が確かめたのは二つの文書で、それぞれが半分ずつを語っている。テキストエディタツールの文書は Anthropic が定義した `str_replace_based_edit_tool` を提供しており、版は 2025 年 1 月から 7 月までに三つある。最も古い版の説明には「optimized for Claude Sonnet 3.7」、つまりそのモデル向けに最適化したとある。この文書の中に「モデルをこのツールで訓練した」という文は見当たらない。この点は事実のとおりに記しておく。もう一つは厳格なツール使用の文書である。ツール定義に `strict: true` を付けると、モデルの出力は文法制約つきのサンプリングで生成され、定義への適合が保証される。対応モデルには Opus 4.8、Sonnet 5、Opus 5、Fable 5 と 5.1 が含まれる。代償もある。定義の `additionalProperties` は偽にしなければならず、再帰や数値範囲など数種類の構文は使えない。ある定義を初めて使うときは文法のコンパイルを待つ必要があり、その後 24 時間キャッシュされる。

つまり、Ronacher 氏が「有効にすれば消えるはずだ」と言ったスイッチは Anthropic の API に実在し、同氏が問題を報告した二機種はどちらも対応リストに入っている。Pi の issue もこの道を指している。「Anthropic API offers strict schema validation that ensures this」。

4.6 ポイントを外し、同じ記録の 11 回に差し替える

仕組みとベンダーの言い分がそろったところで、前夜の判断のもう半分である数字に戻る。前夜の数字は、同じモデル、同じ問題集で二人の評価者が 58.4% と約 63% を得て、二人とも差をツール層のせいにした、というものだった。この帰属の問題は動機ではなく算術にある。

問題集は 113 問で、58.4% は 66 問の正解にあたる。この正答率での一回の測定の標本誤差は、113 の平方根を使う式で約 4.6 ポイントになる。独立した二回の測定の差なら、誤差は約 6.6 ポイントだ。二人の差の 4.6 ポイントは、誤差の単位で 0.7 にすぎない。この差は、ツール層、温度、運のどれについても何の情報も持たない。二人がツール層を原因に挙げたのは誠実な推測であって、測定ではない。

ただし、同じ記録の中に使える数字がある。58.4% の側には公開された設問ごとの記録が付いている。ツール層は `pier` 0.3.1 と `mini-swe-agent` の組み合わせだと明記し、こう自己申告している。113 回の試行のうち 11 回、すなわち 9.7% は、モデルが 3 回続けてツール呼び出しを一つも含まない応答を返したため中断された。記録はこの失敗を「tool-call format errors rather than reasoning deficits」、つまり推論の不足ではなくツール呼び出しの形式エラーだとしている。

モデルとツール層が合っているかを示すのは、この 11 回の方だ。形も、先に見た欄の発明と同じ系統に属する。モデルがツール層の読める出力を出すべき場面で、ツール層の読めない出力を出した。規模は二人の評価者の差の 2 倍あり、しかも同じ一回の測定の中にあるので、評価者をまたいだ比較も要らない。

この数値をより大きな母集団に置いても、形は変わらない。北京大学と啓元科技による Harness-Bench は、設定を変えられる六つのツール層と八つのモデルを掛け合わせ、5,194 本の実行軌跡を走らせた。同じタスク群、同じモデル群で、最良と最悪のツール層の差は 23.8 ポイントだった。失敗の分類で最大のものは「contract / format」、すなわち形式と出力契約の違反で、同論文が定義する実行整合の失敗の 36.4% を占める。次がツールのエラー後に有効な回復ができなかったケースで 24.6% だ。単一論文の自己申告で、まだ他の場所で再現されていない。それでも本稿が必要とする形は示している。ツール層が生む差のうち最大の塊は形式であって、能力ではない。

もう一つ、本紙が 8 月に収録した例を加える。同じ DeepSeek V4-Flash が TerminalBench 2.1 で三つのツール層によって 82.7、79、67 と測られ、差は 15.7 ポイントあった。この三つの数字は同じ一人の転載者がまとめたもので、三社の元の発表とは一件ずつ照合されていない。

最も強い反論：スイッチ一つで直るなら、なぜ調達の話になるのか

ここまでの議論は、直し方が安いことを自分で示してしまっている。そこで本稿自身を攻める。最も強い反論はこうなる。

仕組みの節で言ったとおり、直し方は `strict: true` か、ツール層に未知の欄を除く一行を足すことだ。Claude Code はまさにそうしている。一行で直るバグが、「調達単位がモデルからモデル×ツール層に変わる」こととどう関係するのか。

この反論は半分は成り立ち、そこは認めなければならない。仕組みの節で見た失敗の形、つまり欄の書き足しに限れば、答えは本当にこれだけ安い。厳格モードを有効にするか、Claude Code と同じく未知の欄を捨てればよい。Ronacher 氏も編集の中身自体は「usually correct」、つまり中身は正しく、包み方が形式に合っていないだけだと書いている。したがって前夜の「乗り換えると実際に性能が落ちる」は、こう絞り込む必要がある。乗り換えると、スイッチ一つで直せる形式上の退行にぶつかる。

成り立たない半分は二つの塊からなる。

一つ目の塊は時間差だ。 このスイッチを入れるのはモデル企業ではない。ツール層のベンダーがモデルごとに決める。Ronacher 氏の issue は 7 月 3 日に立てられ、厳格な検証を行うプルリクエストを指していた。同時にコミュニティでは拡張が二つ生まれた。一つは pi-anthropic-text-editor で、Pi の中で Claude 向けに Anthropic 純正の `str_replace_based_edit_tool` を登録する。もう一つは pi-apply-patch で、GPT 系モデルの使用中に Pi の書き込み・編集ツールを Codex 流の `apply_patch` に差し替える。説明には、「Codex models were trained on」という形式を使うためだと書いてある。二つの拡張は同じフォーク・プロジェクトから切り出されたもので、スター数は片方が 0、もう片方が 16 だ。規模はゼロに等しいが、形はすべてを示している。ツール層の中に「どのモデルにどのツールの形を使うか」の表が現れ始めた。この表は第三者が保守しており、新モデルの公開からその行が埋まるまでの数週間こそ、「乗り換えると落ちる」が現実に起きる窓になる。これはバグではなく、繰り返し発生する保守負債である。

二つ目の塊は、本稿では測れない層だ。 スイッチが解決するのは「欄の書き足し」であり、「習慣の違い」は解決しない。仕組みの節で見たとおり、モデルが持ち込むのは規則と習慣、つまり一度に複数を送ること、一意性を求めることだ。厳格モードは定義にない欄を書かせないが、習慣そのものは捨てさせない。呼び出しを複数回に分ける、`oldText` により長い文脈を詰め込む、といった形に変わるかもしれない。この層に成功率の代償があるかどうかは、まだ誰も測っていない。ここが本稿で最も正直に引くべき境界であり、覆す条件の一つ目の出どころでもある。

逆向きの例も一つ入れておく。「純正のツール層を使えば問題ない」という単純化には不利な例だ。Sebastian Raschka 氏は 6 月末に独自に試し、Qwen3.6 が自社の Qwen-Code より OpenAI の Codex のツール層で良い成績を出したと報告した。同氏の言葉では「to my surprise」で、標本が小さいことは同氏自身が断っている。この例が示すのは、「結びつき」が「純正が最良」を意味しないということだ。モデルが学ぶのは訓練場の寛容さと習慣であって、ブランド名ではない。訓練場と同じくらい寛容で習慣の合うツール層なら、純正でなくてもうまくつながる。したがって表に書き込むべきは「どこのものを使うか」ではなく、「このモデルにはどのツールの形を使い、厳格にするかどうか」である。

「モデル×ツール層」という調達単位の中身

反論の節で残った半分を引き受けると、前夜の「調達単位がモデルからモデル×ツール層に変わる」は単位を改める必要がある。掛け算の右側に来るのはブランドではなく、一枚の表である。

この表から、変わることが三つ導かれる。

測るべき数字が変わった。 ツール層をまたいだモデルの順位は持ち運べない。この点は本紙が 7 月に書いた。本稿が加えるのは、測るべきは同じモデルが自社のツール層の中で出すツール呼び出しの形式失敗率だという点である。58.4% の記録の 11 回のように、一回の測定で手に入り、他人のランキングは要らない。Terminal-Bench 3.0 の各行はもともとモデルとツール層を一緒に採点しており、首位の行は Opus 5 と mini-SWE-agent の組み合わせで 42.7% だ。この数字が語るのはその組み合わせであって、モデル単体ではない。

ツール層ベンダーに求める内容に標準形ができた。 上の表がそれである。複数モデル対応をうたうツール層ベンダーが「モデルごとにどのツールの形を使うか、厳格モードの初期値はどうか、新モデルの行を何日で埋めるか」に答えられないなら、その複数モデル対応はインターフェース上のものにとどまり、挙動の上での対応ではない。

プロトコルが開いていることと、モデルを持ち運べることは別物だと、今回より鮮明になった。 Vercel は 8 月 23 日、自社のエージェントツール fx は MCP、Skills、Plugins の三つのオープンなプロトコルだけを使うと発表した。翌日のリリースノートは「Codex と Grok のログインを修正」を売りの一つに挙げている。プロトコル層の開放は本物だが、本稿の表とは互いに干渉しない。プロトコルはどのツールにつなげるかを決め、表はつないだ後にモデルが欄を書き足すかどうかを決める。一つのプラットフォーム企業が両方をこなすことはできる。ただ、前者をこなしたからといって後者をこなしたことにはならない。

本誌の見立て

モデルは乗り換えられる。ただし設定を一行変えて済むのではなく、一枚の表を入れ替えることになる。このツール層の中で、モデルごとにどのツールの形を使うか、厳格モードを有効にするか、新モデルの公開から何日でその行を埋めるか、という表である。欄の書き足しという癖そのものはスイッチ一つで直るので、「乗り換えると落ちる」ことの証明にはならない。この癖が証明しているのは、ツール層がモデルごとにこの表を保守しなければならないことであり、表が新しいモデル世代に追いつかない数週間こそ、退行が現実に起きる窓だということである。今後「モデルとツール層は切り離せるか」という主張に出会ったら、本紙はまず、それが分岐のどちら側に立つかではなく、この表のどの行の話なのかを問う。

これは誰にとって何を意味するか

ここまでの判断を、立場ごとに引き直す。

コーディングモデルの年間契約を結ぶ企業

「モデルの交換は設定一行で済む」も「モデルの交換は受け入れ検査のやり直しに等しい」も、どちらも全称のスローガンである。本稿はこの二つを一つの問いに置き換える。検討中のモデルの行が、利用中のツール層の表で埋まっているかどうかだ。埋まっていれば、モデルの交換は設定変更に近い。埋まっていなければ、最初の週に成功率が落ち、落ちた分の大半は能力ではなく形式によるものになる。交渉の場で「乗り換える」という脅しが信用されるかどうかは、モデル企業ではなく、ツール層ベンダーが行を埋める速さで決まる。

ツール層やエージェントのプラットフォームを作る企業

Claude Code が未知の欄を黙って捨てるという事実には、この種の企業にとって避けて通れない含意がある。Claude Code はそのモデルの訓練場であり、製品の寛容さがそこからどれだけずれているかが、そのままモデルをつないだときのずれになる。最も安く済む対応は二つある。厳格モードに対応したモデルでは初期値を厳格にすること。純正のツール型を持つモデルでは、同じ機能の関数を書き直さず純正の型を使うこと。OpenAI の 35% の失敗率差が、この二つ目の値段にあたる。そのうえで「モデルごとのツールの形の表」を公開すれば、複数モデル対応の主張のうち検証できる唯一の部分になる。

この判断を覆す条件

• Pi かその他の第三者のツール層で、同じモデルに同じ問題集を厳格モードの有効前と有効後に一回ずつ解かせ、有効後も編集の成功率が Claude Code より明らかに劣ると示される場合。 そのとき反論の節の「スイッチ一つで直る」という絞り込みは誤りで、前夜のより強い版が戻ってくる。退行は形式の層ではなく習慣の層にある、という版だ。本稿で単独の反証に最も崩されやすいのはこの部分である。
• Ronacher 氏か誰かが、Pi の元の定義での Opus 5 か Fable 5 の欄の発明率がゼロに近いと公表する場合。 そのとき「新しい世代ほど深刻」という線は一世代かぎりのノイズにすぎず、仕組みの節の世代の向きは無効になる。同氏は Fable を試していないと明言しており、理由として分類器に黙って Opus へ格下げされるおそれを挙げている。
• Anthropic が自社モデルをテキストエディタツールで訓練したと文書に明記し、OpenAI と同じく純正の型と自前の関数の失敗率差を示す場合。 そのときベンダーの説明の節で見た二社の非対称は解消し、Anthropic 側についての本稿の読みは「該当する文が見当たらない」から「二社とも同じ型」に上がる。結論は変わらず、より固くなる。
• どこかのツール層ベンダーがモデルごとのツール呼び出しの形式失敗率を公表し、モデル間の差が無視できるほど小さいと示される場合。 そのとき表の節の表は保守する必要がなくなり、本稿はツール定義の書き方をめぐる工学上の脚注に格下げされる。

本稿は一つ目と二つ目の条件に観察の窓を設ける。この問いに次に答えが出る可能性が最も高いのは、Pi の issue のスレッドと Ronacher 氏の続報だからだ。本稿の判断の答え合わせの日(検証期日)である 2026 年 11 月 12 日に、本紙は三つのことを確かめる。Pi が Claude に対して厳格モードか純正ツールを初期設定にしたかどうか。Opus 5 か Fable 5 の欄の発明率を公表した者がいるかどうか。モデルごとの形式失敗率を公開したツール層ベンダーがあるかどうか。

本記事は日本語版・英語版・中国語版と同一の調査と判断にもとづいて書かれています。出典にはリンクを付け、原文書と報道を区別し、確かめられなかった点を明記しています。

ご意見・ご感想は [email protected] までお寄せください。