チケットぴあリセールの席指定キーワードの仕様変更について

リセールの座席指定を今まではカンマ区切りはAND判定にしていました。つまり、カンマで区切ったものは全て一致していないとOKにはならない仕様でした。

今仕様からカンマ区切りはOR判定にしました。以下のチェッカーは、BOTのシートチェック判定と同じアルゴリズムで判定しているので、事前にチェックが可能です。
https://zatturight.com/ticketpia/seatmatcher.html

楽天市場の中身がガラッと変わりました

楽天の自動購入ツールを作ったのは、BOT制作し始めの時期だった2017年にまで遡ります。

楽天市場のHTMLを見ると、サーバサイドがJavaで書かれていてサーバサイド主導のコードで、SPAフレームワーク(React、Angular、Vue.js)が使われていない、単純なDOM構造をしているサイトでした。これまでは細かな変更はあるものの、一度も大きな修正はありませんでした。

1~2年前ぐらいからログイン画面が変わって、いよいよ変わり始めるのかな?と思っていたのですが、それでもログインは従来と変わらずPostリクエストで通信できていたので、BOT開発側としては修正する必要が無くホッとしていたものでした。

楽天スーパーセールで破竹の勢いだった時代もあったのですが、とある仕様を楽天も気が付いたのか蓋を塞がれてしまい、それ以降はスピード重視をしたところで確実に取れるというものでは無くなってしまいました。

Emperor AIOの利用数も減ってきていたので、また楽天自動購入BOTとして単品販売を考えていた矢先のこと、Emperor購入希望者からの問い合わせで「楽天は動きますか?」と言われて、ただ単に利用者が減ったから使われていないだけだと思い「動きますよ!」と答えたのですが、いざ動かしてみるとカート画面から先に遷移できなくなっていました。

勿論、動くことを目的として購入して頂いているので対応する必要があるので、すぐさま調査したのですが、SPAフレームワーク(React、Angular、Vue.js)の構造に変わっており、HTTP通信だけで何とかなるものでは無くなっていました。

ログインも見た目は1~2年前と変わらないですが、中身は全然別物です。というよりもブラウザで動かす部分は既に変わっていたのかもしれませんが、もう今はPostリクエスト(ログインIDとパスワードをHTTP通信で送信)でログインできる代物では無くなっていました。

今の流行りはSPAフレームワークであるし、構造も複雑になっているので、BOT対策としても有効なので、これからも増えていくと思います。今後は、BOT開発もSPAフレームワークに寄り添ったものが主流になっていくのだと思います。

来週には楽天スーパーセールも始まるので、それまでには楽天市場の処理だけでも完成させますが、BOTを使ったスーパーセールでどこまで結果を出せるのか気になるところではあります。

2025/09/02追記
おととい新仕様に対応したBOTを動かしたユーザからの問い合わせで、動かないと言われて調べたところ、前の仕様に戻っていました。なのでBOTも前のバージョンに戻したら動きました(笑)

楽天、何してんだろ??

ローチケとぴあのアップデート

ローチケは、以下の画面の券種に完全対応ではないですが、対応しました。このページはスマホのみの販売である点と、

スマホの場合は、イベント参加券というのが購入途中しか見えないので、おおよその対応となっています。

必要のない券種については、0を指定してください。

ぴあのアップデートは、本体ではなくチケット大相撲の方です。

自動ログイン処理を改修しました。

ちゃんと動きますので、是非購入ください!

必死で作っています

以前もEmperor AIOと連携するツールを作っていましたが、新型を作成しています。

自動動作におけるOne Time Passwordの連携をこのAndroidアプリが担ってくれます。

iOS版も開発予定ですが、iOSの制約で全自動はできないようで、ワンタップは必要なようです。Androidアプリをリリース後に投入します。

近々、Relief Ticket自動購入を投入予定です。お楽しみに!!

2025/8/10追記
Google Play公開のための審査動画に使用した動画を公開します。
アプリは前面で起動している状態で、画面OFFになっている状態からSMSを受信したときにOTPを抽出したことを現しています。

