data-storytelling

data-storytelling スキルの概要

data-storytelling スキルでできること

data-storytelling スキルは、生の分析結果を「意思決定に使える伝え方」へ変換するのに役立ちます。単にグラフを並べて終わるのではなく、文脈、緊張感、洞察、アクションまで含めたストーリーとして整理するよう促してくれるのが特徴です。特に、実務上のゴールが「データを分析すること」ではなく、「何が重要で、次に何をすべきかを説明すること」にある場合に力を発揮します。

レポート作成とステークホルダー向け説明に最適

この data-storytelling スキルは、経営層や非技術系の読者に指標を説明する必要があるアナリスト、オペレーション担当、コンサルタント、創業者、レポート作成者に向いています。特に data-storytelling for Report Writing、四半期レビュー、取締役会向けアップデート、投資家向けデッキ、提案メモのような用途と相性が良いです。

汎用プロンプトとの違い

通常のプロンプトでも数値の要約はできます。ただ、data-storytelling スキルは、使い回しやすい伝達フレームを与えてくれます。たとえば setup・conflict・resolution、hook・context・rising action・climax・resolution・call to action、さらにデータ・物語・ビジュアルのバランスといった考え方です。この構造があることで、「分析は正しいのに印象に残らない」というよくある失敗を減らせます。

インストール前に確認したいポイント

導入判断で見るべき点はシンプルです。必要なのが「説得力のある説明」なのか、それとも単なる「分析結果の出力」なのか、ということです。読み手に重要性、トレードオフ、次の一手まで理解してもらう必要があるなら、このスキルには十分な価値があります。逆に、SQL の補助、グラフ生成、生の指標要約だけが目的なら、単体ではやや抽象度が高すぎる可能性があります。

リポジトリに含まれているもの

このスキルは軽量です。リポジトリ上で確認できるのは、主なガイダンスをまとめた単一の SKILL.md で、追加のスクリプト、ルール、参考資料は見当たりません。つまりセットアップは簡単ですが、出力の質はプロンプトの質と、こちらが渡すデータ文脈に大きく左右されます。

data-storytelling スキルの使い方

data-storytelling のインストール前提

まず親リポジトリからスキルをインストールし、その後 AI ワークフロー内で呼び出します。

npx skills add https://github.com/wshobson/agents --skill data-storytelling

このスキルは plugins/business-analytics/skills/data-storytelling に配置されているため、導入しているのは実行可能な分析ツールチェーンではなく、分析結果を伝えるためのナラティブ設計フレームワークです。

最初に読むべきファイル

まず確認するのは次のファイルです。

• SKILL.md

このスキルには README.md、rules/、resources/、補助スクリプトといった支援ファイルが見当たらないため、実務上の価値のほぼすべては SKILL.md 内のフレームワークを理解し、どう適用するかにあります。

うまく機能させるために必要な入力

data-storytelling スキルは、データセットを丸ごと投げるよりも、もう一段具体的な情報を与えたときに真価を発揮します。少なくとも次を渡すと効果的です。

• 読み手: executive、client、manager、board、investor、customer
• 形式: report、memo、slide outline、brief、spoken update
• 支援したい意思決定: invest、cut、prioritize、diagnose、explain
• 中核となる指標と対象期間
• ベースラインまたは比較対象
• 最も重要な発見
• 既知の制約や不確実性
• 望ましいアクション

こうした入力がなくてもストーリー自体は生成できますが、見た目だけ整っていて、ビジネス上の意味を外した内容になりがちです。

曖昧な目的を強いプロンプトに変える

弱いゴール:

• “Write a data story about churn.”

より強い data-storytelling usage プロンプト:

• “Use the data-storytelling skill to turn this churn analysis into a report section for a VP of Customer Success. Audience is non-technical. Goal is to justify retention investment for Q3 planning. Use setup-conflict-resolution. Start with a strong hook, explain the baseline, identify the most important driver, quantify business impact, note confidence limits, and end with 3 recommended actions.”

この形にすると、読み手、意思決定、構成、着地点が明確になるため、出力の精度が大きく上がります。

推奨プロンプトテンプレート

安定した結果を得たいなら、次のようなテンプレートが使えます。

• Objective: このレポートで達成したいこと
• Audience: 誰が読むのか
• Data: 主要な数値、トレンド、比較
• Context: 何が変わり、なぜ重要なのか
• Constraints: トーン、長さ、形式、確実性の扱い
• Output request: 求める物語構造、提案してほしいビジュアル、推奨アクション

例:

