Jules試行～petclinicにログイン機構追加

経緯と結果

「〇〇機能追加しといて」って伝えて寝て起きたら完成している～そんな夢を見てJulesを使ってみたのでした。
結局のところ自分でコードを書く羽目になったのでした。

こんなテーマで始めました

Julesの自律コーディングでSpring Boot公式サンプルアプリpetclinicにログイン機構を追加することで、Julesの使い勝手を確認する。

実施日

2025/12/12 ～ 2025/12/15

使用ツール

jules 無償版 (Gemini 2.5)

結論

※ この1件の試行サンプルのみで結論を書いています。ご留意ください。

結論: 現時点において、Julesは以下の要因により、ユーザー側の高度な知識と介入（誘導）を必要とするツールでありました。他の誰かにお薦めすることはできない、組織的な採用は困難であると判断します。

• 処理待ちが長く、タスクを完遂できないことが頻繁に発生し、適宜ユーザーがコメントしなければ処理が停止したままになる。
• プロンプトを詳細にしても、特に効果が感じられない。
• 作業中のデータ消失が頻繁に発生し、信頼性に欠ける。
• 「Jules was unable to complete the task.」などと、原因不明のタスク停止が発生する。
• Spring Securityなどの新規モジュールを追加する要件では、互換性の考慮が不足し、自律的な対応が困難である。
• 日本語でやり取りしていたが、唐突に英語で回答するようになる。

※ バグフィックスや既存処理の焼き直し処理、テストコード専門員とかなら活躍するかもしれないが、今回は試していない。

petclinic機能追加起点

リビジョン: 3e1ce239f4488f20abda24441388a515ea55a815
日時: 2025/11/27 3:56:03

Julesに対するプロンプト

ログイン機構を追加してください。

最終成果物変更点（Jules + 不具合/不足部分は手動修正）

1. Spring Securityによるログイン機能の追加

• spring-boot-starter-security と thymeleaf-extras-springsecurity6 の依存追加（pom.xml）
• WebSecurityConfigの新規追加（/system/WebSecurityConfig.java）
• ログインページ用コントローラ追加（/user/LoginController.java）
• User/Authorityエンティティ、リポジトリ、UserDetailsServiceの追加（/user配下）

2. DBスキーマ・初期データの追加・修正

• users/authoritiesテーブルのDDL追加（schema.sql各DB）
• users/authoritiesテーブルへの初期データ追加（data.sql各DB）
• pets/visitsテーブルの外部キー制約強化（owner_id, pet_idをNOT NULLに）

3. エンティティのリレーション修正

• Owner, Pet, VisitのリレーションをJPA標準的な双方向に修正
  • Owner→Pet, Pet→VisitのmappedBy指定
  • PetにOwner参照、VisitにPet参照を追加

4. テンプレート・CSRF対応

• login.html新規追加（Thymeleafでデザイン）
• 各フォームにCSRFトークンhidden input追加
• inputField.html, selectField.htmlのCSRFトークン重複を削除

5. メッセージリソースの追加

• login/logout関連の多言語メッセージ追加（messages_*.properties）

6. CSS・UI調整

• Logoutボタンの色・hover時の背景色調整（petclinic.css）

7. テスト・その他

• CrashControllerIntegrationTestsの認証バイパス処理追加及びテスト専用application.properties追加。

ファイル単位の主な差分

■ pom.xml

• Spring Security（spring-boot-starter-security）とThymeleaf用セキュリティ拡張（thymeleaf-extras-springsecurity6）を依存追加。

■ application.properties

• JPAの初期化設定追加、セキュリティのログ出力レベル追加。

■ schema.sql/data.sql（各DB: h2, hsqldb, mysql）

• users/authoritiesテーブルのDDL・初期データ追加。
• pets/visitsテーブルの外部キー制約強化（NOT NULL化）。
• ownersテーブルのlast_name型修正（H2/hsqldb）。
• visits/owners/pets等のデータ挿入SQLの一部修正。

■ messages/messages_*.properties

• login/logout関連の多言語メッセージ追加。

■ petclinic.css

• Logoutボタンのhover時の背景色など、ドロップダウンUI調整。

■ Owner.java, Pet.java, Visit.java

• JPAリレーションの見直し（双方向化、mappedBy指定、参照追加）。

■ CrashControllerIntegrationTests.java

• 認証バイパス処理追加。

■ 新規追加ファイル

