AI Tools on KnightLiブログ

ai-goofish-monitor：AI で閒魚の商品を自動監視するオープンソースシステム

Sun, 17 May 2026 17:24:03 +0800

ai-goofish-monitor は、Usagi-org が公開している閒魚向けの商品監視システムです。

目的は明確です。閒魚での検索、絞り込み、商品分析、結果記録、通知を自動化し、大量の中古商品から条件に合うものをより早く見つけることです。プロジェクトは Playwright でページ操作を自動化し、画像入力に対応する AI モデルを接続して商品情報をさらに判断します。

プロジェクト：https://github.com/Usagi-org/ai-goofish-monitor

先に結論

ai-goofish-monitor は、単純なキーワード通知スクリプトというより、「閒魚の購入インテリジェンスダッシュボード」に近いです。

主な特徴は次の通りです。

タスク、アカウント、AI 判定基準、ログ、結果を管理できる Web 管理画面。
複数タスクの並行実行。各タスクでキーワード、価格、絞り込み条件、AI Prompt を設定できる。
Playwright で閒魚ページを取得し、ログイン状態やページ操作が必要な場面に対応しやすい。
キーワード一致だけでなく、AI で商品が条件に合うか判断する。
ntfy.sh、企業微信、Bark、Telegram、Webhook などの通知に対応する。
Cron 定期実行、複数アカウント管理、プロキシローテーション、失敗時リトライ、Docker デプロイに対応する。

特定の商品をよく閒魚で探す人、たとえば中古デジタル機器、カメラ機材、GPU、HDD、ゲーム機、楽器、家電、コレクション品を探す人に向いています。ただし「自動で掘り出し物を買うツール」ではありません。閒魚の検索結果は変化し、ログイン状態は失効することがあり、プラットフォームのリスク制御も自動化の安定性に影響します。人間の判断を置き換えるものではなく、補助的なフィルタリングツールとして使うべきです。

解決する問題

閒魚で中古商品を探すと、よく次の問題があります。

商品数が多すぎて手で見るのが疲れる。
タイトルや説明が不統一で、キーワードの取りこぼしや誤判定が起きやすい。
良い価格の出品は短時間で消える。
同じ商品でも地域、価格、状態、出品者が違う。
安い商品にはアクセサリ、故障品、再生品、誘導的なタイトルが混ざる。
複数キーワードを継続的に監視するのは手作業では続きにくい。

普通のキーワード通知で解決できるのは一部だけです。たとえば「ThinkPad X1」を検索すると、アクセサリ、壊れた画面、空箱、分解部品が混ざることがあります。「ソニー A7C」では、レンズセット、レンタル情報、釣りタイトル、異常価格に出会うこともあります。

ai-goofish-monitor の考え方は、まず自動化で候補商品を集め、それを AI に渡して条件に合うか再判断し、最後に注目すべき結果を通知する、というものです。

主な機能

README に列挙されている機能はかなりそろっています。

Web 可視化管理：タスク管理、アカウント管理、AI 基準編集、実行ログ、結果閲覧。
AI 駆動：自然言語でタスクを作成し、マルチモーダルモデルで商品を分析。
複数タスク並行：タスクごとにキーワード、価格、絞り込み条件、AI Prompt を個別設定。
高度な絞り込み：送料無料、新規出品時間範囲、省 / 市 / 区の地域フィルタ。
即時通知：ntfy.sh、企業微信、Bark、Telegram、Webhook など。
定期実行：Cron による周期タスク。
アカウントとプロキシのローテーション：複数アカウント、タスクへのアカウント紐付け、プロキシプール、失敗時リトライ。
Docker デプロイ：コンテナ化された運用。

これらを組み合わせることで、「監視タスク作成」から「命中通知」までの流れをカバーします。

ワークフロー

典型的な流れは次のようなものです。

サービスをデプロイして Web UI を開く。
閒魚アカウントのログイン状態をインポートする。
監視タスクを作成する。
キーワード、価格範囲、地域、新規出品範囲などを設定する。
判定基準を書く、または AI に生成させる。
タスクをリアルタイムまたは定期実行する。
Playwright がページを開き、商品情報を取得する。
AI がタイトル、説明、画像、Prompt をもとに条件適合を判断する。
命中結果を SQLite に保存する。
設定済みの通知チャネルで結果を送る。
Web UI で結果、ログ、価格履歴を見る。

この流れで AI の価値が最も大きいのは 8 番目です。「状態が良い、価格が妥当、アクセサリだけではない、修理品ではない、できれば同城で手渡し」などの自然言語条件を理解できるため、単純なキーワード規則より柔軟です。

Docker デプロイ

プロジェクトは Docker デプロイを推奨しています。

git clone https://github.com/Usagi-org/ai-goofish-monitor && cd ai-goofish-monitor
cp .env.example .env
vim .env
docker compose up -d
docker compose logs -f app
docker compose down

デフォルトの Web UI アドレス：

`1`	`http://127.0.0.1:8000`

公式イメージ：

`1`	`ghcr.io/usagi-org/ai-goofish:latest`

イメージ取得が遅い場合、README にはミラー例もあります。

1
2
3

docker pull ghcr.nju.edu.cn/usagi-org/ai-goofish:latest
docker tag ghcr.nju.edu.cn/usagi-org/ai-goofish:latest ghcr.io/usagi-org/ai-goofish:latest
docker compose up -d

Docker イメージには Chromium が含まれているため、ホスト側に別途ブラウザを入れる必要はありません。デフォルトの永続化ディレクトリは次の通りです。

data/：SQLite の主ストレージ。タスク、結果、価格履歴を保存。
state/：ログイン状態の cookie ファイル。
prompts/：タスク用プロンプト。
logs/：実行ログ。
images/：商品画像とタスク一時画像ディレクトリ。

.env の SERVER_PORT を変更した場合は、docker-compose.yaml のポートマッピングも合わせて変更します。

最小構成

最小構成は主に AI モデルと Web UI ログインに関するものです。

OPENAI_API_KEY=your_api_key
OPENAI_BASE_URL=your_openai_compatible_base_url
OPENAI_MODEL_NAME=your_multimodal_model
WEB_USERNAME=admin
WEB_PASSWORD=change_me

最初の 3 つは AI モデル接続に必須です。

OPENAI_API_KEY：モデル API Key。
OPENAI_BASE_URL：OpenAI 互換 API エンドポイント。
OPENAI_MODEL_NAME：画像入力に対応するモデル名。

WEB_USERNAME と WEB_PASSWORD は Web UI ログイン用です。README ではデフォルト認証情報が admin/admin123 とされていますが、本番環境では必ず変更してください。

初回利用

初回利用の流れはおおよそ次の通りです。

http://127.0.0.1:8000 を開く。
Web UI にログインする。
「閒魚アカウント管理」に入る。
プロジェクト付属の Chrome 拡張で閒魚ログイン状態 JSON をエクスポートする。
ログイン状態をシステムに貼り付ける。
ログイン状態ファイルは state/ に保存される。例：state/acc_1.json。
「タスク管理」に戻り、タスクを作成してアカウントを紐付ける。
タスクを実行し、結果を見る。

ここで最も重要なのはログイン状態です。閒魚は第三者が自由に取得できる標準 API を公開しているわけではないため、プロジェクトはブラウザのログイン状態を使って通常のページアクセスを模擬します。ログイン状態の失効、リスク制御、captcha、アカウント異常はいずれもタスク実行に影響します。

AI タスクとキーワードタスク

プロジェクトは 2 種類のタスク作成方式をサポートします。

1 つ目は AI判断 です。

「詳細な要件」を入力すると、システムが非同期に分析基準を生成します。複雑な条件に向いています。

本体のみ、アクセサリは不要。
市場価格より明らかに安い場合だけ通知。
状態が良く、説明に水没、修理、隠れた不具合がない。
同城優先、手渡しできるとなお良い。
画像にシリアル番号、箱、重要付属品が写っている。

2 つ目は 关键词判断 です。

これは従来のルール型監視に近く、キーワード、価格、地域などの条件で直接タスクを作成します。AI 生成を使いません。ルールが単純で、多少の誤検知を許容できる場面に向いています。

実際には併用できます。キーワードで初期フィルタし、AI で誤検知を減らす形です。

Web UI でできること

Web UI は、このプロジェクトが普通のスクリプトと違う重要な部分です。

タスク管理ページでは次を設定できます。

AI 作成タスク。
キーワード規則。
価格範囲。
新規出品範囲。
地域フィルタ。
アカウント紐付け。
定期実行ルール。

アカウント管理ページでは次ができます。

閒魚アカウントログイン状態のインポート。
ログイン状態の更新。
アカウント削除。
タスクへのアカウント指定。
システムによる自動アカウント選択。

結果とログページでは次ができます。

