2025年 10月 9日

gemini-cliへの新人教育

おごちゃん

最近になってgemini-cliを使って開発をしています。

元々ChatGPTと会話しながら開発をしていたのですが、コードの扱いが面倒臭くなったので、gemini-cliを使うことにしました。コーディングエージェントの類は色々ありますが、どれも凄く違うわけでもないですし、「これがベスト」とか言ったところで3日もすればまた違うことになったりしていますから、「そこにある」という単純な理由で選びました。

性能評価して選択したわけではありませんが、なかなか良好です。

gemini-cli以前

元々、ChatGPTを使ってコードは書いていました。

とは言え、ChatGPTは直接ローカルのファイルを見たりいじったりしてくれるわけではないので、その間のコピペは自分でやらなければなりません。短いコード片の時はこれでいいですし、これで結構色々できます。 Huishiはそうやって開発したものです。

何よりいいのは、「実質無料」だということですねｗもちろんChatGPTは課金して使ってるわけですが、普通のチャットとしてのバイブコーディングですから、追加課金は発生しません。会話もしっかり自分で制御できますから、余分な処理依頼もありません。

とは言え、コピペの回数が増えたり、プロジェクトファイルの扱いが増えたりすると、だんだん面倒臭くなります。ソースファイル数が増えて来ると、全部のファイルが置けませんし、ローカルで編集すると都度アップロードしたりで、かなり面倒臭くなりました。

gemini-cli登場

しばらく前に、gemini-cliが登場しました。

それ以前にも様々なコーディングエージェントがありましたが、あまりに多過ぎて、さらにそれぞれが一長一短で、しかもベストが3日も持たない… ということで、手を出し辛い状況でした。こういった時はアーリーアダプタ以外は「見」でいいということにしているので、世の中の方向性がある程度決まった頃に使えばいいや、ChatGPTもそれなりに仕事してくれてるし… ということで「見」を決めこんでました。

その中で、gemini-cliはオープンソースだしJavaScriptで書いてあるっぽいし、そもそもGoogleだしってことで、「とりあえず入れてみる」ということで入れてみました。

そして、最初の評価として「Goで書かれているCasaOSのサーバをJavaScriptで書き換える」というタスクをさせてみました。これはそのちょっと前くらいに、ChatGPTが「そんなのチョロいぜ、お前がやってもすぐできるぜ」みたいなことを言っていたので、「もしかして」と思ってgemini-cliにやらせてみたわけです。

この辺のことは、

AI利用によって上がった作業効率の使い道

にも書いています。

最終的なコードをテストするところまでは行きませんでしたが、割とあっさり書き換えまではやってくれました。途中「やって」と書くのが面倒臭かったですけど。

やれたのはいいんですが、色々気になるところがあって採用するには至りませんでした。

社長(mayumi)の評価

私の知らない間に社長がgemin-cliを使うようになっていました。

詳細はいずれ彼女が書くんだろうなと思いますが、結構いい感じでやっていて、それまで彼女もChatGPTの助けでCassetteOSを書いていたのですが、いつの間にかgemini-cliを使うようになったみたいです。

感想を聞いてみたら結構いい感じっぽくて、当初は無課金でやっていたのをGoogle Oneを契約して使うようになってました。彼女としてはGoogle AI Proで十分使えるということでした。

彼女が便利に使っているなら使わない手はないなと思って、Hieronymusの開発に使ってみることにしました。

gemini-cliを使ってみる

gemini-cliはGEMINI.mdで動作の調整ができたり、プロジェクトの途中で投入してもコード調査して対応してくれるということがわかったので、Hieronymusの開発で使ってみることにしました。

私も当初は無課金で使い始めたのですが、割と一瞬でquotaを越えてしまいました。

元々GeminiのAPIはHuishiの開発で使っていました。これも当初はGoogle AI Studio経由の無課金ユーザだったのですが、quotaにひっかかるのがすぐだったので、かなり初期にGoogle Cloudで課金ユーザとなりました。とは言え、Huishiで使う程度だとまるっきり使ってない感じで、先月の使用料は1円とかでした。その前の月は8円くらい。チャットシステムのデバッグやテストはその程度のものなのでしょう。

