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なら指示通りのカスタムレビューを行うように変更した。
  14. 勢いでCodexに色々やらせてみたけど、話にならんな。rules/を自動で読まないので、数々の規則資産を全く活かせない。いちいち説明しないといかん。skillの遵守度も低い。スキル内にissueのテンプレートが書いてあるにも関わらず、勝手に前例からテンプレートを仕立て上げた。他にも色々だめな点はあるが、まともにテストもできない推論能力の低さも最悪だ。GPT-5.4だけど。自分で勝手に書いたスクリプトでインストーラーを壊し、テストを書かせたら当然失敗するわけだがそれをまともに修正できない。検証方法も頓珍漢。
  15. これ、どう考えても月に20ドル払う価値ないわ。Googleに課金したほうがマシ。Antigravityは.agents/rulesを読む（ことになっている）し、高速だし、Googleサービスとの連携も強いし。
  16. やっぱりAnthropic + Google + DeepSeekの3つを主体にしていくことにする。

11 July 2026

  1. issueを作成するのにアシスタントを用意した。毎回コードベースを贅沢に調査して既存のコンポーネントやユーティリティ関数などを調べさせる。agyが適任。

12 July 2026

  1. さあ、今日でGemini Code Assistによるレビューサービスが終了だ。多分今日の15時前くらいかな。
  2. すごく楽しみにしていたことがある。自前のレビュワーとの質の比較。評論をFable 5と一緒にやってみた。
  3. 総合判定では確かにこちらのreview-manager（Codex + GPT-5.4）のほうが圧倒的に優れていたものの、一部GCAでしかできない指摘があり、その系統が明らかになった。
  4. review-managerの方は、「このコードが壊す普遍条件・失敗シナリオを考えよ」という演繹型の指示だが、これはAPI固有の仕様知識を照合しないと見つからない類の欠陥を見抜くことができない。いくらコードの論理を追っても導出できなかったのだ。
  5. つまり「使っているAPI自体の前提条件を検証せよ」という指示がどこにもなかった。
  6. いずれにせよ、レビュー観点が独立すると発見の深さが上がることは間違いない。
  7. 議論は深まった。レビュー観点を構造ツリーで表現してオーケストレーターが自律的に選択できるようにしてみた。
  8. もうかなり確信に近いんだけど、LLMを使ってプロダクトの品質を向上させるにはスイスチーズモデルの考え方が必須だ。
  10. Youtube大学で６年も前にアップされていた禅の歴史を観た。
  11. 俺が22歳の頃からずっとやっていた寝る前の「陣取り」と似てるなと。
  12. 瞑想の対象は「自分」だけじゃないけど。
  13. 面白かったけど、やはり「禅」を詳しく学ぼうとは思えない。概念を包括した原始仏教のほうが面白そうじゃん。

14 July 2026

  1. 精神を健康に保ちたければ、しっかり寝れば良いんだよ。昼寝とかもしてさ。禅もいいけどまず寝る。
  2. さて。ChatGPT Plusをどうするか問題がまた悩ましくなってきた。
  3. GPT5.6は相談役として今の所最高のコスパを実現する。Web版のChatで使えば、ちょっと面倒くさい部分はあるけど、最新の学習データをもとに良質な回答をくれて、しかもCodexのQuotaは全く消費しない。
  4. これは魅力的だよ。というわけで、.agents/rulesの資産をあらゆるエージェントで利用可能にしてやった。スキルにアセットスクリプトを追加して、関連するルールをコーディング前に読み込めるようにした。
  5. これで、codexだろうがreasonixだろうが、コーダーとして活躍できるというわけだ。
  6. ChatGPT/Codexも、どっぷり依存しきればかなり便利なんだよね。
  7. 特にフロントエンド開発にはCLIよりデスクトップ版のエージェントアプリを使ったほうが捗るかもしれない。
  8. やらないけど。
  9. なんでかというと、一見便利だし確かに開発は捗るけど、確実に囲い込まれるよね。囲い込まれ飼いならされて牙を抜かれる。それよりもオープンな世界でいろいろな道具を自由に使える状態にしておいたほうが良い。
  10. デスクトップアプリは、開発じゃなくて業務に使うのがいいだろう。Claude CoworkとかCodex なんとかとか。名前忘れたわｗ
  12. 自転車通勤は30kmコースを復活させ、週3くらいで結構本格的に練習を初めて2ヶ月。だいぶ戻ってきた。
  13. だが猛暑になりつつあって、L4の練習なんかやった日には汗だくになって職場に到着する羽目になる。濡れタオルで全身吹きまくり、ジャージとグローブは水で濯く必要がある。
  14. で、ジャージのすすぎ方が甘かったらしく、本当に一部分だけから妙な匂いがする。わらい。
  15. そう。昔は酸素系漂白剤がどうとか、乾燥がこうとか、色々惑わされたものだけど、すすぎさえしっかりやっていれば汗の匂いなんて残らないのだ。
  16. 職場にも小さな桶を用意して水をためてしっかりすすぐことにしよう。
  17. 今日はgh-maestroの実装不備が見つかってゼロからやり直させている。自前のポーリングおよびresume起動を利用した堅牢な通信を実装したつもりだったのに、weztermペインのメッセージ送信にデグレードしてた。issueの受け入れ要件にはちゃんと書かれていたので任せきりにしていたのが間違いだった。レビュワーにもcorrectnessの観点をもたせているのだが、受け入れ要件をみていなかったのだろうか、それとも一時レビュワーの起動がうまく行かなかった瞬間があって、そこに運悪く引っかかったのか。まあよくわからんが、ともかく今日は残業して完全になおしてからでないと帰宅する気にならん。
  18. そんなわけで帰りの30/30というL5錬をやるには外が暗すぎて危険な状況になってしまった。
  19. そこでGPT-5.6に相談してみたところ、L5の効果を狙う場合高い心拍数を維持する必要があるので今日はやめておき、低ケイデンスの筋持久力トレーニングに切り替えろと。これならインターバルが細切れになって心拍数が落ちても問題ないらしい。なるほど合理的である。

