Java 8 → 25 メジャーアップが 1 日で終わった話 ─ Claude Opus 4.7「engineer to delegate to」の威力

はじめに

GMOコネクトの永田です。

「Java 8 → 25 (4 LTS 飛ばし) + AWS SDK v1→v2(破壊的変更あり) + JWT/JSON/ロギング系も軒並みメジャーアップ。最低限疎通させるだけでも数週間、全件リグレッション込みなら数ヶ月仕事で、きつそう😇」という案件相談を受けました。
同じタイミングで Claude Opus 4.7 がリリースされ、Anthropic 公式の "Treat Claude more like a capable engineer you're delegating to than a pair programmer you're guiding line by line." に背中を押される形で、「逐次指示するペアプロ型」ではなく「Goal を渡して委譲する engineer to delegate to 型」を試してみました。

結果、検証込みで 1 日で完走、開発体験が別物に変わった ので、その記録です。メジャーアップに限った話ではなく、それを支えていた 「AI エージェントに逐次指示しないと進まない」という前提 が変わった話として読んでもらえると嬉しいです。

先にまとめ

最低限疎通スコープで 数週間 → 1 日 (検証含む)。

• 規模感: 本体 Java 数万 SLOC、依存 60 程度 (top-level + 推移的)、運用中の Lambda 関数群
• 想定工数 (最低限疎通スコープ) 数週間 → 実所要 1 日 (検証含む) ─ Before/After を同スコープで比較。全件リグレッション込みなら従来は数ヶ月、Claude 駆動でも追加数日〜数週間。
• Phase A/B/C を 単独でロールバック可能 に切り、検証は Lambda 単体疎通 + E2E smoke (Playwright) の二段構え。OTP 取得まで人手レス化して staging でも再利用可能に。

ポイントはClaude Opus 4.7 で強化された engineer to delegate to スタイルです。Goal / Constraints / Acceptance criteria を初回に渡して委譲するスタイルを活かすために、人が事前に整える 4 つの環境設計:

#	ポイント	これをやらないと	効いた場面
1	Acceptance criteria (Done の定義) を最初に明文化	「動いた = OK」で先に進み、ログ消失等の回帰を見逃す	Done に「CloudWatch に想定外 WARN/ERROR 無し」を含めただけで、Claude が invoke 直後に自律でログ取得 → SLF4J NOP fallback を即検出
2	Constraints (作業ルール) を 5 項目程度に明文化 (横展開・commit 粒度・ロールバック等)	後半で取りこぼしが噴出	「同パターン全件検索」ルールで Map.toString → Gson の取りこぼし複数件を Claude が一斉抽出 → 一斉置換
3	影響範囲は Claude に整理させ、Phase 切り分けは最後に人で握る	Phase の切り口がブレる、設計判断まで AI 任せになる	Claude 初期案で Phase A に紛れていた挙動変化系を人レビューで Phase C に分離、検証範囲を絞り回帰の原因切り分けが容易に
4	Claude が CLI を直接叩ける環境 + Auto Mode (AWS CLI / mvn / Playwright / CloudWatch)	「Claude 出力 → 人が実行 → ログ転送」の往復 + 承認ループで人が呼び戻される	修正 → デプロイ → 実機 invoke → CloudWatch 解析 → 次の修正 が 1 セッション内で完結、長時間タスクは別作業しながら待つ

この 4 つが揃った瞬間、開発体験が別物になりました。「次は何するんだっけ → コマンド打って → ログ見て → 解析して → AI に投げ直す」ループを人が回す側から、Goal を渡して結果を受け取る側へ立場が変わります。

第1部: 設計編 ─ Claude に委譲できる粒度に Phase を切る

ここは 委譲のための前提準備 にあたるパートです。委譲する単位を間違えると、Claude が走った後に回帰の原因切り分けで人が苦労する羽目になります。

1.1 一気にやらない: Phase A/B/C の役割分担

メジャーアップに伴う変更を 1 コミットに混ぜると、回帰が出たときの切り分けが地獄になります。とはいえ「依存を 1 つ上げては検証」の刻みすぎも工数が肥大化します。今回は変更の性質で 3 つに切りました。

