Pivotal Cloud FoundryでPaaSを体験！構成管理なし・手ぶらでデプロイできる驚きの快適さにやはり感動

2017/05/17 06:00

通知

　アプリケーションは、クラウド上での運用を前提に開発することが一般化してきている。また、アプリケーションやサービスの開発はますます短期化・効率化が求められるようになり、そのためのインフラも「構築」から「調達」へ発想を切り替える必要が出てきた。昨今、PaaS（Platform as a Service）への注目が急速に高まっているのには、こうした背景がある。EnterpriseZine編集部でもこうした流れを感じ、Dell EMCが開催した「ゼロから学べる！ PaaSハンズオンセミナー」（参加費無料）に部員を参加させてみることにした。本稿はその体験レポートである。

通知

アジャイル開発でビジネス価値を最大化――それには新しいIT環境が必要

　Dell EMCはIT部門のシステム管理者やアプリケーション開発者向けに「ゼロから学べる！PaaS　ハンズオンセミナー」実施している。セミナーは「Pivotal Cloud Foundry」についての概要とハンズオンで基本操作を行う。PaaSが半日で実感できるコースとなっている。

　このセミナーを、PaaSに触れた経験はほとんどないという、EnterpriseZine編集部の市古明典が体験した。市古はこの4月にEnterpriseZine編集部へ異動してきたばかり。いわばデビュー戦である。「むしろ、あまり経験のない方に体験していただき、感想を述べてほしい」というDell EMCからの要請で、今回の体験に抜擢された。席に着くと「PivotalっていえばCloud Foundryの総本山ですよね。PaaSの高野山ですね」（市古）とよく分からないたとえを言う。そんなに無理やりなレポートは期待されていないだろう。しばらくすると講師が姿を現して、セミナーが始まった。

　講師を務めてくださったのは、EMCジャパンクラウドプラットフォームスペシャリスト吉田尚壮氏だ。吉田氏は最初に、PaaSが求められている背景から解説を始めた。

　ITを軸にして、企業はいま大きな2つの転換期を迎えている。1つはIT変革、もう1つはデジタル変革だ。後者については企業の意識が着実に変化しつつある。2016年3月にDell EMCは世界16カ国12業種の大規模・中規模企業のビジネスリーダー4000人を対象にしたデジタルビジネスに関する意識調査を実施した。これによると「自社が事業を展開している業界において過去3年間で劇的な変化を経験したことがある」との回答は全体で52％（日本では33％）あり、市場の変化に直面した割合が半数を超えている。

　競合に関しては危機感も表れている。「デジタル時代の新興企業は現在または将来における脅威である」と回答したビジネスリーダーは全体で78％、日本で74％。また、「デジタルテクノロジーが発展した結果、新たな競争企業が参入している」と回答したのは全体で62％、日本で32％だったという。

　興味深い例として、吉田氏は米自動車メーカーのフォードを挙げた。2016年1月、フォードCEOのMike Fields氏はデトロイトで開催された自動車ショーにて「今日はフォードが生まれ変わる日。モビリティカンパニーになる」と述べ、フォードが自動車メーカーから移動ソリューションを提供するサービス業となることを宣言した。

　かつて、フォードの競合といえば当然ながら自動車メーカーだった。しかし、近年新興のテスラが競合に加わり、現在ではUberだという。いまフォードは「FordPass」というスマートフォン向けアプリから、クルマの保守や操作といったサービスを提供している。

　時代が急速に転換していることはスマートフォンのアプリからも明確だ。昨今の厳しいビジネス状況を考えると、アプリには機能をいち早く搭載し、リリースできるようにしなくてはならない。そうなると、新しいIT環境が必要になる。開発言語はPython、Ruby、Node.jsで、アプリケーション実行環境はコンテナとなる。アーキテクチャはスケールアウト型で俊敏性と伸縮性を重視し、可用性はハードウェアではなくアプリケーションで担保するのが一般的だ。クライアントサーバー型のような従来のIT環境とはまるで構成要素が異なる。対照的といっていいだろう。

　にもかかわらず、企業が持つデータを活用していくためには、従来のIT環境と新しいIT環境の間でデータを共有する必要がある。そのため、企業ITは両者をうまく連携できるようにバイモーダル（次図）にしなくてはならないと、吉田氏は説く。

