AIで開発を回す仕組み（Claude Code・Codex）

導入前の課題・業務フロー

AIにコードを書かせるだけでは、任せる範囲や完了条件、人が判断する場面が曖昧になります。業務システムを継続的に開発・運用するために、目的と設計を残し、変更を確認してから取り込む流れと、秘密情報や本番データを守る決まりが必要でした。

実施内容

人がIssueに目的・対応範囲・受け入れ条件を書き、AIに渡す開発ルールと、作業ごとの専用の作業場所を整えました。対話での設計相談・実装に加え、2026年9月には承認済みのIssueを扱う自動ランナーを導入しました。開発ルール、Claude Codeの設定、Issueの書き方、ランナーの状態と確認内容、差分レビューの観点を一般化し、公開リポジトリで見本として共有しています。

事故を防ぐ決まり

• AIの実行環境には認証情報を渡さず、コミットとPR作成はランナー側で行う。
• 公開前に秘密情報の形式を検査する。
• DBのマイグレーションや依存関係の変更は自動でマージしない。
• PR作成時と承認時のコミットが一致するときだけマージし、後から追加されたコミットは自動で取り込まない。
• ロックと状態ラベルで二重着手を防ぎ、作業ごとの専用の作業場所で主の作業場所を汚さない。
• 試作段階でも二重送信・データ消失の防止、秘密情報の保護、既存動作の維持を省略しない。

導入後の変化・成果

公開リポジトリのREADMEでは、社内向け業務システムの2026年7月29日〜9月28日（約2か月）の記録として、コミット733件、マージしたPR（変更案）212件、Issue（課題）93件を公表しています。同じ仕組みをほかに2つのプロジェクトでも運用しています。お客様への導入実績や、時間・費用の削減効果を示す数字ではありません。

成果の確認条件・根拠：件数の出典は公開リポジトリ「ai-dev-workflow」のREADME（2026年10月12日確認、Issue #452に司令部が転記）。対象期間は2026年7月29日〜9月28日です。今回は履歴を再集計しておらず、各件数の詳しい集計方法や導入前後の比較は確認していません。

使っている仕組み

Claude Code、Codex、Issue・PR、自動ランナー。対話での開発と、承認済みの作業を進める自動化を組み合わせています。

AIと人の役割

導入時に苦労した点

• レビューでは変更箇所だけでなく、保存と読み込みなど対になる処理も洗い出す必要がありました。
• 既存の動作を断定する前に確かめ、指摘がなくなるまで修正とレビューを繰り返すことが、確認の工夫として記録されています。

導入後に分かったこと

• テストは、修正を戻すと失敗することも確かめ、変更によって守れた動作を確認します。
• 設計はIssueに残し、既存テストを理由なく消さず、コメントには処理の説明よりも理由や制約を残します。
• AIに任せる作業だけでなく、判断が必要なら止める条件と、人が承認する場面を決めておきます。

同様の取り組みが向いている条件

• 継続的な開発を小さな作業に分け、目的・対応範囲・受け入れ条件をIssueに書ける取り組み。
• AIの変更案と確認結果を人が読み、外部送信や本番データの扱いを判断できる体制。
• 作業場所と認証情報を分離し、レビューや公開前の検査を開発の流れに組み込めるプロジェクト。

補足

自社での開発記録と公開している見本を紹介する事例です。向いている条件は、記録にある進め方から整理したもので、同じ件数や効果を保証しません。自社サイトの運営体制や運営中の停止例は、関連する「AIチームで自社サイトを開発・運営」の事例で紹介しています。