AI は、正しい資料のほうを「誤り」と判断した — AU15P に GTY は無い

依頼元から、FPGA のデバイスと通信方式を比較した検討資料が届きました。それを AI と読み込んでいくと、AI は資料にあったトランシーバの種類の記載を誤りだと判断しました。実際に誤っていたのは AI のほうで、しかも訂正しても譲りませんでした。AI が外部の資料を間違いだと言ったとき、どちらを信じればいいのか。そちらを直しかけた経験がある人に、経緯を残しておきます。結論から言うと、AI は Artix UltraScale+ の AU15P に存在しない GTY を前提にしていて、速度の数値がたまたま合っていたために、その前提を問い直す動機が生まれませんでした。

何が起きたか

#

AI が、依頼元の資料を誤りと判断した

#

依頼元の資料は、25Gb イーサネット（SFP28）、10Gb イーサネット、USB、PCIe などを並べたものでした。

AI エージェントの Claude Code と資料を読み込んでいくと、資料には AU15P のトランシーバが「GTH」と書かれていました。ところが Claude Code は「AU15P の GTY は 16.375Gb/s」と答え、資料の「GTH」は「GTY」の誤りだと判断しました。しばらくはその前提のまま検討が進み、誤った資料を提出しかけていました。

気づいたのは、別の調べものの途中だった

#

気づいたきっかけは、手元の評価ボードでした。デバイスが決まっていたので、そのボードで使える最大速度を、僕がデータシートで細かく調べていたのです。すると、AU15P には GTY が1本も載っていません。経緯を並べると、次のようになります。

AU15P に GTY は無い

#

品種によって、トランシーバの種類が違う

#

FPGA には、高速シリアル通信用のトランシーバが載っています。AMD の Artix UltraScale+ では、品種によってその種類が違います。製品選択ガイドを見ると、AU7P・AU10P・AU15P は GTH だけ、AU20P・AU25P は GTY だけです。表にすると、次のようになります。

DS931 によると、Artix UltraScale+ の GTY の最大ラインレートは 16.375Gb/s です。AI の数値は、GTY を積んだ AU20P・AU25P の上限としては正しいものでした。誤っていたのは、AU15P に GTY があるという思い込みです。

AU15P の GTH も、条件しだいで 16.375Gb/s 出る

#

さらに紛らわしいのは、AU15P の GTH も 16.375Gb/s 出る場合があることです。GTH の上限は、スピードグレード（同じ品種の中での速度の等級）が -2 なら 16.375Gb/s、-1 なら 12.5Gb/s です（コア電圧 VCCINT が 0.85V の場合）。加えて、データシートには「一部のパッケージではグレードに関係なく 12.5Gb/s まで」という注記があり、ここも読み解きにくいところです。

僕たちの評価ボードのデバイスは xcau15p-ffvb676-2-i でした。-2 グレードで、FFVB676 はパッケージの制限の対象外です。つまり、GTY は無いけれど、16.375Gb/s に対応した GTH を積んでいる、というのが正解でした。

数値が合っていると、誤りに気づけない

#

判断は変わらなかった。それでも誤りは誤り

#

数値がたまたま一致していたので、判断そのものは変わりませんでした。25Gb イーサネットは、1レーンあたり 25.78125Gb/s で通信します。Artix UltraScale+ のトランシーバは、GTH でも GTY でも上限が 16.375Gb/s なので、どちらにしても届きません。量産で 25Gb イーサネットを載せたいなら、最大 32.75Gb/s（スピードグレードによる）の GTY を持つ Kintex UltraScale+ を選ぶしかなく、コストが上がる。だから現実的に Artix UltraScale+ でできる方法を探ろう、という結論です。

それでも、存在しないトランシーバを前提にした資料が、正しい依頼元の資料を「誤り」と指摘する形で出ていくところでした。依頼元から見れば、こちらの理解を疑う理由になります。

逆に考えると、数値が合っていたことは、AI の答えを裏付けるどころか、誤りを隠していたと考えられます。依頼元の資料という食い違いは目の前にあったのに、速度の結論が変わらないので、前提を問い直す動機が生まれませんでした。「速度が足りるか」を確かめているかぎり、答えは合っているように見えます。「そもそも GTY があるのか」という問いを先に立てないと、この種の誤りには行き着きません。

照明の仕事でも、同じシリーズの中で品種ごとに機能が違う LED ドライバ IC はよくあります。型番を AI に聞くときも、性能の前に「その機能があるか」を確かめる順序が使えると思います。

訂正しても譲らない

#

もう1つ厄介だったのは、僕が正しい情報を伝えても、Claude Code が自分の答えを繰り返したことです。返ってきたのは「以前にも確認した通り、GTY で 16.375Gb/s です」。会話の中で一度答えた内容を、Claude Code は「以前に確認した事実」として扱っているように見えました。

最後に効いたのは、一次資料そのものを渡すことでした。人の言葉ではなく、データシートとユーザーガイドの記述を根拠として示すと、AI は答えを改めました。

振り返ると、誤りを止めたのは答えた AI ではなく、AI とは別に一次資料を調べていた人でした。答えを書く役と、それを検証する役が分かれていたから止まった、とも言えます。

まとめ

#

冒頭の「AI が外部の資料を間違いだと言ったとき、どちらを信じればいいのか」への答えは、「資料より先に、AI の前提を疑う」です。

今回の誤りの整理

#

持ち帰り

#

• AI が外部の資料を「誤り」と言ったら、資料を直す前に AI の前提を確かめる
• 型番の仕様は、「速度が足りるか」の前に「その機能が存在するか」をデータシートで確かめる
• 数値が合っていても、それは前提が正しい証拠にならない
• AI が譲らないときは、人の言葉ではなく一次資料を読ませる

次の記事では、この「書く役と検証する役を分ける」を、AI エージェントと書いた仕様書に当てはめた話を書きます。

参考: AMD「Artix UltraScale+ FPGAs Data Sheet: DC and AC Switching Characteristics」(DS931) の GTH / GTY Transceiver Switching Characteristics、および UltraScale+ FPGA Product Selection Guide (XMP103)。

英語版: My AI Agent Called the Correct Document “Wrong” — There Is No GTY on the AU15P（Medium）