Tag: Ai

エキスパートシステムから生成AIエコシステムへ

Posted: 2026-06-15 | Tags: agent, ai, expert-system, genai, llm, rag

エキスパートシステムから生成AIエコシステムへ

古典的なエキスパートシステムは、主に知識ベースと推論エンジンによって、専門家の判断をルール化して扱う仕組みだった。

現在の生成AIでは「エキスパートシステム」という名前はあまり使われない(技術的な連続性も乏しいと思います)。しかし、その構成要素は RAG、tool calling、agent runtime、guardrails、policy engine、workflow engine、observability などに分解されて生き残っている。

現代的には、次のように捉えると分かりやすかった。

LLM が曖昧な自然言語理解、分類、計画、候補生成を担い、 RAG が外部知識を与え、 tool calling が外部手続きを実行し、 guardrails / policy engine / schema validation / approval gate が決定性と安全性を補う構成。

古典的構成との対応

古典的エキスパートシステムの要素	現代の生成AI周辺で近いもの	役割
Knowledge Base	RAG、Vector DB、全文検索、Knowledge Graph、ドキュメント index	LLM 本体にない外部知識を検索し、質問に応じて関連 context として渡す
Rule Base	Guardrails、Policy-as-Code、OPA/Rego、JSON Schema、Business Rule Engine	「この条件なら許可/拒否」「この形式以外は不可」「このトピックは禁止」などの明示ルールを担う
Inference Engine	Agent runtime、agent harness、planner-executor	LLM が tool 選択や次の行動を判断し、外側の実行基盤がループを管理する
Forward Chaining	Event-driven automation、監視 alert pipeline、SOAR、workflow engine	事実やイベントを起点に次の処理を発火する。例: ログ異常、分類、runbook 検索、ticket 作成
Backward Chaining	Query planning、RAG query decomposition、multi-step retrieval	目標から逆算して、必要な情報、検索、tool call を決める
Working Memory	Conversation state、agent state、scratchpad、checkpointer	現在の事実、途中結果、tool 結果、会話履歴を保持する
Explanation Facility	Trace、citation、observability、eval、provenance	判断過程、参照元、tool 実行履歴を後から検証できるようにする
Knowledge Acquisition	Document ingestion、connector、crawler、MCP resource、schema extraction	専門家の知識、ドキュメント、API、GitHub、Slack、チケットなどを取り込む
External Procedure Call	Tool calling、function calling、MCP tools	LLM の判断を外部 API、CLI、DB、Kubernetes、GitHub などの操作へ接続する
Input / Output Validator	Structured Outputs、JSON Schema、Pydantic/Zod validation	LLM 出力を自由文ではなく、機械処理しやすい schema 準拠データにする
Safety / Compliance Layer	Guardrails、moderation、PII filter、topic control、approval gate	危険操作、情報漏洩、不適切出力、権限逸脱を防ぐ
User Questioning / Interview	Elicitation、フォーム補完、human-in-the-loop approval	不足情報を人間に確認し、重要操作では承認を挟む

古典的な仕組みとの違い

古典的エキスパートシステムでは、推論の中心は if X then Y のような明示ルールだった。

Gemma 4 E4B QAT Q4_0をCodex CLIローカルモデルとして評価したメモ

Posted: 2026-06-14 | Tags: ai, codex, gemma, llama-server, local-llm, mcp

Gemma 4 E4B QAT Q4_0 GGUF を、Codex CLI の text-only local model backend 候補として試した。

比較対象は、先に評価していた Gemma 4 12B Q4_K_M である。見たかったのは、単なる短文応答ではなく次の 4 点だった。

12B より GPU memory が下がるか
Codex CLI の agent prompt を現実的な context に収められるか
JSON final answer と read-only shell tool use が成立するか
広い文書検索や MCP tool selection で破綻しないか

先に結論を書くと、E4B は memory / speed 面では 12B よりかなり扱いやすい。一方で、Codex CLI の tool routing まで含めると、12B の単純な置き換えではない。特に MCP tool を model に直接選ばせる構成は不安定で、検索 intent は adapter / router 側でルールベースに拾う方が堅い。

Gemma 4 12B Q4_K_MをCodex CLIローカルモデルとして評価したメモ

Posted: 2026-06-13 | Tags: ai, codex, gemma, llama-server, local-llm, tool-calling

