Claude Code 上級者向け講座
組織展開と運用 10 モジュール

このコースの前提

本コースは「Claude Code を個人では使いこなせている」マネジメント層を対象とする。対象読者はエンジニアリングマネージャー、CTO、開発リード、およびプラットフォームチームのリーダー。目的は 組織レベルでの展開・運用・ガバナンスを設計できる状態になる ことにある。

初心者・中級講座が「個人の生産性」を扱うのに対し、上級講座は「30–200 人規模の組織に本格導入するときの設計判断と運用」を 10 モジュールに分解して学ぶ。各モジュールは独立して 60–90 分で実施でき、合計で 10–15 時間程度の自習を想定している。

モジュールごとの構造

各モジュールは以下の 6 つのセクションで統一している。単に機能を紹介するのではなく、何を判断し、どう実装し、成功と失敗をどう見分けるか を毎回確認する。

• 目的 — そのモジュールで到達すべき状態
• 内容 — 扱うトピックの一覧
• 設計判断ポイント — 組織の現状に応じた選択肢と判断軸
• 実装指針 — 実際に設定・構築するときの順序
• 成功指標 — このモジュールが機能していると言える測定点
• 失敗パターン — よく見られる落とし穴

Module 1: Team vs Enterprise の選定と組織ポリシー設計 (60 分)

目的

自社の規模、業界、情報セキュリティ要件を元に、Team プランと Enterprise プランのどちらを採用するかを根拠を持って意思決定できる状態になる。併せて「Claude で何を扱って良いか」の組織ポリシーを 1 ページに書き下ろす。

内容

• Team ($20/人 + Code Premium オプション) vs Enterprise の違い
• Enterprise 限定機能: SSO 強制、SCIM、カスタム retention、audit log export、カスタム契約 (ZDR, BAA)
• 決定フレームワーク: 30 人未満 → Team、50 人以上 → Enterprise、中間はケースバイケース
• 組織ポリシー: 「Claude で扱って良い情報」のクラス分け (Public / Internal / Confidential / Secret)
• クラスごとに許可される操作 / 許可されない操作のマトリクス

設計判断ポイント

• 従業員数が 30–50 人の場合、成長カーブを見て「6 ヶ月後の席数」で判断する
• 契約・法務が ZDR / BAA を必要とするなら Enterprise 一択
• 部門別に採用すると後からの統合が難しい。全社一括が原則
• 非エンジニア (経営企画 / 法務 / 営業) に付与するかどうかも事前に決めておく

実装指針

1. 情報クラス分類の原案を 1 ページで書く (4 クラス × 具体例 3 つずつ)
2. 情報セキュリティ部門とレビュー
3. Anthropic sales に RFP を送付、正式見積を取る
4. 法務で DPA / ZDR / BAA の必要性を判定
5. プラン選定の決裁文書を起案

成功指標

• 90% 以上の利用者が情報を正しいクラスで扱える (抜き打ち調査)
• プラン選定の理由を経営会議で 5 分で説明できる
• Acceptable Use Policy が 1 枚に収まっており、新入社員の初日研修で配布されている

失敗パターン

• 「Enterprise にすれば全て解決」と考え、ポリシー設計を後回しにする
• Acceptable Use Policy を作らず「常識で判断して」と現場に丸投げ
• 部門別に Team と Enterprise が混在 → 監査・契約がカオス化

Module 2: SSO + SCIM + RBAC 構築 (90 分)

目的

IdP (Okta / Entra ID / Google Workspace) との SSO / SCIM 連携を本番構成で完了させ、RBAC を Group → Role mapping で実装する。監査ログを SIEM にエクスポートする経路まで整える。

内容

• IdP 選定 (Okta / Entra ID / Google Workspace) の判断軸
• SAML 2.0 / OIDC の選択基準
• SCIM によるプロビジョニング自動化
• Group → Role mapping の設計 (Admin / PowerUser / Reader / Auditor)
• セッション管理とタイムアウト
• 監査: 誰がいつ何をしたかを SIEM (Splunk / Datadog / Elastic) にエクスポート
• ハンズオン: 仮想環境 (Entra ID 無料層) で実際に連携

設計判断ポイント

