代金収納代行システムで誤請求(誤引き落とし)が発生する仕組み2017年10月10日 13時02分25秒

■事件発覚
ある日三菱東京UFJ銀行のメイン口座の入出金を確認したところ、「口座振替4 NS XXX」という名目で4263円の引き落としが記載されていました。
全く身に覚えがありませんが、知らないうちに何か申し込んでいることも自分の行動としてあり得るので色々と身辺確認。
しかし、何も見当たらず、銀行のサポートに電話で確認。

御請求銀行入出金明細



■口座振替依頼書が提出されている
まず、銀行のサポート側の言い分としては私からNS(旧日本信販の略称で現在は三菱UFJニコス)へ口座振替依頼書が提出されていて銀行としては「正規の手続き」で請求処理を行っただけ、ということでした。

■ニコスカードは現在持っていない
確かに過去にはニコスカード持ってました。WOWOWぴあカード。でもこれは提携が解消されてクレジットカード自体がなくなっています。
当然、ニコスに対しては退会手続きが完了しています。
それ以外にはたまにフジヤカメラなどで購入する時にもニコスを利用する場合があります。
その場合も口座依頼書は書いていますが、その都度の提出をしているはずです。
そのことを銀行のサポートに説明してもらちが明かなかったのですが、何らかの手違いがあるのではないか、ということでニコスに問い合わせてくれ、とのことでした。

■ニコスに問い合わせ
ニコスのサポートに電話して事情を説明。
住所などの情報を伝えて確かに現在はニコスとの取引がないことを確認してもらい、また、「NSXXX]という明細上の項目はニコス側からの請求処理だということも認識してもらって、何らかの手違いが発生したということを認識してもらえました。
ここからニコスの調査開始。

■代金収納代行システムの問題と判明
色々な会社が口座振替手続きなどで会員などから代金回収しますが、多くの場合はクレジットカードなどを扱っている信販会社が手続き代行しているのが現状です。
これを代金収納代行システムと言います。
ニコスも当然代行業務を行っています。
ある会社の会員が書いた口座振替依頼書のニコスに対するシステム上の手続きでミスがあって私の口座から引き落とされたとのことでした。

全く、意味が分かりませんね。
電話対応した担当者(サポートの女性ではなくではなくあとから折り返してきた男性)からの説明は日本語がおかしい説明でした。論理的な話ができない感じ。
但し、ミスした会社から返金されるような手配はしたとのこと。
その電話で報告書を提出するように依頼しましたが、それもニコスの頭の悪い担当者は理解できず、報告書は以下に示すように誤請求した請求元の会社からのものでした。

■ミスした会社からの謝罪文書

謝罪のお手紙と返金

はい。このお手紙では意味が分かりません。

■報告書提出をこの会社の広報にメールで依頼
電話をかけるのもお金がかかるのでこの会社の広報宛にメールで報告書提出を求めました。
ニコスの担当者は活舌が悪く名前も良くわからないし電話もコールセンターしかわからなかったため仕方なくご請求した会社のホームページ経由で問い合わせた次第。
こちらはエンジニアなので専門用語を使った説明を依頼しました。
また、システム的な問題はニコスと連帯して報告するように求めました。

しかし、しばらく待っても返事がなかったため実名のマスコミリークなどをちらつかせる連絡をしたところやっと以下の報告を貰えました。

経緯報告書1


経緯報告書2




■責任の所在と問題点
ざっくり解釈するとシステムが「ざる」だということは分かりました。
どちらかというと一番責任が重いのはニコスで次が銀行、最後がミスした請求元の会社ですね。
請求元会社が報告するのは仕組みが分かってしまうと本当に筋違いですが、三菱UFJニコスおよび三菱東京UFJ銀行からの正式な謝罪連絡などはありませんでした。
以下、今回明らかになった問題点です。

(1) 口座振替依頼書は抹消手続きしない限り存続
  クレジットカードなどを作った時の口座振替依頼書は当該クレジットカードを解約しても銀行への抹消手続きはされない、ということが今回わかりました。
