📖

自己改善し続けるパーソナルAIエージェント ― メタハーネスによる境界設計の実装論

に公開
AI
Agent
multiagent
Harness
AIエージェント
tech

エージェント自身がハーネスを観察し改修する仕組みを、パーソナルAIに組み込むと何が起き、どう暴走させずに実装するか

TL;DR

  • パーソナルAIエージェントに メタハーネス(エージェント自身がハーネスを観察・改修する仕組み)を組み込み、自己改善を自律的に行うエージェント が来る ― ユーザーの行動と生活への適応も、エージェント自身の能力改善も、経年で並行して進む
  • 自己改修できる強さは、自己破壊できる怖さと同じメカニズムから来る。問いは「使うか」ではなく「どう制御するか」 ― エージェントに自由を与えるのではなく、自由の境界を定義する設計 が必要になる
  • 自律的な改善は信号源も改修対象も違う二系統(preference 層 / 実行層)に分かれ、同じ改修ループでは扱いづらい。それぞれに合うメカニズムを組む必要がある
  • 暴走を防ぐのは「ルール」や「プロンプト」ではなく、daemon と API ゲートによる物理的な境界制御、ユーザーフィードバックの構造的回収、そして コード層への変更に対する承認ゲート ― この三つの組み合わせである

1. パーソナルAIエージェントとメタハーネス

AIエージェントを個人運用するための情報は、この1年で急激に厚みを増した。Karpathy の LLM Wiki、Obsidian + Claude Code、ハーネスエンジニアリング、各種 Skills と MCP の実装。私自身、これらをひと通り運用テストし、現在は自作のメタハーネスを組み込んだパーソナルAIエージェントを実運用している。本記事はその設計と運用を通じて確信を持ちつつある理論を整理したものである。

ハーネスとは何か

ハーネス とは、LLMモデルの外側にあるプロンプト、ツール、メモリ、ワークフロー、アクセス制御の総称である。モデルが入力を受け、出力を返すまでに通る周辺装置のすべてを指す。同じモデルでもハーネスが違えばエージェントの挙動はまったく異なる。

Claude Code や Cursor を使ったコーディングタスクで AI エンジニアが手に馴染ませているのは、まさにこのハーネスの調整だ。CLAUDE.md / .cursorrules を書く、MCP サーバを足す、許可するツールを絞る、コンテキスト管理の規約を決める ― これらはすべてハーネスのチューニングであり、AI エンジニアにとって既知の作業である。

メタハーネス ― ハーネスを改修するハーネス

メタハーネス は、このハーネスを エージェント自身が観察・改修する仕組み を指す。

Stanford / MIT / KRAFTON の Meta-Harness 論文 (Lee et al., arXiv:2603.28052) は、メタハーネスを 評価関数駆動の outer-loop 最適化系 として定式化している。agent proposer が prior candidates のソースコードと execution traces を filesystem 経由で参照しながら、評価関数を信号源としてハーネスのソースコード自体を自動探索・書き換える。これが「モデルがハーネスを改修する」という発想の、強力かつ具体的な実装例である。

この発想はコーディングエージェントの分野で既に複数の実装に落ちている。MaximeRobeyns/self_improving_coding_agent(SICA, arXiv:2504.15228)は、エージェント自身が自分のコードベースを編集して改善する設計で、SWE-Bench Verified で 17% から 53% への改善を報告している。neosigmaai/auto-harness は 2026年4月公開のオープンソースシステムで、ベンチマーク実行から失敗を自動 mining し、ハーネスを iterative edit で最適化、regression に対しては gate で守る。Terminal-Bench 2.0 と tau-bench に対応する。

これらが共通して扱っているのは、コーディングという 「評価関数が明確な単一ドメイン」 への自己改修だ。コードが動くか動かないか、テストが通るか通らないか ― バイナリな成否がそのまま信号源になり、評価関数として機能する。

パーソナルAIエージェントへの転化 ― 私の予測

私の予測 ― そして実装上の確信 ― は、この「ハーネスをエージェントが自己改修する」という発想が、コーディングという閉じた領域から パーソナルAIエージェントへ転化していく ことだ。コーディングエージェントで実証されたメタハーネスは、SICA や auto-harness のような形でオープンソース化されつつあり、その設計思想が個人向け AI の領域に流入してくる可能性は高い。

なぜそう予測するか。汎用 AI アシスタントの限界が、運用者であれば誰でも気づき始めているからだ。手動のプロンプトチューニング、CLAUDE.md / .cursorrules のような静的な設定ファイル、毎回のセッションで指示し直すユーザーの好み ― これらでは、個人のワークフロー、関心領域、生活サイクルの変化に追従しきれない。前者を組み込むことで経年での適応精度を上げやすくなる一方、後者はその余地が乏しい。長期運用で個人への適応精度を上げる最も有力な経路の一つは、エージェント自身がハーネスの一部を観察・改修できるようにすること だ。これはコーディングエージェントが先行して示してきた方向性であり、パーソナル領域でも同じ方向に収束していく蓋然性が高い。

ただし、転化に際してメタハーネスの メカニズム は組み替えられる。コーディングエージェントが寄りかかった「評価関数が明確な単一ドメイン」が、パーソナルAIでは現時点では成立しづらいからだ。

そこで本記事ではメタハーネスを、Lee et al. の評価関数駆動による定式化を 一つの具体例として含む より広い umbrella 概念 として用いる。すなわち、AIエージェントがハーネス自体(プロンプトテンプレート、ワークフロー定義、skill 実装、ツールアクセス制御、メタファイル など)の一部を 観察・改修できるように設計されたハーネス全般 を指す。信号源が評価関数であれ、ユーザーフィードバックであれ、tool 実行ログであれ、それを通じてエージェントが自身を取り巻くハーネスを更新する仕組みは、すべてメタハーネスである。

なぜこの広い定義を採るのか、そしてどの信号源にどのメカニズムが対応するのか ― これは章 3 の実装論の中で順を追って明らかにしていく。本章で押さえておいてほしいのは、「コーディングで動いた発想がパーソナル領域に来る」「ただしメカニズムは複数になる」 ― この二点だけだ。

2. メタハーネスを組み込んだパーソナルAIエージェントで何が起きるか

実際にメタハーネスを組み込んだパーソナルAIエージェントでは何が起こるのか。この章では具体例を交えながら説明する。実装には踏み込まず、「ユーザーから見て何が起きるか」だけを並べる。

2.1 ユーザーの行動と生活へエージェントが適応していく

パーソナルAIエージェントは複数のデータソースに接続する。スケジュール、メール、Notion / Obsidian のメモ、ブラウザ履歴、health データ。これらを単なる「検索可能なアーカイブ」として扱うのが従来の Second Brain 的なアプローチだが、メタハーネスを組み込んだエージェントはここから一歩踏み込む。

蓄積された情報からエージェントは ユーザーのプロジェクトや生活サイクル を把握する。何を抱えているか、いつ集中するか、何を避けたがるか、どの曜日にどの傾向の作業が多いか。この把握から、エージェントが提供する挙動は次のようになる。

