桐をWebで蘇らせる ― DataDrawers開発記
第1回: なぜ「桐」をWebで作り直すのか
プロローグ：私の抱える小さな問題
私はこれまでずっとWindowsのパソコンを使用してきましたが、プログラミングを始めてからMacに変更しました。
Macは環境構築や、各種作業が快適で、仕事もプライベートも全てMacに移行していきました。
そんな中、唯一Windowsを使用しなければならないラスボスが存在します。
それが「桐」です。
職場のデータ管理には長年「桐」という日本製のデータベースソフトを使ってきました。しかし、桐はWindows専用です。
私の大好きなMacでは使用できません。
「だったら、Webで作ればいいじゃないか」
そう思い立ったのが、このプロジェクトの始まりでした。
桐との出会い
私が「桐」に出会ったのは働き始めて間もない頃でした。管理工学研究所が開発したこのソフトウェアは、日本のデータベース文化を30年以上支えてきた名作です。Windows専用のアプリケーションで、データベースのクライアントソフトでもあり、フォーム機能や一括処理、帳票作成など多機能なアプリのため、ローカルで使用する業務アプリなども作成できます。日本語を主体として作成されているため、当時データベース初心者であった私にとって、救世主のような存在でした。
初めて桐を触ったとき、衝撃を受けました。
「これ、めちゃくちゃ使いやすい」
当時、AccessやExcelのVBAで苦労していた私にとって、桐の直感的な操作は革命的でした。特に「段階的な絞り込み」と「補集合機能」は、他のどのデータベースソフトにもない、桐ならではの魅力でした。
桐の「唯一無二」の機能
1. 段階的な視覚的絞り込み
桐では、こんなことができます：
1. 全生徒データを表示 (2,345件)
2. 「1年生」で絞り込み → 150件
3. 「在籍中」で絞り込み → 89件
4. 「3ヶ月以上欠席」で絞り込み → 12件
重要なのは、これらの履歴が視覚的に表示されることです。各ステップでの結果件数が見え、任意のステップを削除して前の状態に戻れます。
AccessやExcelでは、こうした「段階的な絞り込みの可視化」は実現できません。SQLを書くか、フィルタを何度もかけ直すしかありません。
2. 補集合機能
もっと衝撃的だったのが「補集合」です。
例えば、「面談済みの生徒」をチェックボックスで選択したら、ワンクリックで「面談していない生徒」のリストが作れるのです。
全生徒150名から「面談済み」138名を選択
↓
「補集合」ボタンをクリック
↓
「未面談」12名のリストが自動生成
これが桐の威力です。業務の現場では「選択した以外のデータ」を取得したいシーンが頻繁にあります。Excelでフィルタをかけ直したり、SQLでNOT INを書いたりする必要はありません。桐なら、マウスクリックだけで完結します。
3. 併合（データ転記）
最後は「併合」機能。これは、別のテーブルからデータを一括転記する機能です。
出席データに、生徒マスタから「氏名」「学年」を転記
↓
結合条件: student_id
↓
5,000件のデータが一括更新
SQLで言えばUPDATE ... FROM ... JOINですが、桐ではビジュアルな画面で設定できます。プレビュー機能もあり、実行前に確認できます。これも、業務の現場で頻繁に使う機能でした。
Windows専用という壁
しかし、桐には致命的な制約がありました。
Windows専用
30年以上の歴史を持つソフトウェアだけに、Windowsネイティブアプリとして最適化されています。Mac版はありません。Web版もありません。Linuxでも動きません。WindowsのARM版にも対応していないため、AppleシリコンMac上の仮想環境Windowsでも動作しません。
- Mac使用者がデータを見られない
- iPadで確認したいのにできない
- 自宅のMacから作業できない
- 出張先でデータを見たいのに、Windows PCがない
管理工学研究所の桐は素晴らしいソフトウェアですが、クロスプラットフォーム化の予定はありません。それなら、自分で作るしかない。
「Webで桐を作ろう」
そう決意しました。
プロジェクト名「DataDrawers」の誕生
プロジェクト名は「DataDrawers」と名付けました。
Drawer（引き出し）= 桐箱
桐（きり）の木は、古くから高級な家具や箪笥（たんす）の材料として使われてきました。軽くて丈夫で、湿気を調整する性質があり、大切なものを保管するのに最適です。
データも同じです。大切な情報を整理して、必要なときにサッと引き出せる。そんなイメージで「DataDrawers」と命名しました。
コードの中では、内部的に「Kiri」という名前も使っています：
// データベースクラス
export const db = new Dexie('KiriDatabase') as KiriDB;
// 状態管理
export const useKiriStore = create<KiriStore>(/* ... */);
これは、元祖「桐」へのリスペクトです。
技術選定の考え方
さて、Webで桐を作るとして、どんな技術を使うべきか？
私が重視したポイントは3つです：
- クロスプラットフォーム対応 Windows/Mac/iPad/Androidのすべてで動くこと
- ローカルファーストの高速性 桐の強みは「ローカルファイル操作の速さ」。この感覚を再現したい
- モダンな開発体験 TypeScriptによる型安全性、Reactによる宣言的UI
Next.js + React + TypeScript を選んだ理由
Next.js(執筆時点の最新版) を選んだ理由は明確でした：
- SSR/CSRのハイブリッド データ表示はサーバーサイド、フィルタリングはクライアントサイドで最適化
- API Routes バックエンドとフロントエンドを統合管理。SQL Serverとの接続もNext.js内で完結
-
App Router モダンなルーティング。
/view-builder、/merge-builderなど、機能ごとにページを分離 - Turbopack 爆速の開発サーバー。大規模なプロジェクトでも高速にHMR（Hot Module Replacement）
React 19 は、Server Componentsの恩恵を受けたかったため。大量データの初期レンダリングをサーバー側で行い、その後のインタラクションはクライアント側で処理します。
TypeScript は必須でした。データベーススキーマが動的に変わる（ユーザーが任意のテーブルをインポートする）環境では、型安全性がないと破綻します。
// テーブルのメタデータ
export interface ImportedTable {
id: string;
sqlTableName: string;
displayName: string;
objectType: 'TABLE' | 'VIEW';
columns: ColumnInfo[];
importedAt: Date;
customColumns?: CustomColumnDefinition[];
}
こうした型定義により、IDEの補完が効き、ランタイムエラーを事前に防げます。
ローカルファーストをどう実現するか？
桐の最大の強みは「ローカルファイルの高速性」です。
AccessやFileMaker Proのような従来のデスクトップDBソフトは、ローカルのファイル（.mdbや.fmp12）を直接操作するため、検索やフィルタリングが非常に高速です。
Webアプリでこれを再現するには、ブラウザ内にデータを保存する必要があります。
選択肢は2つでした：
- IndexedDB（ブラウザの内蔵DB）
- WebAssembly + SQLite（ブラウザ内でSQLiteを実行）
初期実装ではIndexedDB + Dexie.jsを選びました。理由は以下の通りです：
| 比較項目 | IndexedDB | WASM SQLite |
|---|---|---|
| 導入の容易さ | ◎ ブラウザ標準 | △ WASMビルド必要 |
| データ容量 | ◎ 数百MB〜GB | ◎ 数百MB〜GB |
| 速度 | ○ 50-200ms (10万件) | ◎ 10-50ms |
| ブラウザ対応 | ◎ すべて対応 | △ 一部非対応 |
| オフライン | ◎ 完全対応 | ◎ 完全対応 |
IndexedDBは「ほどほどに速く、すべての環境で動く」という点で、MVP（最小機能製品）には最適でした。
（※ 後日、大量データ対応のためにSQLiteへ移行することになりますが、それは第4回以降のお話です）
既存サービスとの差別化
「Webで桐を作る」と言っても、似たようなサービスは既に存在します：
| サービス | 段階的絞り込み | 補集合機能 | 併合機能 | 価格 |
|---|---|---|---|---|
| Airtable | △ 弱い | ✗ なし | △ 限定的 | 高額 |
| NocoDB | △ 普通 | ✗ なし | ○ あり | 無料 |
| Retool | ○ 強い | ✗ なし | ○ あり | 高額 |
| Access Web | △ 弱い | ✗ なし | △ 限定的 | 終了 |
| DataDrawers | ◎ 桐風 | ◎ あり | ◎ プレビュー付き | 予定無料 |
結論: 桐のような「段階的絞り込みの可視化」と「補集合機能」に特化したWebアプリは存在しません。
Airtableは美しいUIですが、複雑なフィルタリングは苦手です。NocoDBはオープンソースですが、桐的な操作感はありません。Retoolは柔軟ですが、学習コストが高く、カジュアルなデータ操作には不向きです。
市場にはギャップがある
桐ユーザーの移行先がないのです。Windows専用という制約ゆえに、多くのユーザーが「桐を使い続けたいけど、環境が...」と悩んでいます。
DataDrawersは、そのギャップを埋めるプロジェクトです。
開発を始める前に決めたこと
コーディングを始める前に、いくつかのルールを決めました：
1. まずはMVPを作る
完璧を目指さず、最小限の機能で動くものを作る。
- テーブルのインポート
- データ表示（仮想スクロール）
- 段階的絞り込み
- 補集合機能
これだけでも、十分に実用的です。
2. 桐の「使いやすさ」を最優先する
技術的にカッコいいことよりも、ユーザーが直感的に使えることを優先する。
- 右クリックで即座に絞り込み
- ワンクリックで補集合
- フィルタ履歴を視覚的に表示
3. 型安全性を妥協しない
動的スキーマ（ユーザーが任意のテーブルをインポート）だからこそ、TypeScriptの型定義で安全性を担保する。
// ❌ 危険: any型
const data: any[] = await fetchData();
// ✅ 安全: 型定義
const data: TableDataRow[] = await fetchData();
次回予告
次回（第2回）では、IndexedDB + Dexie.js でローカルファーストを実現した話をします。
- ブラウザ内データベースの設計
- Dexieによるスキーマ管理
- チャンク処理による大量データ対応
- Zustandでの状態管理
そして、最初の壁「動的テーブルの実装」にどう立ち向かったのか、お話しします。
(続く)