以下記事につきまして、かねてより提起されていました訴訟の判決が確定したことに伴い、その一部を削除致しましたのでお知らせ致します。

#接触確認アプリ #COCOA の無償ボランティア開発美談は本当か？
#接触確認アプリ #COCOA はマイクロソフトの夢を見せられているのだろうか？

経緯

2021年3月26日付けにて、A氏(仮名)より上記記事内容に関して名誉権の侵害を理由に

1. 金256万3000円及び延滞損害金
2. ブログとTwitterへの謝罪記事の掲載
3. 当該記事の全削除
4. 訴訟費用の全額負担

を求める民事訴訟が提起されました。

その後地裁判決および高裁判決など諸々あったのですが、本年3月11日に

1. 金22万円及び延滞損害金
2. 当該記事中の一部の削除
3. 訴訟費用1/10の負担

との判決が確定しました。

この判決に伴いまして、上記記事中高裁判決が指示する部分に関して、一部削除を行っております。

読者の皆さまには大変申し訳ありませんが、事情をお汲み取りの上ご容赦賜りますようお願い致します。

なお事件番号については公表致しませんのでご了承下さいませ。

以上です。

R1.3.26です。また久しぶりの更新です。バグ修正版となります。

「RSSロード時に異常終了しました」エラーでマイリストのダウンロード出来なくなっていた問題を修正しました

コメント欄でお知らせ頂いていた問題で、長らく時間がかかってしまい、大変申し訳ありませんでしたが修正いたしました。

サーチリストの検索条件で「より多い」を選択すると検索結果取得時にエラーとなっていた問題を修正しました

こちらも以前にコメントでご指摘頂いていた問題の修正となります。

.NET Framework 4.6.2以降での対応となりました

これまでは.NET Framework4以降を動作対象としていましたが、4.6.2以前ではすでにサポートが終了しており、またWindows10以降(バージョン 1507以降)であればデフォルトでインストールされていることから設定を変更しています。これ以前の.NET Frameworkをお使いの場合はバージョンアップをお願いします。

何かありましたらコメント欄までお知らせください。

気づけば一年ぶりの更新ですね…。

R1.3.25をリリースしました。大変お待たせしましたがバグFIX版となります。

不具合情報についてお寄せ頂きました皆さま、誠にありがとうございました m(__)m

niconico側の変更のため、新規でマイリストが追加出来なくなっていた問題を修正しました

コメントなどでもご指摘頂いていましたが、起動時やマイリストの更新時などに「マイリストの操作時にHTTPエラーが発生しました[リモート サーバーがエラーを返しました: (404) 見つかりません]」とのエラーが表示されて、新規でマイリストが追加出来なくなっていた問題を修正しました。

かなり以前からご指摘頂いていたにも拘わらず当方の都合で長らく修正版をご提供できず、大変申し訳ありませんでした。

但し、影響箇所が多く、既知も含めまだテストが十分でないところもあるかと思います。

しかしまずは重大な部分を修正し最低限以前通りに利用できることを優先致しました。不足な部分については追って修正致すつもりですので、ご理解とご容赦願えれば幸いです。

パスワード認証も含めログインが出来なくなっていた問題を修正しました

こちらは最近発覚した問題ですが、大変クリティカルな不具合ですので、やはりテストが不十分な部分もあるかと思うのですが、修正版のリリースを最優先としました。

同様に不足な部分については追って修正致します。問題ございましたらご容赦下さい。

現在把握している既知の問題

• Firefoxとの認証連携を行っている場合に、マイリストへの動画追加などでエラーとなる場合があります。その場合はパスワード入力を選択して下さい
• マイリストの変更ダイアログ画面では[並び順]が正しく表示されません(変更結果は正しく反映されます)
• マイリストからの[移動]や[送る]は正常に動作しません

繰り返しになりますが影響範囲が大きかったため、他にも把握していない問題はあるかと思っています。

またしばらくお時間をいただくことにはなりますが、追って修正してまいりますので、ご容赦くださいませ。