図1：バイモーダル（Bimodal）の概念図。左側の地が青い部分は「モード1」と呼ばれる従来のIT環境。「SoR（Systems of Record）」とも呼ばれ、システムの主目的はIT変革で、システム要件は確定的である。一方、右側の地が緑の部分は「モード2」と呼ばれる新しいIT環境。「SoE（Systems of Engagement）」とも呼ばれ、システムの主目的は（ビジネスの）デジタル変革で、システム要件は不確定（手探り）である（出典：本セミナー資料。一部改変）

　また、これを情報のサイクルから見ると次図のようになる。企業ではECサイトのデータのほかSNSやIoTからのデータも集約し、データサイエンティストらが分析し、ビジネス部門が新しい知見をサービス化し、アプリ開発担当がアジャイルに開発してECサイトに機能を追加する。

　アプリ開発担当はIT担当とDevOpsで連携し、またビジネス部門と組んでアジャイル開発を行う。アプリケーション開発はマイクロサービスを組み合わせ、環境はコンテナ技術で素早く準備するのがトレンドだ。

　「先のフォードの例はまさにアジャイル開発はじめ、新しいIT環境がなくては実現しえません。モダンなWebアプリケーション開発ではアプリケーションのビルド、テスト、リリース、メンテナンス、アップデート、リタイアといったライフサイクルを、不断に回し続けていく必要があるからです」（吉田氏）

　解説の中で次々に登場する新しいIT環境のキーワード。ただ、市古は「ビジネスで起こりつつあることと、IT技術で起こっていることがリンクされた解説でわかりやすい」と満足げだ。「こう整理して話してもらうと、概念としてそんなに難しいものではない気がしてきます。ただ、適用や実行には、自社のビジネスや顧客企業のビジネスを見直す必要がありますよね。実はそれが一番大変な作業かもしれませんが」（市古）

　吉田氏の解説は、いよいよ「じゃあ、なぜPaaSなの？」に入っていく。

コンテナ技術が抱える課題・コンテナ技術では解決できない課題

　PaaSの優位点に触れる前に、まずは改めてコンテナ技術の優位点が説明された。コンテナとは、ソフトウェアが動作する環境を1つのOS上に複数構築し、それらを切り替えて実行可能にする技術である。OSを仮想化する技術ともいえるだろう。マシンを仮想化する従来からの技術に比べ、オーバーヘッドが少なくて軽い、起動が速い、可搬性が高い、マイクロサービスに適しているといった利点がある。

　一方で、次のような課題もある。

アプリケーション開発者の負担が増える

　アプリケーション開発者にとって、コンテナは開発環境を用意しやすいだけでなく、開発したときの環境（ミドルウェアやランタイムなど）を、本番環境へそのまま持って行けることがある。しかし、裏返せば、これまでサーバー管理者が担当していたミドルウェアやランタイムの準備を、アプリケーション開発者が行うことを意味する。Ansibleなどの構成管理ツールで自動化を図る場合も、構成管理ツールに実行させる環境構築のためのコードはアプリケーション開発者が記述し、保守していく必要がある。

　また、可用性を確保するために本番環境ではクラスタ構成を組む場合があるだろう。すると、管理対象が大きく膨らんでしまう。コンテナを使用したシステムでは内部のレイヤーが増えるためだ。しかし、OSより上のレイヤーをアプリケーション開発者が構成していると、サーバー管理者やネットワーク管理者は手を出しにくい。管理の分担は以前よりずっと難しくなっている。

インフラ管理者の作業待ちで開発・公開を待たされる

　OSより下のレイヤーについては、IaaSを利用する場合であっても、仮想マシンやストレージの作成はサーバー管理者、ファイアウォール設定や負荷分散はネットワーク管理者、デプロイ後の監視設定は監視のオペレーターが担当するケースが大半だろう。すると、アプリケーション開発者は彼ら・彼女らの作業が終わるまで待たされることになる。また、依頼や確認などのやり取りにも時間がかかる。アプリケーションを実装するために仮想マシンの作成依頼を行い、実装したアプリケーションをデプロイし、管理設定などを行って公開するまでに「一般に2週間はかかってしまっている」（吉田氏）という。

図5：アプリケーションの開発開始から公開までに大きく時間を取られてしまう（出典：本セミナー資料）