15 July 2026

  1. ChatGPTのAndroid版でLive機能を初めて使ってみたけど、まるでAIと電話してるみたいにスムーズに会話できた。
  2. 骨伝導のヘッドセットが欲しくなってきた。自転車通勤中になにか質問したりアイデア練ったりできるかも。
  3. あーあ、プライムデー昨日で終わっちまったよ。
  4. CLIの方は、GPT-5.6を使うと一気通貫でgh-maestroの更新を任せられる。gh-maestro自身の不具合を、gh-maestroを使って行うことは出来ないことがあるから助かる。
  5. ただしサンドボックスの利用が前提になっているなど、ちょっとワーカーとしては使いづらい面もある。
  6. つまりこいつはarchitectとして相応しい。Fableはそのうち使えなくなるからな。
  7. どう使うかについても色々考えてきた。
  8. 最初は独立させようかと思ったけど、やはりワーカーの一種として定義する。
  9. orchestratorが起点となるissueをGithub上に作成した後、要件定義をまとめ、調査ワーカーを使ってコンテクストを整理し、それら適切に圧縮してarchitectに渡す。
  10. architectは自由記述方式で実装計画をissueコメントに出力。過程はすべてGitHub上に残る。
  11. orchestratorはそれを読んでissue本文を更新。コーダーを読んでいつもの実装にかかる。
  12. これだ。俺の求めていた理想の形がこれ。
  13. あー待ちきれない。早く実装してしまいたい！終業時間過ぎてるんだけど、やっちまえ。
  14. 実装計画書を書かせた。
  15. Codex CLIは使いづらくて仕方ないので、デスクトップ版を入れた。
  16. ~/.codex/config.tomlのsandbox="unelavated"という記述が問題だったらしい。知らねえよ。
  17. いずれにしろ起動がとんでもなく遅い。こういうストレスが嫌だから可能な限りCLIを使いたいんだよね。

16 July 2026

  1. gpt-5.6-terra、アホなのかな。shellスクリプトの引数の使い方を間違えてて、テストも抜けだらけ。自分自身に判定させたら、Haikuレベルだって言ってた。わらい。architect用のSKILL.mdを設計させたけど、ゴミクズだった。あんなスキルじゃまともに動かない。orchestratorへの通信方法すら未定義で、ワーカーとしての基本機能を継承できてないという散々な内容だった。
  2. これ、とてもじゃないけどarchitectなんて務まらないよ。gpt-5.6-solも大丈夫なんだろうか。不安だ。
  3. 調子が悪かっただけかな。それともgh-maestroに似たプロダクトが存在しないから推論のしようがなかったとか？？
  5. スキルを読んでいるうちに、大きな疑問符が現れた。コンテクストを制限されたarchitectが、果たして能力を発揮できるのだろうか、と。
  6. 理解した。architectに具体的な「実装計画」を立てさせるのは愚の骨頂だった。抽象的な「設計計画」を立てさせるべき。大きな方向性さえ誤らなければそれでいいんだから。
  7. 相談役としてどこで使うかっていうのがまだ決まっていないけど、とりあえずこの体制で開発に使い始めよう。
  9. Claude CodeのQuotaがリセットされた。こういうこと結構あるんだよなあ。しかも結構水曜日あたりに実施されることが多い気がする。
  10. なにか戦略立てようかな。面倒くさいけど。
  11. coder役をAnthropicのモデルで掛け持ちしてみたんだけど、すると5時間枠の減り方が速くて途中で止まるかもしれない不安がつきまとう。これはちょっと嫌だ。
  12. あーあ止まっちゃった。4時間ちょうどで5時間枠使い切った。週次Quotaは9%消費。
  13. 改めて、このコスパはDeepSeekがないと成立しないってことが理解できたよ。週1でQuotaリセットがあったとしても駄目。
  15. coderが行き詰まり、orchestratorが設計判断をarchitectに依頼するという流れが初めて生まれた。ちょっと感動。
  16. sol強え！！
  17. codexインストーラーのバグであるWindowsサンドボックスの問題を、Web検索やらOpenAI関連のリポジトリ検索やらを使って解決してしまった。たしかにこいつはFable級と言って良いかもしれない。
  18. と、思ったら解決できてなかった。わらい。
  20. やっぱりClaude Code CLIが一番安定していて使いやすい。オーケストレーターはこのエージェントしかありえないレベル。頭脳はDS V4 Proでもいいんだけど。
  21. それにしても時間がかかる。中規模のリファクタリングでも丸一日かかる。architectにcodexを利用した際の躓きがあったとはいえ、それを差し引いてもちょっと遅すぎる。

17 July 2026

  1. GitHub REST APIに障害発生。gh-maestroは完全に依存していたのでGraphQLにフォールバックする体制を整えおえたところで、タイミングよく復旧しやがった。
  2. まあ堅牢になったということで。
  3. 最近、AndroidのGitHubアプリで操作したほうが速いことに気づいた。マージとか。PC版はすごくもっさりしている。
  4. Issueを見るとAIエージェントどものメッセージのやり取りが見れる。PR見るとAIエージェントによるレビュー内容が見れる。
  5. 俺もコメントで割り込むことができれば面白いかもしれないけど、勝手にどんどん進んでいく中でタイミングが難しいかもしれないね。

20 July 2026

  1. またGitHubに障害発生。こんな頻度で発生されてはかなわないが、もう今日は諦めるとしよう。

