風柳メモ

ソフトウェア・プログラミング関連の覚書が中心

Power Queryのデータソースを間接的に(相対パスで)指定する場合のプライバシー保護に関するリスクについて

Power Queryにおいて、CSVファイル等のデータソースを間接指定する(相対パスを使う)ことはプライバシー保護上のリスク(情報漏えい)が発生しうるために一般には推奨されないという話題をみかけたのですが、では「どうして間接指定をすると(相対パスを使うと)リスクが発生するのか?」その理由について、簡単な具体例を交え備忘録として記事にしておきます。
また、Power Queryにおけるプライバシーレベルに関して、望ましいと思われる設定(ポリシー)についても自分が把握できた範囲で言及してあります。



概要

Power Queryを用いてCSVファイル等からデータを取得する場合には通常、データソース(対象ファイルの場所)を絶対パス("D:\Path\To\Data.csv"のような形)で直接指定する必要があります。

これだと、たとえばAさんが使っていたエクセルファイルをBさんのPCに持っていくようなケースでは、Bさんの環境にあわせてパスを書き換える必要があったりして不便なため、
データソースとなるファイルは、Power Queryを設定したワークブック(エクセルファイル)と同じ場所に置く
といったルールを定めた上で、
データソースをワークブックからの相対パスで間接的に指定
したくなります。
対象のファイル名("Data.csv"のようなもの)だけを決めておいて、ThisWorkbook.Path & "\Data.csv"のようにして組み立てたパスをPower Queryに渡してやるイメージです

実際、例えばこちらの記事に書かれているように、CSVファイル等のデータソースのパスをワークブックの名前定義を介してPower Queryに受け渡す手法等を用いて、間接的に指定することは可能です。

ワークブックと同じところに置かれたCSVファイル(例えば商品マスターと売上データ)のみをPower Queryで読み込んだり結合等の加工を行うといった用途なら、外部とのやり取りは発生しないため、このような手法(間接指定)をとっても特に問題は生じないと考えられます。
もしこのケースでもリスクが発生しうるということであれば、ご指摘願います

ところが、この手法を用いると、
データソースに対するプライバシーレベルを直接設定することができない
という制限が生じます。

プライバシーレベルが設定できないデータソースが存在すると、例えばその中に含まれるデータを元にして異なる場所にあるデータベース等の別のデータソースとの間でデータをマージ(結合)したい場合には、全てのプライバシーレベルをパブリックにするか、「プライバシーレベルのチェックを無視する」という設定にする必要が出てきます(追記:別の回避策もあるようです(後述))。
こうなると、当該データソースのデータが外部に漏出してしまう可能性が出てきてしまうため、特にデータに機密情報等が含まれていた場合には深刻なリスクとなってしまいます。

追記(2022/01/19)

CSVファイル等のデータソースをワークブックと同じところに置いているという条件ならば、
ワークブックと、それが置かれているフォルダ/ドライブのプライバシーレベルを「組織」に設定する
ことで、プライバシーレベルが「パブリック」のデータベース等へのデータ送出は制限しつつ、データのマージが可能なようです

組織内で適切な運用ができるのであれば、間接(相対パス)指定も選択肢として取りうるのかも知れません。
この場合に別のリスク等が発生しうるのかについてまでは検証できていませんが、少なくとも本来「プライベート」に設定すべきデータソースに関しては、間接(相対パス)指定は避けるべきではあるでしょう

プライバシー保護(情報漏えいの防止)の観点からの望ましい設定と運用(ポリシー)(2022/01/19追記)

調べた範囲で、 プライバシー保護(情報漏えいの防止)の観点から望ましいと思われるポリシーについて記載しておきます。

クエリのオプションのグローバルプライバシーレベルの設定

データ>データの取得>クエリオプション>グローバル>セキュリティにおいて、プライバシーレベル

f:id:furyu-tei:20220119134559p:plain
グローバルのプライバシーレベル

の設定を

  1. 常に各ソースのプライバシー レベル設定に従ってデータを結合します
  2. 各ファイルのプライバシー レベル設定に従ってデータを結合します

