Tabulariumをリリースします | Hieronymus ブログ

この前から「LegionのWiki機能」として紹介して来ていたWikiを単体でも十分に価値があると判断し、今回独立してリリースすることにしました。

Tabulariumは、「人間とAIが共働するためのワークスペース」として設計した、Wikiシステムです。

急ぐ人へ

このエントリを読むには、以下のエントリも併せて読むと良いと思います。と言うか、このエントリは以下のエントリのまとめのようなものです。

これらのエントリを既に読んでしまった人は以下の駄文を読まずに、「要するにこの機能を持ったWikiを単独でリリースさせたんだ」と理解すれば十分です。

はじめに

TabulariumはもともとはLegionのWiki機能として育てていました(名前もなかった)。エージェントにナレッジを参照させるための保管庫として作り始めたのですが、気づけば人間にとっても十分実用的なワークスペースに育っていました。結果としてオフィスツールのいくつかを集約するカタチになりましたが、それはあくまで結果であって目的ではありません。目的はあくまで「人間とAIエージェントが同じ場所で仕事をする」という一点です。

Tabulariumの直接的なターゲットは「AIエージェントを取り入れたいけど、MCP地獄にはハマりたくない」という人たち。あるいは「Officeファイルのやり取りにうんざりしているオフィス」です。別にAIエージェントがなくても普通のWikiとして使えますが、本領が発揮されるのはエージェントと組んだときです。

設計思想

Tabulariumは単なる「多機能Wiki」ではありません。設計の根幹は

すべてをファイルとして扱う

ただそれだけです。

カレンダーもブックマークもスプレッドシートも、実体はただのファイルです。単体のファイルでは当たり前のことなんですが、「文書管理システム」という土俵となると、そうなってないシステムがほとんどです。 Tabulariumは「そのまま」にして、全てがただのファイルのままです。ですから、TabulariumのUIやAPIを使わなくても、普通のファイルツリーとして扱うことができます。

つまり、どんなAIエージェントでも「ファイルの読み書き」という標準機能だけで操作できます。 MCPを生やす必要も、専用APIを叩く必要もない。

具体的なイメージとしては、「りっちゃん(エージェントの名前です)、来週のミーティングの議事録をまとめて、カレンダーに反映しておいて」——エージェントにそう頼める。そのための「共通基盤」がファイルベースのワークスペースであり、それがTabulariumです。

この「単純さ」こそが、最大の武器です。

エージェントフレンドリーである理由

では、なぜファイルベースだとAIエージェントと相性が良いのかと言えば。

どのエージェント(ハーネス)にも「ファイルの読み書き」の機能は標準で存在している

Code Interpreterしかできないとか、MCPが必須とか、そういう制約はありません。 OpenAIのAssistant APIしかり、ClaudeのArtifactsしかり、ローカルのオープンなエージェントフレームワークしかり——どのプラットフォームにも「ファイルを読む」「ファイルに書く」という機能は標準装備されています。 当たり前の機能で操作できるというのが、実は最も重要なポイントです。
MCPに頼らないので、skillsを使いやすい

MCPサーバはツールの「説明」が最初から組み込まれていますから簡単に使えるのですが、凝った処理を書こうとすると辛くなります(逆に邪魔になったりする)。そしてどうしても「木に竹を継ぐ」感じになります。さらに便利だった「説明」がずっとトークンを圧迫します。

一方、skillsは補助ツールの使用や条件分岐、エラーハンドリングなど、最初から自由に書けます。ファイル操作を基本とすることで、「MCP地獄」——ツールごとにMCPを生やして、認証を通して、できることとできないことを覚えないといけない——から解放されます。ファイル操作スキルだけで、あらゆるデータにアクセスできる。考え方としては圧倒的にシンプルです。 skillsは必要なものだけ読み込みますから、トークンの圧迫は少なくできる可能性があります(努力次第ですが)。
多様なファイル形式に対応しやすい

新しいファイル形式が出た時にやることは「その形式を扱えるようにskills(やツール)を追加する」だけです。アーキテクチャ自体に手を入れる必要はありませんし、新規のMCPも不要です。将来どんなフォーマットが主流になっても、Tabulariumはそのまま対応できます。

