NECが商談記録AIを1,000名規模で導入——営業のAI活用は「解析」ではなく「記録が残る状態」から始まる

AI開発・生成AI活用公開日:2026年7月29日
徐 聖博
徐 聖博

株式会社シンシア 代表取締役社長

Share
目次開く
  1. 要点 (事実のみ)
  2. 最初に解いたのは解析ではなく入力の問題
  3. 中田CIOのコメントは順番を正しく述べている
  4. 自社で同じものを作るとしたら、難所はどこか
  5. 中堅・中小企業が持ち帰れること

シンシアへのご相談

自社のAI活用・開発体制について相談する

AIをどこまで内製するか、どの業務から着手するか、体制をどう組むか。開発会社・SIer・事業会社の開発部門の方からのご相談を無料で承っています。同じ問題を自社でも解いている立場としてお話しします。

AI活用の進め方を相談する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

ナレッジワークが2026年7月28日に発表した、NECの商談記録AI導入事例を取り上げる。営業のAI活用というテーマで実務的に読むべきなのは、AIが何を解析するかではなく、そもそもデータが集まる状態をどう作ったかのほうである。

要点 (事実のみ)

  • 日本電気株式会社(NEC)が、株式会社ナレッジワークの「ナレッジワークAI商談記録」を営業部門に導入した。発表は2026年7月28日。
  • 導入規模は1,000名。今後は全社規模での活用拡大を進める方針としている。
  • 機能は、対面・オンライン・電話の商談録音/録画、音声のAI自動文字起こし、商談レポートの自動作成(要約・フィードバック・スコアリング)、CRM/SFAへの自動入力、外部システムとのデータ連携、権限管理。
  • ナレッジワークは ISO 27001 / ISO 27017 / ISO 27701 / SOC 2 Type1 を取得している。
  • NEC CIOの中田俊彦氏は、蓄積された商談データを「見える化」から「勝ちパターンの共有」へ進化させ、AIが次のアクションを提言する営業のイネーブルメントを実現していく、と述べている。

最初に解いたのは解析ではなく入力の問題

この事例の機能一覧で私が最も重要だと思うのは、スコアリングでもレポート自動生成でもなく、CRM/SFAへの自動入力である。

営業支援システムが機能しない原因は、たいてい分析能力の不足ではない。データが入っていないことだ。商談が終わった夕方に、営業担当が記憶を頼りに要約を打ち込む。忙しい日は飛ばす。埋まらない項目が増えるほど、レポートは信用されなくなり、さらに入力されなくなる。この悪循環はどの業界でも見てきた。

商談を録音して自動で文字起こしし、そのままSFAに書き込む構成は、この悪循環の入口を塞ぐ。人が「入力する」という工程そのものを消しているからだ。1,000名規模という数字も、精度の高さを誇る文脈ではなく、データが集まる母集団を先に確保したと読むべきだと私は考えている。営業のAI活用が失敗するのは、たいていこの手前で止まっているからだ。

中田CIOのコメントは順番を正しく述べている

「見える化 → 勝ちパターンの共有 → AIが次のアクションを提言する」という順序は、そのまま実装の順序でもある。

順番を逆にすると破綻する。次のアクションを提言するAIを最初に作ろうとすれば、学習に使える商談データが存在しないという壁に必ず当たる。勝ちパターンを共有しようにも、何が勝ちだったのかを再現可能な形で記録していなければ、共有されるのは属人的な武勇伝になる。提言AIは、記録が3か月分たまってからでないと作れない。

私が受託開発とAIエージェント事業で相談を受けるときも、詰まっているのはたいていここだ。「AIで営業を強くしたい」という相談の実態は、記録が残っていないので現状分析すらできない、という状態であることが多い。この構造は「使われないシステム」が生まれる要件定義の失敗と同じで、業務に埋め込まれていないシステムはデータを生まない。

自社で同じものを作るとしたら、難所はどこか

作る側の目線で見ると、この製品の難しさは音声認識の精度ではない。すでに文字起こしは十分な水準にあり、そこは差別化要因になりにくい。

難所は3つあると考えている。

