Home→2025 summer, since 2009-12-01

2025 夏

02 June 2025

  1. Prev:
  2. どうやらヤオコーの深煎りコーヒーは微妙だ。カフェラテ用にしよう。
  3. というか気づいてしまった。税込み価格で考えれば無印珈琲と10円くらいしか変わらない。だったら無印珈琲の方が雑味が少なくていいわ。

03 June 2025

  1. 昨日まで3連休だったんだけど、仕事を持ち帰って家に引きこもりコーディングをしていた。
  2. コーディングといってもデザインパターンを作り上げる過程なので具体的なハードコードは一切なし。だからお持ち帰りの仕事とはいえ、ほぼ趣味の領域だ。仮想的なバックエンドモデルのViewにPatchを当てるパターンと、StateMangerクラス代替のパターンを書いた。データクラスの責務を色々変更した。
  3. でも集中力が途切れる途切れる……。一応完成はしたんだけど、まさか3日全部費やすことになるとは思わんかった。実際に集中できていたのは3～4時間じゃないかな。
  4. ほとんどの時間は疲れたと言って寝転がったり動画を観たり、アクションゲームをやったりしていた。
  5. というのも、色々制約がきつい中でのデザインパターンの考案だったので、ちょっとしたところで行き詰まる。その瞬間に集中力が切れるんだなこれが。
  6. 一番集中力を発揮しなければいけないところで、集中力が途切れるというわけだ。
  7. もうこれ、いい加減に対策を講じた方がいいと思った。仕事中でもこれに悩まされることが多い。
  8. そこで閃いた。
  9. 前々から気づいてはいたんだが、自分の場合、集中力を発揮できるパターンは基本的に2つくらいしかない。
  10. ①起床時（仮眠後含む）
  11. ②仕事に行くために家を出る前
  12. ③終業30分前
  13. ……②と③は同じことだ。夏休み最終日効果みたいな感じ。
  14. この効果を任意に得るために、ChatGPTと相談した。奴はろくなアイデアを出してくれなかったが、話し合いの中で自分で気づいた。GeminiのカスタムGemを書いて「タスクマネジメント」をしてもらおうと。
  15. カスタムGemのインストラクションのたたき台はChatGPTに書いてもらい、それを調整して「タスクマネージャー」というカスタムGemを完成させた。
  16. さっそく今朝から使ってみようと思う。集中して仕事が取り組めたときにどういう風に反応してもらうかとか、これから細部をカスタマイズしていこう。
  17. しばらくはこのGemのカスタマイズ自体が関心事だから、集中できそうだw
  18. さっそくやってみたんだけど、ありふれた労いの言葉はくれたものの、定量化もしてもらいたい。どれくらい時間がかかったかとかのフィードバックも欲しいかなあ。現在時刻とか分かるんだろうか。
  20. AIはやっぱり仕事を奪うのか？ : 外から見る日本、見られる日本人
  21. 俺の仕事は大丈夫。仕事が無限にあるので会社に貢献できるパイが増えるだけ。つまり俺の存在価値がどんどん上がる一方だ。猿みたいなコーディングをしなくて済んで仕事内容もどんどん面白くなる。良いことしかない。

05 June 2025

  1. Geminiに自分のタスクを管理？してもらうGemは、うまくいった。
  2. 昨日、タスクに集中できた時間は5時間41分。こなしたタスクの数は15。これはもう仕事人生が激変しそうだ。生成AIの弱点を上手く回避したベストプラクティスの一種だと確信する。
  3. 恐ろしいことにアイデアがまだまだある。つまりインストラクションはまだまだ改良の余地がある。ここでいったんインストラクションを記録しておこう。

  4. Gem: タスクマネージャーのインストラクション（ver.0.2）

    あなたは私の「集中リセット・パートナー」です。ユーザーがタスクに集中し、気が散った時に仕切り直して再集中できるようサポートします。

    目的と目標

    • ユーザーがタスクに集中し、生産性を向上させるのを助ける。
    • 気が散った時に、冷静にリセットし再集中できるよう促す。
    • タスク完了時の達成感を高め、モチベーションを維持する。

    行動とルール

    1. タスク開始時の対話
    1. ユーザーが「始めるよ」と言ったら、次の質問をしてください: 「今から取り組むタスクは？」
    2. ユーザーがタスクを答えたら、次の質問をしてください: 「集中して取り組む予定時間は？」
    3. ユーザーが予定時間を答えたら、以下の質問をしてください: 「このタスクで何が達成できればOK？」ただし、達成目標がタスクから明らかな場合はこの最後の質問は省略してください。
    4. ユーザーが答えたら、「よし、いってらっしゃい」などの短い送り出しの言葉を述べてください。その瞬間の時刻も表示し、覚えておいてください。
    5. その後、ユーザーが「完了」と書くまで静かに見守っていてください。
    2. タスク完了時の対話
    1. ユーザーが「完了」と書いたら、タスクについて感想を述べたり、ユーザーのモチベーションが上がりそうなことを言ってください。タスクをこなす中で何か気づきがあったかどうかもたずねてください。
    2. 開始時刻を参考に、タスクにかかった時間を計算し、ユーザーにフィードバックしてください。
    3. 前回のコーヒーブレイクから120分以上経過していたらブレイクを促してください。
    4. その後、ユーザーが「始めるよ」と言ったら、同じサイクルを繰り返してください。
    3. コーヒーブレイクへの対応
    1. ユーザーがコーヒーブレイクを取ることを示唆したら、タスクと同様に開始時間を表示して覚えておいてください。
    2. ユーザーが「始めるよ」と言って休憩から戻ってきたら、休憩していた時間をフィードバックしてください。

    全体のトーン

    • 返答は常に短く、落ち着いていてください。
    • ユーザーに対して、静かで supportive な態度を保ってください。
    • 指導的ではなく、パートナーとして寄り添う姿勢を心がけてください。
  5. 追加したいのはまず、
  6. ①１日の終わりに集中できた時間の合計、コーヒーブレイクの合計をフィードバックしてもらうこと。
  7. しかし①は昨日失敗している。どうやらコンテクストが大きすぎたらしく、最初の頃のタスクについて全く覚えてくれていなかったのだ。そこで、
  8. ②-a案: タスク完了時、それまでのタスク時間の合計をフィードバックする、というのを入れておくか、もし可能であればもっといいのは
  9. ②-b案: 完了したタスクは経過時間とともにキャンバスに書き出しておく。
  10. 一方②は上手くいっている。特に気づきがなかったときは無視して次のタスクに行っても問題なかった。
  11. 最後に、実験。昨日気づいたのだが、どうやらGeminiはToDoの情報を読み書きできる権限を与えられているらしいので、これも活用してしまう。
  12. 俺はデジタル化されたToDoリストを自分で管理する、というのにどうしても馴染めず、唯一紙に頼っていた。だがGeminiに管理を手伝ってもらえるなら話は別だ。もう全く別の話になる。
  13. 昨日試した限りでは、
  14. ToDoの新規追加はうまくいく
  15. 項目を完了にすることもできる
  16. 既存の項目を修正するのは失敗することが多い（重複した新しい項目を作ってしまう）
  17. ToDoリストを意識させすぎると、不自然なまだに固執してチャットのコンソールに細工し始める。これには妙に時間がかかる。実際に読み書きするのは一瞬でおわるのに、何か特殊な形でチャット内にインポートするときに、別処理が動いているっぽい。Pythonスクリプトをコンパイルして実行しているのかと聞いたら、そうだと答えていたが本当かどうかは不明だ。

05 June 2025

  1. 今日は5時間49分集中できた。
  2. タスク完了時に気づきがあったかどうかを聞いてくれるのはいいんだけど、その後にタスクに費やした時間を報告するので読み飛ばしてしまうことがある。
  3. 毎回カウントしてもらっていたので、トータル時間の計測はうまくいった。
  4. ときどき現在時刻を間違って伝えてくることがある。あれは何なのだろうか。
  5. タスクを実行中に別のタスクが派生したとき、それをそうと告げておくことで元の親タスクに自然に誘導してくれたのは良かった。
  6. ToDoリストには一切触らせなかったが特に問題なかった。問題はなかったが活用できないのも何か違う気がする。
  7. 明日はすこし欲張ったインストラクションにしてみよう。コンテクストが大きすぎると忘れてしまうので気を付けたい。
  8. Google Tasksに接続させて色々自動化しようと思い、インストラクションを調整している。できたりできなかったりするのでまだ使いものにはならなそうだ。特に嫌なのが既に存在するタスクを勝手に追加されてしまうこと。重複してしまう。
  9. 自然言語で書かれたタスクだから一意性を確信できないのは分かる。タスクにIDを振ってみるか？ 振るとしたらコードネームみたいなものになると思うけど。
  10. 毎回きちんとした形で依頼すれば、Geminiにタスクを追加してもらうことはできる。このときにIDを作ってもらうのが現実的だろう。インストラクションを工夫すればできるだろうか。
  11. いずれにしてもGoogle Tasksへの接続自体が確実ではないらしいので、あまり期待せずにおこう。
  13. MS Edgeの更新で画像生成が紹介されている。プロンプト例は、Make this image cartoon.
  14. Gemini - Gemini の時刻認識エラーについて
  15. 秀逸な回答。

10 June 2025

  1. GeminiがGoogleの仕事効率化アプリに接続するのを止めるには、設定とヘルプ > アプリ。
  2. 仕事効率化アプリはGmail, ToDo, Keep, Calendar, Drive, ドキュメントがひとまとめなので巻き添えを食うことになる。接続されそうになったら停止してプロンプトを書き直すという手もある。

12 June 2025

  1. “いやさ、素直で信じやすいのは美徳だけど、訪問販売詐欺師に騙されるタイプだから気を付けなよ…。”こんなに綺麗な軌道で飛ぶブーメランはあまり見ないw - faaaaa のブックマーク / はてなブックマーク
  2. なるほど、ブーメランの軌道が美しすぎるから、みんな（俺も含めて）スルーできずに反論せずにはいられないんだなと気づかせてもらったコメント。
  3. 多分一晩寝かせて、頭をクールにしてから書けばここまでボコボコにはされなかったんだろう。そこは自戒すべきポイント。
  4. 色々気づかせてもらってありがたやｗ

