道具とインフラの違い

1. 「Claude Codeいらない」という気づき

Claude Codeは優れている。ローカルファイルを直接操作できる。レスポンスはリアルタイムだ。エラーを即座に確認して即座に直せる。機能だけ見れば、今日構築したシステムより明らかに高性能だ。

それでも「いらない」と思った。なぜか。

Claude Codeを使う限り、データはAnthropicのサーバーにある。セッションが終われば文脈は消える。使うほど課金が積み上がる。高性能だが、それは借り物の高性能だ。

今日構築したシステムは非同期で、30秒の待ち時間がある。リアルタイムではない。だがデータは自分のGitHubにある。セッションをまたいで文脈が続く。コストはゼロで、使うほどtr/リポジトリが育っていく。

「高性能な借り物」より「自分のインフラ」を選んだ。その判断の根拠を整理する。

2. 道具の三つの性質

道具には共通した三つの性質がある。

一つ目は、所有権が自分にないこと。ハンマーは自分のものだが、SaaSツールは違う。利用規約が変わる。値上げされる。サービスが終了する。その判断は常に提供者側にある。

二つ目は、コストが使用量に比例すること。使わなければ安く、使えば高い。上限を気にしながら使う構造は、判断を歪める。「この処理はコストに見合うか」という問いが、本来不要なところで発生する。

三つ目は、蓄積が自分の手元に残らないこと。Claude Codeで何百回会話しても、その文脈・判断・学習はセッションと共に消える。次のセッションは、また最初からだ。

3. インフラの三つの性質

インフラはこの逆だ。

所有権が自分にある。tokistorage/trは自分のリポジトリだ。GitHubがサービスを終了しても、gitリポジトリはローカルにクローンできる。どのホスティングサービスにも移行できる。ロックインがない。

コストが使用量に比例しない。publicリポジトリのActionsは無制限・無料だ。朝に一回使っても、一日に十回使っても、固定費はゼロのままだ。コストを気にせず使える状態は、判断の質を変える。

蓄積が手元に残る。memory/context/に書いた文脈は次のセッションでpullできる。skills/に定義したスキルは積み上がる。project/cache/のデータは更新され続ける。使うほど、システムが自分に合ってくる。

4. 非同期は欠点か

このシステムの明確な弱点は非同期であることだ。リクエストをpushして、Actionsが動いて、結果をpullする。数十秒かかる。

だが業務を振り返ると、「30秒待てない」処理は思いのほか少ない。朝のプロジェクト確認、タスクの更新、資料の生成、エッセイの公開——どれも非同期で足りる。むしろリアルタイム性を求めていたのは、道具に慣れた感覚の側にあった。

インフラは即応しなくていい。水道は蛇口をひねった瞬間に水が出るが、発電所は予約制ではない。常に動いていて、必要なときに使える。このシステムも同じだ。

5. 設計の方向性が違う

道具は、提供者が設計する。ユーザーはその設計の範囲内で使う。機能リクエストを出せるが、受け入れるかどうかは提供者が決める。

インフラは、自分が設計する。.github/workflows/のyamlを書けば、どんな処理でもActionsに実装できる。スキル定義をskills/に追加すれば、Claudeの振る舞いが変わる。設計の主体が自分にある。

今日一日で、朝のブリーフィング・タスク更新・エッセイ公開という三つの用途が動いた。明日は四つ目を設計できる。上限は提供者ではなく、自分の想像力だ。