Claude Code

複数の AI コーディングエージェントを使い分けるのは手間がかかる。その課題を解決するのが oh-my-openagent（omo） だ。Claude Code・OpenAI Codex・Gemini CLI といった主要エージェントを一元管理し、タスクに応じて最適なモデルへ自動ルーティングするオープンソースのハーネスで、GitHub スター数は 5.7 万超（2026 年 5 月時点）に達している。 oh-my-openagent とは oh-my-openagent は、もともと oh-my-opencode という名称で 2025 年 12 月に登場し、その後マルチエージェント対応を強化するかたちでリブランドされたツールだ。 作者: code-yeongyu 言語: TypeScript ライセンス: SUL-1.0 公式サイト: ohmyopenagent.com キャッチフレーズは「the best agent harness」。単一のエージェントに何でも任せるのではなく、専門化されたエージェント群がタスクを分担し、並列実行することで開発速度と品質を両立させる設計思想を持つ。 対応エージェントとプロバイダー oh-my-openagent は以下のエージェント・モデルプロバイダーに対応している。 プロバイダー 主なモデル Anthropic Claude Code（claude-opus-4-6 / 4-7 等） OpenAI Codex、GPT-5.5 Google Gemini CLI GitHub Copilot その他 Kimi K2、DeepSeek V4 等 インストール時に利用中のサブスクリプションプラン（Claude Pro/Max、ChatGPT Plus など）を選択することで、利用可能なプロバイダーのみを有効化できる。 主要機能 マルチモデルオーケストレーション タスクの種類ごとに最適なモデルを自動選択する「カテゴリベースのモデル割り当て」が核心機能だ。 visual-engineering（フロントエンド・UI 実装）→ Gemini ultrabrain（高難度なアーキテクチャ設計）→ Claude Opus 4.7 artistry（クリエイティブな文章生成）→ GPT-5.5 deep（深い推論・リサーチ）→ Claude Opus / Kimi K2 コスト最適化の観点から、大量ファイル生成のような作業は DeepSeek V4-Flash などの安価なモデルに自動振り分けされる。 ...

2026 年 3 月、Anthropic は Claude Code の思考深度（thinking effort）のデフォルト値を high から medium に静かに変更した。 リリースノートには目立つ記述がなく、多くの開発者は「最近 Claude の質が落ちた気がする」と感じながら原因を見つけられずにいた。 Claude Code の開発者である Boris Cherny 氏が Hacker News でこの変更を認め、その後 AI 開発者コミュニティで 15 の重要設定がまとめられて話題になった。 本記事ではそれらを日本語で解説する。 1. 思考深度（effort level）の復元 問題： 2026 年 3 月以降、デフォルトが medium に変更された。Claude の思考回数が減り、コードの質・ツール呼び出し数・コメントの充実度すべてが低下している。 修正方法： セッション内で一時的に変更する場合は /effort high、恒久的に変更する場合はシェル設定に追記する。 1 export CLAUDE_CODE_EFFORT_LEVEL=high 本格的なコーディング作業では high または max を設定することで、2026 年 2 月以前の品質に戻せる。 2. Adaptive thinking の無効化 問題： 2026 年 2 月以降、Claude はタスクの複雑さを自己判断して推論量を動的に調整するようになった。「簡単なタスク」と判断した場合はほぼ思考せず、バグを見逃すことがある。 ...

