moaiのログにようこそ

やりたかったこと（最初の方向性） ブログ記事のカバー画像を用意したものの、どうにも殺風景だった。 困ったものだ。 情報としては成立しているが、「moai-log らしさ」がほとんど伝わらない。 やりたかったのは次のようなこと。 記事タイトルの視認性を高めたい でも派手にはしたくない moai というキャラクターが、主張しすぎず“そこにいる”感じで伝わってほしい 記事が増えても使い続けられる構造にしたい 具体的な希望としては、 タイトルの上下に区切り線（枠線）を入れる 左端にモアイの画像を配置する ただしこれは「案」であって、 ブログ記事のカバー画像として適切かどうかを一度外から見てほしかった。 最初に出したサンプル画像 最初のカバー画像は、かなり要素が少ない。 白い背景 左にモアイ画像 右寄りにタイトルテキスト 結果として、 余白が「意図を持っていない」 モアイがただ置かれている タイトルも背景も、同じ強度で並んでいる という状態だった。 ここから調整を始めた。 ChatGPTから最初に返ってきた視点 まず指摘されたのは、「要素を足す前に、役割を決めたほうがいい」という点。 殺風景に見える理由として整理されたのは、 余白が意味を持っていない タイトルと背景の緊張感が同じ モアイが“役割を持っていない” そして方向性として示されたのは、 要素は増やさない 役割を与える 特に重要だったのは、 モアイは全部見せない（はみ出させる） タイトルは中央に置かず、やや右に寄せる 枠線は「囲う」のではなく「読む場所を区切る」ものにする つまり、 静かな個性を、配置と余白で出すという方針だった。 グラデーションの検討 次に出てきたのが背景のグラデーション。 ここでの前提は一貫していて、 背景は主役にならない タイトルの視線誘導を助ける 感情を動かす色は使わない というもの。 提案されたのは、派手な色ではなく、 ウォームグレー → ほぼ白 ベージュ寄り → 白 ごく薄いオリーブグレー → 白 など、 色というより“明度差”で整えるアプローチ。 特に強調されていたのは、 白→色 ではなく、色→白 モアイ側に重さが溜まり、タイトル側に抜ける構造 だった。 実際にグラデーションを入れてみた 上下に薄いグラデーションを入れた案を作成。 ここでの評価は、 殺風景さは解消された カードのような厚みが出た ただし、やや全面的に効きすぎている というもの。 ...

