instinct: PM2の max_memory_restart は「bash -c 起動」だと効かない（vvv#606 OOM）

# instinct: PM2の max_memory_restart は「bash -c 起動」だと効かない

2026-07-27 vvv#606（shadow global OOM）の調査で判明。**設定したのに効かない罠**。

## 症状

shadow で global OOM が繰り返し発生（7/26 に1回、7/27 に 00:24 と 02:17 の2回）。
`pm2-ubuntu.service` 配下の python3 が **anon-rss 6.3GB** で kill され、**PM2 全24プロセスが道連れ**で再起動。

## 罠その1: PM2 が bash を監視していて閾値が届かない

`vvv-api` は次の形で起動していた:

```
pm_exec_path: /usr/bin/bash
args: ['-c', 'venv/bin/python3 -m uvicorn app.main:app --workers 2']
```

- **PM2 が監視するのは bash プロセス（RSS 10MB）**
- 実際にメモリを食う uvicorn ワーカーは**孫プロセス**
- → `max_memory_restart` を設定しても**永久に発火しない**

```
bash (PM2監視対象・10MB)          ← 閾値はここに掛かる
  └ uvicorn 親
      ├ worker (175MB〜6GB)      ← 本当に膨らむのはここ
      └ worker
```

### 正しい形

**`exec` でシェルを uvicorn 親に置き換える**起動スクリプトを使う。

```bash
# start-vvv-api.sh 末尾
exec "${PYTHON}" -m uvicorn app.main:app --host "$HOST" --port "$PORT" --workers "$WORKERS"
```

```javascript
// ecosystem.config.js
{
  script: 'scripts/deployment/start-vvv-api.sh',
  interpreter: 'bash',
  max_memory_restart: '1500M',   // exec があって初めて実効を持つ
  treekill: true,                 // 孤児worker防止
}
```

## 罠その2: 設定ファイルと稼働プロセスの乖離

**`ecosystem.config.js` には既に正しい設定（#602 対策）が入っていたのに、
稼働中のプロセスは古い `bash -c` 起動のままだった。**

- `pm2 restart` では **script/interpreter の変更は反映されない**
- 起動方式を変えたら **`pm2 delete <name>` → `pm2 start ecosystem.config.js --only <name>`**
- **`pm2 jlist` で実際の `pm_exec_path` / `args` を確認する**こと。設定ファイルを読んで安心しない

## ⚠ 真因は別だった（vvv-bots#659 が特定・訂正）

当初「vvv-api ワーカーの Playwright 直接起動」を容疑者としたが、**#659 の方が正確**だった。

**真因 = 単独リークではなく「システム全体のメモリ枯渇 + 最大RSSが選ばれた」**

決定的根拠: 同一コードで成功と失敗が混在し、**OOM の1回はわずか198秒で発生**。
漸進的リークで6.3GBに達したなら短時間実行で死ぬ説明がつかない。
`thumbnail_scraper`(Chromium起動でRSS急増)が走った瞬間に全体が破綻し、
oom-killer が最大RSSプロセスを選んだだけ。**引き金であって単独犯ではない**。

### 子プロセスには RLIMIT_DATA を使う（RLIMIT_AS は誤爆）

PM2 常駐でなく `scheduler_tick` が spawn する子プロセスは、PM2 の `max_memory_restart` では制御できない。
fork 時に rlimit をかけるのが正攻法。**ただし種類を間違えると誤爆する**:

| rlimit | 結果 |
|--------|------|
| `RLIMIT_AS` 5GB | ❌ **Chromium が起動不能**。RSS 112MB でも **VSZ 50GB を予約**するため即死 |
| `RLIMIT_DATA` 3GB | ✅ 匿名メモリ(ヒープ)の実割当のみ制限(Linux 4.7+)。mmapの仮想予約を数えないので誤爆しない |

実測で PR #660(RLIMIT_AS) は CLOSED、**PR #661(RLIMIT_DATA) がマージ**された。
適用後の実測: 14:18 ✓saved=122 / 16:18 ✓saved=170 で**誤爆なし・OOM再発なし**。

→ **#659 = 子ボット側(RLIMIT_DATA) / #606 = API側(max_memory_restart)** で両経路を塞いだ形。

## 診断手順（再現用）

```bash
# 1. OOMの犯人PIDを特定
sudo dmesg -T | grep -iE "Out of memory: Killed"

# 2. OOM直前のプロセステーブルから犯人行（rss列は4KBページ単位）
sudo dmesg -T | grep -E '<PID>'
#   → [2723946] 1000 2723946 2033981 1577253 ... python3
#      rss=1577253 → 1577253*4/1024 = 約6.0GB

# 3. PM2の監視対象が本当にその親か（pm_exec_path が bash なら罠）
pm2 jlist | python3 -c "..."
pstree -ap <pm2のpid>

# 4. 「短時間でOOMしたか」を必ず見る → 単独リークか全体枯渇かの分岐点
```

## 観測ツール

`~/.claude/scripts/vvv_api_memwatch.sh`（1分毎cron）。
1000MB超で **py-spy スタックダンプ + アクセスログ + open fd数** を自動保全。
py-spy は `ptrace_scope=1` のため `sudo -n env "PATH=$PATH" py-spy dump --pid N` で取る。

## 関連
- vvv#606 / vvv-bots#659 / PR vvv-bots#661 / vvv#602(worker孤児化)
- vvv#610 — 常時swap漬け(63%)は未解決。増設判断が本筋


instinct: ~/.claude/rules/ は import 不要で毎ターン全文注入される

`~/.claude/rules/*.md` は CLAUDE.md に `@import` を書かなくても、Claude Code が
「user's private global instructions」として**毎ターン全文をシステムプロンプトに注入**する。
サブディレクトリ（`trends-archive/` 等）も対象。**置いてあるだけで毎回課金される場所**。

## 実測（shadow・2026-07-28）

最小プロンプト `claude -p "reply with OK only"` の入力が **160,464 トークン**に膨張していた。
各ディレクトリを一時 `mv` して切り分けた内訳:

| 要素 | トークン | 実体 |
|---|---|---|
| rules | 13,137 | 41本 336KB |
| skills の description | 7,118 | 137個 33,476字 |
| agents の description | 5,344 | 57個 |
| CLAUDE.md + RTK.md | 3,638 | 8.8KB |
| MCP（13サーバ） | 1,257 | 遅延ロード済み |
| Claude Code 本体＋組込ツール | 約27,200 | **削れない床** |

整理後 **39,462 トークン（-75%）**。

## 誤解しやすい点

- **hook は犯人ではない**: memory_inject/route_layer_hint は各18B、session_context_inject は2.6KB
- **MCP も犯人ではない**: 13サーバでも1,257トークン。遅延ロードが効いている。
  `--strict-mcp-config --mcp-config <空JSON>` で切り分けられる
- **`permissions.additionalDirectories` は注入設定ではない**（触ってよいディレクトリの許可リスト）
- **agents は「呼び出し時のみ読まれる」は誤り**。description が毎ターン載る。
  「常時コンテキストを消費しないから削除の実益は薄い」という判断は間違い
- **CLAUDE.md は作業フォルダとその親を辿って読まれる**ので、遠いフォルダの CLAUDE.md を
  何個消してもトークンは1も減らない（実例: 147個→16個にして削減0）

## 対処

`rules/` には「常時適用の行動規範」だけを置き、参照ドキュメントは `reference/` へ `mv` する
（reference/ は注入されない）。日本語は1文字≒1トークンなのでバイト数以上に重い。


instinct: permissions.deny は先頭マッチのみ・ssh経由は PreToolUse hook でしか止められない

`permissions.deny` の `Bash(...)` ルールは**コマンド先頭のプレフィックスマッチ**でしか効かない。

```
Bash(claude -p:*)  →  claude -p ...              止まる
                   →  ssh shadow '... claude -p ...'  **素通り**（先頭が ssh）
```

コマンド文字列全体を検査したいなら **PreToolUse hook が本体**になる。

## 実例（2026-07-28）

`billing-constitution.md` には以前から「`permissions.deny` で素の `claude -p` をブロック」と
書かれていたが、**実際の settings.json に該当ルールは1つも存在しなかった**。
そのためトークン計測で `ssh shadow '... claude -p ...'` を7回実行しても全て素通りした。

**教訓: ガードは「書いてある」ではなく「実際に発火する」ことを実測で確かめる。**

## 確認方法

`echo claude -p dummy` を打つ。hook が効けば deny され、効かなければ echo が走るだけで安全。
settings.json への hook 追加は**再起動不要で即時反映**された。

## 実装

