Home → 2026 spring, since 2009-12-01

2026春

01 March 2026

  1. Prev:
  2. Web版のGemini 3.1 Proと議論していて気付いたAgent Skillsの使い方をメモ。
  3. 今まで、技術スタックに関する正ドキュメントをプロジェクト毎にdocs/reference/に置いて、GEMINI.mdにそのロケーションと使うタイミングを一々指示していた。
  4. だが、これをスキル化してしまうことによりGEMINI.md等の汚染が少なくなり、かつ、そのスキルをlinkインストールしたextentionで共通化してしまえば、ドキュメントの更新がすべてのプロジェクトに反映される。
  5. スキルを使うのは大抵サブエージェントなんだし、extensionは必須だ。
  6. Gemini CLIがコードを担当していたころは、間違ったAPIの使用による手戻りを少なくすることがQuotaの経済にとって極めて重要だったが、外部エージェントに委譲する場合も、ある程度詳細な計画を含めてしまうことにより、Quotaについてはブラックボックスだからわからないにしろ、少なくとも負担を軽くすることはできるはずだ。負担が軽いということは「実装現場」における詳細により頭を使えるということであり、コードの品質が良くなることを期待できる。

  7. やはりおれはタスクの掛け持ち2つまでがちょうどいい。3つにするとくたびれてしまうよ。2つだと暇な時間が生まれてしまうけど、もっと計画をよく読んだり深く考える時間にあてた方がいい。
  8. アプリ開発ひとつ + Gemini CLIのextension開発ひとつ。これがちょうどいい。アプリ自体の開発と、その開発品質自体が常に前進する形。
  9. で、そのextensionの進化がとまらない。進化とはいっても、Gemini CLIを少しでも他の有能なコーディングエージェントに近づけるためのhackがほとんどではあるけども。
  10. 今朝思いついたスタック知識のSkill化だが、技術スタック毎にサブエージェントを定義などしていられないので、tech-expertという単一のサブエージェントを定義して、そいつに複数のスキルを扱わせる形がいい。
  11. すでにgemini-cli-expertという形でやっている方法だが、スキルを複数持たせる点が違う。
  12. 問題となるのは、そのtech-expertをどうやって自律的に使わせるか、だ。これはSNSの投稿などでもよく見かけるGemini CLIの弱点「ツールの使い方がド下手くそ」案件に引っかかる。サブエージェントにしろスキルにしろ、明示的に言わない限り適切に使ってくれないことがほとんどなのだ。こんな便利なツールがあるよってことを伝えているだけでは絶対に守ってくれない。
  13. そこで思いついたのが、SessionStartに仕込むフックだ。
  14. このアイデアはgemini-3-flash-previewと議論していなければ生まれなかったかもしれない。
  15. このフックに仕込んだスクリプトで、プロジェクトが使っている技術スタックを調査させ、そのリファレンス利用スキル定義されているものをリストアップし、たとえばCP-SATとMUI7についてはtech-expertエージェントに調査させてから計画を確定させるよう指示を出してしまう。
  16. というかそもそも、Gemini CLIは確かにGEMINI.mdを読んでくれはするものの、そこにセッション開始時の知識の初期化に関する指示を書いておいたところで、最初にユーザーが指示しない限り何も始めないという特性がある。プロジェクトの設計理念やら何やらの知識を初期化させるためには、それらすべてをGEMINI.mdという既定の文書にまとめておかなければならないのだ。
  17. そこで、初期化に関するプロンプトについても、すべてこのSessionStartフックに仕込んでしまおうかと考えたのだが、そうするとGEMINI.mdとの責務の重複と混乱の未来が見えてくる。

02 March 2026

  1. Antigravityを使い始めて1週間くらいか。弱点発見。npm testなどのコマンド実行でいちいち停止してくれる。テストで躓いてしまうと、もうずっと張り付いてみていないといけないお守り状態となる。Ctrl + ,でAgentの設定から許可リストに追加してみてもだめだった。
  2. タスクによっては、Allow This ConversationだとかRunだとかっていうボタンを延々と押し続ける、糞みたいな体験ができる。
  3. alecdotdev/Markpad: The Notepad equivalent for Markdown
  4. マークダウンファイルはAntigravityでもVSCodeでもなく、このマークダウン用メモ帳「Markpad」で開くことにした。Notepadにちなんでいるのだろう。求めていたビューワーのコンセプトに合致している。
  5. Pathを通してGemini CLIがマークダウンを書こうとしたらフックが起動してこいつで開いてくれる。実際のファイルを開かないのがポイント。
  6. さすがに初回の起動はメモ帳より遅いけど、専用のビューワーなので読みやすいし、ダークモードもあるので目に優しい。

