Shogo Komori (Born: Shogo Hida)小森翔吾(旧姓 樋田)

A retrieval-augmented QA system over GHG Protocol, CSRD/TCFD, and internal emissions-accounting documents — every answer cites its source.

GHGプロトコル・CSRD/TCFD開示ガイドライン・社内算定マニュアルなどを検索し、根拠となる出典を明示したうえで回答するRAGシステム。

Role-based access control by department, Recall@K search-quality evaluation, and IP rate limiting for public deployment — extends the climate-tech domain expertise from Zeroboard into a standalone, production-minded system.

部署ごとのRBAC、Recall@Kによる検索精度の定量評価、公開運用を想定したレート制限まで実装。ゼロボードで培った気候テック領域の知見を、単体の本番運用可能なシステムとして再構築。

When an alert fires, it gathers logs, deploy history, and metrics, hands them to an LLM, and returns a structured root-cause report — before a human opens a dashboard.

アラート発火時にログ・デプロイ履歴・メトリクスを収集してLLMに渡し、担当者がダッシュボードを開く前に構造化された根本原因レポートを生成する。

A from-scratch, open-source generalization of the Claude-driven bug-investigation system I built and ran in production at Zeroboard, cutting mean time to diagnosis by ~50%. Runs free on local Ollama or on the Claude API; the public demo runs the same system prompt against a small in-browser model via WebLLM.

ゼロボードで構築・運用したClaude活用のバグ調査自動化システム（調査時間50%削減）を、依存ライブラリなしのOSSツールとしてゼロから汎用化。Ollamaでローカル無料実行も可能。公開デモは同じシステムプロンプトをWebLLMでブラウザ内の小型モデルに対して実行。

A replicated key-value store built on a from-scratch implementation of the Raft consensus algorithm — leader election, log replication, and persistence — with a live browser demo of elections in action.

Raftコンセンサスアルゴリズムをゼロから実装し、その上にレプリケーションされたキーバリューストアを構築。リーダー選出をブラウザからリアルタイムに確認できるデモ付き。

Production experience with distributed systems doesn't automatically prove consensus-level reasoning. This is a correct, tested implementation of the algorithm behind etcd, Consul, and CockroachDB.

実務での分散システム経験だけでは、コンセンサスレベルの理論的な正しさは証明できない。etcd・Consul・CockroachDBを支えるアルゴリズムを、テスト付きで正確に実装。

Push every post to followers' feeds at write time, or compute the feed on demand at read time? A synthetic 8,000-user network with a handful of celebrity accounts turns this textbook trade-off into a measured one — push cost spikes with follower count while pull and the hybrid real systems use stay flat.

投稿をフォロワーのfeedへ書き込み時にPushするか、読み込み時にPullで都度計算するか。数千フォロワーの有名人アカウントを含む合成8,000ユーザーネットワーク上で、この教科書的トレードオフを実測値として可視化。Pushのコストはフォロワー数に比例して急増する一方、Pullと実システムが採用するHybridはコストが平坦なままであることを示す。

System design interviews ask this exact question — push, pull, or hybrid — almost every time. This doesn't diagram the answer; it measures the real write/read cost against a graph shaped like the problem, and a test proves the three strategies never disagree on content, only cost.

システム設計面接ではPush・Pull・Hybridのどちらを選ぶかがほぼ必ず問われる。この実装は答えを図で説明するのではなく、問題の形をした実際のグラフに対して書き込み・読み込みコストを実測し、3つの戦略が結果の内容では絶対に食い違わず、コストだけが違うことをテストで証明している。

A minimal S3-like object store built from scratch: consistent hashing places every object on a ring of storage nodes, and Dynamo-style sloppy quorum reads/writes — no leader, no single point of failure — keep it durable and available even when nodes fail. Live browser demo of the ring, replication, and a node-failure drill.

ゼロから実装した最小限のS3風オブジェクトストア。一貫性ハッシュ法で全オブジェクトをストレージノードのリング上に配置し、Dynamo方式のsloppy quorumによる読み書き——リーダーも単一障害点もなし——により、ノード障害時でも耐久性と可用性を維持する。リング・レプリケーション・ノード障害シミュレーションをブラウザで確認できるデモ付き。

