Gemini Code Assist Standardの使い方

Gemini Code Assist StandardをGemini CLIで使おうとしてハマったのでメモ。

Gemini Code Assist Standardを使う場合、Gemini3を有効にするにはCode Assistのpre-GAを有効にする必要があるのだが、通常の方法ではGCPのプロジェクトを指定するのではなくユーザー単位でログインするので、そもそもpre-GAの設定が適用できない。

いつものごとくWeb上を彷徨っていると、どうもGemini CLIにもGCPのプロジェクトIDを設定できる項目があるらしい。

mkdir -p ~/.gemini
cat >> ~/.gemini/.env <<'EOF'
GOOGLE_CLOUD_PROJECT="your-project-id"
EOF

これでプロジェクトIDを設定しておけば、pre-GAでしか使えないGemini3も使えるようになる。

Gemini Code Assist Standardだけど、この他にもどうもよくわからない点があって、例えばライセンスを割り当ててもLicense last usedが更新されないという謎現象もある。これについては、ライセンス割り当て時と割当解除時で明らかに動作やクオータが異なるので、多分ライセンス自体は当たっていると思うんだが、正直よくわからない。

正直、Gemini Code Assist Standard難しすぎるだろ。ここまでたどり着くまでに２日くらい浪費したし、若干無駄に金を払ってしまった。

書いといて何だが、Gemini Code Assist Standardを使うのはあんまりおすすめしない。クオータ自身はまあそれなりにあるので良いが、それでもGemini3 Proのクオータはちょっと少ない気がする。

教会と教会員の価値観

教会員制度への疑問と教会移籍の背景

最近、昔から通っていた福音派の教会ではなく、バプテスト系の教会に通っている。こうなった理由は色々あるけれども、自分の中で教会員というものの価値を限りなく損ねてしまうには十分な経験だった。

そもそも教会員というものに馴染みのない方がほとんどだと思うが、一般的に、教会員というのは、特定の教会のメンバーという意味合いがある。ふつう、イエス・キリストを信じて洗礼を受けると、ほぼ自動的にその教会の教会員となり、またほぼ自動的に月定献金なるものが始まるのである。

月定献金：建前と実態の乖離

この月定献金、名前からして会費のようなものであり、実際この献金で教会は運用されているのだが、福音派の教会は頑なにこれを否定する。献金はあくまで神への感謝の表し方であり、決して牧師の謝儀とか教会の運営のために集めているのではないと言い張る。

聖書にみる十分の一献金の本来の目的

ここで聖書を見てみよう。

'主はアロンに言われた。「あなたはイスラエルの人々の土地のうちに嗣業の土地を持ってはならない。彼らの間にあなたの割り当てはない。わたしが、イスラエルの人々の中であなたの受けるべき割り当てであり、嗣業である。 見よ、わたしは、イスラエルでささげられるすべての十分の一をレビの子らの嗣業として与える。これは、彼らが臨在の幕屋の作業をする報酬である。 '

民数記 18:20-21 https://www.bible.com/ja/bible/1819/NUM.18.20-21

つまり、レビ人は嗣業の土地を持つ代わりに、神を受けるべき割当とし、捧げ物の10分の1をレビ人らに与えることが神によって命令されているということだ。「彼らが臨在の幕屋の作業をする報酬」と明示している点に着目したい。

旧約聖書では一貫して、10分の1献金はレビ人の為のものと明記している。それは彼らが生活するための糧であり、神の働きに専念するための保険なのである。

現代教会における献金の使途への疑問

現代のキリスト教会の一部は、この明らか事実を、なんだかよくわからないが神のためと言って有耶無耶にしている。有耶無耶にしている割には、月定献金として集められた献金を、まるでフリーローンのように自由な用途に用いるのである。

まあ批判的な話はこれくらいにしておくが、つまり月定献金を主な収入源としているにもかかわらず、その事実を頑なに認めようとしないのである。これが二律背反で無くて何なのだろうか。宗教団体は、そんな道理が通らないような集団でいいはずがない。