はじめに ブロックチェーン関連の技術を眺めてみるとLayer2やZK、モジュラーといった概念は、個別に理解しようとすると唐突に見える。 個別に背景を理解しても、全体の流れや各技術の立ち位置が理解しづらい。 それに対して、この記事では過去に直面してきた技術的課題の文脈に置くことで、その立ち位置がはっきりさせようと思う。 だからこの記事では現在語られている技術がどのような意図のもとに現れてきたのかを理解するために、ブロックチェーン登場以降の技術革新の流れを歴史的に整理してみようと思う。 こうすることでIBCやZK-Rollupのように、用語としては理解できるが立ち位置が掴みにくい技術について、その背景となった課題と併せて把握することで、各技術がどのような役割を担っているのかを理解できるようにしたいと思う。 一方で技術の背景と概要理解が主な目的であるため、技術の網羅や詳細な仕組みの解説はやめようと思う。 また、流れを理解するためにある程度恣意的な流れのまとめをしている。 そこはご了承いただきたい。 ということで、ブロックチェーンが生まれた2012年からの技術革新の流れを追っていこうと思う。 1. 管理者なしで改ざん耐性のある台帳は作れるのか？（2012–2014） 最初の問いは極めて単純だったように思う。 中央の管理者や信頼できる第三者に依存せずに、改ざん耐性のある台帳を維持できるのか、という点である。 PoWとブロックチェーン構造によって二重支払いを防ぎ、参加者の合意によって台帳を更新する仕組みが成立したことで、「信頼を前提としない価値移転」が技術的に実証された。 一方で、この段階では速度やコスト、使いやすさといった要素はほぼ犠牲にされていた。 全ノードが全履歴を検証する設計は、安全性を担保するための極端な選択であったと言えると思う。 また、汎用的なアプリケーション基盤として利用することは想定されていなかったと思われる。 2. ブロックチェーンは送金以外に使えるのか？（2015–2017） 次に浮上した解決されようとした問いはブロックチェーンが送金以外の用途に耐えうるのか？という点だった。 この問いに対する代表的な解がスマートコントラクトを備えたEthereumだと思う。 スマートコントラクトによって条件付き取引や複雑なロジックがブロックチェーン上で表現できるようになった。 これによってブロックチェーンは単なる台帳から分散的に実行される計算環境へと拡張された。 しかし、この拡張は後の副作用を伴ったのだと思う。 ブロックチェーンにあまりに様々なものが載せられるのではないかという希望をより加速させたように見える。 これは全ノードがすべてのコントラクトの実行を追体験する設計は処理能力の限界を急速に露呈させたことだろう。 取引が増えるほど、混雑と手数料高騰が避けられなくなったという事態が起こった。 3. 全部オンチェーンは無理だった：速度とコストの限界（2018–2020） スマートコントラクトの登場以後、ブロックチェーンのボトルネックは理論上の議論からより現実の地に足ついた問題に移り変わったように思う。 ここで明確になったのは性能不足。つまり、遅い、コストが高いということである。 特に設計前提の限界を試すような試みが多くなされたように思う。 この時期には、高速性を優先するチェーンや、設計思想の異なる多数のプロジェクトが現れたが、分散性や安全性とのトレードオフが常につきまとっていた。 結果として、すべてのノードがすべての計算を検証するという設計は、安全性の面では有効だったが、スケーラビリティの観点では現実的ではなかったことがはっきりしたように思う。 4. 分業という解決策：Layer2とZKによる割り切り（2020–2022） 次に取られたアプローチは、ブロックチェーンのレイヤー化である。計算そのものを一つのブロックチェーン上で行うのではなく、レイヤーをL1, L2の２つ分けて、L2でまとめて処理し、その結果だけをL1が検証するという発想が定着した。 ZK-Rollupはこの流れを象徴する技術である。なぜならばレイヤーを分けたときにどのようにレイヤーをつなぐのか？という問題を解決したからだ。 計算過程をすべて再現する代わりに、計算が正しく行われたことを数学的に証明し、L1はその証明だけを確認する。これにより安全性を損なうことなく、処理性能を大幅に引き上げることが可能になった。 この時点でブロックチェーンは、「すべてを自分で処理するシステム」から複数のチェーンにより「正しさを保証する」という形式に構造を変え始めたように思う。 5. 分断された世界：マルチチェーン化と相互接続の課題（2021–2023） レイヤー化ともに並行して生まれていた問題として、複数のチェーンが乱立があった。 用途や設計思想ごとにチェーンが分化することで、資産や状態が孤立し、相互運用性が低下した。 例えば同じコインが複数のチェーン上で発行されたが、資産を一つのチェーンにまとめることができない問題が起こる。 この問題に対して提案されたのが、IBCに代表されるチェーン間通信プロトコルである。 各チェーンが互いの状態を検証可能な形で参照し合い、信頼を最小化したままメッセージや資産を移動できる仕組みが整備された。 相互接続は、分業の副作用として生じた新たな前提条件であり、マルチチェーン環境を成立させるための基盤となった。 6. すべてを一つにまとめない：モジュラー・ブロックチェーンという整理（2023–2025） ここまでの流れを踏まえると、近年語られるモジュラー・ブロックチェーンは、特定のプロジェクトの発明というより、必然的な整理として現れた概念に見える。 実行、合意、データ可用性、検証といった機能を分離し、それぞれを専門化したレイヤーに委ねることで、全体としての柔軟性と拡張性を高める設計が議論されている。 この文脈においてZK証明は、単なるスケーリング技術ではなく、異なるモジュール間で「正しさ」を受け渡すための共通インターフェースとして位置づけられつつある。 おわりに ブロックチェーンの技術革新は最初の分散台帳というコンセプトから現実劇な問題を解決しつつある、実用的なレベルに押し上げられつつあるように思う。 すべてをオンチェーンで処理するという初期の理想は放棄されて、分業と検証によってパフォーマンスと安全性を保つ設計へと移行してきている。 結果として、ブロックチェーンは単一の完成品ではなく、用途に応じて組み合わせられるインフラ部品として再定義されている。 うーん、面白い。

