AIシステム開発とは？業務システムへの組み込み方と、開発工程での生成AIの使い方を解説

「今使っている業務のシステムにAIを入れたい」「開発会社から、AIを使えば開発が速くなると言われた」。AIシステム開発という言葉を調べている方の多くは、このどちらかの場面にいるのではないでしょうか。ただ、同じ言葉で違うことを指している記事も多く、何から考えればよいのかが分かりにくい状態です。

結論から言うと、AIシステム開発とは、業務のシステムにAIの機能を組み込んで使える形にすること、または、システム開発の作業そのものに生成AIを使うことです。 前者では、AIそのものの性能より「今あるシステムやデータとのつなぎ方」が結果を左右します。後者では、AIが作った設計書やプログラムを人が確かめる工程を省けません。

この記事では、国のガイドラインや各社の公式ドキュメントをもとに、次のことを整理します。情報は2026年10月時点のものです。

• AIシステム開発の2つの意味と、ふつうのシステム開発との違い
• 今ある業務システムにAIを組み込む3つのつなぎ方と、閲覧権限・操作の権限・利用量の上限の考え方
• 要件定義からテスト・保守まで、開発の工程ごとの生成AIの使い方と、人が確かめること
• 進め方、品質の確かめ方、費用と期間が決まる要因
• 情報の扱い・安全面の注意と、よくある失敗

AIシステム開発とは？2つの意味と、ふつうのシステム開発との違い

AIシステム開発の2つの意味：AIを組み込む・AIで作る

「AIシステム開発」は、次の2つの意味で使われています。

• AIを組み込んだシステムを作る：販売管理・顧客管理・社内の文書の保管場所など、業務で使うシステムに、文章を作る・資料から答えを探す・数字を予測する・書類を読み取るといったAIの機能を加えることです。
• AIを使ってシステムを作る：要件の整理、設計書、プログラム、テストといった開発の作業を、生成AIに手伝わせることです。できあがるシステムにAIが入っているとは限りません。

前者について、総務省・経済産業省のAI事業者ガイドライン（第1.2版）（2026年3月公表）は、AIシステムをアプリや既存のシステム、業務の流れに組み込んで提供する事業者を「AI提供者」と呼んでいます。その役割の例として挙げているのが「既存業務システムとの統合」です。AIを作ることと、AIを業務の仕組みにつなぐことは、別の仕事として整理されているわけです。

この記事は、前半で「組み込む」側、後半で「AIで作る」側を説明します。自社が今どちらを考えているのかを先に分けておくと、話がかみ合いやすくなります。

AIを組み込んだ業務システムでよくある形

業務システムにAIを組み込む例を、よく見られる形で分けると次のとおりです（筆者の整理）。

• 社内の文書に答える：規程・マニュアル・過去の記録を読ませて、質問に答えたり、該当する箇所を示したりする
• 書類を読み取って入力する：請求書・注文書・見積もり依頼書を読み取り、項目を業務システムに入れる下書きを作る
• データについて質問できるようにする：売上や在庫のデータに、ふだんの言葉で質問して集計や傾向を見る
• 予測・判定する：需要の予測、異常の検知、検査での見分け
• AIに操作を任せる：問い合わせの内容から、予約や登録などの操作をAIが呼び出す

どの形でも、AIの部分は全体の一部です。データをどこから取り、誰に見せ、結果をどの画面に戻すかという「周り」を設計する量が多くなります。

ふつうのシステム開発との違い

ふつうの業務システムは、「この入力なら、この結果を返す」という決まりを人が書き、そのとおりに動くかを確かめます。AIを組み込むと、その一部をAIの判断に任せることになり、次の3つの違いが出てきます。

同じ入力でも、答えが毎回同じとは限らない

生成AIは、同じ質問にも少しずつ違う答えを返すことがあります。総務省の令和6年版 情報通信白書は、生成AIが事実に基づかない誤った情報をもっともらしく作ることがあり、これを「ハルシネーション」と呼ぶと説明しています。そのため、AIの答えをそのまま次の処理に流すのではなく、人が確かめる場面や、決まった形に合っているかを機械で確かめる仕組みを入れておきます。

データと権限の設計が中心になる