　何よりこのことが生み出す一番の問題は、「責任と役割が異なる分業体制および固定的なインフラでは、柔軟かつ迅速な対応ができない」ことだと吉田氏は強調する。

【無料】PaaSハンズオンセミナーを受講してみませんか！

　本稿でレポートしているPaaSハンズオンセミナーは、どなたでも受講できます。受講は無料です。詳細やお申し込みは、こちらのWebサイトをご覧ください。

PaaSでコンテナ技術の課題を解決できる

　そこでPaaSである。アプリケーション開発者が準備・開発するものを比較すると、IaaSではミドルウェア、ランタイム、データ、アプリケーションとなるが、PaaSならデータとアプリケーションだけになる。

　吉田氏は「Dell EMCのPaaS（Pivotal Cloud Foundry、以下PCF）を導入すれば、アプリ実行環境の準備は完全に自動化します」と言う。サーバー管理者やネットワーク管理者に依頼していたインフラ構築やファイアウォール設定などが全て整う。もちろん、コンテナ機能も入っている。

図6：PaaS（Pivotal Cloud Foundry）導入後の姿（出典：本セミナー資料）

　ここまで「まるっと」そろうとワンストップで環境が準備できる。IaaSでは仮想マシンのプロビジョニングから始まり、ランタイムのインストール、アプリケーションの展開、ロードバランサーの設定、SSLの設定、データサービスへの接続、ファイアウォールの設定をしていたものが、PaaS（PCF）なら“cf push”コマンドを実行し、アプリケーションをPFCにプッシュ（アップロード）するだけで済んでしまうのだ。吉田氏によれば「1日かかっていた作業が数分で終わる」のだという。

図7：PCFならコマンド一発でアプリケーションを公開できる（出典：本セミナー資料）

　また、PCFはサービスだけでなく、ソフトウェアとしても提供されている。それを使えば、VMware、OpenStack、Amazon Web Services、Microsoft Azure、Google Cloud Platformなどの上でもPCFによるPaaS環境を用意できる。アプリケーション開発者はコードをアップロード（push）すれば、PCFが開発言語を判別し、自動的にアプリケーションの実行環境を準備してくれるのだという。

　アプリケーションをスケールアウトさせる場合も同様で、「“cf scale”コマンドを実行するだけです。後は、PCFが新しいコンテナを起動し、ロードバランサーを設定してくれます」（吉田氏）

　ここまでたっぷりの解説内容だったが、実際にはここまで約50分（10分ほど押した）。当日のプログラムによると、次はいよいよPCFを使ってPaaSを体験するハンズオン（前編）である。解説を聞いた市古は、「こんなに面倒でたくさんある作業を、アプリケーション開発者、インフラ管理者の人たちはずっと行っているとしたら、これは省力化したくなるよ〜。自動化もそうだけど、そもそも作業自体を減らさないと、アプリケーション開発に絶対集中できないよね。記事をアップするのに毎回サーバーを立ち上げたりなんて、自分なら全く御免こうむる」と漏らし、PaaSの必要性を理解した様子であった。

【無料】PaaSハンズオンセミナーを受講してみませんか！

ハンズオン前編：アカウント作成からアプリケーションのプッシュまで

　さて、ハンズオンの前編である。まずはPFCを使う準備として、PFCを提供しているクラウドプラットフォーム「Pivotal Web Services」（以下、PWS）のアカウントとスペースを作成。それから、アプリケーションをプッシュするところまで行った。PWSは、PCFをパブリックなPaaSとして提供しているサービスである。

アカウント作成からスペース作成まで

　PWSを使う場合、それへの登録が必要になる。最初だけだが、これもまた重要な作業の1つ。会場のパソコンからPWSサイトにアクセスし、試用アカウントを登録（サインアップ）する。ここは受講者のメールアドレスを用いて正規の手順で登録する。2段階認証があるため、市古は自身のスマートフォンを用いながらアカウント作成を行う。

　なお、このハンズオンでは実際に作成したアカウントでサービスを利用する。セミナーの実習では無料枠の範囲内に収まるはずなので、課金は発生しないとのことだ。課金は使用したメモリ量で課金される。吉田氏は「アカウントが不要な場合、課金が生じないように本セミナー終了後にアカウントを速やかに削除することをおすすめします」と念を押していた。