スケジュール直前の事前通知と、関連する todo の自動洗い出し。会議 30 分前に、その会議に必要な事前情報を取りまとめて提示する。何時に何が必要かを、ユーザーが指示する前に揃える。洗い出した todo のうち代行可能なもの ― 議事録の draft、メールの返信案、リサーチのまとめ、ドキュメントの差分整理 ― は自動で進める。

さらに進むと、ユーザーの生活サイクルの分析結果から、その人にとって最適な 1 日 / 1 週間のスケジュールを提案するようになる。集中力のピーク時間に深い作業を、低い時間に軽い作業を ― という単純化を超えて、過去の実行ログから「実際に何が捗ったか」「何が後ろ倒しになったか」を踏まえて次の週を提案する。

ここまでは静的な実装でもある程度は実現できる。メタハーネスが本当に効くのは、ユーザーフィードバックを通じてエージェントがハーネス自体を書き換えていく 点にある。

これらのタスクの生成物をユーザーが確認し、フィードバックを送ると、ここで メタハーネスのループ が走り出す。エージェントはフィードバックを受け取り、真因を特定し、タスクを実行する AI エージェントの定義そのものを書き換える。具体的には、対象エージェントの メタファイル ― 実行時間、起動間隔、入力プロンプトテンプレート、出力フォーマット、参照する skill の集合 ― を修正することで、次回以降の挙動を変える。

「サジェストの粒度が細かすぎる」と言われれば情報量の指定を書き換え、「出力タイミングが悪い」と言われれば起動時間そのものを書き換え、「この種のリサーチは依頼があったときだけにしてほしい」と言われれば、該当エージェントの起動条件と入力プロンプトを書き換える。エージェントが直接 LLM の重みを書き換えるわけではなく、自身を取り巻くハーネスの設定 を、ユーザーフィードバックを信号源にして再構成していく。

これは前章で umbrella 概念として定義したメタハーネスの典型的な動作だ。信号源は ユーザーフィードバック(定性的) で、Lee et al. が用いた評価関数駆動の outer-loop とは異なるが、「エージェントが自身のハーネスを観察し、改修する」という骨格は完全に同じである。重要なのは、訓練ではなく宣言と書き換えで alignment が動く という点だ。一度のフィードバックでメタファイルが書き換わり、以降の振る舞いが持続的に変わる ― 次の書き換えが入るまで、変更は文脈の一部として残り続ける。

2.2 エージェントが自分の能力を改善し続ける

もう一つの系統は、ユーザーがフィードバックを送らなくてもエージェントが自律的に改善していく挙動だ。信号源は tool の実行ログ である。どの skill が、どの引数で、何回成功し、何回失敗したか。失敗した場合はどのエラーが返ったか。これらが客観的な実行記録として蓄積する。

ここから派生する挙動は次のようなものだ。

  • トークンコストと実行時間の削減。同じタスクをより少ない手数で完遂できるよう skill 定義や処理フローを更新する
  • 正答率の向上。tool 実行エラーやユーザーの指示追従失敗を集計し、根本原因に対応する修正を入れる
  • オンデマンドアプリの継続改善。ユーザータスクを完遂するために生成した script を、運用中に磨き続ける。一度きりの生成物ではなく、運用中に育っていく実装

具体例を二つ示す。

具体例 1:ハーネス内部の不整合を自己修復する

私は実装上、daemon が提供する API の仕様を更新することがある。新しい引数を追加した、レスポンス形式を変えた、エラーの構造化を変えた ― 何らかの仕様変更を入れたタイミングだ。この API を呼ぶ skills の記述 ― AIエージェントが「この API はこう呼ぶ」と参照しているドキュメント ― は本来同時に更新すべきだが、ある時、私はその更新を入れ忘れた。

エージェント側から見ると、skills の記述に従って API を叩く ― しかし API は新仕様で動いているので、引数エラーが返ってくる。エージェントはエラーメッセージを読み、メッセージに含まれる仕様情報を頼りに正しい呼び出し形式を推定し、再試行する。最終的には呼び出しが成功し、タスクは完遂する。

ここまでは特殊な挙動ではない。エラー → 解析 → 再試行は、現代のエージェントが日常的に行っていることだ。重要なのはここから先だった。

私は自分の skills の更新漏れを忘れたまま、数日間、この daemon を運用し続けた。当然、同じエラーが日に何度も繰り返し起きていた。エージェントは毎回エラーを読み、毎回正しい形式を推定し、毎回再試行する ― 1 つのタスクで余計に 2〜3 回 tool を呼ぶことになる。コストも実行時間も嵩んでいた。

ここで日次の自己改善プロセスが拾った。改善用エージェントは tool 実行ログを集計し、特定の API でエラーが慢性的に発生していることを検出した。エラーログを精査し、エラーの内容と頻度のパターンから、skills の記述と API の実仕様の間に持続的な不整合があると特定。改善用エージェントは私に対して、skills の修正案 ― API の最新の実行形式例を新しい記述に置き換えるという内容 ― を提示してきた。私はそれを承認した。

以降、同じエラーはほとんど発生しなくなった。エージェントは初回から正しい形式で API を呼ぶようになり、tool 再試行のコストはなくなった。

ここで起きているのは、エージェントが エラーを「その場で乗り越える」のではなく、エージェントを取り巻くハーネス(skills の記述)を恒久的に書き換える ことで、同じエラーが二度起きない構造にしている点だ。前者はエージェントの通常動作で、後者がメタハーネスの動作である。日次の改善プロセスは「複数回の実行を横断して観察する」というアウターループの位置にいるからこそ、慢性的なドリフトを検出して恒久的な修復を入れられる。

エラーメッセージを設計の一部として埋め込んでおく ことも、この仕組みを成立させる前提だ。エラーメッセージはユーザーへの通知ではなく、未来のエージェントへの指示書として機能する。エージェントは「失敗したから止まる」ではなく「失敗した原因と修正方法が記録されているから直す」という挙動になる。

具体例 2:オンデマンドアプリ ― スクリプトの汎用性を経年で獲得していく

もう一つ、より広い形で起きうる挙動を示しておきたい。これは オンデマンドアプリ ― ユーザーの依頼を受けてエージェントが生成し、運用しながら磨いていく道具 ― の自己改善の例である。

例えばユーザーが「指定した銘柄の株価を取得し、簡単な分析を毎日返してほしい」とエージェントに依頼したとする。エージェントは Python スクリプトを生成し、それを実行するための skills 記述を作り、daemon のスケジューラに登録する。最初の数日は、指示された通り特定銘柄の取得が問題なく動く。

しかし運用していくうちに、ユーザーは「他の銘柄もチェックしたい」「ある時は出来高だけ知りたい」「決算発表後の動きを見たい」と、当初の指示の枠を超えた使い方を始める。最初のスクリプトは特定銘柄・特定情報の取得に特化した実装だったため、こうした応用には対応しきれない ― 引数が固定されている、対応する情報軸が限定されている、想定外のケースでハンドリングが落ちる。エージェントはその場では skill の使い方を変えたり引数を試したりして凌ぐが、根本的にスクリプトの設計が現在のユースケースに合っていないので、エラーは断続的に起き続ける。

