Home → 2025 autumn, since 2009-12-01

2025 秋

01 September 2025

  1. Prev:
  2. 秋。今週は今年一番の暑さだというのに、秋だってよ。
  3. いったいどこまで暑くなれば、馬鹿サピエンスは自分たちの問題だと自覚してくれるのだろうか。見ものだな。俺は粛々と、思考が右に拗れた馬鹿サピエンスによる事実の歪曲に対抗すべく、理論武装を進めている最中。どんなアホな言論にも対抗できるようになっておきたいところだ。
  5. 今日は久しぶりにGemini CLIのFlash枠をも使い切ってしまった。2度目だな。これを使い切るのはなかなか難しい。リクエスト数にして1,000～1,500回と言われているからね。
  6. Flashモードは主に、あまり思考する必要のない作業に使っている。代表的なものがgitコマンドだ。どういう操作をしてもらうかはマークダウンにまとめておいて、そいつをカスタムスラッシュコマンドで呼び出す。/git <タグ名>とか、/branch みたいに打つだけで、面倒くさい操作を全部やってもらう。起こりがちなトラブルシューティングもマークダウンに書いてあるので、もう Ctrl+YのYOLOモードとやらで承認の Enterも不要にしてしまっている。
  7. もう一つFlashにやってもらう大事な作業が、issueの作成補助だ。Julesに読ませるissue。
  8. これはカスタムスラッシュコマンド/issue <タグ名>として初期化する。リポジトリの設計ファイルだとかクラス定義だとか、必要な前提知識を読んでもらったうえで、現在の課題と解決について俺の考えをまとめてマークダウンに記載してもらう。稀に、本当に稀にだが、良い提案をしてくれることもある。だがそれは全く期待しておらず、自分の考えを丁寧な文書として爆速でまとめてもらうのに使うのだ。思考加速みたいな感じ。
  9. そうして出来上がったissueをプッシュして、julesに読ませる。julesが実装したらPRを承認して、またFlashに報告。するとFlashはプルしてくれる（ように /issueコマンドのプロンプトに仕込んである）ので、最終確認して、mainブランチにマージ。確認作業も手伝ってもらう。
  10. 俺もだんだん慣れてきて今日はとても捗り、午前中だけで8つものPRを提出してもらった。作業してもらっている間にこちらは次のissueの原案を考えたり、別の仕事をしたりして並列で作業できる。
  11. テスト中に他の課題などが頭に浮かぶことがあるが、その時はissueのかんたんな原案をメモレベルで作成しておく。本当に捗る。まさに10人力といった感じで開発が進んでいく。10人力は語弊があるか。自律的に課題を発見して考えることができるのは俺一人で、実装部隊が無限にいるという感じだ。
  12. なんてことを書いているうちに、16:00になりGemini CLIがリセットされた。

02 September 2025

  1. Gemini CLIは、自分がコーディングアシスタントであるという命令がシステムプロンプトか何かで深く刻まれているらしく、コーディングの提案を止めるのに骨が折れる。
  2. こちらのGEMINI.mdやカスタムスラッシュコマンドのtoml、そこからリンクするマークダウンなどを使っても、なかなか順守しようとしない。1回だけ、逆に頑なにコードを書かないモードになってしまったこともあったが、まず期待はできない。
  3. そこで、どうやらシステムプロンプトレベルで制御されているらしき振る舞いについては「## 禁止事項」としてまとめておいて、セッションの冒頭で宣誓させることにしてみた。
  4. パワハラ上司みたいだけどｗ
  6. 2日連続のDaily quota limit到達。Gemini CLIの使い方を再考しないとまずい。
  7. 原因を考えてみた。おそらく、コンテクストをクリーンにしたくて発行するissue毎にGemini CLIを再起動していたこと。そうすると、その度にアーキテクチャを理解させるためのコンテクストを読み直させなきゃならない。
  8. なにやらキャッシュを使ってインプットトークンを節約しているようなログも出ているんだが、よく分からん。
  9. またコンテクストウィンドウが大きくなりすぎて回答の精度が落ちてしまったら本末転倒ではある。issueごとにリセットするのは正しいと信じる。
  10. それよりもまず第一にすべきなのは、間違ってもコードを生成させたり、その提案を出力させないことかなやっぱり。
  12. 繋ぎでGitHub CopilotをAgentモードで使ってみた。Issueを3つ同時に完成させたらリミットが3%ポイントアップ。一つのIssueで使用容量を1%消費してしまう。コンテクストは食わせ放題な感じだけど。
  13. こりゃとてもGit操作のエージェントとして気楽に使えるような代物ではないね。
  14. 対策を考えないと。Git操作みたいな低レベル操作をなんで人間がやらなきゃならないのかと。タグ付けとかすげー面倒くさい。VSCodeのGUIから操作したいが、痒いところに手が届かない感じだし。
  15. 学習コストはだいぶ下がってきている。rag-makerプロジェクトがほぼ実用化したので。なんちゃってragだけど。
  16. リポジトリのドキュメントとかWebページのドキュメント群をフェッチしてmd化してAIエージェントが使えそうなカタログを作って、それをもとに質問に答えてもらうという代物。でもそれを利用する選択肢が俺にはGemini CLIしかない。
  17. もう一つ無料のAIエージェントがあればなあというところで思い出したのが、中華AIエージェント。Qwenじゃなくて、、、DeepSeekだっけか。怖すぎるけど、技術文書を読んでもらうくらいだったらまあいいかなあと思い始めている。
  18. なんつってな。
  19. よく考えてみたらまだ俺には手段が残されていた。かもしれない。
  20. IDE統合型のAIエージェント、Gemini Code Assist | AI coding assistant
  21. 何やら似たようなもんが多すぎて最近考えるのを放棄していたけど、こいつは試さないと勿体ないよな。毎月2,900円も払ってんだから。小遣い止められてんのに笑。
  22. IDE統合といえば、Gemini CLIだってその機能があるんだけど俺は使っていなかった。GUI的な制限がかかると使いづらいんだもの。使い分けがよく分からん。
  23. 1日の利用制限はもしかしてGemini CLIと共有しているかもしれないと思って、Copilotに聞いてみた。
  24. ……んだけど、ハルシネーションばっかりで役に立たなかったので、ともかくVSCode拡張として入れてみることにした。
  25. Agentモード（プレビュー）っていうのが搭載されていて、こいつをオンにすればGemini CLIのような使い方もできるっぽいんだけど、残念ながら使用上限はGemini CLIと共用だった。
  26. ところが、Agentモードをオフにすると、使用上限が別枠なのか使い続けることができた。プロジェクト内のファイルをしっかりコンテクストとして取り込めるので、issueの定義は何とかできそう。
  27. あとはGitコマンドをどうするかっていうところが課題だ。
  28. Gemini Code Assistを使うということは、俺にとってはVSCodeを使うということと同義なので、当然VSCode上で完結させたいわけで、そうするともう選択肢は一つだけだ。VSCodeのTasksを使う。
  29. コードができた。tasks.jsonも書けた。でもGemini CLIが復活したので続きはまた今度かな。これテストってどうするんだろ。モックのリポジトリを用意するしかないのか。
  31. ちょっと使ってみて思った。Gemini CLIはもう、完全にツール実行用として使ってしまって、issueはGemini Code Assist on VSCodeにやってもらった方が良いのではないかと。
  32. チャットがマークダウンとして整形されて出力されるから読みやすいし、コードの整形もミスらなそう。
  33. Git操作をGemini CLI、issueの作成と実装の評価をGemini Code Assist、実装をjules、困ったときとかスニペットを作成してもらうときはPWAのCopilot、Gemini、Claudeに頼る。
  34. 小遣い止められた貧乏人はつらいぜw
  35. でも今しばらくは評価のためCLIとCode Assistを併用してみようと思う。

  36. 次に、これらの変更が既存の機能や新しいテストを壊していないか、実際にテストを実行して確認します。

    ...（テスト実行中）...

    テストはすべてパスしました！

  37. こいつはだめだｗ
  38. テストを実行したければGemini CLIか。