• “Apply the data-storytelling skill. Write a 500-word executive summary for a quarterly business review. Data: revenue +8% QoQ, gross margin -3 pts, churn concentrated in SMB accounts, CAC rising 12%. Context: leadership deciding whether to shift budget from acquisition to retention. Include hook, context, rising action, key insight, recommendation, and next steps.”

レポート作成向けの推奨ワークフロー

data-storytelling for Report Writing を実務で使うなら、次の流れが現実的です。

1. まず本当に重要な指標を数個に絞る。
2. 緊張感の源を特定する。例: decline、gap、risk、opportunity、surprise。
3. 意思決定者となる読者を決める。
4. モデルにナラティブの骨子を書かせる。
5. “climax” が本当に意思決定に最も関係する洞察になっているか見直す。
6. ストーリーラインが固まってから、必要なビジュアル提案を加える。
7. 主要な意思決定を支えない要素は削る。

この順番には意味があります。弱いレポートの多くは、最初にグラフを増やしすぎて、あとから「結局何を伝えたいのか」が定まっていないことに気づきます。

適切なフレームワークの選び方

元のスキルでは、長く使える基本構造がいくつか強調されています。実務では次のように使い分けるとよいです。

• 簡潔なメモやレポート節なら Setup → Conflict → Resolution
• プレゼンや経営層向けの説明なら、より長い narrative arc
• 下書きが偏って見えるなら、data・narrative・visuals の 3 本柱

導入判断の目安としては、チーム内で「分析としては面白いが、次の行動につながらない」と言われがちなら、このスキルは採用する価値があります。

良い入力の具体例

良い入力は、比較があり、意思決定と結びついています。たとえば次のようなものです。

• “Conversion dropped from 4.2% to 3.1% after pricing changes”
• “Enterprise renewals offset SMB churn, masking segment risk”
• “Support backlog rose 28% while NPS fell 6 points”
• “The business choice is whether to hire support staff or reduce onboarding friction”

こうした入力は、単独の数値より強力です。なぜなら、緊張感を生み、「なぜ気にすべきか」を自然に説明できるからです。

よくある使い方のミス

弱い data-storytelling usage は、たいてい次のいずれかが原因です。

• 読み手を指定せずに “a compelling story” を求める
• ベースラインなしで指標だけを渡す
• 推奨アクションを省く
• 観測したパターンをすべて物語に詰め込む
• 記述的データから無理に因果関係を断定する
• ビジュアルを根拠補強ではなく装飾として扱う

このスキルは、メッセージを「ひとつの中核洞察」と「ひとつの明確な行動方針」に絞ったときに最も機能します。

通常の分析作業との役割分担

data-storytelling スキルは、分析そのもの、データクレンジング、グラフ作成を置き換えるものではありません。位置づけとしてはそれらの後段です。強い運用フローは、先に分析を済ませ、その後でこのスキルを使って、経営層が流し読みしても要点が残るナラティブに仕立てる形です。

どんな出力を依頼するとよいか

依頼先として有効なのは、たとえば次のような成果物です。

• executive summary
• board-ready memo
• quarterly review narrative
• investor update section
• slide-by-slide outline
• insight-to-action brief
• annotated chart captions

単に “a story” と頼むと、雰囲気はあるが意思決定には使いにくい文章になりがちです。スタイルではなく、ビジネス文書の種類を明示して依頼するのがポイントです。

data-storytelling スキル FAQ

data-storytelling スキルは初心者にも向いている？

はい。すでにデータや発見事項があるなら、初心者でも使いやすい部類です。フレームワーク自体はシンプルで取っつきやすいです。ただし、初心者は「最も重要な洞察をひとつ選ぶ」部分でつまずきやすいため、下書きの前に、発見事項をビジネスインパクト順に順位付けするようモデルに明示的に頼むと進めやすくなります。

普通の要約プロンプトではなく、いつこれを使うべき？

読み手に対して説得、文脈付け、推奨アクションまで必要なときは data-storytelling skill を使うべきです。結果を事実ベースで簡潔に振り返れれば十分なら、通常の要約プロンプトで足ります。

このスキルはプレゼン専用？

いいえ。プレゼンだけでなく、レポート、メモ、経営層向けメール、四半期レビュー、投資家向け文章にも有効です。価値の中心はスライドではなく、ナラティブの構造化にあります。

data-storytelling install にグラフや自動化は含まれる？

いいえ。このスキルにビルトインのスクリプト、グラフ作成ツール、自動化機能がある証拠はありません。data-storytelling install で得られるのはコミュニケーションのフレームワークであって、可視化エンジンやレポーティングパイプラインではありません。

技術者向けの読者にも使える？