何かありましたらコメント欄までお知らせください。

大変お待たせしました。長らくダウンロード時のエラーで使用できなくなっておりましたが、FIX版のR1.3.24をリリースしました。ご迷惑をおかけして申し訳ありませんでした。

niconico側の変更のため、ダウンロードが出来なくなっていた問題を修正しました

niconico側ではこの度全面的に従来のダウンロード方法を廃止してHLS形式(DMCと内部で呼ばれる仕組みです)へ移行した模様です。ニコニコPodderでもHLSへ追従しました。

これに伴い従来のFlashビデオ(VP6)やSWF(Flash)にも対応していた以前の方法は完全になくなった模様です。特にFlashビデオ自体の投稿はすでに昨年に停止されておりSWF(ニコニコムービーメーカーで作成できた)もとうの昔にアップロードは廃止され、徐々にHLS + H.246へ過去動画も変換が進んでいましたが、これでいずれの古の形式もダウンロードされる可能性は完全になくなりました。
ニコニコPodder ではこれらの変換機能は念のため残し続けていましたが、次以降のバージョンで廃止する予定です。
最初期から10年以上に渡って提供してきましたので、感慨深いですね…。

同梱のffmpegを4.3.1へバージョンアップ

上記のHLS対応はやはりffmpegで実現しており、ニコニコPodderはラッパーにすぎません。
そのため同梱のffmpegを4.3.1へ(かなり久しぶりに)バージョンアップしており、これに伴ってsetting.ini(“C:\Users(ユーザー名)\AppData\Roaming\rocaz.net\niconicoPodder”内にあります)に古いバージョンでの変換オプションがあった場合には、日付日時を付加したバックアップファイル作成後に4.3.1に対応した変換オプションへ自動的に置換しています。
変換オプションを追加したり変更されている場合は、ご自身で4.3.1へ対応する必要がありますので、ご注意ください。

その他、以下のような問題も修正しています。

• “C:\Users(ユーザー名)\AppData\Roaming\rocaz.net\niconicoPodder”へ常にバックアップファイルが作成されていた問題を修正しました
• 検索URLがスナップショット検索APIv2形式で保存されていなかった問題を修正しました
• 以前のランキングURLで保存されていた場合を新しいURLへ変更するよう修正しました

重ね重ね、この度は修正にお時間がかかってしまい申し訳ございませんでした。
今後も引き続きニコニコPodderをご愛用頂けますと幸いです。

何かありましたらこちらのコメント欄までお知らせください。

現在ニコニコ動画側の仕様変更につき、エラーが発生しダウンロード含め障害が発生しています。

原因につき確認しましたが、割と大きめの機能の変更と追加が必要であることが判明しておりしばらくお時間を頂く可能性が高く、また現時点でいつまでに修正できるか、お約束が出来ません。

修正自体は可能と思っておりますがテストなどにも十分なお時間を頂きたく、甚だ恐縮ですが今しばらくのお時間を頂けますようにお願い申し上げる次第です。

引き続いての皆さまのご理解とご支援を賜れましたら幸いです。
どうぞよろしくお願いいたします。

(2021-04-09 追記) FIX版としてR1.3.24をリリースしました。

バグFIX版です。

コメント欄へご報告頂いていました、動画説明にダブルクォーテーションが含まれているとエラーとなりダウンロードできなかった問題を修正しました。

また、プロパティ画面にてサムネイル画像が正常に表示できなかった問題についても修正しています。

何かありましたら、こちらのコメント欄までお知らせ下さい。

バグFIX版です。

恐らくですが、Flash終了に伴うniconico側の変更のため、ダウンロードが出来なくなっていましため、これを暫定的に修正しました。

根本的にはHLS形式に対応すべきなのですが、大きな内部変更と仕様変更も伴うため、徐々にですが対応していく予定です。

また検索仕様をスナップショット検索APIv2へ変更しています。

何かありましたら、こちらの記事のコメント欄までお知らせください。

