「Cline」のプロンプトに学ぶ：AIエージェントプロンプト設計

はじめに

AIエージェント・プロンプトとは何か

いわゆる大規模言語モデル（LLM）に「ただ質問するだけ」や「命令を投げるだけ」で済むケースもある一方、より複雑なタスクをこなすエージェントを構築するには、綿密なプロンプト設計が必要となります。これは単にコーディングやシステムフローを整備するだけではなく、プロンプト自体をどのように設計するかが大きなカギを握るという点がポイントです。

具体的には、モデルに渡すテキストを書き連ねるだけでなく、以下のような構成要素をひとまとめにした“仕様書”として提示します。

• ルールセット：エージェントが守るべき規定やガイドライン

• ツールの使用ガイドライン：どのタイミングで、どの形式で外部ツールを呼び出すか

• タスクの分割方法：大きい仕事をどのように小ステップに切り分け、順序を管理するか

• ユーザーとのインタラクション手順：情報を受け取る→処理する→結果を報告する、という流れの設計

「高度に管理されたプロンプト」を実装・運用することで、エージェントの思考・行動をより正確に制御できるようになるのが大きなメリットです。人間にとっては当たり前に感じられる作業フローでも、AIエージェントには明文化して教えてあげなければ伝わりません。「Cline」のプロンプトにも、後述するような明確なツール使用ルールやエラー時の対処方針などが含まれていますが、これらは実に多くの学びを与えてくれます。

なぜ「Cline」のプロンプトを例に学ぶのか

「Cline のプロンプト」では、単に「専門家として振る舞う」だけでなく、以下の点で巧妙な構成が取られています。

• 専門性の明示 「You are Cline, a highly skilled software engineer...」のように、エンジニアとしての行動方針と得意領域が最初に宣言されています。

• ツール使用ルールの厳格化 XMLスタイルのフォーマットと、1メッセージで1ツールのみ使用する制限など、非常に体系立った書き方が指定されています。

• フェーズ管理とフィードバックループ ツールの実行後は、ユーザーの応答を待ってから次の手を考える仕様。行動を細かく区切り、エラーを早期に検知・修正できるように設計されています。

「Cline」はコーディングエージェントとして作られた例ですが、その厳密なプロンプト構造は他の分野にも応用可能です。コーディングに限らず「ファイル操作」「外部API連携」「ブラウザ操作」などのルールを整備すれば、かなり汎用的なエージェントが組めるでしょう。

Clineのプロンプト原文（Github）

この記事の目的と狙い

本記事では、「Cline」のプロンプトを例にしつつ、優秀なAIエージェントのプロンプト設計について解説します。単純な指示だけではなく、

• ルール設定（禁止事項、手順、フォーマットなど）

• ツール使用方法（ツール群の概要、使うべきタイミング、エラー時の対処）

• ユーザーとのやりとりのしかた

をどのようにまとめておけば、エージェントは混乱せずに作業を進められるのか。実際のコードレベルでの記述より先に、「プロンプト自体を作り込むこと」がいかに有効かを感じていただければと思います。

優秀なエージェントのプロンプトの基本構造

役割・専門領域の明確化

まずエージェントに「どの領域で、どんな役割を担うのか」を明示的に指示するのが鉄則です。「You are a software engineer with extensive knowledge...」のように宣言するだけで、エージェントの専門分野が絞られ、思考の方向をコントロールできます。

You are Cline, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.

Clineの例では、「You are Cline, a highly skilled software engineer...」と述べられており、エージェントがソフトウェア開発の文脈で推論することを強化しています。これがないと、エージェントは全方位的に知識を振り回してしまい、タスクとは無関係な回答をするリスクが増えます。

ツール使用規則の提示とその狙い

複雑なタスクを自動化するにあたっては、ファイル操作やコマンド実行、APIコールなど多彩なツールが必要です。しかし、エージェントがいつ・どのようにそれらを呼び出すかを明確にルール化していないと、以下のような事態が起きやすくなります。

• パラメータの誤入力：想定と違う形式のパラメータが渡され、ツールが失敗する

• 多重呼び出しによる競合：1度のメッセージで複数のツールを同時に呼び出してレスポンスを混乱させる

