AIコーディングの話になると、「どのモデルが一番強いか」「どこまで自動で作れるか」に注目が集まりがちです。もちろん性能は大事です。ただ、業務で使うときに本当に差が出るのは、モデル名よりも人間側の渡し方です。
同じAIを使っていても、毎回「この画面をいい感じに直して」と丸投げする人と、「このファイルのこの責務は変えず、ボタン位置だけを変えた。次は保存時の検証だけ見てほしい」と渡せる人では、出てくる結果も費用も変わります。
中小企業がAIで小さな業務ツールやWebサイト改修を進めるなら、最初に覚えるべきなのは高度なプロンプト術ではありません。AIに渡す文脈を、人間がどこまで絞れるかです。
AIに全部探させるほど、手戻りは増える
AIは広い範囲を読むことができます。長いコード、複数ファイル、過去の仕様、エラーログをまとめて渡せる場面も増えています。
ただし、読めることと、正しく判断できることは別です。既存コードには、その会社だけの事情があります。昔の暫定対応、画面上は見えない運用ルール、あとで直す予定だった妥協、担当者が覚えているだけの前提。こうした文脈は、コードだけを読んでも分かりません。
丸投げに近い依頼を繰り返すと、AIはそれらしい修正を返します。しかし、責務をずらしたり、将来の変更に弱い構造にしたり、既存の運用ルールを壊したりすることがあります。動いたように見えるのに、次の変更でほころびが出る。AIコーディングで起きやすい失敗です。
ここで必要なのは、AIに読ませる量を増やすことだけではありません。むしろ、人間が「今回の判断に必要な文脈だけ」を先に切り出すことです。
強い依頼は、コードより先に前提を渡す
AIにコード修正を頼む前に、まず前提を短くまとめます。たとえば、次の5つです。
- この機能の目的
- 変えてよい範囲
- 変えてはいけない範囲
- 既存の例外ルール
- 人間が最後に確認する条件
この5つがないまま依頼すると、AIは「一般的によさそうな実装」を返しやすくなります。一方で、前提があると、AIはその会社の作業として扱いやすくなります。
たとえば、「問い合わせフォームに項目を追加して」ではなく、「既存の送信処理と通知先は変えず、入力欄を1つ増やす。保存先の列名は既存命名規則に合わせる。送信テストは人間が最後に実施する」と渡すだけで、事故の種類はかなり減ります。
AIに任せるほど、人間の仕事が消えるわけではありません。人間の仕事は、手を動かすことから、前提を短く渡し、結果を確認できる単位に切ることへ移ります。
依頼は「全体」ではなく「差分」で切る
AIコーディングで費用と手戻りを増やしやすいのは、毎回コード全体を読ませる使い方です。もちろん初回の調査では広く読ませる必要があります。ただ、毎回それを繰り返すと、確認にも時間がかかります。
現場で使いやすいのは、差分単位の依頼です。
今回の変更:
- 商品詳細ページに在庫注意文を追加した
- 既存の価格表示ロジックは変更していない
- 変更ファイルは商品詳細コンポーネントのみ
確認してほしいこと:
- 表示条件が既存仕様と矛盾していないか
- モバイル幅で文言が崩れないか
- 既存テストに追加すべき観点があるかこの形なら、AIは作業範囲を絞って考えられます。人間もレビューしやすくなります。AIに「全部見て」と頼むより、AIに見てほしい観点を先に決める方が、結果として速い場面は多くあります。
レビューとテストを後回しにしない
GitHubのCopilot関連ドキュメントでも、AIの提案は人間がレビューし、要件やエラー、セキュリティ上の懸念がないか確認する前提で説明されています。AIが書いたコードをそのまま信じるのではなく、レビューとテストを作業の一部として扱う必要があります。
ここで大事なのは、「最後にざっと見る」では足りないことです。AIに依頼する前から、何を確認するかを決めておきます。
- 動けばよいのか
- 既存データを壊さないことが重要なのか
- 権限や個人情報に触れるのか
- 失敗したときに戻せるのか
- 誰が確認して公開判断をするのか
確認条件がないままAIに作らせると、レビューする人も迷います。レビュー観点が曖昧なまま「たぶん大丈夫」で進むと、AI導入の効果よりも事故対応の負担が大きくなります。
中小企業で最初に決める5項目
AIコーディングを社内で使い始めるなら、大きな規程よりも、まず短い運用メモを作る方が現実的です。
1. AIに任せてよい作業:
文言修正、軽いUI調整、テスト案、既存コードの説明
2. 人間確認が必須の作業:
顧客データ、決済、権限、契約、外部公開に関わる変更
3. AIに渡す文脈:
目的、変更範囲、変更禁止範囲、既存ルール、確認条件
4. 残すログ:
依頼文、AIの提案、採用した差分、人間の修正点
5. 止める条件:
仕様が分からない、影響範囲が広い、レビューできる人がいないこれだけでも、丸投げのまま進む状態を避けられます。AIを使うこと自体を制限するのではなく、AIが得意な部分と、人間が持つべき判断を分けるためのメモです。
Optiensの見方
Optiensでは、AIコーディングを「開発作業を全部置き換えるもの」ではなく、業務改善の小さな差分を速く試すための道具として見ています。
特に中小企業では、最初から大きな内製開発を目指すより、既存SaaS、フォーム、スプレッドシート、簡単な管理画面、通知フローなど、影響範囲が見えるところから始める方が安全です。そのうえで、AIに渡す文脈と、人間が確認する境界線を決めておく必要があります。
AI活用をどこから始めるべきか迷っている場合は、まず AI活用診断簡易版（無料） で、既存業務のどこがAIパッケージ化しやすいかをご確認ください。実装まで進めたい候補が見えた場合は、導入前スコープ整理 で対象業務、含む範囲、費用感、5営業日で初期版にできるかを整理します。
AIに強い人は、AIに何でも任せる人ではありません。AIが迷わないように、文脈を短く渡せる人です。
関連記事
参考資料
- GitHub Docs: Best practices for using GitHub Copilot
- GitHub Docs: Responsible use of GitHub Copilot Chat
- NIST: AI Risk Management Framework