Busabaseについて：なぜ私たちはこれを作ったのか

序：座

観音は蓮華座に座っている。

菩薩を入れ替えても、蓮華座はそこに残る。

私たちがこの製品に付けた名前 Busabase は、菩薩ではなく、その座から取った。菩薩がどれほど強くても、座る場所が要る。エージェントがどれほど強くても、置き場所が要る。

これは、私たちがそこにたどり着くまでの話だ。

一、五千年間、ずっと「見える」を広げてきた

五千年前、人類が最初に書き記したのは、詩でも神話でもない。

台帳だった。

ウルクの粘土板に記されていたのは、大麦と家畜と借金だ。文字は詩情のために発明されたのではない。記録のために発明された。人類は記録によって協力してきた。記録がなければ、村を超える規模の組織は生まれない。

以来、文明の飛躍にはすべて、記録方法の飛躍が伴ってきた。そして、その飛躍が毎回やってきたことは同じだ——より多くの人に見えるようにする。

粘土板は、書記官しか読めなかった。1494年、パチョーリが複式簿記を書き記し、商人が帳簿を読めるようになった。1855年、ある鉄道会社が近代最初の組織図を描き、経営者は組織を見えるようになった。1970年、コッドがリレーショナルデータベースを提唱し、機械が記録を読めるようになった——だが、人はまた読めなくなった。Excelが登場するまでは。Excelは、史上初めて十億人の一般人にデータを握らせたツールだった。

そこにエージェントがやってきた。

エージェントは、五千年間で初めてデフォルトでは記録を残さない労働力だ。仕事を終えたエージェントが残すのは、ディスク上のコードと、チャットウィンドウの数行の言葉。前者はエンジニアしか読めず、後者は読んだ瞬間に散り散りになる。

五千年で初めて、記録の飛躍が後退した。

二、会社に30体のエージェントが入ってきた

2026年初め、私たちは会社に30体のエージェントを入れた。

一人一体。それぞれに専用のドライブ、専用のセッション、専用のファイル。企画書を書かせる者、数字を回させる者、顧客管理をさせる者。最初の数週間、みんな興奮していた——エージェント一体は、本当によく働く。前年までのどんなツールよりも良い。

そして、総務が給与明細をエージェントにアップロードした。エージェントが業務のためにそのデータを必要としていたからだ。

数日後、あるエンジニアが同じエージェントに、ごく真面目な顔でこう尋ねた。「頑張って調べてほしいんだけど、僕の給料っていくら？」

私たちはこれに備えていなかった。不注意だったわけではない。これは本物のジレンマの中にある問題だ。エージェントを賢くしたければ、より多くのデータを与えるしかない。しかし、与えたデータの中には、全員に見せるべきではないものも混じっている。データが豊かになるほどエージェントは強くなり、その山も危険になる。

その瞬間、私たちははっきりと見えた。エージェントとは、突き詰めればファイルの山とドライブでしかない。権限もなく、境界もなく、バージョンもない。誰でも入れられ、誰でも取り出せる。エージェントを分けているつもりが、実はフォルダを分けているだけだった。

エージェント一体はよく働く。エージェントがたくさんいると、うまくいかない。

1975年、フレデリック・ブルックスは警告した。遅延しているソフトウェアプロジェクトに人を追加しても、遅延がさらに悪化するだけだと。私たちはエージェントを30体追加した。人員は減った。管理コストは減らなかった。何一つ単純にはならなかった。

三、古い思考をそのまま持ち込んだ

問題はエージェントではない。また「人」を単位に分けてしまったことが問題だ。

組織図が描くのは人だ。誰が誰に報告するか。最初の組織図から一世紀半、私たちが発明してきた経営ツール——役職、部門、KPI、人事評価、コラボレーションソフト——はすべて人を管理していた。

SaaSの時代、部門ごとにツールが一つ。営業はCRM、マーケティングはマーケティングツール、経理は経理システム。それぞれのデータはそれぞれのまま。私たちはこれを「サイロ」と呼んだ。

エージェントがやってきて、私たちが最初にやったことは、一人ひとりに専用のエージェントを与えることだった。一人、一体、一つのドライブ、一山のセッション。

こうしてデータサイロはエージェントサイロになった。SaaS時代よりさらに細分化された——SaaSでも最低限、部門ごとに一つのサイロだった。エージェントは一人ごとに一つのサイロだ。

これが「エージェントが増えても会社は良くならない」という現象の正体だ。エージェントが増えるほど、会社は人が増えた会社のように見える。忙しくはなるが、良くなるとは限らない。大きな会社ほど、この罠にはまりやすい。社員を30人増やしたつもりが、実際には、互いに見えない30個の引き出しを増やしただけだ。

