何を作らなかったか — ひとり＋AI で開発を回す、いちばん軽い型

このコーポレートサイトは、僕ひとりと AI エージェントで作っています。実装のうちコードを書く部分は、コード生成が得意な AI（codex）に任せ、僕は判断とレビューのほうへ寄る。……と書くと、いかにも 2026 らしい話に聞こえます。実際、いまは「AI でこう開発している」という記録が溢れていて、その多くは足し算です。AI を何体も束ねて連携させ、変更のたびに多段の CI を回す。派手で、強そうに見えます。

ただ、このサイトを組むときに僕がいちばん手をかけたのは、そちらではありませんでした。何を足すかではなく、何を作らないか。時間の大半は、その引き算のほうに使っています。

大がかりな仕組みを、あえて持ち込まない

じつは、ジャムチにはもっと大がかりな開発体制の実装もあります。自社プロダクト（FXトレーダーα）の側では、課題を配る担当、コードを書く担当、変更をレビューする担当、それをマージする担当——役割ごとに別々の AI を立て、そのうえ多段の CI と監査を重ねる、大がかりな体制を動かしています。

このサイトには、それを持ち込みませんでした。理由は単純で、規模が違うからです。コーポレートサイトの開発は、課題の数もせいぜい二十件ほど、同時進行でぶつかることも少なく、僕自身がずっと中にいます。この規模でそこまでの体制を敷くと、仕組みを維持する手間のほうが、こなす仕事の量を追い越してしまう。速くて小さいものに重い機械を載せるのは、たいてい割に合いません。

代わりに置いたのは、ずっと薄い型でした。進め方は既製の作業手順に任せ、課題の管理は、仕事を小さな単位（社内では bead ＝課題チケットと呼んでいます）に切って追う軽いツールに。コードを書く作業だけを AI に振る仕組みも、薄い橋渡しのスクリプトが二本あるだけ。マージも、GitHub の標準的な操作だけで回します。派手さはありません。けれど、迷いは確実に減ります。

AI がコードを書くなら、省けないゲートがひとつある

薄くする、とはいえ、どこでも薄くしていいわけではありません。ひとつだけ、削ってはいけない場所がありました。公開前のゲートです。

はじめは、main へ直接コミットして済ませていた時期もありました。小さな変更なら、そのほうが速い。ところが、この形には穴があります。ひとつは、main に入った瞬間に、Cloudflare がそれを本番へ自動でデプロイしてしまうこと。壊れた変更が、そのまま世に出ます。もうひとつは、AI にコードを書かせるときの話で、AI の書き込みは、手元のコミット前チェック（hook）を通らずに入ってくる。つまり、AI が書いて AI がそのまま入れると、途中に誰も立っていない状態になりうるのです。

ですから、main への直接コミットはやめました。いまはすべて、次の一本道を通します。小さな課題をひとつ立て、作業ブランチで進め、変更を PR にまとめ、Cloudflare のプレビューと最小限の CI（型チェック・テスト・ビルド）を自分の目で確かめ、問題なければ squash merge で取り込む。

このサイトのリポジトリは非公開で、しかも無料の枠で運用しているため、CI の合格を「マージの必須条件」として機械的に強制することはできません。だからこそ、プレビューを自分の目で見る、という一手を省かない。強制できないぶんを、規律で埋めます。AI がコードを書くほど、この最後のゲートだけは人間が握っていないといけない、と考えています。

軽さの代償は、別のところで塞ぐ

軽いやり方には、軽いなりの穴もあります。ふたつ、意識して塞いでいます。

ひとつは、声と匿名化です。文章の仕事を AI に手伝わせると、どうしても誇張や受け売り、出してはいけない情報が混ざりやすい。そこで、守りたい線を regex のテストとして書いておき、CI で先に弾くようにしました。過剰な言い回し、取引先の実名、料金や金額のような機微——このあたりは、僕がレビューに入る前に、機械が落とします。人の目は、機械では測れない判断のほうに集中させる。

もうひとつは、複数の AI を同時に走らせるときの隔離です。作業量が増えれば、いくつもの AI を並行で動かしたくなる。ここには、2026 の並行 AI 開発でいちばんよく聞く落とし穴があります。worktree で作業を分けて隔離すれば、同じファイルを同時にいじる衝突は防げます。けれど、防げないものもある。二体が同じ処理や前提を別々に直せば、マージ自体はきれいに通っても、動かすと壊れている。任せた AI が、こちらの意図しないところで git の操作（commit や push）に手を伸ばすこともあります。外部の AI に勝手に commit や push をさせない、という一線は、放っておいて自動で守られるものではないのです。

だから、隔離は最初から既定にしています。作業は必ず独立した worktree で行い、任せたあとは git の状態を自分の目で確かめる。大きな事故は、たいてい隔離を省いたときに起きます。逆に、隔離しておけば、同じ出来事が事故ではなく、取るに足らない一コマで済む。この地味な規律を省かないこと自体が、軽いやり方を成り立たせている条件でした。

薄い型は、渡せる型でもある

こうして眺めると、このサイトは完成物であると同時に、開発のやり方そのものの記録になっています。派手な仕組みは載っていません。むしろ、載せなかったものの記録に近い。何を作らないかを決め、削れない一箇所だけを守り、軽さの代償を別のところで塞ぐ。やっていることは、それだけです。

面白いのは、この薄さが、そのまま他社に渡せる型になることです。大がかりな体制は、それを組んだ会社の事情に貼りついていて、持ち出しにくい。けれど、小さく切って、一本道で流して、譲れない線だけ機械に見張らせる——ここまで薄ければ、少人数 × AI で事業を回したい会社に、ジャムチが実際に使っているまま入れられます。作り込みではなく、どこで作るのをやめるか。レバレッジは、たぶんそちら側にあります。少なくとも僕は、そう思ってこのサイトを組みました。

参考: 複数の作業を worktree で隔離して並行で進める流儀や、計画を先に置いて小さく刻む進め方は、Addy Osmani の AI コーディング手法（2026）などにも共通します。どの作業をどの AI に振り分けるかは別の記事、自律運用側の「壊れ方の設計」はこちらに書きました。