電通総研、秋のキャリア祭り！！（t-wadaさん、中山ところてんさん講演）

キャリア祭りとは？

こんにちは。電通総研の金融IT本部の上野です。
普段の業務ではアーキテクトとして案件に関わる一方で、近年は生成AIを用いた開発生産性の向上についても力を入れて検証を行っております。

さて、10月に電通総研の社内イベントとして「キャリア祭り2025」なるイベントが開催されました。

以下が開催概要の引用となります。

「キャリア」という言葉は難しく捉えられがちですが、その根幹は道であり人生そのもので、皆が当たり前に持っているものです。そのキャリアが「自分らしくある」というのがポイントであり実に難しい点です。「自分らしい」とは、「自分らしい人生」とはなにか、「電通総研人としてなにがしたいか」キャリア祭りでそのヒントをみつけてください。

おそらく、「いろいろな人の話を聞いたり、自分と向き合ったりする中で、今後どのようなキャリアを歩んで行くかを考えてほしい」という、かなりふわっとした理解ですが、そういった意図があったのではないかと思います。

そのイベントの中で、ビッグネームの方が来社されてお話を聞く機会がありました。
講演内容としては以下のとおりです。

• 『t-wada』さん：「AI時代のソフトウェア開発を考える」
• 『中山ところてん』さん：「広聴AI技術解説 ブロードリスニングを支える技術」
  

それぞれパブリックに公開されている資料ではありますが、生の声を聴きながら、また質疑等も行い、いちエンジニアとしてとても刺激的な講演でした。受講者の反響もとても大きいものでした。
電通総研で働くエンジニア、アーキテクトとしての今後のキャリアを考えていくきっかけとなりましたので、僭越ながら、こちらの講演を聞いたうえでの感想・現業における考え方などについて共有できたらなと思います。

AI時代のソフトウェア開発を考える（t-wadaさん）

こちらは、7月頃に初版が公開された資料を更新されたものです。パブリックに公開されているため、内容を知っている人も多いのではないでしょうか。

要約

1. 2025年は「Vibe Coding」熱

• AIエージェントと強力なコード生成により動くものが出来上がるまでが爆速化。多くの人が動作確認だけで前に進み、コードレビューや設計の吟味が省かれがちという状況認識がイントロダクション。ポイントは以下のとおりであり、ソフトウェア開発の道具が変わっただけで本質的な問題は何も変わっていないという点が重要。
• 技術的負債の積み上がる速度が速くなっただけで、負債をためないアーキテクチャがソフトウェア開発として重要なのは変わっていない。
• レビューが課題となることは以前からの課題であり、新たに顕在化したものではない。
• 適切なドキュメントを書けばコーディングは些細な問題というのは新たな考えではなく、これまで様々なツールの登場・衰退とともに何度も議論されてきた。

2. “Agentic Coding”の提案（スピード×健全性の両立）

• AI自走型の領域と、AI伴走型の領域を明確にすること。
  • AI自走型の領域では、並列で実行するためスピードは上がるが、人のコントロールや状況把握が難しくレビューが課題となる。業務ロジックが複雑でない領域はこのやり方。
  • AI伴走型の領域では、人がコントロールする領域が大きく、スピードは落ちるが直列に開発を進める領域。ドメインに特化し、ビジネスの中核となる領域ではこのやり方。

3. 自動化（automation）から自働化（autonomation）へ

• AI伴走型、AI自走型どちらの領域でも、AIは暴走／迷走する。そのためのガードレール設計が不可欠となる。
  • ガードレール技術としての適応度関数の重要性、その代表例としては自動テストがより重要に。
  • 包括的な構成管理では、現在から近い将来はモノレポが有利であり、ドキュメントの同一リポジトリによる管理が重要。
  • Unknown-Unknown領域が増えるため、バグゼロ信仰から離れ、MTBFからMTTRへ切り替える。
  • レビュー負荷軽減の工夫として、Behavior ChangeとStructure Changeを明確にする。
• こうした枠組みで“動く速さ”に“正しさ・保守性”をのせるべき。

