espar (Page 7)
2018.03.16 (Fri)

(所要時間 : 約3〜4分)

3月12日、東京は飯田橋で開催された daab Developers Summit 2018 で登壇させて頂きました。

20180316_daabdevsummit2018

スマホ向けのビジネスチャットサービスである direct の開発者向けイベントです。direct の開発元 LisB さんが daab 発表3周年を記念して主催されました。

daab とは direct agent assist bot の略で direct というビジネスチャットをプラットフォームとした、チャットボットを提供する為の仕組みのようなものです。slack 向けボットでも使われる Hubot がベースになってます。

 

弊社とdirect

directを提供されてるLisBさんと弊社との関係は実は結構長く、それこそdirectがローンチする前からのお付き合いです。社長の横井さんとのご縁がきっかけで、そこからはや10年近く…になるでしょうか。

20180316_businesschat
(Thanks! the photo on flickr by William Hook / CC BY-SA 2.0)

directがまだクローズド版だった時に使わせて貰いました。ビジネスチャットという着眼点は素晴らしいなぁと LisB さんを羨ましく思ったものです。

当時、弊社のファイル共有サービスSYNCNELが思うように拡販できてなかった時期だからかも知れませんが(笑)、自社ビジネスを持つ会社あるあるの隣の芝は青い心境で、スマホ向けビジネスチャットの国内黎明期を羨ましく見てました。これは絶対盛り上がるでしょと。

その後、前述の daab を2014年末に発表されます。チャットツールをサードベンダーがボットを作って拡張できるというんです。LINEの BOT API の発表が2016年4月ですから、如何に早いかが分かりますね。

20180316_daab

リリース前に構想をお聞きして、軌道に乗り始めていた自社のSYNCNELと連携させようという流れで、daab の開発パートナーにならせて貰いました。SYNCNELのロゴも載せて貰ってましたかね。

1年半後の2016年2月、弊社はSYNCNELを富士ソフトさんに事業譲渡しますが、その橋渡しをして下さったのが LisB さんです。何がどう繋がるか分かりませんよねホント。

そんなご縁で今もお付き合いさせて頂いてるという訳です。弊社は今 direct の一販売代理店とならせて貰い、導入支援/運用支援もしています。

20180316_daabdevsummit2018_ft
(参加人数は60人弱ぐらい。ほとんどがSIerさんなどの開発関係者だったかと)

一個人として、国内スマホ向けビジネスチャットの歴史を身近に見てきましたけど、間違いなく direct はその先駆けで(当時chatworkはスマホ最適ではなかった)、今でこそ流行りのビジネスチャットボットのコンセプトを最初に打ち出したのもまた direct なんですよね。

だから応援の意味もあってお付き合いを続けさせて貰ってます。プロダクトとしても良くできてますし。(どこ目線だw)

 

ビジネスチャットの役割

僕は、情報セキュリティレベルが低い国内事情も、生産性が低いと言われて久しい日本企業の実態も、諸悪の根源は「メール」であると考えてます。

メールを廃止すれば、いわゆる働き方改革(?)をやらなくても生産性は劇的に上がりますし、国内セキュリティインシデントも半分以上は無くせるし、際限なく掛かるように思える情報セキュリティ費用も極小化できると思ってます。

20180316_businesschatrole
(発表で使ったスライドの1つ。社内で両者のためにメールを使うべき理由は皆無)

実際、directを始めとするビジネスチャットツールは、社内コミュニケーションとしてのメールを激減させました。人と人との会話はメールよりよほど効率的ですし、スパム誤判定による喪失や大量のメールに埋もれる事もありません。

社内コミュニケーションに使うメールと対比すれば、ビジネスチャットにはメリットしかないのです。

でも、社内のメールを無くすという観点で唯一 direct に欠けていると思っていたのが、社内を飛び交う通知メールをどうにかする手段でした。システムからのアラート、定期的な営業レポート、グループウェアからの通知、IoT機器からのお知らせ…。これらを、簡単に、あらゆるシステムから、あらゆる言語から direct に通知として容易に流せたら良いのにと。