HubSpot は API 認証の選択肢が多く、「結局どれを使えばいいのか」が混乱しがちです。特に Claude Code から HubSpot を操作したい場合、現在は 6 種類の認証手段が併存しています: 非公開アプリ（Private App） 旧 API キー（廃止済み） MCP 認証アプリ（HubSpot 公式 MCP Server） パーソナルアクセスキー（Personal Access Key） 開発者 API キー（Developer API Key） サービスキー（Service Key、新規 Beta） この記事では、それぞれの違い・推奨用途・Claude Code から使う場合の選び方を整理します。なお旧 API Key は廃止済みですが、参考情報として記事末尾で触れます（実質的な選択肢は 6 つです）。 結論を先に言うと: 用途で 2 軸に分かれます。 アドホックに自然言語で操作したい（営業・マーケが Claude Code から HubSpot を触る等） → 公式 MCP サーバー 本番運用・バッチ・Webhook など継続的なシステム統合 → REST API 直叩き + Service Key（新規）/ Private App（既存） 両者は競合ではなく補完関係で、実務では併用するのが現実解です。 早見表 認証方式 用途 スコープ トークン寿命 状態 Claude Code から使うなら HubSpot MCP Server（公式） AI エージェントから HubSpot 操作 アプリと同等 OAuth ベース ✅ 2025-2026 リリース ✅ 最も推奨（1 行で接続） Service Key（新） システム間データ連携 アカウント単位の細かい権限 永続 ✅ 2026-02-10 Public Beta ✅ Private App の後継、新規ならこれ Private App 単一アカウント向け統合 アプリ単位で細かく設定 永続 ⚠️ 維持されているが、新規は Service Key 推奨 ✅ シンプルな REST 呼び出し OAuth 2.0（Public App） Marketplace アプリ・複数アカウント scope ベース access 30 分・refresh で更新 ✅ 公式・現役（v3 が新版） △ 自前で OAuth フロー実装が必要 Personal Access Key（PAK） HubSpot CLI 認証 アカウントごと 永続（rotate 可能） ✅ 現役 △ CLI 経由の操作のみ Developer API Key Developer Account 内のアプリ管理 開発者アカウント全体 永続 ✅ 現役 △ アプリ管理用、CRM データには不向き 旧 API Key（参考） 単純な API 呼び出し アカウント全体 永続 ❌ 2022-11-30 廃止 ❌ 使えない 各認証方式の詳細 ① 旧 API Key（廃止済み、参考情報） HubSpot ポータルの「Integrations → API Key」から発行できたアカウント単位の単一キー。 ...

個人開発アプリの認証は「絶対に」WorkOS を使え — MCP 化で知った最強の選択肢 では、WorkOS AuthKit の Dynamic Client Registration（DCR）対応が MCP 認証の決め手になる、という話を書いた。 MCP × OAuth 2.1 の全体像は MCP のセキュリティが OAuth 2.1 で大幅進化 で扱った。本記事はその中で SHOULD/MAY 扱いされている DCR を仕様レベルで深掘りする補足記事だ。 具体的には、DCR を定義する RFC 7591 そのものの仕様と、MCP 認証で必ず連動する周辺 RFC 群（9728 / 8414 / 9068 / 8707 / 7636）の関係 を、Claude Code の自動ログインフローを追いながら整理する。 この記事でわかること: なぜ事前登録なしにクライアントが認可サーバーに繋がってくるのか（RFC 7591 / 9728 / 8414 の連動） Claude Code の自動ログインフローを HTTP リクエスト単位で何が起きているか なぜ JWT の audience 検証で詰まるのか（RFC 9068 / 8707 と DCR の構造的な相性問題） なぜ MCP では Dynamic Client Registration（DCR）が必要なのか 従来の OAuth 2.0（RFC 6749）は、クライアント（アプリ）を事前に手動登録する 前提だった。Google や GitHub の OAuth を使うときに、開発者が「アプリを登録 → client_id と client_secret を発行 → コードに埋め込み」という流れだ。 ...

