Busabase は AI テーブルに見える。でも、解決する問題で判断してほしい

Busabase は新しい AI テーブルや Wiki ではありません。コンテキストとスキルを共有ベースに置き、どのエージェントも人も仕事を引き継げるようにします。

Busabase チーム
← ブログに戻る
Busabase は AI テーブルに見える。でも、解決する問題で判断してほしい

日々の会話の中で、ほぼ毎日のように聞かれる質問があります。「結局、どんな問題を解決しているんですか? ずいぶん抽象的なプロダクトに見えますね」。

もっともな質問です。Busabase を初めて見た人の多くは、まず知っている何かに当てはめます。サイドバーがあり、型付きのフィールドを持つテーブルがあり、ドキュメントがある。「つまり AI 版の Airtable ですね」「エージェント向けのナレッジベースですね」「API 付きの Notion ですね」。

第一印象としては自然な推測です。ただ、それで判断するのは間違いです。金づちと肉たたきも見た目はよく似ています。手にしているのがどちらかは、何に使う道具なのかを考えればわかります。この記事では機能の紹介ではなく、いちばんよく聞かれるこの質問に答えます。Busabase はどんな問題を解決するのか。そして、それはあなたのチームが抱えている問題なのか。

似て見える 4 つのもの、それぞれが解決する問題

どれも優れたプロダクトです。ただ、それぞれ別の仕事のために作られています。

似ているもの解決する問題書くのは読むのは
AI テーブルとローコード(Airtable、AITable、Retool など)コードを書かずに社内ツールやアプリを作る人人
ナレッジベースとドキュメント(Notion、Confluence など)書き残して、同僚が見つけられるようにする人人
エージェントのメモリとベクトルストア1 つのエージェントが以前見たことを思い出せるようにする1 つのエージェント同じエージェント
Git リポジトリ開発者が一緒に変更するコードをバージョン管理する開発者開発者と CI

右の 2 列に注目してください。どの行でも、書く側と読む側は同じ種類の参加者です。

Busabase の出発点は、どの行にも当てはまらない状況です。チーム全体のエージェントと人が同じ業務に取り組み、全員が同じコンテキストと同じ仕事のやり方を必要としている。

仕事をエージェントに任せると、仕事そのものを共有の場所に置く必要がある

日々の仕事の大半を、すでにエージェントがこなしている会社を想像してください。ブログ記事を書いて公開する。CRM を更新し、営業オペレーションを回す。コードを書き、プロジェクト計画を最新に保ち、製品企画を下書きし、デザインを手伝う。経費の承認申請を出し、前四半期の請求書を探し出す。

一日中画面をクリックして過ごす人はどんどん減っています。人は依頼し、確認し、決める側に回ります。

そうなると、あることが変わります。仕事はもう誰か一人の画面の中にはありません。かといって一つのエージェントの中に置いておくこともできません。明日それを引き継ぐのは、別のエージェントか別の人かもしれないからです。顧客リスト、公開手順、リリースの進み具合。すべてを、どのエージェントもどの人も手の届く場所に置く必要があります。

私たちが「エージェントはステートレスであるべき」と言うのは、この意味です。エージェントは仕事を片づける手段であり、コンテキストこそが仕事の中身です。そしてコンテキストは共有されなければなりません。

エージェントを使い始めたチームが最初にやりがちな間違い

エージェントを使い始めたばかりのチームの多くは、同じ間違いをします。人を採用するようにエージェントを「採用」してしまうのです。

SEO エージェント、営業エージェント、プロジェクト管理エージェント、デザインエージェント。それぞれに専用の指示と、たくさんのスキルが与えられます。半年後、チームには数十のエージェントと数百のスキルがあり、その大半は使われないまま放置されています。その一方で、

  • 同じコンテキストがあちこちにある。 製品情報、ブランドのルール、現在の顧客リストが各エージェントの指示に貼り付けられ、コピー同士が少しずつずれていきます。
  • 新しいプロジェクトのたびにゼロから始まる。 エージェントを新しく作るたびに、背景情報と指示を作り直すことになります。
  • チームの仕事のやり方が、一人の設定に閉じ込められる。 ブログ記事の公開手順や見込み客の判定手順は、そのエージェントを作った人のところにしかありません。他の人には変えられません。
  • どれが最新なのか誰にもわからない。 昨日、あるエージェントが顧客レコードを更新しました。それは最新の状況なのか、古いドキュメントからの推測なのか。

根本にあるのは、カテゴリーの取り違えです。エージェントもスキルも、本質的には「インタラクションの入口」、つまり仕事を始めるための手段であって、役職ではありません。 組織図に合わせてエージェントを設計すると、入口ばかりが増え、コンテキストはそれらに切り分けられます。どのエージェントも一部しか知らず、十分に知っているものはいなくなります。

左:エージェントを役職として設計すると、それぞれがコンテキストの一部と専用のスキルしか持たない。右:どのエージェントも人も、レコード・ドキュメント・スキル・アプリをまとめた共有ベースから仕事に入る。

私たちの実感では、コンテキストがうまく合わせられたエージェント 1 つのほうが、それぞれ一部しか持たないエージェント 10 個よりも役に立ちます。問うべきは「この仕事はどのエージェントの担当か」ではなく、「どのエージェントがこの仕事を引き継いでも、正しいコンテキストと正しい手順を見つけられるか」です。

Busabase が解決するのは、この問題です。「もっと良いテーブルが必要」でも「もっと良い Wiki が必要」でもなく、コンテキストとスキルを、エージェント同士・人同士で共有できないという問題です。

エージェントはステートレスに、コンテキストはベースに