教会からの疎外と、新たな信仰の道

さて、こんな思いを持っていると、当然キリスト教会からよく思われるはずがなく、めでたく爪弾きにされたのが今の自分である。

話が前後しすぎて申し訳ないが、今我が家では、新しく通い始めたバプテスト系の教会に転会するかどうかという決断をしようとしている。個人的には、教会籍という制度自体にあまり良い思いを抱いていないのだが、確かに現代で信仰生活を送ろうと思うと、教会籍というのはある程度必要になってくることは否めない。

次の土曜日に、転会についてバプテストの教会の牧師と話すのだが、果たして上記のような話をして、それでも快くというか、受け入れてもらえるのかは謎である。

どうなるか様子を見てみたい。

AIの可能性を模索した一年

ここ1年くらいだろうか。AIの可能性を模索するために、ありとあらゆるAIツールやサービスを試してきた。最初の半年くらいは、AIができることを見極めるために。その後の半年くらいは、AIに全てを賭ける価値があるか、というかAIにどの程度投資すべきかを見極めてきた一年だったと思う。

世の中的にも、ここ1年でAIエージェントに関する議論や実装が一気に増えてきたと思う。いわゆるリーズニングモデルが一般的になり、AIがそれなりに思考を始めたように見える機会が増えてくるに従って、今度こそAIに何でもかんでも任せられるのではないかという幻想を抱くような、そんな一年だったのかもしれない。

AIの能力と「目的」の欠如

これは、もしかしたら近い将来幻想でなくなるかもしれない。今でも十分動くコードを生成できるし、理路整然とした文章を書くこともできる。今までAIが生成してきた文章を色々と読んだり、このブログでも試験的にAI生成の記事を載せてみたりもしたが、まあ出来は悪くない。

しかし、絶望的に足りていない点が一つある。それは成果物の目的だ。AIの生成物は、たとえ人が目的を持って指示した結果の生成物であっても、最終的な成果物に目的が透けて見えてこない。表面上は良い文章、良いコードでも、なぜそれを書くのか、なぜその処理を入れるのかという本質的な問いに対する回答が含まれていない。AIの性質上当たり前ではあるが、確率論的に確からしいものをつなぎ合わせたものでしかないのだ。

AIへの過信が生む課題

それではAIで何かをすることに反対かというと、そんなつもりはまったくない。自分が危惧しているのは、AIに任せすぎた結果生成されてしまった、目的はないが量だけは大量にある生成物を、人間がレビューするという構造を危惧している。

コーディングエージェントの例

近年の流行りは、Claude CodeなどのCLIで動作するコーディングエージェントであるが、頭のいいモデルほど、放置していると途方もない量のコードを短期間で生成してしまう。例えばテストコードを書いてほしい旨を伝えた場合、自分の中では簡単なスモークテストを書いてほしいのに、AIエージェントは気を利かせて単体テスト・ユニットテスト・E2Eテスト全部を書こうとする。

100歩譲って、これらのテストがすべて正確に書ければ良いのだが、たいてい一回で動くコードを生成することができず、自分で修正してはエラーに対処するという負のループを繰り返し始める。また、もしちゃんと動くコードが書けたとしても、テストコード自体の品質はあまり良くなく、肝心な部分をテストしていなかったりする。

もちろん、こういった問題は過渡期のものであって、将来的には人間もびっくりするようなテストケースを一瞬で生成してくれるのかもしれないが、それにしても人間がそのテストをレビューする必要が出てくる。プルリクエストの修正箇所が数千行もあるとして、それをレビューするのにどのくらいかかるというのか。

もちろん、CoderabbitのようなAIレビューツールを使えば、ある程度のレビュー工数は減るものの、そもそもPRの目的を理解する必要がある事は変わらない。何も見ずにひたすらプルリクをマージするおじさんになってもいいが、それなら誰が品質を担保するのか。

エンジニアの品質責任

