著者: MoeJue(xxx@example.com)

続き：《同じアニメーション、3つの技術スタックで実装したらどう違うの？》

WebGL による二次元じゃんけんゲーム。

ルールは普通：

• グー > チョキ
• チョキ > パー
• パー > グー

でも面白いのはここ：

負けると服を脱ぐ。

ええ、それだけです。単純かつストレート。

きっかけは「スプライトシートを研究したかった」

最初はゲームを作るつもりなんてなかった。
ただ研究したかっただけ：

• atlas
• sprite
• レイヤー合成
• アニメーションカット

こんな技術要素。
それで考えたんです：「実際に使える場面がないと？」

そして思い付き：

じゃあ、二次元脱衣じゃんけんにすればいいと。

そしたらプロジェクトが暴走し始めた。

このプロジェクトで一番大変だったのはゲームロジックじゃない

じゃんけんのルールはシンプルすぎる。
本当に大変だったのは：服のレイヤー管理
キャラクターは「1枚の完成した画像」ではなく：

• ベース画像 (全裸バレ防止のため、わざと暗号化済み)
• 服 A
• 服 B
• 服 C
• アクセサリー
• 遮蔽レイヤー

重ね続ける。

「脱衣」の正体はレイヤー管理

プレイヤーが勝った：

• 設定された順番で服を1枚除去

コンピュータが勝った：

• 逆順で服を着せる

聞こえるのは簡単。
実際は山のような問題にぶつかる：

例えば「ベース画像が一瞬見えてはいけない」

これは特に重要。
もしこうすると：

古い服を先に消す
新しい服を後で追加する

その一瞬ベース画像がチラ見えする。
見た目がすごく変になる。
なので後で：reveal カバーロジックを使うことにした。

新しいレイヤーが即座に上に被さる。
極力避けたい：

「裸が1フレーム映り込む」

この記事は2026-06-13に阿珏酱のBlogで公開され、最終更新日は2026-06-13です

著者: MoeJue(xxx@example.com)

最近、なかなか面白い小実験をやってみました。
二次元キャラクターのちょっとしたアニメーション効果を、それぞれ：

• WebGL
• Canvas 2D
• 純 DOM + CSS

の3つの方法で実装し直しました。
効果自体は複雑ではありません：

• まばたき
• 眉毛/下まぶたの連動
• 汗のゆらゆらした揺れ
• アホ毛の振り動き

でも本当に面白いのは、「作れた」こと自体ではなく：

同じものを、3つの技術スタックで実装したとき、どれくらい差が出るのか？

というところです。
本質的には「フロントエンドグラフィクス色の濃い」再現実験でした。

最初はただアホ毛アニメーションを再現したかった

インスピレーション元：https://tamanidamani.itch.io/nijikas-ahoge
当時のシンプルな思い：「自分だったらどう実装する？」
そしてやるほどに熱中してしまい、最終的にこうなりました：

じゃあ、WebGL、Canvas2D、DOM の3パターン全部作ってみよう。

そうしてリポジトリは今の形になりました：

• canvas/
• canvas2D/
• dom/

同じ効果を3つのバージョンで実装しています。

まず結論

一言でまとめるなら：

WebGL が最強だけど、Canvas2D が一番書きやすくて、DOM がビジネス向け

1. WebGL バージョン：「本当のゲーム開発」に一番近い

このバージョンが一番手間がかかります。
なぜなら本質的には「フロントエンドアニメーション」ではなく：GPU グラフィクスプログラミング だからです。

どう実装しているのか？

コアとなる考え方は：

• 背景レイヤー1枚
• スプライトを重ねていく
• shader で描画制御
• JS でアニメーションパラメータを動かす

例えば：

• アホ毛の回転
• まばたきの切り抜き
• alpha ブレンド

これらはすべて GPU 側で処理されます。
だんだんとこういうものに触れるようになります：

• uniform
• texture
• shader
• UV
• 頂点座標
• テクスチャ座標

そして笑顔が消えていきます。

この記事は2026-05-29に阿珏酱のBlogで公開され、最終更新日は2026-05-29です

著者: MoeJue(xxx@example.com)

最近、コードを書くときに奇妙な感覚がある。

書けないわけでもなく、書きたくないわけでもない。
だが——
自分の書くことがどんどん不要になっているような気がする。