でも、ボットサーバを立てるアーキテクチャではこれが面倒なんですよね。

20180316_makeallbots

LINE WORKS も同じです。ボットは作れますが、特定のチャットルームに通知を送るだけの為に別サーバを立てて環境を作る必要があります(Serverlessという手段もありますが、別に用意しないといけないという意味では一緒)。

この点、REST API を備えて手軽に通知を放り込める slack や chatwork のほうが優位です。

例えば、以下に示すのは chatwork に通知を送る GAS のコード。Google SpreadSheet の編集時にB1セルの値を通知するってなことが、

CHATWORK_WEBHOOK_API_TOKEN = '1234567890abcdef1234567890abcdef';
CHATWORK_WEBHOOK_API_ENTRY = 'https://api.chatwork.com/v2/rooms/12345/messages';
var options = {
  'method' : 'post',
  'headers' : {
    'X-ChatWorkToken' : CHATWORK_WEBHOOK_API_TOKEN,
  },
  'payload' : 'body=' + SpreadsheetApp.getActiveSpreadsheet().getSheetByName("sheet").getRange("B1").getValue()
};
UrlFetchApp.fetch(CHATWORK_WEBHOOK_API_ENTRY, options);

とたった数行で書けます。これを書くのに5分もかかりません。普段使ってて慣れてますから。サーバも特別な環境も不要です。

slackならもう少し簡単ですね。

SLACK_WEBHOOK_API_ENTRY = 'https://hooks.slack.com/services/T00000000/B99999999/123456788912345678901234';
var options = {
  'method' : 'post',
  'payload' : 'payload={"username":"webhook","text": "' + SpreadsheetApp.getActiveSpreadsheet().getSheetByName("sheet").getRange("B1").getValue() + '"}'
};
UrlFetchApp.fetch(SLACK_WEBHOOK_API_ENTRY, options);

って書くことができます。このシンプルさは通知用の REST API (webhook) があらかじめ用意されているからです。

シンプルさとセキュリティは相反するのでバランスが重要ですが、シンプルに提供できるならビジネスチャットツールで社内通知を根絶できます。実際、弊社は通知系を基本 slack に集約していて、社内でのメールも、社内システムからのメールも一切ありません。

20180316_slack

そこで、今回冒頭で言及した daab を使って、direct への通知を REST API (webhook) として実現するようなボットを作ってデモしました。

20180316_daabwebhook

やっぱ応援しているプロダクトが他の競合プロダクトに負けてるかもって思う事があると悔しいじゃないですか。で、実際に動くものを作って見せれるというのは開発者・開発会社の良いところなので作ってみた次第です。中のエンジニアの方にも面白がって貰えたようで良かったなと。

directが標準で REST API を搭載するまで、今回作ったボットを使って社内で運用、また espar など静的化製品での活用を考えてます。

 

以上、イベント参加報告でした。他の登壇者の方も、AIやIoTやEDIやRPAなど、ボットを使って色んなことができるってことを紹介されていて、聴講者としても面白く且つ勉強になるイベントでした。

先日の MobileAct といい開発者向けイベントに登壇することが増えてます(増やしてます)。これからも機会あればアウトプットしていきたいと思います。


2018.02.20 (Tue)

(所要時間 : 約2〜3分)

昨年6月からはじめた静的化サービスのesparですが、おかげ様でお問い合わせやお引き合いを沢山頂いており、実績も着実に増えつつあります。

対象となるサイトは当初の想像通り、ほぼ全て WordPress です。

20180220_espararchitecture

esparの基本的な仕組みは、

  • CMS側(WordPress等)の設定を何も変えることなく
  • 弊社の静的化エンジンが外からhtm化(静的化)して必要ファイルを収集し
  • 弊社のホスティング環境でホストし
  • DNSを弊社ホスティング環境に切替えてもらう

