[{"data":1,"prerenderedAt":77},["ShallowReactive",2],{"article-svgkndwg3ng9":3,"prev-article-svgkndwg3ng9":34,"next-article-svgkndwg3ng9":51,"$f1cEi-3K5CzztKR-MWnUQGhJ52XJW4Arz4UyKrviiry8":69},{"contents":4,"totalCount":32,"offset":33,"limit":32},[5],{"id":6,"createdAt":7,"updatedAt":8,"publishedAt":9,"revisedAt":8,"title":10,"content":11,"tags":12,"is_no_index":31},"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>",[13,19,25],{"id":14,"createdAt":15,"updatedAt":16,"publishedAt":15,"revisedAt":16,"slug":17,"name":18},"qfey3yw0z1","2025-04-29T08:44:41.687Z","2025-12-03T16:07:14.622Z","technology","テクノロジー",{"id":20,"createdAt":21,"updatedAt":22,"publishedAt":21,"revisedAt":22,"slug":23,"name":24},"fwj_nwhj1-s","2025-04-30T04:55:28.953Z","2025-12-03T16:07:03.591Z","server","サーバー",{"id":26,"createdAt":27,"updatedAt":28,"publishedAt":27,"revisedAt":28,"slug":29,"name":30},"4oy2jc8mdg","2025-04-28T07:14:01.179Z","2025-12-03T16:08:24.495Z","diary","日記",false,1,0,{"contents":35,"totalCount":50,"offset":33,"limit":32},[36],{"id":37,"createdAt":38,"updatedAt":39,"publishedAt":39,"revisedAt":39,"title":40,"content":41,"tags":42,"is_no_index":31,"summary":49},"5uoungfiv","2025-09-19T18:00:20.644Z","2025-09-19T18:08:37.327Z","正しさの主張","\u003Cp>お久しぶりです。\u003C/p>\u003Cp>最近、目を背けたい事実に直面することがありました。\u003Cbr>きっかけは、過去に自分が書いた、あるコミュニティについて論じた文章を偶然読み返したことです。\u003Cbr>そこには、特定の人物像に対し、その行動原理を半ば断罪するかのように書き連ねる、傲慢な自分がいました。\u003Cbr>そして、最も衝撃的だったのは、その批判の矛先が、現在の自分自身に正確に突き刺さることでした。\u003C/p>\u003Cp>過去の文章で私が問題視\u003Cs>(あるいは敵視)\u003C/s>していたのは、他責的で、他者への要求がましく、常に自分は被害者であるという立場から世界を語る人々でした。\u003C/p>\u003Cp>しかし、今の私はどうでしょう。\u003Cbr>日々の生活の中で、自分の思い通りにならないことがあると、すぐに他者や環境のせいにしてはいないか。\u003Cbr>自分の苦境を理解し、手を差し伸べるのが当然であるかのように、周囲に期待してはいないか。\u003Cbr>心当たりのある節は、枚挙にいとまがありません。\u003Cbr>自分がいかに他人に対して要求がましく、不平不満を募らせているかに気づいてしまいました。\u003Cbr>誰かが自分の期待通りに動いてくれないと苛立ちを覚えたり、自分の苦境を理解してくれない社会や他者に対して、心の中で攻撃的な言葉を並べたりする。\u003Cbr>その姿は、私がかつて記事の中で批判的に描写した人物像と、驚くほど酷似していました。\u003C/p>\u003Cp>私がコミュニティの中に見ていた問題点は、全くの他人事などではなく、何を隠そう、私自身の内面にある課題を投影したものであったのだと。\u003Cbr>これはまさしく同族嫌悪です。\u003Cbr>自分の中にある、認めたくはない醜い部分。\u003Cbr>それと同じものを他者の中に見つけ出し、批判することで、あたかも自分だけは違うのだと安心しようとする、卑劣な防衛機制でした。\u003C/p>\u003Cp>以前の記事でも言及した気がしますが、「誰も私を助けてくれない」という嘆きは、いつしか「だからあなたは私を助けるべきだ」という、他者への一方的な要求に変わってしまう。\u003Cbr>というか変わってしまった。\u003Cbr>他者の時間や感情を際限なく奪うための、万能の呪文を私は覚えてしまった。\u003Cbr>私も立派な化け物だったみたいです。笑ってください。\u003C/p>\u003Cp>完全な被害者であるという認識は、一種の安全圏として機能します。\u003Cbr>自分は傷つけられた側であり、悪くない。\u003Cbr>故に、他者からの配慮や支援を要求する権利がある。\u003Cbr>この論理は、一見すると正当なものに思えますが、容易に肥大化し、「自分は常に正しく、周囲が間違っている」という歪んだ特権意識へと変わります。\u003Cbr>この立場に安住する限り、自分自身の問題と向き合う必要がありません。\u003Cbr>全ての原因を外部に押し付け、自分は変わらずに済むからです。\u003Cbr>傲慢ですね。\u003C/p>\u003Cp>「誰も助けてくれない」という嘆きは、この被害者意識と結びつくことで、容易に他者への攻撃性へと変質します。\u003C/p>\u003Cp>自分の価値を他者からの承認に依存していると、期待通りの反応が返ってこないだけで、自分の存在が根底から否定されたかのような感覚に陥ってしまいます。(しまいました)\u003Cbr>すると、助けてくれなかった相手は、単なる「期待に応えなかった人」から、「自分を否定し、傷つけた加害者」へと認識がすり替わります。\u003Cbr>こうして、本来であれば内省に向けられるべき体力が、他者への攻撃という最も安直な形で発散されてしまうのです。\u003Cbr>私自身、ほんとに心当たりしかなくてびっくりします。\u003C/p>\u003Cp>私がかつて批判した彼ら彼女らの傲慢で横暴な姿は、すでになっていた自分自身の姿だったみたいです。\u003C/p>",[43],{"id":44,"createdAt":45,"updatedAt":46,"publishedAt":45,"revisedAt":46,"slug":47,"name":48},"wia4slp55q","2025-04-28T07:14:14.541Z","2025-12-03T16:08:13.798Z","thoughts","独り言","お久しぶりです。最近、目を背けたい事実に直面することがありました。きっかけは、過去に自分が書いた、あるコミュニティについて論じた文章を偶然読み返したことです。そこには、特定の人物像に対し、その行動原理を半ば断罪するかのように書き連ねる、傲慢な自分がいました。そして、最も衝撃的だったのは、その批判の矛",34,{"contents":52,"totalCount":50,"offset":33,"limit":32},[53],{"id":54,"createdAt":55,"updatedAt":56,"publishedAt":56,"revisedAt":56,"title":57,"content":58,"tags":59,"is_no_index":31,"summary":68},"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>",[60,61,62],{"id":26,"createdAt":27,"updatedAt":28,"publishedAt":27,"revisedAt":28,"slug":29,"name":30},{"id":14,"createdAt":15,"updatedAt":16,"publishedAt":15,"revisedAt":16,"slug":17,"name":18},{"id":63,"createdAt":64,"updatedAt":65,"publishedAt":64,"revisedAt":65,"slug":66,"name":67},"8q8qyy8sz3","2025-04-29T08:44:23.406Z","2025-12-03T16:07:24.495Z","programming","プログラミング","はじめにどうも、わたしです。先日、このサイトにいくつかの変更を加えました。 元々は、壁打ちブログのつもりで運営していたのですが、承認欲求がとうとう無視できない大きさになってしまいまして。 ちなみに、ここで話すソースコードは全てGitHub上に公開しているので、もし気になる人がいれば、読んでみてもらえ",{"url":70,"domain":71,"title":72,"description":73,"image":74,"favicon":75,"type":76},"https://github.com/lqvp/hme_bridge","github.com","GitHub - lqvp/hme_bridge","Contribute to lqvp/hme_bridge development by creating an account on GitHub.","https://opengraph.githubassets.com/794b50f67986542e19e8cf4cdff652d45adf715c80fcdf76f22c0f517b408325/lqvp/hme_bridge","https://github.githubassets.com/favicons/favicon.svg","GENERAL",1783975277757]