個人開発を続けていると、ある時点で気づく。同じ判断を毎回やり直していることに。

「これは台帳に起票すべき？」「QAは必要？」「競合調査は先にやった方がいい？」——こういった判断が、毎セッション発生する。疲弊するし、抜け漏れる。

この問題を解決するために、Claude Code に CEO・QA・事業開発・技術検証の4部門 を設けた「AI会社」を1ヶ月運営してみました。本記事はその実録です。

構成と役割定義書

役割定義書はすべてマークダウンファイルで管理し、Claude Code に読み込ませる運用です。複数エージェント・複数 LLM を立ち上げるのではなく、同一セッション内で人格を切り替えるシンプルな設計。

「判断権限の境界」が最初のキー

CEO 役割定義書で一番効いたのは、「CEO が勝手に決めていい範囲」と「オーナー確認必須の範囲」を表にしたことです。

この表を書いて以降、「これ確認すべきか？」という判断コストが消えました。テンポが目に見えて上がります。

QA部の役割定義書には 「あなたの仕事は改善点を見つけること。良い点を褒める必要はない」 と明記しています。

実際に運用してみると、差し戻しは想像以上に頻発しました。1ヶ月で確認できただけで6回以上のレビューサイクルを完走。品質は確実に変わります。

1ヶ月で「やらかし」は4回ありました。

いずれも発生直後にメモリファイル（feedback_*.md）に記録し、次セッションから自動適用する運用にしています。同じ失敗は一度も繰り返していません。

特に「PJ台帳46回更新」は自分でやろうとしたら絶対にサボっていた領域です。CEO に「実装した直後に台帳を更新」というルールを与えると、本当にやってくれます。

Claude Code 通常運用枠、Cloudflare Pages、Astro を無料で使い、追加コストはドメイン代のみ。

詳細な役割定義書の中身・相談処理フロー・4つの失敗パターン全文は元記事に書きました：