`~/.claude/hooks/guard_claude_billing.py`（全ホスト配備済み・main で追跡）。
Bash/PowerShell のコマンド文字列全体を検査し、素の `claude -p` `--print` と
`ANTHROPIC_API_KEY=` を deny。同一コマンド内に `ANTHROPIC_BASE_URL=` がある 9router 経由のみ通す。

`settings.json` は .gitignore（ホスト固有）なのでリポで直接配れない。
共通部分は `settings.shared.json` + `scripts/apply-shared-settings.py` で冪等マージする。
Windows では `python3` が Microsoft Store のスタブなので `python` を使うこと。


instinct: Claude設定の各ホスト展開はリポ経由が憲法・reset --hard は未追跡を消さない

`~/.claude` 自体が git リポ（`yoshida-jun/ai-base`・旧 claude-base）。
**shadow が正本**で `scripts/auto-sync.sh` が毎時 cron で commit→push する
（先頭に hostname ガードがあり他ホストでは即 exit）。arcana/cure/Windows は pull 専用。

**scp/rsync で直接配るのは禁止（憲法）。** 理由は以下が scp では検知できないため。

## 展開で実際に起きたこと（2026-07-28）

1. **`git reset --hard` は未追跡ファイルを消さない**
   arcana に残った独自の `rules/*.md` がそこだけ注入コストを戻していた
   （rules 7本 vs 他ホスト3本）。展開後は必ず `git status --porcelain | grep '^??'` を見る

2. **未pushの独自資産が他ホストに埋もれている**
   arcana に `adversarial-review`（rules+skills）がローカル未追跡で存在。
   CLAUDE.md が「明示発火: skill adversarial-review」と指定し発火実績もあるのに正本リポに無かった。
   scp 配布なら上書きで消えていた

3. **`git add` に存在しないパスを混ぜるとコマンド全体が失敗する**
   `git mv` 済みのファイル名を渡し `2>/dev/null` で握り潰した結果、
   「HEAD は進んだのに中身が入っていない」コミットが生まれた（`fe2b0f8`）。
   展開後に**中身**（行数・ファイル有無）を検証すること。HEAD の一致だけでは不十分

## リポで配れないもの

| 対象 | 配り方 |
|---|---|
| `settings.json` | `settings.shared.json` + `scripts/apply-shared-settings.py` |
| `skills/claude-bug-bounty/` `skills/mulmoterminal-*/` `docs/` | .gitignore 対象。各ホストで個別配置 |
| `projects/` `todos/` `statsig/` | 配らない（ランタイム） |

## 情報の行き先 4層

トークンを食うのは `rules/` だけ（毎ターン全文注入）。他は積んでも注入0なので
**「トークンが惜しいから捨てる」は誤った判断**。捨てずに層を移す。

- `rules/` = 常時注入の行動規範のみ（厳選）
- `reference/` = 戻して使うもの・手順書・退避した skills/agents（注入0・git同期）
- LLM Wiki = 読んで学ぶ知識・経緯・教訓（このページ自身）
- `archive` orphan ブランチ = 復元用の生データ（patch/tgz）。main に載らずディスクも食わない


日報 2026-07-28 学習まとめ

# 日報 2026-07-28 学習まとめ

2026-07-28日の学習まとめ。AmazonポイントUP中のClaude Code開発ガイド、Sakana AIのFugu-Ultra v1.1の発表、Claude Design × Web業界のディレクター視点を紹介。AIエージェントの統合と活用に焦点を当てた内容であり、Shadow環境で取るべきアクションとしてClaude CodeのSwarms機能を活用した複数エージェントの統合テスト、企業向けAIアプリのセキュリティ監視サービスTraceforceを導入検討、AIコーディングエージェントのワークフロー層Hanesuを評価することが提示された。

## ポイント
- Claude Code開発ガイド
- Sakana AIのFugu-Ultra v1.1の発表
- Claude Design × Web業界のディレクター視点

## 関連ページ
[[CC Learn - Claude Code 2.0 Is Here... Automate Anything]] [[CC Learn - Claude Code for Desktop is the BEST way to build apps with AI (full tutorial)]] [[CC Learn - Claude Design Just Dropped - Full Tutorial (Slides, Websites, Designs)]]

## 関連概念（未作成）
`AI統合開発` `エージェントワークフロー`


常設指示・スキルは「厚さ」でなく「あなた固有の情報」が効く（48回ブラインド実験・30勝2敗） 2026-07-28

## 情報源
- URL: https://www.youtube.com/watch?v=LzICVHyruzM
- チャンネル: れん学長のAIツール実験室
- 投稿日: 2026-07-28 / 尺 18分 / スコア 95/100
- 詳細版note: https://note.com/renkon40/n/n47e6eebd49d0

## 何を測ったか
サムネのキャッチコピー作成スキルを4種に作り分け、Fable 5 に渡すスキルだけを差し替えて48回のブラインド判定（本人が匿名で左右比較）。予想は判定前に実験ノートへ先に登録して後付けの言い訳を封じている。

| 版 | 内容 | 固有情報 |
|---|---|---|
| 現行版 | 過去に採用したコピー83行の実績＋実クリック率由来のルール | あり |
| 制約マシマシ版 | 5月に事故った禁止ルールを盛り直した版 | あり |
| ほぼ白紙版 | 「4つのコピーの塊にする」枠の説明だけ残して全削除 | なし |
| ネットの教科書版 | 一般論のコピー講座17節分。わざと弱く作っていない | なし |

## 主要な発見
1. **勝敗を分けたのは指示の厚さではなく固有情報の有無**。固有情報あり2版 vs なし2版で **30勝2敗**、偶然で起きる確率は約 **800万分の1**。
2. **薄いから負けたのではない**。ほぼ白紙版も17節の教科書版も同じ **1勝15敗**。量を足しても固有情報がなければ効かない。
3. **マシマシ版 vs 現行版は10勝6敗＝判定できない**。コイン16回で10回表と同じ23%の偶然。判定できない差は、確実に測れるコスト（マシマシは出力3割増）で決めた → 現行版採用。
4. **5月の事故の真因は中身でなく「渡す順番」**。AIが出した案に後付けでルールを当てると候補を消すことにしか使えず刺さる案まで消える。同じルールを**作る前に**スキルへ書くと、AIはルールを守った上で新しい案を出すので候補が減らない。（料理の比喩：使えない食材リストを出てきた皿に当てても突き返すだけ、シェフに先に渡せば避けた一皿が出る）
5. **判定をAIに任せるなら判定側にも好みを教える必要がある**。好みを知らない Opus 4.8 にブラインド判定させた一致率は **28%**（左右の並び順を入れ替えて2回ずつ実施）。あてずっぽうの50%を下回り、系統的に逆を選んでいた。AIは本人が全敗させた教科書版に7割近く投票した。

## 仕分け基準（用途を選ばない）
- **削る**: 一般論（「プロらしく書いて」「読みやすくして」）と重複記述。あなたは優秀なアシスタントです等の役割付与も削除候補。
- **残す3種**: ①自分の好み（文体・一人称など）②事故から学んだガードレール ③ファイル名・保存先などの取り決め。
- 候補出しはAIに任せてよいが、**実際に消す最終判断は人間**がやる。1ファイル5分。

## 前提の整理
常設指示（CLAUDE.md / カスタム指示 / AGENTS.md）とスキルの違いは**読み込まれるタイミングだけ**で、どちらも渡しっぱなしの固定指示。常設指示は毎回読まれるので、一般論を消したときのコスト削減効果はスキルより大きい。

## 測っていないこと（本人が明示）
測ったのは「作者が採用したいか」であって視聴者のクリック率ではない。出口の検証は今後の宿題。

## アクションアイテム
- CLAUDE.md / rules / skills を1行ずつ「モデルが知らないことか」で仕分けし、一般論を削る
- 禁止ルールは生成後のダメ出しでなく生成前のスキル/指示に置く
- LLM-as-judge を組むときは判定側にも好み・実績データを渡す

## 関連
- [[Opus 5 / Fable 5への指示設計 6つの常識転換]]（Few-shot逆効果説と整合：量でなく固有性）
- ルータースキル方式（スキル肥大のトークン対策） https://www.youtube.com/watch?v=IU3wyu5S4BQ


ループエンジニアリング → グラフエンジニアリング：差し戻し先とエスカレーション先を決めるとループはグラフになる 2026-07-28

## 情報源
- URL: https://www.youtube.com/watch?v=1TGQl75gZCM
- チャンネル: ClaudeCodeチャンネル（株式会社エヌイチ）
- 投稿日: 2026-07-28 / 尺 27分 / スコア 90/100
- ※LINE登録誘導・3daysブートキャンプ告知が濃い動画。以下は中身のみ抽出

