夢を見てJulesに触ってみた結果、夢破れた件
を踏まえて使いどころを再考し、以下観点でCopilotにまとめてもらった。
- ウォーターフォール開発での出番
- スクラム開発での立ち位置
- 人間によるレビューボトルネック対応
1. ウォーターフォール型開発での「Jules」の出番
結論：設計が固まっていることは、AIにとって最大のメリットです。
JulesのようなAIエージェントにとって、最も困難なのは「曖昧さ」です。ウォーターフォール型開発のように、詳細設計書（クラス図、シーケンス図、API仕様書など）が完備されている状態は、AIに対する指示（プロンプト）の解像度を極限まで高めることができるため、非常に相性が良いと言えます。
-
詳細設計からの実装代行:
人間が詳細設計を行い、「このインターフェース定義に従って、内部ロジックを実装せよ」というタスクを投げます。設計という「思考」は人間が担当し、コーディングという「作業」をJulesに完遂させる分業です。 -
テストファーストの実践:
仕様書に基づき、実装よりも先に「単体テストコード」をJulesに大量に書かせます。これは人間がやると退屈で後回しにされがちな工程ですが、AIは文句を言わず高速に実行します。
Julesのワークフローの特徴:
Julesは「プランニング（計画）」→「人間の承認」→「実装」というステップを踏みます。ウォーターフォールにおいても、この「プランニング」段階で設計との整合性を確認できるため、勝手な実装を防ぐことができます。
2. スクラム開発での立ち位置
スクラム開発においては、Julesは「超高速なジュニア～ミドルエンジニア」のような立ち位置でチームに参加できます。
-
PBI（プロダクトバックログアイテム）の消化:
「ライブラリのバージョンアップ」「既存バグの修正」「定型的なCRUD処理の追加」といった、タスクのゴールが明確なチケットをJulesにアサインします。 -
非同期な開発パートナー:
人間が複雑なビジネスロジックやアーキテクチャの議論をしている間に、Julesは裏側（非同期）で環境構築やボイラープレート（雛形）の作成を行います。 -
スプリントレビューの加速:
Julesは変更内容の要約や解説を行う機能も持っているため、何を変更したかの共有コストを下げることができます。
3. 「人間のレビュアーが追いつかない」問題への対策
Julesが24時間体制でPR（プルリクエスト）を出し続けると、人間側のレビューがボトルネックになり、開発フローが詰まる恐れがあります。これを防ぐには、人間の役割を「コードを書く人」から「AIを監督する人（テックリード）」へシフトさせる必要があります。
具体的な対策:
| 対策 | 内容 |
|---|---|
| Lint/Testの自動化 | 人間が見る前に、CI（Lintチェック、自動テスト）を通過したものだけをレビュー対象とします。Jules自身にテストを実行させ、パスするまで修正を繰り返させます。 |
| 解説の義務化 | コードだけを見ようとすると時間がかかります。Julesに「なぜその実装にしたか」の要約や、変更箇所の解説（Walkthrough）を作成させ、レビューの認知負荷を下げます。 |
| 信頼度による選別 | 重要度の高いコアロジックは人間が入念に見ますが、テストコードの生成やドキュメントの更新、単純な移行作業などは、レビュー基準を緩和（あるいはAIによる一次レビューを導入）してスピードを優先します。 |
| Julesによる自己レビュー | 実装後、別のセッションのJules（または別のLLM）に「このコードにバグやセキュリティリスクはないか？」とレビューさせ、指摘事項を修正させてから人間に提出させます。 |
まとめ：Julesの使いどころ
Julesは「自発的に何か面白いものを作る」AIというよりは、「自発的にタスクを完遂する」エージェントと捉えるべきです。
- レガシーコードのマイグレーション: 言語バージョンの移行や、フレームワークの載せ替え（仕様は変えず中身を変える作業）。
- テストカバレッジの向上: 既存コードに対する網羅的なテスト作成。
- ドキュメント生成: コードベース全体の解析とドキュメント化。
- 詳細設計済み機能の実装: 仕様書通りの「製造」工程のアウトソーシング。
設計がしっかりしている現場であればあるほど、Julesへの指示は明確になり、手戻りの少ない高品質なコード生成が期待できます。