Make組ブログ

Python、Webアプリや製品・サービス開発についてhirokikyが書きます。

イラストのAI学習禁止はできるのかをAIエンジニアが短く話します

AI プロダクト開発

こんにちは。 mimic（ミミック）というサービスがリリースされ、インターネットを騒がせています。 このサービスはアップロードされたイラストを学習して、類似されたイラストを生成できるというものです。

illustmimic.com

誰がこの文章を書いているか

ShodoというAI文章校正サービスを作って運営しているものです。@hirokikyといいます。 Shodoは皆さんがメールや記事を書くときに、変な日本語になっていないかや、二重敬語を使っていないかなどをチェックしてくれるサービスです。

この記事はざっくりAIエンジニアが書いていると思ってください。 「AIと著作権」というかなりセンシティブな問題について当事者でもありますので、今回の件をサービスの設計などを含めてざっくり話します。

私自身も勉強中の身ですので、ぜひ文章に改善点があれば教えてくれると嬉しいです。 そして実際に困ったことがあったときは、著作権に詳しい弁護士の方に相談してください

で、AI学習禁止はできるのか？

さっさと結論を言うと、あなたのイラストを「AI学習禁止」と確約することはできません。規約で明示することはできますが、ケースごとの判断となります。

そもそも今回の話ですが「自分の著作物を勝手にアップロードして利益を得るな」という意味ですでに悪意のあるユーザー（なりすましたい人など）は著作権法違反となり得ます。しかし非公開かつ私的利用の範囲では、単にアップロードだけされても著作権違反と言うのは難しいかもしれません（指摘があったので1文を追記しました）。

またあなたのイラストによく似た画像を作って不当に利益を得るのは著作権法違反になり得ます（これは議論が分かれるところで、詳細は下のリンクの「第4の1．そもそも著作権侵害に該当するのか」を読んでください）。「AI学習禁止」という文言を急いで追加しなきゃ！というわけでなく、今までの「無断転載・無断利用・アップロード禁止」という説明で十分と思われます。ただ将来、AIの発達に伴ってもう一度考える機会がくるでしょう。

追記： より著作権法を見ながら解説された記事が書かれました。法律と照らしてより深く知りたい方はこちらを参照してください。

Midjourney、Stable Diffusion、mimicなどの画像自動生成AIと著作権 | STORIA法律事務所

なぜAI学習禁止をできないのか

ざっくり言うと、平成30年の著作権法改正で著作権者の利益を不当に害しなければ、公開された著作物を大規模データの一部としてAIに学習させられるようになりました。ですので、世界に公開したイラストを普遍的な意味で「AIの学習を禁止する」とするのは難しいでしょう。

利益を不当に害する場合そうではありません。あなたのイラストを意図して使い、表現が全く似た画像が生成されて困る場合には、ちゃんと著作権法違反となり得ます。クリエイターの権利は保護されていますが、まだ裁判での判例がないのも現状です。類似性をどう判断するかも難しいところで、画風レベルであれば著作権で保護されません。これから裁判やAIサービス開発者の倫理規定、イラストレーターの意見などを含めてコンセンサスを作っていく必要があります。

著作権法のオーバーライドについて追記：個人の規約として掲示することはできますので、「機械学習やAI、解析しての利用を禁止します」と明示できます（「無断利用禁止」より明確）。その場合も絶対ではなくデータの用途やケースにより判断が個別に行われることになります。

mimicの問題はなんだったのか

今回のmimicについてはAI学習という以前の、サービス設計やコミュニケーションの問題があると思います。

改善するとして、たとえばpixivに公開アップロードされた自分の画像を、pixivと連携した本人だけが学習できるようにすれば問題はかなり小さくなります。連携できるpixivアカウントの登録日などで制限すれば、悪意のあるユーザーの大半を排除できるでしょう。ただこれは実装のコストもありますので、現状でも通報システムくらいは必要です。

実際にmimicも、他人の画像をアップロードすることを禁止しています。なので、「問題ないサービス設計か？はいかいいえで答えてください！」とひろゆきに聞かれると「うーん…、問題はありません」と言ってしまいそうです。ただユーザーを信頼しすぎている点や、それによって生まれる危険をスルーしすぎていると思います。

イラストレーターの人は悪意のあるユーザーを断罪していくコストが増える可能性はあります。mimicというサービス側で何かしらの対策は考えたほうが良いと思います。イラストレーターの人が心配しているのは、そこじゃないでしょうか。

