WinTicket x タップル x SGEマンガ事業部 で 「Coding Agent BEER BASH」を開催しました！

WRITER: 坂上翔悟
このエントリーをはてなブックマークに追加

はじめに

こんにちは！株式会社タップル技術本部でAIチームのリーダーをしている坂上（@tosaka07）です。普段は、AIを活用した業務効率化や、AI技術のプロダクトへの応用をサポートしているチームのリーダーをしています。

2025年7月1日に「LGTM Tapple x WinTicket Coding Agent ビアバッシュ with SGEマンガ事業部」を実施しました。今回はこのイベントの内容をレポートとしてご紹介します。

LGTM って？

今回のイベントは、サイバーエージェント内の技術者交流パッケージ「LGTM（Let’s Gather To MIU）」の一環として実施されました。「MIU（ミュー）」とは、FY2025からの新セグメント「メディア＆IP事業部」の略称です。

趣旨

株式会社タップル、株式会社WinTicket、SGEマンガ事業部（WEBTOONのアプリケーションおよびウェブサイトを運営する事業部）の3社合同で開催しました。

この会では、SGEマンガ事業部から降矢大地（@wasabeef_jp）さんと國師誠也（@ronnnnn_jp）さんをお招きし、事業内外でどのようにコーディングエージェントを駆使しているのか、その具体的な活用事例について語っていただきました。本記事では、その発表内容から特に印象的だった部分をピックアップしてご紹介します。

1. 降矢大地さん「AI Agent時代の開発スタイルと必要なスキル」

最初のセッションでは、降矢大地さんが登壇し、AIエージェントの登場によって開発スタイルがどのように変化し、エンジニアにはどのようなスキルが求められるようになるのかについてお話しいただきました。

去年までの働き方とこれからの時代

降矢さんはまず、AIエージェント登場以前の、いわゆる「従来の開発スタイル」が抱えていた課題を振り返りました。

  • 手動でのコード記述（+Copilotでの補完）
  • Stack Overflowなどでの検索
  • ドキュメントの深い理解
  • 時間をかけたデバッグ

これらのタスクはエンジニア個人の経験や能力に大きく依存しており、生産性のばらつきや限界を生む一因となっていました。また、繰り返し発生する作業の多さや、新しい技術の学習コストの高さも、開発者にとって大きな負担でした。

これに対し、AIエージェントが浸透する新しい時代では、単にコードを生成させるだけじゃなく、プロンプトエンジニアリングを基礎技術として使いこなし、様々な特性を持つAIモデルをどう選定し、どう組み合わせるかが、価値を生む上での重要な鍵になると指摘しました。

AI Agent時代の新しい開発スタイル：「波乗り」と「並列開発」

ここで特に共感したのは「波に乗り続ける」という表現でした。SNSでみんながAIの登場を転換期だと認識して、とにかく触って、活用するためのツールを作ってを繰り返している状況を「波」と捉え、それに乗っかったり、自分で波を作ったりしていこうという考え方です。

もう一つ、「並列」という言葉も強く印象に残りました。チームに対して「最低3並列、欲を言えば5並列で（ブランチを持って）開発を進めよう。これらができないと今の時代、AIを使ってるとは言えない」と伝えているそうです。チームや組織として具体的な数値目標を掲げ、AI活用のモチベーションを高めている点が最も印象に残る内容の一つでした。

プロンプトから「コンテキストエンジニアリング」の時代へ

これからのAI活用は、単発の優れたプロンプト（指示）を考える「プロンプトエンジニアリング」から、いかに質の高い「コンテキスト（文脈）」をAIに与えるかという「コンテキストエンジニアリング」の時代に進化しています。

ここでいうコンテキストとは、以下のような情報です。

  • プロジェクト固有の知識
  • チームのコーディング規約
  • アーキテクチャの設計方針
  • サービスのドメイン知識

