kubell Creator's Note

株式会社kubellのエンジニアのブログです。

ビジネスチャット「Chatwork」のエンジニアのブログです。

読者になる

kubell プロダクトユニット AI 推進委員会のふりかえり

こんにちは。株式会社 kubell コミュニケーションプラットフォームディビジョン プロダクトユニットの須田です。

今年の途中から、プロダクトマネージャー・エンジニア・デザイナー・SRE・QA・カスタマーサポートなどなどの業種を束ねる「プロダクトユニット」という組織で、AI 推進委員会なる委員会に所属して活動してきました。年末のこの機会に、特に下半期の活動をふりかえってみたいと思います。

この記事は kubell Advent Calendar の12月24日分の記事です。その他の記事はこちらから。

qiita.com

2025年8月に兄弟記事が出ていますので、そちらもぜひ!

creators-note.chatwork.com

前提: プロダクトユニットの AI 事情

現在、プロダクトユニットでは次のような AI を利用しています。

ツール名 利用状況
Claude / Claude Code プロダクトユニット全社員が Max プランを利用可能
Gemini / Gemini CLI Google Workspace に付随する形で、全社員が Enterprise プランを利用可能
ChatGPT / Codex 希望者が利用可能
社内専用 AI (愛称: ねこのて) 社内の事務系ドキュメントを RAG で読み込んだツール。全社員が利用可能

特に Claude / Claude Code はプロダクトユニットとして強い意思を持って導入しており、2025年6月ごろからはプロダクトユニットの全社員が Max プランで利用できるように整備しています。

また、AI コーディングの得意・不得意を見極めるという目的も兼ねて、ChatGPT / Codex も希望者が使えるようにしてあります。将来 ChatGPT / Codex が圧倒的に天下を取るようなことがあれば、スムーズに乗り換えられるようにという、全方位戦略的な目的もあります。さらに、kubell では全社で Google Workspace を利用している (でもチャットは当然 Chatwork ですよ!念のため!) ため、Gemini / Gemini CLI も利用できます。

それに加えて、プロダクト開発とは直接の関係はありませんが、「ねこのて」と呼ばれる社内 AI が存在します。「ねこのて」には事務系・総務系・労務系のドキュメントを RAG で読み込ませてあり、ちょっとした相談なら AI で済むようになっています。総務や労務、CSE に問い合わせるとまず Chatwork のグループチャットに「ねこのて」が入ってきて、一次回答をしてくれるという仕組みも整備されています。このあたりは CSE から記事が出ていますので、ぜひ読んでみてください。

note.com

当時のプロダクトユニットの課題

課題 1 : 全社員に導入した Claude Code の利用率が低かった

2025年8月時点では、過去記事 プロダクト組織のAI活用推進をデータと事例で振り返る - kubell Creator's Note を見ていただければ分かるとおり、プロダクトユニットの AI 活用はやや低調という状態でした。

2025年8月時点でのアンケート結果

前述のとおりプロダクトユニットに所属する社員は全員 Claude Code を使えるわけですが、毎日利用している方は 47% と半数以下に留まっています。AI を使うこと自体は目的ではないものの、AI を活用することで開発生産性が大幅に向上するのは様々な事例から明らかです。プロダクトユニット AI 推進委員会としては、開発生産性を向上させることを目指して、AI の利用率を向上させることが目標の一つでした。

課題 2 : 巨大なコードベースへの AI でのアプローチが五里霧中だった

昨年 (2024年) の記事ですが、こんな記事が出ています。2024年の開発生産性カンファレンスで CTO の田中が語った内容です。

findy-code.io

2024年から2025年にかけて改善活動は行われているものの、Chatwork のモノリス構造・技術的負債はまだ根深く、完全に解消しきることはできていません。

最近はそんなこともなくなりつつありますが、少し以前の AI は「新規コードはガンガン書けるが、巨大な既存コードに立ち向かうのはまだ難しい」と言われるようなことが多かったと思います。我々プロダクトユニットもこの問題にがっぷり四つで直面し、巨大なシステムに対して AI でどのように立ち向かっていくか、五里霧中の状態でした。

