AIコーディングエージェント 2026.05.31 更新: 2026.06.01

Clineをチームで使う前に：Auto Approve・MCP Marketplace・.clinerulesを分ける基準

3行まとめ

VisualCline導入の5つの承認読む、編集、実行、browser、MCPを分けます。

Read

workspace内のreadから始める。

Edit

project filesに限定して開く。

Command

safeとallを分けて扱う。

MCP

toolごとに配布元と権限を見る。

Clineは、どこまで無確認にするかを細かく決めるagentです。

Clineは、read、edit、command、browser actions、MCP toolsを細かくAuto Approveできます。便利ですが、最初から全部を無確認にしないことが大事です。
初回はread-only寄りで始め、edit project files、safe commands、all commands、browser、MCP toolsを別々にreviewします。特にall commandsとworkspace外編集は強い権限として扱います。
MCP Marketplaceやremote MCP serverは、配布元、実行権限、credential、削除手順を見ます。.clinerules はtool選択とteamの作業基準を明文化するために使います。

本文の事実確認には、Cline公式docsのAuto Approve、MCP configuration、MCP Marketplace、remote server、CLI interactive mode、SDK permission handling、Cline GitHub repositoryを使っています。Xで見かけるCline、auto-approve、MCP marketplace、.clinerules への投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

Visual導入前に決める項目チームで迷いやすい判断です。

Approve

自動承認する範囲を決める。

Rules

.clinerulesに置く基準。

Marketplace

MCP serverの配布元を確認。

Remote

remote MCPの信頼を確認。

先に承認境界を決めると、自動化してよい操作が見えます。

ClineのAuto Approveをread/edit/command/browser/MCPで分ける考え方
read all files、edit all files、execute all commandsを初回から避ける理由
MCP Marketplaceとremote MCP serverを導入前に見る観点
.clinerules に置く作業基準とMCP rulesの使い方
CLI/SDKでauto-approveを扱う時の注意
初週にどこまで自動承認すればよいか

Clineは、AI coding agentとしてeditor、CLI、SDKの形で使えます。特徴的なのは、何を自動承認するかを細かく決められることです。毎回承認する運用も、自動で走らせる運用も選べます。

この記事では、Clineをチームへ入れる前に、承認範囲、MCP server、Marketplace、.clinerules を分けて整理します。

前提知識

Visual公式docsで見る対象この記事で扱うCline機能です。

項目	内容	見方
Auto Approve		toolごとの承認設定。
MCP		外部toolやdata source。
Marketplace		MCP serverを探して導入。
Rules		tool選択や作業基準を補助。

Clineの強さは、自律性と承認境界を同時に調整できる点です。

Cline公式overviewでは、Clineをeditor内で動くopen-source AI coding agentとして説明しています。VS Code、Cursor、JetBrains、CLIで使え、MCP serversでdatabase、API、documentationなど外部toolへ接続できます。

Auto Approve docsでは、Clineがfile read、file edit、terminal command、browser actions、MCP toolsなどのtool call前に承認を求め、必要ならカテゴリごとにauto-approveできると説明されています。GitHub READMEでも、file editやterminal commandには承認が必要で、auto-approveを有効にすると自律的に進められると説明されています。

この記事の扱う範囲

項目	役割
Auto Approve	Clineが承認なしで実行できるtoolカテゴリを決める
Read permissions	project files、all filesの読み取り範囲
Edit permissions	project files、all filesの変更範囲
Command execution	safe commands、all commandsの実行範囲
Browser actions	browser操作や認証済み画面の扱い
MCP tools	external APIやdata sourceを使うtool権限

2026年5月31日時点で公開されているCline公式docsとGitHub repositoryを確認しています。導入時には、利用中のCline version、IDE/CLI、teamのAI tool policy、MCP serverの接続先、secret管理を確認してください。

注意点

この記事は、Clineを全自動で長時間走らせるための記事ではありません。まず承認promptを残し、どの操作を無確認にしてよいかを小さく確認する前提です。

まず5つの承認に分ける

Visual承認分類何を無確認にするかで分けます。

項目	内容	見方
Read		fileを読む範囲。
Edit		fileを変更する範囲。
Command		terminal commandの実行。
Browser		browser操作の自動化。
MCP		external toolの実行。