　アカウント作成を終えると、組織とスペースの作成を行う。無料試用の画面から任意の組織名を設定。市古は組織名に「Org-Ichigo」と設定した。この「Org-Ichigo」に新たなスペース「Production」を作成する。画面から［+Add a Space］をクリックしスペース名を入力して［Save］をクリックすればできあがりだ。

アプリケーションのプッシュ

　続いて、アプリケーションのプッシュを行ってみる。まずは、手元のハンズオン用Windows PC上の仮想マシンで稼働しているCentOSに、git bashというコマンドプロンプト上でLinuxコマンドを使用できるツールからログインする。このCentOSにインストールされているCloud Foundryクライアントコマンドツール「cf CLI」を使うためだ。以降、作業はLinuxコマンドを実行して進めていく。用意された手順書のとおりにコマンドを入力していくだけだが、Linuxの基礎知識があるほうが戸惑わないかもしれない。

　CentOSにログインしたら、続いてPWSにログインする。“cf login”からはじまり、API endpoint、アカウントID、パスワード、組織名、スペース名などを入力していく。コマンドのcfはCloud Foundryの意味だ。

$ cf login
API endpoint > https/api.run.pivotal.io
Email > （登録したメールアドレスを入力）
Password > （登録したパスワードを入力）
Authenticating...
OK

Select an org (or press enter to skip):
1. Org-Ichigo

Org> 1
Targeted org Org-Ichigo

Select a space (or press enter to skip):
1. development
2. Production

Space> 1
Targeted space development

　ログインが完了したら“cf push”コマンドでアプリケーションをプッシュする。このハンズオンでは、Pythonで書かれたアプリケーションが手元のPCに準備されているため、コマンドを入力すれば自動的に言語判別されて処理が進んだ。正常にアプリケーションがプッシュされ、動作を開始すると「OK」が表示される。

写真2：PCF初体験の市古氏。コマンドを実行するたび祈るような気持ち — 写真2：PCF初体験の市古。コマンドを実行するたび祈るような気持ち

　続いて、PWSの管理画面（コンソール）から作業する。先ほど選択したdevelopmentスペースの表示を見ると、プッシュしたアプリケーションが1つ稼働しているため、APPSが1になっている。

　また、developmentスペースをクリックして詳細を見ると、プッシュしたアプリケーションが「Running」と表示されている。念のため「Route」にあるURLをクリックし、プッシュしたアプリケーションのURLを開いて確認すると、ちゃんと稼働していることが分かる。アプリケーションはWebで公開されているから、スマートフォンからも確認してみる。

　ハンズオン前編の最後に、アプリケーションのDeleteも体験してみようと、吉田氏から指示が出た。developmentスペースに表示されているアプリケーション名をクリックし、アプリケーションの詳細画面を開く。そこで［Delete App］をクリックすると、アプリケーションはたちどころに削除された。組織の管理画面を開くと、アプリケーション数（APPS）が0になっているのが確認できた。

図14：［Delete App］をクリックしてプッシュしたアプリケーションを削除

　ここまで、とりあえず用意されたサンプルアプリケーションをプッシュし、動作を確認した後、アプリケーションを削除するまでの一連の作業を体験した。「“cf push”コマンドを実行するだけで、アプリケーションのコードがアップされるだけでなく、デプロイされ、アプリケーションが動きだすのはすごい！」と市古。PaaSでなければ、もっと手数が掛かるだろう。

　一方で、「組織」や「スペース」といったCloud Foundryの概念を知らないまま作業し、動作を確認してきたので、何をやっているのかまでは理解できなかったようだ。この辺りも併せて理解できると、もっと楽しいのかもしれない。

【無料】PaaSハンズオンセミナーを受講してみませんか！

Pivotal Cloud Foudryの特徴やメリット

　ハンズオンの前編を終えると、本セミナーは後半戦へ。まずは再び座学になり、吉田氏が改めてPCFについて解説を行った。

　今ではPCFのほかにも、Heroku、IBM Bluemix、Google App Engine、OpenShiftなどのPaaSが提供されている。それらの間には、Cloud Foundryをベースにしているかどうか、オープンソースかどうか、プライベートクラウドとパブリッククラウドのいずれで使えるのか、といった違いがあるという。PCFはCloud Foundryをベースに、運用管理の標準化やエンタープライズへの最適化が加えられている。