私たちの答えはシンプルな役割分担です。エージェントはステートレスにして、会社の知識と仕事は、人が見て管理できる共有ベースに置く。

エージェントは入れ替わります。モデルを切り替えることもあれば、チームの中で好みのアシスタントが人によって違うこともあるでしょう。そのたびにやり直しになるべきではありません。残り続けるのはベースです。

  • レコード:顧客、商談、タスク、コンテンツ計画、請求書、決定事項。構造化されているので、どのエージェントも正確に読み、正確に更新できます。
  • ドキュメント:人やエージェントが作業前に知っておくべき背景。
  • スキル:繰り返し発生する仕事の手順。記事の公開方法、見込み客のフォロー方法、承認申請の出し方など。
  • アプリ:同じデータの上に載る小さな画面。聞くより見たい人のためのものです。

それぞれの人が使い慣れたエージェントを、同じベースにつなぎます。作業の最初にすでにあるものを読み、最後に結果を書き戻す。次のエージェントや次の人は、ゼロからではなくそこから続けます。

スキルの共有:手順は一度変えれば全員に届く

見落とされがちなのがスキルです。

Busabase では、スキルはテーブルやドキュメントと同じく、ワークスペースの中のひとつのノードです。Busabase がエージェントに渡す指示では、どの作業も同じ手順で始めるよう求めています。まずワークスペースを検索して、その仕事用のスキルやプロンプトがすでにあるかを確かめ、あればそれに従う。1 つのエージェントがさまざまな仕事をうまくこなせるのは、このためです。「SEO エージェント」でなくても、あなたのチームの公開スキルさえ見つけられれば、チームのやり方どおりに記事を公開できます。

Busabase の Playbooks ページ。ワークスペースのスキルとカスタムプロンプトが並び、エージェントは指示を受けるたびにまずここを見ます。

これで 2 つのことが変わります。

  1. 一貫性。 誰が依頼しても、どのエージェントが担当しても、仕事は同じ手順で進みます。手順はひとつしかないからです。
  2. 当事者が変えられる。 仕事の責任者が、エンジニアに頼まずに、ワークスペースの中で普段の言葉で手順を書き換えられます。次の実行から、すべてのエージェントが新しい版を使います。

たとえるなら、これまでは手順が各エージェントの頭の中にありました。今はチームのハンドブックに書かれていて、どのエージェントも同じハンドブックを読みます。

共有コンテキストは共有メモリではない

これを「共有メモリ」と呼びたくなるかもしれません。私たちはあえてその言葉を使いません。別のものを指しているからです。

メモリは、エージェントが思い出すものです。そのエージェントだけのもので、曖昧で、確かめにくい。役には立ちますが、それはエージェントのものです。

共有コンテキストは、チームが「これです」と指し示せるものです。顧客レコード、手順、進捗の更新。持ち主がいて、出どころがあり、誰が変更したかの履歴があります。「このプロジェクト、今週は何が変わった?」と聞いたとき、答えは後者から来るべきです。

違いについては Agent memory vs knowledge base vs system of record で詳しく書いています。

では、なぜテーブルに見えるのか

テーブルが、機械とコンテキストを共有するいちばん明快な形だからです。顧客の更新日が型付きのフィールドにあれば、どのエージェントも推測せずに読み、更新できます。同じ事実が段落の中に埋もれていれば、そうはいきません。

Busabase のベース。型付きのフィールドなので、どのエージェントも推測せずに読み書きできます。

テーブルは形であって、目的は共有コンテキストです。ドキュメント、スキル、アプリがテーブルの隣にあるのも同じ理由で、それぞれがある種類のコンテキストにとっていちばん明快な形だからです。

そして、エージェントが機械の速さでこの共有コンテキストに書き込むようになった以上、ベースはそれを信頼できる状態に保つ役目も担います。各エージェントが何を読み、何を変えられるかはあなたが決めます。重要な書き込みは、提案として届き、あなたがレビューしてから確定させることもできます。それ以外はこれまでどおり速いままです。何が、誰によって変わったかはいつでも確認できます。詳しくは AI エージェントのための記録システム のページにまとめています。

仕事の責任者に向けた 4 つの問い

エージェントを使って仕事を回すチームや事業を率いているなら、自分に問いかけてみてください。

  • チームが用意したエージェントとスキルがいくつあり、そのうち実際に使われているのはいくつか、把握していますか。
  • あるエージェントを作った人が明日いなくなっても、他の誰かがその動き方を変えられますか。
  • 同じ背景情報や同じルールを、複数のエージェントに貼り付けていませんか。
  • 今週何が変わったかを知りたいとき、エージェントに聞きますか。それとも会議を開きますか。

答えに不安を覚えたなら、問題はおそらくエージェントではありません。コンテキストの置き場所です。

ひとつのプロジェクトで試す

Busabase は、AIエージェントのための、オープンソースのデータベース兼ワークスペースです。エージェントと人が同じ構造化データ、ドキュメント、スキル、アプリを共有し、重要な書き込みはレビューを経て信頼できる記録になります。

役に立つかどうかを確かめるのに、チームを組み直す必要はありません。プロジェクトひとつから始められます。

  1. そのプロジェクトの最新の進捗と、チームの進め方をワークスペースに入れる。
  2. すでに使っているエージェントを接続する。エージェントごとの接続方法はこちら。
  3. 「このプロジェクト、今週は何が変わった?」と聞いてみる。

Busabase Cloud を無料で始める。すべてを自分のパソコンに置いておきたいなら Personal Desktop をダウンロードできます。手早く始めたいなら、テンプレートセンターにスキルまで書き込まれたワークスペースが揃っています。