2025/8/11更新
Googleの承認が下りました。今後は12人以上にクローズドテストを14日間以上行って頂くことで公開アプリの要件をを満たすことができます。

そこでテスターになって頂ける方を募集します。メールアドレスをこちらでテスター登録すると、下記リンクからアプリをインストールできます。起動したらhideさせておけば起動していることになりますのでそのまま14日以上経過させてください。hide状態のときは、アプリはsuspended状態で停止しています。Androidのみの対応となっています。

https://play.google.com/store/apps/details?id=org.qtproject.UsefulTools
※テスター登録を行わないとアクセスできません

2025/8/14追記
Chromiumのバージョンアップと共に、私が愛用していたQtとの共存が不可能になりました。やり方はあるのかもしれないが、私なりに色々試した結果の結論です。
Chromium v138からそれまでの設計思想から破壊的仕様変更が行われたことが原因ですが、詳細が良く分からず、そこに時間を掛けてまでしてQtを使い続けるか自問自答していましたが、遂に諦める決意をしました。
他の仕事ではC#を使っているのですが、進化が凄く過ぎて、一昔前に今のコードを見たとき、この書き方はどうやって処理されるコードなの?と疑問になるぐらい書き方が変わってしまっています。でもコードの書き方も便利になっていることは確かなので、今後はC# with Chromium Engineを使ってアプリ開発を行っていきます。
但し、当面は認証がきついサイトのみの使用となります。RELIEF TICKETは認証がきついために最新のブラウザを使う必要があるため最新のChromium Versionを使用するためにC#アプリを使います。

2025/8/17追記
C#版のベースとなるアプリが完成しました。
処理速度はC++版に比べれば多少は劣ると思いますが、人間の目では分からない程のものです。これを使うのはreCAPTCHA v2 or v3、その他CAPTCHAを使うサイトに対して有効なものであり、全てのBOTがC#に移行する訳ではありません。
https://github.com/zattu1/CefSharp

2025/8/27追記
Googleより審査結果に違反があるとの通知を受けました。
Android15でSMS受信時にアプリを起動できる権限なのですが、無効と判断されてしまいました。

これに連動しているようで、Googleが本アプリの権限をリモート操作で不可にされてしまったようで、SMS受信時にアプリが起動できなくなってしました。(開発時は起動していたのを確認できていたのですが。。。)
そのため、本アプリを利用するときは、開発者オプションでスリープモードにしないを設定して、電源をつけっぱなしの状態にするほかありません。

2025/9/11追記
上記の設定は不要になりました。スリープ中でもSMSは受信するので、そのときにUIは表示せずにJava層だけでTCP送信する仕組みに変えることで、スマホの画面が復帰しなくてもOTPを受け取ることができるようになりました。

このRELIEF-TICKETサイトは、購入の手続きは異様に多く、
1.日時選択画面
2.携帯電話番号認証画面
3.携帯電話番号入力画面
4.購入に関する注意事項画面
5.同行者情報の登録画面(2人チケットの場合のみ)
6.クレジットカードの指定画面
7.Confirm画面(まだ見たことが無い)
8.恐らくComplete画面
とやることがめちゃくちゃ多い。

SMSのOTP連携を経て、やっとここまで来ました。
試す機会が極端に少ないから開発の進捗が遅くなってしまう。。。

2025/09/16
テスト購入しました。
リセールのリセールはできないので、経費で落とすのみです。

チケットぴあ自動購入のアップデート

以前から問題だった、サーバからの応答が無いままタイムアウトを起こしている現象ですが、今回のアップデートで解決しました。
spのURLがあるチケットについても修正はしましたが、動作確認ができるチケットが分からないので、在庫があるチケットについて連絡頂ければ確認いたします。

サーバからの応答が無くなる問題の部分ですが、ちょっとしたことではあったんですが、それが原因でタイムアウトを起こすため、購入動作に一向に進まない状態になっていました。

今までは無償アップデート対応してきた改修工数かもしれませんが、今回はアップデート料金を頂きたいと思います。

2025/1/31以前に購入して頂いた方が対象になります。

アップデートチケットを当サイトから購入ください。
https://zatturight.com/fastbot/products/detail/88

