法人のお客さま
お問い合わせ
ビジネスブログ

人の代わりにクラウド設計構築やテクニカルサポート業務を支える検索エンジン基盤開発の取り組みについて（デモ付き）

大原 陽宣

batch/OLAP Software Engineer, SREs
大原 陽宣

2022年12月21日掲載

キービジュアル

こんにちは、大原です。

この記事は、ソフトバンク Advent Calendar2022の21日目の記事になります。

 私の部署ではテクニカルサポート業務として、日頃からパブリッククラウドサービスに対するお客様のさまざまな問い合わせを調査し回答する取り組みをしており、同時にパブリッククラウドサービスを通じて新しい技術要素などの取得・サービス改善や情報発信に励んでいます。 そうした活動をもっと外部へ発信しよう、というのが本記事の趣旨となります。

目次

はじめに

私が担当するチームにはパブリッククラウドのテクニカルサポート業務というものがあります。テクニカルサポート業務は、お客様、プリセールス、ソリューションアーキテクト、営業などからパブリッククラウドサービス技術要素に関するチケットや問い合わせに対し、調査し、回答するミッションがあります。

チケットを投稿した人は、ヘルプドキュメントやインターネットなどを色々調べてもわからないから、疑問点や問題点を解決したい一心でチケットを投稿したと思います。ですから、テクニカルサポート部隊として、その問題を綺麗に解決するために真摯かつ丁寧に調査し、チケット投稿者が納得いく回答が提供できるよう日々努めています。

しかし、その過程において調査作業は非常に大変です。パブリッククラウドサービスは日本語外、すなわち英語、中国語による公式ドキュメントが展開されているので、様々な言語に合わせて検索したり、チケットの問い合わせ内容に専門用語やプロダクトサービス名が含まれてなく曖昧な内容でも関連単語を連想しながら検索する必要があります。

そして、ヘルプに載っている情報に基づいて、必要に応じてサービスが意図した通りに挙動するかどうか検証を行い、問題切り分けやチケット回答のための回避策等アクションを執ります。最後に、クラウドサービスは変化が速く、私たちクラウドエンジニアリングでも把握しきれていない仕様変更やリリースノート、ヘルプドキュメントに載っていない仕様変更もいくつか存在します。

こういった大量の情報の荒波をサーファー並にうまく攻略するために、独自の検索エンジンを開発しています。その結果はテクニカルサポート業務を通じて、お客様のサービス満足度向上に結び付けたいと願っています。

1.なぜ独自の検索エンジンが必要なのか？

私たちテクニカルサポート業務として、お客様、営業部隊、プリセールス部隊などからパブリッククラウドの技術的要素に関する問い合わせが都度発生します。

テクニカルサポート業務といえば、受け身、コールセンター、クレーム、謝罪、スキルも身につかない、などネガティブなイメージがあります。しかし、ソフトバンクはバリューというのがあり、テクニカルサポート部隊は「No.1」「挑戦」「逆算」「スピード」「執念」という心構えを持って、日々攻めのテクニカルサポート業務を遂行しています

ソフトバンクバリュー（ソフトバンク採用情報ページより） ソフトバンクバリュー（ソフトバンク採用情報ページより）

この心構えのもと、テクニカルサポート業務のショートカットを行いたいコンセプトで、テクニカルサポートチームは検索エンジンを独自開発しています。なぜ検索エンジンなのでしょうか？それは現在のテクニカルサポート業務の8割が検索・調査メインだからです。

例えば、実際にあった質問：

「パブリッククラウドサービスのRDSログはMySQLなどデータベースが付帯するログとは別にどういう種類のログを持っているか？」

「AWS RedshiftにあるデータをAWS S3にデータを保存する場合はどのようなパターンがあるか？」

「Google Cloud Spannerでクライアントライブラリによる2種類の自動リトライ機能があるが、gRPC処理が失敗した場合トランザクションごとに自動リトライされます。その際にExecuteSQL Requestが2回目まではABORTされるのはなぜでしょうか？」

これをGoogleやYahoo検索しても、当然答えはすぐに出ないです。もちろん、パブリッククラウドサービスの検索バーや他社ブログからも同様です。こういう質問は、テクニカルサポートの人が質問者の意図を把握し、ヘルプページやドキュメントを直接解読しながら、仕様や構造を理解し、事実に沿った回答をする必要があります。

