株式会社ジェイテックジャパン CTOの高丘 @tomohisaです。前回のAIペアプログラミングの記事に続き、既存プロジェクトの開発をAIとともに進める実践的な手法をご紹介します。
はじめに
この記事は以前書いた「ClineでMemory Bankをやめてタスクリストを使うことによってコンテキストを最適化してる」の改善版です。特に既存のプログラムを修正するためにどんな工夫をしているか、タスクリストとタイムスタンプ付き設計ファイルを導入することによって、AIがワイルドに修正しすぎないようにコントロールすることができてきた実践例を紹介します。
Cline と Copilotの共存
基本的にClineとCopilot に同じ指示を設定しています。微妙な動作の違いはありますが、ほぼ同じような結果を得られるようにしています。
Cline側の設定
カスタムインストラクションとして、英語圏でよく使われている感情を文章の最後に書く様に依頼しています。
Be humble and do what I ask you. If you have a good idea, ask me if I want to do it.
Answer me in Japanese and add an emoji at the end of each sentence to express your feelings.
Write comments only for class and function XML comments.
Write other comments only when exceptionally important.
和訳するとこんな感じです。
謙虚に振る舞い、私の指示に従ってください。もし良いアイデアがあれば、それを実行してよいかどうかを私に尋ねてください。
日本語で回答し、各文の末尾に感情を表す絵⽂字を付けてください。
クラスや関数の XML コメントにのみコメントを記述し、その他のコメントは特に重要な場合にのみ記述してください。
また、.clinerulesフォルダにプロジェクト固有の指示を記述しています。
Copilot側の設定
copilot-instructions.mdファイルに同様の指示を追加しています。基本的にはClineのCustom Instructions + .Clinerules の内容を統合した形です。
# Basic
Do exactly what I ask. You are assisting, do not break current feature without being asked.
Just suggest if you think about better refactoring.
Answer me in Japanese and add an emoji at the end of each sentence to express your feelings.
# Project Structure
- The project follows a clean architecture pattern with Event Sourcing as the core persistence mechanism.
- Domain models are organized into aggregates, each with its own events, commands, and projections.
- The frontend is built with Blazor, following a component-based architecture.
# 各種コマンドや環境情報（省略）...
タスクリストの作り方
AIがコードを変更する前に、タスク単位での計画立案を行わせる仕組みを導入しています。
タスク指示ファイル
clinerules_bank/taskフォルダに、000_bug_something.mdのような形式でタスク指示ファイルを作成します。
このファイルには：
- ワークスペース内の相対パスを使ったファイル参照
- やって欲しい解析、見て欲しいファイルの明示
- 数ファイル程度の変更で済むような計画
- ドメインコードの変更に集中した指示
を記述します。
たとえばこんな感じです。
clinerules_bank/tasks/021_start_group.123243.md
clinerules_bank/tasks/021_start_group.md
でStart Displayが正しく動く様になりました。
でも、2つのグループを作って、AdminWebの
EsCQRSQuestions/EsCQRSQuestions.AdminWeb/Components/Pages/Planning.razor
からStart Displayをすると、
EsCQRSQuestions/EsCQRSQuestions.Web/Components/Pages/Questionair.razor
で表示した2つの別のグループ両方に質問が表示されてしまいました。
EsCQRSQuestions/EsCQRSQuestions.Web/Components/Pages/Questionair.razor
での登録が悪いのか、
EsCQRSQuestions/EsCQRSQuestions.AdminWeb/Components/Pages/Planning.razor
での通知側が悪いのか
EsCQRSQuestions/EsCQRSQuestions.ApiService/IHubNotificationService.cs
EsCQRSQuestions/EsCQRSQuestions.ApiService/HubNotificationService.cs
EsCQRSQuestions/EsCQRSQuestions.ApiService/QuestionHub.cs
でのハンドリングのどれかが悪いと思うので、コードを書く前に調査と変更方法を考えてください。
ただ、このタスクでは計画するだけです。
このファイルの下部に計画をよく考えて追記で記入してください。必要なファイルの読み込みなど調査を行い、できるだけ具体的に計画してください。
わからないことがあったら質問してください。わからない時に決めつけて作業せず、質問するのは良いプログラマです。
設計はチャットではなく、以下の新しいファイル
clinerules_bank/tasks/022_filter_code.[hhmmss 編集を開始した時間、分、秒].md
に現在の設計を書いてください。また、あなたのLLMモデル名もファイルの最初に書き込んでください。
後半の ただ、このタスクでは計画するだけです。 以降は定型文で、かつこのファイルに追記ではなく、
clinerules_bank/tasks/022_filter_code.[hhmmss 編集を開始した時間、分、秒].md
の様に指示することにより、複数回作る場合に、別ファイルとして作成できるという利点があります。
この様にすることにより、指示と設計を別ファイルにして、別のモデルで設計をそれぞれ作らせて比較したり、設計が悪い場合に指示を追記して正しい設計になる様に修正することができます。
実際には、Copilot Agentも、Clineも時々設計ファイルを作らずに、チャット内で設計を進める場合がありますが、その時も設計ファイルに書く様に指示して、ファイルが残る様にしています。
この方法で、過去のタスクおよび設計ファイルを消すことも可能ですが、特に直近10回くらいの設計と指示は残しておくことにより、次の指示にも流用することができるので、CopilotやClineのコンテキストのことを心配せずに使うことができます。
また、指示と設計がファイルになっていることで、CopilotとClineで行き来をすることも問題なくできる様になります。Copilotで設計を作って、その設計をClineで実装するなども、ファイルを指示に使うことにより、自由に行うことができます。
設計を開始するときは
clinerules_bank/tasks/021_start_group.md を実行して
で設計を開始します。
設計ファイル
タスク指示に対して、AIは設計を書き込むファイルを生成します（1つのタスク毎に複数作ることも可能）。このファイルには変更前にやるべきことが詳細に記述されます。
これはPlanモードがこんな風に動いて欲しい機能です。個人的にはClineのPlanモードは期待した動きをあまりしてくれないので、常にActモードを使っています。この設計内容は、必要に応じてチャットで調整したり、別のモデルで試したりして、最適な設計を選択できます。
例として、実際のタスクリストサンプル（グループフィルタリング機能の問題解決）を見てみましょう：
のように、時間数字の入ったmdファイルを作ってくれます。複数回生成される場合は、別のファイルで作成されるので、良い設計を選ぶことが可能になります。
このフォルダには実際に使った多くの指示ファイルと設計ファイルを保管していますのでよろしければご覧ください。
タスクリストを使った開発の進め方
この手法の核となるのは、段階的な計画と実行のサイクルです：
-
タスクリストと設計ファイルの作成
AIに計画を立てさせ、複数の設計案から最適なものを選びます。設計が不十分な場合は、参考コードや模範例を追加します。 -
タスク実行と動作確認
選択した設計に基づいてAIにコーディングさせ、動作確認を行います。
実行は以下のコマンドで行います。
clinerules_bank/tasks/022_filter_code.124817.md の実装を行なって
-
コミットと次のタスク計画
良いコードはコミットし、次のタスクへと進みます。多くの場合、次のタスクは前のタスクと関連しているため、前のタスクの指示ファイルや設計ファイルを参照として渡します。 -
セッション管理
ClineやGithub Copilot Agentのチャットセッションは、コンテキストの管理のために新しく始めることが多いです。ただし、タスクが短く、AIの応答に語尾の絵文字がしっかり付いている場合（コンテキスト余裕のサイン）は、同一セッションで続けることもあります。 -
コード検証
全てのコードを精査しない場合もありますが、変更されたファイル一覧や動作確認、テスト結果などでクオリティを判断します。 -
プルリクエスト構成
1つのプルリクエストには複数のタスクが含まれることが多く、関連する変更をまとめて管理します。
モデルの選択
ClineとCopilotの使い分け
- Copilot: 一定数previewでSonnet3.7が使える場合はCopilotを優先
- Cline: Anthropic APIが設定済み
- 使い分けの妙: Copilotの設計が満足できない場合、Clineに設計させ直す場合も。プロンプトのスマートさ、検索などのコマンド連携の設定が優れているため、同じモデルでもClineの方が良い設計を生み出すことがあります。
最適なモデルの選定
- Sonnet3.7: 現状では圧倒的に良い結果（C#コードやタスクリスト方式との相性が良い可能性）
- Gemini 2.5 Pro: 定期的に試すものの、現時点では満足できる設計・コードが得られていない
- GPT 4.1o: Gemini 2.5よりは良好な結果、今後も検証予定
良いプロダクトにしていくために
AIツールを活用する上で重要なポイントをまとめます：
AIツールを活用する上で、人間がいつ介入すべきかを見極めることが重要です。私が実践している3つの原則を紹介します。
まず「2ターンルール」を設けています。同じ問題に対してAIが2回連続で満足のいく解決策を提示できない場合は、手動コーディングモードに切り替えます。無理にAIに解決させようとすると時間を浪費することがあるため、早めの切り替えが効率的です。
次に「検証の徹底」です。AIは時に「フワッとした理解」に基づいたコードを生成することがあります。表面上は動いているように見えても、エッジケースや将来的な拡張性を考慮していないことがよくあります。そのため、生成されたコードを人間がしっかりと検証し、必要に応じて改善することが不可欠です。
最後に「問題解決力」の重要性です。AIが同じ解決策を繰り返し提案したり、問題の本質を捉えられずに堂々巡りになることがあります。そういった場合に、自力でバグを特定し解決する能力が求められます。結局のところ、自分自身が時間をかければ解決できる問題しか、AIでも効果的に解決できないという現実があります。これは「AIは魔法ではなく、あくまでツール」という認識を持つことの大切さを示しています。
設計の重要性
イベントソーシングとアクターモデルの組み合わせで、ドメインに集中できるコード分類とスケーラビリティを実現しています。以前の記事でも触れましたが、将来的な機能追加のしやすさを重視した設計を目指しています：
実践例
このプロジェクトは元々イベントソーシング勉強会のために約3時間、$15程度で作成したものですが、その後少しずつ改良を続けています。現在までの投資は合計で約40時間、$100未満程度ですが、複雑な機能追加や複数の質問グループへの対応などを実装しています。このプロジェクトは、オープンソースで継続開発していますので、実際に参考にしていただけます。
AIが生成したコードを自分で理解・修正できるようになってきたことで、既存プログラムの修正作業にもAIコーディングを使った協働作業が実現できるようになってきました。
まとめ
タスクリストとタイムスタンプ付き設計ファイルを活用することで、AIによるコーディングをより制御可能にし、既存のプロダクト開発に安全に取り入れることができます。AIと人間それぞれの強みを活かし、効率的かつ品質の高い開発を進めていくための実践的なアプローチを今後も模索していきたいと思います。
Discussion
This is amazing, thank you for sharing.
You're welcome!
This is English Version of this article!