Case1「IaaS上のSoEから、SoRで管理されているデータを参照する」時の連携方式
堀越悠久史氏（以下、堀越）：3つぐらい（ケーススタディを）持ってきているので、鶴田さんと一緒に考えていきたいと思います。
（スライドを示して）このような問題設定というか、こんな話ですね。IaaS、まぁAWSだと思ってください。そこに構築されたSoEです。Webや先ほどやったようなオンラインショップ、もしくはチャットボットみたいなやつかもしれません。
そこから、チャットボットだと思えば、取引のデータを確認したいです。「私のいついつの履歴って何ですか」みたいなことを確認したいパターンです。ほかのシステムと連携の実績のあるAPIが、オンプレミス（内）で提供されている流れですね。さて、考えられる方式にはどんなものがありますかという話です。
鶴田拓己氏（以下、鶴田）：そうですね。ほかのSoR側に他システムと連携実績があるAPIがもう具備されていて、かつVPNや専用線の接続も可能というところでいくと、SoE側からVPNなり専用線なりを通じてAPIを叩きにいって、契約データ、取引履歴データをSoRから返してもらうみたいなもののは、パッと思いつく方式になるかなと思います。
堀越：ありがとうございます。私もそれ（が思いつくもの）ですね。（スライドを示して）検討の過程はこんな感じですが、出来あがった絵はこんな感じのアーキテクチャですね。
特にIaaS、AWSをちょっと念頭に置いてあげると、パブリックサブネットとプライベートサブネットみたいな分け方があるので、そのプライベート側で専用線なり、Site-to-Site VPNを引いてアクセスしてあげます。非常にオーソドックスなものですね。「クラウドデザインパターン」みたいなものを読んでもらえれば必ず載っているパターンかなとに思っています。
あとはこれをどういうふうに議論していくかもけっこう大事なので、ちょっと戻ります。“プランA”の絵です。「SoE側のIaaSの機能でプライベート通信しましょう」みたいなところですね。比較的バランスが取れているプランになるかなと思います。
一方で、実は履歴のデータ、バッチをこちらに送り込んであげるのもけっこう良い手かなと思います。この場合はプライベート通信なしでもできるので、これもありなのかなと。
という時に、では何が問題になるかという話です。「ここなんですけどね」という（議論をするような）ところですね（笑）。「前日データなので」「最新状態じゃないので」というところだと思います。逆に言うと、鶴田さん。「これは、こういう状態だったら実はこれでもいい」という判断はできますかね？
鶴田：先ほどのデータの最新性ですよね。先ほどの、僕が陥ったWebでの通販の部分でいくと、通販であれば、1秒前、2秒前のデータ、連携したタイミングでの最新のデータが欲しいところではあるかなと思っています。
一方で、履歴データや、例えばお客さんのデータはそんなに変わらないから、最新性はそこまで必須ではないかなと考えました。
堀越：ありがとうございます。私もだいたいそんなイメージですね。契約データはやはりそんなに変わらないので、そこは別に（SoE側に）送り込んじゃってもいいかなという気がしています。
なので、やはりデータのあり方とか、そこに対するアクセスのされ方を一緒に考えてあげるのがいいのかなという気がしています。よかったです。だいたい私と同じような意見が出てきて。
鶴田：よかったです（笑）。
Case2「パブリッククラウドのSoEで、SoRのデータを迅速に参照する」時の連携方式
堀越：さて、2個目にいってみますか。今度は、冒頭であったSalesforceみたいなやつですね。あれをちょっと念頭に置いてみましょう。
営業さんやコールセンターの方が使うというところです。そしてパブリッククラウドです。純粋なパブリッククラウドなので、直接的に閉域網というか、プライベートの通信ができなさそうなものです。シチュエーションとしては同じで、SoRにある契約データ、取引・履歴データを参照したいというところですね。
「もう答えが出てるじゃん」みたいな話かもしれないですけど（笑）。APIゲートウェイがここにあるとします。スマホアプリみたいなのを持っているところだと、比較的APIゲートウェイを立てていたりするので。そんな中で、どんな方式が考えられるかというところですね。
鶴田：そうですね。すでにあるAPIゲートウェイやAPIを使って連携していくのが考えられる方式かなと思っています。あと、どんな制約があるかですが、やはり認証やセキュリティの部分はちょっと考えなければいけないかなと思いました。
堀越：ありがとうございます。私もそんなところですかね。プランAと書いてありますが、SoEからAPIゲートウェイを通して、SoRからデータを取ってきます。構造は、先ほどと似たようなところですが、「APIゲートウェイを扱う」というところですね。
（スライドを示して）絵としてはこんなものです。SoEがあって、APIゲートウェイを叩きにいきます。先ほどあったように、認証をうまく使うところがポイントになるのかなというところです。
「では他の案はなにがあるんだろう」というところも一緒に考えられるかというところですね。実は、夜間バッチというか日次バッチで、データをコピーしてあげるのも、やはり有力な手段として常に出てくるのかなというところです。
それから、SoE側からSoR側に画面遷移するという方法が実はあったりもします。冒頭で出したSalesforceだと、ボタンを押してあげて、SoRのブラウザで対応していればそこの画面を開くというのも、実はけっこう検討の余地があるところです。
ただ、これは今回のケーススタディに出たものでは×がついていました。どんなイメージ（で×がついた）かというと、SoR側の改修コストがけっこうかかるということです。
昔のシステムはけっこうセッション管理をしていて、URLがずっと同じで違うデータを表示しているものがあったりします。そうすると直接的にURLを指定してリンクできないみたいなことがあって。「そこを直すのは大変ですね」ということがけっこうあったりします。
（スライドを示して）あとはここ（データ量についての評価）かな。これは鶴田さん、どう思いますか？ けっこう判断が悩ましいところかもしれないですけれど。
鶴田：あぁ、「膨大なデータ量を」というところですかね。そうですね。データ量の部分はやはりキャパシティ、パブリッククラウドで、特にSalesforceだとストレージ容量が制約として発生してくるので、膨大なデータ量を取り込むのであれば、データストレージを空ける分のデータのアーカイブ（方法）というか、削除の方式もあわせて考えていかなければいけない部分かなと思います。
あとはストレージの計算が必要になってくるし、動き、パフォーマンスにも少なからず影響してくる部分ではあるかなと思っています。
堀越：ありがとうございます。そうですね。私も聞いていて「うん、確かに」（と思いました）。今はSalesforceを念頭に置いていますが、データが多くなると、そこそこ普通のデータベースみたいな動きをけっこうするので、少し大変なことがあるかもしれないというのは、やはり考えなきゃいけませんね。ありがとうございます。
Case3「パブリッククラウドのSoEから、厳重にアクセス管理されたSoRのデータを迅速に変更する」時の連携方式
堀越：では、最後のケーススタディにいってみようと思います。実はここは、鶴田さんと台本で読み合わせをしていないところなので、大変かもしれません。
鶴田：はい（笑）。
堀越：これは先ほどと同じです。純粋なパブリッククラウドですね。Salesforceを念頭に置いてください。
迅速にSoR側にある契約状態を変更したい場合、プライベート領域のセキュリティは厳重です。APIゲートウェイみたいなものは置きません。既設のものはないというところですね。
あと、SoRは銀行のものを想定してもらえればいいのですが、勘定系のものがあって、（スライドでは）“MQ”という”伝統ある”という表現をしていますが、昔ながらのメッセージ通信用のミドルウェアがくっついている時です。さて、この状態でどういうふうに連携できますかね。
鶴田：そうですね。金融機関さんとかに、よくある基幹系（のシステム）だと想定して進めていきます。やったことがあるパターンというか、使ったことがある方式だと、データ連携基盤を基幹系から踏み台サーバーにファイルを送り込んで、踏み台サーバーからデータ連携基盤にファイルを送って、そこからFTP通信やSFTP通信でデータ連携基盤とやり取りさせて、SoEとそのデータ連携基盤をコネクトさせます。
データ連携基盤側の機能を使ってやるという方法が、簡単にパッと思いついたのですが、データ連携基盤をかませて連携させる方法かなとパッと出てきました。
堀越：ありがとうございます。ちなみに、SoEの画面から契約状態を変更したい場合は、どうしますか？
鶴田：そうか。即時反映となると、APIがいいんだろうなとは思いますが、ここはAPIゲートウェイもなくて、かつセキュリティが厳重なところなので、SoR側との調整、SoR側の担当されているベンダーさんやステークホルダーの方との調整が制約というか、大変な部分かなと思ってきました。
堀越：ありがとうございます。データ連携基盤は、一応SoEとアクセスが可能なので、そこの穴をなんとか開けてもらってみたいな感じですかね。
鶴田：あぁ、そうですね。はい。
堀越：「既存のAPIゲートウェイとはなにがどう違うんだろう」みたいな話になるかもしれない（笑）。
鶴田：そうですね、確かに（笑）。
堀越：ありがとうございます。ここは実は私も大変悩んだところです。最終的にどんなアーキテクチャになったかだけ先にちょっと紹介すると、こんなアーキテクチャにしました。
これはちょっとわかりにくいのですが、なにを言っているかというと、SoE側は、最初に出したような画面です。あれは、ブラウザ上で作られていて、ユーザーインターフェースは、ブラウザでロードされていくので、あくまで通信上は社内LANに出てきます。
社内LAN上で動いているということは、そこにJavaScriptが動いていたら、社内LAN上から社内の別のサーバーへの通信が一応可能ということになります。ということで、実はUI側だけ中にいて、そこからサーバーを経由して、そこにこのプロトコル変換（サーバ）を噛ませました。
ここ（JavaScriptとプロトコル変換サーバーの間）はAPIですが、MQに飛ばすようにという（変換）のを噛ませて、この子（プロトコル変換サーバー）がプロキシになってくれて叩きにいくような感じですね。
なので、ここはもう完全にマッシュアップみたいな世界でやりました。けっこう訳わからない感じになりました。ちょっといろいろ書いてありますけど、やはり汎用的じゃなく、トリッキーです。これが正解というわけではぜんぜんないと思いますが、1個の乗り越えるための技ではあるのかなと思います。
ここはだいぶお客さんとも揉めながらも、「これだったらできるかね？」ということを話しながらやりました。
（スライドを示して）その時に作ったDA表っぽいのがこれです。
最初の案として、「やはりAPIゲートウェイを作りましょうよ」というところは中心にあったのかなと思っています。ただ、そうするとセキュリティ上の運用を作らなければいけないとかいろいろあって、「うーん」と言って、先ほどのような違う方式になりました。
あとは「画面でうまく連携されればいいんじゃないの？」という話ももちろんあったのですが、やはりそれはSoR側を直さなければいけない。全部が（SoEだけで）できるわけではありません。特に勘定系用のシステムはぜんぜん別になっているところもあって厳しかったです。そんな感じでした。
そうすると、冒頭でやった連携のパターンとして①、②、③、④がありましたが、UI側の連携についても話したし、クライアント連携という今回やったようなパターンもあるし、サーバー連携が一番オーソドックスだし、常に有力な手段になりそうなデータ連携もやりましたという感じだと思います。
（次回に続く）