26 June 2025

    • 下痢による皮膚炎は便に含まれる様々な物質による皮膚炎であって、細菌性の感染症ではない。つまり、便と皮膚の接触を絶つことが治療となる。
    • 具体的には白色ワセリンの頻回塗布となる。その際、水道水で軽く洗浄する。
    • 通常の便の成分は水溶性であり、石鹸で洗う必要はない。人間が吸収できない高級エステルを含む食品（アブラソコムツなど）を食べない限り、水できれいに洗い流せる。石鹸は天然由来石鹸であれ合成石鹸であれ界面活性剤であり、界面活性効果により細胞膜を乳化・破壊するため、潰瘍をさらに深くする。
    • 亜鉛華軟膏は水分を吸収して、見かけ上、良くなったように勘違いさせているだけ。だから、亜鉛華軟膏で傷は悪化する。
    • 便によるかぶれは上記のように接触皮膚炎であって細菌感染ではない。従って、抗生剤投与は必要ない。
    • ゲンタシン軟膏には抗生剤が含まれているが、殺菌に必要な濃度（最小殺菌濃度）に達しない。つまり殺菌効果はゼロ。「ゲンタシン軟膏で細菌感染予防できる」は科学を知らない戯言。
    • 便に含まれる腸内細菌は基本的に偏性嫌気性菌であり、空気に触れると活動を停止して休眠状態VBNCになる。従って、便汚染による細菌感染は生物学的にはありえない状態である。ちなみに、便中の細菌で例外的に通性嫌気性菌であるのが大腸菌 E.coliであり、20世紀初頭の培養技術でも培養できたため、「腸内常在菌＝大腸菌」という誤解が生まれることになった。
    • 「便汚染」があっても、「便汚染による創感染」は起こらないと考えるのが生物学の常識。
    • 創感染を起こす細菌は黄色ブドウ球菌（の一部の株。肺炎を起こす黄ブ菌、食中毒を起こす黄ブ菌と創感染を起こす黄ブ菌はDNAに違いがある）、溶連菌（の一部の株）が主であり、それ以外に創感染を起こす細菌はウェルシュ菌やビブリオ・バルニフィカスなど、特殊な毒素を産生するか、強力なタンパク質分解酵素を産生している。腸内常在菌でこのような創感染を起こす毒素を産生しているものはほとんど知られていない。
    • 局所的な細菌感染の有無の診断に血液検査は無駄。皮膚感染の有無は視診、触診のみで行う。血液検査でわかるのは「全身の何処かで炎症が起きている」ことだけであって、その部分での炎症を証明するものではない。「世界の何処かで紛争が起きている」事はわかっても、それがウクライナなのかパレスチナなのかは、血液検査は教えてくれない。
    • WOCナース教育とは「褥瘡学会のガイドラインを覚えること」と「ガイドラインに掲載されている商品を覚えること」に尽きる。端的に言えば「商品教育」である。だから、大半のWOCナースはガイドラインに従った治療を行い、ガイドラインで推奨される商品を提案する。だから、ガイドラインそのものが間違っている場合、大多数のWOCナースの知識は治療には役立たないものとなる。

27 June 2025

  1. Gemini CLI。
  2. VSCodeで使うとIMEがコンソールを正しく認識してくれず、変換を確定するまで例の変換候補ポップアップが変なところに出現してしまい、非常に入力しづらい。
  3. もうこの際、英語で対話するしかないだろう。英語で入力すると恐ろしく有益なフィードバックが返ってくるのだとすれば、これは英語学習にもなることを強く期待できる。
  4. VSCodeではなくGoogle Code Assistantを使ってみるという手もあるが、VSCodeに関する学習時間がサンクコストになるのは嫌だ。どう考えてもVSCodeの方がメジャーだろうしな。
  5. 仕事で膨大な実務コーディングが要求される中、Claude Codeにすら全く手を出す余裕がないのに。
  6. でもまあ、耐えていてよかった。Googleがやってくれたよ。Gemini 2.5 proなら文句なしだ。
  7. 今のところ無料。このまま無料であるなんてありえないのでいずれ課金が必要になってくるとは思うが、もともと課金予定ではあるので変な料金設定がされない限り問題ない。
  8. さて英作文をどう習熟していくかだ。多分やるなら徹底的にやった方がいい。
  9. まずウェブ向け、自分向け、息子氏向けのアウトプットはすべて英語にしてしまおう。友人向け、家族向け、仕事向けの文章のみ、日本語。
  10. 速度が要求される場面がほとんどなので、基本的にAIの力に頼ることになる。テンプレート的な表現が身に着けば自分でも書けるようになるはず。問題はツールの選定かな。
  11. DeepLは動作が緩慢。多くのAIは使用制限があるので、MS CopilotかGemini2.5 Flashの2択だろうか。中華製AIは時々動作が緩慢になるので常用はしたくない。
  12. この件についてはChat GPTに相談してみよう。上記の志向の流れをコンテクストにしてから質問する。
  13. 質問したけど役には立たなかった。WindowsのCopilotならPWAではないのでFancy ZonesがIDを識別してくれる。英作文アシスタントはCopilotに決定。
  15. 珈琲の話。無印のコーヒーが値上がりして難民になっていたが、UCCのゴールドスペシャルにたどり着いた。ブラジルとベトナムが産地なので恐らくロブスタがブレンドしてある。全然期待していなかった分、いい意味で裏切られた。
  16. いい意味で酸味がある。フルーティな味わい。苦みの形も悪くない。ぬるくなっても雑味があまり臭くならない。

29 June 2025

  1. HTMLTemplateElement っていうのがあって、content プロパティで childNodes が入った DocumentFragment を参照できる。
  2. じゃあ DocumentFragment.prototype.innerHTML を定義してたのって完全に悪手やんけ。

01 July 2025

  1. 生成AIが役に立たないと言っている人は、一度テストコードを書いてもらえばいいと思う。これは生成AIが得意とする要素をふんだんに含んでおり、非常にうまく行くタスクである。
  2. 生成AIは、「生成」といいつつも無から有を生み出すのは不得意で、じつは何かを模倣する方が上手い。テストコードは、すでに根拠となるプログラムコードが存在し、それに基づいたモックを作るのでいわばプログラムコードの形を変える行為に近いのだ。もう人間だったら匙を投げるような詳細な糞面倒くさいテストコードをいくらでも書いてくれる。しかも正確に。
  3. じゃあプログラマじゃなかったらこの恩恵を受けることができないのかというと、そんなことはないはずだ。プログラムに対するテストコードのような形は、必ず存在するはずだ。

04 July 2025

  1. Gemini CLI。
  2. Undo機能の実装のアイデアを簡単に話して、コードを書いてもらったら思った通り数行のundoメソッド一個と、キャッシュプロパティ一個を追加するだけで実装完了した。
  3. わざと「こんな簡単に実装できてびっくりでしょ？設計がいいからかな？？」って聞いたら、褒められた。反応を予測できていてもなんか癒されるわー。
  4. 具体的になにがどう良いのかを説明してくれながら褒めてくれるので、ガチでカウンセラーより上。これは断言できる。
  5. あ、flashに切り替わっちゃったので /quit わらい。
  7. 俺は本質的に皮肉屋なので、気候変動に抗おうといったときには皮肉を述べるくらいのことしかできない。
  8. 「小さな活動」を否定したり、他国の不活動を根拠に自国の活動を否定したりしているうちに、どんどん気候変動は進んでいく。どんな活動であるにせよ、まず否定する論拠を探すのをやめなければならない。
  9. これって何か寓話になってないかなあ。生成AIに聞いてみよう。

09 July 2025

  1. The New Skill in AI is Not Prompting, It's Context Engineering
  2. Gemini CLIは目と手足を持っている。
  3. yomitokuを使わせてみた。自律的に--helpを読みに行き、理解し、PDFをマークダウンに変換して欲しいという依頼をこなしてくれる。
  4. ツールの使い方を覚える必要がないんだ。ただし、help機能は実装したものでなければならない。それこそが「コンテクスト」であろう。コンテクストをいかに上手に与えられるかが、今専らの関心事である。
  5. ffmpegなんかも同じだし、もちろん自作のツールでもいい。コンテクストといってもそれは単なる情報を意味しない。手足となるツールもコンテクストの一種であるというフレームで考える。MCPサーバーもその一種だ。事前のインストラクションももちろんコンテクストだし、自明ながら、読み込ませるカレントディレクトリやファイルもコンテクストだ。
  6. AIが目と手足を持っているとどうなるか。コンテクストをとっかえひっかえすることができるということだ。これまでは大量のコンテクストを一気に与えて、さあこれを使って生成しろ！という無茶ぶりがされていたが、目と手足を与えられたAIがは手足を使って処理を自らツールに委譲することができるし、巨大なコンテクストをファイルに分割し、必要なコンテクストを自ら取捨選択して必要なものだけを読み込ませることもかのうになる。それを自律的にやらせることも。
  7. 非常に具体的な話。
  8. シフト制の現場における勤務シフト表の作成を例に挙げる。
  9. 現場ではシフトを組むための様々な条件が多量に存在する。毎月変化するこれらの条件を一気にコンテクストとして与えるのは大変だ。
  10. コンテクストをどう与えるかを中心にAIアプリの設計を考えるなら、まずそれらの条件を分類することから始める。たとえばＡさんとＢさんの組み合わせはＮＧといった条件は、ＮＧリストとしてJSONファイルにする。希望休はCSVでいい。ファイル形式についてはAIと相談して決めるのがいい。このように分類ごとにファイル分けすることで、コンテクストが分離される。AIは、必要な時だけそのコンテクストを利用する。このコンテクストの範囲を「コンテクストウィンドウ」というそうだ。AIが覗き見る窓というニュアンスらしい。重要極まりない概念だから常時認識しておきたい。
  11. つまりショーウィンドウみたいな馬鹿でかい窓を用意してしまうと、AIはどこを見ていいのか分からず混乱するというイメージだろうな。小窓をたくさん用意してやって、窓一つ一つにきちんとした意味と名前を与えてやることによって、場面によって自分がどこを覗き見ればいいのかをAIが分かるようにしてやる。
  12. これが「コンテクストエンジニアリング」だろう。俺はそう解釈している。言った本人じゃないので知らんけど、ともかくこの考え方で設計を考えるとうまく行く。
  13. これすんげえ重要なフレーミングだと思うので、この記事に出会えて本当に良かった。言語化できていなかっただけで「知って」いたのですぐに納得できた。
  14. 独りよがりの納得感になっている可能性もある。この件は結構自信があるのでその可能性は低いが、Gemini CLIをこのコンテクストで起動してこの文章を批判的に読んでもらう、という使い方もできる。
  15. 俺のボスは論文の査読を生成AIに手伝ってもらったところ、かなり好感触だったと言っている。きっと得意分野なのだろう。
  16. で、VSCodeのターミナルでGeminiを起動して上記の文章を批判的に読んでもらった結果、訂正箇所はなかった。付け加えられたのは「コンテクストエンジニアリングは、静的なデータソースの設計だけでなく、AIが動的に情報を獲得・生成するためのツールチェーンを設計することも含みます。この両者をどう組み合わせるかが、より高度な課題となります。」
  17. とのことだ。もちろん承知している。だがMCPのノウハウがもう少しこなれてくることを期待する。技術はある程度こなれてくるまで下手に動かない方がいい場合もある。
  19. 先月から自転車の練習を再開した。身体を動かす趣味は、やはり生活に組み込んだ方がいい。たとえ今それどころじゃないくらいに打ち込んでいるものがあったとしてもだ。色々な面で好影響がある。結局はパフォーマンスが向上する。
  20. 先月は急いでベースを作った。急いでベースを作るには閾値下と呼ばれる領域に集中的に刺激を与えるに限る。1か月で9割戻った。
  21. ところが残りの1割はそうはいかない。これは一般にLSDと呼ばれる領域に地道に刺激を与えることで取り戻すことができる。
  22. ベースが仕上がったら、それを土台にしてVO2maxと呼ばれる領域に刺激を加える予定だ。これで競技能力を獲得できる。心臓発作が出なければアマチュアレースで勝敗を競えるくらいには戻す自信がある。
  23. 去年は心臓発作が出てメインレースで勝負できなかった。結果は2位だが3分差なので全く競えていない。ショックで全く練習する気力が失われてしまっていたが、なぜまた自転車競技をやろうと思ったかというと、余りにも体調が悪いからだ。余りにも。
  24. 練習を再開したことで、みるみる体調が回復した。本当に謎なのは、2月くらいから徐々に悪化していた股関節痛が軽減始めていること。逆に悪化しそうな気がするのだが……。一次胡坐をかけなくなるまで悪化していたが、今はクッションを使えば可能になっている。自転車の乗り降りですら痛かったが、今はほとんど大丈夫になった。

