はじめに：AIで開発が速くなる…というより「人間に価値のある仕事が変わった」
私はシステム開発の現場で、開発チームリードとして働いています。
遅ればせながら最近Claude Codeを本格的に使い始め、今後のシステム開発の展望について思うところがあったので、ここにまとめます。
Claude Codeを使っていて一番衝撃だったのは、いわゆる“実装フェーズ”よりも前にある
要件・設計のドキュメント整備が、最もコストをかけるべき領域として再浮上したことでした。
逆に言うと、"実装とテスト"は驚くほど速く進みます。
ただし前提があります。AIは「曖昧さが少ない世界」で強い。だから AIが迷わない地図を先に渡す必要があります。
これまで大きなコストがかかっていた "実装とテスト"では、もう人間にコストを払う価値が薄れているのが実情です。
Claude Code + SDD で作ったもの
作ったのは、設定した複数のYouTubeチャンネルを監視して新着動画をGeminiで要約し、Slack/Discordに通知する仕組みです。
IaCで誰でもすぐにデプロイできるようにしました。
コストも月$2程度と安価に運用可能な設計にしています。
NotebookLMで都度YouTube動画の要約をしている方などがいたら、是非使ってみてください!
自動で動画の要約が上がってくるの、かなり便利です！
Gitリポジトリ
是非issueやPRください！
Slack/Discord通知
英語の動画も日本語で要約してくれるので、日本メディアを通さない一次情報をリアルタイムに拾えるようになったのが棚からぼたもちでした。
設定
yaml形式で監視チャンネルやプロンプトなど簡単に設定できるようにしています。
channels:
- id: "UC16niRr50-MSBwiO3YDb3RA"
name: "BBC News"
- id: "UCIALMKvObZNtJ6AmdCLP7Lg"
name: "Bloomberg Television"
summarization:
model: "gemini-2.5-flash"
language: "japanese"
prompt_template: |
Watch this video and respond in {language}.
Output format(Markdown):
Key points (bulleted): Provide 1-4 bullet points capturing the most important takeaways.
Guidelines:
- Be specific and grounded in the video content (avoid generic filler).
- If the video is a live stream or very long, focus on the main segments and overall conclusion.
notifications:
- name: "team"
platform: "slack"
secret_key: "slack_webhook_team"
message_template: |
*{title}*
• Channel: {channel}
• Published: {published_at}
• URL: {url}
{summary}
- name: "private"
platform: "discord"
secret_key: "discord_webhook_private"
message_template: |
**{title}**
- Channel: {channel}
- Published: {published_at}
- URL: {url}
{summary}
Quick Start
AWS SAMで誰でもすぐにデプロイできるようにしています。
git clone git@github.com:sohei56/youtube-summary-notify-with-gemini.git
cd youtube-summary-notify-with-gemini
sam build --template-file infra/template.yaml
sam deploy --guided
デプロイで作成されたS3バケットに前述のyamlファイルを配置し、Secrets Managerにシークレットを登録すれば動作します。
詳しい手順は00_deployment.mdを見てください。
今回の作業の全体像
ざっくり、作業は3フェーズに分かれました。
- ドキュメント作成（CLAUDE.md, docs/）：約6h
- 実装・テスト：約1〜2h
- デプロイ・動作確認：約1〜2h
体感としては「実装に入った瞬間からほぼ完成する」に近いです。
1. ドキュメント作成（CLAUDE.md, docs/） — 人間が価値を持つ仕事
やったこと
ClaudeとChatしながら、要件定義から入り設計資料を整理して docs/ に落とし込みました。
その上で CLAUDE.md から docs を参照させるようにしました。
我流でドキュメント整備したのですが、あとから spec-kit 使ってみればよかったと後悔しました。。
作成したDocuments
詳細はGitを見てください。
youtube-summary-notify-with-gemini/
├── CLAUDE.md
└── docs/
├── 00_requirement/
│ └── 00_requirement.md
├── 01_design/
│ ├── 00_architecture-design.md
│ ├── 01_application-design.md
│ ├── 02_data-design.md
│ └── 03_coding-standards.md
├── 02_operation/
│ └── 00_deployment.md
└── 03_external_apis/
├── 00_youtube-data-api.md
├── 01_gemini-api.md
└── 02_notification-webhook-api.md
実体験からの学び
1) 要件・設計の“意思決定”は人間がやるべき
当然ですが、ここはAIに任せると薄くなります。
Claudeはたとえば S3 or DynamoDB のように幅を持たせた案を出しがちで、
そこを人間が決めて初めて「要件・設計」として意味のある文章になります。
AIは選択肢を並べるのは得意ですが、「決める」のはまだ人間の仕事です。
2) Claudeは“ドキュメント構成の整理”が苦手
経験上、Claudeはドキュメントを「並列の文章」として生成しがちで、
同じ内容が複数ドキュメントに出現したり、責務分担が曖昧になりやすいです。
人間でいうと 部下が作ってきた文章に対して
「同じ話が散らばってる」「論点の粒度や親子関係が崩れてる」って指摘するやつに似てます。
俯瞰して構成立てて整理する力は、しばらく人間の得意分野だと感じました。
3) 観点漏れは相互レビューし合う関係になるべき
Claudeが「漏れてた観点」を補ってくれるのは本当に助かります。
一方で、Claude側の漏れを人間が指摘すべき場面もありました。
例えば私は
- エラーハンドリングの観点追加
- データ設計で「配列であるべき箇所がそうなっていない」点の指摘
などを入れています。
ここは相互にレビューし合う感覚が大事でした。
4) Claudeは筆が走りすぎる
放置すると大量で冗長な文章が出てきます。
「これは敢えて書かない」「粒度が細かすぎる」など、
ドキュメントのスコープ管理は人間が握った方が良いです。
2. 実装・テスト — いきなり全部作らせない方が精度が出る
やったこと
Claude Codeに要件と設計を基にした実装とテストを依頼し、成果物をレビューして必要なら修正を依頼しました。
実体験からの学び
1) 依存の少ないものから作らせると精度が上がる
いきなり全部作らせるより、簡単なものから積み上げた方がうまくいきました。
最初のプロンプトはこうでした：
Read CLAUDE.md and all documents under docs/, then implement
store/config_store.py,store/video_state_store.py, andconfig.py.
Also write tests.
他の部品への依存度の低いstore系の実装だけを最初にしてもらったんです。
人間の開発と似ていて、依存の少ない部品から作る → 依存関係の大きいところに進む、が手戻りを減らす感覚がありました。
2) 実装中も“ドキュメントと齟齬がないか”を都度チェックさせる
私は実装を小分けに進めつつ、毎回こう依頼していました：
Re-read Claude.md and all documents under docs/, and fix any implementation mistakes if you find them.
すると実際に、ドキュメントと齟齬が発生していて修正が必要になったケースがありました。
AIは速度が出る分ズレたときも速くズレるので、定期的に原典へ戻すのが効きました。
3) 実装が進むと、ドキュメント側も直すべき点が出てくる
これは人間の開発でも同じですが、
「書いた設計が現実に合ってない」ことは普通に起きます。
その場合は、実装だけ直さず ドキュメントにFBして設計を更新するのが良いです。
4) ここでも筆が走る：過剰なコード/過剰なテストは削る
過剰なテストや抽象化、未来の拡張のためのコードが増えたら、
人間が「今はいらない」を明確にして削った方が、コードとしても読みやすくなります。
3. デプロイ・動作確認 — “実際に使う”とメッキが剥がれる
やったこと
IaCで簡単にデプロイできるようにしていたので、手順を実際に試し、
ユーザーフレンドリーな動線とOutputになるようにClaude CodeにFBして、バイブコーディング的にドキュメントとコードを都度改修しました。
実体験からの学び
1) 人間にとって使いやすい・心地よいものを作るこだわりを持て
人間の開発でもあることですが、実際に動かしてみて改善点が見えてくることはあります。
特に 人間にとってどう感じるか／どう見えるか といった使用感や感覚は、Claude Codeにはありません。
ただ「動くもの」を作るのではなく、人間にとって使いやすい・心地よいものを作るこだわりにこそ、人間にコストを払う価値のある仕事だと感じました。
まとめ：生成AIが日々進歩する時代に、人間がやるべき仕事
Claude Codeを少し触っただけで大層かつ少し飛躍したことを言ってしまいますが、話半分くらいで読んでもらえると嬉しいです。
「言われたことをミスなく正確に遂行する」ことに価値があった時代は、かなり終わりに近づいていると感じました。
その領域では、遅かれ早かれ生成AIが人間を上回ります（というか、すでに上回っている分野が多いです）。
だからこそこれからは、生成AIが苦手な（あるいは責任を持てない）領域にこそ、人間の価値が残る／むしろ増えると思っています。
- 0→1を創造する（問いを立てる、テーマを見つける、仮説を作る）
- 意思決定をする（責任を持って選び、物事を前進させる）
- 人間の感覚をアウトプットする（使いやすさ、心地よさ、美しさ、違和感の言語化. 対人間のコミュニケーション）
あとがき
今まで、こういうものが欲しいな/作りたいな→こうやれば作れそうだな→でも手を動かすのダルいな、で止まっちゃうことが多かった自分には良い時代が来たかも。
spec-kit, Claude Cowork, Skills, Agents あたりも触ってみて、手じゃなくて頭と心を動かす仕事に比重をシフトしていきたいものですね〜