喫茶店でスマホをポチポチすると、なぜか回復する 喫茶店でコーヒーを飲みながら、スマホをポチポチしていると、なぜか落ち着く。 集中しているというより、回復している感覚に近い。 同じことを家でやっても、あまり回復しない。 むしろ、少し疲れることすらある。 この違いは何なんだろう？ 家と喫茶店で、何が違うのか まず思いつくのは、 雰囲気がいいから？ 安心感があるから？ ちゃんと整っているから？ 人の目があるから？ どれも間違ってはいなさそうだけれど、どこか説明しきれていない感じがする。 家だって安心できるはずだし、整えているつもりでもある。 それでも、家でスマホを触ると疲れて、喫茶店だと回復する。 確かに人の目があり、掃除がゆき届いているところほど回復する気がする。 ただそれらに共通する芯のようなコンセプトは異なる気がする。 家も安心感はあるだろうし、家族という人の目もあったりする。 しかし、喫茶店のスマホのポチポチとは体験が異なる。 違いは「可能性の数」ではないか 家にいるとき、視界や気配の中にはたくさんの「可能性」がある。 これを片づけた方がいいのでは あの作業、まだ終わっていない 今やるべきことが他にある気がする 家族という触れ合ったほうが良いのではないか 皿洗い、食事の用意、洗濯 何なら仕事も家でやってる 何もしていなくても、 **「できてしまうこと」「やるべきかもしれないこと」**が常に立ち上がってくる。 一方、喫茶店ではどうだろう。 できることはかなり限られている。 座る 飲む ぼんやりする スマホを見る 環境そのものが、可能性を制限してくれている。 少なくとも家事はできないし、家族とも距離がある。 目の前にはパソコンかスマホ。 しかも人の目もあり、動画などを見ることもできない。 可能性が少ないんだ。 可能性を棚上げできると回復するタイプ 喫茶店では、多くのことを一時的に棚上げできる。 家事 仕事の続き 未完了のタスク 判断し続ける必要性 「今やらなくていいこと」が、物理的に遠ざけられる。 すると不思議なことに、 何かを生み出す余地が戻ってくる。 考えがまとまったり、 メモを書いたり、 あるいはただ落ち着いたり。 これは休息というより、 趣味に近い回復なのかもしれない。 やらなければならないことを想起する能力が高ければ高いほど、可能性を押しつぶされるようになるのかもしれない。 つまり、可能性が少ない状況での何らかの創作活動が自身を回復させる、どうやら私はそういうタイプらしい。 可能性を減らすためにできること ここまで考えると 喫茶店に行く以外にも、可能性を減らす方法はいくつかある。 掃除をする、片づける → 視界に入る分岐を減らす スマホをカバンやポシェットに入れる → 取り出しやすく、即応できる可能性を減らす 音楽を聴く → 聞こえる音の可能性を減らす。ホワイトノイズとか好きだった。 車の中に入る → 行動の選択肢を制限する。 確かにこれらの行動を散逸的にやってきて、なぜか落ち着くなぁと思うことは度々あったが、 共通項を考えたことはなかった。 ...

