本記事は、OSC 2026 Nagoya で登壇した内容を記事向けに再構成したものです。当日聴いてくださった方も、聴けなかった方も、もう一度ゆっくり読み返せるように書き直しました。

はじめに

突然ですが、ひとつ質問です。

普段、Markdown の編集に何のツールを使っていますか？

VS Code、Obsidian、Typora、Vim、Emacs、Zed・・・きっと人それぞれ「マイ・エディター」があるはずです。

ではもう一つ質問。

そのエディターに、本当に満足していますか？

「う〜ん、そうやな・・・」と考えた人も多いのではないでしょうか。
「もうちょっと軽かったらな」「もうちょっとここが便利だったらな」
――そんな感じの違和感を誰しも抱えてそうな気がします。

私はそれを抱えたまま、長いこと色んなエディターを渡り歩きました。Atom が好きだったけれど開発終了。VS Code は執筆用には機能が多すぎて、重い。Obsidian は強力だけど、私の目的とは少しズレる。「メモ専用・執筆専用の軽いやつが欲しい・・・」とずっと思っていました。

そして、ある日 自分で作ることにしました。

これは、その自作 Markdown エディター Bokuchi（ぼくち）を OSS として公開して見えてきたこと、そして「立ち上げる側」に回って初めて気づいたことの記録です。OSS を始めたいけど一歩を踏み出せていない人に、少しでも勇気を渡せたらと思って書きました。

ちなみに、Bokuchi の技術的な中身（Tauri のこと、メモリ使用量 40MB の軽さのこと）は以前こちらの記事に書きました。

今回はその続編です。ツールの「中身」の話ではなく、作って、公開する側に回ったら何が起きたか、という「人間側」の話 をします。

過去の私の3つの告白

本題に入る前に、前置きしておきたいことが3つあります。今の私は「OSSを作ってよかった〜！」と100%思っていますが、そこに至るまでには長い葛藤がありました。

告白1. 個人のリポジトリは、基本 Private にしていた

前職では、仕事がEC-CUBEの開発だったので、当たり前にOSSにPRは出していました。でも、それは当然 業務だから 出していただけです。プライベートで触るリポジトリは、ほとんど Private に閉じていました。

理由はシンプルで、見られるのが恥ずかしかった からです。

告白2. OSS を「立ち上げる」なんて考えたこともなかった

使う側、PR を出す側までは経験がありました。でも「自分から始める側」は、別世界の話だと思っていました。「OSSのメンテナ」という肩書きは、私からは遠い場所にある言葉でした。

告白3. "作りたいもの" より、"作るべきもの" を考えていた

「何か OSS 作りたいけど、テーマが思いつかない」
「世の中の役に立つものってなんやろう・・・」

――そう考えては行き詰まり、何年も特に行動しないまま過ぎていきました。

今なら全然わかるのですが、そもそも、順番が逆だったんですよね。

転換点 ― 自分のペインに気づく

ある日、ある種麻痺していた自分の感覚に改めて気づいたことがありました。

毎日のちょっとしたメモのために、重いエディターを起動するのが苦痛だった ということです。正確には「気づいた」というより、それまでずっと現実逃避していたことについに向き合った、という表現の方が近いかもしれないです。

ちょっとメモを取るために VS Code を立ち上げ、CPU とメモリが食われる。もちろんダメなわけではないのですが、「メモのため」に払うリソースとしては明らかに過剰でした。

そこでふと、こう思ったのが

「なければ、自分で作ればいい」

ということ。
このときから、視点が変わっていきました。

❌ 「世の中のために作る」
✅ 「自分のペインを解決する」

高尚なことをしようとかは全然思っていませんでした
自身のペインに気づくこと。それが、「一歩目」だったのかなと思います。

"for me" で作る ― Bokuchi が生まれるまで

マーケティングのフレームワークに for me / for us / for you という3段階の考え方があります。「自分のため → 周りのため → 見知らぬ誰かのため」と価値が広がっていく構造です。