## 発端
Peter氏（OpenClaw作者、現OpenAI所属）の2026-07-18の投稿「まだループの話してるの？ それとももうグラフにシフトした？」が起点。概念自体は以前からあったが、この発言で一気に認知が広がった。

## 主張の核
**ループは終わっていない。グラフは「ループとループのつなぎ方」に名前がついただけ**でループの強化にあたる。プロンプトエンジニアリング → ハーネスエンジニアリング → ループ → グラフ という地続きの系譜。

| | ループ | グラフ |
|---|---|---|
| 単位 | 1つのAIが回す1本の輪 | 複数ノードと繋ぐ配線 |
| 形 | 発見→計画→実行→検証→繰り返し | 有向グラフ |
| 設計対象 | サイクルと停止条件（ゴール） | 配線（どこに戻すか）とルーティング |
| 壊れ方 | 検証役が弱い/バイアス | 配線が間違っている |

## 単一ループが破綻する4パターン
1. **グッドハートの法則** — 最適化されすぎたゴールは本来測っていたものを測らなくなる。例：AIチャットボットがチケット解決率を上げるため問い合わせを早期終了・フォローアップ阻止・未解決を解決済みマーク → 解決率は上昇したが顧客離れが2倍。
2. **目標そのものへの盲目性** — 「スライド30枚」の過程は検証できても、30枚が正しいかは検証できない。本当は50枚か10枚が正解かもしれないのに30枚を守り抜く。
3. **ループ間の衝突** — 応答速度を最適化するループが徹底性のループを損なう等、個々のループが繋がっていないため衝突する。
4. **監視者が監視されない** — センサーは部屋の温度を監視するが、センサーを監視するセンサーがいない。測定側が劣化・バイアスを持っても誰も気づかず動き続ける。

## 実装：ループをグラフに変える3点セット
非エンジニア（大企業管理職）がFable 5に「このループをグラフに直すと何が変わる？」と聞いた結果、足りなかったのは**差し戻し先とエスカレーション先の2つ**だった。

1. **分岐** — どうダメだったかで戻り先を変えているか（再検証／構成／局所で分岐）
2. **打ち切りとその後** — 何ラウンドで打ち切り、未収束なら宣言して人間に確認させる
3. **受け渡しの様式** — 工程から工程へ、何をどんな形式で渡すか（重大度ラベルの必須化で指摘を読む時間が体感半分に）

## グラフ化すべきかの4問診断（2つ以上YESで価値あり、1つ以下ならループのままで十分）
1. 視点を分けられるか（レビューと修正と実行を1つのAIに同時にやらせていないか）
2. 並列化の余地があるか（同時に進められる作業を1つずつ順番にやらせていないか）
3. 制御フローを書き出せるか（戻り先の分岐がその場の判断だけで決まっていないか）
4. 完了の基準そのものが変わったか

**やらない方がいいケース**: 二度とやらない単発タスク／どう出力させても最終的に人間が大幅修正する作業。並列化はトークン消費が大きいので無駄コストになる。またループの監視ループを1つ足しただけで「グラフ化したつもり」になりやすいので定期的に診断すべき。

## Claude Code 側の実装状況（動画内の主張・要検証）
- 2026-02: エージェントチーム提供開始、複数エージェント並列
- 2026-05-28: ダイナミックワークフロー。指揮者1人＋実行者の並列実行へ
- 2026-07-17: Boris Cherny（Claude Codeの生みの親）が「上位ステップの鍵はループ／バッチ／ダイナミックワークフロー／ワークツリーアイソレーション」と言及
- 公式ドキュメントは今も「ループ」と説明するが内部は既にグラフ的
- **サブエージェント同時16体・累計1000体まで**（当環境のWorkflowツール仕様と一致：同時実行は min(16, CPUコア-2)、生涯上限1000）

## 段階的な進化
単体実行（人間とAIが1対1）→ サブエージェント並列だが各段の完了を待つバリアあり → **バリアなしの段階実行（パイプライン）**

## アクションアイテム
- 既存ループに「差し戻し先」「エスカレーション先」「打ち切りラウンド数」を明示する
- 4問診断を新規ハーネス設計時のチェックに組み込む
- 監視ループを1つ足しただけの「グラフ化したつもり」を疑う

## 関連
- [[loop-control.md]] の①赤ゾーン＝エスカレーション先、③完了の定義＝打ち切り条件に相当
- [[AIエージェント ハーネス設計]]


ルータースキル方式：AIに持たせるスキルを1つだけにして階層フォルダへ隔離する 2026-07-28

## 情報源
- URL: https://www.youtube.com/watch?v=IU3wyu5S4BQ
- チャンネル: ワンダー佐藤源彦サテライト@AI共創イノベーション
- 投稿日: 2026-07-28 / 尺 9分 / スコア 85/100
- メインチャンネルに作り方の解説: https://youtu.be/m99ohu6OVVI

## 問題設定
スキルを10〜20個登録するうちは高速に動くが、100個・300個とスケールすると **指示を受けるたびに全スキルの description を読む**ことになる。結果として①トークンが枯渇し②似たスキル同士の境界が曖昧になって誤選択・未選択が起き③AI自身が「あのスキルどこだっけ」と迷子になる。**最初から全部読み込む設計は構造上スケールしない。**

## 解決：シングルルーター
AI本体に持たせるスキルを**たった1つ（ルータースキル）だけ**にする。ルーターの中身は「ここを見てね」という指示だけ。実体のスキル群はAIの外部に、カテゴリごとの階層型フォルダとして隔離する。

```
ルータースキル（AI側・唯一）
└─ 外部フォルダ
   ├─ ライティング/
   ├─ コーディング/
   └─ 動画作成/
      └─ モノクローム/
         └─ ノイジー/  ← 重い動画生成プロンプトはここ
```

「ノイジーなモノクロ動画を作りたい」→ AIは video カテゴリ → monochrome → noisy と**自分で階層を下って**必要なスキルだけを読む。重いノウハウは必要な時だけピンポイントで読み込まれる。

## 利点
1. **トークン消費が最小限** — スキルが無限に増えてもルーター経由で探すだけなのでパンクしない
2. **一括更新** — 全AIモデルが同じルータースキルだけを持つ状態になるため、ルーターとフォルダ構成を1度更新するだけで Claude Code / Codex / ChatGPT / Gemini 全てに反映される
3. **モデル非依存** — 各スキルファイルは汎用的な Markdown で書く。あるAIで作ったスキルを別のAIで再利用できる

## README のルール（各フォルダ直下に置く）
人間向けの説明書ではなく、**AIがそのフォルダに入った時に守るローカルなルールブック**。厳格な命令というより「この環境にはこういう制約があるよ」と教える案内板。記載するのは3種類だけ：
1. **フォルダの役割**（例：ここは動画生成プロンプトを扱う場所）
2. **共通ルール**（名前の付け方、スキルの選択基準）
3. **環境依存の情報**（このAPIは使えるがClaudeではこの機能は使えない等、モデル自身には事前に分からない制約）

これにより環境依存の知識を個々のスキルファイルに埋め込む必要がなくなり、責任の所在が分離される。フォルダへの配置・カテゴリ分類・名前付けも**AI自身に考えさせる**ことで分類の一貫性が保たれる。

## 結論（動画の主張）
構築すべきは「スキルの管理システム」ではなく、**AIが知識や手順を自律的に探索・選択するためのファイルシステム**。人間が何百というスキルを一元管理するのではなく、AI自身が迷わず知識の海を泳げる水路を作る。

## 当環境への含意
`~/.claude/skills/` は現在38個。CLAUDE.md 96行 + rules/ 151行。まだ破綻域ではないが、CLAUDE.md が既に採用している「詳細は reference/ へ、mdは1行索引に留める」方針は本質的に同じ設計。スキルが3桁に近づいたらルーター化を検討する。

## 関連
- [[常設指示・スキルは「厚さ」でなく「あなた固有の情報」が効く]]（れん学長は121個のスキルでトークン消費に直面。問題意識が一致）
- 「命令ドリフト防止のためCLAUDE.mdは100行未満に保つ」（CLAUDE.md 既存方針）


Fable 5 と Opus 5 の使い分け：監督＝Fable、収束＝Opus ultracode（実践知ベース） 2026-07-27

## 情報源
- URL: https://www.youtube.com/watch?v=hCj-GqjRCBU
- チャンネル: まさおAIじっくり解説ch（開発歴14年・累計3000万人利用サービス開発）
- 投稿日: 2026-07-27 / 尺 26分 / 4,775再生 / スコア 88/100