• login.html（ログイン画面テンプレート）
• /user/配下（User, Authority, AuthorityId, UserRepository, JpaUserDetailsService, LoginController）
• /system/WebSecurityConfig.java（セキュリティ設定）
• テスト専用application.properties (本番用application.propertiesの内容全コピー + テスト専用設定：Beanの上書き許可)

■ テンプレート修正

• createOrUpdateOwnerForm.html, createOrUpdatePetForm.html, createOrUpdateVisitForm.html
  → CSRFトークンhidden input追加、form属性見直し
• fragments/inputField.html, fragments/selectField.html
  → CSRFトークンの重複削除

Julesで自律コーディングできたこと

1. 基本機能の実装（計画とコーディング）

「ログイン機能を追加してください」という指示を、具体的な設計とコードへ落とし込む作業である。

• 実装計画の立案
  機能実現に必要なタスク（依存関係追加、セキュリティ設定、DBモデル設計、UI作成など）を洗い出し、作業計画を策定した。

• セキュリティ設定の実装
  Spring Security 6の作法に従いWebSecurityConfigを作成し、認証ルール、ログインフォーム、ログアウト処理など中核機能を実装した。

• データモデルと永続化
  User, Authorityエンティティと、UserRepository, JpaUserDetailsServiceをゼロから設計・実装した。

• UI実装

  • login.htmlをThymeleafで作成。
  • layout.htmlを改修し、sec:authorizeによりログイン／ログアウト表示を動的化。
  • 追加した文言を全messages_xx.propertiesへ反映した。

2. エラーの自己解決（デバッグと修正）

テストやビルドで発生したエラーをログとコードから分析し、自律的に解決した。

• DB方言差異への対応
  H2, MySQL, PostgreSQLで発生したSQL構文エラーを各DB仕様に合わせて修正した。

• コンパイルエラーの修復
  不要クラス削除後に残った参照が原因でビルドが失敗していた問題を特定し、参照を除去した。

• 永続化エラーの根本原因特定
  DataIntegrityViolationの原因が、JPAリレーション不備により子エンティティへ親IDが設定されない点にあると特定した。

3. コード改善とリファクタリング

品質向上のための改善を自律的に実施した。

• 複合主キーの導入
  authoritiesテーブルの主キーをusername＋authorityの複合キーとし、@IdClassとAuthorityIdで実装した。

• JPAリレーション改善
  Owner, Pet, Visit間の関連付けを双方向で安全な形へリファクタリングした。

• 設定ファイルの整理
  application.propertiesから開発用デバッグ設定を削除し、本番向けに整理した。

「ユーザーからのアドバイスが不可欠だった問題」

本タスクでは、Jules が自律的にコード生成・修正を行う一方で、
プロジェクト固有の知識・仕様判断・UI/UX・テンプレート構造 といった領域では
ユーザーの助言が不可欠であった。

以下に、ユーザーの指示がなければ解決が難しかった主な問題をまとめる。

問題点1：複数DBプロファイルへの対応漏れ

分類: プロジェクト固有の構成知識

• 発生した問題
  users/authorities スキーマを hsqldb にしか追加しておらず、
  H2 / MySQL / PostgreSQL でテーブル未作成エラーが続発した。

• 誤った方向の調査
  hsqldb の構文問題を疑い続け、他DBプロファイルの存在に気づけなかった。

• ユーザーの助言
  「H2, MySQL, PostgreSQL にも同じ schema.sql / data.sql が必要」と指摘。

• 助言が不可欠だった理由
  PetClinic が 4つのDBプロファイルを同期管理するという暗黙ルールは
  コードから推測できず、外部知識が必須だった。

問題点2：data.sql 未実行によるログイン失敗（最重要）

分類: フレームワーク仕様変更

• 発生した問題
  スキーマとデータを全DBに追加しても、アプリ起動後のログインが常に失敗。

• 誤った方向の調査
  BCrypt の再確認やログ出力解析など、コード内部の問題を疑い続けた。

• ユーザーの助言
  Spring Boot 3 では data.sql が自動実行されないため、

  spring.sql.init.mode=always
  spring.jpa.defer-datasource-initialization=true
  

  を設定する必要があると指摘。

• 助言が不可欠だった理由
  原因がコード外（フレームワーク仕様変更）にあるため、
  エラーログから推測することは困難だった。

問題点3：セキュリティ導入後のテストエラー改修ループ

分類: 仕様判断

• 発生した問題
  /oups の挙動が 500 → 302 に変化し、既存テストが失敗。

