20260930_名古屋クラメソゆる勉強会_Claude Codeデモンストレーション

2026/09/30 名古屋クラメソゆる勉強会で使用したスライドです。
ClaudeCodeの基本的な使用方法・コマンドを記載してます。

Transcript

1. Claude Codeデモンストレーション Claude Code で、小さな業務ツールを15分でつくる クラスメソッド株式会社 製造ビジネステクノロジー部 石井悠汰 なごやクラメソゆる勉強会 #5 2026.09.30
2. 今日つくるもの：期限つきタスク管理ツール 自分ひとりで使う ブラウザだけで動く 足りないところ 共有もログインもなし。業務でやることを1 インストールも起動作業もなし。閉じても中 ここを、これからその場で足します。 か所に置くだけ。 身は残る。 ビルドもサーバー起動も要りません。 HTMLファイルをブラウザで開くだけです。
3. まずは録画でお見せします 空のフォルダから、さっきの雛形ができるまで。 01 02 03 困りごとを伝える 計画を先に出させる 読んでから承認する 「何を作るか」ではなく「何に困っていて、ど いきなり作らせない。何をするかの一覧が ここで方向を直せば、あとから作り直さず うなりたいか」を渡す。 先に返ってくる。 に済む。 仕事で自分だけが使う小さなツールを作りたいです。業務でやるべきことを書き留めておく場所が、Slackのメモ欄と手元のメモ帳 とカレンダーに散らばってしまって、結局どこを見ればいいのか分からなくなるのが困っています。期限があるものだけでも一箇所 にまとめて、朝これを開けば今日やるべきことが分かる、という状態にしたいです。 自分専用なので、他人と共有する機能やログイン周りは不要です。会社のPCのブラウザで開くだけで使えて、閉じても内容が残っ ていてほしい。特別なインストールや起動作業が必要だと結局使わなくなるので、そこは避けたいです。 どう作るのが良さそうか、まず計画を教えてください。 ビルドなしで、単一のHTMLファイルだけで成立する形にしてください。
4. ここからライブ 一文で言えることは、計画なしでいい 差分を一文で説明できるなら、計画は省略していい。小さい直しは、そのまま頼んで大丈夫です。 タスクを消すときに、確認なしで消えてしまう。 間違えて触って消したことがあるので、消す前に一度だけ確認してほしい。 この規模なら、計画を挟むほうがかえって遠回りになります。
5. 基本の流れは、この 5つ さっきのような小さい直しは計画を省略していい。大きい変更のときは、この順で進めます。 STEP 1 STEP 2 STEP 3 STEP 4 相談する 計画を読む 実装させる 確認させる 困りごとを伝える。 何をするかを確認する。 変更点が出てくるのを見ながら 期待した動作を行っているか確 待つ。 認させる。 モードは Shift+Tab で切り替えます。STEP 1~2 は Plan mode（読むだけで書かない）。承認したら実装用のモードに移行します。 STEP 5 レビューさせる 作業者ではない別の視点で見てもらう← 今日はここまでやります。 飛ばされがちなのが STEP 2・4・5。今日はここを見てください。
6. ここからは機能改修 20件たまると、 今日やるべきものが分からない 案件Aの作業も、案件Bの作業も、社内の雑務も、 全部おなじ一覧に混ざっていると視認性が悪い。 打ち合わせ中に「この案件のぶんだけ」を追えない。
7. こう相談しました 作るものではなく、困っている状況をそのまま渡しました。 案件Aの作業と案件Bの作業と、社内の雑務が全部おなじ一覧に混ざっていて、打ち合わせ中に「今この案件の話をしている」というときに、その 案件のぶんだけを見たいのに探せない。期限で並んでいるのは朝の確認には合っているけど、特定の案件だけ追いたいときには向いていない。 必要なときだけ視界を絞れるようにしたい。逆に、絞り込んでいないときの見え方は今のままでいい。朝の使い方は壊したくない。 どう見せるのが良いか、計画を出して。
8. 出来上がったものをレビューする いま直したところを、標準のコードレビューコマンドで見てもらいます。 /code-review この会話のまま打てる 別の枠が、差分だけを読む 直させることもできる 別のセッションを立てる必要はありません。最初 まっさらな状態で立ち上がるので、実装したとき --fix を付けると、指摘をその場で反映します。た から入っているので、用意も要りません。 の理屈は渡りません。 思い込みを引き継がずに だしこの直しは巻き戻しでは戻せません （git の 見てくれます。 仕事）。 指摘が出るのは普通のことです。全部直す必要はありません。正しさに関わるものだけ拾えば十分です。
9. 持ち帰ってほしいこと 1 作業計画を出させて、承認してから進む 2 実装は動作確認までセットで 3 間違った指示を出しても、戻せる
10. 効率的な作業のために ① 自分の手元を速くする 名前だけ聞くと難しそうですが、どれも「毎回これを説明している」を減らすための道具 です。 CLAUDE.md Skills サブエージェント Hooks 会話の最初に毎回読まれるファイル。 決まった手順を、必要なときだけ読ま 別の枠で走らせて、結果だけ受け取 決まった場面で必ずスクリプトを走ら せる。 る。 せる。 こういうとき こういうとき こういうとき こういうとき 「起動の仕方はこう」「この書き方で」を 同じ手順書を何度も貼り付けている と 調べもののログで本題の会話が埋ま 「毎回やって」と書いてもたまに飛ばさ 毎回説明しているとき。 き。月次の作業など。 るとき。 れるとき。 CLAUDE.md は「お願い」、Hooks は「必ず実行」。守らせたいなら後者です。一部のファイルにだけ効かせたい決まりごとは .claude/rules/ へ（置き場と使い分けは付録に）。
11. 効率的な作業のために② 他のツールとつなぐ・チームで使う ここから先は、自分ひとりの作業を超えたとき に必要になるものです。 MCP連携 並列セッション プラグイン コードレビュー 外部のツールやサービスにつなぐ。 複数を同時に動かす。 左の3つをまとめて配れる形。 差分を、別の目で見てもらう。 こういうとき こういうとき こういうとき こういうとき 実装の待ち時間が長いとき。別々の 自分の設定をチームに配りたいとき。 取り込む前。作った本人に採点させな チケットや社内のデータを、会話の中 作業に分けるなら git が前提。 出所は確かめてから。 いため。 から直接読み書きしたいとき。 右端のレビューは、今日の STEP 5 でやったものです。残りの3つは、自分ひとりの作業を超えたときに出てきます。
12. このあと・次回 このあと 45分 10月末 後日 相談会・交流タイム 実践編 資料を公開します 既存のコードにどう使うか、どこまで任せる 今日の内容を元に作りたいアプリを実際に connpass に参加者限定で載せます。 かは相談会で聞いてください。 作成していただきます。 実践編の準備：Pro 以上の契約が必要／Windows でデスクトップアプリを使う場合は Git for Windows も
13. 付録 手を動かすときに開くページ 最初から入っているスキルとコマンド、何本も並列で走らせる方法、 もっと大きいものを作るときの頼み方。それぞれドキュメントへのリンク付きです。 全部を今すぐ覚える必要はありません。必要になったときに戻ってきてください。
14. 権限モードの使い分け Shift+Tab で切り替えます（デスクトップアプリは送信ボタンの横のセレクタ）。どこまで自分で承認するか、の度合いです。 モード 何が起きるか 使う場面 Plan ファイルを読み、コマンドも実行して調べるが、ソースは編集 STEP 2。やり方が決まっていない／複数ファイルに跨る／ しない。最後に計画を出す 不慣れなコードを触るとき ファイル編集とコマンド実行の前に毎回確認。差分を見て、 1つずつ目を通したい変更のとき Manual 受け入れるか拒否するかを選ぶ Accept edits ファイル編集と mkdir・touch・mv は自動で通す。それ以外 編集は任せてよくて、速く回したいとき のコマンドは確認する Auto 別の判定モデルが全部のアクションを先に見て、権限の逸 中断されずに進めたいとき。今日のデモはこれ 脱・知らないインフラ・仕込まれた指示などリスクのあるもの だけ止める Bypass 確認なしで全部実行する サンドボックスや使い捨てのVMの中だけ 基本形 複雑なものは Plan で始める。計画を承認したら、 Accept edits か Manual に切り替えて実装させる。 中断が煩わしければ Auto。 Manual は安全ですが、 10回目の承認あたりからは、読まずに押しているだけ になりがちです。安全 side を保ったまま中断を減らすなら、 /permissions で安全だと分かっている コマンドを先に許可しておくか、 /sandbox で隔離して自由に動かすほうが効きます。
15. 自分の手元を速くする CLAUDE.md Skills 毎回の会話の最初に読まれるファイル。ビルド手順や規約など、毎回説明して 決まった手順をひとまとめにして、必要なときだけ読ませる仕組み。 いることを置いておく。 使いどころ： 同じ指示・チェックリスト・複数ステップの手順を何度も貼り付けてい 使いどころ： 長くしすぎると肝心のルールが埋もれる。手順が増えてきたら 目的 る場合、または CLAUDE.md が事実ではなく手順に成長している場合にスキル に応じてSkills に移す。 を使用する。 code.claude.com/docs/ja/memory code.claude.com/docs/ja/skills サブエージェント Hooks 調べものを別の枠で走らせて、結果だけ受け取る。 決まったタイミングで必ずシェルコマンドを走らせる。 使いどころ： サイドタスクがメイン会話に検索結果、ログ、または再度参照しない 使いどころ： 特定のアクションが常に発生する整形・通知・コマンドの検証・ルー ファイル内容で溢れかえる場合に利用する。 ルの強制など。 code.claude.com/docs/ja/sub-agents code.claude.com/docs/ja/hooks-guide
16. どこに何を書くか（ CLAUDE.md・ルール・スキル・ Hooks） 一番迷うところです。違いは「いつコンテキストに乗るか」 で、置き場所はそれぞれ決まっています。 書くもの 置き場所 いつ読まれるか CLAUDE.md ./CLAUDE.md または ./.claude/CLAUDE.md（チームで共有） 毎セッションの最初に必ず。上位ディレクトリのものも一緒に読ま 毎回必要な事実 個人用は ~/.claude/CLAUDE.md／この案件だけの個人メモは れる ./CLAUDE.local.md（gitignore） ルール .claude/rules/testing.md のようにトピックごと 1ファイル paths: を書けば、一致するファイルを読むときだけ。書かなけれ トピック別の決まりごと 個人用は ~/.claude/rules/ ば毎セッション スキル .claude/skills/<名前>/SKILL.md 呼んだときだけ（ /名前）。関連すると判断されれば自動でも 複数ステップの手順 個人用は ~/.claude/skills/ Hooks .claude/settings.json（共有）／ .claude/settings.local.json（自分 必ず実行させたい処理 だけ） 決まった場面でシェルが走る。中身はコンテキストに乗りません 個人用は ~/.claude/settings.json 迷ったらこの順で 1. 毎回必要な事実か→ CLAUDE.md（200行以下を目標。長いほど守られなくなります） 2. 一部のファイルにだけ効くか→ ルールに paths: を付ける 3. 複数ステップの手順か→ スキル 4. お願いではなく必ず実行させたいか→ Hooks 複数ステップの手順になっているもの、コードベースの一部にだけ関わるものは、スキルかルールに移します。 CLAUDE.md が膨らんできたら、検討しましょう。 いま何が読み込まれているかは /context の Memory files で確認できます。置き場所の一覧は /memory。なお Claude が自分で書き溜める「自動メモリ」は別物で、 ~/.claude/projects/<project>/memory/ にあります。
17. CLAUDE.md の⼿⼊れ 毎セッション必ず読まれるファイルです。放っておくと膨らんで、肝⼼のルールが埋もれます。とはいえ、⼿で書き続ける必要はありません。 ふだんは、定期的に回すだけ その場で⾜すのは、この2つのとき /init コードベースを⾒て作り直す（既にあれば上書きせず改善を提案） 同じ間違いを2回⽬にやったとき ∕ /doctor コードから読み取れる内容の削除を提案 き。 /doctor prompt-audit 古い記述‧存在しないファイルへの参照‧⽭盾を そのときは「これが起きないようにルールを追加して」と頼めば、その 洗い出す 場で書いてくれます。 前と同じ説明を打ち直していると どれも提案を出すだけで、こちらが頼むまでファイルは変わりません。 できあがったものを⼀度だけ読むときの⽬安 残すもの：起動やビルドのコマンド、標準と違う書き⽅の決まり、テストの回し⽅、ブランチ名やPRの作法、環境の癖、引っかかりやすい落とし⽳。読んでも分か らないことです。 消していいもの：コードを読めば分かること、⾔語の⼀般常識、APIの詳細（リンクで⾜りる）、よく変わる情報、ファイルごとの説明。/doctor はここを削除候補 として挙げてきます。 /memory で置き場所の⼀覧が出て、選ぶとエディタで開きます。⼿順に育ったセクションはスキルへ、⼀部のファイルにだけ関わるものは .claude/rules/ へ（前の⾴）。
18. 仕事の道具とつなぐ・チームに渡す MCP連携 並列セッション 外部のツールやサービスにつなぐ仕組み。課題管理やデータベースを、会話の 複数を同時に動かす。片方に書かせて、もう片方に見せるのが定番です。 中から直接読み書きできるようになります。 使いどころ： 「画面を開いてコピーして貼る」が毎回発生している作業。つなぐ先 使いどころ： 実装の待ち時間が長いとき。同じフォルダで2つ走らせると編集が の権限は、自分のアカウントの権限そのままになる点に注意。 ぶつかるので、作業を分けるなら git worktree で別フォルダにします。このあと code.claude.com/docs/ja/mcp の claude agents なら、この分離を自動でやってくれます。 code.claude.com/docs/ja/worktrees プラグイン コードレビュー Skills・Hooks・サブエージェント・MCP設定をまとめて配れる形。 差分を、作った本人ではない別の枠で見てもらう。/code-review がデフォルトで 使いどころ： 自分で整えた設定をチームに配るとき。有志が公開しているものも 入っています。 あるので、どこから入れたかは意識しておくと安全です。 使いどころ： 変更を取り込む前。まっさらな状態のほうが抜けを見つけやすい、 code.claude.com/docs/ja/plugins という考え方です。今日の STEP 5。 code.claude.com/docs/ja/best-practices
19. 最初から入っているスキル（確認とレビュー） 自分で作らなくても、/ を打つと出てくるものがあります（バンドルされたスキル）。STEP 4 の確認と STEP 5 のレビューは、ここで足ります。 確認させる — 3つで連携します /verify アプリをビルドして実行し、変更が意図どおりか確認する。 テストや型チェックには逃げません。 呼んだときだけ走ります（時間とトークンを使うので） /run アプリを起動して操作し、テストではなく 動いているアプリで 変更を確かめる /run-skill-generator 自分のプロジェクトの起動方法を、上の 2つに教え込む レシピが無いときは /verify がうまくいった手順を .claude/skills/verify/SKILL.md に自分で書き残すので、次回以降と他のエージェントが同じ手順をたどれます（ v2.1.200 以 降）。これが「整備されていく」の実例です。 レビューする /code-review いまの差分を、正しさのバグと「使い回せる・単純にできる・速くできる」の観点で見る。 --fix で直し、 --comment で GitHub のPRにインラインコメント、 ultra でクラウドの深いレビュー /simplify 変更箇所の片付け。 4つのレビューエージェントが並列で 走り、既存のヘルパーの使い回し・簡潔さ・効率・抽象度を見る /security-review いまのブランチの未反映の変更を、脆弱性の観点で見る ／ /review <PR番号> GitHubのPRを読み取り専用で一気に読む 同じ名前で自分のスキルを置くと、そちらが優先されます（プロジェクトのcode-review スキルは /code-review を置き換える）。出典：コマンドリファレンス／Skills
20. 困ったときと、知っておくと楽なもの こういうとき これ 中身 そもそも動かない・入れ直した気がする /doctor セットアップ診断。二重インストール、 PATH、壊れた 設定ファイルを見つけて直せる 許可の確認が毎回うるさい /fewer-permission-prompts これまでの会話を見て、読み取りだけの操作に許 可リストを作ってくれる 何を書き換えたのか分からない /diff 未コミットの変更と、各ターンの差分を見る画面 戻したい（今日のライブ②） /rewind または Esc×2 会話・コードを前の時点へ。選んだところから要約し 直すこともできる 話が長くなって重い /context → /compact いまの使用量を色のグリッドで見て、そこまでを要 約して軽くする 枝分かれして試したい /branch いまの時点から会話を分岐させる コードベース全体をまとめて直す /batch <指示> 5〜30個に分解し、 worktreeで分離したサブエー ジェントを立て、それぞれ PRを開く 調べものをまとめてほしい /deep-research <問い> ウェブ検索を広げ、出典を突き合わせて、引用付き のレポートにする ほかに /plan（最初から計画モード）、/memory（CLAUDE.md を編集）、/usage、/loop、/dataviz など。全部は /help で出ます。
21. 何本も走らせて、 1画面で見る（エージェントビュー） シェルで claude agents と打つと開く画面。プロンプトを打つたびにセッションが 1本ずつ増えます（前のセッションへの追撃ではなく、並行して別のセッションが起 動する）。 依頼① 依頼② 依頼③ 3行ならぶ バグ修正 プルリクエストのレビュー 不安定なテストの調査 入力が必要 ／ 実行中 ／ 完了 にグルー プ分けされて表示される 同じファイルを触っても壊れない理由 各セッションは、ファイルを編集する前に .claude/worktrees/ 配下の自分用の作業コピー（ git worktree）に移動します 。読むのは同じチェックアウト、書く のはそれぞれ別。自分で worktree を用意する必要はありません。 そこで分離されたセッションは、確認を求めずに コミットし、自分のブランチを push し、ドラフト PRを開きます 。main / master には push せず、force push も マージもしません。行の右端に出る #番号 が結果の受け取り口で、 緑になったらレビューしてマージ 、紫はマージ済み。 リサーチプレビュー。Claude Code v2.1.139 以降（claude --version で確認）。消すときは注意：Ctrl+X を2回でワークツリーごと消えます（未コミットの変更も）。シェルのclaude rm は未コミ ら残します。
22. 一覧で見る、 1本だけ見る、中に入る 見たいもの 操作 出てくるもの ぜんぶを一覧 claude agents 入力が必要／実行中／完了に分かれた行。各 行に要約と、あれば PR番号 1本だけ軽く 行を選んで Space ピークパネル。最新の出力か、待っている質問。 そのまま返信して Enterできる 中に入る Enter または → フル会話にアタッチ。空のプロンプトで ← を押す と一覧に戻る 並べ替え Ctrl+S 状態ごと ↔ ディレクトリごと の切り替え 1案件だけに絞る claude agents --cwd <パス> そのディレクトリ配下で始めたセッションだけ（既 定は全プロジェクト） 操作を思い出す ? その場でショートカット一覧 いま開いているセッションを一覧に入れるなら /bg、または空のプロンプトで ←。画面を開かずに投げるなら claude --bg "<プロンプト >"。いまのセッションの中で 動いているものを見るのは /tasks です。 /agents は名前が似ているだけの別物です（サブエージェントのファイルの場所を教えてくれるコマンド）。並列セッションの一覧は claude agents。
23. 大きいものを作るときは、先にインタビューさせる アプローチが決まっていない、複数ファイルに跨る、不慣れなコードを触る。このときは計画が効きます。逆に 差分を一文で説明できるなら、計画 は省略していい 。 ［作りたいものを一言で］を作りたいです。AskUserQuestion ツールを使って 、詳しくインタビューしてください。 技術的な実装、UI/UX、エッジケース、懸念点、トレードオフについて聞いてください。当たり前の質問はせず、私が考えられていない難所を掘り下 げてください。 すべてカバーできるまでインタビューを続けて、そのあと SPEC.md に完全な仕様を書いてください。 終わったら新しいセッションを開いて、そのSPEC.md を実行させます。実装だけに集中した状態で始められます。 出典：ベストプラクティス（日本語訳）
24. 影響範囲が大きいときは、一発で頼まない 1 範囲を測る ［変更］をするには、どのファイルを触る必要がありますか？ 2 壊れるものを知る ［対象］を消したら、何が壊れますか？ ［対象］を［目的］のためにどうリファクタリングするか計画してください。変更するファイルを挙げて、まだ何も編集しな 3 計画だけさせる いでください 。 最後の「まだ編集しないでください」が効きます。探索と変更が分かれるので、コードが動き出す前にアプローチが見えます。 出典：プロンプトライブラリ（原文は英語／日本語訳）
25. まとめて読むなら ベストプラクティス 今日話した「計画を読む」「確認まで頼む」「戻せる」の元ネタ。まずはここから。 docs/ja/best-practices プロンプトライブラリ コピーして使えるプロンプト集。職種で絞り込めます。既存のコードがある前提のものも多いので、タグで絞るの docs/ja/prompt-library がおすすめです。 はじめかた デスクトップアプリの入れ方と最初の一歩。10月末の実践編の前にここまで済ませておくと楽です。 docs/ja/desktop-quickstart 変更履歴 docs/ja/changelog 進化が速いので、久しぶりに触るときはここを見ると差分が分かります。