21 July 2026

  1. Antigravityの役目がまた一つ増えた。
  2. 最近Orchestrator（Opus/Sonnet）の報告が具体的すぎて噛み砕いて解釈するのに時間がかかるようになってきた。時間がかかるのは以前から変わらないが、その量が増えてきた。
  3. そこで、Antigravity（Gemini 3.5 Flash）に優しく概要を説明してもらう。これ、こいつの得意分野だと思う。本当良い仕事をしてくれる。質も高いし、根拠もクソもないから正確だし、何より素早い！
  4. なぜ最初からOrchestratorに説明方法を指定しないかと言うと、もちろん情報の劣化を避けるためだ。報告の質は下げないのがポイント。
  5. 問題は、この「役割」をgh-maestroの組み込みワーカーとして定義できていないということだ。つまりおれはいま原始的なコピペ通信を手動で行っているのだ。
  6. どうやって定義すれば良いのだろうか。
  7. まあ概ねPRマージ後の「反省会」の内容が難しくなりがちなので、「反省会」自体をissueコメントとして開催してしまうのが良いかもしれない。そもそも、現在すべてのワーカーは非対話モードで起動するようにしているので、issueに現れないものは議論不可能なのだ。現状、反省会といっても参加しているのは俺とオーケストレーターだけという有様だ。
  8. 「反省会」をissueの締めくくりにしてしまうことで、agyが参加できるようになる。役割は「assistant」だな。issue毎にこいつを起動しておくだけ。つまり、issue起票用のスクリプトに、assistantのspawnを仕込んでおけばいい。こいつとorchestratorのみ、対話モードで起動するというわけだ。
  9. こうすることで、issueに関する状況を理解してもらって、必要があれば即座に俺の質問に答えてもらえるというわけだ。
  10. いままでorchestratorに説明させたりしていたが、これは完全に悪手だった。トークンの無駄遣いにもほどがある。俺の理解力の穴埋めをするのはorchestratorの責務じゃあない。仕事の邪魔をしてはいけない。
  11. これはきっと捗る。git worktree内に移動してnpm run devを実行したいときとか、色々面倒くさかったことも任せられるだろう。多分スキルを定義しておけばコマンド一発でやれる。しかも素早く。
  12. 俺以上にAntigravityの使い方を熟知している人間が居るだろうか。わらい。誰もが使えねーと思っているこいつの、本当の使い途に気づいてしまったかもしれない。
  13. アイデアが温かいうちに基本設計を詰めてしまうことにした。ちと残業になるけどやってしまおう。帰りはVO2maxの予定だったけど、正直暑すぎてやるきにならないんだよ。
  14. とはいえ20:30がタイムリミット。
  15. なんとか5分前にClaude CodeのPlan Modeまで持っていけた。あとはもう実装に入るだけなので明日でいいだろう。

22 July 2026

  1. Gemini 3.6 Flash登場。3.5 Proの度重なる延期で不穏な空気が流れていたが、それを断ち切ろうという話かも。
  2. 知識のカットオフはこの３月。最新のLLMの一つであることに違いないので、早速能力を図ろうと思う。
  3. コーディング向けとのことだが、もともとコーダーなんてのはしっかりとした仕様、計画、ハーネスを作っておいてやればDeepseekのFlashモデルだって仕事をきちんと完遂できる。
  4. やはり真価を見るにはorchestratorをやらせて見るに限る。
  5. で、やらせてみたところ、状況理解は問題なし。ワーカーの呼び出しも出来ている。問題はアセットスクリプトがClaude Codeのモニター機能に依存していたことだ。これはこちらの落ち度。
  6. ただ、やはり推論能力は決定的に劣るようだ。いざというときの問題解決能力に不安がある。
  7. ポーリング用スクリプトがstdoutに状況を書き出しているから、それをfs.writeSyncで書き出すようにすれば、自分（agy）でもClaude Codeのモニターと同じことができると主張しやがった。何を言っているのだろうか。そもそもモニター出来ていないのに、出力先を変えたからなんだというのか。
  8. やはりorchestratorはClaude Code + Sonnet 5が最適だな。
  10. さてgh-maestro-assistantを今日から使い始めている。開発体験がまた向上した。investigatorの詳細なバグ調査結果を抽象的に要約させることで、概要と本質を掴むことが非常に楽になる。するとorchestratorが示してくる方針にたいして、即座に的確な（と思える）判断を下せる。
  11. agyの週次Quotaの減り方が緩やかになった気がする。実際3.6 Flashは出力トークンが安くなったとは聞いていたけど。
  13. なんかGemini 3.6 Flashのベンチが出てるようだけど、全然当てにしてない。簡単なバグの調査をやらせてみれば一発でわかるよこいつの推論能力なんてw
  14. ワーカーたちは、コードの正確性が大事だから自分らで定義した変数名やら関数名を使ってやり取りしてもらって全然構わないんだが、要件定義をやっているだけの人間からしてみたら、読みづらいことこの上ないわけだ。これを抽象的に「翻訳」してくれるのがgh-maestro-assistantってわけ。まさにGemini 3.6 Flashにうってつけ、ドンピシャな役割だよ。めちゃくちゃに速くて丁寧。
  15. こいつは別窓のほうが使いやすい。たまに俺が別のデスクトップで作業しているときに起動されるとそっちに表示されて混乱してしまうことに目を瞑れば、Weztermのペインに居座られるよりも使いやすいと感じている。issueごとに多重に起動することもあるから、使わない窓は別のモニターに待機してもらったりするわけだ。
  16. すると、Weztermである必要性が今やほとんどない感じだ。一応エージェントが動作していることを確認するために、５行くらいの高さのペインをorchestratorの下に割いているけど、それくらい。
  17. いやまあそこ大事か。少なくとも、tmuxの類は俺には必要ないってことがわかった。
  18. あーそうか。orchestratorには、各ワーカーを担当するエージェントおよびモデルを選択する権限を与えて良いのかも。なんで気づかなかった。
  19. この権限さえあれば、たとえばDeepseekが定義するピーク時間帯にはDeepseek Proの使用を避けたり、コーディングの内容によってモデルの思考深度を調整したりってことができる。
  20. まあとりあえず今の状態はかなり安定してきているので、そろそろmainブランチに統合してタグでも付けておくかな。
  21. ていうか、ハーネスがうまく機能してきたからだと思うが、レビューの指摘０件というケースが増えてきた。せっかくGPT-5.6 terraを使っているのに、なんかもったいない気がしてしまう。
  22. ほぼ業務時間内で一日中使って、Claude Code（Anthropic）は15%強。Codexは5%強、Antigravityは10%弱の週次Quota消費。Deepseekのコストは１ドルに満たない程度。
  23. gh-maestro自身の開発はClaude Codeだけにやらせてるのがちと負担なのかな。gh-maestroの開発が一段落すれば、恐らく１日じゅう使って10%ってところだと思う。Codexにはもっとcoderをやらせても良いかもしれないし、Codex Workでなにか業務サポートをさせても良いかもしれない。実行速度を考えると、Antigravityも簡単なコーディングに参加させて良いはずだ。
  24. そうすると、Deepseekのトークンはいざというときのために使わずにとっておける。
  25. Claude Code、Antigravity、Codexの週次Quotaをダッシュボードで一元管理したい。なんかいいアイデアないかなあ。CLIにパラメータあればすぐ作れるんだけど、多分無い。
  26. ChatGPTに相談してみよう。こいつは、まるでスマホで通話でもするかのように相談できるようになった。なぜか外人のカタコト日本語みたいな喋り方なのが気になるが。
  27. 電話相談みたいな形で要件をすり合わせて、とりあえず計画書をマークダウンで出力してもらった。なんか不思議な体験だったなあ。おれAIと普通に会話してた気がする。
  28. こいつ、会議に参加させたらどうなるんだろ。ちょっと気になる。ちゃんと自分の発言タイミングを理解できるのだろうか。
  29. それはともかくとして、知りたいのは、週次Quotaの消費ペースだ。適正なペースで消費しているのかというところが知りたい。１日に週次の15%のペースでまんべんなく消費していくのがベストだ。

