第４部
DXを支える手法と技術

第1章

開発手法・技術第2章

データ利活用技術

第１章

開発手法・技術
はじめにDXを推進するためにはビジネス環境の変化に迅速に対応できるITシステムが必要となる。また、データを分析し、顧客の真のニーズを捉えて早期にサービスを立上げ、改善を繰り返すことで顧客価値を高めていくことも重要である。
第1章では、変化に応じた迅速かつ安全なITシステムの更新や外部サービスとの連携を実現するための企画開発手法・技術を紹介する。第2章では、データ利活用技術として、データ活用基盤技術、新たなデータ獲得手段であるIoT技術、高度なデータ分析や自動化を推進するために必要となるAI技術を紹介する。さらに日米の企業における企画開発手法・技術およびデータ利活用技術に関するアンケート
調査結果を掲載し、関連技術の活用状況や課題について論じている。

１ 企画開発手法（1）背景① 環境変化が激しい VUCA の時代
現在はVUCA（「Volatility：変動性」「Uncertainty：不確実性」「Complexity：複雑性」「Ambiguity：曖
昧性」の頭文字からなる）の時代であると言われており、ビジネスや市場、組織、個人などあらゆるものを取り巻く環境が激しく変化している。
たとえば、
ソーシャルゲーム業界では2013年頃に市場が急拡大したものの、現在では売上高は半減している。また、小売やビデオ業界ではAmazonやNetflixなどがITを活用した新たなビジネスモデルを構築し、既存のビジネスを破壊するデジタル・ディスラプションを起こしており、
これらはまさにVUCAを表す象徴的な例である。
② VUCA 時代に IT システムに求められるもの
VUCA時代においては、消費者ニーズの移り変わりも早く、より激しいものとなっており、企業側もその変化に柔軟に、素早く対応する必要がある。しかし、これまでのような3年や5年などの長期計画や戦略を立てて実行していくやり方では、その変化に追いつくことは難しい。仮に追いついたとしても、すぐにトレンドが変わってしまう可能性が高いのである。
このような状況に対応するには、
顧客志向の徹底とデジタル技術の活用がカギとなる。
たとえば、IoTやビッグデータなどで得た消費者情報をもとに、AIなどのデジタル技術を活用し、消費者行動や何が流行っているかなどの趣味・嗜好を分析する。
そして分析結果から、顧客が望むと思われる製品やサービスを、最新の開発手法や技術を活用して、迅速に提供していくのである。
たとえば「今期や今月は何が利用されたか」
ではなく、
「今週、
もしくは今日何が利用されたか」を把握し、そのデータを次製品やサービス開発へつなげる。
そのようなスピード感でのデータ収集・分析には、

190 DX白書2021

対応が既存の自社の能力だけでは難しいというケースも頻発し、その場合には、技術や能力を有する企業との提携が必要となる。
その際、デジタル技術を活用することによってスピード感を持って各企業が｜第 ４ 部｜第 １ 章｜

これまでの人の介在が多い運用では対応が難しく、デジタル技術の活用が必須となる。また、こうした有している機能を連携させることが望ましい。
このように、
サービスや商品の開発、調整、生産などの多る。
だからこそ、企業側の「変化に対応し続けることへのマインドチェンジ」
も重要となる。
これまでのビジネスモデルや企業文化などを変化させていかなければ、このような激しい変化の時代に適応できず生き残ることが難しい時代なのである。

（2）DX実現に必要な開発手法概要
前項では消費者のニーズをいかに早く捉え、サービス連携などにより実現していくことが重要かを
述べた。
本項では、
このような不断に調整が求められる環境の中で、迅速に消費者や顧客企業へのサービスを提供できるようになるための、
一般的なIT開発プロセスおよび、開発手法を紹介する。
図表41-1

サービス開発を素早く実現するためのビジネス視点におけるプロセスとシステム
開発手法

消費者が欲しいサービスを提供するためには、消費者の視点に立った企画が求められる。近年では、
消費者の抱える問題と、その解決方法を素早く探索・実現するため、「デザイン思考（課題の発見から
企画・デザインまでデザイナー的な思考プロセスを取り入れてプロダクトやサービスの検討に適用すること）」が多くの企業に取り入れられている。また、事前の要件確定が必要なこれまでの開発手法（ウォーターフォール型開発を指す）では、開発以外の多くの事柄の決定に時間がかかりすぎてしまい
完成したころには消費者のニーズが変わってしまっているという可能性がある。外部環境の変化に柔軟に対応するには、
スピードやアジリティを実現するために、「アジャイル開発」
におけるプロダクト責

DX白書2021 191

開発手法・技術

様な局面において、
デジタル技術を用いて競争上の優位性を確保することが、DXの目指すところであ任者と開発者の連携や、「DevOps」における開発者と運用担当の連携のように、関係性を構築して業務を進めることが有効な手段となる。
ここでは、上記の3手法、およびプログラム言語でプログラムを書かなくても、webやスマートフォンなどで利用可能なアプリやサービス開発ができる「ノーコード/ローコードツール」について技術・手法の面での概要を説明する。
①消費者の本当に欲しいサービスを探るための、「デザイン思考」②変化する要求に対応するための、「アジャイル開発」③アジャイル開発を支え、運用・改善し続けるための「DevOps」④システム開発を効率的に実施するための、「ノーコード/ローコードツール」① デザイン思考
デザイン思考やデザインシンキングといった言葉がビジネスの世界で注目されている。デザインに
は製品や意匠・ブランドのデザインという意味での有用性があるだけでなく、近年は「デザイナー」的な視点・思考プロセスの企業活動への活用という動きも「デザイン思考」
や「アート思考経営」という形で始まっている。
ここではとくに活用が本格化しているデザイン思考について取り上げる。
デザイン思考とは、課題の発見から企画・デザインまでデザイナー的な思考プロセスを取り入れて
プロダクトやサービスの検討に適用する、
人間中心のイノベーションへのアプローチである。
ユーザー
は自身が抱える真の問題に気付けていないことも多い。
そこでデザイン思考は、ユーザーの行動観察やインタビューにより、行動の理由や背景、
社会や環境に対する考え方、
その時の感情も含めて理解、
すな
わち
「共感」
する。
そのうえで、ユーザーが抱える真の問題を類推し、絞り込み、解決のアイデアを導出する。それを基にユーザーが体験できる試作品を作成、提供し、フィードバックをまた真の問題を探索するインプットとして活用することを繰り返す。
物理現象がどう連鎖するかのみを考えればよい機械の設計と異なり、デザインの世界では作られたものを人間が見てどう反応するかを考えざるをえない。こうしたデザイン世界に特徴的な考え方や思考のプロセスを、人間による評価結果が重要となる製品やサービスの改善に転用し広く活用できるよ
うにした手法といえる。
本項目では、デザイン思考を活用するうえで理解しておくべきポイントとして、
デザイン思考を実践する際のプロセスとそれに臨むにあたっての態度について紹介する。
（ア）デザイン思考のプロセス
本書ではSAP（ドイツ）の共同創業者であるハッソ・プラットナー氏が創設した、スタンフォード大学（Stanford University、米国）のd.schoolでは5ステージのプロセスを用いて、デザイン思考を用いたア（Empathise）、問題定義（Define）、創
イデア創出の具体的なプロセスを説明する＊1。本プロセスは、共感造（Ideate）、プロトタイプ（Prototype）、テスト（Test）として定義されている。重要な点は、これらのステージは基準となる進め方の順番はあるものの、後ろのステージで新しい気付きやフィードバックを得た場合に、
前のステージに戻ることが推奨されていることである。5ステージのプロセスイメージを
図表41-2に示す。
＊1“ 5 Stage in the Design Thinking Process,” Interaction Design Foundation Website <https://www.interactiondesign.org/literature/article/5-stages-in-the-design-thinking-process>192 DX白書2021

｜第 ４ 部｜第 １ 章｜

デザイン思考の5ステージのプロセスイメージ

図表41-2

共感から開始④プロトタイプ（Prototype）

柔軟に
ステップを
行き来する

②問題定義
（Define）③創造（Ideate）

ここからは、5ステージのプロセスについてそれぞれ具体的な内容を簡単に説明する。
① 共感（Empathise）
最初のステージであり、デザイン思考を進めるうえでもっとも重要なステージである。
このステージではユーザーを理解するために、行動を見る、インタビューを行い会話から知る、またそれらの組合せを行うことになる。
これらの方法はこれまでも行われてきたが、デザイン思考の共感ステージで重要な点は、行動やインタビューなどにおいて、具体的な事物やユーザー自身の意識に上っている事柄だけでなく、行動やインタビューの理由や背景、社会や環境に対する考え方について、そのときのユーザーの感情も含めて理解することである。
本ステージはSympathizeではなくEmpathiseであることに注意が必要である。日本語ではどちらも「共感」と訳されることが多いが、前者は相手の現在の感情に対して自分が同じ気持ちになるという意
味であり「シンパシー」
とも表現される。
一方、後者は相手の過去から現在までの背景や置かれている状況なども踏まえ、相手と同じ境遇や立場などに自分を重ねあわせたうえで相手の感情や行動を自分事として理解する「感情移入」であり、より相手の来歴やパーソナリティに即して全体的に対象を理解することである。
② 問題定義（Define）
ユーザーが持つ真の問題の特定を行うステージであり、意味のある具体的な文章で問題を表現することがゴールである。
ただし、問題の探索にフォーカスし、解決方法をこの時点では考えない。
解決方法を考えてしまうと、解決可能な結果を出そうというバイアスが働いてしまい、
真の問題にたどり着くことを阻害する場合があるからである。共感のステージを通じて収集したユーザーに関するさまざまな情報を踏まえて、
特徴的な気付きをチームで共有したうえで問題の統合と選択を行う。
このステージを通じてさらなる気付きを得て問題を深掘りしていき、最終的には特定した問題を具体的な問題定義文

DX白書2021 193

開発手法・技術⑤テスト（Test）①共感（Empathise）

にまとめて次のステージへつなげることになる。
問題定義文のフレームとして頻繁に用いられるものに「How Might We 〇〇?」
（HMW）がある。
「私たちはどうすれば○○することができるか？」という形で問題を表現する方法であり、ユーザーへの共感を踏まえて主語が「私たち」とされている部分が特徴である。
③ 創造（Ideate）
前のステージで定義した問題を解決するアイデアを出すステップであり、最終的には次のステージであるプロトタイプで作成対象とするアイデアを決めることが目的となる。このステージには十分な時間を取り、玉石混交で問題ないのでとにかく多数のアイデアを出すことが重要となる。また、最善のアイデアを特定することが目的ではないので、チームの中で数個のアイデアに絞っていく。
このステー
ジでは、ブレインストーミングやマインドマップといったツールを活用しながらアイデア出しに注力
し、
アイデア評価は後段のステージで実施していくことになる。
④ プロトタイプ（Prototype）
創造のステージで数個に絞ったサービスのアイデアについて、チームメンバーやユーザーと具体的な会話を行うために、目に見える、体験できるプロトタイプと呼ばれる物を作り、テストに向けた準備を行うステージとなる。プロトタイプというと実際に使えるアプリケーション等をイメージするかもしれないが、ポストイットによるペーパープロトタイプ、画面表示だけのモック、ロールプレイの設定や台本といったサービスを疑似体験しフィードバックを得られるものであれば形にこだわる必要はな
い。
重要なのはテストをしたい事柄、テストでユーザーに反応して欲しいことを作り始める前に考えておくことである。
⑤ テスト（Test）
作成したプロトタイプを活用してユーザーからフィードバックを得て、さらにユーザー理解を深めていくステージである。単純に機能の利用可否を確認するのではなく、ユーザーがどのように動くか、どのように感じるかのフィードバックを得て、新しい気付きを得る事が目的となる。
ユーザーには機能を説明するだけではなく、プロトタイプを経験してもらうことで有益なフィードバックを得ることができる。
上記の5ステージを繰り返すことによりユーザーの持つ真の問題とその解決方法に近づくことが可能となる。
（イ）デザイン思考に臨む態度
前段にてプロセスについて紹介したが、単純にプロセスをなぞるだけではデザイン思考を有効に活用したとは言えない。実践にあたっては、デザイン思考に臨む態度、心構えが重要になる。デザイン
思考については方法論だけでなく、態度についてもさまざまな説明がなされており、ここではKamil
Michlewskiが提唱した五つの要素を紹介する＊2。

＊2

Kamil Michlewski, Design Attitude, 2015

194 DX白書2021

｜第 ４ 部｜第 １ 章｜

1. 不確実性および曖昧性を受け入れる
2. 深い共感に従う
3. 五感の力を用いる
4. 遊び心を持つことで物事に命を持たせる
これらの要素はデザイナーの行動だけではなく、デザイナーの考えや感情にも着目することで抽出したものであり、デザイン思考の実践においても心掛けるべきものである。これらの態度がなければ、結局は自身の価値観を基準として、目に見えるものだけ、ユーザーが言語化できた事柄だけしか捉えられず、安易な単純化に走ってしまい、
ユーザーがまだ言語化できていない真の問題やその解決アイデアを発見することが困難となる。
② アジャイル開発
ソフトウェアの開発は、プロジェクト全体のゴールを設定し、工程を複数に分解し、時間的計画と資源配分計画を策定したうえで、各工程を順番に実行していくウォーターフォール型開発で行われてきた。それに対してアジャイル開発は、一般消費者を対象としたWebサービスのように、ユーザーの要望が頻繁に変化するなど、サービス提供のタイミングやきめ細かい改善がより重視される分野あるいは
事前に予測困難な要素を多く含む技術・事業領域においてとくに効果を発揮するものであり、体制の作り方や運用の仕方に関するプラクティスを含む手法である。
そして近年の経営環境や市場は、
アジャ
イルな開発スタイルを必要とする課題・ニーズがますます増えているのが現実である。
したがって、
アジャイル開発は、
現代の経営スタイルに求められるものに通じるところがあるといえよう。VUCAの時代においては、設定したゴールは日々変動するし、予期しなかったトラブルは日々起
こる。
そのため経営陣は、
大きなゴール感を経営チームで共有しながら、単位プロセスを短期化し、小さく繰り返すことで不確実性に対処しようとしていくのではないだろうか。
アジャイル開発では、同様の考え方に基づいてITシステムを開発する。
しかしながら、決定された中長期の計画を厳格に実行していくウォーターフォール型開発と、短期の計画を作り、実行し、見直すというサイクルを繰り返していくアジャイル開発とでは、実施するうえでのプロセスが大きく異なる。
そのため、従来型のシステム開発者では対応できない場合がある。
また、
ユー
ザーや市場のニーズが変化する中で、あらかじめすべての機能セットを包括的に仕様定義し見積りを行うというウォーターフォール的な価値観を引きずったままの組織がアジャイルプロジェクトを見ると、ゴールに到達するまでのトータルコストが不透明だと見なしてスタートを切れない傾向がある。
なお、
ウォーターフォール型のシステム開発でも環境変化によるコスト増減はあり、実際には余裕を見た予算計画や機器・サービスの事前購入などで対応せざるをえない。
また、
環境変化により実際には使われない機能やもう使う価値のない機能まで計画通りに開発してしまうという無駄が発生したり、開発が間に合わずにプロジェクト全体が遅延して大きな損失を生んだりするケースも多々見受けられる。
本章では、従来はウォーターフォール型の開発をしてきた企業がアジャイル開発を進めるにあたって、とくに注意したい点を紹介する。なおアジャイル開発にはさまざまな枠組みや手法があるが、ここでは代表的な「スクラム」
を例に取り上げて説明する。

DX白書2021 195

開発手法・技術

5. 複雑性から新たな意味を創造する

（ア）経営層の理解と報告
まず前提として重要なのが、開発するシステムや開発元の企業の規模にかかわらず、「マネジメントを担う組織の長や役員がアジャイル開発を正しく理解したうえで推奨している」
ことだ。
スクラムによるアジャイル開発では開発のアジリティやスピードを上げるため、ソフトウェアの実
装からテストまでを「スプリント」と呼ばれる短期間で実施する（これが前述の「短期の計画」に相当す
る）。そしてスプリントを繰り返すことで、システムを作り上げていく。この繰り返しの中で、多くのスタッフは目の前の業務に集中している。
問題になるのは、ウォーターフォールの考え方が抜けきらない組織長が「いつ完成するのか？」「どん
な機能にいくらかかるのか？」「設計書を確認したい」などと、現場とレベル感の異なる報告を要求してくるケースである。
開発チームのメンバーが回答や準備に余計な時間を割かざるを得なくなり、肝心の開発が遅れかねない。こうした問題が起きる要因に、組織長が実際のシステム開発チームと、知識経験
面や感覚心理面で距離があることが挙げられる。
これにより、組織長は形式的報告を受けないと得心できなかったり、
定期報告により現場に計画順守の圧力をかけたりするのである。
そのため、スクラムでは後述する「プロダクトオーナー」が開発チームと事業組織や経営層との間のインターフェース役となり、開発チームの手を煩わせないための防波堤になることが推奨される。また、開発プロジェクトが始動する前に、役員・プロジェクト責任者・各部門長など「組織のマネジメン
トを担い、かつソフトウェア開発のステークホルダーである人々」
に対してアジャイル開発概要を説明
し、その有効性を理解させたり、協力者を生み出してウォーターフォール的な対応をする人々との間に入って障害が緩和されるような体制を構築したり、責任と権限をなるべく開発チームに移譲するなどして、アジャイル開発のチームが円滑に活動できるような環境づくりを行っておくことを推奨する。
（イ）アジャイル領域の見極め
従来、
システム開発は主にウォーターフォールで行われてきた。
近年はアジャイル開発が台頭してきたが、それぞれの開発手法には特性があり、その適用において向き不向きがある。
一 般 に ア ジ ャ イ ル 開 発 は、
「ビ ジ ネ スIT（収益の源泉となる中核ビジネスや対顧客価値を提供する
IT）」のような俊敏性・柔軟性を重要視するシステムに向いた開発手法と言われる。
しかし、「コーポレートIT（社内で利用する業務サービスなど）」に全く向いていないとも言い切れない。
頻度の高い
（少なく
とも1 ～ 3か月ごとの）リリースが必要であったり、開発途中で要件変更が発生したりするシステムなら、「ビジネスIT」「コーポレートIT」に関係なく、
アジャイル開発を導入する価値はある。
また、システムの全体ではなく、システムの一部を後述するように細かいシステムに分割できるのであれば、アジャイ
ル開発に適した一部分だけに導入するのも有効である。
逆に「要件が明確」「改修などの頻度が少ない」とあらかじめわかっているシステムの場合は、ウォー
ターフォールで開発した方がコスト的にも初期品質的にもよい結果が得られる可能性がある。
ただし、要件が明確にFixできた・改修は起こらないというのも思い込みであることが多いので注意が必要である。
また、開発規模にも注意が必要である。一般にスクラムの手法でアジャイル開発を実施する際、適切な開発チーム（スクラムチーム）の人数は3名～ 9名と言われている。
ところが大規模な企業情報システ
ムの開発現場では、
もっと多人数の開発メンバーを必要とすることが多い。
この場合、取りうる手段は2

196 DX白書2021

を導入する。
その際、各アジャイルチームをとりまとめてマネージする大規模アジャイル手法（SAFeや＊3、
または「分割が難しいならアジャイル開発は採Lessなどの手法がある）
を採用することも検討する」｜第 ４ 部｜第 １ 章｜

通りある。
「大規模システムを3名～ 9名で対応可能な細かいシステムに分割したうえでアジャイル開発

用せず、
システム全体をウォーターフォールで一括開発する」
かのどちらかである。
システム単位または機能単位に分割し、「改修などの変化が多いと想定されるもの」と「そうでないもの」に分類する。前者はアジャイル開発とDevOps、後者はウォーターフォールと、特性に合わせて開発
手法を選択するのが理想的である。
なお、
大規模システムへのアジャイル開発は、
まず小規模なアジャイル開発チームでの成功体験を得てから進めるべきである。
社内的に思想もノウハウも十分に育っていない状況では、開発を進めても混乱するだけでありスピードとアジリティは実現できない。アジャイル経験とチームの成熟度合に合わせて、適切な形で大規模アジャイルの導入を進める必要がある。
（ウ）プロジェクト体制
アジャイル開発におけるスクラムチームの人数は、前述のとおり3名～ 9名程度と考えられるが、ア
ジャイル開発に関する先進企業の経験や研究によれば、その中の役割分担の構成上も、定式化されたパ
ターンが認められる。
まず、組織の中核を占めるのが、プロダクトオーナー（PO）とスクラムマスター（SM）である。
プロダクトオーナーは、チームにビジョンを示すもっとも重要な役割である。
ユーザーとの要求事項の合意や、必要機能の優先順位付け、成果物の受入れ確認など業務は多岐にわたり、体力的・精神的に大変負荷がかかる。そのため、意思決定を行うプロダクトオーナーは一人に定めるものの、その負荷を分散するためビジネスサイド（事業部門）
や現場から「PO補佐（ビジネス）」、
システム開発サイドから橋
渡し役の
「PO補佐
（システム）」
を選出しプロダクトオーナーをサポートするなど、POチームを組成して業務を分担することもある。
ただし、この場合は、
他の役割のチームメンバーがどのPO補佐と話せばよいか混乱しないよう、担当範囲をしっかり定めて周知しておく必要がある。
SMは、
サーバントリーダーシップを発揮してアジャイル開発のプロセス（スプリント）が気持ちよく自然に「回る」
ようにチームメンバーを後押しする役割を担う。
チーム内の障害を取り除き、プロダクト
オーナーやメンバーが力を出し続けられるような環境を守るのがスクラムマスターの役割である。そのため、チームメンバーに対して処理しきれないような膨大なタスクをプロダクトオーナーが要求した場合には、タスク量を減らすように進言をする必要がある。一方、チームメンバーに対しては守るべきルールを課すケースがある。
スクラムマスターは組織の上下両方向と信念をもって戦い、協調もできるスキルが求められる。そして、チームを同じ方向に導き、モチベーションを高めることもスクラムマ
スターの重要な役割なのである。
このようなチーム全体のサーバント的な管理者ともいうべきスクラムマスター役にくわえて、場合
によっては、
後述の品質保証担当やセキュリティチャンピオン、
技術リーダー、UIデザイナーといった、＊3

スクラムのチームのリーダーを集めた上位のチームを構成し、その上位の懸案管理（バックログ）や振り返り（レトロスペクティブ）の結果を各チームに割り振って持ち帰って反映させるという階層構造を形成することによって大規模化を実現する Scrum of Scrums という考え方が提案されている。その派生である Large Scale
Scrum や Scaled Agile Framework とともに、大規模システムで適用され始めている。
DX白書2021 197

開発手法・技術

前者の場合、システムの一部だけにアジャイル開発を導入する手もある。まず、システム全体をサブ仕事のある側面における担当管理者（というよりもチーム支援者と言った方が適切である）を設けることもある。いずれにしても、こうした付加メンバーの技術的・環境的サポートのもとでチーム全体が、要件定義・設計・UI・実装・テスト・DB・インフラ・品質といったソフトウェア開発の全側面に関して、そのスプリント内で必要最小限に絞り込んだ機能を最大効率のメンバー間コミュニケーションの下でスピード感をもって実行することを目指さなければならない。
スクラムチームは、自社の重要な差別化要因となるプロダクトやサービスに関わるため、自社のメン
バー（内製メンバー）で構築するのがよいとされているが、しかし、日本企業においては技術やスキル、人材面で難しいケースが多い。
そのため、
図表41-3では日本でよく見られるシステムインテグレーショ
ンの現場をイメージした構造図を示したが、ここでは「開発をITベンダーが準委任契約で受託する」
ケースを想定している。
図表41-3

開発受注時のアジャイル/DevOpsチームの体制
受注者体制

発注者体制
決裁権限者

決裁権限者とPOが、密なコミュニケーショ
ンをとれることが重要

役員

部門長

(情シス、事業部)

プロダクトオーナー(PO)

業務設計

PJ責任者

必要に応じてPOのサポートを配置

スクラム
マスター(SM)

PO補佐

開発者

デザイナー

開発者

テスター

メンバー
事業部門の
業務有識者による導入後の業務設計

発注者側にノウハウ蓄積のためにメンバー参加スペシャリストがスクラムチームをサポート
各種横断チーム(品質保証担当、セキュリティチャンピオン、技術リーダー)

品質保証担当とは、チームの中で、品質（ここでは、システムが期待通り動くこと、アジャイル開発をし続けていくために適切な構造になっていること、社内外の他のシステムと上手く協調することなどを指す）
に関する検討をリードする役割である。
アジャイル開発ではテスト駆動開発や継続的インテグ
レーション/継続的デリバリー（Continuous Integration; CI/Continuous Delivery; CD）に基づくテストの自動化といった手法も含めて、テスト戦略も重要となる。具体的にはコーディングルールの整備やチェックの自動化、
レビュー頻度の決定、ブランチ戦略（機能の違う複数の開発を同時に進める場合に、相互に影響が少なくなるよう分離・統合する際の取り決めや考え方）の立案、レビュー観点・運用方法の整備、評価指標の決定、社内のリリース判定との整合性など、多岐にわたるが、これらの戦略をリードする存在が品質保証担当である。
セキュリティチャンピオンとはチームの中で、セキュリティに関する検討をリードする役割である。
最新のセキュリティ情報を収集し、企画・設計段階からセキュリティの観点における作りこみやレ

198 DX白書2021

ない状況が増えているため、セキュリティテストの自動化を、
後述する、
継続的インテグレーション/継続的デリバリーのプロセスに組み込む。
これにより、
セキュリティリスクの自動的な検出と低減を目指｜第 ４ 部｜第 １ 章｜

ビューを牽引する。
ビジネスITの世界では、
これまでの事前・事後のセキュリティ対策では対処しきれす。
ステム開発について、信頼できる限りにおいて有用なツールやサービスを利用して、なるべく効率的に高品質のシステムを作り、リリースしていくことが肝要である。
中でも、クラウド環境に関しては、
近年、Amazon（米国）のAWS（Amazon_Web_Services）やGoogle（米国）のGCP（Google_Cloud_Platform）などのクラウドベンダーからアジャイル開発・DevOpsに役立つサービスが次々とリリースされている。
技術リーダーは自社の開発に関する技術動向を把握し、利用可能なツールやサービスを的確に見極
め、チームメンバーを巻き込みながらツールの使い方を紹介し、導入や自動化を推進していく。初めて
アジャイル開発・DevOpsに携わるメンバーが多い場合、チーム内に技術リーダーとそれをサポートするメンバーが複数人いるとチーム内での新技術への適用が格段にスムーズになる。
③ DevOps（ア）アジャイル開発とDevOps
従来の情報システム部門がDXの求めるスピードや柔軟性（アジリティ）に対応できない原因には、
開発プロセスにおける「ビジネス変化と開発スピードのギャップ」「スピードを上げたい開発部門と安全性・安定性を重視する運用部門とのギャップ」という二つのギャップがあった。
前者の解決手段として提案されてきたのがアジャイル開発であり、後者の解消手段として注目されているのがDevOpsである。
アジャイル開発では、開発のスコープを小さい複数のイテレーション（通常1～2週間の単位。アジャ
イルの典型的な手法スクラムではスプリントと呼ばれる）に分解し、この短いイテレーションの中で「要件定義・設計・開発・テスト・リリース」までを行い、それを反復することによってアジリティを向上させる。一方、DevOpsは、従来、分業・分断されていた開発（Dev）と運用（Ops）の担当者がそのシステムやサービスのビジネスゴールを共有し、テスト・構成管理・デプロイ等をできる限り自動化す
ることで、
スピードと品質を担保したうえで、
柔軟かつ迅速な開発を目指す。
アジャイル開発とDevOpsをあわせて導入すると、リリースサイクルの短縮や品質の向上の観点で大きな恩恵を受けられる。
本章では、DevOpsを実現するためのポイントを解説する。
（イ）コードデプロイプロセス
システム開発においては、
まず、
ソフトウェアの改訂がなされ、それが要求通りに動作するか、所要のインフラ環境や協働する外部システムとの連携環境の下で期待通りに動作するかを確認後、これを本番環境にデプロイ（開発したソフトウェアを利用可能な状態にすること）
するというようにステージを刻んで進む。
このうち、開発環境や一部の本番環境で、
コードコミット（開発・修正したソースコードをバージョン管理システムに反映させること）のステージでの自動化やテスト自動化を実現している企業は多い。
だが企業の商用システムにおいて、
コードコミットから本番環境へのデプロイまでのプロセ
ス全体を自動化できているケースはまだ少ない。

DX白書2021 199

開発手法・技術

最後の技術リーダーは、チームの中で、最新の技術調査やツールの導入をリードする役割である。シアジャイル開発/DevOpsにおいて自動化は、スピードとアジリティを実現する重要な要素だ。しかし、ソフトウェア開発の各工程の担当者が個別に自動化を進め始めると、結果的に「自動化範囲の重複や欠落」「セキュリティ試験など必要なテストが不十分」「リリースの受入れ基準が不明確」といった問題が起こりかねない。
こうした事態を避けるためには、ソフトウェア開発の全体プロセス設計と自動化を一貫して整備する必要があり、
アジャイル開発・DevOpsで一般的に使われている「コードデプロイプロセス」
を描いた
うえで、
それに沿って進めることが重要となる（図表41-4）。
図表41-4

基本的なコードデプロイプロセスの例

出典：NRIにおける実装例を簡略化して記載

一般的に、
ソフトウェアをコーディングし始めてからユーザーに提供するまでには一連の段階（プロ
セスステージ）に分けてソフトウェアの検証を行っていくことになるが、その構造を、図を例にとりつつ、家を建てることと対比しながら各ステージを説明すると、次のとおりである。
・コードコミットステージ：単体テストとコード解析を自動化し、技術レベルでの検証を行う。
いわば、建物を設計し、くみ上げた段階でのチェックであり、構造設計にミスがあり目の前で壊れないかとか、
おかしなゆがみがないかなどを確認するステージである。
・機能試験ステージ：機能および非機能レベルの検証を行う。
家が建ったのはよいとして、そもそも当初設計した通りに各部屋が配置してあるか、歪みでドアが開かないなどの不具合はないかなどを確認するステージである。
・ユーザー受入れ試験ステージ：実業務の確認に加え、魅力品質（使いやすさ）などのユーザー価値の検証を行う。
実際に試験的に居住するなどすることで、その価値を検証することである。
・性能試験ステージ：性能面での検証を行う。
家単体では十分な建築物になっているとしても、
たとえば200 DX白書2021

えなくてはならない。
そうした実際の環境における十分な性能を確認するのがこのステージである。
・本番リリースステージ：ユーザー環境へのリリースを実施し、最終確認を行う。

｜第 ４ 部｜第 １ 章｜

設置場所の自然環境や地盤強度、
電気やガスの供給事業者との関係できちんと接合できるかなども考

上記はあくまで一般的なプロセスステージの例であり、会社における品質基準やレビュープロセス
ようやく利用できるようになるということは変わりない。
こうした煩雑な検証の省力化、確実化のために、たとえばコードコミットステージにおいてソフト
ウェアの構文解析・バグ検出ツールを導入するように、各段階における自動化の試みは行われていた。
コードデプロイプロセスでは、
こうした各ステージ単位での部分的なテスト作業にとどめず、可能な限り全体プロセスまで自動化するという工夫である。
いわば、出来上がった家に関するさまざまな検証を一気通貫に行ってしまう自動検証サービスを作ろうということである。
これにより、作業者毎のばらつ
きなく、高速に必要な検証を確実に行うことが可能になり、より高速かつ高品質な開発が可能になる。
（ウ）コードデプロイプロセスを支える二つの要素
コードデプロイプロセスのこの自動化の実現には、①構成管理（Configuration Management：CM）、
そして②CI/CDという二つの要素が重要となる。
これとコードデプロイプロセスの関係を図表41-5に示す。
図表41-5

基本的なコードデプロイプロセスを支える三つの要素

出典：NRIにおける実装例（a）構成管理
構成管理とは、各種の設定情報やプロジェクトの内外を含めた環境などを管理することである。なお、ここでいう「環境」は、OSやアプリケーションの設定だけではない。パッチの適用状態や、ネット
ワークトポロジーなどインフラに関する情報、
外部サービスのバージョンおよび設計書なども含む。
管DX白書2021 201

開発手法・技術に合わせてカスタマイズが可能であるが、いずれにせよ、
こうした多段階の検証を経てソフトウェアが理するアプリケーション数やそれを組み合わせた環境数が多いほど、構成管理がリリース時の品質を左右する。
一般的にソフトウェアは決まった環境で実行されることを想定している。
したがって、
ソフトウェアの検証において、その前提とされているような環境を設定することは必要な作業である。
しかし、コンピューターは数多くのソフトウェアが連携作動して一つの環境を形作るため、ある適切な環境を設定するということは、
極めて煩雑な作業なのである。
そのため、各ステージで求められる適切な環境を準備できるようにしておくことで、
いつでも誰でも必要な環境を使ったデプロイが可能となる。もちろん、本番と同じ環境を準備することも可能で、これにより、「開発環境や検証環境ではうまくいったものの、本番環境のリリース時に失敗する」
といった状態も回避しやすくなる。
利用環境の数が多くなりがちなエンタープライズシステムでは、とくに重要な要素である。
（b）CI/CD
継続的インテグレーション（CI）とは、コードコミットステージにおけるプログラムの開発と単体テストまでの検証を自動化することである。これに対して、継続的デリバリー（CD）は、CIの自動化範囲
をコードコミットのステージからさらに拡大したもので、コード変更が行われた段階で、変更された
コードが実行可能なソフトウェアに自動的に組み込まれ、テストや運用環境へのリリースに向けた準備も自動的に済んでしまう状態を目指す。
従って、CI/CDとは、
システム開発におけるコードコミット
から各種検証、調整を経て本番環境へのデプロイまでの各工程を一つの大きなプロセスとしてつない
でいくことを意味する。
これにより、
デプロイまでの業務負荷を大幅に下げられる。
従来、コードコミットステージではプログラムコードの作成や修正から単体テストまでを人手でこなしており、それ以後の各ステージでも「インフラを構築し、その上でアプリケーションを構築。
その後
UT、IT、STやユーザーテストを経て…」と、同様であった。CI/CDとは、
これら作業の大部分をクリッ
ク一つで実現できる姿を目指すことである。ただし、単に自動化による高速化を図るだけではなく、従来は人力ゆえに、
作業者毎の解釈やミスに基づく検証作業のばらつきが生じやすく、
ソフトウェアの品
質も低下しがちであったところ、
自動化
（画一化）
によってその品質を向上させるという意図がある。
技
術的には、CMを十分活用して行うべきものである。
もちろん、CI/CDではテスト自動化を可能な限り推し進めるべきではあるが、実際には一定以上の自動化はそれだけで大変な時間とコストがかかるため、無理なく実現できる範囲から始め、段階的に自動化範囲を増やしていくべきであろう。
この点については三つの重要な視点がある。
一つ目は、セキュリティの取扱いである。
一般的にCI/CDにおいては必ずしもセキュリティ検証は含
まれるものではないが、各種セキュリティ検証もこの自動化範囲内に括り込むことでより効率よい検証が可能になるので、可能な限り目指すべきである。
二つ目は自動化の範囲である。CDにおいては、「ユーザー受入れ試験ステージ」
は人間が実際に使ってみての評価を得るべきステージなので自動化の対象外となる他、「機能試験ステージ」
や「性能試験ステージ」
でも、開発者だけでなくテスターや利用ユーザーを巻き込むことを前提に計画することが望ましい。開発者よりもテスターやユーザーのほうがユーザーシナリオ上の欠陥を見つける可能性がはるかに高く、実態に近い適切なテストシナリオを作成できるためである。

202 DX白書2021

テスト駆動開発手法の実践を段階的に取り入れていくべきである。
これは、ある機能に対応したコードを書く前にその機能コードが完成した場合に成功するはずの単体テストコードを開発者自身がまず書｜第 ４ 部｜第 １ 章｜

三つ目は、開発者にも設計やコーディングの段階からテストを意識させるべきだということであり、いたうえでコードを完成させ、「対応する単体テストコードがすべて成功することを開発者自身が確認テスターや利用ユーザーと密接に協力し合ってテストシナリオを作るというこのプロセスは、開発者たちに自然と必要とされている機能（=ビジネス価値）の改善に集中することを促す。
これにより、
定
まった開発業務の効率性を高めるというだけでなく、ビジネス価値の向上のためにいかなる開発を行うべきかという視点が育ち、企業にとってよりよいシステム開発に近づくことも期待できる。すなわ
ち、事業/開発/保守の各担当者がチームとして一体となってビジネス価値＝共通ゴールをめざすカル
チャー醸成がもっとも大事なことである。
④ ノーコードツール / ローコードツール
近年はアプリケーションの開発ツールとして、プログラミング言語なしで実装可能なノーコード
ツールや、簡単なプログラミングで実装が可能なローコードツールが注目を集めている。以前は、こうしたツールは一部のツール専業ベンダーのみが提供していたが、近年では大手ITベンダーからもツールが提供されるようになり利用が拡大している。
まだ、開発速度を上げるための手段としての認知も高まっており、
スピードとアジリティが必要とされるアジャイル/DevOpsとの相性もよい。
一般的なノー
コードツール/ローコードツールのメリット・デメリットは図表41-6のとおりである。
図表41-6

ノーコードツール/ローコードツールにおけるメリット・デメリット（ア）誰でも開発者となれるのが最大のメリット
これまでは専門的な開発知識を持つエンジニアでない限り作成が難しかった業務アプリケーション
が、業務部門などの非エンジニアでも開発が可能になるというのがノーコードツール/ローコードツー
ルの最大のメリットである。
そのため、業務ロジックや業務フローを熟知した業務部門主導での推進が可能となり、より現場のニーズにマッチしたサービスも期待できる。ツールによっては、さまざまな業
務を実装するためのテンプレートもあらかじめ準備されており、汎用性・拡張性も高い。
既存のシステムの維持保守に手一杯でIT人材が不足する企業においては、
有益なツールである。
ただし、開発に際してビジネスロジックの考え方やセキュリティ面などその企業の開発ルールを押DX白書2021 203

開発手法・技術

したうえでコードコミットする」という文化を徹底するというものである。

さえておく必要はあるため、システム部門のサポートも重要となる。
（イ）ノーコードツール/ローコードツールのデメリット
開発をサポートするツールを利用するという前提のため、プログラミング言語やフレームワーク、ラ
イブラリーなどを使ってゼロから開発することができない。
そのため、他のさまざまな機能と接続する
大規模な業務システム開発には向かない場合がある。
また、ノーコードツールは、一般的な機能実現の範囲であれば汎用性・拡張性ともに高いといえる。
しかし、目的とするシステム実現に必要な機能が提供されていなければ、そのツールの利用価値はない。ローコードツールでは他言語によるコーディングを組み込むことによる実装も一部可能であるため、その点においてはノーコードツールに比べて制約が少ないといえる。
一方で、こうしたツールの利用は、妥当な設計や保守品質の確保、組織を跨いだデータ管理といった観点で問題を抱えているのも事実である。
現状のノーコードツール/ローコードツールは、ツール間の互換性がなく移植は一般的に困難である。また、ライセンス費用が高額になるものも多いため、一度使い始めると他サービスへ移行するときのハードルが高い製品もある。さらに、標準的なツールが確立しているというわけでもない。したがって、ツールの選定に際しては、これらの課題を考慮して意思決定する必要がある。
（ウ）どのようなシステム開発から始めるべきか
前述のメリット・デメリットを考慮した場合、費用をかけてシステム化するほどではないが、実現できれば業務の効率化が見込めるシステム（例：部内における案件・物品管理や、簡易な承認システム）がパイロットプロジェクトとしての選定候補になると考えられる。
これらシステムであれば、必要な業
務ロジックは整理されており、失敗してもリスク（業務面・セキュリティ面）
は少なく、恩恵もすぐに受けられる。
一方で、こうしたツールの利活用を組織的に進める際のルール作りも必要であり、個別事業部門ごとに勝手に蛸壺化したシステムが増えていくことのないように、
情報システム部門やCIO、CDOといった役割と連携して、組織間でのデータの連携やAPIのオープン化と合わせて、真のDXが推進できるような方針の下でそれらの開発を進めていく必要がある。事業部門でスピード感をもって小回りを利かせて開発する部分と全社として組織横断で取組むべきシステム化とを棲み分け、きちんと統制しながら経営にとっての全体最適を目指すべきである。
（エ）社内の体制
ノーコードツール/ローコードツールは、業務部門でもある程度の知識があれば開発可能なツールであることは紹介したが、システム部門が全く関わらなくてよいかといえばそうではない。
業務部門に任せきりとなっていては、保守や管理がきちんとされず、セキュリティホールが生まれる可能性もある。
業務部門に主体的にシステム開発を進めてもらうのはよいが、システム部門は技術リーダーとしてツールの目利きや、セキュリティ面のアドバイザーとしてサポートを実施するとともに、事業部のス
ピード感を殺さないように十分注意しながら、全社最適の観点でエンタープライズアーキテクチャーと整合するように管理の方針をルール化していく必要がある。

204 DX白書2021

前項ではDX実現のための新しいITシステム開発手法として、デザイン思考、アジャイル開発、
DevOps、ノーコード／ローコードツールを紹介した。多くの企業ではすでに従来の開発手法を活用しや既存の手法との使い分けについて留意する必要がある。
既存システムを活用している企業が新しい開発手法を導入する際には、「小さく立ち上げて育てていく」
ことを意識することでスムーズに導入が進む場合が多い。
重要なポイントを3点紹介する。
（ア）新しい開発手法は業務への影響・リスクを考慮して導入する
これらの新しい開発手法は一度にすべてのITシステムに対して導入を行う必要はない。
すでに導入済みのITシステムを用いて既存の業務を行っており、とくに経験が蓄積されていない状態で新しい技術を導入してトラブルを発生させては本末転倒である。
そのため、既存の業務へ影響が少ない一部のITシステム、たとえば内部業務向けのITシステムを対象とすることで既存業務への影響を極小化しながら導入を進めるという方法がある。
とくに、
新しい開
発手法のメリットを最大限享受する意味でも、エンドユーザーのニーズに合わせたシステムへの機能追加や改修が高い頻度で発生する想定のITシステムや、業務自体が「小さく立ち上げて育てていく」ことを目指している業務のITシステム化を対象とすると親和性が高いと考えられる。
また、
前項で紹介したすべての開発手法を一度に導入する必要もない。
スキルの蓄積がない状態で多くの手法に手を出すと、中途半端な状態での導入となることも多く、こちらも既存の業務に影響を与えかねない。業務に与えるリスクと新手法導入による波及効果を勘案した適切な対象プロジェクトの選定が大切である。
（イ）小さい組織で立ち上げる
多くの場合、導入を開始する時点では、自社に新しい開発手法に関するノウハウやそのスキルを持った要員の蓄積は少ないもしくは全くない状態である。
この状態で組織内の多くの要員を集めて大きな組織として立ち上げるのは得策ではない。明確な適用方法が定まらない中では集められた要員の考えや思いを統一することができず、望んでいた効果を得ることは難しい。
そのため、
まずは、
小さく始めたう
えで、
その小さいプロジェクトのシステムの運用状況や業務に対してのインパクトを計測することで、効果を業務部門や経営幹部に示していく。
これによって開発リソースを確保するとともに、機能拡張のアイデアを膨らませてプロジェクトを大きくしていく。
これにより、
ノウハウと実績の蓄積、将来的に新しい開発手法活用の中心となり組織の中でもモデルケースとなる要員のスキルアップを目指す。
また、自社にないノウハウの獲得に外部の詳しい人材を雇用したり、自社にないノウハウを持った企業を活用したりすることによって、プロジェクトのリスクを下げると同時に、外部のノウハウの継承といった人材育成などの観点も踏まえたメンバー構築が大切である。
そうした中で、徐々にメンバーのス
キル・経験が蓄積されていき、複数チームが構成できるようになったところで少しずつ中規模の組織的な取組を開始すべきである。
その際、そうした活動をサポートしてくれるような組織間の連携体制と経営層の積極的な社内啓蒙活動の推進が非常に重要となる。

DX白書2021 205

開発手法・技術てITシステムを構築・運用している。
新たな技術や手法の導入を行う場合には、
既存システムとの接続｜第 ４ 部｜第 １ 章｜

（3）導入プロセス

（ウ）ビジネス部門を巻き込んで体制を作る
部分的な導入から進める、
小さな組織から立ち上げるといった、範囲を限定する方向性のポイントを紹介したが、範囲を広げる方向としてビジネス部門を巻き込んだ体制作りを行うことも重要なポイン
トである。
そもそも、新しい開発手法を導入する目的はユーザー部門にビジネス価値を素早く提供することで競合他社に対する優位性を確保することである。従来のITシステム開発ではユーザー部門が発注側、IT部門が受注側のような関係性であり、コミュニケーションのスピードは十分に速いとは言えず、IT
部門ではエンドユーザーのニーズに直接触れているわけではないためニーズ理解が弱くなり、結局新しい開発手法を導入したとしても得られる効果が小さくなる。IT部門とビジネス部門が連携し、よりエンドユーザーに近い要員を直接巻き込んだ体制で推進することが例え小さな組織であっても効果的にノウハウと実績を蓄積するためには重要となる。
そのためには、IT部門はビジネス部門の業務を理解し、どこに困っているのかを実感できるようにする必要がある。
またビジネス部門は、
自分たちの悩みがデジタル技術によって解決できるものなのか
どうかの感覚を持てるようにする必要がある。
このために、両部門の間で人材ローテーションを行うな
どの工夫をしている組織も存在する。
基本的には企業の規模によらず「小さく立ち上げて育てていく」ことが有効である。比較的規模の小さい企業は、既存システムの規模も小さい、システム化されていない業務も残されている、と考えられるので現行システムで行っている業務への影響は小さいためよりスムーズに新しい開発手法の導入を進めることができると考えられる。一方で、大企業に比べると、中核ビジネスに集中した人員配置となっていることが多く、その分IT関連に割ける人員もコストも少なく、ノウハウが蓄積されていなかったり、そもそもIT専門の部署がなかったりすることもある。そうした中でDXを推進していくためには、ビジネス部門がリードしつつも会社全体としてIT関連のケイパビリティを得るために、社内外のリソースを適時活用していく事が必須となる。
そのためにも、経営層がリーダーシップを発揮することがもっとも大事なポイントとなる。

（4）まとめ
本節では、現在注目されている新しいITシステム開発手法を4種類紹介した。それぞれの特徴について、
本項でまとめる。
デザイン思考VUCA時代のサービス開発において必要となるユーザーの真の問題とそれに対する解決方法を、具体化と抽象化を繰り返して洗練していく、デザイナーの思考プロセスをビジネスに適用した思考方法である。ユーザーへの共感（Empathise）を軸として、問題定義（Define）、創造（Ideate）、プロトタイプ（Prototype）、テスト（Test）のステージを繰り返すプロセスである。デザイナーの思考プロセスだけでなくそれに臨む態度（不確実性を受け入れる態度など）も重要となる。

206 DX白書2021

ウォーターフォール型の開発プロセスで進めることが難しいスピードやアジリティが求められるITシステムの開発に有効な開発手法である。
アジャイル開発は「何度も改修や機能追加を実施する」「要件｜第 ４ 部｜第 １ 章｜

アジャイル開発や環境の変化に柔軟に対応する必要がある」
といった特徴を持つITシステムに適用することが望まし
うえでチーム構成することが重要である。
DevOps
開発者と運用担当者が連携することによって、ソフトウェアによる新しいビジネス価値を迅速に顧客に提供するための手法であり、アジャイル開発とも相性がよい。DevOpsでは、開発と運用を一体運営するとともに、プロセスを自動化することにより従来の開発プロセスにおける「スピードを上げたい
開発部門と安全性・安定性を重視する運用部門とのギャップ」を解消する。
その実現のためには自動化技術とそれを支える事業/開発/保守チームの共通ゴールをめざすカルチャー醸成が重要な要素となり、コードコミットやテストを越えてコードデプロイまでの自動化（CI/CD）を各種ツール等を活用して実現する。
ノーコード／ローコードツール
プログラミング言語を使わない、あるいは一部簡単なプログラミングでシステム実装を可能とするツールである。従来は専門的な知識を持つエンジニアでないと開発が難しかった業務アプリケーショ
ンを非エンジニアである業務部門のメンバーでも開発を可能とすることが最大のメリットであり、IT
人材不足の補完にも寄与する。
既存システムを多く抱える企業では、
これらの新しい開発手法を導入するITシステムおよびツールの範囲と組織規模を絞り、ビジネス部門を巻き込んだ小さい体制で立ち上げて育てていくことで、既存システムへの新しいITシステム開発手法のスムーズな導入の実現を目指すべきである。
本章で紹介した手法は、顧客や事業部門のニーズを満たすために生まれたものである。そのため、ユーザー、消費者、顧客やビジネス組織のそれと近接したところにシステム開発を近づけていく、という志向性をもっている。
本節で紹介した各種開発手法が企業変革としてのDXを支える技術の根幹を成すものだと考えられる。

2 ITシステム開発技術（1）背景① はじめにデジタル技術の革新により、従来のビジネスモデルを変革する新規参入者が次々と登場している。
GAFA（米国の主要IT企業であるGoogle、Amazon、Facebook、Appleの4社の総称）を筆頭としたIT

DX白書2021 207

開発手法・技術い。推進にあたってはアジャイル開発において必要な各メンバーの役割と必要なスキルとを理解した

新興企業の勢いは凄まじく、既存企業は競争力維持のためにはDXの積極的な推進が求められるように旧態依然としたITシステム
なってきた。
日本では2018年に経済産業省が2025年の崖＊4の問題を提唱し、
国の調達・整備への取組方について警鐘を鳴らすとともに、DX推進ガイドライン＊5を作成するなど、を挙げてDXを促す取組を続けている。さらにはコロナ禍でリアル（店や人）での接点を低減し、デジタルによる繋がりが必要になるという急激なビジネス環境の変化も相まって、DXの推進はよりいっそ
うその必要性を増したと言えるだろう。
DXを推進していくためのITシステム開発は、従来と異なる部分も少なくない。従来とは全く異なる
ビジネスモデルを実現することや、新技術の採用が必要になることなど、
これまでの取組の延長線上で捉えることが難しいケースが多いためだ。DXで実現されるデジタルサービスは非連続な進化を続けていくことを前提に考える必要がある。さらには、既存のITシステムも独立した存在ではなく、非連続な進化を続けるデジタルサービスとの連携が求められることが出てくる。
したがってDXを推進していくためには、企業の経営戦略や課題に対し、高度なIT知識と広範なIT技術を複合的に取り入れ、システ
ム全体を俯瞰したITアーキテクチャー（業務アプリケーション、データ、システム基盤を含むシステム
全体の構造）
をデザインしなければならない。
では、どうすればそのようなITアーキテクチャーを実現できるのだろうか。
本節では、昨今のITアー
キテクチャーのトレンドの変遷を振り返り、
現在主流となっている考え方を踏まえ、DX時代に求められるITアーキテクチャーの特徴を整理する。
② IT アーキテクチャーのトレンドの変遷
技術革新によって、システム開発で採用される技術のトレンドは変化を続けている（図表41-7）。1980
年代末までのメインフレーム、1990年代のクライアント・サーバーシステムによるオープン化（脱メ
インフレーム）、2000年代のインターネットの普及によるWeb化を経て、今ではスマートフォンやクラウドの積極的な利用が主流となっている。
今後もブロックチェーンや5Gなどの新技術が普及していく
ことで、ITアーキテクチャーのトレンドは変化していくと予想される。

＊ 4 「DX
レポート ～ IT システム「2025年の崖」の克服と DX の本格的な展開～」経済産業省ウェブサイト
<https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html>＊ 5 「デジタルトランスフォーメーションを推進するためのガイドライン（DX 推進ガイドライン）」経済産業省ウェ
ブサイト
<https://www.meti.go.jp/press/2018/12/20181212004/20181212004.html>
208 DX白書2021

｜第 ４ 部｜第 １ 章｜

図表41-7

技術革新の変遷

1980年代1990年代2000年代2010年代2020年～

サーバー

インターネット

スマートフォン

ノートパソコン

ダム端末 メインフレーム

メインフレーム

パソコン

ブロックチェーン

プライベート
クラウド

RPA

AI

ユーザー価値の提供

ゼロトラスト

効率化

DB

クライアント・サーバー
Web
スマートフォン、クラウド（脱メインフレーム） （インターネットの普及）

さらなる新技術の誕生

技術のトレンドが一極集中型のメインフレームからクライアント・サーバー化による分散システムへ変化したことにより、
アプリケーション開発の世界では、標準化されたプログラムをさまざまなコン
ピューターで自律、分散的に実行することが求められるようになり2000年代からオブジェクト指向での開発が盛んになった。
それ以前のエンタープライズにおけるITシステムは、強力な一台のコンピューターに一つのプログラムを実行させるという考え方で作られていた。そのため、プログラムは業務単位でモノリシックな構造をとる
ことが多かった。モノリシックとは「一 枚 岩 」という意 味で、各サブシステムが適 切に分 割されず密 結 合
な状 態となっている。そのため一 部のサブシステムに変 更を加えた場 合のシステム全 体に対する影 響
範囲を見極めることが難しく、システム改修時に影響調査やテストに時間がかかる、開発規模が大きくな
り費用がかさむ、結果として頻繁なシステム改修が困難になる、などのさまざまな問題が発生しやすい。
こうした課題を解決するために、一つのプログラムをより小さな機能の独立したプログラムの連携として記述しようというオブジェクト指向のプログラミング、ソフトウェア開発が登場した。その後、古い既存システムを分割して再利用性や汎用性を高める技術が流行した。
こうした、独立したプログラム＝機能サービスが連携して一つのソフトウェアの全体を形作るとい
うSOA（Service Oriented Architecture）などのコンセプトをより発展させたものとして、最近注目されているのが、マイクロサービスアーキテクチャーである。マイクロサービスアーキテクチャーとは、小規模かつ軽量で互いに独立した複数のサービスを組み合わせて、システムを実現するという開発コン
セプトである。
マイクロサービスアーキテクチャーの導入によってITシステム内部構造におけるアプ
リケーションの疎結合化を図り、個別のサービスの変更に伴う影響範囲を小さくすることにより、デプ
ロイ（開発したソフトウェアを本番環境に配置し、利用可能な状態にすること）の柔軟性、拡張性を高める狙いがある。
先に挙げた問題を低減されデプロイがやりやすくなると、
システム開発のスピードが高まり頻繁な改修が可能になる。
また、技術の進化もシステム開発のスピードを高めることに貢献している。
とくにクラウドは利用したい時に必要な分のリソースを確保できるため、調達や構築に多くの時間を必要とするオンプレミスのシステムと比べアジャイルな環境構築が可能となる。
DX白書2021 209

開発手法・技術

5G
パブリック
クラウド

③ DX 時代に求められる IT アーキテクチャーの特徴
開発スピードを高める方向へITアーキテクチャーは進化を続けているが、その適用範囲はシステム・
サブシステムの種類や特徴に応じて検討していくべきとするのがITアーキテクチャーの基本的な考え方である。
企業が保有するシステムの特性を踏まえて、全社業務の効率化を支援する品質安定性重視のシステム（現状維持機能）と、収益拡大を目指す俊敏性重視のシステム（差別化機能）の2種類に大別し、それぞれについて適した実現方法で臨むということである。
現状維持機能には、
業務オペレーションを遂行するためのシステム群、
社内ユーザーが利用する人事
給与、財務会計、生産管理といった企業の業務と直接関わる業務向けシステムが含まれる。こうしたシステムは、品質と安定性を重視して、ウォーターフォールでしっかりと開発することの合理性が高い。
（ただし、経営環境の変化もそれなりに激しく、
アジャイルでの開発経験が豊富で、アジャイルでの社内開発要員の確保も容易なユーザー企業を中心に、基幹系システムに対するアジャイル開発も米国を中心に徐々に進んできているという実態もある。
）
他方、差別化機能には顧客との接点として利用するWebやモバイルアプリなどのシステム群が含まれる。差別化機能は、その機能や品質が事業のあり方に強く影響を及ぼすもので、DX推進においてはとくに重要とされる。
競争力強化を目的としたサービスの高度化が不断に求められるため、ユーザーの動向や趣味嗜好に合わせてシステムを柔軟に変更していくことが求められる。
この領域のシステムに対しては、開発やシステムのリリースサイクルを速めるため、アジャイル開発
やDevOpsを採用する傾向にある。昨今の技術の進化との親和性が高く、クラウドやマイクロサービス
アーキテクチャーなどを活用した新しいITアーキテクチャーの採用が望ましい。

（2）技術概要① 基本的な考え方
昨今のITアーキテクチャーは、デプロイを容易にして開発スピードを上げる方向に進化しているが、ITアーキテクチャーの進化だけで開発スピードが高まるものではない。
ウォーターフォール型開発からアジャイル開発への転換、DevOpsの登場などによって開発スピードが高まり、システムの変更頻度が増した結果として、ITアーキテクチャーも変化への強さを求められるようになったという事情を無視することはできない。
上記のような高頻度の変更の要請に耐えられるアジリティの高いITアーキテクチャーをいかに構築するかという考え方については、EA（Enterprise Architecture）の構造を把握すると理解しやすい。
EAは2000年頃に流行ったフレームワークで、上からビジネス、データ、アプリケーション、テクノロ
ジーの四つのアーキテクチャー階層から成る。経営戦略とITシステムの一貫性を維持し、全体最適化を実現するのに有効な手段である。この中でビジネスとデータの2階層については、ビジネスモデルが変化しない限り、大きく変わらない。
一方、
アプリケーション、
テクノロジーの二つの階層においては技術の進化が速く、技術トレンドの移り変わりも激しい。
本項では、
ビジネスとデータの2階層を支えるア
プリケーションアーキテクチャーとテクノロジーアーキテクチャーの両階層の動向について、とくに理解しておくべきポイントについて説明する。
まずはテクノロジーアーキテクチャーとしての「クラウ

210 DX白書2021

クロサービスアーキテクチャー /API」
について説明する。
図表41-8｜第 ４ 部｜第 １ 章｜ド」と「コンテナ」、そしてその技術を基に構成されるアプリケーションアーキテクチャーである「マイエンタープライズアーキテクチャーと変化のスピード
開発手法・技術

ハードウェア/ネットワーク等の情報基盤で採用すべき技術標準② クラウド（ア）クラウドの概要
従来、自前でデータセンターやサーバーを用意してITインフラを構築していたが、近年では、クラウドサービスがITインフラとして利用され始めてきている。
クラウドという言葉は広く使われており、多くの企業がクラウドを活用したITシステムを開発、提供しているが、クラウドにはさまざまな形態があ
クラウドの明確り、
定義が不明瞭である。
米国国立標準技術研究所（NIST）の2009年の公表資料＊6では、な定義はなされておらず、「オンデマンド・セルフサービス」「幅広いネットワークアクセス」
「リソース
の共用」
「スピーディな拡張性」「サービスが計測可能であること」の五つの特徴をあわせ持つもの、との表現にとどまっている。
明確な定義はないものの、さまざまなクラウド活用事例から、クラウドの利用パターンは大きく「プ
ライベートクラウド」と「パブリッククラウド」に分類できる。自前でITインフラのハードウェア自体を保有、運用するオンプレミスに対して、「プライベートクラウド」
は特定の組織専用で利用するクラウド、「パブリッククラウド」はクラウドベンダーが広く一般向けにITインフラとして提供するクラウド
であり、他の組織と計算リソースなどを共有して利用する形態となる。またほかにも、オンプレミスあ
るいはプライベートクラウドとパブリッククラウドを組み合わせた「ハイブリッドクラウド」、複数のパブリッククラウドを組み合わせた「マルチクラウド」
等のパターンも存在する。
（イ）クラウドサービスパターン
クラウドの代表的なサービスにIaaSとSaaSがある。IaaSは単なるハードウェア機能のみが提供され＊6“ The NIST Definition of Cloud Computing（SP 800-145）”, NIST Website<https://csrc.nist.gov/publications/detail/sp/800-145/final>
DX白書2021 211

OSやアプリケーション開発は利用者側が用意することを前提としている。
一方、SaaSではソフトウェ
アが提供する機能をサービスとして使うため、その機能は提供者側で設計、開発されたものとなる。
クラウドサービスパターンは、IaaSやSaaSにくわえて近年のコンテナ技術やサーバーレス技術の発展により増加傾向にある。近年の技術動向も踏まえたクラウドサービスの提供パターンを図で表現す
ると、
図表41-9のとおりである。
図表41-9

クラウドサービスパターン（a）IaaS（Infrastructure as a Service）
クラウドベンダーは、ハードウェア、仮想化（ハイパーバイザー）を提供する。利用者は、IaaS上でOSやミドルウェア、
アプリケーションなどを構築、管理する。
（b）CaaS（Container as a Service）
クラウドベンダーは、
クラウド上で構 築されたコンテナ管 理 環 境を提 供する。利用者は、コンテナ上にミドルウェア、アプリケーションを構築、管理する。なお、コンテナの詳 細に関しては次 項目で紹 介する。
（c）PaaS（Platform as a Service）
クラウドベンダーは、
クラウド上で構築されたミドルウェアを提供する。
クラウドベンダー側がミド
ルウェアの管理、運用を行うため、利用者はミドルウェアの利用のみを意識すればよく、ミドルウェア
を組み合わせてアプリケーションの実装を担う。
（d）FaaS（Function as a Service）
クラウドベンダーは、アプリケーション実行環境を提供する。つまり、利用者はプログラムだけ用意すれば、その実行に必要な環境整備はクラウドベンダーに委ねられる。
利用者が意識する必要がある要
素はアプリケーションのロジックとデータのみであり、
アプリケーションの実行に関連する管理、運用

212 DX白書2021

PaaSなどと比べると料金の圧縮が見込まれる。
ただし、ロジックの実行が終わったら環境自体が消去される作りになっているため、永続保存するデータについては、別のDBやストレージなどのPaaSサービ｜第 ４ 部｜第 １ 章｜はクラウドベンダー側が担う。
また、
アプリケーションの実行時間に依存した課金となるため、IaaSやスを活用して保持する必要がある。

クラウドベンダーは、アプリケーション自体を提供する。利用者は、アプリケーション利用者として設定、利用はするが、アプリケーションのカスタマイズはできない場合が多い。
一般的に、利用量に応じた料金設定となっていることが多い。
（ウ）クラウドの利用のメリット・デメリット
クラウドの利用を検討するにあたっては、コスト削減や期間短縮などのメリットだけではなく、そのデメリットの把握も必要である。本項目ではクラウドの特徴として、クラウド活用のメリット、デメリットの両方を、①品質、②コスト、③スピードの観点で整理する。
クラウド活用によるメリットは次のとおりである。
（a）品質のメリット
クラウドベンダー側からセキュリティ機能が提供され随時最新パッチが適用されることや、国内、海
外を問わず信頼性の高いデータセンター運用が享受できること、サービスパターンによってはシステ
ム運用の一部をクラウドベンダーに任せることができること、業界で標準化されたベストプラクティ
スと考えられるソフトウェア等が利用できること、などが挙げられる。
（b）コストのメリット
初期投資やシステム更改時の機器費用を削減できること、利用した分に対する課金であり利用しな
い分はコスト抑制できること、IT資産を保有しないため固定費が変動費化できること、などが挙げられる。
（c）スピードのメリット
先進技術が積極的に提供されること、機器の購入設置が不要で迅速にシステム利用ができること、サービスを中止したい場合に減価償却を気にせずにすぐに利用中止できること、ITインフラの拡張や縮小が迅速、柔軟にできること、ITインフラの構成をコードの記述内容に従って設定する
Infrastructure as Code
（IaC）の機能を利用することによりインフラの構成管理をアプリケーションと同様にコードで管理できることなどが挙げられる。
一方、
クラウド活用によるデメリットは次のとおりである。
（a）品質のデメリット
クラウドベンダーのセキュリティ対策内容が公開されずブラックボックス化することや、他社シス
テムに起因する障害、性能問題が起こる可能性があること、クラウドベンダーによるメンテナンス時間

DX白書2021 213

開発手法・技術（e）SaaS（Software as a Service）

などの制約を受け入れる必要があること、
クラウド事業者がより厚い環境提供をするほど、その上に構築するシステムの当該環境への依存性から、
ベンダーロックインが起き、当該システムを他のクラウドに移行できなくなる危険性があること、
適切な統制や管理ができないと、クラウドベンダー側から自動的に提供されるITシステムの自社職員による勝手な利用（シャドー IT）が横行してしまう可能性があること、利用者側にもクラウドの知識が求められ重厚なサポートは受けづらいことなどが挙げられる。
（b）コストのデメリット
料金体系によっては自社構築より割高になる可能性があることが挙げられる。とくにサーバーの常時起動が必要、大容量のストレージが必要、クラウド外部との大容量のデータ送受信が必要な場合は、割高になる可能性が高い。
（c）スピードのデメリット
スピード面での大きなデメリットはないが、あえて言えば、迅速さを実現するために拡張単位が提供メニューによって制限されておりカスタマイズ性が低いことや、クラウドベンダー側の都合で機能の改廃がなされるため変化のスピードに追従し対応が求められることが挙げられる。
このように、クラウドは多くのケースでメリットを享受できる可能性の高いITインフラである。
一方で、クラウド利用に対応できる技術者が不足していたり、構築するITシステムのプログラムとしての実
行量や外部とのデータのやり取りの頻度、量など、コストに直結する要素を適切に見積もるノウハウがなかったりするなどの理由で、クラウド利用を躊躇している組織が存在することも事実である。
利活用にあたっては、中途採用や社内でのエンジニア育成、外部パートナーの積極的な活用等をとおして、ク
ラウド技術のケイパビリティがその組織の経営やビジネスに資するように動くことがDXの推進という観点でも非常に重要である。
③ コンテナ（ア）コンテナの概要
サーバーの仮想化とは、1台の物理サーバーをあたかも複数台のサーバーであるように利用できる仕組みである。仮想化技術によって作られたサーバーは仮想サーバーと呼ばれ、物理サーバーにハイパーバイザーと呼ばれる仮想化ソフトウェアを用いることによって動作環境を作る。それぞれの仮想サーバーは独立しており、異なるOSやアプリケーションを実行させることが可能である。
仮想化には多様なOSやミドルウェアなどを必要とする開発環境の構築を容易かつ素早く実現できるというメリットがあり、開発環境構築という点でも必要不可欠な技術となった。
コンテナサーバーは仮想化と異なり、OSを含まない形でアプリケーションの実行環境をパッケージ化したものである（図
表41-10）。
そのため、サーバー仮想化よりも高速に実行環境を構築したり、移行・起動・削除することが可能となり、より早くシステムを開発し顧客に届けるというビジネスニーズに応えるための技術として注目が集まっている。

214 DX白書2021

｜第 ４ 部｜第 １ 章｜

図表41-10コンテナ概要オンプレミスコンテナ

サーバー仮想化

アプリケー
ション

アプリケー
ション

アプリケー
ション

アプリケー
ション

アプリケー
ション

アプリケー
ション

アプリケー
ション

アプリケー
ション

ミドルウェアミドルウェアミドルウェアミドルウェアミドルウェアミドルウェアミドルウェアミドルウェアミドルウェアライブラリー

ライブラリー

ライブラリー

コンテナ

コンテナ

コンテナ

OS

ハードウェアOS

ハードウェアOS

ハードウェア

ゲストOS

ゲストOS

ゲストOS

仮想
サーバー

仮想
サーバー

仮想
サーバー

コンテナ管理OS

仮想化（ハイパーバイザー）

仮想化（ハイパーバイザー）

ハードウェアハードウェア（イ）コンテナの特徴
コンテナイメージ内にはOSが含まれず、
アプリケーションやミドルウェアを稼働させる最低限のライブラリーのみでよいため、各コンテナ内に実装するシステム分量は仮想化環境に構築した場合よりも軽量となる。そのため、管理が容易になり、コンテナの構築や廃棄も迅速に行うことができる。また、コンテナは、
オンプレミスやクラウドを問わずさまざまな環境で稼働したり、稼働環境を移動したりできるといった可搬性が高いという特徴を持つため、開発環境で開発したアプリケーションが本番環境で動かないリスクを軽減することができる。
また、実運用する場合には多数のコンテナを稼働させる必要性があるが、それを管理するためのツール（コンテナオーケストレーションツール）を用いることで、実行処理の負荷を複数のホストを跨いで管理するなどの高度な調整を行うことができる。これはシステムを安定的に実行していくには便利な特性である。
一方、コンテナが向かないシステムも存在する。
具体的には、
上記の特徴が求められない、頻繁な変化を必要としないシステムに対しては、仮想化で十分なケースも多い。
④ マイクロサービスアーキテクチャー /API（ア）マイクロサービスアーキテクチャーの概要
アジャイル開発やDevOpsによる高速開発を支えるためアプリケーションアーキテクチャーとして本命と目されているものがマイクロサービスアーキテクチャーである。マイクロサービスアーキテ
クチャーは「あるサブシステムでの変更が、他のサブシステムにおよびにくくする」ことを目的とした
API（Application Programming Interface）
による疎結合化を強く推し進めた形である。
ここでは現在主流のアーキテクチャーとしてマイクロサービスアーキテクチャーについて説明するが、実装においては目的に応じた適切な粒度での疎結合化が肝要である。
マイクロサービスは2014年にJames Lewis氏とMartin Fowler氏によって提唱され＊7、図表41-11に示す九つの特徴を持つとされる。
これらは当時の先進的な事例に共通する特徴として見出されたものであり、＊7“Microservices” <https://martinfowler.com/articles/microservices.html>
DX白書2021 215

開発手法・技術

アプリケー
ション

厳密な定義ではないとされているが、多くのマイクロサービスアーキテクチャーではこれら九つの特性を示すと考えられた。
図表41-11マイクロサービスアーキテクチャーの九つの特徴（イ）マイクロサービスアーキテクチャーの特徴
マイクロサービスにおけるアプリケーションアーキテクチャーの観点の特徴としては、以下に示す3点が重要となる。
（a）APIによる疎結合化
コンピューターのプログラムは、
繰り返し何度も同じパターンを実行することが多く、そうした一定の処理を別のプログラムとして独立させ、元のプログラムは必要に応じてそのプログラムを呼び出すという構造化が多段階に起きるようになった。マイクロサービスアーキテクチャーの思想においてこの考えはさらに徹底され、現在ではシステムが複数の独立したサービス（仮想化されたコンピューターといってもよい）としてモデル化され、二つのサービスの間で予め定められた仕様に基づき通信を行う
イメージで捉えられることが多い。
こうしたモデル化の中で、相手のサービスを呼び出すための接続仕様（名称や引き渡すデータやその形式等）をAPIと呼ぶ。複数のサービスがAPIを通じて連携することで、全体として一つのシステムとして動作するのがマイクロサービスアーキテクチャーの特徴である。
このように、複数のサービスがAPIを通じてのみ通信するようにした結果、APIで規定された通りの挙動を保証する限りにおいて、呼び出される側のサービス改修は自由に実施可能となる。
これによってサービス単位でのデプロイ、
言い換えれば所要の部分ごとに改修することが可能となり、システムの改修頻度を高めることに繋がっている。また、新旧のAPIを併用することによって、サービスに対する仕様変更の影響を最小限に抑えることもできる。
なお、APIには軽量なHTTPプロトコルが使用され、REST APIが用いられることが多い。また、APIの管理可能性を高めるため、API Gatewayと呼ばれるプロダクトを利用することも一般的で、API Gatewayを用いることでトラフィック管理、
認証認可、
アクセスコントロール、API バージョン管理などの機能を集約することができる。

216 DX白書2021

マイクロサービスアーキテクチャーは分散システムであり、各サービスが独自にデータベースを管理する。
あるサービスが他のサービスのデータベースにアクセスする場合は、そのサービスが提供する｜第 ４ 部｜第 １ 章｜（b）個々のサービスに閉じたデータ格納

APIを経由してデータを操作する。
るが、
この場合、
データベースへ修正を加える際に他サービスに与える影響を見極めることが難しくなる。
しかし、
データベースを共有せず、その操作をAPI経由に限定することで、サービス間の疎結合な状態を保つことができる。
マイクロサービスアーキテクチャーにおいて各サービスが自律的にデータベースを分散管理することはマイクロサービスアーキテクチャーの思想に基づいたスタイルであるが、同時に、モノリシックな
実装にまつわる不確実性を抑止する有効な方法となっている。
（c）データ内容の一貫性に対する妥協
他方で、
マイクロサービスアーキテクチャーのような分散型システムの原理上の限界によって、
通信障害によりシステム全体が機能不全になることを避けるように考えられているマイクロサービスアー
キテクチャーは、
システム内において、各サービスが矛盾したデータベース状態を保持する可能性がある。
もちろん、システム内での矛盾状態は放置できないので、各サービスの状態を確認できなかった段階
で更新のキャンセルを行う方法や、問題があれば元の更新を打ち消すような処理をするなど、結果的に矛盾を解消するような措置を実装することで問題を緩和できる。
しかしながら、
時間的な制約が厳しい
場合に厳密な整合性の確保は苦手であるということは特徴の一つとして指摘できる。
（ウ）マイクロサービスアーキテクチャーの構成要素
マイクロサービスアーキテクチャーの実現に必要な構成要素は複数存在するが、中でも重要な役割を持つのは、コンテナとサービスメッシュの二つである。各サービスを実装するためにコンテナを用いることにより、
アプリケーションの可搬性と自由度が上がり、デプロイの容易性を高めることができる。
サービスメッシュはマイクロサービスアーキテクチャーにおいて、各サービス間で行われる通信を支えるネットワークサービスである。主に、サービスの発見（サービスがデプロイされる度に依存関係にあるサービスを調査し、システム側で適切な接続先を決定する）、
障害の分離（通信障害が起きた時に他のAPIを遮断し、波及を防止する）、分散トレーシング（サービス間の通信内容を監視、追跡して問題発生時に発生個所の特定等を支援する）、認証・認可（セッション情報やアクセス権限などを一元管理する）といった役割を担う。
こうした機能はマイクロサービスアーキテクチャーの実装には必須と言ってよいが、それを共通のシステム基盤として実装することで、通信に関する問題を各サービスが個別に実装する必要がなくな
り、
システム開発者はアプリケーションのロジック開発に集中することができるという利点もある。

DX白書2021 217

開発手法・技術

モノリシックなシステムではしばしば複数のサービス間でデータベースを共有するように実装され

図表41-12

サービスメッシュ（3）導入プロセス、事例① 基本的な考え方
本項では、前項で挙げた「クラウド」「コンテナ」「マイクロサービスアーキテクチャー」の導入の進め方について概略を説明する。
DXを実現するためのITシステムに求められるものの第一は柔軟性である。そのため、実行環境の制約を可能な限り小さくすることがまず考えられ、その具体的なあり方としてクラウドを念頭においたコンテナ技術による実装を考えることになる。そして、システム内部においては、コンテナの中にサービス単位で実装し、それらが互いに通信するスタイルで連携するというマイクロサービスアーキテク
チャーで全体機能を実現していくのである。
そのため、まずはオンプレミスで稼働しているITシステムを、ITシステムの作りを大きく変えず、
主にクラウド活用を中心にインフラのみを変革する対応を行う（リフト）。
その後、DXに最適化されたITシステムへ、クラウドネイティブ化を軸にアプリケーションの作りも含めて変革していく（シフト）という方法が一般的である。
「リフト」
は、オンプレミスで稼働しているITシステムに対して、
クラウド上のIaaSやCaaSを活用したり、
オンプレミス環境にコンテナを導入したりするものである。
アプリケーションの構成が大きく変わらないため短期間に移行可能で、
クラウド活用によるオンプレミスからの脱却や、コンテナ活用によるサーバー集約などにより、
データセンターやサーバーの費用削減を見込むことができる。
「シフト」は、クラウド上で提供されるソフトウェア資源を活用し、実装部分を軽量化しながら、よりDXに最適化した構成へとITシステムを作り変えていくものである。この段階で、マイクロサービス
アーキテクチャーやFaaSを取り入れ、
アプリケーションの抜本的な作り直しも含めた変革を行い、あわせてアプリケーションの開発方式も変革していく。
これにより、
より変化に強いITシステムを実現することが可能となる。

218 DX白書2021

要素として、「クラウド」「コンテナ」にくわえて「マイクロサービスアーキテクチャー」に関する導入プ
ロセスや事例を説明する。

（ア）クラウド活用方針策定
クラウドは、気軽に利用が開始できる反面、統制についての考慮が欠かせない。
たとえば、
クラウド活
用方針を曖昧にしたままクラウド活用を進めてしまうと、各部署が自由に利用してしまい、
結果として情報漏洩や高額な利用料請求に繋がってしまうリスクがある。そのため、クラウド導入を進める際には、まずは、企業のクラウド活用に関する方針をまとめ、社内で合意する必要がある。
クラウド活用対象とするシステム種別（例：顧客接点を担うシステムは対象とするが、基幹系システムは対象としない）
や取り扱うデータ（例：個人情報や機密情報はクラウドにアップロードしない）、
セキュリティ
（例：社
内LANから専用線経由でしかアクセスさせない）、
ガバナンス（例：クラウド契約は社内の管理部署経由で行う）などの活用方針、利用規定を定める。
クラウド活用方針の策定においては、
企業ルールとの適合性とシステム特性が問題になりやすい。
企業ルールとの適合性は、クラウドの持つ特性が従来のオンプレミスのITシステムと異なることによるものである。たとえば、クラウドの課金体系は従量課金であるため予算を定めて調達する自社
調達プロセスと合致しない場合や、自社のセキュリティルールでITシステムの現地監査が求められるのにクラウドは現地監査を許可していない場合などである。基本的にはクラウドを考慮したものに社
内ルールを作り直す必要があるが、たとえば課金体系については定額サービスの利用や利用費用のア
ラーム機能を用いつつ日々の注意深い運用でカバーすることで代えることも可能であろうし、現地調査については、別途証明書の提示で代替できないか調整するなどの対策も考えられる。
システム特性の観点では、クラウドの特性を考慮する必要がある。たとえば、一般的にクラウドからデータを持ち出す場合に、データ容量に応じて課金される場合が多い。そのため、大容量のデータのやり取りは可能な限り同一クラウド内でやり取りするようにしないと、高コストなシステムとなってしまう。
（イ）クラウドへの移行利用するクラウドプラットフォームを選定する。これは、利用しようとしているサービスの有無や、耐障害性などのサービスレベル、
オンプレミスからの移行のしやすさ、
セキュリティ基準に準拠しているか、
コスト見込みなどから選定する。
次に、クラウド移行の進め方を検討する。
まずは、
クラウド活用方針に従い、クラウド化するシステムとクラウド化しないシステムを選別し、その後、クラウド化する場合の移行先（プライベートクラウド
かパブリッククラウドか、IaaS ～ SaaSのどれを選ぶか）を決定する。事前に判断基準を明確にできな
い場合は、クラウド移行先を相談する部隊を設置するやり方でもよい。
政府情報システムにおける事例では、
基本方針として、
クラウド・バイ・デフォルト原則＊8を挙げている。
具体的には、
システム開発を検討する際に、コストや利活用条件（情報セキュリティに関する諸規＊ 8 「政府情報システムにおけるクラウドサービスの利用に係る基本方針」

政府 CIO ポータルウェブサイト
<https://cio.go.jp/sites/default/files/uploads/documents/cloud_policy_20210330.pdf>
DX白書2021 219

開発手法・技術② クラウド導入の進め方｜第 ４ 部｜第 １ 章｜

以降では、「リフト」を実現するための要素として「クラウド」「コンテナ」「シフト」を実現するための

定との整合性なども含める）などを総合的に勘案しつつ、まずはSaaSを利用できないか、
その後、IaaS/
PaaSの利用で対応できないかと評価し、こうしたクラウド基盤での実現が不適切であると判断された場合にのみオンプレミスの利用を検討するものである。
これらの検討は、
有識者（府省CIO補佐官）の関与の下で行われる。
次に実際に決定し、調達されたクラウド環境にITシステムを移行するわけであるが、この場合にも、そのまま移行作業に入るのではなく、クラウドの特徴である、容易に利用開始、利用停止できる点を活かし、これまで検討したクラウド活用方針やクラウドプラットフォーム、移行方式に則したクラウド活用を進められるか、
概念検証（Proof of Concept; PoC）の実施を推奨する。
少数の個別システムに対して、先行してクラウド活用を進めてもらい、クラウド活用方針が現実的か、選定したクラウドプラット
フォームで問題なくシステム構築、運用、移行ができるか、を検証する。
こうした段階的な準備を踏まえ、
「リフト」
「シフト」
によるITシステムの移行を行うのである。
（ウ）クラウド導入後の運用に関する検討
クラウドは日々進化を続けるため、クラウド導入時だけでなく、クラウドを導入した後、どう活用していくかについても検討が必要である。構築時にはベストプラクティスだった構成も、数年経てば新たなサービスが提供され状況が変わることが容易に起こりうる。また、クラウドは利用者が適切に中身を理解して使うことを求めている。そのため、クラウドは利用する側にもスキルを身に着ける必要があり、進化するクラウドに追従可能なクラウドを活用する人材の育成も必要となる。そのような状況に対応するため、
クラウド関連の状況と情報を把握し対応を進めるための専門部署（Cloud Center of
Excellence; CCoE）（図表41-13）を導入する企業も出てきている。
図表41-13

CCoE概要③ コンテナ導入の進め方（ア）コンテナ活用方針策定
コンテナ導入の第一歩として、
コンテナ活用方針をまとめる。
どのようなシステム種別であればコン

220 DX白書2021

ラウドを活用するか、
コンテナオーケストレーションツールはどう運用するかなど、コンテナに関する全体方針の検討を行う。

｜第 ４ 部｜第 １ 章｜

テナ化対象とするのか、活用方針を定める。また、コンテナ実行環境として、オンプレミスにするか、クコンテナ導入は、単体で検討を進めるよりも、前述のクラウド導入も含めた、企業全体のITインフラも可能である。また、本当に今のシステムにコンテナが必要か、の考慮が求められる。2
（2）③
（イ）で述
べたような、コンテナに向かないシステムではないか、
メリット、
デメリットを比較したうえで、コンテナを導入した方が効果を見込めると判断できる場合に導入することを推奨する。
（イ）コンテナ実行環境、移行方式の決定
コンテナについては、
これを実現するためのさまざまなツールがすでに数多く提供されているため、コンテナ活用方針に基づいて決定されたコンテナ化の方向に従って、最適なものを選ぶという作業が中心となるであろう。
選定にはトレンドや実績、コストなどを総合的に勘案する必要がある。
コンテナ技術はまだ比較的新しい技術であり、業界標準として採用される実行環境・ツールも日々変化していくと見込まれる。
そのため、クラウドベンダーをはじめとした業界動向や採用事例をもとに、採用するコンテナ実行環境、コンテナオーケストレーションツール等を選定する。また、コンテナ移行作業についても、一般的にはコンテナ移行ツールを選定し、利用することが多い。
なお、
実際のコンテナ導入にあたっては、
コンテナ導入のベストプラクティスを参考にすることが望
コンテナに関連する潜ましい。
また、NISTは2017年にコンテナセキュリティガイド＊9を発行しており、在的なセキュリティリスクと、リスクに対処するための推奨事項を提供している。なお、このようなベストプラクティスをそのまま採用するのではなく、導入対象となるシステム種別や特有の事情に合わせた判断やカスタマイズが必要な点は、留意が必要である。
（ウ）概念検証
コンテナについても、概念検証の実施を推奨する。コンテナ環境上で業務サービスを提供しているケースを想定し、構築・テスト・リリースに関してコンテナ環境特有の要素を洗い出す。とくに、コン
テナは構成管理の機能を包含しているためIaCやCI/CDといった自動化と相性がよい技術なので、これら自動化関連技術を組み合わせて想定通りの効果を得ることができるか、検証を行うことが望ましい。
また、性能や耐障害性といった非機能要件の観点での検証を行い、業務サービスが実用に耐えうるかの
検証も合わせて行う。
④ マイクロサービスアーキテクチャー /API 導入の進め方（ア）マイクロサービス化の始め方
マイクロサービスアーキテクチャーの導入の先進企業として有名なNetflix（米国）の取組はPoCから始まった。モノリシックなシステムに対して100人以上の開発者が書いたプログラムを集めて2週間に一度本番リリースすることに限界を覚え、その解決策としてマイクロサービスアーキテクチャーに＊9“ Application Container Security Guide（SP 800-190）”, NIST Website<https://csrc.nist.gov/publications/detail/sp/800-190/final>
DX白書2021 221

開発手法・技術検討の一環として進める必要がある。
コンテナの実行環境自体は、
オンプレミスでもクラウド（CaaS）
で辿り着いたとされる。
また、
マイクロサービスアーキテクチャーの導入は一部の対象から徐々に適用範囲を広げるアプローチをとり、小さなプロジェクトを重ねてマイクロサービスアーキテクチャーの導入への取組を洗練させていった。
その結果、今では同社のサービスは多数のマイクロサービスで構成されている。Netflixの取組は絶対的なものではないが、開発の不確実性を下げるためのPoCの実施や、小さく始めて徐々に適用範囲を拡大するスモールスタートのアプローチは一般的に有効だと考えられている。
なお、Netflixの事例では、開発スピードを加速するための手段としてマイクロサービスアーキテク
チャーを採用した点に注目する必要がある。
一般的にシステム再構築が必要となる原因は多様であり、常にマイクロサービスアーキテクチャーの導入が正解だとはいえない。マイクロサービスアーキテク
チャーの導入は後述のとおり試行錯誤を重ねながら取組むことを求められるため、その導入目的およびKPIを初期段階で設定することが重要となる。マイクロサービスアーキテクチャーの構成要素で触れたような複雑化したシステムを支える仕組みや技術者のスキルも求められるので、こうした諸条件も勘案してマイクロサービスアーキテクチャーの採用可否を判断すべきである。
（イ）システムと体制の段階的移行
マイクロサービスアーキテクチャーの導入によって、各マイクロサービスが他サービスとの調整なく自律的にシステムを改修できるため、開発スピードが高速化される。
このため、マイクロサービスアーキテクチャーの導入は、それぞれの業務を最高速でこなせるようなシステム開発・運用体制への変更も要請する。この点について、Amazonでは創業者のJeff Bezos
が提唱する、「各チームの人数はピザ2枚を分けられる人数を超えてはならない」という Two-Pizza
これによれば、各チームの最大人数は8名に制約される。
こうしたTeams＊10と呼ばれるルールが存在し、小さなグループが自律的にシステムを開発していくが、これを協調的に動かすために、実装を進める過程での齟齬や揺り戻しは必ず発生すると考えることが重要である。
このようにマイクロサービスアーキテクチャーの導入はそもそも漸進的なシステム開発であり、したがって、システム再構築も、従来の一括（ビッグバン）でのシステム切替えではなく、段階的に切替えていくことが有力な選択肢となる。また、とくに長期間稼働しているシステムは、改修を重ねて大規模になっている場合が多く、大規模システムの一括切替えは、リスクが高く制御不可能なプロジェクト規模になってしまうことから、数多くの機能の中から変更が頻繁に行われる機能を中心にマイクロサー
ビスアーキテクチャーへ段階的に移行することによって、プロジェクトのリスク管理、
制御可能性を確保できる。
段階的な切替え方式としては、
まずシステム間連携を担うゲートウェイ（Strangler Facade）
を通じて
内部システム間で連携を行う方式にシステム全体を切替えてから、徐々にシステムを切替えていくやり方がよく知られている（Strangler Application Pattern）。

＊ 10“ Two-Pizza Teams”, AWS Website <https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html>

222 DX白書2021

｜第 ４ 部｜第 １ 章｜

図表41-14

Strangler Application Pattern

開発手法・技術（ウ）複合的な推進マイクロサービスアーキテクチャーをITアーキテクチャーの観点だけで取組むことは推奨されない。
アジャイル開発やDevOpsの採用、CI/CD環境の導入などと合わせて開発スピードを高めていくた
めの手段であることは強く意識するべきである。
また、市場や利用者の変化に追随するために設計時にすべてを確定させることは困難であるという特性上、システム開発会社に請負契約で開発を任せている場合は、成果物の定義が難しくなる。
システム開発の内製化やシステム開発会社との契約体系の見直しが必要になる可能性もある。また、社内の組織運用も、Two-Pizza Teamsルールが示唆するように、
小規模化、自律化が望ましい。このように、マイクロサービスアーキテクチャーは会社組織の機能や運用を改革するさまざまな取組と組み合わさり、複合的に推進されていくことで効果をより発揮するのである。

（4）まとめ
本節では、DXを実現するためのITシステム開発技術として、主に「クラウド」「コンテナ」「マイクロ
サービスアーキテクチャー /API」について取り上げ、技術概要や導入プロセスについて説明した。
「クラウド」については、メリット、デメリットや、クラウドサービスパターン、導入の進め方や体制について紹介した。
「コンテナ」
については、
仮想化技術との違いやコンテナが向くシステムと向かないシステ
ム、コンテナオーケストレーションツールについて紹介した。
「マイクロサービスアーキテクチャー /API」については、特徴や特有の構成要素、マイクロサービスアーキテクチャーの導入の進め方について紹介した。
これらが示唆する今後のITシステム開発技術での重要ポイントは、多様性と最適化、自動化、そしてそれらを実現するための各種ツールの活用であろう。ITを利活用するユーザー企業では、企業全体、
あるいは部署ごとに多様なニーズがあり、それはITシステムの各部分において異なるニーズがあることを意味する。市場で提供されるITインフラ・サービスはインフラの提供形態、クラウドのサービスパ
ターンが示唆する通り多様化の方向に進んでいるが、どれをとっても企業全体のニーズを過不足なく満たすものはなく、結局のところ、それぞれに最適な選択をせざるを得ない。
問題は、この多様な選択、多様な開発を認めつつ、それらを協調させて、企業として統一的な運用を実現しなくてはいけないということであろう。
この調整作業は極めて煩雑で、これを人の手で行うことはDX白書2021 223

極めて困難であり、そしてその巧拙がITシステムの動作品質に、ひいては企業のパフォーマンスに影響してしまう。
そのため、これをカバーする各種ツールが提供されており、技術的対応も、
どのツールを利用するか選択するかの重要性が増している。
このツールによる調整の自動化は、開発面においても大きな省力化につながっていることは、CM（構成管理）やCI/CD（継続的インテグレーション/継続的デリバリー）について説明した通りである。これにより、ITシステム開発者はITシステム開発の環境準備に心を砕く必要なく、アプリケーションに必
要なロジック部分に注力することができるようになっている。
前節で取り上げたローコード/ノーコー
ドは、
このトレンドが事業部の現場にまで広がってきていることを示唆しており、DXの実現において、現場でのIT開発は必須要件とまで言われている。そして、それを実現するためには、それを支える適切なアプリケーション、
ツールの導入が不可欠なのである。
アプリケーションやテクノロジーの進化は早い。
近年のITシステム開発技術では欠かせないクラウドを中心に、ITシステム開発技術のトレンドを日々追いかけ、自社に最適なITシステム開発技術を模索していくことが肝要である。

3 開発手法・技術の活用状況と課題
本節では、前節までに紹介した手法・技術についてアンケート調査を実施し、それらの活用状況や導入課題を把握するとともに、活用の方向性を検討した結果を説明する。

224 DX白書2021

企業が環境変化への対応に向けてデータ分析を行ったり、新しいアプリケーションを追加したり、新サービスを短期間で立ち上げたりするために、ITシステムには「スピード・アジリティ」や「データ利に求められる機能について、各社における「重要度」の認識を尋ねたものである。
日米企業の差は顕著であるが、とくに「変化に応じ迅速かつ安全にITシステムを更新できる」
については、「重要である」と回答した企業が日本では30.3%、
米国では55.8％と2倍近い差がある。
図表41-15

ビジネスニーズに対応するためにITシステムに求められる機能（重要度）
0

変化に応じ迅速かつ安全にITシステムを更新できる

20

日本（n=534）
構造が柔軟で外部の有用なサービスと連携して活用できる
米国（n=369）

20.8

取引先など、社外
パートナーとの信頼性の高いデータ連携

プライバシーの強化

36.7

日本（n=534）

日本（n=534）■重要である日本（n=533）
米国（n=369）■まあまあ重要である

17.1

30.9
35.2

18.2

29.8
32.6

35.5

42.0
18.8

35.1

■どちらとも言えない

7.0

25.5

3.6 5.1

16.5

9.8

3.5

2.7

4.5 5.4
7.0 6.5
6.6 5.8

21.4

11.1

29.0

5.4 5.4

33.6

41.2

22.5

36.9

31.3

1.9

6.2 5.4

17.3

28.2

28.8

7.6

30.5

39.3

米国（n=369）

7.3 5.1

31.5

24.3

米国（n=369）

33.7

26.8

40.1

米国（n=369）

11.4 3.3 1.6

33.9

34.5

米国（n=369）

場所に依存せず業務を遂行できるリモートワーク

33.7

4.1 4.9

27.9

38.8

40.1

日本（n=534）

日本（n=534）

26.0

55.8

34.7

（％）
100

80

34.6

米国（n=369）

17.2

部門間で標準化したデータ分析基盤

60

30.3

日本（n=534）

小さなサービスから始め、 日本（n=534）
価値を確かめながら拡張
していくことができる
米国（n=369）

必要で適切な情報を必要なタイミングで取り出せる

40

16.8
32.3

3.8

5.7
6.6

1.9

7.3

32.8

17.9

5.7

■あまり重要ではない■重要ではない2.4

DX白書2021 225

開発手法・技術活用」を実現する機能が求められる。
図表41-15は、
このようなビジネスニーズ対応のためにITシステム｜第 ４ 部｜第 １ 章｜（1）ITシステムに求められる機能

図表41-16は、前述のビジネスニーズに対応するためにITシステムに求められる機能について、各社の「達成度」を尋ねたものである。
日本企業を見ると、前設問の「重要である」「まあまあ重要である」の合計値に対し、「達成している」「まあまあ達成している」の合計値は、
多くの項目で半分以下であるが、「プ
ライバシーの強化」は約6割、「場所に依存せず業務を遂行できるリモートワーク」は約7割と比較的高い。米国企業を見ると、「達成度」は「重要度」より低いものの差は小さく、重要視する機能を着実に実現していることがうかがえる。
図表41-16

ビジネスニーズに対応するためにITシステムに求められる機能（達成度）
0

変化に応じ迅速かつ安全にITシステムを更新できる

20

日本（n=533） 3.6

20.1

日本（n=533） 3.2

18.0

米国（n=369）26.8

構造が柔軟で外部の有用なサービスと連携して活用できる

日本（n=533） 1.9 15.4

部門間で標準化したデータ分析基盤

取引先など、社外
パートナーとの信頼性の高いデータ連携

プライバシーの強化

226 DX白書2021

30.6

23.8

米国（n=369）

28.2

39.3

32.5
42.2

44.4

31.7

米国（n=369）

5.7 5.1

19.5

14.3

19.5

9.5

21.6

18.2

26.6

8.7

18.0

34.4

14.5

14.6

22.8

45.0

32.2

（％）
100

80

22.5

43.0

日本（n=533） 3.2

4.9

6.2

12.8

22.2

9.8

21.6

16.2

5.4

22.8

7.0 6.2

日本（n=533） 3.9

17.4

44.1

17.8

16.7

米国（n=369）

27.1

35.2

22.8

10.0 4.9

日本（n=533） 6.8
米国（n=369）

場所に依存せず業務を遂行できるリモートワーク

39.2

26.0

米国（n=369）

日本（n=532） 3.4

60

35.8

米国（n=369）

小さなサービスから始め、価値を確かめながら拡張
していくことができる

必要で適切な情報を必要なタイミングで取り出せる

40

28.9
33.6

日本（n=533） 7.1
米国（n=369）

42.0
34.4

30.6
33.3

34.9
34.4

■達成している■まあまあ達成している■あまり達成していない■達成していない

11.8

10.5

22.8

5.4 3.8

13.7

13.7

18.4

8.9

■どちらとも言えない

4.9

図表41-17は、ITシステムの開発手法・技術の活用状況である。
米国企業は「全社的に活用している」「事業部で活用している」の割合が日本企業より大幅に高い。
とくに「人間中心デザイン（UI/UX）」
は「全
勢がうかがえる。
図表41-17

ITシステムの開発手法・技術の活用状況
0

人間中心デザイン（UI/UX）
リーンスタートアップ

デザイン思考アジャイル開発

ノーコード/ローコード

DevOpsDevSecOps

CI/CD
マイクロサービス/API
プライベートクラウド

パブリッククラウド

ハイブリッドクラウド

SaaS

クラウドセキュリティ

クラウド認証コンテナ/コンテナ
運用自動化

20

米国（n=369）

20.6

日本（n=532）4.5

10.2

26.6

日本（n=534）4.3

15.0

米国（n=369）

25.2
10.9

米国（n=369）

21.7

12.0

34.8

米国（n=369）

26.6

日本（n=533） 5.1

15.0

日本（n=534）

29.3

日本（n=533） 8.3

8.4

米国（n=369）

25.2

日本（n=534） 8.2

11.6

20.4

10.7

20.2

29.3

日本（n=531）

9.4

31.4

米国（n=369）

12.9

日本（n=534）2.6 9.0
米国（n=369）

26.3

27.1
20.9

25.7

19.8
31.3
30.3

18.4
28.5

■全社的に活用している■事業部で活用している■活用していない■この手法・技術を知らない

11.4

12.7
28.5

10.3

14.9

29.4

8.9

10.3

37.8

37.6
30.9

9.8

14.9

25.3

24.7

31.4

9.2

12.7
30.6

18.2

14.4

9.5

11.1

27.9
24.7

32.0
15.5

29.4

25.1
34.9

米国（n=369）

米国（n=369）

17.6

24.1
17.8

19.1

日本（n=534）

29.0

15.7

14.4

14.9

10.8

23.3

22.0

16.9

米国（n=369）

33.6

31.5

30.9

11.9

14.4

18.4

14.8
15.9

12.2

11.7
43.9

29.3

30.9

米国（n=369）

44.9
23.0

34.3

11.8

13.9

12.5

14.6

20.3

26.6

29.0

米国（n=369）

16.3

43.8

35.2

日本（n=532）2.6 5.6

26.0

10.3

35.5
15.7

22.2
27.4

米国（n=369）

31.5
14.6

34.5
24.1

12.2

10.6

10.8

20.1

29.8

10.2

日本（n=533）2.1 7.5

33.3

25.5
31. 5

17.8

25.2

米国（n=369）

38.5

26.6

13.0

13.6

19.2

14.4

日本（n=533）4.7

日本（n=532）3.0 7.9

40.7

37.1
13.5

12.5

7.6

16.8

33.6

米国（n=369）

32.1

19.8

12.2

日本（n=533）3.2 6.8

（％）
100

80

37.4

43.4

米国（n=369）

日本（n=534）

60

12.0

11.8

日本（n=532） 6.6

40

18.4

12.5

11.9

■活用を検討している

DX白書2021 227

開発手法・技術

社的に活用している」が4割を超えており、誰もが利用しやすいITシステムの実現に全社的に取組む姿｜第 ４ 部｜第 １ 章｜

（2）開発手法・技術の活用状況

これに対して日本企業は、「この手法・技術を知らない」の割合が25.7 ～ 44.9%と、米国企業（10%前後）と比較して著しく高い。
図表は掲載していないが、日本企業に関して企業規模別で見ると従業員数が30人以下の企業において各技術について知らないと回答する割合が50%以上となっており、中小企業における技術理解の向上が望まれる。
図表41-18は図表41-17に示した手法・技術の導入目的を尋ねたものである。
開発コストやインフラ運
用コストの削減、
レガシーインフラの刷新については日本企業の回答率が高く、ソフトウェアのリリー
スサイクルの短縮、生産性や品質、保守性の向上、事業戦略と整合性の高いIT戦略の遂行、
継続的デリバリーの実現、
プロジェクトリスクの低減においては米国企業の回答率が高い。
図表41-18

ITシステムの開発手法・技術の導入目的（複数回答）
0

20
19.7

ソフトウェアのリリースサイクルの短縮

25.7

34.6

ソフトウェアの生産性の向上

46.1

32.4

ソフトウェアの品質向上

29.3

ソフトウェアの保守性向上

25.5

事業戦略と整合性の高いIT戦略の遂行
ビジネスニーズの変化に対する柔軟な対応

27.4

14.9

継続的デリバリーの実現

25.5
18.4
18.3
17.9

インフラ運用の自動化、プロセス改善8.5

アプリケーションのポータビリティ（可搬性）
レガシーインフラの刷新

1.6

6.4

9.2

11.9

34.1
33.0

24.1

開発コストの削減
インフラ運用コストの削減

49.1

40.1

24.9

12.2

プロジェクトリスクの低減

その他

（％）
60

40

36.9
31.9

19.3

■日本（n=518）■米国（n=369）

図表41-17に挙げられたクラウドやマイクロサービス／API、DevOps、CI/CDなどの技術は、図表
41-15で米国企業のトップであった「変化に応じ迅速かつ安全にITシステムを更新できる」を実現するとともに、ソフトウェアのリリースサイクルの短縮、生産性や品質、保守性の向上、
継続的デリバリーの実現にも資するものでもある。
米国企業は、ITシステムの「スピード・アジリティ」
に対する意識が高く、手法・技術の導入においてもその意識が表れていると考えられる。

228 DX白書2021

｜第 ４ 部｜第 １ 章｜

図表41-19は、ITシステムの開発手法・技術を活用する際の課題を尋ねたものである。
図表41-19

ITシステム開発手法・技術の活用課題（複数回答）
10

14.2

アジャイルな手法・技術と相容れない組織文化

20

30
22.9

変化に対する組織の抵抗

26.3
35.8

14.6

経営の理解や支援がない

28.2

スキル不足／アジャイル手法の経験ビジネスや製品の責任者が不明確

11.5

従来の開発手法から変更しなければならないこと

10.3

ツールやデータが断片化されており測定できない
チームのコラボレーションが不十分

7.1

規制順守（コンプライアンス）の問題

6.7

とくに課題はない

1.2
0.3

20.1

28.5

23.6

14.4
14.1

11.4

9.5
8.9

外部ITベンダーとの契約

38.3

26.8

24.5
22.5

トレーニングや教育が不十分

その他

30.6

13.8

ITの開発・運用プロセスにチーム全体で一貫性がない

（％）
50

40

13.3

23.7

■日本（n=253）■米国（n=369）

図表41-20に日米差を整理する。米国企業の方が割合が高い課題は「組織文化」「変化への抵抗」「経営の理解」「チームの一貫性」「従来からの変更」など、企業の文化に関連したものが多い。経済産業省
「DX
＊11
では
「DX推進の本質はレガシー企業文化からの脱却にあるという認識の下、企業が取り
レポート2」

組むべきアクションを具体的に示すことにより変革の加速を目指す」
ことを目的の一つとしているが、DX取組の遅れ（第2部第1章図表21-1 DXへの取組状況参照）
が日本企業の企業文化に関連する課題認識の低さに関係している可能性がある。
図表41-20＊ 11

ITシステムの開発手法・技術の活用課題の日米差

日米の差

ITシステムの開発手法・技術の活用課題
（選択肢）

米国が高い
（50%以上）アジャイルな手法・技術と相容れない組織文化、変化に対する組織の抵抗、経営の理解や支援がない、ITの開発・運用プロセスにチーム全体で一貫性がない、従来の開発手法から変更しなけ
ればならないこと、チームのコラボレーションが不十分、
規制順守（コンプライアンス）
の問題

米国が高い
（50%未満）

ツールやデータが断片化されており測定できない

日本が高い（50%未満）

スキル不足／アジャイル手法の経験、
トレーニングや教育が不十分
ビジネスや製品の責任者が不明確、
外部ITベンダーとの契約

日本が高い（50%以上）

とくに課題はない

 済産業省「DX レポート 2（中間取りまとめ）」
経<https://www.meti.go.jp/press/2020/12/20201228004/20201228004.html>
DX白書2021 229

開発手法・技術

0

また、
日本企業の
「とくに課題はない」の割合も米国企業と比較して高いが、日本企業は米国企業より内製の比率が低いことが要因として推定される。
今後、日本企業においても、変化への対応のため、
アジ
リティを重視するシステムの内製比率を上げるのであれば、米国企業と同様の課題への対応が必要となる可能性がある。

（3）共通プラットフォームの利用意向
経済産業省「DXレポート2」
では、今後の新たなベンダー企業像の形態の一つとして「協調領域における共通プラットフォーム提供主体」を挙げており、具体的機能として「中小企業を含めた業界ごとの協調領域を担う共通プラットフォームのサービス」などを示している。
また一般の企業に対して、「IT投資の効果を高めるために、業界内の他社と協調領域を形成して共通プラットフォーム化することも検討すべきである」との提言がされている。
今回の調査では、「共通プラットフォーム」を「企業が経営資源を競争領域に集中するため、自社の強みとは関係の薄い協調領域を業界内の他社と合意形成してプラットフォーム化することで、IT投資の効果を高める」
ものと定義しており、
図表41-21はその利用意向について聞いた結果である。
米国企業
は、7割近くが「すでに利用している」「すでに利用しており、さらに対象領域を拡大したい」
と回答して
いる。
図表41-21

共通プラットフォームの利用意向
0

日本（n=534） 5.4

米国（n=369）

20

6.4

13.5

40

80

（％）
100

38.0

2.1

60

34.6

33.1

35.0

16.8

5.7

■すでに利用している■すでに利用しており、さらに対象領域を拡大したい■利用に向けて検討している■利用してみたい■利用したいとは思わない

■その他

9.2

0.3

この結果に対して考えられる要因が二つある。一つ目は、日本では取次店などの非システム的な共通ビジネスブロックが発達しているために、プラットフォームとしての共通化に対する直接的なニーズが少ないのではないか。産業界毎に共通で利用するのが合理的な機能を個社の外に構築し利用するという考え方そのものは、たとえば出版産業における主要取次書店のように、我が国で必ずしも全く目新しい考え方であるとはいえない。ITサービスとして同種の役割を担うものとしても、
全国銀行資金決済ネットワークなどすでに稼働しているものもある。二つ目は、日本では、欧米のように業務のモジュール化が進んでおらず、それぞれの業務がすり合わせをしながら進んでいくため、共通化部分を切り出すためには業務の可視化、モジュール化が必要となる。このため、次の取組である共通プラット
フォームに問題意識がいっていないのではないか。

230 DX白書2021

システム的なビジネスブロックの共通システム化や、業務のモジュール化を行ったうえでの非競争領域の切り出しと共通プラットフォーム化は地道な活動として行っていくべきである。

｜第 ４ 部｜第 １ 章｜

いずれにしても、このことが、米国に比べて業務の生産性を低下させる要因ともなっているので、非こうした共通プラットフォームの導入は、一般的に、
コストセンターを共通化して個社の負担を抑え
ムは十分な競争環境の下で合理的な費用を実現できると考えられることから、二重の合理化効果が見込まれる。
しかしながら、
実際にこれを実装するには、業界内の各社間で、個社の事情によりどこが共通化すべきかの理解が異なったり、共通プラットフォームのビジネスモデルや負担水準の設定がしにく
かったり、
また、
短期的には自社のITシステムの改修コストがメリットを上回ってしまうことがあるな
ど、
課題はいくつもある。
現在日本においても経済産業省の主導のもと、水道事業における共通プラットフォームの推進がなされているが（図表41-22）、
これは公開された共通の接続方法等に沿った共通プラットフォームの実装を目指す事業であり、上記の考え方を実現していく先駆的プロジェクトである。もちろん、共通プラットフォームの構築のあり方はこれに限らないが、こうした考え方に鑑みても、また米国の調査結果を踏
まえても、今後、日本においても、さまざまな形で共通プラットフォームの活用が重要になるのではな
いだろうか。
図表41-22＊12
共通プラットフォーム構築によるメリット例（社会インフラ部門：水道）

共通プラットフォーム構築によるメリット
水道事業体 Ａ

水道事業体 Ｂ

水道事業体 Ｃ

利用

利用

利用

データＡ

データＢ

データＣ

共通プラットフォーム
運用コスト（プラットフォームを利用する水道事業体で分散）● データ流通の共通ルールを定め、異なる水道事業体間のデータ連係・利活用を促進● 共同利用により Ｉ Ｔ コストを割り勘、低コスト化を、
セキュリティの確保も含め実現＊ 12 「デジタル時代の新たな
IT 政策⼤綱（案）」の概要 内閣官房情報通信技術（IT）総合戦略室
令和元年 6 ⽉ <https://www.kantei.go.jp/jp/singi/it2/dai76/siryou1-1.pdf>
DX白書2021 231

開発手法・技術るだけではなく、共通の接続方法やデータの扱いが確立していくと、その部分を共通に担うITシステ

第２章

データ利活用技術
1 データ活用基盤技術（1）背景（ア）ビジネスニーズ
ITの技術革新により、
従来のビジネスモデルを変革する新規参入者が続々と登場している。
そういった激しい環境変化の中、既存業務の効率化だけでは企業の競争力を維持するのは難しく、
新
たな価値創造に企業の競争力の源泉は移りつつある。
市場や消費者の変化についていき競争力を維持するため、企業のデータの活用範囲も、自社の経営・
リスク管理や業務改善から、業務・商品・サービスの高度化やデータから新しい価値を創造することへ拡大してきている（図表42-1）。
図表42-1

データ活用範囲の拡大

データを分析してビジネスに活用することは以前から行われてきたが、昨今のデータの活用範囲の拡大の背景には、
ビジネスニーズはもとより、活用できるデータの種類が増えたことも大きい（図表422）。社内システムに格納されたデータだけでなく、設備や機器などからのIoT（Internet of Things、センサーを活用しさまざまな場所にあるモノからデータを取得するコンセプト）データや社外データといったさまざまな情報を収集・活用することができるようになった。
その結果、
社内システムのデータだけでは実現できなかったような、サービスの高度化や新たな価値創造が期待されている。

232 DX白書2021

｜第 ４ 部｜第 ２ 章｜

図表42-2

活用できるデータ種類の拡大

データ利活用技術

このようなデータ活用を実現するプラットフォームとして、必要性が高まりつつあるのが
「データ活
用基盤」
である。
データ活用基盤は、サービスの高度化や新たな価値創造の実現に向けて、社内外のさまざまなデータを収集し、分析しやすい形に整形・蓄積し、活用を行うシステム群を指す。
（イ）課題
近年のデータ活用において特徴的なのは、ビジネス環境変化に応じて、必要なデータや分析手法が頻繁に変わることである。
そこを考慮せず、
データ活用基盤として初めから完全なものを揃えようとすると、「機能不足や拡張に時間・コストがかかる」「使われない機能が実装され、投資が無駄になる」といった問題が生じる。
そうならないように用途や優先順位に応じて必要な機能を実装し、機能を順次拡張する方針やそれが可能な構造とすることが重要である。
一方、
データ活用基盤の全体像を見据えずに個別機能の構築を進めてしまうと、システムやデータの個別最適化が進み、企業全体としての最適なデータ活用が達成できない。そこで、データ活用基盤の全
体像
（1
（2）
技術概要参照）
をおさえたうえで、どのようなデータを活用したいのかというデータ構造（図
表42-3）
や、
どのようにそのデータを取り扱いたいのかという処理方式（図表42-4）の観点を踏まえ、
自社のデータ活用基盤に必要な機能や技術を取捨選択することが重要となる。
図表42-3

データ構造の種類

図表42-4処理方式の種類

DX白書2021 233

また、企業全体の最適なデータ活用に向けては、データ活用基盤の提供だけでは不十分であり、デー
タ活用を組織に浸透させ、統制をかけることも必要である。
したがって、
企業のデータ活用をサポート・推進する体制（図表42-5）や、
ルールやプロセスもあわせて整備しなくてはならない。
図表42-5234 DX白書2021

データ活用体制イメージ

本項では、
まずデータ活用基盤の全体像として、データ活用基盤に必要な機能とその機能を実現するための技術について、技術間の流れがわかるような形で示す（図表42-6）。
上で、個々の技術毎に、それぞれ概要、特徴、
ポイントに分けて紹介する。
図表42-6

データ活用基盤の全体像

図表42-7

データ活用基盤の機能概要

DX白書2021 235

データ利活用技術

そして、
その全体像に含まれる各機能の概要（図表42-7）、
および各技術の概要（図表42-8）を示す。
その｜第 ４ 部｜第 ２ 章｜

（2）技術概要

データ活用基盤の技術概要

図表42-8

機能

収
集

技術

説明

転送
・収集

データハブ
（1 (2) (ア））社内外のさまざまなシステムとデータ活用基盤を接続し、データソースやデータレイク、データウェアハウス間でのデータ送信を行うための仕組み。

保管

データレイク（1 (2) (イ））多様なデータソースからデータの加工や変換をせずに、元の形式のままデータを保存する領域。

データプリパレーション
ツール（1 (2) (ウ））

技術的なスキルを持っていない分析者やビジネスユーザー
が、簡単で迅速にデータの確認や整形を行うためのツール。

ETLツール（1 (2) (エ））さまざまなデータソースから分析を開始するために必要となる
さまざまなデータの整形をバッチで自動処理するツール。主にITエンジニアなどにおいて、処理設計・構築される。

ストリーム処理基盤（1 (2) (オ））IoT機器などから発生する大量のデータを溜めずにリアル
タイムで処理、活用するための仕組み。

データウェアハウス（1 (2) (カ））加工済みの構造化データを目的別に蓄積するための領域。複数のデータソースから集めたデータを活用して分析を行うための保存場所となる。

データカタログ（1 (2) (キ））データの意味や構造、作られ方のようなデータに付随する情報をメタデータと言い、メタデータを管理する仕組み。

BIツール

Business Intelligenceツールの略。
データプリパレーションツールやETLツールで整形されたデータを可視化し、意思決定に活用するツール。

BAツール

Business Analyticsツールの略。データプリパレーションツー
ルやETLツールで整形されたデータをインプットに分析処理を行い、統計分析や予測、最適化を行うツール。

機械学習

システムが大量の学習データをインプットに学習を繰り返すことによって、ルールやパターンを導き出し、判別や予測などを行う技術。

データ連携

集計や分析、機械学習した結果などに関する、外部企
業や外部サービスなどへの連携。

整形

蓄積

活用

（ア）データハブ（a）概要
データハブとは、
社内外のさまざまなシステムとデータ活用基盤を接続し、データソースやデータレ
イク、
データウェアハウス間でのデータ連携を行うための仕組みである。
データ活用を進めるうえで、データ活用基盤はさまざまなシステムと連携してデータを収集・提供する必要がある。このとき、場当たり的にデータの受け渡しを行う機能を構築していくと、データフ
ローが複雑化し、システムの管理が難しくなる。そのため、データ活用基盤内外のデータの受け渡しを236 DX白書2021

機能についてはETLツール（1（2）（エ）参照）などに一部含まれる場合もあるが、ここではデータ連携のための機能をデータハブと捉えて整理している。

さまざまなシステムからデータを収集するにあたり、IoT機器や、クラウド上のシステム、パッケー
ジソフト、ホストシステムなど、さまざまなシステムと接続できなければならない。接続するシステムに応じて取りうるデータ連携方式は異なるため、データハブは、必要なデータ連携方式を備える必要がある。
主なデータ連携方式を図表42-9に示す。
図表42-9

主なデータ連携方式概要

データ連携方式

概要説明

API連携

外部とデータを連携するアプリケーションにより、データを連携する方式。
ゲートウェイ機能により、
アクセス制御等のセキュリティが確保される。

ファイル連携ファイルの受け渡しによってデータを連携する方式。データを一括して転送するバッチ処理によって転送される。FTPやSCP等のプロトコルが利用される。

メッセージ連携

メッセージ単位でデータを連携する方式。送信データは受信者が取りだすまでキューと呼ばれる領域に保存される。
メッセージ指向ミドルウェア等で管理される。

DB連携

データベースに直接接続し、データを連携する方式。テーブル構造の変更により、既存の参照元の設定変更が必要になるなど、データ連携に影響が出る可能性がある。

データハブは、データの連携のみでなく、接続する機器の管理機能も備えている。IoT機器を監視して故障を検知する機能や、接続する機器やシステムの認証を行う機能、各システムからのアクセスログなどの監査証跡を取得する機能など、
データ連携を効率的・安全に行うための機能も備える。
（c）ポイント
データソースやデータを活用するシステムとデータ活用基盤は、疎結合であることが望ましい。
密に結合した構成となると、データソースのシステム改修の影響を受け、データ連携機能も改修する必要が出るなど、メンテナンスのコストが増大する原因となるためである。そのため、システム間の連携方式
は基本的にはAPI連携が採用されることが多い。データ連携の共通のインターフェースとしてAPIを定め、データの操作をAPI経由に限定することで、
データソースやデータを活用するシステムとデータ活用基盤の間を疎結合な状態に保つことが可能となる。
また、
インターフェースをAPIで統一することで、トラフィックの管理機能や認証機能などの機能を集約し、効率的な運用も可能となる。
（イ）データレイク（a）概要
データレイクとは、多様なデータソースからデータの加工や変換をせずに、元の形式のままデータを保存するデータストアである。
名前のとおり「データの湖」
として、あらゆるデータを蓄積するためのストレージという位置づけである。データ活用基盤で扱うデータは、一度データレイクに集約され、目的に応じて各システムが必要なデータを取り出して加工・変換して活用する流れ（図表42-10）となる。
DX白書2021 237

データ利活用技術（b）特徴｜第 ４ 部｜第 ２ 章｜

一元管理し、
インターフェースを削減・統一するためにデータハブが必要とされている。
データハブの

図表42-10

データレイクの活用イメージ（b）特徴
データレイクでは、行と列で構成された構造化データに加え、画像や動画、音声などの非構造化デー
タも取り扱うことが大きな特徴である。すべてのデータをそのままの形式で保存できるため、データを事前に構造化する必要がない。
膨大なデータを扱う場合、必要なデータを事前に選別することは難しい。
将来的に必要となる可能性があるデータを保管するためにも、データレイクの必要性が高まっている。
また、年々扱うデータ種別やデータボリュームが増え続けるため、データレイクは膨大なデータを蓄積することが求められる。一般的に、オンプレミスで同様の仕組みを実現する場合、実現のコストが高額となることが多い。
そのため、クラウドベンダーが提供するオブジェクトストレージサービスを活用
して、データレイクを構成することが多い。同サービスを活用することで、多様なデータを元の形式のまま、安価に保管することが可能となる。データソース側で適切にデータが管理されている場合や、リアルタイムでデータを分析したい場合は、データレイクに保管せずに各システムに直接連携する構成を取るなど、
データレイクに保管するデータ量を減らす考慮も重要となる。
（c）ポイント
データレイクには、生データがそのまま蓄積されるため、機密性の高いデータが含まれることが多い。
そのため、データの暗号化やデータレイクへのアクセス制限、
監査証跡の取得など、
セキュリティ面の考慮が必要である。
また、
データレイクには膨大なデータが蓄積されることになるため、蓄積されているデータやその来歴等の情報を利用者にわかるように共有することも重要となる。どこにどのようなデータが蓄積されているのかが共有されなければ、利用されないデータが蓄積されるだけになってしまう。
データカタロ
グ
（1
（2）
（キ）
参照）
を利用し、
蓄積されているデータの情報を共有することが重要となる。
238 DX白書2021

（a）概要
データプリパレーションは、
直訳するとデータの準備であり、分析に必要な形にデータを整形するこ｜第 ４ 部｜第 ２ 章｜（ウ）データプリパレーションツール

とを指す。
データプリパレーションツールとは、プログラミングやデータベース操作といった技術的なツールとなる。
データ分析・活用の民主化（一部の技術者だけがデータ分析・活用するのではなく、非技術者なども
データ分析・活用を行う状況が望ましいとする原則）を目指す企業が増える中、データプリパレーショ
ンツールはビジネス部門におけるデータ活用を促進できる技術として注目を集めている。
（b）特徴
データプリパレーションツールは、分析者やビジネスユーザーが、データの分布を把握し、試行錯誤を繰り返しながらデータの整形仕様を決めていくという使い方を想定している。
そのため、
データの中
身を確認するための機能があり、またスクリプトを書くことなく、整形処理をUIで簡易に作りこむことができる。
図表42-11

データプリパレーションツールの主な機能

機能名

説明

データ接続

データベースやファイルに接続し、目的のデータを取得する機能。

データ確認

取得したデータの分布や、整形処理前後のデータを確認する機能。

データ整形

欠損データの補完や、表記ゆれの修正、データの分割、重複データや外れ値データの削除などといったデータを整形する機能。
ツールにより整形パターンは限られる。

データ結合

指定する条件のもと、複数のデータを結合する機能。

なお、バッチでの整形処理を担うツールとしては、ETLツールも存在する。ETLツールとは、利用者や用途が以下のように異なる（各ツールの機能詳細については、
本ページと1
（2）
（エ）
を参照）
。
図表42-12

データプリパレーションツールとETLツールの比較

観点

データプリパレーションツール

ETLツール

利用者

分析者、
ビジネスユーザー
ITエンジニア（プログラミングやデータベース操作といった技術的 （プログラミングやデータベース操作といった技術的なスキルは必要でない）
なスキルが必要）

用途

データの分布を把握し、試行錯誤を繰り返しながらデータ加工の仕様を決めていく。
決めた仕様に沿ってデータを整形する。

定義されたシステム処理のワークフローやスクリプ
トに沿って定期的に自動でデータを整形し、データ
ウェアハウスへ格納する。

（c）ポイント
ユーザーが非技術者であるデータ分析者、
ビジネスユーザーになるため、簡単に使いこなせるようになっているか、
わかりやすいドキュメントやナレッジが充実しているかといった習得性や、機能の充実
度や手入力の少なさなどといった生産性が重要なポイントとなる。
DX白書2021 239

データ利活用技術

スキルを持っていない分析者やビジネスユーザーが、簡単で迅速にデータの確認や整形を行うための（エ）ETLツール
（a）概要
ETLは、
Extract（抽出）、Transform（変換）、Load（格納）の略である。ETLツールはさまざまなデー
タソースからデータを抽出したうえで、分析や活用しやすい形へ整形し、データウェアハウスなどへ格納するという一連の処理を、人手を介さずバッチで定期的に自動処理させるためのツールとなる。
（b）特徴
ETLツールは、ITエンジニアが、データ分析者やビジネスユーザーなどからのデータ整形要件に沿って、ETL開発画面上で処理の流れや整形内容などに関するワークフローやスクリプトを作成し、その内容に沿ってデータを整形することを想定している。
そのため、データ整形要件や仕様自体を定めるためのデータの確認の機能はとくにない。
一方、整形処理については、
スクリプトを作成するなどにより、きめ細かなデータ整形要件への対応が可能となっている。
図表42-13ETLツールの主な機能

機能名

説明

データ接続

データベースやファイルに接続し、目的のデータを取得する機能。

データ整形

欠損データの補完や、表記ゆれの修正、データの分割、重複データや外れ値データの削除などといったデータを整形する機能。
スクリプトの記述などにより、きめ細かな整形処理を行うことが可能。

データ結合

指定する条件のもと、複数のデータを結合する機能。

データ格納

整形、
結合したデータをデータウェアハウスへ格納する機能。

ETLツールでは、ワークフローを可視化しながら処理を作りこめる開発画面などが用意されていることから、自前で整形処理を開発することと比較して、
開発工数・期間の削減が期待できる。
また、開発
した処理は自動で定期実行されることから、人為的なミスによるデータ品質の低下を防ぐことができる。
ただし、ETLツールを使用するためには、プログラミングやデータベース操作といった技術的なスキルが要求されるため、基本的にはITエンジニアが開発することになる。そのため、データプリパレー
ションツールと比較すると、データ分析者やビジネスユーザーが整形データを利用できるまでには時間がかかる。
（c）ポイント
大量のデータを限られた時間内で処理することが必要になることから、データ活用ニーズを満たせるよう十分な処理性能を確保すること、
将来的な拡張も可能であることを確認しておく必要がある。
整形処理のタイミングとしては、一般的には日中発生したデータを夜間まとめて処理することが多く、
処理タイミングに偏りが発生しやすい。
そのため、処理のスケジュールを工夫する必要もある。
また、
データ活用範囲が拡がるにつれてデータの追加や変更などが入るため、管理しきれずデータ品質が確保できないようにならないよう、管理性や保守性が高いことも重要なポイントとなる。

240 DX白書2021

（a）概要ストリーム処理基盤とは、WebサイトやIoT機器などから絶えず発生するデータをリアルタイムで｜第 ４ 部｜第 ２ 章｜（オ）ストリーム処理基盤

処理するための仕組みとなる。
リアルタイムで処理した結果は、データウェアハウスへ格納して活用し従来は大量のまとまったデータをバッチで定期的に処理することが多かったが、よりリアルタイム
でのデータ活用ニーズが増えてきていることや、大容量のデータをすべて蓄積していてはコスト効果が見合わないなどの理由からストリーム処理基盤のニーズが高まっている。
前者は、たとえばWebサイト上のユーザー行動をリアルタイムで捉えてのレコメンデーションや、
IoTデータからのリアルタイムでのダッシュボード表示や異常検知などが挙げられる。
後者は、
たとえば映像データそのものではなく特定の物体検出の結果のみ保存することや、特定のイベントが発生した時刻の映像データのみ保存するなどが挙げられる。
（b）特徴
大量の保管データを溜め込み定期的に処理するバッチ処理と比較して、データを溜めずに発生するデータを随時、
短時間で処理するのがストリーム処理の特徴である。
バッチで処理を行うデータプリパ
レーションツールやETLツールでは、データを活用しやすい形へ整形したうえで活用することが中心であったが、ストリーム処理基盤では、リアルタイムでの集計や判定を行い、集計や判定結果をそのま
まデータアプリなどで活用し、不要なデータは破棄する。
ストリーム処理には、画像データの物体検出などといった一つのデータ毎に処理するだけでよい場
合もあれば、IoT機器からのデータが一定時間内でしきい値を超えるなど複数のデータをまとめて集計・判定が必要となる場合もある。
後者は時系列を意識した処理を行う必要があり、ウィンドウ集計と呼ばれる。
図表42-14

ストリーム処理とバッチ処理の比較

観点

ストリーム処理

バッチ処理

処理対象

随時発生するデータ（フローデータ）

大量の保管データ（ストックデータ）処理タイミング

随時

定期
（日次、
月次など）

処理時間

数ミリ秒～数秒

数分～数時間（c）ポイント
リアルタイム性が求められることから、データ処理性能が十分であることや、
データ活用範囲が拡がることに備えて、
将来的な拡張も可能であることを確認しておく必要がある。
また、ストリーム処理はバッチ処理と比較して、開発や運用の難易度が高くなる。とくにウィンドウ
集計が必要な場合、集計期間をどの程度の時間とするのか、遅延して到着したデータの扱いをどうするのかなど、さまざまな考慮をする必要がある。製品選定の際には、意図した処理が実現できるか確認しておく必要がある。

DX白書2021 241

データ利活用技術たり、そのまま機械学習やデータアプリで活用したりする。

（カ）データウェアハウス（a）概要
データウェアハウスも、
データレイクと同様に、さまざまなデータを統合し蓄積するための技術であるが、その位置づけは異なる。
データウェアハウスは、加工済みの構造化データを目的別に蓄積するためのデータストアである。
「データの倉庫」という名前のとおり、複数のデータソースから集めたデータを整理して保管し、活用・分析を行うための領域となる。データウェアハウスには目的に応じて加工されたデータが蓄積されるため、蓄積されているデータを取り出すことで、意思決定のためのレポーティングや機械学習等を利用した分析にそのまま活用することができる。
データレイクとデータウェアハウスは、
どちらか一方のみしか利用しないというものではなく、用途に応じて使い分けられるものである。データレイクには生データを、データウェアハウスには目的別の加工データを保存するという共存関係になる。
（b）特徴
従来の技術に、データベースが存在するが、データウェアハウスもデータベースの一種に位置付けられる。ただし、汎用的なデータベースとは異なり、膨大なデータの分析に特化した仕組みになっている
ところが大きな特徴である。
主なデータストアの特徴を図表42-15に示す。
データベースの場合、扱うデータ量が増加し容量の上限を超えると、明細データを集計したサマリの形式に変換する必要が出てくる。
ストレージ容量の大きいデータウェアハウスでは、長期間の明細デー
タを時系列に保管することが可能であり、過去の履歴を含めた詳細な情報を分析・活用することが可能となる。
また、データベースとデータウェアハウスでは、データの処理方式においても異なる特徴を持つ。
データベースはテーブルの列全体を読み込んで処理を行うが、データウェアハウスは必要な列のみを選択して処理を行う。
大量のデータを処理する場合、必要な列のみを読み込んで処理を行うデータウェ
アハウスの方が、高速に分析を行える。
データウェアハウスは、
オンプレミスの分散処理基盤を利用した構築や、
近年ではクラウドベンダーが提供するマネージドサービスを利用し、容易に構築・運用することが可能となっている。
図表42-15

データストアの特徴比較
データレイク

データウェアハウス

汎用的なデータベース

データ形式

構造化・非構造化データ

構造化データ

保管するデータ

用途未確定含む生データ

用途が明確な加工済みデータ扱えるデータ量

極大大小（c）ポイント
データウェアハウスにデータを格納する際、ETLツール（1（2）（エ）参照）を利用し、欠損データの補
完や修正、削除によりデータの品質を高め、正規化により異なるデータを特定のキー情報により結合する必要がある。
蓄積するデータのアセスメントを行い、データ整形のフローや蓄積方法の設計を事前に行うことで、品質の高いデータを管理することが可能となる。
242 DX白書2021

行うことが重要となる。

｜第 ４ 部｜第 ２ 章｜

また、データレイクと同様に、データカタログ（1（2）（キ）参照）を利用して、蓄積データの情報共有を（キ）データカタログ
データの値そのものではなく、そのデータの意味や構造、特性などといった、データに関する付随情報をメタデータと言う。そのメタデータを登録・管理し、データ利用者に公開する仕組みを、データカ
タログという。
データの意味や構造などを知らなければ、正しいデータ活用・分析はできず、
誤った意思決定などに繋がりかねない。
データ分析・活用の民主化を目指す企業が増える中、データカタログはビジネス部門も含めた企業
全体のデータ活用を促進し、その品質を確保する技術として注目を集めている。
図表42-16

主要なメタデータ

メタデータ名説明

データ意味

データのビジネス・業務上の意味

データ構造

データの形式（データベースの場合、
テーブル名や列名、データ型など）データリネージ

インプットとなるデータソースや、データの活用先

データ鮮度

データの生成タイミング

データオーナーデータを生成、管理する部署や担当者（b）特徴データカタログでは、
大きくメタデータを登録・管理する機能と検索・参照する機能がある。
データカタログの導入により、メタデータの自動収集や一元管理といったメタデータ登録・管理負荷の軽減や、さまざまな切り口でメタデータの検索・参照が可能となる。
図表42-17

データカタログの主な機能

機能名

説明

メタデータ登録・管理

メタデータを登録・管理する機能。
ツールによって、
データ構造やデータリネージなど一部のメタデータを自動的に登録・最新化してくれるものや、項目名などからAI技術などにより自動的にメタデータ候補を提示してくれるものもある。

メタデータ検索・参照

データ活用・分析に必要なデータが存在するかどうかや、そのデータを活用するにあたって把握しておくべきメタデータを検索・参照する機能。

（c）ポイント
古いメタデータを参照することでの誤ったデータ分析や、登録されたメタデータが信頼できず活用されないようなことにならないよう、
メタデータをいかに最新化し続けられるかがポイントとなる。
そのためには、
自動で登録・最新化できるメタデータは自動化し、自動化できないメタデータについては

DX白書2021 243

データ利活用技術（a）概要

登録・最新化するためのプロセスや体制を整備しておくことが必要である。
自動化できないメタデータの登録・最新化はそれなりの負荷がかかる。一気にすべてのメタデータを整備するのではなくニーズの高いメタデータから順次整備することや、初期登録は有識者が行い最新化は有識者とデータ分析者で分担して最新化するといった工夫を行い、無理なくメタデータ品質を確保することが重要となる。

（3）導入プロセス、事例（ア）導入プロセス概要
データ活用基盤の導入を検討する際、まずはデータアーキテクチャーを定義することが重要である。
データアーキテクチャーは、ビジネスの中心となるコアデータと、
コアデータを中心に構成されるデー
タモデル、
そして、
データモデルで表現されるデータを活用するためのデータ活用基盤の三つの要素からなる（図表42-18）。
コアデータとは、ビジネスで活用するさまざまなデータの中心に位置づけられるデータであり、コアデータを中心に各データがつながる。
ビジネス目標の達成に向け、データから価値創造を行うために必要不可欠なデータとして定義される。
データモデルとは、データの構造や関係性を整理した概念図である。コアデータを中心に、ビジネスで活用するデータ間の関係が表現される。
データモデルを整理・共有することで、データの関係性の共通理解を持つことが可能となる。
データ活用基盤とは、ビジネスに必要なデータを収集、蓄積して活用するためのプラットフォームである。
定義したデータモデルに則した、活用可能なデータを整備するために必要不可欠な要素となる。
図表42-18

データアーキテクチャーの概要

データアーキテクチャーはデータ活用を進める中で、継続的に見直しを行うことが重要である。
コア
データが変われば、
データモデルも変わり、必要な基盤の要件も変化する。
ビジネスの変化に合わせて、
データアーキテクチャーを柔軟に対応させていくことが重要である。データアーキテクチャーを考慮
244 DX白書2021

して、データ活用基盤が整理されなければならない。
コアデータは、自社のビジネスやサービスに必要なデータを整理したうえで、
価値創造に必要なデー｜第 ４ 部｜第 ２ 章｜せずにデータ活用基盤だけ構築しても、データ活用は進まない。
コアデータとデータモデルをベースとタを見極め定義する。
たとえば、さまざまな商品を扱う小売業の場合、ビジネスで扱うデータは、商品やは顧客となる。定義したコアデータを中心に、それぞれのデータの関係性を整理することで、データモ
デルが構成される（図表42-19）。
このデータモデルに則したデータを扱う基盤を構築することで、顧客の行動を捉え、
顧客理解を深めることが可能となる。
図表42-19

コアデータとデータモデルイメージ

データ活用基盤の構築は、スモールスタートのアプローチが望ましい。データ活用は試行錯誤を伴い、基盤に求められる要件も変化するためである。そのため、とくにこれからデータ活用に取組む企業
においては、最初から完璧なデータ活用基盤を構築するのではなく、必要な機能に絞って素早く構築し、徐々に拡張していくアプローチが適している。
たとえば、まずは社内の既存システムのデータを収集・蓄積し、構造化データの活用が行える基本的な環境を整える。次に、データ分析が社内に浸透してきたタイミングで、社内ユーザーが独自で分析するための機能を強化する。さらに、IoT機器の導入が進んできたタイミングで、ストリーミング処理や非構造化データを活用する機能を強化するなど、必要に応じて順次拡張していく進め方となる（図表4220）。
ただし、社内外の多様なシステムと接続しデータを連携する中で、個別機能にのみ目を向けて構築を進めると、データフローが複雑化し、運用コストの増大やシステムの拡張性が確保できないなどの問題が発生する可能性がある。そのため、まずはデータ活用基盤の全体像を検討したうえで、小さく始める
アプローチを取ることが多い。

DX白書2021 245

データ利活用技術

店舗、顧客、購買履歴などが考えられる。その際、顧客視点に立って価値創造を進める場合、コアデータ

図表42-20

データ活用基盤拡張イメージ（イ）データ活用基盤の検討プロセス
データ活用基盤の構築は、データ活用要件を定め、システム全体像を整理し、システム構築の全体プ
ランを整理して進めていく。
このとき、現行システムの状況や、技術動向・事例を踏まえて、検討を進めることが望ましい。
検討の進め方を、
以下の五つのタスクで整理する（図表42-21）。
図表42-21

データ活用基盤の検討プロセス（a）データ活用要件の整理
自社におけるデータ活用の目的や方針を整理し、具体的な活用用途から必要となるデータを整理する。
既存システムが保有するデータ資産の棚卸を行い、データ分析に活用するデータの選定やデータの特性を整理する。また、データ分析施策やデータを活用した新サービスを検討し、データ活用の要件を具体化する。
それらの整理・検討結果を踏まえ、データ活用基盤で扱うデータの範囲やデータのライフサイクル、
セキュリティ要件などの満たすべき要件を整理する。
また、今後必要となるデータボリュームについても整理を行い、
費用試算のインプットとする。

246 DX白書2021

自社の現行システムや現状の課題、活用できるリソース、データソースとなりうるシステムを整理し、データ活用基盤と連携またはデータ活用基盤の一部として活用する既存システムの範囲を整理｜第 ４ 部｜第 ２ 章｜（b）現行システム整理する。これらの整理結果は、データ活用基盤の全体像やロードマップ策定のインプットとなる。データ
ステムの改修計画を踏まえ、データ活用基盤構築スケジュールの検討を行う。
（c）技術動向調査
必要に応じて、直近の技術トレンドやデータ活用事例を調査し、データ活用基盤検討に取り込むべき
示唆を抽出していく。
トレンドに沿った技術を活用することで、コストを抑えて長期にわたって活用できるプラットフォームを構成していくことが重要となる。
レガシーな技術の活用を続けると、システムの運用に必要な人材の枯渇や提供サービスの終了に伴う大規模なシステム刷新が必要となり、コストが必要以上にかかってしまう。技術領域の変化のスピードは速いため、随時トレンドを調査し、情報をアップデートすることが望ましい。
また、近年、オープンデータや購入可能なデータなど、外部のデータを取り入れて活用できるサービスが出てきている。社外のデータソースの活用も視野に入れ、外部環境の調査を行うことが重要となる。
（d）システム全体像整理
ここまでの検討結果を踏まえ、システム化の方針やシステム全体構成を検討する。
処理パターン別の機能要素や非機能の方針を定め、データ活用基盤に求める要件を具体化していく。
管理するデータの種
別や処理方式に基づき、データフローの定義や必要なデータストアの選定を行う。また、自社の組織構造を考慮して、データ活用基盤の運用方針を定める。それらの各種要件を踏まえて、データ活用基盤の全体構成イメージを描いていく。
（e）全体プラン策定
データ活用要件に基づき、各機能要素構築の優先順位を整理する。機能構築・データ活用のロード
マップを定め、各スコープの概算コスト算出やリスク・課題の整理を行う。
スモールスタートで迅速に構築を進めるために、優先順位に基づいて、構築の計画を検討することが重要となる。
これら五つのタスクにより、データ活用基盤の構築計画を定め、計画に沿って順次構築をすすめていく。
ただし、前述のとおり、
ビジネスの状況やデータ活用ニーズに合わせて、データ活用基盤の機能の見直しを図っていく必要がある。整理した計画をベースに、要件や全体像をアップデートし、柔軟に拡張
していくことが求められる。
（ウ）データ活用基盤導入事例
データ活用基盤はさまざまな企業で検討・導入が進んでいるが、ここでは全日本空輸株式会社

DX白書2021 247

データ利活用技術

ソースとなるシステムを踏まえ、データ活用基盤として備えるべきインターフェースを検討し、既存シ

（ANA）の事例を紹介する＊13。
ANAでは、これまでもデータ活用基盤を利用したデータ活用に取組んでいたが、システムの複雑化による運用負荷増大に対応するために、データ活用基盤の刷新を行っている。従来の基盤は、オンプレ
ミス環境で運用されており、度重なる追加開発によるシステムの複雑化や、増え続けるデータを保存するディスク容量の逼迫、データ処理の長時間化、運用業務の負荷増大という課題を抱えていた。新たな分析データの追加にもデータ容量に限界があるため容易に対応できず、システム運用を担うIT部門も機能の追加開発やディスクの増設対応に大きな負荷がかかっている状況であった。
データの戦略的な活用のためには、
柔軟性と拡張性を備えた基盤が必要と考え、
パブリッククラウドを活用してデータ活用基盤を再構築する決断に至った。クラウドベンダーが提供するオブジェクトス
トレージサービスやデータウェアハウスのマネージドサービスを利用し、1年ほどの期間をかけて環境を構築、システムテストやデータ移行を経て本稼働を開始した。
国内線・国際線の予約・発券・搭乗データや航空機の運航実績などのデータが蓄積されており、経営企画やマーケティングなどの部門にて、外部データと組み合わせた分析やレポート作成に活用されている。
データ処理のパフォーマンスの向上や、機器調達のリードタイムの短縮などにより、従来抱えていたデータの活用や運用における課題の解決を実現している。
データ活用基盤は、データボリュームの増大や機能の追加に柔軟に対応できる拡張性を備えていることが重要となる。ANAの事例のように、長年使い続ける中で、システム面での課題が顕在化し、思う様にデータ活用を進められなくなってくるというケースも少なくない。
構築して終わりではなく、
ニーズの変化や利用量の増加に素早く対応していかなければならない。

（4）まとめ
本節では、企業のデータ利活用を支えるプラットフォームであるデータ活用基盤の概要と、
データ活用基盤の技術要素、
導入プロセスについて紹介した。
データ活用基盤は、企業を取り巻くさまざまなシステムと接続し、データを収集・蓄積・活用するための機能を備える。
データ構造や処理方式に応じて必要な機能を取捨選択して構成し、データの活用をより効率的に行うために、データカタログやデータプリパレーションツールなどの社内ユーザー自身が分析を行うための機能も提供する。
導入プロセスについては、ビジネスの目的を踏まえてコアデー
タ、データモデル、データ活用基盤からなるデータアーキテクチャーを定義したうえで、スモールス
タートで導入していくアプローチが適していることを紹介した。
データ活用基盤で扱うデータは、今後よりいっそう増加していくと考えられる。IoTの導入が進み、さまざまな機器にセンサーが埋め込まれることで、あらゆる情報を扱うことができるようになる。また、企業間のコラボレーションが進み、データの連携もさらに増えていく。膨大なデータや非構造化データを扱うAIを活用するニーズもより大きくなる。
これに伴い、
膨大なデータから効果的に価値を創出していくことが求められ、データ活用の巧拙がビジネスの成長をより大きく左右する時代になると考えられる。
その際も、データ活用を考える際に、データアーキテクチャーが中心となる点は変わらない。データ＊ 13https://aws.amazon.com/jp/solutions/case-studies/ana/

248 DX白書2021

出することはよりいっそう難しくなる。
とりあえずすべてのデータを集めるだけでは、
データ活用で効果を上げることは難しい。プラットフォームにのみ目を向けるのではなく、ビジネスを捉え、コアデー｜第 ４ 部｜第 ２ 章｜

量が増えると、データの管理はより複雑化し、データの品質が悪化すると、データから新たな価値を創

タやデータモデルを含めたデータアーキテクチャーを確立することが、新たな価値創造につながる。
から小さく始めて、自社に適したプラットフォームに育てていくことが重要であると述べてきた。
将来
像・全体像を見据え、まず効果が出そうな特定の領域で小さな環境を作り、効果が得られたら段階的に規模を拡大していく「Think Big, Start Small」のアプローチでデータ活用を進めていくことが望ましい。

2 AI技術（1）はじめに
本節では、さまざまな人工知能（AI）
技術が浸透しつつある現状を技術の進展と社会実装の視点から俯瞰する。2020-2021年は、「現実の物理世界の中でどのようにAIと関わるべきなのか？」「人間とAIによって実現するエコシステムとは？」、といった議論が本格化した年である。これは新型コロナウイル
ス感染症（COVID-19）の影響が少なくはないものの、本質的には、これまで情報世界（デジタル）で活躍してきたAIが物理世界（リアル）で利用されることで、一部にとどまっていた社会実装が進むことへの期待と、本格的な社会実装に取組み始めたことで生じた課題意識によるものではないだろうか。
AIを活用することで企業がビジネス環境の急激な変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基にプロダクトやサービス、ビジネスモデルを変革する機運が高まっている。
もちろん、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること＊14、Moderna（米にも適用できる。たとえば、いち早くCOVID-19用のワクチンを開発したPfizer（米国）＊15の両社では、AIの活用が早期の開発、臨床試験、実用化に結び付いた＊16。
国）

目の前の変革の一つの切り口として、デジタルとリアルの視点で現在の社会を捉えなおすことが挙げられる。このデジタルとリアルという言葉は目新しいものではない。これまで、どちらかといえば両者は分離され、先進的な企業のみがこれらをシームレスにつなげていたが、AIによってどのような企業であってもデジタル・リアルの垣根を越えてイノベーティブに仕事を進めることが重要になる。
mRNAベースのワクチンがデジタル（情報-mRNA）とリアル（物理-抗体）を図らずもつないだことは偶然以上の意味があると考えるべきである。
一方で、ほとんどの企業が直面している課題はリアルのものであり、データはその一面を捉えているにすぎない。そのような課題をデジタルのデータのみで解決することが可能とは思えないのではないだろうか。ではAIはどのようにしてリアルの課題を解決しているのであろうか。ネット小売りの雄であるAmazon Goの事例は今やだれもが知っている。
しかし、
近年、実店舗を主軸としているWalmart（米国）
が似て非なるAI技術の応用によってCOVID-19の影響下においても増益となるという快挙を報告し

＊ 14
＊ 15
＊ 16

https://www.outsourcing-pharma.com/Article/2020/03/09/Pfizer-Saama-team-up-on-AI-data-projecthttps://www.zdnet.com/article/moderna-leveraging-its-ai-factory-to-revolutionise-the-way-diseases-are-treated/
FDA が緊急使用の承認。FDA による Pfyzer の mRNA ワクチンの正式承認は 2021/8/23。
DX白書2021 249

データ利活用技術

本節では、完璧なプラットフォームを求めて製品やツールに目を向けるのではなく、できるところ

＊18ている＊17。
まずはWalmartの自社の強みを最大限生かす取組であるIRL（Intelligent Retail Lab）
を例にAI技術の導入例を紹介する。Walmartは人的リソースとAI技術の両者を生かすことでリアルの環境とデジタルデータの融合による顧客体験の向上を図っている。
本事例は、
デジタルデータを活用してリアル環境の課題を解決する優れた事例と言えるのではないか。
Walmart IRL
Walmartは2019年4月25日にAIを実店舗に展開するためにWalmart IRLの実験的店舗をニューヨー
ク州レビットタウンでオープンした。在庫管理に主軸を置いているWalmart IRLでは米国内の4,700店
舗に10万種類以上の商品を取り揃えている。
実店舗に実際にこれだけの品物が並んでおり、顧客が直接商品を選ぶという環境は根本的にAmazonとは異なる。では、WalmartはどのようにAIを取り入れたのか。Walmart Labのデータサイエンス・チームは、商品の動きに焦点を当てた。
店舗別の組み合わせで毎週5億アイテムの需要予測をAIで行うことにしたのである。
Walmart IRLでは、多数のカメラを使用することで死角のないデータ取得を行っている。
カメラは顧客の行動ではなく、棚に並ぶ製品に焦点をあてることで在庫管理と需要予測につなげる。
たとえば一袋のポテトチップ。
棚の位置から製品が特定できる可能性は高いものの、顧客が間違った場所に返しているかもしれない。あるいは、袋の変形で製品が特定できないかもしれない。これらの問題をカメラ・センサー群とAI技術により解決するのである。
刻々とかわる状況のもと今現在、棚に並んでいる製品を把握することで在庫管理と需要予測を行う。
レジを利用すれば十分ではないかという疑問も生じるであろう。
しかし、Walmartは、在庫管理とは店頭での陳列までを含むものと捉えており、常に店頭に商品を並べ続けることを重要視している。
顧客が商品を手に取り、カートに入れた瞬間、陳列棚の空きを埋める作業が開始され、その結果を需要予測につなげる。
このような在庫管理・需要予測の視点は実店舗ならではのオペレーションでありAmazonにはない。
しかもWalmartがIRLで取組んだのは生鮮食品、日用品に特化したネイバーフッド・マーケッ
トの一つで、取り扱うアイテムは3万点である。鮮度が重要視される食品は時間単位での管理が必要であり、また欠品が直接店の利益に影響する。
通常のWalmartでは売り場スタッフが担当の棚を常に回ってアイテムの確認を監視、補充のタイミングを見極めている。生鮮食品は実物を見ることが重要であ
り、データのみで管理することは非常に難しい。生鮮食品は補充だけではなく、見た目の鮮度により撤去を行うことも必要であるからである。
そこで死角のないカメラと画像解析を行うAIの登場となる（図
表42-22）。
AIには毎秒1.6TBで取得されるデータが使用される。そのためデータは有線・ローカルで処理する必要があり、
データセンターを店舗建屋内に設置している。
このデータセンターは意図的に外から見える位置にあるため顧客はAIを物理的に認識できる。AIを身近に感じてもらうことで顧客の理解を得ることも可能となる。
最終的にはデータの活用によって、AIを導入した店舗では、
朝、売り場のドアが開く前に補充のタイミングと量を知ることができるようになるという。
では、食品・製品の補充のための見回りが必要なくなった店員は何を行うのか。Walmartでは、皆が口をそろえて言う、「よりきめ細やかな接客です」。
WalmartのAIはNVIDIA GPU上でCUDA-X AIを利用して構築、導入された。
導入前の汎用クラスタ
＊ 17
＊ 18

https://s2.q4cdn.com/056532643/files/doc_financials/2022/q2/Earnings-Presentation-(FY22-Q2).pdf
https://corporate.walmart.com/IRL/

250 DX白書2021

向上し、製品の迅速な納品、
リアルタイムでの対応や在庫コスト削減に期待を持てる状況にある。
WalmartはCOVID-19の吹き荒れるなか好調な業績を示している。ここで紹介したIRLは実験的な店｜第 ４ 部｜第 ２ 章｜に比べ100倍に高速化し、機械学習アルゴリズムは20倍速にまでにもなった。
その結果、需要予測精度が舗であるため、
この店舗で収益を確保することにはならない。Walmartは、AI技術を活用し、トラック
1,800店舗で採用される予定とのことである。
パートナーであるロボットベンチャー企業のBossa Nova
Robotics（米国）のロボットを使って床の清掃や棚の補充を行っており、カメラを使ってセルフチェック
アウトを監視して盗難防止を行うなど先駆的な応用を行っている。Walmartは、個々の小さな変化を積み重ねることで、店舗のエコシステムを構築していくことが重要と考えているようにみえる。
図表42-22

Walmart IRLの特徴

出典：The Tech Inside IRL＊19を参考にIPAにより作成＊20
その後、WalmartはBossa Nova Roboticsとの提携を解消したとの報道があった。
（2020/11/2）
在庫管理ロボプロジェクトは5年にわたり運用検証されたものの、現時点ではロボットでも人間でも作業ス
ピードや効率に大差なしとの結論を得たようである。引き続き、掃除、レジなどの店舗内でのロボット
運用計画は進められている。
Walmartはスマート化に対して引き続き積極的であり、P2P商品配達のJoyRun（米国）の一部資産を買収することで傘下に置くなど＊21の動きもみられる。Walmartは新規の技術を取り入れつつ、有用ではないとの判断も素早く行い絶えず進化しようとしているようにも見える。
2021年、第1・四半期（2-4月）決算では、営業利益は69億1,000万ドル（前年同期比32.3%増）。総売上高は
1,383億1,000万ドル（前年同期比2.7%増）
だった。

＊ 19
＊ 20
＊ 21

The Tech Inside IRL <https://corporate.walmart.com/IRL/>
https://www.wsj.com/articles/walmart-shelves-plan-to-have-robots-scan-shelves-11604345341
https://techcrunch.com/2020/11/20/walmart-is-buying-joyrun-assets-to-add-peer-to-peer-product-delivery/
DX白書2021 251

データ利活用技術

から商品を降ろし、フロアに届けるまでの時間を短縮する自動化プロセスを導入している。
この技術は

（2）技術動向
本稿では、「AI白書2020」の知的活動の分類を引用しながら、AIの主要な機能について述べる。
「AI白書2020」では、人間の知的活動を実現する技術群として、認識、理解、学習、判断、予測、言語、知識、身体性、創作の九つに分類した。
本白書ではその概略を付録に記載した。
個々の技術の詳細に関しては必要に応じて「AI白書2020」の「第2章 技術動向」
を参照されたい。
（ア）知的活動を実現する基礎技術
ヒトの知的活動とキーワードの概念を示したのが図表42-23である。
この分類はAIに関してのさまざ
まな定義がある中で、初学者に対してもわかりやすいものと思われる、「AI技術は人間等の知的活動を
コンピューターで実現するための技術群である」という考え＊22に基づいてIPAが知的活動を整理したものである。この分類は学術的な観点から導出したものではなく＊23、本書でのAI技術の説明を行うに当たって便宜的に作成したものであり、AIの機能をわかりやすく分類するための手がかりにしてほしい。
現在のAIの課題処理に関して一つの目安とすることで理解が深まるであろう。
図表42-23

知的活動を実現する技術

図表42-24に、知的活動を実現するAI技術の概要を示す（詳細は付録参照）。

＊ 22 （研究開発の俯瞰報告書）システム・情報科学技術分野（2019 年）／ CRDS-FY2018-FR-02、JST＊ 23 学術的な俯瞰図としては、JST の研究開発の俯瞰報告書や、人工知能学会の「AI マップβ」<https://www.
ai-gakkai.or.jp/resource/aimap/> を参照されたい。
252 DX白書2021

活動

概要

主な技術

隠れた物体の認識、顔認識・顔認証、カメラによる体温測定、
Vision Transformerに よ る 画
像認識

理解
AIによる
「理解」とは、言葉の意（付録第1章.2） 味理解、画像の理解を分散表現を利用して行うこととなる。

分散表現による意味理解、画像認
識を介した理解、VQA（Visual
Question Answering）等、画 像
内の物体ラベル化技術

マルチモーダル学習による分散表現獲得、Transformerによる分散表現獲得と画像および自然言語での共通分散表現

学習
AIにおける「学習」は、学習の基（付録第1章.3） 本的考え方としてデータの種類とそれに合わせた学習方法に基づくことになる。学習モデルは推論として未知のデータを扱える。

教 師 あ り・ な し 学 習、強 化 学 学習自動化、「拡張分析」、データ
習、SVM、
ディープラーニング、 サイエンスの民主化、超大型学
ノーフリーランチ定理、醜いア 習モデル
ヒルの子定理判断
AIによる「判断」とは、データを（付録第1章.4） 解析した結果に基づく判断＝意思決定となる。

プランニング技術、推薦システ
ム、マッチング、行動経済学、意思決定過程の可視化・自動化技
術

予測（付録第1章.5）

AIに よ る
「予 測 」に は、分 類、回帰、クラスタリングなどが使用される。とくにシミュレーショ
ンを用いることで説明可能な予測が実現しつつある。

分類、回帰、クラスタリング、ベ タ ン パ ク 質 構 造 予 測イズ推定、アンサンブル学習、グ （AlphaFold2）、
工場内故障予測
ラフ構造の学習と予測、マテリ
アルインフォマティクス、バイオインフォマティクス

言語（付録第1章.6）

自然言語処理は、伝統的なルー
ルベース翻訳から、統計機械翻訳、ディープラーニングによる機械翻訳へと進歩してきた。最新のBERTやGPTについては注
目技術としてとりあげる。

ルールベース翻訳（RBMT）、用例に基づく機械翻訳（EBMT）、
統計的機械翻訳（SMT）、ニュー
ラル機械翻訳
（NMT）
、言語モデ
ル

Transformer に よ る 自 然 言
語 処 理 能 力 の 飛 躍（BERT、
ELMO、GPT）、
自然な会話の実
現（Duplex）

知識（付録第1章.7）

AIにおける「知識」および「デー
タ」は、ルールベースに始まりセ
マンティックWebに至る知識処理の考え方の変遷、データ基盤を経て、知識を使った推論や、知識グラフの補完などにつながっている。

オントロジー、セマンティック
Web、LOD、共 通 語 彙、知 識 獲
得、データ処理基盤技術、データ保護技術、知識グラフ、知識獲
得、データ処理基盤技術、データ
保護技術

知識を使った推論（推論チャレンジ）、知識グラフの埋込と補完、情報の信憑性判定、データバ
イアス問題

身体性
（付録第1章.8）

ロボティクスおよび「身体性」は
AI応用分野では注目されている。動作の自動獲得、認知発達ロ
ボティクスや、ミラーニューロ
ンシステム（MNS）等行動する知能を目指す。

認知発達ロボティクス、身体性、予測学習、MNS（ミラーニュー
ロンシステム）の応用、利他行動の創発

ソ フ ト ロ ボ テ ィ ク ス、リ ザ ー
バーコンピューティング、人工意識に関する認知科学的考察、
世界モデル

創造
（付録第1章.9）

AIによる「創造」とは、学習されたデータにない新しいデータを創造する技術が中心となる。統計学の「生成モデル」を利用した
GANが代表となる。

オ ー ト エ ン コ ー ダ ー、VAE、 GANのさまざまなバリエーショ
GAN、
確率的生成モデルの利用
ンの提案（BigGAN、CycleGAN等）、マ テ リ ア ル ズ イ ン フ ォ
マ テ ィ ク ス/創 薬 へ の 応 用、Transformerに よ る 大 規 模 モ
デルからの自動生成

各種センサー利用による自動意
思決定、不完全情報ゲーム解法の応用、議論マップ、議論マイニ
ング、脳の意思決定メカニズムの研究

DX白書2021 253

データ利活用技術

認識
AIによる「認識」とは、物体認識、 物体認識、
行動認識、
音声認識
（付録第1章.1） 音声認識、行動認識など、与えられたデータに対して対象とする要素の有無を判定、区別するこ
とである。

技術動向例

｜第 ４ 部｜第 ２ 章｜

図表42-24 「知的活動」の概要、および、主な技術、最新技術動向

（イ）2021年注目すべき先端技術
AIが流行っているから活用するというのではなく、業務プロセスの全体を見直し、全体最適となるよ
うAIを活用することが理想といえる。
しかし、
常にAI技術のトレンドを理解し、自社の課題解決につなげられないか検討することがその一歩になることはいうまでもない。ここでは最近の技術について紹介することでAIの実装において見通しがよくなるよう注目すべき技術をピックアップする。
最初に、昨年度BERTにより大きく進展した自然言語処理関連について紹介する。自然言語処理が「理解」
をどう攻略しつつあるのか、その進展をみることができる。
AI、
機械学習の導入に関して現在は、
高度な専門的知識と経験をもった人材が大量のデータを前提にシステムを作り上げていくという状況であり、だれでも簡単に導入できる環境とはいいがたい。
この問題に対して、AI研究者や先進企業も手をこまねいているわけではなく、いくつかの技術的なアプロー
チを進めている。
次にこのAI技術の開発・運用を含めた新しい取組を示す。
現在のAI、
機械学習は大量のデータを取得することが前提となっている。
ここで問題になるのはデー
タが集まらない状況や、独自のデータであるので社外に出せない、あるいは必ずしもデータを処理する
AI資源が十分な計算能力を持っていない等の課題である。
フェデレーテッドラーニングはまさにこの種の問題を解決すための技術であるため、その概要を紹介する。
最後に機械学習と量子コンピューティングを組み合わせる次世代の取組を紹介する。
（a）自然言語処理
自然言語処理の歴史は長く、AIの本命技術の一つとして常に期待された領域であった。
深層学習がAIを席巻してからもさまざまな取組がなされたもののすぐには大きな進歩がなかった。
これは自然言語の特性が阻害していたともいえる。深層学習の発展のひとつにGPUの利用、いわゆるGPGPU＊24がある。
これはGPU上にある多数の積和演算ユニットを並列かつ効率的に利用する方法となる。
ところが言語のように意味や指示語、代名詞等を文の中で前後して扱うような構造の場合はRNNと呼ばれる時系
列を扱うための構造が用いるのが一般的であり、この場合、順序による依存関係を考慮する必要がある
ため、依存関係間での待ちが発生し並列化しづらい。
結果としてGPUが効率的に使用できない。
文章中の単語に焦点を当てることでその単語そこで登場したのがAttention＊25という考え方である。
と関係する文章中でのあらゆるつながりを見つけるという方法である。
その際に重要であるのは、
つながりのみに焦点を当てて、文法的な性質を考慮しないことである。
注目すべきはこのときにメモリ上に文章のすべてが格納できれば、あたかも画像内の一部分の特徴を他の場所と比較するかのように並列計算が可能になる。
すなわち自然言語であっても時系列からはなれて並列処理を行えるのである。
このようなAttentionを中心とした基本的な機械学習はTransformerと呼ばれている。
Transformerでは、普通のテキストを学習データに、計算資源を効率よく使用することで膨大なパラメーターを処理することを可能にしたのである。Transformerを理解するための追加のキーワードをいくつか紹介する。
これらのキーワードは現在の自然言語処理技術を特徴づけている。

＊ 24
＊ 25

 PGPU: General-purpose computing on graphics processing units; GPU による汎用計算を示す。GPU の演算
G
資源を画像描画処理以外の目的に応用する技術。
Attention is all you need. <https://arxiv.org/abs/1706.03762>

254 DX白書2021

パラメーターが多ければ、たとえば学習時の参照範囲を広げることができ結果も期待できることになる。
つまりパラメーターのスケールを大きくできれば、現在のモデルの限界を押し上げることと同時｜第 ４ 部｜第 ２ 章｜

1）パラメーター数の拡大に性能が上昇することが期待できる。
実際、Transformerにおいてスケールの拡大保証は確かめられて縮して効率化する手法もまた研究開発されている＊26。
図表42-25

言語モデルのパラメーター数変化

出典：The Future of Natural Language Processing＊27を基に一部データを更新しIPAにて作成

2）言語モデル
言語モデルは自然言語処理を行ううえで機械学習の中心となる部分である。基本的には文章のどこにどの単語が出現するのが自然なのかをTransformerでは文章中の特定の位置での単語の出現確率によって計算する。前後の単語との相互参照を含めて決めることにより確率ベースで計算することが可能なのである。その結果、膨大な数のパラメーターにより事前学習された言語モデルはトレーニング
データから驚くほど多くの知識、
つまり単語の関係性を学習することに成功したことにとどまらず、記
述内容の論理的なつながりさえ学習している。これによりテキストの要約や会話といった文章生成タ
スクが正確でかつ構成上も問題ない水準に押し上げられるだけでなく、簡単な計算やプログラムの自動生成すら可能になることがわかった。
図表42-26は言語モデルの学習パラメーターが大きくなるにつれ、
足し算や掛け算が可能になったことを示している。10億パラメーターが一つの目安となる。
さらに計算だけではなく自然な言語記述を入力することでプログラミングコードが自動で生成できる技術に発展している＊28。
＊ 26
＊ 27
＊ 28

 LBERT: A Lite BERT for Self-supervised Learning of Language Representations <https://arxiv.org/
Aabs/1909.11942>
The Future of Natural Language Processing <https://ja.stateofaiguides.com/20200914-future-of-nlp/>
Codex <https://openai.com/blog/openai-codex/>
DX白書2021 255

データ利活用技術

おり、パラメータースケールの拡大はそのまま性能上昇につながる。一方で、大きくなったモデルを圧図表42-26

言語モデルのパラメーター数を増やすことで翻訳だけでなく計算も可能になる

出典：Language Models are Few-Shot Learners＊29の内容を基にIPAにて作成

3）Zero（Few）
Shot学習前述したように事前学習モデルには、データに使用したテキストに記述されたすべての参照関係が含まれるため、例示なしもしくは一例二例の提示でのタスク推定を可能にした。Few-shot学習はタスク（推論時）に少数（10から100）の例を示す場合を、One-shot学習では一つの例示のみを与える場合となる。そしてZero-shot学習では例示なしとなる。たとえば、ライオン、サイ、キリン…を学習させた属性
モデルは、学習していないヤギやゾウに対しても属性クラスを参照し、クラス判定が可能となる（図表
42-27）。
これらは事前学習モデルの性能に大きく依存することになるが現在では、
実際タスク例がないか、
一つのタスク例を示すことで、タスク達成性能としてほぼ最高のパフォーマンスを上げることに成功している。
言語モデルの規模も話題を呼んだが、2020年、OpenAIによるGPT-3＊30の発表は大きな衝撃を与えた。
そのデモの内容は言語モデルこそ汎用AIにつながる王道なのではないかと考える人も少なくなかった。2021年はVision Transformerが学会をにぎわした。
これは自然言語用に設計されたTransformerを
画像分野に応用するという試みである。
自然言語処理では穴埋め問題で学習するが、では画像ではどうするのか。
ジグゾーパズルを組み立てるかのように画像の穴埋めを行う。

＊ 29
＊ 30

 anguage Models are Few-Shot Learners.:2020 <https://arxiv.org/abs/2005.14165>
L
GPT-3 <https://openai.com/blog/gpt-3-apps/>

256 DX白書2021

｜第 ４ 部｜第 ２ 章｜

図表42-27

Zero-Shot Learning

データ利活用技術

出典：Transductive Zero-Shot Recognition via Shared Model Space Learning＊31を基にIPAにて作成

穴埋めとパズルはヒトにとっては何とも簡単な方法である。AIがヒトの学習方法を真似て理解の言葉とイメー
フェーズへ進みだしたといえるのかもしれない。
実際にOpenAIが発表したDall・E＊32は、ジに関して完全に理解しているようにふるまう。実際デモでは、言葉を理解してその内容に応じたイ
メージを作り出す。
言葉の端々とイメージ内の各ピクセルが本当につながっているかのようである。
もちろんこれは、Transformerが、見方によっては全結合のアーキテクチャーに戻った結果と考えることができ、メモリ内にある全データに対して重みづけの計算を行うことができることによって、これまで実現しなかった理想的な機能が実現できたと考えることもできる。
「アボカドのようなアームチェア」「アボカドを模したアームチェア」と入力すると何十種類ものパターンで結果を返す（図表42-28）。
データで与えられてさえいれば、イメージと言語表現のあいだでそれらしいものが出来上がってくる。ヒトの知的活動が総合的に実現されるまでに至ったといってもいいだろう。
図表42-28

DALL・Eの例

出典：OpenAI DALL・E＊32デモを基に概略をIPAにて作成

＊ 31
＊ 32

Transductive Zero-Shot Recognition via Shared Model Space Learning.: 2016, AAAI16
<https://ojs.aaai.org/index.php/AAAI/article/view/10448>
DALL・E <https://openai.com/blog/dall-e/>
DX白書2021 257

最近、万能性を見せる超巨大事前学習モデルをFoundation Modelと名づけ、社会に与える影響を可能性とリスクの視点でまとめた論文がスタンフォード大学（Stanford University、
米国）のAI科学者約100
この領域について非常に詳しく調べられており参考となる。
人の共著で発表された＊33。
（b）AIの導入・運用を容易にするための技術
AI、
機械学習の導入に関しては課題も多い。
まず、大量のデータをどのように扱えばいいのか、
そもそもデータが集まるのかを検討する必要がある。そしてデータが集まったあとには高度な専門的知識と経験をもった人材がデータに合わせて個別のシステムを作り上げることになる。これではどの企業でも簡単に導入するわけにはいかず、
結果として取組が進まないという課題が生じている。
ここではAIの導入・運用を容易にするための新しい取組を示す。
1）API化自然言語処理に関わるAIタスクは毎回一からシステムを作り上げる必要がある。
たとえば少しのタ
スク追加、もしくは削減を行う場合でも一から再設計する必要がある。これに対して、自然言語処理で使用するタスクに対応するAPIを作成することで、事実上すべての自然言語処理関係のタスクをAPIの呼び出し・組み合わせで構築することが可能になった。
たとえばOpenAIでは自然言語処理系AIの汎化の例としてGPT-3（1,750億のパラメーターを調整した自然言語処理系）にアクセス可能となっている＊34。
さらにGPT-3を使用する/予定のある商用アプリケーションのショーケースも公開されている＊35。
2）AutoML（Automated Machine Learning）
機械学習には多くの作業が必要なため、活用が進みにくい状況である。AutoMLは機械学習の各プロ
セスを自動化してエンジニアの生産性を向上させること、また誰でも機械学習を使えるようになることを目指した技術である。
究極的な目標は、生データを与えれば自動的に処理を行い、ユーザーにとって有用な結果を出すことである（図表42-29）。
これにより、企業内のデータサイエンティストの不足を補った
り、AIの知識がない人材でも機械学習による成果をえたりすることが可能となる。
具体的にはAutoML
では大きく「ハイパーパラメーターチューニング」「モデル選択」「特徴量エンジニアリング」の3点を行う。

＊ 33
＊ 34
＊ 35

On the Opportunities and Risks of Foundation Models <https://arxiv.org/abs/2108.07258>
https://beta.openai.com/
https://gpt3demo.com/

258 DX白書2021

｜第 ４ 部｜第 ２ 章｜

図表42-29

ユーザーからみたAutoMLのイメージ

データ利活用技術「ハイパーパラメーターチューニング」とは、機械学習モデルに存在するさまざまなハイパーパラ
メーターを文字通り最適な値に調整するプロセスである。
たとえば、ランダムフォレストであれば木の深さや数をハイパーパラメーターとして持っているが、学習フレームワークのデフォルトのパラメー
ターでは推論の対象に合わず、よい性能が出ないことが多い。
そこで、AutoMLでは、
従来人手で行っていたハイパーパラメーターチューニングを自動化する。
このとき性能が向上するだけでなく、人が直感的に決めたパラメーターによるバイアスを取り除くことにも繋がることが利点の一つになっている。
「モデル選択」とは、データを学習させるために使う機械学習アルゴリズムを選ぶプロセスである。
モ
デルにはSVMやランダムフォレスト、ニューラルネットワークなど多くの種類がある。その中から解きたい問題に応じてモデルを選択する。
たとえば、解釈性が重要な場合は決定木などのモデルを選ぶべきであり、とにかく性能を出したいという場合はニューラルネットワークが候補になる。
モデル選択が必要な理由として、現状、すべての問題に最適な機械学習アルゴリズムは存在しないという点を挙げる
ことができる。
そのため、これまでの経験例からモデルを適切に選択することが重要となるため選択のための工夫が必要である。
たとえばモデルの名前と課題があり、よい結果となったモデルが並んでいる中などから判断することも可能となる。選択された機械学習モデルのパフォーマンスを最大化する特徴量設定を行うのが「特徴量エンジニアリング」となる。
AutoML-Zero＊36では、人の手をできる限り排除して最適なアルゴリズムを探索、開発させるというアルゴリズムを目指している。
現状では最高性能には及ばないものの、
二層ニューラルネットワークの今後が期待できる。
バックプロパゲーション＊37の自動発見等、
3）MLOps
DevOpsとは、プログラムの設計・実装を担う開発（Dev＝Development）
チームと、
当該プログラムの実行環境を監視・維持メンテナンスする運用（Ops＝Operations）
チームの二つがシームレスに連動し、
＊ 36
＊ 37

AutoML-Zero: Evolving Machine Learning Algorithms From Scratch <https://arxiv.org/abs/2003.03384>
ニューラルネットの代表的なパラメーター更新の方法。前方の重みづけに基づき後方に次々と伝搬させることにより更新する方法。
DX白書2021 259

協調的な活動を行うものでDev+Opsのチームの協働体制および、
それによって得られる「機能改善と安定稼働の両立」を行うこととなる。
つまりアジャイル型開発を志向し、日々、仕様変更や機能追加がDev側で行われ、
それをOps側で運用していくにあたり一丸となって設計・開発・運用をシームレスに行うこととなる。そしてこの概念を機械学習にとりいれたのがMLOps（Machine Learning + Operations）となる（図表42-30）。
図表42-30

Data
Collection

NVIDIAによるMLOpsの説明
Raw
Data

Data
Ingestion

Indexed
Data

Data
Analysis &Curation

Selected
Data

Data
Labeling

Deployment

ML
Certificate
Validated
ML System

ML System
Validation

Data
Validation

Validated
Data

Data

Preparation

Release, Configure, Monitor

Operation

ML System

Labeled
Data

KPIs

Model
Evaluation

ModelsModel
Training

出典：NVIDIA What is MLOps?＊38を基にIPAで作成

機械学習の日々の学習と円滑な運用、安定稼働がなぜ問題となるのか。
これは機械学習システムが抱える根本的な問題が強く影響している。
つまり現在の機械学習システムは、明示的なプログラミングで機能しているのではなく、データを学習することでパラメーターチューニングされたモデルにより機能している。そのため本質的には、新たなデータに対しては、既存のデータでチューニングされたパラメーターは意味をなさなくなる危険性を内包している。そのため常に学習とその結果となる推論の精度を検証しつつ運用する必要がある。
そのため開発・運用が一丸となる必要が出てくるのである。
「デー
タ加工、学習作業の前処理の自動化」「継続的に再学習する仕組み」「デプロイの自動化」「監視およびア
ラートの仕組み」「疎結合なアーキテクチャー」
といった仕組みを各種ツール、コンポーネントを駆使した「機械学習基盤」として組み上げることが、MLOps、つまり、Machine LearningとOperationsの融合となる。
（c）フェデレーテッドラーニングと分散学習
1）フェデレーテッドラーニング（Federated Learning）
オンデバイスで複雑な処理がこなせるようになると、機械学習に必要なデータを収集し、端末上でよりセキュアに管理できることになる。
一方で、機械学習によって端末単位でトレーニングしたデータをクラウドとして学習しないことは学習結果がいつまでたっても反映されないという課題が生じる。この問題を解決するのがフェデレーテッドラーニングである。
Googleでは、個人情報保護とユーザー体験の向上を両立させるべくフェデレーテッドラーニング技術に着目した。たとえば端末上でのある操作に関連する機械学習のベースとなる「モデルA」をクラウ＊ 38

What is MLOps? <https://blogs.nvidia.com/blog/2020/09/03/what-is-mlops/>

260 DX白書2021

号化してクラウドに送り返すというフィードバックを繰り返す。端末内の機械学習データは自動的にブラッシュアップ、改良され続ける。この間、ユーザーの個人情報などのデータは端末から外に送り出｜第 ４ 部｜第 ２ 章｜

ドからスマートフォン等の端末にダウンロードし、端末上で鍛え上げてから「改善情報」
だけを抽出、
暗す必要がないためセキュリティは担保されることになる。
この仕組みを使い、
たとえばカメラアプリに新により使い勝手のよいものにすることが可能になる。そこでGoogleはこのフェデレーテッドラーニ
ングをPixel 3で初めて取り入れた。Pixel 4ではタッチ操作にフェデレーテッドラーニングを用いてい評価解析の結果、
強く押す動作と長く押す動作の区別は、ユーザーには識別困難であることがわ
る＊39。
かったため両者を統一的に扱うべきという興味深い結果を得ている。
個々のデバイス向けには空間的な特徴量に対応するための畳み込みネットワーク
（CNN）
とその時間
的進展に対応するためリカレントネットワーク（RNN）を組み込んでいる。
各信号フレームは、
タッチセ
ンサーから受信したときに、その都度ネットワークによって逐次処理され、RNNの状態ベクトルはフレーム間で保持されることになる。
ネットワークは、
デバイス上で実行するため意図的にシンプルな構
成に保たれている。スマートフォンなどのデバイス上で他のアプリケーションと同時に実行される事を考慮し、推論コストを最小限（フレームあたり約50µsの処理時間とTensorFlow Liteを使用して1MB
未満のメモリ消費量）に抑えこんでいることも特筆すべきであろう。
端末ごとにこれらの個別処理を行い、その結果のみをクラウドに送信する。クラウド側では共通のモデルクラスを更新し、結果をまたデバイスに送ることになる。
別の例としてエッジ側がとくに重要な要素となるマルチホップ無線の適用例がある。マルチホップ
フェデレーテッドラーニングでは、複数のデバイスのグループがデータをローカルかつプライベートに保ちながら、共有されたグローバルモデルを共同で学習することを可能とする。
シングルホップの無線通信を利用する古典的な連合学習システムとは異なり、
マルチホップシステムの更新は、ノイズや干渉の多い複数の無線リンクを経由する必要があり、更新が遅くなる可能性が大きい。そこで通信の遅延、システムやデータの不均一性などの課題に体系的に取組むことで、
安定性、
高精度、
高速な収束速度が保証された新しい無線マルチホップ連合学習システムを開発することで、この課題の克服を目指す
ことになる。
機械学習には大量のデータが必要であり、そのためには学習基盤にデータを渡す必要がある。
しかしデータは今や企業の生命線の一つであり容易に外部に出すことはできない。また個人情報に紐づけされたデータに代表されるデータ、
たとえばヘルスケアデータに関してはさらに慎重に扱う必要がある。
このことは、エッジと分離することでデータ秘匿を果たすことが可能となるフェデレーテッドラー
ニングには適している。もともとエッジで処理を行う理由は、リアルタイムでの結果をエッジ側で処理、使用することが目的であったが、たとえばクラウドに学習結果および学習モデル更新に必要な情報のみをあげることで、データの秘匿性を維持しつつ機械学習を進めることが可能になる。OWKIN＊40
ではこの技術をデータ秘匿と機械学習の効率化の両立という視点で応用している。
さまざまなバイオマーカーのパターンを解析し標的を発見するプロセス、親和性が高く低毒性となるよう最適な分子を設計し新薬をデザインするプロセス、臨床試験で最適な結果となるよう薬物反応を予測するプロセス、そして類似する症例を発見し医学の精度を高める市場分析プロセスといった新
＊ 39
＊ 40

https://ai.googleblog.com/2020/06/sensing-force-based-gestures-on-pixel-4.html
https://owkin.com/federated-learning/
DX白書2021 261

データ利活用技術

関係するアルゴリズムに対して、多くのユーザーから送られてくる改善情報を基に解析評価し、差分更薬開発におけるあらゆるプロセスにおいてフェデレーテッドラーニングによる最適化は、患者のデー
タ・プライバシーを尊重すると同時に、根底にある病気のメカニズムと新しい治療法を発見することを可能とする。
フェデレーテッドラーニングは、データ・プロバイダーがデータのコントロールを可能にするもののそれでもなおプライバシーのリスクが潜んでいる。
そこでOWKINでは優れたトレーサビリティーと透明性を持つブロックチェーンによりこのリスクを軽減することを狙う。スマートコントラクトを利用して、アルゴリズムがネットワークのプライバシー基準に違反していない場合にのみ交換されるセ
キュリティデポジットを要求することで、悪意のあるプレイヤーをそもそも抑止することが可能となるためだ。
（ブロックチェーンに関してはコラムを参照のこと）
NVIDIAは、医用画像によるフェデレーテッドラーニングを医療機関と協力のもと推進している。
図表42-31にNVIDIAのフェデレーテッドラーニングの概念図を示す。各医療機関の個人情報は他の機関には渡されず、医用データでの学習結果のみがフェデレーションサーバーに集まり、学習が進む。
COVID-19でもここで利用されたフレームワークを利用し、
胸部X線、患者のバイタルサイン、検査値を使用するものの、ローカルのトレーニングとグローバルモデルを組み合わせたフェデレーテッドラー
ニングを行った。
このシステムではプライバシーを保護する手法で、モデルのパラメーターのサブセットのみ共有する。20日間で20の病院で学習を行った結果、酸素の需要を予測するAIモデルを構築する
ことに成功した＊41。
図表42-31

フェデレーテッドラーニングの例
Cancer Treatment
CenterCommunity Hospital

Privacy Preserving
Private data

Local Model

Local Model

Private data

Federated Server

GlobalModel

Local
ModelsGlobal Model

Private data

Local Model
Research
Medical Center

Local Model

Private data

Community Hospital

出典：NVIDIA federated-learning-clara＊42を基にIPAで作成

AIは今後もハイパフォーマンスコンピューティングとハイパフォーマンスデータアナリティクスのパイプラインを融合させ、マルチワークロードの収束をもたらすだろう。
現在、データ解析、
トレーニン
＊ 41
＊ 42

https://blogs.nvidia.co.jp/2020/10/09/federated-learning-covid-oxygen-needs/
NVIDIA federated-learning-clara <https://developer.nvidia.com/blog/federated-learning-clara/>

262 DX白書2021

FPGA、グラフプロセッサ、特殊なアクセラレータを用いるケースも増えてきている。コンピューター
ビジョンに始まったAI応用は、マルチモーダルAIや会話型AIに移行している。またディープラーニン｜第 ４ 部｜第 ２ 章｜

グ、推論は、同じコンピューティングプラットフォーム上で実行されており、GPUの使用だけでなく、

グは、LinkedInではパーソナライゼーション、レコメンデーション、Googleでは翻訳、YouTubeではパラメーターは普通であり、一兆個にも届く勢いである。
複雑化した中でフェデレーテッドラーニング
は、AIデータパイプライン内で、それぞれが異なるストレージとI/O要件を持つ異なるステージを同居させることを可能とする。たとえばIntel（米国）は複雑なDNNにさらに数百、数千億のエッジデバイ
スをつなぐにはフェデレーテッドラーニングが解決策の一つになるとみている。
ICML2020＊43において、フェデレーテッドラーニングは分科会として以下のように取り上げられており、関心を集めていたようである。
「フェデレーテッドラーニング（FL）への敵対的な攻撃」「FLのためのブロックチェーン」「FLの公平性」「FL・オン/用・ハードウェア」「FLの新しい応用」「FLの運用上の課題」「FLでのパーソナライゼーション」「FLでのプライバシーに関する懸念」「FLのためのプライバ
シー保護手法」「資源効率の高いFL」「FLのシステム・インフラ」「FLへの理論的貢献」「FLの不確実性」「協調投稿方法」
等が議論されている。ICML2021＊44においても国際ワークショップが開催されており、この分野の注目度は引き続き高い。
2）分散学習
現在の機械学習、とくに深層学習では1か所にデータを集約し、画像・音声認識等のモデルを学習することが一般的である。
しかし、
あらゆるモノがネットワークに接続するIoT時代において、膨大なデー
タを1か所に集約することは困難となる。さらに言えば、プライバシー保護の観点でデータをローカルにあるサーバー・機器にとどめたいという需要も増加していく一方である。
関連して、EUの一般デー＊45のようなプライバシー保護のための法的規則が強化されつつあることも重要な
タ保護規則（GDPR）

視点である。こうした時代において、データを蓄積・分析・処理するサーバーを分散化し、上位システ
ム（クラウド）や通信網の処理負荷を低減させ、応答速度やプライバシー保護の観点でユーザーの利便性を高めるエッジコンピューティングへの期待が高まっている。そこでエッジコンピューティングのように分散配置されたサーバー群に分散してデータが蓄積されていく環境でも、
あたかも1か所にデータを集約して学習したかのようなグローバルモデルを得るための学習アルゴリズムが必要となる。そこで①統計的に非均一なデータがサーバー群に蓄積されており、かつ②サーバー群がモデルに関連する変数を非同期に通信・交換することで全部のデータを1か所に集めて学習したのと同等のモデルが＊46。
得られるというアプローチが分散学習である（図表42-32）

＊ 43
＊ 44
＊ 45
＊ 46

http://federated-learning.org/fl-icml-2020/
https://icml.cc/Conferences/2021/ScheduleMultitrack?event=8359
https://www.ppc.go.jp/enforcement/infoprovision/laws/GDPR/
https://www.ntt.co.jp/news2020/2008/200824a.html
DX白書2021 263

データ利活用技術

動画の低遅延推論でも使用されている。その結果使用するディープラーニングは数十億個のハイパー分散学習の例

図表42-32

Cl
Sh
Lv Tr
Ea
In

統計的に非均一なデータによるエッジ学習
エッジごとに異なるクラス学習
非同期通信とランダムタイミングで変数交換系としてすべてのクラス分類可能

Ta
Fr
In
Sh
Dr
Ea

特徴量パラメーターはエッジ群で部分的に共通化、ネットワーク全体ですべて
を網羅する

Dr
Ea
Bi
Bo
Fr
Lv

分散している
特徴量パラメーター

出典：NTT発表資料＊46を基に一部変更IPAで作成（d）量子機械学習
機械学習では教師あり学習、
教師なし学習、強化学習の3種類があることは本文で述べた。
たとえば教師あり学習であれば、入力ベクトルaに対して出力ベクトルbになるための行列Aを求めるということがその基本にあることは容易に推測できる。
この場合に行列Aを求めるためにbを中心に展開するにはAの固有ベクトルを知らなければならないがここで量子アルゴリズムを使用すると展開状態そのもの
で計算が可能となる。
つまり固有ベクトルをいちいち計算しなくても逆行列が計算できるのである。
このように量子計算アルゴリズムを使用することで学習アルゴリズムの一部を置き替えた機械学習を量子機械学習と呼ぶ。
たとえば教師あり学習で使用する線形回帰にはHarrow-Hassidim-Lloyd
（HHL）
アル
（G検索）
アルゴリズム＊48、サポートベ
ゴリズム＊47、K-meansではデータベース検索のためのGrober検索
クトルマシンではHHLアルゴリズムおよびGアルゴリズムの両者のアルゴリズムを使える場合がある
ことがわかっている。
この場合には従来の計算と比べて量子計算による効果がどの程度になるのか、
量
子加速と呼ばれる効果を見積もることができる。HHLアルゴリズムでは指数の効果、Gアルゴリズム
で2次のオーダーでの効果があることが知られている。
同様に教師なし学習でよく用いられる主成分分析ではHHLアルゴリズム、同様にK-means（クラスタリング）ではGアルゴリズムの適用が可能であり、強化学習のQ学習ではGアルゴリズムが適用できる場合があることがわかっており、いずれも量子加速が見込まれる。
そしてもう一つ重要な視点は、量子機械学習では消費電力が大幅に削減できる可能性が高いことである。
少なくともその性能と消費電力の2点において、AIと量子コンピューティングの融合
は今後の発展に期待が寄せられている。

＊ 47
＊ 48

Quantum linear systems algorithms: a primer.:2018. <https://arxiv.org/pdf/1802.08227.pdf>
A fast quantum mechanical algorithm for database search.:1996.
<https://arxiv.org/pdf/quant-ph/9605043.pdf>

264 DX白書2021

この節では最新の利用動向を紹介することで自社の課題を解決するためのヒントになることを期待する。

医療分野においてAIは、分析と予測モデリングにおいて重要なブレークスルーを実現した。その結果、学習サイクルの大幅な加速を可能にし、これまでアクセスできないことで有効利用できなかった研究データ、生産データから重要な洞察を導き出すことが可能になった。さらに近年DeepMindに代表されるようにタンパク質の折り畳み構造予測はAIの独壇場である。AIによるバイオインフォマティク
スもまた重要な研究開発の武器なのである。
Pfizerはデジタルデータの活用に力を入れており、創薬の研究開発の効率化、早期実用化のための仕組みが作られている。mRNAに関しては、その第一人者Karikó Katalin博士が在籍するBionTechと早くから協力関係を築き、COVID-19のワクチン開発においてもいち早く実用化に成功している。
ここではその中でとくに複雑で手間がかかる臨床データ解析を高効率化させるために利用したAIについて紹介する。
Pfizerではデジタルプレーヤーと多くのパートナーシップを結び、ハッカソンを実施して適切な相手を選ぶことで時間を節約しつつ貪欲に技術を取り入れている。臨床試験用AIスタートアップSaama
Technologies（米国）のデータ解析とライフサイエンス・アナリティクス・クラウド（LSAC）を使用することにより臨床試験モデルと臨床データのクエリーの多面的な解析について進めていた。とくにSaamaのモデルが必要な精度を達成するために、Pfizerの臨床データとドメインの専門知識によってモデルを訓練し、その結果、深層学習技術を用いて臨床データのクエリーを集計、
変換、
分析、
モデル化、
予測することが可能になった。
通常、臨床試験または試験段階が終了すると、患者データが「クリーンアップ」
されるまでに30日以上かかることがある。これは従来データサイエンティストがデータセットを手動で検査して、数千万のデータポイントを収集するときに発生するコーディングエラーやその他の不整合をチェックしているためだ。Smart Data Query（SDQ）と呼ばれる新しい機械学習ツールを含むプロセスとテクノロジーの最適化は、COVID-19ワクチンの臨床試験データに関して主要な有効性の症例数を満たしてから、わずか22時間でレビューまでもっていく。Pfizerの歴史的にみても速いワクチンの市場投入が可能になった一因である。PfizerとSaamaが提携して開発したAIベースのSDQデータ管理ソリューションがCOVID-19のワクチン開発においてデータの不一致を予測し、それらの理由を特定し、「ヒューマンイ
ンザループ」の監視の下でクエリーテキストを自動生成することで、クエリー管理を自動化したのである。
図表42-33は、PfizerのデータマネージャーがAIと連携して、COVID-19研究の臨床クエリーを迅速に、多くの場合は自動的に、検査する方法を示している。

DX白書2021 265

データ利活用技術（ア）医療分野での利用｜第 ４ 部｜第 ２ 章｜

（3）利用動向

図表42-33

スマートデータクエリーのワークフロー
SDQ AI

Site Investigators

Review Data

Trained Machine
Predicts Discrepancies

Data Managers

EDC

CRFs
Review
Correct Incorrect
Queries to Site
出典：Saama’s SDQ Speeds COVID-19 Vaccine＊49を基にIPAにて作成

ワークフロー内では、eCRF（電子カルテ）を介して、EDCシステム（Electronic Data Captureシステ
ム:電子カルテ取得システム）に情報を提供することから始まる。
クエリー（担当医師への照会）
はeCRF
をもとに自動的に生成され、EDCに保存される。AIは信頼区間ごとにクエリーを確認し不一致のデー
タポイントを自動で探しだす。
米国の場合は、
通常このプロセスを人が行っており時間がとられる部分である。SDQ AIは、提案されたクエリーテキストが正しくかつ適切であったことを認識し、基盤となるSDQアルゴリズムを改善する。
クエリーテキストが正しいか否かを確認し、正しくない場合にはどの点が正しくないのか、詳細を検討、修正したクエリーテキストを再作成する。eCRFエントリから自動クエリーの生成とレビューまでのこのプロセス全体は、わずか数分で完了し、SDQでより多くの臨床データが渡されてレビューされるため、かなり高速になる。SDQのパフォーマンスの予備的な結果は印象的であり、わずか4か月で1億500万を超えるデータポイントが調整された。
従来、データキャプチャからクエリー生成までの暦日中央値は、25.4日（すべてのワクチン研究）であり、これがわずか1.7日に短縮された、つまり15倍の時間の節約が可能となった。データの確認とクエ
リーテキストの自動化で節約された合計時間は、2,800 〜 3,500時間と推定される。非構造化テキスト分析においては自然言語処理を使用して、750,000を超えるフリーテキストの文を解析し、有害事象の信号を検出、病歴や症例報告フォームと照合させることに成功した。
上記のように今回非常に高速に処理されたワクチンで有名になったPfizerはたとえば臨床記録においてはSaamaとの協業によりSDGによる高速処理を手に入れている。SaamaのAIクラウドサービス（図
表42-34）の特徴を一言であらわせば、医療に特化した自然言語処理であり、たとえば下記の点が特別な
自然言語処理基盤によって構成されている。
NLP Attention based Graph NN, Biomedical Text => BioBERTPHI Scrubber: Deep Learning Modelを使用し患者の個人情報を消去＊ 49

Saama’s SDQ Speeds COVID-19 Vaccine <https://www.saama.com/saamas-sdq-speeds-covid-19-vaccine/>

266 DX白書2021

SaamaのAIクラウドサービスの特徴

Without SDQ

Smart Data Query AI

すべてのデータの不一致を手動で追跡、レビュー
マニュアルレビュー検査
システム
スプレッドシートベースのシステム
EDCからのエクスポートの随時レビュー
第三者機関（CROなど）からのデータ依存でのクエリー発行

With SDQ

臨床システムの枠を超えたパターン認識能力

AIが自動生成するTo-Doリストとクリニカルクエリー

非プログラマーでのチェック

臨床的に不一致のあるデータ
ポイントのみをレビュー

Human in the loop architecture
質の高い出力を確保しつつ人手による作業量を削減可能

AIのトレーサビリティーを備えた機械ベースのフィードバック
メカニズム（ループに人間も）臨床データ重視推定とCR(Clinical Reasoning)
AIのフィードバックおよび継続的な学習簡単なSingle Sign Onと集中管理されたスマートなToDoリストによるトラッキングとダウンロード
自動生成された不一致とその説明、APIを使用してEDCにク
エリーをインポート

出典：Saama-Smart-Data-Query-Fact-Sheet＊50を基にIPAにて作成

ModernaはmRNAをそれ自身、情報基盤として捉えており2010年の創業からAIを含む高度なIT技術の中で創薬することを重視していた。たとえばLoockerはその一つであり、COVID-19の感染が拡大する中であっても、さまざまなデータの一元化と分析を行うことが可能であった。
そのため常にプラットフォーム技術を進化させるのと同時に強化し、mRNAのソフトウェア的性質の深掘と活用、mRNA医薬品の超並列研究開発、そして全体として機能するmRNAエコシステムを進化させることを積極的に行っていた。
図表42-35

Modernaの階層的なデジタルプラットフォーム

AIは、分析と予測モデリングにおける重要なブレイクスルーを可能にした。学習サイク
ルは大幅に加速され、これまではアクセスできなかった研究データや生産データに関する重要な洞察を得ることを可能にしている。
ロボット工学の助けを借りた自動化は前例のないレベルに到達し、オペレーションの正確性、再現性、スループットを向上させ、ヒューマンエラーを減らし、品質とコンプライ
アンスを劇的に向上させることに成功した。
情報のサイロ化を避け、プロセスとデータを一貫性のある方法でまとめる。また社内外のシステム間でデータが流れることで、ビジネスプロセスの自動化や業務のリアルタイ
ムな同期をも可能とする。

AI
ANALYTICS
AUTOMATION & ROBOTICSINTERNET OF THINGSINTEGRATION
CLOUD

最新のツールと分析手法を用いて、あらゆる種類の分析を行う。より豊かで複雑なデータを容易に利用することが科学的、ビジネス上の洞察を生み出し、十分な情報に基づいた意思決定を行う能力を高める。
IoTを用いることで、その環境や操作に関する情報を生成する。この膨大な新しいデータ
ソースにより、サプライチェーンや製造では、材料の追跡、在庫の管理、エネルギー消費の最適化などを可能とする。
クラウドは、コンピューティング技術の限界に悩まされることなく複雑なデータセットの整理や処理において、計算能力、運用の俊敏性、
費用対効果、効率性を可能とする。

出典：Saama-Smart-Data-Query-Fact-Sheet＊51を基にIPAにて作成

＊ 50
＊ 51

Saama-Smart-Data-Query-Fact-Sheet<https://www.saama.com/wp-content/uploads/2020/06/Saama-Smart-Data-Query-Fact-Sheet.pdf>
Moderna_The_Digital_Biotech_Company_White_Paper_6.22.17_FINAL <https://www.modernatx.com/sites/
default/files/Moderna_The_Digital_Biotech_Company_White_Paper_6.22.17_FINAL.pdf>
DX白書2021 267

データ利活用技術

AIが自動生成する
To-Doリストとクリニカルクエリー｜第 ４ 部｜第 ２ 章｜

図表42-34

そもそもModerna（オランダ）は、タンパク質の折り畳み研究に不可欠なメッセンジャーリボ核酸（mRNA）に基づいたバイオテクノロジーの会社である。COVID-19ではModernaは一貫したデジタル
プラットフォームによって人間でテストできるプロトタイプワクチンの開発に必要な時間を大幅に短縮することに成功した。ModernaはmRNAを情報として捉え、mRNA創薬プロセスそのものをいち早
くデジタル化したことでCOVID-19に対応できたといえる。
（イ）エネルギー分野での利用
Royal Dutch Shell（オランダ）
は、DXを加速させようとする中で、AIをいち早く採用した企業である。
機械学習からコンピュータービジョン、
ディープラーニングから仮想アシスタント、
自律走行車からロボットまで、Royal Dutch ShellはAIの進歩を支えてきたさまざまな技術に注目しており、さらにAIア
プリケーションを大規模に展開する計画を持っている。
たとえば新しいAIプラットフォームを利用した予知保全への取組を推進しつつ、AIを活用したアプリケーションを全社的に普及させている。
コン
プレッサーやバルブなどの機器のメンテナンスが必要な時期を予測したり、シェール鉱床を通るドリ
ルビットの操縦を支援したり、従業員や顧客の安全性を向上させる、
これらすべてが目的なのである。
たとえば、
ドリルビットから送られてくるリアルタイムのデータを解析しながら、地質学者が井戸のより正確なコースを把握するためにAIを利用する水平ドリルの取組は、生産性を向上させ、ドリルの消耗を減らすことができるようになる。
まるで自動運転車のように、データを自律的に解釈できるアルゴ
リズムがあり、AIと連携することで、地質学者は複雑なデータ解釈に費やす時間を減らし、代わりに多くの井戸を監督し、新たな問題に取組むことができるようになっているのだ。
そしてプラットフォーム
上は二つの予知保全アプリケーションが構築されており、そのうちの一つは、オーストラリアでコール
シームガス生産を行う上流機器を対象とし、もう一つは下流のバルブの異常を検出するために、
それぞれ予知保全アプリケーションが稼働している。
データ分析を使用して機器がいつ故障するかを予測することで、Shellは機器が壊れる前に介入して修理することができる。予測によって不意の機器交換を定期的な交換にすることで資産の予期せぬダウンタイムを防ぐことができるため効率性を高めてコストを大幅に削減することができるようになる。
（ウ）航空分野での利用
航空会社がAIをMRO（Maintenance Repair Overhaul：整備・修理・分解点検）戦略に結びつける
ケースが増えている。
これはメンテナンスを予測できれば、不意の故障を避けることができるためである。
また予測メンテナンスは民間航空会社にとってはまだ黎明期であるものの、将来的にはそれ自身が大規模フリートの民間事業者向けのインテリジェントメンテナンスへと進化していくことも期待できる。
実際にその一歩としてメンテナンスチームの意思決定ツールとしてのAIの使用が拡大している。
もともと米国、欧州、アジアに拠点を置く航空会社は、データモデリングやシミュレーションのためのイ
ンテリジェントエージェントの形で、コグニティブコンピューティングの利用にAIツールを採用しており、大量のデータを集約して分析し、そのうえで実行可能な結果を出している。
Air France-KLM（フランス）
は、自社のMROラボを利用して、航空業界内外の大学、
メーカー、
ソフト
ウェア開発者と提携し、新しいアイデアやコンセプトを航空MROで実現する方法を模索していた。そ268 DX白書2021

用を可能にするためのデジタルインフラが検討されている。
図表42-36｜第 ４ 部｜第 ２ 章｜の中の議論で予知保全戦略には、Air France-KLMによるデータマイニングのためのAIの将来的な活PROGNOS Predictive Maintenance の概要
データ利活用技術

出典：Air France-KLM Predictive Maintenance＊52の説明を基にIPAにて作成

MROラボで開発されたPrognos（図表42-36）は、利用可能な接続リンクを介して飛行中および地上の航空機からデータを取得するように設計された予知保全ソフトウェアとなる。
このデータは保存され、AIアルゴリズムを使用して分析され、事前に定義されたパラメーターのセットに従ってコンポーネン
トのアラートをトリガーする。これらの結果はリアルタイムで航空会社のメンテナンス・コントロー
ル・センターにアップロードされ、メンテナンス作業の指示につながる。
将来的にはモデルを用いてより長期の予測を実現する必要がある。長期の予測が可能になることで突発的なメンテナンスを計画的なメンテナンスに組み入れることができ、多くのコストを削減できることになる。
（エ）海運分野での利用
Maersk（デンマーク）は現在、AIの多くの可能性を見出すために集中的に取組んでいる。
コンテナの品質管理は課題の一つである。リモート・コンテナ・マネジメント（RCM）技術は、貨物がコンテナ内にロックされてから、最終目的地に届けられるまでのコンテナ内の状態を監視する（図表42-37）。
キャプ
何か注意が必要なことがあれば顧客
テン・ピーターはコンテナ内の温度、湿度、CO2レベルを監視し、に通知する、
貨物の航海をより深く理解できるように支援するAIバーチャルアシスタントである。
これ
らのデータはクラウドベースになったことで俊敏性が増し、簡単に共有できるだけでなく、顧客の特定のニーズに合わせて設定することも可能になる。

＊ 52

Air France-KLM Predictive Maintenance <https://www.afiklmem.com/en/solutions/about-prognos>
DX白書2021 269

図表42-37

Maersk RCMの概念図

出典：Maersk RCM＊53の説明を基にIPAにて作成

海運では片便でも燃料費が数億円となるので燃費改善は直接利益とつながることになり大きな課題となる。AIは船の性能をより深く洞察することで、船の燃費を向上させるためにも活用できる。
実際コ
ストを削減し、人命へのリスクを低減しながら、船舶の性能を明らかにするのに役立ち、海運業の運営
方法を変えつつあるのが現状である。CMA-CGM（フランス）、Maersk、Stena Line
（スウェーデン）
などの海運会社は、AI支援技術を導入して、船舶の性能をより深く理解するようになっており、
老舗企業と新興企業の両方がAIの限界を押し広げる新しい方法を見つけている。
（オ）購買テック（小売り）
分野での利用Target Corporation（米国）は、
機械学習・AIを使用してビジネスプロセスを改善し、顧客満足度を高めることに早期から取組んでいる。
彼らは新しいAIアプリケーションとアルゴリズムに取組み、顧客の満足度を上げることで販売を促進することを目指している。独自の商品カテゴライズと顧客のショッ
ピングパターンとのAIによる分析と学習を行う。
同社は2014年から小規模なテクノロジー企業を買収し、また他のAI企業と提携して、常にAIソリューションを革新、向上させている。
フランスのスーパーマーケット大手CarrefourもまたAIの導入を積極的に行っている。
注目されたの販売、在庫、顧客行
はAiFi＊54のナノストアをベースにした食料品店でのレジなし購買システムを導入し、動に関するAiFiの分析を利用して、
リアルタイムプロモーションや新商品のプロモートをテストしている。
目指しているのは店舗とオンラインショッピングのメリットを一つにして、これまでにない体験を目指している。Amazon Go とWalmart IRLの両者を合わせた体験を受けられるとのことである。
＊55
は、AIとロボットを駆使した最先端の顧客満足向上センオンライン食料品大手のOcado（英国）ター（中央集約型倉庫／以下、CFC）と精緻な宅配システムを独自に確立し、英国ネットスーパー業界でもっとも早い成長スピードを誇る企業である。
毎日58万人に顧客サービスを行っており、
そのため絶
えず、
効率的、
生産的、
そして競争力を持つために技術革新を進めている。
現在のその中心は機械学習を主体とするAI強化によるものである。Ocadoの倉庫は完全に自動化されており、そのためのピッキン
＊ 53
＊ 54
＊ 55

 aersk Remote Container Management
M
（RCM）
:
<https://www.maersk.com/supply-chain-logistics/captain-peter/services>
https://aifi.com/
https://www.ocadogroup.com/about-us/what-we-do/how-we-use-ai

270 DX白書2021

タ、
機械学習、AI…これらをどう使うべきかを具現化している。
コンタクトセンターはすでに顧客サービスの改善に成功しており、現在はGPUを搭載した機械学習とコンピュータービジョンを従来のバー｜第 ４ 部｜第 ２ 章｜

グロボットを自社開発したことでも有名である。
倉庫は一言でいえば、IoT、
ロボット工学、
ビッグデー

コードシステムに置き換えて、ピッキングプロセスを迅速化し、注文の精度を向上させている。イオン（カ）製造業での利用
製造業では、
常に効率性を上昇させて高い品質を追求しながら作業に取組む必要がある。
たとえば作
業ミスが発生している現場では、より厳格なチェック、指導体制を強化することが急務となる。しかし恒常的な人材不足との関係もあり、これらの体制が十分に機能していない例は少なくないのが現状である。
BMW Group（ドイツ）はAIを使用して、進行中の生産ラインを評価し、標準からの逸脱をリアルタイムで発見している。
人間の経験と洞察、そしてAI技術を組み合わせることで、コストを削減しながらマージンを保護できる新しい手法を確立しつつある。
これは現在の厳しい経済状況の中でも、成長し続けるという課題に対応するためにも有効に働いている。
Nokia（フィンランド）は、製造プロセスに不整合がある場合に、機械学習を使用してアセンブリオペ
レーターに警告するビデオアプリケーションを導入している。フィンランドのオウルにある自社の工場の一つで、機械学習を使用して組立ラインプロセスを監視するビデオアプリケーションを立ち上げている。このアプリケーションは、画像解析の結果からプロセスの不整合をオペレーターに警告して、問題をリアルタイムで修正できるようにする。
彼らは5G環境により600㎞離れたオフィスであってもリアルタイム処理が可能なことを証明している。Nokiaでは、自社での使用にとどまらず、リアルタイムで集められる情報を統合して、さまざまな解析・分析を行うSpaceTime scene analytics＊56というサービスを外部に提供している。
また、競争の激化によって複雑な業務プロセスでの稼働が増え、ミスが多発するような状況が生まれ、結果として生産性の低下を招くことになっている。General Motors
（GM、
米国）
は、
Autodesk（米国）と協力して、
機械学習技術による生成的設計アルゴリズムを実装し、設計の制約を考慮に入れつつ最適化された製品設計を可能にしている。CAD設計環境内に制約最適化ロジックをいれることで3Dプリンタによるラピッドプロトタイピングを可能としている。
制約条件内で機能要件、
材料、
製造方法、
およ
びその他の制約の定義を行うとAIが製品設計を行う。2018年5月からGMでは、積層造形の設計部品に対して、重量やその他の主要製品基準を最適化するために、Autodesk Generative Design（図表42-38）を採用している。
実際にシートベルトブラケットパーツのプロトタイピングでテストした結果、元のコンポーネントデザインよりも40％軽量で20％強力な単一ピースのデザインが可能になり、その有効性を確認した。

＊ 56

https://www.nokia.com/networks/solutions/spacetime-advanced-analytics-technologies/
DX白書2021 271

データ利活用技術が独自の次世代ネットスーパーを立ち上げるためにOcadoの子会社と提携したことでも有名である。

図表42-38

GMのAutoCAD利用のGenerative Design

出典：general-motors-generative-desig＊57を基にIPAにて作成製造業の現場においてもAIは期待されており、生産性の向上や安全性の確保といった具体的な成果が挙げられたことで、製造業における諸問題に解決の兆しが見えてきている。

（4）まとめ（ア）総論
事例紹介からわかってくるのは、単独の機能をAI化するだけではなく、複数機能を組み合わせること
で自社の問題点を克服、強みに変えることがかなり進んでいるということである。COVID-19に関する
ワクチン開発で早期に実用化につながったPfizerとModernaはどちらもAIを活用することで異例の速さでの研究開発そして実用化を行った。mRNAといういわば情報そのものをワクチンとして利用するという、これまでにない種類のワクチンを採用したことでAI導入が加速したと考えることもできるだろう。両社ともクラウド環境を利用し、最新の環境で最新の解析方法を使用し、そしてデータのデジタ
ル化によって人手を介することなく圧倒的な高速化によって実用化にこぎつけた。COVID-19に揺れる世界においてAIとデジタルデータの活用が史上かつてない速さでのワクチン開発につながったのである。
PfizerにしろModernaにしろ、COVID-19のためにAI基盤を作り上げていたわけではなく、むしろ日常業務のためにAI基盤を作り上げてきている。Pfizerは、
医療クエリー、
これは米国の複雑な保険と関係しており、
この業務にとられる時間と人手が根本的に問題であると考えその大幅な削減に取組んだ。
なぜならこの手間と時間が臨床実験の結果そのものに大きな影響を与えるためであり、SaamaとともにAIの活用に取組んでいた。ModernaはmRNAを社の主軸の一つとしていたこともあり、mRNAの
自然（タンパク質）情報の効率的な利用法という目的から元々一貫したデジタル基盤上での創薬を目指していた。
今回のCOVID-19では、その日常での意識改革がそのまま早期実用化をもたらしたといえる。
両社ともBERTを含む最先端のAI、機械学習技術を使用しており、そのためクラウドを使用している＊ 57

 eneral-motors-generative-desig
g<https://www.autodesk.com/customer-stories/general-motors-generative-design>

272 DX白書2021

進化しつづける環境を作り上げることが重要であろう。

｜第 ４ 部｜第 ２ 章｜という共通点も興味深い。
自分たちの課題、
強みを整理し、AIまたは他の先端技術を利用しながら常に（イ）今後の展望にNEDO（国立研究開発法人新エネルギー・産業技術総合開発機構）
から出されたアクションプラン＊58
を紹介する。
政府はこれまでも2017年に「人工知能技術戦略及びその産業化ロードマップ」、2019年の「AI戦略
2019」、科学技術・イノベーション基本計画や統合イノベーション戦略でAIに多数言及しており、AIの研究・実装を積極的に推進している。
海外では、アメリカは2026年までに320億ドル（約3兆5,000億円）を各分野のAI技術開発に投じ、中国も最新の5カ年計画に向けて新世代のAI開発を標榜している。民間ではGAFAM（Google、Amazon、Facebook、Apple、Microsoft）は画像認識や自然言語処理などに膨大なデータと巨費を投じており、各国政府や巨大企業がこれまで以上にAIに注力している。
米国、
中国はAI関連技術に輸出制限を課し、EUはAIの利用についての包括的な規制案を発表するなど、規制・管理面の取組も活発化している。
こうした情勢を踏まえ、NEDOは、新たなAI技術戦略の策定およびプロジェクトの早期開始に向けて、日本がAI分野で世界をリードしていくためのAI技術やAIに密接に関係する技術、さらにAIを含む新技術に関する開発の方向性などを大局的に検討・整理した
「人工知能
（AI）
技術分野における大局的な研究開発のアクションプラン」（以下、AIアクションプラン）
を策定・公表した（図表42-39）。
AIアクションプラン策定委員会（委員会）
では、AIを積極的に活用すべき分野として、農業などの第一次産業も含めた「ものづくり（生産）「」生活・都市」「モビリティ」「教育」「健康（ウェルビーイング）
」
な
どを掲げ、
「期待される社会像」を描いたうえで「社会像に向けた取組」
を整理し、期待される社会像に向けて12の「取り組むべきAI技術開発」を抽出したのが、AIアクションプランである。
本章にヒントとなる技術例が示されているものもあり、今後の方向性を見定めるための視点となるだろう。
たとえば意味
理解のAIでは「記号推論と深層学習の結合による意味理解のためのAI」「深層強化学習の新たなアーキ
テクチャの創出」
が、提案されたAI技術となる。
演繹と帰納の融合として「シミュレーション×機械学習（演繹＋帰納）の方法論の確立」「分子設計のためのAI」、全体最適化/人とAIの関係性多様化として「製
造プロセス全体を最適化するAI」「人の学習工程の解明とAIによる学習支援」「人体の個人別モデル化（ヒューマンデジタルツイン）」、スモールデータ駆動として「脳の活動の研究によるメタ認知を備えたAIの開発」「転移学習技術の確立」、
そしてモダリティを統合した環境認識として「多品種少量生産の効率化に向けたAI技術の開発」「無人搬送車（AGV）などのための環境認識技術の精度向上」「多様な情報から医師に選択肢を提示できるAI」が提案された。
これらの技術を横串に、積極的に活用すべき分野を縦串に描いたものがアクションプランの図となる。

＊ 58

 EDO 人工知能（AI）
N
技術分野における大局的な研究開発のアクションプラン
<https://www.nedo.go.jp/news/press/AA5_101439.html>
DX白書2021 273

データ利活用技術

AI技術の展望として、我が国の社会課題の解決に資する人工知能技術開発の方向性を提起するため

図表42-39

NEDOアクションプラン
AIを積極的に活用すべき分野

ものづ
くりAIの技術開
発の方向性

生活
都市

（生産）

深層学習

意味理解のAI

シミュレーション

演繹と帰納の融合

モビリ
ティ

教育

健康

（ウェルビー
イング）

記号推論と深層学習の結合による意味理解のためのAI
深層強化学習の新たなアーキテクチャの創出

シミュレーション x 機械学習（演繹 + 帰納）の方法論の確立

分子設計のためのAI

部分最適化

全体最適化／人とAIの関係性の多様化

ビッグデータ依存

スモールデータ駆動

製造プロセス全体を最適化するAI

人の学習工程の解明とAIによる学習支援人体の個人別モデ
ル化（ヒューマン
デジタルツイン）脳の活動の研究によるメタ認知を備えたAIの開発

転移学習技術の確立

画像・音声など、個別の認識精度の向上

モダリティを統合した環境認識

取り組むべきAI技術開発

これまで

多品種少量生産の効率化に向け
たAI技術の開発

無人搬送車(AGV)などのための環境認識技術の精度向上

多様な情報から医師に選択肢を提示できるAI

今後10年間
出典：人工知能（AI）
技術分野における大局的な研究開発のアクションプラン＊58

コラム

AI倫理とは何であるべきか？
札幌市立大学理事長・学長中島 秀之

AIシステムの能力が上がり、人事考査、融資

るが、問題にすべきは「何が悪いことなのか」での可否などの判断までに進出している。そうある。これは簡単には定義のできない問題であなってくるとAIシステムは正しい判断をしてる。以下ではAIの倫理について、どうあるべきいるのか？ということが問題になり始め、シスかについて議論を展開する。

テムの動作の健全性や、システムの使い手が最初に断っておくが、筆者は倫理学の専門家

悪用しないことを保証するという要求が出てではない。ここでは倫理そのものを議論するのくる。また、アメリカではAI兵器の開発も進んではなく、AIプログラムが正しく作られ、正し

でおり、その使用に歯止めをかける必要があく使われるための条件を考えたいのである。

る。そのため「AI倫理」の議論が世界的に盛んになっている。日本でも人工知能学会の倫理委

IBMは2014年以来、Everyday Ethics for Artificial

員会などで議論されている。それ自体は大変好Intelligenceという冊子を公開している。中身はましいが、基本的に「悪いことをしてはいけな

以下の項目になっている（2019年版、日本語の説い」という主旨になっている。倫理とは「正しい

明は筆者の意訳）。

こと」の判断基準であるから、それは当然であ・Accountability: 開発者はAIのデザインから

274 DX白書2021

ただし、自分たちで倫理を規定するのでは・Value Alignment: AIはユーザーの規範や価なく、その決め方を議論している点が特徴的で値に沿ったものでなければならないある。倫理というのは人間の本性に深く根ざしているから、誰かが決めれば良いというもので間にとって理解可能でなければならない

はないという認識が感じられる。また、将来の・Fairness: 判断のバイアスを最小化しなけれ問題として自律兵器の枠組みの見直し、AGIばならない
・User Data Rights: ユーザーのデータ利用の権利を守らなければならない（Artificial General Intelligence）とASI（Artificial
Super Intelligence）、感情計算、混合現実（mixedreality）などにも触れている。

人工知能学会が2017年に発表した倫理指針も似たような感じで、人工知能学会員（つまり筆者はAI倫理として、もっと具体的な指針作り手）への要請として以下の項目を列挙してと、そのための議論が必要だと考えている。例いる。

としてアシモフのロボット3原則が参考にな

1 人類への貢献、2 法規制の遵守、3 他者のプライバシーの尊重、4 公正性、5 安全性、
6 誠実な振る舞い、7 社会に対する責任、8
社会との対話と自己研鑽、9 人工知能への倫理遵守の要請る。これは倫理というよりは行動指針であるが倫理の具体化と見ることもできる。
第1原則：ロボットは人間に危害を加えてはならない。またその危険を看過することによって、人間に危害を及ぼしてはならない。

どちらの倫理規定もメタレベルであり、至極第2原則：ロボットは人間に与えられた命令当然と思うものばかりである。すなわち「正しに服従しなくてはならない。ただいことをしましょう」としか言っていない。もし、与えられた命令が第1原則に反う一つの疑問は、これら（項目9以外）はAIに特する場合はこの限りではない。

化したものではないということである。すべての人間にも通じる倫理指針ではないか？
IEEEはEthically Aligned Designという概念

第3原則：ロボットは第1、第2原則に反するおそれのない限り、自己を守らなけ
ればならない。

をWeb公開（初版は2017年、2019年に第2版）して、一般に議論を呼びかけている。これは自律

これらの原則は小説内では具体味を帯びて知能システムが人間の幸福を優先することを使われているが、ロボットの設計に組み込むに目的としており、項目としては以下のものがあ

はまだ抽象的で実装可能性は怪しいものであげられている。

る（人間の危険の予測だけでも実装困難）。それ・Human Rights: 人間の権利を侵害しないでも、少なくともIBMや人工知能学会のものよ・Well-being: 幸福指標を優先するデザインとり具体的である。

利用・Accountability: デザイナーとオペレーターが責任を持つ第1原則に近いものであるが、筆者は「AIは人の生死の判断をして良いか？」ということを考え続けている。
第一感としては「不可」
だと思う。

・Transparency: 透明性を持った動作

医療の場合だと、せいぜいが医師の補佐として・Awareness of misuse: 誤用リスクの最小化

提案をするぐらいで、判断は人間の医師が行う

DX白書2021 275

データ利活用技術

・Explainability: AIの意思決定プロセスは人｜第 ４ 部｜第 ２ 章｜

アウトカムまでの全プロセスに責任がある

というものであろう。

めた場合に、男性が出てくる確率が高い一方、

しかしながら、トリアージ（災害医療等で、大「看護師の写真」
は女性になりがちである。
「犯罪

事故、大規模災害など多数の傷病者が発生した者」に黒人が結びつけられたことも問題になっ際の救命の順序を決めるもの）が必要な場面をた。これらのバイアスは人間の判断にも存在す

考えると、大量の怪我人に対して迅速な判断がる。データに存在するバイアスをどう扱うべき求められる。このような場面でロボットが自律かということは自明ではない。逆バイアスをか的にトリアージを行うということは認められけて確率を同じに揃えれば良いとも限らず、逆ないであろうか？ロボットに様々なセンサを差別につながるかもしれない。もっと議論が必装備することにより、人間よりは適確な判断を要である。

高速に下すことができるはずである。筆者はこ

なお、この問題に関しては人工知能学会、日の問題に対して明確な答えは持っていないが、本ソフトウェア科学会、電子情報通信学会が共そのような議論が必要なのだと考えている。

同で2019年暮れに「機械学習と公平性に関する

AI兵器の使用を不可と宣言することは簡単で声明」を出している。
「機械学習は道具にすぎまあるが、軍事国家に対して現実的な効力は持たせん」というメッセージが印象的である。道具ないであろう。彼らは自国の兵士が死なないこという認識なしに機械学習の結果を全面的にとをメリットとしている。敵国に対する使用を信用することにより問題が拡大されているよ

制限するためには使用条件などに関する緻密

うに思われる。

な議論が必要である。

すべての場面に通用する倫理基準を作ることはまず不可能であろう。人間の倫理観も文化

また、最近問題になっているのは、データのによって多少異なっており、できるだけ具体例

偏りにより、機械学習の結果が統計的には正しに即した議論が必要だと感じている。具体化しいものの、政策的には望ましくない場合がある

たレベルでは差異が小さくなるし、その差異をということである。たとえば「医師の写真」を求追求することも容易になる。

3 IoT技術（1）背景
現在、世界中で未だ収まらない新型コロナウイルス感染症の感染拡大への対応や、深刻化する環境問題の解決に向けた環境負荷軽減、
激しく変化する顧客ニーズへの対応が企業に求められている。
国内に目を向けても、
少子高齢化およびそれに伴う人口減少への対応や働き方改革の推進など、外部環境の変化は著しい。
今後も絶えず変化する外部環境に適応するため、企業はデータを収集・分析し既存事業の改善や新規価値創造に取組んでいる。このようなDXの潮流が強まる中、データ利活用の基盤となるデータ獲得手段として、IoT（Internet of Things: モノのインターネット）の重要性がいっそう高まっている。

276 DX白書2021

IoTとは、
インターネットなどのネットワークにコンピューター類のみならずセンサーやカメラ、工
作機械や家具などさまざまな物が接続され、データを収集したり相互に情報をやり取りしたりするこ
スマートウォッチなどがあげられる。
スマートフォンやスマートウォッチを用いて、外出先から家電を操作したり、心拍数や運動量を計測してアプリで分析したり、自宅の機器、家族やペットの現在の状態を確認したりといったことは今日では珍しくない。IoTは、離れた場所にある多くのデバイスが生成するデータをリアルタイムで取得することを可能としたのである。IoTは消費者向けサービスだけでなく産業でも活用されている。AIやデジタルツインなど、高度化するデータ分析・シミュレーション技術の基盤となるデータ収集技術として、企業の規模や業界を問わず国内外で導入が進んでいる。
IoTの活用において、工場内の生産設備や製品の状態の収集のように、業務プロセスの中でIoTを用
いて生産性向上や業務プロセスの最適化を図る場合と、IoT家電のように製品をインターネットに接続して利用状況を把握するなど、製品・サービス改善による顧客価値向上のために情報収集を図る場
合について以下で紹介する。
生産性向上や業務プロセスの最適化を目的とした活用の場合、生産物や設備の状況、周辺の環境などのデータをセンサーで取得し、通信を介してIoTゲートウェイやプラットフォームなどを経由したのち、クラウドや中央のサーバーでデータの分析・シミュレーションを行うというシステムが一般的である（図表42-40）。IoTを用いることで、企業は大量のデータを取得可能になる。
取得した大量のデータに対し、AIなどのデータ分析技術により高度な分析・予測・シミュレーションを行うことで、コスト削減・生産性向上に寄与することができる。
最近では、製造業・農業・医療・建築・流通といった幅広い業界でIoTが活用され、業務プロセスの効率化や製品品質の向上といったビジネス上の価値を産みだ
している。
また、
機器がネットワークに接続することで、データを収集できるだけでなく、異常発生を予測して機器を停止するなど、データから得られた知見に基づいて、離れた場所から機器をリアルタイムに制御・操作することも可能になる。データの分析結果をすぐさまフィードバックする場合には双方向性が重要となる。
製品・サービス改善による顧客価値向上を目的とした活用の場合は、製品にIoTセンサーを搭載し、製品の状態や、
顧客による製品の利用状況・利用頻度などのデータを収集する。
得られたデータを分析することにより保守サービスの品質向上や各顧客向けにカスタマイズしたサービスの提供が可能となり、顧客への提供価値を向上させることができる。
近年、顧客の行動や従業員の判断など、ヒトに関する
データが収集対象となっていることは重要なトレンドである。
新型コロナウイルス感染症の拡大後、
都心部の人流データが盛んに報道されるようになったように、個人の端末を経由してデータが収集されている。ウェアラブル端末などから取得した健康状態のデータをもとに個人の生活習慣の改善を勧めるといった医療・ヘルスケア業界の例のように、企業の顧客データなどから得た知見を個人にフィードバックし、
助言・注意を行うIoTの使い方も注目されている。
なお利用目的によらず、企業内部の重要なデータや、
顧客・利用者のプライバシーに関わるデータを収集する場合には、IoTに求められるセキュリティとプライバシー保護の水準が高まる点に注意が必要である。

DX白書2021 277

データ利活用技術とを指す。身近な消費者向けの活用例としては、ネットワークに接続した家電やスマートスピーカー、｜第 ４ 部｜第 ２ 章｜

（2）技術概要

図表42-40

IoTを活用したシステムの模式図

農地や広い倉庫などではセンサーネットワークを活用

IoTノードで集約
ゲートウェイ
で送信
IoTプラットフォーム
で集約・分析

工場や店舗など構内ではローカル5GやWi-Fiを活用

ユーザー企業基地局で中継屋外などではLTE, LPWAなど
長距離通信を活用

ユーザー企業が構築するケースのほか、
民間事業者がセンサーからIoTプラット
フォームまで提供するケース、データ分析
はAI企業が行うケースなど多様である

通信技術やプラットフォームなどのIoT構成要素の発達によって、IoTによって取得できるデータのリアルタイム性は大きく向上している。
即時にデータを得られるようになったことで、精密さが要求される遠隔手術・建設機械などの遠隔操作や高度な自動運転など、これまでは実現が難しかったサービ
スや製品が実用化されることが期待される。
図表42-40で示したような、IoTの各構成要素の発達によって、IoTはより洗練され、高品質・低価格になっている。
センサーの小型化・高精度化・低価格化・高性能化、コンピューティング処理能力の向上・低廉化やストレージの可用性向上などによってもたらされたプラットフォームの進歩の影響などにより、IoTが活用される場面が増加している＊59。
ここではIoTの構成要素の進歩の中でも、近年とりわけ注目を集めている5G・ローカル5G、
エッジコ
ンピューティングおよびデジタルツインについて述べる。
1）5G・ローカル5G
5Gとは、第5世代移動通信システムの略であり、①超高速通信（eMBB: enhanced Mobile BroadBand）、②超低遅延通信（URLLC: Ultra Reliable and Low Latency Communications）、③多数同時接続（mMTC:
massive Machine Type Communications）の3項目のうち、利用シーンに対応した項目について、定められた要求値以上の性能を持つネットワークが5Gネットワークと定義される。図表42-40における、IoT
デバイスとIoTゲートウェイ間のネットワーク、ないしは広域ネットワークの部分における先端技術である。
5Gに関して、
スマートフォンでの利用を想定したコンシューマー向けの話題を耳にすることが多い
が、産業においても、上記定義の①の性質により映像などの大容量データを高速に伝送する、②の性質
により遠隔操作などをよりリアルタイムに行い安全性を高める、③の性質により膨大な数のセンサーからのデータを収集できるようになるなど、多くの面でメリットがある。
我が国における産業・社会を日本国内でも通信各社を初めとして、5Gネットワー
支える基盤として5Gへの期待が集まっており＊60、
＊ 59
＊ 60

デロイトトーマツコンサルティング「Tech Trends 2020 日本版」
総務省「令和 2 年版 情報通信白書」

278 DX白書2021

また、
日本国内では事業者向けの制度としてローカル5Gもスタートしている。
これは通信事業者による全国向け5Gネットワークサービスとは別に、地域の企業や自治体などのさまざまな主体が工場内・｜第 ４ 部｜第 ２ 章｜

クの敷設が進められている。

施設内・地域内など限定されたエリアにおける5Gネットワークを構築する仕組みである。
無線局とし
トワークゆえに他の場所の通信障害などの影響を受けにくいなどのメリットがある。スマートファク
トリー・スマートシティなど、多数の機器をネットワークに接続する必要があるケースにおいて、
とりわけ活用が見込まれている。
図表42-41

5Gとローカル5G
構築・運用の主体（全国）
５G

ローカル5Gエリア

セキュリティ

ユースケース例

特定の通信事業者

全国を対象に通信事業者各社が敷設エリアを拡大中

4Gをベースに強化

コネクテッドカー
遠隔診療

無線局免許を取得した
各事業者・自治体

敷地内・建物内など限られた範囲

5Gのセキュリティ水準に加え、独立したネットワー
ク故に外部からのアクセスリスクが低いスマートファクトリー
自動農場管理建機遠隔制御2）エッジコンピューティング
エッジコンピューティングとは、収集したデータの処理をすべてサーバー上（クラウド上）で行うのではなく、データを収集した末端のIoT機器やその近辺（エッジ）で行う方法のことである（図表42-42）。
データをクラウド上で集中処理するクラウドコンピューティングの対義語だと考えると理解しやすいであろう。
図表42-42

エッジコンピューティング
エッジコンピューティング

クラウドコンピューティング
クラウド

クラウド

（処理）

（蓄積・追加処理）
フィードバック

取得データ

抽出した
特徴データ

画像処理により人の特徴から
商品をおすすめスマートスピーカー

インフラ監視電気・ガス検針

物流管理

統合分析に基づく
システム更新など
エッジ（処理）
統計
・表示

不良品検知
・故障予知
フィードバック

画像取得
生体データ
計測

生産監視

DX白書2021 279

データ利活用技術ての免許を取得し、5Gの定義に則り使用用途に応じて必要となる性能を柔軟に設定可能、
ローカルネッエッジコンピューティングを用いる主なメリットは2点挙げられる。
1点目のメリットは通信に伴う遅延を低減してリアルタイム性を改善したり、
インターネットやクラウドの障害時でも処理を継続したりできることである。自動運転など、末端のIoT機器周辺の環境に対する即時制御が必要とされる場面での利用が期待されている。また、5Gと組み合わせることで、IoTデバイスとエッジサーバー間の通信遅延も軽減し、全体として遅延を小さくすることができる点も重要である。
2点目のメリットはエッジで生データを処理し、安全または必要なデータのみをサーバーへ送信する
ことで、セキュリティを高めたり、
通信データ量を軽減して通信コストやストレージのコストを下げたりできることである。近年注目を集めている、ヒトに関するデータ収集においては、個人の行動履歴や個人の外見の画像など極めてセンシティブなデータを収集するケースも少なくない。
したがって、
エッジでの匿名化・暗号化といったデータ処理によるセキュリティの向上がより重要になっており、エッジコンピューティングの活躍が期待されている。
3）デジタルツイン
デジタルツインとは物理空間
IoTと密接な関係にある技術として、
デジタルツイン＊61が挙げられる。
に存在するモノやヒトを仮想空間上に再現したもの、あるいはそれを活用したシステムを指す（図表4243）。
デジタルツインは、
シミュレーションに用いられるほか、3Dモデリング技術を活用し、目で見てわ
かりやすい形での可視化に用いられる場合もある。
工場生産ラインの変更や都市計画など、
実空間で実物・模型を作成してシミュレーションし、試行錯誤を重ねるには多大なコストや時間が必要となる場
合がある。そこで仮想空間上に作成したデジタルツインを用いてシミュレーション・分析・最適化を行い、その結果を物理空間へフィードバックすることで、コストや時間を短縮し、設計や生産などの効率化・改善が可能となる。時間とともに変化する対象や環境の状態を仮想空間内のデジタルツインに反映する際に、物理空間からのデータ収集が必要となるため、IoTセンサーによるデータ収集が必要不
可欠である。
図表42-43

デジタルツイン仮想空間のモノ・ヒト＝「デジタルツイン」

物理空間のモノ・ヒト

データ収集・モデル化・再現

IoT

シミュレーション・分析・最適化

フィードバック＊ 61

 い概念として物理空間と仮想空間が緊密に連携したシステム全体を指すサイバーフィジカルシステム
近（Cyber Physical System: CPS）があり、デジタルツインとほぼ同義で用いられることもある。

280 DX白書2021

などの内面の双方がデジタルツインの対象として研究されている。前者は医療・ヘルスケア業界での活用が見込まれており、現在では心臓など一部の臓器のデジタルツイン化プロジェクトが進められて｜第 ４ 部｜第 ２ 章｜

また、近年ではヒトのデジタルツインの作成も試みられている。生体組織としての人体、意識や思考いる。
後者のヒトの内面のデジタルツインとは、ヒトが行う判断や思考を個人差も含めて再現する試み
ツインに助言をもらったりするという使途が想定されている。現時点ではこのような活用は研究段階であり、実用化にはまだ遠いと考えられるが、実現した場合の社会への影響は大きいであろう。

（3）事例・導入プロセス
1）事例
IoTは、
センサーから得られた情報を可視化するシンプルな活用から、予測・最適化といった知的な処理まで行う技術的に高度な活用まで、幅広い事例が存在する。本項では、（ア）可視化、（イ）ITとOTの連携、（ウ）AIを用いた分析・予測、（エ）デジタルツインの四つのIoT活用法について、事例を紹介する。
（ア）可視化
製品のIoT化により製品状態を可視化し、サービスの向上を行った事例として、アクア株式会社
（日
本）
による、
コインランドリーのIoT化が挙げられる。
各店舗の洗濯機の稼働状況をIoTによって可視化
し、店舗および本部による機器の管理やメンテナンスに活かすとともに、稼働状況を顧客からもweb上で確認できるようにすることで、近隣の店舗に洗濯機の空きがあるかを来店前に確認したり、自分の洗
濯の終了時刻を手元のスマートフォンから確認したりできるようになった。
この事例では、待ち時間の短縮という顧客への価値提供と同時に事業者側の運営の効率化を行っている。
また、近年、感染症の拡大、事故や自然災害、貿易摩擦など、調達に大きな影響を及ぼすリスク要因は多く、予測不可能な事態に対し、迅速に影響を把握し供給を安定させられるようなサプライチェーン
マネジメントが求められている。
そのため、
流通業、
小売業、
製造業、
農業などにおいて、
サプライチェー
ンの可視化・効率化のニーズが高まっている。こうしたニーズに応えるため、IoTを利用することにより、製品やコンテナの状態・位置を追跡し、盗難の防止、保管状態の監視、
サプライチェーン上の中継地点への到着時刻予測、ルート計画の改善などにつなげ、運送を効率化しつつサービスの質を高める事例も増えてきている＊63。IoTによる追跡・監視をサプライチェーンの可視化に役立てた事例として、
海上での石油掘削場からガソリンスタンドに至る
Rockwell Automation（米国）の事例が挙げられる＊64。
まで、数百キロメートルにも及ぶサプライチェーンから自動でセンサーデータを収集・統合・構造化し、リアルタイムな洞察、予測や予防保守が可能になっている。

＊ 62
＊ 63
＊ 64

NTT デジタルツインコンピューティングセンタ <https://www.rd.ntt/dtc/>
BLUME global: How the Internet of Things Is Transforming Supply Chain Management <https://www.
blumeglobal.com/learning/internet-of-things/>
Microsoft Customer Story-Fueling the oil and gas industry with IoT <https://customers.microsoft.com/enus/story/fueling-the-oil-and-gas-industry-with-iot-1>
DX白書2021 281

データ利活用技術

将来的にはデジタルツインが本人の代理として会議での仮判断を行ったり、故人のデジタルである＊62。

（イ）ITとOTの連携
生産機器の制御に代表されるOT（Operational Technology）領域もIoTプラットフォームに連携されるようになりつつある。この潮流は以前から存在したが、新型コロナウイルス感染症の感染拡大によって、稼働状況を遠隔監視する取組の需要が高まり、統合が加速している。Daimler Trucks
North America（米国）の事例では、Cisco Systems（米国）およびRockwell Automationと提携し、PLC（Programable Logic Controller）などからなるOTシステムとITシステムを統合した。
工場での生産を中断することなくシステムを移行し、部品管理の改善やダウンタイムの低減に成功した。
この事例のようにOTとITの統合を図り、さまざまな機器を一括で管理するプラットフォームも使われ始めている。
これまでOT環境はインターネットなどの外部ネットワークから切り離されていた。しかし、OT・ITの統合においては、OT環境が外部のネットワークと接続されるため、セキュリティの確保は非常に重要となる。また統合に際しては、最新の脅威に対応することが求められるITと、安定して稼働することが優先されるOTとの文化の違いも大きく、注意が必要である。
（ウ）AIを用いた分析・予測
AIを用いてIoTから取得したデータを分析し、予測や最適化を行ったり機器へのフィードバックを行ったりすることで、製品品質の向上や障害の予防などの効果が見込まれる。収集データの可視化による現在の状況の把握に加え、AIなどの活用により未来の状況を予測できるようになったという点は重要である。取得・蓄積したデータを適切に処理し、企業内外で共有することによる価値創出も期待されている。
AI技術の発達により、これまでは計算機での分析が難しかった画像や音声などのデータの活用が可能になったことで、IoTセンサーによってこれらのデータを収集する事例が増えている。たとえば、製品の異常や人の危険な行動（危険な機械への接近など）の検知などを目的とした画像処理に用いる入力
画像の取得において、IoTが活用されている。ASUS（台湾）
は、自社が取引する数百のサプライヤーの製造品質の改善・業務効率化のため、高精度で機械部品の欠陥を検出する自動光学検査や、ファンの回転音の波形分析による品質検査といったAIとIoTを組み合わせたソリューションをサプライヤーへ提供している。
小売やヘルスケア分野にもAI・IoTソリューションを展開するほか、自社工場のスマート化も進めており、AI・IoTを組み合わせた取組が十分な成果を上げていることが伺える。
リアルタイム性を高めることを目的とした、エッジでのAIの活用も始まっている。
たとえば、
高レベ
ルの自動運転において、車載カメラなどのセンサーから危険な状況を認識し、ブレーキなどの操作を自動で行う場合、操作開始は可能な限り早いことが求められる。このような場合、事前の学習によって生成したAIモデルを自動運転車に搭載し、データの送受信を介さずに状況認識・操作を行うことで応答を早め、安全性を高めることができる。
（エ）デジタルツイン
デジタルツインの活用は、製造業におけるスマートファクトリーでの活用を中心に広まりつつある。
工場内の機器・機械に加えヒトの情報も取り込んでデジタルツインを構築する取組も進んでいる。
日本国内では、キオクシア（日本）が四日市工場を中心にスマートファクトリーの先進的な取組を進めている。膨大なセンサーデータや検査計測結果を集約・構造化し、人の作業履歴や判断結果、文書と組み合わせてデジタルツインを作成している。AIを用いたデータ分析やシミュレーションによって、282 DX白書2021

生産性や品質の向上を見込んでいる。
2021年にはBMW（ドイツ）がNVIDIA（米国）と提携して、従業員を含む工場全体のデジタルツイン｜第 ４ 部｜第 ２ 章｜

不良になりそうな状態の事前検知・欠陥の原因特定に役立てており、その結果をフィードバックしてシミュレー化に取組んでいることを発表した＊65。NVIDIAのプラットフォーム“Omniverse”を活用し、向上が見込まれる。
工場のデジタルツインがスマートファクトリーの取組に用いられるのと同様に、都市のデジタルツ
インは公的機関と企業、大学などが連携したスマートシティの取組に用いられている。
シンガポールでは、政府関係機関によって、3D都市モデルと交通状況・エネルギー関連情報などを組み合わせ、都市レベルでのデジタルツインの実現を目指す「バーチャル・シンガポール・プロジェクト」
が2014年から始まっており、注目を集めている。国内では、国土交通省が主導するプロジェクト「PLATEAU」が進んでいる。
全国約50都市の3D都市モデルを整備・オープンデータ化して、モニタリングや防災シミュレー
ションなど、企業によるユースケース開発が進められており、新たなソリューション創出が期待されている。中国の杭州市では、市内に本社を持つAlibaba（中国）が主導的役割を果たしてスマートシティ化を推進し、渋滞緩和・治安向上といった成果を上げるなど、自治体や企業主導での取組も国内外で進んでいる。企業はこのようなスマートシティの取組を注視し、自社事業での活用や、取組への参画も検討していくべきであろう。
2）導入プロセス
本項ではIoTの導入プロセスにおける課題やIoT特有の注意点について述べる。
（ア）導入手法
十分な人材・予算の確保が難しい場合には、スモールスタートのアプローチが役に立つ。これまで取得していなかったデータの可視化を第一目標とし、一定の成果を出してからAIでの分析を試みるといった順序でシステムを拡張していくこととなる。
シンプルな構成であれば、センサーとシングルボー
ドコンピューターなどを活用して安価にIoTを導入可能であり、中小企業でも十分に活用が検討できる。
また、多くの業種・業界に向けてIoTプラットフォーム・ツールが国内外の企業から広く提供され、相互連携が進んでいる。IoTを導入する際、これらを活用することで、導入・運用コストや導入までにかかる時間を抑えられる可能性がある。
（イ）複合的技術であることによる導入・運用上の障害
図表42-40に示したように、IoTはセンサー・無線/有線通信・IoTゲートウェイ・IoTプラットフォー
ムなど、
複数の構成要素からなる複合的技術である。
それゆえに技術的な複雑さがプロジェクトの障害となることも多い。
たとえば、複数の構成要素のうちセンサーの設定など一部を変更した場合に他の部分で意図しない変化が生まれてしまう可能性がある。
運用中にIoTを用いたシステムに障害が発生した場合にも、その対応は容易ではない。
本白書の発行に先立って行った、
日米の企業を対象としたIoT導入
課題についてのアンケート結果（図表42-60）からは、米国ではこの点が主要なIoT導入課題として捉え＊ 65

NVIDIA GTC2021 Keynote <https://www.nvidia.com/en-us/gtc/keynote/>
DX白書2021 283

データ利活用技術

ションや機械学習によって工場のライン変更の効率化を可能にした。
今後、時間短縮や柔軟性・精度のられていることが読み取れる。
日本企業の回答率も低くなく、
今後IoTが国内でより普及するにつれて、
この複雑さが米国同様に導入・運用上の障害として顕在化する可能性がある。この問題を回避するため、各構成要素のテストだけでなく、連携するシステムも含めたシステム全体のテストを行うことが重
要である。
また、
障害発生時の対応や責任者についても、予め明確にしておくことが望ましいだろう。
（ウ）セキュリティ
先述のアンケート結果（図表42-60）
において、セキュリティ・プライバシーのリスクを課題と認識している日本企業の割合は16.9%と低いが、IoTの利用に際して、情報セキュリティは極めて重要となる。
IoTで扱う社内機密やプライバシーに関わる情報の流出のリスクがあるほか、外部からの攻撃の影響が医療機器や工作機械、自動車といった機器の制御にまで及んだ場合、人命に関わる事故を引き起こす可能性もあるためである。
たとえば、処理能力の都合上対策レベルを高くできなかったIoTセンサーなどのデバイスが攻撃を受け、そのデバイスから他の機器やシステム全体に影響が広がるといったケースが考えられる。
このようなケースに対しては、異常な状態を検知し、当該機器やシステムをネットワークから切り離すなどの対
セキュリティに関す策を事前に講じる必要がある＊66。IoT機能を搭載した製品を顧客が利用する場合、るアップデートを周知する、
遠隔でアップデートを行うようにするなど、
ユースケースごとに脅威分析を行い、各種ガイドラインなどを参照し適切に対策を行う必要がある。

（4）まとめIoTの構成要素や、関連するデータ利活用技術の進歩により、IoTが生みだす価値は高まっている。
AIの進歩により、データからこれまで以上の知見を得られるようになったことに加え、画像や音声など
これまで自動処理が容易ではなかったデータも積極的に収集されるようになった。現在のトレンドとして、
データ利活用においてヒトに関連するデータの重要性が増していることを見逃してはならない。
設備などのモノについてのデータに加え、従業員・顧客などについてのデータもIoTシステムによって収集され、デジタルツインを用いたシミュレーションやAIを用いた分析・予測に活用され、その結果が物理世界へフィードバックされて製品やサービスの改善等に役立てられている。
また、ヒトが感じ取った情報とセンサーが収集した情報とを組み合わせて活用する取組も始まっている。
今後、IoTセンサー
によって収集されたデータは、企業内での共有のみならず、企業間のデータ連携、社会的なシステム構
築へと用いられていくであろう。
データ利活用がいっそう重要となる今後の社会において、IoTはその基盤としてイノベーションを支えていくと期待される。

＊ 66

IoT 推進コンソーシアム・総務省・経済産業省『IoT セキュリティガイドライン』（平成 28 年）

284 DX白書2021

DX推進の困難とそれを乗り越えるための手法
北陸先端科学技術大学院大学 知識科学系 知識マネジメント領域 教授 内平 直志
る話だ。ITベンダーとユーザー企 業で、データやモデルの共 有について利 害 関 係 が 生じ、話

中堅中小企業でも使え、システムからビジネが進まないこともある。お互いの信頼関係がない

スモデルまでトータルにカバーしたシンプルと、ただでさえ不確実性が高いDXを進めてみよ

な設計方法論として「デジタルイノベーション

う、とはならない。
これらのギャップを埋めるためデザイン」を提唱している。企業がデジタルのには、対話ツール、
フレームワークが必要である。

活用によって得られる最大の価値は、すべてのデジタルイノベーションデザイン手法のフ

情報をサイバー空間で統合することにより、サ

レームワークは対話ツールの一つである。たとプライチェーン、バリューチェーン全体で起きえばロードマッピングでは、企業の中でDXがているムリ・ムダ・ムラを削減できることだと

5 ～ 10年先の将来どう展開していくかを共有考える。実空間でかかっていたコストがなくな

するが、第一人者であるケンブリッジ大学のり、制約によりできなかったことがサイバー空ファール博士はロードマップ自体が正しいか間で可能になる。
「DXによる新しい価値創出」

は重要ではなく、作成段階で関係者が議論し、と言われてもピンとこない中小企業も、DX

相互理解を深めることが本質だと言っている。

の目的は究極のムリ・ムダ・ムラの削減といわれれば理解できるのではないか。デジタルイ
ノベーションを推進する上での重要な点は「明

知識のデジタルイノベーションへの活用

確なデジタルビジネス戦略、リーダーシップ」

暗黙知と形式知をトータルに扱う知識経営「DXを推進する組織文化」「対象やフェーズごをベースにしている。最近の研究では、AIで得とに適したDX推進の仕組みづくり」「組織内外られる知識と人間の知識の協働がキーになるの知識の活用」
である。

と考えている。研究事例としては、プロジェク
トマネジメントにおいて、定量的な品質管理の経営者と現場の対話

分析をAIが行い、プロジェクトマネジャーに気づきを与えるものがある。過去の経験に根ざ

我々の研究において、ステークホルダー間のしたバイアスを補正することができる。また、

ギャップを
「情報
（形式知）
「
」経験
（暗黙知）
「
」将

IoTのデータ取得はモノだけではなく人にも広来認識」「評価基準」「利害」「信頼」の6つに整理しがる。人の気づきをスマートフォンを介して音た。これらのギャップがDXにおける本質的な声でクラウドにあげ、物理的なセンサーデータ

推進阻害要因であると考えている。

と共に分析する取組を行っている。たとえば、

経 営 者・DX推 進 部 門・現 場の間で、情 報、

農家は投資力が限られるためセンサーは簡易経 験 知 値、将 来 認 識、危 機 意 識 が 必 ずしも一的なものになり、人が見回ることも依然重要で致していない。現 場 部 門のキーマンをDX推 進ある。そこで、生育状況などに関する気づきを部門に派遣して欲しくても、抵抗されるのはよくあ

農作業者が音声で入力し、センサーデータを合DX白書2021 285

データ利活用技術

はじめに｜第 ４ 部｜第 ２ 章｜コラム

わせて分析する。高齢化が深刻な農業では、知識の共有・継承が課題となっているので、とてでIT活用体験をしている。
また、自社で成功したシステムを他社に展開も重要なフィールドといえる。

しているところも多い。

中堅中小企業でのDX推進

DX事例と整理軸

石川県で多くの中堅中小企業と交流する中注目事例としては、コマツ、日立建機、アクア

で、成功企業に共通するポイントは次の通りでなどがある。キオクシア（元東芝メモリ）は日本ある。まずはビジョンが明確で、それに基づいでも特に進んでいるスマートファクトリー事てAIやIoTを活用していること。従業員2 ～ 30

例であろう。デジタルイノベーションデザイン

人規模の企業では、全社が1つのチームとしてでは、成功事例を「①DXの提供価値の明確化

議論し、データは改善に直結し、「自分ごと」の（価値設計）「」②AI ／ IoTでどのように実現すDXとなっている。小規模企業ほどその感覚がるか（システム設計）「」③エコシステムの中で他共有されやすい。

者をどのように利用するか（戦略設計）「」④DX

次に、社長のITリテラシーが高いことであプロジェクト推進上のリスクを把握し対策する。社長が自らシステムを作ることも多くて驚るか（プロジェクト設計）」の4つの視点で分析・くほどである。社長が現場を理解し、要望をリ整理している。

アルタイムにシステムに反映し、高速にPDCAを回している。社長に共通するのは、二代目で、ポイントは、
どうやって困 難を乗り越えたか、

大学卒業後大手企業に就職し30代半ばくらい

困 難のパターンとその対 応の整 理である。コマで自分の会社に戻ってきていることだ。大企業

ツは有 名な成 功 事 例 であるが、話を聞くと「 世分析の4つの視点

286 DX白書2021

どのような成 功 事 例も困 難を乗り越えて成 功に人材の育成を、カリキュラムを設けて体系的に至っており、そこに学び がある。成 果 が 出ずに進めている。教育プログラムによる人材育成は止めてしまう企 業もある一 方 で、成 果 が 出るま重要であるが、個別企業が教育を行うのは難しで我慢して継続できたところが成功している。

い。北陸先端科学技術大学院大学の社会人大学院は有効な学びの場であり、第一線の社会人

人材育成について

中堅中小企業の工場の中においては、技術をどのように活用し、何ができるかを体感するとが会社の枠を越えて講義やゼミで議論できる。
そのような場において刺激を受け視野が広がる。リカレント教育の重要性を訴求していきたい。

取組が進む。ファクトリー・サイエンティスト

DX白書2021 287

データ利活用技術協会は、中小規模製造業でIoTデータを扱える｜第 ４ 部｜第 ２ 章｜間 で言われるほど 簡 単 ではなかった」という。

4 データ利活用技術の活用状況と課題
本項では、企業のデータ利活用技術に関する現状や課題を調査し、日米比較を行うことで、日本企業のデータ利活用促進のポイントを探る。

（1）データ利活用に関する技術
図表42-44は、データ利活用に関する技術の活用状況を尋ねたものである。ITシステムの開発手法・
技術（図表41-17）と同様、すべての技術において日米差は大きい。とくに顕著であるのが「データ整備ツール」
であり、「全社的に活用している」
が日本企業の6.8％に対して米国企業は50.1%と約7倍になっている。
第2部4章の「図表24-14 目的を把握したうえでのデータ収集」
や「図表24-16 専門的で高度なデータ
分析への取組状況」
でも明らかなとおり、
米国企業においては、経営や事業企画、営業や製造現場などあらゆる部門においてデータ利活用の文化が浸透しており、関連技術の利用率を押し上げている。
図表42-44

データ利活用に関する技術の活用状況
0

データ整備ツール

ETLツール

データレイクデータハブ

データカタログ

データ統合ツール

マスターデータ管理

IoT

デジタルツインローカル5G

ブロックチェーン

288 DX白書2021

20

14.3

日本（n=533） 6.8

15.4

8.4

米国（n=369）

20.9

日本（n=533）4.1

7.7

米国（n=369）
日本（n=534）4.1
米国（n=369）
日本（n=534）3.9
米国（n=369）
日本（n=534） 5.2
米国（n=369）

14.1

9.4

14.2

9.9

15.9

27.1
29.8

10.3

38.4

14.8

27.6

13.9

30.1
15.9

米国（n=369）

29.5

米国（n=369）

29.3

6.2

10.3

15.2

12.2

33.9

12.5

8.9

12.2

35.0

11.9

30.7
18.4
30.0

32.2

12.5

7.0

28.5

27.1

22.8
38.3

41.5

25.2

17.3

21.1

29.0

■全社的に活用している■事業部で活用している■活用していない■この手法・技術を知らない

12.2

8.4

17.4

11.9

10.6

11.7

28.3
21.7

50.0
26.8

8.7

35.7

50.1

15.4

10.8

32.2

20.3

30.4

20.6

7.0

11.4

22.0

38.0

18.7

28.0

34.5
25.5

25.7

（％）
100

34.3
19.2

29.5

31.7

17.4

1.9
日本（n=534） 6.2

16.3

24.7

日本（n=533） 6.2

1.9
日本（n=533） 3.8

20.3

38.5

26.3

33.1

米国（n=369）

80

36.4

15.2

米国（n=369）

2.1
日本（n=532） 6.8

60

38.8

日本（n=534） 11.6

米国（n=369）

35.6

50.1

米国（n=369）
日本（n=533） 6.8

40

8.1

11.7
26.6

20.9

13.0

10.0

■活用を検討している

後と、
米国企業
（1割前後）と比較して著しく高い。

｜第 ４ 部｜第 ２ 章｜

また、ITシステムの開発手法・技術と同様、日本企業は「この手法・技術を知らない」の割合が3割前

図表42-45は、データ整備・管理・流通の課題を尋ねたものである。
日本企業においては、
人材（「人材
国企業では、開発手法・技術の活用課題（図表41-19）と同様、「経営層のデータ利活用への理解がない」「経営層のデータ利活用への積極的な関与がない」「IT部門が最新のデータ関連技術に対応できない」といった経営者や組織の課題が上位に来ている。ただし、文化（「全社的なデータ利活用の方針や文化がない」）
に関しては日本企業の方が大きく上回っている。
日本企業の3割以上が本項目を課題として認識していることから、今後のデータ利活用に関する方針策定や企業文化の醸成に期待したい。
図表42-45

データ整備・管理・流通の課題（複数回答）
0

10

20

30

全社的なデータ利活用の方針や文化がない

16.1

29.3
20.8
19.8

経営層のデータ利活用への積極的な関与がない

23.3

IT部門が最新のデータ関連技術に対応できない
データを収集する仕組みがない

31.5

14.1

予算の確保が難しい

23.8

16.3

人材の確保が難しい

29.0

22.7

11.1

データ管理システムが整備されていない

41.5

14.1

既存システムがデータの利活用に対応できない

20.8

4.6
16.7

とくに課題はない
その他

37.1

24.1

経営層のデータ利活用への理解がない

（％）
50

40

24.4

1.5
■日本（n=533）■米国（n=369）

DX白書2021 289

データ利活用技術の確保が難しい」）が、後述のAI（図表42-54）およびIoT（図表42-60）同様、最大の課題となっている。米図表42-46は、データ分析（AIを含む）を実施するためのIT環境の整備状況を尋ねたものである。総じて日米差が大きい状況は他の設問と同様であるが、とくに「データ分析モデルを開発するための標準的なツール、フレームワークと開発プロセス」
については米国企業の半数以上が「整備している」と回答しており、「おおむね整備している」
を含めると75.9%に上る。
日本企業は各項目とも、「整備している」「おおむね整備している」を合わせても15%にも至っておらず、
データ分析環境の整備の遅れがうかがえる。
データ分析（AIを含む）
を実施するためのIT環境の整備状況

図表42-46

0
2.4

20

12.5

日本（n=534）
データ分析モデルを開発するための標準的なツール、
フレームワークと開発プロセス 米国（n=369）

モデルの更新頻度の把握および 日本（n=533）
明確に定義された基準による更新
米国（n=369）

自動化ツールの使用によるモデルの作成・テスト

モデルのパフォーマンスの継続的な評価とモデルの改善モデル開発のための高性能
コンピューティング環境標準化したデータ処理パイプ
ラインを使ったモデル作成者
へのデータ提供■整備している290 DX白書2021

日本（n=531）

2.6

9.0

2.6

7.7

米国（n=369）

日本（n=531）

2.6
6.0

米国（n=369）■おおむね整備している

33.3

31.7

16.4

54.0
32.8

■あまり整備していない

7.0

20.5
13.0

16.0

52.8

34.1

6.8

12.2

51.3

16.5

30.6

10.6
19.0

17.9

31.7

16.7
31.2

15.4
51.0

16.8

7.0

19.5

36.9

31.2
2.4

6.2 10.8

50.1

18.4

10.5

17.4

25.5

30.4
2.6

（％）
100

80

48.3

19.3

9.4

米国（n=369）

日本（n=534）

60

50.4

米国（n=369）

日本（n=532）

40

6.5

20.4
10.0

13.8

10.3
20.9

14.4
■整備していない

14.1■わからない

8.1

図表42-47はAIの利活用状況を尋ねたものである。日本企業は「全社で導入している」「一部の部署で導入している」を合わせても20%強であり、米国企業との差は大きい。
AIの利活用状況（日米比較）
020

日本（n=530） 1.9

18.6

米国（n=369）

19.2

40

7.9 2.3

9.9

60

9.9

24.9

28.3

16.3

（％）
100

80

10.0

21.2

6.5

4.9 4.6

13.6■全社で導入している■一部の部署で導入している■現在実証実験（PoC）を行っている■過去に検討・導入または実証実験（PoC）を行ったが現在は取組んでいない■利用に向けて検討を進めている■これから検討をする予定である■関心はあるがまだとくに予定はない■今後も取組む予定はない

DX白書2021 291

データ利活用技術

図表42-47｜第 ４ 部｜第 ２ 章｜（2）AI技術

図表42-48は日本企業におけるAIの利活用状況の経年変化である。
米国企業と比較すれば少ないものの、利活用率は大幅に増加していることがわかる。また、「関心はあるがまだとくに予定はない」が大幅に減少しているのは、AIの理解が進み（図表42-54）、AIの導入を進めたり、自社に必要でないと判断して「今後も取組む予定はない」に変化したりしたためと推定される。
図表42-48

日本のAIの利活用状況（経年比較）
0

今回調査（ｎ=530）

20

20.5

AI白書2020（ｎ=525） 4.2 4.8

AI白書2019（ｎ=350） 3.1 7.1

40

7.9 2.3

1.1

10.5

0.3

10.0

9.9

60

9.9

6.5

28.3

51.2

16.0

（％）
100

80

21.2

16.4

52.6

■導入している■現在実証実験（PoC）を行っている■過去に検討・導入または実証実験（PoC）を行ったが現在は取組んでいない■利用に向けて検討を進めている■これから検討をする予定である■関心はあるがまだとくに予定はない■今後も取組む予定はない■不明

292 DX白書2021

5.3
0.6

10.3

創出」
「新製品の創出」「既存製品の高度化、付加価値向上」「集客効果の向上」など顧客価値の向上に関する項目が日本企業より高い。日本企業では「業務効率化による業務負担の軽減」「生産性向上」など業務｜第 ４ 部｜第 ２ 章｜

図表42-49は、AIを導入している企業に導入目的を尋ねたものである。米国企業では「新サービスの改善に関する項目が米国企業より高い。
AIの導入目的（複数回答）
0

20
33.9

新サービスの創出

50.3

23.9

新製品の創出

51.5
48.6
46.0

既存サービスの高度化、付加価値向上

20.2

既存製品の高度化、付加価値向上

30.1

17.4

集客効果の向上

36.2

18.3
20.9

熟練技術者のスキルの継承
業務効率化による業務負担の軽減

27.6

品質向上（不良品低減、品質安定化）

27.6

ヒューマンエラーの低減、撲滅

25.2

人件費の削減16.0

生産性向上（自動化、機械化の推進）

17.8

45.0
33.0
32.1

29.4

18.4

労働力不足への対策

22.0
39.4

13.8
12.9

セキュリティの強化

4.6
4.9

廃棄ロス等の無駄の削減
その他

（％）
60

40

1.8
■日本（n=109）■米国（n=163）※図表42-47において、「全社で導入している」「一部の部署で導入している」
企業に尋ねたDX白書2021 293

データ利活用技術

図表42-49

図表42-50は、AIを導入している企業に「売上増加」
効果の有無を尋ねたものである。
総じて米国企業の方が売上増加効果が高く、とくに「接客サービス」においては、日本企業の23.1%（5%以上、5%未満の合計）に対して米国企業では85.2%となっている。米国企業では、AI導入目的（図表42-49）において「新
サービスの創出」「新製品の創出」「既存サービスの高度化、付加価値向上」など顧客関係の割合が高いことが要因として挙げられるが、極端な日米差（62.1%）
を説明するには十分ではない。
図表42-50

AI導入による「売上増加」効果
0

接客サービス

営業・マーケティング
コールセンター・
問い合わせ対応
社内業務・一般事務

製品・サービスの開発

製造工程、製造設備
ロジスティクス・調達・物流
保全・メンテナンス

検査・検品

情報セキュリティ

警備・防犯

人事・採用

データ分析の高度化

サプライチェーン

その他

20

15.7

日本（n=108） 7.4

14.8

9.3

16.7

日本（n=108） 8.3

7.4

米国（n=163）
日本（n=108） 3.7 10.2

30.7

日本（n=107） 8.4

14.0

日本（n=108） 5.6

9.3

日本（n=108） 3.7

7.4

日本（n=108） 5.6

9.3

34.4

米国（n=163）
日本（n=107） 5.6 5.6

13.9

米国（n=163）

31.9

14.8

米国（n=163）
日本（n=108） 3.7 7.4
米国（n=163）
日本（n=1）

20.2

4.3 1.2

27.0

3.1 0.6

23.3

28.7

13.0

44.4

26.9

13.9

44.4

36.2

23.9

37.4

10.3
13.9

26.9

25.0

1.2

3.7 1.8

24.5

3.1 0.6

23.9

3.7 0.6

50.0

37.4

21.5

14.8

28.7

41.1

8.0

57.0
35.6

36.8

1.8 3.7

47.2

36.2

日本（n=108） 3.7 5.6

8.6

23.9

35.0

21.5

米国（n=163）

日本（n=108） 3.7

31.9

34.4

米国（n=163）

2.5 0.6

52.8

32.5

米国（n=163）
日本（n=108） 6.5

11.1

20.4

3.7

46.7

37.4
14.8

29.6

43.9

36.2
21.3

米国（n=163）

23.3

34.4

38.0

米国（n=163）

27.6

28.7

12.1

17.8

39.8

12.1

24.3

13.1

39.9

37.4

11.7 1.8 1.2

44.4

30.7

21.5

36.2

米国（n=163）

50.9

15.7

27.8

（％）
100

80

33.7

13.0

28.7

38.7

米国（n=163）

日本（n=107） 3.7

16.7

38.7

米国（n=163）

60

11.1

51.5

米国（n=163）
日本（n=108）

40

38.0

30.7

10.2

35.6

53.7

7.4

1.8

22.7

2.5 3.1

19.0

6.1

2.5

100.0

米国（n=0）■5％以上の売上増加■5％未満の売上増加■成果を測定していない■AIを適用していない■売上増加の成果はない※図表42-47において、「全社で導入している」「一部の部署で導入している」
企業に尋ねた294 DX白書2021

的（図表42-49）
で、日本企業では「業務効率化による業務負担の軽減」「生産性向上」などコスト削減に関係する項目が米国企業より高かったが、実際のコスト削減効果は米国企業より総じて低い結果となっ｜第 ４ 部｜第 ２ 章｜

図表42-51は、AIを導入している企業に「コスト削減」効果の有無を尋ねたものである。AIの導入目ている。
入が進むことで、どの程度、効果が上がるかを経年調査により明らかにする必要がある。
図表42-51

AI導入による「コスト削減」効果
0

接客サービス

営業・マーケティング
コールセンター・
問い合わせ対応
問い合わせ対応

社内業務・一般事務

製品・サービスの開発

製造工程、製造設備
ロジスティクス・調達・物流
保全・メンテナンス

検査・検品
情報セキュリティ
警備・防犯
人事・採用

データ分析の高度化

サプライチェーン

その他

日本（n=108） 4.6

20

19.4

13.0

米国（n=163）

31.3

日本（n=108） 3.7

25.0

米国（n=163）

25.2

日本（n=107） 2.8

18.7

18.5
16.7

日本（n=108） 1.9 13.0
日本（n=108） 2.8

16.7

米国（n=163）

25.2

日本（n=109） 4.6

13.1

46.7

36.2

24.5

13. 9

18.5

日本（n=108） 5.6

22.2

34.4

米国（n=163）
日本（n=108） 1.9 6.5

36.2

米国（n=163）
日本（n=108） 1.9 9.3

米国（n=163）
日本（n=108） 2.8 13.0

45.0

32.5

27.6

13.9

43.5

31.3

27.0

30.7

20.4

10.2

1.8

28.2

6.1 0.6

27.0

4.9 0.6

57.4

29.4

17.6

23.1

31.9

4.9

50.9

28.2

16.7

6.7

11.0

30.7

33.1

米国（n=163）

1.2

3.7 0.6

30.1

12.0

25.9

7.4

49.1

9.3

25.0

5.5 4.9

32.5

12.0
19.3

14.8

0.6

52.8

33.1

米国（n=163）

9.8

45.4

38.0

20.2

4.9 1.2

28.2

33.7
19.4

4.3

27.8

23.9

36.2

29.4

米国（n=163）

26.9

40.5

20.2

32.5

11.1

23.1

27.0

米国（n=163）

1.8 2.5

36.1

14.8

30.1

18.7

17.6

日本（n=108） 2.8

33.7

6.7

2.5

5.5

2.5

6.7

2.5

39.8
33.1
53.7

26.4

100.0

日本（n=1）米国（n=3）

47.9

28.8

米国（n=163）

25.8
44.4

13.9

22.2

日本（n=108） 8.3

（％）
100

48.1

14.8

19.4

27.6

米国（n=163）

80

26.4

19.4

日本（n=108） 2.8

米国（n=163）

60

43.6

米国（n=163）

日本（n=108） 2.8

40

33.3

33.3

■10％以上のコスト削減■10％未満のコスト削減■成果を測定していない■AIを適用していない

33.3■コスト削減の成果はない※図表42-47において、「全社で導入している」「一部の部署で導入している」
企業に尋ねたDX白書2021 295

データ利活用技術

このように「売上増加」「コスト削減」
とも日本企業の効果は上がっていないが、今後、日本企業のAI導図表42-52は、活用しているAI技術について尋ねたものである。
「機械学習（ディープラーニングでな
いもの）」については、データ関連技術の活用（図表42-44）が進んでいた米国企業の方が割合が高いが、「ディープラーニング（深層学習）」
に関しては逆転している。
図表42-52

活用しているAI技術（複数回答）
0

20

40

機械学習（ディープラーニングではないもの）

データ分析技術（上記以外、
または詳細不明）
自然言語処理（テキストマイニング）
情報フィルタリング
機械翻訳
情報検索（検索エンジン）
音声認識
画像認識（静止画処理）
画像認識（動画処理）
診断技術（異常、故障検知など）予測技術（需要、売上など）

7.3

11.0

工業ロボット
サービスロボット（接客、会話、介護、ペット、見守りなど）

4.6

チャットボット・AI対話・アバター
自動取引（株、資産運用など）

18.4

12.9

5.5
10.4
4.9

AI OCR(画像認識を使った高度な文字認識)

3.7

（％）
100

19.6

14.7

RPA（AI技術を使っているもの）

46.8
52.1

80

38.5
35.0
32.1
41.1
29.4
23.9
19.3
38.7
17.4
27.0
28.4
31.9
25.7
28.2
27.5
28.8
18.3
25.2
21.1
19.6
17.4
24.5

ディープラーニング（深層学習）

機械の自動制御（ロボットを除く）

60

33.0

21.1
18.3

その他
■日本（n=109）■米国（n=163）※図表42-47において、「全社で導入している」「一部の部署で導入している」
企業に尋ねた296 DX白書2021

除く全企業）。米国企業では、顧客・取引先、経営者、社内関係者の理解や経営者の積極的な関与に関する課題が日本企業よりも割合が高い。
米国企業へのインタビューでも、
本調査結果に対して、AIの普及｜第 ４ 部｜第 ２ 章｜

図表42-53は、AI導入課題について尋ねたものである（AI利活用に「今後も取組む予定はない」
企業をが進んでもユーザーのAIリテラシーの課題は継続する旨が説明されており、日本でも今後、課題となる
は図表42-55の調査結果を参照願いたい。
図表42-53

AI導入課題（日米比較、複数回答）
0

20

40

自社内でAIへの理解が不足している

31.0

顧客・取引先でAIへの理解が不足している

10.5

経営者の理解が得られない

11.3

社内関係者の理解が得られない

11.5

29.8
26.0
21.0

13.8

経営層の積極的な関与がない
手軽に導入できる製品・サービスがない

21.3
17.6

AI人材が不足している

24.0

AIの導入事例が不足している

33.8

18.2

導入費用が高い

21.8

運用費用が高いAI技術を信頼できない

14.1

学習データを保有・蓄積していない

7.5

学習データの整備が困難である

6.9

AIを活用できそうな業務がない

0.5
0.3

5.0

25.4

11.3

導入効果が得られるか不安である

その他

55.8

22.3

4.8

39.8

（％）
60

29.3

27.6
31.3

22.0

15.3
12.8

■日本（n=400）■米国（n=319）※AI利活用に「今後も取組む予定はない」
企業を除く全企業

DX白書2021 297

データ利活用技術可能性がある。
また日本企業ではAI人材不足が5割を超えている。
不足しているAI人材の詳細について

図表42-54は、AI導入課題について、今回の日本企業の調査結果と、「AI白書2019」「AI白書2020」の調査結果を比較したものである（今回調査は全企業、「AI白書2019」「AI白書2020」はAIについて「利用に向けて検討を進めている」「これから検討をする予定である」「関心はあるがまだとくに予定はない」と回答した企業が対象）「。AI白書2019」の上位3位であった「自社内にAIについての理解が不足している」「導入効果が得られるか不安である」「手軽に利用できるAIのサービスや製品がない」
は今回調査ではす
べて40%以下に減少している。これに対して「AI人材が不足している」は増加している。AI白書発刊当
初はAIに関する総合的な参考資料が少なかったが、近年は書籍でもWebメディアでもAIに関する情報が充実している。
このため、AIの理解や製品・サービスに関する課題は大幅に減少したが、実際に導入に取組んだり、
データ分析を行ったりする人材の課題が表出していると推定される。
国のAIに関する技術開発施策や人材育成施策は積極的に進められているが、とくに後者はAI導入を加速するためにも急務であろう。
AI導入課題（日本企業の経年比較、複数回答）

図表42-54

0

20

40
39.8

自社内でAIへの理解が不足している
顧客・取引先でAIへの理解が不足している
経営者の理解が得られない

6.9

68.4

11.3
11.2

11.5
9.5
8.0
13.8

社内関係者の理解が得られない経営層の積極的な関与がない

24.0

手軽に導入できる製品・サービスがない

29.1

AI人材が不足している

22.9

AIの導入事例が不足している
導入費用が高い運用費用が高い

4.8
4.7
5.5

AI技術を信頼できない
導入効果が得られるか不安である
学習データを保有・蓄積していない
学習データの整備が困難であるAIを活用できそうな業務がない
その他

55.0

10.5

2.2

（％）
80

60

0.5
1.5

■今回調査（n=400）

7.5
6.5

29.3

34.6
36.7
33.8
34.2

21.8 26.5
29.1

43.6

55.8

36.0
38.5

31.3
15.1 22.0
18.5
15.3
11.7
19.3
12.8

■AI白書2020（n＝358）

40.8

52.4

■AI白書2019（n=275）※今回調査はAI利活用に「今後も取組む予定はない」
企業を除く全企業、「AI白書2019」と「AI白書2020」
は「AIについて検討中／
関心あり」の企業が対象※「顧客・取引先で…」
は「AI白書2020」
から、「経営層の積極的な…」
は今回調査から選択肢を追加

298 DX白書2021

人材不足については、職種に限らないものであることがわかる。
とくに「AIに理解がある経営・マネジ
メント層」
における日米差は顕著である。

｜第 ４ 部｜第 ２ 章｜

図表42-55は、AI人材の充足度を尋ねたものである。図表42-53で日本企業の最大の課題であったAI

なお、日本ではAI研究者およびAI開発者において「自社には必要ない」が45%前後と、他のAI人材と図表42-55

AI人材の充足度
0

AIに理解がある経営・
マネジメント層

20

日本（n=532） 4.9

先端的なAIアルゴリズムを開発したり、学術論文を書けたりするAI研究者

日本（n=532）

AIを活用したソフトウェア
やシステムを実装できる
AI開発者

日本（n=531）

1.7

6.2

8.3

現場の知見と基礎的AI知識を持ち、自社へのAI導入を推進できる従業員

日本（n=533）

47.0
29.8

32.2

20.1

17.6

29.5

60.0
36.6

米国（n=369）

16.3

22.2
40.7

30.1
7.9

2.1

10.5

28.2

32.2

■十分にいる■まあまあいる

16.0

19.2
28.1

59.3

米国（n=369）

14.6

13.3

48.6

2.6
日本（n=532）

41.5

31.7

米国（n=369）

AIツールでデータ分析を行い、自社の事業に活かせる従業員

30.5

45.1

米国（n=369）

14.1

10.6

56.4
30.6

2.4

26.9
27.1

10.3

米国（n=369）

（％）
100

80

48.7
48.2

2.8
日本（n=532）

60

19.5

米国（n=369）

AIを活用した製品・サービスを企画できる
AI事業企画4037.4■不足している

15.4

14.9

■自社には必要ない

DX白書2021 299

データ利活用技術

比較して高い理由は、AIシステム開発のソーシング手段（図表42-56）にも関連していると想定される。

図表42-56は、AIの開発・導入という観点からソーシング手段（現在の活用状況）を尋ねたものである。
「内製による自社開発」の日米差が極端に大きいが、日本企業ではAIに限らず内製比率が低いことだけでなく、以下の要因も影響していることに留意いただきたい。
・日本企業のAI利活用は米国企業の半分以下（図表42-47）であったため、本設問には「検討を進めている」「関心はある」
段階の回答者も含めた。
このため各ソーシング手段を「導入している」の割合が低くなる
図表42-56

AIの開発・導入という観点でのソーシング手段（現在の活用状況）
0内製による自社開発

外部委託による開発

パッケージソフトウェアの導入

SaaSの導入

パッケージやSaaSをベースとしたインテ
グレーション

日本（n=410）

20

40

30.4

52.6

53.9

31.2

56.4

29.4

14.1

21.9

33.5

44.5

18.8

36.7

米国（n=319）

44.5

日本（n=411） 8.8

29.7

61.6

米国（n=319）

50.2

33.9

■活用している

■検討中

11.0

16.0

47.6

14.9

米国（n=319）
日本（n=411）

28.5

36.4

米国（n=319）
日本（n=410）

62.7

60.5
17.0

（％）
100

80

23.9

13.4

米国（n=319）
日本（n=411）

60

16.0

■活用していない※AI利活用に「今後も取組む予定はない」
企業を除く全企業

300 DX白書2021

後の予定のため、AI未導入が多い日本企業も「より積極的に活用する」
が総じて増加、「活用しない」は
総じて大幅に減少している。米国企業は、「内製による自社開発」で「より積極的に活用する」が減少、そ｜第 ４ 部｜第 ２ 章｜

図表42-57は、AIの開発・導入という観点からソーシング手段（今後の予定）を尋ねたものである。
今の他のソーシング手段は微増になっている。より迅速なソリューション導入のためにパッケージソフ

図表42-57

AIの開発・導入という観点でのソーシング手段（今後の予定）
0内製による自社開発

外部委託による開発

日本（n=410）

20

日本（n=411）

28.0

日本（n=411）
米国（n=319）■より積極的に活用する

28.2
11.9

48.9
25.6

48.3

27.0

45.0

9.7

42.6

47.6

30.4

47.7

21.9

10.7

41.4

48.0

米国（n=319）

8.8

35.4

39.2

米国（n=319）

26.1

パッケージやSaaSをベースとしたインテ
グレーション

35.4

46.0

25.8

（％）
100

80

55.8

パッケージソフトウェア 日本（n=410）の導入
米国（n=319）
SaaSの導入

60

44.4

20.2

米国（n=319）
日本（n=411）

40

53.3■現状から変更なし

37.3

9.4

■活用しない※AI利活用に「今後も取組む予定はない」
企業を除く全企業

DX白書2021 301

データ利活用技術

トウェアやSaaSの導入が利用されている可能性があると考えられる。

（3）IoT技術
図表42-58は、データ利活用に関する技術の活用状況（図表42-44）においてIoTを活用している企業を対象に、業種とのクロス集計を行ったものである。
全体で見ると、「全社的に活用している」「事業部で活用している」日本企業は23.6%であり、米国企業の59.8%と比較すると差は大きい。目的を把握したうえ
でのデータ収集（第2部第4章 図表24-14）やデータ分析を実施するためのIT環境の整備の状況（図表4246）などが影響していると推定される。
業種で見ると、
日米企業とも製造業および情報通信業での「全社的に活用している」「事業部で活用している」を合計した割合が他業種より高い。日本の製造業では、「活用している」の合計が30%を超えており、ものづくりの現場での活用がうかがえる。
図表42-58

IoTの活用状況（業種別）
0

全体

製造業

流通業

サービス業

情報通信業

金融業、保険業

302 DX白書2021

20

日本（n=533） 6.2

17.4

米国（n=369）

27.6

日本（n=132） 3.8

13.6

米国（n= 44）

18.2

米国（n=111）
日本（n= 40）

米国（n= 32）

20.5

23.1

25.0

20.5
26.0

20.7

22.5

18.0

37.5

7.5

41.6
25.6

14.6

51.2
50.0

■全社的に活用している■事業部で活用している■活用していない■この手法・技術を知らない

8.6

18.2
13.6

18.9

38.2
11.6

8.6

32.7

21.6
20.0

10.6
15.9

19.4
41.7

27.3

12.5

12.2

36.4
32.3

20.7

17.4
17.3

22.7

米国（n= 89）
日本（n= 43）

38.3

16.8

8.7

9.6

（％）
100

80

32.2

31.2

米国（n= 93）

60

20.6

24.8

日本（n=214） 6.1

日本（n=104）

40

5.6
11.6

9.4

9.4

■活用を検討している

6.3

の最適化」は日米共に1、2位になっているが、「顧客の価値向上やロイヤリティ向上」「サプライチェーンの最適化」
については、米国企業が日本企業の2倍近くになっており、
顧客価値志向の高さがうかがえ｜第 ４ 部｜第 ２ 章｜

図表42-59は、IoTを導入する目的について尋ねたものである。
「従業員の生産性向上」「業務プロセスる。
IoTの導入目的（複数回答）
0

20

40

従業員の生産性向上

41.1

業務プロセスの最適化

40.3
39.6

19.0

顧客の価値向上やロイヤリティ向上

23.5

新しい製品・サービスの開発

15.6

従業員の安全確保、健康増進

14.1

サプライチェーンの最適化

9.0

資産管理

6.0

IoTデータの外販、他社への提供
IoTの導入を検討していない
その他

0.8

31.2
28.2

20.6
27.1

遠隔監視、制御
予防保守（インフラ、設備など）

47.2

33.6

21.7

競合に対する競争優位性の獲得

（％）
60

17.9

22.2
21.7

25.6

15.2

9.8
13.0

28.2

■日本（n=531）■米国（n=369）

DX白書2021 303

データ利活用技術

図表42-59

図表42-60は、IoTを導入するうえでの課題を尋ねたものである。
米国企業では「経営層が必要性を理解していない」「複合的な技術であるため利用が難しい」「セキュリティやプライバシーに関するリスクがある」「データを収集しても活用する見込みがない」の割合が日本企業より高い。これに対し、日本企
業では「IoTに関する自社の理解が不足している」「人材の確保が難しい」「予算の確保が難しい」「手軽に利用できるIoTの製品・サービスがない」が高い。
日本企業のIoT活用の遅れ（図表42-58）を改善するためには、日本企業の上記の課題への着実な対応が必要である。なお「セキュリティやプライバシーに関するリスクがある」は16.9%と低い。日本でもIC
カードやスマートフォンによる個人情報の扱いが問題になった経緯を踏まえれば、課題認識を高める必要がある。
IoT導入における課題（複数回答）

図表42-60

0

10

20

12.2

経営層が必要性を理解していない

30

29.0

17.7
17.1

適用できそうな業務がない
IoTに関する自社の理解が不足している

16.9

セキュリティやプライバシーに関するリスクがある
人材の確保が難しい

7.3

データを収集しても活用する見込みがない
手軽に利用できるIoTの製品・サービスがない

10.3

8.7

ベンダーから魅力的な提案がない

3.8

とくに課題はない

0.4

31.6

22.8

13.9

8.1

18.6
21.1

■日本（n=531）

304 DX白書2021

34.8

24.7

16.0
15.3
16.3

コスト削減効果が低い

その他

27.4

17.3

予算の確保が難しい

（％）
50

24.1

19.4

複合的な技術であるため利用が難しい

40■米国（n=369）

外部組織を交えたデータ流通におけるブロックチェーンの活用
社会基盤センター

イノベーション推進部

DXを推進する上で、データ分析を活用した

経路で取引されてきたのかというトレーサビ

業務改善や新サービスの実現が必要不可欠とリティーの記録の信頼性を特定の管理者に権なっている。今後、企業は自社内のデータだけ限やコストを集中させることなく検証できる。

でなく、社外にあるデータを活用することに食品のトレーサビリティーにブロックチェーンを活よって、顧客やビジネスの状況への理解をより用する事例では、生産現場から販売店舗まで流通深めることが可能になると予想される。しかに係る複数の業者のデータを分散型台帳で効率し、そのためには取引相手や競合他社と言った的に記録して、流通にかかわるデータをより早くより外部組織との間でデータを流通・共有させる仕

正確に参照できる成果を活用し、廃棄品を減らす組みの実現が必要不可欠である。

という効果へ繋げている。IBM社の食品サプライ

データ流通や共有を実現する際に重要となチェーン向けブロックチェーン「Food Trust」は、るのが、関係者間でデータの真正性を保証す

大手スーパー Walmart社やフードサービス会社る仕組みである。従来から、共通ポイントのよ

Gollden State Foods社で活用されており、配送のうに企業間でのデータ共有が行われているが、遅れや気温室温の変化など鮮度に影響が出そう

特定の企業がすべてのデータを中央集権的になデータを加工業者や輸送業者からリアルタイムに管理することによって真正性を保障してきた。

参照することが可能となり、Walmart社やGolden

これに対して、より多様な組織間で生成されるState Foods社は「Food Trust」からのデータをもデータの真正性を担保してデータを流通・共有とに、輸送先を近隣へ変更するなど鮮度への影響する仕組みとして、近年注目を集めているのがを最小限にとどめる行動を起こすことができる。

分散型のデータ管理の仕組みである。

他にも、ダイヤモンドの産出や加工、販売を

ブロックチェーンは分散型のデータ管理を記録する「Everledger」や、ハイブランドが非正実現する技術のひとつである。ブロックチェー

規品を排除するため、正規品の流通証明にブンは、特定の者に権限や管理コストを集中させ

ロックチェーンを活用している。

ることなく複数の関係者でのデータ共有を可能にし、且つ高い改ざん耐性を有している。こうした特徴を利用して、ブロックチェーンを取引関係にある企業間だけでなく、競合関係にある企業間でデータを共有する仕組みとして利用され始めている。

2. 競 合 他 社 と の デ ー タ 流 通

フェデレー

テッドラーニング併用による競合企業の協調

ブロックチェーンは台帳記録を分散させて複数で共有する特性があるため機密性の高い

1. 企 業間のデータ流通

サプライチェーン

におけるトレーサビリティーのコスト削
減・効率化

ブロックチェーンは改ざん耐性の高さと、分散型の特性により、モノやデータがどのようなデータの取引には向かないとされるが、学習データではなく学習モデルを統合するフェデレーテッドラーニングと組み合わせて活用することで、競争領域のデータ利用で競合他社との協調ができる。
アステラス製薬、アムジェン、メルクなどのDX白書2021 305

データ利活用技術

独立行政法人情報処理推進機構
主任 安田 央奈

｜第 ４ 部｜第 ２ 章｜コラム

製薬大手が参加する「MELLODDY（Machine
Learning Ledger Orchestration for Drug
Discovery）」
は、化合物ライブラリーのデータを各社で秘匿状態を維持しながら、コンソーシア

3. 企 業と個人間のデータ流通

自己主権型

アイデンティティによるデータ流通への個人の参加促進

ム間で機械学習に利用することができるプロ

ユーザーや消費者の行動や思考を分析できジェクトである。製薬会社は各社で化合物ライる個人のデータはますます企業にとって重要ブラリーを所持しており、そのデータを機械学

であるが、本来のデータ所有者である個人では習に利用することで新たな薬の研究・開発を進なく企業が中央集権的にデータを所有・管理しめている。他社が保有する化合物ライブラリーていることはプライバシーの侵害やデータ寡のデータを活用することができれば機械学習

占、市場競争の阻害といった問題を生み出し、モデルを高度化できるが、化合物ライブラリー

データ流通に向けて解消すべき課題となっては機密情報であり製薬企業の競争力の源泉でいる。

もあるため、競合他社に対し容易に開示する

個人が企業などの仲介なく、自身に関することはできなかった。しかし、MELLODDYで

データや自身のアイデンティティ情報を自身はブロックチェーンの機能を利用してフェデで所持しながら、開示先や開示範囲を自己裁量

レーテッドラーニングを実装することにより、で管理できる「自己主権型アイデンティティ」

各社のライブラリーのデータを開示することが、クレデンシャル
（証明書、信任状等の意）や行

なく、高度な学習モデルの生成と管理を実現し

動履歴データの流通において活用されている。

た。機密保持と学習モデルの高度化が両立され自己主権型アイデンティティにおいてブロッたことにより、機密開示を躊躇する製薬会社がクチェーンを活用すると、極端ではあるがクレコンソーシアムに参加しやすくなり、コンソー

デンシャル発行者が消滅してもクレデンシャ

シアムから得られる深い洞察は創薬に大きなルの有効性は検証できるため
（下図表）
、国連な

進歩をもたらしていく。

どの国際組織は紛争や災害で行政システムが創薬に限らず、ブロックチェーンとフェデ

不安定なために身分証明手段を持たない人々

レーテッドラーニングを併用することで、各社に向けて自己主権型アイデンティティを発行の機密や競争力は守りつつ、協調によって個社するプロジェクト
「ID2020」を推進している。

ではありえない深い洞察を得ることができる。

自己主権型アイデンティティの機能を実装

クレデンシャル検証における信頼の拠り所（パスポートの例）

306 DX白書2021

性や信頼性からよりスムーズにユーザーや消キンググループでは、自動車産業の他に保険会費者といった個人をデータ流通の当事者とし社、広告会社等データ流通を想定した幅広い業て巻き込んでいけると考えられる。モビリティ

種を加え、ブロックチェーンや自己主権型ののブロックチェーンコンソーシアム「MOBI

データの利活用に向けて活動を進めている。

コラム

量子コンピューティングの自社導入に向けて
独立行政法人情報処理推進機構
主任 鷲見 拓哉

社会基盤センター

1. 量子コンピューティングによる新たな価値創出

DXを推 進する上で重 要な「データ利 活 用 」

イノベーション推進部

データを用いた高度な分析により、顧客ごとに最適なアドバイスを導き出し意思決定を支援するような顧客体験の向上を目指す取組が進められている。

の 側 面において、量 子コンピューティングは究

これらの事例に見られるように、量子コン

極の武 器となる。
ビジネスで解きたい計 算にはピューティングの応用は、既存の業務やプロセ

非 常に複 雑なもの が 存 在し、中には 古 典コン

ス全体の効率化を実現するだけにとどまらず、

ピューティングでは太 刀 打ちできず、経 験 則や、

古典コンピューティングの限界により持て余

何か月も要する実 験に頼らざるを得ないものもしていた膨大なデータを処理できるようになある。量 子コンピューティングは、そのような手にることで、これまで提供し得なかった新たな価

負えない計算の一部について、解を提供する。

値を生み出すことをも意味する。

たとえば、化学や材料開発の分野では、新たな化合物を一つ作り出すために、数千という数の試料を実際に作り、そのすべての性質を評価

2. 量子コンピューティングの魅力した上で最終的に一つに絞り込み、その後よう

量子コンピューティングでは、「量子ビット」

やく量産に辿り着く。この工程には通常数年をに計算過程を記憶させる。一つの量子ビットは要するが、量子コンピューティングを応用する

0と1の両方を同時に記憶することができ（「重ことで数か月まで短縮できる可能性がある。こね合わせ状態」）「、もつれ状態」という特別な状

れは、量子コンピューティングによるシミュ

態にある量子ビットを操作することで計算を実レーションにより、実際に作るべき試料の数を現する。
巧妙に設計されたある種の「量子アルゴ

数百まで事前に絞り込むことができるからでリズム」
は、
時間計算量において古典コンピューある。
これにより、試料の原材料費や作成・評価

ティングを凌駕する。これが、量子コンピューに要する時間を削減できるだけでなく、結果的ティングが「超高速」と表現される所以である。

に製品の市場投入までの時間を劇的に改善でたとえば、量子アルゴリズムの一種である「グきる可能性が生まれる。また、金融の分野では、ローバーのアルゴリズム」の時間計算量は理論

古典コンピューティングでは不可能な大量の的に最も小さく、これよりも時間計算量の小さDX白書2021 307

データ利活用技術（Mobility Open Blockchain Initiative）」の ワ ー｜第 ４ 部｜第 ２ 章｜

するデータ流通プラットフォームは、その透明い古典アルゴリズムは存在しないことが証明さ

量子コンピューティングへの投資、自社導入のれている。また、「ショアのアルゴリズム」は、現準備を既に進めている。

在知られている同種の計算を行うどの古典アルユーザー企業がまず行うべきは、「自社ビジネスにおける応用先の検討」と「利用可能な量子ア

ゴリズムよりも時間計算量が小さい。
量子コンピューティングの凄さは時間計算量

ルゴリズムの検討」の二つである。先進企業は、だけにとどまらず、記憶域の観点でも古典コン

量子コンピューティングの専門知識を内製又はピューターを凌駕する。もつれ状態にある量子外部活用してこれらを検討している。内製の場

ビットがn個あるとすれば、その量子コンピュー合、自社ビジネスに直結する量子アルゴリズムn

ターは2 通りの情報を同時に表現することがを開発できる人材を自社内に確保する。そのたできる。日本が世界に誇るスーパーコンピューめ関心事項に応じて集中的かつ独占的に取り組

ター「富岳」の総メモリ容量が4.85 PiB（ペビバ

むことができるが、人材の教育や採用、
雇用維持

50

イト。1 PiBは2 バイト）であるから、仮にこの52には大きな投資が必要となる。
外部活用の場合、すべてを使って情報を表現するとすれば、2 バ

外部の専門家や専門企業を活用する。
この場合、イト＝255ビットの記憶域を利用することができ

社外の経営資源も動員して専門知識を素早く49るが、この記憶域で同時に表現できるのは2 通

利用することが可能となるが、得られた知識をりが限界だ。
つまり、もつれ状態にある量子ビッ

いかにして社内に定着させるかが課題となる。

トを50個備える量子コンピューターが取り扱う

現在のところ、専門人材を個社が獲得すること

データは、富岳のメモリには収まり切らない。
しが難しいこともあり、外部活用が利用されるこ

かも、量子ビットが一つ増加する度にそのデーとも多い。多数の企業が参画するコンソーシア

タ量は指数関数的に増大するから、あっというム型の外部活用先としてはIBM
（米国）の
「IBM

間にスーパーコンピューターをもってしても対Q Network」が有名である。このほか、先進企業

抗できない世界まで行ってしまうところに量子では、自社ビジネスへの応用に最も寄与するでコンピューティングの凄さ、魅力がある。

あろうパートナー企業を自ら見出だし提携する場合もある。
これら先進企業では、
小規模ながら

3. 量子コンピューティングの自社導入も実際に利用可能な量子コンピューターを用いて、実際の業務データを入力とする試行的な計

華やかに見える量子コンピューティングだ

算実験が行われるなど、いつか来るであろう量が、その先行きは不透明だ。実は、大規模な計子コンピューティング実用化の日に備えた実践

算に必要となる量子ビット（論理量子ビット）的な取組が行われている。

が 一つも実現し ていない。つまり、量子コ ン
ピューターというハードウェアの研究開発がまだまだ必要なのである。このような状況の

4. 結び

中、ユーザー企業はハードウェアの成熟を待っ

量子コンピューティング実用化の日がいつていればよいのだろうか。いや、そうではない。

なのかは誰にも分からない。だからこそ、量子「もし量子コンピューティングが実用化したコンピューティングの自社ビジネスへの影響

ら、我が社のビジネスはどう変化するか」「その調査や応用方法の検討、準備を早期から進めて時、他社に先駆けて我が社が量子コンピュー

おくことが肝要であろう。量子コンピューティ

ティングの応用に乗り出せるとしたらどう

ングが他社との差別化因子と認識した企業はか」、これを理解した先進的なユーザー企業は、何歩も先を進んでいることになる。

308 DX白書2021

いかにして新しい手法や技術を組織に取り入れるか1. 米 国企業における導入状況・リーン開発
やデザイン思考を導入する目的

現状、多くの米国企業でリーン開発やデザイ
ン思考を用いている。特に、革新的な価値を実現したいと考える企業は、アジャイルやデザイ
ン思考を意思決定プロセスのフロントエンドに取り入れようとしている。
リーン開発やデザイン思考を導入する目的として、プロセスの適正化／効率化が挙げられる。
グループ内の意思決定を迅速に行い、それに基づいてリソースを適切に配置することにつながる。
他にも、ビジネスで最適化すべきポイントや課題となるポイントの発見、製品を早期に市場に出すなどのために用いる企業もある。IT部門
での利用や組織のデジタル化、データ活用などの領域が最もリーン開発のメカニズムに合致するとみる。
様々な業界で、テクノロジーやデータ
使用がますます加速しているので、リーン開発
やデザイン思考を用いることで課題を抽出し、変革の成果が出るまでには2 ～ 3年かかる。変
革に成功している企業では、トップマネジメン
トから組織の一番下まで、従来とは異なるオペ
レーションであることが共有されているほか、「失敗しても良い」という考え方を持ち、企業文化の変革に多額の投資を行っていることが多い。
リーダーへの投資も重要である。DX推進に
おいては、リーダーやマネジメント層の意識合
わせは欠かせない。リーダーの考え方がウォー
ターフォール型のままであると、企業文化の変
革に失敗する。リーダーシップはDX推進における重要な要素であるにも関わらず、投資が十分に行われていないことも多い。
他にも、リーダーシップによるサポートは重要であり、リーダーシップがチーム外であったとしても、見守り、支援することはDX成功における重要な要素となる。
加えて、DXの初期段階で解決したい課題や実現したい目的、具体的にどういった技術を取り入れ、どういったことを行うのかまで明確にしておく必要がある。

これまで以上のスピードで改善につなげること
ができる。
一方、
企業によって適切なデリバリーの頻度は異なるため、従来型企業がGAFAを真3. AI導入などにおける成功要因と阻害要因似て短期間のサイクルを取り入れようとすると

たとえば、AIを使うことで、採用担当者を支

顧客がサービスの変革のスピードについていけ

援することができる。必ずしもリクルーターやず、これまで築き上げてきたバリューを破壊し採用係をAIに代替させるということではなく、てしまう恐れもある。

彼らにより多くの洞察を提供することで支援を行う。現在、自分が業務で関係しているコン

2. リーン開発やデザイン思考における成功
要因と阻害要因

ビニやガソリンスタンドでは、顧客の購買行動に対してAIやMLを使うレコメンデーションモ
デルの構築を進めている。AIベースのレコメリーン開発やデザイン思考は実践を通じ、継ンデーションエンジンを構築することで、顧客続的に発展するものである。ただし、こうしただけでなく、店舗に置くべき商品を決定するカ

DX白書2021 309

データ利活用技術

Digital Transformation Executive & Principal Consultant Janus Insights LLC
Gustav Toppenberg｜第 ４ 部｜第 ２ 章｜

コラム

テゴリーマネージャーも支援している。AIを活用したインサイトや予測分析、プロテクトア

5. テクノロジー獲得のためのM&Aについて

ナリティクスの判断を評価する。異なるシナリ

DXとは、新製品などの市場投入プロセスのオを実行する前に成功の可能性を測定するこ

デジタル化や、CX、EXのデジタル化などによっともできる。

て市場進出の方法を変革することと考える。そAIの最大の阻害要素は、AIに対する理解の欠如であると感じている。AIのブラックボッの上で、外部からテクノロジーの能力を獲得するためにM&Aが行われている。

クス的な部分を取り除くことで個々のユース

ソーシング戦略と同様、M&A戦略も企業にケースを他のケースにも活用することが期待

よって様々で、買収した企業をそのまま独立さされる。導入候補のツールの評価・選定支援をせておき、経済的／企業価値が上がった際にス行ったことがあるが、各国の規制を考慮した

ピンアウトさせる場合や、社内でインキュベー

り、バイアスを排除する必要があることから、ションを行う場合がある。最も多く見られる戦

大変センシティブなものであった。その他の課略としては、会社を買収して企業文化に完全に題としては、「AIの利用を従業員に説得するこ

統合する方法である。

と」がある。AIが人の行った決定の検証だけでTarget社は企業の買収を通じて一部業務のはなく、AIが意思決定そのものの支援もする

デジタル化に成功した事例として挙げられる。

ということを説明する必要がある。もう一つのTarget社では複数の小規模テクノロジー企業

課題は人材スキルの欠如である。人材やスキルを買収し、顧客接点や顧客体験における変革、の獲得能力は企業にとっても挑戦である。

サプライチェーンやオペレーションの分野における変革に成功した。製造業においては、顧4. 米国におけるAI技術のソーシング戦略について客や市場へのアプローチではなく、製造プロセ
スの強化／効率化に向けた企業の買収であることが多い。機械学習やニューラルネットワー

多くの従来型企業では社内開発、社内構築とクを用いた分析によって、より大きなスケール

いった手段をとることが多い。ソーシング戦略

でのアウトプットの予測に取り組む事例もあは企業によって様々である。AIの実装・開発

る。製造業は巨大なデータセットを持っているが企業にとってコアビジネスに関連しないもため、買収による相乗効果は非常に興味深いものなのであれば、外部アウトソーシングというのとなる。小規模なパートナー企業を早期の段手段も考えられる。

階から支援し、パートナー企業の市場価値が認

ま た、昨 今、オ ン プ レ ミ ス か ら ク ラ ウ ド ／められれば買収し、競争相手が同じサービス

SaaSソリューションへ移行する動きが目立ってを使うことを防ぐといった戦略をとることもいる。SaaSをコスト削減目的で利用する企業はある。なお、非テクノロジー企業では、テクノロ

多く、実際にIT人材が不要になるといったコスジーを獲得し、維持すること、テクノロジーをト面での効果はあるが、ライセンス契約であれ扱える人材を獲得することがいかに難しいかば利用期間に応じたコストがかかる。SaaSの最理解できていないケースもある。買収を行った

大のメリットは、
アジリティである。
日々変化す

企業のエンジニアをスタッフに留めることはるビジネス要件や顧客要件に対し、これまで以難しく、経済的なインセンティブを与える必要

上のスピードで対応することができる。

がある。だが、そのような待遇を提供しない限り、人材は流出し、テクノロジーは進化しなくなってしまうだろう。

310 DX白書2021

企業インタビュー 11｜第 ４ 部｜

旭化成株式会社
1. DXにおけるデジタル技術活用
AI・IoT・ブロックチェーンなどの先進技術活用状況
技術分野によって、導入済み、動向をウォッチ、など様々なフェーズがある。
機械学習、
クラウド、IoTといった技術は、MIなどやスマートファクトリー領域においてはすでに実践的に活用している。
先進事例を参照しながらトライアルを行い、積極的に自社に取り込んでいる。IPランドスケープでは大量のテキストデータの解析を行っている。
自然言語処理技術は、定性情報を解析して経営判断に役立てるといった取組にも活用する。一方で、脳科学や量子コンピュータなど、本格的な実用フェーズが先にある技術は、将来の活用に向けてウォッチしている。
ブロックチェーン技術の活用例は、「Fresh Logi」（生鮮食品の物流高度化）や、IBM等との共同プロジェクトである「BLUE Plastics」（プラスチックの資源循環）等がある。Fresh Logiでは生鮮食品のサプ
ライチェーン管理、BLUE Plasticsは再生プラスチックのリサイクル証明にブロックチェーン技術を適用している。
これらは、新事業として育成を図っている事業領域となる。
BLUE Plasticsプロジェクトにおけるプラスチック資源循環のイメージ

AIは日常的に活用している技術であり、サランラップを始めとする製品製造ラインでの画像認識による製品検査、
異常検知、
異常予測など、多くの工場で実装済みである。
DX推進担当と現場が一体となって、PoCで効果がわかるとすぐ実装に移る、
スピード感を持った実
施体制となっている。
また、
すでに社内で実績が多いため、勘所を押さえてPoCを実施し、社内事例をふまえて実装検討を行えるため、実装が加速している。

DX白書2021 311

ITベンダー活用と内製
内製率の向上は明確な方針となっている。
全て内製とすることはできないので、ベンダーとの協業は継続するものの、関係は変えようとしている。これまでは、仕様が曖昧なままベンダーに丸投げすることもあった。これからは、プロジェクトに自社メンバーも参加し、ベンダーと「ワンチーム」になって推進する。
グローバルテックベンダーの豊富なノウハウを学ぶことができるなど、IT人材の育成にもつながるメリットがある。
2021年1月にはデジタル共創ラボ「CoCo-CAFE」を開設した。社外の様々な組織・団体や人材とオープンにコラボレーションする場である。ベンダーともCoCo-CAFEを使ってプロジェクトを進めており、
ワンチームとしてフラットな関係を築いていっている。
アジャイルとデザイン思考の活用
内製化の最大の目的の一つは、変化への対応スピードを上げることである。社会の変化、社内の変革に迅速に対応できるシステム開発のプロジェクトは内製化しないとスピードが追いつかない。
共創戦略推進部ではGarage（アジャイル開発＋デザイン思考）を推進するためにGarage Teamを立ち上げた。2021年からの取組だが、8月時点では10テーマ以上ですでに活用が進められている。
上述のBLUE PlasticsもGarageを適用しているテーマの一つであり、デザイン思考でストーリーを描
き、
アジャイルに開発を進めている。
その他にもデザイン思考でストーリーを描いている段階のテーマ
において、事業部メンバーや外部ベンダーも参加し、多様性が意識された取組となっている。
データ活用基盤旭化成の事業領域は、マテリアル、住宅、ヘルスケアとタイプが異なる3つの柱があり、全社的にデー
タを流通させることで、強みを明確に発揮できるのではないか、という課題意識を持ち、データマネジ
メント基盤の構築に着手している。
まずはシンボリックに経営課題である領域で、カーボンフットプリントのデータを全社的に可視化しようとしている。基幹システムから取れるデータを活用できるため、取組やすいこともある。領域の壁を超えてデータを共有できるようにすることはハードルが高いが、良い事例を作りつつ、数年かけて全社展開を進めていく。

312 DX白書2021

企業インタビュー 12

1. デジタル技術活用の概要
インフィックのバックボーンは2001年から始めた介護事業である（子会社である株式会社まごころ
介護サービス）。
介護事業を取り巻く環境を見ると深刻な人材不足があり、2025年には介護人材が40万
人不足すると言われている。対策は外国人の力を借りるか、IoTなどデジタル技術を活用するか、である。
このままでは日本の高齢者を支えられないという危機感を持ち、介護の現場から必要にかられて約10年前からデジタル分野を開拓した。
まごころ介護サービスの介護現場で高齢者やヘルパーの声をダイレクトに聞きつつ、インフィック
は3つのデバイス、
室内空間センサー LASHIC（ラシク）-room、
ベッド睡眠センサー LASHIC-sleep、ナー
スコールLASHIC-callの開発を行った。
事業化において、こだわったのは価格である。
介護事業者は投資力が限られるという現状をふまえ、精緻で高価なセンサーを使うのではなく、安価で使いやすいことを追求し、SaaSで月980円/台という価格設定とした。
LASHIC-roomが 使 っ て い る セ ン サ ー は、人 感 セ ン サ ー、光 セ ン サ ー、温 湿 度 セ ン サ ー で あ る。
LASHIC-sleepは、
元は静岡の大手精密部品メーカーの技術を使っている。
介護施設向けLASHIC-careでは、センサー情報の組合せで高齢者がベッドで寝ている、
ベッドの上にはいないが部屋にいる、などの状態がわかる。LASHICはカメラがなくても状態を把握できる技術として評価され、特許も取得している。他社のベッドセンサーシステムでは、ベッドを離れたことはわかるが、部屋にいるかどうかがわからないので見回りに行かなくてはならない。LASHICを利用すれば、夜間巡視がほぼ不要になる。
また、7年かけて独自に離床予測（いつ起きるかの予測）の技術を開発した。
高齢者の入院原因のトップ3に転倒骨折が入る。
転倒骨折は、
睡眠後起きた時にふらついて倒れて起こることが多い。
目を覚ます
前の対応が必要だと考えていた。精密部品メーカーから離床予測ができるかもしれないという話を持ち込まれ、これまでない技術だったので、共同開発に着手した。途中で精密部品メーカーから技術を買取り、滋賀大学や東京電機大学の力を借りながらリリースに至った。
離床予測ではルールベース中心であるが、AI分析を行っている。
今後はディープラーニングを使って精度を上げたり、未病や介護予防にもつなげようとしている。
2. データ活用への取組
外部データと連携するLASHICプラットフォームを開発している。インフィック製品のセンサー以
外の他のセンサーデータや、血圧、遺伝子情報、
食事データなど様々な外部データと連携することで、個人の状態や健康に関する情報が充実する。
また、ヘルパーへのレコメンド機能を実装している。ベテランヘルパーは高齢者の状況から肌感覚
ですべきケアがわかるが、経験の浅いヘルパーに対しては、システムがレコメンドする仕組みである。
熱中症のリスク、
軽度の認知症で起こる異常行動など、20ほどレコメンド項目がある。
大手印刷会社とローンチしたLASHIC+で、AI分析することでさらにレコメンド項目が増える。
最初に高齢者10人分1か月分のデータで分析を開始したが正解率は3割だった。そこで100人分1年間のデータを入れると9割に改善した。ビッグデータを持っていると正解率が上がる。リアルな教師デー
タを取れることがグループ会社のまごころ介護サービスで介護事業を自ら行っている強みとなる。
DX白書2021 313｜第 ４ 部｜

インフィック株式会社、株式会社まごころ介護サービス

3. 成果評価とガバナンス
LASHICを利用した場合は夜間巡視がほぼ不要になる。また、離床予測は、夜間のヘルパーの先進的なフォローになる。特別養護老人ホームやサービス付き高齢者向け住宅では一人のヘルパーが夜勤で20 ～ 50人もの高齢者を担当しており、精神的肉体的に重労働である。
加えて、一人ひとり朝起こすモー
ニングケアも大変な仕事になる。誰から起こすかは勘に頼ることになるが、手が行き届かず、起き抜けに倒れ入院する人が出るなどの痛ましい事故も起こる。誰がいつ起きるか分かるとヘルパーの生産性が大きく向上する。
自社グループ介護施設での実績だが、見回りをしなくて良くなったことによる夜間巡視業務負担の97.5％削減、104床の特養で月間160万円のコストカットを実現した。
夜間の転倒事故は1/3に削減した。
他の施設でも同様の数値になると考えている。
4. 将来展望
インフィックの将来展望として3つの方針がある。まず1つ目は、健康寿命の分析サービスである。介護施設での健康改善の取組にヒントを得て、健康寿命を可視化する分析を進めている。
運動や食事による健康寿命の伸長を支援する狙いである。宅配弁当事業者や大手サプリ事業者と連携してビジネス化を図っている。
2つ目は、グローバル展開である。中期経営計画で「世界No.1のICT活用介護会社を目指す」と打ち出し、増田社長は従業員にことあるごとに話している。
こと介護分野ではGAFAに勝てるという意気込みを持ち、日本の課題を解決した先には、
大きな戦略目標としてグローバル展開を図る。
3つ目の方針は、「IT介護士」
資格の創出である。
これは、ITのスキルと介護のスキルを兼ね備えた介護士に対する資格認定をイメージしている。
介護施設にはIT介護士が必須という状況にもっていきたい考えだ。インフィックがエンジニアの人員不足解消のために2019年に買収したSES企業はITスキル
教育ノウハウを持っており、
ヘルパー育成の知見をあわせ、IT介護士育成に向けた働きかけを行っていく構想を持つ。
介護業でLASHICのユーザのネットワークができてきていることから、業界を束ねて仕掛けていけると良いと考えている。

314 DX白書2021

企業インタビュー 13

1. DX戦略の概要
DX戦略
SBIグループは、1990年代末の「インターネット革命」「日本版金融ビッグバン」の潮流を捉え、イン
ターネットを介して真に顧客中心の金融サービスを提供し、もって社会に貢献する企業グループとして誕生した。創業以来「顧客中心主義」を掲げ、その方法として新技術を先んじて活用し、金融サービス事業を行っている。また、スタートアップへの投資事業に関しても20年ほどの実績がある。ベンチャー
投資事業は「21世紀の中核産業に投資する」という方針を持ち、デジタルテクノロジーやバイオ分野で新技術を持つスタートアップに集中的に投資を行っている。
その中で、SBIグループは基本戦略に
「投資」
「導入」
「拡散」
を掲げる。
有望な技術を持つスタートアッ
プに
「投資」
し、
投資先企業の最新技術をグループ内で積極的に「導入」
して検証・評価し、さらに新技術を使った製品やサービスを地域金融機関など外部にも提供して「拡散」する。こうして自らの投資活動の枠も超え、社会変革にも貢献していく取組を進めている。SBIインシュアランスグループは、こうしたSBIグループ独自の
「投資」
「導入」
「拡散」
のサイクルの中で、先進技術にいち早くキャッチアップ・適
応し、新しいサービスやビジネスを生み出し、他社との差別化を図っていくことで持続的に成長していくことを目指している。
DX推進体制
SBI損害保険（以下、SBI損保）ではDX推進を経営戦略課題の一つに掲げ、昨年度7月にイノベーション推進室を創設した。イノベーション推進室は、先進技術を活用した各事業部の取組をとりまとめ、全社のDX推進を担当している。
イノベーション推進室はアジャイルオーガニゼーションの考え方に基づき構成されており、室長が情報システム部の部長も兼任となり、DXの企画の段階から情報システム部とスムーズに情報共有を行っている。各部門から兼務で人材が集められており、各事業部のDX推進状
況の共有や、新しい技術と各部門の業務課題をつなげている。具体的には、部門ごとにアンケートや課題を収集し、イノベーション推進室に持ち寄って検討し、結果を各部門にフィードバックする。担当者には、現場の状況をよく知る若い層を多くアサインしている。
具体的なDX取組と成果評価
SBI損保は今年度、「DX Force 2021」を立ち上げた。
最も主要なプロジェクトはAI活用であり、3 ヶ年計画で推進中。SBIホールディングスのビッグデータ室とDataRobot社と三者で、AIによる保険金の不正請求検知、コールセンターの受電予測（受電状況の予測に基づくシフト配置など）などの取組を進めている。DX Force 2021の目的は3 ヶ年の間にSBI損保独自でAI・機械学習によるデータ分析に基づく業務改善・社内改革を行える人材を育成することである。各事業部よりアサインされた市民データ
サイエンティスト＊1候補は、DataRobot社のトレーニングを受け、実際のテーマをDataRobot社と一緒に実施するなどのOJTにより育成している。
AI・機械学習への取組のKPIとして、
ローカルCoEの組織構築、
データサイエンティストの育成人数、実施するアイデア、モデリング（AIモデル）の数、業務へのデプロイ数、プレス発表数などがある。ビッグデータ室とDataRobot社とSBI損保の三者によるCoEで隔週の定例会を行い、KPIの進捗率を管理し＊1

 社では、統計学やプログラミングなどの専門知識がなくてもツール（同社の場合は DataRobot）を使って AI・
同
機械学習を活用したデータ分析ができる人材を市民データサイエンティストとして育成している。
DX白書2021 315｜第 ４ 部｜

SBIインシュアランスグループ株式会社、SBI損害保険株式会社

ている。
他のプロジェクトではウォーターフォール型でリリース後に成果が出てから評価するが、DX
Force 2021では複数のテーマを同時進行で管理しており、また機械学習のテーマは進捗により予測される効果が変動するので、CoEが常にKPIを監視し優先順位をコントロールしていくことが重要である。
2. デジタル技術活用開発手法や技術の活用
金融システムには高い信頼性が求められるため、開発手法の主流はウォーターフォール型である。
業
務によっては、アジャイル開発とする場合もある。DXの推進と並行して、システム開発方針をオンプ
レミスからクラウドサービス活用に変更した。
がん保険、団体保険はすでにクラウドへの移行が完了しており、クラウド化に際しては、
シンプレクス社の「Simplex xInsurance」というプラットフォームに載せ換えている。
今年度中にはすべての基幹系システムのクラウド化が完了する見込みである。SBI資本関係の企業（投資先のベンチャーなど）の先進的サービスを導入し、カスタマイズして利用することでDXを加速していくケースも多い。たとえばAI-OCRはSBIグループ投資先の技術を利用し、SBI損保向けのカスタマイズを行い、従量課金で利用している。
他方、火災保険のAI受電は外部サービスを活用して開発している。
社内の技術者が全てAIを内製するのではなく、グループ内外のサービスを組み合わせることでスピードを実現している。
データ整備と活用
現在はデータを使いたい場合はシステム作業依頼を出す必要があり、データ提供にも長くて2 ～ 3週間程度かかることもある。
そのためビッグデータ室とデータ連携の自動化を検討している。
データレイ
クに近い形で基幹系システムのデータを連携し、AI・機械学習に使う予定である。
全社的なデータ活用については、各部門の市民データサイエンティストが広く意見を聞いて課題を集め、DataRobot社と検討している。
日常業務からデータ分析のテーマやソリューションを探していくというDXを意識した
姿勢は、既に全社にスケール化ができている。
2020年10月、SBI損保契約者アプリにおいて、安全運転を計測するサービスの提供を始めた。自動車保険契約者がアプリをダウンロードすると、契約内容の紹介、事故の連絡、ロードサービス手配を行え
るほか、安全プログラムでは加速度センサーの入ったデバイスでデータを収集・分析し、平均数値と比較した運転の安全性を評価し、危険運転エリアを地図上に表示する。
お客様の事故やトラブルを未然に防ぐことを目的としており、
現在運転データを蓄積中で詳細はこれから分析していく段階である。
市民データサイエンティストの育成
営業本部、カスタマー本部、損害サービス本部から1 ～ 4人の市民データサイエンティスト候補をアサインし教育している。市民データサイエンティストは各事業部の課題を出し合い、DataRobot社やビッグデータ室と一緒に検証し、業務改善のテーマを機械学習し、効果があるとわかれば業務プロセスに機械学習効果をデプロイする。
一人のデータサイエンティストが一つの課題を集中的に担当し、効果がないと評価した場合は、次のテーマに取組む。アイデア出しについては業務部門ごとに収集し、テーマとして定義したうえで、効果が大きいと推測できるテーマから一件一件検証している。

316 DX白書2021

企業インタビュー 14｜第 ４ 部｜

日本航空株式会社
1. DX戦略の概要
DX戦略
デジタル・IT戦略のゴールは、顧客体験価値（CX：Customer Experience）と社員体験価値（EX:
Employee Experience）の最大化である。
デジタル技術を活用し、航空に限らない移動（MaaS）、
物販なども含めた新しい価値を提供することでCXを向上させる。また、オペレーティブな作業から社員を開放し、付加価値領域にシフトしていくEX向上の取組も最終的にはCXの向上につながる。AIやRPAによる業務効率化はもちろんのこと、整備領域では異常が起きる前に対処する予兆検知へシフトしていく。
これらの取組により事業領域の拡張とサービスの価値向上を進め、デジタルを活用して事業全体を変革していく戦略となる。
DX推進体制2021年4月にJALグループのDX推進機能を集約し、デジタルイノベーション本部を設置した。DXの取組は3つのレイヤーからなり、DXに必要な「次世代IT基盤の構築」
をIT企画本部、「ビジネスプロセスのデジタル化」をデジタルイノベーション本部のデジタル推進部、「DX推進」を同本部のイノベーション推進部が担当している。
また、グループ会社のJALインフォテックがシステム開発・運用の実働部隊となっている。DX推進に伴い、JALインフォテックを含めた内製化を強化する考えである。
外部組織連携の推進
外部ベンダーとの協業においては、従来型の発注側/受注側という関係性から脱却し、フラットな協業関係を築くことに重点を置く。この気づきを得たきっかけは、50年間利用していた旅客基幹システ
ムを、メインフレームから海外ベンダー Amadeus IT Group社（以下アマデウス）のSaaSシステムへ移行した経験である。同社は、たとえば日本のビジネスマンは精算に領収書が必要であるなど、日本固有のニーズは要件が理解できないため、日本の文化から学んでもらった。一方、当社も彼らからグローバ
ルスタンダードの考え方を学ぶことで業務変革を進めることができた。IT部門、
業務部門、
ベンダーが
いわば
「同じ船」
に乗って一体となり、大型プロジェクトの成功を目指した。
アマデウスを最終リリースした2018年にDX拠点として「JALイノベーションラボ」を開設した。
さらにデジタル関連企業や異業種のデジタル部門と相互連携してオープンイノベーションを推進する仕組みとして「ラボ・アライアンス」を構築した。ベンダー、事業会社という立場を意識することなく、対等な立場で共に新しいテーマにチャレンジしている。
2. デジタル技術活用開発手法や基盤技術の活用
デザイン思考、アジャイル開発、DevOpsなどの活用は組織的な取組となっており、実働部隊である
JALインフォテックの中期経営計画にも組み込んでいる。
デザイン思考の一例が、羽田空港のチェックイン体験を見直すプロジェクトである。従来であれば、チェックインカウンターのファシリティは設計会社、システムはベンダーに委託して作っていたとこ
ろだが、
本プロジェクトでは空港本部などと協業し、顧客思考で体験をデザインすることからスタート
した。
顧客向けのスマートフォンアプリなどでもデザイン思考を取り入れている。
マイクロサービス化は、MaaSなど事業領域が広がる中では重要性が増すと考えている。
旅客基幹シ
DX白書2021 317

ステムをSaaSへ移行した顧客向けサービスはマイクロサービス化を進めやすい。
一方、
運航システムなど他領域へ展開していくには、
レガシーシステムが課題となる。
老朽化更新のスケジュールや投資をふ
まえてシステム全体の構成を考えていく必要がある。
新技術の活用と評価
デジタルツイン、
ロボティクスの7つの技術をキーテクノ
IoT、5G、AI、
量子コンピューター、xR＊1、
ロジーに据え、
まずは小規模に実用化を進め、業務変革や新しいビジネスチャンスの獲得につなげる方針である。新技術を使うことを目的化せず、「足元で役立つこと」と「将来的に役立つこと」の2つを考えることがポイントとなる。
アイデアを出し、
プロトタイプを作成してPoCに進むが、その際イノベーション推進部のメンバーは「近くのゴール」と「遠くのゴール」を設定する。近くのゴールは3か月後で、プロトタイプ作成やPoCは
必ず3か月後にレビューを行う。
アイデアを素早く形にし、多くのトライアルを行い、早いタイミングで失敗か成功かを見極めることが目的である。
但し、3か月で近くのゴールに到達しなければ止めるとは限らず、想定外の結果であっても遠くのゴールに対しては有益という見通しがあれば、さらに踏み込んで進めることもあり、これが2つのゴールを設定する意義である。
また、
まったく新しい技術が使えるかどうかを確認する目的でPoCを実施することもある。
役立つかどうかの見極めにおいては、
メンバーの目利きも重要になる。
業務で役立つかについては業
務部門と、技術の可能性についてはベンダーやスタートアップなどとコミュニケーションを深めることで目利き力を磨こうとしている。
スモールスタートで始めた後に社内でスケールさせることは難しい課題である。投資判断をするには、事業部門が成果にコミットしなくてはならない。イノベーション推進部は、現場に深く入り込んでプロジェクトを進めることで信頼感や納得感を得、さらにマネジメントや役員と合意形成をしながら、ゴールに近づけていっている。
3. データ活用の取組
パーソナライズした顧客体験の提供など、CX向上のためには顧客データの活用が重要なテーマとなる。マイレージ会員のみならず、現在は会員以外のデータも対象としており、様々なシステムから顧客データを収集して活用を進めている。
全社的にデータ活用を推進するため、大規模なデータ基盤構築
を行った。
顧客、
レベニュー、運航、整備など、分散していた多種多様なデータを集め、ETLツールを使ってデータマートやデータレイクを構築し、必要な部分ではリアルタイム分析も行える仕組みとしている。
データアナリティクス人材の育成も進めている。
デジタルマーケティングや予兆検知などでは、AIによる高度なデータ分析も試行している。

＊1

VR（仮想現実）、AR（拡張現実）、MR（複合現実）の総称。

318 DX白書2021