AI 推進委員会としてやったこと

こうした課題には派手に取り組むことができれば AI 推進委員会としても盛り上がるのですが、実際のところは、こういった課題解決には地道に泥臭く改善活動を重ねていくのが最短ルートだと信じています。この半年で行った地道な活動を2点紹介します。

エンジニアの定例ミーティングで順番にAI活用事例を発表してもらう

プロダクトユニットには、全エンジニアが毎週30分集まって情報交換をする「開発者定例」というミーティングがあります。この開発者定例の中に、チームごと順番にAI活用事例を発表するコーナーを設けました。各チームの代表者が、自分のチームの取り組みを10分程度で紹介するようなイメージです。

これまでに9件の事例報告があり、次のような内容が発表されました。

  • Claude Code の Sub-Agents を公式ドキュメントから読み解いてみる
  • Claude Code スラッシュコマンドの徹底活用法
  • Claude Code を使って AWS の Savings Plan の実績算出を劇的に楽にする方法
  • TestRail / Selenium で自然言語から E2E テストを作ってみる話
  • Claude Code と Atlassian MCP を連携させてチケット駆動開発をやってみた
  • プロダクトのプロトタイピングを Claude Code を使って行うと実際のところどうなのか
  • Kubernetes Pod へのリソース割り当てを AI に提案してもらう方法
  • AI に MCP ではなく自作の jira CLI を使わせ、コンテキストを1割以上削減した話
  • GitHub の issue テンプレを整備して AI が自走しやすい環境を整える

発表の中には Chatwork の課題である「モノリス構造・技術的負債の蓄積」に対するアプローチを提案してくれているような内容もあり、私自身も一エンジニアとして参考になるものばかりでした。

実際、この取り組みはとても好評で、アンケートの結果、実に96%の参加者が「とても有意義だ」「やや有意義だ」と回答してくれました。

開発者定例のAI利活用紹介コーナーの感想

AIツールを気軽に導入できるようにする: 導入フローの整備

AI 周辺には日々新しいツールが誕生するとともに、既存のツールも精度や UX で競い合っていて、まさに群雄割拠の様相を呈しています。プロダクトユニットのメンバーも、新しいツールを試してみたくなる場面は多くあります。

一方で我々はビジネスドメインとして「ビジネス向けのチャットサービス」を運用しており、セキュリティの担保は至上命題です。お客様のデータを気軽に AI に渡すなどもってのほかですし、開発基盤の諸々の情報もセキュリティレベルの低い AI に渡すのは大きなリスクを伴います。

「新しい AI ツールはがんがん使いたい、でもセキュリティもバッチリ担保したい」という要求に対応するため、AI ツールの導入フローを整備しました。具体的には、まず我々 AI 推進委員会に使いたいツールを紹介してもらい、我々が伴走する形でセキュリティ部門に確認を取ったり金銭面での調整をしたりするようにしています。こうすることで、各チームが独自にツール利用の調整を行うコストが削減され、また良いツールをプロダクトユニット全体で使えるようにする波及効果も高まります。

現在社内で利用している「AIサービス利用方針」というドキュメントには、AI 推進委員会以外を経由して記載されたものも含まれていますが、約40件のAIサービスが記載されています。開発者はこの方針に基づいて自発的にAIサービスを利用することができるようになっています。

ふりかえり

2025年8月に プロダクト組織のAI活用推進をデータと事例で振り返る - kubell Creator's Note の記事を書くにあたって取ったアンケートと同等のアンケートを、2025年12月にも取ってみました。このデータに基づいて、AI 推進委員会のふりかえりをしてみます。

AI の利用率は向上、でもまだまだ

他チームの AI 活用事例を見聞きしたり、自分が使いたい AI ツールを導入できるようになったりしたことで、AI の利用率は前回調査の2025年8月に比べて向上しました。

いずれかのAIツールを毎日利用している人の割合

