Claude Code Harness Lite: 初心者が安全に変更するための小さな足場

Claude Code を初めて本番に近いリポジトリで使うと、最初の失敗はたいてい「便利だから全部任せる」です。Harness は難しい仕組みではありません。ここでは「読む」「変える」「証拠を残す」「公開URLを見る」「収益CTAを壊していないか確認する」を分ける小さな足場として扱います。

この考え方は、より大きい Claude Code harness engineering の手前に置く入門版です。既存コードの読み方は repo map first pass、権限の記録は permission receipt pattern と合わせると、初心者でも変更範囲を制御しやすくなります。

まず「作業を始める前の禁止事項」を書く

初心者向け Harness Lite の役割は、Claude Code の能力を制限することではありません。最初に安全な境界を言語化し、失敗しても戻れる小さな変更だけに集中させることです。とくにコンテンツサイトや小さなWebアプリでは、記事、CTA、商品リンク、問い合わせフォームが同じ画面に並ぶため、1つの文言変更が収益導線まで崩すことがあります。

最初のプロンプトでは、まだ実装を頼みません。Claude Code にリポジトリの入口、触ってよいファイル、触らないファイル、検証コマンド、公開後に見るURLを返してもらいます。ここで曖昧なまま進むと、あとから「なぜそのファイルを変えたのか」を人間が説明できません。

harness_lite:
  owner: "Masa"
  scope:
    allowed:
      - "read repository"
      - "edit selected files"
      - "run build or test"
    blocked:
      - "delete unrelated files"
      - "touch secrets"
      - "hide failed verification"
  proof:
    - "git diff reviewed"
    - "build command recorded"
    - "public URL opened"
    - "CTA path checked"

コピーして使える開始プロンプト

このリポジトリで小さな変更を1つだけ安全に行いたいです。
まだ編集しないでください。
返してほしい内容:
1. 読むべきファイル
2. 変更してよいファイル
3. 変更してはいけない領域
4. 最小の検証コマンド
5. 公開URLで確認すべき h1 / canonical / CTA
6. 無料PDF、Gumroad、導入相談リンクを壊さないための注意点

このプロンプトの狙いは、Claude Code の出力を「作業計画」ではなく「作業の境界」にすることです。境界が見えたら、次のメッセージで初めて1つの変更を頼みます。

変更後の証拠を小さなオブジェクトにする

変更が終わったら、証拠を文章だけでなく、確認項目として残します。次の小さな JavaScript は本番で使うツールではなく、完了条件を頭の中から外へ出すための型です。

const proof = {
  goal: "change one small thing",
  filesChanged: 2,
  commands: ["npm run build"],
  publicUrlChecked: true,
  ctaChecked: true,
};

export function isReadyToCommit(receipt) {
  return receipt.filesChanged <= 3 &&
    receipt.commands.length > 0 &&
    receipt.publicUrlChecked &&
    receipt.ctaChecked;
}

console.log(isReadyToCommit(proof)); // true なら commit 前の最低条件を満たします

この型を使うと、「build は通ったが公開URLを見ていない」「CTAは見たが Gumroad リンク先が違う」といった見落としを分離できます。Claude Code には、実装のあとにこの receipt を埋めるよう頼むと効果的です。

初心者が手元で試すなら、最初の1回は記事本文の1段落だけを対象にします。たとえば「導入文を3行だけ読みやすくする」「無料PDFへの案内を1文だけ足す」「古い内部リンクを1つ直す」のように、作業を小さく切ります。そのうえで、変更前に git diff --stat で差分の大きさを見て、変更後に npm run build と公開URL確認を行います。ここで大事なのは、Claude Code に「良い感じにして」と渡さないことです。良い感じは人によって違うので、読者が次に押すボタン、壊してはいけないリンク、確認するURLを先に言葉にします。

私の手元では、この型を記事更新に使うと、差分確認の会話が短くなりました。以前は「なぜProductsページまで変わったのか」「なぜCTAが別商品になったのか」を後から追うことがありましたが、Harness Lite を先に置くと、Claude Code が自分から範囲外の変更を避けやすくなります。特に収益記事では、本文の正しさだけでなく、無料PDF、Gumroad、導入相談のどこへ読者を送るかが成果に直結します。PVを増やす記事と、売上へ進ませる記事は役割が違うので、開始前に「この記事の第一CTAは何か」を書いておくと判断がぶれません。

3つの実例

• Astro の記事修正では、MDX 1本、関連する画像、Products ページだけを範囲にします。公開後は記事の h1、本文冒頭、無料PDFフォーム、Gumroad ボタンを見ます。
• 小さな React 修正では、対象コンポーネント、既存テスト、Storybook またはスクリーンショットだけを範囲にします。認証、課金、環境変数は最初の変更から外します。
• チーム導入では、CLAUDE.md に「読んでよい場所」「危険なコマンド」「証拠の出し方」を書きます。これにより、次の人が同じ説明をやり直さなくて済みます。

失敗例

