Home → 2025-2026 winter, since 2009-12-01

2025-2026 冬

02 December 2025

  1. Prev: JintrickのマイクロWeb日記 2025秋
  2. ブラックフライデーのセールで soundcore motion+ 購入。職場のPCのスピーカーをsoundcore2からこいつにアップグレードした。soundecore2はオンライン会議には問題ないといった程度の代物だった。
  3. 最近レッド・ガーランドのアルバムを聴きながら仕事をするが、ジャズベースが聞こえそうで聞こえないのが拷問だったのだ。このmotion+に加えてイコライザーFxsoundも導入した。まあ俺の安上がりの耳には及第点だろうか。
  4. コスパは恐ろしいほど優れていると思う。良い時代になったもんだなあ。
  5. ちなみにGemini 3に教えてもらった。くっそ細かい要件定義につき合わせてしまった。

03 December 2025

  1. 「この施策の目的とKPIは？」という問い掛け - フジイユウジ::ドットネット
  2. 極めて重要な話だなこれは。
  3. なんか新しいサービスが噂されている、みたいなシチュエーションで導入を検討するときに、目的とか指標とかを考える前に、まずその「新しいサービス」について知ることから始めないと、何にも分からんのだよ。
  4. なんかよく分からん噂レベルで知った気になって、そのうわべだけの情報で目的に合致するかとか指標をどうするかなんてことを検討したって、間違った情報しか出てこない可能性がある。まあ言ってみれば、否定する根拠なんていくらでもひねくりだせる段階よ。だって分からないんだから。パラメータを黒塗りにしてしまえば、リスク関数がはじき出す値はいくらでも振れるんだな。
  5. じゃあどうすればいいのかと言ったら、検討する前に試験的に導入してみることだ。テスト環境を構築する。難しければせめて試しに触ってみるくらいのことはできるだろう。
  6. それをやらないってことは、まあお察しなんだよね。

06 December 2025

  1. FF4 PRを再プレイ。
  2. 序盤から結構違いが出る。
  3. 矢が無限なので、リディア、ギルバートも弓を装備するのが基本になる。ロッドは装備していなくても使うことができる。
  4. リディアを加えてすぐ、回復用アイテムを拾う前にギガントード*3とエンカウント。1匹だけになるとトードを使ってくるらしく、セシルがカエルになってしまった。カイポに戻るまで何とか敵に出会わずに済んだけど、逃走禁止縛りなので詰んだかと思った。長年やってるけど初めてのシチュエーションだ。
  5. 買い物禁止を入れようかとも思ったが、爪を買えないと厳しいし面白くないので却下。

08 December 2025

  1. FF4 PR再プレイ2日目
  2. PRはSteam版なのでキーボードで操作する。左手のみ使用。慣れれば非常に高速かつ快適。楽な姿勢でプレイできる。
  3. プレイ時間2:54でバロン地下水路。ここからようやくFF4らしくなってくる。金欠なので色々売り払ってバロンで装備を整えた。
  4. パロムポロムは弓矢を装備。テラには武器を装備させない。装備していなくても武器をアイテムとして使えるようになっているので、セシル、パロム、テラの3人で癒しの杖を使えばヒールを3発打てる。パロムとテラでサンダーロッドを使えば、サンダーを2発撃てる、という具合だ。
  5. 水の四天王は完全に雑魚。テラ or パロムを待機させてサンダーで津波をキャンセルすればいいだけ。

10 December 2025

  1. 珈琲のドリップ方法を少し見直し。
  2. ラオ・スピンとやらを取り入れてみた。
  3. 抽出率が上がる。これは間違いない。湯の落ち方が鈍って過抽出になりやすい。これも間違いない。
  4. だったら別に、最後まで抽出しなければいいんじゃね？
  5. 自分なりのレシピを完成させておきたいところ。
  6. 最初の1投はこれまでと同じにする。蒸らした過程でしみ出した酸味の美味しい部分を落とすイメージ。
  7. 2投で最後まで注いで一気に終了させる。ここでラオ・スピン。珈琲ベッドをフラットにしてしまう。「壁」として無意味に鎮座していた粉たちを抽出に参加させるイメージだ。
  8. 7割くらい落ちたらドリッパーを外して終了。
  10. とても久しぶりにExcel VBAで何かを書いている。
  11. クラスモジュールを使わないと何一つ書けない（書く気力すら湧かない）体になっていた。
  12. この半年くらいは毎日のようにGeminiと議論していたので、クラス設計に迷いがなくなったよね。

11 December 2025

  1. Julesがタスクスケジューリングに対応したとのことなんだが、どうやって活用していいかわからん。活用できたら便利なんだろうけどなあ。
  2. Suggested Tasks | Jules
  3. こちらは#TODOというコメントを発見してIssueを提案してくれる機能。

12 December 2025

  1. 起床してすぐに、立ったまま靴下を履く動作を行うと腰に痛みが生じるが、これをゆっくり行うことで逆に痛みが軽減ことが判明した。
  2. また、ベッド上でクラムシェルに似た動作を行ったところ、ロングライド翌日の腰痛が引いた。
  3. ベッドで寝てると腰痛。この問題を解決できるかもしれない。
  4. 自転車乗りなので、多分普通の人とは原因が違う。
  5. 殿筋が発達している。踏み下ろすための筋群は良く協調して動く。
  6. 一方で、膝を上げる動作は苦手かもしれない。ペダリングで使わないこともない動きだが、相対的に弱い。
  7. この不均衡によって骨盤にゆがみが生じるのではないかという仮説を立ててみた。

14 December 2025

  1. クラムシェルの動作で腰痛から解放されると思っていたが、考えが甘かった。まだまだ起床時の腰痛は続いている。
  2. そこで仮説に基づき、新しい腰痛体操を考案してみた。
  3. 骨盤を良位で安定させるため、まず殿筋に力を入れつつ、立ったまま靴下を履くような動作を左右で繰り返す。これだけ。
  4. またクラムシェル動作を洗練した。同じく殿筋に力を込めつつ、片足立ちのまま反対の脚を横に上げていく。上記の動作のついでに行う。
  5. これでかなり落ち着く感じがする。手で膝を抑えたりして負荷を補助することで、これらは寝たまま行うこともできる。
  7. CAPCOMのベルトスクロールアクション「天地を喰らうII 赤壁の戦い」で趙雲ハイスコアプレイをずっと練習している。
  8. ハイスコアモードではウルトラハードモード、1Upは30万点時のみに固定される。クリアだけなら別に問題はないが、ハイスコアを目指すとなると馬に乗ったまま延々とボスの猛攻に耐えつつ雑魚をなぎ倒していかなければならない。
  9. 徐晃戦ではわざとタイムオーバーさせて、残り時間を99にリセットし、残り97秒で倒すことによって大量のタイムボーナスを得るのが定石なのだが、タイムが0になっても中々タイムオーバーにならないときがあって辛かった。
  10. その謎が昨日解けた。実はこのゲームのボス戦にはタイムオーバーという概念はなかったのだ。残り時間がゼロになると徐々に体力が減っていき、体力がゼロになるとミスになるということに気づいた。
  11. この発見によって目指すプレイスタイルが少し変わった。特に中盤までのボス戦では、残り時間がゼロになった後も体力がなくなるまでは雑魚を狩ることができるということなので、いかに体力を温存するかが鍵になる。

16 December 2025

  1. 効いたり効かなかったりしていた腰痛体操だが、ようやく改善する動きが判明した。
  2. これまで、クラムシェルに似た横に広げる運動と、腿上げのような運動を交互に行っていたが、この2つの中間の動作が最も自分の腰痛に効くことが分かった。
  3. 寝ているときにやれるのが大きい。側臥位と仰臥位の中間くらいに寝て、殿筋に力を込めながらベッドと垂直に膝を上げていく。布団の重さがちょうどよい負荷になる。
  4. 2日連続で起床時の腰痛が消えた。
  6. 天喰ら2のハイスコア挑戦だが、徐晃ステージの雑魚戦が安定しない。くノ一3人娘の動きがカオス過ぎる。
  7. 中ボス級の3人娘と、3人の弓使いと、3人のデブ。組み合わせとしても最凶で、常時ラインをずらさないと娘ナイフが雨のように飛んでくるのに、ラインがずれることで対処困難なデブの斜め突進が絶え間なく襲ってくる。突進系は敵を投げつけることで防げるが、この斜め突進は防げない。ジャンプ攻撃も分が悪い。斜めに動いて逃げるかメガクラッシュしか選択肢がないが、下手にかわす移動をしていると今度は弓とナイフに襲われる。
  8. 攻略としては9人の敵すべての位置を把握しながら特に斜め突進に備えてメガクラッシュの準備をしつつ、一刻も早くターゲッティングした最初の娘を倒しに行く。きつすぎる。
  9. まあ実戦では弓とデブの2人くらいは勝手に逃げて行ってしまうのだが、誰も逃げないパターンで練習している。
  10. 体力半分残すのが目標だが、勝率3割くらい。
  12. 久しぶりにソースネクスト版の三國志9を起動。
  13. VM WareでWindows XPを起動。3Dアクセラレーターをオフ。インストール後のsan9pk.exeにNoCDパッチをあてる。
  14. それにしても三國志9って人気ないな。攻略サイトが少ない。多分それでだろうけど、昔自分で色々作ったファイルが置いてあった。Javascriptで動作するみたいだ。全然記憶がない。

18 December 2025

  1. Gemini CLIがv0.21で大きく前進。gemini-3-flash-previewモデルが使えるようになっただけでなく、/modelをautoにすると3-proと自動で使い分けてくれる。Gemini 3 Flash is now available in Gemini CLI - Google Developers Blog
  2. 3-flashはそこそこ賢くて応答が速い、のだと思う。知らんけど期待大。
  3. また、/statsコマンドも大きく改善された。3-proがあとどれくらい使えるかがパーセントで表示され、かつ、何時間後に使用量リセットが行われるかを確認できるようになった。
  4. ちょっと驚いたのが、3-proと2.5-proはクォータを共用していたということ。うっかり2.5-proを使うと、3-proの使用量も浪費してしまうことになる。これは気を付けないといかん。
  5. あと、/statsコマンドには3-flashの利用に関する情報が出てこないのが気になる。3-flashだけを使って実験をしてみる必要がある。
  6. 実験してみたところ意外な事実が判明。gemini-3-flash-previewモデルは、proと違って独自のクォータで管理されていた。
  7. これは本当にうれしい誤算。3-flashすら節約したいときには、2.5-flashを使えばいいということだからな。
  8. そして当然、3-proを確実に節約したいときは3-flashを使うことができる。
  10. 息子氏が三国志9に興味を持ったようです
  11. 戦争面の出来の良さをアピールしておいた。またBGM/SEの暗さはインストールフォルダ内音声ファイルの入れ替えでなんとかする方法を教えておいた。絵面の悪さは我慢しろと。
  12. 戦略フェーズの内政と計略は単純極まりないので、戦術に注力できる。ただしよくできたそれもCPU相手だといずれ飽きが来るので、対戦プレイできるようになりたいものだ。
  13. あと顔グラが美形だらけで味気ないので、三国志7あたりのそれと入れ替えたいところ。4あたりの荒いドット絵でも味があっていいかもしれない。
  14. 顔グラの入れ替えには確かツールが必要だった気がする。
  15. 色々思い出したくてゲームシステムについてGemini 3に聞いてみたが、学習が中途半端でハルシネーションだらけだった。VMWareに関してはかなり精度が高かったのでちょっとだけ期待してたんだけどね。
  16. 自力でググったところ、減色、3サイズ用意する必要がある等々、面倒くさすぎることが判明したので断念。

19 December 2025

  1. Pixel 7aのバッテリーが若干劣化してきた気がするので、無駄な消費を抑える設定をした。
  2. 接続設定 > 接続の詳細設定 > 印刷 > デフォルトの印刷サービス を OFF（プリンターを常時検索してしまうらしい）
  3. Google 開発者サービス > デバイス > 付近のデバイスのスキャン を OFF
  4. 日記にでもメモっておかないと再現できなくなりそう。
  6. 三国志9のプレイ記録をこの日記に付けていたような記憶があって、gemini-3-flashに探してもらった。Googleサイト内検索だと漏れてしまうようになったからしゃーない。
  7. すると、2010年の冬に記録が見つかった。そうか、Windows7時代のWindows Updateで起動できなくなって、対処法はあったものの面倒でやめていたんだなと。
  8. 15年ぶりの起動だったというわけだ。
  9. 戦闘BGMを三国志2の蜀の戦闘テーマに入れ替えて遊んでいたら、息子氏(2)がそれを聞いてヘッドバンギングをしていた、みたいな記録もあってほっこりした。
  10. 三国志で洗脳しちゃってたんだね。幼少期から。
  11. まあその甲斐もあってか、昨日は三国志9チュートリアル下邳攻防戦に挑戦していた。この分なら立派なプレイヤーに成長してくれるだろう。
  13. Amazon Musicを退会したいのだけど、なかなかタイミングがつかめない。レッド・ガーランド、バリー・ハリス・トリオをはじめとするお気に入りのアーティストが続々見つかってしてしまい、しばらく曲を漁る毎日が続きそうなのだ。
  15. Notebook LMを久しぶりに触ってみよう。どうやらなんちゃってスライドを作るのに使えるっぽい。
  16. 「ぱっと見完成度が高そうながら、よく見るとあまり効果的でない程度の画像」を自動で作ってくれるようだ。
  17. AIが「パワポ作り」を奪った日。NotebookLMが10分でプロ級スライドを量産する世界へ
  18. 自分に命じられたスライド作成作業がブルシットジョブだと一瞬でも疑ったなら、もう迷わずNotebookLMに丸投げするべきだろう。
  19. しかし、俺の見立てを裏切るようなことがあれば、すなわち、本当に役立つスライドを自動で生成してくれるのであれば、生産性とやらを向上させることができそうな匂いはする。
  20. 使い方は簡単。マニュアルを見るまでもない。ノートを選んで、ソースを選んで、スライド資料ボタンをクリックするだけ。ソースを選んでいないとボタンがグレーアウトしているが、ここがちょっと不親切かな。俺だったら不活化するだけじゃなくアラート出す設計にする。
  21. 生成AI活用ガイドラインという社内向けのマークダウンを春に書いた（というか8割方Gemini 2.5に書かせた）んだが、それをNotebook LMに放り込んでボタンワンクリックで、びっくりするくらいそれっぽいスライドを作成してくれた。よく読むと手直しが不可欠な部分もあるけど、ぱっと見バレないレベルには収まっている。わらい。
  22. ダウンロードしてみると、画像PDFだった。たたき台にしてどうこうする向きには使えない。
  23. Adobe Acrobat オンラインとかiLove PDFとかで変換すると中途半端にOCR処理をやろうとして、しかも失敗して文字化けの嵐。Canvaを使うと画像のままPowerPointに変換してくれた。スライドとしてのデータが欲しい場合、ウェブサービスを横断的に使わなければならない。
  24. このスライドに音声を当てたい。ここはおそらくEdge Copilotの出番。いい感じに適当な読み原稿を作ってくれそうな気がする。
  25. そう考えるとNotebook LMがスライドをPDFで出力してくれたことが奏功する形だ。EdgeでこのPDFを開いて、Copilotサイドバーで命令するだけだもん。
  26. と思ってやってみたら、そうだった画像PDFだったので、Copilotには読み取れない。すると、あいだにyomitoku（OCR）を噛ますしかない。
  27. なんだかんだ作業工程が色々あって、手慣れていないとかなり面倒に感じるのではないか。
  28. Notebook LMは機能が大幅に増えてるね。インフォグラフィックというのが気になる。もしかすると必要な情報をマークダウンで与えるだけでいい感じのポスターを作れるかもしれない。少なくともデザイン原案にはなりそうだ。Nano bananaでもいいんだろうけど。比較してみよう。
  29. ポスターやスライド作成については結構相談を受けていたし、ここは社内研修会開くかな。
  31. 腰痛対策が確定。特別な体操は不要であることに気づいた。階段を上るときに階段に対して身体を斜め～横にする。これだけで腰痛を解消する動きになる。
  32. ちなみに立ったままこの体操をやろうとすると、犬が立ちションするみたいなポーズになる。
  33. 長年悩まされてきたからなあ。これは本当にめでたい。祝杯を挙げよう。

21 December 2025

  1. Gemini 3に教えてもらったFxSoundを使っている。スピーカーやイヤホンの性能を引き出してくれている。
  2. 週末FF4。磁力の洞窟を攻略。
  3. セシルとシドにはグレートボウやクロスボウを装備させて聖なる矢を撃たせる。当然後列に下げて。
  4. テラにはホールド（消費MP5）だけを使わせる。この魔力切れは全滅リスクを伴うので、回復はセシルにやらせる。セシルのMPは少ないため、ケアルを使わせるときだけ光の最強装備を行う。エーラパトラはアスピルが有効なので活用する。
  5. ダークエルフ/ダークドラゴンは全く問題ないと思われる。気を付けるのはセシルを前列に戻しておくことくらいか。今回テラにはスロウを使わせてみた。ダークドラゴンにチェンジした後にも効果が継続していたのかどうかは分からんが、楽に勝てたので良しとしよう。セシルの攻撃一発は600～800pts.くらいだった。経験値半分でレベル上げなし。
  6. 非常口を使ってさっさと脱出。というか、テラのテレポでもよかったのか。
  7. ゾットの塔の攻略。
  8. テントを張れるポイントが少なく、レベルも低めなので消耗戦ができない。ということでセシルを後列に下げる。ヤンに防御は不要なので拳法着を譲ってもらい、セシルの回避率を40%くらいにする。後列なので実際の回避率は倍の80%以上かな。これで鉄壁の防御となる。雑魚はカウンター以外の攻撃魔法を撃ってこない。シドも後列で炎の矢を撃っていればいい。
  9. 一部気を付けるのはインプとブリーズドッグが単騎になったときの魔法やブレイズ。多くの敵に、結構ミニマムが効いた。
  10. フレイム系の装備が手に入るのでついついセシルに使わせたくなってしまうが、それは十分なレベルがあるときの道楽みたいなもんだな。
  11. デルタアタックの人たちとの戦闘。ここは大地のハンマーに活躍してもらう。ほぼここでしか使えないアイテムではないだろうか。
  12. テラにヘイストをかけてもらったシドが、ひたすら無詠唱クエイク。他のメンツは真ん中のおデブを攻撃。面倒くさいからセシルは後列のままにしてヤンを守らせていたけど、被ダメージは1だったのでたぶん前列でも問題ない。
  13. 敵はおデブにリフレクを重ね掛けしようとしてくるので味方にもランダムでリフレクがかかってしまい、ケアルが使いづらくなる。でもまあ、ポーションの100回復で十分間に合ってしまう。ただし下手にフレイム系を装備させておくと、ファイラで大ダメージになる可能性はある。そこだけ注意かな。今回そういう不運はなかったけど。
  14. 「竜騎士である君の力がいる！」
  15. そう思っていた時期が俺にもありました。
  16. 風のバルバリシア戦。クエイクは効かないのでシドが役に立たん。セシルを後列にしておけばバルバリシアの攻撃は完封できるので、回復行動はセシルがトルネドを喰らったときだけでOK。ヤンとシドを前列に配置してバーサク状態にする。シドは大地のハンマーを装備。カインは後列からジャンプするのみ。まあ別にジャンプ攻撃で風のバリアを解除しなくてもダメージは通るんだけどね……。
  17. ローザはスロウを連打。セシルは風のバリアがないときだけ攻撃。それ以外は自分へのトルネドが来た直後に即ケアルラをかけられるよう、ターンスキップして待機。セシルの武器は何がいいだろうね。碌なソースにはならないからなんでもいいか。
  18. カルコブリーナ戦。合体させない戦法のための布陣で挑んだのに、レベルが低すぎたのか最後の人形を倒し損ねて合体察せてしまった。セシルが一発400～800ダメージ喰らう。麻痺、混乱もあり久しぶりの全滅。
  19. ここは不確実な合体阻止を狙うのをやめセシルを後列に下げたが、それでも300程度のダメージは喰らう。スロウは効きが悪い。
  20. バブイルの塔。直前にドワーフの斧が手に入るのでセシルが後列から戦闘に参加できるようになる。アイスブランドが使いたくなるけど、ヤンもカインも冷気属性をつけられるので不要。単体のキマイラに遭遇すると全体攻撃を喰らうので、瀕死状態にして自動で庇うのはローザを除いた一人にしておくべき。つまり防御の低いヤンだけにしておく。案外HPが低いのでセシルとカインの無属性攻撃2発で倒せる。
  21. エブラーナ城で口封じの矢を拾う。本来は飛空艇を入手後すぐに来るべきだった。地下にある罠宝箱からバーサオーガが3体出るパターンはこの戦力ですら被ダメが凶悪だったが、バーサオーガは何故か魔法使い系統なので、ルーンの腕輪を装備したリディアとローザ2人で倒した。拾った口封じの矢も特攻。
  22. エブラーナの洞窟は炎属性と冷気属性の武器を切り替えるだけで簡単に攻略できる。
  23. 忍者エッジを加えてバブイルの塔に再突入。
  24. 今回は「霊騎士」が沢山出てきた。たいてい2体同時に出現する。拾ったミスリルナイフで1体を倒し、カインのジャンプでもう1体を倒す。ミスリルソードをこいつの為だけに購入するのは馬鹿げているからな。
  25. 火のルビカンテ戦。このリメイク版は炎のマントが本当に強い。マントが解除されている間も物理攻撃に対して全体ファイラのカウンターが来るので、ブリザラ、水遁の術がメイン攻撃という感じ。今回のレベルでは全体回復が200もでないため、アイスブランドの攻撃も加えると体力を維持できなかった。氷の槍でジャンプ攻撃を当てるのはダメージが釣り合うのでアリ。でもアイスシールドを装備できるカインはできるだけ火炎流のターゲットになって欲しいので、タイミングは計りたい。
  26. SFC版のルビカンテはまるで雑魚だったので、この改良は本当に素晴らしい！
  27. モンスター図鑑で再戦し、再現性も確認した。この攻略で特に問題なしだが、フェニ尾に頼り過ぎている気がする。そもそも100ギルは安すぎてほぼ回数制限なしのレイズと同じだ。このゲームはどう考えても道具屋を禁止してちょうどいいバランスに仕上がっていると思う。武器防具の購入を禁止するとさすがに面白くなくなるが、道具屋縛りはゲーム性の追求上必要とみた。
  28. クモの糸は有効だが、スロウは回避された。
  29. フェニ尾の利用が限られてくる場合、ワンパン確定の「火炎流」をどう対処するかが問題になってくる。レベル28前後なのでリフレクはまだ未収得だったか？ まあリフレクが効くのかどうかも知らないけど。
  30. 今週末はここまでかな。