意志の力を信頼しないという言説 習慣化について意志の力を信頼しないだとか、意志の力は必要ないだとか。 そんな言説をちょいちょい見る。 キャッチフレーズとしては確かに成立するのだろうけれど、意志の力は信じたいじゃないか。 それに『意思の力は不要』という言葉は扇情的でしっくりこない。 本当は意志の力は必要だけど、限りなく少なくて済むように仕組み化するというのが正しいだろう。 習慣化にとって重要なのはなんだろうか？ マッチョな考え方をするならば、まず毎日やる。 そのうえで意志の力を可能な限り少なくできるようなフォーマットに落としこむ。 こういう順番になるだろう。 これは意志の力がすごく必要になるやり方に見える。 なんたって、習慣化になるまで意志の力で維持し続けて、それが意思コストが十分低くなるまで耐えるということなのだから。 私で言えばスマホを手放したいと非常に思っていたが、まずスマホを手放してみて、それからしばらく打ち手を考えると行っているようなものである。 まずスマホを玄関において、しばらく生活し始めてみた。 このときはすぐに玄関までスマホを取りに行き、えんえんとベットでスマホをいじっていて、結局スマホを手放すには至らなかった。 意志力が低い人はルールを破っていまうと すぐに自身の行動の罪悪感でやりたい方向性に戻る気力を失ってしまうのだ。 意思の力が低いところから始めるためにも意志力が大事。 習慣化をするに当たって意志の力が低いところから始めるという手もあるだろう。 でも、よく考えておくれよ。 意思の弱い人が習慣化するために意志力が低くても実行できる対策を考えきるのだろうか？ スマホをポシェットに入れて、少し出しづらくなるという案を考えた私はたしかに偉い。 自分でも褒めてあげたい。 しかし、それが実現できたのは自分の考え方を理解するという試行錯誤から生まれたものだ。 意志の力が流せる水路を整える では、より良い考え方はないだろうか？ では習慣化に対して意志力は尊重しつつ、目標を眺めて、そこに向かっていく姿勢を表現するより良い考え方はないだろうか？ 意志力はある方が良い。でも確かに意志力という抽象的なものに注目するのではないというのも正しく。 また環境変更によって実現が近づくというのも実感として正しい。 また、それが溜まっていくと成果が静かにたまり結実する。 これは自分の意思が目標に向かって流れるように『水路を整える』という感覚が私の中ではしっくり来る。 水路を整えることで自分の意思がきちんと目標の畑に向かって流すことができるようになる。 水路を整えるためには自分の意志の力の源泉を見つける必要があり、 きちんと地形をみて、水路を掘っていく必要もある。 水が流れるようになっていけば、その水は畑に溜まり、収穫できるようになる。 習慣が一度出来上がってしまえば目標のものは自然と手に入るだろう。 もちろん、その習慣はアクシデントによって止まることもあるだろう。 雨で増水して、水路が溢れてしまうこともあるだろうし、石が水路をつまらせることもある。 だから、その水路は常に詰まりを取り除くこともあるだろうし、崩れた土手は再度積む必要もある。 こういうことを積み重ねていくと習慣によって得られた収穫物が得られるのではないか。 でも結局、自己理解が一番大事だと思う 表現はいいものが見つかったのだが、結局は自己理解が一番大事だと思う。 私はスマホを取り除くという行為を前回してみたが、これにしたって自己理解がないと実行できなかったように思う。 自分に合う方法は人によって異なるのだ。 自分を理解して、意志の力がなれるような水路を整えるように環境を整備し続けると言うことが大事なんだと思う。

気づけばずっとスマホを持っている スマホを常に触っている。 スマホにバンカーリングをつけてスマホを四六時中、手に持っている。 エレベーターの中。何かのちょっとした待ち時間。 買い物するときのレジの待ち時間。 事あるごとにスマホをズボンのポケットから出して、Xを開く、Instagramを開く。 一日になんどスマホのロックを解除しているのだろうか。 たまに面白い記事はあるけれど、大抵は特に響いたりもしない。 それに本当に細切れの時間で見る記事がずっしりと頭に残ったりするわけもない。 ベッドやソファーでもスワイプが止まらない ベッドに入ってもYoutubeのshortをスワイプする。 ソファーに座っていてもYoutubeをあの小さな画面で眺めている。 世間の闇や秘密、陰謀論がとても知れる気になってしまう。 肩こりや親指の付け根が痛い 右の肩こりが本当に酷い。つねに首の付け根に小さな石ころがあるかのように引っかかる。 右に傾けるとツンと痛みが走るような感じがする。 親指の付け根がなんとなく痛いような気がする。 一時期は右腕の肘の付け根あたりが痛くて仕方がなかった。 多分スマホのせいだ 正確に言うとスマホを持ち続けている自分が悪い。 歩くとき、隙間時間、ベッド、ソファーでスマホをずーっと持っていれば、それはその持つ筋肉である右手、右肘、肩の筋肉の緊張が走るというのはそれはそうだろう。 だから、右が側が痛いんだと思う。 ある程度予想はついていて、解決方法もスマホを持たなければいいのだろうと思う。 でも、難しいのだ。 これまで何度もトライしてきた。 でも、スマホを持たないということはなにか難しく、失敗もしてきた。 習慣とは恐ろしいものだ。 肩掛けポシェットを買う 自分の生活からいきなり剥がしてしまうのは無理だし、そんな心理的なコストを払うのは難しい。 だから、ほんの少しだけスマホを取り出しづらくしてみた。 いつもはスマホはズボンのポケットに入れている。 これを肩掛けのポシェットに入れる。 このポシェットにはジッパーも付いているので、ほんの少しだけ取り出しづらい。 ジッパーを開けて、スマホを取り出して、ロックを解除する。 ちょっと手間だ。 でも、スマホは常に持っておけるし、手放さなくなったわけではない。 安心だ。 目に見えて外でスマホを見る回数が減った 外に出たときにはスマホを取り出すのが少し億劫になったおかげで目に見えてスマホを触る回数が少なくなった。 代わりに景色を眺める時間が増えた。 子供を眺める。駅の看板を眺める。点字ブロック、駅の電光掲示板。 道路を行き交う人々。街路樹、海。そこら辺に生えている名前もわからない草たち。 スマホの外にも世界は広がっている。 当然と言えば当然である。 気づいたらスマホを探してる自分もいる。 右手がポシェットを探して、少し右手を胸のあたりに上げる。 でも、出すのが面倒だからいいか。 そう思いながら、右手を下ろす。 こうやってスマホを取り出す時間は減っていった。 ポシェットを帰ったら玄関のフックに掛けるようになった 家でもスマホを見るので、できたら見る時間を減らしてみたいのでスマホを玄関のフックにかけて見るようにした。 そのために充電器も玄関においた。 家から帰ってきたら、コートを脱いて、ポシェットを玄関にかけて、充電器につなぐ。 幸い家には娯楽はたくさんある。 タブレットもあるし、このブログを書いているChromebookもある。 インターネットに繋いで娯楽を楽しむ方法は色々ある。 だから、タブレットでYoutubeを見たり、Netflixを見たり、Chromebookでネットサーフィンしている。 それでも子供と遊ぶときの隙間時間はスマホを見なくて済むようになった。 なにか健全だなと思う。 すっかり家ではスマホを見なくなった タブレット、Chromebookで十分に済むようになった。 もちろん、電話とかはスマホなのでそっちを確認する必要がある。 でも、大抵は不要になった。 外には相変わらずスマホは持って行くが、それも長い外出の時だけで済むようになった。 買い物もしない散歩の時なんかはもう、鍵だけ持って外を歩くようになった。 スマホを持たなくなっても何も困らない スマホを持たなくなって、しばらくたった。 何も困らない。本当に。 残念だ。本当に残念だ。 スマホには本当に恋い焦がれていると言ってもいいほど一心同体の存在だったのに。 離れてみれば不要だったということに気がついてしまった。 ...

