HieronymusとOJT後のgemini-cli

Hieronyumusのマニュアルを執筆しています。

まだまだ十分とは言えませんが、一通りの機能は書けたと思います。

動かしながらマニュアルを執筆していると、当然のようにバグを発見します。そのバグを「あるべき姿」に修正して、マニュアルを書き進めます。

やったこと(やっていること)

マニュアルの執筆はデモデータを作りながらということもあり、操作してはスクショを撮って、画像編集して貼り込んで… ということの繰り返しです。この部分については、まだ自動化していません。

その過程で発見されたバグは作業指示を書いてgemini-cliに処理させます。

前回書いたような設定をちょこちょこ進化させて、今では「Issue渡してバグ修正させる」という程度のことは完全自動化されました。 MCPとか使ってテストも自動化したいのですが、手作業には手作業の良さがあることも発見してしまったので、そこまでのモチベーションはありません。

geminiのバージョンも進んで、かなり信用できるようになりました。以前はかなり高頻度で途中でコケるということがありましたが、最近はそれも随分減ったように思います。

gemini-cliを使うようになって2回ほどリリースしていますが、いずれもリリースノートはgemini-cliに書かせています。作業ログを日々書かせていますから、それを元にリリースノートを書かせるわけです。これもなかなかいい感じです。

わかったこと

面倒臭くてやってなかったことや不十分だったことが、gemini-cliのお陰で随分とちゃんとできるようになりました。

作業ログ書く
リリースノートを書く
面倒なバグを綺麗にする

というようなことは自分の目の前の問題とはあまり関係ないので、ついつい後回しにしてしまいがちですが、環境設定をちゃんとしてやることでほぼ自動化されています。

「環境設定」の多くは流用可能なので、Huishiの開発にも使っています。

そう考えると、「下っ端コミッター」がやっているような作業は、だいたいAIコーディングで代替可能なんじゃないかということに気がつきます。

大きなプロジェクトであれば、開発者も大勢いてやってくれるようなことでも、Hieronymusのような小規模プロジェクトだと何でもかんでも自分でやらなければなりません。また弊社のようにビジネスを模索している時だと、「完成度はイマイチでもラインアップは増やしたい」という希望がありますが、それをやるにはマンパワーの問題がありますし、完成度が低いままだと売れるものも売れません。

特に心配してしまうのは、「下手に広まってしまえば、膨大なissueに対応しきれなくなるのではないか？」ということです。 広まって欲しい気持ちは切実にあるわけですが、そうなれば気がついてなかった問題も顕在化してしまいます。広まってしまえば対応もスピードが求められるようになるでしょう。その時に対応するだけの時間や手間が割けるかと言えば、ちょっとわかりませんよね。

でも、泣きながらでも環境設定をやって、「issueを投げるだけで修正してくれる」という体制ができてしまったので、この心配はなくなりました。これは弊社のような零細企業がオープンソースなものを公開する時には非常に力となります。安心して開発し、安心して布教できます。

かつては大きなプロジェクトでしかできなかった分業体制を、小さなプロジェクトでもできるようになりました。