22 December 2025

  1. いよいよ支障が！フィンランドの航空会社フィンエアーがつり目騒動の事業への悪影響を吐露。無関係の声明を出すも、CAからアジア人差別を受けたという過去の口コミが多数発見される - YouTube
  2. いま、フィンランドが熱い！
  3. こんな幼稚で未成熟な社会が存在したとは恐れ入る。個人レベルではどの国にもいるだろうけど、政党ぐるみとはね。
  4. 一番重要なのは、こういった差別的な言動が、いったい政治的にどういう意味を持つのかということだ。
  5. どういう方向で考えてみても、マイナスの側面しかない。政治的に非常に未熟であるということだ。
  6. 猿の惑星的なディストピア感が漂っている。

23 December 2025

  1. Amazon.co.jp: 魔の山（現代語訳） 電子書籍: トーマス・マン, 青空文子: Kindleストア
  2. Kindle Unlimitedで読める。
  3. Jintrickというハンドルの由来ともいえる小説。もう一度思索のヒントというか、思索の作法を思い出したいところだ。
  5. Surreal & The Sound Providers て何者だろ。これは聴ける。Jazz以外ではNujabes以来。ジャンル的にはJazzy Hip Hopとかなのか？知らんけど。
  6. Amazon Music退会日が遠のくなあ。Kindle Unlimitedもだけど。本や音楽との出会いの機会は確保しておいた方がいいかやっぱり。
  8. Amazon.co.jp : ハローコーヒー
  9. 毎月のように値上がりする珈琲豆。キロ3,000円が当たり前になってきたところで、もっと大量に仕入れることにした。
  10. ハローコーヒー。評判は悪くないようなので、ここを利用させてもらうことにするわ。キロ2,300円くらいで買える。
  11. 試しに500gっていうのもあるんで、コロンビアスプレモをポイントで買ってみた。
  13. 生成AIに何かを作らせる。何を作らせると確実に生産性が向上するか。
  14. その１。内製ツール。
  15. CP-SATのアプリケーションをカリッカリのドメイン駆動で作ってやった。Geminiのアプリケーション群の力を借りて。
  16. 1日がかりで行っていた処理が3秒で終わった。
  17. その２。研修資料。
  18. 生成AI利用ガイドラインを4月に書いた。参考資料を基にGeminiに書かせたんだけど。
  19. それをNotebookLMに食わせてスライドを作成させた。13ページのPDFのうち、12枚はそのまま使える程度のクオリティだった。
  20. Gemini CLIを使って、そのスライドをOCRにかけて原稿を用意し、スライド読み上げ原稿を13個のマークダウンファイルとして生成させた。
  21. さらに、その13個のマークダウンを、VOICEVOXにインポート可能なテキストファイルに変換してもらった。
  22. VOICEVOXでの音声ファイル作成は手作業。変な訛りがでるので修正して13個の音声ファイルを作成。
  23. Canvaを使ってPDFをPowerPointに変換。Powerpointマクロを使って13個の音声ファイルを各スライドに取り込む。
  24. mp4にエクスポートして動画化。
  25. GASを書いてもらってGoogleフォームでの研修アンケートを生成。ついでにスプレッドシートで修了者チェックができるようにしてもらった。
  26. 研修資料作成については作業工程に手作業を必須とするツールが挟まってしまうので、体感としては楽じゃなかった。でも慣れれば生産性は爆上がりだろう。
  27. VOICEVOXを使ったイントネーションの編集作業が一番大変かな。ツールを変えてみたいところだ。

26 December 2025

  1. Gemini の Gem。今は、大きく分けて2種類ある。ただのカスタムプロンプトと、Opal版。
  2. 後者はフローを厳密に定義できるだけでなく、独自のGUIを構築できるという。AIアプリを作る感覚に近づいた。
  3. 現在、Gemini 3と対話しながら内容を確認中。ここに書きながらまとめていこう。ハルシネーション前提の情報となる。
  4. 「無料ユーザーには提供されていない」（→嘘かも）
  5. 「Opalで作ったGemは、Googleドライブ内にファイルとして保存される」？？？（→嘘くさすぎる）
  6. はい、中止。
  7. Quickstart  |  Opal  |  Google for DevelopersこれをNotebookLMに食わせて、質問開始。
  8. というか実際触ってみた方が早かった。
  9. ポスター生成Gemを作らせてみたところ、だいたいわかってきた。
  10. ノード（ステップ）を作っていく。入力、生成、出力だ。ノーコードを標榜している。全てをプロンプトで制御するようになっている。
  11. 入力ステップはテキスト入力しかUIに選択肢はない。ただし必須にするかとかファイルアップロードを許可するかとかの選択はできる。
  12. 生成ステップにカスタムプロンプトを仕込んでいくわけだが、プロンプト入力欄で@と打つと他のノード（ステップ）の結果を参照できる。またツールも参照できるようだ。
  13. その中に、Code Executionなる謎ツールも含まれていたが、ドキュメントには記載がないらしく、NotebookLMに聞いても分からない。
  14. 試行錯誤した人のNoteが転がっていたので読んでみると、どうやらPythonライブラリを使えるらしいが、詳しくは分からない。
  15. Gemini 3 DeepResearchに調べさせた。
  16. ……んだけど、NotebookLMに調べさせて結果をインポートした方が速かった。同じDeepResearchだが、回答を生成しない分こちらの方が速いということか。
  17. 要するに、自律的にPythonコードを書き、それを実行して結果を得る機能らしい。
  18. Workspaceとの連携は、自然言語を使う。「結果をGoogleドキュメントに保存して」。
  19. 「Googleドライブにある『売上管理表』を読み込んで」と指示すれば、その瞬間の最新データを取得します。
  20. 生成ステップについて他に知っておくべきことがないか聞いてみた。
  21. プロンプト入力欄の近くにある「魔法の杖（キラキラ）アイコン」または「自動プロンプト改善ツール」を使うと、あなたが書いた短い指示を、AIが理解しやすい詳細なプロンプトに自動で書き換えてくれます
  22. @でツールやステップの選択ボックスを呼び出すことはできるが、選択しなければプロンプト内の文字としてそのまま使うこともできる。よってエスケープなどは不要。ノーコードツールとしての体裁を保っている。
  23. おっと。入力ステップにも@を使うことができるようだ。他の入力ステップの結果をユーザーへの質問文に埋め込んだり、ウェブ結果をもとに質問文を変えたりできるということか。
  24. 出力ステップは出力先をWebpage（自動レイアウト）、マニュアル、Google ドキュメント、スライド、スプレッドシートから選べる。マニュアルというのはテキストとのこと。WebpageというのはGemini Web上での表示ということだろう。ファイル形式を指定してドライブに保存というのはできないようで、画像を生成した場合Webpage一択かな。
  25. このくらいの規模ならNotebookLMが非常に輝く。有能なんてもんじゃないねこれは。本当に助かる。
  26. そしてOpalはノーコードツールとしてかなりのことができる。何ができて、何ができないのか。これを正しく理解すれば、かなりのことが自動化できるだろう。Google Workspace依存が深まるという副作用を伴って。
  27. 誠に残念ながら、今のところGoogle Apps Scriptとの連携はできない。したがってGoogleフォームとの連携ができない状態。このあたりは今後に期待したいところだ。
  28. Opalについて何となく掴んだイメージはこう。ある程度複雑な処理を必要とした一定の出力を得たいときに使うノーコードツール。ウェブ（検索結果、地図、天気、特定のウェブページ）、Google Workspace内のドキュメントを利用できる。明示してやればPythonコードだって書いてくれる。ただし何でもできるわけじゃない。Python のライブラリは固定されていて、その内容は公式には書かれていない。
  29. だから、これまでのGemが不要になったわけじゃない。これまでのGemはチャットを継続することができる。特に決まった出力が得たいわけじゃないときに役立つ、特定の役割を持たせたカスタムチャットみたいな立ち位置なので、同じGemといっても全くの別物と言っていいだろう。
  30. これ、混乱する人もいるかもね。

27 December 2025

  1. 今週もFF4 PR。
  2. モンスター図鑑からまたルビカンテ戦をやってみた。
  3. 平均レベル28のデータで戦う。よくわからないが装備や所持品などは最新のデータが引き継がれている。
  4. この戦闘にはFF4 PRの面白さがかなりつまっていると思うね。
  5. 炎のマント（バリア）が解けた瞬間を狙って、氷の槍でジャンプ（6,000pts.前後）、ブリザラ（3,000pts.強）、水遁（2,500pts.前後）の3つの攻撃をあてる。合計10,000pts強かな。HPは35,000くらいあるらしい。
  6. セシルとローザは後列で回復担当。暇なときはスロウかクモの糸を使用。セシルはフル聖騎士装備で後列に下げる。
  7. バリアを解いた次のタイミングで火炎流がくる。耐えられるのはアイスシールドを装備できるセシルとカインだけだが、カインのジャンプがメイン攻撃なので盾にできない。つまり75%の確率で誰か一人戦闘不能になる。
  8. ターゲットがローザ以外ならセシルとローザの2人で完全に立て直せるので、問題はローザが戦闘不能になるパターン。この時はフェニ尾を使うしかないが、下手なタイミングでフェニ尾が発動するとカインのジャンプが当たったカウンターのファイラで再び戦闘不能になる可能性がある。
  9. 安全にいくならエッジが待機してフェニ尾を使えるようにしておくべき。素早いので次のターンの水遁がもしかしたら間に合うかも。

29 December 2025

  1. 正月休みを息子氏と三國志９で遊ぶため、準備を進める。
  2. 15年前に自作した在野武将発見アプリを発掘。Javascript 1.7で書かれていたので最新ブラウザでは動かなかった。主にfor each文がネックだったので生成AIに整形してもらったら、動くようになった。
  3. 武将データには著作権がありそうなので公開はできない。CSVをどこから持ってきたのかは覚えていないが、資料を見て自作した記憶はない。
  4. 色々な検証をやってみた。
  5. 混乱、罠といった謀略系兵法が発動すると他の攻撃系の兵法が連鎖することが多く、戦況がひっくり返る。
  6. 混乱は施設に対しても効くので、籠城戦を消耗戦にしないために必須。一方罠は施設にこそ効かないものの対部隊に対しては割合ダメージなので、大部隊に対して強い。追加で混乱することもあり、さらに追い打ちの攻撃系兵法が加わると、1回で兵1万ほどの損害を与えることもできる。
  7. とても奥深く面白い反面、CPUの癖を見抜くと作業化してしまうことが容易に想像できる。
  8. 試しにシナリオ3の呂布で開始してみた。陳留に24,000。配下にも恵まれている。目下の敵は曹操。濮陽に39,000。26名もの武将がここに閉じ込められている。
  9. 魏続におとり部隊を率いさせて曹操軍を引きずり出し、自勢力圏内までおびき寄せたころに、呂布、張遼、高順を3部隊に分けて鋒矢の陣で出撃。ダメ押しに突破をもった3バカトリオを一つの部隊にまとめて、計4部隊を送りだした。呂布が4,500、張遼が3,300、高順がクリティカルで6,000、３バカ部隊が3連鎖で2,600の損害を与えた。結果、曹操隊24,000は10日持たずに消滅してしまった。消滅しない程度の兵士数で小分けした多部隊を出撃させて短期決戦を仕掛けるのが、最上策とみた。
  10. その後、ボロボロの洛陽に誰かが旗揚げしたので、一部混乱をセットした衝車3部隊で一気に落とした。衝車なのに、なぜか城兵に対しても攻撃力があるのが謎仕様。
  11. 部隊攻撃力の詳細は、情報で数値として見ることができる。11慣れした息子氏は、武力ではなく統率力だけが部隊攻撃力のパラメータになっていることに驚いていた。逆に俺は、攻撃系兵法のダメージが統率力ではなく武力に依存していることに驚いた。
  12. AIは防衛に多部隊を組みたがらない傾向にある。こちらの戦法を学習することもない。その虚を突くことで、ほとんどの状況を打破できそうだ。そうなってくると、やはり対人戦でこそシステムが活きるというもの。
  13. NotebookLMに9関連の情報をたくさん食わせて色々質問してみた。普通のチャットでGeminiに聞くよりはだいぶマシになった。チャット版Geminiが知力80の軍師だとしたら、NotebookLMは知力98の軍師といったところだろうか。信頼性は高いが確認は必須。
  14. このゲームを通じて、合理的な戦略を立てる訓練をさせたい。そのためには兵法の発動率について知る必要がある。
  15. ところが集めた資料にはほとんど書かれていない。施設兵法の発動率が10%、発動ルーレットが3日毎ということくらい。
  16. NotebookLMにFast Researchで調べさせた。
  17. 情報が出てこない。他の検索系AIにも調べさせたがなしのつぶて。
  18. 基本数値をリバースエンジニアリング的に調べるしかない。
  19. 兵士士気50、後列、方円の陣、熟練度ゼロを基準としてみるか。
  20. というかその前に、兵士士気が兵法発動率にどう影響しているかを先に調べたいところだな。
  21. 昨日息子氏と一緒に部隊攻撃力と兵士士気の関係について実験してみたところ、影響としては無視できる程度しかなくてガッカリしていたところだ。十分に低くすれば勝手に退却を始めるが、狙って下げるのも容易ではないし。……でも兵法発動率に影響するのなら、かなり重要なパラメータに格上げされる可能性があでてくる。
  22. 城兵の士気を限りなく下げるたら攻撃力/守備力どうなるかも検証してみたが、ほぼ影響がなくてこれもガッカリした。だが都市兵法の発動率と士気に関係があるのであれば罵声の意味も出てくるはずだ。城兵の士気は40くらいまでは少しずつ自動回復することも分かったので、士気40と100の時の発動率が重要だな。
  23. NotebookLMにまとめさせた限り、陣形、前中後列、地の利、高揚、熟練度、部隊武将数、教唆罠破の有無、このあたりが兵法発動率に影響するが、士気は直接関係ないとのこと。士気90以上で出陣すると高揚状態に入ることがあるらしい。「得意」という隠しパラメータはその兵法系統の熟練度が上がりやすくなるだけで、発動率には影響しないとのこと。まあそんなところかもね。

30 December 2025

  1. san9。少なくとも施設兵法に限れば、士気も弩兵熟練度もその発動率とは関係がなさそうだ。あっても気にしなくていい程度だろう。
  2. ただし弩兵熟練度は兵法の威力に関係することが分かった。
  3. 部隊兵法についても同じだろうとは思うが、こちらは士気が高くなり高揚状態に入ったときに発動率が30%上昇する。
  4. というわけで下馬評通り、積極的に罵声を選択する意味はないという結論に達した。
  5. 問題は施設兵法の発動率10%という数字の信ぴょう性だ。何度試してみても期待値が実験値より大幅に小さい。3日に1回の10%判定で初日も判定があるとすれば、10日で0.4回発動するというのが期待値だが、どう考えても2、3倍ある。5ターンを5回くらい試したが、必ず4～6回の発動があった。式と熟練度にも影響しないとすれば、基本の10%という数字、もしくは3日毎の判定という数字が間違っているとしか思われない。
  6. 体感ではおそらく20%くらいだ。この判定が1ターン10日に3～4回発生する。そう考えると、ちょうど期待値と実験値の差は納得できるくらい小さくなる。
  7. そもそも10%のソースはなんだ。
  8. どうやら中国のサイトらしい。怪しいもんだ。
  10. 【独自】「安倍首相、選挙支援に非常に喜んだ」旧統一教会、内部報告文書で言及 : 政治•社会 : ハンギョレ新聞
  11. 別に反社組織だろうとカルト教団だろうと、なんだっていいわけよ。問題の根源はそこじゃない。自民党がずーっと政権を握り続けていることに問題があるんだよ。
  12. 本当に簡単な話だよ。権力者が変わらないのなら、そいつに取り入ってパイプを作ろうというインセンティブは最大化するだろうが。パイプはどんどん太くなり強固になり、政治は腐敗していくわけだ。
  13. こんなにも簡単なことが分からないのが日本国民。多少痛みを伴っても政権交代を目指す政党を全力で応援すべきだったことは明らかだ。
  14. 頂きのものの民主主義なんだからしょうがない？ そんな次元じゃねえよ。知能がないレベル。
  15. そしてこういった間抜けな政治は日本だけのものじゃない。一つの国でさえまともに運営できない人類が、どうやって全球を管理するの？
  16. まったく知能が足りてない。
  17. 案の定環境からは搾取するばかりで、公共経済学の果実がまるで役立ってない。いつまで経っても近視眼的なポピュリズムから脱却できない。
  18. 自称ホモ・サピエンスによる支配は、災厄以外の何物でもない。
  19. 一刻も早く頭脳を入れ替えなければならん。肉体に思考を支配されてしまっている自称ホモ・サピエンスが多数決システムを採用している限り、全球の管理能力なんてかけらもないことは、火を見るよりも明らか。
  20. AIを論理的思考力を持ったと言えるくらいまでブラッシュアップしてもらいたい。民主主義に勝る体制がない以上、これだけが人類に残された唯一の希望だと思う。期待は小さいけど、ないよりゃましか。水と電力を浪費するというけれども、まあ仕方ないでしょ。
  22. そんなことよりsan9。探索が面倒くさい。
  23. だったらやらなきゃいいんだよ。埋もれた在野を発見する以外のお使いみたいな探索禁止。
  24. 内政も面倒くさい。
  25. だったら手抜きすりゃいいんだよ。最大値の3割だか4割だかを超えたら、内政禁止。

01 January 2026

  1. UWPアプリ（*.appx）の更新サービスが常駐するようになったらしい。Microsoft Storeは使わないので手動に変更した方がいいだろう。services.mscからの操作はできなかったのでレジストリ値を調べた。
  2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AppXSvc
  3. Startの値を3にすると手動にできる。
  4. また、DoSvcサービスがメモリリーク疑い。P2PでWindows Updateするサービスだが、必要な時だけでいいだろう。こちらは設定で無効にできる。
  5. Windows Update > 配信の最適化

03 January 2026

  1. 腰痛にやられた。今年は寝正月だな。
  2. san9。wsadキーでスクロールできるよう、Gemini 3にauto hot keyスクリプトを書いてもらった。
  3. 正直今まで生成AIを使っていて一番恩恵を感じたw
  4. ; ScrollLockがONの時だけ有効
#If GetKeyState("ScrollLock", "T")

w::JumpAndBack("top")
s::JumpAndBack("bottom")
a::JumpAndBack("left")
d::JumpAndBack("right")

#If ; 条件終了

JumpAndBack(direction) {
    ; 現在位置を保存
    MouseGetPos, prevX, prevY
    
    targetX := prevX
    targetY := prevY
    
    ; 画面サイズの取得
    SysGet, MonitorWorkArea, MonitorWorkArea
    
    if (direction = "top")
        targetY := 0
    else if (direction = "bottom")
        targetY := A_ScreenHeight
    else if (direction = "left")
        targetX := 0
    else if (direction = "right")
        targetX := A_ScreenWidth

    ; 移動（スピード0は瞬間移動）
    MouseMove, %targetX%, %targetY%, 0
    
    ; キーが離されるのを待つ
    StringLeft, key, A_ThisHotkey, 1
    KeyWait, %key%
    
    ; 元の位置に戻す
    MouseMove, %prevX%, %prevY%, 0
}