図16：PCFの構成。open source componentとあるのはCloud Foundryの機能。PCFはそれに加えてcommercial extensionとある機能も持つ（出典：Pivotal Documentation「Pivotal Cloud Foundry v1.10 - [Cloud Foundry Overview]」） — 図16：PCFの構成。open source componentとあるのはCloud Foundryの機能。PCFはそれに加えてcommercial extensionとある機能も持つ（出典：Pivotal Documentation「Pivotal Cloud Foundry v1.10 - Cloud Foundry Overview」）

　PWSはその名のとおり、PivotalのWebサービスである。主要コンポーネントの設定やサービス登録をGUIで実行する。中でもよく使うのは管理画面の「Applications Manager」だろう。アプリケーションやスペース、ユーザー、サービスをGUIで管理できる。

　吉田氏は、PCFの強みを「アプリケーションの高可用性を標準装備しているところ」と説明。自分のプロセスを自分で監視しているため、アプリケーション障害、ネットワーク障害、プロセス障害が生じても自動で復旧するのだという。これにより、データセンターやラックでの障害に対しても可用性を担保している。

　メリットは運用だけではない。これまでも述べてきたように、アジャイル開発の効率を高めることができる。クラウド（IaaS）を選ばないのも強みとなるだろう。「本番用にパブリッククラウドを使い、開発用にプライベートクラウドを使っていたとしても、どちらもPCFが使えるので環境ごとに使い分ける必要がありません」（吉田氏）

　日本国内ではYahoo! JapanやNTTデータがPCFを導入。また、米国の相互保険会社Allstateは、PCFを導入したことで「月曜日に新しい保険サービスが考案されると、金曜日には提供できるようになった。従来の慣習や手法を変えるすばらしいプラットフォームだ」と話しているという。

　PCFの導入効果として大きいのはプロジェクトの時間短縮や工数削減だ。「導入企業では、アプリケーション開発、インフラやミドルウェアのプロビジョニング、テスト、アプリケーション展開、スケールアウトなどに9か月かかっていたところ、平均で10週間にまで短縮できました。従来の3分の1です」（吉田氏）

【無料】PaaSハンズオンセミナーを受講してみませんか！

ハンズオン後編：アプリケーションのスケールアウトとブルーグリーンデプロイメント

　続いて、ハンズオンの後編である。ここでは最初に、アプリケーションのスケールアウトが、PWSではいかに簡単に実行できるかを体験した。2つ目のサンプルアプリケーションは、アクセスしたアプリケーションのインスタンス番号を表示するというものだ。このアプリケーションをプッシュした後、“cf scale”コマンドを実行して、アプリケーションのインスタンスを5つへ増やす。

$ cf scale appichigo02 -i 5

　appichigo02は、プッシュ時に参照される設定ファイル「manifest.yml」で指定した、このアプリケーションのホスト名である。“cf app”コマンドを使うと、PCFから稼働中のapp-ichigo-02アプリケーションに関する情報を取得し、インスタンスが5つに増えていることを確認できた。

$ cf app app-ichigo-02
Showing health and status for app app-ichigo-02 in org Org-Ichigo / space development as (PWSに登録したメールアドレス)...

name:              app-ichigo-02
requested state:   started
instances:         5/5
usage:             128M x 5 instances
routes:            appichigo02.cfapps.io
last uploaded:     Mon 08 May 16:22:37 JST 2017
stack:             cflinuxfs2
buildpack:         python 1.5.18

     state     since                  cpu    memory         disk           details
#0   running   2017-04-06T07:24:09Z   0.1%   8.2M of 128M   164.9M of 1G
#1   running   2017-04-06T07:29:43Z   0.2%   8.2M of 128M   164.9M of 1G
#2   running   2017-04-06T07:29:43Z   0.2%   8.3M of 128M   164.9M of 1G
#3   running   2017-04-06T07:29:43Z   0.2%   8.3M of 128M   164.9M of 1G
#4   running   2017-04-06T07:29:42Z   0.0%   8.2M of 128M   164.9M of 1G

　また、PCFでは特定のインスタンスへアクセスが集中しないように、5つのインスタンスの間でアクセスを振り分け、ロードバランスを自動的に効かせてくれる。実際に、セミナー会場のパソコンやスマートフォンでアプリケーションにアクセスしてみると、表示されるインスタンス番号が毎回異なった。アクセス先のインスタンスが振り分けられている証拠である。

