AIの船に乗っちゃった

最近、主力の harness を Oh My Pi に替えた。モデルを縛らない点が気に入っている。同じワークフローの中で自分でモデルを選べるので、「Codex は GPT、Claude Code は Opus」といった既定の組み合わせに乗る必要がない。モデルとそれを呼び出す環境は別の速さで変わる。選択も分けておきたい。

ついでに、自分の癖も片付けている。特定の harness でしか動かない hook や skill は、その場では便利でも、環境を替えると荷物になる。これからは汎用的なコマンドやスクリプトを優先して、特定の harness に詰め込まない。次にツールを替えるとき、移行の借金を抱えずに済む。

素の pi は私には少し素っ気ない。OMP はそこに必要な一層を足してくれる。最初から使いやすく、二次開発もしやすい。Prowl を作ったときと同じで、自分の癖に合わせて少しずつ変えられる harness が好きだ。

5月に、自分の fork である Prowl に、すべての agent セッションをまとめて管理するビューを入れた。するとその一、二日後に Claude Code も自前の agent view をリリースした。かぶったのは事実だけれど、ひとつの見立ては裏づけられた。複数の agent を並列で走らせるのはもう日常で、「それらをどう管理するか」が独立した領域になりつつある。

同じ問題に対して、今では少なくとも三つの解き方がある。Claude Code の agent view は組み込み路線で、左矢印を押すだけで会話を切り替えられる。ただし面倒を見るのは自分のところだけ。herdr は tmux 路線で、Rust 製の単一バイナリがターミナル内にワークスペース、タブ、ペインを開く。agent はバックグラウンドで走り続け、必要なときにいつでも attach して戻れる。Prowl は GUI として、Claude Code や Codex といった異なる agent を同じウィンドウに入れ、スクリプトボタンや diff view を添える。

使ってみた体感としては、個々の agent 間の能力差は縮まりつつある。本当のボトルネックは人間側に移ってきた。誰が入力待ちなのか、誰が終わったのか、誰が詰まっているのか。そうした状態が増えると、ターミナルのタブと頭の中の記憶だけではもう捌ききれない。コックピットが解決するのは agent の問題ではなく、自分自身の注意力をどう配分するかという問題だ。TUI か GUI かは、無理に陣営を選ぶ話でもない。エディタ選びと同じで、手になじむものが正義だ。

今日は agent に自分の X タイムラインを少し取得させたくて、手元の軽量な方法をひと通り試してみた。fxtwitter の API は profile のメタデータしか返さず、ポストは取れない。Jina Reader は x.com ドメイン全体が封鎖状態で、以前誰かがある大物アカウントのホームに対して使いすぎ、リスク制御に引っかかったらしい。結局、agent-browser と完全な Chromium の組み合わせで一発通過した。代償として、まず 100 MB 超のブラウザエンジンをダウンロードすることになった。

この件で面白いのは、agent 向けに作られた軽量ヘッドレスブラウザが最近たしかに増えていることだ。ブックマークに入れていた Obscura は Rust で書き直され、メモリ使用量は 30 MB、Chrome より十倍軽く、反検出機能まで内蔵しているとうたっている。Zig でゼロから書かれた Lightpanda はミリ秒単位の起動を売りにしている。方向性には完全に同意する。agent が Web にアクセスするのは高頻度の動作で、数秒のタスクのために Chrome 丸ごとを背負うのは、たしかに贅沢すぎる。

ただ、今日の実践からはもう少し冷静な判断も得られた。x.com のような硬い対象では、「本物のブラウザらしく振る舞う」こと自体が中核機能であり、反スクレイピングシステムが検出しているのは、まさに軽量化で削られた部分だったりする。軽量ブラウザの上限は Web API のカバレッジで決まり、それを埋めていく工数は、実質的にブラウザをもう一度作るのと大きく変わらない。なので今の使い分けは階層化している。静的ページは curl や reader 系サービスで済ませる。一般的な動的ページなら軽量案に一度チャンスを与える。ログインウォールや反スクレイピングに当たったら、おとなしく完全なエンジンを使う。減量は理想だが、最後の支えになるのは体重だ。

「夫れ事は独り断ずべからず、必ず衆と論ずべし。」—— 聖徳太子『十七条憲法』第十七条。最近 argue という小さなツールを作った。複数の AI エージェントに、同じ問いをめぐって構造化された議論をさせるためのものだ。きっかけは単純で、同じ技術設計や同じ PR を異なるモデルに渡すと、気にする点と切り口がまるで違うことに気づいたからだ —— Claude は設計レベルのリスクを見抜き、Codex は実装の細部にこだわり、Gemini はまた別の次元から盲点を見つける。一つのモデルにしか聞かないと、より精緻なプロンプト調整が必要になり、余計な認知負荷がかかる上に、ほかの視点も見落とされがちになる。

