🎄 本記事は ZOZO Advent Calendar 2025 シリーズ 1 の 2 日目です。
1日目の記事は @ikkouさんによる「ZOZO Advent Calendar 2025の見どころ」でした。
はじめに
2025年11月15日、日本最大級のJavaコミュニティカンファレンス「JJUG CCC 2025 Fall」が開催されました。ZOZOは今回、初めて協賛企業として参加し、結果的に自分も登壇することになりました。
セッション応募と採択
協賛に伴い、会社としてセッションを持ちたいと考え、CfPに2つのセッションを応募しました。その結果、「ZOZOTOWNカート決済リプレイス ── モジュラモノリスという過渡期戦略」が採択されました。
発表資料：ZOZOTOWNカート決済リプレイス ── モジュラモノリスという過渡期戦略
なぜClaude Codeを使おうと思ったのか
ちょうど社内でAWSさん主催の「AI-Driven Development Lifecycle (AI-DLC) の実践体験ジム（Unicorn Gym）」が開催されました。これは、AWS利用者自身のユースケースでAI-DLCを使用し、AIネイティブな開発を体験するワークショップです。
私たちは、既存のモノリスな基幹システムをClaude Codeで分析し、特定のドメインをマイクロサービスとして切り出し可能かどうかを検討しました。
参考：AI主導のソフトウェア開発ライフサイクル（AI-DLC）– ソフトウェア開発をどのように変革できるか
Unicorn Gymの経験から、Claude Codeは他にも活かせると直感しました。どこまで精度高くできるかは分かりませんでしたが、情報整理から台本作成、スライド作成までClaude Codeで進めてみることにしました。
登壇経験豊富な人であれば、スライドに要点だけまとめ、台本なしで発表するのが望ましいでしょう。しかし、自分はこれが初めての外部登壇でした。また、自分はこのような場では非常に緊張しやすいタイプであると自覚していました。
緊張して頭が真っ白になった場合でも、20分の枠の中で、参加者に少しでも有意義な時間を過ごしてもらいたい。何か参考になる情報を一つでも多く持ち帰ってほしい。また、時間が足りなくなってスライドを飛ばしたりせず、20分間で要点を全て伝えられるよう、ガチガチの台本を作る方針に振り切りました。
スライド作成の流れ
準備：作業環境とコンテキストの整理
まず、Claude Codeで作業するためのディレクトリを作成しました。
mkdir -p jjug-ccc-2025-fall/docs/pdf
cd jjug-ccc-2025-fall
次に、コンテキストとなる資料を準備しました：
1. docs/pdf/ - 過去のアーキテクチャ検討資料を配置
これまでの検討過程で作成した資料（アーキテクチャ検討の議事録、登壇資料デザインテンプレートなど）をpdfファイルとして配置しました。
2. docs/docs_information.md - 各資料の概要を記載
各pdfファイルのパスと、そのファイルの概要を記載しました。Claude Codeがpdfファイルを読み込む際のコスト削減が狙いです。
3. README.md - セッションの基本情報とアウトライン
セッションのタイトル、概要、アジェンダ、話すこと、話さないことを記載しました。
# セッションタイトル
ZOZOTOWNカート決済リプレイス ── モジュラモノリスという過渡期戦略
# セッション概要
略
# アジェンダ
1. 自己紹介
2. ZOZOTOWNリプレイスの背景・概要
3. 既存のカート決済システム
4. 最終的なカート決済システムの理想系
5. 理想系への道筋
6. 意思決定の論点
7. モジュラモノリスを実現するための構成
8. 運用してわかった成功と課題
9. まとめ
# 話すこと
- 技術選択の意思決定プロセス（組織的制約を含む）
- モジュラモノリスの設計パターンと実装方針
- 実際に運用して見えてきた課題と解決策
# 話さないこと
- 詳細なコード実装（ライブラリレベルの技術詳細）
- ビジネス要件の詳細
- 他システムとの連携部分
初期プロンプト
準備が整ったところで、Claude Codeに以下のプロンプトを投げました：
あなたの役割: あなたは技術カンファレンスの登壇経験が豊富なソフトウェアアーキテクトです。
JJUG CCC 2025 Fallの20分間のセッションのための台本とスライドを作成する任務を担っています。ドキュメントは全て日本語で生成してください。
セッションの構成はREADME.mdに記載されています。また、セッションの内容に関する追加情報はdocs/docs_information.mdに記載されています。
作業の計画を立て、各ステップにチェックボックスを付けて docs/plan.md ファイルにステップを記載してください。
いずれかのステップで私の説明が必要な場合は、[Question] タグを付けて質問を追加し、私が回答を記入するための空の [Answer] タグを作成してください。独自の判断や決定は行わないでください。
計画を作成したら、私のレビューと承認を求めてください。承認後、同じ計画を 1 ステップずつ実行できます。各ステップが完了したら、計画のチェックボックスに完了マークを付けてください。
あなたのタスク: 20分間のセッションのための台本とスライドを作成
このプロンプトのポイントは以下の3つです：
- 役割の明確化 - 「登壇経験が豊富なソフトウェアアーキテクト」という役割を与えることで、適切なトーンと内容を期待
- 計画立案の依頼 - いきなり作業を始めるのではなく、まず計画を立てて承認を求める形式
-
質問駆動 - 不明点は勝手に判断せず、
[Question]タグで質問する方式
これは、AWS AI-DLC Unicorn Gymで学んだ手法です。
Claude Codeが提案した作業計画
プロンプトを投げると、Claude Codeは docs/plan.md に詳細な作業計画を作成してくれました。計画は以下のフェーズに分かれていました。
フェーズ1: 情報収集と要件定義
- [ ] pdfディレクトリ内の検討資料を確認して、セッション内容の詳細を理解する
- [ ] スライドのフォーマットを決定する
[Question] スライドはどのフォーマットで作成しますか？（例：PowerPoint、Google Slides、Markdown + Marp、Keynoteなど）
[Answer] Google Slides
[Question] スライドのデザインテンプレートやブランドガイドラインはありますか？
[Answer] docs/登壇資料デザインテンプレート.pdf、docs/template.pptx を参照してください。
このように、Claude Codeは各フェーズで [Question] タグを使用して質問してくるので、[Answer]タグに自分で回答を記入し、確認を依頼します。
以降のフェーズは以下の通りです。
- フェーズ2: セッション構成の詳細化 - 各章の時間配分の確定（合計20分）
- フェーズ3: 台本作成 - 完全な原稿形式で各章ごとに作成
- フェーズ4: スライド構成作成 - 台本に基づいたスライド構成の作成
このように、Claude Codeは作業を始める前に、まず計画を立てて承認を求めてくるという形式で進みます。これにより、作業の全体像が見え、各ステップで必要な情報を事前に確認でき、自分が想定していなかった質問にも気づけました。
ステップ毎に進める
作業計画の承認後、Claude Codeは1ステップずつ進めていきました。
資料の確認と情報整理
まず、Claude Codeは docs/pdf/ 内の資料を確認し、各章で必要な情報を整理してくれました。資料から読み取れない部分（組織体制の確定度合い、ドメイン境界の確信度など）は [Question] タグで質問してくれるため、情報の抜け漏れに気づくことができました。
台本の作成とブラッシュアップ
まず、台本の叩き台としてscript.mdファイルをClaude Codeが作成してくれました。修正したい部分の指示と反映を繰り返し、完成させていきます。完成すると、Claude Codeは文字数を数えて時間配分を確認してくれました。
現在の台本は約5,500文字です。
1分あたり300文字として計算すると、約18分程度になります。
20分の枠に対して2分の余裕があります。
もう少し詳細を追加しましょうか？それとも、このまま進めますか？
このように、時間配分を常に意識して提案してくれる点が非常に助かりました。また、実際に台本を読み上げ、本当に20分以内に収まるか検証しました。
複数のペルソナによるレビュー
ある程度台本が固まったところで、ペルソナを設定したレビューを行いました。ベテランJavaエンジニア、アーキテクト、エンジニアリングマネージャーなど、複数のペルソナでレビューしてもらいました。
特に効果的だったのは、以下のプロンプトです。
あなたはアーキテクチャ設計とJava経験が豊富なスタッフエンジニアです。
頭の回転が人よりも早く、カンファレンスなどで発表を聞くと、ついマサカリを投げたくなってしまいます。
この台本を読んで、率直な感想や、マサカリを投げたくなる部分があれば教えてください。
JJUG CCCの会場には、マサカリを投げるような怖い人はいません。とても温かいコミュニティです。このペルソナは、あくまで資料をブラッシュアップするための手段として使用しています。
このペルソナでレビューしてもらうと、Claude Codeが情報不足により想像で補っていた部分の細かな矛盾点に気づくことができました。
台本のトーン調整
台本のレビューを進める中で、Claude Codeは内容を盛ってくる傾向があることに気づきました。
- 「画期的な」「革新的な」といった大げさな表現
- 成功事例を過度に強調
- 自分が言うのは照れくさい、誇張された台本
この問題に対処するため、以下のように指示しました。
台本を「謙虚で誠実なキャラクター」で見直してください。
過度な誇張表現を避け、事実ベースで、失敗や課題も正直に語るトーンに修正してください。
この指示により、全体的にトーンが落ち着き、より自分らしい台本になりました。
スライド構成の作成
台本が完成すると、Claude Codeは docs/slide_structure.md に詳細なスライド構成を作成してくれました。スライドの作成まで自動化することも一瞬考えましたが、今回はこれを元に手動でGoogle Slideを作成しました。
各スライドの指示には以下の情報が含まれています。
- 対応する台本の範囲（script.mdの行番号）
- レイアウトパターン（図が主役/グリッド/表形式など）
- 文字サイズ（タイトル40pt、メイン28pt、など）
- タイトルとコンテンツ（そのままコピペできるテキスト）
- 作成手順（ステップバイステップの指示）
- 書式設定のヒント（例：「11万行」を赤色で強調、など）
このように詳細な指示があったおかげで、迷うことなくスライドを作成できました。まずは指示通りに作り、その後は手動でブラッシュアップしました。
完成したスライドは、社内のDevEngチームからも「スライドが見やすい！」と好評でした。
チェックボックスの更新
各ステップが完了するたびに、Claude Codeは plan.md のチェックボックスを更新してくれるため、進捗が一目で分かりました。常に「今どこにいて、次に何をすべきか」が明確でした。
作業期間
最終的に、以下の期間で完成しました：
- 台本作成: 業務の合間に作業し、約1週間
- スライド作成: 台本完成後、約3日
正直、初めての経験なので、他のやり方と比べてどれだけ効率的だったかは分かりません。
しかし、「何をすべきか」が明確だったため、本質的な内容のブラッシュアップに集中することができ、社内のレビューでも大きな指摘はありませんでした。
まとめ
カンファレンス初登壇の私にとって、Claude Codeは心強い味方でした。
どう作れば良いか分からないレベルから、ある程度のレベル感まで引き上げてくれたと実感しています。
ただし、忘れてはいけないのは、最終的な確認は一言一句まで自分で行う必要があるということです。
Claude Codeが作ってくれた内容は、あくまでも叩き台です。微妙な言い回しや細かな矛盾は、気をつけないとスルーしてしまいがちです。特に、技術的な正確性や数値データ、自分の経験との整合性は、念入りに確認する必要があります。
実際の登壇では、ガチガチの台本を用意して、しっかり練習して臨んだことが功を奏しました。緊張する場面もありましたが、台本があることで安心感があり、アドリブも挟みながら、20分ピッタリで発表を終えることができました。
この記事が、これから登壇資料を作成する方や、Claude Codeを活用したい方の参考になれば幸いです。
🎄 ZOZO Advent Calendar 2025 シリーズ 1 の 3 日目の担当は、@hiro0218 さんです！お楽しみに！