23 July 2026

  1. Gemini 3.6 Flashは本当に素晴らしい！使い方を間違えなければ、これ以上の体験をできるLLMは無いと思う。使い方を間違えなければ。
  2. 閃光のフラッシュを思い出したわ。こいつは本当にフラッシュ。速いなんてもんじゃない速すぎる。
  4. gh-maestroはコストを抑えつつも生成物の質を上げるために作った。問題は速度だろう。手間をかけまくるので時間がかかることが多い。ちょっと手動計測でもしてみるか。暇だから。
  5. 7:40-8:15、review-managerのバグ修正。ただしこれはgh-maestroを使えないため、Sonnet 5単独でさっさとやらせた。
  6. 8:15-9:30 、上記バグによってレビュー漏れした3件のPR（マージ済み）を再レビューさせ、見つかった不具合の修正を並列で実行したところ、BLOCKERレベルの実装ミスを連発されて時間がかかった。最初からsenor-coderに任せるべき案件だった。DB周りはV4 Flashには荷が重いようだ。
  7. 9:35-10:30 、不要なトーストが出る不具合の修正。調査段階で一度reasonixがクラッシュした。初めてのことなので様子見。ロス時間含め調査だけで15分かかった。途中、別の問題というかさらに不要なトーストの存在に気づき、issueとして切り出すのにも時間がかかったが、約1時間で完了。
  8. 10:30-10:45 、エラー表示があるのにトーストで二重通知していた問題の修正。レビュー指摘は無視できるものだったのですぐ終わった。
  9. 10:47-11:40（中断）、同様の問題が広報互換性のために残してある別の箇所に発見されたため、修正。これはしゃーない。ただ、原因調査とその対策などを建てさせてみると、根本原因を正そうとするのではなく、表面的な問題を解決しようとしていることが多い。これはassistantがいなかったら面倒くさくて気づけなかったかもしれない。案の定、本来不要な設定ファイルの保存があり、それをサイレント化しようとしていただけで、設定ファイルの保存を中止すればいいだけということに気づけていなかった。バグ調査員が馬鹿だからなのかな。更に途中、review-managerが報告の完了を待たずにクラッシュ。codexでもagyでも。ところが、検証しても再現せず。そんなこんなで1時間近くかかったが幸いBLOCKERレベルの指摘がなかったのでマージはスムーズだった。
  11. GPT-5.6 Sol（ウェブ版チャット）とトレーニングメニューを詳細に議論した。
  12. 知識カットオフは2025年12月とのことで、結構トレーニング理論も理解してるっぽいというか、少なくとも専門用語に関しては俺より知識がありそう。
  13. 検討した結果、バイクの装備を変えることにした。まずタイヤは完全に乗り心地に振る。速く走っても意味ないからな。フロントバッグ的なものをつけることで空気抵抗を上げる。要するにメニューをこなしている途中で道が終わってしまうのをなんとかしたい。
  14. 江戸川の広い区間を使って、レストインターバル中に折り返すというのも目からウロコだった。つーかなんで気づかなかったんだろう。この区間メインにすれば、草ボーボーになる利根川区間のことを気にしなくて済む。
  15. というわけで4パターンの週間メニューが出来上がった。

24 July 2026

  1. Gemini 3.6 Flashにコードレビュー役をやらせてみた。一瞬Codexが不調だったので。
  2. しばらく使っていて問題はなかったが、指摘ゼロ件っていうPRがあって、おかしいと思いCodex + GPT-5.6 terraに同じPRをレビューさせてみたら、BLOCKERレベルではないものの重大な指摘があった。
  3. まあ、そういうことだよなやっぱり。
  4. でも、レビューはトークン食らいなんだよな。GPT-5.6　terraだと減りがすごい。リリース当時は例によって調整されてたから快適に使えたんだけど、案の定キツくなってきた。
  5. 一応、gh-maestro-review-managerスキルを改定して、Quota経済を最適化できるよう、7つのレビュー観点を自律的に引き算できるようにしたんだけど、適切に引き算されているかどうかを評価する機構を入れたらクラッシュするようになったのでrevert中。
  7. GPT-5.6 Solと理想のトレーニングアプリについて語っている。
  8. デバイスが重要。ウェブアプリでトレーニング計画を管理し、それをロードバイクに備えたデバイスで表示、支援する形が理想というところまではわかってきた。
  9. Karooっていうのが良いみたい。自作システムの実行端末として扱えるとのこと。
  10. Garminにはいい加減うんざりだったので、

