AIのお陰で最近辛かった個人開発がまた楽しくなった

AIのお陰で最近辛かった個人開発がまた楽しくなった

AIのお陰で最近辛かった個人開発がまた楽しくなった

こんにちは、TAKUYAです。日本語ではお久しぶりです。僕はInkdropというプレーンテキストのMarkdownノートアプリを、デスクトップとモバイル向けにマルチプラットフォームで提供するSaaSとして、かれこれ9年にわたり開発運営しています。

最近、その開発にClaude Codeを導入しました。エージェンティックコーディングを可能にするCLIのAIツールです。
最初の試行は失敗に終わったものの、徐々に自分のワークフローに馴染ませることができました。そして先日、アプリ開発がまた「楽しい」と感じられるようになったのです。これは予想外でした。

本稿では、自分がエージェンティック・コーディングをワークフローに取り入れた方法と、それが個人開発への視点をどう変えたかを共有します。

自分のアプリに技術的負債が山ほどあった

ご想像のとおり、9年も続くサービスをメンテするのは本当に大変です。
初期の頃は新機能の追加も簡単で、すべてがスピーディーに感じられました。しかしコードが増えるたびにソフトウェアは指数関数的に複雑になり、技術的負債も増えていきます。

拙アプリのデスクトップ版はElectron製です。そこに高い拡張性と柔軟なカスタマイズ性を実現するためにAtom Editorのコードを大きく取り込んでいました。巨人の肩の上に立つことで、個人開発者の僕でもテキストエディタに必要な機能一式を素早く実装できたわけです。近年の例でいえばVSCodeをフォークしたCursorのケースに似たアプローチです。

ところがAtomは2022年に突如開発終了となってしまいました。
以来、アプリの多くの依存ライブラリがメンテナンス停止となり、プロダクトを維持するうえで大きな頭痛の種となっていました。時代遅れのライブラリを置き換える作業はまったく楽しくないうえに、ユーザーに直接的な新しい価値をもたらすわけでもありません。必要な作業量は僕ひとりではどうにもならないほどに思え、もう諦めようかと迷っていました。

そこへ登場したのがClaude Codeをはじめとするエージェンティック・コーディング・ツールです。長期運用プロダクトにとって、これはまさにゲームチェンジャーでした。以下では、僕がこのAIツールを導入してみることにした経緯を紹介します。

自転車のようにAIも使い方を練習する必要があった

AIツールが世界中で絶賛されているのを見て、もしかしたら経験豊富な開発者だったら簡単に導入できるだろうと高をくくっていました。
しかしそれは大きな間違いでした。
約1か月前、Claude Codeで簡単なツールを作ろうと試みたものの、散々な結果に終わりました。

ワンショットのプロンプトで“完成品”をまるごと生成させようとしたところ、Claude Codeは誤ったコードや壊れたコードを延々と吐き出しました。
慎重なプロンプト設計やコンテキスト管理、深いレビューなしに「バイブコーディング」に走ると簡単に破綻する ―― これを痛感しました。

自転車は見た目には簡単そうでも実際には練習が必要ですよね。
AIエージェントも同じということを学びました。

動画のコメント欄でいただいたフィードバック(感謝!)から得た学びは次のとおりです。

  1. 行き当たりばったりは NG ―― 綿密な計画を立てる
  • 詳細な仕様を定義し、小さなタスクに分割する。
  • 1 つずつ順番に取り組む。
  • 各パートを進める前に ユニットテストで検証する。
  • プロンプト自体も Claude に 一緒に作らせる ―― プロンプトエンジニアリングが肝心。

2. Vibe coding が真価を発揮する場面

  • ボイラープレートや小規模自動化、レガシーコードなど、手作業したくない退屈なタスク。
  • Claude を リード開発者ではなく助手や作業者として扱う。

3. 自分を置き換えようとせず、自分を拡張せよ

  • 自分が何をしているか理解が深いほど、Vibe coding に頼り過ぎなくなる。
  • AI は直感ではなく実行が得意。スピードアップのために使う。

4. 明確な構造から始める

  • まず TODO リストやロードマップを作る。
  • 作業を 段階に分ける:例)スキャフォールディング → 機能実装 → テスト → 仕上げ。

