生成AIニュース 2026年6月21日

「意味はトレースできない」とAI自身が言った。その一言から始まったトレーサビリティ計器の話

AIが「意味はトレースできない」と自己申告した

AI駆動開発を進めていた開発者が、Claude Codeにトレーサビリティマトリクスの作成を依頼した。AIはこの作業を上手くこなす。IDを振り、表を整え、対応関係を並べる。ところが、開発プロセスの検討を続けるうちに、AI自身からこういうコメントが返ってきた。

AIはドキュメント間の番号を整えるのは得意だが、意味を正しくトレースすることはできない。

この一言が、トレーサビリティ計器「legixy」の出発点だ。

「UC-001とDD-001が番号で結ばれている」ことと「DD-001がUC-001の意味を正しく引き継いでいる」ことは、別の事実である。AIが保証できるのは前者だけだと、確率論的生成機が自己申告してきた。そこで問いを返した。「ではその欠落に、どのような対処方法があるのか？」　この一往復からV1が生まれた。

道具の話としてではなく、なぜこの道具が存在するのかの記録として書かれた記事が、Zennに公開されている。読んで、しばらく考えてしまった。

なぜ今これが重要か：需要のない交差点に道具は生まれない

トレーサビリティの自動検証など、誰かがとっくに作っていそうに思える。なぜなかったのか。

記事はこの問いに正直に答えている。道具自体はあった。航空・医療機器・自動車・鉄道といった規制分野では、要求トレーサビリティは規格上の義務であり、商用の要求管理ツールが何十年も前から存在する。なかったのはツールではなく、交差点だった。

「トレーサビリティを義務づけられる集団」と「AIエージェントで日常的に開発する集団」の積集合が、現時点でほぼ空集合なのだ。前者はAIコーディングエージェントをほとんど使わず、後者には速度を競う文化があってトレーサビリティの語彙がそもそもない。CLAUDE.mdにも、MCPのエコシステムにも、「トレーサビリティ」という言葉は出てこない。

ここからは見方だが、この空集合が埋まる条件は2つある、と記事は整理している。ひとつは「AIコーディングが長期保守領域へ浸潤し、検証の壁に当たる開発者が増えること」。もうひとつは「規制側がAI生成物を受け入れる枠組みを定め、その枠組みが証跡を要求すること」。後者が動いた瞬間、トレーサビリティは文化の問題から適合性の問題に変わり、需要は個人の選好ではなく義務として一斉に立つ。

legixyは「早すぎる需要の先取り」ではなく、「制度が来たときに、既にそこにあるための先行実装」として位置づけられている。この見立ての妥当性は今後の規制の動き次第だが、構造として理解しておく価値はある。

実測が裏付けた「静かな破壊」

AI自身の自己申告だけでは逸話にすぎない。これを定量化した実測がある。

Microsoft Researchの論文「LLMs Corrupt Your Documents When You Delegate」（Laban / Schnabel / Neville）だ。DELEGATE-52というベンチマークで、52の専門ドメインの文書を19のLLMに渡し、20回の委任編集ワークフローを繰り返させた。結果は以下の通り。

フロンティアモデル（Gemini 3.1 Pro / Claude 4.6 Opus / GPT 5.4）でさえ、ワークフロー終端までに文書内容の平均25%を破壊した
全モデル平均では劣化は約50%に達した
20回の対話後も再構成スコア98%以上という「ready」基準に大半のモデルが達したのはPythonのみ。最良モデル（Gemini 3.1 Pro）でさえ、readyは52ドメイン中11にとどまった
エージェント用ツールや現実的なdistractor文書を与えると、性能はむしろ悪化した

数字より重要なのは壊れ方だ。弱いモデルは削除で壊す。欠落は見ればわかる。問題はフロンティアモデルの方で、形式・長さ・流暢さを保ったまま意味だけが移動する「もっともらしい書き換え」で壊す。研究チームはこれを「sparse but severe（まばらだが深刻）」な静かな破壊と表現している。能力が上がるほど破壊が「上手く」なり、検出が難しくなる。

劣化のパターンも特徴的だ。モデルは小さな誤りを毎回積むのではなく、多くのラウンドではほぼ完全な保全を維持しつつ、ごく一部のラウンドで10〜30ポイント以上を一度に失う。このまばらな致命的失敗が、観測された劣化全体の約8割を説明する。