先日のR1.3.20にて、購読中でもトライアル期間となってしまう問題があり、急遽FIX版としてR1.3.21をリリースしました。

お手数をおかけしますが、バージョンアップをお願いいたします。

何かありましたコメント欄までお知らせください。

バグFIX版です。

• (Re)のリリースに伴い動画音楽変換が失敗していた問題を修正しました
  
  

何かございましたら、コメント欄までお知らせ下さい。

前々々回と前々回と前回からの続きです。

接触確認アプリ COCOAにおけるベンダーロックインのリアル

そもそも本稿含む一連のCOCOA記事では「無償の民間ボランティアチームと喧伝したCOVID-19Radarオープンソースプロジェクトは実際はマイクロソフト・ファミリーによる営業活動ではないか」とともに「マイクロソフト Azureプロダクトによる囲い込み = プロプライエタリなベンダーロックインではないか」とも主張してきた。

この「マイクロソフト Azureによるプロプライエタリなベンダーロックイン」の部分について、主にマイクロソフト関係者の方々から「何をもってベンダーロックインというのか」「いずれのパブリッククラウド使おうと何らかのロックインはある」「そんなにロックインが嫌ならオンプレミスで運用しろ」「たとえCOVID-19Radarではなくコード・フォー・ジャパン(CfJ)のまもりあいJapanをしたところでロックインの部分はあった」「クラウドではロックインは完全に排除などできない」などの意見を頂いた。

部分的に納得できる意見もあるものの、これらの意見にはことCOCOAにおいては明確に誤っているとの姿勢を示さないといけないと思っている。
民間会社の1プロジェクトなら好きなプロダクトでどれだけプロプライエタリ(“利用者の持つ権利を制限的にすることで自身や利用者の利益およびセキュリティを保持しようとするソフトウェアを指す。制限には法的手法や技術的手法など様々な方法がある”)なベンダーロックインに陥ってもらってもいいだろう。各社の自由にまたマイクロソフト・ファミリーは大いに喧伝すればよい。

しかしCOCOAは「公共事業」である。この事実は幾つ言葉を重ねても消えることは無い。
接触確認アプリ COCOAの仕様書においても当然にして、中立性に関する事項における「いわゆるベンダーロックインの解消」はしっかりと掲げられている。

では接触確認アプリ COCOAでのベンダーロックインへの対応とはどうなっているのか。

実はこの点についてはCOVID-19RadarオープンソースプロジェクトのGitHubリポジトリに明快な答えが掲載されている。下記にAzureで(つまりサーバーサイドで)使用されているプロダクトを抜粋しよう。

• FrontDoor
  • ロードバランサ兼アプリケーションゲートウェイ
• Functions
  • サーバーレス・アプリケーション
• Application Insights
  • ログやメトリクス監視
• Cosmos DB
  • NoSQLデータベース(恐らく今回はドキュメント型(コアSQL))
• Blob Storage
  • オブジェクトストレージ(AWSで言えばS3)
• CDN
• Key Vault (HSM)
  • マネージドIDやモバイルアプリのデプロイに必要な秘密鍵など各種キーを保管するPaaS型HSM(セキュアストレージ)
• GitHub
• Azure DevOps
  • モバイルアプリ含めたアプリケーションCI/CDツール。ビルドやテスト・デプロイなどの一連のリリース作業を自動化する
• App Center
  • モバイルアプリケーション用のビルドやテスト・デプロイまたアプリストアへの公開などの一連のリリース機能をAzure DevOpsと連携して行う(モバイルアプリのパフォーマンス評価などの機能もあるが今回は使っていない模様)

注釈を入れさせてもらったが、採用プロダクトの「全てが」マイクロソフト社独自のプロダクトばかりで選定されているのには驚かされる。

マイクロソフト社独自プロダクトと書いたが、念のため書き添えると、これらの製品はAzureクラウドでしか提供されておらず、他のAWSや独自のオンプレミス環境などへそのまま移行することは出来ない。
ここがクラウドにおけるベンダーロックインの肝である。