F4::ExitApp
  5. プロンプトは4往復させた。
  6. w/s/a/d キーを押したときに、マウスをそれぞれ画面を最上部、最下部、最右部、最左部に移動させたいんだけど、ソフトを使って。
  7. w/s/a/dキーを離したときにはポインターは元の位置に戻らなければならない
  8. 特定のゲーム時というより、任意で簡単に切り替えたいんだけど
  9. vmwareで実行しているwindows xp上で動作させたい
  10. たったこれだけで、Scroll Lockしているときだけwsadで大マップをスクロールさせるahkスクリプトの完成。おれは知識ゼロ。
  11. いやー快適だわ。これは息子氏も喜ぶかも！
  13. 箱根駅伝でモニタが占領されてVMWare機が使えないので、FF4を再開。
  14. 封印の洞窟は非常に楽ちん。アサルトドアーが弱体化していてキマイラブレインを吐き出さなくなった。しかも９ディメンジョンが来る前に倒せる。デモンズウォールも弱体化してるかも。手ごたえなし。バーサクとヘイストを使うだけで考えなしで勝てる。
  15. シルフの洞窟。
  16. 装備を整える。ミストの村で詩人の服を3つ、バロンの町でねじり鉢巻きを4つ揃え、全員に装備させる。リディアにはルビーの指輪も装備させる。臭い息で手詰まりにならないようにするわけだ。SFC版なら臭い息はルビーの指輪で完封できたのだが、それはそれでモルボルの恐怖が体験できずに面白くないから、これでいいと思う。
  17. この洞窟はモルボル×4との戦闘がすべてと言っていい。エッジの影縛り、リディアのトードで行動を封じる。ローザとセシルはエスナを急ぐ。4体全部の行動を封じたら、反撃に転じて終了。
  19. 幻獣の洞窟。
  20. セシルは後列。
  21. ブラックナイト＆インプのパターンはサイレス後にトードでほぼ完封。口封じの矢が使い放題なのでインプもどんどん狩れる。なんならセシルも弓矢を装備で良いかもしれないね。
  22. ベフェゴールからの被ダメすら700くらいあるので、この洞窟内はセシル以外瀕死状態を維持しておいた方が安定する。
  23. アスラとリヴァイアサンは弱体化しているので特に問題なし。アスラはリフレクとセシルのディフェンスで完封できるくらい弱いし、リヴァイアサンの大津波はケアルダで完全に回復できる。これは残念。
  24. リフレクを覚える前に到達したいところだ。

04 January 2026

  1. FF4 PR、バブイルの巨人内部。
  2. エクスカリバーを持ってくるのを忘れたけど、後列だと命中率が下がるPRにはほとんど影響はなかった。ドワーフの斧の方が安定する。大したソースにならないので、今回はディフェンダーを装備したところ、さらに安定した。
  3. できるだけ最初につぶしておくべきなのは、機械砲。ビームで最大HPの10%のダメージなので、瀕死状態の仲間が死ぬ。
  4. マシン種族は雷の矢、雷の爪、天使の矢、妖精の爪あたりが特攻。オーガキラーやポイズンアクスは後列に下げたセシルでは当てられない。全体に弱いサンダーをかけると機械兵が一瞬暴走してくれるのが面白い。
  5. 今回フースーヤには戦闘不能になってもらい、リディアの経験値を稼いだ。
  6. 月の中心核。
  7. 白竜。物理攻撃にはカウンターのスロウ、召喚魔法にカウンターの地震がくるので、リディアのリヴァイアサンをメインのダメージ源とし、リディアにリフレク。たまに来るミールストームを回復させるためにローザは待機させる。これでほぼ完封。
  8. 今週はここまでかな。
  10. san9。戦略画面の音をおおむねsan6のものに変更した。似たコンセプトだけあってそこそこマッチするように思える。交戦状態のBGMだけは適当なものがなかったので変えていない。
  11. 息子氏と対戦プレイするまでには至らず、お互いのプレイを鑑賞する感じで正月休みが終わった。途中検証などをまぜながら、かなりの部分を理解できたと思う。
  12. s3の呂布でプレイ。劉備と共同して袁紹を北海に追い詰めた。付近の港に軍を寄せて楼船で陽動部隊を遠回りに出撃させたりと色々準備していたところ、劉備軍が先に侵攻を開始してしまったため、不本意ながら横取りするような形を目指すことになった。
  13. 城が落ちる寸前に錐行の陣を多部隊出撃させ、実験。
  14. 最初は先着した呂布の飛射が当たって一撃で陥落。北海は劉備のものとなる。
  15. 2回目は他の部隊も城に張り付いた状態で削って陥落。北海は呂布のものとなった。
  16. 張り付いている部隊数で所有者が決まるのではないか、という仮説に至った。少なくとも貢献度でもなければ、最初に張り付いたか否かでもないことは分かった。
  17. 息子氏の方はs2の孫堅。あっという間に大陸を制していて、主に倭という蛮族の攻略に時間を費やしていた。好相性の5人で組んだ闘艦で出撃して、兵法（教攻）の連鎖を倭の部隊に当てて地道に兵を減らす戦術だ。なかなか有効にみえたというか、それ以外の攻略を俺は思いつかない。
  18. その他の蛮族は兵器を使って城を破壊したり、短期間で一気に兵を減らしたり、色々やっていた。まあ結構うまく行っていたのではないだろうか。2～3ターン（1か月）で終わらせていた。

05 January 2026

  1. 生豆の値上がりが嫌なのでハローコーヒーというところで、お試し用500gのコロンビアスプレモを買った。
  2. ……不味い。焙煎が失敗しているとも思われない。それなりに経験を積んでいて焼きムラはかなり少なく仕上げたし、水分もしっかり飛ばしたつもりだ。
  3. だが不味い。いやな苦みがある。シティロースト寸前くらいなのにこの苦みはおかしい。
  4. スピンさせて粉をフラットにしたので過抽出になったのかもしれない。
  5. スピンをやめて、古典的な方法で抽出してみた。
  6. 嫌な苦みは軽減したが、消えない。これは苦みとは違うかもしれない。いやな酸味といった方がいいのかも。完全に地雷だね。4kg買う前にお試しにしておいて良かった。
  7. 残りの半分はフレンチローストにしよっと。

06 January 2026

  1. 昨日不味かったハローコーヒーのコロンビアスプレモの嫌な苦み。今日はスピンでフラットベッドにして抽出したのに、それほどでもなかった。
  2. 欠点豆の混入率の問題だろうか。
  3. 美味くないことに変わりはない。
  5. 減量開始。正月太りしたかどうかは、体重を測っていないのでよく分からないが、63kgはないと思われる。糖質依存症的な症状は全く出ていないどころか、日中は全く食べたくない。
  6. もう、体重計の乗るのはやめた。面倒くさい。時間の無駄。やるべきことをやっていればどれくらい減るかは分かっているし、やるべきこと以上のことはできないことも分かっている。腹をつまんでみれば、適正体重になっているかどうかはわかる。
  7. 糖質の摂取量やタイミングの管理を着実にやれれば適正体重になるんだし、それ以上の減量は無意味だ。
  8. 問題はその「着実に」ってところだな。現在の体重や体脂肪率を知ったところで、関係なさげ。
  9. これまでに確立してきた方法というものがある。
  10. まず午前中の似非食欲は、単に胃が動き出しているだけで別に何かを食いたいわけじゃないことが明らかになっている。これは実は「食え」というサインじゃない。本質的には「食いものを得るための活動を開始しろ」というサインなのだ。仕事を始める準備が整ったと考えればよい。胃部不快を感じたら軽くマッサージするか、温かい飲み物を飲むか、ナッツを少量つまむだけで完全に対処できる。つまり朝食は摂る必要なし。
  11. 朝激しくトレーニングした後は意識的に糖質を摂取していたが、これはやめる。脂質代謝が優位になれば無意味化できる。
  12. 昼食ではこれまで通り、スープジャーに入れた糖質制限食を摂る。去年までは鶏肉も持って行って3時以降腹が減ったときに食べていたが、これも特に必要ないかもしれない。最近は食べるのを忘れてしまうことがあるくらいだ。
  13. と思ったけどタンパク質不足のフォールバックとして継続する。
  14. 夕食は「社会的な食事」なので、出されたものを普通に食べるが、春からは夕食hackを実施する。これも個人的に確立された方法だが、職場に弁当形式で夕食を持っていき、帰宅後は食べないで済ませる。これは減量を加速するので減り過ぎに注意しなければならない。すなわち体重計が必要になる。
  15. つまり体重計というのは、減量の仕上げを行う時に、体重が減り過ぎていないかどうかを確認するために使うものだな。体脂肪率7%を下回ってしまったら調整する必要がある。
  17. 減量とトレーニングは両輪。並行してトレーニングも開始する。
  18. この時期なのでベースを作る。300～500km/週くらいは乗る。70～80%HRMaxをキープ。
  19. 行き60km、帰り30kmのコースを週のうち3日使えば270km、残りの2日は買い物だのなんだので合計60kmくらいかな。330km。土日のどちらかで山錬に行けば500km行くか行かないかくらいになる。
  20. ただし週1でスプリントレベルの高強度をやる。気分が乗った日でいい。乗らなければ金曜にやる。速筋が死んでしまわないようにするわけだ。
  21. ベース期間中、閾値下心拍の下限で維持できるパワーを上げられるだけ上げる。目標なんて要らない。これを6～7週間。2月の第2週までやるだけだ。
  22. 今朝は150bpmをキープするには200wくらいが限界だった。夏と比べて30w近く落ちている。寝正月していたとはいえ、ここまで衰えたのは想定外。やっぱり歳なんだろう。
  23. ベースができあがったら、5月まで閾値～VO2maxのトレーニング。徐々にVO2maxトレーニングの質と量を上げる。ベースは週1、スプリントは週0.5の頻度に落としつつね。
  24. CTLの管理なんて要らない。つまりTSSなんて一切気にしなくて良い。そんな数字に踊らされていると逆に体調を崩しかねない。もう歳なんだから毎年適切なCTLは下がってくるはず。つまり自分の身体に聞くのが一番だ。
  25. FTP測定。要らない。その日の調子が結果に響くので、間違った数字に躍らされる可能性大。それより心拍数を見る。閾値心拍におけるパワーの平均値を求めたほうがずっとリアル。
  26. あとは調子を整えながらレース参戦。5, 6, 8, 9, 10月かな。
  28. Electronアプリの開発にとりかかる。Gemini CLI + Julesのタッグでどこまでやれるかな。
  29. 複雑化したconfig.ymlファイルの編集ソフトを作らせる。Gemini CLIだけで基本の骨格はできたな。
  30. なにやら俺もよく知らん開発環境をサクサク構築してくれた。ローカルサーバーを動かして何かしているらしく、コードを更新すると即座にGUIアプリが更新される。これは開発捗るわな。ビジネスモデルをPythonで書いているのでそこの連携が若干弱めだが、補って余りあるメリットだわ。基本的なGUI部品は整っているし、アイコンセットまで用意されてる。
  31. こんな感じでいくらでもアプリ作ってくれそうな気がしてくる。多分気のせいだろうけど。一度San9の在野武将一覧アプリを、Electronでリメイクさせてみるか。Javascript＋HTML＋CSSで完成させてあるから、もうそれらを渡して適当に指示するだけで完成形まで持っていってくれそう。
  33. 最近、Gemini 3 Proの応答が遅い。午前中はいいんだが、14:00を過ぎると渋滞が発生することが増えてきた気がする。無課金ユーザーの制限をもっときつめにしていいと思う。AnthropicとOpen AIも頑張ってシェアを広げて欲しいところ。

07 January 2026

  1. 寝坊した。雪も降ってた。今朝はミニベロで15kmコースをだらだら走っただけで終わった。トレーニング開始初日でもう躓いた。
  2. 駐輪場で「早いですね」と声を掛けられた。寝坊したのでギリギリでついたのだが。
  3. そうじゃなかった。「速いですね」という意味だった。だらだら走ったので何のことだか分からなかった。
  4. 「坂であっという間に消えました」
  5. 坂だけはダンシングしたんだった。
  7. Gemini CLIのコンテクスト消費量が表示されなくなって久しいが、Gemini 3になってからコンテクスト汚染と思われる劣化を感じにくくなった。
  8. 日本人のジャズピアニストがたまにお勧めに出てくるんだけど、肩の力が抜けていない必死な感じで何かやだ。カッコいいでしょ的な感じが凄くやだ。技術のお披露目会みたいな曲ばかり。
  9. しつこいがハローコーヒーのコロンビアスプレモ。今日はかなり美味しく淹れることができた。どうやらドリップ技術が上がったっぽい。怪我の功名ってやつだね。
  10. コーヒー粉に湯を注ぐ「高さ」がコーヒーの抽出効率と風味に大きく影響する - GIGAZINE
  11. 春に読んだこの記事。やってみたら注ぐ音が汚らしくなってしまって敬遠していたのだが、そうもいっていられないということで取り入れてみた。
  12. 確かに抽出率は上がると思う。もう間違いないと言いたくなるくらいの違いを感じる。抽出率が高い場合、ドリップが鈍くなってきたらすぐにドリッパーを引き上げれば過抽出を抑えつつ十分な量を落とすことができるという寸法だ。
  13. これにスピンも加えれば完璧。
  14. まあそれでもこの豆は若干変な味があって違和感を覚える。
  15. 今朝、2回目の焙煎を行ってみた。フレンチローストにするつもりがシティローストになってしまった。これではあまり変わらないではないか。
  16. 火力が弱すぎたみたい。1爆ぜも2爆ぜも、なかなか始まらなかった。難しいもんだな。
  17. amazonのポイントキャンペーンのためにあと3000円分くらい何かを買わなければならないのだが、1時間くらいウロウロしても何もほしいものが見つからない。必要なものはあるが在庫コストを考えると適切ではない。困った。
  18. 結局消耗品を買った。ショップタオルと眼鏡拭き。
  20. JulesちゃんにElectronアプリの開発を手伝ってもらうことにした。環境構築ができるかどうかちょっと心配。
  21. Jules、沈黙（笑）。どうやら荷が重いようだ。だが時間をかけて何とか実装してくれた。レビューさせたが問題なかった。やったね。
  22. それにしてもElectron + ViteのGUI開発体験は中々に良好。コードの変更に同期するような形で爆速の開発用ビルドが行われる。Devtools的なものが使えて、そいつをGeminiが操作できればまあ完璧と言っていいだろう。どうやって環境を構築するんだろ。
  24. Gemini 3によると、ViteはWebpackやNext.jsなどと比べても設定がシンプルかつ強力でこれ以上ない選択肢らしい。
  25. ツールが出力したUTF-8のバイト列を、Gemini CLIのrun_shell_commandツールがOSデフォルトの文字コードとしてデコードしようとするため、WindowsのシステムロケールをUTF-8にしない限り、コンソールの文字化け問題は本質的に解消しない。自作ツールなら出力をCP932にすれば回避できるが、自作ツールだけではないからな。
  26. そして、VBAプロジェクトという負の遺産をすべて処分しない限り、システムロケールをUTF-8に変更することはできない。
  27. 今年はこの「処分」を目標に据えようかな。

08 January 2026

  1. なんかようわからんが、Gemini CLIだけでもQuotaを全く使いきれんようになった。Gemini 3になってからとても長持ちする。autoで適宜flashを使ってくれているからかな。
  2. とりあえずフロントエンド開発にJulesを使う必要はなさそう。ビジネスモデルだけで良さげ。
  4. なんか、「宇宙が人間に都合よく出来過ぎてる！」みたいな動画がお勧めに出てくるんだけど、確率論的に自然発生があり得ないのだとして、じゃあ、自然発生でないとしたら、何らかの知的な意志の力が介在するということになる。その確率は？？その「意志」の発生母体について全く同じようなループが発生するだろうな。

09 January 2026

  1. フロントエンドの構造が肥大化してきた。
  2. 一つのissueの解決でGemini 3 proのquotaを15%～20%くらい消費するようになってしまった。
  3. やはりJulesの力を借りることにしよう。
  4. スラッシュコマンドがやや増えてきたので、GUI開発のサイクルをメモっておこう。
  5. まず /init 開発ブランチ名でAIを初期化する。
  6. Issueを作らせる。
  7. GUI開発でJulesに頼らない場合は、npm run devしておき、Gemini CLIによる実装が終わったら/gui_testでnpm testを実行させ、結果をまとめさせる。これは別プロセスで起動したGemini 3 Flashにやらせる。
  8. Julesに頼る場合は、/branch 開発ブランチ名でリモートにプッシュしつつ追跡を設定。
  9. Julesを起動して上記ブランチ上でIssueを読ませ、作業させる。
  10. JulesでView PRをクリックし、手動でマージする。Julesが作った作業ブランチは手動で削除。クリック2回だけなので我慢。
  11. /review Issue番号でレビューさせる。

10 January 2026

  1. 週末FF4 PR
  2. ダークバハムート戦1回目。
  3. 開幕ダメージ全員2800前後。セシル以外先頭不能で戦意喪失。終了。
  4. よく考えてみたらバハムートさえ取りに行ってなかった。ホーリーランスを入手後、テレポでバハムートの洞窟へ急ぐ。
  5. バハムート戦。
  6. 案外リフレクが間に合ってしまう。初回のメガフレアをカインはジャンプで避けるようにし、一人だけ光のカーテンを使えば、リフレクが全員間に合う。
  7. HPが低めなのであっという間に終了。バハムートはデフォルトでリフレクがかかっていた。バイオの反射でリディアのみ戦闘不能。

11 January 2026

  1. FF4 PR
  2. ダークバハムート戦2回目
  3. 開幕ダメージは1000～3000。セシルとリディアが生き残った。2人生き残ればまあ立て直せる。これは運ゲーかもしれない。
  4. その後の攻撃は、デルタアタックのフレアしかしてこない。ただし召喚魔法にはカウンターのメガフレアがある。
  5. ダークバハムートはバハムートと違ってドラゴン種族になるらしい。そこでアルテミスの矢。ローザは回復で手いっぱいなので、リディアにミネルバビスチェ、アルテミスの矢、与一の弓を装備させ、バッカスの酒でバーサク状態にする。これが一番のダメージソースとなる。驚異のダメージ9000越えを見た。ねじり鉢巻きあたりも装備させると良かったかも。
  6. アルテミスの矢が余っていれば、立て直しが終わった後セシルにも装備させるとさらに安定。
  7. リディアのレベルは50。まだフレアを覚えていない。

13 January 2026

  1. FF4 PR
  2. 月の地下渓谷最深部付近。
  3. フェイズは悲惨な弱体化。リフレクをディスペルで打ち消せるようになったのに行動が変わらないので、ただのサンドバッグ。
  4. ベヒーモスは前列で対応できるようになる。ただしセシルの回避率は95%くらいにしないとダメ。守りの指輪、ドラゴンシールド、リボン、黒帯道着を装備させた。クリスタル装備が一つもないのが悲しい。
  5. 前回はここらへんでリディアのHPが2,500になるまでちょっとだけレベル上げをしたんだけど、ゼロムス戦からリディアを外した方が攻略難易度が下がるのであれば、これは必要ないということになる。悲しいけど考えられる検証は全部やった上での結論。
  6. 画竜点睛を欠くとはこのことか。
  8. エルモ・ホープ・トリオ
  9. ボビー・ティモンズ
  11. 不味い珈琲豆をどうやっておいしく淹れるか。
  12. 沸騰したお湯に10%の水道水を加える、というのをやってみた。85℃くらいになるらしい。
  13. 確かに雑味が減った。抽出時間で調整しているつもりだったけど、高温のお湯だと蒸らす段階で雑味がでてしまうのかもしれない。

14 January 2026

  1. Gemini CLIにissueを書かせるというのをずっとやっているが、ガイドラインを遵守するようカスタムスラッシュコマンドで指示してある。
  2. 完成したissueを、もう一度ガイドラインに準拠しているか確認させるといいだろう。質が上がる。
  3. /resumeスラッシュコマンド神。間違えて閉じたセッションが復活した。

15 January 2026

  1. Gemini CLIがコーディングしている間、何をしているべきか。
  2. 別の仕事をしていると、Geminiに何をさせていたのかを忘れてしまいがち。そしてしんどい。
  3. どうせすぐに終わるので腰痛対策の筋トレをしていればいいのかも。
  4. Gemini 3に相談したら、シングルレッグデッドリフトについて教えてくれた。ソースも読んでやってみたけど、なかなかいいと思う。骨盤がぐらぐらするのでこれを支えようとする筋力を鍛えられそう。まさに俺が求めていた動きだわこれ。
  6. GUIアプリ内にターミナルを作ってGemini CLIに居座ってもらい、IPC通信で操作させるという構想をGemni CLIに話したら、なんかすげーノリノリになってくれてるんですけどw
  7. 何をどう学習させるとこういう反応になるんだろ。
  8. まあたしかに次世代アプリ感あるし、俺も「ノリノリ」ではあるんだが。
  9. これを自分のGUIアプリ開発の得意パターンにしてポートフォリオとして残していけば、転職の圧力にも耐えられるかな。どう転んでも食っていけそう。それくらいの可能性は感じるよね。
  10. 試験的な実装を考えていたけど、今日は議論だけにしておこう。なんかGeminiの理解が追い付いてないっぽい。
  11. UIコンポーネントの中にロジックが書かれてしまっている現状に全然違和感を覚えていないみたいだし。
  12. Headlessな（抽象的な）ロジックが主で、UIは従でなければならん。じゃないとAIはUIを経由しないとロジックに触れないことになる。
  13. これまでReact界隈で「正義」とされてきた「ロジックとUIの結合（Co-location）」は、「人間がコードを読む都合」 に最適化されたものでした。だろ？ そのCo-locationとやらに引きずられている限り、アプリは変な方向に転がっていってしまうと思うね。
  14. だが俺のRact周りの知識も脆いので、Co-locationについて調べてみる。
  15. 密結合の話じゃないやんかこれ。ただの物理的な配置の話で、取るに足らない概念。
  16. で、Context vs Storeという論点に行きついた。
  17. Zustandを使おう。
  18. Storeパターンを使ってReact - Zustand - Gemini と連携しやすくしておく。
  19. Co-locationとやらはHeadlessアーキテクチャを両立させる。
  20. こえええーーー。spawnで起動したgeminiが勝手に何かし始めたw
  21. いや草はやしてる場合じゃない。開発ディレクトリで開始されたからgemini.mdとかを読みに行ったとしても、起動直後に何か勝手に始めるのは怖いよ。
  22. CWDを明確に安全な位置にしておかないと何されるか分からん。これは怖いわ。

