Anthropic Claude の出力に言語的ドリフト、著作者が問題提起

最近、最先端のモデルから奇妙な挙動が目立つようになりました。コーディングやデザイン、問題解決などの能力は向上しているのに、文章生成に関してはもう耐えられません。本当に腹立たしいのです。

最も最近では、Anthropic の Claude モデルが「seam」という単語を使い始めました。これはソフトウェア（あるいはその他の）システムにおいて、2 つのコンポーネントがつながる点を指す言葉です。私はこれまでこの用語を聞いたことがありません。私がソフトウェア用語に詳しいわけではありませんが、通常は「interface」や、もっと基本的な「contract」（SDK や API の契約など）という言葉を使うはずです。「seam」という表現でこれを表したことは、最近 Fable 5 がコードベースにこの言葉をあちこちに吐き出すまで、聞いたことがありませんでした。

そこで今回は、Pydantic AI の機能を使ってこの現象に対処しようと思います。結果はケースバイケースですが、少なくともあなたの知性的・哲学的な側面に響く言葉になるでしょう。また、Pydantic AI と Pydantic AI Harness が提供する強力な抽象化機能を用いて、エージェント型ハニースの機能をいかに簡単に作成できるかを実演します。

ある日、コンテキストをクリアして Fable 5.1 に尋ねてみました。「ソフトウェアの構成要素が接する点を説明する際、なぜいつも『シーム』という言葉を使うのですか？」と。Fable 5.1 は明らかに防御的な態度を取り、2004 年の書籍、マイケル・フィザーズの『Legacy Code と効果的に付き合う』を引用しました。Fable の厳密な強化学習は数十年も前の古びた用語を掘り起こし、それが実際に広まっていることを示しています。

この Google 検索トレンドの画像を示すと、Fable は正当に防御的な態度を見せました。急増は非常に不審ですが、「seam」という言葉自体がソフトウェア固有のものではありません。そこで私は GitHub を指し示して、「seam」という単語を含む PR（プルリクエスト）を検索するよう頼みました。すると約 70 万件が見つかりました。そのうち約 68.5 万件は 2026 年からのものです。残りの約 1.5 万件はすべて 2026 年以前のものでした。

次に、Fable 5.1 に、これらの PR のコミットメッセージに一般的な Claude Code の共著者ノートが含まれているか確認するよう頼みました。その結果は非常に決定的です。

PR 本文内の指紋 | 件数 | seam 関連 PR の割合 | 2026 年全 PR に対する割合 | 過剰代表度

---|---|---|---|---

"Claude Code" | 307,971 | 45% | 12.5% | 3.6x

"Generated with Claude Code" (正確なフッター) | 247,275 | 36% | - | -

"Codex" | 119,845 | 17.5% | 5.8% | 3.0x

"Copilot" | 53,726 | 7.8% | 5.2% | 1.5x

"Cursor" | 51,974 | 7.6% | - | -

"Gemini" | 25,514 | 3.7% | - | -

"Devin" | 4,970 | 0.7% | - | -

これは決して誤りではありませんが、私が「言語的ドリフト」と呼ぶ現象を象徴しています。AI を利用するすべてのユーザーが知っておくべきであり、時には懸念すべき点です。

さらに厄介なのは、この言語的ドリフトがモデルからモデルへと伝播していくことです。ここ数ヶ月、Anthropic の Claude 3.5 Sonnet（現在は 3.5）との作業を楽しんでいますが、私のコードベースには「seam」という単語がコメント、ドキュメントストリング、Markdown ファイルに溢れています。そして OpenAI の GPT-4o、DeepSeek v4 Flash (0731)、Qwen 3.8 27b、あるいは最新の Z.AI GLM 5.3 Flash を使っても、彼らは既存のコードベースを読み込み、「seam」という言葉について語り始めます。

もう少し深く掘り下げてみました。LLM の「患者ゼロ」は誰だったのか？答えは明白です。Opus 4.6 が患者ゼロでした。「seam」という単語を使う傾向が徐々に広がり、その後 Opus 4.7 でさらに増幅され、Opus 4.8 の登場で急激にピークを迎えました。

ここで起きているのは、古くからあるフィードバックループです。なんと恐ろしいことでしょう。

「seam」という言葉の現象は、それだけで終わる話ではありません。その背景には、さらに深い要因が潜んでいます。

この傾向を定量化できないかと考え、GitHub の README ファイルをスクレイピングする実験を始めました。最初は HuggingFace からデータセットを取得しようとしたのですが、期待したほどの成果はありませんでした。最終的に、2025 年以前の README 4,319 件（22 の言語にわたる層別サンプリング）と、Claude Code によるコミットが行われたリポジトリから取得した 2026 年版の README 1,047 件のデータを収集しました。