AIを使ったソフトウェア開発が急速に普及する中、「バイブコーディング」と「エージェンティックエンジニアリング」という2つのアプローチの境界線が曖昧になりつつある。Simon Willisonがこの問題を鋭く考察した記事が話題を呼んでいる。 バイブコーディングとエージェンティックエンジニアリングとは AI開発の文脈で、2種類のアプローチが対比されることが多い。 バイブコーディング（Vibe Coding） コードを深く読み込まず、AIの出力をそのまま使う開発スタイル。主に個人プロジェクトや試作品向けとされてきた。コードの内容を理解しなくても動くものが作れる、いわば「感覚」で進める手法だ。 エージェンティックエンジニアリング（Agentic Engineering） AIを強力なツールとして活用しつつ、プロのエンジニアが責任を持ってコードをレビューし、本番環境に耐えうるシステムを構築するアプローチ。品質・セキュリティ・保守性への意識が高い。 以前は「バイブコーディング＝個人・試作」「エージェンティックエンジニアリング＝本番」と明確に区別できた。しかし、AIの性能向上により、その境界線が揺らいでいる。 「もうコードを一行ずつ読まなくなった」という告白 Simon Willisonは自身の経験として、本番向けのコードでさえ、AIが書いたものを一行ずつレビューしなくなってきていると率直に認めている。 Willisonはこう述べる。Claude Codeに「JSON APIエンドポイントを作って」と頼めば、正しく実装してくれる——それはもう分かっている、と。 これは、大企業で別チームが開発した機能を、中身をほとんど確認せずそのまま使う感覚に近い。AIをある種のブラックボックスとして扱い始めているということを意味する。 人間のチームとの違いは「責任」にある。別チームの開発物には担当者がいて、問題が起きれば責任を取る人間が存在する。しかしAIには責任を取る能力がない。この非対称性が、Willisonに居心地の悪さを感じさせる根本的な理由だ。 AIの信頼が油断を生む 問題はさらに深い。AIが問題なくコードを書き続けることで「このAIは信頼できる」という過信が生まれる。そしていつか、本当は慎重であるべき場面でAIを過信して失敗するリスクが高まっていく。 また、AIの普及でソフトウェアの品質評価基準そのものも変化している。 従来: 充実したテストスイート、丁寧なドキュメント → 高品質の証明 現在: AIを使えばテストもドキュメントも数十分で完璧に揃えられる 見た目の完成度はもはや品質の指標にならない。代わりに価値を持ち始めたのは「実際に誰かが数週間・数ヶ月にわたって日常的に使っている」という実績だ。 開発プロセスの重心がシフトする @iwashi86 の整理によれば、AIによってコーディング速度が10倍（Willlison の元記事では「1日200行→2000行」）に跳ね上がったことで、従来のソフトウェア開発プロセス全体に変化が生じている。 コードを書くコストが劇的に下がったことで、失敗を恐れずに大胆なアーキテクチャ変更や仕様変更を試せるようになった。以前は実装コストが高すぎて試せなかったアイデアを、気軽にプロトタイプできる環境が整いつつある。 これはボトルネックを「実装」から「設計・判断・文脈理解」へとシフトさせることを意味する。 ソフトウェアエンジニアという職業の未来 Willisonは、AIが自動でコードを書く時代になってもソフトウェアエンジニアという職業は脅かされないと考えている。 その理由はシンプルだ：ソフトウェア開発はそもそも非常に困難な作業だから。AIはプロのエンジニアが持つ経験・判断力・文脈理解を増幅する道具にすぎない。AIを使いこなすためにこそ、深い専門知識が必要になる。 そして最終的には、企業も個人も「素人がAIで自作したシステム」より「プロがAIを駆使して作り上げた、実績のある製品」に対してお金を払いたいはずだ、とWillisonは結論づける。 まとめ Simon Willisonの考察は、AI開発ツールの急速な進化がエンジニアの「当たり前」を静かに書き換えていることを示唆している。 バイブコーディングとエージェンティックエンジニアリングの境界は、AIの性能向上とともに溶けつつある AIへの依存は「責任の所在」という根本的な問題を内包している ソフトウェアの品質指標は「見た目の完成度」から「実績・継続使用」へ移行しつつある 開発ボトルネックは「実装」から「設計・判断」へシフトしている それでもプロのエンジニアの価値はなくならない — AIはあくまで増幅器だ 元記事: Vibe Coding and Agentic Engineering Are Getting Closer Than I’d Like ツイート: @iwashi86

Anthropic のエンジニアとされる人物が Claude Code を使って Polymarket（予測市場プラットフォーム）向けの取引 bot を構築し、$200（約3万円）を $14,300（約200万円）に成長させたという事例が話題を集めている。ただし本人の公的な確認は取れておらず、複数の紹介ツイートも「伝えられるところによると」という留保を付けている点は注意が必要だ。 単純に取引回数を増やすのではなく、「勝てる場面だけを選ぶ」判断を AI に委ねるという設計思想が注目ポイントだ。 Polymarket とは Polymarket は分散型の予測市場プラットフォームで、政治・経済・スポーツなど様々なイベントの結果に対してポジションを取れる。各イベントの結果確率を市場参加者が売買することで価格が形成される仕組みになっている。 bot のアーキテクチャ このシステムは Claude Code をベースに、以下の3つの機能を組み合わせて動作する。 1. 大規模な取引データ分析 8,600万件の取引データを AI で分析 過去のパターンから「どういう取引が利益を出しやすいか」を学習 2. ウォレットランキング Polymarket の 14,000 以上のウォレットを数分でスキャン 各ウォレットの勝率・利益率を算出し、ランキング化 高勝率ウォレット（クジラ）が動いたタイミングを検出する 3. 厳選した取引実行 1日あたりわずか 10 回のみ取引を実行 勝率の高いクジラが動いた相乗りポジション、かつクジラより早く Exit（手仕舞い） 高確率の取引だけに絞ることでドローダウンを最小化 設計思想：「勝てる場面だけ選ぶ」 このシステムが興味深いのは、取引頻度ではなく取引品質を最大化している点だ。 多くのアルゴリズムトレードは「できるだけ多くの機会を捉える」方向に走りがちだが、このボットは逆の方針を選んでいる。 力技で数をこなす → 採用しない 「勝てる場面だけ選ぶ」判断を AI に任せる → 採用 1日10回という制約は、シグナルの質を落とさないための意図的な設計といえる。 Claude Code + Skills + MCP の連携 このような bot を実際に構築するには、Claude Code 単体ではなく、Skills や MCP（Model Context Protocol） を組み合わせた拡張が必要になる。Claude Code だけでは外部 API への接続や大規模データパイプラインを扱いきれないためだ。 ...

