ID:80865さん

### 概要 - Redash 内に、MongoDB や MySQL のクエリを実装して、同じ部署のメンバーがデータ取得を開発チームに依頼せずに行える仕組みを実装 - Redash API を使用して、Google Apps Script を経由して Slack に情報を流す仕組みも実装 ### 抱える課題 - 開発チームに、使用したい背景を伝えて、それをチーム全員に伝わるようドキュメント化して、実装してもらった後にテストする流れにすごく工数がかかる - 要件が伝わっていない場合に、依頼側はちゃんと伝えたつもりでも伝わっておらず、精神的なストレスと工数が増える原因になっていた。 ### 使用した技術 - MySQL, MongoDB, Redash - Slack に情報を流したい場合には、追加で Slack API, Google Apps Script, Redash API を使用した ### 工夫 - 大量のリクエストを一度に行うとキューが詰まってしまうので、つまらないように一度に取得するカラム・フィールドを制限 - Google Apps Script から Redash API 経由で取得する場合も、100 件ごとに 1 秒待機するなどの工夫をした ### どのような成果が出たのか - 開発と使用する側の両方の背景を理解することで工数が削減され、コミュニケーションのミスも無くなることで、部署間の関係もよくなった

### 無料主義アプリ（`freeism-app`） #### 詳細 - GitHub：<a href="https://github.com/yuichisugio/freeism-app_v1" target="_blank">https://github.com/yuichisugio/freeism-app_v1</a> - ※今後、大きく仕様が変更する&残しておきたいコードもあるため URL が変わる可能性あり - Zenn：<a href="https://zenn.dev/329/articles/0d13b45c46330f" target="_blank">https://zenn.dev/329/articles/0d13b45c46330f</a> #### 概要 - 無料主義アプリ（`freeism-app`）は、無料主義の管理を行うことができるアプリです - 無料主義とは - 何かしら作業した人を第三者がそれぞれの評価軸で評価して、その評価結果をもとに他者が提供する商材を優先的に得られるようにする仕組みです - 詳細：<a href="https://zenn.dev/329/books/0dbe4578af702a" target="_blank">https://zenn.dev/329/books/0dbe4578af702a</a> - 作成した理由・解決したい課題・なぜ作ったか - OSS などの収益化できない or 報酬が十分ではない労働に対して、報酬を与えられる仕組みを作りたいと考えました - まずは、無料主義の仕組みを理解してもらい、どうすればより良い仕組みとなるかの材料としたいと考えました - ターゲット層 - 無料主義の仕組みを実践してみたい人 - 初期はプログラマー向け - 実装期間 - 2025 年 01 月〜2025 年 07 月 - バージョン - freeism-app ver1 #### 実装の進め方 1. 仕様を markdown にまとめます 2. 仕様 markdown を Cursor に渡して AI に要件定義・設計漏れを指摘してもらい、追記します 3. 仕様 markdown を Cursor に渡して AI に実行タスクをまとめてもらいます 4. 仕様/タスク markdown を Cursor に渡して AI に実装してもらいます 5. AI の実装コードをすべて読んで、理解できない点があれば解説してもらい、ロジックを理解できる状態にします #### エラー対処法 1. Cursor に、エラーログと関連コードを渡して修正してもらいます 2. それでも直らない場合は、`console.log()`,`console.trace()`を記載してバグ箇所を特定して手動 or AI に修正依頼します 3. その後、関連コードにバグりにくいコードに変更 & わかりやすく注意するコメントを入れます 4. テストコードを実行したり、Playwright MCP を使用したり、LocalHost から操作して、バグがある場合は AI に依頼 or 手動で修正します #### 実装で意識したこと - ライブラリなどを利用するときは、ブログや記事や AI の解説だけでなく、公式ドキュメントの確認を習慣づけました #### アプリ作成で苦労した点 - **必要工数の算出** - 説明 - どの機能をどれだけで実装できるか算定が難しかったです - 必要工数の算出が甘かったが仕様に入れてしまったため、アプリ作成が大きく遅れました - 解決方法 1. 感覚的に判断せず、実装方法と実装によるよくあるバグを AI で調査した結果と、影響範囲の小さい部分で最小限の実装をしてみて、どれくらいの期間がかかるか判断して、工数算出の精度を高くしました 2. 様々な機能を実装することで難易度/工数を算出する能力が上がると実感したため、本質的ではないが経験を積めるいろいろな機能を実装して、工数算出の精度を高くしました - 例 - 全画面表示に対応する機能の実装 - 工数予測は、簡単に実装できるので 1 日だと考えていました - 実際は、全画面にすると Index の関係でテーブル内の Sort や Filter 機能が表示されなくなったため 3 日ほど必要でした - **要件定義** 1. アプリとして必要な本質的な機能は何なのかを考える作業 - 例）オークション機能では「出品者が商品を登録できる」「入札者が価格を提示できる」という 2 つのコア機能に絞り込み、通知機能は後回しにしました - 解決方法 1. ユーザーストーリーマッピングで優先順位付けしました - 「誰が」「何のために」「何をする」を整理し、Minimum Viable Product（MVP）として最小限必要な機能を定義しました 2. 類似サービスの分析と GitHub Issues の調査をしました - 既存のオークションサービス（ヤフオク、メルカリ等）のコア機能を分析しました 3. Claude 等の AI で技術的実現可能性を確認しながら仕様を詰めました - 実装難易度が高すぎる機能は代替案を検討しました 2. 「エッジケース対応や機能の UI/UX の充実さ」と「アプリ実装の難易度や実装期間」のトレードオフがあった際の意思決定 - 例）オークション入札では、`Server-Sent Events`,`WebSocket`のどちらが必要か、またはどちらも不要なのか - 解決方法 1. 技術選択の判断基準を 3 軸で評価しました - ユーザー体験への影響度（高：Server-Sent Events 採用、低：ポーリング可） - 実装・運用コスト（学習時間、サーバー負荷、障害対応の複雑さ） - アプリの目的（無料主義の仕組み理解を目的とするので、エッジケースや UI/UX よりロジックの可読性を意識しました） 3. 技術の選定 - どのライブラリ・フレームワークを使用するのか、AI や技術記事からメリット・デメリットを判断して選ぶ作業 - 解決方法 1. 公式ドキュメントと技術記事の比較検討をしました - Next.js の App Router と Pages Router の選択では、公式ドキュメントの推奨事項と実際の採用事例（Vercel のブログ、GitHub Discussions）を照らし合わせて判断しました - O/R マッパ の選定では、Prisma、Drizzle、TypeORM の公式ドキュメントを読み比べ、型安全性と開発体験を重視して Prisma を選択しました 2. コミュニティの活発さとメンテナンス状況の確認をしました - GitHub のスター数、Issue/PR の対応速度、最終更新日を確認しました - 長期的に使用できる技術かを判断材料に含めました 4. デザインの決定 - どのような UI にするのか - 解決方法 1. 既存サービスの UI/UX パターン分析をしました - 類似サービスの優れた UI を Figma で模写しながら学習しました - Material Design、Human Interface Guidelines などのデザインシステムから一般的なパターンを理解しました 2. Claude に複数の UI を実装してもらい、Claude 内の Preview から UI を選定しました - **AI の使い方** - 苦労した点 - ハルシネーションに惑わされました。ドキュメント/GitHub Issues をよく読む重要性を実感しました - 例 - Auth.js の設定方法を AI に聞いた際、v4 の情報と v5 の情報が混在しました - Next.js の App Router と Pages Router が混在しました - 解決方法 1. AI 出力の検証プロセスの確立 - AI が提示したコードや情報について、必ず公式ドキュメントで裏取りする習慣を徹底しました - 特にバージョン依存の情報（非推奨 API、破壊的変更等）は、公式のマイグレーションガイドや CHANGELOG で確認してから採用しました 2. プロンプトエンジニアリングの改善 - 曖昧な質問を避け、バージョン番号や実現したい具体的な挙動を明示しました - 「Next.js 14 の App Router で、Server Actions を使ってフォーム送信する方法」のように技術スタックを具体的に指定しました 3. エラー解決時の段階的なアプローチ - まずエラーメッセージをそのまま Google 検索し、Stack Overflow や GitHub Issues で同様の問題と解決策を確認しました - 公式ドキュメントの該当箇所を読んで根本原因を理解しました - その上で AI に「このエラーの原因は ○ だと理解したが、解決方法として △ と □ のどちらが適切か」と具体的な選択肢を提示して意見を求めました 4. Model Context Protocol（MCP）を活用した正確性の向上 #### アプリの改善点 1. Supabase の RLS の設定 - version2.0.0 をこの後実装予定なので、そこで行います 2. Next.js の Middleware の実行ランタイムと認証ロジックの修正 - `freeism-app ver2`では、2025/2/26 にリリースされた Next.js v15.2.0 で experimental ですが Node.js runtime が正式サポートされたので、Node runtime で認証処理するよう修正したいと考えています #### 主な言語 - TypeScript - なぜ使用したか 1. Next.js/React のエコシステムで設定・ビルド・スクリプト用途に必須だからです 2. Node.js ランタイムでの CLI・運用スクリプト（`scripts/`）に適合し、周辺ツールが充実しているからです 3. 型安全と保守性を向上させたいためです - 主に学んだサイト - [https://typescriptbook.jp/](https://typescriptbook.jp/) - [https://jsprimer.net/intro/](https://jsprimer.net/intro/) #### 開発環境 - GitHub - なぜ使用したか 1. リポジトリのバージョン管理をするためです 2. GitHub Actions による CI/CD 連携のためです 3. 教材が豊富だからです - Cursor - なぜ使用したか 1. tab 補完が便利だからです 2. 多くのエディタの中でも AI の使い方が上手で便利機能が多いと感じるためです - Mac OS - Windows #### 主に使用したライブラリ - **React** - なぜ使用したか 1. 業界標準を実践的に学びたかったためです 2. 公式ドキュメントが分かりやすく、フロントエンドの UI を作るライブラリとして最良だと感じたためです - **Next.js** - なぜ使用したか 1. ルーティング、サーバーアクション、メタデータ管理、ISR/SWR 相当のキャッシュ制御をフルスタックで統合できるためです 2. App Router・Server Actions・API を同一プロジェクトで完結できるためです 3. 解説記事が豊富だからです - **TanStack Query v5** - なぜ使用したか 1. クライアントサイドのキャッシュを行いたいためです 2. TanStack 系は、Table や Form など豊富で今後の勉強のために Query で慣れておきたいからです - その他 - `src/library-setting/tanstack-query.ts` で QueryClient を拡張し、`idb-keyval`と連携して IndexedDB 永続化やトースト連携を共通化しました - **Auth.js（NextAuth v5）** - なぜ使用したか 1. Google OAuth を利用したシングルサインオンと JWT セッション管理を短時間で構築するためです 2. Next.js 系の認証ライブラリを選択したいからです 3. 技術記事や公式ドキュメントが豊富で分かりやすかったためです - **Tailwind CSS** - なぜ使用したか 1. AI にコーディングしてもらうのに適していると感じたためです - 1 つのファイルで AI にコンテキストを渡せるため便利です 2. 色々な CSS 系ライブラリを試してみた結果、一番理解しやすかったためです - **Prisma** - なぜ使用したか 1. Supabase/PostgreSQL 上で複雑なリレーション（Auction・Task・Notification など）を型安全に扱うためです 2. 系ライブラリの中で、一番ドキュメントの英語が分かりやすく、量も豊富だったためです - その他 - Drizzle も気になっています - **Zod** - なぜ使用したか 1. サーバー／クライアント双方で環境変数やフォーム入力をスキーマバリデーションするためです - その他 - `src/library-setting/env.ts` で `@t3-oss/env-nextjs` と組み合わせ、ビルド時に必須環境変数の欠落を検出しています - **Upstash Redis（@upstash/redis）** - なぜ使用したか 1. オークションの入札イベントを Pub/Sub で即時配信し、`Server-Sent-Events` へ連携するリアルタイム基盤を実現するためです 2. 公式ドキュメントや Redis の GUI がとても分かりやすかったためです - **Commitizen/commitlint/Husky/lint-staged** - 説明 - Conventional Commits を採用し、Commitizen/commitlint でコミット品質を統一しています - Husky + lint-staged でコミット前に自動整形と Lint 実行を行っています - なぜ使用したか - コミット前に整理されたコードとコミットメッセージで分かりやすく履歴を残すためです - **PostgreSQL(Supabase)** - なぜ使用したか 1. 簡単に DB を使用できるためです 2. また、ドキュメントや技術記事も豊富だからです - **Vercel** - なぜ使用したか 1. Next.js との統合が最適化されており、エッジでの SSR・ISR といったモダンなレンダリング戦略を実践的に学べる環境として最適だと感じたためです 2. プルリクエストごとに自動生成されるプレビュー環境も便利だからです 3. デプロイの自動化によってインフラ設定に時間を取られず、アプリケーションロジックの実装に集中できるためです - **GitHub Actions(CI/CD)** - なぜ使用したか 1. コードの品質を自動的に担保する仕組みが欲しかったためです 2. CI/CD による自動テスト・Lint・型チェックの実行をしたいからです 3. GitHub との統合によってワークフローが一元管理できてとても便利だからです - **その他使用ツール** - draw.io - Resend - Notion #### 主な機能 - **入札機能** - 概要 - 入札 - 自動入札 - 入札履歴 - 質問（Q&A)チャット機能 - ウォッチリスト/ - レビュー - 入札通知 - 終了間際の入札時の自動延長 - 延長回数上限機能 - デポジット返還スクリプト - 画面のスクリーンショット <p> <img src="public/bid_screenshot.png" alt="bid_image" width="600"> </p> - 詳細 1. `Server-Sent-Events`×`Upstash Redis Pub/Sub` の組合せ - 大変だった実装 1. サーバー側の再接続制御 - クライアント側の `Server-Sent-Events` 接続が切れた際の画面チラつきが発生していました - そのチラつきを無くすために、サーバー側の`while`で持続できるよう工夫しました 2. `Upstash`,`Vercel` の `Server-Sent-Events` の長時間接続の制約への対処 - そもそも購読ユーザーに対して一斉に通知するには、特別な実装が必要だと理解しておらず、AI に的外れな相談ばかりしていました - その後、Vercel のサーバーの性質（Vercel のサーバーレスはステートレスで、複数のインスタンスで実行してインスタンス間では情報共有されないため、`Server-Sent-Events` の配信先の情報が取得できない）を理解して、`Upstash Redis Pub/Sub`を使用すれば、外部のインメモリのストレージを使用して `Server-Sent-Events` の配信先の情報を保存できることを理解しました - その後、サーバーからクライアントへは `Server-Sent-Events` で接続して、サーバーには Upstash Redis Pub/Sub でリアルタイム通信を行う実装に変更しました - その後、`Upstash Redis Pub/Sub`の接続が 1 分弱の短時間で切れる事象が発生しました - Upstash の無料枠の接続数上限に引っかかりやすくなるため、接続時間を増やすため、`fetch`オプションで`cache: "no-store"`を削除して接続時間を伸ばしました - 次に、接続が 5 分で切れる事象が発生しました - Vercel の実装やドキュメントを読み込んで原因調査した結果、Vercel Edge Runtime で fetch したときの内部で使用される`undici`ライブラリの接続時間のデフォルトが 300 秒で、それを回避する方法はないことが判明しました - 改善するためには、`Cloudflare Workers`にデプロイすれば改善しそうですが、工数的にいったんは Vercel デプロイのままにしました 3. クライアント側の `EventSource` ベースのデータ取得処理・再接続・エラー時の UX を実装（`use-auction-bid-sse.ts`） - `Server-Sent-Events`で受け取るデータ構造が少し複雑だったので、データを抽出する処理が手間取りました - 実装理由 - 競り上がりの体験をリアルタイムかつ低レイテンシで実現し、ページ再読み込みに依存しない快適な UX を提供したいと考えたためです - 使用したライブラリ、サービス 1. Upstash Redis Pub/Sub - 同じオークション商品ページを開いているクライアント全員に一括通知するために使用しています - 他者が入札したら、同じページを開いている全員の画面が更新されます 2. Prisma のトランザクションと楽観的ロック（`Auction.version`）で同時入札を整合的に処理 3. 最高入札者の更新時に OUTBID 通知（Web Push/Email/In-App）を即時送出 - **push 通知** - 概要 - VAPID 署名付き Web Push。Service Worker で受信し、OS ネイティブ通知を表示 - 購読は設定画面から ON/OFF を切替 - 画面のスクリーンショット <p> <img src="public/notification_screenshot.png" alt="notification_setting_image" width="600"> </p> - 実装した理由 - 入札競合・締切・結果など重要イベントをアプリ外でも即時に伝達し、再訪率を高めるためです - 大変だった実装 - `pushsubscriptionchange` の購読更新（SW→ クライアント or 直接 API 経由で `subscription-update` に保存）を実装しました - デバイスで重複の購読をしないよう実装しました - 同じユーザーでも端末ごとの購読を管理できるようにしました（同じユーザーでは設定を共有することも可能） - 無効購読（404/410)の自動削除を実装しました - Service Worker の特殊なライフサイクルを理解して実装するのが大変でした - 工夫・意識したこと - 設定画面から push 通知を ON にできる UI にしました - その際に chrome の権限許諾が出て OFF にしたらアプリ側の設定も OFF にするようにしました - **出品一覧** - 概要 - カテゴリ/状態/価格帯/残り時間/グループ/フリーテキストを クエリパラメータ（`nuqs`）と同期しフィルター・ソート・ページネーション - サジェスト取得・件数取得をサーバー側でキャッシュし、描画と操作の体感速度を最適化 - INDEX を作成して、検索速度の向上 - 実装した理由 - 多条件での探索性・再現性（URL 共有）・パフォーマンスを両立するためです - 大変だった実装 - いいね（お気に入り）を実装しました - ページネーションを実装しました - 並び替え＋ページネーション保持を実装しました - 絞り込み検索＋ページネーション保持を実装しました - N+1 問題解消、索引最適化、キャッシュレイヤとの整合を行いました - 工夫・意識したこと - 条件オブジェクト（`AuctionListingsConditions`）を型で表現し、URL⇄ 状態の相互変換を一元化しました - キャッシュ/API レイヤと UI の責務分離（一覧/件数/サジェストを個別最適化）しました - 「Bigram の 2 文字分割」と「TokenMekab による形態素解析の分割」の 2 つのトークナイザーでインデックスして、誤字脱字と多少の意味的な単位で検索やサジェストができるようにしました - ベクトル検索は費用面を考えて実装しませんでした - その他の機能は以下 URL に記載 - <a href="https://zenn.dev/329/articles/0d13b45c46330f" target="_blank">https://zenn.dev/329/articles/0d13b45c46330f</a>