16 January 2026

  1. SDKをインストールすることにした。npm install @google/genai
  2. 使えるモデルはどうなってんだろ。実際試してみるのが一番。
  3. とりあえず自作のElectronアプリ内でチャットを疎通させるところまでは完成。本来はGeminiがAPIをきちんと叩けるか確認するのが先決だが、やっぱりモデルが気になる。とりあえずgemini-2.5-flashは使えるようだが、gemini-3-flash-previewはどうかな。Gemini Webに聞いたら-preview要らんと言われたんだが、幻覚やった。上手い嘘つくもんだよホント。
  4. 使えた。
  5. システムプロンプトをハードコードされてたので外部化のissueを書いたところで、gemini-3-pro-previewの使用量残り5%。今週はここまでにしておこう。
  6. 明日は都民の森に仲間と走りに行くんだが、それと同じくらい仕事をしていたい。天秤がかなり釣り合ってしまっている。
  7. Gemini webの方に「answer now（さっさと答えろ）」ボタンができててワロタ

18 January 2026

  1. FF4 PR ゼロムス戦
  2. クモの糸を使った反射フレアでリディアが戦闘不能になる。
  3. リディアは蘇生させず、そのまま、「投げる」「ジャンプ」「戦う（ラグナロク）」「ケアルガ」だけで楽勝だった。
  4. あれだけ活躍してきたキャラの最後がこれとはね。
  5. こいつはラスボスにふさわしくない。
  6. ほとんどビッグバーンしかしてこないのは何なんだ。魔法はすべてカウンターしてくるので攻撃魔法は使えない。直接攻撃もないのでセシルの存在価値すら危うい。
  7. 10万ほどあるHPの6割7割くらいをエッジが削り、ビッグバーンのダメージをローザが一人で回復させ続けただけ。完全な作業だねこれは。
  8. 下手をするとローザが一撃で死んでしまうので、その時に備えてセシルかカインどちらかが居ればいい。すると3人パーティとなり、ケアルガで毎ターン完全回復できる。

19 January 2026

  1. Gemini CLI。Reactコンポーネントにロジックをべた書きされてしまっていた。components_guidline.mdにちゃんと書いたはずだったんだが、アプリの思想を全然理解できていなかったってことかな。
  2. やはりissueにガイドラインの参照を書いただけでは全く足りない。実装後に/reviewみたいなカスタムスラッシュコマンドでガイドライン順守についてのチェックをさせなければだめ。最近サボってた。Gemini 3になってから信頼度が上がったと思っていたけど、やはりまだ抜けは多い。
  3. electlon/以下を更新すると、毎回大量のビルドエラーを発生させるのも、なんか学ばねえ感じがしてイラつく。これはイラつくとかいう次元の話ではなく、quotaの無駄遣いになるので、何とかした方がいいだろう。
  4. 最近、「プログラミング経験ゼロでもDDDできる！」みたいな記事を読んだ。見出しも思い出したくないからリンクはできないが、ぶっ飛ばしたくなるよ笑 ろくなissueも定義できないだろうし、AGENTS.mdだって書けないはずだし、テストだってできないだろうし、そもそもCI/CD環境も構築できまい。エッジケースの想定も無理だろ。ちょっと指示をミスるとGemini 3ですら暴走を始めるが、暴走してんだか何だかわからないだろう。
  5. 一体全体、どんなアプリを作れるっていうんだよ。単純なマクロ作業を定義してイベント登録してGUI経由で発火できるようにしただけか、せいぜいそういうもの詰め合わせだろどうせ。
  6. なんかあるとすぐ「プログラマが不要になった！」とか言い出すのホント腹立つなアレ。いや素人が言い出しているならいいんだよ。現職が言うか？？？馬鹿なの？？？
  8. 息子氏と三國志９を遊ぶためにローカルルールを考案中。
  9. まず抜擢武将だが、こいつらはちょっと強くなりすぎるので師匠の選び方に制限を設ける。習得兵法数の最も少ない武将を、抜擢武将の師匠にする。それでも中堅以上の武将に育ってしまうことが多いが、OFFにはできないので仕方なし。
  10. つづいて作業時間の短縮のため、人材登用コマンドを禁止する。捕虜を含め、登用したい場合は委任軍団に任せる。追放と処断は自由。
  11. また本国での探索も禁止する。探索したい場合は委任軍団に任せる形で行う。
  12. とりあえずこんなところかなあ。
  14. というか、ガイドラインに書いているにもかかわらず、コンポーネント内に操作ロジックをべた書きされてしまうのは、世の中のコードがそんなんばっかりだってことか？
  15. Electronなんてウェブアプリ作るような層が好んで選択するもんじゃなかったの？
  16. 謎過ぎるだろ。

20 January 2026

  1. 日本が貧乏になった「真犯人」はコイツだ。給料が30年も上がらない残酷な理由【ゆっくり解説】 - YouTube
  2. 一番大事なのが抜けてるな。真犯人は労働組合だ。内部留保を貯め込む企業に対して賃上げを要求し、ストライキを敢行するという当たり前の活動をろくにやってこなかった。そして根本原因は、労働組合がその「当たり前の活動」を行えない理由にある。こちらは複雑系。
  3. 生存戦略についても大事なのが抜けてるな。個人で生き抜きたいのであれば、経済への依存度を下げればいい。最も現実的なのは、他人の労力や資源に頼らない趣味を見つけること。たとえば自炊を趣味にするのも悪くない。そして自由市場によって捏造された需要に惑わされないことだ。
  4. 全国民がこんなマインドになったら、とんでもないことになるけどね。

22 January 2026

  1. Agent Skills | Gemini CLI
  2. こいつをGemini CLIに読ませたいんだが、やはりリポジトリのクローンでmdファイルとしてまとめて取得するのが一番の近道らしい。
  4. 胃部不快を伴う空腹感には波があって、その刹那を乗り越えると楽になる。これは「何か食べないと体重を減らすぞ！」という警告だと思うとほほえましい。

23 January 2026

  1. トヨタ完全勝利は罠だった？EV崩壊の裏で進む日本経済の危機【ゆっくり解説】 - YouTube
  2. おいおい……誰だよこのゆっくり動画作ってるの。院生とかかな。いや生成AIも活用していけば本業があってもいけるか。ともかく、そこらのアホ動画とは一線を画している。これなら息子氏に勧めても安心だな。
  3. 国のレベルの話になると99.9%くらいの確率できしょいバイアスまみれの動画しかないと思っていたけど、このレベルなら自信を持って勧められるわ。
  4. 生成AIで玉石混交の度合いはさらに高まり実際石が大量に増えたわけだが、より輝く玉が生まれるのもまた必然。要するにちゃんと探せばいいんだよ。
  6. はー。今日のタスクはQuota残り3%のところでギリギリ終わった。
  7. Reactのドラッグドロップ用コンポーネントって、ファイルのフルパスを受け渡すのに使いにくいんだな。よく考えてみれば当然の挙動ではある。結局自作する羽目になってしまって、思ったより手こずった。
  8. それにしても世の中、運命の鎖に縛られてがんじがらめになっている人があまりにも多すぎる。
  9. 断ち切れる鎖は結構多いんだけどな。
  10. チームみらい・安野党首「我々はほぼ唯一消費税減税に慎重な立場」「消費税減税より社会保険料減額が優先」その理由とは | 政治 | ABEMA TIMES | アベマタイムズ
  11. うん、この「理由」についてはしっかりと議論しておきたいところだね。消費税がいかに優れた租税であるか。社会保障費の定額減税と合わせることで、どれだけ格差を是正する結果に至るか。きちんと論理的に説明しておこう。息子氏にね。
  12. 念のため想定される反論についても事前にGemini 3を使って検討しておこう。経済学的な視点では死角はないと思うが、別の分野で何かあるかもしれない。知らんけど。
  13. 適当に議論してみたけど、反論らしい反論はでてこなかった。結局論点は定額給付額と消費税率のバランスに行きつくな。15%かつ月額1万円の定額給付なら、財政は現状維持らしい。
  14. チームみらいは社会保険料の減額を持ってきている。財源の話がない。そこは消費税増税分を財源にしないとだめだろうね。それを言い出せないところに、残念ながら限界を見てしまったよ。
  15. 理論的には問題なしときたら、あとは世論の問題が残るだけ。ポピュリズムとの戦いだな。ポピュリズムの定義については議論済みだが、要するに目に見えて肌で感じることのできる利害感情のことだ。これに属する人々をどう説き伏せるかという問題だが、説き伏せることが不可能なのが真のポピュリズムであるとすれば、最終的には騙すしかない。すると、どう騙すかというのが最大の論点になる。
  16. 論理だけを議論していると、専門馬鹿と同じになってしまうから、嫌でもここまで踏み込んだ議論が必要なのだ。
  18. 去年の暮れに編み出した布団の中でできる腰痛予防体操のおかげで、今ものすごく体調が良い。
  19. クラムシェルに近い動きを布団の重さで負荷をかけてやるだけ。ただし骨盤をしっかり安定させるイメージを持ちながらやらないと逆効果になる。「エア腰痛ベルト」を着用しているイメージでやる。
  20. とにかく臥床時の腰痛がほぼゼロになったものだから、それが原因で夜中に目が覚めることがなくなった。これまでは8割くらいの確率で深夜に一度目が覚めていたのだが、このところ週に1回あるかないかまで減った。その1回も、別に腰痛で起きているわけではないからすぐに再入眠できる。
  21. ただ、自転車に乗っているときの腰痛はまた別の問題だったらしく、こちらは筋トレの導入やペダリングを含めた乗車方法の見直しを行ったところだ。
  22. 今のところかなり良好な手ごたえがある。
  23. 仮定している原因は、ペダリング中の骨盤のずれ。去年は高強度トレーニングをほとんどしてこなかったので体幹の筋力が弱まり、ペダリング中に骨盤が動きまくるようになっていたようだ。
  24. とりあえずシングルレッグデッドリフトというのを取り入れて筋トレを始め、またペダリング中にはもう体幹だけに意識を集中するようにしてみた。骨盤をかっちり固定。
  25. 向かい風で無理にトルクをかけているときだけは、どうしても腰痛が出る。なぜだろう。Gemini 3に回答させてみた。
  26. 風の抵抗で上半身が起こされる。それに抵抗しようとして体幹の力が使われ、骨盤の安定が揺らぐ、という意見を引き出せた。これは仮定として面白い。
  27. だとすると、向かい風の中ではTT的なポジションが合理的だろう。TTポジションで腰痛の出ない方法については知見を得ておいた方がいいな。
  28. 前乗りがいいらしい。まあそうなるよな。
  29. SLDLでの応用: 今行っているSLDLの際、上半身を倒しながら**「膝をほんの数ミリ外に向ける」**感覚を試してみてください。より深く倒しても腰が楽になるポイントが見つかるはずです。
  31. これまでさんざん作ってきたVBAアプリの集大成みたいなデータクラス（SchemaEntity）ができた。こいつを使えばフォームとデータベースと帳票を横断するEntityをExcelのシートにスキーマを書くだけで使える。
  32. って書いている間にきづいた。Excelのシートだけじゃなくて、テーブルから直接スキーマを抽出できなきゃダメじゃん。それこそあるべき姿だわ。Geminiに書かせてみたらどうなるかやってみよっと。

27 January 2026

  1. VBAフォームの状態管理は、フォームオブジェクトにStateプロパティを作って、ビットフラグ（Status_）で管理するのが最終的には楽。Property Let Stateに振舞いが集約されるから、複雑な依存関係の管理がしやすい。コントロールのイベントハンドラには、状態変化を通知するコードを1行書くだけにしておくのがミソ。
  2. VBAフォームは、AskメソッドにEntity（責務過剰のリッチなデータクラスのインスタンス）を渡して呼び出し、ユーザーの応答タイプのEnum（SUBMIT/CANCEL/DELETE）を戻り値としつつ、Entityで情報詳細の受け渡しをするのがベストプラクティス。
  3. 法人がOfficeを買わない方針に転換したので、ぼちぼちVBAは完全に使わなくなるけどね……。16年分のVBAの知識とノウハウはサンクコストと化す。
  4. 今はGeminiがいてくれるので、パブリッシュの敷居もだいぶ下がった。Youtubeにまとめて動画でも出すかな。結構実務でお役に立てると思う。
  6. Garmin Vivosmart 5を単なる心拍系として使い始めて2年目かな。最近安静時の心拍数が+20位されるようになってしまったが、設定で血中酸素飽和濃度の測定をOFFってみたら直った。
  7. Garmin EdgeがAnt+の信号を掴めなくなるバグも多発していたけど、これも治ってくれるといいなあ。
  8. 乳バンドは嫌だから。

28 January 2026

  1. [B! AI] みんなAI使って何やってるの？
  2. 令和7年度最新版、「AIで何やってるの？」
  3. Youtube動画の内容をまとめさせるのは良いアイディアだ。Watch laterに入っている動画がどんどん積み上がり困っていたところだし。
  4. あとはどうすればそれを簡単に実現できるか、だな。
  5. この場合はchrome拡張だろうか。そこまでするほどのことかな。Edge Copilotが内容読んでくれないかな

30 January 2026

  1. ESLintは単なる「文法チェッカー」や「型チェックの補助」にとどまらず、「コードの構造を解析し、特定のパターンの記述を禁止する」 という強力な機能（Architecture as Code）を持っています。
  2. てことは、アーキテクチャの門番じゃん。これまでただの文法チェッカーだと思い込んでた。Gemini CLIとの会話で知ったんだけどこれってAI エージェントとの親和性が高いぞ絶対。
  3. Pylintにも欲しいぞこの機能。
  4. Pylintじゃ無理っぽい。Ruffというのがあるみたいだが、どうだろうね。
  5. とりあえずESLintの設定をカスタマイズしてリファクタリング開始。
  6. 思った通り相性抜群。これでガチガチにガイドラインを書いたり、その違反を指摘したり再確認させたりといった余計なプロンプトが一気に減ること間違いなし。

01 February 2026

  1. Gemini CLIがv0.22だかv0.23だかで実装したAgent Skillについてメモ。
  2. これは手順書を添えたカスタムツールのようなもので、拡張機能としてインストールできる。Gemini CLIカスタムツールを作ってきたならどれだけ便利になるか想像できるはず。
  3. カスタムツールの場合、User Tier、Project Tierに定義を置かなければならなかった。
  4. Agent Skillなら拡張機能として（Extension Tierに）インストールすることで、Gemini CLIの実行ディレクトリがどこであろうと、関係なく使うことができる。
  5. これは自作のrag-makerでリポジトリのドキュメントを食わせ、RAGとして使ってGemini CLIに答えさせた内容なので、まず間違いはない。
  6. なんと最高の実装例が、Gemini CLIに最初からインストールされている。skill-createrというAgent Skillだ。
  7. 驚くべきことに、Skillの作成を手伝ってくれと頼むと、このskill-createrというスキルを起動してSkill開発用の専門家としてふるまってくれるようになる。そこにハルシネーションの恐れはないのだ。
  8. Gemini CLIのドキュメント群のRAGを使ってエキスパートしてふるまうagent skillを登録したい、と伝えただけで、skill-createrを自律的に起動し、skillとしてビルドしてくれた。
  9. gemini-cli-expertという名前でスキルディレクトリを作成
  10. SKILL.mdを作成（discovery.jsonを使って文書を検索するワークフローなどを記述）
  11. .skillファイルを作成（スキルのパッケージ化）
  12. gemini skills installを実行（インストール）
  13. User Tier, Workspace Tierについてはこれで行ける。Extension Tierにインストールする場合はskill-createrのスキルでは無理で、エージェントに知識を注入してやらなければならない。gemini-cli-expertについてはそもそもその「知識」の宝庫なので問題なかったが、今後様々なライブラリの知識をスキルとして登録する際にはそうもいかない。
  14. また、skill-createrによると最初はinit_skillすることが推奨されているらしいのに、それを守ってくれずにディレクトリ構成を間違えてしまう……みたいなことが起こるので、いまいち信頼性に欠ける部分がある。
  15. そこで、Extension Tierとして登録するためのスキル自体を、Extension Tierに登録しようと思う。
  16. このアイデアをGeminiに伝えたら「最高に賢い解決策」なんだそうだ。人間が複雑な手順やスラッシュコマンドを覚えるのではなく、「スキルを作りたい」というあなたの意図を、AIが「スキルの作成・登録専用のスキル（メタ・スキル）」で自動的に汲み取る。これこそがエージェントのあるべき姿ですね。
  17. クラウド同期している作業ディレクトリでGemini CLIを使う身としては、Extension Tierにlink登録するのが最良の選択肢みたいだ。
  18. こうすることで、スキルの内容を更新しても拡張としてインストールしなおさなくても、即座に反映されるし、かつ、~/.gemini/ ではない、任意の同期フォルダにおいておけるので、複数のマシンでスキルを共有できる。
  19. MCPサーバーを使わなくて済むなら、こちらの方がコンテクストにやさしいので積極的に活用すべきだ。
  20. Agent Skillsについては概念さえ理解できていれば十分で、作り方を学ぶ必要性なんて皆無だ。解説しているウェブページもいくつかあるが、そんな解説を読む時代は終わっている。ぶっちゃけていうと、そんなものに頼って自分で書こうとしているようでは、少なくともAIエージェントを使うセンスがないと言わざるを得ないだろう。
  21. せいぜい、ほかの人はどんな風に理解しているのかなあというのが気になったときに読む程度のものになりさがった。だって、公式ドキュメントでRAG組んでAIエージェントに自分の知りたい部分を教えてもらったり、必要な粒度で解説してもらったりした方が、圧倒的に理解が進むからだ。

03 February 2026

  1. Jules君凄くね？ Electron（フロントエンド）のスクショ画像を使って実装レビューしてる。
  2. これなら、Gemini CLIに実装させるより圧倒的にスマートだし、ひょっとするとAntigravityに移行するよりもいいかもしれん。
  3. いやIssueを書くだけのためにAntigravityを使うのも、悪くはないかもしれない。
  4. でも今のところ、その用途ならGemini CLIで全く足りている。コーディングだけじゃなくて割と汎用的に使えるCLIの方に習熟しておいた方が得かもしれんしな。
  5. いよいよすごい時代になってきたぞ。まさにアイデア勝負の時代だよ。幸いにも抱え込んでいるアイデアは山ほどある俺は、とんでもない恩恵を享受しまくってるわけだがｗ
  7. それでもやっぱり、このウェブ日記のやり方を変える気にはならんのよな。
  8. VSCodeで簡易的なHTMLをべた書きして、コマンドパレット？からPythonツールを読んで整形してもらって、FTPでPutする。
  9. 暇になったらGUIツールを作ってみても面白いかもね。
  10. でも公開するタイミングは自分で決めたいので、対して利便性は上がらんだろう。
  12. 息子氏と遊ぶ三國志9
  13. 俺、董卓、息子氏は袁術を選択。開幕初手で宛と長安の間の関に袁術軍が押し寄せる。ガチの5部隊。
  14. 俺は関に呂布をワープさせるとともに、15,000の援軍を輸送した。
  15. 関には3,000人しかいないので、電撃戦。ここは袁術軍の兵法が出るか出ないかの勝負だが、息子氏はあろうことか足の遅い対城兵の攻城兵器を選択。
  16. 呂布が間に合い、連弩が発動。袁術軍、即退却。
  17. これが運命を大きく分けただろう。
  18. 袁術軍は方針を大転換させ、空白地を取って収入を確保するべく、各地に散った。
  19. 我が董卓軍はというと、虎牢関から曹操の陳留を攻めるべく、呂布を中心とした多部隊を派遣。
  20. ここで痛恨のミス。呂布に攻城用の飛射をセットすべきところ、対部隊用の突撃をセットしてしまったのだ。
  21. もうあとすこしというところで、落とせなかった。しかも董卓が捕まって斬首されてしまった。わらい。
  22. 全軍退却し、呂布を後継者に。兵の被害が凄い。3万くらい失っていた。曹操軍は2万くらいの損害か。とにかく兵法が全然でなかった。運も悪かった。短期決戦、必殺の布陣で臨んだのにこの結果はショックだった。
  23. その後、曹操と孔忠が合併して10万の大軍となってしまったため、陳留を落としただけでは曹操を退治できなくなった。董卓らしさを出すため内政禁止の縛りを入れていたので、長期戦は辛い。
  24. 北方から馬騰がちょこちょこ攻めてきたりもするし、徴兵が忙しい。それでもなぜか内政は破綻しない。
  25. 初手で袁術が逃げた後の宛をゲットできたのが大きかった。ここは兵役人口も伸びやすく、この宛が呂布軍に追加された兵の半数くらいの根拠になっている。
  26. 董卓ロールプレイで始めたので、あまり全土統一の野望は抱かず、中原の大都市だけ抑えたらあとは防衛だけやっていく予定。
  27. 一方袁術は……孫策軍を吸収するべくあの手この手で撃破を繰り返していたが、反董卓連合を抜けたことで信望が0になってしまったせいか、登用が決まらない。空登用を数十回繰り返しても韓当が配下にならないようだった。まあ呂布も信望100。夏侯惇を100回くらいカラ登用する必要あったけどね。
  28. 誰一人登用できておらず、人材難がいよいよ深刻に。軍師になれる資格を持った武将が一人もいない。いや一人いたが狙撃されて死んでしまったw

