CA Tech JOB 参加記録【極予測やりとりAI】

はじめに

こんにちは！電気通信大学大学院 情報理工学研究科 修士1年の南村栞多と申します。2026年5月の1ヶ月間、AI事業本部の「極予測やりとりAI」チームで、就業型インターンシップ「CA Tech JOB」に参加しました。

「極予測やりとりAI」は、クリエイティブ制作・入稿フローにおける確認作業を AI で効率化するプロダクトです。サイバーエージェント社内だけでなく、広告主企業とサイバーエージェント間の確認作業も対象としています。

「極予測AI」や「極予測TD」と呼ばれる広告クリエイティブ作成 AI が作った広告をやりとり AI に送信し、顧客または審査 AI による審査後に承認を経て各プラットフォームへ入稿する流れになっています。従来この入稿作業は人の手で行われていましたが、やりとり AI ではこの作業を自動化する「自動入稿機能」の開発を行っています。

やりとり AI の詳細については、こちらの記事もご覧ください！

インターンで取り組んだタスク

今回のインターンでは、はじめに「このインターンでどんなことを学びたいか / 成長したいか」について確認する場を設けてもらい、その中でどんなタスクに取り組みたいかを決めさせていただきました。今回はパフォーマンスチューニングや改善系のタスクをやってみたい、という感じでふわっとした要望を伝えたところ、いくつかタスクを用意していただきました。その中で特に印象に残っているタスクをピックアップしてお話しします。

納品の Slack 通知のトランザクション構造の再設計

広告クリエイティブをクライアント企業に納品する際、やりとり AI の管理画面から納品ボタンを押すと、クライアント先の Slack チャンネルに通知が届き、その広告を承認するかどうかの審査を行う流れになっています。この通知処理のトランザクション構造に問題があったため、再設計を行いました。

旧設計では、納品ボタンを押すと DB トランザクション内で Slack API を同期的に呼び出しており、Slack の応答が遅れるだけでユーザーが十数秒待たされ、障害時には配信ステータスの変更ごとロールバックされるという問題がありました。外部通信中も行ロックを握り続けるためロック競合のリスクもあり、さらにスレッド ID のバリデーションが NULL チェックのみだったために空文字列が通過して通知の消失や誤送信も起きていました。これらは個別のバグではなく同期処理という設計方針そのものに起因する構造的な問題だったため、非同期処理への転換が必要と判断しました。

必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等) は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:

{"translation": "## はじめに\n\nこんにちは！電気通信大学大学院 情報理工学研究科 修士1年の南村栞多と申します。2026年5月の1ヶ月間、AI事業本部の「極予測やりとり AI」チームで、就業型インターンシップ「CA Tech JOB」に参加しました。\n\n「極予測やりとり AI」は、クリエイティブ制作・入稿フローにおける確認作業を AI で効率化するプロダクトです。サイバーエージェント社内だけでなく、広告主企業とサイバーエージェント間の確認作業も対象としています。\n\nimage\n\n「極予測 AI」や「極予測 TD」と呼ばれる広告クリエイティブ作成 AI が作った広告をやりとり AI に送信し、顧客または審査 AI による審査後に承認を経て各プラットフォームへ入稿する流れになっています。従来この入稿作業は人の手で行われていましたが、やりとり AI ではこの作業を自動化する「自動入稿機能」の開発を行っています。\n\nやりとり AI の詳細については、こちらの記事もご覧ください！\n\n## インターンで取り組んだタスク\n\n今回のインターンでは、はじめに「このインターンでどんなことを学びたいか / 成長したいか」について確認する場を設けてもらい、その中でどんなタスクに取り組みたいかを決めさせていただきました。今回はパフォーマンスチューニングや改善系のタスクをやってみたい、という感じでふわっとした要望を伝えたところ、いくつかタスクを用意していただきました。その中で特に印象に残っているタスクをピックアップしてお話しします。\n\n## 納品の Slack 通知のトランザクション構造の再設計\n\n広告クリエイティブをクライアント企業に納品する際、やりとり AI の管理画面から納品ボタンを押すと、クライアント先の Slack チャンネルに通知が届き、その広告を承認するかどうかの審査を行う流れになっています。この通知処理のトランザクション構造に問題があったため、再設計を行いました。\n\n旧設計では、納品ボタンを押すと DB トランザクション内で Slack API を同期的に呼び出しており、Slack の応答が遅れるだけでユーザーが十数秒待たされ、障害時には配信ステータスの変更ごとロールバックされるという問題がありました。外部通信中も行ロックを握り続けるためロック競合のリスクもあり、さらにスレッド ID のバリデーションが NULL チェックのみだったために空文字列が通過して通知の消失や誤送信も起きていました。これらは個別のバグではなく同期処理という設計方針そのものに起因する構造的な問題だったため、非同期処理への転換が必要と判断しました。\n\nimage"}

このようにトランザクション内に Slack API への HTTP 通信が発生し、Slack API のレイテンシに直接依存する構造になっていました。実際に本番環境の Datadog のメトリクスを参照すると、chat.postMessage 呼び出し中に context canceled が発生し、レイテンシが 8,000ms〜10,000ms に達する事例が過去に起きていました。

そこで、以下のようなトランザクション処理に再設計しました。

再設計後は、リクエスト処理と Slack 通信を担うバッチ処理を完全に分離しています。納品ボタンを押すと API は DB の配信ステータスを更新し、Slack への送信ジョブを通知キューnotice_queueに登録した後、Slack を呼ばずに即座にレスポンスを返します。

