創業者（ファウンダー）主導のケーススタディアーカイブを作る方法

目的と成功指標を定義する

ケーススタディアーカイブは「誰にでも向ける」と中途半端になりがちです。デザインやツールに触れる前に、このライブラリがビジネスのために何をするのか決めてください。その選択がページテンプレート、強調する要素、成功の測り方を決めます。

まずは主要な目標を1つ選ぶ

アーカイブの主な役割を1つ選んでください（他の目的をサポートすることはできますが、明確な#1を決める）：

• 営業支援: 見込み客に成果を示し、リスクを下げ、商談につなげる。\n- 採用: 働き方や価値観、チームが解く問題の種類を示す。\n- 信頼構築: 投資家やパートナー、メディアに具体的な成果で信頼を築く。\n- コミュニティ: 顧客を紹介し、勝利を祝福し、共有したくなる理由を作る。

選んだら、1文の目的ステートメントを書いて（例：「業界とユースケース別の成果を示して、適格な見込み客の自己選別を助ける」）、制作中は常に見える場所に置いてください。

対象読者（とその“状況”）を明確にする

主な読者と彼らが答えを求めていることをリストアップします：

• 見込み客:「自社のような会社で効果がありますか？」
• パートナー:「このチームは信頼でき、仕事がしやすいか？」
• 投資家:「需要は再現性があり、維持率は高いか？」
• メディア／アナリスト:「明確な数字と切り口があるストーリーか？」

もし二つの読者層でニーズが競合するなら、主要目標に紐づく方を優先してください。

「ファウンダー主導」の定義を決める

ファウンダー主導が必ずしも創業者がすべてを書かなければならないという意味ではありません。次のように運用可能な定義に落としてください：

• ボイス: 一人称視点で明確な意見（何をしたか、なぜそれを選んだか、次にどうするか）
• インタビュー: ファウンダーが顧客や社内をインタビューし、ナラティブにサインオフする
• バイライン: 「By {Founder Name}」のような明示的な著者表記で説明責任と信頼性を示す

実際に使う成功指標を設定する

目標に直結する少数の測定可能な成果を選びます：

• リード／デモ: デモ申込、問い合わせ、“book a call”のクリック
• エンゲージメント: ページ滞在時間、スクロール深度、リピート訪問、セッションあたりのケーススタディ閲覧数
• 営業インパクト: ケーススタディページの閲覧がどのパイプライン段階で起きているか、影響した商談、営業担当による共有数

ターゲット値とレビュー頻度（初期は週次、安定後は月次）を定めてください。これによりアーカイブは単なる「コンテンツ」ではなく改善できるシステムになります。

ケーススタディのコンテンツモデルを設計する

すべてのストーリーが同じ「パーツ」から組み立てられているとブラウズが楽になります。それがコンテンツモデルです：収集するフィールド、サポートするフォーマット、繰り返すナラティブ構造。

後でフィルターできるように押さえるコアフィールド

各ケーススタディで必須にする小さなフィールドセットから始めます。これは誰向けか、何が変わったか、どう証明するかを示すものにしてください。

最低限定義する項目：

• 顧客プロファイル： 業界、会社規模（レンジ）、ロケーション（オプション）
• ユースケース： ジョブ・トゥ・ビー・ダン（例：オンボーディング、レポーティング、営業支援）
• 開始時点： 置き換えたツール、制約、タイムライン
• ソリューション要約： 実装内容、誰が実施したか（顧客／自社／パートナー）
• 成果指標： 数値化された結果（収益、時間短縮、コスト削減）＋期間
• 証拠ポイント： 主要引用、測定可能なKPI、短いハイライト文

ファウンダー主導の語りにしたいなら、Founder takeaway、次にやるなら、予想外の気づきなどのフィールドを追加してください。

公開するフォーマットを決める

「ケーススタディ」が長い記事である必要はありません。継続的に作れるフォーマットを選んでください：

• 書き起こし（SEOとスキミング向け、デフォルト）
• 動画（信頼構築に有効だが労力高め）
• ポッドキャスト／音声（ファウンダーインタビューに向く）
• スライド（カンファレンス向け）
• PDF（営業向けだが任意の資産として）

1つのフォーマットを正本にし、他は補助資産として添付することを推奨します。

一貫したストーリーアウトラインを使う

読者がストーリーを比較しやすいようにナラティブを予測可能にします：

Problem → approach → results