個人的にはCosenseはかなり気に入っているのだが、生成AIにCosense記法を書かせる能力が高くない。 なので、プロンプトを作って解決する。 育てていくつもり。 Cosense記法 に変換せよ． これは Scrapbox / Cosense 用の出力形式であり，他の表記は一切許可しない． 【基本方針】 後からリンクで展開できる構造を優先する． 【キーワードの扱い】 ・文中の意味的に独立した名詞，重要概念，固有語句のみを[ ]で囲むこと ・概念として再利用されうる語を優先的に[ ]で囲むこと ・数量，単位，時刻，金額，比率，動作，状態変化（例：2人分，5回，伸ばす，検討する）は[ ]で囲まないこと ・助詞，接続詞，抽象度の低い一般名詞は[ ]で囲まないこと 【構造】 ・内容は簡潔にまとめ，必ず箇条書きで出力すること ・箇条書きは階層構造を許可するが，インデントは常に半角スペース1つのみとすること ・各箇条書き行の先頭には必ず半角スペース1つを挿入すること ・先頭行には対象の名称やタイトルを書かず，概要のみを体言止めで記述すること ・タイトル行や見出し行は作成しないこと 【整形ルール】 ・ルールに沿わない改行を作成しないこと ・装飾記号（*, -, ・, 数字付きリスト）は一切使用しないこと 【禁止事項】 ・Markdown形式の使用 ・見出し，番号付きリスト，太字，引用の使用 ・Cosense記法以外の説明文の付与

