COG second brainとは｜33スキルと検証ハーネスをMarkdownだけで回す第二の脳を実測

セカンドブレイン（第二の脳）を名乗るツールは山ほどあるが、その多くは専用データベースと専用アプリを前提にしている。COG second brain（huytieu/COG-second-brain、★959・MIT）はそこを外した。保存されるのは素のMarkdownファイルだけで、バージョン管理はgit、閲覧は任意のエディタかObsidian。データベースは存在しない。

そのうえでCOGが持ち込んだのが、作業したエージェントが自分の成果を採点しないという検証ハーネスである。この記事では公称値を実際に数え、その検証ハーネスがどのレベルで担保されているかまで確かめた。

エージェントに作業手順を仕込むという発想の全体像、CLAUDE.mdやHooksの位置づけについてはClaude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめてある。COGはその上に「知識管理」と「検証」という2つの層を載せたものだと考えると分かりやすい。

COG second brainとは——DBを持たないという設計判断

COGの構造はきわめて素朴だ。リポジトリを開くと 00-inbox、01-daily、02-personal、03-professional、04-projects、05-knowledge、06-templates という番号付きのディレクトリが並んでいる。ここに入るのは全部Markdownである。

この素朴さが効くのは、出口が塞がらないという一点においてだ。専用DBを持つツールは、乗り換えるときにエクスポート機能の出来に運命を握られる。COGにはエクスポートという概念が無い。最初からファイルなので、別のツールに移りたければディレクトリごとコピーすればいい。gitで管理しているので履歴も一緒に付いてくる。

エージェント側の対応範囲も広い。README記載の対応表を実ファイルと突き合わせた結果が次のとおりで、公称値はすべて正確だった。

数が合っているだけでなく、リポジトリは自分でそれを検査する仕組みを持っている。

git clone https://github.com/huytieu/COG-second-brain.git
cd COG-second-brain

# 同梱の自己検証スクリプト。マニフェスト・ドキュメント・実ファイルの乖離を検出する
bash scripts/validate-agent-surface.sh

実行すると、各スキルについて「マニフェストのパスが実在するか」「AGENTS.mdに対応するコマンドが記載されているか」を1件ずつ検査し、最後にバージョン整合とKiro/Geminiの本数を確認する。結果は ✓ Validation passed with 0 warning(s) だった。

ドキュメントと実装の乖離は、この種のスキル集で最も起きやすい劣化である。それを検査するスクリプトを自分で同梱し、実際に通っている——という事実は、README上のどんな主張よりも信頼できる材料だと考えている。

33スキルの中身——個人向けからチーム運用まで

スキルは用途別に分かれている。全部を並べても意味がないので、性格の違う群だけ挙げる。

個人の知識管理では braindump（頭の中を吐き出すと自動分類される）、daily-brief（7日以内の鮮度で検証済みニュースを届ける）、url-dump（URLを保存し要点を抽出）、weekly-checkin（領域をまたいだパターン分析）、knowledge-consolidation（散らばったメモから枠組みを組む）といったものが並ぶ。

興味深いのは memory-hygiene である。永続メモリに溜まった記述を実環境に対して再検証し、last_verified と確信度をスタンプし直す、という機能だ。書いた時点では正しかったが今は違うという記述を放置しない発想は、長く使うほど効いてくる。

個人向けの群でもうひとつ挙げたいのが memory-hygiene の設計思想だ。このスキルが防ごうとしているのは、COGが「stale-but-confident（古いのに自信がある）」と呼ぶ失敗モードである。「あのwebhookはXにある」「ボードIDはYだ」といった記述は、書いた時点では正しい。しかし環境が変わったあとも同じ確信度で検索に引っかかり、そのまま使われてしまう。

対処として採っているのが、信頼度を保存物の属性ではなく実行時の判断にするという方針である。各エントリに last_verified と confidence（high / medium / low）を第一級のフィールドとして持たせ、実環境に対して再検証したうえでスタンプし直す。安価に検証できないものは unverifiable-cheaply として確信度を据え置く、という逃げ道も用意されている。この考え方はUC Berkeleyの論文「From Model Scaling to System Scaling: Scaling the Harness in Agentic AI」（arXiv:2605.26112）からの翻案だと明記されている。

チーム運用の群では team-brief がGitHub・Linear・Slack・PostHogを横断して日次のチーム状況を作り、Linearへ書き戻す。meeting-transcript は会議の記録を決定事項・アクションアイテム・チームの力学に構造化する。comprehensive-analysis は7日分を深掘りして週次レビューや役員会の準備に使う（所要8〜12分と明記されている）。

プロダクトマネジメントの群は、auto-research で調査し、generate-prd でPRDを起こし、create-user-story でユーザーストーリーに割り、開発後に generate-release-notes でリリースノートを作り、update-knowledge-base で知識ベースを更新する、という一連の流れを想定して並んでいる。create-user-story にはLinear・GitHub Issues・Jiraをまたいだ重複チェックが入る。