AIに何を読ませ、誰の質問にどこまで答えさせるかを決めないと、使える仕組みになりません。ふつうの開発でも権限の設計はしますが、AIは読ませた資料の中身を文章にして返すため、見せてよい範囲の決め方がより重要になります。この点は、次の章の「閲覧権限を守る」で詳しく説明します。

作った後も見直しが続く

業務の内容や資料が変われば、AIの答えの質も変わります。また、外部の生成AIを使う場合、元になるAIのモデルは提供元の予定で古いものから順に提供を終えます。OpenAIのモデルの提供終了の案内も、同社のモデルに頼るソフトウェアは、動き続けるために時々更新が要ることがあると書いています。作って終わりではなく、答えの質を定期的に確かめ、直し続ける前提で計画します。

AIシステム開発・AI開発・AIアプリ開発の違い

似た言葉との違いを表にまとめます（言葉の使い分けは筆者の整理で、決まった定義があるわけではありません）。

AIの仕組みを作るところから考えたい場合は、AI開発の進め方と外注・内製の選び方で、PoCや契約まで含めて整理しています。

今ある業務システムにAIを組み込む方法

業務システムにAIをつなぐ3つの方法

今あるシステムを作り直さなくても、AIを足す方法はあります。よく使われる形を、手間の小さい順に3つに分けます（分け方は筆者の整理）。

方法1：既製のAI機能を使う

使っている業務ソフトやグループウェアに用意されたAI機能を有効にしたり、画面の操作で組み立てる道具を使ったりする方法です。たとえばMicrosoftのCopilot Studioは、AIを使った仕組みを画面の操作中心で作る「ローコード」の道具として案内されています。作る量は小さい一方、できることは道具の機能の範囲に限られます。

方法2：APIで横につなぐ

今のシステムはそのままにして、外部の生成AIを、プログラムから呼び出す口（API）でつなぐ方法です。社内の資料を探して答えに使う仕組み（RAG）や、AIからほかの機能を呼び出す仕組みを、この形で作ることが多くなります。Amazon Web ServicesのRAGの解説は、RAGを、AIが答えを作る前に、学習したデータの外にある信頼できる情報源を参照させる方法と説明しています。

方法3：データをまとめる場所を作ってからつなぐ

販売・在庫・顧客などのデータが別々のシステムに散らばっている場合、まずそれを1か所に集め、形をそろえてからAIをつなぐ方法です。作る量は大きくなりますが、データについて自由に質問したり、予測に使ったりしやすくなります。

3つのつなぎ方の比較表と選ぶ順番

選ぶ順番の目安は、次のとおりです。

1. 使っている道具に、目的に合うAI機能があるかを先に確かめる
2. 無ければ、1つの業務に絞ってAPIでつなぎ、小さく試す
3. 複数のデータを組み合わせる必要が見えてから、データをまとめる場所を作る

いきなり3から始めると、AIで何をするかが決まる前にデータの整理だけで時間がかかりがちです。

社内の文書に答えさせるときは、閲覧権限を守る

社内の文書をAIに読ませる仕組みで、最初に決めたいのが「誰の質問に、どの文書まで使って答えるか」です。全部の文書を1つにまとめて読ませると、ふだんは開けない人事や取引の文書の中身を、AIが答えの中で話してしまうおそれがあります。

既製の仕組みには、この点を最初から組み込んでいるものがあります。MicrosoftはMicrosoft 365 Copilotのデータとプライバシーの説明で、Copilotは利用者が少なくとも閲覧の権限を持つ組織のデータだけを表示する、としています。自分でAPIを使って作る場合も、検索の段階で利用者の権限に合わせて文書を絞り込む作りが用意されています。たとえばMicrosoftの検索サービスAzure AI Searchは、文書ごとの閲覧権限の反映に対応していると説明しています。

作り方は道具によって違いますが、考え方は共通です。

• 今の業務システムやファイルの置き場所で決まっている閲覧権限を、AIの検索にも引き継ぐ
• 権限の情報が無い文書は、読ませる前に見せてよい範囲を決める
• 試すときは、権限の違う複数の利用者で同じ質問をして、答えが変わるかを確かめる

AIに操作を任せるときは、権限を小さくする

AIに文章を返させるだけでなく、登録・予約・送信などの操作を呼び出させることもできます。GoogleのGemini APIの関数呼び出しの説明は、この仕組みでAIを外部の道具やAPIにつなげると説明しています。また、AIと外部のシステムをつなぐ共通のやり方として、MCP（Model Context Protocol）という公開の標準も広がっています。仕組みの詳しい説明は、MCPとは何かを解説した記事にまとめています。