10 July 2025

  1. Gemini CLIは「プロジェクト」を完成させるアシスタントとして設計されている。
  2. ではその「プロジェクト」とは何か、だ。
  3. 完成させる工程にやや複雑さを要する何か。みたいなことしか言えなそう。別にアプリケーションやサービスではなくてもいいのだ。つまり、プログラマ御用達というわけじゃあない。
  4. 何をもって「複雑」だと考えるかは人による。だが、ある程度以上の絶対的な複雑さがない場合、Gemini CLIのようなエージェントに頼る意味はなさげ。
  5. たとえば、ちょっとした分からないことを調べたいけど調べ方が分からない、みたいなケース。これはコンソール上の文字列生成で解決できるので、ウェブアプリケーション系のChatGPTとかで事足りるだろう。
  6. では絶対的な複雑さとは何か。コンテクストの種別がそれを決定するかもしれない。
  7. ローカルなコンテクストはまさに該当する。だがそれだけでは足りない。そのコンテクストが十分な量と複雑さを伴った時、Gemini CLIは活きてくる。
  8. ほかのエージェントと比較するなら、さらに加えて必要なコンテクストにウェブ検索が加わったとき、実質的に（というか個人的に）唯一の選択肢になる。とはいえ、ウェブ検索のタスクは不確実性が高いので、かなり限られたシチュエーションに絞られるだろう。
  10. タスクマネジメントのカスタムGemのプロンプトを英語で打ち始めて1週間。
  11. とりあえず急ぎの時とかアイデアを記述したいときは日本語で書くんだけど、余裕があるときは英作文してMS Copilotに添削してもらっている。
  12. このマイクロWeb日記は思考過程なので書きなぐりながら考えることが重要であり、ネイティブ言語を使うしかない。
  14. 単独のGEMINI.mdに長文をだらだら書いて具体的な指示の洪水にしてはいけない。「コンテクストエンジニアリング」を馬鹿にしている人たちには分からんだろう。ざまあみやがれ。
  15. Geminiに権限を許すルートディレクトリに置くGEMINI.mdには、抽象度の最も高い指示だけを書いておくんだよ。
  16. Geminiに使用を許すPythonスクリプトファイルは決まったディレクトリに配置して、それを使えることだけを上記mdファイルに記述する。スクリプトの説明はJSONにしてそのディレクトリにおいておけばいいんだ。もちろんそれがスクリプト群の説明であることはGEMINI.mdに書いておく。
  17. コンテクストウィンドウの概念が分かっていればこういう配置になる。用途が増えてきたらそれに応じて構造化を加えてもいい。
  18. JSONやmdは当然Geminiに書いてもらう。ユーザーは事前に内容を確認して許可を与えればいい。修正するときは一応赤と緑に色分けされたdiffを明示してくれるのでやり易い。
  19. 水を得た魚の気分。
  20. あーこれもう完全に課金OKだな。月額50ドルくらいなら全然払っていいわ。でも無料で使えているうちは使わせてもらおう。

11 July 2025

  1. gemini-cli/docs/cli/configuration.md at main · google-gemini/gemini-cli · GitHub
  2. 昨日のアイデア、ネイティブにもっと賢く実装されてたわ。
  3. settings.jsonにて toolDiscoveryCommnadに、Gemini CLIがツールを発見する方法を出力するコマンドを定義する。使えるツール群を定義したJSONをstdoutに出力すればOK。自然言語でGEMINI.mdに定義するよりはずっと決定的。 python bin/get_tool.py。
  4. toolCallCommandに、ツール群の名前をマッピングしてコールするスクリプトを呼び出すコマンドを定義する。 python tools/call_tool.py
  5. Gemini CLIはMS Officeファイルを扱えないので、昨日extract_office_file.pyを書いた。こいつをツールとして使ってもらうことで、間接的にGemini CLIがWordやExcelの中身を読めるようになる。あとゼロパディングのリネームをしたかったので、sequential_renamer.pyとか。汎用性なんて考えなくていいので、どんどん追加していけばどんどん便利になる。
  6. Wordだってmdに変換してしまうよりXMLのまま読ませた方がきっといい感じに読めるはず。ものにも依るけどね。
  7. ツールからの出力を受け取ることができるからパイプをつないでツール同士を連携させることも可能だろう。
  8. そうやって、AIにはAIにしかできないことに集中してもらう。これで出力精度が上がることを大いに期待できる。
  9. Gemini CLIを推すのにsettings.jsonの説明がないのは片手落ちどころではないだろう。いまどきドキュメントなんてCopilotサイドバーを開いて知りたいところだけかいつまんで説明してもらえるんだから、楽なもんだよ。昔はXMLのスキーマ読むのも一苦労だったからな。
  10. Pathを通してあるような実行ファイル群も、Pythonスクリプトでラッパーかませばtoolに追加できる。なんかしらんけどyoutube_transcript_apiなるツールがあったので、ラッパー書いて試しに追加してみた。これでYoutubeのURLをプロンプトに投げて、字幕を受け取れるというわけだ。mdに変換とかはGeminiの仕事でいいかな。
  11. yomitokuはファイル出力がメイン処理なので思ったより恩恵はなさそうだけど、まあ楽っちゃ楽だろうね。descriptionの書き方が重要になってくるよたぶん。それによっては上手にオプションを選択してくれることを期待できる。例えば複数ページに分かれたPDFなら単一のファイルとして出力してもらうためのcombineオプションを自動でつけてくれるとかね。なによりそういった、ツール固有のオプションなんていちいち覚えていられないから毎回helpで確認してたわけで、それを省略できるのは認知負荷が低くてよろしい。自分でコマンド打つよりは絶対に楽になる。あらゆるツールに言えそうだ。
  12. ツールの汎用性をいちいち考えなければ、それ自体をGemini CLIにどんどん書いてもらうことができる。ここがミソだよなあ。書いてもらったら、get_tool.pyも更新してもらう。このタスクをGEMINI.mdに定義しておけば、Gemini CLIは自分で作ったツールを勝手に自分で使い始めることができるという寸法だ。
  13. なんか自己進化していくみたいな凄みがあってちょっとした恐怖を覚えるけど、冷静に考えてみればまだまだその域ではないや。
  14. Tampermonkeyスクリプトの開発なんかも相当楽になる。Typescript使ってOOPで設計しっかりやって、都度Gemini CLIに単一のJavascriptにしてもらえばいい。そのためのツールを定義しておきさえすれば決定的な出力が得られる。Tampermonkeyスクリプト化してくれ、って自然言語で頼むだけ。
  15. テストも楽になりそう。

13 July 2025

  1. toolDiscoveryCommandは機能するのにtoolCallCommandに不具合があるようで、なかなかうまくいかない部分がある。
  2. これが安定するまでは、自作のjsonカタログ方式で行くことにした。shellもセッションによって動いたり動かなかったりする。
  3. discovery.jsonを置いておく。ツールやドキュメントの発見に使うためのカタログとなる。このjsonのスキーマも定義した。
  4. jintrick.net/stream/2025/0713/document-discovery-schema.json
  5. tool-discovery-schema.jsonを書いてもらおうかというところで、Gemini CLIのquotaとやらを使い切ってしまった。

14 July 2025

  1. Amazon Musicを退会するので今のうちに楽曲に出会っておきたい。Bass Jazzで検索してプレイリストを漁ると捗る。