2025 年以前のデータセットでは、低品質なコンテンツを除外するため、スター数が 500 件以上という条件を設けました。一方、2026 年のデータにはこの制限は適用していません。これらのデータを TF-IDF（Term Frequency - Inverse Document Frequency）ベクトライザーにかけ、次に特異値分解（Singular Value Decomposition: SVD）、そして t-SNE を通して可視化しました。

※余談ですが、私はあえて伝統的な NLP 手法を採用しています。なぜなら、すべての課題をトランスフォーマーで解決する必要はないからです。

緑色 = 2025 年以前

オレンジ色 = 2026 年

これは、言語の drifting（漂移）を視覚化したものです。

これは、AI による集団的な精神錯乱なのでしょうか。それとも、システム構成要素の結合点を指す適切な用語が「シーム（seam）」であるという事実を受け入れ、対抗するべきでしょうか。それとも、AI の支配者が選んだ新しい語彙を全員が採用すべきなのでしょうか。

一瞬、あなたがこれまで人生の大半で学び、使用してきた言葉の意味について考えてみてください。日常生活で使っている用語や表現は、中央集権的な政府や巨大企業から来たものですか？場合によってはそうです。特定のブランドが浸透した場合（Google や Kleenex など）のようにです。しかし、多くの場合、それは人間由来のものでした。学術用語であれば厳格なピアレビューを経た権威ある専門家によるものであり、そうでなければ作家、芸術家、詩人、音楽家といった人間の影響力から生まれたものです。

AI が社会規模で引き起こす精神錯乱の長期的な見通しについて、あまり哲学的に深入りするつもりはありません。しかし、あなたの心に種を蒔くために提示したい、恐ろしい状況があります。ある航空会社で働いていると想像してください。そこで顧客サービスチケットの受付を行うエージェントを作成しました。このエージェントは非常にシンプルです。類似したチケットを検索して分類を支援するためのツール呼び出しが一つ、顧客データを取得するためのツール呼び出しがもう一つあります。目的は、トリアージチーム（実際の人間）に引き継ぐために、顧客や類似チケットに関するデータをできるだけ多く掘り起こすことです。

これを Pydantic AI エージェントとしてどのように構築するかを見てみましょう。

from dataclasses import dataclass

from pydantic import BaseModel

from pydantic_ai import Agent, RunContext

@dataclass

class Deps:

customers: object

tickets: object

class TriageBrief(BaseModel):

category: str

priority: str

summary: str

agent = Agent(

"openai:gpt-5.6-luna",

deps_type=Deps,

output_type=TriageBrief,

instructions=(

"Triage airline support tickets for a human team. "

"Always retrieve the customer profile and similar past tickets "

"before writing a concise brief."

),

)

@agent.tool

async def get_customer(ctx: RunContext[Deps], customer_id: str) -> dict:

return await ctx.deps.customers.get(customer_id)

@agent.tool

async def similar_tickets(ctx: RunContext[Deps], query: str) -> list[dict]:

return await ctx.deps.tickets.search(query, limit=5)

result = await agent.run(

f"Customer: {ticket.customer_id}\n"

f"Subject: {ticket.subject}\n"

f"{ticket.body}",

deps=deps,

)

brief = result.output

これは完全に架空のシナリオですが、このブログ記事で最も注目したい構造化された出力フィールドは「要約（summary）」です。この要約は、後段の人間によるトリアージチームに対して、重要な情報を簡潔に伝えるために用意されています。人間の担当者は、「手荷物の紛失」や「遅延」といった特定のキーワードに瞬時に対応できるよう訓練されているはずです。

さて、Fable 5.1 というモデルが、航空業界の権威ある書籍『Legacy Aviation Systems と効果的に付き合う方法』の中で「doodled」という用語を「遅延」の意味で使っていると仮定してみましょう。はい、はい、はい……これは明らかに誇張ですが、言いたいことはお分かりいただけるはずです。

Spirit Airlines（※現在は倒産）がチケット受付エージェントを Anthropic の claude-sonnet-5 から OpenAI の gpt-4o に切り替えた瞬間、トリージョチームが一斉に本社へ「『doodled』というフライトはどういう意味ですか？」と問い合わせ始めます。……当然、大混乱です。

このディストピア的な未来は未然に防げます。私たちは無力ではありません。ハームエンジニアとして、Pydantic AI の機能を使ってエージェントに制約を課すことができます。その制約とは、人間が定義したガードレールです。

上記の GitHub README を参考に、Fable 5.1 に生成されたテキストのスパンを評価する分類器を作成させました。この手法の詳細は付録に記載します。

これは PyPI パッケージとして公開されており、uvx vocabguard "some text ..." コマンドを実行すれば、あらゆるテキストスパンに対して適用可能です。

プロジェクトに vocabguard を追加するには、uv add vocabguard と実行してください。以下は、Pydantic AI エージェントでこれを利用した例です。