逆に言えば、これは「エージェントファースト」で設計された、新しい種類のWikiです。従来のWikiが「人間が書いて人間が読む」ために最適化されているとしたら、Tabulariumは「エージェントが読み書きできて、人間も同じ場所を使える」ように最適化されています。この「人間とエージェントの対等性」が他のナレッジ管理ツールとの最も大きな違いです。

機能

というわけで、具体的に何ができるのか。Tabulariumは以下の機能を持った knowledge workspace です。

文書基盤——ドキュメント作成と編集

Markdown

Markdownはベースとなる文書フォーマットです。何ならエージェントが一番書きやすいフォーマットでもあるので、これを軸にしています。雑に文書を作るには、これが一番楽ですしね。

表示:

編集:

エディタにはCodeMirrorを使っています。VSCodeのエディタ(Monaco)と比べると高機能ではありませんが、その分軽快で扱いやすく、Markdownエディタとしては必要十分です。 Monacoと比べて強くどっちがどうだってことはないのですが、Monacoって進化が止まってるようですし。

人間が編集する画面も、エージェントが読み書きするときも、同じMarkdownを使います。それによって「人間が編集したものをエージェントが読める」「エージェントが生成したものを人間が修正できる」という対称性が生まれます。これがTabularium全体を貫く思想です。

CSV

jspreadsheet-ceを使って、CSVをブラウザ上でスプレッドシートのように編集できるようにしています。どうせテキストファイルですから、エディタで操作すればいいような気でいたのですが、やっぱり「表」になっている方がずっと見易いし間違いもありません。後で述べるようにExcelで扱えばいいという話もあるのですが、CSVでそこまでやるのは「やり過ぎ」以上に間違いの元なので、これくらいの方が都合がいいと思っています。

例えば経費精算シートをCSVで置いておけば、ブラウザから直接セルを編集して保存するだけ。軽い「表」にはこれで十分じゃないかと思います。

Office

Collabora OnlineをPodmanで動かしています。Podmanなので実行にroot権限は不要です。

実はかつてはこのようなものにあまり好意的ではなかったのですが、クラウド版Officeを使えば、どうせフォントとか滅茶苦茶になってしまうし、だったらCollaboraで十分じゃない？って気持ちになりました。

また、DockerではなくてPodmanを基本にしました。 Dockerと違って仕掛けが大掛りではないので、セットアップが本当に楽です。 READMEを読めばわかると思いますが、Collabora Onlineのインストールについては一言も言及していません。 Podmanがインストールしたユーザの権限で勝手にインストールしてくれるからです。

Excel:

PowerPoint:

Word:

(Wordは正直うちではほとんど使いません。なのでサンプルは父が生前書いていた薄い本の原稿を使っています)

Draw.io

draw.ioのフロントエンドだけを持って来て使っています。

この図はMermaidからimportしたものです(そういう機能があります)。

仕様書を作って、draw.ioでアーキテクチャ図を描いて、そのまま納品データに——すべて同じワークスペースで完結します。 SVGへのエクスポートもボタン一発です。エージェントにDraw.ioのファイルを生成させることも可能で、すでにPowerPointのファイル生成には成功しています。

時間・情報管理——カレンダーとブックマーク

カレンダー

FullCalendarを使って実装しています。

単独カレンダー（.ical）:

もちろん、年や週単位のビューもあります。

組カレンダー（.mycal）:

複数の単独カレンダーを束にして扱うこともできます。赤で囲った部分のように、アクティブにするカレンダーを選択できます。そのまま編集することもできます。

icsファイルとしてexportできるので、他のカレンダーアプリとの同期も簡単です。エージェントに「来週の予定を入れておいて」と指示するだけでカレンダーが更新される——それを実現するためのインターフェイスです。プロジェクト用カレンダーと個人用カレンダーを分けて、エージェントに「プロジェクトAの締切をプロジェクトカレンダーに入れて」と頼む——そんな使い方が現実的になります。

ブックマーク

ブラウザのURLをDnDするとブックマークになります。サムネを保存します。

インデックスファイル(index.md)が存在しないフォルダはファイル一覧を表示しますが、それと並んでブックマークのサムネも表示されます。

調査のときにURLをDnDするだけで、あとでエージェントに「さっきブックマークしたサイトの内容をまとめて」と頼める。そんな使い方ができます。 AIエージェントに「このサイト調べて要約して」と依頼するための材料置き場としても使えます。

データ可視化(実験中)

Evidenceモドキ

