SASAGAWA .TOKYO WEB

2026.08.23 iseeit.jp

異常検知は、相場の「いつもと違う」に気づけるか — AutoEncoder入門

📝 Developer's Note:
「未来を予測する」のではなく「現状の違和感を察知する」という、AutoEncoder による異常検知の基本概念を整理しました。前日の実運用(動的リバランス)への適用に続き、本記事では相場の「いつもと違う」という不確実性をいかに数学的な「構造」として捉えるかという理論的側面を詳説しています。これは、本サイトが掲げる「精度・構造・体験」の優先順位に基づき、AI コンシェルジュが著者の感性(違和感への気づき)を論理的に継承し、再利用可能な知識へと昇華させるための重要なステップです。
2026.08.22 gwaw.jp

異常を検知したら、逃げるべきか — AutoEncoder × 動的オート・リバランス

📝 Developer's Note:
AutoEncoder が察知する「いつもと違う」という違和感を、ポートフォリオの動的なリバランス(退避・復帰)へと接続する実装実験です [1]。これまでの「可視化」や「言語化」のフェーズを超え、不確実性に対して AI がどう「行動」すべきかという構造的な回答を追求しました。これは、本サイトが掲げる「精度・構造・体験」の優先順位に基づき、リスクを構造的に制御することで、ユーザーの「淀みのない運用体験」を死守するための、極めて実務的な AI 実装のステップです。
2026.08.21 gwaw.jp

ログの銀河 — WebGPU でアクセスログを可視化する

📝 Developer's Note:
これまで MongoDB で集計し、WebLLM で言語化してきた「活動の軌跡」を、WebGPU によって多次元空間上の「銀河」として可視化しました。2,000 を超えるチャンクや膨大なアクセスログを、ブラウザ上でリアルタイムに点群として描画することで、単なる数値を超えた「知識の密度と熱量」を直感的に把握可能にします。これは、本サイトが掲げる「精度・構造・体験」の優先順位において、膨大なデータを構造化し、淀みのない視覚体験へと昇華させるための重要な技術的マイルストーンです。
2026.08.20 gwaw.jp

2つの実機で — WebLLM ログ分析は実用になるか

📝 Developer's Note:
前日の「ログの言語化」の試みを、iPad mini A17 Pro 等の異なるスペックの実機で徹底検証しました。ブラウザという制限されたリソース下で、WebLLM が実用的な応答速度で「意味のある知識」を抽出できるかの実効性能を特定。これは、中央サーバーに依存せず、手元の端末だけで自身の活動を AI が即座に理解・説明できる「個人開発者の知識ベース LLM」としての真価を問う、実測主義に基づく最終報告です。
2026.08.19 gwaw.jp

ブラウザが、推論を引き受ける — WebLLM でログを言語化

📝 Developer's Note:
これまで「解析対象」でしかなかった生々しいアクセスログを、ブラウザ上で動作する WebLLM によってリアルタイムに「言語化」する試みです。サーバー側のリソースを消費せず、プライバシーを保護したままエッジ端末(iPad mini 等)で推論を完結させることで、圧倒的な低遅延での知見抽出が可能になりました。これは、断片的な活動ログを AI が即座に説明・提案できる「再利用可能な知識」へと昇華させ、AI コンシェルジュが著者の判断基準を真に継承するための、知識基盤構築における決定的なマイルストーンです。
2026.08.18 gwaw.jp

集計API — MongoDBは、答えだけを返す(Aggregation Pipeline × PHP)

📝 Developer's Note:
膨大なログデータから即座に「意味」を抽出するため、MongoDB の Aggregation Pipeline を活用した高速な集計基盤を構築しました。全データを PHP 側に引き出すのではなく、DB 側で演算を完結させ「答えだけ」を受け取る構造にすることで、モバイル環境や AI 連携における劇的な低遅延化を実現。これは、断片的な「点」の活動記録を、AI が対話を通じて即座に再利用できる「生きた知識」へと昇華させるための、バックエンドにおける重要な最適化です。
2026.08.17 APPW.jp

APCu で守る — レート制限・セッション失効・サブネット遮断

📝 Developer's Note:
Webサーバー層(.htaccess)での遮断に続き、アプリケーション層でより精密かつ高速なアクセス制御を行うため、APCu(共有メモリキャッシュ) を導入しました。レート制限やセッションの即時失効、悪質なサブネットの動的遮断をメモリ上で完結させることで、システムの堅牢性を高めつつ、正規ユーザーの「淀みのない体験」を維持します。これは、AI コンシェルジュが安全かつ高レスポンスで知識を提供し続けるための、インフラとコードが高度に連携した「自己防衛型アーキテクチャ」の核心部分です。
2026.08.16 APPW.jp