命中商品の確認。
結果のエクスポート。
履歴検索。
タスク実行過程の確認。
ログイン失効、リスク制御、AI 呼び出し問題の調査。

システム設定ページでは次ができます。

システム状態の確認。
Prompt の編集。
プロキシとローテーション設定の調整。

長期監視では Web UI が重要です。タスクが増えると、設定、ログ、結果、通知はすぐ管理しにくくなります。

データ保存

現在のオンライン主ストレージは SQLite で、デフォルトパスは次です。

`1`	`data/app.sqlite3`

Docker はデフォルトで SQLite の主 DB を次のようにマウントします。

`1`	`./data:/app/data`

アプリ起動時に DB とテーブルを自動作成し、古い config.json、jsonl/、price_history/ から一度だけ履歴データをインポートしようとします。

注意点として、state/、prompts/、logs/、images/ は引き続きファイルシステム上のディレクトリであり、SQLite 内には入りません。商品画像は次のようなディレクトリに一時保存されます。

`1`	`images/task_images_<task_name>/`

タスク終了後、デフォルトではクリーンアップされます。

この構成は個人または小規模チームに向いています。SQLite は軽量で移行しやすく、ファイルディレクトリにログイン状態、画像、ログが残るため調査もしやすいです。

通知チャネル

プロジェクトは複数の通知チャネルに対応します。よく使う設定は次の通りです。

NTFY_TOPIC_URL
GOTIFY_URL / GOTIFY_TOKEN
BARK_URL
WX_BOT_URL
TELEGRAM_BOT_TOKEN / TELEGRAM_CHAT_ID / TELEGRAM_API_BASE_URL
WEBHOOK_*

通知はこの種のツールの体験の中心です。監視システムが結果をバックエンドに書くだけなら、ユーザーは結局ページを何度も開く必要があります。プッシュ通知があれば、命中商品をすぐ受け取れます。

実用的には商品価値で通知を分けるとよいです。

普通のキーワード命中はバックエンドにだけ記録。
AI 高信頼度の結果はスマホへ通知。
高価値商品は企業微信または Telegram へ通知。
デバッグ中はログを増やし、安定後にノイズを減らす。

開発者向け実行

Docker を使わないローカル開発には次が必要です。

Python 3.10+
Node.js + npm
Playwright CLI
Chromium または Chrome / Edge ブラウザ

基本コマンド：

1
2
3

git clone https://github.com/Usagi-org/ai-goofish-monitor
cd ai-goofish-monitor
cp .env.example .env

ワンコマンド起動：

1
2

chmod +x start.sh
./start.sh

start.sh は Playwright CLI とブラウザ条件を確認し、依存関係のインストール、フロントエンドビルド、成果物コピー、バックエンド起動を行います。

バックエンドを手動起動：

`1`	`python -m src.app`

または：

`1`	`uvicorn src.app:app --host 0.0.0.0 --port 8000 --reload`

フロントエンド開発：

1
2
3

cd web-ui
npm install
npm run dev

テストとビルド：

1
2

PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 pytest
cd web-ui && npm run build

向いている人

ai-goofish-monitor は次のようなユーザーに向いています。

閒魚で特定モデルをよく探す人。
中古デジタル機器、カメラ機材、ゲーム機、ハードウェア部品を監視したい人。
「キーワード検索 + 手動選別」を自動化したい人。
OpenAI 互換モデル API を持ち、AI 判定コストを受け入れられる人。
Docker または基本的なコマンドラインデプロイに慣れている人。
命中結果をスマホ、企業微信、Telegram に通知したい人。

あまり向いていないケース：

デプロイを全く知らず、すぐ使える App だけが欲しい。
ログイン状態、captcha、アカウントリスク制御を扱いたくない。
公式認可された強いコンプライアンスのデータ API が必要。
大規模かつ高頻度にプラットフォームデータを収集したい。
AI に取引リスクを自動判断させ、注文まで代行してほしい。

リスクと境界

この種のツールでは境界を意識する必要があります。

第一に、プラットフォーム規則を守ることです。

閒魚には独自の利用規約、リスク制御、アカウント安全機構があります。自動化アクセスは制限を引き起こす可能性があります。高頻度に取得したり、リスク制御を回避したり、出品者への迷惑行為、プライバシーの一括収集、プラットフォーム秩序の破壊に使ってはいけません。

第二に、アカウントのログイン状態を保護することです。

state/ に保存されるのはログイン状態 cookie ファイルです。これは実質的にアカウントアクセス資格情報です。Git リポジトリにコミットせず、信頼できないサーバーにも置かないでください。サーバーをインターネットに公開する場合、Web UI のデフォルトパスワードは必ず変更し、VPN、リバースプロキシ認証、または内部ネットワークの背後に置くべきです。

第三に、AI 判定は事実保証ではありません。

AI は誤検知を減らせますが、商品の真偽、出品者の信頼性、価格の妥当性、取引安全性を保証しません。最終的には商品詳細、出品者評価、チャット履歴、配送方法、支払いプロセスを人間が確認する必要があります。

第四に、コストに注意してください。

すべての候補商品をマルチモーダルモデルで分析すると、呼び出しコストはすぐ増えます。まずキーワード、価格、地域で強く絞り込み、少数の候補だけを AI に渡すのがよいです。

第五に、プライバシーに注意してください。

商品スクリーンショット、チャット関連内容、アカウント状態、通知内容には機密情報が含まれる可能性があります。通知 Webhook、ログディレクトリ、データベースは適切に保護してください。

普通のスクリプトとの違い

普通の閒魚監視スクリプトは、通常 3 つのことだけをします。

キーワードを検索する。
価格を判定する。
通知を送る。

ai-goofish-monitor はさらに進んでいます。

Web UI でタスクとアカウントを管理する。
AI Prompt で複雑な購入基準を表現する。
マルチモーダルモデルで商品画像と説明を見る。
SQLite に結果と価格履歴を保存する。
ログページでタスク失敗原因を調査する。
プロキシローテーションと複数アカウントで安定性を高める。
定期タスクで長期運用を支える。

機能が多いぶん、デプロイと運用コストも高くなります。一般ユーザーには Docker デプロイが最も簡単です。開発者にとっては、Web UI、FastAPI、Playwright、SQLite の構成が二次開発しやすい形です。

使い方の例

実用的には、小さなタスクから始めるのがよいです。

たとえば中古カメラを探すなら、次のようなタスクを作れます。

キーワード：A7C、索尼 A7C
価格範囲：市場価格に基づいて上限を設定
地域：同じ省または同じ市を優先
新規出品範囲：直近 1 日または数時間
AI 基準：レンズ単体を除外、修理品を除外、明らかなアクセサリを除外、シャッター数と状態に注目
通知：AI 判定を通過した結果だけ通知

安定して動くようになってから、タスク数を少しずつ増やします。最初から数十キーワード、複数アカウント、高頻度 Cron にしないでください。ログイン状態の安定性、誤検知率、AI コスト、通知ノイズを見てから調整するのが安全です。

まとめ

ai-goofish-monitor は、閒魚監視を「キーワードスクリプト」から「管理可能な AI 監視システム」へ進めるプロジェクトです。Playwright でページ操作を自動化し、AI で複雑な判断を行い、Web UI でタスクと結果を管理し、SQLite にデータを保存し、複数通知チャネルで結果を届けます。

特定商品を監視したい個人や小規模チームに向いています。特に中古デジタル機器、ハードウェア、カメラ機材のように、価格変動が大きく、出品タイミングが重要で、説明ノイズが多いカテゴリに適しています。

ただし慎重に使う必要があります。ログイン状態を保護し、デフォルトパスワードを変更し、取得頻度を抑え、AI 結果を人間が確認し、プラットフォーム規則とプライバシー境界を守ることが重要です。補助的なフィルタリングツールとしては価値がありますが、完全自動取引システムとして見ると能力を過大評価しやすいです。

参考リンク：

OpenKB：ドキュメントを継続更新される LLM ナレッジベースへコンパイルする

Sun, 17 May 2026 17:15:08 +0800

OpenKB は、VectifyAI が公開しているオープンソースの LLM ナレッジベースツールです。

これは、ドキュメントをチャンク化し、ベクトル化し、問い合わせ時にコンテキストを組み直すだけの従来型 RAG システムではありません。OpenKB はまず生のドキュメントを構造化された wiki にコンパイルします。そこには文書要約、概念ページ、相互参照、後続の問い合わせ、lint チェックが含まれます。言い換えると、資料を継続的に整理していくナレッジベース CLI に近い存在です。

プロジェクト：https://github.com/VectifyAI/OpenKB

先に結論

OpenKB で注目したい点は 3 つあります。