かつては、機能を実装する際の流れはこうだった。

要件を理解する → 設計を考える → コードを書く → デバッグ → バグ修正 → リリース

今はどうなっている？

要件を説明する → AIがコードを書く → AIがバグを直す → 確認するだけ → リリース

その間にあった「コードを書く」という大きな部分が、突然薄くなり、ほぼ存在しなくなる。

最初はそれがすごく楽だった。
だが、楽しくなるにつれて少し不安になる。

かつてのプログラマーは、「タスクを完了する」ことで得られる達成感に加え、コードを書く過程そのものにも多くの喜びを感じていた。

コードを書くことって、もはや重要じゃない？

かつて私はプログラマーの最も核となる能力は「コードを書くこと」だと思っていた。

速さ、美しさ、抽象化の度合い——これらが「レベル」の差を作っていた。

だが、今ではこの基準がだんだん通用しなくなってきている。

多くのコードは、人間よりAIの方が早く、あるいは同じくらい良く書ける。

特に以下のようなもの：

• CRUD
• API連携
• 通常のロジック処理

AIは圧倒的な効率でこなしてしまう。

時々自分で書いたコードをAIに投げるようになる。

「ちょっと見直して」

すると、単に改善されただけでなく、自分が気づかなかったケースまで補ってくれる。

その瞬間、微妙な違和感がある——
このコード、誰が書いたのか区別できない。

さらに奇妙なのは、自分で書くのをやめてしまうこと

これが本当に危険だ。

かつてはコードを書くことは「制御感」だった。

一行一行自分が打ったし、なぜそう書いたのか理解していたし、どこに問題があるかも把握していた。

だが、AIに任せることに慣れてくると、自分で書くことが逆に遅くなることに気づく。

そしてこう感じるようになる：

「なぜ自分で書かなきゃいけないのか？」

これは怠惰ではなく、効率の自然な選択だ。

大きな整数を手計算しないように、自動で生成できるコードを自分で書く必要もなくなる。

プログラマーは、別の役割へと変貌している

だんだんと毎日の業務内容が変わってきていることに気づく。

もはや：

• どれだけコードを書くか
• どんなデザインパターンを使うか
• コードがきれいかどうか

ではなく、

• この要件は何をしたいのか？
• AIにどう伝えると誤解されないか？
• 結果は正しいか？

ということに時間を費やすようになる。

この記事は2026-05-05に阿珏酱のBlogで公開され、最終更新日は2026-05-05です

著者: MoeJue(xxx@example.com)

この件はドラマのような展開に聞こえるかもしれないけど、実際に起きたことだよ。
私自身、懐古主義だからね。

家庭の事情で、あの土地を離れてからはずっとそこにいられなくなった。幼馴染みみたいなものは、自分には曖昧な存在だったんだ。だからこそ、幼い頃から付き合って感情が深まった人たちを羨ましく思う。

大人になってからは、ずっと漂っているような気がした。習慣的に先に立って、友達を置いていく。

でも、その一言だけは——
「戻るよ」

信じられないくらい、二十年待った。

誰も本当に待ってくれるとは限らないことはわかっていた。
でも、それでもこの約束は心の中でひとつの執念になっていた。

帰ってくると、昔のことがすぐに頭に浮かぶと思った。
でも、実際にそこに立ってみると、記憶はぼんやりとしていた——
忘れたからか、それとももう物事は人も変わってしまっているからか。

二十年後にまたそこに立つとは、これまで一度も考えたことがなかった。
二十年前の自分も、未来の自分がまたそこに戻ってくるとは、決して想像できなかっただろう。

その瞬間、タイムスリップしたような不思議な感覚があった。
ふと、もし違う次元から見てみたら、二十年前の自分と今の自分が同じ時間に重なっているのではないかと考えてしまう。

この旅は、一人旅だった。

写真はスマホで勝手に撮ったものだ。歩きながら撮って、少し揺れてる。
自分が孤独に見えないように、写真に誰かを合成してしまった。

昔の運動場は、子供の私にとっては大きすぎて不思議だった。
夜になると、たくさんの人がダンスをする。
一番身近だったのは『月の上』と『最炫民族風』。当時はとても賑やかだった。

人間が10年以上いない街の様子を見せてあげる

あの日、私は紅領巾を着けた。
小学5・6年生の兄姉たちが結んでくれた。それは少先隊員になる瞬間だった。

