今年もお世話になりました!

今年は、会社の事業を拡大しようと試みた年でした。

去年からとてもしつこく勧誘電話を受けていたアイドマホールディングスという会社があります。とても胡散臭い会社だと思っていましたが、いざ今年の売上が落ちることが分かると、騙されたと思ってやってみようと契約したのが6月中旬でした。

そこからは、DXという新規事業を立ち上げるために、仮想的な組織を作るというアイドマホールディングスの言うがままに、営業を配置して新規顧客開拓を行いました。

私は営業という行為に苦手意識があり、また新たな商品開発をしなければDXだけでは顧客は付かないとひと月経ったあたりから気づきだし、電子帳簿保存法対応のアプリケーション開発に乗り出しました。

新規アプリの中核機能として、AIを使った文字認識に取り組みました。しかし知識ゼロからの開発は時間が掛かるのと、営業による新規顧客開拓も結果が出ないまま8月下旬になり、アイドマホールディングスとの契約を打ち切りました。

アイドマホールディングスの契約は2年契約が基本となっており、それを破棄したために違約金を払わなければならず、当時は騙された感がとても強かった。そのときはこの顔が江戸時代の武士みたいに見えて、農民のわずかな備蓄を、根拠も無い儲け話で奪っていくビジネスモデルで株式上場までしているのだから、如何に騙されている人が多いことか。やっていることは、ねずみ講と何ら変わらない。

独立したときから売上が少しずつ増えていた中で、今年は減収になることが見えていることの不安から自分を見失い、無謀な挑戦をしてしまったと反省しました。

AI技術は、機械学習させるときは、人間が学習させる方向を決めますが、機械学習の過程はコンピュータ任せのため、ブラックボックス感が強くて自分で作った実感があまり湧きません。

それに比べてBOT開発は、サーバサイトの仕様はブラックボックスですが、ブラウザで動作するように設計されたものなので、ブラウザの動きを解析すれば、ある程度自分で作ることができる点が面白い。

そんなこんなで、DX関連のアプリ開発が滞ってしまっています。

ただ、電子帳簿保存法は2024年1月から施行されることは確実であり、自分自身が使うためにもアプリ開発は継続していく予定です。

Emperorの新規開発として、新たな画像認証が導入されたハピネットをターゲットにしています。以前から次の開発候補としてハピネットが上がっていたのですが、やろうとするとほかの仕事が割り込んできたり、風邪を引いてそれどころでは無かったりという状況が続いて早1年が経ってしまいました。

リモートワークをしているので、通勤やオフィスで風邪菌をもらうことはありませんが、4歳の息子が幼稚園から強力な風邪菌を家へ持ち帰り、毎回家族全員にうつします。もーやだ。。。

わくわくするような画像認証なんですが、12月から新たな組織で働きだして、そこでの技術もなかなか難易度が高く、そちらの方が優先になってしまいました。

当社のアプリはQtというフレームワークを使っています。20代後半にこのフレームワークに出会って以降、個人的に使い続けています。Qtはとても使いやすく、マルチOSなアプリケーションを作れるという点に惹かれました。

Qtは欧州では認知度が高く、車載器などにも搭載されているのですが、日本ではほとんど使われておらず、自分が仕事で触れたのは数える程しかありません。日本では、C#やPythonなど、非コンパイラ言語の方が圧倒的に多く使われています。

12月からの仕事でC#からC++に移植するということを行い、初めて仕事でC#に触れましたが、非コンパイラ言語ならではの、柔軟なソースコードの書き方を見てしまうと、C++は神だと思っていたのが揺らいでしまうぐらい良くできた言語だと思ってしまいました。

私が使うC++は、2003年に出たC++03ぐらいまでの仕様しか使っていなかったし、それで必要十分だと思っていましたが、C++11以降(C++11,C++14,C++17,C++20)の仕様に触れて、C++の進化を改めて実感しました。

C++の進化について、簡単な例を上げます。

int a = 1 ;  ・・・①
int *b = &a; ・・・②
int &c = a;  ・・・③
int &&d = 1; ・・・④

①は、左辺の1を右辺のaへ代入する処理です。
②は、左辺のaのアドレスをbポインタに設定しているという意味で、aを参照していることから、左辺値のアドレスを指していることになります。
③は、a自体が左辺値であり、cがaを参照しているので、左辺値参照という解釈となります。
④は・・・これがC++11以降の仕様で、&&は右辺値参照という意味で、dは1を格納しているメモリの中身を参照しています。

左辺値のアドレスを参照とか、そんなこと考えなくてよくね??と思いたいですが、C++はアセンブリ言語の次に速い言語としての進化をし続けているわけで、私のC++の知識は20年ぶりにアップデートされました。

