AIコーディング導入、最初の2週間で決める5つの線引き

生成AIにコードを書かせる、いわゆる「AIコーディング」を試してみたい。そう考える中小企業の経営者やシステム担当者は増えています。一方で、「とりあえず使ってみて」と現場に丸投げした結果、誰が何をどこまで使っているのか分からなくなり、セキュリティ部門や取引先からの問い合わせに答えられなくなる、という状況も起こりがちです。

AIコーディングツールの導入は、技術の問題である以上にルールと判断の問題です。そして、そのルールは「使い慣れてから整備する」のでは遅く、最初の2週間で大枠を決めてしまうのが現実的です。本稿では、受注開発の現場で業務システムを作る立場から、最初の2週間で必ず決めておきたい5つの論点を、判断材料とともに整理します。

なぜ「最初の2週間」が分かれ目になるのか

理由は単純で、2週間を過ぎると既成事実ができてしまうからです。開発者は便利なツールをすぐに日常のワークフローに組み込みます。そこから「この用途は禁止」と後出しで言うと、生産性が落ちた感覚だけが残り、ルールは形骸化します。

逆に、最初に「ここまではOK、ここからは要相談」という線さえ引いておけば、現場は安心して踏み込めます。決めるべきは細則ではなく、判断の基準と、迷ったときの相談先です。完璧な規程を作ろうとして3か月かかるより、A4一枚の暫定ルールを2週間で出すほうが実務的です。

決めること1：入力してよい情報の範囲

最初に決めるべきは、AIツールに何を渡してよいかです。ここが曖昧なまま走ると、後から取り返しがつきません。情報を次の3段階に分けて考えると整理しやすくなります。

ここで言う「学習に使われない設定」とは、入力した内容がモデルの再学習（追加の訓練）に利用されないことを指します。法人向けプランやAPI経由の利用では、入力データを学習に使わないと明示している提供事業者が多いものの、プランや契約形態によって扱いが異なります。利用規約とデータ処理条件を、導入前に必ず自社で確認してください。

個人情報を含むデータを外部サービスに渡す場合は、個人情報保護法上の委託や第三者提供の整理が必要になる場面があります。また、政府の「AI事業者ガイドライン」（総務省・経済産業省、2024年公表）では、AIを利用する事業者に対して、データの適正な取得・管理やリスクの把握を求める考え方が示されています。自社が公的機関や金融機関と取引している場合、こうした枠組みへの準拠状況を問われることもあります。

決めること2：どの工程に使うか

「AIでコードを書く」と一口に言っても、効果と risk は工程によってまったく違います。最初の2週間では、効果が出やすく失敗コストの低い工程から始めるのが定石です。

たとえば次のような場面です。10年前に作られた受発注システムの改修で、仕様書が残っていない。この場合、AIに既存コードを読ませて処理の流れを説明させると、調査にかかる時間を圧縮できる可能性があります。ただし出力された説明が正しい保証はないため、重要な分岐は人が実コードで裏取りする、という運用とセットにします。

決めること3：レビューの基準と責任の所在

AIが生成したコードであっても、本番に入れた時点で責任は自社にあります。したがって「AIが書いたから」はレビュー免除の理由になりません。むしろ逆で、生成コードは人が書いたコードと同等以上のレビューを通すと明記しておくべきです。

実務で詰まりやすいのは、AIが「それらしく動くが、前提が違う」コードを出してくるケースです。存在しないライブラリ関数を呼ぶ、古いバージョンの書き方を使う、エラー処理を省略する、といった傾向は依然として報告されています。レビュー時のチェック項目を最初に決めておきましょう。

• 依存ライブラリは実在し、ライセンスと保守状況に問題がないか
• 例外処理・入力値検証が省略されていないか
• SQLの組み立てが文字列連結になっていないか
• 既存の社内規約・命名規則から逸脱していないか
• 生成されたコードの意図を、担当者が自分の言葉で説明できるか

最後の項目が実は一番重要です。説明できないコードは、障害発生時に直せません。

決めること4：著作権とライセンスの扱い

生成されたコードが既存の著作物と同一・類似になる可能性はゼロではありません。文化庁「AIと著作権に関する考え方について」（2024年公表）では、AI生成物の利用についても、既存著作物との類似性と依拠性という従来の枠組みで判断されるという整理が示されています。つまり、AIが出したから自由に使える、ということにはなりません。

実務上は、特徴的なアルゴリズムやまとまった量のコードがそのまま出力されたと感じた場合は採用を避ける、OSSのライセンス表記が必要なコードを無断で取り込まない、といった運用で大半は回避できます。受注開発では、納品物にAI生成コードを含む場合の取り扱いを契約書でどう書くかも、早い段階で顧客と合意しておくと後の摩擦を防げます。

決めること5：やめる条件と測り方

導入を決めたら、同時に「どうなったらやめるか」も決めます。測定指標は凝る必要はなく、2週間で取れるもので十分です。

重要なのは、成果が出ない工程をずるずる続けないことです。前述のとおり工程によって向き不向きがはっきり出るため、2週間ごとに対象工程を入れ替えて試すほうが、全社一斉展開より学習が早く進みます。

まとめ

AIコーディングの導入で失敗する典型は、技術的な問題ではなく、線引きを決めないまま走り出すことです。最初の2週間で決めるべきは、(1)入力してよい情報の範囲、(2)適用する工程、(3)レビュー基準と責任の所在、(4)著作権・ライセンスの扱い、(5)測り方とやめる条件の5点です。

どれも完璧である必要はありません。暫定版でよいので文書化し、全員が同じ前提で動ける状態にすることが先です。そのうえで、テストコード生成や既存コード調査のような失敗コストの低い領域から着手し、効果を確認しながら範囲を広げていく。この順序を守れば、生産性を取りに行きながら、情報漏えいや品質低下のリスクを管理可能な範囲に収められます。

なお、ツールの仕様や提供事業者のデータ取り扱い方針は変更されることがあります。導入時点の規約を社内で控えておき、定期的に見直す運用を併せて決めておくことをおすすめします。