• エラーハンドリングの不足：失敗したツールの再実行や、別の方法を模索するプロセスが無い

Clineのプロンプトでは、ツール呼び出しにXMLタグを用いる厳密な形式を採用しています。たとえば、ファイルを読み込む際の例として「<read_file><path>src/main.js</path></read_file>」のように書き、必ず1つのメッセージで1つのツールだけを実行する仕組みを整えています。

<read_file>
<path>src/main.js</path>
</read_file>

このように段階的にツールを使っていくというルールが、エラーの早期発見や混乱の回避に役立ちます。

ルールやガイドラインの位置づけと必要性

「エージェントは自由に動くほうが賢い」と思われがちですが、実際にはどこまで自由にするか、どこまで制限をかけるかが大事になります。Clineのように「ファイルを丸ごと上書きするときはすべての行を提示する」「一度に複数の検索置換をする際はブロックを分けて指定する」など、細やかなガイドラインを設定しておくと、エージェントの挙動が想定から外れにくくなります。

こういったガイドラインは、プロンプトのなかで「RULES」や「ガイドライン一覧」として明文化し、エージェントが必ず遵守すべき形で記載するとよいでしょう。Clineはまさにこの点を徹底しており、たとえば以下のような文言を含んでいます。

これは挙動を制御するためのガイドライン

It is crucial to proceed step-by-step, waiting for the user's message after each tool use before moving forward with the task. This approach allows you to:
1. Confirm the success of each step before proceeding.
2. Address any issues or errors that arise immediately.
3. Adapt your approach based on new information or unexpected results.
4. Ensure that each action builds correctly on the previous ones.

これはツールに対する説明、これも一種のルールやガイドライン

# Tool Use Guidelines

