自分で良くなる Agent：Orkas の自己進化ループ

多くの AI アシスタントは「使って忘れる」ものです。今日ある癖を直しても、明日また同じ間違いをします。先週チーム固有の手順を教えても、今週には初めて聞くように振る舞います。会話は毎回ゼロから始まり、どれほど賢いモデルでも、記憶喪失の賢い人のようになります。

Orkas が目指すのは別の形です。agent が日々の使用から学び、繰り返し現れる経験を蒸留し、次回は自分で使えるようにすることです。平たく言えば、使うほど役に立つようになり、その「役立ち方」はモデルベンダーが全員向けに決めたものではなく、あなた、あなたの好み、あなたの領域へ向かって育ちます。

この記事では、その仕組みを分解します。単に「会話を覚えさせる」話ではありません。背後には、観察する → 反省すべきか判断する → 実際に反省する → 再利用できる形へ書き出す → 次回使う、という閉じた loop があります。

最初に一番重要な点を言います。ここで説明する観察、記録、reflection はすべてあなたのデバイス上で完結します。 実行データ、skills、agent の自己理解は普通のローカルファイルとして保存されます。Orkas のサーバーへアップロードされず、ユーザー横断の分析やモデル学習にも使われません。自己進化とは、プログラムが自分の実行記録をローカルで読み、ローカルで改善することです。

要点 自分のエージェントを書き換えるエージェント 自己進化はデスクトップアプリ上、あなたのワークスペースで動き、加えた変更はすべて確定前に確認できます。

Orkas をダウンロード — 無料

Loop 全体

実際の使用を繰り返す
      │  どの tools を呼んだか、失敗したか、修正されたかをローカル記録
      ▼
   signals が蓄積する
      │  会話からその場で抽出し、すべて on-device に保持
      ▼
  reflection すべきか判断する
      │  signals を重み付けして閾値を超えたときだけ発火。ネットワーク揺れは除外
      ▼
   バックグラウンドで reflection
      │  毎 turn ではなく、条件を満たす agent を周期的に選ぶ
      ▼
  二つのものへ蒸留する
      │  ① 再利用可能な skills   ② 自分自身への understanding
      ▼
  次の turn に自動で持ち込む
      └──────────► 最初へ戻る

この loop で間違えやすいのは、見た目には簡単そうな二点です。いつ reflection するか、そして reflection の結果として何を記録するかです。

Step 1: ほぼゼロコストで自分を観察する

経験から学ぶには、まず見るべき経験が必要です。各 agent run の終わりに、Orkas はその場で軽量な事実を数えます。この turn で tools がだいたい何回呼ばれたか、error があったか、それは network などの transient error か本当の失敗か、ユーザーがその場で修正したか。すべてローカルで計算され、モデル呼び出しも送信もありません。

これが重要なのは、モデル費用がかからないからです。もし毎 turn の自己分析に追加のモデル呼び出しが必要なら、コストと latency が膨らみ、この仕組みは日常利用に載りません。

「修正されたか」は完全な判定ではなく signal です。端末上で「不对」「应该是」「重新」や wrong、actually、instead のような表現を拾います。多少の誤検出は問題ありません。後段で他の signals と重み付けされ、単独で決定を下すわけではないからです。

Step 2: いつ reflection する価値があるか

単純な方法は「N 回たまったら reflection」ですが、それでは粗すぎます。三回の network timeout と三回のユーザー修正は同じではありません。Orkas は weighted multi-signal scoring を使います。各現象に weight を持たせ、この turn で発火した signal の合計が閾値、既定では 0.7、を超えたときだけ reflection します。

Signal	Weight	Trigger
User correction	0.9	この turn でユーザー修正を検出
Skill ineffective	0.85	skill を読んだのに失敗した
Recovered from error	0.8	失敗したが最終的に回復した
Hit a known weakness	0.7	自己評価にある弱点に当たった
Task complexity	0.5	tool-call count が一定数を超えた

ユーザー修正は 0.9 と高い重みを持ちます。明示的な「違う」は signal-to-noise が高く、記録する価値がある可能性が高いからです。一方、少し複雑だっただけの turn は 0.5 で閾値に届かず、無理に学習しません。

もっとも重要な例外

この scoring で最も大切な線引きは、transient errors を数えないことです。ネットワーク timeout、接続断、rate limit は環境の問題であって、agent の能力不足ではありません。

ここを間違えると、ひとつの偶発的な network error から「この tool は信頼できない」と学んでしまい、良い skill を壊したり削除したりする恐れがあります。自己改善システムにとって最も怖いのは、学ぶのが遅いことではなく、間違った方向へ学ぶことです。

そのため、recovered from error、skill ineffective、known weakness の signals は純粋な transient error を除外します。reflection prompt でも同じ注意を繰り返します。network 系の失敗を弱点として記録せず、関連 skill を触らないようにします。

Step 3: Reflection は表ではなく裏で走る

「反省すべき」と分かった瞬間に、その場で agent を止めて reflection すると、ユーザー体験は途切れます。Orkas は reflection を background に移し、固定 cadence で動かします。

一定時間ごとに reflection cycle を開始する。
同じ agent の reflection には cooldown を置き、過度に頻繁にしない。
長く reflection していない agent は強制的に対象にする。
一回の cycle で選ぶ agent 数を制限する。

