はじめに
AIによるプログラミング支援ツールの進化は目覚ましく、特にClineとSonnet 3.7の組み合わせは、プログラミングのパラダイムを大きく変えつつあります。本記事では、これらのツールがどのようにプログラミングの方法論を変革し、開発者の役割を再定義しているかについて、実践的な知見を共有します。
Sonnet 3.7: 『真似プログラミングの天才』
Sonnet 3.7の現在の個人的評価は、『真似プログラミングの天才』と表現できます。これは、すでにインターネット上に存在する類似コードを微調整して作成することが非常に得意という意味です。特にフロントエンドやゲーム開発が得意なのは、これらの分野のコードが学習データに豊富に含まれているからでしょう。
例えば、「C#のバックエンドで、フロントエンドがBlazorのシステムを作って」と指示すると、すぐに実用的なシステムを構築してくれます。しかし、その内容はお世辞にもアーキテクチャとしてよく考えられたものではなく、とりあえず動作するが、大規模システムとして成長させていくためには、ファイル構造、使用するデータ管理手法、基本設計、プログラミングスタイルなどを改善していかないといけない、いわゆる初心者向けテンプレートとなります。
しかし、Sonnetは真似をするのがとても上手なので、アーキテクチャとして基本設計が整ったものをテンプレートとして渡して、それをSonnetが真似をして機能追加をしていくことにより、簡単に将来性を考えたアーキテクチャを考慮したプロジェクトを開始することができます。この能力は、既存のパターンを理解し、適切に応用できる「真似の天才」としての特性を示しています。
プログラマの新たな役割：「真似の素」の供給者
AIツールの台頭により、プログラマの役割は変化しています。最も重要な役割の一つが「真似の素」を供給することです。アーキテクチャについて最初からSonnetに考えさせるのではなく、基本的な枠組みとして成長可能な優れたアーキテクチャを説明したり、提供したりする必要があります。
新しい種類の機能、例えばPlaywrightによるE2Eテストを一から作らせると、様々なサンプルからそれらしいものを作成しますが、正確性に欠けることがあります。機能が少なくても、正しく設計され正しく動作するものが先にあると、その後の拡張がスムーズになります。
また、イベントソーシングとCQRSを使ったシステムを作成してほしいと依頼しても、いきなり良いものができるわけではありません。基本的な設計思想についても説明することが必要です。
そうなってくると、プログラマにとって大事になってくるのは、いろいろな事例や本の知識、サンプルコード、実際の経験などから、アーキテクチャについての知識を増やしていくことが大切になります。『動けばコードの質やアーキテクチャの組み合わせはどうでもいい』と考えてそのように指示するととりあえず動くものしか作ってくれませんし、大規模システムに対応した強固なシステムを作ってと頼んだら、インフラ費用が高すぎて豪華すぎるシステムになる可能性もあります。アーキテクトとして将来を見据えつつ今必要な技術を考えることが大事になりますね。
コンテキスト管理の重要性
AIとの協働において、コンテキスト量は費用に直結します。また、コンテキストが多すぎると、どの指示を優先すべきか分からず混乱することがあります。
例えば、関数型ドメインモデリングの本を実践したいからといって、本の内容をを全部コンテキストに入れても、うまくいかないと思います（試してはいません）。自分がやりたいプログラミングスタイル、例えば値オブジェクトの使い方、APIの定義方法、フロントからのアクセス方法などを、1つでも正しく動くサンプルとして提供し、「真似」してもらうことで効率的にプログラミングできます。
前述のPlaywrightの例でも、1つのテストを開発者が作成してデバッグし、それを真似して似たようなE2Eテストを作ってもらったところ、スムーズに実装できました。
デバッグアプローチ
デバッグに関しては、AIにある程度任せてみると意外とできることが多いですが、同じ問題で無限ループに入った時は開発者が大胆に修正する必要があります。
Webでよく見られる単純なパターンのエラーであれば、Sonnetにエラーメッセージを見せるだけで修正してくれることが多いです。実行結果のエラーを見せて対策を考えさせるなど、まずはAIの能力を試してみるのが良いでしょう。
ただし、AIが同じ修正を繰り返し行い、コストだけがかかって実が伴わないこともあるので、進捗を注意深く確認することが重要です。Planモードで考えを確認することも大切ですが、Actモードや生成されるDiffを見ながら、怪しくなってきたら具体的な説明をスレッドに書き込んで調整するとよいでしょう。
調整して成功した時には、memory bankに学んだことを記録してもらうことで、次回以降の作業効率が向上します。
Clineの教育と成長を助ける
Clineとの協働では、「しつけや教育、成長を助ける」という考え方が有効です。毎回の思考過程を観察し、特に間違いが発生した時に、どのような情報が不足していたのか、どのような「真似の素」がなくてうまくいかなかったのかを考えることが重要です。
指示書を更新していくことも大切です。ただし、手作業で指示書を更新するのではなく、「今回はこんなことを理解していなかったから間違えたよね、次に同じことを間違わないように記録しておいて」と言って、AIに自ら指示書を更新させる方法が効果的です。
ClineのMemory Bank機能は非常に有用です。私は以下のカスタムインストラクションをそのまま使用しています：
メモリーバンクには、以下のファイルが含まれます：
- activeContext.md
- productContext.md
- progress.md
- projectbrief.md
- systemPatterns.md
- techContext.md
「init memory bank」という指示で全体を読み込んでメモリーバンクを作成してくれ、「update memory bank」でそのセッションで覚えておきたいことを記録します。読み込みコンテキストが増えるため、必ずしもこれにより劇的に技能が向上したとは言えませんが、作業の安定性は向上したと感じます。毎回細かな指示を与えなくて済むというのが大きなメリットです。
言語選択：日本語 vs 英語
私は個人的にインストラクションや指示書は英語で更新させており、普段の指示も半分以上は英語で行っています。ただし、日本語で指示した場合も明らかに質が落ちるようには感じません。プロジェクトや個人の好みに応じて選択するとよいでしょう。
フレームワークのスタイルガイドの重要性
フレームワークを使用する場合、そのスタイルガイドが非常に重要になります。私は会社でSekiban（イベントソーシング、CQRSフレームワーク）を開発しており、Clineでの作業中に発生した問題点をフレームワークの指示書として更新しています。
.clinerulesファイルで技術的な事項はこのファイルを参照するように設定しています。これにより、フレームワークの実装基礎を理解しやすくなり、非常に有用です。
Sekibanのコンセプトは、低コストで開始でき、必要に応じてスケールアップが可能（アクターモデル）で、イベントソーシングによりデータが消失しないため、LLMで大量のコードを書く時代に最適なフレームワークだと感じています。
以下の記事に、イベントソーシングとアクターモデルのくみあわせがAIプログラミング時代に有用と考えるかを書きました。併せてご覧ください。
実際の使用方法
新規プロジェクトの場合、.NETをインストールした後、空のリポジトリに.clinerulesとsekiban.instructions.mdファイルを作成し、https://github.com/J-Tech-Japan/Sekiban/blob/main/README_Pure_For_LLM.md の内容をsekiban.instructions.mdに書き込みます。その後、Clineで以下のように指示するだけで、テンプレートのインストールから自動的に行ってくれます：
sekiban.instructions.md のやり方で、C#で学生と生徒を管理をするウェブアプリを作って
これだけで、データベース設定、BlobやQueueの設定も含めて、テンプレートをダウンロードして実装してくれます。その後、部分的に修正したり、メモリーバンクを設定したりして開発を進めることができます。
参考として、以下のリポジトリをご覧ください。これは現在Cline研究のために使用しているもので、基本的なインストラクションなどが設定された状態のものです：
LLMの選択
現状の選択肢としては、個人的に試したものではSonnet 3.5と3.7の2つがありますが、3.7の方が明らかにスキルが高いです。3.5は仕事を小さくまとめて細かな指示を与えれば正しく実行してくれますが、大きな仕事はうまくいったことがありません。
一方、3.7は指示していない部分も積極的に改善しようとするため、指示した内容以外のことをしないよう繰り返し伝える必要があることもあります。英語で指示している場合は、「ONLY DO WHAT I ASK!」のように大文字で書くと、意外と指示を守ってくれます。
o1, o3 mini, 4o, Gemini 2.0 flash, DeepSeek R1 (local), PHI-4, Codestral, llama 3.3, qwen 2.5 coder などは試してみた限りでは、Clineとの相性の可能性もありますが、どれもSonnet 3.5にも届いていないと感じています。
こまめなコミットの重要性
AIによる開発では大きな間違いが発生することもあるため、良いタイミングでこまめにコミットすることが重要です。まとめて作成したものは頻繁に確認してコミットすることで、間違いが発生してもタスク全体が失敗しないようにすれば、安心して作業を進められます。
まとめ
Cline+Sonnetの組み合わせは、費用はかかるものの、プロダクティビティは大幅に向上するため、しばらく積極的に活用していきたいと考えています。個人的にはSonnet 3.7の限界として、私自身が書いているような複雑な設計を完全に理解して実装することは難しいと感じており、そのためDevinなどの他のツールには手を出していません。
自分の子どもの活動を逐次観察して一緒に過ごすことで成長を促すように、ClineやCursorなど思考過程が逐次見えるツールを使い、間違いが発生したら「真似の素」をアップデートする方法が、現時点では最も効果的だと考えています。AIがさらに成長し、共通インストラクションが確立されてきたら、より自立型のDevinやOpenHandsなどのツールを試してみるのも良いでしょう。
個人的には、Clineがコーディングする様子を観察するのは非常に楽しいです。どのような材料、知識、指示を与えたらどのような結果が得られるかを見ることで、技術の進歩を実感できるからかもしれません。AIによってプログラミングが退屈になったとは感じず、むしろより面白くなったと感じています。
ただし、これらのツールを使いこなせる人材の育成も今後の重要な課題となるでしょう。引き続き最新技術のキャッチアップを続けていきたいと思います。
Discussion