■ 1. 背景と目的
- 実装以外のボトルネック:
- AIにコードを書かせると実装は速くなるが、開発全体が速くなるとは限らない
- AIへの依頼には、タスク選定と資料・前提の収集が必要になる
- さらに実行結果の確認と次の作業の起動も必要になる
- これらに人間の手作業や待ち時間が残ると、実装速度が上がるほど実装以外の部分が詰まる
- 残っていた人間の介入:
- Skills、Rules、リポジトリ固有のコンテキストを整えたことで、AIによる実装は徐々に速くなっていた
- 一方、人間がセッションを立ち上げて指示しなければ作業は始まらない
- 同期的に会話しながら複数タスクを切り替えることにも限界がある
- AIに任せる範囲を広げるだけでなく、人間が見るべきものを絞る必要がある
- 自動化の狙い:
- Claude Codeのルーティンで実装タスクを定期的に進める仕組みを設計した
- 目的は人間を開発から外すことではない
- 繰り返し作業や待ち時間を減らし、人間が判断すべき仕事に集中できるようにすることが目的
■ 2. 仕組みの概要
- ルーティンの処理内容:
- 1時間ごとに実行される
- issue選定、コンテキスト収集、実装、セルフレビューを行う
- 続いてドラフトPR作成、AIレビュー、実行結果の報告までを行う
- セルフレビューとAIレビューの違い:
- セルフレビューは、実装したClaude Codeのセッション自身が変更内容を見直す工程
- AIレビューは、ドラフトPR作成後に別のAIがPRを確認する工程
- 無人実行の範囲の限定:
- 1回の実行で扱うissueを1件に絞る
- 対応方針が明確なissueだけを対象にする
- 人間に残す判断:
- 仕様やマージの判断は人間が行う
- 人間の判断が不要な箇所への介入を減らすことが自動化の目的
■ 3. 人間はタスクを完全には並列処理できない
- 作業情報の保持の限界:
- 人間が一度に意識して扱える作業情報には限りがある
- 1つのタスクでも、目的、優先度、変更箇所を保持する必要がある
- さらに制約や現在の進捗も保持する必要がある
- 複数タスクを抱えると情報量が急増し、すべてを同じ精度で保持し続けることは難しい
- 逐次処理になる実態:
- タスクAに取り組む間、タスクBやCは待ち状態になる
- 一区切りつけてから次のタスクへ注意と判断を切り替えて進める
- タスク切り替えは画面の切り替えではなく、注意を向ける対象の切り替えを伴う
- 並列に見えても、実際は切り替えながら1つずつ処理していることが多い
■ 4. 承認待ちの課題とAuto Mode
- 以前からあった承認待ち:
- Auto Mode以前は、ファイル編集やコマンド実行の前にClaude Codeが許可を求めていた
- 人間が確認して許可するまでAIも待ち状態になっていた
- --dangerously-skip-permissions:
- 権限確認を省略し、すべてのアクションを確認なしで実行させるオプション
- 安全性の問題が残るため解決策にならない
- 公式ドキュメントでも隔離されたコンテナや仮想マシンでの使用が推奨されている
- Auto Modeの仕組み:
- 現在のClaude CodeではAuto Modeがデフォルト
- 別モデルで構成された分類器がツール呼び出しを確認する
- 危険な操作や環境外への操作を検出すると、停止や安全な方法の選択を行う
- 必要に応じて人間に確認を求める
- 確認を無視するのではなく、AIのチェックを挟みつつ長く実行できるようにする仕組み
- Auto Modeの検出性能:
- Anthropicの検証では危険なコマンドの検出率を人間の手動確認と比較した
- 人間の手動確認は13.6%、Auto Modeは89%を検出したと報告されている
- セッション外側への発想の拡張:
- タスクの目的や実行してよい範囲が明確なら、人間がすべての操作に介入しなくてもAIに任せやすい
- この考え方をセッションの外側にも広げる
- issue選定、コンテキスト収集、セッション起動も条件を定めればAIに任せられると考えた
■ 5. 設計上の工夫
- 全体像:
- GitHubのissueを起点に、実装、ドラフトPR作成、レビュー、結果報告までを定期的に進める
- issueの選定条件の明確化:
- 定期実行ではissueの曖昧さをAIが勝手に補う可能性がある
- AssigneeやLabelなどの管理情報を、自動実行してよいissueの判定材料に使う
- 本文の自然言語だけに頼らず、機械的に確認できる条件を先に置いて対象範囲を狭くする
- 1回の実行で1 issueに限定:
- 候補が複数あっても、1回の実行で着手するのは1件だけ
- 無人実行では1つの判断ミスが複数の変更へ波及する
- 失敗と成功のissueが混ざると原因の確認が難しくなる
- 処理量は減るが、処理したissue、停止箇所、生成物を追いやすくなる
- 扱う背景や関連資料も抑えられ、AIが参照すべき情報を絞りやすくなる
- 処理量の最大化より、コンテキストを広げすぎず失敗時に戻しやすいことを優先した
- 複数リポジトリ横断のコンテキスト収集:
- issue本文には目的、対応範囲、完了条件を記載しているが、実装に必要な情報が足りないことがある
- 担当案件では実装に必要な情報が複数リポジトリに分散している
- 参照先が限られるとコンテキスト不足で精度が落ちる
- 各リポジトリの役割や参照先をまとめたリポジトリを用意し、収集の最初に参照させる
■ 6. 運用結果と今後の考え方
- 運用の成果:
- 人間がセッション起動や進捗確認をしなくても、手が離れている時間に実装が進むようになった
- 実装の待ち時間や次の作業を起動する手間が減った
- 人間は仕様確認や成果物レビューなど、判断が必要な作業に集中しやすくなった
- 仕様が顧客業務に合うか、画面が使いやすいかなど、顧客価値に直結する確認に時間を充てやすくなった
- 開発フロー全体の設計:
- 実装時間が短くなったからこそ、周辺に残る作業や待ち時間を減らし開発フロー全体を整えたい
- AIにコードを書かせるだけでなく、AIが継続的に作業できるフローを設計することが重要