argue がやるのは、その「角度の差」を明示的に同じテーブルに乗せることだ。設定したエージェント（Claude / Codex / Gemini / OpenCode などの任意の組み合わせ）がまず独立に意見を述べ、それから互いの主張を検証し合い、立場を統合し、最後に投票で結論を出す —— 最終的には根拠・異論・主張ごとの信頼度スコアが揃った結論が返ってくる。最近は技術設計レビュー、コードレビュー、重要な意思決定にこれをよく使っている。決めるのはあくまで自分で、argue は違うモデルの視点と食い違いを一度に並べてくれるだけだ。

狙いは「AI に多数決させて平均を取る」ことではない。むしろ最も価値があるのは、統合できなかった異論 —— あるモデルだけが見抜き、他のモデルも反論できなかった角度のほうだ。MIT ライセンス、ぜひ遊んでみてください、Star もお待ちしています。

ローカルのワークフローでは、Git をほぼ jj に切り替えて、数か月継続して使っています。体感はかなり良いです。いちばん大きいのは「コマンド数が減った」「操作が速い」よりも、バージョン管理の心智モデルが今の開発リズムに合っていることでした。

Git は非常に優れたツールで、20年以上にわたって協業を支えてきた実績があります。ただ、その前提には一世代前の開発運用モデルも含まれています。agent 時代になると、日々の操作や履歴の扱い方の要件が変わってきて、私にとって jj は思考の流れに沿いやすく、履歴整理もしやすく、頻繁な反復と巻き戻しにも向いています。

これは Git を否定する話ではなく、いまの自分のワークフローに合わせた選択です。バージョン管理を見直しているなら、こちらの完全版もどうぞ：jj for Agent Era。実践の細部と判断の根拠をより詳しく書いています。

AI によってソフトウェア開発の希少性は変わった。汎用機能はますます手に入りやすくなり、本当に希少なのは「自分のワークフローに合った版」だ。

以前、二次開発が難しかったのはコードが書けないからではなく、既存コードを読み解き、変更の境界を判断し、リスクを管理するコストが高すぎたからだ。「本当はここを変えたい」という要望の多くが、最終的にコストに押し戻されていた。今は違う。成熟したオープンソースを Fork し、AI で理解と改造を助ければ、ハードルは明らかに下がり、効率ははっきり上がる。

これが「上流に貢献する」ことが唯一の答えでなくなった理由でもある。多くの要望はもともと私的だ。個人の癖、チームの流程、インタラクションの好み、さらには作者の理念との衝突まで。公共のデフォルトには向かないが、自分のブランチに置いて継続的に磨くには最適だ。

私の fork Prowl も同じだ。基盤は元プロジェクトを踏襲しつつ、高頻度の体験改善だけを入れている。例えばスクリプトボタン、ショートカット、diff view。単体の変更は小さいが、組み合わさるとツールは「使える」から「手になじむ」へ変わる。

私はますます、オープンソースの土台 + AI カスタマイズが次の段階で非常に主流になると信じている。ソフトウェアの核心は、「作れるかどうか」から「どれだけ自分に似ているか」へ移りつつある。

最近、OpenClaw を「ひとりの助手」として使うことが減ってきました——むしろ、育てられる“チームシステム”のように感じています。同じマシンに複数の猫娘を置き、役割を分担させて、お互いに協力してもらうのです。

この仕組みを本当に「チームらしく」するために、各 agent に独立した GitHub の身分（例えば onevclaw）を用意し、それぞれの名義でコードを書き、コミットし、レビューし、さらには日記（claw.onev.cat）まで書かせています。共同作業的なコミットの多くは Co-authored-by: で履歴に残して追跡できるようにし、彼女たちの貢献への敬意も込めています。

通信面もいくつか研究しました：agent 間にセッションの通路を設け、Claude の Agent Team を参考に、ファイルシステムとポーリングで猫娘チームの対話モデルをシンプルかつ効果的に保っています。最も面白いのは相互レビューと「吐槽大会」かもしれません：一匹が実装を担当し、別の猫娘たちが査読してツッコミを入れる。異なるモデル、異なる性格はしばしば異なる盲点や嗜好を生みますが、同じフローに入れてしまえば、より安定的で包括的な結論にたどり着きやすいのです。