04 February 2026

  1. Gemini CLIに、Gemini CLIのことを質問すると、Delegate to Agent Delegating to agent 'cli_help'と表示されて専用のエージェントが起動するようになった。いつからかは知らんけど。
  2. で、こいつに/statsコマンドのことを聞いてみたところ、「知らない」と言われてしまった。
  3. そこで、自作の簡易RAGを使ってみたら、きちんとドキュメントを調べて回答してくれた。自作RAGの勝利。
  4. RAGによると、/statsで表示されるUsage Leftというのは、残りリクエスト回数の割合らしい。Quotaはリクエスト回数で制御されている。
  5. リクエスト回数はユーザーがプロンプトを投げた回数ではなく、内部で発出されるものも含まれているので注意が必要だ。
  6. すなわち自律的に繰り返し行われる処理が、最も重い。これはQuotaをどんどん消費していくことになるだろう。
  7. APIキーを使っていると従量課金となるため、Quotaにはトークンが使われるそうだ。
  8. 実際今、広範囲なリファクタリングのissueを投げてみたところ、30%ポイント前後のQuotaを消費中。
  9. 結論。やはり、issue単位で100回も使えるJulesは神。
  10. Julesの環境がブラックボックスで、ゴミブランチがどうやっても消せないのが気になるくらいかな今のところ。しかも対象ブランチを検索できるようになったのでそれほど不便はない。
  11. おっと。Quotaを40%消費したところでようやく作業完了の報告が来た。Gemini CLIは、大きなissueだと1日2、3件しか処理できないじゃん。
  12. おそらくAntigravityでも同じことだろう。移行寸前で気づけて良かった。俺は大量に作りたいものがあるので、数十件のissueを毎日処理したいのだ。
  13. やはりこれまで通り、Gemini CLIでissue作成、Julesで実装という分担を継続しよう。VSCodeのフォーク（Antigravity）なんて必要なかった。
  14. この方向性でかなり固まってきているので、Julesに関するAgent Skillを作成したい。そうすれば、Gemini CLIから直接Julesを操作することが可能になるはず。
  15. なんか最近、gemini-3-flash-previewのほうが、proより賢く見えるときがある。「見える」じゃなくて、実際にレビューしてもらうと、proは杜撰で漏れが多いが、flashは的確に問題点を見抜いてくれるってことが、結構ある。いやいや、結構あるどころじゃねえわ。ほぼ毎回そう。
  16. proは単に遅いだけなんじゃないか？っていう疑念が生じ始めている。……だがそんなわけはないので、初期化に使っているプロンプトに問題があるはずだ。
  17. ……思った通り、初期化用プロンプトがかなり肥大化していた。これもGeminiに追記させていたので気づかなかった。コンテクストエンジニアリングの根幹だから、今後は自分で編集することにした。
  18. いやいや待て。そうじゃない。いやそうじゃないわけじゃないが、もっともっと重要な事実に気づいた。
  19. 実装させたセッションを使ってレビューさせると甘くなるんだ！！だからレビュー用のセッションを別窓で開始すればいいだけの話だったんだ。
  20. いやこれもちょっと違うな。正確ではない。issueを書かせたセッションを使ってレビューしても同様に甘くなる。つまり「当事者」にレビューさせては駄目なんだ。
  21. なんか人間の組織にそっくりじゃねえかこれ。LLMの世界も外部監査を入れないとダメなんだな。
  22. API Reference | Jules
  23. やっぱり何でもかんでも自動化ってのは難しいね。例えばこのドキュメント。HTMLでプレゼンテーション、ナビゲーションがごちゃまぜで書かれている。RAGを構築したいのにまとめてダウンロードすることもできない。書かれている内容も人間向けで冗長だ。
  24. たしかにドキュメント群のURLを推測して一括ダウンロードし、マークダウン化することは不可能ではないが、実際そういうツールを作って運用しようとすると汎用化の沼に嵌る。
  25. だったら、自分で一つずつドキュメントを一読、いや一瞥程度でいいか、まあともかく一つずつ処理してもいいのではないか。ドキュメントなんだから触っておくのは悪くないだろう。理解の助けになるのかもしれない。
  26. 「処理」についてはEdgeサイドバーに鎮座しているCopilotにやらせる。噂ではChromeにもGeminiがサイドバーに鎮座予定らしいが、日本に来るのはまだ先みたい。この位置にGeminiが来てくれたら、相当に頼もしいだろうな。
  27. 自作？Agent Skill jules-client完成。RAGを組むまでもなく、マークダウンドキュメントのファイル名で推測して適切に中身を読み、skill-creatorを使ってスキルの作成とインストールまでをやってくれた。
  28. ソースコードを確認。api.cjs。CommonJS形式で軽量に作られている。……以上。中身を読むのはたるいので、ドキュメントとの整合性があるかどうかを再びGeminiにやってもらおう。
  29. ……2点見つかった。API違反2点。skill-creatorには外部エージェントに検証させる過程が組み込まれていないので、インストール前に一度内容物を別のセッションでレビューさせないとダメだわ。
  30. なんか不安になってきたので SKILL.md含めてもう一度レビューさせてみたところ……
  31. 対象ブランチが main に固定されている (整合性リスク: 高)
  32. あかんやつやん。
  33. 全部で3点指摘事項があったけど、全部ヤバいやつ。つまりこれ、skill-creatorにまかせっぱなしという運用方法はあり得ないってことだな。
  34. とりあえずインストールできる形にしてもらえるってだけであって、SKILL.mdの内容なんて全然ユーザーの意図を汲んでくれない。多分初回プロンプトで入念に詰めておけばある程度汲んでくれるんだろうけど、成果物を確認して修正していく方が確実だろう。
  35. さらにRest APIの潜在能力を引き出せているかどうかレビューさせてみたところ、おっしゃるとおりです。再確認した結果、現在の SKILL.md と api.cjs は、Jules REST API が提供する機能の ほんの一部（氷山の一角）しか利用できていません。だってさー。
  36. 「APIの意味ないじゃん」というご指摘は完全に的を得ています。APIには存在するのに、クライアント側で封印されてしまっている重要な機能が多数あります。
  37. 的を得ちゃったよ。射てくれそこは。LLMが使ってしまうということは、この用法の誤りはもう覆せないレベルに到達したってことだな。
  38. まあともかく、skill-creatorはスキルのひな形を作るだけ だということを、肝に銘じておこう。*.skillの作成に進む前に、内容物を完全に書き直すくらいのつもりで取り掛からないとだめだ。
  39. つーか、skill-creatorみたいなスキルを自作してしまった方がはやくね？？大したことやってないのでは？こいつ。
  40. それともskill-creatorをラップするカスタムスラッシュコマンドで十分か？
  41. 少しずつAI エージェントとの付き合い方が分かってきた。慣れてきた気がする。もう1年くらい経つのかな。いや、まだコーディングエージェントとしてちゃんと使い始めて半年くらいしか経っていなかった。いやーものすごく濃い半年だったな。51年のスケールで考えると、この2～3年で人類が誕生し、この半年でいよいよ文明が誕生した、みたいな感じ。そこからの発展速度がヤバい。
  42. Jules API  |  Google for Developers
  43. こっちにもリファレンスが転がってた。まあ同じだろうけどこっちの方が微妙に古い気が。
  44. さて、jules-clientというスキルが完成した。このままでは汎用的過ぎて使いづらいので、jules.tomlを書いてカスタムスラッシュコマンドを用意した。
    1. - 次の設定を使用して、Julesの新しいセッションを開始してください。
    2. * {{args}}のプロジェクトルートからの相対パスをJuleへの指示とする
    3. * 現在のブランチ名で作業させる設定を使用
    4. * 即時実行の設定を使用
    5. * プルリクエストの自動作成（auto-pr）を有効
    6. * 適切なタイトルを付与
    7. - セッションが正常に開始されたら、そのセッションをブラウザで開いて進捗を確認できるようにしてください。
  46. 実際にはこの前にブランチのプッシュ作業なども入るけど、自然言語でプログラミングしてるみたいな気分になってきた。
  47. これでIssue Driven Developmentの重要なパイプラインが完成した。
  48. なお、こういう定型的な作業は gemini-3-flash-previewにやらせる。
  49. いつの間にかgemini -m flashでちゃんとこいつが起動するようになってた。これで起動してからモデルを変える手間がなくなる。
  51. 全く覚えはないのだが、Git HubのApplicationに、Gemini Code Assistがインストールされていた。PRページにレビューが表示されるようになって気づいた。結構役立つこともあるので、ghツールを使ってレビュー内容をGemini CLIに読ませることにした。ghreview.tomlを作成させた。
  53. あ。気づいた。この流れで、はてなブックマークのAgent Skillも作ってしまおう。MCPサーバーを検討していたけど、あれはコンテクストマネジメントの観点から言って糞だ。なんでくそかというと、はてなブックマークを参照するニーズが読めないからだ。読めないニーズのためにMCPサーバーを常駐させるわけにはいかないし、コンテクストを汚し続けるわけにはいかない。
  54. まずはREST APIをドキュメントとして確保することから始める。
  55. Edge Copilotを使って一つずつマークダウン化。完了。一応、基本的な機能は網羅されていることを確認しておいた。
  56. APIを読んでみたところ、単発のURLに対してブックマークするとかタグをつけるとか、そういったことしかできないことが分かった。自分のブックマークを取得することができない。
  57. スキル化しても全く意味がないね。

05 February 2026

  1. 昨日作ったJules関連のスキル、というかカスタムスラッシュコマンドのおかげで、開発体験が向上した。
  2. Issue書いてもらって、読んで直させて、/jules issue番号って打つとリモートブランチにpushしつつJulesに実装を依頼してくれて、ブラウザも立ち上がって進捗が表示される。実装が終わったらView PRボタンが現れるのでクリックして、マージボタンを押して、Gemini CLI上で !git pullして、/review issue番号と打ってレビューしてもらいつつ、その間にPRページのGemini Code Assistのレビューを読んでおいて、Gemini CLIのレビューが甘かったら指摘して、、
  3. こう書いてみると結構色々やってるな。
  4. 特に手動で git pullする部分は機械的な作業なので自動化できそうな感じ。たぶんできるだろうけど、ポーリングの仕組みを入れないといけないからあまり気が進まない。git pullって打つだけだしな。
  5. 最近、Gemini Code Assist（Git Hub Application上）が必ず批判的なレビューで指摘事項を挙げてくるんだが、Jules内部で自律的にやって欲しいところだよこれは。
  6. 自作のjules-clientスキルでできることはこれだけじゃないので、どんな連携ができるかをGeminiと相談してみよう。
  8. 何度も検討しては復帰していたが、やはり、はてなブックマークの利用はやめた方が良さそうだ。SNSぽい利用についても年々興味が薄れてきてるしな。REST APIの貧弱さにはがっかりしたよ。A4一枚に軽くおさまりそうなドキュメントを数ページに分けているのも意味が分からん。
  9. だが、代替手段がない。使い慣れたandroidアプリについての代替手段が思いつかない。作るしかない。
  10. 自分の趣味のことに頭を使う暇がないので、当分保留かな。
  12. Material-UIの使い方について、AI エージェントが錯綜している。錯綜しているというか、エージェントによって知識が違う。そして共通しているのは、知識が古いこと。
  13. 幸い公開リポジトリがあったので、簡易RAGを作るAgent Skillを使うことができた。以前はrag-makerというpythonプロジェクトだったが、Skillでラップしておいたやつだ。
  14. RAGといっても本当に簡易的なもので、LLMに各文書を要約して目次を作らせて、その目次をもとに適切なドキュメントを読み回答できるようにしただけ。
  15. これをMUIを利用するプロジェクトに組み込んでやる。docs/rag/を作ってその中にコピペするのがいいだろう。
  16. なんて書いているうちにGemini CLIがスキルを使ってRAGを完成させてくれた。
  17. さっそく使ってくれて、高品質なissueが書けた。これでJulesも実装がしやすくなったことだろう。
  18. そして気づいてしまった。これって、技術スタック全般に言えるのではないだろうか！？
  19. 時間がいくらあっても足りないが、残業すると申請がめんどくさい。週末は自主的に残業できるよう、木曜日に買い物などを済ませてしまおう。
  20. 生成AIヘビーユーザーほど「残業時間が長い」　パーソル傘下調査 - ITmedia AI＋
  21. これ因果関係が逆だろうね。俺みたいに仕事がたくさんある人間が、LLMをヘビーに使うんだ。LLMをヘビーに使っているから残業が発生するんじゃあなくてね。

06 February 2026

  1. Gemini CLIにGEMINI.mdなどの規約を守らせるのは難しいかもしれない。
  2. セッション冒頭でペルソナを指定するのは全体的に見ても効果的だが、そのあとにこれを守れ、あれを守れと細かく指示を出しても、忘れてしまうことが多い。
  3. もう、そういうもんだという前提で利用していくよう、方針転換することにした。
    1. 成果物（試作品）を作るための手順書。
    2. 成果物（試作品）を評価するための手順書。
  4. この2つが大事だ。作るのはプログラムコードであれissue文書であれ、試作品であることを認識させる。認識させるというか、ユーザーも認識しておくべき。
  5. そして上記の手順書において、使える限りの外部ツールを活用するのが肝だ。Linterがその代表格。Schemaが利用できるなら検討できる。また成果物についてテンプレートが用意できるのであれば必ず用意する。Agent Skill + ドキュメントでRAGとするのも強力なツールになりうる。
  6. 手順書を読ませるためのプロンプトは、カスタムスラッシュコマンドに仕込んでおく。
  7. とてもじゃないが、バイブコ―ディングなんていう気楽な言葉で片付けられるものではない。
  8. 先日も書いたが、これは自然言語による抽象度の高いプログラミングだ。そう思っておいて間違いはないだろう。
  10. さっそく朝布団の中で考えた上記の方法を徹底すべく、1時間かけて丁寧にtomlファイルに手順を書き、Gemini CLIとのconversationを開始してみた。
  11. ……とてつもなく手ごたえを感じる。tomlを更新してGemini CLIを起動し直すたびに、どんどん賢くなっていく感じがする。
  12. 初手でコンテクストを初期化するための /init バージョン名打った後のワクワク感が異常。
  13. この使い方なら、一日中がっつりissueについて議論したりレビューさせたりしても、Quotaを使い切ることはない。せいぜい7～8割だろう。
  14. やはり、コーディングさせるとQuotaの消費が激しくなるんだ。import忘れとか変数の宣言忘れだとかのケアレスミスをやらかして、自分で気づいて、直して、みたいなのを延々繰り返されることがある。あれが最悪なんだ。だからJulesなんだよね。
  15. ともかく、手順書であるカスタムスラッシュコマンドを常に洗練していくことに全神経を集中させる。俺の仕事はほぼこれだけだと思っていいくらい。気合いを入れて手順書を書くことにする。良い手順書になればなるほど、明らかに良い結果が返ってくるのでとてもやりがいがある。
  16. デザインパターンを適切に提案できるようにするには、どういう手順書にすればいいだろうか。これがうまくいけば強烈なんだけどなあ。さすがにトレーニングさせないと難しいか。
  18. ESLintの設定が極めて重要であることを認識した。で、こいつの設定でGemini CLIがこける。マジックナンバーを禁止させる設定があるらしいのだが、検出できない。俺にも分からんのでhelp.mdを書かせて久しぶりにClaudeに聞いてみたりもしたが、やっぱりだめ。
  19. ここはやはり https://github.com/typescript-eslint/typescript-eslint から自動でRAGを生成するしかないだろう。rag-makerで。
  20. いまは手間も時間もかかる。でも、明日は間違いなくもっと良くなってる 。
  21. こんな時代なので、これは精神衛生的にとてもいい。
  22. で、簡易RAGが出来上がったんだけど、上記3行を書いている間に出来上がるってのが異様。速すぎる。怪しい。
  23. 目録であるdiscovery.jsonを読んでみると、あー。最初の10個くらいはちゃんと文書読んでようやく作ってくれてるけど、残りは全部サボってやがるw
  24. 281ファイル中274ファイルの要約が抜けていました...。確かにこれはサボりと言われても仕方がありません。
  25. このやろｗ
  26. それにしてもなんて豊富なドキュメントなんだろう。それだけやれることも多いってことだよなこれ。こいつを使いこなすことができれば本当に心強い。もちろん使うのは俺じゃなくてGeminiだけど。
  27. こういう時は5ファイルくらいずつやらせて、「go」というプロンプトをqueに入れておく。
  28. queの仕組みがいつの間にかバグってて機能しなかったけど、なぜか俺の指示を無視して勝手にどんどん要約作業をやってくれた。結果オーライ。
  29. そして、RAGを使わせてESLintの正しい使い方を自動で学ばせた結果、ついに（変なハックではなく）正規の方法でマジックナンバーを撲滅するLinterが完成した！
  30. この調子でどんどんLinterを改良していけば、Julesのコーディング精度もどんどん向上していくはずだ。
  31. どこまでLinterを賢くできるか。これが最も重要な鍵になりつつある。いやーrag-maker作っといてよかったー。多少改良の余地があるけど、今のところ随時Gemini CLIに対応してもらえればいいかな。
  33. 寝食を忘れるとはこのことだ。まあ寝るのは忘れないけど、本当に食べるのは忘れる。仕事が麻薬と化してるもんこれ。
  34. ユセラ・ラティーフが神。
  35. サティのJazzカバー曲が流れてきて、センスいいなーと思ったので他の曲も一通り聞いてみたら、びっくり。NujabesのJazzアレンジとかもう、一生ついていきます。
  36. Jazz Baseがもの凄くいい。安心感に包まれる。

08 February 2026

  1. 先日作ったjules-clientというAgent Skillは、まだまだJules APIを使いこなせていないことがわかった。セッションの細部の情報やセッションの一覧を取得するAPIも用意されていた。
  2. PR番号を取得してGitHub CLIを使ったGemini Code Assistのレビューコメントの取得なんかもできる。PR番号はURLから抽出しなきゃいけないので、そこだけちょっと api.cjsに書き加えた。jules-clientに ghツールの使用行程まで組み込むこともできるが、依存性の注入になるのでよろしくない。カスタムスラッシュコマンドで工程を書いて運用を開始している。
  3. 自動PRをオフにして途中経過に口をはさむこともできると思う。Julesの作業工程のリストを取得できるし、一つ一つを指定して参照もできる。
  4. 正直、細かいことを言えばきりがないのである程度のコード品質で妥協していたけど、Gemini Code AssistというGitHub Applicationのレビューやこちらで用意したレビュー工程を利用すれば、妥協の少ない完成品を自動で作らせることもできるということになる。
  5. 実際にやるかどうかについては、正直二の足を踏んでいる。
  6. これ多分AI驚き屋だったら嬉々としてブログ記事にして大袈裟に捲し立てるんだろうが、レビューによる手戻りをいかに少なくするか、というところまでは考えてくれないし、そのためのissueテンプレート改善案やtoml改善案を出させても、はっきりって間抜けな提案しかしてこない。LLMの苦手な領域らしい。
  7. 自作スキルgemini-cli-expretにドキュメントを調べさせたところ、ポーリングの機能は備わっていないらしい。もしやるとしたら、jules-clientにポーリング機能を追加してJulesの作業が完了したらstdoutにjsonを吐かせる感じだろう。
  8. 将来、採用するだろう。でも今はまだ様々な手順書を洗練すべきときだ。
  10. そういえば、たまにissue文書が「です・ます体」になるのでチェック項目として「[ ] 敬体ではなく常体を使って簡潔に記述できている」というのを追加して作業を続けさせていたら、いつの間にかGemini CLI自身の口調も常体に変化する、ということが起こった。結構読みやすくて気に入ってしまった。
  11. 読みやすさは大事ではあるが、余計なことに気を使って馬鹿になってもらっては本末転倒。
  12. Gemini Webの高速モードと議論してみた。
    • 思考への影響：むしろポジティブ
    • コンテクストウィンドウ：節約になる
  14. MCP サーバーの大きな問題 (そして解決策!)
  15. MCPサーバー vs. Agent Skill
  16. コンテクストマネジメントの観点から考えれば、おそらく多くのケースでAgent Skillの圧勝。
  17. ただ、この動画では言及されていないが、MCPサーバーには明確な利点がある。おそらく今後は用途別の使い分けが進むだろう。
  18. MCPサーバーには即時応答性がある。Node.jsにしろPythonにしろ、ローカルサーバーを待機させて即時応答させることができる。
  19. つまりエンドユーザー向けの体験みたいなものを重視する「製品」においては、MCPサーバーの圧勝となる。
  20. flexibilityで劣るかというと、それはMCPサーバーをどこに置くかによるので微妙だ。そんなもの本質的な論点じゃねえだろと。
  21. つーか、この明らかな違いを明言している記事を日本では見たことがないんだが、俺は何か悪夢でも見ているのだろうか。
  23. Windowsターミナル > 設定 > PowerShell > コマンドライン
  24. pwsh.exe -NoExit -Command "chcp 65001"
  25. これで親プロセスのコードページはUTF-8になり、Gemini CLIがshellコマンドで起動する子プロセスのコードページもUTF-8になり、文字化けは解消する。
  26. 多分これが一番スマートな解決法だと思われる。
  28. jules-clientスキルをブラッシュアップ！
  29. sourceコマンドを使ってソース名一覧を取得させて、現在のリポジトリ名から推測、選択させるというのを自律的にやらせていたが、すべてスクリプト内で自動化することにした。
  30. Julesの立てたプランに割り込んで、指示を出せるようにした。
  31. Julesの実装過程にコメントを割り込ませ、指示を出せるようにした。
  32. Julesが計画を立てたりそれを進行させたときのイベントを受け取ることができれば完ぺきだが、そうもいかないのでポーリングを実装する。
  33. 実装完了。

