flipslidersand

## どんなサービス・システムか 架空のマーケットプレイス企業を想定し、注文・在庫・価格の3系統がJSON/CSVでバラバラに出力され、 在庫切れリスクや異常な価格変動、重複注文による売上水増しを運用チームが手作業のスプレッドシート 突合でしか検知できない、という状態を技術評価課題として設定した。 ## 体制・担当範囲 1名体制（個人開発）。要件整理（8項目の成功基準の言語化）、Medallion Architecture（Bronze/Silver/Gold） の設計、PySparkによるETL実装、Silver層のバリデーション・重複排除ロジック、Delta LakeのMERGE/OPTIMIZE/ タイムトラベル運用モジュール、テスト設計（31ケース）、GitHub Actions によるCI構築、Databricks SQL 経由のStreamlitダッシュボード連携まで、企画からリリースまでの全工程を1人で担当。 ## 思考プロセス 「PySparkの文法を見せる」のではなく「顧客の曖昧な業務課題を、検証可能な成功基準とアーキテクチャに 翻訳できるか」を自分自身への評価軸にした。まず8項目の成功基準（例:不正レコードが集計を汚染しない ことをどう検証するか）を先に文章化し、それを満たすためにBronze/Silver/Gold の責務分割を逆算で設計した。 ## 開発した機能 - 在庫リスク・価格異常・重複注文を検知するGold層集計（daily_revenue / inventory_risk / price_anomalies） を実装し、運用チームが手作業のスプレッドシート突合で行っていた異常検知を自動化した - 不正レコードを握りつぶさず `_quarantine_reason` 付きで隔離テーブルに退避する仕組みを実装し、 異常検知の精度そのものより「なぜ弾かれたか」を後から追跡できる状態を優先した - Databricks SQL経由のStreamlitダッシュボードで日次売上・在庫リスク・価格異常を可視化し、 意思決定に必要な指標を運用チームが即時確認できるようにした ## 工夫したこと - 不正レコード（ID欠損・数量ゼロ等）を握りつぶさず `_quarantine_reason` 付きで隔離テーブルに退避し、 後から調査可能な形にした - 重複注文をSilver層でdedup後にGold集計することで、売上水増しを構造的に防止 - ローカルで2分以内に全パイプラインが再現できるように、合成データ生成からCIまで一気通貫で構築 - Delta LakeのMERGE upsert・OPTIMIZE・タイムトラベルを別モジュール化し、運用面（再処理・履歴参照）まで想定 ## 成果 - テスト31/31 pass、GitHub ActionsでCI常時グリーン化 - Databricks SQL経由でStreamlitダッシュボードから在庫リスク・価格異常・日次売上を可視化するところまで エンドツーエンドで動く状態を1週間で完成

## どんなサービス・システムか SQLite FTS5によるBM25キーワード検索と、multilingual-e5-baseによるベクトル検索をRRF （Reciprocal Rank Fusion）で統合したハイブリッド検索エンジン。Ollama連携でRAG回答生成 （/ask）も提供し、Claude CodeからMCPサーバーとして直接呼び出せる。 ## 体制・担当範囲 1名体制（個人開発）。要件定義、BM25検索エンジン、ベクトル検索+RRF統合ロジック、FastAPI REST API、 RAGパイプライン（Ollama連携）、Qdrantバックエンド移行、リモート埋め込みサービス連携、 MCPサーバー実装、Prometheusメトリクス計装までを8フェーズに分けて全工程担当。 ## 課題 キーワード検索（BM25）だけでは意味的に近いが表記の異なる文書を拾えず、逆にベクトル検索単体 では固有名詞やコードの完全一致検索に弱い。両方を単に併用するのではなく、検索結果をどう統合 すれば実用的な精度になるかが課題だった。また、埋め込み生成をどの段階でどう最適化するかが RAG精度に直結する部分として重要だった。 ## 思考プロセス BM25とベクトル検索を「足し合わせる」のではなく、RRF（Reciprocal Rank Fusion）でランキング 統合する方式を採用。さらに埋め込み生成をローカル計算からMINIPC上のリモート埋め込みサービスに 切り出し、単発呼び出しからバッチAPI優先＋失敗時は直列フォールバックする構成に発展させることで、 RAGパイプラインの「検索精度」と「埋め込み生成の効率」を別々に改善できる構造にした。 ## 開発した機能 - BM25キーワード検索とベクトル検索をRRFで統合したハイブリッド検索モードを実装し、 単一方式では拾えなかった検索漏れを減らした - `/ask` エンドポイントでRAG回答生成を実装し、検索結果の根拠(sources)付きで自然言語回答を 返せるようにした - リモート埋め込みサービスのバッチAPI対応を実装し、大量ドキュメントのインデックス構築を高速化した - Prometheusメトリクス（search_latency_seconds / rag_latency_seconds等）を実装し、 検索・RAGのレイテンシを運用側で継続的に監視できるようにした - MCPサーバーを実装し、Claude Codeから直接この検索エンジンを呼び出せるようにした ## 工夫したこと - パストラバーサル対策として `ALLOWED_INDEX_DIRS` を必須化し、`/index` が任意ディレクトリを 読めない設計にした - SQLiteとQdrantの両方に対応するVectorStoreインターフェースを設計し、小規模はSQLite、 スケール時はQdrantに無停止で移行できる構成にした - リモート埋め込みサービスの障害時にローカルSentenceTransformers/ハッシュ埋め込みへ 自動フォールバックする設計にし、外部依存の単一障害点を作らないようにした ## 成果 実装済みの成果: - 8フェーズ（BM25→ハイブリッド検索→REST API→RAG→Qdrant移行→リモート埋め込み→MCP→メトリクス） を約2ヶ月で完遂しマージ済み - テスト189/192 pass（3件skip）、CI相当の検証を継続実施 - 本番運用中: Prometheusメトリクスによるレイテンシ監視、Discord通知連携まで稼働 残課題（Issue化・優先度管理済み）: - 例外ハンドリングパターンの統一（HTTPException変換の一貫性確認、#74）

