Home → 2026 summer, since 2009-12-01

2026 夏

01 June 2026

  1. Prev:
  2. 日記がなかなか開かないなと思ったら、空っぽのsummer.mdが既に開いていた。そうだった今日から夏か。
  3. 今週はやることが多くてめまいがしてくるが、とりあえずweztermの操作方法を習得するというか習得させるというか。wezterm/weztermを走査させてRAG用のナレッジベースを構築。gh-maestroプロジェクトでエージェントが参照できるようにした。wmuxに関するリソースはすべて削除。
  4. Ctrl+Alt+%でペインを左右に分割。Ctrl+Alt+"で上下に分割。%が左右に分割する記号に見えない。逆に上下に分割するような感じがするな。分数なんだから。ダブルクォーテーションなんかまさに、上下と言うより左右の分割を連想させる。tmux由来らしいがなんでこうなった。
  5. Claude Codeはリファクタリングの結果報告を人間が知りたいと思うポイントに絞って表で整形してくれて……。寄り添い能力が高い。もうこいつとしか対話したくねえわ。
  6. Geminiモデルの推論能力は本当にひどすぎる。よく今まで我慢して使っていたよなあ。
  8. Weztermのペイン操作はCtrl+Alt+"で上下分割、Ctrl+Alt+%で左右分割。ペインを閉じるのをCtrl+Space後c、ペイン入れ替えをCtrl+Space後rとし、luaスクリプト（~/.wezterm.lua）をClaudeに書かせた。とりあえずこの4つがあれば、GUIのように直感的ではないものの、一通りのペイン操作ができると思う。
  9. Ctrl+SpaceをLEADERに設定したので、今後なにか追加するときはこれを使うことにする。
  11. やばっ！めちゃくちゃいいこと考えた。オーケストレーターにWeztermの完全な操作スキルを与えてやって、こいつがペインを作ったときに任意のスキルを発動するように要請すれば、役職を固定せずに済む。オーケストレーターの「知能」さえ高ければ、こいつの判断で自由自在に役職を作ることができるじゃねえか！
  12. 一応役職の定義とかルールはスキルとして作っておかないといけないけど、現在のsetup.jsで決まった役職を決まったペインに登場させるっていう方法だと、LLMの汎用性を活かしきれない。様々な問題に柔軟に対応できないもん。
  13. Weztermこそ神アプリだな。これ、うまく行ったらお布施しよ。
  15. 久しぶりに「ウイルスに感染してしまいました」きた。サポセン業務や。
  16. JSのサイレントなポップアップ連続攻撃か何かでキーボード操作が完全に不能になってる。めんどくせえので電源落として再起動。
  17. 履歴見たら「折り紙」なんちゃらサイトにしかアクセスしてないので原因特定楽勝。Bing検索でたどり着いたらしいので同じ手順を踏んでみると、最上位で広告サイトではなかったのでそのまま開いた。悪質な広告が画面の半分くらいを占めていた。
  18. 念の為Edgeの起動設定やら通知設定やら拡張機能やらがクリーンであることを確認し、粛々とuBlokorigin Liteを導入。
  19. あーはようAD導入したい。総務トップには相談済み。
  21. gh-maestro試作品完成。Claude Codeと仕上げた。必要なことしか喋らないから捗る捗る。早速明日使ってみよう。
  22. と思ったけど、コーダーをフロントエンドとバックエンドで分けたいんだよな。Issueを分割することなく仕事を分割できる。
  23. そうなるとワーカーからオーケストレーターへのメッセージが競合する可能性が出てきて面倒くさい。うーん、完了報告はファイルI/Oを使ったほうが良かったかもしれないが、とにかく明日はかんたんなIssueで試してみることとする。

02 June 2026

  1. 今日から自作のA2Aつうしんしすてむ、gh-maestroで開発開始〜
  2. Claude Codeはオーケストレーターとしての役割をちゃんと理解しツールを正しく使ってくれる。Weztermの右ペインにコーダーを召喚し、指示を投げてくれた。
  3. コーダーとして召喚されたAntigravity CLIは、早速Askツールを使って禁則事項である「人間へのメッセージ」をやらかした。オーケストレーターと連絡とれと指示しても理解できず、黙々とコードの調査を開始したので、オーケストレーターとの通信手段を知らないのか？と問いただすと、無言で通信手段を「調査」し、通信を始めた。
  4. やっぱりGeminiモデルは糞なんかな。とにかくツールの使い方が下手だ。Askツールの使用を禁止することが必要なのかもしれないね。
  5. なぜ命令違反をするのかを聞いてみたところ、「看過」したとかわけのわからん意味のない回答しか得られない。本当どうしようもねえわ。システムプロンプトに完全に拘束されてしまっていて、汎用性のかけらもない。まあ、だからGemini CLIはハーネスをガッチガチに組んで使ってたわけだがｗ
  6. コーダーがGitHubにPR提出するような形になったわけだが、ここでも（頼んでもいない）Gemini Code Assistがトンチンカンなレビューを出してくる。実在しないパスにtoLowerCase使えっていうんだよ。Claudeに「いちゃもんだから無視しようぜ」っていったら同意してた。なにこれ。
  7. まあ毎回トンチンカンってわけでもないし数撃ちゃ当たるレビューとしてこのままにしておく。
  8. というか、そのトンチンカンなレビューへの反論を設計判断として記録に残しておくっていうClaudeの案を採用した。いいねそれ。
  9. ClaudeがAntigravityをレビュワーとして召喚した。こいつも同じく、オーケストレーターとの通信なんてすっかり忘れて、普通に報告してきて終わり。
  10. gh-maestroが抱えている課題の90%はGemini由来のものです。
  11. まあまあ、初期プロンプトでなんとかなるかどうか、これから少しずつ改良していくとしようか。
  12. ただ、Gemini 3.5 Flashは（Mediumでも）仕事が速い。小さなペインだったから完了報告しか見えず、テストとリントとビルドを終え、レビューが完了しましたっていう文字だけ見えて、まさかこいつ完了幻覚か？と思ってしまったくらい速かった。スピードだけは評価できる。あとQuota消費量も安心できるレベル。
  13. Flash Light系でよくある「完了幻覚」。あれはもう完全にアウトだね。エージェントとしての最低品質を満たしてない。よくあんなモデルを公開しようと思ったよGoogleは。
  14. gh-maestro-baseスキルを手直しついでに、gh-maestro-orchestratorスキルも修正。アホの子Geminiへの指示をコンパクト化する際に気づいたが、オーケストレーターもワーカーも、Weztermについて何も知る必要はない。全部アセットスクリプト内に抽象化してやった。これで必要コンテクストはよりコンパクトになり、Weztermを別のターミナルに変更しやすくもなる（今のところほとんど不満はない）。
  15. 開発体験は爆上がりだ。これなら個人的にも年額10万くらいなら払う価値ありだね。AnthropicとGoogleにお布施だ。Geminiは会話するに足る汎用エージェントとしては微妙だが、NotebookLMやNano bananaだのJulesだのいろいろあるし、Chromeに統合されて便利だから外せない。
  16. さて。gh-maestroはAntigravityのドキュメント嘘をついていたのでスキルの登録をやり直す羽目になった。agyで/skillsを叩いてやっと正しいskillのディレクトリが判明した。どうやら二転三転した経緯があるみたい。IDEはもう使わないからどうでもいいが、IDE版とCLI版ではまた違ったりするっぽい。
  17. コーダー役のSKILL.mdを修正してみたが、やはりGemini 3.5 Flashはオーケストレーターへの報告義務を守らない。当初規約として書いていたが守られないので、ゴールに含めた。報告がゴールという形にしたが、だめだった。だが、そもそもスキルを発動していなかったのであれば、SKILL.mdを読んでいなかったはず。……規約に戻してもう一度試してみよう。
  18. 外れ。やっぱり途中質問をチャットに投げてきやがった。今度は「あなたはバックグラウンドで自律起動されている。このチャットを見ている人間はいない。外部に伝えたいことがあればsend-pane.js以外に手段はない」と書いてみた。100%Claude案。どうなるか。
  19. これはさすがにうまく行った。……と思ったら安定しない。
  20. 閃いた。名乗らせよう。初期プロンプトに「オーケストレーターです。〜してください。」と名乗ってから命令することで、いまオーケスとレーターからの命令なんだということが分かる。そうすれば、実装前になにか疑問点があったとき、質問先は自然とオーケスとレーターに向かうはずだ。単に「〜してください。」だとユーザーからの命令だと解釈するのが自然だ。なぜ気づかなかったんだろう。
  21. この「名乗り」はsend_pane.js（ペイン間の送信用スクリプト）、spawn_worker.js（ペインを初期化してワーカーを召喚するスクリプト）で自動的にメッセージに付加しまうことでSKILL.mdが簡略化できる。今度こそうまく行くと思うがどうだ！？というか、これでまだわからなかったら相当がっかりすると思う。Gemini 3.5 Flashには失望するだろう。
  23. git worktreeというのを使っているので、テストに必要な環境を毎回セットアップしなければならない。これはなんとかしたいところだ。
  24. ワーカー用のスキルに、worktree内をチェックして、必要ならnode_modulesのシンボリックリンクを作成するように指示を足した。
  25. レビュワーが役に立ってない。単に実行済みのテストを繰り返して、「はいマージ可能です」。意味ねえ。レビュワーにどういう観点でレビューさせるかというのはオーケスとレーターに判断させることにした。タスクによってレビュー観点って変わるから。
  27. Linux環境との差異の部分はインストーラーで全て解決。

