2026-03-03 Goose Ollama Troubleshooting

Goose → Ollama 接続完全ガイド

Open WebUI経由ではなく、OllamaにGooseを直接接続する際のトラブルシューティング記録です。

1. 環境構成

ホストIP役割備考
CLIENT192.168.1.xGoose実行マシンApple Silicon Mac
SERVER192.168.1.yOllama / Open WebUI大容量RAM Mac
PROXY192.168.1.zliteLLM proxy / n8nApple Silicon Mac
サービスポート用途
Open WebUI18789Web UI + OpenAI互換API
Ollama11434LLM推論エンジン（直接接続）

2. 根本原因

⚠ 主要原因 (PRIMARY CAUSE)
Goose v1.26.1 がデフォルトで OpenAI Responses API を使用する

Goose 1.26以降、OpenAIの新しい /v1/responses エンドポイントをデフォルトで使用します。Open WebUI はこのエンドポイントを実装していないため、405 Method Not Allowed が返り続けます。

⚠ 二次的要因 (SECONDARY CAUSE)
Ollamaがデフォルトでlocalhostのみにバインド

Ollamaはデフォルトで 127.0.0.1:11434 しか待ち受けないため、他マシンから直接アクセスできません。OLLAMA_HOST=0.0.0.0:11434 の設定が必要です。

3. 解決ステップ詳細

1
Open WebUI APIキーの取得

Open WebUIのアカウント画面にAPIキーセクションが表示されない場合、Admin設定で有効化が必要。

# Admin Panel → Settings → General → Enable API Keys をON
# APIキー発行UIが動作しない場合、サインインAPIで直接JWTを取得
curl -X POST http://192.168.1.y:18789/api/v1/auths/signin \
  -H "Content-Type: application/json" \
  -d '{"email":"user@example.com","password":"yourpassword"}'
2
Gooseの設定 — OPENAI_BASE_PATH の修正

Gooseは OPENAI_HOST + OPENAI_BASE_PATH + /chat/completions でURLを組み立てます。

# ❌ 誤り — URLが二重になる
OPENAI_BASE_PATH: api/chat/completions

# ✅ 正しい
OPENAI_BASE_PATH: /api/v1
3
Goose v1.26.1 の Responses API 問題を迂回

プロバイダーをOpenAIからOllamaに切り替えます。

# config.yaml を直接編集
# ✅ 追加する設定
GOOSE_PROVIDER: ollama
GOOSE_MODEL: qwen2.5:7b-instruct
OLLAMA_HOST: http://192.168.1.y:11434
4
NRT Ollama のネットワーク公開

外部マシンからアクセスするには 0.0.0.0 へのバインドが必要。

# SERVER側で実行（再起動後も有効）
launchctl setenv OLLAMA_HOST 0.0.0.0:11434
brew services restart ollama

4. 最終設定

# ~/.config/goose/config.yaml
GOOSE_PROVIDER: ollama
GOOSE_MODEL: qwen2.5:7b-instruct
OLLAMA_HOST: http://192.168.1.y:11434
OLLAMA_TIMEOUT: '600'
GOOSE_TELEMETRY_ENABLED: false

Goose to Ollama Connection Guide

This troubleshooting guide is only available in Japanese. Please switch the language to 日本語 (Japanese) using the toggle in the top-right corner to view the guide.

2026-05-29 Local LLM macOS llama.cpp

Mac Studio M2 Max (32GB)でローカルLLM 3基をオンデマンド切り替え並行運用する極上環境の構築

高性能なオープンソースモデルが毎月のように登場しています。しかし、限られた物理メモリ環境で複数の高性能モデル（Q8_0などの高品質量子化）を同時に動かそうとすると、メモリプレッシャーの増大やVRAM溢れによる速度低下、最悪の場合はクラッシュに直面します。

本稿では、メモリが32GBであるMac Studio（M2 Max）において、Gemma 4 E4B (7.5B)、Qwen 2.5 (14B)、Phi-4 (14B) という3つの超強力なモデル（すべて最高精度のQ8_0量子化）を別々のブラウザに割り当てつつ、VRAMの衝突を避けてオンデマンドで自動切り替えするAPIゲートウェイアーキテクチャの構築ログを紹介します。

1. 課題：38.6 GB のメモリ要求と32GBの物理制限

今回ローカル環境にロードしたモデルと、それぞれのメモリ（VRAM）占有量は以下の通りです：

  • Gemma 4 E4B Q8_0: 約 8.2 GB
  • Qwen 2.5 14B Q8_0: 約 15.2 GB
  • Phi-4 14B Q8_0: 約 15.2 GB

合計すると 約 38.6 GB となり、Mac Studioの物理メモリ（32GB）、およびMetal GPUへのメモリ割当上限（約 21.8 GB）を大きくオーバーします。何も工夫せずに3つ同時にプロセスを立ち上げると、GPUアロケーションがエラーとなるか、SSDへのスワップアウトにより処理速度が1トークン/秒以下に激落ちします。