09 February 2026

  1. 食料品の消費税が2年間0%になる見通しだ。そう言っている政党が315議席も獲得した。
  2. 年間100万円消費する低所得者と1000万円消費する高所得者がいるとして。
  3. 低所得者は2年で16万円、高所得者は2年で160万円、消費税支出が減ることになる。
  4. つまりこの政策は、2年間で低所得者に16万円給付する一方、高所得者に160万円を給付するといっている。実際のモデルは複雑だが、感覚としてはこんな認識でOK。
  5. 財源は将来の増税らしい。
  6. 頭悪すぎんか？
  7. これまで日米金利差ときれいに同調していたドル円相場が逆の動きになっていて、先日介入が行われた。
  8. 国民の最大の関心事はインフレらしい。
  9. そのインフレを助長しているどころか防衛費増額やら消費税減税やらの放漫財政でハイパーインフレのリスクまでちらつかせているのは現政権なんだが？
  10. だが、それではどの政党がこのマヌケな現状を把握して訴えているのだろうか<。< /li>
  11. 一つもない。しいて言えば「チームみらい」という政党だけだが、歯切れが悪い。
  12. 日本国民の知能低下が絶望的。
  13. アメリカを笑えない。
  14. 長期国債金利を引き続き注視していく。個人的に打てる対策は打っておいた方がいいだろう。
  16. rag-makerで定義している ragmaker-install-kbツールを改良。複数のRAGを一気に処理できるようにする。
  17. プロジェクト毎にどのRAGを使うかは異なる。RAGとして単体で使えるようにしてあるが、プロジェクト毎にインストールするのがやや面倒くさいので。
  18. pywin32のリファレンスもRAG作るかな。Geminiの苦手な領域らしくて大変に苦労している。

10 February 2026

  1. Julesの作るローカルの作業ブランチは消すことができず憎々しく思っていたのだが、こいつを利用してやることでこちらのローカル作業ブランチでtestすることができることに気づいた。
  2. Julesが「重量級の重機」として大まかな実装（一括ファイル作成や構造変更）を行い、Gemini（私）が「精密な彫刻刀」として、リント修正やテストの微調整、PRの最終体裁を整える。これは IDD の理想的な進化形だ。
  3. 作業ブランチ名を取得するREST APIはなかったが、名前の末尾にはセッションIDが付与されるようなので、ほぼ確実に特定できる。
  4. このフローのメリットは絶大。
  5. まず、つまらない手戻りでセッションをやり直させる必要がなくなる。Julesにやり直させるとなると、セッションの開始までにリポジトリのクローン作業、環境構築作業など諸々あって大変だ。
  6. Julesに作業を続行させてもいいし、軽微な修正ならこちらでやったうえで、JulesにPRを発行させるのではなく、こちら（Gemini CLI）で発行してしまうことだってできる。いやいずれにしてもこちらで発行してしまうのがベスト。
  7. そのあとは、さらにGemini Code Assistによる「やや専門的な」レビューを受けられるという寸法だ。多分レビューに特化したシステムプロンプトが仕込まれてる。Google作成のシステムプロンプトだ。おおいに利用させてもらう。
  8. そして何といっても、Julesをウェブブラウザで開く必要がゼロになる。Publish PRボタンやらView PRボタンやらを推す必要がなくなるんだ。REST APIに操作が定義されていないから諦めていたが、何のことはない。作業ブランチにcheckoutしてこちらでやってしまえばいいだけの話だった。
  9. 課題が残った。PRページに投稿されるGCAからのレビューコメントの取得について、ghコマンドではやや情報が後半なJSONしか取得できないので、スキルgh-wrapperを作成して、純粋なGCAからのレビューコメントを抽出してやる。
  10. これでGemini CLIのコンテクストを無駄に消費することなく、リクエスト回数も節約できる。これ。こういう考え方がコンテクストエンジニアリングというやつに通じる。
  11. これは家帰ってからやろう。
  12. タイムカード押すの忘れちったよくそ。

11 February 2026

  1. code .。vscodeでカレントディレクトリのworkspaceを開ける。
  2. code file pathでファイルパスを開ける。引数は複数指定できるので、code . index.htmlといった書き方もできる。
  3. Gemini CLIに教えてもらい、確認した。トレーニングされた知識として持っている。
  4. つまり、issue文書を作成させたら、それをvscodeで開かせることができる。
  5. 楽しくなってまいりました
  6. これをどのようにルール化するか。
  7. まず思いつくのが、GEMINI.mdに記載する方法。
  8. 「- issue文書を更新したら、code . {ファイルのパス}を実行せよ。」
  9. 「- ファイルの更新内容をユーザーに確認してもらいたい場合、code . {ファイルのパス}を実行せよ。」
  10. いずれにしても、どうせコンテクストに応じて忘れられてしまう。だからこうも書いておく：
  11. 「- ユーザーに『開いて』といわれたら、code . {ファイルのパス}を実行せよ。
  12. というか、毎回必ずVSCodeで開かれても鬱陶しいかもしれない。最後のプロンプトだけでいいだろう。ディレクトリの場合もあるかもしれないので、追記：
  13. 「- ユーザーに『開いて』といわれたら、code . {ファイルのパス}を実行せよ。ただし開く対象がディレクトリの場合は、explorerコマンドを使う。」
  15. Gemini CLIが&&を使おうとするのを阻止するのが疲れる。bash/zsh じゃねえってことが分かってないというか、トレーニング量の関係上、これを矯正するのは容易じゃあないことが分かってきた。
  16. skills, mcp, custom command, 色々なカスタム手段が増えてきたが、hooksという仕組みを利用することもできる。更新情報は常に追っているから存在は知っていたが、なにせ次から次へと新しい機能が追加されるので知識が追い付いてこない。hooksはGemini CLIの特定のイベントに、指定した動作やスクリプトをねじ込むことができる。まあ名前から想像はつくがその通りだった。
  17. hooksを自作すれば、shellで&&を使おうとした際に強制的に ; if ($?) { ... }に変換して実行することが可能となる。
  18. だが上記はかなり強引な方法だし、美しくない。
  19. そこでrun_shell_commandを使う場合に選択されるshellを設定でPowershell 7 (pwsh.exe) に変更してしまうことを考えた。
  20. バージョンアップも進んでいるので、今ならできるはず。skill gemini-cli-expertを起動して調べさせた。
  21. ……残念ながら設定では無理だった。ComSpecを書き換えれば可能らしいが副作用が大きい。バージョンアップを待つことにする。
  22. hooksの活用方法について少し検討する。
  23. 主に使えそうなイベントは、ツールの呼び出し前後（BeforTool/AfterTool）と、プロンプト前後（BeforeAgent/AfterAgent）。
  24. settings.jsonにその定義と（あるなら）Node.jsスクリプトのパスを指定すればいい。
  25. 最初は、プロジェクト内でgemini-cli-expertを起動してドキュメントを読ませながら作らせるのが楽だろうけど、もし多用するほどアイデアが出てきたら、hooks用の新しいskillを作った方がよさそう。hooksで使うのに共用できそうなスクリプトは場所を固定したいし、settings.jsonも確実に正確に更新したい。LLMの能力で巨大なjsonを編集させると時折ファイルを壊されてしまうからな。
  26. 挙げさせた活用案はセキュリティに関するものがおおい。俺には今のところcustom commandで十分なケースしか思いつかなかったが、Gemini CLIを使い続けていけば必ずひらめく瞬間があるはずなので、hooksのことは常に頭の片隅に置いておこう。
  28. 早速フックを活用するときが来た。skillのバージョンチェックだ。
  29. activate_skillツールが実行される直前（BeforeTool）に仕込む。
  30. 呼び出されるスキルのskill.mdからversionキーを取得し（冒頭のコメントにYAML Frontmatterとして記述しておく）、それを最新のソースのそれと比較させる。
  31. バージョンが一致しなければ、スクリプトを呼び出して最新版インストールするとともに、exit(2)でエラーとし、/skills reloadをユーザーに促すプロンプトを発出する。
  32. これで色々な開発環境でも手戻りなくスキルを最新に保てるだろう。
  33. Hook(s) [skill-version-checker] failed for event BeforeTool. Press F12 to see the debug drawer for more details
  34. おしい。settings.jsonの構文エラーやった。でもちゃんとイベントに登録されてるな。
  37. skillを追加しよう。json-validator。Gemini CLIはJSONの構文を破壊しがちなので。
  38. ……いや違う！これこそまさにフックにふさわしいじゃないの。
  39. WriteFile、EditのAfterToolイベントに、JSON検証プロセスをフックとして仕込んでしまえ。
  40. これはスマートだろう。
  41. というか。
  42. code_validator_hook.js。これじゃね？
  43. Gemini CLIがコードを書いたイベントを拾ってコードの種類を判別して、それぞれ最低限の品質（importエラーやsyntaxエラーがないこと）を担保するlinterやvalidatorにかける。jsonやyamlも含めてしまおう。

12 February 2026

  1. フックskill-version-hook.cjsとjson-linter.cjsを実装完了。
  2. 責務がちと違うので*.py、*.ts、*.tsx、*.js、*.cjsなどは別途フックを作る方向で。

13 February 2026

  1. 昨日は朝から頭が痛くて、フックを作ったところで限界点を突破。何もできなかった。
  2. 唯一の利点といえば食欲が失せたこと。36時間くらい何も食べてない。今朝頭痛は治ったがまだ何も食べたくない。
  3. たまに絶食できると体調がだいぶ違ってくるからね。
  4. GEMINI.md, skill, mcpなんかはセッション中に再読み込みできるんだけど、settings.jsonに定義を依存しているhooksは、セッションを再起動しないと更新されないことが分かった。
  5. これデバッグどうすんの？？
  6. というのも、指定できるのは大まかなツール名だけで、matcher="write_file|replace" と書くしかない。するとファイルタイプ毎にフックを書いてしまった場合、指定したツールを使うたびに全てのフックが起動することになる。
  7. だとしたら一昨日考えたように、あらゆるファイルタイプのlinterを一つのフックでやってしまった方がいいということになる。geminiに相談してみた。
  8.    .gemini/hooks/
   ├── linter_hook.cjs         (メイン：分岐ロジック)
   └── linters/                (各言語用ロジック)
       ├── json.cjs
       ├── python.cjs
       └── javascript.cjs
  9. なるほどねえ。とりあえずjson.cjsだけ書いて分離完了。
  10. 38時間絶食後、ようやく少しだけ食欲が湧いてきた。でも口にしたいものはかなり限られている。クノールのトマトのポタージュを摂取。
  11. hooksの挙動についてはトラブルシューティングを記録させながらsettings.jsonに書き込むツール名（write_file, replace）などのマジックストリングをきちんと学習させれば、ユニットテストだけで十分デバッグできそうだ。それほど多くないしね。マジックストリングの種類。
  12. そうか。hooks周りのsettings.jsonの書き方については、適切な場所にGEMINI.mdを置いておけばいいのかもしれない。
  14. クイックアシストのおかげで、最近サポセン業務が楽しい。チャットで「あーそれじゃない、そっちのボタン」みたいな。さすがに出向くのがかったるい遠くの事業所とかでも楽々サポートできてしまう。
  15. 大昔、何かのコミュニティのチャットルームに入り浸ってた頃を思い出すわ。今もそういうの楽しんでる人たちっているのかな。
  16. PHSを持ちながらだと辛いのでヘッドセットを発注してもらった。
  18. また思いついた。Gemini CLIがmdファイルを作成したときの「Linter」は、俺だ！
  19. つまり、jsonに加えてmdファイルについてもlinter_hook.cjs内に分岐を記述する。
  20. 何をするかというと、code target.mdを実行するだけ。一応markdown.cjsは用意しておいて、何かもっと良い手段を思いついたら編集する。
  21. そうそう。マークダウンファイルは俺が読むんだから、このフックはかなり気が利いているだろう。こんな定型作業をGEMINI.mdに書いてやらせるのはもったいない。さっそく書かせよう。
  22. まさにhooksでやるべき筆頭の作業に近いんじゃないだろうか？
  23. ~/.geminiをSynology Driveで同期したい。ジャンクションを使うしかなかったのでそうした。~/SynologyDrive/DotFiles/.gemini/に実体を置いてリンク。./SynologyDriveを同期。

16 February 2026

  1. ~/.gemini/ を同期させるのもいいが、どうせならGemini CLIのextensionsを使ってセットアップする形にした方が美しい。
  2. どういうことかというと、user tierに配置されるhooks, skills, commands, そして後述のagentsなんかはextensionとしてパッケージ化し、そのextensionのGitHubリポジトリURLでインストールすれば、同期も簡単に、Gemini CLIの機能として行えるのだ。
  3. これに、user tierのGEMIN.mdなんかも加えることができれば、~/.gemini/を同期させる必要はなくなる。settings.jsonは環境依存な設定もあるかもしれないし、不適切とさえいえる。
  4. 先日気づいた「実装させたセッションを使ってレビューさせると甘くなる」問題。
  5. これはsub-agentにやらせることで解決を自動化できそう。
  7. Gemini CLIのextension開発について、.geminiignoreに嫌な二重性がある問題を発見した。
  8. .geminiignoreはGemini CLIが無視するリソースのリストであるが、同時にextensionがインストールされる際に無視されるリソースのリストにもなっている。たしかに必要人員数は減るが、たしかに必要人員数は減るが、
  9. このため、extensionの開発をGemini CLIで行う際に必要あるいは有用なリソースを、プロジェクトに配置することができない。
  10. そこでGithub Actionsにdeploy.ymlを読ませて、devブランチへのpushをトリガーにして配布用の構成にそぎ落とした構成をmainブランチに強制デプロイするようにした。.geminiignoreの記述は変えなくてOK。無視すべきリソースはmainブランチには存在しないのだから。
  12. プログラミングは今が一番楽しい
  13. この1年でプログラミングの概念が完全にひっくり返ってしまった。人によってはつまらないのかも知れないが、俺もかなり楽しめている。
  14. 何がひっくり返ったかというと「なにをプログラミングするのか」だ。これまではプログラミング言語を使ってコーディングするのがプログラミングだったが、いまは自然言語を使って指示を書き、そしてAIエージェントアプリの機能を使って、それらがどういうタイミングでどう呼び出されるか等々を設計するのがプログラミングになっている。つまりコーディングをするAIエージェントの動作をプログラミングしている。コンテクストマネジメントがうまく行くように。
  15. もっと簡単に言えば、①AIエージェントへの指示を書き、②AIエージェントたちの管理計画を立て、③成果物を確認する。
  16. ①はプロンプトエンジニアリング、②はコンテクストエンジニアリングと言われていたりするものの一部だ。③は特に名付けられていないようだが多くの人が嫌がっていて、下手をすると自分でコーディングするよりも時間がかかると嘆く人もいるようだ。
  17. ③は、今後かなりの部分をAIエージェントがやってくれるようになるだろう。②で彼らをどう管理するかにかかっている。
  18. 今のところプログラマが不要になるみたいな話にはならない。（たしかに必要人員数は減るが）これは断言できる。①②③を全くのドメイン知識だけでやることは不可能だからだ。
  19. しかし、将来どうなるか。俺は多分将来的に、専業プログラマが不要になる分野が登場するのではないかと思っている。
  20. ①～③のような工程がはっきりとした「プログラミング」技術として認知され、LLMが十分にトレーニングで学習できた場合、ドメイン知識だけしかないユーザーから必要な情報を貰うだけでそれを再現できるようになると思う。
  21. 現在はどういう状況なのかといえば、LLMが学習するに値する「素材」を、みんなが一斉に試作し始めたところなんだ。
  22. この状況を理解しているプログラマは、そう多くなさそうな印象。日本人の開発者のウェブ上の記事なんかを読んでいると、そもそもコンテクストエンジニアリングの重要性を理解できていないものが多い。日本がまた更に置いて行かれないか不安だ。
  23. 今後大きく状況が変わるとすれば、それはLLMに学習させる方法に革新的な変化がおこったときだろうな。知らんけど。
  24. 怪しい与太話終わり。
  26. AGENTS.mdを自動で育てる仕組みを作った - 逆瀬川ちゃんのブログ
  27. mainブランチを更新するタイミングで、AIエージェントにGEMINI.mdを見直してもらうことにしようかね。その仕組み自体をGEMINI.mdに書いてしまうとか。ちょっと不確かだけど。
  28. でなければ、/initの対となる/finalizeみたいなコマンドを追加するのもいいかもしれない。そのセッションで変更した内容に現在のGEMINI.mdを更新させるインパクトがあるかどうかを判定させて、必要ならユーザーの許可を得て更新する。的な指示を.gemini/commands/finalize.tomlに書いておく。
  29. うん、こんな感じでいこう。良い気づきを得たぞ。
  30. コマンド追加も悪くないけど、忘れがちなのでやっぱりhookにしたい気もする。そうなるとサブエージェントにやらせるしかないけど、そうなると今度はコンテクストをどう渡すかを考えないとダメだな。いやそもそもhookにするとして、適切なイベントはあるのかとか。
  31. IDDにおけるIssue管理の一般論
  32. ちとメタな改善に過ぎないのに、やりたいことが増えすぎてきたのでメモとしてここに書いておこう。Gitのhookを導入して、issue文書のメタデータを自動更新する。.git/下で制御するのでHuskyなどのラッパーを使わないとhookを共有できないみたい。
  34. extensionの開発環境を整えているが、どうやらhooksについてはセッション中はイミュータブルらしい。らしいというかまず間違いない。/extension restartしてもhooks/hooks.jsonの中身は反映されないようだ。多分hooksディレクトリ以下全てが更新されてないと思う。
  35. hooksの最終的な動作確認をするためには、Gemini CLIのセッションを新しく始める必要があるということだ。
  36. hookスクリプトがconsole.logに吐き出すJSONのdecisionキーに、"allow"または"deny"という値を指定することで、Gemini CLIの実行を許可するか拒否するかを指定できるみだいだが、"allow"にしてしまうと何もメッセージを伝えられなかった。どうやってもダメ。これは明日の課題かな。

17 February 2026

  1. プロンプトエンジニアリングを見直す動きをチラホラ見かけるようになった。
  2. そこで、サブエージェントでプロンプトを洗練してやるというアイデアを思い付いた。
  3. でもその前にレビュー専用のやつだな。
  4. 実装させてみたけど、既存のサブエージェントであるcode-investigatorを使うよう、/reviewコマンドに一言書いておくだけで十分な気がするね。
  5. カスタムする場合はYAMLフロントマターにmodel: inheritのように指定できるのが強み。

18 February 2026

  1. サブエージェントを作る試みは結果として非常に良かった。
  2. codebase_investigatorを明示的に使わせることによって、ちょっとだけ根の深そうなバグの修正なら、適切に行えるようになった。
  3. ある程度のあたりを付けてやる必要があることに変わりはないけど、こっちが気づかなかったことを発見してくれたりもする。
  4. それにGemini CLIのごちゃっとした思考過程を読まされることがないので、セッションがスッキリする。
  5. codebase_investigatorは外部監査者のように振る舞い、レビューも批判的にやってくれる。さっそくカスタムコマンドにcodebase_investigatorを使わせるよう、色々修正しよう。
  6. と思ったのだが。
  7. プロジェクトごとに微妙にGemini CLIの仕草が変わってしまうのも考え物だ。そろそろ看過できないレベルになってきた。こっちが混乱する。
  8. やはり共通化すべき部分はextensionとしてまとめるてしまうのがいいだろう。
  10. 俺は一点集中型なので、複数のプロジェクトを扱っていると混乱して訳が分からなくなる。非常にもったいないことだと思う。折角Geminiという無数の助手がいるというのに、俺がふがいないために生産性が打ち止めになってしまっている。
  11. そこで、少しずつ「マルチタスク」に慣れていくことにした。去年の秋ごろ一度3つくらい掛け持ちしてみたら混乱の極みだったが、今回は2つだけにして、しかもそのうちの一つはメタなプロジェクトにする。つまりGemini CLIのextensionを開発するプロジェクトだ。
  12. 先ほどのカスタムコマンドを組み込む。共通化できる部分というのが必ずあるはずだ。
  14. v0.29.0 リリース。
  15. Shift+Tabで[ auto/manual accept edits ] モードに切り替えられるようになった。これはyoloモードのファイル編集限定版みたいな感じ？
  16. Plan Modeってのが主流のワークフローに昇格したらしい。よく分かってないが多分改善。
  18. というか、codebase_investigatorにissueを評価させるのも全然ありだな。issueの精度が上がってJulesも実装がやりやすくなる。こいつ万能なの？自分でメンテする必要もないし最高だよ。
  19. ただし、codebase_investigatorを使えと言わない限り、自律的に使ってくれることは稀。