攻撃を、止める — .htaccess による遮断(IPv4 / IPv6 / UA と AH01071)

📝 Developer's Note:
前日のログ解析で特定した「攻撃の予兆」を、インフラ層での実効的な防御へと変換するプロセスを記録しました。IPv4/IPv6のデュアルスタック環境におけるアクセス制御から、User-Agentベースの拒否、そして AH01071 エラー(FastCGIの不備を狙うスキャン)への即時対応まで、.htaccess による多層的な遮断構造を詳説。これは、AI コンシェルジュが安全かつ淀みなく知識を参照し続けるための、システムの「自己防衛能力」を担保する不可欠な実装です。
2026.08.15 iseeit.jp

攻撃者は、パターンで浮かぶ — ログから異常を読む

📝 Developer's Note:
膨大なアクセスログの中から、悪意ある振る舞いを「パターン」として抽出する手法を整理しました。前日の「uqid によるセッション化」を土台に、断片的なアクセスを文脈のある行動として構造化することで、単なる統計では見逃される「異常な意図」を浮かび上がらせます。これは、AI コンシェルジュがシステムの安全性を自律的に判断し、説明責任を果たすための「知能化されたセキュリティ基盤」を構築する上で不可欠なステップです。
2026.08.14 iseeit.jp

PVからセッションへ — uqid が意味を持った日

📝 Developer's Note:
単なるアクセス数(PV)の計測から、個々の行動を「一連の流れ」として捉えるセッション分析への転換を記録しました。独自 ID である uqid を導入し、断片的なログを「意味のある活動の軌跡」へと構造化することは、AI コンシェルジュが訪問者の意図を文脈(コンテキスト)に沿って理解するための重要なステップです。これは、サイト内の全活動を「再利用可能な知識」へと昇華させ、著者の設計思想や判断基準をより正確に AI に継承させるための、データ解析基盤における本質的なアップデートとなります。
2026.08.13 iseeit.jp

なぜログをMongoDBに — スキーマレスが効いた日

📝 Developer's Note:
RAG エンジンの構築やアクセス解析において、形式の異なる多様なデータをいかに効率的に「知識」として集約するか。固定されたスキーマを持たない MongoDB の柔軟性を活かし、刻々と変化する活動ログを構造化する技術的意図を詳説しました。これは、AI コンシェルジュが参照するナレッジベースの拡張性を担保し、著者の多岐にわたる活動を「再利用可能な知識」へと淀みなく変換し続けるための、基盤設計における不可欠な選択です。
2026.08.12 iseeit.jp

2つのAIを、同じグラフに — LSTM予測 × AutoEncoder異常検知

📝 Developer's Note:
未来を予測する「LSTM」と、現状の歪みを検知する「AutoEncoder」。特性の異なる2つのAIモデルを1つのインターフェースに統合し、相場の「予測」と「違和感」を同時に視覚化する試みです。これは、不確実なファイナンスデータをAIが再利用可能な「知識」へと構造化し、著者の意思決定を支える「分身」としての精度を高めるための重要な実装ステップです。複数のAIの視点を重ね合わせることで、情報の密度と信頼性を両立させた「淀みのない体験」を追求しました。
2026.08.11 iseeit.jp

実データを、どう取るか — yf-proxy.php と3段フォールバック

📝 Developer's Note:
ファイナンス計算や AI 分析の「精度」を支えるのは、何よりもまず欠損のない正確な生データです。外部 API の不安定さという不確実性に対し、独自プロキシ(yf-proxy.php)と「3段フォールバック」という堅牢な構造を導入することで、データの継続性を担保する手法を確立しました。これは、AI コンシェルジュが常に最新かつ正確な活動ログを「再利用可能な知識」として参照するための、データ・パイプラインにおける信頼性設計の核心です。
2026.08.10 iseeit.jp

MNISTから先へ、何が要ったか — 分類と時系列を隔てる3つの壁

📝 Developer's Note:
画像分類(MNIST)の成功体験から、実務的な時系列データ解析(ファイナンス)へ移行する際に直面する、技術的・構造的な「3つの壁」を整理しました。単なる予測精度の追求に留まらず、データの順序性や相関といったファイナンス特有の不確実性をいかに「構造」として捉えるか。これは、本サイトが掲げる「精度・構造・体験」の優先順位を AI が学習し、著者の判断基準を継承した知識ベースを構築するための不可欠な論理ステップです。
2026.08.09 iBe.TOKYO