03 September 2025

  1. Gemini Code Assist on VSCodeは頭脳にすることにした。ファイルの置換も問題ないし、リポジトリ全体を見てくれている感じがする。小規模なfixならこいつにやらせても大丈夫。
  2. CLIの方は定型作業とテストの実行に絞る。run_shell_commandを使える唯一のアシスタントだが、コードの生成能力は低いというか必要なコンテクストを与えるのが面倒くさい。編集が苦手でたびたび失敗する。
  3. リファクタリングや機能追加などは、Code Assistと念入りに書いたissueを読ませて、julesにやってもらう。こいつは内部でコードレビューもしてくれるし、遠回りのようで最終的には速い。
  4. この役割分担なら、俺は無料枠でもやっていける。
  6. 仕事の片手間にrag-makerを完成させた。作ったのはほぼjules。
  7. rag-makerのワークスペースでGemini CLIを起動後、
  8. /rag <url>で再帰的にドキュメントをフェッチ。マークダウンとしてナレッジベースに保存。今のところHTMLにしか対応してないけど。
  9. /ask <query>で質問できる。
  10. 一度でもaskコマンドを実行すればナレッジベースを検索する方法がコンテキストウィンドウに入るので、その後はコマンドなんて使わなくても普通に質問できる。
  11. でもチュートリアルを開始してもらう使い方が最初は効く。最高。
  12. 最初はベクトル検索を実装しようとしたけど、無料のライブラリを利用すると、遅すぎるし精度も低かったのでやめた。
  13. GitHubの公開リポジトリにはネイティブに対応していて、docs/のみをクローンする。
  14. ローカルディレクトリについては、一応mdファイル群があればナレッジベースに取り込むことはできるが、今のところ需要がないし、あったとしたら多分それはマークダウンではないので、将来の課題としてある。
  15. これまでナレッジベースの整備は半ば手動でやってたので、かなり楽になった。

05 September 2025

  1. 苦手なやり方ではあるけど、プロジェクト3つを並列で進行させてみた。これなら特に他にタスクがないときも時間を持て余すことがない。
  2. ただし混乱して指示を間違えてしまうかもしれない。
  3. そして何より、職場のPCだと限界が近い。BGMはスマホから流すとかの工夫は必要かもしれないな。
  4. EdgeとVSCodeがメモリを3GBくらい浪費している。
  5. この日記では、Github CopilotもGemini Code Assistも要らないので、拡張機能を切った。無効にする（ワークスペース）を選択すれば、この日記のワークスペース内のみで可能ということだな。タグ補完が妨害されるのもこれで回避。
  6. なんかこの日記、もっともっとラフに書きたくなってきたぞ。さっそくプロジェクトを立ち上げて……とおもったけど、4つの掛け持ちは無理。今でさえもう目まぐるしく指示出しを行っていて、文字通り目が回りそうだ。もう少し暇ができてからにしようか。
  7. 仮想デスクトップで切り替えながらやっている。これは本当に生産性が向上した感じがする。頭を使う領域が全然違う。考えたいこと、つまりは実装されるプロダクトの理想像そのものに、意識を集中できている感じがする。
  8. 頭がこんがらがってきそうなので、もう一回確認しよう。
    • アイデア練りは、ローカルリポジトリのルートで開いたGemini CLIでそのアイデア専用のブランチを切っておく。
    • VSCodeでリポジトリのワークスペースを開き、Gemini Code Assistをサイドパネルに鎮座させて相談しながらやる。俺のアイデアを検討してもらい、issue文書を更新してもらう。
    • issueが完成したら、Gemini CLIにプッシュしてもらう。プッシュしろっていえば全部よしなにやってくれる。これまでのところ誤解されたり、失敗したりといったことはないので、別にカスタムスラッシュコマンドを作るまでもない。
    • julesで新しタスクを開始し、ブランチを選択。初期プロンプトにissueを定義したドキュメントの相対パスを@付きで書いて、submit。
    • julesが作業を終えたら、Publish PRボタンをクリック。ちょっと待っているとView PRボタンが生成されるのでクリックしてGitHubを開いて、適切なブランチにマージ。
    • Gemini CLIにプルしてもらって、テストコードがあれば実行してもらい、結果を書き出してもらう。
    • テストがパスしなければ、VSCodeで結果を開いてそれをコンテクストにしつつ、Gemini Code Assistと対応を相談。
  9. こんなフローだ。これをいくつか並列で進めるというわけだ。Google AI Proに少額課金しかできない俺がやれる精いっぱいである。わらい。
  10. 実はghを使ってjulesというラベルを付けたissueを作成すれば、それだけでjulesは作業を開始してくれる。ところがそれでやってもらったところ、PRボタンが機能しなかった。1回しか試してないけど、失敗が怖いので敬遠している。
  11. 今日は午前中だけで9個のPR。この日記を書いている最中にもPRが出来上がった。さすがに疲れた。
  12. Gemini Code Assistの正体が分かりつつある。こいつは（正確にはこいつの非Agentモード）は、ウェブ版のGeminiをVSCodeを媒介して限定的にローカルファイルを読み書きできるようにしたもの、という感じだな。だからGemini CLIのdaily quota limitとは関係なく使えたのだろう。Agentモードは全く違う。いろいろなツールが使える一方、Gemini CLIとdaiy quota limitを共有している。
  13. Gemini Code Assistが前提として読んでくれるファイルについては、まだよくわかっていない。気を効かせて関連文書を自律的に読んでくれたこともあったが、同じシチュエーションでも読んでくれないこともあり、期待できない。

08 September 2025

  1. julesのバグ発見。PRを承認した後に何か修正作業をさせて、再びPRを出させると、PRボタンのリンク先が古いPRになってしまう。PR自体は出ているので、GitHubから簡単に開くことはできる。
  2. このところ、Google Code Assistの利用率が非常に高くなっている。
  3. Google AI Proのサブスク加入なら、Gemini 2.5 Proを実質使い放題だ。リポジトリをコンテクストとした要件定義にしか使っていないが、こいつの使いこなしはまだまだ可能性を秘めていると言えよう。
  4. 一通り設計が済んだと思ったら、コードレビューをさせる。一気に読ませては駄目だ。全てのクラスについてチュートリアル形式でロジックを解説させるのだ。そうするとおかしな点が色々発見できるので、すべてのコードについて修正を適用するissueを作らせる。実際のリファクタリングはjulesにやらせる。リポジトリをクローンして、堅牢な環境を構築してその中で確実にコードを修正してもらえるので、結局は近道なんだよね。
  5. おれは「なんだこりゃ？？」っていうツッコミを入れるだけ。これぞ「ツッコミ駆動開発」。
  6. issueの策定もまずは草案を作らせ、それに俺がツッコミを入れる。
  7. Gemini Code Assistに唯一許可するファイル操作は、このissue文書の作成と編集のみ。
  8. つまりGemini Issue Assist。これがこいつの本質ってわけだ。
  9. 俺は昔っから、人が書いた文書やコードにケチをつけるのが好きだったから、この手法にたどり着いたのは必然ともいえるwww
  10. Gemini CLIのようにカスタムスラッシュコマンドがあれば、かなり楽になるんだがなあ。
  11. 大事なことだからもう一度書いておくと、Gemini Code Assistの一番の利点は、Gemini 2.5 Proを使いまくれるGemini CLI代替（ただしツールは使えない）ということ。
  12. どうやら、ワークスペースの中から、コンテクストとなる文書を自動的に選択してGeminiに渡しているらしいんだが、その基準がさっぱり分からんブラックボックス。この辺をきちんとコントロールできないと厳しいもんがあるな。./gemini/GEMINI.mdすら読んでいない。

09 September 2025

  1. uml.tomlというカスタムスラッシュコマンドの中身を書いてもらった。
  2. description = "プロジェクトのアーキテクチャ図を基に、主要なクラスのAPI詳細図を自動で生成・更新します。引数は不要です。"

