「生成AIを使って、自社の仕事に合う道具を作りたい」「ChatGPTのようなものを自社用に作れるのか」。生成AI開発という言葉を調べている方の多くは、こうした場面にいます。ただ、「作る」と言っても、AIのモデルそのものを作る話から、既存のモデルを使った小さな道具づくりまで、幅がとても広いのが実情です。
結論から言うと、生成AI開発とは、文章・画像・プログラムなどを作れる生成AIを使って、業務で使える道具や仕組みを作ることです。 多くの場合、モデルそのものは作らず、すでにあるモデルを、プロンプト(指示文)の工夫・社内資料の参照(RAG)・追加学習で自社の用途に合わせます。結果を分けるのは、どのモデルを使うかよりも、答えをどう確かめ、どこまで任せるかの設計です。
この記事では、国の指針や各社の公式ドキュメントをもとに、次のことを整理します。情報は2026年10月時点のものです。
- 生成AI開発で「作る」ものの3つの意味と、モデルを作らなくてよい理由
- プロンプト・RAG・追加学習・自前のモデルという4つの作り方と、試す順番
- 外部のAPI・クラウド経由・オープンなモデルという、モデルの置き場所の違い
- 答えの質と安全を確かめる設計(評価・ハルシネーション・出力の形・入力の安全)
- 費用が何で決まるかと、進め方、よくある失敗
生成AI開発とは?作るものの3つの意味と、モデルを作らなくてよい理由
生成AIとは何か:国の資料での説明
総務省・経済産業省のAI事業者ガイドライン(第1.0版)(2024年4月公表)は、生成AIを「文章、画像、プログラム等を生成できるAIモデルにもとづくAIの総称」としています。総務省の令和7年版情報通信白書は、文章や画像、動画などを作るAIが生成AIで、その技術の一つが大規模言語モデル(LLM)だと説明しています。
ChatGPTやClaude、Geminiのように、言葉で指示すると文章などを返してくれるものを思い浮かべると、イメージしやすいでしょう。
「生成AI開発」の3つの意味
「生成AI開発」は、次の3つの意味で使われています(筆者の整理)。
- モデルそのものを作る:大量のデータからAIのモデルを学習させて作ること。大きな計算設備と専門人材が要る
- 既存のモデルを使って、道具や仕組みを作る:すでにあるモデルを部品として使い、社内の問い合わせ対応、文書の要約、書類の読み取りなどの道具を作ること
- 開発の作業に生成AIを使う:プログラムを書く、テストを作るといった作業を生成AIに手伝わせること
検索する人の多くが知りたいのは、2つ目だと考えられます。この記事も2つ目を中心に、3つ目は注意点を短く扱います。
AI開発者とAI提供者:自社はどちらに当たるか
先ほどのガイドラインは、モデルを作る事業者と、それを組み込んで提供する事業者を分けています。AIモデルの開発やデータ収集、学習と検証までを担う事業者は「AI開発者」と呼ばれます。一方、AI事業者ガイドライン(第1.2版)(2026年3月公表)では、AIシステムをアプリ、製品、既存のシステム、業務の流れに組み込んだサービスとして提供する事業者が「AI提供者」とされています。
既存のモデルを使って道具を作る会社は、多くの場合、後者の「AI提供者」の立場になります。つまり、自社の業務に使う道具を作るだけなら、モデルを一から作る必要はありません。
生成AIで作れるものの例
2つ目の意味(既存のモデルを使って道具を作る)で、よく見られる形を3つ挙げます(筆者の整理)。どれも、AIは仕組み全体の一部で、データの取り込みや画面、権限の設計が大きな部分を占めます。
社内の資料に答える道具
規程やマニュアル、過去の対応記録を探して、質問に答えたり、該当する箇所を示したりする道具です。資料の置き場所と閲覧権限の整理が、最初の仕事になります。
書類を読み取って下書きを作る道具
見積もり依頼書や注文書などを読み取り、項目を拾って、入力の下書きを作る道具です。最終の確定は人が行う形にすると、誤りの影響を小さくできます。
データについて、ふだんの言葉で質問できる道具
売上や在庫のデータに、ふだんの言葉で質問して、集計や傾向を見る道具です。数字の計算は、AIに任せず、プログラム側で行う設計もよく取られます。
筆者が関わった2つの例
筆者(WebLeben)が関わり、すでに事例として公開している開発の中から、生成AIとの関わり方が違う2つを紹介します。詳しくはAI開発事例100選に載せています。
- S社(見積もり依頼書を読み取って、似た案件を探すデモ版):ブラウザの中だけで動き、データを外に送りません。生成AIなどの外部のAIはまだつないでいません。データを外に出したくない場合は、まず外に出さない形で試すという選び方の例です
- T店(レジの売上データを使った土台):レジの売上データを書き出してクラウドに保存し、生成AI(ChatGPT)とつないで、保存したデータについて質問できる形にしました。既存のモデルを部品として使う、2つ目の意味の例です
どちらも小さな規模で、期間や費用の数字は公開していません。ここから分かるのは、「何を外に出すか」と「どこで動かすか」を最初に決めることが、作り方を選ぶ前提になる、という点です。
AI開発・AIシステム開発・AIアプリ開発との違い
似た言葉との違いを、この記事の中での使い分けとして表にします(筆者の整理)。
| 言葉 | 中心になる話 | 生成AIとの関係 |
|---|---|---|
| AI開発 | データから学ばせるAIも含む広い言葉 | 生成AIは選択肢の一つ |
| 生成AI開発(この記事) | 生成AIを使う道具の作り方、答えの確かめ方、費用、安全 | 生成AIが前提 |
| AIシステム開発 | 業務システムへのつなぎ方、開発工程での使い方 | 生成AIを使うことが多い |
| AIアプリ開発 | 画面のある道具(アプリ)としての作り方 | 生成AIを組み込むことが多い |
生成AI開発の4つの作り方:プロンプト→RAG→追加学習→自前のモデル
生成AIを自社の用途に合わせる方法は、大きく4つあります。公式の資料を組み合わせると、手間の少ない順に試すのが基本です。
4つの作り方の比較と、試す順番
| 作り方 | 内容 | 向いている場面 | 手間と注意 |
|---|---|---|---|
| ①プロンプトの工夫 | 指示文・例・背景情報を整える | まず試す。文章の型や口調を整える | 手間が最も小さい。長い指示は毎回の費用に響く |
| ②RAG(外部資料の参照) | 質問のたびに社内資料などを探して渡す | 社内の資料・最新の情報に答えさせる | 資料の整理と検索の仕組みが要る。閲覧権限に注意 |
| ③追加学習(ファインチューニング) | 例を与えてモデルを調整する | 型の決まった作業を安定させたい | 質の高い例を集める手間。提供元の方針の影響を受ける |
| ④自前のモデル | モデルそのものを作る | ごく限られた事業者の領域 | 計算設備・人材・データが大きく必要 |
試す順番の目安は、次のとおりです。ただし、この順序を1つの文で述べた公式の文書は見つかっていません。次の各項目で引く複数の公式資料を組み合わせた、筆者の整理です。
- 評価用の問いを作り、まずプロンプトの工夫で足りるかを見る
- 社内資料に答えさせたいなら、RAGを試す
- 型の決まった別の作業を安定させたいときに、追加学習を検討する
- モデルそのものを作る必要があるかは、ここまでで足りなかったときに考える
①プロンプトの工夫:まず試す
OpenAIのモデル最適化のガイドは、評価を用意したうえでプロンプトを工夫することを勧めたうえで、プロンプトの工夫だけで目的の結果が得られることもあると述べています。指示文には、背景情報を入れる、期待する答えの例を添える、といった工夫が挙げられています。
②RAG:社内の資料に答えさせる
RAGは、質問に合う資料を探して、その内容をAIに渡したうえで答えさせる方法です。AWSのRAGの解説は、モデルを再学習させずに社内の知識を使えるようにする、費用対効果の高い方法だと説明しています。同じAWSの選び方の資料は、RAGは最新の資料を数分で取り込めるとしています。
資料を使って答える仕組みを作りたいなら、RAGから始めるのが基本です。総務省・経産省のガイドライン第1.2版も、RAGの活用でハルシネーション(もっともらしい誤り)の抑制や、答えの根拠の透明性の向上が期待されていると書いています。ただし、期待されている、という書き方で、必ず減るという意味ではありません。見てはいけない人に社内文書が見えないようにする閲覧権限の設計は、AIシステム開発の記事で整理しています。
③追加学習:型の決まった作業を安定させる
追加学習は、例を与えてモデルを調整する方法です。Microsoftの追加学習の解説は、数百から数千組ほどの、質の高い例(指示と答えの組)があって、モデルの性能を上げたいときに向くとしています。OpenAIのガイドは、追加学習をすると、短い指示で済み、使う量が多いときのトークン費用(後の節で説明します)を抑えられると述べています。
AWSの選び方の資料は、資料を使って答える仕組みはRAGから始め、要約のような別の作業をさせたいときに追加学習を使う、という分け方を示しています。同じ資料には、追加学習したモデルで質問に答えさせると、誤りが出る危険が高まりうるとの注意もあります。
注意したいのは、追加学習の提供が提供元の都合で変わりうることです。OpenAIのガイドは、追加学習のプラットフォームを縮小しているとしており、新しい利用者はもう使えない旨を書いています(この記事の執筆時点の記述です)。追加学習をしたモデルも、元のモデルが提供終了になるまでしか使えません。
④自前のモデル:多くの会社には要らない
モデルそのものを作るには、大量のデータと計算設備、専門の人材が要ります。この難しさを直接述べた公式の資料は取れていないため、ここは筆者の整理です。前の節で見たように、ガイドラインでは、モデルを作る事業者(AI開発者)と、組み込んで提供する事業者(AI提供者)が分けられています。自社の業務に使う道具づくりなら、多くの場合、前者になる必要はありません。
使うモデルの選び方:外部のAPI・クラウド経由・オープンなモデル
作り方の次に決めるのが、どのモデルを、どこで動かすかです。
3つの置き場所の比較
3つの置き場所を、次のように整理します(筆者の整理。確かめることの欄は、この後に各社の公式な文書を引いて説明します)。
| 置き場所 | 内容 | 良い点 | 確かめること |
|---|---|---|---|
| モデル提供元のAPI | OpenAIなどの提供元が動かすモデルを、インターネット越しに呼び出す | 始めやすい | データの扱い、提供終了の予定 |
| クラウドの事業者経由 | Amazon・Microsoft・Googleなどのクラウドの仕組みから呼び出す | 既存のクラウドの契約・管理に乗せやすい | データの扱い、提供終了の日付(提供元と別のことがある) |
| オープンなモデルを自社で動かす | 公開されているモデルを、自社の環境で動かす | データを自社の中に置ける | ライセンスの条件、動かす設備と運用の手間 |
送ったデータの扱いを、公式の文書で確かめる
提供元によって、送ったデータの扱いは違います。次は、各社の公式な文書にある書き方です。
- OpenAI(API):データの扱いのページに、2023年3月1日以降、APIに送ったデータはOpenAIのモデルの学習や改善に使われないと書かれています。不正利用の監視のための記録は、既定で最長30日保存されるとも書かれています
- Amazon Bedrock:データ保護のページに、モデルの提供元は利用者のプロンプトや応答にアクセスできないと書かれています
- Microsoft(Foundry):データのプライバシーのページに、プロンプトや応答、学習データは、許可や指示なしに基盤モデルの学習に使われないと書かれています
- Google Cloud(Vertex AI):データガバナンスのページに、事前の許可や指示なしに、AIモデルの学習や追加学習にデータを使わないと書かれています
条件は契約やサービスの種類で変わるため、使うサービスの最新の文書で、学習に使われるか、記録がどれだけ残るかを確かめてください。個人情報を含む入力をする場合の考え方は、後の「気をつけたいこと」で扱います。
オープンなモデルにも、使い方の条件がある
オープンに公開されているモデルは、自由に使えるとは限りません。たとえばMetaのLlama 3.1のライセンスは、モデルや、それを使った製品・サービスを提供する場合に、関連するサイトや製品などへ「Built with Llama」と目立つように表示することを求めています。また、前の暦月の月間利用者が7億人を超える場合は、Metaに許諾を求める必要があるとしています。これは Llama 3.1 の条項の例で、ほかのモデルや新しい版では条件が違う可能性があるため、使う版のライセンスを自分で読む必要があります。
モデルの提供終了に備える
使っているモデルは、いつか提供が終わります。各社の公式な文書では、次のように決まっています。
- OpenAI:提供終了のページによると、一般提供のモデルは、提供終了の少なくとも6か月前に告知されます
- Anthropic:モデルの提供終了のページによると、公開されたモデルは、廃止の少なくとも60日前に告知されます。Amazon BedrockやGoogle Cloud経由では、それぞれが独自の廃止日を決めます
- Microsoft(Foundry):モデルの提供終了の資料によると、一般提供から18か月で推論が止まり、410 Gone が返ります
- Amazon Bedrock:モデルのライフサイクルのページによると、提供終了後は自動では移行されません
備えとして、使うモデルの名前を1か所の設定にまとめておくこと、評価用の問いを残しておいて、別のモデルに替えたときに同じ問いで測り直せるようにすること、が挙げられます。
生成AI開発の品質を確かめる設計:評価・ハルシネーション・出力の形・入力の安全
生成AIは、同じ問いでも答えが変わり、もっともらしい誤りも出します。そのため、作る前に「どう確かめるか」を決めておくことが、通常のシステム開発以上に大事になります。
評価用の問いを先に作る
OpenAIの評価(evals)のガイドは、期待に対してアプリがどれだけ動くかを把握するために、評価を書くことを挙げています。Anthropicの評価の設計のページは、評価を実際の使われ方に近い分布で作り、例外的なケースも入れるよう述べています。
実際には、次のような問いを集めます(筆者の整理)。
- 実際の業務で来る質問や書類(できれば現場の担当者が選んだもの)
- 答えられない問い、無関係な問い、長すぎる入力などの、例外的なもの
- 答えてはいけない問い(個人情報を聞き出す、社内の規則に反するなど)
モデルを替えたとき、指示文を直したときに、同じ問いで測り直すと、良くなったのか悪くなったのかが分かります。
ハルシネーションは減らせるが、なくならない
もっともらしい誤りは、国際的にもリスクとして扱われています。OWASPは、LLMがもっともらしい誤情報を出すことをリスクの一つ(LLM09)に挙げています。NISTの生成AIのリスク管理の資料(AI 600-1)は、これを「confabulation」と呼び、誤った内容や偽りの内容(いわゆるハルシネーション)と説明しています。
対策としてAnthropicのハルシネーションを減らす方法は、分からないときは分からないと答えてよいと、あらかじめ明示することを挙げています。ただし同じページは、これらの方法で大きく減らせても、完全にはなくならないと述べています。重要な答えは、人が確かめる前提で作る必要があります。
出力の形を決めて、プログラムで確かめる
答えを別のシステムに渡すなら、出力の形を決めます。OpenAIの構造化出力のガイドは、指定したJSONの形式(スキーマ)に必ず従った応答を出させる機能を説明しています。OWASPのプロンプトインジェクションのページも、出力の形式を明確に決め、決まった形に従っているかをプログラムで確かめることを、対策の一つに挙げています。
入力の安全:プロンプトインジェクションとガードレール
プロンプトインジェクションは、入力された文章によって、AIの動きを意図しない形に変えられてしまう問題です。OWASPは、LLMの性質上、これを完全に防ぐ確実な方法があるかは分からないとしています。そのため、一つの対策に頼らず、被害を小さくする対策を重ねることが前提になります。
具体的には、次のような対策が公式の文書にあります。
- 利用者の入力を、軽いモデルで事前に審査してから、本体に渡す(Anthropicのジェイルブレイク対策のページ)
- 公開の前に、わざと攻撃の指示を混ぜた文書・メール・ツールの出力で試し、防げるかを確かめる(同じページ。NISTの資料も、想定外の失敗を見つけるためのレッドチーム演習を勧めています)
- 権限の大きい操作は、AIが勝手に実行せず、人の承認を挟む(OWASPのプロンプトインジェクションのページ)
総務省・経産省のAI事業者ガイドライン(第1.2版)も、AI提供者に、不適切な出力などのリスクを減らす方法として、ガードレール技術などを検討することを求めています。
個人情報・機密を入力するとき
個人情報保護委員会の生成AIサービスの利用に関する注意喚起(2023年6月2日)は、個人データを含むプロンプトを入力する場合には、そのサービスの提供事業者が、個人データを機械学習に利用しないことなどを十分に確認することを求めています。注意喚起は、本人の同意などがないまま、応答の出力以外の目的で個人データを扱うと、個人情報保護法に違反することになる可能性があるとも述べています。OWASPの機微な情報の漏えい(LLM02)のページも、入力を厳しく検証し、機微なデータが入らないよう検出・除去することを挙げています。
生成AI開発の費用の決まり方と、進め方
費用を決める3つの要因
生成AIのAPIの料金は、モデルの種類や提供元で違います。ここでは、AnthropicのAPIを例に、仕組みを見ます(他社の課金の仕組みは、それぞれの公式ページで確かめてください)。Anthropicの料金のページは、料金は、モデルに送る入力のトークン数(ツールの定義を含む)と、モデルが返す出力のトークン数で決まるとしています。トークンとは、文章を数える単位のことです。なお、同じページの料金は米ドル表示です。この記事では、金額は書きません。
費用を左右する要因は、次の3つです(筆者の整理)。
- 送る文章の長さ:RAGで資料を多く渡すほど、また指示文が長いほど、1回あたりの入力が増える
- 使う回数:何人が、1日に何回使うか
- モデルの種類:モデルごとに料金が違う(各社の料金表で確かめる)
費用を抑える仕組みと、利用量の上限
Anthropicの文書には、費用を抑える仕組みがあります。
- バッチ処理:急がない大量の処理を、あとでまとめて処理する形にすると、標準のAPIの50%の料金になります
- プロンプトキャッシュ:保存した内容を再利用すると、入力料金の10%になります(同じ料金のページ。モデルによって率は異なります)
また、使える量には上限があります。Anthropicの利用量の上限のページは、1分あたりのリクエスト数・入力トークン数・出力トークン数で上限が測られるとしています。多くの人が同時に使う道具では、上限に達したときの動き(待たせる、断る、別の手段に切り替える)も設計に入れます。
導入の費用全体の考え方は、AI導入の費用の記事に整理しています。
国内の調査で見る、AI導入・運用の課題
国内の調査から、課題として挙がっているものを2つ紹介します。調査の対象や時期が違うため、数字どうしを比べることはできません。
- IPAのDX動向2026(調査期間は2026年4月中旬〜6月中旬。日本標準産業分類の19業種の企業の経営層またはICT関連の部門が対象で、有効回答は1,799社)では、AI導入・運用上の課題として「専門人材が不足している」が50.1%で最も高くなっています
- 同じIPAの調査では、生成AIを「導入している」と答えた割合が、2024年度の22.6%から2025年度の44.0%に増えています(同じ調査の対象内での、年度どうしの比較です)
- 中小機構の調査(2026年3月)(調査期間は令和7年11月17日〜12月12日。全国の中小企業10,000社が対象)では、AIの導入率が20.4%でした
自社に人材がいない場合でも、使う範囲を絞れば進められます。ただし、自社の業務を知る担当者の関わりは外せません。
体制:自社の業務の担当者の関わりは外せない
経済産業省のAI導入ガイドブック(製造業の需要予測)は、どの体制で進めるにしても、AIのプロジェクトには自社の業務の担当者の関与が必須だと述べています。これは生成AIが広まる前の、需要予測を題材にした資料ですが、「うまくいったかの基準は、業務を知る人にしか決められない」という点は、生成AIの道具づくりにも当てはまると考えられます(筆者の見方)。
評価用の問いを集める、答えの良し悪しを判断する、といった役割を、開発する側にだけ任せないことが大切です。
進め方の4段階
進め方は、次のように区切るのが無理がありません(筆者の整理)。
| 段階 | やること | 終わりの条件 |
|---|---|---|
| ①課題を決める | 1つの業務に絞り、今の手間と、AIに任せる範囲を書く | 「うまくいった」の基準が書けている |
| ②小さく試す | プロンプトとRAGで試作し、評価用の問いで測る | 基準に届くか、届かない理由が分かる |
| ③安全を整える | 入力の審査、出力の確認、権限、記録を作る | 攻撃を混ぜた試験に耐える |
| ④運用して直す | 使われ方を見て、問いを足し、モデルの更新に備える | 測り直しの手順がある |
生成AI開発で気をつけたいことと、よくある失敗
開発の作業に生成AIを使うときの注意
プログラムの作成に生成AIを使う場合も、確認は必要です。GitHub Copilotの公式の注意書きは、提案を受け入れる前に、利用者が内容を確認して検証する責任があるとしています。
開発の現場でAIを使うことの効果については、DORAの2025年の報告が、AIの主な役割は「増幅器」で、組織の持つ強みも弱みも大きくすると述べています。AIを入れれば成果が出るのではなく、確認やテストの仕組みが整っている組織ほど生かせる、という読み方ができます。
開発者の調査にも、同じ傾向が出ています。Stack Overflowの2025年の調査は、177か国から49,009件の回答を分析したものです。ただし回答者の募集は主に同社自身の経路で行われたため、開発者全体の姿とは言えません。同じ調査の結果のページでは、AI利用の不満の最大の項目は、「ほぼ正しいが完全ではない回答」(66%)でした。
よくある失敗と誤解
評価なしで作り始める
見た目の良い答えが出ると、うまくいったように感じます。しかし、少数の例で判断すると、例外的な入力で崩れます。評価用の問いを先に作ります。
最初から追加学習やモデル作りを考える
資料に答えさせたいだけなら、RAGで足ります。追加学習やモデル作りは、手間が大きく、提供元の方針の影響も受けます。
データの扱いを確かめずに送る
個人情報や機密を、学習に使われるかを確かめないまま送ると、後から取り返せません。使う前に、各社の公式な文書で確かめます。
モデルの提供終了を見落とす
一度作った道具が、ある日、動かなくなります。使うモデルの提供終了の予定を、定期的に見ます。
作る前のチェックリスト
- 何の業務を、どこまで任せるのかを1文で書いた
- 外に出してよいデータと、出してはいけないデータを分けた
- プロンプトで試し、足りないと分かってからRAGや追加学習を検討する順にした
- 評価用の問い(通常のもの・例外的なもの・答えてはいけないもの)を集めた
- 使うサービスの、データの扱いと記録の残し方を公式の文書で確かめた
- 重要な答えと、取り消しにくい操作は、人が確かめる形にした
- 攻撃の指示を混ぜた文書などで、公開前に試した
- 使うモデルの提供終了の予定と、替えるときの手順を確かめた
- 利用量の上限に達したときの動きを決めた
生成AI開発についてよくある質問(FAQ)
Q1. 生成AI開発には、自社でモデルを作る必要がありますか?
多くの場合、必要ありません。ガイドラインはモデルを作る「AI開発者」と、組み込んで提供する「AI提供者」を分けており、社内の道具づくりは後者の仕事です。まずは既存のモデルを使い、プロンプトとRAGで試すのが基本です。
Q2. 社内の資料に答えさせるには、追加学習が必要ですか?
最初は不要です。AWSの資料は、自分の資料を参照して答える仕組みはRAGから始めるよう勧めています。追加学習は、要約のような別の作業を安定させたいときに検討します。
Q3. オープンなモデルを使えば、費用も制限もありませんか?
そうとは限りません。ライセンスに条件があり、動かす設備や運用の手間もかかります。たとえばLlama 3.1のライセンスには、表示の義務などがあります。使うモデルの版のライセンスを読んでください。
Q4. ハルシネーションは、完全に防げますか?
防げません。Anthropicの文書も、対策で大きく減らせるが、完全にはなくならないとしています。重要な答えは、人が確かめる前提で作ります。
Q5. 費用や期間の目安はありますか?
公的な相場は見当たらないため、この記事では金額や期間を書いていません。費用は、送る文章の長さ・使う回数・モデルの種類で決まります。まず小さく試して、実際の使い方で測るのが確実です。
Q6. 個人情報を含む資料を、生成AIに入力してもよいですか?
使うサービスの条件と、自社の個人情報の利用目的によります。個人情報保護委員会は、事業者が個人データを機械学習に利用しないことなどを十分に確認するよう求めています。確認できない間は、個人情報を入れない形で試します。
Q7. 使っているモデルが提供終了になったら、どうなりますか?
終了後は、そのモデルへの依頼ができなくなり、別のモデルへ自分で移す必要があります。事前の告知の長さは、OpenAIは6か月以上、Anthropicは60日以上と、会社で違います。評価用の問いを残しておくと、替えたときに測り直せます。
まとめ:生成AI開発は、「作り方の順番」と「確かめ方」を先に決める
要点サマリー
- 生成AI開発には、モデルを作る・既存のモデルで道具を作る・開発作業に使う、の3つの意味がある。多くの会社に関係するのは2つ目
- 作り方は、プロンプト→RAG→追加学習→自前のモデルの順に、手間の少ないものから試す(筆者の整理)
- モデルの置き場所(提供元のAPI・クラウド経由・オープンなモデル)で、データの扱い・提供終了・ライセンスの確認先が変わる
- 評価用の問いを先に作り、ハルシネーションは「減らせるがなくならない」前提で、人の確認とガードレールを重ねる
- 費用は、送る文章の長さ・使う回数・モデルの種類で決まる。進め方は、課題を絞って小さく試し、安全を整えてから運用する
読者タイプ別の次の行動
- 経営者・事業の責任者:生成AIに任せたい業務を1つ選び、今かかっている手間と、外に出せないデータを書き出す
- 情報システムの担当者:使いたいサービスの、データの扱い・記録の残し方・提供終了の予定を、公式の文書で確かめる
- 開発会社に依頼する立場の方:作り方の順番(プロンプト・RAG・追加学習)と、評価用の問い、安全の対策を、提案の中で確かめる
さらに確かめておきたい観点
- 使うモデルの最新の料金・上限・提供終了の日付(各社の公式ページ)
- 自社の個人情報の利用目的と、AIに入力してよい範囲
- 評価用の問いを誰が作り、どの頻度で測り直すか
- AI事業者ガイドラインのうち、自社が「AI開発者」「AI提供者」「AI利用者」のどれに当たるか



