AIを使って開発をする、という話自体はもう珍しくなくなりました。
実装を補助してもらったり、コードを書いてもらったりすることも、今では当たり前になりつつあります。
一方で、使い続ける中でふと立ち止まる瞬間がありました。「これは本当に“任せていい”判断なのか？」「今、何が起きているのかを、私は説明できるだろうか？」
私は SE / PM としての経験は長いものの、プログラミングを主戦場としてきたわけではありません。
だからこそ、AIに実装を任せること自体には早い段階から可能性を感じていましたが、同時に 判断まで委ねてしまうことへの違和感 も強く残っていました。
試行錯誤の末に辿り着いたのが、AIを「便利なツール」としてではなく、 役割を持った「チームメンバー」として扱う という考え方です。
この記事では、なぜその考え方に落ち着いたのか、どんな失敗があり、何を手放し、何を手放さなかったのか、という 背景や判断の話 を中心に書いていきます。
なお、実際の構成や設定ファイル、Kiro / Claude Code / Codex をどう役割分担しているかといった 技術的な詳細 については、別途 Qiita にまとめています。
試行錯誤のはじまり
最初に使い始めたのは、VS Code の GitHub Copilot でした。
コード補完の精度は高く、実装スピードは確実に上がりましたが、それはあくまで 「実装効率を上げるツール」 という位置づけでした。
次に Claude Code が登場したとき、正直なところ少し期待しすぎていました。「設計をしっかり作れば、実装はほぼ任せられるのではないか」と。
実際、Claude Code の実装力は高く、新規機能の追加やリファクタリングもこなしてくれます。しかし、プロジェクトが大きくなるにつれて、別の問題が見えてきました。
それは、全体を見渡す視点が持続しない ということです。
目の前のタスクには真面目に取り組む一方で、前提条件や影響範囲が少しずつ抜け落ちていく。結果として、局所的には正しそうに見える修正を何度も積み重ねることになりました。
この状態は、「AIが悪い」というよりも、 私の使い方が曖昧だった のだと思います。
「どこまで任せていいのか」「どこから先は人が判断すべきなのか」が、明確に定義されていなかったのです。
役割を分けるという発想
そこで大きく意識を変えました。
AIに「できること」を期待するのではなく、 「役割」を与える という考え方です。
実装は実装担当に、仕様の整合性は仕様管理に、デバッグは事実ベースで切り分ける担当に、それぞれが得意なことに専念できるようにし、判断が必要な場面では、必ず人に戻す。
この前提ができてから、開発中に感じる不安や違和感は、明らかに減っていきました。
Codex を入れて感じた「安心感」
それでも、どうしても不安が残る場面がありました。 それは、リファクタリング後のテストで、 理由のはっきりしないエラーが続いたとき です。
Claude Code は仮説を立て、修正を提案し、前に進もうとします。その姿勢自体は悪くありません。ただ、ある時点から私は、「今、何が起きているのかを自分が把握できていない」という感覚を持つようになりました。
エラーは減ったり増えたりを繰り返し、修正の意図と結果が少しずつズレていく。
この状態が続くと、 直っているのか、たまたま通っているのか が分からなくなります。
そこで試しに導入したのが Codex でした。
Codex に期待したのは、「賢い修正案」ではありません。
今何が起きているかを、事実として整理してもらうこと でした。
私がターミナルでテストを実行し、そのログを Codex に渡す。
Codex は、それを 箇条書きで整理 します。
- どのテストが失敗しているか
- どの変更が影響していそうか
- 未使用の変数や処理はどこか
- 安全に削除できそうなものは何か
この「見える化」によって、私の中で一気に状況が整理されました。
修正は Codex に任せつつ、私は 判断だけを行う 。
必要であれば、もう一度テストを回し、その結果をまた Codex に渡す。
このやり取りを繰り返すうちに、エラーはすべて解消され、仕様書どおりの動作が確認できました。
何より大きかったのは、 「なぜ直ったのか」を説明できる状態 に戻れたことです。
このとき初めて、「AIをチームに入れても大丈夫だ」という安心感を持てた気がします。
あえてやらないこと
ここまで書いてきて、私がやっていることは決して特別なことではないと感じています。
AIにすべてを任せるわけでもなく、AIを疑い続けるわけでもない。ただ、人と同じように役割を分けただけです。
同時に、あえてやらないことも明確にしました。
- AIに最終判断を委ねない
- 「なんとなく直った」を良しとしない
- 説明できない修正を放置しない
これらを守ることで、AIと一緒に開発することへの不安は、少しずつ安心感に変わっていきました。
おわりに
現在は、Kiro、Claude Code、Codex をそれぞれ「チームメンバー」として扱いながら、開発を進めています。
このやり方が常に正解だとは思っていません。
ただ、 自分が納得できる形で開発を続けられる という点では、今のところ一番しっくり来ています。
この記事では考え方や判断の背景を中心に書きましたが、実際の構成や設定ファイル、
AIそれぞれの役割定義については、 Qiita に技術記事としてまとめています。
👉 Kiro × Claude Code × Codex —— AIを「チーム」として扱う開発スタイルの実践
https://qiita.com/miyakawa2449@github/items/672101d83066db0a8b3b
また、この記事で触れた内容を
そのまま試せる サンプルプロジェクト も GitHub で公開しています。
👉 https://github.com/miyakawa2449/ai-team-dev-sample
同じように、「AIに任せたいけれど、判断は手放したくない」と感じている方の参考になれば幸いです。
