Bika から Buda へ: ビジョンは同じまま、なぜ技術の道を変えるのか

長い間、Bika は私たちにとって単なる製品名ではありませんでした。

そこには、次世代の仕事ソフトウェアについての私たちの考えと、実際の創業の歩みが詰まっていました。

私たちは、ソフトウェアが単に仕事を記録するだけではなく、仕事を前に進めるものであってほしいと思ってきました。
自動化は単なるフロー接続ではなく、文脈を理解してほしい。
AI はチャットするだけではなく、チームの日常業務に参加してほしい。

だからこそ、この文章は簡単には書けません。

まず、はっきり伝えたいことがあります。

Bika は完全になくなるわけではありませんが、限定的なメンテナンス段階に入ります。私たちの主要な製品の未来は Buda に移ります。

これはきれいに整えた広報文ではありません。何度も悩み、何度も Bika をさらに前へ進めようとした末に、ようやく認めた結論です。

最初に結論: Bika と Buda のビジョンは変わっていない

この 2 つの製品の根本にあるビジョンを 1 行で言うなら、ずっと同じでした。

会社全体の仕事を動かす AI Organizer。

私たちは最初から、ただ会話するだけの AI を作りたかったわけではありません。

本当に作りたかったのは、

• 文脈を理解し
• ツールを使い
• 継続的にタスクを実行し
• チームと協働し
• 会社の日々の運営に参加できる

そんなシステムでした。

つまり、今回変わったのはビジョンではありません。

変わったのは技術の道であり、プロダクトの形であり、そして同じビジョンを実現するには Bika の道が最善ではなくなったと私たちが認めたことです。

Bika が私たちに教えてくれたこと

もし Bika がなければ、Buda もありませんでした。

Bika は失敗した前段ではなく、むしろ重要な問いを深く掘り下げたからこそ、力と限界の両方が見えた段階でした。

1. Bika は、複雑な仕事を 1 つの強力なシステムに統合できると証明した

Bika は最初から野心的な製品でした。

単一機能ではなく、分散していた複数の仕事の層を 1 つのシステムにまとめようとしていました。

• spreadsheet / database
• agent
• docs
• automation
• dashboard
• template package

私たちの考えはシンプルでした。企業の難しい問題は、単独のツールでは解けないことが多い。

本当に複雑な仕事はたいてい、

• データ構造
• 業務フロー
• ドキュメント協業
• 自動実行
• AI による理解と生成

をまたいでいます。

だから Bika は、それらを template package にまとめ、ユーザーに機能の寄せ集めではなく、動く仕事の解法を渡そうとしました。

この発想自体は、今でも正しかったと思っています。

そして率直に言えば、Bika はとても powerful です。

深く使えば、一般的な SaaS ではまとめ切れない複雑な仕事を実際に扱えます。

2. ただし、その強さは同時に複雑さも生んだ

spreadsheet、agent、doc、automation を 1 つのシステムに溶かし込み、さらに template package にすることで、製品は非常に強力になりました。

しかし、その代償もありました。

インタラクションの複雑さが上がっていったのです。

新しいユーザーは 1 つの製品を学ぶのではなく、仕事の仕組み全体を理解しなければならなくなります。

その結果、

• オンボーディングのハードルが上がる
• 心理的負荷が重くなる
• 機能は多いが最初の印象が軽やかでなくなる
• 本来のプロダクト哲学の魅力が薄れていく

という現実がありました。

後になって強く感じたのは、Bika の問題は「弱いこと」ではなく、複雑な仕事を解こうとする中で、その複雑さをそのままユーザーにも渡してしまったことでした。

機能は本当に強い。

でも、入り口は簡単ではない。

そして製品の第一印象が「未来の働き方」よりも「学習コストのある強力なシステム」に寄っていくと、プロダクトの哲学はどうしても弱くなります。

3. もっと根本的な制約は、Agent エンジンそのものにあった

さらに深い問題もありました。

Bika の Agent 層は、依然として API orchestration に強く依存していました。

これは多くのシナリオでは十分に機能しますし、価値あることもたくさんできます。

しかし、agent を「呼び出される機能」ではなく「長期的に働く AI 社員」に近づけようとすると、限界が見えてきます。

本当に働く agent は、外から起動される API 呼び出しの連鎖だけでは足りません。

それには、自分自身の作業環境が必要です。

必要なのは、

• 独立した作業ドライブ
• 永続的なコンテキスト
• 自分のファイルシステム
• 分離された実行空間
• 長時間動くサンドボックス
• 実際の作業をこなせる runtime

です。

ここが、Bika の構造的な弱点でした。

Bika は多くの能力をつなげられましたが、agent 自身が独立したサンドボックスドライブと持続的な作業空間を持つことを第一原則としては設計されていませんでした。

そして私たちは次第に、これは付加価値ではなく、基礎そのものだと考えるようになりました。

独立した作業空間も、隔離されたサンドボックスも、長期的にファイルや文脈や実行履歴を蓄積できるドライブも持たない agent は、本当の意味で働く存在というより、何度も呼び出される能力に近いからです。

4. 私たちはもう「AI 機能が豊富な SaaS」を作りたいわけではなかった

Bika を進めるほど、私たちは AI を既存ソフトウェアに少しずつ足していくこと自体には、もう満足していないと感じるようになりました。