あの映画館は、一度も入ったことがなかった。
でも、今では屋根が完全に崩壊してしまっている。

実は来る前から衛星地図で学校の様子を見ていた。
学校はすでに姿を変えていた。

運動場は平らげられ、玄関さえ見つからない。
記憶の中の姿とは全く違う。椅子はほとんど撤去されてしまっている。

知らない教室も多くあった——
標本室、図書館、器材室…。当時の教科書には「本教科書は国家無償提供」と書かれていた。
古びた値日表にも昔馴染みの名前が残っていた。なぜか、長い間そこにあるのか不思議だった。

これは、小さい頃に学校で映画を見ていた教室。
当時はとても広く感じて、男の子たちは最後の方に隠れていた。暗闇の中だった。

この木も同じだ。
小さい頃は太さが股下くらいで、背丈は私より少し高かった。
今では、大木になっている。

こんにちは、古い友達。
また戻ってきたよ。

昔の品々を見せてあげる。何個認識できるかな？

道は空っぽで、草むらが生い茂り、路面は破損している。

小さい頃は、列車の車両に乗り、ゆっくりと進む列車に乗っかっていた。

私は、かつての家、学校、そしてクラスメートの家の近くにも戻ってきた。

意外な発見があると思っていた。

例えば、旧友と再会する。

でも、現実は想像より冷静だった——
当時は携帯電話もコンピューターもなく、お互いの連絡先さえ残していなかった。

久しぶりに残っている携帯番号を見つけて、WeChatに追加した。
結果、初日に追加された翌日に削除された。
電話をかけた。最初は誰も出なかった。
二回目には、結果が予想できていた——
確かに、ブロックされた。

小さい頃は、ここが男の子女の子が裸足で跳び縄をする場所だった。

でも、今では壁で塞がれていて、入れない場所も多い。
当時、「戻るよ」と言った階段を撮影したいと思っていた。

この記事は2026-04-17に阿珏酱のBlogで公開され、最終更新日は2026-04-17です

著者: MoeJue(xxx@example.com)

4月のこの件、おそらくは桜から始まった。

そして、そのアニメ『四月は君の嘘』からだ。

ある時は、作品によって定義されるものなんだ。

今も、4月になると、あのセリフを思い出さずにはいられない。

「4月は、君の嘘。」

ある日、ふと顔を上げたら、普段気にも留めていなかった路地の木が、すでにピンク色に満ちていた。

📷 アニメの世界から降りてきたような背中

その日は、前を歩いている二人の姿に気づいただけだった——

金髪と黒髪、制服、スカート、セーター、桜の下を歩くその背中は、一瞬、本当にアニメのキャラクターが現実に落ちてきたみたいだった。

その瞬間、少し目眩がした。
現実が一瞬、二次元になったような。

あのアニメを見ているとき、よくこう思う。

「このようなシーンが現実にあったら、どんな感じだろう？」

🎹 4月、音楽で覚えられる

『四月は君の嘘』では、4月はただの月ではない。

始まりであり、終わりでもある。

再会であり、変化でもあり、別れでもある。

物語にはクラシック音楽が溢れていて、ショパンの『叙事曲第一番』みたいな曲には、言葉にできないほどの感情が込められている——

優しいけれど不安定。
明るいけれど、少しだけ痛みを秘めている。

それはまるで4月そのもののように。

🌸 桜はなぜ、少しだけ苦しい気持ちになるのか？

桜自体は特別なものではない。

でも、咲きすぎて短すぎる。

「春が来た！」と気づいた瞬間、すでに終わりを迎えている。

あのアニメと同じだ。

物語がまだ始まったばかりに思えるのに、
不知不覚にも終盤へ向かっていく。

桜の花は通常、1週間ほどで終わる。

風が吹けば、散ってしまう。

何か残す暇もなく、すでに記憶になってしまう。

🧃 4月、ちょうど良いタイミングで終わる時間

4月は不思議な月だ。

不安定でも、確かに存在する。

普段気にも留めないものに目を向けやすくなる。例えば：

• 路地の木
• 人の背中
• 風の音
• あるいは、一曲の音

ただ前を歩いている人を見ても、物語を想像してしまう。

あの日の二人の背中もそうだ。

彼らは何者でもなかったかもしれない。
でも、その瞬間——