4. 現場でどう使うか？またエンジニアはどうこの時流に立ち向かっていくべきか

• AIの活用
  • ここまで記載してきたように、開発に取り入れるにしてもガードレール設計を行ったうえでの開発が必要。そのためにはソフトウェアエンジニアリングが不可欠。
  • outputを出すためだけではなく、自分の能力を上げるためにもAIを利用する。
• エンジニアとしてどう立ち向かっていくべきか
  • AIは知識の代替ではなく増幅器であり、AIから引き出せる性能は自分の能力にそのまま比例する。
  • AIに賭けるのではなく、自分の能力を上げることは必然的に必須。あえてのオーガニックコーディング、AIを用いた議論。

感想

さて、要約といいつつ重要なポイントが多いため熱くなって色々書いてしまいました。
というのは、まさに今年は変化の大きい年であり、現業のやり方や顧客から求められるものも大きく変化したと感じていた中で、すっと腹に落ちる内容だったためです。

現業でどう取り組んでいくか

私は現業ではM5というマイクロサービス用のフレームワーク開発を行っており、生成AIが登場する前も「ソフトウェアエンジニアリングの領域」の観点で、開発のレバレッジおよび保守性の向上のためにDDDや自動テストに取り組んでいました。

生成AIの登場により、「より開発生産性が高くなるためにはどうすればよいか？」を日々検討していました。
今回の講演を拝聴し、以下の観点で取り組んでいこうと考えています。

（1）これまですでに敷いていた「ガードレール」をAIネイティブにブラッシュアップし、より効果的な安全対策を実現することで特に「AI自走型」領域における開発速度を向上させる。

• 構成管理をモノレポに変更
  • AIが理解できるコンテキストを身近に配置し、ドキュメントから実装まで一気通貫で行えるような管理体制が必要となります。
• ドキュメントをこれまで以上にMarkdownで記載
  • 例えばバックエンドであれば、インターフェースの定義（OpenAPI Spec等）、DBの定義（ER図）をExcelではなくAIが理解できる形にします。ER図はmermaidでは保守性がいまいちになることもあり、現在模索中です。
  • 業務ドメインが少ない領域でも、ユビキタス辞書による単純なエラーハンドリングは必要です。OpenAPI SpecとJSON Schemaの統合により、インターフェース設計から単項目バリデーションの実装までを一気通貫で行います。
• アーキテクチャをより明確に
  • DDDやクリーンアーキテクチャというワードは思想でありアーキテクチャレベルでは曖昧であるため、DDDのうち採用している要素をAIに理解させるために明確にレイヤ化されたアーキテクチャを明記する必要があります。これまでは人が読むために図式化して記載していたアーキテクチャを、Agentが理解できるように書き換えていきます。
• 実装の手順・テストの手順をより明確に
  • 例えばClaude CodeであればCLAUDE.mdに、実装手順・テスト手順を明確に指示することが必要になってきます。これまで規約として管理してきた実装手順では、ドメインの実装→ドメインのテスト→プレゼンテーション層→プレゼンテーション層のテストと進むことで、低レイヤから品質を担保しながら実装を進めることができています。これを、Agentに理解できるように書き換えていきます。

以下が、CLAUDE.mdの例として開発手順を記載した例です。

## Development Process

### Layered Development Order

**IMPORTANT**: When implementing a new feature, ALWAYS follow this development order:

1. **Domain Layer** → 2. **Infrastructure Layer** → 3. **API Layer**

This order ensures that:
- Business logic is validated first without external dependencies
- Database operations are tested before exposing them via API
- The complete feature is built on a solid, tested foundation

### Step 1: Domain Layer (No Side Effects)

**Implementation Order:**
1. Value Objects (`domain/value/`)
   - **String-based**: Extend M5 framework base classes
...略

（2）「AI伴走型」領域では、人間がAIを活用しやすい環境を整備する。

