help.nanco.io の機能ヘルプを
「全部書く」ではなく「効く順に」整備する

このロードマップを 4 つの数字で言うと

「全 24 機能のうち、 上位 10 だけを 5 ヶ月かけて、 姉崎の月次負担 2h で書く」 が要点。

なぜ「全部書く」をやらないのか

運営制約から逆算して、 ROI が落ちる前にやめる。

core/product.md に挙がる実装済み機能は 約 35 個。 1 ページ 2-3 時間 × 35 = 70-100 時間。 これを全部書ききっても、 AEO 引用率や SEO 流入に効くページは限られる（パレートの法則）。

本書では:

• 「機能の使用頻度」と「外部からの検索 / 引用流入の可能性」を 2 軸の主軸に置く
• 1 ページ作成 = 2-3 時間という前提で、 上位 10 = 20-30 時間の投資で AEO / SEO リターンの 80% を取りに行く
• 業種別ユースケースガイドは、 機能ヘルプの横断引用 hub として後発で構築する

insights/08-how-we-operate.md の「マーケに割ける時間 = 1 人あたり週数時間」制約と整合する。

5 軸でスコアリング（各 1-5 点、 合計 5-25 点）

単一軸では取りこぼすので、 検索 / AI 引用 / 顧客語彙 / オンボ / 業種横断 の 5 つを総合する。

機能カバレッジマトリクス（実装済み 24 機能）

スコア順に並び替え。 ✅ = 上位 10 入り、 ⬛ = 補欠 / Phase 2 候補。

β版・将来機能: 入出荷リスト / 納品書 / 取引先管理（β）は **上位 10 の 6 位に統合済**。 API 公開（年内）/ AI 在庫最適化（探索中）は本マトリクス対象外。

上位 10 機能の優先順位

スコア + 戦略的依存（FAQ や機能 LP との連動）を加味した着手順。

cannibalize 回避ルール: ヘルプページ冒頭に「この機能の概要・導入検討は /{LP-slug} LP を参照」と明示。 ヘルプ側は「使い方手順 + 業種別 Tips + トラブル対応」に絞り、 「料金」「他社比較」「USP 訴求」は LP に集約。 流入見込みは LP の 30-50% を想定。

月別の着手スケジュール（月 3 本、 3 ヶ月強で完走）

姉崎判断で v0.2 の月 2 本 → v0.3 で**月 3 本**に加速。 2026-08 末で上位 10 完走。

累計: 3 ヶ月強 / 工数 20-30h / 姉崎 7-10h。 業種別ガイドは機能ヘルプ完走後の Phase 2（2026-09+）。

ヘルプページ作成テンプレート

1 ページ 2-3 時間で書く、 schema 対応、 双方向リンク必須。

本テンプレートは skills/write-help.md の構造を本書のロードマップ用に圧縮したもの。 実際のドラフト生成は skills/write-help.md を直接呼ぶ前提で、 本書には差分（順序・schema・cross-link 設計）のみを記載する。

# {機能名}（タイトル H1）

## この機能でできること（要点 60-120 字）
{nanco の {機能名} を使うと、〜できます。}

## 使い方（HowTo schema 対応、 3-5 step）
1. {手順 1}（スクショ 1）
2. {手順 2}（スクショ 2）
3. {手順 3}（スクショ 3）

## よくある質問（FAQPage schema 対応、 3-5 件）
- Q. {質問 1}? → A. {回答 1（60-120 字）}
- Q. {質問 2}? → A. {回答 2}

## 業種別の使い方ヒント
- 製造業: → /case/metalwork/{anchor}
- EC / ネットショップ: → /case/ec/{anchor}
- アパレル: → /case/apparel/{anchor}

## 詳しく試したい（機能 LP への逆方向導線、 必須）
- → /{LP-slug} で {機能 LP のタイトル} を見る
  ※ 主責任 LP がある機能（#2 #3 #10 等）のみ。 LP がない機能はこの節を省略

## 関連機能
- {内部リンク 3-5 本}

文字数目安: 800-1,500 字 / ページ。 過剰に長くしない（薄い記事禁止、 faq-content-plan F-1「やらないこと」整合）。

双方向リンク設計:

