平均律とApple IIの色表現は、同じ「滲みの技術」で結ばれている。平均律は純正律のように倍音比に忠実ではなく、各音の周波数をわずかにずらし、十二音を等間隔に配置する。このわずかな歪みは、調性の純度を犠牲にする代わりに、どの調にも自由に転調できる可動性をもたらした。音楽の世界を均一な地図に写す──それはまるでメルカトル図法が地球を歪めて描くような操作である。音は完全ではなくなるが、世界はつながる。その歪みを聴覚的に感じるとき、私たちはそれを「滲み」と呼ぶほうが近い。
Apple IIの色も同じ構造を持つ。正確なRGBではなく、NTSC信号の副作用によって偶然に色を得ていた。走査線の干渉がもたらす色のにじみは、計算された錯覚であり、物理的精度よりも「表示できること」「動くこと」を優先した設計だった。純度を捨てて柔軟さを得る──平均律と同じである。どちらも理論の理想をわずかに崩し、その歪みを感覚的な連続性として受け入れることで、世界を滑らかに繋ぐ。平均律の響きもApple IIの色も、滲みの中に人間的な創造の自由を宿している。
熱は温度差に押されて、高温から低温へと移動します。エントロピーは増え、やがて全体がバランスに近づきます。資本も同じように考えられます。お金は利回りの低いところから高いところへ移り、競争が産業全体の利潤率を共通の水準へと押しならします。「最大エントロピー」という考え方も有用です。一定の制約がある中で、偏りの少ない全体パターンに近づく――市場が統計的な均衡を見つけていくイメージです。
ただし、これは厳密な物理法則ではありません。実際に均されやすいのはリスク調整後の期待収益です。参入・退出コスト、制度やルール、独占力、情報の不均衡、与信の制約、技術変化や需要の移り変わりなどが、この調整を遅らせたり歪めたりします。時間スケールも異なります。熱の拡散は物理定数に従いますが、資本の流れは制度・情報・信用に依存するため、超過利潤がしばらく残ることもあります。さらに経済には厳密な「保存則」がなく、信用創造や創造的破壊が前提そのものを変えていきます。
カントからソシュール／ヤコブソンに至る流れは、二元対立を「直交的構造」に転換した思想史の道筋として整理できる。カントは人間の認識を空間と時間という直交的な形式に基づく構成と捉え、経験を主観と客観の座標系上で可能にした。スピノザは精神と延長を対立させず、同一実体の二つの独立な表現とすることで、二元論を平行関係へと移し替えた。ボーアは量子論において波と粒子を排他的ではなく相補的な現象と見なし、観測条件ごとに独立軸が立つと考えた。カッシーラーは人間文化を神話・言語・科学などの象徴形式に分け、互いに干渉しない多軸的世界像を示した。ソシュールとヤコブソンは言語を通時／共時、連辞／選択という直交二軸で分析し、構造そのものを「座標」として捉え直した。こうして哲学的二元論は、互いに独立しながら世界を織りなす直交的構造へと転換された。
世界各地の神話・伝承や航海記録には、船上で鳥を見つけたり放ったりして陸地の存在や希望・生還を確信する描写が多い。以下、代表的な事例を挙げる。
メソポタミア・旧約聖書（洪水神話）: 『ギルガメシュ叙事詩』ではウットナピシュティム（ノアに相当）が洪水後に鳩や燕（つばめ）、最後に鴉を放ち、鴉が戻らなかったことから陸地到達を知るja.wikipedia.org。同様に旧約聖書『創世記』では、ノアが洪水収束後に鴉と鳩を放ち、３度目の鳩がオリーブの葉を加えて戻ってくることで「陸地の乾燥」を知る象徴的場面が描かれるja.wikipedia.org。これらではハト・カラスといった渡り鳥が神からの救済や新天地出現のシグナルとして働く。
インド・仏典ジャータカ物語: 紀元前から伝わるジャータカ説話（釈迦の前世物語）にも、航海で方位を探る描写がある。商人が「方見カラス（ディサカーカ）」という指導用のカラスを船に同乗させ、見えない陸地を探すため放つエピソードが知られるacademia.edu。この「方見カラス」はサンスクリット語で「コンパス・カラス」を意味し、船乗りに進むべき方向を示す役割を果たしたとされる。
古代ローマ／セイロン島: プルニウス『博物誌』（1世紀）にも、スリランカ（当時のタプロバンナ）付近の船乗りが陸鳥を航海に利用した記録がある。「水平線しか見えなくなると、陸鳥を放ってその行く先を追えば陸地にたどり着く」と記されるacademia.edu。高く舞い上がった鳥は陸を発見すると一直線に飛び向かうため、航法の一種として知られていた。
ポリネシア・太平洋航海術: ポリネシア航海士は鳥の習性を「航海の羅針盤」として用いた。ニワシドリ（シロアジサシ類）やオスリカケアジサシ（ノドジロアホウドリ）などは朝に沖へ出て夜に陸へ戻るので、航海中に朝と夜で鳥の飛行方向を追えば陸地位置を知ることができるen.wikipedia.org。また、オオグンカンドリ（フリゲートバード）のように水面に降りられない鳥を携行し、島が近付くと放すと、鳥が戻らなければ陸地へ向かった証とする方法も用いられたen.wikipedia.orgtourmaui.com。実際、ポリネシア人はこうした技術でイースター島を発見したとも伝えられる。伝承によれば、黒翅セグロアジサシ（ソティタイミーリー）の飛翔経路をたどってイースター島を見つけた例があるen.wikipedia.org。いずれも「群れで島に帰巣する鳥」に乗じて航路を修正した事例である。
北欧伝承（バイキング航海）: ノルウェーからアイスランド航海を試みたバイキング探検家ハフナ・フロキ（Hrafna-Flóki）は、航海中に3羽のワタリガラスを同船させ、放して道案内に使ったという。１羽目はフェロー諸島方向へ飛び、２羽目は船に戻ったが、３羽目のカラスがまっすぐ飛び去った方角に新天地（アイスランド）があったとされるviking-store.com。北欧神話で知識の鳥とされるカラスを用いるこの方法は、伝承上「海上の目印」として機能した例であるviking-store.comda.lib.kobe-u.ac.jp。
大航海時代の記録: 15～16世紀の大航海時代にも、鳥の観察は重要な航海術だった。コロンブスは1492年の大西洋横断で、9月に海鳥（ペリカン、熱帯アジサシ類など）を多数見つけ、その動きから上陸間近と判断した。航海日誌には「南に向かう熱帯の小鳥４羽が船に寄ってきた。これは陸地の明確な徴候だ」と記しておりloe.org、「陸地から25リーグ以内しか飛ばないシギ類」や「海では寝ないトロピックバード」などが現れたことを根拠にしているloe.org。これらの鳥も、群れで海岸付近に留まる性質から、遭難しかけた船員に希望と進路指示を与えた。
文学・伝承・民話の例: 冒険譚でも同様のモチーフが登場する。『千夜一夜物語』のシンドバード航海記では、第二の航海で巨大な幻鳥（ルフ鳥）が主人公をダイヤの峡谷に運び、続いて大鷲が陸地へ連れて行く場面があるminpaku.repo.nii.ac.jp。ルフ鳥（鷹型伝説鳥）や大鷲は絶望的な漂流からの救済者として描かれ、陸地への到達と生還を象徴する役割を果たしているminpaku.repo.nii.ac.jp。※その他、小説『ヤコブ一家の冒険』（Swiss Family Robinson, 1812年）などでは、遭難者が海岸でカモメの群れを見つけて浅瀬に気づく描写がある（例: 大量のカモメを発見し付近に島影を見つける）など、近代冒険文学にも鳥が「希望のサイン」として登場する例がみられるenotes.com。
以上のように、ハト・カラス・燕・アジサシ・フリゲートバード・ワタリガラス・大鷲など、地域ごとのさまざまな渡り鳥や海鳥が「陸地や安全地帯」の象徴として機能している。多くの場合、鳥は遠洋での孤立した人々にとって唯一の視覚的手がかりとなり、新たな陸地発見や生還の希望を意味するモチーフとなっている。
参考資料: 洪水神話や航海記録には鳥による陸地発見譚が繰り返し登場するja.wikipedia.orgja.wikipedia.orgacademia.eduacademia.eduen.wikipedia.orgen.wikipedia.orgviking-store.comloe.orgminpaku.repo.nii.ac.jp。各事例の詳細は上記出典参照。
シャノンはノイズを定義しなかった。これにより情報理論は意味から完全に切り離され、記号の伝達効率のみを扱う純粋な形式科学として成立した。ノイズは原因も内容も問われず、ただ確率的なゆらぎとして扱われる。この「非定義性」こそが、理論をあらゆる領域に応用可能にした源泉である。ベルクソンの哲学では、時間や意識は「持続」として定義不能な流れに宿る。彼にとっても、概念化を拒むものが真の創造の場であった。シャノンがノイズを排除せず、あくまでチャンネルの一部として計測したように、ベルクソンもまた、意識の流れを分節化せず全体として捉えた。両者に共通するのは、「定義しないことによる強度」である。ノイズは誤差ではなく、秩序の成立を支える余白であり、思考の外縁で光る測定可能な無知として、理論を閉じながら世界を開く。
漱石と吉本はいずれも「心的現象」を扱いながら、その内部でFとfの直交構造を描いた。Fは社会的・制度的な指示の次元、fは情動や衝動といった自己の一次的運動である。漱石の文学論では、感情の流れ（fₛ）が文体や語彙規範（Fₛ）と交差することで美的均衡が生まれる。リズムや比喩はこの交差角を微細に調整し、読者の知覚に「媒質化された心」を生じさせる。吉本隆明の表出理論でも、自己表出（fᵧ）と指示表出（Fᵧ）は互いに独立な基底として設定され、美とはその二つの力が過剰にも欠損にもならず共鳴する帯域に現れる。両者に共通するのは、F⊥fという直交構造を動的に保ちつつ、表出＝E(F,f)を時間的に最適化する点である。美はFとfの和でも差でもなく、両軸の張力がつくる照度、すなわち「意味が成立しかける瞬間」の輝きとして立ち上がる。
技術者の間でまれに「HTMLはコンテナ言語である」という表現が使われることがあります。本レポートでは、この「コンテナ言語」という用語が登場した背景を探り、HTMLの正式な分類との関係、そして用語の混乱や技術的妥当性について詳しく検討します。
「コンテナ言語（container language）」という表現は、過去の一部文献や記事でHTMLの特性を説明する際に使われたものです。例えば、1996年の米国沿岸警備隊の機関誌に掲載された記事では、HTMLについて「 HTML is a container language. It has a very simple two-dimensional representation... HTML is a sequential one-dimensional representation of two-dimensional containers. It always takes two tags (a tag set) to identify a container. If the closing tag is left out, the container extends to the end of the document.（HTMLはコンテナ言語である。二次元コンテナを一次元で表現しており、常に開始タグと終了タグのペアでコンテナを識別する。終了タグを省略すると、そのコンテナは文書の終わりまで続いてしまう） 」と解説されていましたdco.uscg.mil。このように、HTMLのタグで囲む構造を「コンテナ」にたとえて説明する用例が存在したのです。
Wikipediaでも一時期、「HTMLは広く使われているマークアップ言語だが、一部の計算機科学者はその地位に異議を唱え、HTMLはコンテナ言語に当たると主張している」という旨の記述がありましたlandsurvival.com。これは、HTMLではタグの配置に制約があり「他のタグの内部に完全に入れるか、文書全体を覆うルート要素として配置する必要がある」ためであり、そのような厳格な入れ子構造（階層モデル）に従う言語を指して「コンテナ言語」と呼べる、という主張でしたlandsurvival.com。Wikipediaの当該記述には出典が付けられており、主に文書構造の理論を研究する研究者たちによる見解をまとめたものでした。具体的には、SGML/XML系のマークアップ言語が前提とする「入れ子木構造（階層構造）の制約」に着目し、HTMLはタグを重ねて（オーバーラップして）使えない＝入れ子コンテナでしか構造を表現できないことから、従来のマークアップ言語とは異なるカテゴリとして位置づけようとする文脈で使われた表現ですlandsurvival.com。
まず押さえておくべきは、HTML (HyperText Markup Language) はその名称が示す通り「マークアップ言語」に分類されるのが一般的だという点ですen.wikipedia.org。W3CやMDNなど標準的な技術文書でも、HTMLは「ウェブページの内容と構造を定義するための標準的なマークアップ言語」であると明記されていますen.wikipedia.org。実際、MDNの解説でも「HTMLはウェブのもっとも基本的な構成要素であり、マークアップによってテキストや画像などのコンテンツをブラウザに表示するために記述する」ものだとされていますdeveloper.mozilla.org。要するに、HTMLはタグ（markup）を用いて文書の構造を示す言語であって、プログラミング言語ではないし、「コンテナ言語」という分類も一般的ではありません。
「コンテナ言語」という用語は、公式な技術分類としては広く認知されていません。例えば、プログラミング言語、マークアップ言語、スタイルシート言語（CSS）といったカテゴリは一般に使われますが、「コンテナ言語」は主要な技術文献やリファレンス（W3C勧告やMDN Web Docsなど）ではほとんど登場しません。実際にHTMLを説明する際にも、「コンテナ言語」という表現はMDNやW3Cでは用いられておらず、そのような分類法は標準的でないことがわかりますdeveloper.mozilla.orgen.wikipedia.org。このことからも、「コンテナ言語」はあくまで一部の文脈で使われた説明的な言葉であり、HTMLの正式なカテゴリを表すものではないといえます。
「コンテナ言語」という言葉が生じた背景には、「コンテナ」という語の多義性による混乱も考えられます。Web技術の文脈で「コンテナ」という言葉は様々な意味で使われているため、用語が混乱しやすいのです。以下に主な例を挙げて整理します。
HTMLにおけるコンテナ要素: HTMLでは、ある要素が他の要素を内包する場合、その外側の要素を「コンテナ」と呼ぶことがあります。例えば「ブロックレベル要素は親要素（コンテナー）の範囲全体を占有する」という記述があるようにdeveloper.mozilla.org、親要素＝コンテナという意味合いです。また、<div> のように中に他の要素やテキストを入れるための要素を「コンテナ要素」と呼ぶケースもあります。さらに、HTMLの解説では従来から**「コンテナ・タグ」（開始タグと終了タグで囲むタグ）と「空要素（エンプティ・タグ）」**を対比する用語もあり、開始・終了タグで囲むものを総称して「コンテナ」と表現することもありますgeeksforgeeks.org。このように、HTMLのタグ構造自体にコンテナという言葉を用いることがあるため、「HTMLはコンテナ言語だ」という表現を耳にすると、何か正式な分類名であるかのような誤解を生む恐れがあります。
CSSにおけるコンテナ（コンテナクエリ）: 最近のCSSには コンテナクエリ（Container Query）という機能が導入され、「コンテナ」という概念が登場しました。CSSの@containerルールやcontainerプロパティは、特定の要素をレイアウト上のコンテナ（クエリコンテナ）として指定し、その大きさに応じてスタイルを適用する仕組みですdeveloper.mozilla.org。例えばCSSプロパティのcontainerは「要素をクエリコンテナとして確立し、コンテナクエリで使用するコンテナコンテキストの名前と種類を指定する」ものですdeveloper.mozilla.org。この場合の「コンテナ」はHTML全体ではなく、個々の要素に対するレイアウト上の概念です。コンテナクエリの文脈で「コンテナ」という言葉が頻出するため、これと混同してHTML自体を「コンテナ言語」と呼ぶのは誤りですが、用語の響きが似ているため初心者には混乱ポイントとなりえます。
フレームワーク等での.container: Webデザインのフレームワーク（例えばBootstrapなど）では、しばしばクラス名や概念として「コンテナ」が使われます。Bootstrapでは.containerというクラスが基本的なレイアウト要素として定義されており、「デバイスやビューポートに応じてコンテンツに適切な余白を与え、中央に整列させる」ための囲み枠として機能しますgetbootstrap.jpgetbootstrap.jp。ドキュメントにも「コンテナは内部にコンテンツを格納したり、適切な余白を与えたり（場合によっては中央に配置したり）するために使われます」と明記されていますgetbootstrap.jp。このように、フロントエンド開発では「コンテナ=レイアウト用の入れ物」の意味で広く使われており、HTMLそのものの分類とは無関係です。しかし、コンテナという言葉自体は日常的に使われるため、「HTMLのコンテナ」という表現が独り歩きして「HTMLはコンテナという種類の言語？」と混同する要因になっている可能性があります。
以上のように、「コンテナ」という語は文脈によって指す対象が異なるため、「コンテナ言語」という言い回しも人によって受け取り方が違ってしまいます。本来は先述のとおり特定の文脈（HTMLの入れ子構造の厳格さを強調する文脈）でのみ意味を持つ言葉ですが、他のコンテナ概念と混ざりやすい点に注意が必要です。
前述のように、HTML（およびXML由来のマークアップ言語）は要素の入れ子（ネスト）構造によって文書の構造を表現します。あるタグを開始したら、その内部で別のタグを開始した場合、後から開始したタグを先に閉じることはできません（例えば <b><i>テキスト</b></i> のようにタグが交差して閉じることはHTMLでは許されず、必ず <b><i>テキスト</i></b> のように入れ子が正しく閉じられる必要があります）。このようにタグを完全に入れ子にする規則はHTMLの設計上の制約であり、文法上もブラウザのパーサ実装上もそれが前提となっていますlandsurvival.com。先のWikipediaの記述で一部の研究者が「HTMLはコンテナ言語だ」と述べた背景にも、この厳格な入れ子階層モデルがありますlandsurvival.com。
しかし文書構造全般の議論として見ると、世界中のあらゆる文書構造が単一の階層（ツリー）で表せるわけではないという問題が存在します。例えば、文学作品や劇作、詩などでは、ページや行といった物理的区分と、文法的・物語的区分（章・節・文・セリフなど）が重なり合うことがあります。こうした**重なり構造（overlapping structure）**は、純粋な入れ子構造では表現が困難です。この課題は「重なりマークアップ（overlapping markup）」として知られており、XMLベースのスキーマでは直接扱えない問題として古くから指摘されてきましたen.wikipedia.org。
Text Encoding Initiative (TEI) のような文書エンコーディングの業界標準でも、XMLを基盤としているため、詩の「行」と「文」の境界がずれて重なるようなケースを直接には表現できませんen.wikipedia.org。そこで、いくつかのアプローチが考案されています。代表的なものとしては、以下のような方法がありますen.wikipedia.orgen.wikipedia.org。
マイルストーン（milestone）要素: 開始タグと終了タグを設けず、テキスト中の位置を示すだけの空要素を使い、重なり構造の区切りを表現する方法ですen.wikipedia.org。例えば、段落の途中に「ここから詩行開始」「ここで詩行終了」といったマーカー要素を差し込むことで、入れ子構造を壊さずに重なりを表現します。ただし、この方法ではXMLパーサーはその特別な意味を解釈できず、あくまで人間や専用ツールがそれを意味づけする必要がありますen.wikipedia.org。
スタンドオフ（stand-off）マークアップ: テキスト本体とは別の場所（別ファイル等）にマークアップ情報を持たせ、テキスト中の位置（オフセットやID）と対応付ける方法ですen.wikipedia.org。これにより、テキストと構造マークアップを分離し、複数の異なる構造を並存させることが可能になります。TEIでもスタンドオフ記法が提唱されており、注釈者ごとに別々のマークアップを付加するような協調作業にも向いていると言われますen.wikipedia.org。
上位メタ言語の利用: SGMLにはかつてCONCUR（並行マークアップ）といった機能が存在し、複数の並列したDTDを用いて一つの文書に複数の階層構造を持たせることも理論上可能でした。しかしSGMLのCONCURは実装が複雑で広く普及しなかったため、実際のHTML/XML系には引き継がれませんでした。その代替として、XMLに重なり構造を直接記述できる新たな実験的言語も登場しました。例えば LMNL (Layered Markup and Annotation Language) はXMLに似た記法で**タグ範囲の自己重複（self-overlap）**さえ許す非階層型のマークアップ言語として提案されましたen.wikipedia.org。また、GODDAG (General Ordered-Descendant Directed Acyclic Graph) と呼ばれるデータモデルも考案されており、これはマークアップ言語そのものではありませんが、非階層的なマークアップを表現する一般モデルとして提唱されていますen.wikipedia.org。GODDAGは重複階層を有向非巡回グラフで表現しようとするもので、学術的にはSperberg-McQueenやClaus Huitfeldtらによる提案が知られていますen.wikipedia.org。
このように、HTMLが採用する単一ツリー構造（＝OHCO、Ordered Hierarchy of Content Objects 的なモデル）は表現力の面で限界があり、特殊なケースでは重なりを扱えないという指摘があります。しかし、その制約こそがHTMLをシンプルにし、ブラウザで高速に解析・レンダリングできる理由でもあります。実際、Tim Berners-LeeはHTMLをSGMLの応用として設計した際、当時のSGMLの複雑な機能を削ぎ落とし、入れ子構造主体の簡易な設計とすることでWeb上で実用的な仕様にまとめましたlandsurvival.comlandsurvival.com。結果としてHTMLは大きな成功を収めましたが、一部の研究者にとってはその**単純すぎる構造（コンテナモデル）**が逆に「厳密な意味でマークアップ言語と言えるのか？」という議論につながったと言えますlandsurvival.com。
要するに、「HTMLはコンテナ言語である」という主張の根底には、HTML（およびXML）の設計が文書構造を単一の入れ子（コンテナ）の集合としてしか記述できない点への着目があります。それ自体は事実ですが、後述するように、それをもってHTMLを別カテゴリの言語と見なすことには無理があります。
以上を踏まえ、「HTMLはコンテナ言語」という呼び方が技術的に適切な分類かどうかを総合的に評価してみます。結論から言えば、この呼称をHTMLの正式な分類名として用いることは妥当ではありません。主な理由を整理すると以下の通りです。
公式な分類ではない: 前述の通り、HTMLは一般に「マークアップ言語」と分類されており、W3C勧告や教科書的な文献でもそのように位置付けられていますen.wikipedia.org。一方、「コンテナ言語」という分類区分は標準化団体や権威ある技術文書には登場しません。従って、「コンテナ言語」は公式なカテゴリーではなく、広く認知された用語でもありません。特定の文脈で説明的に使われた言葉を、そのまま分類名のように捉えるのは適切ではないでしょう。
用語の明確な定義がない: 「コンテナ言語」という言葉自体、明確に定義された技術用語とは言い難い状況です。例えば「プログラミング言語」であればチューリング完全性や手続き的記述の可否など定義の議論がありますし、「マークアップ言語」であればタグによる構造記述という定義があります。しかし「コンテナ言語」は何をもってそのカテゴリーに属するとするのか不明瞭です。HTML以外にもXMLやJSON、あるいは単純な構造を持つフォーマットは多数ありますが、それらをまとめてコンテナ言語と呼ぶ慣習もありません。結局、「コンテナ言語」は厳格な入れ子構造を持つ言語を指すのでしょうが、そのような分類は一般的ではなく、定義も共有されていません。
誤解を招く可能性: 「コンテナ言語」という表現は、前述したように他の「コンテナ」に関する概念（HTMLのコンテナ要素やCSSのコンテナクエリ、コンテナクラスなど）と混同される恐れがあります。技術者同士の会話で文脈が共有されていれば問題ないかもしれませんが、文脈を離れてこの言葉だけが一人歩きすると、初学者や周辺分野の開発者に誤った印象を与えかねません。実際、「HTML コンテナ言語」というキーワードで検索しても統一的な定義にはたどり着かず、人によって解釈がバラバラになる可能性があります。分類名はできるだけ誤解を生まない明確な用語を使うべきであり、その点で「コンテナ言語」という言葉は適切さに欠けます。
議論は階層構造 vs. 重層構造の問題に収束する: 「HTMLはコンテナ言語」という主張の背景には、技術的にはマークアップ言語における階層構造の限界というテーマがあります。このテーマ自体は非常に重要で興味深いものですが、HTMLの分類名の話とは切り離して論じるべきです。実際、重なり構造を扱える別のマークアップ手法（LMNLやGODDAGなど）の提案はありますが、だからと言ってHTMLを「マークアップ言語ではない」とするのは極論でしょう。HTMLは歴史的にもマークアップ言語として発展してきた経緯がありlandsurvival.com、その成功もマークアップ言語としての利点によるものだと評価されていますsamplecontents.library.ph。一部の研究者が「HTMLは本当の意味でのマークアップ言語ではなくコンテナ言語だ」と表現したのは、あくまで階層モデルに依存する点を批判的に捉えたレトリックに過ぎず、分類学的な再定義ではありません。そのため、この主張を鵜呑みにしてHTMLの種類付けを変更する必然性はありません。
以上の理由から、「コンテナ言語」という呼称をHTMLの技術的カテゴリーとして用いることは適切でないと言えます。HTMLはタグで情報にマーク（印）を付けるマークアップ言語であり、その枠組みで議論すべきものですen.wikipedia.org。「コンテナ言語」という表現は、HTMLの入れ子構造を強調したい特殊な場面でのみ限定的に使われるべきもので、一般的な文脈では避けるのが無難でしょう。
「HTMLはコンテナ言語」という言い回しについて、その出典と背景、そして適切性を検討してきました。確かに過去の一部資料ではHTMLの階層構造に着目してコンテナ言語と呼ぶ例がありましたlandsurvival.comdco.uscg.mil。しかしながら、標準的な位置付けではHTMLはハイパーテキストマークアップ言語でありen.wikipedia.org、「コンテナ言語」という分類用語は一般には定着していません。むしろ「コンテナ」という語は他の文脈（HTML要素の入れ物やCSSのコンテナクエリ、フレームワークのレイアウトクラス）で多用されるため、用い方に注意が必要です。
HTMLの設計上、タグの入れ子による厳密な階層構造しか持てないことは事実であり、これが重なり構造を表現できないという議論landsurvival.comen.wikipedia.orgにつながって「コンテナ言語」呼称が生まれました。しかし、この呼称は公式な分類ではなく、技術的にもあまり有用とは言えません。エンジニアとしては、こうした用語が出てきた背景（階層 vs. 重層構造の議論）を理解しつつ、正確な分類用語（マークアップ言語）を用いることが望ましいでしょう。
参考文献・出典として、本稿ではMDNやWikipedia、技術ブログ等から関連記述を引用しましたlandsurvival.comen.wikipedia.org。これらを辿っていただければ、さらに詳しい議論（例えばLMNLやGODDAGに関する学術論文en.wikipedia.orgen.wikipedia.org）にも当たることができます。最後に改めて強調すると、「コンテナ言語」はHTMLを公式に説明するための一般的な言葉ではなく、技術コミュニケーションにおいては誤解を避けるためにも慎重に扱うべき用語であると言えるでしょう。