Alcogy Tech Blog
SvelteKit・Cloudflare・AI・アーキテクチャ設計など、 現場で得た技術的な知見を発信しています。
TCPヘッダのparse/buildの上に、stop-and-wait方式によるシーケンス番号管理・タイムアウト再送・簡易フロー制御を実装します。合わせて、OSの標準ソケットAPIを経由せず生ソケットで自前のTCPコネクションを実装したときに必ず踏む、「送信元マシン自身のカーネルが身に覚えのないセグメントへRSTを送り返してしまう」という設計上の制約と、その回避方法についても扱います。
TCPヘッダはICMP/UDPと違い、フラグ・シーケンス番号・可変長のオプションを持ちます。3-wayハンドシェイクに必要な範囲でヘッダの型を設計し、UDPと同じ疑似ヘッダ方式のチェックサムを再利用しつつ、UDPには存在する「0はチェックサム未使用」という読み替えがTCPには不要である理由にも触れます。最後に、実際にLAN上のホストとSYN/SYN-ACK/ACKを交わすところまで確認します。
MCP Apps（ui://リソースによるインタラクティブUI拡張）を使い、カウンターウィジェットを題材にサーバー・クライアントを実装したハンズオンの記録です。MCPコア仕様の最新バージョンとnpmパッケージが実際に対応しているバージョンにズレがある点や、公式SDKの実装ポイント、セッション設計を中心にまとめます。
AIエージェントにDB検索を任せる際、ツールに用意されていないカラムでの絞り込みが実は動いていなかった、というケースをきっかけに、SvelteKit + DrizzleORM + Cloudflare D1 + Anthropic Tool Useで安全な動的クエリビルダーを実装しました。AIには`{field, operator, value}`という「意図」だけを渡させ、実行はサーバー側の許可リストが握るという設計を整理します。
デスクトップアプリの開発でSvelte + Tauri(Rust)を選んだ理由と、実際に重い処理を書いた上で見えてきたメリット・デメリットを実体験ベースで整理します。「TauriとSvelteでネイティブアプリを作ってみた」という入門記事ではなく、実装を通して得られた知見に絞った内容です。開発していたプロジェクトの詳細は記事末尾で触れています。
モジュールスコープに置いた$stateは、writableストアを使わずにアプリ全体で共有できる「グローバル変数」として機能します。ただしSvelteKitのSSRではこれだけでは足りません。多言語切り替えを例に、クライアントのリアクティブ更新・SSRでの初期表示・チラつき防止という3つの役割をどう分担させるかを整理します。
Copilot + PCとMacBook Airで、ローカルAI推論の速度は実際どれくらい違うのか。Foundry Localを使って、手元の2台でCPU・GPU実行のベンチマークを取ってみました。
propsの値をそのまま$stateの初期値に使うと、Svelteのコンパイラがstate_referenced_locallyという警告を出すことがあります。この警告が何を指摘しているのか、$derivedとuntrack()のどちらで解決すべきかを実例で整理します。
モバイル向けのCPU/NPUは省電力・小型・小規模タスクに最適化され、デスクトップのGPUは高電力・大規模タスクに最適化されています。最適化の方向性が異なるこの2つを、LAN経由で組み合わせる「ネットワークGPU」構成が、互いの苦手分野をどう補うかを整理します。
モバイル向けノートPCのGPU/NPUの非力さを補うため、型落ちのGeForce GTX 1080Tiを積んだUbuntu機にRust+llama.cppでローカルAI推論サーバーを自作しました。Foundry Localを使わなかった理由、ビルドで詰まったポイント、実測9.2倍という数字を紹介します。
Claude DesktopのようなクラウドAI前提でMCPサーバーを解説した記事の姉妹編として、Foundry LocalのようなローカルAIランタイムでMCPを使う場合に何が変わるかを整理します。コード例は実際に動かして疎通確認まで行ったC#/.NET製のstdio MCPサーバー・クライアントをもとにしています。
Copilot+ PCのようにNPU搭載を訴求するマシンが増えていますが、「NPUがAIに最適」というメッセージは省電力の文脈でのみ正確です。推論性能そのものではGPUが依然優位という整理と、それでもNPU搭載機が無意味ではない理由を解説します。
Microsoft Foundry Localのような登場によって、ローカルAIの導入障壁は下がってきています。とはいえクラウドAIを丸ごと置き換えるものではありません。コスト構造・レイテンシ・プライバシー・モデル品質・運用負荷という開発観点の軸で、両者の向き不向きを整理します。
端末上でLLMを動かすローカルAIは、以前は環境構築だけでかなりの手間がかかりました。Microsoft Foundry Local（2026年4月にGA）は、この手間を数コマンドまで圧縮しています。何が変わったのか、そして現時点での限界を整理します。
プロトタイプ開発の「製造」フェーズは、仕様書からゼロでコードを書き起こす一般的な製造フェーズとは性質が異なります。既に動くプロトタイプの実装を土台に本番品質へ仕上げていく、実質的にはリファクタリングに近い作業だという観点を整理します。