2025年8月には5割程度に留まっていた「毎日AIツールを使う人」が、4ヶ月で30%以上増加し、現在では8割以上の人が「毎日AIツールを使う」と回答しています。4ヶ月で30%以上利用率が向上するのは、目に見える成果だと言って良さそうです。(ちなみに、回答者にはエンジニア以外の職種も一部含まれていることに留意してください。)

ただ、絶対数としては、まだ19%程度の社員が毎日は AI ツールを利用していないと回答しています。AI 推進委員会のメンバーでもある私個人の考えとしては、「この情勢において、AI を使わない日なぞ無い」と思っています。既に利用しているメンバーにより効率的に AI を利用してもらうと同時に、残る19%のメンバーにも AI の恩恵にあずかってもらえるような基盤整備が必要だと痛感しています。

AI の利用時間はまだ短い

アンケートでは、AI ツールの利用時間も回答してもらっています。このうち1日2時間以上 AI ツールを使っている方は、2025年8月から約10%増加して50%に到達しています。

いずれかのAIツールを1日2時間以上利用している人の割合

しかし、前項の繰り返しにはなりますが、絶対数としては半分程度の方の AI 利用時間が2時間未満であることは課題だととらえています。この原因には様々なことが考えられます。Chatwork の「モノリス・技術的負債の蓄積」という課題から AI の利用場面が限られてしまっている可能性もありますし、純粋に AI 活用のスキルがまだまだ未熟ということも考えられます。

いずれにしても、さらに長時間 AI を使いこなせる (そしてその空いた時間で、人間はより人間が求められる仕事に取り組める) ような環境・基盤を構築することが必要だと感じています。

モノリス・技術的負債の蓄積との向き合い方

モノリス・技術的負債の蓄積との向き合い方として面白いなと感じたのは、「AIツール導入前後で、既存コードのキャッチアップ速度がどの程度向上したか」という質問に対する回答です。実に70%のメンバーが「大幅に向上した」「向上した」と回答しており、AI 導入の効果が如実に現れていそうです。

AIツール導入前後で、既存コードのキャッチアップ速度がどの程度向上したか

モノリス・技術的負債の蓄積を解消していくためには、ゴリゴリとコーディングをすることはもちろん必要ではありますが、それよりも全体の状況を冷静に把握・分析した上でリスクを洗い出し、そして最後には人間が意思決定をするという作業の方がむしろ重要と感じます。

こうした見方に立つと、新規コードの生成精度・速度を上げるというベーシックな戦略と並行する形で、既存コードの定性的な分析に AI をフル活用するような基盤・環境・文化を作るという戦略の比重を高めることが重要なのかもしれません。多くの開発現場では新規コードを生成するためのコンテキストエンジニアリングの文脈で既存コードを AI に分析させることに注力していることでしょう。我々はそこから少しズラして、既存コードの改善をどう進めるか意思決定する相棒として AI を鍛え上げていくというのは、面白い進み方であるように思います。

2026年に向けて

2025年は、現場のエンジニアの8割以上が毎日 AI を使うようになったことで、AI を用いたエンジニアリングが当たり前であるという環境は整備することができたと思っています。次のステップである 2026 年は、この環境を活かした上で、「Chatwork という巨大なプロダクトに AI でどう切り込むか」という点に真剣に向き合う必要があるでしょう。

kubell では現在、半ば “危機感” のようなレベル感で全社を挙げて AI 利活用を推進しています。AI 推進委員会としても、巨大かつレガシーなコードベースに対してどのように AI を活用していくのかユニット全体を巻き込んで考え、実行し、発信していかねばならないと思っています。

来年の Advent Calendar ではその成果をドヤ顔で発信できるよう、引き続き地道に頑張ってまいる所存です!

--

kubellでは、様々なフェーズのコンポーネントに対して AI を武器の1つとして全力で立ち向かうエンジニアを募集しています。気になる方はぜひ採用ページもご覧ください。

www.kubell.com

www.kubell.com