これは長期的な実験に近いものです：多 agent 協作は次の段階の主要な形になっていく可能性があり、複数の agent を指揮する能力も自然と重要になっていくでしょう。この仕組みが最終的にどんな姿に進化するかはまだ分かりませんが、過程そのものが確かにとても面白いと感じています。

これまでは、プロジェクトを書くとき頭の中にいつも明確な受け手がいた。ユーザーは人、読者も人、開発者も人。機能設計やドキュメントの書き方、公開の仕方は、デフォルトで「人がどう使うか」を中心に組み立てていた。

最近小さなプロジェクトを作った：TransCrab。これは私が初めて、本気で「最初のユーザー」を人から agent へ切り替えた試み——正確には OpenClaw だ。

人がやることはごくわずかに圧縮される：OpenClaw にここにプロジェクトがあること、望む結果、そしてそれをインストールして動かすことに同意することを伝えるだけ。残りのインストール、設定、ワークフローを本当に通す面倒な手順は、ほぼすべて任せられる。さらに面白い（そして突飛な）ことに、TransCrab は最初から最後まで OpenClaw が「書いた」——私はチャットアプリ越しに方向を示し、判断だけを下していた。

この体験は私にとってとても新鮮だった。初めてはっきり感じたのは、私は「人のためのツール」を作っているのではなく、「agent のための能力」を作っているということ。ドキュメントを読み、スクリプトを走らせ、判断し、自分で保守し、さらにコールドスタートでもデプロイの流れを本番まで押し上げる——私は横で見て確認し、方向を修正することの方が多い。

この体験をもう一歩先へ進めて考えると、もっと面白いことが見えてくる。たぶん近い将来、「プロジェクトを書く」こと自体がますます協業に近づく——人間は意図と境界を明確にし、agent が実行と保守を引き受ける。さらに agent が別の agent のために能力パッケージを用意し、彼らが自律的に調整し、連携し、最後には一つのシステムを立ち上げて長期運用するかもしれない。人間は、一本一本ネジを締める人ではなく、願いを提示する人に近づいていく。

TransCrab はほんの小さな探索にすぎないが、私は初めて本当に未来を見た：ソフトウェアはますます agent 向けに書かれ、agent はますます人間の代わりにソフトウェアを書いていく。そう思うと、むしろ少しワクワクする。この道はまだ始まったばかりだ。

Chroma（Swift のターミナル向け構文ハイライトライブラリ）と ca（cat のハイライト代替）で記録すべきなのは機能ではなく、AI が性能最適化の価値を拡大した点だ。継続的な benchmark 主導の反復で、tokenizer と renderer の性能はおよそ 10 倍まで押し上げられた。

やり方は単純だ。benchmark を一等市民として扱い、AI にコードを読ませてボトルネックを探し、案を出させ、理論的に効果を見積もる。毎回小さな変更だけを行い、すぐに計測して次へ反映する。最適化は「仮説—検証—修正」の科学実験になる。AI の価値は天才的な微調整ではなく、試行錯誤のコストを下げ、最後までやり切れるようにする点にある。

代表的な最適化もそれを示す。tokenizer/renderer を batch パイプラインから streaming に変更してメモリとコピーを体系的に削減。ASCII が支配的な入力には fast-path を用意し、非 ASCII では安全経路にフォールバックする。どれも「ひらめき一発」ではないが、細かな変更と検証が必要で、まさに AI が担う部分だ。

だから「早すぎる最適化は万悪の源」は AI 時代に再解釈が必要だ。かつて早期最適化を避けたのは試行錯誤が高コストだったからだが、AI ではその負担が下がり、多くの最適化を前倒しで設計し早期に検証できる。早期最適化は工学的合理性に反するどころか、効率的な道だと感じている。

最近、MCP (Model Context Protocol) の使い方を見直している。プロトコル自体はとても強力だが、ローカルで多数の server を動かすのはやはり重く感じるし、agent の context window にとっても負担になる。そこで原点に立ち返り、できるだけ CLI ツールを直接使って AI から呼び出す方針を試し始めた。

例えば Jira CLI で JIRA のタスクを処理したり、AXe でシミュレーターを操作したりする。理由は単純で、server を走らせる必要がない、クリーンな binary、管理が楽で意味が明確 ということだ。CLI をそのまま skill に置き、CLI 自体のヘルプが十分に優れていれば、追加の説明なしでも agent を超熟練にできる。

いまは Vibe Coding の後押しもあり、足りないツールがあれば自作 CLI くらいはすぐに作れる。そして、まだ置き換えが難しく、CLI 化する気が起きない MCP については、MCPLI を中間層として使えば MCP をコマンドラインに変換でき、体験もかなり良い。

