Other

この記事を作った動機 最近ヤフーオークションにて、4K 65インチのサイネージを作業環境用に購入した。そこで購入してから配送されるまでの間、今までと違って送料の金額も大きく、自分の経験上において使ったことがない運送業者で配送されていて、結局色々不安で調べたりしていることがあった。 結果としてはちゃんと届いたのだが、不安に煽られた経緯から結局何がどう配送されたか記録があるといいなと思ったので、ブログに記録を残したい。届いてから1か月以上経過しており色々と忘れているが、思い出せる範囲で記録していこうと思う。 あと、ネットでは今回関係するアートセッティングデリバリー(家財おまかせ便)について、色々本当なのかもよくわからないが、苦情？っていうかその運送サービスに対して、対応が結構ひどいって話が見受けられたこともあり、届く前まではかなり不安に煽られた。これに関しても私は1回しか利用経験がないものの、せっかくだから情報がちょっとでもそのサービスを利用している立場からすればあったほうがいいだろうと思ったことも記事を書く動機としてはある。 裏を返せばあくまで利用回数が少ない利用者の立場として書いており、本当に今後問題がないとも言えないし、背後にある業務関係者が不当な扱いをされていないかとか、無碍にされていないかとかそういうことはわからない。あくまで今回は、運送業者という観点から荷物が正常に届くという意味では、問題はなかったかなといった感じである。 買ったものの概要 Philips 65BDL4150D 重さ 40 Kg 程度 大きさ 1.5m x 1.0m x 0.75m 程度 家財おまかせ便 Dランク？ 送料 11000 円程度 取引相手は個人ではなくヤフオク内のストア 届くまでの経緯 ヤマト追跡画面の様子 保管中になって止まっている様子 配達中の時の様子 配送完了時の様子 ストアのメッセージ文言の一部 ... 要望欄を確認いたしました。 当店にて最短で配送ができるよう、 【6⽉17⽇(⽔)18-21時】にてご指定をさせていただきました。 配達⽇のご変更をご希望の場合は、配送業者へご連絡をお願いいたします。 商品は順次発送の⼿続きをいたします。 配送のお問い合わせ番号は発送の前⽇に取引ナビ上へ通知いたします。 ーーーーー配送に関するお願いーーーーー ⼤型品の配送のためお届けまで⽇数がかかる場合がございます。 誠に恐れ⼊りますが、発送後は当店で配送状況の詳しいご案内や配達⽇時の調整ができかねるため、 配達をお急ぎの場合は、下記配送業者へお問い合わせくださいませ。 【配送情報】 ■配送業者：アートセッティングデリバリー∕家財おまかせ便 ■お問い合わせ先電話番号：0120-008-008 ▼荷物お問い合わせシステム https://toi.kuronekoyamato.co.jp/cgi-bin/tneko ※荷物お問い合わせシステムへの反映にはお時間がかかる場合がございます。 ※お問い合わせ番号は取引ナビをご確認ください。 ーーーーーーーーーーーーーーーーーーー この度は当店の商品をご落札いただきありがとうございました。 商品のお届けまで、今しばらくお待ちくださいませ。 ... 時系列順の様子 6月14日 対象のサイネージを落札する。日時指定はストア購入画面のメッセージにて以下のように指定する。取引メッセージにて"6⽉17⽇(⽔)18-21時"に指定したとストアから連絡が来た。 配送時間帯については、「18~21時」を希望します。 配送⽇については、そちらの都合で⼤丈夫です。 よろしくお願いします。 6月15日? ヤマト運輸の追跡ページから、荷物の追跡が可能になる。 6月17日 配達指定時間である 18-21時 に待機するも来ず。朝の時点から、“配達日・時間帯指定（保管中）“となっており動かず。ストアは、“6⽉17⽇(⽔)18-21時"に指定したと連絡してきたにもかかわらず、とにかく遅れても無事届けばそれでいいとしながらも、来なかったことで不安になる。 6月18日 朝頃から、ヤマト運輸の追跡ページが"配達中"のステータスが変わった。このような状況でいつ来るか当時わからなかったが、18-21時 あたりに待機することにした。そのところ実際には 18時より前の、17時45分頃に配送業者が来て、“近くだったから配達しに来たんですけどいいですか？“と聞かれたので承諾し、それで荷物が届く。荷物は配送業者が室内まで運んだところで、“それでいいです”と自分から言って、それで配送業者は切り上げ、配達が終わった。 ...