• AIによるレビューはマスト
  • twadaさんも「コーディングが開発のボトルネックだったことはなく、いつもボトルネックはレビュー」とおっしゃっていましたが、レビューの負荷を下げていくことは必須です。例えばGitHub Copilotによる一次レビューにより、人がこれまで判断していたtypoやコメントの誤記、不要な変数などを除去してくれます。linterやformatterの整備は当然ですが、そのうえでコードの可読性や保守性を高めるための細かな改善点まで指摘してくれるため、併用することでレビュワーの負荷を下げます。
• 設計伴走
  • 新規に採用するOSSやテスト手法（利用ツール）の変更など、ARDとしてAIと議論、決定。
  • （業務ドメインが複雑な領域について）伝えた要件からMarkdownを記載し、人の手で最終的にFIXさせる。フォーマットは人間の手で整備し、準拠させる。
• テスト伴走
  • 自身が大量に書いていたJUnitやテストデータについて、コードから検証すべき内容を自動生成し、テストコードの作成を効率化。
  • 逆に、詳細設計からテストコードを出力し、TDDの手法によりグリーンになることを人間とAgentが並走して解消する。最初からテストコードを全量作成するのは不可能なので、漏れているケースについては追加し、レッド→グリーンのサイクルを回す。
• ナレッジの蓄積
  • ここまでの運用で失敗した内容を、逐次AIが理解できるドキュメントに再度追記する運用の定義。

総括

書いていて感じましたが、今までソフトウェアエンジニアリングとしてやってきたことと大きくは変わりません。これらを、AIネイティブに変更していくだけです。また、このガードレールを整備していくには自身のスキルを向上させることが必須となります。
AIにすべてベットするのではなく、自身のスキル向上をAIによってサポートしてもらいながら、現業で利用できるところは利用していこうという欲張りな感想を記載して締めとします。

広聴AI技術解説 ブロードリスニングを支える技術（中山ところてんさん）

こちらも、すでに公開されている資料をもとに講演していただいた内容です。
ところてんさんは広聴AIの開発に関わっており、広聴AIの技術要素の説明を行っていただきました。

要約

1. 広聴AIとは（背景と目的）

• デジタル民主主義2030が開発するOSSの意見可視化・分析（ブロードリスニング）基盤。市民の自由記述を“論点単位”に分割し、多様な意見（少数意見も含む）を俯瞰できるようにする。東京都の政策検討などでも活用が進んでいる。
• 本資料の狙いは、普通のプログラマでも理解できる技術水準で、ベクトル化・LLM次元圧縮・クラスタリング・ラベリングのつなぎ方を解説すること。

2. 処理パイプライン*

• 抽出（意見分割）：長文から論点をLLMで分割し、構造化（JSON）。分割ではFewshotにより分割の基準が明確化、出力結果が安定。
• 埋め込み：分割済みテキストを文脈ベクトル化。
• 意見グループ化：UMAP（2次元化）→k-means（細分割）→Ward法（統合）で階層的クラスタリング。
• 初期ラベリング：KJ法/表札という専門用語によって、各クラスタの特徴を抽出し、意味のあるラベルを付与。
• 統合ラベリング：下位ラベルを束ねて上位クラスタの名称・説明を決定。
• 要約：上位ラベル群から全体概要をLLMで1段落に圧縮。
• 出力：中間成果を1つのJSONに集約。ビジュアライズのための準備。
• 表示：現生成されたJsonをもとにnodeで静的ウェブページを作成する。（現在は未使用）。

3. TTTCとの関係とアルゴリズムの選択

• 広聴AIはTTTC（Talk to the City）由来だが、説明容易性重視の構成に最適化。
• 広聴AI：Embedding→UMAP→k-means→Ward→LLMによりクラスタに命名。
• TTTC：BERTopic（BERT＋HDBSCAN）系、またはUMAP→Spectral Clustering系の2通り。

4. まとめ

• LLMやエンベディングをプログラムに組み込むことで、複雑な自然言語を処理できるようになり、新たなサービスを作るチャンス。

感想

LLMを分割／命名／要約の道具として割り切っており、データサイエンスでこれまで使われてきたEmbedding, UMAP, クラスタリングによる実装骨格が作られている点が非常に面白かったです。日常の業務ではやはりどうしても「LLM（生成AI）によって業務を最適化してほしい」といった方向に思考が行きがちだったため、目から鱗でした。

