エキスパートシステムから生成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 が決定性と安全性を補う構成。

古典的構成との対応

古典的な仕組みとの違い

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

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

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 を主に使う前提で考えた方がよい。