すごくシンプルで当たり前ながら、実は結構ハードワークです。なぜなら、ヘルプページは英語、中国語、日本語が混合展開しているため複数の言語で調査するうえ、過去ナレッジ集、社内ドキュメント、必要に応じてインターネット上で英語、中国語、日本語による検索も行うからです。

それでも答えなければパブリッククラウドサービスの開発チームに直接問い合わせたりしますが、AWSやAzureなど扱う顧客数や会社規模が大きい大手クラウドほど答えがすぐ出なかったり、スルーされることが日常茶飯事です。

こういった検索業務の負荷を減らしつつ、「調べる」をもっと楽にしたい、という狙いのもと、ソフトバンクのパブリッククラウドサービスを担当するクラウドエンジニアリングのテクニカルサポートは独自の検索エンジン基盤を独自開発しています。

2.検索エンジンの種類について

先に、検索エンジンの種類について説明します。

・全文検索

検索クエリのテキスト文字列を使って、テキスト全文から文字列マッチングを行うアプローチです。Linuxだとsed・awkコマンド、SQLクエリだと条件分岐にLIKE演算子を使うようなパターンです。このやり方は言語に依存することなく高速で検索を行うことができますが、検索クエリのテキスト文字の表示順序が反対もしくは別の構文であれば検知しにくいデメリットもあります。

・セマンティック検索（ベクトル類似検索）

検索クエリ（文字列や画像など）を直接テキスト全文などデータベースへ照合せずに、事前に高次元ベクトルとしてエンコードしたニューラルネットで近似値から検出するアプローチです。

例えば、テキスト文章による検索であれば、事前に検索クエリおよびテキスト全文をword2vec（Word to vector）などで全ての単語を数百次元以上のベクトル化しながら、検索クエリに対する関連性の高い対象ベクトルを拾うことで、こうして関連文書検出ができます。ベクトル空間での距離を測る方法はコサイン類似度と呼ばれます。ユークリッド距離も似たアプローチです。

コサイン類似度のベクトルとして−1から1の範囲の値で表示され、向きがそろっているほど大きくなり、反対向きになるほど値が小さくなります。コサイン類似度の評価式は次の通りです。

このアプローチであれば、検索クエリが曖昧もしくは、答えが見つからない場合でも、検索意図を検索エンジン側が理解しながら、キーワードに応じた検索結果を提供することができます。このようにセマンティック検索（ベクトル類似検索）は現在画像類似検索、ビデオ類似性検索、レコメンデーション検索、タグ分類検索、など幅広く活用されている技術です。

・参考：絵で理解するWord2vecの仕組み

なお、著者は過去にElasticsearchで自由かつカスタマイズできる類似画像検索サービスを提供しています。この資料はAlibaba Cloud Elasticsearch向けですが、この手法はAWS、Azure、オープンソースのElasticsearchでも適用しながらElasticsearchによる画像のセマンティック検索が実現できます。

参考：Alibaba Cloud Elasticsearch勉強会資料

・ODQA（Open Domain Question Answering）

Open Domain Question Answering（ODQA）はユーザーが検索クエリに質問文を入力したら、文章でなく答えを返却するアプローチです。ODQAシステムはヘルプページやWikipediaなど質問に関連するテキスト文書を大規模な文書集合体（データセット・モデル）として検索するためのDocument Retriever層と、検索した関連文書を用いて質問の回答を抽出するためのDocument　Reader層の２つのコンポーネントで構成されます。

Document Retrieverは検索クエリの質問文およびテキスト文書全体（データセット）を解読しながら検索エンジンに渡す役割があります。通常は文章内の単語の重要度を示すTF-IDFなどを使用して実装します。

Word2VecやBEATの組み合わせもできます。TF-IDFは文章全体からみて、それぞれの単語がどれほど重要であるかを数値統計するため、検索クエリの質問文およびテキスト文書全体は一定の方向性と共通性を持った数百次元以上のベクトルへ変換しながら、先述通りセマンティック検索と同様にコサイン類似度で抽出を行います。

先述のセマンティック検索との違いは、文章単位でTF-IDFベースでコサイン類似度によるランク付けをするため、テキスト文書全体から回答に一致するContext（テキスト一句、パッセージ）に分割し、それらをコサイン類似度で抽出フィルタリングすることで、質問に対する回答に必要な判定素材情報（関連文一句一句の集まり）をDocument Readerへ橋渡しすることができます。