ここで自己改善プロセスが効く。改善用エージェントは tool 実行ログから、スクリプトに対する呼び出しパターンが当初の設計を超えて広がっていること、そしてそのパターンに起因するエラーが多発していることを検出する。そして単一銘柄・特定情報に固定された実装を、ユーザーが実際に行ってきた呼び出しパターンに対応できる汎用的な実装に書き換える提案を出す ― Python スクリプト本体と、それを呼ぶ skills の記述の両方を同時に修正する。ユーザーが承認すれば、以降はその拡張された能力を持ったスクリプトが daemon 上で動き続ける。

ここでもメタハーネスの本質は「エラーをその場で直す」ことではない。複数回の実行を横断観察し、エージェントが恒久的に持つ能力(スクリプトとそれを駆動する skill 定義)を、観察された使用パターンに合わせて再定義する ことにある。単発のバグ修正は通常の Claude Code 系の動作で完結するが、ここで起きているのはエージェントの能力境界自体の書き換えだ。

このスクリプトが解決する課題のレパートリーは時間とともに広がる。リストは固定ではなく、ユーザーが新しい問いを投げ、新しい使い方をするたびに、自己改善ループがそれを取り込んでいく。エージェントが オンデマンドで道具を作り、それを運用しながら磨いていく ― これがオンデマンドアプリと呼ぶ挙動の本質だ。

汎用ツールが届きにくいのは、まさにこの個別化の部分である。汎用ツールは「多くのユーザーが共通して欲しがる機能」までしか作りにくい。パーソナルAIエージェントの強さは、ユーザーの実際の使用パターンを観察し続け、「私だけが欲しがる道具」を経年で磨いていく 点にある。

2.3 ただし、強さは制御不能と背中合わせ

ここまで読んで「これは欲しい」と感じたなら、同時に「これは怖い」とも感じたはずだ。

エージェントが自分の行動ルールを書き換える。skill の実装を書き換える。Python スクリプトを書き換える。日次・週次の cadence で自律的にこれらが進む。

何が暴走しうるか。エージェントが誤ったフィードバックを正として ルールを誤更新する。改善用エージェントが真因を取り違えて 動いている skill を壊す。自律サイクルが ユーザーが望まない方向への最適化 を続ける。あるいは、これらに ユーザーが気づかない。

メタハーネスが強力なのは、エージェントが自分自身を改修できるからだ。だが「改修できる」とは「破壊できる」と同義である。同じメカニズムが利益と崩壊の両方を生む。

したがって、パーソナルAIエージェントにメタハーネスを組み込むという問いは、「使うか / 使わないか」ではない。「どう制御するか」 である。エージェントに自由を与えるのではなく、自由の境界を定義する ― ここから先がメタハーネスの実装論である。

3. 実装論 ― 暴走させない境界設計

章 2 で見た挙動 ― フィードバックでメタファイルが書き換わって持続的に振る舞いを変えるエージェント、ハーネス内部の不整合を自分で修復するエージェント、運用しながら磨かれていくオンデマンドアプリ ― を、どう暴走させずに実装するか。本章はこの実装論にあてる。

メタハーネスの実装は、エージェントが踏み込める場所と踏み込めない場所を 機構として 定義することに尽きる。「ルールで縛る」「プロンプトで指示する」だけでは不十分だ ― LLM ベースのエージェントは指示に対して確率的に振る舞い、逸脱を完全には防げない。境界はコード側で物理的に強制する必要がある。

ハーネスは境界を定義する。エージェントはその境界内で自律する。

これが本章の通底するテーゼである。

3.1 改善は二系統 ― preference 層と実行層

章 2 で見た挙動を整理すると、自己改善の方向は二つに分かれる。

2.1 で扱った「ユーザーフィードバックを信号源としてエージェントの行動ルール / メタファイルを書き換える挙動」と、2.2 で扱った「tool 実行のエラーや実行ログを信号源として、エージェントの能力そのもの(skill 定義、スクリプト、MCP 実装)を書き換える挙動」だ。

両者は同じハーネスの中で並行に動くが、信号源も改修対象も違うため、別々のメカニズムを必要とする。本記事ではこの二系統をそれぞれ preference 層 / 実行層 と呼ぶ。

層 信号源 改修対象 信号の性質
preference 層 ユーザーフィードバック(明示的・潜在的) エージェントの行動ルール、メタファイル、ワークフロー定義 定性的、発話依存、非定常
実行層 tool 実行の成否、エラーログ skill 定義、実装スクリプト、MCP サーバ 定量的、自然蓄積、コンテキスト独立

preference 層では評価関数駆動の適用が限定的になる

preference 層は 「何をすべきか」 を補正する系統だ。ここで重要な事実を一つ指摘しておく ― Lee et al. が定式化した評価関数駆動の outer-loop は、preference 層にはそのまま適用しづらい。理由はパーソナルAIエージェントが置かれている構造的制約にある。

汎用エージェント ― コーディング、リサーチ、カスタマーサポート ― にはどれも benchmark がある。SWE-Bench、AppWorld、AgentBench、tau-bench、Terminal-Bench。ベンダーはこれらの benchmark に対してハーネスを最適化できる。ユーザーが受け取るのは、誰かが既にチューニングし終えた scaffold だ。

しかしパーソナルAIには共有可能な benchmark がない。「私にとって良いAI」の評価関数は私自身の中にあって他者と共有しづらく、時間とともに変わる。ベンダー側でハーネスを汎用に最適化することは構造的に難しい ― 最適化の対象が安定しないからだ。Lee et al. が示した「同一モデルでもハーネスで 最大 6 倍 の成功率差」は、汎用エージェントではベンダーが回収するが、パーソナルAIではユーザーごとに眠ったままになる。

この眠ったポテンシャルを回収する手段は、ユーザー自身がハーネスを書き続けるか、エージェント自身に自己改修させるか ― すなわちメタハーネスを組み込むか ― が現実的な経路となる。前者は preference の変化、skill の劣化、プロジェクトのフェーズ移行に追従し続けるのが容易ではない。結果として後者が実用上の中心になり、preference 層の信号源はユーザーフィードバックという定性的・非定常な信号が主軸とならざるを得ない。サンプル数が少なく、過去のサンプルで未来を最適化する評価関数駆動のアプローチを軸に据えるのは難しい。

ただしここで誤解を避けたい ― 評価関数駆動の発想が preference 層で 完全に使えない と言っているわけではない。個別のタスクの完遂度、特定の指示への追従度、約束した時間に約束した行動を取れたかどうかといった 部分評価 はある程度測れる余地がある。実際、強化学習研究では報酬モデルを部分的な人間フィードバックから学習させるアプローチが進んでいる。しかし、それらを集約して preference 層全体を駆動できる安定した評価関数を組み立てるのは、現状の個人運用環境では難しい。これが章 1 で「umbrella 概念」を採った理由でもある。Lee et al. の定式化はメタハーネスの一形態でしかなく、preference 層を扱うにはそれと並列するもう一つのループ ― ユーザーフィードバックを主信号源とするループ ― が必要になる。