• 機能 LP → ヘルプ: 各機能 LP の Section 5「副 CTA」に「ヘルプを見る」リンクを設置（PLS Part 2 の 2-4-2 節 規定）
• ヘルプ → 機能 LP: 上記テンプレ「## 詳しく試したい」節（必須）

スクリーンショット撮影ガイド 🚧 別途議論で見直し

v0.3 では下記方針を**たたき台として保留**扱い。 各ヘルプ着手時に撮影ポリシーを別 task で確定する。

撮影体制

• 一次生成（推奨）: skills/render-marketing-screen.md の Flutter Widgetbook + widgetbook_mcp_server 経由で PNG / GIF を生成。 デモデータは demo-data-curator agent が整合性チェックする nanco-flutter の seed
• 実機撮影（限定）: 「実機の物理感」が必要な機能のみ（バーコードスキャン中の手元 / 棚卸し時のスマホ操作 等）。 姉崎の判断で月 0-1 件
• 保存先: nanco_hp_2026/public/help-screenshots/{機能 slug}/{step-N}.png（別 repo 配下、 月 1 回バッチで PR）
• 命名規則: {機能 slug}-step-{N}-{state}.png（例: barcode-scan-step-1-empty.png）

撮影セット（1 業種先行 + 段階追加）

業種別ユースケースガイドの構造（Phase 2）

機能ヘルプの cross-link hub。 SEO（業種 + 在庫管理 KW）と AEO（業種特化質問）の両取り。

業種別ガイド 1 ページの構造

# {業種} の在庫管理を nanco でやる方法

## この業種の {2-3} つの悩み（顧客語彙の引用、 60-120 字 × 3）
{insights/04-customer-worlds.md から引用}

## nanco の使い方ステップ（業種ストーリー仕立て、 600-1,000 字）
1. 朝の準備（フォルダ整理 → アイテム登録 → スキャン）
2. 日中の運用（入出庫記録、 数量更新）
3. 週次の振り返り（在庫アラート、 レポート）

各ステップから上位 10 機能ヘルプへ内部リンク。

## 業種ならではの設定例
- 属性カスタマイズ（材質 / ロット番号 / 賞味期限 等）→ {属性カスタマイズ ヘルプへ}
- フォルダ階層（拠点 / カテゴリ）→ {フォルダ ヘルプへ}

## よくある質問（FAQPage schema）
- Q. {業種特化の質問} × 3-5

## 関連事例（既存導入事例があれば）
- {ケーススタディ or 実名顧客の声}

着手業種の優先順位（2026-11 以降）

業種ガイドの実装親 task は MARK-26 の後続として MARK-? を起票する（v1.0 化時に確定）。 機能ヘルプ上位 10 完走（2026-10）後に着手判断。

多層レビュー結果（3 件並列）

v0.1 ドラフト → 3 reviewer 並列 → 10 件指摘反映 → v0.2 化。

姉崎レビュー対応 ／ v1.0 確定（全 6 件反映済）

残課題なし。 MARK-26 を Done 化。

• (1) 上位 10 リストの妥当性: OK で v1.0 化済。 以降の議論で再構成 (3') を実施
• (2) 現状 H 列の実態化: Claude が WebFetch で help.nanco.io を実調査し、 セクション 03 マトリクスの「現状」列を実態値で更新（2026-05-19 完了）
• (3) β版機能の扱い: 入出荷リスト / 納品書 / 取引先管理 を 1 ヘルプに統合して上位 10 の 6 位に先回りで組み込み
• (3') 具体的な入れ方: ラベル印刷を 10 → 5 位に昇格、 入出荷を 6 位に新規追加、 フォルダ管理を 7 → 11 位に降格（Phase 2 候補）
• (4) 撮影体制: 別 task MARK-73 として起票完了。 6 月 #1 アイテム登録着手前に「実例 1-2 本書いてから自動生成 vs 実機撮影の比率を決める」 運用判断
• (5) 着手スケジュール: 月 2 → 月 3 本ペースに加速。 3 ヶ月強で完走（2026-06 〜 2026-08）、 姉崎月次工数 ≤ 3h
• (6) schema 責任所在: MARK-11 が仕様 SoT、 MARK-26 はマークアップのみ責任で OK

関連 SoT

本ドキュメントが参照 / 連動する単一ソース。

上位（思想 / 戦略）

並列（事実 / 連動）

下位（実装 / 関連 Task）