Cline AIアシスタントに魅了されてしまった
昨日Cline AIアシスタントを試してみたのですが、そのあと5時間ほど、まるでトランス状態のようにClineが代わりにバグを直していくのをただ呆然と見つめることしかできませんでした。
プロの開発者として、その体験は魅力的であると同時に恐ろしくもありました。AIがここまでのレベルに達したことに心を奪われる一方で、同じ理由で恐怖も覚えます。AIが自分よりも上手く、そして速くコードを書ける世界で、自分はどのような役割を担えばいいのか分からなくなるからです。
この分野では完全に乗り遅れていたのだと気づきました。多くの開発者がすでにAIツールをワークフローに深く組み込んでいるようです。まだ体験していない方に向けて、私が見たものをご紹介したいと思います。
これまでもAIツールは使ってきました
Clineが初めてのAI体験というわけではありません。
ここ2年ほど、LLMアシスタントをいろいろと試してきました。特にここ半年は、モデルが安定して正しいコードを生成できるレベルに達したこともあり、使う頻度がぐっと増えています。
私は検索エンジンにKagiを使っています。Ultimateプランでは主要なLLMをすべて無制限に利用できます。普段はKagi Assistantという、LLMとチャットするためのウェブUIを通してやり取りしています。

私が使っている検索エンジンKagiには、主要なLLMをまとめて使える便利なウェブチャットインターフェースが付いています。
念のためお伝えしておきますが、私はKagiのクラウドファンディングに参加しているので、よく分かってはいないのですが、少額ながら出資しています。
AIツールを使うと、自分がbotになったような気分になります
最近気づいた問題は、AIツールを使っていると自分が機械になったように感じてしまうことです。エディタとチャット画面の間でコードをただ無心にコピー&ペーストし、「うまくいきませんでした」と言ってエラーメッセージを貼り付け、それを4、5回繰り返すだけなのです。


チャットボット型のLLMがバグに対して誤った修正を繰り返し、完全な解決策を引き出すまでに何度も促す必要がある様子です。
もっと良い方法があるはずです
今のやり方よりも、もっと賢くAIを統合する方法があるはずだと気づきました。
「コードとエラーメッセージを往復させる係」という自分の役割を肩代わりしてくれるツールが必要でした。
Sourcegraph Codyは1年ほど間をあけて2回試しましたが、どちらも期待外れでした。エディタ内で直接コードを編集してくれるのは、ブラウザとエディタの間でコピペするよりはましでしたが、動作が遅く不具合も多かったため、結局またブラウザへのコピペに戻ってしまいました。
最近Clineについてのブログ記事をいくつか見かけ、以下の点で魅力的に感じました。
- コードがオープンソースであること。
- メインエディタであるVS Codeと統合できること。
- ローカルファイルの編集やコマンドの実行、実行結果を踏まえた反復作業を任せられること。
- 必要に応じてローカルでホストするLLMを使えること。
- 多くのAIアシスタントのように、AI APIへのアクセス購入で中間マージンを取ろうとしないこと。
欠点を挙げるとすれば、Clineには投資家の資金を燃やす以外に目立った収益源がないように見えることです。そのため持続可能性には疑問が残りますが、今のところは問題ありません。
Lexical Illusions(語彙の錯覚):AIアシスタントにぴったりのテスト課題
最近、自分のブログをスキャンして「lexical illusions(語彙の錯覚)」を見つけてくれるツールが欲しいと思っていました。これはMatt Might氏がそう呼んでいる、文章中の単語の重複に気づかない現象のことです。例えば次のようなケースです。
Many readers are not aware that the
the brain will automatically ignore
a second instance of the word “the”
when it starts a new line.
私はブログでこのミスをよくやってしまい、校正の最終段階や公開後になるまで気づかないことがよくあります。
Matt Might氏はlexical illusionsを見つけるPerlスクリプトを公開していますが、作りがシンプルで、私のブログではMarkdownの書式記号のせいで誤検出が大量に出てしまいました。
Kagi AssistantにMarkdownを考慮したPython版を書いてもらおうとしましたが、バグのあるコードばかり返ってきました。
この課題はClineを試すのにうってつけだと気づきました。問題の定義が明確だからです。期待する動作を示すテストケースをAIアシスタントに見せ続け、テストが通るまでコードを編集させ続ければいいはずです。
また、大量のファイルをできるだけ高速に処理したいのでZigで書きたいという気持ちもありましたし、なによりZigで開発するのが好きなのです。
課題の定義
ツールのメインインターフェースはシンプルでした。ファイルの中身を文字列(Zigでいう[] const u8)として受け取り、重複している単語とその行番号のリストを返すだけです。
基本的なインターフェースは次のようになります。
pub const DupeWord = struct {
line_number: u32,
word: []const u8,
};
pub fn FindAdjacentDupes(allocator: std.mem.Allocator,
input: []const u8) !ArrayList(DupeWord) {
// TODO: Implement this.
}そして、最初に用意した単体テストがこちらです。
test "FindAdjacentDupes" {
// Don't consider distinct words to be duplicates.
try testFindDupes("cat dog", &[_]DupeWord{});
// Find simple dupes.
try testFindDupes("cat cat", &[_]DupeWord{
.{ .line_number = 1, .word = "cat" },
});
}
fn testFindDupes(input: []const u8, expected: []const DupeWord) !void {
const allocator = testing.allocator;
var result = try FindAdjacentDupes(allocator, input);
defer {
for (result.items) |item| {
allocator.free(item.word);
}
result.deinit();
}
try testing.expectEqual(expected.len, result.items.len);
for (expected, 0..) |expected_dupe, i| {
try testing.expectEqual(expected_dupe.line_number, result.items[i].line_number);
try testing.expect(std.mem.eql(u8, expected_dupe.word, result.items[i].word));
}
}Clineの最初の結果
わずか30秒ほど、LLMのクレジットにして0.09ドルで、Clineはテストをパスさせました。

