はじめに この記事では「IOWNの名前は知ってるけど、実際にどんなビジネスに使えるの？」という疑問にお答えするため、IOWNの特徴を活かしたB2B向けユースケースをご紹介します。 IOWNの特徴 IOWN（アイオン: Innovative Optical and Wireless Network）の概要と特徴についてはこちらのサイトをご参照ください。 https://www.nttdata.com/jp/ja/trends/data-insight/2025/0403/ IOWNは、単に通信経路を光に置き換える技術ではありません。光の強みである大容量・低遅延・低消費電力を通信から

(この記事は、 Enable zero-copy access to AWS services on Amazon FSx for NetApp ONTAP with Amazon S3 Access Points を翻訳したものです。) 半導体の検証チームは EDA（Electronic Design Automation）ツールを使い、毎晩数千件のシミュレーションジョブを実行しています。大規模な検証環境では 1 晩に 10 万件以上のテスト実行のログが生成されることもあります。1 回のリグレッションテストではシミュレーションログ、コンパイルログ、ジョブスケジューラーのログが出力されます。失敗が数十件に及ぶリグレッションテストでは手作業によるトリアージ（失敗原因の切り分け）に通常 45～60 分を要します。多数の失敗に共通する根本原因の特定には数日を要することもあります。現状ではエンジニアが SSH で接続し、grep でシミュレーション結果を検索して、複数のターミナルでジョブスケジューラーのログと照合しています。独自のスクリプトを開発するチームもありますが、継続的な保守が必要なうえ、ほかのテストスイート（リグレッションテストで実行するテスト群）への展開も困難です。ログファイルは高性能な共有 NFS ストレージにすでに格納されています。課題はこれらのログを、複数のファイルを読み込んで内容を突き合わせられる AI サービスから参照可能にすることです。そのためには取り込み用のパイプラインを構築するか、データを Amazon Simple Storage Service（Amazon S3） にコピーする必要があります。 本記事では既存のワークフローを妨げず、データも移動せずに、EDA の検証ワークフローと AI による分析を連携させるアーキテクチャを紹介します。このアーキテクチャでは Amazon FSx for NetApp ONTAP 、 Amazon S3 Access Points 、 Amazon Bedrock AgentCore 、 Amazon Quick を使用します。 FSx for ONTAP の S3 アクセスポイントを使うと、AWS のサービスから S3 API で検証ログにアクセスできます。データはファイルシステム上に保持されたままです。AgentCore はツールを利用できる AI エージェントをデプロイするマネージドサービスです。Amazon Quick は自然言語による問い合わせやワークフローの自動化を AI で実現する分析サービスです。エンジニアが Amazon Quick で「昨夜の失敗の原因は何か」と質問すると、シミュレーション、コンパイル、ジョブスケジューラー（LSF）の各ログを突き合わせた分析結果が数分以内に返されます。根本原因の分析が迅速になれば、エンジニアは手作業のトリアージに費やしていた時間を削減してバグの修正に注力でき、テープアウトまでの期間も短縮できます。 ソリューションの概要 図 1 にソリューションのアーキテクチャを示します。EDA ツールは NFS 経由で FSx for ONTAP にログデータを書き込みます。ログデータには S3 アクセスポイントを介して S3 API でもアクセスできます。エンジニアがログファイルを参照する経路は 2 つです。要約を素早く得るためのナレッジベースの経路と、複数のファイルを横断して詳しく調査するためのエージェントの経路です。 図 1: EDA ツールは NFS 経由で FSx for ONTAP にログを書き込みます。ログには S3 アクセスポイントを介して S3 API でアクセスできます（ゼロコピー、読み取り専用）。エンジニアはナレッジベースの経路か、エージェントの経路（MCP ゲートウェイ）でログを参照します。 訳注 ナレッジベースの経路（RAG）: ログデータから事前に作成したインデックスを基に回答する経路です。 エージェントの経路: AI エージェントがログファイルを直接読み込み、複数のファイルを横断して調査する経路です。 MCP（Model Context Protocol）: AI エージェントが外部のツールやデータを利用するための標準プロトコルです。 FSx for ONTAP に保存されるログファイル EDA ツールは計算クラスター上でシミュレーションやコンパイルのジョブを実行します。各ジョブは NFS 経由で FSx for ONTAP のボリュームにログファイルを書き込みます。この既存のワークフローを変更する必要はありません。ログデータは FSx for ONTAP に集約され、ここが正本（Single Source of Truth）となります。ログは共有ストレージ上の /mnt/fsx/logs/ のようなプロジェクトディレクトリ配下に格納されます。 FSx for ONTAP の S3 アクセスポイント ログを格納したボリュームに S3 アクセスポイントをアタッチすると、S3 API によるアクセスが可能になります。アクセスポイントには読み取り権限のみを持つファイルシステムユーザーを関連付け、アクセスポイント経由の操作を読み取りに限定します。EDA ツールは従来どおり NFS 経由で書き込みを続けます。同時に、AWS のサービスは S3 API 経由でデータを読み込みます。S3 アクセスポイントは AWS CLI の create-and-attach-s3-access-point コマンドで作成します。 ナレッジベースの経路（RAG） Amazon Quick は自然言語による問い合わせ、ビジュアルダッシュボード、ワークフローの自動化を単一のインターフェイスでエンジニアに提供します。検索拡張生成（RAG: Retrieval Augmented Generation）を用いるこの経路では、Amazon Quick が S3 アクセスポイントからログデータを同期してインデックスを作成し、ナレッジベースに格納します。Quick のチャットエージェントはリクエストのたびにログファイルを読み込むのではなく、作成済みのインデックスから回答します。そのため、「昨夜はいくつのシミュレーションが失敗したか」のように、要約を素早く得たい質問に適しています。 エージェントの経路（MCP ゲートウェイ） AgentCore は MCP ゲートウェイをホストします。ゲートウェイに登録した AWS Lambda 関数は S3 アクセスポイントを介して FSx for ONTAP のファイルを問い合わせのたびに読み込みます。MCP ゲートウェイはエージェントに次の 3 つのツールを提供します。 List – ディレクトリの一覧を取得する Read – S3 のファイルを読み込む Search – S3 のファイルを横断して検索する シミュレーションログの読み込み時は、Lambda 関数が S3 アクセスポイントに対して GetObject（ファイルの取得）を呼び出します。実行済みのリグレッションテストを一覧で確認する際は、ボリューム上のパスに対して ListObjects（ファイルとディレクトリの一覧の取得）を呼び出します。エージェントは自律的にディレクトリをたどって複数のログを読み込み、詳細なトリアージレポートを生成します。この経路は「AXI タイムアウトによる失敗の根本原因は何か」のように、複数のファイルにまたがる、より詳細な分析が必要な質問に適しています。 仕組み たとえば、エンジニアが Amazon Quick で「昨夜はいくつのシミュレーションが失敗したか。最も多いエラーは何か」と質問したとします。Amazon Quick はこの質問を AgentCore 上の MCP エージェントに渡します。エージェントはツールを使い、リグレッションテストの結果を格納したディレクトリの一覧を取得します。続いて、終了コードが 0 以外のログファイルを特定し、関連するシミュレーションログと LSF のログを読み込みます。複数のファイルにわたるエラーのパターンを突き合わせ、失敗の種類ごとに件数と影響を受けたモジュールをまとめて返します。エージェントはさらなる質問にも回答できます。この経路では事前に作成したインデックスではなく、問い合わせの時点で S3 アクセスポイントを介して FSx for ONTAP のファイルを読み込みます。そのため、回答には問い合わせ時点のファイルシステム上のデータが反映されます（ 図 2 ）。 図 2: トリアージに関する質問例と、AI が生成した回答を表示した Amazon Quick のチャット画面 すべてのコンポーネントはお客様の仮想プライベートクラウド（VPC）内で動作します。S3 アクセスポイントは AWS Identity and Access Management（IAM） のポリシーと、ファイルシステムのアクセス権限の両方を適用します。ログデータを読み取れるのは許可されたサービスに限られます。この構成では、書き込みは NFS 経由に限定されます。 S3 アクセスポイントにより、AWS の分析サービスや AI サービスから S3 API でログデータにアクセスできます。AgentCore と Amazon Quick はこのパターンの実装例の一つです。 Amazon Athena 、 AWS Glue 、独自に開発した Lambda 関数などのサービスも、同じアクセスポイントを介して同じデータにアクセスできます。 ダッシュボードとワークフローの自動化 エージェントによるログ分析に用いる S3 アクセスポイントは、ダッシュボードによる可視化とワークフローのスケジュール実行にも利用できます。 リグレッションテストの状況を可視化するダッシュボード Amazon Quick Sight は S3 アクセスポイントを介して、FSx for ONTAP から構造化された集計データを読み込めます。検証チームのマネージャーは毎朝ブラウザでダッシュボードを開くだけで、スクリプトを実行せずに夜間のリグレッションテストの現状を把握できます。ダッシュボードにはモジュールごとのパス／フェイル率、失敗の種類の内訳、カバレッジのヒートマップ、リソース使用率の推移が表示されます。ファイルシステムに新しいリグレッションテストのデータが追加されると、ダッシュボードは自動的に更新されます。 図 3: モジュールごとのパス／フェイルと失敗の種類の内訳を表示した Amazon Quick Sight のリグレッションテストのダッシュボード ワークフローのスケジュール実行 Amazon Quick Automate を使うと、毎晩のリグレッションテストの完了後にワークフローをスケジュール実行できます。たとえば、毎日のトリアージを自動化するワークフロー（ 図 4 ）では、チームの始業前に失敗の概要をまとめてメールで送信可能です。カバレッジを監視するワークフローでは、モジュールのカバレッジが設定したしきい値を下回った時点でアラートを送信可能です。ライセンスを監視するワークフローでは、繰り返されるチェックアウトの失敗を検知し、インフラチームに通知可能です。 これらのワークフローも S3 アクセスポイントを介して FSx for ONTAP から同じログデータを読み込みます。エンジニアは独自のスクリプトの開発や cron ジョブの保守を行う必要がありません。 図 4: 朝のトリアージレポートを自動生成する Amazon Quick Flows のフロー 検証のトリアージ以外のユースケース 同じアーキテクチャは NFS ストレージにログデータを出力するほかの EDA ワークフローにも適用できます。たとえば、論理合成のタイミングレポートの分析、物理検証（DRC/LVS）の結果、電力解析の出力、設計ドキュメントの生成です。構造化または半構造化されたログを FSx for ONTAP に書き込むワークフローであれば、このパターンを活用できます。 まとめ EDA の検証チームは毎晩大量のログデータを生成します。このデータは高性能な NFS ストレージに格納されていますが、分析は手作業のままでした。FSx for ONTAP の S3 アクセスポイントを使えば、AI サービスから S3 API で同じデータにアクセスできます。データのコピーや移動は不要です。AgentCore と Amazon Quick を組み合わせると、エンジニアはリグレッションテストについて自然言語で質問できます。回答はシミュレーション、コンパイル、ジョブスケジューラーの各ログを突き合わせて分析したものです。これまで 45～60 分を要していた毎日のトリアージは、数分以内での完了が可能になります。ログデータは FSx for ONTAP に保持したまま、NFS と S3 API の両方から同時にアクセスできます。S3 アクセスポイントは AI サービスが同じデータを活用して有益な知見を得るための、独立した読み取り専用の経路となります。その結果、検証クロージャーの短縮とエンジニアの生産性向上につながります。チームは何時間もかけてバグのトリアージを行うのではなく、バグの修正から 1 日を始められます。 このアーキテクチャを実際に試すには、FSx for ONTAP と S3 アクセスポイントを扱う ワークショップ について AWS のアカウントチームにお問い合わせください。このソリューションで使用するサービスの詳細は、次の資料を参照してください。 Amazon S3 アクセスポイントを介したデータへのアクセス Enabling AI-powered analytics on enterprise file data: Configuring S3 Access Points for Amazon FSx for NetApp ONTAP with Active Directory Amazon Bedrock AgentCore 開発者ガイド Amazon Quick ユーザーガイド Vinayak Datar Vinayak Datar 氏はサンフランシスコ・ベイエリアを拠点とする AWS の Senior Customer Solutions Manager です。半導体業界のお客様が AWS のサービスを使って EDA ワークロードを移行し、モダナイズする取り組みを支援しています。「GenAI Ambassador」として、Amazon Quick や Amazon Bedrock をはじめとする AWS の生成 AI サービスを使ったソリューションの導入を推進しています。 Ratna Dasari Ratna Dasari 氏は AWS の Senior Solutions Architect です。半導体業界のお客様と密に連携し、クラウド活用とデジタルトランスフォーメーションの戦略の策定と実行を支援しています。半導体業界で 20 年以上の経験を持ち、その深い業界知見をお客様の支援に生かしています。革新的なソリューションを主導・設計し、大規模に提供することでビジネス価値を創出してきた豊富な経験を有しています。 翻訳はソリューションアーキテクトの酒井 賢が担当しました。原文は こちら です。