まあこの発想自体が、もう古いものになりつつあるのかもしれないが、少なくともエンジニアを名乗るような人間の場合、成果物の品質には責任を持つべきである。

自分は製造業の人間なので、あまりソフトウェアの品質には詳しくないが、AIエージェントに書かせたコードを鵜呑みにする行為は、製造業で言う、今までと同じ条件で製造しているから品質は大丈夫だろうというのと大差ないのではと思う。テストコードを書かない、あるいはテストコードさえAIに投げるという行為は、すべてをAI任せにする手法であり、これまでもこれからも適切ではないと思う。

「使い捨てアプリ」の落とし穴

品質のことについて、どうせ使い捨てアプリだからあまり必要ではないと言われるかもしれないが、案外その使い捨てのつもりで作ったアプリが10年くらい使われるという経験は、実務をやったことある人間ならわかると思う。少なくとも、僕はそういった適当に作った技術負債の塊を、あとから必死にメンテするという経験をいくつもしてきた。

成果物のライフサイクルで考える

AIによる成果物の是非について語る際、どうしても目先のことというか、成果物の存在そのものの是非について語られがちであるけども、本来はその成果物のライフサイクルに視点を当てて語るべきだと思う。もしそれが、本当に一度限りのコードで、GitHubにもコミットせずにローカルですぐ消すようなコードなら、あるいはAIのポン出しでも構わないだろう。ただ、もしその成果物を少しでもメンテするとか、今後機能追加とかバグ修正を行う前提で運用するなら、やはり目的を伝えてあとはAIポン出しというのはやめておいたほうが無難だ。

今後のAIとの向き合い方と技術的負債

自分の周りには、こうやってポン出ししたアプリケーションがいくつかあるのだけれども、果たして今後どうやって処理していこうか。技術負債をどう返済していくかということを考えている。非常に悩ましい話だ。

少なくとも、今後はAIポン出しとか、AIに頼り切った文章作成やシステム設計はやらないと思う。自分のものにならないし、その負債を返済するのはほかでもない自分自身なのだから。

バイブコーディングやめた

ここ数ヶ月、いわゆるバイブコーディングにハマってたのだけれども、バイブコーディングは止めることにした。バイブコーディングって確かになんかどんどん出来上がっていってる気がするんだけど、いざソースコードを読んでみると、一つのファイルに数千行のメソッドが書いてあったり、コメント無しのコードが山ほど出来上がったりでコードの品質が非常に悪かった。

あと、なんか動きそうで動かない機能とか、そもそもなんで動いているのかよくわからんシステムなど、明らかな技術負債を量産していることに気がついてしまったのだ。

すでに作ってしまったシステムはまあ仕方がないとして、これから書くコードとか、今から追加修正する機能に関連するコードはちゃんと機能を理解しつつPRをマージしようと思った。

まあ、流石に昔のググってコピペと自力でコード作成というのはもうやらないと思うけど、例えば肝心なロジックの場合は一部手動で書くとか、メソッドだけ生成してそれを組み合わせるのは自分でやるとか、まあ少なくとも自分が何をやっているのかを分かったうえでプロダクトを作るというのは、このAI全盛期時代でも変わらないんだなと再認識した。当たり前の話だが。

当然、このやり方でやるとバイブコーディングと比べて進捗は遅くなるが、生産性自体は上がっているのではないかと思う。無意味にAIのトークンを浪費することもないし、コードを読めばわかることを延々とAIに質問するような時間も削減できる。

これもまあ今更な話だが、AIに「〜やって」と投げている時点で、そのタスクというのはあまりうまくいかないか、うまくいっても再現性がないのだと思う。生成AIが出てきたといえども、やはりコンピュータというのは単純作業や、単純ではないけど定型的な面倒な作業を自動化するためのものであり、思考を放棄して丸投げする対象ではない。ついついAIのすごさに気を取られてここを忘れてしまいがちだが、時間と金の浪費なので、本質を見失わないようにしたい。