のどちらかにしておきます(「常にプライバシー レベル設定を無視します」は選択しないようにします)。
なお、1.と2.の違いですが、1.を選択しておくと、現在のブック>プライバシーでは設定がグレーアウトされ(プライバシーレベルを無視する設定にできない)、個別のクエリについても「プライバシーレベルのチェックを無視…」にチェックを入れて保存したとしてもこれは無効化されるようです。

クエリのプライバシーレベルは適切な設定を!

クエリのマージを行う場合などには、必要に応じてプライバシーレベルの設定ダイアログが表示されます。

f:id:furyu-tei:20220119130739p:plain
プライバシーレベルの設定ダイアログ

これは、Power Queryが
「プライバシーレベルの変更によってクエリの最適化はできるけれど、そうするとデータを送信しないといけないから、プライバシー上問題がある可能性がありますよ、どうしますか? 」 と尋ねてきているイメージです。
逆に、上記のグローバルプライバシーレベルが適切に設定されていて、かつ、プライバシーレベルの設定ダイアログが出ないようなら、当該クエリはプライバシー保護の観点からは問題ないものと判断できると思われます

このときには、適切なプライバシーレベルを判断して、保存するようにします。

特に、

  1. 「このファイルのプライバシー レベルのチェックを無視します」にはチェックを入れない
    f:id:furyu-tei:20220119132118p:plain
    プライバシーレベルのチェックは無視しない
  2. 全てを「パブリック」にするといった安易な設定は行わない
    f:id:furyu-tei:20220119132151p:plain
    安易にすべてパブリックにしたりしない

ように留意しましょう。

データソースを間接指定することの是非

データソースを相対パスで間接指定すること自体が問題と言うよりも、Formula.Firewallの警告が出てしまうなどしてクエリが動作しないからといって、安易にプライバシーレベルのチェックそのものを無効化したり、すべてをパブリックに設定してしまうようなユーザーの行動(およびそのような設定をリスクの説明をすることなく推奨する記事等)の方に問題があると考えられます。