全部auto-approveではなく、操作カテゴリごとに開きます。

ClineのAuto Approveは、最初に5つへ分けて考えます。

承認	内容	初期方針
Read	fileを読む	workspace内から始める
Edit	fileを変更する	project filesに限定して試す
Command	terminal commandを実行する	safe commandsだけ慎重に検討
Browser	browser actionsを実行する	初回は手動承認
MCP	external toolsを使う	serverごとにreview

この分類をせずに「auto-approveを入れる」と、何が無確認で実行されるのか分からなくなります。Clineは細かく開けるからこそ、カテゴリごとに決めます。

全部入りで始めない

read all files、edit all files、execute all commandsを同時に開くと、Clineはworkspace外のfileを読み書きし、任意commandを実行できる状態に近づきます。初回導入では避けます。

承認を記録する

teamで使うなら、どのauto-approveを許可しているかをREADME、AGENTS.md、.clinerules、運用docのどこかに残します。個人のlocal設定だけに閉じると、team標準として再現できません。

Read権限はworkspace内から始める

VisualRead権限の段階読ませる範囲を広げすぎません。

Project

current workspace内だけ読む。

All files

system fileまで広がる。

Ignore

secretやprivate fileを除外。

Review

読ませる範囲を定期確認。

readは安全に見えますが、secretやlocal configを含む可能性があります。

Auto Approve docsでは、Read project filesとRead all filesが分かれています。Read project filesはcurrent workspace内、Read all filesはworkspace外のsystem filesやconfig filesまで広がると説明されています。

readは安全そうに見えますが、secret、local config、SSH設定、personal notes、tokenを含むfileが読まれる可能性があります。最初はworkspace内に限定します。

Read権限の段階

段階	扱い
manual read	Clineが読む前に承認する
read project files	workspace内だけauto-approve
read all files	workspace外も読むため別review
ignore rules	secretやprivate fileを除外

workspace外は別レビュー

workspace外を読む必要がある場合、なぜ必要なのかを説明します。たとえばglobal configやSDK cacheが必要な場面はありますが、初回から開くものではありません。

Edit権限はproject filesに限定する

VisualEdit権限の境界変更できる範囲を決めます。

項目	内容	見方
Project files		workspace内の変更に限定。
All files		workspace外は原則避ける。
Generated		生成物やlockfileを確認。
Review		diffを人間が見る。

edit auto-approveは、diff reviewとrollbackを前提にします。

Edit project filesはworkspace内の変更を無確認にできます。Edit all filesはworkspace外の変更まで広がります。チーム導入では、まずeditを手動承認にし、必要になったらproject filesだけを限定的に開きます。

Edit権限で見るもの

観点	確認すること
scope	workspace内か、workspace外か
generated files	lockfile、snapshot、build output
rollback	git diffで戻せるか
review	PR前に人間がdiffを見るか

edit all filesは強い権限

workspace外のfile変更は、editor設定、shell profile、SSH config、global package manager設定などに触れる可能性があります。原則としてteam標準では開きません。

判断基準

auto-approve editを開くなら、変更対象をproject filesに限定し、git管理下のdiffとしてreviewできることを前提にします。

Command実行はsafeとallを分ける

VisualCommand承認の段階terminal実行のriskです。

項目	内容	見方
Safe		modelが安全と判断するcommand。
All		任意commandを許可する強い設定。
Timeout		長時間実行の通知を見る。
Deny		deployやsecret表示は除外。

all commandsは便利ですが、最初から開く設定ではありません。

Auto Approve docsでは、Execute safe commandsとExecute all commandsが分かれています。safe commandsはmodelがnon-destructiveと判断するcommand、all commandsは任意commandの実行を許可する強い設定です。

command実行は、agent運用で一番事故りやすい領域です。lintやtestは便利ですが、deploy、rm、chmod、curl、secret表示、package publishなどは強い影響を持ちます。

command承認の段階

段階	扱い
manual command	初期導入の基本
safe commands	lint、test、typecheckなどから検討
all commands	原則避け、必要なら別レビュー
deny list	deploy、prod操作、secret表示を禁止

safeを過信しない

safe commandsは便利ですが、model判断に依存します。npm test がpostinstallやscriptを通じて外部commandを走らせることもあります。safe扱いにするcommandは、projectごとに確認します。