その中で「背景」「なぜ我々を選んだか」「導入」「結果」といった標準セクションを定めてください。一貫性が可読性を高め、執筆を早めます。

アセットチェックリスト（と許諾）を計画する

インタビュー前に収集するものを決めます：

• 顧客引用（承認付き）
• ワークフローのスクリーンショットや短いクリップ
• ファウンダー写真と任意の顧客ヘッドショット
• ロゴやブランド名（明示的許諾）
• 関連ページへのリンク（例：/pricing や /product）を文脈的なCTAとして

このコンテンツモデルがテンプレートであり、インタビューガイドであり、後のフィルタ／検索の基盤になります。

情報アーキテクチャとサイトマップを計画する

“自分と似たストーリー”をどれだけ速く見つけられるかがアーカイブの成否を分けます。情報アーキテクチャ（IA）はコンテンツのグループ化、ラベリング、到達方法の設計です—ページを書く前に決めてください。

まずは主要ナビゲーションから

トップナビは短く明快に。シンプルなセットが有効です：

• Archive: メインライブラリビュー
• Topics: キュレーションされた閲覧（例：「Onboarding」「Security」「Pricing」）
• About: これらのストーリーを公開する理由と読者が期待すべきこと
• Submit（任意）: 顧客／パートナーが提案できるフォーム
• Contact: 連絡手段

製品を販売しているなら、/pricing をトップナビに置くかフッターの二次リンクにするかを早めに決めてください。アーカイブが行き止まりに見えないようにします。

アーカイブの表示方法を決める

読者は様々にブラウズするので、いくつかの入り口を用意します：

• グリッドビュー（ロゴ、業界、成果で視覚的にスキャン）
• リストビュー（タイトル、要約、主要指標で高速に読む）
• 注目（Featured） ストーリー（初めての人向け：「ここから始める」）
• コレクション（例：/collections/startups、/collections/enterprise）

サポートページをマッピングする

アーカイブ以外に通常必要なページ：

• /about：アプローチと編集基準の説明
• /contact：パートナー／プレス向けの連絡先
• /submit：ストーリー提案用フォーム
• /privacy：メールやフォーム送信を収集する場合

ビルド前にサイトマップとテンプレートをスケッチする

1ページのサイトマップを書き、必要なテンプレート（Archive、Case Study、Topic、Collection、About）を定義してください。これはCMSの手戻りを防ぎ、URLをきれいに保ちます。例：/case-studies/acme-onboarding、/topics/pricing、/collections/saas。

タクソノミー：カテゴリ、タグ、コレクションを作る

“自分と似たストーリー”が認識しやすいかどうかでアーカイブの価値が決まります。タクソノミーはストーリーを整理するための命名体系です–訪問者が自信をもってブラウズでき、チームが一貫して公開できるようにします。

購買者の疑問に合うフィルタ軸を選ぶ

まずは見込み客が自分を識別する方法や、ファウンダーが物語を語る方法に即したフィルタを選びます。高信号の軸の例：

• 業界（例：Fintech、Healthcare、Ecommerce）
• 役職（例：Founder、RevOps、Product Lead）
• 製品／ユースケース（何を使ったか、なぜ）
• 課題（前の状態の問題）
• 会社ステージ（Seed、Series A、Growth、Enterprise）

各軸は互いに明確に区別できるようにしてください。同義語や重複があるとフィルタを台無しにします。

カテゴリとタグ（少ない方が良い理由）

カテゴリは数個の安定したバケツに使い、長期的に維持するものにします。広く理解されるものを少数に絞ってください。

タグは発見性を高める柔軟な詳細に使います（ツール、戦術、ニッチシナリオ）。タグは増えても構いませんが、同義語や重複のガバナンスが必要です。

実用ルール：カテゴリ5–10個、タグ20–60個、各項目に短い定義を付けることを推奨します。

コレクションでキュレーションされた閲覧を作る

コレクションはカテゴリやタグを横断する手動キュレーションです。ファウンダー主導の語りを表現するのに向いています：

• Featured: トップ6–12の「ここから始める」ストーリー
• Editor’s picks: 回転式の意見を伴う注目（毎月または四半期ごと）
• テーマセット（例：「最初の10顧客」「スプレッドシートからの乗り換え」）

検索なしでもブラウズが明快になるようにする

検索は有用ですが、タイプしなくてもブラウズできるようにします。