便利な半面、任せる範囲を広げすぎると事故につながります。OWASPは、LLMアプリケーションの主なリスクの1つに過剰な権限（Excessive Agency）を挙げ、AIの思わぬ出力や、操られた出力をきっかけに、害のある操作が実行されてしまう弱点だと説明しています。対策の1つとして、影響の大きい操作は、実行する前に人が承認する形にすることを挙げています。

業務システムにつなぐときは、次のように範囲を決めておきます。

• 読むだけの操作（在庫を調べる、予定を見る）から始める
• 書き換える操作（登録、変更）は、下書きをAIが作り、確定は人が押す
• 取り消しにくい操作（送信、支払い、削除）は、AIに任せない
• AIが使う権限は、その仕事に必要な最小限にし、操作した記録を残す

利用量の上限と、AIが止まったときの備え

外部の生成AIは、使える量に上限があります。OpenAIの利用量の上限の説明は、一時的な上限を超えた要求にはエラーを返すとしています。Anthropicの利用量の上限の説明も、上限を超えるとどの上限を超えたかを示すエラーが返ると書いています。

業務システムは止まると困るので、AIの部分が使えないときの動きを先に決めておきます。

• 上限に達したときは、少し待ってからやり直す仕組みにする
• AIが答えられないときは、ふつうの検索や、人への引き継ぎに切り替える
• 月末など利用が集中する時期を見込んで、上限と費用を確かめておく
• AIの答えを待つ間も、画面が固まらないようにする

古い仕組みと、散らばったデータが壁になる

AIをつなごうとして最初にぶつかるのが、今のシステムからデータを取り出しにくいという問題です。経済産業省のDXレポート（2018年、国立国会図書館の保存版）は、古く複雑になり、中身が分からなくなった既存のシステムの問題を取り上げています。そうしたシステムのもとではデータを使いきれず、新しいデジタル技術を入れても効果が限られてしまう、という指摘です。

この傾向は今も続いています。IPAのDX動向2026では、データの整備・管理の課題として最も多かったのは「人材の確保が難しい」（51.2%）でした。次いで、データの形式をそろえる標準化の難しさが36.8%、管理のための仕組みが整っていないことが32.6%となっています。AIの前に、データの形と置き場所をそろえる作業が要る会社が多いということです。

筆者が関わった2つの例

筆者（WebLeben）が関わり、すでに事例として公開している開発のうち、既存のデータとAIのつなぎ方に関わる2つを紹介します。どちらも小さな規模の例です。

S社（製造業）：データを外に送らない形で、似た案件を探す

見積もり依頼書のPDFを読み取り、過去の似た案件を探す仕組みをデモ版として作りました。この仕組みはAI開発事例100選でも紹介しているとおり、ブラウザの中だけで動き、データを外に送りません。生成AIなどの外部のAIは、まだつないでいません。

この例で先に確かめたのは、AIを入れる前に「データの形をそろえれば、探し方として役に立つか」でした。外部のAIをつなぐかどうかは、その効果と、社外にデータを出す条件を確かめてから決める、という順番です。

T店（食品の製造販売）：レジのデータを生成AIとつなぐ土台

レジの売上データを書き出してクラウドに保存し、生成AI（ChatGPT）とつないで、保存したデータについて質問できる形にしました。レジのシステムそのものには手を入れず、データを書き出して別の場所に置き、そこにAIをつなぐ形です。この記事の分け方でいえば、方法2と方法3の間にあたります。

2つの例から言えるのは、今のシステムを作り直す前に、「データをどこから、どの形で取り出せるか」を確かめるのが出発点になる、ということです。

システム開発の工程で生成AIを使う方法

ここからは、もう1つの意味である「AIを使ってシステムを作る」側を説明します。自社で開発する場合だけでなく、開発会社に依頼する場合にも、どの工程でAIが使われ、何を人が確かめているのかを知っておくと、見積もりや品質の話がしやすくなります。

工程ごとの使いどころと、人が確かめること

システム開発の主な工程ごとに、生成AIに任せやすいことと、人が確かめることを整理します（筆者の整理）。

要件定義・設計での使い方