はい。ただし、真価を発揮しやすいのは、技術・非技術が混在する読者や非技術系の読者です。かなり技術的な相手であれば、ナラティブの演出を弱め、方法論の詳細を増やした、より直接的な構成のほうが適する場合があります。

向いていないケースは？

次のような場合は、このスキルは見送ったほうがよいです。

• まだ分析の妥当性検証が終わっていない
• 読み手が生テーブルや技術付録だけを求めている
• 意思決定が単純で、説得の工程が不要
• 伝え方の構造より、領域特化の統計的厳密さが優先

スライド作成スキルとは何が違う？

スライド作成スキルは、形式やプレゼンの流れに重点があります。一方、この data-storytelling guide は、まず証拠を意味のあるメッセージへ変えることに重心があります。スライドを書く前にも、レポートを書く前にも、口頭説明を組み立てる前にも使えます。

data-storytelling スキルを改善する方法

データセットではなく意思決定から始める

data-storytelling の出力を最も手早く改善する方法は、そのストーリーが支えるべき意思決定を定義することです。“Summarize this dashboard” では弱すぎます。“Help leadership decide whether churn warrants retention investment” のようにすると、格段に強くなります。

緊張感を明示する

ストーリーには conflict が必要です。プロンプト内にそれがなければ、モデルが不自然にドラマを作るか、無難で平板な文章を返す可能性があります。次のように緊張感を直接書いてください。

• growth with declining margin
• higher revenue with worsening retention
• segment gains hiding segment losses
• improving top-line metrics with rising operational risk

ストーリーを書く前に洞察を順位付けする

最終的なナラティブを依頼する前に、まず次をやらせるのが有効です。

• 上位 3 つの発見を抽出する
• ビジネス上の重要度で順位付けする
• そのうち 1 つを中心メッセージとして選ぶ
• どの意思決定に影響すべきか説明させる

こうすることで、初稿が 5 つの話を同時に語ろうとして散漫になる、という典型的な問題を防げます。

ベースラインと比較を加える

比較があると、ナラティブの説得力は上がります。data-storytelling guide への入力には、次のような比較軸を足すと効果的です。

• previous period vs current period
• target vs actual
• segment vs segment
• before vs after intervention
• internal trend vs market benchmark

比較のないストーリーは、洞察というより説明文に見えがちです。

確実性のレベルをコントロールする

大きな失敗パターンのひとつが、データから言える以上のことを断定してしまうことです。発見が descriptive なのか、directional なのか、causal なのかをモデルに伝えてください。さらに、次を分けて書かせると有効です。

• データが示していること
• その背景要因として有力なもの
• 追加検証が必要なこと

これは特に、経営層向けや投資家向けの文脈で信頼性を高めます。

ビジュアルはナラティブが固まってから依頼する

元のスキルでも visuals は重視されていますが、グラフは物語を主導するものではなく、支えるものとして使うべきです。実用的な反復順序は次のとおりです。

1. まず hook と key message を固める
2. conflict と evidence を検証する
3. recommendations を絞り込む
4. その後で、各ポイントを最も明確にする chart を聞く

セクション制約を入れてレポート品質を上げる

data-storytelling for Report Writing では、各セクションの振る舞いを指定すると実用性が大きく上がります。

• opening sentence must state the business stakes
• context paragraph must define the baseline
• evidence section must use only 3 supporting points
• recommendation section must include owner, timing, and expected impact

こうした制約は、実際に使える文書にするうえで効果的です。アクション可能性を強制できるからです。

きれいだが中身の薄い出力を直す

初稿が無難で空疎に感じるなら、次の指示を追加して修正します。

• “Use the exact numbers provided.”
• “Name the affected segment explicitly.”
• “State the tradeoff behind the recommendation.”
• “Cut any claim not supported by the data.”
• “Replace abstract language with operational implications.”
• “End with a concrete next step.”

文言ではなくナラティブの質で改善する

トーンだけを直して終わりにしないでください。下書きに次があるかを確認します。

• 明確な hook
• 読み手に十分な context
• 記憶に残る 1 つの key insight
• 納得できる recommendation
• 実行に移せる next step

このどれかが欠けているなら、問題は言い回しではなく構造です。

data-storytelling を軸に再利用可能な社内スタイルを作る

チームで定期レポートを書くなら、data-storytelling skill の前段に共通プロンプトを用意し、audience、decision、metrics、baseline、risk、confidence、recommendation の固定項目を持たせるのがおすすめです。これにより出力のばらつきが減り、定常的なビジネスレビューでもスキルを安定して使いやすくなります。