Gemma 4 12B Q4_K_M の GGUF を llama-server で起動し、OpenAI-compatible proxy を挟んで Codex CLI の local model として使えるかを試した。

後続では、同じ環境で Gemma 4 E4B QAT Q4_0 の軽量 backend 評価も行った。

見たかったのは、単なる短文応答ではなく次の 3 点だった。

Codex CLI の大きめの agent prompt を context に収められるか
JSON-only final answer が壊れないか
shell tool call と tool result の読み取りが成立するか

先に結論を書くと、12GB class GPU でも ctx=16384, ngl=28, --reasoning off なら短時間の JSON/tool smoke は通った。ただし、長文、温度、tool schema の増加、別の chat template ではまだ崩れる余地がある。

構成

抽象化すると構成はこうなる。

flowchart LR
    Codex[Codex CLI] --> Proxy[OpenAI-compatible proxy]
    Proxy --> Llama[llama-server]
    Llama --> Model[Gemma 4 12B Q4_K_M GGUF]
    Codex --> Tools[Codex tool executor]

今回の評価では adapter を挟まず、proxy の Responses API 変換から llama-server の Chat Completions へ流した。

AI Agent向けContext Hygieneの段階導入

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 を小さく保ちながら、過去判断の再利用性を落としにくい。

強いAIでも制約抽出とゲート化に失敗する

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 が失敗したことを説明できた。つまり、後から問われれば正しく整理できる。

ローカルLLM AdapterをBFCLとTerminal-Benchで評価する計画

Posted: 2026-05-20 | Tags: ai, benchmark, bfcl, local-llm, terminal-bench, tool-calling

先に私の評価結果

2026年時点でNvidia 3060 12GBメモリモデルで検証
現状のローカル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 を見るには相性がよい。

ローカルLLM Tool Adapterのトラブルシューティング分類

Posted: 2026-05-20 | Tags: ai, codex, local-llm, tool-calling, troubleshooting

ローカルLLM Tool Adapterのトラブルシューティング分類

ローカル 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 。

ローカルLLMでTool Callを安定させるHermes Adapter設計メモ

Posted: 2026-05-20 | Tags: ai, codex, hermes, local-llm, tool-calling

なぜこのアプローチを試しているのか

ローカルLLM、日本語は結構返してくれるようになった
tool searchの段階で結構あやしい
ローカルLLMの性能に期待せずに、途中でインターセプトしてcodexなどから使えないか?と考えた
2026年時点ではまだうまくできてない(かなりのユースケースに対応するコードが必要そう)

ローカルLLMでTool Callを安定させるHermes Adapter設計メモ

小型のローカル 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]

役割を分けると、

PicoClawを最初に動かすまでのメモ

Posted: 2026-03-15 | Tags: ai, getting-started, picoclaw, slack

PicoClawを最初に動かすまでのメモ

PicoClaw は設定項目が多いが、最初は全部を理解しなくても動かせる。

この記事では、次の流れだけに絞る。

PicoClaw を用意する
~/.picoclaw/config.json を作る
モデルを 1 つ設定する
必要なら Slack を 1 つつなぐ
picoclaw gateway を起動する
DM またはメンションで疎通確認する

1. PicoClaw を用意する

ソースから使うなら、まずリポジトリを取得してビルドする。

git clone https://github.com/sipeed/picoclaw.git
cd picoclaw
make deps
make build

インストール済みの picoclaw バイナリを使うなら、この段階は省略できる。

2. 初期ファイルを作る

最初に設定ファイルと workspace を作る。

picoclaw onboard

これで通常は次が作られる。

~/.picoclaw/config.json
~/.picoclaw/workspace/

workspace 配下には、AGENT.md や USER.md、skills/ などのベースファイルが入る。

3. 最小の `config.json` を書く

最初は API で使うモデルを 1 つだけ定義すれば十分だ。

{
  "agents": {
    "defaults": {
      "workspace": "~/.picoclaw/workspace",
      "restrict_to_workspace": true,
      "model_name": "gpt-5.4"
    }
  },
  "model_list": [
    {
      "model_name": "gpt-5.4",
      "model": "openai/gpt-5.4",
      "api_key": "sk-your-openai-key",
      "api_base": "https://api.openai.com/v1"
    }
  ]
}

ここで大事なのは次の3つ。

PicoClawのスキル一覧を確認する方法と現状入っているスキル

Posted: 2026-03-15 | Tags: ai, cli, picoclaw, skills

