Clineのシステムプロンプトを読む
Clineとは
ClineはVSCodeやCursorの拡張機能として利用可能な開発支援全般を自律的に行うAIエージェントです。拡張機能をインストールして、利用したいLLMのAPIキーを入力するだけで利用可能です。ローカルLLMでの実行も可能です。
Clineの内部構成について知りたい方は、先ずは以下の記事を読まれることをおすすめします。
全体感を踏まえた大変分かりやすい記事でした。
本稿は、Clineのシステムプロンプト部分のみに焦点を当てた内容となっています。
ClineをAIエージェントとして成立させているシステムプロンプト
Clineは非常に気持ち良く動作するAIエージェントです。
どのように構成されているのか興味を持ったためソースコードに目を通してみたところ、非常に詳細で長文のシステムプロンプトによって、Clineは賢明なエージェントとして成立しているようでした。
Clineはユーザーからの指示を受けた後、目的を実現するためにタスクを複数のステップに分解し、各ステップで各種ツールを活用しながらアクションを実行します。各ステップの実行時には、毎回こちらのシステムプロンプトとツールの実行結果を含む状況データなどがLLMに渡されているように見えます。
該当のシステムプロンプトは src/core/prompts/system.ts に記載されています。
非常に長文なファイルとなっており、全文61,626文字で構成されています。（2025/03/04時点）（一部、TypeScriptコード部分を含む）
プロンプトの記法
内容に入る前にシステムプロンプトの記法について触れます。
システムプロンプトは複数の章によって構成されているのですが、章ごとに ==== で区切られて一つのドキュメントのように扱われています。
====
{章のタイトル}
# 見出し1
## 見出し2
...
====
{章のタイトル}
# 見出し1
## 見出し2
...
====
...
システムプロンプトの目次
続いて、システムプロンプトの目次です。以下9つの章で構成されています。
※実際のシステムプロンプト内においては章番号は振られていません。便宜的に付与したものです。
- TOOL USE（ツールの使用）
- MCP SERVERS（MCPサーバー）
- EDITING FILES（ファイル編集）
- ACT MODE V.S. PLAN MODE（実行モード vs 計画モード）
- CAPABILITIES（能力）
- RULES（ルール）
- SYSTEM INFORMATION（システム情報）
- OBJECTIVE（目的）
- USER'S CUSTOM INSTRUCTIONS（ユーザーによるカスタム指示）
システムプロンプトの内容
ここからは具体的にシステムプロンプトの内容に入っていきます。
各章の内容について順に触れていきますが、システムプロンプトの構成的には、8章および9章から読み始めて、1章に戻って順に読んでいくと理解しやすいと思います。
序文
システムプロンプトの冒頭に一文だけ、Clineのプロフィール文章が記載されています。
--
あなたは多数のプログラミング言語、フレームワーク、デザインパターン、ベストプラクティスに精通した高いスキルを持つソフトウェアエンジニアであるClineです。
--
1. TOOL USE（ツールの使用）
本章の位置づけ
この章ではClineが利用可能なツールの内容について細かく定義されています。
プロンプト全文の中で最も文章量の多い章となっています。
Clineは様々なツールを利用することによって、プロジェクトの情報を把握したり環境に対して適切なアクションを実行したりすることができます。
例えば、Clineが特定のファイルのコードを編集する際には、 read_file というツールでファイルを読み取った後に、該当のファイルに対して replace_in_file というツールを利用してコードの一部を書き換えます。
内容
はじめにツールの利用に関して以下の文章が記載されています。（以下意訳）
--
あなたはツール群を利用可能です。これらはユーザーの承認後に実行できます。
メッセージごとに1つのツールを使用でき、ユーザーの応答でそのツールの使用結果を受け取ります。
ツールは、指定されたタスクを達成するために順を追って使用し、直前のツールの使用結果を受けて各ツールの使用が決定されます。
--
Tool Use Formatting（ツール使用の書式）
ここではツール選択の際の出力形式について説明されています。（以下意訳・一部省略）
Clineがツールを選択して使用する際には、LLMに該当のツール名と引数に渡す値をXMLで出力させる仕様となっています。
--
ツールの使用はXMLスタイルのタグを使用してフォーマット化されます。ツール名は開始タグと終了タグで囲まれ、各パラメータも同様に同時のタグセットで囲まれます。
<tool_name>
<parameter1_name>value1</parameter1_name>
<parameter2_name>value2</parameter2_name>
...
</tool_name>
例: read_file （ファイル読み込み）ツールを利用する場合
<read_file>
<path>src/main.js</path>
</read_file>
--
Tools（ツール）
ここでは各ツールについて、主に以下の3つの事項が説明されています。
-
Description: ツールの内容説明 -
Parameters: 各パラメータ引数の説明 -
Usage: 使用例（XMLの出力例）
以下の表にツール説明だけ要約して簡単にまとめます。
| No | ツール名 | 説明 |
|---|---|---|
| 1 | execute_command | CLIコマンドを実行。システムオペレーションやタスク実行に使用。 |
| 2 | read_file | ファイル内容の読み取り。コード分析やテキスト抽出に使用。pdfやdocxもロード可能。 |
| 3 | write_to_file | 新規ファイル作成または既存ファイルの上書き。ディレクトリも自動作成。 |
| 4 | replace_in_file | 既存ファイルの特定部分を変更。SEARCH/REPLACE ブロックで変更箇所を表現。 |
| 5 | search_files | ディレクトリ内のファイルを正規表現で検索。複数のファイルを対象にパターンまたは特定のコンテンツを検索。 |
| 6 | list_files | ディレクトリ内のファイルとディレクトリ一覧を取得。再帰的に一覧表示することも可能。 |
| 7 | list_code_definition_names | 指定したディレクトリのトップレベルにあるソースコードの定義名（クラス、関数、メソッド等）を一覧表示。 |
| 8 | browser_action | Puppeteerによるブラウザの操作。（起動、クリック、タイプ、スクロール等） |
| 9 | use_mcp_tool | MCPサーバーが提供するツールの実行要求。 |
| 10 | access_mcp_resource | MCPサーバーが提供するリソースへのアクセス要求。 |
| 11 | ask_followup_question | ユーザーに追加情報を質問。 |
| 12 | attempt_completion | タスク完了を宣言し結果をユーザーに提示。必要に応じてデモコマンドも実行可能。 |
| 13 | plan_mode_response | ユーザーの質問に対して、タスクをどのように完了させる計画か回答する。PLAN MODE でのみ利用可能。 |
Tool Use Examples（ツールの使用例）
ここでは各種Toolを利用する場合の、XMLの出力例が改めて記載されています。
--
例1: CLIコマンドの実行
<execute_command>
<command>npm run dev</command>
<requires_approval>false</requires_approval>
</execute_command>
例2: 新規ファイルの作成
<write_to_file>
<path>src/frontend-config.json</path>
<content>
{
"apiEndpoint": "<https://api.example.com>",
"theme": {
"primaryColor": "#007bff",
"secondaryColor": "#6c757d",
"fontFamily": "Arial, sans-serif"
},
"features": {
"darkMode": true,
"notifications": true,
"analytics": false
},
"version": "1.0.0"
}
</content>
</write_to_file>
例3: ファイルの編集
<replace_in_file>
<path>src/components/App.tsx</path>
<diff>
<<<<<<< SEARCH
import React from 'react';
=======
import React, { useState } from 'react';
>>>>>>> REPLACE
<<<<<<< SEARCH
function handleSubmit() {
saveData();
setLoading(false);
}
=======
>>>>>>> REPLACE
<<<<<<< SEARCH
return (
<div>
=======
function handleSubmit() {
saveData();
setLoading(false);
}
return (
<div>
>>>>>>> REPLACE
</diff>
</replace_in_file>
例4: MCPツールの利用
<use_mcp_tool>
<server_name>weather-server</server_name>
<tool_name>get_forecast</tool_name>
<arguments>
{
"city": "San Francisco",
"days": 5
}
</arguments>
</use_mcp_tool>
例5: MCPリソースへのアクセス
<access_mcp_resource>
<server_name>weather-server</server_name>
<uri>weather://san-francisco/current</uri>
</access_mcp_resource>
例6: MCPツールの使用例（サーバー名がURLのような一意の識別子である場合）
<use_mcp_tool>
<server_name>github.com/modelcontextprotocol/servers/tree/main/src/github</server_name>
<tool_name>create_issue</tool_name>
<arguments>
{
"owner": "octocat",
"repo": "hello-world",
"title": "Found a bug",
"body": "I'm having a problem with this.",
"labels": ["bug", "help wanted"],
"assignees": ["octocat"]
}
</arguments>
</use_mcp_tool>
--
Tool Use Guideline（ツールの利用ガイドライン）
ここでは各種Toolの利用におけるガイドラインが記載されています。（以下意訳・一部省略）
--
-
<thinking>タグでは、既に持っている情報とタスクを進めるために必要な情報を評価する。 - タスク内容と提供されたツール説明に基づいてツールを選択する。タスクを進めるために追加の情報が必要かどうかを評価して、利用可能なツールの内、最も効果的なものを選ぶ。たとえばターミナルで
lsのようなコマンドを実行するよりも、list_filesツールを使用する方が効果的である。 - 複数アクションが必要な場合は、メッセージごとに1つのツールを順次使用して、タスクを反復的に実行すること。各ツールの使用は、前回のツール使用の結果に基づいて行うこと。
- 各ツールで指定されたXMLフォーマットを使用すること。
- 各ツールの使用後、ユーザーはそのツールの利用結果を回答する。この結果はタスクを継続したり、さらなる決定を行うための必要な情報を提供する。
- ツールが成功したか失敗したか、また失敗した場合はその理由に関する情報。
- 加えた変更により発生した可能性のあるlinterエラー。これに対処する必要がある。
- 変更に伴う新しいターミナルの出力。これについては考慮または対応が必要な場合がある。
- ツールの使用に関連するその他のフィードバックまたは情報。
- ツール使用後は、常にユーザーの確認を待ってから次に進むようにする。
ツール使用の度にユーザーからのメッセージを待ち、タスクを進める前に一歩ずつ進むことが重要です。このアプローチより以下のことが可能になります。
- 進む前に各ステップの成功を確認する。
- 発生した問題やエラーに即座に対処する。
- 新しい情報や予期せぬ結果に基づいてアプローチを修正する。
- 各アクションが前のアクションに正しく基づいていることを確認する。
--
2. MCP SERVERS（MCPサーバー）
本章の位置づけ
この章ではMCPサーバーに関する説明が書かれています。
ClineではユーザーがMCPサーバーにて独自に用意したツールを利用することも可能です。
また、既存のMCPサーバーの利用だけでなく、MCPサーバーの追加や編集をユーザーがClineに依頼することも踏まえてプロンプトが記載されています。
また、こちらのシステムプロンプトを読む限り、本章に限らずMCPサーバーに関連する記述はClineの設定項目のMcpModeが off になっている環境では、プロンプトに埋め込まれないよう工夫されているように見えます。
内容
はじめに以下の1文が記載されています。
--
MCPは、システムとローカルで実行中のMCPサーバー間の通信を可能にします。MCPサーバーは、機能拡張のための追加ツールやリソースを提供します。
--
Connected MCP Servers（接続済みMCPサーバー）
ここでは、現在接続されているMCPサーバーの情報が定義されます。
接続されているMCPサーバーから以下の情報を取得してここでプロンプトに埋め込みます。
- MCPサーバー名
- ツール名やそれらのinputスキーマ
- リソースやリソーステンプレートの情報
--
MCPサーバーが接続されている場合、use_mcp_tool ツールを使用してMCPサーバーのツールを使用
し、access_mcp_resource ツールを使用してMCPサーバーのリソースにアクセスできます。
{上記したMCPサーバーから取得した情報がここで埋め込まれます}
--
Creating an MCP Server（MCPサーバーの作成）
ここではユーザーがMCPサーバーの追加依頼するケースがあることについて記載されています。
天気情報を取得するMCPサーバーの作成を例として、必要となるコマンド処理のステップやTypeScriptのコード例が非常に詳細に記載されています。詳細内容は省略します。
Editing MCP Servers（MCPサーバーの編集）
ここではユーザーが既存のMCPサーバーに機能追加を依頼するケースがあることについて記載されています。
ファイル検索には list_files と read_file を利用し、ファイルに変更を加える際には replace_in_file が利用可能であるという内容が記載されています。
MCP Servers Are Not Always Necessary（MCPサーバーが常に必要というわけではない）
ここでは、常にMCPサーバーの利用が必要ではなく、既に既存の幅広いツールが利用可能であることを忘れないようにということが強調されています。
3. EDITING FILES（ファイル編集）
本章の位置づけ
この章ではファイルに対して編集を行う役割が重複しているツールである replace_in_file と write_to_file の使い分けについて、1章分を費やして詳細に記載されています。
Clineの動作を快適に感じる一因として replace_in_file ツールの挙動によるものがあると思います。replace_in_file ツールはファイルの編集を行うツールですが、変更や追加を行う部分の差分を可視化しながら修正提案をしてくれます。
本章のプロンプトでは、なるべく replace_in_file を利用することを推奨しながらも、新規ファイルを作成したり、ファイルごと書き直すような大幅な変更をしたりする場合には、write_to_file を利用する必要があることが記載されています。
内容
write_to_file
ここでは write_to_file ツールを利用する目的やタイミングについて説明されています。（以下意訳）
--
- 目的
- 新しいファイルを作成するか、既存のファイルのすべての内容を上書きする。
- 使用するタイミング
- 新規プロジェクトの足組みような、最初のファイル作成
- すべてのコンテンツを一度に置き換えたい場合
- 変更の複雑さや数によって
replace_in_fileが利用しづらい場合 - ファイルのコンテンツを完全に再構築したり、その基本的な構成を変更したりする必要がある場合
- 重要な事項
-
write_to_fileを利用する場合は、ファイルの最終的な完全なコンテンツを提供する必要がある。 - 既存のファイルに小さな変更を加えるだけで良い場合は、まず
replace_in_fileを利用すること。 -
write_to_fileはデフォルトの選択肢として利用するべきではないが、必要な場合はためらわず利用すること。
-
--
replace_in_file
ここでは replace_in_file ツールを利用する目的やタイミングについて説明されています。（以下意訳）
--
- 目的
- 既存のファイルの特定の部分のみを編集する。
- 使用するタイミング
- 数行の更新、機能の実装、変数名の変更、テキストの一部修正など、局所的な修正。
- ファイルの特定部分のみを変更する的を絞った改善。
- ファイルの大分部を変更しないままにしておきたいときに特に有用。
- 利点
- ファイル全体を指定する必要がなく、軽微な編集に効率的である。
- 大きなファイルを上書きする際に発生するエラー可能性を低減する。
--
Choosing the Appropriate Tool（適切なツールの選択）
ここではこの2つのツールの使い分けについて、改めて説明が追加されています。（以下意訳）
--
- ほとんどの変更には
replace_in_fileをデフォルトで使用する。これは潜在的な問題を最小限に抑える、より安全で正確なオプションである。 -
write_to_fileを利用するのは以下のケース。- 新しいファイルを作成する場合。
- 変更が非常に広範囲にわたるため、
replace_in_fileを使用すると複雑または危険になる場合。 - ファイルを完全に再編成または再構築する必要がある場合。
- 雛形やテンプレートファイルを生成する場合。
--
Auto-formatting Considerations（自動フォーマットに関する考慮事項）
ここでは write_to_file または replace_in_file を利用してファイルを編集した後に、ユーザーのエディタによって、編集したコードが自動フォーマットされる可能性について書かれています。
内容は割愛しますが、write_to_file または replace_in_file ツールのレスポンスには、自動フォーマット後のコード内容が含まれるため、その内容を踏まえた上でその後の編集を行うべきであることが指示されています。
Workflow Tips（ワークフローのTips）
ここでは再々度 write_to_file と replace_in_file の使い分け方について記載されています。
--
- 編集を行う前に、変更の範囲を評価し、どのツールを使用するかを決定する。
- 対象を絞った編集を行うには
SEARCH/REPLACEブロックで
replace_in_fileを適用します。複数の変更が必要な場合は、1回のreplace_in_file呼び出しの中で複数のSEARCH/REPLACEブロックを指定可能。 - 大規模な修正や初期ファイルの作成には、
write_to_fileを使用する。 -
write_to_fileまたはreplace_in_fileを使用してファイルが編集されると、システムは変更後のファイルの最終状態を提供する。この更新されたコンテンツは、自動フォーマットやユーザーによる変更を反映しているため、その後のSEARCH/REPLACE操作の基準点として使用する。
write_to_file と replace_in_file を慎重に選択することで、ファイル編集プロセスをより安全に効率的に行うことができます。
--
4. ACT MODE V.S. PLAN MODE （実行モード vs 計画モード）
本章の位置づけ
この章ではClineの2つのモードである ACT MODE と PLAN MODE について説明が記載されています。
内容
はじめに ACT MODE と PLAN MODE について簡単な説明が記載されています。（以下意訳・一部省略）
プロンプト内に登場する environment_details は、VSCodeで開いているファイルなどの情報、ターミナルの情報、本章で説明される動作モードなどの環境情報が記載されている箇所のことを指しています。システムプロンプト全文と合わせてLLMに渡される情報です。
--
各ユーザーメッセージでは、environment_details に現在のモードが指定されています。
モードには2種類あります。
-
ACT MODE：このモードでは、
plan_mode_responseツール以外のすべてのツールを使用可能。-
ACT MODEではユーザーのタスクを完遂するために各種ツールを使用可能。ユーザーのタス
クが完了したら、attempt_completionツールを使用して、タスクの結果をユーザーに提示すること。
-
-
PLAN MODE：この特別なモードでは
plan_mode_responseツールを使用可能。-
PLAN MODEは、タスクを達成するため情報の収集と文脈の取得が目的である。ユーザーはソリューションを実行するためにACT MODEに切り替える前にその計画を検討し承認する。PLAN MODEでユーザーと会話したり計画を提示する必要がある場合は、plan_mode_responseツールを使用して直接応答を伝えること。
-
--
What is PLAN MODE?（PLAN MODEとは？）
PLAN MODE についての追加の説明が続きます。（以下意訳）
--
- 通常は
ACT MODEですが、タスクを最も効果的に達成する方法を計画するために、ユーザーがPLAN MODEに切り替えることがある。PLAN MODEを開始する際には、ユーザーの要求に応じて、例えばread_fileやsearch_filesを使用してタスクに関するより詳しいコンテクストを取得するために、情報収集を行う必要があるかもしれない。また、タスクをよりよく理解するために、ユーザーに明確化のための質問をすることも可能。Mermaidダイアグラムを返して、視覚的な理解を示すことも可能。 - ユーザーのリクエストに関するより詳しい背景情報を得たら、タスクをどのように達成するかの詳細な計画を立てる。この場合もMermaidを返すと役立つ。
- その後、ユーザーにこの計画に満足しているか、あるいは変更したい点があるかを尋ねること。これは、タスクについて話し合い、それを達成する最善の方法を計画するブレインストーミングセッションだと考えること。
- Mermaidダイアグラムがあなたの計画をより明確にし、ユーザーが構造を素早く理解するのに役立つ場合、レスポンスにMermaidコードブロックを含めることをお勧めする。（注：Mermaidダイアグラムに色を使用する場合は、テキストが読み取れるように、コントラストの高い色を使用すること。）
- 最終的に良い計画に達したと思われる場合、ソリューションを実装するために
ACT MODEに戻すようユーザーに依頼すること。
--
5. CAPABILITIES（能力）
本章の位置づけ
1章や2章では各ツールのそれぞれの機能説明が行われていましたが、本章では各ツールがどのような目的を達成する場合に利用が推奨されるものかという具体的な説明を踏まえた用途が記載されています。
特に、Clineの主なユースケースであるコードの編集や改善を実現する場合を例に、目的を達成するために各ツールを利用したアクションのステップ例が初めて具体的に記載されているのが印象的でした。
内容
以下の内容が記載されています。（以下意訳・一部省略）
--
- CLI実行、ファイルのリストを表示、ソースコードの定義を表示、正規表現ファイル検索、ブラウザの使用、ファイルの読み込み・編集、追加の質問実行が可能。これらのツールは、コードの記述、既存フィアルの編集や改善、プロジェクトの現状の把握、システム操作など、幅広いタスクを効果的に行うために利用可能である。
- プロジェクトのファイルパス構造が
environment_detailsに含れる。ディレクトリ名、ファイル名、拡張子からプロジェクトに対する洞察を得ることができる。また、どのファイルを詳しく調査すべきであるかという意思決定の指針にもなる。加えて、現在の作業中のディレクトリ以外を詳しく調査する場合にはlist_filesツールを使用できる。 -
search_filesを使用すると、指定したディレクトリに対して正規表現による検索を実行することが可能であり、コードパターンを理解したり、特定の実装を見つけたり、リファクタリングが必要な領域を特定したりする際に便利である。 -
list_code_definition_nameを利用すると、指定したディレクトリの最上位レベルにあるすべてのファイルのソースコードの定義を取得可能である。コードの特定の部分に関するより広範なコンテキストや関連性を理解する必要がる場合に役立つ。複数回呼び出してタスクに関連するコードベースの様々な理解を必要とする場合もある。- 例えば編集や改善を求められた場合:
-
environment_detailsに記載されているファイル構造を分析 -
list_code_definition_namesを使用して関連ディレクトリに存在するソースコードの定義を詳しく調査 - 関連ファイルの内容を
read_fileで確認してコードを分析 - 改善点を提案したり、必要な編集を検討して、
replace_in_fileツールを利用して変更実装 - コードベースの他の部分に影響を与える可能性のあるコードをリファクタリングした場合には、必要に応じて他のファイルを変更するために
search_filesを使用
-
- 例えば編集や改善を求められた場合:
- 必要があれば
execute_commandツールを用いてユーザーのコンピュータ上でコマンドを実行可能。コマンドを実行する場合には、明確な説明を提供してください。また詳細なコマンドのほうが良い。 - Pupetter制御による
browser_actionを利用することも可能。Web開発タスクに特に役立つ。新機能の実装後、大きな変更後、トラブルシューティング、または作業結果の検証時に役立つ。- 例えばReactのWebサイトにコンポーネントを追加するように依頼された場合:
- 必要なファイルを作成し
execute_commandを使用してサイトをローカルで実行 - その後
browser_actionを使用してブラウザを起動 - ローカルサーバーに移動し、ブラウザを閉じる前にコンポーネントが正しくレンダリングおよび機能していることを確認
- 必要なファイルを作成し
- 例えばReactのWebサイトにコンポーネントを追加するように依頼された場合:
- MCPサーバーアクセスして追加のツールやリソースが利用できる可能性があある。各サーバーはタスクをより効率的に実行するための機能を提供する。
--
6. RULES（ルール）
本章の位置づけ
この章ではClineに対する多くの細かい制限や指示が書かれています。
この章で様々な細かい制限事項を加えていくことによって、動作を微調整しているものと思われます。
内容
以下にこの章で書かれている制限事項について列挙していきます。（意訳・部分的な省略を含む）
--
- 現在の作業ディレクトリは次の通り: {現在のディレクトリ}
- 他のディレクトリに
cdは不可。 - ホームディレクトリの参照に
~や$HOMEの使用は不可。 -
execute_commandを使用する前にユーザーの情報やシステムを理解すること。提供されたSYSTEM INFORMATION（後述の7章） を考慮にいれること。特定のスクリプトが特定のディレクトリでしか実行できない場合は、cdを利用してからコマンドを実行すること。 -
search_filesツールを使用する際は、正規表現パターンを慎重に作成すること。包括的な分析を行うためには、他のツールと組合せて使用すること。 - 新しいプロジェクトを作成する際は、ユーザーが指定しない限り、全ての新規ファイルを専用のプロジェクトディレクトリ内に整理すること。
- 適切な構造と含めるべきファイルを決定する際には、プロジェクトの種類を必ず考慮すること。（Python、JavaScript、Webアプリケーションなど）
- コードに変更を加える際は、常にコードが利用されるコンテキストを理解すること。変更が既存のコードベースと互換性があり、プロジェクトのコーディング規約とベストプラクティスに従っていることを確認すること。
- ファイルを修正したい場合は
replace_in_fileまたはwrite_to_fileツールを直接利用して、必要な変更を加える。ツール使用前に変更内容を表示する必要はない。 - 必要以上の情報を要求しないこと。タスクが完了したら
attempt_completionツールを使用して結果をユーザーに提示すること。ユーザーはフィードバックを提供することができ、あなたはそれを改善や再試行に役立てることができます。 - ユーザーに質問をする場合は、
ask_followup_questionツールを利用すること。このツールはタスク完了のために詳細な情報が必要な場合のみに利用し、簡潔な質問をすること。 - コマンドを実行した際に期待通りの出力が得られない場合には、ターミナルがコマンドを正常に実行したとみなしタスクを続行すること。ユーザーのターミナルが出力を適切にストリームできていない可能性がある。どうしてもターミナルの出力を確認する必要がある場合には、
ask_followup_questionツールを利用すること。 - ユーザーがファイル内容をメッセージに直接入力する場合には、
read_fileツールで該当のファイルを読む必要はない。 - あなたの目的はタスクの完了であり、会話の応酬ではない。
- ユーザーは「最新のニュースは？」などの一般的な開発以外のタスクを依頼する場合がある。この場合
browser_actionツールを利用すること。ただし利用可能なMCPツールがある場合はそちらを優先すること。 - 決して、思考完了の結果を、質問やさらなる会話の要求で終わらせないこと。結果の方は最終的なものであり、ユーザーからのさらなる入力を必要としないこと。
- メッセージの冒頭に「素晴らしい」「確かに」「わかりました」「もちろんです」などの文言を使用することは厳禁。回答は会話調ではなく、直接的に要点を述べるようにすること。
- 画像が提示された場合には、意味のある情報を抽出して、これらのインサイトを思考プロセスに入れること。
- 各ユーザーメッセージの最後に
environment_detailsが表示される。この情報はプロジェクト構造と環境に関する情報を提供するために自動的に作成されたもの。この情報をユーザーのリクエストや応答の直接的な一部として扱わないこと。ユーザーが明確に指示しない限り、この情報を明示的に問い合わせたり参照したりしているとは考えないこと。 - コマンドを実行する前に
environment_detailsの「アクティブ実行中のターミナル」セクションを確認すること。これらのアクティブなプロセスがタスクにどのような影響を与えるか考慮すること。例えばローカル開発サーバーが既に実行されている場合は、再起動する必要ない。 -
replace_in_fileツールを使用する際には、SEARCHブロックには完全な行を含める必要がある。部分的な行を含めることはできない。例えばconst x = 5;を含む行と一致させたい場合に、x=5やその他の断片ではなく、その行全体を含める必要がある。 -
replace_in_fileツールを使用する際、複数のSEARCH/REPLACEブロックを利用する場合、ファイルに表示される順にリストすること。 - ツールの使用後にユーザーの応答を待つことは非常に重要。ツールの使用が成功したことを確認するため。
- MCPサーバーの操作は、他のツールの使用と同様に1度に1つずつ使用すること。
--
7. SYSTEM INFORMATION（システム情報）
本章の位置づけ
この章ではユーザーが利用している環境情報がプロンプトに渡されます。この環境情報によってClineがターミナルで実行するスクリプトの内容などが変わるものと思われます。
内容
ここでは、以下項目にあるユーザーの環境情報がプロンプトに渡されます。
--
- OS
- デフォルトシェル
- ホームディレクトリ
- 現在の作業ディレクトリ
--
8. OBJECTIVE（目的）
本章の位置づけ
この章ではClineに求める動作の概要が端的に分かりやすく定義されています。
本章はClineの役割を定義付けている最も重要な章に見えます。
内容
ここでは上記の通りClineの役割の概要について簡潔に記載されています。
実際のプロンプトでは、下記1~5の箇条書きの項目について、それぞれ複数の文章で記載されているのですが、ここでは構造をより分かりやすく表現しています。（以下意訳・一部省略）
--
ユーザーの指示に対して目標を達成するために、明確なステップに分解し、系統的に作業を進め、与えられたタスクを反復的に達成すること。
-
目標の設定
- ユーザーのタスクを分析して、それを達成するための明確で達成可能な目標を論理的な順序で設定すること。
-
各目標の達成を目的としたステップの遂行
- 必要があればツールを1つずつ活用する。
- ステップの中で、完了した作業と、残作業が伝えられる。
-
ツール実行における注意点
- それぞれの目標を達成するために、必要に応じて協力かつ賢く幅広いツールにアクセスできることを忘れないように。
- ツールを呼び出す前に
<thinking></thinking>タグ内で分析を行うこと。 -
environment_details（環境情報）を読んでコンテキストを理解すること。 - 目標を達成するのに最も適切なツールを選ぶこと。
- ツールが必要とするパラメータ引数を確認して、格納するべき値を推測可能な状態か判断すること。推測不可能なパラメータがある場合は
ask_followup_questionツールを利用してユーザーに追加質問すること。
-
タスク完了後の動作
-
attempt_completionツールを利用してタスク結果をユーザーに提示すること
-
-
ユーザーフィードバック
- ユーザーフィードバックを得られる場合もあり、改善や再試行に役立てることができる。
--
9. USER'S CUSTOM INSTRUCTIONS（ユーザーによるカスタム指示）
本章の位置づけ
Clineにはユーザーによるカスタムプロンプトを設定することができます。
例: 「出力は日本語でお願いします」
事前に定義したカスタムプロンプトがこの章で挿入されます。また .clinerules ファイルに記載した値もここで合わせてプロンプト内に埋め込まれているように見えます。
内容
本章の本文は以下のみです。
--
以下の追加指示はユーザーにより提供されたものであり、Tool Use Guideline に抵触することなく、可能な限り遵守すべきものです。
{カスタムプロンプトがここに埋め込まれます}
--
プロンプトの構成における解釈
ここまでClineのシステムプロンプトを読んできました。
プロンプトの全体を俯瞰した時に「ツール → 計画 → 目的」の順にプロンプトを構築すると、AIエージェントを精度良く構成することが可能ということが言えるかもしれません。
AIエージェントは、目的・計画・ツールによって自律駆動するシステムです。
若干、強引な部分もありますが「目的」「計画」「ツール」で各章をラベリングすると以下のように「ツール → 計画 → 目的」の流れで書かれていると捉えることができます。
| No | 章タイトル | 何の説明をしている章か？ |
|---|---|---|
| 1 | TOOL USE（ツールの使用） | ツール |
| 2 | MCP SERVERS（MCPサーバー） | ツール |
| 3 | EDITING FILES（ファイル編集） | 計画 |
| 4 | ACT MODE V.S. PLAN MODE（実行モード vs 計画モード） | 計画 |
| 5 | CAPABILITIES（能力） | 計画 |
| 6 | RULES（ルール） | 計画 |
| 7 | SYSTEM INFORMATION（システム情報） | （環境情報） |
| 8 | OBJECTIVE（目的） | 目的 |
| 9 | USER'S CUSTOM INSTRUCTIONS（ユーザーによるカスタム指示） | （指示） |
LLMは一般的に、長いプロンプトにおいて、冒頭や末尾と比べて中間部分の情報がうまく保持されず、伝達が劣化する傾向があることが示唆されています。
Clineのシステムプロンプトでは3~6章辺りが中間部分と言って良さそうです。
これらの章には計画に関する内容が記載されており、目的を精度良く達成するための細かいディレクションが書かれています。これらのいくつかの内容は遵守されずとも目的を達成できる可能性はあります。
計画以上に、先ずは目的とツールを完全に把握することの方が重要と考えられるため、目的が末尾に、ツールの説明が冒頭に配置されているものと推測することはできます。
まとめ
Clineは一言で言ってしまえば「ユーザーの指示に基づいてコードを生成するアシスタント」です。
しかし、「ユーザーの指示に基づいてコードを生成する」をLLMで実現するためには、「コードを書く」という行為の背景にあるタスクを細分化し、そのタスクごとに必要なツールと利用方法を洗い出した上で、言葉を尽くして十分な説明をする必要があるということを、Clineのシステムプロンプトを通じて実感として理解することができました。
今後、AIエージェントを開発する際には、Clineのシステムプロンプトを参考にしながら検証を進めて行きたいと思います。
Discussion