AIでプログラム自動生成｜実践手順とツール選び
Check!
- AIでプログラムを自動生成する4ステップと指示の出し方がわかる
- コード生成ツール3種類の選び方と生成コードのレビュー観点を整理
- 著作権・ライセンスの注意点とノーコードCMSとの使い分けを解説
「AIにプログラムを書かせてみたいが、どう指示すればよいか分からない」「生成されたコードをそのまま業務で使ってよいのか不安」「著作権やライセンスの扱いが気になって社内で導入を決めきれない」と悩んでいませんか。AIによるプログラムの自動生成は、要件の整理から指示、レビュー、テストまでの流れを押さえれば、開発の手間を大きく減らせる手段です。一方で、生成コードには不具合や脆弱性が含まれることがあり、「AIが書いたから正しい」と考えて使うと、後から大きな手戻りにつながります。この記事では、AIでプログラムを自動生成する具体的な手順、コード生成ツールの種類と選び方、生成コードの品質・セキュリティレビューの方法、著作権・ライセンス上の注意点、よくある失敗パターンまでを整理します。あわせて、そもそも「コードを書く」必要があるのかを見極めるための、ノーコードという選択肢との使い分けも解説します。
AIプログラム生成で読むべき箇所を診断
Q1. AIでのプログラム生成で、いま一番気になっていることは？
おすすめ記事
目次
開く
閉じる
開く
閉じる
作りたいものを実現する第一歩、ノーコードCMSという選択肢
AIでプログラムを生成するか、ノーコードツールで作るかは、「作りたいものが独自の処理を必要とするか」と「生成されたコードを社内で確認・保守できるか」の2点で判断するのが基本です。企業サイトやキャンペーンページ、お知らせ更新のように、決まった型で作れるものであれば、コードを書かずに済むノーコードCMSのほうが早く安全に形になることも少なくありません。
「AIでプログラム」と検索する人の目的はさまざまです。社内の定型作業を自動化するスクリプトを作りたい開発者もいれば、自社のWebサイトを作り直したいが外注費を抑えたいという担当者もいます。後者の場合、AIにHTMLやCSS、JavaScriptを書かせても、サーバーへの設置、更新作業、セキュリティ対策といった周辺の作業は残ります。AIによるコード生成は「プログラムを書く手間」を減らしますが、「プログラムを運用する手間」までは減らしてくれない点を押さえておくと、手段の選び間違いを防げます。3つの選択肢の違いを整理すると次のとおりです。
| 手段 | 向いているもの | 強み | 留意点 |
|---|---|---|---|
| AIによるコード生成 | 業務の自動化スクリプト、既存システムの機能追加、独自の計算処理 | 自由度が高く、細かい要件にも対応できる | 生成コードを読んで確認・修正できる人が必要。設置・保守の手間は残る |
| ノーコードCMS | 企業サイト、ブログ、LP、店舗ページなど型が決まったWebサイト | 画面操作で作成・更新でき、サーバー管理や更新作業の負担が小さい | テンプレートや提供機能の範囲を超える独自機能は作りにくい |
| 外部の開発会社に依頼 | 基幹システム連携、大規模な業務システム | 要件定義から保守まで専門家に任せられる | 費用と期間がかかり、仕様変更のたびに調整が必要 |
目的が「自社のWebサイトを持ちたい、更新を楽にしたい」であれば、AIにコードを書かせる前に、ノーコードCMSで実現できる範囲を確認しておくのが近道です。ノーコードCMSは、無料プランから試せるサービスもあり、デザインテンプレートを選んで文章や画像を差し替えるだけでページを公開できます。一方、カスタマイズ性や容量はプランによって差があるため、「どこまで自由に作りたいか」と照らし合わせて選ぶことが大切です。ノーコードCMSのメリット・デメリットや選び方、代表的なサービスの特徴は、次の記事で比較しています。
AIプログラミングの2つの意味と、AIに任せられる作業
「AIプログラミング」という言葉には、「AIそのものを開発するプログラミング」と「AIを使ってプログラムを書くこと」の2つの意味があり、この記事が扱うのは後者です。どちらを指しているかで、必要な知識も使う道具もまったく異なるため、最初に区別しておくと情報を探しやすくなります。
前者は、画像認識や需要予測、自然言語処理のように、データから学習するモデルを自分たちで作る開発を指します。Pythonなどのプログラミング言語と機械学習用のライブラリ、数学や統計の基礎知識が必要で、学習用のデータを集めて整える工程も欠かせません。後者は、文章で指示を出すとAIがコードの生成・補完・修正を行う使い方で、生成AIの普及によって広く使われるようになりました。作るものは在庫集計や帳票出力といった通常のプログラムであり、AIの仕組みに詳しくなくても始められます。なお、従来のプログラムは人が書いた手順どおりに動くのに対し、AIはデータから規則を学習して出力を決めるため、同じ指示でも結果が変わることがあります。生成されたコードを人が確認する工程が必要になるのは、この性質によるものです。
AIに任せられる作業の範囲
AIが支援できるのは、新しいコードを書く場面だけではありません。開発の工程ごとに見ると、次のような作業で使われています。
| 作業 | AIができること | 人が確認すること |
|---|---|---|
| コードの生成・補完 | 文章の指示や書きかけのコードから、続きや関数全体を提案する | 要件どおりの処理になっているか |
| エラー・バグの調査 | エラーメッセージから原因の候補と修正案を示す | 修正案が本当の原因を解消しているか |
| リファクタリング | 読みにくいコードや古い書き方を、動作を変えずに整理する案を出す | 書き換え前後で動作が変わっていないか |
| テストコードの作成 | テストケースの洗い出しとテストコードの下書きを行う | 業務上重要な条件が漏れていないか |
| コードの説明・ドキュメント作成 | 既存コードの処理内容を文章で説明し、コメントや手順書のたたき台を作る | 説明が実際の処理と食い違っていないか |
| 表計算の関数・マクロ | やりたい集計を伝えると、関数やマクロの例を示す | 元データを壊さないか、想定外の行で止まらないか |
| 試作品(プロトタイプ)の作成 | 画面や簡単なアプリのたたき台を短時間で作る | 本番運用に耐える設計になっているか |
メリットとデメリット、人に残る役割
メリットは、定型的なコードを書く時間を減らせること、不慣れな言語やライブラリでも着手しやすくなること、処理内容を文章で説明させることで特定の担当者しか分からない状態を減らせることです。デメリットは、出力の精度にばらつきがあり、存在しない関数を使うなどの誤りが混ざること、著作権・ライセンスや情報漏えいの確認が必要になること、そして内容を理解しないまま使い続けると、保守しにくいコードが増えたり、担当者のスキルが育ちにくくなったりすることです。
「AIがあればプログラマーは不要になるのか」という疑問を持つ人もいますが、現状のAIは開発者を置き換えるものではなく、作業を補助する道具と捉えるのが一般的です。何を作るべきかを決める要件定義、システム全体の構成を決める設計、生成されたコードが正しく安全かを見極める評価は、引き続き人が担います。むしろ、書く作業の比重が下がるほど、要件を言葉にする力と、コードを読んで判断する力の重要性は高まります。次の章からは、この前提に立って具体的な進め方を見ていきます。
AIでプログラムを自動生成する方法
AIによるプログラムの自動生成は、「要件を整理する」「指示(プロンプト)を出す」「生成結果を確認・修正する」「テストする」の4ステップで進めると、意図と違うコードが出てくる失敗を減らせます。どのツールを使う場合でも、この流れは共通です。
ステップ1. 要件を整理する
最初に、何を入力として受け取り、何を出力するのか、例外が起きたときにどう動くべきかを文章で書き出します。たとえば「売上CSVを集計するプログラム」であれば、CSVの列構成、文字コード、集計の単位(日別・月別・担当者別)、空欄や不正な値があったときの扱い、出力形式(画面表示・Excel・CSV)までを決めておきます。ここを曖昧にしたままAIに依頼すると、AIはもっともらしい前提を勝手に補ってコードを書くため、動くけれど業務には合わないプログラムができあがります。要件を書き出す作業は、人に開発を頼むときの仕様書づくりと同じで、AI活用でも省略できない工程です。
ステップ2. 具体的な指示(プロンプト)を出す
指示には、使うプログラミング言語とバージョン、利用してよいライブラリ、入出力の例、守ってほしいコーディング規約を含めます。抽象的な指示と具体的な指示では、得られる結果が大きく変わります。
| 指示の質 | 指示の例 | 結果の傾向 |
|---|---|---|
| 抽象的 | 「在庫を管理するプログラムを作って」 | 前提が不足し、想定と違う機能や構成になりやすい |
| 具体的 | 「商品コードと在庫数の列を持つCSVを読み込み、在庫数が10未満の商品一覧をCSVで出力する関数をPythonで書いて。空欄の行は読み飛ばし、件数をログに出して」 | 意図に近いコードが得られ、修正の手間が少ない |
| 段階的 | 「まず処理の設計方針だけ箇条書きで出して」の後で「その方針でコードを書いて」 | 設計段階で食い違いに気づけるため、大きな手戻りを防げる |
一度で完璧なコードを得ようとせず、小さな単位で生成と確認を繰り返すのが実践的です。大きなプログラムを一度に書かせると、どこに問題があるのか人が追いにくくなります。関数単位、画面単位など、1回で確認できる量に分けて依頼しましょう。
ステップ3. 生成結果を読んで確認・修正する
生成されたコードは、まず処理の流れを人が読んで理解できるかを確認します。意味の分からない処理や、要件にない機能が含まれていれば、その部分の意図をAIに質問し、不要なら削除を指示します。エラーが出た場合は、エラーメッセージと実行した手順をそのままAIに伝えると、原因の候補と修正案を示してくれることが多くあります。ただし、修正案が本当に原因を解消しているかは、最終的に人が判断する必要があります。
ステップ4. テストして動作を確かめる
正常なデータだけでなく、空のデータ、想定外の文字、非常に大きなデータなど、境界的な条件でも動作を確かめます。テストコード自体をAIに書かせることもできますが、テストの観点(何を確かめるべきか)は要件を知っている人が決めるべきです。AIに「このコードのテストケースを洗い出して」と依頼し、出てきた観点を人が取捨選択する使い方をすると、確認漏れを減らしながら効率も上げられます。
主なコード生成ツールの種類と選び方
コード生成ツールは、「対話型AI」「開発環境統合型」「アプリ・画面生成型」の3種類に大きく分けられ、誰がどの場面で使うかによって向き不向きが変わります。名前の知られたツールから選ぶのではなく、自社の使い方に合う種類を先に決めると、比較がしやすくなります。
| 種類 | 特徴 | 向いている人・場面 | 留意点 |
|---|---|---|---|
| 対話型AI(チャット型) | チャット画面で相談しながらコードを生成・説明してもらえる | 短いスクリプトの作成、エラーの原因調査、学習用途 | 既存のプロジェクト全体の構成は把握しにくく、貼り付けた範囲の情報で判断する |
| 開発環境統合型 | コードエディタ内で補完・生成・修正提案を受けられる | 日常的に開発を行うエンジニア、既存コードの改修 | ソースコードが外部に送信される範囲を事前に確認する必要がある |
| アプリ・画面生成型 | 文章で説明するだけで画面やアプリの試作品を作れる | 企画段階の試作、社内向けの小さなツール | 試作から本番運用に移すときに、設計や保守性の見直しが必要になりやすい |
代表的なサービスで言えば、対話型AIにはChatGPT、Claude、Geminiなどの汎用チャットAIがあり、開発環境統合型にはGitHub CopilotやCursorのようにエディタ上でコードの補完・修正を提案するツールがあります。アプリ・画面生成型には、ブラウザ上で文章の指示からアプリの試作まで進められるReplitなどのサービスがあります。いずれも新しいコードを書くだけでなく、既存コードのエラー原因の説明、バグ修正案の提示、読みやすく書き直すリファクタリングの提案にも使えるため、「新規開発」と「既存コードの改善」のどちらに使いたいかも選定の軸になります。各サービスの機能や料金、無料で使える範囲は頻繁に変わるため、導入前に必ず公式サイトで最新の情報を確認してください。
種類を決めたら、個別のツールを次の観点で比較します。特に業務で使う場合は、機能や生成精度よりも、入力したデータの扱いと管理機能の確認が重要になります。
| 確認する観点 | 具体的に見るポイント |
|---|---|
| 入力データの扱い | 入力したコードや文章がAIの学習に使われるか、使われない設定にできるか、保存期間はどれくらいか |
| 対応言語・環境 | 自社で使っているプログラミング言語、フレームワーク、エディタに対応しているか |
| 組織向けの管理機能 | 利用者の一括管理、利用ログの確認、利用範囲の制限ができる法人向けプランがあるか |
| 生成コードの権利に関する規約 | 生成物の権利の帰属、既存コードと類似した場合の扱いが利用規約でどう定められているか |
| 料金体系 | 利用者数単位か利用量単位か、無料プランで業務利用が認められているか(料金は変動するため公式サイトで確認) |
選定時は、無料プランや試用期間で自社の実際のコードに近い題材を使って試し、「自社の規約どおりのコードが出るか」「レビューにかかる時間がどれくらいか」を確かめてから本格導入を判断すると、導入後のミスマッチを防げます。
生成コードの品質・セキュリティレビュー
AIが生成したコードは、動作するかどうかだけでなく、「要件どおりか」「安全か」「後から人が保守できるか」の3つの観点で人がレビューしてから使うのが原則です。生成AIは文脈を取り違えたり、存在しない関数やライブラリを使ったりすることがあり、見た目が整っていても正しいとは限りません。
品質面で確認すること
品質面では、要件にない処理が紛れ込んでいないか、エラー処理が省略されていないか、変数名や構成が自社のコーディング規約に沿っているかを確認します。AIは一般的な書き方を優先するため、自社独自のルール(命名規則、ログの出し方、例外の扱い)は指示しない限り反映されません。また、同じ処理を別の場所で重複して書いていたり、古い書き方を使っていたりすることもあります。レビューで気づいた点は指示のテンプレートに追記していくと、次回以降の生成品質が安定します。
セキュリティ面で確認すること
セキュリティ面では、外部からの入力をそのままデータベースへの命令や画面表示に使っていないか、パスワードやAPIキーがコードに直接書き込まれていないか、利用しているライブラリが実在し、保守が続いているものかを確認します。Webアプリケーションの代表的な脆弱性と対策は、独立行政法人情報処理推進機構(IPA)の「安全なウェブサイトの作り方」で体系的に整理されており、レビューの観点をつくる際の拠り所になります。
もう1つ見落としやすいのが、AIに渡す情報そのものの管理です。顧客情報を含むデータ、社外秘の設計書、認証情報を含む設定ファイルをAIに貼り付けてしまうと、ツールによっては外部に保存されます。何を入力してよいかを社内ルールで決めておくことが、生成コードのレビューと同じくらい重要です。レビューの観点をまとめると次のとおりです。
| 観点 | チェック項目 |
|---|---|
| 要件との一致 | 入出力・例外時の動作が要件どおりか。要件にない処理が含まれていないか |
| 入力値の扱い | 外部からの入力を検証・無害化してから使っているか |
| 秘密情報 | パスワードやAPIキーがコード内に直接書かれていないか |
| 依存ライブラリ | 実在し、保守が続いているものか。ライセンス条件を確認したか |
| 保守性 | 担当者以外が読んでも処理の意図が分かるか。コメントや命名が規約に沿っているか |
こうしたレビューを継続するには、コードを読める人材が社内に必要です。逆にいえば、レビュー体制を用意できない状態でWebサイトのような公開物をAI生成コードで作るのは、脆弱性を抱えたまま公開するリスクがあります。作りたいものが自社サイトや情報発信用のページであれば、セキュリティ対策や更新の仕組みがサービス側で用意されているノーコードCMSを選ぶほうが、社内の負担を抑えられます。
著作権・ライセンス上の注意点
AIが生成したプログラムを業務で使う際は、「既存のコードと似ていないか」「オープンソースのライセンス条件に触れていないか」「ツールの利用規約で生成物の扱いがどう定められているか」の3点を確認しておくことが一般的に推奨されています。
文化庁は「AIと著作権について」のページで、AIの開発・学習段階と、生成・利用段階を分けて考え方を整理しています。生成・利用段階では、AIを使わずに作った場合と同様に、既存の著作物との類似性と依拠性があるかどうかで著作権侵害の有無が判断されるとされています。プログラムも著作物に含まれ得るため、生成されたコードが既存のコードとほぼ同じ形で出力された場合には注意が必要です。
オープンソースのライセンスにも配慮が必要です。ライセンスの中には、そのコードを組み込んだソフトウェアを配布する場合に、ソースコードの公開や著作権表示を求めるものがあります。AIが学習したコードの断片が生成結果に含まれていると、意図せずこうした条件の対象になる可能性が指摘されています。ツールによっては、公開コードと一致する出力を検出・抑制する設定を用意しているため、選定時に確認しておくと安心です。
| 確認項目 | 具体的な対応 |
|---|---|
| 既存コードとの類似 | 長いまとまりのコードがそのまま出力された場合は、出所を確認するか書き直す |
| ライセンス条件 | 公開コードとの一致を抑制する設定を使う。依存ライブラリのライセンスを一覧化する |
| ツールの利用規約 | 生成物の権利の帰属、商用利用の可否、入力データの扱いを確認し、改定時も見直す |
| 社内の記録 | どの部分をAIで生成したかを記録しておき、問題発生時に追跡できるようにする |
なお、AIと著作権をめぐる考え方は、今後の議論や裁判例によって変わる可能性があります。本記事は一般的な情報提供を目的としたものであり、法的助言ではありません。個別の判断が必要な場合は、弁護士などの専門家に相談してください。
立場別に見るAIプログラム活用の始め方
AIによるプログラム生成は、使う人の立場によって「任せてよい範囲」と「人が担うべき範囲」が異なるため、開発者・情報システム担当者・非エンジニアの3つの立場で分けて考えると、導入の進め方を決めやすくなります。
総務省の「令和7年版 情報通信白書」によると、生成AIの活用方針を定めている日本企業の比率は2024年度調査で49.7%と、2023年度調査の42.7%から増加しました。一方で、中小企業では「方針を明確に定めていない」との回答が約半数を占めています。方針がないまま個人の判断でコード生成AIを使い始めると、入力データの扱いやレビューの有無が人によってばらばらになりがちです。立場ごとの役割を先に決めておくことが、安全に効果を出す近道です。
| 立場 | AIに任せやすいこと | 人が担うべきこと |
|---|---|---|
| 開発者 | 定型的なコードの下書き、テストケースの洗い出し、既存コードの説明 | 設計判断、レビュー、セキュリティ上の最終確認 |
| 情報システム担当者 | 業務自動化の小さなスクリプト、設定手順書のたたき台 | 利用ルールの策定、ツールの選定と権限管理、入力してよい情報の線引き |
| 非エンジニア | 表計算の関数やマクロの相談、アイデアの試作 | 業務で継続利用するものは情報システム担当者に確認を依頼する。Webサイトなど公開物はノーコードツールの活用を検討する |
AIを事業で利用する際の考え方全般については、経済産業省・総務省がまとめた「AI事業者ガイドライン」が参考になります。AIの利用者として求められる、適正な利用や情報の取り扱いについての考え方が整理されており、社内ルールをつくる際の出発点として使えます。
AIプログラム生成でよくある失敗パターン4つ
AIによるプログラム生成の失敗は、ツールの性能不足よりも、要件の曖昧さ、レビューの省略、情報管理の甘さ、手段の選び間違いという「使い方」の問題から起きることがほとんどです。代表的な4つのパターンと改善策を整理します。
| 失敗パターン | Before(よくある状態) | After(改善後) |
|---|---|---|
| 1. 丸投げの指示 | 「〇〇を作って」の一言で依頼し、想定と違うコードの修正に時間がかかる | 入出力・例外・言語を明記し、設計方針の確認を挟んでから生成する |
| 2. レビューなしでの本番投入 | 動いたのでそのまま使い、後から不具合や脆弱性が見つかる | 要件・安全性・保守性のチェック項目で人が確認してから反映する |
| 3. 機密情報の入力 | エラー解決のために、顧客データや認証情報を含むファイルをそのまま貼り付ける | 入力禁止の情報を社内ルールで定め、ダミーデータに置き換えて相談する |
| 4. 手段の選び間違い | 自社サイトをAI生成コードで作ったが、更新や保守ができる人がいない | 型が決まったWebサイトはノーコードCMSで作り、独自処理だけAIで開発する |
特に4つ目は、AIの手軽さゆえに起きやすい失敗です。AIに頼めばコードはすぐに出てきますが、そのコードを動かし続けるための環境の用意、ソフトウェアの更新、障害時の対応は人の仕事として残ります。作った後に誰がどう運用するかまで考えてから手段を選ぶことが、結果的に最も手戻りの少ない進め方になります。
導入効果をどう確認するか
AIによるプログラム生成の効果は、「作成にかかった時間」だけでなく、「レビューや修正にかかった時間」「リリース後の不具合件数」まで含めて測ると、実態に近い評価ができます。生成が速くても、レビューや手戻りに時間がかかっていれば、全体としての効率は上がっていないためです。
| 指標 | 測り方の例 | 見るべきポイント |
|---|---|---|
| 作成時間 | 同程度の規模の作業で、導入前後の着手から完成までの時間を比べる | 題材の難易度をそろえて比較する |
| レビュー・修正時間 | 生成後に人が確認・修正した時間を記録する | この時間が増えていれば、指示の出し方や使う範囲を見直す |
| 不具合件数 | リリース後に見つかった不具合の件数と内容を記録する | AI生成部分に偏っていないかを確認する |
| 利用範囲 | どの作業でAIを使ったかを分類して記録する | 効果の大きい作業と小さい作業を見分け、使いどころを絞る |
効果を測ってみると、「テストコードの作成や既存コードの説明には効果が大きいが、Webページの作成と更新は結局人手がかかっている」といった傾向が見えてくることがあります。後者のように、効果が出ていない作業がWebサイトの制作・更新であれば、プログラムを書くこと自体をやめて、ノーコードCMSに置き換えることも検討する価値があります。AIでのコード生成と、コードを書かないツールを作業ごとに使い分けることで、開発リソースを本当に独自の処理が必要な部分に集中させられます。
よくある質問(FAQ)
Q1. プログラミングの知識がなくてもAIでプログラムを作れますか?
A. 簡単なスクリプトや表計算の関数であれば作れる場合があります。ただし、生成されたコードが正しいか、安全かを判断するには一定の知識が必要です。業務で継続して使うものは詳しい人に確認を依頼し、Webサイトのような公開物はノーコードツールの活用も検討すると安心です。
Q2. AIが生成したコードはそのまま業務で使ってよいですか?
A. そのまま使うのは避けるべきです。生成コードには要件との食い違いや脆弱性が含まれることがあるため、要件との一致、入力値の扱い、秘密情報の有無、依存ライブラリ、保守性の観点で人がレビューし、テストしてから使うのが原則です。
Q3. どのコード生成ツールを選べばよいですか?
A. まず使い方に合う種類(対話型AI、開発環境統合型、アプリ・画面生成型)を決め、そのうえで入力データの扱い、対応言語、組織向けの管理機能、生成物に関する利用規約、料金体系を比較します。無料プランなどで自社のコードに近い題材を試してから判断すると失敗が少なくなります。
Q4. AIで生成したプログラムの著作権はどうなりますか?
A. 文化庁の整理では、生成物の利用による著作権侵害の有無は、既存の著作物との類似性と依拠性で判断されるとされています。生成物の権利の扱いはツールの利用規約でも定められているため、あわせて確認してください。個別の判断が必要な場合は専門家への相談をおすすめします。
Q5. 社内のソースコードをAIに入力しても大丈夫ですか?
A. ツールによって、入力内容が学習に使われるか、どこにどれくらい保存されるかが異なります。利用規約と設定を確認し、法人向けプランの利用や学習に使わない設定を検討してください。顧客情報や認証情報は入力しないなど、社内ルールで入力してよい範囲を決めておくことが大切です。
Q6. 自社サイトを作るならAIでコードを書くのとノーコードCMSのどちらがよいですか?
A. 企業サイトやブログ、LPのように型が決まったWebサイトであれば、画面操作で作成・更新でき、サーバー管理の負担も小さいノーコードCMSが向いています。独自の計算処理や既存システムとの連携など、テンプレートの範囲を超える機能が必要な部分にだけAIでのコード生成を使う組み合わせが現実的です。
まとめ
AIによるプログラムの自動生成は、要件の整理、具体的な指示、人によるレビュー、テストという流れを守ることで、開発の手間を減らす強力な手段になります。一方で、生成コードの品質・セキュリティ、著作権・ライセンス、入力データの管理は、ツールではなく使う側が責任を持って確認すべき点です。今日から取り組めることは次の3つです。
- 作りたいものが「独自の処理が必要な開発」か「型が決まったWebサイト」かを切り分け、後者ならノーコードCMSを先に検討する
- AIに渡す指示のテンプレートと、入力してはいけない情報のルールを社内で決める
- 生成コードのレビュー項目(要件、入力値、秘密情報、依存ライブラリ、保守性)を用意し、作成時間だけでなくレビュー時間や不具合件数でも効果を測る
参考文献
- 文化庁「AIと著作権について」 https://www.bunka.go.jp/seisaku/chosakuken/aiandcopyright.html
- 経済産業省「AI事業者ガイドライン」 https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20240419_report.html
- 独立行政法人情報処理推進機構(IPA)「安全なウェブサイトの作り方」 https://www.ipa.go.jp/security/vuln/websecurity/about.html
- 総務省「令和7年版 情報通信白書 企業におけるAI利用の現状」 https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r07/html/nd112220.html
