最新AIツール4件 効率厨verdict 2026-08-15 — Claude Code v2.1.233・spec-kit・Opus 5 effort dial

今日の判定サマリ

ツール	verdict	一言
Claude Code v2.1.233	🟢	task ツール deprecated。CLAUDE_CODE_ENABLE_TODO_TOOLS=1 を今日追加しないと routine が止まる
github/spec-kit	🟢	Spec-Driven Development。spec init → spec scaffold で仕様駆動フローを即導入
holaboss-ai/holaOS	🟡	100+統合・MCP・共有メモリ。今のスタックで完結している間は不要
Claude Opus 5 effort dial	🟡	per-request 重み設定（low/medium/high）。軽量タスクに effort:low で速度比較を試す価値あり

---

🟢 Claude Code v2.1.233 — TaskCreate 等 task ツール deprecated（CLAUDE_CODE_ENABLE_TODO_TOOLS=1 が必要）

今日やること: claude update → .env または環境変数に CLAUDE_CODE_ENABLE_TODO_TOOLS=1 を追加 → routine を手動実行して動作確認。

v2.1.233 の最重要変更は TaskCreate・TaskGet・TaskList 等のタスクツールが deprecated になった点。旧 API を使い続けると動作が不安定になる。継続して使うには CLAUDE_CODE_ENABLE_TODO_TOOLS=1 環境変数の明示追加が必要。

自動化 routine への影響: SNS automation や content-executor のような routine で TaskCreate 系を呼んでいる場合、今日 update せずに放置すると次回実行時にエラーが出る可能性がある。routine のログを確認して、task ツール呼び出しがある箇所は優先的に対応する。

その他の変更:

• WebFetch TTL 制御が追加（キャッシュ挙動の細かい制御が可能に）
• Skill 引数バグ修正（Skill に引数を渡す際の不具合が解消）

効率厨視点: task ツール deprecated は「知らずに放置→routine 停止」のリスクが高い。今日 update → 環境変数追加 → 動作確認の3ステップが最短のリスク消去。WebFetch TTL と Skill バグ修正は副次的な恩恵として受け取れる。

---

🟢 github/spec-kit (128K★) — Claude Code対応 Spec-Driven Development toolkit

今日やること: npx spec-kit init をリポジトリで実行して READMEの構造化フローを3分確認。自分の開発スタックに組み込めるか判断する。

GitHub 公式の Spec-Driven Development toolkit。spec init で仕様テンプレートをリポジトリに生成、spec scaffold で設計から実装骨格を自動生成する Claude Code 対応フロー。128K★ は急上昇の証拠。

vibe-coding 脱却の具体的な設計: 「とりあえず作る → 後でリファクタ」型の vibe-coding から脱却して、仕様ファースト・テストファーストで開発を進める体制を作るツール。CLAUDE.md や Skills に組み込むと、Claude Code に「まず仕様を書いてから実装する」フローを強制できる。

masatoman.net / sns-automation への適合: 新機能追加時に spec scaffold で骨格を生成 → CLAUDE.md の「コード書く前に仕様を確認する」原則と組み合わせると、AI への任せ方の設計精度が上がる。routine に「spec定義ステップ」を追加するとドキュメントが自動で揃う副作用もある。

効率厨視点: 128K★ かつ Claude Code 直連携は今年のトレンドの中でも質が高い候補。vibe-coding で後から詰まった経験が一度でもあれば、今日3分で init して試す価値がある。「仕様を書かずに進めて後悔」パターンの再発防止に直結する。

---

🟡 holaboss-ai/holaOS — Claude Code 対応 AI エージェントワークスペース（7.3K★）

100以上のサービス統合 + MCP サポート + 共有エージェントメモリを一つのワークスペースに集約した Claude Code 対応環境。マルチエージェント並走・クロスセッション共有が設計の核心。

何ができるか:

• 100+ の外部サービス統合（Slack・Notion・GitHub 等）を統一インターフェースで操作
• MCP プロトコルを通じて Claude Code エージェントが共有メモリ・状態を持てる
• 複数エージェントが並走する際のコーディネーション機能

効率厨視点: 今のスタック（masatoman.net + sns-automation + Supabase）で完結している間は導入コストがメリットを上回る。100+ 統合が魅力に見えるが、「今使っていないサービスの統合を増やす」のは管理コスト増。

再評価タイミング: 「複数エージェントが並走して状態を共有する必要が出てきた」「MCP でクロスセッション連携を設計したい」という具体的な詰まりが発生した時点で評価する。今は「こういうカテゴリが存在する」という認識で記録。

---

🟡 Claude Opus 5 — per-request effort dial（low / medium / high / xhigh / max）

Claude Opus 5 が導入した per-request の推論重み設定。effort: "low" から effort: "max" まで5段階で、リクエストごとに推論コスト・速度のトレードオフを制御できる。

Workflow agent との直結: Claude Code の Workflow agent では agent() 呼び出しに opts.effort を指定できる。

agent("軽量な要約タスク", { effort: "low" })
agent("コード設計の判断", { effort: "high" })

機械的な変換・フォーマット整形・ラベル付け等の軽量タスクに effort: low を設定すると、同じ品質を維持しながら速度が改善する可能性がある。

現在の routine への適用: content-executor のような日次自動化 routine で、frontmatter 整形・誇張 grep・lint チェック等の定型処理は effort: low 候補。一方、記事の publish-gate 判定・記事本文執筆は effort: high 以上が適切。

効率厨視点: 既存 routine を手元で確認して、明らかに軽量な agent 呼び出し（grep 結果の解釈、単純な変換）に effort: low を試験的に設定する。速度比較は次回実行時のログで確認できる。設定コストは低く、改善の可能性がある分、記録しておく価値はある。

---