最近、MulmoClaudeの開発記事を読んでいて、ひとつの発想に目が止まった。それは「Worklog」「Client」「Invoice」といった業務機能を個別のプラグインとして実装するのではなく、汎用的なデータベース機能の上に構築するという考え方だ。

一見すると「それはただのデータベース設計の話では？」と思うかもしれない。しかしその本質は、AIが介在することで従来のデータベース設計の常識が変わる、という面白い視点を含んでいる。本記事では、MulmoClaudeのCollections構想と、AIネイティブデータベースの可能性について考察してみたい。

プラグインが増えるとAIは苦しくなる

従来のAIエージェント設計では、業務機能を個別のプラグインとして積み上げていくアプローチが一般的だ。

  • Worklogプラグイン
  • Clientプラグイン
  • Invoiceプラグイン
  • Calendarプラグイン
  • CRMプラグイン

最初はシンプルでよい。しかし機能が増えるにつれ、深刻な問題が発生してくる。

問題具体的な影響
システムプロンプトの肥大化各プラグインの説明がプロンプトに蓄積し、毎回巨大なコンテキストが必要になる
トークン消費の増大読み込む情報量に比例してAPIコストが増加する
エージェント管理の複雑化どのエージェントにどのプラグインを読ませるかの組み合わせが爆発する
機能間の依存関係InvoiceがClientを参照するといった依存が複雑に絡み合う

これはAIエージェントが本格的な業務システムへ進化する際の大きな壁だ。「機能を足せば足すほど重くなる」という問題は、プラグイン積み上げモデルが本質的に抱える構造的問題でもある。

Collectionsという発想：「機能」ではなく「データ定義」を増やす

MulmoClaudeのCollections構想が採用するのは、これとは異なるアプローチだ。一言で言えば、「機能を増やすのではなく、データ定義を増やす」という考え方だ。

例えばWorklogは、次のようなスキーマを持つコレクションとして定義される。

{
  "collection": "worklog",
  "fields": {
    "date": "date",
    "client": "reference:client",
    "hours": "number",
    "memo": "text"
  }
}

ClientもInvoiceも同様にスキーマとして定義される。つまり「Worklogプラグイン」として機能を実装するのではなく、「Worklogというスキーマを持ったデータ」として定義する。AIエージェントは共通のデータベースAPIだけを知っていればよく、機能ごとに異なる操作方法を覚える必要がない。

これはWebフレームワークの世界で言えば「Convention over Configuration（設定より規約）」に近い発想だ。共通のルールで動く仕組みの上に、個別の定義を乗せていく。

LLMがいるから成立する：表現の揺れを吸収する

ここからが本質的に面白い部分だ。従来のデータベース設計では、顧客の時給を扱うなら設計段階で必ずhourly_rateのようなフィールドを用意しなければならない。「あとから追加」は可能でも、既存データの移行コストがかかる。

しかしLLMが介在すると事情が変わる。顧客メモのテキストフィールドに以下のような記述があるとする。

「2026年6月から時給6000円に改定」
「単価6000円/時間でお願いします」
「6月以降は料金が変わります（6000円）」

従来のデータベースはこれらの文字列から「時給6000円」という数値を自動的に抽出することはできない。しかしLLMなら、表現の揺れに関係なくその意味を理解できる。構造化しきれなかったデータの意味を、クエリ時にLLMが補完するというアーキテクチャが成立する。

AIネイティブデータベースの設計思想

重要なのは「構造化データを捨てる」ことではない。むしろ両方を活かすハイブリッド設計だ。

データの種類保存方法理由
ID、日付、金額、顧客ID厳密な構造化フィールド集計・検索・整合性チェックに必要
契約条件、注意事項自然言語テキストLLMが意味を理解できるため構造化不要
顧客とのやり取りの経緯自然言語テキスト時系列の文脈をLLMが統合的に扱える
例外的なケースの判断自然言語テキストルールに落としにくい判断はメモで残す

この設計は「最小限の構造化 ＋ 大量の自然言語データ ＋ クエリ時にLLMが意味を補完」という構成だ。従来型の「全てを構造化しきる」アプローチとも、「全てをベクトル化する」アプローチとも異なる第三の道と言える。

