【レポート】Claude Code Meetup Japan #2 ─ サブエージェントと仕様駆動で加速するAI駆動開発
はじめに
こんにちは、ネクスタで開発エンジニアをしている日野岡です。
2025/8/8に開催された 「Claude Code Meetup Japan #2(Claude Code祭り!#2)」 をオンライン視聴しました。
本記事では、このイベントの各セッションの要点をまとめつつ、AI駆動開発の現在地と未来について考察します。
開催概要
「Claude Code Meetup Japan 2」は、LINE Yahoo株式会社の会場で開催され、多くの参加者がYouTube経由でも視聴しました。特筆すべきは、前回からの継続参加者が半数以下で、新規参加者が多かった点です。これは、Claude Codeというツールへの関心が急速に高まっている証拠と言えるでしょう。
弊社でも最近Claude Codeを導入したばかりなので、各セッションで語られた実践的な知見は、非常に参考になるものばかりでした。各発表の詳細なスライドは添付URLから参照できますので、ぜひそちらもご覧ください。
セッション1: Claude Codeは仕様駆動の夢を見ない
- 登壇者:Gota@Data Analyst氏(@gota_bara)
発表の概要
株式会社フェズの@gota_bara氏による本セッションでは、Claude Codeを活用した開発プロセスの変革と、AWSのAI駆動開発ツール「Kiro」との比較が紹介されました。タイトルの「Claude Codeは仕様駆動の夢を見ない」は、人気アニメのタイトルを引用し、AI開発における「理想」と「現実」のギャップを「思春期症候群」というユニークな言葉で表現しています。
チーム開発での課題(思春期症候群)
AIの導入で実装(How)から仕様(What)へと開発の焦点が移る一方、チーム開発では新たな課題が浮上します。
- 存在忘却症候群:プロダクトの目的や背景がAIに共有されず、意図を汲み取れない。
- タイムループ:要件や受け入れ基準が曖昧なため、手戻りが多く発生し、同じスプリントを繰り返してしまう。
- 記憶リセット:プロジェクトのコンテキストが永続化されず、過去の経緯や決定事項が失われる。
Kiroとエージェント駆動開発(AIDLC)
これらの課題への解決策として、AWSが提唱するAI中心の開発方法論「Kiro」が紹介されました。Kiroは、AIが詳細な作業計画を作成し、人間はフィードバックと意思決定に集中する 「人間の監視によるAIの実行」 と、チームがリアルタイムの問題解決に集中する 「動的なチームコラボレーション」 を重視します。
Claude Code SpecによるKiroの再現
@gota_bara氏は、このKiroの優れたワークフローをClaude Code上で再現した 「Claude Code Spec」 を開発しました。
- 要求定義: 厳格な要求定義手法である EARS記法 を用いて、曖昧な要求を明確な言葉に落とし込みます。これにより、後のテスト自動生成にも繋がります。
- 詳細設計: Claude CodeのWeb検索機能や推論モデル(GPT-5など)を活用し、納得性の高い技術調査を行います。
- タスク分解: 要求の受け入れ基準とタスクを紐づけることで、レビューの負荷を大幅に削減します。
結論と今後の方向性
AI駆動開発を成功させるには、単にツールを導入するだけでなく、開発プロセス全体をAI中心に再設計する必要があります。人間はビジョンや熱意といった「何を創るか」に集中し、その具体化をAIに委ねる。この協業モデルを自社に合わせて構築していくことが、今後の鍵となると締めくくられました。
セッション2: Claude CodeをDevinにしよう - 叩き駆動開発のススメ
- 登壇者:こたにゆうく氏(@yukukotani) CTO@Ubie
現状の課題と「叩き駆動開発」
AIコーディングツールは個人の実装速度を上げましたが、レビュー、テスト、要件定義といった開発プロセス全体で見ると生産性は頭打ちです。このボトルネックを解消するため、こたに氏は 「叩き駆動開発」 を提案します。これは、AIエージェントが人間の指示を待たずに、PBI(プロダクトバックログアイテム)が作成された時点で自動的に実装の「叩き台」を生成するアプローチです。
提案アプローチ:AIエージェント駆動開発
開発プロセス全体にAIエージェントを組み込むことで、以下のような利点を生み出します。
- 認知負荷の軽減: AIがクラウド上で自律的にスケールするため、開発者は複雑なプロセスを意識する必要がありません。
- 見積もりの精度向上: AIが生成した「叩き台」を前提に、より正確なプランニングと見積もりが可能になります。
- 全社的な改善: プラットフォームエンジニアリングとして改善を進めることで、効果が組織全体に波及します。
自社エージェント「Uvin」の実装例
この思想を具現化したのが、Ubie社開発のAIエージェント 「Uvin」 です。Jiraでチケットを作成すると、Uvinが自動で実装を開始し、プルリクエストを生成します。
-
実装の分類と改善サイクル: 生成された実装は以下の3つに分類されます。
- そのままリリース可能
- 軽微な修正で対応可能
- 再実装が必要
-
この分類に基づき、「いかに3を減らし、1と2を増やすか」という視点でプラットフォームチームが継続的に改善を行います。
技術的詳細とDevinとの比較
UvinはGitHub Actionsをベースに、Claude Code Base Actionsを活用して構築されています。特定のAIサービスに密結合しない設計で、将来の技術変更にも柔軟に対応可能です。Devinと比較して、プロンプトエンジニアリングの自由度が高い点や、自社プロセスに合わせたカスタマイズが容易な点が優位性として挙げられました。
得られた効果と今後の展望
AIエージェントが自然に動く開発プロセスを構築することで、生産性を桁違いに向上できる可能性が示されました。重要なのは、Claude Codeのような強力な基盤を使いつつも、インターフェースを自社に合わせて徹底的に作り込むことだと結論づけられました。
セッション3: Claude Codeと始める“自律型プロジェクト運用“
- 登壇者:為藤アキラ氏 BLUEISH 代表取締役CEO兼CTO
Claude Codeの課題とサブエージェント
為藤氏は、Claude Codeを使い込む中で見えてきた課題を指摘します。
- プロンプトの限界: TDDやクリーンアーキテクチャなど、多くの情報をプロンプトに詰め込むと、かえって性能が低下する。
- コンテキストウィンドウの問題: 大量の情報を扱うと、すぐにコンテキストウィンドウの上限やアカウントのリミットに達してしまう。
この課題を解決するのが、2025年7月25日にリリースされた 「サブエージェント機能」 です。
サブエージェントの利点と活用法
サブエージェントは、特定の目的や専門分野の役割を与えられた分身のようなものです。メインのエージェントとは別のコンテキストウィンドウを持つため、以下のようなメリットがあります。
- コンテキストの節約: 専門的なタスクをサブエージェントに任せることで、メインエージェントの貴重なコンテキストを消費せずに済みます。
- 専門知識の活用: 特定のドメイン知識を学習させたサブエージェントを用意すれば、より高度なタスクを処理できます。
- 再利用性と権限設定: 一度作成したエージェントは再利用可能で、「コードレビュー担当にはRead権限のみ」といった柔軟な権限設定も行えます。
Anthropic社の研究によれば、OpusのリードエージェントとSonnetのサブエージェントを組み合わせたマルチエージェントは、単一のOpusよりも90%以上優れた性能を発揮したとのことで、その効果は折り紙付きです。
サブエージェント作成のコツと実用的なアドバイス
作成のコツは 「シンプルに使うこと」 。短い専用プロンプトと、最小限の権限・ツールで設定するのが効果的です。
現状では、要件定義から実装までの全工程を任せるのはまだ難しいものの、テストとレビュー作業の自動化に活用するのが非常に有効だと述べられました。
セッション4: リモート環境(VPS)を活用したClaude Codeの導入と運用
- 登壇者:前島さん@Xserver氏
導入背景とVPSによる解決策
情報管理に厳しい企業では、新しいツールをローカルPCに導入するだけでも多くの許可プロセスが必要となり、導入のハードルが高くなりがちです。Xserverの前島氏は、この課題を VPS(仮想専用サーバー) を活用することで解決しました。隔離されたリモート環境で検証することで、導入プロセスが大幅に簡略化され、申請からわずか1週間で部内展開が完了したそうです。
リモート環境運用のメリット
- 精神的安心感: サンドボックス環境であるため、ローカル環境を汚す心配なく、危険なコマンドも安全に試せます。
- 常時稼働と並行作業: ローカルPCの電源を落としてもAIはVPS上で稼働し続けるため、長時間タスクを任せている間に別の作業に集中できます。
- 環境の共有: 生成したアプリケーションをVPS内にデプロイし、URLを共有するだけで、チームメンバーが簡単にレビューできます。
長時間自律実行を安定させるための工夫
AIに長時間タスクを安定して任せるには、人間が優秀なエンジニアに業務を依頼するような感覚で、環境を整えることが重要です。
-
開発ルールの事前定義:
claude.md
に開発プロセスやルールを明記し、AIが参照できるようにします。 - テスト重視のアプローチ: TDDの考え方を取り入れ、AI自身にテストサイクルを回させることで、品質を担保します。
- プロセス改善への着目: 成果物そのものに固執せず、AIが動くものを繰り返し作る過程でドメイン知識を学習し、開発プロセス自体が改善されていくことを重視します。
お知らせ
イベント参加者向けに、Xserver VPSを約1ヶ月間無料で利用できる案内と、業務向けClaude Codeのスタートガイドが提供されました。
セッション5: hooksのStopをつかって永遠にpbi定義&開発を繰り返させ続けるSingularity的方法
- 登壇者:@t_fujita24氏
発表者と開発環境
バックエンドとエージェント開発を専門とする藤田ともや氏は、エンタープライズ向けリサーチエージェント「KumaKumaAI」を開発しています。neovimとtmuxを駆使し、左画面でClaude Codeに開発を依頼し、右画面のlazygitでレビューするという効率的な開発スタイルを実践しています。
hooksの活用と「シンギュラリティ的アプローチ」
藤田氏は、Claude Codeのhooks機能を徹底的に活用しています。
- フォーマットと通知: Pythonファイルの編集時に自動でフォーマットを適用したり、AIの処理完了をスマホに通知させたりすることで、開発体験を向上させています。
-
無限ループによる自律開発: 特に興味深いのが、エージェントの応答完了時に呼び出される
STOP
イベントフック の活用です。このフックで「続けて」という命令を返すことで、AIに無限に処理を繰り返させることが可能です。
この仕組みを使い、「新機能を自動的に考案し、追加し続ける」という、まさにシンギュラリティ的な実験を行いました。
実験結果と結論
pyxelライブラリを使ったレトロシューティングゲーム開発の実験では、見た目は良いゲームが生成されたものの、実際にはプレイできないという結果に。原因は、Claude Code自身がゲームをプレイしてフィードバックを得ることができないため、問題に気づかずに開発を進めてしまったことでした。
この実験は、AIによる自律的なプロダクト開発の大きな可能性と、「人間による適切なフィードバックループ」の重要性という現在の限界を同時に示す、示唆に富む結果となりました。
セッション6: スクラムイベントの議事録をAIが書く時代 〜Claude Code活用事例〜
- 登壇者:Masaru Furuya氏(@enzerubank)
スクラムマスターの悩みとAIによる解決
EMとスクラムマスターを兼任するFuruya氏は、スクラムの知見が特定の個人に属人化し、組織変更のたびに失われてしまうという課題に直面していました。この課題を解決するため、Claude Codeのサブエージェント機能を活用し、スクラムイベントの議事録作成を自動化するソリューションを開発しました。
AIによるスクラムイベント連携の仕組み
- 議事録の自動生成: デイリースクラムやスプリントプランニングなど、各イベント用のサブエージェントが、AIに与えられたペルソナ(目的、責務、手順)に基づき、議事録を自動で作成します。
- イベント間の情報連携: GitHubプロジェクトのデータを自動で取得し、デイリースクラムの記録からレビューの進捗を更新したり、レビュー内容を次のスプリントプランニングに活用したりと、イベント間での情報連携も実現しています。
学びと効果
- コミュニケーションの質の向上: 人間は面倒な議事録作成から解放され、本質的な対話に集中できるようになりました。
- 属人化の解消: スクラムマスターのペルソナを言語化してAIに与えることで、個人への依存から脱却し、ファシリテーションの持ち回りも容易になりました。
- 陳腐化しないドキュメント: ルールがエージェントに組み込まれ、成果物とセットで出力されるため、ドキュメントが形骸化しにくくなります。
Furuya氏は、「完璧(100点)なAIを目指すのではなく、70点の成果でも運営できる人材が増えること自体が組織にとっての価値だ」と述べ、AIとの協業における重要な視点を示しました。
セッション7: Claudeと一緒に仕様書から実装してみた
- 登壇者:Otonowa Naka氏(@NakaOtonowa)
クリーンアーキテクチャの課題とAI活用
アーキテクトとしてAI駆動開発を推進する中野氏は、高品質だが実装が面倒と敬遠されがちなクリーンアーキテクチャこそ、AIに任せるべきだと考えました。しかし、単純に実装を依頼するだけでは、モデルの不備や設計思想のズレなど、細かな不満点が残ります。原因は 「コンテキスト不足」 でした。
課題解決アプローチ:「対話的モデリング」
この課題を解決するため、中野氏は以下のような対話的なアプローチを取りました。
- ドメインモデルの改善: 自然言語で指示してドメインモデル図をAIに描かせ、 「ここ、集約を分割して」 といった対話を通じて、ホワイトボードで描くよりも速くモデルを洗練させていきます。
- プロジェクト構成の改善: 実際のフォルダ構造を見ながら 「このフォルダは余分」「ここに移動して」 と自然言語で指示し、その指摘をルールとしてAIに記録・学習させます。
メリットと他のAIツールとの比較
このアプローチにより、手間をかけずにクリーンアーキテクチャを実現できるだけでなく、モデル図やルール、実装例といった重要なコンテキストをテキストとして残せるため、機能追加時の精度も向上します。
Devinとの比較では、初回実装はClaude Codeが優れているものの、反復開発やスケーリングではDevinに軍配が上がるとの所感も共有されました。
セッション8: 俺的 instruction の書き方
- 登壇者:さかす氏(@sakas1231)
開発における課題:「雑な指示」と「手動修正」
Canary社でバックエンド開発を担当する赤坂氏は、AIとの協業における2つの大きな課題を挙げました。
- 雑な指示は雑な実装に繋がる: 仕様を曖昧なまま依頼すると、意図しない実装が一度に生成され、手戻りが増える。
- 手動修正がコンテキストに反映されない: 生成されたコードの90%が正しくても、残りの10%を人間が手動で修正すると、その「修正内容」という重要なコンテキストがAIから失われ、次回同じ間違いを繰り返す。
効果的なインストラクション:「対話による仕様書作成」と「差分の反映」
この課題を解決するため、赤坂氏はClaude登場以前から独自の手法を編み出していました。その手法は、後に登場するClaude Code/SpecやKiroのアプローチと驚くほど似ています。
- 丁寧な指示書作成フェーズ: まずAIとの対話を通じて、詳細な仕様書とタスク分解を丁寧に行います。
- 実装とフィードバックのループ: 分解したタスクごとに実装を進め、手動で修正した差分(diff)を随時インストラクションに反映させます。
これにより、インストラクション(AIへの指示書)が常に最新の状態に保たれ、AIが過去の修正から学習し、成長していくサイクルが生まれます。
セッション9: Claude Codeをdotfiles管理しよう!(おすすめの設定を添えて)
- 登壇者:shuntaka氏(@shuntaka_jp)
AI設定の「秘伝のタレ」化問題
クラスメソッドの髙橋俊一氏は、多様化するAIツールの設定が個人の「秘伝のタレ」と化し、チーム内での共有や管理が難しくなっている課題を指摘。この解決策として、Linux文化に根付く 「dotfiles」 の考え方をAIツールの設定管理に応用する手法を提案しました。
dotfilesによる設定管理の具体的な実装
- 設定の共通化: MCP(カスタムプロンプト)やスラッシュコマンドなどをリポジトリで一元管理し、シンボリックリンクを使って各環境に展開します。
- Hooksの管理: 保守性を高めるため、HooksはTypeScriptで記述し、Denoで実行します。
-
機密情報の管理:
secrets.jsonnet
のようなファイルで機密情報を管理し、設定ファイル本体とは分離します。
高度な連携:静的解析ツールとの連携
さらに発展的な使い方として、Stopイベントフックと静的解析ツールを連携させる試みが紹介されました。
- AIがコード生成を完了(Stopイベント)。
- 静的解析ツール(循環的複雑度を検出など)を自動で実行。
- エラーが検出された場合、その内容をAIにフィードバック。
- AIがエラーを認識し、自動でリファクタリング計画を立てて修正する。
この仕組みにより、AIが自律的にコード品質を改善していくループが実現します。ただし、不要なエラー出力がコンテキストを圧迫するという新たな課題も生まれており、試行錯誤中とのことでした。
セッション10: Claude CodeでmacOSのアプリを作ってみた
- 登壇者:wmorioka氏(@watarumorioka)
開発の動機とアプリ「Hivelex」
10年前に一度Macアプリ開発で挫折した経験を持つ森岡氏が、Claude Codeの力を借りてリベンジを果たした話です。開発したのは、開発者向けの便利ツール詰め合わせアプリ 「Hivelex」 (アプリ名もClaudeが提案)。特にカレンダー機能にこだわり、リモート会議での日程調整をスムーズにするための工夫が凝らされています。
Claudeとの役割分担
このプロジェクトでは、人間とAIの役割分担が見事に設計されていました。
- Claude(企画・サポート担当): アプリ名や機能の提案、仕様書のドラフト作成、さらにはApp Storeの申請画面の選択肢へのアドバイスや、アプリ説明文の作成までサポート。
- Claude Code(実装担当): Claudeが作成した仕様書に基づき、黙々とコードを生成。
結果と学び:UIの弱点と段階的構築の重要性
結果として、開発されたアプリはApp Storeの審査に一発で合格しました。
この経験から得られた学びとして、Claude Codeはビジネスロジックのような複雑なコードは得意な一方、UIの構築は苦手な傾向があることが挙げられました。UIを一気に作らせようとすると、レイアウトが崩れることが多いそうです。
結論として、AIの特性を理解し、UIは少しずつ段階的に構築していくアプローチを取れば、個人でも十分にApp Storeでアプリを公開できる、という勇気の出る発表でした。
まとめ
今回のMeetupで浮き彫りになったのは、AI開発の焦点が単なるコード生成から、開発プロセス全体の再設計へとシフトしているという事実です。各セッションに共通していたのは、AIに対して質の高い「コンテキスト」をいかに与え、効果的な「フィードバックループ」をどう設計するかというテーマでした。
これからの開発者に求められるのは、AIに実装を指示するスキルだけでなく、AIが自律的に動作できる仕組みやガードレールを設計する「アーキテクト」としての視点だと感じます。私自身も、仕様書をベースとした開発や、レビュー専門のサブエージェント導入など、学んだことを早速実践に移していきたいと思います。
AIとの協業が当たり前となった今、私たちの挑戦は「いかにAIとの連携を深化させ、開発プロセスそのものを革新していくか」という次のステージに進んでいます。この大きな変革の最前線に立ち続けるため、AIとの関わり方を常にアップデートし続けなければならないと、改めて強く感じたイベントでした。
この記事が、少しでも皆さんの参考になれば幸いです。
Discussion