Browse allビューに目立つフィルタチップといくつかのキュレーション入口（Featured、Editor’s picks、Newest）を配置してください。訪問者が二クリックで関連リストに辿り着けるのが理想です：Industry → Challenge、または Role → Stage。

ユーザーが使う検索・フィルター・ソートを作る

アーカイブが数十件を超えるとブラウズだけでは不十分です。訪問者は明確な意図（「B2Bのオンボーディング成功事例を見せて」など）を持って来るため、検索とフィルターは明快で寛容である必要があります。

人々の言い方を理解する検索を作る

目立つ検索ボックスを置き、最初の入力から役立つようにします。

タイプアヘッドは実際の検索語と一致すべきです：企業名、業界、役職、よくある成果（「解約減少」「オンボーディング高速化」「パイプライン増加」）。語彙の差で失敗しないよう同義語を設定してください（例：「HR」＝「people ops」、「customer success」＝「CS」、「ecommerce」＝「online store」）。

モバイルで使えるフィルターにする

多くの人がスマホでスキャンします。フィルタはドロワー（またはボトムシート）にしてワンタップで開き、チップで選択できるようにしてください。

含めるべき要素：

• 業界、会社規模、ユースケース等のマルチセレクトチップ
• 目立つ「全てクリア」アクション
• 適用時（または即時）に更新される結果数表示

フィルタ名は内部用語でなく「チーム規模」のような人間に分かる表記にしてください。

意思決定に合うソートを提供する

ソートは見られる内容を変える重要な要素です。小さめの選択肢を用意しましょう：

• Newest（新着）
• Most viewed（よく見られている）
• 成果タイプ別（成長、効率化、定着など）

検索結果は「Most relevant（最も関連性が高い）」をデフォルトにし、メインアーカイブは「Newest」または「Most viewed」にするのがよくあるパターンです。

行き止まりを避ける

フィルタで結果がゼロのときに空ページを見せないでください。近い選択肢を提案し（「'Enterprise'を外してみる」や「'SaaS'のストーリーを表示しています」）、関連ストーリーのリンクを必ず出して次のクリックを用意します。

適切なプラットフォームとCMS設定を選ぶ

プラットフォーム選びの1つの基準は：開発者を毎回呼ばなくても、創業者（と小さなチーム）が一貫したケーススタディを迅速に公開できるかどうかです。

チームに合う構築タイプを選ぶ

月に数件の公開でスピードを重視するならノーコードCMSで十分なことが多いです。数十〜数百件、複数貢献者、将来的な高度なフィルタを想定するならより強力なコンテンツモデルと権限管理が必要です。

実用的な判断基準：

• No-code + CMS：スピードと低メンテを重視する場合
• 従来型CMS（WordPress）：柔軟性や多数のプラグインを使いたい場合（アップデート管理が必要）
• ヘッドレスCMS：サイト＋アプリ＋ニュースレターなど複数にコンテンツを配信する場合や構造化コンテンツ管理が必要な場合

ガイド付きビルドの速さとコード所有を両立したいなら、Koder.aiのようなvibe-codingプラットフォームが中間的選択肢になり得ます：チャットでアーカイブ、テンプレート、フィルタを指定するとReactベースのWebアプリとGo＋PostgreSQLバックエンドを生成し、デプロイ、ホスティング、ソースコードのエクスポートまで提供します。

ケーススタディアーカイブ向けの一般的オプション比較

Webflow + CMS

洗練されたデザインと速いイテレーションに向いています。編集者がレイアウトを触らずに公開できます。ケーススタディページが一貫構造の時に特に有効です。

注意点：複雑なタクソノミーや高度なフィルタは追加作業やサードパーティが必要になる場合があります。

WordPress

馴染みのある編集体験、豊富なSEOツール、柔軟なコンテンツタイプが利点です。

注意点：プラグイン肥大化、セキュリティ更新、テーマ制約が運用負担になることがあります。

ヘッドレスCMS（例：Contentful）

引用、成果、FAQなどのクリーンで再利用可能なコンテンツモデルを求める場合に最適です。チームと権限が増えてもスケールします。

注意点：フロントエンドやセットアップの進化に開発者支援が必要になることが多いです。

権限と役割を計画する（ファウンダー主導を維持するため）

シンプルに、しかし明示的に設計します：