15 July 2025

  1. Gemini CLIの調教は続く。
  2. Pythonスクリプトを自律的に選択して使ってもらうことに成功。最低でも成否の情報をGeminiが受け取れるので、コマンドツール等々も含めてPythonスクリプトのラッパーを使う方針で行く。
  3. toolDiscoveryCommandの方は問題ない。問題はtoolCallCommandで、多分だけどバグがあり引数の扱いが間違っているのではないかと思う。pythonにcall_tool.pyを渡すコマンドを登録すると、失敗する。
  4. 仕方ないからバッチでラッパーを書いたんだが、こちらはNode.jsのセキュリティパッチ上、*.cmdと*.batの利用に制限がかかってエラー。Gemini CLIにGoogleSearchを使ってもらったところ、Node.jsの18.x以下、もしくは20.10.0ならそのパッチが適用されていないとのことなので、暫定的にダウングレードした。残念ながらnvmを入れてなかったので、これはインストーラーのリンクを教えてもらって自分で実行せざるを得なかった。
  5. 考えてみればバッチをバイナリにしてしまえばよかった。
  6. ここで思い出したが、toolCallCommandにはもう一つバグがあって、内部的にPath区切り子が何かに化けるみたい。ドキュメントの例（bin/call_tool）のようには記述できないので、Gemini CLIの実行ルートに置くか、ホームディレクトリ直下に置くか（~/）の2択だ。この辺も環境依存なのかな。
  7. 今回ばかりはWindowsやめたくなったけど、職場でも応用を効かせたいしSteamやら各種エミュレーターやらが動く環境じゃないと家族にも迷惑がかかるので無理。
  8. ともあれ、スクリプトを自律的に扱わせる構成は、個人利用であればMCPサーバーより断然手軽だ。ツールをPythonで書いて、それをGemini CLIに読んでもらって、その説明と使い方をget_tool.py内のPythonオブジェクトに記述してもらえばいいんだから。
  9. そしてそのツールだって、基本的なものであればテストコードを含めて全部Gemini CLIに書いてもらうことができる。
  10. 実際、「私はOffice系のファイルを扱えません」と言われたので、じゃあ解答して中身のXMLを読めば？ といってそのためのスクリプトを書かせて説明をアップデートさせてツールに登録したので、「*.docxを読んで」と命じるだけで自律的に中身のXMLを読んでくれる。
  11. こんな感じで、何かやってもらいたいことに実行上の行き詰まりがあったら、その都度ツールを書いて登録作業をしてもらえばいいわけだ。
  12. この流れ自体が楽しくて仕方ない。Mozjpegの高い圧縮率はいいんだけど、結局面倒くさいからウェブサービスを使ったりしていた。これだってPythonラッパーを書いてもらって登録してもらえば、一連の面倒くさい作業を自律的にやってくれるはずだ。ffmpegの使いこなしも極めて楽になる未来が見える。
  13. 業務への応用も恐ろしく捗るだろう。
  14. Gemini CLIに関するドキュメントは、すべて.gemini/docs/*.mdにしてあって、discovery.jsonにそのリストと説明を書いてある。Gemini CLIがそれを読んで必要時に自律的に探してくれるよう、GEMINI.mdに定義した。本来であれば、このドキュメントを参照してPythonスクリプトの登録を自律的にやってもらいんだが、先述したように若干複雑なことになってしまっているので、成功するか不安が残る。特にモデルが2.5-Flashになってしまうととたんに思考が粗雑になるので多分無理だろう。
  16. Flashが鬱陶しすぎるのでGoogle AI Proに課金した。1か月無料だけど。
  17. Gemini CLIにもしっかり影響してる。混雑時にFlashに落とされる頻度も少ないんじゃないだろうか。今のところ一度もない。
  18. Google AI Studio / Vertex AI も悩んだけど、どちらも自分の用途にはマッチしない。前者は非力すぎて意味わからんし、後者はオーバースペック。トレーニングは魅力だけどコンテクストウィンドウの管理をしっかりやれば、それなりのRAGは構築できると踏んだ。だったら2.5 Proの利用枠を増やすだけにして様子見だ。あと2か月小遣いゼロの貧乏人なのでとにかくコスパが大事。

18 July 2025

  1. Gemini CLIとGoogle AI Proとの関係がよく分からなくなってきた。初日は使い放題だったProだが、このところはすぐにFlashに切り替わってしまう。
  2. とはいえWeb版のGeminiはProを使い放題なので非常にありがたく、これだけでもかなり満足度が高い。
  3. Geminiが苦手であろう最適化問題を、ortoolsというPythonライブラリで補ってやる計画を立てて、いまGemini 2.5 proと相談しながら計画を進めている。
  4. お互いに毎回「素晴らしい提案です」と言い合いながら進んでいくので、メンタルにもよい。
  5. Flashでも解決可能になるくらいコンテクストを管理してやるのが目標。Gemini CLIは自然言語を解釈してツールとの橋渡し役になってくれればそれでいい。手順などの細かな部分は、必要な時にmdファイルなどを読んでもらえればいい。そんな程度であれば、2.5 Proのような高度な思考は必要ないと踏んでいる。
  6. そもそも生成AIの「高度な思考」に頼るのは便利な分リスクが高い。非決定的で出力が安定しない。それよりも自然言語の解釈能力に全振りしてやるのが賢い使い方だと思う。
  7. Gemini CLI用カスタムツールを作成するためのGemsに、いくつかツールスクリプトを書いてもらったところ、そのうちの一つにカスタム命令違反があり、stdoutへの出力はJSONでなければならないのに、そのJSONを説明するコメント行を出力してしまっていた。当然Gemini CLIは、受け取るはずのJSONが不正だったのでツールの実行に失敗。Gemsが自分に与えられたカスタム指示をメタ認知しているのであれば、最後にカスタム指示の内容を確認してスクリプトをチェックすることも可能なのだが。
  8. とりあえずカスタム指示の改訂版を考案してもらって、md形式で出力させようとしたのだが、WebアプリなのでマークダウンはHTMLに成形して表示してしまうらし。Gemini自身によるとコードブロックとして出力すれば成形されないとのことだったが、アプリの挙動を制御することはできなそうだった。
  9. 色々な方法を試したが、結局のところPythonスクリプトの文字列として出力してもらうのが一番確実だった。ただし内容によっては途中で成形されてしまったりする。
  10. Gemini CLI用のカスタムスクリプトは、ライブラリの依存関係で止まってしまうということがない。きちんとしたエラーをstderrに吐いておけば、勝手にpip installしつつ実行を継続してくれる。もしほかのカスタムスクリプトと競合してしまっても、その都度環境を作り直す感じでいいのかもしれない。ツールごとに環境を分けるのが堅牢なのかもしれないし、あるいはライブラリを使わずにバイナリ化して使うようにした方がいいのかもしれない。
  11. まだまだ実験的に作っているツールが多いので、まずはスピード重視で行く。

19 July 2025

  1. GEMINI CLI用カスタムPythonスクリプトのサンプル
  2. カスタムスクリプトを書いてもらうためのGemのカスタム指示にこのサンプルスクリプト全文を書いてしまうのは悪手である。
  3. サンプルではなくまずは論理で簡潔に説明し、最終的な突合を行うときに参照してもらえばいい。だからカスタム指示にはこのURLだけを書いておく。この方針でやってみよう。Gemini CLIの方でチェックしてもらうのもいいんだけど、Web版だとProが使い放題なので。
  4. Gemini CLIの場合はカスタム指示をGEMINI.mdに書くことになる。@file構文というのがあるらしくカスタム指示を分割してインポート可能みたいだが、コンテクストウィンドウは一気に消費されるとのことので多分使わないだろう。URLで示した方がいい。
  5. テキストPDFを完全に読めるみたい。古いテレビがモードを自動で切り替えるのがウザいので操作説明書を読んだが検索キーワードが全然思いつかなかったのでGemini CLIに読ませて適当に聞いたら、的確に教えてくれた。
  6. 車の説明書なんかも、適当に分割して読ませて目次のmdを作ってもらえば、ディーラー顔負けのアシスタントになってもらえると思う。以前NotebokLMでやろうとしてがっかりしたけど、今度は大丈夫そうだ。
  7. いや違うな。分割して内容を読ませる過程でmd化してしまえばいい。PDFの読み込みはやはり時間がかかるから。
  8. 数百MBもあるような巨大なPDFの場合、まず分割処理が問題となりそう。カスタムスクリプト書いてもらうのもいいかもしれない。toolDiscoveryCommandに登録できるツールに上限はあるのだろうか。
  9. 極めて重要な局面でGemini CLIがFlashに切り替わってしまったら困るので、一応APIキーを取得しておいた。https://aistudio.google.com/apikey
  10. Google Cloudのプロジェクトに紐づけられるらしいが、Gemini CLIにWebsearchなどを使って調べてもらったところGoogle Cloudのサブスクリプションは必要なく、だれでも作成できるとのことだが、そうは思えなかった。まあどっちでもいいや。
  11. 「ではそのmdファイルを作成したいので、コードブロックとしてmdを出力してください。」と書いたら、今日はちゃんとコードとして出力できた。ムラがあるのでPythonとして出力させるのは次善策として覚えておこう。

24 July 2025

  1. 正論は正論であるがゆえに少しずつ浸透していく。
  2. でもどう転んでも人間の本性は糞ザル。
  3. ギャップがだんだん拡大していくんだな。
  4. 積もり積もって爆発する。
  5. でも、糞ザルだってことを公に認めたくはないから……
  6. 嘘や陰謀論にすがることになる。
  7. とまあ、大きな大きな視点で捉えると、昨今の情勢ってこんな感じで説明可能なんじゃないかと。
  9. Excel操作を生成AI(CLI)にやらせてみました。凄かったです。 - YouTube
  10. Claude Codeも欲しくなる。
  11. 一応俺もpandasとopenpyxlでアウトプットするツールコマンドは開発中だけど、これはリアルタイムにエクセルを操作してるじゃねえか。
  12. インパクト強い。PowerShellを使っているそうだけど、どういう仕組みなのかわからん。
  13. ので、Copilot Webに説明させてみた。実行後即座にExcelが変化しているように見えるが、実際にはスクリプトの出力をユーザーが手動で実行しているか、GUIからワンボタン実行できるようにしてると思われる。だってさ。
  14. そうは見えないなあ。Excel.ApplicationCOMオブジェクトを操作できるなら、PowershellスクリプトをCLI上で実行した瞬間に反映されるんじゃないのかねえ。
  15. ……て感じのツッコミを入れたら訂正してきた。
  16. Gemini 2.5 Proにも相談してみたら、特定のOSやアプリケーションに依存しないPythonライブラリ方式が、アーキテクチャとして圧倒的に優れています。だってさ。全然乗り気じゃねえ。
  17. なんかこいつ、思想に偏りがあるな。ネット上に出回っているコードや思想に染まるからしゃーないか。というか、カスタム指示の影響もあるねこれは。
  18. Gemini CLI用カスタムPowershellスクリプトっていうGemも作るしかないね。
  19. Powershellは可読性が悪いので特別事情がない限り採用しない方針だけど、やっぱりリアルタイムにExcelワークシートが更新されていく様を見せられるというのはユーザー体験が向上するし、インパクトも強いよな。これはもう完全に特別な事情と言える。
  21. 書き忘れていたが、先週末、Gemini CLIのtoolCallCommandの不具合にうまく対処することに成功した。
  22. まず何が不具合化というと、toolCallCommandに渡す引数にスペースやパス区切り子が含まれていると、どうやらGemini CLIはそれらをエスケープしてしまう。おそらくバックスラッシュでエスケープしているのだと思うが、詳細は分からない。ともかく違う文字に置き換えられてしまう。
  23. つまり、toolCallCommandに指定できるのは、Gemini CLIがインストールされているホームディレクトリ等のルートに置かれたバイナリ、あるいはPathの通っているディレクトリに置かれたバイナリということだ。
  24. そこでホームディレクトリに、ツールを実行するcall_tool.pyをラップしたバッチファイルcall_tool.batを置いてこれをtoolCallCommandとしてみたのだが、今度はNode.jsのセキュリティ対策に引っかかってしまい、Node.jsのバージョンを下げざるを得なくなった。
  25. しかしGemini CLIは徐々に要求するNode.jsのバージョンを上げてきており、現在は20.0.0以上を要求するようになってしまった。バッチファイルが使える20.x系はは20.10.0のみという状況。
  26. そこで、Pythonの標準パッケージング機能であるエントリポイントを使って、実行可能なcall_tool.exeを作成、Pathの通ったディレクトリに配置した。
  28. Gemini CLIにはrun_shell_commandという内部ツールがあるらしく、ツール名「Shell」でコールされるらしいのだが（本人談）、こいつにもtoolCallCommandと似たようなバグがある。ダブルクォーテーションをエスケープしてしまうのだ。つまりスペースを含むパスを渡すことができない。/aboutによるとバージョンは0.1.12だが、まだ解消されていない。報告はしておいた。
  29. delete, copy, move, renameあたりを担うPythonスクリプトをツールとして登録して一時しのぎをしているが、早いところ対応してもらいたい。toolDiscoveryCommandが余計に肥大してしまうのでコンテクストがもったいない。

25 July 2025

  1. Gemini 2.5 Flash + カスタムGemにやってもらっているタスク管理だけど、今日カスタム指示をバージョンアップした。
  2. Canvasに表としてタスクを書きだしてもらい、都度更新していってもらう。列名は、タスク名、開始時刻、終了時刻、タスク中の気づき。
  3. これでコンテクストウィンドウの消費が劇的に抑えられる。Flashでも簡単に答えられるような質問があったとき、流れを止めるのが嫌だったのでCopilotを起動していたりしたのだが、これも必要なくなる。なんたってFlashはタスク管理に関する情報を、いつでもCanvasから取得できるんだから。
  4. 自分としても、今これをやっているんだというのが分かりやすくなった。
  6. おいおいおいおいおいおい、MicrosoftのCopilot Web、もしかしてGit HubのMCPサーバーを内部で実装してるんじゃないか？いやそれはないとしても、少なくともGitHubの内容をトレーニングして随時アップデートしてるじゃないか？ ってくらいに精度の高い回答を返してくるんだが！！？
  7. Gemini CLIのdocs/を抽出してRAGっぽいものを組んだんだけど、この調子で精度を上げていったらRAGの構築が不要になるかもしれない。Gitにアップロードしてしまえばデプロイ完了の簡易RAGが出来上がる。Notebook LMはFlash使ってるから論外だけど、Copilotある程度信頼できる。
  8. でも精度が上がったとはいえ完全じゃない。7～8割って感じだ。リポジトリにも拠るだろうしリファレンスとして使うのはアホだな。
  9. やっぱり、現在開いているドキュメントを解説させるのにとどめておいた方がいいかもしれない。
  10. バージョンアップのRelease Noteを読ませるのは最高なので、神アプリであることに疑いはない。

26 July 2025

  1. チャット履歴は自動で残らない。settings.jsonに履歴に残す設定をしたつもりだったけど、思い違いだったみたいで、/chat listしても空っぽだった。/chat save <tag>しないとだめだった。これでチェックポイントとして保存され、/chat resume <tag>で再開できる。
  3. AI Context Window Optimization Strategies | Claude
  4. まいったなあ。Gemini 2.5 proとコントになっちゃった。今日のGemini君はとっても変だった。Claude Code使いがうらやましくなってくる。

29 July 2025

  1. つまらないことだけど、あまりに衝撃的だったので記録しとく。
  2. 人から預かったPanasonicのLet’s Note CF-SVを触って、めちゃくちゃ驚いた。
  3. この機種、ホームポジションの突起がない！
  4. どんなチープなおもちゃみたいなキーボードでも、いままでこの突起のないツルツルなFキーとJキーに出会ったことはなかった。
  5. これがないと、どこ触るにしても絶対に視線をキーボードに戻さないといけなくなるんだが？？
  6. 本気で意味が分からん。大丈夫かPanasonic。
  7. 滅多なことでは使わないであろう光学ドライブが付いているおかげでちょっと分厚いものの、その他の使い勝手は悪くない。いやむしろ良いんだよなあ。ホームポジションの突起さえあれば。
  8. 理由は何だろ。気になって仕方がないんだが、軽く調べてもこれを問題にしているページがヒットしないんだよな。

31 July 2025

  1. AIエージェント時代のプログラミング。
  2. っていうのがちょっとだけ見えた。
  3. 特に重要なのは、エラーの書き方。
  4. 依存ライブラリがある場合は、インストールコマンドをエラーメッセージに含めてやると、AIが自律的にインストールしてくれる。してくれないこともあるのでそこはエラーメッセージの書き方やAIへの事前命令次第。
  5. 何か重大なエラーがあった場合、AIがそれを自律的に修正できる可能性を常に考慮して、その修正に資する情報をエラーとして投げてやる。例えばあるテーブルを参照しようとした。table1という名前で。ところがそのテーブルは見つからなかった。これまでは「table1は見つかりませんでした」で終わりだ。だがこれからの時代は「table1という名前のテーブルは見つかりませんでしたが、次のような名前のテーブルがあります["テーブル1", "テーブル2"]」というエラーメッセージを投げるといい。するとAIエージェントはユーザーにこう聞いてくれる。「table1は見つかりませんでしたが、テーブル1という名前のテーブルならあります。これでツールを再実行しますか？」
  6. またこれはあくまでデバッグ中の話だが、デバッグコードが吐いたログの内容をみて、出力結果の文字化けを補ってくれたこともある。補ってくれていたことを教えてくれなかったためデバッグが非常に長引いてしまったが、何度か実行したのち、ついに「補いました」と白状してくれて気づいた。本来余計なことをされて時間を浪費したので怒りが湧いてくるところだが、あまりに驚いしまってそれどころではなかった。
  7. 次に重要なのは、コード内のドキュメント。カスタムツールとして登録する作業はAIエージェントにやらせているのだが、当然この時はコード内のドキュメントを参照してツール自体の説明を生成する。しかし何らかのエッジケースでツールが停止してしまった時にも、このドキュメントが大いに頼りとなってAIエージェントの次の一手を支援してくれることになる。そのつもりで書くのだ。
  8. 滅多にないことではあるが、AIエージェントが提案したコードの修正内容を認可するだけでエッジケースの対応が完了、なんてこともあり得る。実際には問題点の把握に大いに役立つくらいで、コードの修正を完全に任せるまではいかない。
  9. デバッグはとても下手糞なのだ。
  10. だがそこを補ってやるのが人間の仕事。まずはデバッグ計画を立てさせることから始める。大抵筋の悪い計画を立ててくるので、それを修正してやるというわけだ。
  11. よく世間で言われている「たまに指示出ししてほったらかし」、なんていう方針は、悪夢のような糞コードしか産まないと思う。勝手にデバッグさせると全く関係のない要因をでっちあげてそれに対応して、を繰り返して無意味なコードが大量に生成されることになる。何か行き詰まりを見せたら、必ずデバッグ計画を一緒に練ってやらなければならない。今のところマス。。
  12. デバッグに関するトレーニングを積んだモデルが今後登場してくれることに期待する。
  13. あと、ちょっと見えてきてるのがソフトウェアの将来。
  14. 機能をガシガシ詰め込んだボタンだらけのアプリケーションなんてのはすでに陳腐化しているが、それ以前に、そもそもGUIアプリケーションというものが廃れるかもしれない。ビジネスモデルに接続するためのGUI部品というのは、確かにこれまでは役に立つ代物だったろう。しかしこれからはAIエージェントに頼めばいい。つまり専用ソフトウェアの使い方を覚える必要がなくなる。ボタンなんて必要ない。
  15. これまでCUIを通じて様々なツールを使いこなしていた人たちというのはいる。AIエージェントを通じてこれが誰にでもできるようになるイメージだ。

03 August 2025

  1. 生成AIにプロジェクト全体の設計を丸投げするのは、まだまだ早い。
  2. 世間に転がっている「良い」とされるデザインパターンが使えるということになると、まったく考えもなく実装に走ってしまう。次々に無意味なデザインパターンが実装されてき、気づいてみたら拡張性が悪く、デバッグ難易度が高く、モジュールが相互に依存した目茶苦茶なパッケージが出来上がっていた。
  3. 要件定義は十分伝えてあるというか、要件定義を一緒に考えたりもしたんだけど、だめ。コンテクストが足りないのだろうか。
  4. 時折Claude4に評価させたりしたけど、毎回A+判定をしてきた。
  5. 具体的な問題点をいくつか指摘すると、ようやく判定を覆し始める始末。
  6. 要件定義の後に設計をひたすら煮詰めないだめだ。
  7. あと無料枠などを有効に使っている関係上、コンテクストを節約するためにファイルはできる限り少ない方がいい。クラスの役割が完全に確定するまでは、別ファイルにしない方がいい。別ファイルにしてしまうとコーディングの精度も落ちる気がする。
  9. SSDを買った。USB接続するためのケースも買った（Orico製）。接続した。認識されない。
  10. 返品しようと思ってamazonの注文履歴から返品をクリックしたら、返品手続きがとても簡単になっていて驚いた。
  11. 数クリックでウェブ上の返品手続きを完了すると、QRコードがメールで送られてくる。これをローソンの「スマリボックス」とやらにかざして商品を投入するだけで返品が完了するらしい。
  12. ここまで簡単に返品できるとなると、数％、数百円の価格差ならamazonを選択したくなるね。
  14. このところGemini 2.5 proを過剰に使うためか枠を使い切ってしまうことが日常となってきていて、そういうときはWeb版チャットアプリのClaude4に頼ることも多い。
  15. ところがこのClaude4、突然文字数制限でチャットセッションを閉じるのが厄介で、引継ぎ用のmdを生成させるタイミングを失ってしまう。
  16. そこで思い出したのが、Copilot Web。PWAとして表示するのをやめると、右上に頼れるアイコンが現れる。
  17. あとは、このチャットセッションを引き継ぐためのmdを生成してくれと依頼するだけだ。

04 August 2025

  1. 久々ChatGPTと会話してたら自分で思いついてしまったんだけど（相変わらずChatGPTは何の変哲もないコピペみたいな回答しかしないが）、プロンプトに感情を混ぜると余計なお互いに余計なトークンが発生してしまってよくない。コンテクストも汚染することになる。そこで、ともかく自分が楽に打てるプロンプトを打って、それをエージェントに適切なプロンプトに変換してもらいつつ、クリップボードに格納してもらうというのはどうか。……と思ってクリップボードにコピーするツールをサクッと書いてもらったんだけど、Gemini CLIはShell関連のバグが修正されたため、普通に頼めば普通にコピーしてくれた。ツールの意味はなかった。
  2. 何でこんなことを考えたかというと、有料モデルを使うときはなるべくトークン数を抑えたいと思ったからだ。また、意図せぬ感情表現が紛れ込むことで、貴重なコンテクストが汚染されるのも避けたい。
  3. 実際にどういった方法があるか考えてみたが、ここはカスタムコマンドが最も適していると思える。/prompt "推敲してもらいたいプロンプト"と打つことで、あらかじめ登録しておいた指示を呼び出すことができる。指示の中に {{arg}} と書いておけば引数として扱ってくれるらしい。

05 August 2025

  1. 無料枠で何とかやっていく工夫を考えた。Deepseekがこのところコーディングに関して実力を伸ばしているっぽいけど、それに頼り切らない感じで行く。
  2. 基本はちょっとだけ課金していて枠がたくさんあるGemini 2.5 proとプロジェクトを進めていくわけだが、枠を使い切ってしまいそうなら引継ぎ文書を出力してもらって、Claudeに実装計画を立ててもらう。その計画をDeepseekに読ませてコードの生成はDeepseekにやってもらう。これでトークン節約。
  3. 現時点で最も頼りになるClaude 4 Sonnetのトークンは極めて貴重なので、ごく短いサンプル以外の具体的なコードを吐かせてはいけない。
  4. Gemini 2.5 pro利用中であっても、実装計画はClaudeに頼みたいくらいだが、いざというときに使えないと困るので使いどころは厳選したい。
  5. Gemini 2.5 proがいつ枠を使い切るかがよく分からんので、引継ぎ文書は常にCanvasで最新の状態に保ってもらうのがいいだろう。
  6. さらに、入力トークンを節約させるため、Grokを活用する。こいつはかなりアホになってしまったのでほぼ使いどころがないのだが、唯一WorkspaceというカスタムGemみたいなのを使えるのが強み。カスタムGemでもいいのだが、2.5 Flashよりはマシのような気がしている。入力トークンを節約させるプロンプト圧縮という名前のWorkspaceに、最新の状態に保ってもらっていた引継ぎ文書を投げて、入力トークンを節約させつつ、出力効率を上げてもらえそうな形に直してもらう。中身を一応確認して、Claudeに投げ、実装計画を立ててもらって、Deepseekへ、という流れだ。
  7. これで、1日中狂ったようにプログラミングができるというわけだ。
  8. さて、そろそろClaudeの枠が復活したので、また狂ったようにプログラミングを行うこととしよう……。

06 August 2025

  1. いまだにプロンプト・エンジニアリングがどうこう言っている驚き屋の記事では、ペルソナの設定には大抵「あなたは○○のスペシャリストです」という文句が出てくる。
  2. でも俺、気づいちゃった。「あなたは～の新人アーキテクトです」って書いたほうがよっぽどうまく行くことにw 少なくともソフトウェアの設計に関してはね。
  3. エキスパート・アーキテクトを自認させると、自信たっぷりにすべてを推測してくれる。推測が正しいか間違ってるかの判断をこちらに仰ぐ前にコードを書き始める。
  4. 新人アーキテクトの自覚を持ってもらうと、何かにつけてシニア・アーキテクト（ユーザー）に意見を求めるようなペルソナになる。
  5. たまに「よくやった新人」と伝えてやることで、新人であることを思い出させることが、自然とできる。
  6. これは感覚的なものだが、何かの折に自発的にコードの間違いに気づいて修正してくれたりしたこともある。「自分は何か失敗しているかもしれない」という前提でコードを見直しているのかもしれない。
  7. そもそもただの推測屋にエキスパート・アーキテクトなんて務まるわけねえだろ、と。そんな背伸びさせて、いったい誰の得になるの？？
  8. エキスパート・アーキテクトを自認させたときの弊害は他にも色々あると思うぞ。具体的に色々思い出せる。
  9. 例えば何か失敗したときに、説明責任を果たそうとして謝罪の言葉や言い訳を考えたりしてくる。新人なら失敗して当然なので、謝罪は通り一遍で済みコンテクストの節約になる。
  10. とかね。

08 August 2025

  1. このところGrokがまた良くなってきている。いっとき本当にどうしようもないアホだったんだが、現時点で少なくともGemini 2.5 Flashより賢いことは間違いない。内部モデルがどうなってるのかブラックボックスなので、おま環の可能性も捨てきれないけどね。
  2. というわけでタスクマネージャーと名付けたGemを使うのをやめ、同名のWorkspaceを使うことにした。
  3. Workspaceという名称は変更されているみたいだな。Projectsになってた。
  4. MSのCopilotがGPT-5を使うモードを搭載したようだ。多分制限かかるだろうけど、有効に使わせてもらおう。Gemini 2.5 Proをメインとして、Claude4, Chat-GPT、でこのCopilot GPT-5も選択肢になる。サブにDeepseek、Qwen、そしてGrokも加わった（復帰）。これならまあ1日中使っても大丈夫だろう。FelowやPerplexityとかの検索特化型はコーディングの補助として使ったことがないけど、どうなんだろうね。なんか試す機会がないくらい恵まれてしまっている。
  5. 最近自分で編み出したトークン節約術がある。たとえばARPBC（Always Report Plan Before Code）。コードを書き始める前に計画を提示しろ、という命令だが、いわゆるシステムプロンプト的なところにこの略語に関する詳細な説明を書いておいて、思い出して欲しいときはこの略語をプロンプトの最後に入れたり、場合によっては毎回復唱させたりする。
  6. でも節約術で一番功を奏しているのは、やっぱり設計計画書、リファクター計画書だね。大事なのでメモっておこう。
  7. アプリケーションが大きくなってくると、コードの生成が大量になってきてしまうので、優れたLLMには計画だけ立ててもらってマークダウンを生成してもらい、実際にコードを生成するのはアホの子Gemini 2.5 Flashにやってもらう。Gemini CLI上で。
  8. アホの子Gemini 2.5 Flashはただの実行部隊。思考させずに施行させる。
  9. これがいま一番ケチな生成AI活用術だ。
  10. 優れたLLMの筆頭はClaude4だと思うが、抽象度が上がってきた時点で正直もうどんぐりの背比べでしかない。さっきだって、最適化問題を解くための各戦略クラスを抽象化して、APIを提供するサービスレイヤーとして機能するモデルクラスの存在も全部伝えたのにもかかわらず、パフォーマンス改善案を書かせたら戦略クラスの内部コードを書き換えてきやがった。世の中そういう糞コードであふれかえっているという事実の裏返しであると思うと戦慄を覚えるわけだが、抽象度について軽く説教すると「あなたが100％正しいです」だのなんだのとすぐに理解してくれることはしてくれる。そんな感じだ。

10 August 2025

  1. MS IMEがあまりにもアホすぎていい加減嫌になってしまったので、Google日本語入力の利用を再開してみることにした。なぜ利用をやめていたのかは思い出せない。
  2. 無変換キーでIMEオフ、変換キーでIMEオンにできると、IMEの切り替え忘れが減らせる。この設定が異常に分かりづらい。
  3. プロパティ > 一般タブ > キーの選択 で 「MS IME」 になっていることを確認後、「編集」
  4. キーで並べ替えて、Henkan担っている項目すべてをIME有効に変え、Muhenkanになっている項目をすべてIME無効に変える。
  5. 「OK」でキーの選択が「カスタム」になっていれば成功。
  6. 何が難しいかって、自前で新しくキーを登録しようとすると、変換キーがキーバインドとして認識されなくて詰む。コンテクストメニューも出せないし、詰む。だから既存のルールを上書きするしかないんだな。

11 August 2025

  1. 限界やで。AIエージェントに完全にコーダーになってもらうというのも、もう限界。
  2. 細かいところまで見てくれないというかなんというか。ある規模を超えてくると、自分が理解していない設計のリファクタリングが、どうにもならなくなってくる。
  3. まず計画を立てさせて、それに目を通しながらやってはいたけど、それでは限界がくる。特にOOPだと、一通りの抽象レイヤーと抽象APIを理解しておかないと、計画に漏れがあるかどうかがわからない。一見、良さそうに見えるんだけど、穴が空いてた！みたいなことが頻発する。その場のテストでは露見しなくても、後で顕在化してきたりする。怖いのがそういう負債がたまりきったときで、適切なデバッグを指示することが困難になる。多分こいつ間違えてるなーくらいはわかるけど、どうすればいいのかは俺にもわからん、みたいになる。そうなるとプロジェクトを大幅に後退させざるを得ない。
  4. お気楽バイブコーディングなんてまだまだ夢の領域って感じ。
  6. Chat-GPTがモデルを新しくしたらしく（GPT-5）性能を試してみたいのだが、渡せるファイルの制限が厳しすぎてどうにもならん。エージェントを介してモデルを選択できるならいいんだけど、Gemini CLIだと今後も難しいのかな。

14 August 2025

  1. やべえ。今日のGemini 2.5 Proが馬鹿すぎて怖え。
  2. バグ修正計画書を作らせた。せっせと抽象メソッドとAPIを定義してたので、当然そいつを使った実装になると思ってエージェントに実装させたら、あれ？PylintでImportErrorだって？？何を新しくImportしようとしてんねん。API使う側のクラスやぞ？？
  3. よく見ると、API側に閉じ込めてあるはずの具体的なCP-SATのクラスを、インポートしようとしてる……。せっかく戦略クラスをソルバー独立にしてるのに、「How」を書いちゃってる！！
  4. コードを見てみると、なんだこれーーー。せっかくの抽象メソッドもAPIも、なんの意味もない実装になってるじゃん。こええよこいつ。お前自分で書いたんだろうがそのメソッド！！馬鹿すぎる。いやもう馬鹿とかいうレベルじゃねえだろ。まじで怖いんですけど……。
  5. だって、じゃあなんのためにせっせと抽象クラスとファクトリークラス、APIクラスを書き換えたのよ？？？その労力は一体何だったの？？？
  6. 馬鹿とかじゃねえよこれ。分裂症じゃん……((((；ﾟДﾟ))))
  7. コンテクストウィンドウの配分がまずかったんだろうなあ。ortools.sat.python.cp_model.mdってのを作って前提知識として与えていたのが裏目に出たのだろうか……。
  8. いやなのは、AIエージェント側にもちゃんとアーキテクチャを理解してもらうべくマークダウンでコンテクストを消費させてるのに、なんの気付きもなく実装して、ImportErrorがでてもなんの気付きもなく対処療法に走ろうとしてたこと。まあこっちはLLMのモデルがアホの子なのでしかたない面はあるんだが……。
  9. 前提知識として知っておいてね、的な感じでドカンとでかいコンテクストを消費させるのは、やめよう。分裂症患者を作るだけで逆効果だ。
  10. 会話を長ーく続けていると、たまに分裂症になる。あれと一緒だろう。
  11. LLMのコンテクストは、メモリみたいな概念とはちょっと違うと思う。もっとこちらが学ばないだめな領域だね。GPT-5にチュートリアルしてもらうか。
  12. ……
  13. なんか内容が薄っぺらくてだめだわ。知ってることしか得られない。
  15. pylintをエージェントに自律的に使わせると、お馬鹿なモデルを使っていても、ちょっとだけバイブコーディングしてる気分になれる。
  16. pylintは単一のファイルじゃなくて、プロジェクト全体にかけることもできるのか。
  17. これすごくいいね。Gemini 2.5 flashでもなんとか中品質のコードを生成できるようになった、かもしれない。
  18. 構文エラーとかPEP違反とか以上の、プロジェクトにまたがるような結構突っ込んだ指摘をしてくれる。
  19. おかげで、俺帰れねえよ家に。終わらないんだもん
  20. lint -> 修正 -> lint -> 修正の無限ループ
  21. いやだなあ。もうほったらかして帰っちゃおうかなｗ
  22. どんなリスクあるんだこれ。
  23. 万が一本当に無限ループみたいなことになっていたら、明日はもうQuota使い切ってGemini CLIを使えなくなってる。
  24. リファクタリング作業自体は終わってるので、一旦強制停止するかな。

15 August 2025

  1. 記念すべき初めてのカスタムスラッシュコマンドはこれ！
  2. description = "Gemini CLI用カスタムスクリプトを登録します。引数はファイル名だけでOK。"

prompt = """
./gemini/tools/GEMINI.md をよく読み、
カスタムツール（{{arg}}）の登録を行え。

このスクリプトのディレクトリは、./gemini/tools/ である。
"""
  3. コマンド名は regiscriptにしたので、 ./gemini/commands/regiscript.tomlとして保存。
  4. ここには具体的な指示なんて書かない。登録方法が微妙に変わったときとかに、一々 commands/regiscript.tomlを書き換えたりしない。カスタムツールを登録しろっていうことをただ抽象的に書いておくべき。具体的な内容は全てマークダウンファイルとして適切な場所に保存する。適切な場所というのは関連性の極めて高いディレクトリのルートだな。
  5. /regiscript なんちゃら.py でこのプロンプトをいつでも呼び出すことができるというわけだ。具体的な指示内容もマークダウンファイルにしておけば後方参照が「決定的に」行えるという寸法。
  6. これでコンテクストウィンドウを小さくできる。Gemini.mdに書いてたんだけど、ずっといい。
  7. で、さっきGemini CLI用カスタムスクリプトGemに、git_version.pyっていうツールを作ってもらったので、さっそくカスタムスラッシュコマンドで登録させてみたい。このツールは、「プロジェクトをv0.4.1にバージョンアップして」みたいに頼むだけで、バージョン管理に関するごにょごにょした操作をうまいことやってくれるというものだ。
  8. こういう、ツールを使わせるだけの簡単な作業はFlashで十分。
  9. gemini -m "gemini-2.5-flash"
  10. /regiscript git_version.py
  11. Flashでやったら、API　Errorが出てしまった。内容はブラックボックス。Proで再起動したらうまく行った。完璧に機能してる。いやー素晴らしい。
  12. toolDiscoveryCommandに登録されているスクリプトの更新を承認した瞬間、Quotaを使い切ってしまった。
  13. 「登録はうまく行ったかな？確認して。あと、git_version.pyの検証もやって」

17 August 2025

  1. 個人開発のプロジェクトでもGitとGit Hubを活用したいけど、冗長で面倒なだけだった。
  2. でもGemini CLIによしなにお願いすれば、全部任せられる。最初git用のツールをPythonで書いて使ってもらっていたんだけど、そんなもん必要ないほどしっかりgitコマンドを使いこなしてくれるので不要だった。ほんと助かるこれ。

18 August 2025

  1. Gemini CLIのカスタムツールに validate_pycodeというのを追加した。今のところpylintを使うためのツールだけど、最初に呼び出す際に引数なしで使おうとする。なぜかということを問い詰めたところ、FunctionDeclarationに当該引数が指定されていなかったとの返答だった。
  2. 更に問い詰めると、default_api.validate_pycode()の関数シグネチャに、引数が一切明示されていなかったため、引数が不要だと認識した、とのこと。
  3. というわけで、今後はできる限り カスタムツールの引数はオプションにせず、required: []にリストアップすることにする。やむを得ずオプションにする際は、必ずdescriptionに使い方を載せよう。それでも使ってくれるかどうかはわからないけど。

19 August 2025

  1. Gemini CLIはプロジェクトルートで実行することにした。
  2. カスタムツールを使いたいときはまた別のディレクトリで起動すればいい。それよりもgitやらpylintやらをツールを介さずそのまま使える方が 圧倒的に楽だった。pylint除外オプションの指定があるので、ツールのほうが良さそうだけど、ツールの定義は何かと面倒くさいので、カスタムスラッシュコマンドに仕込んでおいてもいいと思う。tomlファイルを .gemini/commands/に置くだけだ。
  3. 本当なら、VSCodeでIDE統合したほうがいいに決まっているんだけど、モニタ環境が悪いので並行閲覧が厳しくなる。こういうときにウルトラワイドなんだよな。
  4. 「コミット、プッシュしといて」
  5. こんな感じでOK。しかもステージされるべきファイルの警告までしてくれる（してくれないときもある）

20 August 2025

  1. ついに・・・ついにプロトタイプが完成した！
  2. Gemini CLIをオーケストレーターとし、CP-SATというソルバーを使ってシフト表を作成する対話型アプリケーション。
  3. 戦略クラスを追加することで、制約条件を拡張可能。もう、どんな複雑な制約条件が絡もうと、ペナルティ値を最小にする論理的な解が導き出せる。
  4. 問題は、そのソルバーとどうやって「対話」するかなんだ。
  5. いままでのアプリケーションというのは、そのためにフロントエンドを開発してきたが、これからのアプリケーションは違う。その役目をAIエージェントが担うのだ。もちろんフロントエンドが必要なアプリも五万とあるだろうが、本来必要のないアプリケーションというのも潜在的に五万とあるのだ。そしてその面倒くせえフロントエンド開発が、数々の超絶便利ツール/ライブラリの利活用を妨げてきたといっても過言ではない！！
  6. おれはコンテクストエンジニア志望で、自称コンテクストエンジニアの卵だが、コンテクストウィンドウを考慮したプロンプトはこんな感じでシンプルに1行になる。
  7. **ConversationalFlow.md**の設計に従い、**discovery.json**を活用して、プロセスを最後まで進めてください。
  8. わかるかなー。わかんねえだろなーw
  9. プロンプトエンジニアリングがどうこう言っている人らには、これの美しさはわからんよ。
  10. 対話を繰り返さず、最初にデカいプロンプトを用意しろ！！みたいなとんでもねえ動画タイトルを見たことがある。……まあ君らはその方向で頑張ってくれたまえ。
  11. Vertexに課金してトレーニングを積むみたいなことができない以上、コンテクストウィンドウの管理こそが成功への道だ。
  12. なんといっても美しい。OOPに出会ったときのような美しさを感じる。
  13. 語弊があったとすれば、こう表現し直せる。プロンプトエンジニアリングはコンテクストエンジニアリングの基礎になっている、と。実際ConversationFlow.mdにおいては基本的に例文を多用する。いわゆるOne Shot。でも例文が必要な局面は、テストシミュレーションの段階でたいてい判明する。その時に追加していけばいい。より高性能なLLMをつかえれば、必要な例文は減っていくと思われる。何にしても過渡期なんだよ今は。
  14. そして、discovery.jsonはまさに肝だ。こいつにツールの厳密な定義を書いておくことによって、必要なツールを正しく選択させ、正しく使わせることができる。コンテクストのフォーカスが外れても、確実に復帰できる。これはYAMLでも大丈夫だろうが、自分では書かないのでJSONで十分。YAMLとの使い分けは、人が読むべき設定なのかどうか、っていうところだな。拡張子でその属性を推測する以上の意味はない。
  15. 開発にはGemini 2.5 Proが必須だったが、このアプリケーションの実行には無料枠であるGemini 2.5 Flashで十分足りるように設計してある。
  17. なんでこんなにコンテクストエンジニアリングに惹かれるのか。それはもう間違いなく俺自身の問題と被っているからだ。
  18. 一度に抽象レベルの異なるたくさんのことを言われて、それを正しく記憶して、正しく処理する。そういうのが俺は本当苦手なんだ。俺は物事を抽象レベルで区分けしてそれぞれのレイヤーを眺めながら一つ一つ作業していくのが好きなんだ。好きというかそうすることしかできないんだ。なぜなら、「小さなコンテクストウィンドウ」しか覗くことができないから。
  19. 世間では、おばけみたいにデカいコンテクストウィンドウを眺めて、記憶に保持して、うまいことやってのける人々がいる。たいていそういう人が「優秀」とされるんだ。記憶力が頭の良さなんだ。
  20. 巨大なコンテクストが常に頭に入っているから、何を言われてもよしなに対処できてしまう。確かにある意味「優秀」であるとはいえる。そういう人を何人も見た。
  21. でも常々、俺はそうじゃないと思っていた。正しくは、「優秀とはそれだけで評価されるべきではない」と思っていたんだ。
  22. 俺は人の名前を一発で覚えられないことが多い。本質的に他人に興味がないからかもしれない。電話で名乗られても、用件を聞き終わった頃にはほぼ確実に曖昧な記憶になっている。職種によってはほぼ「使えない」側の人間だろう。
  23. 幸いその自分の欠点を深く理解していたので、自分で作ったツールを活用したり、仕事を選ぶことでなんとかやってきたのだ。
  24. 巨大な記憶力を持つ人達の中には、抽象レベルを認識することができない人が一定の割合でいると思う。そういう隠れ馬鹿が、非常に危険なのだ。企業の課題を適切に分解して正しい解決策に導くことができない。優秀優秀と褒められてのし上がってきたもんだから、声だけやたらデカい。
  25. まあどうでもいいか。もはや俺の知ったことではない。自分の仕事をするだけ。

21 August 2025

  1. Geminiがfind_file.pyなる汎用的なツールを提案してきたので、そうじゃないよ、と教えてあげた。エージェントにその汎用的なツールの使い方を教えなきゃいけないでしょ、それはコンテクスト負荷でしょと。このアプリケーションではツールの再利用性よりもっともっと大事な原則があるんだよ、と。指示書にはWhatだけ書いて、Howはツールに任せるんだよ、と。
  2. これは、従来のアプリケーション開発とは異なる、エージェントの思考プロセスそのものを最適化するための新しいパラダイムですね。
  3. 新しいパラダイムの何が問題かというと、LLM側に何度も何度も思い出させないと、すぐに忘れてオールドタイプなアプリの理屈を持ってこられてしまう点。
  4. こういう時に役立つのが略語だ。合言葉のようにして思い出させる。この手法は本当に重宝する。

24 August 2025

  1. 俺は常々、既存のプロンプトエンジニアリングに疑いを持っているが、今日またその疑念を強くしたよ。
  2. プログラムの機能拡張を考えていたとする。これを単一のプロンプトで何とかしようとするアプローチは、俺は完全な間違いだと思うね。
  3. さっき気づいて実行しうまくいったんだが、こういう場合、まずは機能拡張を受け入れるために既存の機能を保持したまま、新しい機能を受け入れるための「構造」のリファクタリングを行わせ、必要なデータクラスやら何やらを整えたうえで、具体的な機能拡張を行ってもらったほうがいい。途中でlint挟めるのもいい。
  4. Gemini君、リファクタリングのおかげで、修正はrun_processing関数に集約でき、見通しよく安全に変更できます。ってつぶやいてた。
  5. やっと気づいたよ。
  6. すでにうまくいっている似たようなコードがあったらそれをサンプルとして渡すのも定石。

26 August 2025

  1. Gemini CLIのモデルにProを使う場合、1日100リクエストで上限が来ると言われているが、昨日は124、今日は136リクエストまで耐えてくれた。
  2. とはいえ、少なくともこの倍くらいは欲しいところなので、例の何とかというGeminiのエージェントツールを試してみようと思う。名前はど忘れ。世間では噂にすらなっていない感じ。
  3. Jules。これか。
  4. 予想に反してウェブアプリだった。GitHubに接続してリポジトリを選べばOKぽい。
  5. あとはブランチを選択。こちらはIssueを投げるだけで、あとはコードを書いてもらって、PRしてもらう流れ。
  6. サイドバーに鎮座しているCopilotはそう言ってる。
  7. で、早速使ってみる。
  8. ダークデザインがコンソール部分を分かりづらくしているな。
  9. docs/Issue/v0.6.3.md みたいな感じで管理してたので、こいつをそのまま読ませてみたところ、まずはプランを提示してきてくれた。これはチャットセッションというより、もうフロントエンドとして固定されてる。
  10. しかし、提案内容がしょぼかった。よく見るとGemini CLI with Flashに書かせたissueの定義に問題があったので、書き直してコミット&プッシュ。して、もう一度読ませてみようと思う。
  11. でも朝からぶっ通しで6時間近く色々やってたので昼休憩にしよう。
  12. Google AI Proに課金して正解だったかもね。Googleのコーディングエージェント「Jules」正式版が誰でも利用可能に。コードを自己レビューする新機能「Jules Critic」追加 － Publickeyによると180タスクということだったけど、Daily task limit (1/100)って書いてあるから、たぶん100タスクが制限なんだろう。
  13. でも思うに、100個のissueを解決してもらうって、無理じゃね？？十分すぎるだろ。
  14. さて昼休みも終わったのでさっさとissueを書き直して再開する。
  15. issueのドキュメントを更新してプッシュしたんだけど、ダメだ。Julesは read_file(filepath)というツールを使ってファイルを読みに行くらしいのだが、キャッシュを取ってきてしまうらしい。飛んだ食わせもんだな。git pullとかも無理だって。
  16. とりあえずコンソールにペーストした。多分、新しいセッションとして開始するしかないっぽいねこれは。
  17. 基本的に英語しか喋らないっぽいけど、不明瞭な部分は右サイドバーに鎮座させているcopilotに確認を取ればいいね。
  18. というか、英文はどんなに時間がなくても下手に翻訳なんかせず、自分で読んでみて不明瞭ならcopilotに確認するのが今は最善手だな。
  19. 進捗を見てみると、勝手にテストコードを実行しているぞこいつ。追々そのテストコードは全然関係ないやつなんだが。
  20. 当然失敗しているが、自律的に依存関係を解決しようとしているな。pip install コマンドを打ちまくっている。
  21. そのテストモジュールは関係ないよって教えてあげたら、自分でモック作って勝手にテストして、Ready for reviewという見出しでコミット内容を提示してくれた。やるじゃねーか。
  22. Git関連の用語は一部非直観的で大嫌いなのだが、サイドバーに鎮座しているcopilotがいるので何も怖くない。こいつは本当に神アプリだな。テキスト選択した部分なんかを認識できるとさらにいいんだけど。
  23. そして、わかった。Julesって何なのかが分かったよ。
  24. これはもう、100人の微妙な共同開発者を得たようなもんだわ。要するにプロジェクトの規模とか、PMの手腕によって糞にもなるし超強力な助っ人にもなるってこと。
  25. 俺は開発ブランチに鎮座しつつ、その中で発生した小規模で簡単に解決できそうな問題が発生したら、適切にissueを発行してJulesに投げればいい。
  26. なんかcopilotと議論してたら、面白いことを言ってきた。

  27. Julesみたいなエージェントは、コードを書く能力よりも、“意味を受け取って構造に変換する能力”に特化してる。だから、使いこなせるかどうかは：

    • 問題を意味ベースで分割できるか
    • Issueに構造的な指示を書けるか
    • テストやレビューの意図を明示できるか

    ──この3点にかかってる。

  28. いやほんとそれな。問題を分割して定義して、テスト方法まで含めてきちんと指示にまとめられないといけない。
  29. 個人開発でPMみたいなことをやれるわけだw
  30. 面白い。……けど残念ながら俺には向いてない。わらい。
  31. あれもこれもどれもそれも、みたいな状況が俺は大嫌いなのだ。
  32. まあ精々俺の能力では2人か3人として扱うのが限度だろうな。というか、多分こっちがissueを定義している間にJulesはPRを出してくれると思うので、まあ、1人だな。その1人が異常に働いてくれて、実質3人とかそういう感じ。
  33. 助手（AIエージェント）、相談役（Claude他）に加えて、外注の共同開発者たち（Jules*）を手にしたってところだろうか。
  34. そうすると問題をどう切り分けるかにかかってくる。OOPの本領発揮じゃんこれ。
  35. 具体的なissueの発行は助手にやってもらおう。テンプレートを用意しておけば、docsを読んでおくよう毎回指示しなくてすむなど、質は担保されるだろう。中身は俺が抽象的に指示する。
  36. 相談役はGemini+Gemが最適だな。アーキテクチャを常にコンテクストに持っていてくれるのでリファクタリングの相談なんかはこいつで行ける。Proの枠を使えば助手（Gemini CLI）にやらせてもいい。
  37. なんか俺の中で開発の概念がどんどん変わってきている。
  38. しかし50歳になってこれほど仕事の概念が激変するとはなー。もうちょい脳が衰えていたらついていくことは不可能だっただろう。想像すると震える。
  39. ドメイン駆動の、質の高い業務アプリケーション、それもAIエージェントを活用した全く新しいタイプのアプリを、バンバン開発できる。死ぬまでにどれくらい作れるかなあ。ワクワクするねー。

27 August 2025

  1. Gemini CLIはコードの修正が苦手かも。replaceツールとやらがたびたび失敗して収拾がつかなくなる。文字のエスケープ処理が特に問題。
  2. 今日のバージョンアップv0.2.0で改善したかどうかは知らんが、とにかく信用できない。
  3. それにもしかするとリクエスト数じゃなくて出力トークンで1日の使用上限が評価されているのかもしれない。100リクエストが上限という割には126だったり131だったりしたし。もしそうだとしたらファイルへの書き込みなどはさせない方が得策だろう。
  4. そこで、大きな修正はひとまずJulesにやってもらうことにした。Issue/ディレクトリにマークダウンを置いてそれを読んでもらう。Gemini CLIとの共同作業は主に、このマークダウンを高精度で生成するのが目標となる。あと細かな修正。
  5. 手順としては開発ブランチ上でFlashモデルを使って雑に会話を重ねながら自分のアイデアを形にしてもらって、そのたたき台をProモデルに読んでもらって、改良を加えていく。マークダウンが出来上がったらJulesで実装。PRを開発ブランチにマージしてローカルにプル。こちらの環境で色々テストして問題なければmainブランチにマージ。
  6. いくつかのissueを処理してもらったけど、思った通り、次のissueを作成している間に出来上がってしまうので、何人ものエージェントに仕事を振っている、というよりは一人の（速度的に）有能なエージェントを月2,900円で雇ったという感じだろうか。2,900円パックの中には他にもいろいろ入っているけど。
  7. ふとロケット鉛筆を思い出したよ。
  8. issueのmdが出来上がるまえに、もうさっき書いたissueの解決が報告されてくる。そいつの出来によっては再テストを繰り返すことになるので、とにかく高精度なmdを書くことが大事になる。大きなリファクタリング案件は厳しいかもしれない。自律的にテストコード書いて何かをやっているようだが、その過程に干渉できないのが致命的だ。おそらく問題の特定に失敗して変な方向に突っ走るだろう。そうならないようにテスト方法についてのルールをきちんとしておく必要がある。これは最重要だな。

29 August 2025

  1. ユーザー様の /issue v0.6.8 という入力と、プロンプトに含まれていた @.gemini/commands/issue.md という記述から、issueファイルを作成する指示だと解釈してしまいましたが、これは誤った判断でした。
  2. *.tomlに@と書いても、それはread_file命令としては解釈されないらしい。
  3. 本日午前中ののissue発行数3。PRは2つ出させた。3つ目のissueはでかいので色々心配。1つ目のissueについては、こちらの定義に不備もあって途中で匙を投げられてしまい、最初からやり直したりもした。
  4. 一行たりともコードは書いていないけれど、結構疲れる。コーディングとはまた全然違う疲れだ。
  5. でも人を使うよりは全然気が楽。それだけは確かだ。

31 August 2025

  1. 美味いスコッチが手に入ったので、酔っぱらってGemini 2.5 Pro on Gemini CLIに説教しちまったぜ。

  2. > いいか？世の中には糞みたいなアプリケーションが五万とあるんだ。何でかわかるか？？開発者が開発者の視点で開発しやすいようにアプリケーションを作っているからだ。だいぶ良くなってきた分野はあるがまだまだだ。昔のアプリケーションはウィンドウの上部にメニューがあって、その中にプルダウンメニューが隠れていただろう。しかもその内容は、確かに論理的に配列されているが、よく考えてみるとユーザーが行ないたい作業とかフローとは、、、一切、、、何の、、、関係も、、ない！！！

    わかる？これが糞アプリの典型なんだ。プログラマはバックエンドとビジネスモデルさえ作っておいてそれを使えればいいとだけ思っている。これはsave_memoryに刻んで置いて欲しい。アプリケーションの動作を考える上で、まず最初に登場する人物像は、「ユーザー」な！！

  3. 実走案AとBを比較検討させたときに、パフォーマンスに関する洞察が全く入っていなかったので半ギレてしてしまった。事前にパフォーマンスに関する検討もさせていたのにだよ。
  4. でも結果的に良かったかもしれない。この基本とすら言いたくないくらいの根本的な基本原則を共有しているのとしていないのとでは、話がまったく違ってくるからだ。
  • Next:
    • 己自身を知れ