要件定義と設計では、文章を扱う作業が多く、生成AIの得意な要約や整理を使えます。打ち合わせの記録を要約して要望の一覧にする、設計書の書き方をそろえる、確認の抜けがないかを観点の一覧と照らす、といった使い方です。

ただし、AIは自社の業務の事情を知りません。AIが作った要件の一覧は「抜けを見つけるための材料」として使い、最終的な判断は業務を知る人が行います。総務省・経済産業省のAI事業者ガイドライン（第1.2版）別添も、この点に触れています。生成AIをシステム開発に使うと、ふだんの言葉がそのままプログラムや設計の情報に変わるため、AIに渡す情報の確かさがシステムの安全性に直結するおそれがある、という指摘です。要件や設計の材料として渡す文書は、最新で正しいものに絞ります。

実装・コードレビューでの使い方

プログラムを書く工程は、生成AIの使い方がいちばん進んでいる分野です。入力の途中で続きを提案する道具や、指示した変更をまとめて作る道具があります。GoogleのGemini Code Assistの説明は、プログラムの作成のほか、単体テストの作成やデバッグの手助けにも使えると案内しています。

AIが書いたプログラムが、公開されている他人のプログラムとそっくりになる心配もあります。GitHubの公開コードとの一致を調べる仕組みの説明によると、Copilotは提案が公開されているコードと一致するかを確かめており、一致はふつう提案全体の1%未満だとしています。少ないとはいえゼロではないため、一致したときに知らせる設定や、ライセンスの扱いを、開発の決まりとして決めておきます。

テスト・運用保守での使い方

テストの工程では、テストの項目やテスト用のデータ、テストのプログラムの下書きをAIに作らせられます。ただし、GitHubのインライン提案の責任ある使い方は、AIが作ったテストはすべての場合を網羅しているとは限らないので、やはり人が確かめる必要があるとしています。業務上大事な場合（締め日、端数、権限の違う利用者など）は、人がテストの項目に入れておきます。

運用・保守では、エラーの記録を読み解かせたり、古いプログラムの中身を説明させたりする使い方があります。一方で、先のガイドラインの別添は、プログラムを作るAIを使うと、作った人の意図やプログラムの組み立てがつかみにくくなり、保守や更新が難しくなるおそれにも触れています。AIに書かせた部分ほど、なぜそう書いたかの説明を設計書や記録に残しておくと、後で直す人が困りません。

AIが書いたプログラムを、人が確かめる理由

AIの道具を提供している会社自身が、人の確認を前提にしています。GitHubはCopilotの責任ある使い方の説明で、提案されたプログラムは文法として正しくても安全とは限らないとし、作られたプログラムは常に十分に確かめてテストするよう求めています。同じGemini Code Assistの説明も、出力はすべて使う前に確かめるよう勧めています。

アメリカ国立標準技術研究所（NIST）の生成AIの安全な開発の実践をまとめた文書（SP 800-218A）（2024年7月）も、人が書いたプログラムとAIが作ったプログラムを区別していません。すべてのプログラムを、使う前に弱点などがないか評価すべきだという前提に立っています。AIが書いたかどうかにかかわらず、レビューとテストの手順は同じように通す、と考えるのが基本です。

開発で生成AIを使っている割合

IPAのDX動向2026では、AIの使い道として「プログラムコードやシステム開発支援」を挙げた割合が、情報通信業では76.3%と、ほかの業種を大きく上回りました（AIを導入・試験利用・検討している企業が対象）。システムを作る側の会社では、AIの利用が本業である開発の仕事に広がっていることが分かります。

一方、システムを発注する側も含めた見方では、まだこれからの段階です。IPAのソフトウェアモダナイゼーション委員会の報告書（2026年3月）は、同機構のソフトウェア動向調査をもとに、開発にAIを導入している企業は現時点では一部にとどまるとしています。

海外の調査では、使う人の広がりと、品質への影響の両方が示されています。Google Cloudの2025年のDORAレポートの発表によると、回答者の90%が仕事でAIを使っている一方、30%はAIが作ったプログラムをほとんど、または全く信頼していないと答えました。また、AIの導入は、ソフトウェアを安定して届けることと引き続き負の関係にあるとしています。同じ発表は、自動のテストや変更の管理といった仕組みが強くないまま変更の量だけが増えると、不安定になりやすいと説明しています。