私はまず "for me" から始めました。高尚な動機はなかったし、別にいりませんでした。「自分が満足するもの」だけを目指して、自分一人を顧客として開発する。まずはそれでいい と決めて手を動かし始めました。

こうして生まれたのが、軽量・クロスプラットフォームの Markdown エディター Bokuchi です。

名前の由来

「墨池（ぼくち）」は書道の道具で、硯で摺った墨をあらかじめ入れておく小さな入れ物のことです。墨汁が入っているので、筆さえあればすぐに文字を書き始められます。

これが墨池。

画像引用元:https://syodo.tokyo/?p=1403

この道具のように、すぐに Markdown を書き始められる存在になってほしい。そう願ってこの名前を付けました。軽さと即時性を表すには、ぴったりのネーミングだと自分では結構気に入っています。

技術スタック

レイヤー	採用技術
デスクトップ枠	Tauri 2（Rust）
UI	React 19 + TypeScript
エディター	Monaco Editor
Markdown 描画	marked + KaTeX + Mermaid + Marp

Tauri を選んだ理由

これは正直に言うと、ものすごく個人的な動機でした。

Rust に挑戦してみたかった
Electron より軽くなることが分かっていた ― Bokuchi の「軽さ」思想に合う

当時、2つ目の理由はかなり大事だったんですが、今思えば本音は1番目だったような気がします。やってみたかった、学びたかったから選んだ、その要素もかなり大きかった気がします笑

「個人開発の特権」と言ってしまえばそれまでですが、技術選定をこれくらい個人的な動機で決めていいのが、自分で立ち上げる側に回ったときの最大の自由だと思います。仕事と同じ義務感でスタックを選ぶ必要はないんです。

Tauri そのものの解説や、Electron と比べてどれくらい軽いのかという話は、前回の記事で書いたのでここでは割愛します。

こだわった3つのポイント

常に立ち上げておける軽さ（通常時 40MB〜80MB）
タブの水平／垂直切替（比較しながら書ける）
変数機能（テンプレ的な文書を DRY に書ける）

全部、自分が欲しかったから 入れた機能です。

1. 軽さ

メモを取りたい「今この瞬間」に、待ち時間ゼロで立ち上がってほしい。重いエディターは「起動している間にメモする気が失せる」という、地味だけど致命的なペインを発生させます。

常に立ち上げておける軽さこそが、最大の武器。 これは Bokuchi のすべての判断の根っこに今もあります。
（例えば機能追加をする時に、便利になったとしても「重くなるなら却下する」という軸があります）

2. タブの水平／垂直切替

タブを持つエディターは珍しくないですが、向きまで切り替えられるのは意外と少ない印象です。同じファイルを左右で見比べたいときもあれば、別ファイル同士を上下に並べたいときもあります。最近Chromeブラウザが垂直タブに対応しましたが、あれ便利ですよね。
水平と垂直を時と場合によって切り替えられるようにしたかったんです。

3. 変数機能

これは特に議事録テンプレなどで威力を発揮します。

{{client_name}} 様
{{date}} 議事録

## 参加者
{{attendees}}

## アジェンダ
- {{topic_1}}
- {{topic_2}}

同じ値を複数箇所で使う書類は、1か所変えれば全部に反映される世界の方が圧倒的に楽です。

Marp モード

個人的に一番気に入っていて、実際に普段一番使ってる機能です。

Bokuchi には Markdown でスライドが作れる Marp モード もあります。ソースとプレビューを左右に並べたセパレートビューで、編集しながらスライドの仕上がりを確認できます。

Marp は通常の Markdown の先頭に YAML フロントマターを書くだけでスライドになります。

---
marp: true
theme: default
paginate: true
style: |
  section { font-family: 'Noto Sans JP', sans-serif; }
---

# タイトルスライド

---

## 次のスライド

- 箇条書き
- もう一つ

--- で区切るだけでスライドが切り替わる、というのが Markdown ネイティブには馴染みのいい仕様です。Bokuchi では、この Marp プレビューを iframe で隔離しつつ srcDoc でコンテンツを差し込み、編集中も入力のたびにスクロール位置が飛ばないように工夫しています（このあたりは別記事で書いてもいいかもしれません）。

