Claude Codeに機能削除を委任したら何が起きたか――雑な指示で失敗した話

こんにちは、白々さじきです。

前回から「Claude Code完全委任開発」を検証しています。今回は機能削除をClaude Codeに委任した体験をまとめました。

はじめに：なぜ店候補機能を削除したのか
削除対象の全体像
Claude Codeへの指示方法
実際にやってみた結果
気づいたこと・ハマりポイント
まとめ
次にやること
参考リンク
サポートのお願い

はじめに：なぜ店候補機能を削除したのか

今回の題材は飲み会の日程調整ツールです。技術スタックは以下の構成で作っています。

フロントエンド：React + Vite + TypeScript + Tailwind CSS v4
バックエンド：Hono + TypeScript
インフラ：Cloudflare Workers + D1 + Drizzle ORM

当初は「日程調整 + アレルギー対応 + 店候補共有」の3機能を実装していました。しかし実装を進めるうちに、アレルギーがわからないと店選びできないと思い、プロダクトの方向性を「日程調整 + アレルギー対応」に絞ることにしました。

機能追加はAIに任せやすいイメージがありますが、機能削除はどうでしょうか。削除漏れがあると型エラーやランタイムエラーにつながります。今回はその作業をClaude Codeに委任してみました。

削除対象の全体像

今回削除したのは restaurants テーブルに関わる全コードです。レイヤーごとに整理すると以下の通りです。

レイヤー	ファイル	削除内容
DB スキーマ	src/server/db/schema.ts	restaurants テーブル定義（Drizzle）
マイグレーション	migrations/0004_drop_restaurants.sql	DROP TABLE IF EXISTS restaurants（新規作成）
型定義	src/shared/types.ts	RestaurantRow 型、AddRestaurantRequest / AddRestaurantResponse 型、各レスポンス型の restaurants フィールド
バックエンド	src/server/routes/events.ts	restaurantRows クエリ×2、レスポンスマッピング×2、POST エンドポイント（約40行）
API クライアント	src/client/lib/api.ts	addRestaurant() メソッドと関連 import
フロントエンド	src/client/pages/admin.tsx	state 3変数、handleAddRestaurant() 関数（約25行）、店候補フォーム・一覧 JSX（約70行）
フロントエンド	src/client/pages/event.tsx	参加者画面の店候補表示セクション（約28行）

変更規模は9ファイル、226行削除でした。追加行数（100行）の大半は今回作成した指示書ファイルとログです。

Claude Codeへの指示方法

口頭で「店候補機能を削除してください」と伝えることも可能でしたが、今回は事前に削除対象を列挙した指示書ファイル（docs/remove-test.md）を用意しました。後述する失敗経験から、雑な指示では意図通りに動かないとわかっていたためです。

指示書に書いた主な内容は以下の3点です。

削除対象をフロントエンド・バックエンド・DBに分けてチェックリスト形式で列挙
「コメントアウト禁止・完全削除のみ」「新機能追加禁止」などの制約を明示
完了条件として tsc --noEmit 完走・ビルド完走・マイグレーション作成を定義

Claude Codeへのプロンプトはシンプルです。

docs/remove-test.mdを元に機能の削除を実施してください。

実際にやってみた結果

削除前のデータ確認

削除を依頼する前に、wrangler コマンドで本番の restaurants テーブルのデータ件数を確認しました。0件だったため、バックアップなしで削除を進めました。

作業の流れ

Claude Codeは指示書を読み、schema → types → routes → api → admin → event の順に削除を進めました。しかし events.ts の修正途中で応答が止まりました。

「進捗を報告してください。」と送ると、完了済みと残作業を整理して返答。「続けてください。」で作業が再開し、最終的に全削除・マイグレーション作成・型チェック・ビルド確認まで完了しました。

検証結果

チェック項目	結果
tsc –noEmit	型エラーゼロ ✅
pnpm build	正常完走（153ms）✅
削除漏れ	なし ✅

気づいたこと・ハマりポイント

雑な指示では意図した削除にならなかった

実は今回が初めての削除指示ではありません。以前「投票機能を削除して」と一言だけ伝えたことがありました。結果、投票機能自体は消えましたが、店の追加機能と参加者への店候補表示はそのまま残りました。

Claude Codeは「投票」という言葉に直接対応するコードだけを消した形です。店候補機能全体を削除したかったにもかかわらず、意図とはかけ離れた結果になりました。

この失敗を踏まえて今回は指示書を用意しました。削除対象をファイル単位・コード単位でチェックリスト形式に列挙したことで、型定義・APIクライアント・フロント・バックエンドの整合性を保ちながら、意図通りに全て削除できました。

教訓：機能名だけの指示では部分削除にしかならない。削除対象はファイル・コード単位で列挙した指示書を事前に用意してから依頼すること。

規模の大きいタスクは途中で止まることがある

今回、events.ts の修正途中で応答が打ち切られました。出力トークンの上限に達したと考えられます。「続けてください」で再開できましたが、止まったことに気づかず放置すると削除が中途半端なまま残ります。

対策としては、settings.json の maxTokens を増やすか、タスクを「バックエンドのみ」「フロントエンドのみ」のように分割して渡す方法が有効です。

教訓：規模の大きいタスクは出力トークン上限で途中停止することがある。止まったことに気づけるよう、作業後は必ず完了状態を確認すること。

削除は「指示の粒度」がそのまま結果に出る

削除作業は一見シンプルに見えますが、曖昧な指示では部分削除にしかならないことが今回よくわかりました。「〇〇機能を削除して」という機能名レベルの指示では、AIはその言葉に直接対応するコードしか消しません。関連する型定義・APIエンドポイント・UIコンポーネントのどこまでが「その機能」なのかを、AIは文脈から自動で判断してくれるわけではありませんでした。

逆に、削除対象を列挙した指示書を用意すれば、機能追加より高い精度で作業を完了できます。「何を消すか」が固まっていれば、実行はAIに任せられます。

教訓：削除作業の品質は指示の粒度で決まる。「何を消すか」を人間が整理できれば、「どう消すか」はAIに委任できる。

まとめ

今回の作業でわかったことを整理します。

機能名だけの指示では意図した削除にならない。以前「投票機能を削除して」と伝えたときは、投票のみ消えて店候補の追加・表示は残ってしまいました
削除対象をファイル・コード単位で列挙した指示書を渡すことが前提。それさえ用意すれば、型エラーゼロ・ビルド通過まで一気に任せられます
規模の大きいタスクは出力トークン上限で途中停止することがある。maxTokens 設定を上げるか、タスクを分割して渡すことで対応できます

SIerの現場でも「古い機能の削除」「廃止予定のAPIエンドポイント撤去」といった作業は頻繁に発生します。業務でのAI活用を検討しているエンジニアへ伝えたいのは、削除対象を人間が先に整理して渡すことができれば、実装作業自体はAIに委任できるということです。逆に言えば、何を消すべきかを判断する設計力・影響範囲の把握能力は、引き続き人間側に求められます。AIはあくまで「決まった仕様を正確に実行する」ツールとして使うのが、現時点での現実的な使い方です。