エージェントの入力UXに関して、ちょっとした提案なんだけど、チャットウィンドウを一つじゃなくて、タスク、コンテキスト、制約、出力フォーマットの4つに分けるといいかも。それと、長文じゃなくて、出力を考え方と内容、他のセクションに分けるのもアリだと思う。

いいところに気づいてるね。もっとメタな感じで、ユーザーが複数の出力ストリームをカスタマイズできるように動的に定義できるかな？

プロンプト用にXMLを知っておくのはいいと思うよ（出力に人気だったのと同じように、他のセクションでも使えるし）。でも、個人的にはJSONを書いて、改行やコロンを使ってセクションを区切る方がずっと良い経験があった。例えば、こんな感じで：...指示... 入力: .... 出力: {..ここにjson} ...さらに指示... 入力: {実際の入力} 使い道はドキュメント処理/抽出（HaikuとOpenAIモデル両方で）、後者の例はXMLよりずっと良く機能したよ。まあ、これは一つの使い道に関する体験談だけどね。

ちょっと確認したいんだけど、そのタグは実際に存在するタグで、使い方を学ぶ必要があるの？それとも、タグである限り、Claudeが特別な方法で理解してくれるの？

XMLはJSONよりずっと読みやすいよ。特にデータに意味のあるJSONの構文が含まれている場合はね。

XMLは役立つよね。a) 構造を説明できるし、b) 明確な文脈の変更を作ることで、「XMLで話してる」んじゃなくて「XMLについて話してる」ってわかるようになる。君の言う通り、JSONは冗長性が少ないフォーマットで、XMLで表現できる構造を表現できるし、AIが解析するのも簡単なはず。ただ、それはトレーニングデータにも依存するだろうね。最近、AIに.mdファイルがエージェントAIで広まってる理由を聞いたら、答えは… .mdファイルもヘッダーやリストのように構造を表現しているからだって。やっぱり、AIがどんなトレーニングを受けたかによるよね。私はJSONか、それにコメントを許可するバージョンがいいと思う。

余談だけど、HTMLのどんな特性（それとも今使ってるBraveブラウザのせい？）で、言葉が変なところで分割されるんだろう？「検査」デベロッパーツールでは特に変なことは見えなかったんだけど。（編集：Chrome、MS Edge、Firefoxも同じことしてる。全部リンクになってるのも関係あるのかな。）https://i.imgur.com/HGa0i3m.png

タグに関するCSS: word-break: break-all;

CSSのword-breakプロパティ

これはサイトのCSSのエラーだね。CSSには、言語に応じて単語を正しく分けたり、ハイフンを使ったりする方法があるのに。正しい呪文を思い出せないけど、LLMには簡単だと思う。

Claudeに聞いてみる？

1. XMLは一番クリーンで質の高いトレーニングデータだと思う（特にPDF/HTMLと比べて） 2. それに従って、ユーザーがXML形式でセマンティックタグを提供すれば、最高のトレーニングアラインメント（つまり最高の結果）が得られる。ここでその主張を定量化してないのは残念だね。

なるほどね。

この記事の主旨は、デリミタがClaudeにとって重要なコンテキストを提供するってことみたいで、そのためにXMLを使うべきだということ。記事では、英語の組み込みデリミタである引用符についても言及していて、これはClaudeのトレーニングデータの一部としてトークンとして表現されてる。だから、教訓は単にプロンプトで引用符のようなデリミタを活用することじゃないの？この記事では、XMLが引用符より優れている点を示してないし、引用符が提供する曖昧さの解消が必要なシナリオでのXMLの優位性も示してないように思う。むしろ、示されているXMLタグはプロンプトのセクションを記述するためのショートハンドとして機能しているように見える（「このプロンプトの部分を特定の方法で扱う」）。これは便利だけど、著者が考えている懸念とは別の問題に対処しているように感じる。

でも、引用符が普通のテキストみたいに見えるのが気になる。引用を使う時は、やっぱり引用符が必要だよね。

ClaudeにとってXMLはちょっと特別で、一級品だね。ツール呼び出しにXMLを使ってるから：/path/to/file 100 50 Claudeはどんな区切り文字や擬似マークアップも扱えると思うけど、XMLの区切り文字の利点は、最後に区切り文字の名前を繰り返すことができることだと思う。内容が長い場合には助けになるんじゃないかな（人間には確実に助けになるし）。

Claudeには、関連するスニペットをペアに入れるって言っただけでかなり成功したよ。それはXMLでもないし、実際には必要なかった。シンプルな---の区切りでも十分良い結果が得られるし、どのアイテムが異なるのかがわかりやすければ大丈夫だよ。

> Claudeの現代的なアプローチと[...] 1998年からある技術であるXMLとの対比 まさかXMLを古臭い技術だと思う人がいるなんて、本当にそうなの？この記事の表現を見てると、そう感じちゃう。ちょっと変だよね。

そうだね。最近の子供たちは…

XMLはもう10年以上「古臭い技術」だよ。全盛期は2002年くらいだったかな。今は誰も自分の製品のXML機能を宣伝しないし（昔はみんなやってたけど）、新しいものとも思われてないし、成熟したものとも見なされてない。ただの時代遅れの企業向けのゴミ扱い。今の人気はJ2EEと同じくらいで、「10年前」と言ったら1999年を指す人には受け入れられてるけどね。