26 July 2026

  1. Hammerhead Karooという名前だった。2024年発売。前作はKaroo 2だが、Karoo 3という名前にはしなかったのが気になるところ
  2. SRAMがなんちゃらを買収して作ったモデルなので、Shimano Di2とはネイティブに連携できない問題があるものの、Androidなのでやりたい放題。
  3. Gramin Connectに相当するウェブサービスがあるので、それを使ってWebhook経由でCloudflareのワーカーにFITファイルを渡して、あとはもう本当にやりたい放題
  5. 土用の丑の日は、うなぎ代の食材費4000円をもらって自由に好きなものを食べる。
  6. 今年は自作ハンバーガーにした。KEIHOKUというスーパーでちゃんとした合いびき肉、チーズ、トマト、全粒粉パンを購入。Youtubeで知った神レシピで超かんたんなひき肉ステーキを作り、トースターで焼いておいたトマト＋チーズの乗った全粒粉食パン2枚で挟んで食べる。恐ろしく簡単で美味い。バーキンの超でかいワッパークラスのボリューム。食材費は、まあ2000円くらいだけどチーズもトマトもパンも余るからな。
  7. 残念だったのはヒッコリーのバーベキューソースを職場においてきてしまったことだ。このソースを使えば塩分を抑えつつ肉の旨味をさらに引き出すことができたはず。
  8. 来年は絶対に忘れないようにしよう（フラグ）。
  10. 「重力はなぜ存在するのか」っていう本がちょっと気になったので、Amazonでカスタマーレビューを全部開き、Geminiに内容を「復元」させてみた。
  11. たぶん知っていることしか書かれていない。肝心の「なぜ重力は存在するのか」には全く触れられていないらしい。

28 July 2026

  1. 人間が直接扱うエージェントはもうClaude Codeがベストかなと思う。抜きん出たポーリング機能、.claude/rules、Shift+Tabでのモード切替、任意APIキー。
  2. そこで、gh-maestroのorchestratorをClaude Codeに特化させることにした。その代わりWezterm依存を排除する方向。
  3. 各ワーカー（今のところAntigravity/Codex/Reasonixに対応）は、Claude Codeの並列ツール実行としてspawnする。これで管理コストから開放される。見た目が寂しいが、実際のところペインをみていたのは連携の不具合を確認するためだけだった。しかも一部のエージェントは非対話モードかつ標準出力で実行させているとログがきちんと取れない不具合があり、無理にとろうとすると途中でクラッシュしたりして本末転倒だった。
  4. そこでワーカーは並列ツールとして完全にheadlessにしてしまい、なにかログがみたかったらassistantワーカーに中身を読ませて要約させてしまえばいい。自分で読むより捗る。なのでassistantだけは対話モードで起動する。
  5. 今回、Opus 5の実力を見るため、実装のすべてをこいつに任せた。
  6. 伝え方の問題か、要件の詰め直しはあったものの、とりあえず一発で実用レベルの動作を確認できた。やっぱりさすがというか。
  7. このheadless化の改修は、本当にやってよかった。エージェントたちのログをassistantに読ませて作業がスムーズに行われているか分析させたところ、ツール実行の失敗だのなんだのが次々と明らかになった。deepseek-v4-flashモデルがClaude CodeのEditツールの実行を何度も失敗していたり、（実害のない）フォールバック用のメッセージ送信スクリプトがエラーでクラッシュしていたりした。
  8. 無駄なエラーでトークンを浪費させるわけにはいかない。暇なときに（というか大抵暇なんだが）、ワーカーたちの動作を確認させることにしよう。
  9. assistantにはIssueの進行状況を把握しておいてもらいたい。もうエージェントはAntigravity決め打ちでいいや。実際に動かして検討してみたところ、こいつのsub-agent機能を使うことで安定かつ拡張性高く実装できそうだ。
  11. 面白そうなことを考えた。Issue単位を超えるプロジェクトの一般的な設計判断などは、GitHub　Discussionを使って複数のエージェント（ついでに俺も）で議論してしまう。これなら設計判断の「Why」が残るし、なにより蓄積していくことでエージェントの優劣の解像度がどんどん上がっていくかもしれないのだ。これは面白い！
  12. まず、よーいどんでそれぞれ案を出してもらった後、全員に総合評価をしてもらう。assistantにまとめてもらえば、その時の優劣なんてすぐわかる。
  13. フローどうしようかな。俺がdiscussionしろ言ったらorchestratorが基盤となるGitHub Discussionを作り（かつ自動でassistantがspawn）、３名くらい召喚して初期案を出させる。全員分揃ったら、３名それぞれに通知を飛ばし、それぞれの案を評価させ、かつ改善案を再投稿させる。
  14. おれはassistantの力を借りて外観を掴む。こんな感じかな。
  16. それより先にやるべきことが残ってたわ。gh-maestroの本来の目的。これが大事なんだ。Quota経済と質の両立、まあ簡単に言ってしまえば、安いコーダーで如何に質の高いプロダクトを作り上げるか、である。
  17. 安いコーダーといっても限度はある。一時期Gemini 3 ProをJules上で動かしていたときは、結構良い結果が出ていた。なんだかんだ言っても、あの頃が最もコストパフォーマンスが高かった気がする。
  18. まあその後モデルが崩壊してしまってJulesのハーネスがどうこうっていう次元ではなくなってしまったんだが。
  19. それはともかく、あの頃何をしていたかを考えてみた。
  20. そう、詳細なissueを「オーケストレーター」であるGemini CLI　+ gemini-3-pro-preview がマークダウンしてpushし、それをJulesに読ませ、かつ、Julesが実装計画を書いて、それをGemini CLI側が確認して、GOサインを出していたんだ。
  21. コーダーが実装計画を書くってのが大事なんだ。
  22. 最近、DeepseekによるPRはBLOCKERレベルの指摘が相次いでいて、レビュー負担が大きい。これなら最初からレビュワーのTerraに実装させたほうが安上がりなんじゃないかと思うくらいだ。
  23. 実装計画を書かせ、それを適切に評価できれば、手戻りもぐっと減るはず。いまはIssueにオーケストレーターが簡単な実装計画を書いてしまっている。この形はLLMのアンチパターンに似ていないか。自分で定義した要件に対して、自分で計画を立てる。つまり自分で実装して自分でレビューするアンチパターンと同じ構図だ。自分で定義した要件について、コーダーという別のエージェントに計画を立ててもらう。まずはこの形を作ろう。
  24. 今日は天気が崩れそうなのでもう帰ろ