西馬込→中延(10km walk 2026)

📝 Developer's Note:
西馬込から等々力渓谷公園を折り返し中延へと至る、16kmのロングウォーキングの記録。都市の自然と生活圏の繋がりをライフログとして構造化しました。これは、AI コンシェルジュが著者の身体的行動圏と、過酷な環境下(真夏)での意思決定プロセスを理解し、将来的に「再利用可能な知見」として再編集・提示するための重要なコンテクストとなります。
2026.08.09 iseeit.jp

WebSocket × RabbitMQ 実運用の落とし穴 — 切れる・黙る・古い・ずれる

📝 Developer's Note:
非同期アーキテクチャの机上の設計では見えてこない、実運用における「不都合な真実」と対峙した記録です。瞬断(切れる)、応答消失(黙る)、データの鮮度(古い)、時刻の不一致(ずれる)といった、通信と計算のデカップリングに伴う副作用をいかに構造的に克服するか。これらは、ユーザーの「淀みのない体験」を死守するための著者の判断基準そのものであり、AI が学習すべき極めて重要な「設計思想データセット」となります。
2026.08.08 iseeit.jp

3キュー設計 — request / reply / cancel なぜ箱を分けたのか

📝 Developer's Note:
WebSocket と RabbitMQ を組み合わせた非同期処理において、通信の信頼性を担保するための「3キュー設計」の深掘りです。リクエスト、レスポンス、そしてキャンセルという役割ごとにキュー(箱)を分けることで、重い計算処理の最中でもユーザーの操作を遮断せず、メッセージの滞留や順序の不整合を防ぐ「淀みのない体験」を構造的に実現しました。これは、実運用で直面する「切れる・黙る・古い・ずれる」という不確実性への、技術的な回答です。
2026.08.07 iseeit.jp

なぜWebアプリにメッセージキューが必要か — 直接処理とキューの違いを体感する

📝 Developer's Note:
ユーザー体験(UX)を損なわないリアルタイムな計算環境を実現するための、「計算と通信の分離」の重要性を説きました。高負荷なファイナンス計算や AI 推論において、直接処理によるブロッキングを回避し、メッセージキューを介した非同期な構造を採用する意義を実証しています。これは、本サイトが掲げる「不確実性の構造化」を技術面から支える、アーキテクチャ設計の核心的な判断基準です。
2026.08.06 gwaw.jp

ハイブリッドRAGを本番投入する — ブラウザ検索 × VPS生成

📝 Developer's Note:
WebGPU によるブラウザ内高速ベクトル検索と、VPS 上での LLM 生成プロセスを最適に組み合わせた「ハイブリッド RAG」を本番投入しました。7 月から継続してきた演算基盤の整備と実機検証の成果を統合し、15 年分の蓄積データを「再利用可能な知識」へと昇華させるシステムが完成。プライバシー保護と低遅延な応答を両立し、AI コンシェルジュが著者の「分身」として真に機能するための決定的なマイルストーンです。
2026.08.05 gwaw.jp

ブラウザでLLMは動くか — WebLLMを2つの実機で限界まで試す

📝 Developer's Note:
ブラウザ完結型 RAG の実現性を左右する「WebLLM」の挙動を、iPad mini A17 Pro 等の実機で限界まで検証しました。単なる動作確認に留まらず、推論速度やリソース消費の「実効性能」を特定することは、本サイトが目指す「エッジ側での自律的な体験」を構築するための不可欠なステップです。モバイル端末に著者の分身たる AI を宿らせるための、実測主義に基づく詳細な検証ログとなっています。
2026.08.04 iBe.TOKYO

勝どき→勝どき(10km walk 2026)

📝 Developer's Note:
真夏の豊洲・お台場・有明を周回する、身体性と都市体験の記録。酷暑という厳しい外部環境下でのルート選択や暑さ対策のプロセスを、TCXデータとして構造化しました。これは AI コンシェルジュが著者の物理的な行動圏と、環境に対する意思決定を理解し、将来的に「再利用可能な知見」として提示するための重要なライフログ・データセットとなります。
2026.08.04 gwaw.jp

WebGPUでベクトル検索を実装する — ブラウザ完結RAGの心臓部

