午後ハンズオンガイド

OVERVIEW

午後ハンズオンの全体像

7工程と3つの人間確認ポイント。いま自分がどこにいるかを常に意識する。

route7工程の流れ

arrow_forward arrow_downward

keyboard_return arrow_downward

arrow_forward arrow_downward

front_hand人間が必ず止まる3つのポイント

CP1

書く前に構成を確認する

info AIのレビュー結果をそのまま採用せず、最終判断は人間がする。順番・必須情報・差別化・CTA導線を確認してから本文作成へ進む。

確認観点

読者が理解する順番になっているか
必須情報が抜けていないか
差別化が見出しレベルで入っているか
CTAまで自然につながっているか

CP2

出す前の最終確認

info ファクトの修正漏れ・要確認の残り・禁止表現・機密混入・トーンを人間の目で止める。AIに任せたからこそ、最後の止め場所を分けて持つ。

確認観点

NGファクトの修正漏れはないか
要確認メモが本文に残っていないか
禁止表現・強すぎる断定はないか
機密情報・個人情報が混入していないか
クライアントに出して問題ないトーンか

CP3

次の案件に渡す形に確定

info 改善ログを書いて終わりではなく、CLAUDE.md・エージェント定義に反映する。ここで決めたルールが次の案件の精度を上げる。

確認観点

案件フォルダの improvement-log.md に記録したか
「次回守るルール」を rules.md に昇格させたか
全案件共通ルールは CLAUDE.md に反映したか

checklist進め方のルール

講師の画面で流れを見る
同じプロンプトを自分の環境で実行する
出力が出たら、すぐ次に進まない。人間確認ポイントで一度止める
完璧な出力ではなく、工程の分け方と確認の入れ方を体験する

詰まったとき： 各タブ末尾の「サンプル出力」を読み込んで次に進む。完成度より、工程を体験することを優先。

STEP 0

案件フォルダを用意する

記事を書き始める前に、案件ごとの「作業場」を1つ作る。複数案件でもログやルールが混ざらないための土台。

folder_open道具と作業場を分ける

Starter Kit は共通の道具：スキル本体・サブエージェント。全案件で使い回す。
案件フォルダは案件ごとの作業場：成果物・入力・ルール・改善ログを案件単位で分ける。
改善ログは案件ごとに分ける：全案件を1つのログに混ぜない。
クライアント別ルールは rules.md に置く：トーン・禁止表現・品質基準を1ファイルに。

なぜ分けるのか： 案件ごとに分けることで、AIが「今どの案件のルールで動くか」を間違えなくなる。

account_treeフォルダ構造のイメージ

article-workspace/
├── client-a_seo/          ← 案件フォルダ（作業場）
│   ├── input.md           今回の入力
│   ├── rules.md           この案件のルール
│   ├── outputs/
│   │   └── {KWフォルダ}/    記事ごとの成果物（01〜05）
│   └── improvement-log.md  この案件の改善ログ
│
└── client-b_note/         ← 別案件は丸ごと別フォルダ
    └── …

play_circle当日のワーク：案件フォルダを1つ作る

Claude Code にこう伝える：

記事を書きたいです

→ スキルがまず「どの案件フォルダで作業するか」を聞いてくる

扱いたい案件・テーマを1つ決める（実案件でも練習テーマでもOK）
フォルダ名を決めて伝える（例: personal_blog）
「rules.md を作りますか？」と聞かれたら「作って」と答える
input.md に今回の記事の入力を書く

NEXT 案件フォルダができたら、① リサーチへ。以降の成果物はすべて outputs/ の中にまとまります。

STEP 1

リサーチ実行

記事を書く前の地図づくり。本文ではなく、構成作成に渡す"材料"をそろえる工程。

emoji_objectsこのパートのゴール

search リサーチャーを起動して結果を見る

person_check 「人間が確認する観点」を体験する

arrow_forward 次の構成へ材料を渡す

STEP 1-1 入力テンプレを埋める expand_more

input_template.md に入れる内容：

テーマ / キーワード / 想定読者
記事の目的・競合URL
必ず確認したい公式情報
禁止事項 / 最終的な出力形式