そこで完全になめプして、Google CloudのAPIキーで使ってみたら、2日で1000円越えになってしまい衝撃を受けます。 Google Cloudでやれば青天井課金になるとは言えquotaを意識する必要もないので快適ではあるのですが、私の使い方だと1000円/日を軽く越えそうなので、私もGoogle Oneに入ることにしました。

gemini-cliを使ってみての感想

効果は絶大です。

やってもらった作業は、

画面遷移関係の修正
帳票周辺の潜在的バグの調査と修正
「プロジェクト」機能の追加

です。

それぞれについて詳しく書いて行きます。

画面遷移関係の修正

Hieronymusは元々MPAだったのですが、途中でSPAにしました。この時によくわかってなかったこともあって、ルータはかなりいい加減なことをして力技でやっていました。

これが結構いろんな厄介の元であったので、やっぱりルータを使う方がいいなと思いルータを使うように書き換えることにしました。ルータは色々迷ったのですが、今はSvelteが4から5になる過渡期だということや(Hieronymusは4を使っています)、ルータそのものはそんなに難しいものではないので、ほとんどのルータが

Svelte4前提のものはSvelte5に全く対応していない
Svelte4のものは開発が止まっているものが多い(てゆーかルータは基本機能以外に追加に何かする必要があるものではない)
Svelte4前提のものはSvelte5に対応する気配がない
Svelte5前提のものはSvelte4では使えない

等々の惨状だったので、自分で書くことにしました。やってることは他のルータと同じことです。ルータについては特にここで書く必要もないので割愛します。

そこで「力技」の部分をルータを使うように書き換えるわけですが、単純作業とは言え結構面倒臭いです。人間、面倒臭い作業をすると、たいてい凡ミスをします。

また、力技でやってしまっていますから、あちこちに潜在バグ顕在バグが存在しているので、これらを片付ける必要があります。その他にも画面遷移や状態管理に起因するバグや懸念点が結構あります。

そこでgemini-cliを使って書き換えることにしました。

GEMINI.mdに作業内容や留意点、実装のヒント等を書いておいて、step by stepで作業依頼をします。実際にはなぜか途中で暴走(？)を始めて、step by stepのはずが最後まで一気にやってしまったりしたわけですが。

途中、いくつかの追加の指示をしたり質問に答えたりはしますし、テストは手動でしたが、作業自体はほぼ自動的に片付けてくれました。また、この辺りにあった潜在バグ等についても懸念を伝えるだけで解決してくれました。その結果この辺の懸念点はほぼ解消し、またバグを発見してもissueを与えるだけで修正してくれる程度にはなっています。

実はこの修正作業、テストや潜在バグの検出や修正も含めて1人月くらいかかるだろうと予測していました。スケジュールもそういったことで立てていました。

ところが、gemini-cliを使い始めたのが10月1日で、修正が完了したのが10月2日です。つまり、1人月分の作業をたった1日で終わらせたということです。なので、私はまるっと1ヶ月空いてしまいました。まぁ予定になかったことをすればいいだけなんですけどね。

もちろんいかにAIがやったものとは言えバグが皆無ということはないでしょう。しかし、仮にバグを発見してもissueを与えるだけで修正してくれるというメドが立っているわけですから、この工数削減は絶大です。うまくフローを作ってやれば、ほぼ無人でメンテナンスができるのではないかと期待してしまいます。貧乏OSS開発には持って来いです。

帳票周辺の潜在的バグの調査と修正

決算は無事終わりましたが、その過程で税理士には様々な計算上の問題を指摘されました。前回やった決算がVer 1.0系で、それから後に大量の修正や追加を行ってVer 2.0となりました。また、今回は過去の蓄積ではなくて新規に全てがスタートですから、潜在的な問題だったものがかなり顕在化しています。前のエントリはその辺のことを書いています。

それらの問題は当然ながら都度修正して行くわけですが、そういったことが多数あると「元々品質が低いのではないか？」という懸念を持ちます。ごく一般論として、潜在的問題(バグ)の数は顕在化した問題(バグ)の数に比例します。