つまり、クレジットカード解約したら銀行に対してはそのクレジットカード会社に対しての口座振替依頼書の抹消手続きが必要、ということです。
※三菱東京UFJ銀行に対しては窓口に出向いてしか手続きできません。しかも、事情説明が非常にめんどくさい。手続き書類も事情説明しないと出てきません。

(2) 全く他人に対する請求が未確認で引き落とされる
 今回全く知らない他人の口座番号が私の口座と同じで、支店番号が間違ってシステムに登録されたことにより、私の口座から引き落とされてしまいました。
名義名や請求元の会社は関係ありません。

(3) 悪意があればいつでも「誤請求」できる
問題点(1)とも実は関係なくて、クレジットカード持ち続けていて口座振替依頼書も正常ならば全くの他人の請求が自分に向けられても防ぐ手立てがないということです。
架空の請求でも勝手に引き落とされる可能性があるということです。

(4) 誤請求をミスした側は認識できない
これが今回の事例の最大の問題。システム上、ミスしたことに気づけない。全ての段階でスルーしてしまいます。気付くのは間違って引き落とされた被害者本人だけです。しかもそれがお年寄りだったりしたら今回の私のように強気な調査はできないと思います。
また、全く銀行口座の記帳をしない人も気づかないでしょう。

■三菱UFJニコスと三菱東京UFJ銀行のシステムが問題
今回の「事件」の責任は明らかに三菱UFJグループにあります。
なので、ミスをした会社の名前は非公表にしましたが、こちらは明らかにしました。

(追記)記事で三菱東京UFJ銀行と表記している部分は2018年4月以降は三菱UFJ銀行と読み替えてください。

コピペ記事が技術をダメにする2017年09月28日 06時25分30秒

■きっかけ
最近IoT関連の技術開発のスタートアップの会社を取材しました。増資もして勢いがあるように見えます。若いけど優秀なエンジニアも揃っていて、と自信満々。いわゆる、はんだ付けカフェやレーザーカッター、3Dプリンタもそろえた「工作室」も一般に開放しました。
ところが、この会社のホームページのエンジニアが書いたArduinoでの温度センサーを使う記事が他のサイトのコピペ記事で、しかも、他の記事よりも質が悪い始末。
この記事は公開されてから4ヶ月以上放置されており、書いた当人以外のエンジニアもお粗末さを指摘していないということになります。
私はこの会社の技術力には疑問を持たざるを得ず、社長の資質にも疑問を感じる次第となりました。
社長に指摘の連絡をしましたが、「本人に伝えておきます」程度の反応でした。

■コピペ記事の弊害
コピペ記事の弊害はいわゆる検索エンジンに引っかかる複数の記事が「同じ」だということです。正しい内容ならもちろん問題ありません。
いくつかの主張のうちの一つを自分の考えで選択しているのならまだしも、無理解、無思想でコピペしてあたかもそれが正解かのような印象を持たせる。
間違っているのに数多くの記事で同じことを言っているのでそれを正しいと鵜呑みにする。
そこが問題です。

■技術の基本は考察と実験による実証
コピペ記事は書いてあることを鵜呑みにしてそれがソフトウェアであればコピーして実行して試しますが、それが正しい結果なのかの検証をしません。
なぜ、そのような計算をして、そのような結果が得られているのか。
それらを自分自身の頭で考えて検証してこその技術です。



温度センサーLM35DZを移動平均で処理する2017年09月26日 11時12分50秒


ADCからのセンサーデータをそのまま使うと様々な要因により値がふらつきます。
それを平滑化させるために移動平均という手法があります。

■移動平均の考え方
同じセンサーデータをある程度の数だけ格納してその数の平均値を求めるのですが、次々に新しい観測データを採用して古いデータを捨てていくという処理が移動平均です。

■移動平均に必要な処理構造
(1) センサーデータを一定数配列に保管します
(2) 一定数のセンサーデータの合計値を求めます
(3) センサーデータの合計値を格納数で割ると平均が求められます
(4) 配列に新しいデータを格納する時には一番古いデータを捨てます
(5) 一番古いデータを捨てる前にそのデータを合計値から引きます
(6) 合計値に新しいデータを加えます
(7) センサーデータ単体で平均値を求める代わりに最終的な換算時に加味することもできます

