AIの船に乗っちゃった

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

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

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

私の supacode fork も同じだ。基盤は元プロジェクトを踏襲しつつ、高頻度の体験改善だけを入れている。例えばスクリプトボタン、ショートカット、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 の産物です）。