第17回 大規模開発 ─ CI/CD・SDK
大きい仕事をどう渡すか、そしてClaude Codeをパイプラインにどう組み込むか。仕様書を先に書き、別視点でレビューさせ、並列で走らせる。さらにGitHub連携・claude -p・SDKでCI/CDの中にClaudeを置く。Claude Codeの使い方コース 第17回。
大規模開発
第17回スタート。エンジニア向けの🔴回。今日のゴールは2つ。①大きい仕事の上手な渡し方を知る ②Claude Codeをパイプライン（CI/CD・SDK）に組み込む。前半は仕事の渡し方、後半は自動化の土台づくり。
応援お願いします！
共通テンプレート（src/deck-shared.tsx の CtaSlide）。高評価・チャンネル登録・メンバーシップ・noteメンバーシップのお願い。内容はテンプレート側で一括管理。
「そのまま渡す」問題
大きいタスクを丸ごと「これ全部やって」と渡すと2つの事故が起きる。①途中でコンテキストが切れて、最初の指示を忘れる ②全体像がないまま進み、方向がズレて大きな手戻りになる。地図なしで大工事を始めるイメージ。だから準備が要る。
仕様書を先に書く
解決策その1。SPEC.mdパターン。いきなり実装させず、まずClaudeにこちらをインタビューさせて仕様書を作らせる。実装前にその仕様書をコンテキストに読み込ませる→方向のズレが消える。設計図を先に描いてから工事する、当たり前のことをAIにもやる。
誰が何を決めるか
仕様づくりの肝は役割分担。人間が決める＝要件・優先順位（何を作るか・何を大事にするか）。Claudeが決める＝実装方法（どう作るか）。この線引きを仕様書ではっきり分ける。人間は判断に集中し、実装の細部はClaudeに任せる。
Writer / Reviewer
解決策その2。実装役と別のレビュー役を分ける。セッション1が実装（Writer）、セッション2は別のClaudeがレビュー（Reviewer）。同じ頭だと自分のミスに気づきにくい→わざと「別の視点」を作って間違いを捕まえる。一人二役より、別人格の二段構え。
並列セッション
解決策その3。複数のClaude Codeを同時に走らせる。それぞれ別タスク・別の独立したコンテキストなので干渉しない。第9回のサブエージェントの発展形＝独立した作業者を並べるイメージ。大規模ほど並列が効く。
GitHub統合
ここから後半、パイプライン編。/install-github-app 一発でGitHub Appをセットアップ。ここは紹介にとどめ、実演はしない ─ GitHubそのものの使い方は難易度が高いので、別コースでまとめて扱うと明言する。Mention Action＝Issue/PRに @claude と書くとClaudeが応答・作業。PR Action＝PRを自動でコードレビューし影響範囲を分析。ツール権限は設定で管理。チームの開発フローにClaudeが住み着く。
claude -p ─ 非対話モード
claude -p は非対話モード。対話画面を開かず、パイプラインやスクリプトからClaude Codeを呼べる。stdin/stdoutでつなぐので、ログ解析の自動化・バッチ処理・大規模マイグレーションに向く。人が座っていなくても回る使い方。
Claude Code SDK
もっと細かく制御したいなら公式SDK。TypeScript／Pythonからimportして使う。claude -p より細かい制御＝ツール権限・モデル・並列度を指定できる。既定は読み取り専用で安全、書き込みは allowedTools で明示的に許可する。プログラムにClaudeを埋め込む正式な入口。
パイプラインに組み込む
全体像。CI/CDの流れの中でClaudeが動く＝コミット→レビュー→解析→デプロイのどこにでも差し込める。ただし鉄則は2つ。権限は最小限（既定読み取り・書き込みは明示）／人間のレビューは必須。自動化しても最終確認は人が握る。
実演① 作るものを取材させて決める
実演はここから3枚ひと続き。作るものは「RSS 3本の前日分の新着を集めて、3行要約つきのMarkdownを1日1枚つくるツール」。RSSは はてなブックマーク テクノロジー（https://b.hatena.ne.jp/hotentry/it.rss）／Publickey（https://www.publickey1.jp/atom.xml）／ITmedia NEWS（https://rss.itmedia.co.jp/rss/2.0/news_bursts.xml）の3本を使う（収録前にこのURLを手元にコピーしておく）。要約は claude -p にやらせる（前半に出てきた非対話モードがそのまま出番になる）。画面のプロンプトをそのまま打つ ─「毎朝の情報収集を自動化する小さなツールがほしい。実装はまだしないで。」「1問ずつ質問して要件を引き出して、SPEC.md にまとめて。」。あとは聞かれたら画面右の5つ（集めるもの／出力／要約のさせ方／動かし方／結果の受け取り）を答えるだけ。動かし方は GitHub Actions で毎朝6時、できたMarkdownはメールに添付して自分へ送る。実況ポイント＝①1問ずつ聞いてくるので、こちらは考えを言葉にするだけでいい ②聞かれるのは「何を作るか」で「どう作るか」は聞かれない ③「GitHub Actionsで毎朝6時」「結果はメールで受け取る」も要件としてこの時点で渡しておく（あとで運用を後付けしないため）。
実演② 運用込みの計画を書かせる
SPEC.md ができたら、実装ではなく計画を書かせる。画面のプロンプトをそのまま打つ ─「SPEC.md をもとに実装計画を PLAN.md に書いて。GitHub Actionsで毎朝6時に実行、結果はメール添付で送る。そこまで含めて。まだ実装はしないで。」。迷うところは聞いてほしい、と口頭で足してもいい。出てきた PLAN.md を画面で一緒に読む。実況ポイント＝①「まだ実装しないで」でいきなり手が動くのを止める ②ワークフロー定義・スケジュール（cron式）・メール送信の手順が1枚に並ぶ ③メール送信の認証情報をどこに置くか（リポジトリのSecrets）も動かす前に決まる ─ 値そのものは画面に出さないよう注意する。締めの一言＝「作ってから運用を考えると二度手間。最初から運用込みで設計させる」。
実演③ 計画にOKを出して投げる
締め。計画にOKを出して、一気に実装させ始めるところで終わる。プロンプトは1行 ─「PLAN.md のとおり実装して。ワークフローとメール送信の設定まで含めて。」。走り出したのを見せたら実演は終了で、完走は待たない（数分〜十数分かかるため）。実況ポイント＝①計画を一緒に読んで選択肢に答えるだけでOKになる ②あとは投げるだけ ③人間がやったのは、質問に答えることと計画にOKを出すことだけ。実行基盤としてGitHub Actionsを使うが、ワークフローを書くのも設定するのもClaude側で、GitHubそのものの使い方は説明しない（別コース送り）。
今日のまとめ
大きい仕事は丸投げせず、仕様書を先に書く（人間=要件／Claude=実装）。Writer/Reviewerで別視点を作り、並列セッションで広げる。取材→実装→運用の計画まで、ひと続きで渡せる。パイプラインには claude -p・SDK・GitHub連携で組み込む。権限は最小限・レビューは必須。
次回予告
次回は第18回「Discordからも使えるよ ─ どこからでもClaude Code」。ターミナルの外、スマホやチャットからClaude Codeを動かす話。チャンネル登録とメンバーシップ登録もよろしくお願いします！
応援お願いします！
共通テンプレート（src/deck-shared.tsx の CtaSlide）。最後にもう一度、高評価・チャンネル登録・メンバーシップ・noteメンバーシップのお願い。