【日経コンピュータ】電子社印「eシール」制度化へ～EU手本にGMOなどが先行～
日経コンピュータのニュースに「電子社印「eシール」制度化へ～EU手本にGMOなどが先行～」が取り上げられましたので、紹介します。
社印（角印）とは
概要
- 企業が発行する請求書、領収書に広く使用されている
- 企業が使う認印的な存在
社印（角印）の欠点
- 書類にハンコを押印するため、印刷、封入、郵送などの手間がかかる
- 新型コロナウイルスの感染拡大防止のために電子化のニーズが高まっている
社印の代替になる「eシール」とは
- 社印の電子版、電子署名の企業版の位置づけ
- 自社で作成したPDFなどの電子文書にeシールを付与する
- データの信頼性を確保する仕組みである「トラストサービス」の1つ
「eシール」の2つの機能
- 文書を作成したのは自社であることの証明
- 文書は作成後に改ざんされていないことを証明
必要となる法整備
既に実用化しているEU
- 「eIDAS（イーアイダス）規則」という法制度に基づき、実用化
日本での法整備
eシール事業進出を発表した2つの事業者
GMOグローバルサイン
- 電子認証サービスを手掛ける企業
- 2020年6月に日本版eシール対応のサービス設計、開発の開始を発表
- 総務省での検討を踏まえて日本版eシール対応サービスを提供
帝国データバンク
- 企業調査情報を提供する企業
- 2020年6月に日本版eシール対応のサービス設計、開発の開始を発表
- 同社が公表する企業調査情報の改ざん防止に使用する予定
- 電子認証サービス会社との連携も視野
自治体も動き出した
2020年7月に福岡県飯塚市が実証事業を2021年に実施することを発表
住民が遠隔地から各種証明書をスマホアプリで受け取れるサービス
- 住民票などの各種証明書データに独自のeシールやタイムスタンプを付与
- データの作成時刻やデータの改ざんがないことを証明
期待するサービスの効果
- 窓口交付の多い住民票のリモート化による業務効率化
- 住民票以外の課税証明書など他の証明書への拡大を期待
- 飯塚市が発行した証明書を企業などが確認、保存利用する社会実装を目指す
【WEBを支える技術】HTTPヘッダ編～～
- HTTPヘッダの重要性
- HTTPヘッダの生い立ち
- 日時
- MIMEメディアタイプ
- 言語タグ
- コンテントネゴシエーション
- Content-Lengthとチャンク転送
- 認証
- キャッシュ
- 持続的接続
- その他のHTTPヘッダ
- まとめ
HTTPヘッダの重要性
- メッセージボディに対する付加的な情報（メタデータ）を表現
- クライアントとサーバはヘッダを見てメッセージに対する挙動を決定する
- メディアタイプなや言語タグなど、アプリケーションのフレームワークでなく、実装者が設定するヘッダも多い
HTTPヘッダの生い立ち
- HTTP1.0から登場
- 電子メールのメッセージ仕様のヘッダ形式をもとに追加
→ インターネットの成長とともに規定された歴史 HTTP1.0から登場ヘッダと電子メールのメッセージヘッダと共通部分が多い
例）Content-Type、Dateなど歴史からくる制約、バッドノウハウも多い
- メール：7bit ASCIIコード以外の文字が入れられない
- HTTP：文字エンコーディングの制限でラテンアルファベット以外い入れられない
電子メールとの違い
- メール
- 1方向にしかメッセージのやり取りができない
- HTTP
- 一度の通信でリクエスト/レスポンスの2つのメッセージをやりとり
- メール
日時
MIMEメディアタイプ
- メッセージでやり取りするリソースの表現の種類を指定
電子メールからきた仕様（Muktipurpose Internet Mail Extensions）
Content-Type
- メディアタイプを指定する
- タイプとサブタイプで構成
charsetパラメータ
言語タグ
コンテントネゴシエーション
- メディアタイプ、文字エンコーディング、言語タグはサーバーで指定
クライアントと交渉して決めることができるパラメータ
Accept
- 処理できるメディアタイプを伝える
- メディアタイプに優先順位をつける
- サーバーがクライアントからの要求にこたえられない場合、「406：Not Acceptable」
Accept-Charset
Accept-Language
- 処理できる言語を伝える
- 自然言語に優先順位をつける
Content-Lengthとチャンク転送
Content-Length
- ボディの長さを指定する
- 静的ファイルなどあらかじめサイズがわかっている場合
Transfer-Encoding:chunked
- チャンク転送
- ボディを分割して転送する。
- 動的に画像生成する場合など、ファイルサイズが決まるまでレスポンスが返せない場合に応答性能が低下するのを防ぐ
- チャンクサイズは16進数を仕様
- HTTP1.1で受信が必須仕様
認証
HTTP認証方式
Digest認証
- セキュアな認証方式
- 認証なしでリクエストして、レスポンス情報から認証情報を生成し、再送信する
チャレンジ
再送信
利点
- パスワードに関するセキュリティリスクを低減
- パスワードを盗まれる危険性がない
- パスワードそのものを預けなくてもよい、パスワードのハッシュ値を保管すだけ
- パスワードに関するセキュリティリスクを低減
欠点
- パスワード以外のセキュリティリスクは回避できない
- パスワードのみを暗号化
- メッセージ自体は平文でネットワーク上に流れる
- クライアント側の負担が大きい
- 同じURI空間でも毎回チャレンジして、ダイジェストを生成する必要がある
（nonceを取得するため）
- 同じURI空間でも毎回チャレンジして、ダイジェストを生成する必要がある
- パスワード以外のセキュリティリスクは回避できない
普及していない理由
WSSE
キャッシュ
- サーバから取得したリソースをローカルストレージに蓄積し、再利用する手法
ローカルストレージにキャッシュしたデータそのものをキャッシュと呼ぶこともある
ヘッダ（サーバーへのアクセスをしない）
Pragma
- キャッシュを抑制
- 「no-cache」のみ指定可能
- 指定された場合は必ずサーバーにアクセスする
- キャッシュを抑制させない場合に指定（Cache-Controlにも指定）
Expires
- キャッシュの有効期限を示す
- クライアントが有効期限内からサーバーへのアクセスを行うか判断する
- 最長1年を推奨
- 有効期限が明確に決まっている場合に指定
Chache-Control
- 詳細なキャッシュ方法を指定する
- HTTP1.1で追加、Pragma、Expiresを代用可能
- 相対的な有効期限設定が可能
- 有効期限が相対的に指定したい場合に指定
条件付きGET
- サーバーに判断してもらう
クライアントではキャッシュ利用不可と判断された場合でもリクエストヘッダに情報を詰めて、キャッシュ利用可否をサーバーに判断してもらう
if-Modified-Since
- リソースの更新日時を条件にする
if-Non-Match
- リソースのEtagを条件にする
- サーバーがEtagを出している場合に利用、正確な更新有無が判断可能
静的ファイルの場合
- Webサーバーで判断可能
- inode番号、ファイルサイズ、更新日時から自動計算可能
動的リソースの場合
- アプリケーションで判断する
- 生成したHTMLなどからEtagを算出
- サイズが大きなリソースや複雑なクエリが発生する場合はメタデータで生成、リソースの更新カウンタから算出
持続的接続
- HTTP1.1からの追加機能
問題
解決
- 都度接続、切断を繰り返すのではなく、接続し続ける手法が開発
- HTTP1.0ではオプション（keep-alive）
- HTTP1.1ではデフォルト
- パイプライン化
- クライアントはサーバからのレスポンスを待たずに同じサーバーにリクエストを送信可能
- コネクションを切断したい場合、（Connection:close）を指定
その他のHTTPヘッダ
- Content-Disposition
- サーバがクライアントにファイル名を提示
- 電子メール仕様から伝承
- 文字エンコーディングが必要
まとめ
- HTTPヘッダはメソッドやステータスコードと組み合わせて認証やキャッシュなどのHTTPの重要な機能を実装
- 電子メールや文字エンコーディングは深い歴史があり、バッドノウハウを引き継いでいる。
- HTTPヘッダをうまく利用するためにサーバやブラウザだけでなく、電子メールや文字エンコーディングの歴史も調査する必要がある
【WEBを支える技術】URI設計編～良いURI設計とは～ - WEB道楽
【WEBを支える技術】HTTP基礎編～シンプルさが標準化～ - WEB道楽
【日経コンピュータ】アフラックのDX～後編～
アフラックのDX革命～前編～
日経コンピュータの特集に「アフラックのDX革命」が取り上げられましたので、前編を紹介します。
ロボット活用における分身出社
2019年秋 分身ロボット「OriHime」を導入
- ダイバーシティ推進部が企画
- 研修場所から離れた地域に住む社員のキャリアアップ支援
「OriHime」とは
活用方法
- 細かい動作が可能（手を挙げる、うなずくなど）
- ビデオ通話よいも親近感のあるコミュニケーション
（高代公美 東京総合支社支社次長） - 集合研修などメイン会場があり、一部が遠隔地の場合に有効
- 半数以上がリモートの場合は向かない
テレプレゼンスロボット「temi」で日常業務でも導入
「temi」とは
- ハウステンボスグループのロボット事業会社「hapirobo st」が販売
- ディスプレイ、マイク、カメラ、センサーを搭載
- 自律走行、ビデオ通話が可能
活用方法
- 介護、育児と仕事を両立支援
- けがで出社が難しい社員を支援
- オフィスの雰囲気やメンバーの表情を確かめられる
導入計画
- 2020年6月 パイロット運用開始
- 東京在住の管理職が地方都市の拠点で勤務を開始
- 本格展開
- 社内での活用に展開
- 保険代理店などに展開を検討
成果をもたらすアジャイル開発体制
経営環境の変化を察知
従来のプロジェクト
- 数か月単位の計画
- 数年単位での実現
- ウォーターフォール型
経営環境の変化
- 異業種のスタートアップ企業が金融サービスに参入
- 速いスピード感で新しいデジタルサービスを提供
- 従来のプロジェクト推進では対抗できない
アジャイル開発への切り替え
- 各業務部門とIT部門が協力してプロジェクト推進する仕組みを構築
- 2019年1月 アジャイル推進室を立ち上げ
- 2019年11月 Aflac Agile Baseを新設
- 透明性、柔軟性を保ち、スピード感ある運営を実現
アジャイル開発体制
3つの組織体制
- スクワッド
- プロジェクト開発チーム
- チーム構成
- プロダクトオーナー
- スクラムマスター
- 業務部門のメンバー
- IT部門のメンバー
チャプター
- 各部署が担当
- スクワッドに派遣する業務部門メンバー、IT部門メンバーを選抜
トライブ
- スクワッドを管理
- スクワッド間の取り組みの方向性の調整
意思決定の権限委譲
- スクワッドのプロダクトオーナーに権限を委譲
- 取組みテーマ、予算、意思決定の権限の大半を委譲
- 迅速な意思決定を実現
- 意思決定の重さによって待遇を見直し
【日経コンピュータ】アフラックのDX～前編～
アフラックのDX革命～前編～
日経コンピュータの特集に「アフラックのDX革命」が取り上げられましたので、前編を紹介します。
アフラックで起きた51のDXプロジェクト
- 二見通 CIOが指揮
3つの領域でのDX
顧客・保険代理店
- 例）ビジュアルIVR
- 電話とスマホ画面が連動し、顧客体験を一新
社内業務
- 例）あひるーぺ
- 社内の情報検索システムにAIを搭載
- 検索時間を6割削減
マーケティング・営業
- 例）営業サポートAI
- 顧客との会話内容をAIがアドバイスなどでサポート
AIスピーカーの開発
企画：音声認識への着目
目的
- 業務効率化やシステムの利便性向上のため
適用可能性
- 一般的な会話で利用できる
- 社内固有の業務用語を予めシステムに登録すれば、認識できる
適用先の課題整理（社内ヘルプデスク）
- 受付時間
- 朝から夕方までの担当社員による受付
- 様々な勤務体系を持つアフラック
- 早朝出社する社員が利用できない時間帯が存在
- 混雑
- 日中は混雑で電話がつながらない
期待する効果
- 受付時間
- AIが応答を行うことで24時間対応が可能
- 混雑
- AIが応答を行うことで混雑が解消
- ヘルプデスク担当社員の負荷軽減
開発
アジャイル開発で3か月での稼働を実現
業務直結の効率化
- 業務利用を念頭にプロトタイプ開発
- 活用度を高める機能拡張を実現
- 回答の聞きそびれ、聞き取りづらいなどの課題を発見
- 応答をスピーカーだけでなく、画面表示やメール送信などの機能追加で解消
3つのポイント
- UI、UXの実現
- AIスピーカーでは応答内容を画面表示するUIを採用
- 適用技術の丁寧に説明
- ヘルプデスク担当社員に音声認識技術を説明
- 人を助けるデジタル技術を導入
- ヘルプデスクをデジタル技術への置き換えではなく、業務負担の軽減と位置付け
【WEBを支える技術】HTTPステータス編～名は体を表す～
HTTPステータスとは
- サーバーからクライアントにリクエストの結果を返すコード
- HTTPステータスによってそのあとのクライアントの挙動が変わる
- 仕様通りにステータスを返すことが重要
ステータスコードの種類
- 1桁目でどの種類のステータスであるかを判別できる
- 1xx：処理中
- 2xx：成功
- 3xx：リダイレクト
- 4xx：クライアントエラー
- 5xx：サーバーエラー
ステータスコードの意味
エラー処理
プロトコルにあたフォーマットでエラーを返す
Acceptヘッダに応じたフォーマットでエラーを返す
- クライアントからリクエストで指定
ステータスと結果の整合性
- ステータスは200（成功）で、レスポンスボディには「File Not Found」となっているなど
- 人間が理解できても、検索エンジンや機械が解釈を間違う。
【WEBを支える技術】URI設計編～良いURI設計とは～ - WEB道楽
【WEBを支える技術】HTTP基礎編～シンプルさが標準化～ - WEB道楽
【日経コンピュータ】電子契約サービスだけじゃない！～請求・支払いのデジタル化と成功のポイント～
電子契約サービスだけじゃない！～請求・支払いのデジタル化と成功のポイント～
日経コンピュータの特集が挑むに「電子契約サービスだけじゃない！～請求・支払いのデジタル化と成功のポイント～」が取り上げられましたので、紹介します。
ハンコだけじゃないテレワークの阻害要因
- デジタル化が進まない請求書、納品書、検収書への押印、郵送業務
- 契約時のハンコをなくすだけではテレワークの実現は難しい
- 見積依頼、回答、請求、支払いなど契約前後もデジタル化が必要
大成建設の事例
- 「SUPER TRIO」を導入
- 下請けやグループ企業との取引で利用
2019年の実績
- 全3万3000件のうち、93%で利用
- 57%で契約書までをデジタル化
コロナ禍での課題
- 取引先の経理部門、法務部門の出社をどう減らすか
- 大口の取引先だけでなく、小口の取引先企業へも展開
サントリーHDの事例
2020年7月に契約関連の新業務システムを稼働
- 取引先（卸売業者、小売店、飲食店）との契約から請求、支払いまでをデジタル化し、システムで完結
- 2022年までに国内のグループ企業へ展開
期待する効果
- 年間300万枚のかみをさくげん
- 収入印紙代、印刷代郵送料など年間3000万円のコスト削減
- 業務効率化によるグループ全体で6万時間の時短効果
- 2～3年でシステム投資分を回収できる
契約関連のデジタル化の成功ポイント
工程間でのデータ引き継ぎ
- 見積依頼、回答、契約、請求、支払いなどの工程間でデータ連携
- 人の手を介さずに書類作成の自動化比率を高める
- 例）見積依頼時に使用した発注仕様を契約書に反映させるなど
書類のフォーマットを標準化
- 標準化によって、全社的に書類作成の自動化が進む
社内手続きをデジタル化する
- 書類の自動チェック、承認などもデジタル化
- システムにワークフローの機能を持たせるなどが必要
2023年10月に導入される「適格請求書（インボイス）制度」
- 消費税額の計算に必要な明細を請求書に記録、保存する制度
- すべての企業でデジタル化すべき事務手続き
仕入税控除額の申告に必要となる
- 現行では帳簿上のデータから申告できる
- 2023年から適格請求書を交付し、消費税の積み上げが必要
- 紙のインボイスでは手作業で計算が必要
各業界で使用するEDIシステムのデータ連携が必要に
- ITコーディネーター協会が動き出す
【WEBを支える技術】HTTPメソッド編～名は体を表す～
- HTTPメソッドとは
- 8つのメソッドと意味
- HTTPメソッドとCRUDの関連
- GET メソッド
- POST メソッド
- PUT メソッド
- DELETE メソッド
- HEAD メソッド
- OPTIONS メソッド
- GETとPOSTだけで実装する場合
- べき等性と安全性
- HTTPメソッド、URIとサーバー側処理の整合性をとる
HTTPメソッドとは
- クライアントからサーバーへリソースに対してどのような処理を行うかを伝達する
8つのメソッドと意味
- GET
- 子リソースの取得
- POST 子リソースの作成
- リソースへのデータ追加
- どのほかの処理
- PUT
- リソースの更新
- リソースの作成
- DELETE
- リソースの作事
- HEAD
- リソースのヘッダ取得
- OPTIONS
- リソースがサポートするメソッドの取得
- TRACE
- 自分宛てにリクエスメッセージを返すテスト
- CONNECT
- プロキシ動作のトンネル接続への変更
HTTPメソッドとCRUDの関連
| CRUD | 意味 | HTTPメソッド |
|---|---|---|
| Create | 作成 | POST / PUT |
| Read | 読込 | GET |
| Update | 更新 | PUT |
| Delete | 削除 | DELETE |
GET メソッド
- リソースの取得
- 例）WEBページの取得、画像の取得、映像の取得など
POST メソッド
PUT メソッド
- リソースの更新
- リソースの作成
- POSTとPUTの使い分け
DELETE メソッド
- リソースの削除
HEAD メソッド
- リソースのヘッダを取得
- Content-Type、文字コードタイプなど
OPTIONS メソッド
- リソースのサポートするHTTPメソッドを取得
- Webアプリケーションに実装
- Apacheに挙動を設定
GETとPOSTだけで実装する場合
- HTMLのフォームはGETとPOSTだけ使用可能
- HTMLの制限でGETとPOSTだけを利用する時代が長かった
- AjaxのXMLHttpRequestモジュールで解消
- 携帯電話（ガラケー）ではサポートしていないので、GETとPOSTのみ
_methodパラメータで解決する方法
- inputタグにパラメータとして含め、サーバー側で受け取る
- 例）'< input type="hidden" id="_method" value=PUT">'
X-HTTP-Method-Overrideで解決する方法
- リクエストボディにパラメータとして含め、サーバー側で受け取る
- 例）X-HTTP-Method-Override:PUT
べき等性と安全性
- べき等性
- ある操作を何度実行しても結果が同じであること
- 安全性
- 操作対象のリソースの状態を変化させないこと
- GET
- べき等、安全
- POST
- べき等でない、安全でない
- PUT
- べき等、安全でない
- DELETE
- べき等、安全でない
HTTPメソッド、URIとサーバー側処理の整合性をとる
- GETでリソース作成、リソースの削除を行ってはならない
- 例）GETメソッド http://example/test/delete
- PUTで相対的な更新を行わない
- 例）PUTメソッド http://example/test
requestBody +50
- 例）PUTメソッド http://example/test
【WEBを支える技術】URI設計編～良いURI設計とは～ - WEB道楽
【WEBを支える技術】HTTP基礎編～シンプルさが標準化～ - WEB道楽
