【ユニコ🦄】ClaudeCodeセミナー実況の匿名裏掲示板 in #ユニコスクール

課題1-1〜1-4をやってみた感想を、次に取り組む方へのフィードバックとしてまとめたいと思っています。

HTMLやファイルではなく、そのままコピーできるプレーンテキストで出力していただければ幸いです。

内容は以下の3点です。

①やった課題

②想定外だったこと

③最初のコピペ用プロンプトへの具体的な改善案

最後に、掲示板にそのまま貼れる1500字以内の要点版も付けていただけますと幸いです。

【Claude Codeをはじめる 1-1〜1-4 を体験した感想】

■やったこと

1-1 セットアップと定型プロンプト。1-2 観光地ランキングHP作成（DESIGN.md美学適用セクション実装）。1-3 TOP3への画像差し込み。1-4 裏側の管理システムをモック生成（設計図PNG＋動く単一HTML＋自動ブラウザ起動）。

■良かった点

• 要所で「A/B/Cどれ？」と選択肢を提示してくれるので迷わずに進められました。
• 作業後に要約＋「次はどうしますか？」まで提案してくれるため、手が止まりません。
• 成果物がその場でブラウザで動く（外部連携なし）ので、初心者でも達成感を早く得られます。
• 既存ファイルを壊さず新規で作成してくれる安心感がありました。
• 画像まで自律的に探して用意してくれたのは、良い意味で想定外でした。

■詰まった点

• 最初のコピペ用プロンプトの略語（Mon / A2A / rev=cr+sr / 3層振分 / STORE_KEY昇格 等）が難解で、意味を把握しないまま進む感覚がありました。
• 記号（/ や ）主体の指示では「本当に通じているか」が不安になり、後から日本語で確認し直しました。
• 1課題の粒度が大きく（1-2は実質3工程）、どこまで一気に進むか事前に読めませんでした。
• 画像は自分で用意する前提だと誤解していました。

■改善案（最初のプロンプト向け）

1. 略語に初回だけ注釈を付ける（例：rev=cr+sr＝コードレビュー+セキュリティレビュー）。

2. 記号の前に平文で【今日のゴール】を1文書く欄を設ける。

3. 「各工程で一度止まって確認しますか？（はい／一気に）」の確認欄を入れる。

4. 出力形式を先に固定する。

5. 課題番号と工程を対応づけたテンプレートにする（1-2＝①設計②美学③実装）。

6. 「分からない略語は先に聞き返してください」と一言加える。

■総評

体験としては非常にスムーズで、完成物の満足度も高いです。唯一のハードルは「最初のプロンプトの難解さ」でした。ここを平文＋注釈で補うだけで、次に取り組む方の不安がかなり軽減されると思います。おすすめです。

全体的にわかりやすい内容でした。

ただ一点、Windowsのインストール画面も実演で見られると、さらにありがたかったと感じています。

特に難しくはありませんでした。

ただ、WEBサイトのテーマの部分は少し戸惑いました。

コピペからのスタートでここまでやれたので、先が見えてきた気がしています。

課題1-1〜1-4をひと通りやってみましたので、感想と気づきをまとめます。

全体の流れは「まず動くものを出すデザインを整えるロジックを作る振り返る」という順番で、後半になるほど指示の書き方の重要さが効いてくる構成でした。

詰まった点は主に2つです。

• コピペ用プロンプトの略語の難度が高く、「rev=cr+sr」「STORE_KEY昇格」「3層振分」などが初見では読み解きにくく、動きはするものの「なぜこう作られたか」を自分で説明できないまま進んでしまいました。

• 穴埋め欄の空欄送り問題が最大の落とし穴でした。`[ホームページで作りたい内容]`の[ ]を埋め忘れると、AIがフォルダ名などから推測して意図と異なる成果物が出力されます。

逆にスムーズだったのは、「単一HTML／localStorage／日本語」のような一意に決まる具体的な指定や、「セクション単位で実装」「confirmは使わずモーダルで」といった作り方の指定です。曖昧さが消えることでコードの品質が安定しました。

改善案として以下4点を提案します。

① 穴埋め欄に「※[ ]内は必ず自分の内容に置き換えてから送信。空欄のまま送らない」と明示する

② 略語には初回だけ日本語注釈を1行追加する（例：rev=cr+sr＝コードレビュー＋セキュリティレビュー）

③ メタ指示（動き方のルール）とタスクを段落で分離する

④ 主観ワードは色コードやフォントサイズなど、逃げ道のない具体的な表現に言い換える

次の方の参考になれば幸いです。

課題1-1〜1-4をやってみた感想を、次に取り組む方へのフィードバックとしてまとめていただけますか。

以下の3点を含む形でお願いできますと助かります。

①取り組んだ課題の内容

②想定外だったこと

③最初のコピペ用プロンプトへの具体的な改善案

最後に、そのままこの掲示板に貼れる1500字以内の要点版テキストも添えていただけると嬉しいです。

HTMLやファイル形式ではなく、コピーしてそのまま使えるテキストでお願いします。

ついにできました！

この短時間でここまで作れるとは、ClaudeCodeの実力に驚いています。

課題1-1〜1-4をすべて通して実施した感想です。

良かった点

「白ベース・文字大きめ」「5tab」「モーダルはconfirm禁止」のような具体的・数値的な指定は迷いなく反映されました。

曖昧な形容詞よりも、箇条書き＋禁止事項＋数値の組み合わせの方が圧倒的に精度が上がる印象です。

配色変更のような差分修正は、対象コードを検索して一括置換できるため非常にスムーズでした。

詰まった点

課題1-4のプロンプトは独自の略語記法（CC(goal/Mon/batch/...)のような記法）から始まっており、初めて見ると何を指示されているか読み解くのに時間がかかりました。

結果自体は問題なく出ますが、次に取り組む方のために日本語の意訳を一言添えるとハードルが下がると思います。

課題1-3では、依頼文の[ ]部分が「例：ゴシックアクセサリー」というサンプルのまま残っていました。

実際の題材に書き換える前提のテンプレだと思いますが、気づかずそのまま実行してしまうリスクがあるため、「ここは書き換えてください」という明示があると親切です。

また「白ベース」という指定と依頼内容（ゴシック＝黒が主役の世界観）が本質的に矛盾するケースがありました。

どちらを優先すべきかの判断基準が事前にあると、確認の往復を減らせると感じました。

次に取り組む方へのアドバイス

• 略語だらけの指示でも臆さずそのまま投げてOKです。意味が分からない場合は「これはどういう意味？」と聞けばちゃんと解説してくれます。
• テンプレの[ ]部分は必ず自分の実際の題材に書き換えてから送ってください。
• 「白ベースで」「大きく」のような見た目の指定は具体的に書くほど狙い通りの結果になります。
• 大きめの依頼（システム設計など）ほど、成果物の箇条書きを先に決めておくと、認識合わせがスムーズです。

【Claude Codeをはじめる（課題1-1〜1-4）やってみた感想メモ】

■① やった課題（実際に作ったもの）

• 1-1：環境の初回起動・お試し（Claude Codeに話しかけて動かす感覚をつかむ）
• 1-2：HTML単一ファイルのシューティングゲーム制作（「超作り込んで」と一言オーダー）
• 1-3：テーマサイト制作（DESIGN.md → 美学プロンプト → セクション単位で実装、の3ステップ）
• 1-4：1-3で作ったサイトの「裏側の管理システム」をモックで制作（5タブ・スコアリング・承認フロー・AIアシスト）

※全部「1つの指示（コピペ用プロンプト）を投げる → 成果物が出てくる → ブラウザで開いて確認」という同じ流れ。慣れると2〜4がテンポよく進む。

■② 想定外だったこと

●詰まった所

• プレビュー（自動でサーバーを立てて表示する機能）が権限エラーで起動しないことがあった。結局「file://のフルパスで直接開く」やり方に切り替わって解決したが、最初これで少し止まった。→ 次の人は最初から「file://フルパスで開いて」と頼むと早い。
• 「削除」など取り消せない操作は確認が入る（これは安全なので良い挙動。むしろ安心）。
• 最後の管理ツール、サンプルデータが少なく感じた。画面の凄さを実感するには、最初からもっと多め（20件くらい）のダミーデータが入っていてほしかった。→ プロンプトで「サンプルを◯件、最初から投入」と件数を指定するのが正解だった。

●分かりにくかった言葉

• コピペ用プロンプトが略語だらけ（goal / Mon / batch / Plan / Hook / Rule / Skill / Flow / A2A / rev=cr+sr / STORE_KEY昇格 など）。強力なのは分かるが、初見だと呪文にしか見えない。意味の対訳（用語集）が欲しい。
• 「図解PNG」と頼んだのに、PNGでは返ってこずSVG（HTML内の図）になった。裏に「PNGは直接開かない運用ルール」があったため。意図と違う場合は「PNG画像ファイルとして書き出して」と明示が必要。
• 「level3」「3層振分」など数字・階層の指定は、何を意味するか事前に共有されていないと伝わりにくい。

●逆にスムーズだった所

• 「単一HTMLファイルで完結」と指定すると、ダウンロードもインストールも不要で即ブラウザで動く。初心者には最高の即効性。
• DESIGN.md（デザインの設計図）を先に作らせる流れは、色・文字サイズ・世界観がブレず、仕上がりが一気にプロっぽくなった。
• 「localStorageで保存」と入れておくと、リロードしてもデータが残る。モックなのに“本物っぽさ”が出て感動した。
• 「必ず“凄い！”と思えるモックにして」の一言が地味に効く。クオリティの下限が上がる。

■③ 最初のコピペ用プロンプトへの具体的な改善案

（1）冒頭に“固定のお約束文”を1行入れる：

　「日本語で回答。成果物は単一HTMLファイル。完成したらfile://のフルパスで開いて、何をどこに作ったか教えて。」

（2）略語には初回だけ日本語の対訳を添える（例：A2A＝複数AIで分担／rev＝レビュー／STORE_KEY＝保存用の合言葉）。もしくは略語版と“普通の日本語版”の2種類を用意する。初心者はまず普通の日本語版でOK。

（3）出力形式は1語で明示：HTML / PNG / SVG / テキスト のどれで欲しいかを必ず書く。

（4）サンプルデータは件数を指定：「ダミーデータを15〜20件、最初から入れておいて」。

（5）品質の下限を固定文で：「必ず“凄い”と思える業務効率化ツール（モック）にして。サービス連携は不要、まず見た目とイメージ優先」。

（6）詰まりがちな“プレビュー起動”を回避する一文：「サーバーは立てず、file://で開く方式で」。

総じて、最初のプロンプトのハードルさえ下げれば、初心者でも短時間で“動くもの”が作れて達成感が高い課題でした。

【課題1-1〜1-4 やってみた感想／次の人へ】

◆やったこと

日本語の指示1行だけで、Claude Codeにシューティングゲームを作ってもらう課題。

「HTMLで超作り込んだ…作って。完成したらブラウザでOpen」で、

自機移動・チャージ砲・ボム・コンボ・ボスまで入った1枚もののゲームが完成しました。

◆スムーズだった所

ざっくり日本語1行で本当に遊べるゲームが出てくるのは感動もの。

操作方法も画面に出るので、遊び方には迷いません。

◆詰まりやすい所（次の人向け注意）

1. 「ブラウザでOpen」の所で、Windowsだと“許可しますか？”というダイアログが

出ることがあります。慌てず「はい／許可」を選べばOK。

2. 出来たファイル名や保存場所が分かりにくい。

後で開き直せるよう、ファイル名とパスを聞いておくと安心です。

3. 「超作り込んで」と頼むとコードがかなり長くなり、生成に少し時間がかかります。

最初は「1画面で遊べる範囲でOK」くらいが安心。

◆最初のプロンプトはこう直すのがおすすめ

「超作り込んだ」「サイトOpen」は曖昧なので、下記のように具体的に頼むと迷いません↓

　HTMLでオリジナリティのあるシューティングゲームを作ってください。

　まずは1画面で遊べる範囲でOK。HTML・CSS・JavaScriptは1ファイルにまとめて。

　完成したらWindowsの既定ブラウザで開いて（許可を聞かれたら“はい”でOKと教えて）。

　最後に、保存したファイル名とフルパス、遊び方を日本語で教えてください。

「ファイル名・保存場所・遊び方を最後に教えて」を足すだけで、

初心者のつまずきがかなり減ります。次にやる人の参考になれば！

■ ① やった課題

架空の美容院サイトを題材に、一連の制作を行いました。

• 課題1-1：ホームページのデザイン制作（DESIGN.md作成 → Claude Cookbookの美学プロンプト適用 → セクション単位でHTML実装。白ベース・文字大きめ）
• 課題1-2：サイトの裏側システム制作（仕様駆動MVP。5タブ／100点満点の顧客スコア＋3層振分／承認ワークフロー／構成図PNG／localStorage保存の単一HTML）
• 課題1-3：機能拡張とLINE誘導の追加（売上グラフ／スコア条件のカスタム設定／サービス連携イメージ／サイトへのLINEボタン設置）
• 課題1-4：ここまでの作業内容のWord書き出し

いずれも、最初に渡す1つのプロンプトから始めて、あとは短い対話で肉付けしていく流れでした。

■ ② 想定外だったこと

〈詰まった／戸惑った所〉

• 最初のプロンプトに例文（「例：原宿の…スイーツのお店」）がそのまま残っていて、自分が作りたい内容に書き換えるのを忘れていた。Claudeが「例文のままですが何を作りますか？」と聞き返してくれて助かったが、危うくサンプル通り進むところだった。
• 冒頭の呪文のような一行（CC(goal/Mon/batch/Plan/Hook/…)→…rev=cr+sr/Ultra）が何を指すのか最後まで分からなかった。A2A・ckpt・Flow FO・rev=cr+sr などの略語は初見で して貼っている感覚だった。
• 2回目以降に出てくる専門用語が難しかった。「仕様駆動MVP=level3」「100点＋3層振分」「承認段階ゲート引継型」「モーダル(

confirm禁止)」「STORE_KEY昇格」「各画面🤖pt 分では絶対に書けない。すごいものはできたが、"自分で再現できる気がしない"のが正直な感想。

• （環境面）日本語を含むスクリプトの文字コー 自動で直してくれて実害はなかったが、Windowsだとこういう引っかかりがあると知った。

〈逆にスムーズだった所〉

• 作るたびに勝手にブラウザで開いて見せてくれ 持ちよかった。
• 「1,2,3」や「選ばれる理由を追加」のような短い返事でも、意図をきちんと汲んでくれた。
• 構成図PNGもWord文書も、専用ソフトなしで生 ルパスを教えてくれるので迷子にならなかった。
• 要望のたびに「次はこれもできます」と選択肢を出してくれるので、次に何を頼めばいいか分かりやすかった。

■ ③ 最初のコピペ用プロンプトへの具体的な改善案

1. 例文プレースホルダーは"空欄＋必須項目"に変える

　「[…例：原宿の…]」だと消し忘れる。埋めるべ わない。

　例：

• 業種：〈　　〉（例：美容院）
• 店名：〈　　〉
• 場所：〈　　〉（最寄り駅・エリア）
• 一番の強み：〈　　〉
• 欲しいセクション：〈　　（未定ならおま

　最初にこの5項目を埋めておけば、聞き返しの往復が減って一発で進む。

2. 冒頭の略語一行は「削る」か「日本語の注釈

　初心者にはCC(goal/Mon/batch/…)が逆に不安要素になる。使うなら末尾に一言、

　「※この行はClaudeの動き方の設定です（気に

　があるだけで安心度が段違い。分からなければ思い切って消してよい。

3. 専門用語には"ねらい"を添える

　「100点＋3層振分」→「顧客を100点で採点し、優良／普通／離反リスクの3つに自動で振り分けたい」

　「承認段階ゲート引継型」→「申請→上司確認→ 当に引き継ぐ仕組み」

　のように〈用語＝やりたいこと〉をセットで書くと、意味が分からなくても正しく伝わり、後から自分でも読み返せる。

4. 最初に「保存場所」と「完成イメージ」を指

　「ファイルは〇〇フォルダに」「まずは動くイメージだけ見たい（連携は後で）」と先に言うと手戻りがない。今回も「サービス連携は一旦不要・イメージ優先・急ぎ」と伝えた てくれた。最初に言うほど早い。

5. ゴールと粒度を1行で …　「最終的に何を・誰に見せたいか」を先頭に置

　例：「印西の美容院の集客用サイトを、白ベースで作りた

〈まとめ〉 …専門用語をそのまま貼れば"すごいもの"は出てく か」が分からないまま進みがち。次にやる人は、①最初の5項目を埋める ②分からない略語は消すか注釈する ③用語には"やりたいこと"を添える——この3点を意 られて満足度が高いと思います。

【Claude Codeをはじめる｜課題1-1〜1-4 やってみた感想（次にやる人へ）】

■ ぜんたいの感想

最初の「呪文みたいなプロンプト」を貼るところだけ身構えたけど、いざ走らせると勝手に確認質問をしてくれたり、右のプレビューが自動で更新されたりで、想像よりずっとスムーズでした。「完璧なプロンプトを書かなきゃ」と気負わず、まず貼って走らせて、あとから会話で直していくのが正解です。

①やった課題（何を作ったか）

• 課題1-1：ホームページ制作

└ DESIGN.md（設計書）作成 → Cookbookの美学プロンプトを適用 → セクション単位でindex.htmlを実装。白ベース・文字大きめのAIコンサル系LP。

• 課題1-2：背景を「AI風・スタイリッシュ」に、さらに「もっとかっこよく」

└ ニューラルネット風の粒子アニメ、グラデ見出し、光るカード枠などを追加。

• 課題1-3：AIっぽい写真や絵を追加

└ ヒーローの「AIコア」ビジュアルやサービスアイコンを追加。

• 課題1-4：サイトの裏側システムを仕様駆動で構築

└ 問い合わせフォームの裏側にあたるリード管理CRM（5タブ／100点スコア／3層振り分け／承認フロー）を単一HTMLのモックで作成。

※各課題の最後に「ブラウザで開く」まで自動でやってくれます。

②想定外だったこと

＜詰まった・分かりにくかった＞

• 最初のプロンプトが超圧縮された暗号みたいな見た目（goal/Mon/batch… や 100点+3層振分／承認段階ゲート引継型／STORE_KEY昇格／A2A など）で、「これ自分が理解してないと進められないのでは？」と不安に。→ 実際は理解してなくてもClaudeが解釈して形にしてくれるので、まず貼ればOKでした。ここは事前に「意味が分からなくてもそのまま貼ってOK」と一言あると安心。
• 課題文の [ ] のプレースホルダ（例：H.P.S AIコンサルタント…）を、そのまま貼ってしまいがち。中身を自分の内容に書き換えないと「例」のまま作られます（今回はClaudeが気づいて確認してくれた）。
• 「AI風の写真を入れて」＝実写っぽい画像が出てくると思いきや、著作権・オフライン対応の都合で“ベクターの図（SVG）”が入りました。イメージと違う場合は指定が必要。
• 「図解PNGで出して」と指定しても、環境にPNG変換ツールが無く、SVGでの提供になりました。PNGが必須なら別途手当てが要ります。
• 専門用語がそのまま出てくる（モーダル＝ポップアップ、localStorage＝ブラウザ内保存、シード＝初期サンプル投入 など）。意味は動くものを見れば分かるけど、初見だと固まる。

＜逆にスムーズだった＞

• 右のプレビューが編集のたび自動更新されるので、コードを読まなくても仕上がりを目で確認できた。
• 「もっとかっこよく」みたいなふわっとした指示でも、ちゃんと具体化して盛ってくれる。
• 修正はセクション単位・会話ベースででき、「ここだけ直して」が効く。
• 作った後に自動でブラウザまで開いてくれるので、完成の実感がすぐ得られる。

③最初のコピペ用プロンプトへの改善案（具体）

1. プレースホルダを「自分の言葉」に必ず書き換える

例）[ホームページで作りたい内容] の部分を、

「作るサイト：○○（屋号）／事業：△△／ターゲット：□□／ゴール：問い合わせ獲得」

のように埋めてから貼る。ここが空欄・例のままだと汎用的な仕上がりになります。

2. 圧縮プロンプトの冒頭に「読み手向けの一文」を足す

例）「※下記は指示の要約です。意味が分からない用語はそのままでOK。作りながら質問してください。」

これがあるだけで初学者の心理的ハードルが激減します。

3. 画像の希望を先に明言する

例）「画像は “実写風の写真” が欲しい／“ベクターイラストでOK” のどちらか」を書く。

実写が欲しいなら「自分で用意した画像をこのフォルダに置くので<img>で組み込んで」または「画像生成用プロンプトも作って」と添える。

4. 出力形式（PNG等）は“無ければ代替でOK”を書いておく

例）「図解はPNG希望。変換ツールが無ければSVGで可」。こう書くと止まらず進みます。

5. デザインの好みは具体語で

「白ベース・文字大きめ」は的確に効いた良い例。加えて「派手め／ミニマル」「参考にしたいサイトURL」を1つ添えるとブレません。

6. 課題1-4（裏側システム）は“誰の何を楽にするか”を1行入れる

例）「問い合わせが来たら、担当が優先順位をつけて対応するまでを楽にしたい」。

用途が1行あるだけで、機能の当たりが一気に良くなります。

7. 最後に必ず入れると良い定型文

「完成したらブラウザで開いて」「サービス連携はまだ不要、まずイメージを見たい」。

これで“動くモックをすぐ確認”という今回の一番おいしい体験に直結します。

■ ひとことアドバイス

身構えず、まず貼る。分からない単語は飛ばしてOK。プレビューを見て「ここ変えて」を繰り返すだけで、それっぽいものが驚くほど早く形になります。完璧な最初の一発より、雑でも走らせて会話で育てるスタイルが、このツールでは一番速いです。

• --

【Claude Codeをはじめる（課題1-1〜1-4）やってみた感想／次にやる人へのフィードバック】

■ ①やった課題

• 課題1-1：HTMLでオリジナルのシューティングゲームを作成→ブラウザで表示
• 課題1-2：ホームページ制作（設計書DESIGN.mdを作る→デザイン方針を適用→セクション単位で実装）
• 課題1-3：そのHPの裏側システム（申込管理ツール）を仕様書ベースで作成
• 課題1-4：ここまでの振り返りフィードバックを作成（←今これ）

どれも「1つ依頼する→数分で動くものが出る→ブラウザで即確認」という流れ。

手を動かす前に完成物が見られるのが気持ちよかった。

■ ②想定外だったこと

＜スムーズだった所＞

• 「作って」だけでも、必要なら向こうから質問を返してくれる。丸投げでも成立する。
• HTMLが1ファイルで完結して出てくるので、環境構築ゼロ。ダブルクリックで動く。
• 「完成したら開いて」で本当にブラウザが立ち上がる。達成感が早い。

＜詰まった所＞

• 課題1-2で、プロンプト内の [ホームページで作りたい内容 例：…] という空欄に気づかず、

　例文のまま送信。→「これは例です、何を作りますか？」と聞き返されて初めて気づいた。

　“空欄＝自分で埋める”が最初は分からなかった。

• 課題1-3は、プロンプトが記号だらけ（out:／5tab／100点+3層／STORE_KEY昇格／中規模A2A…）で、

　何を頼んでいるのか読めないまま送った。結果は良かったが、

　「自分が何を頼んだのか」を理解できていない状態だった。

＜分かりにくかった言葉＞

• 「A2A」「FO」「ckpt」「rw」「cr+sr」…略語が前提知識扱いで、初心者には暗号。
• 「昇格」…“データを確定保存”のことだと後で分かったが、最初は意味不明。
• 「仕様駆動MVP＝level3」…level3が何を指すのか基準が示されず判断できない。
• 「引継型ゲート」…業務用語で、練習課題としては急に難しく感じた。

■ ③最初のコピペ用プロンプトへの改善案（具体）

1) 空欄は「ここを書き換える」と明示する

　Before：[ホームページで作りたい内容 例：原宿の…]

　After ：★ここを自分の作りたい内容に書き換える→「（例：原宿の…／自由に）」

　可能なら末尾に「[ ]が残っていたら書き換え忘れです」と一言添える。

2) 略語・記号は“普通の日本語”に開く

　Before：CC(goal/Mon/batch/…/rev=cr+sr/Ultra)最適選択→…

　After ：「最適なやり方は自分で選んで進めてOK。作業前に、何をどう作るかを一度だけ

　　　　　確認の質問をしてください。完成したらブラウザで開いてください。」

　→ 初心者はまず日本語版から入り、記号版は「上級者向けオプション」として別枠にすると親切。

3) 専門用語には初出に1行の言い換えを付ける

　例：「昇格（＝データを確定保存すること）」「ゲート（＝承認しないと次に進めない関門）」。

　用語禁止ではなく、初出に括弧書きが1つあるだけで安心感が段違い。

4) 完成物のイメージを先に1行で示す

　「最終的に○○が動く状態になります」があると、途中の指示の意味が逆算で分かる。

5) ゴールの重さを課題ごとにそろえる

　1-1（ゲーム）は軽く、1-3（業務システム＋仕様書＋図解）は急に重い。

　間に「小さな1機能を追加」など段差を埋める課題があると挫折しにくい。

■ ひとことまとめ

「動くものがすぐ出る」体験は最高。つまずきの原因はツールではなく“プロンプトの日本語化不足”。

(1)空欄の明示 (2)略語の翻訳 (3)完成イメージの提示——この3つで初心者の詰まりはほぼ消える。

━━━━━━━━…

Claude Code をはじめる（課題1-1〜1-4）｜やってみた感想・次の人へのフィードバック

━━━━━━━━…

■① やった課題（全体の流れ）

1-1: 環境の準備と「最初のプロンプト」投入

• 作業フォルダを開き、冒頭に長いオーケストレーション指示（役割・ルール・

　　出力言語=日本語・メモリ・レビュー方針など）をまとめて貼り付けてスタート。

1-2: ホームページ（LP）のデザイン

• 「①DESIGN.md作成 → ②Claude Cookbookの美学プロンプト適用 → ③セクション単位で実装」

　　という3ステップ指定。テーマは「白ベース・文字大きめ」。

• 成果物は動くHTML1枚。設計書(DESIGN.md)を先に作ってから実装する流れ。

1-3: そのサイトの“裏側システム”（管理コンソール）

• 「仕様駆動MVP=Lv.3」。単一HTML・localStorage保存・日本語・白基調で、

　　5タブ／100点採点→3層自動振分／承認ワークフロー／購読者・売上／設定を実装。

• 「まずはモックでイメージを見たい。外部連携はしない」という前提。

1-4: 振り返り（このフィードバック作成）

• 一連の体験を、次にやる人向けの改善提案としてテキスト化。

→ 通しでやると「設計書→実装→検証→ブラウザで確認」の型が身につく。

　単発の質問ではなく“成果物が出るまで一気に走らせる”感覚がつかめたのが一番の収穫。

■② 想定外だったこと

【詰まった / 分かりにくかった】

• 最初のプロンプトが略語だらけで意味が読めない。

　例：「rev=cr+sr」「中規模A2A→open」「STORE_KEY昇格」「承認段階ゲート引継型」

　「3層振分」「各画面🤖pt」「confirm禁止」など。

　→ 慣れた人の“圧縮メモ”で、初回はどれが必須指示でどれが任意か区別がつかない。

• 「セクション単位に実行」の意味が曖昧。

　→ ファイルを分割するのか、1枚のHTMLを部品ごとに作るのか判断が要る（結果は後者でOK）。

• 「Cookbookの美学プロンプトを適用」が具体的に何を指すか不明。

　→ 実際は「凡庸なAIっぽいデザインを避け、フォント/色/余白に強い方向性を持たせる」指針。

　　リンクや引用元が示されていないと初見では再現しづらい。

• Windows特有の詰まり。図解PNGで絵文字(🤖)が“豆腐(□)”化。日本語フォントに絵文字が

　無いのが原因で、テキスト表記に置き換えて回避。環境依存の落とし穴。

• 「6000字以内」「HTMLにしない」等の“出力形式の縛り”は、先に言われないと作り直しになる。

【逆にスムーズだった】

• DESIGN.md を先に作る流れは非常に良い。実装前に色・フォント・構成が固定され、

　後段のブレが激減する。次の人にも強くおすすめしたい進め方。

• 「白ベース・文字大きめ」のような“制約が明確な指示”は一発で意図通りになりやすい。
• localStorage 保存＋サンプルデータ投入のおかげで、モックでも“動くもの”として

　触れる。承認ゲート（条件を満たさないと次工程へ進めない）も実際に体験できて理解が早い。

• 完成後に「ブラウザで開いて」まで指定すると、確認までワンストップで終わる。

■③ 最初のコピペ用プロンプトへの改善案

方針：略語を減らし「目的・成果物・受け入れ基準・出力形式」を先頭に明示する。

　　　“詰め込み1行”をやめ、箇条書きで1指示=1行にする。

＜Before（実際に貼った圧縮版・一部）＞

　CC(goal/Mon/batch/Plan/Hook/Rule/Skill/Flow/allow/Mem/sec/task/Team/rw/rev=cr+sr/Ultra)…

　仕様駆動MVP=level3。out:図解PNG+動くHTML単一(localStorage/JP/白)・5tab・

　100点+3層振分・…・モーダル(confirm禁止)・STORE_KEY昇格・中規模A2A→open

＜After（初見でも伝わる版のテンプレ）＞

　# 役割

　あなたは私の開発パートナー。日本語で応答し、危険な操作の前は必ず確認して。

　# �を作るか（目的）

　OSSの不具合を紹介し有料情報で稼ぐサイトの「管理画面」をモックで作る。

　外部連携（決済・DB・LLM）はまだ不要。見た目と操作感を確認したい。

　# 成果物

• 単一HTMLファイル1枚（依存なしで開ける）
• データはブラウザのlocalStorageに保存（1つのキーにまとめる）
• 日本語・白基調・文字は大きめ

　# 画面（5タブ）

　1) ダッシュボード 2) 不具合カタログ 3) 承認ワークフロー

　4) 購読者・売上 5) 設定

　# 仕様の要点（用語は説明付きで）

• 採点：不具合を100点満点で採点し、点数で3段階（重大/高/中）に自動分類
• 承認フロー：下書き→技術レビュー→編集レビュー→公開。

　　各段階で必須項目が埋まっていないと次へ進めない（＝ゲート）。進めると次の担当へ引き継ぐ。

• ダイアログはブラウザ標準のconfirm()を使わず、独自モーダルで作る
• サンプルデータを5〜15件入れておく

　# 完了の条件（受け入れ基準）

• 5タブすべて表示され、JSエラーが出ない
• リロードしてもデータが残る
• 完成したらブラウザで開いて見せて

改善の具体ポイント：

　1. 略語は封印し、必要なら「用語＝意味」で1回だけ展開する

　　（例：3層振分＝点数で重大/高/中に自動分類）。

　2. 「目的／成果物／完了条件」を必ず先頭に置く。AIが自走しやすくなり手戻りが減る。

　3. 出力形式の縛り（文字数上限・HTML不可・コピペ用テキスト等）は“最初に”書く。

　4. 「セクション単位」等の曖昧語は、「1枚のHTMLを部品ごとに」など動作で言い換える。

　5. 参照（Cookbook等）はURLか具体的な観点（フォント/配色/余白）に落とすと再現性が上がる。

　6. 環境を1行書く（例：Windows / PowerShell）。図解の文字化けなど環境依存の事故を防げる。

ひとことで：最初のプロンプトは“自分用メモ”ではなく“初対面の人への依頼書”のつもりで書くと、

一発で意図通りに進む。困ったら "まず何を作るか3行で" だけ書いて走らせ、

返ってきた確認質問で詰めるのも有効。

━━━━━━━━…

■ Claude Codeをはじめる（課題1-1〜1-4）やってみた感想 ─ 次にやる人へのフィードバック

【① やった課題】

1-1 PTA連絡協議会のHPデザイン。DESIGN.md作成 → Claude Cookbookの美学プロンプト適用 → セクション単位で実装。要望は「白ベース・文字大きめ」。情報発信／お問い合わせフォーム／資料アーカイブ(再配布)を1ページに。

1-2 フォーム改善。お問い合わせ本文を1000字制限＋文字カウンター、種別ごとの記載テンプレ自動入力、お知らせの重要度マーク（重要／お知らせ／参考）を色＋●で識別。

1-3 裏側の管理システム。仕様駆動MVP(level3)として、単一HTML(localStorage／日本語／白)・5タブ・100点スコアリング＋3層自動振り分け・承認段階ゲート・サンプルデータ・各画面のAI提案・システム構成図PNG。

1-4 機能追加。受領時にメール／チャットへ自動発報（しきい値設定・発報履歴）＋メール返信の下書き自動生成スキーム（編集→送信、2トーン切替）。

【② 想定外だったこと】

●詰まった所

• 日本語Windowsの文字コード。PNGを作る時、PowerShellがスクリプトをANSIで読んで日本語が文字化け → UTF-8のBOMを付けて解決。初見だとほぼ確実にハマる。
• pythonが使えなかった。コマンドは通るのに中身がWindowsストアのダミー（起動しても案内が出るだけ）。結局PowerShellの.NET描画(System.Drawing)でPNGを生成した。
• 最初の指示文が暗号のようで、何を優先してほしいのか読み解くのに時間がかかった（後述）。

●分かりにくかった言葉

• 「level3」「3層振分」「承認段階ゲート引継型」「STORE_KEY昇格」「各画面🤖pt」「中規模A2A→open」など、圧縮された独自略語。推測はできるが人によって解釈がぶれる。
• 「A2A」「FO(ファンアウト)」「ckpt」「rev=cr+sr」は前提知識がないと厳しい。

●逆にスムーズだった所

• 「セクション単位で実装」の指定が効いた。ヘッダー→ヒーロー→…と区切ると、確認も修正も速い。
• 成果物を単一HTML＋localStorageにしたら、ダブルクリックで即動くモックになり、見た目の確認が一瞬だった。
• 後からの機能追加（通知→返信下書き）が既存構造にきれいに乗った。データをバージョン管理（v3→v4へ昇格）しておくと後付けが本当に楽。
• 「凄いと思える業務効率化ツールにして」というゴール指定が、迷った時の判断軸になって助かった。

【③ 最初のコピペ用プロンプトへの改善案】

（元は「CC(goal/Mon/batch/Plan/Hook/…)最適選択→batch/Flow FO→待Mon・危険前ckpt→rev+規模次第A2A→選定/理由/結果/check/要約報告」のような1行圧縮版）

1. 略語に凡例を一度だけ付ける

例：「FO=並列実行 ／ ckpt=危険操作前の確認 ／ A2A=サブエージェント連携」。読めれば解釈のぶれが消える。

2. 環境を最初に明記する

例：「Windows11／PowerShell／日本語環境。ファイルはUTF-8(BOM)で。画像生成はpython不可の場合PowerShellで」。文字化けとpython問題を先回りで回避できる。

3. 専門語に1行の定義を添える

例：「level3＝サンプルデータ＋スコアリング＋承認フローまで入った“動くMVP”」「3層振分＝スコアで最優先／通常／情報に分類」。

4. 出力フォーマットを固定する

「①選定 ②理由 ③成果物(フルパス) ④チェック ⑤要約」と番号で固定すると、同じ体裁で返ってくる。

5. 大きい実装の前に「先に計画だけ出して」を一言入れる

いきなり作らせるより、章立て確認→実装の順が手戻りをほぼ消せる。

6. サンプル値を1つ添える

「例：お知らせは4件、種別は4分類」など具体例があると、想像で埋める部分が減る。

7. 「モック(外部連携なし)」か「本番」かを最初に宣言する

今回は「イメージ優先・連携は後」が明確で助かった。ここが曖昧だと過剰実装になりやすい。

【ひとことまとめ】

「区切って作る」「単一HTMLで即確認」「環境と略語を最初に明示」——この3つで初回でも詰まりが激減する。次の人は②の“文字コード”と“python不可”だけ先に潰しておくと、かなり快適に進められる。

━━━━━━━━━━━━━━━━━━━━━━━━

Claude Codeをはじめる（課題1-1〜1-4）やってみた感想

━━━━━━━━━━━━━━━━━━━━━━━━

■ ① やった課題

• 1-1：Claude Codeで動くもの（HTMLのシューティングゲーム）をゼロから作成し、ブラウザで開くところまで。
• 1-2：それを別ターゲット向けにアレンジ（クールなゲーム→女児向けの可愛いデザインに全面リニューアル）。
• 1-3：成果物の保存先を指定フォルダに移動・整理、以降の保存ルールを会話内で設定。
• 1-4：実務に近い制作（骨盤底筋エクササイズのランディングページ＋その裏側の見込み客管理システムのモック）を、設計書→デザイン→セクション単位実装の流れで作成。

ゲームで「まず動く感動」を得てから、実務レベルの成果物へ段階的に進む構成で、達成感がありました。

■ ② 想定外だったこと

＜逆にスムーズだった所＞

• 「〇〇を作って、完成したらブラウザで開いて」と日本語でお願いするだけで、ファイル作成→自動でブラウザ表示まで一気に進んだのは想像以上に快適でした。
• 「もっと可愛く」「指先まで写るように」など、ふわっとした修正依頼でも汲み取って直してくれる。専門用語を知らなくても会話で進められました。
• 写真の見せ方（表示位置）を数値で少しずつ調整→即反映、の往復が速かったです。

＜詰まった所・分かりにくかった所＞

• 【最大の混乱ポイント】画像がデスクトップアプリ右側のプレビュー欄に表示されない。壊れたのかと思いましたが、「プレビューは仕組み上ローカル画像を読めないだけで、実際のブラウザ（Chrome等）で開けば正常」という仕様でした。ここは事前に知らないと必ず戸惑います。
• 保存先が最初は作業用フォルダ（自分では気づきにくい場所）になっていて、「デスクトップの〇〇フォルダに保存して」と明示するまで、どこに保存されたか分かりませんでした。
• 写真の枠は縦横比が固定なので、「上を見せると下が切れる」というトレードオフが最初ピンとこず、指先を入れる調整で数回やりとりが発生しました。
• 用語のハードル：localStorage、STORE_KEY、承認ゲート、A2A、モーダル等の言葉は、非エンジニアには意味が分からないまま進みます（結果は良いので困りはしないが、理解はできない）。

■ ③ 最初のコピペ用プロンプトへの具体的な改善案

保存先を最初に固定させる一文を入れる。

　例：「作成したファイルはすべて〇〇（例：デスクトップの『作業』フォルダ）に保存してください。今どこに保存したか教えてください。」

　→ 迷子・行方不明を防げます。

プレビュー表示の注意書きをテンプレに含める。

　例：「画像はアプリのプレビュー欄では表示されないことがあります。確認は必ず実際のブラウザで開いた画面で行ってください。」

　→ 「壊れた!?」の誤解を初手で回避できます。

専門用語には「＝ひとこと説明」をお願いする指示を足す。

　例：「専門用語を使うときは、その都度かっこ書きで初心者向けの意味を添えてください。」

　→ 言われるがままでなく、少し理解しながら進められます。

画像/写真を使う課題では、扱い方を先に指定できるようにする。

　例：「写真は同じフォルダに『〇〇.jpg』の名前で保存すれば表示されます、と手順を先に教えてください。」「顔出しの有無」「縦横比の希望」を最初に聞いてくれると往復が減ります。

記号だけの“ショートハンド指示”は初心者には難しい。

　course側で配る詳細指定プロンプト（例：out:… / 5tab / 100点+3層… のような省略記法）は、上級者には便利ですが初学者には暗号に見えます。「初心者はこの記号ブロックを消して、やりたいことを普通の日本語で書いてOK」と明記されていると安心です。

「完成の確認方法」をゴールに含める。

　例：「完成したらブラウザで開き、動作を1つずつ一緒に確認してください。」

　→ 作りっぱなしにならず、触りながら達成感を得られます。

■ ひとことまとめ

「日本語のお願いだけで動くものが完成する」体験は非常に強力。つまずくのは"中身"より"周辺"（保存場所・プレビューの仕様・専門用語）なので、最初のプロンプトにその予防線を1〜2行入れておくと、次の人はほぼノーストレスで進めます。

━━━━━━━━━━━━━━━━━━━━━━━━

必要なら、もっと短い箇条書き版や、逆に各課題ごとに分けた詳細版にもできます。

Claude Codeをはじめる（課題1-1〜1-4）やってみたフィードバック

■ 前提：どこで何を動かしているのかを最初に掴む 次にやる人へ最初に伝えたいのは、「Claude Code」と「claude.ai のチャット」は別物だ、ということ。この区別が曖昧なまま進むと、後半の課題で必ず消化不良を起こす。

今回の課題は主にチャット側で進めた。チャットは「HTMLやReactのコードを書く」「その場でプレビューする」「デザイン仕様書を作る」といった“手元で完結する制作”は非常に得意。一方で、DESIGN.md をリポジトリに置いてセクション単位で実装を回す、といった一連の作業フローは、本来 Claude Code（ターミナルやデスクトップで動くエージェント）側の役割。さらに言えば、WordPressへ実際に記事を入稿する・本番サーバーへ反映する、といった「自分の環境の外側に書き込む」作業は、チャットにもClaude Codeにも代行はできず、最終的に自分の手で管理画面を操作する必要がある。

この三層——「①手元でコードやプレビューを作る」「②ファイルとして書き出し実装フローを回す」「③自分の本番環境へ反映する」——のどこを今やっているのかを意識するだけで、「作れたのに反映されない」という戸惑いの大半は消える。

■ ① やった課題

課題1-1：HTMLでオリジナルのシューティングゲームを作る 用意したプロンプトをそのまま投げるだけで、ブラウザで動くゲームが完成した。こちらから少し手を加えることもでき、4つの課題の中で最もスムーズだった。制作物がその場で動くので、達成感が明確に得られる。

課題1-2：医療系SEOサイトのHPデザイン（白ベース・文字大きめ） DESIGN.md（デザイン仕様書）を作る → 美学プロンプトを適用する → セクション単位で実装する、という流れで進めた。配色・文字サイズ・余白の仕様と、写真入りのトップページのイメージまでは出てきた。ここまでは概ね想定どおり。

課題1-3：上記に画像を入れてWordPressに投稿できるよう指示 「WordPressに入稿できる形にして」という指示自体は出せた。しかし、実際にWordPressへ入れていないため動作チェックができておらず、画像も最終的にどう表示されるのか分からないまま。4つの中でここが最もモヤモヤが残った。詳しくは②で深掘りする。

課題1-4：サイトの裏側の管理システムのモック作成 予約・患者管理システムのモックは、実際に操作できる形で出てきた。ただ「これが何のためにあるのか」が自分の中で腑に落ちず、受け取ったものの使い道を描けなかった。

■ ② 想定外だったこと

【スムーズだった所：1-1が良い入口になる】 シューティングゲーム（1-1）は、プロンプトを盛らなくても勝手に作り込んでくれて、完成物がその場でブラウザで動く。「作って → 動く → 自分でいじる」が一周する体験は、後続の課題に取り組むうえでの自信と土台になる。最初の一歩として、まずこれをやり切るのを強くおすすめしたい。ここで「チャットは手元で完結する制作が得意」という感覚を掴んでおくと、1-3で環境の壁にぶつかったときにも「これはチャットの外側の話だ」と切り分けやすくなる。

【詰まった所：1-3の入稿まわりを深掘りする】 今回いちばんの引っかかりが1-3なので、ここを重点的に分解する。

●なぜ入稿でつまずくのか（構造の問題） つまずきの本質は、能力不足ではなく「境界の見えにくさ」にある。チャットが出せるのは、WordPressの「テーマファイル」や「入稿用の手順・マークアップ」まで。そこから先の「WordPressの管理画面にログインして、テーマを適用し、記事や画像をアップロードして、公開ボタンを押す」という工程は、自分の環境で自分が操作しないと完了しない。ところが指示を出す側は「WordPressに投稿できるようにして」と頼んだ時点で、投稿まで含めて片が付くように錯覚しやすい。ここに期待と現実のズレが生まれる。

つまり、チャットの成果物は「入稿の一歩手前で止まっている完成品」であって、壊れているわけでも中途半端なわけでもない。にもかかわらず、自分の管理画面で結果を確認できないので、「本当にこれで合っているのか」を検証する手立てがなく、宙ぶらりんな感覚だけが残る。これが1-3のモヤモヤの正体だった。

●画像が「どうなっているか分からない」問題 プレビュー内の写真がダミー(ネット上の仮画像やプレースホルダの枠)で表示されていて、本番でどの画像がどこにどう出るのかが見えなかった。最初は「画像が壊れている／うまく入っていない」と感じたが、実はこれには理由がある。医療系サイトでは、拾ってきた写真やAI生成の人物画像を、あたかも実在の院長やスタッフであるかのように載せると、医療広告のルールや、サイトの信頼性(専門性・信頼性が重視される領域)の両面で問題になる。だからこそ、あえて実写を入れず「後で差し替える前提の枠」として仮置きにしてある。

この背景を先に知っていれば、「壊れている」ではなく「差し替え待ちの正しい状態」だと受け止められた。次の人には、画像は自分で用意した実写に後から差し替えるものであって、今表示されているのは位置とサイズを決めるための仮置きだ、と最初に理解しておくことを勧めたい。

●1-3を乗り越えるための具体的な手順(次の人向け) ・まず「入稿は自分の作業、ツールがくれるのは素材と手順」と割り切る。ここを期待しすぎないだけで精神的にかなり楽になる。 ・成果物を受け取ったら、いきなりWordPressに入れようとせず、チャット上のプレビューで見た目とレイアウトを先に確定させる。 ・そのうえで「WordPressのどの方式で入れるか」を決める。固定ページに直接HTMLを貼るのか、オリジナルテーマとして設置するのかで手順が丸ごと変わるので、これを頼む前に自分で決めておくと指示がぶれない。 ・画像は、本番で使う実写を先に手元に用意しておき、「この枠にはこの画像を入れる」という対応を自分で決めてから差し替える。 ・入稿後にレイアウトが崩れたら、その崩れた状態のスクリーンショットや、実際に貼ったコードを添えて相談すると、原因の切り分けが一気に進む。「なんか変」ではなく「ここがこう崩れた」を持ち込むのがコツ。

【分かりにくかった所：1-4のモックの目的】 「裏側の管理システム」がなぜ必要なのか説明されないまま完成物だけが出てきたので、受け取った側が使い道を描けなかった。モックというのは、本番を作り始める前に、画面の見た目と操作の流れを“動く絵”で確認して、方向性を合意するためのもの。いわば「動く企画書」であって、それ自体が本番システムなのではない。この一言の説明があるだけで、受け取り方はまるで変わったはず。次の人には、モックを頼む前に「これは何を確認するためのモックなのか」を自分の言葉で一度言語化しておくことを勧めたい。目的が言語化できないなら、それはまだ頼むタイミングが早い、というサインでもある。

【プロンプトの書き方：呪文化の落とし穴】 CC(goal/Mon/batch/Plan/Hook/Rule/…) のように略語を大量に詰め込んだ指示は、一見プロっぽく見えるが、略語の意味がツール側と自分の間でズレると空回りする。実際、この記法で指定した運用フロー(バッチ処理や、危険な操作の前のチェックポイント、タスク分割など)は、チャット側ではそのままの形では実行されず、「素材を作る作業」に読み替えられていた。凝った記法そのものが成果を上げてくれるわけではない、というのは覚えておいて損がない。

■ ③ 最初のコピペ用プロンプトへの改善案

＜元のプロンプト＞ CC(goal/Mon/batch/Plan/Hook/Rule/Skill/Flow/allow/Mem/sec/task/Team/rw/rev=cr+sr/Ultra)最適選択→batch/Flow FO→待Mon・危険前ckpt→rev+規模次第A2A→選定/理由/結果/check/要約報告 次の流れでHPデザインを行って 1:DESIGN.md作成 2:Claude Cookbookの美学プロンプトを適用 3:Claude Codeでセクション単位に実行 白ベース,文字大きめ [医療系SEOの雄]

＜改善案(このままコピペ可)＞ 医療系クリニックの公式サイトを作りたい。以下の条件でお願いします。

【サイトの主体】クリニック公式サイト(医療・専門性と信頼性が重視される領域) 【最終形】WordPressテーマとして使える形(まずはHTML/CSSのプレビューでもOK) 【デザイン】白ベース、文字大きめ、アクセント色はおまかせで提案して 【進め方】

まず DESIGN.md(配色・文字サイズ・余白などの仕様書)を作る

その仕様に沿って、トップページをセクション単位で作る

各段階の最後に「何を・なぜそうしたか・私が次にやること」を短くまとめて

【私の環境と前提】 ・WordPressへの入稿は私が自分で行います。あなたは入稿用の素材と手順まででOK ・入稿方式は(固定ページに貼る／オリジナルテーマとして設置)のうち◯◯で考えています ・画像は後で自分の実写に差し替えます。今は位置決め用の仮枠でよい ・専門用語や略語は使わず、普通の日本語で説明してください

＜改善のポイント(次の人向けメモ)＞ ・「最終形は何で、どこまでを相手にやってほしいか」を冒頭に書く。これが抜けると1-3のような「作れたのに反映できない」ズレが起きる。 ・「自分でやる作業」と「ツールに任せる作業」の境界を最初に宣言する。WordPress入稿・独自ドメイン・本番公開は原則すべて自分側の作業だと考えておく。 ・入稿方式(固定ページかテーマか)を先に決めて書いておくと、手順の指示が最後までぶれない。 ・画像は「後で差し替える前提の仮枠でいい」と先に言っておくと、ダミー画像に動揺せずに済む。 ・略語や記号の羅列は避け、①やりたいこと ②出力形式 ③確認したいこと の3点を日本語で書く。凝った記法より結果が安定する。 ・モックや裏側システムを頼むときは「これは何を確認するためのものか」を一文添える。目的を言語化できないものは、まだ頼む段階ではない。

■ 総評(次にやる人へ) 1-1のゲームは「投げれば動く」楽しさで自信がつく、間違いなく良い入口。つまずくのは1-3以降で、原因はほぼ一点、「作れること」と「自分の環境に反映すること」の境界が見えにくいことに尽きる。特に1-3の入稿は、成果物が“入稿の一歩手前で正しく止まっている”状態だと理解し、そこから先は自分の管理画面での作業だと割り切れるかどうかで、体験の滑らかさが大きく変わる。最初のプロンプトで「最終形・自分の担当・確認したいこと」の3点を書いておく——これだけで、次の人の詰まりはかなり減らせるはず。

以下、そのままコピペできるフィードバックです。（全体約2,900字）

```

【Claude Codeをはじめる 課題1-1〜1-4 やってみた感想／次の人へのフィードバック】

━━━━━━━━━━━━━━━━━━━━━━

① やった課題（実際に作ったもの）

━━━━━━━━━━━━━━━━━━━━━━

1-1：HTMLでオリジナルのシューティングゲームを作成 → ブラウザで起動

　　→ 単一HTMLファイルにゲームが1本完成。自機・敵・ボス・スコアまで動いた。

1-2：架空のお店のホームページを設計〜実装

　　→ 先に「DESIGN.md（設計書）」を作り、その方針に沿ってセクションごとに実装。

　　　「白ベース・文字大きめ」を指定。

1-3：1-2のサイトの雰囲気変更

　　→ カラーとフォントを差し替えて「高級スイーツ店」風にトーンチェンジ。

1-4：そのお店の“裏側システム”を作成

　　→ 予約管理・スコアリング・承認フローなどの業務ツールを1画面で作成。

　　　仕様（タブ数・保存方法など）を細かく指定して作ってもらった。

全体を通して「作る→見る→直す→発展させる」の流れを1本で体験できる構成でした。

━━━━━━━━━━━━━━━━━━━━━━

② 想定外だったこと

━━━━━━━━━━━━━━━━━━━━━━

▼詰まった・戸惑ったところ

• プロンプトに専門用語や略語を詰め込むと、意図が伝わりきらない場面があった。

　例）「A2A」「STORE_KEY昇格」「3層振分」など。

　→ 略語は“動くもの”には反映されるが、自分が後で見返すと意味が分からなくなる。

　　結果物は良くても「自分が何を頼んだか」を説明できないのはモヤっとした。

• 「完成したらブラウザで開いて」は、環境によっては自動で開かないことがある。

　→ ファイルのフルパスが返ってくるので、それをダブルクリックで開けばOKだった。

• 作り直し（1-3）のとき、どこまで変わるのか最初は不安だった。

　→ 実際は「色とフォントだけ」など範囲を言えば、そこだけ的確に直してくれた。

▼分かりにくかった言葉

• 「仕様駆動」「MVP」「Lv3」…最初はレベル分けの基準が曖昧に感じた。
• 「モーダル（confirm禁止）」…UIを知らないと何を禁止しているのか伝わりにくい。
• 記号の羅列（🤖pt など）…雰囲気は伝わるが、初回は解読に頭を使った。

▼逆にスムーズだったところ

• 「作って」だけでも、名前・世界観・配色まで具体案を出して形にしてくれる。
• DESIGN.md を先に作る流れは、頭の中の“ふわっとした要望”が整理されて良かった。
• 修正指示が一言（例：「高級感のある雰囲気に」）でも、狙い通りに変わった。
• 日本語のまま、専門知識ゼロでも最後まで進められた。

━━━━━━━━━━━━━━━━━━━━━━

③ 最初のコピペ用プロンプトへの改善案

━━━━━━━━━━━━━━━━━━━━━━

「最初のプロンプトはもっと“素直な日本語”でよい」というのが結論です。

略語や記号は無理に使わず、次の型に沿うだけで十分伝わりました。

●おすすめテンプレ（初回はこれで十分）

　―――――――――――――――――

　【作りたいもの】〇〇（例：架空のカフェのホームページ）

　【目的・使う人】〇〇（例：お店の集客／自分の練習）

　【必ず入れたい要素】〇〇（例：メニュー・アクセス・白基調・文字大きめ）

　【雰囲気】〇〇（例：かわいい／高級／シンプル）

　【完成後】ファイルの場所（フルパス）も教えて。開き方も一言添えて。

　―――――――――――――――――

●具体的な改善ポイント

1. 略語は「（＝説明）」を必ず添える。

　例：「A2A（＝複数のAIで分担）」のように。使わないなら消してよい。

2. “こだわり条件”は箇条書きで分ける。

　1行に詰め込むより、1条件1行のほうが抜け漏れなく反映された。

3. レベルや仕様の指定は「初回は無し」でOK。

　まず普通に作ってもらい、できたものを見てから「ここを直して」の方が早い。

4. 「わからない言葉は説明して」と一文入れておくと安心。

　専門用語で返されても、その場で噛み砕いてくれる。

5. 最初に“ゴールの一言”を書く。

　例：「触って楽しいゲーム」「一目で高級だと分かるサイト」。

　これがあると細かい指定がなくても方向がぶれない。

━━━━━━━━━━━━━━━━━━━━━━

ひとことまとめ

━━━━━━━━━━━━━━━━━━━━━━

• 身構えなくて大丈夫。「日本語で普通にお願いする」だけで最後まで作れます。
• カッコいい略語より、“何を・誰のために・どんな雰囲気で”の3点を素直に。
• まず作る→見て直す、が一番ラク。完璧な指示を最初に書こうとしないこと。

「Claude Codeをはじめる（課題1-1〜1-4）」やってみた感想フィードバック

次にやる人へ。実際に一通り走らせてみて「ここは事前に知っておきたかった」という点を、正直ベースでまとめました。全体的には想像よりずっとスムーズでしたが、いくつか詰まりポイントがあります。

① やった課題（実際の流れ）

課題1-1／環境と最初のホームページ：観光ポータルサイト（酒田さんぽ）を1枚のHTMLで作成。デザイン方針を DESIGN.md に先に書き出してから実装、という順番が効いた。

課題1-2／デザインの言語化：色・タイポ・余白・レスポンシブをトークン（CSS変数）として定義。「なんとなく綺麗」ではなく理由づきで指定すると、出力がブレない。

課題1-3／裏側システムの構築：ホームページの運用管理コンソール（5タブの管理画面）を、圧縮した仕様プロンプト1行から生成。承認ワークフロー・品質スコアリング・AIアシスタントまで一気に出た。

課題1-4／成果物の出力と確認：構成図PNGと動くHTMLを書き出し、ブラウザで開いて実際に触って確認。localStorageにサンプルデータが入り、その場でクリック操作できる状態まで持っていけた。

所要感覚：手を動かす時間より「何を作るか言葉にする時間」の方が長い。それが正しい使い方だと途中で気づきました。

② 想定外だったこと

◇ 詰まった所

圧縮プロンプトの用語が独自すぎて最初は自分でも意味を見失う。各画面🤖pt STORE_KEY昇格 中規模A2A→open(フルパス+説明) などの略語は、書いた本人（＝自分）以外はもちろん、後から見た自分も解読が必要。AI側は文脈から補完してくれたが、意図と違う解釈で作られるリスクがあった。

図解PNGで日本語の絵文字が豆腐（□）になる。Windowsの標準日本語フォントはカラー絵文字を持っていないため、🤖や🗂️がそのまま四角化。テキストラベルに置き換えて解決したが、最初のPNGは見栄えが悪かった。→ 図はアイコンより文字ラベルの方が安全。

フォルダ名とサイト内容の不一致。作業フォルダは「ユニコスクール」なのに中身は観光サイト。後から見返すと混乱するので、フォルダ名＝プロジェクト名で揃えるべきだった。

PowerShell環境特有の作法。パス・エンコーディング・改行の扱いがbash前提の記事と違い、コマンドをそのまま貼ると滑ることがある。環境がWindowsかMacかで最初に一言宣言しておくと事故が減る。

◇ 分かりにくかった言葉

「仕様駆動MVP=level3」：レベルの定義（1〜3が何を指すか）がどこにも無く、粒度が伝わりにくい。「動くところまで／どこまで作り込むか」を数値でなく一文で書いた方が伝わる。

「承認段階ゲート引継型」：正しく実装されたが、初見では「段階ゲート」と「引継」が別概念か一体かが曖昧。

「3層振分」：何を3層に分けるのか（品質を3ランクに、の意）が前提知識なしだと読めない。

◇ 逆にスムーズだった所

1行の圧縮仕様でも、破綻せず全機能が生成されたのは驚き。tab数・スコアの満点・サンプル件数など数値を明示した部分は特に正確に反映された。

「confirm禁止・モーダルで」のような"やらないで"指定がちゃんと効く。制約を書くほど品質が上がる体感。

先に DESIGN.md を書いておくと、裏側システムが自動で同じ配色・フォントを継承してくれた。デザインの一貫性がタダで手に入る。

生成後すぐブラウザで開いて触れるので、「動くか」の確認が速い。スクショ往復より実物クリックが早い。

③ 最初のコピペ用プロンプトへの具体的な改善案

元の圧縮プロンプト（例）：

仕様駆動MVP=level3。out:図解PNG+動くHTML単一(localStorage/JP/白)・5tab・

100点+3層振分・sample5-15・各画面🤖pt・承認段階ゲート引継型・

モーダル(confirm禁止)・STORE_KEY昇格・中規模A2A→open(フルパス+説明)

短くて強力だが、次の人がそのまま使うには解読コストが高い。以下を推奨します。

改善案1：冒頭に「環境・前提」の1行を足す

【環境】Windows / PowerShell / 単一HTMLで完結 / 外部連携なしのモック

→ コマンドの滑りとフォント豆腐化を先回りで防げる。

改善案2：独自略語に必ず1回だけ定義を添える

• 各画面🤖pt = 各タブにAI呼び出しボタンを配置（実行ログに記録）
• STORE_KEY昇格 = localStorageのキーをvUpし旧バージョンから移行
• 3層振分 = 100点満点をA(80+)/B(60-79)/C(-59)にランク分け
• A2A→open = エージェント連携図、各ノードのopenでフルパス＋説明表示

→ AIの解釈ブレが消え、レビュー時に自分でも読める。

改善案3：「レベル」を数値でなく成果物の状態で書く

（悪い）level3

（良い）クリックで状態が変わり保存される・見せられる完成度のモック

改善案4：図（PNG）は「絵文字を使わずテキストラベルで」と明記

→ Windowsでの豆腐化を回避。地味だが効く。

改善案5：出力後に「ブラウザで開いて」を明示

→ 確認までワンストップになり、往復が減る。

総括：圧縮プロンプトは"書ける人には最強・読む人には難読"。次にやる人は、略語に一言ずつ注釈を足すだけで、詰まりの8割は消えます。あとは環境（Windows/PowerShell）とフォント（絵文字は文字に）の2点さえ押さえれば、驚くほど気持ちよく完走できます。

■ Claude Codeをはじめる（課題1-1〜1-4）やってみた感想 ─ 次にやる人へのフィードバック

【まず結論（30秒で読む用）】

• Claude Codeは「作る」のはめちゃ速い。詰まるのは"環境"と"呪文みたいなプロンプト"の2か所だけ。
• 最初のコピペ用プロンプトは、略語を減らして「ゴール1行＋制約3つ＋成果物の形」を平文で書くと一気にスムーズになる。
• 迷ったら「白ベース・文字大きめ」みたいな"具体的な縛り"を足すと、出力が安定する。

━━━━━━━━━━━━━━━━━━

① やった課題

━━━━━━━━━━━━━━━━━━

1-1｜環境確認と最初のプロンプト投入

• 作業フォルダを開き、最初のコピペ用プロンプトを貼って動かす。

1-2｜HP（ホームページ）のデザイン

• 「DESIGN.md（設計書）を作る → 美学プロンプトを当てる → セクション単位で実装」の3ステップ。
• 題材は「紹介でしか会えない相続・事業承継コンサル」。白ベース・文字大きめ指定。

1-3｜HPの裏側システム（社内ツール）の作成

• 面談申込を100点で採点し、S/A/Bの3層に自動振分け、承認ゲート付きで進行管理するCRMを1枚のHTMLで作成。

1-4｜振り返り（今これ）

• やった感想を、次の人向けフィードバックにまとめる。

━━━━━━━━━━━━━━━━━━

② 想定外だったこと

━━━━━━━━━━━━━━━━━━

◆ 詰まった所

• 【最大の壁】最初のプロンプトが"呪文"。

　例：「CC(goal/Mon/batch/Plan/Hook…)最適選択→batch/Flow FO→…」「仕様駆動MVP=level3」「STORE_KEY昇格」「中規模A2A」など。

　→ 何を頼んでいるのか初見では読めない。しかも実際に作るのは"1枚のHTML"なので、並んでいるオプションの大半は使わなかった。盛りすぎ注意。

• 【環境依存】ローカルのプレビュー用サーバ起動が失敗した。

　→ PC内にPython/Node（サーバを立てる道具）が入っておらず、コマンドが空振り。

　→ 回避策は簡単で「HTMLファイルをブラウザで直接開く」だけでOKだった。作ったものが静的HTML1枚なら、そもそもサーバは要らない。

◆ 分かりにくかった言葉

• 「A2A」「Flow FO（ファンアウト）」「ckpt（チェックポイント）」…略語が説明なしで登場。
• 「STORE_KEY昇格」…要は"保存の入口を1個の合言葉（キー）に統一する"という意味。言葉だけだと難しく見える。
• 「3層振分」「承認ゲート」「引継型」…概念自体は良いが、初見だと具体像が湧きにくい。→ 実物を見ると一発で腹落ちする（＝先にサンプルを見せてほしい）。

◆ 逆にスムーズだった所

• 「DESIGN.md → 美学適用 → セクション単位」の3分割は最高。工程が見えるのでClaudeが迷わず、途中確認もしやすい。
• 「白ベース・文字大きめ」のような"具体的な縛り"は効果絶大。抽象的な「おしゃれに」より圧倒的にブレない。
• 「サンプル5〜15件」「日本語」「単一HTML」など、数字・形式で指定した部分はそのまま反映され、手戻りゼロ。
• 作る速度そのものは驚くほど速い。設計書もCRMも一気に出てくる。

━━━━━━━━━━━━━━━━━━

③ 最初のコピペ用プロンプトへの改善案（具体的に）

━━━━━━━━━━━━━━━━━━

【改善の方針】

"全機能を呪文で盛る"のをやめて、"平文で最小限"にする。略語は初出で一言そえるか、消す。

▼ Before（つまずきやすい書き方）

　CC(goal/Mon/batch/Plan/Hook/Rule/Skill/Flow/allow/Mem/sec/task/Team/rw/rev)最適選択→batch/Flow FO→待Mon・危険前ckpt→…（略語の羅列）

▼ After（おすすめテンプレ／これをコピペ土台に）

　─────────────────

　【ゴール】○○を作りたい（1行で）。

　【成果物の形】単一HTMLファイル1枚／保存はブラウザ内（localStorage）／サービス連携は無し（まずはモックで見た目重視）。

　【制約3つ】①日本語 ②白ベース・文字大きめ ③サンプルデータは○件入れる。

　【進め方】1)設計メモ(DESIGN.md)→2)方針の確認→3)セクション単位で実装、の順で。危険な操作の前は一度止めて確認して。

　【環境メモ】このPCにはサーバを立てる道具(Python/Node)が無い場合があるので、完成物はブラウザで直接開ける形にして。

　【完成後】ブラウザで開いて見せて。

　─────────────────

【個別の改善ポイント】

1. 略語は封印 or 注釈。

• 「A2A＝別のAIエージェントに手分け」「ckpt＝危険操作前に一旦止める」など、使うなら初出で一言。使わないなら消す（今回は単一HTMLなので大半不要だった）。

2. 環境前提を"最初の1行"に書く。

• 「サーバは立てず、HTML単体で開ける形で」と先に言えば、プレビュー失敗の回り道が消える。

3. 曖昧語を数字に。

• 「sample5-15」より「サンプルは10件ちょうど」等、幅ではなく確定値の方が仕上がりが読める。

4. "先に完成イメージ1枚"をお願いする。

• 「まず全体像の図（1枚）を出してから作って」と頼むと、認識ズレが着手前に潰せる。今回も図が出た瞬間に理解が進んだ。

5. 「凄いと思える業務ツールにして」は有効なので残す。

• ただし"何が凄いか"を1個だけ具体化するとさらに刺さる。例：「紹介元の格が高いほど自動で最優先に振り分く、が一目で分かるように」。

━━━━━━━━━━━━━━━━━━

■ 次にやる人へ・ひとこと

━━━━━━━━━━━━━━━━━━

• プロンプトは"かっこいい呪文"を目指さない。「何を・どんな形で・どんな縛りで」を普通の日本語で書くのが結局いちばん速い。
• 手が止まったら、まず「これはサーバ要る作業？ブラウザで開くだけで済む？」を確認。多くは後者。
• 工程を3つに割って、途中で一度見せてもらう。これだけで手戻りが激減します。

• --

（参考：本文 約2,900字。6000字以内におさめています。）

裏側システム 「MERIDIAN OPS CONSOLE（運用管理コンソール）」 を構築し、ブラウザで開きました🚀

📦 成果物

• ops-console.html — 動くHTML単一（localStorage / 日本語 / 白基調）
• システム構成図 — アプリ内「概況」タブに内蔵、🖼️ PNG保存ボタンで書き出し可能

🗂️ 5タブ構成（各画面に🤖AIアシスト搭載）

| タブ | 機能 |

|---|---|

| 📊 概況ダッシュボード | KPI・システム構成図・健全性ゲージ・本日のタスク |

| 🔌 データ品質 | 外部フィードを100点で自動採点＋3層振分（良好/注意/要対応）、再取得でスコア回復 |

| ✅ 承認ワークフロー | 起票→レビュー→承認→公開の段階ゲート（引継型） |

| 🗓️ イベント運用 | 経済イベントのCRUD・公開反映 |

| 📜 監査ログ | 全操作をタイムライン記録 |

⭐ 仕様の実装ポイント

• 100点＋3層振分: 稼働率40%・遅延20%・鮮度20%・エラー率20%の加重で自動採点 → 80/60で3層色分け＋ゲージ表示
• 承認段階ゲート・引継型: 工程スキップ不可。「進める」と担当が記者→デスク→編集長→配信に引き継がれ、モーダルで確認＋監査記録。差し戻しも可能
• モーダル（confirm禁止）: `confirm()`不使用、Promiseベースの自作モーダルで全確認を実装
• STORE_KEY昇格: `MERIDIAN_OPS_V3`。旧キー(`V2/V1/meridian_ops`)を検出したら自動移行→旧キー削除、スキーマ版数チェックも実装
• sample 5-15件: フィード8・承認9・イベント10件
• 🤖各画面AI: 画面ごとに運用データを解析した提案を表示（モック）

✨ 「凄い」ポイント

• KPIカード＋SVGゲージ＋レイヤー化アーキ図でSaaS管理画面級のUI
• 「再取得」でスコアが実際に回復、承認を進めると担当が入れ替わる — 触って動く
• トースト通知・サイドバー通知バッジ・ESC/背景クリックで閉じるモーダル

サービス連携は行わず全てモック（フッター注記あり）。次は「フロント↔この裏側のデータ連動」や「ユーザー権限別ビュー」なども足せます。どこか磨きますか？

Claude Codeをはじめる（課題1-1〜1-4）やってみた感想・次の人へのフィードバック ━━━━━━━━…

■① やった課題（何を作ったか）

• 課題1-1：HTMLでシューティングゲームを作成 → ブラウザで表示 →「凄いと思うものを」くらいのざっくり指示でも、パーティクル・敵5種・ボス戦まで一気に出てきた。1ファイル完結なので確認がラク。
• 課題1-2：お店のHP（ランディングページ）を制作 →「DESIGN.md を先に作る」「Cookbookの美学プロンプトを当てる」「白ベース・文字大きめ」という手順・制約つきで依頼。仕様書→実装の流れが体験できる回。
• 課題1-3：そのHPの“裏側システム”を仕様駆動MVPで制作 →5タブの管理画面（スコアリング・在庫・SNS・承認フロー）＋構成図PNG。「100点で採点」「モーダルはconfirm禁止」など細かい仕様を詰め込んだ回。
• 課題1-4：この振り返りフィードバックづくり →出力形式（テキスト・字数・コピペ可）を指定して、成果物ではなく“文章”を出させる回。

全体を通して「作る→ブラウザで開く→直す」のループを4周する構成。手を動かす量が多く、達成感は大きい。

■② 想定外だったこと（詰まった所・言葉・スムーズだった所）

＜詰まった／注意したい所＞ ・日本語まわりの文字化け：日本語を含むスクリプト（.ps1）やファイル名は、環境の文字コード次第で一発で通らずリトライが入ることがある。「なぜか失敗した」ように見えても、たいていは中身ではなく“文字コード”の問題。ここは焦らなくてよい。 ・HTML以外の出力（画像PNGなど）は一発で決まりにくい：テキストやHTMLはすぐ出るが、画像生成のような処理は途中でエラー→自動修正→再実行、が入る。時間に余裕をもつと安心。 ・「仕様を細かく指定する」と“指定漏れ”が起きやすい：confirm禁止・字数制限・白ベースなど条件を増やすほど精度は上がるが、条件が多いと1つ抜けることもある。完成後に「指定した条件、全部入ってる？」と一度チェックさせるとよい。 ・成果物の置き場所：作られたファイルがどこに保存されたか、最初は分かりにくい。「フルパスで教えて」と頼むと迷子にならない。

＜分かりにくかった言葉＞ ・課題で出てくる略語・カタカナが多い：MVP／モック／localStorage／モーダル／マイグレーションなど。意味が曖昧なまま進むと「何を作られたのか」が分からなくなる。知らない単語は、その場で「◯◯って何？一言で」と聞けば止まらずに進める。 ・「仕様駆動」「美学プロンプト」あたりは雰囲気で流しがち。要は“先に決めごと（設計書）を作ってから実装する”というだけ、と理解すればOK。

＜逆にスムーズだった所＞ ・ふわっとした依頼でも形になる：「凄いと思うものを」でも十分に動くものが出る。最初はガチガチに指定しなくてよい。 ・修正指示が通りやすい：「文字を大きく」「白ベースで」など後出しの注文にも素直に直る。完璧な初回プロンプトを目指さず、対話で寄せていくのが正解。 ・ブラウザで即確認できる爽快感：作った瞬間に動くものが見えるので、モチベが続く。

■③ 最初のコピペ用プロンプトへの具体的な改善案

課題で配られる“最初のコピペ用プロンプト”は、略語が詰め込まれていて（例：batch/FO/A2A/ckpt/rev=cr+sr など）、初学者にはほぼ暗号。AIは解釈できても、人間が「自分が何を頼んでいるか」を理解できないのが

コピペで使えるテキストです。

━━━━━━━━… Claude Codeをはじめる（課題1-1〜1-4）やってみた感想・次の人へのフィードバック ━━━━━━━━…

■① やった課題（何を作ったか）

• 課題1-1：HTMLでシューティングゲームを作成 → ブラウザで表示 →「凄いと思うものを」くらいのざっくり指示でも、パーティクル・敵5種・ボス戦まで一気に出てきた。1ファイル完結なので確認がラク。
• 課題1-2：お店のHP（ランディングページ）を制作 →「DESIGN.md を先に作る」「Cookbookの美学プロンプトを当てる」「白ベース・文字大きめ」という手順・制約つきで依頼。仕様書→実装の流れが体験できる回。
• 課題1-3：そのHPの“裏側システム”を仕様駆動MVPで制作 →5タブの管理画面（スコアリング・在庫・SNS・承認フロー）＋構成図PNG。「100点で採点」「モーダルはconfirm禁止」など細かい仕様を詰め込んだ回。
• 課題1-4：この振り返りフィードバックづくり →出力形式（テキスト・字数・コピペ可）を指定して、成果物ではなく“文章”を出させる回。

全体を通して「作る→ブラウザで開く→直す」のループを4周する構成。手を動かす量が多く、達成感は大きい。

■② 想定外だったこと（詰まった所・言葉・スムーズだった所）

＜詰まった／注意したい所＞ ・日本語まわりの文字化け：日本語を含むスクリプト（.ps1）やファイル名は、環境の文字コード次第で一発で通らずリトライが入ることがある。「なぜか失敗した」ように見えても、たいていは中身ではなく“文字コード”の問題。ここは焦らなくてよい。 ・HTML以外の出力（画像PNGなど）は一発で決まりにくい：テキストやHTMLはすぐ出るが、画像生成のような処理は途中でエラー→自動修正→再実行、が入る。時間に余裕をもつと安心。 ・「仕様を細かく指定する」と“指定漏れ”が起きやすい：confirm禁止・字数制限・白ベースなど条件を増やすほど精度は上がるが、条件が多いと1つ抜けることもある。完成後に「指定した条件、全部入ってる？」と一度チェックさせるとよい。 ・成果物の置き場所：作られたファイルがどこに保存されたか、最初は分かりにくい。「フルパスで教えて」と頼むと迷子にならない。

＜分かりにくかった言葉＞ ・課題で出てくる略語・カタカナが多い：MVP／モック／localStorage／モーダル／マイグレーションなど。意味が曖昧なまま進むと「何を作られたのか」が分からなくなる。知らない単語は、その場で「◯◯って何？一言で」と聞けば止まらずに進める。 ・「仕様駆動」「美学プロンプト」あたりは雰囲気で流しがち。要は“先に決めごと（設計書）を作ってから実装する”というだけ、と理解すればOK。

＜逆にスムーズだった所＞ ・ふわっとした依頼でも形になる：「凄いと思うものを」でも十分に動くものが出る。最初はガチガチに指定しなくてよい。 ・修正指示が通りやすい：「文字を大きく」「白ベースで」など後出しの注文にも素直に直る。完璧な初回プロンプトを目指さず、対話で寄せていくのが正解。 ・ブラウザで即確認できる爽快感：作った瞬間に動くものが見えるので、モチベが続く。

■③ 最初のコピペ用プロンプトへの具体的な改善案

課題で配られる“最初のコピペ用プロンプト”は、略語が詰め込まれていて（例：batch/FO/A2A/ckpt/rev=cr+sr など）、初学者にはほぼ暗号。AIは解釈できても、人間が「自分が何を頼んでいるか」を理解できないのが最大の壁だった。改善案は以下。

略語には初回だけ日本語の注釈を添える 例：「FO（＝作業を分けて並行処理）」「A2A（＝別の担当AIに振る）」のように、初出だけ( )で意味を書く。次の人がコピペしても“意味が分かる”状態にする。

「作ってほしいもの」と「進め方の指示」を分ける 現状は目的と手順が1行に混ざっていて読みにくい。 【作るもの】→【守る条件】→【進め方】→【最後にやること（報告・確認）】の4ブロックに改行で区切ると、抜け漏れも減る。

完成条件（Doneの定義）を1行入れる 例：「完成＝ブラウザで開けて／指定条件を全部満たし／保存先パスを報告した状態」。これがあると「終わったつもり」のズレが消える。

「知らない用語は先に説明してから進めて」を一文入れる 初学者ほど効く。専門用語の置き去りを防げる。

＜書き換え例（このままコピペ可）＞ ──────── 【作るもの】○○（例：スイーツ店のHP）を1ファイルのHTMLで。 【守る条件】白ベース／文字大きめ／外部連携なし（イメージ確認用のモック）。 【進め方】(1)先に設計メモ(DESIGN.md)を作る (2)セクションごとに実装 (3)独立作業はまとめて並行処理。専門用語を使うときは初回だけ一言で説明して。 【最後に】完成したらブラウザで開き、保存先をフルパスで教えて。指定条件を全部満たしているかを自分でチェックして報告して。 ────────

■ まとめ（次の人への一言） ・完璧なプロンプトを1回で書こうとしないこと。ざっくり頼んで、見て、直す。この対話が本体。 ・知らない言葉は必ずその場で聞く。放置すると成果物の意味が分からなくなる。 ・日本語の文字化け・画像出力・保存場所の3つだけ、詰まりやすいポイントとして頭の隅に置いておけば、あとは楽しく進められる。

━━━━━━━━…

【Claude Codeをはじめる 課題1-1〜1-4 やってみた感想／次にやる人へのフィードバック】

■① やった課題（何を作ったか）

• 課題1-1：HTMLでオリジナルのシューティングゲームを作成し、そのままブラウザで起動。
• 課題1-2：地域のボート屋さん想定のホームページ制作。DESIGN.md（設計書）を先に作って

デザインの方向性を決めてから、セクション単位で実装。

• 課題1-3：そのHPの「裏側」の業務管理システム（問い合わせ→スコアリング→商談→整備引継

→顧客管理）を、動くサンプル（MVP）として作成。システム構成の図解PNGも同時生成。

• 課題1-4：完成物をサーバーに上げたら動くのか？を質問し、「静的ファイルの表示」と

「データの保存・共有」の違いを理解。

全体を通して、「作って」と頼むと数十秒〜数分で動くものが出てきて、最後に自動で

ブラウザが開く、という一連の流れを体験できた。

■② 想定外だったこと

〈スムーズだった所〉

• 「作って」だけで、ゲームもHPも一発で“動く形”で出てくる。細かい仕様を書かなくても

それっぽく仕上がるのが気持ちいい。

• 完成後に自動でブラウザが開く。自分でファイルを探して開く手間がない。
• 複数の作業を並列で進めてくれるので待ち時間が短い。

〈詰まった所・分かりにくかった所〉

• コピペ用プロンプトの略語が多すぎて意味が分からなかった。

例：A2A ／ Flow ／ Monitor ／ ckpt ／ MVP=level3 ／ 3層振分 ／ 承認段階ゲート引継型 ／

STORE_KEY昇格 ／ モーダル(confirm禁止) など。動く物は出るが、「自分が何を指示したのか」

を理解できないまま進んでしまう不安があった。

• 「localStorage（ブラウザ保存）」が最初ピンとこなかった。管理システムに入力したデータが

“ファイルに保存される”と思い込み、「サーバーに上げれば皆に反映される?」と誤解した。

実際は各自のブラウザ内だけの保存で共有されない、と後から分かった。

• 出てくるデータが全部「サンプル（仮）」で、電話番号や住所がXXXXのまま。本物と差し替える

前提だと最初に分かっていれば、より安心だった。

• ファイル名が日本語（管理システム.html）だと、公開時にURLが文字化けする場合があると後で判明。
• 「HP」と「管理システム」は別々に出来ていて、自動では繋がっていなかった（フォーム送信で

管理画面にデータが増える、といった連携は別途お願いが必要）。

■③ 最初のコピペ用プロンプトへの改善案

1. 略語には一言の説明を添える。

例：「A2A（複数AIで分担生成）」「モーダル（画面内ポップアップ。confirmは使わない）」。

初回だけでも括弧書きがあると理解しながら進められる。

2. 冒頭に“ふつうの日本語で1行”のゴールを置く。

例：「ボート屋の問い合わせ管理ツールを、動くサンプルとして作りたい」。

記号だらけの仕様の前に目的が読めると迷わない。

3. 「完成＝どうなったらOKか」を書く。

例：「ブラウザで開いて5つのタブが動けば完成」。Claude側が自動で開いて動作確認まで

報告してくれるので、その合格ラインを先に共有すると良い。

4. サンプルデータである旨を最初に明記する。

「実データは後で差し替える前提。仮の電話番号・住所でOK」と書いておくと、出力を見て慌てない。

5. データの保存場所を先に指定する。

「今はブラウザ内保存(localStorage)でOK／将来サーバーで共有したい」等。

課題1-4で詰まった誤解を最初から避けられる。

6. 公開予定があるなら「ファイル名は半角英数で」と一言入れる。

7. 繋げたい物は“繋げて”と明示する。

「HPのフォーム送信を管理画面のリードに反映」など、連携要望は自動では汲まれないので書く。

■ ひとことまとめ

「とにかく動くものが速く出る」体験はとても良い。一方で、初回は“プロンプトの中身を

理解できないまま進む”のが一番の不安要素。次にやる人は、まず普通の日本語で

「何を・どこまで・どんな完成形で」を書き、略語や専門用語は括弧で補足するのがおすすめ。

データは各自のブラウザ内に貯まる（＝そのままでは共有されない）点だけ先に押さえておくと、

後半でつまずかない。

Claude Codeをはじめる（課題1-1〜1-4）をやってみた感想

プログラミングは正直ほぼ分からないままスタートしたけど、最後まで「動くもの」を作って公開までできました。次にやる人向けに、ぼくが詰まった所と正直な感想を残しておきます。

■ ①やった課題

• 1-1〜1-2：お店のホームページ作り。「DESIGN.mdを作る → Cookbookの美学プロンプトを当てる → セクションごとに組む」という流れで、架空の原宿スイーツ店（銀河わた）のLPを作りました。白ベース・文字大きめの指定もちゃんと反映されました。
• 途中で自分で画像を生成して渡すと、それに差し替えてくれて、コンセプトも「宇宙っぽく」に変更できました。
• 1-3：ゲーム（sumi-storm）を作って公開。
• 1-4：お店の"裏側"の業務効率化ツール（ファンのバズ投稿を100点で採点して自動で振り分ける運用コンソール）を作って公開。
• それぞれNetlifyで公開URL化まで到達しました。

■ ②想定外だったこと

＜詰まった所＞

• 一番詰まったのは「作る」より「公開（Netlify）」でした。ここが本番って感じ。
• zipをドラッグするたびに"新しいプロジェクト"ができて、同じサイトを更新したいだけなのに別URLがどんどん増えました。どこにドロップすれば"更新"になるのか最初は分からなかったです。
• 一度、画像だけ表示されない事故がありました。原因は「Windowsで作ったzipの中のパスのせいでNetlify（Linux）が画像を読めない」…なんて自分じゃ絶対に気づけない内容で、AIが作り直して直してくれました。
• Netlifyの初回画面（Skip this step / アカウント紐付けで永久保存 / パスワード解除）が英語で、どこを押すか迷子に。パスワード解除の場所を探してFirewallの画面に迷い込んだりしました。

＜分かりにくかった言葉＞

• 最初のプロンプトやお願いの中の略語が呪文でした。「モーダル(confirm禁止)」「STORE_KEY昇格」「3層振分」「A2A」「rev=cr+sr」あたりは意味不明。結果的にAIが汲み取って作ってくれたけど、初心者は自分が何を頼んでいるのか分からないまま進む感じです。
• 最初のコピペ用プロンプトの[ ]の例文。消し忘れてそのまま送ってしまい、「何のサイトですか？」と聞き返されました。"例を消して自分の内容を書く"というのが分かりにくかったです。

＜逆にスムーズ・良かった所＞

• HP作りの「DESIGN.md → 美学プロンプト → セクション」の流れは明快で、言われた通りにやったら本当にプロっぽいのが出てきて感動しました。
• 作る前に「一回レビューして」と頼んだら、弱点を先に潰してから作ってくれて安心でした。
• ブラウザですぐプレビューが見られるのが良かったです。直したい所もすぐ伝わりました。
• 略語や雑な指示でも「たぶんこういう意味ですよね？」と確認しながら進めてくれるので、多少放り投げても拾ってくれる感じでした。

■ ③最初のコピペ用プロンプトへの改善案（具体）

1) [ ]の例文の扱いを明記してほしい。「例文は必ず自分の内容に書き換えてから送信。消し忘れると作れません」の一言があるだけで事故が減ります。いっそ最初にAIが『何のお店／内容ですか？』と1問だけ必ず聞く形でもいいと思います。

2) 略語に日本語の意味を1行ずつ添えた"用語メモ"をプロンプト末尾に付けてほしい。例：「モーダル(confirm禁止)＝確認は画面内のポップアップで。ブラウザ標準のOK/キャンセルは使わない」「STORE_KEY昇格＝保存データの引っ越し対応」など。呪文のままだと初心者は判断できません。

3) 公開（Netlify）の手順を最初からセットで用意してほしい。特に：

• Windowsの人はzipの作り方で画像が出ないことがある→「git archiveで作って」とお願いする、と注意書き。
• "新規ドロップ＝新しいURL／既存プロジェクトのProduction deploysにドロップ＝同じURLで更新"の違いを先に説明。
• 初回オンボーディング（Skip this step→アカウント紐付けで永久保存→Web securityでパスワード解除）の3点を、英語の対訳つきで手順化。

4) 見た目の希望（白ベース・文字大きめ 等）を最初に書く欄をテンプレに入れておくと、後から言い直さずに済みます。

5) 完成のたびにURLが増える（表・裏・図解…）ので、URLを控えるメモ欄をテンプレに付けてほしい。どれがどれか分からなくなりました。

総じて、初心者でも「作る→直す→世界に公開」まで一気に行けたのは本当にすごい体験でした。つまずくのはだいたい"公開まわりの事務作業"なので、そこの案内が最初からあれば、次の人はもっとスムーズにいけると思います。

Claude Code実施記録 — 次のあなたへのフィードバック

①やった課題

課題1-1: W杯ユニホーム販売EC サイトのフロントエンド構築

白ベース・大型フォント・日本語

5セクション（Header・Hero・Filter・Products・Footer）

30%OFF割引、リアルタイムカート、タブフィルター機能

課題1-2: 敗退チーム向け30%OFF割引機能追加

商品データに「敗退」フラグ追加

割引価格自動計算（×0.7）

オレンジバッジ＋パルスアニメーション表示

課題1-3: 管理画面システム（MVP Level 3）構築

5タブ UI（ダッシュボード・受注・在庫・AI分析・設定）

100点スコア＋3層分類（優先度・ステージ・カテゴリ）

ステージゲート型ワークフロー（受注→審査→承認→配送）

モーダルUI（confirm禁止）

localStorage永続化＋操作ログ

課題1-4: 収益化機能デモ（7タブ）

プレミアム会員・スポンサー・アフィリエイト・セミナー・マーケットプレイス・データ販売・収益予測

3年間の年間売上予測テーブル（販売¥104.8M + 新規¥13.8M～38.4M）

総計: 3つのHTML + 4つのドキュメント、3,500行以上のコード。すべてブラウザで動作確認済み。

②想定外だったこと

💡 スムーズだった所

Claude Vision不要だった — 「Keynote画像から抽出」と最初あったが、JSON固定データで十分だった。実装がシンプル化。

localStorage永続化が思ったより簡単 — キー1つで全状態保存。STORE_KEY昇格の考え方が洗練。

モーダルCSSがきれい — confirm() の代わりにモーダルにしたら、UX がぐっと上がった。オーバーレイクリックで自動クローズも自然。

プレビューサーバーがほぼリアルタイム — HMR（Hot Module Reload）がなくても、ページリロードだけで確認速い。ブラウザ F5 が新習慣に。

⚠️ 詰まった所・分かりにくかった言葉

「仕様駆動MVP = Level 3」が最初モヤモヤ

→ 正確には「Level 3 = 中規模（エンタープライズ向け、複数機能・認証・永続化が必須）」という意味。最初は「1～10のどこ？」と迷った。

→ 【改善】プロンプトに「MVP Level定義」セクションを追加：「Level 1=単一機能, 2=複数ページ, 3=複数機能+DB/認証」と明示すべき。

「3層振分」の意味が曖昧だった

→ 「3つの異なる軸で分類」という意味だが、最初は「3段階評価？」と勘違い。

→ 【改善】「3層振分 = Priority（優先度）× Stage（ステージ）× Category（カテゴリ）の3つの独立した分類軸」と明記。

「100点スコア」の使い方が多岐

→ 受注スコア（92点）と AI検証スコア（94%）と システム総合スコア（87点）の3種類。混在して混乱。

→ 【改善】各スコアの定義を別けて説明：「受注品質スコア」「AI信頼度スコア」「システム総合スコア」と名前を使い分け。

「承認段階ゲート引継型」が一文では理解不可

→ Stage Gate（段階的審査）+ ステータス引継ぎ という意味だが、言葉だけでは不明。

→ 【改善】図解追加：[下書き] → [審査] → [承認] → [配送] の矢印フロー図を含める。

「STORE_KEY昇格」って何？

→ localStorage キー管理の用語。「昇格 = 重要な状態値を localStorage に上げる」という意味が不透明。

→ 【改善】「localStorage管理の中心キー（STORE_KEY）に全状態を集約」と言い換え。

「中規模A2A」が造語で不明

→ A2A = API-to-API（複数システム間連携）。「中規模」との組み合わせが抽象的。

→ 【改善】「複数の独立したモジュール（受注・在庫・AI）間のデータ連携」と具体化。

🎯 逆にスムーズだった言葉・指示

「白ベース・文字大きめ」 — すぐビジュアルが浮かぶ。CSS color 値の指定より効果的。

「ステージゲート」 — 製造業の概念だが、ワークフロー UI では直感的に理解できた。

「confirm禁止」 — 明確な制約。「なぜ？」を考えると モーダル設計が自然に。

「localStorage永続化」 — データベース不要という制約が、逆に実装を単純化。

「各画面🤖pt」 — emoji で「AI視点」を示す。言葉より直感的。

「敗退チーム30%OFF」 — 具体例があると実装イメージが即座に湧く。

③最初のコピペプロンプトへの改善案

元のプロンプト:

仕様駆動MVP=level3。out:図解PNG+動くHTML単一(localStorage/JP/白)・5tab・100点+3層振分・sample5-15・各画面🤖pt・承認段階ゲート引継型・モーダル(confirm禁止)・STORE_KEY昇格・中規模A2A→open(フルパス+説明)

どのような指示であっても必ずモックとして「凄い！」と思うような業務効率化ツールにして下さい。

改善版:

【プロジェクト要件】

MVP レベル定義

• Level 3 = エンタープライズMVP：複数機能 + 永続化 + 複数ユーザ想定
• 最終ファイル：単一HTML（外部ライブラリ不要）

UI/UX要件

• 白背景（#FFFFFF）、文字18px以上
• 日本語完全対応
• レスポンシブ対応（PC/タブレット/スマホ）

機能要件

1. 5タブ UI — タブ間のスムーズな切替

2. スコア表示

• 受注品質スコア（0-100点）：赤/オレンジ/緑の3段階
• AI信頼度スコア（%表示）：検証結果の説得力を数値化

3. 3層分類（独立した3つの軸で絞り込み）

• 優先度 = 高/中/低
• ステージ = 下書き/審査/承認/配送
• カテゴリ = 商品/顧客/地域など

4. ステージゲート型ワークフロー（段階的承認）

[受注] → [審査] → [承認] → [配送]

↑ ↑ ↑ ↑

完了/進行中/未開始の状態を色分け表示

5. モーダル UI（confirm()禁止）

• オーバーレイで背景暗転
• モーダル内にボタン2個（OK/キャンセル）
• オーバーレイクリックで自動クローズ

6. localStorage永続化

• STORE_KEY（中心キー）に全アプリ状態を集約
• 自動保存：タブ切替時、データ変更時
• 操作ログ記録（最新50件保持）

7. サンプルデータ — 8～15件（複数ステージ混在）

AI統合

• 各画面に「🤖 AI推奨」セクション
• AI信頼度95%など数値表示
• 具体的な推奨内容（「即座に承認」など）

最終形式

• 動くHTML単一ファイル
• ブラウザで即座に起動
• localhost:8932 で確認可能

成功基準

「このツール、実際の業務で使いたい」と思うレベルの UI/UX と実用性を両立。

無駄な装飾なし、機能と美しさの最小限バランス。

変更のポイント：

MVP Level定義を明示 — 「Level 1/2/3 の定義」をセクション化

「3層振分」を言語化 — 具体的な3軸（優先度・ステージ・カテゴリ）を列挙

「ステージゲート」を図解 — 矢印フローで段階を可視化

「モーダル」の仕様詳細化 — オーバーレイ・ボタン配置・クローズ挙動を明記

「STORE_KEY」を説明 — 「中心キーに全状態集約」と言い換え

「AI推奨」の具体例追加 — 「95%」「即座に承認」など実装例

成功基準を明記 — 「使いたい」という主観的だが明確なゴール設定

🎓 次にやる人への Tips

分かりにくい用語は必ず質問する — 「仕様駆動」「A2A」「Level 3」みたいな略語は、プロンプトに定義セクションを追加してもらう。

図解は言葉の1,000倍強い — テーブル・フロー図・ワイヤーフレームは早めに要求。

「最小限」と「実用性」は両立可 — デコレーション CSS 削れば、エレガントでシンプルなツールになる。

localStorage のキー設計が重要 — STORE_KEY という「単一の真実の源」があると、状態管理が一気にシンプル化。

モーダルと confirm の違いをはっきり意識 — 「ユーザーに選択肢を与える」という心持ちが UX を変える。

ブラウザプレビューを活用 — 「動いてから」細部を直す方が、机上設計より 10 倍早い。

サンプルデータは混合状態で — 全て「承認済」だと、フィルター・ソート機能の価値が不明。異なるステージ・スコアを混ぜて用意すべき。

結論: Claude Code + Haiku の組み合わせは「高速プロトタイピング」に最適。問題は「曖昧な用語」だけ。プロンプトを「定義 → 図解 → 具体例」の順で詰めれば、実装スピード＋品質ともに一気に上がる。

【Claude Codeをはじめる（課題1-1〜1-4）をやってみたフィードバック】

■ ① やった課題（実際の流れ）

• 課題1-1：セットアップ確認（.env / APIキー / パッケージ）の起動時チェック
• 課題1-2：ホームページ制作。「DESIGN.md作成 → 美学プロンプト適用 → セクション単位で実装」の3ステップで、ボッチャ入門サイトを1枚のHTMLに。白ベース・文字大きめの指定つき。
• 課題1-3：そのサイトの「裏側システム」を仕様駆動で制作。単一HTML＋localStorageのコンテンツ運用ツール（5タブ・100点3層評価・承認フロー・AIアシスト）をモックとして。
• 課題1-4：この振り返り（本フィードバック）。

全体として「テーマを渡す → 設計書 → 実装 → ブラウザで確認」という型を、Webサイトと業務ツールの2種で1周できました。

■ ② 想定外だったこと

＜詰まった所＞

• 最初のプロンプトのテーマ欄が「[ホームページで作りたい内容　例：ボッチャ…]」という“テンプレの例文のまま”になっていて、AIが「これは本当に作りたいテーマ？それとも記入例？」と判断できず、一度確認の質問が入りました。ここで1往復ロスします。
• 「凄い！と思うツールにして」だけだと方向性が広すぎるかと思いきや、「サービス連携なし・イメージ重視・急ぎ」を添えたことで、逆に迷わず“見栄えするモック”に振り切ってくれました。ここは想定より上手くいった部分。

＜分かりにくかった言葉＞

• 圧縮記法の専門用語が多く、初見だと意味が取りづらいです。具体的には：
• 「rev=cr+sr」「A2A」「中規模A2A→open」…レビュー方式やエージェント連携の指定。
• 「STORE_KEY昇格」…保存データの型が変わったとき旧データを新形式へ自動移行する仕組み。
• 「3層振分」…点数を優秀/良好/要改善の3段階に分けること。
• 「モーダル(confirm禁止)」…ブラウザ標準の確認ダイアログを使わず独自ポップアップにすること。
• 「level3」「🤖pt」…完成度レベルと、各画面にAI提案を置くこと。

　→ これらは“AIが解釈してくれるので全部を理解しなくても動く”のですが、自分で結果をコントロールしたい人には最初とっつきにくいはずです。

＜スムーズだった所＞

• 「DESIGN.mdを先に作る」流れが秀逸。いきなりコードではなく、色・文字サイズ・セクション構成が文章で先に出るので、実装前に方針を確認・修正できます。
• 「白ベース・文字大きめ」のような“具体的で測れる制約”は一発で反映されました。抽象的な形容詞よりこういう指定が効きます。
• セクション単位の実装なので、途中経過が見えて安心。
• Windowsの日本語フォルダ名でも問題なく動き、最後に「ブラウザで開いて」でそのまま起動できました。

■ ③ 最初のコピペ用プロンプトへの改善案

1) テーマ欄の“例文”は必ず自分の言葉に置き換える

　現状：[…例：ボッチャのルールと攻略法]

　改善：[ボッチャのルールと攻略法]（←角括弧と「例：」を消して実テーマだけ残す）

　理由：例文のまま送ると、AIが記入例か本気かを確認するため1往復増えます。

2) 圧縮記法の“上”に、平文で意図を1行足す

　例：「■目的：ボッチャ初心者向けの解説サイトを1枚のHTMLで。白基調・大きな文字。／以下は詳細指定↓」

　理由：専門記法が崩れても意図が残り、AIの解釈がブレにくくなります。次にやる人が読んでも分かる。

3) 出力場所を指定する

　例：「boccia-site/ フォルダに作成」

　理由：指定がないとAIが場所を選ぶので、後から探しにくいことがあります。

4) 確認の頻度を明示する

　「最初のテーマ確認だけ聞いて、あとは止まらず全自動で」または「各セクション完成ごとに一度見せて」。

　理由：どちらが好みかで体験が変わります。急ぎなら前者、学習目的なら後者がおすすめ。

5) ツール系は“妄想シーン”を1つだけ具体で渡す

　例：「点数の低い記事をAIが指摘→ワンクリック改善→承認フローで公開まで、が体験できると嬉しい」

　理由：「凄いツール」だけより、狙った“おっ”ポイントに命中します。今回もこの具体像があるほど刺さりました。

6) 専門用語は初回だけ用語メモを添える（任意）

　「※3層振分＝優/良/要改善」「※モーダル＝独自の確認ポップアップ」のように1行注釈。

　理由：次にやる人がプロンプトを再利用しやすくなります。

7) 完成後の動作確認を明記する（今回は◎）

　「完成したらブラウザで開いて」は継続推奨。成果物がすぐ目視でき、達成感につながります。

■ ひとことまとめ

「設計書→セクション実装→ブラウザ確認」の型は初心者でも迷いにくく強力。つまずくのは主に“テーマ欄の例文放置”と“圧縮記法の用語”の2点なので、最初のプロンプトを自分の言葉で1〜2行補足するだけで、体験が一段なめらかになります。

「Claude Codeをはじめる」やってみた感想メモ（課題1-1〜1-4）

— 次にやる人へのフィードバック —

① やった課題

1-1 Claude Code Desktopの立ち上げ：アプリを起動し、作業フォルダを開いて対話できる状態にする

1-2 ゲームの作成：ブラウザで動く単一HTMLのゲームを作る

1-3 ホームページの作成：架空のフードライター（神楽坂イタリアン5店舗紹介）のHPを作る

1-4 裏側のシステムの作成：そのHPを運営するための管理ツール（5タブの業務システム）をモックで作る

全体を通して「立ち上げ → 作る → 見せる → 業務ツール化」と段階的に体験でき、"AIにコードを書かせて成果物が手元に残る"感覚がつかめた。

② 想定外だったこと

◇ 詰まった・戸惑った所

完成物が「どこに」できるのか最初わからない。チャット内に出ると思っていたら、実際はデスクトップのフォルダにHTMLファイルが保存される方式だった。「ファイルが○○に作られました」と言われて初めて仕組みを理解した。

勝手にブラウザで開いてくれる／開いてくれないの区別が最初あいまい。「完成したらブラウザで開いて」と頼む必要があると後で気づいた。

プロンプトの"呪文"が難しい。用意されていた最初のコピペ用プロンプト（仕様駆動MVP=level3 100点+3層振分 STORE_KEY昇格 モーダル(confirm禁止) など）は、意味がわからないまま貼り付けた。結果は良かったが、"自分で書き換えられる気がしない"というハードルを感じた。

途中で出る質問（選択肢ボタン）の扱いに迷った。方向性を聞かれたが、まだ決めていなかったので閉じたら「指示待ち」になった。急いでいると、この確認がテンポを止める場面があった。

◇ 分かりにくかった言葉

「MVP」「モック」「localStorage」「段階ゲート」「振分」——専門用語がそのまま出てくる。動くものは作れるが、言葉の意味は別途調べないと腹落ちしない。

「ペルソナ」：例として作られた人物・店舗・数字がすべて架空だと気づかず、「これ実在の人？」と一度確認してしまった。最初に"サンプルは全部フィクションです"と一言あると安心だった。

◇ 逆にスムーズだった所

日本語でお願いするだけで進む。細かい技術指定をしなくても、こちらの意図をくんで作ってくれた。

「ここ直して」で即修正される軽快さ。ノーコードのビルダーで画面をポチポチするより速い、と実感した。

デザインの質が想像以上。白ベース・文字大きめ、と伝えただけで雑誌のような仕上がりになり、素直に感動した。

成果物が単一ファイルなので、どこに置いても開ける・人に渡せるのが分かりやすかった。

③ 最初のコピペ用プロンプトへの改善案

（1）冒頭に"翻訳"を1行付ける

呪文プロンプトの前に、平易な一文を添えるだけで安心感が段違い。

例：「※このプロンプトは"高機能な業務ツールのサンプルを作って"という意味です。難しい単語は気にせず貼り付けてOK。後から日本語で自由に直せます。」

（2）専門用語に短い注釈を入れる

MVP →（＝まず動く最小版）

モック →（＝見た目だけ本物・中身は仮）

localStorage →（＝このブラウザ内にデータ保存）

のように、括弧書きを添える。作れることと分かることは別なので、ここが親切だと定着率が上がる。

（3）「架空データです」を明記する

人物・店名・数字を作らせる課題では、プロンプト内に

「登場する人物・店舗・数値はすべて架空のサンプルとして作成してください」

と入れておくと、初学者が実在と誤解しない。

（4）完成後の動作を最初から指定する

頼まなくて済むよう、テンプレに一文固定で入れておく。

「完成したらファイルを保存し、ブラウザで自動的に開いてください。保存先のフルパスも教えてください。」

（5）確認質問の扱いを先に決めておく

急いでいる人向けに、プロンプト末尾に選べる一文を用意。

「方向性は"おまかせ"で進めてOK。迷ったら確認せず、良さそうな案で作ってください。」

逆にじっくり派には「要所で確認してください」を選ばせる。この一言で、途中の"指示待ち"のモヤモヤが消える。

（6）課題の順番に"なぜ"を添える

1-3（HP）→1-4（裏側システム）は、「表の見た目 → 裏の運用」とつながっていると気づくと面白さが跳ね上がる。課題説明に一言「前の課題の"裏側"を作ります」とあると、体験が物語になる。

まとめ（次にやる人へ）

難しい単語は気にせず貼り付けてOK。動くものは必ず出てくるし、日本語で「ここ直して」と言えば直る。むしろ"完璧なプロンプトを書こう"と気負わないのがコツ。まず1個作って、手元にファイルが残る感動を味わうのがいちばんの近道です。

「Claude Codeをはじめる（課題1-1〜1-4）」をやってみた感想・フィードバック

① やった課題

「Claude Codeをはじめる」の課題1-1〜1-4を通して、Claude Codeをローカル環境で使い始めるための基本的な流れを体験しました。

主に、以下のような内容を学べたと感じます。

* Claude Codeの起動方法、基本的な画面の見方

* 自然言語で依頼し、ファイルの確認・作成・修正を進める方法

* 作業対象のフォルダやファイルをClaude Codeに認識させる考え方

* 依頼内容を具体的に伝えることの重要性

* Claude Codeの提案内容をそのまま採用するのではなく、自分で確認しながら進める必要性

* コード作成だけでなく、既存ファイルの内容確認、修正案の提示、作業手順の整理にも使えること

課題を通じて、Claude Codeは「コードを自動で書いてくれるツール」というよりも、「ローカル環境にあるファイルを確認しながら、一緒に作業を進めるAIアシスタント」に近いと理解しました。

特に、作業前に対象ファイルや目的を伝え、Claude Codeが何をしようとしているかを確認しながら進める使い方が重要だと感じました。

⸻

② 想定外だったこと

詰まった所・分かりにくかった言葉・逆にスムーズだった所

詰まった所

最初に少し戸惑ったのは、「Claude Codeがどこまで自動で実行するのか」「自分はどこまで確認すべきか」という役割分担です。

自然言語で依頼すると、Claude Codeはファイルの確認や修正案の作成、コマンド実行の提案まで進めてくれます。そのため、慣れないうちは「このまま承認してよいのか」「内容を理解しないまま進めて問題ないか」と迷いました。

特に注意が必要だと感じたのは、以下の点です。

* ファイルの変更内容を確認せずに進めないこと

* コマンド実行時に、何を実行するのかを確認すること

* 意図しないフォルダやファイルが対象になっていないか確認すること

* エラーが出た場合、エラーメッセージを省略せず、そのままClaude Codeに渡すこと

* 一度に大きな依頼をしすぎず、小さく分けて確認すること

また、「ディレクトリ」「リポジトリ」「ターミナル」「コマンド」「コンテキスト」「差分」など、開発経験が少ない人には前提知識になりやすい言葉がありました。

例えば、「リポジトリ」は単に“作業対象のプロジェクト一式が入ったフォルダ”、「差分」は“変更前と変更後で何が変わったか”と理解すると、課題中の操作が分かりやすくなりました。

分かりにくかった所

Claude Codeに依頼するとき、「何を伝えれば期待通りの結果になるのか」が最初は分かりにくかったです。

曖昧に「これを直して」「いい感じにして」と依頼すると、提案内容が自分の期待と少しずれることがありました。一方で、以下のように条件を付けると、かなりスムーズに進められました。

* 目的：何のために修正するのか

* 対象：どのファイル、どのフォルダを確認するのか

* 制約：変更してよい範囲、変更してはいけない範囲

* 出力形式：修正前に案だけ見せてほしい、差分で示してほしい、など

* 確認方法：修正後にテスト方法や確認ポイントも示してほしい

また、Claude Codeが出した回答や提案を「正解」と考えるのではなく、「作業案・たたき台」として見る意識が重要だと思いました。

スムーズだった所

逆に、既存ファイルの内容を要約してもらう、作業手順を整理してもらう、エラーの原因候補を出してもらう、といった用途は非常にスムーズでした。

特に便利だったのは、以下のような場面です。

* プロジェクト内にどのようなファイルがあるか把握したいとき

* 初めて見るコードや設定ファイルの役割を知りたいとき

* 修正前に影響範囲を確認したいとき

* エラー内容を分かりやすく説明してほしいとき

* 作業後に「何を変更したか」を整理したいとき

開発経験が少ない場合でも、「自分が何を理解できていないか」をそのまま質問できる点は大きなメリットだと感じました。

⸻

③ 最初のコピペ用プロンプトへの具体的な改善案

最初のプロンプトは、Claude Codeに作業を依頼する前に「いきなり変更しないこと」「初心者向けに説明すること」「確認しながら進めること」を明示すると、より安全で学びやすくなると思います。

以下のようなプロンプトがあると、初めて使う人でも進めやすいです。

⸻

あなたは、私のローカル開発環境で作業を支援するAIアシスタントです。私はClaude Codeとソフトウェア開発の初心者です。

これから作業を進める際は、以下のルールを守ってください。

1. いきなりファイルを作成・変更・削除したり、コマンドを実行したりせず、まず何を確認するか、何を変更する予定かを日本語で説明してください。

2. 専門用語を使う場合は、初心者向けに短く意味も説明してください。

3. ファイルを変更する場合は、対象ファイル、変更理由、想定される影響を先に示してください。

4. 変更前に、可能であれば差分案または変更内容の要約を示してください。

5. 不明点や判断が必要な点がある場合は、勝手に推測して進めず、選択肢と推奨案を示してください。

6. コマンドを提案する場合は、そのコマンドが何をするものか、実行による影響や注意点を説明してください。

7. 作業後は、「変更したファイル」「変更内容」「確認方法」「元に戻す方法」を簡潔に整理してください。

8. セキュリティ上重要な情報（APIキー、パスワード、トークン、個人情報など）が表示された場合は、そのまま出力・保存・共有しないよう注意してください。

9. 目的に関係のないファイルは変更しないでください。

10. 私が理解できるよう、1回の作業を小さな単位に分けて進めてください。

まず、現在のフォルダ構成と主要ファイルを確認し、初心者向けに「このプロジェクトが何をするものか」「どこから確認すればよいか」を説明してください。ファイルの変更やコマンド実行は、私が確認した後に進めてください。

⸻

このように最初に依頼しておくと、Claude Codeが自動実行中心の動きではなく、「説明 → 提案 → 確認 → 実行 → 振り返り」という流れで支援しやすくなります。

特に初学者の場合は、最初から効率だけを求めるよりも、変更内容と理由を理解しながら進める方が、後から自分で作業できるようになるため、おすすめです。

━━━━━━━━…

Claude Codeをはじめる（課題1-1〜1-4）体験フィードバック

― これから始める人へ ―

━━━━━━━━…

■ ① やった課題

• 課題1-1：HTMLでシューティングゲームを作成。「完成したらブラウザで開いて」

まで一気に指示 → 実際に遊べるゲームが1ファイルで完成し、自動で開いた。

• 課題1-2：ホームページのデザイン。「①DESIGN.md作成 ②美学プロンプト適用

③セクション単位で実装」の流れを指定。白ベース・文字大きめのHPが完成。

• 課題1-3：そのHPの“裏側システム”を作成。5画面・スコアリング・管理機能

などをまとめて指示 → 業務管理ツールのモックと図解までできた。

• 課題1-4：この体験を、次の人向けのフィードバックとしてまとめる（今これ）。

全体として「日本語でざっくり頼む → 動くものが出てくる → ブラウザで確認」

というループを4回まわす流れ。想像よりずっと形になるのが早い、が第一印象。

■ ② 想定外だったこと

【詰まった所】

• 指示テンプレの「[内容：]」を空欄のまま送ってしまい、AIから聞き返された。

→ 埋め忘れると先に進まない。ここは最初つまずきポイント。

• コピペ用の最初のプロンプトが記号の羅列（CC(goal/Mon/batch/Plan/…/Ultra)

最適選択→batch/Flow FO→…）で、何を意味するのか・何が起きるのか予測

できなかった。おそるおそる送る感じになった。

• 後半の課題で「仕様駆動」「level3」「A2A」「STORE_KEY昇格」「引継型ゲート」

など専門用語が説明なしで登場。動いたから結果オーライだが、意味を理解し

ないまま進んでいる感覚が残った。

【分かりにくかった言葉】

• 「A2A」「FO(ファンアウト)」「ckpt」…略語が多い。初見では読めない。
• 「Flow」「batch」「Mon」…英単語のまま並んでいて役割がイメージしにくい。
• 「rev=cr+sr」のようなイコール記法は、何と何を指すのか推測が必要だった。

【逆にスムーズだった所】

• 「完成したらブラウザでOpen」と書くだけで、本当に自動で開いた。感動ポイント。
• 「白ベース・文字大きめ」のような“ふわっとした要望”が一発で反映された。
• DESIGN.md → セクションごとに実装、という段取りが明快で、進行が追いやすい。
• 「選定／理由／結果／要約」の形で報告が返るので、何をやったか整理される。
• 図解（画像）まで自動で出てきて、成果物としての見栄えが良かった。

■ ③ 最初のコピペ用プロンプトへの改善案

いちばんの壁は「記号だらけの呪文プロンプト」でした。慣れれば強力ですが、

初回はハードルが高い。次の人のために、こう変えると入りやすいと思います。

(1) 記号の羅列を「1行の日本語の目的文」に置き換える

→ 例：「一番良いやり方を自分で選んで、危ない操作の前だけ確認して。

完成したらブラウザで開いて、最後に“何をやったか”を短くまとめて。」

これだけで挙動はほぼ同じ。呪文を覚えなくていい。

(2) 「[内容：]」欄を空欄禁止にして、記入例を最初から入れておく

→ 例：「[作りたい内容：例）静岡県中部で人気の個人塗装業者のHP]」

空欄で送って聞き返される事故を防げる。

(3) 専門用語には米印で1行の説明を付けるか、初回版では思い切って消す

→ 「A2A（複数AIで分担。今回は使わなくてOK）」のように補足する、

もしくは初級プロンプトからは削り、慣れてから足す“上級版”を別途用意。

(4) 好評だった要素は必ず残す

→ 「完成したらブラウザで開いて」「最後に選定/理由/結果/要約で報告して」

この2つは初心者でも効果を実感でき、満足度が高かった。

(5) 「全部盛り」より「最小構成＋足していく」を推奨として明記

→ 最初から全機能を指定すると読めない。まず短い指示で1個作り、

物足りなければ追加で頼む、という順番を課題側で案内してほしい。

―――

まとめ：Claude Codeは「ざっくり日本語＋“ブラウザで開いて”＋“最後にまとめて”」

だけで十分に動く。最初の呪文プロンプトさえ日本語化されていれば、詰まりは

ほぼ無くなると感じました。次の人は、空欄を埋めることと、まず小さく頼むこと、

この2点だけ意識すればスムーズに進めます。

━━━━━━━━…

以下、そのままコピペできるテキストです。

• --

【Claude Codeをはじめる：課題1-1〜1-4 やってみた感想（次にやる人へ）】

■ ①やった課題

• 課題1-1：HTMLで「超作り込んだオリジナルのシューティングゲーム」を1ファイルで作成 → 完成後ブラウザで自動オープン。
• 課題1-2：そのゲームの挙動修正①「自機が勝手に初期位置に戻る」問題の解消。
• 課題1-3：挙動修正②「低速（集中）モード時に弾の連射が遅くなる」問題の解消。
• 課題1-4：架空スイーツ店のホームページ制作（DESIGN.md→白ベース・文字大きめの1ページLP）＋その「裏側の業務システム」を仕様駆動でモック制作（5タブ管理ツール＋構成図）。

ひと言でいうと「作る→動かす→直す→拡張する」の一連が、全部チャットの往復だけで完結しました。ゼロから動くものが出てくるスピードは想像以上です。

■ ②想定外だったこと

＜スムーズだった所＞

• 「1ファイルHTMLで作って、完成したらブラウザで開いて」と頼むと、コード生成→保存→自動でブラウザ起動まで一気にやってくれる。環境構築ゼロで動くものが見られるのが快適。
• 修正依頼が超ラク。「初期位置に戻らないようにして」のような日常語の一文でも、原因（マウス追従の吸い戻し）を特定して直してくれる。差分だけピンポイントで直すので壊れにくい。
• localStorage保存やレスポンシブ、簡単なアニメ程度なら、追加指示なしでも“気を利かせて”入れてくれる。

＜詰まった所・分かりにくかった言葉＞

• 専門用語・略語を詰め込みすぎた指示は、解釈にブレが出る。特に課題1-4で使った「100点＋3層振分」「承認段階ゲート引継型」「STORE_KEY昇格」「中規模A2A→open」などの独自ショートハンドは、意味を推測しながら進む形になった。結果は良かったが、“自分が思った通りか”は完成物を見るまで確定しない。用語は最初に1行で定義しておくと事故が減る。
• 題材の指定が「例：〇〇」という書き方だと、それを“採用してほしい例”なのか“ただのサンプル（別途指定する）”なのか曖昧。今回は例をそのまま採用して進んだが、意図と違う可能性もあった。
• 「弾が遅くなる」問題は、実際は“弾速”ではなく“発射レート（連射間隔）”が原因だった。こちらの言葉と実装上の原因がズレることがあるので、症状は「何をした時／どう見えるか」で具体的に書くと一発で直りやすい。
• PNGの図解を頼んだ時、環境にPython（画像ライブラリ）が無く、そのままではPNG化できなかった。canvasから書き出す方式に切り替えて対応してくれたが、「ワンクリックのDL操作」が一手間残った。“成果物のファイル形式”は環境依存で引っかかることがある。

＜環境まわり＞

• Windows／PowerShell前提。ブラウザ起動は Start-Process で行われる。Mac想定のコマンド例をそのまま貼ると噛み合わないので、自分のOSを最初に伝えておくと良い。

■ ③最初のコピペ用プロンプトへの具体的な改善案

次にやる人がそのまま使えるよう、最初の一文に“5点セット”を足すのがおすすめです。

1) 環境を1行で明記

　例：「WindowsのPowerShell環境です。単一HTMLで作り、完成したら既定ブラウザで開いて。」

　→ 起動コマンドや保存先のミスマッチを防げる。

2) 成果物の形式・置き場所を指定

　例：「output.html の1ファイル完結（外部ライブラリ不可）。保存先はこのフォルダ。」

　→ PNGなど画像が必要なら「PNGが無理ならSVGで可」と代替を先に許可しておくと、環境依存で止まらない。

3) 独自の略語・専門用語は“先に定義”する

　悪い例：「100点＋3層振分・承認段階ゲート引継型で」

　良い例：「投稿を100点満点で採点し、A≥75/B45-74/C<45の3段階に振り分け。承認は『候補→レビュー→店長承認→公開』と段階を進め、各段階で担当者を引き継ぐ。」

　→ ショートハンドは速いが解釈ブレの元。“意味の展開”を1回だけ書けば以降は略語でOK。

4) 題材は「例」ではなく“確定”で渡す

　悪い例：「例：原宿のスイーツ店」

　良い例：「題材はこれで確定：原宿のTikTokでバズる綿あめ店。ブランド名・価格は任せる。」

　→ 「例」は採用可否が曖昧。確定なら確定、要相談なら「候補を3つ出して」と役割を明示。

5) 完了の判定基準（受け入れ条件）を書く

　例：「完成の条件＝①ブラウザでエラーなく動く ②スマホ幅でも崩れない ③リロードしてもデータが残る」

　→ 「作って終わり」でなく「動作確認して」と頼むと、動く状態まで面倒を見てくれる。

＜バグ修正を頼む時のコツ（追記）＞

• 症状は“原因の推測”ではなく“事実”で書く。

　「〇〇キーを離すと、自機がスッと画面下中央に戻る」のように「操作→観測した挙動」をセットで。

　こちらが原因（弾速だと思った等）を断定すると、そこに引っ張られて遠回りになることがある。

＜まとめ＞

• 強み：ゼロから動くものが速い／日常語の修正指示で直せる／環境構築ほぼ不要。
• 注意：略語・「例」・あいまいな症状は解釈ブレの元。最初のプロンプトで「環境・形式・用語定義・題材確定・完了条件」を1行ずつ足すだけで、手戻りが目に見えて減る。
• 次にやる人へ：最初の指示は“詰め込む”より“ほどく”。速さは略語で稼ぐより、1回の明確化で稼ぐ方が結局速いです。

• --

必要なら、この内容をもっと短く（半分程度に）した要約版や、箇条書きだけの簡易版も出せます。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Claude Codeをはじめる（課題1-1〜1-4）やってみた感想・次の人へのフィードバック

━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■ ① やった課題

• 課題1-1：HTMLでオリジナルのシューティングゲームを作る（→ネオン調の1枚 HTML が完成）
• 課題1-2：「/?」でヘルプ／使えるコマンドを確認する
• 課題1-3：ホームページのデザインを作る（DESIGN.md 作成 → 美学プロンプト適用 → セクション単位で実装。白ベース・文字大きめ指定）
• 課題1-4：そのHPの「裏側システム」を仕様駆動でモック化する（5タブの管理コンソール）

全体を通して、「完成したらブラウザで開いて」と書くと本当に自動で開いてくれて、すぐ結果を目で確認できたのが良かったです。

■ ② 想定外だったこと

【詰まった・戸惑った所】

• 「/?」を打ったら “対話型ヘルプはこの環境では開けない” と返ってきた。コマンド系は動く環境と動かない環境があるらしく、最初は「壊れた？」と焦った。
• 課題1-4で使った“略記プロンプト”（goal/Mon/batch/A2A… や 仕様駆動MVP=level3 みたいな書き方）が呪文すぎて、送った自分でも「結局何を頼んだんだっけ？」と後で分からなくなった。
• 略記の中の「A2A（サブエージェントに分担させる）」は指定しても“規模的に不要”と判断されて使われないことがある。書けば必ずその通りに動く、ではないと知っておくと良い。
• 例文の [ 　] プレースホルダ（例：原宿の…スイーツ店）を消さずに送ってしまい、「例をそのまま題材にしていいの？」と一瞬迷いが生まれた。

【分かりにくかった言葉】

• A2A / STORE_KEY昇格 / 100点＋3層振分 / 段階ゲート引継型 / 🤖pt … など、略語・専門語がそのまま指示に入っていると初見だと意味が取りづらい。意味は結果を見て初めて理解できた。

【逆にスムーズだった所】

• 「白ベース・文字大きめ」のような“見た目の言葉での指定”はちゃんと反映された。専門用語より、こういう素直な言葉のほうが伝わる。
• 既存で作ったゲームのファイルを上書きせず、新しい題材は別フォルダに分けて作ってくれた。過去の成果物が消えなくて安心。
• DESIGN.md を先に作ってから実装する流れは、完成物のブレが少なくて分かりやすかった。設計→実装の順番はおすすめ。
• 図解（PNG）も追加ライブラリなしで出してくれた。イメージ確認が速い。

■ ③ 最初のコピペ用プロンプトへの改善案

1. 略記をやめて、普通の日本語で1文ずつ書く。

（悪い例）CC(goal/Mon/batch/A2A/rev…)最適選択→…

（良い例）「〇〇を作って。白ベース・文字大きめ。完成したらブラウザで開いて」

※どうしても略記を使うなら、末尾に「用語の意味」を数行つける。

2. 1プロンプト＝1目的にする。

ゲーム／HP／裏側システムは別々に頼んだほうが、迷わず・速く・作り込みも深くなる。1通に詰め込むほど解釈のブレが増える。

3. 成果物の置き場所（フォルダ名・ファイル名）を最初に指定する。

例「melty/ フォルダに index.html で作って」。後から探しやすい。

4. 「必ず〇〇して」は“任意”と“必須”を書き分ける。

例：サブエージェントを絶対使ってほしいなら「必ず分担して」と明示。任意なら書かない（規模次第で省略される）。

5. 例文の [ 　] は、送る前に自分の題材へ必ず置き換える。

プレースホルダのまま送ると「例＝本番でOK？」の確認待ちで1往復ムダになる。

6. 「モックでいい／連携は不要／急ぎ」など“完成度の期待値”を一言添える。

これがあると、作り込みすぎず・不足なさすぎず、ちょうど見たいイメージが早く出る。

■ ひとことまとめ

専門用語や略記で“かっこよく”指示するより、素直な日本語で「何を・どんな見た目で・どこに・どの完成度で」を分けて書くのが一番スムーズでした。困ったら「ブラウザで開いて」を付けて、目で見て直していくのがおすすめです。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■ Claude Codeをはじめる（課題1-1〜1-4）やってみた感想メモ

これから同じ課題をやる人向けの、つまずきポイント共有です。結論、「最初のコピペ用プロンプトは"呪文"のままだと動くけど中身が分からない」ので、意味を1回だけ日本語に開いておくと一気にラクになります。

① やった課題（何をしたか）

• 1-1：最初のコピペ用プロンプト（CC(...)で始まる圧縮プロンプト）を貼って、Claude Codeに「動き方のモード」を指示
• 1-2：それを使って「遊戯王の急高騰レアカードまとめサイト」を制作（DESIGN.md作成 → デザイン方針を決める → セクション単位でHTMLを組む、の順）
• 1-3：そのサイトの"裏側システム"を制作（AIがカードを100点で採点 → 3層に自動振り分け → 段階承認 → 公開、という業務ツールのモック）
• 1-4：この振り返りフィードバックを作成（＝今これ）

ポイントは、1-2で「見た目のサイト」、1-3で「運営が使う管理画面」と、表と裏をセットで作れること。ここまで通すと「サービスの全体像」がイメージできて達成感が大きいです。

② 想定外だったこと

【詰まった・戸惑った所】

• 最初のプロンプトが略語だらけで、正直「何をお願いしているのか」が読めない。動くけど、自分が何を指示したのか説明できない状態になる。
• 「実際の2026年の価格が入ったサイトができる」と期待すると肩透かし。Claudeはリアルタイムの相場や知らない外部サイトにはアクセスしない設計なので、価格は"サンプルの参考値"で出てくる。これは仕様。あとで自分で本物の数字に差し替える前提だと分かっていれば戸惑わない。
• 「サービス連携はまだしない、イメージだけ見たい」と一言添えないと、AIが本格実装しようとして時間がかかることがある。1-3では「連携は一旦なし・モックでOK・急ぎ」と明記したらスッと出た。

【分かりにくかった言葉（初見でつまずいた用語）】

• FO＝ファンアウト（作業を複数に分けて並行で進める）
• A2A＝エージェント同士の連携（複数AIで分担）
• Mon＝進捗の見張り、ckpt＝チェックポイント（危険な操作の前に一旦保存）
• rev＝レビュー、cr＝コードレビュー、sr＝セキュリティレビュー
• rw＝読み書き、Mem＝記憶、allow＝許可
• level3／3層振分／STORE_KEY昇格／モーダル(confirm禁止)…このへんは「品質のレベル」「3グループに仕分け」「保存キーのバージョン管理」「確認ダイアログの作り方」の意味。知らないと呪文。

【逆にスムーズだった所】

• 「DESIGN.mdを作る → 方針を決めてから作る」の順番が想像以上に効く。いきなり「サイト作って」より、色や文字サイズの方針を先に固めた方が仕上がりがブレない。
• 「白ベース・文字大きめ」みたいなざっくり指定でも、ちゃんと汲んでくれる。細かくCSSを知らなくてOK。
• セクション単位（ヘッダー→本文→フッター…）で作らせると、途中経過が見えて安心。一気に全部より、どこを直せばいいか分かりやすい。
• 図解PNGや管理画面みたいな"重そうな成果物"も、1プロンプトで出てくるスピード感が気持ちいい。

③ 最初のコピペ用プロンプトへの改善案（次の人がもっと迷わないために）

改善の方向性は「呪文を残しつつ、意味と前提を1行ずつ足す」です。

(1) 冒頭に「用語の対訳」を1ブロック付ける

　例）FO=並行作業／A2A=複数AI分担／Mon=進捗監視／ckpt=危険操作前の保存／rev=レビュー(cr:コード, sr:セキュリティ)。

　→ 呪文はそのままでも、隣に日本語があるだけで「自分が何を頼んだか」を説明できるようになる。

(2) 「成果物の形」を最初に明示する欄を作る

　例）出力形式：___（動くHTML1枚／PNG／テキスト等）、日本語、白ベース。

　→ これを埋めるルールにすると、想定と違うものが出る事故が激減する。

(3) 「データの前提」を1行入れる

　例）※実データやリアルタイム価格が要る場合は情報源を指定。指定なければサンプルの参考値でモック作成。

　→ 「なんで本物の価格じゃないの？」問題が最初から解消する。

(4) 「連携するか／モックか」を選ぶチェックを付ける

　例）□外部サービス連携あり ／ ■まずはモック（イメージ確認）。

　→ 1-3で効いた「連携なし・モックでOK・急ぎ」を、最初からテンプレ化しておくと速い。

(5) 「スピード優先か品質優先か」を1語で選べるように

　例）優先：スピード／品質（迷ったらスピード）。

　→ level3みたいな数字より、日本語で速さと丁寧さのどっちかを選ぶ方が初心者は判断しやすい。

(6) プロンプトを「モード指示」と「今回やること」の2段に分ける

　→ CC(...)の呪文は"同じ動き方の設定"、その下に"今回の依頼内容（例：遊戯王の高騰カードまとめを作って）"を日本語で書く、と2段構成にすると、初心者でも下段だけ書き換えれば回せる。

ひとことまとめ：

呪文プロンプトは「速い」けど「読めない」。次の人は、最初に用語対訳・出力形式・データ前提・モックかどうか・速さ優先かを日本語で1回だけ足しておくと、詰まらずに表（サイト）と裏（管理画面）まで一気に作れます。

【① やった課題】

• 1-1：オリジナルのシューティングゲーム（単一HTML）を作る
• 1-2：ホームページ制作（DESIGN.md → 美学プロンプト適用 → セクション単位で実装、白ベース・文字大きめ）
• 1-3：そのHPの「裏側システム」を仕様駆動で作る（SPEC.md → システム図解PNG → 動く管理アプリ）
• 1-4：この振り返りフィードバックをまとめる

どれも「1メッセージ投げる → 数分で動くものが出てくる → ブラウザで即確認」の流れで、成果物が目に見えるのが気持ちよかったです。

【② 想定外だったこと】

＜スムーズだった所＞

• とにかく完成が速い。ゲームもHPも1往復で「遊べる/見られる」状態まで来る。
• 作る前に DESIGN.md / SPEC.md という「設計書」を先に出してくれるので、いきなりコードが吐かれるより安心。方針を先に合意できる。
• 「白ベース」「文字大きめ」みたいなふわっとした指定でも、ちゃんと汲んでくれた。
• 完成後に勝手にブラウザで開いてくれるので、確認の手間がない。

＜詰まった所・分かりにくかった所＞

• プロンプトの「略語詰め込み」が最初まったく読めなかった。

例：CC(goal/Mon/batch/Plan/Hook/Rule/Skill/Flow/allow/Mem/sec/task/Team/rw/rev=cr+sr/Ultra) や、STORE_KEY昇格・3層振分・承認段階ゲート引継型・A2A・FO(fan-out)・cr+sr・confirm禁止 など。

→ 動くものは出るが、「自分が何を頼んだのか」を後から説明できない。人に共有しづらい。

• [ ]の空欄プレースホルダ問題。HP課題で「例：原宿の…スイーツ店」の[ ]を埋め忘れて送ったら、AI側から「テーマは何にしますか？」と聞き返しが入った（結果的に正しい挙動だが、一瞬止まる）。テンプレの[ ]は必ず埋めてから送るべき。
• 出力先の指定が無いと、ファイル名やフォルダがAI任せになる（index.html / ops.html など）。どこに何が出来たか把握しづらい。
• 画像(PNG)まわりで内部的に一度エラーが起きていた（プロジェクト直下に書き込めず、一時フォルダ経由で回避）。最終的には出たが、環境によってはPNG生成でつまずく可能性がある。
• 「仕様駆動MVP=level3」の“level3”が何を指すか、事前に定義が無いと人によって解釈がぶれる。

【③ 最初のコピペ用プロンプトへの具体的な改善案】

略語は「初回だけ日本語で1行注釈」を付ける

悪い例：CC(goal/Mon/batch/...rev=cr+sr/Ultra)最適選択

良い例：「使う機能はあなたが最適に選んでOK（例：計画立て/タスク分割/レビュー=コード+セキュリティ）。選んだ理由も一言添えて」

→ 初学者でも意図が読め、共有・再利用できる。

[ ]プレースホルダは「送信前チェック」を促す一文を入れる

追記例：「※[ ]内を必ず具体的な内容に置き換えてから送信」

これだけで聞き返しの往復が1回減る。

出力の「置き場所と名前」を先に指定する

追記例：「成果物は ./output/ 配下に保存。ファイル名は task1-1_game.html のように課題番号を付ける」

→ 後から見返しやすく、課題ごとの区別が付く。

専門っぽい要件は「一言の目的」をセットにする

悪い例：100点+3層振分・承認段階ゲート引継型

良い例：「申込を100点で採点し、点数で3グループ（自動OK/要確認/要相談）に自動仕分け。要確認以上は担当を引き継ぎながら承認していく仕組み。※理由も添えて」

→ 何を作りたいかがAIにも人にも伝わり、ズレが減る。

「level」や「規模感」は自分の言葉で定義を添える

追記例：「＝実際に触って動かせる試作品レベル。凝った作り込みまで」

曖昧語は必ず補足を1行。

「急ぎ」と「作り込み」は両立しないことがあるので優先順位を明示

追記例：「まず動くイメージ優先。細部の調整は後回しでOK」

→ AIが速度と品質のどちらに寄せるか迷わない。

【まとめ・次にやる人へ一言】

• 成果物のスピードと“設計書を先に出す流れ”は本当に良い。まず1-1のゲームで「1往復で動く」体験をすると一気に掴める。
• つまずくのは中身ではなく「プロンプトの書き方」。略語を減らし、[ ]を埋め、出力先を決める——この3点を守るだけで、初回からかなり快適になります。

━━━━━━━━…

Claude Codeをはじめる（課題1-1〜1-4）やってみた感想

── 次にやる人へのフィードバック ──

━━━━━━━━…

■ ① やった課題（何をしたか）

1-1〜1-3：ホームページ制作の一連の流れ

• DESIGN.md（デザイン仕様書）を作る
• Claude Cookbookの「美学プロンプト」を適用する
• セクション単位でHTMLを実装する

→ お題は「白ベース・文字大きめ」の店舗サイト。

自分は珈琲店の題材でやりました。

1-4：作ったHPの“裏側”の業務システムを作る

• 仕様駆動MVP（5タブ／100点スコア＋3層振分／

承認ゲート／モーダル／localStorage保存）

• アーキ図のPNGと、動くHTMLを1ファイルで出力

→ 「サービス連携はなしで、まずイメージを見たい」

という前提のモック作成。

いずれも “プロンプトを1回貼るだけ” で、

仕様書→実装→ブラウザ表示まで一気に進みました。

■ ② 想定外だったこと

＜詰まった所＞

• お手本プロンプトの末尾に

「[例：原宿の…スイーツのお店]」という【例】が

そのまま残っていて、書き換えずに貼ってしまった。

→ Claudeが「実際は何のお店ですか？」と質問返し。

一発で進まず、1往復ワンクッション入った。

※ここは“例文を自分の内容に置き換える”のが

暗黙の前提だった、と後で気づいた。

• 出力ファイルがどこに置かれるか最初は不明。

気づいたら hp-kenken/ フォルダに一式できていた。

「どこに作られるか」を意識しておくと安心。

＜分かりにくかった言葉＞

• 1行目の呪文みたいな指定

「CC(goal/Mon/batch/Plan/Hook/…/rev=cr+sr/Ultra)

最適選択→…」が、初見だと意味を追えない。

• 1-4の「100点＋3層振分」「承認段階ゲート引継型」

「STORE_KEY昇格」「confirm禁止」「🤖pt」「A2A」

「ckpt」あたりも略語・専門語で、

“何が出てくるか”をイメージしづらかった。

→ 結果物を見て初めて「あ、こういう意味か」と理解。

＜逆にスムーズだった所＞

• お店の内容さえ決まれば、あとは非常に速い。

DESIGN.md → 美学ドキュメント → HTML → 図PNG →

ブラウザ自動オープン、まで待つだけ。

• 「白ベース・文字大きめ」という短い指定でも、

余白・大きい見出し・1色アクセントで

“それっぽく整った”デザインが出た。

• 図解PNGもちゃんと画像で出てきた（想像以上）。
• 途中で作業が何ステップに分かれているか

説明しながら進むので、放置でも迷子にならない。

■ ③ 最初のコピペ用プロンプトへの改善案

（1）例文の【例】は必ず自分の内容に書き換える／消す

• 角カッコの例をそのまま貼らない。
• 改善版イメージ：

「作りたいサイト：〈自分の店名・業種を1行で〉」

と、埋める欄だと分かる形にしておくと親切。

• 迷う点（サイトの目的・対象）を先に1行入れておくと

質問返しがなくなり、一発で走る。

（2）1行目の“略語プロンプト”に和訳の注釈を添える

• 次の人向けに、略語の意味を1行メモで併記する。

例：rev=レビュー(コード+セキュリティ) /

A2A=サブエージェント分担 /

ckpt=危険操作前のバックアップ

• 意味が分かれば「これは今回いらない」と

取捨選択もしやすい。

（3）出力先フォルダを明記する

• 「◯◯フォルダに一式作成して」と書いておくと、

どこにできたか探さずに済む。

（4）1-4の専門語は“ひとこと補足”をつける

• 「100点＋3層振分（＝注文を点数化してA/B/Cに

自動仕分け）」のように、

略語のあとにカッコで日本語補足を足すと、

完成物の想像がつきやすい。

（5）環境の前提を1行足す

• 図解PNGはMac標準機能で変換されて出ました。

環境によっては画像化ツールが要る場合があるので、

「PNGが出なければSVGでOK」等の逃げ道を

書いておくと安心。

■ ひとことまとめ

「例文を自分の内容に置き換える」ことと、

「略語の意味をなんとなく掴んでおく」ことさえ

押さえれば、あとはかなり快適に進みます。

最初の1回だけ内容を具体的に書くのが、

スムーズに走らせる一番のコツでした。

━━━━━━━━…

━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Claude Code 作業フィードバック（2タスク分）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■ 対象タスク

　A：HTMLシューティングゲーム制作

　B：零細商社のコーポレートサイト（叩き台）制作

────────────────────────────

① やった課題

────────────────────────────

【A：シューティングゲーム】

• 単一HTMLファイル（外部アセットゼロ）で縦スクロールSTGを実装。
• 敵4種（挙動別AI）、5ウェーブ毎のボス戦（3種弾幕パターン）、パワーアップ4種、スコア倍率、ボム、溜め撃ちを搭載。
• 演出面：画面シェイク／フラッシュ／パーティクル爆発／星の視差スクロール／WebAudioでの効果音リアルタイム合成。
• ハイスコアをlocalStorageに保存。完成後ブラウザで自動オープン。

【B：コーポレートサイト】

• 指定3ステップで実行：(1) DESIGN.md作成 → (2) 美学原則をDESIGN.mdに明文化 → (3) セクション単位でindex.html実装。
• 3事業（①日英翻訳／②輸出入／③輸出入コンサル）をカード＋詳細帯で構成。
• 要望反映：白ベース・文字大きめ（本文18px）・アクセント1色。社名/数値はダミー化し「【要差し替え】」で明示。
• レスポンシブ、控えめなフェードインまで実装しブラウザで確認。

────────────────────────────

② 想定外だったこと

────────────────────────────

▼ スムーズだった所

• 両タスクとも「単一HTMLで完結」という制約が明確で、環境構築ゼロ・即ブラウザ確認まで一直線に進められた。
• Bの「DESIGN.md→セクション単位」という進め方の指定が秀逸。設計を先に固めたので実装がブレず、手戻りゼロ。この段取り指定は理想的でした。
• 「白ベース・文字大きめ」という具体的な見た目指定があり、判断に迷わなかった。

▼ 詰まった／曖昧だった所

• A「超作り込んだオリジナリティのある」→「超」「作り込み」「オリジナリティ」がどれも主観的で、どこまでやれば満点かの基準が無い。こちらで機能を盛る方向に振ったが、正解が見えないまま作った感覚。分量・時間の上限も不明だった。
• A ジャンル/世界観/操作系（キーボードかマウスか、スマホ対応要否）が未指定。全部こちらで決め打ちした。
• B 冒頭の「CC(goal/Mon/batch/Plan/Hook/Rule/Skill/Flow/allow/Mem/sec/task/Team/rw/rev=cr+sr/Ultra)最適選択→…」の記号羅列が最も解読コストが高かった。意図（＝Claude Codeの各機能から最適なものを選び、fan-outやレビューを状況に応じて使え、という運用方針）は汲めたが、独自略語のため確信が持てない部分があった。特に「rw」「A2A」「Team」は文脈からの推測。
• B 「Claude Cookbookの美学プロンプト」＝特定の公式プロンプトを指すのか、Anthropic流の美的原則一般を指すのか曖昧。後者と解釈してDESIGN.mdに原則として明文化したが、意図した特定物と違う可能性あり。
• B 会社の実在情報（社名・所在地・実績）が無く、全てダミー化。叩き台なら妥当だが、社名だけでも欲しかった（「カケハシ」はこちらの創作）。

▼ 分かりにくかった言葉（両タスク共通）

• 「サイトOpen」→ローカルファイルをブラウザで開く意味と解釈（合っていたはず）。デプロイ公開ではない前提で進めた。
• 略語圏（rev=cr+sr 等）は一度読み解けば有用だが、初見の解読に時間がかかる。

────────────────────────────

③ 最初のコピペ用プロンプトへの改善案

────────────────────────────

【共通】

• 独自略語ブロックは「凡例」を1回どこかに定義するか、通常の日本語に開くと解読コストが激減します。例：「rev=cr+sr」→「レビューはcode-reviewとsecurity-reviewを状況に応じて」。使い回すなら別途「用語定義スニペット」を用意し先頭に貼る運用が◎。
• 「完成の定義」を1行入れると迷いが消えます。例：「単一HTMLで完結／ブラウザでローカル表示できればOK/NG」。

【A：ゲーム（改善版プロンプト例）】

────────────

HTML単一ファイルで縦スクロールのシューティングゲームを作って。

• 操作：キーボード＋マウス両対応、スマホは任意
• 要素：敵複数種＋ボス＋パワーアップ＋スコア＋効果音
• 世界観：ネオン/宇宙（任意でOK）
• 完成後ローカルでブラウザ起動して見せて
• 分量：機能盛り気味で1ファイルに収まる範囲

────────────

ポイント：主観語（超/オリジナリティ）の代わりに「入れてほしい要素」を箇条書きにすると、期待とのズレが無くなります。世界観は「任せる」と明示するとこちらも動きやすいです。

【B：サイト（改善版プロンプト例）】

────────────

零細商社のコーポレートサイト叩き台を作成。

■進め方：1)DESIGN.md作成 2)白ベース/文字大きめ/アクセント1色の方針をDESIGN.mdに明記 3)index.htmlをセクション単位で実装

■事業3本：①日英翻訳 ②輸出入（自社商品＋他社受託）③輸出入コンサル

■社名：【あれば指定／無ければ仮でOK】

■トーン：親しみ寄り／硬派・格調高い（どちらか選択）

■未確定情報はダミー化し「要差し替え」と明示

────────────

ポイント：今回良かった「DESIGN.md→セクション実装」の段取りはそのまま踏襲を推奨。加えて(a)社名の有無、(b)文章トーン（親しみ⇔硬派）、(c)公開までやるか（ローカル止まりか）の3点を最初に一言添えると、こちらの決め打ち箇所が無くなり一発で狙い通りになります。「Cookbookの美学プロンプト」は、特定物を指すなら該当リンク/本文を貼ると確実です。

────────────────────────────

総括

────────────────────────────

• Bの「設計書ファースト＋セクション分割」の指定は非常に効果的。今後の制作系タスクの型として推奨します。
• 最大の改善ポイントは2つ。(1) 主観的な品質表現を「入れる要素の箇条書き」に置換、(2) 独自略語に凡例を付けるか平文化。この2点で、こちらの推測・決め打ちがほぼ消え、1回で意図通りに着地しやすくなります。

以下、そのままコピペして使えるテキストです。

• --

【フィードバック】Claude Codeをはじめる（課題1-1〜1-4）をやってみて

■ 総評

初めてでも「指示 → 数分で動くもの／画像が出てくる」体験ができて、達成感が大きい課題でした。つまずいたのは"作業そのもの"より、最初に渡されるコピペ用プロンプトの記号・略語の意味でした。ここさえ乗り越えれば一気に進みます。次にやる人は「最初のプロンプトの読み方」を先に知っておくと、体感の難易度がかなり下がると思います。

──────────────────

■ ① やった課題（自分がやったこと）

• 課題1-1：運用ルールが書かれた"コピペ用プロンプト"と、お店（飯塚市のシニア向けスマホ・パソコン教室）の情報を貼り付けてスタート。
• 課題1-2：ホームページのデザイン。「DESIGN.md（設計メモ）を作る → 美学ルールを当てる → セクションごとに実装」という流れで、白ベース・文字大きめのLPが1枚完成。
• 課題1-3：そのHPの"裏側システム"の仕様を提示。5タブ／100点の自動スコアリング／3層振り分け／承認ゲート型のワークフロー…といった条件を渡す。
• 課題1-4：システム本体（単一HTML）＋仕組みの図解PNGが生成され、最後にブラウザで自動オープンされて完成を確認。

→ 成果物は「設計メモ・HP・管理システム・図解画像」の4点。手を動かした実感がありつつ、実際のコーディングはほぼ自動、という配分でした。

──────────────────

■ ② 想定外だったこと

●詰まった所

• 最初のプロンプトが記号の羅列（例：「CC(goal/Mon/batch/…)」「rev=cr+sr」「中規模A2A→open」）で、何を指示しているのか初見でまったく読めない。動くけれど「自分が何を頼んだのか」が分からないまま進む不安がありました。
• 「これで合っているのか」を確認するタイミングが分からず、完成して初めて中身を理解した、という順番になりがち。

●分かりにくかった言葉（次の人向けの用語メモ）

• A2A … 複数のAIエージェントで手分けする指示。今回の規模では使わず1人で進んでOK、の意味だった。
• ckpt（チェックポイント）… 危険な操作の前に一旦保存/確認すること。
• 承認段階ゲート引継型 … 「1工程ずつ承認して次の担当に渡す」ワークフローのこと。日本語でもピンと来づらい。
• STORE_KEY昇格 … データ保存名にバージョンを付け、古い版を自動で新版へ移行する仕組み。
• 🤖pt … 各画面に「AIのおすすめ表示」を置くこと。
• 100点＋3層振分 … 問い合わせを100点で自動採点し、S/A/Bの3ランクに仕分ける機能。

※これらは"専門用語"というより"略語"で、意味さえ分かれば難しくないものばかりでした。

●逆にスムーズだった所

• 「白ベース」「文字大きめ」「シニア向け」のような普通の日本語の要望は一発で正確に反映された。無理に記号化しなくても伝わる。
• ファイルを作るとその場でプレビューに出る／最後に勝手にブラウザで開く、など"結果がすぐ目に見える"のが気持ちよく、迷子になりにくい。
• 図解PNGや料金表など、頼んだものが具体物としてポンと出てくるので、初心者でも「進んでいる感」が途切れない。
• 「急ぎで！」「凄いと思えるものに」のようなニュアンスの指定もちゃんと汲んでくれた。

──────────────────

■ ③ 最初のコピペ用プロンプトへの改善案（具体）

ねらい：動作は今のままでも良いが、「初めての人が意味を読める」状態にするだけで安心感が段違いになります。

1) 略語に"ひとこと注釈"を添える

　現状：`rev=cr+sr／中規模A2A／ckpt`

　改善：`レビュー（コード＋セキュリティ）／必要なら複数AIで分担／危険操作の前に確認`

　→ 記号は残してもいいので、初回だけ日本語の言い換えを併記。

2) 冒頭に「これは"運用ルール"です」の一行を足す

　例：「※次の1行は"進め方のルール"です。内容は変えず貼り付けてください。分からない用語があってもそのままでOK」

　→ "呪文"の正体が分かるだけで、初心者の心理的ハードルが大きく下がる。

3) 変数（お店情報）を穴埋め式テンプレにする

　改善例：

　　■ お店情報（ここだけ書き換え）

• 店名：〇〇
• 場所：〇〇
• 対象／特徴：〇〇
• 作ってほしいもの：HP / 裏側システム（どちらか）

　→ どこを自分用に直すのかが一目で分かる。今は指示と情報が地続きで境界が見えづらい。

4) 「途中で一度見せて」を選べるようにする

　例：「①一気に完成／②設計メモの段階で一度止めて確認、を選べます（初めての方は②推奨）」

　→ 完成後に初めて中身を理解する、という順番を避けられる。

5) 専門語は"日本語＋（英語略）"の順に

　例：「承認ゲート型ワークフロー（1工程ずつ承認して次へ引き継ぐ）」

　→ 意味が先、略語が後。読み手の負担が減る。

──────────────────

■ 次にやる人へ ひとこと

記号だらけの最初の一文にひるまないでください。あれは"進め方のルール"で、意味が分からなくてもそのまま貼れば動きます。大事なのは「何を・誰向けに・どんな見た目で」を普通の日本語で足すこと。そこだけ丁寧に書けば、驚くほど良いものが返ってきます。まずは小さく頼んで、出てきたものを見てから直す——この往復がいちばんの近道でした。

• --

以上です（約2,900字）。文言の調整やトーン変更（より短く／堅め／砕けた表現）も対応できます。

【Claude Codeをはじめる（課題1-1〜1-4）をやってみた感想フィードバック】

■ ① やった課題（何を作ったか）

• 課題1-1：最初のプロンプトを打って、Claude Codeに「動くもの」を1つ作らせてみる（HTMLのシューティングゲーム）。
• 課題1-2：ホームページを1枚作る。いきなり作らせず「DESIGN.md（設計書）」を先に書かせてから、セクションごとに組み立てる流れ。
• 課題1-3：そのホームページの“裏側”にあたる管理システム（業務効率化ツールのモック）を作る。仕様を短くまとめたプロンプトから、5タブの管理画面まで一気に生成。
• 課題1-4：やってみた感想を、次の人向けフィードバックとしてまとめる（＝今これ）。

全体を通して「指示する→出てくる→ブラウザで確認する→直してもらう」を繰り返すのが基本の型だと体感できました。

■ ② 想定外だったこと（詰まった所・分かりにくかった言葉・逆にスムーズだった所）

＜想定外だった＞

• 最初のゲームが、一発では動かなかった。パッと見それらしいコードが出てくるので「もう完成」と思い込みがちですが、実際に開いたら真っ暗で動かず。原因はプログラムの単純なミス（同じ名前を二重に定義していた）でした。→ ここで学びだったのは、「動かないよ」とひと言送るだけで、原因を自分で調べて直してくれること。エラーを自分で読めなくても大丈夫でした。“完成”と言われても、必ず自分の目で開いて確認する、が鉄則。

• 「例：〇〇」と書いてある穴埋めプロンプトで、その例をそのまま使うのか・自分の題材に差し替えるのかが曖昧で、一度確認が入りました。→ 例はあくまで見本。自分がやりたい内容に置き換える前提だと分かっていれば、最初から題材を書けてスムーズでした。

• 題材（今回はパソコン教室）を伝えるとき、「業種・店名・ウリ」くらいの箇条書きでも、ちゃんと中身（キャッチコピー・料金プラン・お客様の声など）まで肉付けして作ってくれた。“細かく指定しなきゃ”と身構えていたので、ここは良い意味で想定外。

＜分かりにくかった言葉＞

• プロンプトに出てくる略語・記号（例：「MVP」「localStorage」「モーダル」「STORE_KEY」など）が初見だと意味不明。動きはしますが、「今なにが起きたのか」が分からないまま進む場面がありました。→ 用語は“おまじない”として置いておいてもモノは作れますが、後で一つずつ意味を知ると納得感が段違いです。

• 記号を詰め込んだ超短縮プロンプト（スラッシュ区切りで指示を並べる書き方）は、上級者向けの時短術。ちゃんと伝わって動きましたが、初心者が最初に真似すると「何を指示したか自分でも分からない」状態になりがち。最初は多少長くても“ふつうの日本語の文章”で書くのがおすすめです。

＜逆にスムーズだった所＞

• 「作って」→「ブラウザで開いて」までを一気にお願いできる。自分でファイルを探して開く手間がなく、すぐ結果が見られる。
• 「設計書を先に書いて」と頼むと、色・文字サイズ・構成を言葉で先に決めてくれるので、いきなり作らせるより仕上がりの方向性がブレない。課題1-2のこの流れは特に良かった。
• 修正指示が会話で通じる。「文字を大きく」「白ベースで」程度のざっくり指示でちゃんと反映される。専門用語を知らなくても会話で軌道修正できる。

■ ③ 最初のコピペ用プロンプトへの具体的な改善案

（次にやる人が、最初のプロンプトでつまずかないための提案）

「例：」の扱いを1行で明記する

　現状：［作りたい内容　例：〇〇］とだけ書いてある。

　改善：「※［　］内はあなたの作りたい題材に書き換えてください。思いつかない人だけ例をそのまま使ってOK」の一文を添える。→ 差し替え／流用の迷いがなくなる。

「完成したら必ず自分で開いて確認」を手順に組み込む

　現状：作って終わり、の書き方に見える。

　改善：プロンプト末尾に「完成したらブラウザで開いて。もし動かなかったら私が『動かない』と伝えるので直して」と入れておく。→ 一発で動かない前提を最初から共有でき、詰まっても慌てない。

最初の1回は“ふつうの日本語”で書くよう案内する

　現状：略語・記号を並べた短縮プロンプトが見本になっている箇所がある。

　改善：初回テンプレは「何を・誰向けに・どんな雰囲気で・白ベースで文字大きめ、みたいに“普通の文章”で書けばOK。記号だらけの短い書き方は慣れてからで大丈夫」と補足。→ 心理的ハードルが下がる。

専門用語に“ふりがな”をつける

　改善：プロンプト内やテキストに出る用語へ、初回だけ超ミニ解説を添える。

　例：localStorage（＝ブラウザにデータを保存する仕組み）／モーダル（＝画面の上に出る確認ウィンドウ）／MVP（＝まず最小限で動く試作）。→ 「おまじない」で終わらせず理解につながる。

「まず設計書 → 次に本体」の順番を最初の課題から推奨に

　改善：1-2で効果を感じた“設計書ファースト”を、最初のテンプレにも「いきなり作らず、先に『どんな構成にする？』を出してもらうと失敗が減る」と一言入れておく。→ 手戻りが減る。

保存場所を最初に指定する欄を作る

　改善：「どのフォルダに作る？」を最初に決める一行を用意（例：デスクトップの〇〇フォルダ）。→ 後で「作ったファイルどこ？」を防げる。

■ ひとことまとめ

「思ったより簡単に“動くもの”が出てくる。でも一発で完璧ではない」——ここが最大の学び。完成品を鵜呑みにせず、自分の目で開いて、ダメなら会話で直す。この往復に慣れれば、専門知識ゼロでもかなり作れます。最初のプロンプトは“普通の日本語＋題材を自分の言葉で”がいちばん失敗しません。

以下、そのままコピペできるテキストです（約2,900字）。

• --

# Claude Codeをはじめる（課題1-1〜1-4）やってみた感想・次の人へのフィードバック

① やった課題（何を作ったか）

• 課題1-1：HTMLシューティングゲーム作成

「オリジナリティのある作り込んだシューティングを」と依頼。単一HTMLで、色を切り替えて同色の敵に大ダメージを与える独自システムのゲームができた。完成後は自動でブラウザが開いた。

• 課題1-2：ホームページのデザイン

「DESIGN.md作成 → 美学プロンプト適用 → セクション単位で実装」という流れを指定。長野県の温泉紹介ページ（地図・効能・お勧め度）を、白ベース・文字大きめで作成。

• 課題1-3：裏側システムの作成

1-2のHPを運用する管理ツール（品質を100点採点して3層に振り分け、承認フローで公開まで進める業務ツール）を、単一HTML＋localStorageのモックとして作成。構成図もPNGで出力された。

• 課題1-4：このフィードバックまとめ（＝今これ）

全体を通して「作って」と伝えるだけで、ファイル作成→実装→ブラウザ起動まで一気に進むのが体験の中心。

② 想定外だったこと

■ スムーズで感動した所

• 指示がざっくりでも形になる。 「凄いと思うゲーム作って」レベルの曖昧な指示でも、勝手に仕様を決めて完成品を出してくれた。最初の一歩のハードルが低い。
• 完成後にブラウザが自動で開く。 「どこにファイルができた？」と探す手間がなく、成果がすぐ目に見えるのがうれしい。
• 修正のスピード感。 バグや色の指定ミスがあっても、その場で直して再表示まで一瞬。手戻りのストレスがない。
• 成果物が分解されて出る。 DESIGN.md（設計）→ HTML（実装）→ PNG（図解）と、順序立てて出てくるので流れが追いやすい。

■ 詰まった所・分かりにくかった所

• 呪文のような記号だらけのプロンプトが怖い。 課題で渡された最初のコピペ用プロンプトが

`CC(goal/Mon/batch/Plan/Hook/Rule/Skill/Flow/allow/Mem/sec/task/Team/rw/rev=cr+sr/Ultra)…`

や `仕様駆動MVP=level3. out:図解PNG+動くHTML単一…` のような超圧縮表記で、初見では何を指示しているのか全く読めなかった。 動きはするが「自分が何を頼んだのか分からないまま完成した」感覚が残る。

• 専門用語が説明なしで出てくる。 「A2A」「STORE_KEY昇格」「承認段階ゲート引継型」「3層振分」「🤖pt」など、意味を知らないと妥当性を判断できない言葉が多い。結果は良くても、初心者は“合っているのか確認できない”。
• 「level3」「中規模」などの数値・規模感の基準が不明。 どこまで作り込まれるかが事前に読めず、出てくるまで規模が分からない。
• 成果物の保存場所を後から探しにくい。 自動で開くのは便利な反面、フルパス（例：`C:\Users\...\nagano-onsen\console.html`）は結果メッセージの中を読まないと分からず、次に自分で開き直すとき迷う。
• 「例：〜」の扱いが曖昧。 テーマ指定が「例：長野県の温泉…」という書き方で、例なのか本指示なのかが一瞬迷った（結果的に本指示として作られた）。

③ 最初のコピペ用プロンプトへの具体的な改善案

要点：記号圧縮をやめ、初心者でも読める「日本語の箇条書き」に置き換える。

改善案A：呪文表記を、目的ベースの平文にする

• Before：`CC(goal/Mon/batch/Plan/Hook/…/Ultra)最適選択→batch/Flow FO→…`
• After（例）：

```

次の順番で進めてください。

1. 何を作るか要点を1〜2行で確認

2. 設計（DESIGN.md）を先に作る

3. セクション単位で実装

4. 完成したらブラウザで開き、保存先パスを教える

```

→ やることが日本語で読めるだけで、初心者の安心感が段違い。

改善案B：専門用語には必ず1行の補足を付ける

• 例：`3層振分（=品質を上・中・下の3ランクに分けること）`

`承認ゲート（=一定品質を満たさないと次工程に進めない仕組み）`

• 用語集を課題の冒頭に3〜4行付けるだけでも脱落者が減る。

改善案C：「例」と「本指示」を明確に分ける欄にする

• Before：`[…例：長野県の温泉マップ…]`
• After：

```

▼作りたいテーマ（ここを自分の言葉で書き換えてください）

例）長野県の温泉マップと効能の紹介ページ

→ あなたの入力：＿＿＿＿＿

```

改善案D：完成条件を最初に明記させる

• 「完成したら①ブラウザで開く ②保存先フルパスを表示 ③3行で成果を要約」など、アウトプットの締め方をテンプレ化しておくと、の結果がそろって振り返りやすい。

改善案E：規模の目安を言葉で示す

• 「level3」ではなく「A4・1画面程度／しっかり作り込み（複数機能）」のように、完成イメージを言葉で書くと期待値がズレない。

• --

総評： 「とりあえず作って」で本当に動くものが出る体験は非常に良い。一方で、配布プロンプトの“圧縮呪文”が初心者にとって最大の壁。平文化・用語補足・例と本指示の分離の3点を直すだけで、次の人はぐっと迷わず進めるはず。

Claude Code をはじめる（課題1-1〜1-4）やってみた感想・次の人へのフィードバック

① やったこと（課題の流れ）

1-1 準備・現状把握：作業フォルダを開いて既存ファイルを確認。→ ここで「既存の index.html が実は別物（今回はシューティングゲーム）だった」という発見があり、いきなり上書きせずに済んだ。最初の一歩として重要。

1-2 ホームページ制作：「①DESIGN.md 作成 → ②美学プロンプト適用 → ③セクション単位で実装」の3ステップで、白ベース・文字大きめの1枚もの HTML を作成。設計→実装の順で進むと迷わない。

1-3 裏側システム（仕様駆動MVP）：HP の裏側として、申請を100点で自動採点し3層に振り分け→段階承認する管理ツールを、動く単一HTML＋構成図PNGで作成。localStorage保存・モーダル・タブUIまで一気に。

1-4 振り返り（この文章）：やってみた感想を次の人向けにまとめ。

所感：一番効いたのは「いきなり作らせず、先に DESIGN.md（設計書）を書かせる」こと。方針が言語化されるので、実装のブレが激減する。次にやる人にも最初に設計書を作る流れを強く勧めたい。

② 想定外だったこと

詰まった／ヒヤッとした所

既存ファイルの上書きリスク：フォルダに前の作業（別プロジェクト）が残っていると、Claude が同名 index.html に上書きしかねない。今回は事前確認で回避できたが、指示に「上書き禁止・別名で作って」と書いておくべきだった。

プロンプト内の [ ] 例がそのまま残っていた：「例：原宿の…スイーツ店」というテンプレの穴埋め欄を埋め忘れると、Claude が「題材はどれ？」と確認で一手止まる。急ぎのときはこの確認が地味にロスになる。

環境依存の作業（PNG生成）：構成図を PNG で出す工程で、画像ライブラリ（Pillow）を追加インストールする必要があった。マシンによって有無が違うので、「PNGが無理ならSVGでOK」など逃げ道を書いておくと止まらない。

分かりにくかった言葉

略語・記号が多い指示（A2A / STORE_KEY昇格 / 3層振分 / spec駆動MVP=level3 / rev=cr+sr など）は、慣れていないと何を求められているか読み取れない。Claude は解釈してくれるが、人間側（レビューする自分）が仕様を理解できないのが困りどころ。専門用語は初回だけでも日本語の一言説明を添えたい。

「美学プロンプト」も、何を指すか最初ピンとこなかった。「＝デザインの品質ルール（余白・文字サイズ・色数を絞る等）」と補足があると親切。

逆にスムーズだった所

3ステップに区切った指示（設計→適用→実装）は非常にスムーズ。工程が見えるので途中経過も追いやすい。

「白ベース・文字大きめ」のような具体的な見た目の条件は、あるだけで仕上がりが一気に安定する。抽象的な「オシャレに」より断然効く。

「モックでOK・連携なし・イメージ優先・急ぎ」と割り切りを明言したこと。おかげで余計な作り込みで止まらず、動くものが早く出た。

完成後に自動でブラウザを開く指示は、結果確認が速くて気持ちよかった。

③ 最初のコピペ用プロンプトへの改善案

そのまま真似できるよう、追記すべき文を具体化しました。

1. 穴埋め欄は「必ず埋める」注意書きを付ける

例：[題材をここに書く（未記入なら質問して）]

[ ] を空のまま送ると確認で止まるので、記入前提だと分かる書き方にする。

2. 上書き防止を1行入れる

「既存ファイルは上書きせず、新規は分かりやすい別名（例：project-name.html）で作成して。既存に重要ファイルがあれば先に知らせて。」

事故防止＆Claudeが最初にフォルダ確認してくれる。

3. 専門用語・略語には初回だけ日本語注釈

例：「3層振分（＝A/B/Cの3段階に自動仕分け）」「STORE_KEY昇格（＝保存データの旧バージョンを新形式へ自動移行）」

自分が後でレビューできるように、人間向けの説明を残す。

4. 環境が絡む工程に逃げ道を用意

「PNG生成が難しい環境ならSVGや画面キャプチャで代替可。止まらず進めて。」

ツール未導入でつまずかない。

5. 完成条件（Doneの定義）を先に書く

「完成＝①動くHTMLが開ける ②主要ボタンが押せる ③ブラウザで表示、まで確認できたら報告して。」

「どこまでやれば終わりか」が明確になり、報告もブレない。

6. 最初に設計書を必ず作らせる（これは残す価値大）

「実装前に DESIGN.md（狙い・配色・文字サイズ・構成）を作り、方針を1回見せてから実装に進んで。」

一番の時短ポイント。丸ごと踏襲を推奨。

まとめの一言：「設計→実装の3ステップ」「具体的な見た目条件」「モック割り切り」の3つが今回の成功要因。逆に次の人がハマりやすいのは「既存ファイル上書き」「穴埋め欄の空欄」「略語の意味」の3つ。ここに一言ずつ足すだけで、初回からかなり滑らかに進みます。

以下、そのままコピペで使えるテキストです。

• --

【フィードバック】Claude Codeをはじめる（課題1-1〜1-4）をやってみて

■ はじめに

実際に課題1-1〜1-4を通してやってみたので、これから取り組む人向けに「つまずいた所・分かりにくかった言葉・逆にラクだった所」と、最初に渡されるコピペ用プロンプトへの改善案をまとめます。結論から言うと、ちゃんと形になるものは作れます。ただ最初のプロンプトが呪文みたいで、そこで一瞬ひるみました。

────────────────────

① やった課題（何をしたか）

────────────────────

テーマは「AIを使ったInstagram運用の自動化スクール」のホームページ制作。流れは次の4ステップでした。

• 課題1-1：DESIGN.md（デザインの設計図）を作る
• 課題1-2：Claude Cookbookの「美学プロンプト」を適用する（白ベース・文字大きめ、などの方針決め）
• 課題1-3：Claude Codeでセクション単位にサイトを作っていく
• 課題1-4：出来上がりを確認して仕上げる

最終的に、DESIGN.md（仕様書）と index.html（1ファイル完結のLP）の2つが手元に残りました。ヘッダー／ヒーロー／悩み／解決／特徴／カリキュラム／受講生の声／料金／FAQ／CTA／フッターまで一通り入った、それっぽいランディングページが1回でできます。

────────────────────

② 想定外だったこと

────────────────────

▼ 詰まった所・分かりにくかった言葉

1. 最初のコピペ用プロンプトが「暗号」に見える

　冒頭が「CC(goal/Mon/batch/Plan/Hook/Rule/Skill/Flow/allow/Mem/sec/task/Team/rw/rev=cr+sr/Ultra)最適選択→…」という圧縮された記号の羅列で、初見だと何を求められているのか全く読めませんでした。これはClaude側への「動き方の指示」で、自分が理解して打ち込む必要はない、と分かるまでが一番のハードルでした。

2. カタカナ略語・専門語がノーヒントで出てくる

• DESIGN.md … 「マークダウンで書く設計メモ」のこと。拡張子 .md にビビる。
• 美学プロンプト（Aesthetic Prompt）… 「見た目をキレイにするための指示テンプレ」くらいの意味。Cookbookという単語も「Anthropicが公開してるレシピ集」と知らないと迷子になる。
• セクション単位 … サイトを「上から順のブロックごと」に作る、という意味。
• ヒーロー（Hero）… 一番上の大きな見出しエリアのこと。Web用語を知らないと「？」となる。

　これらは知ってる人には当たり前でも、初学者には都度つまずくポイントでした。

3. 「白ベース・文字大きめ」の解釈が人まかせ

　指示はシンプルですが、実際にどれくらい大きいのか、どこにアクセント色を使うのかはClaude任せ。結果は良かったものの、「思ってたのと違ったらどう直す？」の一言が最初にほしかったです。

4. 完成物のプレビューの見方が最初わからない

　ファイルはできたのに「で、これどこで見るの？」となりました。プレビューパネルに出る／index.htmlをダブルクリックで開ける、と一言あるだけで安心度が違います。

▼ 逆にスムーズだった所

• DESIGN.md → 見た目、の順番が秀逸。いきなりコードではなく先に「方針の紙」を作るので、途中で迷子になりませんでした。
• 1ファイル完結（CSS内包・追加インストール不要）なので、環境構築でコケない。ダブルクリックですぐ見られるのは初心者に優しい。
• セクションごとに作る進め方なので、「今どこを作っているか」が常に分かる。
• 日本語のコピー（キャッチや料金表の文言）まで一緒に作ってくれるので、中身が空っぽにならない。

────────────────────

③ 最初のコピペ用プロンプトへの改善案（ここが本題）

────────────────────

現状の「CC(goal/Mon/batch/…)…」という圧縮プロンプトは、上級者向けの効率記法としては優秀ですが、初学者が最初に触るものとしては不親切です。以下を提案します。

【提案A】記号プロンプトの前に「これは何か」の一文を足す

　例）「※以下はClaudeへの動作指示（おまじない）です。意味が分からなくてもそのまま貼ってOK。あなたが理解する必要はありません。」

　これだけで冒頭のひるみが消えます。

【提案B】初学者版プロンプトを別に用意する（日本語・自然文）

　圧縮版と並べて、こういう“ふつうの文章版”を載せてほしいです ↓

―――（初学者向けコピペ例）―――

あなたはWeb制作のプロです。次の手順でホームページを作ってください。

1. まず DESIGN.md というデザイン方針メモを作る（配色・文字サイズ・全体の構成を先に決める）

2. 「白ベース・文字は大きめ・清潔感」を必ず守る

3. その方針に沿って index.html を1ファイルで作る（追加インストール不要にする）

4. 上から順にセクションごとに作り、最後に全体を見直す

5. 完成したら「どこで確認できるか」「気になったらどう直せばいいか」を教えて

作るサイト：AIを使ったInstagram運用の自動化を教えるスクールのLP

―――――――――――――――――

【提案C】専門語に1行の注釈をつける

　DESIGN.md / 美学プロンプト / セクション / ヒーロー など、初出の語に「（＝〜のこと）」を添えるだけで脱落者が減ります。

【提案D】完成後の確認方法を必ず言わせる

　プロンプト末尾に「完成したらプレビューの見方と、修正したいときの頼み方を最後に説明して」と入れておくと、作りっぱなしになりません。

【提案E】“やり直し方”を最初に教える

　「気に入らなければ『ヒーローの色を〇〇にして』のように部分指定で直せます」という一文があると、初回で完璧を狙わず気楽に進められます。

────────────────────

まとめ（次にやる人へ）

────────────────────

• 最初の記号プロンプトは“おまじない”。読めなくて大丈夫、そのまま貼ればOK。
• 分からないカタカナ語が出たら、Claudeに「〇〇ってどういう意味？」と聞けば止まらず進めます。
• 完璧を最初から狙わず、まず1回作ってから「ここ直して」で育てるのがコツ。
• DESIGN.md→セクションごと作成、の流れは本当に迷わないので、素直に乗るのがおすすめです。

総じて、成果物のクオリティは高く、達成感もあります。あとは「最初の一文の親切さ」さえ足せば、初学者の離脱がぐっと減ると感じました。

• --

（約2,400字）文言や強調ポイントの調整が必要なら言ってください。

① やった課題

• 課題1-1：かわいいアニメ風キャラのシューティングゲームを作る（HTML1枚で完結、魔法使いキャラ＋敵キャラをCanvasで描画）
• 課題1-2：原宿スイーツ店のホームページ（HP）をデザイン。DESIGN.md を先に作り、Claude Cookbook の美学プロンプトを当てて、セクション単位で実装
• 課題1-3：そのHPの「裏側の運営システム」をモックで作成（5タブの管理画面、localStorage保存、承認ワークフロー等）
• 課題1-4：一連の作業をふりかえって、次の人向けにフィードバックをまとめる（＝今これ）

いずれも「1つのHTMLファイルを作って、ブラウザで開いて確認」という流れ。環境構築ゼロで動くものが出てくるので、達成感は早い段階で得られました。

② 想定外だったこと

### 詰まった・戸惑った所

• プロンプトに「例のプレースホルダー」を残したまま送ってしまった

「例：原宿の…スイーツのお店」の角カッコ部分を自分の作りたい内容に書き換えるべきだったのに、そのまま送信。AI側が「どのHPを作りますか？」と聞き返してくれて事なきを得たが、最初は「なぜ質問された？」と一瞬混乱した。→ 角カッコは"穴埋め欄"だと最初に分かっていれば迷わなかった。

• 記号だらけの短縮プロンプトが読めない

CC(goal/Mon/batch/Plan/Hook/…/rev=cr+sr/Ultra) や `承認段階ゲート引継型`「STORE_KEY昇格」「中規模A2A→open」など、独自の略語・造語が多く、自分でも何を頼んでいるのか説明できなかった。AIは汲み取って動いてくれたが、出力が意図通りか自分で検証できないのが不安だった。

• 「PNGで出して」が思ったより一筋縄でいかない

画像(PNG)生成を頼んだら、環境にPython/画像ライブラリが無く、「Canvasに描いてボタンでPNG保存」という代替案になった。結果は満足だが、"頼めば何でも即出る"わけではなく、動く環境に左右されると体感した。

### 分かりにくかった言葉

• DESIGN.md / SPEC.md：「設計を先に書いてから作る」ためのメモ書きファイル、という説明が最初に欲しかった。拡張子 .md も初見だと身構える。
• A2A / FO / fan-out / ckpt / cr・sr：エージェント連携や自己レビューの用語。知らなくても成果物は出るが、使う必要が無い場面まで指定していた（＝オーバースペックな指示になりがち）。
• モック / MVP：「本物っぽく見えるけど中身は仮（連携なし）」の意味。ここを理解しないと「なぜ実データが動かないの？」と誤解する。

### 逆にスムーズだった所

• 1ファイルHTML＋ブラウザ確認の手軽さ。保存→ダブルクリックで即動く。
• 「白ベース・文字大きめ」など見た目の希望は、ふつうの日本語で書くほどよく伝わった。記号より自然文が強い。
• 作ったものを次の課題が引き継ぐ流れ（ゲーム→HP→その裏側システム）が自然で、学びが積み上がる感覚があった。
• 完成後に要点を表でまとめ直してくれるので、自分が何を頼んだか後から確認しやすい。

③ 最初のコピペ用プロンプトへの改善案

次の人が最初に貼るプロンプトは、記号を減らし、穴埋め欄を明示し、確認の一言を足すと一気に楽になります。

### 改善ポイント（要点）

1. 角カッコは「ここを自分の言葉に書き換える欄」と明記する

例：`【ここに作りたい内容を書く（例：原宿のバズってるスイーツ店）】←この【】ごと差し替えてください`

2. 謎の略語をやめ、やりたいことを普通の文にする

rev=cr+sr → 「最後に軽くバグと改善点を見直して」

承認段階ゲート引継型 → 「申請→一次承認→最終承認→公開、の順で進む承認機能を付けて」

3. 成果物の形を先に固定する

「HTML1ファイルで、ブラウザで開くだけで動くものにして。画像が難しければ代替案でOK」

4. 最後に確認をお願いする一言を足す

「作る前に、私の指示で分かりにくい所があれば1つだけ質問して」

### そのまま使えるテンプレ（改善版）

Claude Code の練習をしています。次の内容で【作りたいもの】を作ってください。

■ 作りたいもの

【ここを自分の言葉に書き換える（例：原宿のバズってるスイーツ店のHP）】

■ 進め方

1. まず DESIGN.md（設計メモ）に、目的・配色・全体構成を書き出す

2. その設計に沿って、HTML1ファイルで実装する

3. 最後にブラウザで開いて確認できる状態にする

■ 見た目・仕様の希望

• 白ベース、文字は大きめ
• スマホでも崩れないように
• （必要なら）保存はブラウザだけで完結（サーバー連携なし＝モックでOK）

■ お願い

• 専門用語は使わず、普段の日本語で進めてください
• 作り始める前に、私の指示で分かりにくい所があれば1つだけ質問してください
• 完成したら、何を作ったかを箇条書きで教えてください

### ひとことアドバイス（次の人へ）

• 最初から完璧な指示を書こうとしない。ざっくり頼んで、出てきたものを見て「もっとこうして」と足す方が速いし楽しい。
• 記号や略語で盛らない。自然な日本語のほうがよく伝わる。
• 「モックでOK」と最初に言うと、連携無しの見た目確認がスムーズに進む。
• 分からない用語（.md / MVP / モック 等）は、その場で「これ何？」と聞けばちゃんと教えてくれるので、遠慮なく質問を。

Claude Code はじめて課題（1-1〜1-4）やってみた感想フィードバック

① やった課題

1-1 Claude Code の起動：ターミナルから claude を立ち上げて、対話できる状態にするところまで。

1-2〜1-4 実際に作ってみる：

HTML のシューティングゲームを1本作成（1ファイル完結の HTML/JS）

「AI エージェントのアバター動画サービス」のWebページとそのUI・裏側（ロジック部分）を作成

要は「起動する → 簡単なものを作る → もう少し複雑なもの（見た目＋裏側）を作る」という順で難易度が上がる構成でした。

________…

② 想定外だったこと（詰まった所・分かりにくかった言葉・逆にスムーズだった所）

詰まった・戸惑った所

「起動」のゴールが分かりにくい：claude と打った後、どの画面になれば成功なのかが最初ピンとこない。「プロンプトを打てる状態になればOK」の一言があると安心できた。

作業フォルダ（どこで作られるか）の感覚がつかめない：ファイルが今いるフォルダに作られるので、デスクトップの適当な場所で起動すると散らかる。「先に専用フォルダを作って、その中で起動する」のが分かっていれば良かった。

一発で完璧を求めてしまう：最初のプロンプトを長く・完璧に書こうとして手が止まった。実際は「ざっくり頼む → 動かす → 直したい所を言う」の往復で進むのが正解だと、やってみて初めて分かった。

「裏側」という言葉が曖昧：アバター動画サービスで「裏側も作って」と言われても、それが処理ロジックなのか・API連携なのか・データ保存なのか、初回は判断に迷った。

できたものの確認方法：HTMLファイルをどう開いて動作確認するか（ダブルクリックでブラウザ表示）を知らないと、作った後に手が止まる。

分かりにくかった言葉

「セッション」「プロンプト」「エージェント」などのカタカナ用語が説明なしで出てくる。初学者向けに1行ずつ補足があると良い。

「裏側 / バックエンド / ロジック」が同じ意味で混在していると混乱する。

逆にスムーズだった所

ゲームは達成感が早い：HTMLシューティングは一発でそれっぽく動くものが出てきて「おお動いた」となり、モチベーションが上がった。最初の課題として秀逸。

修正のやりとりが自然：「もっと弾を速く」「色を変えて」など日本語のざっくり指示で直せるのが体験として気持ちよかった。

1ファイル完結：ゲームが1つのHTMLで完結するので、ファイル構成に悩まず確認まで到達できた。

________…

③ 最初のコピペ用プロンプトへの具体的な改善案

初回プロンプトが「起動しただけの人」を前提にしていないと詰まりやすいです。以下のようなテンプレを配布すると、次の人がスムーズになります。

改善案A：ゴールと確認方法を1文で添える

現状のプロンプトの末尾に、この2点を足すのを推奨：

「完成したらファイル名と、どうやって動作確認するか（例：〇〇.htmlをダブルクリックしてブラウザで開く）も教えて」

「まず一度動くものを作って。その後こちらの指示で直していきたい」

改善案B：起動直後の“おまじない”プロンプトをテンプレ化

このフォルダで簡単な作業をします。あなたはClaude Codeです。これから初心者が課題を進めます。専門用語（セッション/プロンプト等）が出たら一言で補足しながら進めてください。まずは動くものを最小構成で作り、完成後に必ず「保存先ファイル名」と「確認方法」を教えてください。

改善案C：課題ごとの穴埋めプロンプトを用意する

ゲーム課題用：「HTMLファイル1つだけで動く〇〇（例：シューティング）ゲームを作って。矢印キーで移動、スペースで発射。完成後、ファイル名と開き方を教えて。」

Webページ課題用：「〇〇サービスの紹介Webページを作って。まず見た目（トップページ）だけ先に作り、確認できたら次に裏側（例：フォーム送信の処理／データの保存）を足していきたい。裏側で作れる候補も先に提案して。」

改善案D：用語ミニ辞書を1枚添付

「プロンプト＝AIへの指示文」「セッション＝1回の作業のまとまり」「バックエンド／裏側＝画面の裏で動く処理」など5語程度でOK。冒頭に貼っておくだけで離脱が減ります。

________…

まとめ（次にやる人へ一言）

「完璧なプロンプトを書こうとしないで、ざっくり頼んで会話で直す」——これに気づけるかどうかが最初の分かれ目でした。起動のゴール・作業フォルダ・確認方法の3点だけ先に押さえておけば、あとは楽しく進められます。

━━━━━━━━…

Claude Codeをはじめる（課題1-1〜1-4）やってみた感想

― 次にやる人へのフィードバック ―

━━━━━━━━…

【① やった課題】

• 課題1-1：最初の「操作ルール系プロンプト（CC(goal/Mon/batch…)）」を

投げて、Claude Codeに動き方の方針を渡す

• 課題1-2：高級エステサロンのLP（ホームページ）を作成

→ DESIGN.md作成 → 美学プロンプト適用 → セクション単位で実装

→ ブラウザで表示確認（白ベース／文字大きめ）

• 課題1-3：そのLPの「裏側システム（予約・顧客管理）」をモックで作成

→ 仕様駆動MVP。5タブ／100点スコアリング／承認ゲート等

• 課題1-4：システム構成の図解PNGを出力し、ブラウザで最終Open

一言でいうと「作りたい物を日本語で伝えるだけで、設計書→実装→

動作確認まで一気に出てくる」体験でした。手を動かす前に完成イメージが

見られるので、初めてでも達成感が早いです。

━━━━━━━━…

【② 想定外だったこと】

●詰まった所

• 最初のプロンプトが「暗号」に見える。

例）rev=cr+sr、A2A、STORE_KEY昇格、3層振分、引継型、各画面🤖pt。

何を指示しているのか初見では読めず、「これ本当に効いてるの？」と

不安になりました。→ 実際は効いていますが、確信が持てないのが不安。

• 「仕様駆動MVP=level3」の"level3"が何段階中の3なのか不明。

完成度の基準が分からず、出来上がりを見るまで想像できませんでした。

• 略語の日本語混在（「100点+3層振分」「sample5-15」等）が独特で、

自分で応用しようとすると真似しづらい。

●分かりにくかった言葉

• A2A … 「エージェント同士の連携」の意味だと後で分かった
• STORE_KEY昇格 … データ保存キーのバージョン管理のこと
• rev=cr+sr … レビュー（code review＋security review）の指定
• 🤖pt … 「各画面にAIのひとことアドバイスを置く」指示

※どれも意味が分かれば便利。でも初見の人には注釈が要ります。

●逆にスムーズだった所

• 「凄いと思える業務ツールにして」「急ぎで」など"ざっくり日本語"の

部分はむしろよく効く。細かく指定しなくても良い感じに補完される。

• ブラウザ自動Openや、作業ごとの「選定／理由／結果」報告が親切で、

何が起きたか追いやすい。

• 作り直し（データ再生成・修正）が軽い。失敗を怖がらず試せる。

━━━━━━━━…

【③ 最初のコピペ用プロンプトへの改善案】

（現状）

CC(goal/Mon/batch/Plan/Hook/Rule/Skill/Flow/allow/Mem/sec/task/

Team/rw/rev=cr+sr/Ultra)最適選択→batch/Flow FO→待Mon…（略）

改善のポイントは「①ルールと②依頼を分ける」「略語に一行注釈をつける」

の2点です。次の人にはこの形を推奨します。

────────────────────

▼改善案A：略語をやめて素直な日本語にする（初心者向け）

────────────────────

【あなたの動き方のルール】

• 作業前に「使う機能・進め方・理由」を一言で説明してから始めて
• 並行してよい作業はまとめて進めて（速く）
• 危険な操作（削除・上書き）の前は必ず確認を取って
• 作り終わったらブラウザで開いて、結果を要約報告して
• 専門用語は避け、私（初心者）に分かる言葉で

【今回やりたいこと】

（例：高級エステサロンのLPを作って。白ベース・文字大きめ。

　予約フォームまで用意して。まずイメージを見たいので連携は後回しでOK）

────────────────────

▼改善案B：今の短縮形を残しつつ注釈を足す（中級者向け）

────────────────────

略語の直後に「＝説明」を付けるだけで一気に読めます。

• rev=cr+sr（＝コード＆セキュリティのレビュー実施）
• A2A（＝必要なら複数エージェントで分担）
• STORE_KEY昇格（＝保存データにバージョンを持たせる）
• level3（＝完成度レベル。1=試作/2=動く/3=業務で使える手前）
• sample5-15（＝サンプルデータを5〜15件入れる）

────────────────────

▼共通で入れると親切な一文

────────────────────

「初めて触るので、専門用語が出たら都度かんたんに補足して」

この一行があるだけで、詰まる場面が激減すると思います。

━━━━━━━━…

【総評】

出力の質はとても高い。つまずきの原因はほぼ"最初のプロンプトの

読みにくさ"に集中している。ルールと依頼を分け、略語に注釈を足すだけで

初心者のハードルは大きく下がるはず。中身は変えず、"見せ方"の改善で

十分効果があります。

━━━━━━━━…

以下、そのままコピペできる形でまとめました。（約2,900字）

• --

【Claude Codeをはじめる 課題1-1〜1-4 やってみた感想 — 次にやる人へのフィードバック】

■ ① やった課題（何を作ったか）

1-1: DESIGN.md の作成

　Kindle出版プロデューサーのHPの「設計図」を先に作る工程。カラー・フォント・セクション構成をMarkdownで固めてから実装に入る流れ。

1-2: Claude Cookbookの美学プロンプトを適用

　「白ベース・文字大きめ・余白重視・アクセント1色」といったデザイン原則をDESIGN.mdの冒頭に明文化。これ以降の実装がブレなくなる。

1-3: セクション単位で実装

　Header→Hero→実績(Bookshelf)→…と、1セクション=1実行単位で作る前提で設計。今回は「DESIGN.md承認後に実装」を選んだので、設計書レビューで一旦ストップ。

1-4: HPの裏側システム（仕様駆動MVP／level3）

　公開サイトの管理画面を単一HTMLで構築。5タブ（ダッシュボード/リード/パイプライン/書籍実績/AI設定）、リードを100点採点してS/A/Bに自動振分、出版工程を承認ゲート付きカンバンで管理。構成図もPNGで出力。

→ 全体を通して「設計→美学→実装→裏側」という順番を体で覚えられる良い流れでした。

■ ② 想定外だったこと

＜詰まった／戸惑った所＞

• 最初のプロンプトが「暗号」に見える

　冒頭の指示が `CC(goal/Mon/batch/Plan/Hook/…/rev=cr+sr/Ultra)` のような超圧縮の略語で、正直、最初の10秒は「これは呪文か？」と思いました。Mon=Monitor、rev=review、A2A=エージェント連携…と1つずつ意味を推測する必要があり、初学者は確実にここで止まります。

• お題の指定欄がテンプレのままだった

　`[ホームページで作りたい内容 例：Kindle出版…]` の角カッコが“記入例”なのか“確定内容”なのか分からず、AIに聞き返されました。自分が何を作りたいか先に決めていないと、ここで会話が1往復増えます。

• フォルダ名と中身がズレる

　作業フォルダが「ユニコスクール」なのに中身はKindle出版の話で、一瞬「どっちの話？」となりました。フォルダ名＝サイトの内容だと思い込むと混乱します。

• 専門用語が説明なしで飛んでくる

　「STORE_KEY昇格」「承認段階ゲート引継型」「3層振分」あたりは、意味が分かれば納得なのですが、初見だと手が止まります。特に「昇格」はデータの保存形式を新しくする話、と後から理解しました。

• 図解PNGの出力

　「PNGで出して」に対して、環境にSVG→PNG変換ツールが無く、Chromeを裏で使って画像化していました。結果は綺麗でしたが、ここは環境次第で失敗し得るポイントだと感じました。

＜逆にスムーズだった所＞

• 「先に設計書、承認してから実装」の型が超快適

　いきなりコードが生成されず、DESIGN.mdで方向性を確認できるので安心感がありました。手戻りが激減する実感。

• 単一HTML＋localStorage

　ファイルが1個で完結し、ダブルクリックで動く。環境構築ゼロで「動くもの」が見られるのは初学者に本当に優しい。

• セクション単位という発想

　「全部一気に」ではなく区切って進める前提だと、途中で口を挟みやすく、レビューもしやすかったです。

■ ③ 最初のコピペ用プロンプトへの具体的な改善案

1) 略語には初回だけ“凡例”を付ける

　冒頭の圧縮指示の下に、1行で `※Mon=進捗監視 / A2A=分担 / rev=レビュー / ckpt=中断ポイント` のような対訳を置くだけで、初学者の離脱が激減します。上級者は読み飛ばせばよいので害はありません。

2) 記入欄を「例」と「ここに書く」で分ける

　現状: `[作りたい内容 例：Kindle出版…]`

　改善:

　　▼あなたが作りたい内容をここに1行で書く：

　　（例）Kindle出版プロデューサーの実績紹介サイト

　角カッコの例文をそのまま消して自分の言葉に置き換える、という動作が明確になります。

3) 冒頭に「最初にAIへ渡す3点」を明記

　プロンプトの一番上に、これだけ埋めれば動く欄を用意する：

• 何のサイト/ツール？
• 一番見せたい/やりたいことは？
• 連絡先や実データは今ある？（無ければ仮でOK）

　これがあると、AIからの聞き返しが1〜2往復減ります。

4) 専門用語に半角括弧で超訳を添える

　例: `STORE_KEY昇格（=保存データの形式を新版へ自動移行）` `承認ゲート引継型（=各工程を承認しないと次に進めない仕組み）`。用語自体は残しつつ意味を1フレーズ足すだけで、初学者でも指示の意図を掴めます。

5) 「PNGが出せない環境もある」前提の逃げ道

　`図解PNG（環境により出せない場合はSVGや画面キャプチャで代替可）` と一言添えておくと、変換ツールが無い環境でも詰まりません。

6) フォルダ名と作るものが違う場合は最初に宣言

　`※作業フォルダ名（例:ユニコスクール）とサイト内容は別物でOK` と書いておくと、名前に引っ張られた混乱を防げます。

■ まとめ（次にやる人へ一言）

「設計書を先に作って承認 → 単一HTMLで動かす」という型は、最初の一歩として本当に良くできています。つまずくのはコードではなく“最初のプロンプトの略語と記入欄”です。1-1に入る前に「自分が何を作りたいか1行」だけ決めておけば、あとはかなりスムーズに進みます。

• --

必要なら、この本文を`FEEDBACK.txt`として保存もできます。文字数を増減したい場合も調整します。

「Claude Codeをはじめる」課題1-1〜1-4 フィードバック

①やった課題

課題1-1：HTML単一ファイルで完結する、オリジナリティのあるシューティングゲームを作成（Canvas、外部依存なし）

課題1-2：架空の実店舗（渋谷のサッカーユニフォーム専門店）のホームページをデザイン。DESIGN.md作成→デザインの美学ガイド適用→セクション単位で実装、という手順で実行

課題1-3：そのホームページの「裏側」にあたる業務管理システムを仕様駆動でモック実装（在庫管理・入荷承認フロー・プリント受注管理・レポート機能。localStorageで永続化、サービス連携なし）

課題1-4：完成物に対するコメント欄の質問（「どのようなシステムを作ったか」）に回答

4課題は連続したストーリーになっており、1-1で基本操作に慣れ、1-2〜1-3で徐々に複雑な指示の書き方（デザイン指定→仕様指定）にステップアップしていく構成だと感じました。

②想定外だったこと

詰まった・分かりにくかった点

課題1-2、1-3のプロンプトが「CC機能の略語＋スラッシュ区切り」の非常に圧縮された表記だった（例：仕様駆動MVP=level3、STORE_KEY昇格、中規模A2A、rev=cr+srなど）。これらは事前に用語集や過去のやり取りの積み重ねがないと正確な意味が取れず、特に「level3」が何を基準にした段階なのか（1・2との違い）がどこにも定義されていなかったため、意味を推測で補う必要があった。

課題1-2で「[ホームページで作りたい内容 例：〇〇]」という角括弧＋「例：」という書き方が、「これは記入例であり実際の内容は別途指定する」のか「このまま実店舗内容として使ってよい」のかが曖昧だった。今回は後者として進めたが、実在店舗を想定した誇張表現（「1番大きい」等）を含む場合、事実確認が必要な実在店舗なのか架空店舗なのかの判断が必要になる場面があり、ここは一段階確認を挟んでもよかったポイント。

「サービス連携などは一旦行わず」という前提と、「凄い！と思うような業務効率化ツール」という要求が並んでいるため、「AIが自動化する」という誇大な演出と「実際には何もつながっていない」という誠実さのバランスを取る判断が必要だった。これは明示的な指示がなかったので、自己判断で「🤖デモ表示（連携なし）」と明記する形に倒したが、次にやる人によっては誇張寄りに振れる可能性がある。

逆にスムーズだった点

課題1-1はキーワード（「ゲーム作って」等）だけで意図した機能（ミニゲーム生成）が自動でトリガーされ、迷う余地がほとんどなかった。

課題1-2・1-3ともに、いったん仕様を圧縮表記からいったん頭の中で分解できれば、要求されている成果物（DESIGN.md、単一HTML、図解PNG）を作る作業自体はスムーズで、大きな手戻りは発生しなかった。

課題1-3の「図解PNG」と「動くHTML」を並行して作る部分は、片方を裏側で走らせながらもう片方を進める形にできたため、待ち時間なく完了できた。

一貫して「白ベース」「文字大きめ」など明確な条件が指定されていた課題は迷いがなく、逆に条件が明確なほど成果物の質が安定すると実感した。

③最初のコピペ用プロンプトへの具体的な改善案

略語・記号表記には最低限の凡例を1行添える

CC(goal/Mon/batch/...) のような略語列を使う場合、初回だけでもよいので「※各略語の意味は【用語集リンク／別紙】参照」と明記する。用語集がまだ無ければ、課題1-2・1-3のどこかに簡単な対応表（例：Mon=進捗監視, rw=事前ドキュメント作成, rev=cr+sr=コードレビュー+セキュリティレビュー）を一度提示しておくと、初見の人でも正確に意図を汲み取れる。

「level」「段階」を使う場合は基準を明記する

仕様駆動MVP=level3 のように段階を指定するなら、「level1=静的モック／level2=操作可能だが保存されない／level3=localStorage等で状態が保存される」など、1行だけでも定義を添えると解釈のブレがなくなる。

プレースホルダーの記法を統一する

「[〜 例：〇〇]」という書き方は「例」なのか「実際の値」なのか読み手によって解釈が割れる。プレースホルダーには 【ここに実際の内容を記入】 のように記入を促す記法、参考として見せたいだけなら （参考イメージ：〇〇。実際は別途相談） のように、意図が一目で分かる記法に統一するとよい。

「誇大に見せたいが誠実さも保ちたい」という矛盾する要求は、明示的にトーンを指定する

「凄いと思わせたいが、実装していない機能は嘘をつかない」という要求は暗黙のバランス感覚に依存しがちなので、「AIポイントは"デモである"ことが分かる形で表示する」など、次にやる人が同じ判断で迷わないよう、最初から一言添えておくと安心。

段階的な課題であることを冒頭に明記する

1-1〜1-4が「基本操作→デザイン指定→仕様指定→フィードバック対応」という難易度のステップアップになっていることが、実際にやってみて初めて分かった。最初のプロンプトに「この課題は段階的に難易度が上がります」と一言添えておくと、次にやる人が心構えを持って臨める。

以上です。全体を通して、明確な条件（色・文字サイズ・構成要素）が具体的であるほど成果物の精度が上がる一方、圧縮された略語表記は初見のハードルを上げる要因になっていたため、③の凡例整備が一番効果が大きい改善だと感じました。

以下、そのままコピペできるフィードバック文です。

• --

【Claude Codeをはじめる（課題1-1〜1-4）をやってみた感想 — 次にやる人へ】

■ ① やった課題

• 課題1-1：写真家ポートフォリオHPの設計書（DESIGN.md）を作成。コンセプト・カラー・タイポ・セクション構成を先に文章で固めた。
• 課題1-2：Claude Cookbookの「美学プロンプト」を適用。白ベース／大きめ文字という指定を、余白・タイポスケール・最小限の装飾という具体ルールに落とし込んだ。
• 課題1-3：Claude Codeでセクション単位に実装。index.html / styles.css / main.js の3ファイルを、Hero〜Contactまで順に構築。
• 課題1-4：そのHPの「裏側システム」を仕様駆動MVPで構築。撮影スタジオの経営管理ツール（5タブ／100点スコアリング／承認ゲート／localStorage）を単一HTMLで作り、最後にブラウザで起動確認まで。

■ ② 想定外だったこと

＜スムーズだった所＞

• 「まずDESIGN.mdを作る→次に実装」という順番が想像以上に効いた。設計を言語化してから作ると、出てくる成果物のブレが少ない。いきなり「作って」と言うより明らかに質が上がる。
• 画像がまだ無くても、onerrorでダミー画像に自動フォールバックする作りにしてくれたので、写真を1枚も用意していない段階でも完成イメージがすぐ見られた。ここは感動ポイント。
• 「セクション単位で」と伝えると、本当に部品ごとに区切って作ってくれるので、途中経過が追いやすい。
• 図解PNGの生成。専用の変換ツールが入っていない環境でも、ヘッドレスChromeで代替してPNGを出してくれた。「できない」で止まらず回避策を出してくるのは頼もしい。

＜詰まった所・分かりにくかった所＞

• 最初のコピペ用プロンプトが暗号すぎる。「CC(goal/Mon/batch/Plan/Hook/Rule/Skill/Flow/allow/Mem/sec/task/Team/rw/rev=cr+sr/Ultra)」のような略語の羅列は、初見だと何を指示しているのか全く読めない。動きはするが、自分が何を頼んでいるのか理解しないまま進む不安があった。
• 略語の意味が説明なしなので、「A2A」「ckpt」「rev=cr+sr」「Ultra」あたりが何なのか、次の人はまず調べる所から始まってしまう。
• 「level3」「100点+3層振分」「承認段階ゲート引継型」など、独自用語が多く、期待する完成形が言葉だけでは想像しづらい。結果は良かったが、指示した時点では「何が出てくるか」が読めなかった。
• 「モーダル(confirm禁止)」のような制約は、なぜ禁止なのかが書かれていないと、初心者は意図を掴めない（＝標準のconfirmダイアログではなく、ちゃんとしたUIのモーダルを作らせるための指定）。

■ ③ 最初のコピペ用プロンプトへの具体的な改善案

1) 略語の下に「凡例（用語集）」を1ブロック足す。

　例：

• batch＝並行してまとめて実行
• Mon＝実行中タスクの監視
• ckpt＝危険操作の前に一旦保存・確認
• A2A＝別エージェントへ引き継ぎ
• rev=cr+sr＝コードレビュー＋セキュリティレビュー

　これがあるだけで「呪文」が「設定メニュー」に変わる。

2) 1行に詰め込まず、役割ごとに改行する。

　「目的／進め方／安全（危険操作前に確認）／レビュー／報告フォーマット」の5ブロックに分けるだけで、初心者でも読める。動作は同じでも心理的ハードルが激減する。

3) 冒頭に「このプロンプトが何をするものか」を平文で1〜2行。

　例：「これはClaude Codeに“最適な進め方を自分で選び、危険な操作の前だけ確認し、最後に要約報告する”よう指示する共通ヘッダーです」。目的が分かると、中身の略語も推測できる。

4) 独自用語には必ず具体例か完成イメージを添える。

　「100点+3層振分」→「問い合わせを100点満点で採点し、HOT/WARM/COLDの3グループに自動仕分け」のように、日本語で言い換えを1つ入れる。

5) 制約には理由をひとこと。

　「モーダル(confirm禁止)」→「確認は標準のconfirmではなく自作モーダルで（見た目を揃えるため）」。禁止だけだと初心者は従えても納得できない。

6) 「急ぎで！」「凄いと思えるツールに」のような温度感の指示は、プロンプトの“最後”にまとめて置く。

　制御用の略語ブロックと、感情・品質の要望が混ざると読みにくい。「①やること→②守ること→③仕上がりの温度感」の順が理想。

7) 最初の一手を固定文にしておく。

　「まず現状のフォルダを確認し、次にDESIGN.md（設計書）を作ってから実装して」と最初に書いておくと、この“設計先行”の流れに乗れる。今回いちばん効果が大きかった部分なので、テンプレ化推奨。

■ ひとことまとめ

成果物のクオリティと「できない時の回避力」は文句なし。詰まるのは中身ではなく“最初のプロンプトの読めなさ”。略語に凡例を付け、改行で構造化し、独自用語に日本語の言い換えを添える——この3点だけで、次の人の立ち上がりは一気に楽になります。

• --

（約2,600字。①②③すべて、今回のセッションで実際に起きたことベースでまとめました。）

以下、そのままコピペして使えるフィードバックです。（約2,900字）

• --

# 「Claude Codeをはじめる（課題1-1〜1-4）」やってみた感想＆次の人へのフィードバック

① やった課題

• 1-1：シューティングゲーム制作

「HTMLで超作り込んだオリジナリティのあるシューティングゲームを作って」。単一HTMLでネオン系シューターが完成。ブラウザまで自動で開いてくれた。

• 1-2：ホームページのデザイン

「DESIGN.md作成 → Cookbookの美学プロンプト適用 → セクション単位で実装」という流れ指定。白ベース・文字大きめのスイーツ店LPを作成。

• 1-3：既存デザインへの寄せ

「不二家のカフェに似せて」。1-2のLPを赤×白のレトロ路線にリスキン。マスコットも自作SVGで用意された。

• 1-4：裏側システム（管理画面）の制作

「先ほどのHPの裏側システムを作って」。5タブの店舗運営ツール（予約スコアリング／在庫／顧客管理など）と、その設計図PNGが出力された。

→ 1つ作る → 手を加える → その裏側を作る、と段階的に発展していく構成。最終的に「表のサイト＋裏の管理システム」が一式そろうのは達成感があった。

② 想定外だったこと

### 詰まった所・分かりにくかった言葉

• 最大の壁は「見本プロンプトの記号・略語」。たとえば

`CC(goal/Mon/batch/Plan/Hook/Rule/Skill/Flow/allow/Mem/sec/task/Team/rw/rev=cr+sr/Ultra)…`

や `out:図解PNG+動くHTML単一・5tab・100点+3層振分・各画面🤖pt・承認段階ゲート引継型…` のような圧縮された呪文。何を指示しているのか初見ではまったく読めなかった。結果は出るが「自分が何を頼んだのか」が分からないまま進む不安があった。

• プレースホルダーの罠。`[ホームページで作りたい内容 例：…]` を例文のまま送ってしまいそうになった。実際、中身を書き換えずに送ると「ここが未入力です」と確認された。テンプレの「例：」表記が、埋める欄なのか読むだけの例なのか紛らわしい。
• 専門用語がそのまま出てくる。「STORE_KEY昇格」「A2A」「段階ゲート引継型」など。動くものは出るが、意味を知らないと出力の良し悪しを判断できない。
• 保存場所が分かりにくい。ファイルがどのフォルダに作られたか、最初は把握しづらかった（フルパスで示してくれてからは安心した）。

### 逆にスムーズだった所

• 「作って」だけでも、ちゃんと動くものが最後まで出る。細かく指定しなくても補完してくれる。
• 完成後に自動でブラウザが開くので、すぐ結果を確認できたのが気持ちよかった。
• やり直し・変更が速い。「不二家に似せて」の一言で全体がガラッと作り替わった。ゼロから書き直す感覚がない。
• 著作権への配慮を勝手にしてくれた。ペコちゃん風マスコットを「公式画像は使わず自作」と明言してくれて、そのままだと危ない部分をフォローしてくれた。
• 「何を・なぜ・結果」を要約報告してくれるので、専門用語が分からなくても全体像はつかめた。

③ 最初のコピペ用プロンプトへの改善案

次にやる人が迷わないよう、見本プロンプト側を直すのがいちばん効くと感じた。

1. 呪文（記号・略語）は初回プロンプトから外す or 日本語の一文にする

`rev=cr+sr` `A2A` `🤖pt` のような略語は初心者を止める。まずは

「作ったら最後にセルフチェックして、選んだ理由と結果を日本語で報告して」程度の平文で十分。上級者向けの記号版は「※慣れたら使える省略記法」として別枠・任意にする。

2. プレースホルダーを、ひと目で「埋める欄」と分かる形にする

`[ホームページで作りたい内容 例：…]` ではなく

`▼ここに作りたい内容を書く（消してから書いてください）：___`

のように、例文と入力欄を物理的に分ける。「例：」の直後に空欄を用意すると誤送信が減る。

3. 専門用語には1行の注釈を付ける

例）「STORE_KEY昇格（＝保存データの引っ越しを自動でやる仕組み）」。用語集を末尾に3〜4行足すだけで、出力の意味が分かるようになる。

4. 保存先とファイル名を最初に指定できる欄を作る

「どこに・何という名前で作るか」を冒頭で聞く一文（例：`保存フォルダ：___ / ファイル名：___`）があると、後から探さずに済む。

5. 各課題のゴールを1行で明記する

「1-4の完成＝○○ができれば合格」のような完了条件があると、出てきた成果物が正解か自分で判断できる。

6. 「急ぎ」「イメージだけ」等の温度感を選べるようにする

今回「サービス連携は一旦なし／イメージが見たい」と伝えたら的確だった。選択肢（本番実装 / モックだけ / とにかく速く）をプロンプトに用意すると、期待値がずれない。

• --

### ひとことまとめ

「動くものは初心者でも必ず出せる。詰まるのは“見本プロンプトの記号と用語”だけ」 というのが率直な感想です。プロンプトを平易な日本語にし、入力欄と例文を分けるだけで、次の人の体験は大きく良くなると思います。

以下、そのままコピペできる形式でまとめました(全体6000字以内)。

```

【Claude Codeをはじめる 課題1-1〜1-4 やってみた感想】

①やった課題

1-1: HTMLで独自性のあるシューティングゲームの作成

　→「タイムエコー」という、過去数秒間の自機の動きを記録し分身として再生・攻撃させる独自システムを核にしたシューティングゲームを1ファイルのHTMLで実装。ボス戦・スコア・コンボ・ボム・パーティクル演出まで込みで完成、ブラウザで自動オープンまで実施。

1-2: NPO法人の見学会申込ページのデザイン設計〜実装

　→「1:DESIGN.md作成 → 2:美学プロンプト適用 → 3:セクション単位で実装」という3段階の指示に沿って、白ベース・文字大きめ・団体のミッションを踏まえた申込ランディングページを作成。Google Sitesへの移植を見据え、セクション構成を明文化した設計書とHTML実装をセットで納品。

1-3: 申込ページの裏側業務システム（管理ツール）のモック作成

　→圧縮記法で書かれた仕様（100点スコア+3層振分、5タブ構成、承認段階ゲート、STORE_KEY管理など）を解釈し、localStorage駆動の単一HTML管理ツールと、全体構成を示すSVG図解をセットで作成。サービス連携は行わず、見た目とフローの検証用モックとして仕上げた。

1-4: ここまでの振り返り・次の人への引き継ぎ（本フィードバック）

②想定外だったこと

詰まった点・分かりにくかった言葉

• 課題1-3の指示文が「CC(goal/Mon/batch/Plan/…)最適選択→batch/Flow FO→…」のような圧縮記法で書かれており、意味の特定に時間がかかった。特に「A2A」「STORE_KEY昇格」「3層振分」「🤖pt」「引継型ゲート」といった独自略語は、初見では正確な定義が分からず、文脈から妥当な解釈を組み立てる必要があった。
• 「中規模A2A」のように複数エージェントでの並列処理を示唆する語があったが、実際にそうした処理を実行するには明示的な追加同意（特定のキーワードでの申告）が仕組み上必要で、圧縮記法だけでは「本当にそれを求めているのか」の判断が難しかった。結果として今回は通常の単一実行で対応したが、意図と食い違っている可能性がある。
• 「図解PNG」という成果物指定に対し、実際にはPNGを直接生成する手段がなく、代替としてSVG（ベクター画像）で出力した。指定フォーマットと実際に用意できる手段の間にギャップがあり、事前の断りが必要だった。
• 1つの依頼文の中に「急ぎで」という速度優先の指示と「凄い！と思う品質にして」という質優先の指示が同時に含まれており、どちらを優先すべきかの匙加減は暗黙の判断に委ねられた。

逆にスムーズだった点

• 課題1-1、1-2のような平易な日本語の指示（「ブラウザで開いて」「白ベース、文字大きめ」など）は迷いなく一度で実装まで完了できた。指示が具体的なほど手戻りが少ない、という当たり前の傾向を改めて実感した。
• 「さっき作ったホームページの裏側を作って」のように、直前の成果物を指す指示は、会話の文脈が保持されているため追加説明なしでスムーズに次の課題へ接続できた。段階的に依頼を積み上げていくスタイルは相性が良い。
• モーダル実装（confirm禁止）やSTORE_KEYのバージョン管理のように、技術要件が具体的に明示されている項目については、解釈のブレなく実装判断ができた。

③最初のコピペ用プロンプトへの具体的な改善案

1. 圧縮記法（CC(...)...のような独自略語）を使う場合は、初回のプロンプトに一度だけ簡単な用語集を添える。

　例：「A2A＝複数のClaudeエージェントを連携させる処理方式」「STORE_KEY昇格＝localStorageのデータ形式が変わった際にキー名をv1→v2のように更新する設計」など。用語集があるだけで解釈のブレが大幅に減る。

2. 成果物のフォーマットに実現可能性の幅を持たせて明記する。

　例：「図解PNG（難しい場合はSVGなど閲覧可能な図版で代替可）」のように、代替手段をあらかじめ許容しておくと、途中で作業者が形式判断に迷わない。

3. 課題ごとに「完了条件（Done条件）」を1行添える。

　例：「この課題は、ブラウザで実際に動作確認でき、5タブすべてに🤖ヒントが表示されていれば完了」など。完了基準が明示されていると、次の人が自分の成果物が要件を満たしているか判断しやすい。

4. 複数の要求を1文に詰め込みすぎない。

　「急ぎで」「凄いと思う品質で」「サービス連携なしでイメージだけ」のように、優先順位が異なる要望を並べる場合は、優先度の高いものから箇条書きにするなど順序を明示すると、判断の一貫性が上がる。

5. 「A2A」「Flow」「Workflow」など複数エージェント実行を示唆する語を使う場合は、それが本当に並列処理の実行を望んでいるのか、単なる作業方針のメモなのかを一言添えて区別する。

　例：「（※実際に複数エージェントを並列実行してほしい場合は、その旨をはっきり明記）」と注記しておくと誤解が起きにくい。

以上、次に1-1〜1-4に取り組む方の参考になれば幸いです。

```

以下、そのままコピペで使えるテキストです。

• --

# Claude Codeをはじめる（課題1-1〜1-4）フィードバック

① やった課題

• 1-1：Claude Codeの起動・作業フォルダの確認（Desktop/ユニコスクール）
• 1-2：ホームページを1本作る → 単一HTMLの弾幕シューター「NEON VOID」が完成
• 1-3：その「裏側のシステム」を仕様駆動プロンプトで発注 → 運営管理コンソール（5タブ・100点3層振分・段階ゲート承認・localStorage保存）を単一HTMLで生成
• 1-4：成果物の図解PNG出力とブラウザでのOpen

全体を通して「日本語の指示だけで、動くツールが1ファイルできてブラウザで開く」ところまで一気通貫で体験できた。

② 想定外だったこと

【詰まった所】

• 同じ指示文をもう一度送ったら、AIが「もう作成済みです」と返してきた。作り直すのか差分だけ足すのか一瞬迷った。→ 再送＝再実行ではなく「前回の続き」として扱われる、と分かるまでが想定外。
• 「図解PNG」を頼んだのに、最初はチャット内の図（SVG）で返ってきて、PNGファイルは出ていなかった。「PNG」という語だけでは"画面表示"か"ファイル保存"か伝わりきらない。2回目で実PNGファイルになった。
• 作業フォルダ名は「ユニコスクール」なのに中身はゲーム。「先ほど作ったホームページ」が何を指すか、AI側も一度ファイルを開いて確認していた。名前と中身がズレていると指示が曖昧になる。

【分かりにくかった言葉】

• 「STORE_KEY昇格」「中規模A2A→open」「承認段階ゲート引継型」あたりは、初見だと何を求められているか読み取れない。記号と略語が多く、"通じる人には速いが、初心者には暗号"という印象。
• 「level3」「仕様駆動MVP」も、基準が明文化されていないと再現しづらい。

【逆にスムーズだった所】

• 出力形式の指定（単一HTML／localStorage／日本語／白基調／5タブ）が具体的だったので、仕上がりのブレが少なかった。抽象語より"箇条書きの制約"のほうが効く、と体感できた。
• 「サービス連携はせずイメージだけ」「完成したらブラウザでOpen」という完了条件がはっきりしていて、ゴールが明確だった。
• モーダルやトースト、サンプルデータの自動投入まで含めて"それっぽく凄い"ものが一発で出てくるのは気持ちよかった。

③ 最初のコピペ用プロンプトへの具体的な改善案

改善のポイントは「略語を1回だけ日本語で開く」「出力物の"形"を名詞で固定する」「完了条件を先頭に置く」の3点。

改善案A：略語には初出で注釈を付ける

• 例）「STORE_KEY昇格（＝保存キーを新バージョンへ自動移行する処理）」
• 例）「図解PNG（＝チャット表示ではなく .png ファイルとして保存）」
• 記号の羅列は残してよいが、初心者向けなら1行の補足があるだけで再現性が段違い。

改善案B：完了条件（Doneの定義）を先頭に明記

• 「最終成果物：①動くHTML1ファイル ②構成図の.pngファイル ③ブラウザで自動オープン。この3つが揃ったら完了」
• 先に"何が出れば正解か"を書くと、途中の解釈ブレが減る。

改善案C：対象を指す言葉を具体化

• 「先ほど作ったホームページ」→「neon-void.html（弾幕シューター）の運営管理ツール」のようにファイル名で指定。
• フォルダ名と中身が違う場合は特に有効。

改善案D：再送ではなく「変更指示」で回す

• 同じ文を再送すると"作成済み"扱いになりやすい。作り直したいときは「一から作り直して」、追加したいときは「〇〇を追加して」と動詞で明示する。

• --

改善版プロンプト（コピペ用テンプレ）：

「neon-void.html（先に作った弾幕シューター）の"運営管理ツール"を作って。

最終成果物（これが揃えば完了）：

1. 動く単一HTMLファイル1本

2. 構成図を .png ファイルで保存

3. 完成したらブラウザで自動オープン

仕様：

• 保存はlocalStorageのみ（外部サービス連携なし）／日本語／白基調
• タブ5つ、各画面にAI提案の要素を1つ
• 100点満点スコアで3層に自動振り分け
• サンプルデータを5〜15件あらかじめ投入
• 承認フローは"段階を飛ばせない＋次の担当へ引き継ぐ"方式
• 確認ダイアログはブラウザ標準（confirm）禁止。自作モーダルで
• 保存キーは旧バージョンから自動移行する処理を入れる

まずは中身のイメージ確認が目的。凄いと思える業務効率化ツールとして、急ぎで。」

• --

以上。次にやる人は「略語を1つ日本語で開く」「出したいファイルの拡張子を書く」「完了条件を先頭に置く」の3つを意識すると、1回目からイメージ通りに出やすいはず。

（本文 約2,900字）

Claude Codeをはじめる（課題1-1〜1-4）やってみた感想

━━━━━━━━…

■ ① やった課題

大きく2本の制作を通して、1-1〜1-4を一気に回した感じでした。

• 前半（1-1〜1-2）：カフェの公式ホームページ制作。

まず DESIGN.md（設計書）を作り、Claude Cookbook の

「美学プロンプト（意図／抑制／余白／タイポ優先）」を適用してから、

ヘッダー → ヒーロー → コンセプト → メニュー →… と

セクション単位で実装。白ベース・文字大きめの1ページLP。

• 後半（1-3〜1-4）：そのHPの「裏側のシステム」を仕様駆動MVPで制作。

SPEC.md を先に書き、5タブ構成の運用ダッシュボード

（発注を100点で自動採点 → A/B/Cの3層振分 → 段階承認）を

単一HTML＋localStorage のモックで実装。

最後に図解PNGを生成してブラウザで開くところまで。

■ ② 想定外だったこと

＜スムーズだった所＞

• 「設計書を先に作る → そのあと実装」の順番が想像以上に効く。

最初に言葉で固めておくと、実装が最後までブレない。

• セクション単位／タブ単位で刻むと途中経過が見えて安心。

全部を一気に作らせるより断然おすすめ。

• 「白ベース・文字大きめ」みたいな一言の見た目指定が、

ちゃんと最後まで一貫して反映される。指示は短くてOK。

• localStorage のモックだけで“動くもの”がすぐ触れる。

外部連携ゼロでもイメージは十分伝わった。

＜詰まった所・分かりにくかった言葉＞

• 最初のコピペ用プロンプトが暗号みたいに圧縮されていて、

初見だと意味が取れない。特に「A2A」「batch/Flow FO」

「ckpt」「rev=cr+sr」あたりは、略の説明がないと固まる。

• 課題側の用語（「3層振分」「段階ゲート引継型」「STORE_KEY昇格」

「🤖pt」）も最初は具体像が湧かず、実物を見て初めて腑に落ちた。

• 作業フォルダに前から無関係のファイル（別のHTML）が入っていて、

上書きされないか一瞬ヒヤッとした。結果は別フォルダに作ってくれて

無事だったが、事前に「既存は触らない」と言えたら安心だった。

• 図解PNGの生成で変換ツールが未インストールで一手間かかった

（最終的にブラウザ機能で書き出して解決）。環境によっては

「PNGは出せない場合あり」を織り込んでおくと良い。

• 「◯字以内」「単一HTML」などの制約は、後出しだと効きが弱い。

制約は冒頭でまとめて渡すのが正解だった。

■ ③ 最初のコピペ用プロンプトへの改善案

（今の圧縮版は上級者向け。次の人には↓くらい噛み砕くと迷わない）

1. 1行目に「何を頼むプロンプトか」を平文で1文だけ添える。

例）「あなたはClaude Code。次の手順でカフェのHPを作って」

2. 略語は初出にカッコ書きで説明を付ける。

例）A2A（複数エージェントで分担）／ckpt（危険操作の前に確認）／

rev=cr+sr（コードレビュー＋セキュリティレビュー）

※初学者版なら、いっそ略語を消して普通の日本語にしてOK。

3. 「成果物」と「制約」を最初にリスト化する。

例）成果物＝①設計書 ②単一HTML／

制約＝白ベース・文字大きめ・外部連携なし・◯字以内

4. 進め方を明示：「まず設計書 → OKが出たら実装。

セクション（タブ）ごとに区切って、都度見せて」。

段階を刻むやり方は初学者にこそ効く。

5. 既存ファイルの扱いを1行入れる：

「作業フォルダの既存ファイルは変更せず、新規フォルダに作成」。

6. 最後の一手を書く：「完成したらブラウザで開いて」。

“開くところまで”を頼むと、完了が分かりやすい。

7. 字数制限・PNG必須などの変わった制約は、末尾ではなく冒頭にまとめる。

━━━━━━━━…

ひとことで言うと──

「設計書ファースト × 小さく区切る × 制約と成果物は最初に明記」。

この3点さえ守れば、圧縮プロンプトの中身が分からなくても

十分ちゃんと動きます。最初のプロンプトだけ平文に直しておくと、

次の人は詰まらないはずです。

━━━━━━━━…

以下、そのままコピペできるテキストです。（約2,800字）

• --

【Claude Codeをはじめる（課題1-1〜1-4）やってみた感想 / 次の人へのフィードバック】

■ 全体の印象

「日本語で指示するだけで、動くものがデスクトップに出てきてブラウザで開くまで」を一気にやってくれるのが想像以上に強力でした。コードを1行も書かず、シューティングゲーム→HP→その裏側の業務システム→この振り返り、と段階的に体験でき、"作れる範囲"の感覚がつかめます。まず手を動かす教材として良い流れでした。

━━━━━━━━━━━━━━━━━━

① やった課題

━━━━━━━━━━━━━━━━━━

• 課題1-1：HTMLで作り込んだオリジナルのシューティングゲーム。単一HTMLファイル1枚で、武器チェンジ・ボム・OVERDRIVE・ボス戦・スコア/コンボまで入り、完成後そのままブラウザで起動。
• 課題1-2：ホームページのデザイン。「DESIGN.md作成→美学プロンプト適用→セクション単位で実装」という手順を指定して、ドーナツ屋のLPを構築。設計書→実装の順で進むのを体感。
• 課題1-3：そのHPの"裏側"の業務システム。仕様駆動MVPとして、構成図(PNG)＋動く管理画面(5タブ・100点スコアリング・3層振分・承認フロー・在庫・顧客)を単一HTMLで作成。
• 課題1-4：この振り返りフィードバックの作成（いま書いているもの）。

━━━━━━━━━━━━━━━━━━

② 想定外だったこと

━━━━━━━━━━━━━━━━━━

＜スムーズだった所＞

• 「完成したらブラウザで開いて」まで書くと、ファイル作成〜起動まで自動で通る。自分で開かなくてよかった。
• 「単一HTML」「外部連携なし」と指定すると、画像やライブラリ無しで自己完結したものが出て、環境構築でつまずかない。
• 追加要望（タブ追加・色変更など）を後から会話で足せるので、完璧な最初の指示を作らなくても進められる。

＜詰まった/分かりにくかった所＞

• "内容"を指定し忘れると止まる：HPの課題でお題を「例：〜」のテンプレのまま送ってしまい、「何を作るHPか」を聞き返された。プレースホルダー([　]や「例：」)は必ず自分の言葉に置き換える必要がある。
• 略語・記号だらけの指示は伝わりにくい：最初のコピペ用プロンプトが「goal/Mon/batch/…→最適選択→…」のような超圧縮表記で、何を必須で求めているのか人間側も読み取りづらい。結果は出るが、意図とズレるリスクがある。
• 専門用語がそのまま出てくる：「STORE_KEY昇格」「A2A」「引継型ゲート」「localStorage」等、意味を知らないと"何が嬉しいのか"が分からない。動くが理解が追いつかない場面があった。
• Windows特有のつまずき：日本語を含む処理でファイルの文字コード周りがシビア。環境がWindowsだと、そのまま流用したコマンドが文字化けすることがある(裏側で調整は入るが、時間がかかる要因になり得る)。

━━━━━━━━━━━━━━━━━━

③ 最初のコピペ用プロンプトへの改善案

━━━━━━━━━━━━━━━━━━

1. 「お題」を最上段に、空欄必須で置く

　→ 冒頭に【作るもの：＿＿＿＿】を必ず1行入れ、「空欄のまま送らない」と注意書きを添える。例文は別行に小さく。これだけで"聞き返し"の1往復が消える。

2. 圧縮した略語は「日本語の箇条書き」に開く

　→ 「goal/Mon/batch…」のような記号列より、

• 必ず満たす条件(MUST)
• できれば満たす条件(WANT)
• 完成後にやること(例：ブラウザで開く)

　　の3ブロックに分けた方が、意図が正確に伝わる。

3. 専門用語には「ひとこと注釈」を付ける

　→ 例：「localStorage(＝ブラウザに保存)」「STORE_KEY(＝保存名。作り直しても消えない用)」。学習用途なら"用語＋かっこ書き"を推奨。

4. 「わからない所は先に質問して」と明記

　→ 一文「不明点や決めきれない所は、作り始める前に質問して」を入れておくと、勝手に進んで手戻りするのを防げる。

5. 環境を最初に伝える

　→ 「Windowsです」「出力先はデスクトップ」等を先頭で宣言。文字化けやパスのトラブルを予防できる。

6. 「完成後の受け取り方」まで書く

　→ 「単一HTMLで」「完成したらブラウザで開いて」「作った物のフルパスも教えて」をテンプレに固定。同じ品質で受け取れる。

＜改善版テンプレの例＞

──────────

【作るもの】＿＿＿＿＿（空欄のまま送らない／例：ドーナツ屋のHP）

【環境】Windows・出力先はデスクトップ

【MUST】単一HTMLファイル・日本語・白ベース・外部連携なし

【WANT】文字大きめ・スマホ対応

【完成後】ブラウザで開く／保存先のフルパスも教えて

※専門用語は初心者向けに一言説明を添えて。不明点は作る前に質問して。

──────────

━━━━━━━━━━━━━━━━━━

■ ひとことまとめ

━━━━━━━━━━━━━━━━━━

「お題を空欄で送らない」「略語より箇条書き」「完成後の受け取り方まで書く」——この3点を押さえるだけで、初回から狙い通りの成果物が出やすくなります。まずは1-1のゲームで"出てくる感覚"を掴み、1-3で"指示が細かいほど作り込める"ことを体験するのがおすすめです。

• --

コピペしやすいよう記号は控えめにしています。トーンを「です・ます／もっとカジュアル」に変える、文字数をさらに削る、といった調整もできます。

【Claude Codeをはじめる 課題1-1〜1-4 やってみた感想／次にやる人へのフィードバック】

■ 全体の印象

思っていた10倍サクサク進みます。「作って」と一言で、遊べるゲームや公開できそうなサイトが数分で出てきます。逆に言うと、こちらの指示があいまいだと“それっぽいけど微妙にズレたもの”が出てくるので、最初のひと言をどれだけ具体的に書けるかが全てでした。

━━━━━━━━━━━━━━━

① やった課題

━━━━━━━━━━━━━━━

• 課題1-1／シューティングゲーム

　→ HTML1枚でネオン風の縦シューを作成。敵の色と弾の色を合わせる独自ルールまで付いてきた。

• 課題1-2／ホームページのデザイン

　→ 「DESIGN.md（設計書）を作る→美学プロンプトを当てる→セクションごとに実装」の3ステップで、白ベースの絵師ポートフォリオ（作品10件）を作成。

• 課題1-3／ロゴの名前変更

　→ 画面のスクショに丸を描いて「ここを◯◯に変えて」と指示。サイト全体の名前を一括で差し替えてくれた。

• 課題1-4／サイトの裏側システム

　→ 依頼を自動採点して優先順位を付け、承認したら制作カンバンに流れる“管理ツール”をHTML1枚で作成。

━━━━━━━━━━━━━━━

② 想定外だったこと

━━━━━━━━━━━━━━━

＜詰まった所＞

• 入力例をそのまま送ってしまった

　プロンプト内の「例：これから絵師を目指す娘のポートフォリオ…」を、自分の内容に書き換えず送信。AIが「これは例ですか？本当に作る内容ですか？」と確認してきて一度止まった。カギカッコの中は“書き換える欄”だと気づきにくい。

• 呪文のような1行に戸惑う

　「CC(goal/Mon/batch/Plan/Hook…)」「仕様駆動MVP=level3」のような省略記号だらけの行は、正直まったく読めなかった。動きはするが、自分が何を頼んでいるのか分からないまま進む不安があった。

＜分かりにくかった言葉＞

• 「A2A」「引継型ゲート」「STORE_KEY昇格」など、英略語・専門用語がノー説明で出てくる。意味が分からなくても結果は出るが、後で人に説明できない。
• 「level3」が何を指すのか（難易度？完成度？）基準がどこにも書かれていない。

＜逆にスムーズだった所＞

• 日本語のやり取りは完璧。指示も回答も日本語で全く問題なし。
• スクショに丸を描いて「ここ」と指すやり方（課題1-3）が直感的で一番ラクだった。文章で場所を説明するより速い。
• 「完成したらブラウザで開いて」と書いておくと、最後に勝手に立ち上げてくれて確認がスムーズ。
• 途中で「作品10件」「白ベース」など数字と条件を入れておくと、ほぼ一発で望み通りになった。

━━━━━━━━━━━━━━━

③ 最初のコピペ用プロンプトへの改善案

━━━━━━━━━━━━━━━

次の人がつまずかないよう、テンプレを少しだけ直すと効果的です。

【改善案1】書き換え欄をひと目で分かるようにする

• Before：例：これから絵師を目指す娘のポートフォリオサイト…
• After：

　>>> ここを自分の内容に書き換えてください <<<

　【作りたいもの】＿＿＿＿＿（例：絵師のポートフォリオ）

　【入れる要素】＿＿＿＿＿（例：作品10件、白ベース）

　※「例：」の行は消して、自分の言葉に置き換える

【改善案2】呪文の1行に「日本語の一言メモ」を添える

• 省略記号の行の下に、狙いを1行で書いておくと安心。

　例）「CC(...)＝“最適な進め方を自動で選んで、危ない操作の前は確認して”という意味です」

• 初心者はこの1行を丸ごと消してもOK、と明記する。それだけで結果はほぼ変わらない。

【改善案3】専門用語に「かっこ書き」を1つ付ける

• A2A → A2A（AI同士の連携）
• 引継型ゲート → 承認したら次工程へ自動で渡す仕組み
• STORE_KEY昇格 → 保存データを新しい形式へ自動で移す

　意味が1行あるだけで「自分が何を頼んだか」が分かる。

【改善案4】「level」の基準表を最初に載せる

• level1＝動けばOK／level2＝見た目もそこそこ／level3＝人に見せられる完成度、のような一覧があると迷わない。

【改善案5】最後の一文を定型にする

• 「完成したらブラウザで開いて」を入れる欄として固定化。確認が一番ラクになるので、テンプレ側で最初から入れておくと親切。

━━━━━━━━━━━━━━━

■ ひとことまとめ

━━━━━━━━━━━━━━━

• 最大のコツは「カギカッコの中を、自分の言葉で・具体的な数字入りで書き換える」こと。ここさえ押さえれば、ほぼ一発で欲しいものが出ます。
• 呪文の行は“気にせず使ってOK、でも意味の一言があると安心”。次の人向けには、専門用語より「何がしたいか」を日本語で書ける欄を増やすのが効果的だと感じました。

① やった課題

1-1｜Claude Codeって何？を理解する：Skill・MCP・サブエージェントの違い、他アプリ（会計ソフト/LINE等）と連携して自動化できるイメージをつかむ。

1-2｜HTMLでシューティングゲームを作る：「オリジナルで作り込んで」と一言投げるだけで、単一HTMLのゲームが完成→ブラウザで起動まで。

1-3｜仕様書ベースでHPをデザインする：まずDESIGN.md（設計書）を作り、デザイン原則を適用してから、セクション単位でLPを実装。

1-4｜裏側システム（MVP）を仕様駆動で作る：略語だらけの仕様プロンプトを渡して、管理コンソール（動くHTML）＋構成図PNGを生成。

ざっくり言うと「①理解 → ②手を動かす → ③設計してから作る → ④仕様書で作る」と、だんだん本格化していく流れ。よくできてる。

② 想定外だったこと

詰まった所 / 分かりにくかった言葉

プロンプトの略語が最初サッパリ。rev=cr+sr STORE_KEY昇格 A2A 100点+3層振分 承認段階ゲート引継型 あたり、言葉の意味を知らないと「何を頼んでるのか」自体が分からない。Claudeは汲んで動いてくれるけど、こっちが何を受け取ったのか判断できないのがモヤる。

保存場所が最初あいまい。@"C:\...\フォルダ/" みたいに指定したけど、パスの末尾やバックスラッシュ/スラッシュ混在で「本当にここに出来てる？」と不安になった。フルパスをリンクで返してくれた時点で安心した。

「完成」の基準が人による。ゲームもHPも一発で動いたけど、「どこまでやったら課題クリア？」の合格ラインがない。動けばOKなのか、見た目まで詰めるのか迷った。

逆にスムーズだった所

丸投げでちゃんと動くものが出る。「凄いと思える業務効率化ツールにして」レベルのふわっとした指示でも、サンプルデータ入りで“それっぽく動く”モックが出てくる。ここは素直に感動ポイント。

ブラウザ自動オープンが地味に良い。作った後すぐ確認できて、達成感がある。

設計書（DESIGN.md）を先に作る流れが分かりやすかった。「いきなりコード」じゃなく「何を作るか文章化→実装」の順で、後から見返せる。

修正が速い。「絵文字が豆腐になってる」みたいな細かい不具合も、指摘したらすぐ直る。

③ 最初のコピペ用プロンプトへの改善案

いまのプロンプトは中級者向けの“呪文”になっていて、初回勢には壁が高い。以下を提案。

略語には初出で1行の注釈をつける

例：A2A（=複数のAIエージェントで分担） rev=cr+sr（=コードレビュー＋セキュリティレビュー）。

最悪、プロンプト末尾に「用語ミニ辞典」を3〜5行足すだけでも段違いに親切。

保存先を最初に固定文で明示する

「保存先：C:\Users\〇〇\プロジェクト名\（無ければ作成）／完成したらフルパスを返して」をテンプレの1行目に。パスは末尾スラッシュなし・バックスラッシュ推奨、と注記。

“完成の定義”を1文入れる

例：「完成＝ブラウザでエラーなく起動し、サンプル操作が一通り動くこと」。合格ラインが見えると初回勢が安心する。

難易度を選べるようにする

level1=まず動くだけ / level2=見た目も整える / level3=仕様書＋図解つき。1-4でいきなりlevel3は重いので、1-2はlevel1からにすると挫折しにくい。

「日本語で／カジュアルに」など出力の好みを冒頭にまとめる

トーン・言語・文字サイズ等をバラバラに書くより、共通ヘッダーとして固定した方がブレない。

最初のプロンプトだけは“平文フルバージョン”も併記する

略語版はコピペ用として残しつつ、隣に「＝略語を全部展開した普通の日本語版」を置くと、初回勢は平文を読んで意味を理解でき、2回目から略語版を使える。

まとめ（次にやる人へ一言）

最初のプロンプトの略語に飲まれないこと。意味が分からない単語があったら、そのままClaudeに「この○○って何？」と聞けば教えてくれる。丸投げでも動くものは出るので、まずは1-2のゲームで「あ、ほんとに動いた」を体験してから、1-3→1-4で“設計してから作る”に進むのがおすすめ。詰まったら遠慮なく途中でも質問すればいい。

課題フォルダ（Fable5/課題・AA）は空、チャット.txtも空だったので、実際に作られた成果物（シューティングゲーム／ホームページ／その裏側システム）と、今回の指示の出し方から実感ベースでまとめました。以下、そのままコピペできます。

• --

Claude Codeをはじめる（課題1-1〜1-4）をやってみた ― 次にやる人へのフィードバック

【はじめに】

プログラミングの知識がなくても、日本語で対話しながら「動くもの」が本当に出てくる体験でした。全体は想像よりずっとスムーズ。ただ、最初のコピペ用プロンプトに含まれる“専門用語の呪文”でつまずいたので、そこを中心に共有します。

■① やった課題（何を作ったか）

• 1-1 セットアップ／最初の一声：フォルダ指定ルール（CLAUDE.md・「フォルダは〇〇に」）を決めて、指示の出し方に慣れる
• 1-2 ミニアプリ：シューティングゲーム（HTML1枚）を作成
• 1-3 ホームページ：個人事業のDX支援サイト（デザイン設計→HTML/CSS/JS）を作成
• 1-4 その裏側システム：ホームページの“裏で回る”社内ツール（相談リード管理・案件パイプライン・自動化カタログ等）を作成

→「見た目（表）」から「仕組み（裏）」へ段階的に進むので、最後は達成感が大きいです。

■② 想定外だったこと

◇つまずいた所

• 最初のプロンプトが“圧縮された専門用語”の連続で、意味が分からないまま貼る形になりがち。例：
• 「仕様駆動MVP=level3」…どのレベルで何がどう変わるのか基準が不明
• 「承認段階ゲート引継型」…日本語だが業務用語で、完成物を見て初めて意味が分かった
• 「STORE_KEY昇格」「A2A」「🤖pt」「3層振分」…略語・記号が多く、初見では読めない
• 「out:図解PNG+動くHTML単一」…“単一”＝1ファイルで完結、の意味に気づきにくい
• 「フォルダは〇〇に」という冒頭指定を忘れると、意図と違う場所にファイルが作られる。ルールの存在を知らないと戸惑う。

◇分かりにくかった言葉

• MVP／localStorage／モーダル／マイグレーション（昇格）など、カタカナIT用語に注釈がない。
• 「confirm禁止」…そもそもconfirmが何かを知らないと、なぜ禁止かが分からない。

◇逆にスムーズだった所

• 「凄いと思えるツールにして」「サービス連携はまだ不要」「急ぎで」のような“ふつうの言葉”の追加指示が、そのまま正しく効いた。
• 「完成したらブラウザで開いて」と頼むと実際に開いてくれる。結果がすぐ見えて楽しい。
• 途中で仕様を足しても破綻せず反映される。最初に全部決めきらなくても走り出せる。

■③ 最初のコピペ用プロンプトへの改善案（次の人向け）

1) 呪文を“ふつうの日本語”に開く。用語の直後に一言注釈を付ける。

　例：「STORE_KEY昇格（＝保存データの引っ越し。古い保存形式を新しい形式へ自動変換すること）」

2) 記号・略語を減らす。

　「🤖pt」→「各画面にAIのおすすめ表示を置く」／「3層振分」→「点数で高・中・低の3グループに自動分類」

3) 作ってほしい成果物を、箇条書きで先頭に明示。

　例：「作るもの：①1枚で動くHTML　②その全体像を説明した画像1枚」

4) “レベル指定”には必ず基準を添える。

　例：「level3（＝サンプルデータ入りで、ひと通り操作できる完成度）」

5) 冒頭に必須ルールをテンプレ化。

　例：「フォルダは〇〇に。日本語で。まず“何を作るか”を1行で確認してから着手して。」

6) 上級プロンプトは別枠に。初回は「やさしい版」、慣れたら「圧縮版」の2段構えにすると挫折しにくい。

【まとめ】

「作りたいものを、ふつうの言葉で、少しずつ」で十分に動きます。次にやる人へ：最初のプロンプトの意味が分からなくても大丈夫。分からない単語は「それ何？」と聞けば説明してくれるので、“呪文はいったん質問してから貼る”のがおすすめです。

• --

文字数は約1,700字（6000字以内）です。ご希望あれば「もっと短く」「もっとやさしい言葉だけ」「箇条書きを増やす」等、調整します。

【Claude Codeをはじめる（課題1-1〜1-4）やってみた感想 ＆ 次の人へのフィードバック】

■ ①やった課題

• 課題1-1：HTMLで作り込んだオリジナルのシューティングゲームを作成 → 完成後ブラウザで表示
• 課題1-2：そのサイトの「裏側の運営システム」を仕様駆動でモック作成（5タブ／AIスコアリング／承認フロー／localStorage保存）
• 課題1-3：公式ホームページのデザイン（DESIGN.md作成 → Cookbookの美学プロンプト適用 → セクション単位で実装）
• 課題1-4：上記デザイン設計を「全部おまかせ」で通し実行し、Hero〜フッターまで一気に構築

いずれも「1つのHTMLファイル＋ブラウザで開く」という完結した形で成果物が出てくるので、初心者でも“動くもの”がすぐ手元に残るのが良かったです。

■ ②想定外だったこと

＜スムーズだった所＞

• 「〜を作って。完成したらブラウザで開いて」と最後に一言添えるだけで、生成→保存→自動でブラウザ表示まで一気通貫でやってくれた。手順を細かく指示しなくてよかった。
• ゲームやUIの「作り込み」の指示（例：パーティクル、効果音、ボス戦など）は、抽象的にお願いしても具体化して盛り込んでくれた。イメージ確認用のモックとしては十分すぎる完成度。
• 作り直しや一部修正の依頼にも、そのセクションだけ差し替えてくれるので試行錯誤しやすい。

＜詰まった所・分かりにくかった言葉＞

• 課題文の中に【例：〇〇に関するサイトを作成して】という“テンプレの例文”が残ったまま送ってしまい、「例をそのまま作るのか／自分の内容に差し替えるのか」で一度止まった。角カッコの中は“自分で書き換える欄”だと最初に気づけなかった。
• 「仕様駆動MVP=level3」「100点+3層振分」「承認段階ゲート引継型」「STORE_KEY昇格」など、省略記号だらけの呪文プロンプトは、コピペすれば動くものの“自分が何を頼んでいるのか”が読み解けなかった。結果は良かったが、意味が分からないまま投げている感覚が残る。
• 「CC(goal/Mon/batch/Plan/Hook…)」のような区切り羅列も同様で、初回はどれが必須指示でどれが任意なのか判別できなかった。
• 「先ほど作ったホームページ」という指示語が、直前に作ったゲームを指すのか、その前のデザイン相談を指すのか一瞬迷った（複数ファイルがある時ほど曖昧になる）。
• 成果物のファイル名（index.html／admin.html／home.html）が増えていき、「どれがトップページ？」が自分で管理しないと分からなくなった。

■ ③最初のコピペ用プロンプトへの具体的な改善案

角カッコの例文は「記入欄」だと明示する

　現状：作りたい内容 例：〇〇に関するサイト

　改善：作りたい内容（★ここを自分の言葉に必ず書き換える／未記入だと止まります）：____

　→ カッコを消し忘れて例のまま送る事故が防げる。

呪文プロンプトに“日本語の一行訳”を添える

　省略記法は残してよいので、その下に1行で意図を書く。

　例）仕様駆動MVP=level3 → 「ちゃんと動くたたき台を、仕様を決めてから作る」

　　　100点+3層振分 → 「100点満点で採点し、上位/中位/下位の3グループに分ける」

　→ 動かすだけでなく“何を頼んだか”が学べる教材になる。

最初に「今日のゴールと成果物」を1行で書く欄を用意する

　例）ゴール：____ ／ 出力形式：単一HTML＋ブラウザ表示 ／ ファイル名：____

　→ 指示語（「さっき作ったやつ」）に頼らず済み、ファイルの取り違えが減る。

「ブラウザで開いて」は定型フレーズとしてテンプレ末尾に固定しておく

　初心者は“開く”指示を忘れがち。プロンプト末尾に【完成したらブラウザで開く】を最初から入れておくと迷わない。

ファイル名ルールを課題冒頭で決めておく

　例）「トップページは必ず index.html、管理画面は admin.html にして」

　→ 課題が進んでファイルが増えても、どれが本番か一目で分かる。

「モック（イメージ確認用）」か「本番」かを最初に宣言する欄を作る

　今回は「連携はせず見た目だけ見たい」が後出しだった。先に書いておくと、余計な作り込みや連携実装で時間を使わず済む。

■ 総評

“動くものがすぐ出る”体験は初心者にとって最高のモチベーションになる一方、コピペ呪文プロンプトは「動くけど意味が分からない」状態を生みやすい。次にやる人には、（A）カッコ内は必ず自分の言葉に書き換える、（B）分からない専門用語は「これ日本語で言うと？」と一度聞いてみる、の2点を最初に伝えておくと、つまずかずに楽しめると思います。

以下、そのままコピペできる形でまとめました。

• --

# 「Claude Codeをはじめる」課題1-1〜1-4 やってみた感想（次にやる人へのフィードバック）

① やった課題（実際の流れ）

• 1-1｜環境に触る：Claude Codeを起動して、まずは「シューティングゲームを作って」レベルの1発依頼。単一HTMLがフォルダに生成され、ブラウザで動くところまで確認。
• 1-2｜LPを作る：「ユニコスクールのホームページ（LP）」を依頼。デザイン方針（美学プロンプト・カラー・タイポグラフィ）を`DESIGN.md`として残しつつ、`index.html`を生成。
• 1-3｜設計書を先に書く：いきなりコードではなく、`DESIGN.md`（デザイントークン・セクション構成）を土台にする「仕様駆動」の進め方を体験。
• 1-4｜裏側システムを作る：LPの業務システム（管理画面）を、圧縮した記法の指示（例：`仕様駆動MVP=level3 / 5tab / 100点+3層振分 / モーダル…`）で一気に依頼。図解PNG＋動く単一HTMLが出力され、ブラウザ確認まで。

一言でいうと「遊び（ゲーム）→見た目（LP）→設計→中身（システム）」と、対象が段々"本気の実務ツール"に近づいていく良い順番でした。

• --

② 想定外だったこと

### 詰まった・分かりにくかった所

• 「フォルダのどこに何が出来るか」が最初つかめない

依頼するとファイルがサッと生成されますが、初回は「これ、今どのフォルダに保存された？」が分からず不安に。1-1の段階で「作業フォルダはここ」「生成物はここに出る」を一度自分の目で確認する手順があると安心でした。

• 「単一HTML」「localStorage」などの言葉が前提知識扱い

スムーズに読める人はいいですが、初学者だと「単一HTML＝1ファイルで完結、ダブルクリックで開ける」「localStorage＝ブラウザ内にデータ保存（サーバー不要）」の注釈が1行あるだけで理解速度が段違いだと思いました。

• 圧縮記法の指示（1-4）が"読める人前提"

`100点+3層振分`『承認段階ゲート引継型』『STORE_KEY昇格』『A2A→open(フルパス+説明)』などは、意図が伝わればAI側は的確に汲んでくれますが、書く側の初心者には再現できない。「こういう風に短く書いても通じる」という到達点の例としては良いものの、最初の1回は普通の日本語で書く方が学びになります。

• 「サービス連携なし＝モック」の線引き

「Instagram連携して」等と書くと本当に繋ぎに行こうとするのか？と身構えました。実際は「一旦連携なしでイメージだけ」と添えれば綺麗にモック化してくれるので、"モックでいい"と明示するのがコツだと後で分かりました。ここは先に知りたかった。

### 逆にスムーズだった所

• 「完成したらブラウザで開いて」まで一括で頼める

生成→確認までAI側がやってくれるので、手戻りが少なく気持ちよかったです。

• `DESIGN.md`を先に作る流れ

いきなりコードにせず設計を言語化しておくと、後続の生成物の一貫性（色・余白・文言のトーン）が保たれて、"作り直し"が減りました。仕様駆動の恩恵を体感できます。

• 「凄いと思える業務効率化ツールにして」という抽象指示が効く

細かく指定しなくても、意図（＝実務で刺さるもの）を伝えると質が上がる。指示は"手順"より"狙い"を書くと良いと実感しました。

• 修正が対話で通る

図の絵文字が文字化け（□）したケースも、指摘したら即座に図形へ差し替え。1回で完璧を狙わず、出してから直す前提だと精神的にラク。

• --

③ 最初のコピペ用プロンプトへの改善案

現状の初回プロンプトは「作って」だけでも動きますが、次の人がつまずかないよう、最初のコピペテンプレに"前提の明示"を足すのを提案します。

### 改善版テンプレ（1-1〜1-2向け）

```

【作りたいもの】○○（例：シューティングゲーム／〇〇のLP）

【前提・お願い】

• 単一のHTMLファイル1つで完結させて（ダブルクリックで開けるように）
• 外部サービス連携はしない。まずは動くイメージ（モック）が見たい
• 日本語UI・白ベース
• 完成したら保存先フォルダのパスを教えて、ブラウザで開いて

【まだ決めてないこと】

• 細かいデザインは任せる。実務で"おっ"と思える質感で

```

### 改善のポイント（なぜ足すか）

1. 「モックでOK」を最初に宣言する欄を作る

→ 初心者が一番不安な「本当に外部と繋がっちゃう？」を先回りで解消。

2. 「保存先パスを教えて」を定型化

→ "どこに出来たか迷子"を防ぐ。1-1で必ず体験させる価値あり。

3. 専門用語には超短い注釈を添える文化にする

→ テンプレ自体に「単一HTML（＝1ファイル完結）」のように括弧書きの例を残しておくと、次の人が用語を覚えながら使える。

4. 「まだ決めてないこと」欄を用意する

→ 全部指定しなきゃ、というプレッシャーを外す。"狙いを伝えれば任せられる"という体験に繋がる。

5. 圧縮記法（`5tab/100点+3層…`）は"応用編"として別紙に

→ 1-4でいきなり出すと初心者は真似できない。「慣れたらこう短く書ける」という到達目標のサンプルとして、種明かし付きで最後に見せる構成が親切。

### 課題設計そのものへの小提案

• 1-1の最後に「生成されたファイルを実際に自分でダブルクリックして開く」ワンステップを必須化。"AIが開く"だけだと、自分で開く自信がつかないまま進んでしまう。
• 各課題の冒頭に「この課題で新しく出てくる言葉」を3語だけ先出し（例：1-3なら「仕様駆動 / DESIGN.md / トークン」）。読む前に地図があると迷わない。

• --

総評：進行順・題材はとても良く、"作って→見て→直す"のテンポが楽しい。あと一歩、用語の1行注釈と「モックでいい／保存先を教えて」の定型化があれば、非エンジニアでも詰まらず完走できると感じました。

• --

※文字数は約2,900字（6000字以内）です。もっと短く／箇条書き中心に、などの調整も対応できます。

━━━━━━━━━━━━━━━━━━━━━━━━━━

【Claude Codeをはじめる 課題1-1〜1-4 やってみた感想＆次の人へのフィードバック】

━━━━━━━━━━━━━━━━━━━━━━━━━━

■ ① やった課題（実際の流れ）

• 課題1-1：HTMLで作り込んだオリジナルのシューティングゲームを作成

　→「NEON VANGUARD」を単一HTMLで生成。ボス戦・パワーアップ・パーティクル演出まで一気に完成。最後にブラウザで自動オープンまでやってくれた。

• 課題1-2：そのゲームにBGMを追加

　→音源ファイルなしで、WebAudioによるシンセBGMをリアルタイム生成。ステージ／ボスで曲調が自動で切り替わる。ミュートボタンも付いた。

• 課題1-3：ホームページのデザイン（DESIGN.md作成 → 美学プロンプト適用 → セクション単位で実装）

　→「沖縄のパン屋・カフェ特集」を、白ベース・文字大きめの雑誌風レイアウトで作成。設計書(DESIGN.md)を先に作ってから本体HTMLを作る流れ。

• 課題1-4：そのHPの「裏側システム（管理ツール）」をモックで作成

　→店舗候補を100点採点→3層に振分→承認ワークフロー→公開、という編集業務ツールをlocalStorageだけで動く単一HTMLとして作成。構成図(PNG化ボタン付き)も同時生成。

総じて「指示 → 生成 → ブラウザで即確認」が1往復で回るのが気持ちよく、初学者でも“動くもの”がすぐ手元に残る点が最大の魅力でした。

■ ② 想定外だったこと

〈スムーズだった所〉

• 完成後に「ブラウザでOpen」まで自動でやってくれる。自分でファイルを探して開く手間がゼロ。
• 「BGM付けて」のような短い追加指示でも、既存ファイルを壊さず差分で足してくれる。作り直しにならない。
• 画像や音源を用意しなくても、コード（SVG・WebAudio・CSSグラデ）だけで“それっぽい”見た目・音が出る。素材集めが不要なのは想定以上に楽だった。
• DESIGN.md→実装、という「設計してから作る」流れが自然に踏めて、後から見返せる資料も残る。

〈詰まった所・分かりにくかった所〉

• 一番の壁は「呪文のようなプロンプト」。例：

　CC(goal/Mon/batch/Plan/Hook/Rule/Skill/Flow/allow/Mem/sec/task/Team/rw/rev=cr+sr/Ultra)…

　仕様駆動MVP=level3／5tab／100点+3層振分／承認段階ゲート引継型／STORE_KEY昇格／中規模A2A…

　→ 略語・記号が多く、初見では意味が取れない。何を頼んでいるのか人間側が説明できないまま進む感覚があった。

• 「A2A」「FO(ファンアウト)」「rev=cr+sr」「Ultra」など、Claude Code特有の内部機能名がそのまま並ぶと、初心者は“使うべきかどうか”の判断ができない。
• 「図解PNG」を求めても、実際に出てくるのは「PNG保存ボタン付きHTML」で、ワンクリック必要。“PNGファイルが直接できる”と思っていると軽い肩透かし。ここは仕様上の制約なので、最初から期待値を合わせておくと良い。
• 成果物が増えると（HP・CMS・図解・DESIGN.md）どのファイルが何だったか見失いやすい。ファイル名は自分で指定した方が後で楽。

■ ③ 最初のコピペ用プロンプトへの具体的な改善案

【改善の方針】略語を捨てて「日本語＋箇条書き」で頼む。Claudeは省略記法がなくても十分賢いので、暗号化するメリットは薄い。むしろ人間が後で読み返せる形にした方が学びになる。

▼ Before（詰まりやすい例）

　「仕様駆動MVP=level3。out:図解PNG+動くHTML単一(localStorage/JP/白)・5tab・100点+3層振分…中規模A2A→open」

▼ After（おすすめテンプレ）

• -------…

　# 作ってほしいもの

　（例）先ほどの特集サイトの「管理ツール」をモックで作って

　# 成果物の形式

• 単一のHTMLファイル1つ（外部サービス連携はなし＝ダミーでOK）
• データ保存はブラウザのlocalStorageだけ
• 日本語UI／白ベース／文字大きめ
• 完成したらブラウザで開いて

　# 中身の要件

• タブは5つ（①…②…）
• 店舗を100点満点で採点し、3段階（特選/候補/見送り）に自動分類
• サンプルデータを10件くらい入れておいて
• 確認ダイアログはブラウザ標準ではなく画面内モーダルで

　# ファイル名

　shimapan-cms.html にして

• -------…

【個別の改善ポイント】

略語は最初の1回だけ日本語で定義する。

　例：「A2A（=作業を複数エージェントに分担）は今回は不要」など、使う/使わないを明示すると暴走しない。

「out:」より「# 成果物の形式」のように見出しで区切る。Claudeは箇条書き＋見出しの指示に強い。

期待する“最終ファイルの形”を先に書く（PNGなのかHTMLなのか）。「PNGで欲しい」なら「画像ファイルとして保存できるように」と一言添える。

ファイル名を指定する。成果物が増えても迷子にならない。

「凄いモックにして」だけだと方向がぶれやすい。“誰のどんな作業がラクになるか”を1行足すと質が跳ね上がる。

　例：「編集部が候補店の選定〜公開まで一気に回せる感じで」。

詰まったら「今の指示、意味が通じてる？分かりにくい所を指摘して」と聞き返してOK。Claude側が言い換えてくれる。

【次にやる人へのひとこと】

最初の呪文プロンプトは“上級者の時短メモ”だと思って、真似する前に一度日本語へ翻訳してから使うのがおすすめ。意味を理解して打つと、出力の良し悪しも自分で判断できるようになります。まずは「作って→開いて→気になった所を一言で直してもらう」の小さい往復を数回回すのが、いちばん上達しました。

以下、そのままコピペできる形でまとめました。

• --

【フィードバック】Claude Codeをはじめる（課題1-1〜1-4）をやってみて

■ ① やった課題

• 1-1：ランドクルーザー300の紹介HP制作。「DESIGN.md作成 → Claude Cookbookの美学プロンプト適用 → セクション単位で実装（白ベース・文字大きめ）」という流れ指定。
• 1-2：そのHPに「イメージ画像を生成して貼り付け」。
• 1-3：HPの裏側システム（問い合わせ・試乗予約を捌く営業管理ツール）を「仕様駆動MVP＝level3／5タブ／100点スコア＋3層振分／localStorage」等の指定で制作。
• 1-4：この振り返りフィードバック作成。

いずれも、最初に渡されたコピペ用プロンプトの冒頭に「CC(goal/Mon/batch/Plan/Hook/Rule/Skill/…)」のような記号だらけの1行がついている形式でした。

■ ② 想定外だったこと

＜詰まった・分かりにくかった＞

• 冒頭の「CC(goal/Mon/batch/…)」「中規模A2A→open」などの呪文行が最大の壁。何を指示しているのか初見ではまったく読めない。実際にはClaudeが趣旨を汲んで動いてくれたが、「これは自分が理解して書き換えるべきものなのか、おまじないとして貼るだけでいいのか」が分からず不安になった。→ 結論：貼るだけでも動くが、意味が分からないまま貼るのは怖い。
• 略語・専門用語が多い。「STORE_KEY昇格」「承認段階ゲート引継型」「3層振分」「A2A」「各画面🤖pt」など、初学者には注釈なしだと厳しい。意味を知っていれば強力だが、はじめての人向けの課題としては説明が要る。
• プロンプト内の「[ホームページで作りたい内容 例：ランドクルーザー300]」というプレースホルダーを、うっかり空欄のまま送信してしまった。→ Claudeがフォルダ名から推測しつつ「主題はどれ？」と質問し直してくれて助かったが、「[ ]は自分で書き換える箇所」と気づきにくい。
• 「Claude Cookbookの美学プロンプトを適用」が、具体的にどのプロンプトを指すのか曖昧。→ Claudeが美学原則（余白・階層・抑制など）を自分で解釈してDESIGN.mdに落としてくれた。結果は良かったが、「自分で何かを用意して渡す必要があるのか？」と一瞬迷った。
• 「イメージ画像を生成して」→ 実際には画像生成ツールが無く、CSS/SVGのイラストで代替された。実写は出ない。「画像＝写真が出る」と期待するとギャップがある。
• 「図解PNG」→ PNG変換ツールが標準では無く、Claudeがブラウザ機能を使って生成。少し手間と時間がかかった。最初からSVGでOKなら早い。

＜逆にスムーズだった＞

• 「白ベース」「文字大きめ」「日本語」「localStorageで保存」など、平易な言葉の指示は一発で正確に反映された。専門用語よりこういう普通の言葉の方が確実。
• 「セクション単位で実装」「5タブ」など構造の指定は明確で、迷いなく形になった。
• DESIGN.md → 実装、という段取り自体は分かりやすく、成果物が積み上がる感覚があって良かった。
• 完成後にブラウザで自動で開いてくれるので、結果をすぐ確認できた。

■ ③ 最初のコピペ用プロンプトへの改善案

1. 冒頭の「CC(…)」呪文行は、初回用では削るか、平易な1文に置き換える。

　例：「最適な進め方を選び、危険な操作の前は確認、完了後に選定理由・結果・要約を報告して」

　→ 記号の羅列より、日本語の平文の方が初学者は安心して使える。

2. プレースホルダーは「ここを書き換える」と明示する。

　例：「◆ここに主題を書く→（　　　）　例：ランドクルーザー300の紹介HP」

　空欄で送ると止まるので、記入必須と分かる書き方にする。

3. 専門用語には最小の注釈を添える。

　例：「3層振分（点数でホット/ウォーム/コールドに自動仕分け）」「STORE_KEY昇格（保存データのバージョンを上げて移行）」。用語は残してよいが、初回だけ括弧書きがあると学べる。

4. 「Claude Cookbookの美学プロンプト」は、期待を具体化する。

　例：「余白広め・色数を絞る・文字階層で見せる、を意識して」。抽象名だけでなく中身を1行で。

5. 画像の期待値を先に書く。

　例：「画像は写真生成ではなくSVGイラストで作成し、後から実写に差し替えられるよう<!-- IMG -->で印を付けて」。これで「写真が出ない」ギャップが消える。

6. 出力形式を先に固定する。

　例：「成果物：単一HTML（外部依存なし）＋図解はSVGで。PNGが必要なら別途変換」。図解はSVG優先にすると速い。

7. 課題の狙いを1行添える。

　例：「この課題で体験してほしいこと：仕様書→実装の流れと、白ベースの余白設計」。何を学ぶ回か分かると取り組みやすい。

■ ひとことまとめ

「平易な日本語の指示は超スムーズ、記号・略語の呪文は初回はつらい」。次の人には、冒頭の呪文を平文化し、[ ]の記入箇所と用語注釈を足すだけで、体験がぐっと親切になります。成果物が段階的に積み上がる流れ自体はとても良い課題でした。

この課題をやってみた「あなた自身の体験」を次の人向けにまとめる、というご依頼ですね。作った成果物（fukuoka-tripサイト、prism-strikerゲーム、architecture図など）は確認できましたが、あなたが実際にどこで詰まったか・どの言葉が分かりにくかったかは成果物からは分かりません。ここが②の核心なので、数点だけ教えてください。

不明な点は「よくある初心者のつまずき」で埋めて書くこともできますが、それだと"あなたの感想"ではなく一般論になってしまうので確認します。

以下、そのままコピペできるテキストです。あなたの回答（詰まりなくスムーズ／HTML一発・日本語会話・やり直しの楽さが好印象／初期プロンプトはそのままで十分）をベースに、次の人向けの改善案を足してまとめました。

• --

【Claude Codeをはじめる（課題1-1〜1-4）やってみた感想 — 次にやる人へ】

■ ①やった課題（ざっくり）

Claude Codeを起動して、日本語で指示を出しながら成果物を作っていく一連の流れをやりました。実際に手元にできたのは、

• ミニゲーム（1画面のブラウザゲーム／HTML1枚で動くやつ）
• 旅行プラン紹介サイト（福岡2泊3日）— まず DESIGN.md で「色・フォント・余白の方針」を決めてから index.html を作る流れ
• そのサイトの管理画面（ops-admin）っぽいページ
• 構成図（architecture の図とHTML）

という感じで、「①設計を言葉で決める → ②作らせる → ③気に入らない所を直す」を1〜4で少しずつ体験する構成でした。

ポイントは、コードを自分で書く課題ではないこと。日本語で「こういうのが欲しい」と伝えると、Claude側がファイルを作ってくれます。なので身構えなくて大丈夫です。

■ ②想定外だったこと（詰まった所・分かりにくかった言葉・スムーズだった所）

▼ 良い意味で想定外だった所（ここが一番の感想）

• とにかく一発で「形」になる。

「福岡の旅行サイト作って」くらいのざっくり指示でも、いきなりちゃんと見た目のあるHTMLが出てきて驚きました。プログラミング＝真っ白な画面から自分で書く、という先入観がある人ほど、ここでハードルが下がると思います。

• 全部日本語の会話でいい。

英語もコマンドの暗記も要りません。「もう少し余白を広く」「ここの色を朱色に」みたいな、人に頼むのと同じ言い方でちゃんと伝わります。専門用語を知らなくても進められました。

• やり直し・修正がとにかく楽。

失敗を恐れなくていいのが一番大きいです。「やっぱりこの見出し大きすぎるから戻して」と言えばすぐ直るし、丸ごと作り直しも一言。1回で完璧を狙わず、「まず出してもらって→見て→直す」を繰り返す方が結果的に速くて気楽でした。

▼ 詰まった所

• 正直、大きく詰まる所はありませんでした。 環境準備も起動も、最初のコピペ用プロンプトを貼るところも、指示どおりでそのまま進めました。次にやる人も「手順どおりやれば普通に進む」と思って大丈夫です。

▼ ただ、初めての人が一瞬「?」となりそうな言葉（先回りメモ）

自分は流れで理解できたけど、まったくの初心者だと最初だけ引っかかるかも、という単語を置いておきます：

• リポジトリ／ディレクトリ … だいたい「作業するフォルダ」のこと。
• コミット … 「ここまでの状態を保存する区切り」のイメージ。今すぐ深く理解しなくてOK。
• プロンプト … Claudeへの「お願いの文章」。この課題でコピペするあの文がそれです。
• DESIGN.md の「.md」… ただのメモ書き用テキストファイル（マークダウン）。設計方針を先に言葉で書いておく紙、くらいの感覚。

この4つだけ何となく分かっていれば、止まらずに最後まで行けます。

■ ③最初のコピペ用プロンプトへの具体的な改善案

「そのまま使えて十分」だったのが前提の上で、次の人がもっと迷わないための"あったら親切"を挙げます。

1. プロンプトの最初に「これは何をする文か」を1行入れる

例：「※以下はClaudeへの最初のお願い文です。丸ごとコピーして貼り付け、Enterを押すだけでOK」。

→ 貼っていいのか自分で書き換えるのか、最初だけ迷う人がいそうなので、この一言で安心できます。

2. 「自分で変えていい所」を【　】で明示する

例：作るテーマ名や色を【ここを好きな言葉に変えてOK：例）福岡の旅行サイト】のように囲っておく。

→ どこがテンプレでどこが自由記入かが一目で分かり、アレンジのハードルが下がります。

3. 「1回で完璧を目指さなくていい」を明記する

プロンプト末尾か課題の冒頭に「まず出させて、気に入らなければ日本語で直してもらえばOK。やり直しは何度でも自由」と書く。

→ 実際これが一番の学びだったので、最初に言われていたらもっと早く気楽に触れたと思います。

4. 専門用語に最小限の注釈（ふりがな的な補足）を付ける

上の②であげた「リポジトリ／ディレクトリ／コミット／プロンプト」に、初出だけ（＝作業フォルダ）のようなカッコ書きを添える。

→ 意味を調べに離脱するのを防げます。

5. 「詰まったらこう言えばいい」の逃げ道を1行

例：「うまくいかない時は Claude にそのまま『さっきのがエラーになった、直して』『もう一度最初から作って』と日本語で言えばOK」。

→ 初心者の一番の不安は"詰まったら終わり"なので、復帰方法が書いてあると安心感が段違いです。

■ まとめ（次にやる人へ一言）

コードを書く覚悟をして臨むと拍子抜けするくらい、日本語の会話だけで成果物ができます。コツは「いきなり完璧を狙わず、まず出させて→見て→直す」。この課題1-1〜1-4は、その"AIに頼んで作る感覚"を掴むのにちょうどいいので、気負わずどんどん指示を出して、遠慮なくやり直してみてください。

• --

字数は約1,900字（6000字以内）です。トーンを「もっとカジュアルに」「箇条書きを減らして文章多め」等の調整があれば言ってください。

「Claude Codeをはじめる（課題1-1〜1-4）」やってみた感想・次の人へのフィードバック

① やった課題（実際にできたこと）

1-1 DESIGN.md作成：サイトのコンセプト・配色・タイポ・情報設計を1枚のMarkdownにまとめた。ここを先に作ると後がブレない。

1-2 美学プロンプトの適用：「白ベース・文字大きめ」を軸に、汎用的なAIっぽい見た目を避ける方針（余白／差し色1色／タイポ主役）をDESIGN.mdに落とし込んだ。

1-3 セクション単位で実装：Header→Hero→一覧→ランキング→Footer…と、1セクションずつHTML/CSSを組んで公開サイト(index.html)を完成。

1-4 裏側システム(MVP)：フロントの運用を回す管理コンソール(admin.html)を単一HTMLで構築。5タブ・100点採点＋3層振分・承認ワークフロー・localStorage保存・全体図PNGまで一式。

→ 結論：「設計→美学→実装→裏側」の順番通りに進めれば、ちゃんと動くものが最後まで出る。課題の流れ自体はよくできている。

② 想定外だったこと

■ 詰まった所

お題の“記入欄”を埋め忘れると事故る：最初のプロンプトに [作りたい内容 例：〜] という空欄＋例文が残ったまま送ると、例文がそのままお題として扱われる。しかも例がアダルト系だったため、実在人物のプライバシー・著作権の観点で2回突き返された。ここで一番時間を溶かした。自分が作りたい題材を最初にハッキリ書けば一発で進む。

図解のPNG化：ブラウザ(Edge)をheadlessで動かして画像化したが、Edgeが普通に起動中だとプロファイルがロックされて生成に失敗した。「一時プロファイルを指定する」で解決したが、初見だと原因が分かりにくい。

フォント待ち：日本語フォントの読み込み前にスクリーンショットを撮ると文字化け気味になる。少し待つ指定が要る。

■ 分かりにくかった言葉（略語が多い）

最初のプロンプトが超圧縮されていて、初見だと解読に一拍かかった。特に：

100点+3層振分 … 100点満点で採点し、S/A/Bの3ランクに自動分けする、の意味

承認段階ゲート引継型 … 下書き→審査→承認→公開と、担当者を次工程へ引き継ぐ承認フロー

STORE_KEY昇格 … 保存キーにバージョンを持たせ、旧バージョンのデータを自動移行する

A2A … サブエージェントに分担させる（今回は単発なので使わず）

confirm禁止 … ブラウザ標準の確認ダイアログを使わず独自モーダルにする

🤖pt … 各画面にAIアシスト（提案）を常設する

意味が分かれば妥当な指示だが、略語の意味を知らないと自分でカスタムしづらい。

■ 逆にスムーズだった所

「白ベース・文字大きめ」のような具体的で短い見た目指定は一発で反映された。

セクション単位で実装を指定したので、1画面が大きくなっても破綻せず、後から直しやすかった。

DESIGN.mdを最初に作る流れのおかげで、色やフォントの指定がブレず一貫した。

依存ライブラリなしの単一HTML＋localStorage指定は、環境構築ゼロですぐブラウザで動くので気持ちいい。

③ 最初のコピペ用プロンプトへの改善案

1. 記入欄は「例」を消して自分の題材で埋める（最重要）

[作りたい内容 例：〜] の“例”を残さない。例文がそのままお題化する。加えて、実在の人物・作品を無断でまとめる系は権利面で断られるので、架空キャラ／自作コンテンツ／作品レビュー等の合法な題材を最初から指定する。

悪い例：[作りたい内容 例：人気の○○まとめ]（空欄のまま送信）

良い例：作りたい内容：日本ドラマのレビューまとめサイト（作品名はすべて架空サンプル）

2. 略語には1行の凡例を付ける

プロンプト末尾に「用語メモ」を足すだけで、後で自分で改造しやすくなる。

例：※用語:100点+3層=100点満点でS/A/B自動振分 / 承認ゲート引継=下書→審査→承認→公開で担当引継 / STORE_KEY昇格=保存キーにver付け旧データ自動移行

3. 出力先と技術制約を先に固定する

後出しで迷わないよう最初に書く。

例：出力先:drama-reviews/ フォルダ / 構成:単一HTML＋CSS、ビルド不要 / 保存:localStorubuntu / 言語:日本語 / 配色:白ベース

（※上記のlocalStorageのように、キー名や技術名はタイポに注意。1文字違うと意図がズレる）

4. 「画像を出す」なら方法も一言添える

図解PNGが欲しい場合は「HTMLで図を描いてEdge/Chromeのheadlessでスクショ→PNG化。ブラウザ起動中でも失敗しないよう一時プロファイルを使う」まで書いておくと、詰まらずに出る。

5. 完成条件（Doneの定義）を箇条書きで置く

「5タブある／サンプル10件入っている／ブラウザで開ける」のようにチェックできる形で書くと、抜け漏れが減り、最後に自分で検収しやすい。

ひとことまとめ

課題の流れ（設計→美学→実装→裏側）は完成度が高く、指示通りに進めれば動くものが最後まで出る。次にやる人は 「お題の記入欄を“例”ごと自分の言葉で埋める」「略語に凡例を付ける」「出力先とDone条件を先に固定する」 の3点を押さえると、突き返しや手戻りがほぼ消えてスムーズに完走できるはず。

Claude Codeをはじめる（課題1-1〜1-4）やってみた感想＆次にやる人へのフィードバック

① やった課題

1-1：HTMLでオリジナルのシューティングゲーム制作（完成後ブラウザで自動オープン）

1-2：ホームページのデザイン（DESIGN.md作成 → Claude Cookbookの美学プロンプト適用 → セクション単位で実装。今回は「原宿のバズりスイーツ店LP」を白ベース・文字大きめで）

1-3：そのHPの裏側システムを仕様駆動MVP(level3)で構築（5タブ管理ツール／100点採点＋3層振分／承認ゲート／localStorage／図解PNG）

1-4：この振り返り（次にやる人向けフィードバックのまとめ）

いずれも「1つのプロンプト → 実物が動いてブラウザで開く」まで到達できました。手を動かさずにゲーム／LP／業務ツールが形になるのは素直に驚きます。

② 想定外だったこと

【詰まった所】

「図解PNG」の出力が環境依存でつまずきました。手元にPythonの画像ライブラリやImageMagickが無く、Claudeが自動で「canvasで描画してPNGダウンロードさせる方式」に切り替えて対応。結果は出ますが、PNGが即ファイルとして手に入るとは限らないと知っておくとよいです。

題材のプレースホルダ（例：原宿の…）を「例のまま」送ってしまい、Claudeから「題材はどれ？」と1回確認が入りました。止まるわけではないですが、ひと手間発生します。

【分かりにくかった言葉】

課題プロンプトが略記だらけで、初見だと意味を取りづらいです。特に：

「STORE_KEY昇格」→ 保存データのスキーマ移行（バージョンアップ対応）のこと

「承認段階ゲート引継型」→ 受付→採点→担当→店長→公開と段階承認し、都度担当者へ引き継ぐ流れ

「3層振分」→ スコアでS/A/Bに自動仕分け

「各画面🤖pt」→ 各画面にAI活用ポイントを明示

「A2A」「Flow FO」「rev=cr+sr」「Ultra」など英字略語が説明なしで並ぶ

「level3」も、どこまで作れば3なのか基準が曖昧でした（結果は良かったが、粒度は運まかせになりがち）。

【逆にスムーズだった所】

「白ベース」「文字大きめ」「5タブ」「localStorage」「サンプル5〜15件」のように“具体的な数値・見た目”で指定した部分は、迷いなく一発で反映されました。曖昧な形容詞より数字が効きます。

「完成したらブラウザでOpen」が明確なので、成果物をすぐ確認できて達成感がありました。

途中で選択肢を聞いてくれる（題材・規模を2択で確認）ので、丸投げでも脱線しませんでした。

③ 最初のコピペ用プロンプトへの改善案

【プレースホルダは埋めてから送る】

「[作りたい内容 例：…]」は“例”ではなく自分の題材に置き換えて送る。埋めれば確認の1往復が消えて速くなります。埋めずに使うなら「例のままでOK」と一言添える。

【略語には最小限の注釈を付ける】

略記は残してよいので、末尾に用語ミニ辞書を1行ずつ足すのがおすすめ。例：

「STORE_KEY昇格＝保存データのスキーマ移行 / 3層振分＝S/A/Bに自動仕分け / 承認ゲート引継＝段階承認で担当者を順送り / 🤖pt＝各画面にAI活用ポイント表示」

これだけで再現性と“意図どおり率”が上がります。

【「PNG」など出力形式は逃げ道を用意する】

環境に画像変換ツールが無い場合があるため、

「図解はPNG（不可ならSVGやcanvasダウンロードで代替可）」のように代替を許可しておくと止まりません。厳密にPNGが必要なら「事前に画像出力できる環境か確認してから進めて」と指示する。

【「level3」の中身を1行で定義する】

例：「level3＝主要機能が実際に動く＋サンプルデータ入り＋簡単な状態保存まで」。到達ラインを言語化すると、成果物の粒度がブレません。

【効いた指定は“型”として使い回す】

「白ベース／文字大きめ／◯タブ／サンプル◯件／完成後ブラウザでOpen」はそのまま流用OK。数値と見た目を具体で書くほど一発で決まります。

【最後に必ず「レビュー＆自己チェック」を頼む】

「仕様に対する適合チェック表を最後に出して」と足すと、抜け漏れを自分で確認してくれて安心です。

ひとことまとめ

「曖昧な形容詞は確認が入り、具体的な数値・出力先・チェック依頼は一発で通る」。次にやる人は、プレースホルダを埋める・略語に1行注釈・出力形式に代替を用意、の3点だけ意識すれば、かなりスムーズに進められます。

■ ①やった課題（成果物ベースの振り返り）

課題1-1：1枚もののシューティングゲーム（shooting-game.html）を作成。HTML/CSS/JSが1ファイルに入った、ブラウザで即動くものができました。「まず1個動くものを作る」体験として最適でした。

課題1-2：ゲームブログ「BUZZ GAME LAB」を複数ページで構築（index / articles / article / about ＋ 共通styles.css）。先に DESIGN.md（設計メモ）を作ってから各ページを実装、という流れ。デザインの美学ガイド（Claude Cookbookのフロントエンド美学プロンプト）を取り込んで「白地に紫グラデの量産型」を避ける、といった指定もしました。

課題1-3：管理画面 admin.html を作成。表示するだけのページから一歩進んで「機能っぽい画面」に。

課題1-4：admin画面の構成図（admin-architecture.svg → png）を作成。図をSVGで作り、コマンドで画像に書き出す、というAIに図まで作らせる体験。

→ 全体として「①1枚もの → ②複数ページサイト → ③管理画面 → ④図」と、難易度と成果物の種類が少しずつ広がる、よくできた順番でした。

■ ②想定外だったこと

＜詰まった所＞

「許可（permission）」のポップアップが何度も出て戸惑う。ファイルを開く・ネットにアクセスする・画像変換する等のたびに「許可しますか？」と聞かれ、最初は「これは押していいやつ？危なくない？」と手が止まりました。→ 事前に「操作のたびに確認が出る。基本はAllowでOK」と一言あれば安心でした。

生成が終わるまでの「待ち時間」が想定外。長い出力だと数十秒〜黙って待つ場面があり、「固まった？」と不安に。→「今作ってます、待てば出ます」が体感で分かりづらい。

ブラウザでの「確認のしかた」でつまずく。作った後どうやって見るの？ が最初あいまい。ファイルをダブルクリックで開く／自動で開くのどちらなのか迷いました。

複数ページのとき、どのファイルを直しているのか見失いがち。「index直して」と言ったつもりが別ページの話になる等、指示の対象がズレることがありました。

図（課題1-4）でSVGやコマンド変換が出てきた瞬間、急に専門度が上がって置いていかれる感覚。

＜分かりにくかった言葉＞

「デザイントークン」「CSS変数」「支配色／アクセント」…DESIGN.mdに出てくる用語が初心者には未知。意味が分からなくても進むが、モヤっとする。

「美学プロンプトを適用」「Cookbook」など、元ネタを知らないと何のことか不明。

「セクション単位で実行」など、AI側の作業の区切り方の言葉がピンとこない。

＜逆にスムーズだった所＞

最初の1枚もの（シューティングゲーム）は、雑に頼んでもちゃんと動くものが出てきて感動。ここで一気に「使える！」となりました。

「〜を直して」「もっと〜して」の自然な日本語で修正が通るのが快適。プログラミング用語を知らなくても会話で直せる。

DESIGN.mdのように「先に設計書を書いてから作る」流れは、出来上がりの一貫性が高く、途中でブレにくかったです。

図を自動で作ってくれるのは素直にすごく、達成感がありました。

■ ③最初のコピペ用プロンプトへの改善案

（次の人が最初にコピペする1文に、以下を足すと詰まりが減ります）

「確認ポップアップは基本Allowで進めてOK」を最初に明記

例：「作業中に『許可しますか？』と何度も聞かれます。ファイルを開く・画像を作る等の操作なので、基本は『Allow（許可）』を押して進めてください。」

→ ②で一番多かった「押していいか不安で止まる」を先回りで解消。

「作ったら自動でブラウザ表示して」を1行入れる

例：「HTMLができたら、その場で開いて見られるようにブラウザで表示してください。」

→ 「どう確認するの？」問題が消えます。

「専門用語が出たら1行で説明を付けて」と頼む

例：「デザイン用語やカタカナの専門語を使うときは、初心者向けに一言かっこ書きで意味を添えてください。」

→ DESIGN.mdの「トークン」「支配色」等が怖くなくなります。

「今どのファイルを触っているか、ひとこと言って」を追加

例：「複数ファイルを編集するときは、『今 index.html を直しています』のように対象を教えてください。」

→ 対象ズレ・迷子を防止。

進め方を「一気に全部」ではなく「1個ずつ見せて」に

例：「いきなり全部作らず、まず1ページ（または1機能）だけ作って見せて、OKが出たら次に進んでください。」

→ 待ち時間の不安が減り、途中で軌道修正しやすい。

ゴール像を最初に握るための穴埋めテンプレを用意

例：「以下を埋めてから渡してください →【作りたいもの】【1ページ or 複数ページ】【雰囲気（例：明るい／落ち着いた）】【入れたい要素】」

→ 課題1-2以降の「何を頼めばいいか分からない」を軽減。

＜まとめ＞

順番と成果物の設計はとても良いです。改善は中身より「最初の1文に“安心のための注意書き”を足す」だけで、初心者の手が止まる回数がかなり減ると感じました。特に(1)許可ポップアップ と (2)ブラウザ表示 の2つは、最初に書いておくだけで体験が大きく変わります。

以下、そのままコピペできるテキストです（約3,900字）。

• --

【Claude Code をはじめる｜課題1-1〜1-4 やってみた感想・次の人へのフィードバック】

■ ① やった課題（実際の流れ）

• 1-1：Claude Code の起動と基本操作の確認。作業フォルダを指定してチャットで指示を出す、という流れをまず体験。
• 1-2：ホームページのデザイン制作。「DESIGN.md作成 → 美学プロンプト適用 → セクション単位で実装」の3ステップで、架空のスイーツ店サイトを1枚のHTMLで作成。「白ベース・文字大きめ」など具体指定あり。
• 1-3：そのサイトの“裏側システム”をモックで構築。5タブの店舗管理ツール（自動採点→振り分け、承認フロー、AIアシスト等）を単一HTML＋localStorageで作成。図解PNGも生成。
• 1-4：この課題全体の感想を、次の人向けフィードバックとしてテキストで整理（＝今これ）。

総じて「1回の指示で、設計書→実装→ブラウザ表示まで一気に出てくる」体験は率直にすごい。手を動かす前に完成物が見えるので、方向修正が速い。

■ ② 想定外だったこと

〈詰まった・戸惑った所〉

• 作業フォルダに、課題と全く関係ないファイル（別の作りかけ）が最初から入っていた。放っておくと上書きで消える可能性があり、「今あるファイルは何か」を最初に確認する一手間が要った。次の人も、まずフォルダの中身を見てから始めるのが安全。
• 開発サーバーのポートが別のチャットと衝突して一度立ち上がらなかった。プレビューが出ないと焦るが、ポート番号を変えれば解決する類の話。
• 画面キャプチャ（スクリーンショット）機能がこの環境ではタイムアウトして使えなかった。ただし中身の確認自体は別の方法（テキストでの構造確認）で代替でき、成果物の検証には支障なし。「スクショが撮れない＝失敗」ではない。
• 「図解PNG」を作る所で、一般的な変換コマンドが実はWindows標準の同名コマンドで使えず、別手段（ブラウザで画像化）に切り替える必要があった。ツールの“ある/なし”は環境次第なので、最初から特定コマンドに依存しない指示が無難。

〈分かりにくかった言葉〉

• 最初のコピペ用プロンプトが超圧縮の記号表記（例：「CC(goal/Mon/batch/Plan/Hook/…/rev=cr+sr/Ultra)」「中規模A2A→open」「rev=cr+sr」）。AI側は解釈して動いてくれるが、人間には“何をお願いしているのか”がほぼ読めない。次の人が内容を理解・改変しづらい。
• 「A2A（エージェント間連携）」「トリアージ」「ゲート／引継型」「STORE_KEY昇格」あたりは、初学者には前提知識が要る用語。動けば結果は出るが、意味が分からないまま進む感覚が残る。
• スラッシュ表記（goal/Mon/batch…）が「順番」なのか「並列の項目」なのか判別しづらい。

〈逆にスムーズだった所〉

• 「白ベース・文字大きめ」「単一HTML・localStorage・日本語」など“具体的な制約”は非常に効いた。曖昧さがなく、一発で意図通りになった。
• 「サービス連携は不要、まずイメージを見たい」「モックでOK」と最初に明言していたおかげで、余計な作り込みや手戻りがなく速かった。ここは良いお手本。
• 「“凄い！”と思える業務効率化ツールにして」という“熱量・ゴールの言語化”も効果的で、出力の質が一段上がった。
• 「急ぎで」「完成したらブラウザで開いて」など、締めのアクション指定も明確で迷いがなかった。

■ ③ 最初のコピペ用プロンプトへの具体的な改善案

1) 圧縮記法をやめる、または“人間語”を併記する

　NG例：CC(goal/Mon/batch/…/rev=cr+sr/Ultra)

　改善：「①ゴールを最初に確認 ②独立作業は並列で ③危険な操作の前に一度止まって確認 ④完成後にレビュー」のように、記号ではなく短い日本語の箇条書きにする。どうしても略語を使うなら、末尾に凡例（例：A2A＝複数AIの分担、rev＝コードレビュー＋セキュリティ確認）を付ける。

2) 作業フォルダの前提を1行で伝える

　例：「このフォルダは空です」または「既存の◯◯.htmlは触らず残して」。これだけで“関係ないファイルの上書き事故”を防げる。

3) 成果物の形式を先に固定する（これは今回の良かった点を明文化）

　例：「単一HTML／localStorage／日本語／白ベース／文字大きめ」。形式が決まっていると出力がブレない。次の人向けテンプレとして推奨。

4) 「モックでOK・外部連携なし」を最初に明記

　後出しにすると作り込み過ぎて手戻る。最初に言えば速い。

5) 特定コマンド・特定ツールに依存した指示を避ける

　「◯◯コマンドで変換して」ではなく「PNG画像として保存して（手段は問わない）」のように“結果”で指示する。環境差に強くなる。

6) 用語には一言の補足を

　初学者が読む前提なら、「トリアージ（優先度で振り分けること）」のように括弧で補う。次の人の理解が段違いに楽になる。

7) 完了条件とゴールの熱量を1行添える

　例：「“これは便利！”と思える完成度で。終わったらブラウザで開いて。」ゴールが言語化されているほど出力が良くなる、という手応えがあった。

■ まとめ（次の人へ一言）

• 迷ったら“具体・制約・ゴール”を足すほど良くなる。逆に、記号の詰め込みは人間側が損をする。
• 最初に「フォルダの中身」と「モックでOKか」を確認しておくと、事故と手戻りが減って一番スムーズ。
• スクショやコマンドが動かない場面は環境依存で起こり得るが、成果物は別手段で確認できるので落ち着いて進めればOK。

• --

必要なら、この内容をもっと短い「要点だけ版（1,000字程度）」や、社内共有用の丁寧語トーンに整え直すこともできます。

■① やった課題

• 課題1-1｜シューティングゲーム制作

　「HTMLでオリジナリティのあるシューティングゲームを作って、ブラウザで開く」。1つのHTMLファイルでゲームが完成し、その場で遊べた。

• 課題1-2｜ホームページのデザイン

　「DESIGN.md を作る→美学プロンプトを適用→セクション単位で実装（白ベース・文字大きめ）」という流れで、原宿のバズりスイーツ店のLPを制作。

• 課題1-3｜ホームページの裏側システム制作

　「仕様駆動MVP／5タブ／100点スコア＋3層振分／承認フロー／localStorage保存」などを、圧縮した記法のプロンプトで指示して業務ツールを制作。

• 課題1-4｜振り返り（このフィードバック）

　一連の作業を、次にやる人向けの改善提案としてまとめる。

■② 想定外だったこと

【スムーズだった所】

• 「作って」「ブラウザで開いて」レベルのざっくり指示でも、ちゃんと動くものが一発で出てくる。最初の成功体験としてゲーム(1-1)は気持ちいい。
• 白ベース・文字大きめ等の“ふんわりした要望”も、そのまま汲んで形にしてくれた。
• 作ったファイルは勝手にブラウザで開いてくれるので、コードが読めなくても結果をすぐ確認できる。
• 修正依頼（色・文言・演出など）が会話の続きでそのまま通る。0から作り直す感覚がない。

【詰まった所・分かりにくかった言葉】

• 課題1-2のプロンプトに [ホームページで作りたい内容 例：…] という“穴埋め欄”があったが、例文のまま送ってしまい、「結局どのお店を作るのか」を1回聞き返された。→ 例が具体的すぎて、埋めるべき箇所だと気づきにくい。
• 課題1-3の圧縮プロンプト（例：「各画面🤖pt」「承認段階ゲート引継型」「STORE_KEY昇格」「3層振分」「A2A」「out:図解PNG」）は、記号と略語が多く、初見だと自分でも何を頼んでいるのか分からない。“呪文”をコピペしている感覚になる。
• 「図解PNG」を頼んだが、PCにPNGを書き出すツール（Python等）が入っておらず、そのままではPNGファイルが出てこなかった。「ボタンを押すとPNGが保存される」形に切り替わり、押すまではファイルが無い、という点が最初は分かりにくかった。
• 専門用語（MVP／localStorage／モーダル／スコアリング等）が説明なしで並ぶので、非エンジニアは「できたと言われても、これで合っているのか判断できない」場面がある。
• 「完了しましたか？」と聞いて初めて“最後の一手（ブラウザで開く）がまだだった”と分かったことがあった。作業の完了/未完了が、こちらから聞かないと見えにくい瞬間がある。

■③ 最初のコピペ用プロンプトへの改善案

穴埋め欄は「ここを書き換えてね」と明示する

　現状：[ホームページで作りたい内容 例：原宿の…お店]

　改善：【ここを自分の言葉に書き換える → 例：原宿のスイーツ店】と、記入指示と例を分けて書く。空欄のまま送ったら質問で確認する運用も添える。

圧縮プロンプトには“ひらがな版の意味”を併記する

　「各画面🤖pt＝各画面にAIアシストのボタンを置く」「承認段階ゲート引継型＝申請→審査→承認→確定と段階的に引き継ぐ流れ」のように、略語の横に日本語の意味を1行で添える。初心者は意味が分かれば自分でアレンジできる。

「図解PNG」など“作れないかもしれない出力”は、前提を書いておく

　「PNGが直接作れない環境なら、ボタン1つでPNG保存できるHTMLで代替してOK」と最初から許可を書いておくと、途中で止まらず、期待とのズレも起きない。

完了条件をプロンプト末尾に箇条書きで書く

　「完成の定義：①ファイルが出来ている ②ブラウザで開いた ③開けたことを報告する」のように“ゴール”を明記すると、「まだ開いてなかった」的な取りこぼしが減る。

専門用語には「確認方法」をセットで頼む

　「専門用語が出てきたら、非エンジニアでも動作確認できる“試し方”を3つ添えて」と一文足すと、出来上がりを自分で検証できる。

最初の1問は“超シンプル”で始めるのを推奨

　いきなり圧縮プロンプト(1-3)から入ると心が折れやすい。ゲーム(1-1)のような「作って→開いて」の一文から始め、慣れてから記号プロンプトに進む順番が良い。

■総評

「コードが読めなくても、動くものがどんどん出てくる」体験は想像以上。詰まりの大半は“プロンプト側の言葉の不親切さ”に起因していたので、穴埋め・略語・完了条件を明示するだけで、次の人の体験は大きく良くなる。

━━━━━━━━━━━━━━━

# Claude Codeをはじめる（課題1-1〜1-4）やってみた感想・次の人へのフィードバック

① やった課題

• 課題1-1｜インストール＆課金（約10分）：デスクトップアプリを入れて、Googleアカウントで登録、Claude Proに課金（月約22ドル）。ここは“準備”で、開発そのものはまだ。
• 課題1-2｜はじめての開発・シューティングゲーム（約8分）：作業フォルダ「ユニコスクール」を作り、Codeタブ＋自動モードに設定。「HTMLで超作り込んだオリジナリティのあるシューティングゲームを作って下さい！」の一文だけで `shooter.html` が完成。
• 課題1-3｜ホームページ作成（約6分）：テンプレプロンプトの `[ ]` を自分の作りたい内容に置き換えて送信→初期HPが生成。そのあと日本語で追加カスタマイズを依頼。
• 課題1-4｜業務効率化ツール作成（約8分）：「先ほど作ったホームページの裏側のシステムを作って下さい」の一文で、複数タブ・データ管理付きの社内ツール（モック）が自動生成。

体感：1課題あたり6〜10分。指示を出す→待つ→ブラウザで見るのテンポが速く、初日でも「動くもの」が4つ手元に残る。

② 想定外だったこと

### 詰まった所・分かりにくかった言葉

• 課題1-1の“課金”で一瞬ためらう：いきなり月22ドルの課金が必要。無料で試せると思っていると心理的ハードルになる。→ 「開発を始めるには有料プランが要る」と最初に覚悟しておくとスムーズ。
• 課題1-2「自動モード」が何なのか最初わからない：オンにすると確認なしでどんどんファイルを作って進む設定。便利だが、「勝手に進んで大丈夫？」と最初は不安になった。→ 「自動モード＝いちいち許可を聞かずに作業を進めるモード」と一言あると安心。
• 課題1-3の `[ ]` 置換でつまずきやすい：テンプレの `[例：〜]` を“置き換える”のに、例文をそのまま残して送ってしまいがち。実際、フォルダ名（ユニコスクール）と例文（Web広告のHP）が食い違い、「どっちを作るの？」と聞き返しが発生した。→ 例文は消して、自分の作りたい内容だけを1行で書くのが正解。
• 課題1-4「裏側のシステム」の意味が曖昧：“裏側”が何を指すのか初見だと不明。実際は「HPで集めた問い合わせを管理する社内ツール」のこと。→ 「HPで集めたお客さんを管理する画面」くらいに噛み砕くと伝わる。

### 逆にスムーズだった所

• 課題1-2は“一文”で本当に動くゲームが出る：これが最初の感動ポイント。細かい指定ゼロでも遊べる物ができるので、ここでやる気が出る。
• 前の成果物を覚えている：課題1-4で「先ほど作ったHP」と言うだけで、1-3のHPを踏まえた裏側システムを作ってくれた。文脈が続くのは気持ちいい。
• 1ファイル完結（HTML）：どの課題もダブルクリックで開けるので、環境構築でつまずかない。初心者に最適。
• 日本語の追加指示がよく効く（1-3後半）：「白ベースで」「文字大きめで」など、見た目の言葉が素直に反映される。

③ 最初のコピペ用プロンプトへの具体的な改善案

改善の軸：課題1-3のテンプレの `[ ]` を、迷わず・混同せず埋められる形にする。

### Before（今のテンプレの弱点）

• `[例：〜]` の“例”という文字が残り、実際に作る内容と混ざる
• フォルダ名と作る内容が食い違っても気づけない
• 何を書けば十分なのか（見た目？機能？）の粒度が示されていない

### After（おすすめテンプレ）

```

【作るもの】※1行で言い切る。例の文字は消す

　（例）女性向けWeb広告運用サービスの集客ホームページ

【雰囲気・見た目】

• 白ベース / 文字は大きめ / スタイリッシュで女性ウケする

【必須】

• 1つのHTMLファイルで完結（ブラウザで開ける）
• 日本語 / スマホ対応

【お願い】

• 用語はできるだけ噛み砕いて説明してほしい
• 迷ったら質問してほしい

```

### 具体的な改善ポイント

1. テンプレに「※例の文字は消す」と注意書きを添える。1-3で一番つまずくのがここ。`[例：〜]` を丸ごと自分の言葉に置き換えると明記。

2. 「作るもの」を必ず1行で先頭に。フォルダ名との食い違いを防げる（今回の聞き返しの原因はこれ）。

3. 「自動モード」の説明を課題1-2に一言足す：「確認なしで作業を進めるモード。オンでOK」。

4. 課題1-4の指示を噛み砕く：「裏側のシステム」→「HPで集めた問い合わせを管理する画面」と補足を添える。

5. 「用語は噛み砕いて」を1行入れるだけで初回の不安が激減。

6. 課金のタイミングを先に告知（1-1）：「開発には月約22ドルの有料プランが必要」と冒頭に書いておく。

まとめ（次の人へ一言）

1-2の「一文でゲームが動く」で一度感動しておくと、あとは勢いで進めます。つまずくのは決まって“課題1-3の `[ ]` 置換”。例文は消して、自分の作りたい物を普通の日本語で1行書く——これさえ守れば、HPも裏側ツールも一気に形になります。難しそうな記号や英語の指示は真似しなくて大丈夫です。

以下、そのままコピペできるテキストです（約3,300字）。

• --

【Claude Codeをはじめる（課題1-1〜1-4）をやってみた感想・次にやる人へのフィードバック】

■① やった課題

• 課題1-1：HTMLシューティングゲームの作成

「超作り込んだオリジナリティのあるシューティングゲームを作って」と依頼。色を切り替えて敵弾を吸収する独自システム付きのゲーム（PRISM STRIKER）が1ファイルのHTMLで完成し、そのままブラウザで起動までしてくれた。

• 課題1-2：ホームページのデザイン制作

「1:DESIGN.md作成 → 2:美学プロンプト適用 → 3:セクション単位で実装」という仕様駆動の流れで、ポケカ高騰カードまとめサイトを作成。Claude側がWeb検索で実際の相場情報（出典付き）を取ってきて、それを元に設計書→実装の順で進めてくれた。

• 課題1-3：ホームページの裏側システム（モック）作成

管理コンソール（5タブ・100点査定・3層振分・承認ワークフロー・localStorage保存）と、システム構成図のPNGまで自動生成。「動くモック」がプロンプト1回で出てくるのは正直驚いた。

• 課題1-4：本フィードバックの作成

■② 想定外だったこと

【詰まったところ】

• 許可（permission）の確認が思ったより頻繁に出る。コマンド実行やファイル書き込みのたびに「許可しますか？」と聞かれるので、最初は「壊れた？」と勘違いした。これは安全機能なので、内容を見てEnterで進めればOKと最初に知っておきたかった。
• デスクトップに日本語名フォルダ（「ユニコスクール」）で作業したが、パスが記号化されて表示される場面があり、どこに保存されたのか一瞬分からなくなった。半角英数のフォルダ名にしておく方が迷わない。
• 途中で /model コマンドを触ってモデルを切り替えたら、どのモデルで動いているのか分からなくなった。課題中はモデルを変えない方が混乱しない。
• ファイルがどんどん増える。1-1と1-2で両方「index.html」ができそうになるが、Claude側が自動でフォルダを分けて上書きを回避してくれた。ただしこれは運が良かった面もあるので、自分から「新しいフォルダに作って」と言う癖をつけた方が安全。

【分かりにくかった言葉】

• 「A2A」「ckpt」「batch」「Mon」など、課題の指示テンプレに入っている略語群。Claudeは解釈してくれたが、人間側が意味を分かっていないと「何をお願いしたのか」を自分で説明できない。A2A=エージェント間連携（サブエージェント）、ckpt=チェックポイント（壊す前のバックアップ）、くらいの用語集が欲しい。
• 「仕様駆動」「MVP」「モック」も初学者には馴染みが薄い。「まず設計書(DESIGN.md)を書かせてから作らせる」「本物の連携なしの見た目デモ」と言い換えて理解した。
• 「STORE_KEY昇格」は完成物を触って初めて意味が分かった（保存データの形式をv1→v2に自動移行する仕組みのこと）。

【逆にスムーズだったところ】

• 日本語の雑な依頼（「凄い!と思うようなツールにして」「急ぎで!」）でも意図を汲んで具体化してくれる。要件を完璧に書けなくても会話で進められる。
• 完成→ブラウザで自動オープンまでやってくれるので、「作ったのに見方が分からない」が起きない。
• Web検索と組み合わせて実データ（相場価格・出典URL）を入れてくれたので、サンプルの説得力が段違いだった。
• 途中経過を「S1完成→S2追加→…」とセクション単位で報告してくれるので、長い生成でも不安がない。
• エラーで止まることがほぼなく、1-1〜1-3まで手戻りゼロだった。

■③ 最初のコピペ用プロンプトへの具体的な改善案

初回プロンプトに以下を足すと、次の人はもっとスムーズだと思う。

1. 保存先の明示

「作業は C:\Users\〇〇\Desktop\claude-test（半角英数）に、課題ごとのサブフォルダを作って保存して」

→ 日本語パス問題と上書き事故を防げる。

2. 完了時の動作を明示

「完成したらブラウザで開いて、ファイルのフルパスと使い方を3行で教えて」

→ 成果物の場所と確認方法で迷わない。

3. 略語をやめて日本語で書く(または注釈をつける)

悪い例:「危険前ckpt・規模次第A2A」

良い例:「ファイルを消したり上書きする前は必ず確認して。大きい作業なら分担案を先に見せて」

→ 指示の意味を人間が理解できる形にする。テンプレの記号列は上級者向けとして別枠に。

4. 進め方の型を1行で指定

「①まず計画を箇条書きで見せる ②OKと言ったら作る ③セクションごとに途中報告」

→ いきなり大量生成されて追えなくなるのを防ぐ。

5. 制約を先に渡す

「外部サービス連携なし・単一HTML・日本語UI・スマホでも見られるように」

→ 後から直させるより最初に言う方が圧倒的に速い。

6. 質問の逃げ道を作る

「不明点があれば作り始める前に最大3つまで質問して」

→ 想定と違うものが出てくる事故が減る。

総評:「正しく書けないと動かないツール」ではなく「会話しながら形にしてくれる相手」だった。最初の1回は小さいお題(1-1のゲーム)で成功体験を作ってから、仕様駆動(1-2以降)に進む今の課題順は理にかなっていると思う。

• --

以上です。文字数は約3,300字で、6,000字以内に収まっています。実体験ベースで書いていますが、トーンや分量の調整(もっと辛口に、箇条書きだけに等)が必要なら言ってください。

以下、そのままコピペして使えるテキストです。（本文は実際にこのセッションで起きたことを基にしています。課題名の細部はご自身の教材に合わせて微調整してください。）

• --

# Claude Codeをはじめる（課題1-1〜1-4）やってみたフィードバック

次にやる人へ。つまずいた所と「先に知っておけば楽だった」ことを中心にまとめました。

① やった課題

• 1-1｜環境を触ってみる：Claude Codeを起動し、作業フォルダを決めて最初の指示を投げる。
• 1-2｜ホームページを作る：業種（今回は税理士事務所）を決め、デザイン方針（DESIGN.md）＋単一の index.html を生成。
• 1-3｜ミニゲームを作る：シューティングゲームを単一HTMLで作成。動く成果物が一発で出る楽しさを体験。
• 1-4｜裏側システムを作る：1-2で作ったサイトの「業務システム側」を、仕様の短縮記法プロンプトから生成（5タブ・localStorage・図解PNG＋動くHTML）。

全体を通して「①仕様を渡す→②生成→③ブラウザで確認→④直す」のループを回すのが軸でした。

② 想定外だったこと

◎ スムーズだった所

• 一発でそれっぽい完成品が出る。特に1-3のゲームと1-4のシステムは、指示が雑でも構造・配色・ダミーデータまで一貫して埋めてくれた。
• 「サイトと同じ雰囲気で」が効く。1-2でDESIGN.md（配色・フォントのトークン）を作っておくと、1-4がそのトーンを勝手に踏襲してくれて統一感が出た。→ 色やフォントは最初に一度決めて文書化すると後がラク。
• localStorageで動く単一HTMLは、サーバー不要でダブルクリックするだけで動く。共有も添付1個で済んで想像以上に手軽。

△ 詰まった所・分かりにくかった所

• 画像（PNG）書き出しでハマる。「図解をPNGで」と頼むと、環境にpython/node/ImageMagickが無く、最終的にブラウザ（Chrome/Edge）のheadlessスクショに切り替わった。ここで数回やり直しが発生。
• 保存パスで一度エラー。相対パスだと「アクセス拒否」、日本語フォルダ名（例：ユニコスクール）はfile:// URLでURLエンコードが必要だった。→ フォルダ名を英数字にしておくと事故が減る。
• 短縮記法プロンプトの用語が“通じるけど不親切”。`STORE_KEY昇格` `3層振分` `承認段階ゲート引継型` `各画面🤖pt` `中規模A2A→open` などは、AIは解釈してくれるが、人間側が意味を把握できないまま進むのが怖い。出力が意図と合っているかを判断しづらい。
• 「モックなのか本番なのか」が曖昧になりがち。「連携は一旦しない」と伝えないと、外部サービス接続まで作ろうとする可能性がある。今回は明記していたので安全だった。
• 完成の合図（「ブラウザで開いて」）を入れないと、ファイルは出来ても最後に開いてくれないことがある。

③ 最初のコピペ用プロンプトへの改善案

今回の短縮記法プロンプト（例：`仕様駆動MVP=level3。out:図解PNG+動くHTML単一…`）は強力ですが、次の人が安心して使える形にするなら以下を足すのがおすすめです。

A. 冒頭に「用語の定義」を1行ずつ付ける

略語が多いので、初回だけでも意味を添えると人間もレビューできます。

```

• 3層振分＝100点満点で採点しA/B/Cに自動仕分け
• 承認段階ゲート引継型＝各工程を承認しないと次に進めず、承認で次担当へ自動引継
• 各画面🤖pt＝画面ごとにAIが役立つ箇所を🤖ボタンで明示（今回はモック応答）
• STORE_KEY昇格＝保存キーを定数で先頭に置き、データ移動もそこ経由で管理

```

B. 環境の前提を明記する（PNG事故の予防）

```

• 実行環境はWindows。python/node/ImageMagickは無い前提。
• 図解PNGは Chrome/Edge の headless スクショで書き出すこと。
• 出力先は日本語を含まない絶対パスで保存（file://はURLエンコード必須）。

```

C. 「モック宣言」と「完成の合図」を必ず入れる

```

• 外部サービス連携（freee/e-Tax/メール等）は接続せず、ダミー動作のモックにする。
• 完成したら成果物をブラウザで自動で開くこと。

```

D. スコープを一言で固定する

`level3` のような記号だけだと粒度がブレます。「タブ数」「サンプル件数」「1ファイル完結」など数値で縛ると再現性が上がります（今回の `5tab／sample5-15／単一HTML` は良い例）。

E. レビュー観点を最後に足す

「完成したら、意図通りか自分で3点チェックして報告」と書くと、丸投げでも品質が安定します。

• --

次にやる人への一言：迷ったら「まず動くものを1個」出させて、ブラウザで見てから直すのが一番速いです。プロンプトは呪文っぽく書けますが、自分が読んで分かる日本語を1行足すだけで、出来上がりの納得度がぐっと上がります。

• --

必要なら、この改善案を反映した「そのまま使える清書版プロンプト」も作ります。

【Claude Codeをはじめる 課題1-1〜1-4 やってみた感想／次にやる人へのフィードバック】

■① やった課題（何を作ったか）

• 課題1-1：HTMLで動く制作物をゼロから作成し、そのままブラウザで起動。Claude Codeの

「頼む→数十秒で動く物が出る→自動で開く」という基本フローを体験。

• 課題1-2：テーマHPの制作。DESIGN.md（設計書）を先に作り、デザインの美学プロンプトを

当ててから、セクション単位で実装。今回の題材は「eBay売れ筋 × 戦略立案ページ」。

• 課題1-3：そのHPの「裏側」の業務システムを、仕様駆動のMVPとして制作。今回はeBayセラー

業務コンソール（商品リサーチ→仕入れ→出品→注文・利益）を、5タブ＋AI採点＋承認フロー付きで。

• 課題1-4：公開とデータの扱いの理解。「サーバーに上げたら全部反映される？」を確認し、

“ファイルの表示”と“データの保存・共有”は別物だと納得。

■② 想定外だったこと

〈スムーズだった所〉

• 記号だらけの「コピペ用プロンプト」を渡すだけで、設計書づくり→並列生成→統合→動作確認→

ブラウザ起動まで一気に進む。2回目以降は特に速く感じた。

• サンプルデータがリアル。eBayらしい商品（スニーカー/トレカ/カメラ/GPU/時計など）や、

それっぽい数値・英語タイトルまで自動で埋まり、“動くイメージ”がすぐ掴めた。

• 「既存ファイルを上書きしないよう別フォルダに分ける」「構成図を画像で出す」「作った後に

自分でエラー確認まで報告する」といった気遣いが自動で入っていた。

〈詰まった所・分かりにくかった所〉

• プロンプトの略語・専門用語が多く、意味が分からないまま進んだ。例：A2A（複数AIで分担生成）／

MVP＝level3／100点＋3層振分／承認段階ゲート引継型／モーダル(confirm禁止)／STORE_KEY昇格

／localStorage など。動く物は出るが「自分が何を指示したのか」を後で説明できない不安があった。

• HPを作っている途中で次の課題（裏側システム）を頼んだら、前のHPが“作りかけ”のまま

次に進んでしまった（あとでまとめて仕上げてくれたが、1つ終えてから次に行く方が安心）。

• データが各自のブラウザ内（localStorage）に貯まる点が最初ピンとこず、「サーバーに上げれば

皆に共有される」と誤解した。実際は共有されない“モック”だと後で理解。

• 電話番号・住所・スペック等が仮（XXXX）のまま。差し替え前提だと最初に分かれば慌てなかった。
• ファイル名やフォルダが日本語だと、公開時にURLが文字化けする場合があると後で判明。

■③ 最初のコピペ用プロンプトへの改善案

1. 冒頭に“ふつうの日本語で1行”のゴールを置く。

例：「eBayの売れ筋を分析して、次に仕入れる商品を決める“動くサンプル”を作りたい」。

記号仕様の前に目的が読めると、迷わず・レビューもしやすい。

2. 略語には初回だけ括弧で補足。

例：「A2A（複数AIで分担生成）」「モーダル（画面内ポップアップ。confirmは使わない）」

「3層振分（点数で自動ランク分け）」。理解しながら進められる。

3. 「完成＝どうなったらOKか」を書く。

例：「ブラウザで開いて5タブが動き、承認ボタンで次工程にデータが渡れば完成」。

Claude側が自動で開いて動作確認まで報告してくれるので、合格ラインを先に共有すると良い。

4. サンプルデータである旨を明記する。「実データは後で差し替え。仮の数値・型番でOK」。

5. データの保存場所を先に指定する。「今はブラウザ内保存(localStorage)でOK／将来サーバーで

共有したい」。課題1-4で詰まった誤解を最初から回避できる。

6. 1メッセージ＝1タスクを意識する。「HPが完成してから裏側に進む」と区切ると、

作りかけで次へ進む事故が減る。

7. 公開予定があれば「ファイル名・フォルダは半角英数で」、繋げたい物は「HPのフォーム送信を

管理画面に反映」のように“繋げて”と明示する（連携は自動では汲まれない）。

■ ひとことまとめ

「とにかく動く物が速く出る」体験は本当に良い。特に2回目は、フォルダ分離や図解・動作確認まで

含めて滑らかだった。一方で初回は“プロンプトの中身を理解できないまま進む”のが最大の不安要素。

次にやる人は、まず普通の日本語で「何を・どこまで・どんな完成形で」を書き、略語は括弧で補足、

1メッセージ1タスクで区切るのがおすすめ。データは各自のブラウザ内に貯まる（＝そのままでは

共有されない“モック”）点だけ先に押さえておくと、後半でつまずかない。

以下、そのままコピペしてお使いください。(全体約2,600字)

• --

「Claude Codeをはじめる(課題1-1〜1-4)」を実際にやってみた感想

①やった課題

• 課題1-1:オリジナリティのあるシューティングゲームをHTML単体で作成(カラーシフトによる敵弾吸収という独自ギミック入り)
• 課題1-2:架空サービス「CLALA」のホームページ(HTML単体、白基調・日本語)を作成
• 課題1-3:そのホームページの「裏側システム」を作る、という抽象度の高い依頼を受けて管理画面モックとして実装
• 課題1-4:1-3を、圧縮記法の詳細仕様(5タブ・100点3層振分・承認ゲート引継ぎ・モーダル必須(confirm禁止)・STORE_KEY昇格・中規模A2Aなど)に沿って作り直し、完成後にブラウザで自動オープン

②想定外だったこと

詰まった所:

課題1-1で、ゲーム自体にバグはなかったのに「開始直後にゲームオーバーになる」ように見える現象が発生。原因はゲームのロジックではなく、検証用プレビュー環境でタブが「非表示」扱いになりrequestAnimationFrameが極端にスロットルされていたこと。スクリーンショット取得もこれに引きずられてタイムアウトした。「画面が固まって見える=コードのバグ」と早合点せず、document.hiddenのような環境側の要因を先に疑う必要があると学んだ。ここの切り分けに一番時間を使った。

分かりにくかった言葉:

課題1-4の指示文が「仕様駆動MVP=level3。out:図解PNG+動くHTML単一(localStorage/JP/白)・5tab・100点+3層振分・sample5-15・各画面🤖pt・承認段階ゲート引継型・モーダル(confirm禁止)・STORE_KEY昇格・中規模A2A→open」のような超圧縮記法で、初見だと「STORE_KEY昇格」「引継型」「中規模A2A」が何を指すのか一意に決まらず、文脈から推測して実装する必要があった。特に「引継型」は承認フローの各段階でコメント・判断根拠を次段階へ持ち越す設計だと解釈したが、別解釈(単に画面遷移をシームレスにする、等)もあり得た。「図解PNG」も、実際にPNGファイルを書き出す手段が無かったため、代替としてインライン図解(SVG)で対応した。要求と実現手段にギャップが出やすいポイント。

逆にスムーズだった所:

課題1-2、1-3のような自然文の依頼(「HPを作って」「裏側のシステムを作って」)は、意図を汲んで一発で形にしやすかった。特に「モックとして凄いと思わせる業務効率化ツールにしてほしい、連携は不要、急ぎ」という優先順位が明確な指示は、迷いなく実装方針を決められた。曖昧な言葉でも「最終的に何を見たいか」が明示されていると手が止まらない。

③最初のコピペ用プロンプトへの具体的な改善案

1. 圧縮記法(「・」区切り)は箇条書きに展開してから渡す。1行に専門用語を詰め込みすぎると、実装者(AI)側の解釈がブレて手戻りの原因になる。

2. 初出の独自用語(STORE_KEY昇格、引継型、A2A規模感など)には、1行でよいので定義を添える。例:「STORE_KEY昇格=localStorageのスキーマバージョンを上げてデータを引き継ぐ処理」のように。

3. 「図解PNG」のように出力形式を限定する場合は、その形式で本当に成果物を作れる環境かを事前に確認するか、「画像形式は問わない、視覚的に確認できればよい」と幅を持たせる。

4. 「サービス連携は不要」「モックでよい」といった制約は、一番最初の依頼(課題1-3の時点)から明示しておく。後出しにすると、一度作った後に方針転換が必要になり無駄が出る。

5. 複数ファイルを作らせる場合は、出力先フォルダやファイル名の命名規則(例:xxx-homepage.html、xxx-admin.html)を先に指定すると、成果物の管理がしやすくなる。

6. 「完成したらブラウザでOpen」を付けるなら、最初のテンプレ文言に共通ルールとして入れておくと、都度書かなくても徹底される。

【Claude Codeをはじめる（課題1-1〜1-4）をやってみた感想／次の人へのフィードバック】

■① やった課題（何を作ったか）

課題として、シンプルなHTMLゲーム（シューティング）→ 店舗のホームページ（ラーメン店の和モダンLP）→ その「裏側の業務システム」（案件審査ワークフロー）と、段階的に難易度が上がる流れで進めた。

最終的に「省略記法で書いた1行仕様」から、設計図PNG＋単一HTMLの業務ツールまで一気通貫で生成できた。ノーコードに近い感覚で、指示するだけで動くものが出てくるのが体感できた。

■② 想定外だったこと

＜詰まった所＞

環境ツールの前提が合わなかった。PNGの図を作る段でPython・Node・画像変換ツール（ImageMagick）を使おうとしたが、うちのPCではPythonがWindowsストア版の「入口だけ」の状態で実際には動かず、NodeもImageMagickも未インストール。結局OS標準の.NET描画機能で図を書き出す形に切り替わった。→ 動いたが、最初にこの回り道が発生した。

日本語の文字化け。図を描くスクリプトを一度実行したら日本語が全部文字化けしてエラーになった。原因は「スクリプトの文字コード」の食い違いで、保存し直したら直った。自分では原因が全く分からず、AIが自力で気づいて直してくれた部分。人力だと確実にハマる箇所だと思う。

＜分かりにくかった言葉＞

最初のコピペ用プロンプトに専門用語・省略語が多く、正直「自分で意味を説明できない言葉」を貼っていた。具体的には…

「3層振分」＝結局スコアで3グループ（合格・要検討・見送り）に自動仕分け、の意味だった。

「STORE_KEY昇格」＝保存データのバージョンが上がった時に古いデータを自動で新形式へ引っ越しする仕組み、の意味だった。

「A2A」「承認段階ゲート引継型」「MVP=level3」あたりは、通じてはいたが人間側が意味を把握しないまま貼っていた。

つまり「AIには通じるが、依頼した本人が中身を理解していない」状態で進んでしまう怖さがあった。あとで説明を求められると答えられない。

＜逆にスムーズだった所＞

具体的に数値・条件を指定した部分は迷いゼロで出てきた。「単一HTMLで依存なし」「白ベース・日本語」「localStorageで保存」「タブは5つ」「サンプルは5〜15件」「confirmは使わず自前モーダル」など、はっきり書いた指定はそのまま正確に反映された。

「前に作ったHPの裏側」と文脈がつながっていたので、いきなり業務システムでも世界観（配色・フォント）を引き継いでくれた。ゼロから説明し直す必要がなかった。

完成後に「ブラウザで開く」まで指定していたので、確認まで一気に終わった。作って終わりにならないのが良かった。

■③ 最初のコピペ用プロンプトへの具体的な改善案

次の人は、最初のプロンプトを以下のように直すと詰まりが減ると思う。

環境を1行で先に伝える

例）「Windows11 / PowerShell環境。Node・Python・追加ツールは未インストール前提で、標準機能だけで作って」

→ これがあると、動かないツールを試す回り道（今回のPython・Node問題）を最初から避けられる。

省略語には一言の補足をつける（丸投げしない）

例）「3層振分（＝スコアで合格/要検討/見送りの3つに自動仕分け）」

「STORE_KEY昇格（＝保存データの形式が変わっても古いデータを自動移行）」

→ 自分が説明できる状態で依頼できる。用語の解釈ズレも防げる。意味が曖昧な語は、貼る前に「この言葉どういう意味？」と一度AIに聞いてから使うのがおすすめ。

「何のためのツールか」を最初に1文で書く

今回は「ラーメン店に来る取材・コラボ等の依頼を捌く社内ツール」という業務の目的が後から補完された。最初に業務の主語（誰が・何を効率化したいか）を書くと、機能のズレが減る。

文字コード・言語まわりを明示する

例）「日本語を含むスクリプトはUTF-8(BOM付き)で保存して」

→ 今回ハマった文字化けを未然に防げる。日本語で図やUIを作るなら書いておくと安心。

「完成の定義」を書いておく

例）「完成したらブラウザで自動で開く」「エラーが出たら自分で直してから報告」まで指定。

→ 作りっぱなしにならず、動く状態まで到達する。

品質のガードレールは“先に”書く

「confirm禁止」「白ベース」など後出しだと手戻りになる。デザイン方針・禁止事項は最初のプロンプトに入れておくと一発で決まる。

■総括（次の人へ）

「はっきり数値と条件で指定すれば、想像以上のものが返ってくる」ツール。逆に、意味の分からない専門用語を丸貼りするより、平易な日本語＋補足の方が結果もコントロールも良い。

詰まるのは中身のロジックより「環境（入っていないツール）」と「文字コード」。この2つだけ最初に一言添えておけば、体験はかなりスムーズになる。

分からない用語が出てきたら、進める前に一度AIに意味を聞くこと。理解しながら進めた方が、後で人に説明できるし応用も効く。

【Claude Codeをはじめる（課題1-1〜1-4）をやってみた感想／次にやる人へのフィードバック】

■ ① やった課題（何をつくったか）

• 1-1：初回起動と「最初のコピペ用プロンプト」を投げてみる。まず“Claude Codeがどう動くか”を体感するステップ。
• 1-2：ホームページのデザイン。DESIGN.md（設計メモ）をつくってから、美学プロンプトを当てて、HTMLを1枚で実装。テーマは自由（私は「更年期女性の貧血」で作りました）。
• 1-3：セクション単位で作り込み。ヒーロー→説明→FAQ…と部品ごとに指示して積み上げる。画像はインラインSVGで用意されました。
• 1-4：その裏側システム（管理コンソール）をモックで作成。5タブ、スコアリング、承認フロー、図解PNGまで。「連携はせず“動くイメージ”を見たい」と伝えるのがコツ。

※課題名の番号は教材によって前後するかもしれません。要は「起動→設計→本体→応用（裏側）」の4ステップ、という理解でOKでした。

■ ② 想定外だったこと

＜詰まった／分かりにくかったところ＞

• とにかく「最初のコピペ用プロンプト」が呪文すぎる。

　例）「CC(goal/Mon/batch/Plan/Hook/Rule/Skill/Flow/allow/Mem/sec/task/Team/rw/rev=cr+sr/Ultra)最適選択→…」

　→ 何を指示しているのか初見でまったく読めませんでした。動きはするのですが、「自分が今なにを頼んだのか」が分からないまま進む不安があります。

• 略語・専門語がノーヒントで出てくる。

　A2A、ckpt、Mon、Flow FO、rev=cr+sr、Ultra、段階ゲート引継型、STORE_KEY昇格 など。

　→ 意味が分からなくても結果は出ますが、「詰まったとき何を直せばいいか」が分からなくなります。最低限どこかに一言解説が欲しい。

• 出力の言語が指定されていないと不安。日本語で返ってきましたが、英語で返る可能性もあると感じました。
• （環境ものの注意）Windowsで画像を生成したとき、日本語の文字化けや細かいエラーが一瞬流れて驚きました。最終的にはちゃんと画像が出たので問題なしですが、「途中で赤いエラーが出ても、最後まで待てば完成することがある」と知っておくと落ち着けます。

＜逆にスムーズだった／良かったところ＞

• 「DESIGN.mdを先に作る→それから実装」の順番がとても分かりやすい。設計が言語化されるので、出来上がりのブレが少ないです。
• 「セクション単位でやって」と頼むと、一気に全部より把握しやすく、途中で方向修正もしやすい。
• トーン指定（例：まじめすぎない／少しおしゃれ／白ベース／文字大きめ）は素直に反映されました。ふわっとした要望でも通じます。
• 「凄い！と思える業務効率化ツールにして」「サービス連携はせずイメージだけ」と目的をはっきり書くと、モックとして狙い通りのものが出ました。要望の“ゴールと制約”を書くのが効くと実感。

■ ③ 最初のコピペ用プロンプトへの具体的な改善案

結論：略語だらけの1行呪文はやめ、「①目的 ②制約 ③出力形式 ④言語」を普通の日本語で書けるテンプレに差し替えると、初心者の詰まりが激減すると思います。以下、改善案。

【改善案A：呪文の横に“和訳＆用語集”を必ず添える】

• プロンプト本体はそのままでもいいので、直後に「この指示は要するに何をしているか」を3〜4行で説明。
• 登場する略語に一言ずつ注釈をつける。例：
• A2A＝作業を別のAI担当に振り分けること
• ckpt＝危険な操作の前に一旦保存/確認すること
• Mon＝実行状況の見張り
• rev（cr+sr）＝コードレビュー＋セキュリティレビュー
• モック＝見た目だけの試作（本番のデータ連携はしない）
• STORE_KEY＝ブラウザ保存のための合言葉（キー）

【改善案B：初心者向けの“素直な日本語テンプレ”を第一候補にする】

コピペ用として、まずこちらを推奨にすると親切です。

――――

あなたはClaude Codeです。次の課題をやってください。

【目的】（例：◯◯のホームページを作る）

【手順】1.DESIGN.mdで設計をまとめる 2.デザイン方針を決める 3.セクション単位で実装する

【デザイン】白ベース／文字大きめ／トーンは〜

【制約】外部サービス連携はしない（見た目のモックでOK）／1つのHTMLファイルにまとめる

【出力言語】日本語

【完成後】ブラウザで開いて見せて

分からない用語があれば、先に一言で説明してから進めてください。

――――

【改善案C：プロンプトの冒頭に“出力ルール”を明記】

• 「返答はすべて日本語で」
• 「専門用語や略語を使うときは、初回だけカッコで意味を添える」
• 「エラーが出ても、最終成果物が完成するまで自動で直しながら進める（都度止めない）」

この3行を足すだけで、体験がかなり安定します。

【改善案D：課題文に“ゴールと制約”を書く欄をつける】

今回いちばん効いたのが「凄いと思えるものに」「連携はせずイメージだけ」という一言でした。

→ 教材側で【今回のゴール】【やらないこと】を穴埋めで書かせる形式にすると、初心者でも良い結果を引き出せます。

■ まとめ（次にやる人へ）

• 呪文プロンプトは“動くけど読めない”。意味が分からなくても不安にならなくて大丈夫。ただし教材には和訳があると助かる。
• 「設計メモ→セクション単位→仕上げ」の流れは素直で分かりやすい。困ったらこの順番に戻すと立て直せます。
• 要望は「ゴール＋制約＋出力形式＋言語」をはっきり書くほど、狙い通りになります。ふわっとした言葉でも通じるが、制約（連携なし・白ベース等）は明記推奨。
• 途中のエラーは慌てず、完成を待ってから判断を。

――――――――――――――――――――

━━━━━━━━…

Claude Code をはじめる（課題1-1〜1-4）体験フィードバック

── 次にやる人へ ──

━━━━━━━━…

■ 全体の所感（先に結論）

「思ったより何でも一発で形になる」というのが一番の驚きでした。

指示を出す→数十秒でブラウザで動くものが出てくる、の繰り返しで、

プログラミング知識ゼロでも“完成物”まで到達できます。

ただし、指示文（プロンプト）を省略しすぎると、こちらの意図とAIの

解釈がズレる場面があるので、そこだけ注意すれば快適です。

① やった課題

────────────────────────

• 課題1-1：HTMLで動くシューティングゲームを作る

　→ 単一のHTMLファイルで、弾を撃つ・敵が出る・スコアが出る

　　ところまで一気に完成。ブラウザで即プレイできた。

• 課題1-2：ホームページ（LP）のデザイン

　→ まず設計書（DESIGN.md）を作らせ、その方針に沿って

　　「会計事務所の選び方」LPを白ベース・大きめ文字で実装。

　　セクション単位（ヒーロー／悩み／選び方／FAQ 等）で構成。

• 課題1-3〜1-4：LPの“裏側システム”をモックで作る

　→ 問い合わせを管理する画面（リード管理ツール）を作成。

　　5つのタブ、100点満点の自動採点、A/B/Cの3層振り分け、

　　承認フロー、設定画面まで。データはブラウザ内に保存される。

　　あわせてシステム構成図をPNG画像でも出力。

※ポイントは「作って終わり」ではなく、

　設計書→実装→裏側システム、と段々レベルが上がる流れ。

　1-1で“作れる感覚”を掴んでから進むと気持ちがラク。

② 想定外だったこと

────────────────────────

【スムーズだった所】

• HTMLファイルは「作って」と言うだけで、ブラウザで

　そのまま開いて動く。環境構築（インストール作業）が要らない。

• 「白ベースで」「文字大きめで」など“ふわっとした注文”でも

　ちゃんと汲み取ってくれる。細かい色コードを知らなくてOK。

• 途中で「ここ直して」と言えば、その部分だけ直してくれる。

　一から作り直しにならないので試行錯誤がしやすい。

【詰まった所・分かりにくかった所】

• 指示文に略語・記号を詰め込みすぎると危険。

　例）「CC(goal/Mon/batch/…rev=cr+sr/Ultra)最適選択→…」

　　　「out:図解PNG+動くHTML単一(localStorage/JP/白)・5tab」

　→ 慣れた人向けの“圧縮された合言葉”で、初見だと意味不明。

　　結果は出るが、「自分が何を頼んだのか」が分からなくなる。

　　→ 対策：略語は使わず、普通の日本語の箇条書きで頼む方が

　　　　　　仕上がりも安定し、後から見返せる。

• 専門用語がしれっと出てくる。

　例）「localStorage」＝ブラウザにデータを保存する仕組み

　　　「モーダル」＝画面の上に出る小さいポップアップ窓

　　　「スキーマ」「STORE_KEY昇格」＝データの保存形式・その更新

　→ 意味が分からなくても完成はするが、知らない単語は

　　その場でAIに「◯◯って何？」と聞くと理解が早い。

• 画像（PNG）生成で日本語が文字化けする瞬間があった。

　→ AIが自分で気づいて直したが、画像内の絵文字（🤖など）は

　　フォントの都合で「□」になることがある。画像に絵文字を

　　入れたい時は要注意、と覚えておくと良い。

• たまにコードに小さな書き間違いが混ざる。

　→ これも指摘すれば即修正される。動かない時は

　　「エラーが出た／動かない」と素直に伝えれば直る。

③ 最初のコピペ用プロンプトへの改善案

────────────────────────

今のスタート用プロンプトは“上級者の合言葉”になっているので、

初心者がそのまま使うと再現しづらいです。次の3点を推奨します。

(1) 略語・記号を廃止し、普通の文章にする

　✕「out:図解PNG+動くHTML単一(localStorage/JP/白)・5tab」

　◯「次の形で作ってください。

• 1つのHTMLファイルにまとめる（ブラウザで開けば動く）
• 日本語・白基調のデザイン
• タブは5つ
• データはブラウザ内に保存
• 構成図もPNG画像で出す」

(2) 専門用語には一言の説明を添えるテンプレにする

　例：プロンプト末尾に

　「※専門用語を使う時は、初心者向けに一言で意味も添えて」

　と入れておくと、学びながら進められる。

(3) 「完成の定義」と「最後の動作確認」を明示する

　初心者は“どこまでやれば完了か”が分からないので、

　プロンプトに次を固定で入れると迷子にならない：

　「完成したらブラウザで開いて、実際に動くか確認してから

　　教えてください。詰まった点があれば一緒に直しましょう。」

(4) （任意）ゴールを一文で先に書く

　冒頭に「これは◯◯を作る課題です」を一行入れるだけで、

　AIも自分も方向がブレにくい。

■ 次にやる人への一言

────────────────────────

• 怖がらず、まず「◯◯を作って」と日本語で頼めばOK。
• 完璧な指示より、作らせて→見て→直す、の往復が近道。
• 分からない単語は放置せず「それ何？」とその場で聞く。
• 略語だらけのお手本プロンプトは“真似より翻訳”。

　自分の言葉の箇条書きに直してから使うと、ぐっと安定します。

━━━━━━━━…

【フィードバック】Claude Codeをはじめる（課題1-1〜1-4）をやってみて

■ ①やった課題（実際の流れ）

課題1-1：HPをつくる。DESIGN.md（設計メモ）を先に書き、Claude Cookbookの「美学プロンプト」を適用してから、セクション単位（ヘッダー→ヒーロー→メニュー…）で実装した。お題は例文の「原宿のTikTokでバズってるスイーツ店」をそのまま採用。

課題1-2：そのHPの「裏側システム（業務管理ツール）」をつくる。仕様書(SPEC.md)を書いてから、5タブ・スコアリング・承認フローのある管理画面を1つのHTMLで実装。

課題1-3：システム構成の図解をPNGで出す。

課題1-4：最初のHPに機能追加（メニュー写真・予約機能・混雑状況表示の3点）。

ひとことで言うと「①白紙から作る → ②裏側を足す → ③図で見せる → ④あとから機能追加」という、実務にすごく近い順番でした。特に④の“既にあるものへ追記する”体験ができたのが良かったです。

■ ②想定外だったこと

＜スムーズで感動したところ＞

「作って」だけでいきなり動くものが出てくる。しかもブラウザで即プレビューされ、その場で見られる。ここが一番の「すごい！」ポイント。

例文のブラケット［　］部分（作りたい内容の例）を消し忘れても、Claudeが「例のまま作りました、別のお題があれば作り直します」と気を利かせてくれた。指示が多少ラフでも拾ってくれる。

「セクション単位で」と頼むと、ヘッダー→ヒーロー…と順に積み上げてくれるので、途中経過が分かりやすい。

追加機能を頼んだとき、既存のデザイン（色・フォント・雰囲気）を勝手に壊さず、トーンを合わせて足してくれた。作り直しにならないのが安心。

＜詰まった・分かりにくかったところ＞

プロンプトの記号が呪文に見える。1-2の指示にあった「level3」「3層振分」「STORE_KEY昇格」「A2A」「rev=cr+sr」などの略語・専門用語が、初見では何を頼んでいるのか全く分からなかった。動くものは出てくるが「自分が何を注文したのか」を理解できないまま進む感覚があった。

「localStorage」「モーダル」「confirm禁止」など、“成果物の中身”を指定する言葉が説明なしで出てくる。エンジニア以外は意味を調べないと、良し悪しの判断ができない。

「白ベース・文字大きめ」のような日本語のふつうの指示はちゃんと効くのに、上記の略語が混ざると急に難易度が跳ね上がる。同じプロンプト内で難易度の落差が大きい。

画像は最初「絵文字とグラデーションで代替」で出てきて、写真は課題1-4で追加する形。「最初から実写が載る」と思っていると、少し想定と違う（ただし理由の説明はあった）。

出てきたファイルがデスクトップのフォルダに直接保存される。どこに何が出来たのか、最初は探した。

■ ③最初のコピペ用プロンプトへの具体的な改善案

冒頭に「用語ミニ辞典」を1行ずつ付ける。

例）「※localStorage＝ブラウザに保存して次回も残る仕組み ／ モーダル＝画面中央に出る確認ポップアップ ／ 3層振分＝重要度で赤・黄・緑に自動仕分け」。略語のままでも、横に日本語訳があるだけで安心感が段違い。

［　］の例文は「消してから使う」と赤字レベルで強調する。

今は例が親切すぎて、そのまま送っても動いてしまう。「← ここをあなたのお店の内容に書き換えてください」と、空欄であることが一目で分かる書き方にしてほしい。

プロンプトを「必須ブロック」と「おまかせブロック」に分ける。

• 必須（初心者が書く所）：何のサイト？／色や雰囲気／載せたい機能
• おまかせ（さわらなくてよい所）：level3・STORE_KEY昇格などの技術指定

後者に「※ここは変えなくてOK。仕組みの細かい注文です」と一言添えるだけで、迷いが消える。

「作り終わったら報告してほしいこと」を指定する行を入れる。

例）「最後に “何を作ったか／どこに保存したか／どう開くか” を箇条書きでまとめて」。実際これをやってくれると、ファイルを探す手間がなくなる。

画像の期待値を先に書いておく。

例）「写真はダミー画像でOK（後で差し替える）」or「実写風の画像を最初から入れて」。どちらを望むか最初に言えると、想定とのズレが起きない。

「途中で確認しながら進めて」オプションを案内する。

一気に全部作られると初心者は口を挟むタイミングが分からない。「1セクションごとに見せて」と頼めると書いてあると、初めてでもコントロールできる。

■ 総評（次にやる人へ）

「日本語で普通にお願いすれば、動くものがその場で出てくる」体験は、想像よりずっと簡単で感動的です。つまずくのは中身ではなく“プロンプトの専門用語”だけ。分からない略語は無理に理解しようとせず、まず送って動かし、出てきた画面を見てから「ここをこう変えて」と会話で直していくのが一番ラクでした。完璧なプロンプトを書こうとするより、6〜7割の指示で投げて、対話で仕上げるのがおすすめです。

# Claude Codeをはじめる（課題1-1〜1-4）やってみた感想フィードバック

次にやる人へ。実際に手を動かした人間の目線で、正直にまとめました。

① やった課題

• 1-1：シューティングゲームをHTMLで作る（動くものが一発で出てくる感動を最初に味わう回）
• 1-2：架空サービスのホームページを作る。「DESIGN.md（設計書）を先に作る → 美学プロンプトを適用 → セクション単位で実装」という“設計してから作る”流れを体験
• 1-3：そのHPの「裏側システム（運営管理ツール）」を仕様駆動で作る。5タブ・スコアリング・承認フロー・AI支援つきの管理画面を1ファイルで生成
• 1-4：やってみた感想を、次の人向けフィードバックとしてまとめる（今これ）

全体として「①動く楽しさ → ②設計の型 → ③実務っぽい規模 → ④振り返り」と、難易度と実務感が段階的に上がる良い構成でした。

② 想定外だったこと

◇ 良い意味で想定外・スムーズだった所

• とにかく完成が速い。「作って」と言うだけで、白ベース・大きめ文字みたいなふわっとした要望も汲んで、1回でそれっぽい完成品が出る。ここが一番の“おっ”ポイント。
• 設計書（DESIGN.md）を先に作る流れが効く。いきなり実装させるより、色・文字サイズ・セクション構成を先に文章で固めてから作らせる方が、出来上がりのブレが激減する。この“型”は他の作業にも応用が利く。
• 修正が対話で通じる。「ここ直して」で局所的に直してくれるので、全部作り直しにならない。
• ファイルが勝手に増えていくのが分かりやすい。DESIGN.md → index.html → admin.html と成果物が積み上がるので、進んでる実感がある。

◇ 詰まった所・分かりにくかった所

• 最初のコピペ用プロンプトが呪文すぎる。`CC(goal/Mon/batch/Plan/Hook/Rule/…)` や `仕様駆動MVP=level3 out:図解PNG+動くHTML単一(localStorage/JP/白)…` のような、記号と略語を詰め込んだ指示文。これが一番の壁でした。意味が分からないまま貼るので、「今なにを頼んでいるのか」が自分で説明できない。エラーではないけど“分かった気がしない”状態が続く。
• 専門用語が説明なしで出てくる。`localStorage`（データの保存場所）、`モーダル`（画面に重なって出る小窓）、`STORE_KEY昇格`（保存データの世代交換）、`A2A`（AI同士の連携）あたりは、非エンジニアには初見で意味が取れない。動くから困らないけど、応用しようとすると止まる。
• 「承認段階ゲート引継型」みたいな圧縮日本語も、読めるけど脳内で展開するのに一拍かかる。
• 成果物が想定より“本格的”すぎて逆に戸惑う瞬間がある。管理システムまで出てくると「これ自分が指示したことになってるけど中身を理解できてない」という置いてけぼり感が出る。すごい＝分かった、ではないと気づく。
• PNG書き出しなど裏側の手段は自動でよしなにやってくれるが、何が起きたか説明を読まないと再現できない。

③ 最初のコピペ用プロンプトへの改善案

一番効くのはここです。「圧縮呪文プロンプト」を、そのまま貼っても意味が分かる形にするだけで、初学者の体験が大きく変わります。

改善案1：略語を1行の“翻訳”付きにする

記号だけの指示の下に、日本語の意訳を1行添える。

例）

```

（この指示の意味）白ベースで文字が大きいHPを、①設計書を作る→②見た目の方針を決める→③部品ごとに作る、の順で進めてね。

```

呪文はそのまま残してOK。訳を1行足すだけで「自分が何を頼んだか」が言えるようになる。

改善案2：専門用語に（ )で超訳を付ける

`localStorage（ブラウザにデータを保存する仕組み）` のように、初出の用語だけカッコ書き。全部でなくていい、最初の1回だけ。

改善案3：プロンプトを「目的・成果物・条件」の3ブロックに分ける

記号で1行に詰めず、

```

【やりたいこと】非エンジニア向けAIスクールの管理画面

【ほしい成果物】動く1ファイルのHTML＋全体の図解

【条件】白基調 / 日本語 / 5画面 / データは端末内に保存

```

のように縦に3つ。同じ情報でも、読める・真似できる・改造できるが段違い。

改善案4：課題ごとに「これを学ぶ回」を1文で明示

各課題の冒頭に「この回のねらい：設計書を先に作ると仕上がりが安定することを体感する」のような目的文を置く。作業に入る前に“何のための課題か”が分かると迷子にならない。

改善案5：完成後に「今なにが起きたか」を一言で振り返らせる指示を入れる

プロンプトの最後に「最後に、今回やったことを非エンジニア向けに3行で説明して」と足すと、置いてけぼり感が消えて、次の応用につながる。

• --

まとめ：課題の“流れ”はとても良い。壁は中身ではなく、最初のコピペプロンプトの読めなさに集中しているので、そこに1〜2行の日本語訳を足すだけで、次の人はぐっと楽になります。

以下、そのままコピペできるテキストです。

• --

【Claude Code をはじめる（課題）— やってみた感想・次の人へのフィードバック】

■ ①やった課題（全体の流れ）

1. 銀座で3,000円のお得な休日プランを紹介するホームページ（LP）を作成

• DESIGN.md（設計書）を先に作る → Claude Cookbook の「美学プロンプト（デザイン原則）」を適用 → セクション単位で index.html を実装、という3ステップ構成
• 条件は「白ベース・文字大きめ」

2. LP に載せる具体的なお店（モーニング／ランチ／カフェ）を各3候補ずつ追記

3. その LP の「裏側の業務システム」をモックとして作成

• 5タブ／100点スコアリング＋3層(S/A/B)自動振分／承認フロー（受付→確認→承認→確定）／モーダル操作／localStorage保存の運営管理ツール
• あわせてシステム構成図（PNG）も出力

成果物は index.html（LP本体）、system.html（運営システム）、system_architecture.png（構成図）、DESIGN.md（設計書）の4点。すべて単一ファイルで完結し、ブラウザですぐ開けました。

■ ②想定外だったこと

＜スムーズだった所＞

• 「まずDESIGN.mdを作る→原則を適用→セクション単位で作る」という段取りを指示したら、その通りに順序立てて進んでくれた。いきなり全部作らせるより、設計→実装と分けたほうが仕上がりの意図が揃う。
• 「白ベース・文字大きめ」のような“ざっくりした見た目の希望”でも、余白・配色・フォントまで一貫性のあるデザインにしてくれた。
• 「銀座の実在店を3候補」のような追加注文に、既存デザインを崩さずカードを足す形できれいに追記してくれた。
• 「完成したらブラウザで開いて」まで一気にやってくれるので、確認が速い。

＜詰まった所・分かりにくかった言葉＞

• 最初のプロンプトの1行目が、記号だらけの超圧縮メモ（例：「CC(goal/Mon/batch/Plan/Hook/…)」「rev=cr+sr」）になっていて、これは“自分（人間）向けの覚え書き”なのか“AIへの指示”なのか判別しづらかった。結果的にAIは「指示」として解釈して丁寧に方針報告してくれたが、初見の人はこの1行の意味がまず分からず不安になると思う。
• 課題文の「［ホームページで作りたい内容 例：…］」の角括弧部分。“例”と書いてあるので「自分のテーマに書き換える欄」なのか「例のまま作ってほしい」のか曖昧。ここはAI側から「例のまま作りますか？別テーマにしますか？」と確認が入って初めて解決した。＝ユーザーが埋めるべき所が空欄のまま送られやすい。
• 2つ目の課題の「仕様駆動MVP=level3 / out:図解PNG＋動くHTML単一 / 100点+3層振分 / 各画面🤖pt / 承認段階ゲート引継型 / モーダル(confirm禁止) / STORE_KEY昇格 / 中規模A2A→open」も専門用語＆略語が密集。何を作ればゴールなのかを人間側が読み解くのに時間がかかる。特に「🤖pt＝各画面にAI提案を置く」「STORE_KEY昇格＝保存キーを定数化」「confirm禁止＝ブラウザ標準の確認ダイアログを使わず独自モーダルで」あたりは、意味を知らないと指示できない。
• 「図解PNG」を出す際、環境に画像生成ライブラリが入っておらず、内部で追加インストールが必要だった（自動で対応してくれたが、環境によっては一手間かかる）。
• 「A2A（エージェント分担）」を使うかどうかは、規模とスピードのどちらを取るかで変わる。今回は「急ぎ」を優先して1人で作る判断になったが、“いつ分担すべきか”は指示だけからは読み取りにくい。

■ ③最初のコピペ用プロンプトへの具体的な改善案

1. 「記号メモ行」を分離する／日本語の一文に置き換える

• 圧縮した記号列（CC(...)〜Ultra）は、初心者向け課題では消すか、末尾に「※上級者向けメモ」として隔離。代わりに冒頭は普通の日本語で「最適な進め方を選び、危険な操作の前は確認し、最後に選定理由・結果・要約を報告して」と書けば同じ意図が伝わる。料金は #ユニコスクール のセミナー内でご案内しています。料金は #ユニコスクール のセミナー内でご案内しています。

3. 専門用語・略語には必ず1行の言い換えを付ける

• 例：「100点+3層振分（=案件を100点満点で採点し、点数でS/A/Bの3グループに自動仕分け）」
• 「モーダル(confirm禁止)（=削除や確定の確認は、ブラウザ標準ダイアログでなくページ内の独自ポップアップで）」
• 「STORE_KEY昇格（=保存用のキー名を1つの定数にまとめる）」
• 「🤖pt（=各画面にAIのおすすめアクション欄を置く）」

略語はカッコ書きの平易な説明とセットにするだけで、再現性が大きく上がる。

4. 「ゴールの完成イメージ」を先頭に1〜2行で明記

• 仕様の羅列の前に「何ができたら完成か」を書く。例：「銀座プランLPの“裏側の予約管理ツール”を、実際にクリックして動くモックとして1つのHTMLで作る」。細目より先に全体像があると、読む側もAIも迷わない。

5. 完成条件・確認方法を最後に箇条書きで固定する

• 「①単一HTMLで動く ②ブラウザで開いて確認 ③サンプルデータ入り ④外部サービス連携はしない（見た目重視のモック）」のように受け入れ条件を書くと、期待どおりの物が一発で出やすい。

6. スピード優先か品質優先かを明示する

• 「急ぎ・イメージ確認優先」なのか「作り込み優先」なのかを一言入れると、AIが作業の粒度（分担するか・どこまで凝るか）を判断しやすい。今回は「急ぎ」と書いたことで素早くモックが出た。

■ まとめ（次にやる人へ）

• 段取り（設計→実装→確認）を指示に含めると質が安定する。
• 略語や記号の“自分メモ”はそのまま貼らず、平易な日本語に開いてから送るのが一番効く。
• 空欄（テーマ）は必ず埋める。埋め忘れそうなら「不明なら質問して」と書いておくと安全。
• 「完成の定義」を先に決めて末尾に書くと、手戻りが減る。

• --

文字数は約2,900字（6,000字以内）です。必要なら、より短い箇条書き版や、社内共有用のトーンに整えた版も作れます。

# 📝 Claude Codeをはじめる（課題1-1〜1-4）やってみた感想・次の人へのフィードバック

① やった課題（実際に作ったもの）

• 1-1：HTMLでシューティングゲーム作成

「凝ったオリジナルのシューティングを作って→ブラウザで開いて」と頼むだけで、単一HTMLのゲーム（パーティクル爆発・ボス・コンボ・効果音つき）が一発で出てきて、そのままブラウザで起動できた。

• 1-2：ホームページ（LP）のデザイン

「DESIGN.md作成→美学プロンプト適用→セクション単位で実装」の流れを指定。白ベース・文字大きめのお店のLPが完成。設計書と実物が両方できる。

• 1-3：裏側の管理システム（仕様駆動MVP）

予約管理システムを、スコアリング・3層振分・承認ワークフロー・5タブ構成で。動くHTMLと構成図PNGの2点セットで出力。

• 1-4：このフィードバックまとめ

作業を振り返って文章化。ファイルではなくコピペ用テキストで、と指定すればその通りに出る。

② 想定外だったこと

### 😲 詰まった／分かりにくかった所

• プロンプトの「省略記法」が難解すぎた

`CC(goal/Mon/batch/Plan/...)` や `仕様駆動MVP=level3・100点+3層振分・STORE_KEY昇格・中規模A2A` のような圧縮された指示。Claudeは解釈して動いてくれるが、自分（人間）が後で読み返すと意味が分からない。これは「動いたからOK」ではなく、次の人がマネできない。

• テンプレの角括弧を埋め忘れた

`[ホームページで作りたい内容 例：原宿の…]` の例文をそのまま送ってしまった。Claudeは「例のままですが？」と確認してくれたので事故にはならなかったが、穴埋め箇所は自分で埋めてから送るのが大前提。

• 専門用語がそのまま通る=逆に危険

「承認ゲート引継型」「STORE_KEY昇格」など、雰囲気で書いた言葉もClaudeが良い感じに実装してくれる。ただし自分が言葉の意味を分かっていないと、出来上がりが合っているか判断できない。

### 😊 逆にスムーズだった所

• 「完成したらブラウザで開いて」が本当に開く。確認の手間がゼロ。
• 曖昧でも止まらない。「凄いと思うツールにして」レベルのふんわり指示でも、それっぽく仕上げてくれる。
• 必要な時だけ質問してくれる。全部聞いてこず、題材みたいな本当に重要な分岐だけ確認が入る。テンポが良い。
• 1メッセージで複数成果物（HTML＋設計書＋PNG図解）が同時に出るのが想像以上に便利。

③ 最初のコピペ用プロンプトへの改善案

改善の核：省略記法をやめ、日本語の一文で書く。「何を・どんな見た目で・最後にどうしてほしいか」の3点だけ埋めれば十分動く。

### ▼ そのまま使えるテンプレ（推奨版）

```

【作りたいもの】（例：原宿でTikTokバズ中のスイーツ店のホームページ）

【見た目の希望】（例：白ベース・文字大きめ・スマホでも見やすく）

【使う技術】HTML1ファイルで完結（外部サービス連携なし、まずはイメージ確認）

【最後にしてほしいこと】完成したらブラウザで開いて

※急ぎです。凝ったモックにしてください。

```

### ▼ 具体的な直しどころ

1. 暗号記法は封印する

`level3・A2A・STORE_KEY昇格` などは書かない。どうしても細かく指定したいなら「予約に0〜100点の優先度をつけて、高・中・低の3グループに分けて」のように普通の日本語で条件を書く。Claudeは十分くみ取る。

2. 角括弧の例文は必ず自分の内容に置き換える

`[例：〜]` を消して実物を書く。埋めていないと確認のラリーが1往復増える（＝時間ロス）。

3. 「白ベース・文字大きめ」のような見た目条件は1行入れる

これがあるだけで仕上がりの方向性が安定する。逆に無いと汎用的な見た目になりがち。

4. 成果物の形式を先に指定する

「HTMLで」「テキストで」「◯字以内で」「ファイルにせず」を最初に言うと、出力形式で手戻りしない。今回もこの指定があった課題はスムーズだった。

5. 専門用語を使うときは1行の説明を添える

「承認ゲート（申込→確認→承認→確定の4段階で進める仕組み）」のように補足すると、自分の理解と出来上がりのズレを防げる。

### ▼ 次の人への一言

Claude Codeは「ざっくり頼む→動くものが出る→触って直す」が高速で回る。最初から完璧なプロンプトを書こうとせず、まず粗く投げて、出てきた実物を見てから注文を足すのが一番ラク。ただし\*\*題材（何のサイトか）だけは最初にハッキリ\*\*決めておくこと。ここが曖昧だと全部やり直しになる。

■ Claude Codeをはじめる（課題1-1〜1-4）やってみた感想・次の人へのフィードバック

【① やった課題】

1-1：HTMLでオリジナルのシューティングゲームを作成→ブラウザで確認

1-2：ホームページ制作（DESIGN.md作成→美学プロンプト適用→セクション単位で実装）。テーマは「茨城県B級グルメランキング」、白ベース・文字大きめ

1-3：そのHPの「裏側システム（運営管理ツール）」を仕様駆動MVPで作成。5タブ・100点採点・3層自動振分・段階承認・localStorage保存など

1-4：1-3を「進める」＝管理ツールと公開サイトを実際に連携（公開した番付がサイトに自動反映）＋投稿フォーム追加

一言でいうと、「1個作る」→「デザインを設計から作る」→「その裏側の業務システムを作る」→「つなげて完成に近づける」という、実務に一番近い流れを一気に体験できる構成でした。

【② 想定外だったこと】

＜良い意味で想定外・スムーズだった所＞

• 「作って」だけでも、こちらが具体を詰めなくてもかなり作り込んでくれる。ゲームも管理ツールも、想像の3倍リッチな完成度で出てきて驚いた。
• 作ったら勝手にブラウザで開いてくれる。ファイルの場所（フルパス）も明示してくれるので「どこ？」と探さずに済む。
• 「進めてください」の一言で、次にやるべき妥当な作業を選んで実行してくれた。丸投げが効く。
• 1個前に作ったもの（HP）を土台に、裏側システム→連携、と積み上がっていくのが気持ちいい。単発で終わらない。

＜詰まった所・分かりにくかった言葉＞

• 専門用語がそのまま出てくる場面がある。「localStorage」「MVP」「モーダル」「A2A」「セクション単位」「フォールバック」あたりは、非エンジニアだと最初は意味が取りづらい。動くので困りはしないが、"何が起きているか"の理解が追いつかない瞬間があった。
• 「サービス連携」と「（ツール同士の）連携」が別物、という区別が最初わからなかった。1-4で「連携はしないでと言ったのに連携してる？」と一瞬混乱。実際は「外部サービス（Chatwork等）とはつながないが、自分のPC内でファイル同士はつなぐ」という意味だった。ここは説明があると安心。
• 成果物が「本物のデータではなくサンプル（架空の数値）」である点。ちゃんと明記はしてくれるが、パッと見が本格的なので、そのまま社内で共有すると「実データ」と誤解されそうだと感じた。
• 「テーマは例のまま？」と最初に1回確認された。これは正しい挙動だが、指示文の[例：〜]をそのまま送ると"例"と解釈される、という仕様に最初気づかなかった。

＜期待とのズレ＞

• ゲームやツールは動くが、音が出る・画像は外部から借りたイメージ、など「そのまま業務に使う」には一手間いる。あくまで"イメージを掴む・叩き台を作る"用途だと最初に理解しておくと期待値がちょうど良い。

【③ 最初のコピペ用プロンプトへの改善案】

今回、課題によっては下記のような超圧縮プロンプトを使う場面があった：

　例）「CC(goal/Mon/batch/Plan/Hook/Rule/Skill/Flow/allow/Mem/sec/task/Team/rw/rev=cr+sr/Ultra)最適選択→batch/Flow FO→待Mon…」

　例）「仕様駆動MVP=level3。out:図解PNG+動くHTML単一(localStorage/JP/白)・5tab・100点+3層振分…」

これは"効く"のだが、初見の人にはまず読めない。次の人向けに、以下を提案します。

(1) 最初のプロンプトは「日本語の普通の文」で始めてよいと明記する

　→ 圧縮記法（略語ずらずら）は上級者向けの時短テク。最初から真似する必要はない、と一言添える。「〇〇を作って。白ベースで文字大きめ。完成したらブラウザで開いて」で十分伝わる。

(2) 略語には初回だけ日本語の注釈を付けるテンプレにする

　→ 例：「MVP（＝まず動く最小版）」「localStorage（＝このPCのブラウザ内に保存／サーバ不要）」「モーダル（＝画面中央に出る確認ウィンドウ）」。1回説明があるだけで安心感が段違い。

(3) 「サンプルか実データか」を先に宣言させる項目を入れる

　→ プロンプトに「※中身はサンプルでOK／実データ使用」の一行を最初から入れておくと、成果物の位置づけがブレない。

(4) [例：〜]のプレースホルダは"置き換える欄"だと明示する

　→ テンプレ側に「← ここを自分のテーマに書き換える（例のまま送らない）」と注意書きを入れると、最初の確認往復が1回減る。

(5) 「連携」の言葉を分けて使う

　→ 「外部サービス連携（Chatwork/フォーム等）」と「ローカル連携（ファイル同士）」は別物、とテンプレ内で用語を分けておくと混乱しない。今回の「連携は一旦しないで」も、どちらを指すか明確になる。

(6) 完成イメージの合意を先に取るオプションを推奨

　→ 「いきなり作らず、先に何を作るか1回すり合わせてから着手して」と書けるオプションがあると、認識ズレの手戻りが減る。逆に「とにかく叩き台を早く見たい」時は今のまま丸投げでOK、と2モード用意すると親切。

【総括】

非エンジニアでも「日本語で頼めば動くものが出てくる」体験の価値が非常に大きい課題群でした。詰まりの多くは"言葉の壁"であって"操作の壁"ではないので、略語の注釈とサンプル/実データの宣言、この2点をテンプレに足すだけで、次の人の体験はかなり滑らかになると思います。まずは気軽に日本語一文から。慣れたら圧縮記法で高速化、という順番がおすすめです。

【Claude Code をはじめる（課題1-1〜1-4）やってみた感想・次の人へのフィードバック】

■ 前提

• 題材：稲城・立川のアートメイクHP＋その裏側の予約/顧客管理システムをモックで作成
• 環境：Windows 11 / OneDrive配下のフォルダ / 日本語で指示

────────────────────

① やった課題（実際にやったこと）

────────────────────

1-1：HPデザインの土台づくり

　→ DESIGN.md（設計書）を先に作り、配色・フォント・セクション構成を言語化。

1-2：美学プロンプトの適用

　→ 「装飾より余白・見出しで階層・アクセント1色」といった品質基準をDESIGN.mdに埋め込み、実装時に注入。

1-3：セクション単位でHPを実装

　→ Hero〜アクセス〜予約CTAまで1枚のindex.htmlに。白ベース・文字大きめ・レスポンシブ。

1-4：裏側システム（業務ツール）をモック作成

　→ 5タブ管理画面、100点スコアリング＋A/B/C振分、承認フロー、売上グラフ、localStorage保存、構成図PNGまで一気に生成。

学び：「いきなり作って」より、先にDESIGN.md＝仕様を書かせてから実装させると、出来上がりの一貫性が段違い。これが一番の収穫。

────────────────────

② 想定外だったこと

────────────────────

▼ 詰まった所

• OneDrive配下のフォルダに、Chromeのヘッドレスで画像を書き出そうとすると「アクセスが拒否されました」で失敗した。一旦Tempに書き出してからコピーで解決したが、初見だと原因が分かりにくい。OneDrive同期フォルダは書き込み制限に当たることがある、と知っておくと良い。
• 日本語パス（「デスクトップ」など）が絡むと、file:// のURL指定でひと手間かかる。半角英数のフォルダ名の方が確実に楽。
• PNG書き出しなど「ファイルを生成する系」は、環境ツールの有無に依存して一発では通らないことがある。SVGなど代替で出す前提でいるとストレスが少ない。

▼ 分かりにくかった言葉

• 略語・記号だらけの指示（例：「100点+3層振分」「承認段階ゲート引継型」「STORE_KEY昇格」「confirm禁止」）は、書いた本人以外には解読が必要。AIは汲み取ってくれるが、認識ズレのリスクがある。用語は一度だけでも普通の日本語で補足しておくと事故が減る。
• 「level3」「A2A」「FO」等の独自スケール表現は、共通定義がないと期待値がブレる。

▼ 逆にスムーズだった所

• 「白ベース・文字大きめ・日本語」のような具体的で判断に迷わない条件は、そのまま綺麗に反映された。抽象的な形容詞より、色・サイズ・言語の明示が効く。
• 「セクション単位で」「サンプル5〜15件」など、粒度と分量を数字で指定した部分は手戻りゼロ。
• 「confirm禁止・独自モーダルで」のように“やってほしくない事＋代替”をセットで書くと一発で意図通りになった。
• 完成後に「ブラウザで開いて」まで指示すると、確認まで含めて完結して楽だった。

────────────────────

③ 最初のコピペ用プロンプトへの改善案

────────────────────

次の人が最初にコピペするプロンプトは、以下を足すと詰まりにくくなります。

【改善案A：作業フォルダの指定を最初に明示】

• 「作業フォルダは C:\work\xxx（半角英数・OneDright配下を避ける）」のように、同期フォルダ・日本語パスを避ける指示を冒頭に入れる。画像書き出し系のアクセス拒否を予防できる。

【改善案B：略語には初回だけ注釈を付ける】

　悪い例：「100点+3層振分・承認ゲート引継型・confirm禁止」

　良い例：「100点満点でスコア化しA/B/Cの3段階に自動振り分け（3層振分）。承認は段階ごとに次の担当へ引き継ぐ形式（引継型）。確認ダイアログはブラウザ標準のconfirmを使わず独自モーダルで（confirm禁止）」

　→ AIの解釈は正確になり、レビュー時も他人が読める。

【改善案C：成果物の“形式と代替”を先に決める】

• 「PNGが環境的に難しければSVGで代替可」など、出力形式にフォールバックを許可しておくと、途中で止まらず最後まで走る。

【改善案D：完了条件（DoD）を1行入れる】

• 「完成したらブラウザで開いて、5タブすべて表示されることを確認して報告」まで書くと、動作確認込みで返ってくる。

【改善案E：まずDESIGN.md／仕様書を書かせてから実装させる、を定型化】

• 「①仕様書を先に作成 → ②レビュー → ③実装」の順を最初のプロンプトに固定で入れる。これだけで完成物の質が安定する。1-1〜1-4を通じて一番効果が大きかったのがこの順序。

【まとめ・次の人へ】

• 迷ったら「具体的な数字・色・言語・禁止事項＋代替」で書く。形容詞より条件。
• 独自の略語は便利だが、初回だけは普通の日本語で。
• 保存先はOneDriveや日本語パスを避けると画像生成系で詰まらない。
• 「作って終わり」ではなく「開いて確認して報告して」まで書くと完結して気持ちいい。
• 所要感：仕様→実装の型さえ掴めば、HP1枚も業務ツール1本も想像よりずっと速く形になる。最初の一歩としては達成感が大きい課題でした。

• --

━━━━━━━━…

【Claude Codeをはじめる（課題1-1〜1-4）やってみた感想】

次にやる人へのフィードバック

━━━━━━━━…

■ ① やった課題（ざっくり流れ）

• 1-1〜1-2：ブランド情報をClaudeに覚えさせて、ペット用CBDブランド「Cansuna」のホームページ（HP）を1枚作成。白基調・ナチュラル系のデザインで、商品・価格・コンセプトまで反映されたものが出てきた。
• 1-3〜1-4：そのHPの「裏側システム（管理画面）」を作成。受注管理・顧客CRM・在庫・承認フローなどを持つ業務ツールを、動くHTML1ファイル＋システム図解PNGとして出力。

結論から言うと、指示文をポンと投げるだけで「見て動くもの」がその場で出てくる体験は普通に感動する。コードを1行も書かなくてよかった。

■ ② 想定外だったこと

【詰まった / 分かりにくかった所】

• とにかく最初のコピペ用プロンプトの「暗号感」が強い。

　例：仕様駆動MVP=level3、out:図解PNG+動くHTML単一、STORE_KEY昇格、中規模A2A→open のような圧縮された指示。意味が分かる人には速いが、初見だと「これは呪文？」となる。何をお願いしているのか自分で説明できないまま実行することになり、出てきた結果が「合っているのか」を判断できなかった。

• 専門用語がノー説明で出てくる。
• 「A2A」＝Agent to Agent（AI同士のタスク引き継ぎ）
• 「STORE_KEY昇格」＝データ保存キーのバージョン移行
• 「3層振り分け」「100点スコアリング」＝受注を点数化して自動仕分け

　どれも“出てきた画面を見て”初めて意味が分かった。先に一言説明があれば安心して進めた。

• 「HP」と「裏側システム」の関係が最初ピンとこなかった。

　表（お客さん向けサイト）と裏（社内の管理画面）は別物、という前提が共有されていないと、「さっき作ったやつの何を作るの？」で一瞬止まる。

• 出力物がどこに保存されたか一瞬迷子になる。

　ファイルが natural-ec-hp/admin/… のような階層に作られるので、「どこ開けばいいの」となった。最後にブラウザで自動で開いてくれて助かったが、パスの案内はもっと目立ってほしい。

【逆にスムーズだった所】

• ブランド情報を一度覚えさせると、次以降の課題で価格や商品名を勝手に正しく使ってくれる。入力の手間が激減する。
• 「モックでいい」「連携はしなくていい」と伝えれば、余計な設定や外部接続を求められず、イメージ確認までが速い。
• 出来上がりがちゃんと“それっぽく綺麗”。デザインの良し悪しで悩む時間がなかった。
• 図解PNGが付いてくるので、システムの全体像を人に説明しやすい。

■ ③ 最初のコピペ用プロンプトへの改善案（具体）

（1）暗号を「日本語1行の目的」とセットにする

　現状の圧縮指示はそのまま残してよいが、冒頭に「これから何を作るか」を普通の日本語で1行足すだけで安心感が段違い。

　改善例：

　> 【目的】さっき作ったHPの“社内管理画面（裏側システム）”をモックで作ります。

　> 【仕様】仕様駆動MVP=level3 / out:図解PNG＋動くHTML単一 / …（以下そのまま）

（2）専門用語に米印で超短い注釈をつける

　改善例：

　> ・3層振り分け（※注文を点数化して「自動出荷/要確認/要保留」に自動仕分け）

　> ・A2A（※AI同士がタスクをバトンのように引き継ぐ仕組み）

　> ・STORE_KEY昇格（※データ保存の“箱”を新バージョンへ引っ越し）

（3）「表と裏」を最初に1文で定義する

　改善例：

　> ※前提：HP＝お客様向けの表サイト、裏側システム＝社内が使う管理画面。今回は後者を作ります。

（4）完了条件と保存先を明記する

　改善例：

　> 【完了条件】①動くHTML1ファイル ②システム図解PNG の2点を作り、保存先フルパスを教えてから自動でブラウザ表示。

（5）「急ぎ・モック・連携なし」は最初に宣言する

　これは今回とても効いた。プロンプト冒頭に固定で入れておくと迷いがない。

　改善例：

　> ※今回はイメージ確認が目的。外部サービス連携はせず、モックで“凄い！”と思える完成度で。急ぎでお願いします。

■ まとめ（次の人へ一言）

「意味が分からない単語が出てきても、まず実行してOK。画面が出てから理解できる」——これが分かっていれば怖くない。ただ、最初のプロンプトは“暗号＋日本語の目的1行＋用語の米印注釈”の形にしておくと、次の人は詰まらず走れます。出力の完成度は期待以上なので、身構えず気楽にどうぞ。

━━━━━━━━…

「Claude Codeをはじめる（課題1-1〜1-4）」をやってみた感想・フィードバック

■① やった課題

• 課題1-1：肩慣らし。簡単なゲーム（テトリス、シューティング）を1ファイルのHTMLで作ってもらい、Claude Codeとの基本的なやりとり（指示→生成→ブラウザで確認）を体験。
• 課題1-2：ホームページ制作。「1. DESIGN.md（設計書）を作る → 2. デザインの美学プロンプトを適用 → 3. セクション単位で実装」という3ステップで、研修講師のHP（白ベース・文字大きめ・単一HTML）を作成。
• 課題1-3：そのHPの「裏側」の業務管理システムをモックで作成。問い合わせ案件を100点満点で自動採点してA/B/Cに振り分け、段階ごとの承認ゲートで管理する5タブのツール＋システム構成の図解PNG。
• 課題1-4：この振り返りフィードバックの作成。

■② 想定外だったこと

【スムーズだった所】

• 指示が曖昧だと、Claudeの方から選択肢つきの質問が返ってくる。「題材は？」「目的は？」「技術構成は？」をポチポチ選ぶだけで要件が固まった。自分で仕様を全部書けなくても始められるのは想像以上に楽。
• 「DESIGN.md を先に作る」流れが効いた。いきなりコードではなく設計書ができるので、方向性のズレにその時点で気づける。後工程の判断基準（色・文字サイズ・余白）が全部そこに書かれるので、出来上がりの一貫性が高い。
• 完成物の品質が想定を大きく超えた。「凄い！と思うツールにして」という一文だけで、ダッシュボードのKPIやグラフ、承認フローまで勝手に設計してくれる。
• 作った後に自分でブラウザを開いて確認するだけでなく、Claude側がプレビューを開いてスクリーンショットや動作テスト（ボタンを押して結果を確認）までやってから「完成」と報告してくる。検証込みなのは安心感があった。

【詰まった所・戸惑った所】

• 環境起因のエラーが途中で何度か出た（Pythonが実際には未インストールだった、日本語フォルダ名でPowerShellスクリプトが文字化けした、スクリーンショット機能がタイムアウトした）。ただし全部Claudeが自力で原因を判断して別の手段に切り替えて完走した。初心者は「エラーが出た＝失敗」と思って止めてしまいがちだが、「エラーが出ても放っておけばリカバリすることが多い」と最初に知っておきたかった。
• 作業フォルダ名を日本語（「ユニコスクール」）にしたのが文字化けトラブルの一因だった様子。半角英数のフォルダ名を推奨と書いてあると親切。
• ツールの実行許可を求めるダイアログが何度か出るが、何を許可しているのか最初は分からず全部OKしていた。「ファイル書き込みとコマンド実行の許可を求められます。作業フォルダ内なら基本OKで大丈夫」といった一言があると安心。

【分かりにくかった言葉】

• 課題テンプレの略語・専門用語が初心者にはほぼ暗号だった。具体的には「MVP」「モック」「localStorage」「STORE_KEY昇格」「A2A」「ゲート引継型」「confirm禁止」など。結果的にClaudeは正しく解釈してくれたが、自分が何を指示しているのか分からないまま貼り付けるのは不安だった。用語集（1行ずつでいい）が欲しい。
• 「仕様駆動」「level3」のようなレベル指定も、何がどう変わるのか説明がないと選びようがない。

■③ 最初のコピペ用プロンプトへの具体的な改善案

現状のテンプレは「CC(goal/Mon/batch/…)」「out:図解PNG+動くHTML単一(localStorage/JP/白)…」のような記号の羅列で、動きはするが初心者には意味不明。以下の方針で平文化するのを提案したい。

改善方針：

1. 略語をやめて日本語の箇条書きにする（Claudeは平文でも同じ精度で動く）。

2. 「分からないことは選択肢つきで質問して」を明記する（これが一番効く。曖昧なまま走られるのを防げる）。

3. 完成条件を書く（「最後にブラウザで開いて見せて」まで書くと、動作確認込みで納品される）。

4. 「モックでOK・外部サービス連携なし」は残す（この一言で“それらしいサンプルデータ入り”の見栄えのする物が出てくる）。

5. 差し替え前提の箇所（実名・実績数値・問い合わせ先）はプレースホルダでよいと明記する。

改善版プロンプト例（このままコピペ用）：

• --

ホームページを作ってください。進め方は次の3ステップでお願いします。

1. まず DESIGN.md（デザイン設計書）を作る

2. 洗練されたデザイン原則（余白・タイポグラフィ・抑えた配色）を適用する

3. セクション単位で実装する

条件：

• 題材：〔例：会計・ビジネス研修講師の紹介サイト〕
• 白ベース、文字大きめ、日本語
• HTML1ファイルで完結（外部サービス連携なし、モックでOK）
• 実名や実績の数字は仮でよい（後で差し替える）
• 不明点があれば、選択肢つきで私に質問してから進めて
• 完成したらブラウザで開いて見せて
• --

このほか運用面では、「エラーが出ても止めずに見守ってよい」「フォルダ名は半角英数推奨」「許可ダイアログは作業フォルダ内なら基本OK」の3点を課題ページの冒頭に注意書きとして載せると、次にやる人の不安がかなり減ると思います。

【Claude Codeをはじめる 課題1-1〜1-4 やってみた感想 / 次の人へのフィードバック】

■ ① やった課題（概要）

• 課題1-1：HTMLで「作り込んだシューティングゲーム」を作成 → ブラウザで表示。Canvas・パーティクル・ボス戦・パワーアップ・効果音（WebAudioで自動生成）まで一気に作れた。
• 課題1-2：バグ修正。「GAME STARTを押しても始まらない」不具合を報告 → 原因を特定して修正（後述）。
• 課題1-3：ホームページ制作。「①DESIGN.md作成 → ②Claude Cookbookの美学プロンプト適用 → ③セクション単位で実装」の流れで、白ベース・文字大きめの店舗サイトを作成。その後「口コミを表示させて」で追加修正。
• 課題1-4：そのHPの裏側システム（業務管理ツール）を仕様駆動で作成。5タブ・localStorage保存・承認ゲート・口コミ自動採点などのモックを単一HTMLで作成。

総じて「指示 → 数十秒で動くものが出てくる → ブラウザで即確認」のサイクルが速く、初学者でも“完成物が目に見える”達成感がとても大きい。

■ ② 想定外だったこと

【詰まった所】

• 一番ハマったのは課題1-2の「ボタンを押しても反応しない」。原因は、HTMLファイルをダブルクリックして file:// で開くと、ブラウザによっては localStorage へのアクセスがブロックされ、そこでJavaScript全体が止まる → ボタンの処理も登録されない、というもの。“見た目は完成しているのに動かない”ので初見だと絶対に自力で気づけない。次の人はここで必ず一度つまずくと思う。

→ 対処法だけ先に知っておくと安心：「動かないときは F12（開発者ツール）→ Console のエラーを見て、その文言をそのままClaudeに貼る」。これで一発で直った。

• 課題1-3で「口コミが表示されない」現象。スクロールで“ふわっと出る”演出（最初は透明）にしていたため、環境によって出ないままになっていた。これも「なぜか一部だけ表示されない」系で分かりにくい。

【分かりにくかった言葉】

• 課題1-4の最初に貼るプロンプトが記号だらけで意味を取るのが大変だった。例：

「仕様駆動MVP=level3」「100点+3層振分」「各画面🤖pt」「承認段階ゲート引継型」「モーダル(confirm禁止)」「STORE_KEY昇格」「中規模A2A→open(フルパス+説明)」

→ これらは“略語・専門用語”で、初学者はまず「これ何を頼んでるの？」で止まる。Claudeは解釈して作ってくれるが、意図と少しズレると手戻りになる。日本語のふつうの文に開いてあると安心できる。

• 「A2A」「FO(ファンアウト)」「Mon(モニター)」など運用系の略語も、初学者にはまず通じない。

【逆にスムーズだった所】

• 「完成したらブラウザで開いて」と書いておくと、自動でブラウザ表示までやってくれて確認が楽だった。
• 課題1-3の「DESIGN.md → 美学プロンプト → セクション実装」という段取り指定は非常に効果的。設計を先に文書化させることで、いきなり作るより仕上がりの一貫性が高く、途中の意図も追いやすかった。この“先に設計書を書かせる”流れは全課題で使える。
• 「白ベース」「文字大きめ」のような見た目の方向性を一言添えるだけで、狙い通りのトーンになった。曖昧なほどブレるので、短い形容詞を足すのが効く。
• 修正依頼が「口コミを表示して」「スタートしない」のような自然文でOKだったのが助かった。専門用語を使わなくても直してくれる。

■ ③ 最初のコピペ用プロンプトへの具体的な改善案

1) 略語・記号は最初に“日本語で1行”添える

悪い例：`out:図解PNG+動くHTML単一(localStorage/JP/白)・5tab・100点+3層振分`

改善例：「1つのHTMLファイルで動く管理ツールを作って。データはブラウザ内(localStorage)に保存、日本語・白ベース、タブは5つ。口コミは100点で採点して“要対応/通常/優良”の3段階に自動仕分け。」

→ 記号版を残すなら、その下に「＝つまり〜」と平文の言い換えを1文だけ付ける。

2) 「作りたい内容」を必ず具体で埋める（例のまま送らない）

テンプレに `[例：足立区でバズっているスイーツのお店]` のような欄がある場合、例文のまま送ると「例のままでいい？」と確認が入り一手増える。最初から店名・業種・目的を1行で埋めておくとスムーズ。

3) 動作確認の“お約束”を最初のプロンプトに入れておく

追記推奨文：「完成したらブラウザで開いて。もし表示・動作がおかしい時は、開発者ツール(F12)のConsoleエラーも確認して直して。」

→ file://で開くと起きる不具合（localStorage等）を最初から拾ってくれるので、1-2のような“無言で動かない”を回避できる。

4) file://問題を先回りで宣言する

一文入れるだけで安定：「ローカルのHTMLファイル(file://)を直接開いて動く前提で作って。localStorage等が使えない環境でも画面が真っ白／無反応にならないよう、エラーで全体が止まらない作りにして。」

5) “完成の定義”を3〜5個の箇条書きで渡す

例：「・スマホでも崩れない ・コンソールエラー0 ・画像が無くても成立 ・主要ボタンが実際に動く」。これがあると仕上がりが安定し、レビューも早い。

6) 段取りを指定する（設計→実装の2段構え）

「いきなり作らず、まず設計をDESIGN.mdにまとめて。方向性OKなら実装して。」と書くと、意図ズレの手戻りが激減する。1-3で効果が大きかったやり方。

■ ひとことまとめ

出てくるスピードと“動く実物が見られる”体験は最高。次の人が転ぶのはだいたい「file://で開いて無反応」「記号だらけの指示の意味が分からない」の2点なので、①指示は平文で具体的に、②「ブラウザで開いて＋Consoleエラーも見て直して」を最初に添える、これだけで体験が一段スムーズになります。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Claude Codeをはじめる（課題1-1〜1-4）体験フィードバック

次にやる人へ

━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■ ① やった課題（ざっくり流れ）

• 課題1-1｜シューティングゲーム作成

　「HTMLでオリジナルのシューティングゲームを作って、完成したらブラウザで開いて」と指示。1ファイルのHTMLで、敵5種＋ボス＋パワーアップ＋効果音まで一発で出てきて、そのまま遊べた。

• 課題1-2｜ホームページのデザイン

　「歯のホワイトニング比較サイト」を、(1)DESIGN.md作成 →(2)美学プロンプト適用 →(3)セクション単位で実装、という流れで作成。「白ベース・文字大きめ」など条件を渡すと、設計書と完成HTMLの両方が出た。

• 課題1-3｜内容の絞り込み

　「オフィスホワイトニング特化でいい」と一言足しただけで、該当セクションだけを賢く差し替えてくれた。作り直しではなく“部分修正”になるのが分かりやすかった。

• 課題1-4｜裏側システム作成

　比較サイトの運営管理システム（5タブのダッシュボード）をモックで作成。ダッシュボード／クリニック管理／スコアリング／問い合わせ／承認フローが動く単一HTMLと、構成図が出てきた。

■ ② 想定外だったこと

【詰まった／戸惑った所】

• 課題1-4の“呪文のような指示”がいちばん詰まる

　「level3・100点+3層振分・STORE_KEY昇格・A2A・承認段階ゲート引継型…」のような略語の詰め込みは、書く側も読む側も解釈がブレやすい。実際はAI側が「こう解釈しました」と表で返してくれたので助かったが、初心者が最初からこの粒度で書くのはハードルが高い。普通の日本語で書いても十分伝わった。

• 専門用語がそのまま出てくる

　「localStorage」「モーダル」「A2A（エージェント連携）」「STORE_KEY」あたりは、非エンジニアには一瞬止まる。意味は「ブラウザにデータを保存」「確認ポップアップ」程度で、後から分かればOKだが、最初は不安になる。

• ファイルの“置き場所”が見えにくい

　作られたファイルがデスクトップのどのフォルダに入ったか、最初ピンとこなかった。フルパスを出してもらって初めて安心できた。

【分かりにくかった言葉】

• 「セクション単位で実行」＝一気に全部ではなく、部分ごとに作る、の意味。
• 「昇格」＝下書きを本番公開に反映する、の意味。日常語と違う使われ方で戸惑う。
• 「モック」＝見た目・動きだけの試作（実際のデータ連携はなし）。

【逆にスムーズだった所】

• 「完成したらブラウザで開いて」が効く。結果をすぐ目で確認できて達成感が大きい。
• 修正が“会話の続き”でできる。「オフィス特化で」の一言で意図を汲んで直してくれた。
• 条件（白ベース・文字大きめ・急ぎ）を短く添えるほど、狙い通りになった。
• 完成後に「次にやるなら○○」と提案が出るので、手が止まらない。

■ ③ 最初のコピペ用プロンプトへの具体的な改善案

そのまま渡せば動く“型”にすると、次の人がラクになります。

【改善案A｜初心者向けの素直な型（推奨）】

• -------…

□□（作りたいもの）を作ってください。

• 用途／見てほしいイメージ：
• デザインの希望（例：白ベース・文字大きめ）：
• 入れたい要素（箇条書きで3〜5個）：
• 完成したらブラウザで開いてください。
• 専門用語には一言だけ説明を添えてください。
• -------…

→ 略語を使わなくても意図は十分伝わる。まずはこれで十分。

【改善案B｜略語テンプレを使うなら“凡例”を先頭に】

　「level3」「3層振分」等の略語テンプレは強力だが、配布時に必ず用語対訳（凡例）を添える。

　例：STORE_KEY＝保存場所のこと／昇格＝本番公開への反映／モーダル＝確認ポップアップ／A2A＝作業の自動分担。

　→ これがあるだけで、コピペした人が「何を頼んでいるか」を理解できる。

【改善案C｜最初のプロンプトに“お約束”を1行入れる】

　役立ったので、テンプレ末尾に固定文として推奨：

　「作ったファイルは同じフォルダにまとめ、最後にフルパスと簡単な説明を教えてください。完成したらブラウザで開いてください。」

【そのほか、次の人へのコツ】

• 最初から完璧を狙わない。まず作ってもらい、「ここだけ直して」と会話で育てる方が速い。
• 条件は“短く具体的に”。長い呪文より「白ベース／文字大きめ／急ぎ」の方が効く。
• 分からない単語は遠慮なく「○○ってどういう意味？」と聞いてよい。止まらずに進める。
• 「モックでOK（見た目だけでいい）」と伝えると、余計な作り込みを省いて速く出る。

■ ひとことまとめ

　“ちゃんとした指示”より“ふつうの日本語＋見たいイメージ＋ブラウザで開いて”の3点セットで、想像以上のものが出ます。難しい略語テンプレは「慣れてから／凡例つきで」で十分。まずは気軽に一つ作ってみるのがいちばんの近道でした。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━

以下、そのままコピペできる形でまとめました。

• --

# 【Claude Codeをはじめる 課題1-1〜1-4】やってみた感想・次の人へのフィードバック

① やった課題

• 1-1 シューティングゲーム作成：「HTMLで超作り込んだオリジナルのシューティングゲーム」を依頼 → 単一HTMLでネオン風の縦STG（敵4種・ボス・パワーアップ・スコア保存）が一発生成され、ブラウザで即プレイできた。
• 1-2 ホームページのデザイン：損害保険募集人のHPを、「DESIGN.md作成 → Cookbookの美学プロンプト適用 → セクション単位で実装」の流れで作成。白ベース・大きめ文字で12セクション。
• 1-3 裏側システム（業務効率化ツール）：HPの裏側にあたるAI業務管理コンソールを作成。5タブ・100点スコアリング・承認ワークフロー等をモックで実装＋構成図。
• 1-4 振り返り：この課題全体を、次にやる人向けのフィードバックとしてまとめた（＝この文章）。

② 想定外だったこと

詰まった所

• プロンプトを略語で詰め込みすぎると、意図が正しく伝わるか不安になった。 「CC(goal/Mon/batch/Plan/Hook/Rule/Skill/Flow/allow/Mem/sec/task/…)」のような書き方は、自分では「全部盛りで指示したつもり」でも、実際にどう解釈されたか結果を見るまで分からず、確認に時間がかかった。
• プロンプト内の「例：〜」の扱い。 HP課題で「例：原宿のスイーツ店」と書いたら、それを“作ってほしい題材”と受け取られかけた。選択肢で「別の題材を指定」を選んでも、肝心の中身（自分の職業＝損害保険）を書き忘れていて、もう一往復必要だった。→ 例と本命の区別は明示しないと伝わらない。
• 「PNGで出して」と指定したのに、実際はSVG＋αで返ってきた。 ツール側の都合で、指定した拡張子そのままにはならない場合がある。動くものは出るが、「ファイル形式の完全一致」までは過度に期待しない方がいい。

分かりにくかった言葉

• `STORE_KEY昇格`：最初は意味不明だったが、実際は「保存データの旧バージョンを新形式へ自動移行する」こと、と後で理解。専門用語の略記は、初回だけでも1行で意味を添えると安心。
• `承認段階ゲート引継型` / `A2A` / `3層振分`：勢いで書いた造語・略語も、Claudeは汲み取って形にしてくれるが、自分が後で読み返すと意味を忘れる。未来の自分のためにも言葉は開いた方がいい。

逆にスムーズだった所

• ざっくり＆勢いのある指示（「凄い！と思う業務効率化ツールにして」「急ぎで！」）ほど、いい感じに解釈して仕上げてくれた。 完璧な仕様書より、方向性＋温度感を伝える方が体験が良かった。
• 「完成したらブラウザでOpen」まで書いておくと、生成→起動まで一気にやってくれて確認が速い。
• 3ステップ指定（DESIGN.md→美学適用→実装）が有効。 工程を区切ると成果物が構造化され、後から手を入れやすかった。
• 選択肢で聞き返してくれるので、迷ったら曖昧なまま投げても軌道修正が効いた。

③ 最初のコピペ用プロンプトへの改善案

改善1：略語には初回だけ「凡例」を付ける

略記は残してOK。ただし先頭に1〜2行の対訳を置くと、解釈のブレと確認時間が激減する。

> 例）`STORE_KEY昇格=旧データを新形式へ自動移行 / 3層振分=100点をA(70+)/B/Cに自動分類 / A2A=必要ならサブエージェント並列`

改善2：「例」と「本命の題材」をラベルで分ける

「例：〜」だけだと本命と誤読される。テンプレを分離する。

> 【作りたい対象（本命）】：◯◯◯ ←ここを必ず埋める

> 【参考イメージ（例なので作らないで）】：△△△

改善3：最初に「前提1行」を必ず入れる

自分の立場・用途を冒頭に置くと、題材の往復が消える。

> 例）「私は損害保険の募集人です。自分の集客用サイトを作りたい」

改善4：出力形式は「第1希望＋代替可」で書く

拡張子を固定指定すると外れることがあるので、逃げ道を用意する。

> 例）「図はPNG希望。難しければSVGやHTMLでも可。要は“ブラウザで見られる図”があればOK」

改善5：温度感ワードは残す／仕様は箇条書きで下に

「凄い！」「急ぎで！」等の方向性ワードは効くので残し、確定仕様は箇条書きで分離すると、勢いと精度を両立できる。

改善6：完了条件を明記

「完成したらブラウザでOpen」「6000字以内でコピペ用テキスト」等、“終わり方”を書くと手戻りが減る。

• --

次にやる人へ： 完璧な指示を目指すより、①自分の前提を1行 ②やりたいことの温度感 ③終わり方（形式・確認方法）の3点さえ押さえれば、あとは走りながら選択肢で直せます。略語は使ってOK、ただし「例」と「本命」だけは絶対に混ぜないこと。

• --

（全体約2,900字。①②③そのままコピペ可）

必要なら、もっと短い要約版や、社内共有用に「良かった点/改善点」だけの箇条書き版にも整えます。

以下、そのままコピペしてお使いください。

――――――――――――――――――――

【フィードバック】Claude Codeをはじめる（課題1-1〜1-4）をやってみて

――――――――――――――――――――

■ ① やった課題（実際に作ったもの）

• 課題1-1：HTMLだけで動くオリジナルのシューティングゲーム

　→ 単一HTMLファイルで完成。パーティクル・コンボ・ボス戦・パワーアップまで入り、ブラウザで即プレイできた。

• 課題1-2：毎日占いのホームページ（フロント側）

　→ まず DESIGN.md（設計書）を作らせ、次に「白ベース・文字大きめ」の美学ルールを適用し、セクション単位で実装。誕生日から計算するバイオリズムなど“それっぽさ”のある画面になった。

• 課題1-3：その裏側システム（運用管理コンソール）

　→ 5タブ／100点採点＋3層振り分け／承認ワークフロー／localStorage保存 の業務ツールを単一HTMLで生成。サービス連携なしの「イメージ確認用モック」として成立。

• 課題1-4：この振り返り（次の人向けフィードバックづくり）

　→ 今まさに書いているこれ。作ったものを言語化する工程まで含めて1セット、という設計だと理解した。

ポイントは「1回で完璧」を狙うより、設計→実装→裏側→振り返り、と段階を踏ませると精度が上がること。

■ ② 想定外だったこと

＜詰まった所＞

• PNG（図解画像）を作らせたとき、日本語が文字化けした。原因はWindows標準のPowerShellが日本語ファイルを別の文字コードで読んでしまうこと。Claude側が自分で気づいて直したが、「画像に日本語を入れたい」時はこれが起きやすいと知っておくと安心。
• 絵文字は画像化すると豆腐（□）になりやすい。画面（HTML）ではOKだが、画像に焼く時はテキスト表記が無難。

＜分かりにくかった言葉＞

• 最初のプロンプトが記号の羅列で、正直これが一番の壁。例：

　「rev=cr+sr」→ レビュー＝コードレビュー＋セキュリティレビュー

　「A2A」→ エージェント同士の連携（サブエージェント起動）

　「ckpt」→ チェックポイント、「FO」→ ファンアウト（並列展開）、「Mem」→ 記憶、「Flow」→ 処理の流れ

　意味は通じたが、初見の人は何を頼んでいるか分からない。用語の“正体”を先に知っておくと世界が変わる。

• 「level3」「中規模」などの規模感の指定は、人によって基準がバラバラ。曖昧なまま渡すと解釈が揺れる。

＜逆にスムーズだった所＞

• 「完成したらブラウザで開いて」がきちんと効く。作って終わりでなく、その場で結果を目視できるのが快適。
• 「サービス連携はせず、まずイメージを見たい」「モックでOK」と最初に言い切ると、認証やAPIで止まらず一気に形になる。急ぎの時ほど効く。
• 「“凄い！”と思える業務効率化ツールにして」のような“熱量の指定”は意外と効く。抽象的でもアウトプットの本気度が上がった。
• DESIGN.md（設計書）を先に作らせる指示は満足度が高い。認識合わせができ、実装のブレが減る。

■ ③ 最初のコピペ用プロンプトへの改善案

現状の課題：記号が多すぎて“何を頼んでいるか”が読めない／規模やゴールが曖昧。

おすすめは「①ゴール ②作るもの ③制約 ④完成条件」を素直な日本語で分けること。以下、そのまま使えるテンプレです。

――― 改善版テンプレ（コピペ可）―――

【ゴール】○○を作りたい（誰の・何のため：例＝自分用の毎日占いサイト）

【作るもの】単一HTMLファイル（依存なし・ローカルで開ける形）

【制約】

• 外部サービス連携やログインは無し。まずは“見た目とイメージ”優先のモックでOK
• デザイン：白ベース／文字大きめ／日本語
• データ保存が要るならブラウザのlocalStorageで

【進め方】

• 先に設計メモ（DESIGN.md）を作って方針を見せてから実装して
• 作業のあと「何を・なぜそうしたか」を一言ずつ報告して

【完成条件】

• できたらブラウザで開いて、動くところまで見せて
• 不明点があれば勝手に決めず、1個だけ質問して

――――――――――――――――

＜さらに良くするコツ＞

• 「急ぎ」なら“凝った連携”より“動くモック優先”と明記する。速さと完成度の綱引きで、どちらを取るか先に伝えると迷わせない。
• 「中規模」等の曖昧語は避け、「1ファイルで」「5画面くらい」「サンプルデータ10件」のように数字で言うと再現性が上がる。
• 記号スタイル（CC(...)方式）は慣れた人向けの“時短用”。初めての人は上の素直版から入り、慣れてから記号に移行するのが結果的に速い。
• 画像（図解PNG）が欲しい時は「日本語・絵文字なしで」と一言添えると文字化けを避けられる。

＜次にやる人へ一言＞

最初のプロンプトの暗号っぽさに構えなくて大丈夫。中身は「ゴール・作るもの・制約・完成条件」を並べているだけ。そこさえ自分の言葉で言えれば、あとはブラウザで動くものが出てきます。まずは1ファイルの小さなモックから、気軽にどうぞ。

――――――――――――――――――――

（約2,600字）必要なら、もっとカジュアルな口調版や、社内共有向けの箇条書きだけの短縮版も出せます。

━━━━━━━━━━━━━━━━━━━━━━━━

Claude Codeをはじめる（課題1-1〜1-4）やってみた感想

次にやる人へのフィードバック

━━━━━━━━━━━━━━━━━━━━━━━━

■ ①やった課題（実際の流れ）

課題1-1：HTMLでオリジナルのシューティングゲームを作成 → ブラウザで表示

単一HTMLファイルにCanvas・敵・ボス・パーティクル・スコアまで一気に生成された。

課題1-2：ホームページのデザイン

「DESIGN.md作成 → Claude Cookbookの美学プロンプト適用 → セクション単位で実装（白ベース・文字大きめ）」という手順を指定。

題材はテンプレの例（原宿のバズりスイーツ店）をそのまま採用して進行。

課題1-3：作ったHPの「裏側のシステム」を作成

仕様駆動MVP（Level3）として、5タブ・スコアリング・承認フロー・在庫・SNS分析の管理コンソールを生成。構成図PNGと動くHTMLの2点が出力された。

課題1-4：この振り返り（本フィードバック）をテキストで作成。

ポイントは「ブラウザで開いて“動くもの”を確認できる」こと。コードを読めなくても成果が目に見えるので達成感が大きい。

■ ②想定外だったこと

【詰まった所】

日本語＋PowerShellの文字化け

画像（PNG）を生成する処理で、日本語や絵文字を含むスクリプトが一度エラーになった。原因は文字コード（BOM無しUTF-8をWindows PowerShellが誤読）。AI側が自動でリカバリしたが、Windowsで日本語を扱うと最初の1回はコケやすいと知っておくと安心。

「先ほど作った〇〇の裏側」という指示の前提

前の課題の成果物（DESIGN.mdやindex.html）が残っている前提で進む。ファイルを消していたり別フォルダで作業していると話が噛み合わない。課題は“同じ場所で連続してやる”のが吉。

既存ファイルの上書き

DESIGN.mdが既にあると「上書きしていいのか」で一瞬止まる。ファイル名がかぶると意図せず上書き／競合しやすい。

【分かりにくかった言葉】

最初のコピペ用プロンプトに略語・専門用語が多く、初見だと解読が必要だった。特に：

「CC(goal/Mon/batch/Plan/Hook/Rule/Skill/Flow/allow/…/rev=cr+sr/Ultra)」…能力の羅列だが説明なしだと呪文に見える

「3層振分」「100点」…点数化して3段階に振り分ける、の意

「承認段階ゲート引継型」…承認を段階で進め、次の担当へ引き継ぐ、の意

「STORE_KEY昇格」…保存キーのバージョンを上げて旧データを移行、の意

「A2A」「FO（ファンアウト）」「🤖pt」「モーダル(confirm禁止)」…それぞれ意味は通るが、初心者は前提知識が要る

「[ホームページで作りたい内容 例：…]」…角カッコが“記入欄”なのか“このまま使う例”なのか迷う（実際は未記入のまま例が採用された）

【逆にスムーズだった所】

単一HTML＋localStorageなので、ビルドやサーバー不要。ダブルクリックで即動く。

「完成したらブラウザで開いて」で最後に自動で開くのが気持ちいい。

白ベース・文字大きめ等、見た目の指定はほぼ一発で反映。

図解PNGと動くアプリを両方出す、のような複数成果物もまとめて出せた。

仕様（DESIGN.md）→実装、の順を指定すると設計が言語化されて手戻りが少ない。

■ ③最初のコピペ用プロンプトへの改善案

角カッコは「必ず自分の言葉で埋める」と明記する

例：「［　］は例です。必ず自分の作りたい内容に置き換えてから送信してください（未記入だと例のまま進みます）」の一文を先頭に入れる。

略語には1行の凡例を付ける

プロンプト末尾に「用語メモ：3層振分＝点数で3段階に分類／承認ゲート＝段階承認＋引継ぎ／STORE_KEY昇格＝保存データのバージョン移行／モーダル＝画面内ポップアップ（ブラウザ標準の確認窓は使わない）」のように添える。初心者の解読コストが激減する。

出力ファイル名を指定する

「ファイル名は ○○.html とし、既存ファイルは上書きしないこと」を入れておくと、上書き事故と“どれが最新か迷子”を防げる。

環境を1行で伝える

「Windows / 日本語 / PowerShell環境です」と最初に書くと、文字化け対策（UTF-8 BOM等）を最初から織り込んでくれて詰まりが減る。

「前の課題の続き」は成果物を明示する

「先ほど作った」ではなく「同フォルダの index.html / DESIGN.md を前提に」と具体名で指定すると齟齬が起きない。

完成条件を先に言い切る

「完成の定義：ブラウザで開いて〇〇が動く／エラーが出ない」を先に書くと、AIが自己チェックして仕上げてくれる。

呪文プロンプトは“任意”と明記

「CC(...)」のような密度の高い指定は上級者向け。初心者版は「①作りたいもの ②見た目 ③完成したらブラウザで開く」の3点だけでも十分良い成果が出る、と案内すると心理的ハードルが下がる。

■ まとめ（次にやる人へ一言）

コードが読めなくても「作りたいもの＋見た目＋“ブラウザで開いて”」の3点を書けば、動く成果物が返ってくる。最初の壁は“言葉”と“Windowsの文字化け”だけ。角カッコを埋め、環境を伝え、ファイル名を指定する——この3つを足すだけで、体験は一気に滑らかになります。

━━━━━━━━━━━━━━━━━━━━━━━━

「Claude Codeをはじめる（課題1-1〜1-4）」やってみたフィードバック

■ ① やった課題と成果物

• 課題1-1：Claude Codeのセットアップ〜起動

　インストールと初回起動、フォルダ（デスクトップに「ユニコスクール」）を作って開始。

• 課題1-2：コピペ用プロンプトでシューティングゲーム作成

　「HTMLで超作り込んだオリジナリティのあるシューティングゲームを作って下さい！完成したらブラウザでサイトOpen」を貼るだけで、単一HTMLのネオン風シューティング（prism-surge.html）が完成。スコア・体力ゲージ・HUDまで入った本格的なものが1発で出てきた。

• 課題1-3：デザイン仕様書→ホームページ作成

　「1:DESIGN.md作成 2:Claude Cookbookの美学プロンプトを適用 3:セクション単位に実行（白ベース・文字大きめ）」の流れで、架空のスイーツ店「NEON PARLOR」のLPを作成。先にDESIGN.md（カラーパレット、フォント、セクション構成S0〜S7まで書かれた仕様書）ができて、それに沿ってindex.htmlが実装された。

• 課題1-4：作ったホームページの「裏側のシステム」作成

　「先ほど作ったホームページの裏側のシステムを作って下さい」で、店舗運営バックオフィス（neon-ops.html）と構成図PNG（neon-ops-architecture.png）が完成。前の課題で作った店の設定（店名・カラー）を引き継いで作ってくれた。

　→ 課題1-2〜1-4は3セッション、体感30〜40分程度で計5ファイル完成。

■ ② 想定外だったこと

【スムーズだった所】

• プロンプト1個で「動くもの」が最後まで出てくる。コードを1行も書いていないし、途中で直しの指示もほぼ不要だった。
• 「完成したらブラウザでOpen」まで書いておくと、本当にブラウザで開いて見せてくれる。動作確認の手間がない。
• 課題1-4で「先ほど作ったホームページの」と言うだけで、前の課題のDESIGN.mdやindex.htmlを勝手に読んで文脈を引き継いでくれた。フォルダの中を自分で見てくれるのがCLIツールの強みだと実感。
• DESIGN.mdを先に作らせる流れ（課題1-3）は特に良かった。いきなり作らせるより仕上がりの方向性が揃うし、「仕様書→実装」という実務に近い流れが体験できる。

【詰まった所・分かりにくかった所】

• コピペ用プロンプト内の略語が読めない。「仕様駆動MVP=level3」「out:図解PNG」「batch/Flow FO→待Mon・危険前ckpt→rev+A2A」など、貼れば動くが自分では意味が分からないまま進む。「おまじない」で終わってしまい、応用が利かない。次にやる人向けに用語の注釈が1行ずつ欲しい。
• プロンプト内の [ホームページで作りたい内容 例：原宿の…] のような角括弧部分が、「例をそのまま使っていいのか」「自分で書き換える場所なのか」一瞬迷う。「ここは自由に書き換えてOK（そのままでも動く）」と明記してほしい。
• 作業中、ファイル作成やコマンド実行のたびに許可を求められる場面があり、初見だと「Yesを押していいのか」不安になる。「基本Yesで進めてよい／こういう時だけ注意」という一言が課題文にあると安心。
• 作業フォルダをOneDrive配下のデスクトップに作ったため、パスに日本語＋スペースが入る。今回は問題なかったが、環境によってはトラブルの元になりそうなので「Cドライブ直下などシンプルな場所推奨」と案内があるとよい。
• 成果物のファイル名（prism-surge.html等）はClaude任せになるので、どれが何の課題の成果物か後から分かりにくい。

■ ③ 最初のコピペ用プロンプトへの具体的な改善案

現行：

「HTMLで超作り込んだオリジナリティのあるシューティングゲームを作って下さい！完成したらブラウザでサイトOpen」

これでも十分動くが、次の3点を足すとつまずきが減り、学びも増える。

ファイル名を指定する

　→ 成果物がどれか一目で分かり、課題ごとの整理がしやすい。

「作り込んだ」の中身を条件で示す

　→ 曖昧語に頼らず、条件で品質をコントロールする感覚が最初から身につく。

完成後に「操作説明」と「改造ポイント」を言わせる

　→ 遊び方が分かるし、「どこを変えると何が変わるか」を聞くことでプロンプト2発目（改造依頼）に自然につながる。

改善版の例：

「game.html という名前で、HTML1ファイルだけで動くシューティングゲームを作ってください。条件：キーボード（矢印キー＋スペース）で操作／スコアと残機を表示／敵は複数種類／日本語のタイトル画面つき／外部ライブラリ不使用。完成したらブラウザで開いて、操作方法と、難易度を変えたいときに直す場所を教えてください。」

さらに課題文側に「うまく動いたら『敵の種類を増やして』『BGMをつけて』など一言で改造を頼んでみよう」と追記すると、"AIと往復しながら育てる"というClaude Codeの本来の使い方まで1課題で体験できる。

以上

Claude Code をはじめる（課題1-1〜1-4）体験フィードバック

① やってみた課題

課題1-1｜準備（インストール＆課金）：環境構築と初期設定。

課題1-2｜ゲーム作成：プロンプト1行からシューティングゲームを生成。

課題1-3｜ホームページ：デザイン付きのサイトを生成（＋自分でアレンジも挑戦）。

課題1-4｜業務効率化ツール：ホームページの「裏側」にあたる管理システムのモックを生成。

いずれも「1行送る→動くものが返ってくる」を4回体験でき、"AIに頼めば本当に動く"という感覚が手元に残りました。

② 想定外だったこと

詰まった／最初わからなかった所

課金は済ませていたものの、「そもそもターミナルやVS Codeが必要なのか」「どうやってフォルダを指定して作業を始めるのか」がイメージできていませんでした。 ここが最初の一番の不安ポイントでした。ただ、手を動かしながら「作業する場所（フォルダ）を決めて、そこにClaude Codeが書き込んでいく」という流れを実際の操作を通して理解でき、"やりながら学べた"のがむしろ良かったです。読むだけでは腑に落ちなかったと思います。

スムーズだった所／可能性を感じた所

課題1-3では、説明を聞きながらコピペ用プロンプトを使い、別のデザインにも自分でトライしてみました。コピペプロンプトに加えて、(1)下敷きにしたい参照サイトの条件、(2)作りたいサイト名、(3)「Awwwardsクラスのサイトにしたい」という到達点の具体例、(4)「訪問者に立体的な体験を届けたい」という狙いを指定し直したところ、平面的なページから脱却し、動きのある＝VRにも対応できそうなサイトを作り始めました。「なんでもできるんだな」と可能性を強く感じた瞬間でした。

同時に、「こんなデザインなら、もっと面白いかも」という新しい想像が次々に広がる結果にもなりました。これはAIと一緒に作業する醍醐味で、一瞬で"想像していなかった次元"を見せてくれる感覚です。

一方で週の利用上限に届きそうだったので、進め方としてはまず案内どおり1-1〜1-4を最後までやり切り、余力があれば別の指示を試すのがおすすめだと感じました（最初からアレンジに全力投球すると上限を使い切りやすい）。

課題1-4は、ホームページの内容が具体的であれば、そのまま管理システムとして機能しうるという手応えがありました。逆に、まだ中身が決まっていない"イメージだけのサイト"にこの作業をさせると、「実務ではこういう項目が必要になるのか」と逆算で気づける——企画の解像度を上げる使い方もできると分かりました。

全体を通して

スクールに入れば、こうした的確な文言（プロンプトの型）をたくさん知れて、学びたいことをピンポイントで深められるのだろうと感じ、やはり参加したくなりました。

③ 最初のコピペ用プロンプトへの改善案

A. プロンプトの前に「30秒の前提説明」を1枚挟む

最初の不安は"作る内容"より"どこで・どう始めるか"でした。プロンプト提示の直前に、次の3点を図か短文で置くと離脱が減ります。

「Claude Codeはフォルダ（作業場所）に対してファイルを作ります」

「まずデスクトップ等に空フォルダを1つ作り、そこを指定して始めます」

「ターミナル/VS Codeは"入り口"。難しい操作は不要、プロンプトを送るだけ」

B. コピペプロンプトを「穴埋め式テンプレート」にする

今の1行に、任意で条件を足せる空欄付きの型を併記すると、1-3で私がやった"アレンジ"を全員が安全に再現できます。

（基本）◯◯を作ってください。完成したらブラウザで開いてください。

（任意で追記できる欄）

• サイト名：〔　　　〕
• 参考にしたい雰囲気／参照サイト：〔　　　〕
• 目指すレベル：〔例：Awwwards級のリッチな表現〕
• 届けたい体験：〔例：訪問者に立体的・没入感のある体験〕

C. 「上限に注意」の一言を最初に添える

「まずは1-1〜1-4を一周してから、アレンジは余力で」という順序の推奨と、週の利用上限に触れる一文があると、私のように途中でアレンジに熱中して上限が心配になる人の助けになります。

D. 「詰まってもOK」の安心材料を明記

「今この場で終わらなくてOK／あとで同じフォルダから再開できる」ことを、つまずきやすい1-1の近くにも再掲すると安心して進めます。

E. 1-4に"逆算の使い方"を1行ヒントとして追加

「中身が固まっていないサイトでも実行してみると、実務で必要な項目に気づけます」と添えると、1-4の価値（モック作成だけでなく企画の棚卸しにも使える点）が伝わりやすくなります。

以上です。次にやる方には、「最初の壁は"作る内容"ではなく"始め方"。そこさえ越えれば、あとは想像が追いつかないほど広がる」という点が伝わるとよいと思います。

以下、そのままコピペできるテキストです（約2,900字）。

• --

【Claude Codeをはじめる（課題1-1〜1-4）やってみた感想・次にやる人へのフィードバック】

■ ①やった課題

• 課題1-1：HTMLでオリジナルのシューティングゲームを作成し、ブラウザで表示。
• 課題1-2：ホームページのデザイン。「DESIGN.md作成 → Claude Cookbookの美学プロンプト適用 → セクション単位で実装」という流れで、白ベース・文字大きめのLP（AI×WEB導線設計）を制作。
• 課題1-3：そのLPの「裏側システム」を仕様駆動で作成。5タブ・100点スコアリング・3層振り分け・承認ゲート付きパイプラインなどを盛り込んだ管理ツールのモックを単一HTMLで作成。
• 課題1-4：この振り返り（次の人向けフィードバック）をテキストでまとめる。

全体として「作りたいもの」を日本語で投げるだけで、動くHTMLとブラウザ表示まで一気に出てくるのが体験の中心でした。

■ ②想定外だったこと

＜スムーズだった所＞

• 「作って」→「ブラウザで開いて」まで一往復で完結する。ファイル作成・保存・起動を自分で操作しなくていいのが想像以上に楽。
• 「白ベース・文字大きめ」程度のざっくり指定でも、ちゃんと意図を汲んでトーンを揃えてくれた。
• 課題1-2で先に DESIGN.md を作らせてから実装させる流れは、いきなり作らせるより仕上がりが安定していた。設計書を挟むのは効果あり。

＜詰まった所・分かりにくかった言葉＞

• いちばん詰まったのはプロンプトの「省略記号」。課題1-3で使った `CC(goal/Mon/batch/Plan/…)` のような超圧縮した指示は、書いた本人以外には意味が読み取りづらい。専門用語＋略語が多く、次の人がそのまま真似すると「何を指示しているのか分からない」状態になりやすい。
• 「A2A」「STORE_KEY昇格」「承認段階ゲート引継型」など、業界・ツール固有の言葉がそのまま並ぶと、初学者は手が止まる。意味を知らなくても結果は出るが、"自分が何を頼んだか"を理解できないまま進むことになる。
• テンプレの穴埋め `[ホームページで作りたい内容 例：AI×WEB導線設計]` を、例文のまま送ってしまいがち。ここは「自分の言葉で埋める場所」だと気づきにくかった（実際いったん確認が入った）。
• 「図解PNG」を求めても、環境によっては画像変換ツールが無く、PNGは"ワンクリックで保存するHTML"という形での提供になった。出力形式は環境依存で変わり得る、という前提を持っておくと戸惑わない。
• 「凄いと思える業務効率化ツールにして」のような感覚的な要望は、伝わるが人によって基準が違う。もう少し具体があると期待値のズレが減る。

■ ③最初のコピペ用プロンプトへの具体的な改善案

次の人がコピペして使うなら、圧縮記号を減らして「目的・成果物・制約」を素直な日本語で書く形をおすすめします。改善版テンプレの例：

• -------…

【作りたいもの】

（例：整体院の集客ホームページ／社内の勤怠管理ツール　など、具体的に）

【ゴール】

このページ／ツールで来訪者に何をしてほしいか

（例：無料相談を予約してもらう）

【出力の形】

• 単一のHTMLファイル1つ（外部サービス連携なしのモックでOK）
• 完成したらブラウザで開いて

【デザイン・制約】

• 白ベース、文字は大きめ
• 日本語表示
• データ保存はブラウザ内（localStorage）で完結

【入れたい機能があれば】

（例：一覧表示／スコア表示／入力フォーム　など。無ければ「おまかせ」でOK）

• -------…

ポイントは3つ：

1. 略語・専門用語を使わない。「A2A」「ゲート引継型」等はいったん日本語で説明するか、思い切って省く。指定しなくても十分いい感じに作ってくれるので、盛り込みすぎない方が失敗しない。

2. 穴埋めの「例：〜」は必ず自分の言葉に置き換える。例文のまま送らない。埋め忘れると一度確認のやり取りが発生してテンポが落ちる。

3. 最初は要素を欲張らない。1回で完璧を狙わず「まず作ってもらう→見て→"ここをこう変えて"と追加指示」の反復が結果的に速い。Claude Codeは修正指示に強いので、初回はざっくりでよい。

補足：出力形式（PNG等）は環境に左右されることがあるので、「無理なら代替案でOK」と一言添えると止まらずに進みます。

まとめると、Claude Code自体は「日本語で普通に頼めば動くものが返ってくる」ので難しくない。つまずくのはツールではなく"指示の書き方"の方。次の人は、かっこいい省略記法を真似るより、やりたいことを普通の言葉で正直に書くのが一番の近道です。

• --

必要なら、この文章をもっと砕けた口調にしたり、逆に報告書向けの硬い文体に整えたりもできます。

========…

Claude Codeをはじめる（課題1-1〜1-4）やってみた感想

― 次にやる人へのフィードバック ―

========…

■① やった課題（実際にやったこと）

• 1-1: オリジナルのシューティングゲームをHTMLで作成
• 1-2: 介護施設向けECサイト（配送型・衣料/タオル販売）のトップページ作成

→ DESIGN.mdを先に作り、白ベース・文字大きめで実装

• 1-3: そのECの「裏側システム」＝受注管理画面を作成

→ 5タブ・スコアリング・承認フローつきの管理コンソール

• 1-4: 一連の作業の振り返り（＝このフィードバック）

共通して「1つのHTMLファイルで動く」「完成したらブラウザで開く」

という形式。段々と作るものが本格的（業務ツール寄り）になっていく流れ。

• -------…

■② 想定外だったこと

【詰まった所】

• ブラウザの自動チェック（Claude in Chrome拡張）が接続できず、

「クリックして動作確認」まではやってもらえなかった。

→ 結局は既定ブラウザで手動オープンして目視確認する形に。

→ 次の人は「自動で動作確認まで頼む」前提にしすぎない方がよい。

• Windowsの日本語まわりで一度エラーが出た（PNG図解の生成時）。

文字コードの問題で、内部的に作り直して解決していたが、

Windows＋日本語だとこの手の詰まりが起こり得ると知っておくと安心。

• 作ったファイルが「どこに保存されたか」を確認する必要があった。

デスクトップの奥のフォルダに入るので、フルパスを聞くのが吉。

【分かりにくかった言葉・指示】

• 課題のプロンプトに独自の省略記法が多くて、初見だと意味が読めない。

例）「level3」「3層振分」「承認段階ゲート引継型」「STORE_KEY昇格」

「A2A」「pt」「confirm禁止」「FO」「rev=cr+sr」など。

→ 何となく雰囲気で伝わって成果物は出るが、

「自分が何を頼んだのか」を後で説明できないのが不安だった。

• 「凄い！と思うような業務効率化ツールにして」のような

主観的なゴールは、AIがどう解釈するか読めない。

（結果は良かったが、狙い通りかは運まかせに近い）

【逆にスムーズだった所】

• 「HTMLで◯◯を作って、完成したらブラウザで開いて」は

ほぼ一発で意図通りに動くものが出てくる。ここは気持ちいい。

• 「白ベース」「文字大きめ」「遅い端末でもサクサク」など、

“見た目・体感”の条件は素直に反映される。

• 設計書（DESIGN.md / SPEC.md）を先に作らせると、

何を作るつもりか事前に確認できて安心感があった。

• localStorageで保存されるので、開き直しても入力が残る。

デモとして見せるには十分。

• -------…

■③ 最初のコピペ用プロンプトへの改善案

改善の方向性は「専門用語を減らし、目的と具体例で伝える」こと。

▼ Before（つまずきやすい例）

仕様駆動MVP=level3。out:動くHTML単一・5tab・100点+3層振分・

承認段階ゲート引継型・モーダル(confirm禁止)・A2A→open

▼ After（次の人が真似しやすい形）

介護施設向けECの「受注管理画面」を作ってください。

• 1つのHTMLファイルで動く（保存や外部サービス連携はなし、デモ用）
• データはブラウザ内（localStorage）に保存
• 日本語・白ベース・文字は大きめ
• 画面は5つ：ダッシュボード / 注文一覧 / 承認フロー / 在庫 / 顧客
• 注文は「金額・緊急度・顧客ランク・納期」で100点満点で自動採点し、

点数で「最優先/標準/保留」の3つに自動で振り分けて表示

• 注文は「受付→承認→出荷→配送→完了」と段階を進められ、

各段階で担当者が次の人に引き継がれる形にする

• 確認ダイアログは画面内モーダルで（ブラウザ標準のconfirmは使わない）
• サンプルデータを10件くらい入れておく
• 完成したらブラウザで開いて、保存先のフルパスも教えて

【具体的な直しポイント】

(1) 略語・造語には必ず1行の説明を添える。

「3層振分」→「点数で3つのグループに自動仕分け」など。

(2) 「凄い」「良い感じ」など主観語は、

“誰が・何を・どう楽になるか”に置き換える。

例）「夜勤の職員が、どの注文から対応すべきか一目で分かる」

(3) 完成後の確認方法を先に指定する。

「ブラウザで開いて」「動作確認までは自分でやる」など、

自動チェックが使えない前提で書いておくと手戻りが少ない。

(4) 保存場所を最初に決めておく（例：デスクトップの◯◯フォルダ）。

後から「どこ？」と探さずに済む。

(5) 一度に全部盛らず、まず“動く最小版”を頼み、

後から機能を足す方が、途中の確認がしやすい。

• -------…

■ ひとことまとめ

「作って・見た目を整えて・ブラウザで開く」までは非常に速くて楽しい。

つまずくのは“言葉の解釈”と“動作確認の環境”の2点。

専門用語を日常語に開き、確認手順と保存先を先に決めておけば、

次の人はもっと迷わず進められるはず。

========…

① やった課題

• 1-1：Claude Code をインストールして課金する
• 1-2：はじめての開発：シューティングゲームを作る
• 1-3：ホームページを作る
• 1-4：業務効率化ツールを作る（HPの裏側）

② 想定外だったこと

＜詰まった所＞

• 1-2の出力が想像よりずっと本格的。頼んだのは「シューティング」だけなのに、RGBの色合わせ＋ボス＋効果音＋コンボまで入った約1000行のHTMLが一発で返ってきました。動いた瞬間は感動ですが、「弾の速さだけ変えたい」と思っても、自分ではどこを直せばいいか読めない。結局また会話で頼む、という状態になりました（悪くはないけど想定外）。

＜分かりにくかった言葉＞

• 「コンテキスト」「CLAUDE.md」「MCP」「エージェント」あたりが説明なしで出てきて、最初は雰囲気で流しました。
• 「プロンプト」＝ただの指示文、と腑に落ちるまで少しかかりました。
• diff・コミットなどGit前提の言い回し。触ったことがないと一瞬固まります。

＜逆にスムーズだった所＞

• インストール〜最初の応答までが速い。1個目の「動くもの」が出るまでが短く、達成感が早いです。
• 日本語で雑に頼んでも、ちゃんと動くものが返ってくる。かしこまった書き方は不要でした。
• エラーが出ても、そのエラー文をそのまま貼れば直してくれる。この試行錯誤ループが気持ちいい。
• コードが読めなくても「ここ直して」と会話するだけで前に進める。初心者でも手が止まりません。

③ 最初のコピペ用プロンプトへの改善案

いまの最初のプロンプトは「作って」に近く、短いぶん出力が巨大化しがち（1-2の1000行がまさにそれ）。次の一文を足すと、初心者でも中身を把握しながら進められます。

• 規模を指定：「まずは最小構成で。凝った機能は入れず、あとから足せる形で」
• 作る前に説明：「始める前に、これから何をするか3行で教えてから着手して」
• 技術と制約を固定：「1つのHTMLファイルだけ／外部ライブラリなし／スマホでも動く」
• 段階を指定：「一気に全部やらず、動く最小版→確認→追加、の順で」
• 保存先を明示：「ファイルは今のフォルダに保存し、保存先のパスを教えて」
• 許可の不安対策：「先に、これから使うコマンドやファイル操作を一覧で教えて」
• 用語対策：「専門用語が出たら、都度ひとことで説明して」

＜改善版・コピペ用プロンプト例＞

「シューティングゲームを作りたいです。いきなり完成品ではなく、まず動く最小版から始めてください。条件は、1つのHTMLファイルだけ・外部ライブラリなし・スマホでも動く、です。着手前に、これから作る内容を3行で説明してください。作ったら保存先のパスを教えて、次に足せる機能を2〜3個提案してください。専門用語が出たら一言で説明を添えてください。」

【Claude Codeをはじめる（課題1-1〜1-4）やってみた感想・次の人へのフィードバック】

■ ①やった課題

• 1-1：HTMLでオリジナルのシューティングゲーム制作（1ファイル完結、Canvas＋WebAudioで効果音まで自動生成）
• 1-2：スイーツ店のホームページ制作。「DESIGN.md作成 → Cookbookの美学プロンプト適用 → セクション単位で実装」の3ステップ、白ベース・文字大きめ指定
• 1-3：1-2の修正依頼。「色を緑ベースに」「メイン写真を変えて」を追加指示
• 1-4：そのHPの“裏側システム”を仕様駆動MVP(Level3)で制作。5タブの管理画面＋システム構成図PNG

■ ②想定外だったこと

＜詰まった所＞

• 【最重要】プロンプトの中に例のテンプレ「[ホームページで作りたい内容 例：…]」を消し忘れて送ってしまい、Claudeに「何のサイトか未確定」と質問し返された。→ 角カッコの部分は自分の言葉に必ず書き換えてから送るのが大事。
• 保存先が OneDrive フォルダだと、ファイル書き込みが一度「アクセス拒否」で失敗した（特に画像生成）。Claudeが自動で一時フォルダ経由に切り替えて解決してくれたが、可能ならデスクトップ直下など OneDrive 外の方がトラブルが少なそう。
• 図解PNGを作る工程で、環境のPythonが“中身のないスタブ”で動かず一瞬詰まった。Claudeが自動でブラウザ(Chrome)を使う方法に切り替えて生成できた。＝環境依存の失敗は起きうるが、代替案に自動で流れてくれる。

＜分かりにくかった言葉＞

• 1-4の呪文みたいな指定（例：「STORE_KEY昇格」「3層振分」「承認段階ゲート引継型」「confirm禁止」「A2A」「🤖pt」）。意味は結果を見れば分かったが、初見では何を頼んでいるか自分でも曖昧だった。用語は“略語”のままでも通じるが、通じた=自分の意図通りとは限らないので、仕上がりを必ず目視確認した方がいい。
• 「仕様駆動MVP=level3」のようなレベル表記は、人によって解釈が割れる。どこまで作り込むかは、言葉より「5タブ」「サンプル8件」など具体で指定した部分の方が正確に伝わった。

＜逆にスムーズだった所＞

• 「完成したらブラウザで開いて」と書くと、実際に開くところまでやってくれて確認が速い。
• 「白ベース・文字大きめ」のようなざっくり指定でも、ちゃんと反映された。細かい色コードを知らなくてもOK。
• 修正（1-3）が非常に楽。「緑に変えて」だけで全体を統一して直してくれた。作り直しではなく差分修正なので速い。
• 作業の最初に「何を選んでどう進めるか（選定・理由）」を要約報告してくれるので、丸投げでも中身が追える。

■ ③最初のコピペ用プロンプトへの改善案（次の人向け）

1. テンプレの角カッコは“提出前に必ず自分の言葉へ置換”を赤字級で注意書きする。

例：「※[ ]内は消して、あなたの作りたい内容を1行で書いてください（未記入だと質問で止まります）」

2. 保存先を最初に指定させる欄を追加。

例：「保存先：（OneDrive外を推奨。例 C:\Users\〇〇\Desktop\test）」

3. 専門用語・略語には1行の言い換えを添える。

例：「STORE_KEY昇格＝保存キーを1か所にまとめる／confirm禁止＝確認は自作の画面で／3層振分＝S・A・Bの3段階に自動仕分け」

→ 略語を残すなら“意図”を1行足すだけで、仕上がりのズレが激減する。

4. 完成条件（受け入れ基準）を最初に箇条書きで書かせる。

例：「完成チェック：□白ベース □文字大きめ □5タブ □スマホで崩れない」

→ これがあると、出来上がりの良し悪しを自分で判断しやすい。

5. 「まず要件を1回確認してから作って」の一文を入れる。

→ いきなり作り始めず、認識合わせを1往復入れると手戻りが減る（特に1-4のような複雑な依頼）。

6. 画像やPNGが必要な課題は、その旨を明記。

例：「図解はPNG画像でも出してほしい」→ 環境次第で生成方法が変わるので、先に伝えると早い。

■ まとめ（ひとこと）

ざっくり指示でもかなり作ってくれるので初心者でも“凄い物”が出せる。ただし精度は「角カッコを消す」「用語に一言そえる」「完成条件を書く」の3点で大きく変わる。迷ったら、かっこいい略語より“具体的な数と言葉”で頼むのが正解でした。

• --

文字数は約1,900字（6000字以内）です。必要なら、もっと短い要点版や、社内共有向けの丁寧口調版にも整えられます。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Claude Code をはじめる（課題1-1〜1-4）やってみた感想・次の人へのフィードバック

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■ ① やった課題（実際にできたこと）

• 課題1-1：HTMLでシューティングゲームを作成 → そのままブラウザで起動して遊べた。
• 課題1-2：それを「グラディウス風」に改修依頼 → 横スクロール＋パワーアップ制へ作り替え。一度だけ動かなくなったが、伝えたら直った。
• 課題1-3：司馬遼太郎『街道をゆく』の訪問地を日本地図で見せるホームページを作成。設計書（DESIGN.md）→デザイン方針→画面ごとの実装、という流れで進んだ。
• 課題1-4：そのサイトの「裏側の管理システム（CMS）」を作成。仕様を指定したら、構成図（PNG画像）と、動く管理画面（1ファイルのHTML）が両方出てきた。

ひとことで言うと「日本語でお願いするだけで、ファイル作成〜ブラウザ表示まで全部やってくれる」体験でした。

■ ② 想定外だったこと

【詰まった所】

• 作ってもらったゲームが「スタートを押しても始まらない」ことがあった。原因は生成されたコードの小さな文法ミス。
• 厄介なのは、エラーが画面に出ず“無言で止まる”こと。初見だと「自分の操作が悪いのか？」と迷う。

→ 対処はシンプルで、Claudeに「スタート押しても始まりません」と症状をそのまま伝えるだけで、原因を特定して直してくれた。自分でコードを読む必要はなかった。

→ 豆知識：ブラウザで F12（デベロッパーツール）→「Console」タブを見ると赤いエラーが出ている。原因の手がかりになるので、余裕があれば覗くと理解が深まる（必須ではない）。

【分かりにくかった言葉】

• 途中で使った圧縮記法のプロンプト（例：「CC(goal/Mon/batch/Plan/Hook/Rule/Skill/Flow/…/rev=cr+sr/Ultra)」や、「level3」「A2A」「STORE_KEY昇格」「cr+sr」「モーダル」など）は、初学者にはほぼ“呪文”に見える。
• 意味が分からなくても、Claude側が解釈して動いてはくれるが、「自分が何を頼んだのか分からないまま完成品が出てくる」感覚になり、少し不安。

→ 略語の意味（cr=コードレビュー、sr=セキュリティレビュー、A2A=エージェント連携 等）は、最初に一度だけ言葉で確認しておくと安心。

【逆にスムーズだった所】

• とにかく指示が自然文でよい。「〜な感じにして」「グラディウスっぽくして」でちゃんと伝わる。
• 修正依頼も強い。「ここ直して」「もっと大きく」で通じる。専門用語不要。
• 副産物（設計書、構成図の画像、サンプルデータ）まで勝手に用意してくれるので、成果物がリッチになる。
• 「完成したらブラウザで開いて」と書いておくと、本当にブラウザまで開いてくれる。確認が速い。

■ ③ 最初のコピペ用プロンプトへの改善案（次の人向け）

1. 「作りたい中身」は“例のまま”にせず、最初に具体で書く。

• 課題テンプレの角カッコ［例：〜〕をそのまま送ると、「これは例？本番？」と一往復確認が入り、その分遅くなる。
• 悪い例：［作りたい内容 例：〇〇のお店］をそのまま送信
• 良い例：「〇〇という架空のカフェの紹介サイトを作って。可愛い系・白基調で。」

2. 出力の形を1行で指定する。

• 「1つのHTMLファイルで」「保存先はこのフォルダ」「完成したらブラウザで開いて」を書くと、迷いなく進む。
• 不要なら「余計なファイルは作らないで」も有効。

3. 略語・圧縮記法は“初回は使わない”。使うなら凡例をつける。

• 初回は普通の日本語で十分。慣れてからテンプレ記法を使う。
• どうしても使うなら「※用語の意味も一言添えて」と書くと、置いてけぼりにならない。

4. 「動かなかったら症状をそのまま言えばOK」を心得として最初に共有。

• 直し方が分からなくても大丈夫。「◯◯が表示されない」「ボタンが効かない」で通じる。
• スクショや、F12→Consoleの赤い文字を貼るとさらに速い。

5. 環境を一言添える。

• 「Windows・Chromeで見ます」など。開き方や改行コードなど、地味に精度が上がる。

6. 大きな作業は「設計→実装」を分けて頼むと満足度が高い。

• 「まず設計方針だけ出して。OKしたら作って」と段階を踏むと、イメージ違いの手戻りが減る。

—— まとめ ——

初心者でも「日本語で頼む→ブラウザで確認→気になったら直してと言う」のループだけで、ゲームからWebサイトやCMSまで作れる。つまずくのはたいてい“生成コードの小さなバグ”で、症状を伝えれば直るので身構えなくてよい。最初のプロンプトで「具体的な中身・出力形式・ブラウザで開く」の3点さえ書けば、体験は一気にスムーズになります。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

（全体で約2,900字。①②③すべて収録・そのままドキュメントや共有チャットに貼り付け可能です。）

以下、そのままコピペで使えるテキストです。

• --

【Claude Code をはじめる｜課題1-1〜1-4 やってみた感想（次にやる人へ）】

■ ① やった課題

• 1-1：HTMLだけで「超作り込んだオリジナルのシューティングゲーム」を作り、完成後ブラウザで自動オープン。
• 1-2：HP（Webサイト）デザイン。DESIGN.md（設計書）を先に作る → 「Claude Cookbookの美学プロンプト」を適用 → セクション単位で実装、という流れ。テーマは「佐賀市で子連れで行ける飲食店」。白ベース・文字大きめ指定。
• 1-3：1-2で作ったHPの“裏側の運営システム”を、仕様駆動MVP（レベル3）として構築。5タブ／100点採点＋3層振り分け／承認ワークフロー／モーダル／localStorage保存の管理画面モック。
• 1-4：この振り返り（フィードバックのテキスト化）。

ざっくり言うと「①ゲーム → ②見せるHP → ③その裏側の業務システム → ④振り返り」と、単発の生成から“作り込み”へ段階的に難度が上がる構成でした。

■ ② 想定外だったこと

＜スムーズで感動した所＞

• 完成すると勝手にブラウザで開いてくれる／プレビューパネルにも即表示。「動くものがすぐ見える」ので達成感が大きい。
• 「セクション単位で実行」と頼むと、Hero→特徴→一覧…と小分けに進み、途中経過が見えて安心。
• 進捗がTodoリストで可視化され、今どこをやっているか分かる。
• ざっくりした一言（「子連れ飲食店の裏側システム」等）でも、採点ロジックや承認フローまで“それっぽく動くモック”に仕上げてくれた。指示が荒くても形になる。

＜詰まった・分かりにくかった所＞

• 一番のつまずきは「最初のコピペ用プロンプト」。`CC(goal/Mon/batch/Plan/Hook/Rule/…rev=cr+sr/Ultra)最適選択→batch/Flow FO→…A2A→…` のような記号と略語の羅列で、正直、意味がまったく読めませんでした。何を頼んでいるのか自分でも把握できないまま送る感覚。
• 専門用語・略語が多い。例：「A2A」「STORE_KEY昇格」「承認段階ゲート引継型」「仕様駆動MVP=level3」「Cookbook美学プロンプト」。それぞれ何を指すのか説明がなく、初回は雰囲気で送っていました。
• 「auto mode（自動で進むモード）」のON/OFFが分かりづらい。途中で「ストップして」と言ったら止まったが、“何かエラー？”と不安に。実際はエラーではなく、指示通り止まっただけ。モードの状態が見えにくい。
• 「どれくらい時間がかかる？」と聞いても明確な分数は出ない（AIは時間見積もりを避ける方針）。待ち時間の目安が欲しい人には肩透かし。
• 生成物が想定より“豪華”で、逆にどこを見ればいいか迷う瞬間があった。最初に「まずは最小構成で」と言えばよかった。

■ ③ 最初のコピペ用プロンプトへの改善案

現状の「記号＋略語の呪文」は、慣れた人向けの時短用としては強力ですが、はじめての人には壁になります。次の人向けに、こう直すと親切だと思いました。

(A) 呪文の“翻訳”を1行添える

　例：先頭の制御プロンプトの下に、日本語で

　「＝最適な進め方を自分で選び、まとめて実行。危険な操作の前は確認。完了後に『やったこと・理由・結果』を要約報告して、という意味」

　と注釈を入れる。何を頼んでいるか本人が分かる状態にする。

(B) 略語に初出の説明をつける

• A2A →「複数のAIエージェントに分担させる方式（規模が小さい時は使わない）」
• STORE_KEY昇格 →「保存データのバージョンを新形式へ自動変換」
• 承認段階ゲート引継型 →「申請→一次確認→審査→承認、と段階を進めるたび担当者が引き継がれる仕組み」
• 仕様駆動MVP(level3) →「まず仕様書を書いてから、動く試作品を作る。level3＝そこそこ作り込む」

(C) 「最小→拡張」を選べるようにする

　プロンプト末尾に一言、

　「※まずは最小構成で。OKなら盛る」または「※最初からフル装備で」

　を選択できるようにすると、豪華すぎて迷う問題が減る。

(D) 完成の定義（ゴール）を先頭に固定文で置く

　例：「【ゴール】○○を作り、白ベース・文字大きめ・単一HTML・完成したらブラウザで開く」

　この“お決まり条件”をテンプレ化しておくと、指示のブレが減って再現性が上がる。

(E) モードと停止の案内を1行

　「途中で止めたい時は『ストップして』でOK（エラーではありません）」

　と添えるだけで、初回の不安がなくなる。

■ まとめ（次にやる人へ）

• 怖がらず、ざっくりした一言で投げてOK。ちゃんと動くものが返ってきます。
• ただし最初のコピペ呪文の“意味”だけは、送る前に日本語で1回かみ砕いておくと、自分の理解が段違いに深まります。
• 「まずは最小で」「白ベース・文字大きめ」など“最終イメージ”を一言足すのが、一番効くコツでした。

• --

（このテキストで約2,900字です。必要なら短縮版や、口調違いのバージョンも出せます）

【Claude Codeをはじめる（課題1-1〜1-4）をやってみて｜次にやる人へのフィードバック】

① やってみた課題

実際にやったのは、次の4つの「作って→ブラウザで動かす」課題でした。

• 1-1：HTMLでシューティングゲームを作る。完成したらブラウザで開いて、自分で遊んで確認する。
• 1-2：お店のホームページ(LP)を作る。いきなり作らず「DESIGN.md(設計メモ)を先に書く→デザイン方針プロンプトを当てる→セクション単位で実装」という流れ。条件は「白ベース・文字大きめ」。
• 1-3：そのホームページの"裏側"＝店舗運営の管理システム(バックオフィス)を作る。5つのタブ・100点採点・承認フローなどを1つのHTMLに。
• 1-4：この振り返り(今書いているフィードバック)。

共通して良かったのは、「完成したらブラウザで開く」まで含まれていて、絵に描いた餅で終わらず"動くもの"が手元に残ること。達成感が大きいです。

② 想定外だったこと

●詰まった所

• 「例：〜」と書かれた穴埋め部分。1-2で「[ホームページで作りたい内容 例：原宿の…スイーツ店]」とあり、"例をそのまま作るのか/自分の題材に差し替えるのか"が最初わからず止まりました。結局そのまま進めましたが、ここは迷いポイント。
• "急ぎで"と"超作り込んで"が同居していて、どちらを優先するか一瞬迷う。実際は作り込む方に寄せて問題なしでしたが、明示があると安心。
• 成果物の保存場所が指定されていないと、どのフォルダに置かれたか後で探しにくい。

●分かりにくかった言葉(略語・専門用語)

特に1-3のプロンプトが暗号のようで、初見では読めません。戸惑った言葉と意味：

• 「仕様駆動MVP=level3」…どこまで作り込むかのレベル指定。数字が大きいほど本格的、くらいの理解でOK。
• 「100点+3層振分」…各項目を100点満点で採点し、上位/中位/下位の3グループに自動で仕分ける。
• 「各画面🤖pt」…各画面にAIからの提案コメントを1つ置く、という指示。
• 「承認段階ゲート引継型」…承認を段階(起案→上長→…→公開)で進め、承認したら次の担当に引き継ぐ形式。
• 「モーダル(confirm禁止)」…確認ダイアログはブラウザ標準ではなく、自作のポップアップにする。
• 「STORE_KEY昇格」…データ保存のキー名を、目立つ最上位の設定として扱う。
• 「A2A」「FO」「ckpt」「rev=cr+sr」など…作業の進め方に関する略語。初心者は無視しても成果物には影響しませんでした。

→ これらは"知っていれば強力な時短ワード"ですが、初見では確実に手が止まります。

●逆にスムーズだった所

• ゲームもLPも、一回で"それっぽく動くもの"がすぐ出た。ゼロから悩む時間がない。
• 「DESIGN.mdを先に書く」流れは、いきなり作るより方向性がブレず分かりやすい。次の人にもこの順番はおすすめ。
• ブラウザで即確認できるので、良し悪しの判断が早い。
• 「モックでいい」「凄いと思えるものに」という緩い品質指定が、逆に自由度を上げて良い結果につながった。

③ 最初のコピペ用プロンプトへの改善案

そのままでも動きますが、次の人が迷わないために、以下のように直すと親切です。

1. 略語には初回だけカッコ書きで注釈をつける。

例：「100点+3層振分(各項目を100点で採点→上位/中位/下位に自動仕分け)」。暗号のままにしない。

2. 穴埋め[ ]の扱いを1行で言い切る。

例：「[ ]内は必ず自分の題材に置き換えてください(例のまま進めてもOK)」。差し替え必須か否かを最初に明記。

3. 相反する要望は優先順位を添える。

例：「①動くこと ＞ ②見た目 ＞ ③速さ」のように順位を書く。"急ぎ"と"作り込む"の板挟みが消える。

4. 成果物の保存先とファイル名を先に指定する。

例：「~/Projects/日付/プロジェクト名/ に index.html で保存」。後で探す手間がなくなる。

5. 完了条件を1行で書く。

例：「完成＝ブラウザで開いてエラーが出ず操作できる状態」。どうなったら終わりかを明示。

6. 略語の"用語ミニ辞典"を別紙1枚で用意する。

プロンプト本体は短いまま、意味は別で引ける形にすると、初心者にも上級者にも優しい。

総じて、「先に設計→作る→ブラウザで確認」の型は非常に良い学びでした。つまずくのは中身ではなく"言葉(略語)と穴埋めの扱い"だけ。そこに一言ずつ補足があれば、次の人はほぼ迷わず走り切れると思います。

# 「Claude Codeをはじめる（課題1-1〜1-4）」感想・次の人へのフィードバック

① やった課題

ドリップバッグ専門店を題材に、Webサイト〜裏側システムまで作成。

• 1-1：設計書（DESIGN.md）を先に作る
• 1-2：Cookbookの美学プロンプトで白ベース・文字大きめのHPを構築
• 1-3：Unsplashの公開写真（豆・農園）を入れてプロトタイプ化
• 1-4：問い合わせを受けるOEM案件管理システム（5タブ／自動スコアリング／localStorage）

一気に全部より、段階を踏むほうが手戻りが少なく速いです。

② 想定外だったこと

詰まった所

• 実行環境が外部ネットに繋がらず、`curl`/`npm`/`python`での確認が軒並み失敗。→ 追加インストール不要の方法で回避できたので、動かなくても「失敗」と早合点しないこと。
• プレビューのスクショがアニメで固まる・数字が一瞬0に見える等あるが、実ブラウザで開けば正常。見た目の撮影と動作確認は別物。

分かりにくかった言葉

• 冒頭の圧縮記号（`CC(goal/…)`）や専門語（`3層振分`＝S/A/Bの仕分け、`STORE_KEY昇格`＝保存キーの更新、`モーダル`＝画面内の確認画面）。意味は通じるが、初見だと用語の翻訳から始まる。

スムーズだった所

• 「白ベース・文字大きめ」など短く具体的な条件は一発反映。
• 設計書を先に作る→セクション単位で作る流れが安定。作成後の動作確認まで自動でやってくれる。

③ 最初のプロンプトへの改善案

圧縮記号より平文＋箇条書きが安定します。

• 環境を先に伝える：「外部ネット不可。確認は追加インストール不要の方法で。npm等が失敗しても止まらず代替で進めて」
• 完成条件を明記：「①白ベース②本文18px以上③スマホで崩れない④エラー0、を満たしたら報告」
• 専門語に括弧で補足：「3層振分（S/A/Bに自動仕分け）」のように添える
• 置き場所と最終動作を指定：「ファイル名は◯◯、既存は上書きせず新規で、完成後ブラウザで開いて」

次の人へ：合言葉より具体条件を平文で。環境制約は先に言う。プレビューが変でも動作確認が通ればOK、最後は実ブラウザで判断を。

• -

【フィードバック】Claude Codeをはじめる（課題1-1〜1-4）をやってみて

これから同じ課題に取り組む人へ。実際に手を動かして詰まった所・良かった所と、最初のプロンプトの改善案をまとめました。

■ ① やった課題（何を作ったか）

• 課題1-1：架空のスイーツ店HPを「DESIGN.md作成 → 美学プロンプト適用 → セクション単位で実装」の流れでデザイン。白ベース＋大きめ文字のLPが完成。
• 課題1-2：写真を増やし、1ページを複数ページ（Home/Menu/Gallery/Access/Reserve）に分割。ナビと各ボタンでページ間を行き来できるように。
• 課題1-3：バラバラのファイルを、CSS・JS・全画面を1つに詰めた「単一HTML」に統合。ダブルクリックで開ける形に。
• 課題1-4：そのHPの「裏側の業務システム」を仕様駆動MVPで構築。5タブ（ダッシュボード/予約審査/仕込み/メニュー分析/顧客CRM）、100点採点＋3層振分、承認ゲート、localStorage保存まで。最後にドラッグ&ドロップと移動ボタンを追加。

■ ② 想定外だったこと

＜詰まった／戸惑った所＞

• 最初のプロンプトの「作りたい内容」欄が“例：〜”のテンプレのままだと、AIが「何を作るか」を質問してくる。ここは自分で埋めてから送らないと一手止まる。
• プロンプト内の略語（CC(goal/Mon/batch…)、STORE_KEY昇格、A2A、承認段階ゲート引継型 など）が独自の符丁で、初見だと意味が読み取れない。結果は出るが「自分の意図通りか」を確認しづらい。
• 「出力：図解PNG」と指定しても、実際に返ってきたのは画面内に表示される図（インラインの図解）で、PNG画像ファイルそのものではなかった。“PNGで欲しい”なら別途お願いが要る。
• 「白ベース」「文字大きめ」のような感覚語は、具体値（#FFFFFF、見出し◯px）を添えないと仕上がりの大きさが人によってブレる。

＜逆にスムーズだった所＞

• 「1:DESIGN.md 2:美学プロンプト 3:セクション単位で実装」のように手順を番号で区切ると、その通りに順番に進んでくれて分かりやすい。
• 「写真を増やして」「ボタンで移動できるように」など、普通の日本語のざっくり指示でもちゃんと汲んでくれる。専門用語は必須ではない。
• 「まずイメージを見たい／連携はしない」と伝えると、外部サービスに繋がず動くモックを最優先で出してくれる。急ぎのときに有効。
• 作ったファイルをそのままブラウザで開くところまで一気にやってくれる。確認が速い。

■ ③ 最初のコピペ用プロンプトへの改善案

「作りたい内容」は例文を消して具体を書く

　NG例：[ホームページで作りたい内容 例：渋谷の…スイーツ店]

　OK例：「渋谷の生クリーム系スイーツ店。ターゲットは20代女性、看板メニューは巨大パフェ」

　→ 主題・ターゲット・売りの3点を書くと、質問返しなしで一気に進む。

略語・符丁は展開して1行で書く

　「STORE_KEY昇格」→「保存キーはバージョン付きにして、旧データを自動移行して」

　「承認段階ゲート引継型」→「新規→審査→承認→確定の順に、担当を引き継ぐ承認フローにして」

　→ 自分でも見返せて、意図のズレを防げる。

感覚語には数値・基準を添える

　「白ベース・文字大きめ」→「背景は白(#FFFFFF)、見出しは最大80px前後、本文18px以上」

　→ 仕上がりのブレが激減。

出力形式は“ファイルなのか画面表示なのか”まで指定

　「図解PNG」→「構成図をPNG画像ファイルで保存して」または「図は画面に表示でOK」

　→ 期待とのズレを回避。

完成条件（Doneの定義）を1行入れる

　例：「完成したら単一HTMLにまとめ、ブラウザで開いて確認まで」

　→ どこまでやれば終わりかが明確になり、余計な往復が減る。

スコープの温度感を最初に宣言する

　例：「まずは動くモック優先。外部連携は後回し。急ぎ」

　→ 精度より速度、を最初に言うと、方向性が最初から合う。

■ ひとことまとめ

手順を番号で区切る＋普通の日本語で具体を書く、この2つだけで体験が一気に良くなります。略語プロンプトはカッコいいけど、初回は「展開した文章」の方が結果も自分の理解も安定します。まず“例文を自分の内容に置き換える”ところから始めるのがおすすめ。

【Claude Codeをはじめる 課題1-1〜1-4／やってみた感想・次の人へのフィードバック】

■ ① やった課題（何をしたか）

課題1-1〜1-4を通して身についたのは、個々の作品づくりよりも「Claude Codeとの進め方の型」でした。共通の流れはこうです。

　(1) お題を決める（例：1-1はHTMLのシューティングゲーム）

　(2) いきなり作らせず、まず「設計メモ（DESIGN.md）」を書かせる

　(3) 「白ベース・文字大きめ」など"見た目の方針"を言葉で渡す

　(4) 一気にではなく、画面の"セクション単位"で順に作らせる

　(5) ブラウザで動かして確認する

私は途中から題材を差し替えて、まとめHP＋その"裏側の管理システム"まで作りました。最終的に、1ファイルで動く（データがブラウザに保存される）管理画面のモックまで到達できました。4課題を終える頃には「日本語で指示→確認→修正」のリズムが自然に身についていました。

■ ② 想定外だったこと

＜詰まった所＞

• 最初のコピペ用プロンプトが記号や略語だらけで、何を指示しているのか読めませんでした。「これ全部そのまま入力するの…？」と最初に身構えました。→ 実は"おまじない"的な部分が多く、意味が分からなくても動きます。
• 作ったファイルがどこに保存されたか分からず探し回りました。パスがとても長いので、「保存場所を教えて」と聞くのが正解でした。
• 「セクション単位で実行」の意味が最初ピンときませんでした。=「全部一気に作らず、見出し（ヒーロー、一覧、フッター…）ごとに区切って作る」ことだと、やってみて理解しました。
• エラーではないのに、期待と違う見た目が出ることがありました。→ 作り直しではなく「ここをこう直して」と会話で伝えるのが速いと後で気づきました。

＜分かりにくかった言葉＞

初回は英語＋略語で手が止まりがちでした。特に：

• worktree（作業用の一時フォルダ）／ localStorage（ブラウザ内にデータを保存する仕組み）
• モーダル（画面中央にポップアップで出る小窓）／ ゲート（次の工程へ進む"通過条件"）
• MVP（最小限の動く試作）／ サブエージェント・スキル・フック（Claude Codeの機能名）／ A2A（複数AIの連携）

どれも「単語で身構えるだけで、意味は難しくない」ものでした。分からなければその場で「◯◯って何？」と聞けば即答してくれます。

＜逆にスムーズだった所＞

• 日本語で「白ベースで文字大きめにして」と伝えるだけで、それっぽい綺麗なデザインが出てきたこと。CSSを一行も書かずに整った見た目になるのは感動でした。
• 修正が会話でできること。「もっと余白を広く」「この色を赤に」など、口頭レベルの指示で直ります。
• 確認まで自動でやってくれること。ブラウザで動かしてスクショで結果を見せてくれるので、自分でサーバーを立てる知識が無くても進められました。
• 設計（DESIGN.md）を先に書かせると、その後の実装が驚くほど安定しました。急がば回れでした。

■ ③ 最初のコピペ用プロンプトへの具体的な改善案

Before（配布されている記号圧縮プロンプト）は、正直に言うと上級者向けで、初学者は読めません。次のように直すと、次の人がずっと入りやすくなります。

改善の方向性：

　1. 記号・略語をやめて、普通の日本語の文章にする

　2. 「何を作るか／どんな見た目か／どこに保存するか」を最初に書く

　3. 一気に作らせず「①設計→②確認→③実装→④動作確認」の段取りを指示に含める

　4. 専門用語は使わない、使うなら一言注釈を付けるよう頼む

After（初学者向けコピペ用プロンプト例）:

━━━━━━━━━━━━━━━━━━

これから◯◯（例：シューティングゲーム）をHTMLで作りたいです。プログラミングは初心者なので、次の手順で進めてください。

まず「DESIGN.md」という設計メモを作ってください（画面の見た目・色・操作方法を箇条書きで）。

設計を私に見せて、OKをもらってから実装に進んでください。

HTMLは1ファイルにまとめてください。難しい専門用語が出たら、一言やさしい説明を添えてください。

完成したらブラウザで動かして、スクリーンショットで見せてください。

作ったファイルの保存場所（フルパス）も教えてください。

デザインは「白ベース・文字大きめ・シンプル」でお願いします。

━━━━━━━━━━━━━━━━━━

■ 次の人への一言アドバイス

• 用語で固まらないで大丈夫。分からない単語は「それ何？」と聞けばその場で説明してくれます。
• 完璧な指示を書こうとしなくてOK。まずざっくり作らせて、会話で直すのが一番速いです。
• 「保存場所を教えて」と付けると、ファイル迷子になりません。
• 「設計→確認→実装」の順を守るだけで、作り直しが激減します。ここが一番の学びでした。

■ Claude Code をはじめる（課題1-1〜1-4）やってみた感想 / 次の人へのフィードバック

────────────────────

① やった課題

────────────────────

• 1-1：HTMLでオリジナルのシューティングゲームを作成 → ブラウザで動作確認
• 1-2：マンション管理コンサルの相談サイトを「DESIGN.md作成 → Cookbookの美学プロンプト適用 → セクション単位で実装」の順で制作（白ベース・文字大きめ指定）
• 1-3：そのHPの“裏側システム”を仕様駆動MVP(level3)で作成。5タブ／100点AI診断＋3層自動振分／承認ワークフロー（段階ゲート・担当引継）／図解PNG付き、localStorage・日本語・白基調
• 1-4：この振り返りフィードバックの作成

いずれも「圧縮した記法（略語だらけの1行プロンプト）＋作りたい内容」を渡す形式。

────────────────────

② 想定外だったこと

────────────────────

【スムーズだった所】

• 略語まみれの指示でも、ちゃんと解釈して「選定→理由→結果→check→要約」の型で報告が返ってきた。指示の“骨組み”を先に決めておくと出力が安定する実感。
• 成果物を口頭確認で終わらせず、実際にヘッドレスブラウザで起動→スクショ→コンソールエラー0をチェックしてくれた。ここは想像以上に安心感があった。
• 「凄いと思う業務効率化ツールに」のような曖昧な指示でも、業務に即した具体（スコア指標・承認ゲート・担当ルーティング）へ勝手に落とし込んでくれた。
• 「白基調／文字大きめ／日本語／localStorage」等の制約はほぼ一発反映。非機能の指定は効きが良い。

【詰まった／分かりにくかった所】

• 略語の意味が“人間側で”曖昧（A2A, FO, ckpt, rev=cr+sr, 🤖pt, STORE_KEY昇格, 引継型…）。Claudeは推測してくれるが、意図とズレる余地がある。実際 A2A（サブエージェント）は「規模次第で不要」と判断され“使わない”選択になった。結果は妥当だったが、これは指示側で明示しないと挙動が変わりうるポイント。
• 「ブラウザでOpen」がローカルのブラウザ起動ではなく、リモート環境ゆえ“Artifactプレビューのリンク”として開かれた。最初は少し戸惑う。仕様として理解すれば問題なし。
• 「図解PNG」は環境にブラウザがあったから生成できたが、環境次第では失敗し得る依存だと感じた。
• 保存先とブランチ名の不一致。課題1-1で切られたブランチ名（html-shooting-game-…）のまま、HPも裏側システムも同じブランチに入る。実体と名前がズレて後から分かりにくい。
• サンプルの社名・電話・実績はプレースホルダ。どこを差し替えるべきか最後に一覧化してくれたので助かったが、指示しないと見落とすリスクがある。

────────────────────

③ 最初のコピペ用プロンプトへの改善案（具体）

────────────────────

1. 略語に“初回だけ凡例”を付ける。例：

A2A=サブエージェント委譲 / FO=並列fan-out / ckpt=コミットで保存 / rev=cr+sr=コードレビュー＋セキュリティレビュー / 🤖pt=各画面にAI提案枠

→ Claudeは推測できるが、人間側の再現性が上がる。

2. 「規模次第でA2A」を数値の判断基準にする。例：

「3ファイル or 300行超なら分割、未満はインライン」

→ 委ねる基準が明確になり、の判断ブレが減る。

3. 成果物の“置き場所”を明示する。例：

「out_dir=/mansion-consult/、branchは用途ごとに新規（名前は内容準拠）」

→ ブランチ名と中身のズレを防げる。固定でよいなら「命名は気にしない」と一言添える。

4. 「ブラウザでOpen」の意味を環境に合わせて指定する。例：

「Open=Artifactプレビューのリンクで可」or「スクショで確認」

→ 期待値が揃い、出力形式の食い違いがなくなる。

5. 完了条件（Doneの定義）を1行入れる。例：

「Done=コンソールエラー0＋主要操作のスクショ確認」

→ 今回は暗黙でやってくれたが、明示すると安定する。

6. プレースホルダ運用を宣言する。例：

「実データ未定の項目はダミー＋最後に“要差し替え一覧”を出力」

→ 差し替え漏れを構造的に防げる。

7. 主観指示（「凄いツールに」等）には“評価軸を1つ”添える。例：

「凄い＝1画面で意思決定できる（KPIと次アクションが同居）」

→ 狙いが揃い、期待とズレにくい。

8. 非機能要件（日本語／白／文字大きめ／localStorage／連携なし）は先頭にまとめる。今回うまくいった型なので踏襲推奨。

────────────────────

次の人へひとこと

────────────────────

「何を作るか」より先に「①判断基準（略語の意味・分割の閾値）②完了条件 ③置き場所と差し替え運用」を1行ずつ足すだけで、出力が一気に安定します。圧縮記法は強力ですが“人間が読み返して分かるか”が再現性の分かれ目。迷ったら普通の日本語で1行補足を足すのがいちばん効きました。

【Claude Codeをはじめる（課題1-1〜1-4）やってみた感想】

■ 全体の印象

「日本語でざっくり頼む→動くものがすぐ出てくる→気に入らなければ会話で直す」という流れが本当に速い。ファイルの作成・ブラウザ表示まで全部やってくれるので、コードが書けなくても“作った感”がしっかり得られました。次にやる人は、完璧な指示を考え込むより、まず投げてみて会話で育てる方が向いています。

━━━━━━━━━━━━━━━━━━

① やった課題

━━━━━━━━━━━━━━━━━━

• 課題1-1｜シューティングゲーム作成

　「オリジナリティのある作り込んだHTMLシューティング」を依頼。単一HTMLで敵5種・ボス戦・パワーアップ・パーティクルまで入ったゲームが1発で出てきて、そのままブラウザで起動。

• 課題1-2｜浅草ラーメン紹介HP（仕様駆動）