というもので、絵にするとまさに上図のような感じで実現しています。

google bot のようなものが対象サイトの全ページをクロールする仕組みと同じですので、対象となるサイトには弊社の静的エンジンからのアクセスが必要になるのが特徴です。

 

20180220_engine
(Thanks! the photo on flickr by bark / CC BY 2.0)

静的化エンジンを内部に持ちたい

通常は外からのアクセスが普通にできるので問題ないのですが、医療機関・自治体・財団法人など公的色合いの強いWebサイトの場合、そうはいかない場合があります。

例えば、院内のプライベートネットワークに WordPress 環境があって院内から関係者が編集、全体を静的化してインターネット上の公開サーバに転送…ってことをしたい場合があります。あるいは、そもそも外からの余計なアクセスをNGとしているサーバ環境に WordPress を構築している例もあったりします。

20180220_esparonpre
(プライベートネットワークにWordPressがあると外から静的化できない)

このような環境のサイトには、従来のesparは導入できませんでした。外から静的化させて貰えませんから。そこで今回、御客様の要望にお応えする形で espar WP Plugin という新商品を開発しました。

『弊社の静的化エンジンを WordPress のプラグインにしました』

ということですね。Go言語で実装したエンジンを WordPress プラグインの仕組みでラップしています。宜しければプレスリリースも御覧下さい。

 

20180220_staticpress
(静的化プラグインでは一番有名な Static Press)

既存の静的化プラグインとの違い

実は、WordPressの静的化プラグインって幾つもあります。

国内だと Static Press が一番有名でしょうか。WordPressのプラグインではないですが、古くからあるwgetというWebサイト取得ツールもありますね。

無償のものがあるのに、今回 espar WP Plugin を出したのは何故か。何が違うのか。理由(優位性)は主に3つあります。

1. 速度

Static Press しかり Really Static しかり、wget もそうですが既存のものはとにかくスピードが出ません。

並列処理をしているかどうかが大きな差なのですが、esparのエンジンは並列処理が得意なGo言語の特性をフルに活かしているので高速です。サイトやページ構成にも依りますが普通に10倍ぐらい早いこともあります。

2. 静的化クオリティ

既存のものは静的化を巧くできないケースが散見されます。静的化って結構複雑なんですよね。

  • CSSのbackground:url()属性に指定されている画像
  • html5のsvgタグやdata-属性の中身
  • jQueryで制御された<a>タグではないタグによるリンク先
  • ページからはリンクされていない画像やPDFデータ

など、静的化においては、解釈できなければいけないこと、取得できなければならないもの、が沢山あるのです。既存のものはこれらを取得できないことが多く、それはサイトの静的化品質にそのまま繋がります。

esparは2年以上も静的化エンジンという用途に特化して進化させてますから、クオリティは圧倒的に高いんですよね。つまり再現性が高くて、そこには自信があります。

3. 設定は全部お任せ

WordPressプラグインのインストールからエンジンの設定、公開サーバの設定まで全部弊社で実施します。「このサイトを静的化したいんです〜」と丸投げして頂ければ、数日のうちにWebサイトの静的化が完了します。

動的な要素(問合せフォームや検索)などの機能と共存も可能です。

 

このようなメリットがあって、御客様もそれを期待して頂いていたので、商品としてリリースすることにしました。既に都内の某財団法人様においては導入済みで本番稼働しております。また、某金融系企業様にも導入がほぼ決まっています。

という訳で新商品のご紹介でした。

今回発表の espar WP Plugin は、WordPressサイトの運用で陥りがちな課題を一挙解決する最もコストパフォーマンスが高い商品であると自負しております。WordPressの高速化やセキュリティにお悩みの方は是非ご連絡下さい。


2018.02.08 (Thu)

(所要時間 : 約1分)

待ったなしの常時SSL化。

メリットを体感できず面倒くさい、というのが対応進まない最大の理由です。でも周りのサイトがほぼ対応してる…ってなってくるとそうも言ってられなくなりますね。

