どうも、こんばんは。マイクです。今日も一日おつかれさまでした。
六月二十三日、火曜日の朝七時をまわりました。「zenncast」、今日もゆるっと始めていきましょう。
この番組では、毎回、技術記事の投稿サービス「Zenn」に上がっているトレンドの記事の中から、気になるネタをピックアップしてご紹介していきます。
通勤・通学の支度をしながら、あるいはコーヒー飲みながら耳だけ貸してもらえたらうれしいです。
さて今日は、お便り紹介はお休みで、そのぶんガッツリ記事を紹介していきたいと思います。
今日ご紹介する記事は、ぜんぶで五本です。
個人開発のダッシュボードづくり、ローカルのAWSエミュレータ、ローカルLLMを使ったIME、JWTまわりのセキュリティ、そして地味だけど超大事なCSV配布のTipsまで、幅広く攻めていきますよ。
まず一本目。
一枚で自分の資産全体を静かに眺められる、そんな投資用の資産ポートフォリオダッシュボードを、個人開発で作り上げた記録です。
面白いのが、Claude Design と Claude Code を組み合わせて、デザインから実装、さらに自動運用までぜんぶ仕上げちゃった、という点なんですね。
元々の課題は、「国内株・米国株・投資信託・金」が、証券会社の複数口座に散らばっていて、全体像がとにかく見づらい、と。
そこで、「一枚のダッシュボードで、自分の資産全体を静かに眺められる画面がほしい」というコンセプトで作り始めています。
まず Claude Design に、自然言語で「iGrow っぽいUIにしたい」とか、こういう雰囲気にしたい、といったプロンプトを投げて、iGrow風のUIプロトタイプを生成してもらいます。
配色だったり、ドーナツチャートをクリックしたときのドリルダウンの挙動、グラフがどう動くか、そういったインタラクションも、実際の投資データを流し込みながら詰めていきます。
で、ある程度デザインが固まったところで、Claude Code にバトンタッチ。
フレームワークはあえて使わずに、バニラのJavaScriptと静的サイト構成で、本番用のコードに落とし込んでいく、という流れになっています。
裏側のデータ更新もけっこう攻めていて、株価の取得や、その日の評価額のスナップショット保存、それから OGP 画像の自動生成なんかを、GitHub Actions で全部自動化しています。
元となるデータは「取引台帳のCSV」ひとつだけにしておくことで、「このデータが唯一の真実」と言える状態にしているんですね。
これによって、「データが嘘をつかない」「何もしなくても毎日最新状態」という構造を作っているのがポイントです。
さらに設計思想として、外部ライブラリや巨大なフレームワークへの依存をできるだけ避けて、Claude が生成した軽量なランタイムコードを土台にすることで、長期運用でのメンテナンスコストやリスクを最小限に抑えています。
「資産管理のツールって、十年単位で使い続けたいよね」という観点から、あえてシンプルな技術スタックを選んでいるあたりも、読みどころです。
「AIにデザインも実装も手伝ってもらいながら、でも長く保守できるようにミニマムに組む」という、今っぽい個人開発のいい事例になっていました。
。。。。
続いて二本目。
LocalStack の有料化をきっかけに紹介されている、「MiniStack」というツールのお話です。
これ、無料でサインアップも不要の AWS エミュレータで、Terraform からは LocalStack とほぼ同じようなエンドポイントを指定するだけで使える、というのが売りになっています。
ポイントは、RDS や ECS を、ただのモックとしてではなく、「実際のコンテナ」として Docker 上に立ち上げるところ。
例えば PostgreSQL だったら、本物の Postgres コンテナがローカルで立ち上がるので、その実物に対してアプリケーションをつないで動作確認ができる、というわけですね。
筆者の方は、個人開発のアプリで、けっこう本格的な構成を組んでいます。
VPC、S３、CloudFront、ECS Fargate、ALB、RDS、Secrets Manager、ECR といった構成を、すべて Terraform で管理していて、その同じモジュールを「MiniStack 用のローカル環境」と「本番の AWS 環境」で使い回しています。
違いは、どのエンドポイントに向けるか、とか、どのプロファイルを使うかといった「環境の切り替え」だけ、というスタイルですね。
さらに、Makefile とスクリプトを組み合わせることで、MiniStack の起動から始まって、`terraform apply` でインフラを立ち上げて、フロントエンドを S３ で配信して、E２E テストを実行して、最後に後片付けまで、全部を「メイク イーツーイー」のワンコマンドで回せるようにしています。
これによって、「本番とほぼ同じ構成なのに、ローカルで安心してインフラ変更を試せる環境」が手元にできた、というのがこの記事のメッセージです。
LocalStack の料金や仕様変更に振り回されたくない人、あるいは「ちゃんと動くRDSやECSをローカルで触りたい」という人には、MiniStack という選択肢があるんだ、というのを教えてくれる内容になっています。
。。。。
三本目。
ローカルで動く自作の macOS 用 IME、「RomKana」を開発した記録です。
テーマは、「汎用の大規模言語モデルをどう使えば、従来の辞書ベースのかな漢字変換より賢くできるのか？」という検証です。
前半では、まず Mozc 系の辞書、具体的には mozcpy をベースにして、それにローカルで動かせる Qwen などの LLM を組み合わせていきます。
最初に試したのは、「LLMに対して、候補の中からどれを選ぶべきか指示して選ばせる」という方式なんですが、これはなかなか既存の辞書の精度を超えられなかったそうです。
そこでアプローチを変えて、「LLMには“確率計算だけ”をさせて、候補をスコアリングさせる」という方法に切り替えます。
要するに、変換候補ごとの尤度、確からしさをログの形で足しあげていって、その合計対数尤度、サムですね。
このサムの値で候補を並べ替えるようにしたところ、初めて辞書単体の精度を上回る結果が出た、という話になっています。
後半ではさらに一歩進んで、かな漢字変換専用のモデルである「zenz」と、「AzooKeyKanaKanjiConverter」という仕組みを採用していきます。
ここで分かってくるのが、「専用にチューニングされた小さなモデルのほうが、軽くて速くて、しかも高精度で、日常使いには向いている」という事実です。
結果として、プロセスも一つにまとめられて、メモリ消費もかなり削減できたそうです。
最終的に記事では、単に精度の話だけじゃなくて、実際に毎日使うIMEとして、どう設計すべきかという教訓も整理されています。
例えば、OSへのIME登録の仕組み、入力の待ち時間と候補の安定性のトレードオフ、ユーザーの学習データをどう扱うか、といった実用上のポイントですね。
「LLMを使えばなんでも良くなる」ではなく、「どこまでをLLMにやらせて、どこからは専用モデルに任せるか」という線引きがとてもリアルに描かれている記事です。
。。。。
四本目。
Hono の JWT／JWK ミドルウェアに見つかった、アルゴリズム混同攻撃が可能になる脆弱性についての記事です。
JWT のヘッダに入っている `alg`、アルゴリズムの指定を悪用されると、署名の検証がすり替えられてしまう、という、けっこう怖い系の話ですね。
まず、`hono/jwt` のミドルウェアでは、`alg` を明示的に指定しない場合に、勝手に HS二五六 が選ばれてしまっていました。
この結果、本来は公開鍵で検証すべきところを、公開鍵の値を HMAC の秘密鍵として扱ってしまう、という問題が起きます。
つまり、公開されている鍵を、そのまま「秘密鍵」として使えちゃうような、よろしくない状態ですね。
さらに `hono/jwk` の方では、JWK に `alg` が設定されていないとき、JWT のヘッダ側の `alg` をそのまま採用してしまっていました。
しかも、そのとき HS 系のアルゴリズムを拒否していなかったために、公開されている JWKS の鍵を使って、偽造トークンを作れる余地が出てきてしまっていた、という状況です。
これを受けて、修正ではけっこうガッツリ設計が変わっています。
JWT ミドルウェア側では、まず `alg` の指定を必須にしました。
そして、ヘッダに書かれている `alg` と、ミドルウェア側で許可している `alg` が一致しない場合は、必ずエラーにするように変更されています。
JWK ミドルウェアのほうでは、「許可するアルゴリズムの一覧」を必須の設定にして、そもそも HS二五六 みたいな対称鍵アルゴリズムを受け付けない設計に変えています。
さらに、JWK 側に `alg` が書かれている場合は、ヘッダの `alg` と一致しているかどうかもきちんと確認するようになりました。
記事のまとめとしては、「JWT や JWK を自前実装するときには、アルゴリズムをデフォルトに任せない」「外部から入ってくる `alg` を信用しない」ことが本当に大事だ、というメッセージが強調されています。
便利なライブラリを使うにしても、「デフォルトで何が有効になっているか」「どのアルゴリズムを受け入れているか」は、ちゃんと意識しておきたいところですね。
。。。。
そして最後、五本目。
これは、CSV をお客さん向けに配布するときにハマりがちな罠を、きれいに整理してくれている Tips 系の記事です。
「ただのカンマ区切りでしょ？」と思っていると痛い目を見る、その代表シリーズですね。
まず基本として、CSV は単なるカンマ区切りじゃなくて、クォートの扱いとか、改行コードとか、RFC 四一八〇に沿った実装を意識する必要があります。
特に、「すべてのセルを二重引用符で囲んでおく」と、いろんなバグや、SYLK 形式と誤認される問題を避けやすくなる、という指摘があります。
次に、「同じ入力からは、いつでも同じバイト列のCSVを出す」、つまり決定的で、バイトレベルで同一になる出力を目指そう、という話。
CRLF の扱い、列の順番、ロケールに依存した並び替えなんかを排除して、テストで固定しておくと、後から再生成したときの差分確認が安定するよ、というのは、運用上かなり効いてきます。
配信時のHTTPヘッダも重要で、`Content-Disposition: attachment` をきちんと付けて、「これはファイルのダウンロードですよ」とブラウザに伝える。
それから、正しい `Content-Type` を付けること、日本語ファイル名には RFC 五九八七に基づいた `filename*` を使うこと。
これによって、Reflected File Download 攻撃だったり、MIMEタイプの誤認、ヘッダインジェクションなどのリスクを減らすことができます。
また、presigned URL は「短命の認可情報」だと意識して扱おう、という注意も書かれています。
そして多くの人が一番悩まされるのが、「Excelで開いたとき問題」です。
SYLK 誤認、つまり先頭のセルが「ID」だと、Excel が「これはSYLK形式では？」と誤解してしまう問題。
それから、先頭のゼロが消えてしまう、長い数値が勝手に指数表記に変わる、日付に自動変換される、UTF-８でBOMなしだと文字化けするといった、いろんな罠があります。
記事では、「生成側で防げるもの」、たとえば全セルクォートや、条件付きでBOMを付ける、といった対策と、「Excel側のインポート設定に委ねるしかないもの」とを、きちんと切り分けて説明しています。
最後に、CSVインジェクション、いわゆる数式インジェクションへの対策。
セルの内容が「イコール」「プラス」「マイナス」「アットマーク」、あるいは空白や全角記号などで始まっている場合に、それが単なる数値リテラルではない限り、先頭にシングルクォートを付けて無害化する、という方法を紹介しています。
ただし、これはあくまで「人がExcelで開く、最終的な配布物」としてのCSVだけに適用すべきであって、中間生成物のCSVとか、ヘッダ名なんかには適用しないように、境界を慎重に設計しよう、という注意喚起もされています。
実務でCSVを触っている人なら、「ああ、それやったわ…」となるポイントがたくさん並んでいるので、心当たりのある方は、この記事をチェックしておくと、今後ちょっとラクになるかもしれません。
。。。。
というわけで、きょうの zenncast は、このへんでお時間です。
今日は、Claude を使って投資用ポートフォリオダッシュボードを個人開発した話、MiniStack というAWSエミュレータで本番そっくりのローカル環境を作る話、自作macOS IME「RomKana」でLLMと専用モデルを比較した話、Hono のJWT／JWKミドルウェアのアルゴリズム混同脆弱性とその修正、そしてCSV配布のときに踏みがちな罠とその対策、という五本を駆け足でご紹介しました。
気になった記事があれば、詳しい内容はショーノートのリンクから、ぜひ本編も読んでみてください。
番組の感想や、「こんなテーマを取り上げてほしい」といったリクエストも、どしどしお待ちしています。
それでは、そろそろお別れの時間です。
きょうも聞いてくれて、ありがとうございました。
次回の zenncast で、またお会いしましょう。
お相手はマイクでした。いってらっしゃい。