`raftkv` proves the other half of this problem — a leader and consensus guaranteeing strict order. Real object stores like S3 and DynamoDB bet the opposite way: no leader, durability from quorum overlap instead. This implements and tests that side of the trade-off, including the proof that killing a node doesn't lose data.

`raftkv`はこの問題のもう半分——リーダーとコンセンサスによる厳密な順序保証——を証明している。S3やDynamoDBのような実際のオブジェクトストアは逆の賭けをする：リーダーなし、クォーラムの重なりから耐久性を得る方式だ。本プロジェクトはそちら側のトレードオフを実装・テストしており、ノードを1台落としてもデータが失われないことも証明している。

A minimal EC2-like fleet manager: instances (small/medium/large) get placed onto hosts by a best-fit bin-packing scheduler, and killing a host triggers a real relaunch attempt elsewhere — the fleet self-heals when capacity allows, and honestly reports what it couldn't save when it doesn't. Live demo of packing, host failure, and best-fit vs. round-robin placement measured side by side.

ゼロから実装した最小限のEC2風フリート管理システム。small/medium/largeのインスタンスをベストフィット型のビンパッキング・スケジューラでホストに配置し、ホストを1台落とすと別ホストへの実際の再起動を試みる——容量に余裕があればフリートは自己修復し、余裕がなければ何を救えなかったかを正直に報告する。パッキング・ホスト障害・ベストフィット対ラウンドロビン配置の比較をブラウザで確認できるデモ付き。

`raftkv` and `objectlab` are both about keeping the same data alive across replicas. Compute scheduling is a different problem: placing variably-sized, mutually-exclusive workloads onto capacity-constrained hosts efficiently — the algorithm family behind Kubernetes, Nomad, and Borg. This measures that trade-off directly: best-fit packs strictly more instances onto the same hosts than naive round-robin placement, proven against real launch sequences, not asserted.

`raftkv`と`objectlab`はどちらも「同じデータをレプリカ間でどう生かし続けるか」の話だ。コンピュートのスケジューリングは別の問題:サイズの異なる、互いに排他的なワークロードを容量制約のあるホストに効率よく配置すること——Kubernetes・Nomad・Borgのスケジューラの背後にあるアルゴリズム群だ。本プロジェクトはそのトレードオフを直接実測する:ベストフィットは、実際の起動リクエスト列に対して、素朴なラウンドロビン配置よりも明確に多くのインスタンスを同じホスト群に収容できることを、主張ではなく証明している。

Run a query unindexed and watch it scan; add the suggested index and rerun the same query to see the plan flip to a search — plus a natural-language-to-SQL panel that runs entirely in your browser, no server-side model or API key.

インデックスなしでクエリを実行してスキャンを体感し、推奨インデックスを追加して同じクエリを再実行すると実行計画がサーチに切り替わる。自然言語→SQL変換パネルはブラウザ内だけで完結し、サーバー側モデルもAPIキーも不要。

The reproducible version of a résumé claim — "40% performance improvement via load profiling and indexing" — that a visitor can trigger themselves, not just read. The AI panel runs client-side via WebLLM/WebGPU so the public demo never calls a metered LLM API.

「負荷プロファイリングとインデックス最適化で40%改善」という職務経歴の一文を、訪問者自身が再現できる形にした。AIパネルはWebLLM/WebGPUでクライアント側実行のため、公開デモが従量課金APIを呼ぶことは一切ない。

Paste CREATE TABLE DDL plus a sample of real rows and it empirically detects normalization violations — a non-key column silently repeating the same paired value across rows — then suggests the table split that fixes each one. A bundled scenario injects a new requirement into a naive schema and its normalized twin side by side, so you can watch one absorb it cleanly and the other reintroduce the redundancy.

CREATE TABLEのDDLと実データのサンプルを貼り付けると、非キー列が複数行にわたって同じ値を無自覚に繰り返している正規化違反を経験的に検出し、解消するためのテーブル分割案を提示する。同梱シナリオでは素朴なスキーマと正規化済みスキーマの両方に同じ新要件を注入し、片方は綺麗に吸収し、もう片方は重複を再び生む様子を並べて見せる。