もうひとつの "for me" ― Lightning Timer

Bokuchi だけが「自分のため」のプロダクトではありません。Lightning Timer という別の OSS も並行して作っています。

きっかけ：LT で毎回時間オーバーする病

正直に告白すると、私は LT で毎回時間オーバーしていました。

目の前にタイマーは置いてある。なのに、見ていない。気づいたら残り数秒。「あるある」と頷いてくれる人も多いんじゃないでしょうか。

これも最初は「自分が不器用なだけ」で済ませていたのですが、ある時ふと、構造の問題に気づきました。

視線の問題

発表中、登壇者の視線は スライドと聴衆の間をひたすら往復 しています。机の上のタイマーは、視野の外にある。既存のタイマーアプリはスライドをフルスクリーンにすると裏に隠れるし、別デバイスに置いても結局見ない。

視線の中にタイマーを「物理的に」置くしかない ―― そう結論しました。

解決策

そこで生まれたのが Lightning Timer です。

スライドのフルスクリーン表示の上に重なる
クリックスルーで、スライド操作の邪魔をしない
半透明で時間を浮かべる
Tauri 2 + Rust + React 製、macOS / Windows 両対応

ダウンロード数は、執筆時点でほぼ 1（私） です。それでも問題ありません。私の登壇を救ってくれているし、私が満足しているからです。"for me" の純度を極限まで高めると、こうなります。

Bokuchi と Lightning Timer の構造は同じ

	Bokuchi	Lightning Timer
ペイン	重いエディター	LT 時間オーバー
既存ツール	満足できなかった	どれも視線問題未解決
動機	自分が使いたい	自分の登壇を救いたい
ユーザー	まず自分	まず自分

自分のペインに気づくと、自分を救いたくなってくる。これが習慣化すると、ペインの数だけプロダクトが生まれます。

Lightning Timerの詳しい内容はこちらの記事でも触れています。

"for us" ― 周りに広がる

Bokuchi で「これこれ、こういうのが欲しかった」と 自分が満足した瞬間、ふと思いました。

「あれ、これ 他にも使ってくれる人 いるんじゃない？」

職場の同僚に勧めてみたら、想像以上の反応が返ってきました。

「これ、ヘビーユーザーになりそうです」

めちゃくちゃ嬉しかったのを昨日のように覚えています。

この一言で完全に自分のスイッチが入りました。"for me" だったツールが、目の前で "for us" になった瞬間でした。

そして気づいたことがあります。

他者の視点が、自分のプロダクトの価値を引き上げてくれる。

自分一人で開発していると、どうしても主観的になります。自分では気づかない使い勝手の悪さ、UI の細かな欠点。それを他者が指摘してくれて、改善した結果、自分自身も使いやすくなる。これは "for me" のままでは絶対に届かない領域でした。

SNS でもポジティブな反応をもらえるようになりました。「軽くていい」「HTML のエクスポート機能、欲しかった」等々、自分があまり重視していなかった機能で気に入ってくれる人もいて、自分が見えていなかった価値を、ユーザーが教えてくれる ことが何度もありました。

"for you" ― 会ったことない誰かへ

Bokuchi の GitHub Star は、執筆時点で 85個 です。

数字としてはそこまで大きくありません。でも、そのほとんどは 私が会ったこともない人 です。ユーザー一覧を見に行ったら、海外の方が普通に多くて驚きました。世界中の誰かが「これ、いい」と思ってくれている証拠です。

そしてこの段階に来て、一番感動したのが――

他人が、Bokuchiのバグを見つけてくれた ことです。

KaTeX のバグ報告

KaTeX 機能をリリースした直後、海外の方から Issue が届きました。自分のテストでは気づけなかった条件で、特定の数式がうまくレンダリングされない。すぐに修正してリリースしたところ、報告してくれた方が 修正にとても喜んでくれました。

この体験で、心の底から「公開してよかった」と思いました。

自分以外の人間がデバッグを助けてくれる世界。これは公開しないと絶対に得られない体験です。PR で修正案を送ってくれる人が現れたら、たぶん私は泣きます。