サービス設計とはお客様や世界とのコミュニケーションです。利用される人や関係する人がどう幸せになるのかだけでなく、悪影響がないかも考えるべきでしょう。AIに関したサービスの開発者は私を含めて法律だけでなく、倫理観や権利への考え方、コミュニケーションも大切にしたほうが良いと思います。

改正された著作権法は悪法なのか

改正された著作権法は悪法なのでしょうか？　そう結論づけるのは早計です。ただ、個々に議論の余地はあります。

デジタル技術の発展のためオープンなデータを活用できることは重要です。たとえばmidjourneyって便利ですごいですよね。あれは他人の著作物を勝手に学習しています（たぶんですが高確率でそう）。そしてGoogleやTwitterもおそらくあなたの著作物を、ビッグデータの一部として学習していると思います。今日、大きなテックカンパニーはほとんどがAIを活用して、皆さんの生活に役立っているでしょう（望んだ結果を返してくれるGoogle検索やYouTubeのレコメンド、Google Photoにある僕の娘の写真とか）。

また、改正著作権法は大規模なデータや研究、技術開発のためという背景でAIへの学習を認めています。「表現や思想又は感情を自ら享受し又は他人に享受させることを目的としない場合のみOK」という条件がついているので、それを逸脱していればWebサービスやAIシステムなどとしても違反となります。

https://www.bunka.go.jp/seisaku/bunkashingikai/chosakuken/bunkakai/51/pdf/r1406118_08.pdf

意図して露骨な著作物を学習・生成させて使う場合は現行法でもアウトとなり得るでしょう。なので「改正された著作権法は悪だ」、「また我々の知らないところで法律を変えやがった」と反応しすぎるのはやめたほうが良いです。AIの利点を損ないすぎる法律を日本で通してしまうと、日本だけサービスの質が低く発展しない国になる可能性もあります。

個別のサービスには議論の余地がありますし、日本の著作権法も今後また改正されていくでしょう。判例もまだありません。ですのでイラストレーターの皆さんの意見を出していくのは良いことだと思います。ですが、「悪法だ！」と反応的になる前に、少し落ち着いてから良い法律や権利について議論するほうが良いと思います。

おわりに

今回のような議論が深まることは、僕はとても良いことと思います。

ですがあまり過剰な反応は危ういと思います。本当にちゃんと進めるべき議論が進まないおそれがあるからです。とくにSNSの渦というのは、人間の心を乱してしまいます。僕も経験があります。

僕もなるべく公平かつ簡潔にこの記事を書いたつもりですが、もちろん立場としてAIエンジニアですのでAI側に優しいバイアスがありそうだとは念頭に置いてください。そして、間違いがあれば僕に教えてください。

大切なのは落ち着いて、世界を一つひとつ良くしていくことです。そしてAIを使ったサービスに問題があれば開発者は説明や謝罪をして、修正したほうが良いでしょう。私も法律家や弁護士ではありませんが、著作権法や今回の話に深く関わる人間の一員です。なので記事で助けになる説明をしたいと思いましたし、自身の仕事でも大切にしていきたいと思っています。

イラストレーターの方のことは、AIエンジニアの皆さんも、もしかしたらAIくんも大好きだと思います（そう信じたいです）。ただ、今回みたいなサービス側の失敗（というか不備や齟齬）があるのは少し残念で、同業者として申し訳なくも思います。でも改善すれば良いと思います。

僕の記事がなにかの助けになると嬉しいです。そして、世界をより良くする方法があれば、一緒に考えていけると嬉しいです。

良ければ僕のTwitterのフォローをよろしくお願いします。

執筆：Kiyohara Hiroki (@hirokiky) （Shodoで執筆されました）

DjangoCongress JP 2022、開催します！そしてトークを募集中です

Django

DjangoCongress JP 2022のトップ画像

DjangoCongress JP 2022を11月12日（土曜日）に開催します！

そのトークを募集中ですので、ぜひお気軽に応募してください。 締切は 8月12日（金曜日） いっぱいです。

「私なんて…」と思う方、ご安心ください。今日はトーク応募のポイントをお伝えします。 Djangoについての知見がある方は共有していただけると、コミュニティのためになると思います！

とくに今年はオフラインで、東京で開催する予定です。ここ数年はイベントを開催することそのものが難しい時代でした。新型コロナへの感染対策も慣れてきた昨今ですので、ぜひオフラインで皆さんと会えると嬉しいです。

