AIに開発を任せるときの線引き｜調査・実装・検証は任せて、判断と確認は手元に残す

AIに開発を手伝ってもらうのは、もう特別なことではなくなりました。エラーの原因を探す、公式ドキュメントを読む、テストを書く。こうした作業は、AIに任せると驚くほど速く進みます。一方で、任せる範囲を決めないまま使うと、間違った判断がそのまま本番に出ることもあります。この記事では、AIに任せてよいことと、手元に残すべきことの線引きを整理します。

この記事は、筆者が開発や技術記事の執筆でAIを使ってきた経験をもとにした考え方の整理です。特定の製品の使い方の解説ではありません。

結論：任せるのは「手数」、残すのは「判断」と「確認」

先に結論です。

AIに任せてよいのは、調査・実装・検証の手数です。
手元に残すべきなのは、判断と、公開・本番反映の前の確認です。
AIの出力は、時間がたつと古くなり、ときに条件を省いて言い切ります。根拠を一緒に出させ、公式ドキュメントや実際の動作で確かめる習慣が必要です。

前提：ここでいう「AIに任せる」とは

この記事で扱うのは、チャットでAIに指示を出しながら、調査・コードの修正・コマンドの実行・結果の確認まで進めてもらう使い方です。AIは手を動かせますが、何を目的にするか、結果を受け入れるかどうかは人が決めます。

任せやすいこと

1. エラーの原因の切り分け

エラーメッセージを読み、仮説を立て、1つずつ潰していく作業はAIの得意分野です。たとえば「設定ファイルが読み込まれているか」を確かめるために、わざと全リクエストを止めるコードを入れて確認する、といった手順を素早く組めます。

ポイントは、推測ではなく再現で確かめさせることです。手元で実際にビルドして動かすと、ドキュメントを読んだだけでは分からない挙動が見つかることがあります。

2. 公式仕様の確認と、代替案の比較

「この仕様はどうなっているか」「ほかにどんな方法があるか」を調べて並べる作業も任せやすいです。たとえば、ある操作が別の処理を起動しない理由を公式ドキュメントで確認し、回避方法を複数挙げて、それぞれの利点と注意点を比べるところまではAIに進めてもらえます。

関連：GitHub Actionsのbotがpushしてもデプロイが動かない理由

3. 定型作業

テストの追加、依存パッケージの更新、データの形式変換など、やることが決まっていて、結果を機械的に確かめられる作業は任せやすい代表です。型チェックやテストが通るかをAI自身に確認させれば、手戻りも減ります。

手元に残すこと

1. 本番に影響する判断

依存パッケージのメジャーバージョンを上げるか、デプロイの権限をどこまで与えるか。こうした判断は、失敗したときの影響を引き受けるのが自分である以上、手元に残します。AIには選択肢と根拠を出してもらい、決めるのは人です。

関連：GitHub ActionsからCloud Runへキーレスデプロイ

2. 設計上のトレードオフを受け入れるかどうか

「この方式なら壊れにくいが、後からの修正が反映されない」のように、どちらを取っても何かを諦める設計があります。AIはトレードオフを説明できますが、どちらを諦めるかは、運用する人の事情で決まります。

3. セキュリティの最終判断

認証情報の置き場所、Cookieの送信範囲、外部サービスに何を渡すか。セキュリティに関わる設定は、一般論として正しいことと、自分の環境で安全なことが一致するとは限りません。AIに仕組みを説明してもらうのは有効ですが、最後の判断は自分で行います。

関連：サブドメインを外部サービスに向けるとき、Cookieはどこまで届くのか

AIの出力が古くなる・言い過ぎるときの見つけ方

古くなる：書いた時点で正しくても、数か月で危険になる

脆弱性の情報やバージョン番号は、コードを何も変えていなくても変わります。実際、ある記事のために「本番で使う依存のHIGHは0件」と確認した内容が、約2か月後には、使っていたNext.jsそのものにcriticalの脆弱性が公表されて通用しなくなっていました。

対策は、公開や本番反映の直前に、もう一度確かめ直すことです。AIに「今の状態でもう一度確認して」と頼むだけで済みます。

言い過ぎる：条件を省いて言い切る

AIの説明は、ときに成り立つ条件を省いて断定します。「この設定は読み込まれない」「このオプションを付ければ必ず直る」といった言い切りには、実際には「この置き場所なら」「このバージョンでは」という条件が隠れていることがあります。

見つけ方は2つです。

「その根拠は？」と聞き、公式ドキュメントのどこに書いてあるかを出させる
手元で再現できるものは、実際に動かして確かめる

このシリーズを書く過程でも、構成案の段階では、開発サーバーで確かめた結果をもとに「このファイルは読み込まれない」と書いていました。ところが本番ビルドで確かめると、読み込まれていました。「開発サーバーでは」という条件が抜けていたわけです。確かめる前と後で、記事の結論が変わりました。

効く進め方

毎回「結論 → 根拠 → 次の一手」の順で出させる。根拠が書けない結論は、確かめるまで保留にする
根拠は公式ドキュメントのURLで出させる。開けるか、本当にそう書いてあるかを自分で見る
公開・反映の前に、事実を確認し直す。とくにバージョン番号・脆弱性・料金・仕様
秘密情報を渡さない。APIキーやパスワードはチャットに貼らず、置き場所（シークレット管理など）だけを伝える

人に残る仕事は何か

AIが手を動かしてくれるほど、人の仕事は「作業」から「問いを立てること」と「引き受けること」に寄っていきます。

何を解決したいのかを決める
出てきた選択肢のうち、どれを採るかを決める
公開・反映した結果に責任を持つ

この3つは、AIがどれだけ速くなっても手元に残ります。逆に言えば、ここさえ握っていれば、手数はどんどん任せてよいと考えています。

チェックリスト：AIの出力を採用する前に

結論に根拠（公式ドキュメントのURLや実行結果）が付いているか
根拠のリンクを開いて、本当にそう書いてあるかを自分で確かめたか
「必ず」「すべて」「読み込まれない」などの言い切りに、隠れた条件がないか
手元で再現できるものは、実際に動かして確かめたか
バージョン番号・脆弱性・料金など、時間で変わる情報を直前に確認し直したか
本番に影響する変更は、自分で判断して反映したか

よくある質問

Q. AIが「確認しました」と言ったら、信じてよいですか？

A. 何をどう確認したのかを聞いてください。実行したコマンドと結果、または参照したドキュメントの箇所が示されていれば、自分でも同じことを確かめられます。示されないなら、確認はまだ終わっていないと考えます。

Q. 全部自分で確かめるなら、AIを使う意味はありますか？

A. あります。自分でゼロから調べるのと、AIが出した根拠を開いて確かめるのとでは、かかる時間がまったく違います。人がやるのは「探す」ことではなく「見て判断する」ことになります。

Q. どこまで任せるかは、作業ごとに決めるべきですか？

A. 目安は「間違えたときに、誰がどれだけ困るか」です。手元で何度でもやり直せる作業は大きく任せ、本番や他人に影響する作業ほど、確認と判断を手元に寄せます。

まとめ

AIに任せるのは調査・実装・検証の手数。とくに切り分け・仕様確認・定型作業は任せやすい
手元に残すのは、本番に影響する判断・トレードオフの選択・セキュリティの最終判断
AIの出力は古くなるし、条件を省いて言い切る。根拠を出させ、公式ドキュメントと実際の動作で確かめる
公開・反映の前にもう一度確かめ直す
人に残るのは「問いを立てること」と「引き受けること」