はじめに
この記事の目的は、チームや個人で色々と考えなくても、ローカルでagentを使用してさえいれば
プロジェクトのハーネスが自動改善される仕組みを整えるためのヒントを提供することです。
そのために、有名OSSのEverything Claude Codeを引き合いに出して、現実のプロジェクトへ取り込む方法を模索します。
スター数17万を誇る有名OSSのECC（Everything Claude Code）には、Continuous Learningの仕組みが搭載されていて、
この中でsession情報をinstinctという中間フォーマットに変換するアーキテクチャが存在します。
ざっくりいうと、instinctとは、セッション情報を解析した結果を再利用可能なrules、skills、agentsなどに変換する前の中間フォーマットのことです。
古くからデータ基盤を作ってきた人にはこのアーキテクチャ自体に馴染みがあると思います。
ユーザーの生ログがセッション情報だとする、instinctは加工したデータのことで
再利用可能な状態に持っていくことはその加工データをさらに使って本番利用可能な状態に持っていくことと類似しています。
instinct（中間フォーマット）があると何が嬉しい？
セッション情報から直接rulesやskillsに変換するパイプラインを構築している人の記事も
ちらほらあったりするのですが、いちいちinstinctに変換する構造を持つことで
一体何が嬉しいのでしょうか？
という疑問が浮かぶと思います。
なので、その部分について解説します。
セッションプライバシーを担保できる
セッション情報は、ユーザーの生ログなので、古くwebサイト運営などでやってきたように、かなりセンシティブな情報になり得ます。
チームでのハーネス運用を考えるときにはこのプライバシーの問題にぶち当たると思いますが、instinctを挟むことで、生ログの提供を回避できるので、この問題を緩和することができます。
ただ、厳密にはいくら中間フォーマットとはいえ、変換内容によってプライバシーを侵害する可能性はあるので、
そこに関しては厳密なrulesを入れたり、レビューを挟むなど、いろいろと改善の余地はあります。
現実的には、セッション解析があると恥ずかしいなど抵抗がある場合があるので、社内で
ある程度強いroleをもった人が先導していくとうまくいきやすいはずです。
また匿名性を担保しつつもチームでハーネスを育てていく
現実的なアーキテクチャの提案についてはこの記事の後半でも解説していますので、ぜひ最後までご覧ください。
再利用するかどうか判断する余地が生まれる
セッションから直接、再利用する形にもっていくと、判断のフェーズを作り込みにくいです。
セッションを跨いで解析したり、統計的な情報を判断材料にしたり、閾値を利用して、再利用レベルを調整したりするといったことです。
ですが、instinctを挟むと、ECCで行われているように、例えば、confidenceの閾値が高いものはglobalハーネスに昇格するなど、再利用のレベルをコントロールしたりといった柔軟な対応が可能になります。
これは明らかにinstinctという中間フォーマットに変換することのメリットです。
セッション解析する手法を分散できる
潜在的にセッションを解析する戦略は、たくさん考えることができるので、
どれか1つに絞ってしまうことは状況や目的によっては不利に働きます。
なので、需要に応じたセッション解析パターンを使い分けられるようにするとベターです。
ECCではActionとEvidenceという構造に固定されているので、この部分に対して筆者は物足りなさを感じています。
https://deepwiki.com/search/continuous-learning-v2_7cd2977f-2938-438b-bbf8-3cadbf47f378?mode=fast
instinctという中間フォーマットを作ることで、解析戦略を豊かにできます。
その需要ですが、たとえば
- tokenをできる限り節約したい
- 同じ失敗を繰り返したくない
- 成功パターンを繰り返したい
- セッション時間をタスクごとに最短にしたい
- 適切にskillやrulesなどを参照したい
などがよくあるものだと思います。
なので、チーム運用をする際にはまずは、目的を定めて、そこから下ろしてinstinctの設計をすると良いです。
そして、instinctへの変換戦略は、目的ごとに複数あって良いです。
たとえば、自分は
- 成功は繰り返す(成功→成功)
- 失敗は成功に変える（失敗→成功)
- 目的に対して最もセッション長を短くできたとしたらどのようなrulesやskillsがあればよかったか
という意図の変換のほかに、skills検索の自動検索最適化がしたいので、うまくキーワードを拾えていたかを解析させて、検索精度を改善するという変換も採用しています。
そのほかもチームによっては、いろいろと変換戦略は考えることができるはずです。
色々と試してみて、あったものを採用していくフローでよいと思います。
こういった試行錯誤でも、
直接ハーネスにデプロイしないので、instinct構造を入れる利点があります。
現実世界でも、生ログをどのように表現するかは結構分散しています。
例えば、zennやqiitaのように記事にしたり、stackoverflowのように質問と答えをformat化したり。
なので、生ログからinstinctへの変換も目的に応じて、多種多様な変換を考えると良いです。
適切な再利用単位を選択することができる
skills,docs,rules, commands,agents,memories,root rules(CLAUDE.md, AGENTS.mdなど)といった再利用単位があるなかで、どの再利用単位に変換するかという再利用効率をより深く柔軟に設計することができるようになります。
たとえば、自分の場合、プロジェクトによってはskillsに寄せて全プロバイダー対応するハーネス戦略をとっていたりするので、既存skillsと重複がないかなどの観点も盛り込んで、skillsに変換させることも多いです。
ECC(Everything Claude Code)で不足する部分を補う
ECC自体はマルチエージェント対応を掲げていて、instinctなど自動ハーネス改善の先駆けとして素晴らしいものなのですが、Continuous Learning v2に関してはhaikuに固定されていたりとまだClaude Code限定のアーキテクチャに偏っているので、全プロバイダーに最適化されていません。
なので、その部分を解説します。
実務だと、Claude Codeの他も混ぜることができると有利になるからです。
あえて名指しするのであれば、特にcodex、copilot、cursor, opencodeあたりです。
instinctへの変換は、作業時間と被らないようにしたい
これは、人間が夜に寝ている間に、今日あったことを整理する"睡眠"という仕組みと全く同じ考えです。（あえてくどい表現をしています、ご容赦ください)
人間=agentと考えると、
セッション=起きている時間に経験したこと
と対比ができるからです。
人間でも、体験しながら、同時に振り返りをしていると効率的ではないですよね？
同様にセッション解析は高コストなので、同一プロバイダーのチームagent運用でrate limitにかからないためには、時間帯をずらす戦略が有効です。
ちなみにECCではツール使用の回数が20回溜まったら、haikuでinstinctへの変換が走るようになっていますが、rate limitをより気にするのであれば、時間をずらしたり、他のプロバイダーのモデルを使ったりすることも合理的です。
自分はinstinct変換は、基本cursor cliのcomposer2にやらせることが多いです。
composer2は安くてそこそこうまいの代表格だからです。
(ただチームプラン運用だとhaikuやmini系のモデルなども選択肢に入ってくるのかなと思います。
また、最近だとGemma4などの強力local llmでも十分解析は可能だと思います。)
こうすることで、解析部分だけ別の脳でできるので、人間の睡眠的制約を超えられます。
さらに、同一プロバイダーではないので、rate limitを気にする必要がなく、ほぼリアルタイムで実行することも可能になります。
instinctへの変換戦略が固定されている
先ほども触れましたが、ECCでは、Action Evidence型でinstinctへの変換戦略が1つに固定されていて、これは最適化の余地があると考えています。
なぜなら、プロジェクト構成などによっては最適化されたセッション解析パターンを考えられるからです。
たとえば、それは、skills検索精度の自動改善だったりです。
機能が多すぎて、既存プロジェクトに取り入れづらい
ECCは、巨大なプロジェクトなので、参考にはなるけど、既存のプロジェクト取り入れる際にはどの要素を取り入れるのか迷うと思います。
そこでおすすめは本記事で解説している、Continuous learning
v2の
- session to instinct
- instinct to harness (/evolveコマンド)
の部分を取り入れることです。
なぜなら、この部分はECCの中でも中核をなす機能で、本記事でも解説してきたように
移植価値が高いものだからです。
これを導入することで、自動的にプロジェクトのハーネスを改善することができます。
そのまま入れるわけでなくて、複数プロバイダー最適化、プライバシー最適化などプロジェクトごとに解くべき問題はあります。
再利用プロセスをチームで強制できない
ECCでは、instinctを生成する部分はhookドリブンなので、ローカル生成において強制されますが、そのinstinctを再利用フォーマットに変換するかどうかは、command(/evolve)での任意実行になっています。
なので、個人にドライバーを渡すと、この仕組みを導入はしたけど、
- セッションプライバシー
- プライド(雑なpromptを見られたくないなど)
の観点から実際一向に再利用PRが上がってこないというバッドエンドになりかねないです。
つまり、プロジェクトにおいて個人最適化が全体最適化にブレーキをかけてしまうという
典型的な損失パターンです。
なので、現時点での自分の提案としては、
プライバシーを考慮して匿名で
認証、ip制限、ネットワーク制限などを搭載したセキュアなサーバーにinstinctを自動送信するようにして、
サーバー側では、fine grained tokenを使って、instinctから再利用のPRを自動生成するというアーキテクチャにするとうまく回ると考えています。
そしてそれを、ある程度社内政治を動かせる人が指揮して実装する。
そうすると、instinctの中身すら見ないで、チームとしてはただ上がってきたPRをレビューして承認するという匿名性の高い自動サイクルに持ち込めます。
人間がみて承認するという部分をいれていますが、どちらでもよいです。
そしてここは、プロジェクトごとにいろいろ裁量のある部分だと思います。
そもそも、匿名にしないで、うちは
- オープンにgithubアカウント名を紐付けする
- セッション情報も全部閲覧できるようにする
- instinctは全員に確認させたい
といったプライバシーをそんなに考慮しない設計もぜんぜん可能だと思います。
個人的にはあまりおすすめできないですが、可視化された結果としてライバル意識が芽生えて、動きが良くなるといった効果がある可能性は完全否定しないです。
古典的な営業マンの売り上げランキングのような方法は割と会社の文化によってはあるのかなと思います。
instinctは強化学習における経験圧縮の概念近い
このinstinct構造は、実は強化学習のアーキテクチャと比較するとかなり理解しやすいです。
強化学習では、agentが環境の中で行動し、その結果として報酬や失敗を得て、次回以降の行動方針を改善していきます。
これをClaude CodeやAI Agentのチーム運用に置き換えると、次のように対応づけられます。
| 強化学習 | AI Agent開発環境 |
|---|---|
| agent | Claude Code / Cursor / Codex / Copilotなど |
| environment | プロジェクト、コードベース、タスク、チームルール |
| trajectory / episode | 1回のセッションログ |
| reward / penalty | 成功、失敗、手戻り、レビュー指摘、token浪費 |
| experience replay | 過去セッションの再解析 |
| policy update | rules / skills / docs / agents / commandsの改善 |
| distilled experience | instinct |
つまり、sessionはagentが実際に環境で行動した生のtrajectory/episodeと割り当てられて、
instinctはそこから抽出された学習に使いやすい経験(distilled experience)の圧縮表現と対応させることができます。
ここで再確認すべき点は、やはりすべての生ログをそのまま学習に使う必要はないという点です。
生ログにはノイズ、個人情報、偶然うまくいっただけの行動、再利用価値の低い文脈が大量に含まれています。
だから、強化学習的な観点から見直してみても、直接rulesやskillsに変換するよりも、一度instinctという中間表現に落とし込んだ方が、組織として扱いやすくなります。
これは、強化学習的にはexperience replayやtrajectory filteringに近い考え方です。
すべての経験を等しく学習に使うのではなくて
- どの失敗が繰り返されているのか
- どの成功パターンが再利用可能なのか
- どの知識をrulesにすべきか
- どの知識をskillsにすべきか
- どの情報は個人依存なので共有すべきでないか
を判断してから、最終的なハーネスへ反映します。
チーム運用で考えると、これは古典的なマルチエージェント強化学習に近いです。
個々の開発者やagentが、それぞれ別々のセッションで試行錯誤して、
その結果得られた経験をinstinctとして集約し、再利用可能な知識だけをrules、skills、docs、agentsなどに変換する。
こうすると、ある人が踏んだ失敗を、別の人や別のagentが繰り返さなくて済むようになります。
また、成功にフォーカスを当てるとあるagentが見つけた成功パターンを、チーム全体の標準行動として取り込めるようになります。
この意味で、instinctは個人の経験を、
チーム全体の行動方針に昇華するための中間層
と強化学習の文脈では表現できます。
でも、ここで注意したいのは、これは厳密な意味でのモデル重みの更新ではないということです。
Claude CodeやCursorのモデルそのものをfine-tuningしているわけではありません。
実際に更新しているのは、モデルの外側にあるハーネスです。
つまり、rules、skills、docs、commands、agents、memories
といった、agentの行動を制御する外部構造を更新しているわけです。
画像生成でいうとLoRAとかの発想にも近いです。
なので、これはモデルの強化学習というより、
ハーネスの強化学習と呼ぶ方が近いかもしれません。
モデルの重みは固定したままでも、周辺のハーネスを継続的に改善すれば、agentの実効性能は上がります。
そのための経験データとしてセッション情報を使い、抽象化された学習単位としてinstinctを使います。
この構造を持つことで、チームのAI Agent運用は単なる個人運用ではなく、経験が蓄積され、再利用され、自動改善され続ける学習システムになります。
これは冒頭で指摘したように、従来のログ分析やデータ基盤の構成にも似ていますが、
より本質的には、チーム全体のagent行動を改善するための強化学習的な仕組みとして捉えることができます。
Claude Dreamsとの違い
最近ClaudeからDreamsという機能が発表されましたが、非同期に過去セッションを振り返って、メモリーを整理するという発想はまさにこの記事で解説してきたContinuous Leanringの発想と近いものがあります。
ただこの機能はセッションを解析して、既存のmemoryをより整理したmemoryに変換する仕組みなので、instinctを明示的に作って、それをrules,skills,docs,agentsに分配するというより、今のところはmemory storeの再編成・重複排除・洞察抽出に寄せたexperimentalな機能です。
なので、dreamsもあっても良いもので今後の活躍と発展が楽しみですが、セッション解析で別プロバイダーを使用したり、skillsやrules,agentsなどに柔軟に変換したりといった部分とは現時点では重複しないという理解です。
まとめ
この記事では、セッションログを直接rulesやskillsに変換するのではなく、
一度instinctという中間フォーマットに落とし込むことの有用性を整理しました。
instinctを挟むことで、セッションプライバシーを守りやすくなり、再利用するかどうかを判断する余地が生まれます。
さらに、成功パターン・失敗パターン・検索改善・token削減など、
目的に応じた複数のセッション解析戦略を持てるようになります。
ECCのContinuous Learning v2は、この構造を理解するうえで非常に参考になります。
ただし、Claude Code限定の仕組みとして見るのではなく、Codex、Cursor、Copilot、ローカルLLMなども含めた
マルチプロバイダー対応のハーネス自動改善基盤として再設計する余地があります。
特にチーム運用では、個人のセッションログをそのまま共有するのではなく、匿名性やセキュリティを考慮しながらinstinctだけを集約し、そこからrules、skills、docs、agents、commandsなどへの
再利用PRを自動生成する構成が現実的と考えています。
そして、レビュー&mergeも自動化して人間を挟まないようにしていく。
そのための中間層として、やはりinstinctはかなり有効な設計パターンだと思います。
最近、今回紹介したチームでの匿名instinct収集からの自動PRのアーキテクチャの導入など、
積極的にハーネスの導入、強化支援をやっていますので、これをうちでもぜひ取り入れたいという方がいらっしゃいましたらお気軽にお声がけください。
https://ai-advisor-lp-peach.vercel.app/ja