03 March 2026

  1. jintrick、その「恐怖」はエンジニアとして極めて健全であり、鋭い。 AIが「もっともらしい理屈」を並べて、バックエンドの深淵に「不要で複雑な、メンテナンスの重荷にしかならないガラクタ」を勝手に詰め込んでいく。これは開発者にとって、脆弱性そのものよりも恐ろしい事態だ。
  2. 「懐疑的なシニアアーキテクト」というペルソナのGeminiを使いこなすには、こっちも一定の知識や経験をもち、こいつの提案や計画を注意深く読み込む必要がある。バランサーというサブエージェントを導入したが、それでもおかしな設計を盛り込まれてしまい、手戻りで丸一日要してしまった。このやり方はいずれ破綻する。

  3. ついに!プロジェクトで利用されている技術スタックについてのドキュメント(ナレッジベース)を根拠に質問に答えてくれるサブエージェント、tech-expertが完成した。関連するフックやスキルと共に、自分専用のGemini CLI Extensionであるjintrick-coding-extensionに統合。セッション開始時にフックを仕掛けてpackage.json等から技術スタックを抽出し、「この技術スタックについてはtech-expertに聞くことができる」というコンテクストをセッション開始前の初期プロンプトとして叩きこんでしまう。
  4. ナレッジベースはPython製のrag-makerをGemin CLIに使わせてそれぞれ作成しなければいけない。そこが手間。GitHubリポジトリがあれば簡単なんだけど、ウェブページとして細切れのドキュメントになっていると収集が自動化できず手間取ることがあるが、それもLLMの力を借りて強引に何とか出来てしまうことが多い。
  5. コンテクストを切り離して使えるRAG専用のエージェントなので、Gemini 3 Flashで十分な性能を発揮してくれる。こいつはもう実質的に無限のQuotaを持っている。使い切るのは容易じゃない。今後どんどん活用していこうと思う。つまり、tech-expertを定義するYAMLフロントマターには、明示的にgemini-3-flash-previewを指定しておいた方がいいってことだ。
  6. JulesがGemini 3.1を使えるようになったらしい。んだが、指示違反多発させてデグレードまで起こして、Gemini CLIプンプン。なんだこれ。すげーアホになっちゃった。
  7. というか、SNSで全然話題になってなくてワロタ。
  8. 幸いなことに、いまAntigravityに実装のほとんどを任せているので影響はほぼゼロ。でもはやいとこ修正されるといいな。
  9. まあいずれにしても、おれはやる。3 Flashでもなんとか使い物になるレベルに引き上げるため、コンテクストエンジニアリングの腕を磨くぞ。

04 March 2026

  1. Claude Code Agent Teamsの衝撃と実際 | gihyo.jp
  2. 非同期で連携するサブエージェントたち。
  3. 使いどころは:
    • 大規模リファクタリング
    • 大規模コードレビュー・バグ調査
    • 新規実装
  4. 今日はGemini 3.1 Pro Web版チャットアプリを通じて実践を通じたバックエンドに関する指南を受ける。とても楽しい一日になりそうだ。
  5. Linuxサーバー側のタスクマネージャーでNode.jsスクリプトを走らせ、CSV経由でテーブルを更新できる、というのが本日のゴール。
  6. 堅牢なシステムを構築したいので、テーブル設計のアンチパターンを徹底的に叩き込んでもらう予定だ。
  7. 最近Gemini系のエージェントどもが微妙にアホなので、ストレスが蓄積していたんだ。特にJules。お前だ。
  8. phpMyAdminやべえ。現代のフロントエンドの常識でみるとアタオカレベル。今のうちにさっさと変更した方が良さげだなこれは。