ナレッジベースを専用データベースに閉じ込めず、通常の Markdown ファイルとして出力する。
PageIndex で長い PDF を処理し、ベクトル DB なしの長文ドキュメント検索を重視している。
「知識のコンパイル」を重視し、毎回ゼロから検索するのではなく、LLM が要約、概念ページ、相互リンクを生成する。

そのため OpenKB は、論文読解、プロジェクト文書、社内資料、技術仕様、製品調査、個人ナレッジベースのように、資料を長期的に蓄積する場面に向いています。

一方で万能の代替ではありません。高並行のオンライン Q&A、複雑な権限管理、Web 管理画面、企業向け監査、大規模なマルチテナント機能が必要なら、現時点の OpenKB は完全な企業ナレッジプラットフォームというより、開発者向けツール兼ナレッジベースのプロトタイプに近いです。

OpenKB とは

OpenKB は Open Knowledge Base の略です。

CLI として動作し、知識庫に入れた原始ドキュメントを変換、整理、要約し、一連の wiki ファイルを生成します。公式 README の説明は明快です。OpenKB は LLM を使って原始ドキュメントを構造化された相互リンク付き wiki スタイルのナレッジベースへコンパイルし、PageIndex によってベクトルレスな長文ドキュメント検索を支援します。

対応する入力形式は次の通りです。

PDF
Word
Markdown
PowerPoint
HTML
Excel
プレーンテキスト
markitdown で変換できるその他の形式

生成されたナレッジベースは wiki/ に置かれ、主に次の内容を含みます。

index.md：ナレッジベースの概要
log.md：操作タイムライン
AGENTS.md：ナレッジベース構造とメンテナンス方針
sources/：変換後の原文
summaries/：各ドキュメントの要約
concepts/：ドキュメント横断の概念ページ
explorations/：保存された問い合わせ結果
reports/：lint レポート

この設計の最大の利点は透明性です。ブラックボックスの検索インターフェイスから答えを受け取るだけでなく、Markdown ファイルを直接開いて知識庫を確認できます。

従来型 RAG との違い

従来型 RAG の典型的な流れは次のようなものです。

ドキュメントをチャンクに分割する。
embedding を生成する。
ベクトルデータベースに保存する。
問い合わせ時に関連チャンクを取得する。
それらを LLM に渡して回答を生成する。

この流れは成熟しており、Q&A システムにも向いています。ただし、知識そのものは本当の意味では蓄積されません。質問のたびに、関連片を探し、コンテキストを組み立て、回答を生成し直すことになります。

OpenKB の考え方は「先に整理し、それから問う」に近いです。

ドキュメントを raw/ に入れる。
短いドキュメントは markitdown で Markdown に変換する。
長い PDF は PageIndex でツリーインデックスと要約を生成する。
LLM が文書要約を生成する。
LLM が既存の概念ページを読み、ドキュメント横断の概念を作成または更新する。
ナレッジベースの索引、ログ、相互リンクを更新する。

その結果、新しいドキュメントを 1 つ追加することは、単に検索可能なファイルを 1 つ増やすことではありません。十数個の wiki ページが更新されることもあります。知識は概念ページに書き込まれ、既存資料と接続されます。

これは人間がナレッジベースを維持する方法に近いです。新しい資料が入ったら、保管するだけではなく、トピックページを更新し、差分を要約し、参照を追加します。

PageIndex が解決する問題

長文ドキュメントは、RAG と LLM ナレッジベースにとって常に難所です。

長い PDF を単純に多数の chunk に分けると、次の問題が起きやすくなります。

章や節の関係が失われる。
表、画像、脚注を扱いにくい。
検索される断片が細かすぎて、回答に全体構造が欠ける。
コンテキストウィンドウが大きくても、文書全体を詰め込むのは適切ではない。
要約の連鎖が長いと、細部が圧縮されて失われやすい。

OpenKB は長い PDF の処理に PageIndex を使います。プロジェクト説明によると、PageIndex は長文ドキュメントに対してツリーインデックスと要約を作成し、LLM が全文を直接読むのではなく、文書ツリー上で推論できるようにします。

この路線の要点は「ベクトル類似度が最も高い数段落」を探すことではありません。モデルが文書の階層構造を利用して関連内容を見つけられるようにすることです。研究レポート、論文、マニュアル、目論見書、コンプライアンス文書のような長い資料では、この考え方はかなり有効です。

OpenKB はデフォルトでオープンソース版 PageIndex をローカル実行できます。OCR、複雑な PDF 処理、より高速な構造生成が必要な場合は、PAGEINDEX_API_KEY を設定して PageIndex Cloud を使うこともできます。

インストールとクイックスタート

OpenKB は pip で直接インストールできます。

`1`	`pip install openkb`

GitHub の最新バージョンを入れることもできます。

`1`	`pip install git+https://github.com/VectifyAI/OpenKB.git`

ソースから開発用にインストールする場合：

1
2
3

git clone https://github.com/VectifyAI/OpenKB.git
cd OpenKB
pip install -e .

ナレッジベース用ディレクトリを作成します。

1
2

mkdir my-kb && cd my-kb
openkb init

ドキュメントを追加します。

1
2

openkb add paper.pdf
openkb add ~/papers/

質問します。

`1`	`openkb query "What are the main findings?"`

対話モードに入ります。

`1`	`openkb chat`

新しいファイルを自動処理したい場合は watch モードを使います。

`1`	`openkb watch`

その後 raw/ にファイルを置くと、OpenKB が自動的に wiki を更新します。

LLM 設定

OpenKB は LiteLLM を通じて、OpenAI、Claude、Gemini など複数のモデルプロバイダーに対応します。

モデルは初期化時に設定できますし、.openkb/config.yaml に書くこともできます。

1
2
3

model: gpt-5.4
language: en
pageindex_threshold: 20

モデル名は LiteLLM の provider/model 形式に従います。OpenAI モデルでは provider 接頭辞を省略できます。

`1`	`model: gpt-5.4`

Anthropic や Gemini のモデルは通常、次のように書きます。

`1`	`model: anthropic/claude-sonnet-4-6`

`1`	`model: gemini/gemini-3.1-pro-preview`

API key は .env に入れます。

`1`	`LLM_API_KEY=your_llm_api_key`

PageIndex Cloud を有効にする場合は、さらに追加します。

`1`	`PAGEINDEX_API_KEY=your_pageindex_api_key`

よく使うコマンド

OpenKB のコマンドは開発者にとって扱いやすいです。

openkb init：新しいナレッジベースを初期化する。
openkb add <file_or_dir>：ファイルまたはディレクトリを追加する。
openkb remove <doc>：ドキュメントを削除し、関連する wiki ページ、画像、レジストリ、PageIndex 状態を整理する。
openkb query "question"：ナレッジベースに対して単発の質問を行う。
openkb chat：複数ターンの対話に入る。
openkb watch：raw/ を監視し、自動更新する。
openkb lint：構造と知識の健全性を確認する。
openkb list：索引済みドキュメントと概念を一覧する。
openkb status：ナレッジベースの統計を表示する。

openkb chat は、連続した探索には openkb query より向いています。セッションの再開、一覧、削除に対応し、チャット内では /status、/list、/add <path>、/save、/lint のような slash commands も使えます。

Markdown wiki が重要な理由

多くのナレッジベースツールで厄介なのは移行コストです。

資料が専用データベース、専用インデックス、専用フォーマットに入ると、直接確認、編集、バックアップ、移行するのが難しくなります。OpenKB は結果を通常の Markdown として書き出すため、既存ツールと自然に組み合わせられます。

最も直接的な使い方は、Obsidian で wiki/ を開くことです。

要約ページをそのまま読める。
概念ページを [[wikilinks]] で相互接続できる。
グラフビューで知識間の関係を確認できる。
問い合わせ結果を explorations/ に保存できる。
AGENTS.md でナレッジベースの維持方法を定義できる。

これにより OpenKB は単なる Q&A ツールではなく、個人やチームの知識整理パイプラインにもなります。

向いている場面

OpenKB は特に次の場面に向いています。

論文や技術レポートの読解。
プロジェクト文書の整理。
製品調査資料庫。
オープンソースプロジェクト周辺の文書ナレッジベース。
社内規程、会議メモ、説明資料の整理。
個人 Obsidian ナレッジベースの自動メンテナンス。
長い PDF、PPT、Word、Web 資料の構造化。

大量のドキュメントに向き合うとき、単に「一問一答」したいだけでなく、資料を徐々に閲覧可能、再利用可能、追跡可能な知識庫にしたいなら、OpenKB の方向性は合っています。

使うときの注意点

第一に、OpenKB は LLM の品質に依存します。

要約、概念ページ、相互リンクはモデルによって生成されます。モデルが強いほど知識コンパイルの品質は安定します。モデル能力が不足していると、概念抽出、矛盾検出、ドキュメント横断の統合は弱くなります。

