機能の開発
コードベースを理解したら、新しいものを作ってみましょう。
エージェントを活用して機能をリリースするには、作業をエージェント自身で確認できるステップに分割することが重要です。主要な機能は必ずプランから始め、エージェントが自らのミスを検出して修正できるよう、適切なガードレールを設けましょう。
プランを立てて始める
エージェントは、コードを書き始める前に何を作るか考えるのに役立ちます。
コードを書く前には、検討すべきことが数多くあります。機能のアイデアがある場合は、まずシンプルなバージョンを作り、後から改善を重ねることもできます。また、考慮すべき特定の設計上の判断がある場合もあります。
コードを書く前に、コーディングエージェントを使ってこうした判断を検討できます。Cherri Code の Plan モード では、エージェントがコードベースを調査し、補足の質問を行い、編集・変更できる段階的なプランを作成します。
Plan モードにプロンプトを送信すると、エージェントはまず要件を把握するために質問します。
回答すると、エージェントは機能を作る過程で確認・検証できるマイルストーンを含む構造化されたプランを生成します。このプランは編集可能なため、気になる点があれば変更できます。
通知設定
概要
ユーザー設定に通知設定ページを追加します。ユーザーはカテゴリごと（マーケティング、製品更新、セキュリティアラート）に、メール、プッシュ、アプリ内通知を切り替えられます。設定はデータベースに保存し、UI は楽観的に更新します。
アプローチ
タスク
Cherri Code は、大きなリクエストをより小さな、個別に検証可能なステップに分割することで、プランを実用的なものにします。各ステップで、エージェントは進捗を確認し、正常に完了したことを確認してから次に進みます。
最初からやり直すタイミング
エージェントが期待どおりのものを作れないことがあります。フォローアッププロンプトで修正しようとするのではなく、プランに戻りましょう。変更を元に戻し、再度実行する前にプランをより具体化します。
たとえば、重要なアーキテクチャやシステム設計に関する注記を見落とすと、プランが誤ったものを作ってしまう可能性があります。プランから最初からやり直すのは一見遠回りに思えますが、誤った方向で始めたアプローチを継ぎはぎで修正するよりも、結果的に速いことがよくあります。
エージェントを使ったテスト駆動開発
エージェントは、自分のコードが正しいかどうかを判断できるときに最も力を発揮します。テストが失敗すると、何が問題だったのかを確認して再試行できます。
エンジニアは長年テスト駆動開発を活用してきましたが、常に最も一般的なコードの書き方だったわけではありません。エージェントを使えば、先にテストを書くのがはるかに簡単になり、コードベースの成長に伴ってテストの価値も高まります。
- 最初にテストを書く。 期待する入力と出力に基づいてテストを書くようエージェントに依頼します。まだ存在しないコードのモック関数を作らないよう、TDD を行っていることを明示してください。
- テストが失敗することを確認する。 テストを実行し、失敗することを確認するようエージェントに伝えます。この時点では、機能のコードを書くことが目的ではありません。
- テストをコミットする。 テストカバレッジと品質に満足したら、テストをコミットします。これにより、エージェントが実装の基準とする要件が固定されます。
- エージェントにコードを書くよう依頼する。 テストを変更せずに、すべてのテストを通すよう伝えます。すべて通るまで繰り返します。
- コードをコミットする。 出力を確認し、期待どおりに動作することを確認してからコミットします。
テストをコミットしたら、エージェントにコードを書くよう伝えます。テストを変更せずに、すべてのテストを通す必要があることを明示してください。
なぜこれほど効果的なのでしょうか。エージェントはテストを実行し、失敗を確認し、コードを調整して再試行できるからです。テストを実行するたびに、エージェントは具体的なフィードバックを得られます。テストがなければ、変更したコードが正しく動作するかを知る方法がありません。
このアプローチは、画面を見るだけでは正しさを確認できないバックエンドコードで特に有用です。テストで期待する挙動を記述すれば、エージェントがそれに合うコードを書きます。
エージェントを使った TDD ワークフローで、エージェントにコードを書かせる前にテストをコミットすべき理由は何ですか？
デザインをコードに変換
エージェントは画像を処理・理解できます。スクリーンショットやモックアップをプロンプト入力欄に直接貼り付けると、エージェントが画像に基づいてデザインを再現できます。
次のような用途で利用できます。
- モックアップ: ワイヤーフレームやFigmaのエクスポートを貼り付け、エージェントにコンポーネントの作成を依頼する
- 視覚的なデバッグ: 想定外のUI状態をスクリーンショットに撮り、エージェントに調査を依頼する
- 反復作業: 現在の結果のスクリーンショットを撮り、変更すべき点を説明する
Figma MCP サーバーを接続すると、エージェントはFigmaファイルからデザイントークン、変数、コンポーネントの仕様を直接取得できます。
統合ブラウザでは、エージェントが変更を加えながら結果をプレビューできます。このブラウザを使うと、エージェントはページに移動し、スクリーンショットを撮影して、自身の視覚的な出力を確認できます。これにより、スクリーンショットを手動でエージェントに渡し直す必要がなくなります。
よくある失敗パターン：検証せずに作る
機能を素早く作る際の最大のリスクは、検証を省略することです。エージェントは大量のコードを高速に生成できますが、正確性を伴わないスピードは、後でかえって作業を増やす可能性があります。
エージェントが作業を検証できるようにする具体的な方法は次のとおりです。
- ロジックと挙動のテスト
- 構造的な正確性を確認するための型チェック
- コードスタイルとパターンを徹底するためのリンター
- UI の変更に関するフィードバックを取得するためのブラウザツールまたは MCP サーバー
エージェントが出力を検証できない場合、修正により多くの時間を費やすことになります。
次のステップ
機能をリリースしました。しかし、ソフトウェアにはバグがつきもので、中には厄介なものもあります。次の章では、エージェントを使ってバグを体系的に見つけて修正する方法を学びます。