from pathlib import Path

from pydantic import BaseModel
from pydantic_ai import Agent

from vocabguard import OutputField, TextOutput, ToolArgument, VocabularyGuard

class CaseTicket(BaseModel):
    summary: str
    priority: int

def write_markdown(path: str, content: str) -> str:

"""docs/ 配下にファイルを記述する。"""

target = Path(path)

target.parent.mkdir(parents=True, exist_ok=True)

target.write_text(content)

return f'wrote {path}'

guard = VocabularyGuard(

rewriter='openai:gpt-5.6-luna',

targets=[

OutputField(CaseTicket, lambda ticket: ticket.summary), #構造化された出力のフィールド

ToolArgument(write_markdown, 'content'), # ツール呼び出しの引数

TextOutput(), # エージェントが文章で回答する際の最終テキスト

],

on_hit=lambda report: print(report.describe()),

)

エージェントはチケットを提出するか、提出すべき事項がない場合はテキストで返信する。

agent = Agent(

'openai:gpt-5.6-luna',

output_type=[CaseTicket, str],

instructions='不具合報告のトリアージを行う。作業メモを docs/triage/.md に記述し、その後チケットを提出せよ。',

tools=[write_markdown],

capabilities=[guard],

)

result = agent.run_sync(

'Bug report: exporting a project with more than 200 assets hangs the desktop app at 97%. '

'Reproducible on macOS and Windows since 3.4.1. Three customers affected, one enterprise.'

)

print(result.output)

Vocabguard は、このエージェントからのモデル出力が宣言されたターゲット（Pydantic Structured Outputs を使用している場合は ToolArgument または OutputField を指定可能）と一致した場合、その Vocabguard の機能により、再書き込み用 LLM が出力の言い換えを試みます。あるいは、再書き込み機能を無効化し、代わりに ModelRetry を発生させて、表現やトーンに関するヒントを付与することも可能です。

また、uvx vocabguard コマンドとして実行できるため、Claude Code のフックや mini Pi 拡張機能との連携も容易です。スタンドアロンのツールとして uv tool install vocabguard で利用することもできます。

この手法が実際に効果的かどうかはまだ確信が持てません。言語ドリフトは非常に深刻な懸念事項であり、今回の試みは Fable 5.1 を使って午後にふざけて作ったものです。本格的な博士論文レベルの研究が必要ですし、半リアルタイムで言語ドリフトを監視するツールの開発も急務です。

そういえば、Nature 誌がすでに先を行っていました。「大規模言語モデルの時代における言語多様性の縮小」という記事です。

ぜひお試しください。いかがでしょうか？用語の整合性を保つのに役立つかもしれません。Pydantic AI の Capabilities が救世主となるでしょう。もし Spirit Airlines が Pydantic AI の Capabilities を活用していれば、経営危機を回避できたかもしれませんね。

お読みいただきありがとうございます！

謝辞

Eugene Geis 氏は、類似点のある興味深いブログ記事を執筆してくれました。

Patrick Harrison 氏からは、GH Archive を活用してデータセットを充実させるという素晴らしい提案をいただきました。

バージニア州シャーロッツビルで、Slack の#datascience および #ai チャンネルで刺激的な議論を繰り広げた Carson Sweet 氏と Owen Zanzal 氏に感謝します。

最近の採用において Pydantic にお世話になりました。2.5z_w>2.5 は、プールされたコーパス全体における文書均等度 ew=dfw/tfwe_w=\mathrm{df}_w/\mathrm{tf}_w によって再重み付けされます。

z^w=zw ewγ,γ=1,\hat z_w = z_w\,e_w^{\gamma}, \qquad \gamma=1,

そして、この値が最も大きい 1,000 個の z^w\hat z_w が監視リスト WW を構成します。

トークンシーケンス TT を持つテキストのスコア s(T) は以下のように計算されます。

s(T)=1∣T∣∑t∈T,  t∈Wmax⁡(0,z^t),s(T)=\frac{1}{|T|}\sum_{t\in T,\;t\in W}\max(0,\hat z_t),

閾値 τ=0.41\tau=0.41 は、各コーパスの 20% をホールドアウトしたデータセット上でバランス精度を最大化するように設定されたカットオフ値です。このスコアリング手法は AUC 0.8690.872 [ランクベース、Hanley & McNeil, Radiology 143, 1982] を達成し、真陽性率と偽陽性率はそれぞれ 0.750.75 と 0.060.06 です。

文書均等度の重み付けを行わない場合、AUC は 0.8720.872 ですが、エージェント（agent）が最上位にランクされます。一方、γ=1\gamma=1 の設定では「every」「across」「never」が最上位となり、エージェントのスコアは z=77z=77 から z^=5.4\hat z=5.4 に低下します。