10. Hermes / PMO AIPC | 工程別ドキュメント運用ガイド

主な読者: PMSEPG

第10章の結論

Hermes は別章で管理するのが妥当です。理由は、実装支援ツールではなく「常時稼働・記憶・Skill蓄積・MCP公開・セキュリティ境界」を含む運用設計だからです。本文では PMO AIPC としての限定採用に絞り、開発 PC 直置きや Cursor LLM 透明中継の期待を明示的に退けます。

採用前提: 本章は導入決定ではない。セキュアゾーン要件、MCP allowlist、監査ログ、モデル標準、責任者を ADR で確定するまで UNRESOLVED 扱い。

客観評価 — Hermes を別章化すべきか

査読結果（2026-06-22時点）
観点	評価	根拠
章独立性	別章化が妥当	実装、運用、インフラ、PMO ガバナンスを横断し、単なるツール紹介より導入判断の比重が大きい。
現状資料の強み	高	「Cursor/Codex の代替ではない」「開発 PC 直置き非推奨」「MCP allowlist」「draft/approved」を明確にしており、過剰期待を抑えられている。
現状資料の弱み	中	同じ説明が第4章・第6章・第17章相当に分散し、読者が採用条件・未決・導入順を一読で追いにくい。
情報鮮度リスク	高	Hermes Agent は更新が速い。資料には「調査日」「採用時の再確認」「ADR 化」を必ず残す必要がある。
推奨採用段階	限定 PoC 後	最初は bonus_kit / Agent-native CI/CD の eval 整備を優先。Hermes 常時稼働はガバナンス・インフラ審査後。

判定: Hermes は独立章にし、既存章には要約とリンクを残す。採用判断は「PMO AIPC として限定利用」「開発 PC 直置き禁止」「人間 approved 昇格」の3条件を満たす場合に限る。

PMO AIPC — 社内ノウハウ蓄積地（Hermes + Ollama · MCP Server）

PMO AIPC とは、別インスタンスや別 PC という一般論ではなく、セキュリティの担保が取れた社内エリアに置く Hermes Agent + Ollama を内包した MCP Server のことです。役割は 社内ノウハウの蓄積地 — 手順・観点・Skill・失敗パターン・プロンプト型を組織で共有・再利用すること。開発・作業 PC（Cursor / Codex）は MCP Client として参照・依頼するだけに留め、ソースや本番鍵は載せません。

定義 — 3層の置き場所
場所	本体	役割	載せないもの
開発・作業 PC	Cursor · Codex · Git	実装 · 敵対的レビュー · リポジトリ正本	常時稼働 Hermes ダイモン（非推奨）
PMO AIPC	MCP Server（Hermes + Ollama）	社内ノウハウ蓄積地 — 検索 · 整形 · draft 登録 · 振り返り	ソースツリー · 本番 API 鍵 · 顧客機密の恒久保存
Git 正本	`.agents/skills/` · SOP · REQ	approved 昇格後の正式版 Skill・手順	draft のまま正本化しない

蓄積してよいもの · してはいけないもの

PMO AIPC に蓄積 OK	蓄積 NG（第13章 · ガバナンス）
approved / draft Skill（手順・観点・抽象ルール）	顧客名 · 個人情報 · 本番接続情報
Cursor / Codex 用プロンプト型（テンプレ）	ソースコード全文 · 未公開仕様の詳細
抽象化した失敗パターン · lessons-learned	API キー · 社内 URL（生）· 見積原価
レビュー観点チェックリスト · Runbook型	マスキング前のログダンプ

MCP Server として公開するツール例（allowlist）

search_skill / get_template — 今回タスクに必要なノウハウだけ返す（Cursor 全 Rules 読み込み削減）
format_cursor_prompt — 雑な依頼 → 背景/範囲/禁止/完了条件付き指示
format_codex_review — レビュー観点リスト生成
submit_lesson_draft — 作業後の振り返りを draft Skill として登録（人間 approved 後 Git へ）

Hermes の位置づけ（社内調査 2026-06-22）: Cursor/Codex の代替ではなく、その前後の整流・記憶レイヤー。Cursor 契約内 LLM を Hermes が透明中継する構成は現実的でない — 開発 PC の LLM と AIPC の Ollama は別経路。

メリット · デメリット · 注意

