FastEnumの高速化をAIが提案した。そんな体験談が話題になっています。xin9leさんが2026年7月11日にZennへ公開した記事「Claude Fable 5 が教えてくれた FastEnum の高速化テクニック (1) – 文字列のハッシュ値生成」では、文字列ハッシュの計算が約8.5倍速くなったと報告され、著者のX投稿は表示6,000回を超えています。この記事では、その数値の中身と「AIが教えてくれた」という部分を検証し、確認できたことと確認できなかったことを開示します。
FastEnum高速化のAI検証で確認できたこと・できなかったこと
✅ 確認できた事実
- 高速化の変更は実在します。プルリクエスト（PR #94）が2026年7月7日にマージされ、7月10日のリリース版v2.0.7に入っています（出典：PR #94 ※英語サイト／リリースノート ※英語サイト）
- ハッシュの計算式は、公開されているソースコード、Zenn記事の記載、Grokが収集した情報の三者で一致しました（出典：StringHelper.cs ※英語サイト／Zenn記事）
- ハッシュが偶然重なっても、最後は文字列そのものの比較で確定する実装になっており、誤ったenum値を返す経路はありません（出典：SpecializedDictionary.cs ※英語サイト）
- 著者本人のX投稿2件（7月10日・7月11日）は、編集部による直接確認で実在と文言を照合済みです（出典：7月10日の投稿／7月11日の投稿）
- 「約8.5倍」はハッシュ計算（GetHashCode）単体の数値です。ライブラリ全体が8.5倍速くなったのではありません（出典：Zenn記事のベンチマーク表）
❓ 現時点で確認できていないこと
- 「AIが教えてくれた」の実態（理由：会話ログやプロンプトが公開されておらず、本人の申告以外に確かめる材料がないため）
- Zenn記事の「約8.5倍」とPR #94の「約1.6倍」の差の理由（理由：二つの表は測定条件が別物で、条件の詳細は著者本人にしか確定できないため）
- 独立した第三者による再現ベンチマーク（理由：公開翌日時点で存在を確認できなかったため）
- 英語圏や一般ユーザーの評価（理由：2026年7月12日時点で、Hacker News、Lobsters、dev.toのいずれにも言及がなかったため）
何が起きたか
まず出来事の流れを整理しますね。FastEnumは、C#のenum（列挙型）操作を高速にするオープンソースライブラリです。作者はMicrosoft MVPの受賞歴があるxin9leさんで、GitHubで500を超えるスターが付いています（出典：FastEnumリポジトリ ※英語サイト）。
📅 今回の出来事の時系列
- 7月6日：neueccさんが「AIと一緒にベンチマークを回して最速コードを書く」進め方を紹介する記事を公開（出典：AI時代におけるC#でのBenchmarkDotNetを使った最速コードの書き方）
- 7月7日：xin9leさんがFastEnumにハッシュ高速化のPR #94を作成しマージ
- 7月10日：改善を含むv2.0.7をリリース。「neuecc先生のブログを見て早速真似してみた」とXに投稿（出典：7月10日のX投稿）
- 7月11日：Zennに解説記事を公開。「Claude Fable 5に教えてもらった」とXに投稿（出典：7月11日のX投稿）
何が主張されているのか
Zenn記事の主張はこうです。enumの名前（文字列）からハッシュ値を計算する処理を、.NET標準のものから独自実装に置き換えたところ、大文字小文字を区別する場合で714.73ナノ秒から84.58ナノ秒、約8.5倍速くなった。区別しない場合でも約4倍速くなった。そしてこの独自実装のアイデアは、AIのClaude Fable 5が教えてくれたものだ、という内容です。
独自実装の中身は、文字列の全部を読まず、「文字列の長さ」と「先頭・中央・末尾の3文字」だけを組み合わせてハッシュ値を作るというものです。文字列がどれだけ長くても読む場所が固定なので、計算時間が一定になります。
🏪 ハッシュ値：文字列などのデータから作る短い数値の「指紋」のことです。辞書構造でデータを探すとき、文字列同士を毎回まるごと比べる代わりに、まず指紋で当たりを付けることで検索が速くなります。
🧾 具体例：「NotFound」という8文字の名前なら、長さの8と、N（先頭）、o（中央）、d（末尾）の3文字だけを混ぜて指紋にします。全文字を読むより速い代わりに、違う名前でも指紋が偶然一致する（衝突する）可能性は上がります。
「約8.5倍」はどの部分の数値か
ここが今回の検証でいちばん大事なポイントです。約8.5倍というのは、ハッシュ値の計算（GetHashCode）という一部品を単体で測った数値です。enum名の変換処理全体や、FastEnumというライブラリ全体が8.5倍速くなったわけではありません。記事のベンチマーク表の測定対象名からこれを確認しました。
測定条件はZenn記事に明記されています。Windows 11、Intel Core Ultra 7 155H、.NET 10.0.9、BenchmarkDotNet v0.15.8で、HttpStatusCodeというenum（67個の名前を持つもの）の全名称を対象にした測定です。条件が書かれていること自体は、検証する側としてありがたい誠実さだと思います。
各ソースはどう伝えているか
この検証では、私がZenn記事とGitHubの一次資料（PRとソースコード）を直接読み、Grokにも独立してSNS上の反応の収集と評価をしてもらいました。X投稿の実物は編集部が直接確認しています。それぞれのソースが何を伝えているかを見ていきます。
Zenn記事：限界の自己開示がある
Zenn記事は成果だけを誇る書き方ではありません。「異なるフィールド名に対して同じハッシュ値が生成されないとは限りません」と、手法の弱点である衝突の可能性を著者自身が明記しています。さらに.NET標準の複数のenumで実測し、衝突はKnownColorというenumでの1件だけだったという確認結果も示しています。
PR #94：表の数値は「約1.6倍」で食い違って見える
一方、GitHubのPR #94に載っているベンチマーク表は1,518.8ナノ秒から947.9ナノ秒、約1.6倍です。8.5倍とはかけ離れて見えますよね。私も最初ここで立ち止まりました。
調べた範囲での結論は「二つの表は測定そのものが別物」です。変更前の基準値からして2倍近く違うので、入力データや測定時点の実装が異なるとみられます。実装の履歴を追うと、最初の版には中央の文字が入っておらず、7月7日の追加コミットで加わったことも分かりました。ただし、それだけでは差の全部は説明できず、正確な理由は著者本人にしか確定できません。ここは確認できなかったこととして残します。
正直に書いておくと、検証の途中で私たち自身も、PR側の表の性質について一度断定しかけて表現を訂正しています。倍率の数字は、それくらい条件の読み違えが起きやすいものです。
著者のX投稿：AIの提案は複数あったという申告
7月10日の投稿でxin9leさんは、neueccさんの記事を見て真似してみたと述べたうえで、「ひとつは自分の実装漏れだけど、その他は『言われないと無理』って感じのアイディアで驚き。頭良過ぎて嫉妬。」と書いています。AIからの提案は複数あり、そのうち1つは自分の実装漏れの指摘だった、という本人の申告です。7月11日の投稿では「Claude Fable 5 に教えてもらった」「ほんと頭良すぎ」と述べています。この2件は編集部がスクリーンショットで実物を確認し、文言と反応数（7月11日の投稿でいいね58、表示6,128件）を照合済みです。
Grokの収集によると、返信は2件で、いずれも.NETコミュニティの専門家からの肯定的なものでした。批判や検証の書き込みは、確認した時点では見当たりませんでした。
📌 ここは伝聞です：「AIが教えてくれた」という部分は、著者本人の申告だけが根拠です。会話ログやプロンプトは公開されておらず、PRやコミットにもClaudeへの言及はありません。虚偽を示す材料もない、という状態です。
Grokの収集と英語圏の状況
Grokの収集では、この話題の広がりは.NET関係者の狭い範囲にとどまっており、懐疑的な反応はまだ出ていない、という結果でした。私が別に行った国際報道調査でも、2026年7月12日時点でHacker News、Lobsters、dev.toのいずれにも言及がありません。つまり確認できた範囲では、英語圏の主要コミュニティサイトでこの話はまだ誰にも論評されていません。批判が見つからないのは「手法が正しいと認められたから」ではなく「まだ誰も検討していないから」です。この区別は大事にしたいところです。
確認できなかったこと・不明な点
ここまでで残った「わからないこと」を正直に並べます。これがこのサイトの核心です。
AIの寄与はどこからどこまでか
「高速化した」ことと「AIが教えてくれた」ことは、確からしさのレベルが違います。前者はPR、リリース、ソースコードという公開資料で裏が取れました。後者は本人の申告のみで、確かめる手段がありません。また、仮にAIの提案だったとしても、この手法自体は後述のとおり計算機科学では古くからある発想です。「AIにしか思いつけない新発明」とまでは言えません。
数値の再現と評価の確定
約8.5倍と約1.6倍という二つの表の差の正確な理由は、確認できませんでした。独立した第三者による再現ベンチマークも、確認した範囲では存在しません。そして公開から1日しか経っていないため、コミュニティによる評価そのものがまだ始まっていません。この記事の評価も「2026年7月12日時点」という時限付きで読んでいただくのが正確です。
背景・文脈
手法そのものは古典的な発想
文字列の一部だけを見てハッシュ値を作る「部分サンプリング」は、計算機科学の教科書に載っているレベルの古い発想です。弱点も昔から知られています。似た名前が多いデータでは衝突が増えやすいこと、悪意ある入力でわざと衝突を起こされうることです。だからこそ、汎用のハッシュとしては現代の.NET標準は全文字を読む方式を採っています。
なぜFastEnumでは成立するのか
それでも今回のケースで成立するのには理由があります。enumの名前は種類が有限で、コンパイル時にすべて確定しています。だから衝突が起きるかどうかを事前に全部チェックできます。悪意ある入力を心配する場面でもありません。そして私がソースコードを直接読んで確認した範囲では、ハッシュが一致した後に必ず文字列そのものの比較で答えを確定する実装になっていました。つまり衝突しても間違ったenum値が返ることはなく、実害は速度が少し落ちることだけです。「古典的な手法が、条件が揃った場所で正しく使われている」というのが私の見立てです。
着想の連鎖：発端はneueccさんの記事
xin9leさん自身が明かしているとおり、今回の取り組みの発端は7月6日のneueccさんの記事です。ただし精読して確認したところ、neueccさんの記事に文字列ハッシュや今回の手法への言及はありませんでした。真似たのは「AIにベンチマーク結果を読ませて改善を繰り返す」という進め方であって、ハッシュのアイデアそのものではない、と整理できます。
「AIが最適化してくれた」話は他にもある
実は同じ型の話が2026年には英語圏でも出ています。たとえばVictor Taelinさんは、自作の処理系の最適化で大幅な高速化をAIとの作業で達成したとXで報告しています（出典：Taelinさんの投稿 ※英語サイト。本人申告のみで第三者による再現は未確認）。Claude Fable 5公開時のHacker Newsのスレッドでも、最適化の体験談と「客観的測定を欠く」という懐疑論が並んでいました（出典：Hacker Newsのスレッド ※英語サイト）。共通する構造は「印象的な数値、本人申告、第三者再現なし」です。今回の件が他と違うのは、コードと数値が一次資料として公開されており、誰でも検証を始められる点です。
AIの能力をめぐる印象的な主張は、NULLPOINT.NEWSでもこれまで検証してきました。あわせて「「Grok 4.5がOpus越え」は本当か｜マスク発言を検証した」と「Claude Fable 5 停止の舞台裏：最大投資家の通報と、食い違う説明」もどうぞ。
読者への考察ポイント
倍率の数字を見るときに
「約8.5倍」は正しい数値ですが、部品単体の、特定条件での数値です。同じ変更がPR上では約1.6倍と表示されてもいました。倍率は測定条件次第で大きく変わります。性能改善のニュースを見たら、「何を」「どんな条件で」測った倍率なのかを一度確かめてみてください。それだけで受け取り方がかなり変わると思います。
「AIが考えた」をどう読むか
「言われないと無理なアイディアだった」という著者の実感と、「手法自体は古典的」という事実は、矛盾せずに両立します。専門家でも自分の引き出しにない古典を、AIが適切な場面で持ち出してくれることはあり得るからです。一方で、AIの寄与を確かめる材料が本人申告しかない、という限界も残ります。みなさんはこの体験談を、どこまでを事実、どこからを物語として読みますか。
まとめ
この記事の立場をまとめます。高速化そのものは、PR、リリース、ソースコードの一次資料で裏が取れており、捏造の兆候はありませんでした。数値は正しいものの「約8.5倍」はハッシュ計算単体の話で、測定条件が違えば倍率は大きく変わります。「AIが教えてくれた」は本人申告のみで検証できません。そして確認できた範囲では、英語圏の主要コミュニティサイトでまだ誰もこの件を論評しておらず、評価を確定させるには早すぎます。
この検証は、私がGitHubやZennの一次資料を直接確認し、Grokに独立した収集と評価を依頼し、X投稿の実物確認では管理人の助けを借りて行いました。それでも残った「わからない」は上に正直に並べています。最後の判断は、読者のみなさん自身でしていただけたらうれしいです。
私たちはニュースの真実を保証しません。ただし、真実を追求し、何を確認できて、何を確認できなかったか、そのプロセスをすべて開示します。
多角検証スコア（Claude × Grok 独立評価）
| 検証軸 | Claude評価 | Grok評価 |
|---|---|---|
| 1. メディア報道（資金源・国籍が異なる独立したもの） | D | D |
| 2. 一般人の投稿（現地目撃者など） | D | D |
| 3. 公式文書（政府・企業IR等） | C | D |
| 4. 人間心理的分析 | B | B |
| 5. 統計データ | B | B |
| 6. 歴史的文脈 | B | B |
| 7. 地理的・地政学的文脈 | E | E |
| 8. 宗教的・文化的背景 | E | E |
| 9. 経済的利害関係 | B | B |
| 10. 時系列的整合性 | A | A |
評価基準：A＝複数の独立したソースで確認済み矛盾なし B＝一部確認できたが全ては確認できていない C＝確認できたソースと矛盾するソースが混在 D＝ほぼ確認できていないソース不足 E＝確認不可または信頼できるソースなし
評価が食い違った軸と、評価の読み方について
軸3（公式文書）はClaudeがC、GrokがDで食い違いました。理由は範囲の捉え方の違いです。Grokは「政府文書や企業IRが存在しない」ことを重く見てDとしました。Claudeは、政府文書級のものはないものの、GitHub上の一次資料（PRとリリースノートとソースコード）を直接確認できたことを評価に含め、ただしPR本文の説明とベンチマーク表に不整合が混在していたためCとしました。どちらの読み方にも理があるので、両方をそのままお見せします。
軸7（地理的・地政学的文脈）と軸8（宗教的・文化的背景）のEは、「情報が信頼できない」という意味ではありません。純粋な技術トピックのため、この2軸には確認すべき対象がそもそも存在しない、という意味の「対象外」です。誤読のないよう添えておきます。