Phase	何をするか	何をしないか	ロールバック単位
A	AWS SDK v1 → v2、JWT、json-simple → Gson 全置換 など Java 8 ランタイムでも動く lib だけ先行入れ替え	ランタイムはまだ java8.al2、Java 11+ 必須の lib (logback 1.5.x 等) はまだ触らない	A の jar を baseline に戻す
B	pom.xml の java.version=25 + ランタイム識別子を java25 へ + Java 11+ 必須の lib (logback 1.5.x 等) を最終バージョンへ	アプリ層のコード差分はゼロ (pom.xml のバージョン番号と依存追加だけ)	ランタイムだけ java8.al2 に戻す + lib バージョンも併せて Phase A 状態へ
C	不要依存削除 (abandoned project / 参照ゼロ lib)、Object.finalize() 撤去、dead code 一掃	ロジック変更なし	該当ファイルだけ revert

切り方の判断基準は 「Phase 単位で回帰が出たときに原因を絞り込めるか」 がメインです。狙いは「Phase A で起きた回帰なら lib 入替が原因」「Phase B で起きた回帰ならランタイム切替が原因」と即断できる切り分け線を引くこと、です。

Phase A に入れる lib の選別は、Goal を渡しただけで Claude が公式ドキュメントから各 lib の Java 要件を集めてラベル付き一覧を返してきました。人がやったのは、その一覧をレビューして「Phase A は旧 Java 8 ランタイムで動くもの限定」という線引きを Go するだけ。例えば:

ライブラリ	採用バージョン	Java 要件	Phase 配置
AWS SDK for Java v2	2.43.x	Java 8+ (公式)	Phase A
logback-classic	1.5.x	Java 11+ (公式)	Phase B にずらす

logback 1.5.x は Java 11+ 必須なので Phase A には入れられません。Phase A の段階では logback 1.3.x (Java 8 LTS 系で SLF4J 2.x 対応) を経由するか、logback 自体は触らずに Phase B でランタイム切替と同時にまとめて 1.5.x へ上げる かの 2 択。今回は後者を選択しました。

今回のスタックでは AWS SDK / JWT / Gson / SLF4J api までは Java 8 ランタイムで動きましたが、ロギングの logback 1.5.x だけは Java 11+ 必須なので Phase B にずらす必要がありました。この 1 件を Phase 設計時に追い出すかどうかで、Phase A の単体疎通が成立するかどうかが決まります。

1.2 ロールバックを「1コマンド」に保つ運用

Phase ごとに デプロイ成果物 (jar) を S3 の別キーに残しておく だけで、aws lambda update-function-code で任意の Phase baseline に 1 コマンドで戻せます (実コマンドは AWS 公式の Lambda runtime updates ドキュメント参照)。

ポイントは技術ではなく 「詰んだら戻せる」という安心感を Phase に進む前に作っておく こと。後続 Phase に思い切って進められるかどうかが工数に直結します。

1.3 リグレッション試験は「先に」作る

メジャーアップに踏み込む前に検証手段を仕上げておかないと、終盤で「動いたかどうか分からない」状態になります。今回は 2 段構えにしました。

検証手段	何が分かるか	何が分からないか
Lambda 単体疎通 (aws lambda invoke で JSON event を直接食わせる)	コード経路の単体疎通、SDK 呼び出しが新しい lib で通るか	フロントエンドからの実 HTTP 経路、SPA の SPA ルーティング、CloudFront 等の前段、認証セッションの実フロー
E2E smoke (Playwright で実ブラウザ → 実 HTTPS)	上記の単体疎通では出ない実運用バグ (ハマり 2 件は全部こっちで初検出)	コールドスタート所要時間や warm 時のレイテンシ等の性能観点は別途 (CloudWatch Lambda Insights や負荷試験で見る)

検証ポリシーは「メジャーを上げた lib は主要な API 呼び出しを 1 ルートは消化する、SDK は機能カテゴリごとに 1 ルート以上正常疎通したら OK」というラインで握りました。完全網羅ではなく「変更で影響を受けそうなパターンを最低 1 ルート」という割り切りが、1 日完了の前提条件です。

第2部: 委譲スタイルの核心 ─ Goal / Constraints / Acceptance criteria を握る

ここが本記事の核です。Claude Code に「Java を上げといて」と漠然と振ると Phase の切り口がブレたり、終盤で取りこぼしが噴出したりします。最初の 30 分で Goal (達成したいこと) / Constraints (作業ルール) / Acceptance criteria (Done の定義) を明文化 するのが、Opus 4.7 を engineer to delegate to として扱えるかどうかの分岐点です。

2.1 影響範囲を Claude に机上で見切らせる (lib 差分抽出)

最初の指示は Goal だけです。

