正直、今日まで気づいていなかった。
きっかけは「GPSを使った何か新しいビジネス」を考えていたこと
UberみたいにリアルタイムGPS位置情報を使ったアプリ、どんなビジネスになるだろうと漠然と考えていた。
マッチングアプリ、高齢者見守り、おつかいマーケット、場所をトリガーにした体験経済……いろいろ出てきたけど、どれもパッとしなかった。
そこで「ローカルで動く何かがいい」という感覚が出てきた。
クラウドのAIを使いながら、ローカルで新しい何かを生み出す。今自分がやっていることを複製させるような。
「自分のコーディングフローを複製させたい」
Open Interpreterみたいなやつ、と言えば近い。でも違う。
自分が Claude × Cursor でコーディングするときの動作パターンごと、AIに移植したい。
今やっていること：
MUSUBUセッション開始
→ DB構造ダンプ
→ tree出力
→ Supabase型生成
→ コーディング開始（1ステップずつ確認）
このフローは自分が手を動かして作ったものだ。なぜこの順番か、どこで確認を挟むか、どのファイルはVSCodeで触りPowerShellは使わないか。全部に理由がある。
これを「Skill.md」というファイルに書き溜めている。Claude（AI）がそれを読んで、自分流に動いてくれるように。
ふと思った。このSkill.mdの品質さえ上がれば、エージェントが自分の代わりに動けるんじゃないか。
理想の姿が見えた瞬間
今：
自分 → Claude → Cursor → 手動確認 → 手動デプロイ
理想：
自分「MUSUBUの整骨院バージョン作って」
エージェント → 設計 → 実装 → テスト → Vercelデプロイ
自分「これでいい？」→ Yes → 完成
MUSUBUというLINE×AI予約SaaSを作った。
これを整骨院向けに横展開する。英語版にする。
今は全部自分がタイプして、確認して、デプロイしている。
でもMUSUBUのソースコードと文脈を全部持ったエージェントが動けば、変更点だけ伝えれば勝手に横展開してくれる。
台数が増えたら、工場になる
1台のPCでそれが動いたら。
使っていない古いPC、3〜4台ある。
PC① → MUSUBU整骨院版 → デプロイ待ち
PC② → MUSUBU英語版 → デプロイ待ち
PC③ → JINZAI Care版 → デプロイ待ち
PC④ → 新規アイデア → デプロイ待ち
朝起きたら通知が来ている。「確認してください」。
LINEで「OK」と返す。デプロイされる。
自分はもう職人じゃない。工場のオーナーだ。
ボトルネックはハードウェアじゃない
ここが重要な気づきだった。
古いPC（Core i5 / 16GB RAM）でいい。処理の重さはClaudeAPI側が持つ。中古3万円 × 5台 = 15万円。
あるいはGitHub Actionsで並列実行すればPCすら要らない。
本当のボトルネックはSkill.mdの品質だ。
エージェントへの文脈の解像度が低いと：
迷う
間違った実装をする
確認コストが増える
結局自分が直す
文脈の解像度が高いと：
迷わない
正しく実装する
最終確認だけでいい
台数を増やすほど生産量が増える
「台数を増やす」前に「文脈の品質を上げる」。これが今やること。
これから1〜2ヶ月でやること
今まで：作って終わり。セッションが終わったら忘れる。
これから：作りながら記録する。
具体的には：
セッション終了時に一行残す
今日やったこと
なぜその順番だったか
どこで迷ったか
どう判断したか
コードだけじゃなく「なぜ」を残す。それがエージェントの判断基準になる。
新しいパターンが生まれたらSkill.md化する
「あ、これいつもやってるな」と気づいた瞬間に書く。
汎用AIには絶対に真似できないもの
世の中が作ろうとしているのは汎用エージェント。
自分が作ろうとしているのは：
「MUSUBUを知っている」
「JINZAIのルールを知っている」
「確認ファーストの判断基準を知っている」
「Vercelの本番環境を知っている」
自分の文脈ごと持ったエージェント。
これは汎用AIには真似できない。そして、この設計図（Skill.md群）自体が、いつか売れる資産になる。
まだ土台は固まっていない
正直に言う。今日、少しだけ未来が見えた。でもまだ土台が固まっていない。
1〜2ヶ月は品質を上げる地味な作業が続く。
でも今やっていることを「残す前提」で作業や思考を合わせていく。それだけで、数ヶ月後に全然違うものが手元にある気がしている。
個人開発者 / 元ホテル支配人 / LINE×AI予約SaaS「MUSUBU」開発中