• 既存 IdP がある場合は原則そのまま。新規導入を伴うなら Entra ID か Okta が主流
• Role は 4 種類以内に絞る。多すぎると棚卸しが回らない
• SIEM を既に運用している場合は Claude ログの format を既存 dashboard に合わせる

実装指針

1. IdP 側で Claude 用アプリを作成
2. SAML 2.0 metadata を Anthropic 管理画面にアップロード
3. SCIM エンドポイントを有効化し、Group 同期をテスト
4. Admin / PowerUser / Reader / Auditor の Group を IdP 側に作成
5. Role mapping を設定
6. Audit log export (S3 / Splunk HEC / Datadog API) を設定
7. 退職フロー (IdP からの削除 → Claude の即時アクセス剥奪) を 1 件テスト

成功指標

• IdP 削除でアクセスが 5 分以内に遮断される
• 監査ログが SIEM にリアルタイム (遅延 10 分以内) に流れている
• 手動でのユーザ追加・削除の作業がゼロ

失敗パターン

• SCIM を設定せず手動でユーザー管理 → 退職者のアクセスが残り続ける
• Role を 10 種類以上作り、実態と乖離する
• 監査ログを export したのに誰も見ていない (ダッシュボードがない)

Module 3: AWS Bedrock で Japan residency 構成 (75 分)

目的

API トラフィックを ap-northeast-1 に閉じ込めた構成を動作する形で完成させ、「データが US に送られない」ことを経路とログの両面で検証できる状態を作る。

内容

• なぜ Japan residency が必要か (APPI、取引先要求、独自契約の BCP)
• Direct API (api.anthropic.com) vs Bedrock (ap-northeast-1) の比較
• Bedrock 経由で Claude Code を使う設定 (環境変数、IAM ロール)
• 料金比較: Direct API vs Bedrock
• 2026-04-20 の Opus 4.7 ap-northeast-1 対応の活用
• ハンズオン: 自社 AWS で Bedrock を enable、Claude Code CLI で動作確認

設計判断ポイント

• Direct API は簡単だが米国通信。Bedrock は日本国内で閉じるが IAM / VPC / 請求設計が増える
• クロスリージョン inference profile は便利だが、データ経路が US に逃げる危険があるため明示的に無効化する
• Bedrock の料金は Direct API より高めだが、residency 要件を満たすための必要コストと捉える

実装指針

1. ap-northeast-1 リージョンで Bedrock の Claude モデルアクセスを申請・承認
2. 専用 IAM ロールを作成 (最小権限)
3. 環境変数を配布: CLAUDE_CODE_USE_BEDROCK=1, AWS_REGION=ap-northeast-1
4. inference profile を ap-northeast-1 限定に設定 (クロスリージョンを使わない)
5. VPC Endpoint / PrivateLink の採用可否を検討
6. CloudTrail で実際のリクエスト先リージョンを 1 週間監視

成功指標

• 全 API トラフィックが ap-northeast-1 に閉じている (CloudTrail で確認)
• 法務・情報セキュリティが residency 構成に合意済み
• 料金が月次で想定レンジ内

失敗パターン

• クロスリージョン inference profile の設定ミス → データが US へ漏れる
• Direct API と Bedrock が混在 (一部利用者が旧キーを使い続ける)
• Bedrock の料金を Direct API と同じ感覚で見積もり、予算超過

Cross-link: deep-security.html

Module 4: Agent SDK でカスタムエージェント構築 (90 分)

目的

Agent SDK (Python / TypeScript) を使った自律エージェントを最低 1 本動かし、Claude Code の extension ではなく独自のワークフローを API で組む判断軸を身につける。

内容

• Agent SDK (Python / TypeScript) とは、いつ必要か
• Claude Code の extension ではなく、独自の自律エージェントを API で組む選択
• Built-in tools: file / shell / web
• MCP server を SDK から呼び出す
• プロトコル: ループ / 停止条件 / エラー処理 / 監視
• サンプル: 社内ドキュメントの質問応答 bot を Slack からトリガーで起動
• ハンズオン: ミニ bot を 1 本動かす

設計判断ポイント

• Claude Code で十分か、Agent SDK が必要かを「対話性・永続化・トリガー源」で判断する
• Slash コマンド / Skill で足りるなら SDK を使わない。これが第一原則
• SDK を使うのは「Claude Code のセッション外で動く」ワークフローだけに絞る

実装指針

