watermint toolbox開発を振り返る
18th September 2025先日Dropboxを退職したことは前回のエントリーでご報告しました。 Dropboxに在籍している約10年間で最も長く取り組んだプロジェクトがwatermint toolboxです。 このプロジェクトも取り組んだのは9年ほどになります。 これは主にDropbox for Teamsの管理者向けのCLIツールで、Windows、macOS、およびLinux環境で動作します。
プロジェクトの終息
このプロジェクトも、先日(2025年8月)アクティブな開発終了をアナウンスしましたとおり、一旦の終息とすることにしました。 にツールが使えなくなることはありませんので、ご利用いただいている皆様はご安心ください。 自身もいまだに週に数回は使うユーザーの一人ですので、重大なセキュリティ上の課題があれば対応しようとは思っています。
プロジェクト終息の理由はいくつかありますが、主な理由は3つほどあります。
ひとつめの理由は自身が利用する理由が減少したことでしょう。先述の通りwatermint toolboxの主な機能はDropbox for Teamsの管理であり、Dropboxを退職したいま、利用するケースは個人用のDropboxを整理整頓したり、データの棚卸しをするために使ったりと限定的です。 ある意味自身のデータ整理のためにまた新しく拡張を作るかもしれませんが、現状それなりに事足りているので拡張を作る可能性も低そうだなと思っています。
ふたつめの理由はGoでのプログラミングに一区切りをつけようと思ったことです。技術的な詳細は後述しますが、AIでコーディングすることが当たり前になった今、よりAIが効率的に使える言語、そしてAIでコーディングしても間違いにくい言語を選択していきたいという技術的視点を持っています。 そのため、100% Goで書かれたこのプロジェクトを続けるのはある種、私のなかでは技術負債にどう立ち向かうかという種類の課題であり、それはこのwatermint toolboxプロジェクトの原点である実験的姿勢とは異なってくるという理解をしているためです。
みっつめの理由は今後10年、20年と自分自身で使い・発展させていくにはフレームワークが不十分だと感じていることと、ある意味、それらフレームワークに必要な要素が実験的過程で概ね目標を果たせたということがあります。 それらの要素はこれも後述しますが新しいプロジェクトの中で発展させていこうと思っています。
成功したこと
プロジェクトの最初のコミットの2026年11月ですが、前身となるいくつかのプロジェクトを含めると2016年6月ごろが開発の始まりです。
必要は発明の母といいますが、このプロジェクトは必要から始まりました。Dropboxチームのメンバーを一括して招待したい、メールアドレスのドメインが変わるので一括変更したい、グループとメンバーの一覧をCSVで取得したい、など。 そんな調子でDropboxチーム向けのコマンドは120以上、個人向けDropboxのコマンドは60以上と、かなり広い範囲のやりたいことをカバーできるようになりました。
成功したと考えている点は次のようなことがあります。
(1) シングル バイナリでの配布
なるべく導入の敷居を下げるために、利用開始前にPythonをインストールしたり、Javaランタイムをインストールする必要のないシングル バイナリ構成で配布できるようにしたこと。このため、当時最も安定していると思えたシングル バイナリでの開発環境であるGoを選びました。結果的にユーザー数も順調に増えましたし、導入の際に他ライブラリとの依存関係がないことから、それらにまつわるサポートQ&Aとも無縁だったことは大きな効果でした。
(2) リリース プロセス
リリース プロセス自体もwatermint toolboxのコマンドとして実装すること。国際化対応するために、UI上のメッセージは全てリソースファイルで管理していますが、各言語ファイルでリソースの不足があればビルドが停止するようにしていたり、リリース プロセスをコマンドで自動化したことにより配布バイナリのテスト、Githubでの公開、Webページの公開など一連のプロセスが自動化されましたのでかなりの工数削減と、手戻り防止に効果がありました。
(3) コマンドの内容調整
Dropbox用だけでも180コマンド以上ありますが、それでも足りない要望というのはさまざまあるものです。しかし、コマンドが何かの環境に特化したものになりすぎないように、可能な限り一般化してからデザイン・実装しました。一度あることは二度あるわけで、その時にはまた別の環境で少しだけ違うことをやりたいというリクエストが来ることが多いです。その時、最初に一般化をしていなかったらまた同じようなコマンドを別に作る必要が出てメンテナンスコストがどんどん肥大化していったことでしょう。
(4) ドキュメントの自動生成
このプロジェクトに使える時間は限られていました。コマンドごとの利用マニュアルを毎回作る時間もありませんでしたので、途中で各コマンドの最低限のマニュアルが生成されるようにドキュメントを自動生成するプログラムを作成してリリースプロセスに含めました。 これにより、ドキュメントがすべてのコマンドに対して網羅的に生成されるようにしました。ドキュメントに必要な説明があればリリースプロセスがエラーで停止し、どのような説明追加が必要かを教えてくれるようにしました。
(5) ログを重視する
watermint toolboxは非常に多くのログを取得しています。実行した時のオプション、バージョン、OSバージョンなどから、Goのヒープ状態、トレースログ、APIコールまでさまざまあります。なお、それらのログにはたとえばOAuthトークンなど秘匿性の高い情報は自動的にマスクされるようになっており、また、サーバに転送などする機構はありませんのであくまで実行したユーザーのディスク上に格納されるだけですので安全に利用できます。 クラウドといっても、アカウントの状態や利用しているプランなどによって同じAPIを同じパラメータで実行しても期待した結果が得られない場合があります。そのような時に、APIコールすべてのパラメータやエラーを含むログは大きな時間短縮につながりました。
ログを使ってプログラムを自動テストする仕組みも作りましたので、再現テストやバグの再発防止に役立ちました。 ログはかなり早い段階ですべてJSON形式(正確にはJSON Lines)にしました。これにより、APIコールのリトライやパフォーマンスについて統計的分析がとてもやりやすくなりました。特定パラメータが含まれたリクエストの条件のログだけ取得するということも簡単でした。
(6) 公式SDKを使わずRESTレイヤーを自作したこと
watermint toolboxの最初の頃はDropbox unofficial Go SDKを使っていました。Unofficialということもありますが、自作に至った経緯としては制御のやりにくさがきっかけです。 ログ出力、エラー発生時の自動再実行（QoS制御付き）、テスト用のモックコールなどさまざまやりたいことが増えた結果、SDKはもはや足枷でした。 RESTレイヤーを自作したことによりログや再実行などの制御を簡単にできるようになりました。
改善の余地があること
(A) ドキュメント生成プロセス
ドキュメントの自動生成は生産性をあげてくれましたが、一方で制約事項もあります。 テンプレートに沿ったドキュメントしか生成できない構造だったので、少しの注釈を入れたり、複数のコマンドについてのユースケースごとの使い分けなどの説明をするドキュメントを作るのにかなり手間がかかり、場合によっては一時的にこのプロジェクト外で別のドキュメントを作って利用したこともあります。
これは、いまならAIを使ったコーディングをすれば、テンプレートの拡張など簡単にお願いできるので、でさほど大きな課題とは言えないものですが、AIなしでテンプレート作成からコード変更、ドキュメント作成とプレビューという一連の流れを実行するのにはかなりの工数がかかりました。
(B) 利用拡大のための努力をあまりしなかったこと
利用者数はこの9年でおおよそ360〜500アカウント程度(2025-09時点、Dropbox APIのIDが歴史的経緯で複数あるため正確な数字は分かりません)、GitHub starは85 (2025-09時点)とまあまあ悪くない数字ですが、もっと伸びてもいい数字だとも思っています。 利用者拡大のためにやれることはもっとあったとは思いますが、一方であまり増えすぎてサポートの手が回らなくなる心配もありました。
ChatGPTのGPTsなどを使って簡単にAIチャットbotを作れるような時代になりましたので、このサポートに関する問題もいまはもう少し影響が小さいと考えてもいいかもしれません。
プロジェクトを通じた発見
このプロジェクトは単に役に立つツールを作るというだけでなく自身にとっての技術的な発見も目標の一つでした。
プログラミング言語
プロジェクトでGo言語を選んでよかったと思えることは次のようなことです。
- シングルバイナリへの出力の容易さと安定性。
- 非常に広く強力なエコシステム。
- 開発ツールのサポート。
一方で苦労したのは次のようなことです。
- 型の制約が弱く、インタフェースの使い方になれるまでかなりの時間を要した。
- リストの和など、基本的なコレクション操作もないため、毎回同じようなコードを書かざるを得ず、隠れたバグを探すのにかなりの時間を使った。
このプロジェクト開始時点で一番詳しかったのはやはり一番長く触っているJavaでした。他にはScalaも当時よく使っていたので、強い型でコードを書くことに慣れていました。 この辺りは言語の特徴を把握してからのデザインの慣れでしょう。
ホビープログラムということで、ある程度集中してプログラムをできる時期もあれば、数ヶ月全く触らないという時期もありましたので、そういった環境では深いレベルでのプログラミング言語への理解と、ハイレベルデザインへの適用というのは難しく感じました。 最近一番使っているRustはまだ理解しきれているとは思っていませんが、強い型に慣れている身からするとかなりやりやすい言語だと思います。
どのようなプログラミング言語でいかに実業務レベルの複雑なユースケースを、考えに考え抜いてデザインに適用してきたかという経験値なのかなとも思います。 最近はほとんどCodex, Claude Code, Cursorなど色々AIを使ってコードを書いていますが、やはりどのAIもPythonが得意でPythonで書きたがる。という癖があると思っています。 そういう意味では、人間もAIも経験値を共通的に高いレベルで持っているプログラミング言語を選ぶというのがいいのかもしれませんが、これは今後の研究課題です。
開発・リリースプロセス
SunやGREEで働いていた頃は、趣味のプログラムもありますが、基本的にプログラムといえばチーム開発でした。 チームで開発するには当然いろいろな決まりごとが必要になります。
今回のプロジェクトは一人で研究的に進めてきたプロジェクトでしたが、チーム開発をしていた経験はかなり役に立ちました。 数ヶ月コードを見ない・触らないという時期があると、バグ修正をしたりコードを拡張しようとしてももはや他人が書いたコードかのようにほとんど忘れてしまっています。
まとまった休みや土日を使ってプロセスを整備するために時間を使ったからこそ、他人が書いたコードに見えるような状況でも開発が滞りなく勧められたのだと思います。 ですから、趣味のプログラムでもプロジェクトのサイズに合わせて最初は軽量でも良いので、リリースプロセスは先に決めて、しっかり自分でそれを守るようにするというのが今後の自分のベストプラクティスになりそうです。
マニュアルの整備
「Done is better than nothing」という言葉があります。これはこのプロジェクトを進めたり、ツールを紹介する中で何度も感じたことです。 マニュアルがあると無いとでは、全く世界が変わります。 開発者の方の中にはせっかく時間をかけてマニュアルを作ったのに、マニュアルを読んでくれないという嘆きも多くあることかと思います。
しかしそれでも、マニュアルがあることによって読もうとしてくれる人がいたり、理解してくれた人が他の人に説明しようとしてくれます。 さらには今ならAIにマニュアルを読み込ませればサポート用のチャットボットも簡単に作れます。
マニュアルの品質が十分で無いなと気になっていたとしても、全くゼロよりは遥かに良いのです。 ですから、新しいコマンドを作る時にコマンドに必要なリソースをすべて準備しなければならないように制約をつけ、マニュアルが自動生成されるようにしたことは自分にとって一番大きな大きな成功だったと感じています。
最後に
watermint toolboxのDropboxに関するお話を中心にしましたが、Figma、GitHub、Asana、DeepL、Slack、Google Workspaceとさまざまなサービスへの対応もこのプロジェクトでは進めていました。 複数サービスに展開するに当たっても、ここまで紹介した内容が非常に役に立ちました。そういったDropbox以外のサービス向けでも使っていただいた皆様ありがとうございます。
watermint toolboxをこれまで使ってくださった皆様、他の方に紹介してくださった皆様、マニュアルを読み込んでサポートをしてくださった皆様本当にありがとうございました。 冒頭に書きました通り、リリース済みのものはまだ利用できますので引き続き皆様のお役に立つことを願っています。