どんな内容を投稿すれば？

トークの内容はDjangoに少しでも関連していればOKです。 たとえば、このような知見はありませんか？

もしあれば何でもお気軽に投稿してください。

イベントを作るのは、あなたのトークです

ぜひ、あなたのトークを送ってください。

初めての人や、慣れてない人も歓迎しています。たとえばPyCon JPや海外イベントでの登壇となるとハードルが少し高くなるかもしれませんので、一度DjangoCongress JPで実績を積んでおくのはどうでしょう。

選考の基準としては、トークが求められているかや、イベント全体でバランスよく内容がバラけるかなどを見ています。また、応募フォームに入力している内容が詳しく書かれているかも大切な判断基準になります。逆に、投稿者や所属等は選考に関係しません。内容やトークの具体性を重視しています。公平になるために、応募者や技術のトレンドだけで選ばないためです。

お早めに内容を投稿してくれると、イベントのスタッフ的にはメンタルが安定するので嬉しいです（ギリギリまで寝かせようという気持ちも分かります…）。

ぜひ以下のフォームからDjangoの知見を共有してください。

イベントを作るのは、あなたのトークです。

forms.gle

https://forms.gle/ucAfuMdPwLxfm4n7A

追伸：私がこのイベントの代表とはいえ、個人ブログで書く内容なのか？という気もあります。ですが読んでくれる方も多いのですし、スタッフの一員としてイベントを応援する気持ちで書いています。

執筆：Kiyohara Hiroki (@hirokiky) （Shodoで執筆されました）

テックブログ運営で大変だった話とプロダクト開発に繋がった話

プロダクト開発 学び

こんにちは。kyです。 今日はちょっと昔話というか、お話をしようと思います。ですので気軽に聞いてもらえると嬉しいです。

ここでお伝えしたいことは「テックブログの運営で大変だった話」と「課題を解決するプロダクトを作っていった話」です。僕なりに気づいたこともお伝えします。

昔、テックブログを作ったときの意気込みと大変だったこと

前の会社でPyQというWebサービスを数人で立ち上げたのですが、成長するにつれて、もっとお客様にPyQを知っていただく必要がありました。

マーケターのnanaもチームにジョインし「ブログを通して有益な情報を公開して、それでサービスを知ってもらおう！」と決めました。SEOだけを考えた残念な記事を量産するのでなく、ちゃんと問題の解決や知見になる記事を書こう！ということを大切にしました。

テクノロジーに関したWebサービスだったので、テックブログとも言えるブログを作り始めました。ブログについてきちんと取り組むため、こういったことを大切にしました：

  • 独自ドメインでやる
  • 技術の内容とWebサービスのニュース両方を書く
  • 複数人で運用。相互にレビューしてちゃんと良いものを書く
  • エンジニアが技術的な正しさや有益さに、マーケターが読みやすさやSEOに責任を持つ

ブログを作るだけなら良いのですが、このような条件で真剣に運用するとなると、どうでしょうか。とくに最後の1つはとてもチャレンジングだったと思います。コピー&ペーストしたような記事が量産される時代を終わりにしようと、「うちはちゃんと読まれるうえ、読む人の課題解決や成長につながるものを作ろう！」と意気込んでました。

最初は、運営について大変なことがありました。チーム（とくにこの活動を引っ張ってくれたnana）が一生懸命考えて運営体制を作っていきました。

当時の運用フロー

そのためにこのようなフローで記事を書いていました。

  1. 記事をVSCodeで書き「テキスト校正くんプラグイン（textlint）」でチェックする
  2. 記事を書く仕事をAsanaでタスク管理する
  3. 記事のレビューをDropbox Paperで渡してコメントしてもらう（Asanaのタスクにアサイン）
  4. レビューのやり取りを記事に反映して、はてなブログに記事を作成する
  5. はてなブログの下書きプレビューで社内に共有する
  6. 記事を修正して、完成すれば記事を予約投稿する
  7. 記事が投稿されたらツイート、Facebookでシェアをする

これは結構大変そうです。

ですが条件の中で良い記事をちゃんと作ろうとすると、必要な作業だったと思います。実際に良い記事を書いて、多くの方に読んでいただいていました。今もそのブログ、Python学習チャンネル by PyQは多くの方に読んでいただいていますし、実際に役立つ内容が盛りだくさんです。

