MonoOps

はじめに — なぜこのメソッドが必要か

AI を業務に取り入れる流れが加速する一方で、ツールを揃えるだけでは事業は変わらない。一人〜小規模で複数事業を動かす経営者が直面する典型的な問題は、情報の分散、AI コンテキストの欠落、横断管理の限界の3つに集約される。

これらは個別の問題ではなく、運用構造の不在から起こる。本書が提案する「MonoOps（Monorepo Operations Method）」は、モノレポをベースに、AI 秘書を組み合わせて、複数事業を一人〜小規模で運営するための方法論だ。

なぜこのメソッドが必要か（背景・想定読者・スタンス）を詳しく読む→

メソッドの全体像 — 1枚で見る

MonoOps の中核は、ただ1つの命題に集約される。

事業全体を1つのコードベース（モノレポ）として扱い、AI に横断管理を委譲する。

「事業全体」とはコードだけではなく、マーケティング・契約・経理・運用・研究など、すべての文書・状態・履歴を含む。それらを1つの git リポジトリにまとめ、ディレクトリ構造を組織構造の写像として設計する。

5つの原則

1. 原則1: 事業を1つのモノレポに統合する — ディレクトリ構造は組織構造の写像
2. 原則2: 重い資産は外部、軽い情報は中央 — 軽情報モノレポ + 重資産 GDrive
3. 原則3: AI 秘書に横断管理を委譲する — 中央管理層を AI に
4. 原則4: 自動化より仕組み化（複雑性排除） — 完全自動より半自動
5. 原則5: クリーンコードのベストプラクティスを実務に適応 — 命名規則と統一構造で蓄積

メソッドの全体像とディレクトリ = 組織構造の写像を詳しく読む→

原則1: 事業を1つのモノレポに統合する

一人で複数事業を動かす段階に入ると、リポジトリを案件ごとに分ける発想は致命的なオーバーヘッドを生む。「あの処理を別案件で再利用したい」が事実上不可能、Hermes Agent に何かを頼むたびに事業構造をゼロから説明する、PC 死亡時の復元が指数関数的に複雑化する、といった具合に。

解決は単純で、全部を1つの場所に統合すること。コードだけでなく、文書・契約・状態・履歴も含めて、ディレクトリ構造を組織構造の写像として設計する。

世界では Ben Gregory（Kasava CEO）が「AI is all about context. And this monorepo is our company — not just the product.」と語り、DHH（Basecamp）が「Run a small team, not a tech behemoth? Embrace the monolith and make it majestic.」と Majestic Monolith を提唱している。

原則1を詳しく読む（実装手順・失敗パターン・海外引用）→

原則2: 重い資産は外部、軽い情報は中央

モノレポに「全部入れる」方針を選ぶと、最初に直面する壁が重い資産だ。画像・動画・PDF を git に入れるとリポジトリが肥大化する。ソフトウェア工学の世界では、ソースコード（軽い情報）と Asset（重いメディア）は分離するのが定石。これを事業運営にも適用する。

実装の核は「軽い情報は中央、重い資産は外部、symlink で繋ぐ」の3点。軽い情報はモノレポ git 内、重い資産は projects/assets/ に集約して Google Drive for desktop で同期、各プロジェクトから symlink で参照、**/assets/ は .gitignore で除外。

Steph Ango（Obsidian CEO）の言葉を借りれば、「File over App」の哲学。データはアプリではなくファイルで持つ。

原則2を詳しく読む（symlink 設計・GDrive 同期・PARA との関係）→

原則3: AI 秘書に横断管理を委譲する

一人で複数事業を回すと、進捗監視・期限追跡・優先順位整理・横断分析・戦略判断の管理職務が膨大になる。これを人力でやろうとすると必ず破綻する。秘書を雇うコストが見合わない規模では、AI 秘書を中央管理層として常駐させる。

実装の核は4つ: (1) 専用ディレクトリ secretariat/ の設置、(2) state（DASHBOARD.md）と action（NOW.md）の分離、(3) AI エージェントの人格定義、(4) frontmatter による状態管理。

朝、ターミナルで claude を起動して「ブリーフィング」と打つだけで、AI 秘書が全 frontmatter とカレンダーを並列収集し、優先順位付き TODO を返す。経営者は実行に集中できる。

