人生3回目のCSVエディタ開発をしている理由。SmoothCSV作者がビルド不能から再起するまで【フォーカス】

「SmoothCSV」という、多機能なCSVエディタがあります。表計算ソフトのような操作感を持ちながら大規模データでも軽快に動作し、SQLによるデータ抽出や高度な編集機能を備えたこのツールは、エンジニアやデータアナリストの間で支持を集めてきました。開発者は、医療系スタートアップでエンジニアを務めるkohiiさんです。

驚くべきは、このソフトウェアが約15年の間に「3回」もフルスクラッチでつくられていることです。2011年に「Java Swing」（GUIツールキット）で開発されたバージョン1（v1）、2016年にオープンソース化されたv2。このv2では数年間、開発が停滞するも、2025年には技術スタックをTypeScript / RustとTauri（※）に全面刷新した「v3」が公開されました。

完全に異なる技術スタックにしてまで、なぜ同一ジャンルのツールを、これほどの執念でつくり続けるのか？

「今度は、本気でやってみようと思ったのです」と語るkohiiさん。3度にわたる開発の経緯と、これまでの経験を踏まえて「限られた時間の中でコミットを続けていくため」にとっている戦略について聞きました。

※Tauri（タウリ）：HTML、CSS、JavaScriptなどWeb標準技術でフロントエンドを、Rust言語でバックエンドを記述するデスクトップアプリ開発のツールキット。 描画エンジンをアプリ内に内包せず、各OSが標準で持っているWebView（WindowsのWebView2、macOSのWebKit等）をAPI経由で呼び出して利用するアーキテクチャを採用している。

• keyboard_arrow_down 「もうCSVエディタなんて求められていないのかも」と思ったあの日
• keyboard_arrow_down 限られた時間で開発するための「AI-Ready」戦略
• keyboard_arrow_down それはもはや「CSVエディタ」ではない。最強の“表形式データ”プラットフォームがつくりたくて

――まず、2011年。kohiiさんがSmoothCSV v1をつくり始めた経緯を振り返っていただけますか。

kohii：当時の自分は新卒で入社したSIerにて、公共・医療系の部署に配属されていました。そこでは、医療や保険に関する業務システムを扱っており、CSVのフォーマットが特殊なものも多々あったんですね。「行によって列数が異なる」あるいは「ある列の値がどういう意味を持つかは、別の列の値によって決まる」といった複雑な仕様を持つCSVを正確にハンドリングする必要がありました。

しかしCSVを扱える既存のソフトをどれだけ試しても、「自分が欲しいと思うものとはちょっと違うな」と僕は感じていました。

――「欲しいものと違う」というのは、具体的に何が足りなかったのでしょうか。

kohii：一番大きかったのは、CSVを扱えるツールに「両極端」なものしかなかったことです。

片方の「極」は、テキストエディタです。データを生のまま扱えますが、カンマ区切りの文字列を目で追わなければいけないため、データの構造を把握しづらいというデメリットがありました。

もう一方の極はMicrosoft Excelをはじめとした「表計算ソフト」です。これらは表形式で閲覧と編集ができ視認性は高いものの、CSVはあくまで「インポート/エクスポートされるもの」であり、その過程で元データにはあった表現が抜け落ちてしまいます。インポート時に「00123」というコードが数値として解釈されて「123」になってしまう「ゼロ落ち」や、意図しない日付変換などが起きてしまう。エクスポートする過程でも、元のデータとはフォーマットが変わるリスクが常にありました。

また他のCSVエディタでも、「行によって列数が異なる」など「テーブルとしては正しくないがテキスト表現としては可能」なデータを扱えませんでした。

「CSVをCSVとしてなるべくそのまま、かつExcelのような表形式で快適に扱いたい」。その中間の需要を満たすものが存在しませんでした。

加えて、表形式データである以上はデータベースのように柔軟に扱いたいという思いも自分にはありました。結合やデータの追加など、SQLを使って操作したくなる場面が多かったため、そうした機能も実現したいと考えた。

「そういうものがあれば他の人も使いたいのではないか」。そんな予感に従って、v1を開発しました。

――CSVを生のまま使い、表形式で、SQL。追い求めてきた要素が広そうですね。ずばり、エディタとしてのコンセプトをひと言で表すとしたらどうでしょうか？　どんなソフトを目指してきましたか。

kohii：難しいですね。ワンコンセプトで「『これ』があるからいいんですよ」というよりは、CSVの閲覧や編集において必要なことが全て「ストレスなく思い通り」にできる状態を目指してきました。

もちろん、大量の行数を扱えるパフォーマンスなどは大前提です。それ以上に重視しているのはユーザーの意図を汲み取る“おもてなしの心”と、「期待したものがそこにない」「日本語入力中の挙動がおかしい」「特定の操作で一瞬待たされる」といった、業務中に思考を阻害し得る小さなストレスを、徹底的に排除することです。