1つ目は録音そのものの運用である。対面・オンライン・電話という3経路をすべて拾うには、デバイスも同意取得の設計も変わる。特に対面商談は、誰がいつ録音を開始するかという運用ルールが崩れると、途端に穴が空く。

2つ目は相手方の同意と情報の取り扱いである。商談の録音には顧客企業の担当者の発言が含まれる。ナレッジワークが ISO 27701(プライバシー情報マネジメント)まで取得しているのは、この領域が製品要件として重いことの裏返しだろう。1,000名規模の企業に導入されるには、機能より先にこの認証が必要になる。

3つ目は既存SFAへの書き込みである。自動入力は、対象システムの項目定義・必須項目・入力規則にすべて合わせないと弾かれる。ここは地味だが、実際に工数を食う部分だ。汎用的に見えて、導入先ごとの個別対応が発生しやすい。

生成AIプロダクトの難所が、モデルではなくその周辺の業務接続にあるという構造は、AIシステム開発の進め方AI PoCの進め方で整理してきた話と一致する。

中堅・中小企業が持ち帰れること

1,000名規模の導入をそのまま真似することはできない。それでも、順番は再現できる。

営業のAI活用を検討するなら、最初に問うべきは「どのAIツールを入れるか」ではなく、商談の内容が今どれだけ記録として残っているかである。残っていないなら、解析より先に記録の仕組みを作る。記録が残り始めれば、勝ちパターンの抽出は後からいくらでもやりようがある。逆に、記録が無い状態で提言AIを導入しても、提言の根拠になるデータが社内に存在しない。

自社の営業プロセスのどこからAIを差し込むべきかを整理する段階で迷っている場合は、開発のご相談からお問い合わせいただければ、記録・データ整備の順序から一緒に検討する。

出典: NEC、AI活用の商談記録・解析ツール「ナレッジワークAI商談記録」を導入 (株式会社ナレッジワーク / PR TIMES, 2026-07-28)

Share

シンシアへのご相談

自社のAI活用・開発体制について相談する

AIをどこまで内製するか、どの業務から着手するか、体制をどう組むか。開発会社・SIer・事業会社の開発部門の方からのご相談を無料で承っています。同じ問題を自社でも解いている立場としてお話しします。

AI活用の進め方を相談する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

徐 聖博のプロフィール写真

この記事の書き手に直接相談する

徐 聖博株式会社シンシア 代表取締役社長

記事の内容について、より具体的に自社のケースで聞きたいことがあれば、徐 聖博を指名してご相談いただけます。営業担当ではなく、 実際に手を動かしている本人が回答します。

シンシアの開発事例

株式会社Atsumell様|サービスを止めずにデータ基盤を刷新したBPマッチングプラットフォームの開発事例

