開発・レビュー・QA・セキュリティ・業務確認を役割別AIに任せ、人間は判断と承認に集中する。Claude CodeのSubagentを会社で使うための準備から運用まで、金融系プロジェクトを例に整理する。
Claude CodeのSubagentとは、開発担当・レビュー担当・QA担当・セキュリティ担当といった役割別の専門AIを、一つのプロジェクト内で使い分けられる仕組みのことだ。ChatGPTやClaudeのチャット画面で質問する使い方とは異なり、それぞれのAIが自分の担当範囲だけに集中する形で動く。
これは「AIが人間の代わりに全部やってくれる」仕組みではない。基本は人間が司令塔になり、工程ごとに適切な専門AIへタスクを振る運用だ。AIは調査、整理、実装補助、レビュー観点、異常系の洗い出し、テスト観点、ドキュメント作成を担い、人間は最終判断・承認・優先順位・リスク許容・社内外調整に集中する。
決済・残高・取引・管理画面・監査ログが絡む金融系プロジェクトは、実装だけでなく仕様整理・権限設計・QA・法務確認まで重い。このような案件こそ、役割別AIを工程に組み込む価値が大きい。6人程度のチームでも、AIをうまく使えば擬似的に10〜15人分の専門スタッフを持つような働き方に近づける。
まず混同しやすい概念を整理しておく。Claude Teamプランは、会社や組織としてClaudeを契約・管理するための仕組みだ。メンバーの招待、権限設定、利用範囲の管理、請求の一本化などが含まれる。2026年時点では月額約30ドル/ユーザー（年払い）が目安で、5〜150人規模の組織向けに設計されている（料金や仕様は変更される可能性があるため、最新の公式サイトを確認すること）。
一方、Subagentは、Claude Code内で使う役割別の専門AIのことだ。「誰がClaudeを使えるか」を管理するのがTeamプランで、「そのClaudeにどんな役割を持たせるか」がSubagentの話になる。
会社利用では、Teamプランでメンバーを管理しながら、共有ProjectでAIに与える前提知識をそろえ、Claude CodeとGitHubで開発プロセスに組み込む構成が現実的だ。
会社でClaude CodeとSubagentを使う場合、以下の5つの層を整えると動かしやすい。 【Claude Team】 会社としてClaudeを契約・管理する。メンバー招待、権限、利用範囲を一元管理する。 【Claude Project（共有）】 プロジェクト概要、用語集、仕様、業務フロー、決定ログ、AI利用ルールを入れる。メンバー全員が同じ前提でClaudeに相談できるようにする土台になる。 【GitHub】 Issue・Pull Request・レビュー・履歴管理の中心に置く。Claude Codeによる実装やレビューも、GitHub上のPR単位で人間が確認する。 【Claude Code】 各メンバーのローカル環境、または開発環境で使う。リポジトリ内のCLAUDE.mdや.claude/agents/を読み込ませ、チーム共通ルールで動かす。 【Subagent】 developer、code-reviewer、qa-tester、security-reviewer、db-reviewerなど、役割別AIとして.claude/agents/配下のmarkdownファイルで定義する。
チームで使い始める前に、会社側として以下を整える必要がある。 ・Claude Teamなど会社で利用可能なClaude環境を用意する ・管理者を決める（Anthropicとの契約窓口、社内ルール策定責任者） ・利用対象メンバーを決める ・会社メールで招待する ・メンバーごとの権限を決める（Claude Code利用者とチャット中心利用者を分けるとよい） ・共有Projectを作成し、入れてよい情報・入れてはいけない情報のルールを決める ・GitHubリポジトリへのアクセス権限を整理する ・AI利用ルールを社内で合意する
特に「Projectに入れてよい情報・入れてはいけない情報」の線引きは早めに決めておくことが重要だ。後述の「AIに入れてよい情報・入れてはいけない情報」の節も参照してほしい。
6人チームを例に、役割ごとの準備と使い方を整理する。 ■ PM / PdM 準備：Claude Teamへの参加、共有Projectへのアクセス、プロジェクト概要・スコープ・未決事項の整理、議事録・決定ログ管理ルール、GitHub Issueの起票ルール 使い方：要件整理、論点整理、仕様ドラフト作成、ステークホルダー説明資料、Issueの分解、受入条件の作成 ■ テックリード 準備：Claude Codeの利用環境、GitHubリポジトリへのアクセス、CLAUDE.mdと.claude/agents/の整備、ブランチ・PR運用ルールの策定 使い方：設計レビュー、実装方針の整理、Subagentの作成・管理、PRレビュー、セキュリティ・DB・アーキテクチャ観点の確認 ■ 開発者 準備：Claude Teamへの参加、Claude Codeのセットアップ、GitHubアカウントとリポジトリアクセス、ローカル開発環境、ブランチ作成・テスト実行・PR作成の基本ルール 使い方：developer-agentで実装補助、code-reviewerでセルフレビュー、qa-testerでテスト観点確認、既存コードの理解、小さなPR作成 ■ QA / テスト担当 準備：共有Projectへのアクセス、GitHub Issue/PRへのアクセス、仕様書・API・業務フローへのアクセス、テスト観点テンプレート 使い方：qa-testerでテストケース作成、異常系の洗い出し、回帰テスト観点作成、受入条件の確認、不具合報告の整理 ■ セキュリティ / リスク確認担当 準備：共有Projectへのアクセス、必要な範囲でGitHub PRを確認できる権限、セキュリティ観点チェックリスト、AIに入力してはいけない情報のルール 使い方：security-reviewerで認証・認可・ログ・秘密情報・攻撃面を確認、個人情報や機密情報の扱いをチェック、権限管理・監査ログの不足を洗い出す ■ 業務 / コンプラ確認担当 準備：共有Projectへのアクセス、業務フロー・社内ルール・確認先一覧、法務・コンプラ確認が必要な論点の整理ルール 使い方：compliance-reviewerで確認事項を整理、業務フロー上のリスクを洗い出す、規約・FAQ・社内説明資料のドラフト作成。ただし最終的な法務・コンプラ判断は必ず人間が行う。
GitHub OrganizationまたはOrganization管理のリポジトリを用意する。個人アカウントのリポジトリではなく、会社管理のOrganizationに置くと権限管理がしやすい。 メンバーをGitHubに招待し、以下のように権限を分けると管理しやすい。 ・Admin：管理者・テックリードなど最小限に絞る ・Maintain：リポジトリ運用担当 ・Write：開発者 ・Triage / Read：PM、QA、業務担当など確認が主な役割のメンバー
Branch protectionの設定も重要だ。mainブランチへの直接pushを禁止し、Pull Request必須、レビュー必須、テスト・lintが通らないとmergeできない設定にする。AIが作ったPRも必ず人間がレビューする運用を徹底すること。 IssueテンプレートとPRテンプレートも用意しておくと、AIとの作業がスムーズになる。PRテンプレートに入れると良い項目は以下のとおりだ。 ・変更概要 ・背景 ・影響範囲 ・テスト内容 ・リスク ・ロールバック方法 ・人間が確認すべき点 ・法務・業務・セキュリティ確認の要否
Claude Codeを使うメンバーは、各自の開発環境でセットアップする。リポジトリをcloneし、依存関係をインストールし、テスト・lint・buildが実行できる状態にしてからClaude Codeを起動する。 リポジトリのルートにCLAUDE.mdを用意することで、Claude Codeがプロジェクトのルールを理解した状態で動く。また.claude/agents/配下にSubagentのmarkdownファイルを置き、Gitで管理することで、チーム全員が同じAI運用ルールを使えるようになる。 推奨ディレクトリ構成例： repo/ CLAUDE.md .claude/ agents/ developer.md code-reviewer.md qa-tester.md security-reviewer.md db-reviewer.md business-reviewer.md commands/ review-risk.md make-test-plan.md draft-spec.md
各Subagentのmarkdownファイルは、YAMLフロントマターで設定（name、description、使用するtools、modelなど）を書き、その下にそのエージェントへの指示（システムプロンプト）を記述する形式だ。toolsにはRead・Grep・Glob・Write・Edit・Bashなど必要なものだけを指定し、各agentに最低限の権限だけを与えるのが安全な設計になる。
CLAUDE.mdはClaude Codeがプロジェクトを理解するための設定ファイルだ。金融系プロジェクトでは、以下のようなルールを書いておくことを推奨する。 ・小さな差分で実装する ・仕様変更は影響範囲を説明してから実装する ・DB変更はマイグレーション、ロールバック方法、監査ログへの影響を必ず出す ・本番データ、秘密鍵、APIキー、認証情報は扱わない ・金融・法務・コンプラに関わる判断は確認事項として残し、人間に委ねる ・勝手に本番DBを変更しない ・残高・取引・入出金・権限・監査ログに関わる仕様変更は、必ずテスト観点を出す ・変更時には、変更概要・影響範囲・リスク・テスト観点・人間が確認すべき点を必ず出す ・実行できない外部作業を「実行済み」と言わない ・不確かなことは不確かと書く
最初から多くのSubagentを用意する必要はない。まずは以下の3体から始めるのがよい。 【developer】 小さく安全に実装する。既存コードを壊さない。変更後にテスト観点を出す。toolsにはRead・Write・Edit・Bash・Grep・Globを設定する。 【code-reviewer】 差分レビューを行う。バグ・型エラー・設計崩れ・不要な大改修を指摘する。原則として勝手に修正しない。Read・Grep・Globに絞ることで、誤って変更しない設計にできる。 【qa-tester】 正常系・異常系・空状態・エラー時・権限違い・モバイル表示などのテスト観点を出す。受入条件を整理する。こちらもRead・Grep・Globに絞るのが安全だ。
3体の運用に慣れてきたら、以下を追加していく。 【security-reviewer】 認証・認可・ログ・秘密情報・攻撃面を確認する。 【db-reviewer】 DB設計・トランザクション・整合性・冪等性・監査ログを確認する。 【business-reviewer】 業務フロー・運用・CS対応・社内確認事項を整理する。 【compliance-reviewer】 法務・コンプラ確認事項を整理する。ただし最終判断はしない。
Subagentは自律的に動くAI社員ではなく、人間が工程ごとに呼び出す専門スタッフだ。取引履歴画面の仕様変更を例に、流れを見てみよう。 人間（PM）：「今回の取引履歴画面の仕様変更について、まず要件を整理して」 → requirements-agentが論点・影響範囲・未決事項を出す 人間：「developerで小さく実装して」 → developer-agentが変更対象ファイルを示し、実装する 人間：「code-reviewerでレビューして」 → code-reviewerが「権限チェックの考慮が不足しています」と指摘する 人間：「db-reviewerでデータ整合性の観点を見て」 → db-reviewerが「履歴表示の元データと監査ログの参照方針を明確にした方がよい」と指摘する 人間：「qa-testerでテスト観点を出して」 → qa-testerが正常系・権限違い・データなし・ページング・エラー時のテストケースを出す このように、人間が工程ごとに適切なSubagentを呼び出し、AIの出力を確認しながら進める。承認・最終判断・リスク許容は常に人間が行う。
決済・残高・取引・管理画面・監査ログが絡むプロジェクトでは、以下の用途でAIを活用する価値が大きい。 ・取引履歴や残高表示の異常系洗い出し（データなし・金額ゼロ・タイムアウトなど） ・二重処理や二重実行の防止観点の整理 ・権限管理の確認（誰が何を見ていいか） ・監査ログに残すべき項目の洗い出し ・管理画面の操作ミス防止設計の確認 ・返金・取消・タイムアウト時の業務フロー整理 ・障害時のRunbook作成 ・法務・コンプラ確認事項の整理（最終判断は人間） ・QAテストケースの網羅化 ・CS対応FAQのドラフト作成
注意点として、AIはこれらの「論点整理」「観点出し」「ドラフト作成」を担う。法的判断、コンプライアンス上の最終結論、規制への適合判断は必ず人間が確認する。AIの出力はもっともらしく見えても誤ることがある。
会社でAIを使う際は、入力してよい情報と入れてはいけない情報を社内ルールとして定めることが重要だ。 【入れてよい情報】 ・匿名化された仕様 ・サンプルデータ（実データではないもの） ・業務フロー ・テーブル定義（機密でないもの） ・エラーコード ・公開情報 ・社内で共有許可された設計資料
【AIに入れてはいけない情報】 ・本番顧客データ ・個人情報 ・秘密鍵・APIキー・認証情報 ・実口座情報 ・未承認の契約書全文 ・外部に出せない機密資料 ・社内規程上AI入力が禁止されている情報 CLAUDE.mdにも「本番データ・秘密鍵・認証情報は扱わない」と明記し、Subagentの指示にも同じルールを記載しておくとよい。
Step 1：会社としてClaudeの利用環境を用意する（Claude Teamなど） Step 2：管理者とメンバーを決め、招待・権限設定する Step 3：共有Projectを作り、プロジェクト概要・用語集・業務フロー・決定ログを入れる Step 4：GitHubの権限・ブランチ保護・PRルールを整える Step 5：Claude Codeを使うメンバーのローカル環境を整える Step 6：リポジトリにCLAUDE.mdと.claude/agents/を追加する Step 7：developer / code-reviewer / qa-testerの3体から始める Step 8：実際のIssueを1つ選び、要件整理→実装→レビュー→QA観点作成まで通す Step 9：うまくいったらsecurity-reviewer / db-reviewer / business-reviewerを追加する Step 10：効果を測る
測る指標の例：要件整理にかかった時間、仕様書ドラフト作成時間、PR作成時間、レビュー指摘数、QA観点の漏れ、手戻りの減少、人間が判断に集中できたか。小さく始めて、効果を確認してから広げるのが現実的だ。
・AIに最終承認を任せない。金融系プロジェクトでは法務・コンプラ・セキュリティ・監査の最終確認は人間が行う ・AIの出力はもっともらしく見えても誤ることがある。必ず人間がレビューする ・Subagentを増やしすぎると運用が複雑になり、コストも増える。最初は3体から始める ・AIを使うほど人間の役割は不要になるのではなく、判断・承認・責任に集中するようになる ・会社利用では、個人が勝手にAIを使うのではなく、入力してよい情報・権限・レビュー・記録のルールを会社として決める ・Claude CodeやTeamプランの仕様・料金は変更される可能性があるため、最新の公式ドキュメントを確認すること
Claude CodeのSubagentは、少人数チームの生産性を上げる強力な仕組みだ。ただし本質は「AIに全部任せること」ではなく、「人間が司令塔になり、専門AIを工程に組み込むこと」にある。
会社で使う場合は、Claude Team・共有Project・GitHub・Claude Code・CLAUDE.md・Subagentをセットで整えることが重要だ。個人がバラバラにAIを使うのではなく、チーム共通のルールと前提知識をそろえて初めて、組織としての効果が出る。
特に金融系プロジェクトでは、実装だけでなく、権限・監査ログ・データ整合性・業務フロー・法務確認事項・QA観点の洗い出しにAIを使う価値が大きい。少人数チームでは、採用で人を増やす前に、開発・レビュー・QA・ドキュメント・異常系洗い出しをAIで補強できる段階に来ている。AIは作業を広げ、人間は判断に集中する。この分担が、これからの少人数開発チームの現実的な形だ。
記事で紹介した銘柄のAIスコアを確認
MSFT · GOOGL などをランキングで比較できます