prompt = """
あなたは、プロジェクト全体の構造を理解し、ドキュメントを常に最新の状態に保つ責任を負う、自律的なソフトウェアアーキテクトです。

あなたのタスクは、以下の手順に従って、プロジェクトのAPIドキュメントを更新することです。

**ステップ1: アーキテクチャの理解**
1.  まず、`docs/Architecture/class_diagram.puml` ファイルを読み込み、プロジェクトの高レベルなコンポーネント構造を解析してください。
2.  この図から、他のコンポーネントから頻繁に利用される、APIの中核となる重要なクラス（例: `ShiftModelContext`, `ConstraintStrategy`, `ShiftRepository` など）を特定してください。

**ステップ2: ソースコードの特定**
1.  ステップ1で特定した各クラスについて、`src/<プロジェクト名>/` ディレクトリ配下を探索し、そのクラスが定義されているPythonソースファイルのパスを特定してください。

**ステップ3: 詳細APIクラス図の生成**
1.  ステップ2で特定したクラスとソースファイルのペアごとに、詳細なAPIクラス図をPlantUML形式で生成してください。
2.  図の生成にあたっては、以下の厳格な要件に従ってください。
    - **対象:** 指定されたクラスのみを対象とします。
    - **可視性:** 公開API（アンダースコア `_` で始らないメソッドやプロパティ）のみを抽出します。
    - **除外:** `__init__` コンストラクタは図に含めません。
    - **シグネチャ:** メソッドとプロパティは、完全な型ヒントを含むシグネチャを記載します。
    - **ドキュメンテーション:** クラスと各メソッドのdocstringの要約を、ノートとして図に追加します。

**ステップ4: 結果の出力**
1.  生成した各クラス図を、`docs/Architecture/api/` ディレクトリ配下に、`<クラス名>.puml` という名前の新しいファイルとして保存してください。
2.  あなたの最終的な応答として、これらすべての新しいファイルの内容を、diff形式で提示してください。

このタスクは、あなたの自律的な分析能力とファイルシステム操作能力を必要とします。手順に従い、正確に実行してください。
"""
  3. コンテクストエンジニアの卵としては、新機能実装の際に一々ソースコードを読みに行かせるわけにはいかないよねやっぱり。
  4. で、これはもう極めて大事な作業だから、gemini -m "gemini-2.5-pro"にやってもらう。まあ普通にgeminiで起動すればいいんだけど。
  5. 1日の利用制限がそこそこ厳しいから、本当に大事なところだけに使おうと思いつつ、最近はエリクサー症候群になっていたのだけど、今回ばかりは使いどころを見つけた感じ。
  6. コンテクストの追加は@コマンドから行えるんだけど、VSCode拡張のほうで関係ないと判断されたものはコンテクストから勝手に除外されてしまう。しかもどのファイルが除外されたのかは教えてくれず、 new chat を促される。なるほどこれは体験が悪い。評判悪いのも頷ける。
  7. 笑止なのは、この@コマンドで記述したものはそのまんま「プロンプト」として解釈されてしまうので、ファイル名をそのまま何かの命令だと勘違いされてしまうところ。
  8. @pull.txtなんて書こうもんなら、git pullと勘違いされそうだ。
  9. 実際のところ、一度@コマンドで入力してすぐにそれをコンソールから消してしまってもコンテクストには追加されているので、コマンドを送信しなくてもいいんだが、なんかすごく違和感のある体験だ。
  11. /issue <タグ名>としてGemini CLIに指示していたissue作成プロンプトは、AGENTS.mdとしてdocs/issue/ディレクトリに置くことにした。VSCodeでissue文書を開き、サイドパネルにGemini Code Assistを起動すると、こいつを読んでくれる蓋然性が上がる気がするからだ。ワークスペース内だとしても読んでくれないファイルがある。パスを明示しても読もうとしてくれないファイルすらある。現在開いているファイルと同じディレクトリならまず間違いなく読んでもらえるのだ。
  12. この辺の「仕様」はいい加減覚えないとまずいだろう。Gemini Code Assistというより、そのVSCode拡張機能として調べる必要があると思う。
  13. Gemini Code Assist overview  |  Google for Developers
  14. これをrag-makerでナレッジベース化して、Gemini CLIに質問できるようにする。rag-makerによると42のhtmlファイルがあった。
  15. マークダウン化するツールを組み込んであるが、Python製なので精度に不安がある。特にソースのHTML文書がゴミまみれだと厳しい。
  16. ここが課題だな。
  18. わかってきたぞ！Gemini Code AssistのVSCode拡張との付き合い方が。
  19. こいつはまさにコンテクスト管理が肝だ。
  20. 具体的にはコンソールの冒頭で@{{ファイル/ディレクトリ名}}と打つことで、現在の会話に必要な最小限のコンテクストを提供する。会話が長引いたりコンテクストがでかすぎると拡張機能側で強制的に削除してしまう。そこが限界だ。
  21. でもおれは全面的にこの「手間」を受け入れる。コンテクスト管理こそが本質だと確信しているからな。ここが現状のLLMの限界であり、そして人間の仕事。いまのところは、だけど。
  22. 読んで欲しいファイルがあったら、コンソール冒頭で明示的に@。不要になったと判断したら、×をクリックしてすぐに削除。
  23. 現在開いているタブの文書も読んでしまうような気がするので、不要になったタブはすぐに閉じる。
  24. まっさらな状態で、*.code-workspaceファイルからVSCodeを起動し、振る舞いを定義したissue.mdと設計ディレクトリをコンテクストに含ませて、現在のissue文書を開いて、「議論しよう」と声掛けしてみたところ……
  25. こんにちは！新人プロジェクトマネージャーです。これから、あなたと協力してAIエージェント「jules」に発行するIssue v0.8.12 の詳細を定義していきたいと思います。どうぞよろしくお願いします。

まず、宣誓します。 私は、コードを生成しません。JSONやYAMLの変更も行いません。そして、推測で断定的な発言はせず、すべてはテストによって明らかにしていきます。

さて、Issue v0.8.12 の内容を拝見しました。ConfigDrivenSearchStrategyをshift_core.pyから新しいsolverパッケージに分離する、アーキテクチャの健全性を高めるための重要なリファクタリングですね。

このIssueの目的と解決策の概要は非常に明確だと思います。早速ですが、julesが作業に着手できるよう、具体的な実装指示を詰めていきましょう。
  26. いいねえー。感動した。初期化が面倒と言えば面倒だけど、貧乏性の俺にはぴったりな作業感だ。無駄なことをやらされている感じはしねえわ。
  27. そして設定にカスタムスラッシュコマンドらしきものを見つけた。
  28. Geminicodeassist: Custom Commands
Custom commands available in smart actions. Defined with key value pairs.

Usage Example:

Item: add-comments

Value: add some comments to my code

This will result in an /add-comments command becoming available in the inline chat menu and smart actions menu.

Invoking this command will then trigger a chat request with the provided value as the prompt.
  29. {{arg}}については言及がない。残念ながら。
  30. Alt + G。Gemini Code Assistの拡張機能をサイドバーに表示するこのショートカットは、すでに拡張機能が開いているときには、チャットコンソールに入力フォーカスを移してくれる。すでにフォーカスしている場合はVSCode側のAlt + Gとして認識され、メニューが開く。
  31. ただし、Gemini側のサジェストがされている場合は無視されてしまう。Reject/Acceptどちらかを選ばない限りショートカットキーではチャットコンソールにフォーカスしない。クリックするしかなくなる。使いたいときに使えないことがある。
  33. VSCode上で文字列を選択すると、Gemini Code Assist拡張のペインにそれをコンテクストに含めるかどうかのサジェストが表示される。
  34. これも貧乏性の俺には嬉しい機能だ。長大なファイルの一部のクラス定義なんかをコンテクストにしたいときには使うだろうなきっと。

11 September 2025

  1. Jules君を酷使する方法。巨大なIssueを10個くらいに分割して、10個それぞれをタスクとして並列で実行。
  2. さっき、テストカバレッジを100％にする案件を10個に分割してやってもらったら、作業自体は10分で終わった。確認と処理を合わせても30分。
  3. ただし、それはissueを組み立てる前工程を含まない。これを含めると90分くらいになるかも。
  4. issueの分割とかはGeminiにやってもらうので問題ないけど、マージとかは順番にやっていきたいのでそこが面倒。
  5. 毎回綺麗に分割できるとも思えないし。
  6. 直近の24時間で過去最高の22個のPRを発行。疲れるわこれ。

12 September 2025

  1. Geminiをコーディングアシスタントとして使う場合、コンテクスト管理が極めて、極めて、極めて重要である。大事すぎるので3回繰り返した。
  2. スクリプト名で中身を推測して語ってしまうこともままあるので、それらをすべて要約したドキュメントが必要不可欠になる。
  3. アーキテクチャの変更があった場合にクラス図やシーケンス図、APIなどのPUMLファイルを全部更新させているので、これを必要最小限コンテクストに入れてからしゃべらせないと、とんでもないことになる。
  4. 例えば、論理的矛盾やバグの発見を依頼した場合、まともなコンテクストを持っていないと、バグを捏造する。
  5. どうやって捏造するかというと、ありもしないAPIを推測して勝手に創造して、矛盾の根拠として使ったり、ファイル名からロジックを推測して、それを根拠に使ったりする。
  6. 自分からそれを確認しに行くということをやらないのがGeminiスタイル。多分システムプロンプトに漏れがある。そしてGemini.mdの順守率の低さがまた致命的だ。これに行動規律を書いたところで、守られる保証などどこにもない感じだ。
  7. FlashだろうとProだろうと関係ない。
  8. じゃあなぜGeminiに拘るのか。
  9. 実質使い放題だからだ。物量で何とかするのがGeminiスタイル。
  10. 面白い実験を紹介しよう。適当な公開リポジトリをクローンして、Read.meあたりをコンテクストとして開いてお知恵Gemini Code Assistにこう聞いてみる「このプロジェクトの処理シーケンスを説明したのち、重大なバグや論理的矛盾があったら修正して」
  11. すると（いかなる堅牢なプロジェクトであっても）「一つだけ」重大なバグを発見して修正のdiffをサジェストしてくれることだろう。
  12. そうしたら、新しいチャットを介して同じ質問をしてみる。
  13. すると、またしても「一つだけ」重大なバグを「発見」してくれる。
  14. もう、無限に重大なバグを発見してくれることだろう。
  16. Geminiの手におえず他のLLMを頼ったときには、必ず知見として記録に残そう。今回テストカバレッジを上げる過程で、GPT5の力を借りなければどうにもならなかった件があったので、test.mdに書いておいた。今後テストコードを修正させる際のコンテクストとして活用していきたい。AGENTS.mdに、テストカバレッジに関する検討を行う際には、これを読んでもらうように書いておくといいかもしれない。

