[{"data":1,"prerenderedAt":79},["ShallowReactive",2],{"article-w4q57e0zh0v1":3,"prev-article-w4q57e0zh0v1":33,"$f5-LjDMkY38dRYiR6cBrST_Key1i_IYtmal3bAXy4zWk":53,"next-article-w4q57e0zh0v1":61},{"contents":4,"totalCount":31,"offset":32,"limit":31},[5],{"id":6,"createdAt":7,"updatedAt":8,"publishedAt":8,"revisedAt":8,"title":9,"content":10,"tags":11,"is_no_index":30},"w4q57e0zh0v1","2025-10-05T08:09:52.259Z","2025-10-05T08:20:42.619Z","サイトをリニューアルしたにょ","\u003Ch1 id=\"h8d027c8ed3\">はじめに\u003C/h1>\u003Cp>どうも、わたしです。\u003C/p>\u003Cp>先日、このサイトにいくつかの変更を加えました。 \u003Cbr>元々は、壁打ちブログのつもりで運営していたのですが、承認欲求がとうとう無視できない大きさになってしまいまして。 \u003Cbr>ちなみに、ここで話すソースコードは全てGitHub上に公開しているので、もし気になる人がいれば、読んでみてもらえると嬉しいです。\u003Cbr>\u003Ca href=\"https://github.com/chan-mai\" target=\"_blank\" rel=\"noopener noreferrer\">https://github.com/chan-mai\u003C/a>\u003C/p>\u003Cp>開発を始めた当初は、ただただコメントといいね機能を追加するだけの、簡単な改修のつもりでした。\u003Cbr>ところが、いざ作り始めると「コメントは絶対に自分の目で見てから承認したい」「どうせなら管理画面もちゃんと作りたい」と、次から次へとやりたいことが溢れてきてしまい、その結果、そこそこ本格的なWebアプリケーションへと変貌を遂げました。\u003Cbr>最初の動機を考えると、拍子抜けするほど大掛かりなものになってしまったな、というのが正直な感想です。\u003C/p>\u003Ch1 id=\"h2220f0ef7d\">やったこと\u003C/h1>\u003Cp>今回の改修の始まりは、サイトに外との接点となるインタラクション機能を設けることでした。\u003C/p>\u003Cp>まず手始めに、いいね機能に手を入れています。\u003Cbr>仕組みは簡単なもので、ユーザーがハートを押すとAPIが叩かれ、記事の\u003Ccode>contentId\u003C/code>やIPアドレスなんかが記録されます。\u003Cbr>同時にlocalStorageにuuidが保存されるのですが、これはいいねの解除時に使うためだけのものであって、IPベースでの制限はしていないので、スマホとPCから同じ記事に…みたいなことも普通に出来てしまいます。\u003Cbr>普通に欠陥な気もするのですが、ちゃんと実装する気力はなかったので仕様です。\u003C/p>\u003Cp>そして、コメント機能。\u003Cbr>だいたいコメントというのは常々、おぞましいほどに醜い言葉で溢れるのが大概で、私はそういうものを目にしたくないのです。\u003Cbr>だから、どうしてもコメントを完全にコントロールする手段が必要でした。\u003Cbr>その解決策が、投稿されたコメントを一つひとつ自分の目で確認し、手動で承認するという運用フローと、それを実現するための管理コンソールだったわけです。\u003C/p>\u003Cp>ここからは、技術的な話をちょっとだけします。\u003C/p>\u003Ch1 id=\"h55235f9fca\">コメント機能の裏側\u003C/h1>\u003Cp>まず、コメント機能そのものの話から。\u003C/p>\u003Cp>ユーザーがコメントを投稿すると、\u003Ccode>POST /api/comment/[contentId]\u003C/code>というAPIが叩かれます。\u003Cbr>バックエンドでは、ユーザー入力値の基本的なバリデーションと、お気持ち程度のTurnstileのtoken検証のみを行なっています。\u003Cbr>投稿されたコメントは、まずデータベースに\u003Ccode>PENDING\u003C/code>ステータスで保存されます。\u003Cbr>このステータス管理が肝で、Prismaのスキーマに\u003Ccode>CommentStatus\u003C/code>というenumを定義して、\u003Ccode>PENDING\u003C/code>、\u003Ccode>APPROVED\u003C/code>、\u003Ccode>REJECTED\u003C/code>の3つの状態を持たせました。\u003Cbr>承認されるまでAPIの返り値を含めフロントには一切露出しない、完全な事前承認制です。\u003C/p>\u003Ch1 id=\"heb9db543a7\">データベース\u003C/h1>\u003Cp>これらのデータを保存しているのが、CockroachDBという分散SQLデータベースです。\u003Cbr>所謂NewSQLとかいうやつですね。\u003Cbr>PostgreSQLと互換性がありつつ、スケーラビリティと耐障害性に優れている面白い子で、名前が気持ち悪いことを除けば結構好きです。\u003C/p>\u003Cp>ORMにはPrismaを選びました。\u003Cbr>「型安全でマイグレーションが簡単！」とは言うものの、最近のORMであれば大体は似たようなことができる気がします。\u003Cbr>選定理由は単なる好みです。\u003Cbr>名前かわいいし！\u003C/p>\u003Cp>今回追加した主なモデルは、いいね用の\u003Ccode>Favorites\u003C/code>、コメント用の\u003Ccode>Comments\u003C/code>、そして管理者情報を格納する\u003Ccode>AdminUser\u003C/code>と権限を管理する\u003Ccode>AdminPermission\u003C/code>。\u003C/p>\u003Cdiv data-filename=\"prisma/schema.prisma\">\u003Cpre>\u003Ccode>// いいね\nmodel Favorites {\n  id        String   @id @default(uuid(7))\n  contentId String   @map("content_id")\n  userIp    String   @map("user_ip")\n  createdAt DateTime @default(now()) @map("created_at")\n  updatedAt DateTime @updatedAt @map("updated_at")\n\n  @@index([contentId])\n  @@index([userIp])\n  @@map("favorites")\n}\n\n// コメントステータス\nenum CommentStatus {\n  PENDING // 承認待ち\n  APPROVED // 承認\n  REJECTED // 拒否\n}\n\n// コメント\nmodel Comments {\n  id        String        @id @default(uuid(7))\n  contentId String        @map("content_id")\n  name      String\n  comment   String\n  userIp    String        @map("user_ip")\n  status    CommentStatus @default(PENDING)\n  createdAt DateTime      @default(now()) @map("created_at")\n  updatedAt DateTime      @updatedAt @map("updated_at")\n\n  @@index([contentId])\n  @@index([userIp])\n  @@index([status])\n  @@map("comments")\n}\n\n// 権限の種類\nenum Permission {\n  COMMENT_VIEW      // コメント閲覧\n  COMMENT_ADMIN     // コメント管理\n  FAVORITE_VIEW     // お気に入り閲覧\n  FAVORITE_ADMIN    // お気に入り管理\n  ADMIN_USER_VIEW   // 管理者ユーザー閲覧\n  ADMIN_USER_ADMIN  // 管理者ユーザー管理\n}\n\n// 管理者ユーザー\nmodel AdminUser {\n  id              String            @id @default(uuid(7))\n  githubUsername  String            @unique @map("github_username")\n  githubUserId    BigInt            @map("github_user_id")\n  displayName     String?           @map("display_name")\n  email           String?\n  avatarUrl       String?           @map("avatar_url")\n  isActive        Boolean           @default(true) @map("is_active")\n  createdAt       DateTime          @default(now()) @map("created_at")\n  updatedAt       DateTime          @updatedAt @map("updated_at")\n  permissions     AdminPermission[]\n\n  @@index([githubUsername])\n  @@index([isActive])\n  @@map("admin_users")\n}\n\n// 管理者権限\nmodel AdminPermission {\n  id         String     @id @default(uuid(7))\n  adminId    String     @map("admin_id")\n  permission Permission\n  createdAt  DateTime   @default(now()) @map("created_at")\n  updatedAt  DateTime   @updatedAt @map("updated_at")\n  admin      AdminUser  @relation(fields: [adminId], references: [id], onDelete: Cascade)\n\n  @@unique([adminId, permission])\n  @@index([adminId])\n  @@index([permission])\n  @@map("admin_permissions")\n}\u003C/code>\u003C/pre>\u003C/div>\u003Cp>\u003C/p>\u003Ch1 id=\"h495fd6e106\">管理コンソール\u003C/h1>\u003Cp>この管理コンソールこそ、今回の改修で最も大きな作業となった代物です。\u003Cbr>「コメントは絶対に自分の目で見てから承認したい」という要件が、この巨大な機能を生み出すきっかけでした。\u003Cbr>最初は適当なBASIC認証でなんとかしようと思っていたのですが、「どうせならとログイン機能も…」と考えたのが運の尽きです。\u003C/p>\u003Cp>認証には手軽なGitHub OAuthを採用しました。\u003Cbr>ユーザーがログインするとGitHubの認証ページに飛び、認可が済むとコールバックURLに戻ってくる。\u003Cbr>GitHubから受け取ったユーザー情報が\u003Ccode>AdminUser\u003C/code>テーブルに登録されていて、かつアクティブならセッションを発行する、という流れです。\u003C/p>\u003Cp>セッション管理には\u003Ccode>nuxt-auth-utils\u003C/code>を利用しました。\u003Cbr>内部的にJWTを使い、いい感じにサーバーサイドでセッションを検証してくれます。\u003Cbr>認証関連の処理は\u003Ccode>server/utils/auth.ts\u003C/code>にまとめていて、特に\u003Ccode>requireAdminSession\u003C/code>関数では、リクエストごとに管理者の存在とアクティブ状態をDBに確認しにいく割と厳格な権限確認を行っています。\u003Cbr>Middlewareで未認証ユーザーをサインインページに弾いてくれるので、部外者が管理画面を覗くことはできません。\u003C/p>\u003Cp>そして極め付けが、RBACの実装です。\u003Cbr>このサイトの管理者は私一人しかいないのに、いくつかの細かい権限を定義しています。完全に過剰な機能ですね。\u003C/p>\u003Cp>でも、この設計のおかげで、将来「この人にはコメントの承認だけ任せたい」なんてことが可能になりました。\u003Cbr>各APIエンドポイントの冒頭で\u003Ccode>requirePermission\u003C/code>関数を呼び出して権限をチェックし、フロント側でもComposableで、権限に応じた表示に切り替えています。\u003C/p>\u003Cp>UIも割といい感じにできたので自慢がてら見せびらかしておきます。\u003C/p>\u003Cfigure>\u003Cimg src=\"https://images.microcms-assets.io/assets/3aba23b5bd6f4b79800a0305d0e4f8aa/a0e5f14bbe1c4e50a04cb7770218956d/image.png\" alt=\"\" width=\"3600\" height=\"2338\">\u003C/figure>\u003Cfigure>\u003Cimg src=\"https://images.microcms-assets.io/assets/3aba23b5bd6f4b79800a0305d0e4f8aa/a257735d764c4c85b995d6f9b42517ea/image.png\" alt=\"\" width=\"3600\" height=\"2338\">\u003C/figure>\u003Cfigure>\u003Cimg src=\"https://images.microcms-assets.io/assets/3aba23b5bd6f4b79800a0305d0e4f8aa/554a3692ecaa488880af06b58022b603/image.png\" alt=\"\" width=\"3600\" height=\"2338\">\u003C/figure>\u003Cp>\u003C/p>\u003Ch1 id=\"h1afe451c43\">さいごに\u003C/h1>\u003Cp>今回のサイト改修は、過去のちょっとした機能追加が嘘のように、大規模なものとなりました。 \u003Cbr>承認欲求という、どちらかといえばネガティブな感情から始まった作業でしたが、いざ手を動かし始めると、技術的な好奇心がすべてを上回ってしまった感じです。\u003C/p>\u003Cp>満足したので安心して眠れます。\u003Cbr>それでは。\u003C/p>",[12,18,24],{"id":13,"createdAt":14,"updatedAt":15,"publishedAt":14,"revisedAt":15,"slug":16,"name":17},"4oy2jc8mdg","2025-04-28T07:14:01.179Z","2025-12-03T16:08:24.495Z","diary","日記",{"id":19,"createdAt":20,"updatedAt":21,"publishedAt":20,"revisedAt":21,"slug":22,"name":23},"qfey3yw0z1","2025-04-29T08:44:41.687Z","2025-12-03T16:07:14.622Z","technology","テクノロジー",{"id":25,"createdAt":26,"updatedAt":27,"publishedAt":26,"revisedAt":27,"slug":28,"name":29},"8q8qyy8sz3","2025-04-29T08:44:23.406Z","2025-12-03T16:07:24.495Z","programming","プログラミング",false,1,0,{"contents":34,"totalCount":52,"offset":32,"limit":31},[35],{"id":36,"createdAt":37,"updatedAt":38,"publishedAt":39,"revisedAt":38,"title":40,"content":41,"tags":42,"is_no_index":30,"summary":51},"svgkndwg3ng9","2025-09-29T13:06:03.316Z","2026-06-26T14:50:56.142Z","2025-09-29T13:16:44.358Z","独自ドメインでのメールアドレス運用をやめ、Hide My Emailに移行した話","\u003Cp>どうも、わたしです。\u003Cbr>今日は、長らく頭を悩ませていたメールアドレスの運用について、その移行経緯と最終的な結論を記録しておこうと思います。\u003C/p>\u003Ch1 id=\"h8d027c8ed3\">はじめに\u003C/h1>\u003Cp>かつては自宅サーバでメールサーバを運用していましたが、自宅サーバ群の完全撤廃に伴い、その運用も当然ながら終了しました。\u003Cbr>以前はHomeNOCより割り当ていただいたIPで運用していましたが、自宅の一般回線はOP25Bの影響を避けられないため、代替としてAmazon Simple Email Service (SES)を暫定的に利用していた、というのがこれまでの経緯です。\u003C/p>\u003Cp>SESのコストや機能に大きな不満はなかったものの、ごく稀に発生するGmailへの転送失敗という、再現性の低い問題が看過できなくなり、本格的に移行先を探すことにしました。\u003C/p>\u003Ch1 id=\"h408cdaab63\">検討と検討と検討\u003C/h1>\u003Cp>まず、国内でよく名前が挙がる安価なメールサービス、例えばConoHaやさくらのメールボックスあたりから検討を始めましたが、これらはその仕様のお粗さから、候補にすら入りませんでした。\u003C/p>\u003Cp>特にさくらのメールボックスに関しては、価格の安さからスパム業者の温床になっているという話は有名で、実際にAS単位でメールサービスからブロックされることも珍しくありません。\u003Cbr>私のような真っ当な利用者が、なぜスパマーのせいでメールが届かないリスクを負わなければならないのか。\u003Cbr>サービス設計としてあり得ない話です。\u003Cbr>たまったものではありません。\u003C/p>\u003Cp>そもそも私の要件は極めてシンプルです。\u003C/p>\u003Col>\u003Cli>独自ドメインで、大量のアドレスを生成・受信できること。\u003C/li>\u003Cli>それらを普段使いのメールボックスに転送できること。\u003C/li>\u003Cli>生成した大量のアドレスからメールを送信できること。\u003C/li>\u003C/ol>\u003Cp>メインで利用しているメールアドレスを、素性の知れないウェブサービスに登録するのが生理的に受け付けない、というだけの理由で、サービスごとにアドレスを使い分けるためだけに独自ドメインを利用しています。\u003Cbr>プライバシがどうこうという崇高な理念は、あいにくと持ち合わせていません。\u003Cbr>現代において、ビッグテックから完全に情報を秘匿することが、現代においてどれほど非現実的か理解しているつもりですので。\u003C/p>\u003Cp>Tech系の界隈を見渡すと、Zoho MailやProtonMailを利用している層がかなり観測できます。\u003Cbr>しかし、私のユースケースはサービス登録の都度、数百から数千といった単位でアドレスを量産することにあるため、エイリアス数に課金されるこれらのサービスはコスト的に全く見合いません。\u003C/p>\u003Cp>コストだけを考えればCloudflare Email Routingも候補でしたが、基本的に受信専用のものでした。\u003Cbr>送信もそれなりに行うため、機能的に片手落ちであり、これも除外。(これを書いている少し前に\u003Ca href=\"https://blog.cloudflare.com/email-service/\" target=\"_blank\" rel=\"noopener noreferrer\">Cloudflare Email Service’s\u003C/a>なるものがプライベートベータとしてリリースされたようですが、検討していた時点では存在しなかったため、考慮していません)\u003C/p>\u003Cp>正直なところ、VPSを借りて再びメールサーバを構築することも一瞬考えました。\u003Cbr>しかし、あの不毛な設定と、セキュリティアップデートやスパム対策に追われる運用保守に、再び貴重なリソースを投下するのはあまりにも非合理的だと判断し、即座に却下しました。\u003Cbr>あんな面倒なこと、二度とやりたくありません。\u003C/p>\u003Ch1 id=\"h046bdabcec\">Apple Hide My Email、お前だったのか\u003C/h1>\u003Cp>ここで私はiCloud+に含まれるHide My Email機能の存在に行き着きます。\u003C/p>\u003Cp>最近の私の身の回りは比較的Apple製品で固められており、そのエコシステムとの親和性は言うまでもありません。\u003Cbr>そして何より、私の目的はアドレスを使い分けることであり、独自ドメインの利用は、その目的を達成するための単なる手段に過ぎませんでした。\u003Cbr>その手段へのこだわりを捨てることに、何のためらいもありません。\u003C/p>\u003Cp>むしろ、独自ドメインを手放すことには予期せぬメリットすらありました。\u003Cbr>PictLinkのような、特定のドメイン以外からの登録を受け付けない、前時代的で愚かな仕様を持つサービスが未だに存在しますが、\u003Ccode>icloud.com\u003C/code>というドメインパワーの前では、そうした問題も発生しにくい。\u003Cbr>これはうれしい。我ながらかなり合理的な判断です。\u003C/p>\u003Cfigure>\u003Cimg src=\"https://images.microcms-assets.io/assets/3aba23b5bd6f4b79800a0305d0e4f8aa/eae3d94adc674e3b89835222a24fd6ef/D510F5C4-01C7-4CC9-966C-29245F32CE0D.JPG?w=600&h=1303\" alt=\"\" width=\"600\" height=\"1303\">\u003C/figure>\u003Cp>一つ問題だったのは、パスワード管理に利用しているVaultwarden(Bitwarden互換)のクライアントから、直接Hide My Emailのアドレスを生成できない点でした。\u003Cbr>サービス登録のたびに手動でアドレスを生成し、コピペするのは普通にしんどいですし、UXとして最悪です。\u003C/p>\u003Cp>しかし、この問題は\u003Ca href=\"https://misskey.vip/@n\" target=\"_blank\" rel=\"noopener noreferrer\">お友達のまくらくら\u003C/a>が作っていたブリッジツールによって解決しました。\u003Cbr>\u003Ca href=\"https://github.com/lqvp/hme_bridge\" target=\"_blank\" rel=\"noopener noreferrer\">https://github.com/lqvp/hme_bridge\u003C/a>\u003C/p>\u003Cp>外向きにはSimpleLoginのAPIとして振る舞うことで、Bitwardenクライアントを騙し、内部でiCloudのAPIを叩いているようです。\u003Cbr>Rustで書かれていたのでコードの詳細は読んでいませんが、きちんと動くので多分問題ないでしょう。\u003Cbr>ありがたく利用させてもらうことにしました。\u003C/p>\u003Cp>各種サービスに登録していたメールアドレスの変更も概ね完了し、現在はiCloud基盤で安定して稼働しています。\u003Cbr>SES + Lambdaの環境で発生していたようなメールのロストもなく、不満はありません。\u003C/p>\u003Ch1 id=\"h1afe451c43\">さいごに\u003C/h1>\u003Cp>最近のサービスはSSOを前提とし、ユーザにメールアドレスの入力すらさせず、GoogleアカウントやiCloudアカウントでログインさせるものが増えているように感じます。\u003Cbr>この風潮の背景には、「原則としてユーザは馬鹿で愚かで無能なものなので、まともにアカウント管理など到底できる訳がない」という、サービス提供者側の諦観にも似た思想があるのでしょう。\u003Cbr>それ自体は否定しませんし、私も同感です。\u003C/p>\u003Cp>しかし、例えばGoogleのような単一の認証基盤に、あらゆるサービスの認証を依存させるアーキテクチャには、強い違和感を覚えます。\u003Cbr>これは、すこし考え方を変えて見れば、SPOFを意図的に作り出しているに等しいあまりにも稚拙で傲慢な設計です。\u003Cbr>一つのサービスから情報が流出しただけで、他の全アカウントに影響が及びかねない構造など、本来あってはならない。\u003Cbr>どうやら世の中の多くの人間に、まともなセキュリティ感覚はないらしいようです。\u003C/p>\u003Cp>GoogleがDon't be evilを捨てて久しいですが、そのGoogleアカウントに生活の全てを預けることを、なぜ誰も疑問に思わないのでしょうか。\u003Cbr>なーにがゼロトラストだ。口だけでフルトラストじゃないか。\u003C/p>",[43,44,50],{"id":19,"createdAt":20,"updatedAt":21,"publishedAt":20,"revisedAt":21,"slug":22,"name":23},{"id":45,"createdAt":46,"updatedAt":47,"publishedAt":46,"revisedAt":47,"slug":48,"name":49},"fwj_nwhj1-s","2025-04-30T04:55:28.953Z","2025-12-03T16:07:03.591Z","server","サーバー",{"id":13,"createdAt":14,"updatedAt":15,"publishedAt":14,"revisedAt":15,"slug":16,"name":17},"どうも、わたしです。今日は、長らく頭を悩ませていたメールアドレスの運用について、その移行経緯と最終的な結論を記録しておこうと思います。はじめにかつては自宅サーバでメールサーバを運用していましたが、自宅サーバ群の完全撤廃に伴い、その運用も当然ながら終了しました。以前はHomeNOCより割り当ていただい",35,{"url":54,"domain":55,"title":56,"description":57,"image":58,"favicon":59,"type":60},"https://github.com/chan-mai","github.com","chan-mai - Overview","ITなんでも屋さん / Misskeyにいます. chan-mai has 21 repositories available. Follow their code on GitHub.","https://avatars.githubusercontent.com/u/74494945?v=4?s=400","https://github.githubassets.com/favicons/favicon.svg","GENERAL",{"contents":62,"totalCount":78,"offset":32,"limit":31},[63],{"id":64,"createdAt":65,"updatedAt":66,"publishedAt":66,"revisedAt":66,"title":67,"content":68,"tags":69,"is_no_index":30,"summary":77},"3hkti2d82ywg","2025-10-22T08:28:00.344Z","2025-10-22T10:26:32.921Z","生成AIがなんだ","\u003Cp>どうも、わたしです。\u003C/p>\u003Cp>最初に断っておきますが、私は所謂お絵かきの人間ではありません。\u003Cbr>普段は創作とは直接関係のない領域でエンジニアのような業務に携わり、余暇にデザインや映像制作を細々と行う程度です。\u003Cbr>幸いにも有償での依頼や企業案件と呼べる経験も僅かながらありますが、それだけで生計を立てられるほどの技術も影響力も持ち合わせていません。\u003C/p>\u003Cp>そのような中途半端な立ち位置から、昨今の生成AIをめぐる議論を観察していると、その顕著な温度差に一種の戸惑いを覚え、気持ち悪ささえ感じることがあります。\u003Cbr>私自身、現時点では創作活動に生成AIを利用していません。\u003Cbr>技術そのものへの嫌悪感はなく、むしろその技術的側面には強い関心を抱いていますが、利用をためらう主な理由は、SNSなどで散見される、まるで異端審問のような過剰な魔女狩りへの恐れです。\u003Cbr>もし、誰からも後ろ指をさされることのない条件が整うなら、喜んで飛びつくでしょう。\u003C/p>\u003Cp>しかしながら、技術的な仕組みや関連法規、一次資料にあたることなく、「とにかく素晴らしい」「絶対的な悪だ」といった二元論的な主張を声高に叫ぶ人々には、それが推進派であれ反対派であれ、同程度の疲労感を禁じ得ません。\u003Cbr>故に、ここで一度立ち止まり、この技術と自身の距離感について、改めて考えを整理しておこうと思った次第です。\u003C/p>\u003Cp>この議論が著しく複雑化する根本的な要因として、まずAIという用語が指し示す対象範囲の過剰な広さが挙げられます。\u003Cbr>一般に、AIは記号論理に基づくエキスパートシステムから、ニューラルネットワーク、機械学習へと至る多様な技術群の総称です。\u003Cbr>極端な話、工場のラインを制御し、外乱に対して系を安定させるPID制御だって、見方によっては知能の現れだと主張することさえできてしまいます。\u003C/p>\u003Cp>我々が日常的に利用するAmazonのレコンドエンジンやDeepL Translatorは、統計学と機械学習、深層学習技術の結晶です。\u003Cbr>YouTubeの動画推薦アルゴリズムが深層学習に基づいていることはGoogle自身が論文で公表していますし、TwitterもレコンドアルゴリズムをGitHub上で公開しています。\u003Cbr>現在、社会的な注目を集めている生成AIは、これら広範な技術、特に深層学習という基盤の上に位置づけられる、特定の一分野に過ぎません。\u003Cbr>にもかかわらず、「AIは善か悪か」といった問いかけが、どの技術レイヤー、あるいはどの具体的な実装を対象としているのか不明瞭なまま交わされています。\u003Cbr>これでは建設的な対話は望めません。\u003C/p>\u003Cp>そして、このAIという言葉の曖昧さに関連して、私が強い違和感を覚えるのが、主張のダブルスタンダードです。\u003Cbr>我々は、Google検索の最適化された結果に日常的に依存し、Netflixのレコメンドアルゴリズムが提示するコンテンツを享受し、DeepLやPLaMoに甘やかされて生きています。\u003Cbr>これらは狭義の生成AIではないものの、紛れもなくAI技術の恩恵です。\u003C/p>\u003Cp>にもかかわらず、AI反対を唱えながら、その主張の発信にパーソナライズされたSNSを利用し、情報収集にGoogleを用い、海外情報の参照にDeepLやPLaMoを活用するといった状況が平然と観測されます。\u003Cbr>AI技術の恩恵を浴びるだけ浴びておきながら、特定の領域にAIが踏み入った途端、手のひらを返したように拒絶反応を示す態度は、率直に言ってご都合主義が過ぎるのではないかと感じます。\u003Cbr>もし本気でAIという技術概念そのものを拒絶するのであれば、その論理的帰結は、現代社会の利便性の多くを放棄することに他ならないはずです。\u003Cbr>それこそユナボマーのように山中で自給自足の生活を送る覚悟があるというのなら、その主張には一貫性があると言えるかもしれませんが。\u003C/p>\u003Cp>また、AIの学習を単純な盗用と同一視する言説も散見されますが、これも技術的なプロセスへの理解不足から来る感情的な反発に過ぎないように見受けられます。\u003Cbr>もちろん、生成物が既存の著作物と酷似する依拠性の問題は別途、法的に議論されるべきですが、学習データセットから統計的なパターンを抽出する行為そのものを、即座に盗用と呼ぶのは、人間が過去の偉大な作品群から様式や技法を学ぶ行為まで盗用と呼ぶに等しい、あまりにも乱暴なレッテル貼りではないでしょうか。\u003C/p>\u003Cp>では、生成AIのリスク、特に著作権に関する現行の法的枠組みはどうなっているのでしょうか。\u003Cbr>重要なのは、2018年の著作権法改正で導入された柔軟な権利制限規定、とりわけ第30条の4です。\u003Cbr>極めて簡潔に要約すれば、思想又は感情の享受を目的としない利用(情報解析、機械学習用途でのデータ利用等)は、著作権者の利益を不当に害する場合を除き、許諾なく行えるとする規定です。\u003Cbr>AIの学習データ利用は、現時点ではこの条文が主要な法的根拠の一つと解釈されています。\u003Cbr>文化庁は2024年に「AIと著作権に関する考え方」を取りまとめ、学習段階と生成・利用段階に分けて現行法下での解釈と論点を整理しました。\u003C/p>\u003Cp>ただし、これらはあくまで現行法の解釈指針やガイドラインの提示であり、最終的な法的判断は個別の事案における司法判断に委ねられます。\u003Cbr>つまり、法的なグレーゾーンは依然として広範に存在するわけです。\u003C/p>\u003Cp>そして、この著作権の問題において、特に感情的な対立を招きやすいのが二次創作との対比です。\u003Cbr>私自身も所謂オタク文化に親しんでいるため、この論点には慎重にならざるを得ません。\u003Cbr>法律の条文に照らせば、二次創作は二次的著作物に該当し、その創作および利用には、原則として原著作物の権利者の許諾が必要です。\u003Cbr>しかし、現実には広範な二次創作文化が、権利者によるガイドラインの策定や黙認といった、極めてデリケートな均衡の上に成り立っています。\u003Cbr>これは法律上の当然の権利ではありません。\u003C/p>\u003Cp>ここで、AIの学習と二次創作の法的な位置づけを比較すると、現行の日本法下では明確に異なる規律が適用されていることがわかります。\u003Cbr>AI学習は、一定条件下で著作権法第30条の4という権利制限規定の射程内とされる一方、二次創作は原著作者の権利への配慮(許諾または黙認)が前提となります。\u003C/p>\u003Cp>この法的な枠組みの違いを意図的にか、あるいは無理解からか無視して、「AIによる無許諾学習は著作権侵害であり許されないが、自身の行う無許諾の二次創作は文化として許容されるべきだ」と主張することは、法制度上の整合性を著しく欠く議論であると断じざるを得ません。\u003Cbr>自らの二次創作活動が依拠する黙認という極めて不安定な砂上の楼閣には無自覚なまま、法的根拠に基づこうとするAI開発側を泥棒と断じるのは、自己の立場を客観視できていない証左ではないでしょうか。\u003Cbr>必要なのは感情論で法解釈をねじ曲げることではなく、法と運用の筋を通した議論のはずです。\u003C/p>\u003Cp>「AIには魂がない」「人間の努力を愚弄している」といった情緒的な主張も、議論の場においてはノイズでしかありません。\u003Cbr>技術の是非を問う議論において、定義不能な魂の有無や、個人の主観的な努力の感覚を持ち出すことは、論理的な対話を拒否しているのと同じです。\u003C/p>\u003Cp>我々は日常的にAI技術の恩恵を享受しており、その事実を無視して、生成AIのみを特異点として拒絶する態度は、やはり論理的な一貫性を欠いています。\u003Cbr>現代社会において、AI技術との関わりを完全に断つことは非現実的です。\u003Cbr>だからこそ、思考停止に陥ることなく、個別の技術、サービス、運用状況を具体的に評価し、その都度、自身の立ち位置を判断していく必要があります。\u003C/p>\u003Cp>そして最も唾棄すべきは、この種の議論(笑)で見られがちな選民意識ではないでしょうか。\u003Cbr>「わたしの創作は特別だ」「絵師である自分はAIを使う人間や、ただの消費者よりも偉い」。\u003Cbr>このような根拠のない特権意識は、建設的な対話を著しく阻害します。\u003C/p>\u003Cp>我々の多くは、巨大な社会のエコシステムや経済圏の中では、代替可能な構成要素の一つに過ぎず、私を含めほぼ全ての人間はただのコマであることを自覚するべきです。\u003Cbr>自らが(技術によって支えられたプラットフォーム上で)享受している消費者としての側面を棚に上げ、都合よく創造主として振る舞い、特権意識を振りかざす態度は、滑稽ですらあります。\u003Cbr>他者を攻撃し、魔女狩りに興じる前に、まず自身の思考や言動の整合性を取ることに努めるべきだと、わたしは思います。\u003C/p>\u003Cp>結局のところ、我々は日常的にAI技術の恩恵を享受しており、その事実を無視して、生成AIのみを特異点として拒絶する態度は、論理的な一貫性を欠いています。\u003Cbr>現代社会において、AI技術との関わりを完全に断つことは非現実的です。\u003Cbr>もし本気でAIという技術概念そのものが受け入れられないのであれば、その論理的帰結は、現代社会の利便性の全てを放棄することに他なりません。\u003Cbr>それこそGoogleもSNSも使わず、ユナボマーのように山中で文明と隔絶した生活を送る覚悟でもない限り、その主張は単なる自己矛盾であり、稚拙で傲慢な子供の主張と何ら変わりはないでしょう。\u003C/p>\u003Cp>あ、私はAI推進派でも反対派でもありませんよ。悪しからず。\u003C/p>",[70,76],{"id":71,"createdAt":72,"updatedAt":73,"publishedAt":72,"revisedAt":73,"slug":74,"name":75},"wia4slp55q","2025-04-28T07:14:14.541Z","2025-12-03T16:08:13.798Z","thoughts","独り言",{"id":19,"createdAt":20,"updatedAt":21,"publishedAt":20,"revisedAt":21,"slug":22,"name":23},"どうも、わたしです。最初に断っておきますが、私は所謂お絵かきの人間ではありません。普段は創作とは直接関係のない領域でエンジニアのような業務に携わり、余暇にデザインや映像制作を細々と行う程度です。幸いにも有償での依頼や企業案件と呼べる経験も僅かながらありますが、それだけで生計を立てられるほどの技術も影",33,1783975277751]