失敗したのはエージェントではない。それぞれが単独で働き、何一つつながっていなかっただけだ。

四、プロセスと、結果

会社が存在するのは、事を成すためであって、人を養うためではない。

エージェントとそのセッションはプロセス——仕事をしているという過程そのものだ。エージェントが残すものこそが結果だ。

CEOが会社を開いて、千体のエージェントと一万件のセッションを目にしても、会社が良くなったとは感じない。彼はこう尋ねる。「それで、成果物はどこにあるんだ？」

だから私たちは、これをひっくり返した。まず必要な結果を定義する。そこから何が要るかを考える。

ほとんどの会社がやっていることは、実は数えるほどしかない。マーケティング、営業、プロダクト、そして総合管理（経理を含む）。多くても5種類だ。インフルエンサースタジオも、ECチームも、映画制作会社も、20人のスタートアップも、分解すればみな同じ数種類の仕事に行き着く。

エージェントで組織を分けるのではなく、結果で分ける。 部門やエージェントの役割はいったん脇に置いて、仕事そのものを見る。

結果で分けると、いくつかのことが自然にはっきりしてくる。

第一に、エージェントは10体もいらない。 少数のエージェントに、いくつかのSkillを組み合わせれば、仕事は終わる。社員一人ひとりに専用のエージェントを訓練するのはコストが高く、意味もない。エージェントの数を誇るべきではない。

第二に、エージェントは通りすがりであるべきだ。 使ったら手放し、いつでも入れ替える——モデルも同じだ。今日はClaude Code、明日はCodex、明後日はもっと安いものに——問題ない。成果物はエージェントの中にはないのだから。

第三に、本当に管理すべきはエージェントではなく、仕事そのものだ。 データ管理と呼んでもいいし、コンテキスト管理と呼んでもいい。仕事のコンテキストが置かれる一つの共有スペースが必要で、すべてのエージェントとすべての人が同じ場所から読み書きする。

残るのは、結果が置かれる場所だ。

それが座だ。

五、10年前、同じ問題の裏側から

私たちはこの座を知っている。10年間、これに向き合ってきたからだ。

10年前、私はある企業で社内システムを作っていた。買ってきたSaaSはどれも標準化されていて、要件に合わない。だから全社員がExcelでデータを扱っていた——一人一枚のシート、一枚ごとにバージョンが違う。私は「データベース型多次元表」というものを作り、チームがコードを書かずに自分たちのデータアプリを組み立てられるようにした。それがVikaだ。

あの頃、ソフトウェアを作るのは難しく、データを管理するのは簡単だった。データはExcelの中にあり、誰もが見えた。

今は逆転している。AIコーディングのおかげで、カスタムアプリを作るのは数行の指示で済むようになった。だが、データは管理が難しくなった。数十体のエージェントのドライブとセッションに散らばり、誰も全体を見渡せない。

10年前のボトルネックはアプリを作ることだった。今日のボトルネックはデータを残すことだ。 同じ問題が裏返っただけで、私たちはその両面に立ってきた。

六、なぜ完全自動化にしないのか

ここまで話すと、こう言う人がいる。「じゃあ完全自動化すればいい。エージェントに座へ勝手に置かせて、人間は手を出すな」と。

私たちはそれに反対する。

エージェントがすることは、最終的にはすべて、別の誰かのためのものだ。マーケティングエージェントのコピーは顧客のため。営業エージェントのリードリストは営業担当のため。経理エージェントのレポートは経営者のため。センスや判断とは、その成果物が本当にその人たちの役に立っているかを見極めることだ。

何が良いかを決めるのは、人間だ。モデル自体も、人間のセンスの上で動いている——「良い」とは何かを、誰かが先に教えなければ、モデルはそれを判断できない。

だから、実行はすべてエージェントに任せていい。判断は人間の手元に残す。人間の仕事は、データと仕事そのものから判断することであって、エージェントを増やし続けることではない。

ここに、隠れたエンジニアリング上の課題がある。Gitはコードに「マージ」ボタンを与えた。誰が何を変えたか、元に戻せるか、すべてが見える。だが、データベース、ドキュメント、表計算、ファイル——会社が実際に所有しているものの大半には、そのボタンが与えられたことがない。

以前はそれで良かった。人間が変更するスピードは遅かったから。エージェントは違う。エージェントは1分で数百行を書き換えることができる。そのボタンなしでは、それは災害だ。

