Clineのプロンプト設計について

Omicron

了解しました。Clineがどのようにプロンプトを設計し、どのような情報（特にTree-sitter由来の構文情報）をLLMに渡しているか、それらの情報がLLMによってどのように利用される設計になっているかを、リポジトリ全体を対象に満遍なく調査します。

日本語で5000文字以上の構成されたレポート形式でお届けします。しばらくお待ちください。

はじめに

ClineはVS Code向けの自律型コーディングAIエージェントであり、LLM（大規模言語モデル）を活用してコードの生成・編集、コマンド実行、ブラウザ操作などを対話的に行います (GitHub - cline/cline: Autonomous coding agent right in your IDE, capable of creating/editing files, executing commands, using the browser, and more with your permission every step of the way.) (GitHub - cline/cline: Autonomous coding agent right in your IDE, capable of creating/editing files, executing commands, using the browser, and more with your permission every step of the way.)。その特徴の一つに、大規模な既存コードベースに対応するためのプロンプト設計があります。特に、プロジェクトのソースコード構造を把握するためにTree-sitterによるAST（抽象構文木）の解析結果をLLMに提供し、関連する情報のみを文脈に含める工夫をしています (GitHub - cline/cline: Autonomous coding agent right in your IDE, capable of creating/editing files, executing commands, using the browser, and more with your permission every step of the way.) (From time to time, I use Cline for coding. In my perspective, LLM models are not... | Hacker News)。本稿では、GitHub上のClineリポジトリ（cline/cline）をもとに、Clineがどのような情報をLLMに渡し、どのようにプロンプトを構成しているのかを詳しく分析します。また、プロンプト内でのLLMのロール定義やテンプレート構造、ユーザ指示からプロンプト生成・送信までのフロー、LLMの種類（ClaudeやGPT-4等）による違いについても考察します。

プロンプト生成のフローと構造

