- NISTが策定した耐量子署名アルゴリズムであるML-DSAのGo実装で、署名検証が失敗する問題が発生
- Claude Code v2.0.28が、テストコードとソースパスだけで複雑な低レベルバグを迅速に特定
- 原因は、
Verify段階でw1の上位ビットを重複計算していた関数統合時のミスだった
- 続く2回目の実験でも、ClaudeはMontgomery定数の計算ミスと署名長の不一致バグをそれぞれ発見
- 3回の試行すべてでバグの特定に成功し、AIの低レベルデバッグ活用の可能性を示した
ML-DSA実装と初期の問題
- 筆者は、NISTが策定した**ML-DSA（Post-Quantum Signature Algorithm）**をGo言語で新たに実装
- 4日間のライブコーディング後、テストでVerify関数がすべての署名を拒否する問題が発生
- テストログには
invalid signatureエラーが繰り返し出力された
- 疲労のためデバッグを中断し、Claude Codeに問題分析を依頼
Claude Codeの最初のデバッグ
- Claude Code v2.0.28（モデル Opus 4.1、システムプロンプトなし）に次の情報を提供
- テスト実行コマンド（
bin/go test crypto/internal/fips140/mldsa）
- コードの場所（
src/crypto/internal/fips140/mldsa）
- 「署名が常に拒否される」という説明と、「w1が異なる」というヒント
- Claudeは数分で完全な修正提案を返した
- 原因は、
HighBitsとw1Encodeを1つに統合した後、Verifyで既に上位ビットを生成していたUseHintの結果に対して再び上位ビットを取っていたこと
- つまり、w1の上位ビットを2回計算していた構造的なミス
- Claudeはコードを読み込んだ直後に原因を把握し、自前のテストを書いて仮説を検証
- 提案された修正は完璧ではなかったが、核心原因の把握によってデバッグ時間を短縮
- その後、筆者は
w1Encodeをリファクタリングし、上位ビットを入力として受け取る構造に変更、Montgomery表現への変換工程も短縮
2回目の実験: 署名生成段階のバグ
- 署名生成実装でもテスト失敗が発生
- 1つ目のバグ: Montgomeryドメインでの定数（1、-1）の計算ミス
- 見つけにくい問題で、多数の
printfと推測が必要になり、約1〜2時間を要した
- 2つ目のバグ: 署名に含まれる値の長さミス（32ビットではなく32バイト）
- 筆者はこの2つのバグがClaudeの性能検証に適していると判断し、以前のバージョンのコードでClaude Codeを再実行
Claude Codeの2回目のデバッグ結果
- 最初のプロンプトでClaudeはprintfデバッグと値追跡を行い、誤った定数を見つけて修正
- 処理時間は人間より短く、テスト失敗の原因を正確に特定
- 2つ目のプロンプトでは署名長の不一致問題を発見
- Claudeは複数の経路を探索した後、割り当て長だけを修正する提案を提示
- 提案された修正は完璧ではなかったが、核心的なエラー箇所を正確に指摘
- 3回の独立した試行すべてで、Claudeが正確なバグ原因を単独で発見
AIデバッグの効率性と示唆
- Claudeのアプローチは、テスト失敗の原因探索に特化した自動化アシスタントとして有効
- ユーザーはClaudeの修正案をそのまま適用せず、バグ箇所の確認後に自分で修正
- 筆者は「テスト失敗時に自動でLLMが原因を分析して知らせるツール」の必要性に言及
- 単純なチャットや自動PR生成よりも、テストベースのデバッグエージェントの形が理想的だと評価
支援およびその他の情報
- 筆者のオープンソース保守はGeomysを通じて支援されており、
Smallstep、Ava Labs、Teleport、Tailscale、Sentryなどがスポンサー
- Ava Labsは、暗号プロトコルの持続可能なオープンソース開発の重要性を強調
- Teleportは、ユーザーアカウント乗っ取り防止とアクセス制御強化のためのTeleport Identityプラットフォームを紹介
付録: 画像と個人的な言及
- 記事には、**Microsoft Officeのクリッピー（Clippy）**が「w1の上位ビットを2回取ってしまった」と吹き出し付きで登場
- 最後には猫の写真が含まれており、AIをめぐる感情的な議論を和らげるユーモアとして提示されている
2件のコメント
最近、
tritonやcudaを使って GPU カーネル開発を少しやっているのですが、3.5 まではまともに動くものをあまり見られなかった一方で、4.5 ではある程度ちゃんとしたコードや最適化をしてくれるのが見えるようになりました。Hacker Newsのコメント
コーディングエージェントを使ってバグの 根本原因 を追跡するやり方は、かなりうまく機能する
3回のワンショットデバッグはすべて成功した。LLMがコードを直接修正するのではなく、自分で判断して直せるように バグの位置だけを教えてくれる補助役 として使うのが核心だ
こうしたアプローチはLLM懐疑派にとっても良い出発点になりうる。コードを代わりに書かせるのではなく、厄介なバグを見つける役割だけ任せればいい
「これを直すべきだ」という提案自体は間違っていなくても、核心とは無関係な場合が多い。結果として不要な修正提案が積み上がり、ジュニア開発者がそれをそのまま反映すると 無駄な作業 ばかり増える
自分もこうしたツールを使うが、しばしば「ジュニアに説明するせいで、かえって時間がかかる」感覚になる
テスト生成もアルゴリズム系はうまいが、並行処理の状況では限界がある。それでも「テスト生成」や「デバッグ」用途としては十分価値がある
コードのリファクタリングや長期保守の観点では、まだ不十分だ
ただ、ブログで勧められていた通りバグハンターとして使ってみると、驚くほど効果的だった。数週間で複数の 本番環境のバグ を捕まえた
コードを本格的に掘る前に関連文書を長めに書かせてみると、間違いがあっても負担が小さく、懐疑的な人にとっても良い入り口になる
この過程を機械に任せてしまうのは惜しい気がする。バグハンティングはシステム構造を深く理解させ、長期的にはより良いプログラマへと成長させてくれる
こうした経験がないと、結局は自分のコード判断さえLLMに依存してしまう危険がある
私の助言はただひとつ、AI First だ
まずAIに問題を投げてみれば、モデルの限界を学べると同時に プロンプトを構造化する能力 も鍛えられる
最新モデルはほとんどの問題で同僚のように扱えるほど強力だ。ただし、失敗パターンを理解して直感を蓄えることが重要だ
新しいモデル世代が出るたびに既存のプロセスを捨て、GPT-5-Codex や Sonnet 4.5 のような最新モデルで実験してみることを勧める
ドメインの専門家ならLLMの 幻覚や誤り を見分けられるが、そうでなければむしろ時間の無駄になる
結局こうしたツールは 専門家にこそ最も有用 であり、初心者にとっては品質にばらつきがある
自分も Sonnet 4.5 を使ってみたが、前のバージョンより少し良くなった程度だった。相変わらず 時間の無駄 になることが多い
Anthropic が数か月間、私に Claude Max を無料で提供してくれた
最近はInstagramの広告でもClaude関連のコンテンツがあふれている。「Claude Codeのインストール」といった広告が繰り返し出てくるのを見ると、マーケティングチームは本当に熱心に動いているようだ
開発者がClaude Codeを非常に有用だと感じていて、月額200ドルの契約も多い。収益性があるならマーケティングに資金を注ぎ込むのは当然だ
LLMはバグを見つけるときに役立つ一方で、的外れな説明 を出して時間を無駄にさせることもある
結局重要なのは、批判的思考を保ち続けることだ
LLMは優れたツールだが、早計な結論 を出しがちだ。人間が考えるのをやめた瞬間、モデルは見当違いの方向へ走っていく
「LLMをチャットや自動補完の形でしか使わないのは微妙」という意見に共感する
自分も Claude Code/Codex を使って初めて可能性を感じた。継続的に実行されるモードがあれば、さらに面白くなりそうだ
うっかりファイルを消したり、Gitリポジトリを壊したりするかもしれない。だから私は サンドボックス環境 でしか試していない
モデルがこちらに質問し、自分が直接介入しながら学べる ソクラテス式 の協業ツールを求めている
今の「自動化中心」のアプローチは、開発者をコード文盲にしてしまう危険がある。逆にうまく設計すれば、理解と直感を増幅するツール にもなれる
CLIターミナル は今でも強力なインターフェースだ
Gemini CLI や Qwen Code は無料で、OpenAI互換APIも簡単につなげられる。
単純な作業は自動化し、難しい部分は Grok でワンショット処理すれば効率的だ。CLI + MCPサーバー + MDファイルだけでも賢いプログラムを作れる
テストが失敗するたびにLLMが自動で原因を分析するというアイデアは興味深い
Git hook を使って Claude CLI を実行すれば可能だ。
例とチートシートは このガイド で見られる
近いうちに、LLMの学習データに対する敵対的攻撃 によって暗号学的な誤りを誘発する事例が出てきそうだ
「修正がまったく新しい関数の追加を含む」というのは、暗号実装 では危険に感じる
この記事は誤った助言を与えているように思える
修正コードは捨てて、人間が直接書いていた。むしろ 保守的で責任ある活用 の事例に見える
LLMは「修理工」ではなく ガス漏れ検知器 のように、問題の場所を知らせるツールとして使うのが正しい
LLMはコードの 曖昧なパターン を認識して、退屈な問題をたくさん取り除いてくれた
ただし、これが 副作用 になることもある。自分のコードベースは Node.js のように見えるが実際にはそうではないので、モデルがずっと Node のプロジェクトだと誤認する