原則3を詳しく読む（人格定義・朝の運用ループ・実装ファイル構成）→

原則4: 自動化より仕組み化（複雑性排除）

「自動化」は魅力的だが、一人〜小規模事業の運用において、複雑な自動化は多くの場合逆効果になる。動かなくなった時に直せない、ROI が低い、デバッグに時間を吸われる。

本メソッドは「自動化」より「仕組み化（pattern化）」を選ぶ。完全自動ではなく半自動。人手が介入できる余地を残す。「動き続けること」を最優先、自動化は補助。

判断軸は3つ:「動かなくなった時、自分で直せるか」「半年後の自分が思い出せるか」「コストに見合う頻度か」。3つすべて Yes でない限り、その自動化は採用しない。

原則4を詳しく読む（autocommit・hooks・スキル化の具体例）→

原則5: クリーンコードのベストプラクティスを実務に適応

ソフトウェア工学のクリーンコード原則の本質は「6ヶ月後の自分が読んでも理解できる」こと。事業運営も同じだ。命名規則の統一、frontmatter での状態管理、ディレクトリ構造の明示性、共通テンプレ + 個別カスタムの組み合わせ。これらを揃えることで、知見が蓄積する構造になる。

ただし、教科書通りに守ると硬直化する。過度な DRY・早期最適化・マイクロサービス化は避ける。実務で動く形に適応するのが鍵だ。

原則5を詳しく読む（命名規則・frontmatter スキーマ・PARA との対応）→

実装の具体

5原則を理解しただけでは実装には踏み込めない。本書は3つの観点で実装の具体を扱う。

~/Desktop/projects/
├── .claude/                # 横断的な agents / rules
│   ├── agents/argus.md     # AI 秘書の人格定義
│   └── rules/              # frontmatter スキーマ等
├── _templates/
│   └── client-project/     # 雛形（マスター）
├── assets/                 # 重い資産（GDrive 同期、.gitignore）
├── scripts/
│   ├── git-autocommit.sh   # 自動 commit/push
│   └── launchd/            # plist のバックアップ
├── biz/                    # 法人事業部
│   ├── website/            # コーポレートサイト（独立 git）
│   ├── product-a/          # 自社 SaaS（独立 git）
│   ├── marketing/          # マーケティング・出品管理
│   ├── playbooks/          # 再利用可能な型のストア
│   └── ...
├── personal/               # 個人ブランド発信部
│   ├── note/
│   ├── youtube/
│   ├── x/
│   └── substack/
├── products/               # 自社プロダクト
├── billing/                # 経理
├── clients/                # クライアント案件
│   ├── platform-a/{name}/  # プラットフォーム A 経由
│   ├── platform-b/{name}/  # プラットフォーム B 経由
│   └── direct/{name}/      # 直接契約・卒業組
├── learning/               # 自己研鑽
└── secretariat/            # 取締役室・AI 秘書
    ├── CLAUDE.md
    ├── DASHBOARD.md        # 全体状態の俯瞰
    ├── NOW.md              # 今この瞬間の優先タスク
    ├── BACKLOG.md
    ├── tasks/              # 部署別タスクファイル
    └── data/
        └── decisions.md    # 戦略級判断ログ

ディレクトリ構造の設計指針: 第1層（モノレポ・ルート）/ 第2層（部署）/ 第3層（プロジェクト・案件）の3層構造。ツール選定: Hermes Agent、Git+GitHub、macOS launchd、Google Drive、各種 MCP 統合、TimeRex / Stripe / Resend / MicroCMS、Vercel / Supabase / Next.js。autocommit / hooks / AI 秘書の構築: シェルスクリプト30行 + plist 50行で動く最小構成。

実装の具体を詳しく読む（ツール選定基準・コード例・hook 設定）→

世界の先駆者たち

本メソッドは私の独自手法ではない。世界各地で同じ思想が異なる文脈で実践されてきた。本書のルーツとなる6人を挙げる。

• DHH（Basecamp）: 「Majestic Monolith」 — 大企業向けパターンを小規模チームに持ち込むな
• Pieter Levels（@levelsio）: 「One PHP file. One server. Many products.」 — 一人で複数プロダクトを単一 VPS で運営
• Tiago Forte: 「PARA」 — Projects / Areas / Resources / Archives でディレクトリ = 知識構造
• Steph Ango（Obsidian CEO）: 「File over App」 — データはアプリではなくファイルで持つ
• Ian Fisher: 個人モノレポ運用 2,300+ コミット、2026年1月 HN フロントページ
• Ben Gregory（Kasava）: 「AI is all about context. And this monorepo is our company」