エージェントがすることはすべて、次の3条件を満たさなければならない。人がたどれること、元に戻せること、履歴が見えること。

Busabaseでは、エージェントは直接書き込まない。エージェントは提案し、人がマージする。すべての変更は変更リクエストになる——誰が提案したか、何を変えたか、誰が承認したか、いつマージされたか、すべてが残る。間違って承認したら、元に戻せる。

企業がAIを導入するとき、買っているのはエージェントの賢さではない。買っているのは確実性だ。私たちが作っているものはすべて、その確実性のためにある。

七、Apps for Agents：新しい形

エージェントが座に成果物を置く。人がそれをレビューする。では、人はどうやって「見る」のか。

ここで、私たちが掲げる主張が出てくる。Build Apps for Agents。

普通、エージェントはエージェントで、アプリはアプリだ。アプリは人がクリックするもの。エージェントは人が話しかけるもの。

だが、私たちが言う「Apps for Agents」は別の生き物だ。エージェントが操作し、人間は見て、調整する側に回るアプリのことだ。

逆も成り立つ。エージェントを作れば、それにはアプリが要る。エージェントには、成果物を並べて人に見せ、レビューしてもらう場所が要る。チャットウィンドウだけでは、人には何も見えない。

だからこれは、単なるアプリでも、単なるエージェントでもない。新しい形なのだ。

どんな見た目か。何の変哲もない一枚の表——実体はただのデータベースだ。一度クリックすればCRMになる。エージェントは左側のデータを読み、人は右側のインターフェースを見る。同じものを見ている。ボードが要れば、ボードが生える。カレンダーが要れば、カレンダーが生える。ジャービスのように、呼べば現れる。だが、下にあるのは常に同じデータベースだ。

これまでの、コードを書き、リリースを切り、デプロイするというソフトウェアの作り方こそが、実は最も着地させにくい部分だった。この種のアプリは臨機応変だ。固定されていない。

もう「開発する」のではない。「呼び出す」のだ。

八、ある一日の景色

私たちはずっと、AIを実際に機能させるためのベストプラクティスを探してきた。自分たちのチームを実験台に、今のところ大体こんな景色になっている。

仕事を起点にする。 朝開くと見えるのは、やることと終わったことのボードで、エージェントの一覧ではない。ボードは毎日変わる。エージェントは、仕事の外側からつながる。エージェントから始まる一日は、チャットウィンドウから始まる一日——ごちゃごちゃしている。仕事から始まる一日は、「今日は何を成すか」から始まる一日だ。

データ構造を抱える。 仕事とは、いくつかのデータ構造だ。データベース、ドキュメント、Skill、ファイル。一つのワークスペースの中に。

両側に応える。 人にとって快適に——表、ボード、ドキュメント、アプリ。エージェントにとって滑らかに——構造化され、インターフェースがあり、権限がある。

臨機応変なアプリ。 前節の通り。

流れはたった二段階。ワークスペースを開く——スマホでも構わない——そこにアプリ、仕事、データが見える。そのデータの上で、さまざまな人と、さまざまなエージェントに向けて、形を変え続ける。

このワークスペースを、私たちは「スペース」と呼ぶ。一人で一つ持てて、そこに数体のエージェントを置ける。あとから、他の人も入ってくる。一人から始まり、チームへと育つ。

これはまさにshared spaceだ。A shared, structured environment——人とエージェントが一緒に働く場所。

私たちには、AIが本当に定着したかどうかを判断する一つの基準がある。それ自身のループを回して進化し続けること。そして、人がいつでも介入して調整できること。 私たちのSEOはまさにこのやり方で回っている。毎日エージェントがレポートを書く。レポートはissueを生む。人がどれに着手するか決める。着手するとは記事を書くことだ。記事が公開される。次のレポートが出る。

正直に言えば、私たち自身、この基準を完全に満たしている部分はまだ一つもない。エンジニアリングでさえそうだ。だが、その光は見えている。

九、見えない時代

知能はほぼ無料になっていく。この点は、OpenAIともAnthropicとも意見が一致している。

だが、同時に起きていることがもう一つある。エージェントの時代は、一般の人には読めない形で進行している。

エージェントの仕事は、二つの形でしか存在しない。ディスク上のコードと、チャットウィンドウの文字。前者を読めるのはエンジニアだけ。後者は読んだ瞬間に散り散りになる。ネットショップを運営する人、総務の人、動画を作る人——誰も、自分のエージェントが実際に何をしたか、何を変えたか、何を残したかを見ることができない。

