この記事は 2026年3月 時点の情報をもとに作成しています。Cline・Claude Codeはどちらも活発に開発が続いているため、最新情報は公式ドキュメントも合わせてご参照ください。
はじめに
初心者向けの入門記事では、ClineのインストールからMCPの基本的な使い方までを解説しました。
この記事では、実際の開発現場でClineを最大限に活用する方法に踏み込んで解説します。対象は「すでにClineを使ったことがある」「MCP・CI/CD・チーム開発に取り組んでいる」方です。
扱うテーマは以下の通りです：
- 高度なMCP活用：カスタムMCPサーバーの構築、複数MCPの連携
- CI/CDへの統合：GitHub Actionsでの自動化
-
チーム開発：
.clinerulesの共有とガバナンス - Claude Code との比較・使い分け：用途に応じた選択基準
アーキテクチャ全体像
まずClineがどのように動作するかを把握しましょう。
Clineの特徴は「VSCodeのプロセス内でエージェントループが動作する」点です。ファイル編集・コマンド実行・MCP呼び出しがすべてローカルで完結し、LLMへの通信だけが外部に出ます。
高度なMCP活用
MCPアーキテクチャの理解
MCP（Model Context Protocol）はAnthropicが策定したオープン規格で、AIエージェントと外部ツールを接続するためのプロトコルです。
MCPサーバーは STDIO（標準入出力）と SSE（Server-Sent Events）の2つのトランスポートをサポートしています。
| トランスポート | 特徴 | 用途 |
|---|---|---|
| STDIO | プロセスとして起動・終了 | ローカルツール、ファイル操作 |
| SSE | 常駐HTTPサーバー | リモートサービス、Webhook |
複数MCPの高度な連携
実際のプロジェクトでは複数のMCPを組み合わせます。以下は典型的な構成例です：
{
"mcpServers": {
"brave-search": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-brave-search"],
"env": {
"BRAVE_API_KEY": "${BRAVE_API_KEY}"
}
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
}
},
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres"],
"env": {
"POSTGRES_CONNECTION_STRING": "${DATABASE_URL}"
}
},
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/nick/projects"
]
}
}
}
環境変数の管理
APIキーは直接JSONに書かず、${ENV_VAR} 形式で参照しましょう（Clineは .env や環境変数を自動展開します）。シークレット管理にはdirenv・1Passwordなどの利用を推奨します。
カスタムMCPサーバーの構築
既存のMCPに機能が足りない場合は自前で構築できます。以下は社内APIに接続するカスタムMCPの実装例です：
// custom-api-mcp/src/index.ts
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
CallToolRequestSchema,
ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";
const server = new Server(
{ name: "custom-api-mcp", version: "1.0.0" },
{ capabilities: { tools: {} } }
);
// ツール一覧を返す
server.setRequestHandler(ListToolsRequestSchema, async () => ({
tools: [
{
name: "get_user_info",
description: "社内ユーザーDBからユーザー情報を取得する",
inputSchema: {
type: "object",
properties: {
user_id: {
type: "string",
description: "ユーザーID",
},
},
required: ["user_id"],
},
},
{
name: "create_ticket",
description: "Jiraにチケットを作成する",
inputSchema: {
type: "object",
properties: {
title: { type: "string" },
description: { type: "string" },
priority: {
type: "string",
enum: ["low", "medium", "high", "critical"],
},
},
required: ["title", "description"],
},
},
],
}));
// ツールを実行する
server.setRequestHandler(CallToolRequestSchema, async (request) => {
const { name, arguments: args } = request.params;
if (name === "get_user_info") {
const response = await fetch(
`${process.env.INTERNAL_API_URL}/users/${args.user_id}`,
{
headers: { Authorization: `Bearer ${process.env.INTERNAL_API_TOKEN}` },
}
);
const user = await response.json();
return {
content: [{ type: "text", text: JSON.stringify(user, null, 2) }],
};
}
if (name === "create_ticket") {
const response = await fetch(`${process.env.JIRA_URL}/rest/api/3/issue`, {
method: "POST",
headers: {
"Content-Type": "application/json",
Authorization: `Basic ${Buffer.from(
`${process.env.JIRA_EMAIL}:${process.env.JIRA_TOKEN}`
).toString("base64")}`,
},
body: JSON.stringify({
fields: {
project: { key: process.env.JIRA_PROJECT_KEY },
summary: args.title,
description: { type: "doc", version: 1, content: [
{ type: "paragraph", content: [{ type: "text", text: args.description }] }
]},
priority: { name: args.priority ?? "medium" },
issuetype: { name: "Task" },
},
}),
});
const ticket = await response.json();
return {
content: [
{ type: "text", text: `チケット作成完了: ${ticket.key}` },
],
};
}
throw new Error(`Unknown tool: ${name}`);
});
// STDIOトランスポートで起動
const transport = new StdioServerTransport();
await server.connect(transport);
このカスタムMCPをClineに登録します：
{
"mcpServers": {
"custom-api": {
"command": "node",
"args": ["/path/to/custom-api-mcp/dist/index.js"],
"env": {
"INTERNAL_API_URL": "https://api.internal.example.com",
"INTERNAL_API_TOKEN": "${INTERNAL_TOKEN}",
"JIRA_URL": "https://mycompany.atlassian.net",
"JIRA_EMAIL": "nick@example.com",
"JIRA_TOKEN": "${JIRA_API_TOKEN}",
"JIRA_PROJECT_KEY": "ENG"
}
}
}
}
.clinerules による高度なプロジェクト管理
.clinerules はClineのプロジェクト専用設定ファイルで、チーム全員が同じルールを共有するために使います。
実践的な .clinerules テンプレート
# プロジェクトルール（.clinerules）
## スタック情報
- Runtime: Node.js 22 (LTS)
- Framework: Next.js 15 (App Router)
- Language: TypeScript 5.x（strictモード）
- Styling: Tailwind CSS v4
- DB: PostgreSQL 16（ORM: Prisma）
- テスト: Vitest + Testing Library
- CI: GitHub Actions
## コーディング規約
- コメントはすべて日本語で記述すること
- 関数はすべてJSDoc形式でドキュメント化すること
- `any`型の使用は禁止。代わりに`unknown`を使い型ガードを実装すること
- エラーハンドリングは必ず実装。エラーメッセージは日本語で記述
- APIエンドポイントはzodでバリデーションを実装すること
## ファイル構造
src/
├── app/ # Next.js App Router ページ
├── components/ # 再利用可能なUIコンポーネント
├── lib/ # ユーティリティ・ヘルパー
├── hooks/ # カスタムReact Hooks
├── types/ # 型定義
└── server/ # サーバーサイドロジック（Server Actions）
## 禁止事項
- `console.log` をコミットしないこと（debugログはloggerライブラリを使う）
- `.env` ファイルをコミットしないこと
- `TODO` コメントをそのまま放置しないこと（Issue番号を必ず記載）
- `node_modules` 以下のファイルを直接編集しないこと
## テスト要件
- 新機能・バグ修正には必ずテストを追加すること
- カバレッジ目標: 80%以上
- テストファイルは `__tests__/` ディレクトリまたは `.test.ts` 拡張子
## PRルール
- 変更前に必ず `git status` と `git diff` を確認してから報告すること
- 1つのPRは1つの機能・修正のみ
- コミットメッセージは Conventional Commits 形式: `feat:`, `fix:`, `chore:` 等
## 作業開始前のチェックリスト
1. 依存関係が最新か確認: `npm outdated`
2. 型チェックが通るか確認: `npm run type-check`
3. テストが通るか確認: `npm test`
4. Lintが通るか確認: `npm run lint`
.clinerules の階層管理
大規模プロジェクトでは、サブディレクトリごとに .clinerules を配置できます：
project/
├── .clinerules # プロジェクト全体のルール
├── frontend/
│ └── .clinerules # フロントエンド固有のルール
├── backend/
│ └── .clinerules # バックエンド固有のルール
└── infra/
└── .clinerules # インフラ固有のルール（Terraform等）
CI/CDへの統合
GitHub ActionsでClineを活用する
Clineは基本的にVSCode内で動作しますが、CI/CDではClaude APIを直接使う形でパイプラインに統合できます。以下はPR作成時に自動でコードレビューを行うワークフロー例です：
# .github/workflows/ai-code-review.yml
name: AI Code Review
on:
pull_request:
types: [opened, synchronize]
paths:
- 'src/**/*.ts'
- 'src/**/*.tsx'
jobs:
ai-review:
runs-on: ubuntu-latest
permissions:
pull-requests: write
contents: read
steps:
- name: Checkout
uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '22'
- name: Get changed files
id: changed-files
run: |
git diff --name-only origin/${{ github.base_ref }}...HEAD \
| grep -E '\.(ts|tsx)$' \
| head -20 > changed_files.txt
echo "files=$(cat changed_files.txt | tr '\n' ',')" >> $GITHUB_OUTPUT
- name: Generate diff
run: |
git diff origin/${{ github.base_ref }}...HEAD \
-- $(cat changed_files.txt | tr '\n' ' ') \
> pr_diff.txt
- name: AI Code Review
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
PR_NUMBER: ${{ github.event.pull_request.number }}
REPO: ${{ github.repository }}
run: |
node - <<'EOF'
const Anthropic = require('@anthropic-ai/sdk');
const fs = require('fs');
const { execSync } = require('child_process');
const client = new Anthropic();
const diff = fs.readFileSync('pr_diff.txt', 'utf-8');
async function review() {
const message = await client.messages.create({
model: 'claude-opus-4-6',
max_tokens: 2048,
messages: [{
role: 'user',
content: `あなたはシニアエンジニアです。以下のPRのdiffをレビューし、日本語で簡潔にフィードバックしてください。\n\nレビュー観点：\n- バグの可能性\n- セキュリティリスク\n- パフォーマンス問題\n- 可読性・保守性\n- TypeScriptのベストプラクティス\n\n\`\`\`diff\n${diff.slice(0, 8000)}\n\`\`\`\n\nマークダウン形式で、重要な問題は⚠️、提案は💡、良い点は✅ でマークしてください。`
}]
});
const review = message.content[0].text;
const comment = `## 🤖 AI Code Review\n\n${review}\n\n---\n*このレビューはClaude AIにより自動生成されました*`;
execSync(`gh pr comment ${process.env.PR_NUMBER} --repo ${process.env.REPO} --body "${comment.replace(/"/g, '\\"')}"`, {
env: { ...process.env }
});
console.log('Review posted successfully');
}
review().catch(console.error);
EOF
テスト自動生成ワークフロー
新しいソースファイルが追加されたときに自動でテストを生成するワークフロー：
# .github/workflows/auto-test-gen.yml
name: Auto Test Generation
on:
push:
branches: [feature/**]
paths:
- 'src/lib/**/*.ts'
- 'src/hooks/**/*.ts'
jobs:
generate-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- run: npm ci
- name: Find untested files
id: find-files
run: |
for f in $(git diff --name-only HEAD~1 -- 'src/lib/**/*.ts' 'src/hooks/**/*.ts'); do
test_file="${f/.ts/.test.ts}"
if [ ! -f "$test_file" ]; then
echo "Missing test: $test_file for $f"
echo "$f" >> files_needing_tests.txt
fi
done
- name: Generate tests with Claude
if: hashFiles('files_needing_tests.txt') != ''
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
while IFS= read -r source_file; do
node generate-test.js "$source_file"
done < files_needing_tests.txt
- name: Commit generated tests
run: |
git config user.name "github-actions[bot]"
git config user.email "github-actions[bot]@users.noreply.github.com"
git add "src/**/*.test.ts" 2>/dev/null || true
git diff --staged --quiet || git commit -m "test: auto-generate tests for new files [skip ci]"
git push
チーム開発での活用
コードレビューの自動化
Clineをレビュアーとして使う際の効果的なプロンプトパターン：
このPRの変更を以下の観点でレビューしてください：
1. バグの可能性
- 境界値・エッジケースの未処理
- null/undefined の扱い
- 非同期処理のエラーハンドリング
2. セキュリティ
- SQLインジェクション、XSS の可能性
- 認証・認可の漏れ
- 機密情報の露出
3. パフォーマンス
- N+1クエリ
- 不要な再レンダリング
- メモリリーク
4. テスト
- カバレッジの漏れ
- エッジケースのテスト
変更ファイル: @src/api/users.ts @src/hooks/useUser.ts
ドキュメント自動生成
APIドキュメントを自動生成する使い方：
src/api/ 以下のすべてのルートハンドラーを読んで、
OpenAPI 3.0形式のYAMLドキュメントを生成してください。
要件：
- すべてのエンドポイントを網羅
- リクエスト/レスポンスのスキーマを正確に記述
- 日本語でdescriptionを追加
- 認証が必要なエンドポイントにはsecurityを設定
- docs/openapi.yaml として保存
コンフリクト解消支援
以下のマージコンフリクトを解消してください。
コンテキスト：
- main ブランチはキャッシュ機能を追加
- feature/refactor ブランチはエラーハンドリングを改善
- 両方の変更を統合した形で解消してください
@src/lib/api-client.ts
Claude Code との比較・使い分け
ツールの位置づけ
詳細比較表
| 観点 | Cline | Claude Code |
|---|---|---|
| 動作環境 | VSCode拡張機能（GUI） | ターミナル（CLI） |
| 操作方法 | チャットUI + 承認ボタン | コマンドライン + インタラクティブ |
| MCPサポート | 完全対応（GUI設定） | 対応（設定ファイル） |
| 承認フロー | アクションごとにGUI確認 | インタラクティブ確認 or --yes で自動 |
| 対応モデル | 多数のプロバイダー対応 | Claude専用（Anthropic API） |
| 料金 | APIキー直接（プロバイダー依存） | Anthropic API（Claudeのみ） |
| スクリプト化 | 難しい（GUI前提） | 容易（--print フラグで非対話モード） |
| IDE統合 | VSCodeに最適化 | エディタ非依存 |
| コンテキスト共有 | プロジェクトファイル参照 |
CLAUDE.md による設定 |
| マルチエージェント | 非対応 | サブエージェント対応 |
| Hooks | 非対応 | 対応（PostToolUse等） |
ユースケース別選択ガイド
実際の使い分け例
Clineが向くシーン：
# 新機能の実装（VSCode内で対話的に）
「認証機能を実装してください。
JWTトークンベースで、
リフレッシュトークンも含めてください。
@src/auth/ フォルダに実装してください」
# リファクタリング（ファイルを見ながら）
「@src/api/users.ts の関数を
リポジトリパターンに分離してください。
@src/repositories/ に移動してください」
Claude Codeが向くシーン：
# CI/CDでの自動テスト生成
claude --print "src/lib/*.ts を読んで、
各関数のユニットテストを生成し、
__tests__/ に保存してください" \
--allowedTools "Read,Write"
# バッチ処理（複数ファイルの一括変換）
claude --print "src/ 以下のすべての .js ファイルを
TypeScript に変換してください" \
--allowedTools "Read,Write,Bash"
# Gitフックとの連携
# .git/hooks/pre-commit
claude --print "$(git diff --staged)" \
"このdiffにセキュリティ問題がないか確認してください。
問題があれば exit 1 してください"
両方を組み合わせる戦略
Clineで開発しつつ、Claude Codeでパイプラインを自動化するのが最も効率的です：
| フェーズ | ツール | 作業内容 |
|---|---|---|
| 設計・実装 | Cline | UIを見ながらコードを書く |
| コードレビュー | Claude Code | PRのdiffを自動解析 |
| テスト生成 | Claude Code | カバレッジ不足箇所を補完 |
| デプロイ確認 | Cline | ログを見ながらデバッグ |
| ドキュメント生成 | Claude Code | バッチでAPIドキュメント生成 |
パフォーマンス最適化とコスト管理
APIコストを削減するテクニック
1. モデルの使い分け
// 軽いタスクには安価なモデルを使う
{
"cline.apiProvider": "openrouter",
"cline.openRouterModelId": "anthropic/claude-haiku-4-5"
}
重いタスク（設計、複雑なリファクタリング）には claude-opus-4-6、軽いタスク（コメント追記、簡単な修正）には claude-haiku-4-5 と使い分けるとコストを大幅に削減できます。
2. コンテキストの最適化
# .clinerules に追加
## コンテキスト管理
- 作業に無関係なファイルは `@` で参照しないこと
- 大きなファイルは必要な部分だけ引用してください
- テストファイルは実装ファイルと同時に参照しないこと（別タスクで）
3. Auto-Approveの活用
安全な操作（読み取り専用・テスト実行）は Auto-Approve を有効にしてラウンドトリップを減らします。
プロンプトエンジニアリングのベストプラクティス
効果的な指示の構造：
## タスク
[1文で明確に何をするか]
## 背景・コンテキスト
[なぜこれが必要か、現在の状況]
## 要件
- [具体的な要件1]
- [具体的な要件2]
## 制約
- [やってはいけないこと]
- [既存の設計との整合性]
## 参照ファイル
@src/existing-code.ts # 参考にするファイル
セキュリティ・ガバナンス
企業環境でのCline利用
チームでClineを使う際に考慮すべきセキュリティポイント：
| リスク | 対策 |
|---|---|
| APIキーの漏洩 |
.env を .gitignore に追加。CI/CDはSecretsを使用 |
| コードの外部送信 | プロプライエタリコードをLLMに送信するポリシーを確認 |
| 意図しない変更 | Auto-Approveは限定的に使用。重要ファイルは手動承認 |
| 機密データの含まれるファイル |
.clineignore ファイルでLLMへの送信を制限 |
.clineignore の設定
# .clineignore
# 機密情報を含むファイル
.env
.env.*
secrets/
credentials/
*.pem
*.key
*.p12
# 大きすぎるファイル（コンテキスト節約）
node_modules/
dist/
build/
*.log
coverage/
.next/
# バイナリファイル
*.png
*.jpg
*.gif
*.pdf
*.zip
まとめ
上級者がClineを使い倒すための要点：
- MCPは複数組み合わせる — GitHub、Jira、社内API等を連携させてClineの能力を最大化
-
カスタムMCPを構築する — 既存ツールで足りなければ
@modelcontextprotocol/sdkで独自拡張 -
.clinerulesをチームで共有する — プロジェクトルールを明文化してAIの行動を統一 - CI/CDにはClaude Codeを使う — Clineはインタラクティブ作業、Claude Codeは自動化に使い分け
- コストを意識する — 軽いタスクはHaikuモデル、重いタスクはOpusモデルと使い分け
次のステップとして、実際にカスタムMCPを1つ構築してみることをおすすめします。自分のチームの開発フローに最適化されたMCPは、生産性を大幅に向上させます。