そこで、「**複数のブラウザを同時に使って対話することはない**」という自分自身の利用スタイルに注目し、リクエストのあったモデルだけをGPUに読み込み、不要なモデルを即座に解放する動的ライフサイクル管理を構築しました。

2. アーキテクチャ：APIゲートウェイによる自動ライフサイクル制御

仕組みはシンプルですが、極めて強力です。ポート 11430 で待機する軽量なPythonプロキシゲートウェイを自作し、OS起動時のバックグラウンドサービス（LaunchAgent）として登録しました。

このゲートウェイが、各ブラウザのPage Assist拡張機能から送られてくるリクエストに含まれる "model" フィールドを解析し、macOSのサービス管理コマンドである launchctl を用いて裏側でロード・アンロードを自動実行します。

自動スイッチングの流れ：
Brave（Gemma 4を要求）からリクエストが到着 ➡️ ゲートウェイがQwenやPhi-4のサービスを launchctl unload で即座に終了（VRAMを全開放） ➡️ Gemma 4 の plist を launchctl load` して起動。

3. ローカル起動を滑らかにする「/health」ポーリング

llama-server はポートをリスンしてからモデルのテンソル（重み）をロードし終わるまでに少し時間がかかります。ポートが接続可能になったからといってすぐにプロキシを始めると、ブラウザ側に 503 Loading model エラーが返されてしまいます。

これを防ぐため、ゲートウェイ内でターゲットプロセスの /health エンドポイントを 200ms ごとにポーリングし、レスポンスが {"status":"ok"} (HTTP 200) になるまでクライアントからのリクエストを待機（保留）させる処理を実装しました。

これにより、モデルの切り替え（SSDからVRAMへの15GBの読込）にかかる **約10秒間** を安全に待機させ、ロードが完了した瞬間にシームレスにチャットが開始される体験を実現しました。

4. 黙読と同期する「readline()」ストリーミング最適化

構築の過程で、Page Assistへの文字出力が数秒おきに表示される「カクカク現象」に直面しました。調査の結果、Pythonプロキシがバックエンドからのレスポンスを response.read(8192) で大きなバッファサイズごとに読み込んでいたことが原因と判明しました。

ストリーミングAPI（SSE）は1行（1トークン）ごとにデータを送信するため、コードを response.readline() による「1行ごとの即時読み出し＆即時フラッシュ（wfile.flush）」に書き換えました。結果、AIが文字を出力したその瞬間に遅延なくブラウザに反映され、**自分が黙読するのとちょうど同じスピード（毎秒22〜47文字）でスラスラと出力される滑らかな環境**へと進化しました。

5. 成果とまとめ

このオーダーメイド環境により、以下の完璧なマルチブラウザ使い分けが実現しました：

  • Brave (ポート 11430 / model.gguf): Gemma 4 Q8_0 が爆速で機能（~47 tokens/s）
  • Chrome (ポート 11430 / Qwen2.5): Qwen 2.5 14B Q8_0 が高度な日本語で対話（~25 tokens/s）
  • Safari (ポート 11430 / phi-4): スタンドアロンHTMLから Phi-4 14B Q8_0 を論理思考用に使用（~22 tokens/s）

Building a Premium On-Demand Multi-LLM Environment on Mac Studio M2 Max (32GB) with Native llama.cpp

This post details the architecture and implementation of a custom API gateway on a Mac Studio M2 Max (32GB RAM) designed to concurrently serve three powerful models—**Gemma 4 E4B (7.5B)**, **Qwen 2.5 (14B)**, and **Phi-4 (14B)** in full Q8_0 precision—automatically swapping them in and out of VRAM on-demand based on browser-specific routing.

1. The Challenge: 38.6 GB Memory Request vs. 32GB Physical Limit

Here are the VRAM/RAM footprints of the models loaded in our environment:

  • Gemma 4 E4B Q8_0: ~8.2 GB
  • Qwen 2.5 14B Q8_0: ~15.2 GB
  • Phi-4 14B Q8_0: ~15.2 GB

The total allocation is ~38.6 GB, which exceeds the physical 32GB RAM of the system and the ~21.8 GB Metal VRAM allocation budget. Running all three servers concurrently triggers GPU out-of-memory errors or aggressive SSD swapping, reducing speed to less than 1 token/second.

Since we only type in one browser at any given moment, we realized we don't need these models loaded simultaneously. The optimal solution was to dynamically load the requested model into VRAM and immediately unload inactive ones when switching contexts.

2. The Architecture: Automatic Lifecycle Control via API Gateway

We built a lightweight Python API Gateway proxy running on port 11430, registered as a macOS LaunchAgent to run continuously in the background.

When a browser's Page Assist extension sends a chat completion request, the gateway inspects the "model" parameter in the HTTP payload. It then invokes macOS's native service controller (launchctl) to swap the model daemons in the background:

The Switching Logic:
A request from Brave (targeting Gemma 4) arrives ➡️ The gateway calls launchctl unload on Qwen and Phi-4 services (freeing up to 30 GB VRAM instantly) ➡️ Calls launchctl load on the Gemma 4 service.

3. Smooth Warm-up with "/health" Polling

At startup, llama-server immediately opens its network port, but is not ready to serve requests until it completes loading the weights into memory. Forwarding the API call prematurely results in a 503 Loading model error.

To solve this, the gateway polls the target server's /health endpoint every 200ms. It intercepts and holds the client's request until the endpoint returns {"status":"ok"} (HTTP 200).

This allows the ~10-second model loading phase (moving 15 GB from the fast internal SSD to VRAM) to resolve safely and transparently, resuming the chat stream seamlessly once the model is fully initialized.

4. "readline()" Streaming Optimization for Real-Time Flow

During initial testing, the text output in the browser popped in in large, stuttering chunks every few seconds. We traced this to the gateway's proxy loop, which read the upstream socket response in large blocks via response.read(8192).

Since Server-Sent Events (SSE) stream text line-by-line, we rewrote the reading loop to use response.readline(), flushing immediately with self.wfile.flush(). This bypassed any internal buffering and routed every generated token directly to the browser in real-time. The text now flows smoothly and fluidly at 22-47 tokens/sec, matching the user's natural silent reading speed.

5. Results and Summary

This tailored, Docker-free local AI environment runs cleanly with maximum Apple Silicon hardware acceleration:

  • Brave (Port 11430 / model.gguf): Dedicated to Gemma 4 Q8_0 for ultra-fast general queries (~47 tokens/s).
  • Chrome (Port 11430 / Qwen 2.5): Dedicated to Qwen 2.5 14B Q8_0 for nuanced Japanese tasks (~25 tokens/s).
  • Safari (Port 11430 / phi-4): Accessing Phi-4 14B Q8_0 via a standalone web page for programming and logic tasks (~22 tokens/s).
2026-05-08 Manifesto Causa Determinism

プロジェクト・マニフェスト: Anchor LLM & Anchor DB (Causa) v1.0

1. コア・フィロソフィー (核心となる思想)

本プロジェクトの根本的な目標は、LLMの持つ「非決定的（確定的でない）」な性質を、OS操作における**「決定論的（100%再現可能）」**な実行エンジンへと変換することにあります。

私たちは、ユーザーの**「Enterキー」**の打鍵を、因果関係の究極 of アンカーポイント（錨）と定義します。従来のベクトルデータベースが「セマンティックな類似性」に焦点を当てるのに対し、**Anchor DB（Causa）**は、人間が承認した過去のアクションを凍結し、自律的なOS運用における信頼性、速度、安全性を担保する**「判例エンジン」**として機能します。

2. システムアーキテクチャ

A. Anchor LLM (パイロット)

  • 役割: OS操作の計画 and 実行判断に特化した専門知能（OS-WorldやOS-Copilotの構造を継承）。
  • プロトコル: 推論を開始する前に、必ず現在の画面状態（アクセシビリティツリー/スクリーンショット）をスキャンし、Anchor DBに同一の判例が存在しないかをクエリします。AIの提案は、常に人間が承認した歴史的事実（データベース）の下位に位置します。

B. Anchor DB (土台 / "Causa")

  • 物理構成: 300TB NAS (データレイク) + SQLite (メタデータインデックス)
  • 因果の連鎖（スキーマ設計）:
    1. UI Snapshot: AX Treeの構造データ + 画像ハッシュ（観測された状態の証拠）
    2. User Intent: 指揮官（人間）によって定義された具体的な目標
    3. LLM Proposal: AIが生成したアクションシーケンス
    4. The Anchor (承認): 人間が「Enter」を押して承認したという事実（決定的な因果の結合）
    5. Outcome Evidence: 実行後の画面状態と、成功/失敗の検証結果

C. Anchor Engine (実行部隊)

  • ワークフロー: Difyを介して統合され、Apple Silicon Mac上で実行されます。
  • リスクガバナンス: 5段階のリスク分類を導入。**リスク3以上**（削除、資金移動、データのエクスポート）に分類される操作は、たとえ過去に全く同じ判例があっても、必ず「ヒューマン・アンカー（人間の手動再承認）」を要求します。

3. 実装ドグマ (実装上の戒律)

  1. 決定論ファースト（Deterministic First）
    「同一のUI指紋」「同一のビジネスオブジェクトID」「同一アクションのハッシュ値」「過去の承認」「過去の実行成功」がすべて満たされた場合に限り、LLMの推論をバイパスしてミリ秒単位で過去の操作をリプレイ（自動実行）します。
    ※ただし、マイルストーン1段階では、自動実行は行わず「リプレイ候補（replay_candidate）」の判定を生成するのみに留めます。
  2. 判例インジェクション（Precedent Injection）
    推論を始める際、AIにゼロから思考させるのではなく、プロンプトに「過去の自分の実行履歴」をコンテキストとして注入（想起）させます。
  3. 厳格な分離（Strict Decoupling）
    「提案レイヤー（LLM）」と「承認ポリシーレイヤー（DB/人間）」を物理的に分離します。LLM自身が自分の危険なアクションを自分で承認することは決して許されません。

Project Manifesto: Anchor LLM & Anchor DB (Causa) v1.0

1. Core Philosophy

The fundamental goal of this project is to transform the **"Non-deterministic"** nature of LLMs into a **"Deterministic"** execution engine for OS operations.

We define the user's **"Enter"** key stroke as the ultimate anchor point of causality. While traditional Vector DBs focus on "semantic similarity," the **Anchor DB** serves as a **"Precedent Engine,"** freezing human-approved actions to ensure reliability, speed, and safety in autonomous OS operations.

2. System Architecture

A. Anchor LLM (The Pilot)

  • Role: A specialized intelligence (inheriting structures from OS-World/OS-Copilot) that plans and judges OS operations.
  • Protocol: Always scan the screen state (AX Tree/Screenshot) and query the Anchor DB for existing precedents before reasoning. The LLM proposal must remain subservient to human-approved historical truth.

B. Anchor DB (The Foundation / "Causa")

  • Physical realization: 300TB NAS (Data Lake) + SQLite (Metadata Index).
  • The Chain of Causality Schema:
    1. UI Snapshot: AX Tree JSON + Image Hash (Observed State Evidence).
    2. User Intent: The specific objective defined by the Sovereign Commander.
    3. LLM Proposal: The action sequence generated by the AI.
    4. The Anchor (Approval): The fact that a human pressed "Enter" (The definitive causality link).
    5. Outcome Evidence: Post-execution state and verification of success/failure.

C. Anchor Engine (The Executor)

  • Workflow: Orchestrated via Dify (Neuro-link) and executed on M4/M2 Mac.
  • Risk Governance: Implement a 5-tier risk classification. Operations categorized as **Risk 3 or higher** (Deletion, Financial Transaction, Data Export) strictly require a **"Human Anchor" (Re-approval)** even if a precedent exists.

3. Implementation Dogmas

  1. Deterministic First: Bypass LLM inference and execute within milliseconds *only* when UI fingerprint, business object identity, action payload hash, prior human approval, and prior success evidence are all verified. In Milestone 1, this only produces a `replay_candidate` decision without autonomous execution.
  2. Precedent Injection: Inject "Past Self" contexts into the prompt before the LLM begins reasoning. Do not let the LLM "think" from scratch; let it "remember."
  3. Strict Decoupling: Separate the Proposal Layer (LLM) from the Policy/Approval Layer (DB/Human). An LLM must never self-approve its own risky actions.
2026-05-08 Design Milestone SQL Schema

マイルストーン 1: Causa Core 設計と仕様

本マニュアルは、因果関係データベース「Causa（Anchor DB）」における、最初の安全な実装境界（マイルストーン1）を定義します。本層はロジックおよびデータ定義のみを扱い、直接的なOS実行や破壊的な操作は一切行わない安全な設計となっています。

1. SQLite スキーマ設計 (Schema Design)

因果の連鎖を正確にトラッキングするため、以下の7つのテーブル構造をSQLite上に定義します：

CREATE TABLE AnchorCase (
    id TEXT PRIMARY KEY,
    user_intent TEXT NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE UISnapshot (
    id TEXT PRIMARY KEY,
    anchor_case_id TEXT NOT NULL,
    ax_tree_json TEXT NOT NULL,
    image_hash TEXT NOT NULL,
    FOREIGN KEY(anchor_case_id) REFERENCES AnchorCase(id)
);

CREATE TABLE LLMProposal (
    id TEXT PRIMARY KEY,
    anchor_case_id TEXT NOT NULL,
    action_sequence TEXT NOT NULL,
    risk_level INTEGER NOT NULL,
    FOREIGN KEY(anchor_case_id) REFERENCES AnchorCase(id)
);

CREATE TABLE HumanApproval (
    id TEXT PRIMARY KEY,
    llm_proposal_id TEXT NOT NULL,
    approved_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY(llm_proposal_id) REFERENCES LLMProposal(id)
);

CREATE TABLE OutcomeEvidence (
    id TEXT PRIMARY KEY,
    execution_event_id TEXT NOT NULL,
    success BOOLEAN NOT NULL,
    post_execution_state TEXT,
    FOREIGN KEY(execution_event_id) REFERENCES ExecutionEvent(id)
);

2. 決定論的リプレイ判定ルール (Replay Eligibility Rules)

過去の判例データ（Precedent）が、再び自動実行可能（replay_candidate）と判定されるには、以下の条件を**すべて**満たす必要があります：

  • 現在のUIスナップショットが、過去のUI指紋と完全に一致すること。
  • ビジネスオブジェクトの同一性が検証されていること。
  • アクションのペイロードハッシュが完全に一致すること。
  • 過去に人間の承認（HumanApproval）が存在すること。
  • 過去の実行結果（OutcomeEvidence）が存在し、それが「成功」を示していること。
  • リプレイポリシー（ReplayPolicy）が有効であり、期限切れでないこと。
  • 現在の操作のリスクレベルが「リスク3（手動再承認しきい値）」未満であること。

もし一つでも条件から外れる場合は、以下のように安全に判定が分岐します：

  • リスクレベルが3以上 ➡️ requires_human_anchor (手動承認要求)
  • 過去の実行が失敗 ➡️ do_not_replay (リプレイ禁止)
  • UIの完全一致ではなく部分一致 ➡️ requires_llm_reasoning (LLMによる推論要求)
  • ポリシーが期限切れ ➡️ requires_human_anchor (再承認要求)

3. マイルストーン1 完了条件と安全境界

本マイルストーンは、データモデルの構築、上記の決定論的リプレイ判定ロジック、監査サマリー生成、およびインメモリDBを用いたテストがすべてクリアされたことで「完了」と定義されます。実際のOS特権昇格やアプリ操作などの外部副作用は一切行いません。

Milestone 1: Causa Core Specification

This document defines the first safe implementation boundary for the Anchor DB ("Causa") project, focusing strictly on data structures and decision logic without side effects.

1. SQLite Schema Design

To track the chain of causality, we define the core relational structure in SQLite:

CREATE TABLE AnchorCase (
    id TEXT PRIMARY KEY,
    user_intent TEXT NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE UISnapshot (
    id TEXT PRIMARY KEY,
    anchor_case_id TEXT NOT NULL,
    ax_tree_json TEXT NOT NULL,
    image_hash TEXT NOT NULL,
    FOREIGN KEY(anchor_case_id) REFERENCES AnchorCase(id)
);

2. Replay Eligibility Rules

A historical case may return `replay_candidate` only if:

  • current UI snapshot exactly matches the historical UI fingerprint
  • business object identity is verified
  • action payload hash matches
  • prior HumanApproval exists
  • prior OutcomeEvidence exists and indicates success
  • ReplayPolicy is valid and not expired
  • current risk level is below Risk 3

Otherwise, it falls back to: `requires_human_anchor` (Risk 3+ or expired policy), `do_not_replay` (prior failure), or `requires_llm_reasoning` (partial UI match).

2026-05-08 Release v1.0-alpha Core Log

リリースノート: Causa Core v1.0-alpha

Causa Core（Anchor DBエンジン）の最初のマイルストーンとなる、v1.0-alphaのリリーフ概要です。本バージョンは機能・データ定義およびシミュレーションのためのロジックモジュールであり、外部OS等への破壊的影響を持たないよう保護されています。

1. バージョン v1.0-alpha に含まれるもの (Features)

  • データモデル定義: AnchorCase, UISnapshot, LLMProposal, HumanApproval, ExecutionEvent, OutcomeEvidence, ReplayPolicy, ReplayDecision などのPythonデータクラス（Dataclasses）の実装。
  • 決定論的リプレイ判定機能: 厳格な一致ルールとリスクしきい値に基づいて、自動実行の適格性を判定する純粋関数 determine_replay_decision の実装。
  • 監査ログ生成（Audit Summary）: 判定結果と理由コードを、人間が監査しやすい親切な自然文で説明・出力する build_audit_summary レイヤー。
  • 抽象ストレージレイヤー: データベースの実装に依存しないよう設計された、共通インターフェース CausaRepository の定義。
  • テストインフラ: ローカルテスト用のインメモリDB（InMemoryCausaRepository）と、判定パイプライン全体をシミュレーションするための包括的な単体テスト群。

2. 本バージョンに明示的に含まれないもの (Non-Goals)

安全境界の確保のため、以下の項目は本リリースから厳格に除外されています：

  • 実際のOSコマンドの実行、およびマウス・キーボード操作などの自動制御。
  • アクセシビリティAPI（Accessibility API）への直接のクエリやフック。
  • Dify、n8n等の外部ツールとの連携。
  • `sudo` コマンド等による管理者特権の昇格。
  • ネットワーク通信（ソケット、HTTPリクエスト等）。
  • 本番環境のデータベース（Supabase、PostgreSQL、ローカル以外のSQLite）への直接の接続。

3. 今後のロードマップ (Next Steps)

今回のアルファリリースでデータモデルとコア判定ロジックがフリーズ（確定）したため、次回のマイルストーンでは、コアロジックの独立性を維持したまま、ローカルでのデータ永続化を行うための SQLiteローカルアダプター の開発に着手する予定です。

Release Notes: Causa Core v1.0-alpha

1. What v1.0-alpha includes

  • Data Models: Python dataclasses for `AnchorCase`, `UISnapshot`, `LLMProposal`, `HumanApproval`, `OutcomeEvidence`, `ReplayDecision`, and `AuditSummary`.
  • Decision Logic: A pure deterministic function (`determine_replay_decision`) that assesses replay eligibility.
  • Audit Summary: An informational layer (`build_audit_summary`) providing human-readable explanations of replay decisions.
  • Storage Abstraction: The `CausaRepository` abstract base class establishing a storage-agnostic interface.
  • Test Infrastructure: `InMemoryCausaRepository` alongside comprehensive simulation tests.

2. What it explicitly does not include

For safety, the following are strictly excluded: OS execution, autonomous replay, accessibility API calls, network calls, sudo escalation, and production database usage.

2026-05-30 PWA iPad mini Cloudflare Tunnel Zero Trust Access

iPad mini PWA コンソール + Cloudflare Tunnel + Zero Trust 安全リモートアクセス環境の構築

ローカルで起動しているAIエージェントやHammerspoonなどのシステム管理コンソールを、iPad miniからセキュアかつシームレスに操作するための、リモートアクセス＆PWA環境の構築ログです。

ルーターのポート開放を一切行わず、Cloudflare TunnelとZero Trust Accessを組み合わせることで、社外・外出先からでも安全にローカル環境へアクセスし、スクリーンショットやメッセージを相互に送受信できる仕組みを構築しました。

1. ネットワーク＆セキュリティ設計 (Tunnel & Zero Trust)

家庭内のローカルネットワーク内に閉じているコンソール（http://localhost:3000）を、安全に外部公開するためにCloudflareのネットワークを利用しました。

  • Cloudflare Tunnel (kix-console): cloudflared をローカルMac上で動作させ、ルーターのポートを開放することなく、安全に https://antigravity.z0a.net へのリクエストをローカルの 3000 ポートへとトンネリングします。
  • Zero Trust Access Policy: 不特定多数からのアクセスを防ぐため、Cloudflare Zero TrustによるワンタイムPIN（OTP）認証ルールを設定。以下の信頼されたメールアドレスのみにアクセスを制限しました：
    • cx3.zoom@gmail.com
    • info@olbin.dev

2. iPad miniに最適化されたPWAコンソール (UI/UX)

外出先やソファの上でiPad mini（縦持ち 744px 画面）から片手で操作できるよう、コンソールのUI/UXをブラッシュアップしました。

iPad mini의体験向上：
縦持ち時のスペースを最大限に活かす2カラム・サイドバーレイアウトを採用。入力文字数に応じて自動で縦幅が調整される自動リサイズ型テキスト入力エリアや、コンソール上のレイアウト崩れを防ぐレスポンシブなCSSグリッドを採用しました。

3. システムの常時稼働化 (launchd Daemon)

Macの再起動時やシャットダウン後でも、コンソールとトンネルが自動でバックグラウンド起動するように、macOSの起動デーモン（launchd）のplistを設定し、自動永続化を行いました。

<!-- /Users/p/Library/LaunchAgents/ai.openclaw.gateway.plist -->
<key>Label</key><string>ai.openclaw.gateway</string>
<key>ProgramArguments</key>
<array>
  <string>/Users/p/start_jules_task.sh</string>
</array>
<key>RunAtLoad</key><true/>

4. 「➕」機能：マルチパート画像＆スクリーンショットアップロード

コンソール上で文字入力が欄外に飛び出すバグや、スクリーンショット添付機能の不良を解消するため、バックエンドとフロントエンドの両面で以下の改修を行いました：

✓ 改善された機能
Multerマルチパートアップロード ＆ CSSコンテキスト自動調整

フロントエンドに ➕ ボタンを新設し、デバイスのカメラやフォトライブラリから画像ファイルを直接アップロードできるようになりました。multer を用いたマルチパートデータ処理により、Braveなどのブラウザキャッシュをクリアした後も、安定してスクリーンショットの送信と表示ができるようになっています。

Building a Secure iPad Remote Console using Cloudflare Tunnel and Zero Trust Access

This entry documents the setup of a secure, mobile-friendly PWA remote console for system and agent management, optimized specifically for the iPad mini.

By leveraging Cloudflare Tunnel and Cloudflare Zero Trust, the local console running at http://localhost:3000 is safely exposed via https://antigravity.z0a.net without requiring port forwarding.

1. Network & Security Architecture

  • Cloudflare Tunnel (kix-console): Connects the local port 3000 to the public DNS record at antigravity.z0a.net over outbound connections.
  • Zero Trust Access Control: Restricts authentication using One-Time PIN (OTP) delivery to authorized email addresses:
    • cx3.zoom@gmail.com
    • info@olbin.dev

2. iPad mini-Optimized PWA Frontend

The user interface has been tailored to fit the vertical profile of the iPad mini screen (744px wide):

  • Responsive 2-column sidebar layout that automatically adjusts on portrait screens.
  • Auto-resizing textareas that prevent text from clipping or overflowing their container boundaries.
  • Standalone PWA manifest configuration for a full-screen, native application feel.

3. Persistent macOS Daemon Setup

The console server and tunnel client are configured to persist across macOS reboots using native launchd agents:

<!-- launchd plist mapping -->
<key>Label</key><string>ai.openclaw.gateway</string>
<key>ProgramArguments</key>
<array>
  <string>/Users/p/start_jules_task.sh</string>
</array>
<key>RunAtLoad</key><true/>

4. Screenshot Upload & Form Handling

We resolved input layout clipping and added image upload capabilities (via the ➕ button) to allow sharing mobile screenshots directly with the host machine. The backend now processes multipart/form-data payloads cleanly using multer.

SS-FIA テクニカルデータ

SS-FIA（Super Sports Federation Internationale de l'Automobile）の技術要件と開発ドキュメントです。

テクニカル仕様

  • エンジン出力制限: 規定に基づく制限値の遵守
  • シャシー安全基準: FIAホモロゲーション取得要件
  • 電子制御システム: 共通ECU of setup and mapping

詳細は、各セクションのドキュメントを参照してください。

SS-FIA Technical Data

Technical requirements and development documentation for SS-FIA (Super Sports Federation Internationale de l'Automobile).

Technical Specifications

  • Engine Power Limits: Compliance with limits defined by regulations.
  • Chassis Safety Standards: FIA homologation requirements.
  • Electronic Control Systems: Common ECU setup and mapping.

Please refer to the specific section documents for details.

2026-05-30 Macro Engine MVP Streamlit FRED API

マクロ → 産業翻訳エンジン (Macro Engine) MVP & ロードマップ

マクロ経済指標の変動を分析し、各産業セクターへの影響度を決定論的にスコアリング・ランク付けする「マクロ → 産業翻訳エンジン (Macro Engine)」の開発仕様と将来のロードマップです。

1. 概要とディレクトリ構成

本ツールは、セントルイス連邦準備銀行（FRED）などのAPIからリアルタイムにマクロ経済データを取得し、あらかじめ定義された影響度マトリックスに基づいて、17の主要産業セクターのスコアを自動算出します。

/Users/p/FIA/translation_engine/
├── README.md                 # プロジェクトの概要とセットアップ
├── requirements.txt          # 依存パッケージ
├── main.py                   # 統合CLIデモ実行スクリプト
├── app.py                    # StreamlitベースのWebダッシュボード
└── src/
    ├── schema.py             # 17セクター、影響度マトリックス定義
    ├── detector.py           # 変動・重篤度検知 (EventDetector)
    ├── engine.py             # 加重合計スコアリング (RuleEngine)
    └── ingestion.py          # FRED APIデータ取得

2. コア計算ロジック

主要な指標の期間変化率（金利はパーセントポイント、原油や為替はパーセント変化）を検知し、重篤度（Severity: 1〜3）を乗じた加重合計でセクター毎のスコアを算出します：

数式モデル (Mathematical Formula)

スコア算出: Score = Σ (Base Impact Weight × Severity)

スコア正規化: Normalized Score = Score / Max(|Scores|)

イベント検知基準 (EventDetector)

  • 10年債利回り変化 (30日間): +0.25% (Severity 1), +0.5% (Severity 2), +1.0% (Severity 3) で long_rate_spike を検知。
  • CPI前年比 (YoY): > 2% (Severity 1), > 3% (Severity 2), > 5% (Severity 3) で inflation_high を検知。
  • WTI原油価格 (30日間): ±10% (Severity 1), ±20% (Severity 2), ±40% (Severity 3) で oil_price_spike / oil_price_crash を検知。
  • 為替ドル円 (30日間): ±2% (Severity 1), ±5% (Severity 2), ±10% (Severity 3) で yen_weakening / yen_strengthening を検知。

3. テストと動作検証

APIのモック経路、データフレーム処理などを検証するテスト（pytest）がすべてパスしています：

tests/test_ingestion.py ....                                             [ 44%]
tests/test_translation.py .....                                          [100%]
============================== 9 passed in 0.27s ===============================

4. 将来の開発ロードマップ (Phases 1-5)

1
コアロジックとWebモックアップの構築 (完了)

ルールエンジンとFREDデータ取得、Streamlit（macro.z0a.net）によるWebダッシュボードを開発。

2
個別株評価とスクリーニング (ミクロ結合)

yfinanceやJ-QuantsからPER/PBR/ROE/自己資本比率等の個別銘柄データを取得し、マクロスコアと結合したBUY/WATCH/AVOID判定スクリーナーを開発。

3
103イベントデータベースと日本国内データの拡張

総務省統計局などから国内マクロデータ（国内CPI、日銀政策金利、日銀短観）の取得に対応し、イールドカーブ逆転などの103個のマクロイベントを完全網羅。

4
プレミアムデスクトップGUI (PySide6)

PySide6 (Qt for Python) による洗練されたダークモード対応デスクトップクライアントアプリを開発。

5
ローカルキャッシュとスタンドアロン配布

SQLiteキャッシュによるオフライン動作対応と、PyInstallerを使用したmacOS/Windows用スタンドアロンアプリのビルドパッケージング。

Macro → Industry Translation Engine (Macro Engine) MVP & Roadmap

Technical specifications and future development roadmap for the Macro Engine, a tool designed to parse macroeconomic trends and score their impact on individual industry sectors.

1. Overview & Directory Layout

The engine fetches macroeconomic indicators in real-time from APIs (such as FRED) and automatically computes contribution scores for 17 core industry sectors based on dynamic impact rules.

/Users/p/FIA/translation_engine/
├── README.md                 # Project overview and setup
├── requirements.txt          # Dependency packages
├── main.py                   # CLI demo script
├── app.py                    # Streamlit interactive web dashboard
└── src/
    ├── schema.py             # 17 sectors, impact matrix
    ├── detector.py           # EventDetector (anomaly and severity logic)
    ├── engine.py             # RuleEngine (scoring calculations)
    └── ingestion.py          # Ingestion client

2. Core Mathematical Logic

Detects the rate of change over a 30-day window (percentage points for interest rates, percentage change for commodities/forex) and weights the base impacts by event severity (levels 1-3):

Mathematical Model

Score Formulation: Score = Σ (Base Impact Weight × Severity)

Normalization: Normalized Score = Score / Max(|Scores|)

Event Detection Thresholds (EventDetector)

  • 10-Year Yield change (30 days): +0.25% (Severity 1), +0.5% (Severity 2), +1.0% (Severity 3) triggers long_rate_spike.
  • YoY CPI Inflation: > 2% (Severity 1), > 3% (Severity 2), > 5% (Severity 3) triggers inflation_high.
  • WTI Crude Oil price (30 days): ±10% (Severity 1), ±20% (Severity 2), ±40% (Severity 3) triggers oil_price_spike / oil_price_crash.
  • USD/JPY exchange rate (30 days): ±2% (Severity 1), ±5% (Severity 2), ±10% (Severity 3) triggers yen_weakening / yen_strengthening.

3. Automated Verification

All ingestion, data processing, and rule math tests pass successfully via pytest:

tests/test_ingestion.py ....                                             [ 44%]
tests/test_translation.py .....                                          [100%]
============================== 9 passed in 0.27s ===============================

4. Future Roadmap (Phases 1-5)

1
Core Engine & Web Mockup (Completed)

Designed the Rule Engine, integrated Fred data fetcher, and deployed the interactive Streamlit dashboard (macro.z0a.net).

2
Stock Valuation & Screening (Micro Integration)

Fetch fundamental metrics (PER, PBR, Dividend Yield, ROE) from yfinance or J-Quants APIs to create a BUY/WATCH/AVOID screener scoring mechanism.

3
103-Event Library & Domestic Data Expansion

Add support for Japanese domestic indicators (CPI, BOJ Policy Rates, BOJ Tankan) and complete mapping for all 103 macroeconomic events.

4
Premium Desktop Client GUI (PySide6)

Develop a high-fidelity desktop client using PySide6 (Qt for Python) featuring custom widgets and dynamic dark styling.

5
SQLite Cache & Standalone Package Release

Implement local database caching for offline operation and package application bundle files for macOS (DMG/APP) and Windows (EXE).

2026-05-31 Daily Log Sovereign OS

日誌・進捗日報 : 2026-05-31

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

Sovereign Log (Docs Site)

  • 385d48f docs: add Macro Engine MVP walkthrough and development roadmap

Daily Log & Progress: 2026-05-31

📝 Today's Notes & TODOs (Obsidian)

  • No Obsidian notes found for today.

💻 Development Activity (Git Commits)

Sovereign Log (Docs Site)

  • 385d48f docs: add Macro Engine MVP walkthrough and development roadmap
2026-06-01 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-01

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-01

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-02 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-02

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-02

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-03 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-03

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-03

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-04 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-04

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-04

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-05 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-05

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-05

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-06 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-06

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-06

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-07 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-07

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-07

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-08 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-08

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-08

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-09 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-09

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-09

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-10 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-10

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-10

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-11 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-11

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-11

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-12 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-12

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-12

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-13 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-13

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-13

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-14 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-14

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-14

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-15 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-15

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-15

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-16 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-16

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-16

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-17 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-17

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-17

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-18 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-18

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-18

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-19 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-19

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-19

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-20 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-20

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-20

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-21 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-21

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-21

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-22 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-22

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-22

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-23 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-23

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-23

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-24 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-24

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-24

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。
2026-06-25 Daily Log Sovereign OS

日誌・進捗日報 : 2026-06-25

📝 本日のメモ・TODO (Obsidian)

  • 本日のObsidianメモはありません。

💻 本日の開発コミット (Git Commits)

  • 本日のGitコミットはありません。

Daily Log & Progress: 2026-06-25

📝 Today's Notes & TODOs (Obsidian)

  • 本日のObsidianメモはありません。

💻 Development Activity (Git Commits)

  • 本日のGitコミットはありません。