それが狙いで、一つの指標とすべく2017年12月よりやっている、国内上場企業サイトの常時SSL化対応調査の2018年2月版をお届けします。ザックリこんな感じ。

20180208_sslratio
(もう2018年だというのに上場企業でさえ、まだ半分に届いていない…)

 

常時SSL化の対応状況 2018年2月

このレポートが初めての方の為に調査方法を改めてご紹介すると、

  • 日本取引所グループが公開する銘柄一覧を元に上場企業URL一覧を作成
  • TOPページが https 対応していれば常時SSL化対応済みとみなす

という調査です。2018年2月の上場会社数は3601社で、2018年1月より上場会社の数は少し減りました。

一方で常時SSL化をしている上場会社の割合は少し上がり、前回より0.8ポイントアップの48.7%となりました。数にして26社増。

先々月から先月も似たようなものなので、だいたい1%UPぐらいで増えていってるのかも知れません。相変わらず半数にも至ってないのが残念ですが、この調子で行けば5月初旬には祝半分!になるのではないでしょうか。

2018年2月レポートの詳細を、こちらから御覧頂けますので宜しければどうぞ。

 

EV証明書対応サイトが増えた

驚いたのは、EV証明書対応サイト数の伸び。

20180208_websecurity.jpg
(Thanks! the photo on flickr by FutUndBeidl / CC BY 2.0)

前回はプラマイゼロだったのに対して、今回はグンッと増えました。

  • ETSホールディングス(1789)
  • ケアサービス(2425)
  • すかいらーく(3197)
  • Minoriソリューションズ(3822)
  • 日本碍子(5333)
  • 千趣会(8165)
  • いちよし証券(8624)

EV対応していた企業が上場廃止になったケースが今回も2社ありましたが、全体ではプラス5社。割合にしてEVだけで見ると、3%アップです。非常にいい傾向ですね。

まだ常時SSL化していない上場会社はCSR的に論外だと個人的には思っていますが、ホントは全ての上場企業がEV証明書にすべきです。投資家や対顧客への情報発信姿勢としてなぜたった年数万円が支払えないのか、webに対する意識が低いってことだろうなぁと悲しい気持ちになりますね。

 

という訳で2018年2月の常時SSL対応レポートでした。来月もまたレポート致します。

余談ですが、上場企業に限らず、何かのククリで常時SSL化対応状況を知りたいというリクエストがあれば是非ご連絡下さい。URL一覧があれば調査できるので検討させて頂きます。


2018.01.11 (Thu)

余り進んでいないように見える常時SSL化。もう2018年だというのにどうしたものか。

そんな思いもあり、国内サイトの対応状況を知る指標にできればと、国内上場企業サイトの常時SSL化対応調査を昨年12月に行いました。ScanNetSecurityさんに掲載されるなど少しばかり反響もありました。

20180111_scannetsecurity

この手の調査は継続しないと意味がありませんので、定点観測として毎月行っていくことにしています。で、本日2018年1月度版のレポートを公表しました。

 

常時SSL化の対応状況 2018年1月

調査条件は前回と変わらず以下の通り。

  • 2017年12月末時点の銘柄リストからpickupした全上場企業3604社(19社増えた)
  • 2018年1月10日時点での常時SSL化対応状況を調査
  • 企業サイトのTOPページがhttps対応していれば常時SSL化済みとみなす

対応サイト数は1729社で国内全上場企業の3604社に対して47.9%です。相変わらず半数にも至ってないのが残念なところですが、前回より36社が対応となりましたので微増ですね。全く増えないよりは良いのでしょう。ただもっと勢い良く増えていくと良いなと思います。

今回のレポートについては、詳細をこちらから御覧頂けますので宜しければどうぞ。

EV証明書対応サイトはプラマイゼロ

常時SSL化に使用する証明書はEV/OV/DVの3種類。上場企業は信頼性が一番高いEV証明書を採用すべきだと個人的には考えてます。

20180111_ssltype.png

