実験ノート：Claude Code 2.0でxsdからxmlを作る
Claude 4.5 Sonnetが、発表され、Claude Codeも2.0になった。どれだけの実力か。
お題はxsdからカバレジの高いxmlを作る
既存のcoverageを計算するプログラムが、中途半端でうまく動かいのでこれを修正するところからスタート。いつものとおりinstructions.mdを書く。
xsdを使って、xsdに合っているxmlファイルを複数あるとき、どれだけxsdの定義をカバーしているかを計測したい、要素カバレッジと属性カバレッジを取りたい、ただし、要素も属性も、xmlの階層構造を考慮する必要がある、同じ要素であって、複数の階層の異なる場所に登場すれば、それは別のものとして数える、属性も同様に直上の要素がある場所に応じて分けて考える。それぞれ要素パス、属性パスとして区別する。
既存のコードをテストその１、テストその２の出力を確認し正しさを検証し、間違っている場合はこれを修正しほしい。
要素パスカバレッジの全数の数の根拠や、属性パスカバレッジの全数の根拠も説明すること。
最初に、既存の間抜けなアルゴリズムを実行。
生成された、カバレッジの説明。
属性パスはこうなる
要素パスの全数の算出の根拠
属性パスの全数算出の根拠
カバレッジ修正の結果
テスト１、テスト２ともカバレッジが低い。。。
貪欲法によるカバレッジの高いxmlの生成
、xsdからカバレッジの高いxml群を生成する機能を作ってほしい、testファイルでそれぞれ検証し、既存のxml群との比較をする。
生成されたアルゴリズムは、Set-Cover問題を使った貪欲法
結果は、大幅な改良ができた！しかし、ISO IEC62474 Schemaは、カバレッジが50%強か。。。
SMTをつかったアルゴリズム
ということで、もっと斬新なカバレッジの案を出してもらう。plan modeに切り替えて。。
もう一つ、斬新なカバレッジの高いxml群生成アルゴリズムを考えてほしい。
提案1: パス依存関係グラフベースの階層的生成アルゴリズム
提案2: 進化的多目的最適化 (NSGA-III)
└カバレッジ、ファイル数、可読性など複数の目的を同時に最適化する遺伝的アルゴリズム。
提案3: 強化学習ベースの逐次決定アルゴリズム
└ XMLの構築を逐次決定問題として定式化し、Q学習またはDeep Q-Network (DQN)で最適方策を学習。
提案4: 制約充足問題 (CSP) + SMTソルバーベース
└ カバレッジ最大化を論理制約の充足問題として定式化し、Z3などのSMTソルバーで最適解を求める。
提案5: モンテカルロ木探索 (MCTS) ベース
└ XMLの構築をゲーム木の探索として定式化し、AlphaGoで有名なMCTSで最適な構築手順を発見。
おお、さすがに、4.5 Sonnet、小難しいアルゴリズムを持ってくるわい。いづれも、修士レベルの実装能力が必要な気がする。どれも魅力的だ。
ここでは、提案4SMTソルバーを選択
各アルゴリズムの比較表
| アルゴリズム | カバレッジ期待値 | ファイル数 | 実装難易度 | 実行速度 | 説明可能性 | 新規性 |
|--------------|----------|-------|-------|-----------|-------|------|
| 現在（セット被覆） | 85-90% | 1-3 | ★★☆☆☆ | 速い | 高 | 低 |
| 提案1: グラフベース | 90-95% | 2-4 | ★★★☆☆ | 速い | 非常に高 | 中 |
| 提案2: 進化的最適化 | 90-95% | 1-5 | ★★★★☆ | 遅い | 中 | 高 |
| 提案3: 強化学習 | 95-98% | 1-3 | ★★★★★ | 非常に遅い（学習） | 低 | 非常に高 |
| 提案4: SMTソルバー | 100% | 最小 | ★★★★☆ | 中 | 高 | 高 |
| 提案5: MCTS | 92-97% | 1-4 | ★★★★☆ | 遅い | 中 | 高 |
| 提案6: ベイズ最適化 | 85-95% | 1-3 | ★★★☆☆ | 中 | 中 | 中 |
その基本アイデアはこちら、SMTソルバ最高！
あっという間に完成、カバレッジ高すぎ！
評価１：簡単な例
さすがに100%だ。
評価2:ISO IEC62474 Schema
要素カバレッジ、１ファイルで100%？本当か？？
Limitが来た
Readme.mdとか作ってもらってたら、Limitがやってきた。3時間待てばよいのか？
コスト
コストをここにのせる。Sonnet-4-5が動いていることがわかる。$4.24でリミットが来たことになる。
追記：choice要素が考慮されてない？
一晩寝て(limitの刑が終わって）考えた、
choice要素がある場合は、複数のxmlの生成が必要であるという理解は正しいか？
やはり、複数ファイルが必要になるのか。ただ、テストファイルにxsd:choiceが含まれてないのでさぼったのか。。
ああ、実装してないと。。。4.5 Sonnetになってもさぼる性質は変わらないのか。
そして、ユーザーの理解は正しく、実装が不足だそうだ。。
他のことも気になりだした。。
xsdを単にカバーするという観点と、生成されたxmlは下流のソフトウエアのテストデータであるという観点にわけると、後者の
場合ははchoiceと同様にminOccurs="0"の要素や、optionalの属性は有無により実質的なchoiceと同じになり、複数のxmlが必要な
のではないか？
答えはこちら、
そうでしょうそうでしょ、そして組み合わせが発生する、そして組み合わせが爆発する。
天文学的数字。。。なので、現実的な戦略は、
なるほど、全部ありと全部なしの２パターンを作るというのが最も単純（戦略１）、そして、一つづつあり無しにする（戦略２）、
それから、戦略３では、ペアの組みわせを作る。これはテスト的にはいい感じだが、数が。。増えてゆく。
そして、結論。
なるほどね、現実的な改良ってのが必要なのね。。やってみるか。。
pairwiseを実装してもらった
カバレッジは上がった、複数ファイルが必要だった。大規模データではタイムアウトで動かなかった。。つづく。
追記：いろいろ格闘した記録
夜な夜なclaudeを動かして修正している、カバレッジれのレポートをみて怪しいと思うところがあればこれを指摘して、原因を探したり、そういうのが続く。
pairwise coverageで最後にxmlを生成するところが、validなxmlを生成できない。
上記を修正するも、行ったり来たりでらちが明かない。
opus4.1（有料）にスイッチして実行、こいつはじっくり問題解決してくれた。
xmlにあるのにxsdにない要素があるとcoverageが報告、良く調べさすと、外部xsdを参照しているところ？があるという
そこを外しても、さらにcoverageを計算するときの深度の制限でそうなることが判明。
深度を深めること指示
不具合調査を依頼すると、昔の消し忘れのフォルダを調べ出した、過去履歴が残っているわけではないらしいだから、Serenaとかが大切なのね。
→ESCで止めて、そのフォルダは無視してと要請
pairwise xml generationで、要素数が多くなると、デフォルトで300個に制限して計算していることが発覚、それでも結果はカバレッジ100%と言っている。。本当は1781個もあるのに。。
オプションで上限を変更できるように修正、終わらなくなった。。。←今ここ
むう、やっぱり、さぼるというか、ちゃんと出力みて、ツッコミ入れたり、概算でよいので、数の検算をさせたりしないと信じられん。。履歴というかそいうのをちゃんと配慮するというのができてない、SerenaとかVibeKanbanとかが役に立つはずだ。
４晩を費やし、途中Opus4.1の助けも借りて、まあなんとか形にはなったかな。いやそろそろ、Proユーザーの利用制限が近づいた。