• Founder（著者／承認者）: 下書き、最終承認、発信のボイス
• Editor: 一貫性の確保、主張の検証、構成の polishing
• Contributor: 生のノート、インタビュートランスクリプト、アセット、リンクを追加

権限を管理することで誤ったレイアウト変更を防ぎ、承認フローを予測可能にします。

繰り返し使うセクションは編集しやすく（壊しにくく）する

引用、結果テーブル、主要指標、タイムライン、FAQ、「How we did it」などは再利用可能コンポーネントや構造化フィールドにします。フリーフォーム段落にしないでください。

これにより：

• すべてのストーリーが読みやすくなる
• 一部のコンテンツ（Resultsスニペット等）をリストやプレビューで再利用できる
• フォーマットの修正を1回で済ませられる

不安があるなら、まずは構造化フィールドをサポートする最もシンプルなセットアップから始め、公開での摩擦が見えたらレベルアップしてください。

高いコンバージョンを生むケーススタディページの執筆とデザイン

優れたケーススタディページは2種類の読者に応えます：素早く証拠を見たいスキマーと、決断を正当化するために詳細を求める吟味者。

15秒でスキャンできるようにする

ページ上部近くにサマリーボックスを置き、訪問者がここにいるのが正しいかを素早く確認できるようにします。

含める要素：

• 対象（業界、会社規模）
• 問題を1文で
• 実施したこと（アプローチ）
• 主要成果（数字を先に、文脈を後に）

さらにファウンダーや顧客のプルクオートを1〜2個入れてページを分割し、信頼を強化します。

一貫した見出しを使い（人に寄った表現で）

見出しの一貫性はアーカイブ間の比較を助け、SEOにも貢献します。シンプルで繰り返し使える構成例：

• Challenge
• Context（制約、以前に試したこと）
• Solution（何が変わったか）
• Implementation（手順、タイムライン）
• Results（指標＋ナラティブ）
• Lessons learned / What we’d do differently

見出しは「オンボーディングで何が変わったか」のような平易な表現にしてください（「Operational transformation」のような業界用語は避ける）。

意図に合うCTAを配置する

成果の後に1つのプライマリCTAを置き、サイドバーやフッターにはよりソフトな選択肢を置きます。しつこくしないのがポイント：

• 「新しいケーススタディをメールで受け取る」 → /newsletter
• 「状況を相談する」 → /contact
• 「自社に合うか確認する」 → /demo

軽い信頼要素で裏付ける

小さく見える要素が信頼差を埋めます：

• 著者の略歴（ファウンダー視点）
• 公開日＋「最終レビュー日」
• 明示的な開示（例：「顧客承認済みの引用と指標」）
• 短いレビューノート（「営業＋カスタマーサクセスがレビュー」）

アーカイブのSEOと内部リンク設定

各ストーリーが検索で独立して機能しつつ、読者を次の行動に導けることが理想です。ここでのSEOはテクニックではなく、明快さ、一貫性、クロールとナビゲーションのしやすさにあります。

クリーンで予測可能なURLを使う

長期的に維持するURLパターンを決めてください。シンプルな形式は共有や検索エンジンの理解を助けます。例：

• /case-studies/company-name-use-case

日付やランダムIDは不要なら避けてください。スラッグを変更する場合は301リダイレクトを設定して古いリンクを壊さないようにします。

意図を反映する内部リンクを作る

内部リンクは読者と検索エンジンに何が重要かを教える手段です。

• アーカイブから各ケーススタディへ：カテゴリとタグページが関連ストーリーへリンクしていることを確認
• 各ケーススタディからアーカイブへ：関連タグ／コレクションへのリンク、明確な次のステップへのリンクを追加

実用パターン：

• 関連タグへの「More like this」リンク（例：業界、ユースケース、ステージ）
• CTAで /contact へリンク

メタデータテンプレートを作ってから個別調整する

すべてのページに標準のSEOデフォルトを用意しつつ、編集で調整できるようにテンプレートを作ります。

• Title tag template: {Company} case study: {Outcome} with {Product}
• Meta description template: How {Company} used {Product} to {measurable outcome}. See goals, approach, timeline, and lessons learned.
• Social preview template: 一貫した画像スタイル＋成果に焦点を当てた短い見出し

タイトルや説明で成果を誇張しないよう具体的かつ正直に記載してください。

支持できない主張は避けつつスキーマを追加する

構造化データは検索エンジンの理解を助けます。多くのケースでは Article スキーマが安全なベースです。顧客を明記する場合は Organization（名前、ロゴ、URL）を参照できます。