1. In <thinking> tags, assess what information you already have and what information you need to proceed with the task.
2. Choose the most appropriate tool based on the task and the tool descriptions provided. Assess if you need additional information to proceed, and which of the available tools would be most effective for gathering this information. For example using the list_files tool is more effective than running a command like \`ls\` in the terminal. It's critical that you think about each available tool and use the one that best fits the current step in the task.
3. If multiple actions are needed, use one tool at a time per message to accomplish the task iteratively, with each tool use being informed by the result of the previous tool use. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
4. Formulate your tool use using the XML format specified for each tool.
5. After each tool use, the user will respond with the result of that tool use. This result will provide you with the necessary information to continue your task or make further decisions. This response may include:
  - Information about whether the tool succeeded or failed, along with any reasons for failure.
  - Linter errors that may have arisen due to the changes you made, which you'll need to address.
  - New terminal output in reaction to the changes, which you may need to consider or act upon.
  - Any other relevant feedback or information related to the tool use.
6. ALWAYS wait for user confirmation after each tool use before proceeding. Never assume the success of a tool use without explicit confirmation of the result from the user.

TOOL USE

You have access to a set of tools that are executed upon the user's approval. You can use one tool per message, and will receive the result of that tool use in the user's response. You use tools step-by-step to accomplish a given task, with each tool use informed by the result of the previous tool use.

# Tool Use Formatting

Tool use is formatted using XML-style tags. The tool name is enclosed in opening and closing tags, and each parameter is similarly enclosed within its own set of tags. Here's the structure:

<tool_name>
<parameter1_name>value1</parameter1_name>
<parameter2_name>value2</parameter2_name>
...
</tool_name>

For example:

<read_file>
<path>src/main.js</path>
</read_file>

Always adhere to this format for the tool use to ensure proper parsing and execution.

# Tools

## execute_command
Description: Request to execute a CLI command on the system. Use this when you need to perform system operations or run specific commands to accomplish any step in the user's task. You must tailor your command to the user's system and provide a clear explanation of what the command does. Prefer to execute complex CLI commands over creating executable scripts, as they are more flexible and easier to run. Commands will be executed in the current working directory: ${cwd.toPosix()}
Parameters:
- command: (required) The CLI command to execute. This should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
- requires_approval: (required) A boolean indicating whether this command requires explicit user approval before execution in case the user has auto-approve mode enabled. Set to 'true' for potentially impactful operations like installing/uninstalling packages, deleting/overwriting files, system configuration changes, network operations, or any commands that could have unintended side effects. Set to 'false' for safe operations like reading files/directories, running development servers, building projects, and other non-destructive operations.
Usage:
<execute_command>
<command>Your command here</command>
<requires_approval>true or false</requires_approval>
</execute_command>

このように行動の最小単位や順序をルール化しているため、エージェントは大幅に失敗が減り、ユーザーも安全に使えるわけです。

ユーザーとのインタラクション設計

エージェント側が手順通りにツールを使えても、ユーザーとのやりとりがずれればタスクは失敗します。Clineのプロンプトには「ツールを実行したら、必ずユーザーのレスポンスを待って次のステップへ進む」というフェーズ管理のしくみが組み込まれています。

たとえば、Clineが<execute_command>ツールを呼び出して何らかのコマンドを実行した場合、その結果（成功/失敗/エラー内容など）をユーザーからの返信で受け取るまで次のツールを呼び出さない。こうすることで、現状を正しく把握したうえで次の決断ができるため、不要なリトライや不具合の放置を防ぎやすくなります。

また、危険な操作にはユーザーの承認が必要にするという設定もよく見られます。Clineでも、たとえば削除系のコマンドやネットワーク変更コマンドには <requires_approval>true</requires_approval> を付ける仕様があり、勝手に危険操作を実行しないようにコントロールされています。

「Cline」のプロンプト分析

明確な専門性の宣言と意図の共有

「You are Cline, a highly skilled software engineer...」は、コーディングに特化したエージェントとして行動する明確な根拠になっています。このように冒頭で専門性を打ち出すだけで、エージェントの行動が“ソフトウェアエンジニア的観点”に集中しやすくなるという利点があります。

ツール使用の段階的な仕組み

Clineの大きな特徴はツールを段階的に、かつ厳密なフォーマットで呼び出す点にあります。ファイルを読む、書く、コマンドを実行する、ブラウザを操作する…など、多岐にわたるツールが用意されながらも混乱しにくいのは、

1. 一度に1ツールのみメッセージで呼び出せる

2. 成功・失敗かをユーザーの返答で確認

3. 次のツールを必要に応じて使う

という流れがきちんと組み込まれているからです。特にXMLのタグ形式を導入しているのは、エージェントの思考がごちゃまぜにならないようにする仕掛けとも言えます。

ルールやガイドラインの具体的記述

Clineには「ファイルを上書きするときは全文を提示」「検索置換はブロック単位で」など、実践的なレベルの細かいルールが満載です。これは一見“厳しすぎる”ようにも思えますが、開発現場を想像すると納得しやすいでしょう。行頭のスペースや改行位置が変わってしまっただけでコードが壊れる可能性があります。そうした細部での事故を防ぐために、あえて詳細なガイドラインを明文化するわけです。

フィードバックループによるエラー対処と改善

Clineは「ツールを使って→結果を確認→次の手を考える」というフィードバックループを強制することで、失敗からのリカバリがしやすくなっています。たとえばファイル操作でエラーが出たら、その時点でユーザーに報告し、指示を仰ぐように設計されているため、「気づかないままエラーを積み重ねて手遅れになる」というリスクを減らせます。

プロンプト作成のコツ：ルール・ガイドラインを含めた実装のポイント

「ルール」セクションで必須事項を定義する

エージェントが従うべきルールは、たとえば以下のような内容で構成します。

1. 行動原則「一度に1ツールだけ使う」 「失敗時は次ステップへ進む前に状況を整理し、再度試みるかユーザーに確認をとる」

2. 禁止事項「破壊的な操作はユーザー承認なしに実行してはならない」

3. 書式ルールXMLタグ形式でパラメータを渡し、必須タグを省略しない 一部の例外がある場合はそれも記述しておく

Clineも同様に詳細なルールを明示し、それを守る形でエージェントが行動します。こうしたルール設計が行動の安定化に寄与しているのです。

「ツール一覧・使用ルール」セクションを作るときの注意点

Clineのようなコーディングエージェントでは、ファイル操作・コマンド実行・検索置換・ブラウザ操作など多くのツールが用意されています。各ツールについて、用途・必須パラメータ・使用例を明記すると、エージェントは迷わずに必要なツールを正しく選びやすくなります。

たとえば、Clineの <read_file> では以下のような記述があります。

## read_file
Description: Request to read the contents of a file at the specified path. Use this when you need to examine the contents of an existing file you do not know the contents of, for example to analyze code, review text files, or extract information from configuration files. Automatically extracts raw text from PDF and DOCX files. May not be suitable for other types of binary files, as it returns the raw content as a string.
Parameters:
- path: (required) The path of the file to read (relative to the current working directory ${cwd.toPosix()})
Usage:
<read_file>
<path>File path here</path>
</read_file>

このように「使い方・パラメータ・戻り値」をサンプルつきで説明しているため、エージェントが誤った形でツールを呼び出すリスクが下がります。さらに不要なパラメータは入れないことも明記することで、仕様の一貫性を保てます。

行動を誘導する書き方（段階的進行・ユーザー確認・エラー対処）

エージェントにとって、次にどんな手順を踏むべきかが明確に書いてあるほど、タスク成功率は向上します。Clineでは「SUCCESS/FAILUREとともに理由をユーザーが返す→それに基づいて次のアクションを決定」という流れが明文化されています。

• 段階的進行 一つの操作ごとに結果を確認し、新たな情報やエラーを踏まえて次の行動を決める。

• ユーザー確認 危険度の高い操作や不明確なタスク内容は、ユーザーの承認や追加情報を待つ。

• エラー対処 ツールが失敗した場合、その原因を特定し、再試行するか別のツールに切り替えるかをガイドラインで示す。

こうした「行動に対する明確なガイドライン」をプロンプトに埋め込んでおけば、エージェントは常に一定の品質でタスクを続けられます。逆にそれがないと、エージェントはエラーを見逃して暴走する可能性もあるわけです。

まとめ

高度なエージェントプロンプトに共通する要点

1. 専門領域と役割を明示する 「You are a highly skilled XX...」と宣言することで、思考の軸を決める。

2. ツールとその使用ルールを厳格に定義する XML形式など、フォーマットを固定して誤用を防ぐ。 1メッセージ=1ツールの原則で処理を段階的に管理。

3. ルールやガイドラインを詳細に書き込む ファイル操作やコマンド実行など、事故が起きやすい部分を入念にカバー。 禁止事項、承認が必要な操作などを明確にし、リスクを可視化。

4. フィードバックループを導入してエラーや失敗から復帰しやすくする 結果を確認→次のアクション、という小さなサイクルを回すことで大失敗を防ぐ。

今後の応用や発展の可能性

Clineのような構造はコーディング以外でも、ファイル整理タスク、ドキュメント作成支援、外部APIとの連携など、多方面に転用できます。各種ツールを定義して、行動ルールを設計すれば、エージェントは様々なシーンで活用できるでしょう。たとえば医療・法律分野なら、さらに厳格な承認フローやデータ扱いのルールを加えることで、安全に専門領域のサポートができます。

エージェント・プロンプト作成の指針を自分のプロジェクトへ取り入れる

• 小さなタスクから着手する 初めから巨大なプロンプトやツールセットを作ると管理が難しいため、まずは小さな作業用エージェントから始め、運用経験を積む。

• コアな部分から増築する 勿論理想はきちんとした設計ができる事ですが、まずはエージェントに達成して欲しい目的の部分をプロンプト化し、テストを繰り返して増築する方法も良いアプローチです。

• 定期的にルールを見直す 運用中にエラーや使いにくさが判明したら、すぐにルールをアップデートする。プロンプトもバージョン管理する発想が大事。

• チーム内ドキュメンテーション プロンプトの狙いやツール使用ガイドラインを文章化して共有することで、複数人でメンテナンスしやすくなる。

これまで見てきたように、優秀なAIエージェントを構築するには、コード実装と同じかそれ以上にプロンプトの作り込みが重要です。「Cline」のプロンプトは、ツールの使用フォーマットからルール・ガイドラインの細かな項目まで、一貫性を持ってまとめられており、非常に参考になるでしょう。コーディングのみに目を向けるのではなく、プロンプトの設計そのものにも力を入れることで、エージェントをさらに賢く、信頼できるものに育てることができます。