■サンプルプログラム
以前の記事のプログラムをベースに修正しています。
以下の部分が変わっています。
(1) 換算用のマクロの変更
(2) 配列へのADCデータ格納と合計処理の追加
(3) 配列インデックスをLED点滅に流用
(4) シリアル出力に合計値出力を追加
(5) 温度換算時に使うデータはADC出力の合計値を使う
移動平均版LM35DZ処理スケッチ

出力結果は以下のようになります。

移動平均版でのLM35DZ処理出力

■注意点
今回のサンプルではサンプリング周期と表示周期を同じ1秒としていますので室温測定には問題ありませんが、もっと早い応答性が必要な場合にはサンプリング周期をもっと短い間隔にして、表示や出力間隔とは分ける必要があります。

ADCの出力値をアナログ値に換算する考え方2017年09月25日 15時11分05秒

■ADC出力値からアナログ値を求めるやり方の問題
ADCから量子化されて出力されるデジタル値をアナログ値への換算を行う時に2^nで割るのか、2^n - 1で割るのかの問題ですが、ADCの内部の仕組みとしては以下図の左側で示したような配列とその要素のインデックスだと考えると問題が整理しやすくなります。
2^nとか2^n-1の代わりにここでは10bitADCを前提として1024と1023という数値でどちらかを表すことにします。

ADC出力値の換算方式の比較図


この図の左側で示した配列の条件は以下です。
(1) メモリ上の通常の配置とは逆のイメージ
(2) 10bitADC
(3) 基準電圧(VREF)は5.0V
(4) 1LSB = 5.0/1024.0 = 0.004882813V
(5) 上限(n) = 下限(n+1)未満の値

■1024で割る派の問題
ADCから出力されたデジタル値からアナログ値に換算するやり方で、1024で割る派の人たちは上記の「仕組み」を前提に話をしているわけですが、常に配列インデックスに対応したアナログ値の範囲の下限のデータを拾ってくることになります。
理屈から言えば上限を拾ってきても良いはずだし、下限と上限の中間の値を採用しても良いはずです。
この点が1024で割る派の人たちのおかしなところです。
現実的には下限であることは非常にまれでしょう。
シフト演算して処理を高速化するために1024で割るという主張の方がよっぽど説得力があります。

■1023で割る派には問題はありません
あえて問題があるとすればシフト演算での高速化はできません。
あくまでもブラックボックスとしてのADCを扱うため、出力値が0なら0Vだし、1023なら5Vとして係数を求めて度量換算する算数の問題として計算するだけです。
結果的に中間値を採用することになり、フルスケールに達すると確実に5Vになります。
もちろん、中間値とはいっても0の時は下限値を採用し、1023の時は上限値を採用するような変則的な対応付けが自動で行われることになります。
図の右側で示した通り左側の配列の下限値から上限値の間に換算値は収まっていることが分かります。
無思想でコピペ増殖で1024で割る派が多い中、数少ない1023で割る派の書籍はこちら

とは言え、実験してみるのは筋なので、実際のセンサーでの実験結果はこちら

温度センサーLM35DZを実用域で使う2017年09月25日 01時17分37秒

秋月通商などで手に入る安価な温度センサーにLM35DZというものがあります。
これをArduinoと組み合わせて使う記事は検索するといくつも出てくるのですが、ほとんど「コピペ」で有用な追加情報はほとんど得られない状況です。

そこで、いくつか実験も兼ねてテストしてみようと思います。
以下は実験風景です。
実験風景

多くの記事は基準となる温度計などとの測定値の比較をして検証を行うなどの基本的なことが行われていません。
また、データシートの読み込みが足りなかったりADCからの取得値のデータ処理の仕方の根拠説明がありません。

今回の実験では比較のために他の温度センサーでの観測値と市販のデジタル温度計の測定値を使います。
「他の温度センサー」としてはセンサーそのものがデジタル値を返すセンシリオンのSHT-11を使いました。これはADCによる変換処理の仕方の影響を排除するためです。

