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