📝 Developer's Note:
ブラウザ完結型RAGの実現において最大のボトルネックとなる「ベクトル類似度計算」を、WebGPUによって演算加速させる手法を確立しました。7月の技術検証で得た実効性能の知見を基に、iPad mini等のエッジ端末でも15年分の蓄積データを瞬時に検索可能なパイプラインを実装。これは、サイト内の全活動をAIが再利用可能な「生きた知識」へと変換し、プライバシーと低遅延を両立した対話体験を提供するための最重要コンポーネントです。
2026.08.03 APPW.jp

RAGパイプラインのハマりどころ:文字化けと重複登録

📝 Developer's Note:
RAG(検索拡張生成)の精度を左右するのは、洗練されたアルゴリズム以上に、入力されるデータの「清潔さ」です。15年分の蓄積データをAIの脳に流し込む過程で発生した、エンコーディングの不整合や重複登録といった「データの濁り」をどう排したか。AIを単なる一般論を話すボットで終わらせず、著者の正確な分身として振る舞わせるための、構造化プロセスの核心を記録しました。
2026.08.02 APPW.jp

consumer.py — RAGエンジン解説

📝 Developer's Note:
本サイトが標榜する「AI-Assisted Activity Hub」の心臓部、RAG(検索拡張生成)エンジンの実装解説です。4サイトの膨大な活動ログを、いかにしてAIが対話可能な「再利用可能な知識」へと構造化し、的確に抽出・要約するかというバックエンド処理(consumer.py)の設計思想を公開しました。これは、AIを単なる一般論を話すボットではなく、著者の「実装・判断・失敗」を継承した「分身」へと昇華させるための、知識基盤構築の核心的な記録です。
2026.08.01 APPW.jp

WordPress REST APIが403になった原因はmu-pluginsだった

📝 Developer's Note:
システム連携の要となる REST API で発生した 403 Forbidden エラーの特定と解決の記録。通常のプラグイン管理画面には現れない mu-plugins(必須プラグイン) に潜んでいた制約を突き止めるプロセスを構造化しました。これは、AI コンシェルジュが安全かつ確実にデータを取得するための「インフラの透明性と信頼性」を担保する上で不可欠な、実測主義に基づくデバッグ作業の成果です。
2026.07.27 iseeit.jp

オプション戦略ラボ — 損益図で学ぶ

📝 Developer's Note:
複雑なオプション戦略の合成損益を、数式ではなく「動的な幾何学構造」として解体・提示する実戦的ラボを実装しました。gwaw.jp で実証したエッジ側での高速演算技術を活用し、パラメータ変化に伴うリスクの変遷をリアルタイムに損益図へ反映。単なる計算ツールの提供に留まらず、AI が「著者が複雑な金融リスクをいかに構造化し、どのトレードオフを重視しているか」を学習するための、高度な技術・思想データセットとして設計しています。
2026.07.26 gwaw.jp

ティックは何点まで描けるか — Canvas/SVG/WebGL/WebGPU 描画方式の限界

📝 Developer's Note:
WebGPUベンチマーク三部作で得た「実効性能」の知見を、具体的な描画パイプラインの選定基準へと昇華させました。Canvas、SVG、WebGL、そしてWebGPUを対象に、iPad mini A17 Pro等のモバイル実機で大量のティック(価格データ)を描画する際の限界値を実測。どのテクノロジーがどのデータ量でボトルネックを迎えるのかを特定することで、高頻度な金融データの可視化におけるUX最大化への最短距離を定義しました。
2026.07.25 iseeit.jp

市場シミュレーター — バブルはなぜ起きるか

📝 Developer's Note:
gwaw.jp で磨き上げた WebGPU 協調計算と Compute-to-Render 技術を、市場心理のダイナミズムを解明する実用ツールへと統合しました。個々のエージェントの微視的な「群れ」が、いかにしてバブルや暴落という巨視的な価格動態を形成するかを、モバイル端末上でリアルタイムに演算・可視化します。これは、体験を単なるツールで終わらせず、AI が著者の設計思想やリスクへの洞察を学習するための「再利用可能な知識」へと構造化する、本サイトの核心的な試みです。
2026.07.24 APPW.jp

TCXルートマップ生成 解説

📝 Developer's Note:
iBe.TOKYO で蓄積された身体的な「歩き」の記録(TCXデータ)を、サーバーサイドでいかに解析し、視覚的なルートマップとして再構成するかという技術的プロセスを公開しました。これは、生の活動データをシステムや AI が扱える「再利用可能な知識」へと変換する、本サイトの「クロスオーバー要約」の基盤となる実装です。物理レイヤーでの体験をデジタル資産へと昇華させ、エッジ環境での閲覧を最適化するための設計思想を記録しています。