AIシステム開発の進め方と、品質・体制・費用の考え方

AIシステム開発の4つの段階

AIを使う開発は、作る前に「うまくいくか」が分からない部分を含みます。経済産業省のAI・データの利用に関する契約ガイドライン（AI編）は、こうした開発のために、アセスメント・PoC・開発・追加学習の4つの段階で進める「探索的段階型」の進め方を示しています。途中で結果を見て、次の段階に進まない選択ができるのが特徴です。

この4段階は、学習させてAIを作る開発を念頭に置いたものですが、既存のシステムに生成AIをつなぐ場合も、段階を分けて確かめる考え方はそのまま使えます。生成AIをつなぐ場合に置き換えると、次のようになります（置き換えは筆者の整理）。

品質の確かめ方：評価用の問いと記録を用意する

AIを組み込んだシステムは、「動くかどうか」だけでなく「答えがどのくらい正しいか」を確かめる必要があります。Anthropicの評価の作り方の解説も、生成AIを使ったアプリづくりは、成功の基準をはっきり決め、それを測る評価を設計することから始まると書いています。

実務では、次のように準備するのが一般的です。

• 評価用の問いを作る：実際の業務で来る質問や書類を数十件集め、期待する答えを人が用意しておく
• 基準を決める：「正しい答えの割合」「答えられないときに、分からないと返せるか」「見せてはいけない情報を出さないか」などを、数字か合否で決める
• 変えるたびに測り直す：読ませる資料、指示の文、元になるモデルを変えたら、同じ問いで測り直す
• 本番の記録を見る：使われた質問と答えを記録し、うまく答えられなかったものを評価用の問いに足していく

品質の考え方を体系的に知りたい場合は、公的なガイドラインも参考になります。産業技術総合研究所の機械学習品質マネジメントガイドラインは、企業が自ら作ったAIを使うシステムの品質を測って高め、AIの誤った判断による事故や経済的な損失を減らす助けになることを目的にしています。

社内に要る役割：作る人だけでなく、決める人と見直す人

AIシステム開発では、プログラムを書く人だけでなく、業務を知っている人の関わりが欠かせません。IPAのDX動向2026（2026年4〜6月に調査、1,799社が回答）では、AIの導入・運用の課題として「専門人材が不足している」が50.1%で最も多くなっています。

社内に専門の技術者がいなくても、次の役割は自社で持っておくと進めやすくなります（筆者の整理）。

• 決める人：どの業務を対象にし、どこまでAIに任せるかを決める
• 業務を知る人：評価用の問いと期待する答えを用意し、試したときの答えを判定する
• データと権限を管理する人：読ませる資料の更新と、見せてよい範囲を管理する
• 見直す人：記録を見て、答えの質と使われ方を定期的に確かめる

費用と期間が決まる要因

AIシステム開発の費用や期間について、公的な相場は見当たりません。ここでは、金額ではなく、何によって変わるかを整理します。

AIの利用料は、使った量で決まるのがふつう

外部の生成AIをAPIで使う場合、利用料は主に、AIに送る文字の量と、AIが返す文字の量で決まります。GoogleのGemini APIのトークンの説明も、呼び出し1回の費用は入力と出力のトークン（AIが文字を数える単位）の数で一部が決まると書いています。社内の資料を長く読ませるほど、また利用者が多いほど、利用料は増えます。

開発の費用と期間を左右するもの

• つなぐシステムの数と古さ：外からデータを取り出す口（API）があるか、書き出しが要るか
• データの整い方：形式がそろっているか、最新の資料がどこにあるか
• 権限の細かさ：部署や役職ごとに見せる範囲を分けるか
• 求める答えの質：人が必ず確かめる前提か、そのまま次の処理に使うか
• 運用の体制：資料の更新や評価のやり直しを、誰がどのくらいの頻度で行うか

中小機構の中小企業のAI活用に関する実態調査（令和7年11〜12月に1万社を対象に調査）でも、費用の課題が目立ちます。導入時の課題は「導入にあたっての高コスト」が46.9%、導入後の課題は「ランニングコストが高い」が44.0%で、どちらも最も多くなっています。作るときの費用だけでなく、使い続ける費用まで含めて見積もることが大切です。費用の内訳と相場の考え方は、AI導入の費用の内訳と相場で詳しく整理しています。