FrontDoorやCDNなどはアプリケーションコードが直接関わるところでは無く、また各クラウドベンダーごとに別製品であっても実際のところ提供する機能に大きな差異は無いのであまり問題にはなりにくい。

しかしCosmosDBなど独自のDBの場合は専用のSDKを使用するため、もし将来他の環境へ移行したいとなると、当然他の種類のDBを選定する必要がある。それに応じてソースコード全体を修正するのは大仕事だろうし、またそもそもDB設計からして見直しを迫られる可能性も高い。

サーバーサイドアプリケーションはFunctionsに置かれており、Dockerコンテナを使用する(またはFunctions環境自体がコンテナにも出来る)とのことだが、構成上一般的なコンテナオーケストレーションツール(kubernetesなど)へそのまま移行できるような柔軟性があるとは思わず、また一般的にはKey Vaultから認証情報を取得するインターフェースを実装していたりBlob Storageなどのストレージへの保管なども必要であるなら代替を考えやはりコードは大きく修正することになるだろう。

何よりも実は影響が大きいと思われるのはAzure DevOpsやApp CenterといったCI/CDツールだ。

今日のサーバーサイドアプリケーションはコードを作れば終わり、というものでは無い。アプリケーションのための各種テストケースやリリースのためのビルドといったオートメーションツールでも一種のコードを記述する必要があり、これはCI/CDツールごとに大きく異なる。
CI/CDツールは現在では個別のクラウドに(大きく)依存しないサードパーティーツールも非常に数多いが、Azure DevOpsやApp CenterはもちろんAzure内のアプリケーションにしか適用できない。
サードパーティーツールへ移行するにせよ、恐らく全てを作り直す必要に迫られるだろう。

いかがだろうか。これが(Azureに限らず)「クラウドベンダー独自のプロダクトのみで構成されたシステムで現場が味わうベンダーロックインのリアル」である。
いかに「逃げにくくなっているか」おわかり頂けるだろうか。

接触確認アプリ COCOAでは、モバイルアプリのプラットフォームであるXamarinとC#については「iOSとAndroidで標準的なSwiftとKotlinならオープンソースへ貢献したい開発者がもっと多いのに」などよく嘆かれているが(個人の観測範囲)、実のところもっと深刻なのはサーバーサイドアプリケーションなのである。

これが、コンテナオーケストレーションツールとしてkubernetes(AzureでもAKSというマネージドkubernetesサービスがある)を、DBとしてMySQLでもPostgreSQLでもまたはCassandraやMongoDBといったNoSQL DB(実はCosmosDBでも内部的にはCassandraやMongoDBに対応可能である。が今回はコアSQLと呼ばれるマイクロソフト独自のドキュメント型DBが採用された)であれば、アプリケーションとしての主要な部分はそのままどの環境へでも移行できるはずだ。
例えばマルチクラウド対応としてそうした想定を最初から行うケースも最近では珍しくない。

しかしそうはならなかった。

逆に「意識的にマイクロソフトのプロプライエタリなプロダクトのみ選んだ」「仕様書で言うところの市場において容易に取得できるオープンな標準的技術又は製品はわざと排除した」とさえ思える。

まさしく接触確認アプリ COCOAのシステムは、教科書に載せられるほど典型的な、パブリッククラウドとオープンソースを隠れ蓑にしたクラウドベンダーによるロックインの好例と化している、ということだ。

ベンダーロックインは何故マズいのか

こと同じくして、マイナポイント・サイトへのマイナカードでのPCからのログインが未だにIE11にしか対応していない(iOSやAndroidのモバイル機器では端末のNFC機能を用いて著名ブラウザから可能)時代遅れも甚だしい仕様に利用者の不満が続出し、政府CIO補佐官でもある楠正憲氏がその赤裸々な「理由」を説明する騒ぎがあった。

本稿ではこの話題には深く触れない。