ご購入頂けない場合、ライセンスの一時停止処置をさせて頂きます。

ご協力のほど、よろしくお願いいたします。

また今回のアップデートで、今まで試験的な導入だったPurchase Actionリトライのチェックボックスを削除しました。これを追加した理由は、そもそもサーバから応答が無くなることを考慮しての機能だったので、今回のアップデートによりサーバからの応答が来なくなることは無くなったため不要となりました。

【急募】スマホアプリを作ってもらいたい方【急募】

勤怠管理システムを作ってからというものの、興味がスマホアプリの開発の方に変化していきました。

ただし、スマホアプリでBOTを開発というのは自分が扱う言語(Qt QML)では不向きですが、MoCやシステムを構築したい場合にAndroidとiOS双方を同時に開発できる点が一番の特徴だと思います。

以下の方については、お役に立てると思いますので是非お声がけください!

・Webシステムを持っているがスマホと連携したい
・Map情報を使ったシステム連携がしたい
・Bluetooth端末との連携をスマホで行いたい
・NFCを使ったスマホ連携を行いたい
・etc…

先日のごたごたからようやく落ち着きを取り戻しつつある状態になり、気持ちにも少しずつ余裕が出てきたので今回の募集に踏み切りました。

新ブラウザ&BOTの開発も行いたいのですが、Chromiumのソースコードからの開発が膨大でパンクしそうなので手が付けられていません。こちらも時間が出来てきたので再開して行こうと思っています。

最近microDXのWebページからの問い合わせが多くなってきた理由は、多摩地区代表に選出されたのが大きいのですが、顧客からの問い合わせは全然来なくて、企業からの営業代行や効率化システムの宣伝ばかりでうんざりしています。

俺は顧客が欲しいのだ!!!

AIによって開発手法は劇的に変わった

NewsPicksの以下の記事、

2025/5/31

【新事実】AIは「仕事」ではなく「やる気」を奪う
https://newspicks.com/news/14290811/body/?ref=index

これはNewsPicks会員でないと見れない記事だが、要約するとプログラマーは自分でコードを書くことが好きなのであって、AIが書いたコードを読んで、修正があれば再度直させて、良ければデプロイしてという作業は「やる気」を失うというのだ。

確かに一理あると思う。自分も書くことが好きだし、アドレナリンがバンバン出ているときは気持ちよく書ける時間が好きである。

しかしそれは、慣れ親しんだプログラミング言語の場合であって、慣れないコードを書く場合は、ググって書き方を覚えてながらデバッグして、上手くいかなければ直してを繰り返すので、とても時間の掛かる作業となる。

今回新たな取り組みとして勤怠管理システムを作ったが、サーバサイドは初めての試みでLaravel+Vue.js+Inertia.jsという組み合わせで作成したが、コードの98%はAIのコードをそのまま使っている。勿論設計しているのは自分自身なので、設計思想に合わないコードを出してきたときは修正したものを再度出してもらっている。
これまでは、自分で作るしかなかった手段が、AIが代替してくれることになり、疲労や時間が大幅に削減できている。学習コスト自体を10分の1以下に抑えられていると思う。

AIは自分の中では何でも要望に応えてくれる相棒になっている。一番欲しかったものがそこにある。唯一、最終的にはAIが作ったものをチェックしなければならないので、自分のコーディング作業はゼロにはならないが、ググる時間と動くか試す時間が劇的に減っているのは確かだ。

但し、AIに頼るのは自分がこれまで携わってこなかったWebシステムやデザイン部分のみであって、CやC++などの制御部分を任せるときはとても慎重になる。小さなサブルーチン的なコードを書いてもらうことはあっても、全体的な設計思想をお願いすることは無いし、今後も行わないだろう。

AIに任せると、出来ないこともできると言い張る点は依然から変わっていない。出来ると言い張るのを信じて任せてみると、絶対にできないものなのに、何度もトライしようとするので、時間の無駄になる。最終的にはそのコードは捨てることになる。これを防ぐために設計は自分で作成する必要があるのだ。

使いにくい部分はまだまだあるが、それでも良い時代になったとは思う。今ならどんな仕事が来ても問題無く受け入れることができる。