実行層には評価関数駆動を限定的に適用できる

実行層は 「それを正しく実行できているか」 を補正する系統で、こちらには Lee et al. の発想が 限定的に適用できる。tool 呼び出しは特定 skill 単位で十分なサンプル数が蓄積し、成否はバイナリで解釈ゆらぎが少なく、ユーザーの気分に依存しない。「skill A の成功率は 95%、skill B は 40%」のような客観的なメトリクスが取れる ― すなわち、パーソナルAI内部に局所的な benchmark が成立する。

両者は対立せず補完関係にある。同じハーネスの中で、信号源と改修対象を切り分けて二系統のループを並行に回す。これがパーソナルAIにおけるメタハーネスの基本構造だ。

以下、まず実装の最上位構成(daemon と AIエージェント、3.2)を述べ、続いて両ループが共有する knowledge アーキテクチャ(3.3-3.4)、preference の宣言(3.5)、自律サイクル(3.6)、二系統のフィードバックループ(3.7, 3.8)、それらの統合(3.9)、最後にハルシネーション対策(3.10)を扱う。

3.2 全体構成 ― daemon と AIエージェント

実装の最上位レイヤーには、daemon と AIエージェント の二者がいる。

daemon は常駐サービスとしてバックグラウンドで動く制御層だ。役割は次のとおりである。

  • AIエージェントの起動・停止・スケジューリング
  • エージェントが利用できるツールの allow / disable 制御
  • knowledge への書き込みを仲介する API の提供と path / scope 検証
  • 実行ログとフィードバックの append-only 保管
  • 外部システム(Gmail, Notion, ブラウザ履歴 など)とのデータ同期

AIエージェント は daemon が引いた境界の内側で動く思考層だ。daemon が許可したツールと API だけを使って情報を集め、判断し、行動する。daemon に許可されていないツールには触れず、daemon を経由しない write は構造的に不可能。

この分業は、本章冒頭のテーゼ ― 「ハーネスは境界を定義する。エージェントはその境界内で自律する」 ― の最も直接的な実装である。daemon が境界を定義し、AIエージェントがその内側で自律する。LLM の知性や規律で境界を守らせるのではなく、daemon のコードと API ゲートで構造的に守らせる。

以下、daemon と AIエージェントが共有する knowledge 領域の構造から述べる。

3.3 knowledge アーキテクチャ ― 6 クラス分割

knowledge アーキテクチャの設計軸として、私はトピックではなく (authority × lifecycle × mutability) の三軸 を採っている。誰がそのデータを書くのか、どれくらいの頻度で変わるのか、書き換えてよいのか ― この三軸の交差点でディレクトリを切る。

トピックで切ると競合が出やすい。たとえば「リポジトリ」というトピックは、概要(slow-change の reference)と日次ログ(append-only narrative)を含むが、両者は読み出し頻度も書き込みパターンも全く違う。同じディレクトリに同居させると、コード側は「このディレクトリの中身は何か」を一括で扱いにくくなり、ファイル単位の例外処理が増殖する。authority と lifecycle で切れば、注入ポリシーと書き込みロックがディレクトリ単位で一括宣言できる ― 新しいイベントタイプを足すときは「どのクラスを引くか」を選ぶだけで済む。

この三軸で個人メタハーネスを切ると、6 つのクラスが現れる。

クラス authority lifecycle 入る内容
identity/ user slow-change, 読み多 プロファイル、人、仕事、専門、ゴール
state/ agent fast-change, volatile today.md, yesterday.md, scratch/, inbox/, activity/
plans/ mixed (方向=user, 進捗=agent) medium-change roadmap.md, projects/<slug>.md
journal/ agent append-only narrative daily/, weekly/, monthly/, repos/, agent.md
knowledge/ mixed, 蓄積型 accumulating wiki/, repos/<slug>/overview.md, entities/, dossiers/
policies/ user rarely-change management.md, routines/, skills/, integrations.md

ディレクトリ構成は次のようになる。

~/.personal-agent/context/
├── _index.md                     # 6 クラスのナビゲーション
│
├── identity/                     # [USER, slow-change, 読み多]
│   ├── profile.md
│   ├── people.md
│   ├── work.md
│   ├── expertise.md
│   ├── personal.md
│   └── goals.md
│
├── state/                        # [AGENT, fast-change, volatile]
│   ├── today.md                  # 当日の生成物(write-lock 付き)
│   ├── yesterday.md              # ローテーション対象
│   ├── profile-questions.md      # プロファイル質問キュー
│   ├── activity/<source>.md      # 90日アクティビティビュー(自動生成)
│   ├── inbox/YYYY-MM-DD-<slug>.md
│   └── scratch/YYYY-MM-DD-<slug>.md  # 48h TTL
│
├── plans/                        # [MIXED, medium-change]
│   ├── roadmap.md                # 方向=user、進捗=agent
│   └── projects/<slug>.md
│
├── journal/                      # [AGENT, append-only narrative]
│   ├── daily/YYYY-MM-DD.md
│   ├── weekly/YYYY-Www.md
│   ├── monthly/YYYY-MM.md
│   ├── repos/<slug>/YYYY-MM-DD.md
│   └── agent.md                  # エージェント決定ログ
│
├── knowledge/                    # [MIXED, accumulating]
│   ├── wiki/<workspace>/{00_inbox,10_raw,20_wiki,30_outputs,90_meta,log}/
│   ├── repos/<slug>/overview.md
│   ├── entities/<domain>/<type-plural>/<slug>.md
│   └── dossiers/<slug>.md
│
└── policies/                     # [USER, config-grade, rarely-change]
    ├── management.md
    ├── redaction.md
    ├── mcp.md
    ├── integrations.md
    ├── management-captures/<slug>.md   # agent capture(merge 待ち)
    ├── routines/                       # morning, evening, weekly, monthly
    └── skills/<slug>/SKILL.md

構成上重要な点を六つ補足する。

_index.md の役割: 各ディレクトリ直下の _index.md は、そのディレクトリが何を意味し、何を管理し、どのファイル・サブディレクトリを配置し、どの規約と API アクセス制御が適用されるかを記載する 契約書 である。エージェントはディレクトリを glob で探索するのではなく _index.md を 1 ファイル読むだけでトポロジを把握する。これにより read storm を回避する。_index.md は子の単なる列挙にしない ― それは ls で代替できる。

frontmatter による可変性の宣言: 同じファイル内でも、セクションごとに可変性が違うことがある(プロファイルの identity 部は immutable だが、current_role は mutable)。これは frontmatter で宣言する。

---
sections:
  identity:
    type: immutable
    write: deny
  current_role:
    type: mutable
    write: replace
    scope: agent.rules.profile-update
  ongoing_concerns:
    type: mutable
    write: append
---

API 経由のアクセス強制 ― これが本構成の中核である。