前提が曖昧なまま渡すと、それっぽいけど使いにくいリサーチになる。

STEP 1-2 依頼する expand_more

リサーチして

（または「リサーチお願い」「KWで調べて」）

Claude Code — 実行イメージ

リサーチして

✦

input_template.md を読む

検索意図・競合分析を実行

一次情報候補を整理

安全確認メモを生成

research_note.md に保存

✓ リサーチ完了。research_note.md に保存しました。

STEP 1-3 スキルが自動でやること expand_more

crew-researcher が起動し、input_template.md を読んで以下を返す：

狙うKW / 検索意図 / 顕在&潜在ニーズ
競合共通点&弱点 / 一次情報候補 / 安全確認メモ
出力フォーマット固定・本文・構成案には進まない

STEP 1-4 返ってきてほしい中身（6項目） expand_more

① 検索意図：読者が知りたいこと / 解決したい不安
② 顕在ニーズ・潜在ニーズ：表に出ているもの / 本当は気にしていそうなこと
③ 競合の共通点：どの記事にもある情報
④ 競合に足りない要素：差別化できる余地
⑤ 一次情報候補：公式サイト / 公的機関
⑥ 安全確認メモ：断定注意 / 鮮度 / 引用注意

STEP 1-5 人間が見る6つの観点 expand_more

① 検索意図：読者がどの順番で理解したいかを見る。ここがズレると構成も本文もズレる。

② 顕在/潜在ニーズ：良い構成は潜在ニーズまで回収する（失敗しないか・自分にも使えるか）。

③ 競合の共通点：真似するためではなく、読者期待の最低ラインを見るため。コピペ材料ではない。

④ 競合に足りない要素：奇抜なことではなく、読者が次に判断できる情報を補う。

⑤ 一次情報候補：競合記事はファクトの根拠として弱い。最終確認は一次情報に当たる。

⑥ 安全確認メモ：URLが貼られていることと、ファクトチェック済みは違う。AIが出したURLの中身と主張が一致するか確認。

STEP 1-6 結果を保存 expand_more

保存先：research_note.md

検索意図 / 顕在・潜在ニーズ / 競合共通点 / 競合不足 / 一次情報候補 / 安全確認メモ / 構成担当への注意点

NEXT リサーチの出口は本文ではなく構成。検索意図 / 読者の理解順 / 必須情報 / 差別化要素を渡す。

詰まったとき： sample_outputs/01_research_note.md を読み込んで次の構成作成へ進む。

STEP 2

構成作成・構成レビュー

本文を書く前に、"何を、どの順番で伝えるか"を決める。レビューを挟んでからCP1で人間確認。

emoji_objectsこのパートのゴール

architecture 設計者を起動して構成案を作る

rate_review 構成レビューが自動で動くのを見る

pause_circle CP1（人間確認）で止まる体験をする

STEP 2-1 設計者に依頼する expand_more

OK、構成に進んで

（または「構成行こう」「構成案作って」）

構成案は見出しの一覧ではなく、"設計意図つき" で出してもらう。

STEP 2-2 スキルが自動でやること（4セクション固定） expand_more

02_designer.md が動き、以下を返す：

① 記事コンセプト（ターゲット読者 / 読了後の状態 / 核心メッセージ）
② 記事設計（タイトル案2〜3 / 差別化 / 読後の行動変容）
③ 見出し構成案（H2/H3 + 読者がここを読む理由）
④ 各セクションの要旨（【一次情報】【要ファクト】タグ付き）

STEP 2-3 返ってきてほしい構成案の要素 expand_more

タイトル案 / 導入文で触れること / H2・H3と各見出しの役割 / 読者ニーズとの対応 / 一次情報を入れる場所 / 差別化ポイント / 執筆時の注意点

見出しだけだと後で本文を書くときに意図が崩れる。"なぜその見出しが必要か" まで残す。

STEP 2-4 構成を見るときの4つの観点 expand_more

① 読者が理解する順番：書き手が話したい順番ではなく、読者が迷わない順番か。前提→不安解消→比較基準→読後行動の自然な接続。