今更だけどGANTZ読んだ…

1月中旬から作っていた勤怠管理システムの開発の終わりがようやく見えてきた。。。今回作ったアプリは、サーバ側はLaravel+Vue.js+Ant Designを使って、管理者用のページを作成した。今回のお客様きっての要望で、Webからお知らせ文章を送ると、スマホのバックグラウンド通知を受けて受信する機能を搭載したいということだったため、一から作成した。今のご時世Android機だけではだめなので、iPhoneも対応した。iPhoneのアプリは初めて作ったので、バックグラウンド通知とバイブレーションと画面の大きさを自動調整する仕組みに2週間ぐらい手探りし続けて死にそうだった。。。

スマホアプリの面白い機能だと自分では思っているのが、出勤・退勤打刻を行えるのは、会社のWi-Fiでないとできないようにしたというもの。GPSで打刻管理というのはあるようだが、GPSが届かないところもあるので、ユニークな機能だと思う。あとは、出勤・退勤打刻リマインダをバックグラウンド通知で搭載したというのも面白いと思う。

ちょっとした遊び心として、打刻時の音やバイブを色々選択できるようにした。初めてアプリを作った割にスマホのハードウェア機能の殆どのものを載せる必要があったので、作っているときはマジでつらかったけど自分の知識はかなりアップした。スマホのコードは、Qt QMLを使っているのでAndroidもiPhoneも画面回りはほぼ同じコードで済むのが良いところだ。

他にも大変だったのがスマホアプリの配布方法で、Androidは野良アプリで配布すれば簡単ではあるが、相手は企業なので野良アプリでは提供できないためにGoogle Playで配布するやり方を覚えた。iOSアプリは野良アプリが許されていないので、Test Flightというテストアプリを配布するアプリからのリリースを行うために証明書を作成して登録したりと色々なことを覚えて学んだ。今回のアプリは企業用のため一般公開用のアプリにはしないが、作るやり方は覚えたので、そのうちスマホアプリも作成して行けれたらと思う。

勤怠アプリの詳細は、仕事の合間を見てmicrodx.zatturight.comのブログに宣伝用として載せていくつもりだ。デモサイトとデモアプリを一般公開する予定なので、興味があれば触ってみてほしい。

辛いときこそ逃げ場を見つけたくなるもの。今回は漫画のGANTZにハマった。これまで名前ぐらいしか知らなかったのだが、HuluでたまたまGANTZのアニメを見たのがきっかけで、アニメを見終わったらその続きがどうしても見たくなってしまい、電子漫画を最終話まで大人買いしてしまった。

ネタバレ記事になるかもなので、見たい人がいれば先を読まない方が良いと思う。

最初は、話の先の展開が読み辛くて、すぐ違う描写に移るのがとても気持ち悪い作り方をしているなぁと思っていたのだが、なぜか話の先が気になってしまいアニメを最後まで見終わってしまった。アニメの最終話が滅茶苦茶腑に落ちない終わり方をしていたので、ネットで調べてみたら全然序盤だったこともあり、先を読まずにはいられなくなった。

最後を知っていればこその黒い球(GANTZ)なのだが、それにしても設定が強引な個所が無数にあった。最後を知ればある程度は腑に落ちるが、転送すると死んでさえいなければ負傷していた傷が治るという強引な設定やそもそも転送のきっかけが曖昧過ぎた。

最初の方でやたらと大きい乳の女性ばっかりが目立っていたが、後半は嘘のようなちいパイが大活躍するという点もなんかもやもやする。

最後の最後が、アクションヒーローものって感じのジャンルで片付けられてしまいそうで、ちょっともったいない落ちだったが、とにかく次の展開が気になる漫画だった。

この漫画の物凄いところが、とにかく繊細で丁寧で細かい描写に驚いた。滅茶苦茶時間掛けているのが良く分かる。ガラケー全盛期から始まってiPhoneが登場して数年経ったぐらいまでの期間に連載していた漫画だったが、漫画の描写自体がその時代に合わせて作られているので、20年以上前のその時代に起きている出来事や風景が丁寧に細かく描写されていて、その頃のことを思い出すことも多々あった。