Document Readerは質問に対する回答抽出のために読解アルゴリズムをテキストセグメントに適用する役割を持つため、先述通りDocument Retrieverによって回答判定素材が揃った状態から処理を始めます。Document Readerは一連のNLPモデル（品詞のタグ付けや名前付きエンティティの認識、正規表現パターンマッチング、命名規則など）を使って、Document RetrieverからのContext（パッセージ）を精査し、識別しながら回答を行います。

・Intro to Automated Question Answering
　https://qa.fastforwardlabs.com/methods/background/2020/04/28/Intro-to-QA.html

・Reading Wikipedia to Answer Open-Domain Questions
　https://arxiv.org/abs/1704.00051

・Dense Passage Retrieval for Open-Domain Question Answering
　https://aclanthology.org/2020.emnlp-main.550/

・ACL2020 Tutorial: Open-Domain Question Answering
　https://github.com/danqi/acl2020-openqa-tutorial

・DrQA
　https://github.com/facebookresearch/DrQA

このODQA（Open Domain Question Answering）技術は20年以上も昔からあり、現在Google検索やsiri検索、Alexaなどにも使われています。

モデル学習はTF-IDFのほか、DrQAやSQuADなどが有名です。これらは回答アプローチや目的によって異なってきます。

もし、テキスト文書全体（データセット）に回答箇所がなくても、RAGモデルであればRAGは答えとなる文章を生成するというODQAアプローチもあります

＜参考＞
・Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
　https://arxiv.org/abs/2005.11401

・【論文解説】Open Domain Question Answering 『RAG』を理解する
　https://data-analytics.fun/2021/06/03/understanding-rag/

・Kaggle「chaii - Hindi and Tamil Question Answering」コンペで2位入賞したお話 & 解法解説
　https://techblog.exawizards.com/?page=1648631364

・Latent Retrieval for Weakly Supervised Open Domain Question Answering
　https://arxiv.org/abs/1906.00300

・How to Build an Open-Domain Question Answering System?
　https://lilianweng.github.io/posts/2020-10-29-odqa/


余談ですが、この技術は近年非常にHotであり、海外ではAIクイズ大会、国内では「AI王 クイズ問題をAIが解く日本一決定戦」というコンペが流行っています。

なお、Elasticsearch 8.3からドキュメントを使った質疑応答NLPタスク機能が実装されています。現状どのクラウドサービスでもまだ実装されていないので、実装する時が待ち遠しいですね。

<参考>
・[ML] adds new question_answering NLP task for extracting answers to questions from a document #85958

・Elasticsearchによる質問応答 ～NLP機械学習モデルの利用～

・質疑応答検索（会話型検索）

一言でいえば、先述、ODQA（Open Domain Question Answering）技術を応用した、会話型で質疑応答しながら情報検索をするアプローチです。

基本的なコアアーキテクチャはODQAとあまり大差ないですが、継続しながら強化学習が行え、回答に対する精度向上ができる部分が大きいです。

Meta Research（Meta AI研究所、旧名：Facebook AI Research）による 「ParlAI」という、リアルタイム会話しながら質疑応答で疑問点をコミュニケーションしながら解消するという検索サービスがあります。

その検索基盤は全ての検索技術要素をハイブリッド構成にしたうえで、モデルをEnd-to-end学習（一貫学習）するため会話ベースに合わせるため遅延も全くなし。GPT2/3ベースに新しい回答（返答）文章をAI側が自動作成しながら会話を提供します。インターネットを通じて外部から新しいデータセットのリアルタイム反映もできますし、最近流行っている「ChatGPT」も良いですが、学習を含めシステムの成長面や検索を通じて質疑応答というコンセプトではParlAIが統合的に上回っています。（参考記事）

筆者は専門でないこともあり、理解が部分的に追いつかなかったため、各種論文やこの記事などを精読しつつ、いつかは構造的に理解して現在の検索エンジン基盤に上乗せを期待したいところです。

＜参考＞
・ParlAI
　https://parl.ai/

・Teaching Models new APIs: Domain-Agnostic Simulators for Task Oriented Dialogue
　https://arxiv.org/abs/2110.06905

・対話モデルの訓練/評価フレームワーク ParlAI がすごい
　https://deeplearning.hatenablog.com/entry/parlai

・ParlAIで英会話を楽しみませんか？
　https://qiita.com/halboujp/items/342c88a7db17e07fe390

 

3.ソフトバンクのテクニカルサポートが目指す検索エンジン