2026年Q1、Anthropicは3ヶ月間で120以上の機能をリリースした。これは18時間に1機能というペースであり、エンジニア1人あたり1日約5PRというアウトプットが確認されている。 なぜこれが可能なのか。@suthio_ による note記事「Anthropicの異次元の開発速度を支える7つの要因」が、その構造を詳細に分析している。@MLBear2 がX上で紹介し大きな注目を集めた内容を、本記事でまとめる。 7つの要因 1. AIがAIを作る再帰構造 Anthropic全社のコードベースの70〜90%はClaudeが書いており、Claude Code製品自体では約90%に達するとされる。ツールの改善がツール改善速度を加速させる自己強化ループが成立している。 このフライホイール構造により、「AIを使ってAIを改善する」サイクルが止まらない。開発速度は線形でなく、指数的に加速し続ける。 2. 未公開モデルへの先行アクセス Anthropicの社員は、公開前のモデル（Claude Mythosなど次世代モデル）をコスト制約なしで利用できる。これは世界中の開発者より数ヶ月先の能力を使って開発を進められることを意味する。 競合他社がAnthropicの公開済みモデルに合わせて開発している間、Anthropic自身はさらに数段階先のモデルで作業している。この非対称性は構造的な優位性を生む。 3. PRD廃止・プロトタイプ主義 仕様書（PRD）を書かない。代わりに、1機能あたり10〜20個のプロトタイプを数時間で作成し、実装したものを全社員に使わせてフィードバックを得る。 「考えてから作る」のではなく「作ってから考える」。このプロセスで、机上の設計では気づけないUX上の問題を早期に発見できる。 4. PMの仕事の変容 従来のPM（プロダクトマネージャー）の役割は「要件を定義する人」だった。Anthropicでは「大量のプロトタイプを評価する人」へと変わっている。 著者は「デザインプロセスは死んだ」という表現を使うほど、この転換は根本的なものだと指摘する。PMに求められるスキルセットは、仕様書を書く能力から、良いプロトタイプを見極めるセンスへとシフトしている。 5. 全員Builder文化 PM、デザイナー、法務担当まで、全員がAIツールを使ってコードに触れる。部門間の「人から人への引き継ぎ」がほぼ消滅した。 従来のソフトウェア開発では、PM→デザイン→エンジニアリング→QAというハンドオフが必ず存在し、そのたびに情報の欠落と時間のロスが生まれていた。全員がBuilderになることで、このボトルネックが根本から消える。 6. 1人で複数AIを並行操作 エンジニアが5〜10個のClaudeインスタンスを同時に動かし、役割分担させながら作業する。従来の「実装者」から「オーケストレーター」へという役割の変化だ。 Claude Codeの開発者であるBoris Cherny氏は1日20〜30件のPRを生成するという。業界標準が週1〜2件であることを考えると、桁違いのアウトプットになる。 7. 超高速フィードバックループ コードを変更すると、即座に社内全員が利用できる状態に自動デプロイされる。本番に近い環境でのフィードバックを数時間単位で得られるサイクルが確立されている。 「リリースが怖い」文化は存在しない。小さく素早く動かし続けることが前提となっている。 7つは独立していない——相互強化の構造 著者の重要な指摘は、これら7つが「独立した施策のリスト」ではないという点だ。 AIがコードを書くから、プロトタイプを大量に作れる 大量のプロトタイプが作れるから、PRDが不要になる 全員がBuilderになれるから、ハンドオフがなくなる 未公開モデルを使えるから、数ヶ月先の能力で開発できる これら7つは互いに強化し合うシステムであり、「一部だけ真似する」と効果が限定的になる。構造ごと変える必要がある、というのが著者の結論だ。 他の組織が今すぐ始められる3つの原則 もっとも、Anthropicのすべてを真似することは現実的ではない。未公開モデルへのアクセスや、AIがAIを作る再帰構造は、Anthropicならではの特権的な条件だ。 著者は「規模や業種を問わず始められる」として、次の3つを挙げている。 プロトタイプ・ファースト思考 — 仕様書を書く前に動くものを作る 自分たちで使い倒す（内部ドッグフーディング） — 作ったものを開発者自身が日常的に使う 全員がBuilderを目指す — 非エンジニアもAIツールでコードに触れる環境を作る これらはツールや予算の問題ではなく、思想と文化の問題であり、今日から変えられる。 セキュリティ領域での実績 記事内では、Claude Code SecurityやProject Glasswingといった取り組みにも触れている。AIを使って数十年間潜んでいたバグを検出した事例が紹介されており、「大量のコードを読んで異常を見つける」タイプのタスクではAIが人間を圧倒しつつあることが示されている。 まとめ Anthropicの開発速度の源泉は、単なる「AIツールの活用」ではない。AIが組織の全層に浸透し、相互に強化し合うシステムとして機能していることにある。 「なぜこんなに速いのか」という問いの答えは、7つの個別の施策ではなく、それらが織りなす構造にある。そして、その構造の一端は、どんな組織でも今日から取り入れ始めることができる。 参考リンク 元記事: Anthropicの異次元の開発速度を支える7つの要因（@suthio_） 紹介ツイート: @MLBear2 on X

