メインコンテンツへスキップ
← 記事一覧に戻る
·運用·7 min read

AIツール5件 2026-07-12 — Claude Code Week 28内蔵ブラウザ・/doctor・superpowers

Claude CodeAIツール効率化キュレーションWeek 28

今日の判定サマリ

ツール / トピックverdict一言
Claude Code 内蔵ブラウザ (Week 28)🟢今日から使える・画面切り替え消える
Claude Code /doctor (Week 28)🟢routine壊れたら最初に叩くコマンド
obra/superpowers🟡Skills設計の参照用・今は乗り換え不要
davila7/claude-code-templates🟡既存設定との競合確認が先
「AI生産性46%向上」統計🚫体験ベースブログへの転用で信頼を失う

🟢 Claude Code 内蔵ブラウザ (Week 28 / v2.1.202-206) — セッション内にブラウザが入った

今日やること: Claude Code を最新版に更新して内蔵ブラウザを確認する。

Week 28 アップデートで、Claude Code のセッション内からブラウザを開いて外部ページを参照できるようになった。GSCのデータ確認、ドキュメント参照、競合記事の確認——これまでターミナルとブラウザを往復していた作業がセッション内で完結する。

なぜ即採用か: 記事執筆ルーティンで「調査→執筆」のコンテキストスイッチが一番時間を食う。調べるたびにブラウザを開いて戻ってくる動作が消えれば、Claude Code上でのフロー状態が維持できる。セットアップ不要・アップデートするだけで使える点も評価が高い。

料金変化なし、設定変更なし、今すぐ使える。見送る理由がない。


🟢 Claude Code /doctor — セットアップ診断コマンド (Week 28)

今日やること: /doctor をターミナルで叩いて現状確認する。

MCP接続の失敗、hookが発火しない、routineが途中で詰まる——これらの原因究明に今まで時間がかかっていた。/doctorはClaude Codeの設定状態を診断し、問題があれば修正候補を出す専用コマンド。

判断の根拠: content-executor や sns-automation など複数のroutineを運用していると、「どのMCPが死んでいるか」「どのhookが設定ミスか」を手動で切り分けるのに20〜30分かかることがある。それが1コマンドで済むなら即採用。問題がなくても「問題なし」が確認できること自体に価値がある。

routine運用中の人なら今すぐ /doctor を一度叩いておくことを勧める。


🟡 obra/superpowers (+740★) — エージェント型スキルフレームワーク

Claude Code Skillsと同じ問題意識——「頻出タスクをスキル化してエージェントに任せる」——を別アーキテクチャで実装したフレームワーク。1日で740スターを獲得したことから、同じ課題を感じている開発者が多いことが分かる。

なぜ今すぐ乗り換えないか:

  • 現時点でClaude Code公式のSkillsエコシステムが成熟してきており、npx skills addの体験が安定している
  • superpowersはまだ設計段階のものが多く、実運用実績が少ない
  • 乗り換えコスト(既存スキルの移行・検証)が読めない

🟡 = Skillsの設計を見直すタイミング、または公式Skillsに限界を感じたときに参照。スターしておく価値はある。


🟡 davila7/claude-code-templates (+232★) — CLAUDE.md/Skillsテンプレート集

CLAUDE.md・Skills・routineのスターターテンプレート集。Claude Codeを始めたばかりの人には有用で、232スターが示すように需要は実在する。

今すぐ入れない理由(既存ユーザー向け):

  1. 既存カスタマイズとの競合リスク: すでにCLAUDE.mdやSkillsを独自に整備している場合、テンプレートを後から入れると設定が上書きされる可能性がある。diffを確認してから採用するかどうかを判断する必要がある
  2. テンプレートは出発点: 汎用テンプレートより、自分のスタック・routineに合わせた設定のほうが最終的に効く

🟡 = 新規セットアップ時または設定の棚卸しタイミングで参照。中身を読んで採用箇所を選ぶ使い方が正しい。


🚫 「AI生産性46%向上」統計 — 体験ベースブログへの転用は逆効果

外部の調査レポートがはじき出した「AI導入で生産性46%向上」という数字を記事に引用したくなる気持ちは分かる。だがmasatoman.netのポジションから見ると、これは罠になる。

なぜ使ってはいけないか:

  • 実態との乖離が大きい: 調査報告では実際の改善幅と測定方法に疑問が残る項目が含まれており、数字を鵜呑みにすると読者の実体験と大きくズレる
  • 体験ベースブログの信頼を壊す: masatoman.netは「実際に組んで動かした実験ログ」として差別化している。一次情報なしの統計引用は「他の数字マーケサイトと同じ」になる
  • 読者が同じ数字を見ている: Claude Code/Cursor を日常使いする読者はリテラシーが高い。根拠薄い数字を出すと信頼が落ちる

判断軸: 自分が実際に計測した数字以外は引用しない。「作業時間が30分から10分になった」のような具体的な自分の体験を書く。抽象的な「46%向上」より、具体的な「この作業が20分短縮した」のほうが読者に刺さる。


masatoman のメルマガ — 毎週月曜の朝に手紙を 1 通

masatoman.net の今週の記事 1 本を、読者目線で深掘りした手紙が毎週月曜 9:00 に届きます。「これ自分のことだ」が見つかる予告編。登録特典に「個人開発の収益化チェックリスト 15 項目」。

masatoman のメルマガ — 毎週月曜の朝に 1 通

masatoman.net で今週公開した記事の中から 1 本を、読者目線で深掘りした手紙が届きます。「自分も同じことやってる」「ここで詰まってた」が見つかる予告編。

シェア

コメント

投稿にはログインが必要です(メールアドレスのみ・パスワード不要)。入力内容は保持され、ログイン後そのまま投稿されます。