「Java 8 ランタイムの Lambda を Java 25 まで上げたい。まず影響範囲を調査して、依存ライブラリと Java 要件を整理してほしい」

これだけ渡すと、Claude は自律で

• mvn dependency:tree を直接実行 (CLI 直叩き環境を整えていたおかげ。ポイント 4)
• 各 lib の最新バージョン + Java 要件を公式ドキュメントから収集
• メジャー/マイナー/patch の判定 + Phase 振り分け案

を 1 セッション内でこなしてきます。返ってくるのはラベル付きの依存一覧 (例):

+- software.amazon.awssdk:auth/regions/s3/cognito/ses/secretsmanager:2.43.x [Phase A: lib 入替 (Java 8+ OK)]
+- ch.qos.logback:logback-classic:1.5.x                                      [Phase B: メジャー (Java 11+ 要件)]
- com.github.fge:json-schema-validator (abandoned, 参照ゼロ)                  [Phase C: 削除]

人がやるのは この Phase 振り分けが妥当かを読み直すだけ (= ポイント 3)。Object.finalize 撤去や dead-code 削除を Phase A から Phase C にずらしたのもこの段階の人レビューでした。今回の最終配分:

• Phase A 確定: SDK v1→v2 全置換 / JWT メジャーアップ / json-simple → Gson 全置換 / slf4j-api 2.0.x の明示宣言 (= Java 8 ランタイムでも動くもの)
• Phase B 確定: pom.xml の java.version=25 化と --runtime java25 切替 + Java 11+ 要件の lib (logback 1.5.x) を最終バージョンへ (Java コードの差分はゼロ)
• Phase C 確定: 不要依存削除 + Object.finalize() 撤去 (Java 18 で deprecated forRemoval=true ─ JEP 421) + dead code

なお AWS SDK v1→v2 のような「ツールが揃っている」移行は Claude も道具を選びます。今回は AWS 公式の v1→v2 移行ガイド と OpenRewrite recipe を Claude が拾って、機械的置換できる範囲を切り出してくれました。

2.2 作業ルールを最初に Claude のコンテキストに明文化する

Claude Code は会話の冒頭で明文化した「ルール」を以後の作業で参照してくれます。各 Phase に進む前に、以下を文章で渡しておくと終盤の手戻りが減ります。

作業ルール:
1. 横展開: 1 ファイルでパターンを変更したら、同パターンを project 全件検索して
   取りこぼしを報告。私が確認してから一斉置換に進む。
2. commit 粒度: Phase をまたぐ変更を 1 commit に混ぜない。
   Phase 内でも論理的なまとまり (lib 1 つの置換、SLF4J 統一、SDK v2 化、等) ごとに
   こまめに commit を切る。後で目視レビューしやすい粒度を優先する。
3. 検証ポリシー: メジャーを上げた lib は主要な API 呼び出しを 1 ルートは消化。
   AWS SDK は機能カテゴリごとに 1 ルート以上正常疎通すれば OK。
4. ロールバック: Phase B のデプロイ前に Phase A の jar を S3 に baseline として
   別キーで残す。問題が出たら baseline に戻す。
5. ログ確認: Lambda 単体疎通 実行後は CloudWatch を確認し、
   想定外の WARN/ERROR が無いか報告。機能が動いてもログ消失は致命的。

ルール 1 (横展開) が第3部のハマり 3 件のうち 2 件を救いました。ルール 5 (ログ確認) が SLF4J NOP fallback を即検出させました。ルール 2 で Phase 内も細かく commit を切っておく と、E2E で回帰が出たときに「Phase 内のどの変更で入ったか」を git bisect で素早く特定できます。「書いておいてよかった」となるのは罠を踏んだ後なので、最初から明文化しておくのが良いです。

2.3 「Done の定義」を最初に握る

「動いた」の解像度を上げる作業です。Claude にも人にも同じ指標で握ってもらいます。

観点	Phase A の Done	Phase B の Done
ビルド	mvn clean test PASS (テストは旧ランタイム JDK でも動くもの)	JDK 25 で mvn clean test PASS
デプロイ	dev に java8.al2 のまま新 jar 反映	dev に --runtime java25 反映、LastUpdateStatus=Successful
Lambda 単体 (Lambda 単体疎通)	機能カテゴリごとに 1 ルート以上、CloudWatch に正常ログ	同左
E2E smoke (Playwright)	login → 1 サブ画面表示まで通る、想定外 console error/network failure なし	同左 + ランタイム切替後も同等の挙動
ロールバック試運転	baseline 戻し動作を 1 回実演	(Phase A で実演済)