・・・と思っていたら、後日、本当に高校生の男の子がセキュリティ強化のためのPRを送ってくれました。

Bokuchiのコントリビューターが一人増えたわけです。
彼には今でも感謝しています。

自分自身の変化

公開を続けるうちに、自分の中の景色が完全に変わっていくのを感じました。

Before	After
ツールを「使うだけ」	ペインを見つけて「作る」視点
バグに遭遇＝イライラ	バグの再現条件を冷静に分析
自分の不満は我慢	ソフトウェアで解決できないか？
他人の困りごとはスルー	自分が貢献できないか？

そしてある日、ふと気づきました。

いつのまにか、公開する恥ずかしさが消えていた んです。

これは自分でもかなり驚きました。
「自分の見栄」だった状態から、「誰かのペインを救えるかも」に変わった瞬間に、見えていた景色が変わっていました。

もうひとつ気づいたこと

リポジトリがPrivateかPublicかという話をしたので、身も蓋もない話をしておきます。

そもそも、リポジトリを Public にしても誰も見ません。

悲しいかな、これ現実ですね。
それこそQiita などで紹介したり、SNSで発信でもしない限り、誰も辿り着かない。自分も他人のリポジトリは、関係性か興味がない限り見ない。何もしなければ、勝手に見られることなんて基本ないんです。

Private にすべきなのは、こういう場合だけだと思います。

未公開の情報が含まれている
ソースコードそのものに金銭的価値がある
業務上の秘密保持義務がある

それ以外は、Public のままでいいんじゃないかと、今は思っています。

失敗もあるし、諦めたものもある

良い話ばかり並べると嘘っぽくなるので、正直なところも書いておきます。

想定外に時間がかかったこと

実はデスクトップアプリを作るのは初めて だったので、配布まわりは未知のことだらけでした。

課題	やったこと
macOS の公証化	Apple Developer 登録 → 署名 → notarization
自動アップデート機能	やり方を調べながら実装
Windows の公証化	まだ未対応（Windows機が手元にないのとライセンスが高額すぎる）

「自分が使うだけ」なら絶対にやらなかった作業です。でも配布する選択をすると、こうしたコストが乗ってきます。

失敗：E2E テストが書けていない

一度 E2E テスト導入にチャレンジしましたが、諦めました。そもそも Tauri 自体に有用な E2E ツールがまだ整っていない、というのが大きな理由です。
強引に一度作ろうと思ったときがあったのですが、無理だなとおもって素直に諦めました。

ユニットテストはありますが、E2E は未実装のままです。OSS は正直に「未実装」と言ってもいい、というのは個人開発を続けてきて学んだことの一つです。

削った機能：オンライン連携

Obsidianとかを使う人が特に選んでる理由なのではないかともうのですが、スマホ連携、クラウド同期、といった機能があるエディターもありますよね。今どきメジャーな機能だと思います。実際に自分も「これがないと使わない」ということを言われました。

でも、あえて 実装しないと決めました。

理由	中身
差別化	後発だからこそ、オフラインにこだわる
セキュリティ	OSS で他人のデータを預かるのはリスクが大きい
運営コスト	個人で持続可能じゃない

「オンライン同期に対応したら使う」と言われても、対応はしない。
"何を作るか" と同じくらい、"何を作らないか" が大事 だと思っています。

諦めなかったこと：PlantUML 対応

実は私、Mermaid より PlantUML の方が慣れています。本当は PlantUML を Bokuchi に組み込みたかった。でも、3つの壁がありました。

壁	なぜダメか
Java 依存	インストール後にすぐ使えないので Bokuchi の思想に反する
（上記を回避するために）オンラインでSVG取得	オフライン思想に反する
Rust の Crate がない	組み込もうにも素材がない

ここで一旦は諦めて Mermaid の実装を優先しました。
でも、「ない素材は自分で作る」というのもやりたかったので、PlantUML を Rust で扱うための Crate を別途開発中 です。完成すれば Bokuchi にも組み込めます。