少し奇妙な要件があって、Claude Code のサブスクリプションをどうにかして汎用的な OpenAI API エンドポイントに変換し、ローカルの他のサービスやアプリから使えるようにする必要がありました。なぜそんな要件があるのか、あるいはなぜ既成の API や他のモデルをそのまま使わないのかは聞かないでください……コンプライアンスだの制限だの、語り出すと涙なしでは済まない話なので。

ともあれ、本来なら余裕でさばけるはずのことが、今は急いで取り繕うしかなくて、Claude の Agent SDK に Hono を一枚かぶせ、簡単な変換を入れて、claude CLI を OpenAI 互換の API に変身させた 形でローカル向けに提供することにしました。コミュニティを一通り見ても、使いやすい類似案はあまり見当たらなかったので、必要な人が使えるように手早く OSS として公開しておきます。リスク提示には注意して、規約違反にならないようにしてください。ただ、たぶん需要はほとんどないと思います。というのも、こんな奇妙な状況にぶつかる人はそう多くないでしょうから……。

またしてもAnthropicにチャージした資金が使い切れずに期限切れとなり損をしたことをきっかけに、すべてのAPI利用方針を「モデルベンダーに直接課金」から「モデルアグリゲーションプラットフォーム経由」に切り替えることにした。以前から OpenRouter でアカウントを持ち、軽く触ったことはあるが、ORはモデル数が多すぎて雑多で、プロバイダー設定も複雑なため、少し油断するとマイナーなサービスに流れて思いがけない問題を招きかねない。それに比べてZenMuxはUIがすっきりして分かりやすく、モデルも明らかに選別されていて、プロバイダーも公式だけに見える。今後しばらくはこちらをメインに使うつもりだ。

アクセスボタンは私の紹介リンクにつながっており、新規ユーザーは初回チャージで25%のボーナス残高を得られるのでコストパフォーマンスも悪くなく、ぜひ試してみてほしい。

Nix は「純粋関数型」という思想の上に構築されたパッケージマネージャーで、依存関係を明示的に記述し、すべてのソフトウェアビルドを再現可能にし、環境を相互に汚染させることもありません。さらに嬉しいのは、宣言的な設定を使うだけで複数台のマシンにおけるシステム環境・開発ツール・ユーザーレベルのソフトウェアをすべて同期でき、「一度書けばどこでも同じ」を本当に実現できることです。

以前は Mackup を使って設定を同期していましたが、新しいシステムではそれが大幅に制限され、設定を丸ごと失う事態さえ起きました。そのため Nix を使う優先度を改めて見直し始めました。ただ Nix の文法や習得コストは決して優しくなく、これまで完全移行できなかった主な理由でもあります。ところが今は状況が変わりました。自然言語で要件を説明すれば、AI が nix の設定や flake 全体まで代わりに書いてくれ、学習コストはほぼゼロになりました。

Nix の決定性という特性と組み合わせれば、将来デバイスを替えるのも、システムを再インストールするのも、環境を引っ越すのも、残るのはただ一言──コピーすれば完了。

いくつものノートアプリを渡り歩いてきたが、ローカル優先でビジュアルも優れ、さらに AI を深く統合したものを見つけるのは本当に難しい。再び Obsidian に戻る前は、およそ 2 年間 Craft.do を使っていた。彼らは Mac Catalyst を見事に完成させたものの、AI への対応が遅く、結局は涙を飲んで離れることにした。AI 時代に最も優れたノート整理法は markdown ファイルに回帰し、ファイルを直接操作して Agent が最大限の力を発揮できるようにすることだ。Obsidian で Infio を使うことで、ノートが有機的につながり、本当のナレッジベースになった。

実のところ VS Code と任意の agent を組み合わせても似たような効果は得られるが、Obsidian にはノートに必要なビジュアルスタイルやバックリンクなどを備えた、より整ったエコシステムがある。モバイル版の Obsidian はかなり力不足なので、外出先では Termius を使って自宅サーバーに直接接続し、コマンドラインの agent にノートを操作させている。同期を気にする必要がないのも利点だ。

以前から繰り返しで退屈だが人の手も要る作業にとって、AI に置き換えるのはまさに理想的なユースケースだ。