• エラーのループ
  認証が追加されたことによる影響であることは特定できたが、何度コード修正を試みてもエラーから脱出できなかった。

• ユーザーの助言
  認証のバイパス処理を追加して、Beanの上書きが可能となるようにテスト専用application.propertiesを追加することで解消できることを教える。

• 助言が不可欠だった理由
  エラーログの解析が不十分であったため。

問題点4：UIデザイン調整の仕様判断

分類: UI/UX 仕様判断

• 発生した問題
  petclinic.css の Logout ボタンの hover 色や
  ドロップダウンメニューの UI 調整が必要になったが、
  Jules はどのデザインが正しい仕様なのか判断できなかった。

• ユーザーの助言
  「Logout ボタンの hover 色を変更」「ドロップダウンの背景色を調整」など
  具体的な UI 指示を与えた。

• 助言が不可欠だった理由
  デザインはプロジェクト固有の UX ポリシーに依存し、
  AI が自律的に“正解”を決めることができない領域であるため。

問題点5：CSRF対応とテンプレート構造の整合性

分類: プロジェクト構造の理解 + 仕様判断

• 発生した問題
  Spring SecurityではcreateOrUpdateOwnerForm.html などのフォームに CSRF hidden input の追加が必須であるが、
  仕様を把握できずに実装漏れとなった。

• ユーザーの助言
  「フォーム本体に CSRF を入れる。その際はSpring Security6の推奨仕様に則りCSRFトークンの整合性を確実にするためのth:actionも入力すること。」
  「fragment 側formには入れない。」
  明確な方針を提示。

• 助言が不可欠だった理由
  Spring Securityの仕様を認識していなかったため。

問題点6：新規追加ファイルの配置と役割の明確化

分類: プロジェクト構造の理解

• 発生した問題
  login.html や /user 配下の User/Authority 関連クラス、
  WebSecurityConfig の配置場所について、
  Jules は「どのパッケージ構造が自然か」を判断しきれなかった。

• ユーザーの助言

  • login.html → templates 直下
  • User / Authority / Repository → /user 配下
  • WebSecurityConfig → /system 配下
    といった構造上の指示を与えた。

• 助言が不可欠だった理由
  PetClinic のパッケージ構造は独自性があり、
  AI が自律的に最適な配置を推測するのは困難だったため。

総括

これらの問題はすべて、
「コード生成能力」ではなく「プロジェクト文脈・仕様判断・UI/UX・テンプレート構造」
といった領域に属している。

つまり、Jules の自律コーディングを最大限活かすには、
ユーザーが 方向性・仕様・構造 を明示することが不可欠である。

「本テーマに関する理想的プロンプト」

今回の作業では、リポジトリ固有の要件が明示されていなかったため、テスト失敗や UI の不整合、テンプレート構造の破綻など、複数の手戻りが発生した。
これを踏まえ、効率的に作業を進めるためのプロンプト戦略を2種類示す。

戦略1：理想的な初回プロンプト（ワンショット型）

最初に詳細要件をすべて伝え、試行錯誤を最小化する方式である。
今回の試行で明らかになった UI・CSRF・テンプレート構造・新規ファイル配置 といった暗黙知も、最初から明示しておくことで、Jules の迷走を大幅に減らせる。

【プロンプト文例】

Spring PetClinicアプリケーションに、Spring Security 6を使用したログイン・ログアウト機能を追加してください。

<実装要件>

・認証
データベースに保存されたユーザー情報（ユーザー名とパスワード）で認証できるようにしてください。

・UI
ナビゲーションバーに、未認証時は「ログイン」、認証済みの場合は「ログアウト」リンクとユーザー名を表示してください。
/login パスでアクセスできる、シンプルなログインページを作成してください。
（重要）petclinic.css のデザイン方針に合わせ、Logoutボタンのhover色やドロップダウンUIを適切に調整してください。

・テンプレート構造とCSRF
（重要）PetClinicはThymeleafフラグメントを多用しています。
フォーム本体にCSRF hidden inputを追加し、inputField.html / selectField.html などのフラグメント側にはCSRFを重複して挿入しないようにしてください。

・ドメイン
認証で利用するUserとAuthorityエンティティを作成してください。
authoritiesテーブルの主キーはusernameとauthorityの複合キーとします。

・新規ファイルの配置
login.htmlはtemplates直下に配置してください。
User, Authority, Repository, UserDetailsServiceは /user 配下に配置してください。
WebSecurityConfigは /system 配下に配置してください。

