nanco-knowledge
少人数チームが AI を司令塔として使い、
マーケ・営業・CS のアウトプットを最大化するためのナレッジベース
4人体制（開発中心、マーケ専任なし）で nanco を運営する私たちが、AI と一緒に毎日の判断・制作・レビューを回すための仕組みです。事実・トーン・戦略・役者・Playbook・Skill を1つのリポジトリに集約し、誰が読んでも同じ判断ができる状態を目指しています。
TL;DR
4 人 + AI 運営の全仕組みを 1 ページに。 6 層アーキ × 16 役者 × 7 Playbook（全 7 構築済）。 SoT は nanco-knowledge/。
ミッション
少人数で大量のアウトプットを出すために、AI を「下書きと集約」、人を「判断と哲学」に分担する運営モデルを採用しています。
運営方針の中核
「1人マーケ × AI」を効率最大化する。大企業向けフレームワーク（CDP導入、専任SEOチーム前提、フルファネルABM 等）はそのまま採用しません。提案時は必ず「4人で回せるか」を自問します。
6層アーキテクチャ ＋ 学習ループ
上から下に参照します（上位層が下位層を呼ぶ）。下位から上位への依存はしません。学習ループ（decision-log と pattern-library）は全層を横断的に参照されるメモリです。
playbooks/
.claude/commands/オーケストレーション層
decision-log/ に重要判断を Compiled Truth + Timeline 形式で記録し、pattern-library/ に勝ちパターン・アンチパターンを結晶化します。次の Playbook 実行時に取り込まれます。
迷ったらここを参照する
事実の単一ソース（SoT）。重複を増やさず、ここから引いてくるのが原則です。
| 知りたいこと | SoT |
|---|---|
| 製品の事実（機能・料金・受賞・対応業種） | core/product.md |
| 会社の事実 | core/company.md |
| nanco 用語（アイテム・フォルダ・属性 等） | core/glossary.md |
| 文体・トーン・NG表現・顧客呼称 | core/tone-guide.md |
| ビジュアルスタイル（カラー / 線質 / キャラ / 構図） | core/visual-style-guide.mdNew 2026-05-18 |
| ブランド仮説・旗印 | insights/05-brand-hypothesis.md |
| 哲学・原点・やる/やらない | insights/01-who-we-are.md |
| 運営モデル（4人 × AI） | insights/08-how-we-operate.md |
| マーケ全体方針 | strategy/marketing-master-plan.md |
| 直近の実行計画 | strategy/execution-plan-2026-05.md |
| KPI 定義 | strategy/kpi-definition-2026-05.md |
| どの戦略フレームワークを使うか | strategy/strategy-selection-rule.md |
| 役者一覧 | .claude/agents/README.md |
| Playbook 一覧 | playbooks/README.md |
| Skill 一覧 | skills/README.md |
| 判断履歴と経緯 | decision-log/README.md |
| 勝ちパターン / アンチパターン | pattern-library/README.md |
16 の役者システム
各役者は razor-thin スコープ（1 つのことを深くやる）で設計されています。評価系の役者は読み取り専用、書き込みは Operator 役だけ。意見が割れたときは CEO が tie-breaker を担います。2026-05-14 に project-manager（スケジュール策定 専門）を追加して 14 役者になり、その後 copy-creator-hero（高ステークスな外向けコピー専用、2026-06-12）を加えて現在 16 役者です。
戦略・判断レイヤー（4）
nanco-ceo-review
nanco の旗印に合うかを判定。さらに、複数 reviewer の意見が割れた時の最終判断（tie-breaker）を担う。
strategy-router
タスクが PLG / Traction / PLS のどれを主担当にすべきかを判定する router。
feasibility-check
4 人運営で本当に回るかを判定。工数感・自動化余地・大企業向けフレームワークの混入を確認。
project-manager
スケジュール策定だけを担当。Top N 提案 / タイムライン / 容量チェック / 詰まり解消の選択肢 A/B/C を返す。2026-05-08 で削除した pm-orchestrator（自動オーケストレータ）とは別物（人発火・razor-thin）。
Director レイヤー（3）
director-plg-review
PLG 戦略整合性のみ評価。サインアップ動線・アクティベーション・TTV 短縮の観点。
director-traction-review
Traction 戦略整合性のみ評価。19チャネル・広告クリエイティブ・3軸テスト。
director-pls-review
Product-Led SEO 戦略整合性のみ評価。検索意図 × 責任ページの整合。
実行・審査レイヤー（8）
copy-creator
ルーチンのマーケコピーを作成する Operator（sonnet）。LP 本文 / SNS / メール件名 / CTA / A/B バリエーション量産。
copy-creator-hero
「最も読まれる 1 行」だけを書く Operator（fable 固定、2026-06-12 新設）。LP Hero / Tagline / PR 見出し・リード / 主力広告の見出し。語選択が成果を左右する高ステークス外向けコピー専用。
visual-creator
画像 / 動画 生成。Widgetbook + Storybook + HyperFrames を経由してレンダリング。
brand-check
ブランド整合性のみ評価。文体・絵文字・自称最上級などを core/tone-guide.md に照らす。
ai-tone-check
AI 出力特有の構造・語彙パターンのみ評価（16 軸）。brand-check が nanco 固有 NG リスト担当に対し、本役者は LLM 共通の統計的兆候（抽象総括 / 三連並列 / メタ言明 / burstiness 等）を担当。
art-director
マーケティング視覚構成のみ評価。デバイスフレーム / 背景 / レイヤー / スケール / 余白の5軸。
demo-data-curator
デモデータの整合性のみ評価。業種一貫性 / 数値整合 / 単位 / 価格レンジ / 画面間連続性。
analyst
GA4 / 広告KPI / AI引用テスト結果 / TTV / オンボ離脱率 等の集計・解釈。
補助レイヤー（1）
researcher
マーケ書籍 / 顧客ヒアリング transcripts の長尺資料を、メインコンテキストを汚さず読み込み、構造化インサイトを返す。
CEO tie-breaker のルール（2026-05-08 確立）
複数 reviewer の判定が割れたとき、自動の多数決は絶対にしません。すべての reviewer の出力をそのまま並べて nanco-ceo-review に渡し、「nanco の本質と合致するか」「どの軸を重く見るか」を明示的に判断します。多数決すると評価軸の重みづけが暗黙になり、説明できない判定になるためです。
タスク → 役者の振付
「1つのタスクを、どの役者を、どの順序で動かして、どこで人レビューを入れて完成させるか」を記述しています。直列・並列・混合の3パターンを使い分けます。
Claude Code に向かって / で発火
Claude Code 公式のスラッシュコマンド機能。/<name> で .claude/commands/<name>.md がプロンプトとして実行されます。明示しなくても description のキーワードマッチで Claude が候補を提示することもあります。
render-nanco-app-mockup.md 経由nanco-marketing-stories（見た目専用 repo）の Storybook story を業種別に PNG 量産する web admin 本命ルート使い方の例
「アパレル業種のリスト画面を LP の hero に欲しい」と話せば、/app-screen-as-asset が想起されます。明示発火したいときだけ /app-screen-as-asset アパレル list LP-hero のように打ちます。スマホ管理画面の業種スクショ量産は /marketing-screen-as-asset、nanco-next 本物の画面で撮りたいときだけ /web-screen-as-asset を選びます。
手の道具 ／ タスク実行のレシピ
役者（agents）が「人格」だとすれば、Skill は「手の道具」です。Operator 役が Skill を呼び出してタスクを実行します。SoT は skills/README.md。直近 1 ヶ月で ビジュアル素材作成の skill が大きく増えたため、用途別の入口チャートを冒頭に置いています。
web / マーケ素材スキルの入口チャート（2026-05-19 更新）
用途で 1 本目に呼ぶ skill を引きます。組み合わせる場合（例: モバイル mockup を作って LP に挿し込む）は「→」で連結します。
- モバイル app の画面を実機 SS から React で再現したい →
render-nanco-app-mockup.md（本命）。旧 HTML stack のrender-app-screen.mdは deprecated。 - 業種別の管理画面スクショを量産したい →
render-marketing-screen.md（本命、見た目専用 repo、mock 不要、build 3 秒）。 - nanco-next 本物の画面で撮りたい →
render-web-screen.md（production component を storycap、mock 多め）。 - mockup を LP セクションに静的に組み込みたい →
integrate-mockup-into-lp.md（MockupCard + 業種 dataset + 影 / 角丸 / 背景の標準化済み）。 - LP Hero で「触ってる感」を出したい（scripted UI demo） →
create-scripted-ui-demo.md（motion.dev、6 業種クロスフェード、内部座標オーバーレイ原則 / iOS transition / Material ripple を内包）。 - LP セクションの背景パネルを量産したい →
generate-stage-background.md（prompt pack v1 を SoT に持つ、ChatGPT 経由）。 - アイテム名 + 業種から商品写真風画像が要る →
generate-item-images.md（Pollinations.ai / Flux）。 - mockup と staging で差分が出ている →
visual-diff-review-loop.md（Codex / Gemini に diff 出させて loop で潰す。13 iter で staging fidelity 達成の実例付き）。 - 新画面を始める前に Web ↔ mockup の地図が欲しい →
replicate-nanco-next-ui.md（W2-W5 着手前に必読。重要ファイル index + checklist）。 - Chrome MCP の screenshot が保存パスを返さない →
extract-chrome-mcp-screenshot.md（session jsonl から base64 抽出で救済）。
3 路線の関係（A: LP 同居 React、B: PNG 派生、C: 動画フレーム入力）の経緯は skills/render-app-screen.md 冒頭の「路線整理」と decision-log 2026-05-11-app-screen-as-asset-skill.md / 2026-05-16-mockup-standard-mockupcard.md / 2026-05-19-scripted-demo-iteration.md を参照。
司令塔（メタスキル）
commander.mdどの core / insights / strategy / workflow / skill をどの順で使うか決めるオーケストレーション protocol
コア技術 ─ コピー
copy-creation-nanco.mdnanco のトーン・観点に沿ったマーケコピー作成（横断スキル）
ビジュアル素材 ─ モバイル app 画面
render-nanco-app-mockup.md本命: nanco_hp_2026 配下app/(dev)/mockup-screens/で iPhone 16 Pro Max @3x（1206×2622）ネイティブ座標の React mockup を作る / 修正。実機 SS から色 picking + 共通 chrome 統一 + Cupertino Sheet パターンrender-app-screen.md⚠️ deprecated（2026-05-19 路線整理）。新規入口はrender-nanco-app-mockup.md。HyperFrames 用 HTML フレームが要るときだけ本 skill 後半の C 路線を参照replicate-nanco-next-ui.mdW2-W5 着手前に必読。nanco-next の web 画面を nanco_hp_2026 mockup として staging fidelity で再現するための map（重要ファイル index + checklist）extract-flutter-tokens.mdnanco-flutter から CSS Variables を抽出（mockup の drift 防止）verify-flutter-source-fidelity.mdHTML mockup と Flutter Widget tree を子 widget まで再帰照合visual-diff-review-loop.mdmockup と staging SS を Codex / Gemini に diff 出させて loop で潰す。13 iter で staging fidelity 達成の実例付きvisual-diff-real-vs-stories.md実機 SS と stories の差分レビュー（pixel diff の軽量版）
ビジュアル素材 ─ Web 画面
render-marketing-screen.md本命:nanco-marketing-stories（見た目専用 repo）の Storybook story を storycap で撮影。production を取り込まないので mock 不要・build 3 秒・5-10 分／枚で量産可render-web-screen.mdnanco-next（web service）の Storybook story を storycap で直接 PNG 化（production component 取込、mock 多め）extract-chrome-mcp-screenshot.mdChrome MCP のscreenshot save_to_diskが path を返さない問題を、session jsonl から base64 抽出して回避
ビジュアル素材 ─ LP 組み込み ／ アニメーション ／ 背景 ／ アイテム画像
integrate-mockup-into-lp.mdモックアップ component（MockupCard+Mobile{...}Screen+ stable bg）を nanco_hp_2026 の LP セクションに組み込む。app/(dev)/mockup-galleryの 26 パターンを Good 例の元ネタに使う。動かしたい場合はcreate-scripted-ui-demo.mdを呼ぶcreate-scripted-ui-demo.mdLP B1 等の Hero に「触ってる感」を再現する scripted UI demo（既存Mobile{...}Screenを motion.dev で puppeteer する live HTML/CSS/JS）。内部座標オーバーレイ原則 / iOS transition / Material ripple / 業種ローテを統合。Annex に汎用「内部座標オーバーレイ原則」を内包generate-stage-background.mdLP の UI ステージ背景（mint/moss/teal の flat molded panel）を ChatGPT 経由で量産。prompt pack v1（sessions/2026-05-16-.../prompt-packs/nanco-stage-background-v1.json）を SoT に持つgenerate-item-images.mdアイテム名 + 業種から商品写真風画像を Pollinations.ai（Flux）で生成
成果物制作 ─ ライティング
write-help.mdヘルプページ作成write-sns.mdSNS 投稿作成write-release-note.mdリリースノート作成write-press-release.mdプレスリリース作成（節目ニュース該当時のみ。戦略書:strategy/deliverables/press-release-strategy.md）write-appstore.mdApp Store 文章作成create-presentation.mdnanco プレゼン作成（DESIGN.md/PRESENTATION.mdを SoT に）
Foundation 更新パイプライン（insights を育てる）
summarize-meeting.md議事録作成extract-meeting-insights.mdMTG からインサイト抽出extract-faq.mdFAQ 抽出analyze-user-feedback.mdユーザーフィードバック分析review-insights-on-release.mdリリース時の insights 見直しupdate-implementation-map.md実装マップ更新
知識系（戦略立案を補助）
book-to-strategy.md書籍 → nanco 戦略への変換saas-feature-page-strategy.mdBtoB SaaS 機能紹介ページの「メリット先行型」構成理論
内部運用
write-monthly-report.md月次レポート作成linear-sync.mdLinear Marketing team（linear.app/nsketch/team/MARK）との同期。project-manager v0.2 から呼ばれる手の道具
3つの戦略フレームワークを並走
タスクごとに主担当を決めて回します。どれを選ぶかは strategy/strategy-selection-rule.md に従い、迷ったら strategy-router が判定します。
Product-Led Growth
PLG
プロダクト内部での体験設計。サインアップ動線、アクティベーション、TTV 短縮、エンゲージメントで成長を作る。
Traction
Traction
19チャネル探索 + 広告運用。新規流入と CPA・CTR・CVR の改善。3軸テスト（アプリファースト / チーム共有 / バーコード管理）を継続。
Product-Led SEO
PLS
検索意図に直答するページを積み上げ、SEO と AEO（AI 引用獲得）の両方で nanco の世界観を発信する。
判断と学びを蓄積する
重要な判断は decision-log に Compiled Truth + Timeline 形式で残し、Playbook を回した経験は pattern-library に結晶化します。同じ議論を再発させず、次の判断に取り込みます。
decision-log/
判断履歴と経緯
YYYY-MM-DD-{topic}.md 形式。「いま正しい結論（Compiled Truth）」と「そこに至った時系列（Timeline）」の両方を残します。GBrain の哲学から借用しつつ、本体は未導入で運用しています。
pattern-library/
勝ち / 失敗パターンの結晶化
win-patterns.md と anti-patterns.md に蓄積。Playbook 実行のたびに「うまく回ったパターン」「詰まった点」を追記し、次回呼ばれた役者が参照します。
運営の3つの原則
少人数で大量のアウトプットを継続するための設計思想です。
- 情報を集約する場所を1つにする ── 真実の単一ソース（SoT）を原則として置く。迷ったら必ずナレッジベースを先に見てから外に発信する。
- AI に下書きをさせ、人が最終判断をする ── AI は下書き生成と情報集約の担い手。判断と哲学は人が担う。
- 量ではなく流れで勝つ ── 競合と同じ土俵で量で戦わない。1つの行動が複数のトピックに効くよう、情報のフローを設計する。
やる
- 必要な機能を積み上げる（複雑さは増やさない）
- UX を消費者アプリ並みに磨き続ける
- 業務フローごと設計する
- 現場に足を運ぶ
- AI と共進化する（AI が nanco を正しく理解できる状態を作る）
- 全機能を全プランに開放（アイテム数でのみ段階をつける）
やらない
- 営業マンによる高額販売
- 機能制限やユーザー数制限による追加課金
- 複雑さを増やしての差別化
- 規制産業の法定トレーサビリティ要件への完全対応
- 検索順位のためだけの薄い記事
- 自称最上級（「業界No.1」「最も」「最安」「最高の◯◯」）
Claude Code の起動と使い方
ナレッジベース単独でも、複数リポジトリ参照でも起動できます。AI に複雑な依頼をするときは Slash Command か Playbook を経由するのが基本です。
基本起動
cd nanco-knowledge
claude複数リポジトリを参照しながら作業
claude --add-dir ../nanco_hp_2026 --add-dir ../nanco-flutterPR の diff を見ながらヘルプを書く、Web とアプリの整合性を確認する、など。
司令塔として AI を動かすときの実行フロー
- 状況入力を受ける（ユーザーから「X してほしい」）
core/で事実確認insights/で文脈理解strategy/strategy-selection-rule.mdでフレームワーク選定playbooks/{該当}.mdで役者の振付を取得decision-log/で関連する過去判断を確認workflows/{該当}.mdで行動シーケンスを取得.claude/agents/{役者}.mdまたはskills/{各タスク}.mdで個別実行- 「人のチェック必要」タスクは必ずレビューを挟む
- 重要な判断は
decision-log/に記録、学びはpattern-library/に蓄積