アーティスト・クリエイターの廣川政樹です。普段は壁紙や癒し系の iOS アプリを個人で運用していて、累計5,000万ダウンロードを超えたあたりから「コードベースに少しずつ溜まった Xcode 警告」をどう片付けるかが頭の片隅で気になり続けていました。深刻なバグではない。けれど、ビルドのたびに 300 を超える警告が流れていく状態は、設計者としての自分が一番落ち着かない景色でした。
両家の祖父が宮大工だったこともあり、「組み上げたものが何十年も歪まないかどうか」は私にとって大事な感覚です。コードに残った警告は、組み上げの精度がほんの少しずつズレている合図のように感じます。そこで2026年の春、Claude Code をスプリントの相棒として4週間だけ警告ゼロを目指すという、小さな自分プロジェクトを走らせました。本記事はその記録です。
4週間スプリントを始める前に決めたこと
最初に決めたのは「警告ゼロを達成する」ではなく「警告ゼロを保てる運用に切り替える」ことを目的にする、という線引きでした。期間中に新しい機能は入れない。ライブラリのメジャーアップデートも追わない。やるのは、ビルドログに出る警告のうち、修正可能なものを順番に減らす作業だけです。
スコープを固定すると、Claude Code に渡すコンテキストも自然と絞れます。私の場合は対象アプリを3本に絞り、それぞれのスキームでビルドした際の警告ログを xcodebuild の -quiet を外した状態でテキストに落とし、Claude Code の作業ルートに置きました。最初の claude セッションでは、このログを読み込んだうえで「警告を意味別に分類し、対処コスト順にラベルを付けてください」と頼みました。
返ってきたのは、Deprecation 系・Unused 系・型推論で曖昧になっている箇所・@available の境界が古いままになっている箇所、といった4つのカテゴリ分けでした。これだけでも、自分一人で漠然と眺めていたときよりも作業順序が明確になり、最初の30分で頭が整理されました。
週ごとの方針：機械的に潰せる警告から削る
Week 1 は Unused 系と未使用 import の整理だけに絞りました。Claude Code に「Xcode の Unused Variable 警告のみを対象に、影響範囲を変えずに削除案を提示してください」と指示し、提案された差分を1つずつ git ブランチに分けて受け入れていきます。ここで大事だったのは「複数の警告を一度に潰そうとしない」ことです。1コミットあたり1カテゴリ・1領域に揃えると、テスト失敗時の切り戻しが格段に楽になりました。
Week 2 は Deprecation 警告でした。UIApplication.shared.statusBarOrientation のように iOS 13 で deprecated になっていながら、しれっと残っていた箇所が私のコードベースには思いのほか多かったです。Claude Code には API ごとに置き換え方針を提示してもらい、私が iPad の景観切り替え挙動だけは自分の目で確認する、という分担にしました。Sequoia 対応で増えた UIScene 周りの新しい API も、ここでまとめて整理しました。
Week 3 は型推論で曖昧になっている箇所と、@MainActor の付け忘れ系。これは Claude Code 単体に任せると過剰修正になりやすい領域です。私は「変更案を提示してから、ビルドが通る最小修正のみを採用する」運用に切り替えました。Swift 6 の strict concurrency をオンにする前段としては、ここを通っておくと後が楽です。
Week 4 は残った @available の境界更新と、サードパーティ依存に由来する警告の追跡。後者は自分のコードでは直せないものも多いため、Claude Code に「対処不可な警告は理由付きでドキュメント化してください」と頼みました。出力された Markdown を _docs/known-warnings.md として残し、ビルド設定で抑制ルールを書く判断基準にしています。
Claude Code に任せた領域と人間が残した境界
4週間を通じて、私の中で「ここは Claude Code、ここは自分」というラインがはっきりしてきました。任せたのは、影響範囲が局所的で、git の差分を読めば判断できる修正です。たとえば未使用変数の削除、API のシグネチャ変更だけで済む差し替え、@available のバージョンを揃える整理。こうした作業は私が手を動かしても楽しくない種類のもので、Claude Code に任せると速度も精度も上がりました。
逆に手放さなかったのは、「ユーザーの体感に効く挙動」が絡む変更です。ウィジェットの背景処理、スクロールの慣性、ハプティクスの強弱、画像読み込みのタイミング。このあたりは警告ゼロのためであっても私が一度自分の指で触ってから判断するようにしました。個人開発で長く運用してきたアプリほど、ユーザーが「いつもの感じ」を覚えていて、論理的には正しい修正がユーザー体験を地味に削ることがあります。
もう一つ手放さなかったのは「警告を意図的に残す」判断です。サードパーティ SDK の都合で消せないもの、互換性のために残してある旧コード、ABテスト用に意図的に並走させているコード。これらは Claude Code が積極的に直したがる領域ですが、私の判断として残す場合は // swiftlint:disable ではなく、理由を書いた // MARK: コメントで残すルールにしました。
つまずきと回避策
最初の壁は「Claude Code が一度に多くを直そうとする」傾向でした。これは指示の粒度を細かくすれば落ち着きます。私は「対象ファイルを1つに絞る」「対象警告のカテゴリを1つに絞る」「1コミットの差分量を 200 行以内に収める」という3つの制約を毎回プロンプトに書き添えるようにしました。
次の壁は「ビルド成功を Claude Code 自身に確認させる」設計でした。xcodebuild を Claude Code 経由で叩くと、警告ログが長すぎて要約に時間がかかります。そこで xcodebuild ... | tee build.log でログをファイルに残し、Claude Code には「build.log の末尾 500 行だけ読んで判定してください」と渡すフローに変えました。これで応答が速くなり、レビューのテンポも上がりました。
最後の壁は「自分のレビュー疲れ」でした。Claude Code が早いぶん、私のレビューが追いつかなくなる場面が何度かありました。これは Week 3 の途中で気づき、1日に受け入れる差分量に上限を設けることで解消しました。スプリントとはいえ、無理に進めても警告が新たな技術的負債を生むので、テンポは大事だと感じました。
数値で振り返る効果
開始前の警告数は3本のアプリ合計で 312 件、4週間後の警告数は 6 件。残った 6 件はサードパーティ SDK 由来のもので、すべて known-warnings.md に理由付きで記録されています。コミット数は約 90、そのうち Claude Code が下書きを作って私がレビューして取り込んだものが約 75 を占めました。
体感としていちばん大きかったのは、ビルドログを開く心理的な抵抗が消えたことです。これまでは「警告 300」というバッジを見るたびに、無意識にビルドログを閉じていました。それが日々の改善判断の精度を地味に削っていたのだと、ゼロになって初めて気づきました。AdMob の表示遅延を疑うときも、Firebase の初期化順序を見直すときも、警告がないビルドログのほうが原因を絞り込みやすいです。
このスプリント中に新しく入れた警告は 0 件です。Claude Code が下書きを作る段階で「新しい警告を増やさない」を制約として書いておくと、提案がだいぶ守ってくれる体感でした。コードベースの規模が大きい個人開発者にとって、警告ゼロを「達成する」より「保てる運用に切り替える」ほうがずっと意味があると、4週間を通して再確認しました。
これから取り組むこと
次の4週間では、Swift 6 の strict concurrency オプションを段階的に有効化し、Sendable 違反を Claude Code と一緒に潰していく予定です。現状のコードベースで一気に有効化すると数百件の警告が再発するので、まずはターゲットを1本ずつ、@preconcurrency の境界を引きながら進めるつもりです。
同じ時期に、リリース時の xcodebuild ログを Claude Code が自動で要約して _docs/known-warnings.md を更新する仕組みも整えたいと考えています。警告ゼロを「保つ運用」を仕組みに落とし込めれば、私が他の制作に時間を回せます。1997年に独学で始めたプログラミングが、いまは別の作業に時間を空けるための足場になっている。そう感じられる4週間でした。同じように長く運用してきたコードベースを持つ方の参考になれば嬉しいです。