Tag: Ai Posted: 2026-05-30
| Tags:
ai ,
codex ,
llm ,
openai ,
operations
Codexの利用量とPrompt Cachingの見方 Codex を ChatGPT plan で使っていると、ローカルログ上はかなり大きな token 数に見えることがある。
ただし、ChatGPT plan の Codex 利用と OpenAI API 課金は同じものではない。ChatGPT plan 側では agentic usage limit と rate limit で制御され、API 側では input / cached input / output の token 単価で課金される。
このメモは、Codex を重めに使っている時に次の点を確認するための整理である。
今月どのくらい使っているように見えるか API 課金だったらどの程度になりそうか cached input は何を意味するか 重い使い方が Codex の想定範囲なのか 参考 URL:
まず見るローカル情報 Codex CLI は ~/.codex 配下にローカル状態と session JSONL を持つ。
Read more... Posted: 2026-05-29
| Tags:
agent ,
ai ,
codex ,
documentation ,
llm
AI Agent向けContext Hygieneの段階導入 AI agent に長期運用を任せる場合、ドキュメントは多いほどよいとは限らない。
過去ログ、設計メモ、運用手順、トラブルシューティング、現在の作業状態が同じ場所に増えていくと、agent は読むべき情報を失う。情報が消えるのではなく、常時読む context の中で重要度が埋もれる。
この問題は、短い context だけで解決するものではない。必要なのは、情報を捨てることではなく、読み込む頻度と役割に応じて置き場所を分けることである。
基本方針 常時読むファイルは、現在の正だけを持つ。
履歴や失敗経緯は別の memory index に置く。再発する障害は known issues に昇格する。手順は runbook に、設計判断は design document に置く。
役割は次のように分ける。
current context
agent が毎回読む working set
現行構成、現在の制約、危険な前提、読むべき入口だけ
memory index
過去経緯の索引
日付、要点、詳細リンク
known issues
現在も再発しうる障害
症状、確認コマンド、原因候補、対応
operation docs
手順、runbook、検証計画、実行境界
system docs
設計判断、責務境界、contract、恒久制約
troubleshooting docs
調査記録、原因分析、再発時の切り分け
archive
現行ではない履歴
memory index から必要時だけ辿る
この分割にすると、常時読む context を小さく保ちながら、過去判断の再利用性を落としにくい。
Read more... Posted: 2026-05-24
| Tags:
agent ,
ai ,
codex ,
llm ,
operations
何が起きたか AI agent に、自宅検証環境の復旧と設計相談を任せていた。
使っていたのは GPT 5.5 xhigh の coding agent で安定してた。それでも、既存ドキュメントに残っていた重要な制約を、計画上の制約として扱いきれなかった。
具体的には、ある Windows app installer を Wine / container / Kubernetes volume 上で動かす検証で、install destination が local disk として見える必要があった。
Linux 側では path が見えており、Kubernetes volume として mount でき、read/write もできる。しかし app 側はそれだけでは通さない。Windows API 的に remote filesystem と判定されると installer が止まる(NFS上にストレージを置くとエラーになる)。
# TF_VAR_xpra_basic_auth_htpasswd: ‘kaoru:$2y$05$replace_with_htpasswd_output_after_changeme’
Wine / Windows app の文脈では、たとえば GetDriveType("C:\\") が DRIVE_FIXED なのか DRIVE_REMOTE なのかが効く場合がある。
この制約は過去ログや既存メモに残っていた。しかし AI agent は、復旧計画を立てる時点でそれを制約事項に昇格できなかった。
推論力不足ではなく制約抽出の失敗 この失敗は、単純な推論力不足とは少し違う。
AI は関連ログを読めば、NFS-backed path が local disk と見なされず installer が失敗したことを説明できた。つまり、後から問われれば正しく整理できる。
Read more... Posted: 2026-05-20
| Tags:
ai ,
benchmark ,
bfcl ,
local-llm ,
terminal-bench ,
tool-calling
先に私の評価結果 2026年時点でNvidia 3060 10GBメモリモデルで検証 現状のローカルLLMは日本語はかなりのものを返すようになった( 1bit LLMでも割と正しいものを返す )ただし tool search , tool use の機能の正確さはまだ良くない( 結構な頻度で失敗する ) ローカルLLMへの期待としては 1bit LLM かつ tool search 機能を最初から学習したモデルが待たれる ローカルLLM AdapterをBFCLとTerminal-Benchで評価する計画 ローカル LLM の評価では、model 単体の一般能力と、adapter を含む tool calling 経路の品質を混ぜない方がよい。
今回測りたいのは、Hermes 3 Llama 3.1 8B の総合知能ではなく、Hermes adapter が Codex CLI 互換の tool call をどれだけ安定して成立させるかである。
そのため、評価対象を次の 3 層に分ける。
層 評価したいもの adapter-native parser、tool routing、warning filter、output relay、suppression proxy / CLI OpenAI-compatible proxy、Responses 変換、Codex CLI JSONL terminal task terminal agent としての最終タスク達成
BFCLとTerminal-Benchの位置づけ BFCL は function calling の評価に近い。adapter の tool schema 変換、arguments、tool name、malformed recovery を見るには相性がよい。
Read more... Posted: 2026-05-20
| Tags:
ai ,
codex ,
local-llm ,
tool-calling ,
troubleshooting
ローカル LLM と tool calling adapter を組み合わせると、失敗原因が複数の層に分かれる。
最終応答だけを見ると「model が間違えた」に見えるが、実際には次のような層のどこかで起きていることが多い。
model context / VRAM Hermes prompt / parser tool pruning / router OpenAI-compatible proxy CLI の tool execution shell sandbox internal web tool external research helper benchmark harness このメモでは、公開してもよい抽象度でトラブルの傾向を整理する。実 port、実 path、token 名、host 名、生ログは private runbook 側に残す。
全体の切り分け flowchart TD
Final[final answer] --> A{tool call eventは出たか}
A -->|no| Router[adapter router / model tool selection]
A -->|yes| B{tool executorは動いたか}
B -->|no| Proxy[proxy / schema / unknown tool]
B -->|yes| C{tool outputは正しいか}
C -->|no| Sandbox[sandbox / command / environment warning]
C -->|yes| D{finalが正しいか}
D -->|no| Relay[output relay / model summarization]
D -->|yes| Done[pass]
まず見るべきなのは final answer ではなく、tool call event と tool result 。
Read more... Posted: 2026-05-20
| Tags:
ai ,
codex ,
hermes ,
local-llm ,
tool-calling
なぜこのアプローチを試しているのか ローカルLLM、日本語は結構返してくれるようになった tool searchの段階で結構あやしい ローカルLLMの性能に期待せずに、途中でインターセプトしてcodexなどから使えないか?と考えた 2026年時点ではまだうまくできてない(かなりのユースケースに対応するコードが必要そう) 小型のローカル LLM を coding agent や terminal helper に使う場合、通常の chat 品質よりも tool call の安定性が先に問題になる。
特に 8B 級の model では、次のような失敗が起きやすい。
tool call すべき場面で自然文のコマンド例を返す tool name や arguments の JSON が崩れる tool 数が多すぎて選択を誤る tool output に混じった環境 warning を実行結果と誤解する 「実行しないで」と言われたのに実行系 tool を選びかける このメモは、Hermes 3 Llama 3.1 8B Q5_K_M を例に、ローカル LLM と Codex CLI の間に小さい adapter を置いて tool call を安定させる設計をまとめる。
基本構成 想定した流れは次のようになる。
flowchart LR
CLI[Codex CLI] --> Proxy[OpenAI-compatible proxy]
Proxy --> Adapter[Hermes tool adapter]
Adapter --> Llama[llama-server]
Llama --> Model[Hermes 3 Llama 3.1 8B GGUF]
Adapter --> InternalTools[adapter internal read-only tools]
InternalTools --> Fetch[fetch_url]
InternalTools --> Search[search_web]
InternalTools --> Research[optional research helper]
CLI --> ToolExecutor[Codex tool executor]
ToolExecutor --> Shell[exec_command / write_stdin]
役割を分けると、
Read more...