claude code on the web実践・導入ガイド

こんにちは。ウィルダー株式会社です。

claude code on the webについて調べているあなたに向けて、私の現場経験を踏まえながら、導入から活用、セキュアな運用までを一気通貫で解説します。

エージェント型の開発スタイルやCLIの使い方、VS Code拡張やJetBrains連携、Model Context ProtocolやFiles APIによる外部システム統合、Amazon BedrockとVertex AIでのエンタープライズ運用、さらにAgent Skillsによる自動化、SWE-benchやTerminal-Benchの性能評価、サンドボックスとパーミッション、YOLOモードまで、気になるポイントを実務目線で整理しました。

この記事を読み進めれば、claude code on the webの導入判断に必要な情報がまとまり、チームの生産性向上と安全性を両立するための運用設計まで、しっかり踏み込めるはずです。

claude code on the webの概要

出典：https://unsplash.com/ja

まずは全体像から。claude code on the webは、チャットの域を越えて、ファイル編集、コマンド実行、Gitコミットまで担うエージェント型のコーディング環境です。ここでは、CLIの基本、インストール、IDE連携、MCP/Files API、そしてクラウド提供形態までを一気に整理します。

いわば「開発に必要な手と目を持つAI」ですよね。ポイントは、人が用意した要件・ガイドライン・制約を、エージェントがタスク化して淡々と進められること。作業は常に差分ベースで可視化され、あなたがレビューしたうえで適用。テストやビルドの結果を再学習的に取り込み、完了条件に到達するまで反復します。

従来の「チャットで提案、手動で貼り付け」から一歩進んで、計画からコミットまでの工程を一体化して扱えるのが魅力です。チームで使うなら、ルールや責務の境界をはっきりさせるほど、誤動作の余地が減り、速度と安全性が両立しやすいと思います。

使い方とCLI基本

私のおすすめは、「計画→差分→実行→検証→コミット」のサイクルを、CLIで明示的に回すことです。Claudeは自然言語での指示から作業計画を立て、対象ファイルだけに限定して編集し、テストやビルドのコマンドを実行し、その結果を踏まえて修正、最後にコミットまで行えます。

基本フロー

1. 計画: タスクの意図と制約を明確化（影響範囲、ガイドライン、テスト要件）
2. 差分: 提案された変更のdiffをレビューし、必要に応じて修正指示
3. 実行: ローカルでテストやビルドを走らせ、結果をフィードバック
4. 検証: 追加のテストや静的解析で品質を確認
5. コミット: 約束されたフォーマットのコミットメッセージで保存

tail -f app.log | claude -p "このログストリームで異常を検知したらSlackに通知してください"

CIでも同様に、構造化出力で後続処理しやすくしておくと便利です。

claude -p "新規の英語文言をフランス語に翻訳し、PRを作成してください" --json > result.json

さらに踏み込むなら、計画段階で「期待する完了条件（Definition of Done）」を明文化しましょう。例えば「テストカバレッジ+5%、アクセシビリティ基準A達成、変更は500行以内」など、数値やしきい値で具体化しておくと、エージェントが同じゴールを見やすいです。

差分レビューでは「命名規則」「パフォーマンス影響」「セキュリティ影響」の観点チェックをテンプレ化してショートカット化。実行フェーズはタイムアウトやリトライ回数、idempotency（同じコマンドを再実行しても結果が安定するか）も設定しておくと、CI/CDとの親和性が上がります。

検証で失敗したらログと出力をそのままCLIへ渡して再提案を依頼。コミットはConventional Commitsなどの規約を前提化し、PRの説明文も自動生成させるとレビューが相当ラクになります。
なお、Claudeがファイル操作・コマンド実行・差分適用を行う基盤機能については、公式ドキュメントが一次情報です（出典：Anthropic公式ドキュメント「Claude Code」）。

CLIインストールとnpm設定

導入はシンプルです。Node.js（LTS推奨）を用意し、グローバルインストールします。

# インストール
npm install -g @anthropic-ai/claude-code

#APIキー（Anthropic直API利用の場合）
#export ANTHROPIC_API_KEY="your_key"

#企業プロキシ環境の例
npm config set proxy http://proxy.example.com:8080 npm config set https-proxy http://proxy.example.com:8080

正確な情報は公式サイトをご確認ください。環境変数やフラグ名はアップデートで変わる可能性があります。

実運用のセットアップTips