## どんなサービス・システムか WebAssembly MVPバイナリフォーマットの全既知セクション（id 0〜12: Custom/Type/Import/Function/ Table/Memory/Global/Export/Start/Element/Code/Data/DataCount）を型付きRust構造体にデコードする バイナリパーサー。CLI（wasm-dump）でセクション一覧表示・詳細デコード・バリデーションを提供する。 ## 体制・担当範囲 1名体制（個人開発）。要件定義、8バイトモジュールヘッダー検証、LEB128（符号あり/なし）デコーダー、 全13種のセクションデコーダー、セクション横断バリデーション、CLIツール、proptestによる プロパティベーステストまでを全工程担当。 ## 課題 WebAssemblyのバイナリ仕様は「セクションIDごとに構造が異なる」「LEB128という可変長整数エンコーディング を境界チェック込みで正しく実装する必要がある」など、パーサー自体の正しさを保証するのが難しい領域。 既存のwasm系クレートはランタイム実行に主眼があり、仕様の全セクションを型として明示的に表現し、 教材・検証用途に使えるパーサー単体の実装が手薄だった。 ## 思考プロセス 「動くパーサーを書く」のではなく「仕様のどの部分が壊れるとどう失敗するか」を先にエラー型 （ParseError / ValidationError）として設計してから実装した。特にLEB128はオーバーフローや 不正な終端ビットなど仕様上のエッジケースが多いため、通常のユニットテストに加えてproptestで ランダム入力に対する不変条件（デコード→エンコードで元に戻る等）を検証する構成にした。 ## 開発した機能 - 全既知セクション（id 0〜12）のデコーダーを実装し、任意のWebAssemblyモジュールを型安全に 解析できるようにした - セクション横断バリデーション（`validate()`）を実装し、Function宣言とCode本体の数の不一致など 単一セクション内では検出できない不整合を検知できるようにした - `wasm-dump` CLIを実装し、コンパクト表示・詳細デコード・バリデーションの3モードで 実際のwasmファイルをその場で検証できるようにした - `parse_module_with_events` によるコールバック方式のイベント通知を実装し、 大きなモジュールを一括ロードせず逐次処理できる拡張性を持たせた ## 工夫したこと - init_expr/offset_exprをConstExprという単一の型付き表現に統一するリファクタリングを行い、 セクションごとにバラバラだった定数式の扱いを一本化した - LEB128デコーダーにproptestを導入し、手で書いたテストケースでは見つけにくい境界値バグを ランダム生成入力で継続的に検出できるようにした - pre-commitでcargo fmt/clippyを強制し、CI通過前にローカルでスタイル・静的解析エラーを 検知できるようにした ## 成果 - 310テスト全てpass（0 failed）、Open Issue 0件で完結 - 全既知セクション（13種）のデコード・セクション横断バリデーション・CLIツールまで 約1ヶ月で完遂