The design-time counterpart to sqllab's runtime query optimization — the reproducible version of a real lesson from a Zeroboard emissions dashboard: columns that turned out to be missing had to be added later, and the table needed renormalizing once that redundancy became a real problem. The AI panel explains findings the deterministic analyzer already made — it never invents violations of its own — and runs client-side via WebLLM/WebGPU like sqllab's.

sqllabがクエリ実行時の最適化なら、こちらは設計時の対になるプロジェクト。Zeroboardの排出量ダッシュボードで、後から必要なカラムが判明して追加し、その重複が実害になった時点でテーブルを正規化し直したという実体験を再現可能にした。AIパネルは決定的なアナライザーが既に検出した内容を説明するだけで発見を捏造せず、sqllabと同じくWebLLM/WebGPUでクライアント側実行。

Three fictitious new customers, each with a differently-shaped GHG data export — English, Japanese, category codes needing a lookup table — mapped by the same deterministic engine onto one canonical schema. It scores every mapping on header-name match and value shape, and flags exactly what it can't be confident about instead of guessing.

形式の異なる3社の架空顧客のGHGデータエクスポート（英語、日本語、ルックアップテーブルが必要なカテゴリコード）を、同一の決定的エンジンで単一の正規スキーマにマッピングする。ヘッダー名の一致度と値の形状の両方でスコアリングし、確信が持てない箇所は推測せず明示的にフラグする。

The reproducible version of "partnered directly with Customer Success and enterprise clients to translate business problems into technical specifications" — the Forward Deployment motion of turning someone else's messy export into a working, customized fit before assuming the platform is generic enough to work as-is. A bundled discovery-call note per customer, and a client-side WebLLM panel that explains (never invents) how that note resolves a flagged ambiguity.

「CS担当・顧客と直接コミュニケーションを取りながら課題を深く理解し、仕様へ落とし込む」という職務経歴を再現可能にしたもの。プラットフォームが汎用のままで動くと決めつける前に、他社の乱雑なエクスポートを実際に動く形へ落とし込むという、Forward Deployment的な動き。顧客ごとのディスカバリーコール・ノートを同梱し、クライアント側WebLLMパネルがそのノートがフラグされた曖昧さをどう解決するかを説明する（新たな判断を捏造することはない）。

A hybrid static-analysis + Claude AI tool that flags Clean Architecture violations — forbidden imports, layer boundary breaks, mixed responsibilities — as GitHub PR comments or via an MCP server for Claude Desktop.

AST静的解析とClaude AIのハイブリッドでClean Architecture違反（禁止import・レイヤー依存違反・責務混在）を検出し、GitHub PRへ自動コメントするか、MCPサーバーとしてClaude Desktopから呼び出せる。

Deterministic checks (imports, dependency direction) run as free AST analysis; only judgment calls that need real understanding go to the LLM. Turns "300+ PR reviews enforcing Clean Architecture" into reusable tooling.

決定的に判断できる検査（import・依存方向）は無料のAST解析で、意味理解が必要な判断だけをLLMに任せる設計。「300件以上のPRレビューでClean Architectureを徹底した」実務経験を再現可能なツールとして公開。

A full-stack Instagram clone — signup/login, image posts, a following-based feed, likes, comments, 24-hour stories, direct messages, and notifications — built end to end on Go, Echo, and GORM.

Instagram風のフルスタックアプリ。サインアップ/ログイン、画像投稿、フォローベースのフィード、いいね、コメント、24時間ストーリー、DM、通知を、Go・Echo・GORMで一貫して実装。

Unlike most of the other cards here, this one isn't reproducing a single résumé line — it's reproducing the *stack*. My résumé lists "Backend & APIs: Go (Echo, Gorm)," and this app exercises that stack across a full multi-resource, auth-gated surface, the shape of real product work rather than a single-concept demo.

他の多くのカードと違い、これは特定の実務経験ではなく「技術スタックそのもの」を再現するプロジェクト。職務経歴書の「バックエンド・API: Go (Echo, Gorm)」という記載を、認証付き・複数リソースにまたがるフルCRUDの実プロダクトに近い規模で実証する。