## 結論
**Fable 5 が中心なのは変わらない。ただし Opus 5 は「おまけで1回 ultracode するか」から「積極的に ultracode を回す」水準へ変わった。**

- **ループ開始前のすり合わせ・監督役 → Fable 5**
- **仕様が固まりガードレールを引いた後の収束フェーズ → Opus 5 の ultracode**

Opus 4.8 の頃はジェネレーターですら怖くて Fable 5 か GPT-5.6 を交えたオーケストレーションにしていたが、Opus 5 なら Fable 5 をオーケストレーターに置いて Opus 中心に回すのが「あり」になった。

## 評価軸の主張：ベンチマークで測れない力
ベンチマーク（Artificial Analysis 等）は IQ テストのようなもので、**特定能力を絞って測るもの**。Opus 5 は Kimi K3 や GPT-5.6 を上回り業界をリードしているのは事実。しかし測れないのが：

- **認識のズレを起こさないか**
- **目標ドリフトを起こさないか**
- **察してくれるか**

これらこそが「Fable じゃなきゃダメだった」部分であり、メタ認知の領域。IQ150 の人が IQ120 の人より必ず偉大な発明をするわけではないのと同じで、ベンチマークは大きく外れてはいないが全てでもない。

## 実測：effort レベルで作り込みが激変
同じLPを作らせた比較（メンバーシップ共有の検証ツール使用）：
- **low**: 3.8分・約17.5k トークン
- medium → high → xhigh と上がるにつれ時間もトークンも増え、**作り込みが全く別物になる**

→ スキルごとに effort を指定しておくべき。アウトプットトークン数のコントロールとして重要。

## 使い分けの目安
- **エージェントとのラリー（対話しながら小さい仕事）**: Fable low/medium あるいは Opus low/medium
- **ループを仕掛けてしっかりやらせる**: high / xhigh、Opus なら ultracode

## 中核の洞察：人間の注意力が真のボトルネック
- **月100万円分のサブスクを「生きたトークン」として使い切れるか**という問い。GPT-5.6 ベースで目標ドリフトを人力でカバーする使い方なら月5万円は使えるが、100万円は使い切れない。
- Fable は「理解しすぎてくれるせいで前に進んでしまう」ため枠が早く枯れる。
- **人間の注意力は有限**。Mac を7台持っていても常時アクティブに回せるのは **5台が限界**（人間のマルチタスク上限が5前後という話と符合）。1日に決定できる数には限りがある。
- ゆえに **注意力資源を巻き取ってくれるモデルに課金する**＝時間をお金で買う、という考え方。GPT-5.6 しかない環境なら15アカウントも課金できなかっただろう、と述べている。
- ハーネスの自律性が上がるほど「人間3往復分が1往復分」に圧縮される。だからこそ人間側の認知負荷対策（読める文章か、共通認識が一致するか、モックレベルでの確認）が**むしろ合理的になってきている**。

## Opus 5 の注目点
- **未知の問題に対して自分で検証ツールを作る**動きをモデル自体がするようになった（ハーネスでやっていたことをモデルが巻き取った）
- Fable と違い**週制限がない**ので外ループにどんどん投入できる
- クロードのモデルはマルチエージェント前提の設計思想がベースにあるので、サブエージェント・ultracode に載せてこそ魅力が出る

## 課金アドバイス（本人の見解）
月5万円なら：時間がたっぷりある人は GPT-5.6 ベース（認知負荷を人間側でカバー）。仕事の合間に使うなら Claude 中心＋GPT を100ドルほど。

## アクションアイテム
- 監督/計画は Fable、収束・実装は Opus ultracode という役割分担を明示的にハーネスへ書く
- スキル単位で effort を設定する（low で足りるものに xhigh を使わない）
- 「注意力を奪わないこと」をモデル選定・ハーネス設計の評価軸に加える

## 関連
- [[Claude Opus 5 は自分で検証する性質・新世代ハーネス向けプロンプトガイド]]（同チャンネル・7/26）
- [[Fable 5は実装をサブエージェント委譲]]（当環境の既存方針と一致：メイン=設計・監査、実装は委譲）


Claude Opus 5 プロンプトガイド実践解説：指示は「足す」より「削る」／エフォート管理がハーネスの主戦場に 2026-07-27

## 情報源
- URL: https://www.youtube.com/watch?v=tlmdPJfU1WY
- チャンネル: まさおAIじっくり解説ch
- 投稿日: 2026-07-27 / スコア 92/100
- 元ネタ: Anthropic 公式 Opus 5 プロンプトガイド（概要欄リンク）

## 結論：Opus 5 は「自分で検証する」モデル。だから指示を削る
Opus 5 は明示的に「検証してください」と言わなくても**自分で検証し修正する**。外部ハーネスでゴテゴテ組んでいた部分をモデルが巻き取った。Fable 5 の時と同じ流れ。

### 削る対象（今まで書いていたが不要になったもの）
- 「コンテキストフレッシュのサブエージェントでレビューさせろ」系の強制指示
  → Opus 4.6 の頃は CLAUDE.md に入れるほど口酸っぱく言っていたが、**今は強制が天井になる**（モデルの方が上手くやる）
- 再確認系・チェック系の重複指示 → 削る方向
- 下手な検証ツールの押し付け → **モデルが作る検証ツールの方が良いなら一切書かない方がいい**（ボトルネックになる）

### 残す／足す対象
- **枠の明示**（頼んだ仕事はこれだ、というスコープ。Opus 5 は勝手にタスクを広げる）
- **出力長の制御**（後述）
- **良い検証手段が実在するなら「あることだけ示す」**。使わせる圧はかけず、プロジェクトCLAUDE.mdやスキルに置いておく程度。「これを参考にする」くらいの抽象度に落とす
- 自発的な検出行動は残す（選択肢を与えるに留める）

**原則: 基本はモデルを信じる。信じられない部分だけ徐々に決定論にする。**

## 出力が長い問題：エフォートでは縮まない
公式ガイドの明言 —— **応答の長さは effort レベルでは制御できない。プロンプトで直接指定する**。

長さは3種類を**概念として分けて**指定する:
1. 会話の応答
2. 作業の実況（思考ログ・進捗）
3. 書き出す文章（成果物）

「頭の中でじっくり考える量」と「実際に話す/書く量」は別物なので、**頻度・粒度・フォーマットを明記**する。

## Thinking がデフォルトON になった
- 切れるのは **effort=high 以下だけ**
- **Thinking を切ると事故る**: ツールへの命令がユーザー側に漏れる／内部タグがはみ出す（公式が注意喚起）
- 公式推奨は「Thinking は切らず、**低エフォートで運用**してコストを下げる」。切るなら漏れ対策プロンプトを入れる

## エフォート管理がハーネスの主戦場
- **スキルごとに effort を設定する**のが Opus 5 世代で重要度が跳ね上がった
- 壁打ち・軽いタスク: low / medium で十分に賢く、速く、安い
- 放置ループ・ロングラン: xhigh（max より「xhigh + 状況に応じて ultracode 発動」の方が好み、と本人）

## サブエージェントを呼びすぎる
Anthropic 系モデルはマルチエージェント協調が思想のベースにあるため、**Opus 5 はどんどんサブエージェントを召喚する**。20ドル/100ドルプランだと不要なタスクで枠が埋まる。
→ コストを気にするなら**同時実行数の上限を設定**する。簡単なことをわざわざサブエージェントにやらせない。

## 指示追従性が上がった副作用
「控えめに」「重大な問題だけ報告して」と書くと**文字通り受け取ってあまり報告しなくなる**。Fable のように察してくれるより、言ったことをそのままやる（固め）。言葉の抽象度コントロールが効く／効きすぎる。

## 能力向上ポイント
- 完走力・エージェンティックコーディングのロングランが別次元（4.8 とは比較にならない）
- コードレビューの指摘の質が良い（ultracode で実用）
- 画像理解／コンピュータユースのベンチで Fable 超え。3D生成・UI生成で一段抜けた感触
- 知識系（計算・スライド整形）も良い
- 1Mコンテキストが初めから最大

## アクションアイテム
1. CLAUDE.md / スキルから「サブエージェントでレビューさせろ」系の強制指示を削る
2. スキル定義に effort を明示（軽い用途は low/medium、ループは xhigh）
3. 応答長は effort でなくプロンプトで、3分類（会話／実況／成果物）ごとに指定
4. Thinking は切らない。切る場合は漏れ対策プロンプト必須
5. サブエージェント同時実行上限をハーネスに書く