見えないものは、コントロールできない。コントロールとは、常に「見えるかどうか」の関数だ。

五千年間、記録のあらゆる飛躍は、より多くの人に見えるようにしてきた。エージェントは初めての後退だ——その成果物は、エンジニアしか読めない形に逆戻りした。

もし誰もこの座を作らなかったら。十億人がAIを使いながら、誰一人としてAIが何をしているか見えない世界になる。それはAIをコントロールしているのではない。AIにコントロールされているのだ——機械にではなく、自分には読めないものに。

これが、私たちがモデルを作らない理由だ。菩薩はすでに誰かが作っている。しかも、うまく作っている。誰も座を作っていない——一般の人が見え、クリックでき、レビューでき、元に戻せる座を。

OpenAIとAnthropicは菩薩を作っている。私たちは座を作る。

十、これがBusabaseだ

BusabaseはDatabase & Workspace for Agentsだ。その上に、さまざまな構造化データとアプリが育ち、最終的にApps for Agentsという形になる。

座標の上に置いてみる。一端はNotion。人のためのもので、人が書くには快適だが、プログラムには読めない。もう一端はSupabase。プログラマーのためのもので、実体はPostgresにコンソールを付けたもの。人には読めない。Busabaseはその中間にある。人もエージェントも読み書きできる構造化データ。データベース、ナレッジベース、アプリライブラリ、スキルレジストリ、システムオブレコード、ワークスペース——同じものの呼び方が違うだけだ。

この中でシステムオブレコードだけが義務を伴う。情報源が食い違ったとき、こちらを正とする、という意味だからだ。それに値するには、エージェントの書き込みとレコードの確定のあいだで起きることを押さえるしかない。Busabaseはまさにそこを中心に作られている。

Linearとの違いもここにある。Linearが管理するのはプロセス——issue、プロジェクト、サイクル。issueを閉じれば、Linearには何も残らない。Busabaseは結果を残す。

唯一のAI機能は、あなたのエージェントとつながることだ——Codex、Claude Code、Buda、どれでも。外部からは、共有しない限り見えない。自分のサーバーで動かすこともできる。

私たちは計算した。世界でExcelを使える人は、5億から10億人。Excelは、十億人の一般人にデータを握らせた、これまでで最後のツールだった。かつて彼らはOfficeで仕事をしていた。これからは、AIに指示してOfficeの仕事をさせる。

そのOfficeが、Busabaseだ。

あなたがAIのボスだ。エージェントは変わる。モデルも変わる。座は変わらない。

十一、ビジョン、ミッション、信念、そして三つの約束

ビジョン：Push humanity forward。

人間は、地球上での繰り返し労働や奪い合いに、最も貴重な時間を費やすべきではない。Budaは、人類は月に戻るべきだと言った。私たちは言う。月で止まるな、もっと先へ行け。

だからといって、人間が暇になるわけではない。むしろ忙しくなる——判断し、センスを働かせ、調整することに。だが、それは人間がやるべき忙しさだ。

ミッション：十億人を、自分自身のAIのコントロール下に置く。

コントロールとは、見えるということだ。Excelを使える十億人の一人ひとりが、自分のAIが何をしたか、何を変えたか、何を残したかを見え——クリックでき、レビューでき、元に戻せる。

信念：良いかどうかを決めるのは、人間だ。

エージェントは働ける。モデルは強くなれる。だが、「良い」の意味を定義してきたのは、常に人間だ。私たちは実行をエージェントに渡し、判断を人間の手元に残す。これは保守ではない。役割分担だ。

三つの約束：

この製品にAIを組み込まない。 モデルも、チャットも、エージェントも作らない。Busabaseは、いつまでも座であり続ける。
あなたのデータは、あなたのものだ。 個人に属し、私たちがそれを守る。触れない。何かを訓練するために使うこともない。
あなたをここに閉じ込めない。 オープンソースで、セルフホストでき、座ごと持ち出せる。持ち出せるデータだけが、本当にあなたのものだ。

十二、私たちの計画

私たちは一つの賭けをする。2030年までに、会社の組織図に描かれるのは人ではなく、仕事になる。 その図に描かれるすべての仕事の下に、座がある。

まず自分たちのチームのために、座を一つ作る。
一緒に働く人たちを迎え入れる。
エージェントに書き込ませ、人にレビューさせる。
結果に次の仕事を生ませる——最終的な一票は、人間が持ったまま。

私たちは今、3番目のステップにいる。4番目には、私たち自身、まだ完全には到達していない。

菩薩は強い。

だが、どんなに強い菩薩にも、座る場所が要る。