Clineではユーザがエディタ内のチャットUIに自然言語でタスクを入力すると、それを元にLLMへのリクエストが開始されます (From time to time, I use Cline for coding. In my perspective, LLM models are not... | Hacker News)。プロンプト生成の大まかなフローは以下の通りです。

  1. システムメッセージの構築: まず、Clineはシステムプロンプト（system prompt）を組み立てます。ここにはLLMに対するベースの指示やルールが含まれ、Clineの役割や利用可能なツール、環境情報などが定義されます (Roo-Code 核心实现分析_roo code-CSDN博客) (cline/src/core/prompts/system.ts at main · cline/cline · GitHub)。例えば「あなたはClineという熟練のソフトウェアエンジニアです...」というロール定義から始まり、利用可能なツール一覧とその使用方法が詳細に記されています (cline/src/core/prompts/system.ts at main · cline/cline · GitHub) (cline/src/core/prompts/system.ts at main · cline/cline · GitHub)。ツールの呼び出しはXMLライクなタグ形式で行うよう規定されており、各ツールにつき使用フォーマット（タグ名とパラメータ）や使用上の注意が説明されています (cline/src/core/prompts/system.ts at main · cline/cline · GitHub) (cline/src/core/prompts/system.ts at main · cline/cline · GitHub)。例えば<read_file>ツールであれば、<path>パラメータに読み込むファイルパスを指定し、閉じタグ</read_file>で囲む形式です (cline/src/core/prompts/system.ts at main · cline/cline · GitHub) (cline/src/core/prompts/system.ts at main · cline/cline · GitHub)。また「1回の回答メッセージで使用できるツールは1つだけ」「ツール使用後、その結果は次のユーザメッセージとして返ってくる」など、エージェントが守るべき対話上のルールも明示されています (cline/src/core/prompts/system.ts at main · cline/cline · GitHub)。加えて、現在の作業ディレクトリやOS種別・使用シェルといった実行環境情報も文字列中に埋め込まれます（例えば「コマンドは${cwd}で実行されます」といった形で作業ディレクトリパスを提示） (cline/src/core/prompts/system.ts at main · cline/cline · GitHub)。

  2. カスタム命令・プロジェクト固有ルールの付与: 次に、ユーザが設定したカスタム命令や、プロジェクトルートにある**.clinerulesファイルの内容がプロンプトに組み込まれます。カスタム命令はユーザがグローバルに指定できる指示であり、例えば「コーディングスタイルガイドに従うこと」等を含めることができます (cline/docs/prompting at main · cline/cline · GitHub)。.clinerulesは各プロジェクトごとの追加指示を記述するファイルで、セキュリティ上読み書きを避けるべきファイルパターンやプロジェクト固有のコーディング規約などを定められます (cline/docs/prompting at main · cline/cline · GitHub) (cline/docs/prompting at main · cline/cline · GitHub)。Clineではシステムプロンプト内でこれらの内容に言及し、プロジェクト固有のルールもLLMが考慮する前提を作ります (cline/docs/prompting at main · cline/cline · GitHub)。実際にClineのコードを見ると、.clinerulesファイルまたはディレクトリが存在するかを確認し、その内容を読み込んでプロンプトに統合する処理が実装されています（clineRulesFileInstructionsという文字列として取得） (cline/src/core/Cline.ts at main · cline/cline - GitHub)。したがって、システムメッセージの末尾にはプロジェクト毎の追加指示が追記され、LLMに対する不変の前提**として機能します。なお、Clineは複数言語に対応するため、ドキュメントでは.clinerulesファイルだけでなく.clinerulesディレクトリに分割したルール定義もサポートすると記載されています (Prompt Engineering Guide - Cline Documentation)（大規模プロジェクトで指示が増える場合の管理を容易にするための仕組み）。

  3. ユーザメッセージの生成: 上記システムメッセージを送信した上で、続けてユーザからの指示内容（タスク）がLLMに渡されます。OpenAI系モデルの場合は system ロールと userロールのメッセージとして送信され、Anthropic Claudeのようなモデルの場合は1本のプロンプト文字列中に「Human: ...」「Assistant: ...」形式で埋め込まれる可能性があります（ClineはOpenRouter経由で複数APIに対応しており、プロバイダ毎に適切なプロンプト形式に変換しています）。例えばAnthropic APIではシステムメッセージの概念が明確でないため、Cline内部でシステムプロンプトの内容を会話の先頭に人間の発話として付与し、続けて実ユーザの発話を付ける実装になっていると思われます。このようにモデル種別ごとにロール表現の差異は吸収しつつも、実際にモデルに与えられる論理的な内容は共通です。

  4. 対話ループの開始: 構築された初期プロンプトをもとにLLMが応答を生成し始めます。Clineではこれを受け取り、リアルタイムにストリーミング表示する仕組みがあります (Roo-Code 核心实现分析_roo code-CSDN博客)が、本稿の主題はその内容構造です。LLM（アシスタント）はシステムプロンプトの指示に従い、必要であれば最初の応答でツールの呼び出しを行います。通常のフローでは、まずプロジェクトの概要把握のためコードベースの構造を調べる段階から始まります。LLMは「list_code_definition_names」ツールを使ってソースディレクトリ内の主要な定義一覧を取得することが推奨されています (Cline コード生成 AI のソースコードを読んで、試しに自分でも作ってみました #JavaScript - Qiita)。Clineのシステムプロンプトにも「コードベースの全体像把握に重要な高レベル構造を提供する」ツールとしてlist_code_definition_namesが紹介されています (cline/src/core/prompts/system.ts at main · cline/cline · GitHub)。したがって、LLMはまずAST解析結果に基づくクラス名・関数名の一覧を要求し、その出力（プロジェクト内の各ファイルで定義されているクラスや関数の名前リスト）を受け取ります (Cline コード生成 AI のソースコードを読んで、試しに自分でも作ってみました #JavaScript - Qiita)。次に、その情報から変更すべきファイルを特定し、read_fileツールで該当ファイルの中身を読み込みます (Cline コード生成 AI のソースコードを読んで、試しに自分でも作ってみました #JavaScript - Qiita)。Clineは各ツールの実行結果を内部で取得すると、それを次のユーザ発話としてLLMに提供します。こうして、LLMは要求したファイル内容や検索結果を順次受け取りながら、解決策を考えます。最後に、必要なコード修正箇所の内容が揃った段階で、LLMはコードを書き出し、write_to_fileツールでファイルを編集する提案を返します (Cline コード生成 AI のソースコードを読んで、試しに自分でも作ってみました #JavaScript - Qiita)。Clineはその差分を実際のファイルに適用する前にユーザに確認させ、許可が得られればエディタ上で変更を反映します (From time to time, I use Cline for coding. In my perspective, LLM models are not... | Hacker News)。

以上のように、システムメッセージ（不変のルール + ツール説明 + 環境情報 + カスタム指示）と、ユーザメッセージ（タスク内容）から対話が始まり、あとはLLM（アシスタント）とCline（ツール実行・結果提示）が交互にメッセージをやり取りするループとなります (From time to time, I use Cline for coding. In my perspective, LLM models are not... | Hacker News)。プロンプト全体は逐次更新され、直近の対話履歴（ツールの結果やこれまで生成した部分的な回答内容）も文脈として保持されます。そのためLLMは過去のツール出力を参照しながら、一貫したプランの下でタスクを遂行できます。

Tree-sitterによる構文情報の抽出と利用

Clineが大規模プロジェクトにも対応できる鍵として、Tree-sitterを用いたソースコード構文情報（AST）の抽出があります。Tree-sitterは多言語対応のパーサジェネレータで、ソースコードから構文木を生成できます。Clineではこれを利用して、コードベース内のシンボル情報（クラス名、関数名など）を正確に収集し、LLMに提供しています (From time to time, I use Cline for coding. In my perspective, LLM models are not... | Hacker News)。

具体的には、Cline起動時にプロジェクト内のファイル拡張子を調べ、対応するTree-sitterパーサのWASMモジュールをロードします (cline/src/services/tree-sitter/languageParser.ts at main · cline/cline · GitHub) (cline/src/services/tree-sitter/languageParser.ts at main · cline/cline · GitHub)。例えばプロジェクトに.jsや.tsファイルがあればJavaScript/TypeScript用の文法をロードし、.pyがあればPython用パーサをロードする、という具合です (cline/src/services/tree-sitter/languageParser.ts at main · cline/cline · GitHub)。こうして必要な言語のパーサをメモリ上に準備した後、Clineは**list_code_definition_namesツール**の処理で各ファイルのASTを解析します。list_code_definition_namesは指定されたディレクトリ以下のソースコードファイルを再帰的に走査し、トップレベルの定義名（クラス、関数、メソッド、グローバル変数等）を抽出・一覧化するツールです (cline/src/core/prompts/system.ts at main · cline/cline · GitHub) (cline/src/core/prompts/system.ts at main · cline/cline · GitHub)。内部的にはTree-sitterのクエリ機能を使い、各ASTからノード型（例えば関数宣言やクラス宣言）を検索して名前を取り出していると推測されます。実際、Clineのコードには各言語ごとのTree-sitterクエリ文字列（javascriptQueryやpythonQueryなど）が定義されており、例えばJavaScriptでは関数宣言やクラス宣言にマッチするパターンを含んでいるでしょう (cline/src/services/tree-sitter/languageParser.ts at main · cline/cline · GitHub) (cline/src/services/tree-sitter/languageParser.ts at main · cline/cline · GitHub)。これにより、ファイルごとに「どんなクラスや関数が定義されているか」を正確に把握できます。

LLMはlist_code_definition_namesツールを呼び出すことで、その結果（各ファイルの定義一覧）を取得できます。結果の形式は、システムプロンプトの説明によれば「コードベース構造と重要な構成要素についての洞察を提供する」ものとなっており (cline/src/core/prompts/system.ts at main · cline/cline · GitHub)、具体的にはファイルパスごとに定義されたシンボル名のリストが含まれると考えられます。例えば以下のような出力イメージです（擬似例）:

File: src/App.js
 - Class: App (React Component)
 - Function: renderApp()

File: src/utils.js
 - Function: calculateSum
 - Function: formatDate

このようにファイル構造を俯瞰できる情報をLLMに与えることで、モデルは「どのファイルにどんな機能があるか」を把握できます。ユーザの指示内容とこの情報を突き合わせることで、関連するモジュールを特定する助けとなります (Cline コード生成 AI のソースコードを読んで、試しに自分でも作ってみました #JavaScript - Qiita)。例えばユーザが「APIエンドポイントの認証ロジックにバグがあるので修正して」という依頼をした場合、LLMはまずlist_code_definition_namesでプロジェクトの定義一覧を得て、「Auth」「API」など関係しそうなクラスや関数名を探します。仮にAuthServiceクラスやauthenticateRequest関数といった名前が見つかれば、その所在ファイルを突き止め、次にそのファイルの内容をread_fileで開く、という段取りです (Cline コード生成 AI のソースコードを読んで、試しに自分でも作ってみました #JavaScript - Qiita)。ツール呼び出しとAST情報により、大規模プロジェクト内でも必要最小限のファイルに絞って読み込むことができ、コンテキスト予算（トークン数）を節約できます (GitHub - cline/cline: Autonomous coding agent right in your IDE, capable of creating/editing files, executing commands, using the browser, and more with your permission every step of the way.)。

Tree-sitterによる解析は、正確かつ言語仕様に沿ったシンボル抽出を可能にします。正規表現だけでは見落としがちなシンボル（例えば似た名前のコメントや文字列リテラル中の単語）も、ASTを通じて確実に識別できます (Idea: Add an option to make the output more friendly with RAG ...)。ClineはさらにRipgrepによる正規表現検索(search_filesツール)も併用していますが (cline/src/core/prompts/system.ts at main · cline/cline · GitHub) (cline/src/core/prompts/system.ts at main · cline/cline · GitHub)、ASTベースのlist_code_definition_namesはコード構造の地図として機能し、正規表現検索は具体的なコード断片（エラーメッセージや特定関数の呼び出し箇所など）の探索に使われます。両者を組み合わせることで、モデルは「まず構造を把握し、次に詳細を検索する」というアプローチで効率的に必要情報を得られます。

ClineのAST活用は他にも活かされています。例えばコード編集の精度向上にも寄与しています。モデルが修正内容をwrite_to_file提案する際、Cline側では実際の差分適用前にTree-sitterやdiffライブラリで意図した箇所のみ書き換えられているかを確認する処理があります（diff比較や競合解消など） (Roo-Code 核心实现分析_roo code-CSDN博客)。また、replace_in_fileというツールも定義されており、これは特定ファイル内の一部分を検索文字列と置換文字列で更新する機能ですが (cline/src/core/prompts/system.ts at main · cline/cline · GitHub)、この操作にも構文情報が使われている可能性があります。Cline作者は、Large Language Modelによるコード変更後に構文エラーやリンタエラーが出ないよう、モデル自身にコードコンパイルの結果をチェックさせ再度修正するループも実装しています (GitHub - cline/cline: Autonomous coding agent right in your IDE, capable of creating/editing files, executing commands, using the browser, and more with your permission every step of the way.)。この際、ASTを用いた簡易Lintチェックをしているかもしれません（例えばツール実行後にファイルをパースし直し、ASTが壊れていないか確認する等）。実際Aider等類似ツールではTree-sitterを用いた構文整合性チェックを行っています (Linting code for LLMs with tree-sitter | aider)。ClineでもAST解析は主に文脈提供目的ですが、潜在的にモデルの出力検証にも応用可能な基盤と言えます。

以上のように、Tree-sitterによって抽出されたコード構造情報はClineのプロンプトに組み込まれ、モデルが広大なコードベースを扱う際の羅針盤となっています。公式READMEでも「Clineはまずファイル構造とソースコードASTを分析し、正規表現検索や関連ファイルの読込を行って、巨大なプロジェクトでもコンテキストウィンドウを圧迫しないよう慎重に情報を取捨選択する」と説明されています (GitHub - cline/cline: Autonomous coding agent right in your IDE, capable of creating/editing files, executing commands, using the browser, and more with your permission every step of the way.)。まさにAST解析結果を活用した賢いコンテキスト管理と言えるでしょう。

LLMへの入力設計の意図と機能

Clineのプロンプト設計は、LLMがエージェントとして正しくタスクを遂行できるよう導くことを目的として練られています。その意図や機能をいくつかの観点から分析します。

  • エージェントのロール定義: システムプロンプト冒頭で、LLMに「あなた（アシスタント）はClineという有能なソフトウェアエンジニアである」と宣言しています (cline/src/core/prompts/system.ts at main · cline/cline · GitHub)。この記述はLLMの役割（ペルソナ）を定義し、回答の文体やスタンスを規定する効果があります。熟練エンジニアというロールにより、モデルは技術的に詳しく、慎重かつ分析的にタスクに取り組むことが期待されます。また後続のツール説明と相まって、「ツールを使いこなしながらステップバイステップで問題解決する」というエージェント的振る舞いを促しています。

  • ツール利用のガイダンス: プロンプト内でLLMが使用できるツール一覧（コマンド実行、ファイル読み書き、検索、ブラウザ操作、MCPカスタムツールなど）が詳細に説明されています (cline/src/core/prompts/system.ts at main · cline/cline · GitHub) (cline/src/core/prompts/system.ts at main · cline/cline · GitHub)。各ツールには何のために使うか、パラメータは何か、注意事項（破壊的操作にはrequires_approval=trueを指定 etc）まで書かれています (cline/src/core/prompts/system.ts at main · cline/cline · GitHub) (cline/src/core/prompts/system.ts at main · cline/cline · GitHub)。これはLLMに行動の選択肢を明示し、適切なタイミングで適切なツールを選ばせる設計です。例えば、コード内容を把握したければread_fileではなくまずlist_code_definition_namesを使うべきこと、複数ファイルにまたがる変更を確認したければsearch_filesが役立つことなどをモデル自身が理解できます。実際、Qiitaの分析でもCline（Claudeモデル）が手順4で定義一覧ツールを呼び出し、手順5でファイル読込に進んでいることが示されています (Cline コード生成 AI のソースコードを読んで、試しに自分でも作ってみました #JavaScript - Qiita)。この順序はシステムプロンプトで提示された手引きをモデルが守っている例と言えます (Cline コード生成 AI のソースコードを読んで、試しに自分でも作ってみました #JavaScript - Qiita)。
    また、ツールのフォーマットをXML風タグとしたのも興味深い設計です。これはOpenAIの関数呼び出し機能が登場する以前からClineが導入していた独自形式で、モデルの出力をパースしやすくするためのものです (Claude Dev v2.0: renamed to Cline, responses now stream into the ...)。タグ形式はモデルが誤ってユーザ向けメッセージ内でツール名を言及した場合でも誤検出しにくく、安全に実行コマンドを抽出できるメリットがあります。ClineはAnthropicのClaudeを主に想定して開発されており、Claudeはこのようなフォーマットでのツール指示にも柔軟に対応できるだけのコンテキスト理解力を持っています。

  • 必要情報のみを逐次提供: プロンプト設計の要点は、一度にすべてのコードや情報を渡さないことです。最初はASTに基づく概要だけを与え、LLMの要求に応じて詳細（実際のコード内容）を開示するという逐次開示戦略になっています。これにより、どんなに大きなリポジトリでも常にコンテキスト内の情報量を抑制できます (GitHub - cline/cline: Autonomous coding agent right in your IDE, capable of creating/editing files, executing commands, using the browser, and more with your permission every step of the way.)。モデルが今本当に必要とする情報だけを都度要求させることで、無関係な部分を読ませないようにしているのです。これは人間のソフトウェアエンジニアが新しいコードベースを読む際に、まず目次や概要に目を通し、関係ありそうな箇所だけ詳しく読む手法に似ています。ClineはLLMに対してこの「絞り込み探索」をさせるために、AST概要や検索ツールを用意しました。モデルがこれらを使いこなす前提で設計されている点が重要です (From time to time, I use Cline for coding. In my perspective, LLM models are not... | Hacker News)。逆に言えば、モデルが誤った判断で無関係なファイルを開きまくるとコンテキストがあふれる危険もありますが、Claudeのようなモデルは指示を守り比較的計画立てて探索できるよう調整されています（AnthropicのClaudeシリーズは長文のプロンプトや複雑な指示に従う性能が高いとされています）。

  • コンテキスト保持と参照: Clineはタスク中のすべてのメッセージ履歴を内部的に管理し、必要に応じてLLMに送り続けます。LLMは自身が出力したツール呼び出しや、その結果として提供されたファイル内容を会話履歴から参照できます。例えば一度read_fileで取得したファイル内容はその後もプロンプト履歴に残っているため、モデルは改めて同じ内容を要求せずに済みます。これはいわば一時記憶のように機能し、大きなファイルでも一度読めばその後のコード生成で自由に内容を引用できます。Clineはトークン数節約のために、必要なくなった履歴を省略または要約する工夫も持っています（例えば完了したサブタスクの詳細ログを落とすなど）。ただし、常に完璧に要約できるわけではなく、モデルの出力の整合性を保つため直近の対話はできるだけそのまま保持します。このあたりのコンテキスト管理は繊細で、プロジェクトが巨大な場合はlist_code_definition_namesの出力自体が長大になり得るため注意が必要です。

  • ユーザの意図反映: .clinerulesやカスタム命令をプロンプトに入れることで、ユーザが望むコーディング方針や扱いたくない情報がモデルに伝わります。例えばセキュリティ上無視すべき機密ファイルパターンを指定すれば、モデルはそれらを開かないようになります (cline/docs/prompting at main · cline/cline · GitHub)。またプロジェクト独自のコーディング規約（命名規則やテスト方針など）も盛り込めるため、モデルの提案するコードがチーム標準から逸脱しないようにできます (cline/docs/prompting at main · cline/cline · GitHub)。このようにプロンプトにはユーザのカスタマイズ要素も組み込まれており、出力結果の品質や安全性を高めるフィルターの役割も果たしています。

以上の設計から、ClineのLLM入力は単なる「ユーザ質問とコード断片」ではなく、ツール駆動のエージェント対話として構築されています。モデルが環境を理解し、自律的に調査・編集・検証を繰り返せるよう、プロンプトが一種のタスクガイドになっているのです。Clineの作者も「逐次的なツール使用を通じて段階的にソフトウェア開発タスクを進める」と述べています (GitHub - cline/cline: Autonomous coding agent right in your IDE, capable of creating/editing files, executing commands, using the browser, and more with your permission every step of the way.)。これはLLMに従来の一問一答ではなく、開発者の思考プロセスをなぞらせることを意図した設計と言えるでしょう。

考察と限界

Clineのプロンプト設計は非常にリッチで強力ですが、いくつか考慮すべき点や限界もあります。

1. プロンプトが長大になる問題: Clineは多くの指示やツール説明をシステムプロンプトに含めるため、そのサイズが大きくなりがちです。実際、あるユーザは「コードを何も追加していない状態のClineのプロンプトが135,000文字以上（約35,000トークン）もあり、モデルのレートリミットに抵触した」と報告しています (Number of request tokens has exceeded your per-minute rate limit in ...)。これはおそらく.clinerulesやカスタム命令、ツール一覧などを全て含めた結果と考えられます。Claude 2 など一部のモデルは100kトークン超を扱えるとはいえ、毎回巨大なプロンプトを送るのは効率的でありません。Cline開発陣も更新でlist_code_definition_namesツールの出力が不要に長い場合は自動でread_fileにフォールバックするなど、トークン削減の工夫を進めています (API request seems not to comunicate with any model. It ... - GitHub)。今後もプロンプトの簡潔化（例えばツール説明を必要に応じて省略する、.clinerulesを段階的に適用する等）は課題でしょう。

2. モデルごとの対応差: ClineはAnthropic Claudeを念頭に開発されましたが、OpenAI GPT-4や他のモデルにも対応しています (GitHub - cline/cline: Autonomous coding agent right in your IDE, capable of creating/editing files, executing commands, using the browser, and more with your permission every step of the way.)。Claude系は長大なシステムプロンプトや複雑な指示に強い一方、GPT-4（8k/32k版）ではコンテキスト容量や出力の傾向が異なります。Clineはモデル固有設定（supportsComputerUseフラグなど）でプロンプト内容を多少切り替えています (cline/src/core/prompts/system.ts at main · cline/cline · GitHub)。例えばClaude 3.7 Sonnetではウェブブラウザ操作（画像取得を含む）まで行えるためbrowser_actionツールを有効にしますが、GPT-4では対応しない（もしくは開発者が意図的に無効にする）可能性があります。このように、モデルの能力や制約に合わせたプロンプトのオンオフが存在します。ただ、根本的な構成はどのモデルでも共通で、XMLタグ形式のツール指示などは一律です。OpenAIの関数呼び出しAPIを使った実装ではないため、GPT-4もClaudeと同様にタグベースでツール要求を出す必要があります。この形式にGPT-4が常に従う保証はなく、例えば通常のコード生成モードに引きずられてJSON風に出力してしまうケースも考えられます。その点、ClaudeはAnthropicが社内でエージェント用途を実験していた経緯もあり、Clineとの相性が良いようです (Cline - New (Old) Kid in Town - LinkedIn)。「Claude 3.5/3.7 Sonnet」はエージェント志向の調整がなされているモデルらしく、Clineのツール使用プロンプトを理解して適切に行動します (Cline - X)。モデルによっては出力が暴走したり、ツールでなく直接解答を試みてしまうケースもあり得ます。Clineはそうした違いを吸収するため、対話ループ中にモデルからの不正確な応答を検知してリトライする仕組み（例えばツールタグが無いのにコード提案だけしてきたら「一旦停止して計画を」と促す等）も実装しているようです (Roo-Code 核心实现分析_roo code-CSDN博客)。

3. 自律性と安全性のバランス: Clineは基本的にLLMに自律的なコード編集を任せますが、人間の許可を逐次求めることで安全性を担保しています (GitHub - cline/cline: Autonomous coding agent right in your IDE, capable of creating/editing files, executing commands, using the browser, and more with your permission every step of the way.)。プロンプト中でもrequires_approvalパラメータをツールに持たせ、重要操作には必ずtrueを指定するようモデルに指示しています (cline/src/core/prompts/system.ts at main · cline/cline · GitHub)。モデルがこれを遵守すれば、削除や外部通信などリスクあるコマンドは必ずユーザ確認が入ります。ただ100%守る保証はなく、モデルが意図せず危険操作をfalseにしてしまう可能性もゼロではありません（もっともCline側でも、特定コマンド実行前には二重確認するなどガードしています）。また.clinerulesで秘密情報の保護ルールを与えても、新しい未学習の機密パターンには無力です。ブラックリスト方式の限界もあり、今後はホワイトリスト（許可されたファイルだけ読む）的なアプローチも検討されるかもしれません。

4. 大きなファイル・複雑な編集: HNのユーザ報告によれば、Clineは巨大なファイル（1000行以上）の編集が苦手とのことです (From time to time, I use Cline for coding. In my perspective, LLM models are not... | Hacker News)。これはモデルが長大なコンテキスト内で部分的変更をうまくやり遂げるのが難しいためです。一度に全部を書き換えようとしてトークン超過になったり、2行の修正だけのはずが何度も差分生成に失敗して無限ループする、という問題が指摘されています (From time to time, I use Cline for coding. In my perspective, LLM models are not... | Hacker News)。Clineは内部で差分を取って前回との差異のみを適用する戦略（DiffStrategy）も備えますが (Roo-Code 核心实现分析_roo code-CSDN博客)、LLMが一貫しない出力をすると収束しません。またクラス間の依存などクロスファイルの文脈も、基本は名前マッチに頼っているため完全ではありません。ASTでシンボル一覧は取れても、それぞれがどう関連するか（関数の呼び関係や継承関係）は把握できません (Idea: Add an option to make the output more friendly with RAG ...)。このため重要な関連をモデルが見落とす可能性があります。例えば修正対象関数が他でも使われているのに、モデルがその場所以外チェックせずに変更してバグを生むケースです。人間ならIDEのリファレンス検索をかけますが、Clineのモデルは自分でsearch_filesツールを呼ぶ必要があります。Claudeは比較的自発的に検索しますが、それでも完全ではありません。文脈保持の限界から、Clineは一度のタスクではプロジェクト全体の一括リファクタリングのようなことは不得意で、むしろスコープの狭いタスクを順にこなすのに向いています (From time to time, I use Cline for coding. In my perspective, LLM models are not... | Hacker News)。

5. ユーザへの認知負荷: Clineは人間の「承認」をインタラクティブに求める設計上、ユーザはモデルが提示する各ステップを逐次監督する必要があります。例えばファイルを開くたび、その内容が表示されるのでユーザも確認できますが、大規模プロジェクトでは何度も長大なコードが表示され煩雑かもしれません。また、モデルが間違った方向に進みそうなとき人間が軌道修正するUIも用意されていますが、その判断をユーザが下すにはモデルの思考ログを追う必要があります。Clineは「Planモード」で一旦計画をモデルに述べさせてユーザがレビューできるようにする等の工夫もしているようですが (From time to time, I use Cline for coding. In my perspective, LLM models are not... | Hacker News)、依然ユーザの積極的な介入が求められます。これは安全のためには必要な妥協点ですが、「完全自律で放置しても勝手に実装が終わる」といった夢からは程遠い現実でもあります。現状のLLM性能では人間のレビューは不可欠であり、Clineはそこのバランスを取っている状態です。

結論

Clineアプリケーションのプロンプト設計は、LLMを高度なコーディングエージェントとして機能させるための工夫が随所に凝らされています。ソースコード全文を無計画に渡すのではなく、Tree-sitterで解析したAST情報を使ってコードベースの構造を概要提示し、LLM自身に必要な部分を探索させるというアプローチは、巨大プロジェクトを扱う上で非常に理にかなっています (GitHub - cline/cline: Autonomous coding agent right in your IDE, capable of creating/editing files, executing commands, using the browser, and more with your permission every step of the way.) (From time to time, I use Cline for coding. In my perspective, LLM models are not... | Hacker News)。プロンプト全体も、システムメッセージにエージェントのロールと利用可能なツール・ルールを網羅的に記述し、ユーザメッセージに具体的なタスクを与えるというテンプレート化された構成になっていました。.clinerulesによるプロジェクト固有の追加指示や、カスタム命令によるユーザ嗜好の反映も可能であり、LLMへの入力は静的な一問一答からユーザ毎・プロジェクト毎にチューニング可能な動的プロンプトへと昇華しています (cline/docs/prompting at main · cline/cline · GitHub)。

ClineのLLM入力設計は、Claudeのような高性能モデルの長所を引き出すと同時に、その限界を補うものです。ツールの助けを借りつつ段階的に問題解決する手法は、大規模言語モデルを思考エージェントとして扱う一つの完成形と言えます。もっとも、その実現には長大なプロンプトと複雑なフローが必要であり、最適化やモデル間差異への対応など課題も見られました。それでも、オープンソースであるClineのコードからは、現時点で考えうる先進的なプロンプト設計パターンが学べます。特にASTの活用や独自フォーマットのツール呼び出しは、他のAIコーディング支援ツールにもインスピレーションを与えています（実際、類似プロジェクトのAiderやCursor等もTree-sitterによるコード理解を取り入れ始めています (Idea: Add an option to make the output more friendly with RAG ...)）。

総括すれば、Clineは**「LLM＋ツール」でコーディングタスクを進める対話型エージェントの優れた実装例であり、そのプロンプト設計はLLMに最大限プロジェクト知識を与えつつ無駄を省く工夫に富んでいます。今後モデルが進化しコンテキスト長の制約が緩和されても、こうした情報構造化と段階提示**の戦略は依然有用でしょう。Clineの設計と経験は、これからのAIペアプログラマー開発における貴重な知見となるはずです。

【参考資料】Cline公式リポジトリおよびドキュメント、ユーザコミュニティからのフィードバック (GitHub - cline/cline: Autonomous coding agent right in your IDE, capable of creating/editing files, executing commands, using the browser, and more with your permission every step of the way.) (From time to time, I use Cline for coding. In my perspective, LLM models are not... | Hacker News) (cline/docs/prompting at main · cline/cline · GitHub) (cline/src/core/prompts/system.ts at main · cline/cline · GitHub) (Cline コード生成 AI のソースコードを読んで、試しに自分でも作ってみました #JavaScript - Qiita)など。

いいなと思ったら応援しよう！