ですが、もう少しでも良いから運用を改善したいものです。とくに外部の人のチェックがあるインタビュー記事で、さらに運用が大変になったのを覚えています。困っているチームメンバーを見たときに 「絶対に助けたい」と思いました。

数年前の話ですので、今なら「Notionで運用できる！」など新しい方法があるかもしれません。Slackのスレッドでコメントしたり、Zennをチームで運用するのも良いかもしれません（独自ドメインでやりたいのでZennやQiitaは避けたと思いますが）。皆さんも、もしかしたら苦労されているかもしれません。

何かを作って解決できないかな、と考えた

そんな困っているチームメンバーを何とかしたい、と思いました。

そこで 「テックブログの運営に使えるWebサービスがあれば良いのでは」 と考えました。いえ、テックブログと言わず、複数人でのメディア運営を何とかできるプロダクトが作れるのではないでしょうか。

こんなものがあれば、協力してブログを運営するプロダクトになるのではと考えました：

  • インストール不要ですぐ使える：
    • Webサービスにすることで、導入の手間を減らす
    • オンラインのエディターで執筆すると、自動で校正される
    • テキストで入力できる（Markdownに対応）
  • 執筆のタスク管理もできる：
    • 記事を執筆する状態を同じサービス上で管理する
    • レビューのワークフローに自動で則る
    • アサインや期限、ステータスを管理し、誰があと何をすれば記事の完成かを分かるようにする
  • 記事のレビュー（コメント）もできる
    • GitHubライクな行のレビューにし、社内のエンジニアも協力しやすくする（案外誰にとっても見やすい）
    • 記事はバージョン管理し、コメントが混ざらないようにする
    • コメントが通知、Slack連携されることで連絡を減らす
  • ワンクリックで配信できる：
    • ブログ上への記事作成をワンクリックでできるようにする
    • 画像も自動で配信する
  • 高速な校正：
    • textlintはJavaScriptの形態素解析エンジンを使うので、MeCabなどの速いものを使う
    • 独自に校正ツールを実装し、高速化する
  • ディープラーニングによる校正：
    • BERTの技術を活かした文法誤り訂正（GEC）をする
    • 助詞の間違いやタイポなど、ルールや正規表現でカバーできない間違いを検知する

と、若干モリモリではありますが、これを作り始めました。

当時のブログ運用は「ある価値を実現しようとして、既存の仕組みで何とかしていた」状態でしたので、マッチするプロダクトがあるだけで何とかなります。最初からすべてを実装する必要はなく、運用しながら改善できる点も取り組みやすかった理由です。

もし皆さんも「既存のツールをいくつか使って何とか運用しているが、大変」という場面があれば、何かプロダクトを作るチャンスだと思います。一般化でき、1つの需要としてまとまりがあれば、きっと他の人も困っています。

使ってもらいながら成長する

これは完全にサイドプロジェクトとして作り始めました。まずアルファ版として作り、PyQチームに使ってもらいました。 その当時でも業務はかなり改善されたので、より便利になる「はてなブログ連携」やディープラーニングの技術を追加していきました。

ただ、狭すぎる需要に特化して作れば、それは「便利な社内システム」ができるだけです。そこで開発が進むごとに、クローズドベータやオープンベータとして多くの方に使っていただきました。 開発はその後も続き、半年前に正式リリースしました。もう前の会社での新規事業（PyQ）も軌道に乗っていたので、退社して今の株式会社ゼンプロダクツを起業しました。

そのWebサービスが、今のShodoです。

テックブログの運営にお使いいただいています。

導入してフィードバックをくれた皆さん、初期のころから使ってくださる皆さん、本当にありがとうございます。プロダクトは人に使ってもらわないと育たないと、よく分かりました。

そして、誰に使ってもらうか、どういった人に使ってもらうかも大切だと思います。なぜなら使う人によってプロダクトの方向性すら左右されるからです。プロダクトマネージャーとしては、誰に使ってもらい、いただいた意見をどう受け取るかという判断が重要です。そのためのブレない指針や心と、その逆の柔軟性も大切です。

今のShodoが最初からあれば、当時の悩みはなかったと思います。ですが悩みもあったからこそ良いプロダクトが生まれましたし、悩みや課題に向き合ったからこそチームがより強くなれたのかなと思います。

おわりに