1. 題材を 1 つ決める (例: Slack からの質問 → 社内 wiki 検索 → 回答)
2. Agent SDK の Python または TypeScript プロジェクトを作成
3. Built-in tools を必要最小限で組み込む
4. ループの停止条件を明文化 (最大ステップ数 / 最大トークン / タイムアウト)
5. エラー時のフォールバック動作を設計
6. 実行ログを構造化 (JSON) で出力
7. 監視: 失敗率 / 平均トークン / 平均レイテンシを dashboard 化

成功指標

• 自律タスクが最小限のプロンプト変更で新しいワークフローに適用できる
• トークン使用量が事前見積もりの ±30% に収まる
• 失敗時のアラートが人に届いている

失敗パターン

• 停止条件を甘く設計 → トークン爆発
• Claude Code で足りるタスクを SDK で書き、運用負荷を自ら上げる
• ログを構造化せずテキストで吐く → 失敗原因の特定に時間がかかる

Module 5: ZDR (Zero Data Retention) 契約と企業セキュリティ (60 分)

目的

ZDR の適用範囲と契約プロセスを理解し、情報セキュリティ部門が合意できる形で契約を締結する。社内の「ZDR 対象 / 非対象」の混同を防ぐ運用を作る。

内容

• ZDR の動作原理とスコープ (API response 後削除)
• ZDR 対象: Messages API / Token API / Claude Code (API キー経由 or Enterprise)
• ZDR 非対象: Console / Consumer / Teams UI (Claude Code 以外)
• 契約プロセス: Anthropic sales 連絡、資格確認、組織単位での有効化
• ZDR 有効化で無効になる機能 (会話履歴保持系) の一覧

設計判断ポイント

• ZDR を契約する場合、UI ベースの Console / Consumer 利用は社内で禁止 or 情報クラスを Public 限定にする
• 会話履歴が残らないため「前の会話の続き」ができない。利用者教育とセットで運用
• BAA が必要な医療・金融系は ZDR + BAA の同時契約が標準

実装指針

1. ZDR 契約の必要性を法務・情報セキュリティと合意
2. Anthropic sales に ZDR 契約申請
3. 対象エンドポイント (Messages API / Claude Code) でのみ利用するよう社内周知
4. Console / Consumer UI のアクセスを IdP で制限 (Confidential 以上の情報を入力しないよう)
5. ZDR 有効後、会話履歴が実際に残らないことを 1 件テスト

成功指標

• ZDR 契約が存在し、社内情報セキュリティ部門が合意している
• ZDR 対象外の UI への機密データ入力が 0 件 (抜き打ち監査)

失敗パターン

• ZDR を契約したつもりで Console UI を使って機密データを扱う
• ZDR 有効化後に会話履歴が残らないことを利用者に周知せず、混乱を招く

Module 6: 社内プラグインマーケットプレイスの構築 (75 分)

目的

プラグイン (skills + commands + MCP 設定) を社内配布する仕組みを構築し、バージョニング・署名・承認プロセスを設計する。

内容

• プラグイン (skills + commands + MCP 設定) を社内配布
• GitHub 社内 repo を marketplace として設定
• extraKnownMarketplaces を settings.json で配布
• プラグインのバージョニング、署名、承認プロセス
• ハンズオン: 社内用「weekly-report」プラグインを作って配布

設計判断ポイント

• Marketplace は 1 つに集約する (複数あるとバージョニングが破綻)
• 承認プロセスは「PR レビュー必須」をベースに、セキュリティチームのサインオフを追加
• Semantic Versioning を厳守する (破壊的変更は major 上げ)

実装指針

1. 社内 GitHub org に専用 repo を作成 (例: claude-marketplace)
2. README でプラグイン投稿手順を明文化
3. CODEOWNERS でレビュアーを指定
4. settings.json テンプレートを配布 (extraKnownMarketplaces を含む)
5. 最初のプラグイン「weekly-report」を作り、1 チームで dogfood
6. 利用状況を dashboard 化 (install 数 / 実行数)

成功指標

• 社内の 10 人以上が同じ /your-command を標準として使う
• プラグインが Semantic Versioning で管理されている
• 承認プロセスを経ないプラグインが本番で動いていない

失敗パターン