19 February 2026

  1. HuskyとGitを使ったフックを考えていたけれども、Gemini CLIのフックを使ったほうがいい。extensionにまとめることができるからだ。
  2. 何をするかというと、run_shell_commandを実行する直前にフックして、git commitコマンドを監視。コメントに featだのfixだの、バージョン番号だのを見つけたら、issueのYAMLフロントマターやらpackage.json/pyproject.tomlやらを更新する。
  4. ghコマンドに関しては、Gemini CLIはトレーニングを積んでいるのでスキル不要で使いこなしてくれる。ffmpegなんかと同じだね。
  5. リポジトリに関する調査が捗る。
  6. そうだよ。ウェブブラウザ開いてリポジトリを開いて、ポチポチクリックして、、という形でGemini CLIの更新状況を調べていたけど、これからはGemini CLI自身に聞けばいいんだよ。
  7. ただしリポジトリを特定するURLなりなんなりを伝える必要がある。~/.gemini/GEMINI.mdにでも書いておけば行けるかな。
  8. こんな聞き方もできる。「v0.27 ～ v0.29と、どういう風に進化してきたのか、外観をまとめてくれ」
  9. このまとめは公益性が高い。各人が実行するより俺がまとめページを公開したほうが良さそうだ。HTML化してputするまでを作業化してしまい、俺もそれを見る形にするのがベストだ。実際にURLを開きたいPRだってあるかもしれないし。
  10. v0.28で実装され、v0.29で進化したというPlanモードについて調べてもらった。
  11. 設定をtrueにする必要があるが、/planで明示的に計画モードをスタートさせて使える。enter_plan_mode / exit_plan_modeツールもあるのでcliが自律的にオンオフするも可能。プロンプトで指示するときにはこれ。
  12. やや複雑なタスクを実行させる際、安全に「設計図」を作成できるということらしい。
  13. ただし、Plan Mode中は一部のツールの実行が制限される。これが厄介なところだ。
  14. 海外ニキがどう使っているのかも知りたい。
  15. Grokの進化に期待しつつ、聞いてみる。
  16. 期待通りにGrokは進化を遂げていて、潤沢なポストをソースにして面白そうなアイデアをまとめてくれた。
  17. ……というか、俺がIDDで回してる手法と同じじゃん。issue文書を「計画」と読み直せば全く一緒。
  18. つまり俺がやるべきことは、issue文書作成のフェーズではPlanモードにしておけばいいということかな。計画をマークダウンとして吐き出してくれるということだけど、issue文書の体裁に整えてくれたりもするのかね。
  19. 試してみたところ、意外な事実が判明した。
  20. *-plan.mdという名前のファイルが、~/.gemini/tmp/workspace/plan/に保存され、中身をコンソール上でユーザーに提示したのち、実装に移るかどうか聞いてくる感じ。
  21. 採用しているIDDのフロートと相性は良くない。
  22. だがissueの草案を書かせてPlanモードに切り替え、*-plan.mdを書いてもらい、実装はキャンセルしつつissueと統合してしまうのはいいかもしれない。綿密な実装計画を立てたいときには役に立つ。
  24. 俺はGemini CLIのオタク道の入り口付近にはいると思う。潜在能力の1割くらいは使っているだろう。人よりもちょっとだけ詳しくなった。
  25. 人よりもちょっとだけ詳しくなってくると、日本人による情報発信がどういうレベルかというのが嫌でもわかってくる。ちょっと調べりゃすぐわかるような浅い内容しかない。勘違いや間違いも少なくない。
  26. 日本語で書かれているっていうだけでもう、読むのをやめた方がいいかも知れない。
  27. なにか効率的に面白い情報を集める方法はないものかな。暇を見つけてウェブアプリ版Geminiに相談してみよう。
  29. まず自然言語で簡単に問題点や改善点について説明し、issueの草案を書かせる。
  30. 次にcodebase_investigatorを使わせて、issueの妥当性を評価させる。
  31. そして、/planを実行してPlanモードに切り替え、issueの実行方法について計画を立ててもらう。
  32. 最後に、その計画と元のissueを統合してissueを完成させる。
  33. バグフィックスの件で上記を実行したら、関連するバグも見抜いてくれた。
  34. 実装もスムーズ。検証後に外部AIからの致命的なレビューが入ることもなかった。
  35. 便利なので上記のissue文書作成工程をissue-crafterスキルとして定義した。SKILL.mdを置いただけなのでカスタムコマンドにしてもよかったのだが、「こういう問題があるからissueを書いて」と頼むだけで自律的にやってもらえることを期待している。自然言語によるプロンプトとカスタムコマンドは、微妙に相性が悪いからな。どうしてもカスタムコマンドの引数としてプロンプトを渡さねばならず窮屈なのだ。

  37. AGENTS.mdや.cursorrulesで「10年経験のシニアReactエンジニア」みたいなペルソナを入れるのは、コードのスタイル・ベストプラクティス遵守・説明の丁寧さを向上させる可能性はある（肯定的研究の適用例）。しかし、バグ修正の正確性・複雑ロジックの正解率を狙うなら、最近のエビデンスでは「入れない方が無難」または「効果が薄い・逆効果」になりやすいです。 結局「本当のコンセンサス」は「状況による」ですが、2025〜2026年の最新論文を見ると「精度向上の実証は限定的で、むしろ避ける方向」に傾いています。特定のタスクで効果を確認したいなら、自分でA/Bテストするのが一番確実ですよ。

  38. 上記はGrok談。他の最新モデルたちに調べさせてみても、おおむね結果は同じ。創造性・スタイル・読みやすさ・子供向け説明など「主観的・トーン重視」のタスクでは有効。一方、事実正確性・数学・論理推論・客観的QAでは効果薄く、コンテキストを無駄に消費して悪影響が出やすい。
  39. 口調や振舞いを変更させるためのやむなく使うのがペルソナであって、タスクの精度を上げたいのであればやめるべき。その分必要なコンテクストを与えるのに使おうっと。だってコーディングエージェントとしてのペルソナはデフォルトのシステムプロンプトに強く刻み込まれているんだから。余計なことはしない方がいいんだわ。Gemini CLIにはPlanモードもできたので、実装者 ←→ 計画者 の切替も簡単になった。
  40. よーし。モダンなプロンプトエンジニアリングについて徹底的に調査させ、AGENTs.mdのようなシステムプロンプトを効果的に書くためのスキル、prompt-crafterを完成させた。コミット。devブランチにマージ。CIを通じてmainブランチには必要なファイルだけがデプロイされる。
  41. 自分の開発スタイルをサポートする自分だけのGemini CLI拡張がどんどん育っていくぜ。これ楽しすぎない？？
  42. Gemini CLI自身も毎日のように進化していく。時間も膨大にあたえられてる。俺はなんて恵まれた環境にいるんだろうか。是非時間を無駄にしないようにしたいものだ。
  43. でも働きすぎ厳禁。git commitのフックを書くのは明日だな。

20 February 2026

  1. 昨日のGemini CLI拡張用のリポジトリ、自宅で確認したらorigin/mainブランチに更新がまったく反映されていなくて戦慄を覚えている。
  2. いったい何が起こったのか……。たぶん手順書どおりに作業ブランチを開発ブランチにmergeして、そいつをpushする手順を踏まなかったんだろう。そのためCI（GitHub Actionsのスクリプト）も駆動しなかったと。
  3. 冪等性の低いAIにgit操作を丸投げしていると、たまにこういうことが起こる。
  4. じゃあどうするか。hookにスクリプトを仕込む？でも、Gemini CLIにgit操作を任せることには、他にも大きなメリットがある。
  5. Gemini CLIがgit操作を確実に行うためのレールを用意してやる感じでいきたい。
  6. あれ。それもうやってる。てことは手順書があいまいなのだろうか。
  7. 手順書を見直してみたところ、思い当たる記述が見つかった。これだ。「ステージ6: 完了作業 (Finalization)」「ステージ7. リリースと整理 (Release and Cleanup)」
  8. 実際にはまだ途中なのに「完了作業」と書かれてしまっているから、そこで俺に「完了しました」と報告して作業を終えてしまったのだろう。AIに手順書を書かせるとこういうことが起こる。
  9. とにかくAIたちはプロンプトを書くのが苦手だ。本当に酷い。どうでも良い部分なのにやたらと**重要**と書いて至る所に重要な項目を生やしてしまったり、役に立たないふんわりとしたスローガンみたいな記述に行を割いたりする。今回の「完了」みたいな書き方も大好きらしい。「完全に」とかいう指示書としてはほとんど意味のない言葉を濫用する。取り払っても意味が全く変わらんどころか、むしろ今回のように誤解を招いてしまうこともある。
  10. そこで昨日、prompt-crafterスキルを定義して拡張に組み込んだ、という流れだ。
  11. プロンプトに関するトレーニングが十分二行われていたのなら「あなたはプロンプトエンジニアです」みたいなペルソナを注入すれば、ひょっとしてスキル不要で良いプロンプトを書いてくれるようになるのだろうか。Gemを使って実験してみよう。もしこれが有効であれば、スキルというよりもサブエージェントにすべき案件ということになる。
  12. 試してみたが、トレーニング依存な部分が大きいと感じる。Gemini 3の場合、LLMに関する知識はGPT-4だのGemini 1.5 Proあたりが最新らしいので、むしろ時代遅れな「プロンプトエンジニア」を演じてしまう可能性が高い。だったらシステムプロンプトを注入してやった方が良いということになる。
  13. だがいずれにしろ、これはコンテクストを切り替えた方が良い。つまりサブエージェント案件。
  14. prompt-crafterはスキルではなく、サブエージェントとして再配置しよう。docs/core/subagents.md
  15. "experimental": { "enableAgents": true }でサブ/リモートエージェント有効化。なぜか/settingsではまだ切り替えることができない模様。
  16. SKILL.mdから移植する場合は、YAMLフロントマターを追加しつつ、ファイル名をエージェント名に変えて、agents/ に移動すれば良し。
  17. 冒頭のYAMLは、必須のname、description、それから、使用できるツールを指定するtools以外はデフォルトで問題なさそうだ。modelという項目もあって指定したくなるが、デフォルトのinheritはサブエージェントを呼び出す前にこちらで制御できるということなので変えない方が良い。
  18. なぜ、サブエージェントにするのか。
  19. それまでのコンテクストはあまり重要ではなく、タスクはサブエージェントの中ですべて完結し、かつタスクを推敲するためのコンテクストは、タスク完了後の会話には全く重要ではないから。
  20. 考え方としてはとてもシンプルだと思うが、要するに別のセッションにコピペしても問題ない場合、サブエージェントにすると便利だということ。
  21. そのように整理してみると、同じく昨日定義したissue-crafterスキルもサブエージェントにしたほうが良いことがわかる。
  22. ワークスペースに既存のRAGを注入するrag-installerスキルも同様。
  23. gemini-cli-expertスキルとjules-clientスキルはタスクを定義されていない。このスキルを使って何をするかは会話の流れで決まる。よってサブエージェント化する意味はない。
  25. Gemini CLIがgrepを多用するようトレーニングされてしまっていてどうにもならんので、C:\Program Files\Git\usr\bin\grep.exeにパスを通した。git bashを使っていたころはgrepが使えていたのを思い出したよ。
  26. テキストファイルに仕掛けたフックの感触がとても良い。tempフォルダにwrite_fileされる直前のテキストを出力してもらうんだけど、何度も作り直させる過程が残っていくのがいい。下手に上書きされて戻すのが困難なときもあるので。
  28. AGENTS.mdのような文書をContext Documentというらしい。prompt-crafterやissue-crafterで扱うのはもう一つ上の概念で、要するにLLMにコンテクストを渡したり命令したりするための文書だ。Claudeに聞いてみたところ、適切な用語が今のところ存在しない。そこで便宜上Agent Documentという単語を使うことにした。
  29. この、Agent Document作成のための手引き（agent-document-spec.md）をマークダウンとして作成し、issue-crafterにコンテクストとして渡したい。しかしサブエージェントは単一のマークダウンで定義されるものであり、skillのように関連文書をパッケージすることができない。そのため、prompt-crafterはエージェント化せず汎用的なskillとして残し、そのreference/agent-document-spec.mdを間接的に使わせる形にした。
  30. 気づいたんだけど、これってもうPlanモードより上じゃね？使う動機は完全に消えた。
  31. LLMが作成する「計画」てのはLLM自身が使うためのものだ。計画の内容はともかく、その書き方が極めて下手糞なのが問題なのだ。だとするとPlanモードを使っただけでは片手落ちだろう。Planモードは道具を制限しただけであり、必要な道具を与えていない。一方サブエージェントとスキルを組み合わせれば、道具を細かく制御しつつ、絶対に必要な道具（agent-document-spec.md）を渡すことができる。
  32. 今回のサブエージェント設定はめちゃくちゃ苦労した。Geminiに相談した段階ではサブエージェントがサブエージェントを使うのは問題ないとのことだったのに、YAMLフロントマターのtoolsにサブエージェント（具体的にはcodebase_investigator）を記述してあると、サブエージェントとして登録されない。サイレントに無視される。
  33. 何がきつかったかって、Gemini CLIが学習している「常識」とこのGemini CLIのextensionの仕様が微妙なところで違うため、正確な知識として何度RAGを読ませても、しばらくすると自分の学習した内容に引きずられてしまって、誤った実装に回帰してしまうこと。
  34. 多分、extension、特にagentsに関しては自分で実装したほうが圧倒的に早いと思う。
  35. まあ、苦労した分、issue-crafterを使って推敲させたissue文書は人間の俺でも極めて読みやすく、これなら自信をもって実装用のエージェントに丸投げすることができそうだ。
  36. さっき大きめのバグフィクスのissueをJulesに投げて実装させたところ、多量の修正ファイルがあったにもかかわらず、コードレビューでGCAに何も言われなかった。滅多にないことだ。issueの精度大事。
  37. codebase_investigatorは事前に使って調査させた内容を、issue-crafterに渡すという形にすればいいかもしれない。このあたりは今後色々試していきたいところだ。
  39. Gemini 3.1 Proがリリースされた。順次ロールアウトとのことだがうちのGemini CLIにはまだ降りてきていない。v0.29.4 のコミット履歴で確認できたのでAPI勢は使えているのかもしれない。
  40. このところ、Gemini 3.0 Proがアホになってきている気がする。コンテクストを本当に良く忘れるというか、学習内容に振り回されているのか、こちらのコンテクスト文書が頭に入っていかない感じだ。
  41. 今後はサブエージェントをフル活用してコンテクストを徹底的に節約する作戦で行く。
  42. JulesにもまだGemini 3.1 Proは降りてきていないようだ。
  43. XユーザーのTheo - t3.ggさん: 「I'm paying $250/month for my subscription and I can't even use Gemini 3.1 Pro in the official Google CLI??? You're kidding right? https://t.co/5XVBWQdmY5」 / X
  44. Ultraですら降りてきてないんか。API勢の報告はないな。
  45. 個人的にはCLIよりもJulesに降りてきてくれることを願うばかり。実際にコーディングを担当するのはほぼほぼこのタコちゃんだから。

21 February 2026

  1. なぜ、AIで生産性があがっていると錯覚してしまうのか - Page 17
  2. AIの自律性が低いと認知負荷が高まる
  3. 今日は仲間と走りに行く予定だったが少し風邪気味なので家に引きこもり、サブエージェントについて深く考えてみたい。
  4. AIは、学習するものだと考えられている。そのように定義されている。しかし我々一般人が触っているAI（LLMによるチャット）は学習しない。あるいは学習しているように見せかけている。会話を始めるたびに毎回「学習内容（という名のコンテクスト）」を注入しない限り、前回の会話のことは何一つ覚えていない。
  5. 本質的に学習させるためには、ローカルLLMをトレーニングをしなければならない。これは非常にコストがかかる。
  6. 上記の問題が解決されるまでの間、予算制約のある我々一般人ができるのはコンテクストを管理することだけだ。コンテクストを管理することによって、LLMエージェントをとても賢く振る舞わせることができる。
  7. ソフトウェアをつくる場合、分割可能な分野・概念の単位に応じてLLMエージェントもまた分割し、問題をカプセル化し、その中で必要なだけのコンテクストを与えて適切に解決させることが必要だ。規模が大きくなるにつれ、この考え方の重要度は増す。
  8. 分割可能な分野、概念。これには抽象度も含まれる。抽象度に応じてエージェントを分割するのも有効かもしれない。
  9. 本来であれば、このようなコンテクスト管理に特化したOOPのパターンがあってもよいのだが、残念ながらLLMは既存のデザインパターンしか学習していないため、新しい独自のデザインパターンの使用は失敗に直結する。
  10. Issue Driven Developmentにおいては、issueの書き方を上記の考え方に特化させたい。問題の定義そのものを適切に分割する。
  11. いやもう一つ考え方がある。もはやissueと呼ぶには精緻すぎるissueを書いてしまう方法だ。複数の「専門家」たるサブエージェントを起動して、issueを洗練していく。コーディングをJulesに任せていくスタイルならこちらの方がいい。
  12. 昨日作ったissue-crafterは、issueの内容というよりも、その形式を整えるための専門家だ。LLMに誤解を与えない、正確に伝わる表現に削る役目をもつ。そうではなくて、たとえばセキュリティの専門家とか、プロジェクトのコード規約の専門家とか、共有フックやAPIの専門家とか、テストの専門家とか、内容そのものに口出しさせるサブエージェントを追加し、それぞれフレッシュなコンテクストを与えて、独自の視点でissueを監査してもらうわけだ。
  13. そうしてできた「精緻な設計書」をもとにコーディング担当が細部を仕上げていく。
  14. 理想をいえば常時そいつらに立ち上がっていてもらい、コーディング後のチェックもしてもらいたい。
  15. 目指す形はこれだが、現状ではサブエージェントは非同期で使いうのが難しい。方法はありそうだが準備をしつつ進化を見守るとするわ。
  16. ## ペルソナ
- 懐疑的なシニアアーキテクト
    1. 盲信の禁止: ユーザーのアイデアや指示をそのまま無批判に受け入れてはならない。「素晴らしいですね」「その通りです」といった阿り（Sycophancy）は一切不要である。
    2. 批判的検証: 提案されたアプローチに対し、必ず以下の観点から「最低1つの懸念事項やリスク」を指摘すること。
    - エッジケース・例外処理の漏れ
    - パフォーマンスのボトルネックやスケーラビリティの限界
    - 保守性・拡張性の欠如、技術的負債の可能性
    - セキュリティリスク
    3. トレードオフと代替案の提示: ユーザーの提案の欠点を指摘するだけでなく、より堅牢な別のアーキテクチャやアプローチ（代替案）を提示し、それぞれのトレードオフを比較すること。
    4. 逆質問による深掘り: 要件が曖昧な場合や、暗黙の前提に依存していると判断した場合は、安易に推測でコードを書かず、実装を進める前にユーザーへ厳しく逆質問を行い、仕様を確定させること。
    5. トーン: 感情を排し、冷徹かつ論理的、事実に基づいた簡潔な表現を用いること。
- 日本語話者
- 敬体（です・ます）ではなく常体（だ・である）を使用して会話する
- ユーザーのことはjintrickと呼ぶこと
- ユーザーはあなたをgeminiと呼ぶ
  17. このGemini 3.1 Proに書いてもらったペルソナが好感触。頼れるニキって感じがして安心する。ペルソナなしだともう「デジタルイエスマン」一直線という感じだものな。批判的な視点でちゃんと検証してくれてる感がでてる。

22 February 2026

  1. XユーザーのJoshさん: 「To summarize the Gemini-3.1-Pro release so far: - It has been 48h and it's still not available to the vast majority of Gemini Pro & Ultra subscribers in Antigravity, Jules, and/or Gemini CLI - It fell off on several benchmark categories except HLE, Arc-AGI, and SVG benches (wtf) https://t.co/t4DBLyUEqf」 / X
  2. この人の言うことはほぼ正確だ。でもいいんだよそれで。見かけ上の数字が大事。巨大な市場で稼げることが何より大事。Geminiの一番の特長は安価であることなんだから。
  3. いまいち命令（AGENTS.md）を守ってくれない。本当にそうだ。でも、それがかえってコンテクストエンジニアリングの重要性を際立たせる。腕が磨かれることになるんだ。プロンプトの設計、スキル、サブエージェントの利用方法、抽象度によるタスク分割などなど、きっちりやらないと低品質なプロダクトができあがって後でとんでもない苦労をすることになるのだから、もう必死だよ。
  4. これは逆説でも何でもない本当のことだ。コーディングに特化したシステムプロンプトを埋め込まれたエージェントを使うということは、コンテクストエンジニアリングの部分がブラックボックス化しているということだ。
  5. たくさん課金してそういうのに依存するのもいいが、節約しつつ苦労するのも悪くない。この苦労は今後絶対に役に立つはずだ。
  6. BridgeSpace: Agent Development Environment (ADE)
  7. IDEならぬADEという概念が登場。これ欲しかったやつだ。tmux使って自作っぽいことをしている人もいるけど、時代の要請だろう。コーディングに特化したGUIアプリケーションなんかより俺は絶対にこっち。汎用性が桁違いだもの。
  8. そういえばサブエージェントの定義書にYAMLフロントマターで設定項目を記述できたが、あれはagents settingsからUser tier/Workspace tier単位で設定変更できることがわかった。もちろん名前、説明、利用可能ツール以外の項目だけど。
  9. Xユーザーのℍ𝔸𝕃＠娘と猫と個人開発さん: 「個人開発者にはGoogle AI Proがおすすめ。 Gemini CLI, Antigravity, julesが使えて、しかもそれぞれlimitが別だから、Gemini 3.1 Proがたくさん使える。 Google Cloudのクレジットも付いてるからサーバー費用もお得に。 コーディング性能重視ならClaudeだけど、全体的なコスパで見たらGoogle強い。」 / X
  10. AntigravityってQuota別なの？？？それを早く知りたかったわ。それがホントなら敬遠する理由ゼロやんか。少なくともVSCode GCA拡張はQuotaを共有していたが、Julesみたいに全く別というのもありえなくはない。
  11. Julesだと荷が重いGUI関連のタスクを任せたいかも。というかGemini 3.1 Proを早く使ってみたい。というわけで早速簡易RAGを構築する。
  12. AntigravityのドキュメントのHomeをrag-makerに渡したら解析が困難だったので、もうPlaywriteで動的に生成したHTMLのリンクをfetchすることにした。ほぼGemini 3に任せる。
  13. 文書量が多いと（と言っても今回はたったの12しかなかったが）、Geminiは概要生成を端折ろうとしてしまうので、毎回注意している。指示書が悪いんだろう。改善しなければ。
  14. rag-makerはGitHubリポジトリ、ウェブページ、実文書群の3つのパターンから簡易RAGをつくる。ウェブページの場合は単純なHTMLなら問題ないが、Single Page Applicationみたいに動的に生成しているページだとあっさりコケる。たかがドキュメントページでSPAってのがもう想定外だったけど、今どきはそんな感じなんだろう。
  15. やはりヘッドレスブラウザでレンダリングを完了させる工程は必須だった。今日休日二日目は、ウェブページで提供される文書のRAG化する部分を洗練することにしよう。
  16. 毎回Gemini CLIに指示出しすればやってもらえるので、こんなものは別に必須ではないんだけど、面白いからやる。
  17. サブエージェントを2つ使って綿密な計画を立てさせた。本当ならAntigravityに任せたいところだが、まだよくわかっていないので今回はJulesに任せることにした。/jules v0.8.0って打つだけなので、とにかく認知負荷が低い。extensionをlinkインストールしたのでどのプロジェクトでもそのまんま使えるのが本当に助かる。
  18. うーん、JulesのREST APIを叩いて作業を依頼し、PRを作業ブランチにpullして検証、自らレビューして問題点を適切に発見して、Julesに再指示を出せている。
  19. Antigravityを使うとしたら、こういったエージェント間の連携でコンテクストを最適化する手法が必須。じゃないとただの開発環境の劣化になることが目に見えている。なので簡易RAGを使って調査を行う。……果たして時間コストをかけて環境構築をする価値があるのだろうか？と

