はじめに こんにちは。株式会社エブリーで約1ヵ月間インターンシップに参加していた山下と申します。 今回のインターンでは、AIを活用して社内の業務変革を進める「AX(AI Transformation)プロジェクト」に参加しました。主に取り組んだのは、次の2つです。 営業活動（Event）の記録を効率化するための、Slack botのバックエンド設計・実装 案件（Opportunity）の記録を効率化するための、提案資料からの情報抽出の検証 この記事では、開発の背景や技術的な取り組みに加えて、初めての技術や営業業務をどのように理解し、社員の方と相談しながら進めたかについても紹介します。 プロジェクトの背景 AXプロジェクトでは、AIを活用して営業担当者の管理業務等の負担を減らし、顧客へのアプローチに使える時間を増やすことで、最終的には売上の増加に貢献することを目指しています。その第一歩として取り組んだのが、Salesforceへの営業活動・案件情報の記録を支援する仕組みです。 Salesforceは、顧客情報や営業活動、案件の進捗などを管理するプラットフォームです。営業担当者は、会議やメールでのやり取りを振り返り、その内容を画面から手作業で記録する必要がありました。活動の内容を思い出し、関連する顧客や案件を確認しながら入力する作業には大きな労力と心理的負担がかかります。 そこで、さまざまな場所に散在する情報を集約し、AIが作成した登録候補をSlack上で確認・承認することで、入力の負担を減らす仕組みづくりを目指しています。 システムの全体像と担当範囲 営業活動の情報は、Zoomでの会議やGmailなど、複数のソースに分かれています。既存の設計では、これらの情報をDatabricksに取り込み、ETLで統合・加工します。さらにAIの判断を加え、紐づけ先となる取引先や担当者、案件の候補を含むGoldテーブルを作成します。 Goldテーブルでは、営業活動1件が1行に対応します。この情報を営業担当者に提示し、内容を確認して承認してもらった後にSalesforceへ登録する、という流れです。 情報ソースからSalesforceへの登録までのシステム全体像 ETLからアプリケーションに渡すデータまでの設計・実装は、主にメンターの方が担当しました。私はその設計を理解した上で、登録候補をSlackに提示し、営業担当者の操作を受け取ってSalesforceに登録するバックエンドを担当しました。 また、営業活動とは別に、案件情報の記録を支援するため、Slackからの情報取得パイプラインの実装と、提案資料からの情報抽出の検証にも取り組みました。 設計・実装に取り組むまで 以前からETLには興味があったものの、実際に触れるのは今回が初めてでした。まずは、段階的にデータ品質を高める メダリオンアーキテクチャ の考え方や、Databricksでのパイプラインの記述方法を学ぶところから始めました。既存の実装やドキュメントを読みながら、どの段階で何の情報が作られ、アプリケーションがどのデータを使うのかを、手探りながら確認していきました。 同時に、営業業務の理解も必要でした。営業担当者が顧客への提案に使う資料やSalesforceの入力画面を直接触って確認したり、営業担当者とのミーティングに参加させていただいたりして、実際にどのような情報を扱っているのかを学びました。 最初は分からないことばかりでしたが、メンターの方は定例会だけでなく、都度の相談にも快く対応してくださいました。実装を読み、業務の情報を確認し、分からない点を相談することを繰り返す中で、少しずつプロジェクトの全体像と、自分の担当する部分を理解できるようになりました。 営業活動の記録を支援するSlack bot 登録候補の提示からSalesforceへの書き込みまで Slack botは、Goldテーブルと同期する Lakebase を参照します。アプリケーション側からはPostgreSQLとしてアクセスできるため、バックエンドは定期的にLakebaseをポーリングし、新たに提示する対象がないかを確認します。 投稿対象があれば、営業活動の内容と、関連する取引先や案件などの候補をSlackに表示します。営業担当者が候補を選択して承認すると、バックエンドがその操作を受け取り、Salesforce APIを通じて営業活動を登録します。 実装には、Slackアプリ開発用のフレームワークである Bolt for Python を利用しました。Slackでのボタン操作などはWebSocket接続を使うSocket Modeで受け取るようにしており、インターネットにポートを公開せずにSlackとやり取りをすることができます。 デプロイ先にはDatabricks Appsを選びました。ETLと同じプラットフォームを利用することで、素早くプロトタイプを作成できると判断したためです。一方で、今後の運用コストの観点から、AWS ECSなどへの移行も検討が必要だと考えています。 営業担当者が確認しやすいフォームを考える 実装で工夫したのは、Slackに表示するフォームです。営業担当者によっては、1日に10件ほどの投稿が届く場合もあります。AIがETLで提示する候補は最大3件に抑えられていますが、それでも候補が多いとメッセージの縦幅が大きくなります。入力の負担を減らすという目的を考えると、Slackでの承認の心理的ハードルを抑えることは重要であると考えました。 候補の表示方法として、ラジオボタンとセレクトメニューを比較しました。今回は、選択肢を一覧できることと、スマートフォンとPCで見え方が大きく変わらないことを重視し、ラジオボタンを採用しました。セレクトメニューはコンパクトに収まるものの、PCでは候補のテキストの省略が発生してしまうため、好ましくありませんでした。 その上で、表示する情報を減らす工夫も行いました。取引先企業が1社に決まっている場合は、取引先企業を1行で示し、案件だけを選んでもらいます。候補が1件しかない項目も、同じように1行で表示します。決まっている項目を選択肢にしないことで、フォームの行数を減らしました。 Slackに表示される営業活動の登録フォーム 検証環境でSlackでの承認からSalesforceの書き込みまで動作することを確認し、リリース直前のところまで実装することができました。 提案資料からの案件情報抽出の検証 何を抽出したいのか Salesforceには、営業活動に加えて案件（Opportunity）という情報を記録します。案件では、どの営業担当者が、どの顧客に、どの商材を提案し、現在どの受注フェーズにあるかなどを管理します。 案件情報を取得するソースとして、Slackの投稿やGoogle Slidesの提案資料が有用でした。そこで、Slackからの情報取得パイプラインの実装と並行して、提案資料から情報を抽出する方法を検証しました。提案資料には、どの顧客に、どの商材を、いくらで提案したかといった情報が含まれます。今回は、LLMを使って資料の内容を提案メニューの候補と照合し、該当するメニューをどの程度正確に抽出できるかを確認しました。 検証方法とコスト削減の仮説 評価のために、9つの提案資料と提案メニューの候補を自分で確認し、対応する商材を紐づけた正解データを作成しました。提案の初期段階では複数のプランが提示される場合もあるため、該当する候補を取りこぼさないこと(高い再現率)を重視しました。 資料には、提案内容に直接関係しない情報(市場調査データや広告戦略など)も含まれています。そのため、LLMに渡す前に不要な情報を取り除けば、入力トークンを減らしてコスト低減につながるのではないか、と考えました。そこで、高速/低コストで判断を下すことのできる、 Typesafe AI のJevによるフィルタリングを前処理に加える場合と、加えない場合を比較しました。また、LLMの性能の違い、thinkingの有無による結果の違いも確認しました。提案資料はGoogle Slides APIを介して取得したJSONをテキストに変換した上、LLMに入力しています。 Jevには価格情報の有無、メニュー情報の有無の観点からスライドを評価させ、閾値0.5でフィルタリングしています。実行対象のスライドには、正解データをつけた9つの資料に加え、コスト測定用に6件を加えた計15件としています。 検証結果 評価には再現率とF1スコアを使いました。再現率は、正解データの商材のうちLLMが抽出できた割合です。取りこぼしが少ないほど高くなります。適合率は、LLMが抽出した商材のうち正解だった割合です。F1スコアは再現率と適合率の調和平均で、取りこぼしと誤った抽出がどちらも少ないほど高くなります。どの指標も1に近いほどよい結果です。 モデル Jev 再現率 F1 コスト／件 時間／件 gpt-6-luna thinking なし なし 0.931 0.718 ¥0.18 6.1 秒 gpt-6-luna thinking なし あり 0.797 0.721 ¥0.24 11.1 秒 gpt-6-luna thinking あり なし 0.972 0.862 ¥0.30 25.0 秒 gpt-6-luna thinking あり あり 0.794 0.733 ¥0.34 27.2 秒 gpt-5-6-terra thinking あり なし 0.954 0.788 ¥5.09 14.6 秒 gpt-5-6-terra thinking あり あり 0.757 0.731 ¥3.08 17.1 秒 今回の検証では、軽量モデル( gpt-6-luna )ではJevによる処理コストが上乗せされ、コストはむしろ増加しました。より重いモデル( gpt-5-6-terra )では、入力トークンの削減効果が現れています。一方、今回試した軽量モデル gpt-6-luna でも、検証用データに対しては十分高いマッチング精度が得られました。コストの内訳を確認すると、thinkingを含む出力トークンのコストが支配的でした。thinkingを無効にした場合はマッチング精度が大きく低下しています。 また、Jevを利用した場合の再現率の低下が確認され、コンテクストが希薄になることで取りこぼしも生じています。 この結果から、今回の検証条件では、Jevによるフィルタリングを行わず、thinkingを有効にした軽量モデルを使う構成がよいと考えています。 今後の課題 検証と営業担当者への聞き取りを進める中で、顧客に見せる資料には、提案を目的としないものも混ざっていることが分かりました。今回試した「資料内の不要な情報を減らす」用途とは別に、「処理対象となる提案資料かどうかを判別する」用途でJevを活用できないか、今後検討の余地があると考えています。 また、今回作成した検証セットでは高い精度が得られたものの、商材の名称には多義性があり、期間限定のものも存在します。営業チームの中で共有されている暗黙知がマッチングに影響する可能性があり、精度をさらに高めるためには、それぞれのメニューの定義など、判断に必要な情報を整備することも必要だと感じました。 AXプロジェクト全体としては、完成した資料から情報を抽出するだけでなく、提案資料を作る前の段階から支援し、情報を記録できる仕組みを考えることも、今後の方向性だと考えています。 インターンを通じて感じたこと データ基盤からアプリケーションまでをつなぐ経験 今回のインターンでは、以前から興味のあったETLを含め、Databricksに触れることができました。複数のソースから統合したデータを、Slack botとして利用するところまでつなげられたのは、貴重な経験でした。 今回は既存設計を理解することで精一杯な部分もありましたが、今後はETL全体の設計にも挑戦できるよう、知識と実力を身につけていきたいです。 チームで設計を共有し、担当範囲を考える難しさ これまで、複数人で1つのプロジェクトに取り組み、並行して開発した経験がありませんでした。今回は、社員の方と設計を共有し、その内容を理解した上で必要な設計について相談することや、プロジェクトの目的と責任範囲から自分のやるべきことを整理することに難しさを感じました。 自分の実装がシステム全体の中でどの役割を持つのかを考え、認識を合わせながら進める経験ができたことは、今後の開発にもつながる学びになりました。 業務・ドメインの理解をもっと大切にしようと思った 営業業務やSalesforceの仕様を理解するには、想像以上に時間がかかりました。一方で、営業担当者が実際に使う資料や画面を確認することで、必要な情報や仕組みを少しずつ理解できるようになりました。私が担った業務の中でも、SlackのUIで提示すべき情報の判断や提案資料からの情報抽出の検証において、業務理解の必要性を強く感じました。 エブリーではビジネスサイドとの距離の近さを感じる機会があり、誰のどのような業務を支援するのかを具体的に捉えながら取り組めたことが、自分のモチベーションにもつながりました。 振り返ると、もっと早い段階で営業資料や実際の入力作業といった一次情報に当たる必要性に気づければよかったと思います。これからの開発に当たっても技術の理解だけでなく、できる限り一次情報に触れ「何がなぜ必要なのか」を理解・判断できるように心がけられたらと考えています。 おわりに 今回のインターンでは、社内の業務変革に取り組むプロジェクトに参加し、Slack botの開発と案件情報抽出の検証に取り組みました。初めての技術や業務に触れながら、社員の方と相談して進める経験ができました。 また、業務外でもさまざまな社員の方とお話しする機会を用意していただき、エブリーのことだけでなく、今後のキャリアについて考えるきっかけもいただきました。 AXプロジェクトの皆様はじめ、様々な形で関わってくださった皆様、1ヵ月という短い間でしたが、本当にありがとうございました。

はじめに 先日、米国サンフランシスコで開催されたSalesforce社主催の年次カンファレンス「Dreamforce 2026」に現地参加してきました。 私は普段、Salesforceが提供するiPaaS製品であるMuleSoftを用いたプロジェクトに携わっており、システム連携基盤の設計・開発・運用を中心に技術支援を行っています。 今回Dreamforceへ参加した目的は、SalesforceやMuleSoftをはじめとした最新の技術・製品動向や、各社のAI活用事例を現地で収集し、その知見を今後の提案活動やプロジェクトでの技術支援に還元することです。 昨年のDreamforce 20