物語の冒頭にそっくりだった。

📝 最後に

ときどき、こう感じる。

桜を好むのは、
どれほど美しいからではない。

それは、何かと似ているからだ。

短く、力強く、そして終わる。

『四月は君の嘘』が語る通りだ。

感情は、その時は言葉にできないこともある。
でも、過ぎ去ってしまえば、二度と戻らない。

この記事は2026-04-06に阿珏酱のBlogで公開され、最終更新日は2026-04-06です

著者: MoeJue(xxx@example.com)

先週の土曜日、二次元風の小さなお店「夜雀小屋」に行ってきました。

実は以前からこの場所を見てたんですけど、公園の中にあるようなちょっと珍しい拠点という感じで、東方Projectや二次元好きにはなるほど懐かしいと思える場所だったんです。週末に空いたので、それで気になって行ってみたんです。

中に入って最初に感じたのは、
想像以上に「濃度が高い」ってこと。

玄関からすでに雰囲気が出てる

まだ入ってない状態でも、このお店の趣向がわかるんです。

大きな魔理沙のぬいぐるみが置いてあって、座ってて落ち着いてる感じで、まるで「見張り」のようにしてるみたい。

正直、初めて見たときはちょっとびっくりしましたね。このサイズのぬいぐるみを玄関に置くのは少し衝撃的です。

そして「冷静な表情だけど少し呆れてる」みたいな感じが、魔理沙らしいというか、ちょうどよいです。

とっても大きい魔理沙

何と言っても、これは一種のチェックポイントみたいなものです。

店内の陳列棚は「信仰陳列」そのもの

中に入ると、一番目についたのはガラスケースの陳列棚。

手元、CD、そして東方周辺のグッズなどが並んでて、全部そこら中に散らばってるわけじゃなくて、ちゃんと一列に並べてる感じがします。

一番大きい手元は特に目立ってて、作りも細部まで丁寧で、ライトが当たってると全体の雰囲気が強く出ます。

壁一面の収納は小さなミュージアムみたい

また、壁一面に木製の収納棚があり、そこには色々なものが詰め込まれています。

例えば：

• 東方キャラクターのぬいぐるみ
• 小さなフィギュア
• 小物類
• 同人グッズ

全部合わせて、長年の趣味を全部展示してるみたいな感じです。

真ん中あたりに芙蘭の立ち絵が置いてあって、かなり目立ってます。

全部見て回ると、途中で知ってるキャラが突然隅に出てくるみたいな感じで、ちょっと面白いです。

まるで古いオタクの収納棚を開けてみるみたいな感じです。

全体の雰囲気は意外とリラックス

行ったのは土曜日の昼過ぎで、人もそこそこいました。

全体の雰囲気は静かで、ライトも柔らかい感じ。

商業的な感じではなくて、むしろ友達同士で集まる拠点みたいな感じです。

例えば：

• 小さな二次元拠点
• 同好の集まり
• あるいは「オタクの居心地の良い部屋」みたいな感じ

東方プレイヤーでも、普段から二次元の世界にいる人なら、こんな場所に来るとちょっと微妙な懐かしさを感じると思います。

多くの飾りつけは、
**「営業用に飾ってるわけじゃなくて、本当に好きだから飾ってる」**っていうことが伝わってきます。

ちょっとした感想

こういうお店はもうあまり見かけなくなってきてるんじゃないかと思います。

多くの二次元のお店は、もう商業化されてて、カフェかグッズショップみたいな感じになってるんです。

でも夜雀小屋は、むしろこういう感じ：

**「自分の趣味を空間にしてしまった人がいる」**っていう感じです。

中に入って回って、飾り付けを眺めてみるだけでも、ちょっと面白いです。

私にとっては、ちょっと面白い発見だったかな。

この記事は2026-03-17に阿珏酱のBlogで公開され、最終更新日は2026-03-17です

著者: MoeJue(xxx@example.com)

🎉 新しい達成感
最近、自分のカメラ機器をアップグレードしました。使っていた Canon EOS 60D から Canon EOS R50 に交換しました。

2010年のクラシックな中堅DSLRと、2023年のエントリーレベルのミラーレスカメラ。両方とも十数年もの技術の差があり、今のミラーレスカメラがどんな感じか試してみたかったんです。

一、私の初めてのDSLR：Canon EOS 60D