Browser actionsとMCP toolsは別レビューにする

Visual追加toolの見方Cline外の操作能力です。

Browser

web操作や認証済み画面。

MCP tools

外部APIやdatabase。

Credentials

tokenやenvを確認。

Audit

tool callの記録を残す。

browserとMCPは、file編集とは別の権限としてreviewします。

Browser actionsとMCP toolsは、file編集やcommand実行とは別の権限です。browserは認証済み画面やweb操作へ近づきます。MCP toolsはexternal API、database、filesystem、cloud service、browser automationなどへつながります。

別レビューにする理由

領域	risk
browser actions	ログイン済みsession、PII、社内画面
MCP tools	token、write API、database操作
remote MCP	信頼元、network、credential
marketplace server	配布元、更新、削除手順

MCP serverは便利な拡張ではありますが、tool権限です。ClineのMCP docsでも、external APIs and servicesへ接続し、custom toolsを追加できると説明されています。

MCP Marketplaceは配布元の信頼で分ける

VisualMarketplace導入の確認点serverを入れる前に見ます。

項目	内容	見方
Source		official、community、自社server。
Install		one-clickかmanualか。
Remote		remote serverは信頼元を確認。
Remove		削除と再install手順。

Marketplaceは便利な入口ですが、MCP serverの実行権限も一緒に見ます。

ClineのMCP docsでは、Marketplaceからone-click installできる場合がある一方、manual追加もできると説明されています。Marketplaceは便利ですが、serverの配布元と権限を見ないまま入れないようにします。

Marketplaceで見るもの

観点	確認すること
source	official、community、自社server
install	marketplaceかmanualか
credentials	envやtokenの扱い
tools	read-onlyかwrite可能か
remove	uninstallとconfig削除手順

Cline docsでは、server削除時にsettings fileやlocal directoryの両方を確認する話も出ています。うまく消せないserverは、後で管理負荷になります。

remote serverは信頼元を見る

remote MCP serverへ接続する場合、Cline docsは信頼できるsourceであることを確認するよう注意しています。remote serverはlocal commandより楽に見えますが、接続先、認証、data送信、tool実行権限を確認します。

.clinerulesはtool選択と作業基準に使う

Visual.clinerulesに置くものClineへ渡す基準です。

MCP rules

serverの使いどころを明確に。

Project rules

testやreview基準。

Keywords

tool selectionのtrigger。

Boundaries

禁止操作とscope。

.clinerulesは、Clineの自律性をteam基準へ寄せるために使います。

ClineのMCP Marketplace docsでは、.clinerules やcustom instructionsを使い、MCP server activationをkeyword-based triggerで支援できると説明されています。MCP Rulesは、connected MCP serversを機能カテゴリへgroup化し、trigger keywordsで使いどころを明確にできます。

.clinerules は、Clineに「どのtoolをいつ使うか」「このrepoではどう作業するか」を伝える場所です。

.clinerulesに置くもの

種類	例
MCP rules	docs調査はdocs server、browser確認はbrowser server
project rules	test command、directory責務、review基準
boundaries	secret、prod操作、workspace外編集の禁止
output	PR summary、tests、risksの書き方

AGENTS.mdとの関係

複数agentを使うteamでは、repo横断の基準をAGENTS.mdに置き、Cline固有のtool選択を .clinerules に置くと管理しやすくなります。AGENTS.mdの設計は、チーム向けAGENTS.mdテンプレートでも整理しています。

最小構成の始め方

Visual最初の構成小さく始める形です。

項目	内容	見方
Read only		read auto-approveから始める。
Manual edit		editは確認付き。
Safe commands		限定的に検討。
No MCP		初回はMCPなしで確認。

最初は承認promptを残し、何を任せてよいか観察します。

最初は、Clineの承認promptを残します。read-only寄りでrepo理解を試し、.clinerules を1つ作り、editやcommandは手動承認にします。

最初の構成

.clinerules
AGENTS.md

.clinerules にはCline固有のtool選択と作業基準を置きます。AGENTS.mdには、他agentにも共通する禁止操作、test command、review基準を置きます。

初回に開かないもの

edit all files
execute all commands
browser actionsのauto-approve
MCP toolsのauto-approve
remote MCP serverの無審査導入
workspace外read