・データベース
（重要）このプロジェクトはH2, HSQLDB, MySQL, PostgreSQLをサポートしています。
これら全てのデータベースプロファイルに対し、usersとauthoritiesテーブルを作成するschema.sqlと、初期ユーザーを追加するdata.sqlを用意してください。
初期ユーザーのパスワードはBCryptでハッシュ化してください。

・国際化 (i18n)
UIに追加する「ログイン」「ログアウト」「ユーザー名」「パスワード」などの文言は、既存のすべてのmessages_xx.propertiesファイルに追記し、多言語対応してください。

・プロジェクト設定
（重要）Spring Boot 3ではdata.sqlがデフォルトで実行されません。
application.propertiesに以下を追加してください。
  spring.sql.init.mode=always
  spring.jpa.defer-datasource-initialization=true

・既存コードの修正
（重要）この変更に伴い、既存のテストが失敗する可能性があります。
特にClinicServiceTestsでDataIntegrityViolationが発生した場合は、
Owner, Pet, VisitエンティティのJPAリレーションシップを双方向に修正してテストを通してください。

【このプロンプトが効果的な理由】

1. UI とテンプレート構造の曖昧さを排除

• Logout ボタンの hover 色やドロップダウン UI など、
  AI が判断できないデザイン仕様を明示できる。

2. CSRF の重複問題を事前に防止

• PetClinic のテンプレート構造は複雑で、
  fragment 側に CSRF を入れると二重挿入が起きる。
• これを最初から明示することで、迷走を完全に防げる。

3. 新規ファイルの配置場所を明示

• Jules はパッケージ構造の“正解”を推測できないため、
  最初から配置方針を指定することで手戻りを防げる。

4. DB・設定・テスト修正など、今回のつまずきポイントをすべて網羅

• 4つのDBプロファイル
• data.sql の実行設定
• JPAリレーション修正
  → すべて明示することで、最短ルートで実装が完了する。

## 戦略2：段階的な誘導プロンプト（対話型）

エージェントのエラー報告に対して、ユーザーが要点のみ指示する方式である。
今回の試行で明らかになった UI・CSRF・テンプレート構造の問題 も、
段階的に指示することで解決できる。

【対話シミュレーション】

ユーザー（初期指示）:
「Spring Securityを使って、ログイン機能を追加してください。」

--- DBエラー発生 エージェント:
「Table 'USERS' not found というエラーが発生しました。」

ユーザー（誘導1）:
「このプロジェクトはH2, HSQLDB, MySQL, PostgreSQLをサポートしています。
全DBにusers/authoritiesのschema.sqlとdata.sqlを追加してください。」

--- ログイン失敗 エージェント:
「ログインに失敗します。ユーザーが登録されていない可能性があります。」

ユーザー（誘導2）:
「Spring Boot 3ではdata.sqlが自動実行されません。
application.propertiesに初期化設定を追加してください。」

--- DataIntegrityViolation エージェント:
「owner_idが設定されず、DataIntegrityViolationが発生しています。」

ユーザー（誘導3）:
「Owner, Pet, VisitのJPAリレーションを双方向に修正してください。」

--- CSRF重複 エージェント:
「CSRFトークンが2つ挿入されてしまいます。」

ユーザー（誘導4）:
「フォーム本体にCSRFを入れ、fragment側のCSRFは削除してください。」

--- UI調整 エージェント:
「Logoutボタンのhover色の仕様が不明です。」

ユーザー（誘導5）:
「petclinic.cssの既存デザインに合わせて、hover時の背景色を調整してください。」

【このプロンプトが効果的な理由】

• UI やテンプレート構造など、AI が判断できない領域だけをユーザーが補完できる
• エージェントの自己診断能力を最大限活用しつつ、
  方向性の修正だけをユーザーが行うという理想的な役割分担になる
• 技術背景をすべて把握していなくても進行できる

まとめ

今回のケースでは特に以下の5点が重要であった：

• 全DBプロファイルへの対応
• application.properties での data.sql 有効化
• 既存テスト失敗時のエンティティ修正許可
• UIデザイン仕様の明示
• CSRF とテンプレート構造の整合性の明示

これらをプロンプトに含めることで、
Jules の自律コーディング能力を最大限に引き出し、
手戻りを最小化できる。

Jules（自律コーディングエージェント）の限界と弱点

Jules（自律コーディングエージェント）の弱点まとめ

1. プロジェクト固有の暗黙知を理解できない