## どんなサービス・システムか イベントをHTTP/NATS JetStreamで受信し、固定時間窓（tumbling window）・スライディング窓ごとに COUNT/SUM/MAX/MIN/AVGを集計、HAVING条件で閾値判定してアラートを発火する単一バイナリの ストリーム処理エンジン。Flink/Kafka Streamsのような重量級基盤を使わずに実現している。 ## 体制・担当範囲 1名体制（個人開発）。要件定義、HTTP/NATSイベント受信層、Tumbling/Sliding Window集計エンジン、 ルールベースパイプライン（filter→group_by→aggregate→having）、BadgerDBによる窓状態永続化、 watermarkによる遅延イベント補正、Prometheusメトリクス計装までを全工程担当。 ## 課題 ストリーム処理はFlink/Kafka Streamsのような重量基盤を使えば実現できるが、それらは運用コストが 高く、小規模な閾値監視・アラート用途にはオーバースペックになりがちだった。goroutine/channelを 使った並行処理、backpressure、遅延イベント補正といった分散ストリーム処理の核心部分を、 単一バイナリで自分の手で組み立てて理解することを目的にした。 ## 思考プロセス プロセスが再起動すると集計中の窓が消える、という単純な実装から始めるのではなく、先に 「watermark（max event ts − 許容遅延）で窓をいつクローズするか」「クローズ後に遅延到着した イベントをどう補正して再アラートするか」という分散ストリーム処理特有の難所を設計に組み込んでから 実装した。永続化もBadgerDBへのオプトインとし、インメモリ運用と永続化運用を切り替えられるようにした。 ## 開発した機能 - HTTP `/events` とNATS JetStream（at-least-once）の両方からのイベント受信を実装し、 チャネルフル時のbackpressureも組み込んだ - rules.yamlによるfilter→group_by（複数フィールド対応）→aggregate→having のパイプラインを実装し、 コードを書かずにルール追加できるようにした - BadgerDBによる窓状態の永続化とプロセス再起動後のresumeを実装し、集計の継続性を確保した - watermarkベースの遅延イベント補正・再アラートを実装し、ネットワーク遅延で遅れて届くイベントも 正しく集計に反映できるようにした - Prometheusメトリクス（streamrail_events_received_total等）を実装し、受信・ドロップ・ 窓クローズ・アラート発火数を運用側で監視できるようにした ## 工夫したこと - Sliding WindowとTumbling Windowを同じエンジンで扱えるよう抽象化し、ルール側の設定だけで 窓の種類を切り替えられるようにした - MAX/MIN/AVGをCOUNT/SUMの後から追加できる集計関数の拡張ポイントとして設計し、 ルールの表現力を段階的に広げられるようにした - Webhook通知シンクをコンソール通知と並行して追加し、通知先を増やせる構成にした ## 成果 実装済みの成果: - HTTP/NATS受信・Tumbling/Sliding Window・5種の集計関数・watermark補正・BadgerDB永続化・ Prometheusメトリクスまで、v1.0.0時点の機能を約2ヶ月で完遂 - 74テスト全てpass

## どんなサービス・システムか Gitリポジトリ全体をAIに渡すとノイズになる問題に対し、タスクに関連するコードだけをBM25検索と 依存関係グラフのBFSで自動選定し、指定トークン予算に収まるコンテキストバンドルを生成するCLI。 Rust/Python/Go/TypeScript/JavaScript/Rubyのシンボル抽出・依存解析に対応し、crates.ioに `context-smith`として公開している。 ## 体制・担当範囲 1名体制（個人開発）。要件定義、Git走査・tree-sitterシンボル抽出、BM25全文検索インデックス、 依存関係グラフのBFS拡張、トークン予算内での貪欲割当アルゴリズム、多言語対応（6言語）、 crates.io/docs.rsへのリリース作業までを全工程担当。 ## 課題 LLMにコード全体を渡すと、無関係なファイルがコンテキストを圧迫し精度低下とコスト増を招く。 一方で人手でファイルを絞り込むのは非効率で属人的になる。「タスクの説明文から、関連度の高い コードだけを機械的に選び出す」ことを、複数言語のコードベースに汎用的に適用できる形で 解決する必要があった。 ## 思考プロセス 単純なキーワード一致だけでは、直接キーワードを含まないが依存関係上重要なファイル（呼び出し元・ 呼び出し先）を見落とす。そこでBM25によるシンボル/本文検索でシード候補を選び、そこから 依存関係グラフをBFSで2ホップ分伝播させてスコアを減衰させる、という2段階のスコアリング パイプラインを設計した。最後にトークン予算内で貪欲法により採用ファイルを決定する。 ## 開発した機能 - tree-sitterによる6言語（Rust/Python/Go/TypeScript/JavaScript/Ruby）のシンボル抽出と import依存関係解析を実装し、言語ごとのパーサー差異を吸収する共通インターフェースを作った - BM25（シンボル×2重み・本文×1重み）による関連ファイル検索と、依存グラフBFSによる スコア伝播を実装し、キーワード一致だけでは拾えない関連コードも選定できるようにした - トークン予算内での貪欲割当とMarkdownバンドル出力を実装し、AIにそのまま渡せる コンテキストファイル一式を自動生成できるようにした - CI/JSON出力対応の `query` サブコマンドを実装し、スクリプトやCIパイプラインから 同じ選定ロジックを呼び出せるようにした ## 工夫したこと - インデックスをSQLite単一ファイル（file/symbol/deps/FTS5を1DBに集約）にすることで、 小規模リポジトリではindex.dbをチームで共有できる運用を可能にした - 差分埋め込み（変更のないファイルをスキップしバッチでストリーム処理）を実装し、 リポジトリが大きくなっても再インデックスのコストを抑えた - v0.1.0→v0.4.0の4回のリリースを通じて対応言語を段階的に拡張し（Rust→TS/JS→Ruby）、 後方互換を保ったままセマンティックバージョニングで機能追加した ## 成果 実装済みの成果: - crates.io / docs.rsに `context-smith` として公開、v0.1.0〜v0.4.0の4リリースを実施 （公開後ダウンロード64件） - 53テスト全てpass、CI（lint/test/coverage）を分離しカバレッジ閾値を運用 残課題（Issue化・優先度管理済み）: - `--version` フラグの追加（#111） - カバレッジ閾値の段階的引き上げ（36%→50%→75%、#110）