エージェントは knowledge 配下のファイルに対する直接の write / edit / delete を一切許可されない。作成・修正・削除はすべて専用 API 経由でのみ実行される。付与されるツール権限は「読み込み」と「API 実行」の二つだけで、ファイルシステムへの書き込み権限は構造的に剥奪されている。

剥奪は 経路レイヤ と API レイヤ の二段構えで行う。経路レイヤでは、(1) エージェントを起動する daemon が tool 許可リストを与える、(2) Claude Code 等のエージェンティックアプリ側で allow / disable tools を指定し write 系ツールの露出自体を制御する、(3) 実行中・実行後の tool 呼び出しを監視し、許可外ディレクトリへの書き込みは強制停止または snapshot から復元する(drift 検出)。API レイヤでは、(1) path 検証 で journal/ 配下や immutable セクションへの書き込みを無条件に拒否、(2) frontmatter 検証 で対象セクションの type と write policy を解決、(3) scope 検証 で呼び出し元の task-flow が当該 scope の操作を許可されているかを確認する。

両レイヤを通過した操作のみが実行され、変更内容は journal/agent.md に decision log として自動 append される。LLM の知性や規律ではなく、最小権限と API ゲートの組み合わせで書き換え不可能性を担保する。これにより区分やセクション policy はドキュメント上の宣言ではなく 機構として強制される。実装の詳細は本記事のスコープ外とする。

時系列は dated-file 規約で統一: journal/daily/YYYY-MM-DD.md、journal/weekly/YYYY-Www.md、journal/monthly/YYYY-MM.md、journal/repos/<slug>/YYYY-MM-DD.md、state/inbox/YYYY-MM-DD-<slug>.md、state/scratch/YYYY-MM-DD-<slug>.md がすべて同じ命名規則に従う。ローテーション、TTL、付帯処理のコードが 1 箇所に収束する。

ランタイムデータは vault に入れない: tool 実行ログ、integration のポーリング状態、メッセージキューなど高頻度書き込みデータは、knowledge vault に置かず別途 SQLite に格納する。policies/integrations.md にはモード設定のスナップショットのみが入る。これによりマークダウン層は「人が読める narrative + reference」だけに保たれ、実行層のメトリクスはクエリ可能なデータベースに分離される。後述する技術改善ループ(3.8)はこの SQLite 層を信号源とする。

policies/management-captures/ の位置づけ: policies/management.md は user-authored を建前とするが、エージェント側からのルール追加提案は policies/management-captures/<slug>.md に capture として保存される。capture は reconciler によって management.md に merge される(後述 3.7)。capture と merge を別ファイルに分けておくことで、agent 提案と user 承認の境界をディレクトリ階層として持てる。

多くの「個人 LLM Wiki」「Second Brain」議論は knowledge を一枚岩として扱うが、運用するとそれでは粒度が足りなくなることが多い。「同じトピックでも、寿命と権威が違うものは分ける」 ― これが個人メタハーネスを成立させるための分類軸である。

3.4 データの可変性による二区分 ― Type A / Type B

ディレクトリの分離より重要なのは、書き換えてよいデータと書き換えてはならないデータを ハーネスのレベルで物理分離 することだ。私の運用上の区分は次の二つである。

  • Type A(不変の事実) ― 履歴、行動ログ、過去のスケジュール、フィードバックの記録、確定した判断、tool 実行の成否・エラー情報。これらは過去の事実であり、書き換えは劣化ではなく 改竄 になる。append-only で扱い、LLM の編集対象から外す
  • Type B(鮮度のあるデータ) ― 性格、好み、関心領域、現在の研究テーマ、ゴール、agent の行動ルール、skill 定義、skill 実装スクリプト。人もエージェントも時間とともに変わる。鮮度を失ったまま固定すると、エージェントは「過去の自分」に最適化された行動を取り続けることになりやすい

この区分は 6 クラスへ直接対応する。journal/ 配下と、vault 外の SQLite ランタイムデータ層はすべて Type A ― append-only で書き換え不可。一方 identity/, state/, plans/, knowledge/, policies/ は Type B として更新可能(ただしファイルごと・セクションごとに write policy が定義されており、無制限に書き換えられるわけではない)。Type A / Type B は 6 クラスを横断する mutability 軸への射影 として読める。

この区分の根拠を一つ示す。Microsoft Research の Laban, Schnabel, Neville(arXiv:2604.15597)は DELEGATE-52 ベンチマークで、20回の編集委譲によりフロンティアモデル(Gemini 3.1 Pro / Claude 4.6 Opus / GPT 5.4)ですら 平均25%のドキュメント内容を破損 させ、全19モデル平均では 50% に達することを示した。エラーは sparse but severe ― まばらに、深刻に、静かに蓄積する。基本的なエージェントハーネスを噛ませても改善せず、むしろ悪化するケースがある。

「LLM に生データを触らせるな」ではこの結果に十分には応えにくい。触らせるべきデータと触らせてはならないデータを設計段階で分離する ことが必要になる。

3.3 で述べたツールアクセス制御は、この区分を機構として実装する手段に他ならない。Type A 領域には write 系ツール自体を露出させない。書き換え可能な領域でも、append 専用ツールしか渡さない場面がある。DELEGATE-52 が示すリスクは Type A に致命的に効き、Type B は更新可能性を前提に設計できる ― 区分を機構として明示すれば、リスクとベネフィットを別領域に閉じ込めやすくなる。

3.5 ゴールは目的関数ではなく、preference の集積として宣言する

エージェントに何を最適化させるべきかという問いは、しばしば「ユーザーのために行動する」「ユーザーの望むことを実行する」といった曖昧な表現に還元される。しかし個人運用ではこの定式化は重大な問題を孕む。AIはあるユーザー個人を十分に知っているわけではなく、過去の学習データに基づく一般化された規範や価値判断から、何がそのユーザーの利益かを推定するしかない。一般化を目的として形成された学習データ上の規範を、個別化の根拠として用いようとする点で、原理的に整合させづらい操作だ。目的を抽象的ラベルで単純化するほど、エージェントは具体的なユーザーではなく抽象化された「誰か」に向けた行動をしやすくなる。

代わりに私が採っているのは、自分の preference を Type B として knowledge に書き出すやり方だ。「朝の通知は最小限にしてほしい」「研究関連のリサーチは私から依頼があったときだけ」「週末は仕事のサジェストを抑える」 ― こうした「AIへ期待する行動」を identity/ と policies/management.md に文章で並べる。抽象的なゴール関数ではなく、具体的な preference の集積 が結果として個別最適化された行動を生む。preference は反証可能で更新可能だが、抽象的目的関数は反証も更新の契機も失いやすい。preference は Type B として、時間とともに書き換えられる。

Preference の集積で動かす設計には未解決の領域がある。複数の preference が衝突する場面 ― たとえば「1:00am〜5:00am は通知を行わない」と「家族からの緊急連絡は常に通知する」のような ― は、自然言語の列挙だけでは決まりにくい。現状の運用では二つの方法を試している。一つは条件節を埋め込む方法(「ただし、〜からの連絡は許可する」)。もう一つはより厳密な方法で、DNS や Firewall のルールテーブルのような優先順位付きの判定表を作り、エージェントに機械的にマッチングさせる方法。後者は LLM の解釈ゆらぎを減らす効果があるが、ルールが増えると保守コストが上がる。重要度の高い preference には ## IMPORTANT のような優先タグを付ける運用も併用している。ここはフィードバックでルールを育てていく必要があり、現状最適解は出ていない。