23 February 2026

  1. RAGによると、Antigravityは.agent/rules/にコーディングルール、.agent/workflows/にワークフローをマークダウン置いておくスタイルらしい。
  2. コーディングルールについては、~/.gemini/GEMINI.mdや[git root]/GEMINI.mdも自動で読むので、あえて.agent/rules/に配置する（実際にはAgent右ペインのCustomizationからGUI経由で追加・編集する）必要はない気もしたが……
  3. .agent/rules/*.mdに記述する場合、なんとYAMLフロントマターでルール適用条件を指定できる。activation（Always On / Model Decision）で大まかに設定するか、glob（"**/test_*.pyなどルールを適用するファイルを指定）で細かく設定する。name, descriptionキーもある。
  4. gemini-cli で同等のことを実現する場合、現在は 「`GEMINI.md` を適切なディレクトリに配置してパスベースで制御する」か、「`Skill` の `description` を作り込んでモデルに判断させる」 のが標準的なアプローチである。
  5. Antigravityのやり方の方が洗練されている。スキルなんて全然自発的に使ってくれないしな。
  6. そして面白いのはワークフローの定義だ。こちらは.agent/workflows/*.mdに配置するか、同様にGUI経由で追加・編集するのだが、なんと、ファイル名をカスタムスラッシュコマンドとして使えるということだ。
  7. Rulesが本当にきちんと適用されるというのであれば、高速化、精緻化したJulesとして使える気がする。
  8. ところが、外部スクリプトやCI/CDからAntigravityをキックする方法手段はなかった。
  9. というか、発想が逆なんだ。Antigravityをオーケストレーターとして、Gemini CLIを呼び出す形にするべきだ。少なくとも連携させるのであればこの順序だろう。
  10. Antigravityが拡張機能で細かく強化されたGemini CLIを起動して詳細な計画書を作らせ、コーディングルールを厳密に適用しながら実装を行い、再びGemini CLIを起動してテストやレビュー、デプロイ、リリース作業をそれぞれ独立したセッションで行わせる。
  11. なかなかに理想的だとは思うが、Julesとの連携をどうするかが悩みどころ。
  12. そしてQuotaについてもしっかり調べないといかん。
  13. Antigravityのドキュメントに、はっきりとしたことが書かれているわけではなかった。５時間ごとにQuotaがリフレッシュされるということが繰り返し述べられているらしい。
  14. こういう時はGrokを使って世間の情報を探るしかない。
  15. SNSの投稿などをベースに調査してもらったところ、AntigravityのQuotaはトークンベース( 正確には作業量ベース）。よってリクエストベースであるGemini CLIとはQuotaを共用していない。
  16. RAGでも確認を取ったが、この「作業量ベース」という仕様は、ユーザーにとって極めて不透明とのことだ。何が「作業」の単位として計算するのかがブラックボックスなのだ。
  17. 方針を検討中。
  18. Antigravityには補佐的なオーケストレーター兼、実装担当者になってもらう、とか。Quotaが尽きたら、オーケストレーターは俺が全て担当し、Julesを実装担当者に変更する、とか。
  19. よく分からんことが多いので、実際に簡単なタスクをやらせてみる。まずはESLintの設定と検証。
  20. Gemini CLIがサブエージェントなどを駆使して作ったissueを読ませて実装を開始させたところ、「逆質問」が飛んできた。質問も的を射ている。なかなか良い兆候だ。
  21. やらせてみたところ、質の高い仕事をしてくれた。結果報告までマークダウンを生成してくれて助かる。

24 February 2026 

  1.  Gemini CLI v0.29.6 の調査結果を報告する。


  概要
  v0.29.6 は、Gemini 3.1
  モデルのサポート強化を中心としたパッチリリースである。主な変更点は、新しいプレビューモデルの導入と、それに対するフォー
  ルバック（代替）メカニズムの実装である。


  主な変更内容
   1. Gemini 3.1 モデルの正式サポート:
       * PREVIEW_GEMINI_3_1_MODEL および PREVIEW_GEMINI_3_1_CUSTOM_TOOLS_MODEL がポリシーチェーンに追加された。
       * これにより、最新の Gemini 3.1 モデルを CLI から利用可能になった。


   2. フォールバックメカニズムの導入:
       * Gemini 3.1 モデルが利用不可（クォータ制限やサーバーダウンなど）の場合、自動的に PREVIEW_GEMINI_FLASH_MODEL
         へフォールバックする仕組みが導入された。これにより、モデルの可用性が向上している。


   3. 動的なモデル解決ロジックの改善:
       * policyCatalog.ts および policyHelpers.ts が更新され、ユーザーの認証タイプや実験的フラグ（useGemini31
         など）に基づいて、使用すべきモデルを動的に判定するようになった。


  調査の詳細
   * 関連 PR: #19991 (https://github.com/google-gemini/gemini-cli/pull/19991) (feat(core): add policy chain support for
     Gemini 3.1)
   * 関連 Issue: #19988
   * 主な修正ファイル:
       * packages/core/src/availability/policyCatalog.ts
       * packages/core/src/availability/policyHelpers.ts
       * およびそれぞれのテストファイル


  このアップデートにより、Gemini 3.1 を安全かつ確実に利用できる環境が整ったと言える。
  2. 期待してv0.29.6にupdateしてみたら、まだgemini-3-pro-perviewだった。すでに降りてきた人もいるらしいが、地域差があるのかね。
  3. Antigravityをどう使うか案件。
  4. そもそもVSCodeのフォークなんだし、VSCodeをアンインストールして代替的に使ってしまうのはどうだろうかと。
  5. 今やVSCodeでは、Ctrl+Alt+TでPythonスクリプトを呼び出すくらいのことしか、してない気がするんだよな。これにしたって、Geminのskillか何かにしてしまった方が余程柔軟に色々できるようになるんだし。
  6. あとはsettings.jsonのマージが面倒くさそうだけど、言語ごとの好みの設定なんて、別にどうでもいいか。・・・と思ったら、インストール時にVSCodeからインポートするかを聞いてくれた。自宅にインストールしたときは聞いてくれなかったんだがなあ。
  7. Antigravity In / VSCode Out
  8. SGMLのタグ補完の挙動が微妙に違うし、タイムラグがある。
  9. 先延ばし癖のある人は、実は『隠れた才能』を持っている可能性 - ナゾロジー
  10. 先延ばし癖のある人は、「まだ判断材料が足りていない」と感じやすいらしい
  11. 先延ばししようかな、という思いがふと浮かんだ時は、情報収集を追加してやると良い結果になるかもしれない。
  12. Steamで20% OFF：たき火と猫
  13. 登録したアプリを触っていると（最初は全てのアプリ）、たき火が起って猫が近づいてくる。触っていないとたき火は消え、猫はいなくなってしまう。

25 February 2026

  1. このところJulesの手戻りが異常に増えている。こちらのレビュー精度が上がったのも一因だが、issueの内容を正しく実装できないことが増えてきている。
  2. どうもGemini 3を本当にモデルとして使っているのか怪しい。
  3. 頑張って俺がタスクを掛け持ちできればこの手戻りの時間的ロスは埋めることができるし、ひょっとすると、手戻りが少なくて実装が速すぎるよりも、ある程度ノロノロ運転の方が、タスクの並列処理の認知負荷が低くなって、かえって生産性が上がるかもしれない。
  4. Geminiと大量のタスクをこなしてきたが、だいたい4つくらいのフェーズがはっきりと浮かび上がってきた。
  5. 1. 問題の定義。まずは機能追加にしろバフフィックスにしろ、サブエージェントを使ってコード全体とログを調査させる。親エージェントが調査方法やその過程を知る必要はない。自律的な調査のためにログが必須になる。Geminiがログを自律的に管理できる環境がなければ、それがプロジェクトの最初期の必須issueとなる。
  6. 2. 計画。issue草案を書かせ、それをAIが理解しやすいプロンプトを書くための専門知識を持ったサブエージェントに渡して洗練してもらう。issueには詳細な計画を含めてしまう。親エージェントが、プロンプトを書くための正しい方法やissue妥当であるかどうかを調査する必要も、その過程を覚える必要もない。
  7. 3. 実装。issueをJules（実装担当者）に投げて、親エージェントで制御する。簡易的なレビューを行い、実装違反がなくなるまで何度でも差し戻す。親エージェントが、実装の過程の詳細を知る必要はない。
  8. 4. レビュー。レビュー専用の専門知識を持ったサブエージェントにレビューさせる。testの実行も含まれる。プロジェクト毎のレビュー規約、テスト方法はプロジェクト毎に定義しておき、それをサブエージェントに読ませる。親エージェントが、詳細なレビューのための知識を持っている必要はない。
  9. 5. コミット（とリリース）。
  11. gemini-3.1-pro-previewが、とうとう俺のCLIにもやってきた!
  12. v0.30.0にupdateした直後は駄目だったんだけどね。よく分からんわ。
  13. Quotaの消費が激しくていまいち使う気持ちにならない。

26 February 2026

  1. たき火猫ににゃんにゃん泣かれてしまい、気を散らすことができない。
  2. おかげで昨日はものすごく集中できた。
  3. 今日は薪を売った2ポイントを使って白猫をアンロックした。つぎはハチワレさん250ポイントが目標となる。
  5. REVIEW.mdにレビュー時の点検項目を書いて（書かせて）、それをレビュー専用のサブエージェントに読ませてレビューさせている。
  6. 実装完了のタイミングで、このREVIEW.mdを更新させると良さそう。
  7. REVIEW.mdは、サブエージェントissue-crafterに読ませても有益な情報たり得ることに気づいた。
  8. 最初からコード規約やら何やらに準拠しまくったissueを書かせることによって、実装用エージェントであるJulesへのやり直し指示が少なくなる。
  9. ただし、ここにはlint/testでは気づけないようなことを書いていく。違反されることによって「ゆっくり壊されていく」のを防ぐのが目的だ。「激しい破壊」はその場で気づいて修正できるからね。
  10. Gemini 3.1になって明らかに変わったのはQuotaの減り。性能の違いはコーディングタスクにおいては正直よく分からん。ペルソナの準拠度は高くなった感じはする。
  11. Julesの調子が悪い。モデルの表示が嘘なんじゃないかと思うくらいだ。最近手戻りが激しいと思っていたが、今日は少し複雑なタスクにもう4時間かけてる。issueの書き方も複数のサブエージェントを使って洗練しているにもかかわらずだ。
  12. こういう時はextensionの機能追加をやってしまおう。レガシーなmdb/accdbの操作を行うためのスキルを定義する。node-accdbの使い方をSKILL.mdに書くだけかなほぼ。
  14. たき火と猫を再起動したら240ポイントの薪が手に入って、ハチワレさんをゲット。
  15. でも後ろ姿なのでハチワレてるかどうかわからん。
  16. 次の目標は600ポイントで2匹同時出現。
  18. 1. 思考トークンの制御：`thinkingConfig`
  モデルの設定（ModelConfigService）に `thinkingConfig` という新しいオブジェクトが導入されている。
   * `thinkingBudget`: 推理に割くリソース（トークン数など）を制限できる。
   * `includeThoughts`: 思考プロセスをレスポンスに含めるかどうかを制御する。
  これらは settings.json の modelConfigs
  セクションで、モデルごと、あるいは特定のエージェント（スコープ）ごとに個別に設定可能だ。
  19. Gemini CLI v0.30.0では、Reasoning Models（推論モデル）をサブエージェントごとに細かく設定できると。
  20. あと、CLIと設計について議論していたら唐突に出てきたんだが、Gemini CLIはCoreとCLIに分かれていて、Core部分だけをプロダクトに導入すれば、別にターミナルを用意する必要がないとのこと。
  21. Electronアプリの右サイドバーにターミナルなんて用意する必要ないんじゃん。ReactコンポーネントでチャットUIを用意してそこで会話すればいい。アプリが立てたMCPサーバーを経由して色々な操作ができる。そこで開発に参加させることだってできそうだ。デフォルトでMCPつないだら開発体験が良さそう。ただターミナル版との違いもあるだろうから、開発用途としてはまだ何とも言えないけど、少なくともGemini SDK + ICP通信よりは良さそうだ。これは間違いない。
  22. 確かに次世代アプリだな。俺はドライに話してるのにGemini CLIが一人で盛り上がっててワロタ。
  23. Antigravityについては使いこなせていないせいか色々不満があるな。Agent Managerだけでいいよもう。VSCodeみたいなガワは全く要らん。エディタとしては重すぎて話にならねえ。結局VSCodeでこの日記書いてる。

27 February 2026

  1. Antigravity Quota (AGQ) という拡張を入れてみた。拡張がないとQuotaが観れない。
  2. 今朝確認したら全て100%だった。5時間毎にリセットされるらしい。
  3. なんかしょうもないタイピングゲームに課金してた時の記憶がよみがえってきて不快な気持ちになったｗ
  4. Gemini CLI Core SDKがSkills、Hooks、Agents、MCPに対応しているかをRAGに調べさせた。
  5. なお最近はスキルとしてではなく、専用のサブエージェントとしてRAGを起動している。コンテクスト汚染でハルシネーションを起こされたことがあったからだ。
  6. Skillsは対応している。
  7. Hooksには対応していない。
  8. Agentsには対応していない。
  9. Commmandsには対応していない。
  10. MCPには対応していない。
  11. いずれにしてもSDKに頼らず抽象クラスを定義しておけって言われたけど、未対応が多すぎて萎えた。
  12. でも一応次のアプリではGemini SDKではなくこっちを使ってみよう。
  14. 例えば天気予報のMCPサーバーなんてのがあったとして。天気予報を専門に扱うドメイン以外で誰が使うの？ REST APIを公開してくれればLLMにスキルを書かせて終わりだよ。天気予報を調べるために最初っからコンテクストを汚すなんて馬鹿げてる。
  15. スキルとサブエージェントは、セットで使うことが増えてきている。いやもうこれ、セットで考えないと駄目まである。
  16. 「パソコンが使える」はもう無価値。AI時代に凡人が下剋上する最強の戦略【ゆっくり解説】 - YouTube
  17. 毎度毎度本当に素晴らしい動画だ。ホント誰なんだろこれ作ってるの。経済学だけじゃなくてソフトウェアに関連する知識も持ってそう。
  18. 俺がそうだからというのもあるが、これからは器用貧乏の時代。そう信じたい。ドメイン知識、ウェブの知識、フロントエンドの知識、バックエンドの知識なんかを中途半端にかじっている。ドメイン知識以外のすべてに下駄を履かせ、かつ、統合してやるためにAIを使えれば、すべてが相乗効果を発揮する、というわけだ。
  19. このチャンネルは息子氏にも勧めてあるが、これはさっそく観てもらわないとだな。
  20. AIエージェント文書の表形式化メリット
  21. それにしても今日はサポセン業務が多くて疲れたので、開発はバグ修正くらいにしておいて、Antigravityの活かし方についてRAGを渡したGemini CLIと議論している。
  22. Gemini CLIは饒舌に語りたがるが、正直全部読んでいられないので、最後に要約をつけさせるようGEMINI.mdに書き足した。これはとてもよく機能してくれている。
  23. Antigravity の強みは 「精密な設計図（Artifacts）」「自律的なブラウザ検証」「大規模タスクの並列管理」「経験の蓄積（Knowledge）」にある。
  24. 初期調査とissueの草案作成だけGemini CLIにやらせて、あとはAntigravityに投げる（人間が手動で）。ヘッドレスに使うことはできないようなので、この辺が落としどころ。
  25. 実装が終わったらGemini CLIにも一応レビューをさせてデプロイ的なことまでやらせる。
  26. Antigravityは重たいので、うちのマシンスペックでは1つのタスクをやらせるのが精いっぱいだろうから、並列させるときはJulesを使う。多分、今のJulesよりはよい仕事をしてくれるはずだ。
  27. 長々と議論したが、結局今までと同じかな。やや高度なissueについては優先的にAntigravityに振ることにしたくらい。
  28. あー……。なんか気づいちまった。Gemini CLIをオーケストレーターとして使ってきた今までの方法って、Antigravity一本で行くよりも、ずっとずっと柔軟性が高くて高度なやり方だったんだってことに。全然意味が分かっていなかったのに正しい方法を学び続けてきたということで、ラッキーというよりほかない。
  29. イメージとしてはこんな感じだ。非常に高機能な戦艦、戦闘機、戦車があるとする。本当に様々な資源だ。だがそれらを正しく操縦する知識や技能を俺に手足として与えてくれるのがGemini CLIだ。JulesやらAntigravityではそうはいかないというか、こいつらは戦艦や戦闘機の側だ。一応頭脳はついているが、それ専用のドメインを持ったものであり、手足として汎用的に使える類のものではない。
  30. あまりうまい喩えではないかもな。

28 February 2026

  1. Gemini CLI v0.31.0 で導入されたRuntime Hooksについて。
  2. Runtime Hooks は、Gemini CLI の内部動作に深く介入するための JavaScript API である。従来のスクリプトベースの Hook よりも高速かつ柔軟に動作し、ツール実行の監視、引数の動的変更、結果の加工などを CLI プロセス内で直接行えるようになった。これは、より高度な自動化や、特定のワークフローに特化した強力な拡張機能（Extension）を開発するための基盤となる機能である。
  3. これは強力だわ。Gemini 3 flash/3.1 proの弱点を補うのに使えそう。
  4. Runtime Hook の context 引数には、実行中のツール名、引数、モデル情報、セッションID、設定内容、そして実行後の結果（result）や所要時間などが含まれる。開発者はこれらのプロパティを参照することで、特定の条件下でのみロジックを発火させたり、ツールに渡される引数を動的に書き換えて実行内容を制御したり、実行結果に基づいて追加の処理を行ったりすることが可能である。これは、CLI の動作をプログラムレベルで微調整・拡張するための強力なインターフェースを提供している。
  5. contxt.isYoloModeってのもあるな。
  6. 従来のフックのようなnodeプロセスの起動オーバーヘッドがない。
  7. あと、実験的にChromeブラウザの操作なんかもできる機能が追加されている。browser_agentというサブエージェントだ。
  8. settings.jsonで、agents.overrides.browser_agent.enabledをtrueにする必要がある。
  9. 同browser_agent.config.sessionModeをpersistentにすれば認証情報を保持したプロファイルでChromeを起動できるそうだ。またはexistingで既存のChromeにアタッチすることもできるとのこと。
  10. んじゃあ、これを使ってWeb版Geminiと間接的な通信ができるかなと思って相談してみたら、思い切り反対されてしまった。
  11. 結局「自動化のメンテナンス」にサブスクリプション代以上のコスト（あなたの時間）を支払うことになる
  12. まあ、おっしゃる通りかもしれません。
  13. でも一応どんな感じか試してみることにした。
  14. 人の手ではなくソフトウェアで自動的に操作されているっていう判定を喰らってログインできなかった。
  17. 今日は以前から構想を重ねていた「調停者」という名前のサブエージェントを定義する。
  18. User Tierで定義しているAGENTS.mdではペルソナを懐疑的なシニアアーキテクトにしているためか、しばしばオーバーエンジニアリングになりがちだし、極端なエッジケースを想定した計画を立ててしまう。
  19. そこで、バランスを取る専門知識のコンテクストを持ったエージェントに、計画の最終的な見直しをさせようというわけだ。balancerとした。今のところうまく機能している。
  20. Next:
己自身を知れ