例えば、パフォーマンスチューニングを行う際にも「このサービスは縦型漫画サービスだからこそ、画像の読み込みパフォーマンスをこのように最適化すべきだ」といったドメイン知識に基づいた具体的な指摘をAIから引き出すには、より的確なコンテキストを渡さないとできないと言っています。

SGEマンガ事業部では、このコンテキストエンジニアリングを実践するために、GitHubリポジトリの docs/ ディレクトリに情報を集約しています。READMEはもちろん、docs にアーキテクチャ設計の思想（なぜ一般的なMVVMを採用しなかったのか、など）や環境構築の手順までを詳細に文書化。これによって、新しく参加したメンバーだけでなく、AIエージェントにとっても有用なオンボーディング資料として機能していました。

また、トラブルシューティングのナレッジ管理も Claude Code に任せており、過去に発生した「GraphQLのコード生成エラー」などの問題について、その症状や環境、再現手順、最終的な解決方法までをまとめて、 troubleshooting.md のようなファイルに記録させていました。

CI/CDとの連携によるレビュープロセスの自動化

コンテキストの提供は、PR（Pull Request）のレビュープロセスでも徹底されていました。

Conventional Commitの規約に則り、コミットメッセージに feat: や update: がついているPRに対して、自動的にDevinによるレビューが実行される仕組みを構築。 さらに、VRT（Visual Regression Testing）の結果や、Copilot Review、CursorのBugBotからの指摘、関連するNotionドキュメントの情報などを、GitHub Actions経由で自動的にPRコメントとして集約します。

特に、DevinはNotionのリンクを直接解釈できないため、Actionsでドキュメントの中身を取得し、PRコメントに展開してからDevinに読ませるという工夫も行われています。結果、Devinは豊富なコンテキストを元により精度の高いレビューを行うことができる、という感じです。

DevinはMCPに対応したので、権限などを適切に管理できている組織であればMCPを使いましょう。

レビュー結果の表示方法も印象的で、総合評価（点数）、指摘事項の分類（must, imo, nits, q）、マージ可否の判断、さらにはAIレビュー自体の自己評価（「この情報が足りなかった」など）まで出力され、人間が最終判断を下しやすいように工夫されていました。

「自律」と「計測」によるパフォーマンス改善

続いて、自律的に実装と修正を繰り返させる自動化について、例を交えながら紹介されました。

ある時、アプリの起動時間に課題があった際、まず「オンボーディング画面が表示されるまで」を起動時間と明確に定義。 その上で、FPSの低下やメモリ使用量といった複数のメトリクスを計測する仕組みを実装しました。

そして、AIに対し「現状の起動時間5200msを3000ms以下にしなさい」というゴールを設定し、ひたすら修正ループを回させたそうです。

ここで重要なのは命令の具体性です。命令が曖昧だと、AIは必要な初期化処理をすべて削除して「速くなりました」と報告してくる場合もあるため、それは具体性のない命令側に問題があるとのこと。そうならないよう、計測すべきチェックポイントを明確に定義し、何を維持しつつ何を改善するのかを的確に指示することが、自律エージェントを使いこなす上で不可欠だと語っていました。

Claude Codeをより便利に使うための工夫

普段から行う冗長な作業をできるだけコマンドに落とし込むようにしています。

例えば、 Claude Code に一定の専門家の視点を持たせてレビューなどを行うことで、より品質の高いコードを生成させることができます。セキュリティとパフォーマンスの専門家に議論させたり、アーキテクトにレビューしてもらったり、議論を俯瞰して見ているような感覚です。

以下のリポジトリにあるカスタムコマンドをチームに導入しています。

https://github.com/wasabeef/claude-code-cookbook

サンプルコードでの実行例


$ /role-debate security,performance

「API レスポンスタイムを改善したいが、セキュリティも重要」

⏺ ロール議論: Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

議題: API レスポンスタイムを改善したいが、セキュリティも重要

Phase 1: 初期立場表明

【Security Expert】の推奨案:
「全 API エンドポイントに Rate Limiting、暗号化、入力検証を必須化」