もう今年終わるじゃん

一年のまとめをしようかなと思っていたところ、もう一年が終わろうとしている。

まあまとめはいいとしても、一年の最後にちょっと記事は書いておきたい気がする。今年も色々とあったが、今年はAI関連の記事が多かったように思う。各所で語られているように、今年はAIエージェント元年というか、コーディングエージェント元年だったように思う。

いわゆるClaude Codeに代表される、コードを勝手に書いてくれるエージェントの普及により、コーディング自体の速度は劇的に加速したと思う。少なくとも、自分がコードを書く何倍もの速度と、何倍もの信頼度でソースコードを生成しまくる。数年前にこんな未来が来ることを誰が想像しただろうか。

これで晴れてソフトウェアエンジニアが不要になるかというと、まあそんなことはない。この手のプログラマ不要論というのは、昔から定期的に出ては消えを繰り返している理論であり、今に始まったことではない。

ただ、プログラミングに対するハードルはかなり下がったと思う。昔は、DOS窓に何かを表示するC言語を学校で習っても、これからどうやったらWindowsアプリとかゲームが作れるのかさっぱり分からなかったが、今ではAIにやらせれば、少なくともその方法はわかる。いい時代になったものだ。

ここまで考えてふと思ったが、もしかしたら今度はその先をどうすればいいか分からないという、また別の問題が出てくるかもしれない。やはり何かを学習するというのは、AIがあろうが無かろうがそれなりのコストがかかるのだろう。

AIの話はこれくらいにして、私生活の話に入ろう。私生活では、教会にもう一度行くことにした事はかなり大きな出来事だろう。もう教会はいいかなと思っていたが、もう一度行ってみようと思えたのは素直に感謝なことだと思う。やっぱり、クリスチャン生活と教会というのは切っても切れない存在であるということは否定できない。

あとは車を買ったこととか、会社で昇進したこととか色々あるけど、もう眠いのでこの辺で書き終わることとする。

来年はどんな年になるだろうかと期待しながら、明日の元旦礼拝に備えよう。

タイヤ擦った

さて少し前に新車を買ったのだが、今日早速ホイール部分を擦ってしまった。

我が家には駐車場が２つあるのだが、片方の駐車場はもう片方の駐車場より若干狭く、普段は使っていない。今日は諸々の事情でこちらの駐車場を使ったのがまずかった。車庫出しの際に、ガリッとホイールをやってしまった。

幸いボディーには傷がなかったので良かった。スタッドレスタイヤなので短期間しか履かないし、タイヤ自体何回か交換するので、まあこのホイールもずっと使うわけではない。

そもそも車自体にこだわりが大してないので、このことも数日後にはどうでも良くなってると思う。スマホの傷と同じ話だ。

とはいえちょっとテンションが下がってしまったので、気分転換にブログに残しておこうと思う。

WINTER WISH

なぜかはわからないが、ふとWINTER WISHを思い出した。

米倉千尋さんの曲で、ラブひなのクリスマススペシャルの挿入歌だった。このクリスマススペシャル、個人的にかなり思い入れがある曲なのだ。

というか、このクリスマススペシャルの曲は豪華で、やまとなでしこ（田村ゆかり・堀江由衣）の「恋の天使 舞い降りて」も挿入歌として使われている。確かこの挿入歌はクリスマスまっただ中の街中で流れている曲だったと思う。

WINTER WISHは、最後になると景太郎が街で会うシーンで流れてたんだったかな。

なんでこんなに覚えてるかというと、昔に数年間くらい、毎年クリスマスにこのクリスマススペシャルを見るというのが慣習となっていた時代があったからだ。あれは確か、高専3年生くらいの話だったか。

当時は恋愛シミュレーションや恋愛アニメにハマっていた時期で、ラブひなのようなアニメは自分にとってどストライクのアニメだったわけです。今はあまり興味がないジャンルではあるが。

そう思うと、自分の好みというのは結構変わるんだなと思った。そんな、なんでもない話