② 必須情報と差別化を分ける：必須情報だけだと普通の記事、差別化だけだと不足。土台＋価値の両輪。

③ 一次情報を入れる場所：料金・制度・数値のH2に目印をつける。後でファクト修正が大きくならないように。

④ CTAまでの流れ：前提理解 → 自分ごと化 → 判断基準 → 不安解消 → 次の行動。押し込みではなく導線。

STEP 2-5 構成レビューを実行する expand_more

構成レビューして

（または「構成チェック」「この構成見て」）

Claude Code — 実行イメージ

構成レビューして

✦

03_structure_reviewer.md 起動

7観点でスコアリング（14点満点）

GO条件を判定

スコア 11/14 — 要修正 → 差し戻し

修正後再レビュー → スコア 13/14 — GO

✓ 構成レビュー完了。CP1へ進んでください。

STEP 2-6 レビュー結果で見たいもの expand_more

① 良い点：構成として活かす点
② 修正した方がよい点：順番の違和感 / 見出しの不足 / 差別化不足
③ 修正案：見出しの追加 / 順番の入れ替え / 統合 / 削除
④ 人間が確認すべき点：判断が必要な箇所

CP1

ここで一度、手を止める — 人間が構成を確認する

info AIのレビュー結果をそのまま採用せず、最終判断は人間がする。確認してから本文作成へ進む。

確認観点

読者が理解する順番になっているか
必須情報が抜けていないか
差別化が見出しレベルで入っているか
一次情報を入れる場所があるか
CTAまで自然につながっているか
実案件ならクライアント確認が必要な箇所はないか

STEP 2-7 修正指示を出す expand_more

CP1の人間確認を踏まえて、構成案を修正してください。修正時は、・どこを変えたか・なぜ変えたか・本文作成時に注意することをあわせて残してください。

STEP 2-8 構成案を保存 expand_more

保存先：outline.md

最終構成案 / 各H2-H3の役割 / 差別化ポイント / 本文作成時の注意点 / CP1で修正した内容

NEXT 本文ライターに渡す：input_template.md / research_note.md / outline.md
本文作成はゼロから書く工程ではない。設計通りに書く工程。

詰まったとき： sample_outputs/02_outline.md を読み込んで CP1 に進む。

STEP 3

本文作成

チェック工程へ渡すための下書き作成。設計図どおりに書く工程。

emoji_objectsこのパートのゴール

edit_note 本文ライターを起動してドラフトを出す

compare_arrows outline.md からの逸脱がないか見る視点を持つ

label 未確認ファクトに【要確認】タグが付くのを見る

STEP 3-1 依頼する expand_more

本文書いて

（または「執筆お願い」「この構成で書いて」）

STEP 3-2 スキルが自動でやること（3セクション固定） expand_more

04_writer_light.md が動き、以下を返す：

① メタディスクリプション
② 本文（H2/H3階層・構成案準拠）
③ 執筆メモ（要確認タグ含む）
未確認ファクトは【要確認】タグで残す

STEP 3-3 本文で守ること expand_more

導入で読者の悩みを受け止める
見出しごとに役割を守る
専門用語は先に説明する
根拠が必要な主張は強く言い切らない
数字 / 料金 / 制度 / 仕様は確認前提にする
CTAに向けて自然につなげる

STEP 3-4 Markdownで保存する expand_more

保存先：draft.md

# タイトル

## H2見出し

### H3見出し

- 箇条書き

[リンクテキスト](URL)

STEP 3-5 未確認ファクトは印をつける expand_more

確認前提で印をつけたい箇所：料金 / 数値 / 制度 / 仕様 / 日付・期限

例：【要確認：公式料金ページ】

STEP 3-6 AIっぽい本文にしないために expand_more

大げさに言いすぎない
同じ語尾を続けすぎない
一般論だけで段落を埋めない
読者の具体的な不安に触れる
結論だけでなく判断基準を書く
使っていない情報をそれっぽく足さない

STEP 3-7 手元チェック（任意） expand_more