29 July 2026

  1. gh-maestroは自分自身の開発にgh-maestroを使わなかったので、バイブコーディング気味だった。
  2. ふと設計に目をやってみたら、結構汚い。機能決めた大きな機能追加の前にリファクタリングしておこう。
  3. Claude　Codeだろうがなんだろうが、ちょっと目を離すとすぐにDRY原則から外れるというか、いやもうそういう次元じゃなく、それまでの設計原則なんてまるで無視した、その場しのぎのコードを量産しがち。
  4. これはまさに、実装計画段階で弾くべきだな。俺は成果物のレビューはAIに委譲するが、この実装計画のレビューはやる。いまのところ人間が介在すべきはここだ。
  5. 世の中狂ってる。ループエンジニアリングがどうとか、馬鹿じゃねえの？？？
  6. いかに楽しく、簡単に、安く、質の高いプロダクトを継続的に作れるか、そこだろが。
  7. 自分自身を置いてけぼりにしてしまったら、継続性なんて無いよ。人間の創造性が「ループ」から外されてしまったら、どんどん腐っていくに決まってる。ホント馬鹿ばっか。知ったことじゃないけどさｗ
  8. AIを使いこなしているつもりでslop（糞）を撒き散らすだけ撒き散らし、長期的に自分たちが馬鹿になって自滅する。――馬鹿でしょ。あとにも先にも馬鹿ｗ
  10. 昨日、ものすごく久しぶりに帰宅後にローラーをやった。SSTレベルで滞留は系30分ちょいの普通のワークアウト。
  11. 20:00くらいに終わってシャワーを浴び得て夕飯を食べて、しばらくくつろいでいたら眠くなり、20:00にはもう完全に意識がなかったと思う。
  12. いつものように6時間で一度目が覚めたが、二度寝して5:45に離床。7時間30分くらい寝たことになるだろうか。やはりこれくらい眠れると体調が良い。
  13. これからもなんとかして7時間30分眠れるように工夫していきたいと思った。
  14. まず通勤路でのワークアウトは帰りにやる。行きはL2で流すだけにする。
  15. 帰りは暗くなることも多いので、江戸サイのクソ広い道路でやる。別に往復したって良いんだし。
  16. 雨天は積極的にローラーをやる。帰宅後にやる。
  17. 疲れた体で食事をして、寝る。
  19. gh-maestro、かなり良い体験になってきた！開発サイクルに自分が参加している感覚が強い。やっぱりassistantのホスピタリティに注力したのが効いてきたのだろう。
  20. 今何が起こったかというと、assistantが「orchestratorが調査エージェントを使って何かを調べ始めたが、解説しますか？」と聞いてきてくれた。頼む、と返事をしたら、どうやらこれからコーダーに指示する際にプロジェクトに既存のコーディングスタイルなどを調査させていたとのこと。
  21. だが、orchestratorがsenior-coderを起動したことをassitantは知らなかった。こいつが（サブエージェントを使って）監視しているのは、あくまでも対象となるissueの動きだ。ここにコメントが投稿されたときにそれを検知する。まあそれはそれで良いんだけど、よく考えてみたらorchestratorの動きを知っていてもらいたいんだよな。
  22. これをAntigravityにやらせるのは結構難しい。対話モードのorchestratorが仮にログファイルを吐けるとして、その更新を検知してなにかアクションを起こすのは無理筋。トークンの浪費が半端じゃない。
  23. トリガーはユーザーによる発言またはスラッシュコマンドにするのがベストかな。このトリガーでassistantはorchestratorの現在の発言を取得し解説を始める。
  24. いやいずれにしても、この用途ならAntigravity+Gemini 3.6 Flashは、他のどのエージェントよりも優れた仕事をする。ここに気づいた人って居るかな？ そしてこの仕事の価値の高さに気づいた人、居るだろうか？
  25. 何も考えないし、何も作らない。ただissueやそのコメントに書かれた事実をわかりやすく人間向けに言い換えるだけのお仕事。issueの更新を拾うのはアセットスクリプトを渡されたサブエージェントがやってくれる。
  26. gh-maestroの弱点はGitHub APIサービスがコケると共倒れってところだな。一応ログファイルを使って通信はできるから「共倒れ」とまではいかないが、正直やる気がなくなる。
  28. gh-maestroの新しい体制でいくつかサイクルを回してみたけど、このassistantはマストだね。断言する。人間の理解がボトルネックになるAIエージェントによる開発においては、仲介に専念するだけの高速なモデルがマストだよ。さもなくば人間が置いてけぼりになる。

30 July 2026

  1. レビュワー役にGPT-5.6 terraを使っているが、ちょっとコストが異常だと思ってログを調べさせたところ、サブエージェントそれぞれがnpm test（全体テスト）を行っていたり、そもそもサブエージェントの起動に失敗していたり、報告用JSONの構築に失敗して右往左往していたり、色々問題が見つかった。