Canon EOS 60Dは、多くの写真愛好家がかつて「夢の機種」と呼んだモデルでした。

当時、購入した理由は主に以下の通りです：

• 握りやすく、操作性が良い
• プロ仕様の操作感がある
• 7Dよりも価格が手頃
• EFレンズが豊富に利用可能

当時は、60Dが「プロっぽい」と感じていました。本体が大きく、ボタンも多く、写真家が使っているようなカメラに見えました（笑）。

60Dの最大の特徴は、実は 信頼性と耐久性 でした：

• バッテリーが非常に持ちが良く、1本で長時間撮影可能
• 本体がしっかりしており、手に持つと「カメラらしい」重厚感があります
• 光学ビューファインダーを使うと、撮影に儀式感があります

しかし、時間が経つにつれて、60Dのいくつかの欠点も気づくようになりました：

• フォーカスポイントがわずか9点
• フォーカス速度が遅い
• 動画は1080pのみ
• 本体が重い

特にスマートフォンや新しいカメラが急速に進化している今、この古いDSLRは少し「時代遅れ」に感じるようになりました。

二、なぜR50を選んだのか

アップグレードを検討する際、私はたくさんの機種を比較しました。例えば：

• R100
• R5
• ソニーやニコン

最終的に R50 を選んだ理由はシンプルです：

1. 価格が比較的リーズナブル
2. 本体が非常に軽い
3. 自動フォーカスが高性能
4. 4K動画対応

R50は、非常に典型的な エントリーレベルのミラーレスカメラ ですが、技術はよりハイエンドな機種から引き継がれています。

三、DSLRからミラーレスへの変化

R50を手に取った瞬間の感覚は：

本当に軽くて小さい。 まるでプラスチック製のような安っぽさがあり、手の小さな女性にも向いているかもしれない。

60Dは約 755g でしたが、R50はわずか 375g。ほぼ半分の重さです。

以前は60Dを1日歩き回ると、どうしても肩が少し凝ります。
今はR50ならどこにでも持ち歩いても、ほとんど感じません。

この記事は2026-03-07に阿珏酱のBlogで公開され、最終更新日は2026-03-07です

著者: MoeJue(xxx@example.com)

《ATRI -My Dear Moments-》を見終わってもう大半年経ったんだけど、
最近コミュでATRIの顔文字が急に増えてきて、また思い出に引き込まれた。

@九日さんに勧めてみたら、見てゲームもプレイしてくれた。

「かわいいロボット×日常癒し」みたいな軽めのアニメだと思ってたんだけど、
見てるうちに——
なんか胸がちょっと締め付けられるようになった？

🌊 世界観：終末＋海水面上昇、だがゴーストタウン風ではない

舞台設定は意外と残酷：
未来、海面上昇で都市がほとんど水没してしまう。
でも作品のイラストは、陰鬱なゴーストタウン風じゃなくて——
陽気な空、青空、廃墟となった街並み、水面の反射、静かな小さな町。

このギャップがすごく効いてる：
世界は半分壊れてるけど、生活は続いてる。

🤖 ATRI（アトリ）ってキャラ（ロボ子さん）、めっちゃ犯されキャラ

ATRIは高性能なシンセサイザルボットだけど、
「冷たい家政婦型AI」じゃなくて、

• ちょっと毒舌
• ちょっと天然
• 感情がリアルで泣いたりする
• むしろ人間より「人間らしい」

軽口を叩くことも多いけど、それをじっくり考えると、
実はそれが刺さるような言葉だったりする。
そして**「時間がないのに、何かを残そうと必死になる」その気持ち**、
本当に心を刺す。

一言で言うと：
👉 彼女はかわいさのためのキャラクターじゃない。この作品の魂だ。

🧑 主人公は王道のハマりキャラじゃないけど、リアル

主人公は勝ち組の王道ハマりキャラじゃなくて、
むしろ：

• ちょっと消極的
• ちょっと現実逃避
• 未来にもほとんど希望なし
  

だからこそ、ATRIとの関係が特にリアルに感じられる。
世界を失った人間が、もうすぐ終わりの訪れる存在に出会い、
二人でお互いを引きずり合いながらも支え合う——
そんな関係が、「世界を救う」よりも胸を締める。

感想