今回は昔話的な内容でしたので、これが知見だ！と豪語するつもりはありません。ですが、こういった学びがあったよ、というサマリーをお伝えしたいなと思っています。

  • 今ある仕組みやツールで何とか解決している課題があれば、プロダクトを作るチャンス！
  • 何か具体的な悩みや助けたい人がいれば、まずは作って使ってもらおう
  • 広い意見をもらったり、どんな立場から意見をくれたかを考えて「社内システム化」を避けよう

プロセスの説明を端折って結果だけを伝えている気もしますが…、もしこの記事が多くの人に読んでいただけたら、もっと詳しく書こうかなと思います。

今後もShodoを開発して皆さんを助けられたら嬉しいです。もちろん今後、Shodoの方向性が大きく変わる可能性なども十分あります。ですが、最初に思った「この困っている人を助けたいな」という気持ちはずっと大切にしたいです。

プロダクト開発、やっていきましょう！

shodo.ink

（Shodoで執筆されました）

会社の説明動画をアバターと一緒に撮ったら再生数が50回から1000回になったという、Twitter的な話

雑談 学び

アバターと一緒に撮ったら再生数が50回から1000回になった話

こんにちは。

会社説明を人間が一生懸命する動画は50回しか再生されなかったのに、アバターと話すおもしろ動画を撮ったら1000回も再生されました、という話です。

前提に違う点が多くありますので、単純に「アバターで撮影したら成果が20倍！」という話ではありません。ただ私的に面白かったので感じたことをメモした記事だと思ってください。

アバターと会話形式にした動画

とある会社説明の動画を作っているときに、「話の聞き役がほしいな」と思いました。せっかくVRやAI音声合成の技術が発達していますので、新技術で遊んだ動画が作れないかなと思い、試しに撮ったデモ を1000回も観ていただきました。

もともとは「こんなことしちゃう俺デュフフ」的なもので、ツイートする行為自体もちょっと痛々しいネタです。ネタに走れば良いというわけではありませんが、少し今回の反応を考える意味はありそうです。

もともとあった真面目な動画はあまり観られなかった

それ以前にYouTubeで投稿してツイートした動画は、50回ほど観ていただきました。

www.youtube.com

単純には比較できませんが、あまり伸びなかったのは事実です。

もちろん真剣に説明した長めの動画ですので、50回観ていただいただけでも非常にありがたいです。さらにYouTubeにアップロードしたものをツイートしたので、上記の動画と再生数だけを比べて良し悪しの判断はできません。

ただ、「新しく知ってもらいたい」という目的であれば、真面目なだけではダメなようです。

何が違ったのか？　Twitter受けとは何か

アバターと会話する奇々怪々な動画は、Twitterという文脈で良かったということでしょうか。

以前、ある方に「SNSを眺めている人には、噛み砕いた流動食を口元まで持っていく」必要があると教えていただきました。ものの例えとして「それくらいの気持ちで発信しなさい」という意味合いです。たしかに今回の動画は「脳死でも楽しめるコンテンツ」ではありますし、見たいなと思わせる何かもあります。

取っ掛かりとして面白かったのは、会社やWebサービスではなく「アバターと会話する妙なお兄さん」 という部分です。さらに音声合成というのもあって、アバターやメタバース、音声合成に興味のある人が楽しんでくれた印象でした。

それでは「会社紹介になっていないだろう！」という心配もありますよね。そこで動画を観てくれた人に直接、感想を聞いておきました。その人が内容をハッキリと覚えていないのは事実でしたが、「こういう事業をやっているんだなぁ。AIを使ったWebサービスもできる時代なんだ」という印象は伝わったようでした。

もちろん会社やサービスの紹介という部分を疎かにしたり、面白さを求めて過激になったりするのは良くありません。そして仕事としてやるのであれば、より関心を持っていただいたり、具体的なアクションに繋がらないと意味はありません。

ともあれ、まず知ってもらう必要はありますし、ハードルを下げる何かは必要なようです。道化とまでは言いませんが、「楽しんでいただけますよ」という雰囲気は必要なようです。まぁ考えてみると、自分自身もTwitterでは面白いネタや体験談のマンガ、ニュースの速報を見がちな気がします。反応しやすいですからね。

立派に主張するような発見はとくにありませんが、真面目だけではウケないのがSNSという世界のようです。

おわりに

今回の動画自体がある種のデモですので、ちゃんとした動画はどこかでお見せできると思います。ぜひ @hirokikyをフォローしてください！