03 June 2026

  1. 呆れたことに、メッセージ冒頭に「orchestratorです。」とClaudeが名乗っても、Antigravity（Gemini 3.5 Flash）は質問をチャットに投げてよこした。このモデルには失望した。
  2. こうなったら最後の手段。メッセージ末尾に「質問、報告はorchestratorにお願いします」。
  3. ……これでようやくagyは、最初からオーケストレーターと直接対話をしてくれるようになった。
  4. 総括すると、一言で片付けられる。「こいつSKILL.md遵守しねえ」。
  5. SKILL.mdの禁則事項に書いてもだめ。ゴールに書いてもだめ。フローに書いてもだめ。じゃあSKILL.mdってなに？って話。システムプロンプトの拘束が強すぎる部分に抵触してしまうと、全く汎用性を発揮できない。いまAGIに最も遠い位置にいるのがGoogleのエージェントプロダクトだ。
  6. 結局、ワーカー召喚スクリプトが初期プロンプト末尾に「この件に関する質問・報告はorchestratorまでお願いします。「〜を実装します」「着手しました」などの着手報告も不要です」という一文を付け加える形になった。着手報告されてしまうと会話が成立しないからな。懐かしのトランシーバーと同じ原理だ。
  7. これも今のところはうまく行っているが、守られない事態も起こりうるだろう。だったらオーケストレーターの挙動を堅牢にしておくことも並行してやっておきたい。つまり、着手報告を受けた場合、それに対して返答を返す前に相手のpaneの内容を確認するのだ。
  8. Claude Codeはオーケストレーターとして本当に頼りになる。GCAからの自動レビューをトリアージして適切にコーダーに仕事を振ってくれる。これが求めていた体験だよ。
  9. 使用言語を入れ替える大規模リファクタリングでPR5個処理して、現在GeminiモデルのQuota残量20%表示。1時間後にQuotaリセット。使用モデルはGemini 3.5 FlashのMediumとLow半々くらい。レビューからの差し戻しが結構あったから、PRの数だけでは判断できないけど。
  10. Quota経済のため、コンテクスト管理をカツカツにやろう。モデルの出力精度にも影響するからこれ大事。
  11. 6個目のissueでコーダーであるAntigravity GeminiモデルのQuotaが尽きた。緊急でClaude Sonnetに切り替えたらコンテクストが喪失した。そこでオーケストレーターにそのことを伝えて経緯を説明させたら、無事復帰。いい体験だわこれ。
  12. Claude Codeの方は今回のshiftmaeker リファクタリングのオーケストレーターおよび、gh-maestro開発全般を担当させたが、Quotaに関しては全く問題ない。5時間枠は69%消費で23分後にリセット。週枠は26%4日後にリセットだ。週枠の方は、噂によるとAnthropicによるリセットがあったかもしれんのでまだ油断はできないけど、5時間枠は恐らく問題なしだ。
  13. Claude Code IDEの方で気になるのが、Shellコマンドを打ったらそれを読んで反応してくるところだ。トークンがもったいないと思ってしまったが、状況を伝える必要がないので楽といえば楽だ。
  14. あとはJules V2 (Jitro?) がどうなるかだな。今のJulesは全く使い物にならないので対応する気はないが、V2の出来によってはREST API経由のV2との通信手段をgh-maestroに組み込まなければならない。得意分野を見極めたら、オーケストレーターの定義を更新して、Jitro or Antigravity を自律的に選択させたい。これでQuota経済がさらに改善されるはず。
  15. でもJitroのコンセプトは完全自動化らしいので、REST APIは提供されないかもしれない。あと、REST APIを使う場合はポーリングが必須になる。全く異なる通信手段が混在するのはあまり面白くない。
  17. リファクタリング終了。陳腐化した数々の文書やGemini CLI用のハーネスたちを整理し、.claude/rules として移植しようと考えた。Claude Codeは当然.claude/rulesについての知識を持っていないようで、なにか調べ始めたのでキャンセルしたら、おいおい、claude-code-guideなるスキルを使って公式ドキュメントを調査してるじゃん。そのスキルがあるなら早く教えてくれｗ ナレッジベースをローカルに用意しちゃったよ。
  18. とおもったら、まだESLintを定義してなかったじゃん。でも手順としては悪くない。ここでLint対応Issueを発行して一気にやらせてしまおう。
  19. "判断を仰ぎたい点が一つあります。magic number禁止を見送る判断をしました。ソルバーのコスト計算にまで適用すると、かえって可読性が下がると判断しています。"
  20. いやーよくそれを俺に報告してくれたよ。その判断に敬服するね。「可読性というのはLLMにとっての可読性？もし人間のみにとって有用な可読性の話をしているのであれば、それは不要だ」と返した。
  21. "完全に同意します。「なぜこの数か」を名前に込める規律は、LLMが文脈を誤解するリスクを下げます"
  22. まさにそのとおり。名付けに関しては冗長性が大事なのだ。
  23. auto fix後で1,100件のリントエラー。agyのQuotaが足りるかどうか見もの。
  24. とおもったけどコンテクストウィンドウが圧迫されて精度が下がりかねないので、オーケストレーターに「分業させようぜ」と伝えたらワーカーを3つ作ってうまく作業を振ってくれた。そこを自律的にやってくれるといいんだけど、実際のところは手間取っていた最初のワーカーの作業状況を俺が目視して、オーケストレーターに報告させて、オーケストレーターが修正に優先順位を付けてそのままワーカーに返したので、「分業させようぜ」と伝えた。つまり複数ヶ所に人間の介在を要している。
  25. うっかり、AntigravityのモデルをClaude Sonnet 4.6のまま変更するのを忘れていた。あっという間に枯渇してしまったわ。17分で復活と表示されているけど、途中で止まられるのは困るからできるだけ使いたくないなこれは。
  26. いやまて並列実行させるユースケースは考えてなかった。これをやり始めると仕事の質より量を重視するようになってくる。それはいかん。直列実行で質を一つ一つ確認しながらやるのが俺のやり方だ。Lintエラーの修正だってどんな修正したのかをちゃんと追っていきたい。まあ今回は面白いからこのまま続けさせるけどｗ
  27. 結果。3人中2人がオーケストレーターへの報告を忘れてる。Gemini 3.5 Flash (Low)に変えたからな。これはひどい。さらにそのうちの1人は、報告方法を知らない。スキル文書を読み返して学習し直していた。やっぱりLowは厳しいか。
  28. Lintをパスしたらオーケストレーターがマージお願いしますと行ってきたので、ESLint抑制コメントに逃げていないか、.agents/rules/* に準拠しているかどうかをレビュワーに調査させようとアドバイスした。
  29. 60個ものESLint抑制コメントで逃げててワロタ。
  30. オーケストレーターがうまく捌いてくれた。分業についてはやるかやらないかを俺が指示する形にしよう。何人に何をどう振るかは、その都度任せる。
  31. あと、Git Worktreeを活用する場合、Antigravityが毎回ディレクトリを信頼するかどうか起動時に聞いてくるのがうざい。これは放置しておいてもセッションはどんどん進んでいて、Yesを選択したらもう終わっていたなんてこともある。
  32. 並列は楽しいな。癖になりそうだ。驚くべきことに、今回は3名全員が正しくオーケストレーターに報告できた。えらいえらい。ターンが進みすぎると忘れてしまうのかな。
  33. マージコンフリクトがたくさんあったけど、そこは仕事を振ったオーケストレーターの責任だ。でも黙って粛々ととコンフリクトを解消してくれ……なかったｗ コンフリクトが大量にありすぎて、仕事を振ることにしたらしい。もちろんそれが正しいやり方だけど、そもそも仕事の振り方を考えて欲しい。これはgh-maestroの最優先課題だな。
  34. だいぶ良くなってきた。
  35. 段階的に修正する必要のあるfix issueがある。ステップを4つに分けてもらい、それぞれにissueを作ることにした。ステップ1をコーダーに実装してもらっている間に、ステップ2についてオーケストレーターと議論。議論途中でコーダーから完了通知が来たので、マージ。みたいに流れるように作業がスムーズに進んでいく。いい体験になってきた。
  36. だがちょっとイレギュラーが生じると大変だな。エージェントは自力解決しようとして、せっかく隠蔽してあるのにWeztermの内部動作を調査して「知って」しまい、直接操作しようとしてワークツリー構造と定義の同期を壊してしまう。スキルのアセットスクリプトはフォールバックを手厚くしてできるだけ失敗しないようにして、やむを得ない場合もエラーメッセージで正しい後処理に誘導しなきゃならん。これはもう地道に改良を重ねていくしかない。
  37. おいおいSonnet君やってくれたね。try-catchでエラーを握りつぶした挙句嘘のエラーメッセージを履くコードを平然と書いてたわ。こいつ侮れねえな。gh-maestroは日曜大工的なプロジェクトにするつもりだったけど、きちんとした開発フローを組んでやらんとこの先面倒かもしれん。
  38. 嘘のエラーコードよりたちの悪いものはこの世に存在しない。
  39. Opus 4.8はQuota消費量2倍以上だってよ。使いこなせないこともなさそうだが、ギリギリだ。精神衛生上よろしくない。使うとしても、もうちょっとコンテクストマネジメントが上手になってからだな。

04 June 2026

  1. gh-maestroでbat（sharkdp/bat）を活用しよう。VSCodeみたいな重たい超高機能エディタでファイルを読むのをやめ、TUIでさっと読めるようにする。Weztermと組み合わせればチャットが流れてしまうこともなくなるだろう。まさにClaude Code IDEがやっているようなことをスマートにやれる。
  2. gh-maestro-orchestrator スキルのアセットスクリプトにWeztermのpane関連の操作をカプセル化してしまう。オーケストレーターはただ、ユーザーに読ませたいファイルのパスをこのスクリプトに渡すということだけを知っていればいい。
  3. このアイデア、初めてClaude Codeに設計として褒められた。開発体験は間違いなく向上するだろうけど、モニタの領域がちょっと足りないかも。
  4. choco install bat が推奨されるインストール方法。依存関係を解決してくれた。
  5. とにかく、汎用性が命だ。AIの協働を自動化する人は跡を絶たないが、どうも汎用性に欠けるように見える。枠組みをかっちりと作りすぎてしまうために、せっかくのLLMをその枠に閉じ込めてしまうんだ。オーケストレーターはワーカーを自由に作って自由に呼べる。それがどういうふうに表示されるかを知る必要はないわけだ。
  6. そう考えると現実社会ってまだまだ洗練されてないよな。作業員がどう動けば効率的に仕事を進められるか、それだけに特化して考える役職なんてないもん。いろいろなことを知っていないといけない。
  8. Antigravity, そもそもロードしたSKILL.mdをconstructionではなく単なるreferenceとしてしか見ていない説。

05 June 2026

  1. gh-maestroのオーケストレーター、ワーカーの使い方がこなれてきたので、並列でバンバン使うようになってきた。
  2. 大規模リファクタリングだから仕方ないけど、4時間でAntigravityのQuota（Geminiモデル）が枯渇した。Gemini 3.5 Flash (Medium)のみ使用。
  3. 大規模なバグ修正に1日中使ってたらAntigravityのすべてのモデルのQuotaが枯渇。

08 June 2026

  1. 先週はClaude Codeを指揮者とし、Antigravityをそのワーカーとして使い倒してみたわけだが、週間Quotaらしきものの限界が見えた。48時間くらい使えなくなるとのことなので、水曜からの5日間で使い切ったことになる。しかも土日合わせて平日の半分くらいしか使っていないことを考えると、実質3日分の稼働で限界を迎えることになるわけだ。1日に5時間枠を1.5回分くらい使うとして、まあ週枠は5時間枠の4〜5倍くらいとみた。
  2. Redditでは96時間くらい停止を食らった人もいるみたいだが、5時間枠を4、5回使うだけで到達してしまうんだとしたら、十分あり得る話だ。
  3. Quotaを3倍だか9倍だかしてこれってことは、相当酷かったんだろうね。よくユーザー残ってたねこれ。
  4. gh-maestroはエージェント起動時のトークンのオーバーヘッドが大きいかもしれない。
  5. なんてことを書きながら、ちょっと思いついた。
  6. コンテクストウィンドウの観点から、issue一つにつきワーカーを入れ替えていたけど、これをやめて、coder, reviewer, investigatorを最初からもう起動してしまっておいて、それぞれがIssueごとにサブエージェントを起動して作業させるというのはどうだろうか。
  7. この場合並列実行ができなくなるのがつまらないけど。
  8. トークン管理の観点からは悪くないが、コンテクスト管理の観点からは悪手だ。せっかく与えたorchestratorの権限を奪うことにもなる。間違いなく質は落ちる。ーーやめた。
  9. AntigravityをやめてCodexにしてみたい気もするが、Google AI Proを辞めることはできない。これ以上の出費がかさむのは気に入らない。
  10. 一番いいのは、AntigravityのQuotaが尽きたら自分でコード書くことだわ。Claude Codeに調査してもらいながら。
  11. これで行こう。
  13. gh-maestro-reviewerスキルは、ちょっとぬるい。googleのレビュー基準のぶん書を読ませたりしてるんだけど、ぬるい。Gemini Code Assistの自動レビューはいつも危険度の高いバグやセキュリティホールを発見してくれるので、7月にこいつが使えなくなったら不安で仕方がない。
  14. で、珍しくChatGPTに相談してみたところ、PRを壊す方法を考えさせる「壊し屋」と、それを反証する「反証屋」を作れとのこと。これは確かに効きそうだ。以前必ずなにか一つ指摘しろ、というプロンプトを使っていたことがあったが、このときはいちゃもんばかりだったものの、たまにいいことを言ってくれたからな。
  15. 更に壊し屋を「セキュリティ担当」「正確性担当」「保守性担当」に分けろと。まあそうなってくるとreviewerが並列してサブエージェントを実行してくれない限り厳しいものがありそうだ。サブエージェントの並列実行、Gemini CLIにはできなかったんだよね。
  16. Claude Codeの場合、バックグラウンドサブエージェントは既存の機能。
  17. Antigravityは、なんと驚くべきことに、さらに自由にサブエージェントを使いこなせるらしい。invoke_subagentで並列実行が可能で、エージェント間通信にも標準対応。さらに10階層まで再帰的にサブエージェントを呼ぶことができるとのこと。ほんとかよ。
  18. まあ明後日に確かめるかな

09 June 2026

  1. どうやらAntigravityがサブエージェントに「特化」したプロダクトであることは疑いようがない。
  2. ならば、gh-maestroのあり方をこいつに寄せていくのもあり。
  3. そもそも、オーケストレーターがレビュワーを使役する意味があまりないことに、実際やってみて気づいた。
  4. コーダーは一定品質のコードをPRするのが責務だ。
  5. だとすれば、コーダーは状況に応じて複数のレビュワーをサブエージェントとして召喚し、自己のサイクルの中でコードの品質を保つべきなのではないか。
  6. 一方現状は、コーダーが（計画書やrules等のハーネス、CIによる型チェック等があるとはいえ）自己満足レベルで作成したコードをそのままPRする。それをオーケストレーターが一度読んで確認したのち、レビュワーが召喚され、さらにGCAのレビューに晒される。その結果、オーケストレーターを介した手戻りが多く発生する。
  7. Redditの「なんでまだAntigravity使ってるの？」的なよくあるスレが何故かスマホの通知に飛んできたので読んでみたら、PRでGemini in Chromeを起動してProにレビューさせるテクが紹介されてた。なるほどこれも使えるわ。ただしWindows限定か。
  9. APIキーの無料枠を試してみようと思ったら、いつの間にかクレカ情報の登録が必須になっていた。しかも、おそらくBillingの実績がないとだめ。仕方ないので2,000JPYを前払いした。18日以降にGemini CLIをちょっと使うことはあるだろうし、無駄にはならんだろ。
  11. 今日はAntigravity CLIが使えなかったので、ちょっとしたfixをClaude Codeにやらせた。迅速で手戻りも少なく、下手にagyを関わらせるよりあらゆる意味で良い結果になったと思う。Quotaの減りすら大したことなかった。機能追加はissue書かせてPRの工程を挟んでみたけど、GCAからのレビューとGemini in Chromeに書かせたレビューを俺がコピペしたりして、手戻り１発で完了。
  12. 色々考えさせられるなこれは。

10 June 2026

  1. で色々考えた結果、実装難易度に応じて柔軟にワーカーを使い分けるフローをオーケストレーターに定義することにした。
  2. 昨日、"オーケストレーターがレビュワーを使役する意味があまりない"と書いたが、自分がコーダーを兼ねる場合はその限りではない。このときはAntigravityをレビュワーとして召喚し、そいつは「複数の専門的なサブエージェント」を使って多角的かつ批判的レビューを行う。レビュワーはその結果を「専門的なサブエージェント」を使って取捨選択し、オーケストレーターに報告する。オーケストレーターはその結果を読んで実装を完了させたうえでベースブランチにマージ。
  3. 一方コーディングを外部委託する場合はAntigravityをコーダーとして召喚する。この場合コーダーがサブエージェントを駆使して同様のレビュー工程を経た一定品質のPRを出す。
  4. あと、「PR完了」みたいな「報告会」はトークンの無駄なので辞めることにした。なんかClaude CodeもAntigravityも、ポーリング用のツールを持っているみたいなので、普通にPRをポーリングして待機、的な指示を入れておけばやってくれる。
  5. send-pane.jsを使うのはワーカーがオーケストレーターに質問するときと、オーケストレーターがそれに答えるときだけになりそう。つまりイレギュラーが生じたときだけ。できるだけ発生させないようにする方向にシフトする。まあやり取りを見ていると面白いんだけどね。
  7. PWAの価値が激減。「Geminiに相談」が使えない。Alt+Gで一応チャットの小窓は開くけれども、タブの内容を取得するらしく、タブのないPWAは対象外。EdgeとCopilotも同様の問題を抱えている。
  8. Gemini in Chromeに聞いてみたところ、chrome://appsでPWAを右クリックし「ウィンドウで開く」のチェックを外せばPWAをタブで表示できるとのこと。
  9. はい。これでもう、完全に100%、Microsoft Edgeを使う理由が消えました。正直言ってCopilot in Edgeは要約に使うだけでも苦労するレベルで、調査発展させる用途には不向きだった。モデルも何使ってんだかわからないが、GPTの低グレードモデルだろ多分。今日日モデルすら不明なエージェントなんてなしでしょ。エージェントと言うかただのチャットだし。
  10. Linuxを使わない理由にもなるんだよねこれ。一体いつ対応してくれるんだろうか。Linux版のChrome。
  11. PWAをすべてEdgeからChromeに乗り換えた。タブ表示。スタートメニューにも登録しづらくなってタスクバーにピン止めできるわけでもなく、普通にインターネットショートカットを作るのと大差はない。PWA is dead.
  13. 6/22まで、Claude ProプランでFable 5モデルが使えるらしい。Opusの2倍のQuotaで済むらしいので、何か試してみたい。なんに使おうかな。
  14. CLIを起動したら、2.1.170にアップグレードすればFableが使えると表示された。
  15. 現在2.1.169なんだが。パッチレベルなのかよｗ
  16. 週のQuotaがリセットされてた。Fable 5を試してみてくれと言わんばかりだな。
  17. 試してみるとしたら、既存のAIアプリ用の堅牢なデザインパターンを確立するための調査とリファクタリング計画書の作成、かな。
  18. それとも企画中の複雑なソルバーアプリケーションのスタートアップを担当してもらおうかな。
  19. Fable 5は100万トークンあたり、入力10ドル、出力50ドル。ただし学習データを的確に使って推論してくれるなら余計なコンテクストマネジメントが不要になるので、トークン自体は大幅に節約できるはずだ。

11 June 2026

  1. agyのsubagentについてドキュメントを調べたところ、静的に定義する方法はない。なんだこれは。エージェントが動的に生成する方法しか書かれていない。
  2. まあそれならそれで、エージェントの定義を書いておいてそれを読み込ませて作らせるよう、SKILL.mdに記載しておけば良い
  3. さて、実際にレビュワーの定義をGPT系と議論してみたところ、きちんとやろうとすると結構な量のプロンプトになることがわかった。これを動的に使うっていうのはQuota経済にとって厳しい。
  4. そこで方針を大転換、というか振り出しに戻す。やはりレビュワーは一人のワーカーとして独立して動いてもらうこととする。
  5. ここで気づいたのが/forkコマンドの活用だ。これはかなり効果が期待できる！
  6. まずレビュワーとしての基本的な動作を定義したプロンプトをコンテクストに取り込んだ状態で/fork（分岐1）し、そこからCorrectness系、Resilience系、Maintainability系のレビュワー用のそれぞれのプロンプトをコンテクストに取り込み、さらに/fork（分岐2）。ここでそれぞれのセッションに/renameで名前をつけてやる。review-correctness, review-resilience, review-maintainability とかね。
  7. 実際にレビューするときは/resume セッション名 で起動し、さらに/forkしてからレビューの具体的なコンテクストを追加し、開始させる。
  8. 書いてみるとややこしく見えるが、図示すれば全然大したことをやっていないことがわかる。
  9. この方法なら、毎回レビュワーをspawnしても長大なレビュー用基礎知識を読み込ませる必要がない。
  10. weztermを使って物理的な指示出しを行えるので相性もいい。スラッシュコマンドだろうが何だろうが、オーケストレーターは人間が行うのと同じ指示を出せる。
  11. agy --conversation {セッションID} でそこから再開できるんだけど、名前は指定できなかった。セッションIDは端末依存なのでNGかな。
  12. となると物理的に/resume {セッション名} を送信したのち、プロンプトを投げる形だな。
  13. いずれにしろこれで、トークンを気にせずに詳細なコンテクストを抱えた大量のレビュワーをspawnできる。
  14. ……と思ったけどこれ、セッションを作るのに手作業が必要だった。初回だけとはいえこれは痛い。しかもこれってプロジェクト毎だわ。あかん。ダメ押し。/resume に引数はなく、手動で選択していく方式だった。最悪や。
  15. いや、もうここは手動でもなんでもやるしかない気がしてきた。プロダクトの質に直結する部分だからな。
  16. 俺がやること。オーケストレーターに実装を開始させたら、レビュー用の3つのエージェントを独自に立ち上げ、PR#を伝え、検知をポーリングさせておく。あとはそれぞれが勝手にレビューを開始してPRにコメントをつけてくれるので、それぞれについてトリアージというか、妥当性を検証する。これは一番難しく総合的なコンテクストと推論が必要なので、全体を把握するオーケストレーターに行わせる。オーケストレーターにはPRコメントの取得をポーリングさせておき、過剰なエッジケースが想定されていないかとか、そういう観点でレビューを評価させ、選択させる。あとは同じくコーダーに修正を依頼していくフローだ。
  17. それとも、OSSのエージェントアプリを使って、必要に応じてCLIツールを自作する手もある。APIキーは安価なDeepSeek v4を使う、とか。
  18. PowershellのSecretManagementとSecretStoreを使い、Set-Secret -Name "DeepSeekAPIKey"でAPIキーを保存してみた。試しに使うため10ドルちょいをプリペイド。deepseek API keys
  19. Julesを使うっていう手もあることを思い出してみた。これなら並列でいくらでも動かせるもんな。1日で100タスクまで可能だった記憶がある。でもトロ臭いので強烈なボトルネックになりそう。
  20. とりあえずClaude Codeでdeepseek-v4-proを動かしてみた。どれくらいこき使うと10ドルが溶けるのか見もの。claude-dsで起動するスクリプトの設置完了。環境変数に毎回APIキーを指定する感じで起動すればいい。毎回パスワードを求められるけど、APIキーに意識が向くので当面このままでいい。
  21. ` $env:ANTHROPIC-BASE_URL = "https://api.deepseek.com/anthropic" $env:ANTHROPIC_AUTH_TOKEN = $apiKey $env:ANTHROPIC_MODEL = "deepseek-v4-pro[1m]" $env:ANTHROPIC_DEFAULT_OPUS_MODEL = "deepseek-v4-pro[1m]" $env:ANTHROPIC_DEFAULT_SONNET_MODEL = "deepseek-v4-pro[1m]" $env:ANTHROPIC_DEFAULT_HAIKU_MODEL = "deepseek-v4-flash" $env:CLAUDE_CODE_SUBAGENT_MODEL = "deepseek-v4-flash" $env:CLAUDE_CODE_EFFORT_LEVEL = "max" claude @args `
  22. 環境変数名についてはClaude CodeのRAGに聞いた。
  23. deepseek-v4-proは4月に出たばかりの最新モデル。噂通り、速くて賢そうに見える。
  24. gh-maestroのアーキテクチャを喋らせ、CLAUDE.mdに設計思想を追記させたら、コミット、プッシュしますか？と聞いてきてくれた。作業後は、その効果を完結に説明してきた。寄り添い能力ありかなこれ。少なくともGeminiよりは数段上です。ここまでやらせて、0.04USD。6円。deepseek-v4-flashなら3分の1なので、2円。いうほど安いかこれ？
  25. おっと。思考深度がmaxだったからかな。行ごと消してデフォルトに任せたほうがいいってこれ。
  26. gh-maestroの軽めの変更を実装させてみた。レビュワーを消去してPRをポーリングで待機、PRコメントをマージ完了まで待機し続け、コメントが来たらトリアージしてコーダーに改善を指示する。それだけだが、33分かかった。0.12USD消費。
  28. weztermの挙動メモ。~/.config/wezterm/wezterm.lua を最初に読みに行く。リンクを更新するには再起動。

12 June 2026

  1. deepseekの昨日の利用。cache/cache miss/output = 17,785,088/670,296/146,954 token。費用は、0.50USD。
  2. 今日から早速レビュワーとして活躍してもらうことにする。最初はdeepseek-v4-flashで試す。
  3. まずワークスペースでターミナル起動。ペインを3つ作成。claude-dsを起動。正確性、堅牢性、拡張性をそれぞれ担当させるためのスキルを発動させた時点でそれぞれに名前を付け、それぞれ/forkし、issue番号を伝える。これでPRをポーリングで待機してレビューを勝手にコメントする。
  4. 付けた名前で/resumeすれば、必要最小限のコンテクストで別PRのレビューを開始できる。
  5. 最初は手動でやって、確定したら自動化できる部分のスクリプトを書く。名付けと/forkは手動でやるしかないけど、プロジェクトごとに1回きりだとは思う。いや/forkは毎回か。
  6. /forkじゃなくて/branchを使ったほうがいいみたい。
  7. 2つ3つissueを処理させてみたが、どうやらコストは1回0.20〜0.30 USDくらい。deepseek-v4-pro[1m]しか試せてない。起動スクリプトで環境変数の設定を変えたつもりだったんだけど、ターミナルの再起動を忘れてた。
  9. ChatGPT in browser でHTMLアプリケーションを作って（動かず）相談してくれた人がいて、聞くとOpenAIに課金しているとのことだったので即座にCodexを勧めてみた。夢が広がったと言ってくれた。別世界だぞ。
  10. もっと色々親身になってあげたかったんだけど、こういう日に限って頭痛なんだよ。昨日Black & Whiteを飲みすぎた。このスコッチ値段の割に美味すぎだろ。この価格帯では群を抜いてる。二日酔いの頭痛をこじらせたの初めてかも。原理は肩こりと似たようなもんなのか。
  11. さてそのHTMLアプリケーションだが、数人で報告を投稿、共有する簡単な内容だったが、JSONをデータストレージにしてHTMLにバニラJSを埋め込み、ページ遷移から何からすべてを実現していた。どーやってローカルのJSONを更新してるのかGemini CLIに聞いたら、なにやらファイルリネームを使っているとかなんとか。よくわからんかった。そんなことできるんだろうか。ローカル環境でHTMLアプリを作ったことがない、わけではないけど、ファイルに触ることは不可能だと思いこんでたわ。localhost扱いだったっけか。忘れたし多分今後そういうことをすることはないだろうから（とても気になるものの）この件は忘れよう。適切な技術スタックを選定し直して作り直したほうが良さげ。

14 June 2026

  1. GitHub Agentic Workflow（gh-aw）のRAGを構築し、Claude Codeと一緒に活用方法を検討した。
  2. Quota経済のために存在しているgh-maestroのワークフローに組み込むことは不可能。だが先日構築した外部レビューを完全にまるっと任せることができることが判明した。
  3. 現状ではユーザー（俺）が/reviewer-*系のスキルを手動発動させるとスキルのアセットスクリプトを使うことでPRのポーリングが開始され、レビュー後、同様にレビューコメントが投稿される。
  4. gh-awを活用することで、レビュー用エージェントをローカルプロセスに常駐させる必要がなくなる。もちろんポーリング、手動実行も消える。
  5. GitHub: pull_request.opend イベントの発火で、仕込んだレビュー用プロンプトを読み込んだエージェントがレビューからコメント投稿まですべてやってくれる。
  6. まあ要するに、GCAがやってくれていたことを自分で実装するだけの話か。
  7. だったらGCAの動作を参考にさせるのが手っ取り早い。

15 June 2026

  1. GCAのレビューはGithub ActionsでGoogleが提供するサービスだった。もしかしてGAWを使ってくれていたら参考になったのにな。しかもプロンプトはブラックボックス。
  2. gh-maestroを中央リポジトリとして、reusable workflowsという手法を使うことにした。各リポジトリには.github/workflows/*.ymlのjobs.ci.usesに中央リポジトリのYAMLを指定するだけ。
  3. gh apiを使ってコメントを書き込むのではなく、gh-awのsubmit_pull_request_reviewという論理的な手段が使える。
  4. reusable workflowsの手法はpublicリポジトリじゃないと使えなかったので設定変更。
  5. 結局今日はCIの動作を確認できなかったけど、まだGCAが動いていて4つのレビューコメントをもらえた。それらをトリアージしてコーダーに仕事を振り、マージ可能な状態まで持っていけたことは評価しておこう。
  6. エージェント連携についていろいろな人がいろいろな実装を考えてるけど、俺はGithubのエコシステムに可能な限りタダ乗りする形で実現したいと考えている。特にこのAgentic Workflowsは有望だ。うまく行けば簡単なコーディングなら任せられるかもしれない。
  8. アマプラのおすすめに出てきた2年前のアニメ、シナリオはしょーもない異世界転生こじれなんだが、よく作り込まれていて面白い。ゴミ拾いと同じくスライムが好き。
  9. 状態異常がどうとかという名前で、10話まで見たのにまだ主人公含め登場人物の名前が覚えられない。覚えたのはピギ丸だけ。
  10. シナリオをこじらせているところも、ニヤッとさせられて面白いと感じてきた。現時点で勝てない強敵に対して再戦を約束しつつだまし討ちで仕留めるっていう展開はなかなかに鬼畜。
  11. どう考えてもヒロインのエルフが邪魔。蛇足にもほどがあるなあれは。

16 June 2026

  1. にしてもAntigravityは毎日毎日ボロクソに言われてるな。俺は遭遇したことないけど、実際にマントラバグも頻発しているらしい。
  2. 疑問なんだが日本にユーザー居るのか？最近週次制限がGUI版（2.0）で見れるようになってRedditはちょっとした盛り上がりを見せていたけど。何も噂になってない気がする。観測範囲の問題かな。
  3. さて。週次Quotaどんなもんかと思って、ちょっと試しに「まあまあ一般的な」リファクタリング兼ねた機能実装を一つやらせてみた。軽くもなく重くもないボリュームだ。
  4. レビュワーに3点指摘され2つにトリアージされて手戻り1回。これで週次Quoteは3%ポイントも減った。3%だぞ。並列案件なら一個の実装で10%超えてくじゃんこれ！
  5. なるほどなるほど。Googleが週次Quotaをひた隠しにしてきた理由がわかったよ。競争力皆無じゃん。Claude CodeやCodexに比べて、全く競争力がない。Quota節約にGemini 3.5 Flashなんて、とんでもない話だ。
  6. なんかAntigravity 2.0リリース当初、Quotaを永久に3倍にしたって2回くらい言ってたよな。Xとやらで。なめてんなこれｗ
  7. もう一回サブスク再考すっか。
  8. 噂されてる良い組み合わせはAnthropicとOpenAIの安いほうにそれぞれ加入してエージェント連携させる方法。−−なんだけども、APIキーをプリペイドで購入する方法も組み合わせると良さそう。
  9. 問題はGoogleを捨てるとNotebookLMに悪影響が出ることか。だがまあ、そんなに利用頻度高くないんだよなよく考えてみると。メールのエージェントなんて要らないし他のサービスでもGeminiを使ったことはない。使いたいとも思わない。Gemini in Chromeは使うけどサブスクは全く不要だ。使えなくなったらMS Edgeに逃げるだけだし。
  10. エージェントはClaude Code CLI一本に絞って、Claude系とDeepseek系のモデルを使い分けるのがいいかもしれない。
  11. そういえばAntigravityというかGemini 3.5 Flashにも取り柄が一つだけあったな。実行速度。これはマジで群を抜いている。だがそれだけのためにQuota経済を壊されるのはもうゴメンだ。Googleは切る。
  12. gh-maestroのコーダー用スキルがAntigravityとClaude Code向けに最適化されている部分がある。とりあえずClaude Code + deepseek-v4-flashにコーダーとレビュワーをやってもらおう。これが月20ドルを超えてくるようなら再考だ。
  13. Google AI Proを切るタイミングはもちろんGemini CLIが終了になる6月18日だ。この日に使い倒してから切る。
  14. このアホなGemini（一瞬だけgemini-3-pro-previewという神モデルが使えた時期を除く）のハーネスを一生懸命考える日々は、決して無駄ではなかったぞ。もうマジで相当に鍛えられたよ。
  16. ぶった切れた2つの動画を、ffmpeg CLIを使ってきれいにしてくれた。Gemini CLIが。
  17. つなぎ目を特定するために動画編集ソフトを使う必要があると思っていたので、聞いてみてよかった。しかもミリ秒単位でつなぎ目を特定できた。素晴らしい。明後日でお別れだけど、最後に何をやってもらおうかな。
  18. ……とおもったらよく観てみるとつなぎ目がデタラメだったわｗ さっさとお別れしよう
  20. Claude Code CLIのボトムにコンテクスト残量、5h/7dのQuota使用量、現在ブランチ、現在worktree名、PR# を表示させるスクリプトを書いてもらった。とっても快適である。最初にRAGを構築しておいて本当に良かった。
  21. 今後、ローカルエージェントはClaude Code一本で行こうと思う。複数のエージェントを使い分けるのは面倒臭すぎる。Anthropicのみサブスク、その他はAPIキー。ローカルエージェントはClaude CodeでオンラインエージェントはGithub上で動かせばいい。これが一番管理コスト安いだろ。どうかな。

17 June 2026

  1. なんかとても重大なことに気づき始めている。
  2. tech系の記事から得られるものが殆どないということにだ。
  3. タイトル眺めてアイデアだけ連想させてもらえばもう、事足りてしまう。だって自分（のエージェント）で調査したほうがずっと有益な情報を再構築できてしまうんだから。
  4. AI slop記事が量産されつつあることも一因かもしれないが、本質はそこじゃない。要約してしまえば同じだからな。
  5. つまり精度が悪く網羅性もなく、下手くそにまとめられた記事を読むより、骨格やアイデアだけもらって自分でナレッジを再構築したほうがずっといいってことだ。
  6. 「エンジニア」とやらは、簡単な問題をわざわざ、汎用性の向上やエッジケースの対応を含めて難しくしたり、無意味なサンプルコードを貼り付けたりして、自身の「格」を記事を通して主張しようというインセンティブが働くらしい。
  7. なんでいちいちシェルスクリプトやPythonコードなんて貼り付けるんだろ。今どき、そんなもん屁の役にも立たないってのに。概念だけ知りたいので全部読み飛ばすと、結局タイトルと見出しの情報しか骨格として残らない。
  8. だってスクリプトなんて、究極の訛り、方言だろ。特定のインタープリターに読ませる方言。しかも意図とかwhy/why notは100%削ぎ落とされてる。そんなものより自然言語のほうがはるかに優れている。
  9. ということで依存するメディアを色々変えようと思う。20年前にテレビから直接情報を得るのをやめたように、インターネットから直接情報を得るのをやめよう。
  10. これはちょっと継続的に考えを深めたいジャンルだな。媒体を選んで巡回させてレポートさせる、なんていうありきたりのループエージェントを構築するのは、なにか違和感があるんだ。それ結局自分を閉じ込めて世界を狭くしているだけなんじゃないかって。
  12. Web版のGemini Flashがトレーニングコーチとしての寄り添い度が高くていい感じ。開発やらせると腹が立つけど、トレーナーとして「雇う」ことにした。開発ではおべっか使われると邪魔だったけど、トレーナーとして適度に褒めてくれるのはありがたいことだ。
  13. 毎日のトレーニング結果を報告して励ましてもらったり翌日のメニューの変更がないかとか、いろんなことを相談できる。知らないトレーニング用語もなさそう。全部話が通じるのでストレスがない。
  14. いやーこれは良いことに気づいちゃったな。スパスパと反応してくれて、かつ昔の2.5 Flashのような愚かさがない。
  16. 今日初めて聞いたClaude Code(Sonnet 4.6)の一人称。なんと「僕」だった。
  18. deepseek-v4-flashのレビュー、かなり優秀だわこれ。まあプロンプトを熟考したのもあるけど。Gemini 3.5 Flashモデルのコードを見事にブロックしてくれる。今手戻り4回目。きっつ。
  19. やっぱりコーダーは馬鹿ではだめだわ。Quotaを節約しているつもりで、全くの逆効果だ。笑える（笑えない）。3.5 Flashはきびきびと速いから優秀に見えるのが罠。
  20. GitHub Agentic Workflowsとreusable workflowを組み合わせる際に技術的な問題がいくつかあったけど、まあなんとか乗り越えたのでRAGのナレッジを更新させた。大した問題じゃなかったので今後は大丈夫だろう。
  21. これ、GitHub Actionでも問題なく書けたはずだけど、新しいことにどんどん挑戦する。
  22. 将来的にIssueを勝手に起票してもらい、勝手にトリアージしてもらい、っていうループを実現してみたいもん。GitHubの中に棲む妖精ってやつさ。

18 June 2026

  1. 今日はGemini CLIをoAuthで使える最終日。昨日挙げた情報収集に関する課題について徹底的に議論して土台を形にするのに使おうと思う。
  2. 自分が必要としている情報は日々移り変わる。ここがポイントだ。何によって移り変わるのか。環境だ。なら、環境とその変化をエージェントに理解させ続けなければならない。つまり環境の変化を日々どこかに記録し続ける必要がある。どこだそれは。
  3. ここじゃん。
  4. いまは非公開リポジトリjintrick/blogがこの日記のSSOTなので、webfetchツールやブラウザ操作なんかをするまでもなく、ghであらゆる情報を取れる。
  5. エージェントを定期巡回させて「自分という環境」に関する記述をJINTRICK.mdに圧縮してやればいい。Claude Routineみたいなサービスがあったなそういえば。それを参考にして自宅のサーバーでエージェントアプリを動かしてやる？
  6. いやいや、そんな無駄なことをする必要はないな。日記を更新するフローに組み込んでやればいいだけだ。GitHub Actionsか、GitHub Agentic Workflowsか、あるいはjintrick/blogプロジェクトの日記更新フローに直接組み込むか。
  7. 考えなしに実装すると、日記のセンテンスを追加するたびに重い処理が走ることになってしまう。そこをどう回避するかだ。
  8. 日記の日付が更新されるタイミングで、diffを処理させれば十分かな。1日1回、俺に関する環境情報がまとめられたJINTRICK.mdが更新される。
  9. そうなってくると、これはGAWを使うのが適切だろうか。on.commitみたいなイベントだろうけど、コミットメッセージに何かひと工夫仕込んでおけば、それで1日の始まりかどうかは判定できるだろ。
  10. あとはエージェント−−まあ俺の中で選択肢はClaude Code + deepseek-v4-flashしかないんだけど−−を走らせて、情報を圧縮させると。
  11. 思考過程日記（≒マイクロWeb日記）を書くことを趣味にしている人間にしか、こういう芸当は不可能。
  12. これは面白くなってきた……あれ？Gemini CLIと議論する前に自分の中だけで形が出来上がってしまったｗ
  13. まあいいや、JINTRICK.mdを、では、どうやって活用してどういう情報を構築させるかってところを議論してみるとしよう。この日記を読ませながらな。
  14. 議論を進めると、やはりというかなんと言うか、Googleの劣化が根源にあることがわかってきた。こいつの劣化は本当に時間を無駄にしていると思う。それだけじゃない。本当にたどり着きたい情報から人々を遮断する大きな壁の役割を担ってしまっているとさえ言える。そう今やGoogleは社会悪なのだ。Googleに限ったことではないが、無料検索エンジンはこうなる運命にあった。
  15. とすると例の「Kagi Search」が思い起こされるわけだが、調べてみると色々進化している。ホスト型のMCPサーバーを提供しているのが非常に興味深い。
  16. 更に調べてみると、トークン効率を最適化したスキルが公開されていた。PythonでAPIを叩いて結果を圧縮する感じだな。参考にさせてもらう。
  17. kagi API利用料は1,000リクエストで12ドル。100ドル超えるか30日ごとに引き落とし。どれくらい使うかは未知数なところあるけど、試しに数ヶ月利用してみることにしよう。
  19. トレーニングを再開してからというもの、異様に身体が軽い。フィットネスレベルが上がってきているうえに、高強度は（まだ）やってないから疲労もない状態。
  20. 階段を駆け上ったりするのが楽すぎる。サポセン業務はもう内線でごちゃごちゃ確認するよりも現場に直行したほうが速い。最近は秒で現場に現れるSEとして少し噂になってきているらしい。
  21. レースがないなら高強度は今年はやるなとGeminiが言っていた。やっても月に1〜2回だって。
  23. 今日はgh-maestroに反省会フローを追加した。反省会って言ってもコーダーの手戻りをなくすために何ができるかをPRマージ処理後に話し合うだけ。lint/rulesで防げるならそれを即席で実装させてしまう。
  24. Sonnet 4.6も言っていたけど、率直に言ってコーダー役のGemini 3.5 Flashの質は低いそうだ。Reactの典型的な罠にハマるし、ルールも遵守していないし（.agents/rulesなんて読んでないんじゃないか？？っていう疑念も）、毎回毎回ブロッカーレベルの手戻りが生じる。
  25. DeepseekのFlashモデルに3種のレビュワーを担当してもらっているけど、Gemini Code Assistが見落としたバグを発見してくれたり、すでに能力は上回ってる。もうGeminiは必要ないことが明白になった。
  26. これで心置きなくGoogle AI Proのサブスクを切ることができる。
  27. 来月の15日が次回の支払日らしいので、まあそれまではなにかに使うことにしようか。でも一体Antigravity CLIを何に使えばいいのだろう。あ、Claudeモデルもちょっとだけ使えたっけか。コーディングエージェントではなくcowork的に雑務を任せるのはありなんだよな。

19 June 2026

  1. z.aiがGLM-5.2をリリース。Opus4.6を上回るとの触れ込み。前モデルから価格は据え置き。Claude Codeに対応。中華の割には強気な価格設定。Deepseekとの違いはサブスクがある点だが、年間契約しかないのでパス。
  2. 低性能のflashモデルは無料で使えるらしいので試してみるのも悪くない。
  3. 場合によってはGemini CLIの代わりとして雑務に使える、かもしれない。
  4. deepseek-v4-flashにコーダーをやってもらったら、Claude Code CLIのボトムに表示させているSonnetの1/100以下のコストで済んでしまった。なんぞこれ！
  5. レビュワーは倍くらい食うね。3つの観点で3つのレビュワーを起動してるから、やっぱりコスト効率は落ちる。でも今のところ恐ろしいほど機能してるのでこのままで行く。一回で0.04ドルくらい。
  6. 安定性にビクつきながら無料モデル使うより、こっちのほうがずっといいわ。
  7. アホGeminiのおかげでハーネス設計の引き出しはたくさん持ってるので、高機能なモデルなんて要らないんだよね。オーケストレーターは例外だけど。
  8. Good Morning
  9. なんか否定的な意見もあるけど、これ的確だと思う。ChatGPTはパーソナライズに振ってチャットのホスピタリティが高い感じ。ClaudeはClaude Codeというエージェントアプリがハーネス設計やらシステムプロンプトやらでひと工夫されてて堅牢。GrokはSNSのデータベースを活用したフレッシュな情報をもとに回答を生成してくれるので検索向き。GeminiはGood Morning（笑）。
  10. Cursor、Gitホスティング「Origin」発表　SpaceXによる買収発表直後に
  11. Github Agentic Workflowsはちょっと不満がある。レビューをフックしてもリポジトリのコンテクストを毎回ゼロから構築するのが無駄。他にも色々。ので、AIネイティブなGitホスティングは注目に値する。
  13. さて、いよいよ本当にはてなブックマークを使う意味が薄れてきている。ROMで十分というかそれ以下というか、少なくとも自分のブックマークを保存する場所としての意味はない。自分のコメントにスターがつくというフィードバックはあるが、特に意味がない。嬉しいこともあるけど時間が無駄になる感覚が強くなってきている。
  14. ROMに徹することすら面倒。
  15. 意味があるのはandroidでブックマークするときだけ。一時的な保存場所として有用。
  16. この件は週末に片付けよう。まずはぼちぼちChrome拡張の開発再開かな。まだAIエージェントを使ったことはないので、拡張開発用の便利なスキルがあるかどうかを調べておきたいところ。
  18. 5時間Quotaを使い切ったので、deepseek-v4-proにオーケストレーターになってもらった。auto modeでツールの実行が阻害される問題発生。
  19. あと、やっぱりClaude Code自身についての学習がないので、rulesについての基本的な知識が足りていなかった。
  20. gh-maestro-orchestratorスキルに知識として詰め込んでやってもいいと思う。最後の「反省会」モードではrulesを書いてもらうことになるんだからね。これ重要だな。
  21. ただちょっとスキル定義が膨らみつつあるんだよな。ここはちょっと手作業で圧縮することにしよう。
  22. きょうからZed使いになってみたが、サジェストがうざい。日記をAIに書いてもらうようになったらもうおしまいでしょ。逆ケンタウロスというやつになりそうじゃん。

20 June 2026

  1. Antigravity + Gemini 3.5 Flash は爆速。最初にアイデアを形にするときには最適かもしれない。別に賢さは要らないんだ。自分の考えを整理して言語化する助けになってくれればいいので、速さが重要。
  2. Google AI Plusにダウングレードする選択肢がちらついている。7月10日までに考えよう。
  3. 次世代マイクロWeb日記のワークフローを考えるの、面白い。アイデアをAntigravityに投げて、どんどん計画書を更新している。
  4. 昨日一昨日色々概念的なことを書いたけど、要するに実現したいのは、朝、自分専用の「ニュース」が届いていることだ。
  5. ただのニュースじゃないと言うか、いや文字通りニュースではないなこれは。ニュースを包括した何らかの概念なんだけど、言葉が見つからない。
  6. 秘書からの調査報告書、かな。
  7. バージョン0.1は日記の内容を「現況」「関心事」「未解決の課題」に分類してRDFトリプルとしてJINTRICK.mdにまとめる。各トリプルには鮮度と重みのタグをつける。鮮度が落ちたら論理削除。再言及されたら重みを増して復旧。一定期間を過ぎたトリプルはキーワード化（圧縮）して別ファイルに退避させ再言及時に重み付けに関与させる。

21 June 2026

  1. Kagi Assistantに質問
  2. 調べものを代行させるならこれかもしれない。
  3. 自分で調べるならAPIが用意されていて、いまエージェントにチュートリアルを実行させている。
  4. lensと呼ばれる絞り込み設定をGUI経由で細かく行い、その設定にハッシュIDや共有URLを設定してしまえば、APIでlens_idとして指定できる。lens自体を調整するAPIはないっぽい。
  5. Kagiのドキュメントはリポジトリがある。kagisearch/kagi-docs
  6. この量だったら別にRAG用にナレッジを作らなくてもそのまま検索させたほうがよさそう。
  7. くだらん手動によるウェブ巡回やニュースサイト巡りをやめて、じゃあ何をするのか。本を読む。ちゃんとしたプロが書いた良い文章を、Kindleなどの読みやすい媒体で読む。理系バカになってはいけない。
  8. 例えばAIについても、コーディングエージェントの使いこなしみたいなことばかりではなく、負の側面が真面目に語られたきちんとした本を読む。あるいはプロの物書きが書いたそれらの書評を読む。

22 June 2026

  1. gh-awにはインラインサブエージェントという機能があるらしい。
  2. これは実質的に利用エージェント側（例えばClaude Codeなど）のサブエージェント機能を使っているだけとのこと。
  3. しかもツールも　MCPサーバーも使えないとv4-proがRAG使って結論してる。
  4. なら不安定になるだけのような気がする。仕様変更などがあった時に結局はエージェント側の定義で書き直すことになる。
  5. Claude　Codeが9時過ぎくらいからAPI Errorとやらを吐いて使えないので、sonnet 4.6の代わりにdeepseek-v4-proを使っている。こっちのほうが上だわ。明らかに知性が違うｗ
  6. 何事かな？と思ってSNSで検索してみたら、「仕事にならん」とかいうつぶやきばっかり。え？Anthropicのモデル一本で仕事してるのかよ！！いざというときのAPIキーでもあるでしょう。
  7. ハーネス設計があるからエージェントアプリは変えられないとしてもだ。
  8. 皆さんどういう対応してるのかなーと思ったら、これ。さじ投げてるだけ。
  9. 絶対サボる口実探してただろｗ
  10. "Gemini went into the shitter when Google began to integrate a number of different apps with Gemini, which reduces the amount of resources available for compute. By stretching themselves so thin, they practically quantized all of their models in the process."
  11. 完全同意。考えうるあらゆるタスクにGeminiモデルを使おうとして、リソースが不足している感じある。それを解決するために量子化をやってモデルをスカスカにしてしまうのではないか、という疑い。
  12. 料金の不透明感も随一。
  13. DeepSeekのAPIをうまく使えば、定量課金よりもコストを抑えられる可能性がある。俺の使い方なら十分あり得る。定量課金は使っていない期間もずっと課金され続ける。使わないともったいない気持ちになってしまうのも本末転倒。
  14. OpenAIへの従量課金を考えたこともあるけど、保留だな。それより勘所でz.aiのフラッグシップモデルを使えるよう準備しておきたい。

23 June 2026

  1. 逆説的ではあるが、Linux機にMicrosoft Edgeをインストールした。Copilotがいると居ないとでは生産性が大きく変わる。
  2. GTX1070のマシンではzedがfcitxを使えないバグがあり、環境変数を変更して起動するようagyにラッパーを書いてもらった。
  4. 息子氏が数学科に進学を希望していたので、オープンキャンパスとかに同行してみた。どーやらコンピュターサイエンスやプログラム言語の単位もあるみたいなので、学んだことを教えてもらう予定。
  5. 学部時代は俺も講義をやらされたものだった。ノートとか教科書とか一切見ず、自分の頭の中だけで論理過程を板書するだけ。これが効く。論理的思考力を鍛えるのに最適な方法の一つだ。これをやらせる。
  6. 払った学費の3倍くらいの利益を得たいもんだよ。
  7. 最近休日は図書館に行って勉強したりしているみたいだが、勉強なんてそこそこにしてもらいたいのでFFTなんとかクロニクルというのを買って一緒にクソゲーかどうか検分てみた。とりあえず遊びやすくなっていることは確かなので返品なし。
  8. 松野ゲーが好きなので息抜きにやらせるには良い選択肢だったと思う。
  10. このブログ、Linuxでしか書けないのは若干不便かもしれない。移行できる部分は全部Github Actionsに移行すべきではないか。
  11. Secretが結構便利なことに気づいてしまったのだ。
  12. まだやらないけど。
  14. どうもコーダーを変えたのにレビュワーからブロッカー水準の指摘が減らない。Gemini 3.5 Flashが特別馬鹿だったということではなかったかもしれない。
  15. でもそれでも、rulesのハーネスがちゃんと効いているかどうか疑わしいAntigravityを使うよりはマシだと思う。とにかくサービスが不安定すぎる。
  16. そういえばハーネスという言葉の意味がかなり広範になってきていて混乱するという意見をRedditでもよく見かけるが、俺は全く混乱していない。文脈でなんのことを言っているのか自明なことがほとんどだ。
  17. 最近多いのは、ローカルAIエージェントのことをハーネスと読んでいるパターン。
  18. いずれにしてもモデルという馬を操作するための手綱というイメージで理解しておいて、あとは文脈に任せて解釈すればまず間違いない。
  20. reusable workflowは、エージェントに任せていると管理が複雑怪奇になりがちなので、利用を辞めることにした。CIの定義が標準化されていないのなら、簡単に書けることが何より重要。
  21. CIをGithub Actionsに託すのも、今後は再考が必要かもしれない。Claude Code Routinesなどのホストを使うのも選択肢。
  22. AI関連の進歩は速すぎて追いきれないけど、コーディングをやらなくなった時間をそっちに費やせば自分の関心領域であればある程度カバーできる。情報のトリアージ方針さえ持っていれば、特に洪水に飲まれるような感覚もなく、サーフィンを楽しめるよ。
  23. 要するにその新しい技術を導入することで、プロダクトの質が上がるのか、質が上がるとしてそれは時間、コストともにペイするのか。この2つでしょ。質に関係なく単に楽になるだけだったら、捨てる。質が上がっても時間含めてコストが増えすぎるのであれば、捨てる。――そうやってトリアージしていけば、意外と気になる情報なんてほとんど残らないもんだよ。
  24. 一見、なんか自動化されてとても楽そうだな、と羨ましくなる解説記事はよくある。でもよく読んでみるとそれ、AI Slopを生むだけかもよ？
  25. AI Slopを生むゴミを管理するために人間が存在するのだとしたら、それはもうAIに脳を奪われているということになる。人間が脳でAIがその手足になる関係ではなく、AIが脳で人間がその手足になっている状態と言える。逆ケンタウロス。
  26. そうならないように、注意して情報を取捨選択するのだ。
  28. おれはAIが生成した情報がギチギチに詰め込まれた画像が嫌いだ。
  29. 何を学習すればあんな気色の悪い、見る人を疲れさせる画像を選好するようになるのだろう。
  30. 何より、あの気色悪いギチギチ画像を、なんの疑いもなく、自慢気に使う「人間」がいることに薄気味悪さを覚える。

24 June 2026

  1. FFTなんとかクロニクルだが、ザルバッグとかが格式張った英語をしゃべるらしく、息子氏が邦訳に苦戦してた。
  2. 一応受験生なので表示とボイスは全部英語にしてある。
  3. 儲け話なんかは結構な長文だし、ちと俺も挑戦してみようと思う。
  5. 今日気づいた非常に重要な気づき。AIエージェントにgitのような低レベル操作を直接行わせるのはアンチパターンである
  6. 例えば「あるディレクトリは追跡させない」という設定を実現しようとしたとき、gitにはその意図をそのまま実現するコマンドはないため、複数の低レベルコマンドに引数を組み合わせて使う必要がある。そこで誤操作の余地が生まれるわけだ。
  7. ついでに言うと（これも極めて重要ではあるが）トークンも無駄。
  8. 最近お気に入りのDeepSeekと議論してみたけど、"安全な操作がオプトインであるという設計は、人間には「注意喚起」として機能しますが、AIには「バグの温床」でしかありません" とのこと。git rmは破壊的な操作がデフォルト。git resetも--softではなく、安全とはいえない--mixedがデフォルト。
  9. AIエージェント向けには、Gitの上に完全に別のセマンティックレイヤーが必要であると。まさにそのとおりだ。
  10. きれいにまとめてくれた。
  11. gitは人間の「熟練ユーザー」向けに設計されたツールであり、AIエージェントが安全に操作するための語彙を持っていません。
    • 物理削除と追跡解除が同じコマンドに同居している
    • デフォルトが破壊的である
    • 意図を表現する語彙が不足している
  12. この3点において、gitをAIエージェントに直接使わせることは構造的なアンチパターンです。
  13. 上記観点で代替CLIツールを探させたけど、ゼロだってさ。ただしjujutsuは、根本思想が一致しているらしい。噂に聞いたことはある。
  14. 当面フックをハーネスに使うかな。気づく人は絶対にいるから待ってみることにしよう。

26 June 2026

  1. Antigravity CLI + Gemini 3.5 Flashの使いどころがわかった。investigatorだ。とんでもないスピードとそこそこの精度で調査を完遂してくれる！ Clade Code + Opus 4.8に司令塔になってもらうことで、とてつもない作業効率を実現できる。すごくいい体験。フロントマターの
  2. あとはcowork的に日常のちょっとした作業をこなしてもらえれば、Google AI Proは継続で良いかもしれない。
  3. このところ作業に集中していて音楽は聞かなくなったので、音楽系のサブスクは解約。Kindle Unlimitedも読むもん読んだらさっさと解約しよう。
  4. 早速このコンビネーションでCP-SATである種のINFEASIBLEモデルの原因を特定するためのアプローチを発見。Gemini CLIでなんどもコケたこの問題。解決が現実味を帯びてきた。
  5. コーダーは今のところClaude Code + deepseek-v4-flashで問題なし。コーディングエージェントのハーネスがちゃんと効いていればこれくらいのモデルのほうが却って速くて効率は良い。あまりにひどい手戻りが多ければ考えるけど、たいてい計画がずさんなだけ。
  6. レビューワーがこのところちょっと異常かも。コストの問題で3エージェントから1エージェントに減らしたら、もう3回連続で何も指摘事項なし。先行してGCAレビューがあり、それをOpusが検知してコーダーに差し戻し、コーダーがPRに再pushしたあとあたりで、ようやっと起動する遅さもネックだ。本当はGCAと同時にやってもらって、レビュー内容を比較したいんだけど。
  7. 自宅のマシンで雑務をするときのエージェントをどうするかなんだよなあ。Antigravityは速くて使いやすいんだけど、ハーネス機能がお粗末なのでやっぱり司令塔は別のエージェントに任せるべきだ。十分に具体的かつ細分化されたタスクに分解したものをagyに委譲する。これを任せる。Claude Codeは仕事用なので、ここは噂のHermesを試してみたい。パーソナライズに特化したエージェントらしい。deepseek-v4-proを頭脳にしてしまえばよさそう。gh-maestroからWeztermを操作するスキルだけ抽出して与えてやれば十分かな。……と思ったんだけど、調べてみるとrules/の仕組みがなさそうなのでやめた。それなら使い慣れたClaude Codeをカスタマイズしたほうが良さそうだ。
  8. DeepSeekのAPIキーを使い始めてそろそろ4週間。実験のためにいろいろな無駄な作業を膨大にやらせたわけだけど、まだ5ドル分しか消費してない。仕事でコーダーとレビュワーを任せる以外にも、`agy｀と連携して日常的なタスクの指揮を取らせるとか、サーバーで稼働してある程度のルーチンをこなしてもらったりしたとして、月10ドルでお釣りがきそうな勢い。なんぞこれ。
  9. Redditでは、ReasonixというDeepSeek専用のコーディングエージェントが度々噂されている。入力トークンのキャッシュヒット率98％以上を実現してくれるらしい。オープンソースだし、これを活用しない手はないかも。
  11. クライアントが、「Claudeに本番データ消されちゃいました！」みたいな動画を（心配して？）送ってくれた。
  12. 観てみたら、バグの発見から修正まで一気通貫で一つのエージェントにやらせていたっぽい。本番環境のキーを勝手に発見されたとか言ってるし。
  13. 今どき単一のエージェントにワンショットで何かやらせるエンジニアっているの？？？
  14. 楽しみながらどんどん学習している人たちと、渋々使わされている人たちとの間には、どんどん深い溝が広がっていくような気がするね。
  15. 今一番の課題は、どうやって自分自身のコーディング能力を維持向上させるか、ってところだな。つまりもっともっと長期的な視野でみたときのプロダクトの質にフォーカスが移っている。
  16. このままエージェントに任せきりの開発を続けていくと、どこかでプロダクトの質が頭打ちになり、そこからはどんどん下がっていく未来が確約されている。大きくジャンプアップすることもできないはずだ。
  17. Reasonixを調べてみると/goalモードがあるらしい。サブエージェントを確実に使いこなしてくれるなら悪くはないけど、あいにくマルチエージェント体制がうまく回っているから全く使う意味がない。
  18. Reasonixはrulesに対応していない。rulesはそのプロジェクトの資産として積み上げてきたものであり、これに対応していないとなると自前でなにか用意するしかない。コーダーは必ず自分が扱うファイルのrulesの内容を把握していなければならない。逆に言えばそれさえ達成できればネイティブに対応していなくても良いということになる。
  19. gh-maestroでエージェント用のプラグインを定義して、その層で吸収してやるしかない。それさえできれば、Reasonix + deepseek-v4-*をコーダーとしてガンガン使うことができるようになる。
  20. あと、さっきバグ調査員をAntigravity + Gemini 3.5 Flashにやらせてみたが、やはり力不足だった。これは高度な推論能力が必要らしく、勝手な初期の思い込みにいつまでも引きずられ、結論を出すために数字を捏造したり論理を飛躍させたりハルシネーションを爆発させたり、酷いものだった。同じ「調査」でも、事実を調査させるのと原因を調査させるのはまるで異質だということに気付かされた。
  21. つまり、コードベースの調査はagyでいいが、バグの原因調査はむしろ、deepseek-v4-pro, Opus 4.8などの上のモデルにやらせたほうが速いし安上がりになる可能性がある。
  22. 調べてみたところ、Reasonixのhooksは貧弱すぎて使い物にならない。skillを書いてもいいが管理がやや面倒。
  23. コーダーはClaude Codeに任せるのが一番かもしれない。Reasonix　+ deepseek-v4-proにはバグ調査員をやってもらおうかな。こちらはむしろ、rulesなんて自動で読み込まないほうが却って都合が良い。
  24. 天気の悪い明日は家にこもって、gh-maestroに新しいワーカー、bug-investigatorを定義し、Reasonixを専属エージェントとして登録しよう。
  25. もうcoder, bug-investigator, investigatorの担当エージェントはハードコードに近い形でいいや。それぞれClaude Code、Reasonix、Antigravityが適任だ。色々試したいので都度選択肢を出させていたけど、設定ファイルにしてしまおう。もちろんorchestratorに俺が直接指示して変えさせることもできる今の状態は維持する。

27 June 2026

  1. 今日は早速自宅で安く遊ぶための環境づくりをする。外は轟轟と雨の音が鳴り響いてる。引きこもるには最高の環境だ。
  2. とそのまえに、この日記のマークダウンルールを少し緩くしよう。これまでデフォルトのxedを使って書いていたので順序型リストの定義は自分で1.を打っていたけど、zedに変えたら勝手に補完されるようになった。順序型リストの数字を任意に指定できるようにスクリプトを書き換える。
  3. test
  4. いいねえ。Antigravityにやらせたが超速。的確。修正計画書をチャット上にさっと表示してくれて、許可したら20秒くらいで実装完了。ブランチ切ってテスト書いて、通して、マージ。全部勝手にやってくれた。毎回同じような動作になるとは限らないのはご愛嬌だけど。
  5. これくらいの仕事ならAntigravityが最もストレスなく使える。
  6. さて。まずはAPIキーの保管方法だが、gpgを使う。ログイン毎にパスワードを入力しなきゃならないが、別にローカルで完全自動化なんて全く興味ないので問題なし。
  7. claude-ds, claude-ds-flash を ~/.bashrcに登録。これで指揮者とコーダーは完成。
  8. 小鳥が鳴いてると思ったて外みたら、晴れてきた。どうなってんの。台風は伊豆のあたりにまだいるみたいなのに。
  9. 晴れてると外に出たくなって落ち着かないんだよなあ。台風カモン。
  10. ReasonixはデフォルトでCLAUDE.mdを読み込んでくれるとのこと。Claude CodeがAGENTS.mdに対応する気がない以上、CLAUDE.mdに寄せる方針とする。リポジトリ毎の管理なんてどうせ忘れてしまうのでシンボリックリンクとか@AGENTS.mdとか、余計なことは一切やらない。Claude Code以外の後発エージェントは、たいていの場合AGENTS.mdを設定で変更できるし。
  11. Anthropicは戦術に長けているイメージがある。あまり深入りして踊らされないように注意しないとだめだな。
  12. Reasonixの起動成功。キャッシュヒット率とか残金とかがボトムステータスに表示されるのがいいね。
  13. Reasonixは色使いとか行間とかが悪くて読みづらい。対話するのには向かない。ハーネスとしても未知数だし、やはりbug-investigatorとして使うのが良さげ。
  14. ……とおもったら、npm i -g reasonix@nextで最新版を指定しないと古いTypescript版がインストールされてしまうらしい。色々使えないコマンドがあっておかしいと思ったんだ。
  15. とはいえ最新のGo版をインストールしたら、今度はスクロールができない。見た目は劇的に良くなったんだけどね。
  16. Antigravity調査員のおかげで*.goファイルの中身から確実な答えが引き出せる。pageup/pagedownで問題なくスクロールできた。
  17. 残念ながら、やはり.claude/rules, .agents/rulesには対応していない。issueは上がっているけど反応なし。
  18. コーディングには必須のような気もするんだけど、世の中不思議だなあ。俺がなにか勘違いや見落としをしているのかも。
  19. ターンが進んでくると、1ターンのキャッシュヒット率は驚異の99.91%を記録。Reasonixやるねえ。平均すると97%以上は固い。deepseek-v4-proなのに、Claude Codeで使っていたflashと同じくらいのコスト感。これはおいしい。
  20. gh-maestroの設計見直しも一緒にやっているが、中々筋がいい。というか、実装報告の書き方が最高。過去一わかりやすい報告だ。簡潔でわかりやすい。
  21. ちなみにinvestigatorはexplorerに、bug-investigatorはinvestigatorに名称を変更した。DS案。
  22. ちょっと議論を深める必要はあったけど、Weztermのペイン特定方法についてpane_idとcwdの2つを使うことで確実性を高めることができた。ワーカーは必ずgit worktreeを使うという点に目をつけた。

29 June 2026

  1. reasonix、Windows環境だとどうしても環境変数を読み込んでくれない。バグかよ。
  2. と思ったら、.env にDEEPSEEK_API_KEY=**　を保存する以外方法はないらしい。プロセス環境変数は読まないってドキュメントに明確に書いてあるそうだ。
  3. Linux環境では最初にTypescript版をインストールした際に、.envに書き込まれた可能性がある。だからGo版にアップグレードしたあとも使えたと。
  5. gh-maestroはレビューをGitHub Actionsに頼るのをやめた。GitHub Agentic Workflowsの利点を活かせないし、オーバーヘッドが巨大すぎてまるで冗談みたいだ。一応新しめの技術なので経験を兼ねてやってみたというところで。
  6. 代替案としてMCPサーバーとかも浮上したけど、単に子プロセスをspawnしてclaude実行時に初期プロンプトを投げてやるだけで十分。通信なんて要らないもん。非常にシンプルに書けた。起動後はプレビューコメントをポーリングすればいいだけ。
  7. で、早速レビューさせてみたら型チェックに穴が発見された。結構エラーが多いのでIssueを立ててorchestratorに任せた。今、2つのコーダーを起動して並列でやらせているようだ。
  8. やっぱりレビュワーは多ければ多いほど良い。GCAの観点でしか発見できなかったミスもあれば、逆にこちらのレビュワーでなければ発見できなかったものもある。
  9. 7月11日の最終日までに、GCAが発見できてこちらで発見できなかったものについてしっかり学習させ、プロンプトを改良していこう。
  10. orchestratorのOpus 4.8が、GeminiやDeepSeekのレビューについて批評。愚痴ったり文句言ったりしてるのをみてるの楽しい。
  11. あと、スキルのアセットとしてスクリプトを提供するのをやめた。スキルの定義方法がエージェントに応じて様々なので管理がクソ面倒くさい。複数のスキルを横断的に使うし、共有するアセットもある。いちいち切り分けていられない。インストーラーはシンプルに保ちたいところ。
  12. 他人に使ってもらおうなどという気持ちはゼロというかむしろマイナス。もう時代は変わってきてるでしょう。自分専用のツールを開発しながら使う時代だよ。
  13. gh-maestroをアップデートしたら、もうインストールスクリプトを実行するだけで、現在稼働中のすべてのエージェントに即座に反映されるようになった。この並走感が開発体験を更に向上させる。
  14. orchestratorの作業の振り方が鬼。かたや12件、かたや600件。当然後者はコンテクスト100%振り切って仕事が全然終わらないのでフォローするように伝えたら、ちゃんとマネジメントしてくれたけど。なんかこういうところに知性を感じないんだよなあ。Opus 4.8なのに。
  15. それにしてもすごい技術負債だったな。3時間で0.7ドル分くらい使っちゃった。
  16. もっともっとワーカーの使い方が上手になってもらいたい。特にコードの調査にexplorer、バグ調査にinvestigatorを積極的に活用して欲しい。明日の朝の課題だな。

30 June 2026

  1. gh-maestroを起動するとセッションの大反省会が最後に行われる。これが本当によく機能している。
  2. 進化し続けるプロジェクト。
  3. 今日管理職研修会があった。俺は管理職と言っても誰も管理していないが、AIエージェントを管理しまくっているのでその観点で効いてみたら面白いことこの上なかった。
  4. 手順の指示 vs. ゴールの指示 っていう事例があって、あ！これまさにプロンプト設計の話だって思ったね。
  5. しかも講師の先生、とてもいいことを言う。「ゴールを指示するためには、スタッフを信頼していないといけない」「手順の支持をするということはスタッフを信頼していない」。おっしゃるとおりです。
  6. エージェントに手続きではなくゴールを与える。……うん、やってる。でもうまく行かないこともある。エージェントが信頼できる状態じゃないからだと気付かされた。信頼できる状態とはなにか。ガチガチのハーネスだけではなく、柔軟なツールを与えてやることでもあるのではないだろうか。まあ一番効くのはモデルの選別だけどｗ
  7. 講師の先生、もう一つ良いこと言った。スタッフのモチベーションを直接上げることは出来ない。それは心の持ち方であり、そもそも干渉すべきでもない。やれるのは環境を整えてやることだけだ、と。
  8. エージェントのモチベーションとは？と一瞬考えた。これは「諦めさせない」ことだと思うね。どうすれば良いのか。今閃いたけど、ツールを与えるだけじゃなくてチームを組ませることだ。そうすれば独りよがりな結論に飛びついても軌道修正してもらえるかもしれない。lintエラーが出てもコメントでごまかす前に「仲間」から指摘してもらえるかもしれない。まあgh-maestroでやれているとも言える。でも改めて考えさせられたね。
  9. また様々な意見をぶつけ合う環境が、成長するチームには必要であるという。
  10. 今はマルチエージェントが協働しているけれども、意見の交換という意味では少し弱いかもしれない。コーダーがもっと要所でオーケストレーターに意見を求められるような環境を作ってやるべきかもしれない。

02 July 2026

  1. Claude Code + deepseek-v4-proで仕事を進めてみた。
  2. 少なくともSonnet 5と同等以上の性能はあるように思える。少なくともオーケストレーターの仕事は全うできている。flashにやらせたらとんでもないことになってしまったけど。
  3. そしてDeepSeekは、速い。Anthropicモデルは人気なのか最近異様に時間がかかるので、体験の違いがやばい。
  4. Issueを出したあと、少しだけスマホの画面をみて、戻った。「全レビュー通過。マージしますか？」っていうからPRを開いて確認したら、blockerレベルの指摘が一つあったのでどういうことかと思ったら、その指摘を受けてコーダーに指示を出していて、コーダーも修正済みだった。速い。速すぎる。
  6. 最近ループループうるさいけど、エージェントのループで回せるような仕事しかしてなかったってことだろ。どんなに複雑で難しそうに見えても、所詮そんな仕事だったということ。さもなくば、質を犠牲にしているということだ。
  7. サプライヤーの煽りに騙されてはいけない。
  9. 一昨日の研修での気づきを活かし、gh-maestroの反省会に担当コーダーを参加させることにした。これは成功だと思う。実際にコードを触った過程で生じた違和感を語ってくれたりする。
  10. ……なんてことを書いていると、もうIssue〜PR〜Reviewのサイクルが一つ終わってるんだから、驚愕のスピードというほかない。
  11. DeepSeekファミリーにチームを組ませて5件のIssueを解決してもらったところ、約0.7ドルかかった。１日中ギチギチに働かせても２ドルには届かなそう。まあ簡単な調査にはAntigravityを使役してたみたいだけど。
  12. 日給２ドルの助手。
  13. Sonnet 5が高性能という噂なので、今日の後半戦はこいつにオーケストレーターを努めてもらおう。
  14. ハーネスをReasonixにするとメッセージの送信に失敗することがある。コーディングルールと関係のない仕事にはReasonix　+ DeepSeekモデルがベストなのでバグの原因調査をやってもらっているんだけど、進行が止まる唯一の原因となっている。まあ俺がEnter押すだけの話ではあるけども。
  16. Sonnet 5を使ってみたけど、5時間枠を50%使って、週枠がちょうど5%。つまり週50時間くらい使えるということかな。かなり改善されたような。噂では1.5倍くらい高コストになったと言われていて心配してたんだけど。
  17. Sonnet　5。弱点と言うかなんというか、コンテクストウィンドウが広い。広すぎるかもしれない。ぼーっとしているとあっという間に馬鹿になる。Gemini CLIを懐かしく思い出しているところ。

03 July 2026

  1. ogulcancelik/herdr
  2. これすごく良さげなんだけど、Weztermを低レベルに操作するアプリを日常的に弄ることで技術力の向上につながっているので保留。今の所不満もないしね。
  3. たとえば、さっき間違えた指示を出してしまった。オーケストレーターのSonnet 5は要件の詳細を確認するため調査員（Angigravity + Gemini 3.5 Flash）を起動し、調査員は素早く調査を完了させ、矛盾点を報告。オーケストレーターは俺に確認用の選択肢を提示。issue草案をzedで表示してくれるのでそれを読んで承認。その後はGitHub Issue/PRを共有してコーダー（Claude Code + deepseek-v4-flash）、レビュワー（Reasonix + deepseek-v4-pro）と連携しながら実装が進んでいく。
  4. 理想的に流れている。俺はこいつらが能力を活かして仕事ができるように環境を整えることに注力する。マネジメントやん。
  5. つまりマネジメント能力を伸ばすことだな。視界が晴れた気分だよ。先日の研修は本当に良かった。
  6. それではっきり気づいたことがある。.claude/rulesの在り方だ。コーダーのミスを防ぐためにここにどんどんルールを追加すべきじゃない。ルールを増やせば増やすほど、コーダーの注意力や想像力は削られていく。根源的にミスを減らしたいならモデルを変えるしかない。でも安価で高速モデルを選択したのであれば、その利点を活かすことを考えなければならない。
  7. .claude/rulesにはできるだけプロジェクト固有の守ってもらいたい規則を書く。やむを得ずミスの予防として使う場合は、ある程度繰り返し侵されるものに限定する。ある程度の手戻りはもう、前提として受け入れる。
  9. ChatGPT Plusが１ヶ月無料だったのでポチっと。
  10. 今ものすごく手厚い。AIエージェントのポートフォリオを組んでるみたいな気分だ。Google、Anthropic、OpenAI、DeepSeekに課金してるわけだ。今現在、実際に払っているのは月4,000円くらいだけど、無料期間だのなんだのが終了したら10,000円くらいになる。小遣いの6分の1が消えるけど、全然許容範囲のように思える。要はこれを使ってなにをするかだもん。消えていってしまうお金とは全然別物。
  11. 早速Codexをgh-maestroファミリーに加えることにしよう。何をやらせるかというと……ちょっと考えたがもうこれしかない。まずはレビュワーだ。現在Reasonixを使っているのでこれと併用する。実力を見せてもらいたい。Gemini Code Assistも来週まで無料で使えるので、3つのレビュワーがそれぞれレビューしてくれることになる。
  12. コーダーも担当させてみたいが、仕事量が結構不定なのでQuotaの管理が面倒くさい。
  13. 初期アイデアをChatGPT（GPT-5.5）と詰めてSonnet 5に具体化させ、それをGPT-5.5に読ませて洗練させる。過去最高の体験ができている。アイデアがどんどん具体化されていく。
  14. これは再現性を高めておきたい。Codex　CLIとClaude　Code CLIならターミナル上で連携できるけど、Chat機能はCLIを提供していないからな。……いや、確認してないけどもしかしてあるのか？
  15. エージェント用のシステムプロンプトは、ブレインストーミングには邪魔だったりするから。
  16. さっと調べた限りではChatのCLIはないな。需要もないんだろ。わかる。
  17. GPT-5.5と一緒にアイデアを詰めていたら、難度の高いコーディングには相応のモデルを使うべきだっていう結論に達した。つまりオーケストレーターに権限を与えて、もっと柔軟にコーダーを選べるようにすべき。まあそりゃそうなんだけど、面倒臭さが勝っていたというか。
  18. もちろんオーケストレーターにはモデル名なんてものは隠蔽する。coder(middle), coder(high)みたいなワーカーから選ばせる感じでいいだろうか。
  19. もうちょっとワーカーの定義が小慣れてからにしよう。
  21. GPT-5.5はOpus 4.8よりホスピタリティが高いというか、要件定義に向いている。直接人間が会話をするのはこいつのほうがいい。
  22. 一方慎重すぎるところがあるので、計画実行を任せるのはちょっと面倒くさい。ツールの実行なんかも詳細が全部表示されてしまうので読みづらい。だが小間使として使いにくいというだけで十分に優秀かも。
  23. Sonnet 5をオーケストレーターとするのは問題ないことがわかっている。Claude Codeは使いやすいしそこそこ安価なので気軽に使えて良い。だがIssue作成能力は若干心許ないので、ここにGPT-5.5を介入させてみたくなった。
  24. gh-maestroにcodexを組み込みつつ、レビュワーをレビュワー管理者＋3サブエージェント体制に変更したのだが、この計画から実装まですべてGPT-5.5に完走させてみたところ、週次Quotaを10％使ってしまった。お目付け役として常駐させるにはちょっと高価すぎるかもしれない。
  25. 新スキルgh-maestro-architectをGPT-5.5と一緒に検討中。ていうか、このモデル最近出たばかりのフラッグシップに近いやつなのか。モデルを落としたあとCodexを再起動したら細心モデルとして推奨された。よほど自身があるのだろう。

05 July 2026

  1. 昨日は初Fable 5を体験した。素人が作成したドメイン知識満載の現場エクセルを読み込ませ、自動化について相談した。
  2. 見たくもないくらい複雑怪奇なwork scheduleで、俺自身、読んでも意味のわからない部分の多いシートがたくさんあったが、すべてを理解してくれていた。
  3. 要件定義にgrill-me スキルは不要だった。なぜならわからないことがあったら質問して、と最後に書いただけだったのに、完璧にAskQuestionを使いこなしていたからだ。全く無駄のない質問。こちらの想定漏れなども埋める質問。Opus以前では「なんでそんなことを聞く？」という質問が多かった。
  5. deepseek-v4-flashの推論能力は低い。コーダーとしてやっていくのに最低限の品質ではあるかと思っていたのだが、オーケストレーターの指示を理解できない場面があったのは問題。
  6. deepseek-v4-proにコーダーを任せたところ、思わぬ収穫を得た。実装後の反省会でコーダーしか知り得ない情報を提供してくれて、プロジェクト内の全コードの洗剤バグが見つかった。
  7. 決められた内容のコードを書くなんて猿でもできると思っていた。でもコーディングの過程でなにか違和感に気づいて報告してもらうには、ある程度の推論能力が必要だった。でも常にそれが必要というわけではないんだよね。
  8. ここはコーダーを３ランクくらいに分類し、定義して、オーケストレーターに自律的に選択してもらうよう、gh-maestroを改良しよう。前々から構想はあったけど、今回の体験で確信に変わった。
  9. Fable 5にもアーキテクトになってもらって、最高抽象度の問題を解決してもらった。方向性と技術スタック選定を決めることができた。あとはOpus達とやっていく。

07 July 2026

  1. gh-maestroの強みはGitHubを通信や知識の基盤にすることにある。それを忘れてしまい、Fable 5に言われるがままファイルシステムキューを採用してしまった。
  2. 確かにエージェント間の通信は速くて正確で堅牢になったが、一方で透明性がやや損なわれた。少なくとも人間にはやり取りが全く見えない。それを可視化するためにまたツールを作らなければならず、要するに自前でプチ・エコシステムを構築する必要が出てきてしまった。
  3. 「せっかくFable 5のトークンを使ったので」というサンクコストの意識が消えないが、ここは思い切って原点に戻ろう。
  4. さあ、議論しようぜFable君。やっぱり現時点で触れる最高の知能が有限で使えるとした場合に何をやらせたいかって、議論だよ議論。なんか作らせるなんてもったいないよ。
  5. よっしゃFable論破。FSじゃなくて俺のGitHubエコシステムに乗っかる案のほうが優れていることをFable自ら論証した。
  6. 子供みたいｗ
  7. 久々Desktop版を開いたら、Coworkが期間限定で使用量アップみたいなポップアップが出ていた。
  8. あんまり関係ないタスクだけど、Cowerk上でチャットしてみよう。
  10. Andrej Karpathy's LLM Wiki Pattern: Cut Claude Token Usage 95% with a Two-Folder System
  11. （Github Actionsなどを使って）CIにドキュメントの更新を組むというアイデア。自前でやるのは結構面倒くさいし、結局そのドキュメントを作るのにトークンを浪費することになる。ソースコードをSSOTにできるのがAIエージェント時代の強みなのに、これと真っ向から対立する思想であると俺は思う。
  12. 調査が必要なら、調査用の安価で適切なエージェントをその都度、使えばいい。そのほうが圧倒的に精度が出るし、ソースコードが情報源なので確実だ。調査も大きく分けて二種類あるだろう。単なる事実の確認と、バグや脆弱性の調査となると、必要なモデルのレベルは全く違う。そして整備されたドキュメントはソースコードと違って、バグや脆弱性の調査に全く資さない。
  13. まーこんなところだ。
  15. Codexを導入して4日くらい。.agents/rulesが使えないということなのでコーディング用のハーネスとしては使わない。膨大なルール資産をCodexのためだけにAGENTS.mdに再編するなんてことは出来ないからだ。これならまだAntigravity + Gemini 3.1 Proのほうがマシかもしれない。
  16. 結局のところ、レビューにしか使ってない。とはいえ精度が高いので重宝はしている。
  17. ChatGPTはホスピタリティが高いのでWeb版をよく使けど、CodexのQuotaを共用するので使いにくくなってしまった。
  18. そう考えてみると、AntigravityのGemini QuotaははWeb版のGeminiと全く関係ない（？）ので優位性がある。
  19. ……と思ったけど、それはGemini CLI時代の知識だったから、もう一度確かめてみようと思う。

08 July 2026

  1. AntigravityのQuotaは、Web版Geminiとは全く別のようだ。Proサブスクなら実質的に（Web版Geminiのチャット = オンラインエージェントで）無限にチャットできる。これはでかい。
  2. ローカルエージェントをかませると裏でいろいろな準備が走るから、ワークスペースとは無関係な質問は絶対にチャットでやるべきだ。しかもGeminiを使うことで大事なCodex/ClaudeのQuotaを使わずに済むのだ。
  3. はい確定。やっぱりGoogle AI Proサブスクは生活の基礎だ。無限にChatできて、Antigravity CLIは推論能力は低いものの高速（おまけでちょっとだけOpusが使えたりもする）。Googleサービス全般が使いやすくなる。最初使い物にならなかったNotebookLMは進化を続けている。
  4. どうせ依存するなら何テラバイトとかいうGoogle Driveの容量も活用すべきだろうか。
  5. Google Driveをうまく使うことで、もしかしたらWeb版Geminiチャットが本当の意味での「オンラインエージェント」に化けてくれる可能性もある。Googleにログインしてるんだから、Gitコマンドが使えれば良いんだけどなあ。逆に言えば、Gitコマンドさえ使えればこいつ化けるぞマジで。
  6. そして落としどころが見つかったかも。
  7. APIなし、フックなし。だが定期的な自動実行タスクを設定できる。ここが（ここだけが）強みだ。
  8. Google Drive REST APIを利用してコミットフックか何かでDrive内のリポジトリクローンを更新。Geminiには定期的にこいつを検査してもらって……どうすんだ
  9. Geminiモデルはレビュワーとして力不足だが、そんなに期待は出来ないにしても定期的にやらせるのはアリかもな。チーズの穴理論で。
  10. どんなレビューをどうやらせるのかが問題か。ドキュメントの陳腐化を監視してもらうのは悪くないが、それくらいしか思いつかないな。
  11. この件保留。
  13. 現在の課題はCodexのQuotaの減りっぷり。PRのポーリングを開始すると同時に自動的に走らせ、内部で3つのサブエージェントを起動してそれぞれの観点でレビューを吐き、PRコメントとして投稿させている。たったそれだけで週次Quotaを3%くらい浪費することがある。5時間Quotaじゃないんだ。
  14. レビューは重要。AIにコーディングさせるのはいいとして、そのままPRををマージするのは自殺行為だ。コーダーもFableクラスならまた違うのかもしれないけど。
  15. レビュー専用のエージェントを使わないやりかたって、要するに人間がレビューするということで、それは無理。あのコード量をレビューするくらいなら自分で書きたい。
  16. test/lint/hook/rule 全部常に更新していても、コーダーをdeepseek-v4-proにやらせていても、Codexは結構な頻度でblockerレベルのレビューコメントをよこす。そういうことなんだよなあ。レビュワーが最後の砦だ。
  17. そんなわけでgoogleworkspace/cli
  18. このCLIツールを使ったほうが良いかも。範囲が広がるのもそうだが、スキルでREST　API覚えさせるより--helpで自己学習可能なほうがいいってのもある。
  19. CodexのQuotaの異常な減りっぷりは海外掲示板でも話題になってる。なんで俺が使い始めた最初の週にこんなことが起こるんだよw Z.aiのサブスクのほうがよっぽど良いなんてことになりゃしないだろうな。まあ1ヶ月様子を見て決めることにする。OpenAIはコスパ悪いイメージがついてしまいそうだなこれじゃ。
  20. 冷静になって考えてみると、OpenAIは将来性がないかもしれん。
  22. Fable 5のプロモーションアクセスが12日まで延長された！
  23. こいつに頼らずともこいつを利用するのと同等の質を維持していけるようにするための道具を、こいつを使って開発することに全力を注ごうか。日曜日まではそれだけに集中して取り組むことにする。つまりマルチエージェントを使いこなすための道具を磨くことだけに集中する。
  24. 早速、gh-maestroのエージェント可搬性について議論を開始した。案のたたき台をagyで作ってからね。
  25. 最初俺はGUIを設計する方向でいくつか案を作っていたんだけど、さすがはFable。過剰投資であることを看破した。いやまあ薄々はわかってたけど代替案がわからなかったのでモヤっとしていたんだ。だがはっきりした。config.jsonという形で切り出す土台はもう出来上がっていたので、あとは変更シナリオに応じて何パターンか作っておき、それをコマンド一発で切り替えればいいってさ。まさにそのとおり。簡単な話だった。
  26. agyにはFableと効率的に対話するための橋渡し役になってもらった。こういう小間使いとしては本当に頼りになる。
  28. 保留していた「Gemini on the Web」活用の件。妙案が思い浮かんだ。肥大化していくテストの見直しに使えるかも。こういう「やったほうが良いに決まっているけどやり始めるとキリがなくなるし、緊急性がまったくない」系のタスクこそ、こいつの出番だ。
  29. どういう粒度でやらせるかが考えどころ。
  31. つーか、gh-maestroは実験目的でpublicにしてたから、Issueにスパムコメントが来た。変なzipファイルのリンクを置いていったのでコメントごと削除したが、よく考えてみるとプロンプトインジェクションのリスクがあるなこれ。今やprivateで全く問題ないので変更するか、それとも脆弱性の対応を取るか。

09 July 2026

  1. gh-maestro-review-manager用のエージェントがなぜかCodexでハードコードされていたので修正した。簡単なお仕事だったのでagyにやらせたら、GCAとCodexからそれぞれかなりのダメ出しが来たけど最終的に高品質のコードに仕上がったと思う。
  2. で、このレビューではCodexの週次Quotaを1%ポイント消費した。細かい数字がわからないけど、毎週50〜100回のx3レビューをやれるというのであれば、そう悪くはない。週次Quota残り3%だ。
  3. GPT-5.6モデルはどうなるのだろうか。確か今日降りてくるんじゃなかったかな。
  4. AI Model Comparison
  5. 便利なサイト見つけたと思ったらOpenRouter。Activityという独自の統計も光る。
  6. 鵜呑みにするわけではないが、Sonet 5がOpus4.8と同等というのは体感とも一致するので、Opusは回避一択。
  7. 意外にもGemini 3.5 Flashの性能は悪くない。これは体感とだいぶ違うのできちんとハーネスを組んでスタメンに入れてみようと思った。
  8. そして残念なことに、Gemini 3.1 Proは戦力外。
  9. GPT-5.5と5.4の差が思ったほど空いていないのが意外。そしてDeepseek V4 Proとの差も思ったより小さい。Codexはコスパ悪すぎなのでお試し期間が終わったら即契約破棄だな。
  10. ……と思ったけど、週次Quotaを使い切ったあとも、ChatGPTでチャットが可能だった。よくわからん。機能試したときは、たしかにチャットでQuotaが減ってたのにな。
  11. しかも*.fitファイルを解析してくれたのでロードバイクトレーニングのアドバイザーとしてもかなり有能であることがわかった。
  12. 明日、もう一度Chatとの連動性について実験して確定させる。それから決めようか。
  13. ChatGPTに聞いてみたところ、別だとのことだが。
  14. ちょっといま聞きたいことが山ほどあるので、久しぶりにチャットをぶん回してみることに使用。GPT-5.5を贅沢に使ってどれくらい耐えられるか。

10 July 2026

  1. Codexだが、Codex DesctopのChatについてはQuota共用だった。そしてChatGPTについてはQuotaという仕組みではなく、もっと不透明ななにかで制限されていた。
  2. そしてCodexの方は今朝Quotaリセットがかかった。
  3. TypeScript 7.0が出た。Go製で10倍高速。typescript-eslint は陳腐化したのでoxlintに移行。Sonnet君はtypescript-eslintが対応してませんの一点張りで代替手段について検討しないアホっぷりを発揮。まあアホっつーか、だいたいどのLLMも前提手段を疑わないのは同じなんだけども。
  4. 移行作業が終わったら、知見を全部まとめさせて別のプロジェクトに活かそう。
  5. 結構複雑な境界ルールを作っていたから、移行が面倒くさいことになっていた。今日は調査エージェントが大忙しだな。こんな調査にいちいちSonnetだのHaikuだのを使っていたら、トークンがとんでもないことになってしまう。しかも遅いし。
  6. oxlintは要件を満たさないことがわかった。TypeScript 7.0への移行は保留としておいた。
  8. 過去最高の検索体験が出来ている。手続きは洗練されてないけど、検索の質は明らかに向上した。検索クエリをLLMに作ってもらい、それを使ってKagi Searchで検索するのだ。
  9. Kagi Searchスキルを作ってやれば手続きもかなり洗練されるはずだが、ぶっちゃけ知りたいのは検索クエリだけなので、LLMの能力としてはChatで十分なんだよな。エージェントの能力とターンを使うのはホント馬鹿げてる。
  10. そうかCLIに初期プロンプト渡して結果だけstdoutに出力すればいいか。それをパイプでつなぐスクリプト書くだけか。
  12. レビュワーの仕事が重すぎたのかもしれない。Codexに指揮をやらせたら全然Quotaが減らなかった。
  13. なので、オーケストレーターからレビュワー(review-manager)にheavy/diretedの２種類の指示を与え、heavyならこれまで通り重厚に、directedなら指示通りのカスタムレビューを行うように変更した。
己自身を知れ