この作品の最も痛いところは、
大きな刃で切り裂くのではなく、
ずっとあなたに——
「素晴らしい時間は、本来有限だ」
と言い続けてくること。

あなたはもうその結末を知ってるのに、
途中で些細な日常の一瞬を貪りたくなる。
本当に終わってみて初めて気づく：
「失う」ことが悲しいのではなく、
**「その日常はもう戻らない」**ことが悲しい。

「記憶」

もし存在が終わるなら、何を残せば「存在した」と言える？
データ？記録？それとも誰かの記憶？

この記事は2026-02-07に阿珏酱のBlogで公開され、最終更新日は2026-02-07です

著者: MoeJue(xxx@example.com)

これは100%分散型のブロックチェーンお年玉（レッドパケット）アプリケーションです。ユーザーはウォレットを接続し、金額と数量を設定してお年玉を送信し、リンクを通じて他の人と共有して受け取ることができます。すべてのデータと操作はブロックチェーンに基づいており、中央集権型サーバーは一切不要で、プロセス全体が安全、透明、追跡可能です。

興味があれば、GitHubで私のコードをご覧ください：redpacket‑dapp

機能ハイライト

• 🧧 お年玉の送信: ウォレットを接続後、金額と数量を設定してブロックチェーンにお年玉を送信します。
• 🎁 お年玉の受け取り: 共有リンクを通じて、他の人はウォレットを接続してブロックチェーンから直接お年玉を受け取ることができます。
• 🔗 スマートコントラクト: Solidityで書かれた安全なスマートコントラクトがすべてのロジックを処理します。
• 🌐 マルチチェーン対応: ローカルテストネットとBSCテストネットをサポートします。
• 💼 Web3統合: MetaMaskウォレットを使用して接続します。
• 🚀 完全分散型: バックエンドサーバーがなく、すべてのデータはブロックチェーンに保存されます。

技術スタック

• フロントエンド：React 19、React Router 6、TypeScript、Vite、Ethers v6
• コントラクト層：Hardhat、Solidity 0.8.x
• ツール：ESLint、Prettier
• バックエンド不要: サーバーへの依存なし ❌

クイックスタート

# 1. プロジェクトの依存関係をインストール
npm install
cd react-dapp && npm install && cd ..

# 2. ローカルブロックチェーンノードを起動
npm run node

# 3. スマートコントラクトをコンパイル
npx hardhat compile

# 4. スマートコントラクトをデプロイ
npm run deploy

# 5. フロントエンドを起動
npm run frontend

ディレクトリ構造

redpacket-web3/
├─ contracts/                # Solidity スマートコントラクト
│  └─ RedPacket.sol
├─ react-dapp/               # React + Vite フロントエンド
│  ├─ src/
│  │  ├─ components/         # 共通コンポーネント（ウォレットボタン、作成フォームなど）
│  │  ├─ config/             # ABI、コントラクトアドレス設定
│  │  ├─ hooks/              # カスタムフック（useWallet）
│  │  ├─ pages/              # ページ（Home、ClaimPacket）
│  │  ├─ styles/             # グローバルスタイル
│  │  ├─ utils/              # Web3 ユーティリティ関数
│  │  └─ App.tsx             # ルーティングとレイアウト
│  ├─ .env.example           # フロントエンドに必要な環境変数説明
│  └─ package.json
├─ scripts/
│  └─ deploy.js              # Hardhat デプロイスクリプト（自動的にフロントエンド設定に書き込みます）
├─ hardhat.config.js
└─ package.json              # ルートディレクトリのスクリプト（Hardhat + フロントエンドをワンクリックで起動）

使用ガイド

お年玉の作成

1. フロントエンドを開き、右上の「ウォレットを接続」をクリックします。
2. お年玉の総額と個数を入力すると、アプリケーションがフロントエンドで金額をランダムに分割します。
3. 送信後、MetaMaskでトランザクションを確認し、ブロックの承認を待ちます。
4. 成功後、システムが生成した受け取りリンクをコピーして友人と共有できます。

お年玉の受け取り

1. 共有リンク（URLに /claim/{packetId} が含まれる）を開きます。
2. 同様にまずウォレットを接続し、「クリックして受け取る」をクリックします。
3. 署名確認後、ブロックのパッケージングを待ち、ページに結果と残り個数が表示されます。

環境変数