outline.md の意図からズレていないか
未確認ファクトが断定されていないか
競合記事の表現に近づきすぎていないか
文章が一般論だけで薄くなっていないか

STEP 3-8 必要なら本文を修正する expand_more

手元チェックで気になった点を踏まえて、draft.md を修正してください。修正時は、・構成意図からズレた箇所を直す・未確認ファクトに印をつける・一般論で薄い箇所を具体化する・断定が強い箇所を調整することを優先してください。

NEXT ファクトチェッカーへ渡す：draft.md / research_note.md / 未確認ファクトのメモ
ここからは "読める文章か" ではなく "出してよい情報か" を見る。

詰まったとき： sample_outputs/03_draft.md を読み込んでファクトチェックへ進む。

STEP 4

ファクトチェック

URLがあることではなく、URLの中身と本文が合っているかを確認する工程。AIに任せきらない。

emoji_objectsこのパートのゴール

fact_check ファクトチェッカーを起動して判定一覧を見る

do_not_disturb NG/要確認が人間判断に渡る流れを体験する

link_off "URL貼ってあるから安心" は通用しないと知る

STEP 4-1 依頼する expand_more

ファクトチェックして

（または「ファクト確認」「事実確認して」）

STEP 4-2 スキルが自動でやること（5判定ラベル） expand_more

crew-fact-checker が起動し、5判定ラベルで返す：

一次情報で確認でき、本文と一致

暫定OK

複数ソースで整合・一次情報が弱い

根拠と本文が違う。修正が必要

要確認

AIだけでは判断できない。人間確認が必要

鮮度注意

情報が変わる可能性あり。日付確認が必要

STEP 4-5 URLの中身を見る expand_more

URLは実在するか
ページの発行元は信頼できるか
本文の主張とURL先の内容が一致しているか
古いページではないか
競合記事を根拠にしていないか

AIがURLを出していても、そのURLが根拠になっているとは限らない。

STEP 4-7 修正案を反映する expand_more

ファクトチェック結果を踏まえて、draft.md を修正してください。修正時は、・NG箇所は根拠に合わせて直す・要確認箇所は断定を避ける・鮮度注意の箇所は日付つきで扱う・根拠URLを本文またはメモに残すことを優先してください。

STEP 4-8 チェック結果を保存 expand_more

保存先：fact_check_report.md

チェック対象 / 判定 / 根拠URL / 修正案 / 人間確認が必要な点

NEXT 納品前チェッカーへ：修正後の draft.md / fact_check_report.md / 未解決の要確認箇所

詰まったとき： sample_outputs/04_fact_check_report.md を読み込んで納品前チェックへ進む。

STEP 5

納品前チェック

記事を"出せる状態"にする最後のゲート。CP2 で人間が止める。

emoji_objectsこのパートのゴール

task_alt 納品前チェッカーを起動してスコアを見る

low_priority GO / 要修正 / ループ上限到達の判定を読む

pause_circle CP2（人間が最終確認）で止まる体験をする

STEP 5-1 依頼する expand_more

納品前チェック

（または「最終チェック」「納品前見て」）

STEP 5-3 判定3つの意味 expand_more

12点以上・要修正0件。そのまま納品してよい状態

要修正

修正すれば進められる状態（自動差し戻し・最大2回）

ループ上限到達

2回ループしても閾値未達。AIだけで決めない方がよい状態

CP2

ここで一度、手を止める — 人間が最終確認する

info ファクトチェックと納品前チェックの結果を踏まえて止める。機密混入が検出されていた場合は、ここで必ず人間判断する。

確認観点

NGファクトの修正漏れはないか
要確認メモが本文に残っていないか
禁止表現や強すぎる断定はないか
競合表現に近すぎる箇所はないか
機密情報・個人情報が混入していないか
クライアントに出して問題ないトーンか
ファイル名・形式・納品物が揃っているか

NEXT スライドに戻り §14（改善ログ・転用・締め）へ。改善ログを improvement-log.md に記録し、CP3 で「次回守るルール」を rules.md へ昇格させます。

詰まったとき： sample_outputs/05_delivery_check_report.md を読み込んで CP2 に進む。