そうしたストレス要素が無く、手足のように動き、ユーザーが使った瞬間に「うおーっ、これだよこれ！」と感じてくれるようなソフトが理想系です。

――そうしてJava Swingで開発されたv1は、ソフトウェアを紹介する雑誌に掲載されるなど一定の評価を得たのですよね。

――一方で、GitHubのリポジトリを見る限り、2016年に公開されたバージョン2（v2）は、ある時期から開発が停滞しています。何があったのでしょうか。

kohii：まず「v1」は新卒レベルの技術でつくったこともあって内部のコードが綺麗とはいえず、次第にメンテナンスが辛くなっていきました。

問い合わせへの返信も滞りがちになったので、2016年ごろに設計を見直してつくり直したのがv2です。「オープンソース化して、みんなでメンテナンスできるといいな」と。

しかしv2を出した頃には、僕自身の環境や心境が変化していきました。当初のSIerはすでに退職し、小さなベンチャー企業に勤めていました。そこでは「自分たちで会社をつくっている」という感覚が楽しく、持てるリソースの多くをそちらでの開発に割くようになりました。

また個人開発は、プライベートの時間を削って行うものですよね。本業に大きな時間を割いているうえに、当時は多趣味で他の活動もしていたため、相対的にSmoothCSVの優先度が下がっていきました。

――本業や私生活の充実に伴い、自然と手が離れ気味になったのですね。

kohii：加えてv2に関しては「全然フィードバックがなかった」というのも大きかったです。

そもそも当時の自分は「いいものをつくれば、勝手に広まるはず」という勘違いを抱えていました。実際、v1の時は特に宣伝をしなくても、口コミなどで一定の反響をいただいていたのです。今思えば、これは運が良かったのでしょう。

かたや、v2に対する反応は極めて薄いものでした。

実のところ、僕には昔から「あわよくば、自分が生み出したもので食べていければ」という思いもありました。なので、v2の反響の薄さを受けて「食べていくどころか、そもそも自分がつくりたかったものはもう、求められていないのか？」とモチベーションを失ってしまい……。

――ではなぜ今回、空白期間を経て3度目の開発（v3）に至ったのでしょうか。

kohii：2020年よりいよいよSmoothCSVを放置するようになり、数年が経つ頃にはv2の開発環境は破綻していました。僕の開発環境はmacOSなのですが、OSのアップデートが重なるうち、JDK（Java Development Kit）とOSの統合部分などで不整合が起き、ビルドすら通らない状態になっていたんですね。

転機は2024年です。ある日GitHubを通じて、海外のユーザーからプルリクエストが届きました。

しかし手元でビルドできない以上、再現確認もできなかった。結局何もできずに、泣く泣くそのプルリクエストをクローズせざるを得ませんでした。

――修正を受け入れることすら、したくてもできなかった。

kohii：そうして「このツールのメンテナンスはもう終了しているんです」とお伝えしたのですが、それに対するユーザーの返信が頭の中に残ってしまって。

• No worries and thank you for your reply.
  Please write on this repo if you’ll ever start developing a newer version. SmoothCSV has been extremely helpful in my day-to-day work routine.
• （気にしないで、ご返信ありがとう。もしも新たなバージョンの開発を始める予定があれば、ぜひこのリポジトリで知らせてください。SmoothCSVは、私の日々の仕事になくてはならない存在です）

というものでした。

――それで、再起を？

kohii：正直なところ、そのコメントを受けてすぐに「よし、またつくり直そう」などと決意したわけではありません。ただ、ちょうどその頃は、僕が個人で開発していた別のWebサービスがうまくいかず、何か次のお題を探していたタイミングでもありました。

「なんとか世に求められるものを開発したい。次は何をつくるべきか」を模索していた時期に、こうしたやりとりがあったので、改めて世の中のCSVエディタ事情を調査してみたのです。

相変わらず「これが覇権を取るだろう」と思えるツールは生まれておらず、デファクトスタンダードは存在しないままでした。そこで「やはり、もっといいツールをつくる余地があるのでは？　またやってみよう」と気持ちを新たにしたんですね。

――海外からのコメントはひとつのきっかけに過ぎず、冷静な気持ちで受け止めていたのですね。

kohii：いえ、うれしかったですよ。めちゃくちゃ、うれしかった。

振り返ると、これはv2のリポジトリに寄せられた唯一のプルリクエストでした。当時、僕は発信活動もしておらず影響力は皆無で、一体どうやってこのツールを見つけてくれたのか不思議に思ったほどです。しかし、SmoothCSVを見つけ出し、使い続け、さらに「なくてはならないもの」と評価してくれる方が、世界のどこかに確かに存在していた。「もう需要などない」と諦めかけていた僕にとって、強烈な体験でした。