テクニカルサポートが目指す検索エンジンはそれぞれ３つの重要な役割を持ちます。

・データセット

データセットはパブリッククラウドのヘルプページおよびソフトバンクのテクニカルサポートのナレッジ集からJSON形式で収集します。

パブリッククラウドのヘルプページは日々PuppeteerによってHTMLページから必要な箇所のみ汲み取ってJSON形式で保存しています。Alibaba Cloudの場合、その量は50万ファイルを超えます。

テクニカルサポートはチケットを通じてSA部隊や営業部隊、お客様との技術やり取りのスレッドをナレッジとして残しています。そのナレッジ集をサマリ化し、これも1チケット=1JSONファイル形式として保存します。（個人や企業を特定できるような各種情報はこの時点で完全に排除しています）

＜参考＞
毎日1時間でWebページ1,000以上のうち1pxの変化を逃さない、ソフトバンクのE2Eビジュアルリグレッションテスト取り組みについて

・検索基盤

テクニカルサポートが目指す質疑応答システムとして、検索基盤には2つのエンジンを搭載しています。1つはODQA（Open Domain Question Answering）、もう１つは関連文書検索です。

パブリッククラウドサービスのヘルプドキュメントに答えがあることを前提に検索する場合は、ODQAエンジンを使用して検索します。仮にパブリッククラウドサービスのヘルプドキュメントに答えがない場合、それに関連するドキュメントのURLを提供するアプローチです。

パブリッククラウドのヘルプページ（英語、日本語、中国語）およびテクニカルサポートのナレッジ集を全部データセットとして格納したのち、検索バーから質問文もしくはキーワードを入れることで検索を開始します。

検索バーは英語、日本語どちらを入れても問題ないし、検索バーのところで複数言語による各種検索処理を並行実行するため、異なる言語による結果をそれぞれ出力することができます。

・分析レポーティング

検索サービスとして、テクニカルサポート業務を支える検索基盤のみ提供だけで終わるのは非常に勿体ないと思います。テクニカルサポート業務として、誰が、どういう情報を求めているのか、どういう調査に工数がかかっているか、チケット対処の経緯等を分析・見える化することで、ソフトバンクのクラウドエンジニアリングとして不足していること、求められてるスキル、弱点箇所が色々浮かび上がります。

同時にテクニカルサポート業務を支える検索エンジンとして、パブリッククラウドサービスの問題や使い方をサポートするだけでなく、チケットを通じて、パブリッククラウドサービスがサポートできるシナリオの幅を広くすることも重要だと考えています。

チケットは実際に直面している課題を解決したいニーズなので、それを活かすことで次のビジネスアクションが生じるし、チケットを通じて新たなビジネス価値を創出するのは、攻めのテクニカルサポート業務による特権です。

 

検索エンジン基盤導入により、テクニカルサポート業務としての効果をBefore/Afterで表すと次の通りになります。

 

Before

After

検索頻度

・英語/日本語など異なる言語のヘルプページ毎に検索
・ナレッジ集など他コンテンツでも再度検索
・検索クエリ（ワード）に一致する文章のみ検出なので、検出後目視でフィルタリング等精査が必要

・１つの言語で1回限りの検索
・英語や中国語が苦手な人でも異なる言語による検索ができる
・検索クエリが曖昧もしくは質問文でも、それに対する回答および関連情報が素早く拾える
・結果、テクニカルサポート業務のショートカットへ

テクニカルサポート業務改善に対する姿勢

定量的測定ができていないため、
・チケット調査にかかった時間やボトルネック、情報不足している点がみえない

・人によって対応工数がかかる箇所の理由が特定できない

定量的測定ができるため、
・検索頻度の高いワードやプロダクトサービスなどを特定し、ソリューションへ活用可能
・不足している情報など弱点を特定できるため、ピンポイントで情報を補うことが可能

4.どのように構築しているか

検索技術は幅広くありますが、今回はMeta Research（Meta AI研究所、旧名：Facebook AI Research）によるオープンソースの検索関連技術を用いています。これを選定した理由はいくつかの理由がありますが、主に以下の通りです。

 

＜参考＞
Efficient QA 上位エントリのアプローチ

Track

順位

Retriever

Reader

自動評価

手動評価

Unrestricted

1位

DPR

FiD

54.0%

65.8%

Unrestricted

2位

DPR+GAR

FiD

53.9%

67.4%