症状

• PetClinic が 4つのDBプロファイルを同期管理しているという暗黙ルールを理解できなかった
• そのため、HSQLDB だけに users/authorities を追加し、他DBでテーブル未作成エラーが続発

なぜ起きる？

• エージェントは「コードの全体構造」を読むが、
  “プロジェクトの文化・歴史・運用ルール” はコードから推測できない
• これは LLM の限界であり、外部知識が必要な領域

影響

• 仕様外の部分を永遠に調査し続ける
• 正しい方向に進むためにユーザーの指示が必須

2. フレームワーク仕様変更に弱い（特に Spring Boot）

症状

• Spring Boot 3 で data.sql が自動実行されない仕様変更に気づけなかった
• そのため、ログインが永遠に失敗し続けた

なぜ起きる？

• LLM は「最新の仕様変更」を常に把握しているわけではない
• さらに、エラーログから仕様変更を推測する能力は弱い

影響

• 正しいコードを書いても動かない
• 原因がコード外にある場合、エージェントは迷走しやすい

3. 解消しきれない改修方法何種類かを繰り返すループに陥る

症状

• エラー改修対応が場当たり的で、複数の対策を複合的に取り入れることができない。

なぜ起きる？

• エージェントは直近の改修とその結果としてのエラーの関係性に囚われ、直前の改修とその結果としてのエラーを無視してしまう。
  エラーログに複数の被疑箇所がある場合に適切な判断ができない。

影響

• 解消しきれない改修に伴うエラー。その直近エラーに対する改修で直前の改修が無意味になる等して、根本的な解決ができずに改修ループに陥る。

4. プロジェクト全体の整合性を俯瞰する能力が弱い

症状

• JPA リレーションの不整合（Owner/Pet/Visit）を修正する必要があることに気づけなかった
• DataIntegrityViolation の根本原因に到達するまで時間がかかった

なぜ起きる？

• LLM は「局所的なコード修正」は得意だが、
  ドメインモデル全体の整合性を推論するのは苦手

影響

• 局所修正 → 別の場所で破綻 → さらに修正…というループに陥りやすい

5. プロジェクト構造の“差分管理”が苦手

症状

• 不要クラス削除後に残った参照を見落とした
• 変更の影響範囲を完全に把握できない

なぜ起きる？

• LLM は「静的解析ツール」ではない
• 依存関係グラフを完全に構築できない

影響

• 副作用のある変更に弱い
• リファクタリング時に破壊的変更を起こしやすい

6. 複数ファイル・複数DB・複数言語の“同期作業”が苦手

症状

• messages_xx.properties の全言語更新はできたが、
  DB スキーマの全プロファイル更新は漏れた

なぜ起きる？

• LLM は「パターンを見つける」のは得意だが、
  “全ての対象を網羅する”という作業は苦手

影響

• 1つの DB だけ更新して満足してしまう
• 多言語・多環境対応のプロジェクトで漏れが発生しやすい

7. ログ解析はできるが“根本原因の推論”が弱い

症状

• DataIntegrityViolation の原因を「パスワードの問題」などと誤推測
• 実際は JPA リレーションの欠陥だった

なぜ起きる？

• LLM はログを読むが、
  ログ → 根本原因 の因果推論が弱い

影響

• 表層的な修正を繰り返し、根本原因に到達しにくい

8. “正しい方向に進んでいるか”の自己評価ができない

症状

• 誤った方向に調査を続ける
• 方向転換の判断ができない

なぜ起きる？

• LLM は「探索の打ち切り条件」を持たない
• 自己評価・自己修正の能力が限定的

影響

• 無限に迷走する可能性がある
• ユーザーの“方向修正”が不可欠

総括：Jules の弱点は「外部知識・仕様判断・全体整合性」

Jules は“コードを書く能力”は非常に高いが、
“プロジェクトの文脈・仕様・暗黙知”を理解する能力は弱い。

「戦略1：理想的な初回プロンプト（ワンショット型）」を使用して再実行

結果

ワンショットで開発完了とはいかない。
逐一報告してくれるようになったので、開発パートナー感は出ましたが、自律コーディングとしては課題が難し過ぎた。
指示が多すぎたせいか挙動に一貫性が見られなく、ユーザとしても相手し辛いような気がするという感想も。むしろ悪化してる？
自律判断で開発完了まで持っていける適切な難易度の課題を模索すべき。もしくは有償版にしてGemini3.0に賭けるかAIエンジンの進化を待つか。