ということで、ここまで言い訳をダラダラ書きましたが、要は来年もよろしくお願いします、ということを言いたい!!

チケットぴあが何やらごにょごにょやっているなぁというのは気づいています。これはフレームワークのブラウザによる影響が高そうなので、ブラウザを変えることを検討しています。

来年も、常に最速を目指していきます!


モジュールアップデートを簡素化します

先々週対応した新暗号化ライブラリ版をインストーラにも適用したため、オンライン版のインストーラが例のVPS上においても動作するようになりました。

今後は、オンライン版インストーラのみに統一していくことにします。

当社のモジュールアップデートは、2種類の方法があります。

1つは、デスクトップのショートカットを起動すると表示するソフトウェアの更新ダイアログによるモジュールアップデートがあります。これは、同じバージョンのフレームワークを使用している場合に有効で、BOTの処理を更新するときなどに使用します。

もう1つは、インストーラからアップデートする方法で、これは未インストールのPCに対してインストールする場合や、フレームワークの更新がある場合は、こちらで行う必要があるため、fastBOTサイトでアップデートを通知していますが、なかなかアップデートが進んでいない場合は、前者の更新で強制的にインストーラの再インストールを促すことを行っています。

今後は、ソフトウェアの更新ダイアログがBOTのアップデート前に、オンラインインストーラの更新チェックを行い、更新があったときは以下の画面を表示するようにします。

上記画面でコンポーネントの更新を行うことで、インターネットから最新のモジュールに入れ替える作業をインストーラが行ってくれます。

今回はチケットぴあ自動購入のみ行っていますが、順次他のBOTも切り替えていきます。

livepocketの更新

クレカ支払いは、3Dセキュア認証が必須になっていました。

そのため、自動入力に対応しました。3Dセキュアが固定のパスワードのときのみ使用ください。


リクエスト種別の「開始時連発+継続」ですが、複数のリクエストを行うことで33%のところからの進みが遅くなっている現象が見られたので、機能自体を廃止しました。

どのくらい経過しないとディレイさせられてしまう仕様なのかは分かりませんが、本日最初に動作させたときは33%でディレイになることはありませんでした。(動画では33%で少しディレイがあります)

暗号化ライブラリを移植しました。

当社が使用しているフレームワークに、新しい暗号化ライブラリの移植が成功しました。

移植に成功しても、KAGOYA CLOUD VPSで動かないと意味がないので早速動作確認をしました。

リモートデスクトップのIPアドレスがKAGOYA CLOUD VPSのものであることを以下の2つの画像で証明しています。現在リリースしているインストーラでは、ライセンス認証が出来なかったのですが、新しいフレームワークでは、ライセンス登録ができるようになりました。

AWSでも動かないようなので、来週中には全てのアプリケーション分を用意したいと思います。

今回移植した暗号化ライブラリは、既存の暗号化ライブラリよりも軽量という謳い文句がありますが、軽量≒高速(軽量だから高速である)というわけでもなく、以前のものも残す方が良いのか悩みますが、利用する側としては、利用できることの方が重要だと思うので、一気に変えていきます。

無題

あれやこれややっていたので追記が遅れたのだが、実は2日後には以下の回答が来ていた。

この言い分は、Windows OSについてはカスタマイズは一切していないよ!ということだ。

Windows OSのNDIS中間ドライバやもっと下位のドライバでブロックすることもできそうだが、上記のことがあるため、ルータでブロックしていることはほぼ間違いないだろう。

このようなケースが他にも考えられるため、自分的には意地でもOpenSSL以外の暗号化スイートを使用したいと考えていて、今はそこに全力投球している。

今は良さげな暗号化スイートをフレームワークに移植することを行っているのだが、その暗号化スイートはOpenSSL ver 1系に合わせたI/Fを用意している一方で、フレームワークはOpenSSL ver 3系のI/Fになっているため、こちらで合わせ込みをしなければならず、予想外に時間が掛かりそうな状況になっている。

ぴあの座席指定機能を追加して欲しいとか、TicketBookに対応して欲しいとか要望を頂いているのは認識しているが、直ぐの実現は難しい。

TicketBookは、去年の年末にサイト側が刷新されたので、アップデートしようとしていたのだが、ブラウザではなく通信データでリストック監視を行った途端にBOTだと判断されてカートにチケットが入らなくなる。これについて色々悩んでいたら風邪を引いてしまい、モチベーションが落ちてしまってほったらかし状態になっていた。

当社BOTは必ずブラウザと共存した作りにしているので、ブラウザの自動操作も駆使することで対応は可能だったとは思うのだが、モチベーションが下がってしまっては元も後もない。

脈絡とは全然関係無いのだが、問い合わせをもらうときに、「いつもお世話になっております」という文言が最初に入ることが多くなった。

実はこれ、俺からするとかなり違和感がある。