この作者は高校生の時からGANTZの構想を温めていたらしく、とても大きいスケールの作品だったけど、生と死とは何なのか?宇宙の起源はいつ?地球はなぜ青い?という誰でも疑問に思って想像を膨らませることがある空想の世界を上手くまとめ上げた作品だったとして、今後も忘れることがないぐらいインパクトがあった。

4月に入ったら、リリース出来るよう最後の追い込みです。

Proxyサーバ構築方法について

チケットぴあ自動購入は、v3.8.0.0にてProxyローテーションに対応しました。

今後、Proxyサーバ構築についての問い合わせが増えることを予想して、構築手順について纏めていきます。当方がProxyサーバ構築の代行を行うことはありませんので、このブログの内容からご自身で学んで頂きたいと思います。

今のご時世、AIを使わない手は無いです。AIは専門的な事についても答えてくれるので、AIと一問一答して行きながら、Proxyサーバ構築までの流れを書いていきます。

サーバ環境は、VPS(Virtual Private Server)を使います。VPSと検索するだけでも国内・海外含めて相当な数があります。自分に見合ったサーバを見つけてきてください。OSはLinux系で十分です。CPU・メモリ・ドライブについても以下のスペックで十分です。

3については、2番目を以下で行いますが、それ以外は無視で構いません。4についても以下で述べていますので省きます。

必要なパッケージは、Ubuntuの場合はsquid→Proxyサーバ、apache2-utils→ProxyのBasic認証用モジュール、その他nano(エディタ)のみです。コマンドとしては、

以上のみです。簡単ですよね。sudoというコマンドは、Windowsで言うところのUACと同じもので、管理者権限を持ったユーザにてコマンドを実行するために必要なものです。上記コマンドを入力するとパスワード入力を求められますので、VPSを契約した際に自動で割り振られた、あるいは自分で設定したパスワードをここに打ちます。

ユーザ認証ファイルの作成とは、Proxyの「ユーザ名」と「パスワード」の部分を作成するための手続きです。これもAIに従ってコマンドを打ちます。

Squidの基本設定についても、nanoというエディタを使ってAIの指示通りにコマンドを一字一句間違えないように打ちます。ここで間違えると正しく動作しません。http_portについては、Proxyのxxx.xxx.xxx.xxx:yyyyy:user_id:passwordのyyyyyの部分になります。3128はProxyのよく使われるデフォルト値なので、敢えて変えた方がセキュリティが高くなります。

squidをインストールすると、/etc/squid/squid.confが既にあります。

以下の設定を追加(既存の設定は一旦コメントアウトすることをお勧めします):

↑重要です

Squidの設定を打ち終えたら、Ctrl+xでnanoのエディタを閉じてSquidの再起動を行います。

このコマンドの後にエラーが無ければ無事Proxyサーバが起動したことになります。

Proxyが導通しているかの確認は、「Proxy Checker」で検索して出てきたサイトにて、作成した、xxx.xxx.xxx.xxx:yyyyy:user_id:passwordの書式をコピペして確認してみてください。

ファイヤーウォールの設定は不要ですが、その代わりProxyを使い終えたらVPSサーバを停止することをお勧めします。間違えてもサーバの削除をしないようにしてください。使用するときだけサーバを起動させて、使用しなくなったら停止するだけでも立派なセキュリティ対策になります。

MacOSの配布用Qtアプリケーション作りが難解過ぎた

黒基調のウィンドウは格好良いです。

1週間以上掛けて、ようやく配布用アプリケーションが作成できました。
MacOS版チケットぴあ自動購入の処理は、1年前のソースコードをそのまま持ってきました。(プラスnewspプラグインの処理を入れています)
MacOS版の方がWindows版よりも購入できるという報告をちらほら聞くため、敢えてそのようにしています。Success PostでMac版を使った時にはそれが分かるようにしているので、そこで判断できます。

今のバージョンである、macOS Sequoiaは、AppleシリコンのM1以降でのみ対応されており、そのCPUでビルドしたアプリケーションを作成する必要がありました。