調査と発信の群には auto-research と content-factory がある。前者は問いを複数の調査スレッドに分解して並列に走らせる。後者は発表を拾い、トレンドの勢いと自分ならではの角度で選別し、重複を台帳で防ぎながら投稿まで持っていく——という自動化パイプラインで、投稿量の上限とスクリーンショットによる投稿確認が組み込まれている。歯止めを最初から設計に入れているのが、この種の自動発信スキルとしては珍しい。

さらに「anti-slop」と名付けられた一群がある。no-ai-slop（文章）と product-ui-taste・taste-skill（UI）が対になっており、いずれも「AIが作ったように見える平凡な成果物」を出さないための基準集だ。COGのリポジトリ説明文が「paired anti-slop design skills for marketing and product UI」と書いているのはこれを指す。

導入は各エージェントの流儀に合わせる形になっている。Claude Codeならリポジトリを開いて「Run onboarding」と伝えるだけで、対話しながら自分の使い方に合わせた設定が入る。npx skills add huytieu/COG-second-brain でスキルとして入れることもできる。

検証ハーネス——作業者が自分の成果を採点しない仕組み

COGで最も特徴的なのがここである。WORKFLOW.md に定義されたV字モデル（V-model）が、全スキルの品質を支える土台になっている。ソフトウェア開発の V-model をエージェントの作業サイクルに移植した、と説明されている。

左側で仕事を分解し、頂点で作り、右側で検証する。チェックポイントはCP-0（intake）からCP-7（retro）まで8段階あり、それぞれに「何が満たされたら次へ進めるか」と「証拠をどこに残すか」が決められている。

設計として優れていると感じた点が2つある。

ひとつは CP-5 の定義だ。受け入れ判定の根拠を「ツールの戻り値」ではなく「事後条件の観測」と明記している。APIが200を返したことと、意図した状態になったことは別である、という当たり前だが守られにくい区別を、チェックポイントの定義に埋め込んでいる。

もうひとつは verifierへの入力の絞り方である。READMEにはこう書かれている——verifierには成果物のパスだけを渡し、workerの出力は渡さない。理由も添えられている。文脈を貼り付けると、verifierは成果物そのものではなく、workerの言い回しのほうを評価してしまうからだ。

全部の作業に全部の検証を掛けない

検証を厳しくすると、今度は小さな作業が回らなくなる。COGはそこを「レーン」で捌いている。作業の性質に応じて、通すチェックポイントの数を変える仕組みだ。

レーンの判定は bash .claude/lib/lane-classify.sh に任せる。full レーンでは受け入れ基準・証拠台帳・検証結果をまとめたHTMLのロールアップまで生成されるが、normal と tiny では省略される。

レーンの導入で見落とされがちなのは、どのレーンに入るかを人間が決めない点である。判定はスクリプトに任され、作業内容から自動的に決まる。ここを人間の裁量にすると、急いでいるときほど軽いレーンが選ばれ、検証は形骸化していく。自動判定にしておくことで、面倒だから省くという逃げ道を塞いでいる。

検証の重さを一律にしないというのは、この種のハーネスが実運用で生き残るかどうかの分かれ目になる。全部に最も厳しい検証を掛ける設計は、数日で誰も使わなくなる。

この考え方は、当サイトが記事の品質管理に使っている writing-loop（書く側と評価する側を分け、書いた本人に合否を判定させない）とまったく同じ発想である。エージェントに何かを任せるとき、作った当人に「できましたか」と聞いても意味がない、という経験則が別々の場所で同じ形に結晶している。

「read-only」がどのレベルで担保されているか

ここは正確に書いておきたい。READMEは検証エージェントを次のように紹介している——「Read-only verifiers（they cannot edit files or mutate external state）」。task-verifier の定義本文にも「You are a read-only verifier」「Spawn no write tools, no Edit」と書かれている。

では、その「できない」は何によって担保されているのか。.claude/agents/ 配下の定義を全部開いて確かめた結果、frontmatterには name / description / model の3つしか無く、ツールを制限する tools: キーは1つも無かった。リポジトリ全体を探しても settings.json もフックも置かれていない。

Claude Codeの公式ドキュメントは、サブエージェント定義で tools を省略した場合の挙動をこう定めている——「Inherits every tool available to subagents if omitted」（省略時はサブエージェントが利用できるすべてのツールを継承する）。バックグラウンド実行時に絞り込まれた後の一覧にも Edit と Write は残る。

つまりCOGの検証エージェントは、技術的にはファイルを書ける。read-onlyはプロンプト上の取り決めとして守られている、というのが実態だ。

強制したければ、利用者側で1行足せばよい。