また、Shodoに興味を持っていただけた方は、無料から使えますのでぜひご利用ください。

shodo.ink

執筆：Kiyohara Hiroki (@hirokiky) （Shodoで執筆されました）

4年間、同じ服を着て気づいたこと

学び

追記：結局、またさらに1年同じ服を着ていました

私の娘は2歳なのですが、父が黒いTシャツ以外を着ている姿を見たことがありません。

この4年間、同じ服をずっと着ていました。

今日はその4年間、同じ服を着て気づいた発見を皆さんにお伝えしようと思います。

同じ服ってどういうレベルで？

事前に仕様の説明から入らせてください。

この4年は以下の服を着ていました：

  • 基本
    • 黒の無地クールネックTシャツ（ヘインズのプレミアムジャパンフィット）
    • ジーパン（EDWIN 402）
  • 上着
  • 温度調節用

僕に会ったことがある人は「あー」と納得いただけると思います。

ケンオールパーカーを着がち

2019年に書いた記事のスタイルから基本的に変わっていません。

どれくらい同じ服だったのか

完全に誰得の情報なので、読み飛ばしてOKです。同じ服を着る生活をしてみたい人は参考にしてください。

  • 黒のTシャツとジーパンは、ほぼ100％毎日着ていました。唯一スーツを着るときに白の下着を着ただけです
  • 型番の誤差として、Tシャツにはスリードッツのジョシュが8枚中2枚、ジーパンはアメリカンイーグルのスリムが5本中2本入っています
  • 黒ワイシャツやタートルネックなどは春や秋ごろに、Tシャツだけだと寒い日などに着ていました
  • 靴はM996からAllBirdsに途中で変わりました
  • 寝間着はイベントのTシャツなど比較的自由ですが、最近はグレーの無地スウェットを多く着ています
  • 下着については同じものを買い続けることが難しく、Amazonで似た黒の靴下やパンツをまとめて買っていま

意外とジョブズもゆるい

「同じ服を着る人」として有名なスティーブ・ジョブズやマーク・ザッカーバーグもゆるいところがあります。

ザッカーバーグ氏はグレーのTシャツしか着ないと言われつつ、Metaへの社名変更発表時に黒のシャツを着ていたりします。スティーブ・ジョブズも実は靴の型番を変えていたり、休暇中に白いシャツや半ズボンをはいた写真が残っています（娘のエリンと金閣寺で撮った写真など）。

まぁそういった「同じ服を着ていると認識されている人たち」も本当に100％ずっと同じ服ではないので、僕も「同じ服を着ていた」と言って差し支えないと思います。

4年間、同じ服を着て気づいたこと

本題です。

こういった記事は良い点ばかり列挙しがちですので、今回はとくにマイナスの面も意識して紹介したいと思います。 4年間、同じ服を着て気づいたことを5つ聞いてください。

スーツは要る

断言しますが、スーツは要ります。

少なくとも、友だちの結婚式に行けるようなスーツは必要です。 他にも大事な商談のときや、銀行に行って会社の融資をお願いするときなど、スーツを着るべきときは現実に存在します。

スーツを着るべき場面を、セットアップやジャケットだけで誤魔化すのは少し難しいと思います。 「考えることを減らすため」に同じ服を着ているフシもあるので、「スーツでなくて良いだろうか？」と気になるほうが本末転倒です。

「絶対にどんな状況でも大丈夫な服」を着続けたい、と考えないほうが良いです 。

そんなものはありません。

ジーパンで結婚式にはいけませんし、スーツでプログラミングをしたくありません。先述したような季節用のワイシャツなどもそうで、あまり厳密に「絶対にこのTシャツとジャケットしか着ない！」とすると状況や気温にあわせられなくて、逆に考えることが増えます。

仮に「袖が着脱可能なセットアップ」と言えるものを用意しても、僕はあまり好きじゃありません。それはすでに「1つの服」ではないからです。であれば、状況や季節に応じた服を着たほうがシンプルです。生き方をシンプルにしようとして手段や振る舞いが複雑であれば意味はない、と考えています。

スーツを着る場面では、スーツを着るのがシンプルな生き方です。

着たい服を買えない苦しみはある

1ヶ月、プロテインだけ食べて生活してください。 食事から得られていた幸せの大きさに驚くと思います。