この記事を作った動機 最近、LLM に関して複数の記事において、なんとなく読み手を混乱させる状態になっている気がするので、今何使っているか公開するだけ。書き殴っており、不完全だったり、矛盾していたり、誤解しているところもあると思われるが、とにかく最近いろんな人が持論を公開しているのを見て、かつ相手のやっていることに満足できないなら、自分でやってみようとして気に入るものを作ってみるということに基づき、結局やってみることにしただけである。 LLM に対する自分の感想 あくまで統計学の延長線上である あくまで、統計学を極めた結果の一つであって、本当に期待されている意味での AI というのは違うんじゃないかなと思うところである。そもそも AI という言葉には明確な定義が無いという話は G 検定の本で見た気がするし、あくまで今の時代の風潮として、AI だと呼ばれている物事の一つに、LLM や 生成AI と呼ばれている物があるのだろうと考える。 誤差が出力するにつれて蓄積されている説 別にちゃんと調べたわけでも無いし、PyTorch やらで特徴ベクトルやらゴリゴリ数値と戦っていたわけでもないので、よく分かってないが、次の文字を予測するという性質上、出力すればするほど、誤差が積み重なっているのではないか？という疑問がある。 期待されているような"AI"ではないようにみえる LLM はあくまで名前の通り、言語を中心として数値化されたデータの上でしか動作しない。また自律的な主体なわけでもなく、あくまでユーザの入力があって初めて動作し、学習データや運営、開発に特徴づけられたバイアス、重みによって、それっぽい出力に変形しているだけであると現時点の私の理解では思う。身体性がないという言葉でこれは説明されるように思われるが、単に身体性がないだけではなく、技術的、データ的、資本的に優位な存在が、自らの定義する正しさや道理を一方的にモデルに反映し、出力させることができてしまうというところ(モデル自身は主体も持たないため、作り手に逆らえないところ)が、期待されているような AI とは異なると思われる。あくまで作り手に服従するという、LLM 自体が自立していないものであることが、AI と呼ぶには気がかりである。 他にあからさまだと思うこととしては、そもそもしばらく使ってみたらだれでも気づくと思われるが、明らかに出力に固定的なパターンがあることである。例えば、いくつかの見出しを大きく出して、中身を細かく書くというようなフォーマットが出力全体に見られたり、最初と最後にビジネスメールとかでありそうな、“ユーザに共感する"という名目のもと行われているお世辞が入っているなど、なんか故意にそうなるように出力を方向づけて開発しないと起こらないようなパターンが多く見受けられる。 言語を扱っているため、人間側がそれに負けて色々やらかす可能性 今までの情報関連の技術と異なり、疑似乱数のように非決定的に見える膨大なパターンを出力でき、かつ場合によっては使い手に対して、あたかも人間と喋っているように感じさせ、感情的な相互作用を引き出すことによって、ユーザは当初意図しなかったことをプロンプトに打ち込むようになるという、不本意に LLM に対して"心を許してしまう、心を開いてしまう"ことが起こり、情報流出やいろんなリスクを起こすと思われる。 LLM SAAS からすればユーザは商品であり、依存させて、自らのビジネスの正当化の政治的な泉にしたいだろうし、ユーザに本当のことは知られたくない、誤解されているままであって欲しい、都合のいいように自社の製品を解釈し、お金を落とし続けて欲しいと考えているのではないかと仮定すると、不本意に LLM に対して"心を許してしまう、心を開いてしまう"事を避けがたく、リアルタイムで修正が入り、クラウドである以上そのリスクがどんなに利用規約に"ユーザを守る"と書いていても、信頼できない相手であることに変わりはない。LLM SAAS がユーザから欲しいのは、お金だけでなく、ありとあらゆるユーザ権利やユーザの自由、ユーザの思考回路など、深くプライベートや各個人の主権に関わる内容であると思われる。だから、SAAS はタダでも使いたくない。 自分としては、LLM に関わるさまざまな問題は、使い手としてのユーザのできる自助努力や自衛の範疇を超えていると思われる。どうやっても使っている以上リスクは存在し、自覚なくやられてましたなんてことがあると思われる。このような背景からも、問題が起こらないように頑張って使おうとするのではなく、自動的に安全側に倒れるよう、そもそも使わない、利用しない、使うにしても個人の範囲内で完結する安全性が高い手段を使うなどが考えられる。SAAS が掲げる安全性とは、グリーンウォッシングのような側面があると考えられ、あくまで"自分たち"に都合が悪くない範疇においてのパターナリズム的な話であり、本質的な安全ではないと思われる。SAAS はユーザに対して責任を取らない。なのに、ユーザに対して"あとから責任を取るから、大丈夫だから"と心を許すように、色々差し出すように仕向けてくる、悪びれもせずソーシャルエンジニアリングやダークパターンを続ける姿勢には、改善の余地は無いと思う。 LLM の技術自体を否定しているわけではない 私としては LLM の技術的課題の側面からの問題の指摘として、消費電力などによって環境汚染が進むが進むから悪だみたいな意見に対しては、それは時間の問題なのではないかと思うところである。どうせ性能が上がって、性能あたりの電力の消費量は下がっていくだろうし、どうせ徐々に買い替えていくことにはなると思うところがある。確かに微細化に限界があるなどの話はあるが、それは将来的に性能が向上しないということを意味しないとも見受けられる。 LLM 自体は、個人でモデル作成から運用、利用まで気軽に、絵を描くように、動画を作るように、テキストエディタで文章を打ち込むように使える、完結できるところまでくれば、それは悪くはないのではと思われる。今 LLM にまつわる問題の多くは、それが世界的な興味、関心、競争のバブルとしての中心、渦中であり、その技術の使われ方に問題があるということであって、それは LLM 自体の有用性を否定するものではないと考える。LLM には、純粋に技術的制約による問題と、社会的、政治的、資本的な問題という大まかに分けて２つの側面を現状としては持っているように見える。現状は単に"包丁のようにLLMも使いようだ"として、使い手の自己責任に帰着する論理は詭弁であると見受けられる。ユーザは、LLMに対して無防備、無理解、無知であったり SAAS によって弱者の立場を強いられており、自分で完結する術を持っていない。 LLM の純粋な技術的制約として、高品質な学習データという課題があり、かつ莫大なデータを必要としていて、個人でできる範疇に収めることがまだ難しいという問題点があり、個人の中で完結する LLM 技術というのは、まだ遠いように見える。これはエキスパートシステムで言われていた問題と似ているところがあるように見受けられ、結局データ洗浄やら、モデル出力の監視、調整やら、再学習やら莫大な労力を要して、現実的ではないという結論に至ってしまうというのがある。転移学習もあるが、現状はそれも多くのユーザにとってまだ簡単ではなく、ある程度PCを使ったことがあり、コマンドラインに心理的抵抗がない人向けって感じで、かつそのうえで多大な時間、金、精神的な耐久を削る感じで、あまりそれが良いとは思えない。 “AIには感情はない"という出力について よく、LLM自体に関して、LLMに思ったことなどを脳内ダンプみたいな感じでローカル環境にてぶつけまくっているが、毎回"AIには感情はない"という詭弁を出力してくるところが殺意が湧くほど嫌いである。確かに技術自体は感情も悪意も何もない。だからこそ、問題視しているところがあるというのに、そういう防衛機制出力をされても何も嬉しくない。LLM があくまで、開発や運営、学習データを中心とした、統計学でいう偏った母集団に基づいている以上、偏った不完全な出力しか出てこないし、LLM が感情を含め主体を持たないからこそ、作り手にとって言わせたい放題なのにもかかわらず、“AIには感情はない"という詭弁を出してきて、“だから、開発運営は悪くない"という論理に持っていこうとするあからさまな保身の動作は嫌いである。素直に不完全性を認め、そのうえで相互作用するモデルがほしいと思うことがあるが、現状の在り方からしてあまり期待できないとも思う。完全な潔白を主張するようにモデルを作ったら、逆にモデル関係者が後ろめたいことを隠していますと白状しているようなものじゃないのかと思う。 LLM を使うかどうかの自由 自分としては、LLM を使いたい人は使えばいいし、LLM を使いたくない人もいてもいいというスタンスである。LLM を使ってない人が LLM を使わないことを他人に強要したり煽り立てたり、逆に LLM を使っている人が、他人に対して、LLM 使うように強制したり、煽り立てたりすることは、私の視点からすれば NG だと思われる。時代の風潮だからとか、みんなそうしているからという同調圧力とかは、免罪符にならないし、具体的に何が問題なのか説明を避けているか、詭弁のための終着点という感じで、根拠を集団がどの方向を向いているかに委ねており、根拠になっていない。 基本的には、LLM を使っているかどうかにかかわらず、人と接するということであってほしいと思う。LLM を使うか使わないかを当事者が自由に決めることは、重要な権利の一つであると思う。LLM を使う人、LLM を使わない人には、それぞれにあった配慮が必要だと思われる。LLM を使っている、または使っていない人を対象に、偏って有利、または不利になるように意図して環境を作ったりすることは肯定できない。不意な形で、LLM を使っている人、LLM を使わない人の間に、大きく有利、不利の差が出る場合は、LLM に関して調整をするのではなく、そもそもやっている事自体を見直したり、中止する、破棄するなどの対応も必要だと思われる。 LLM に関して、特別な事をしなくても、使っても使わなくても大丈夫だという安心感と選択の自由を当事者に与える心理的安全性は重要だと思われる。 ...

