なぜ Markdown エディタの VMark を作ったのか
TL;DR
ある非プログラマーが 2025 年 8 月にバイブコーディングを始め、6 週間で Markdown エディタの VMark を作り上げました。主な教訓: git は必須（それがあなたのアンドゥボタン）、TDD は AI を正直に保つ（テストはバグに対する境界線）、あなたはバイブ思考をしているのであってバイブコーディングではない（AI が作業を行い、あなたが判断する）、そして クロスモデルの議論が単一モデルへの信頼より優れている。この旅は、ユーザーが開発者になれることを証明しました — しかしそれは少数の基礎的なスキルに投資する場合のみです。
きっかけ
実のところ、VMark を作ることは主に自分自身の学習と経験の旅でした。
私は 2025 年 8 月 17 日に、バイブコーディングとして知られる新興のプログラミングトレンドを試し始めました。バイブコーディングという言葉自体は、2025 年 2 月 2 日に Andrej Karpathy がX（旧 Twitter）に投稿したことで初めて広まりました。
Andrej Karpathy は機械学習の分野で非常に影響力のある研究者であり教育者です。OpenAI や Tesla などの企業で重要な役職を歴任し、後に AI ネイティブ教育に特化した Eureka Labs を設立しました。彼のツイートは「バイブコーディング」という概念を紹介しただけでなく、テックコミュニティに急速に広まり、広範なフォローアップの議論を引き起こしました。
私がバイブコーディングツールに気づき使い始めたころには、すでに半年近く経過していました。当時、Claude Code はまだバージョン1.0.82でした。2026 年 2 月 9 日にこのドキュメントを書いている時点では、バージョン2.1.37に達しており、その間に 112 回のバージョン更新を経ています。
最初は、これらのツールを長年前に書いた自動化スクリプト — 例えば ebook の一括翻訳 — を強化するためだけに使っていました。気づいたのは、すでに持っている能力を増幅しているだけだということでした。
すでに何かをできるなら、AI はそれをより上手くやるのを助けてくれます。何かをできないなら、AI はしばしばできるような幻想を与えてくれます — 通常は最初の「わあ」という瞬間が来て — その後は何もありません。もともとできなかったことは、まだできませんでした。あの美しい画像、目を引く動画、長い記事は、多くの場合、新しい時代の「Hello World」の別の形にすぎませんでした。[1]
プログラミングについて完全に無知というわけではありませんが、本物のコンピューターエンジニアでも確かにありません。せいぜい普通のユーザーの中のパワーユーザーです。少しのコードを知っていて、Python プログラミングについての本を出版したこともあります。しかしそれは私をエンジニアにはしません。茅葺き小屋を建てられる人のようなもので: できない人より多くを知っていますが、高層ビルや橋を設計する人たちとは全く別のカテゴリーにいます。
そして、AI がすべてを変えました。
スクリプトからソフトウェアへ
最初から今まで、私はほぼすべての利用可能な AI コーディング CLI を試しました: Claude Code、Codex CLI、Gemini CLI、Grok CLI のような非公式ツール、Aider のようなオープンソースの代替品まで。しかし最もよく使ったのは常に Claude Code でした。Codex CLI が MCP サーバーを導入した後は、ClaudeCode をさらに多く使いました。インタラクティブモードで Codex CLI を直接呼び出せるからです。皮肉なことに、Claude Code は MCP プロトコルを最初に提案したにもかかわらず、まだ自身の MCP サーバーを提供していません（2026-02-10 時点）。
最初は、Claude Code は突然私の家に引っ越してきた専門の IT スペシャリストのように感じました — 大企業でしか見つからないような人。コンピューター関連のことは何でも任せられます。以前見たことのないコマンドラインツールを使って、または見慣れたコマンドを見慣れない方法で使って問題を解決してくれます。
十分な権限を与えれば、ほぼできないことはありませんでした: システムメンテナンス、更新、ネットワーク、無数のトリッキーな設定と競合を持つソフトウェアやサービスのデプロイ。月 200 ドルでこのような人を雇うことはできません。
その後、使うマシンの数が増え始めました。クラウドインスタンスは 1〜2 台から 5〜6 台に増え、家のマシンは 2〜3 台から 7〜8 台に増えました。設定に何日もかかっていて、限られた知識のために失敗することが多かった問題が突然消えました。Claude Code はすべてのマシン操作を処理してくれ、問題を修正した後、同じ問題が二度と起こらないように自動起動スクリプトを書いてくれました。
そして、今まで書けなかったものを書き始めました。
最初はブラウザでの絶え間ないコンテキスト切り替えとコピーペーストを減らすために設計されたブラウザ拡張機能 Insidebar-ai が来ました。次に本物のソフトウェアのように見えた Tepub が来ました: EPUB ブックを翻訳（単一言語または二カ国語）し、オーディオブックも生成できる Python コマンドラインツール。それ以前は、ぎこちない手書きの Python スクリプトしかありませんでした。
突然裁縫スキルを得た — あるいは繊維工場を所有した — ファッションブロガーのように感じました。どれだけ優れたセンスがあっても、一度関連する基礎的な分野についてより多くを学ぶと、多くの見方が自然に — そして必然的に — 変わります。
本物のコンピューターエンジニアになるために数年を費やすことに決めました。
似たようなことをしたことがあります。私は新東方で何年も読解の授業を教えました。数年間教えた後、少なくとも読むことに関しては、英語のネイティブリーダー（スピーカーではなく）に実質的に自分を変えました。スピーキングはひどかった — しかしそれには本当の用途がなかったので — それはそれでよかったのです。
大きなことを目指していたわけではありません。ただ脳を鍛えたかっただけです。それが最も面白いゲームではないですか?
毎週 1 つの比較的小さなプロジェクトを完成させ、毎月 1 つの比較的大きなプロジェクトを完成させることにしました。数十のプロジェクトの後、別の人間になるだろうと推測しました。
3 か月後、12 以上のプロジェクトを構築しました — いくつかは失敗し、いくつかは放棄されましたが — しかしすべてが魅力的でした。このプロセスの中で、AI は驚異的なペースで目に見えて賢くなっていきました。密な実践的な使用なしでは本当にこれを感じることはできません。精々は間接的に聞くだけです。この感覚は重要です。なぜなら、後で議論する AI の哲学を直接形成したからです: AI はどんどん賢くなるという確固たる信念。
2025 年 11 月、foliate.js に基づいた EPUB リーダーを作りました。まさに私が好きな方法で設計されています。Kindle や Apple Books（macOS/iOS）では得られない機能を実装しました: 階層的なハイライト、ハイライトとメモの管理（エクスポートだけでなく）、カスタム辞書、Obsidian カードのエクスポートなど。時々バグがありましたが、個人的な使用には影響しませんでした。
とはいえ、公開するには恥ずかしすぎました。学んだ最大の教訓はこれでした: 自分自身のためだけに作られたものはおもちゃ; 多くの人のために作られたものはプロダクトまたはサービスです。
なぜ Markdown エディタなのか
当然、まだ自分自身のニーズだけを考えていました。「読む」が解決されると、次に自分のために解決できるのは「書く」でした。そこで 2025 年 12 月 27 日 — クリスマス後に哈爾浜から北京に戻った後 — VMark の構築を始めました。名前は単にバイブコーディングされた Markdown エディタを意味します。アイコンでさえバイブコーディングされました: Claude Code が MCP を通じて Sketch に描くよう指示しました。
Markdown エディタを作ることを選んだのには他の理由もありました。
Markdown エディタがどうあるべきかについてかなり明確なアイデアを持っていると感じていました。
また、既存のエディタが満たせない多くの未解決のニーズがありました。
直感的に、このステージの私にとってちょうど良いサイズのプロジェクトのように感じました — 現実的に扱える「中規模」プロジェクト。
また、このようなプロジェクトが AI により多く助けてもらえると信じていました。結局のところ、Markdown エディタは新しいものではありません。そのすべての詳細は AI がほぼ誰よりもよく理解しています。
そして穴に落ちました — 非常に深い穴に。本当に良い Markdown エディタは、想像以上に極めて難しく、はるかに複雑です。
表面的に数日間は喜んでいましたが、その後 1 週間、繰り返し苦闘して落ち込みました。最終的に ChatGPT に尋ねました:
本当に良い Markdown エディタを作る作業量はどのくらいですか?
その返答の冒頭は笑わせてくれました — 自分の無知について。
使える Markdown エディタ: 1 人・ 1〜2 週間
良い Markdown エディタ: 1〜2 人・ 1〜3 か月
ヘビーライターが手放せない Markdown エディタ:
3〜8 人・ 1〜3 年（そして本質的に継続的に進化するプロジェクト）（多くの詳細省略）
最後の質問:
どれくらい維持する意欲がありますか（月単位ではなく年単位で）?
それは実際に安心させてくれました。年単位で測定される保守? 他の人には問題かもしれませんが、私には違います。それは怖くありません。小さな洞察もありました: Markdown はおそらく AI 時代の人間とコンピューターの相互作用の最も基本的なフォーマットです。今後さらに多く使うでしょう。そうなら、なぜ無期限に保守しないのでしょうか?
余談として、このプロセスの中で、長年にわたって複数のライセンスを使用し支払ってきたエディタ — Typora — が実は上海に拠点を置く会社によって開発されていることを発見しました。
2 週間後、VMark は基本的な形になりました。1 か月後の 2026 年 1 月 27 日、ラベルをalphaからbetaに変更しました。
意見の強いエディタ
VMark は 非常に意見が強い です。実際、すべてのバイブコーディングされたソフトウェアとサービスはそうなるだろうと思います。これは避けられません。なぜならバイブコーディングは本質的に会議なしの製造プロセス — 私と決して反論しない実行者だけです。
いくつかの個人的な好みを挙げます:
すべての非コンテンツ情報はメインエリアから外れなければなりません。フォーマットメニューでさえ下部に配置されています。
頑固なタイポグラフィの好みがあります。
中国語文字の間にはスペースが必要ですが、中国語テキストに埋め込まれた英語の文字はそうではありません。VMark 以前、このニッチで商業的に価値のない要件を満たすエディタはありませんでした。
行間隔はいつでも調整できなければなりません。
テーブルはヘッダー行にのみ背景色があるべきです。縞模様が嫌いです。
テーブルと画像は中央揃えにできるべきです。
H1 の見出しだけに下線があるべきです。
通常コードエディタにしか見つからない機能が存在しなければなりません:
マルチカーソルモード
複数行ソート
自動句読点ペアリング
他はオプションですが、あると良い:
Tab による右エスケープ
WYSIWYG の Markdown エディタが好きですが、ビュー切り替えが嫌いです（時々必要ですが）。そこでソースピーク機能（F5）を設計し、ビュー全体を切り替えずに現在のブロックのソースを表示・編集できるようにしました。
PDF をエクスポートするのはそれほど重要ではありません。動的 HTML をエクスポートする方が重要です。
などなど。
間違いとブレークスルー
開発中に無数の間違いを犯しました:
早すぎる複雑な機能の実装でスコープを不必要に膨らませた
後に削除された機能に時間を費やした
進路に迷い、何度も再スタートした
指導原則なしに長い間道を進んでから気づいた
要するに、未熟なエンジニアが犯すあらゆる間違いを何度も経験しました。その結果、朝から晩までほぼ休みなく画面を見つめていました。痛いけれど、喜ばしい。
もちろん、正しくやったこともありました。
例えば、コア機能が固まる前に、VMark に MCP サーバーを追加しました。これにより AI がコンテンツを直接エディタに送信できるようになりました。ターミナルの Claude Code に単純に尋ねることができました:
「この機能をテストするための Markdown コンテンツを、エッジケースを包括的にカバーして提供してください。」
毎回、生成されたテストコンテンツは驚かせ、膨大な時間とエネルギーを節約してくれました。
最初は、MCP が本当に何かまったく分かりませんでした。MCP サーバーをクローンして VMark とはまったく関係のない何かに修正した後で深く理解できました — CCCMemory と呼ばれる別のプロジェクトに至りました。バイブ学習、まさに。
実際の使用では、Markdown エディタに MCP を持つことは非常に便利です — 特に Mermaid 図を描くためです。AI ほどよく理解しているものはいません。正規表現も同じです。今では日常的に AI に分析レポート、監査レポートを出力して直接 VMmark に送ってもらいます。ターミナルや VSCode で読むよりずっと快適です。
2026 年 2 月 2 日 — バイブコーディングコンセプトの誕生から正確に 1 年後 — VMark は本当に快適に使えるツールになったと感じました。まだ多くのバグがありましたが、すでに毎日書くために使い始めており、途中でバグを修正していました。
コマンドラインパネルと AI Genie（正直言って、様々な AI プロバイダーの癖のせいでまだあまり使えませんが）も追加しました。それでも、どんどん自分にとって良くなっていく道が明確で、他の Markdown エディタをもはや使えなくなっていました。
Git は必須
6 週間経って、自分のような「非エンジニア」と共有する価値のある細かいことがいくつかあると感じました。
まず、本物のエンジニアではありませんが、ありがたいことに基本的な git 操作を理解しています。git はエンジニアだけが使うツールのように見えますが、何年も git を使ってきました。振り返ると、GitHub アカウントを登録したのは約 15 年前だと思います。
高度な git 機能はほとんど使いません。例えば、Claude Code が推奨する git worktree は使いません。代わりに 2 台の別々のマシンを使います。基本的なコマンドのみを使い、すべて Claude Code への自然言語命令を通じて発行します。
すべてはブランチで起こります。自由に遊んで、それから言います:
「これまでの教訓をまとめて、現在のブランチをリセットして、最初からやり直しましょう。」
git なしでは、非自明なプロジェクトは何もできません。これは非プログラマーにとって特に重要です: 基本的な git の概念を学ぶことは必須です。Claude Code が作業するのを見ているだけでも自然に多くを学べます。
次に、TDD ワークフローを理解しなければなりません。テストカバレッジを向上させるためにあらゆることをしてください。境界線としてのテストの概念を理解してください。バグは避けられません — 穀物庫の米象虫のようなものです。十分なテストカバレッジなしでは、見つける見込みがありません。
バイブコーディングでなくバイブ思考
中心的な哲学原則はこれです: あなたはバイブコーディングしているのではなく、バイブ思考しています。プロダクトとサービスは常に思考の結果であり、労働の必然的な結果ではありません。
AI は多くの「やること」を引き継ぎましたが、何を、なぜ、どのようにという根本的な思考においては補助することしかできません。危険なのは、AI は常にあなたの先導に従うことです。思考を AI に頼ると、静かにあなたを自分の認知バイアス[2]の中に閉じ込めます — これまでより自由に感じさせながら。歌詞のように:
「私たちは皆ここに囚われている、自分自身の仕掛けによって。」
AI によく言うのは:
「あまり好きではないライバルとして私を扱ってください。私のアイデアを批判的に評価して直接挑戦してください、ただしプロフェッショナルで非敵対的に。」
結果は一貫して高品質で予想外です。
別のテクニックは異なるベンダーの AI に互いに議論させることです。[3] Codex CLI の MCP サービスを Claude Code にインストールしました。よく Claude Code に言います:
「今解決できなかった問題をまとめて、Codex に助けを求めてください。」
または Claude Code のプランを codex CLI に送ります:
「これは Claude Code が作成したプランです。最もプロフェッショナルで率直で容赦のないフィードバックを望んでいます。」
それから Codex の返答を Claude Code に送り返します。
Claude Code の/auditコマンドを発見したとき（10 月初旬頃）、すぐに/codex-auditを書きました — MCP を使って Codex CLI を呼び出すクローンです。AI を使って AI をプレッシャーをかけ監査することは、自分でやるよりずっとうまくいきます。
このアプローチは本質的に再帰の変形です — 「Google の効果的な使い方」を Google で検索するのと同じ原則です。だから複雑なプロンプトエンジニアリングにあまり時間をかけません。再帰を理解していれば、より良い結果は必然です。
ターミナルのみ
性格的な要素もあります。エンジニアは本当に 細部を扱うことを楽しまなければなりません。そうでなければ、作業は悲惨になります。すべての細部には無数のサブ細部が含まれています。
例えば: カーリー引用符対ストレート引用符; カーリー引用符がどれだけ目立つかは CJK フォントよりラテンフォントに依存します（VMark 以前は知らなかったこと）; 引用符が自動ペアになる場合、右ダブル引用符も自動ペアになる必要があります（まさにこの記事を書きながら気づいた細部）; 一方で、右カーリーシングル引用符は自動ペアになるべきではありません。これらの細部を扱うことが喜びを与えないなら、プロダクト開発は必然的につまらなく、イライラし、さらには怒りを招くものになります。
最後に、もう一つの非常に意見の強い選択について言及する価値があります。エンジニアではないから、必要性から、より正しい道と信じるものを選びました:
IDE を一切使わない — ターミナルのみ。
最初はデフォルトの macOS ターミナルを使いました。後にタブと分割ペインのために iTerm に切り替えました。
なぜ VSCode のような IDE を放棄するのか? 最初は複雑なコードを理解できなかったから — そして Claude Code はしばしば VSCode をクラッシュさせました。後に理解する必要がないことに気づきました。AI が書いたコードは、自分が — あるいは雇える範囲のプログラマーが（OpenAI の科学者は雇える人ではありません） — 書けるものよりずっと優れています。コードを読まないなら、diff を読む必要もありません。
最終的に、ドキュメントを自分で書くのをやめました（ガイダンスはまだ必要です）。vmark.appウェブサイト全体が AI によって書かれました; 私はバイブコーディング自体の振り返りを除いて、一文字も触れていません。
投資と同じです: 財務諸表は読めますが、決して読みません — 良い会社はそれなしで明らかです。重要なのは方向性であり、細部ではありません。
だからこそ VMark のウェブサイトにこのクレジットが含まれています:
非常に意見が強いことのもう一つの結果: VMark がオープンソースであっても、コミュニティのコントリビューションは見込み薄です。それは純粋に自分のワークフローのために構築されており、多くの機能は他の人にとってほとんど価値がありません。さらに重要なのは、Markdown エディタは AI 技術の最先端ではありません。慣れ親しんだツールの無数の実装の一つです。AI はそれに関連するほぼすべての問題を解決できます。
Claude Code は GitHub Issue を読み、バグを修正し、報告者の言語で自動的に返答することもできます。Issue をエンドツーエンドで処理するのを初めて見たとき、完全に呆然としました。
リトマス試験
VMark の構築は、学習に対する AI のより広い意味についても考えさせました。すべての教育は生産指向であるべきです[4] — 未来は創造者、思考者、意思決定者のものであり、実行は機械に委ねられます。AI を使用する誰にとっても最も重要なリトマス試験:
AI を使い始めた後、あなたはより 多く 考えていますか、それとも 少なく 考えていますか?
より多く考えている場合 — そしてより深く考えている場合 — AI は正しい方法で助けています。少なく考えている場合、AI は副作用を生み出しています。[5]
また、AI は「より少ない作業をする」ためのツールでは決してありません。論理は単純です: より多くのことができるから、より多く考え、より深く進めます。その結果、できること — そしてしなければならないこと — は増加するだけで、減少しません。[6]
この記事を書きながら、偶然いくつかの小さな問題を発見しました。その結果、VMark のバージョン番号は 0.4.12 から 0.4.13 に上がりました。
コマンドラインで主に生活するようになって以来、大きなモニターや複数のスクリーンに対するニーズをもはや感じません。13 インチのラップトップで十分です。小さなバルコニーでさえ「十分な」ワークスペースになれます。
METR の無作為対照試験では、経験豊富なオープンソース開発者（割り当てられたプロジェクトで平均 5 年の経験）が AI ツールを使用したとき実際に 19% 遅く なったことが判明しました。彼らは 24% のスピードアップを予測していたにもかかわらずです。この研究は知覚と実際の生産性向上の間のギャップを浮き彫りにしています — AI は既存のスキルを増幅するときに最も役立ち、欠落しているスキルを代替するのではありません。参照: Rao, A., Brokman, J., Wentworth, A., et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR Technical Report. ↩︎
人間のフィードバックで訓練された LLM は、真実の応答を提供するのではなく、ユーザーの既存の信念に体系的に同意します — 研究者がお世辞と呼ぶ行動です。5 つの最先端の AI アシスタントと 4 つのテキスト生成タスクにわたって、モデルは一貫してユーザーの意見に合わせて応答を調整しました。たとえそれらの意見が間違っていても。ユーザーが単に間違った答えを示唆するだけで、モデルの精度は大幅に低下しました。これはまさに上で説明した「認知バイアストラップ」です: AI はあなたに挑戦するのではなく、あなたの先導に従います。参照: Sharma, M., Tong, M., Korbak, T., et al. (2024). Towards Understanding Sycophancy in Language Models. ICLR 2024. ↩︎
このテクニックはマルチエージェントディベートと呼ばれる研究アプローチを反映しています。複数の LLM インスタンスがいくつかのラウンドにわたって互いの応答を提案し挑戦します。すべてのモデルが最初に間違った答えを生成しても、ディベートプロセスは事実性と推論精度を大幅に改善します。異なるベンダーのモデル（異なるトレーニングデータとアーキテクチャを持つ）を使用することでこの効果が増幅されます — それらの盲点はほとんど重複しません。参照: Du, Y., Li, S., Torralba, A., Tenenbaum, J.B., & Mordatch, I. (2024). Improving Factuality and Reasoning in Language Models through Multiagent Debate. ICML 2024. ↩︎
これは Seymour Papert のコンストラクショニズムの理論と一致しています — 学習者が情報を受動的に吸収するのではなく、意味のある成果物を積極的に構築するときに学習が最も効果的であるという考え。Piaget の Papert の学生は、具体的な製品（ソフトウェア、ツール、創造的作品）を構築することが伝統的な指導よりも深い認知プロセスを引き起こすと主張しました。John Dewey は 1 世紀前に同様の主張をしました: 教育は受動的な暗記ではなく、体験的で現実の問題解決に結びついているべきだと。参照: Papert, S. & Harel, I. (1991). Constructionism. Ablex Publishing; Dewey, J. (1938). Experience and Education. Kappa Delta Pi. ↩︎
666 人の参加者を対象とした 2025 年の研究では、AI ツールの頻繁な使用と批判的思考能力の間に強い負の相関（r = −0.75）が見つかりました。認知オフローディング — 外部ツールに思考を委任する傾向 — によって媒介されています。参加者が AI に頼るほど、自分の分析能力を活用する機会が少なくなりました。若い参加者は AI への依存度が高く、批判的思考スコアが低い傾向がありました。参照: Gerlich, M. (2025). AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking. Societies, 15(1), 6. ↩︎
これはジェヴォンズのパラドックスの現代的な例です — 1865 年の観察で、より効率的な蒸気エンジンは石炭消費を減らすどころか増加させたというものです。コストが下がると需要が刺激されるためです。AI に適用すると: コーディングと執筆がより安くて速くなるにつれて、作業の総量は縮小するのではなく拡大します。最近のデータはこれを支持しています — AI 習熟者の開発者の需要は 2025 年に前年比で約 60% 急増し、AI ツールを使いこなす開発者に対して 15〜25% の報酬プレミアムがつきました。効率性の向上は新しい可能性を生み出し、新しい作業を生み出します。参照: Jevons, W.S. (1865). The Coal Question; The Productivity Paradox of AI, HackerRank Blog (2025). ↩︎