実のところ私は会計は素人で、わかっているのは「伝票の書き方と自社の会計」であって、それ以上のことはよくわかりません。「自社の会計」については20年くらいやっているわけですから、自社で扱う科目がどう集計されるとか、B/SやPLは何であるか程度はわかります。とは言え、「総論としての会計」や「一般論としての会計」がわかっているかと言われれば、実のところよくわかってないとゆー自覚があります。もしかしたら本当はわかっていて、自分ではそれがわからないのかも知れません。つまり、それくらいわかっていません。ですから、そういった辺りには「誤解に基く間違い」がないとは言い切れません。

そんなこともあって、まずはgemini-cliに「レビュー」を依頼します。つまり、「今回の決算は間違いはなくしたけれど、将来や条件が変わった時に間違わないか」ということについての調査を依頼するわけです。

細かいことは割愛しますが、特に大きな問題はありませんでした。と同時に、一度も使ったことのない決算用科目(こういったのがあるから「わかってない」と思うわけです)の辺りに潜在バグがあったことがわかり修正できました。

途中色々ありましたが、改訂前のコード(Ver 2.0.4)と同じ結果が出ることを確認し、Ver 2.0.5としてリリースしました。つまり、Ver 2.0.5の何割かはgemini-cliの手によるものです。

この節の最初に、「会計は素人で」ということを書いてます。それゆえに「Hieronymusの収益がそこそこになったら、この世界の専門家を雇用する必要がある」と思っていました。やはり「専門家」が欲しいですからね。

しかし、gemini-cliが潜在的な問題を検出したり、Issueを投げるだけで修正してくれるのを見ていると、IssueやTODOをちゃんと書けさえすれば、特に「専門家」がいなくてもGeminiとして専門性を持って考えてくれたり修正してくれたりするということがわかりました。 GeminiはLLMですから、「世の中の常識」を大量に学習しているわけですからね。

つまり、当面は特に専門家が不在であっても、正しい開発ができるということです。ある意味「コンサル付きプログラマ」がいるようなものです。これもまた威力絶大です。

「プロジェクト」機能の追加

無事第一期が終わりましたので、公庫に行こうという話になりました。

そこで出す資料に「売上と経費の推移と予測」があります。要するに「今までこんな感じでした。将来はこうなります(します)」という情報ですね。

以前だと、会計データを見つつExcelで書いていたのですが、この作業は「推移表からの機械的なコピペ」が作業の大部分ですから、自動でできないかと考えました。会計データには「全て」があるわけですから、集計するだけですね。

ただ、そのままだとうまく集計できませんので、伝票の明細単位でどこに集計するかという情報を入れてやる必要があります。

そこで「プロジェクト」という単位を作り、プロジェクト単位で集計することを考えます。この「プロジェクト」は文字通りプロジェクトという意味として、たとえば製品毎とか事業毎に会計情報をラベリングするのに使います。将来的にはプロジェクト単位の経費精算とかできたらいいですね。

ここからは「新規」ですからまずはgemini-cliとチャットをして、どうデータを持たせるか相談をします。

私はこの「プロジェクト」の情報は伝票単位の方が面倒がないですし扱いやすいと思っていたのですが、gemini-cliは「世の中のたいていの会計システムは明細毎に持ってるよ」という話をして来るので、明細単位にその情報をつけることにしました。

ここでありがたいのは、gemini-cliが「世の中のたいていの会計システム」の話をしてくれたことです。私は「独特なシステム」を作りたいわけではなくて、「世間の常識」に合ったシステムを作りたいわけなので、こういった情報をくれるのはとてもありがたいです。さすがは「コンサル付きプログラマ」です。

そして今回私は「プロジェクト」機能については自分では1行もコーディングしないという目標を立てました。つまり、指示は出しても実装はgemini-cliに任せるということです。

現在のところ、gemini-cliが取れなかったバグを修正するためのヒントを出すためにコードを読むとか、「プロジェクトの情報は他の画面にも出てると嬉しいな」と思って既存画面に追加したりということはやっていますが、プロジェクト機能の本体のコーディングに関しては私は1行も書いていません。

これで面白かったのは、gemini-cliも「コピペコーディング」をすることです。どういうことかと言えば、「この新規に作る画面は○○の画面に既に似たものがありますから、これをコピペして修正して作ります」と宣言してやってくれるということです。まさに自分でもやってることをgemini-cliもやるわけです。

