個人開発を続けていると、ある時点で気づく。同じ判断を毎回やり直していることに。
「これは台帳に起票すべき？」「QAは必要？」「競合調査は先にやった方がいい？」——こういった判断が、毎セッション発生する。疲弊するし、抜け漏れる。
この問題を解決するために、Claude Code に CEO・QA・事業開発・技術検証の4部門 を設けた「AI会社」を1ヶ月運営してみました。本記事はその実録です。
構成と役割定義書
| 役割 | 担当 | 設計の動機 |
|---|---|---|
| CEO | 全体の判断と部門間調整 | 意思決定者を立てて責任の所在を明確化 |
| QA部 | 成果物の批判的レビュー | 自分で書いたものを自分でレビューすると甘くなる |
| 事業開発部 | 市場・競合・収益モデル | 「作るか・作らないか」の前に検証する |
| 技術検証部 | 技術的実現可能性 | 推測ではなく PoC を動かす |
役割定義書はすべてマークダウンファイルで管理し、Claude Code に読み込ませる運用です。複数エージェント・複数 LLM を立ち上げるのではなく、同一セッション内で人格を切り替えるシンプルな設計。
「判断権限の境界」が最初のキー
CEO 役割定義書で一番効いたのは、「CEO が勝手に決めていい範囲」と「オーナー確認必須の範囲」を表にしたことです。
この表を書いて以降、「これ確認すべきか？」という判断コストが消えました。テンポが目に見えて上がります。
QA部に「褒めるな」と書く
QA部の役割定義書には 「あなたの仕事は改善点を見つけること。良い点を褒める必要はない」 と明記しています。
実際に運用してみると、差し戻しは想像以上に頻発しました。1ヶ月で確認できただけで6回以上のレビューサイクルを完走。品質は確実に変わります。
失敗→メモリ記録→運用ルール化のサイクル
1ヶ月で「やらかし」は4回ありました。
- CEO代行作業をオーナーが進めたと誤帰属した
- ブラウザ自動化（Playwright MCP）を導入したのに使っていなかった
- 両論併記のクセで判断を押し付けてこなかった
- 新規アイデア相談時に既存PJとの重複を見落とした
いずれも発生直後にメモリファイル（feedback_*.md）に記録し、次セッションから自動適用する運用にしています。同じ失敗は一度も繰り返していません。
1ヶ月の実績数字
| 指標 | 数 |
|---|---|
| 相談ログ | 27件 |
| 進行中PJ台帳更新 | 46回 |
| git コミット | 25本超 |
| QA部レビュー | 6回以上 |
| 本番公開 | 1本（AI Maker Lab） |
| 公開記事 | 10本超 |
特に「PJ台帳46回更新」は自分でやろうとしたら絶対にサボっていた領域です。CEO に「実装した直後に台帳を更新」というルールを与えると、本当にやってくれます。
コストは月¥170
Claude Code 通常運用枠、Cloudflare Pages、Astro を無料で使い、追加コストはドメイン代のみ。
まとめ
- 役割定義書（マークダウン）を書くだけで判断コストが消える
- QA部に「褒めるな」と書くと品質が変わる
- 失敗→即メモリ記録→運用ルール化で同じ失敗を繰り返さない
- コスト月¥170で個人開発が回る
詳細な役割定義書の中身・相談処理フロー・4つの失敗パターン全文は元記事に書きました：