はじめに
2025年が終わろうとしている。
先日、「なぜ『何でも作れる時代』に私は作れないのか」という記事を書いた。「代表作」がないという焦り、量をやることの重要性、そして引き算の必要性。書きながら、自分の弱さと向き合った。
あの記事で「2026年は20個作る」と宣言した。その前に、2025年に何を作ったのか振り返っておきたい。
振り返ると、この1年は「自分が欲しいもの」をひたすら作り続けた年だった。誰かに頼まれたわけでもなく、バズを狙ったわけでもなく、ただ「これがあったら便利なのに」という衝動に従って、キーボードを叩き続けた。「3回同じ不便を感じたら作る」というルールを自分に課している。cctxは3回目の設定ファイル書き換えで、cargo-autoddは3回目のCargo.toml編集で生まれた。前回の記事で書いた「隙間家具」を、実際に作っていた1年だった。
11個のリポジトリを公開し、合計900以上のスターをいただいた。正直に言えば、通知が来るたびに見てしまう。でも、スターが多くても使われないツールはある。逆に、スター10でも毎日使っているツールがある。自分にとっての成功の定義を「毎日使うか」に変えてから、気持ちが楽になった。
Claude Codeと過ごした1年
2025年は、Claude Codeと共に過ごした年だった、と言っても過言ではない。
cctx
Claude Codeを使い込むうちに、設定を切り替えたくなる場面が増えた。仕事では制限をかけたい、個人プロジェクトでは自由にやりたい。kubectxを使ったことがある人なら分かるだろうが、あの「サクッと切り替える」感覚が欲しかった。だからcctxを作った。
cctx work と打つだけで、仕事モードに切り替わる。cctx - で前のコンテキストに戻る。それだけのツールだが、毎日使っている。毎日使うから、これは成功だ。
claudelytics
Claude Codeをどれくらい使っているのか、可視化したくなった。トークン消費量、コスト、セッションごとの使用パターン。数字で見えると、自分の開発スタイルが見えてくる。TUIを作り込んで、眺めているだけで楽しいものにした。
作っていて気づいたことがある。「正確なデータ」より「見たくなるUI」の方が継続利用に繋がる。最初はCSVエクスポートに注力したが、結局TUIの見た目を磨いた時間の方が長かった。
ccat
CLAUDE.mdというファイルが増えてくると、管理が面倒になる。どこに何を書いたか分からなくなる。インポートチェーンが複雑になる。だから分析ツールを作った。地味だけど、自分には必要だった。
ccswarm
これは少し野心的なプロジェクトだった。複数のAIエージェントを協調させて、大きなタスクを分割して処理する。Git worktreeで並列開発を実現する。「Sangha」という仏教にインスパイアされた民主的意思決定システムを入れたのは、ちょっとした遊び心だ。
正直、まだ実験段階で、自分でも使いこなせていない。でも「AIエージェントの協調」という方向性は間違っていないと思っている。来年、もう少し実用的なものにしたい。
Rustへの愛
なぜRustを選ぶのか。理由はシンプルで、ただ好きだからだ。
でも「好き」の中身を分解すると、いくつかの要素がある。まず、型システムがAIと相性が良い。Claude Codeにコードを書かせると、Pythonでは「動くけど大丈夫？」という不安が残る。Rustでは、コンパイラが通ればほぼ安全だという確信がある。AIが生成したコードでも、コンパイラが厳しくチェックしてくれる。この安心感は大きい。
そして、丁寧なエラーメッセージ。Rustのコンパイラは「ここが間違っている」だけでなく「こうすれば直る」まで教えてくれる。学習を助けてくれる先生のような存在だ。使うほど信頼が増す。
所有権や型システムの「難しさ」は、将来の保守性を高めるための設計だと理解している。大規模・長期運用での事故を防ぐための仕組み。楽ではないが「裏切らない」という安心感がある。だから何度でも選ぶ。
cargo-autodd
Rustを書いていると、Cargo.tomlの依存関係管理が面倒になることがある。ソースコードにuse serde_jsonと書いたら、自動で依存関係に追加してほしい。逆に、使わなくなったcrateは消してほしい。そんな怠惰な願望から生まれたツール。
作っていて学んだことがある。ASTパーサーを書いていた。「完璧に解析する」より「80%の精度で10倍速い」方がユーザー体験は良い。完璧主義がUXを損なう好例だった。
cargo-coupling
Vlad Khononovの「Balancing Coupling in Software Design」を読んで感銘を受けた。結合度と凝集度のバランス、距離と変更頻度の関係。これをRustプロジェクトで可視化したら面白いんじゃないか。そう思って作り始めたら、想像以上に深い世界が広がっていた。
Web UIを付けて、グラフを眺められるようにした。自分のコードを分析した。予想以上に結合度が高いモジュールを発見した。「ここ、分割した方がいいな」と気づけたのは収穫だった。ツールを作ることで、自分のコードの問題が見えてくる。
cargo.nvim
NeovimでRustを書いている。:CargoBuildと打つだけでビルドが走り、フローティングウィンドウに結果が表示される。エディタから手を離さずに開発サイクルを回せる。些細なことだけど、この積み重ねが開発体験を変える。
Terraformとの格闘
インフラをコードで管理するのは素晴らしい。でも、時にはTerraformと格闘することもある。
tfmcp
AIにインフラを任せるのは危険か。答えは「条件による」だ。tfmcpで設けた制限は3つ。本番環境は読み取り専用。全操作の監査ログを記録。destructiveな変更は人間の承認必須。この制限下なら、AIはterraform planを高速で回す優秀なアシスタントだ。
危険なのは「AIに任せること」ではなく、「制限なく任せること」だ。この区別が重要だと、作りながら実感した。
tfocus
Terraformのリソースターゲティングは麻薬だ。一度使うと「今回も大丈夫」と手が伸びる。状態の不整合が蓄積し、ある日terraform applyが破滅的な差分を出す。
それでもtfocusを作ったのは、消防士にも斧が必要なように、障害対応には「禁じ手」が要るからだ。peco風のインタラクティブUIを付けて、素早くリソースを選択できるようにした。READMEに「緊急用ツール」と明記した。日常使いした瞬間、このツールは害になる。
開発者のための小さな道具たち
vibe-ticket
チケット管理システムは世の中に溢れている。Jira、Linear、GitHub Issues。でも、ターミナルで完結する、Git worktreeと統合された、開発者のためのチケット管理が欲しかった。
MCPサーバーとしても動くようにした。AIアシスタントに「さっき見つけたバグのチケット作って」と言えば、作ってくれる。
instrument-rs
オブザーバビリティは大切だ。でも、どこにトレースを入れるべきか、どこにログを仕込むべきか、判断が難しい。コードを静的解析して、「ここに入れるといいよ」と教えてくれるツールがあれば便利だと思った。
HTTPエンドポイントから実行パスをトレースして、クリティカルパスを特定する。まだ実験的なプロジェクトだけど、可能性を感じている。
失敗と学び
11個公開したが、実は3個はアーカイブした。最初に作ったツールは設計が甘く、2週間で書き直した。公開して反応ゼロだったものもある。
前回の記事で「捨てやすく作る」と書いた。アーカイブした3個は、まさにそれを実践した結果だ。状況が変わって不要になったもの、設計を間違えたもの。捨てることに罪悪感はない。役目を終えただけだ。
ヒットの予測は難しい。「これは絶対使われる」と思ったものがスター20で止まり、「まあ自分用だし」と思ったcctxが一番使われている。予測できないなら、作りたいものを作るしかない。前回の記事で「量をやることで、初めて見えてくるものがある」と書いた。11個作って、ようやくその意味が分かってきた。
最後に
ccswarmを公開して3日後、見知らぬ人からIssueが来た。「この機能を追加してほしい」と。実装して返信したら「ありがとう」と返ってきた。それだけのやり取りだったが、不思議と孤独じゃなくなった。顔も知らない人と、コードで繋がる感覚。SNSのいいねとは違う何かがあった。
前回の記事で「代表作がない」と書いた。11個作っても、まだ「これだ」とは言えない。でも、前より近づいている気がする。2025年の11個は、2026年の20個への助走だ。
すべてのプロジェクトはMITライセンスで公開している。もしあなたが「こんなツールがあれば」と思っているなら、まず作ってみてほしい。完璧じゃなくていい。私のツールも初版はバグだらけだった。READMEを書いて、v0.1.0をリリースする。それだけで世界が変わる。使ってくれる人がいるかもしれない。いなくても、自分が使えばいい。
2025年、ありがとう。2026年は、もっと狂う。