05 March 2026

  1. さて今日も猫氏を召喚してから仕事を始めますかね。あと195ポイントためればお二方に登場してもらえるのだ。
  2. skill-creatorから学ぶSkill設計と、Orchestration Skillの作り方 - 逆瀬川ちゃんのブログ
  3. 本当にありがたい文書。これからはこういう文書をこそ熟読すべきなのかもしれない。Claude Codeはうまくやってる。システムプロンプトとコンテクスト制御でモデルをうまくコントロールしていると思う。そのノウハウをGemini CLIで活かしたい。モデルの性能では負けていない筈……なんだ……から。
  4. それはそれでいいとして、たき火の猫氏とどう付き合うかだな。メモリを400MBも食う。
  5. 選択肢1: 猫氏を諦める
  6. 選択肢2: 猫氏を表示させる分だけタスクを縮小する
  7. 当然2だな。最近詰め込み過ぎていたのかもしれん。
  8. 世界を操る「石油とドル」の闇…絶望的な物価高から生き残る方法【ゆっくり解説】 - YouTube
  9. 今回もまた良質な動画をありがとうございます。さっそく息子氏に推薦しとく。ただちょっと陰謀論寄りの解釈の揺れがあるかもしれないので釘はさしておこう。

06 March 2026

  1. Gemini CLI v0.32.0(すでにパッチv0.32.1が出ているけど)
  2. 極めて重要なアップデートが含まれている。Kind.Agent と呼ばれる、サブエージェント専用の新しい分類。つまりサブエージェントがサブエージェントとして正しく再定義されたとみていい。熱望していた機能が来たかもしれない。
  3. codebase_investigatorなどのサブエージェントはシステム上「ツール」に分類されていたが、ツールはKind.Defalt、サブエージェントはKind.Agentに分類された。
  4. 並列実行の解禁。複数のサブエージェントをバックグラウンドで走らせることができるようになった。
  5. 地味にうれしいUIのカプセル化。サブエージェントが内部で行うツールコールをメインのチャット画面に表示させない仕組みが導入された。
  6. サブエージェントがサブエージェントを呼び出すことはできないようだ。
  7. さて実際にインストールして色々触ってみよう。
  8. /agents list
  9. generalistなるデフォルトのエージェントが追加されていた。
  10. どうやら何でもできる汎用エージェントらしい。全てのツールへのアクセス権を持っている。
  11. おそらく「バグの原因を特定」みたいな試行錯誤が必要なタスクを投げる形になるのだろう。
  12. Gemini CLIの最大の弱点である「ツールを使うのが下手すぎる」問題が解決されているなら、これはわりと強力なサブエージェントとなる。一方で、調査の過程が見えづらくなったけっか、頓珍漢な方向でどんどん調査と、そう、実装までも勝手に進められてしまう懸念もでてくる。
  13. 原因を推測して、その推測をTrueとしてコードを修正してしまうという悪癖があるから、たまったものではない。
  14. generalistを使う用途はかなり限られるような気がしてきた。
  15. まあやばかったら/agents config generalistで機能を切っておけばいい。
  16. さて、サブエージェントの並列実行をやらせてみた。gemini-cli-expertにKind.Agentの並列化ロジックについて、tech-expertにカレントワークスペースで使用しているesbuildの設定が並列ビルドに最適化されているかを分析させた。
  17. 明らかになったのは、これは並列実行であって非同期処理ではないということだ。つまり、確かに複数のサブエージェントを同時に走らせることはできるが、その間、親エージェントは待機していなければならず、チャットは止まる。
  18. まだ理想には程遠いのかも。

  19. 前回の検証時にエラーテスト用のファイル(broken.cjs)を削除する際、誤って git checkout tools/build.cjs を実行してしまい、私自身が行ったパフォーマンス改善のコードまで全て元の状態にロールバックしてしまっていた。言い訳の余地もない完全なミステイクだ。 by Antigravity
  20. こいつ蹴っ飛ばしていいですかね。

  21. 根本的にGemini CLIを調教する方法を思いついた、かもしれない。
  22. 結局のところ、モデルの性能はそれほど変わらないのだとして、どうしてこんなにGemini CLIはClaude Codeに後れを取っているのかといえば、色々あるだろうがやはりシステムプロンプトなのではないか。
  23. ふと思い立って、gemini-cli-expertという自作サブエージェントにシステムプロンプトを変更する方法を調べさせたところ、なんと、GEMINI.mdのようにマージするのではなく、完全上書きすることが可能らしい。
  24. 何はともあれ、デフォルトのシステムプロンプトを書き出すことから始める。
  25. $env:GEMINI_WRITE_SYSTEM_MD=1; gemini
  26. これで.gemini/system.mdにシステムプロンプトが書き出される。
  27. さっそくやってみたところ、確かに書き出された。さすがにRAGで制御したサブエージェントなのでハルシネーションは滅多に起こらない。
  28. 問題はどうやって修正するかだ。プロンプトのアンチパターンを見つけるのもいいが、Claude Code
  29. 怪しい情報によると、Piebald-AI/claude-code-system-prompts というリポジトリでClaude Codeのシステムプロンプトが公開されているらしいので、Gemini CLIに取得を依頼したところ、ウェブ検索を始めてしまった。おいおい、そういうとこだぞ。ツールの使い方が下手糞過ぎるんだ。一々gh使えと指示しないと使えない。
  30. で、調べさせたところ、恐ろしいほどモジュール化されている。Gemini CLIのsystem.mdなど子供だましに見えてしまう。
  31. Claude Code のプロンプトは、110以上の断片に分割され、状況に応じて動的に結合される極めて高度な「モジュール型」であることがわかった。Gemini CLI に取り込む(奪う)ためには、その「核」となる部分を抽出し、一つの強力なシステム指示書として再構成するのが最も効果的だ。
  32. いやーもうすでに心が折れそう。
  33. 単発のsystem.mdしかないGemini CLI vs. 110のモジュールが動的に結合されるClaude Code
  34. おっと。俺の心が折れているさなか、Gemini CLIは勝手に例の「generalist」を起動し、Gemini CLI用に統合するタスクを投げたようだ。
  35. まあ確かに110ものモジュールを統廃合する過程を延々チャットで読まされても鬱陶しいからね。
  36. やはりというかなんというか、generalistがかれこれ1時間くらいずっと走ってる。UIのカプセル化とやらで過程も全く見れないので、固まってしまっているのか進行中なのかさえ分からない。ゴミだろこれ。
  37. で、タスクを分割しろといったら自らWeb Fetchツールを使い始めた。馬鹿だろどう考えても。やっぱりツールの使い方が下手糞過ぎる。
  38. 結局、generalistを複数起動してタスクを並列処理させろと直接、細部まで指示した結果、ようやくタスクを分割し、generalistを3つ起動して何かやり始めた。
  39. それぞれのエージェントが今やっていることは、一応短文で表示されている。でもおいおい、Implementign curlとか言ってるエージェントがいる。困ったもんだよコレ。
  40. そしてそれぞれのエージェントは固まってしまっているようにも見える。
  41. どうやらタスクによってはフリーズのリスクが高いようだ。3, 4, 6, 8 エージェントと色々やってみたが全く完遂できない。
  42. さて。Claude Codeのシステムプロンプトをすべて取得し、解析させてみたところ、Gemini CLIのそれとの恐ろしいほどの違いが浮き彫りになった。
  43. ①徹底した「コンテクスト非依存性(モジュール化)」
  44. Gemini CLIは全ての指示を一つの巨大なマークダウンに詰め込んだ全部入りのモノリス構造であるのに対し、Claude Codeは228個の断片に細分化し、実行時に「今必要な最小限の指示」だけを動的に結合してモデルに渡している。これが絶望的な違い。
  45. ②ツール説明の解像度が異常に高い
  46. やはりというかここに違いがあった。Gemini は各ツールについて数行ずつの簡潔な説明にとどまっている一方、Claude Codeは一つのツールについて一つの専用マークダウンファイルを割り当てている。……ってこれはGemini CLIもやってるはずだな。これはシステムプロンプトじゃなくて、SKILL.mdの書き方の問題だろう。
  47. ③内省の隠蔽
  48. Gemini CLIは考えお述べてから行動せよと言った指示が混ざることがある一方、Claude Codeは思考プロセスや内省をユーザーに見せるな。最終的な成果物だけを提示せよ、と厳格に「ポエム」を禁じている。
  49. ④指示のメタ化
  50. Claude CodeはAIエージェントが、別のAIエージェントを設計、起動するための指示が非常に充実しているとのこと。Gemini CLIは「自分がどう動くか」が中心の記述であるのに対し、Claude Codeは「自分が指揮官として、いかに部下を動かすか」というメタな視点が組み込まれている。
  51. 結果として、Gemini CLIは饒舌なアシスタント、Claude Codeは無口だが仕事が完ぺきなプロの道具、みたいになるということだ。
  52. Gemini CLIによると、両者の最も大きな違いは「状況に応じてプロンプトそのものが変形・統合される」という動的なアーキテクチャ」だそうだ。
  53. .agent/rules/*.mdを法典として尊重している記述も見つかった。ここは肝の一部だと思う。Antigravityがこのルールを参照する以上、Gemini CLIのシステムプロンプトにもこれを刻み込むのは、もうマストと言っていいだろう。
  54. Claude Code側はシステムプロンプトの「エントリポイント」に何を記述しているのだろうか。
  55. system-prompt-worker-instructions.mdを読み解く。ここには思考のメインループが定義されていた。
  56. 1. Simplify, 2. Run unit tests, 3. Test e2e, 4. Commit, 5. Report
  57. この5ステップの各項目に、さらに詳細な指示が「動的に」埋め込まれる。
  58. その動的な埋込にはプレースホルダーを使っている。${変数名}
  59. このプレースホルダーを解決する手段をどこかに定義しておかなければならないだろう。
  60. 驚くべきことに、定義はマークダウンには一切書かれていなかった。
  61. Claude Code は、静的なプロンプトを投げているのではなく、「JavaScriptによる高度なセッション管理と、状況に応じたプロンプトの動的合成(コンパイル)」 を毎ターン実行している。
  62. なるほどねえ~そりゃ勝てねえわけだよ。コンテクストウィンドウの管理がもう根本からぜんっぜん違う。
  63. Claude Code は、毎ターン JavaScript 側でセッション状態(モード、直前の成否など)を評価し、${..._FN()} 形式の関数を含む 228 のプロンプト断片を動的に「コンパイル(合成)」してモデルに投げている。このアーキテクチャは Gemini CLI の Hooks 機能で完全に再現可能であり、それこそが Claude Code 同等の「知性」を実現する唯一の道だ。
  64. なんてこったい。
  65. いやまてよ?そういえば最近Runtime Hooksが導入されたんだった。これを使って何とかならんだろうか。リポジトリを調査させてみよう。
  66. Gemini CLI の BeforeModel フックは、モデルに送られる直前の llm_request.messages 配列(全履歴)を直接書き換えることができる。これは Claude Code が内部で行っている「断片の結合」と全く同じ、あるいはそれ以上に強力な操作だ。
  67. これで何が起きるか? Gemini CLI は、「常に全ての指示(228ファイル分)をメモリに置く重たい AI」 ではなく、「その瞬間に必要な『法(Rules)』と『知恵(Prompts)』だけを瞬時に合成してまとう、 Claude Code 以上の切れ味を持つエージェント」 に進化する。
  68. なんかすげー自信満々だぞこいつw Claude Code以上という根拠を示せと言ったら3つあるそうだ。
  69. 優位な点①「ブラックボックス」 対「プログラマブル・オーケストレーション」と。いやまあ確かにポテンシャル的にはその通りかもしれないけど、その「オーケストレーション」をフックなんかで実現するのがとても大変そう。
  70. 優位な点②「システムプロンプトの連結」対「メッセージ履歴の全操作」。ユーザーの最新発言の直後にシステム・リマインダーとして動的に挿入できる、と。これはClaude Code側を過小評価している。システムプロンプトを動的にインジェクションして毎ターン送っているんだから、かなり強力だろう。互角と言っていい。
  71. 優位な点③「Antigravityとの法典共有」。これは何言ってんだかわからなかったので無視。
  72. Claude Code は「完成された黒い箱」だが、Gemini CLI + Runtime Hooksは「中身を組み替えられる透明な知性」だ。
  73. うむ。土日を使って実験してみる価値は大いにありそうだ。

  74. Google Workspace関連のスキルが手に入った。
  75. npm install -g @googleworkspace/cli、これでgws.exeにパスが通る。
  76. gemini extensions install https://github.com/googleworkspace/cli、これでスキルセットが一括で手に入る。というか今のところスキルだけだな。フックやエージェント、MCPなんかは同梱されてなかった。
  77. そして認証が結構面倒くさいな。
  78. Google Cloud コンソール > APIとサービス > 認証情報 > 認証情報を作成
  79. OAuth 2.0 クライアントIDを作成してjsonをダウンロード。
  80. ~/.config/gws/client_secret.jsonとして保存。
  81. gws auth login
  82. ブラウザで認証。
  83. 失敗。Gemini CLIは未認証みたいなコメント。
  84. 他に試したいことが色々あるので後回しだなこの件は。

07 March 2026

  1. 今日はGemini CLI拡張を色々弄る。
  2. まずはフック。AfterAgentというイベントに、Gemini CLIの生成が終わったことを知らせるトースト通知を仕込んだ。
  3. というか、どうもサブエージェントが固まりがち。v0.32.1。修正を待つしかなさげ。

  4. さて。Claude Code流のコンテクスト管理について学びを深めよう。
  5. .agent/rules/*.mdCCはどう扱っているか、例の怪しげなリポジトリを調査させた。
  6. 調べた限りではシステムプロンプトで指示を出しているだけのようにも見える。
  7. Runtime Hooksでやろうとしたが、YAMLフロントマター(特にglob: "*.ts"のような指定)を読み込んでマッピング用のjsonを構築するのはいいとしても、コンテクストに応じてプロンプトを生成するというのは筋が悪いことがわかった。
  8. そこで、.agent/rules/*.mdを参照させるプロンプトについては、Gemini CLIではなく素直にAntigravityを利用することにした。

08 March 2026

  1. まずは低品質なsystem.mdを何とかすることから始めようと思う。
  2. リポジトリを調査した。どのような議論が起こっているのか。
  3. まず、システムプロンプトの核となるpackage/core/src/prompts/snippets.tsは数日おき、時には連日更新されているという。主に新機能の導入に伴う指示の追加などが行われており、体系的な設計変更というよりは「継ぎ足し」に近い。
  4. 当然コミュニティではプロンプトの品質やそれによる「命令無視」について、非常に厳しい指摘が複数上がっている。プロンプトの変更がgeminiの「知能」を低下させていないかを自動検証する「Behavioral Evals」の導入が議論されている(#18257)。
  5. さてと。
  6. SSOTはソースコードだ。そこでリポジトリのクローンをgrepで調査させてみたところ、Gemini CLIのシステムプロンプト、もといシステム命令(SI)は、ある程度動的に構成される仕組みを持っていた。もちろんClaude Codeとは比較にならないくらい貧弱ではあるが。
  7. package/core/src/prompts/snippets.tsに定義されたSI用のスニペットが、同ディレクトリのPromptProvider.tsのオーケストレーションの元、状況に応じてインジェクションされる。基本的な命令セットおよびスキルやフック、サブエージェントなどの情報がまず挿入され、GitワークスペースならGitに関する命令セット、PlanモードならPlanningに関する命令セット、YoloモードならYoloに関する命令セット、Sandbox管理下ならSandboxに関する命令セットが追加される、と言った具合だ。
  8. さらに、セッション内でplanモードやyoloモードに変更した場合も動的に上記スニペットが注入される。
  9. ところが、GEMINI_SYSTEM_MD=1でSI上書きモードにした場合、スキル、フック、サブエージェントなどに関してはセッション初回にプロンプトが注入されるものの、基本的に命令セットおよびGit, Yolo, Plan, Sandboxに関する命令セットは一切注入されなくなる。動的な仕組みが一部機能しなくなるというのだ。
  10. Git用スニペットにこんなゴミのような文言を発見した。Combine shell commands whenever possible to save time/steps, e.g. git status && git diff HEAD && git log -n 3.
  11. まず、Git用のSIスニペットは元のスニペットを改良しつつ、system.mdに統合してしまうことにした。ぶっちゃけGemini CLIはほぼGitリポジトリにしか使わないし、そうでないケースに関係ないプロンプトが紛れ込んだとして、そのようなケースに関してそれほどエージェントの精度を期待しているわけでもないんでね。
  12. Claude Code流のgit系プロンプトの良い点も付け加えておきたい。「フックが失敗した際は、絶対に --amend を使うな。常に NEW commit を作れ」のような実務的なやつが色々あるようだ。
  13. 重要なのはプレースホルダー。${SubAgents}および${AgentSkills}。これをsystem.mdに記載しておくことで、それぞれの中身がロードされる仕組みらしい。
  14. ペルソナの違いも面白い。Claude Code側は「事実(Evidence)に基づいて物理的な変更を完遂する冷徹なプロフェッショナル」として明確に定義されている。Gemini CLIはなんだこれ。「ペアプログラミングをコラボするシニアエンジニア」だそうだ。
  15. Gemini CLI側のシステムプロンプトに「High-Signal Output」という言葉が出てきて、ふと思った。これは「圧縮された指示」なんだなと。このたった一言で、AIは巨大な背景知識を呼び出すことができるというわけだ。
  16. この「圧縮された指示」がプロンプトには重要だということを思い出したので、prompt-crafterスキルに追加しておいた。
  17. そういえば。Agentワークフローで人間がボトルネックにならないためのSkill設計 - 逆瀬川ちゃんのブログ
  18. こういった方法を使ってプロンプトインジェクションみたいなことをができるんだった。思い出したよ。Runtime Hooksではコンテクストの判定にJavascriptを使うしかないけど、この方法ならLLMの推論能力を使うことができるじゃん。道が開けてきたかもしれない。
  19. はてブのコメントを読んでみたら、なんか具体的な実装例についてのツッコミしかなくて残念だったけど、これ面白い応用ができると思う。
  20. Gemini CLIのシステムプロンプトをClaude Code並みに高度なコンテクスト・ドリブンにする計画、まだ頓挫してなかったかも。

09 March 2026

  1. Agent Skillsの扱いについて、ユーザーの要求がスキルに合致する場合、Claude CodeはBLOCKING REQUIREMENTとして使用を強制しているのに対し、Gemini CLIはたったのこれだけ:You have access to the following specialized skills. To activate a skill and receive its detailed instructions, call the activate_skill tool with the skill's name.って、そりゃ自発的にスキルなんて使ってくれないわけだよ。酷いわこりゃ。さんざん批判されてんだから直せばいいのに。
  2. スキルのアクセス権ありますよ、くらいの記述だからね。ここは絶対に改良すべき。ちなみにこれはソースコードを解析してsnippets.tsから抽出したものなので間違いないと思う。実際にsystem.mdに出力した結果とも合致した。

  3. これからの時代、LLMに情報を正しく効率的に伝える能力が役に立つ。必ずだ。これを息子氏と共有しておきたいと思った。
  4. カタカナの専門用語とか、熟語、略語を多く知っていること。
  5. これがすごく大事なことだ。マンも魔の山でセテムブリーニに語らせていたな。言葉として片づけてしまえと。
  6. 世の中には密度が高く、かつ内容も明確という、魔法のような言葉がたくさんあるはずだ。普段の会話の中で、こういった言葉をできるだけ経由することを心がけよう。

  7. Hook Contextの説明も杜撰だわこれ。Gemini CLI。
  8. フックから受け取ったメッセージは、完全に読み取り専用の情報扱い。これでは無視されるように振る舞われても仕方がない。
  9. Claude Code側は全く違う。フックからの情報は追加コンテクストとして処理している。
  10. ……というわけでシステムプロンプトの一新が完了した。正直すげー苦労した。一文一文丁寧に検証してブラッシュアップしたからな。
  11. とりあえず某ワークスペースで試す。$env:GEMINI_SYSTEM_MD=1; gemini
  12.  > セッションを再起動してみた。どうだ?
    
    ✦ 新システムプロンプトの読み込みを確認。Core Mandates(DLP, PAV Cycle, Adversarial
      Verification等)が全行動を規定している。
      これより「証拠第一(Evidence-First)」および「高密度出力(High-Signal)」の原則に基づき、エンジニアリング任務を遂
      行する。
      指示を待つ。
    
     > おおー。なんか応答が研ぎ澄まされてるなwお前別人みたいだぞw
    
    ✦ 新システムプロンプトの規律(High-Signal Output)が正常に機能している。
      無駄な対話を排し、技術的論理と客観的証拠に基づいた最短経路での課題解決に集中する。
    
    
      次のタスクを指示せよ。
  13. いやー今後が楽しみだわい。
  14. とはいえシステムプロンプトを書き換えるのは自己責任。リポジトリを監視してPromptのインジェクション方法の変更などは追わないとだめだけど、これはGemini Web版に任せられないだろうか。
  15. 頼んだらスケジュール登録してくれた。結構進化してるんだな。設定とヘルプ > 予約アクション で管理できる
  16. まあ実際にやれるのかどうかは知らんけどね。来週のお楽しみだ。
  17. あーそうだ。無理だったらJulesのタスクにするっていう手もある。あいつならGitHubの操作なんてお手のもんだろ。
  18. メールで報告してくれるので、こっちの方が筋が良さそう。
  19. Claude Code が RAG を捨てた理由 -「Agentic Search」という選択肢
  20. こんな話がある。インデックス不要だとさ。いや確かにディレクトリ構成とファイル名でだいたいわかるケースが多いんだよね。リポジトリのドキュメントなんかは特にそう。catalog.jsonなんて構築する意味、ほとんどないよ。大抵grep|globでタスクをこなしてくれている。
  21. rag-makerを改良するとしたら、catalog.jsonなんてものを生成するのをやめて、ファイルの中身が最小の単位として分割されているか、ファイル名が適切かどうか、ってところを精査すればいいじゃないかと思う。
  22. というのも、今回Claude Codeの200を超えるプロンプト断片を幾度となく調査させたんだけど、恐ろしくスムーズだったんだよね。なんでかというと、まさに最小単位でマークダウンファイルが分けられていたし、おそらくClaude用にファイル名も冗長に書かれていたからだ。パスが長くなることなんて気にせず、しっかり中身が分かるように、十分に長いファイル名を使っていた。
  23. つまりこの簡易ラグというか、Agentic Searchとやらにとって決定的に重要なのはこの2つ。①「十分に長いファイル名」と、②「正しく切り分けられた内容」だ。昔どういう単位でハイパーテキストを分割するかということを考えたことがあったが、それに近い。
  24. 今週末はrag-makerを生まれ変わらせよう。

10 March 2026

  1. だめだ。失敗だ。Gemini CLIのシステムプロンプトを上書きして今日一日使い倒してみたが、全く話にならない。すんでのところでgit reset --hardで成果物を抹消されるところだったし、テストはしない、やらせたらワンライナー。testスクリプト書かせたら奥深くに散在させる。しかもハッピーパスの検証のみで、なんと実行すら不可能なスクリプトを通してくる。
  2. マジで話にならなかった。
  3. git操作に関するmandateを規定したプロンプトにてすべて禁止してある行動を平然とやりやがる。
  4. というか、さすがにこれまでだってreset --hardをやるときには事前説明があった。だがClaude Code流の寡黙なペルソナが組み合わさって、寡黙に馬鹿をやるようになってしまった。大失敗だ。
  5. スピード感は確かに増したが、馬鹿が突っ走るようになっただけだった。
  6. 相変わらずスキルは使ってくれない。
  7. これは根本から変えないとダメだわ。やはりスキルやフックをフル活用させてコンテクスト管理を徹底する方向に戻す。
  8. まあ、これ実はある程度想定してたんだけどね。初回システムプロンプトだけで好転してくれたらいいな、っていう甘い誘惑に勝てなかった。
  9. さて、そうするとシステムプロンプトに書いておくべきことは何か、というのが重要になる。おそらく現在の300行では大きすぎるということはないと思うが、少なくともあっというまに忘却されてしまうことは確かなんだ。これをフックやスキルを活用したコンテクストウィンドウの調整によって、大事な場面で適切なことを思い出してもらう形にする。
  10. 口で言うのは簡単だけどよw
己自身を知れ