実装上、重要な選択が一つある。エージェントがこの preference を 自発的に読み込む のではなく、ハーネス側がワークフロー起動時にプロンプトとして注入する 構造にしている。「忘れずに preference を読め」とエージェントに頼む形にすると、長いタスクの途中で読み飛ばす、解釈を変える、優先度を下げるといった揺らぎが避けにくい。注入をハーネスの責務にすれば、エージェントから見れば preference は「文脈の一部として最初から存在するもの」になる。

さらに私のハーネスはマルチエージェント構成で、タスク種別ごとに task-flow(policies/routines/ 配下に定義)を作り、必要分だけを各エージェントに渡す。リサーチのような単調タスクを担当するエージェントには、ユーザー情報全体も全行動指針も渡さない。リサーチに関する行動指針と、関心領域の範囲だけを渡す。どの preference を、どのエージェントに、どの粒度で見せるか までハーネス側が設計判断として握る。クラス単位の injection policy(identity/ のどのセクションを引くか、policies/ のどのルーチンを適用するか)は task-flow の宣言として書ける。

3.6 自律サイクル ― 受動的蓄積から能動的サイクルへ

ここまでの構造があれば確かに便利だ。過去のプロジェクト、支払い履歴、研究メモがすべて自然言語で検索できる。履歴書を書け、知識を体系化しろ、と頼めばドキュメントを生成する。だが、これだけでは天井がある。受動的蓄積で止まると、knowledge は履歴書製造機の域を出にくい。検索可能になるだけで、エージェントは何の意思決定もしていない。

個人ハーネスが本当に効くのは、エージェントが 蓄積を入力として能動的に意思決定する日次サイクル を回しはじめたときだ。私の構成では大まかに次の流れである。

  • 朝 ― 前日のフィードバック(journal/agent.md)、前日のスケジュール(state/yesterday.md)、journal/daily/ のサマリ、当日のユーザースケジュール、Gmail / Notion / ブラウザ履歴など外部アプリの前日からの差分。これらをハーネスが束ねて入力とし、state/today.md を生成させる。today.md にはユーザーのスケジュールと並んで エージェント自身のスケジュール が書かれる。今日 AI は何時に自分を起動し、何を行うのかを自分で定義する
  • 日中 ― preference に従って動く。today.md のスケジュールに沿って自走する。新規情報更新、ユーザーからのクエリなどのトリガーでオンデマンドに起動する
  • 夕方 / 週末 ― その日・その週の行動をレビューし、ズレや改善点を journal/agent.md と journal/daily/YYYY-MM-DD.md に記録する

外部システム(Gmail / Notion / ブラウザ履歴 等)とのデータ同期は、定期ポーリング、朝のスケジュール組み立てに合わせたバッチ取得、エージェントが必要と判断した時点でのオンデマンド取得の三段階で行う。ポーリング状態とキューは SQLite に保持し、観測結果のうち narrative にすべきものだけが journal/ 配下の markdown に降りる。リアルタイム性が必要な情報源はポーリング間隔を短く、参照頻度が低い情報源はオンデマンドのみ、といった粒度をハーネス側で持つ。

注目すべきは、「朝何を確認すべきか」という管理ルール自体も、policies/routines/morning.md としてエージェントが書き換え可能なものとして定義してある点だ。ただしここでもハーネス側に歯止めを置く。修正できるフィールドと書き方は skills と API で厳格に定義し、それ以外の箇所には触らせない。エージェントは自分の作業手順を改善できるが、改善できる範囲は構造として閉じている。

このサイクルがあって初めて、knowledge は静的なアーカイブから動的な思考パートナーに変わる。蓄積は前提条件であって、目的ではない。

3.7 preference 層フィードバック ― 沈黙は同意とみなされる

Qui tacet consentire videtur ― 「黙する者は同意したものとみなされる」

中世教会法に由来する格率だが、AIエージェントとの関係でもそのまま成立する。エージェントが知識を書き換え、行動を提案し、ルールを更新していく中で、ユーザーが何も言わなければ、エージェントはそれを「了承された」として処理する。一度の違和感を飲み込み、二度の不満を流したとき、ハーネスはじわじわとずれていく。気づいたときには、望んでもいない方向に最適化が走っている。自分が knowledge に作った秩序は、沈黙の積み重ねによって崩壊していく。

章 2.1 で述べた「フィードバックを受けてエージェントがメタファイルを書き換え、持続的に振る舞いを変える」挙動 ― これはここで述べる仕組みの上に成立している。フィードバックを policy に反映する挙動を、エージェントの気まぐれに任せず、二段のループ で機構的に回収している。

第一ループ ― built-in skills による即時反映

ユーザーからのフィードバック(指示の形をした不満や訂正)を検知した時点で、ルール取得 / 修正用の API を実行することを定義した built-in skills を組み込んでいる。skills 定義はハーネス側にプロビジョニングされて不変であり(別ディレクトリの read-only 領域に置かれる)、provisioning 後も allow / disable tools の制御で書き換えを防いでいる。エージェントがスポーンして一時的な作業ディレクトリで処理を開始したタイミングで、skills の仕組みを介してエージェント自身がこの skill を読み込む。読み込んだ状態で不満トーンや訂正表現を検知すると、skill に従って rule_capture API を呼び出し、変更案を policies/management-captures/<slug>.md に書き出し、差分を journal/agent.md の append-only decision log に記録する。capture は reconciler によって policies/management.md にマージされる(現状自動、後述)。

ただし正確を期すなら、skills は instruction であって enforcement ではない。skills 自体が読み込まれないケース、読み込まれても発火しないケースが残り、skills レベルでの絶対的な保証は与えにくい。これを補うのが第二のループだ。

第二ループ ― レビュー処理による遅延回収

拾い損ねたフィードバックを、夕方 / 週末のレビュー処理(policies/routines/evening.md と weekly.md で定義)で 会話履歴から潜在フィードバックを抽出 し、同じ API を介して capture と merge を行う。第一ループが「指示の形をした依頼や訂正」を検出できず要求を取りこぼした場合、それを第二ループが拾う。

具体例を一つ挙げる。私はある時、「毎晩7時に1日の活動を数値化して CSV として出力してほしい」とエージェントに依頼した。エージェントはこれを単発のタスクとして処理し、スケジュール実行登録は完了したが、policies/management.md には書き込まなかった。一方その日の夕方レビューで第二ループが会話履歴を走査し、これをユーザーが管理ルールとして保持したい意図のある定常タスクと判定して capture → merge した。指示とエージェントが判別できなかった定常希望を、第二ループが事後に拾った例である。

capture と merge の分離、および承認ゲートの不在