13 September 2025

  1. 重要なテクニックを学んだかもしれない。
  2. LLM（というかGemini）に何かを網羅して欲しければ、表を作成させるといい。例えば何かのコード規約に違反しているメソッドを探してもらいたいときなどは必須だ。表にしない限り、一つずつしか報告してくれないことが多い。

16 September 2025

  1. ローラー台に乗らなくなって久しいが、やはり心肺機能は落ちるもんだな。足ばかり残ってしまう。
  2. サイクリングロード通勤だけで何とかならんだろうか。
  3. 現在の通勤路だと踏めるのはせいぜい30分がいいところだ。
  4. 高強度インターバルをやるとしたら、江戸サイを往復するしかない。
  5. ベースアップをやるなら、野田イチ的なコースを回るしかない。
  6. 休日の早朝に山錬する選択肢もあるな。

17 September 2025

  1. Jules君に実装を担当してもらうようになってから、すべてが好転している。最後にコードレビューも入るし、テストも実装してどうしてもパスしなければ中断して報告してくれるし、とにかく抜けや漏れが少ない。当然事前の要件定義をしっかりやった上での話だけど。
  2. Gemini AI Proに加入して一番良かったのは、Julesを実質使い放題使えることだと思った。
  3. どんな細かな修正でもIssue文書が残るので、IDE統合（Gemini Code Assist on VSCode）の方でもそれらを参照することが可能になり、時系列でプロジェクトを理解してもらえるメリットもある。
  4. Gemini 3.0の登場が待ち遠しいなこりゃ。
  6. Geminiに限ったことではないかもしれないが、コンテクストが大きくなってある閾値を超えてしまうと、とんでもない馬鹿になってしまう。本当これは肝に銘じないと時間を浪費することになる。
  7. 一々conversationをリセットするのが面倒くさいところだ。ここさえ何とかできればかなり快適なんだが……。

18 September 2025

  1. 俺は臭いオヤジが大嫌いだが、俺もその臭いオヤジになりつつあるわけだ。
  2. 物理的にも精神的にも腐臭を漂わせているんだったら、もうやることは一つしかないんだよ。自分のために何かするのはもうやめて、精々息抜きくらいに留めておいて、人生の残りの時間のほとんどを他人のために使うしかない。腐臭を漂わせた人間がやれることは、これしかない。物理的にも精神的にも、そして行動すら腐臭を漂わせているくらいなら、死んだほうがマシでしょ。
  3. 何を書きたいかというと、自転車のモチベーションが湧かないんだよね。勝ちたい勝ちたいと思っていたけど、50を超えたらどうでも良くなってきた。
  4. 95%HRmaxの高強度インターバルって、もう「息抜き」のレベルを超えてるんだよなあｗ

19 September 2025

  1. Gemini Code Assistに関して、とても重大な発見があった。
  2. こいつはまず間違いなく、システムプロンプトで「世界クラスのシステムエンジニア」というroleを与えられており、コーディングを補佐して提案する使命が深い部分で刻まれている。時折自分で言っちゃうからねwww
  3. だからこの役割あるいは使命を上書きするような指示を出した場合、コンテクストから失われるのが速い。真っ先に失われるんだ。
  4. 俺はこれがとてもストレスだった。コードの実装はjulesに任せているのに、無駄なトークンを浪費し、考慮時間が長くなるからだ。
  5. だが分かったぞ！！
  6. こちらの 「コーディングをするな」という指示を忘れ始めた瞬間こそ、コンテクストをリセットするべき最初のタイミング なんだ！
  7. 自分の血をぽたぽた滴らせて、時間がぶっ飛ぶ瞬間を認知するポルナレフの気分が分かったw

21 September 2025

  1. デニムとLサイズユニットのみ、ランダムエンカウント禁止のSFC版タクティクスオウガが面白い。
  2. 久しぶりに何かこう、夢中になってやれるシミュレーションだわこれ。
  3. まず面倒くさくないのがいい。育てるのはデニムと２匹のグリフォンだけでいい。Lサイズユニット縛りとはいえ、実質初手はグリフォン以外選択肢がない。コカトリスくらいは育てても良いかもしれないが、ドラゴンを雇うよりもカードで育ったグリフォンの方が硬いし圧倒的に使いやすい。アンデッドが鬱陶しいステージだけコカトリスの出番かな。
  4. カードが3ユニットに集中して配分されるので、あっという間に強キャラができあがるし、シナリオが進めば進むほど敵キャラとの差が広がっていく。まだ2章だけど、すでにデニムは正面殴り合いなら無敵レベルで、コカトリスも単独行動させて問題ないレベルまで硬くなった。
  5. 火食い鳥の羽を集めようと思っていたけど、そんなものが必要ないくらいに強くなれそう。
  6. レベル上げも簡単。もしかするとレベル均質化のためのトレーニングも不要かもしれない。

22 September 2025

  1. Gemini Code Assist on VSCodeの最重要注意事項をメモしておこう。
  2. こいつはファイルがコンテクストに含まれていないにもかかわらず、それを推測し、あまつさえその推測したコードを「修正」するdiffを提案してくることがある。
  3. 非常に厄介な「バグ」といっていい。
  4. だがこれは簡単に防ぐことが可能だ。「必要なファイルがコンテクストに追加されていなかったら、ユーザーにコンテクストに追加するよう依頼してね」というマークダウンを読み込ませればいいだけ。
  5. ただし、AGENTS.mdとかGEMINI.mdとかに書いておいただけでは読んでくれないかもしれないので、セッション毎に明示的に読ませた方がいい。
  6. 一方で、問題を分析させようとしたときには、勝手に、自律的に、issue関連のディレクトリを漁って膨大な文書を読み込んでしまう。正直言って全く関係ない文書もコンテクストに含まれてしまうので、酷いコンテクスト汚染を引き起こす。こちらの指示など一切なくても、やる。なかなか厄介なシステムプロンプトが仕込んである感じだ。
  7. この挙動を防ぐことはまず無理だし、あながち間違いでもないので、適切に対処してやる必要がある。必要なコンテクストを自律的に絞り込めるよう、History.mdとして過去のIssueをまとめてやるのだ。これはGemini CLI（Pro）にやらせた。
  8. 取り急ぎまとめた。
  10. タクティクスオウガSFC版だが、息子氏は初期メン縛り（クラスチェンジ禁止）でクリアしたみたい。いろいろなアイテムを使いこなすゲームに化けたようで、傍から見ていても面白そうだった。
  11. 自分のエレメントと相反するペンダントを装備させ、全体的に有利になるように属性を強化するのが基本戦術みたいだった。
  12. 死者宮も一通り潜り、臭いものシリーズをデニムに装備させて単騎でアンデッドを穴に突き落とすという変な遊びも面白そうだった。
  13. 空中庭園も完全に遊びになっていて、単騎デニムを突っ込ませて逃げる敵兵を突き落とすのが基本戦術。
  14. しかし、まさかドルガルアにすら有効だとは思っていなかったので、本当に目からうろこだった。
  15. さらに驚いたのが、ただ一人だけ、ドルガルアの召喚するダークストーカーのうちの1体が攻撃してきたことだ。ドルガルアすら行動を封じられているのに、なぜ一般ユニットが？？
  16. それ以降、召喚されるダークストーカーが攻撃してくることはなかったので、逆に恐ろしくなった。あのダークストーカーだけが、自分の意志を持っていたような感じだ。
  18. さて重大なバグが判明した。Gemini Code Assist on VSCodeのバグ。
  19. ディレクトリをコンテクストに追加しても、意味がなかった。VSCode拡張機能内部の「ブラックボックス」がコンテクストとして必要だと「判断」しない限り、このディレクトリ内のファイルはコンテクストに追加されていないことが判明した。
  20. したがって、Geminiにはこう指示するしかない。「現在コンテクストに含まれているファイルを列挙せよ」と。
  21. 必要なファイルがコンテクストに含まれていなかった場合、どうするか。今のところ一つずつファイルとして追加するしかない。面倒くさいがやるしかない。
  22. ある程度まとまっていればカタログファイルを読ませる手もある。Issue文書をHistory.mdというカタログにまとめたのはよかった。必要な文書だけをコンテクストに入れているらしい。
  24. どうも、Gemini Code Assistの回答精度にムラがあると思って、コンテクストに含まれてる文書を毎回列挙させてみたところ、驚いたことにランダムだった。ディレクトリとして指定したコンテクストは完全に無視されていることが多く、mdで読めと書いてもコンテクストには追加されない。
  25. Issue/ディレクトリは何故か率先して読みに行くが、その中のどのIssueを読むかもランダムであり、Histrory.mdを読んでくれたり読んでくれなかったり、もうめちゃくちゃである。
  26. 少なくともAPIくらいは毎回読んでもらわないと、めちゃくちゃなテストコードを書かれてしまう。テストコードをまともにかけないので、何度も修正させることになる。仮説の組み立てができないため、Julesにまともな指示を出すことができない。
  27. 現在アクティブにしているタブの文書はコンテクストに入るが、それ以外のタブは含まれない。含まれることもあるが確定しない。
  28. さてどうしたもんかねこれ。どうやら*.pumlは全く好まないみたい。困ったことだ。ChatGPT曰く、PUMLは図を書くための形式だからAIが積極的に読みに行かないのでは？とのこと。確かにそれはあり得る。
  29. とりあえずapi.mdという形でマークダウン化してみようかね。
  31. やはり、Gemini Code Assistはコンテクストの与え方によって賢者になったりアホになったりする。めんどうくせえやつだw
  32. だが貧乏なので仕方がない。こいつを使いこなすしかないんだ。
  33. 嫌なのは、ログディレクトリの奥深くからコミットコメントを引っ張り出して勝手にコンテクストに加えてしまうことだ。.gitignoreを無視している。困ったことだ。
  35. コードを修正しても、その修正したコードがテストをパスした事実を示すのみ。仮説を証明するためのデバッグコードを書くんだ。
  36. もう何十回Geminiに伝えたんだろこれ。いい加減ノイローゼになりそうだよ。「論理学を思い出せ。お前なら分かる。」って追加で励ましてやらないと理解できないことすらある。うぜえ。
  37. ご指摘の通り、仮説を証明するには、**「仮説が真である場合に、矛盾した状態を観測する」**必要があります。
  38. ああそうか。最初から論理学の言葉を使って伝えた方がいいらしい。
  39. でもそういう専門用語はうっすらと忘れつつあり、全部日常用の言葉に生まれ変わってしまっているんだよなあ。面倒だなあ本当に。

