壊れたときに効く動き

配布フォルダの exercises/day3 に、受注バッチを模したクラスが1本だけ置いてあります。Spring Boot 本体からは切り離した単体実行用で、package com.example.order.debug を宣言しています。金額が100万円を超える BATCH-004 と BATCH-005 は外部連携で必ず失敗する作りです。ここでリトライが止まらなくなります。

StackOverflowError は、メソッド呼び出しが深くなりすぎて呼び出しスタックが溢れたときに出る実行時エラーです。このクラスの main はそれを受け止め、見出しを1行出したあと e.printStackTrace() でスタックトレースを標準エラーへ流します。at com.example.order.debug.CrashingOrderProcessor.processWithRetry の行が1000行あまり並び、最後にヒントが2行出ます。JVM が保持するフレームは既定で1024までなので、実際の再帰回数はこれより多いです。Claude Code へ渡す証拠は、標準出力に流れるリトライ表示ではなく、この標準エラーのスタックトレースです。想定しているのは、夜中に落ちたバッチの調査で、朝に残っているのがこの出力だけ、という場面です。当たりを付けるところを Claude Code にやらせて、確認は自分の手でやります。

コンパイルは通るのに ClassNotFoundException や NoClassDefFoundError が出るときは、javac の -d . を付け忘れています。クラスファイルは exercises/day3/com/example/order/debug/ の下に出ます。新しいファイルは作りません。クラス名・パッケージ・メソッドの引数はそのままにして、判定に関わる1行だけを直してください。演習が終わったら cd ../.. でプロジェクト直下、つまり pom.xml がある階層に戻ります。mvn は pom.xml と同じ階層で打たないと、対象のプロジェクトを見つけられません。

application-slow.log は本番想定で取った Spring Boot のログです。GET /api/orders の応答が 156ms、880ms、3350ms、6100ms、9200ms と伸び、最後は OutOfMemoryError で止まっています。30〜34 行目では、orders を1回引いた直後に order_items への SELECT が where i1_0.order_id=? のまま5行続きます。これが N+1 です。一覧を1回引いたあとで明細を1件ずつ取りに行くため、件数 N に比例してクエリが N+1 本に膨らみます。

本編ではコードを直しません。最近この画面が重い、という曖昧な報告から、ログだけで原因を切り分けて対策の効きどころまで言える状態が到達点です。N+1 の解消は応答時間に効き、全件取得をやめる方はメモリに効きます。この2つを混ぜずに分けて言えると、後の改善でどちらから手を付けるかを決めやすくなります。OrderServiceImpl を書き換えるのは発展の D3-2+ だけです。

ログには spring.jpa.open-in-view is enabled by default の警告と、GC pause が Young Gen 450ms から Old Gen 2300ms へ伸びてヒープ使用率が 78 パーセントから 96 パーセントへ上がる様子も残っています。ここまで拾えると、遅いという報告が枯渇の手前だったことまで説明できます。メモは exercises/day3/analysis-slow-log.md に置いてください。行番号を書いておくと、後半の改善で見返すときにログを探し直さずに済みます。

このプロジェクトは Spring Boot Actuator を入れていません。アプリが生きているか、DB に繋がっているかを外から確かめる口が無い状態です。監視に GET /api/orders を使うと業務データを毎回読みに行くので、軽い専用の口を別に置きます。返す中身は status、application、version、database.status、database.orderCount、memory.used、memory.max、memory.usagePercent です。orderCount は配布データの受注件数と同じ 10 になります。

処理時間ログの方は、config パッケージの WebConfig に addInterceptors を足して登録します。HandlerInterceptor は、コントローラの処理の前後に共通処理を差し込む仕組みで、入り口の preHandle と出口の afterCompletion を使います。リクエストIDは MDC に入れます。MDC はログ出力ライブラリがスレッド単位で値を持つ置き場で、消し忘れると次のリクエストに前のIDが残ります。afterCompletion の最後に消す行が入っているかを、差分で必ず見てください。MDC に入れただけではログ行にIDは出ません。既定のログパターンに %X{requestId} が無いためで、logback-spring.xml を新しく作ってパターンを差し替えるところまでが1組です。

依存の受け取り方は2通りあります。private final のフィールドをコンストラクタで受ける形が規約で推奨、@Autowired をフィールドに付ける形が規約で禁止です。差分に @Autowired の行があれば直させてください。新しく作るのは RequestLoggingInterceptor、logback-spring.xml、HealthController、応答を組み立てる src/main/java/com/example/order/dto/HealthResponse.java の4本で、これに WebConfig への addInterceptors 追記が加わります。レスポンスは Map で組まず、record か DTO の専用型にします。JdbcTemplate の Bean が見つからないと言われたら、EntityManager のネイティブクエリで SELECT 1 を実行する形に直させます。jq が入っていない環境では、| jq . を外して curl http://localhost:8080/api/health だけで中身を読めます。細かい打鍵と模範プロンプトは exercises/day3/exercise2-監視とセキュリティ.md にあります。

この口ができたら、Day1 で作った src/main/resources/static/dashboard.html から /api/health を呼び、自分の画面の上に UP と受注件数を並べられます。この画面ファイルはアプリを起動したまま書き換えられ、保存してブラウザを再読み込みすると新しい中身に差し替わります。表示を見て気に入らないところを claude に直させ、また再読み込みして見る、という往復をそのまま続けられます。止めて起動し直すのは Java か設定ファイルを書き換えたときだけです。

新規4本と追記1本を30分で通します。時間内に両方が届かないときは、先にヘルスチェックを動かしてください。処理時間ログは logback-spring.xml までを1組として、残った時間で足します。

レビューの基準は docs/セキュリティチェックリスト.md と docs/コーディング規約.md の2つです。前者は SQL のパラメータ化、入力値の検証、個人情報をログや例外メッセージに出さない、例外の詳細を API レスポンスに含めない、DTO と Entity の分離、H2 コンソールの本番無効化、機密情報をログ・設定に残さない、CORS を必要最小限に、という並びです。後者には禁止パターンとして、フィールドインジェクション、生 SQL の文字列連結、空 catch、System.out.println が挙がっています。手順の細かい打鍵と模範プロンプトは exercises/day3/exercise2-監視とセキュリティ.md にあります。

CustomerController の findAll は Customer エンティティをそのまま返しています。email と phone と address が丸ごとレスポンスに出る形です。createCustomer は @RequestBody Customer でエンティティを直接受けるので、利用者に決めさせたくない項目まで外から書き換えられます。WebConfig の addCorsMappings は allowedOrigins が全許可。3つとも配布時点の実コードにあり、探せば見つかります。

/review は直近で変更したファイルを規約に照らして見るコマンドです。観点を細かく指定したいときは、@ でファイルを渡して自然言語で頼む方が狙いどおりになります。指摘一覧を残すなら exercises/day3/review-result.md あたりです。Origin を付けない素の curl は絞る前も後も 200 を返すので、それは設定を壊していない確認として読みます。絞る前に Origin: http://example.com を付けると 200 と Access-Control-Allow-Origin: * が返り、絞ったあとは Spring が同じ要求を 403 と本文 Invalid CORS request で弾きます。ヘッダだけ消えた 200 にはなりません。直す1件は CORS が手軽ですが、例外ハンドラを新規に作る方を選んでもかまいません。ちなみに例外ハンドラを入れると、存在しない ID への問い合わせが 500 から 404 に変わるので、直した効果がそのまま画面に出ます。