6GB

1位

DPR+GAR

FiD

53.3%

65.2%

6GB

2位

BPR

ELECTRA

50.2%

62.0%

6GB

3位

DPR

FiD

47.3%

59.0%

AWS KendraやAzure Cognitive Search、Google Cloud Searchなどクラウドサービス上の素晴らしいSaaSベース検索サービスが豊富にあり、私自身こちらを利用するのも全然アリと考えたぐらいです。しかしMeta Research（Meta AI研究所、旧名：Facebook AI Research）はテキスト技術や検索技術に関して世界的にも最先端技術技術の集大成があることが大きく、またコスト的にはMeta ResearchによるOSSを自前構築したほうがずっと安かったため、自前構築することにしてみました。


ざっくりした全体構成図は次の通りになります。サーバレスをメインとするため、月3万円ぐらいです。

＜参考＞
・Amazon Kendra
・Azure Cognitive Search
・Google Cloud Search
・Meta Research

検索基盤として、セマンティック検索の場合、検索クエリにワードもしくは質問文を入力したら、NLTKで検索クエリおよびテキスト文書全体を形態素解析しながら、fasttextで単語の識別化・グループ化しつつ数百次元以上のベクトル空間からコサイン類似度で検出します。fastTextはWord2Vecという単語に意味を持たせる技術の延長にあり、サブワードという仕組みを入れることにより、活用形等の近い単語同士を汲み取ります。

例えば、word2vecなら ”dogs” と ”dog” は全く別の意味をもたせますが、fastTextであれば ”dog” の複数形を ”dogs” として認識してくれます。”Kubernetes” を ”k8s” 、”コンテナ” として認識もしてくれるため、単語を高次元ベクトルへ変換する際、別の単語として認識され高次元空間で離れた場所に配置されるリスクを排除してくれます。

質疑応答検索（ODQA）の場合、同様にNLTKで検索クエリおよびテキスト文書全体を形態素解析しながら、RetrieverはDPR（Dense Passage Retrieval）、ReaderはFiD（Fusion-In-Decoder）という、 Open Domain question Answering タスクを解くテキスト生成モデルを使って検出します。

これらは全部Meta ResearchのOSSです。代わりのOSS選択肢があまりみつからないというのは凄いです。

＜参考＞
・fastText

・DPR（Dense Passage Retrieval）

・FiD（Fusion-In-Decoder）

5.NLTKの壁

すべてのテキストを自然言語として検索しやすくするように数値統計化するために、NLTK(Natural Language Toolkit)を使って形態素解析をする必要があります。

先述のfastText、DPR、FiDは基本的にBEATの英語学習済みモデルが格納されています。そのため、日本語に対応するために東北大学の日本語版BERT、中国語はtransformersのtokenizerを入れる必要があります。

例えば、FiD のRetriever処理を担当する train_retriever.pyであれば、コード内に以下の処理があります。

  tokenizer = transformers.BertTokenizerFast.from_pretrained('bert-base-uncased')

上記は英語テキストベースですが、これを日本語対応するなら以下の処理を付け加えます。

   tokenizer = transformers.BertJapaneseTokenizer.from_pretrained('cl-tohoku\/bert-base-japanese-whole-word-masking')

中国語であれば、以下の処理を付け加えます。

  tokenizer = transformers.BertTokenizerFast.from_pretrained('bert-base-chinese')

https://github.com/facebookresearch/FiD/blob/main/train_retriever.py#L166

事前学習済みモデルも英語ベースなので、中国語および日本語のBEAT処理を付け加えます。

   if initialize_wBERT:

            self.model = transformers.BertModel.from_pretrained('bert-base-uncased')

        else:

この処理は以下に書き換えています。

   if initialize_wBERT and isEN and isZH:

            # 英語

            self.model = transformers.BertModel.from_pretrained('bert-base-uncased')

        elif initialize_wBERT and isJP:

            # 日本語

            self.model = transformers.BertModel.from_pretrained('bert-base-japanese-whole-word-masking')           

        else:

            # 中国語

            self.model = transformers.BertModel.from_pretrained("bert-base-chinese")

Retrieverのワード数が 英語BEATの30522になるため、`RetrieverConfig`のvocab_sizeも併せて変更する必要があります。
https://github.com/facebookresearch/FiD/blob/main/src/model.py#L287

このようにfastText、DPR、FiDの日本語対応、中国語対応を進めます