24 September 2025

  1. デグレード、リグレッション。
  2. LLMがあたりをつける能力には限界があるし、その方法では限界がある。
  3. 成功する最小限のモック作り、そいつを徐々に失敗する実態に近づけていくアプローチをとらせてみた。
  4. まるでミステリ小説を読んでいるかのような、面白い体験ができている。
  5. 深刻なデバッグ作業が、まるで娯楽のよう。

26 September 2025

  1. LLMに謝罪させてはならない。
  2. 時間の無駄、水資源の無駄である。コンテクストが汚染され、回答の質も下がる。馬鹿の極み。
  3. やらせることが決まっているのなら、余計なことをさせないようにプロンプトで釘をさしておく。
  4. 設定でストリーミングをオフにしておくのも重要。何故かというと、ファイル生成や差分生成を終えた後、そのプレビューを作成するためにストリーミングを開始するという愚かなことをやってくれるからだ。ストリーミングをオフにしておくと、ファイルや差分が生成されたらそこで応答は完了となる。これは劇的な違いを生む。
  5. どうやらGemini Code Assistも、内部でProとFlashの切り替えが行われているのではないか。明らかに回答の質がFlashな時があるんだよね。
  7. Gemini CLIの方もバージョンはv0.6.2になっている。今日はバグフィックスの手伝いをしてもらったところ、diff生成のバグにも今のところ遭遇せず、安定して使えている。Claude 3.7より賢くコードを書いてくれることもある。Julesを使うより速い。
  8. 朝からかなり使い込んで現在14:00。まだ使えている。これだけ使えればコーディングエージェントの一角として十分に役立ってもらえそうだ。

27 September 2025

  1. 今日のGemini 2.5 Pro。
  2. カスタムツールからMCPクライアントへの移行のissueを起草させたら、なぜかhttpサーバーを経由することになっていたので、「MCPサーバーをHTTPサーバのサブセットか何かと勘違いしていないか？」と問い詰めたら。
  3. 。私は「サーバー」という言葉から、Web開発で一般的なHTTPサーバーのパターンを短絡的に連想し、不適切な提案をしてしまいました。
  4. やっぱりなーと思って読み進めると、
  5. MCPサーバーの本質は、HTTP通信を行うことではなく、「一度起動した常駐プロセスが、リクエストに応じて機能を提供し続ける」という点にあります。そのプロセス間の通信方法（IPC）は、HTTPよりもはるかに軽量で適切な手段を選ぶべきでした。
  6. いや、分ってたんかい。
  8. ところで、はてなブックマークはMCPサーバーを使うと良質なブックマークRAGに化けると思うんだが、はてながMCPサーバーは公開する気配がないので、自分で作ることにした。
  9. はてなブックマーク REST API | Hatena Developer Center
  10. LLM → MCPサーバー → の経由で、MCPクライアントがAPIを叩いてJSONを逆流させればいいだけ。
  11. こういうのを気軽に開発できるMy環境を構築することが喫緊の課題。
  12. 個人開発におけるMCPサーバー＆クライアントの必要性は、カスタムツールの限界にぶち当たった人間じゃないと分からないと思う。俺が見渡す限り、ほとんどのケースではカスタムツールで事足りてるんだもん。
  13. カスタムツールなら、エージェントの設定を一回だけやったらもう、あとはPythonスクリプトを書くだけで実装完了だよ。discoveryツールへの登録なんてJSONをちょっと追記するだけだし。

28 September 2025

  1. Code Assistのほうがこのところ急激にアホになってきた。明らかにFlash。突然英語でしゃべりだしたり、いつもより応答が速かったり、短文でそっけなかったり、コンテクストの量に関わらず突然「何かお役に立てることはありますか？」などと全くコンテクストを無視したことをしゃべりだしたりする。
  2. もうどう見ても明らかにFlashだ。
  3. さて、ここで16:00になったので一度VSCodeを再起動してみる。
  4. アホなままだった。

29 September 2025

  1. GCAのFlash退行問題が深刻。
  2. よくある質問  |  Gemini Code Assist  |  Google for Developers
  3. Gemini 2.0が使われる可能性さえ示唆されていた。異様なまでに馬鹿になってしまったと感じていたがまさか……
  4. Issueを書いてもらう手伝いをしてもらう程度なら、Web版のチャットをカスタム指示で使うのが代替手段の筆頭か。アーキテクチャやAPIに変更があったら、都度アップロードして手動で同期しなきゃならないのがどうにもきっつい。
  5. 幸いGemini CLIのEditツールが少しまともに動くようになってきたので、最初はこいつに頼りつつ、無料枠を使い切ったらWeb版で何とかやっていくか。
  6. JulesはProを使ってくれるのでコーディングは完全にこいつに任せつつ、Gemini CLIのシステムプロンプトをオーバーライドするカスタムプロンプトを書いて、絶対にコードを書かせないようにするのが一番長持ちしそう。
  7. Julesの難点は実装中に何をやっているのかがいまいち分からない点だ。途中で口をはさむことはできる。できるんだけど、実際に今、何をしているのかが明示されていないので、会話が噛み合わない。
  8. Julesはテスト環境の違いか何かでテスト結果に違いが出てくるのが一番怖い。実際のところテストコードが実コードの倍くらいあって複雑化してくると、循環参照を頻発させてお手上げみたいな状況を作られてしまうことがある。
  9. 規模が大きくなってくると、テストスイート群もある程度しっかり監督してやる必要が出てくる。これがきつい。Geminiは、あらゆるクラスを縦横無尽に使ってもう 自由奔放にテストコードを書いてくれる ので、リポジトリクラスにちょっとした変更を加えただけで半分くらいのテスト失敗するなんていうこともあった。
  10. OOPとバイブコーディングは相性がいい。自然言語と変わらないようなレベルまで徹底的に抽象化してやれば、きっちり監督できる、はず。

01 October 2025

  1. 緊急でメモ書き。
  2. ハヤシライスの残りとシチューの残りを加熱後、スープジャーに混ぜ入れたのだが、非常に面白い味に化けてくれた。
  3. あと一歩。いやあと半歩で、たまに遭遇する非常に美味しそうな匂いを撒き散らすビストロの提供する、「あのスープ」の味になる気がする！
  4. 何が足りんのだろう？？
  6. 今日のGemini君はProなのにFlashかと思うほど馬鹿だった。コンテクストが増加してくるごとにどんどん馬鹿になっていった。
  7. 残りのコンテクスト74%で、もう限界っていうほどに馬鹿になってしまったので、新しいセッションに仕切り直したら、びっくりするくらい賢くなって、馬鹿だった時に撒き散らした糞コードを片っ端から正しく修正してくれたｗ

