📌 はじめに
⏱️ この記事は10分で読めます。
この記事を一文で言うと — AIに"仕事"ではなく"役職"を任せ、各役職の判断（結論・根拠・却下した代替案）を追記専用ログに残して、次の判断の前に必ず読み戻す。たったこれだけで「同じ提案を蒸し返してくるAI」を卒業できる。
AIにコードを書かせていて、こんな経験はないでしょうか。
「有料プランを足そうか」という案に、一度ちゃんと考えて「いや、それは"手軽に始められる"という製品の良さを壊すからやめよう」と結論を出した。
なのに次に同じ話題が出ると、AIはまた無邪気に「有料プランを追加しましょう」と提案してくる。
"なぜやらないと決めたか"が、どこにも残っていないのです。
Cursorでも、Copilotでも、Claude Codeでも同じです。
AIへの指示は毎回その場限りで、前回の判断も、却下した代替案も、なぜそうしたかも、セッションが変われば消えていく。
毎回ゼロから説明し直すあの徒労感に、心当たりがある人は多いはずです。
ここで作るものを図にすると、こうです。AIに"仕事"ではなく"役職"を任せ、各役職の判断を組織の知識として残していきます。
ただし、本題は会社ごっこではありません。その裏にあるツールに依存しない設計パターン——「却下理由ごと、判断を残す」——のほうです。
特別なツールは要りません。手元のAI（Cursor / Copilot / Claude Code）にそのまま持たせられます。記事の後半では、この設計を実装した個人開発のプラグイン vibecorp を、実際の判断ログとあわせて具体例として紹介します。まずはツールなしで真似できる最小構成から見ていきます。
👥 想定読者
- AIコーディング（Cursor / Copilot / Claude Code 等）を日常的に使っている方
- 「AIへの指示が毎回その場限りで積み上がらない」もどかしさを感じている方
- AIエージェントをチームのように動かす設計に興味がある方
🧩 まず結論：ツールなしで真似できる最小構成
仕組みの本体は単純です。次の3点だけで「蒸し返さないAI」の核は再現できます。
蒸し返さないAIの最小レシピ
- エージェント（またはシステムプロンプト）の手順の先頭に「判断前に
decisions.mdを必ず読む」を入れる - 判断のたびに「結論・根拠・却下した代替案」を追記専用（append-only）のログに書かせる
- ログが育ったら「目次＋本体」に分割して、毎回は軽い目次だけ読ませる
ポイントは2つあります。
ひとつは、「何を決めたか」だけでなく「なぜそうしたか」「何を却下したか」まで残すこと。最新の結論だけなら1行で足りますが、それだと「一度下げた上限を、なぜ後で引き上げ直したか」のような撤回の経緯が消えてしまい、結局また同じ議論を蒸し返します。
もうひとつは、「目次（index）＋アーカイブ」の2階層にすること。毎回読むのは軽い1行サマリの目次だけ。関連しそうな時だけ重い詳細ファイルを開く。これで「全部読むとコンテキストが膨張する」問題を避けます。目次は1判断=1行で、こう書きます。
- YYYY-MM-DD — Issue #NNN または トピック名 — 結論の一行要約
この3点は、どんなAIコーディング環境でも今日から導入できます。以降は、これを「役割ごとに整理し、機械的に強制し、開発ループに組み込む」とどうなるか、という実装例の話です。
📦 実装例：役職を持つAIの組織「vibecorp」
上の最小レシピを、もう一段しっかり作り込んだのが個人開発のプラグイン vibecorp——AIエージェントに役職（CTO・CFO・CISO…）を与えてチームとして組織化する Claude Code プラグインです（構成は冒頭の図のとおり）。
技術はCTO、コストはCFO、安全はCISO、法務はCLO。あなたはCEOとしてIssueを渡すだけです。
役割を分けるのは、見た目を会社っぽくするためではありません。
判断を役割ごとに切り分けて、それぞれの「知識」として残していくためです。冒頭の最小レシピでいう decisions.md を、役職ごとに分けて持っているイメージです。
- リポジトリ: hirokimry/vibecorp（MITライセンス）
- 本記事で紹介する判断ログは、すべて上記リポジトリの
.claude/knowledge/配下に実在するものです
普通のAIとvibecorpの違いはこうです。
違いは、たった1つの分岐だけです。「却下理由を残すか、残さないか」。残さなければ同じ提案へ素通りで戻る（堂々巡り）。残せばknowledgeを経由し、次は過去ログを読み戻してから提案する（＝蒸し返さない）。
📂 実物を見てみる：CFOが自分の判断を撤回した記録
実際にリポジトリに残っている判断ログをそのまま貼ります。
これは .claude/knowledge/cfo/decisions-index.md の冒頭エントリ。同時処理するIssue数の上限（max_issues_per_run）を、CFOが一度「3へ」と決め、後の再判断で自分の結論を撤回して「7へ」引き上げた跡が、理由ごと2行で残っています（元になった Issue #247）。
- 2026-04-28 — Issue #247（第2版） — max_issues_per_run 最適値の再判断（Claude Max 20 前提）、per_run=3 撤回・per_run=7 + per_day=14 に引き上げ推奨
- 2026-04-28 — Issue #247（第1版） — max_issues_per_run 最適値の CFO 判断、per_run=3 への引き下げ推奨（後に撤回）、cycle 単価を $22→$25 に訂正
この判断は、役職ごとに分かれたディレクトリの中に、実際にこういう形で積み上がっています。
.claude/knowledge/
├── cfo/ # 💰 コスト判断
│ ├── decisions-index.md # 目次（各役職が毎回まずこれを読む）
│ ├── decisions/ # 四半期アーカイブ
│ │ └── 2026-Q2.md # 関連した時だけ開く本体
│ └── templates/
├── cto/ # 🧑🔬 技術判断
├── cpo/ # 📋 プロダクト判断
├── ciso/ # 🛡️ セキュリティ判断
├── clo/ # ⚖️ 法務判断
├── sm/ # 🏃 プロセス判断
├── accounting/ # 経理分析員
├── legal/ # 法務分析員
├── security/ # セキュリティ分析員
├── agents-vs-skills.md # 役職横断の知見
├── organization-presets.md
└── public-first-design.md
「何を決めたか」だけなら最新行で足ります。
でもここでは撤回の経緯ごと残すから、次にコスト上限の話が出ても、AIは同じ検討を一からやり直しません。
同じ要領で、他の役職にも判断が積み上がっています。
| 役職 | 残っている判断（実物） |
|---|---|
| 💰 CFO |
max_issues_per_run を月額試算付きで「3へ」と決定 → 後に「7へ」と自分で撤回。なぜ変えたかまで残る |
| 🧑🔬 CTO | Docker隔離を撤回し、より軽量な macOS の sandbox-exec へ転換（隔離方式の評価・却下の経緯ごと記録） |
| 📋 CPO | 冒頭の「有料プラン」の話。Proプラン新設をNo-Goと裁定。「機能を増やすより既存の体験を磨く」という原則に照らして却下 |
CPOの判断基準には、こんな原則が明文で置かれています（cpo/product-principles.md より）。
一貫性: 過去の判断と矛盾しない。矛盾する場合は理由を明示して更新する
冒頭の「蒸し返し」問題が、ここで効いてきます。
やめると決めた理由が知識として残っているから、次に同じ提案が出ても、AIはまず過去の判断を読み戻す。
チームとして同じ過ちを繰り返さなくなるわけです。
🔧 どうやって"読み戻し"を強制しているか（仕組みの実物）
「次の判断で読み戻す」と言葉で書くのは簡単ですが、AIは放っておくと読み戻しません。これを精神論ではなく、エージェント定義のワークフローに固定しているのが実装上のキモです。
各役職エージェントの定義ファイル（agents/cfo.md など）には、判断手順の Step 1が「まず過去ログを読む」 と書かれています。実物の抜粋です。
### 1. 情報収集
以下のファイルを Read ツールで読み込む。
- MVV.md（必須・最初に読む）
- .claude/knowledge/cfo/decisions-index.md（存在すれば。過去判断の目次）
インデックスから関連する過去エントリが見つかった場合、
対応するアーカイブ（decisions/YYYY-QN.md）を追加で Read する。
### 2. メタレビュー
| 観点 | チェック内容 |
| 過去判断との一貫性 | 過去判断と矛盾しないか。
矛盾する場合は理由を明示して更新する。|
さらに、この知識ファイルへの書き込みをhookで多層防御しています。Edit/Write 経由の直書きも、Bash のリダイレクト（>>、tee、sed -i 等）経由の抜け道も、専用フックが機械的に deny します。「AIがログを正しく残さない／壊す」を構造で潰しています。
最小レシピの「必ず読む」「追記専用」を、人間の善意に頼らず仕組みで担保しているわけです。
🆚 「AIに記憶を持たせる」機能との違い
ここまで読んで「それ、AIのメモリ機能と何が違うの？」と思った方もいるはずです。
例えば ECC（Everything Claude Code） は、60超のエージェント・200超のスキルを束ね、10ヶ月以上の実運用で鍛えられた大規模なエージェントハーネスです。継続学習（確信度スコア付き）、メモリ永続化、セキュリティスキャン、マルチIDE対応まで含む総合パッケージで、その一機能として「学習・記憶」を持ちます。
ℹ️ 以下の比較は執筆時点の筆者の理解にもとづきます。ECCは活発に更新されているため、最新は公式READMEを確認してください。
規模も成熟度も、個人開発のvibecorpとは桁が違います。ここで比べるのは優劣ではなく、「学習・記憶」という一軸での設計思想の違いです。その一点だけを並べると、住み分けがはっきりします。
| ECCの継続学習 | この設計（vibecorp） | |
|---|---|---|
| 残すもの | コードの書き方・癖（自動抽出・確信度付き） | 意思決定（結論・根拠・却下案） |
| 単位 | ドメインタグ別 | 役職別（CTO/CFO/CISO…）・時系列 |
| 狙い | エージェントが上手くなる | 組織として同じ判断を蒸し返さない |
念のため補足すると、「自動抽出・確信度スコア・スキルへの進化」といった学習の作り込みはECCに分があります。ECCはセッションから知見を自動で吸い上げて再利用可能なスキルに育てる方向、こちらは人とAIの意思決定を役職別に手元へ残す方向。目指す"記憶"の種類がそもそも違うわけです。
特に 「却下した代替案」を根拠ごと残す という点が、この設計のいちばんの特徴です。
🚀 では、その知識はどう貯まる？ Issueを渡すと組織が回る
その判断ログは、実際に開発を回す中で貯まります。
いちばん使うのはこの1行です。
/vibecorp:ship <Issue URL>
Issueを渡すと、担当役が実装 → PR作成 → レビュー対応 → auto-merge までを自動で回します。
その過程で各役職が下した判断が、そのまま知識として残り、次の判断の前に読み戻される。
実際に流すと、こんな具合に進みます。
⚠️ 以下は動作イメージです（実際の出力を簡略化・再構成したもの）。
$ /vibecorp:ship https://github.com/you/your-project/issues/N
▶ COO Issue #N を解釈 → 担当: CTO（技術選定を含むため）
▶ CTO 過去判断を読み戻し中 … .claude/knowledge/cto/decisions-index.md
↳ 関連エントリ発見: 「Docker隔離を撤回し sandbox-exec へ」を参照
▶ CTO 実装方針を決定（結論・根拠・却下案を knowledge に追記）
… (中略: 実装 → テスト) …
▶ review-loop 指摘 3 件 → 修正 → 指摘 0 件
▶ CFO コスト影響を確認 … decisions-index.md を読み戻し → 課金影響なし・承認
▶ PR を作成 → CodeRabbit レビュー通過
✅ auto-merge 完了（#N → main）
📝 今回の判断を .claude/knowledge/ に追記しました
この一周がそのまま「知識が貯まるエンジン」です。
つまり「自動でPRまで回す」ことと「判断が知識として貯まる」ことは、別々の機能ではなくひとつのループです。
さきほど紹介した判断ログも、vibecorp自身の開発をvibecorpで回す中で、各役職が実際に書き残したものです。
🧱 正直に言うと、設計はだいたい間違える（から記録する）
ここまで「判断を残す」と綺麗に書いてきましたが、実態は逆です。残す価値があるのは、判断がしょっちゅう間違うからです。vibecorp自身の開発でも、CTOが下した技術判断は何度もひっくり返っています。実際にログに残っている撤回の例を挙げます。
- 🐳 Docker隔離 → 撤回: 最初はコンテナで隔離する設計にしたが、重すぎた。より軽量な macOS の
sandbox-exec（Linuxはbwrap）へ転換。却下した代替案（Hyper-V / Firejail）も理由ごと記録。 - 🔍 Semgrep導入 → 不採用: 静的解析を入れようとしたが、現時点では過剰（YAGNI）と判断して見送り。
- 🤖 CodeRabbitの代替に自前OAuth案／別ツール → 却下: OAuthクォータ枯渇リスクと、AGPL-3.0のライセンス感染リスクを嫌って不採用。結局カスタム強化を選択。
ポイントは、これらが「失敗」として消えずに「却下理由ごと」knowledgeに残っていることです。
だから、次に誰か（人でもAIでも）が「Dockerで隔離すれば?」「Semgrep入れたら?」と言い出しても、議論は一からになりません。「それは前に検討して、こういう理由でやめた」と即座に返せる。
冒頭の「蒸し返し」問題への答えは、結局これに尽きます。間違いを前提にして、間違えた経緯ごと残す。 綺麗な正解だけを記録するメモではなく、紆余曲折のログだからこそ次に効く、というのが作ってみての実感です。
🛡️ 自動で動くけど、暴走はさせない
「Issueを渡すと自動でPRまで」と聞くと、暴走が心配になりますよね。
そこは構造で封じています。
- ⚠️ 認証・暗号・課金・ガードレールなど 6領域は自律実行の対象外
- 🚦 レビュー前のPR作成や未整合のpushを止める 必須フック（設定ファイルでも無効化できない）
- 💰 コスト上限はCFOが監査し、証跡を残す
自律で動かすからこそ、危ない操作には機械的なブレーキをかけています。
⚡ 試してみたい人へ
設計だけ持ち帰ってもらえれば十分ですが、実装をそのまま自分のリポジトリで試すこともできます。前提は Git / jq / GitHub CLI（gh）/ Claude Code、そして Claude Maxの定額プラン（APIキー不要）。
導入は実質2コマンドで、3段階のプリセット（デフォルトは minimal、まずはこれで十分）から選べます。手順とプリセットの詳細はREADMEにまとめてあります → hirokimry/vibecorp。
🎯 まとめ
この記事の要点は、ツールの紹介ではなく設計パターンです。一本につなぐと、こうなります。
AIへの指示が毎回その場限りで蒸し返される → だから「結論・根拠・却下案」を追記専用ログに残し、判断前に必ず読み戻す → ログが育ったら目次＋本体に分割する。 これだけで「蒸し返さないAI」の核は手元で再現できる。
押さえどころは3つです。
- 「何を決めたか」だけでなく 「なぜそうしたか・何を却下したか」 まで残すから、次の判断に効く（＝蒸し返さない）
- 「判断前に必ず読む」「追記専用」を、善意ではなく仕組み（hookやワークフロー）で強制する
- 知識は別作業ではなく、開発ループの中で自然に貯まる
AIに"仕事"を任せると判断は毎回消える。AIに"役職"を任せると判断が組織に残る。 vibecorpはその一実装にすぎず、設計そのものはどのAIコーディング環境にも持ち込めます。
🙏 おわりに
「AIに判断が積み上がらない」もどかしさを、役職を与えて知識として残すことで解こう──というのがvibecorpの出発点です。
「うちのAI運用ではこう困っている」「この設計はこう考えるべきでは」など、コメントでぜひ議論させてください。実装が気になった方は hirokimry/vibecorp も覗いてみてください。