図17：市古氏のスマートフォンでインスタンス番号を確認。このときには4番目のインスタンスにアクセスした — 図17：市古のスマートフォンでインスタンス番号を確認。このときには4番目のインスタンスにアクセスした

　次に体験したのは「ブルーグリーンデプロイメント（Blue Green Deployment）」。ブルーグリーンデプロイメントとは、稼働中のアプリケーションに対してパッチの適用やアップグレード、古いバージョンへのロールバックを行う場合に、アプリケーションのダウンタイムを最小化するための手法。具体的には、現行バージョンと並行して、変更を加えたバージョンのアプリケーションをしばらく稼働させ、ユーザーに両者を区別なく利用してもらい、問題がないかどうかを確認する。変更を加えたバージョンでも問題のないことが明らかになったら、現行バージョンから変更を加えたバージョンへ切り替えるというものだ。

　次図は、このハンズオンで体験したブルーグリーンデプロイメントの流れである。

図18：ハンズオンで体験したブルーグリーンデプロイメントの流れ（出典：本セミナー資料）

　xxx-blueが現行バージョン、xxx-greenが変更を加えたバージョンのアプリケーションで、アプリケーションにアクセスするURL（これをルートという）はxxx-pro.cfapps.ioである。xxx-temp.cfapps.ioで進めていたxxx-greenの開発が終わったので、これからブルーグリーンデプロイメントでxxx-greenの動作確認を行う（図のBeforeの状態）。そのため、xxx-pro.cfapps.ioでもxxx-greenにアクセスできるようにし、ユーザーにはxxx-blueとxxx-greenのどちらにアクセスしているか分からなくしてアプリケーションを利用してもらう（図のDuringの状態）。それで何も問題がなければxxx-greenへ移行して差し支えないと判断し、xxx-pro.cfapps.ioからxxx-blueへのルートを削除して、xxx-greenへの移行を完了させる（図のAftreの状態）。

　まず、上図のBeforeの状態を作る（①）。xxx-blueアプリケーションをxxx-pro.cfapps.ioというルートで、xxx-greenアプリケーションをxxx-temp.cfapps.ioというルートでプッシュした（市古はxxxをichigoとした）。次に、Durgingの状態を作るため、xxx-greenに、xxx-blueと同じxxx-pro.cfapps.ioというルートを付加する（②）。これは“cf map-route”コマンドを使って行う。最後にAfterの状態を作るため、“cf unmap-route”コマンドでxxx-blueへのルートと、xxx-greenへの元のルート（xxx-temp.cfapps.io）を削除する。

①Beforeの状態を作る。xxx-blueのコードはblueディレクトリ、xxx-greenのコードはgreenディレクトリに入っていた。
$ cd blue
$ cf push xxx-blue -n xxx-pro

$ cd ../green
$ cf push xxx-green -n xxx-temp

②Duringの状態を作る。
$ cf map-route xxx-green cfapps.io -n xxx-pro

③Afterの状態を作る。
$ cf unmap-route xxx-blue cfapps.io -n xxx-pro
$ cf unmap-route xxx-green cfapps.io -n xxx-temp

　なお、各状態で正しくアプリケーションが稼働し、ルートを追加、削除できたことを確認するため、折に触れて“cf apps”コマンドを用いた。

　また、「アプリケーションのスケールアウトと新バージョンへの移行って、実は面倒だったり、神経をすり減らしたりするんじゃなかったけっけ？」というのが、市古の偽らざる感想のようだ。ハードウェアからミドルウェア、ランタイムまでの管理や操作をクラウド側でやってくれることのありがたさ、便利さ。たった1つや2つのコマンドを発行するだけで、あとは「おまかせ」なのである。コンテナ技術のメリットを活かす面でも、PaaSは積極的にトライしてみる価値があるだろう。

　ここまでで当初予定のハンズオンは終了である。ただ、この日は時間が残ったということで、キーバリューストア「Redis」のサービスをアプリケーションに追加する作業まで行うことができた。最後に吉田氏は「PaaSはデジタル変革に最適なプラットフォームです。そしてPFCは実績豊富なエンタープライズPaaSです。今日のハンズオンで簡単に使えることがお分かりいただけたと思います。ぜひ今後活用してみてください」と述べ、セミナーを締めくくった。