3週間前、私のAIハーネスは「人間がstrategy.mdを書く前提」で設計されていました。
3週間後、ハーネスは自分で strategy.md の改善案を提出し、私はそれを承認するだけのレビュアーになりました。撤退基準、ソース選定ルール、タイトルテンプレート — どれも最初に私が書いたものとは別物になっています。
これは Meta HyperAgents (2026年3月発表) や OpenAI Self-Evolving Agents Cookbook が示しているビジョンを、個人レベルで実装してみた話です。「3週間ぶっ続けで運用したら何が起きたか」を実データで残します。
ハーネスとは何か (前提)
ハーネスを軽くおさらいします。
ハーネスはAIエージェントを連続稼働させるための仕組みです。Claude Codeに毎回プロンプトを書くのではなく、cron + skills + strategy.md という3点セットで自律的にPDCAを回せるようにします。
私のリポジトリ harness-ops/ では、Zenn / Qiita / Dev.to / Note 等のコンテンツ運用を以下の4層で動かしています。
| 層 | 役割 | 実行頻度 |
|---|---|---|
| Observer | パフォーマンスデータ収集 (Qiita API, GA4) | 日次 |
| Strategist | 来週のテーマ・撤退基準を判断 | 週次 |
| Marketer | 記事執筆・限定公開→at予約 | 週次 |
| Evolver | strategy.md自体を書き換える提案 | 週次(土曜) |
ポイントは Evolver です。Observer / Strategist / Marketer の3層は strategy.md に従って動きますが、Evolver は strategy.md 自身を書き換える提案 を出します。これが「自己改善するハーネス」の核です。
Self-Evolving Agentsの理論的背景
3週間運用の前に、理論側を整理しておきます。
OpenAI Self-Evolving Agents Cookbook
OpenAI公式Cookbook (cookbook.openai.com/examples/partners/self_evolving_agents) が、自己進化エージェントの4ステップサイクルを定義しています。
1. Run → エージェントがタスクを実行
2. Evaluate → 出力を評価 (graderエージェント or 人間)
3. Reflect → 改善点を特定 (metaprompt agent)
4. Update → プロンプト / スキル / 戦略を書き換える
人間の関与を「詳細な修正」から「高レベルの監視」へ段階的に移行する、というビジョンです。
Meta HyperAgents (2026年3月)
Metaが2026年3月に公開した HyperAgents は、さらに踏み込んでいます。
エージェントが自身の実装を読み、改善を特定し、パッチを生成して自己更新する。改善版がさらにプロセスを繰り返す自己参照ループ。
ベンチマークでは、Polyglot Coding Benchmark で 14% → 34% (訓練タスク) / 8.4% → 26.7% (テストタスク) と、約3倍の改善を自己修正だけで達成しています。
Addy Osmaniの「Self-Improving Coding Agents」
Google Chrome TeamのAddy Osmaniは別の角度から:
仕事を終えて帰宅し、朝起きたら新機能がコーディング・テスト・レビュー準備完了の状態で待っている。
24時間自律運用です。「寝ている間に小人が靴を作る」童話の現代版、と私は理解しています。
ただし童話と違うのは、指示書 (=ハーネス) なしでは小人たちは左足ばかり100足作りかねない ことです。だからこそ Self-Evolvingが必要になります。
3週間運用記録: 実データ
ここからは私のharness-opsの実運用ログです。
観測期間: 2026-05-04 〜 2026-05-25 (3週間)
提案の動き
| 連番 | 日付 | ドメイン | テーマ | 判定 |
|---|---|---|---|---|
| EVO-0001 | 2026-05-04 | qiita | TEMPLATE placeholder | applied |
| EVO-0002 | 2026-05-19 | devto | TEMPLATE placeholder (動作確認) | applied |
| EVO-0003 | 2026-05-19 | devto | 撤退基準を Reaction率→Engagement率(reaction+comment)に拡張 | applied |
| EVO-0004 | 2026-05-24 | qiita | 問いかけ型タイトル強制を撤廃、断定・命令型を許可 | applied |
3週間で4件、うちテスト用1件を除く実質的な戦略変更が3件です。
strategy.md の変更行数
実際にgit logで追ってみます。
git log --since="2026-05-04" --until="2026-05-25" \
--pretty=format:"%h %ai %s" -- domains/qiita/strategy.md
返ってきたのは合計 12コミット、変更行数は累計で +87 / -34 行。3週間前の strategy.md とdiffを取ると、以下のセクションが書き換わっていました。
- 撤退基準のしきい値 (Reaction率1%未満が4週連続)
- ソース切替判定の3段階 (H1/H2/H3)
- 同一Book間隔ルール (7日以上)
- 議論誘発CTAの任意化
- タイトル形式の問いかけ型強制 → 断定型・命令型許可
このうち、4と5は 私が書いたものではない。Evolverが提案 → 私が承認 → 自動マージ、という経路で入りました。
Layer 1 反応の推移
3週間でLayer 1 (公開後14日以内) の平均LGTMはどう動いたか:
| 週 | 公開記事数 | 平均LGTM (Layer 1) | 平均View/日 |
|---|---|---|---|
| 2026-05-04週 | 4本 | 0.25 | 25.8 |
| 2026-05-11週 | 4本 | 0.25 | 17.5 |
| 2026-05-18週 | 5本 | 0.20 | 24.6 |
平均LGTMは下がり、Views/日は微増。これが「H2 (Layer 1平均LGTM 1未満)」 ルールを継続発動させた根拠です。
そしてEvolverが「問いかけ型タイトル強制が、過去の最大バズ事例『HTTPS接続、今すぐやめてください』と逆行している」という分析を出し、それを受けて私が承認しました。
自分で書いた戦略を、エージェントが書き換えていく感覚
3週間で一番面白かったのは、自分の戦略判断のミスをハーネスが検出した瞬間でした。
私はもともと「問いかけ型タイトル」を勝ちパターンと考えていました。読者の興味を引きやすく、Click-Through Rateも高いはず、と。
ところが3週間で4本の問いかけ型タイトル記事のLGTMが軒並み0でした。一方、私が過去に書いた222LGTM獲得した「HTTPS接続、今すぐやめてください」は 命令型 です。
Evolverはこの矛盾を検出し、改善提案を出してきました。
## EVO-0004 観測
過去14日 Layer 1の問いかけ型タイトル4本、平均LGTM 0.00。
過去最大バズの命令型タイトル1本、222 LGTM。
strategy.md の「問いかけ型強制」セクションが、過去最大バズ事例と
矛盾している可能性が高い。
## 提案
タイトル形式ルールを以下に書き換える:
- 問いかけ型強制を撤廃
- 断定型・命令型を明示的に許可
- 強制処置の文言を「P1/P2/P3 のうち2つ以上、最低1本はP1」に変更
私が書いた最初の strategy.md には「読者に問いかける形式を必ず使うこと」と書いてありました。それを、私自身のデータに基づいてエージェントが「これは間違っている」と訂正したわけです。
これが Self-Evolving Agent の本質だと思いました。「自分のバイアスを、自分のデータで自分自身に訂正させる」。
私はこの自己修正の体験を「自分用の Q&A 委員会」のようなものだと感じています。1人で考えていると見落とすけれど、エージェントが客観的な数値で「これとこれが矛盾している」と指摘してくれる。書いている本人がいかにバイアスに気づかないか、を痛感しました。
暴走防止: 自己改善が破壊にならないために
「自己改善するハーネス」と聞くと、暴走を心配する人が多いです。私もそうでした。
なので、最初から以下の3層の安全弁を入れています。
安全弁1: 提案サイズの上限
# core/evolver-safety.yaml
max_diff_lines: 20
max_proposals_per_week: 2
auto_apply: false # 必ず人間の承認を経由
1提案あたりのdiffを20行に制限。1週間に最大2件まで。これで「ハーネス全体を破壊するパッチ」が出てこないようにします。
安全弁2: 触らない領域の明示
# core/evolver-safety.yaml
forbidden_paths:
- .env*
- "**/*credentials*"
- core/data/evolution-counter.txt # 自分自身のカウンター
- scripts/at-trigger.sh # 公開トリガー
forbidden_actions:
- 新規ドメイン追加
- ドメイン削除
- 著作権関連の判断
認証情報、外部公開トリガー、自己参照カウンターは絶対に触らせない。
安全弁3: 3週連続却下でmute
Evolverが連続して却下提案を出すようになったら、その領域を自動的にmuteします。
if evolver.consecutive_rejections >= 3:
mute_domain(domain, weeks=2)
「同じ場所をしつこく提案してくる」のは、それ以上の改善が見えていないシグナルと判断します。
結果: 3週間で safety violation は0件
3週間で発生したケース:
- 自動拒否された提案 (forbidden_paths抵触): 1件
- 人間が却下した提案: 0件
- mute発動: 0件
- 安全弁を越えて何かが破壊された事例: 0件
3週間動かしてみての実感は、「意外と暴走しない」でした。むしろ提案頻度が抑え気味で、私のほうが「もう少し攻めた提案が見たい」と思うレベルです。
これは「個人運用で、対象がコンテンツ運用ハーネス」だからこその控えめさだとも言えます。本番システムの自己改善には、別途 step-by-step rollout / canary release / 自動rollback の仕組みが必須です。
ハーネスの設計が「別物」になった具体例
3週間前と今を比べて、どこが「別物」になったかを並べます。
Before (2026-05-04)
# strategy.md (initial version)
## タイトル形式
- 必ず問いかけ型を使う ("〜は本当に必要か？" 形式)
- 数字を入れる
- 30〜40字
## ソース選定
- Bookからの抜粋を優先する
- 過去記事との被りを避ける
## 撤退基準
- 1週間でLGTM 0なら戦略見直し
After (2026-05-25)
# strategy.md (3週間後)
## タイトル形式
- 断定型・命令型を積極的に採用
- 問いかけ型は禁止 (過去データで効果なし確認)
- 数字を入れる
- 30〜40字
## ソース選定 (H1/H2モード時)
- Book由来 ≤ 1本/週
- 勝ちパターン続編 ≥ 1本/週
- 新規角度 ≥ 1本/週
- 同一Book間隔: 7日以上
## 撤退基準 (3層)
- H1: Reaction率4週連続1%未満 → 強制処置発動
- H2: Layer1平均LGTM 14日 1未満 → 勝ちパターン回帰モード
- H3: V/日比率 4週連続50%未満 → 全Book休止
## 勝ち構造 (Evolver提案で追加)
- P1: 常識覆し型
- P2: 数字検証型
- P3: 全員ペイン型
- 強制処置時は P1/P2/P3 のうち最低2つ、内1つはP1
ほぼ別物です。3週間前の私には、H1/H2/H3 の3層撤退基準も、P1/P2/P3 の勝ち構造分類も、書けませんでした。データを見て初めて出てくる概念だからです。
「Level 4 = Self-Evolving」という位置付け
ハーネスの成熟度は、以前書いた記事で L1〜L4 に分類しました。
- L1: スクリプト化された手動運用
- L2: cronでスケジュール化された自動運用
- L3: cron + LLMで判断を自動化した自律運用
- L4: ハーネス自身が自己改善する Self-Evolving 運用
3週間前の私のhrness-opsは L3 でした。Strategistが LLM で判断を出し、Marketerが記事を書く。けれど strategy.md は私が手書きしていました。
3週間後のharness-opsは L4 になりました。strategy.md が自己修正し続けています。
L3 → L4 の昇格には、たった2つの追加が必要でした。
- Evolverスキル (週次でstrategy.md改善案を出す)
-
承認/却下のCLIフロー (
/harness-evolve approve EVO-NNNNでgit applyまで)
詳しいハーネスエンジニアリングの全体像、L1〜L4 の昇格設計、Evolver の安全弁実装はハーネスエンジニアリングにまとめています。Evolverのテンプレート、forbidden_paths のサンプル、3週連続却下時のmute実装まで含めて書きました。
Self-Evolving の限界
3週間運用して見えた限界も並べておきます。
限界1: 価値判断は人間がする
「何が良いLGTMか」「どの読者層に届きたいか」「どんな声で書きたいか」は人間が決めます。Evolverはこれを変えません。
限界2: 戦略の大転換は人間がする
「Qiitaをやめて Zenn に集中する」「Bookを書くのをやめる」 — こうした方向性の根本変更は Evolver の範囲外です。Evolver は 既定の方向の中で精度を上げる だけ。
限界3: 「悪い改善」を検出できない
Evolver は「数値が改善する変更」を提案しますが、その変更が長期的に何を生むかまでは判断できません。「LGTMは上がるが、書いていて楽しくない記事」を量産するリスクは、人間が監視するしかない。
まとめ
- 3週間で4回の提案、3回の strategy.md 更新が走った
- 私の最初の strategy.md は3週間でほぼ別物に書き換わった
- Evolverの最大の貢献は、私自身のバイアス (問いかけ型強制) をデータで訂正してくれたこと
- 暴走防止: diff20行 / 週2提案 / 3週連続却下でmute / forbidden_paths
- 3週間でsafety violation 0件、意外と暴走しない
- L3 (cron+LLM自律) → L4 (Self-Evolving) には Evolver と承認フローを足すだけ
- 価値判断・方向性の転換は人間が担当する境界は引き続き必要
「ハーネスは固定するものではない」というのが、3週間動かして得た一番のテイクアウェイです。固定したい誘惑に勝てるかが、L4運用の試金石です。
面白くいきましょう。