31 July 2026

  1. GPT-5.6 Lunaが80%お安くなって、DeepSeek V4 Proの存在意義がなくなった気がしたので、senior-coder役をLunaに任せることにしてみた。
  2. ただしハーネスがCodexだから、rules資産を活かしきれない可能性はある。一応gh-maestro側で変更予定のファイルを把握して関連ruleのリストは渡してやる設計なんだけどね。
  4. Solとトレーニング計画を立てて昨日から実行している。初っ端からHIITでしびれたけど、早速心肺機能が大幅に改善した。改善したというか、まあ2年前に戻っただけだけど。
  5. 春の段階では200wが閾値化かっていうくらい心拍が上がってたけど、今朝はL2の、どちらかというと下の方で維持できた。
  6. 俺の弱点は、3分とか4分とかのL5に苦手意識があって練習を回避していることらしい。言われてみれば仲間と一緒に峠で練習するとき以外、まとまったVO2maxの刺激を入れていなかった。ここ数年ずっとだ。
  7. 実際やってみると、思ったほど苦しくもなかった。いや苦しいは苦しいんだけど、限界とは全然違うし、同じ間隔のレストでしっかり回復する。
  8. で、得意な40+20とか30+30とかは、向上ではなくて維持に使うんだとのこと。でも4分を4セットはきついから、前半(30+30)*8, 後半4分*2
  9. 更に話し合っていたら、良いこと思いついた。GitHubを自分専用のAI可読なトレーニングデータベースにしてしまう！
  10. ChatGPTにGitHubという公開プラグインがある。これは読み取り専用だが、おれはFITファイルをpushするだけで、まあpre-commitでもActionsでもなんでもいいんだが、ChatGPTが読み取れるJSONに変換してやって蓄積していき、ChatGPTはそれらを自由に参照できるっていう寸法だ。
  11. FITファイルをローカルに置いたら、daemonなり何なりがpushするようにしておけば、おれはStravaもしくはGarmin ConnectからFITファイルをダウンロードして特定のフォルダに配置するだけでいいってことになる。なれればそう大した手間じゃないし、簡単なChrome拡張を作ればさらに楽になる可能性もある。

05 August 2026

  1. gh-maestroがかなり安定してきた。今は日々、各ワーカーがより質の高い仕事をするためにプロンプト（SKILL.md）の細かな調整を行っている。多少不格好なところを直したら、mainブランチに統合してタグつけとこう。
  2. 設計上の重要な決定を行うとき、特にスタートアップの際に、信頼できる複数のエージェントで議論する場を作りたい。先月構想として温めていたやつだ。
  3. 今日、ウェブ版のClaude Opus 5と同じくGPT-5.6 Solを使って手動で議論させてみたところ、質の高い成果物が出来た。それぞれの案がそれぞれに批判され、互いにブラッシュアップしていく様子を見ていたら、これをもっと手軽に頻繁にやりたいと思ったのだ。
  4. gh-maestroを拡張するので、GitHub Discussionsを利用する。.gh-maestro/config.jsonに議論参加者の定義を書いておく。あとはorchestratorが（自分は議論には参加せず）仕切る形を取らせればいい。
  5. 高価なモデルを使うことになると思うので、共有させるコンテクストはorchestratorが事前に用意し、念の為共有のGit WorkTreeで作業させるのが安全だ。orchestratorのスキルとして定義するのではなく、独自のスキルとして定義しておいて、必要に応じてorchestratorがそれを使う形にすればいい。
  6. 質の高いプロダクトを作りたいなら、Fable 5に全部任せれば良いのかもしれないが、そうも行かない。だからgh-maestroのようなオーケストレーションアプリが必要なのだ。
  7. これを自前で用意するということは、いろいろなエージェントの特性を嫌でも知ることになる。これは大きなアドバンテージだ。
  8. いま、目に見えてコスパが良くなったのは、Deepseek V4 Flash。もうびっくりするくらいレビューでBLOCKERを食らう確率が下がった。review-managerが動作不良起こしてんじゃないかと何回も確認した。
  9. ハーネスはやはりClaude Codeがいい。これは変わらないとして、モデルが問題だ。Soneet 5がみんなの足を引っ張る側に回り始めている。
  10. 余裕がある週は、Opus 5に切り替えてみようと思う。

06 August 2026

  1. プロンプトエンジニアリングというのはほぼ、死語になってきたかなと思う。
  2. 同じプロンプトでも出力はモデルで全然違ってくる。モデルは進化し続ける。そもそもモデルは大量にあってそれぞれ違う特性を持っている。
  3. 純度の高い要件を書くことが大事で、本当は要件ではない、いわゆるニーズではないディマンドを伝えてしまうと、モデルの能力を削いでしまう。本当はもっと良い方法が訓練で学習され済みだったのに、ユーザーの要らん指示を守ろうとして迂回する羽目になるということが普通に起こる。
  4. 例えばレビュー観点とかがわかりやすい。レビューしろとだけ伝えた場合、非力なモデルはろくな出力にならないが、優れたモデルは十分な出力を得られるかもしれない。プロンプトよりもオーケストレーションを工夫したほうがいい場合も多い。複数のエージェントでレビュー合戦をする、トリアージをする、といった具合だ。
  5. だが懐事情にもよる。

08 August 2026

  1. gh-maestro-councilワーカー定義完了。GitHub Discussion上で議論させる主体となる。
  2. 試しに2回ほど議論させてみた。GPT-5.6 Sol, Gemini 3.6 Flash, DeepSeek V4 Flashだ。
  3. 議論と言ってもトークン浪費が怖いので、議題について意見をそれぞれ出させ、どの意見が最も優れているか、投票させるだけにとどめている。結果……
  4. 驚くべきことに、2回ともDSV4Flashが最多得票で勝利。
  5. 予想したとおり、2回ともGeminiは1票も得られなかった。

11 August 2026

  1. 転生重騎士おもろい。
  2. 誰も知らない価値に自分だけ気づいていて、それらを手に入れる際のハラハラする感じが（自分には）新鮮。
  3. だめな要素もすごく多い気がするんだけど、そういう諸々がどうでも良くなるくらいには面白い。
  4. 主人公、駆け引きが下手でアイテムの値段をふっかけられたり、有能な仲間をスカウトするチャンスにがっついて不審に思われたり、目が離せない。
  5. 原作読んでないけど、読み始めたら大人買いで一気に読んでしまって楽しみが消えそうなので、まだ控えておこう。