上述したポリシーを遵守した上で、

  • ワークブックと同じ場所に置いたCSVファイル等のデータソースのみを扱うケース
  • 「組織」(ワークブックと間接指定したデータソースを置くフォルダ)と「パブリック」(外部データソース)のふたつのプライバシーレベルのみで運用可能なケース(※留意点はこちら

であれば、とくに問題はないように思えます。
他にリスクなどが発生するケースがあればご指摘ください


ここからは具体例等です、詳細を知りたい方は御覧ください

リスクの生じうる具体例

前提

プライベートな(ローカルのストレージ上にあって、機密情報を含むような)CSVファイルと、パブリックな場所にあるデータベース上のデータを、Power Queryでマージしてテーブルデータを作成するような場合を想定しています。

f:id:furyu-tei:20220118220400p:plain
シチュエーション

データソースとしては、CSVファイル(202201.csv)と

f:id:furyu-tei:20220118222353p:plain
CSVファイルから読み込んだデータ
データベースのテーブル(t_holiday)
f:id:furyu-tei:20220118222412p:plain
データベースのテーブルから読み込んだデータ

とがあり、これを日付を照合列としてマージし、
f:id:furyu-tei:20220118223401p:plain
マージ設定
一つのテーブルにします。
f:id:furyu-tei:20220118222814p:plain
マージされたデータ
単なる例ですので、データの内容に意味はありません、念のため。

Power Queryのクエリのオプション(データ>データの取得>クエリ オプション)として、プライバシーレベルは「● 各ファイルのプライバシー レベル設定に従ってデータを結合します」の状態になっているものとします。

f:id:furyu-tei:20220118221326p:plain
グローバルなプライバシーレベルの設定

また、各データソースについては、初期のプライバシーレベルは「なし」になっているものとします。

f:id:furyu-tei:20220118223111p:plain
CSVファイルのプライバシーレベル(初期状態)

f:id:furyu-tei:20220118223157p:plain
データベース上のテーブルのプライバシーレベル(初期状態)

絶対パスで指定する場合(直接指定)

CSVファイル用のクエリ

f:id:furyu-tei:20220118224916p:plain
CSVファイル用のクエリ(直接指定)

マージに伴うプライバシーレベルの設定

CSVファイルのクエリとデータベースのクエリとをマージしようとすると、次のようなプライバシーレベルに関するダイアログが表示されました。

f:id:furyu-tei:20220118225609p:plain
プライバシーレベルのダイアログ

これを適切に設定し(CSVファイルについては「プライベート」、データベースについては「パブリック」)、

f:id:furyu-tei:20220118225731p:plain
プライバシーレベルの設定

保存すると、無事目的のテーブルを得ることができました。

相対パスで指定する場合(間接指定)

CSVファイル用のクエリ

ワークシート上と名前定義で次のように間接的にCSVファイルの場所(DateListFilePath)を指定できるようにし、

f:id:furyu-tei:20220118224218p:plain
シートと名前定義の状態

定義した名前をPower Queryのクエリ中で指定しています。
f:id:furyu-tei:20220118224953p:plain
CSVファイル用のクエリ(間接指定)

マージに伴うプライバシーレベルの設定

CSVファイルのクエリとデータベースのクエリとをマージしようとすると、直接指定のときと同じようにプライバシーレベルに関するダイアログが表示されますが、内容が若干異なっていました。

f:id:furyu-tei:20220118230113p:plain
プライバシーレベルのダイアログ
「現在のブック」というものが増えていました。
とりあえず、現在のブックとd:\については「プライベート」、データベースについては「パブリック」に設定して
f:id:furyu-tei:20220118230229p:plain
プライバシーレベルの設定

保存してみたのですが、
f:id:furyu-tei:20220118230333p:plain
Formula.Firewallの警告

Formula.Firewall: クエリ '202201' (ステップ '変更された型') が、同時に使用できないプライバシー レベルの複数のデータ ソースにアクセスしています。このデータの組み合わせを再構築してください。

のような警告が表示されてしまい、テーブルを取得することができません。

また、この状態でデータソース設定を開いてみると、

f:id:furyu-tei:20220118230715p:plain
間接指定時のデータソース設定

手動で作成したクエリのため、一部のデータ ソースが一覧に表示されない可能性があります。

なる警告が表示されています。

やはり、データソースを間接設定すると、当該データソースに対してはプライバシーレベルの設定ができず、このままでは他のデータソースとのデータのマージ(組み合わせ)ができなくなってしまうようです。

間接指定の場合にはプライバシーレベルのチェックを無視する必要あり

先の警告が出たままだと何も出来ないので、とりあえず、一旦データソース設定をもとに戻してみました(すべてのデータソースについてプライバシーレベルを「なし」に変更)。すると、マージしたクエリの警告が

f:id:furyu-tei:20220118231417p:plain
データのプライバシーに関する情報が必要

データのプライバシーに関する情報が必要です。 [続行]

のように変わりました。

[続行]を押すと、改めてプライバシーレベルの設定ダイアログが表示されました。

f:id:furyu-tei:20220118230113p:plain
プライバシーレベルのダイアログ

今度は、

f:id:furyu-tei:20220118232018p:plain
プライバシーレベルのチェックを無視

☑ このファイルのプライバシー レベルのチェックを無視します。プライバシー レベルを無視すると、未承認の人に機微または機密の情報が開示される可能性があります。

の設定にチェックを付けた状態で保存してみます。
すると、ようやく無事に(?)目的のテーブルを得ることができました。

ちなみに、上記のチェックをしなくても全てのプライバシーレベルをパブリックにすることでも

f:id:furyu-tei:20220119092744p:plain
プライバシーレベルを全てパブリックに設定

目的を果たせはしますが、実質プライバシーレベルのチェックを無視するのと変わらないですよね。

直接(絶対パス)指定時と間接(相対パス)指定時のデータの流れの違いと間接指定時のリスクについて

プライバシーレベルのチェックを無視するようにすると、 別のデータソースのあるパブリックな場所にプライベートな(機密情報等を含んだ)データが送られてしまうリスクが有ります。
例えば「SELECT * FROM <パブリックなDB上のテーブル> WHERE secret = <プライベートなデータの照合列の値(機密情報)>」のようなSQLクエリをパブリックなデータベースに対して発行するイメージです

上記の具体例において、直接(絶対パス)指定時と間接(相対パス)指定時にはデータの流れの観点からは次のようになっていると推測されます。

直接指定時

f:id:furyu-tei:20220118235155p:plain
直接指定時(プライバシーレベルを適切に設定した場合)

f:id:furyu-tei:20220119004035p:plain
クエリのオプション>現在のブックのプライバシーレベル

● 各ソースについて、プライバシー レベル設定に合わせてデータを結合します

プライバシーレベルが適切に設定されていれば、機密情報等を含んだデータを不用意に漏洩する危険はなくなります。
ただし、データをマージするためにはいったん全てのデータを取得しておく必要があるため、パフォーマンス的には低下してしまう傾向にあると推測されます(適宜バッファリングはされるようですが)。

間接指定時

f:id:furyu-tei:20220118235238p:plain
間接指定時(プライバシーレベルのチェックを無視しないと動作しないためこうならざるを得ない)(プライバシーレベルのチェックを無視するか全てパブリックにした場合)

f:id:furyu-tei:20220119004302p:plain
クエリのオプション>現在のブックのプライバシーレベル

● プライバシー レベルを無視すると、パフォーマンスが向上する場合があります

データソースのプライバシーレベルを設定することができないため、別のデータソースとマージするためには、プライバシーレベルのチェックを無視する(もしくは全てのプライバシーレベルをパブリックにする)しか有りません→追記:別の回避策もあるようです(後述)
そうすると、必要に応じて別のデータソースにデータが送られることになるため、機密情報等を含んだデータを扱う場合にはリスクが存在することになります。
DBから必要なデータのみ(例ではCSV上に存在する日付だけ)を取得するクエリが発行されることでパフォーマンス的には向上する傾向はあると推測されますが、情報漏洩のリスクとトレードオフの関係にあることに注意が必要です

間接指定時にもプライバシーレベルをうまく設定すれば大丈夫かも?(2021/01/19追記)

はけた@excelspeedupさんよりご指摘があり、

試してみると確かに、間接(相対パス)指定時でも例えば

f:id:furyu-tei:20220119101754p:plain
プライバシーレベルを適切に設定すれば間接(相対パス)指定でもうまくいく(ブックがあるフォルダを指定)

もしくは
f:id:furyu-tei:20220119082153p:plain
プライバシーレベルを適切に設定すれば間接(相対パス)指定でもうまくいく(ドライブ全体を指定)

のように、

  • 対象のワークブックのプライバシーレベルを「組織」に
  • 対象のワークブックが含まれているフォルダ/ドライブ全体(同じフォルダ下にデータソースであるCSVファイルも含まれる前提)のプライバシーレベルを「組織」に
  • 外部のデータベースのプライバシーレベルを「パブリック」に

であれば、プライバシーレベルのチェックを無視せずとも正常にテーブルがマージされました。

なおこの場合(ブックとCSVファイルを)移動やコピーしたり、他の人のところにコピーしたりすると、再度プライバシーレベルの設定が必要になることがあります。

その場合でも、クエリの更新時に出る

f:id:furyu-tei:20220119083509p:plain
プライバシーレベルの設定を促すダイアログ

のようなダイアログにおいて、移動先のフォルダ/ドライブのプライバシーレベルを「組織」に設定するだけですので、ルールをきちんと決めておけばコピー/移動する毎にデータソースを指定し直すよりも運用が楽かも知れません。

留意点

間接(相対パス)指定時にはそのデータソースのプライバシーレベルを「プライベート」にすることは実質的にできないため、少なくとも Microsoftサポートのプライバシー レベルの設定 (Power Query)の項目に書かれている

f:id:furyu-tei:20220119095940p:plain
データソースのプライバシーレベルを設定する
「プライベート」に該当するようなデータソースについては、(それ以外のセキュリティレベルのデータソースとマージ等をする可能性がある場合には)間接指定はしないようにするべきでしょう。

参考

エクセルでピザカッター!(画像を等しい角度で分割)

PowerPointで、丸い画像を強引に等分する方法というツイートをみかけて、ふと「エクセルでもできるんだろうか?」と思い、試してみたくなったしだいです。
残念ながらPowerPointのように手作業でも簡単にできる方法は思いつかなかったためVBAの力を借りておりますが……
動作イメージはこんな感じです*1



手っ取り早く試してみたい方へ

マクロ有効ワークシートを共有してありますので、ダウンロードしてお試し下さい。
drive.google.com
ソースコードだけ見たい方は、こちらに晒してあります

きっともっと簡便な方法もある気がするので、アドバイス歓迎です!

備忘録

はっきり言って役に立つのか何なのかという一発ネタな感じですが、作成過程で何回もはまりいくつか知見を得られましたので、おおよそはまった気づいた順に書き留めておきます。

画像はなべて96dpi

いくつかの画像をエクセルに挿入して試していたところ、元の画像のサイズ(ピクセル)通りに表示されるものと(図の書式設定でサイズをリセットしても)異なった大きさで表示されるものとがありました。
エクセルに画像を挿入する場合は元のラスタ画像ファイル(JPEG・PNG等)は解像度を96dpiで保存しておくのが良いようです。
画像を挿入した後、図の書式設定でサイズをリセット(高さ/幅の倍率を100%にする)することで元の画像と同じ大きさにできるので、その後の調整も楽になります*2

f:id:furyu-tei:20210530114458p:plain
エクセルに挿入する画像は解像度によって見え方が異なる
画像を図形でトリミングする方法

エクセルに挿入した画像は、これを選択しつつ「図の形式(Alt+JP)→トリミング(V)→図形に合わせてトリミング(S)」から図形を選ぶことで、選んだ図形でトリミングすることができます。
f:id:furyu-tei:20210530125901p:plain
また、先に図形を挿入しておいてこれを選択しつつ「図形の書式(Alt+JD)→図形の塗りつぶし(FS)→図(P)」から画像ファイルを指定して塗りつぶすことにより、図形の形に合わせて画像をトリミングすることもできます。
f:id:furyu-tei:20210530125917p:plain

手動でやる分にはどちらでも構いません。
前者の方が直感的で、いちいち画像ファイルを選択する必要もなく(一度画像ファイルを挿入しておけば後はコピペで済む)デフォルトの塗りつぶしや枠線に煩わされることもないのでおすすめでしょうか。

今回はVBAでやるためにコピー&ペーストを極力使いたくなかったので(クリップボード周りの機能は結構な頻度で失敗するため処理が煩雑になりがち・後述)後者の方法を用いています。
このため、指定したパスに実際に画像ファイルが存在する必要があります
【追記】
最初にシート間で一回だけコピー&ペーストしておけば後はShape.Duplicateで複製できることに気づいたので、マクロ有効ワークシートの方でも前者の方法に変更してあります。

#Const DuplicatePictureToMakePiece = True ' True: 元の画像を複製 / False: 1ピース毎に画像読み込み

のTrueをFalseに変更すれば、後者の方法にも戻せます。

トリミングの位置調整はむずかしい

任意の矩形を取るラスタ画像(円形に見える画像も実際のデータは通常は矩形)に対応させたかったので、矩形の外接円(半径が\frac{\sqrt{短辺^2+長辺^2}}2)を考えて、これを等しい角度の部分円でトリミングしていくことで分割する方法を取ることにしました。

とりあえず部分円のサイズを計算して調整した上で画像を挿入すると、直後は下記のようになります。
f:id:furyu-tei:20210530131933p:plain
どうやらデフォルトは図形にフィットするように画像がサイズ調整されるようですので、図の書式設定→画像の位置で幅・高さを元の画像と同じにしてやります。
f:id:furyu-tei:20210530132345p:plain
うまく切り取られているように見えます。お、これなら簡単にいくんじゃない……? と思っていた頃が自分にもありました。

同じ操作を180°よりも小さい角度の部分円でやってやると……
f:id:furyu-tei:20210530135033p:plain
こうなります……おや、画像の表示位置が……?(わかりやすいように期待している位置を半透明で重ねています)
どうやらトリミングのときには、デフォルト(トリミングの画像位置の横方向/縦方向に移動の値が0cm)では画像の中心を図形の見えている部分(部分円だと扇型の部分)を囲む矩形の中心に合わせるようになっているようです。
つまり、図形の見えている部分(扇型の部分)の表示範囲を計算して、それに合わせて画像位置の横方向/縦方向に移動の値を調整してやる必要があったのです……め、面倒くさい……。
なんでや……図形の大きさ自体は変わってないんやし、図形の中心でええやないか……せめてそっちの設定を選ばせてくれ
f:id:furyu-tei:20210530135428p:plain

部分円を囲む矩形の求め方(三角関数なんて忘れていたかった)

部分円(扇型)を囲む矩形か……とりあえず扇形の外周上の座標X・Yそれぞれの最大値と最小値を求めればよいのだろうけれど、円弧の部分はどうすれば……? ある角度範囲をとるときのsinとcosの最大値・最小値を求める必要がありそう?🤔 そんなの、数学が苦手な自分にできるわけないだろっ!😫
最初は力技で(角度を少しずつ変化させていって最大値・最小値を取得)やっていましたが、いき.xls[互換モード]@aero_iki さん助けを求めていろいろとアドバイスをいただきつつ、

なんとか解決にいたりました。

いき.xls[互換モード]さん、ありがとうございました!

図形のままだとシートの端には寄せられない

ここまでで、なんとか画像を分割できるようになりました。
このままでもよかったのですが、図形のままだと
f:id:furyu-tei:20210530143234p:plain:w350
のように、見た目には余白があるにも関わらず実際の図形はより大きい領域を占めているため、シートの端の方に寄せられない状態になります(図形や画像の座標はシートの左上が原点となっており、負の値は指定できません)。
図形のままで任意の矩形にトリミングできればよいのですが、たぶんできません(もし方法があれば教えて下さい)。

図形を画像に変換するときの問題点

そこで、図形を画像に変換してから矩形でトリミングすることを考えたのですが。
図形を選択してコピー→図 (PNG) として貼り付けると……
f:id:furyu-tei:20210530144020p:plain
のように、見えている部分だけが残る形で画像化されてしまいます。
え、待って……これってまた面倒な座標計算をしないといけない予感?🤔

そろそろ疲れていたので💦「見えている部分だけが残るのなら……残したい部分を見えるようにすればいいじゃない!」という発想のもと、図形の正方形/長方形を基準となる外接円と同じ高さ&幅にして挿入、部分円に重ね合わせてグループ化したものをコピー→図(PNG)として貼り付ける手段を取りました。
f:id:furyu-tei:20210530145329p:plain
実際の処理では矩形は透明にしていますが、矩形の場合はその状態でコピペしても元と同じ大きさとなりました

あとは、元の画像の矩形とそれぞれの部分円が重なる領域が収まる矩形領域で(実際には先の部分円の円弧座標の最大・最小を求める処理と同じ処理で、元画像の矩形と円弧の重なり部分の座標の最大・最小もいっしょに計算しています)画像を切り取れば(ShapeのPictureFormatでCrop◯◯を設定)完成です。
f:id:furyu-tei:20210530152824p:plain
まぁ画像に変換してしまうと今度は透明部分もクリックできてしまうので、これはこれで操作しづらいのですが💦

追記:トリミングしても元画像のデータは残る

「完成です」と書いておいてあれですが💦ひとつ忘れていました。
画像をトリミング(ShapeのPictureFormatでCrop○○を設定)した場合ですが、この状態で画像を選択して「図の形式(Alt+JP)→トリミング(V)→トリミング(C)」してみるとわかるように、
f:id:furyu-tei:20210531212058p:plain
切り取られた部分(灰色になっている箇所)もデータとしては残ってしまっています。

手動でなら「図の形式(Alt+JP)→図の圧縮(M)」を選択することで
f:id:furyu-tei:20210531212304p:plain
のようなダイアログが表示され、「☑ 図のトリミング部分を削除する(D)」という便利な機能も使えるのですが、残念ながらVBAからはうまく使えません。
一応「Application.CommandBars.ExecuteMso "PicturesCompress"」を実行すればダイアログが呼び出せるので、SendKeysと組み合わせることで圧縮できなくもないのですが、オプションの選択がやりにくかったりときどき失敗する等、使い勝手がよくありません

どうしようかと思ったのですが、図形を画像に変換するときの問題点ではやっかいだった「コピー→図 (PNG) として貼り付け」をもう一回行えば、見えている部分だけが残る形で画像化されるんだからこれでいいじゃない! ということに気が付きました。
実際に試してみると……
f:id:furyu-tei:20210531213302p:plain
「コピー→図 (PNG) として貼り付け」した画像(右側)はトリミングで見ても余分な箇所は残っていません。
これで無事、みかけだけではなくてちゃんとトリミングされた画像にすることができました。

VBAでクリップボードが絡む処理は鬼門

図形を画像に変換する際には、Shapeの.Copy&Worksheetの.PasteSpecialを実行しているのですが、これをそのまま行うと高確率で.Copyもしくは.PasteSpecialのいずれかでエラーが発生してしまいます。
場合によってはエラーが発生していないのにも関わらず、画像が正常に貼付けされないケースもあります。

これはコピー→ペーストの過程で行われているクリップボードの操作で発生する問題のようです。

踊るエクセル@ExcelVBAerさんのアドバイス


に参考にクリップボード関係のWinAPIを使い、クリップボードのクリア→コピー→データがクリップボードに入ったことを確認→ペースト…という手順(エラーが発生した場合はリトライ)にしてみました。
踊るエクセルさん、ありがとうございました!
追記:記事作成後のアドバイスも追加しています

ただ、いかにも冗長な処理だし、これが適切な処理なのかも自信がないしで(クリップボード関係のWinAPIをよくわかっていない)もやもやします。よりよいやり方があれば教えて下さい。
標準のメソッドを使っているのにクリップボード関係の処理は高頻度に失敗するというのがそもそも納得いかないというのもありますが

Twitter で「work」ドメインの記事を引用するとツイートが表示されなくなってしまう件

このブログは「memo.furyutei.work」のように、gTLDとして「.work」を使用しているわけですが。
Twitter にて「.work」ドメインの記事(URL)を引用してしまうと、状況によってはそのツイートが表示されないといった不具合が発生してしまう、というお話です(2021/02/11現在)。




不具合の内容

元ツイートが「.work」ドメインの記事を含む場合

「.work」ドメインの記事を引用してツイートした場合、そのツイートにリプライが付くと、元ツイートを開いたらリプライツイートも表示されます。
ここまではいいのですが、実は、

  • リプライツイート(およびリプライツリーで繋がったツイート)を開くと、(自分以外のユーザーからは)元のツイート(リプライ先・「.work」ドメインの記事を引用したもの)は見えず、「このツイートは表示できません。This Tweet is unavailable. )」状態となってしまう