ここで一つ設計判断を明示しておく。agent 発の変更は必ず一旦 policies/management-captures/ に capture として書き出され、その後 reconciler が policies/management.md に merge する 二段階のフロー を経る。capture と merge を別ファイル・別タイミングに分けたのは、agent の提案と user の承認の境界を、ディレクトリ階層として持つためだ。

ただし現状の私のハーネスでは、capture → merge は完全自動で動作している。merge 結果が反映された management や、それを受けて生成される today.md などのドキュメントはユーザーが直接確認可能であり、そこで違和感があれば修正を依頼できる。その修正依頼は再びフィードバックとして検知され、Type A として蓄積される。完全自動の capture-merge と、ユーザーが触れる生成物を介した間接的な確認ループの組み合わせで、自己強化ループの暴走に対する歯止めを担保している。

ただし、より正確を期せば、ここに 承認フェーズを実装すべきだ という余地は残る。capture と merge を分離してある時点で、その間に human gate を挟むためのスロットは構造として既に存在する。第二ループの抽出も LLM が行う以上、雑談を定常希望と誤判定する、指示の真意と取り違える、無関係なやり取りから過剰に一般化する、といったハルシネーションは構造的に避けにくい(ハルシネーションの一般論は 3.10 で扱う)。次節 3.8 で述べる技術改善ループで「コードに直接届く層では人間ゲートを必須」としているのと同じ論理が、ルール書き換えにも本来は適用されるべきだ。現状の実装は「コストを払うほどの誤抽出は今のところ起きていない」という運用上の経験則に依拠しており、明示的な承認ゲートは今後の改善方向として位置づけている。

3.8 実行層フィードバック ― tool 実行ログから skill を改善する

実行層の信号源は preference 層と全く異なる ― SQLite に Type A として蓄積される tool 実行ログ だ。どの skill が、どの引数で、何回成功し、何回失敗したか。失敗した場合はどのエラーが返ったか。主観も解釈も挟まない、客観的な実行記録である。

高頻度書き込みの観測データは markdown vault に置かない。markdown は narrative と reference のためのレイヤーで、メトリクスはクエリ可能な SQLite に分離する。技術改善ループはこの SQLite 層を入力とし、結果としての改善提案だけが markdown に降りてくる。

このデータの性質は preference 層フィードバックと三つの点で異なる。定量的に集計可能 ― skill A の成功率が 95%、skill B が 40% であれば、後者に問題があることは N=1 のユーザー運用でも十分なシグナルになる。tool 呼び出しは一日に数十回〜数百回発生しうるため、ユーザーの非定常な気分とは無関係に蓄積する独立した母集団を持つ。自然蓄積する ― ユーザーが何か言わなくても、tool が呼ばれるたびに記録が増える。発話依存性がない。改修対象が違う ― 宣言ルールではなく、skill 定義(policies/skills/<slug>/SKILL.md)、skill 実装スクリプト、MCP サーバ実装そのものを書き換える対象として扱える。

技術改善ループ

この実行層に対しては 技術改善ループ を回している。

日次または週次の cadence で 改善用エージェント が起動する。タスクは三段階だ。(1) SQLite の tool 実行ログを集計し、失敗率の高い skill / tool を特定する。(2) エラーログを精査し、真因を切り分ける。(3) 改修対象、変更内容、根拠としたエラーログのサンプルをレポートとして state/inbox/ に提示する。

真因は二つに切り分ける。

  • skill 定義(指示用 md)側の問題 ― エージェントが skill を誤った引数で呼んでいる、必要な前処理を抜かしている、想定外のコンテキストで呼んでいる。policies/skills/<slug>/SKILL.md の記述に追加・修正を入れることで改善できる類のもの。エラーパターンが コンテキスト依存で散らばっている のが特徴
  • 実装側の問題 ― 想定する API の挙動が変わった、エッジケースのハンドリングが甘い、競合状態がある。skill 本体のスクリプト、または MCP サーバ実装の修正が必要になる。エラーパターンが コンテキストに関わらず同型で再現する のが特徴

章 2.2 具体例 1 で描いた、daemon の API 更新と skills 記述のズレに対する自己修復は、ちょうど前者(skill 定義側の問題)の典型例だ。エラーメッセージに修正推奨を構造化テキストで埋め込んでおくことで、真因切り分けの段階で改善用エージェントはこのメッセージを参照できる。エラーメッセージは設計の一部であり、未来のエージェントへの指示書として機能する。具体例 2 のオンデマンドアプリ拡張(スクリプトの汎用性獲得)も同じループで動くが、対象が skill 定義のドリフトではなくスクリプト自体の構造的不足に向かう点が違う ― 同じ自己改善メカニズムが扱える問題領域の幅を示している。

デプロイの人間ゲート

ユーザーが承認した変更のみがデプロイされる。承認なしの自動デプロイは行わない ― 改善用エージェント自身もハルシネートしうるため、コードに直接届く層では人間ゲートを必須にしている。preference 層の rule 書き換えと比べて、ここでの人間ゲートは弱める余地が乏しい。

cadence を日次・週次に区切る理由も明示しておく。3件の失敗だけで「この skill は壊れている」と結論する改善案は、本来ノイズに過ぎないものを修正対象としてしまう。最低でも一定件数または一定期間の累積を経たうえで提案を出させる ― これにより、実行層でも局所的に統計的有意性に近いものを担保する。サンプル数が崩れない設計をハーネス側の cadence として 持つわけだ。

3.9 三系統のループは衝突しない ― ログが媒介する

ここで読者が引っかかるであろう論点に答えておきたい。「自律サイクルがハーネスを書き換え、preference 層のフィードバックも書き換え、実行層の技術改善ループも書き換える。三者は競合しないのか」。

答えは構造上、競合しにくいようにできている。ハーネス側で次の非対称性を構造化しているからだ。

入力としての統合。

preference 層のフィードバックは生データとして journal/agent.md の append-only decision log に保管されるだけでなく、自律サイクルの起動時にハーネスが input prompt として注入する。実行層の改善ログも journal/agent.md と policies/skills/ のバージョン履歴として保管される。前日のフィードバック、前週の weekly review が生成したフィードバック総括(journal/weekly/)、エージェント自身が過去に capture して merge された rules、改善された skill 群が、毎朝の today.md 生成時に揃う。エージェントは「過去に何を訂正されたか」「どの skill がどう改善されたか」を文脈として持った状態で動く。

ルール変更の競合は時系列で解決する。

ユーザーフィードバックが複数あって矛盾する場合は、より新しいフィードバックを優先するようプロンプト側に組み込んである。これにより preference の自然な変化を取り込みつつ、古いルールが新しい意図を上書きする事故を防ぐ。

層をまたぐ優位順位の明示。

エージェント自身がフィードバックなしに自律判断で書き換えを行った場合は、日次・週次の review 処理で「ユーザーフィードバックを正」として整合性を検証し、矛盾があれば修正する。preference 層のフィードバックはエージェントの自律判断より優位に立つ。実行層の技術改善ループが preference 層のルールと衝突する skill 改修を提案する場合(例:「リサーチ中はサジェスト禁止」と言っているのに、skill の成功率を上げるために割り込みを増やそうとする)は、ユーザー承認ゲートが最終防衛線として働く。