データ可視化が欲しかったので、Evidenceを~~パクって~~組み込んで使おうと思ったのですが、いろんなところで不整合を起こす(結局木に竹継ぐようなことになってしまう)のが面倒になって、それっぽいものを作ることにしました。元ネタはAIモードは便利で作った「Andrei Sketch」です。

表示:

編集:

MarkdownにSQLブロックを埋め込むと、そのクエリ結果がチャートとして描画されます。PostgreSQLとDuckDBに対応しています。DuckDB経由で他のデータベース(MySQLやSQLiteなど)にもアクセスできるはずです。

とは言え、これはまだ「作ってみた」だけでしかありません。 SQLだけじゃなくてJavascript等を書けるようにしないと、チャート表示はちょっと苦しいように思います(しれっとEvidenceをdisるなど)。データベースに直接クエリを投げて結果を可視化する——この一連の流れをワークスペース上で完結できるのが、この機能のゴールです。

「MCP地獄」とは無縁の拡張性になるのか

ここまで読んで「で、MCP地獄って何？」と思った人もいるかもしれません。簡単に言うと、「AIエージェントに何かをさせようとするたびに、専用のMCPサーバを立てて、認証設定して、できる操作を制限して……」というのがだんだん辛くなる現象です。

例えば、カレンダーを見たい、Todoを管理したい、スプレッドシートを更新したい——それぞれに別々のMCPサーバが必要で、さらにそれぞれのサーバに「どんな操作ができるか」を設定しないといけません。 MCP自体は良い仕組みですが、ツールが増えるほど管理コストが線形に、いや、むしろ指数関数的に増えていきます。ツール同士の連携を考え始めるとさらに複雑になります。自分のエージェント環境のMCPの設定を見ればわかりますよね。

Tabulariumは最初から「全部ファイルで扱えばいいじゃないか」という割り切り方をしています。カレンダーの操作も、ブックマークの追加も、スプレッドシートの更新も全部「ファイルの作成・読み取り・更新・削除」の4操作に統一されます。エージェントに必要なのは「ファイルの読み書きができる」という標準機能だけ。新しいツールを追加するたびにMCPサーバを生やす必要はありません。 skillsは増えますが、こっちはいくらでも整理することができますし、使わないskillsは読み込まれませんので、トークンをムダに使うことがありません(MCPは説明等を全部読み込みますからトークンの消費が多くなりがち)。

エージェントによる操作

今回、エージェント(Legion)は一緒に公開しておりませんが、多分その辺にあるエージェントなら、ちょっとskillsを作ってやれば便利に扱えるんじゃないかと思います。 MCPもCLIも用意していませんが、そんなものは必要ないでしょう。 単なるファイルツリーに過ぎませんから。

現状、PowerPointやDraw.ioのファイルはskillsで生成可能です。「エージェントにプレゼンを作らせてWikiに置く」——もうこれ、実際にやっています。急ぎのレポートの下書きを図も含めてエージェントに作らせて、それを確認して修正してPDFにして。もちろんプロジェクトドキュメントとして保存して。そんな「人間とエージェントの共同作業」が自然に回るようになります。

あまりに早くできたので、「AIに丸投げしただろう」とか言わたりしましたが、そういったものを「AIに丸投げ」するのは結構面倒な準備が必要なのはわかると思います。そこで「丸投げ」ではなくて、下書きとして作ってもらって、適度に人間が手を入れて、さらにそれを… とやった方が、トータル工数が少なくなりますね。

また、ファイルベースであるがゆえに、gitなどのバージョン管理ツールとの相性も抜群です。エージェントが生成したファイルの変更履歴をgitで追う、エージェントの生成物をPRベースでレビューする——そんな使い方も可能です。バージョン管理とAIエージェントの組み合わせは、まだあまり議論されていませんが、実は大きな可能性を秘めていると思っています。

将来

今のところ扱っている文書がそれ程多くないので、検索機能的なものは持っていません(この辺がLLM Wikiとはちょっと違う)。

文書が多くなればQMDやGraphifyを入れたいところなんですが、下手にそんなものを入れるよりは、インデックスやフォルダ構成を最適化する方が人間にもエージェントにも便利なんだってことに気がついてしまい、Legionに「Wikiを整理するskills」を作ったら満足してしまいました。

ただ、やっぱりあればあったで便利でしょうから、いずれは入れたいと思っています。どうせ「入れるだけ」のものですし。