証拠を見る限り、XMLは一般の人々にはあまり人気がなかったって認めざるを得ないよね。ウェブのマークアップでは、業界としてXHTML（厳密にXMLだったHTML）を試してみたけど、結局定着しなかったし、今はHTML5があって、場合によっては閉じタグすら必要ないくらい緩いよね。データ交換に関しては、シンプルさからJSONが圧倒的に好まれているし、効率を重視するならprotobufやその仲間たちが使われてる。設定フォーマットとしては、YAMLやTOML、INIに圧倒されてるし、内容を重視した構文が受けてるんだよね。とはいえ、ClickHouseやAppleのlaunchd、ROSなど、XMLを使ってる人気のツールもあるけど、（例えば）HTMLに比べるとかなりニッチだよ。

XMLが古い技術だと思ってるなら、EDIのことを聞いたら驚くよ。今でもWalmartやAmazonの物流を支えてるからね。XMLは、あの厄介なEDIという暗号のようなペイロードを置き換えるために自己文書化の約束を持って登場した。XMLは世界の飢餓を解決すると約束したし、SOAPやXML over RPC、DOM、DTDを生み出した。全盛期は美しかったし、Microsoftが先頭を切ってた。C#もこの頃に登場した。コンサルティング会社は、非同期革命やXMLの緩やかに結合されたメッセージングの約束を提供するために花開いていた。私はそれが成功したと思うし、今は静かに倉庫の廊下でビールを飲んでる、古い従兄弟の電子データ交換（EDI）と一緒にね。

XMLはまだ存在してるけど、今の新しいプロジェクトで選ぶ人は少ないんじゃないかな。

修正されていないセキュリティの問題がいくつかあって、面白い悪用ができるかもしれないね。

XMLが復活してる、みんなターミナルを再発見してる。もうすぐオブジェクト指向プログラミングがまた良いってことに気づくかも。

XMLタグを使うベストプラクティスに従おうとしたけど、違いは全然わからなかった。正直、AnthropicがSonnet 3.xの頃のドキュメントからその部分を削除するのを忘れたんじゃないかな。今でもこの秘密のソースについてブログを書いてる人がいるし。

XMLは、XMLが出た時のPDP-11と同じくらい古いね。

XMLはXMPPにめっちゃ合ってるよね。KDLもそれに対応してるし。ただ、構造化データからMarkdownに移行するのが気になるんだ。Markdownって機能や構文が足りなくて、LLMたちが引用元を明示しないためにブロック引用を無理に使おうとしてるのがね。

これはXMLの実際に良い使い方のように思える。シリアライズフォーマットとして使うのは、なんかしっくりこなかった（すごく冗長だし、名前付きの閉じタグは文法的に不要だし、属性か子要素かの問題とか）。でも、LLMのプロンプトやレスポンスをマークアップして構造化するには、Markdownよりも良さそうだね（Markdownはストリーミングには向かないし）。

私は納得できないな。始まりと終わりのシンボルがさらに別の始まりと終わりのシンボルを含む可能性がある場合の扱いは難しいと思う。人間もこれをうまくできないし、インデントや構文ハイライトなどの視覚的な補助を使ったり、単純にレベルを数えたりするよね。もちろん、パラメータやトレーニングを問題に投げ込むのは簡単だけど、必要なXMLトレーニングデータを合成的に生成するのは簡単だし。トレーニングデータには、各コンテンツトークンごとにメタデータトークンが必要だと思う。リテラルテキストに表現されていない各トークンに関する既知の情報をエンコードする方法だね。特に、トークンをフィクション、コード、既知の作業プロジェクトからのコード、自分自身で生成されたもの、ユーザーから提供されたものとして明示的にタグ付けすること。苦い教訓に逆らうかもしれないけど、明示的に構造化されたデータには利点があると思う。メタデータがネストを処理できるように、深さを追跡するためのロープ操作を行う次元を含むことができればいいなと思う。トークンごとにそんなメタデータストリームがあれば、ユーザーによって「言われた」メタデータを持つ指示だけに従うように指示モデルを微調整する可能性もあるし、推論時にその特定のメタデータ信号を他の入力からフィルタリングすることもできる。そうすれば、プロンプトインジェクションがずっと難しくなると思う。

トランスフォーマーは、今どれだけ深く、何の中にいるかを追跡するのに完璧な技術に見えるね。

基本的に、ユーザーの入力とモデルのメタ入力を分ける唯一の方法は、ユーザーやLLMの出力には絶対に現れないような文字を使うことだよね。技術的には可能だけど、誰も気づかないうちにどこでも静かに更新しなきゃいけないようなユニコードの陰謀みたいな感じになるね。

でも、これってClaudeのコンテキストに入るもの全般に当てはまるべきなのかな？スキルやコマンド、カスタムサブエージェントなんかでもXMLを使うべきなのか？そうなると、Claudeに過剰にインデックスがかかって、複数のツールを使ってる人には他のモデルに悪影響が出るかも。AIの多くが「これをやれば結果が良くなる」って言ってるのが嫌なんだよね、確かな証拠もないのに。でも、非決定論的な部分もあるから仕方ないか。少なくとも、これはClaudeのコードチーム自体の承認を受けてるから安心かな。

すべてのシステムプロンプトは特定の役割マーカーでラップされてるから（各LLMには独自のフォーマットがある）、どのラボもデリミタやインバンドとアウトオブバンドの信号については知ってると思う。XMLマーカーがMarkdownよりも良い理由は明確じゃないけど、Claudeが明示的にXMLプロンプトでポストトレーニングされてるからかもしれない。一つの仮説としては、トレーニングコーパスの大部分がウェブサイトだから、XMLの構造をMarkdownよりもよく「学習」してるから自然に使いやすいのかも。もう一つは、明示的な開始/終了タグがJSON（マッチする括弧を数える必要がある）やMarkdown（新しいヘッダー要素の存在でセクションの終わりが暗黙的に定義される）よりもマッチするデリミタを特定しやすくするかもしれないってこと。