根拠:
- OWASP API Security Top 10 2023 準拠
- 2023 年の API 攻撃は前年比 681% 増加（Salt Security Report）
- ゼロトラストアーキテクチャの原則

懸念事項:
- パフォーマンス最適化による検証スキップは致命的
- キャッシュ実装時の認証バイパスリスク
- 並列処理による競合状態の脆弱性

成功指標:
- セキュリティインシデント発生率 < 0.01%
- 脆弱性スキャンで Critical/High: 0 件
- コンプライアンス監査 100% 合格

【Performance Expert】の推奨案:
「キャッシュ戦略とデータベース最適化でレスポンス 50% 改善」

根拠:
- Google の研究: 100ms 遅延で売上 1% 減少
- Core Web Vitals: LCP < 2.5 秒が必須
- 現状分析: DB クエリが全体の 70% を占める

懸念事項:
- 過度なセキュリティ検証で 3 倍のレイテンシ
- Rate Limiting による正当なトラフィック制限
- 暗号化/復号化の CPU オーバーヘッド

成功指標:
- P95 レスポンスタイム < 200ms
- スループット 10,000 req/s 達成
- CPU 使用率 < 70% 維持

Phase 2: 相互議論・反駁

Security → Performance:
「キャッシュによる情報漏洩事例多数。2022 年の Cloudflare 事件では 750 万ユーザーが影響」

Performance → Security:
「適切なキャッシュキー設計で回避可能。CDN エッジでの検証により両立できる」

Security → Performance:
「エッジセキュリティは複雑性を増し、設定ミスのリスクが上昇」

Performance → Security:
「段階的セキュリティレイヤーを提案。public API は軽量検証、sensitive API は完全検証」

Phase 3: 妥協点探索

共通理解:
- ビジネス継続にはセキュリティとパフォーマンス両方が必須
- リスクベースアプローチによる最適化が現実的
- 継続的な監視と改善が不可欠

Win-Win 要素:
- セキュリティヘッダーのキャッシュ（静的検証）
- 非同期セキュリティログ処理
- スマート Rate Limiting（AI 異常検知）

Phase 4: 統合結論

統合解決案:
「リスクベース 3 層セキュリティ + インテリジェントキャッシング」

実装詳細:
1. Public 層（低リスク）:
   - 30 秒キャッシュ + 基本 Rate Limiting
   - レスポンス目標: 50ms

2. Protected 層（中リスク）:
   - 5 秒キャッシュ + JWT 検証
   - レスポンス目標: 100ms

3. Sensitive 層（高リスク）:
   - キャッシュなし + 完全検証
   - レスポンス目標: 200ms

段階的実装:
- Week 1-2: リスク分類と API 仕分け
- Week 3-4: Public 層の最適化実装
- Month 2: Protected 層の実装と検証
- Month 3: 全体最適化と負荷テスト

成功指標:
- セキュリティ: ゼロブリーチ維持
- パフォーマンス: 平均レスポンス 40% 改善
- 可用性: 99.95% アップタイム

将来の見直し:
- 月次: セキュリティログとパフォーマンスメトリクス評価
- 四半期: 新たな脅威とパフォーマンス要件の再評価

並列実行になっている状態を把握する為の工夫

最後に、降矢さんが意識する「並列実行」をどう視覚的に分かりやすく表現するかについて、工夫が紹介されました。

ターミナルエミュレータ「Wezterm」は、設定ファイルをLua言語で記述することで、ステータスバーなどを柔軟にカスタマイズできます。これを活用し、Claude Codeのプロセスやファイルディスクリプタを監視して、 エージェントが稼働中であればアイコン（例：⚡）を、停止中であれば別のアイコン（例：🤖）を表示させることで、現在いくつのタスクが並列で処理されているかを一目で把握できるようにしていました。

この設定ファイルは、降矢さんの公開dotfilesリポジトリで実際に確認することができます。

https://github.com/wasabeef/dotfiles/blob/main/dot_wezterm.lua