2.4 Claude が CLI で直接触れる環境を整える

Claude Code は AWS CLI / mvn / git / Playwright のような CLI ツールを自分で直接叩いて動作確認 できます。逆に言うと、ここを準備しておかないと「Claude が修正案を出す → 人が手元で実行する → ログを Claude にコピペで戻す」という往復が発生して工数が膨らみます。

最初に握っておくと効くもの:

項目	やっておくこと
AWS CLI	dev アカウントへの認証情報。aws lambda update-function-configuration aws cognito-idp ... aws logs filter-log-events あたりを Claude が叩ける状態に。操作 scope (dev のみ・読み取り中心、書き込みは確認込み) は最初に明文化 しておく
Maven / JDK	mvn clean test mvn dependency:tree を Claude が叩ける。JDK 25 をローカルにインストールして Claude にも参照可にしておく
Playwright	npx playwright install chromium 済 + smoke スクリプトをリポジトリ内に配置
ログ取得	CloudWatch Logs を aws logs filter-log-events で Claude が読める状態 (一旦 stdout に出させて解析させる)

これにより 「修正 → デプロイ → Lambda 実機呼び出し → CloudWatch 取得 → 解析 → 次の修正」 が 1 セッション内で完結します。CLI の権限スコープは事前に明文化して人が握るのが鉄則で、書き込み系コマンドは Claude が初実行時に確認を入れる運用が安全です。

加えて Claude Code の Auto Mode をオンにしておくと、tool 呼び出しごとの承認確認が省略され、CLI 直叩きと組み合わせて長時間タスクを放置できます。逐次承認のループまで人が抜けられる、という開発体験の最後の 1 ピースです (もちろん書き込み系の権限スコープは事前明文化が必須)。

第3部: 委譲したら何が起きるか ─ 自走で潰した 3 つのハマり

第1部・第2部で土台を整えたあと、Phase B 検証の Goal/Acceptance criteria を握って Claude を走らせると、ハマり 3 件の検出から修正まで人がほぼ介入せずに完走しました。「ハマった話」というより 「委譲したら自走でこう動く」のサンプル集 として読むと、開発体験のリアリティが伝わると思います。

Phase A (lib 差し替え) と Phase B (ランタイム切替) の Lambda 単体疎通 は淡々と通ります。同じ JSON event で機能カテゴリごとに 1 ルート以上を消化し、CloudWatch に正常ログが出ているかを Claude に確認させて Done に倒します。「動いた」だけで確認を切り上げず、CloudWatch をちゃんと覗く運用 (作業ルール 5) が早速 1 件目を救います。

3.1 ハマり1: SLF4J 2.x で NOP fallback (単体疎通中、CloudWatch で発見)

• 現象: Phase B 単体疎通の冒頭、CloudWatch からアプリログが完全消失 (SLF4J: ... Defaulting to no-operation (NOP) logger)
• 原因: logback 1.5.x は SLF4J 2.x を前提に動くが、AWS SDK v2 が引き込んだ slf4j-api 1.7.36 が 推移的依存 で Maven の依存解決に勝ち、1.7 系が探しに行く StaticLoggerBinder クラスを logback 1.5.x が提供しないため NOP に落ちる (SLF4J error code 解説)
• 修正: pom.xml で slf4j-api:2.0.x を明示宣言、依存解決を 2.x に統一

Claude 活用ポイント (Goal 駆動の自律発見)

機能テストの JSON レスポンスは正常に返るので、「動いた = OK」スタイルだと永久に気づかない罠 です。

ここで効いたのが、Done 定義 (2.3) と作業ルール 5 (CloudWatch 確認を Done 必須に) を 最初に明文化して渡しておいた こと。「Phase B 検証完了の条件は X, Y, Z (CloudWatch に想定外の WARN/ERROR が無いことを含む)」と Goal を握らせただけで、私が「ログ確認して」と途中介入することなく、Claude が invoke 直後に自分で aws logs filter-log-events を叩き、SLF4J NOP の警告を報告してきました。Acceptance criteria を満たすルートを Claude が自走で組み立てた、という流れです。

これは Opus 4.7 で強化された 「Goal + Constraints + Acceptance criteria を初回に渡し、途中介入は最小化する」 スタイルが効いた典型例です (Claude Opus 4.7 の主要な変更点 で詳説)。Anthropic 公式の表現は

"Treat Claude more like a capable engineer you're delegating to than a pair programmer you're guiding line by line."