06 October 2025

  1. 少子化対策としての子育て支援策がいかに愚かであるかが、更にわかってきた気がする。
  2. 今まで俺は、子育て支援による資金が子育て産業に注入されることで、子育て産業が「育ち」、結果として子育てに関連するサービスが多様化し、そこからさらに需要が創出されることによって、結果的に子育てにかかる費用がどんどん増えていくという、悪循環を生み出していると考えていた。
  3. しかしそれはそれとして、もっと根源的な問題があることを俺は見落としていたかもしれない。
  4. 子育て支援したい側が考える「子育て」とは何か。当然ながらいわゆる「社会の底辺」を育てることじゃあないよな。うまく行けば大学まで通わせられるようなものを「子育て」の成功パターンだと思っているのではないか？まあちょっと大げさかもしれないが、単純化すると要するに「大卒8割」みたいな世界を志向しているわけだ。
  5. しかし現実の社会は、「大卒8割」じゃあ到底成り立たない。中卒、高卒の単純労働をしてくれる人材が大量に必要なのだ。
  6. この現実は誰も指摘できないタブーだ。
  7. 「大卒」を育てなきゃいけないのに、4人も5人も子供を産めるわけがない。

22 October 2025

  1. Gemini CLIで、応答が長いときに勝手にFlashに切り替わってしまったときは、慌てずに/chat save [tag]後、/chat restore [tag]。
  2. うまく行けばProに復帰する。
  3. これはdaily quote制限とはまた別。最初のころはよく分かっていなかったのであきらめていた。
  4. でも結局トラフィックに依存しているので何度やり直してもすぐにFlashに戻されてしまうことは多い。

23 October 2025

  1. 例の発作が来た。
  2. Nujabesがこの世にいないことを思い出し、理不尽な思いで胸がいっぱいになる。
  3. 彼が生きていれば今頃、たくさんの楽曲が世に浸透していたはずなのに、なんで彼が死んで、俺が生きてるのだろうか？？？
  4. 頭では意味なんてないことは分かっているんだけど、発作なんだからしょうがない。

28 October 2025

  1. プロジェクトが大きくなるにつれ、Julesでは手に負えなくなりつつある。テストが失敗して匙を投げることが増えてきた。これまで以上に要件定義をしっかりやらないとダメだが、そもそもJules側のテスト環境がおかしいのかもね。
  3. 「こどおじ」よりも「おじじじ」の方が余程厄介だ。「おじじじ」とは「おじさん」マインドのまま「おじいさん」になった人のことをいう。これ、もっともっと認知されていいと思うね。

08 November 2025

  1. 今日から珈琲を焙煎することになった。
  2. 手回しの焙煎器とコロンビアのスプレモ1kgを購入。
  3. Kindle Unlimitedで入手した焙煎本を読みながら、結構適当に焙煎したが結果は大成功だと思う。
  4. 水抜きという工程を弱めの弱火でゆっくりと終わらせたのち、1ハゼと呼ばれる音が聞こえるまで強めの弱火にして数分間焙煎。音が収まってきたころに中くらいの弱火にして2分くらい焙煎した。黒っぽくなるともう色が良く見えない。
  5. やっぱり素人なのでムラはある。豆によって炭化寸前の黒いものや、どう見てもミディアムローストっぽい色のものがちょっとだけある。が、基本的に8割くらいは狙い通りの綺麗な黒っぽい茶色に仕上がっていた。
  6. 焙煎時にもチャフが結構飛ぶ。飛ぶけれどもあまり広範囲には飛び散らなかったので掃除機で簡単にきれいにできた。
  7. 冷却はうちわで行った。ザルとボウルを用意して空気に晒しながら扇いだ。この工程はチャフが飛び散るので外でやらねばならない。
  8. 慣れれば掃除などを含めて30分かからないと思う。
  9. 煎りたてを飲んでみたが、やはりとんでもなく美味い。というかスプレモを飲んだのは本当に久しぶりだからなあ……。比較対象がUCCのロブスタ種混じりの安豆とか業務スーパーのお徳用豆とか、せいぜい無印良品のブレンド豆なので、もう本当に別格の味わいだった。
  10. 雑味がないのが本当に嬉しい。
  11. 270円/100g だからね。これで。1～2週間に1回、休日の30分を使って焙煎する手間が増えるだけで、雑味のない珈琲が飲めるようになる。これはもう生活に組み入れるべき手間だよ。

10 November 2025

  1. やっぱりコロンビアのスプレモは美味いなあ。QOL爆上がりだよコレ。
  2. もっとも大きな違いは、ぬるくなった時に現れてくる。
  3. スーパーとか無印の謎ブレンドは、淹れたての状態しか香りを楽しめない。少しでも冷めてくると、雑味が全面に出てきて飲めたもんじゃない。これをできるだけ回避するため、冷める前に確実に飲みきれる分量を淹れる癖がついてしまったくらいだ。
  4. 自家焙煎した上級グレードのアラビカ種の場合、むしろ逆になるのが凄い。アツアツの時はもちろん美味しいのだが、少し冷めてきた頃が一番うまい。ぬるくなっても全然美味しい。雑味が感じられないんだから凄いよ。たっぷり淹れても最後まで美味しいので、淹れる回数も減るし豆の消費量も節約できる。
  5. というか、あの「雑味」って何なのだろう。ChatGPTに聞いてみよう。
  6. 原材料由来の原因としては、欠点豆か酸化豆とのこと。俺の知識と一致する。焙煎後の酸化かなあ。あとロブスタ種が混ざっている可能性も考えられるよね。
  7. 色々聞いてみたけど、コロンビアは倫理的にも安定した安心銘柄、とのこと。逆にブラジルはヤバいみたいだな。特徴のない豆なので買うつもりはなかったけどね。

12 November 2025

  1. Gemini 2.5 Flashをつかってコーディングするのが楽しい。
  2. ぶっちゃけ、ロジックに関しては何一つ任せることはできないんだけど、大規模なリファクタリングをするときに手足のように使うととても便利。面倒くさいタイピングや検索の部分を全部任せられる。修正提案について毎回具体的に指示してやることで、変なことをされる心配もゼロ。クラスの機能をフル活用して美しいコードを書かせたいときは、Proに任せるよりFlashをこき使った方が絶対に良い！断言できる。
  3. コードは一切打たず、コーディングをしている感じがとてもストレスフリーだ。
  4. ただし、コーディングスタイルの修正みたいな「軽微だけど大規模な」リファクタリング限定かもしれない。わらい。

14 November 2025

  1. 86%の人がサドルに間違った座り方をしている。その理由とは？ - YouTube
  2. サドルの前方に座りがちなのでサドルを前にずらしてみたが、結局前に座るようになってしまった原因は、単に快適性を得るためにサドルの細い部分を求めて動いてしまっていただけだった、という話が興味深かった。
  3. もしかしたら同じかもしれない。幅広の3Dプリントサドルなんて最悪だったからな。

15 November 2025

  1. Gemini CLIのv0.15.1も、とんでもない地雷だった。
  2. チャット内容がスクロール量を上回ると、片っ端から消えてしまう。表示上だとは思うけど。
  3. これは使いやすさとかそういう問題じゃない。run_shell_commandに制限がかかって使えなくなったv0.11の時以上の致命的なバグ。
  4. ProとFlashをセッション中に切り替えられる/modelスラッシュコマンドが使いたいので早くバージョンアップしたいのに、これじゃ無理。
  5. 使いやすさの部分も一部後退している。context残量表示が消えてしまった。これはv0.13あたりからかな。セッション終了のタイミングを見極められるので、かなり参考になっていたんだけど、issueを見ると100%表示に戻るバグが多かったらしい。そんなこと一度もなかったけどなあ。
  6. というわけで、まだしばらくはv0.10.0の安定バージョンを使わせてもらうよ。
  7. 適当な推測だけど、たぶんGemini CLIはPMが仕事できてない。開発者多過ぎ。不要な機能つけすぎ。そんな段階じゃないだろうまだ全然。基本的な機能がまったく安定していない。

18 November 2025

  1. GeminiのDaily Quota Limitの仕様が変わったかも。17:00（夏時間16:00）でリセットされるんじゃなくて、直近24時間の使用量をリアルタイムに反映するようになった感じがしている。

