はじめに

ここ数年でAIコーディングツールは急速に進化し、開発現場での役割も大きく変わってきています。本記事では、これまでのAI活用の変遷を振り返りつつ、「AIが自律的にコーディングを行う」開発体制を実現するためのアイデアと、それを支える技術・ルールについて紹介します。

これまでのAIの使い方

2025年頃：人間主体、AIはサポート役

この頃のAIは、あくまで人間の開発をサポートする存在でした。

• GitHub Copilot のサジェスト機能でコード補完してもらう
• 分からないことをチャットで質問する

主役はあくまで人間で、AIは「気の利く補助ツール」という位置づけです。コードの大部分は人間が書いており、AIの提案を取捨選択しながら開発を進めていました。

2026年〜：AI主体、人間がサポート役

過去記事「AIエージェントを中心に据えた開発環境への移行」で紹介したように、Claude Code の活用が進んだことで主従関係が逆転しました。

• コーディングはAIが行い、人間は指示を出すだけ
• ISSUEを渡せば、実装からPR作成までAIが進めてくれる
• 複数のタスクを並列で走らせられるようになり、1スプリントあたりのISSUE消化量が2倍近くに増えた

人間は「コードを書く人」から「AIに指示を出し、成果物を確認する人」に変わりつつあります。

これから実現したいこと

次のステップとして目指しているのが、AIが自律的にコーディングを行う開発体制です。

イメージとしては、AIを1人のプログラマーとしてチームに迎え入れる感覚です。役割分担は次のように考えています。

工程	担当
設計	人間（AIがサポート）
コーディング	AI
コードレビュー	人間（AIがサポート）
結合テスト	人間（AIがサポート）

線引きの考え方はシンプルで、機械的に検証できる工程はAIに渡せる、実環境での判断や責任を伴う工程は人間に残す、という基準で工程を仕分けています。

人間が設計してISSUEを起票すると、AIがそれを拾って実装し、PRを作成する。人間はレビューと結合テストで品質を確認する。コーディング工程を丸ごとAIに任せることで、人間は設計や検証といった、より判断が求められる仕事に集中できます。

これまでの「人間がAIに指示を出しながら一緒にコーディングする」スタイルとの一番の違いは、コーディング中に人間が張り付いていなくてもよいことです。指示を出して結果を待つのではなく、ISSUEを起票した時点で人間の手を離れ、次に人間が関わるのはPRのレビューから。この間、人間は別の設計やレビューを進められますし、AIも複数のISSUEを並行して処理できます。

実現するための技術

スキルエンジニアリング

スキルエンジニアリングとは、チームの開発手順や暗黙知を「スキル」としてAIに教え込む取り組みです。

Claude Code にはスキルという仕組みがあり、定型化された手順をパッケージ化しておけます。人間が明示的に呼び出せるだけでなく、AIが「今のタスクに関係する」と判断すれば自律的に使ってくれるのが強力な点です。例えば次のようなスキルを整備しています。

• ISSUEに書かれた仕様を元に実装し、lintなどの静的解析ツール実行までを一気通貫で行うスキル
• 人間がPRに書き込んだ指摘を読み取り、修正するスキル

ポイントは、毎回プロンプトで細かく指示するのではなく、一度作り込んだ手順を何度でも再利用できることです。プロンプトの品質が人によってバラつく問題も、スキルとして標準化してしまえば解消できます。

人間のプログラマーに開発マニュアルを渡して教育するのと同じように、AIにもスキルという形で手順を渡す。スキルが充実するほど、AIは「指示待ち」ではなく「手順を知っている状態」で作業できるようになります。

ループエンジニアリング

ループエンジニアリングとは、AIが自分で結果を確認し、修正を繰り返せるフィードバックループを設計することです。

AIに自走してもらうには、「実装して終わり」ではなく「実装 → 単体テスト → 失敗したら修正 → 再テスト」というループを自力で回せる環境が必要です。具体的には次のような整備を進めています。

• 単体テストやlint、型チェックをコマンド一発で実行できるようにしておく
• 「単体テストが通るまで修正を繰り返す」という完了条件を明示して指示する
• レビュー指摘への対応も「修正 → 単体テスト → コミット」のループとして定義する

判定基準が機械的にチェックできる形になっていれば、AIは人間の介入なしにループを回し続けられます。逆にここが曖昧だと、AIは中途半端な状態で作業を終えてしまいます。

さらに一歩進めて、「ISSUEが起票されたらAIが自動で着手する」「レビューコメントが付いたら自動で修正に入る」といった、開発フロー全体を大きなループとして回す仕組みも構想しています。ここまでできれば、AIは本当の意味で「自走するプログラマー」になります。

コンテキストエンジニアリング

もうひとつ重要なのが、AIが判断に必要な情報へ迷わずたどり着ける状態を作ることです。

CLAUDE.md にプロジェクトのルールや構成を記述しておく、設計の背景をISSUEに残しておく、ドキュメントを最新に保つ。人間の新メンバーがオンボーディング資料で立ち上がるのと同じで、コンテキストが整理されているほどAIのアウトプットの精度は上がります。

ルール

技術だけでなく、運用ルールも重要です。AIに任せる範囲が広がるほど、「どこまで任せてよいか」「問題が起きたとき誰が責任を持つか」を明確にしておく必要があります。現時点で決めているルールを3つ紹介します。

人間がやること、AIがやることを守る

人間がやらないといけないことを、AIがやってはいけません。

設計・コードレビュー・結合テストは人間の担当です。もちろんAIにサポートしてもらうのは構いませんが、最終的な確認と判断は必ず人間が行う。この線引きを守ることで、システムの品質を担保します。

AIの出力をそのまま信じてマージしてしまうと、品質の責任の所在が曖昧になります。「AIが書いたコードでも、承認した人間が責任を持つ」という原則は崩さないようにしたいです。

開発環境を人間とAIで分ける

「AIがコーディング中だから人間が動作確認できない…」という事態を防ぎたいので、開発環境は人間とAIで分離します。

• Dockerでコンテナを分ける
• 作業ディレクトリを分ける（git worktree の活用など）
• 同じポートやDBをなるべく共有しない

AIを1人のプログラマーとして扱うなら、環境も1人分用意するのが自然な考え方です。人間のチームでも開発環境を取り合うことはないはずで、AIも例外ではありません。物理的にPCを分けてしまうのもアリかもしれません。

環境が分離されていれば、AIが多少大胆な変更を試しても人間の作業には影響しません。これは「AIに安心して任せられる範囲」を広げることにも繋がります。

GitHubのユーザーを分ける

次の理由から、人間の意思でコミット・PRを出したのか、AIが自律的にやったのかを判別できるようにしておくべきだと考えています。

• コミット履歴やPR一覧を見れば、AIの成果物だと一目で分かる
• ブランチ保護でレビューを必須にしている場合、自分のアカウントでAIが作ったPRは自分では承認できないが、ユーザーが分かれていればAIのPRを人間がレビュー・承認するフローが自然に成立する

これらを実現するために、AIのコミット・PRは GitHub App 経由で行うことを考えています。トレーサビリティの確保は、AIに権限を渡すうえでの大前提です。

おわりに

この構想を実現して、より迅速かつ品質の高いサービスを提供していく所存です。

「AIに任せる範囲を広げること」と「人間が品質を担保すること」は、ルールと仕組みさえ整えれば両立できるはずです。これからも目まぐるしく発展するAIに乗り遅れないようにしたいですね。