だから「今度は本気でやろう」と思いました。技術的な工夫はもちろん、もう「いいものをつくれば勝手に広まるだろう」とクールに構えるようなスタンスをやめることにしたんですね。

「Zenn」や「Product Hunt」や「Dev.to」といった海外の技術コミュニティでも積極的に発信し、マーケティングにも力を入れようと考えました。

はたして、本当はどれほどの需要があるのか、全力で取り組んでみたらどうなるのか確かめてみたくなったのです。

そうして人生3度目の、CSVエディタのフルスクラッチ開発に着手しました。

――v3で、これまでと大きく変えた点は何でしょうか？

kohii：大きな点としてまずはJavaから移行し、v3ではTauriを採用しました。これに伴い、フロントエンドにTypeScript / React、バックエンドの言語にはRustを選定しています。Rustの学習コストはやはり大きいですが、しかしそれを支払ってでも乗り換える価値が十分にあると判断しました。

「ストレスなく思い通り」に編集できるCSVエディタをつくる上で、現在の自分にとってJVMは最適解でないと考えたからです。正直なところ「今、僕がJVMを選ぶ理由がない」と感じた、という方が正確かもしれません。

JVMは安定して動作させやすい半面、起動には時間がかかり、メモリも多く消費します。「手元のちょっとしたデータをCSVで見たい」という時に、起動で数秒待たされるのは、サクサク動いてほしいエディタとしては大きな課題です。

また、Java / Swingに習熟したところで、現在の僕が関わる開発現場ではほとんど生かせず、そこにリソースを割きたくないとの思いもありました。加えて、多くの開発者が選ばない技術を採用するのは、ネット上の情報量が少なかったり技術の進化が遅かったり、というようなリスクがあります。

一方、OSネイティブのWebViewを利用するTauriなら、ChromiumやNode.jsを丸ごと同梱するElectronなどと比較してもバイナリサイズも小さく、メモリ消費も抑えられます。Rustによるバックエンド処理も高速です。

またUI構築には現在の僕が慣れ親しんでいるHTMLやCSSといったWeb技術をそのまま使えるため、UIを細部まで自由に、かつ効率的に構築できると考えました。もちろん、Web技術を用いることで巨大なデータを扱った際の描画処理の重さも懸念されますが、そこは仮想スクロールの自作などでカバーしつつ、UI構築の効率を優先することにしています。

あと、企業の採用活動でもそうですが、モダンな言語を採用したほうが長期的にはエンジニアの関心を集めやすいと考えました。将来的にv3をOSSとして公開しコミュニティを広げる可能性を見据えて、他の開発者が「触ってみたい」「参加してみたい」と思える技術スタックにしておくべきだと。

――他にこだわったことがあれば、教えてください。

kohii：メンテナンス性と拡張性の担保でしょうか。v3のアーキテクチャ設計では、「VS Code」のような設計思想を取り入れています。

象徴的なのが「コマンドシステム」の刷新です。「ファイルを保存する」「検索窓を開く」といったアプリケーションの操作を「コマンド」として定義する。この仕組み自体はv2の頃からあったのですが、v3ではそのAPI設計をVS Codeとほぼ同じ構造につくり変えました。

――どのような利点があるのでしょうか。

kohii：最大のメリットは、標準機能も含めてすべてを「拡張機能」として実装できる点です。

通常、新しい機能を追加しようとすると、どうしてもアプリケーション本体のコードに手を加える必要が出てきます。すると機能が増えれば増えるほど、本体のコードは肥大化し複雑になる。

一方でVS Codeのようなアーキテクチャなら、コマンドを定義したり、それが有効になる条件を宣言したりするためのAPIさえ最初に用意すれば、あとはその上にパズルのピースを足していく感覚で機能を増やせます。標準機能であっても、本体とは切り離されたプラグインのようにつくれる。

こうすれば、機能が増えても本体のコードはシンプルなまま保てます。もし機能の実装が気に入らなければ、その部分だけを捨ててつくり直すことも容易になる。結果として、規模が大きくなってもコードが複雑に絡み合うのを防ぎ、メンテナンスしやすい状態を維持できると考えました。

それに加えて、コードの管理方法には「モノレポ」構成を採用しつつ、徹底的な「関心の分離」を行っています。CSVのパース処理、表形式エディタの描画ロジック、SQLの解析エンジンなど、機能ごとにパッケージを明確に分割し、それぞれが独立して動くようにしている。「ひとつの関心事は、1箇所に凝縮させる」という原則を徹底することで、大規模になっても破綻しないコードベースを意識しています。