第二に、コストは先に見積もるべきです。

大量の長文ドキュメントを一度に投入すると、LLM 呼び出しコストは低くありません。まず小規模な資料セットで試し、出力構造と品質を確認してから範囲を広げるのがよいです。

第三に、生成された wiki には人間の確認が必要です。

OpenKB は資料を整理できますが、事実の完全な正確性を自動保証するものではありません。重要な知識庫では、要約、概念ページ、引用関係を人間が確認する必要があります。

第四に、機密資料には慎重に扱う必要があります。

クラウド LLM や PageIndex Cloud を使う場合、文書内のプライバシー、営業秘密、コンプライアンス要件に注意してください。社内資料では、モデルプロバイダー、データ保持方針、アクセス境界を先に確認するのが安全です。

第五に、現時点では CLI ツール寄りです。

ロードマップでは Web UI、データベースストレージ、大規模コレクション対応、階層型概念インデックスが挙げられています。ただし現在の段階では、チームメンバーがコマンドラインに慣れていない場合、導入のハードルはまだあります。

Obsidian、NotebookLM、企業 RAG との関係

OpenKB と Obsidian の関係は、「自動整理レイヤー」と「閲覧・編集レイヤー」と考えると分かりやすいです。

Obsidian は人間が書き、直し、閲覧し、リンクを作るのに向いています。OpenKB は原始ドキュメントを Obsidian に入れられる wiki へまとめるのに向いています。

OpenKB と NotebookLM の違いは、「ローカルで制御しやすいこと」と「開かれたファイル形式」にあります。

NotebookLM は資料を入れてすぐ質問や要約を行う体験に優れています。OpenKB は、整理結果をローカルディレクトリに残し、Markdown として継続的に管理したい開発者に向いています。

OpenKB と企業 RAG の関係は、置き換えではなく補完です。

企業 RAG は権限、監査、サービス化、アクセス分離、監視、安定したスループットを重視します。OpenKB は、読みやすく編集しやすく長期的に蓄積できる知識レイヤーを作るのに向いています。将来的にオンライン Q&A を作る場合でも、OpenKB が生成した wiki は高品質なコーパスとして使えます。

まとめ

OpenKB の価値は、LLM ナレッジベースを「問い合わせ時に一時的にコンテキストを組む」段階から一歩前に進めることです。まず資料を wiki として整理し、その wiki 上で質問、チャット、検査、継続的なメンテナンスを行います。

この方向性はすべての Q&A システムに合うわけではありませんが、長期的な蓄積が必要な知識作業には向いています。Markdown ファイル、Obsidian 互換、PageIndex による長文処理、複数モデル対応、CLI ワークフローを組み合わせると、開発者や調査型ユーザーにとって実用的なナレッジベースツールになります。

大量の PDF、レポート、Web ページ、論文、プロジェクト文書を持っているなら、OpenKB は試す価値があります。成熟した企業ナレッジベースをすぐ置き換えるものではないかもしれませんが、資料整理の入口としては実用的です。まずドキュメントを読める、リンクできる、追跡できる知識に変え、その上で LLM を働かせることができます。

参考リンク：

Claude を Fusion 360 に接続する：AI で STEP モデルを修正する実例

Thu, 14 May 2026 20:58:04 +0800

Claude を Fusion 360 に接続すると、単に「考え方を説明する」だけでなく、CAD モデルの修正に直接参加できる。典型的な流れは、既存の STEP ファイルを開き、Claude に現在のモデルを読ませ、構造上の干渉を分析させ、寸法を計画させたうえで、Fusion プラグイン経由でモデリング変更を実行することだ。

ここでは、遊星ギア分度器の修正を例に、Claude + Fusion 360 の基本的な使い方を整理する。

まず Fusion 360 の API/MCP サービスを有効にする

Fusion 360 で最初に基本設定を行う。

右上の Preferences を開く。
General または「通用」設定に入る。
API オプションを見つける。
MCP server を有効にする。
ポート番号を控える。デフォルト例は 27182。

次に Claude に戻り、Connectors に入り、Fusion コネクタを見つけて、Fusion 360 のアドレスとポートを入力する。通常はデフォルトの 27182 でよい。

接続に成功すると、Claude は Fusion プラグインを通じて、現在開いているモデルとやり取りできる。

STEP ファイルを開き、修正目標を明確にする

今回修正するのは、遊星ギア分度器の中の一つのギアだ。元の設計では、このギアは一本のねじを中心軸としてブラケットに固定されている。

目標は、それをベアリング構造へ変更することだ。

中心穴をベアリングに合わせる；
周囲のねじ穴が拡大した中心穴と干渉しないようにする；
ブラケット上のタッピングねじ穴も、ベアリング回転に適した軸構造へ調整する；
最終モデルはスライサーに読み込め、3D プリントに使えるようにする。

重要なのは、Claude に「ちょっと直して」とだけ言わないことだ。用途、組み立て方法、材料、製造方法をはっきり伝える必要がある。

Claude はスクリーンショットで現在のモデルを理解できる

Fusion プラグインはコマンドを実行するだけで、Claude にモデルを見せられないのではないか、と心配する人もいる。実際のテストでは、Claude はスクリーンショットを通じて現在のモデル状態を認識できた。

このケースでは、Claude はギア構造を確認し、次のような作業を行えた。

ギアと中心穴を識別する；
関連寸法を測定または推定する；
ベアリング寸法を提案する；
ベアリング取り付けに影響する構造を判断する；
中心穴を拡大すると、周囲のねじ穴と幾何干渉が起きる可能性を見つける。

このステップは重要だ。Claude が文字の指示だけで盲目的に修正しているのではなく、現在のモデルビューと構造判断を組み合わせられることを示している。

材料と加工方法は事前に伝える

最終的に 3D プリントするモデルなら、材料と工法を明確に Claude に伝える必要がある。

たとえば PLA でプリントする場合、ベアリング穴を CNC 金属加工の公差そのままで設計してはいけない。直径 6mm のベアリングを圧入するなら、穴径を約 6.1mm にすることを検討できる。この寸法が適切かどうかは、プリンター精度、材料収縮、スライサー設定、実際のテストによって調整する必要がある。

材料を伝えないと、Claude は CNC 加工の考え方で寸法を出す可能性がある。その場合、3D プリントでは穴が小さすぎ、後の組み立てが難しくなる。

プロンプトには次のように書くとよい。

1
2
3

このモデルは FDM 3D プリント用で、材料は PLA です。
目標は直径 6mm のベアリングを取り付けることで、プリント公差と圧入を考慮してください。
CNC 金属加工の公差として扱わないでください。

Claude にギア構造を修正させる

目標が明確になったら、Claude に具体的な修正を実行させる。

中心穴を拡大する；
干渉する周囲のねじ穴を調整する；
ベアリング取り付け座を追加する；
エッジに面取りを加える；
ギア本体と重要な噛み合い構造は維持する。

このケースでは、Claude はまず計画を出し、その後 Fusion 360 を呼び出してモデリング操作を行った。たとえば、元のねじ穴と中心穴が衝突すると判断した後、穴位置を少し外側へ移動し、ベアリング取り付け空間を壊さないようにした。

修正後は、モデルを確認する。

中心のベアリング座が正しく形成されているか；
周囲の穴が機能を維持しているか；
ギア構造が誤って壊れていないか；
面取りが組み立てに影響しないか；
オーバーハング、薄肉、スライス上のリスクがないか。

ブラケットも一緒に修正する

ギアだけを変更しても足りない。元のブラケットにはタッピングねじ用の取り付け穴がある。ギア中心をベアリングに変更するなら、ブラケット側もベアリング軸構造へ合わせる必要がある。

Claude にブラケットにも同様の修正をさせられる。

全体の取り付け位置を維持する；
元のタッピングねじ穴を円柱状の軸に変更する；
軸の直径と高さを制御する；
ベアリング回転のための空間を確保する；
ブラケットの他構造との干渉を避ける。

こうしてプリントすると、ギアはベアリングにスムーズに圧入でき、ブラケットは新しい回転中心を提供できる。最終的には、ねじ固定の構造が、より滑らかなベアリング回転構造へ変わる。

エクスポート、スライス、プリント検証

CAD 修正が終わったら、実際の製造フローに進む必要がある。

Fusion 360 から修正後のモデルをエクスポートする。
スライサーに読み込む。
穴、薄肉、オーバーハング、サポートを確認する。
ギアとブラケットをプリントする。
実際にベアリングを圧入する。
回転が滑らかか確認する。

AI が修正した CAD 結果は、画面上のモデルがきれいかどうかだけで判断してはいけない。必ずプリントして検証する必要がある。特にベアリング、穴位置、スナップ、ギアのような機械構造では、0.1mm レベルの誤差が、組み立てられるか、滑らかに回るかを決める。