中国在住のあるユーザーが、Claude Code を「従業員」として使い、数十の Instagram アカウントを 24 時間体制で自動管理することで月 3 万ドル超を稼いでいるという事例が SNS で注目を集めている。AI を使った収益化が「すでにゲームのルール」になりつつある現状を、この事例から読み解く。 Claude Code による Instagram 自動管理で月 3 万ドル超 AI インフルエンス・オペレーターを名乗る @Jouhatsu_ai が X（旧 Twitter）で紹介したこの事例では、Claude Code が以下の作業を自律的にこなしている。 数十の Instagram アカウントを 24 時間運用: 投稿スケジュール管理、コンテンツ生成、エンゲージメント対応 トレンドリサーチを常時実施: バズっている数百のアカウントを継続的にモニタリングし、流行を把握 退屈な反復作業を全自動化: ユーザー本人は実務から解放され、戦略立案やチェックに集中できる 本人は「AI にすべての面倒な作業を任せ、自分は一日中のんびりできる」と話しており、Claude Code が文字通り自律エージェントとして機能している様子が伝わる。 英語圏では月 1.5 万〜4.2 万ドルの受託案件も @Jouhatsu_ai の引用ツイートによれば、英語圏の Claude Code ヘビーユーザーはこうした AI 自動化システムを構築・運用することで、クライアントから 月 1 万 5,500〜4 万 2,000 ドル を請求しているという。 さらに「Anthropic がこのやり方を 30 分の公式コンテンツでほぼすべて説明している」とも言及しており、公式ドキュメントや事例を参照すれば再現性のある手法として学べることを示唆している。 Claude Code が自律エージェントとして機能する理由 Claude Code がこうした自動化ビジネスに適している背景には、いくつかの技術的特性がある。 長期タスクの継続実行 Claude Code はコマンドラインから起動し、ファイル操作・Web 検索・API 呼び出しなどを連続して実行できる。単発の質問応答に留まらず、複数ステップにわたる業務フローを自律的にこなす。 ...