という不具合が発生します。
これ、自分で見る分には普通に表示されるため、誰かに指摘されたりしないと気が付かない罠

リプライツイートが「.work」ドメインの記事を含む場合

また、Twitter のツイートに対するリプライ中に「.work」ドメインの記事(URL)を引用してしまうと、

  • 元ツイートのユーザーには通知が行かない
  • (自分以外のユーザーが)元ツイートを表示しても、「.work」ドメインの記事を引用したリプライツイートは見えず、リプライ数としてもカウントされない
    この場合も、自分で見る分には普通に表示されているので気が付きにくい
  • 当該リプライツイートにさらにリプライが付いた場合、当該ツイートは「このツイートは表示できません。This Tweet is unavailable. )」状態となってしまう
    もちろん自分では普通に見える

という不具合が発生してしまいます。
なお、 (自分以外のユーザーであっても)当該リプライツイートを直接URLを指定して開けば見ることはできます。

自分のところだけではないらしい

最初、自分のところだけかと思いましたが、gTLD「.work」を使っているサイトを3か所ほど探して試してみたところ、いずれも同様の不具合が発生していたので、少なくとも「.work」に関しては普遍的に発生するのではないかと予想しています。
他の TLD で同様の不具合が発生するかどうかまでは調べられていません。
「.work」は新gTLDと呼ばれる比較的歴史の浅いものらしいですが、そういうのが関係していたりするのですかね?