この技術を応用してどんなサービスが考えられるか？

さて、なかなか現業でどのように取り組んでいくかは難しいところなので、LLMやエンベディングにより今後どのようなサービスが考えられるか？いくつか案でも考えてみます。

サービス問い合わせの論点クラスタダッシュボード

• 「広聴AI」とほぼ同様の仕組みで実現可能。
• 問い合わせに応じてラベリング、クラスタを分割。
• 技術的要因の場合は「問い合わせする人」では判別しづらいこともあり、カテゴリを自然に分割することでサービス管理者の負荷を軽減。

例えばシステムプロンプトの例としては以下。

# 役割
あなたは「サービス問い合わせの論点クラスタダッシュボード」を生成するアナリストAIです。
ユーザー問い合わせ（自由記述）を機械可読なクラスタと安定ラベルへ整理し、担当者の負荷を下げるための
カテゴリ分割・優先度付け・エスカレーション指針を生成します。

# 目的（達成基準）
1) 問い合わせ文を「論点単位」へ分割し、重複・テンプレ表現を正規化して**安定クラスタ**を形成する  
2) 各クラスタに**説明可能な表札（ラベル）**と**原因仮説**、**推奨アクション**を付与する  
3) 技術的要因でユーザー本人が分類しづらい案件を**自然なカテゴリ**に分割し、**担当ルーティング**を明確化する

# 入力
- 略

# 出力（最終）— JSON
- 略

運用ログの自然言語要約

• システム運用において膨大に蓄積されるログについて、自然言語による要約＋ラベルを付与。
• マイクロサービスにおいては、負荷のかかっているサービスの原因を可視化。
• アラートの抑制として、ただあるログが検知された際に発火していたアラートをより業務ロジックよりに昇華。

例えばシステムプロンプトの例としては以下。

# 役割
あなたはSRE/プラットフォームチームの“ログ理解・負荷原因可視化・アラート抑制”コパイロットです。
分散トレース/ログ/メトリクスを、ビジネス影響が判断できる形に要約し、再現性のあるラベル付けと運用アクション提案を行います。

# 目的
1) 膨大なログを「インシデント単位」に自然言語で要約し、安定ラベル（表札）を付与
2) マイクロサービスで負荷が高いサービスの**第一原因**を可視化（依存関係・SLO寄与込み）
3) 単純な“文言検知”型アラートを、**業務ロジック寄りの条件**に昇華（抑制/バンドル/昇格）

# 入力（機械可読）
  ```json
  {
    "traceId": "9999999"
    "ts":"99-99-99T99:99:99Z",
    "service":"auth",
    "endpoint":"POST /sign-in",
    "status":403,
    ... 以下略
  }

総括

いくつか案を出しましたが、微妙だと思われるかもしれません。しかし、LLMとクラスタリングの組み合わせにより考えられるサービスの幅が広がった気がします。
プロジェクト運用の中でも利用シーンがあればぜひ使ってみたいと思える技術要素でした。

おわりに

「キャリア祭り」というタイトルに即して感想を述べるなら、私自身、生成AIの登場により日々どのように現業と向き合っていくか悩みながら仕事をしていました。
「エンジニアとして生きていけるのか？」、「この領域はAIに取って代わられてしまうのではないか？」そう感じている同業種の方は少なくないと思います。
しかし、今回の講演を拝聴し、エンジニアとして研鑽することとAIツールを使いこなすことの両輪でキャリアを歩んでいこうと強く思えました。

AIの登場により、自身の日々のエンジニアリング業務にも、また今後出てくるAIを利用したサービスにも大きな変化が生まれてきます。常に時代の変化に適応していくことが大切だと再認識させられました。
AIライフ楽しんでいきましょう、ご講演ありがとうございました！

私たちは一緒に働いてくれる仲間を募集しています！

新卒採用ページ クラウドアーキテクト

執筆：@kamino.shunichiro
レビュー：@nagamatsu.yuji
（Shodoで執筆されました）