ただし重要な留保がある。DELEGATE-52が測ったのは「検証ループを一切挟まない委任」のベースラインだ。各ターンは独立の単一ターンセッションで、人間は途中の成果物を見ず、修正も差し戻しもしない。著者ら自身がこの線を明確に引いており、「実利用者についての主張には使えない」と断っている。

つまり25%という数字の正確な読み方は「AI駆動開発の現実」ではなく、「検証なき委任のベースライン」だ。検証ループを挟めば変わる。では、その検証ループを誰が担うのか、という問いに戻ってくる。

legixyの設計：V1の意味検証はenabled=falseで出荷された

legixyの三層アーキテクチャは、あの一往復の分解をそのまま写している。

第1層（形式検証）：番号の世界。ID整合・ファイル存在・連鎖順序――機械が決定論的に保証できる領域
第2層（意味検証）：意味の世界。AIが「できない」と申告した領域を、凍結されたembedding計器で観察可能にする――保証はできなくとも、ずれの観測はできる
第3層：人間によるレビュー。V1のREADMEはこの層を「本ツールの対象外」と明記した

ここで正直な告白が記録されている。V1の時点で、意味層（第2層）は主役ではなかった。「AI自身がそう言っているのだから、安く塞げるなら塞いでおけ」程度の動機で、設計の重心は第1層にあった。その証拠として、V1のinitが生成する既定設定で、意味検証はenabled=false――任意機能として、無効のまま出荷されていた。

それを中心機能に変えたのは、前述のMicrosoft Researchの実測だ。先見ではなく、実測に押し上げられた。この経緯の正直さが、この記事の信頼性をひとつ上げている。

V1からV3への進化の履歴も記録されている。V2でMCPサーバーとフィードバックループ（observe→analyze→approve/reject）が加わり、V3でマトリクスが有向グラフに置き換わった。「成果物の関係は多対多――マトリクスでは追跡の形が足りない」という問いに答えた結果だ。

コードには検証ループがある。では文書は？

実務の観点から、ここが一番刺さる問いだと思う。

DELEGATE-52で唯一「ready」基準に大半のモデルが達したのがPythonだった。偶然ではない。コードには検証ループが既にある。テスト、CI、型検査――これらがコードの逸脱を検出する構造として社会に埋め込まれている。検証可能な領域でだけ、モデルは崩れなかった。

問題はSPEC・UC・DDという自然言語成果物だ。

既存の防御	すり抜けられる理由
diffレビュー	削除は見えるが、もっともらしい書き換えは「妥当な修正」に見える
テスト	コードしか守らない。SPEC/UC/DDは対象外

AI駆動開発では、仕様からコードへの変換をLLMに委ねる場面が増えている。コード側に検証ループがあっても、その上流にある自然言語成果物の検証ループが欠けていれば、静かに意味がずれていく。しかも「もっともらしい書き換え」で。

ここからは実務的な話だが、開発チームが今すぐ問うべきは「AIの出力を信じるかどうか」ではない。「AIの出力の上流にある文書の変化を、誰がどの構造で追跡しているか」だ。その答えが「人間の記憶と善意」なら、DELEGATE-52が示した経路で静かに壊れていく可能性がある。

legixy自体を導入するかどうかは別として、この問いを持っておくことには価値がある。

起源への自己適用という構造

記事の中で個人的に面白いと思った論点がある。legixyがなぜ品質保証の語彙で出来ているのか、という問いへの答えだ。

記事はこれを「AI開発を考えていたら品質保証に到達した」とは説明しない。もっと冷たく整理している。「AI は確率論的生成機である」と定義し、「ではこの生成機の品質をどう保証するか」と問うたとき、AIが返したのは真理ではなく、学習した知識空間の中で問題定義に最も近い既存の知識クラスター――品質保証・監査・トレーサビリティ・規制――だった、と。

そしてこの起源説明は、「出自が分布である以上、出自を信じるな、ゆえに試せ」という結論を導く。L2A SCPの上に作られた道具の起源説明が、L2A SCPの世界観そのもので記述され、その記述の帰結が「検証せよ」に着地する。自己一致でなければ崩壊する構造になっている。

人間も確率論的生成機である、という命題も同じ場所から出てくる。人間の生成が破綻せずに来たのは、時間・レビュー・職業的責任・組織的監査という検証ループが社会に埋め込み済みだったからにすぎない。AIが危ういのは本性が劣るからではなく、その埋め込みを持たないまま、高速・大量に連鎖させられるからだ――という整理は、AI論としてではなく品質管理の論理として読める。