Claude Code を使い続けると、トークン消費が積み重なってコストが気になってくる。X（旧 Twitter）ユーザーの @xiaoying_eth が、トークン消費を最大90%削減できる10のGitHubリポジトリをまとめて紹介している。本記事では出力フィルタリング・シンボル単位参照・プロンプト制御・MCP サーバーという4アプローチで各ツールを分類し、導入しやすいものから解説する。 1. RTK (Rust Token Killer) リポジトリ: rtk-ai/rtk コンテキストに流れ込む前にターミナル出力をフィルタリングするツール。よく使う開発コマンド（cargo build、npm test など）の冗長な出力を削減することで、60〜90% のトークン削減を実現する。Rust 製のため高速で、Claude Code の実際のコーディングセッションでの効果が大きい。 詳細は「RTK（Rust Token Killer）で Claude Code のトークン使用量を60〜90%削減する」を参照。 2. Context Mode リポジトリ: mksglu/context-mode Playwright や GitHub のツール出力を SQLite に転送し、クリーンな要約のみを Claude に送信するアプローチ。生のツール出力をそのままコンテキストに流さないことで 98% の削減を達成している。ブラウザ自動化や CI/CD 連携を多用するワークフローに特に有効。 3. code-review-graph リポジトリ: tirth8205/code-review-graph Tree-sitter を使ってローカルでコードリポジトリをナレッジグラフに変換するツール。ファイル全体を渡す代わりにグラフ構造で必要な情報だけを抽出するため、大型モノリポでは 49倍 のトークン削減が可能。コードレビューや依存関係の調査に向いている。 4. Token Savior リポジトリ: Mibayy/token-savior MCP サーバーとして動作し、ファイル全体ではなくシンボル単位（関数・クラス・変数）でコードを参照するツール。コードナビゲーション操作で 97% のトークン削減を達成。外部依存がゼロなので導入しやすい。 5. Caveman Claude リポジトリ: JuliusBrussee/caveman “原始人の口調” で Claude に話させることで出力トークンを削減するユニークなアプローチ。技術的な正確性は維持しつつ、出力を 65〜75% 削減できる。プロンプトエンジニアリングによる出力スタイルの制御という発想が面白い。 詳細は「Claude を「原始人」口調にするとトークンが 80% 減る話」を参照。 ...

2026年5月、SNSで注目を集めた一本のポストがある。会社員として働きながらAI×SNS副業で月30万円を達成したエンジニア・おさぼり（@1osabori）氏が「英語圏のClaude Codeガチ勢がクライアントから月50万〜200万取ってる手法、Anthropic公式が30分でほぼ全部喋っちゃう」と発信した。そのポストは83万インプレッションを超えた。 この記事では、Anthropicが公式に公開しているドキュメントとガイドをもとに、英語圏のフリーランサーたちが実践している具体的なテクニックを解説する。 なぜ日本人が知らないのか 英語圏では Claude Code を活用した高単価フリーランスという働き方が急速に広まっている。Anthropicは「How Anthropic teams use Claude Code」という公式ドキュメントや「Best practices for Claude Code」で、社内エンジニアが実際に使っているワークフローを詳細に公開している。 しかしこれらのコンテンツはすべて英語で書かれており、日本語圏には届いていない。おさぼり氏が「日本人で知ってる人1%もおらん」と指摘するとおり、この情報格差が収益格差に直結している。 テクニック1: 計画先行ワークフロー（Plan-First Approach） Anthropicエンジニアが最も強調するのが「実装より前に計画を立てる」という原則だ。 Claude Code には plan モード（Shift+Tab を2回押して切り替え）があり、このモードでClaudeはコードを書かずに計画だけを提案する。 # プロンプト例 「まずコードには触れずに、このAPIの認証機能をどう実装するか 設計案を提示してください」 実装と探索を分離することで「間違った問題を解決する」リスクを排除できる。一度のプロンプトで複雑なタスクを丸ごと投げるのではなく、ステップバイステップで進めることが品質の鍵だと公式ドキュメントは述べている。 テクニック2: 並列エージェントパターン 英語圏の高単価エンジニアが特に活用しているのが「複数のClaude Codeセッションを同時に立ち上げて並列で動かす」手法だ。 Anthropicの社内実践として紹介されているのは以下のようなパターンだ。 エージェント1: スタイルガイドの確認 エージェント2: プロジェクト履歴のレビュー エージェント3: バグのフラグ立て エージェント4〜8: 元の発見の検証 一人のエンジニアが複数のClaudeインスタンスを「チーム」として運用することで、従来は複数人が必要だったコードレビューや品質保証を一人でこなせるようになる。これがクライアントから高い報酬を得られる直接の理由だ。 テクニック3: ストップフックによる自動化 Stop Hooksは、Claudeがタスクを完了したときに自動でアクションを実行する仕組みだ。 settings.json の設定例: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 { "hooks": { "Stop": [ { "matcher": "", "hooks": [ { "type": "command", "command": "npm test && npm run lint" } ] } ] } } Claudeがコードを書き終わると自動でテストが実行され、失敗があればClaudeが修正する。このサイクルを人間が介在せずに回すことで、Anthropicエンジニアは「2〜3倍の品質向上」を報告している（プロジェクトによって異なる）。なお npm test の部分は実際のプロジェクト構成に合わせて変更すること。 ...