【OSS貢献】AIと協調してmemosにオートフェッチ機能を追加した話

はじめに

最近、情報整理のために memos というOSSを愛用しています。X（旧Twitter）ライクなUIでメモを残せる素晴らしいツールなのですが、一つだけ不満がありました。

それは、「別端末で投稿したメッセージが、リロードするまで表示されない」 という点です。
PCでメモを書いて、スマホで見ようとしたときに一覧に出てこないと、「あれ？保存されてない？」と不安になる体験が地味にストレスでした。

Issueを確認してみると、同様の要望 (#3652, #4141) が上がっていましたが、長らく動きがない様子。「それなら自分でやってしまおう。」と思い立ち、オートフェッチ機能（自動更新）を実装してPRを送ってみました。

https://github.com/usememos/memos/pull/5348

現在レビュー待ちの状態ですが、コードオーナーがお忙しそうなのでマージされるかは未知数です。 「とりあえず自分が使えればOK」というだったので、今回の変更を含んだDockerイメージもDocker Hubで公開しておきました。もし同じ不満をお持ちの方がいれば、ぜひ試してみてください。

https://hub.docker.com/r/iwakiaoba/aoba-memos/

memosの紹介

GoとReactで書かれた、プライバシー重視の軽量なメモサービスです。Markdown対応で、SQLiteだけで動く手軽さが魅力です。

memosは下記の画像のようなシンプルなUIを持つOSSのメモアプリケーションです。
内容は適当にAIに書かせたダミーデータなので気にしないでください。

AIを「責任あるエンジニア」として活用する工夫

今回の実装にあたり、AI（主にClaude Sonnet 4.5）をフル活用しました。
ただ、個人開発のプライベートリポジトリなら「動けばヨシ！」のいわゆる バイブコーディング でも良いのですが、今回はOSSへの貢献です。

パブリックな場にコードを投げる以上、書かれたコードには自分が責任を持たなければなりません。また、既存のアーキテクチャを壊さず、保守性を意識する必要があります。
AIに丸投げして「なんか動きました」では、後から自分でもコードが読めなくなり、レビュアーにも迷惑をかけてしまいます。

そこで今回は、「AIのコンテキストを制御し、設計の主導権は人間が握る」 ために以下のドキュメント運用を行いました。

ABSTRACT.md と PLAN.md の分離

AIとの対話でコンテキストが溢れないよう、ドキュメントを明確に役割分担させました。

• ABSTRACT.md (人間向け)

  • 実装の目的、大まかな仕様、満たすべき要件を人間が理解できる粒度で記述。
  • 「なにを作りたいか」を把握するのが目的。

• PLAN.md (AI向け)

  • 具体的な実装ステップ、変更すべきファイルパス、関数の仕様など、AIに指示するための詳細な設計図。
  • 「どう作るか」をAIに伝えるのが目的。

さらに必要に応じて SCHEMA.md や ARCHITECTURE.md などを作成し、AIに一度に読ませるトークン量を調整しました。これにより、「実装の方向性を理解した上で、AIがコードを書き、人間がそれをレビューする」というサイクルを高速に回すことができました。

開発フローと使用ツール

https://antigravity.google/

エディタには Antigravity を使用しました。
操作感はCursorに近いですが、完全無料でClaude Sonnet 4.5が使い放題なのが強すぎます（そのうち有料化されそうなので今のうちに使い倒します）。

開発の流れとしては以下の通りです。

1. AIと協議してアーキテクチャを決定し、ドキュメントに落とし込む。Mermaidを書かせて不要な処理がないかをよく確認するのが重要だと感じました。
2. PLAN.md に基づいて、AIに実装単位ごとにコードを書かせる。
3. 生成されたコードを人間がレビューし、動作確認。
4. 最後に、自ら全コードを読み通して整合性をチェック。

特に4番目の「満を持しての全コードリーディング」が最も重い作業でしたが、これを経ることで「自分のコード」として自信を持ってPRを出すことができました。

実装の概要

実装のアプローチ：WebSocketではなく、あえてポーリングで

今回の要件である「新着メモの自動取得」を実現するにあたり、WebSocketを用いたプッシュ通信も検討しましたが、以下の理由から シンプルなポーリング（一定間隔でのデータ取得） を採用しました。

1. 実装コストと堅牢性のバランス: WebSocketは接続断のハンドリングや再接続処理など考慮事項が多い一方、ポーリングはステートレスで実装が単純であり、バグを生みにくい。
2. 既存APIの活用: memosには既にメモ一覧を取得するREST/gRPC APIが存在するため、バックエンドに手を入れずフロントエンドのみの変更で完結できる。
3. memosのユースケース: チャットアプリほどのリアルタイム性（ミリ秒単位）は求められておらず、数秒〜数十秒の遅延は許容される。

ひとつだけ後悔していること

今回、AIとのやり取りや設計をまとめたドキュメント類（ABSTRACT.md等）は、PR作成時に「リポジトリには不要だろう」と判断して削除してしまいました。ローカルには残っているつもりだったのですが……それも操作ミスで消滅していました。

あのドキュメントこそが今回の開発の肝であり、AIと何度も対話して作り上げたものだったため、非常に後悔しています。今度からはどんな内容もリモートにプッシュしておこうと心に誓いました。

おわりに

OSSへの機能追加はハードルが高く感じられますが、AIと適切なドキュメント管理を組み合わせることで、複雑なコードベースでも迷子にならずに実装を進めることができました。
今回のPRがマージされることを祈りつつ、引き続きmemosを愛用していこうと思います。

その他のOSS貢献記事

https://zenn.dev/aobaiwaki/articles/db3d30313330da