ロボット研究への応用：SCOUT実験データで考えてみる

この発想は、筆者が取り組んでいるSCOUTのTeach & Repeat研究にも直接応用できそうだ。

現在の実験ログ管理は主にCSVベースで、構造化されたデータの記録は得意だが、実験中に気づいた定性的な観察を記録・検索するのが難しい。

Collectionsの考え方を応用すると：

# 構造化フィールド（厳密に管理）
experiment_id: EXP-2026-0603-001
timestamp: 2026-06-03T14:23:00
vpr_score_avg: 0.73
collision: false
teach_path: route_A
hold_stop_K: 3

# 自然言語フィールド（観察・文脈を自由記述）
notes: |
  窓からの午後の日差しでVPRスコアが0.6台に下落した区間あり。
  机の横（座標X=2.1付近）で特徴点マッチングが不安定。
  照明条件を変えた再実験が必要。

後でLLMに「照明が影響した実験を全部まとめて」と聞けば、notesフィールドの自然言語を横断的に分析して答えてくれる。従来のCSVログではSQLや正規表現でしか検索できなかった定性情報が、自然言語クエリで引き出せるようになる。これは実験管理の質を大きく変える可能性がある。

Claude Code自身が機能を拡張する未来

個人的に最も興味深いのは、この先の発展形だ。Collectionsの仕組みが完成すると、次のようなシナリオが現実味を持ってくる。

ユーザー: 「顧客管理機能を追加して」

Claude Code:
1. 「Client」コレクションのスキーマを生成
2. 必要なバリデーションルールをDSLで記述
3. CRUD操作のスキルを自動生成
4. 既存のInvoice・Worklogとのリレーションを定義
→ 人間がTypeScriptを書かずに機能が追加される

つまりAIが自分でデータ構造を設計し、自分で機能を拡張する世界だ。人間の役割は「何が必要か」を伝えることだけになる。

これはまだ発展途上のアイデアだが、Claude Codeがコードを書く能力を持っている現在、「スキーマを生成してコードを書く」というループはすでに技術的に実現可能な範囲に入っている。MulmoClaudeのCollections構想はその方向性を実験的に探っているプロジェクトと理解できる。

筆者の考察：データベース設計の「前提」が変わる

従来のデータベース設計は「将来必要になりそうなフィールドを全て事前に定義する」という方針が正しいとされてきた。なぜなら後からスキーマを変更するコストが高いからだ。

しかしLLMが「定義されていない情報を自然言語から読み取れる」なら、この前提が揺らぐ。「今必要な構造だけ作り、残りは自然言語でメモしておく」という設計が合理的になり得る。

これはデータベース設計の哲学として興味深い転換だ。構造化のコストとLLMの推論コストがトレードオフになる設計空間が生まれる。業務の性質によって「どこまで構造化すべきか」の最適解が変わる、という新しい設計判断軸が登場する。

まとめ

  • プラグイン積み上げ型のAIエージェント設計はシステムプロンプト肥大化・トークン増加という構造的問題を抱えており、Collectionsはその解法として「データ定義を増やす」アプローチを提案している
  • LLMが介在することで「構造化しきれなかった情報」を自然言語のまま保存し、クエリ時に意味を補完するハイブリッドなデータ管理が成立する
  • ロボット実験ログや研究メモのような定性情報管理にも応用でき、自然言語クエリで横断検索できるシステムが実現できる
  • 将来的にはClaude Code自身がスキーマ生成・コード生成・機能拡張のループを回す「AIが自分で機能を追加するシステム」への発展可能性がある
  • AI時代のデータベース設計は「どこまで構造化しどこからLLMに任せるか」という新しいトレードオフを持つ設計空間に移行しつつある

MulmoClaudeのCollections構想はまだ実験段階だが、「AIが業務システムを自律的に拡張する」という方向性において、示唆に富んだアーキテクチャだと感じている。AIエージェントを業務システムに組み込もうとしているエンジニアにとって、注目しておく価値のあるアプローチだ。

関連書籍（Kindle）