それと同じで、「着たい服を着る」という幸せは案外大きかったんだと気づきました 僕は欲しいTシャツがあっても「これは着られない」と諦める必要があります。

ふと買い物に行ったときやネットで見かけたとき、推しがグッズを出したときなどありますよね？ほとんどの場合、諦める必要があります。これが案外、寂しいものです。

そういった日常の小さな喜びが減ってしまいます。ある意味では、その可能性を断つことで余計なことを考えずに済んでいると言えます。

公私の区別をつけにくい

意外な盲点なのですが、精神的に公私の区別をつけにくいです。

休日も平日も同じ服に着替えますので、「よし今日は仕事だぞ」というようなメリハリが生まれません。とくに最近は自宅で仕事をする機会も多いので、何らかの切り替えスイッチは欲しいものです。

人間には着ている服や周囲の状況から自分の気持ちや感情を調整する機能があるように思います。僕の場合は部屋を1つ仕事用にしていますが、同じ服を着て生活するのであれば何かしらの切り替えスイッチは用意したほうが良いです。

考えることは案外増える

「同じ服を着れば考える回数が減る」とも言い切れません。

たしかに毎朝服について考えることは減ります。そこは楽です。ですが「同じ服を着る」という思想自体を考える機会は増えます。たとえば前述の通り服が買えないなと残念に思ったり、定期的に今の型番の服で良いか検討したり、このブログ記事を書いたりします（逆にめちゃくちゃ考えてるが！）。

だんだん慣れて考えることは減り、4年も経てばほぼゼロになりますが、最初の1年くらいは考えることが増えると思ってください。

服飾について一番考えない状態が何かと言うと、「着たい服を深く考えずに買って、毎朝何も考えずにあるものを着る状態」だと思います。つまり、普通でいることです。

とはいえ、僕はズボラなわりに「この着合わせで良かったかな？」と心配になったり、「今日はこの服で良かったかな」とずっと気になる人間なのです。「この服を着ているということは、こういう感情だと予想されるのではないか？」とまで考えることもありました。

そういった憂慮の余地がなくなったのは、同じ服を着ていて良かったことです。 ですが「同じ服を着ることについて考える」機会は、始めてから1年はとくに増えます。

「いつも最高の自分」ではない

ネットで同じ服を着ることについて調べると、利点として「いつも最高の自分でいられる」というような表現を目にします。

断言しますが、いつも最高の自分ではありません（たぶんこれを言う人はエアプ勢だと思います）。 「いつも、いつもの自分でしかない自分」が正しいと思います。

誰だって良いスーツを着ているときやドレスを着ているときが最高だと思います。それはそうですよね。他にもオシャレな服屋さんでマネキンが着ているセットを買うほうが、誰にとってもより良い状態だと思います。

バッチリした服をバッチリ着て最高と思っている人の姿：

スーツをバッチリ着たほうが最高なのは間違いない

良い服だね！と褒められることはなくなります。「同じ服を着ているね」と言われたことすらありません。おしゃれをしたいのであれば「同じ服を着るのがファッションだ」なんて思い違いをせずに、素直におしゃれをするほうが良いです。

ただ、自分の中で外さない、好きなスタイルで居られることは事実です。その状態に無思考でなれる、というのが良い点です。

同じ服を着る生活はおすすめできる？

おすすめできません。

多くの人にはできません。

準備や制約がある一方、とくに内面的なメリットは大きいと感じられず、誰かから褒められることもありません。僕にとっては結構快適ですが、不自由があるのは事実です（むしろ不自由を選択している）。

もし「仕事では決まった服やスーツを着ている」という人がいれば、案外それが良い答えだなと感じます。考えることを減らせますし、仕事モードに入りやすいです（もちろんプログラミングにスーツは向いていません）。

もともと同じ服を着たい傾向があるのであれば、試す価値はあります。自分のもともとの精神構造が重要なポイントです。たとえば「すでに靴下は黒の1種類で統一している」ような人であれば、Tシャツやズボンも統一して良いと思います。ただ、あまり真剣になりすぎる意味はないと思います。

僕は気に入っているのでこれからも続けると思います。ですが、より楽な気持ちでいようかなと思います。まぁ、どんな服を着ていても、僕は僕です。

一番気づいて良かったのは、そういう部分なのかもしれません。4年かかってそれかよ、という内容ですね。

ここまで読んでくれてありがとうございます。

もし気になることや相談したいことがあれば @hirokiky に聞いてください。同じ服を着ることについては、平均的な人よりも続けているほうだと思います。