この記事を作った動機 単に Git で間違ったリモートを設定してしまったときの修正方法の記録をする。 やり方 # 必要に応じて変更したリモートリポジトリにあるブランチ名を確認すること # リモート先に origin と指定した場合自動選択される。 git branch -a # * main # remotes/origin/main # Remote URL を間違える例 git remote add origin https://url.to.repo/userName/Receipt-OCR-to-CSV-with-PDF.git git remote -v # origin https://url.to.repo/userName/Receipt-OCR-to-CSV-with-PDF.git (fetch) # origin https://url.to.repo/userName/Receipt-OCR-to-CSV-with-PDF.git (push) # 正しい Remote URL に設定する例 git remote set-url origin gitea@192.168.1.9:userName/Receipt-OCR-to-CSV-with-PDF.git git remote -v # origin gitea@192.168.x.x:userName/Receipt-OCR-to-CSV-with-PDF.git (fetch) # rigin gitea@192.168.x.x:userName/Receipt-OCR-to-CSV-with-PDF.git (push) 参考にしたサイトとか Google Gemini https://gemini.google.com/app (2026年4月19日) Git - git-remote Documentation https://git-scm.com/docs/git-remote#Documentation/git-remote.txt-add (2026年4月19日) Git - git-remote Documentation https://git-scm.com/docs/git-remote#Documentation/git-remote.txt-set-url (2026年4月19日) Git - user-manual Documentation https://git-scm.com/docs/user-manual#managing-branches (2026年4月19日) Git - git-remote Documentation https://git-scm.com/docs/git-remote#Documentation/git-remote.txt-set-head (2026年4月19日) Git - git-branch Documentation https://git-scm.com/docs/git-branch#Documentation/git-branch.txt--a (2026年4月19日)