現場では、nvm/VoltaなどでNodeを固定し、CIでも同じバージョンを使って差異を潰します。APIキーは.envやSecret Managerに置かず、なるべくOSの安全な秘密管理（macOS Keychain、Windows Credential Manager、Linuxのpass等）かクラウドのシークレットに保存。

キーはローテーション方針を用意し、権限は最小限に。プロキシ配下ならnpmのproxy設定に加えて、HTTP(S)_PROXYやNO_PROXYも併用すると安定します。npxでの一時実行もアリですが、CIでキャッシュしたいならグローバルインストールが楽かもです。

CLIの構成値はプロジェクトに隠しファイル（例：.clauderc.json）として置くと、開発者ごとの差が減ります。ジョブごとのタイムアウト、最大並列数、使用モデル、ヨーロッパリージョン優先などのポリシーを共有化しましょう。

Makefile/Taskfileと組み合わせて「make fix-lint」「make gen-docs」のような定型コマンドにラップしておくと、オンボーディングが早いです。CIでは–json出力のスキーマを決めて、結果をjqで抽出→Slack通知→PRコメントに反映、まで自動化しておくと、日々の手間が一気に減りますよ。

VS Code拡張とJetBrains連携

出典：https://unsplash.com/ja

VS Codeの公式拡張を導入すると、エージェントが編集した差分がエディタ上にそのまま反映され、提案を選択して適用できます。ターミナル操作やテスト実行のログもコンテキストとして取り込めるのが便利です。JetBrainsではAIアシスタント経由で連携し、エディタ内でのマルチファイル編集やコード参照がスムーズです。

設定のコツ

• プロジェクトフォルダを信頼済みにし、ファイルアクセスの範囲を明示
• ターミナルを統合して、ビルド・テスト結果を即時フィードバック
• 差分ビューで小さなPR単位に分割（レビュー生産性が上がります）

IDE連携のキモは「脳内コンテキストをIDEに寄せる」こと。ターミナル、問題パネル、テストエクスプローラ、Git差分ビューを1画面に集め、Claudeに見せたい情報はターミナルへ出すか、関連ログをスレッドに貼り付けると認識精度が上がります。

ワークスペース単位で「除外ディレクトリ（node_modules、dist）」や「読み取り専用パス」を定義しておくと、不要な差分や誤操作が減ります。JetBrains系では、スコープ設定とファイルテンプレート、コードインスペクションのプロファイルをプロジェクト共有しておくと、提案がガイドラインに沿いやすいです。

操作面では、差分が広いとレビュー疲れが出るので、機能単位でエージェント実行→PRを分けていくと、チームの合意形成が速いです。CIの保護ルール（最低2レビュー、ステータス必須）と組み合わせると、IDE上の「適用→テスト→PR作成」までが一筆書きになって気持ちいいですよ。

MCPとFiles API連携

Model Context Protocol（MCP）は、Claudeの認識範囲を「あなたの開発環境の外」まで広げるための標準インターフェースです。Jira、Google Drive、Figma、社内ツールなどに接続し、デザインや要件、チケットの状態をタスクの判断材料に注入できます。Files APIは、永続的なファイルコンテキストを提供し、長時間タスクでもブレずに継続可能にします。

{
  "mcp": {
    "providers": [
      { "name": "jira", "url": "https://jira.example.com", "auth": "oauth" },
      { "name": "figma", "token": "FIGMA_TOKEN" }
    ]
  },
  "files": {
    "persist": true,
    "paths": ["docs/", "design-system/", "specs/"]
  }
}

この組み合わせにより、マルチステップの開発フローを30時間級で維持しても文脈が崩れにくくなります。

運用設計のポイント

MCPは「どの外部情報をタスク判断に使ってよいか」を宣言的に制御できるのが強み。例えばJiraなら読み取り専用でタスク要約とラベルだけ、Figmaはコンポーネント名と注釈だけ、Driveは設計書の最新版のみ…といった粒度で許可すると、情報過多を防ぎつつ根拠のある判断ができるようになります。

Files APIでは、仕様書・設計体系・命名辞典・コミット規約を永続化し、エージェント起動時に自動ロード。長時間タスクでタイムラインが飛んでも、重要な前提が揺れません。ファイルの更新トリガーで再同期（watcher）を仕込み、差分が出たらClaudeに「刷新点」を要約させるのも定番です。

エラー処理も重要です。MCPが404/401を返したときは、黙って進めず「必要な権限が不足しています（対象: PROJECT-123）」のように可観測なメッセージを返すようテンプレ化を。Files APIの肥大化はコンテキスト圧迫の原因になるので、古い資料はスナップショット化や軽量要約に置き換えると安定します。