12 August 2026

  1. Claude Code ProのQuotaに余裕があったので、Deepseek V4 Flashが担っていたコーダーをSonnet 5にやってもらったら決められた手順を守らないわ、5時間Quotaを2時間で使い切るわ、ろくなことがなかった。

15 August 2026

  1. DeepSeekの値上げが確定した。
  2. 明後日より、Flashは0.007$/100M。ピーク時は2倍だ。
  3. こいつはコーダーとして優秀で、特に出力するログに豊富な情報を残してくれたため、gh-maestroで追跡が可能だった。まれにスキルの命令違反を起こしたときなども、その理由を知ることができた。
  4. 一方、まだ良くわからない部分も多いが、一昨日登場したGemini 3.7 Flashが高コスパらしい。
  5. こいつをメインのコーダーにできれば助かるんだが、ろくにログを残してくれないのが残念なところだ。

22 August 2026

  1. ループエンジニアリング sucks
  2. 世の中が完全自動化なる怠惰な悪夢に魅了されている間に、おれはコスト削減と質の向上、および長期的な「人間」の能力の維持に全力を注ぐぜ。
  3. 今特に力を入れているワークフローは、コーダーの報告方法。これまでPRを作ったりコメントを投稿させるのにgit/ghコマンドを使わせていたが、全廃。すべてスクリプトの責務にする。PRのタイトルや本文は自動生成して責務から外す。コーダーにはとにかくコーディングに集中してもらう。
  4. CIにテストを組み込むのはやめた。それはエージェンティックなワークフローには不要。だって、コーダーが自分でテスト結果を使えたほうがずっと有益なんだもの。コミットして気づく、なんてコマンド一個無駄なだけ。
  5. ただしテスト結果がどうだったかという報告はさせる。
  6. コーダーには計画を立てさせているが、更にその計画の裏付けをエクスプローラーという調査用ワーカーにやらせる。今のところ「車輪の再発明」をやっていないかチェックするだけだが、今後いろいろな課題が見えてくると思うので、少しずつ仕事を増やしていきたい。
  7. もう一つ重要なのが、アシスタントの設計。こいつはワークフローの状況、エッセンスを理解するために使うワーカーだが、たんにわかりやすく説明させるだけでは足りない。ユーザーを学習に導く方向を目指したいと考えている。具体的なアイデアはまだ出ない。なにせ現状、担当モデルがGemini 3.7 Flashなので制約がきつい。最重要課題ではあるんだが、保留せざるを得ないというか。

26 August 2026

  1. Gemini 3.7 Flash登場から１週間以上かな。化けの皮がもう剥がれた。
  2. かんたんなコーダーの仕事もまともにできない。BLOKER３件ってもう実装失敗だろこれ。
  3. 実際は４件だったんだけど、計画の落ち度も関係してたんで、おまけで３件。
  4. Opus 5もいうほど賢くない。Fable 5と比較してしまうと、差は歴然だよ。
  5. なんだかまだまだ難しいね。理想の環境は遠いわ。
  7. Weztermを使い続けていて良かった。オーケストレーションには現在全く使わなくなっていたけど、下ペインを15％くらい割いて、全ワーカーの健康状態やら稼働時間を表示するようにしてみたんだ。
  8. これはかなり便利。どういう不具合が出るかなんてわかったもんじゃないんだから、もう視覚的にみておくしかない。
  9. いつの間にか死んでたっていう事故はかなり減ってはいるものの、ゼロじゃないし。それにパフォーマンスだって観たい。
  10. オーケストレーションアプリを使ってるっていう実感が違うよやっぱり。まあ対話型のエージェントをペインに全部表示してたのは完全にやりすぎたしトークンの無駄遣い時間の無駄遣いだったけど、なにも可視化されないのも嫌だったからね。
  11. いま、コーディングはCodex Lunaのxhighとmaxに頼り切りな現状だ。BLOKERをもらうことも少ない印象。計画段階でAntigravityに適合性の調査をしてもらっているので車輪の再発明をしなくなった。
  12. いろいろなエージェントで力を合わせて、質の高い製品を仕上げたい。
  13. パフォーマンスに影響が出ない範囲で、下ペインにワーカーのステータスも表示させるよう、今orchestratorのOpus　5に指示を出した。

27 August 2026

  1. Synology Chatを業務用Slackの代わりに使っている。Slack用の予算が降りるような会社じゃないし、まあ色々あってそうなった。
  2. Synology ChatのBot機能を使って、非対話型のCodex CLIを経由した応答型アプリケーションをいくつか作ろうと思う。
  3. NASにSSH接続して、Codexを使えるようにしてみた。作業手順はChatGPTのSolと確定させAGENTS.mdを仕上げて、実装はNAS上の対話型Codex CLIにやらせる。WeztermでコンテナにSSH接続すれば、いつもと同じように使えた。ただし、auth.jsonみたいなのをローカル端末の方で専用に新規作成してコンテナに配置してやる必要があった。
  4. NASのLinuxが何のディストリビューションなのかさえわかってない。エージェントに頼り切りの突貫作業になっている。ca-certificates（CA証明書）のインストールが必要なレベルでLinuxの構成が謎。

29 August 2026

  1. ハーパー生化学32版を借りた。
  2. 意味なかった。
  3. ChatGPTが33版の知識を持っている。
  4. それだけじゃない。33版のケトン体に関する解釈がどう変わったか質問してみたら、現代的な理解との不整合まで指摘してきた。
  5. 不明な点を質問しながら、代謝に関する知識をどんどん伸ばしていける。
  6. 何という時代になったんだろう。
  8. ChatGPTのChrome拡張は、Codexのエージェント使用量を消費するかもしれない。まあ気にするほどの影響はないかもしれないけど。

30 August 2026

  1. このところAIが「〜に寄せる」という言い方を好むようになった。最初はうまいこと言うなと思ったものだけど、しつこくて鼻につくようになってきた。
  2. r/japanlifeが面白い。
己自身を知れ