最初は、Clineが何を読もうとして、何を変更しようとして、どのcommandを実行しようとするかを観察します。

導入初週の進め方

Visual1週間の導入順承認範囲を段階的に広げます。

1日目
read-onlyでrepo理解を試す。
2日目
.clinerulesを1つ作る。
3日目
edit project filesを限定試行。
5日目
safe commandsを棚卸し。
7日目
MCP Marketplace候補をreview。

初週はauto-approveを広げるより、承認の型を作ります。

初週は、Clineを自律的に走らせる週ではありません。承認境界を作る週です。

日	やること	完了条件
1日目	read-onlyでrepo理解を試す	read範囲を説明できる
2日目	`.clinerules` を1つ作る	tool選択と禁止操作が書かれている
3日目	edit project filesを限定試行	diffを人間がreviewできる
5日目	safe commands候補を棚卸し	lint/test/typecheckが分かれる
7日目	MCP Marketplace候補をreview	source、tools、secret、remove手順が分かる

拡大する条件

read/editの範囲を説明できる
all commandsを開かずに価値が出ている
.clinerules が短く保たれている
MCP serverごとの権限を説明できる
PR前に人間reviewが残っている

この条件を満たしてから、auto-approve範囲を少しずつ広げます。

FAQ

Visualよくある迷いCline導入で詰まりやすい点です。

Auto approve?

readから段階的に開く。

All commands?

初回は避ける。

Marketplace?

配布元とtool権限を見る。

Rules?

tool選択と基準を明文化。

迷ったら、Clineが無確認で何を実行できるかを見ます。

Auto Approveは使わない方が安全ですか

使わない方が単純ですが、作業効率は下がります。初回はread-only寄りで始め、editやcommandは手動承認にし、必要なカテゴリだけ段階的に開くのが現実的です。

Execute all commandsを開いてよいですか

初回導入では避けます。safe commandsでもprojectごとに確認が必要です。all commandsは、sandbox、deny list、review、rollbackが整ってから別レビューにします。

MCP Marketplaceのserverは安全ですか

Marketplaceにあることだけでは判断できません。配布元、tools、credential、read/write権限、削除手順を確認します。remote serverは信頼元とdata送信も見ます。

.clinerulesとAGENTS.mdはどう分けますか

Cline固有のtool選択やMCP rulesは .clinerules、agent横断のrepo基準はAGENTS.mdです。複数agentを使うなら、禁止操作やtest commandはAGENTS.mdへ寄せます。

ClineとContinue.devはどう使い分けますか

Clineはapproval granularityとautonomous agent操作に寄せて考えます。Continue.devはconfig.yamlでmodels、rules、prompts、context、MCP toolsを組み合わせるassistantとして考えます。Continue.dev側はContinue.devをチームで使う前にで整理しています。

参照した主な情報源

Cline Docs: What is Cline?

https://docs.cline.bot/introduction/overview

Cline Docs: Auto approve

https://docs.cline.bot/features

Cline Docs: MCP

https://docs.cline.bot/mcp/configuring-mcp-servers

Cline Docs: MCP Made Easy / Marketplace

https://docs.cline.bot/mcp/mcp-marketplace

Cline Docs: Connecting to a Remote Server

https://docs.cline.bot/mcp/connecting-to-a-remote-server

Cline GitHub repository

https://github.com/cline/cline

次に読むなら

Continue.devをチームで使う前に

Clineと近いopen-source assistantを、config.yaml、rules、MCP、contextの観点で比較できます。

チーム向けAGENTS.mdテンプレート

Cline以外のagentにも効く禁止操作、test command、review基準をrepo側へ残す考え方です。

MCP更新で壊さないための確認手順

ClineへMCP serverを追加する前に、仕様、SDK、認可、Toolsの見方を整理できます。

更新履歴

Visual確認と更新の記録Clineは更新されるため確認日を残します。

2026年5月31日
Cline公式docsのAuto Approve、MCP、Marketplace、CLI/SDK permission情報を確認して初版を作成しました。

導入時には公式docsと利用中のCline versionを確認してください。

2026年5月31日: Cline公式docsのAuto Approve、MCP、Marketplace、CLI/SDK permission情報を確認し、初版を作成しました。