＜参考＞
・bert-base-japanese-whole-word-masking

・Whole Word Mask Language Model

・FacebookのfastTextでFastに単語の分散表現を獲得する

6.実際の検索デモ

このアドベントカレンダー向け記事を書いている時点で、検索エンジンはプロダクトサービスとして成熟していない状態ですが、一部デモをご紹介します。

言語やヘルプページなどの壁を意識せず、非常に高速かつ範囲の広い検索結果が提供できていることがみえます。同時に、ODQA検索アプローチとして質問文に対する回答、および関連文書検索（セマンティック検索）アプローチとして質問文に対する回答のヒントになる関連文書やURLも拾えています。

7.苦労点

私自身AIエンジニアリングでないため、勉強不足なところもあり、社内で構築できるリソースがかなり限られているという点や、私自身中国語があまりネイティブではないため中国語による検証結果の確認に苦労している点が大きいです。

ただ、先述通り、パブリッククラウドサービスのヘルプページおよびテクニカルサポートのナレッジ集等テキストをコンピューターが認識しながら幅広い角度で様々な検索ができるようになれば、テクニカルサポート業務の工数削減はもちろん、将来的には様々な工数削減に結び付けた施策などの展望には結び付くと考えています。

例えば、クエリにて「AWSのコンテナを使った、予算3万円のWeb三層構成」と入れたら、それに応じた構成図や、提案資料を自動作成出来るようにしたいと考えています。いつも担当しているプロダクトサービス紹介資料作成業務もワンクリックで自動作成できるようにしたいです。実はパブリッククラウド プロダクトサービスのアップデート情報も、似たアプローチで自動作成しています。

将来像に関してこれらはまだ先の話であり、今は確実に動く検索エンジン基盤サービスをリリースすることにフォーカスしています。パブリッククラウドサービスのヘルプおよびテクニカルサポートのナレッジをデータソースとして検索基盤を整えていますが、いずれはパブリッククラウドサービスのHands-on training、ベストプラクティス、ホワイトペーパー等PDFやpptなどもOCRで読み取りつつデータソースへ格納しながら、もっと幅広い領域での検索を提供することも視野にしています。

孫子の兵法に「情報を制する者が戦いに勝つ」という言葉がありますが、クラウドエンジニアリングのテクニカルサポート業務として情報戦はまさにその通りであり非常に重要だと痛感しております。

＜参考＞
効率よくパブリッククラウドのアップデートを入手する方法 【2022年版】

8.さいごに

クラウドサービスは常に新しい技術が生まれ続けることや、仕様の変化が非常に激しいです。そのため、テクニカルサポートエンジニアはどんなに知識や経験を増やしても100%にはならないです。クラウドサービス歴10年以上のクラウドエンジニアもいますが、日々研鑽の連続です。

それでもチケットを通じてお客様の疑問を解消しながら、お客様が安心してクラウドサービスをご利用いただけるよう、検索技術を通じて情報リソースの有効活用で100％に限りなく近い状態を提供・維持し続けられるようにクラウドエンジニアリングは常に新技術へ挑戦し続けます。

こういう裏方で泥臭い努力をし続け、チケットを通じてお客様を満足させるように創意工夫している部分が、ソフトバンクによるクラウドサービスのリセラーにおける一つの魅力ともいえます。

では、ソフトバンク Advent Calendar 2022 の 22日目にバトンを渡します。

関連サービス

クラウドプラットフォーム

ソフトバンクはあらゆるクラウドサービスに対応し、お客さまに最適なクラウドサーバの選定・設計・構築・運用までをトータルサポートします。

サービスをみる

MSPサービス

MSP（Managed Service Provider）サービスは、お客さまのパブリッククラウドの導入から運用までをトータルでご提供するマネージドサービスです。

サービスをみる

 ＼ 業務課題をデジタルで支援 ／

デジタルツールの選定から導入の手引きまで、中小規模のお客さまへわかりやすくお伝えします。

中小規模のお客さま向けサイトをみる

メールマガジン登録（無料）
ビジネスに役立つ記事やウェビナー情報をお届けします。

おすすめの記事

条件に該当するページがございません

法人のお客さま向け イベント

イベント・セミナー

ビジネスに役立つ 資料ダウンロード

資料ダウンロード

「今」と「未来」を発信 ソフトバンクのビジネスブログ

ビジネスブログ

クラウドテクノロジーブログ

クラウドテクノロジーブログ