Amazon BedrockとVertex AI

出典：https://unsplash.com/ja

エンタープライズでは、Amazon BedrockやGoogle Cloud Vertex AIでのホスティングが有効です。ガバナンス、監査、ネットワーク制御を既存ポリシーで統合しやすく、SLAやデータ主権の要件にも適合しやすいのが利点です。

# Bedrock例
export AWS_PROFILE=enterprise
export AWS_REGION=us-east-1
claude --provider bedrock -p "社内規約に沿ってテストを更新"

#Vertex AI例
export GOOGLE_PROJECT=your-project export GOOGLE_APPLICATION_CREDENTIALS=/path/creds.json claude --provider vertex -p "アクセシビリティレポートを生成"

正確な情報は公式サイトをご確認ください。接続設定、料金、リージョン可用性は変更される場合があります。

ガバナンス観点の実務Tips

BedrockはVPCエンドポイントでの私設接続、KMSによる暗号化、CloudTrailでの監査がまとまりやすく、既存のIAMポリシーでアクセス統制をしやすいのが魅力です。

Vertex AIは組織ポリシーやDLP、Service Perimeter（VPC-SC）との連携が強く、GCP資産で統一している組織に向いています。どちらもPIIの取り扱いは「入力フィルタリング→モデル呼び出し→出力検査」の3段階で仕切ると監査に通しやすいです。

費用はトークン消費だけでなく、ログ保管、ネットワーク、CI回数も含めて全体TCOで評価しましょう。フェイルオーバーは「プロバイダBへ自動切替」ではなく「非機能要件ごとに許容範囲を明文化」してからルーティング設計を。

実装ではIAM/Service Accountに最小権限を割り当て、環境ごと（dev/stg/prod）に別アカウント・別プロジェクトを分離。リソース命名規則、タグ/ラベル戦略、コスト配賦（コストセンター）を最初に固めると、後々の監査・可視化がきれいに回ります。

claude code on the web導入

出典：https://unsplash.com/ja

ここからは、実運用に踏み込んだ導入・自動化・安全対策の話です。Agent Skillsでの専門化、SWE-bench/Terminal-Benchの指標の読み方、パーミッション／サンドボックスの考え方、そしてYOLOモードの安全な使い方まで、意思決定に直結する要点を整理します。

Agent Skillsで自動化強化

Agent Skillsは、エージェントの「仕事のやり方」をパッケージ化する仕組みです。スクリプト、プロンプト、リソース、規約をひとつのフォルダにまとめ、スラッシュコマンドで呼び出します。これにより、汎用エージェントを、組織特化のエキスパートに変換できます。

ディレクトリ構成の例

skills/
  test-generator-bdd/
    prompts.md         # BDDの原則、命名、ダブルループのレビュー手順
    rules.md           # モック戦略、例外パターン、禁止事項
    run.js             # 生成→実行→差分レビュー→修正の制御ロジック
    resources/
      testing-core.md
      testing-components.md
      testing-cases-ngrx.md

呼び出しの例

claude /test --target src/auth/ --coverage 80 --format junit

Skillは「半製品の自動化」です。なので、入力契約（必須フラグ、許可パス）、出力契約（JSONスキーマ、エグジットコード）、副作用（書き込み先、コマンド実行範囲）をREADMEで宣言しておくと、誰が触っても事故が起きにくいです。テストも忘れずに。

run.jsをユニットテストし、エンドツーエンドでは実際に空のブランチへPRを作らせてスモークテスト。Skillのバージョニングはsemverで、非互換変更はメジャーアップ。変更履歴とモデルの相性（例：Sonnet推奨）も記録すると、運用がぶれません。

ログはSTEP単位で残してDatadogやCloudWatchに逃がすと、トラブル時に「どの指示で暴れたか」を再現できますよ。

SWE-benchとTerminal-Bench

パフォーマンスの評価には、SWE-bench VerifiedとTerminal-Benchが有用です。前者は実在リポジトリのバグ修正能力、後者はコマンドライン駆動のエージェントとしての遂行力を測ります。

読み解きのポイントは、SWE-bench＝改修品質、Terminal-Bench＝自律実行力。スループット重視ならSonnet、精緻な変更やリスクが高い領域はOpusを使い分けるのが現場では効きます。

評価設計のコツ

ベンチは指標であってゴールではない、を徹底しましょう。あなたのリポジトリに近い課題セット（例：Web/DB/メッセージング/ML）を抜き出し、社内版ミニSWE-benchを作るのが実践的です。