目標設定について語られるとき、よく聞く一般論がある。 「目標は具体的であるほど良い」 数値があり、期限があり、達成条件が明確であること。 SMART目標やOKRのようなフレームワークはこの原則に立って設計されている。 実際、それが機能する人も多いだろう。 そもそも向かう先を定めることは重要だし、指針があるからこそ力を集中できる。 ただ、ここ数年ずっと感じていた違和感がある。 具体的にすればするほど、なぜか目標が重くなり、運用できなくなる感覚だ。 具体性が高すぎる目標が苦しくなるとき 目標を立てたはずなのに常に頭の片隅に居座り続ける。 達成できていないこと自体がストレスになり、考えるたびに疲れる。 期限が近づくと気が重くなる 少し逸れるだけで「失敗した」感じが出る 現実に合わせて調整すると、裏切っているような気分になる こういう経験がある人は少なくないと思う。 例えば、昨年私は健康に対する目標で２つの目標を立てた。 一人の時間を10分取る 毎朝サイクリングを行う というような目標だ。 が、この目標は達成できなかった。 実際にはまとまった一人時間は取りづらく、 朝のサイクリングも生活リズムと合わなかった。 一方で、時間が詰まってきたら短く散歩することによって自分の時間を回復する。 運動として、1日8,000歩歩くというような目標は達成できた。 具体性が高すぎたがゆえに一年の目標にしては具体度が高すぎたのだとおもう。 具体性が高すぎる目標はそれ自体が常駐タスクになってしまう。 それ故にこの目標は人を縛る力非常に強いのだけれども、それが故に自分をそこから回避させてしまうようなことも起きる。 特に、制約の多い状況（仕事・家族・体調など）では、「計画を守ること」と「現実に合わせて動くこと」が衝突しやすい。 重要なのは目標を"運用できる"ことだろう 問題は「目標」をSMARTにそって立てることそのものではなく、目標によって力を集中できること。 それによってより良い状態に変化し続けられること。 なりたい自分に近づけること。 多分、こっちのほうが重要度が高いだろう。 だから、年間の目標はもっと抽象度を上げてもよいのではないか？と思う。 さもなくば、年の途中にたくさんの目標変更が発生してしまい、運用がとても難しくなる。 我々には仕事も家庭も含めた生活もあるのだ。 だから今年は目標の抽象を指針というレベルまで上げることと、 行動目標を打ち手候補という形で抽象度を下げ、具体性をこちらに持たせることにした。 『軽やかな目標設定』：抽象度の高い指針と、具体的な行動トリガー 今年の目標を一部、抜粋してみる。 1. 抽象度の高い指針を置く たとえばこんなものだ。 人生の主導権を取り戻す 選びなおす 考えたことを再利用可能にする これらは測定できないし、達成判定もない。 ただし、判断の基準としては十分に機能する。 「これは今、この指針に沿っているだろうか？」 そう問い直すための軸になる。 今年の目標ぐらいの抽象度なこの程度でいいだろう。 ついでに言うなら、自分自身の今年のテーマなので他人から見て十分な客観性も不要だ。 美しくもないが、自分の心に響くことのほうが重要度が高い。 2. 行動は、かなり具体的にする 一方で、日々の行動は抽象化しない。 同じ説明を2回したら、1行メモに残す 迷ったら、いったん歩く 見てくれる人がいるなら、任せる ここには理想も、長期計画も置かない。 状態に反応して起動するだけの、小さな行動にする。 この行動目標は客観度が高いメモのようなものだ。 3. 見直す前提を、最初から組み込む 重要なのは、途中で見直すことを失敗扱いしない設計にすることだ。 四半期に一度、指針が機能しているかを見る 合っていなければ、行動だけを入れ替える 指針そのものは、基本的に年単位で扱う こうすると、調整すること自体が自然な運用になる。 この運用にすることで行動目標も失敗前提で打ち手ぐらいの立ち位置にして、あとから追加も修正もするということも可能だ。 タイムスパンのコントロールもできる。 ...

node.jsで .env と direnv を並行運用するには？ 疑問: .env と direnv はどうやって並行運用するのだろうか？ Node.jsアプリケーションを開発していると、環境変数の管理方法として .env ファイルを使う方法と、 direnv のような環境変数管理ツールを使う方法があります。 両者を併用する場合、どのように動作するのか、優先順位はどうなるのかという疑問が生じます。 .env とはどのようなものなのか？ .env ファイルは、Node.jsアプリケーションで環境変数を管理するための単純なテキストファイルです。各行に=KEY=VALUE=の形式で変数を定義します。 例えば: DB_HOST=localhost DB_USER=admin DB_PASS=password API_KEY=1234567890 これらの変数を読み込むには、一般的に dotenv というパッケージを使用します： require('dotenv').config(); // 環境変数にアクセス console.log(process.env.DB_HOST); // "localhost" dotenv.config() を実行すると、 .env ファイルの内容が読み込まれ、 process.env オブジェクトに追加されます。 そもそも process.env はどのように環境変数を読み込むのか？ Node.jsでは、 process.env オブジェクトを通じてシステムの環境変数にアクセスできます。プロセス起動時に、Node.jsはオペレーティングシステムの環境変数を自動的に process.env オブジェクトに読み込みます。 例えば、シェルで NODE_ENV=production node app.js と実行すると、アプリケーション内では process.env.NODE_ENV=に“production”= という値が設定されています。 console.log(process.env.NODE_ENV); // "production" process.env は通常のJavaScriptオブジェクトなので、後から値を変更することも可能です： process.env.MY_VARIABLE = "some value"; console.log(process.env.MY_VARIABLE); // "some value" ただし、この変更はNode.jsプロセス内でのみ有効で、親プロセスや他のプロセスには影響しません。 process.env は環境変数と .env で定義された内容をどのように読み込むのだろうか？ 環境変数の読み込み順序は次のようになります： ...