■動作電圧
LM35DZに印加する電圧範囲は広く、4V~20Vとなっています。
実験風景でオレンジ色はArduinoの5Vに接続しており、赤色は3.3Vに接続しているのですが、実は実験の結果、3.3Vで十分に動作することが分かったため、3.3Vで動作させることにしました。



■ADC基準電圧
ArduinoのデフォルトのADC基準電圧は5Vです。
一方でLM35DZを追加部品なしに使う場合は氷点下の測定はできず、10mV/℃という特性なので100℃の場合は1000mV、つまり1Vの電圧程度しか測る必要はないでしょう。このようなセンサーをADCで使う場合は基準電圧を下げるかアンプなどで増幅するなどしてフルスケールと基準電圧が近くなるようにします。
Arduinoはデフォルトの設定以外にもINTERNALという指定をすることにより機種ごとの異なる電圧をADCの基準電圧として使うことができます。
Arduino UNOの場合はその電圧は1.1Vです。
今回は1.1Vを基準電圧に設定します。
なお、通常の5Vが基準電圧の場合、生活環境での室温は明らかに他のセンサーの測定値よりも小さい値となりましたので、実用にならないことを確認しています。
スケッチは以下になります。
デフォルトと1.1Vの設定処理はマクロで切り替えるようにしていますのでどれ位値が変わるかは試してみると分かります。
ArduinoIDE上のスケッチ

■ADC基準電圧とプログラムの対応付け
5Vの基準電圧とか3.3Vの基準電圧とか1.1Vの基準電圧とかいろいろありますが、本当にそれらの電圧が基準電圧として正しいのでしょうか?
5Vのつもりが5.01Vであったり、4.98Vであったりします。
当然プログラム上はそれに合わせて実測値を採用しないと変換処理の誤差となります。
今回はそこまで実行していませんし、1.1Vの基準電圧の場合は外部から正確に測ることもできませんから、理論値として処理するしかありません。
また、これらの基準電圧そのものが温度によって変動する場合もありますので、センサーを使った測定というのはそれだけ奥が深いものだということを忘れないでいただきたいと思います。

■10bitADCでの換算について
10bitADCを使った変換処理で最近よく見かけるのは1024で割っている処理です。
ソフトウェアとしての前提条件とブラックボックスとしてのADCを扱う場合はこれは算数的には間違いです。
0Vの時に0が出力され、5V(1.1V)の時に1023が返るのですから、1024という数字はどこから出てくるのでしょうか?
例えば「10kmの距離を5時間かけて歩きました。時速は?」という問題を解くときに10km/6なんて計算しますか?しませんよね。
0~1023は1024段階だから1024?違います。
上記の時速の問題で0~5の6段階だから6で割る、ではないでしょう?
1024にする場合の理由はもちろんあるのですが、算数の問題の前提条件を無視するのは違います。
理屈は別の記事に譲ることにして、上記のスケッチでは両方試しています。

■他の温度センサーと温度計との比較
全部バラバラでした。
あえて近い組み合わせを選ぶとセンシリオンのセンサー出力値とADC基準電圧1.1Vで1023で割り算した値でした。とはいえ、1024で割ったものもそれ程差があるわけではありません。
単体の温度計の値は冒頭の写真を参考にしてください。HAKUBAの温度計は近い値を示しています。
センシリオンセンサーなどを使った他のシステムの出力
上記のデータはカンマで区切ってありますが、左から3番目の値がセンシリオンのSHT-11というセンサーを使った温度測定値です。
今回のスケッチでのシリアル出力結果
上記が今回試したスケッチでの実行結果です。

■Lチカの理由
上記のスケッチではLEDを点滅させていますが、これは他の負荷がある場合にADCへの影響があるかどうかを確かめるためです。
試しにA0に3.3Vを直結してAREFをデフォルトの5Vにしてみると分かります。
固定値のはずがふらついています。
もちろんこれはLチカの影響だけではありません。要はADCはセンサーと接続しない場合でも値がブレるということの確認です。