よくある失敗は、Harness を作る前に「全部調べて直して」と頼むことです。これだと、Claude Code は親切に広く動き、差分が大きくなり、検証も曖昧になります。もう1つの失敗は、ローカル build だけで終えることです。公開URLがトップページの fallback になっていれば、200 OK でも記事は公開されていません。

収益導線でも失敗があります。記事本文では無料PDFをすすめているのに、記事下CTAが別商品へ飛ぶ。Gumroad商品は英語版が主軸なのに、多言語記事でリンク説明が曖昧になる。問い合わせ導線を置いたが、相談対象が「初心者」「チーム」「運用者」のどれなのか伝わらない。この3つはPVを売上に変える前で止めてしまいます。

無料PDF、Gumroad、相談への分岐

最初の Harness Lite は無料PDFで十分です。毎回同じ review や debugging の依頼文を作っているなら 50 Prompt Templates が合います。権限、CLAUDE.md、hooks、MCP、CI/CD まで整理したいなら Setup Guide が近道です。複数人での導入や、記事から商品、相談までの収益導線を設計するなら 導入相談 に進みます。

この記事で確認したこと

この記事では、軽量ハーネス、開始プロンプト、検証receipt、3つの実例、失敗例、無料PDFとGumroadと相談への分岐を同じ本文内に置きました。次に見る数字は、この記事から無料PDF登録、Prompt Templates、Setup Guide、導入相談へ進むクリック率です。

公開後の運用メモ

この記事の型を実際に使うときは、作業完了を「ファイルができた」ではなく「公開URLで読者が次の行動を選べる」まで広げます。具体的には、スマホ幅で h1、本文冒頭、hero image、無料PDFフォーム、Gumroadリンク、導入相談リンクを確認します。本文が正しくても、記事下CTAが別商品へ飛んでいれば収益導線としては未完成です。

多言語記事では、slug が同じでも安心できません。日本語、英語、中国語、韓国語、スペイン語、フランス語、ドイツ語、ポルトガル語、ヒンディー語、インドネシア語それぞれで、本文冒頭とCTA文言が対象言語になっているか見ます。見出しだけ翻訳され、本文やCTAが英語のままなら、読者は次の行動を選びにくくなります。

次回の改善判断では、PVだけを見ません。PDF登録開始、Gumroadクリック、Productsページ到達、Trainingページ到達、国別の流入、検索エンジン別の流入を並べます。Claude Codeに渡す時点でこの数字を1つのbriefにすると、単なる記事追加ではなく、既存の無料PDF、Prompt Templates、Setup Guide、導入相談のどれを強めるべきか判断しやすくなります。

また、記事を公開するたびに「この記事の読者が今日すぐできる行動」を1つに絞ります。初心者には無料PDF、作業を繰り返す読者にはPrompt Templates、設定や権限で詰まる読者にはSetup Guide、組織や収益導線の判断が必要な読者には導入相談です。本文の途中、記事下CTA、Productsページのカードが同じ判断を向いていれば、読者は迷いません。逆に、本文は無料PDFをすすめ、カードは別商品をすすめ、相談フォームは見つかりにくい、という状態なら、PVが伸びても登録や購入にはつながりません。

最後に、検証ログを残します。確認した公開URL、スクリーンショットの対象、CTAのリンク先、修正したファイル、残るリスクを短く書いておくと、翌日の運用で同じ確認をやり直さずに済みます。Claude Codeに次の改善を頼むときも、前日のログがあると「新しく記事を増やすべきか」「既存人気記事を直すべきか」「Productsページの説明を変えるべきか」を判断しやすくなります。収益導線の改善は一度の大きな改修ではなく、公開、確認、数字、修正を繰り返す運用です。

もし数字が弱い場合は、記事本文だけを責めません。検索意図とCTAが合っているか、heroImageが読み込みで崩れていないか、スマホでボタンが押しやすいか、内部リンクが読者の段階に合っているかを順に見ます。Claude Codeには「売上を増やして」と頼むより、「このslugでPDF登録が弱い。本文中CTA、記事下CTA、Productsカードのうちどこを直すべきか」と渡す方が、具体的な改善になります。

この運用では、記事作成、導線改善、公開確認、スクリーンショット、commitを別々の作業として扱いません。1本の記事が読まれ、無料PDFに進み、必要ならGumroad教材や導入相談へ進むところまでを1つの体験として見ます。Claude Codeに任せる範囲も同じです。本文を直すだけではなく、読者が次に押すボタン、公開後に見る数字、翌日の改善判断までつなげることで、記事は単なる更新ではなく収益導線の部品になります。

小さな改善でも、毎回同じ確認表を使えば蓄積できます。本文の目的、読者の段階、最初のCTA、最後のCTA、公開URL、スクリーンショット、次に見る数字を残しておくと、翌日の判断が速くなります。確認表があると、記事を増やす作業と導線を直す作業を同じ品質で続けられます。数字を見て戻る場所まで決めるのが運用です。特に日本語記事では、読者が最初に何を試すか、失敗したらどこへ戻るか、購入や相談へ進む条件は何かを文章で明示します。