しかしこの話からの学びは「選択肢(オプション)を失った瞬間、システムはオワコン化しレガシーとなる」という点だろう。

ベンダーロックインとは「特定ベンダーが囲い込むことによる競争原理の阻害」「経営視点からは(当初のプラットフォームコストが高騰し別のプラットフォームへ移行する際の)スイッチングコスト」の問題として語られることが多い。
と同時に今回は政府調達案件での「税金の使われ方の妥当性」とも捉えることが出来る。
ユーザー企業でIT戦略に関わることが多い方々にとっては税金ではないにせよ、「選択肢が奪われる」問題は、大変身近な懸念ではないだろうか。

まさしくこの一点において、マイナポータルでの問題と接触確認アプリ COCOAでのベンダーロックイン問題は同じ軸線上にあることが分かる。
前項でも述べた通り、将来へ向けて「移行可能な選択肢を確保する」見通しを阻害することが、プロプライエタリなベンダーロックインの典型的な悪質性の本質なのだ。

接触確認アプリ COCOAは現代の新たなベンダーロックインの類型だ

先に指摘しておくが、ここに及んでも「それでも開発期間の無い中で可能な技術で駆使するのが悪いのか」「何年も使うことの無いシステムならたとえロックインされても大きな問題にはならない」という意見は根強く残るだろう。

ここで先の楠氏のブログ記事から一部引用しておこう。

普通は役所のシステムって構築してから5年とか7年は塩漬けにして使うもので、一度やらかしてしまうと名誉挽回の機会なんて向こう数年は与えられないんだけど、

何故お役所ってオワコンIEが大好きなの？

政府調達案件において短期間で簡単にシステムの更改は行えないし、まさにそれ故にマイナポータルに限らず、官公庁システムは十分な将来可能性とオプションを最初に確保し、残し続けていくことが肝要であることがわかる。

はっきり言えば、「開発期間が短いならしょうがない」「現場の苦労を考えろ」「そういう状況でのベンダー依存は許容される」といった意見は、発注側・ユーザー企業のためではなく、結局のところベンダー側へ利しているに過ぎない。
短納期は全く別に解決されるべき問題であって、発注側・ユーザー企業は詭弁に誤魔化されてはいけない。

「ベンダーによる囲い込み」問題は特に目新しい話題では決して無い。
コンピュータ黎明期を除けば、ここ何十年もそれぞれの時代において様々なベンダーによる囲い込み戦略が跳梁跋扈してきたのがIT業界であったと理解している。

そこに「ようやく」風穴を開けられる、ベンダーでは無くユーザー主導でのシステム戦略を組み立てる足がかりとなったのが、いわゆるオープンシステムの潮流であったとも理解している。
オープンソースであることや民間活力が必ずしも必須で無いことには注意したい(それらを否定しているのでは無い)。本質的な「選択肢を確保する」ことに繋がらないのであれば、ただただ将来へ向けてレガシーシステムを量産し続けるだけだということだ。

そう考えると、接触確認アプリ COCOAでのベンダーロックインの仕組みはよく出来ている。
昭和の頃からの伝統的な、寡占プロダクトでユーザーを囲い込むのではなく、「パプリッククラウド」「オープンソースプロジェクト」「民活」など役所にも社会にも綺麗に説明可能な要素が絶妙に忍び込まれている。
同時にクラウドではプロプライエタリなプロダクトとベンダーロックインの仕組みを備え持つ。

まさしく、昭和の時代から綿々と続くベンダー囲い込みの伝統は途絶えること無く、パプリッククラウドの時代においても、新たなロックイン手法を生み出し続けているのである。

この話、まだまだ新たな展開はあるのだが、続くかどうかは気が向いたら書く、多分…。

(7/26 07:30 修正) 中盤の何故ロックインが起きるかの箇所に説明が足りないと思えたため、がっつり追加しました。また一部表現などを見直しています。
別にAzureだけの話じゃないよ

https://www.atmarkit.co.jp/ait/articles/1912/05/news026.html