Claude Code Harness KPIダッシュボード: 証拠、収益、リスクを1枚で追う

なぜ専用の成果物にするのか

この記事では、Claude Codeで記事公開や運用を始めた開発者とコンテンツ運用者向けにharness KPIダッシュボードを作ります。よくある失敗は単純で、PVは伸びているのに、どの記事がPDF登録、Gumroadクリック、相談ページ訪問、検証証跡につながったのか見えないことです。Claude Codeの作業は「よさそうな回答」で終わらせず、別の人が確認できる成果物を残す必要があります。今回の成果物は記事ごとに証拠、収益アクション、リスクメモを並べる1行のダッシュボードです。

この成果物は、prompt、command line、公開ページの間の契約として扱います。Claude Codeが何を読み、何を変更し、どのコマンドで証明し、読者を次にどの収益導線へ送るのかを見える化します。この考え方はharness engineering、getting started、permissionsとつながります。

運用ループ

運用は5段階で回します。actionを決める、proofを選ぶ、Claude Codeに最小作業をさせる、出力を検証する、次の収益アクションを記録する、という順番です。このテーマで見るべき証拠は「コードが動いた」だけではありません。PDF開始、Gumroadクリック、trainingページ訪問、build証跡、未解決リスクを見ます。項目が見えると、勘で記事を書き直さずに済みます。

1. harness記事の検索流入は多いのにPDF登録が少ないなら、無料チェックリストを最初の実例近くへ移します。

2. 入門記事はPDF登録があるのに有料クリックが弱いなら、Setup Guideが必要になる場面をCTAで説明します。

3. 権限記事から相談ページへ流れているなら、リスクの言葉を記事末尾だけでなく中盤にも残します。

コピペ用スターター

const rows = [
  { slug: "claude-code-harness-engineering", sessions: 1882, pdfStarts: 42, gumroadClicks: 9, consultationVisits: 3, riskFlags: 1 },
  { slug: "claude-code-getting-started-complete", sessions: 760, pdfStarts: 28, gumroadClicks: 6, consultationVisits: 1, riskFlags: 0 },
];

function revenueSignal(row) {
  return row.pdfStarts * 1 + row.gumroadClicks * 4 + row.consultationVisits * 9 - row.riskFlags * 3;
}

for (const row of rows) {
  console.log(row.slug, revenueSignal(row));
}

3つの現場例

例1. harness記事の検索流入は多いのにPDF登録が少ないなら、無料チェックリストを最初の実例近くへ移します。

例2. 入門記事はPDF登録があるのに有料クリックが弱いなら、Setup Guideが必要になる場面をCTAで説明します。

例3. 権限記事から相談ページへ流れているなら、リスクの言葉を記事末尾だけでなく中盤にも残します。

自己レビューチェック

この運用を習慣にする前に、release noteのように記事を見直します。最初に見るのはscopeです。読者がharness KPIダッシュボードを使う場面と、もっと小さなchecklistで足りる場面を区別できる必要があります。次にproofです。提案はcommand、URL、diff、metricのどれかへつながっているべきです。最後にroutingです。無料PDF、Gumroad guide、導入相談は競合させず、違う緊急度に答えさせます。

小さなowner ruleも書きます。成果物のowner、検証のowner、次のCTA実験のownerを分けます。1人運用なら同じ人で構いませんが、note上では役割名を残します。こうするとClaude Codeが公開、計測、販売文改善を1つの曖昧な作業として扱いにくくなります。次回の自動運用も、どこから続けるかを判断しやすくなります。

最後に「明日の朝、このこの記事を検証しやすくするものは何か」と聞きます。答えがscreenshotなら保存します。答えが強いpromptならprompt packへ入れます。答えが境界線ならsetup noteへ入れます。記事ごとに証拠、収益アクション、リスクメモを並べる1行のダッシュボードは、次のsessionでも使えるときだけ価値があります。

実務では、記事を公開した日より翌日の見直しのほうが重要です。公開直後はbuild、deploy、HTTP 200、h1、canonicalを確認します。翌日は、検索流入がどの段落で止まったか、PDF formまで届いたか、Gumroad linkがクリックされたか、導入相談ページへ進んだかを見ます。PDF開始、Gumroadクリック、trainingページ訪問、build証跡、未解決リスクを1行にしておくと、PVだけで成功扱いする癖を避けられます。

Claude Codeに任せる範囲も段階化します。まずread-onlyで分析し、次に1ファイルだけ編集し、最後にbuildと公開URLを確認します。いきなりdeployや商品導線変更まで渡すと、どこで失敗したのか分からなくなります。harness KPIダッシュボードは、作業を止めるための書類ではなく、次に任せてよい範囲を決めるための判断材料です。

収益導線では、強い売り込みよりも適切な分岐が効きます。初心者には無料PDF、繰り返し作業にはGumroad、チーム導入や権限設計には相談を出します。記事本文の実例とCTAが一致しているほど、読者は次の行動を選びやすくなります。

もう1つ大事なのは、失敗を責める材料にしないことです。Claude Codeの出力が外れたら、prompt、権限、検証コマンド、公開確認のどこが弱かったかに分解します。人間の記憶で修正するのではなく、次回の入力に戻せる形で残します。そうすると同じ失敗が、次の記事、次のCTA、次のdeploy checkを強くする材料になります。

最後に、数字を見る時間を決めます。公開当日は技術的な正しさ、翌日は読者行動、1週間後は収益導線を見ます。1つの画面で全部を判断しようとすると、PVだけに引っ張られます。記事ごとに証拠、収益アクション、リスクメモを並べる1行のダッシュボードは、時間軸ごとに見る数字を分けるための道具でもあります。

多言語記事では、機械チェックだけでは不十分です。h1が正しくても本文冒頭が別記事だったり、CTAだけ翻訳されて本文が英語のままだったりします。公開後にスマホ幅で開き、hero画像、本文冒頭、CTA付近、Gumroad link、相談linkをまとめて見ます。読者が見る画面を確認して初めて、記事公開と導線改善が同じ作業になります。

この確認を毎回の終点にすると、Claude Codeは単なる執筆補助ではなく運用担当になります。記事、商品、相談導線を同じ検証単位で扱えるため、次の改善点が自然に見えます。迷ったときは、次の読者がクリックする場所を1つだけ選び、そこを証拠つきで直します。

失敗例

失敗例の1つ目は、PVだけを点数にすることです。2つ目は、proof commandなしで変更を承認することです。3つ目は、無料PDFが合う読者にも相談が合う読者にも同じ有料商品だけを出すことです。CTAを変える前にrouting ruleを書くと、この混線を防げます。

収益導線

読者は詰まり方で分けます。commandに不安があるなら無料PDFまたはfree Gumroad cheatsheetへ送ります。同じ作業を毎週繰り返すなら50 Prompt TemplatesかSetup Guideが合います。rollout、risk、revenue designが問題なら導入相談です。このテーマでは、Prompt Templatesは確認プロンプトの標準化に、Setup Guideはharnessルールの固定に効きます。

検証する数字

公開後はHTTP 200だけで終わりません。h1、canonical、hero image、本文冒頭、CTA link、mobile layout、言語を確認します。そのうえでPDF開始、Gumroadクリック、trainingページ訪問、build証跡、未解決リスクを見ます。数字が動かなければ、記事全体ではなく最初の具体例の近くにあるCTAから直します。