Tabulariumのmarkdownを強化してアプリが書けるようにました

今週は夏休みということにしています。まぁどこもそうでしょうね。

「夏休みの課題」として、Tablariumを機能拡張をしてみました。

まぁ正確には先週くらいからりっちゃんが、「Sales Management Systemが欲しい」と言い出したからなんですが。

背景

vibe codingの時代となって、自分で直接コードを書くことが少なくなりました。もうちょっと正確に言えば、なるべく自分で直接コードを書かないで、AIに任せるようにするようにしました。理由は色々あるのでこれについては別稿で詳しくと思うのですが、とにかく自分ではコードを書かないようにしています。

それと同時に、ソフトウェアの「機能の多さ」はあまり価値ではなくなっているように思うようになりました。何しろ必要であれば「○○の機能作って」と書くだけで実装されますから、機能そのものがあるとかないとかというのは、「今は」に過ぎませんし、いつでもどうとでもなります。

この時代にあって重要なのは、その「いつでもどうとでもなる」ことをどう担保するかでしょう。基盤がしっかりしてなければ、機能を追加する時にしんどいことになる… というのは、AIの前でも後でも同じことです。

ということもあって、今回のような機能は「後回し」と思っていました。機能を増やすのは容易いことですからね。最初から無闇に増やして開発の自由度を下げることはしたくありません。

他方、Legionが安定してスムーズに動くようになり、様々な用途に使うことができるようになりました。そこで、「営業活動」をさせるためのskillsを入れたり仕組み作りをしていたのですが、冒頭に書いたように「りっちゃん」が「Sales Management Systemが欲しい」と言い出したわけです。

元々、HieronymusにはCustomer Management system(CRM)はありました。ただ、これはある程度関係の進んだところで使うものです。「見込み客」を相手にすることは考えていません。

HieronymusのCRMの延長に営業管理も入れたら良いんじゃないかとも思いますが、

今は決算時期(弊社は7月決算)なので機能追加したくない
海のものとも山のものともつかないのであまり工数かけたくない
「AIフレンドリー」なものにしたい

ということもあって、Tablariumの中に作れないかなと考えました。

実装

元々あった「Evidenceモドキ」を拡張しました。 markdownに、

任意のSvelteコンポーネントを組み込む機構(mdsvex)
フォーム部品のコンポーネントの用意
Javascriptを処理する機構
front matterやCSVをDBとして扱う機構(DuckDBの強化)

等を追加しました。つまりは、markdownをlow code基盤として使う機構を強化したわけです。

たとえば、

  ```js:run compute
  const data = await runQuery('sales_by_month');
  const sum = data.rows.reduce((acc, r) => acc + r.revenue, 0);
  const avg = Math.round(sum / data.rows.length);
  append(`<p>年間売上合計 <b>${sum.toLocaleString()} 百万円</b>（月平均 ${avg.toLocaleString()}）</p>`);

こんなことや、

 ```sql:run regional_sales
SELECT region, sales
FROM (VALUES
  ('東京', 4200),
  ('大阪', 3100),
  ('名古屋', 2400),
  ('福岡', 1800),
  ('札幌', 1200)
) AS t(region, sales)
WHERE region = '{region}'

こんなことが書けますし、この{region}は<ParamInput name="region" label="地域:" default="大阪" options="東京,大阪,名古屋,福岡,札幌" />と書いたところから入力する… というようなこともできます。とりあえずlow code基盤として欲しそうなものは実装してあります。

次にやること

この次には、「メールの送受信」の機能を付加する予定です。 AIが生成したメールをそのまま送信するわけには行きませんし(ワークフロー)、返って来た返事はそのままAIに処理させたいです。このために専用のMUAとか作るのは面倒臭い上に良い方向とも思えないので、

wikiのエントリーをメールとしてそのまま送信
特定のアドレスに来たメールをwiki領域に保存
メールを評価して分類

といった機能をTablariumに付加して、「AIにメールを作らせ、人間が承認してから送信する」とか「返信を評価してPDCAを回したり案件継続させたりをAIにさせる」というようなことを可能にしようと思ってます。

AI時代のLCNC

こうやってlow code基盤的なものを作っていると、ちょっと前までのLCNCとはちょっと違うなという感じがして来ます。

まず、操作のほとんどの部分はエージェントがやることが前提となります。ですから、「人間が使いやすくする」ことよりは「オペレーションそのものはエージェントがやることが前提となり、人間はそこに指示を出す」ことを考えた方が良くなります。そうなると、フォーム中心のデータ入力画面が並ぶことよりは、文書化されたものを元に指示を出すことが中心となります。

会計処理のように「整合性を持ってデータベースを処理する」ことの価値がなくなるわけではありませんし、そういったものをAI化するにはMCPを用意してやるのが良いとは思いますが、Sales Management Systemは「文書のやりとりと整理」が中心となるので、データベースを使うというのは、単に実装の都合に過ぎません。そうなると、データベースシステムの上のアプリケーションとしてではなくて、文書管理システムの上のアプリケーションとして構築されてもおかしくはありません。この分類になるアプリケーションは、特にLCNCの守備範囲には多いのではないかと思います。 LCNCを使わない環境だとExcelがその地位にいると思いますが、この「Excel」って要するに「整列と罫線」のためですよね。「データベースの入口としてのExcel」ではありませんよね。

とか考えていると、ObsidianやNotionのプラグインの延長にアプリ的な使い方があるというのは現代的な方向だと思います。

まとめ

今回はSales Management Systemを作るという「お題」で色々やってみたのですが、図らずも「AI時代のLCNC」について考えると共に実装もできました。私の思った方向性が必ずしも正解であるとは思いませんが、今までのLCNCとは違った方向が求められていそうで、それに合ったような拡張をしたというお話でした。

Tabulariumのmarkdownを強化してアプリが書けるようにました

背景

実装

次にやること

AI時代のLCNC

まとめ

最近のエントリー

タグ一覧