AIシステム開発で気をつけたいことと、よくある失敗

情報の扱い：顧客のデータと、設計書・ソースコード

業務システムには、顧客の名前や取引の記録など、個人情報や社外に出せない情報が入っています。個人情報保護委員会の生成AIサービスの利用に関する注意喚起（令和5年6月）は、個人情報を含む指示を生成AIに入力する場合の注意を示しています。利用目的の範囲内かを確かめることと、提供する事業者がそのデータを機械学習に使わないことなどを十分に確かめることです。

APIで使う生成AIは、提供元が「送られたデータを学習に使わない」と定めていることが多いものの、条件はサービスや契約で違います。たとえばOpenAIは、APIのデータの扱いで、2023年3月1日以降APIに送られたデータを自社のモデルの学習に使わないとしつつ、不正利用を見張るための記録は既定で最大30日残すと説明しています。つなぐ前に、使うサービスの条件を公式の文書で確かめ、社内の決まりと合うかを見ておきます。

開発の工程で生成AIを使う場合は、設計書やソースコードも社外に出せない情報です。開発会社に依頼するときは、どの生成AIを、どの契約の条件で使うのかを、先に確かめておくと安心です。

入力で動きを変えられる：プロンプトインジェクション

AIを組み込んだシステムには、ふつうのシステムにはない攻撃があります。セキュリティの非営利団体OWASPのLLMアプリケーションの主なリスクは、利用者の入力によって、AIのふるまいや出力が意図しない形に変えられてしまう弱点を「プロンプトインジェクション」として1番目に挙げています。人の目には見えない形で入れられた指示でも、AIが影響を受けることがあるとしています。

業務システムでは、AIに読ませる文書やメール、取引先から届いた書類にも、こうした指示がまぎれ込むおそれがあります。AIに任せる操作を小さくする、大事な操作の前に人の確認を入れる、という前の章の備えが、ここでも効いてきます。

国のガイドラインと、人の判断を入れること

AIを業務の仕組みに組み込む会社は、AI事業者ガイドラインでいう「AI提供者」にあたることがあります。総務省・経済産業省のAI事業者ガイドライン（第1.2版）は、AIに単独で判断させるだけでなく、適切なタイミングで人間の判断を入れる使い方を検討するよう求めています。また、不正な操作によってAIのふるまいが意図せず変わったり止まったりしないよう、セキュリティを確保することが重要だとしています。

同じガイドラインは、AIの判断を後から確かめられるよう、利用時の入力と出力や判断の根拠などの記録（ログ）を、合理的な範囲で残すことも求めています。どの記録をどのくらいの期間残すかは、事故の原因を調べたり、再発を防いだりするときに役立つかを考えて決めます。このガイドラインは、取引先や利用者に「どう安全に作ったか」を説明するときの物差しとしても使えます。

よくある失敗と誤解

「AIを入れるなら、今のシステムを作り直す必要がある」

作り直さなくても、既製のAI機能を使う、データを書き出して横につなぐ、といった形から始められます。まず1つの業務で効果を確かめ、必要になったところだけ作り込むほうが、無駄が少なくなります。

「社内の文書を読ませれば、誰にでも答えてくれて便利」

閲覧権限を反映しないまま全部の文書を読ませると、見てはいけない人に人事や取引の情報が見えてしまいます。便利さより先に、誰に何を見せるかを決めます。

「AIに書かせたプログラムなら、速くて間違いがない」

AIが書いたプログラムも、人が読み、テストをしてから使う前提です。速く書ける分、確かめる工程を計画に入れておかないと、後で手直しが増えます。

「一度つないだら終わり」

資料は古くなり、元になるAIのモデルも提供が終わります。答えの質を測り直す予定と担当者を、作る前に決めておきます。

チェックリスト：AIシステム開発を始める前に

• AIを「組み込む」のか「開発の作業に使う」のか、どちらの話かを社内でそろえた
• 対象の業務を1つに絞り、今どのくらい手間がかかっているかを書き出した
• AIに読ませるデータと、つなぐシステムの一覧を作った
• 誰に何を見せてよいか（閲覧権限）を決めた
• AIに任せる操作と、人が確かめる操作を分けた
• 使う生成AIの、データの扱い（学習に使うか・記録をどれだけ残すか）を公式の文書で確かめた
• 評価用の問いと、合格の基準を用意した
• AIが止まったとき・上限に達したときの動きを決めた
• 運用で見直す担当者と頻度を決めた

