半構造化データ

厳密な表形式ではないが、タグや階層など一定の構造を持つデータ。XMLやJSONが該当する。項目の有無が案件ごとに違っても扱えるため、システム間のデータ交換に広く使われる。

表形式のような固定したスキーマはもたないが、タグやキーによってデータの構造や意味が示されているデータ。XMLやJSON、ログファイルなどが該当し、項目の増減に柔軟に対応できる一方、集計にはデータの解析や変換が必要になる。

構造化データに加え、ログ、JSON、画像、音声などの半構造化・非構造化データを、加工せずに元の形式のまま大量に蓄積するリポジトリ。スキーマオンリードで利用時に構造を解釈するため、用途を決めずに取り込めて機械学習の素材にもなるが、メタデータやデータカタログで管理しないと中身の分からないデータスワンプになる。

データを格納する前にスキーマを定義し、それに合うように変換・検証したデータだけを書き込む方式。DWHやリレーショナルデータベースで採られ、データの品質や一貫性を保ちやすく問合せも速いが、事前の設計が必要で、新しい種類のデータや要件の変化への対応に手間がかかる。

JSONやBSONなどの形式の文書（ドキュメント）を1件のデータとして格納するNoSQLデータベース。事前にスキーマを固定しなくてよく、入れ子の構造や項目の追加に柔軟に対応でき、文書内の任意の項目で検索や索引付けができる。文書をまたぐ結合や複数文書の更新の整合性の確保は関係データベースより弱く、MongoDBが代表例である。

大規模言語モデルに、利用できる関数（ツール）の名前、説明、引数の形式をあらかじめ渡しておき、モデルが必要と判断したときに、呼び出す関数名と引数をJSONなどの構造化された形式で出力させる仕組み。ツール呼出し（Tool Use）ともいう。モデル自身は関数を実行せず、アプリケーションが出力を受けて実際に関数を実行し、その結果をモデルに返して回答を続けさせる。

字下げ（インデント）で階層を表す、人が読み書きしやすいデータ記述言語で、キーと値の組やリストを簡潔に書け、コメントも記述できる。JSONの書き方もそのまま扱える上位互換の仕様を持ち、Kubernetesのマニフェスト、CI/CDの設定、IaCのテンプレートなどの設定ファイルに広く使われる。字下げの誤りがそのまま構造の誤りになる点に注意する。

XMLやSGMLで、どの要素や属性をどの順序で使えるかという文書の構造を定義する仕組み。文書がその定義に従っているかを検証できる。データ型の指定が弱く、より表現力の高いXML Schemaに置き換わりつつある。