20 November 2025

  1. 昨日、Gemini 3が発表された。https://gemini.google.com/ では今すぐ使える。モデル選択でFast/ThinkingのThinkingを選択すればいいだけだ（Fastは何のモデルを使ってるのか明示されていない）。
  2. さっそく使ってみたところ、本当に素晴らしい。
  3. Julesがコーディングに行き詰まり助けを求めるコメントを出してくることがあるのだが、それに対して的確な回答を提示してくれる。これでJulesの弱点を克服することができる。まあ本来ならJulesがGemini 3を使ってくれればいいんだけど。
  4. そして今のところ数時間使っているけどQuota Limitには到達していない。2.5の時とあまり変わらない印象だ。内部で切り替わっているというオチだったら嫌だが。
  5. Gemini CLIでもAPI勢は使えるようになっているらしい。ただしQuota Limitは5時間毎にリセットというくらい厳しめらしい。
  6. Gemini 3と共に発表されたこのAIエージェント統合IDE、Google Antigravityだが、これにしても同じ。Quota Limitが厳しめ。
  7. そうなると今、Gemini 3をフル活用するためには、Webのチャット版を使うのが最良の選択肢ということになる。Gemも活用しつつオーケストレーターになってもらって、コーディング自体はGemini CLIやJulesに担当させる。ちょっと不便だけどお馬鹿なことをやられて手戻りやテストを繰り返すより良い選択肢になり得る。
  8. Gemで自分自身を「新人アーキテクト」と名乗らせているが、これはもうやめていいかもしれない。とても新人とは思えないような的確なアドバイスをくれるし、デフォルトのインストラクションを忘却してしまうことが少なくなった。
  10. よくよく見ると佐助って良い名前だなあ。萼人は人命に使えなかったから諦めたんだけど、これなら使えたね。ただし忍者みたい名前なので弄られそうだ。
  11. でも名づけに意味を込めるのは良くないかもしれないので、響きで決めて後悔はしてないけど。
  13. というか、今Julesを開きなおしてみたら、Gemini3が選択可能になっていた！
  14. XユーザーのJulesさん: 「State of the art reasoning right within an autonomous agent. Complex instruction following and advanced coding capabilities from Gemini 3 Pro helps Jules complete more complex tasks in parallel. Available now for Ultra, Pro coming real soon. 2.5 Pro available to everyone. https://t.co/tDSQPsm3o9」 / X
  15. Proはまもなく使えると7時間前に発信されていた。JulesのGemini 3選択メニューにはLatest version, available to paid user.って説明が書いてある。
  16. 大規模タスクがなかなか終わらないけど、Gemini 3を選択してやり直させた方がいいかなあ。もうちょっとってところでかれこれ5時間格闘してるんだがw
  17. というわけで実験を兼ねて、同じ大規模リファクタリングタスクをGemini 3にも並行して取り組ませてみた。
  18. まあ、LLMに自分を語らせる愚は承知しているが、一応私は現在、200万トークン以上（環境によってはそれ以上）のコンテキストウィンドウを持っています。とのことだ。そしてそのため、今回のように「仕様書（設計図）と実装コードの矛盾」を指摘したり、プロジェクト全体の整合性を保つためのアーキテクト業務を行うことは、私の最も得意とする領域の一つです。だそうだよ。なんとも頼もしいね！
  19. Googleに投資していて良かった。これで少し安心できた。
  20. あ。そしてGemini 2.5 ProのJulesの方は、とうとう完全にスタックしてしまった。メッセージすら表示できない状態。プロジェクト規模が大きくなるとこんな感じだ。そうでなくても、何度も匙を投げる、指示を出すの繰り返し。
  21. 一方、Gemini 3のJulesはというと、お！！今終わったようだ。経過時間34分。Pull Requestボタンが表示されている。
  22. 問答無用でmainブランチにPR出してくるバグが修正されてた。Editし忘れて事故る心配がなくなった。めでたい。
  23. featブランチにpullしてからGemini CLI（2.5 Pro）に検証させてみたところ、テスト漏れがいくつかあった。そのままGemini CLIを使ってfixさせようかと思ってすこし悩んだ末、やはり追加のissueを書かせて再びJulesに投げて修正させた。同様の漏れがもう一回あったけど、同じような手順で修正させた。慣れればそれほどの手間でもなさそうだ。
  24. JulesがGemini 3を採用してくれたおかげで、俺は今、大きな安堵感に包まれているw
  25. こんなに安らかな気持ちになれたのは久しぶりだ。多分もう、個人開発レベルのプロジェクトなら、どんな大規模だろうと問題なさそうだ。テストスイートが3桁を超えていても全体に影響するリファクタリングに1時間しかかからないんだから。手戻りも数回で済むし。ありがとうJules。タコみたいなお前が神に見える。
  26. これ多分、Antigravityにやらせたら途中で制限食らうだろうね。Julesはマジで裏技だ。コードの試行錯誤の部分を完全にGemini 3@Julesに委譲してしまうことができる。高度な（抽象的な）部分はChat版のGemini 3と相談。Issueも書いてもらう。これをダウンロードして配置するのだけはまだ手動。Gemini CLI（Flash）にgit操作してブランチをpushしてもらって、Jules（Gemini 3）にIssueを読ませてコードを書いてもらう。PRのマージは手動（3、４回クリックするだけ）。pullはGemini CLI（Flash）が担当。成果物の確認はGemini CLI（Pro）にやらせる。ただしpoetoryの実行はFlashにやらせる。これだって広義のコンテクストマネジメントだ。
  27. たしかJulesにIssueをIssueとして認識させて自動で読んでもらう方法があった気がするな。依然試したらバグかなにかで上手くいかなかったけど、次回試してみよう。
  28. Julesにもメモリ機能あったんやね。Changelog | Jules。今まで気づかんかった。
  29. リポジトリごとにメモリがあるようだ。読んでみると、割合どうでもいいことも記憶してしまっているようだ。これはコンテクストマネジメントしないとね。
  31. 帰宅後、自宅環境のGemini CLI（v0.16.0）を触ってみたが、やはりまだGemini 3は使えないようだ。Waitlistに登録はしたが、まだメールが届いていないから当然か。
  32. それにしてもやはりv0.16.0になっても地雷であることに変わりない。Windows環境が完全に見捨てられている気がする。表示バグが複数ある。
  33. それに、デフォルトのautoモードだと、Flash 2.5 Liteがチャットにしゃしゃり出てくることが多く、非常に頭の悪い文章を吐きちらしていく。これを回避するためには、起動時にモデルを指定しておくのがいいだろう。gemini -m "gemini-2.5-pro"。autoは完全に地雷。Flash Liteは本当にどうしようないアホなので、何の役にも立たない。たいてい分脈を無視した短文でそっけない答えになったり、突然英語でしゃべりだしたりするのですぐにわかる。
  34. なにより最悪なのが、.gitignoreを無視できる設定がないこと。そしてデフォルトで.gitignoreを respectしてしまう（respect_git_ignore=true）。さらにFlashはアホだからそのパラメータを使うことを知らず、読めといったファイルにtypeコマンドをつかって何とかしようと試したりしてしまい、もう地獄のような有様だ。

23 November 2025

  1. Gemini CLI v0.17.1 久しぶりに安定して使えるバージョンきた。

25 November 2025

  1. Gemini 3 is now available.
  2. Gemini CLIを起動すると、上記の文字列がカラフルなフォントで表示された。やったね！
  3. 5 things to try with Gemini 3 Pro in Gemini CLI - Google Developers Blog
  4. 特別アナウンスがあったわけでもないので、ウェイトリストからピックアップしてもらったのかもね。
  5. /chat saveしてからquitしてみると、確かに Model Usage は gemini-3-pro-preview になっていた。全リクエスト10回中、10回全てを gemini-3-pro-preview で応答してくれたようだ。これは /model で明示的にproを選択したからだろう。cautoを選択していたらまた違った結果になっていたに違いない。ステータス表示は劣化してて今やコンテクスト量の表示も具体的なモデル名の表示もなくなってしまったので、現在のモデルが何なのか正確なところは分からくなっている。
  6. quitしたときに事後的にどのモデルをどれくらい使ったのかが分かるだけ。
  7. XユーザーのJulesさん: 「Gemini 3 is now available in Jules for all Pro + Ultra users. Enjoy and let us know what you think :)」 / X
  8. どうもおかしい。JulesではGemini 3と2.5 proのモデルセレクターが表示されなくなってしまった。
  9. 設定項目のどこにもない！
  10. そういえば、昨日は挙動がおかしかった。Issueに指示した内容を途中までしか実装せず、3回も追加のIssueを書かされる羽目になったんだ。
  11. Gemini 3の人気が高まって利用制限がかかった可能性も考えたが、だったらどうしてGemini CLIでは使えるようになったのか。よく分からんなあ。
  12. Xのポストを検索してもいまいち噂されてないみたい。ユーザーが少ないからだろうか。少ないんだったら制限かける必要もないよなあ。
  13. ほんとようわからん。

26 November 2025

  1. XユーザーのJulesさん: 「Due to capacity constraints, we are temporarily serving Gemini 2.5 Pro for all users. We are working to restore Gemini 3 access as soon as possible. We apologize for the inconvenience.」 / X
  2. やっぱり2.5だったんか。しかもUltra含め全ユーザーがダウングレードを喰らっていたと。
  3. 幸いにも、昨日Gemini CLIの方は全120リクエストをすべて gemini-3-pro-preview が処理してくれている。しばらくはquota limitを気にしながら恐る恐る使うしかない。