私たちが本当にやりたいのは、

AI が働くことを前提に、ソフトウェアそのものを作り直すこと

でした。

これが、私たちの中で最も大きかった葛藤です。

それを認めると、Bika の上で積み増せる仕事の多くが、本当に行きたい未来から少しずつ外れていくことも認めなければなりません。

なぜ最終的に pivot を決めたのか

率直に言えば、Bika に主要な力を注ぎ続けることが、もはや最も誠実な選択ではなかったからです。

Bika に価値がないからではありません。

私たちが本当に全力で賭けるべき未来が、別の技術基盤と別の製品重心を必要としていると、ますます確信したからです。

その道が Buda になりました。

一文で言えば、

• Bika は AI、表計算、ドキュメント、自動化を 1 つの強力な仕事システムに統合する試みだった
• Buda は AI Organizer が本当に会社を動かせるように、agent-native な runtime から作り直したもの

という違いです。

Buda が技術的に変えたこと

Buda は突然現れた新しい物語ではありません。

それは、Bika を作る中で得た最も深い確信を引き継ぎながら、焦点を絞り、別の技術前提から組み直したものです。

もし Bika が私たちに、

• AI は単なる会話ではない
• 自動化は単なるトリガーではない
• システムには文脈と記憶が必要だ
• 仕事ソフトは実行できなければならない

と教えてくれたなら、

Buda はさらにこう問い直します。

AI が本当にチームメンバーになるなら、どんな runtime、どんな workspace、どんな製品構造が必要なのか。

だから Buda は最初から別の場所から始まっています。

重視しているのは、

• 単一アシスタントではなく multi-agent collaboration
• 一時的な会話ではなく persistent workspaces
• Browser、Terminal、Drive、Git のような実行環境
• 個人のお試しではなく team-level orchestration
• 長時間動き、分離され、管理できる agent infrastructure

です。

より具体的には、Buda は次の点で違います。

• agent は cloud sandbox の中で動く
• 各 agent は独自の independent Drive を持つ
• workspace は isolated で、文脈が混ざらない
• agent はテキストを返すだけでなく、実行環境の中で実際に作業できる
• 基盤としてより強い Coding Agents と Agent Skills を持つ

つまり Buda は、「AI を追加した SaaS」というより、AI worker のための operating environment に近いのです。

単に agent をサポートするのではありません。

まず 独立したサンドボックス、独立したドライブ、永続的な workspace を作り、その中で agent が本当に暮らし、働けるようにする。

ここが本質的な違いです。

これは簡単な決断ではなかった

外から見ると、pivot は短い一文に見えるかもしれません。

「会社が方向転換した。」

でも内部では、そんなに単純ではありません。

それは多くの場合、

• 以前の計画の一部を続けないと認めること
• すべての積み上げがそのまま延長できるわけではないと受け入れること
• 古いユーザー、古いページ、古い物語と新しい未来の緊張に向き合うこと
• これから何のために作るのかをもう一度答え直すこと

を意味します。

私たちにとって難しかったのは、新しい名前を考えることではありませんでした。

難しかったのは、これを認めることです。

Bika を主戦場とし続けても、私たちが本当に行きたい場所には届かない。

Bika ユーザーにとって、これは何を意味するか

曖昧にはしたくありません。

これからは、

• Bika は限定的なメンテナンス段階に入ります
• 私たちは機能拡張よりも基本的な安定性を優先します
• 新しい中核的な製品投資の多くは Buda に向かいます

これは Bika が明日なくなるという意味ではありません。

既存ユーザーを突然切り離すという意味でもありません。

でも、1 つ大切なことを意味します。

これからの私たちの製品方向や、新しい能力の進化を見たいなら、Buda に注目してほしいということです。

なぜこれを公開して伝えるのか

私たちは、静かにトラフィックだけを切り替えたり、曖昧なコピーでごまかしたくありません。

方向が変わったなら、なぜ変わったのかを説明するべきです。

ユーザーには、その誠実さが必要だと思っています。

そして正直に言えば、これは私たち自身のための文章でもあります。

これは単なる製品紹介ではなく、1 つの節目です。

過去を率直に振り返り、今の選択を説明し、未来にどこへ賭けるのかをはっきりさせるためのものです。

共感してくれたなら、Buda を見てほしい

もし Bika をここまで追ってくれたなら、本当にありがとうございます。

皆さんのフィードバック、批判、そして実際の使い方が、Buda を形作りました。

そして、もしあなたが次のような問いに関心があるなら、

• AI は本当にチームの仕事を担えるのか
• agent は demo を超えられるのか
• ソフトウェアはツールの集合から AI worker system へ進化するのか

ぜひ Buda を見てください。

Visit Buda

Bika が、私たちをここまで連れてきてくれました。

そしてこれからの未来は、Buda の上に築いていきます。

• Ultimate Guide: How Marketing Automation Increases Online Store Sales
• Contract Workflow Automation: How AI Is Transforming Contract Management
• AI Automation Benefits: Cut Costs, Save Time, and Scale Faster in 2026
• 6 Best Tools for Automating Contract Workflows in 2026 (Reviewed & Compared)
• 9 Key Benefits of AI Workflow Automation That Drive Real Results