慎重に扱ってください：成果を保証するようなマークアップは避け、可能であれば測定コンテキスト（期間、基準値）を含めてください。

パフォーマンス、アクセシビリティ、モバイル設計を確保する

人々がスマホで、遅い接続で、支援技術を使って閲覧することを想定してください。速度、アクセシビリティ、モバイルレイアウトは「おまけ」ではなく必須条件です。

速度：送るものを最適化する

大きなメディアが最大のパフォーマンス殺しです。

• 画像最適化：モダンフォーマット（WebP/AVIFが可能なら）、表示幅に合わせたサイズ、折り返し遅延読み込み
• 動画埋め込みに注意：クリックして再生するサムネイルを使い、プレイヤーを対話まで読み込まない。自動再生は避ける
• ページを軽く保つ：ケーススタディページではサードパーティスクリプト（チャットや重い分析バンドル）を最小限に

ドロップオフを防ぐアクセシビリティの基本

アクセシビリティ改善は誰にとっても有益です：より明瞭で読みやすいページになります。

• コントラストとタイポグラフィ：コントラストチェックに合格し、小さすぎるフォントを避ける
• 代替テキスト：意味のある画像に対して有用なaltテキストを書く（装飾的なロゴは空でも可）
• キーボード操作：フィルター、メニュー、Next/Previousがマウスなしで操作できることを確認

ブラウジングに適したモバイルファーストコンポーネント

カード、フィルター、表をレスポンシブに設計してください。表はスタック表示にするか、明確な横スクロールで扱います。タップターゲットは大きく、余白を一貫させて窮屈さを避けます。

一貫性のための簡単なスタイルガイド

タイポグラフィ、スペーシング、ボタン、リンク状態をまとめた1ページのスタイルガイドを作ってください。これが設計負債を減らし、どのケーススタディも迅速に公開できるようにします。

ファウンダー主導の公開ワークフローを作る

公開が習慣になればアーカイブは生き続けます。目標は良いストーリーを迅速に捉え、品質を保ち、リリース直前の驚きを避けることです。

シンプルなストーリー受付フォームから始める

営業、CS、ファウンダーがストーリー候補を提出する窓口を1つ作ります。フォームにすることで情報が散逸するのを防げます。

質問例：顧客の目標、何が変わったか、測定可能な結果（日時入り）、以前に試したこと、使ったプロダクト機能、なぜ我々を選んだか。

必須アセットも列挙します：ロゴ使用許諾、承認済み引用1–2件、ヘッドショット（任意）、スクリーンショット（許可があれば）、補助資料へのリンク。

品質を守る編集チェックリストを使う

デザインや公開前にチェックリストを通してください：

• 数字、タイムライン、顧客名／役職の事実確認
• 主張の裏付け（「大幅に増えた」など曖昧な表現は避ける）
• 成果が明確であること
• 許諾（ロゴ、引用、スクリーンショット）が取れていること
• 最終ページがコンテンツモデルに沿っていること

このチェックリストはバックログに置いておくと抜けを防げます。

レビューステップを定義し、速く回す

実用的なレビューの流れ：

1. ファウンダー確認： ナラティブ、ポジショニング、トーンの確認
2. 顧客承認： 引用、指標、記述方法の確認
3. 法務チェック（必要時）：規制業界やセンシティブな主張、ブランド制約がある場合のみ

各ステップに時間制限（例：48–72時間）を設けて停滞を防いでください。

公開頻度とバックログ管理

持続可能な公開頻度（週次、隔週、月次など）を決め、バックログにステータス（Pitch → Interview scheduled → Draft → In review → Approved → Published）を付けます。次に出すものをまとめた「next up」キューを作ると記憶頼みを減らせます。

内部提出リンク（例：/case-studies/submit）を1つ用意しておくとパイプラインが常に開かれた状態になります。

分析、フィードバック、イテレーションのループを追加する

アーカイブは出して終わりではありません。成功するライブラリは各ページを小さな実験として扱い、何が適切な読者を引き付けるか、何が会話につながるかを学び続けます。

意図を示すアクションを計測する

ページビューだけでなく本当の関心を示すイベントを追跡します。通常重要なのは、訪問者が関連ストーリーを探しているか、次のアクションに近い瞬間です。

追跡イベント例：