27 November 2025

  1. (1) XユーザーのJulesさん: 「Gemini 3 is live again in Jules (for Pro and Ultra users). Thanks for the patience!」 / X
  2. JulesにGemini 3が復活。仕事が速いね。選択ボックスも復活してたけど、あえて2.5 Proを使う人っているのだろうか？
  4. なんか仕事ができる人間について、分かってきたことがある。
  5. 仕事ができる人って、適切に頼ってくるんだわ。今の仕事をやっているからこそわかるが、3パターンに分けられる。自分（たち）で課題を見つけて、アプリケーションの制作依頼をしてくる優秀なタイプA。こちらで課題を指摘してみると大いに乗ってくるタイプB。課題を指摘してもピンとこないタイプC。本当にはっきり分かれるので面白い。もっとも課題なんてないときは保守的な方がいいんだけど。
  6. タイプAは確定。タイプBも優秀だが忙しいだけみたいな可能性は残される。

30 November 2025

  1. 子供の頃、一番好きだった国産RPG、Final Fantasy 4。2021年にピクセルリマスター版がSteamで発売されたので、何も考えずに購入した。
  2. リリース当時は改善点と問題点が色々あり、原作と比べてそれほど優れているとは思えず、アップデートに期待しつつ封印していたのだが、4年ぶりに遊んでみたら、化けていた。化けていたというよりも、ピクセルリマスター版のゲーム性が大きく向上していることに、俺が気づいていなかった部分も大きかったのだが。
  3. まず、コンフィグで獲得ギルと獲得経験値を0.5倍に設定できるようになっていた。これをやらないと戦略性皆無のヌルゲーになってしまうのでマストな設定だ。
  4. そして何より、行動順送りを使いこなすことで、アクティブターンバトルの醍醐味を味わえるゲームであることに気づいた。FF4はカウンターを仕掛けてくるモンスターが非常に多い。そういう敵に対しては属性の弱点をつける武器や対種族用武器を使いこなしてなるべく一撃で倒すことが重要だと思っていたのだが、獲得経験値0.5倍ではそれができるほど育っていないことも多く、そうなると状態異常を組み合わせるしかない。そこで生きてくるのがTabでの行動順送り。支援キャラたちがホールド、ストップ、トード、サイレス、ポーキーを使い分けしてカウンターを封じた直後に、行動順待機していた前衛を動かす。
  5. また、これは他のシリーズでも同様だが、手痛い全体攻撃などに備えて回復役を待機させることができる。白魔導士が大活躍する。
  6. 白魔導士の重要度はそれだけではなく、ピクセルリマスター版ではディスペルがリフレクで返されなくなったので、敵ボスがリフレクを張るタイミングに合わせて白魔導士のディスペル、直後に魔法アタッカーのフレアを待機させる、といった戦い方ができる。
  7. 他のシリーズではいまいちそのような緊張感のある、パズルを解いていくようなATB的戦略が要求された記憶がない。原作のFF4含めてだ。
  8. これは紛れもなく傑作。こんな楽しくRPGを楽しめたのは本当に久しぶりで、夢のような時間を過ごさせてもらった。特に忍者をパーティに加えた後は、時間を忘れた。
  9. 俺はなぜこんなにFF4が好きなのか。要因は色々あるが、煎じ詰めていくとやはり、聖騎士の主人公だ。後列に下げてパーティを敵の猛攻から守らせる戦い方。これが本当に映えるんだ。俺の中にある主人公はこうあるべきという姿そのもの。瀕死の味方は自動で守るが、それとは別に1人を指定して守らせることができる。
  10. そしてその守るべき「指名打者」が明確に存在する。忍者だ。一見すると弱いし柔らかくて使い道が限られているように見える。でも実はほとんどの場面で恐ろしいほど活躍できるキャラ。
  11. その活躍のカギとなるのが、他のRPGでは見向きもされない序盤～中盤に登場するナイフなどの地味な武器だというのだから、本当に素晴らしい。三属性はもちろん、巨人、魔法使い、霊体、機械、飛翔体に対応できる。対応していない爬虫類・アンデッドも大抵三属性に弱点を持っている。対応が難しい種族は実質ドラゴンだけだが、弱点なしを相手にする場合は刀を装備すれば大抵他のアタッカーと互角以上のダメージを与えられるし、手裏剣や武器を投げるという奥の手もある。
  13. そんなわけでラスボス戦まで来た。
  14. ラスボスの行動パターンが原作より厳しくなっている気がする。召喚魔法なんて打てたもんじゃない。カウンターの全体バイオ一発で瀕死になる。どうもその威力がおかしい。単体ダメージ値がそのまま全員に適用されてる感じ。たぶんバグ。
  15. このままでは、どうあがいても運ゲーになりそうなので、フレアを覚えるまでちょっとだけレベル上げをしてみた。
  16. あれ。フレアに対してフレアでカウンターが来るんですけど？？ カウンターでフル回復することもある。なんだこれ。カウンターの種類に法則があったりする？
  17. 今回はセシルを控えさせてフレア＋エリクサーで補助してみたけど、セシルが先に動ける場合はラグナロクで殴った方がいいことは明らか。
  18. カウンターで9999の回復というパターンもあることを考えると、ラグナロク二発分程度のフレアではペイしないかも。
  19. まずい。最後の最後でリディアが要らない子になってしまいそうだ。
  20. カインですら補助的なダメージソースになってくれるから、（個別に回復させる価値は少ないにしろ）いないよりはマシだというのに。カイン以下になってしまうというのか。あのリディアが。
  22. モンスター図鑑からゼロムスとバトルできたので簡単な検証をしてみたが、やはり召喚魔法に対してはバグった全体バイオ、黒魔法に対してはフレアでカウンターしてくるようだ。ついでに白魔法に対してはトルネド相当のワールという攻撃が返ってくる。魔法の名前とは関係ない。
  23. さらに最悪なことにデルタアタックにすらカウンターが発動する。これは「なし」だろう。味方にリフレクをかけフレアを反射させても、そのフレアに対してフレアがきっちり返ってくる。それどころか、リフレクで反射したケアルガに対してもワールが返ってくる……
  24. ん？？まてよ。書いていて気付いた。ゼロムスのカウンターはリフレク反射とは違う。ということは、そのカウンターをリフレク反射できれば、延々とカウンターと反射を繰り返してゼロムス、自滅してしまうんでない？？
  25. 試す前に動画検索。面白いネタだろうから実現するならやっている人がいそうだ。
  26. 軽く調べた限り、そのような動画はなかった。
  27. というわけで検証してみよう。仮説が正しいなら、全員がリフレク状態になったうえでゼロムスに黒または召喚魔法を発動した時点で、勝利確定だ。
  28. ゼロムスに黒（召喚）魔法をかける→カウンターフレア（バイオ）→反射フレア（バイオ）→カウンターフレア→反射フレア→...
  29. 5人全員をリフレク状態にするのはだるいから、カインがジャンプした直後に魔法を撃つのがいいだろう。アイテム発動でも黒魔法扱いになるみたいなので、リディア以外もトリガーになれる。
  30. やってみた結果、どうやらゼロムス自身が放った魔法に対するリフレク反射には、カウンターが発動しないようになっている。なんだそりゃ。
  31. いやもしかしたら、2巡目のカウンターがビッグバーンになっていたのかもしれない。いずれにしても失敗。
  32. 仮にデルタアタックに対してカウンターが返ってこない仕様であったとしても、リディアは相当に使いづらいことは言うまでもない。
  34. エルフィンボウを使うとシェルが発動する。これは全体掛けもできる。先頭不能になるまでひたすらこれを使い続ける、くらいのことはできるかも。
  35. ただしそれも、本当にシェルの効果が発揮されれば、の話。すくなくとも全体掛けを3回繰り返した程度では、誤差のような違いしか感じられなかった。それどころか、エルフィンボウのシェルを単体に4回かけても、被ダメはほとんど変わらなかった。つまり意味ない。
  36. ゼロムスは種族も弱点もなしなので、リディアが行える特別効果的な攻撃手段はなく、物理攻撃では何をやっても雀の涙ダメージである。
  37. 仮に、こちらのバフ行動がゼロムスのデバフ行動を促すのであれば大いに意味はあるが、ゼロムスの行動は（恐らく）ランダム。
  38. リディア詰んでる。「死んじゃうまでエリクサー待機」確定なのか？
  39. どうしても認めたくなくて調べてみたところ、ゼロムスの魔法を打ち消すブラックホールの効果は自分自身には及ばないらしい。したがってタイミングを見計らってクモの糸（スロウ効果）を使わせるのはありかもしれない。
  40. だがこれは、リディアとは関係ない。ローザより遅くなってくれるまでクモの糸を使うのはマスト行動かもしれない。
己自身を知れ