5. 期待値をコントロールする

  • AI が苦手なのは:
  • 大規模・複雑なコードベース
  • 振る舞いを細かく制御したい場合
  • 非標準スタック(例:Bun + SQLite)

あわせて次の記事も読みました。

次の試行では、Claude Codeを使ってついに自分用のRAGツールを構築することに成功しました。めちゃくちゃ嬉しかったです。

以来、Claude Codeをインターン開発者のような相棒として頻繁に使っています。

つまらない作業はAIに任せ、自分は楽しい作業に取り組む

利用していて気づいたのは、AIエージェント活用の鍵はモチベーションだという事です。つまり、退屈で先延ばしにしがちなタスクをAIが肩代わりしてくれるのです。AIは過去に多くの人が取り組んだありふれたタスクに強いです。ボイラープレート(テンプレート)、スクリプト化、レガシー修正など「自分で書きたくないコード」はAIが素早く片付けてくれます。AIにこういった作業をさせた後は頭の中がスッキリし、ワーキングメモリも解放され、とても爽やかな気分になれました。

僕の場合、Atomの終了で避けられない退屈なタスクが大量に残っていました。代表的なのは次の2点です。

  • ipm — Inkdrop Package Manager(apm をフォーク)
  • ビルドパイプライン — 多くのElectronアプリが Electron BuilderElectron Forge を使う中、Inkdrop はAtom由来の独自で複雑なパイプラインを採用していた

この2つは互いに依存しており、同時に移行する必要がありました。気が重くてずっと後回しにしていたのですが、Claude Codeに現状を解析させ、移行ステップを計画させ、ボイラープレートを生成させることで、
古いipmをシンプルな実装に置き換え、複雑だったビルドパイプラインを Electron Builderへと移行できました。

たとえば、Claude Codeが作ってくれた分析・移行プランはこちら

作業の概要を掴むのに大いに役立ちました。誤情報も混ざっていましたが、ドキュメントを読ませることで修正できました。

これは人生が変わるほどの体験でした。

AIは新幹線である

今世の中には、AIが役立つという人もいれば、そうでもないという人もいます。その分け目は、AIの特性を理解しているかどうかです。AIはコードを驚異的な速度で生成するため「もうコーディングがボトルネックではなくなった」と錯覚しレビューが新たなボトルネックだと誤解されることがちらほらあります。

ここで、AIを新幹線だと考えてみてください。
主要都市へはとても速く行けますが…

  • 速すぎて車窓から景色をじっくり楽しめない
  • 行きたい場所の“目の前”には着かず、大きなハブ駅までしか行けない

東海道新幹線では富士山を眺められるのはほんの数十秒。最終目的地によっては在来線やバス、タクシーに乗り換える必要があります。

同じように、AIツールでは…

  • 生成されたコードの細部をじっくり確認する暇がない
  • 自分の頭の中にある理想を完全に再現することはできない

AIがなぜその結果コードを出力したのか、そのプロセスを追うのはほぼ不可能です。特に、あまり詳しくない言語で出力された場合、細部を理解するのは難しいでしょう。品質を高めるには、結局細かな修正やリファクタリングを人間が行う必要があります。

AIを過大評価する人は、AIが得意な“幹線ルート”までしか使っていません。AIを否定する人は、新幹線に乗りながら富士山を間近で見ようとしています。どちらも使い方が的外れです。新幹線が単なる移動手段であるように、AIも単なるツールです。最終的に「本当に欲しいもの」を作るには、ローカル線や徒歩、つまり手書きのコードが依然として必要です。

つまりボトルネックは今も昔も変わっていません。あなた自身の創造性とクラフトマンシップです。

僕はこの変化にワクワクしています。AIに雑用や退屈な作業を任せつつ、僕はAIが学習データでまだ見たことも聞いたこともない斬新なアイデアの実装に集中できる。

皆さんはこの変化をどう思いますか?

Read more

Inkdrop v6 Canary版リリースしました — 新Markdownエディタやその他新機能盛り沢山

Inkdrop v6 Canary版リリースしました — 新Markdownエディタやその他新機能盛り沢山

