Building An Ephemeral Markdown Paper with AI

Transcript

1. AIと作るEphemeral Markdown Paper 個人開発でのAI利用の試行錯誤 1 Findy 個人開発のAI活用 LT @unvalley_
2. @unvalley_ - TypeScript / Rust - A core contributor of Biome - AI（NLP）は学部レベルの知識 - 週末はプレミアリーグを見ながらAIにコードを書いてもらっている 2 @unvalley_ unvalley
3. 話すこと 3 - Ephe (個人開発しているWebアプリ) - EpheをAIで開発した過程における判断・成功・失敗・意見 AIツールやモデルの検証というより、個人開発を優先してどういう判 断をしてきたかというサンプルになれば幸いです
4. Ephe https://ephe.app/landing 4 - Markdownで記述可能な1枚の紙を模したページ - データはブラウザのLocalStorageに保存（ログイン不要） - OSS, Free - -[ or - [ と入力した時点で - [ ] に補完 - cmd + s でテキストフォーマット（+ スナップショット作成） - TypeScript / React / Vite / Tailwind CSS / CodeMirror v6 / dprint 他
6. 個人開発のコスト 6 💸 and ⌛ 費用・時間対の効果が高い開発を可能にするツール を使う
7. 自分が個人開発に利用している技術・ツール 7 - Editor : VS Code / Cursor - Model : Claude Sonnet 3.7 / Gemini 2.5 pro - Chat : ChatGPT / Gemini / Perplexity / NotebookLM - MCP playwright / sequential-thinking / filesystem 基本はEditor, Chatは複雑な実装の壁打ちやツール調査,
8. Editor : VS Code / Cursor 8 - Epheは主に Cursorを利用して実装した - タブ補完がかなり優秀, 体感だがAgent Modeが速い - 雲行きは怪しい：VS Code拡張周り・Copilot Agent - ネットワークエラー多くないですか？ - 0.49からは、コマンドでRule生成可能になる - 最近はVS Code（Copilot）に戻りつつある - Copilot は OSS貢献者は無料で使える
9. Cursor 自分の使い方 9 - Agent Modeのみ利用, beta機能はできるだけON - Rules内はフォルダ分け可能なので、Attach方法ごとに分ける - メモリバンク拡張のSpecstoryは入れた途端にCursorが落ちるよう になったので利用していない（直接の原因かは不明） - たまにCursorを2つ使って、同じリポジトリを同時作業させる
10. 10 github.com/unvalley/ephe に色々置いています
11. 中の人の発信とかも参考に（そんなにうまくいくか？と思いながら試す） https://x.com/ryolu_/status/1914384195138511142 11
12. その他ツール 12 - Clien は試す程度でしか使っていないのであまり知見がない - 費用面で今回あまり収益を重視せずに満足いくところまで開発 したかったので、利用していない - Claude Code / Codex / Gemini Code Assist - 試してはいるがあまり自分は合っていない感じがある - 今後これらのツールでしか利用できないモデルが出てきて、そ れが良いなら使うかも
13. 個人開発に利用している技術・ツール 13 - Editor : VS Code / Cursor / Zed - Model : Claude Sonnet 3.7 / Gemini 2.5 pro - Chat : ChatGPT / Gemini / Perplexity / NotebookLM - MCP playwright / sequential-thinking / filesystem できれば使うツールはもっと減らしたい 若干の違いで使い分けているが、用途も大体被っている…
14. AIのコード品質との向き合い方 14 - 小中規模のコード量なので、AIにとって比較的簡単 - Epheは4/22時点で65ファイル / 1万行程度 - コード品質のために、結構手を加えている - 動く状態を作ってもらって、手直しする - LLMはすでにあるコードベースを変更するより、One-shotで動く コードを作る方が得意に見える - 例えばコンポーネント周りの実装でレイアウトを変えたいときな ど、別ページで新しく作らせると割と上手くいく
15. 成功 ✅ 15 - 機能実装の速度向上 - 機能の良し悪しの判断は自分で行う - AIができるタスク・できないタスクの感覚値が掴めた - コードが増えれば増えるほど不満が溜まる
16. 失敗 ☠ 16 - 自分でやるべきタスクをAIに任せて時間を溶かしてしまう - 機能数が少ないとテストの優先度を下げてしまう - 当然ある方が良いが、無駄にならないように - 機能実装が簡単になった故に、不要な機能を作り込んでしまう - Twitterなどに流れる新しい情報に踊らされてしまう？ - 今しか有効ではない情報をどれだけ捨てられるか
17. AIと技術的負債 17 - 負債だと感じるような実装が多々生まれるのでテストとルールはサ ボらずに書いた方がいい - Context Windowが溢れたらルールも無視される - ユーザー0で始まる個人開発なので、割り切ってガンガン生成させ てそれを逐次直していくのでも良いと思う - 正解だとは思わないが自分はそうした
18. 意見 18 - 自分は公式情報やエンジニアとして著名な人の情報を重視する - AIツール・モデルの良し悪しの判断は自分で検証する - プロジェクト規模・既存コードの質・テストの量・スキルセット・ルール・プ ロンプト…変数が多過ぎる - 誰かにとっていいものが自分にとっていいわけではない - 業務では気軽にRulesを変えづらいと思うので、個人開発で色々試 すのはいい機会
19. 終わり 19 - Cursorや他ツールを使いながら、Ephe を開発 - 非機能要件を満たすには自分の能力が必要