【第3部】知性の経験を残し、検証する
Memory、Observability、Git、Policyで多層Harnessを捉える
はじめに
第1部で二体のHermesによる討議を作り、第2部でMCPを通じてRikAI2を接続しました。
必要になったのは、次回の判断に使うMemory、今回の判断過程を確かめるObservability、成果物の変更を追うGit、何を許すかを決めるPolicyです。
Memoryは次回の判断材料。Traceは今回の判断過程の証拠。Gitは成果物の変更履歴。Policyは許可と停止の基準。
1. Obsidian Vaultは実験的なMemory基盤
現在はObsidian Vaultを長期Memoryの保存先として試しています。Markdownをローカルファイルとして扱え、人間とAgentの双方が読みやすく、Gitへつなげやすい点を評価しました。
ただし、長期的に最良の選択と結論づけたわけではありません。検索性能、アクセス制御、同時更新、メタデータ管理、評価、失効などは、別の基盤が適する可能性があります。
人間とAgentが同じMarkdownを読み書きできるかを確かめるための、実験的なMemory基盤です。
Memoryへ残す候補は、最終結論、採用理由、反論、却下理由、未解決事項、再利用可能な手順、成功・失敗パターンです。
以下は、AIとの会話や、基本的な構築に関する情報をObsidian Vaultに導入し、それを可視化させたものです。登録した情報をGraph化させ、コンテキスト間の関連性を見えるようにしています。
図.ObservabilityVaultの可視化図
2. Memory昇格条件
二体のAgentが同意しても正しいとは限りません。根拠、Tool結果との対応、反論、未確認事項、適用環境、人間確認を経て長期Memoryへ残します。
この条件を Memory昇格条件 としました。現時点ですべてが自動化されているわけではありません。
記憶量ではなく、再利用してよい根拠を持つこと。
3. 見えているUIの奥に、複数のHarnessがある
ユーザーが操作するのは一つのUIです。しかし、その奥で一つのLLMだけが直接応答しているとは限りません。
MCPを使えば、さらにTool Harnessと外部サービスが加わります。
ユーザーが感じる総遅延は、モデルのReasoningだけではありません。
総応答時間
= UI・通信
+ 入力検査
+ Session準備
+ Dispatch
+ 各LLMのReasoning
+ Tool待機
+ 応答回収
+ Moderator統合
+ Policy評価
+ Trace・Memory処理
+ UI返却
観測対象はLLMだけではない。入力から最終表示までをつなぐHarnessの連鎖全体です。
4. Langfuseで層ごとの時間と判断を追う
Langfuseでは、一連の処理をTrace、内部のLLM呼び出しやTool呼び出しをObservationとして階層化できます。
理想的には、次のように分けて観測します。
単一のLatency値だけでは、モデル、Tool、Session起動、応答回収、Policyのどこがネックか分かりません。改善方法も異なります。
5. Traceは届いた。しかしOutputが空白だった
実際のLangfuse連携では、TraceとSpanは届いたものの、Outputが空白でした。
HermesNativeExecutorはメッセージ注入後に制御を戻し、実際の応答は後からstate.dbへ書き込まれます。Spanを閉じた時点では、まだ応答が存在していませんでした。
そこで基準メッセージIDを保持し、後続のassistant応答を待ってからSpanを閉じる遅延取得を導入しました。
メッセージ注入
↓
Hermesが別Sessionで処理
↓
state.dbへ応答
↓
Omnigentが回収
↓
Outputを載せてSpanを閉じる
この経験は、多層Harnessでは「LLMが回答を作った時刻」と「Harnessが回答を回収した時刻」と「UIへ表示した時刻」が一致しないことを示しました。
Observabilityは監視製品を置くだけでは成立しない。被観測側の非同期構造まで理解して計装する必要があります。
OutputがみえるようにしてほしいとAgent相談すると、Agentがひたすら試しては、調整をつづけ、半日ぐらい考えた結果、アウトプットが追えるような設定になりました。それが以下の図です。以下はOmnigentでの会話を、第2部の結果をLangfuseで追ったものになります。
図. Langfuse上の管理画面
6. ローカルではTokenよりPolicyが重くなる
ローカルLLMでは、Tokenは主にメモリ、Context、Reasoning時間、応答性の指標です。一方、より重要になるのは、入力、出力、Tool、外部送信、保存の許可です。
ただしPolicyも多層化します。
同じ検査を重ねれば安全性が高まる可能性がありますが、遅延と責任の曖昧さも増えます。誰が利用者権限、外部送信、Tool許可、出力検査を担うかを決める必要があります。
Harnessが多いほど安全になるとは限らない。責任境界が見えないHarnessは、遅延と複雑さを増やします。
7. Memory、Trace、Gitを混ぜない
Obsidian Vault
└─ 次回へ再利用するため、選んで残す
Langfuse
└─ 今回を説明するため、実行事実を残す
GitHub
└─ コードや設定の変更履歴を残す
Agentによる変更案は、作業Branchへ保存し、Diffとテスト結果を提示し、人間の承認後に反映する形が理想です。自動化の実装範囲は公開前に確認します。
8. RSI(再帰的自己改善)ではなく、人間を含む反復改善
現在の構成は、Agentが自身の目標やコードを書き換え、能力を再帰的に高め続けるRSIではありません。
今後定義すべきものは、Role、Stop、Memory、Judge、Metrics、Policyです。
Agentを増やす前に、討議・記憶・評価・Policyのルールを決める。
結び：AIと会話する段階から、一緒に環境を作る段階へ
AI × Harnessとは、単にHarnessやLLMを増やすことではありません。
どの層が何を制御し、どこで時間を使い、どこで判断を止めたのかを、人間が説明できるようにすることです。
議論が増えるほど賢くなるのではなく、検証可能な経験が増えるほど強くなる。
今回の検証で最も印象に残ったのは、AIとの会話が、画面の中だけで終わらなくなったことでした。
「このモデルを使いたい」「二体のAgentを議論させたい」「RikAI2をToolとしてつなぎたい」と相談すると、AIが構成やコードを提案し、人間が確認して実行することで、実際にPCの設定やサービス構成が変わっていきました。
生成AIができた数年前の、質問に答えてくれるチャットAIとは少し違う。いや、ものすごく違う段階へ進んでいるという実感があります。
そして、それをクラウド上の話だけでなく、DGX Sparkを中心とした手元のオンプレミス環境で、ここまで試せたことも大きな発見でした。
必要に応じてクラウド上のモデルやサービスと連携することも考えられます。ただし企業で利用する場合には、社内データを外部へ送信してよいか、どのモデルやToolへ何を渡してよいかという判断が欠かせません。
そのため、何を任せ、どこで人間が確認し、何を止めるのかを、Policyとセキュリティの両面から設計する必要があります。
今回の環境は、まだ完成形ではありません。
それでも、AIが何を見て、どう考え、何を変えたのかを人間が確かめながら、AIと一緒に、AIが働く環境を組み上げていく可能性を実感できました。
この三部作が、AI AgentやHarnessを考える際の参考になれば幸いです。
最後まで読んでいただき、ありがとうございました。