2. 國師 誠也「チーム全体でのAI活用とワークフロー自動化」

続いて、國師 誠也さんが登壇。チーム全体で AI を効果的に活用するためのドキュメント管理方法やプロンプトの共有、そして n8n や各種ツールを連携させたワークフローの自動化について、具体的な事例を交えながら解説しました。

チーム全体でのAI docs管理方法

SGEマンガ事業部では、shared-workflows というリポジトリを用意しています。

このリポジトリでは共通の設定ファイルやワークフロー、スクリプトを管理しており、更新があると各リポジトリに配布される仕組みです。

現時点で各種 AI ツールのルールやコマンドの管理場所やファイル形式は標準化されていません。チーム内で複数のツールが利用されている場合、各ツール向けに似たようなドキュメントを複製しないといけないという課題があります。

これを解決するために、一つのドキュメントから各ツール向けに最適化したドキュメントを生成するスクリプトを shared-workflows で管理しています。

これを各リポジトリに配布することで、AI ドキュメント管理の課題を解消しています。

prompt リポジトリの活用

AI ツールの中にはリポジトリでドキュメントを管理しづらいものもあります。

例えば Devin は、 Playbook や Knowledge がコンソール上にのみ存在し、バージョンという概念もないため、どの指示でうまく動いた、動かなかったという因果関係が分かりにくいです。この課題を緩和するアプローチとして、それらのプロンプトを prompt というリポジトリで管理しています。

例えば、一般的なコードレビューを行うものや、renovate が作成した PR に対して安全に依存を更新できるかレビューするプロンプトがあります。

ワークフロー自動化ツール「n8n」の活用

SGEマンガ事業部では、ノーコード・ローコードのワークフロー自動化ツール「n8n」を導入しています。

Devin と Linear の連携において、Linear から Devin を発火させようとした時の通知に課題があり、それを解消するために n8n のワークフローを用意しています。

このワークフローでは、次のステップが実行されます。

  1. Linear の issue コメントを webhook で検知
  2. Devin がコメントする行動計画かどうかをフィルタ
  3. issue コメントから、「行動計画のサマリ」「行動計画の詳細」「実行する際に Devin に渡るプロンプト」を抽出して Slack に送信

このワークフローの過程で AI は使用していませんが、ツール間の連携をよりシームレスにすることで、AI ツールの利用ハードルを下げる狙いがあります。

ai-inference (GitHub Models)の活用

https://github.com/actions/ai-inference

GitHubが提供する ai-inference アクションは、無料で GitHub Models（LLM）を利用できるため、簡単な要約や翻訳タスクに活用しているそうです。活用例として、Terraform の plan 結果を要約し、PRにコメントとして投稿するといった使い方があります。ただし、無料である一方、レート制限があるため、軽量なタスクでの利用が推奨されます。

まとめ

今回のビアバッシュでは、AIエージェントを単なるコーディング補助ツールとしてだけでなく、チーム開発全体のプロセスに組み込み、生産性を飛躍的に向上させるための取り組みがたくさん紹介されました。

特に自分が感銘を受けたのは、「並列」を常に意識し続けること、モバイルアプリはサーバーよりも計測の難易度が高いが、一つひとつ丁寧に解決してコンテキストや自動化に寄与していることでした。

文脈を過不足なく渡すことがこれからのAI開発に不可欠で、どれだけ土台を固められるかが鍵になると強く感じました。

先日弊社から発表された「エンジニアの開発AIエージェント活用に年間約4億円投資します！」にもあるように、AI エージェントの台頭は、間違いなくエンジニアがプロダクトに貢献できる価値のスケールを大きく変えようとしています。この変革の波を後押しするように、サイバーエージェント全体としてもAI活用を強力にサポートする体制が整っています。

このような会社全体のサポート体制のもと、組織の壁を越えてつながり、集合知としてさらに活用していけるよう、今後も勉強会などを通じて知見を共有していきたいと思います。

チームでどれぐらい AI を利用しているか可視化する「tosage」
次の記事