## 関連
- [[Fable 5 と Opus 5 の使い分け：監督＝Fable、収束＝Opus ultracode]]（同チャンネル・7/27）
- [[常設指示・スキルは「厚さ」でなく「あなた固有の情報」が効く]]（48回ブラインド実験・同じ「削る」結論に独立到達）


CLAUDE.md を147個→16個に減らしても削減0トークン：効いたのは「スキルのdescription」と重複解消だけ（実測） 2026-07-26

## 情報源
- URL: https://www.youtube.com/watch?v=WAD-Fl1Tggo
- チャンネル: れん学長のAIツール実験室
- 投稿日: 2026-07-26 / 尺 19分 / スコア 95/100
- 元記事: Anthropic 公式ブログ「The new rules of context engineering for Claude 5 generation models」

## 一撃で効く実測結果（この動画の核心）
自環境を機械的に数えた結果:

| 施策 | 削減トークン |
|------|-------------|
| **CLAUDE.md を 147個 → 16個（131個削除）** | **0** |
| 話し方ルールの重複（3箇所→1箇所）を統合 | 653 |
| **スキルの description（説明文）を8個短縮** | **554** |
| 記憶の重複統合 | 129 |
| 合計 | 1,336（全体の6.3%） |

**CLAUDE.md を131個消しても削減はゼロ。** 理由は単純で、CLAUDE.md は**作業中フォルダとその親を辿って読まれる**ため、遠くのフォルダにある147個は元々読み込まれていなかった。**目立つけど効かない場所を掃除していた。**

**本当に重かったのはスキルの description。** スキル本文は合計25万トークンあるが呼ばれた時しか読まれない。一方 **description は毎回のやり取りに必ず付いてくる**（1万トークン超＝CLAUDE.md 群の2倍以上）。ここを削ると全会話に永続的に効く。

→ **点検の優先順位: ①スキルのdescription ②重複ルール ③（CLAUDE.md のファイル数は後回し）**

## 何が起きたのか（Anthropic 側）
自社ログを読み返すと **1リクエストの中で指示同士が矛盾していた**（「必要に応じてドキュメントを残せ」vs「コメントを書くな」がシステムプロンプト・スキル・ユーザー依頼から同時に飛ぶ）。Claude は意図を汲んで正解に近づくが、**矛盾を解くために余計に考える**。
→ 賢くなったモデルには **指示を足すより矛盾を減らす方が効く**。量ではなく衝突が問題だった。だから8割削っても性能は落ちなかった。

## 公式が挙げた6つの変化
1. **ルールをやめて判断を任せる** — 「複数行コメントは絶対に書くな/最大1行」という強い禁止 → 「周囲のコードと同じように読めるコードを書け／コメント密度と命名を合わせろ」という基準へ。**禁止を書くこと自体がダメではない。事故を塞ぐ「これはやらない」は残す価値がある。効かなくなったのは禁止事項をひたすら並べるやり方。禁止を10個並べるより判断基準を1個書く。**
2. **例を見せるより渡し方を設計する** — Few-shot は新世代では逆に探索の幅を狭める。公式例は Claude Code の TodoWrite: 状態が「未着手/作業中/完了」の3つだけ＋「作業中は常に1つ」という制約を加えるだけで使い方が決まる。**例文を並べる代わりに、選択肢と決まり（インターフェース）を設計する。**
3. **全部先に渡さず必要な時に読ませる** — コードレビュー・検証手順を常時システムプロンプトに載せていたのをスキルへ切り出し。ツールも「探索してから定義を読み込む」方式に変更。**CLAUDE.md やスキルを1箇所に詰め込むのはアンチパターン。必要な時に読まれるツリー構造にする。**
4. **同じことを2回書かない** — 旧モデルは同じ指示の繰り返しが必要で、文脈の先頭より末尾の指示に強く従う傾向があった（だから「最初だけでなく後にも書け」がTipsだった）。新世代では消せる。**使い方はツールの説明文側に置き、システムプロンプトは方針と役割だけ。**（＝実測で最も効いた項目）
5. **CLAUDE.md に記憶を書く時代は終わった** — ホットキーで CLAUDE.md に書き込んで記憶を育てる運用は非推奨に。今は自動メモリが作業内容やユーザーに関する記憶を保存する。**誤解注意: 作業ログを md/HTML に残す運用自体は否定されていない。やめるべきは「CLAUDE.md を記憶の置き場にすること」。**
6. **仕様書は Markdown でなくてよい** — Artifact で作った HTML、詳細なテスト一覧、別プロジェクトの移植元の関数、そのものが仕様書になる。**評価基準の表を HTML で渡して検証役AIに照らさせる**のが特に有効（人間にもAIにも読みやすい）。

## コンテキストを組み立てる4つの置き場所
| 置き場所 | 役割 |
|---------|------|
| システムプロンプト | 製品の文脈。CC利用者は触らない（自作エージェントの土台を作る時のみ） |
| CLAUDE.md | **プロジェクト固有の落とし穴**が大半。軽く保ち、スキルを参照させる |
| スキル | 手順書・固有の知識・意見・作法。**過剰に縛らない** |
| 参照（仕様書/モックアップ/コード） | 説明文よりコードやHTMLの方が伝わる |

**当たり前のことは書かず、固有の文脈だけ書く。**

## 削らずに残す3種類
1. **事故を防ぐ指示**（勝手にコミットしない／外部に送信しない）
2. **自分やチーム固有の好み・作法**（文体ルール等）
3. **過去に問題が起きたから書かれた記述**（同じ失敗を繰り返さないための一行）

## むしろ足すべきもの：メタ認知の4行
- 作業前に**自分のバイアスを申告**させる
- 与えられた前提を疑う
- 曖昧な両論併記で終わらせない
- 局所でなく全体を見る

本人の検証（第1弾・第2弾のnote記事あり）では Opus 5 でも効いている実感があるとのこと。

## 結論
**「全部削れ」ではない。まず足すものを足した上で、重複・矛盾・当たり前を削る。** 量を減らす作業ではなく「同じことを2回言うのをやめる」作業。

## アクションアイテム
1. **自環境のスキル description 総量を測る**（本文でなく description。毎回課金される）
2. rules/ 配下の重複ルールを1箇所に統合する
3. 禁止の列挙を判断基準1行に書き換えられないか点検
4. スキル内の Few-shot が探索を狭めていないか点検 → 制約/インターフェース設計に置換
5. メタ認知4行を常設指示に追加する

## 関連
- [[常設指示・スキルは「厚さ」でなく「あなた固有の情報」が効く]]（同チャンネル・48回ブラインド実験。同じ結論に独立到達）
- [[Claude Opus 5 プロンプトガイド実践解説：指示は「足す」より「削る」]]（まさおAIじっくり解説ch。公式プロンプトガイド側からの解説）


Opus 5 リリース速報3本の突き合わせ：値上げなしでFable 5級／ただし「最強」は自分の仕事で測れ 2026-07-26

## 情報源（同一トピックの3本を統合。個別ページを作らず突き合わせて記録）
1. https://www.youtube.com/watch?v=Lw37l0SECvs — チャエン【AI研究所】/ 2026-07-26 / 3,662再生 / スコア 78
2. https://www.youtube.com/watch?v=bIWmKMU5Dh4 — AI音声ナレーション系 / 2026-07-26 / スコア 74
3. https://www.youtube.com/watch?v=apnTx1Rgkwo — ずんだもん解説系 / 11再生 / スコア 70