- **詳細** - <a href="https://github.com/yuichisugio/freeism-calc-contrib" target="_blank">https://github.com/yuichisugio/freeism-calc-contrib</a> - **概要** - 指定したソフトウェアを、設定ファイルの重み付け値を使用して、各開発者・各ソフトウェアの貢献度を算出するコードです - **実装期間** - 2025 年 09 月〜2025 年 10 月 - **作成した理由・解決したい課題・なぜ作ったか** - 開発者の貢献度を算出することで、報酬を得るべき人たちと得るべき量を視覚化したいと考えました - **使用した言語・ライブラリ** - シェルスクリプト - jq - **頑張った実装・工夫した実装** - 使用されることよりも自分が実現したいことを理解してもらうことを第一目標にしたため、ライブラリを使用せず皆が使うシェルスクリプトの簡単な文法のみで完結するよう実装しました - **苦労した点** - GitHub GraphQL API のフィールドの構造を把握するのが苦労しました

- **詳細** - <a href="https://github.com/yuichisugio/freeism-depchecker" target="_blank">https://github.com/yuichisugio/freeism-depchecker</a> - **概要** - 指定したソフトウェアが依存しているソフトウェア一覧を出力します - **実装期間** - 2025 年 08 月〜2025 年 09 月 - **作成した理由・解決したい課題・なぜ作ったか** - 指定ソフトウェアを成り立たせるのに貢献したソフトウェアの貢献度を算出するために、一覧が欲しいからです - `freeism-calc-contrib`で算出する各ソフトウェアごとの貢献度の算出に依存ソフトウェア一覧を使用します - **使用した言語・ライブラリ** - シェルスクリプト - jq - **頑張った実装・工夫した実装** - 使用されることよりも自分が実現したいことを理解してもらうことを第一目標にしたため、ライブラリを使用せず皆が使うシェルスクリプトの簡単な文法のみで完結するよう実装しました

### 実装コード - <a href="https://github.com/yuichisugio/gas" target="_blank">https://github.com/yuichisugio/gas</a> - 公開しているコードはテスト的に実装した内容です - 実際は、より業務内容にカスタマイズした内容になっています（非公開） ### 概要 - 業務効率化のために Google Apps Script を使用してあらゆる作業を自動化した ### 抱える課題 - 手作業で編集することが多く、自動で行えるようにしたい場面が多いため - また、既存ツールでは制約があるので、よりカスタマイズして業務に適したツールを自作したい場面が多いため ### 使用した技術 - Google Apps Script - JavaScript - Slack API - Google Forms - Google SpreadSheets ### 工夫 - メンテナンスしやすいようにコメントを丁寧に入れたり、可読性の高いコードを意識しました ### どのような成果が出たのか - 20 種類以上の Google Apps Script を実装し、手作業だった定型業務を自動化してチーム全体の作業時間を大幅に削減した - 業務フローをヒアリングして使いやすいデータ形式を整えたことで、メンバーから「作業が楽になった」「ミスが減った」とフィードバックを得た - 業務効率化の価値を上司に提案し、業務時間内に改善施策を進めるための開発時間を確保できる体制を整えた