プルリク単位で「修正の正当性」「副作用の有無」「差分サイズ」「テストの妥当性」を採点。Terminal-Bench系では、コマンドの順序、エラー復帰、idempotency、出力の構造化を評価軸に。

再現性のためにDockerイメージを固定し、乱数や外部API呼び出しをモック。スコアは週次でトレンドを見て、モデル更新やSkill改修の効果を測るとよいです。数字が良くてもレビューコストが上がっていたら総合効率は落ちるので、レビュー時間やリワーク回数も合わせてダッシュボード化するのがオススメです。

サンドボックスとパーミッション

出典：https://unsplash.com/ja

エージェントは強力だからこそ、安全枠の設計が最重要です。デフォルトはリードオンリー＋明示承認。そこに、ファイルシステム分離とネットワーク分離を重ねましょう。

• ファイルシステム分離: プロジェクト配下の特定ディレクトリのみをアクセス許可
• ネットワーク分離: 外部送信を禁止（データ持ち出しやC2通信を阻止）
• 承認ログ: 権限付与を監査・可視化し、「承認疲労」を回避

最小権限のパターン集

私のおすすめ構成は「Allowlist方式」です。読み取り可能パス、書き込み可能パス、実行可能コマンドを列挙し、それ以外は拒否。承認は「単発許可（30分のみ）」「セッション許可（スレッド内のみ）」「永続許可（CI用のみ）」の3段階で。

ネットワークはデフォルト閉域、必要な社内APIはDNSベースで許可。ファイルの書き込みはpre-commitでガード（秘密鍵・大型ファイル・生成物の誤コミットをブロック）し、万一の破壊対策にローカルのスナップショット/Time Machineを併用します。

監査の観点では、「誰が」「どの権限で」「どのファイルに」「どんな差分を適用したか」が追えることが最重要。ログは集中管理に送り、異常検知ルール（短時間に大規模削除、.envアクセスなど）を用意しておくと安心です。

YOLOモードとセキュリティ

YOLOモード（--dangerously-skip-permissions）は全承認をスキップして高い自律性を与えますが、本番環境での使用は厳禁です。どうしても必要な検証時は、ネットワークから隔離されたコンテナでのみ。

# オフライン検証コンテナ例（概念）
docker run --rm -it \
  --network none \
  -v $PWD:/workspace \
  -w /workspace \
  your-dev-image \
  bash -lc 'claude --dangerously-skip-permissions -p "限定タスクのみ実行"'

安全に試すための手順

YOLOは「シード実験用の一時サンドボックス」と割り切るのがコツ。必ず読み取り専用のGitクローンで、PRブランチ専用の検証。ファイルシステムはCopy-on-Write（例：btrfs/ZFSのsnapshot）で守り、破壊的変更は即座にロールバック可能に。

実行前・後でチェックサム（git statusとファイルサイズ）を取り、想定外の大量変更があれば即停止。pre-commitフックで危険拡張子や秘密情報の混入をブロック。さらに、変更は最大Nファイル/最大行数の制限を設けておくと、大事故のリスクはかなり減ります。

検証が終わったらコンテナを破棄し、キャッシュ/一時ファイルも消去して後に残さないのが鉄則です。ここは慎重でいきましょう。

claude code on the web使い方

https://unsplash.com/ja

最後に、日々の運用での実践ステップをまとめます。私の現場では、次の流れが定番です。

1. プロジェクト準備

• CLAUDE.mdにフレームワーク、Lint、テスト、コミット規約を明記
• MCPでJiraとFigma、Files APIでデザインシステムと仕様を永続化
• サンドボックスを有効化し、アクセス範囲とネットワークを限定

2. タスク実行（例：認証の不具合修正）

# 目的・制約・完了条件を具体的に
claude -p "
/src/auth のトークン失効の根本原因を特定し修正。
/tests/auth の単体テストを更新。
コミットメッセージは 'fix(auth): <要約>' 形式。
" --json

提示された計画とdiffをレビューし、必要なら追加の制約を与えて再提案。ローカルテストを走らせ、失敗ログをClaudeに返して再試行します。

3. コミットとPR

# コミットは小さく、PRはレビュー観点ごとに分割
git add -p
git commit -m "fix(auth): refresh token TTL mismatch"
git push && gh pr create --fill

4. CI/CD連携

CI側でclaude --jsonを使い、レポートを機械可読にします。翻訳、ドキュメント生成、リンティング修正などは高い相性です。大規模移行は、OK/FAILのバイナリ出力を次工程に渡すパイプライン化が効きます。