Agenticabilityの検討

生成AIが、人間が扱うツールを直接操作する場面が増えてきた。そこで、生成AIが扱いやすい状態というのをagenticabilityという言葉で表現しておく。

✅ 比較的得意な形式

1. 単一の大きなテキストファイル（プレーンテキスト）

理由：言語モデルの本来のトレーニングデータが自然言語テキストであり、文脈や流れを自然に把握できる。

得意な用途：読解、要約、構造化、リライト、ナレッジ抽出など。

制約：長さがトークン制限（最大 context length）を超えると扱いきれなくなる。

2. JSON

理由：構造が明示的かつ軽量。Key-Valueの対応関係を理解しやすい。

得意な用途：構造的データの要約、特定の値の抽出、構造の変換など。

制約：大規模なJSONだと文脈を保てなくなるため、分割・整理が必要。

3. 意味構造で分割されたフォルダ・ファイル構造（Zettelkasten, PKM, etc）

理由：ノード（カード）単位で意味が完結しているので、部分的に読み込みつつ全体を扱える。

得意な用途：関連ノートの抽出、タグベースの探索、リンク構造の解析。

制約：ファイルが多い場合、どれをどう読むかの制御がユーザー側に必要。モデル単体ではフォルダ全体を横断的に探索する能力はない（外部のアプリやAPI経由が必要）。

🤔 ある程度対応可能だが工夫が必要な形式

4. XML

理由：構造は明確だが、冗長でネストが深くなりやすいため、トークン圧迫のリスクがある。

用途：パースして内容抽出することは可能。HTMLと近い扱い。

制約：文書構造が複雑すぎる場合、意味的な理解が難しくなることも。

5. OPML（アウトライン形式）

理由：階層構造を持ち、ノードをたどるモデルとして有用。ただし見た目はXMLに近い。

用途：マインドマップ、アウトライン構造の読み解き、要約など。

制約：ノード数が多い場合は分割が必要。

6. Markdownフォーマット

理由：シンプルな記法でセクション構造が明示されている。タグやリストを自然に処理できる。

用途：要約、変換（HTML等）、ナレッジ抽出など。

制約：コードブロックなどは意図を読み間違える可能性あり。

❌ 苦手・補助が必要な形式

7. データベース（SQL, NoSQL）

理由：データ自体は構造化されていても、LLMが直接「全体を一望」することはできない。クエリ結果など、部分的な表示を通してしかアクセスできない。

用途：クエリ生成、スキーマ設計のアドバイス、結果の解釈などは得意。

制約：DB全体の構造や関係性を渡すにはメタ情報の整理が必要。操作には外部ツールとの連携が不可欠。

8. バイナリ形式（画像、PDF、Excel等）

理由：テキストではないため、前処理（OCR、抽出ツール）を介さないと扱えない。

用途：適切な変換ができれば問題ないが、元データだけでは不可。

補足：得意≠効率

たとえば、JSONは構造的に理解しやすいが、非常に巨大なJSONをそのまま渡しても、トークン制限に引っかかって読み切れません。逆にテキスト形式であっても、意味構造が曖昧だと処理結果がぶれることがあります。

まとめ：LLMが得意なデータ形式の特徴

table:_

特徴 説明

プレーンテキスト中心 自然言語処理に最適

セクションやラベルが明示的 Markdown・JSONなど

ノードが自己完結 Zettelkasten的構造

階層が浅めで冗長でない XML・OPMLはほどほどが良い

逐次読み込みや分割が可能 長文対応に有利

必要であれば、各形式ごとに「LLMとの連携方法」や「変換・前処理の工夫」についても掘り下げられます。興味のある形式があれば教えてください。