moz の位置づけが変わる
従来: 「mozを通して仕事をしてデータを集約」 するアプリ。
これから: 「メンバーの現状ワークフロー（スプシ・Doc）に moz が出向いて読み取り、社の記憶として整え、MFに送り、LLM的に活用する」プラットフォーム。
集約のために働き方を変えさせるのではなく、moz側がメンバーの現場に出向いていく設計に転換する。
2026-05-18 戦略議論で追加された論点:
- メンバーはスプシ・Docで仕事している現実を前提に、moz は集約強制でなく「読み取り側」に徹する
- moz は「並べる・見る・MFに送る・LLM化」プラットフォームに進化
- Phase 11 として MF送信パイプ復活、Phase 12 として LLM化（pgvector）を構想
A戦略レイヤー
1moz の進化 — 4つの役割
| 役割 | 内容 | 状態 |
|---|
| 並べる | 案件・取引先・タスク・クリエイター・財務を一覧で見せる | Phase 1〜9で実装済 |
| 見る | KPI・お知らせ・ダッシュボードで会社の状態を可視化 | Phase 8〜9で実装済 |
| 送る | 会計（MF）に仕訳を送る経理パイプ。「集約 → 会計の前段」 | Phase 11で復活予定 |
| 賢くなる | 過去案件・構成案・レポートをナレッジ化し、AIが「過去の類似案件は？」「このクライアントの傾向は？」を引ける | Phase 12で新規 |
2データ3レイヤー設計
mozが扱うデータを構造化度で3層に分けて戦略を変える。「すべてmozに集約」ではなく、レイヤーごとに最適な取込方法を採る。
L1構造化データ
案件・取引先・タスク・クリエイター・財務目標
戦略: moz DBが Source of Truth。MCPで読み書きを公開（Phase 10）。メンバーは moz UI または AI 経由で操作。
L2半構造化データ
案件進行用Googleスプレッドシート（担当者ごとの管理表）
戦略: Linked Sheet型として登録、定期スナップショット＋差分検知で moz に取り込む。書き戻しは禁止（双方向同期は競合で詰む）。メンバーは現状のスプシで仕事を続ける。
L3非構造化データ
構成案Doc、案件レポート、メールスレッド、Slack議論
戦略: 原本はDriveに残し、moz はリンク参照＋テキスト抽出を保管。ベクトル化してpgvectorに格納し、semantic searchで「過去の類似案件」を引けるようにする（Phase 12）。
3Phase 10-12 ロードマップ
PHASE 10
MCP化
AIの "口" を作る
54本のMCPツールを公開。Claude等のAIから moz の全データをCRUDできる基盤。Sanctum PAT + ability + is_admin制約 + 監査ログ。
PHASE 11
MF送信パイプ
会計の "出口" を作る
既存のMF API連携フェーズ（停止中）を再開。月次で moz から MF に仕訳を送信。「並べる・見る」だけで終わらせず "送る" で経理を閉じる。
PHASE 12
LLM化（ナレッジ）
moz が "賢くなる"
構成案・レポート・メールを pgvector で semantic search 可能に。MCP経由でAIが「過去の類似案件」「このクライアントの提案傾向」を即答できる "モカLLM" 状態に。
4検討論点（要回答）
-
L2 スプシ連携の同期方式
どのモードでメンバーのスプシを moz に取り込むか。
選択肢: (a) Linked Sheet（リンク登録＋定期取込） / (b) Import（一度取り込んで縁切り） / (c) ハイブリッド
推奨: (a) Linked Sheet型 — メンバーのワークフローを変えない
-
L3 構成案Docの蓄積方法
Driveの構成案ドキュメントをどう moz に保管するか。
選択肢: (a) Driveリンク参照のみ / (b) テキスト抽出してmoz保管 / (c) PDFスナップショットも保管
推奨: (b) — ベクトル化用にプレーンテキスト保管、原本はDriveのまま
-
ベクトルDBの選定
Phase 12 で使うベクトル検索の基盤。
選択肢: (a) PostgreSQL pgvector（既存DB拡張） / (b) Pinecone等の外部サービス
推奨: (a) pgvector — インフラ追加なし、初期データ量なら十分
-
MF送信再開のタイミング
Phase 11（MF送信パイプ）の着手タイミング。
選択肢: (a) Phase 10完了直後 / (b) Phase 12と並行 / (c) Phase 12後
推奨: (a) — "送る" がないと "並べる・見る" は片手落ち。早く価値を閉じる
5設計原則
- メンバーの現状ワークフローを壊さない — スプシ・Docはそのまま使う。mozが出向く側
- 書き戻し原則禁止 — moz → Sheet/Doc の書き戻しは競合で詰む。一方向取込が安全
- 原本はDrive、コピーはmoz — 真実の源を二重化しない（L3）
- ナレッジは社内資産 — 構成案・レポートはモカに蓄積されてこそ価値。Phase 12でAIから引けて初めて本当の財産になる
BPhase 10 詳細 — MCP化
moz（モカ基幹システム）を Model Context Protocol サーバーとして公開。Claude Code等のAIアシスタントから自然言語でデータ操作できる基盤を構築する。詳細設計書: docs/mcp_design.md
54公開ツール
20Ability
9対象テーブル
7-12実装工数(日)
6アーキテクチャ
[ユーザー端末] [Heroku: moz-mocha]
Claude Code / Claude Desktop
│ Laravel App
│ stdio ┌──────────────────┐
[ブリッジプロセス] ──── HTTP SSE ────▶ │ /mcp エンドポイント │
(Node.js 薄いproxy) │ McpToolService │
│ Sanctum PAT認証 │
└──────────────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
[PostgreSQL] [Redis Queue] [Slack API]
7Ability リスト（20種）
| リソース | read | write | delete admin |
|---|
| 取引先 (clients) | ○ | ○ | ○ |
| 案件 (projects) | ○ | ○ | ○ |
| タスク (tasks) | ○ | ○ | ○ |
| クリエイター (creators) | ○ | ○ (メモのみ) | — |
| 請求書 (invoices) | ○ | ○ (ステータスのみ) | — |
| 広告アカウント (ad_accounts) | ○ | — | — |
| KPI / 財務 (financials) | ○ | ○ (is_admin必須) | — |
| ユーザー (users) | ○ | — | — |
| お知らせ (announcements) | ○ | — | — |
| タグ (tags) | ○ | ○ | ○ |
⚖ destructive操作の追加制約: delete系ability および projects.mark_lost / invoices.mark_paid は is_admin=true のユーザーのみ実行可能。PAT発行UIで is_admin ユーザーのみ表示、McpToolService 実行時も再チェック（2重防御）。
8MCPツール一覧（54本）
| カテゴリ |
safe |
normal |
destructive |
合計 |
| 取引先 (clients) | 3 | 7 | 1 | 10 |
| 案件 (projects) | 3 | 10 | 2 | 13 |
| タスク (tasks) | 2 | 4 | 1 | 7 |
| クリエイター (creators) | 3 | 2 | 0 | 5 |
| 請求・支払 (invoices/payslips) | 4 | 2 | 1 | 7 |
| 広告 (ad_accounts) | 4 | 0 | 0 | 4 |
| KPI / 財務 (financials) | 2 | 1 | 0 | 3 |
| ユーザー (users) | 2 | 0 | 0 | 2 |
| タグ (tags) | 1 | 1 | 1 | 3 |
| 合計 | 24 | 27 | 6 | 54 |
9操作分類と削除フロー
safe 読み取り専用
listや検索系。即実行。監査ログは記録しない。
制限: 300req/分
normal 書き込み
create / update / complete。即実行＋全件監査ログ。
制限: 60req/分
destructive 破壊的 admin
delete / mark_lost / mark_paid。is_admin必須＋dry-run→confirm→実行。
制限: 20req/分
削除フロー（destructive）
Step 1: AIがツール呼び出し（confirm なし）
↓
is_admin チェック → ability チェック
↓
dry-run 実行（DBを変更しない、影響範囲を JSON で返却）
Step 2: AI がユーザーに影響範囲を提示し確認を求める
↓
ユーザーが承認
Step 3: AI が confirm=true で再呼び出し
↓
DB トランザクション + 監査ログ + 実行
10Phase 10 実装ロードマップ（合計 7〜12日）
Step 0: 事前準備0.5日
設計書承認、PAT発行UI配置確定、proposals機能の削除完了
Step 1: PoC（safe 5本）1〜2日
Sanctumセットアップ、/mcpルート、clients/projects のread系でブリッジ疎通
Step 2: 取引先・案件 Write系2〜3日
最重要フェーズ。create/update/add_note、監査ログ実装
Step 3: destructiveフロー1〜2日
delete系＋mark_lost、is_admin判定とdry-run基盤
Step 4: タスク・クリエイター1〜2日
tasks全7本、creators 3本
Step 5: 請求・KPI・広告・その他1〜2日
invoices/payslips 7本、financials 3本、ad_accounts 4本、users/tags/announcements 6本
Step 6: レート制限・仕上げ0.5〜1日
ThrottleRequests設定、setup.sh整備、結合テスト
CPhase 11/12 構想
11Phase 11 — MF送信パイプ復活
既存の「MF API連携フェーズ」（Step 0データ蓄積待ちで停止中）を Phase 10 完了後に再開する。
- 月次の請求・支払データを moz から MF に仕訳として送信
- 期首残高入力＋4月締めなど、停止中の前提条件を解消
- MCPツール
invoices.update_status / invoices.mark_paid の延長線で「送信ジョブ」を実装
- 送信前のdry-run（仕訳プレビュー）を必須化
12Phase 12 — LLM化（ナレッジ）
moz自体がモカのビジネスに詳しくなる "モカLLM" 化フェーズ。
取り込むデータ
- 過去の構成案Doc（クリエイター・案件・カテゴリ別）
- 案件レポート（実施後のKPIまとめ）
- クライアントとのメールスレッド（既存のGmail自動取得を拡張）
- Slackの案件議論（オプション、機密性検討）
技術構成（提案）
- 埋め込み: OpenAI
text-embedding-3-small または Claude (Anthropic) 経由
- ベクトルストア: PostgreSQL
pgvector 拡張（既存DBに同居、追加インフラ不要）
- 取り込みパイプライン: Driveファイル → テキスト抽出 → チャンク分割 → embedding → DB保存
- 検索: MCPツール
knowledge.search を追加。AIが「過去の類似案件は？」を引ける
想定ユースケース
- 「コスメ系で轟ちゃんを起用した過去案件の構成案パターン」を一発で引く
- 「このクライアントは何を重視する傾向があるか」をメール履歴から要約
- 新規案件の構成案ドラフトを過去案件をベースに自動生成
D次のアクション
13意思決定が必要な項目
- 戦略全体の承認 — Phase 10/11/12 のロードマップでいいか
- 4つの検討論点への回答（§4）— 推奨案でOKか、別案にするか
- proposals削除の実装着手（Phase 10 Step 0 の前提）
- Phase 10 着手タイミング — proposals削除後すぐか、別タイミングか