Kylonを作った理由

AIを導入したチームは、どこも同じことをしている。タブを開き、コンテキストを貼り付け、何かを受け取り、それをまた別の場所に貼り付ける。AIは本当の会話を見ることがない。プロジェクトが遅れていることも、3つ前のスレッドで決定が下されたことも、AIは知らない。

私たちは、それとは違うものを求めた。

私たちが繰り返し目にしてきた課題

Kylonを作る前、私たちはチーム向けのツールを開発していた。コラボレーション製品、社内プラットフォーム、仕事が実際に行われる場所に根ざしたものを。そして「AI機能」が実装されるたびに、決まって同じ形で登場した——サイドバー、オートコンプリート、既存の画面に後付けされた「生成」ボタン。

AIがチームに加わることはなかった。誰かが引き出しから取り出すまで、ただそこで待っているだけだった。

単発のタスクならそれで十分かもしれない。しかし本当の仕事は単発ではない。本当の仕事には、何週間もかけて積み上がるコンテキストがある。履歴があり、関係者がいて、依存関係があり、積み重なる判断がある。それをすべてテキストボックスに貼り付けることはできない。

チームに居続けるagent

そこで私たちは、別の考えを軸にKylonを設計した。agentは製品の「機能」ではなく、workspaceの「メンバー」であるべきだ——という考えだ。

Kylonでは、agentはチャンネルに参加する。スレッドを読む。先週火曜日に何があったかを覚えている。GitHub、Notion、Gmail、Slack、Linearといったツールと連携し、内容を要約するだけでなく、実際にそこで行動する。

逐一指示する必要はない。何が必要かを伝えれば、agentは自分で考えて動く。行き詰まれば確認を求め、承認が必要なら待つ。完了すればチームが見える場所に結果を投稿する。

今、これが重要な理由

AIモデルの性能は、十分なレベルに達した。もはやそこがボトルネックではない。

ボトルネックは、モデルと仕事の間にある空白だ。配線、コンテキスト、メモリ——そして「提案する」だけでなく「実行する」能力。

私たちが話を聞くチームは、みな同じことを言う。「ChatGPTは使っているけど、下書き専用だ」。「Copilotを試したけど、自社のコードベースを理解していない」。「毎回コンテキストの準備に20分かかる」。

それは知性の問題ではない。アーキテクチャの問題だ。そして、それこそが私たちが解いている課題だ。

私たちが信じること

すべてのチームの次のかたちには、AIメンバーが存在すると私たちは考える。見せかけのためではなく——会社のことを既に知り、ツールを使いこなし、初日から貢献できる新しいチームメンバーを迎えるように。

agentにはメモリ、アイデンティティ、そして自律性があるべきだと考える。誰と働いているか、これまで何をしてきたか、チームが何を大切にしているかを理解していなければならない。

そして、workspaceはそのために設計されるべきだと考える。適応でも、後付けでもなく、最初からそのために作られるべきだ。

それがKylonだ。