• バージョニングなし → 破壊的変更で全社の業務が止まる
• 承認プロセスを省略 → 品質のばらつきが信頼を損なう
• Marketplace が複数乱立し、どれが正なのか分からない

Module 7: Routines (クラウド自動化) の運用 (75 分)

目的

Routines を本番運用する基盤 (トリガー設計、失敗時アラート、実行数管理) を整備し、3 種類のトリガー (schedule / GitHub / API) で定型業務を自動化する。

内容

• Routines とは (schedule / trigger / API で Claude Code タスクを自動実行)
• Schedule: 毎週月曜 10:00 に週次レビュー生成
• GitHub trigger: PR マージ時に関連ドキュメント更新
• API trigger: 外部システムから job を投下
• Plan / Max / Team / Enterprise の実行数上限
• 失敗時のアラート設計 (Slack / PagerDuty 連携)
• ハンズオン: 3 つの routine を設計 (schedule / GitHub / API)

設計判断ポイント

• Schedule はクリティカルでない業務から始める (失敗しても困らないもの)
• GitHub trigger は PR マージ後の「ドキュメント更新」「changelog 追記」から
• API trigger は社内 chatbot / ticketing からの呼び出しで拡張性が高い

実装指針

1. 自動化する定型業務を 3 つピックアップ
2. 各業務に最適なトリガーを割り当てる
3. Routine を書き、dry run で挙動確認
4. 失敗時の Slack / PagerDuty 通知を組み込む
5. 2 週間 soak して失敗率を測定
6. プラン別の実行数上限に収まるか確認

成功指標

• 手作業していた定型業務 3 つ以上が自動化されている
• 失敗率が 5% 未満、かつ失敗時は必ず人に通知される
• 実行数が上限の 70% 以内で余裕がある

失敗パターン

• エラーを見ない設計 → サイレント失敗が何週間も続く
• いきなりクリティカルな業務を自動化 → 失敗時の影響が大きい
• 実行数上限を管理せず、月末に止まる

Module 8: 複数 Repo 横断 Parallel Sessions 運用 (60 分)

目的

複数 Repo にまたがる機能開発で Parallel Sessions を使いこなし、セッション間のコンテキスト伝達を明示的に設計できるようになる。

内容

• 大規模組織では Repo が分かれている (backend / frontend / infra / docs)
• Claude Code Desktop の Parallel Sessions で同時に複数 Repo を扱う
• セッション間の情報共有パターン (clipboard vs shared doc vs Session summary export)
• Code レビュー: セッション A で書いた diff をセッション B の Claude にレビューさせる

設計判断ポイント

• セッション間でコンテキストは自動共有されないことを前提にする
• 共有用の「feature note」を 1 ページで作り、各セッションの冒頭で読ませる
• Repo 境界を超えるリファクタは 1 つのセッションで完結させない (レビュー不能になる)

実装指針

1. feature ごとに「feature note」テンプレートを用意 (目的 / 影響 Repo / API 契約)
2. 各 Repo のセッションで note を先に読ませる
3. セッション A の diff を export し、セッション B にレビューさせる
4. 各セッションの最後に「引き継ぎメモ」を吐かせる

成功指標

• 1 feature を 3 repo にまたがって同時作業できる
• レビュー時にセッション間の不整合が発見されない

失敗パターン

• Context 分離を理解せずセッション B が前提知識を持っていると誤解
• feature note を作らず、セッションごとに口頭で説明 (再現性なし)

Module 9: Claude Code + CI/CD 統合 (75 分)

目的

GitHub Actions から Claude Code を呼び出し、PR 自動レビューと CI 失敗時の原因分析を本番稼働させる。API キー管理を OIDC 連携でセキュアに運用する。

内容

• GitHub Actions で Claude Code を呼ぶ
• PR 作成時に自動コードレビュー
• CI 失敗時に Claude が原因を分析してコメント
• Routines からの CI トリガーと逆連携
• API キー管理 (GitHub Secrets / OIDC 連携)
• ハンズオン: GitHub Actions で PR 自動レビュー

設計判断ポイント

• API キーは OIDC + AWS Secrets Manager / Vault 経由で注入し、GitHub Secrets に長期保存しない
• 自動レビューは「blocking ではなく suggesting」で始める (誤検知を許容)
• CI 失敗分析は「コメントで補足」までにとどめ、自動リトライはしない

実装指針