Inkdrop v6.0.0 Canary版リリースしました — 新Markdownエディタやその他新機能盛り沢山 こんにちはTAKUYAです。 v6.0.0 の最初の Canary バージョンをリリースしました 😆✨ v6では、アプリのコア機能の改善がたくさん盛り込まれています! * リリースノート(英語): https://forum.inkdrop.app/t/inkdrop-desktop-v6-0-0-canary-1/5339 CodeMirror 6 ベースの新しいエディタ フローティングツールバー v5ではツールバーがエディタの上部に固定されており、使っていないときもスペースを占有していました。 v6では、テキストを選択したときだけ表示されるフローティングツールバーに変わりました。 GitHub Alerts 構文のサポート Alerts の構文が正しい色と左ボーダーでハイライトされるようになりました。 ネストされたアラートや引用にも対応しています。 また、アラートタイプの入力を支援する補完機能も追加されました。 スラッシュコマンド 空行で /

By Takuya Matsuyama
個人開発を7年以上続けて分かった技術選択のコツ

個人開発を7年以上続けて分かった技術選択のコツ

個人開発を7年以上続けて分かった技術選択のコツ InkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。 TL;DR * 最初はとにかく最速でリリースする事を最優先する * 迷ったら「ときめく方」を選べ * 程よいところで切り上げて開発を進める * 使っているモジュールがdeprecatedされるなんてザラだと覚悟する * 古いから悪いとは限らない * シンプルにしていく * 老舗から継続の秘訣を学ぶ * 運ゲー要素は排除しきれない 最初はとにかく最速でリリースする事を目標に技術選定する 開発計画とビジネス計画は切っても切り離せない。 コーディングに傾倒するあまり完璧主義に陥って結局リリース出来ないまま頓挫してしまう個人開発者は多い

By Takuya Matsuyama
子育て中の個人開発者の一日

子育て中の個人開発者の一日

子育て中の個人開発者の一日 どうもTAKUYAです。 久しぶりに生活まわりの事を書きたい。自分はInkdropというMarkdownノートアプリを売って生きている。 子供も無事順調に成長しており、あと数ヶ月で3歳になるというところで、イヤイヤ期もやっと終わりが見えてきた。 生活パターンもなんとなく定着しつつあるので、ここで一旦どんなルーティンなのか書き出してみる。ちなみに当方今年で40歳。 平日の1日の流れ * 06:30 妻と子供起床、朝食 * 07:10–30 俺起床、朝食 * 07:40 布団を畳んで子供を着替えさせる。妻はその間に化粧や通勤の準備 * 08:00 ストレッチと軽い筋トレ(腕立て50回、スクワット100回) * 08:10 妻と子供を見送る。15分前後瞑想 * 08:30 散歩 * 09:00 作業開始(カフェまたは家) * 11:00 昼飯 * 12:00 ダラダラする * 12:30 作業再開(だいたい家)

By Takuya Matsuyama
個人開発で次の5年を生き残るためのブランディング戦略

個人開発で次の5年を生き残るためのブランディング戦略

個人開発で次の5年を生き残るためのブランディング戦略 生成AI時代を生き残るためには、感情がより重要になる/ハイブランドからブランディングを学んでみた/生産的な雰囲気をアプリに取り入れる/エデュテイメント: 教育+エンタメ こんにちは、個人開発で生活しているTAKUYAと申します。 主に英語圏で活動しており、本稿は先日書いたブログ記事の日本語訳です。 個人で作っているMarkdownノートアプリInkdropの価格を、2024年2月5日から月額$4.9(年額$49.9)から$9.98(年額$99.8)に変更しました。Inkdropは2016年にローンチして、「自分がユーザならこれぐらい払う」という基準で値段を設定しました。それからありがたいことに7年以上このアプリを続けられていて、お役に立てている事の証左として捉えて喜びと感謝の気持ちでいっぱいです。奇跡だと思います。その間、状況も大きく変わり、アプリの機能性もずいぶん上がりました。その状況と提供価値を反映するために今回初めて価格を更新する事にしました。 この変更の背景については以下の記事で詳しく述べていますので、興味のある方は

By Takuya Matsuyama