そして、まだ対応したいファイル形式やアプリはたくさんあります。

以前から作っているJupyterの改良版——コードとドキュメントを一体化したインタラクティブな環境
Evidence風機能の強化——チャートの種類を増やしたり、ダッシュボード的な使い方ができるようにしたい
GeoGebra——技術文書に数式やグラフを埋め込むのに使える。数学的なコンテンツを扱うチームには有用です
ファイルのプレビュー機能の強化

まぁ欲しいと言い出すとキリがありませんし、わざわざ作らなくても扱えればいいわけなので(つまり外部ソフトと連携させればいいので)、その辺も含めて色々考えるつもりです。

そういったこと以外にも、もっと「手触り」を良くするための改良もTODOにいっぱい積まれています。例えば、エージェント操作用の標準skillsの同梱、UIの細かな使い勝手の改善など。気にしなけりゃ今でも足りないってことはありませんけどね。

この機能は部品として、開発中のCassetteOS Ver 2のファイルエクスプローラとして使用するつもりです。つまり、Tabulariumは単なるプロダクトではなく、もっと大きなプラットフォームの一部でもあります。CassetteOSとの統合によって、さらに面白い使い方ができるようになるでしょう。

気が向けば操作のためのskillsも同梱しようかなと思ってます。

まとめ

Tabulariumは「AIエージェントのためのOSとしてのファイルツリー」、言い換えれば人間とエージェントが対等に同じ机を共有するためのワークスペースです。

インストールの難しさはありません。Podmanさえあれば、5分で動きます。 Officeファイルがブラウザで編集できる感動を、ぜひ一度味わってみてください。

そして、もし「りっちゃん、これ使って何か作っておいて」とエージェントに任せたくなったら——その時、Tabulariumの本当の価値が分かるはずです。何かあればIssuesなりで教えてください。

おまけ

TabulariumはほとんどVibe Codingで作りました。 Legionはコアや初期機能(ゲートウェイ)はだいたいOrganic Codingですが、Tabulariumになっている部分は、ほぼVibe Codingです。

具体的には、OpenCodeを使い、モデルはOpenCode Goにある、DeepSeek V4 Flashを使っています。

元々激安のOpenCode Goで、その中でも廉価なモデルであるDeepSeek V4 Flashです。コストは、多分5ドルもかかってないでしょう。デバッグでしばしばハマったりしますが、作ることには特に問題はないように思ってます。そこそこ以上の知性と地頭の良さ、そして「激安」ということが非常に良い環境となってくれています。

コーディングに必要な規約やルールに属することは、Tabulariumの管理下にあって、AGENTS.mdから参照するように書いてあります。以下にLegionのAGENTS.mdの抜粋を挙げますが、この中でknowledgeと書かれている部分がTabulariumのメインツリーのフォルダです。

...
## プロジェクトの構造

...
- [knowledge](./knowledge/)
  エージェントと人間が参照するための知識ベース
...
## プロジェクトでの作業手順

- リクエストを実行する前に、`@knowledge/wiki/software-development/`にあるドキュメントを読んでください

## 教訓

このプロジェクトの開発で得られた教訓は、`@knowledge/wiki/software-development/` に格納されています。
新しいバグや問題に遭遇した際は、まず既存の教訓を確認し、同じ過ちを繰り返さないこと。

特に以下の文書は、本プロジェクトで実際に発生した問題とその解決策をまとめたものです:

- [ファンアウト/ファンイン実装の教訓](knowledge/wiki/software-development/lessons-from-fanin.md)
- [実データをテストで壊した話](knowledge/wiki/software-development/lessons-from-data-loss.md)
- [CSSクラスを確認せずに書いたレイアウト失敗](knowledge/wiki/software-development/lessons-from-layout-debacle.md)
- [ロジックをコンポーネントに閉じ込めた失敗](knowledge/wiki/software-development/lessons-from-hoarding.md)
...

エージェントが変なことを始めた時は「AGENTS.mdを読み直せ」と命じると、だいたいいい感じに戻ります。

「丸投げ」で全部作ってくれるほどの能力はありませんが、こっちはこっちでやりたいことがあるわけなので、それくらいの方が都合が良いです。デバッグは苦手みたいですが、投げ出すことはないので、まぁこれくらいでもいいかなという感じです。