AIシステム開発についてよくある質問（FAQ）

Q1. AIシステム開発には、どのくらいの期間がかかりますか？

対象の業務やつなぐシステムの数で大きく変わるため、決まった目安はありません。参考として、経済産業省のAI導入ガイドブック（製造業の需要予測）（国立国会図書館の保存版）は、検証の工程を2〜3か月程度で進めるのが一般的だとしています。全体を一度に決めず、段階ごとに期間を区切って進めると、見通しを立てやすくなります。

Q2. 今使っているシステムが古くても、AIはつなげますか？

つなげることは多いものの、つなぎ方は変わります。外からデータを取り出す口（API）があれば横につなぎやすく、無い場合は、データを定期的に書き出して別の場所に置き、そこにAIをつなぐ形が考えられます。まず、今のシステムからどんな形でデータを取り出せるかを確かめるところから始めます。

Q3. 社内に詳しい技術者がいなくても、進められますか？

進められますが、業務を知っている人の関わりは欠かせません。同じガイドブックも、どの体制で進めるにしても、自社の業務の担当者がAIのプロジェクトに関わることは必須だとしています。作る作業は外部に任せても、対象の業務を決めること、答えの良し悪しを判定することは、社内で持っておきます。

Q4. 開発会社が生成AIを使うと、費用は安くなりますか？

作業によっては速くなりますが、どのくらい安くなるかの一律の数字は、公的な資料では見当たりません。AIが作った設計書やプログラムを人が確かめる工程は残るためです。見積もりのときに、どの工程で生成AIを使い、確認を誰がどう行うのかを聞いておくと、比べやすくなります。

Q5. 社内の文書をAIに読ませても、情報は漏れませんか？

使うサービスの条件と、作り方によります。提供元が送られたデータを学習に使うかどうか、記録をどれだけ残すかを公式の文書で確かめること、利用者ごとの閲覧権限をAIの答えにも反映させることの2つが大切です。

Q6. AIに業務システムを直接操作させても大丈夫ですか？

最初は、読むだけ・下書きを作るだけの範囲から始めるのが安全です。登録・送信・削除のように取り消しにくい操作は、AIに任せるとしても、実行の前に人が確かめる形にします。AIに渡す権限は、その仕事に必要な最小限にとどめます。

Q7. 使っているAIのモデルが提供終了になったら、どうなりますか？

提供が終わったモデルは使えなくなります。Anthropicのモデルの提供終了の案内も、提供を終えたモデルへの依頼は失敗すると書いています。提供元の終了予定を定期的に確かめ、新しいモデルに切り替えたら、評価用の問いで答えの質を測り直します。

まとめ：AIシステム開発は、つなぎ方と人の確認を先に決める

要点サマリー

• AIシステム開発には、「業務システムにAIを組み込む」と「開発の作業に生成AIを使う」の2つの意味がある
• 組み込むときは、AIの性能より、データのつなぎ方・閲覧権限・AIに任せる操作の範囲・止まったときの備えが結果を左右する
• 今あるシステムは作り直さなくても、既製のAI機能や、横につなぐ形から始められる
• 開発の工程で生成AIを使うときは、AIが作ったものを人が確かめ、テストする工程を必ず残す
• 段階を区切って小さく試し、評価用の問いで答えの質を測りながら広げる

読者タイプ別の次の行動

• 経営者・事業の責任者：AIで軽くしたい業務を1つ選び、今かかっている手間と、AIに読ませたいデータを書き出す
• 情報システムの担当者：今のシステムからデータを取り出せる口（API・書き出し）と、閲覧権限の仕組みを一覧にする
• 開発チーム・開発会社に依頼する立場の方：どの工程で生成AIを使うか、誰がどう確かめるか、ソースコードをどの条件のAIに渡すかを決める

さらに確かめておきたい観点

• 使う生成AIサービスのデータの扱いと、終了予定のモデル
• 自社の個人情報の利用目的と、AIに入力してよい範囲
• 評価用の問いを誰が作り、どの頻度で測り直すか
• AI事業者ガイドラインのうち、自社が「AI提供者」「AI利用者」のどちらにあたるか