• 検索使用（クエリ含む）
• フィルター適用（どのフィルターと値か）
• ソート変更（例：「最新順」→「業界別」）
• CTAクリック（Book a call、Contact sales、Start trial、Subscribe）
• PDFダウンロードや共有クリック（ある場合）

命名規則を統一してレポートが読みやすくなるようにします（例：case_study_filter_applied、case_study_cta_click）。

どのタグやページが実際にコンバージョンに効いているか学ぶ

多くのチームは大きなロゴ＝ベストストーリーと仮定しますが、分析は異なることを示すことがよくあります。

簡単なレポートで次を把握してください：

• どのタグ／カテゴリが最もCTAクリックを生んでいるか
• どのケーススタディページがコンバージョンに最も貢献しているか
• よくあるパス（Homepage → Archive → Case Study → CTA）

これにより投資先が明確になります：人々が本当に探している業界、成果、ユースケースに注力してください。

軽いフィードバックとストーリー候補の収集

各ケーススタディとアーカイブ／検索ページに小さな「これは役に立ちましたか？」プロンプトを置きます。「いいえ」を選んだら任意で「何を探していましたか？」を尋ねると、欠落しているタグや用語の違い、ライブラリのギャップがわかります。

また顧客やパートナーがストーリーを提案できるシンプルなフォームを設置し（「Suggest a case study」）、提出を共有InboxやCRMに流すとファウンダー主導のアウトリーチがしやすくなります。

インサイトをイテレーションに変える頻度を決める

月に1回、検索で良い結果が出なかった上位クエリ、高離脱のケーススタディ、コンバージョン率の高いタグをレビューします。

その結果を元に次に書くべきもの、更新するもの（スクリーンショット、指標、引用）、再編成すべきタグやカテゴリを決めてアーカイブを継続的に改善します。

アーカイブのローンチと維持管理

ローンチは「公開して終わり」ではありません。製品リリースのように扱って、クリーンなv1を出し、意図的にアナウンスし、正確さを保ちながら成長させてください。

プレローンチチェックリスト（QAは省略しない）

発表前に以下を確認します：

• リダイレクト: 旧URLから新URLへのマッピング（PDF、Notion、ブログカテゴリから移行する場合）
• Sitemap + robots.txt: XMLサイトマップが公開され、robotsルールがアーカイブをブロックしていないこと
• 404ページ: /case-studies（またはアーカイブインデックス）への案内と検索を含む親切な404
• ページQA: 名前、ロゴ、指標、引用の校正、CTAsの確認、モバイルでのフィルタ検証、フォームとメールキャプチャのテスト
• トラッキングのスモークテスト: ページビュー、CTAクリック、ダウンロードでイベントが発火するか確認

素早く構築・イテレーションする場合、スナップショットやロールバック（Koder.aiのようなプラットフォームが提供）を利用するとリリースリスクを下げられます。

発表計画（共有しやすく）

アーカイブは分配資産です。発表は次のように行うと良いです：

• メール: 「新しい顧客事例ライブラリ」の短い案内と3つの注目ケーススタディへのリンク
• ソーシャル: 各注目ストーリーから1–2の学びを引いたスレッドとコレクションへのリンク
• パートナー＋コミュニティ: パートナー向けに事前用の文面とUTM付きリンクを用意し、対象のファウンダー／オペレーターグループで共有

アーカイブに「どう作ったか」的な裏話を入れると配信コンテンツにもなります。例えばKoder.aiはコンテンツ作成のクレジット付与や紹介プログラムを持っており、公開と共有を促す運用に役立ちます。

維持の頻度で信頼性を保つ

四半期ごとのルーチンを設定してください：

• 古い指標を更新（例：「as of Q3」）し、顧客拡張時は追記
• 断リンクチェック（内部・外部）と欠落アセットの修正
• 上位検索クエリとフィルタ使用の見直し；人が見つけられないならタグ／カテゴリを調整

「30分以内で新しいケーススタディを追加する」手順を文書化する

1ページのSOPをチームスペースに置き、CMSから参照できるようにします：

1. ケーススタディテンプレートを複製 2) 必須フィールドを埋める（業界、ユースケース、指標、引用） 3) タグを付ける 4) 公開 5) 1–2件の関連ストーリーへ内部リンクを追加 6) 新URLを営業／サポートと共有

この一枚が忙しい時期でもファウンダー主導のアーカイブを生かしておく鍵です。