AI にコードを書かせることと、本番を触らせることは違う

Posted at 2026-09-30

はじめに

AI にアイデアを出してもらったり、コードを書いてもらったりすることには、かなり慣れてきました。一方で、AI が提案を出すだけでなく、実際に何かを変更・実行するところまで任せることには、まだ抵抗があります。

AI を「Copilot」、つまり副操縦士として使う。壁打ちをしたり、文章やコードのたたき台を作ってもらったりするのは、とても便利です。考えを広げる相手として、AI は頼もしい存在になりました。

それでも、生成物を人間が確認することと、AI に本番環境で操作させることは、同じ「AI を使う」でも別の話です。操縦桿を握り、進む方向を決めるのは人間でありたい。その境界について考えてみます。

たとえば、スライドを作るために構成案を出してもらう。新しい機能の案を一緒に考えてもらう。コードの書き始めを手伝ってもらう。

こうした場面では、AI の出力は完成品というより、考え始めるための材料です。何もないところから考えるより、目の前に案があるほうが「ここは違う」「この順番のほうが伝わる」と判断しやすくなります。

実際、出てきた構成案を見ていると、少し違う味を加えたくなることがあります。自分が本当に伝えたいことに合わせて順番を変えたり、余計な項目を削ったりする。AI の案をきっかけにして、自分の考えがはっきりすることもあります。

大切なのは、出力を鵜呑みにしないことです。AI が作ったものをそのまま採用するのではなく、たたき台として受け取り、目的に合わせて人間が手を入れる。その工程にこそ、作り手の判断が表れるのだと思います。

コード生成なら、提案されたコードを読み、動かし、テストし、レビューしてから取り込むという段階があります。気に入らなければ書き直せますし、採用しない選択もできます。生成されたものが、そのまま利用者へ届くとは限りません。

一方で、本番環境への変更は、案を作るだけではなく、実際のシステムや利用者に影響を起こす操作です。実行したあとに元へ戻せるとしても、変更が適用されている間に誰かが影響を受けるかもしれません。取り消せることと、影響がなかったことになるのは同じではありません。

たとえば、スライドの構成案を作ってもらうことと、その内容を確認せずに公開すること。コードを書いてもらうことと、そのコードを本番へ反映すること。どちらも後者では、生成物の良し悪しだけでなく、実行によって生じる影響を考える必要があります。

これは、AI に能力がないと言いたいわけではありません。むしろ、できることが増えるほど、「生成してよい範囲」と「実行してよい範囲」を分けて考える必要があると感じています。

「人間が確認する」と言うのは簡単ですが、ただ形式的に承認ボタンを押すだけでは意味がありません。どこを変えるのか、なぜ変えるのか、失敗したらどうするのかを理解して、実行してよいと判断することが必要です。

そのためには、何をしようとしているのか、影響する範囲はどこか、必要ならどう止めたり戻したりするのかが分かる状態でなければなりません。人間が関わるなら、判断に必要な情報と、その判断を実行に反映できる仕組みも必要です。

もちろん、すべての操作を人間が手作業で行うべきだと言いたいわけではありません。安全な範囲で自動化することには価値があります。ただ、本番環境を変える最後の判断まで、確認なしに AI へ渡すことには慎重でありたいです。

AI の提案をすべて疑って何も任せないのでもなく、出力をそのまま信じて任せきるのでもない。提案を受け取り、確かめ、自分の意図に合う形へ整えてから使う。そのバランスを取りたいと思っています。

AI は、考えるための相手にも、ものづくりを進めるための道具にもなります。壁打ちや案出し、コードのたたき台づくりを頼りながら、出てきたものを自分の目で見て、よりよい形にしていく。私はそんな使い方が好きです。

一方で、本番環境への変更のように、人に影響する操作では、最後の判断を人間が引き受けたいです。AI がコードを書けることと、本番環境へ反映してよいことは別だからです。

副操縦士に任せられる仕事は、これからもっと増えるでしょう。それでも、どこへ向かうのかを決め、本番へ進む最後の操作を判断するのは人間でいたい。AI と一緒にものを作るとき、私はその境界を忘れないようにしたいです。