別件でMac Miniを購入したことと、ユーザからの要望があったので作成してみようと思った訳ですが、情報が殆どないためAIサービスに頼るしかありませんでした。

最初は、ChatGPTに聞いていたのですが、開発者IDを取得するところで躓いてしまい、先に進めなくなってしまったため、ChatGPTよりも賢いと評判のClaudeに相談することにしました。

Apple M1以降のCPUを搭載しているMacOS用に配布するためのQtアプリケーションを作成するには、アプリケーションに開発者IDを署名する必要があります。

公式には以下に作成方法が書かれているのですが、中途半端な開発者ID証明書を作成するところまでは簡単にできます。
https://developer.apple.com/jp/help/account/create-certificates/create-developer-id-certificates/

xcodeから作成するのが手っ取り早い。

結論から言うと、開発者ID証明書には、中間証明書とCA証明書を付加する必要があります。

Apple Root CAは以下からダウンロードして、キーチェーンアクセス.appにダブルクリックして取り込みます。
https://www.apple.com/certificateauthority/

中間証明書のありかは、Claudeに聞いて取得してきました。

1.G2の中間証明書を直接ダウンロード:
curl http://certs.apple.com/devidg2.der -o devidg2.der
2.ダウンロードした証明書をインストール:
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain devidg2.der

xcode→Settings→Accounts→Manage Certificatesで以下の画面を開き、+ボタンからDeveloper Application IDを指定すると、CAルート証明書までリンクしている自己証明書が作成されます。

コマンドで「security find-identity -v -p codesigning」を実行して、Developer ID Applicationがvalid状態であり且つ、ルートCA証明書まで正しく登録できていれば証明書の作成は完成です。

次に、アプリケーションに署名を付与していきます。

プロジェクト内に「entitlements.plist」を作成し、内容を以下にします。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.cs.allow-jit</key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
<key>com.apple.security.network.client</key>
<true/>
</dict>
</plist>

proファイルに以下の項目を追加します。

macx {
ICON = res/ticketpia.icns
QMAKE_INFO_PLIST = Info.plist
ENTITLEMENTS.files = entitlements.plist
ENTITLEMENTS.path = Contents
QMAKE_BUNDLE_DATA += ENTITLEMENTS
}

ビルドを行い、macdeployqtにて必要なライブラリをapp内に取り込みます。QtWebEngine.appも同様に行います。

% macdeployqt ticketpia.app 
% macdeployqt ticketpia.app/Contents/Frameworks/QtWebEngineCore.framework/Helpers/QtWebEngineProcess.app

# パスを変更
install_name_tool -change /opt/homebrew/opt/brotli/lib/libbrotlidec.1.dylib @executable_path/../Frameworks/libbrotlidec.1.dylib ticketpia.app/Contents/MacOS/ticketpia

install_name_tool -change /opt/homebrew/opt/brotli/lib/libbrotlienc.1.dylib @executable_path/../Frameworks/libbrotlienc.1.dylib ticketpia.app/Contents/MacOS/ticketpia

install_name_tool -change /opt/homebrew/opt/brotli/lib/libbrotlicommon.1.dylib @executable_path/../Frameworks/libbrotlicommon.1.dylib ticketpia.app/Contents/MacOS/ticketpia

以下にてアプリケーションに署名していきます。

# 拡張属性をクリア
xattr -cr ticketpia.app

# メインアプリの署名
codesign --deep --force --verify --verbose \
--sign "Developer ID Application: KAZUHIRO OZAWA (VSAYCF9RQD)" \
--options runtime ticketpia.app

# WebEngineProcessの署名(entitlementsを指定)
codesign --deep --force --verify --verbose \
--sign "Developer ID Application: KAZUHIRO OZAWA (VSAYCF9RQD)" \
--options runtime \
--entitlements ticketpia.app/Contents/entitlements.plist \ ticketpia.app/Contents/Frameworks/QtWebEngineCore.framework/Helpers/QtWebEngineProcess.app

この2つの署名を行わないと、例えばWebEngineProcessの署名を行わない場合、ticketpia.appのアプリは起動するがWebEngineが表示されずに落ちてしまう現象が発生します。

この情報がどこかに刺さったら嬉しいです。