さらに dirty gate があります。cycle の開始時に、前回 reflection から新しい signals や会話更新があるかを確認します。何も動いていなければ skip します。小さな仕組みですが、不要なモデル費用を大きく減らします。

Step 4: Reflection の中身

reflection が必要になったら、最近の活動を packet にまとめ、慎重に書いた prompt と一緒にモデルへ渡します。packet には予算があります。最近のいくつかの会話、重要な system events を時系列に並べ、token 上限を超えないようにします。全履歴を詰め込むのではありません。

prompt の肝は、出力を「説明」ではなく実行可能な命令にすることです。

✗ 「出力が長くなりがちなので注意する。」
✓ 「family-office の質問に答えるときは、箇条書きを 5 個以内にする。」

✗ 「ユーザーは簡潔な回答を好むようだ。」
✓ 「family-office 文脈では、必ず結論を先に出し、その後に理由を書く。」

「注意する」は次回読んでも行動に落ちません。「5 個以内にする」はそのまま実行できます。自己改善で残すべきものは、正しい感想ではなく、次回使える instruction です。

二つの保存先

reflection の結果は主に二つの場所へ入ります。

ひとつは skills。 各 skill は metadata つきの Markdown ファイルです。名前、説明、作成時刻、更新時刻、patch 回数、最後に使った時刻を frontmatter に持ち、その下に手順や要点を書きます。ファイルなので、人間が直接読めて編集できます。opaque な DB に閉じ込めません。

---
name: "Weekly Report Export"
description: "今週のデータを標準の週報フォーマットにまとめる"
createdAt: "2025-01-01T00:00:00Z"
updatedAt: "2025-01-08T00:00:00Z"
patchCount: 2
lastUsedAt: "2025-01-09T10:00:00Z"
---

## Steps
1. ...
2. ...

もうひとつは自分自身への understanding。 これは agent が自分に書く memo に近く、「自分は何が得意でどこでつまずくか」と「このユーザー、この domain でうまくいった play」を短く残します。次回の会話開始時に system prompt へ入るので、agent は自己理解を持って入ってきます。

Skills は書きっぱなしにしない

skill を作るだけでは、時間がたつほど散らかります。そこで lifecycle を持たせます。

作成より多い操作は patch です。既存 skill の小さな範囲だけを書き換え、patch count と update time を更新します。毎回丸ごと書き直すのではなく、経験に沿って少しずつ育てます。

数にも上限があります。一定数を超えると、LRU、つまり最近使われていないものから退避します。作成以来一度も読まれていない skill は、そもそも蒸留がうまくなかった可能性が高いので、先に消えます。agent が skill を読むたびに last used time が更新され、この値が整理の判断材料になります。

Skill が有効かどうかを測る

多くの自動学習システムは「学んだあと、それが役に立ったか」を見ません。Orkas はここを local metrics にします。これらの指標はオンマシンの進化機構のためだけに使われ、外へ出ません。

Invocation rate = invocations / impressions。提示されたのに読まれない skill は、役に立たないか、説明が悪くて使い時が分からない可能性があります。
Edit-after-hit rate = skill を使った後にユーザーが手で直した割合。高いなら、出力が好みに合っていません。
Ineffective rate = skill を使った turn が非 transient error で終わった割合。高いなら skill 自体に問題があるかもしれません。

ここでも transient errors は除外します。network の一時的な揺れで、良い skill に悪い評価をつけるべきではありません。

Loop が閉じる

agent は実際の仕事を進めながら run data と signals をローカルに残します。background reflection cycle が来ると、新しい動きがあり cooldown を過ぎた agent を選び、最近の活動を packet 化して、現在の自己理解と照らしてレビューします。統合すべきものは統合し、捨てるべきものは捨て、新しい skills や understanding へ蒸留します。次の会話では、それらが prompt index と system prompt に入ります。そしてまた新しい metrics と signals が生まれ、最初へ戻ります。

設計上の trade-offs

内省は安くなければならない。 観察は zero-model-cost の metrics で行い、高価な reflection は background で低頻度に、dirty check を通して走らせます。

間違って学ぶくらいなら学ばない。 transient-error exemption、何も保存しない選択、曖昧な説明ではなく実行可能な命令を書くことは、すべて同じ判断に基づいています。

学んだものは見えて、編集できて、手元にあるべき。 skills は plain-text files、self-understanding も plain text、効果は metrics で確認できます。すべてローカルにあります。

学習にはブレーキが必要。 数量上限、LRU、長さ制限がなければ、continuous learning は continuous bloat になります。忘れること、捨てること、刈り込むことは、覚えることと同じくらい重要です。

まとめ

Orkas の自己進化は、agent に遅い loop を足すことです。速い loop は各会話への即時応答であり、遅い loop は一定周期で振り返り、次回使える形へ経験を蒸留することです。難しいのは「モデルに覚えさせる」ことではありません。どの経験を残すか、偶発故障で学習を歪めないか、学んだものを実行可能にするか、膨らむ前に刈り込むかです。

これらの判断が合わさることで、「使うほど役に立つ」は宣伝文句ではなく、実際に回る mechanism になります。単に賢い助手よりも、あなたから学び、かつ間違ったことを学ばない助手の方が、多くの人が本当に欲しいものに近いのかもしれません。