**約11ヶ月・のべ4名のリレーで、機能開発を止めることなく基盤の刷新を完了しました。** 参画時期の重なりは最大2〜3名で、メンバーは1ヶ月の短期集中から5ヶ月の継続稼働までさまざまです。それでも積み上げが効いたのは、**先に入ったメンバーが構造を残していたから**でした。2025年7月に導入された Repository 層の上で、半年後に別のメンバーが移行作業を進めています。認可条件はコード上の仕様コメントとして、スナップショット方式はアーキテクチャドキュメントとして残り、いずれも「引き継いだ人が読んで分かる」形になっています。 この期間に手掛けた業務機能は、協力会社のラベル分類機能、パートナー企業管理画面、CSV による一括招待とデータ出力、案件辞退フロー、ステータス変更通知メールなど多岐にわたります。基盤刷新と機能開発は、どちらかを止めて行ったものではありません。 > 大規模な基盤刷新は「一度止めて作り直す」以外にも方法があります。呼び出し側を壊さない層を挟み、テーブル単位で少しずつ移し、移行と改善を混ぜない。この3つを守れば、リリースを止めずに土台は入れ替えられます。事業を止められないプロダクトほど、この進め方の価値が出ます。 ### この事例からの示唆 **稼働中のサービスでも基盤は入れ替えられる。** 前提は、呼び出し側の契約(戻り値の形)を保つ中間層を挟むこと、移行単位をテーブルや画面まで小さく割ること、そして移行と機能改善を同じコミットに混ぜないことの3点です。この3つが崩れると、不具合が出たときに原因が移行なのか改善なのか切り分けられなくなり、結果として一度止めるしかなくなります。 **メンバーが入れ替わる前提の体制では、成果物より「残る構造」が価値になる。** 短期参画のエンジニアを増やしても積み上がらないプロジェクトは、設計判断が個人の記憶に閉じていることが原因であるケースが多いです。この事例では、認可条件をコード上の仕様コメントとして、データ設計をアーキテクチャドキュメントとして残す運用を徹底しました。開発体制の失敗パターンについては[システム開発の失敗から立て直す方法](https://blog.xincere.jp/articles/system-development-failure-patterns)でも整理しています。 **要件が固まりきらない領域ほど、データ設計で制約を表現する。** 「協力会社が人材情報を編集したら応募内容が変わってしまう」といった問題は、運用ルールやUIの注意書きでは再発します。スキーマとトリガーで表現すれば、アプリ側の実装漏れがあっても壊れません。要件を仕様に落とす工程そのものについては[要件定義の進め方](https://blog.xincere.jp/articles/requirements-definition-process)を参照してください。 ### よくある質問 **Q. 稼働中のサービスを止めずに基盤刷新はできますか。** A. できます。この事例では約11ヶ月にわたり、機能リリースを継続しながらデータアクセス基盤の移行と主キー変更まで実施しました。ただし「一斉に切り替える」やり方では現実的に困難で、呼び出し側を壊さない中間層を用意して段階移行する設計が前提になります。 **Q. 途中でメンバーが入れ替わる体制でも品質は保てますか。** A. 設計判断がドキュメントとコードに残っていれば保てます。この事例では参画時期の重なりが最大2〜3名、1ヶ月だけの参画者もいる体制で、前任の導入した層の上に後任が半年後の移行作業を積み上げています。 **Q. どのくらいの規模・期間の支援ですか。** A. 約11ヶ月、のべ4名(同時稼働は最大2〜3名)です。プロジェクトの規模や費用感の考え方は[システム開発とは](https://blog.xincere.jp/articles/what-is-system-development)で解説しています。 ### 関連する支援領域 - [システム刷新の進め方|検討・計画から移行までの方法](https://blog.xincere.jp/articles/core-system-renewal-guide) — 稼働中システムを止めずに刷新する判断基準 - [業務システム開発の要件定義とは?進め方・手順を7ステップで解説](https://blog.xincere.jp/articles/business-system-development-requirements-definition-steps) — 要件を仕様に落とす工程 - [システム開発の失敗から立て直す方法](https://blog.xincere.jp/articles/system-development-failure-patterns) — 体制・引き継ぎで詰まったときの選択肢 同じように「稼働を止められないプロダクトの基盤を作り替えたい」という課題をお持ちでしたら、[開発のご相談](https://blog.xincere.jp/contacts)からお問い合わせください。現状のコードとデータ構造を確認したうえで、段階移行の設計からご一緒します。

株式会社Atsumellの事例を読む →

この記事が役に立ったら、Google で優先表示を

Google 検索の「優先するソース」に blog.xincere.jp を追加すると、シンシアの新着記事がトップニュースなどで見つけやすくなります。

Google で優先ソースに追加

著者について

徐 聖博のプロフィール写真
徐 聖博
株式会社シンシア 代表取締役社長

株式会社シンシア(Xincere, Inc.)代表取締役。中国生まれ・3歳から日本で育ち、日本語・中国語・英語を操るトリリンガル。大学院でコンピュータサイエンス(進化型ニューラルネットワーク)を研究し、GREE・メドレー・カウンティア・Indeed Japan などで検索エンジン開発やスタートアップの立ち上げ・グロースを経験。2020年に「人の価値をテクノロジーで最大化する」という想いでシンシアを創業した。エンジニア歴15年以上、代表でありながらほぼ毎日コードを書く現役エンジニアとして、基幹システム開発からAIエージェント活用まで顧客の事業成長に並走している。創業に込めた思いはnoteの創業ストーリーに綴っている。

人気記事

    お問い合わせ

    システム開発やAI推進についてのご相談はこちらから

    無料相談を予約する