――とはいえ、大変不躾なことを申し上げると、過去、特にv2においては開発が止まってしまった経緯がありますよね。メンテナンスがしやすくなったとはいえ、開発を持続可能にするための、より根本的なアプローチなどは考えているのでしょうか。

kohii：おっしゃる通り、そこは最大の懸念事項でした。しかも、v3を開発し始めた昨年の7月に、第1子が生まれまして。以前から「子供が生まれれば、自分の時間はなくなる」とは聞いていましたし、いよいよ物理的に開発に充てられるリソースが極限まで少なくなる現実を前にして、どう向き合うべきかについては真剣に悩んでいました。

そこで導き出した、開発を止めないための僕なりのリスクヘッジこそが、今申し上げたような設計なのです。

コードベースを綺麗に保ち、機能ごとに関心を分離しておくことは、僕自身や他の方がメンテナンスしやすいのはもちろん、さらには「AIコーディングエージェント」にとっても非常に働きやすい「AI-Ready」な状態であることをも意味します。

――これらはAIの活用を見越しての設計だった、ということですか。

kohii：はい。やはりAIエージェントが開発現場で当たり前に使われるようになることは明白でしたから、活用しない手はない、と。

AIも人間と同じで、多くの依存関係や背景にある文脈といった事情を、あらかじめすべて頭に入れておかないと理解できないようなコードベースでは、精度の高いコード生成ができません。さらに、そうした複雑に絡み合うコードの中で、AIに無理やり目的を達成しようとすると、既存の構造を無視した実装になるなど、余計に複雑さを増やしてしまいます。

しかし、関心がうまく分離されていれば、やりたいことに対して「どこをどうすればよいか」が明確になり、変更の影響範囲も局所化されます。

このように、コードベースが理想的な構造に近づくほど、結果としてワンショットでこちらの意図に近いものが出てくる確率が高まると考ました。実際に、一定程度の複雑さの機能までなら、欲しいアウトプットを一発で出してくれることが増えています。

今の僕にとっての開発速度の源泉は自分がタイピングする速さではなく「コードベースの状態」にあります。人間にとっても読みやすく、AIにとっても扱いやすい状態を維持する。こうすることで、育児による物理的な時間が削ぎ落とされた中でも、開発を止めることなく進めることができていますし、ユーザーからのちょっとした修正要望などにも、即座に対応できるようになりました。

――最終的には、SmoothCSVというソフトウェアをどのような存在にしたいと考えているのか教えてください。

kohii：究極的なゴールは「表形式データ全般を扱える『VS Code』」のような存在です。

VS Codeは拡張機能を入れることであらゆるプログラミング言語や開発のニーズに対応できますよね。それと同じように、SmoothCSVを「表形式のデータを扱うための共通プラットフォーム」にしたいのです。

ここまでずっと「CSV」と繰り返してきましたが、そもそも、僕たちが普段扱う表形式データはCSVだけではありません。ParquetやAvro、Excel、あるいはデータベースの検索結果など、多岐にわたります。現状これらを閲覧・編集するにはそれぞれ専用のツールを使うか、重い統合環境を開く必要があります。

そこでSmoothCSVという「表データを快適に操作できるツール」をベースに「拡張機能を追加することで、CSV以外のあらゆるフォーマットも同じ操作感で扱える」状態にしたいとも考えています。

先ほどお話しした「関心の分離」や「コマンドシステム」ともつながるのですが、コア機能を疎結合にし、プラグインのように切り出せる設計にしたのは、将来的にユーザー自身が自由に拡張機能をつくり、あらゆる表データを扱える仕組みを見据えているから、というのもあります。

そうしてロードマップ通りに開発が進み、もしもこうしたシステムを実現できたら、ソフト名も「SmoothCSV」ではなく、「Grid」や「Table」といった概念を中心に据えたものへと改名しようかとも思っています。

――そこまでの構想があったとは。しかし、そこまでしての3回目の挑戦を支えるモチベーションの源泉は、現在はどこにあるのでしょうか。やはり、マネタイズなどですか？

kohii：マネタイズは考えていますが、現状はしていません。それよりも、まずは世の中に求められるものをつくること。「CSVを扱うなら、これを選ばない理由がない」といわれるレベルにまで到達すれば、結果は自然とついてくるだろうと考えています。

もちろん、AIの進化次第で、こうしたツール系ソフトウェアの需要自体が減っていく可能性もあるとは認識しています。

しかしそうした時代が完全に到来しない限りは、自分が考える理想のSmoothCSVには、確かな価値があると今の僕は信じています。自分の「理想」を形にしてお見せしたいですし、現在いただいている多くの要望にも応えたい。それらをつくりあげ、このソフトを広く知ってもらった先に何が起きるのか。その未来を早く見てみたいという気持ちが、現在の最大のモチベーションです。

取材・執筆・編集：田村 今人