こんにちは！iimonでエンジニアをしている なかむ です。 普段は主に「入力速いもん」の拡張機能を開発しています！
今日は 「Claude Code Routinesで技術負債の修正をどこまでAIに任せられるか」 という検証について、現時点での計画とこれから何を試すかを共有します。
検証環境（2026年5月時点）
Model: Claude Opus 4.7 Plan: Claude Pro Plan
なぜこのテーマを選んだか
背景1：技術負債をNotion → GitHub Issueに移行した話
最近、Notionで管理していた技術負債リストをGitHub Issueに移行しました。
自チームではPMからもらうタスクはセールス側と共有する都合で、すべてNotionで管理しています。そのため、技術負債も慣例通りにNotionで記載していました。 しかし、エンジニア側で把握できていれば良い技術負債については、Notionで管理する必要がないということに気づきました。 また、GitHub Issueのほうが起票が楽で、Notionだとツールを切り替える手間があり、技術負債を見つけてもスルーされている状態でした。
少しの手間といえど、忙しいときには後回しにしたいと思うのは誰しも経験のあることだと思います。
CI/CDだけでなく、そういう 人間の認知的な負荷も実は技術負債の背景にある のではないか、ということに気づきました。
そこで、「きれいなコードになりやすい環境を整える」 ことを目指してみようと思いました。
背景2：他チームのIssue駆動開発を見て
社内のあるチームでIssue駆動開発をしていて、そこでは 「Issueを立てる → ローカルのClaude Codeに修正させる」 というループを作っていました。
ただ、ローカル実行だと
- 自分のPCを開いていないと動かない
- 実行中はそのClaude Codeセッションを占有する
- 他の作業と並行しづらい
という制約があって、もう一歩踏み込めないかなと考えていました。
そもそもClaude Code Routinesとは
そんなとき、タイミングよくX（旧 Twitter）でClaude Code Routinesという定期的に自動実行してくれる機能について知りました。
Claude Code Routinesについて、公式ブログの定義をそのまま引きます。
A routine is a Claude Code automation you configure once — including a prompt, repo, and connectors — and then run on a schedule, from an API call, or in response to an event. （公式ブログより）
ポイント：
- プロンプト + リポジトリ + コネクタ を一度設定すれば、スケジュール / API / GitHubイベント をトリガーにクラウドで自動実行される
- ローカルの
/loopと違って PCを閉じても動き続ける - リサーチプレビューとして公開されており、Pro / Max / Team / Enterpriseで利用可能（2026年5月時点の情報です。最新情報は公式ドキュメントをご確認ください。 ）
今回のスコープ
現在のチームの状況として、すでに多くの技術負債Issueが溜まっている状態です。そのため、今回のスコープでは 既存Issueの自動解消 にフォーカスします。 AIを起点に、修正すべき技術負債を網羅的に拾わせることも考えましたが、手つかずのIssueがどんどん溜まっていくこと自体が認知負荷につながると考えたためです。
またこの記事では 計画まで に留めます。実運用の結果は次回以降の勉強会で共有します。
具体的な進め方
1. 評価Skillを作成する
- AIが既存Issueに難易度ラベル（difficult / medium / easy）を付ける
- 修正案を計画する
2. 評価Skillを既存のIssueに適用する
3. 修正Skillを作成する
- AIが easy ラベルから修正PRを生成できるようにする
4. 修正SkillをRoutine化する
既存のIssueの起票のされ方
/tech-debt というSkillを作成し、メンバーにはそれを使用してIssueを立ててもらうようお願いしています。
/tech-debt では以下のように記載しています。
/tech-debt Skill の内容（クリックで展開）
--- name: tech-debt description: | 技術負債issueを素早く起票する。以下のようなリクエストで発動: - 「この技術負債をissueにして」「〇〇が気になるからissue作って」など自然言語 - /tech-debt コマンドによる明示的な起動 PRレビュー中やコード調査中に気づいた技術負債を、手軽にGitHub Issueとして記録する。 user-invocable: true argument-hint: '<技術負債の説明>' allowed-tools: - Read - Grep - Glob - Bash(gh issue create:*) - Bash(gh issue list:*) - Bash(gh issue view:*) - Bash(git log:*) - Bash(git blame:*) - AskUserQuestion --- # Tech Debt Issue Creator 技術負債をGitHub Issueとして素早く起票するスキルです。 ## 入力 ユーザーからの入力: `$ARGUMENTS` ## 実行フロー ### Step 1: テンプレートの読み込み まず `.github/ISSUE_TEMPLATE/tech-debt.md` を読み込み、issueの本文フォーマットを把握する。 ### Step 2: 入力の解析 `$ARGUMENTS` から以下を推測する: - **タイトル**: 簡潔な日本語タイトル - **カテゴリ**: bug-suspect / refactor / test / その他（tech-debtのみ） - **優先度**: 内容の重要度から5段階で判断（判断できない場合はユーザーに確認） ### Step 3: 関連コードの調査 入力に具体的なファイル名・クラス名・関数名が含まれる場合: 1. Grep/Globで該当コードを特定 2. 影響範囲を簡潔に把握 3. 対象ファイル/モジュールをリストアップ 具体的なコード指定がない場合はスキップする。 ### Step 4: 重複チェック ```bash gh issue list --label tech-debt --state open --limit 100 ``` 類似のissueが既にないか確認する。重複の可能性がある場合はユーザーに報告し、続行するか確認する。 ### Step 5: ユーザー確認（必須） **issueを作成する前に、必ず以下の内容をユーザーに提示して確認を取ること。確認なしでの起票は禁止。** 提示する内容: - タイトル - ラベル（カテゴリ + 優先度） - 本文（テンプレートに沿った内容） ユーザーから承認を得てから次のステップに進む。修正の指示があれば反映する。 ### Step 6: Issue起票 ユーザーの承認後、issueを作成する。 ### Step 7: 結果報告 起票したissueのURLと内容を簡潔に報告する。 ## ラベル一覧 ### カテゴリラベル | ラベル | 用途 | | ------------- | ---------------------- | | `bug-suspect` | バグ疑い（調査が必要） | | `refactor` | リファクタリング | | `test` | テスト関連 | ### 優先度ラベル（5段階） 内容の重要度・緊急度に応じて適切なレベルを選択する。 | ラベル | 重要度 | 判断基準 | | ---------------------- | ------ | ---------------------------------- | | `priority: 💎💎💎💎💎` | 最高 | バグ疑い・本番影響あり・即対応検討 | | `priority: 💎💎💎💎` | 高 | 重要な改善・品質に直結 | | `priority: 💎💎💎` | 中 | 計画的に対応すべき | | `priority: 💎💎` | 低 | 余裕があれば対応 | | `priority: 💎` | 最低 | 保留・いつかやりたい | ## 注意事項 - **Issue作成前のユーザー確認は絶対にスキップしないこと** - 優先度が不明な場合は必ずユーザーに確認する - カテゴリが複数該当する場合は最も適切な1つを選ぶ - 発見日は当日の日付を使用する
下の写真のように、優先度は5段階で付けています。
ただし、難易度は修正方針が固まってからでないと判断できないため、この段階では難易度ラベルは付けていません。
以下の写真は /tech-debt を使用して作成されたIssueの例です。
なぜこの方法を選んだか
なぜ評価層が必要か
着手するIssueの優先順位付けのためです。
優先度は /tech-debt の段階で付与されていますが、AIに修正させるにあたっては、【難易度easy】から徐々に直させていく ことで、可能な限り人の介在を減らして修正を進めていきたいと考えました。
また、ドメイン知識やビジネスロジックが絡む 【難易度difficult】 はローカルで同期的に計画を壁打ちしてからリモートに上げたほうが、計画の差し戻しの手間が減ると考えています。
機械的な修正に人が時間を割く割合が少しでも減れば、当初の目的（人間の認知負荷を減らす環境作り）の達成に繋がります。
なぜ評価層と修正層を分けたか
PMとエンジニア、Skill、コードがそうであるように、責務は独立したほうが連携しやすい と考えたためです。
なぜ評価層と計画層を分けていないのか
まだお試し段階のためです。 複数のSkillを作るとそれだけ扱うのに考えることが増えます。評価と計画は修正よりも似た責務を持つので、今回は分けずに運用し、必要があれば後から対応しようと考えています。
複雑な変更は「まず計画させる → 計画をレビュー → 実行させる」という流れになります。 これはClaude Codeを対話的に使うときと同じ流れなので、特別なものではありません。
単純な修正であっても、AIに計画を立てさせる段階を挟むことで、「コード生成 → 取り消し → 再指示」の手戻りを減らせます。
どのように難易度を評価するか
難易度は、以下の観点でAIに判断させる方針です：
- 影響範囲：周辺コードへの変更波及がどの程度あるか
- テストカバレッジ：対象モジュールのカバレッジが75%以上あるか（リグレッション検知の信頼性）
- 判断要素の種類：機械的に判断可能な変更か、ドメイン知識やビジネスロジックの解釈が必要か
これらを総合して、以下のようにマッピングします：
| 難易度 | 判定基準 |
|---|---|
easy |
影響範囲が局所的かつ、機械的に判断可能な修正（型修正、未使用コード削除、リネーム等） |
medium |
複数ファイルにまたがるが、機械的判断で対応可能な修正 |
difficult |
ドメイン知識やビジネスロジックの判断を要する修正 |
Issue修正Routineの設計方針
着手順序
AIが人間の手を借りずに修正でき、かつコードへの影響が低いもの（easyラベル）から着手させます。
人間のレビューをボトルネックとして受け入れる
人間によるレビューがボトルネックになることは、現時点では避けられないと考えています。 そのため、まずは負荷を減らす方向で設計します。具体的には、AIだけで生成したPRを人間がレビューしてマージする実績 を、easyラベルから積み上げていきます。
既存Issue優先のスタンス
AIで新規Issueを大量に起票することは技術的には可能ですが、継続可能な形でチームに導入することを考えると、Issueが膨大になる認知負荷 は無視できません。 そのため、まずは既存Issueの修正から始める方針です。
次回の勉強会までに検証すること
評価Skillの作成
確認すること
- タスクの修正難易度が適切か
- 出した修正計画がどのくらいの精度かフィードバックを行う
実は今一番頭を悩ませているのが、この「評価の基準」です。 AIに任せきりにすると、人間から見れば「これ、ロジックに深く関わるから危ないな」と思うものでも、AIが「変更行数が少ないからeasy！」と判断してしまうリスクがあります。 そのため、単なる行数やファイル数だけでなく、テストの有無やビジネスロジックの依存度をどう数値化してAIに伝えればいいか、試行錯誤している最中です。
AI修正Routineの稼働
- AI修正Routineを週1で走らせる
- PR作成までAI、マージは人間ゲート
測ること
- PR採用率（マージ / 全PR）
- レビュー所要時間
- リジェクト理由の分類
リジェクト理由の分類があると、「何を改善すれば精度が上がるか」が定量的に見えるようになるはずです。
結果は次回以降の勉強会で共有します！
まとめ
技術負債を「気合で消す」のではなく、「溜まりにくく・直しやすい環境を整える」 ことを起点に、Claude Code Routinesでどこまで自動化できるかを検証していきます。
この記事を読んで少しでも興味を持ってくださった方がいらっしゃいましたら、ぜひカジュアルにお話させていただきたいので、ご応募いただけると嬉しいです！
iimon採用サイト / Wantedly / Green