そのもので、ペアプロ的に逐次指示するモードから委譲モードへの切り替えが、Opus 4.7 を活かす最大のスイッチでした。

裏を返すと、Done 定義に「CloudWatch 取得 + 想定外ログなし」を入れていない案件では人手レビューでも見落としがち な性質です。Done 定義の精度がそのまま検出の精度になります。

3.2 E2E でも 2 件バグを発見

Phase A/B の Lambda 単体疎通 が通った段階で、Playwright で実ブラウザ + 実 HTTP の smoke を流したら 2 件出ました。どちらも Lambda 単体疎通 では検出不能な構造です。

ハマり2: java-jwt 4.x で JWT.decode(null) の例外型が変わった

• 現象: E2E smoke で初回ログイン POST が 502
• 原因: 旧コードが内部実装由来の NPE に依存して catch (NullPointerException) で受けていたが、java-jwt 4.x で入口が JWTDecoder.decode(String) 経由になり正規の JWTDecodeException を投げる挙動に変わったため、旧 catch から漏れた
• 修正: decode 入口で null/empty ガード + 想定外な形式の token に備えて JWTDecodeException も明示的に catch する形に変更

Claude 活用ポイント

修正方針として「catch (JWTDecodeException) を増やす」と「入口で null/empty ガード」の 2 案が挙がりました。Claude にいきなり「どちらがいい？」と聞かず、「両案を比較表で出して。私が決める」 と振った結果、両者の役割が違う (前者は想定外な壊れた token への防御、後者は想定済みの login 初回 POST の素通し) と整理でき、両方採用 が結論になりました。

E2E smoke スクリプト (Playwright) 自体も Claude に書かせていたので、smoke 実行 → ブラウザのコンソールエラー収集 → CloudWatch 突合 → 原因特定までが 1 セッション内で完結します。

ハマり3: Map.toString() を Gson に食わせる箇所が複数残っていた

• 現象: ログイン直後の業務ロジックで JsonSyntaxException → 500
• 原因: 旧 JSONObject#toString は JSON シリアライズだが、Phase A で Map<String, Object> に置換した結果、Map#toString() の {key=value} 形式が Gson.fromJson に流れて例外
• 修正: JsonHelper.stringify(map) (= gson.toJson(map)) に置換

Claude 活用ポイント (横展開の威力)

この類のバグは 「1 箇所気づいたが、他にも同じパターンが何箇所残っているか分からない」 が一番怖い性質。Goal 駆動で握ったルール群 (「Done 定義に E2E smoke 通過を含める」+「作業ルール 1 で横展開」) の合わせ技で、Claude は人手レビューを介さず一気に最後まで自走してくれました。

1. 検出: Phase B の E2E smoke を Claude が自分で起動 → /xxx/yyy 遷移後に 500 を踏んで stop → smoke の HTTP ログと CloudWatch を Claude が自分で突合 → JsonSyntaxException の発生箇所を特定
2. 診断: 該当行の map.toString() が JSON ではないと根本原因を特定
3. 横展開 (作業ルール 1 発動): project 全体を全件検索、修正済 1 件 + 取りこぼし複数件を一覧化して報告
4. 適用: 私が「OK」と返した時点で Claude が一括 patch + ビルド検証 + smoke 再実行

私から指示したのは Phase B の Goal/Acceptance criteria だけで、500 検出も診断も全件検索もすべて Claude が自走で組み立ててきました。

「人手で 1 箇所修正して残りを忘れる」が一番怖い類の罠で、最初から横展開を作業ルールに書いておくか否かで事故率が大きく変わります。Gson の挙動は仕様で確定 + 静的解析で検出可能 + ビルド通過で即時確認、と条件が揃っているのでこの種のバグは Claude の独壇場です。

第4部: 運用編 ─ 委譲を将来も再利用するための人手レス E2E

ここは 「engineer to delegate to の開発体験を、未来の自分や別環境にも引き継ぐ」 ためのパートです。メジャーアップは prod 反映までに staging でもう一度同じ試験を流すことが多く、その都度人がブラウザを叩くと工数が積み上がるだけでなく、Goal を渡しても「最後だけ人が画面ポチポチ」の点で委譲スタイルが破綻します。Playwright + 補助スクリプトで OTP 取得まで人手レス化したので、staging では Goal を渡し直すだけで同じ試験が走ります。

4.1 Playwright + メール OTP の自動取得

