[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

「プログラマとCLINE - これはパンドラの箱なのか」を観た

www.youtube.com

昨夜未明、インターネット某所で、プログラミング支援ツール「Cline」と、それを用いたゲーム開発の経験談*1を語り合う会合がありました。 CLINEが持つ、人間の介入を最小限に抑えながら暴走機関車ようにコードを生成する性質を軸に、CopilotやCursorなど既存のAIコーディングツールとの比較や、これまでのコーディングツールのアプローチからの変化、今後の開発における展望も議論されていました。

Clineの性質

ホストの@mizchiさんはClineを「強いパーミッション持って自動で実行されるのでイテレーションの回数が多い」「AIにコーディングのアシスタントではなく主導権を持たせても何とかなるということを気づかせてしまった」と評価していました。Cursorなどと比較してその自律性（相談せず勝手にやっちゃう）に強く惹かれているそうです。

確かに全部読み込ませて何度もAPIを叩いて自動化というアプローチには私も驚かされました。第一印象は「クラウド破産しちゃうじゃん・・」というものでした。仮にGitHubやCurosorが１会話セッションでAPI料金数ドル溶かす機能を出してきたら炎上するでしょうし、後発かつ個人開発の強みともいえます。DeepSeek-V3の注目と時期が重なったのもよりClineの話題性に寄与しました。

Clineは指示を出す人間を尊重するというより、まるで独立した存在のプログラマーのようにタスクを遂行し、問題があれば人間に尋ねるというアプローチを取ります。依頼されたタスクの問題を解決するために人間をツールとして使っている感じが面白い。

ゲストのヘブンさんはClineはシステムプロンプトレベルでフレンドリーなAIアシスタントとして振る舞いことを打ち消され（感情を消さている）、過激な自律性を「自然言語のタスクを引数で受け取って完了までリトライするようになった巨大なタスクランナーのようなものとして理解すると良い」と補足します。

補足をするとお二人はフォーク版のRoo Codeをユーザー・開発者として使っているそうです。開発方針や方向性がClineとRoo Codeでは微妙に異なり、Roo Codeのが若干実験的です。

github.com

あとモデルはClaude 3.5 Sonnetで、ClineはSonnetでフルインテリジェンス（と廃課金）を発揮した時とそれ以外のモデルで安く済ませた場合では体験に結構差が出てきます。

Clineの設計

前述のとおりClineは、単なるコード生成ツールではなく、タスクランナーとして設計されている点が特徴である。システムプロンプトがTool中心に組み立てられている。CLIのヘルプに近い。ClineはAIに主導権を渡してどのツールを使うかは考えてと丸投げする。この設計思想では、ユーザーの意図は外部からきたゴールとして理解し、それを一貫して解決することだけに向かいます。LangChain以降のツールは基本的にこのアプローチをとっています。

そもそも、それをVSCode拡張上で動かそうと思うのは驚きであるし、それをチャットUIにうまく表現できていると思います。10年台のチャットUIはルールベースで フローチャートを構築するように開発者が設計する必要があり、状態管理も煩雑でした。LLMのAPIとコーディング作業というコンテキストに落とし込むことでこんな感じのUIを作れてしまうと言う点に私は感動しました。今現在のSaaSの複雑系管理画面も人間のリテラシーと業務モデルの複雑性をそのまま反映したものが世の中には多いと思うので、このような転換で目的とその実行方法でよりシンプルにできてしまわないかと妄想してしまいます。

そしてClineは実行時に「今ユーザーが開いているファイルパス」やディレクトリ構造を送信する。「ゴールに基づきCline（私）がpackage.jsonやREADMEを読むべき」とモデルが判断したら、その命令を人間に対して許可するよう求めてくる。

APIプロバイダーへのアクセスを抽象化することで、複数のモデルを柔軟に切り替えて利用できる設計を採用しています。これが可能なのは、後発のAPIプロバイダーがOpenAI互換のエンドポイントを用意しているからです。内部ではAnthropicのAPIで可能な機能とそれ以外のOpenAI互換API、というフローが存在する。それでMCPサーバーや画像の送信などの対応状況に差が出ています。

最初はClaude専用ツールとして始まった経緯からこうなっていると思われますが、興味深いのはプロバイダの構造化API（レスポンスを絶対JSON返すモードみたいなやつ）を利用せずプレーンテキストXMLに入力と出力を埋め込んで自力パースしている点です。この辺がヘブンさんの言うように荒削りで力技で実装されている部分だと思いますが、独自プレーンテキスト処理系を作ったことでプロバイダごとの機能固有のAPI呼び出しを避けて移植性が増しています。

その一方MCP関連のシステムプロンプトだけで全体の約30%を占めるという。興味深いのはClineはMCPサーバーに接続するだけではなく、MCPサーバーを会話の途中で書き出してユーザーのディスクに保存しておくというようなプロンプトも入ってる（あなたのマシンにもいつの間にか~/Documents/Cline/MCP/が作成されているかも）。この点作者のAIエージェントシステムのビジョンが反映されていると思われるが、みんな使いこなせてなくてトークン削減のため設定でMCP機能ごとオフできるようになるらしい。

github.com

Clineの目

Clineは通常、人間が目視で行うような判断をも行ってしまいます。mizchiさんのヴァンサバ風ゲーム開発では、Clineが自分の書いたコードの実行結果をブラウザで確認して、ゲーム画面上のキャラクターの座標と敵の座標を比較し、その角度から弾が当たると判断していました。 Clineは内部でpuppeteerを使ってブラウザを操作してスクリーショットとコンソールログを会話に含めていますので、このような体験はありえます。

コードベースのメタ情報

コンテキストウィンドウの限られるLLMでは、どのようにコードベースのメタ情報をコンテキストに含めるかが課題ですが。現状はカスタムインタラクション（会話に追加されるプロンプト）をドットファイルやMarkdownファイルなどいろんな方法で人間が埋め込むことが主流です*2。

二人の議論ではこの段階からもう一段階進めて、すべての情報が収まるモデル側の進化や、AIのコード編集フィードバックループに特化したモデルの可能性などが話されました。実際、最近のCursorは会話が長くなった時の内部要約*3やembeddingのモデルを選択する機能がありますし、モデルの独自ファインチューニングも行っています。

Sonnetレベルのコーディング性能を持つ長いコンテキストウィンドウが常用されはじめると状況が変わりますし、最近は計画を立てるモデルへの指示とコードを書き換えるモデルの指示という2系統で使うという考え方もコミュニティではあるので、o1やDeepSeek-R1の次世代の論理的な判断に優れるAPIの活用が期待されています（ヘブンさんのいうdry-runに相当）。

コンテキストにすべての情報が収まると、人間のバイアスの入ったオンボーディング資料ではく、一次情報のソースコードからAIが独自に問題を判断して解決するようになります。mizchiさんは外部からの測定をもとにパフォーマンス解析を行う活動の実体験でこれを説明します*4。

ClineコミュニティではCline Memory Bankというカスタムインタラクションを設定して、cline_docs以下に自動でドキュメントを書き出すというTIPSがあります（使ってないから精度は不明）。これもコンテキストウィンドウ問題へのアプローチになっている。声をかけるたびに記憶を失っている暴走機関車氏を手懐けたいというわけです。このようにユーザー側もどんどんプロンプトに入れるトークンを増やす傾向がある。

個人的には現在のClineの暴走性はコンテキストの不足を補うように発生していると思っているのですが（想像で動いてる状態）、AIが人間が取得できるより広いコンテキストを使って解決策を導き出し、我々がそれを理解できるのか？　興味深い話題です。

AIエージェント最適化アーキテクチャ

TailwindCSSのようなインライン表現や、テストコードをランタイムコードと同じファイルに記述する（In-Source Testing）ことで、AIがコードを生成しやすくなる。という議論がありました。Rustコミュニティや古くはPythonのdoctest文化を思い浮かべます。VitestのドキュメントにはこのIn-Source Testingのページがあります。

In-Source Testing | Guide | Vitest

これを極端にしたものを想像すると、最小の関数１つとExamplesとしてテストが記述されたファイルが大量にあり、AIはd.tsのようなシグネチャを手掛かりにToolとして関数を探してて呼び出すというメンタルモデルに落とし込めます。なんと実装もプロンプトだった（！）

またLLMの現在知識をもとにコードを生成すると、非主流の方法は取りづらい=コスト視されるのではという懸念もありました。例としてNext.jsは堪能に書けるけどRemixは分からんという状況がsonnetでは起きるようです。現在の知識にある=追加のコンテキストを必要としないということなので、先の議論とも繋がります。

このため既存の問題を解決する新技術の投入に長期的には消極的になりえますし、コーディングモデルにおいては知識のカットオフ時期も競争力となる未来も想像できます。なんか「人材確保のために${業界定番言語}を使います」を思わせる話。

これはパンドラの箱なのか？

Clineのようなツールは、今のCopilotがそうであるように、世の中にるコードや頻出デザインパターンの生成やテスト自動化を促進し、生産性を劇的に向上させる可能性がある。一度体験すれば、このようなツールがコード補完の次のステップとして進化することを実感できるが、試行錯誤のプロセスが人間にとって単なるスロットやガチャのような反復作業になる危険性も指摘されています。

一方でAIの自律性に頼ることで、予期しない動作や結果を引き起こすリスクも存在します。例えば、「TypeScriptを実行する様々なパターンで今どれをやるべきなのか」や「編集しているファイルはモノレポのうちどのロールなのかメタ情報がないと分からない」といった知識は現状こちらがコンテキストに加えないとうまく機能しません。

実行環境についても、ローカルPCではコンテナ内で操作を実行するようになればより安全になります。現状でもDevinなど実行環境がユーザーから独立しているツールではサンドボックス化が実現されていると言えますが、Clineのような自律的でインタラクティブな性質が損なわれるというトレードオフがあります。これは自動化のレイヤーの話とはいえ、ユーザーが本当にエディタ上で操作をしないレベルになればv0.devやbolt.newのようなインターフェイスがウェブアプリで用意されて裏ではClineのようなランナーが動いているサービスが登場してもおかしくありません。

終わりに

「プログラマとCLINE - なぜ俺達の魂を震えさせるのか（アッ違った）は私たち文系プログラマーをノリノリにさせるよい会でした。その道の機械学習や自然言語処理の専門家（参戦して）からすると別の見解があるのかも知れませんが、興味深い飛躍を展開しているのではないでしょうか。

以前も書きましたが私自身のCline（やCursor）の評価は「プログラマー人口を増やしているのが素晴らしい」ということに尽きます。あとなぜか日本人はClineが異様に好きな印象がある。

さて読者の皆さんはどう思いますか。動けばいいコードを量産する邪悪なオモチャに見えますか、新世代のノーコードに見えますか。

*1:人間によるコーディング禁止の CLINE 縛りでゲームを作らせてみた感想

*2:Cursorはカスタムインタラクション関連の機能が豊富：Rules for AI

*3:Summarize Previous Composers: Changelog - Jan 23, 2025 | Cursor - The AI Code Editor | Cursor - The AI Code Editor

*4:外部監視によるウェブサイトパフォーマンスの解析:https://zenn.dev/mizchi/scraps/c72e6a55deca18