サブスクの商品であればまだ理解はできるが、売り切りの商品についてこれを言われても、契約書を交わしている訳でも無いわけで、こちらからすれば赤の他人から言われても違和感しかない。カスタマーサポートが存在する企業であれば、そこが一次受付するから、開発部署には問題の内容ぐらいしか届いてこないのが普通なのだが、当社は俺しかいないので仕方ないのかもしれないが、変えていきたい。

問題提起をしてくれるのはありがたい反面、只々動かないとしか書かれていると、これで何を判断しろって言うんだ?!と思う。ログや画面キャプチャーなどの証拠を提示してくれれば、こちらのことも考えてくれていると思える。

Google DriveやOne Driveにログや画面キャプチャーをアップロードさせておいて、そのリンクを問い合わせフォームに貼り付けてくれれば助かります。Driveにアップロードしたログは共有状態にしておくことを忘れずに。

KAGOYA CLOUD VPS

BOTを使う場合、自分の家の環境でIPBANになったら不便になるので、ProxyIPを使うか、VPSを使う選択をする場合も多いと思う。

最近、ユーザからインストーラが動かないという連絡があった。以前もこの問い合わせがあったときは、ITリテラシーが無いのだろうと決めつけてしまい、BOT利用自体をお断りすることがあったが、今回は詳細な事象を話してもらえたため、原因追及のために私自身が調査を行った。

当社のインストーラは2種類存在しており、インストーラ内に全てのモジュールを詰め込んであるものと、インストーラを起動すると、インターネットからモジュールをダウンロードするものがある。今回の事象は後者の方で、モジュールがダウンロードできないので、インストーラを動かすことができなかった。

最初は、ファイヤーウォールや受信の規則を弄れば良いのではと考えていたのだが、そこらを弄っても全然改善されない。

まず何が原因なのかを調べるため、VPSにWiresharkを入れて、通信の状況を監視したところ、そもそもデータがサーバに届いていないことが分かった。具体的には、サーバには送っているが、KAGOYAのLAN内で戻されていた。恐らくルータにブロックフィルターを仕掛けているのだろうと思い、問題の切り分けをするために、HTTP POSTデータ送信を行うだけのアプリを作り、暗号化ライブラリを変えて通信できるか確かめた。

当社が使っている暗号化ライブラリはOpenSSLを採用しており、インストーラもOpenSSLを使用している。これはOpenSourceであり且つアップデートが頻繁に行われているため、信頼性の高いものである。こちらを使った場合は、サーバとの通信が行えなかった。

もう一つはEdgeの暗号化ライブラリを使ったHTTP POSTデータ送信を使用したところ、問題無くサーバとの通信ができた。

暗号化ライブラリが関係しているのは、下記の第5層に位置している。恐らくKAGOYA VPSでは、LAN内のルータにて第5層のペイロードを見て、OpenSSLだと分かる何かで判断して、ブロックしているのだと思う。

BOTが扱っているのは第7層だが、ここは暗号化ライブラリによりデータが暗号化されているのでチェックすることが出来ない。そこでBOTが使用している暗号化ライブラリに着目して、BOT利用者を弾き出そうとしたという訳だ。

いつから使えなくなっているのかは分からない。少なくとも1回目の使えない報告があったのが2023/3/25なので、それより前から使えなくなっていたということだろう。

この対処の仕方が、一般的に考えてあり得ない対応だと思ったので、当方からKAGOYAに以下のように問い合わせてみた。

土日祝を除いた3営業日と考えると、18時は営業時間外なので11/14(火)までに連絡があるのか待ってみようと思う。

今回発覚した暗号化ライブラリ特有のペイロードでブロックしているということが分かり、こういう技術は、BOT対策として他でも行っているに違いない。

ブラウザと同じデータを送っているのに、処理でHTTP通信を行うとサーバ側で弾かれる理由の1つにこの件が該当するのだと思うと、もっと早く調べておけば良かったと少し後悔した。

当社BOTは全てOpenSSLを使用しているため、他の暗号化ライブラリに変更しようと実際に動き始めている。

サーバ運営側はBOT利用者を追い払いたいと思うだろうが、私はBOT利用者を推進する側なので、今回のことは正直むかついた。

自動電話発信機能連携の追加

前回の便利ツール(Androidアプリ)と連携する機能を、チケットぴあ自動購入に追加しました。

使用するには、最新のインストーラをインストールする必要があります。

ヘルプメニューの「MQTT Settings」を選択すると、以下の画面が表示されます。

MQTT Brokerに接続のための情報を設定後、Connectボタン押下で、接続されます。

次に、Topicを指定します。指定後、TabキーでSubscribeボタンが有効になります。

Topicは、便利ツール(Androidアプリ)と同じにする必要があります。

