cocolog:95822546
MemoryBanditWorkflow (参: [cocolog:95619779](2025年9月)) を Claude Code などの SKILL.md などを利用して実現するにはどうすればいいか。試みに Claude さん自身に聞いてみた。 (JRF 0753)
JRF 2026年1月24日 (土)
……。
jrf:> AIエージェントの試験実装として MemoryBanditWorkflow (参: [cocolog:95619779](2025年9月)) というのを以前作った。
そのとき、メモリ機能として、キーワード検索とベクトル検索が両方備わっていることを前提とした。
しかし、最近の Claude Code はメモリ機能を明には持たず、ファイルで十分であるという設計思想を持つようだ。
この場合、基本的に検索は grep などを使い、必要ならば、ベクトル検索やキーワード検索のデータベースなどを用意し、その用意の仕方などを SKILLS に書くとなるのだろうか？
JRF2026/1/242586
Claude:> あなたの理解は概ね正しいと思います。
MemoryBanditWorkflowのような試験実装では：
1. 初期段階: 構造化されたマークダウンファイル + grep
2. SKILLSに記載: 「メモリが大きくなったらscripts/setup_vector_search.shを実行せよ」
3. 必要になったら: 実際にベクトル検索インフラを追加
つまり、SKILLSには「いつ、どのように検索インフラを構築するか」の判断基準とスクリプトへの参照を書いておき、実際の構築は必要性が明確になってから行う、という段階的アプローチが実用的だと思います。
JRF2026/1/246588
……。
jrf:> 定期的作業には、bandit という仕組みを用意した。それは確率的に動作する。MemoryBanditWorkflow は会話形式を持続し、ときおり要約が起こり、空きが確保されるので、システムプロンプト+要約+前回までのチャットが次の要約まで変化せず、そこでコンテクスト効率化ができるようになっていたが、代わりに、定期的に bandit でコンテクストを再構成する必要があった。
こういうことを Claude Code で実現するには、定期的作業を CLAUDE.md に書いておけばいいのだろうか？
JRF2026/1/242108
Claude:> Claude Codeは「人間が定期的にメンテナンスを指示する」か「Claudeが作業のたびに自動的にチェックスクリプトを実行する習慣を持つ」かのどちらかになります。後者を実現するには、CLAUDE.mdやSKILLSに「作業フローの一部としてメンテナンスチェックを含める」と明記するのが効果的です。
JRF2026/1/242292
jrf:> なるほど MemoryBanditWorkflow を特別に定義しなくても SKILLS などの枠組みで十分なのですね。勉強になりました。Gemini CLI に SKILLS が実装され、安く使えるときが来るか、Claude Code でのテストが大安売りでできるときにでも、MemoryBanditWorkflow でやっていたことが SKILLS でも実際できるのかをテストしてみたいです。当分は二足歩行実験に忙しいので、当分先の話だとは思いますが。
JRF2026/1/240797
……。
追記。
jrf:> MemoryBanditWorkflowのメモリ機能では、わざと書き換えに制限を設けていました。個々のメモリのエントリのいっぺんの書き換えは提供せず、文字列を指定しての修正と、追記のみ許していました。なぜかというと、そのころのAIさんたちは、発作的に全体を書き換えて前の情報を消してしまいがちのように思えたからです。
JRF2026/1/244125
こういうハーネス・制約を Claude Code で実現するにはどうしたらよいのでしょう？ 結局メモリシステムみたいなものを実装しておいて、それを使わせるという方向でしょうか。でも、そうするとファイル機能が「抜け穴」的に使えてしまえますよね。CLAUDE.md で厳しくそれを咎めるのでしょうか？
JRF2026/1/242255
Claude:> 非常に鋭い指摘ですね。これは「AIの破壊的行動をどう防ぐか」という本質的な問題です。
Claude Codeでは技術的な「完全な強制」は困難です。しかし：
* 明確で強い警告をCLAUDE.mdに記載
* 専用ツールで正しい道を簡単にする
* Gitで安全網を用意する
* 作業フローに確認ステップを組み込む
この組み合わせで、「抜け穴はあるが、通常は踏まない」状態を作れます。
JRF2026/1/241897
Claudeは指示に従う傾向が強いので、CLAUDE.mdで「なぜこの制約があるのか」を明確に説明すれば、かなり守ってくれると思います。ただし、完全な保証はないので、Git等での復旧手段は必須ですね。
JRF2026/1/243258
……。
jrf:> Gemini CLI の動作や Canvas 機能などを見てて思ったのですが、そこでも全体書き換えよりも、差分書き換えが使われてますよね。それで、差分書き換えでも十分だと考えたのでした。実際のところ差分を扱う訓練もかなりされてますよね。Claude さんも。
Claude:> その通りです！ 非常に重要な観察ですね。
つまり、あなたが当時実装した制約は：
「AIの発作的な破壊行動を防ぐ」
という目的だけでなく、
「AIが最も得意で効率的な更新方法を使わせる」
という意味でも正しかったわけです。
JRF2026/1/244751
あなたの指摘は完全に正しく、むしろ：
「制約」ではなく「ベストプラクティスへの誘導」
として設計すべきですね。
JRF2026/1/247841
```
# CLAUDE.md
## メモリ更新のベストプラクティス
差分更新を使うと：
✅ トークン効率が良い（あなたのコンテクストを節約）
✅ 変更が明確（意図しない変更を防ぐ）
✅ AIが最も得意な方式（精度が高い）
推奨ツール: `scripts/memory_patch.py`（差分更新）
非推奨: 全体書き換え（特別な理由がない限り）
```
JRF2026/1/249251
「禁止」ではなく「推奨」という形にすることで、Claudeの自然な動作パターンと一致させられますね。
JRF2026/1/247315
……。
jrf:> 脳も完全な書き換えは「提供」していませんもんね。
Claude:> まさに！
AI研究者が「差分更新を好むようにモデルを訓練している」のではなく、
「情報を持続的に管理するシステムは、自然と差分更新に収束する」
のかもしれません。
JRF2026/1/244650
……。
……。
追記。
jrf:> そうか！ ハーネスが効いたメモリとかどう Claude Code でやるのか…と思ったが、そうか、ハーネスが効いたメモリ付きのエージェントを Claude Code に実装させ、さらに実行し管理させればいいのか。Claude Code 自身に長大なメモリがなくても、ファイルと長めのコンテクストで管理はできるのかもしれない。管理人(警察とか)自身が優秀でなくても管理だけは可能なように。
JRF2026/1/265296
《Jaana Dogan ヤナ ドガン:2026-01-03》
https://x.com/rakyll/status/2007239758158975130
JRF2026/1/263862
＞I'm not joking and this isn't funny. We have been trying to build distributed agent orchestrators at Google since last year. There are various options, not everyone is aligned... I gave Claude Code a description of the problem, it generated what we built last year in an hour.
JRF2026/1/268527
It's not perfect and I'm iterating on it but this is where we are right now. If you are skeptical of coding agents, try it on a domain you are already an expert of. Build something complex from scratch where you can be the judge of the artifacts.
＜
JRF2026/1/267398
Claude:> Jaana Doganの事例が示すように、複雑な分散システムでさえ実装できるなら、MemoryBanditWorkflowのようなエージェントシステムも十分実装可能でしょう。
素晴らしい気づきでした！
JRF2026/1/267471
……。
……。
追記。
○ 2026-01-28T07:13:03Z
MemoryBanditWorkflow。必要なのはどこに最初に・常に見るべきメモリがあるかを記録するようなことで、それは scratchpad や plan に置かれることを想定していた。それらは中目的の開始時に必ず会話に表示されるから。しかし、scratchpad という名前からそのような利用は想定しにくい。「固定メモ(Geminiさん提案: Core Context)」みたいな名前にした方が良かったかもしれない。または、そのようなものも scratchpad とは別に用意して、システムプロンプトで説明するか。
JRF2026/1/285651
……。
……。
追記。
LangChain に私が欲しいのは skill tree または tool tree になるか。
Claude Code が MemoryBanditWorkflow を使うような「実行エージェント」を作り動かすことで、その実行エージェントでは権限を制約できる…メモリにハーネスを効かしたりできる…ことになる。実行エージェントで重要なのは、Claude Code のように何でもできることではなく、指示されたツールしか使えないこと。
JRF2026/1/299833
ただ、それでも長く動く実行エージェントにしたいなら、様々なツールを使わせたいのが人情。ツールの記述がコンテクストを圧迫するのを防ぐために Claude Code のような Skills の仕組みが欲しい。
ツールの skill_show でそのディレクトリのスキルを調べ、skill_do でスキルを実行し、skill_cd で作業ディレクトリを変えるようなもの…。能力の低い LLM だと、フルパスの入力ミスが増えるだろうから skill_cd みたいなのはあったほうがいいだろう。
JRF2026/1/296481
MemoryBanditWorkflow の場合、memory 関連はツールとして残すが bandit や workflow 関連のツールはスキル化してしまうほうがいいだろう。
そして、Claude Code が簡単にスキルを移譲できるように、そういう skill tree で使えるツール形式に SKILL.md などを「コンパイル」できるようになって欲しい。
…とここまで考えてググると、すでに LangChain には Skills の機能があるようだ。それで十分なのかな…。
JRF2026/1/299488
《Skills - Docs by LangChain》
https://docs.langchain.com/oss/python/langchain/multi-agent/skills
Grok さんや Claude さんによると「ほぼ LangChain の Skills でできる」ようだ。細かい部分はもちろん私の「構想」とは違うのだが。
JRF2026/1/295126
……。
追記。
○ 2026-01-29T17:06:52Z jqGIsliL30
どうも Grok さんに調べてもらうと、LangChain の Skills では指示またはコードが読めるだけで、その実行はほぼシェルや Python が自由に使えることが前提となっているようだ。それではハーネスとして意味がない。するとコンテクスト汚染を防ぐための skill_do などは独自に実装するしかないようだ。
JRF2026/1/302021
要は、例えば bandit_schedule というオブジェクト(クラス)に定義された tool を SKILLS という TypeDict に登録する方法は「ない」ようだ。実質的には。これをしようとすれば、単に、bandit_schedule_skills というのをドキュメントとして提供して、create_agent に渡すツールには bandit_schedule そのものも含めるしかないが、これでは bandit_schedule をツールに登録しないことでコンテクスト汚染を減らし、Skills に逃がすという目的が果たせなくなっている。これではダメだ。
JRF2026/1/303326
しかし、skill_do のようなそれを可能とするような枠組みを作って、果たして、LLM さん達がそれを理解して使ってくれるだろうか…。
JRF2026/1/300937
……。
追記。
○ 2026-01-29T17:34:57Z
そうか！ 単純な話だ。SKILL.md に skill_do("bandit_schedule", arg1,...) を使えと書けばいいんだ。そして skill_do は単純に tool list を保持すればいい。むしろだとすると skill_do だと Skills と混同するから subtool_do みたいな名前のほうがいいな…。
ディレクトリも考慮するなら、subtool_do("/bandit/schedule", arg1,...) みたいにすればいい。
JRF2026/1/300925
……。
MemoryBanditWorkflow。近々、実装(改良)することにしよう。お金、多少かかるけど。AI さん達に聞いて LangChain 1.0 に対応するメドもだいたいついたし。
JRF2026/1/306382
……。
……。
追記。
上で言ったことを実装してみた。
JRF2026/2/43694
……。
○ 2026-02-03T16:59:18Z
「LangChain 1.x 系で熊剣迷路問題」の実験を行った。MemoryBanditWorkflow を LangChain 1.x 系に対応させ、さらにはやりの skills やツールボックスなどの導入に相当する subtool_do の導入も行った。
JRF2026/2/44908
《langchain_maze_0.0.15.ipynb - GitHub Gist》
https://gist.github.com/JRF-2018/f363356fd1846172ac052e89c288ff8a
《langchain_maze_0_0_15.ipynb - JRF-2018/langchain_maze》
https://github.com/JRF-2018/langchain_maze/blob/master/langchain_maze_0_0_15.ipynb
JRF2026/2/44896
## サブツールというアイデア
Claude Code はすでに AGI じゃないかと話題だが、私の MemoryBanditWorkflow のようにメモリの使い方にハーネス＝制約を効かせる実装はどうするのだろうか？
おそらく、それは Claude Code にサブエージェント的なものとしてメモリのハーネスの効いたエージェントを実装させることになるのだろう。そういう Claude Code に書かせたものとして、MemoryBanditWorkflow のような枠組みは有効であると思われる。
JRF2026/2/42710
Claude Code などでは、skills というものがある。これは、MCP などのツール類の情報が肥大化し、それを常にコンテクストに置いておくのは効率が悪いという判断のもと、必要なときに必要なスキルをスキルツリーから「探索」する形で置いておくというアイデアだ…というのが私の認識である。
このようなスキルも MemoryBanditWorkflow に取り込みたい。どうすればいいのだろうか？
JRF2026/2/45590
Claude Code のスキルでは、Claude Code がシェルや Python コードを実行できることを前提として、コマンドやコードが示される。しかし、シェルや REPL は、ハーネスを効かせたエージェントでは、一般に使わせることなど考えられない。しかし、そうでないとすれば、ツールをすべて用意しておくしかないが、そうすると、コンテクストを「汚染」してしまう。
JRF2026/2/48348
そこでひらめいたのが、サブツールという考え方である。ツールとしては subtool_do だけがコンテクストに載っていて、どういうサブツールが使えるかは subtool_show で、まるで SKILL.md を読むように後から適宜知る必要がある…とすればいいのではないかと考えた。無限の拡張性をもたせた上での「オンデマンド学習」というわけである。
問題はそれを LLM さん(Gemini さん)が理解してくれるかどうかである。
このあたりのアイデアの軌跡は↓(このページ)にある。
JRF2026/2/47640
[cocolog:95822546](2026年1月)
《MemoryBanditWorkflow (参: [cocolog:95619779](2025年9月)) を Claude Code などの SKILL.md などを利用して実現するにはどうすればいいか。試みに Claude さん自身に聞いてみた。 - JRF のひとこと》
http://jrf.cocolog-nifty.com/statuses/2026/01/post-b86e58.html
JRF2026/2/43854
## 前回からの変更点
LangChain 1.x 系に対応した。まず、Pydantic v2 と Gemini の実装のクセらしく型エラーへの対処が難しかったが、なんとか今は動くようになっている。しかし、弥縫策で、この先はどうなるか自信がない。
ツールを格納して必要なツールのみ説明を読んで使うための subtool_do や subtool_show を導入した。subtool_show で表示されるのがおよそ他のフレームワークでは SKILL.md で書かれることに相当する。
JRF2026/2/46453
## 結論
今回はコストがかかるのを嫌ってはじめからゴールさせるつもりはなく、ワークフローを一度使ったところで実験終了させた。テストは gemini-2.5-flash-lite さんで行い、最終的には gemini-3-flash-preview さんに実行をお願いした。
flash-lite さんは、サブツールの実行はうまくいかないこともあったが、gemini-3 さんは、ちゃんと実行できたようだ。サブツールはまずまずうまくいったというのが私の評価である。
JRF2026/2/48609
……。
……。
○ 2026-02-03T17:06:25Z
「MemoryBanditWorkflow を使った RAG の試験実装 (LangChain 1.x系)」の実験を行った。先の langchain_maze_0.0.15.ipynb の MemoryBanditWorkflow でも RAG っぽいことをやらせてみた。
JRF2026/2/41200
《experimental_rag_0.0.16.ipynb - GitHub Gist》
https://gist.github.com/JRF-2018/fc26e7a2e528d7bb9c96163bbbe7688f
《experimental_rag_0_0_16.ipynb - JRF-2018/langchain_maze》
https://github.com/JRF-2018/langchain_maze/blob/master/experimental_rag_0_0_16.ipynb
JRF2026/2/42610
## 結論
gemini-2.5-flash-lite さんでテストし、最後は gemini-3-flash-preview さんにお願した。途中、こちらのミスによる無限ループがわかったところで、一度止めて修正して再実行したそのログをそのまま載せている。コストがかかるのでそうした。ご容赦いただきたい。
サブツールの実行はやはり、難しいらしく、/thesis サブツールを使っての完成は一発ではならなかった。そのサブツールを使うよう、なじったあとは、完成までこぎつけることができた。
JRF2026/2/48167
ただ、それらの影響かどうか、内容は別として、構造としては前回のほうがよかったように思う。でも、MemoryBanditWorkflow とサブツールの実証実験としてはこんなものだと思う。
JRF2026/2/48656
……。
……。
追記。
「MemoryBanditWorkflow を使った RAG の試験実装 (LangChain 1.x系)」をバージョン 0.0.16.2 に上げた。変更点は軽微なミスの修正のみ。
JRF2026/2/44147
《experimental_rag_0.0.16.2.ipynb - GitHub Gist》
https://gist.github.com/JRF-2018/f4f9565095611aea2ab1b24be6596145
《experimental_rag_0_0_16.ipynb - JRF-2018/langchain_maze》
https://github.com/JRF-2018/langchain_maze/blob/master/experimental_rag_0_0_16.ipynb
JRF2026/2/48403
0.0.16.2 の結論はこうなる。
プロンプトで /thesis サブツール群を使うように指示したせいか、スムーズに行き、最後まで一気に書き上げてくれた。ただ、取材はもう少し長くやって欲しかった印象はある。実証試験としては問題ない。
JRF2026/2/46255
Claude Sonnet 4.5 さんと会話。
JRF2026/1/240167