AIツール5件 効率厨verdict 2026-06-28 — 永続メモリ・仕様書ファースト・PPT生成・Claude代替(罠)・フィルター除去(罠)

今日の判定サマリ

ツール	verdict	一言
cognee	🟡	routine管理が限界になったタイミングで評価
OpenSpec	🟡	solo開発には重い。要件定義フェーズで再評価
ppt-master	🟡	英語文書でまずテスト、日本語品質は未確認
opencode	🚫	MAX定額→従量課金への乗り換えはコスト逆行
Open-Generative-AI	🚫	フィルター除去系はリスクを丸ごと引き受ける

---

🟡 cognee（topoteretes/cognee）— Claude Code専用プラグインで会話横断の永続メモリ構築

今やること: いまは入れない。routine管理が限界になったタイミングで評価リストに追加する。

Claude Code の会話をまたいで記憶を持続させるプラグイン。会話ごとに CLAUDE.md や memory/ フォルダへ手動でコンテキストを引き継ぐ手間を自動化できる可能性がある。

効率厨視点: 現状の memory/ フォルダ + CLAUDE.md の手動引き継ぎで管理できているうちは導入コストが見合わない。cognee は Supabase または Neo4j などのグラフ DB インフラが別途必要で、セットアップと維持コストがある。「CLAUDE.md が 3000 行を超えた」「routine ごとにコンテキスト再構成に 10 分かかる」といった限界サインが出てから評価する。今日のアクションではない。

🟡 = 将来評価対象。今すぐ導入するにはインフラコストが不釣り合い。

---

🟡 OpenSpec（Fission-AI/OpenSpec）— 仕様書ファースト(SDD)でAIと構造的に協業するフレームワーク

今やること: solo 開発なら保留。複数人開発または要件定義フェーズに入ったタイミングで再評価。

SDD（Software Design Document）ファーストで AI と協業する構造を提供する。変更のたびに /opsx:propose → 仕様確認 → /opsx:apply の流れを踏むことで、静的な CLAUDE.md と違い変更理由を後から追えるようになる。

効率厨視点: solo 開発で回している分には、このプロセスを挟むオーバーヘッドが仕様管理のメリットを上回りやすい。CLAUDE.md + Skills + routine の現行設計でまだ追いきれている範囲では導入メリットが薄い。一方、外注や共同開発でレビュアーが「なぜこの設計にしたか」を後追いで確認する必要が出てきたタイミングでは刺さる。設計の「なぜ」を残す習慣は良いが、ツールで強制するのは人数が増えてからでいい。

🟡 = 現状 solo なら保留。共同開発・要件定義フェーズで再評価推奨。

---

🟡 ppt-master（hugohe3/ppt-master）— Claude CodeからPDF/ドキュメント→ネイティブ編集可能PowerPoint生成

今やること: 英語ドキュメントを 1 件 PowerPoint に変換してレイアウト崩れを確認する。

PDF やドキュメントから、後から PowerPoint で編集できるネイティブ形式のスライドを生成する。Claude Code MAX 定額内で動くため追加費用なしで試せる。docs 配下の HTML や Markdown を商談スライドに変換するユースケースが具体的に想定できる。

効率厨視点: 日本語ドキュメントへの対応品質が未確認なのでいきなり本番運用は危ない。まず英語の技術仕様書やリリースノートで変換精度を確認し、レイアウト崩れや図表の再現性を見てから日本語対応を評価する順番が正しい。MAX 定額内で追加費用ゼロという点は試すハードルを下げる要因として評価できる。PowerPoint 出力が必要な場面（顧客向け提案、社内報告）が月 1 件以上あるなら試す価値がある。

🟡 = 英語ドキュメントでまずテスト推奨。日本語品質は確認が必要。

---

🚫 opencode（anomalyco/opencode）— 75+プロバイダー対応オープンソースClaude Code代替

使わない。Claude Code MAX の定額構造から外れる時点でコスト設計が逆行する。

GitHub で 179k stars のオープンソース Claude Code 代替。75 以上のプロバイダーに対応し、マルチモデルで使える。stars 数だけ見ると魅力的に映るが、構造的な問題がある。

効率厨視点（使わない理由・2 つ）:

1. MAX 定額→API 従量課金への乗り換えになる: Claude Code MAX の月額定額から、API コールごとに課金される構造に移行することになる。ヘビーユーズするほどコストが青天井になり、定額の安心感が消える。
2. hooks / routines / Skills / CLAUDE.md の再設計コストが不釣り合い: 現行の Claude Code 向けに設計された CLAUDE.md、Skills、hook、routine の設定資産がすべて移植コストになる。stars が多い＝自分の設計と合う、ではない。

「スター数 = 優れたツール」という判断はプロバイダー変更コストを見落とす。今の設計でまだ MAX 定額内で回せている間は切り替えるメリットがない。

---

🚫 Open-Generative-AI（Anil-matcha/Open-Generative-AI）— コンテンツフィルター除去系の無制限AI生成スタジオ

使わない。リスクの引き受け方がワークフローに合わない。

200 以上のモデルを無制限で使えると謳う AI 生成スタジオ。コンテンツフィルター除去が主な差別化ポイント。

効率厨視点（使わない理由・3 つ）:

1. TOS/著作権/倫理リスクを一身に引き受ける: フィルター除去とは、プロバイダーが意図的に制限した境界を外すということ。生成物の責任が自分に集中する構造になる。
2. 収益モデルが不透明: 200 以上のモデルを無制限で無料提供する収益モデルが見えない。サービス継続性のリスクと、データ扱いへの疑問がある。
3. 実務ユースケースが今の設計にない: 工務店向け資料や SNS 投稿の生成には既存の Claude MAX フローで十分。フィルター除去が必要な場面が今の業務設計には存在しない。

フィルター除去系は「できる」と「やっていい」を混同させる作りになっている。判断軸は「自分のワークフローにこのリスクを組み込む価値があるか」。今はない。

---