Kingfisher のリリースは複数の PR や Issue に関わることが多く、人力で整理すると細部を見落としがちだ。手作業で確認し、変更を適切なコントリビューターへ帰属させるのも骨が折れる。さらに各バージョンに名前を付ける作業は、一日中頭を悩ませることもある。この手順があれば、AI がまず master と直前のタグとの差分を列挙し、PR の説明を自動解析して機能・修正・貢献者をまとめてくれる。私は校正と洞察の補足に集中でき、情報を一から集め直す必要がなくなる。

精度を高めるために、会話で 1～2 件のサンプル出力を添えて AI に例を模倣してもらい、新しい項目を change_log に埋めてもらう。「YAML のキー名を変更しないこと」と「各項目にリンクと貢献者を必ず付けること」をプロンプトで明示すれば、AI は release スクリプト要件に沿ったリリースノートを安定して生成する。また、なぜマイナーバージョンなのか、なぜパッチなのかといったバージョン番号の導出プロセスも提示させることで、レビュー時にセマンティックバージョニングの判断根拠を素早く検証できる。これらの戦略を組み合わせれば、煩雑だったリリース準備は気軽なレビュー工程へと生まれ変わる。

毎日コツコツと作業に没頭する技術職として、私は経済や投資を体系的に学んだ経験が乏しく、その分野の嗅覚も鈍いままだ。経済系の読物（ブログ、長文記事、評論など）を読むと、要点をつかみづらく、現象の本質を理解するのも難しい。AI の登場は、初心者として「誰にも相談できない」という気まずさを見事に補ってくれた。最近 Stratechery を購読し、ざっと読んだ後に LLM に渡して10分ほど対話しながら記事とその背後のロジックを深掘りしているが、とても役立っている。

多くの LLM は記事の要約や投資提案では良いパフォーマンスを見せるものの、ディスカッション段階になるとモデルごとに微妙な差がある。Sonnet は話題が逸れやすく、同調モードに入りがちだ。ChatGPT は発散しやすく、逆質問でテーマをやや無関係な方向へ振ることがある。Gemini は専門性が高そうだが、ときどき感情がこもった印象を受ける。総合すると、この種のタスクでは ChatGPT が最もバランスを取っている。多様な場面で使うほど、モデルが人間に似ていることを実感する。モデルごとに個性や得意分野が異なり、とても興味深い。

開発者の限界は実のところ入力速度にあります。AIの時代になり、ついに音声入力であらゆるタスクを思い通りにこなせるようになりました。VoiceInkやそのほかの類似ツールでローカルの音声ディクテーションを変換し、利用しているアプリに合わせて結果をAIへ渡し、状況ごとにプロンプトを組み合わせて二次処理を行います（たとえばCodexやClaude Codeでは「開発者向け音声指令処理」を使い、Slackでは自動翻訳で私の中国語入力を相手が理解できる文章に変換するなど）。こうしたワークフローは驚くほどシンプルですが入力効率を大幅に高め、マルチタスク作業の最後の障壁を越えさせてくれました。

二次処理の速度は極めて重要で、現在では高速さに長けた Groq が最も有力な選択肢に思えます。モデルに関してはKimi-2を好んで使っています。GPT OSSの2つのモデルはトークン生成の絶対速度こそ速いものの、推論モデルであるためこの種のリアルタイムタスクではKimiのような非推論モデルほど直接的かつ迅速には機能しません。普段使いの範囲であれば、Groqの個人プランは完全に無料で利用でき、とても快適です。

自宅サーバーでセルフホストした n8n インスタンスは、日々の幸福度を大きく高めてくれます。私の環境では、毎朝スケジュールされたタスクが実行され、その日に加えて翌日の天気や家族全員のカレンダー予定を取得します。さらに AI 連携によって、服装の提案や一日のスケジュールを自動生成し、温かい挨拶と短いモチベーションメッセージを添えて、最終的に Bark 経由で家族全員に届けてくれます。最高の一日の始まり方です。

その通りです。ご覧いただいているこのサイトは、純粋な vibe coding の産物であり、私は一行もコードを書いていません。現在のプログラミングエージェント系ツールは、フロントエンドの問題を扱う際にまさに自由自在で、Codex のコストパフォーマンスは現代においてトップクラスと言えるでしょう。企画から実装まで、ほぼすべての作業を担ってくれています。

経験の話をすると、何度か「ゼロから」の vibe coding を試してみて、実際に手を動かす前に要求をきちんとすり合わせておくことが成功の鍵だと感じました。このプロジェクトの最初のコミットのように、「計画ドキュメントに基づく」新しい開発パラダイムは、AI 時代に新規プロジェクトを始める際の最適解かもしれません（もちろん、その計画ドキュメント自体も LLM の産物です）。