PicoClawのスキル一覧を確認する方法と現状入っているスキル

PicoClaw のスキルは、特定用途の手順や知識、補助スクリプトをまとめた小さなパッケージとして扱われる。

ここでは次の 2 つをまとめる。

スキル一覧を確認する方法
現在 ~/.picoclaw/workspace/skills に入っているスキルの説明

スキル一覧を確認する方法

CLI から確認するなら、まずはこれでよい。

picoclaw skills list

現行実装では skills list は「インストール済みスキル」を列挙するコマンドになっている。

picoclaw skills list

必要なら個別スキルの詳細確認もできる。

picoclaw skills show weather
picoclaw skills show github

コマンド実装はこのあたりにある。

ファイルで直接確認する方法

workspace 側にあるスキルの実体は、次のように確認できる。

find ~/.picoclaw/workspace/skills -maxdepth 3 -type f | sort

基本的には各スキルディレクトリの SKILL.md が中心で、必要に応じて references/ や scripts/ が付く。

典型的な構成はこうなる。

~/.picoclaw/workspace/skills/
  weather/
    SKILL.md
  tmux/
    SKILL.md
    scripts/
      find-sessions.sh
      wait-for-text.sh
  hardware/
    SKILL.md
    references/
      board-pinout.md
      common-devices.md

現在入っているスキル

現在の ~/.picoclaw/workspace/skills には 6 個のスキルが入っている。

PicoClawの現行設定方針メモ

Posted: 2026-03-15 | Tags: ai, config, llm, picoclaw

PicoClawの現行設定方針メモ

PicoClaw は設定項目がかなり多いが、現行の方針としては ~/.picoclaw/config.json を model_list 中心で組み立て、必要なチャネルと機能だけを有効化するのが分かりやすい。

この記事は過去の互換設定はいったん脇に置き、今から設定するならどう書くかに絞っている。

まず押さえる方針

モデル定義は model_list を使う
agents.defaults.model_name で既定モデルを決める
チャネルは使うものだけ enabled: true にする
allow_from は空にせず、可能なら必ず制限する
Web 検索やスキル、MCP などの補助機能はデフォルトを尊重し、必要になってから増やす
MCP は npm / node / npx 経由の実装が多いため、可能なら自前の小さい実装、checksum 固定済み binary、lockfile 付き npm install の順で検討する
公開用の設定例にはトークン、ユーザー ID、社内 URL、内部ホスト名を書かない

現行での最小構成

最初はこれくらいで十分だと思う。

{
  "agents": {
    "defaults": {
      "workspace": "~/.picoclaw/workspace",
      "restrict_to_workspace": true,
      "model_name": "gpt-5.4"
    }
  },
  "model_list": [
    {
      "model_name": "gpt-5.4",
      "model": "openai/gpt-5.4",
      "api_key": "sk-your-openai-key",
      "api_base": "https://api.openai.com/v1"
    }
  ],
  "channel_list": {},
  "tools": {},
  "gateway": {
    "host": "127.0.0.1",
    "port": 18790
  }
}

ポイントは、PicoClaw は未指定項目をかなりデフォルトで補完してくれることだ。最初から巨大な config.example.json を全部埋める必要はない。

`model_list` を中心に考える

現行では providers より model_list を主に使う前提で考えた方がよい。

Tag: Ai

エキスパートシステムから生成AIエコシステムへ

古典的構成との対応

古典的な仕組みとの違い

構成

AI Agent向けContext Hygieneの段階導入

基本方針

何が起きたか

推論力不足ではなく制約抽出の失敗

先に私の評価結果

ローカルLLM AdapterをBFCLとTerminal-Benchで評価する計画

BFCLとTerminal-Benchの位置づけ

ローカルLLM Tool Adapterのトラブルシューティング分類

全体の切り分け

なぜこのアプローチを試しているのか

ローカルLLMでTool Callを安定させるHermes Adapter設計メモ

基本構成

PicoClawを最初に動かすまでのメモ

1. PicoClaw を用意する

2. 初期ファイルを作る

3. 最小の config.json を書く

PicoClawのスキル一覧を確認する方法と現状入っているスキル

スキル一覧を確認する方法

ファイルで直接確認する方法

現在入っているスキル

PicoClawの現行設定方針メモ

まず押さえる方針

現行での最小構成

model_list を中心に考える

3. 最小の `config.json` を書く

`model_list` を中心に考える