回避方法

現状、「.work」ドメインの URL は引用しないようにするしか……。
このブログの場合、もともとはてなブログなので「furyu.hatenablog.com」の方の URL を使って引用する、という手はないではないです(面倒くさいけれど……)。

Twitter さんに不具合報告はしているのだけれど


2020/12/03・12/09、2021/02/09 と、これまで都合3回この不具合に関して報告しているのだけれど、なしのつぶて……(2021/02/11現在)。

追記


やっぱりTwitterさんにスパム判定されているってことですかねぇ。
安さで判断したのが悪いって? さすがにこういう「安かろう悪かろう」は納得いかないのですが……。

Web版TwitterからFleet画像/動画をダウンロードできるユーザースクリプト

スマホ用Twitterアプリに「Fleet(フリート)」がリリースされて早三ヶ月が経とうとしていますが、未だに使い道がよくわからない風柳です、ごきげんよう。

Web版TwitterではなかなかFleetが見られるようにならないので、こっそり(?)ダウンロードツールを作って公開していたのですが、現在もまだ見られないようなので、記事でも紹介しておきます。
スマホアプリ版みたいにリアルタイムで誰が投稿しているか表示されるわけでもなく、画像/動画を別タブで開いた際も誰が投稿したものかもわかりづらいので、使い勝手としてはイマイチですが……😅