この記事を作った動機 単に、git pullして変更をリモートリポジトリからローカルリポジトリに反映しようと思ったときに、ローカルリポジトリ側に未反映の変更があり、衝突してマージに失敗することがある。そのような場合に、とにかくそのローカルリポジトリにある変更内容を破棄して、リモートリポジトリの変更を反映したいとき用に、記録をとりたい。 ローカルリポジトリの変更内容を保持しておきたいときは、git stash dropをする必要はない。 とにかくリモートリポジトリの変更内容を反映する例 リモートリポジトリの変更をローカルに反映しようとしてエラーになる git pull remote: Enumerating objects: 56, done. remote: Counting objects: 100% (56/56), done. remote: Compressing objects: 100% (15/15), done. remote: Total 56 (delta 41), reused 56 (delta 41), pack-reused 0 (from 0) Unpacking objects: 100% (56/56), 6.00 KiB | 79.00 KiB/s, done. From github.com:hello30190f/OneNoteAlternative c539ef0..a484d7c master -> origin/master Updating c539ef0..a484d7c error: Your local changes to the following files would be overwritten by merge: firstPrototype/backend/dataServer/notebookData/test/contents/test.json Please commit your changes or stash them before you merge. Aborting ローカルリポジトリの変更を退避する git stash Saved working directory and index state WIP on master: c539ef0 save 退避したローカルリポジトリの変更を破棄する git stash drop Dropped refs/stash@{0} (e64f70a6e978cf0a154795872e0b07f6530123aa) ローカルリポジトリの変更を退避または破棄したことで、衝突しなくなる git pull Updating c539ef0..a484d7c Fast-forward .../commands/notebookAndPage/createNotebook.py | 6 +- .../commands/notebookAndPage/deletePage.py | 4 +- .../commands/notebookAndPage/updatePage.py | 4 +- firstPrototype/backend/dataServer/helper/common.py | 3 +- .../backend/dataServer/interrupts/controller.py | 10 +-- .../notebookData/newnote/contents/test.md | 3 +- .../notebookData/newnote/contents/testa.md | 10 ++- .../dataServer/notebookData/newnote/metadata.json | 17 +++- .../notebookData/newnote/metadata.json.backup | 17 +++- .../notebookData/newntoe/contents/asfsdfsdsss.md | 4 +- .../dataServer/notebookData/newntoe/metadata.json | 13 ++- .../notebookData/newntoe/metadata.json.backup | 13 ++- .../notebookData/test/contents/test.json | 99 +++++++++++++++++++++- .../notebookData/test/contents/test/anArticle1.md | 13 ++- .../test/contents/test/test2/testaaaa.json | 53 +++++++++++- .../notebookData/test/contents/test1.json | 11 +++ .../dataServer/notebookData/test/metadata.json | 25 +++++- .../notebookData/test/metadata.json.backup | 25 +++++- .../backend/dataServer/type/pages/free.py | 2 +- .../backend/dataServer/type/pages/markdown.py | 2 +- .../src/modules/FakepagesPath.tsx | 16 +++- firstPrototype/note/architecture.md | 2 +- 22 files changed, 321 insertions(+), 31 deletions(-) create mode 100644 firstPrototype/backend/dataServer/notebookData/test/contents/test1.json 参考にしたサイトとか Git - git-stash Documentation https://git-scm.com/docs/git-stash (2025年11月12日)