使用上の提案

Claude + Fusion 360 は次のようなタスクに向いている。

既存 STEP モデルへの局所的な改造；
穴位置、面取り、ブラケット、取り付け座の調整；
ねじ固定をベアリング、スナップ、ピン構造へ変更する；
3D プリントモデルの公差補正；
複数の改版案を素早く生成する。

ただし、何も確認せずに最終部品を直接出す用途には向かない。より安定した流れは次の通りだ。

人間が組み立て目標と材料工法を定義する。
Claude が構造を分析し、修正案を出す。
Claude が Fusion を呼び出してモデリングを実行する。
人間が重要寸法と干渉を確認する。
小さな試作品をプリントして検証する。
実物の結果に基づいて再度イテレーションする。

まとめ

Claude を Fusion 360 に接続する価値は、CAD の基礎知識を置き換えることではない。「既存モデルの局所修正」を速くすることにある。

目標、材料、寸法、公差、組み立て方法を明確に伝えれば、モデルを読み、干渉を見つけ、構造を修正し、面取りを追加し、プリント可能な状態へ進める手助けができる。3D プリント、オープンソース機械部品の改造、個人工房での小ロット試作において、この AI CAD ワークフローはすでに実用的だ。

Codex は中国系 LLM とどう接続する？CCX で OpenAI 互換 API を一元管理する

Wed, 13 May 2026 23:20:40 +0800

CCX は AI API プロキシ兼プロトコル変換ゲートウェイです。Claude Messages、OpenAI Chat Completions、OpenAI Images、Codex Responses、Gemini API を 1 つのサービス入口にまとめ、チャネル、キー、モデルマッピング、優先度、フェイルオーバー、トラフィック監視を設定する Web 管理画面も提供します。

Claude、OpenAI、Gemini、Codex を同時に使っている場合や、OpenAI API 互換の上流サービスを複数維持している場合、CCX の価値は入口と管理の一元化にあります。クライアントは 1 つのサービスアドレスへ接続し、後続の上流チャネルは CCX が選択します。

プロジェクト：https://github.com/BenedictKing/ccx

CCX が解決すること

複数の AI API を混在させると、次の問題が起きやすくなります。

プロバイダーごとにパス、認証方式、リクエスト形式が異なる。
同じ種類のモデルでも複数の上流があり、base URL や API key を手動で切り替える必要がある。
ある key やチャネルが失敗したとき、クライアント側では自動でバックアップへ切り替わらないことが多い。
チーム利用では、モデル許可リスト、プロキシ、カスタムヘッダー、呼び出しログの集中管理が難しい。
Claude、Gemini、OpenAI Chat、画像 API、Codex Responses を同時に扱うと設定が散らばる。

CCX はこれらの差異をプロキシ層へ集約します。フロントエンドツール、スクリプト、業務サービスは CCX だけにアクセスし、CCX が API 種別、モデル、チャネル状態、優先度、ヘルス状態に基づいて適切な上流へ転送します。

対応エンドポイント

CCX は統一されたバックエンド入口を提供します。デフォルトポートは 3000 です。主なパスは次の通りです：