## どんなサービス・システムか LAN内はmDNSで自動検出、異なるネットワーク間はSTUN+リレーシグナリング+UDPホールパンチングで NAT越えする、QUIC上でNoise Protocol（XXハンドシェイク）により暗号化したP2Pファイル転送ツール。 BLAKE3-256によるハッシュ検証、中断からの再開、ディレクトリ転送、pipeモードまで実装している。 ## 体制・担当範囲 1名体制（個人開発）。要件定義、QUICトランスポート層、Noise Protocol暗号化ハンドシェイク、 mDNS自動検出、チャンク単位のresume/checkpoint機構、NAT越え（STUN+リレー+ホールパンチング）、 Web UI、リリース署名（cosign/Sigstore）までを全工程担当。 ## 課題 LAN内の単純なファイル転送だけでなく、異なるネットワーク間でのNAT越え、転送中断からの再開、 中間者攻撃への耐性を、既存の汎用ツール（scp/rsync等）を組み合わせるのではなく、 1つの筋の通ったセキュリティモデルとして実装する必要があった。特に自己署名証明書だけでは 中間者攻撃を防げない、という認証の弱さが早期から課題として見えていた。 ## 思考プロセス 転送の速度や機能追加を優先するのではなく、まず「暗号化・整合性検証・改ざん検知」を 土台として先に固める設計にした。QUICの各ストリームごとにNoise XXハンドシェイクを行い、 BLAKE3-256で到着後にハッシュ検証する、という2重の検証を組み込んだ上で、resume機構や ディレクトリ転送といった機能を段階的に積み上げるリリース戦略（v0.1.0→v0.9.0）を取った。 ## 開発した機能 - QUIC上でのNoise Protocol暗号化とBLAKE3-256整合性検証を実装し、転送の機密性と 改ざん検知を両立させた - チャンク単位のresume/checkpoint機構を実装し、大容量ファイル転送が中断しても 完了済みチャンクをスキップして再開できるようにした - STUN+リレーシグナリング+UDPホールパンチングによるNAT越えを実装し、異なるネットワーク間 でも中継サーバー経由でP2P転送を確立できるようにした - リリースバイナリをcosign（Sigstore keyless signing）で署名する仕組みを実装し、 ダウンロードしたバイナリの改ざんを利用者が検証できるようにした ## 工夫したこと - 自己署名証明書だけでは中間者攻撃を防げないという弱点を自分で発見し、 受信側から送信側へfingerprintを渡すことでMITM耐性を強化する仕組みを追加した - doReceiveDirのハッシュ検証とリネームを2パスに分離するなど、並行処理下での データ破損リスクを実装後にレビューで発見し都度修正した - v0.1.0から段階的に機能追加するリリース戦略を取り、9回のリリースを通じて ディレクトリ転送・Web UI・レート制限・圧縮など機能を安全に積み上げた ## 成果 実装済みの成果: - v0.1.0〜v0.9.0の9リリースを約3ヶ月で実施 - テスト373/374 pass 残課題（Issue化・優先度管理済み）: - webui認証テスト1件が現在失敗中（クエリパラメータトークン認証、要修正） - 実カバレッジ53%→60%以上への引き上げ（閾値チェックのbc計算バグを発見・修正し、 サイレント通過していた問題を可視化した、#542）