試しに、Publish欄に、「tel:xxxxxxxxxxxx」(x=電話番号)を設定してPublishボタンを押下すると、便利ツールが起動状態であれば、その電話番号に発信することが確認できます。

以下は、チケットぴあ自動購入ツール自身も「tt」TopicをSubscribeしているため、送信したデータを受信しているのが分かります。

チケットぴあ自動購入の右側には、MQTTの状態が表示されており、以下の表示になっていれば、繋がった状態になります。この状態であれば、電話認証が表示されたときに、スマホと連携する動きになります。

Global interpark 自動購入が完成しました。

座席指定のチケットを扱うのが初めてだったからか、対応する画面の量がいつもの倍以上あったため、予定外の時間を費やしてしまいました。

画面遷移の仕組みも、自分は今まで出会ったことが無い作りになっていて、最初はすんなり行けそうと思っていたのですが、なぜか最後の購入完了のところでサーバに弾かれてしまい、その理由が全く分からず、仕方なく通信とブラウザ遷移のハイブリット型と言ったらよいのか、とにかく今までの形とは異なるものが出来上がりました。

動作速度については、最速にはしておらず、失敗しない速度にしています。

最後の画面遷移は入力はしていません。裏でデータは全て取得済みのため、そのデータを足しているだけです。

便利ツールv2.0.0をリリースしました。

この便利ツール(Androidアプリ)は、v1.0.0ではYahoo!ショッピングのSMS認証で、スマホに受信された認証コードをBOTに連携するツールとして、Emperor AIOで使用するためにリリースしたものです。

名前は適当です。当初はGoogle Playに登録しようかと思い、分かりやすい名称ということで選んだものですが、当方の時間的余裕が全く無いので、Google Playからのインストールではない方法でインストールするやり方を採用しています。

野良アプリをインストールするやり方をググれば色々出てきます。

APK(Androidアプリ)は、https://zatturight.com/fastbot/products/detail/38 の下の方にダウンロードリンクがあります。

LAN環境以外でも利用できるようにするため、MQTTというプロトコルを使用することにしました。以下が便利ツールアプリ画面です。

便利ツールはMQTTのクライアント側で、サーバ(Broker)はPublic Freeなところを使用することを想定しています。
個人で使用する分には、有料になることがまず無い程のリソースが用意されている以下のサーバを使用することを前提に進めていきます。
https://www.emqx.com/ja/pricing

MQTTは、世界規格統一された通信プロトコルで、LINEやDiscordなどのチャットシステムで利用されています。

MQTTを簡単に説明すると、Publish アンド Subscribe モデルで動作するマシン間接続プロトコルです。

MQTT クライアントは、MQTT を使用して MQTT サーバーへのネットワーク接続を作成するプログラムまたはデバイスであり、 ブローカー とも呼ばれます

通信が確立されると、クライアントはブローカーにメッセージを送信できるようになります。

他のクライアントは、クライアントから送信された特定のトピックに関する通知を購読できます。

Brokerとして今回利用させて頂くのが www.emqx.com 、SubscribeするだけのClientが便利ツールアプリ、PublishするだけのClientがチケットぴあ自動購入ツールとなります。

何をしたいのかというと、チケットぴあのログイン後にたまに電話認証になりますが、これを自動化したいというのが目的です。

Cloakでリストック監視を行っていると、1日に2~3回は遭遇します。手間でも認証を通しておけば、発生頻度は減ります(と思う)が、電話を掛けること自体が手間です。例え自動化させても、電話認証が出た段階で速度的に不利になることは間違いないので、電話認証が出たときは厳しいかもしれませんが、自動化によってストレスフリーになることをモチベーションとしています。

スマホ側のセットアップが完了したら、次はBroker側の準備です。

https://cloud-intl.emqx.com/console/deployments/new
上記リンクから、無料開始ボタンを押して、アカウントを作ります。

個人情報を入力する欄がありますが、クレカは登録しなくても使用できます。

無料枠は個人利用としては使いきれない程の上限幅なのでクレカを登録する必要は無いでしょう。

アカウントを作成したら、ログインします。
https://cloud-intl.emqx.com/console/

Console画面に行くと、接続先が表示されているので、便利ツールの接続先に指定します。

左側の認証メニューから、ユーザを作成して、便利ツールのユーザとパスワードを指定します。

便利ツールアプリ側でConnectボタンを押して、接続されたら、動作確認をしてみましょう。

サーバ側Consoleメニューのオンラインデバッグを開きます。Connection Nameは適当で構いません。

Topicは、便利ツールのTopicと合わせる必要があります。tel:の後に電話番号を入れてPublishボタンを押してみてください。スマホが自動的に電話発信されたら成功です。

チケットぴあ自動購入ツールの対応後に続きを書きます。