ただ、ただ！
正直、画像処理ライブラリのデバッグはしんどいです。修羅の道です。まだ全然完成する目処はたっていません。でも、ペインを諦めない とBokuchiのときに決めたので、技術スタックの足りない部分まで自分で埋めにいく覚悟は、案外できるものでした。むしろ楽しい。

副作用として、3つ目の OSS が地味に増えました笑

OSS 立ち上げの「8か条」

ここからは、OSS を始めたい人に向けた実用的な話です。自分なりの「立ち上げの心得」を8つにまとめました。

その1：ペインに気づくこと

それが本当の一歩目。リポジトリ作成は2歩目です。「自分が日常で諦めていることは何か？」を見つけられたら、そこが出発点になります。「作りたいもの探し」は、たいてい空振りします。

その2：最初はプライベートリポジトリでいい

最初から公開を意識しなくて構いません。恥ずかしいなら隠したままで OK。まず動くものを作る ことが最優先です。

その3：意思決定は自分一人で、速やかに

自分のためのリポジトリだから、誰の許可もいりません。スピードはスタートアップより速い。この爽快感が、個人開発の最大の魅力のひとつだと思います。

その4：ライセンスはコピペで決める

他のリポジトリを参考にして決めればいい。MIT、Apache、GPL・・・迷ったら MIT で。問題があれば後で変更すればいいだけです。完璧を目指すより、進めることを優先しましょう。

その5：README は「自分のための取扱説明書」

他人向けに着飾る必要はありません。半年後の自分が読んでわかれば OK。
結果的に、それが他人にもわかりやすいことが多いです。

その6：自分のペインが解決した瞬間に、一度立ち止まる

「完璧になったら公開」 ではありません。そう思っていたらたぶん永遠に公開は出来ません。自分が作ったツールに満足する瞬間が発生したなら、それは少なくとも一人分の価値があるということ。ということは・・・同じ悩みを持つ人は、必ず世界のどこかにいます。

その7：完成度より、公開する勇気

公開しないと Issue も PR も来ません。逆に公開すると「もう少しちゃんと作ろう」と良い緊張感が生まれます。公開しないメリットより、公開しないデメリットの方が圧倒的にデカいです。

その8：Issue/PR は怖くない。むしろ最高！！

自分が気づけなかったバグを発見してくれる。デバッグを助けてくれる。思いも寄らない改善提案が来る。この体験は、公開した人しか味わえません。

自分以外の人が、自分が作ったツールに貢献してくれるんですよ。
めちゃくちゃ嬉しいです。めちゃくちゃ。

もう少し具体的な話 ― 実務的な疑問に答える

上記の8か条だけでは見えにくい「で、実際どうすれば？」にも触れていきます。

README は10行以下から始めていい

最初は「半年後の自分が開発環境を再構築できる」だけで十分です。

git clone https://github.com/you/your-repo.git
cd your-repo
npm install
npm run dev

これで OK。いきなり「わかりやすい解説文」を書こうとすると、そこで詰まってまた公開できなくなります。

配布は GitHub Releases で十分

App Store などのアプリマーケットを必ず使う必要はありません。公証化（コードサイン）なしでも、Releases で配れます。起動時に OS の警告が出ても、毎回「許可」すればいいんです。

私が公証化をやったのは、それが 自分にとって面倒だったから ですね。これも結局、「自分のため」。だから Windows はまだやれていません（手元に Windows 機もない笑）。

AI との付き合い方

自分の経験値	AI の使いどころ
高いところ	自分で判断する
低いところ	壁打ち → 裏取りで補強

具体的には、

「自分の経験ではこうするが、この技術でも一般的か？」と問う
AI の答えを 鵜呑みにしない
有名 OSS での実例を挙げさせる など、裏取りする
「同じように作ってみるか」と腹落ちしてから書く

AI 活用は、人とのペアプロと似ています。自分の経験を活かせるところは活かし、わからないところは手伝ってもらう。何でもかんでも頼むのは、AI でも人でも「上手な使い方」ではないんと思いますし、失敗の温床になります。