Slack への通知は毎時バッチが担い、通知準備バッチ（notice バッチ）が送信先リストを作成し、Slack 送信バッチ（notice_slack_external バッチ）がスレッド作成・スレッド ID 保存・通知送信を順に処理します。スレッド未確立の状態で非納品通知だけが存在する場合は RetryableError として次のサイクルで再処理します。

Slack 送信バッチが確立したスレッドIDは、その後クライアントが広告を審査する際の承認・コメント通知を同一 Slack スレッドへ返信するために使われます。そのため、スレッド ID の判定も NullString.Valid から hasDeliverySlackThreadID（空文字列を正しく除外するチェック）に切り替えています。旧設計では NullString.Valid が空文字列でも true を返すため、スレッド未確立の状態で Slack API が呼ばれてしまうバグがありましたが、この修正によって空文字列を未確立として正しく扱えるようになっています。

この再設計により、納品操作のレスポンスが Slack の応答速度に左右されなくなり、障害時にも配信ステータスが失われることなく、Slack 復旧後のバッチサイクルで通知が確実に届く構造になっています。行ロックの保持時間が短くなることでロック競合も解消され、スレッド ID のバリデーション修正と合わせて通知処理全体の信頼性が向上しています。

学び

Datadog MCP が便利

今回の開発を通じて、Datadog MCP の利便性を強く実感しました。トレーナーの方から「Datadog MCP を使えば、Web UI を開かなくても必要なログ・メトリクス・トレースを直接取得できる」と教えていただき、実際に活用してみると、その効果は想像以上でした。

今回は Datadog を初めて触ったこともあり、当初は Web UI から目的の情報を探し当てるまでに時間がかかっていました。どのダッシュボードを見ればいいか、どのクエリを書けば求めているメトリクスが取れるかがわからず、情報収集だけで多くの時間を費やすことがありました。しかし Datadog MCP を使うことで、「過去 1 ヶ月のレイテンシを環境ごとに比較したい」といった調査を素早く行えるようになりました。

特に、複数のサービスにまたがるパフォーマンス調査においては、Web UI 上で手動で条件を絞りながら確認していた作業が、MCP（Model Context Protocol）経由のツール呼び出し一つで完結するケースが多く、開発サイクル全体のスピードが大きく向上しました。Datadog のような可観測性（Observability）ツールと AI エージェントを組み合わせることで、調査・分析・改善のループが格段に回しやすくなると感じており、今後の開発でも積極的に活用していきたいと思います。

チームリーダーの方の立ち回り

私のトレーナーを担当していただいた方は、チームリーダーとして長くプロダクトを牽引してきた方でした。私が参画したタイミングは、そのリーダーシップをちょうど新卒 2 年目のエンジニアの方へ段階的に委譲していくという転換期にあたっており、貴重な場面に立ち会うことができたと感じています。

その新卒 2 年目の方が参加するプロダクトの定例会議にも同席させていただく機会があったのですが、そこで印象に残ったのは、設計の議論への積極的に関与する姿勢でした。ただ意見を述べるだけでなく、「この認識で合っていますか？」「この点について全員の理解を一致させておきたい」という形で、曖昧なまま話が進みそうな箇所を丁寧に拾い上げ、認識の齟齬や不明点を確実に潰そうとする姿勢が一貫していました。

チームで開発を進めていく上で、技術的な判断力はもちろん重要ですが、それと同じくらい「全員の認識を揃える」というコミュニケーション面のリーダーシップが大切だということを、間近で学ぶことができました。設計の議論では、声の大きさや年次に関係なく、論点を整理しながら参加者全員が納得できる結論へ導いていく姿は、自分が今後チームの中で動いていく上での良いロールモデルになりました。

チームメンバーの方々との関わり

業務面での学びはもちろんですが、チームの皆さんとの人間的な関わりも、このインターンを通じて大切な経験の一つになりました。入社初日には Welcome ランチをご馳走していただき、初日から温かく迎えていただいたことで、業務にも早く馴染むことができたと感じています。

最終日にはお疲れ様会まで開いていただき、1 ヶ月間の振り返りをチームの皆さんと一緒にでき、インターンの締めくくりとして充実した時間を過ごせました。こうした業務外での関わりを積極的に設けていただいたおかげで、チームの雰囲気や文化をより深く感じることができ、単なる業務体験以上の充実した時間を過ごすことができました。

さらに、インターン終了後には、記念品として技術書 2 冊のプレゼントまでしていただきました。いただいた本は今後の学習にも活かしていきたいと思っています。

まとめ

このインターンを通じて、既存プロダクトの改善タスクに継続的に取り組む中で、改めて気づいたことがあります。それは、プロダクトを長期にわたって運用していくにあたって、「この改善はやるべきか、やらないべきか」というトレードオフを常に意識しながら判断を積み重ねていくことの重要性です。

技術的に正しい改善であっても、工数・リスク・優先度・チームの状況によっては今すぐ着手すべきでないケースもあります。逆に、地味に見える改善でも、長期的な保守性やパフォーマンスに大きく効いてくるものもあります。そうした判断を日々積み重ねていくのが、実際のプロダクト開発の現場なのだということを、1 ヶ月間のインターンを通じて肌で感じることができました。

インターン前は「実装できること」に意識が向きがちでしたが、インターン後は「何を・なぜ・いつ改善するか」という視点も持てるようになったと感じています。

おわりに

トレーナーとして技術面・業務面の両方から丁寧にサポートしていただいたエンジニアの方、技術的なマネジメントの観点から多くのアドバイスをいただいたエンジニアの方、人事の方、そして日々の業務でお世話になったやりとり AI チームの皆さん、本当にありがとうございました。

1 ヶ月という短い期間でしたが、技術的にも人としても多くのものを得ることができました。改めて、1 ヶ月間本当にありがとうございました！