GET  /                         -> Web 管理画面
GET  /health                   -> ヘルスチェック
/api/*                         -> 管理 API
POST /v1/messages              -> Claude Messages プロキシ
POST /v1/chat/completions      -> OpenAI Chat プロキシ
POST /v1/responses             -> Codex Responses プロキシ
POST /v1/images/generations    -> OpenAI Images 生成
POST /v1/images/edits          -> OpenAI Images 編集
POST /v1/images/variations     -> OpenAI Images バリエーション
GET  /v1/models                -> モデル一覧
POST /v1beta/models/*          -> Gemini プロキシ

つまり、1 種類のプロトコルだけをプロキシするのではなく、Messages、Chat、Responses、Gemini、Images というよく使われる AI API 種別を個別のチャネルとして管理します。プロトコルごとにヘルス状態やログ空間が分かれるため、トラブルシュートしやすくなります。

アーキテクチャの考え方

CCX は Go バックエンドと Vue 3 フロントエンドで構成されています。フロントエンドのビルド成果物はバックエンドバイナリに埋め込まれるため、単一ポートでデプロイできます。同じサービスが Web UI、管理 API、プロキシ API を提供します。

リクエストの流れは概ね次の通りです：

`1`	`Client -> Auth Middleware -> Route Handler -> Channel Scheduler -> Provider / Converter -> Upstream API -> Metrics / Channel Logs -> Client Response`

主要モジュールの役割：

handlers: 各プロトコルのリクエストと管理操作を受け付ける。
providers: 上流 API のリクエストとレスポンス処理をラップする。
converters: Responses などの場面でプロトコル変換を行う。
scheduler: 優先度、プロモーション期間、ヘルス状態、サーキットブレーカー状態、セッション親和性に基づいてチャネルを選ぶ。
metrics: リクエスト数、成功率、遅延、ログ、サーキットブレーカー状態を記録する。
config: ランタイム設定を管理し、ホットリロードとバックアップをサポートする。

この設計の要点は、すべての API を無理に 1 つの形式へ変換することではありません。プロトコル種別ごとに代理し、管理、スケジューリング、ログ、認証を統一することです。

CCX と CodexBridge の違い

CCX と CodexBridge はどちらも Codex と OpenAI 互換 API に関係しますが、解決する問題が違います。

CodexBridge は専用の Codex ブリッジに近いツールです。目的は Codex CLI/SDK を OpenAI 互換の /v1/chat/completions サービスとして公開し、OpenWebUI、Cherry Studio、スクリプト、その他の OpenAI 互換クライアントからローカル Codex を呼び出せるようにすることです。つまり、CodexBridge の焦点は「Codex を外へ出す」ことです。

CCX は統一 AI API ゲートウェイに近いツールです。Codex Responses だけでなく、Claude Messages、OpenAI Chat、OpenAI Images、Gemini API も扱い、Web 管理画面、チャネル優先度、フェイルオーバー、ログ監視、複数 key 管理を提供します。つまり、CCX の焦点は「複数のモデルとプロバイダーをまとめて管理する」ことです。

簡単な比較：

項目	CodexBridge	CCX
中心的な位置づけ	Codex ローカルブリッジ	マルチプロトコル AI API ゲートウェイ
主な目的	Codex を OpenAI 互換エンドポイントにする	Claude、OpenAI、Gemini、Codex などのチャネルを一元管理する
管理画面	API サービス自体が中心	Web 管理画面を提供
複数チャネル調度	主目的ではない	チャネル優先度、フェイルオーバー、ログ監視に対応
向いている場面	ローカルまたは単一サービスで Codex を呼ぶ	チーム、多数の key、複数プロバイダー、複数プロトコル

Codex を OpenWebUI や Cherry Studio に接続したいだけなら CodexBridge のほうが直接的です。Codex、Claude、Gemini、DeepSeek、Qwen、Kimi など複数の上流をまとめて管理したいなら CCX が向いています。

クイックデプロイ

最も簡単なのはバイナリをダウンロードする方法です。ダウンロード後、同じディレクトリに .env を作成します：

PROXY_ACCESS_KEY=your-proxy-access-key
PORT=3000
ENABLE_WEB_UI=true
APP_UI_LANGUAGE=zh-CN

起動後、次へアクセスします：

`1`	`http://localhost:3000`

Windows で WSL、Docker、PowerShell などから localhost に接続できない場合は、Windows ホストの LAN IPv4 アドレスを使います。例：

`1`	`http://192.168.1.23:3000`

CCX はデフォルトで :PORT により全ネットワークインターフェースを待ち受けるため、LAN に公開する場合はアクセス制御に注意してください。

Docker デプロイ

Docker は常駐サービスに向いています：

docker run -d \
  --name ccx \
  -p 3000:3000 \
  -e PROXY_ACCESS_KEY=your-proxy-access-key \
  -e APP_UI_LANGUAGE=zh-CN \
  -v $(pwd)/.config:/app/.config \
  crpi-i19l8zl0ugidq97v.cn-hangzhou.personal.cr.aliyuncs.com/bene/ccx:latest

リポジトリに docker-compose.yml がある場合は次でも起動できます：

`1`	`docker compose up -d`

自動更新が必要なら Watchtower 設定を重ねます：

`1`	`docker compose -f docker-compose.yml -f docker-compose.watchtower.yml up -d`

デプロイ後、.config ディレクトリにはランタイム設定と永続データが保存されます。コンテナ再作成時に設定を失わないよう、ホストへマウントするのがおすすめです。

ソースから実行

開発またはカスタムビルドではソースから実行できます：

git clone https://github.com/BenedictKing/ccx
cd ccx
cp backend-go/.env.example backend-go/.env
make run

よく使うコマンド：

make dev
make run
make build
make frontend-dev

フロントエンドのみの開発：

1
2
3

cd frontend
bun install
bun run dev

バックエンドのみの開発：

1
2

cd backend-go
make dev

主な環境変数

最小構成は通常次のようになります：

PORT=3000
ENV=production
ENABLE_WEB_UI=true
PROXY_ACCESS_KEY=your-proxy-access-key
ADMIN_ACCESS_KEY=your-admin-secret-key
APP_UI_LANGUAGE=zh-CN
LOG_LEVEL=info
REQUEST_TIMEOUT=300000

ポイント：

PROXY_ACCESS_KEY はプロキシ API 用で、必ず変更します。
ADMIN_ACCESS_KEY は Web 管理画面と /api/* 用で、プロキシ用キーとは分けるべきです。
ENABLE_WEB_UI は管理画面の有効化を制御します。
REQUEST_TIMEOUT はリクエストタイムアウトです。長文コンテキストや画像タスクでは増やせます。
LOG_LEVEL はログレベルです。本番環境では通常 info または warn を使います。

リクエスト本文サイズを制限したい場合：

`1`	`MAX_REQUEST_BODY_SIZE_MB=50`

画像編集、base64 画像、マルチモーダルリクエストでは本文サイズが大きくなりがちです。

チャネル編成とフェイルオーバー

CCX の管理画面では複数チャネルを設定でき、各チャネルに次のような項目を指定できます：

上流サービス種別。
API key または複数 key のローテーション。
プロキシアドレス。
カスタムリクエストヘッダー。
モデル許可リスト。
ルートプレフィックス。
優先度。
ヘルスチェックとサーキットブレーカー復旧。

スケジューリングでは、チャネル状態、優先度、プロモーション期間、Trace 親和性、サーキットブレーカー状態、利用可能な key を総合的に考慮します。簡単に言うと：

通常は優先度の高いチャネルが先に使われる。
あるチャネルが失敗するとバックアップへフェイルオーバーできる。
サーキットブレーカーにより、明らかに使えない上流へ打ち続けることを避ける。
Trace 親和性により、同種のセッションをなるべく適切なチャネルに維持する。

これは複数 key、複数プロバイダー、複数地域の上流がある場合に便利です。個人の軽量利用なら、1 つのチャネルだけを設定して Web UI 付きプロキシ層として使うこともできます。

ログと監視

CCX はチャネル指標とリクエストログを提供します。確認できるもの：

リクエスト数。
成功率。
失敗率。
平均遅延。
モデル別の履歴データ。
チャネル状態とサーキットブレーカー状態。

本番環境では控えめなログ設定がよいです：

ENV=production
LOG_LEVEL=info
ENABLE_REQUEST_LOGS=true
ENABLE_RESPONSE_LOGS=false

これにより基本的なリクエスト情報を残しつつ、完全なレスポンス内容をログに書かないようにできます。調査時には一時的に詳細ログを有効化できますが、終わったら戻すべきです。特に本番でリクエスト本文とレスポンス本文を長期出力し続けるのは避けます。

セキュリティ上の注意

CCX はプロキシゲートウェイであり、上流 API key を保存します。したがって「動けばよい」だけで終わらせるべきではありません。少なくとも：

デフォルトまたは短すぎる PROXY_ACCESS_KEY を使わない。
ADMIN_ACCESS_KEY を別に設定する。
Web 管理画面を直接インターネットへ公開しない。
公開が必要な場合は、リバースプロキシ、VPN、アクセス制御、SSO の後ろに置く。
.env、.config、ログファイルを Git にコミットしない。
本番環境で完全なリクエスト本文とレスポンス本文のログを長期的に有効化しない。

ランダムキーは次のように生成できます：

1
2

PROXY_ACCESS_KEY=$(openssl rand -base64 32)
ADMIN_ACCESS_KEY=$(openssl rand -base64 32)

向いている人

CCX は次のような場面に向いています：

Claude、OpenAI、Gemini、Codex、画像 API を同時に維持している。
複数の API key があり、ローテーション、分流、フェイルオーバーが必要。
設定ファイルを手で編集するのではなく Web UI で上流チャネルを管理したい。
各チャネルの成功率、遅延、リクエストログを観察したい。
チームへ統一された AI API 入口を提供したい。

自分のマシンで単一モデルをたまに呼ぶだけなら、公式 SDK や単一の OpenAI 互換プロキシのほうが簡単です。CCX の強みは、複数チャネル、複数プロトコル、統一運用にあります。

まとめ

CCX は AI API ゲートウェイであり、特定モデルのクライアントではありません。Claude Messages、OpenAI Chat、OpenAI Images、Codex Responses、Gemini を 1 つのプロキシ層にまとめ、チャネル編成、フェイルオーバー、ログ監視、Web 管理画面を提供します。

個人利用では API アドレスやキーの切り替えを減らせます。チームや長期運用サービスでは、軽量な AI ゲートウェイに近い存在です。本番導入前には、モデル設定だけでなく、キー、管理入口、ログレベル、チャネル優先度、フェイルオーバー戦略も整える必要があります。

参考

GitHub プロジェクト：https://github.com/BenedictKing/ccx
アーキテクチャ説明：https://github.com/BenedictKing/ccx/blob/main/ARCHITECTURE.md
環境変数説明：https://github.com/BenedictKing/ccx/blob/main/ENVIRONMENT.md

Codex は中国系 LLM とどう接続する？OpenAI 互換 API と CodexBridge の使いどころ

Wed, 13 May 2026 23:08:28 +0800

CodexBridge は、Codex CLI/SDK を OpenAI 互換の HTTP サービスとして公開するローカルブリッジです。これにより、これまでターミナル中心だった Codex を、OpenWebUI、Cherry Studio、スクリプト、自動化システム、または OpenAI Chat Completions 互換クライアントから呼び出せます。

中心となるエンドポイントは /v1/chat/completions と /v1/models です。前者は会話を処理し、通常の同期レスポンスと SSE ストリーミングをサポートします。後者は OpenAI 風のモデル一覧として利用できます。すでに OpenAI API に対応しているツールなら、基本的には base URL、API key、モデル名を変更するだけで済みます。

プロジェクト：https://github.com/begonia599/CodexBridge

向いている用途

CodexBridge は、Codex を既存の AI クライアントやワークフローに組み込みたい場合に向いています。たとえば：

OpenWebUI や Cherry Studio で Codex を直接選びたい。
curl、Python、Node.js などのスクリプトからローカル Codex を呼びたい。
1 つのフロントエンドから OpenAI、Ollama、他の互換 API、Codex を同時に扱いたい。
Codex のローカルスレッド、サンドボックス、作業ディレクトリ、承認ポリシーを維持したい。
社内ツールに統一された /v1/chat/completions 入口を提供したい。

これは新しい LLM ではなく、Codex CLI を完全に置き換えるフロントエンドでもありません。より正確にはアダプター層です。上流はあくまで Codex で、ブリッジが OpenAI 風のリクエストを Codex が扱える会話入力に変換します。

基本環境

必要なもの：

Node.js 18 以上。
インストール済みでログイン済みの Codex CLI。
npm。好みに応じて pnpm / yarn でも構いません。

ソースからの基本的なデプロイ手順：

git clone https://github.com/begonia599/CodexBridge
cd codexbridge
npm install
cp .env.example .env
cp .env .env.local

その後、.env または .env.local を編集し、API key、デフォルトモデル、作業ディレクトリ、サンドボックスモード、ネットワーク権限などを設定します。

HTTP サービスを起動します：

`1`	`npm run codex:server`

デフォルトポートは 8080 で、PORT で変更できます。起動後は次のエンドポイントを利用できます：

1
2
3

GET /health
POST /v1/chat/completions
GET /v1/models

CLI 会話モード

HTTP サービスのほかに、軽量な CLI も用意されています。

`1`	`npm run codex:chat`

CLI では自然言語を直接入力して Codex と対話できます。よく使うコマンドは次の 2 つです：

/reset: 新しい Codex スレッドを作成する。
/exit: CLI を終了する。

現在のスレッド ID は .codex_thread.json に保存されます。次回 CLI を起動したときにこのファイルが残っていれば、以前の会話を続けられます。

HTTP 呼び出し例

最小構成のリクエストは次のようになります：

curl http://localhost:8080/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer 123321" \
  -d '{"model":"gpt-5-codex:medium","session_id":"demo","messages":[{"role":"user","content":"ls"}]}'

注意点：

authorization の token は CODEX_BRIDGE_API_KEY と一致している必要があります。
model には gpt-5-codex:medium や gpt-5-codex:high のように推論レベルを付けられます。
session_id は会話を紐付け、同じ Codex スレッドを再利用するために使います。

ストリーミング出力が必要な場合は stream: true を追加します：

curl -N http://localhost:8080/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer 123321" \
  -d '{"model":"gpt-5-codex:high","session_id":"stream","stream":true,"messages":[{"role":"user","content":"Node.js プロジェクトの作り方を段階的に説明してください"}]}'

OpenAI のストリーミング応答に対応したクライアントなら、通常のチャットに近い体験になります。

セッション永続化

CodexBridge の重要な機能の 1 つがセッションマッピングです。リクエストでは次のフィールドからセッション ID を渡せます：

session_id
conversation_id
thread_id
user

ヘッダーから渡すこともできます：

x-session-id
session-id
x-conversation-id
x-thread-id
x-user-id

本番環境では次を有効にするのがおすすめです：

`1`	`CODEX_REQUIRE_SESSION_ID=true`

これによりすべてのリクエストにセッション ID が必須となり、別ユーザーや別チャットウィンドウの文脈が混ざるのを避けられます。ブリッジ側のマッピングは .codex_threads.json に保存されます。このファイルを削除するとブリッジ側の対応関係をリセットできますが、Codex 自体のスレッドは ~/.codex/sessions に残ります。

CODEX_REQUIRE_SESSION_ID=false でリクエストにセッション ID がない場合、ブリッジは現在の messages を一回限りの入力として Codex に渡します。これは一時的な呼び出しには便利ですが、長い会話には向きません。

マルチモーダル入力

CodexBridge は OpenAI 風の content block をサポートし、画像を Codex が扱える local_image 入力に変換します。

リモート画像：

{
  "type": "image_url",
  "image_url": {
    "url": "https://example.com/demo.png"
  }
}

ローカル画像：

{
  "type": "local_image",
  "path": "./images/demo.png"
}

リモートリソースは一時ディレクトリへダウンロードされ、ターン終了後に削除されます。実運用ではリクエスト本文のサイズに注意してください。特に画像を base64 で送る場合は、CODEX_JSON_LIMIT を増やす必要があるかもしれません。

構造化出力

クライアントが response_format に対応している場合、CodexBridge はそれを Codex の outputSchema にマッピングできます。チェック結果、要約、分類結果、自動化レポートなど、固定 JSON 構造を返したいときに便利です。

最小例：

{
  "model": "gpt-5-codex",
  "session_id": "lint",
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "lint_report",
      "schema": {
        "type": "object",
        "properties": {
          "summary": { "type": "string" },
          "status": {
            "type": "string",
            "enum": ["ok", "action_required"]
          }
        },
        "required": ["summary", "status"],
        "additionalProperties": false
      }
    }
  },
  "messages": [
    {
      "role": "user",
      "content": "src/ の lint 問題を確認し、結果を JSON で返してください"
    }
  ]
}

type: "json_schema" では schema が必須です。ない場合、サービスは 400 を返します。

主な環境変数

よく使う設定は次のように分けられます。

サービスと認証：

1
2
3

PORT=8080
CODEX_BRIDGE_API_KEY=123321
CODEX_JSON_LIMIT=10mb

デフォルトモデル：

1
2

CODEX_MODEL=gpt-5-codex
CODEX_REASONING=medium

Codex 実行環境：

CODEX_WORKDIR=
CODEX_SANDBOX_MODE=read-only
CODEX_APPROVAL_POLICY=never
CODEX_SKIP_GIT_CHECK=true

ネットワーク機能：

1
2

CODEX_NETWORK_ACCESS=false
CODEX_WEB_SEARCH=false

フロントエンドチャット用途だけなら、デフォルトでネットワークを閉じておくほうが安全です。Codex に curl、git clone、Web 検索を明確に実行させたい場合だけ、対応するスイッチを有効にします。

Docker とインストールスクリプト

長時間常駐させたい場合は Docker 方式も使えます：

1
2

docker compose up -d
docker compose logs -f codexbridge

Linux 用のインストールスクリプトもあります：

`1`	`curl -fsSL https://raw.githubusercontent.com/begonia599/CodexBridge/master/scripts/install.sh \| bash`

このスクリプトは依存関係をインストールし、リポジトリを clone または更新し、.env.example をコピーして Docker Compose でサービスを起動します。sudo 権限が必要なので、クリーンなサーバーでの素早いデプロイに向いています。すでに複雑な Node.js、Docker、Codex 環境がある場合は、実行前にスクリプト内容を確認してください。

よくある問題

リクエストが 413 を返す

通常はリクエスト本文が大きすぎます。base64 画像でよく起きます。次を増やします：

`1`	`CODEX_JSON_LIMIT=20mb`

API key が無効と表示される

リクエストヘッダーに次があるか確認します：

`1`	`Authorization: Bearer <your CODEX_BRIDGE_API_KEY>`

または x-api-key を使います。

Codex が Git リポジトリ制限を報告する

実行ディレクトリが信頼済みリポジトリではない場合、Codex のチェックに引っかかることがあります。安全を確認した環境でのみ使ってください：

`1`	`CODEX_SKIP_GIT_CHECK=true`

会話をリセットしたい

ブリッジ側のマッピングは .codex_threads.json、Codex 自身のスレッドは ~/.codex/sessions にあります。サービスを停止して該当ファイルまたはディレクトリを削除すればリセットできます。

使い方のすすめ

ローカルで試すときは、まずデフォルト API key と read-only サンドボックスで流れを確認します。OpenWebUI、Cherry Studio、スクリプトから正常に呼び出せることを確認してから、CODEX_WORKDIR、CODEX_SANDBOX_MODE、CODEX_NETWORK_ACCESS、CODEX_APPROVAL_POLICY を段階的に調整します。

複数人で使う場合は、少なくとも次の 3 点を行うべきです：

session_id を必須にする。
デフォルト API key を変更する。
作業ディレクトリとサンドボックス権限を明確に制限する。

CodexBridge の価値は機能の多さではなく、Codex を既存の OpenAI 互換エコシステムに入れられる点にあります。クライアントが base URL を変更できるなら、Codex を通常のチャットモデルのように扱いつつ、ローカルスレッド、サンドボックス、ツール利用といった Codex 本来の機能を維持できます。

2026年の組み込み開発環境はどう選ぶべきか: Keil、STM32CubeIDE、VS Code、そして AI 協調

Wed, 22 Apr 2026 23:05:00 +0800

マイコンや組み込み開発を続けていると、すぐにひとつの現実的な問いにぶつかります。2026 年になり、AI によるコーディング支援がかなり一般化してきた今、開発環境は結局どう選ぶのがよいのか、という問いです。

表面的にはこれは IDE 同士の比較に見えます。しかし実際に問われているのは別のことです。つまり、単に「プロジェクトを動かせる道具」が欲しいのか、それとも「既存エコシステム、コーディング体験、AI 協調」を両立できるワークフローが欲しいのか、ということです。

その観点で見ると、答えは Keil、STM32CubeIDE、VS Code、CLion のどれかひとつを選ぶことではなく、それぞれが得意な部分を組み直すことになりやすいです。

まず主な選択肢を見て、それぞれ何を解決しているのかを整理する

組み込み分野で長く見かける環境は、だいたい次のようなものです。

Keil
STM32CubeIDE
VS Code
CLion

さらに遡れば IAR を挙げる人もいます。ただ、今の議論で重要なのは「誰が一番古くからあるか」ではなく、「今の開発現実に誰が一番合っているか」です。

Keil: エコシステムは強いが、編集体験は明らかに古い

Keil は今でも避けて通りにくい存在です。理由は単純で、とにかく使われているからです。

会社に残っている古いプロジェクト、オンライン上の教材、サンプルコード、共有されている既存資産の多くが、今でも Keil を中心に組まれています。ビルド、書き込み、デバッグという一連の流れも依然として成熟しており、とにかく基板を動かすことが最優先なら、非常に短い道筋で済みます。

その一方で、弱点もかなりはっきりしています。

UI が古い
編集体験が平凡
AI 支援コーディングの主戦場にはなりにくい

つまり Keil は、「プロジェクトの入口とデバッグ基盤」としては強いものの、2026 年の編集体験を担う理想的な環境とは言いにくいです。

STM32CubeIDE: STM32 には親切だが、どちらかといえば学習と立ち上げ向き

STM32 のエコシステムを主に使っているなら、STM32CubeIDE は最初に触れる環境になりやすいです。

長所は非常にわかりやすいです。

入門しやすい
ペリフェラル設定やプロジェクト生成がしやすい
デバッグ系の流れも比較的そろっている

学生や初心者、立ち上げフェーズのプロジェクトには十分に直感的です。

ただし、長期運用、チーム協業、より複雑なワークフローに入っていくと、徐々に限界が見えてきます。特に商用プロジェクトや重めのチーム開発では、必ずしも最も快適な主環境ではありません。

そのため、これは「すばやく始めるための環境」であって、長期的な主力エディタとは限りません。

VS Code: 厳密には IDE ではないが、AI 時代では優位性が増している

VS Code は厳密には従来型の IDE ではなく、拡張可能なコードエディタです。

だからこそ、最初から二面性があります。

弱点は次の通りです。

プラグインや設定が必要
初心者にはあまり親切ではない
組み込み IDE の全工程をそのまま置き換えるわけではない

しかし、その同じ特徴がそのまま強みにもなります。

拡張性が高い
編集体験がかなり現代的
ハイライト、ジャンプ、検索、リファクタリングが強い
AI ツールや Agent ワークフローとの相性が良い

今や多くの開発者が欲しいのは、単に「コードが書けること」ではなく、「AI 協調を自然に入れられること」です。その意味で、VS Code の優位性はかなり明確です。

CLion: 体験は良いが、組み込みの主流ワークフローの中心ではない

CLion が話題に出ることはよくあります。C/C++ の編集体験が良いからです。

ただ、組み込み開発者にとって本当の問題は「良いか悪いか」より、「移る価値があるか」です。

組み込みでは利用者が比較的少ない
既存の組み込みエコシステムとの接続が Keil ほど直接的ではない
AI 協調という観点でも、VS Code より現実的な優位があるとは限らない

そのため、CLion は「理屈上はかなり良い選択肢」ではあっても、今の組み込み主流ワークフローの自然な中心とは言いにくいです。

より現実的な答え: ビルドとデバッグは Keil、日常のコーディングは VS Code

それぞれの道具を役割ごとに分けて考えると、かなり実務的な結論が見えてきます。

Keil には既存プロジェクト互換、ビルド、書き込み、デバッグを任せる
VS Code には日常のコーディング、検索、ジャンプ、AI 協調を任せる

この組み合わせの価値は、ひとつの道具ですべてをやろうとしない点にあります。それぞれを、本当に得意な位置に戻してあげるわけです。

多くの組み込み案件では、Keil のエコシステム自体を避けることができません。ならば、すべてを Keil に押し込めるより、Keil をビルド・デバッグのバックエンド入口と割り切り、実際の編集体験は VS Code に任せる方が自然です。

なぜこの組み合わせが AI 時代に向いているのか

今や環境の違いは、「エディタが気持ちよく使えるか」だけではありません。「AI を自然に接続できるか」が大きな分かれ目です。

VS Code にはこの点でかなり実務的な強みがあります。

AI プラグインや Agent の動きが活発
AI がプロジェクトを読み、変更するのに向いた閲覧体験
現代的なプラグイン群と組み合わせやすい

つまり、組み込み開発で面倒になりがちな作業の一部を AI に肩代わりさせやすくなります。

既存プロジェクト内の関数や呼び出し関係を探す
初期化コードを素早く生成する
簡単な UART 出力を足す
古いプロジェクト構造を説明させる
既存ファイルの一部だけを小さく直す

こうしたことは昔も不可能ではありませんでした。ただ、とにかくやりにくかったのです。VS Code の価値は、見た目がよいことではなく、AI 協調の作業台になりやすいことです。

重要な補助線: プラグインで VS Code と Keil プロジェクトをつなぐ

このワークフローが現実に機能するかどうかは、VS Code と Keil プロジェクトをつなげられるかにかかっています。

実用的な方向性のひとつは、VS Code から Keil のプロジェクト構造を読み取り、エディタ内部から Keil のバックエンドを呼び出して次のような操作を行えるようにすることです。

プロジェクトを開く
ビルドする
書き込む

そうすれば、日常のコーディングで二つの画面を行ったり来たりする必要が減ります。重いデバッグ、つまりステップ実行、ブレークポイント、レジスタ確認が必要なときだけ Keil に戻ればよくなります。

この種のプラグインの価値は、単に画面切り替えが減ることではありません。ワークフロー自体を途切れさせないことにあります。

C/C++ の基本プラグイン設定を軽視しない

VS Code を組み込みの主エディタとして使うなら、見落とされがちですが非常に重要な点があります。C/C++ の基本プラグインとプロジェクト索引をきちんと設定することです。

これが整っていないと、体験を壊す問題が次々に起きます。

定義ジャンプが効かない
赤線の誤検知が多い
補完の精度が低い
ヘッダ関係が崩れる

この状態を見て、「やはり VS Code は組み込みに向かない」と判断してしまう人もいます。ですが実際には、プラグインと索引の接続が不十分なだけであることが少なくありません。

この部分がきちんと整えば、VS Code は大規模プロジェクトの読解、シンボル検索、AI を使った局所的なコード修正でかなり強さを発揮します。

このワークフローが特に向いている人

この組み合わせは、特に次のような人に向いていると思います。

1. すでに Keil ベースの資産が大量にある人

会社の案件、教材、過去コードがすべて Keil 中心なら、見た目を現代化したいだけでその資産を捨てる必要はありません。Keil を残し、VS Code を前段に足す方が、移行コストははるかに低いです。

2. AI に組み込みコードを手伝ってもらいたい人

関数の説明、ひな形コードの生成、局所ロジックの修正などを AI に任せたいなら、従来型の組み込み IDE より VS Code の方が自然にその役割を引き受けやすいです。

3. 学習資料と実案件の両方をつなぎたい人

学習資料は今でも Keil ベースのものが多いですが、自分の作業環境までその時代に留まる必要はありません。Keil を互換層、VS Code を生産性層として分けて考える方が、全体としてバランスが取れます。

結び

2026 年の組み込み開発環境で本当に問われているのは、「どの IDE が最も多機能か」ではなく、「どの組み合わせが今の仕事のしかたに最も合っているか」です。

素早く始めたいだけなら STM32CubeIDE には今でも価値があります。大量の既存資産を受け継ぐなら Keil は依然として避けられません。ですが、現代的な編集体験と AI 協調まで取り込みたいなら、より現実的な答えは次の形になりやすいです。

Keil にビルドとデバッグを任せ、VS Code にコードを書く仕事を任せる。

唯一の正解ではないとしても、今ある選択肢の中ではかなり無理の少ない答えだと思います。

AI Tools on KnightLiブログ

ai-goofish-monitor：AI で閒魚の商品を自動監視するオープンソースシステム

先に結論

解決する問題

主な機能

ワークフロー

Docker デプロイ

最小構成

初回利用

AI タスクとキーワードタスク

Web UI でできること

データ保存

通知チャネル

開発者向け実行

向いている人

リスクと境界

普通のスクリプトとの違い

使い方の例

まとめ

OpenKB：ドキュメントを継続更新される LLM ナレッジベースへコンパイルする

先に結論

OpenKB とは

従来型 RAG との違い

PageIndex が解決する問題

インストールとクイックスタート

LLM 設定

よく使うコマンド

Markdown wiki が重要な理由

向いている場面

使うときの注意点

Obsidian、NotebookLM、企業 RAG との関係

おすすめのワークフロー

まとめ

Claude を Fusion 360 に接続する：AI で STEP モデルを修正する実例

まず Fusion 360 の API/MCP サービスを有効にする

STEP ファイルを開き、修正目標を明確にする

Claude はスクリーンショットで現在のモデルを理解できる

材料と加工方法は事前に伝える

Claude にギア構造を修正させる

ブラケットも一緒に修正する

エクスポート、スライス、プリント検証

使用上の提案

まとめ

Codex は中国系 LLM とどう接続する？CCX で OpenAI 互換 API を一元管理する

CCX が解決すること

対応エンドポイント

アーキテクチャの考え方

CCX と CodexBridge の違い

クイックデプロイ

Docker デプロイ

ソースから実行

主な環境変数

チャネル編成とフェイルオーバー

ログと監視

セキュリティ上の注意

向いている人

まとめ

参考

Codex は中国系 LLM とどう接続する？OpenAI 互換 API と CodexBridge の使いどころ

向いている用途

基本環境

CLI 会話モード

HTTP 呼び出し例

セッション永続化

マルチモーダル入力

構造化出力

主な環境変数

Docker とインストールスクリプト

よくある問題

使い方のすすめ

2026年の組み込み開発環境はどう選ぶべきか: Keil、STM32CubeIDE、VS Code、そして AI 協調

まず主な選択肢を見て、それぞれ何を解決しているのかを整理する

Keil: エコシステムは強いが、編集体験は明らかに古い

STM32CubeIDE: STM32 には親切だが、どちらかといえば学習と立ち上げ向き

VS Code: 厳密には IDE ではないが、AI 時代では優位性が増している

CLion: 体験は良いが、組み込みの主流ワークフローの中心ではない

より現実的な答え: ビルドとデバッグは Keil、日常のコーディングは VS Code

なぜこの組み合わせが AI 時代に向いているのか

重要な補助線: プラグインで VS Code と Keil プロジェクトをつなぐ

C/C++ の基本プラグイン設定を軽視しない