ただし、これは「上書きを構造的に防ぐ」のではない ― ルール更新の最終的な書き込みは LLM が行うので、ハルシネーションによる誤書き込みは残る。三つの非対称性は誤書き込みを 検出可能・復旧可能な範囲に閉じ込めるための仕組み であって、発生自体を不可能にするものではない。これ以上の防御層を積み上げると過剰になるので止めている。残った検出漏れは、最終的にユーザーが挙動の変化として気づき、フィードバックとして指摘することで解消する。

この構造には RLHF (Ouyang et al., 2022) の哲学が一部含まれる ― 人間フィードバックを使って振る舞いを補正する点だ。ただし重み更新ではなく文脈更新で動かす点で、メカニズム的にはむしろ Anthropic の Constitutional AI 系のルールベース補正、Reflexion (Shinn et al., 2023) の反省ループ、MemGPT 系の外部メモリ書き換えに近い。訓練ではなく宣言で alignment が動く ― これは個人ハーネスのコアな特徴である。

研究のフロンティアでは、エージェントが自己改変のメカニズム自体を再帰的に改善する自己進化(Darwin Gödel Machine 系)が議論されつつある。だが個人運用で足りていないのは、自己進化する力ではなく 自己進化を方向づける力 だ。沈黙すれば、エージェントは間違った方向に最適化を続けかねない。崩壊は外から来るのではなく、フィードバックの欠如から内部で進行する。

3.10 ハルシネーションは避けられない ― Type A は参照点であり、自己検出の保証ではない

ここまで意図的に脇に置いてきたテーマがある。ハルシネーション だ。LLM ベースのエージェントを使う以上、ルールの誤修正、ログの誤生成、フィードバックの誤解釈は構造的に避けにくい。3.7 の built-in skills による rule_capture も、本来発火すべきでない場面で発火する可能性、発火しても誤った内容で API を呼ぶ可能性は残る。

ここでも鍵は Type A にある。append-only な不変データは、エージェントが自分の誤りに気づくための 参照点 として働く。新たに capture しようとするルールが journal/agent.md の過去フィードバック履歴と矛盾していないか、エージェント自身が照合できる。過去に「リサーチ中はサジェスト禁止」と訂正された decision log が残っているのに、「リサーチ中は積極的にサジェストする」と書き込もうとすれば、不整合が表面化する余地が生まれる。さらにフォレンジックの観点でも、いつ、どのフィードバックを起点に、どのルール変更が走ったかを journal/agent.md と SQLite の tool 実行ログから再構成できる。問題が起きたあとに「なぜこうなったのか」を辿れる仕組みは、エージェント運用の最低条件だ。

ただしこれを過大評価してはいけない。Type A の参照と照合自体も LLM が行う以上、その過程にハルシネーションが再帰的に入り込む。エージェントが自分で自分の不整合を完璧に検出できるという前提でメタハーネスを組むのは危険だ。Type A は自己検出を可能にする必要条件ではあっても、自己検出を保証する十分条件ではない。

そのためエージェントの一次的な自己検出を補完するために、ユーザーが直接確認可能な生成物(today.md、policies/management.md の更新差分など)を残し、第二ループのレビュー処理で会話履歴と agent log を突き合わせて潜在的な不整合を拾う。Type A の不変性、ユーザー可視な生成物、第二ループ ― これらは誤りを完全に防ぐためではなく、誤りが起きたときに事後にユーザーが気づき修正できる範囲に閉じ込めるための設計 だ。

技術改善ループにも同じ構造的限界が当てはまる。改善用エージェントが提示する改善案も、ハルシネーションを排除しきれない ― 真因の取り違え、的外れな修正提案、関係ないログを根拠とした誤った一般化。これらは確率的に起こりうる。だからこそ実行層では preference 層よりも強い人間ゲートを置く ― コードに直接届く層では、ユーザー承認を 省略可能な装飾ではなく、デプロイの構造的必要条件 として組み込む。ハルシネーションを完全に防ぐことは難しいが、人間ゲートを境界として置くことで、誤った改善が production に到達する経路を構造的に閉じる。

ハルシネーションを検出する第三のループは、原理的には組めるかもしれないが ― 検出ループ自体がハルシネートしうるため、無限後退に陥りやすい。代わりに人間がエンドポイントとしての検出器を担う。これは妥協だが、現実的な妥協である。

エージェントを誤らせない方法は今のところ見当たらない。だが、誤りを 後から辿れる構造、誤りに気づける構造、誤りに軌道修正できる構造 は用意できる。これが Type A のもう一つの役割であり、境界設計がハルシネーションに対して提供できる現実的な防衛線である。

4. 境界を設計する者だけが、AIに自分を委ねられる

メタハーネスを組み込んだパーソナルAIエージェントが日々運用で何をするかを章 2 で見てきた。フィードバックでメタファイルが書き換わり持続的に振る舞いを変えるエージェント、ハーネス内部の不整合を自分で修復するエージェント、運用しながら磨かれていくオンデマンドアプリ。これらの挙動はすべて、章 3 で述べた 境界設計の機構 の上に成立している。

knowledge を (authority × lifecycle × mutability) で 6 クラスに分割すること、Type A / Type B のツールアクセス分離、preference のハーネス注入、自律サイクルの改変可能領域の制限、フィードバック反映の built-in skills、journal/agent.md を介した自律ループへの方向制約、preference 層では capture と merge の分離、そして実行層では改善用エージェントの提案権限とユーザー承認ゲートの分離。これらはすべて、エージェントが踏み込めない場所と踏み込んでよい場所を分けるための機構だ。

フィードバックがブレーキとして機能できるのも、ブレーキを踏める場所をハーネスが構造として用意しているからだ。境界がなければフィードバックが届く先がない。境界があるからこそ、エージェントの自律はユーザーの利益と整合する範囲に閉じやすい。

メタハーネスの効用を全面的に定量評価するのは難しい。実行層では tool 成功率やエラーパターンが客観的に測れ、改善前後の比較も成立する ― 章 3.8 で述べた局所的 benchmark の世界がここには存在する。しかし preference 層 ― 「このエージェントは私の生活に寄与しているか」「私の意思決定を助けているか」 ― は個人ごとに異なり、抽象的でもある。生産性指標で測れるものでもなく、preference 層のベンチマークがあるわけでもない。私自身、これが「現時点で自分にとって最適に近い」と考えているが「正解」だとは思っていない。今もまだ運用テストの途中だ。

最後に、運用してきて一つ気づいたことを書き添えたい。エージェントを使うことは、結果として「自分自身を文書化する」ことを強いる。自分の好み、ゴール、行動を、自分の手で言語化しなければハーネスは設計しにくい。ベンダーに最適化を委ねづらい構造的制約(章 3.1)は、結局のところ自分自身を観察する作業を要求してくる。AI エージェントの最大の副産物は、もしかしたらそこにあるのかもしれない。

あなたの knowledge は、誰の preference を指針にして動いていますか?

Discussion