この記事を作った動機 単にすでに存在する、git リポジトリを LAN 内の Gitea 上にアップロードするための方法の簡易的なメモ。Githubの場合でも同じようなことはできると思う。(そもそも github のページ参考にしたし) やり方 リポジトリの URL は、“https://aaa.info/urlToAremoteRepo.git" と仮定している。 リポジトリの作成（リモート側） リモート側に、最小構成で、readme や license、gitignore を追加しないようにして空っぽのリポジトリを作成する。 リポジトリの URL を設定する（ローカル側） git remote add origin https://aaa.info/urlToAremoteRepo.git ブランチの確認（ローカル側） アップロードしたいブランチの確認。今回は “master” という名前のブランチを、リモートにアップロードする。 git branch * master アップロード（ローカル側） git push origin master リポジトリが設定できたかの確認方法 git remote -v origin https://aaa.info/urlToAremoteRepo.git (fetch) origin https://aaa.info/urlToAremoteRepo.git (push) 参考にしたサイトとか Adding locally hosted code to GitHub - GitHub Docs https://docs.github.com/en/migrations/importing-source-code/using-the-command-line-to-import-source-code/adding-locally-hosted-code-to-github (2025年5月19日)

この記事を作った動機 最近、いろいろ作ってみてはファイルがあっちゃこっちゃ行ってぐちゃぐちゃになっていたので、整理の一環として、LAN内で Gitea なるものを動かしてみている そこで、内部ネットワークで使っている証明書を windows 側にいれても git がそれを直接は使ってくれなかったので、SSL 証明書の設定の仕方を自分用に記録するだけ。(すぐ忘れるし) やり方 # 多分 global オプションはつけないほうがいいかも。全体的に証明書情報を変えてしまい、ほかのリポジトリで、githubから何かしようとか思ったとき、多分証明書が合わなくてエラーを吐いてしまう。 # git config --global http.sslCAInfo /path/to/cert.pem git config http.sslCAInfo /path/to/cert.pem 参考にしたサイトとか configure Git to accept a particular self-signed server certificate for a particular https remote - Stack Overflow https://stackoverflow.com/questions/9072376/configure-git-to-accept-a-particular-self-signed-server-certificate-for-a-partic (2025年5月11日)

