元記事は、WebSocketとClaudeを使って、リアルタイムで協働できるAI文章作成ツールを作るという内容です。
これ、地味にかなり今っぽいです。
単なる「AIに質問して返事をもらうチャット」ではなく、複数人が同じドキュメントを触っている横で、AIが文章を補助していくという形だからです。
たとえば、こんな使い方が想像できます。
このタイプのツールは、もはや「チャット」より編集作業の相棒に近いです。
個人的には、ここがいちばん面白いところだと思います。AIを“会話相手”ではなく、“同じ机に座る同僚”として扱う発想ですね。
記事冒頭で強調されているのは、request-response chatbotとの違いです。
普通のチャットボットは、
という、かなり単純な構造です。
でも共同編集ツールになると、状況が一気に複雑になります。
つまり、AIの会話というより、交通整理つきの共同作業場を作るイメージに近いです。
ここで必要になるのが、WebSocketやCRDTのような技術です。
元記事では、システムの主要要素を4つに分けています。
利用者が触る画面です。
ブラウザ上のエディタや入力欄を想像するとわかりやすいです。
WebSocketは、サーバーとクライアントが双方向でずっと通信し続ける仕組みです。
普通のWeb通信は「質問して返事をもらったら終わり」ですが、WebSocketはつながりっぱなしにできます。
これが重要なのは、共同編集では「誰かが入力したら即座に他の人へ反映する」必要があるからです。
いちいちページを更新していたら、実用になりません。
CRDTは、ざっくり言うと複数人が同時編集しても、なるべく矛盾しないようにするデータ構造です。
「Conflict-free Replicated Data Type」の略で、名前は難しいですが、考え方はわりと素直です。
という仕組みです。
共同編集で厄介なのは、単純に「最後に届いた更新を採用する」だけだと、誰かの入力が消えたり、順番がおかしくなったりすることです。
CRDTはそこをかなりうまく避けます。実運用に耐えやすいので、こういう用途ではかなり筋がいい選択だと思います。
Claudeのstreaming APIは、AIの返答を一気にまとめて返すのではなく、少しずつ流す方式です。
これはかなり大事です。
なぜなら、文章生成を待っている間に「何も起きていない」と、体感が重くなるからです。
でもトークン単位で少しずつ見せれば、
という利点があります。
個人的には、AIツールの使い心地を決めるのは、モデルの賢さだけじゃなくてこの“出し方”だと思っています。
速さより、待たされていない感が大事なんですよね。
記事では、FastAPIサーバーがWebSocket接続を管理する役として登場します。
FastAPIはPythonのWebフレームワークで、API開発に向いています。
ここでやることは主に、
という感じです。
要するに、サーバーは「全員の発言をまとめる司会者」みたいな役割です。
しかもただの司会ではなく、会話しながら議事録も更新するくらい忙しい。これはなかなか大変です。
共同編集の世界では、単純なサーバー管理だけでは足りません。
同時編集は必ず「競合」が起きるからです。
たとえば、2人が同じ行を同時に修正したらどうするのか。
ネットワークの遅延で、Aさんの更新が先に見えたり、Bさんの更新が先に見えたりすることもあります。
CRDTは、こうした問題に対して「多少順番が前後しても、最終的に整合しやすい」性質を持っています。
この性質のおかげで、中央集権的に全部を厳密に順番制御しなくても、実用的な共同編集ができます。
これはかなり重要です。
AIライティングツールは見た目が華やかでも、裏側が雑だとすぐ壊れます。CRDTは地味ですが、こういうプロダクトの“足腰”ですね。
Claudeが文章を一気に返さず、delta one at a timeで流す、というのもポイントです。
deltaは「差分」や「少しずつの変化」という意味合いで考えるとわかりやすいです。
つまり、
ということです。
これによって、他の人が同じドキュメントを見ていても、AIが今まさに文章を作っているのが伝わります。
リアルタイム性があるだけで、ツールの印象はかなり変わります。
正直、この「途中経過が見える」体験は、文章作成の心理的ハードルを下げると思います。
完成品だけ見せられるより、「一緒に書いている感」が出ますから。
記事では、token-bucket rate limiter も登場します。
これは簡単に言うと、使える回数や量に上限を設けて、急な連打を制御する仕組みです。
token-bucketは「一定量のチケット（token）が溜まり、使うたびに減る」イメージで理解するとわかりやすいです。
共同利用のAIツールでは、1人が大量にリクエストを飛ばすと、
という問題が起きます。
だから、ユーザーごとに制限をかけるのはとても現実的です。
このあたり、記事が「夢のあるAIツール」だけでなく、ちゃんと運用する前提で書かれているのが好印象でした。
元記事の構成は、かなり実務っぽくて好感が持てます。
派手な新技術を全部盛りした感じではなく、
という、必要なものをちゃんと組み合わせている。
この「最小限だけど、実際に動く」感じがいいんです。
個人的には、AIアプリ開発はここが分かれ道だと思っています。
モデル自体が賢くても、同時編集・遅延・コスト・応答の見せ方まで設計しないと、プロダクトとしては弱い。
この記事は、その現実をちゃんと踏まえているのがえらいです。
この記事は、Claudeを使ったAI文章支援を、単なるチャットではなくリアルタイム協働編集システムとして作る話です。
ポイントは、
という4本柱です。
「AIで文章を作る」と聞くと、ついモデルの性能ばかりに目が行きます。
でも実際には、どうつなぐか、どう同期するか、どう待たせないかがめちゃくちゃ大事です。
この記事は、そのあたりをかなり実践的に押さえていて、AIツール開発の良いお手本だと思います。
参考: Build a Real-Time Collaborative AI Writing Tool with WebSockets and Claude
