こんにちは。bravesoftのeventech本部カスタマーサクセス部です。
「これはバグかもしれない」と思ったとき、皆さんのチームでは誰が最初に動きますか。
多くの会社では、エンジニアへのエスカレーションがその答えになっているのではないでしょうか。カスタマーサクセス(CS)担当者やプロジェクトマネージャー(PM)にとって、プロダクトのコードは触れられない領域であり、原因調査も修正も、すべてエンジニアに委ねるしかない。それが当たり前の姿だと思います。
私たちも、つい先週まではそうでした。
ところが、たった1時間の勉強会をきっかけに、その当たり前が崩れ始めています。初月から、CSメンバーが自らAIを使ってプロダクトのリポジトリを調べ、緊急対応をエンジニア工数ゼロで解決するという出来事が起きました。
何が起きたのか、そこから何に気づいたのかをレポートとしてまとめました。
そもそも何が変わったのか
一言でいうと、「CSが、バグかどうかを自分で見極められるようになった」ことです。
これまでは、プロダクトに関する問い合わせが来ると、CSはまず「バグかもしれない」と考え、エンジニアにエスカレーションするのが唯一の手段でした。原因調査も修正も、すべてエンジニアの仕事。CSにとってコードは、いわば「ブラックボックス」だったのです。
私たちが目指したのは、CSがエンジニアの代わりにコードを書けるようになることではありません。AIを使って自分たちで一次調査ができる状態をつくることでした。
- 「バグかもしれない」の前に、CS自身で原因の当たりをつけられる
- クライアントへの一次回答までのスピードが上がる
- 本当にエンジニアの手が必要な問い合わせだけが、開発チームに届くようになる
きっかけは、たった1時間の投資でした。
1時間のAI活用勉強会で伝えたこと
用意した内容はシンプルです。コードの書き方や技術研修は、一切ありません。
① GitHubへのアクセスとセットアップ
まずは、プロダクトのリポジトリを見られる状態をつくりました。
② AIと一緒に働く進め方
一人で調べるのではなく、AIに問いを投げながら一緒に調査を進める、その基本の型を共有しました。
③ 良い質問の仕方
「バグっぽい」ではなく、「何が起きて、何を知りたいのか」を言葉にする。これがいちばん時間をかけた部分です。
CSとPMのメンバーに手渡したのは、このたった3つだけです。
実例:eventosでの緊急対応
先週、自社が提供するイベント管理プラットフォーム「eventos」で、ある設定を削除すると参加者向けの画面が壊れてしまうという不具合が発生しました。クライアントからの緊急エスカレーションです。
これまでの流れであれば、エンジニアへのエスカレーション → 原因調査 → 修正 → リリースという手順を踏み、対応は早くても翌営業日になっていたはずです。
しかし、今回は違いました。CSメンバーがAIにリポジトリを見せながら、平易な言葉でこう尋ねたのです。
「なぜこの問題が起きたのか。管理画面の操作だけで復旧できないか?」
返ってきたのは、原因についての仮説と、管理画面の操作だけで実行できる復旧手順でした。PMがその手順に沿って対応した結果、最初の問い合わせから1時間以内に解決。エンジニアの工数はゼロでした。

もちろん、これはあくまで応急処置です。原因の疑いがある箇所は不具合として起票し、恒久対応は開発チームが担当しています。判断の速さを求めた分、最終的な責任の所在まで曖昧にしたわけではありません。そこは変わらず、エンジニアリングの領域です。
数字よりも印象に残った、もうひとつの変化
今回の対応そのものよりも印象に残ったのは、別のメンバーが書いた週次報告でした。
そこには、「以前は『バグかもしれない』とすべてエンジニアに丸投げしていたが、今は本当のプロダクト不具合なのか、設定の誤りなのかをある程度自分で見分けられるようになった。クライアントからの最初の問い合わせには、自分で回答できるようになった」とありました。
これは、たまたま起きた成功事例ではないと感じています。仕事の中身そのものが変わりつつある、ということです。
気づき:AIの本質は「一次情報へのアクセス」
今回の変化を振り返って、あらためて気づいたことがあります。ブレークスルーの正体は、AIモデルの賢さではありませんでした。
コードを見せずにAIに質問すれば、返ってくるのは一般論です。しかし、リポジトリという一次情報を接続した瞬間、答えは「自分たちのプロダクトについての答え」に変わります。
そして、非エンジニアがコードを書けるようになる必要はありません。「自分で調査できる」というだけで、エンジニアリングチームに届く問い合わせの量は大きく変わるのです。
次の課題:個人のチャットから、組織の資産へ
今、私たちが向き合っている課題は、こうした調査の知見が個人のチャットウィンドウの中に閉じてしまっていることです。
そこで、問い合わせとその調査の過程をNotionに記録として残し、繰り返し発生するものはサポートサイトへ昇格させる取り組みを進めています。そうして初めて、コードを読めないメンバーにとっても使える資産になると考えています。
私たちがこれから目指しているのは、次の3つのステップです。

① AIとGitに慣れて、自分で調査できるようになる
② ローカル環境を使って、手を動かしながら検証・受け入れを行う
③ SQLクエリからコンテンツ運用まで、自分たちのツールを自分たちで作る
AIへの投資対効果は、ツールにいくら支出したかでは決まりません。どこまでアクセスを開くかで決まる。たった1時間の勉強会が、それを確信させてくれました。
おわりに
私たちは、AIを導入すること自体ではなく、現場の一人ひとりが自分の力で一次情報にたどり着けるようになることを大切にしています。
「バグかどうか判断できず、いつもエンジニアに聞くしかない」
「AIを導入したはずなのに、現場のスピードはあまり変わっていない」
もし少しでも当てはまることがあれば、その突破口は意外と身近なところにあるかもしれません。私たちにとって、それは「たった1時間」でした。
引き続き、AIと現場が一緒に働く様子は、ブログやSNSでお伝えしていきます。
もし『AIやイベントプラットフォームの活用について相談したい』という方がいらっしゃいましたら、開発やイベント運営のご相談からお気軽にお問い合わせください。