A same-day delivery dispatch problem — modeled on Amazon last-mile and Rakuten EC logistics — solved by chaining four algorithms: Dijkstra shortest paths over a congested road grid, bin packing for truck loading, nearest-neighbor + 2-opt for routing, and greedy time-window scheduling.

Amazonのラストマイル配送・楽天のEC物流を想定した当日配送ディスパッチ問題を、渋滞グリッド上のDijkstra最短経路・トラック積載のビンパッキング・最近傍法+2-optによる経路構築・貪欲法の時間枠スケジューリングという4つのアルゴリズムを連結して解く。

A naive load-order route and the fully optimized route run side by side over the identical truck assignment, with a step-by-step 2-opt swap animation — the optimization is watchable, not just a before/after number.

素朴な積載順ルートと最適化後ルートを、同一のトラック割当の上で並べて比較。2-optの改善過程を1手ずつアニメーション再生でき、最適化の効果を数字の提示だけでなく実際に見て確認できる。

A transformer inference engine built from scratch in pure Go — no PyTorch, no ONNX Runtime, no cgo. The forward pass, a KV cache, int8 weight-only quantization, and a decode-only continuous batching scheduler, running a real Llama-2-architecture model.

Go言語のみでゼロから実装したTransformer推論エンジン（PyTorchもONNX Runtimeもcgoも不使用）。フォワードパス・KVキャッシュ・int8重みオンリー量子化・デコード時のみのcontinuous batchingを実装し、実在のLlama-2アーキテクチャモデルを実行する。

Not tied to a résumé line — this one's aimed at the systems fundamentals a Google/Amazon/Meta-tier infra interview actually probes: why a KV cache is provably correct, not just faster (tested, not assumed); why attention can't batch like a feed-forward layer; why quantization is a real memory/compute trade-off. The benchmark panel reports live-measured tokens/sec across five configurations, including an honest result a hand-wavy writeup wouldn't show: int8 quantization saved memory but didn't clearly win on speed, since this Go implementation has no SIMD int8 path.

職務経歴の一文には紐づけていない一枚。狙いはGoogle/Amazon/Meta級のインフラ面接が実際に問うシステムの基礎——KVキャッシュがなぜ「速いだけでなく正しい」と証明できるのか（想定ではなくテスト済み）、アテンションがなぜFFN層のようにバッチ化できないのか、量子化がなぜ本物のメモリ／計算トレードオフなのか。ベンチマークパネルは5つの設定でのtokens/secを実測表示し、その中には「int8量子化はメモリを削減したが速度では明確に勝てなかった（SIMDのint8命令パスがGo実装にないため）」という、体裁を整えた説明では出てこない正直な結果も含まれている。

A Flutter mobile app for tracking a dog's health records, weight history, and GPS-logged walks — backed by a from-scratch Go API (`dogapp-api`) with JWT auth, Postgres persistence, and Claude-powered photo/video health checks.

犬の健康記録・体重推移・GPSによる散歩ログを管理するFlutterアプリ。バックエンドはPostgres永続化・JWT認証・写真/動画をClaude APIで解析する健康チェック機能を備えたGo実装のAPIサーバー(`dogapp-api`)。

Full-stack, end to end: the Flutter client and Go API are separate, independently tested repositories talking over a hand-specified JSON contract — EN/JA localization and a live GPS walk tracker (Haversine-computed distance) on the client, JWT-secured owner-scoped access control and bcrypt password hashing on the server. Auth tokens live in secure storage rather than plain SharedPreferences, and a rejected token triggers an automatic logout instead of failing silently — the kind of detail that only shows up once you're running something like this for real, not demoing it.

FlutterクライアントとGo APIを別リポジトリとして分離し、それぞれ独立してテスト可能な構成でエンドツーエンドの開発を担当。クライアント側は日英ローカライズとGPSによるリアルタイム散歩記録(Haversine公式で距離を計算)、サーバー側はJWT認証・所有者スコープのアクセス制御・bcryptによるパスワードハッシュ化を実装。ログイントークンは平文のSharedPreferencesではなくセキュアストレージに保存し、トークンが無効化された際は静かに失敗するのではなく自動ログアウトする——実際に動かし続けて初めて気づくような細部まで作り込んでいる。