EV証明書採用企業一覧をレポートに記載しているのはそれが理由。セキュリティ意識が高い企業である(または担当制作会社がセキュリティ意識が高い)のは間違いありません。

今回、EV証明書対応サイトが一社追加された(大同特殊鋼(5471))のですが、EV証明書対応していた別の会社が上場廃止となった為に152社から変わらずです。全体の4.2%で、まだまだ少ないですね。

 

という訳で2018年1月の常時SSL対応レポートでした。このペースでいけば春先には半数越えるぐらいになるのでしょうか。また来月もレポートいたします。


2017.12.22 (Fri)

常時SSL化はなかなか進みませんね。http なサイトは今でも結構沢山見ます。もう2018年を迎えようというのにどうしたものか。

何ごとも改善するには、また、改善されたことを把握するには、何か指標が必要だろうということで、国内の全上場企業サイトの常時SSL対応状況を調べてみました。半自動+目視です。頑張った(笑)

で、その結果を本日プレス発表した次第です。プレスはこちらで、詳細なレポートページはこちらです。

20171222_report

日本は常時SSL化レベル最下位?

日本のWebサイトにおける常時SSL化対応状況が余り芳しくないことは、Googleが定期的に発表している統計にも現れています。Chromeユーザのhttpsリクエストベースの統計なんですが、

20171222_googlechrome
(米Google HTTPS encryption on the web より)

Chromeユーザが多い主用10カ国でほぼ常に最下位なんですよね。Chromeに偏っているとは言えhttpsリクエスト数が少ないってことは、日本で常時SSL化に対応してないサイトが少ないことを物語っている訳です。

…じゃぁ、実際どの程度少ないのだろう?と思ったのが本調査のきっかけでした。

上場企業のWebサイトの傾向が日本のWebサイト全体の傾向とイコールである筈もないですが、一つの指標にはなると思います。詳細はプレスリリースやレポートページを確認して頂けると嬉しいのですが、

20171222_ssltable

こんな感じ。実に47.2%。少ない…。

2015年頃から常時SSL化の声が高まり始めてることを鑑みると、2年が経過した今でも上場会社の半分も未対応というのはちょっと残念ではあります。

上場企業だからこそサイトを常時SSL化することは面倒で大変な筈ですが、でも見方を変えるとサイト閲覧者の通信を守るというセキュリティの優先度がずっと上がってこなかった証拠ですから、CSRという観点でも余り宜しくはないと思う次第です。

 

調査から気がついたこと

やはり業種ごとに傾向が現れます。以下は17業種コードで常時SSL化対応とその証明書種別の割合を並べたものです。

20171222_ssltable_categories17

ある程度の想像はしていましたが、いわゆるIT企業(17業種コードで「情報通信・サービス」)は対応比率が高かったです。高かったと言っても55%なのでまだまだ伸びしろがあるという意味では他業種と余り変わりませんが。他に目についたのは金融系企業のEV証明書採用率。当然っちゃ当然なのですが、他業種を圧倒するEV証明書率が特徴です。

個人的には、CSRの観点から上場企業は全部EV証明書にしましょうよ…と思ってます。

逆の視点では、既にEV証明書を取り入れている企業は、経営者やWeb関係者、あるいは制作担当会社のセキュリティ意識が高いということを表しているといえるでしょう。

 

目指すは上場企業の全サイト常時SSL化

Web全体の常時SSL化が進むかどうかは、一社の努力だけでどうこうなるものではありません。でも今回の調査を通して、自分は常時SSL化をもっと啓蒙していく必要があることを再確認できました。上場企業の半分以上がまだ対応できてないのですから。

20171222_https

今回の指標が多くの人に共有されて、関係者が常時SSL化への一歩を踏み出すきっかけになってれたら嬉しいなと思います。安心・安全なWebの未来の為に。

ちなみにプレスリリースにも書いたのですが、上場企業の常時SSL対応状況調査は、定期的に実施して結果を公表していく予定です。