執筆：Kiyohara Hiroki (@hirokiky) （Shodoで執筆されました）

JavaScriptのClipboard APIでリッチテキスト（書式付きテキスト）をコピーする

JavaScript

クリップボードにリッチテキストをコピーする方法を説明します。今回はとくにClipboard APIという現在推奨された方法で実装します。

「リッチテキストをコピー」というのは、ペーストしたときにWYSIWYGエディターへ書式が有効なまま入力されることを言っています。たとえばWordでコピーをすると、見出しや太字などを含めてコピーされるのと同じことです。

Clipboardを使ってリッチテキストをコピーする

標準のClipboard APIを使ってリッチテキストをコピーするには、以下のようにします。

const body = '<h1>見出し</h1><strong>太字</strong>'

const blob = new Blob([body], { type: 'text/html' })
const blobPlain = new Blob([body], { type: 'text/plain' })
const item = [new window.ClipboardItem({ 'text/html': blob, 'text/plain': blobPlain })]

await navigator.clipboard.write(item)

（たとえば「コピー」ボタンをクリックしたときなどに実行してください）

MIMEタイプに 'text/html' と指定して、Blobを渡すことでできます。こうすることでHTMLと認識させられるので、WordやWYSIWYGエディターへペーストしたときに書式が有効となります。Google Chromeの場合、コピーしたHTMLは自動でサニタイズされます。

実装するときは 'text/plain' としてもコピーしてください。そうしないと、メモ帳などにプレーンテキストとして貼り付けられるときに動作しません。

Firefoxは未対応

2022年1月26日時点ではFirefoxがHTMLのコピーに対応していません。

window.ClipboardItem が存在するかなどをチェックして、ない場合は navigator.clipboard.writeText を使ってプレーンテキストのみコピーするのが良いと思います（細かい実装の話はお任せしますが）。

Google Chromeで対応された履歴はこちらです。

chromestatus.com

Google ChromeとSafariではできるので、そこまで困らないのが事実です（僕はFirefoxユーザーですが）。

document.execCommandは使わない

以前まではClipboard API経由でリッチテキストをコピーできませんでした。少し前の記事ですと document.execCommand('copy') とイベントリスナーを使って何とかする方法も書かれていますが、現在は避けたほうが良いかと思います。

document.execCommand 自体が非推奨になっていますので、できれば Clipboard を使いましょう。

developer.mozilla.org

まとめ

Clipboard APIを使ってリッチテキスト（書式付きテキスト）のコピーはできます！ Firefoxは執筆時点で未対応ですが、そこは割り切れる範囲かなという気もします。

document.execCommand('copy') はなるべく使わないようにしましょう。

今後、対応されていくと良いなと思っています。

caniuse.com

執筆：Kiyohara Hiroki (@hirokiky) （Shodoで執筆されました）

Pythonで`{文字列: 数値}`の辞書から数値が最大のキーと値を取る

{文字列: 数値} のような辞書（Dict[str, int]）があるときに、数値が最大・最小のキーと値を取得する方法です。

たとえば文字の出現回数をカウントしているときなどに使えます。

>>> d = {"a": 3, "b": 2, "c": 1}
>>> k, v = max(d.items(), key=lambda x: x[1])
>>> k
'a'
>>> v
3

他にも sorted() や min() でも使えます。

collections.Counter とも併せて使えるので便利です。

>>> from collections import Counter
>>> d = Counter("aaaaabbbcc")
>>> k, v = max(d.items(), key=lambda x: x[1])
>>> k
'a'
>>> v
5

タプルのリストが便利に使える

タプルのリストから最大値、最小値を取ると便利に使えます。

たとえば辞書のキーにできないオブジェクトの場合は、第一要素に数値を持つタプルを使うと似たことができます。 この例では辞書がひも付いているとしました。

>>> l = []
>>> for i in range(5):
...     l.append((i, {}))
... 
>>> l
[(0, {}), (1, {}), (2, {}), ...]
>>> max(l, key=lambda x: x[0])
(4, {})

key= を指定しない場合、第1要素の数値が同値の場合に第2要素が評価されますので注意してください。

タプルのリストや key= 引数をうまく使えば、何らかの値に数値がひも付いているときに最大値や最小値を取得できます。

執筆：Kiyohara Hiroki (@hirokiky) （Shodoで執筆されました）