二段階認証が絡む経路は OTP コードをメールから読んで入力 というステップが入るので、ここを自動化しないと反復試験になりません。gog (gogcli) という Google Workspace CLI を使い、Gmail から narrow に OTP メールを polling します。

# 起動時刻以降の新着 OTP メールだけを拾う (個人メール一般を読まない設計)
QUERY="from:<otp-sender> subject:<otp-subject> newer_than:1h in:anywhere"
gog gmail messages search "$QUERY" --include-body --max 5 --json

• 起動時に既存メッセージ ID を baseline として保存し、新規発生 ID のみから 6 桁数字を抽出 (古い OTP の誤拾い防止)
• in:anywhere を必ず付与 (開発環境でのシステム送信メールは Gmail の自動判定で SPAM 行きになることがある)
• 検索条件を 送信元 + 件名 で絞り込み (個人メール一般は読まない、最小権限の原則)

抽出した 6 桁を otp.txt に書き出し、Playwright 側はファイルを polling して読む、というファイル結合だけにしておくと、gog が無い環境では人が echo 123456 > otp.txt で手で投入する逃げ道も残せます。

4.2 staging 等での再利用

URL/ユーザー名は env (SMOKE_BASE_URL / SMOKE_USERNAME) で切り替え、OTP fetch 側も送信元アドレス・件名・クエリ全体を env で上書き可能にしておくと、staging では SMOKE_BASE_URL=... を変えるだけで同じ試験が走ります。後日同じ手順を別環境で回す 未来の自分 へのレバレッジが効きます。

まとめ

工数の Before / After

工程	従来想定 (逐次指示型)	Claude 駆動の実績 (委譲型)	短縮の主因
影響範囲調査	数日	30 分	dependency tree 差分を Claude に整理させる + 人で握り直す
Phase A 実装 (lib 大入替)	数週間	数時間	SDK v1→v2 は OpenRewrite + Claude、JSON/JWT/SLF4J は Claude が一気に修正
Phase B 実装 (ランタイム切替)	数日	数十分	コード差分ゼロに絞り込んでおいたので即時
検証 (単体疎通 + E2E)	数週間	数時間	smoke スクリプト + OTP 自動取得まで Claude に書かせる
Phase C (不要依存削除)	数日	1 時間	参照ゼロ判定を Claude に走らせる
合計 (最低限疎通スコープ)	数週間	1 日

注: Before/After は同じスコープ (最低限疎通) で揃えました。全件リグレッション試験仕様書込み だと従来想定は数ヶ月、Claude 駆動でも追加数日〜数週間が必要です。

開発体験の Before / After

数値以上に変わったのが手触りでした。

観点	逐次指示型 (Before)	委譲型 (After)
人の役割	「次は何するんだっけ → コマンド打って → ログ見て → 解析して → AI に投げ直す」のループを人が回す	Goal/Constraints/AC を渡して結果を受け取る、人は判断点だけ握る
ハマりへの対応	人がエラーログを見つけて Claude に転送 → 解析させる → パッチ案を待つ	Claude が CloudWatch を自分で叩いて検出 → 診断 → パッチ → 再検証まで自走
横展開	人が「他にも漏れてないか確認して」と毎回頼む	作業ルール 1 が常時効いて、修正のたびに自動で全件報告が返る
終わりの判定	人が「動いてるかな…」と CloudWatch をしぶしぶ覗く	Done の AC に CloudWatch 確認を含めるだけで Claude が自走で確認
承認ループ	tool 呼び出しごとに人が確認、放置できない	Auto Mode で全自動、長時間タスクは別作業しながら待つ
心理状態	「メジャーアップは長丁場、覚悟して臨む」	「Goal 渡して別の作業しながら待つ」

まとめ

メジャーアップが 1 日で終わったことよりも、「次は何やる、どう確認する」を逐次考えなくてよくなった ことのほうが体験としては大きい変化でした。Claude を「速い作業者」ではなく engineer to delegate to として扱うために、Phase で切り分け線を引き、Goal/Constraints/Acceptance criteria を握り、CLI 直叩き + Auto Mode で環境を整える ─ この事前準備さえできれば、メジャーアップに限らず長丁場の作業全般で「Goal を渡して別の作業をしながら待つ」スタイルが現実になります。

「メジャーアップは大変」だけでなく、それを支えていた 「AI エージェントに逐次指示しないと進まない」という前提 ごと、Opus 4.7 で過去のものになりました。

---

最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。

お問合せ：https://gmo-connect.jp/contactus/