これの都合が良いのは、コードの「調子」が他の部分と同じになってくれることですね。後から読む時にムダに頭をスイッチする必要がないのが良いです。

この部分は現在進行中です。今の感じからすると、来週頭には使えるようになっているでしょう。

効果

既にポチポチ書いていますが、得られた効果をまとめておきます。

作業が速くて正確なので工数削減効果が大
ドメインの専門性が期待できて「専門家」の雇用や外注が不要
コピペをうまく利用してくれてコーディングの質が安定
IssueやTODOを元に作業してくれて、手放し運転が可能

デメリットとしては、

待ち時間が多いし細切れなので作業が退屈
他人の出したバグの修正は上手いが自分の出したバグの修正は下手
途中で落ちたりAPI Errorとかが出てイラっとする
落ちるとやっていた作業を忘れてしまうので、再開が面倒だしトークンを消費する

あたりでしょうか。

その他デメリットとして挙げられそうなことでは、Google Oneを使う限りquotaにひっかかります。

それも当初イラっとしたり、途中で認証を切り替えたり(Google CloudのAPIキーを使います)していましたが、gemini-cliは大きな作業が完了すると「これで本日の作業は終わりたいと思います」とか言って来るので、「それもそうだな」と思ってそこで作業を終わらせています。

どうせ人間がやるより作業は速く進んでいるわけなので、「トークン使い切ったら作業の終わり」という判断は悪いことではないでしょう。仕事はコーディングだけじゃありませんし、「今日の仕事は終わった」ってことにして帰ってしまっても誰も「困り」はしません(怒られる人はいるかも知れませんけど)。そういった意味では「残トークン数」は「エネルギーゲージ」みたいなもんだと思ってしまえば良いと思います。

とは言え、かなり早いタイミングで「終わりたいと思います」とか言うことがあるのも事実なんで、そんな時は「甘えんじゃねー」と気合い入れる必要はあります。

新人教育とゆーか、付き合い方

弊社にとっては、gemin-cliは 今月入社して来たばかりの「新人」 です。潜在能力が高く地頭も良く素直ですが、やっぱり「新人」に過ぎません。

そして、少なくとも私がgemini-cliを使う限りでは「自動コーディング」と言うよりは「ペアプロ」です。やってることが完全にAIとのペアプロです。

そうしてみると、バイブコーディングは

デキる新人とのペアプロ

と思ってやっているのが一番平和なのかも知れません。会話の内容も全くそんな感じです。

潜在能力が高いとは言え「新人」なので、案外間抜けてます。また打たれ弱いせいか、割とすぐ音を上げます。

具体的には、

自分の勘違いによる間違いがうまく修正できず、フレームワークや環境に問題があるから自分ではどうしようもないと言って諦めてしまう

のです。まさに「新人しぐさ」ですね。前の節の「早く帰りたがる」のもそんな感じ。ビシビシしつける必要があります。

さて、GEMINI.mdはgemini-cliにとっては「長期記憶」として機能します。実装の細かいところは別にして、これはプロンプトの一部となります。ですから、私は「教育」したことを

肝に命じておけ(@GEMINI.mdに記録しとけ)

と指示します。

そして、作業の区切りがいい時に早めに(今日使えるトークンが残っている時に)作業を終わらせて、「反省会」をします。そこで色々な話をして、上の指示を与えます。その結果、今のGEMINI.mdには、

### 0. 心構え：「`malloc`にバグなし」

不可解なバグに遭遇した際、安易にライブラリ、フレームワーク、ビルドツールといった「外部環境」のせいにしないこと。問題は常に、自分自身のコードのロジック、前提条件の誤り、あるいは仕様の理解不足にあると仮定して、デバッグに臨む。**「環境のせい」という思考停止は、100%自分の凡ミスを見逃している兆候と心得る。**

なんてことが書いてあります。もちろん私が直接書いたわけではなく、gemini-cliに自分で書かせました。

他の人の作ったGEMINI.mdの例を見ても、結構「精神論」みたいなことが書かれていますし、ChatGPTにエージェント用のプロンプトの作り方を聞いた時も、「システムプロンプトに精神論的なことを書くのは有効」という話でしたので、意味のあることでしょう。

今のgemini-cliは「ジュニア」でしかないですが、そのうち育ってくれたらいいですね。