---
name: task-verifier
description: Read-only verification gate.
model: sonnet
tools: Read, Grep, Glob, Bash          # ← Edit / Write を継承させない
---

この tools: はカンマ区切りの文字列で書く（公式ドキュメントにも tools: Read, Grep, Glob, Bash という例がある）。逆に外したいツールだけを指定する disallowedTools: も同じ書式で使える。信頼できない入力を扱う場面、あるいは自動実行を長時間まわす場面では、この1行を入れておく価値がある。

公称値とread-onlyを自分で確かめる

READMEの数字を信じる必要はない。手元で数えられる。

# 公称値を自分で数える（33 / 33 / 33 / 7 / 7 / 10 になるはず）
for d in skills .claude/skills .agents/skills .kiro/powers .gemini/commands .claude/agents; do
  printf "%-22s %s
" "$d" "$(ls "$d" 2>/dev/null | wc -l)"
done

# バージョンの実体を確認する（タグではなくこちらが配布される値）
cat COG-VERSION

# read-only の担保レベルを確認する（tools: が出力されなければプロンプト上の取り決め）
grep -l "^tools:" .claude/agents/*.md || echo "tools: 指定なし = 全ツールを継承する"

3つ目のコマンドが重要である。何も出力されなければ、検証エージェントは技術的にはEditやWriteを使える状態にある。自動実行を長時間まわす、あるいは信頼できない入力を扱うなら、前節で示した tools: の1行を足しておきたい。

READMEの分類がひとつ噛み合っていない

同じ「Read-only verifiers」の見出しの下に、4つのエージェントが並べられている。task-verifier、integration-verifier、fix-agent、harvest-curator である。

このうち fix-agent は明らかに読み取り専用ではない。定義本文にはこう書かれている——「Apply minimal edits to close each failure id」（各失敗IDを解消する最小限の編集を適用する）。descriptionも「Implements only what the verifier flagged」だ。検証が FAIL:fixable を返したあとに修正を当てる役なのだから、当然ファイルを書く。

見出しが「they cannot edit files or mutate external state」と宣言している下に、編集するのが仕事のエージェントが入っている。設計が間違っているのではなく、分類のラベルが合っていない。fix-agent の設計自体は、むしろ良くできている——自分でPASSを出すことを禁じられ（「You do NOT self-verify as PASS」）、修正後は必ずorchestratorが task-verifier を再派遣する。試行回数も2回までに制限されている。ハーネスの思想には忠実だ。

この不整合を細かすぎると感じる人もいるだろうが、指摘しておく理由がある。read-onlyという言葉は、利用者にとって「このエージェントは何をしても壊さない」という安心の根拠になる。その分類に、編集を行うエージェントが1つ混ざっているだけで、分類そのものが根拠として使えなくなる。分類は正しいから役に立つのであって、おおむね正しい分類は、確認の手間を減らさない。

harvest-curator のほうは概ね整合している。/tmp/ には書くが、永続的な知識ディレクトリ 05-knowledge/ へは人間の承認なしに書かない設計になっている。

COG second brainの「型」を支える3つの仕掛け

33スキルを個別に眺めても本質は見えない。COGを面白くしているのは、スキルの下に敷かれた共通の仕掛けのほうだ。3つある。

1. ループの設計を1箇所に集約している

loop-engineering というスキルは、それ自体では何も生成しない。「繰り返すスキル」が共通で参照する設計リファレンスである。冒頭にはこう書かれている。

鉄則：決定論的なチェックを信じ、エージェント自身の「できたっぽい」という自己申告は決して信じない。すべてのループは、検証器・停止条件・従うパターンを宣言しなければならない。

daily-brief、knowledge-consolidation、url-dump、weekly-checkin、auto-research、scout といった反復系のスキルは、ルールを各自で書き直さずここへリンクする。同じ規律を1箇所で定義し、全スキルが参照するという構造は、スキル集が育つほど効いてくる。ルールを各ファイルにコピーしていると、必ずどこかが古くなるからだ。

2. 外部から取り込んだスキルの出所を記録している

no-ai-slop は、AI特有の文体を検出して直す編集スキルだ。「delve」「leverage」「robust」「game changer」といった語を名指しで禁止し、抽象的な表現を具体に置き換えることを求める。当サイトの humanizer スキルと発想が近い。

注目したいのは中身ではなく、同梱されているファイルのほうである。このスキルのディレクトリには SKILL.md の他に LICENSE、SOURCE.md、eval.md が置かれている。SOURCE.md にはこう書かれていた。

・出所：petergyang/no-ai-slop（Peter Yang）、MITライセンス
・取り込み日：2026-07-23、この注記以外は無改変
・採用前に、実在する書き手の公開済みの文章に対して照合した経緯
・元スキルと自分たちのハウスルールが食い違う箇所（em dashの扱い）と、どちらを採ったか

外部のスキルを取り込むときに、出所・ライセンス・取り込み日・改変の有無・採用理由を残す。これは本来どのスキル集もやるべきことだが、実際にやっている例は多くない。後述するスキル管理ツールが解こうとしている問題を、COGは手作業の規律で先に解いている。

3. 参照を本文から切り離している

taste-skill の SKILL.md は73KB、product-ui-taste は53KBある。これはスキルとしては相当に大きい。ただし taste-skill は本文の脇に references/ を持ち、そこへ5つの参照ファイル（デザインシステムの導入手順、モーションの雛形、パターン語彙など）を分けている。

リポジトリの直近のコミットにも「肥大化した5つのスキル本文を references/ へ分割」というものがあった。エージェントが毎回全文を読むと文脈が圧迫されるので、起動時に読む本文と、必要になってから読む参照を分ける——という運用に手を入れ続けている。

バージョンとメンテナンス状況

導入前に見ておくべき数字も挙げておく。COG-VERSION と plugin.json はいずれも 3.11.0 で、同梱の検証スクリプトもバージョン整合を確認している。一方、GitHubのタグは v3.8.1 が最新で、3マイナー分遅れている。

実害は小さい。COGの導入手段は git clone（デフォルトブランチ）か npx skills add で、どちらもタグではなく main を取る。読者が手にするのは3.11.0のほうだ。タグはリリース記録として置かれているにすぎない。

ただし「特定バージョンに固定して配りたい」という運用をするなら、タグが実態を指していない点は把握しておく必要がある。

リポジトリの動きは活発で、最終pushは2026-08-24。直近では「構造的なslop対策ルール（v3.11.0）」「肥大化したスキル本文を references/ へ分割」「デッドリンクの除去」といったコミットが並んでいる。ドキュメントと構成の手入れに継続的に手が入っているタイプのリポジトリだ。オープンなIssueは7件、PRは1件だった。

誰に向いていて、誰には向かないか

COGは万人向けではない。向き不向きがはっきりしている。

・向いている：すでにMarkdownでメモを取っており、それをエージェントに読ませたい人
・向いている：プロダクトマネージャーやエンジニアリングリード。team-brief や generate-prd のようなチーム運用スキルが刺さる
・向いている：エージェントの成果物を検証する型を探している人。COGの検証ハーネスは、知識管理と切り離しても参考になる
・向かない：GUIのノートアプリを求めている人。COGにUIは無い
・向かない：スキル数の多さを期待する人。33個は多いが、自分の業務に該当するのは数個のはずで、残りは使われない

近い領域のOSSと並べると、それぞれが担当している層の違いがはっきりする。

COGとObsidian Skillsは競合しない。前者がワークフローと検証を、後者が金庫の操作を担うので、併用できる。COGとgstackも対象領域が違う（知識管理 vs ソフトウェア開発）ため、両方入れて使い分けることになる。

導入コストの観点では、COGはリポジトリを丸ごと自分の金庫にするという取り方をする点に注意がいる。既存のObsidian金庫がある人は、COGのディレクトリ構造（00-inbox 〜 06-templates）を自分の構造にどう重ねるかを最初に決める必要がある。onboarding スキルはその調整を対話でやってくれるが、既存の分類体系が強固な人ほど摩擦は大きい。

似た系譜のOSSとしては、Y CombinatorのGarry Tanが公開したgstackとは｜Garry Tan流Claude Codeスキル集『AIソフトウェア工場』の全貌がある。COGのREADME自身が影響元として gstack と gbrain を挙げている。gstackがソフトウェア開発の工程（CEO・QA・セキュリティ責任者の視点）を役割別スキルにしたのに対し、COGは知識管理の工程を同じやり方でスキル化した、という関係にある。

Obsidianを軸にAIエージェントを組む方向ではObsidian Skills とは・使い方｜kepano製Agent SkillsでObsidianをAIエージェント化が近い。こちらはObsidianの操作そのものをスキル化したもので、COGのようなワークフロー全体の型は持たない。

スキルを複数のプロジェクトで使い回し、バージョンを固定して配りたくなったら、qvr（quiver）とは｜エージェントスキルにlockfileと監査を持ち込むGo製パッケージマネージャを実測のような管理ツールが視野に入ってくる。COGは「1つの完成したセット」として配られるので、まずはそのまま使い、必要になってから分解を考えるのがよい。

まとめ

参照ソース

・huytieu/COG-second-brain（公式リポジトリ・README） — スキル数・エージェント分類・対応エージェント表の公称値の出典
・COG WORKFLOW.md — V字モデルとCP-0〜CP-7の定義、各チェックポイントの証拠要件
・Claude Code サブエージェント公式ドキュメント — tools 省略時に全ツールを継承するという挙動の一次情報
・garrytan/gstack — COGが影響元として挙げるスキル集