※Qiitaではこの手の内容の記事がめちゃくちゃヒットするのでみなさんもおそらくご存知かと思います

モチベ維持のため、複数プロジェクトのローテーションをする

まずOSSは仕事じゃないので、飽きたら中断していいんです。リリースの締め切り日もありません。

私は Bokuchi のメンテナンスに飽きたことが何度もあります。そんなときはさっき書いてたLightning Timer のメンテに切り替えます。飽きたらまた次へ。常にやんわりモチベが残る状態 を保つのがコツです。

好きな食べ物も、毎日食べたら飽きます。色んなものを食べるから、好きな食べ物が「好きなまま」キープされる。OSS のメンテも、ローテーションが「好き」を守ってくれます。

収益化は、考えなくていい

「いつ収益化するの？」と聞かれることがあります。悪気はないと分かっているのですが、内心「金だけで物事を考えるなよ〜」と思っています。

この記事は 収益化を考えていない人向け の話です。自分を助けるためのツールを、おすそわけするだけ。 最初はその考えで始めれば十分です。

※収益化を念頭にアプリ開発したい人はそういう記事を探してください。いっぱいあります。

「保守って大変じゃないですか？」とよく聞かれます

これも本音を書きます。

答え：思ったより「楽しい」

ユーザーのフィードバックが返ってくるのが、こんなに嬉しいなんてと自分は思ってます。
バグが見つかると「お、改善ネタが来た」と思える。AI の力も借りられる時代なので、メンテナンスコストは昔より明らかに下がっています。

ただし「楽」とは言わない

一定の時間は取られます。バグが起きれば調べないといけないし、ライブラリのアップデートや脆弱性対応も必要です。「楽」と「楽しい」は別もの です。

きっと皆さんの趣味と同じ感覚です。例えば、ゲームのレベル上げ、楽じゃないですよね。時間がかかるし、地味な作業も多い。でも、みんな楽しんでやっている。OSS の保守も、それと同じ感覚です。多少手間はかかっても、楽しいから苦にならない。

私はポケモンの厳選作業が割と好きなんですが、どう見てもあれは楽な作業ではないです。でも楽しいから続けられます。

開発自体は怖くありません。むしろ、一番恐れているのは「このエディターが本当に完成して、もう何もすることがなくなってしまうこと」 だったりします。
（脆弱性対応やライブラリ更新があるので、実際にはそうはなりませんが）。

※HUNTER x HUNTERのクラピカのセリフが元ネタです

最大の報酬 ―「視点の獲得」

ここまで色々書いてきましたが、OSS を立ち上げて得られた一番大きなものは、お金でも Star の数でもありませんでした。

視点が変わったこと です。

自分のペインに気づけるようになる
他人のペインも気になるようになる
「ソフトウェアで解決できないか？」と考えるクセがつく

これは、コードを書く力よりもずっと大きな資産だと、心から思います。

「世の中のため」から考えると始まらないけれど、「自分のペイン」から始めると、結果として誰かを救う可能性が生まれます。

お伝えしたかったこと

最後に、要点をもう一度。

ペインに気づくこと、それが一歩目
"for me" で作っていい、高尚な動機はいらない
公開しないデメリットの方が、圧倒的にデカい
あなたのペインは、誰かを救う資源かもしれない

みなさんが普段感じている「不満」「諦め」「違和感」それは全部、誰かを救うための素材になるかもしれません。

私が "for me" で作ったツールが、今日この記事を通して、あなたへの "for you" になっていたら嬉しいです。そして、あなたの "for me" が、いつか誰かの "for you" になりますように。

「自分のため」が、「誰かのため」になる瞬間が、すぐやってくるかもしれません。

リンク

Bokuchi は無料で使えます。「常に立ち上げておける軽い Markdown エディター」を探していた方は、ぜひ一度触ってみてください。

Bokuchi: bokuchi.com
Lightning Timer: github.com/shinya/lightning-timer
前回の記事: メモリ使用量40MBの衝撃。理想のMarkdownエディタを求めた結果、Tauriで自作が一番良かった

IssueやPR、お待ちしています！
もちろん、GithubStarも。