煮込み料理 ドライカレー ハヤシライス 親子丼 牛丼 クリームシチュー 肉じゃが すき焼き風煮込み 鳥と大根の煮物 豚の角煮 かぼちゃのポタージュ 油揚げの甘煮 炒め物 きのこのバタポン炒め 焼きそば 焼きうどん 子供が食べられやすい野菜 色の薄い野菜 キャベツ もやし 茹でたブロッコリー（これは色が濃いのになぜか食べられる） 嫌いなもの 酸っぱいもの 辛いもの 色の濃い野菜

疑問 honoでLINE message APIを受け取るWebhook APIを作るときに何をすればよいか？ 回答 HonoでLINEのWebhookを作成するには、主に以下の3つのステップが必要です。 リクエストの署名検証 リクエストボディのパースとイベント処理 LINEサーバーへの応答 手順 Honoプロジェクトの準備 npm create hono@latest でプロジェクトを作成します。Node.js環境を想定します。 環境変数の設定 LINE Developersコンソールから取得した2つの値を設定します。 LINE_CHANNEL_SECRET: 署名検証に使うチャネルシークレット LINE_CHANNEL_ACCESS_TOKEN: メッセージ返信に使うチャネルアクセストークン（長期） Webhookエンドポイントの実装 以下は、Node.jsランタイムで動作するHonoのサンプルコードです。 import { Hono } from 'hono' import { HTTPException } from 'hono/http-exception' import type { MessageEvent, TextMessage } from '@line/bot-sdk' import crypto from 'crypto' const app = new Hono() // 環境変数から設定を取得 const CHANNEL_SECRET = process.env.LINE_CHANNEL_SECRET! const CHANNEL_ACCESS_TOKEN = process.env.LINE_CHANNEL_ACCESS_TOKEN! // LINEからのリクエストの署名を検証する関数 const verifySignature = (signature: string, body: string): boolean => { const hash = crypto .createHmac('sha256', CHANNEL_SECRET) .update(body) .digest('base64'); return signature === hash; }; // Webhook用のPOSTエンドポイント app.post('/webhook', async (c) => { // 1. 署名検証 const signature = c.req.header('x-line-signature'); const body = await c.req.text(); // JSONパース前に生テキストを取得 if (!signature || !verifySignature(signature, body)) { throw new HTTPException(401, { message: 'Invalid signature' }); } // 2. イベント処理 const data = JSON.parse(body); const events: MessageEvent[] = data.events; for (const event of events) { if (event.type === 'message' && event.message.type === 'text') { const message: TextMessage = event.message; const replyToken = event.replyToken; // 3. メッセージを返信する (オウム返し) await fetch('https://api.line.me/v2/bot/message/reply', { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${CHANNEL_ACCESS_TOKEN}`, }, body: JSON.stringify({ replyToken: replyToken, messages: [{ type: 'text', text: message.text, // 受け取ったテキストをそのまま返す }], }), }); } } // LINEサーバーに正常処理を通知 return c.json({ status: 'ok' }); }); export default app 要点 署名検証が最重要: x-line-signature ヘッダーとリクエストボディ、そしてチャネルシークレットを使って、リクエストがLINEから来た本物であることを確認します。 生のボディテキストが必要: Honoの c.req.json() はボディを消費してしまうため、署名検証には c.req.text() で先に生のテキストを取得します。 非同期で返信: Webhookのレスポンスとしてメッセージを返すのではなく、LINEのReply API (/v2/bot/message/reply) を別途 fetch などで呼び出します。 200 OKを返す: イベント処理が終わったら、LINEサーバーに 200 OK を返す必要があります。Honoでは c.json({ status: 'ok' }) などで応答します。