ClineがFindAdjacentDupesを次のように更新していました。
pub fn FindAdjacentDupes(allocator: std.mem.Allocator, input: []const u8) !ArrayList(DupeWord) {
var result = ArrayList(DupeWord).init(allocator);
var it = std.mem.splitScalar(u8, input, ' ');
var prev_word: ?[]const u8 = null;
while (it.next()) |word| {
if (prev_word) |prev| {
if (std.mem.eql(u8, prev, word)) {
const dupe_word = try allocator.dupe(u8, word);
try result.append(DupeWord{
.line_number = 1,
.word = dupe_word,
});
}
}
prev_word = word;
}
return result;
}Clineはvarをconstの代わりに使ったり、非推奨のAPIを使ったりと回り道もしましたが、人間と同じようにエラーメッセージを元に自己修正していました。
この時点の実装は明らかに不完全で、Markdownの書式や大文字・小文字、句読点などには対応していませんでした。行番号が1以外のテストケースを見せていなかったため、現在の実装では行番号が常に1を返すようにハードコードされていました。
ここで一気に引き込まれました
Clineが最初の実装を終えたあと、私は新しいテストケースを次々と書き足し、Clineがそれを満たすためにコードを更新していく様子を眺め続けました。
そして、すっかり虜になりました。こんな方法でソフトウェア開発ができるなんて、ただただ驚きでした。やりたいことを伝えるだけで、ツールが求めた通りに着実にやってくれるのです。
冒頭でも紹介した、実際の作業風景の動画がこちらです。
成果
その日は残りの時間をClineと一緒にツールの実装に費やし、ついに重複単語検出ツールの動くバージョンが完成しました。wordwordと名付けました。
wordwordを使って、私のブログからlexical illusionの誤りを7件見つけることができました。
かかった費用は、OpenRouterでのクレジットで合計わずか6ドルでした。これはClineと5時間ぶっ続けで作業した分に相当します。
ここまでで学んだこと
放置したままの作業は非効率ですが、安すぎて気になりません
Clineには各ステップの前に計画の承認を求めるオプションがあります。しかし5秒ごとに「承認」を押すのにすぐに飽きてしまったので、ファイルの読み取り、書き込み、コマンド実行は自動承認するように設定しました。
注意を向けずに放置していると、Clineがときどき行き止まりにはまり、失敗すると分かっている戦略を何度も繰り返すことがありました。
それでも私は、解決に至るか20回の試行上限に達するまで、基本的にはClineを放置して実行させ続けました。行き止まりでAPIクレジットを消費しても、せいぜい数セントの話です。アシスタントを細かく管理するより、数セントを無駄にするリスクを取る方がましだと感じました。
Clineはあなたを無条件に信じるので、言葉は慎重に選びましょう
Clineが最も混乱したのは、私が誤った挙動を期待するテストケースをうっかり書いてしまったときでした。
これは私が急いで書いてしまったテストケースです。
// Detect duplicates after a heading
try testFindDupes(
\\## Foods
\\
\\These potatoes potatoes are the best!
, &[_]DupeWord{
.{ .line_number = 1, .word = "potatoes" },
}本来3とすべき行番号を、誤って1と書いてしまいました。
Clineにこのテストをパスさせようとしたところ、明らかに3であるべきところをどうやって1として正当化するのか悩み、少しパニック状態になってしまいました。
デバッグ出力を追加させるのが有効です
LLMは、コードがなぜそのように動作するのか情報を集めるために立ち止まるよりも、解決策を当てずっぽうに推測しがちだと感じます。
Clineがバグ修正でやみくもな試行のループにはまったときは、一度作業を止めて、コードに関する仮説を検証するためにデバッグ出力を挿入するよう指示すると効果的でした。Clineは役立つデバッグ出力を追加し、解決完了を宣言する前にきちんとそれらをすべて削除してくれました。
Kagiは私のせいで赤字になっているに違いありません
従量課金のLLM APIを使うのは今回が初めてでした。これまでトークンコストについて語る人は見かけましたが、Kagiは基本的に「コストは気にしなくていい」と言ってくれるので、実感がわかずにいました。
Clineはコーディングタスクごとにどれだけクレジットを消費したかを随時表示してくれるので便利です。

つまり、Kagiの月額25ドルの無制限プランでは、間違いなく私の方が得をしています。Clineで5時間かけて6ドル使いましたが、Clineはトークン消費を抑える工夫をいろいろとしてくれています。私は毎日Kagi Assistantを使い、会話の中で巨大なファイルを10回以上貼り付けることもよくあります。今回コストを目の当たりにして、おそらく私は1日あたり5〜10ドル分のAPIクレジットをKagiに負担させているのだろうと思います。
参考資料
AIに関する記事の多くは中身が薄く、実践的な学びが得られないものがほとんどです。そんな中で、何が可能かを知る上で特に役立った記事は次のとおりです。
- “Everything I built with Claude Artifacts this week” by Simon Willison
- “How I Use ‘AI’” by Nicholas Carlini
- “How I program with LLMs” by David Crawshaw
記事をランダムに読む