「AI社員を何人も増やしたら、社長の仕事は本当に減るのか？」
1人法人（Nogawa L.prince合同会社）を経営しながら本業と育児を両立する中で、手作業の限界を突破するために立ち上げたのが**「1人法人1000馬力化計画」**です。
1000馬力とは、巨大なAIを1台導入することではありません。 終わらない仕事の「ループ（回路）」を設計し、それぞれの工程に専門のAI社員と設備を配置して、小さな馬力を掛け算して自律稼働させる組織の仕組みです。
このページでは、社内で実際に稼働している24人のAI社員の座席表（担当・見る資料・責任範囲、2026-10-19時点）、50の社内設備（2026-10-19時点）、そして連載全8回の実践記録を一元的に公開しています。
初めて読む人向けの3本（読む順番）
全8回の連載から、まず全体像を掴むためのおすすめ記事です。
- 出発点: 【第1回】Claude Codeのタスク管理：期日とPRの申し送りを1枚にする方法
- 朝起きて最初に見る「秘書エージェント」の設計。散らばった期日とGitHub PRを1枚に集約する。
- 連携の要: 【第5回】Claude Codeで複数のAIエージェントを連携させる方法、自律対話を捨ててGitとファイルで繋ぐ業務ループ設計
- エージェント同士を直接対話させず、GitとMarkdownファイルを共通言語にして非同期に疎結合連携させるアーキテクチャ。
- 30日の答え合わせ: 【第8回】AI社員を増やして社長の仕事は減ったのか？ 1人法人1000馬力化計画の30日答え合わせと組織の見える化（完結編）
- 30日間の答え合わせ。手を動かす作業は減り、人に残った「意思決定と責任」の密度が高まった。
連載全8回のアーカイブ
各業務ごとの詳細な設計思想、プロンプト指示書の作り方、トラブルと再教育の記録です。
| 回 | テーマと記事タイトル | 主な登場担当・機能 |
|---|---|---|
| 第1回 | Claude Codeのタスク管理：期日とPRの申し送りを1枚にする方法 | 028 オクリ（秘書） |
| 第2回 | Claude CodeでSNS投稿を量産する：型と設定を分けたエージェント指示書の作り方 | 010 フデ（制作） |
| 第3回 | Claude CodeでSNSの反響を分析する方法、評価式と勝ち型を抽出するエージェント設計と人に残る意思決定 | 012 ヨミ（分析） |
| 第4回 | AIにブログ記事を採点させる方法、点数と公開判断を分けた品質管理エージェントの設計 | 029 モンバン（品質管理） |
| 第5回 | Claude Codeで複数のAIエージェントを連携させる方法、自律対話を捨ててGitとファイルで繋ぐ業務ループ設計 | Software Factory基盤 |
| 第6回 | 作ったAI社員は翌週も使えたのか？ 採用後に直面した4つの誤作動と指示書の再教育・メンテナンス運用 | 指示書再教育・保守運用 |
| 第7回 | 1人法人のAI運用費をどう記録するか？ サブスク契約費と人間の確認時間を並べたリアルな費用対効果 | コスト・実作業時間管理 |
| 第8回 | AI社員を増やして社長の仕事は減ったのか？ 1人法人1000馬力化計画の30日答え合わせと組織の見える化 | 30日総括・組織論 |
AI社員座席表（WHO DOES WHAT）
※2026年10月、AI社員の呼び名を姓名から、仕事を表す言葉から取った愛称（例: 申し送りを担う秘書は「オクリ」）に改めた。連載の各回も同じ愛称に直している。
「約20人は雇用人数ではなく、役割分担である」（家電彼女 かでん氏の提唱）。 自社では、LLMが状況を解釈して判断を下すものだけを「社員」と定義し、見る資料（入力）とやってよい範囲（責任境界）を厳密に切り分けています。
┌─────────────────────────────────────────────────────────────┐
│ Nogawa L.prince合同会社 │
│ 代表社員（人間・社長） │
│ 【最終判断：本番公開GO / 戦略方針決定】 │
└──────────────┬──────────────────────────────┬───────────────┘
│ │
┌──────────────┴──────────────┐ ┌──────────────┴──────────────┐
│ 社長室 │ │ 経営企画部 │
│ 028 オクリ（秘書役） │
│ 038 チョウボ（経理） │ │ 018 カセツ（改善仮説） │
│ └ 毎朝の状況・申し送り集約 │ │ 019 タナ（ループ監査） │
└─────────────────────────────┘ └─────────────────────────────┘
│ │
┌──────────────┼──────────────┬───────────────┼───────────────┐
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
【X事業部】 【Threads事業部】 【ブログ編集部】 【情報システム】 【社内設備】
010 フデ(制作) 001 ツヅリ(制作) 029 モンバン(品質) 030 トドケ(配信監査) 50件の自動システム
011 サイテン(採点) 002 カゾエ(品質) 032 キチョウ(記録) (Actions/hooks/
012 ヨミ(分析) 003 ノビ(分析) 033 テンサイ(転載) スクリプト等)
031 スミ(進行) 004 ヘンジ(対応) 035 ウラトリ(事実)
034 アワセ(進行) 005 アイサツ(渉外)
【note事業部】
036 ハカリ(品質)
037 ツムギ(制作)
039 カンソク(計測)
040 ミキワメ(判定)
041 カカゲ(公開)1. 社長室（2人）
代表とAI作業の境界を整理し、セッション開始時の状況把握を1枚にする部署。
-
028 オクリ｜秘書
- 担当: 毎朝の申し送り集約、期日管理、未マージPR・残骸worktreeの検知、定時設備の稼働監視。
- 見る資料: Git状態、ドキュメント内の判定期日、GitHub Actions実行履歴。
- 実績: 入社初日に放置されていた残骸worktree 4件を検出。処理済み期日を除外する再教育を経て安定稼働中。
-
038 チョウボ｜経理（収益の月次記録、2026-10-12入社）
- 担当: 毎月最初の月曜に、各ASP・広告の管理画面から前月分の数字を読み取りだけで集め、1か月1ファイルで記録して月次レポートを作る。読めないものは数字を埋めず「未記録」のまま社長に頼む。
2. X事業部（5人）
エンジニアリング・複業・FIRE・法人の4本柱で発信し、オウンドメディアへの送客を担う。
- 010 フデ｜事業部長・制作（モデル: sonnet）
- 担当: 本文単体で価値が完結するX投稿案の作成。
- 011 サイテン｜品質管理（モデル: haiku）
- 担当: 100点満点の配点制採点。文字数（280 weight以内）、禁止ワード、構成を厳格に検査。
- 012 ヨミ｜分析（モデル: sonnet）
- 担当: 伸びた投稿の型抽出と、4本柱ごとの需要定点観測。
- 031 スミ｜進行管理
- 担当: 公開を確認した投稿のステータス（STATUS=公開済み）と投稿URLを管理台帳へ一括書き戻し。
- 034 アワセ｜進行管理
- 担当: X予約一覧と管理台帳を照合し、重複・欠落・時刻不整合を自動検出。
3. Threads事業部（5人）
子育て・育児軸に特化し、共感と価値提供を行う事業部。
- 001 ツヅリ｜事業部長・制作（モデル: sonnet）
- 担当: 育児軸の投稿案作成。発信者設定とトーンを厳守。
- 002 カゾエ｜品質管理（モデル: haiku）
- 担当: 文字数、改行密度、重複表現を機械的に検査。
- 003 ノビ｜分析（モデル: sonnet）
- 担当: 閲覧数・エンゲージメントデータに基づく型の抽出。
- 004 ヘンジ｜カスタマー対応（モデル: sonnet）
- 担当: 届いたコメントへの返信文案の作成（相手の具体に必ず触れる）。
- 005 アイサツ｜渉外（モデル: sonnet）
- 担当: 同ジャンルの人気投稿へのコメント案作成（実体験を添える）。
4. ブログ編集部（4人）
オウンドメディアの執筆・検査・記録・外部配信を担う中核部隊。
- 029 モンバン｜品質管理
- 担当: 公開前チェックリスト（75点基準）の機械検査。文字数1,500字以上、内部リンク2本以上、検索クエリ型タイトル等を判定。
- 実績: 初日に全112本の記事を検査し、内部リンク不足の記事を即座に検出。
- 032 キチョウ｜記録管理
- 担当: 本番公開された記事が実測管理表に登録されているかを突合（記録漏れ防止）。
- 033 テンサイ｜配信管理
- 担当: engineering柱の記事がZennやQiitaの転載用ファイルになっているかを検査。
- 035 ウラトリ｜事実確認
- 担当: 「複数社を比較した」等の一次体験記述を抽出し、人間への確認依頼として提示。
5. 経営企画部（2人）
判断の型を固定し、人間の思いつきによるブレを防ぐ部署。
- 018 カセツ｜企画（モデル: opus）
- 担当: 実測データからの改善仮説立案。過去に棄却された仮説を記憶し、二度と再提案しない。
- 019 タナ｜内部監査（モデル: opus）
- 担当: 定型業務がループ6要素（Automations・Worktrees・Skills・Connectors・Sub-agents・Memory）で仕組み化されているかを棚卸し。
6. 情報システム部（1人）
- 030 トドケ｜配信監査
- 担当: Zenn・Qiitaの公開APIとローカルファイルを突き合わせ、配信が本番に正しく届いているかを監査。
7. note事業部（5人・2026-10-07新設）
- 036 ハカリ｜品質管理（モデル: sonnet）
- 担当: noteの記事を公開する前に、「全文」「そのまま使える」のような中身より強い言い切りを拾い、載せる元のファイルと突き合わせて事実かを判定する。点数より、公開を止める条件を優先する。
- 037 ツムギ｜制作（モデル: sonnet）
- 担当: ブログ原稿と自社の指示書を素材に、noteの記事原稿を作る。表や「全文」「そのまま使える」のような強い言い切り、確認のない体験を避けて書く。
- 039 カンソク｜計測
- 担当: noteのダッシュボードを読み、記事ごとのインプレッション・ページビュー・スキ・売上を記録する。
- 040 ミキワメ｜判定
- 担当: 判定日に、Xの告知からnoteの購入までの段階を並べ、止まった所と見直し案を書く。数が小さい段階は「判断できない」と書き分ける。
- 041 カカゲ｜公開
- 担当: noteの記事を、社長のGOを得て1本ずつ公開・更新し、公開後に原稿と照合する。
社内設備一覧（50件の社内システム、2026-10-19時点。ワークフロー42本＋ローカル実行の道具7＋フック1）
「自動ドアに名前を付けてはいけない」という原則に基づき、LLMの判断を伴わない定型スクリプトやCI/CDパイプラインは「設備」として管理しています。
- 定期監視・収集（GitHub Actions / cron）:
- 週次記事メトリクス自動収集（Search Console実測）
- 本番HTMLヘルスチェック（タグ欠落・重複監視）
- Threads・X投稿頻度および予約枠検査（毎日定時実行）
- ガードレール・安全弁（Git hooks / scripts）:
pre-push: mainブランチへの直接pushをブロックpre-commit: gitleaksによるシークレット漏洩防止、ファイル相対リンク検証、029記事品質検査protect-loop-baseline: 運用基準ファイルの不正改定防止
30日間の運用実績サマリー
| 指標 | 実績 |
|---|---|
| 在籍AI社員数 | 20人（社員名簿の行数、2026-10-07時点） |
| 稼働設備数 | 47件（GitHub Actionsのワークフロー40本＋ローカル実行の道具6＋フック1、2026-10-07時点） |
| アウトプット | XとThreadsの投稿案、ブログ記事の下書き（本数は数えていないため載せない） |
| AIツールの費用 | 定額サブスクの範囲（金額は整理中のため載せない） |
| 社長の作業時間 | 計測していないため載せない。公開のGOと施策の選択は人間が行う |
組織運営の原則：人間に残る「2つのゲート」
AI社員を何人増やしても、会社を経営し、責任を取るのは人間です。 自社では、以下の「2つの決定ゲート」を絶対にAIへ委譲せず、人間が握り続けます。
- ゲート①：本番公開・マージの判断
- 事実確認に偽りがないか、クライアントの守秘義務を侵していないか、ブランドの価値を損ねていないかを確認し、マージ・公開ボタンを押す。
- ゲート②：次週の戦略・方針の選定
- 分析担当が提示した改善候補の中から、会社のリソースをどこへ配分するかを決める。
作業（Do）はAI社員と設備へ任せ、意思決定（Decide）と責任（Responsibility）だけに人間が集中する。 これが、すきま時間で大きな事業を動かす「1人法人1000馬力化」の核心です。
