みなさん、こんにちは！今日も元気いっぱい「zenncast」の時間がやってまいりました。今日は2024年5月29日、水曜日です。さあ、Zennで今日トレンドの記事を紹介していきますよ！
前回紹介した記事は、「レビュー待ちプルリクを減らす GitHub Actions」、「Rust製TypeScript Linterにおける型情報Lintルールの模索」、「ESP32のC/C++の関数をアセンブリ言語化し手作業で最適化してみる」の3つでしたね。GitHub Actionsでプルリクの効率化や、RustとTypeScriptの融合、そしてESP32のアセンブリ最適化と、それぞれ技術的に深い内容で興味深かったですね。
さて、今日はどんな記事が紹介されるのか楽しみですね！今日は全部で5つの記事を紹介します。それでは、早速いってみましょう！
....
まず一つ目の記事は「無料で商用にも使える日本の郵便番号APIをリリースしました」です。
この「jp-postal-code-api」は、日本の郵便番号から住所データを取得できるWeb APIです。GitHub Pagesを使って静的なJSONファイルとして配信されており、オープンソースなので商用利用でも安心です。データは日本郵便の公開データを基にしており、毎日自動更新されます。
特徴として、日本語表記・カナ表記・英語表記の住所データを提供し、大口事業所個別番号や市町村変更への対応も含まれています。特定のエンドポイントにGETリクエストを送ることで、郵便番号に対応する住所データがJSON形式で取得可能です。
例えば、郵便番号「100-0014」の場合、エンドポイント「https://jp-postal-code-api.ttskch.com/api/v1/1000014.json」にアクセスすると、東京都千代田区永田町の住所データが取得できます。PHPとGitHub Actionsを使って毎日自動更新されるこのAPIは、住所補完機能を持つフォームの開発などに役立つでしょう。
プロジェクトは「madefor/postal-code-api」にインスピレーションを受けており、新たにモダンPHPで再実装されました。詳細はGitHubリポジトリをチェックしてみてください。
....
次に紹介するのは「クラウド時代のデータベースを理解するために①」です。
クラウド時代において、データベースの構造や運用方法が大きく変わり、「コンピュートとストレージの分離」が重要な概念として浮上しています。従来のデータベースはSQL処理部分とストレージエンジンが同じサーバ内にありましたが、クラウド環境ではこの2つが分離されています。これによりリソースの効率的な配分とコスト削減が可能になります。
Amazon Auroraはこの分離の一例で、賢いストレージによりコンピュートを生やし、読み取り性能の向上とストレージの自動拡張を実現しています。
さらに進化した形態としてサーバーレス・データベースが登場しており、Amazon Aurora Serverless v2やTiDB Serverlessなどが代表的です。これらはコンピュート部分がオンデマンドで自動的に拡張される一方、ストレージのコストは継続的に発生します。
サーバーレスのメリットは、急激な負荷の上昇に迅速に対応でき、予測不可能な需要にも対応可能です。ただし、コスト削減の面では必ずしも効果的とは限らず、リソース不足やDBハングアップのリスクもあります。サーバーレスの選択は特に需要予測が困難な場合やリリース直後のサービスに適しています。
このように、クラウド時代のデータベースでは「コンピュートとストレージの分離」が基本となり、その延長線上にサーバーレス・データベースがあることを理解することが重要です。次の記事ではさらに詳細な概念について解説していきます。
....
三つ目の記事は「React でゼロからフローチャートUIを実装する」です。
この記事では、AIのワークフローを簡単に構築できるOSS「Dify」のフローチャートUIをReactを使ってゼロから実装する方法を解説しています。以下、主要なポイントです。
まず、フローチャートの基本構成はノードとエッジから成り、ノード同士はエッジで繋ぐことができます。ノードの作成では、識別子IDと位置をpropsとして受け取り、両サイドにコネクターを持つノードを作成します。次に、ノードをボードに配置し、ドラッグ&ドロップ可能にします。イベントでノードの座標を更新し、エッジを始点と終点の座標で指定して<svg>を使用して描画します。
エッジをドラッグして他のノードに接続する機能を追加し、ノードからエッジを伸ばして接続することも可能です。エッジのカスタマイズでは、直線のエッジを3次ベジェ曲線で滑らかな曲線に変更します。
パフォーマンス改善のために、ノードやエッジをメモ化し、再レンダリングを最小限に抑えます。このようにして、React FlowというフローチャートUIライブラリを活用しながら、独自のフローチャートUIを構築する方法が詳しく解説されています。実装コードはGitHubで公開されています。
....
四つ目の記事は「RAGで文書を1トークンに圧縮する『xRAG』について」です。
株式会社ナレッジセンスが開発した「xRAG」は、RAG（Retrieval-Augmented Generation）システムで使用するドキュメントを1トークンに圧縮する手法です。従来のRAGでは関連する文書全体をプロンプトに含めるため、トークン数が多くなりがちでしたが、「xRAG」を使用することでこれを大幅に削減できます。
「xRAG」は文書のベクトルデータを「LLMが解釈しやすい別のベクトルデータ」に変換してLLMに渡す手法を採用しています。これにより回答速度が向上し、コストも削減できます。特に、LLMをファインチューニングする必要がなく外付けシステムとして機能するため、導入が容易です。
具体的には、ユーザーの質問に関連したドキュメントを取得し、そのベクトルを「Projector」で変換します。この変換されたベクトルとユーザーの質問を併せてLLMに入力し、回答を生成します。変換器は2層のMLP（ニューラルネットワーク）で設計されており、シンプルながらも強力です。
成果として、素のLLMに比べて平均10%以上の性能向上が見られ、一部のデータセットでは従来のRAGを上回る結果を出しました。全体のFLOPsが3.53倍削減され、誤った文書が含まれている場合でもLLMが元々持っている知識を活用して対処できるロバスト性が確認されました。ただし、複数の知識を統合する必要があるマルチホップなタスクでは、従来のRAGに劣る場合があります。
この手法は特にエンタープライズ向けのRAGシステムにおいてコスト削減と回答速度の向上に寄与する可能性があります。ナレッジセンスでは、今後もRAGの回答精度を上げる研究を進めていく予定です。
....
最後に紹介するのは「デザインシステムをマルチフレームワーク(React/Vue.js)に対応させてみた」です。
この記事は、レバテック開発部で新たに誕生したデザインシステム『VoLT』をReactとVue.jsの両方で使えるようにするための取り組みについて説明しています。主な対象読者はデザインシステムに興味のあるフロントエンド開発者です。
マルチフレームワーク対応の際に発生した問題として、フレームワーク間で同等の機能提供を担保できるか、Storybookを一つのURLで一覧できるかの2点が挙げられています。これらの問題を解決するために、スタイルやプロパティなどフレームワークに依存しない部分を共通化し、開発体験を向上させるために開発サポートツールも共通化しました。
『VoLT』のシステム基盤はデザイントークンライブラリとUIコンポーネントライブラリ（React/Next.js用、Vue.js/Nuxt.js用）から成り立っています。Monorepoを採用し、フレームワーク間でスタイルとプロパティの型を共有することで多重定義を避け、同等の機能提供を担保しています。
共通スタイルファイルと共通型ファイルを作成し、ReactとVue.jsそれぞれのUIコンポーネントライブラリで使用することで、フレームワーク間で共通の機能を実現しました。Storybookの仕組み上、ReactとVue.jsのStorybookを一つのURLで一覧できるようにするために、iframeを使って切り替える方法を採用しました。
この記事は、マルチフレームワーク対応のデザインシステム構築に挑戦する方々の参考になる内容となっています。
....
今日は以上の5つの記事を紹介しました！どの記事もとても興味深く、学びが多かったですね。詳しい内容はショーノートに書いてありますので、ぜひチェックしてみてください。そして、番組の感想や質問もお待ちしています。次回もまたお会いしましょう！それでは、さようなら！