1. OIDC 連携で API キーを動的に取得するワークフローを準備
2. PR opened イベントで Claude を起動するワークフローを作成
3. コメント投稿に GITHUB_TOKEN を使う (最小権限)
4. 誤検知パターンをルール化し、プロンプトで抑制
5. 2 週間の soak で PR 作者・レビュアーからフィードバック収集

成功指標

• 人のレビュー負荷が明確に減り、早期修正が増える
• 誤検知率がチームで受容可能な範囲
• API キー漏洩インシデントがゼロ

失敗パターン

• Claude の誤検知をルール化せず、メンテに負ける
• API キーを GitHub Secrets に平文で長期保存
• 自動レビューを blocking にして CI が常に赤

Module 10: 社内育成プログラムと OKR 設計 (90 分)

目的

30/60/90 日のロールアウト計画を作り、対象別の育成プログラムと OKR を設計する。6 ヶ月後に投資対効果を経営会議で説明できる状態を目指す。

内容

• 30/60/90 日の社内ロールアウト計画
• 対象別育成 (エンジニア / PM / 経営企画 / 法務 / IR)
• 講師役 (Champion) の選定と育成
• 効果測定 OKR
• 運用ドキュメントのメンテナンス責任者
• 失敗時のプレイブック (利用率が上がらない、ROI が見えない)

設計判断ポイント

• 一度に全社展開しない。Champion 5 名 → 20 名 → 全社の 3 段階
• 対象別にコンテンツを変える (エンジニアと経営企画で学ぶことが違う)
• OKR はアウトカム (時短、品質) に寄せる。アウトプット (PR 数) だけで評価しない

実装指針

1. 0–30 日: Champion 5 名を選定、集中トレーニング
2. 30–60 日: Champion がチーム内展開、週次振り返り
3. 60–90 日: 全社展開、対象別オンボーディング資料配布
4. 90 日以降: 月次で KR 測定、四半期レビュー

効果測定 OKR の例

• KR1: アクティブユーザー率 70% 以上
• KR2: 月間 PR の X% に Claude 関与
• KR3: 導入 6 ヶ月で XX 時間 / 人 / 月の時短

成功指標

• 導入 6 ヶ月後に経営会議で投資対効果を説明できる
• Champion が 5 名以上育っている
• 対象別オンボーディング資料がメンテされている

失敗パターン

• 配って終わり。育成と測定なし
• KR をアウトプットだけで設計し、アウトカムが見えない
• Champion が 1–2 名に集中し、バス係数が低い

上級者卒業の先

10 モジュールを完走した後、組織を「Claude Code を運用できる」状態から「Claude Code を武器として外部に価値を出せる」状態へ進めるための次の一手。

• Agent SDK でのプロダクト化 — 社内ツールを顧客向け機能に昇華する判断
• MCP server を外部に公開する判断 — 自社サービスを LLM から使える形で提供する
• Anthropic との共同開発プログラムへの応募 — ケーススタディ / ベータアクセス
• 社内 AI 倫理委員会の設置 — AI 利用に関する判断の権威体を作る
• deep dive の徹底読み込み — deep-security.html / deep-ecosystem.html / deep-mcp.html

組織展開チェックリスト 20 項目

大規模展開 (30 人以上) の前に必ず確認する項目。どれか 1 つでも未完了ならロールアウトを止めて戻る。

• Team / Enterprise 契約の署名
• DPA / ZDR 契約の法務承認
• SSO / SCIM の本番稼働
• audit log SIEM エクスポート
• Bedrock Japan residency 構成
• API キー rotation 運用 (90 日サイクル)
• 社内プラグインマーケットプレイス
• Champion 5 名以上の育成
• 対象別オンボーディング資料
• 利用状況ダッシュボード
• インシデント対応プレイブック
• Acceptable Use Policy
• 情報クラス分類 → 許可ツールの対応表
• OKR 設定
• 四半期レビュー体制
• ROI 測定の計算式 (自分の会社用)
• Routines 監視 → アラート
• 退職時のアクセス剥奪フロー
• 新規入社時の付与フロー
• 6 ヶ月後の Refresh 研修計画

※ 本資料は 2026 年 4 月 22 日時点の情報に基づく。Anthropic の製品開発サイクルは迅速であり、機能・価格・契約条件は予告なく変更される可能性がある。