本メソッドの哲学は、これら6人の主張の交点に立っている。

世界の先駆者たちを詳しく読む（各引用文・URL・本メソッドとの対応関係）→

実例 / ケーススタディ

本メソッドが「机上の空論ではなく、実装が動いている」ことの証拠として、4つの実例を扱う。

• pixel-office: モノレポ可視化 Web アプリ — Hermes Agent セッションをピクセルアートオフィスで可視化
• AI 秘書 / secretariat: 中央管理層の実装 — 朝のブリーフィング・期限監視・横断分析
• autocommit: 仕組み化の典型 — 30行のシェルスクリプト + plist で日次自動 push
• クライアント案件運用: 統一構造の実装 — 全案件が同じディレクトリ構造、案件数が増えても管理コストが線形に増えない

実例を詳しく読む（pixel-office / Argus / autocommit / 案件運用）→

よくある失敗パターン

メソッドを採用する際、典型的に陥る失敗が4つある。事前に知っておくことで回避できる。

1. 「全部マイクロサービスに分ける」: 一人事業の規模では使わない複雑性を抱え込む
2. 「自動化しすぎて壊れた時に直せない」: 過剰な CI/CD、複雑なワークフロー
3. 「複数 AI ツールを並列で使う」: コンテキストが分散し横断分析できない
4. 「Notion / Trello / Asana 等の SaaS 乱立」: 月額コスト累積、データ分散、AI から横断的に見えない

いずれも「自分の規模を超えた仕組みを早期に導入する」ことから生まれる。シンプルさは武器、複雑さは敵。

失敗パターンを詳しく読む（各失敗の回避策・実例）→

このメソッドが向く人 / 向かない人

メソッドには適合範囲がある。万人向きではない。

向く人: 1〜10人以内のチームで複数事業を運営し、IT リテラシーがあり、Hermes Agent に抵抗がなく、論理派・本質派で運用設計を整えたい層。向かない人: 50人以上の組織、IT リテラシーなし、手元で動かす事業がない、短期収益10倍志向、「全部 AI に丸投げしたい」スタンス。

適合判断を詳しく読む（中間ゾーンのカスタマイズ方針含む）→

今日から始める3ステップ

本メソッドの基盤は半日〜2日で立ち上がる。完璧を目指さず、動き始めることが最優先。

3ステップで動き出した後、Step 4（オプション）として autocommit を入れると、PC 死亡時の最大ダメージは「直近24時間分」に限定される。動かしながら各原則を深く理解していくのが正しい順序だ。

3ステップを詳しく読む（具体的なコマンド・ディレクトリ構成・運用ループ）→

FAQ と関連リソース

本メソッドの採用にあたってよくある質問:

• 既存の複数リポジトリからの移行 → 段階的に。新規は projects/ に作る、既存は独立 git のまま配置
• チーム展開 → 1〜10人想定、10〜30人は frontmatter に assignee 追加で対応可
• 機密情報 → GitHub Private 必須、frontmatter に書いても外部に漏れない
• Mac じゃないとダメか → Linux/Windows でも動く（launchd を cron + systemd / タスクスケジューラに置換）
• 月額コスト → Claude Pro $20/月 + GitHub Private 無料 + Google Drive 数百円程度。合計 $30〜$120

FAQ を詳しく読む（移行・チーム展開・機密情報・コスト・8項目）→

関連リソース（海外文献・関連書籍・ツールドキュメント）は別ページにまとめてある。

関連リソースを見る（海外文献URL・参考書籍・ツール一覧）→

まとめ

MonoOps は「事業を1つのコードベースとして扱い、AI に横断管理を委譲する」運用思想だ。5つの原則と実装の具体を理解し、3ステップで動かし始める。

世界各地で同じ思想が実践されている中で、本メソッドは一人〜小規模事業 × AI ネイティブという特定の文脈に最適化された方法論として位置づけられる。

規律のある運用設計は、AI 時代の経営者の最大の武器になる。