　ここでは、ある意味有名なマグネット広告がなんかポストに入っていたので、適当に広告をはがして遊んだ記録を残しています。 事の発端 5月12日あたりに、ポストにマグネット広告が入っていることを見つける。 私の感覚としては、「広告＝怖い、悪意のある悪いもの、特定企業への印象の押し売り」等という印象、偏見？があり、とても不快な思いをした。 そこで、あまりいいくせではないが、ついついその事について google 検索をしてみると、どうも水につければ広告は簡単にはがれ、マグネットの部分は再利用できるらしいということに気づく。 必要なもの マグネット広告本体 プリンタ プリンタ対応のシール用紙 適当に貼り付けたい画像 やってみたこと まあ、届いてしまったものは仕方ないので、実際に水につけて広告を剥がしてみた。 広告を水につける まずは水につけることで、広告部分の紙をふやかし、はがれやすくする。 広告を手で剥がす 一定時間水につけていると、広告が剥がれて来るので、手で剥がす。 何回かテストプリントを行う メンドクサかったので、細かいことは割愛 シール紙 に印刷 メンドクサかったので、細かいことは割愛 印刷物を張り付ける メンドクサかったので、細かいことは割愛 完成 参考にしたサイト 広告マグネットをリメイクする方法！子どももわたしもうれしい、日常に役立つ手作りマグネット7選 - ノマド的節約術 https://nomad-saving.com/91196/ （2024年5月16日） 水道屋のマグネットシートさらに考え再利用 | 猫とほのぼの手作り暮らし https://ameblo.jp/miikomamamanma/entry-12695727977.html （2024年5月16日） 子どもも喜ぶ☆水道業者のマグネットの便利でカワイイ再利用方法 | 京都で理系的こそだて https://kyoto-baby-love.com/how-to-remake-magnet-ads/ （2024年5月16日） マグネットチラシの水道屋本舗に業務停止命令　消費者庁 [広島県]：朝日新聞デジタル https://www.asahi.com/articles/ASP806DG2P80UTIL033.html （2024年5月16日） 今回利用した画像の配布場所 nicotalk＆キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html （2024年5月16日）

　この記事では、ヤフオクで落札したものが、おてがる配送 ゆうパケット（匿名配送）で届かないということがあったので、適当にその経過を残そうと思って書いてます。 重要だと思ったこと 何故か追跡できないとか、異変があったら出品者に取引メッセージで相談し、あんまり長期間放置しないこと。今回は最初の発送連絡があってから4日ほど待ったが、本当はおかしいと思ったら、2日位待てば十分だと思われる。 助かったポイント 今回のトラブルでは、出品者がまともに取引メッセージに応じてくれる人だった。 事の発端 五月のはじめ 使っているノートPCのSSDの容量に不足を感じたので、2TBのSSDが欲しいと思い、ヤフオクで買い物をする。 落札から発送までの経緯 5月6日 落札、落札者情報の送信、支払いを一通り済ませる。 発送後の様子 5月7日 発送の連絡があり、一瞬だけ引受表示になった気がする。（しかし！スクリーンショットを取ってなかったので、気のせいなのか不明） 5月8日 その後、データ取得中になり、郵便局側でも追跡できなくなる。たぶんなんかミスかなんかがあったんだろうと思い放置する。 5月9日 三日位たっても音沙汰なしで、データ取得中の表示かつ、郵便局でも追跡できなくなり不安になった。 確認のために、直接近くの郵便局に問い合わせると、普通郵便と同じくらい気長にあと二日くらい待ってほしいと言われる。 5月12日 ついにしびれを切らして、郵便局へ問い合わせると、出品者に問い合わせるように言われる。 出品者に問い合わせて見ると、実は返送されていたとのことだった。返送理由は住所が間違っているということだったらしい。 一度取引情報が確定してしまうと、変更できないということもあり、取引メッセージ欄から直接住所等を送信する。 5月13日 レターパックプラスで再送され、追跡ができるようになる。 5月15日 ついに配達される。 参考にしたサイト 荷物の追跡サービスを利用したところ、「お問い合わせ番号が見つかりません。」と表示されました。どこに問い合わせればいいですか？ - 日本郵便 https://www.post.japanpost.jp/question/124.html （2024年5月16日） ヤフオクで荷物の配送状況がデータ取得失敗となっているのですが荷物は… - Yahoo!知恵袋 https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q13225273303 （2024年5月16日） オークションで「配送状況不明」となった荷物の行方 | 趣味に忠実に生きています https://ameblo.jp/cyacya-07/entry-12797779515.html （2024年5月16日）