インストール方法

ユーザースクリプトとして公開しています。
[このページを参考に](https://greasyfork.org/ja)、お使いのブラウザに Tampermonkey 等のユーザースクリプトマネージャーをインストールした状態で、
greasyfork.org
のページを開いて[スクリプトをインストール]ボタンを押し、フリートキャプチャーをインストールしてください。

使い方

フォローしている方のFleet画像/動画のダウンロード方法

[Twitterのホームタイムライン](https://twitter.com/home)を開くと、上部に[Fleets 💾]のようなボタンが表示されます。

f:id:furyu-tei:20210206123026p:plain
HOME画面上のボタン

これをクリックすると、フォローしている方が公開中のFleet画像/動画をまとめて(ZIPファイルで)ダウンロードできます。
また、[Alt]+クリックで、画像/動画を別タブでまとめて開くこともできます。
ブラウザのポップアップブロックにより別タブでうまく開けない場合は、ポップアップブロックをオフにするか、あきらめてください。

ユーザーが公開中のFleet画像/動画のダウンロード方法

ユーザーのプロフィールタイムラインを開くと、その方がFleetを公開中であれば、プロフィールアイコンの周りが水色になり、同時に[Fleets 💾]のようなボタンが表示されます。

f:id:furyu-tei:20210206123913p:plain
プロフィール上のボタン

これをクリックすると、その方が公開中のFleet画像/動画をまとめて(ZIPファイルで)ダウンロードできます。

f:id:furyu-tei:20210206123802p:plain
Zipファイルサンプル

こちらも、[Alt]+クリックで、画像/動画を別タブでまとめて開くこともできます。
注意書きも同上です。

おまけ

Fleet用自作テンプレートです。ご自由にお使いください。

f:id:furyu-tei:20210206124108p:plain
フリート用テンプレート.伝言板

【お知らせ】アマゾン注文履歴フィルタが突然使えなくなるかもしれません!!

多くの方にご利用いただいている拙作「アマゾン注文履歴フィルタ」

memo.furyutei.work

ですが、Amazon.co.jp 様側のページ仕様の変更に伴い、残念ながら今後使えなくなる可能性が高いです。

現状、本拡張機能(アドオン)は、領収書ページのHTMLを用いて一括印刷やCSVダウンロード等の機能を実現しているのですが、領収書ページのフォーマットがHTMLからPDFに変わってしまったアカウントが存在するようです(2020/12下旬に確認)。今後はこの切り替えが実施されるユーザーの方が増えていくものと予想されます。

こうなると抜本的な改修が必要となってくるのですが、現状当方の所持するアカウントではまだ切り替えが行われておらず、また時間的な余裕もないことから、短期間での対応は困難です。
少なくとも、2020年分の確定申告の期間には本拡張機能は使用できないという前提で、各位対処されることをお勧めいたします。
大変ご不便をおかけしますが、ご容赦願います。