• dapp/.env（開発環境では自動的に無視されます。.env.exampleを参照してください）
  • VITE_RPC_URL：フロントエンドが直接接続するノードRPC、デフォルトは http://127.0.0.1:8545
  • VITE_CONTRACT_ADDRESS：デプロイスクリプトによって書き込まれたアドレスを上書きできます。
  • VITE_CHAIN_ID：フロントエンドが使用するチェーンID（16進数）
• root/.env：Hardhatで秘密鍵やBSC RPCを参照する必要がある場合は、既存の記述をそのまま使用できます。

スマートコントラクト（RedPacket.sol）

コアメソッド：

この記事は2026-01-10に阿珏酱のBlogで公開され、最終更新日は2026-01-10です

著者: MoeJue(xxx@example.com)

いつの間にか、2025年も過ぎ去りました。 ブログのタイムラインを振り返ってみると、なんと今年もたくさんの記事を書いていたことに気づきました。 多くの場合、「思いついたことを書く」というスタイルでしたが、振り返ってみると、どの記事もこの1年の状態をかなりリアルに記録していました。

この記事は、自分自身へ、そしていつもブログを見に来てくださる皆さんへの年末のご報告とさせていただきます。

この一年、ブログは何を書いた？

2025年のブログ内容をいくつかのキーワードでまとめると、おそらくこうなります。

技術的な試行錯誤 + 二次元 + 日常エッセイ

技術関連、やはりたくさん書いた

今年のブログでは、技術系のコンテンツが依然として大きな割合を占めており、毎年多くのプロジェクトについて書いています。 主な内容は以下の通りです。

• ブログの国際化自動化ソリューションの実装
• 現在、web3ブロックチェーンの小さなプロジェクトも書いていますが、まだ公開していません。
• MoeKoe Musicも1年以上メンテナンスしており、累計50以上のバージョンをリリースしました。
• ツール系、個人的なファン向けの大小さまざまなプロジェクト
• 少しハードウェア関連の小さなもの

二次元 & 観後感、楽しく書けた

今年は二次元関連のコンテンツもたくさん書きました。例えば：

• 某アニメ/ソシャゲのフィギュア開封
• 特定のキャラクターやシーンに対する個人的な解釈、視聴後の雑感
• 見終わった後に「何か言わずにはいられない」という感想

『狼と香辛料』のような作品は、書いているときに本当に感情移入して、一行ごとに涙がこぼれました。 このような記事は通常、「専門的に分析する」ためではなく、むしろ：

「この展開は心に刺さった、記録しておきたい。」

ブログについて

• 来年、ブログ開設10周年記念日を迎えます。その際には、サプライズイベントを予定しています。
• 今年は私もプログラミング経験10年のフルスタックエンジニアになりました。
• 昨年同時期にリリースしたMoeKoe Musicは、今年4.5Kスターを達成しました。
• ついにブログの国際化ソリューションも導入しました。
• ブログ界の知人の多くは、年に一度しか更新しないブロガーになってしまいました。

時には記事が長くなく、体系的でなくても、一つの問題を解決したり、一つの考えを表現したりしただけで、残す価値があるのです。

そして、書けば書くほど気づくのは：

ブログの最大の価値は、実は未来の自分が見るためだということです。

この一年、できなかったこともあった

もちろん、すべての計画が完了したわけではありません。

• シリーズとして書きたかった内容も、結局1、2記事しか書けませんでした。
• いくつか掘った穴も、埋められませんでした。
• たまに怠けて、更新が遅れたり、しばらく書きたくなくなったりすることもありました。

でも、今はもう割り切っています。 ブログはKPIでもタスクリストでもありません。書き続けること自体が、多くの「計画」に勝っているのですから。

2026年への小さな期待

特に壮大な目標を立てるわけではなく、いくつか簡単に述べます。

• ブログを書く習慣を続ける
• 技術コンテンツは実践的で、薄っぺらくないものにする
• 二次元や個人的な感想は、書きたいときに書く
• ブログはあくまでブログであり、ストレス源にしない

もし、いつか書いた内容が、 たまたま誰かの役に立ったり、「ああ、私も同じ気持ちだ」と感じてもらえたりしたら、それだけで十分価値があります。

最後に

2025年のブログは、おそらくこんな感じでした。

この記事は2026-01-01に阿珏酱のBlogで公開され、最終更新日は2026-01-01です