観点	メリット	デメリット · 注意
セキュリティ	ノウハウサーバをセキュアゾーンに閉じ、開発 PC からは MCP のみ。blast radius 分離	MCP ツール定義が広いと再び全権限化。allowlist 必須
理念	「個人のプロンプト」→組織の蓄積地。属人化・再発防止に直結	蓄積地をゴミ箱にしない — `draft/approved/deprecated` と月次棚卸し
標準化	同じレビュー観点 · 同じ指示型を全員が MCP 経由で取得	誤 Skill が自信を持って再適用 — approved 前は Git 正本にしない
効率	Cursor へ 1〜2 ページに圧縮した指示を返せる	Ollama 軽量モデル alone では長文整形が弱い — 用途限定
運用	PMO/インフラが1台のノウハウサーバをオーナーしやすい	オーナー不在 · 可用性設計なしは導入禁止。停止時も Cursor 単体で開発可

最小 Phase: (1) MCP format_cursor_prompt (2) format_codex_review (3) submit_lesson_draft → PMO が approved → Git .agents/skills/ へ。

UNRESOLVED: セキュアゾーンのネットワーク要件 · MCP Server 実装（Hermes 同梱 vs 薄いラッパー）· Ollama モデル標準 — ADR 化待ち。

参考: Hermes Agent · Ollama × Hermes

長期記憶 — Hermes 内蔵 vs Memanto 等（2026-06 評価）

AIエージェントの「忘却」は性能不足ではなく長期文脈の欠如として扱う。Hermes は記憶を持つエージェント基盤、Memanto 等は構造化・共有・外部化の候補（採用は PoC 後 · UNRESOLVED）。

出典: Zenn — Memanto × Hermes Agent 長期記憶 · 正本 MD: references/hermes_memanto_memory_evaluation.md

結論（3行）

Hermes 内蔵メモリ — 個人・Hermes 中心なら十分な場合が多い（Step 1 個人検証）
Memanto / Mem0 / Supermemory 等 — Cursor/Codex 横断・チーム共有が必要なら候補。PMO AIPC と役割を分離して設計
社内原則 — 「AIが勝手に覚える」ではなく人間承認済み文脈レジストリ。Git 正本（REQ/ADR/Skill）の代替にしない

Hermes 内蔵 vs 外部 Memory Provider

役割分担（Memanto 採用は未決）
観点	Hermes 内蔵	Memanto 等（候補）
位置づけ	Hermes 自身の記憶	複数エージェント・IDE 横断の外部 Provider
向く用途	個人継続作業 · Skills 化	チーム · チケットインタビュー内容の recall · 却下理由共有
注意	Hermes 外から参照しにくい	権限 · 同期 · 棚卸し · 監査ログ設計が必須

Cursor / Codex / Cline / Roo
        ↓ MCP Client
   PMO AIPC（Hermes + Ollama · 組織ノウハウ）
        ↓ 必要時のみ
  Memory Provider 候補（Memanto / Mem0 / …）— PoC 比較 · UNRESOLVED

記憶ランク · PMO AIPC との対応

ランク	内容	AIの扱い	PMO AIPC
A	正式決定（ADR · 承認済み仕様）	強く従う	`approved` → Git 正本へ
B	作業中前提（仮方針）	参照するが確認	`draft`
C	個人メモ · 好み	参考程度	個人 Hermes のみ推奨
D	破棄済み（却下案 · 古い仕様）	原則使わない（再提案防止に残す）	`deprecated`

責務分担（記憶は正本の代替ではない）

管理対象	役割
チケット	作業単位 · 進捗 · 完了条件
ADR / REQ	設計判断 · 採用/却下理由
Git	実装差分 · レビュー履歴
長期記憶	AI が次回 recall する承認済み文脈（索引）

AIチケット起点開発ループとの接続

インタビュー → 人間承認 → チケット/ADR/Git 正本 → 承認済みのみ長期記憶へ。実装時は recall → 関連 REQ/ADR 提示 → 正式文書確認 → 実装。完了時に棚卸し（新規教訓 · 廃止前提 · Dランク却下理由）。

セキュリティ · 運用上の注意

ローカル完結 ≠ 安全 — DB・Docker ボリューム · PC 紛失 · 別案件誤参照のリスクは残る
メモリ汚染 — 仮説を正式決定として保存しない · プロジェクト単位で分離
ベンチマーク過信禁止 — LongMemEval 等は業務安全性を保証しない
棚卸し — チケット完了 · リリース前 · 仕様変更 · 月次

UNRESOLVED: Memanto 等の採用可否 · MCP 連携方式 · PMO AIPC とのデータ境界 · 監査ログ標準 — ADR 化待ち。Step 1（Hermes 内蔵個人検証）→ Step 2（チケットループ接続）までを先に。