Claude Code を一人会社の「チーム」代わりに使う

🧭一人会社で足りないのは「手」より「役割」

一人だと、実装もレビューも意思決定も同じ頭で起きる。だから、自分の抜けに自分で気づけない。

チームで開発していたころを思い出します。あの価値は、半分が「手の数」ではありませんでした。 ――「立場の違う目」です。

実装した本人とは別の誰かがレビューする。おかしいと思えば、差し戻す。この摩擦があるから、雑なコードは本番に出にくい。

一人になると、その摩擦が消えます。自分のコードを自分で見ると、どうしても甘くなる。「たぶん大丈夫」で通してしまう。

AI に全部投げても、じつは同じでした。作った本人（AI）に自己採点させると、評価が甘くなる。人間と変わりません。だから私が Claude Code にまず求めたのは、速さではなく他人の目をもう一度つくることでした。

🗺️Claude Code に渡せる「役割」の地図

一人ぶんの仕事を4つの役割に切り分けると、AI に任せる範囲と、人が握る範囲が見えてきます。

肝は、実装役と検証役を同じ会話で兼任させないこと。同じ文脈にいると、検証役が実装役の言い分に引きずられて甘くなる。だから検証は別のセッションで、変更の中身だけを渡してやり直させます。

⚙️肝は「自己採点させない」設計

検証役の判定根拠を「感想」から「実行できる合否」に寄せるほど、自走は安全になります。

検証役に「このコード大丈夫？」と聞くと、だいたい「問題なさそうです」と返ってきます。これは当てになりません。LLM は、目の前の文脈に同調しやすいからです。

そこで、検証役の合格条件を機械が判定できるものに置き換えました。

• ユニットテストが通っているか（node --test や vitest の終了コード）
• 変更が、触っていいファイルの範囲に収まっているか
• API キーなどの機密が、コミットに紛れていないか
• リンタ・型チェックがエラーを出していないか

どれも「良い・悪い」の主観ではありません。合否が、はっきり出る。検証役にはこの合否だけで Pass/Fail を返させ、一つでも赤ければ実装役に差し戻す。

実際にこの組み方を OSS プロダクトで回した記録は Claude Code の自走サイクルを実プロダクトで回してみた にまとめました。そこでは検証役を node --test の exit code などで判定させ、6 つのゲートをすべて機械の合否で通しています。

🚦マージは人間が握る――「自走」と「全自動」は違う

AI に任せるのは PR を用意するところまで。公開のスイッチは、いつも自分の手元に残します。

一人会社で一番こわいのは、誰のレビューも通らずに変なものが本番に出ることです。だから私は、自走ループの出口を必ずPull Requestにしています。実装役が作り、検証役が機械の合否で通したものを、Draft PRとして積み上げる。マージするかどうかは、私が中身を見て決める。

「工場は在庫を作る、出荷は人間が決める」。そういう分け方です。

記事の自動生成も同じでした。この i-Willink のメディアでは、AI が記事ドラフトの PR を起こすところまでを自動化し、公開（マージ）は私が判断しています。不可逆なこと――本番反映・公開・課金が動くこと――だけは、人間のゲートを外さない。これが一人で回すうえでの、自分なりの線引きです。

🛡️あとから「なぜ通したか」をたどれる形に残す

一人だと、記憶が唯一の引き継ぎ書になる。だから判断の根拠を、会話の外に残しておきます。

チームなら「あのとき誰がどう判断したか」を聞けます。でも一人だと、全部が自分の記憶頼み。半年後の自分は、他人と同じくらい忘れている。

だから、自走ループの1 周ごとに「何を・どう確かめて・通したか」を1行残すようにしています。

派手な仕掛けではありません。でも「AI に任せて大丈夫か」を自分一人で担保するなら、速さよりたどれることのほうが効きます。あとで問題が出ても、どこで判断を誤ったかを1行ずつ遡れる。

🚀一人会社の、現実的な始め方

いきなり全自動を組まず、まず実装役と検証役を別セッションで回すところから始めます。

最初から無人の自走ループを組む必要はありません。私も、手元で次の順に育てました。

1. 手動で2役を分ける：実装を頼んだセッションとは別のセッションを開き、変更内容だけを貼って「テストを実行して合否を返して」と検証させる。これだけで、自己採点の甘さが消えます。
2. 合否を機械に寄せる：テスト・型チェック・リンタを CI に積み、検証役の判断材料をログにする。主観のレビューを減らし、赤緑で語れるようにします。
3. 出口を PR に固定する：通ったものは必ず PR にし、マージは自分が押す。ここまで来て初めて、着手の自動化（どのタスクから手を付けるか）を少しずつ足します。

いきなり3段目から始めると、検証が甘いまま本番に出る事故が起きます。順番を守るほど、あとで安心して任せられる範囲が広がっていく。そういう感覚があります。

🤝正直な限界――AI は同僚の代わりにはならない

役割は分けられても、責任は分けられない。最後の判断と説明責任は、人間に残ります。

ここははっきり書いておきます。この組み方は「AI が一人で会社を育てる」話ではありません。検証役を分けても、根本の方針が間違っていれば、間違った方向に正確に進むだけ。何を作るか、誰に届けるか、いつ止めるか。事業の責任を負う判断は、AI に渡せません。

それでも――実装役と検証役を分け、出口を PR に固定し、判断を1行ずつ残す。この三つを守るだけで、一人でも「他人の目」に近い摩擦を取り戻せました。チームの完全な代わりではない。でも、一人で詰まりやすいところを、ずいぶん埋めてくれています。

あなたが一人で事業を回しているなら、まずは実装役と検証役を別セッションで分けるところから、試してみてください。設計のヒントになればうれしいです。