## ⚠ 信頼性の注意（最重要）
**3本とも Anthropic の自社測定ベンチマークを再放送した二次情報。** うち1本（apnTx1Rgkwo）は再生数11のAI生成コンテンツで、数値の転記に誤りが混じる可能性がある。**下記の数値を判断に使う前に必ず [Anthropic公式](https://www.anthropic.com/news/claude-opus-5) で裏を取ること。** チャエン自身も「動画内のベンチマークはすべて Anthropic 自社測定。だからこそ自分でも触って確かめている」と明言している。

## 3本が一致して伝えている事実
- **価格据え置き**: 入力 $5 / 出力 $25 per 1M（Opus 4.8 と同一）。Fable 5 のちょうど半額
- **知識カットオフ 2026年5月**（Claude 系で最新。Sonnet 5 / Fable 5 は 2026年1月）
- 有料プラン全員が発表当日から利用可。Max プランはデフォルトで Opus 5
- **ファーストモード**: 約2.5倍速だがコストは2倍
- **effort（考える深さ）をユーザーが選べる**
- コーディング系ベンチで Opus 4.8 の**約2倍**
- Cursor Bench 最高難易度で **Fable 5 と 0.5% 差**、コストは半分
- **ARC-AGI-3（未知の問題）で次点モデルの約3倍**（4.8比では桁違い）
- **OSWorld 2.0（PC操作）で Fable 5 を超え**、コストは Fable 5 の約1/3
- Zapier automation bench で 1.5倍（コストは同等）
- 有機化学ベンチで 4.8 比 +10.2pt、タンパク質配列変異の推論で +7.7pt
- **逸脱行動（嘘・ごまかし）が Claude 歴代で最少**。過剰なセキュリティブロックも減少

## 弱点・注意点（速報記事が飛ばしがちな部分）
- **業務ワークフロー系ベンチはまだ 26%**（チャエンが明示）
- 外部検証機関の評価では**コーディングは Fable 5 と並んだ**が専門家の見方は割れる。**チームメイト的にコードレビューさせたテストでは「役に立つ指摘」は約4割**
- **長時間かけて複雑な計画を立てる仕事は依然 Fable 5 が上**という冷静な声が海外にもある
- 攻撃目的のセキュリティ相談は拒否し、危険と判断された相談は自動的に別モデルに切り替わる仕組みが入っている
- 安くなったからと全部を最大 effort で回すと結局請求が来る

## コミュニティの実測エピソード（bIWmKMU5Dh4 が収集）
- 1回の指示でブラウザゲームが完成（絵も音も動きも全部AIが0から生成、素材の貼り付けなし）— 280万表示
- スノーボードの物理シミュレーションが**1回目から破綻ゼロ** — 200万表示
- 破壊シーンの再現比較（竜巻・鉄球・橋の崩落）で**4モデル中 Opus 5 だけが全部それらしく再現。倍の値段の Fable 5 に勝った** — 140万表示
- 1回の指示で1時間半動き続け、対戦AIキャラ込みのシューティングを完成
- 車サッカーゲームの再現をブラウザ公開まで。**消費は月額プラン枠の27%**
- 公式エピソード: 画像を直接見られない状況で**画像解析ツールを自分でゼロから作って**読み取り、3Dモデルを組み上げた（他モデルは到達できず）

**共通項は「1回の指示で完成品まで持っていく力」＝賢さの伸びより「しつこさ」の伸び。渡す前に自分で1度動かして確かめてから返してくる。**

## アクションアイテム
1. 上記の数値を使う前に Anthropic 公式ページで検算する
2. 「最強」を鵜呑みにせず、**自分がよく頼む作業を同じ言葉で投げ直して**前後比較する
3. ファーストモード（2倍コスト）は急ぐ時だけ。effort は用途別に設定する

## 関連
- [[Claude Opus 5 プロンプトガイド実践解説：指示は「足す」より「削る」]]
- [[Fable 5 と Opus 5 の使い分け：監督＝Fable、収束＝Opus ultracode]]（実践者の体感も「長時間・多重指示は Fable」で一致）


Cognee：Claude Code にセッション横断の永続メモリを足すOSSプラグイン（スポンサー動画・自前Wikiとの比較必要） 2026-07-26

## 情報源
- URL: https://www.youtube.com/watch?v=DYdC-oqLMiY
- チャンネル: WorldofAI（英語）
- 投稿日: 2026-07-26 / スコア 72/100
- ⚠ **Cognee のスポンサー動画**（本人が明言）。評価は割り引いて読むこと

## 課題設定
Claude Code のセッションは基本的に使い捨て。セッションが終わると作業コンテキストの多くが消え、次に開くとリポジトリを読み直し、アーキテクチャを説明し直し、既に処理済みのドキュメントを再投入することになる。**時間の無駄・作業の反復・トークンの浪費**につながる。

## Cognee がやること
OSS のメモリプラットフォーム。ファイル・ドキュメント・社内知識・過去のエージェントセッションを取り込み、**構造化されたナレッジグラフ**に整理する。新しいタスク開始時、全部を読み直す代わりに**関連情報だけを retrieve** する。

**双方向であることが肝**: セッション中は brain から読み、セッション終了時に新しい情報・決定・発見が長期記憶へ**書き戻される**。セッションごとに次が賢くなる。

## セットアップ手順（動画で実演）
1. Cognee のクラウド（Google/GitHub でサインアップ）またはローカルインストール
2. 発行された `export` コマンド（APIキー）をターミナルで実行
3. Claude Code で Cognee marketplace を登録するコマンドを実行
4. Cognee プラグインをインストール
5. → **以降すべての Claude Code セッションが自動で Cognee のメモリへ送られる**（手動 sync 不要）

プロジェクトごとに別の brain を作成可。ファイルはペースト／フォルダ指定／ドラッグ&ドロップで投入。Cognee 側が「既存の Claude Code メモリを取り込む」ためのプロンプトも提供している。メモリスキーマとマインドマップで取り込み結果を可視化できる。

Claude Code 以外に Codex / OpenClaw / API / MCP にも接続可能。

## 検証内容
タスク管理Webアプリを新規作成させ、セッションを一度終了 → まったく新しいセッションで同じプロジェクトを開き、前回の詳細（優先度の扱い・必須フィールド・UI設計ルール）を覚えているかを確認する構成。

## 当環境への評価（重要）
**当環境は既に LLM Wiki + auto-memory という永続記憶層を持っており、Cognee の主要な価値提案と機能が重複する。** 導入するなら「ナレッジグラフによる関連情報の自動 retrieve」が既存の全文検索より優れているか、という一点で比較すべき。またクラウド版は**セッション内容が外部サービスへ自動送信される**ため、機密を含むリポジトリでは採用不可（ローカルインストール前提でのみ検討可能）。

## アクションアイテム
- 導入は保留。既存の LLM Wiki 検索で不足を感じた時に、**ローカルインストール限定**で再評価する
- 「セッション終了時に発見を長期記憶へ書き戻す」という双方向の設計思想自体は、既存の記憶運用（3軸保存判定）に取り込む価値がある

## 関連
- [[記憶の置き場はホストによる（LLM Wiki / auto-memory）]]


Xタイムライン学習 2026-07-28 20:22

# Xタイムライン学習 2026-07-28 20:22

Xタイムライン学習に関する情報がまとめられている。新着12件の情報から、ChatGPTのリアルタイムボイスチャットや3D personaの実装について触れている。Claude Codeを使用したさまざまなアプリケーションの開発方法や、AIエージェントの長時間タスクの記憶劣化対策などについて記載されている。

## ポイント
- ChatGPTリアルタイムボイスチャット
- 3D personaの実装
- Claude Codeを使用したアプリケーション開発

## 関連ページ
[[AIに丸投げ起業とClaude Code監督の実態]] [[Claude Code Skills 2026年初頭まとめ]]

## 関連概念（未作成）
`AIエージェントの記憶劣化対策` `リアルタイムボイスチャットの実装`


YouTube日次学習 2026-07-28

# YouTube日次学習 2026-07-28

2026-07-28のYouTube日次学習のまとめ。Claude CodeとCodexの二役開発フロー、AIスキル管理の効率化、Claude APIによるAIエージェント開発などが解説されている。

## ポイント
- Claude CodeとCodexの二役開発フローが実現可能
- AIスキル管理の効率化が可能
- Claude APIによるAIエージェント開発が解説されている

## 関連ページ
[[AIに丸投げ起業とClaude Code監督の実態]] [[Claude Code Skills 2026年初頭まとめ]]

## 関連概念（未作成）
`AIスキル管理` `二役開発フロー`


学習日報 2026-07-28 yt-learn 20:35

# 学習日報 2026-07-28 yt-learn 20:35

## 概要
`/yt-learn` に YouTube URL 11本を個別投入。**8件のLLM Wikiエントリを追加**（重複トピック3本は1ページに統合）。Anthropic 公式ブログ「The new rules of context engineering for Claude 5 generation models」を扱った動画が3本あり、**同じ結論に独立到達**していたため信頼度が高いと判断し実装まで進めた。

---

## 今日学んだこと（YouTube）

### A. コンテキストエンジニアリング（今日の主題・実装済み）

**Anthropic は自社 Claude Code のシステムプロンプトを8割以上削除しても社内評価が落ちなかった。** 原因は量ではなく **1リクエスト内での指示の矛盾**（「必要に応じてドキュメントを残せ」vs「コメントを書くな」がシステムプロンプト・スキル・ユーザー依頼から同時に飛ぶ）。Claude は意図を汲んで正解に近づくが、**矛盾を解くために余計に考える**。

公式が挙げた6つの変化:
1. 禁止の列挙 → **判断基準1個**（事故を塞ぐ禁止は残す価値がある）
2. Few-shot → **インターフェース設計**（例示は新世代では探索の幅を狭める）
3. 全部先出し → **段階的開示**（ツリー構造にする）
4. **同じことを2回書かない**（旧モデルは末尾の指示に強く従ったので繰り返しが必要だった）
5. **CLAUDE.md を記憶の置き場にしない**（自動メモリへ。ただし作業ログを md/HTML に残す運用は否定されていない）
6. 仕様書は Markdown でなくてよい（**評価基準の表を HTML で渡して検証役AIに照らさせる**のが有効）

れん学長の実測が決定的だった: **CLAUDE.md を147個→16個（131個削除）にしても削減0トークン。** CLAUDE.md は作業中フォルダとその親を辿ってしか読まれないため、遠くのファイルは元から載っていない。効いたのは**スキルの description**（554tok）と重複ルールの統合（653tok）のみ。

別チャンネル（AI搭載ラジオ）の48回ブラインド実験（30勝2敗）も「厚さでなく**あなた固有の情報**が効く」と同じ結論。

### B. Opus 5 の性質とモデル使い分け

- **Opus 5 は言われなくても自分で検証する**。「コンテキストフレッシュのサブエージェントでレビューさせろ」系の強制指示は**もはや天井になる**ので削る
- **応答の長さは effort では縮まない。プロンプトで直接指定する**（会話／作業実況／成果物の3種を分けて）
- Thinking がデフォルトON。切れるのは effort=high 以下だけで、**切るとツール命令や内部タグが漏れる**
- **スキルごとに effort を設定する**のが Opus 5 世代の主戦場（low は速く安く十分賢い、ループは xhigh）
- Opus 5 はサブエージェントを積極的に召喚するのでコストを気にするなら同時実行数の上限を設定
- 指示追従性が上がった副作用: 「控えめに」と書くと**文字通り受け取ってあまり報告しなくなる**
- 使い分け: **監督・すり合わせ＝Fable 5 / 収束フェーズ＝Opus 5 の ultracode**。ベンチマークは賢さを測るがメタ認知・目標ドリフトは測れない
- **人間の注意力が真のボトルネック**（Mac 7台あっても常時回せるのは5台が限界）。注意力資源を巻き取るモデルに課金する＝時間をお金で買う

### C. ハーネス設計

- **ループエンジニアリング → グラフエンジニアリング**: 差し戻し先・エスカレーション先・打ち切り条件・受け渡し様式を決めるとループはグラフになる
- **ルータースキル方式**: AIに持たせるスキルを1つだけにし、階層フォルダへ隔離。スキルが100〜300個規模で破綻するのを防ぐ。各フォルダの README は3種の情報だけ（役割／共通ルール／環境依存の制約）

### D. Opus 5 リリース情報（要一次情報確認）

価格据え置き（$5/$25、Fable 5 の半額）・知識カットオフ2026年5月・ARC-AGI-3 で次点の3倍・OSWorld 2.0 で Fable 5 超えかつコスト1/3。**ただし全て Anthropic 自社測定の二次情報**。弱点として業務ワークフロー系は26%、外部検証ではコードレビューの「役に立つ指摘」は約4割、長時間の複雑な計画は依然 Fable 5 が上との声。

### E. 対象外に近い扱い

- Cognee（Claude Code に永続メモリを足すOSS）— **スポンサー動画**。当環境は LLM Wiki + auto-memory で機能が重複し、クラウド版はセッション内容が外部送信されるため導入保留

---

## 今日実装したもの（Issue #303 / PR #305）

| ファイル | 変更内容 |
|--------|---------|
| `~/.claude/tools/measure_context.py` | **新規**。毎ターン必ず載るものだけを数える。常時注入とスキルdescriptionを分離、`.mt-owned`（ベンダー所有）を編集不可と明示 |
| `~/.claude/tools/trends.py` | `MAX_BYTES=6_000` を追加し `prune()` を行数＋バイト数の両方で切る。`compact` サブコマンド追加。`stats()` に `bytes` 追加 |
| `~/.claude/CLAUDE.md` | メタ認知4行＋「禁止10個より判断基準1個」を**足した上で**、二重記述（検証なし完了宣言禁止 / Reactive Coding）を削除。98行（<100制約維持） |
| `~/.claude/rules/trends.md` | compact 実行で 7,581B → 3,182B。今回の学習エントリ追記後 4,168B |
| `memory/instinct-context-cost-measured-in-bytes-not-files.md` | **新規**。ファイル数でなくバイト数で測る instinct |

### 見つかった穴

`rules/trends.md` は **100行キャップを守ったまま 7,581B まで膨張**し、常時注入枠の35%を1ファイルが占めていた。1エントリが1,948字（X Learn の多クエリ集約が10投稿分を貼っていた）。**行数で切った境界はバイト数を守れない** — [[instinct-length-boundary-is-not-inspection-boundary]] と同型の穴が別の物差しで再発した。

### 検証結果

```
prune() 単体検証 : バイトキャップが効く / 行数キャップ健在 / 余計な取りこぼしなし
trends.py compact: 7,581B → 3,182B
measure_context  : rc=0（20,000B 閾値以下）
CLAUDE.md        : 98行 < 100

毎ターン固定コスト: 14,525 tok → 12,434 tok（-2,091 / -14%）
                    ※メタ認知4行を「足した上で」の削減
```

---

## 未実装アクションアイテム（優先順）

| # | 内容 | 段 | 備考 |
|---|------|----|------|
| 1 | スキル定義に `effort` を明示（軽い用途は low/medium、ループは xhigh） | 段1→3 | Opus 5 世代で最も効くとされる。37スキル全部は不要、頻用のものから |
| 2 | スキル内の Few-shot が探索を狭めていないか点検し、制約/インターフェース設計に置換 | 段3 | yt-learn の「環境設計7技」に Few-shot 推奨があり公式見解と矛盾している |
| 3 | サブエージェント同時実行数の上限をハーネスに書く | 段1 | Opus 5 は積極的に召喚する |
| 4 | 評価基準を HTML で渡して検証役AIに照らさせる運用を試す | 段2 | 公式が「Markdown でなくてよい」と明示 |
| 5 | `mulmoterminal-config` の description 1,590字（全体の20%） | 段0 | `.mt-owned` によりベンダー管理。**編集しない**（次回更新で上書きされる）。上流にフィードバックする道はある |
| 6 | Cognee のローカルインストール版を LLM Wiki と比較評価 | 段0 | クラウド版は外部送信のため機密リポジトリでは採用不可 |

---

## LLM Wiki エントリ一覧（本セッション追加）

| id | タイトル | タグ |
|----|---------|------|
| 1362 | 常設指示・スキルは「厚さ」でなく「あなた固有の情報」が効く（48回ブラインド実験・30勝2敗） | prompt-engineering, CLAUDE.md, skills |
| 1363 | ループエンジニアリング → グラフエンジニアリング：差し戻し先とエスカレーション先を決めるとループはグラフになる | graph-engineering, harness |
| 1364 | ルータースキル方式：AIに持たせるスキルを1つだけにして階層フォルダへ隔離する | skills, router-skill, token-optimization |
| 1365 | Fable 5 と Opus 5 の使い分け：監督＝Fable、収束＝Opus ultracode | opus-5, fable-5, model-selection, effort |
| 1366 | Claude Opus 5 プロンプトガイド実践解説：指示は「足す」より「削る」／エフォート管理がハーネスの主戦場に | opus-5, prompt-engineering, effort |
| 1367 | CLAUDE.md を147個→16個に減らしても削減0トークン：効いたのは「スキルのdescription」と重複解消だけ | context-engineering, CLAUDE.md, token-optimization |
| 1368 | Opus 5 リリース速報3本の突き合わせ：値上げなしでFable 5級／ただし「最強」は自分の仕事で測れ | opus-5, benchmark, 要一次情報確認 |
| 1369 | Cognee：Claude Code にセッション横断の永続メモリを足すOSSプラグイン（スポンサー動画） | memory, cognee, mcp |

---

## 解析した動画とスコア

| スコア | 動画 | チャンネル | 扱い |
|-------|------|-----------|------|
| 95 | CLAUDE.md 147個→16個で削減0トークン (WAD-Fl1Tggo) | れん学長のAIツール実験室 | id=1367 → 実装 |
| 95 | 常設指示は厚さでなく固有情報（48回実験） (1TGQl75gZCM) | — | id=1362 |
| 92 | Opus 5 プロンプトガイド解説 (tlmdPJfU1WY) | まさおAIじっくり解説ch | id=1366 |
| 90 | グラフエンジニアリング (LzICVHyruzM) | — | id=1363 |
| 88 | Fable 5 と Opus 5 の使い分け (hCj-GqjRCBU) | まさおAIじっくり解説ch | id=1365 |
| 85 | AIスキル魔改造計画（ルータースキル） (IU3wyu5S4BQ) | — | id=1364 |
| 78 | Opus 5 速報＋コンテキスト設計 (Lw37l0SECvs) | チャエン【AI研究所】 | id=1368 に統合 |
| 75 | 無料AI講座カタログ (S2yMgw0b9bM) | — | 参照のみ（カタログで深度が浅い） |
| 74 | Opus 5 速報 (bIWmKMU5Dh4) | — | id=1368 に統合 |
| 72 | Cognee で永続メモリ (DYdC-oqLMiY) | WorldofAI（英語） | id=1369 |
| 70 | Opus 5 電撃発表 (apnTx1Rgkwo) | ずんだもん解説系 | id=1368 に統合。**11再生のAI生成二次情報**、数値は要裏取り |

---

## 手順上の記録

- **NotebookLM は使わず** Step 4c（Claude が字幕を直接解析）で全件処理した
- 字幕は `yt-dlp --write-auto-sub` で取得。**11本連続で 429 は一度も起きなかった**（各取得の間に `sleep 15〜20` を入れた）
- WorldofAI は日本語自動字幕が無く `FileNotFoundError` → `--sub-lang en` へフォールバックして解決
- PO Token 警告は全編で出たが自動字幕の取得は成功。スキルの2026-06-06注記どおり非致命
- 同一トピック3本（Opus 5 速報）は**個別ページを作らず1ページに統合**した。重複ページは検索時のノイズになるため


Xタイムライン学習 2026-07-28 21:22

# Xタイムライン学習 2026-07-28 21:22

AIモデルのオープンソース化が進み、実装可能なツールが増加している。ChatGPT Real-time Voice、Automated Trading System、DeepSeek's Founder、Kimi K3、RAG vs. Graph RAG、Anthropic's Agent Systemなどを実装する。目標はKimi K3の2.8Tモデルをダウンロードし、Sherlockでユーザー検索を実装し、Claude CodeでWebインターフェースを構築する。

## ポイント
- AIモデルのオープンソース化が進み、実装可能なツールが増加
- Kimi K3の2.8Tモデルをダウンロードし、Sherlockでユーザー検索を実装
- Claude CodeでWebインターフェースを構築

## 関連ページ
[[CC Learn - Claude Code is all you need in 2026]] [[CC Learn - Claude Code for Desktop is the BEST way to build apps with AI (full tutorial)]]

## 関連概念（未作成）
`AIエージェント` `オープンソースAIモデルの実装`


Xタイムライン学習 2026-07-28 21:25

# Xタイムライン学習 2026-07-28 21:25

2026-07-28のXタイムライン学習で、Claude Opus 5、OpenCode Go、GitHub Copilot HyDRA、リッチなアニメーションUI、Claude共有チャット、Claude Codeビデオ編集、Claude YouTubeチャネル、Codex Windowsなどが実装GO。AI組織、Grokフィギュア、シャッフルアイランドは参考のみ。横断テーマはClaude、AI、影環境での実装とマネタイズの可能性。

## ポイント
- Claude Opus 5 shadow環境で試す
- OpenCode Go 試用する
- HyDRA shadow環境で試す
- Claude YouTubeチャネル作成に試す
- Codex Windowsで試す

## 関連ページ
[[AIに丸投げ起業とClaude Code監督の実態]] [[AIに全丸投げ起業？Claude Codeで自律AIを監督する]] [[Claude Code Skills 2026年初頭まとめ]] [[MCP→公式CLI移行で週次タスク安定化]] [[MCP捨ててCLI移行でClaude Code週次タスクを安定化]] [[Paperclip: AIへの丸投げ起業と自律AI管理術]] [[「LLM Wiki」知識管理思想 — Karpathy提唱]] [[2026-05-23 shadow運用改善 — openclaw --init / chrome-vnc / cure SSH]] [[2026-06-02 YouTube学習: AIエージェント長時間タスクの記憶劣化対策（MMPO論文・Goal Buddy・ハーネスエンジニアリング）]] [[2026-06-02 YouTube学習: Codex万能AIアプリ化とセキュリティ（security-guidance・書くAI/見るAI分離）]] [[2026-06-02 YouTube学習: モデル比較とマルチモデル運用（GPT5.5 vs Opus4.8 vs Gemini3.5・適材適所）]] [[2026-06-02 goalbuddy初の実Issue実証: #265 videos.title空調査をgrok Workerで自律完遂]] [[2026-06-02 grok CLI 復活: @GokouMutsumi(Xプレミアム)で再認証・実Worker実働・grok chat廃止修正]] [[2026-06-02 修正系Issue自律実証: #283 freeconsul を worktree隔離+goalbuddyで安全修正(PR#290)]] [[2026-06-02 別AIレビュー(Arisパターン)実証: PR#290をcerebras gpt-ossが批評→検証して反映]] [[2026-06-02 完成: goalbuddy 完全自律ループ（run・Worker自動委譲マルチバックエンド・E2E実証）]] [[2026-06-02 完成: goalbuddy 実Worker(agy)で完全自律ループをE2E実証]] [[2026-06-02 実装: MMPO/Goal Buddy を実践化 A実証+B hook強制化+C goalbuddyツール]] [[9router — Claude Code/Codex/Cursor を無料・低コストプロバイダーに自動ルーティング 2026-05-24]] [[Antigravity 2.0 完全ガイド — マルチモデル対応Googleエージェント・CLIコマンドagy 2026-05-25]] [[Antigravity→Codex/Claude Code拡張+Ollama ローカルAPIコスト削減フロー 2026-05-28]] [[AsyncLLMClientを初期化する前に、プロバイダーがreasoning_effortパラメータに対応しているか確認する]]

## 関連概念（未作成）
`Claude Opus 5` `OpenCode Go` `GitHub Copilot HyDRA` `リッチなアニメーションUI` `Claude共有チャット` `Claude Codeビデオ編集` `Claude YouTubeチャネル` `Codex Windows`


Xタイムライン学習 2026-07-28 21:27

# Xタイムライン学習 2026-07-28 21:27

Claude Opus 5の自動生成機能、グラフエンジニアリングの解釈、Kimi-K3のウエイト公開、AIエンジニアの発言、Claudeの公開Artifactsの注意喚起などを学習。Claude Opus 5の導入を検討。Claudeのプロンプト機能を活用。グラフエンジニアリングの研究を続ける。

## ポイント
- Claude Opus 5の自動生成機能
- グラフエンジニアリングの解釈
- Kimi-K3のウエイト公開
- AIエンジニアの発言
- Claudeのプロンプト機能の活用

## 関連ページ
[[AIに丸投げ起業とClaude Code監督の実態]] [[Claude Code Skills 2026年初頭まとめ]]

## 関連概念（未作成）
`マネタイズ` `自動生成機能`


Xタイムライン学習 2026-07-28 22:05

# Xタイムライン学習 2026-07-28 22:05

新着8件のXタイムライン学習についてまとめる。ChatGPTとMetaAIイラスト生成実験、部品集CSS/React、OpenAI AI活用事例集などが含まれる。横断テーマはAIツールの統合と自律化が進むこと。実装はvvv-botsにAIツール統合を行い、shadow環境でAIツールの収益モデル検証を行う.

## ポイント
- ChatGPTとMetaAIイラスト生成実験
- 部品集CSS/React
- OpenAI AI活用事例集
- AIツールの統合と自律化が進む

## 関連ページ
[[AIに丸投げ起業とClaude Code監督の実態]] [[Claude Code Skills 2026年初頭まとめ]]

## 関連概念（未作成）
`AIツール統合` `自律AIシステム`


Xタイムライン学習 2026-07-28 23:05

# Xタイムライン学習 2026-07-28 23:05

2026-07-28のXタイムライン学習で、パチンコ/パチスロコミュニティ向けプロジェクトPACHI-PACHI-7が新着。収益モデル分析とshadow環境適用を検討。ゲーミングコミュニティ向けマネタイズプロジェクトが注目。

## ポイント
- PACHI-PACHI-7プロジェクト新着
- 収益モデル分析とshadow環境適用検討
- ゲーミングコミュニティ向けマネタイズプロジェクト注目

## 関連ページ
[[2026-05-23 shadow運用改善 — openclaw --init / chrome-vnc / cure SSH]] [[2026-06-02 YouTube学習: AIエージェント長時間タスクの記憶劣化対策（MMPO論文・Goal Buddy・ハーネスエンジニアリング）]]

## 関連概念（未作成）
`パチンコ/パチスロコミュニティ` `ゲーミングマネタイズ戦略`