はじめに 本記事は、 株式会社レスター （以下、レスター）の加瀬 友基 氏による寄稿記事です。 レスターでは、各社・各部門に分散していた営業情報を一つの土台に集める AI 情報プラットフォームを構築しています。中核となるレスターマッチングサービス（以下、RMS）は、顧客ニーズと企業・技術・製品などの解決手段を結びつけるマッチングの仕組みであると同時に、顧客・仕入先、取引実績、担当者との接点、商材、案件、議事録などを相互の関係性を保ったまま蓄積する、グループ共通のデータウェアハウスです。商談時の録音データを AI が議事録としてデータ化し、RMS へ取り込み、AI チャットボット機能で RMS 内の蓄積された情報から必要な知見を引き出します。これにより、ある部門がつかんだ顧客課題を、別部門が持つ人・商材・技術へつなげます。本稿では、この仕組みを構築した背景、Amazon Web Services（以下、AWS）の活用、そして情報を蓄積し続けるための運用についてご紹介します。 レスターとは レスターグループは、「情報と技術で、新しい価値、サービスを創造・提供し、社会の発展に貢献します」の経営理念のもと、半導体・電子部品の販売・ソリューション提供をはじめ、映像・音響・通信機器の取り扱い、太陽光発電などの再生可能エネルギーの企画・オペレーション、完全閉鎖型植物工場の運営、ソフトウェア開発、産業用PCの設計・製造など多岐にわたる事業活動を行っています。 グループの多様な強みを一つの提案力に変えるために 事業領域の拡大とグループ再編の結果、グループが持つ顧客基盤、商材、技術、知見は大きく広がりました。一方で、各社・各事業は、もともとの顧客や商流、情報の持ち方、業務プロセスが異なります。子会社・事業・部門が「どの顧客と接点を持ち、何を得意とし、どのような商材や知見を持つのか」を、日々の営業活動の中で十分に把握することは容易ではありませんでした。 お客様の課題は、必ずしも一つの事業領域だけで完結するものではありません。グループ内に解決手段があっても、必要な情報や担当者にたどり着けなければ、提案にはつながりません。グループの多様な強みを一つの提案力に変えるためには、会社・事業・部門を越えて情報を見つけ、活用できる仕組みが必要です。レスターは「あらゆるニーズに対応できる『エレクトロニクスの情報プラットフォーマー』」をビジョンに掲げています。このビジョンが目指しているのは、例えばステークホルダーの課題を自部門の知識だけで答えるのではなく、グループ全体から最適な人・商材・技術を探し出し、事業横断で提案できる状態を指しています。一つひとつの顧客課題と、グループが持つ多様な解決力を結び付け、あらゆるニーズに応えられるエレクトロニクスの総合商社へと進化することを目指しています。 現場で起きていた、4 つの情報の断絶 背景にある課題を営業の現場で分解すると、単に情報が複数のシステムへ分散していたというだけではありません。会社・事業・部門の境界を越えて、情報の所在と文脈を理解し、次の行動へ移すまでの各段階に断絶がありました。 商談内容の属人化 : 商談の詳細は個人のメモやファイルに残り、組織の知識になりにくい SFA では残らない文脈 : 営業支援システム（SFA）は案件金額や進捗管理に有効でも、顧客の背景や会話の文脈までは十分に残りにくい グループ理解の属人化 : 会社・事業への理解が担当者の経験に依存し、他部門の得意分野、取扱商材、顧客接点まで把握しにくい 訪問前準備の負荷 : 情報収集が担当者の経験と人脈に依存し、訪問前準備に時間がかかる この状態でチャットボットだけを導入しても、参照する情報が古い、少ない、偏っているという問題は解消しません。私たちは、情報が生まれる現場から、会社・事業を越えた蓄積、検索、提案までをつなぐ必要があると考えました。 RMS を中核に、商談の会話から次の提案までをつなぐ こうした 4 つの情報の断絶を解消するため、情報の流れを「データ化する」「蓄積・統合する」「引き出し、提案へつなぐ」の 3 段階に整理しました。それぞれを AI 議事録、RMS、AI チャットボットが担い、商談で得た情報が次の提案に使われるまでを一本につなぎます。 図 1：顧客課題とグループの解決力をつなぐ情報プラットフォーム 1. AI 議事録：会話を「検索できる営業資産」に変える AI 議事録では、オンライン会議や対面商談の録音データと、会議で使用した資料を取り込みます。音声ファイルを Amazon Simple Storage Service (Amazon S3) に保存し、Amazon Transcribe で文字起こしと話者分離を行います。その結果を Amazon Bedrock 上の Anthropic Claude に渡し、会議概要、発言内容、顧客課題、決定事項、次回アクションなどを所定の形式で整理します。生成した議事録や案件情報は、必要に応じて RMS や SFA へ連携します。 Amazon Transcribe では、独自の音声認識モデルを構築することなく音声をテキスト化し、話者分離によって複数人の会議を発言者単位で整理できます。Amazon Bedrock については、社内外の商談情報を扱うため、安全性と統制を効かせながら生成 AI を利用できる点を重視しました。 従来、議事録は会議後の記録作業でした。今回の構想では、議事録を営業データの入口と位置づけています。会話には、顧客の言葉、困りごとの背景、検討状況、関係者、次の打ち手といった、SFA の数値項目だけでは表現しきれない鮮度の高い情報が含まれるためです。 2. RMS：全社の営業情報をつなぐデータウェアハウス RMS には、顧客・仕入先の基礎情報、取引実績、名刺・接点、従業員、商材、SFA の商談情報、Web サイト経由の問い合わせ、そして AI 議事録などを集約しています。単にファイルを保管するのではなく、顧客、担当者、商材、課題、案件の関係性を保ったまま蓄積することが特徴です。 この構造により、顧客を起点に、グループ各社の取引実績、過去の商談、社内の担当者、関連する商材や解決策を横断的にたどることができます。部門ごとに分かれていた情報を、次の提案に使える形で結びつけることが RMS の役割です。 また、レスターグループ各社で取り扱っている多様な商材ごとにビジネスオーナーを置き、内容の最新化、公開範囲、分類を管理する運用を整えています。AI の回答品質は、モデルの性能だけでなく、参照データの鮮度と網羅性に左右されます。そのため、コンテンツマネジメントをシステム運用の一部ではなく、事業側の役割として設計しました。 3. AI チャットボット：必要な情報を引き出し、次の一手へつなぐ AI チャットボットは、RMS に蓄積された情報を業務で使うための対話型インターフェースです。LangGraph で構築した AI エージェントを Amazon Bedrock AgentCore Runtime 上で動作させ、RMS から呼び出した回答をストリーミング表示します。独自に設計した検索・回答の処理を維持しながら、AWS 上の実行環境として RMS と連携できる点を評価しました。 社内文書や議事録の検索には、Amazon Bedrock Knowledge Bases と、そのベクトルストアである Amazon OpenSearch Serverless を利用しています。Amazon S3 は元データの保管先であり、質問のたびにファイルを直接検索するのではありません。会社、商材、案件、担当者などの構造化データが必要な場合は、Catalog API を通じて PostgreSQL から取得します。標準設定では外部 Web 検索を行わず、社内情報に基づく回答を優先しています。 代表的な利用シーンは次の通りです。 訪問前準備 : 対象企業の取引実績、接点、過去の議事録、進行中の商談をまとめる クロスセル : 別部門の議事録にある潜在ニーズと、グループ内の商材・ソリューションを結びつける 提案準備 : 顧客の状況に応じた提案の骨子やトークスクリプトを作る 社内探索 : 商材の担当者、類似案件の経験者、協業可能な部門を探す 利用場面に応じたボタンを用意しており、選択すると「明日この会社へ訪問するので、グループ全体の取引と商談を整理して」といった質問文が自動入力されます。利用者は最初から精緻なプロンプトを書く必要はなく、回答を見ながら追加質問で深掘りできます。回答は結論ではなく、営業が原典や担当者を確認し、次の行動を考えるための出発点です。 AWS を活用した構成と、安全な利用のための設計 AWS を採用した理由は、音声データの保管、文字起こし、議事録の生成、社内情報の検索、回答生成までを、一つのクラウド環境で連携できることです。Amazon S3、Amazon Transcribe、Amazon Bedrock、Amazon Bedrock Knowledge Bases、Amazon OpenSearch Serverless、Amazon Bedrock AgentCore Runtime を組み合わせることで、システム間連携の複雑さを抑えながら、情報が増え続ける前提の基盤を構築しました。また、当社の汎用生成 AI 環境では、AWS がオープンソースで公開する Generative AI Use Cases（GenU） も活用し、そこで得た知見を社内ユースケースの設計に生かしています。 図 2 は、RMS、AI 議事録、AI チャットボットと、今回利用している主な AWS サービスの関係を示したものです。 図 2：AI 情報プラットフォームの AWS アーキテクチャ 主な AWS サービスと役割 Amazon S3 : 音声・資料・正規化済みドキュメントの保管 Amazon Transcribe : 音声の文字起こしと話者分離 Amazon Bedrock : Anthropic Claude による議事録の要約・構造化と、チャット回答の生成 Amazon Bedrock AgentCore Runtime : LangGraph で構築した AI エージェントの実行 Amazon Bedrock Knowledge Bases / Amazon OpenSearch Serverless : 社内文書・議事録の RAG 検索 Amazon Bedrock では、入力したデータや生成結果が基本モデルの改善に使用されることはなく、モデルプロバイダーと共有されることもありません。また、Amazon Bedrock 内のデータは転送中も保管中も暗号化されます。商談や取引に関する情報を扱うため、こうした AWS 側の仕組みに加え、レスター独自の権限設定と運用ルールを設けています。主な対策は次の通りです。 録音時の同意 : 社外商談は事前に相手先の許可を得る 参照対象の選択 : 議事録ごとに社内 AI チャットボット回答時の参照対象へ含めるかを選択し、秘匿性の高い会議は除外する 競合情報の制御 : 担当サプライヤーに応じて競合情報の閲覧を制限する仕組みを設ける 人による最終判断 : AI 回答は参考情報として扱い、重要な判断や社外提出前には原典・担当部署を確認する 特に、「AI に学習させる」という言葉は、モデル自体の追加学習と RAG での参照を混同しやすいため、運用説明では「社内 AI 回答時の参照対象に含めるか」と表現するようにしています。技術的な安全性だけでなく、利用者が誤解しない言葉を選ぶことも重要だと考えています。 導入で難しかったのは、技術よりも「情報が集まり続ける運用」 AI チャットボットの回答は、参照する情報以上には良くなりません。特定の利用者だけが議事録を登録すれば、回答もその部門や担当者に偏ります。商材情報が更新されなければ、AI は古い内容を基に回答します。 そこで、半導体・電子部品を扱うデバイス事業部門から段階的に利用を開始し、社員を対象とした説明会（延べ 500 名以上が参加）、商材ビジネスオーナーへの登録レクチャー、利用フィードバックの回収を実施しました。スマートフォンから録音・登録できる導線も整え、現場が無理なく情報を残せるよう改善を続けています。 運用上の学び : 情報を集めたい運営側は入力項目を増やしがちですが、現場はまず「楽になること」を求めます。AI 議事録で日常業務の負担を下げ、その結果として質の高いデータが蓄積される順序が重要でした。 現在の活用と、見えてきた効果 情報を蓄積する側では、AI 議事録が営業データの入口として回り始めています。社内調査を基に、1 件あたり約 23 分の議事録作成時間を削減できると試算しており、2026 年 7 月現在、月間 2,000 件を超える議事録が作成されています。ただし、私たちが重視しているのは削減時間よりも、毎月 2,000 件を超える商談・会議の情報が、統一形式で検索・分析・再利用できるデータとして蓄積されていく点です。長期的にはこちらの方が大きな価値を生むと考えています。 情報を引き出す側では、2026 年 6 月に AI チャットボットを公開し、利用データと現場の声を基にチューニングを続けています。RMS には取引・接点情報、AI 議事録、SFA 情報、商材情報などが連携され、これまで人に聞くか複数システムを調べていた作業を、1 つの対話画面から始められるようになりました。たとえば、訪問先についてグループ内の取引金額と担当者、過去の商談経緯をまとめる、別部門の顧客課題に対して自部門のソリューションを提案できないか探索する、特定製品を扱う担当者と関連商材を同時に確認する、といった使い方が始まっています。 一方で、現時点は完成形ではありません。登録されていない取引や議事録があれば回答には現れず、情報を入力する利用者が偏れば結果にも偏りが出ます。こうした不足を可視化し、システム、データ、運用の 3 つを同時に改善できることも、パイロット運用の成果だと捉えています。 今後の展開：事業横断で、提案と行動を生む基盤へ 生成 AI を業務に定着させるために必要なのは、高性能なモデルだけではなく、日常業務の中で情報が生まれ、整い、使われ、更新され続ける仕組みです。AWS では、AI を安全に利用するための機能が揃っており、新しい機能も継続的に追加されるという点で、当社の取り組みのような社内横断的な情報の整備、AI 活用を推し進めることができると考えています。今後は、顧客ニーズとグループ内の商材を継続的に照合し、AI が提案候補や新規開拓リストを提示する仕組み、部門を越えて適切な担当者や知見へつなぐ仕組みも検討しており、実際の利用状況と蓄積データを見ながら、顧客・商談・商材・担当者・議事録の関係性をより活用しやすい形へ発展させます。 営業担当者個人の経験や人脈だけに依存せず、ある部門が捉えた顧客課題を、別部門の商材やソリューションへつなげます。半導体・電子部品からシステム、映像・通信、エネルギーまで、レスターグループが持つ幅広い解決手段を一つの営業基盤から活用できる状態を目指します。目指しているのは、社内検索の効率化だけではありません。顧客との会話から課題を捉え、グループ全体の知識と解決手段を組み合わせ、顧客自身も気づいていない潜在ニーズに対して最適な解決策を提案できる営業基盤です。その結果として、新しい顧客と新しいビジネスが継続的に生まれる状態を目指します。 おわりに レスターが構築しているのは、単体のチャットボットではなく、営業活動で生まれた情報を会社の資産に変え、再び営業へ戻す仕組みです。商談の会話がデータになり、関係性を保ったまま蓄積され、必要なときに引き出される。この循環が回るほど、商談を重ねた分だけ会社の知識が積み上がり、事業横断の提案力が高まります。AWS のサービスを活用しながら、この情報循環をレスターグループ全体へ広げ、各事業の強みを一つの提案力へ変えていきます。「まずレスターに相談すれば、解決の糸口が見つかる」という世界を実現し、「エレクトロニクスの情報プラットフォーマー」というビジョンにつなげていきます。 著者について 加瀬 友基（Yuki Kase） 株式会社レスター Data Analysis Management データドリブン経営を担当し、グループ内外のデータを統合・分析する情報プラットフォーム戦略を推進。データと AI を活用し、商社機能の進化と新たな事業・顧客価値の創出に取り組む。