Product · MARKHUB

なぜ私たちは、もうひとつのAIワークスペースをつくるのか

古典的な版画の技法で描かれた円卓の議論と、その上に浮かぶ現代的な吹き出し

いま、AIワークスペース市場はすでに混み合っている。

Buzz.xyz、Grokのボット、そしてSlackのような既存のコラボレーションツールまで、どこもエージェントを組み込んでいる。方向性も似ている。人が交わした会話を理解し、その会話を実際の業務につなげることだ。

では、なぜ私たちはこの競争の激しい市場にあえて飛び込んだのか。

私は以前から、人類の進化を導いてきた最も強い力のひとつは想像力だと考えてきた。

人はまだ存在しないものを頭の中に描き、それを現実にする。脳を、ただ生き延びるための道具としてだけ使ってきたわけではない。建物を想像し、製品を想像し、会社を想像し、まだ世界にない技術を想像する。

そして、それを実行する。

想像が実行された瞬間に、価値が生まれる。

Markhubはこの考えから始まった。

最初はデザイナーの問題を解こうとした

私は長いあいだデザイナーとして働いてきた。

当時いちばん不便だったもののひとつが、クライアントのフィードバックだった。

フィードバックは一か所からは来ない。打ち合わせで語られることもあれば、メールで届くこともあり、メッセンジャーに残されることもある。突然電話がかかってくることもある。

問題はその次だ。

デザイナーはそのフィードバックを整理し直し、作業に反映し、成果物をつくり、また別のチャネルで共有する。

この過程で何かひとつでも抜ければ、やり直しになる。日程が押し、コストが発生する。

だから最初はとても単純に考えた。

「クライアントとデザイナーがフィードバックをきちんとやり取りできる道具をつくろう。」

それが初期のMarkhubだった。

そして、失敗した。

振り返れば問題意識は正しかったが、その問題を解くために必ずしも新しい道具が必要だったわけではない。

仕事のうまい個人が丁寧に管理すれば解けてしまう問題でもあった。

そこで二つ目の仮説を立てた。

チャットの上に、デザインフィードバックに特化した機能を載せてみよう。

この仮説も失敗した。

結局のところ私たちがつくっていたのは、「デザインチームのための、少し違うSlack」に近かった。

二度の失敗から、ひとつを見つけた

プロダクトの実験は失敗したが、その過程で不思議と残り続ける問いがひとつあった。

何がデザイナーを働かせるのか。

そして反対側からは、

クライアントは何のためにお金を払うのか。

掘り下げていくと、答えは驚くほど単純だった。

リクエストと結果(Request → Result)だった。

クライアントが知りたいのは、結局これだ。

「私が頼んだものは、どんな結果になったのか。」

「私の要件はきちんと反映されたのか。」

「いつ結果を受け取れるのか。」

一方でデザイナーはこう考える。

「このリクエストを処理するには、何をしなければならないのか。」

「どれくらい時間がかかるのか。」

「ここからどんな後続の作業が生まれるのか。」

「そしてこの仕事で、どれだけの価値をつくれるのか。」

ごく小さなフリーランスのデザイン案件でさえ、ほどいてみるとかなり複雑だ。

要件を分析し、レファレンスを調べ、初稿をつくり、レビューとフィードバックを受け、修正版を共有し、最終承認を得てから納品する。

結局、はじめにはリクエストがあり、終わりには結果がある。

そしてそのあいだに、数えきれない仕事が発生する。

ところが、これはデザインだけの話ではなかった

この構造を他の産業に当てはめてみると、もっと面白くなる。

たとえば製薬会社がひとつの製品をつくるとしよう。

商品を企画し、成分を調べ、配合を定義し、試作品をつくる。名前とブランドを決め、工場で量産し、パッケージングし、マーケティングし、配送し、オフラインの棚に納品する。

思いつくだけでも十段階近い工程になる。

そして各段階で見積書、エクセル、企画書、報告書、デザインファイルなどが生まれ、修正される。

ひとつの製品が実際に世に出るまで、各ファイルのバージョンまで含めれば、数十から数百回の更新が起こりうる。

そこに作成者がいて、検収者がいて、意思決定者がいる。

誰かが依頼し、誰かが実行し、誰かが確認し、誰かが承認する。

産業はまったく違っても、構造は驚くほど似ている。

要件 → 実行 → 結果 → フィードバック → また実行。

そして、このすべての過程に必ず存在するものがひとつある。

会話だ。

仕事は結局、会話から始まる

「これ、調べてください。」

「この部分をこう変えてください。」

「この案で進めましょう。」

「この資料をもとに見積書を作り直してください。」

「クライアントが承認しました。生産に入りましょう。」

働きながら毎日交わす無数の会話は、実は単なるテキストではない。

その中には要件があり、知識があり、意思決定があり、やるべきことがある。

これまで私たちは、その会話が終わったあとに、また人が動かなければならなかった。

会議が終われば議事録を書く。

メッセージを読んでタスクに移す。

エクセルを更新する。

ドキュメントをつくる。

エンジニアにチケットを渡す。

デザイナーに修正事項を伝える。

そしてまた確認する。

ここで私たちは三つ目の仮説にたどり着いた。

会話そのものが、仕事を動かすことはできないだろうか。

だから私たちは会話を集める

AIの登場で、この問いへの答えが変わった。

人がすべての反復作業を自分で実行しなくてもよくなり始めたからだ。

会話の中から要件を理解し、意思決定を見つけ、やるべきことをつくり、必要なコンテキストをつなぎ、できることはAIが直接実行できる。

だから今のMarkhubは、単に会話を保存するコラボレーションツールでも、会議を要約するノートテイキングツールでもない。

組織で生まれる会話を一か所に集め、その中の知識と意思決定を実際の実行につなぐハブをつくっている。

人は会話に集中する。

Markhubはその会話から、やるべきことを見つける。

左が会話。右はそこから取り出したもの。トピック、決定、やることの下書き。機微な行はぼかしている。
左に会話、右にそこから取り出されたトピックと決定とやることの下書き

そして人がやるべきことは人へ、AIができることはAIへつなぐ。

必要ならローカルエージェントとつなぎ、開発、デザイン、ドキュメント作業まで続かせる。

同じ仕事がチケットになった姿。どこから来たのかを一緒に持っていく。機微な行はぼかしている。
チケットの詳細の横に、トピックとタスクが並ぶライブコンテキストの面

私たちが望むのは、単により多くの知識を保存することではない。

保存された知識が、実際の結果になるようにすることだ。

会話はデータではなく、実行のためのエネルギーだ

私たちが会話を集めようとするのは、すべてを記録するためではない。

人の口と手から出てくる言語には、まだ現実になっていないものが入っている。

「こんな製品をつくりたい。」

「この問題をこう解いたらどうだろう。」

「この部分を変えよう。」

「これを来週までにつくってみよう。」

それはまだ結果ではない。

しかし実行されれば、製品になり、デザインになり、コードになり、契約になり、売上になる。

私は、AIを動かす最も重要な力もまた人間の知識と想像力だと考えている。

AIがどれほど強力になっても、何をつくるのか、どの問題を解くのか、どんな結果を望むのかは、人から始まる。

だからMarkhubが集めたいのは、単なるチャットログではない。

人間の想像と知識が、実行される直前の瞬間たちだ。

そしてその瞬間と実際の結果とのあいだの距離を、できるかぎり短くしたい。

会話すれば、仕事が進む。

それが、競争の激しいAIワークスペース市場に私たちがふたたび飛び込んだ理由だ。