先日、バックエンド開発をしている友人と食事をしたとき、彼は「最近AIがコードを書くのがチートみたいになってる。以前は半日かけて調整していたインターフェースも、今では数秒で出してくれる」とこぼしていました。しかし面白いことに、最近はむしろXMLのフォーマットに費やす時間が増えたそうです。それを聞いて私は笑ってしまいました。そんなものは10年前からある骨董品じゃないか、どうして逆襲しているんだ？と。
ところが彼がプロジェクトファイルを見せてくれて、私は黙りました。それはマイクロサービスの設定で、AIが生成したコードのロジックには問題ありませんでしたが、中のXML設定はまるで猫がキーボードを踏みつけたかのようでした——インデントはバラバラ、タグのネストは実の親でもわからないほど入り組んでいて、コメントとコードが混ざり合っていました。彼曰く、これでもまだマシな方で、時にはAIが名前空間を失くしたり、属性値の引用符を間違えたりして、サービスが起動しなくなることもあるそうです。
そんな時、XMLフォーマッターが命綱になります。この機能は単純に見えますが、実際にやっていることは非常に重要です。まず、あのぐちゃぐちゃな絡まりを整理し、タグの階層を一目でわかるようにして、人間の目で追えるようにし、問題が起きたときに素早く特定できるようにします。次に、スタイルを統一します。AIが生成するものは、時には2スペースのインデントを使い、時には4スペースを使い、属性の順序も気まぐれです。フォーマッターを一度実行すれば、プロジェクト全体がすぐに整います。
さらに重要なのは、XMLはJSONほど寛容ではないということです。JSONはフォーマットが間違っていてもせいぜいパースに失敗するだけですが、XMLはタグが閉じていなかったり、属性に引用符が欠けていたりすると、まさに全体に影響を及ぼします。AIがコードを書くのは速いですが、XMLのような強い構造を持つものに対しては時々混乱することがあります。特にDTDやSchemaの検証が関わる場合です。そんな時、フォーマッターを一度通すことは、静的チェックを一度行うことに相当し、多くの低レベルなミスを事前に防ぐことができます。
もう一つ面白いシナリオは、設定ファイルのマージです。最近の多くのプロジェクトでは、AIがK8s設定、Spring Bean定義、Androidレイアウトファイルの生成を支援しており、異なるソースからのXML断片を組み合わせると、インデントや名前空間がしばしば衝突します。フォーマッターはこれらの断片を再調整し、ファイル全体が一人の人間によって書かれたように見せることができます。
つまり、AIがコードを書くのが激しくなればなるほど、生成されるXMLは増え、そのXMLはますます整える必要が出てきます。フォーマッターはむしろAI時代のインフラストラクチャーとなったのです。台所で包丁が速ければ速いほど、まな板がより重要になるのと同じです。それはコードを生み出しませんが、コードを見られる、修正できる、保守できるものにします。これが、一見地味な小さなツールがAIの波の中でむしろ地位を確立した理由なのでしょう。