情報通信業では、生成AIを使ったコード作成、文書作成、情報検索が急速に広がっています。

▶ あわせて読みたい：AIエージェント開発の新潮流とは？プロンプトからループ・グラフ・ハーネス設計へ

エンジニアがコードのたたき台を作る、営業担当者が提案書の構成を考える、サポート担当者が問い合わせ回答案を作るといった活用は、すでに珍しいものではありません。

一方で、社員がそれぞれ異なる生成AIを使い、顧客のソースコードや仕様書を入力している状態では、会社として安全に活用できているとはいえません。

生成AIの導入効果を高めるには、単にアカウントを配布したり、プロンプト研修を実施したりするだけでは不十分です。営業提案、要件定義、仕様書作成、テスト設計、問い合わせ対応、社内ナレッジ検索など、実際の業務工程へ生成AIを組み込み、入力情報、出力形式、確認責任、品質評価の基準をそろえる必要があります。

添付の「日本の業種別IT・AI導入状況・DX取り組み状況調査」では、情報通信業のIT導入度と生成AI導入度はともに5段階中4.5、DX成熟度は大企業4.5、中小企業3.5と評価されています。また、IPA集計では情報通信業でDXに取り組む企業の割合が83.2％とされています。

その一方で、部門別のツール乱立、シャドーAI、顧客コードや仕様書の入力、生成物の知的財産、オープンソースライセンス、AI出力の品質管理が、情報通信業特有の課題として挙げられています。

この記事では、IT企業が生成AIを個人の便利な道具で終わらせず、開発・営業・保守工程へ定着させる方法を解説します。

情報通信業では生成AI導入が進んでいるが、工程への定着が課題

情報通信業は、他業種と比べてクラウド、データ基盤、開発管理、コード生成、生成AIを導入しやすい業種です。業務の多くがデジタルデータとして扱われ、ソースコード、仕様書、議事録、問い合わせ履歴、障害記録など、生成AIが参照しやすい情報も蓄積されています。

ただし、これらの4.5や5という数値は、公式の導入率ではありません。公開統計、政策資料、業界特性を組み合わせた調査独自の相対評価です。情報通信業のDX取組企業83.2％という数値についても、調査対象や業種グループの定義を確認したうえで利用する必要があります。

重要なのは、IT企業では生成AIを使い始めること自体よりも、会社の業務として統制し、継続的に成果を出すことが課題になっている点です。

コード生成だけでは会社全体の生産性は上がらない

生成AIを導入すると、最初に注目されやすいのがコード生成です。自然言語で実装内容を指示し、コードのたたき台を作ることで、実装にかかる時間を短縮できる場合があります。

しかし、コーディング時間だけが短くなっても、次の工程に問題が残っていれば、プロジェクト全体の生産性は上がりません。

• 顧客要求が曖昧なまま実装が始まる
• 要件定義書と仕様書の内容が一致していない
• 仕様変更の影響範囲を把握できていない
• テストケースに抜け漏れがある
• レビュー待ちが長い
• 問い合わせのたびに担当者が過去資料を探している
• 障害の原因や対応履歴が個人に属人化している

実装速度だけを上げると、誤った要件を早く実装してしまう可能性もあります。そのため、生成AIはコードを書く工程だけでなく、営業、要件定義、設計、テスト、保守まで含めて活用方法を設計する必要があります。

個人利用と業務への組み込みは異なる

社員が自分の判断で生成AIを使う状態と、会社の標準工程へ生成AIを組み込む状態には、大きな違いがあります。

会社として導入する場合は、「誰が使っているか」だけでなく、「どの工程で、どの情報を入力し、どの基準で確認しているか」を管理しなければなりません。

IT企業が生成AIを組み込める6つの業務

IT企業における生成AI活用は、コード生成に限られません。特に中小IT企業では、営業提案、要件定義、テスト仕様、問い合わせ対応、社内ナレッジ検索の標準化が有望です。

1．営業提案書と顧客ヒアリングの整理

受託開発やシステム導入の営業では、顧客との面談内容を整理し、提案書や概算見積もりへつなげる必要があります。しかし、ヒアリング内容が担当営業のメモに残り、開発担当者へ十分に共有されないケースがあります。

• ヒアリングメモの要約
• 顧客課題と要望の分類
• 現状業務と理想状態の整理
• 制約条件と未確認事項の抽出
• 次回の確認質問の作成
• 提案書の構成案作成
• 過去提案書との類似点の検索
• 顧客向け説明文の下書き

AIに価格、納期、技術的実現性を決定させてはいけません。提案内容が自社の開発体制、契約条件、技術要件と合っているかは、営業責任者や技術責任者が確認します。

2．要件定義で要求・制約・未決事項を整理する

要件定義では、顧客の発言をそのまま機能一覧へ変換するのではなく、背景、目的、例外、制約、優先順位を整理する必要があります。

• 業務要求
• 機能要件
• 非機能要件
• 制約条件
• 関係者
• 前提条件
• 例外処理
• 未決事項
• 矛盾する要求
• 追加確認が必要な事項
• 受入条件の候補

生成AIは、要件を決めるものではありません。要件の候補や不足事項を見つけ、顧客との合意形成を支援する役割として使います。

3．仕様書・設計書の作成とレビューを支援する

仕様書や設計書は、担当者によって書き方や情報量がばらつきやすい成果物です。生成AIは、標準テンプレートに沿って不足項目を確認する用途に活用できます。

• 仕様書の構成案作成
• 用語や表記の統一
• 項目不足の確認
• 曖昧な表現の抽出
• 仕様変更箇所の要約
• 変更による影響範囲の候補抽出
• 既存仕様との不整合確認
• 設計意図の説明文作成
• API仕様の説明補助
• エラー処理や例外処理の不足確認

AIが仕様書を整形できても、業務要件やシステム全体との整合性まで保証するわけではありません。設計責任者によるレビューを省略しないことが重要です。

4．テストケースとレビュー観点を作成する

テスト設計は、生成AIと相性のよい業務の一つです。要件定義書、仕様書、過去の障害記録などを参照し、テスト観点の候補を作成できます。

• 正常系のテスト候補
• 異常系のテスト候補
• 境界値テスト
• 入力値の組み合わせ
• 権限別の確認項目
• 状態遷移の確認
• エラーメッセージの確認
• 過去障害の再発防止テスト
• 回帰テスト候補
• テストデータ案
• 要件とテストケースの対応付け

AIはテスト観点を広げる支援には向いていますが、システム固有のリスクや顧客業務への影響を完全には理解できません。生成されたテストケースは、QA担当者や開発責任者が要件との対応を確認します。

5．問い合わせ対応と障害の一次切り分け

保守やカスタマーサポートでは、問い合わせ内容の把握、過去履歴の検索、回答案の作成に時間がかかります。

• 問い合わせ内容の要約
• 問い合わせ種別の分類
• 緊急度の候補判定
• 不足情報の抽出
• 過去の類似問い合わせ検索
• FAQや手順書の検索
• 回答案の下書き
• 開発部門向け調査依頼の整形
• 障害発生状況の時系列整理
• 暫定対応と恒久対応の整理

顧客へ送る回答は、契約内容や顧客固有の仕様を確認したうえで、担当者が承認します。

6．社内ナレッジ検索で過去案件を再利用する

IT企業には、仕様書、議事録、テスト結果、障害記録、問い合わせ履歴、作業手順書など、多くの情報が蓄積されています。しかし、保存場所が分散していたり、担当者に聞かなければ見つからなかったりすると、組織の知識として活用できません。

• 過去の類似案件を検索する
• 特定機能の仕様を確認する
• 過去障害の原因と対応を調べる
• 手順書から作業方法を確認する
• 新任担当者の学習を支援する
• ベテラン社員への問い合わせ集中を減らす
• 回答と一緒に参照元を表示する

社内文書をそのまま読み込ませればよいわけではありません。古い仕様書、重複資料、誤った手順、廃止済みのルールが混在していると、AIも誤った回答を作ります。

▶ 関連記事：中小企業がフィジカルAIを導入する前に整理すべきこと｜ロボットを買う前の7つの準備

▶ 関連記事：国のAIロボティクス戦略で中小企業はどう変わる？フィジカルAI時代に増える仕事と支援市場

開発工程へ生成AIを組み込む標準フロー

入力情報を構造化してからAIへ渡す

生成AIの回答品質は、入力情報によって大きく変わります。ただ長い資料を貼り付けるのではなく、目的、対象業務、対象範囲、前提条件、参照資料、制約、出力形式、確認観点、判断を保留する条件、入力禁止情報を整理して渡します。

重要なのは、優れたプロンプトを一人ひとりが考えることではありません。業務に必要な入力項目を会社として決め、誰が使っても一定の結果を得られる状態を作ることです。

AI出力をそのまま成果物にしない

生成AIの出力は、原則として下書きや確認候補として扱います。基本的な流れは「入力情報の確認 → AIによる下書き → 自動チェック → 担当者レビュー → 責任者承認 → 正式な場所へ保存 → 次回以降に再利用」です。

自動チェックを通過しても、内容が正しいとは限りません。最終的な判断責任は、業務担当者と承認者が持ちます。

既存システムの中で利用する

生成AIだけを別の画面で利用すると、コピー、貼り付け、転記が増えます。また、生成結果が個人のチャット履歴に残り、組織で再利用できません。営業・顧客管理、プロジェクト管理、チケット管理、ソースコード管理、文書管理、問い合わせ管理、社内ポータル、チャット、テスト管理との連携を検討します。

AI利用ログと変更履歴を残す

業務で生成AIを使う場合は、問題が発生したときに追跡できる状態が必要です。利用者、利用日時、対象案件、対象業務、使用したAI環境、参照資料、出力内容、修正内容、承認者、正式成果物の保存先を記録します。

すべての入力内容を無条件に長期間保存するのではなく、情報区分、顧客契約、社内規程に応じて保存期間を決めます。

IT企業の生成AI導入で注意すべき情報管理

情報通信業では、一般的な文章作成だけでなく、ソースコード、仕様書、構成情報、障害ログなどを扱います。これらは顧客の営業秘密やセキュリティ情報に該当する可能性があります。

顧客コードや仕様書を入力できるとは限らない

「法人向けプランだから入力してよい」「学習に使われない設定だから安全」と単純に判断してはいけません。利用可能かどうかは、顧客との契約、秘密保持義務、再委託条件、AIサービスの利用規約、入力データの利用条件、保存期間、保存地域、管理者設定、権限管理、削除方法などを総合して確認します。

契約上の秘密保持義務と再委託条件を確認する

AIサービスを利用すると、外部事業者のシステムでデータが処理される場合があります。契約によっては、この処理が外部委託や再委託に該当する可能性があります。秘密保持契約、業務委託契約、基本契約、個別契約、情報セキュリティ条項、再委託条項、個人データ取扱条項、成果物の権利帰属、データ返却・削除条項を確認します。

認証情報や本番情報は入力しない

• パスワード
• APIキー
• アクセストークン
• 秘密鍵
• 接続文字列
• 本番環境の認証情報
• 顧客の個人情報
• 未加工の本番データ
• セキュリティ設定の詳細
• 外部公開していない脆弱性情報

ソースコードから認証情報を削除したつもりでも、コメント、設定ファイル、ログなどに残っている可能性があります。入力前に自動検査する仕組みも検討しましょう。

シャドーAIを防ぐには禁止より利用環境の整備が重要

シャドーAIとは、会社が承認・管理していない生成AIを、社員が業務で利用する状態です。

シャドーAIが発生する主な理由

• 会社が正式なAI環境を用意していない
• 利用申請に時間がかかる
• 利用可能な用途が分からない
• 禁止事項しか示されていない
• 現場が必要とする機能を会社が把握していない
• 無料版と法人管理版の違いが共有されていない
• 社内ツールが使いにくい
• 成果を出している人の使い方が共有されていない

全面禁止だけでは、利用が見えない場所へ移る可能性があります。まず、業務で必要な用途を把握し、会社が承認した利用環境を用意します。

用途別の利用可否を明確にする

例外申請と相談窓口を設ける

利用規程では、禁止事項だけでなく、判断に迷った場合の相談方法を定めます。誰へ相談するか、どの情報を提出するか、誰が承認するか、回答期限、一時的な検証の可否、検証データの用意方法、承認後の全社共有方法を決めます。

生成物の知的財産とオープンソースライセンスに注意する

生成AIが作った文章やコードだからといって、自由に利用できるとは限りません。著作権、契約上の権利帰属、既存コードとの類似、オープンソースライセンスなどを確認する必要があります。

AI生成物だから権利問題がないとは限らない

生成AIの出力には、既存の文章、設計、コードに類似した内容が含まれる可能性があります。また、顧客との契約で、成果物の権利帰属や第三者権利の非侵害について定められている場合があります。

• AIサービスの利用規約
• 出力物の利用条件
• 顧客との成果物条項
• 著作権の帰属
• 第三者権利の非侵害保証
• 再利用できる範囲
• 社内資産として保存できる範囲
• 顧客ごとの成果物を別案件へ流用できるか

AI生成コードにもライセンス確認が必要

AIが生成したコードに、オープンソースソフトウェアと類似する部分が含まれる可能性があります。確認せずに顧客へ納品すると、ライセンス表示、ソース公開、再配布条件などに影響する場合があります。

• 既存コードとの類似
• 使用しているライブラリ
• 依存関係
• ライセンスの種類
• 商用利用の可否
• 再配布条件
• 表示義務
• ソースコード開示条件
• 顧客契約との整合性

コードスキャンと人によるレビューを組み合わせる

AI生成コードは、通常の開発品質管理へ組み込みます。

• コードレビュー
• 単体テスト
• 結合テスト
• 静的解析
• 脆弱性検査
• 依存関係の確認
• ライセンススキャン
• 秘密情報の混入確認
• 既存コードとの重複確認
• 性能・保守性の確認

AI出力の品質をどのように評価するか

生成AI導入の失敗で多いのが、利用回数や生成時間だけを測り、出力品質を評価していないケースです。AIが短時間で成果物を作っても、修正やレビューに時間がかかれば、総工数は減りません。

用途ごとに評価基準を変える

正解率だけでなく修正率と確認時間を測る

• 初回採用率
• 修正率
• 全面作り直し率
• 重大誤り率
• 回答不能率
• 出典表示率
• レビュー時間
• 修正時間
• 手戻り件数
• 本番障害への流出件数
• 利用規程違反件数

作成時間だけでなく、確認を含む総工数を比較します。

高リスクな出力ほど承認段階を増やす

生成AIを開発工程へ定着させる7つのステップ

ステップ1．対象業務と現状工数を棚卸しする

誰が担当しているか、何を入力しているか、どの資料を使うか、どのくらい時間がかかるか、誰が承認するか、どこで待ち時間や手戻りが発生するかを整理します。

ステップ2．低リスクで効果を測りやすい業務を選ぶ

会議録の構造化、ヒアリング内容の整理、問い合わせ分類、テスト観点の候補作成、仕様書の表記統一、過去資料検索、FAQ回答案などから始めます。

ステップ3．入力情報と利用環境を決める

利用できるAIサービス、利用者、アカウント管理、入力可能情報、禁止情報、顧客情報の利用条件、ログ保存、データ削除、退職・異動時の権限停止、問題発生時の報告先を定めます。

ステップ4．業務テンプレートを作る

利用目的、必要な入力項目、参照資料、出力形式、禁止事項、確認項目、承認者、保存先、エラー時の対応をテンプレート化します。

ステップ5．品質評価とKPIを設定する

導入前の作業時間、レビュー時間、修正時間、手戻り、誤り、欠陥、問い合わせ解決時間、回答採用率、規程違反件数を測っておきます。

ステップ6．小規模な検証を行う

1案件、1チーム、1部門、1種類の文書、1種類の問い合わせなど、影響範囲を限定します。

ステップ7．標準化して継続的に改善する

テンプレート、成功例、失敗例を共有し、研修内容、利用規程、KPIを定期的に見直します。モデル変更時には再評価します。

IT企業で起きやすい生成AI導入の失敗

社員へアカウントを配るだけで終わる

対象業務、入力情報、出力形式、確認方法が決まっていなければ、利用する人としない人に分かれます。利用率だけでなく、業務ごとの利用方法を作りましょう。

生成時間だけを効果として測る

AIで文書やコードを早く作れても、レビューと修正に時間がかかる場合があります。正式な成果物として完成するまでの総時間を測ります。

詳しいエンジニアだけに推進を任せる

生成AI導入は技術だけの問題ではありません。開発、営業、品質保証、保守、情報システム、情報セキュリティ、法務、経営を含めた体制が必要です。

社内文書を整理せず検索対象にする

古い仕様、重複資料、誤った手順を含めて検索対象にすると、AIも誤った回答を作ります。文書の所有者、最新版、更新日、権限を整理します。

AI出力を前提にレビューを省略する

生成速度が上がるほど、誤った成果物も大量に作れるようになります。人のレビューをなくすのではなく、AIで確認候補を作り、人が重要な判断に集中できる設計にします。

IT企業における生成AIの活用イメージ

以下は、実在企業の導入事例ではなく、活用方法を示す想定例です。

想定例1．受託開発会社が要件定義の抜け漏れを確認

受託開発会社が、顧客との打ち合わせ記録を生成AIで整理します。AIは顧客の課題、業務要求、機能要件、非機能要件、制約条件、未決事項、次回の確認事項へ分類します。PMはAIの出力を確認し、誤った解釈を修正してから要件定義書へ反映します。

想定例2．システム開発会社がテスト設計を標準化

要件定義書と画面仕様書を参照し、生成AIがテスト観点の候補を作成します。QA担当者は、要件との対応、正常系、異常系、境界値、権限、状態遷移、過去障害の再発防止、対象外となる試験を確認します。

想定例3．保守会社が問い合わせ一次対応を効率化

顧客から届いた問い合わせを生成AIが要約・分類します。次に、過去の対応履歴、FAQ、手順書から関連情報を検索し、回答案を作成します。担当者は、顧客固有の仕様、契約範囲、最新情報を確認してから回答します。

想定例4．社内ナレッジ検索でベテラン依存を減らす

仕様書、障害記録、作業手順書を整理し、社内検索の対象にします。社員が質問すると、AIは回答だけでなく、参照した文書名や該当箇所を表示します。回答の根拠が見つからない場合は、確認できないと回答し、担当部署へ問い合わせるよう案内します。

▶ 関連記事：AIエージェントとフィジカルAIの違いとは？デジタル業務から現実の作業へ広がるAI

導入効果を測るKPI

営業・要件定義のKPI

• ヒアリング内容の整理時間
• 提案書作成時間
• 提案書レビュー回数
• 要件確認にかかる日数
• 要件変更件数
• 認識違いによる手戻り
• 顧客への追加確認件数

開発・テストのKPI

• 実装時間
• コードレビュー時間
• 修正時間
• テストケース作成時間
• テストケースの修正率
• 欠陥検出率
• 本番流出不具合
• 再作業時間
• ライセンス確認件数

保守・ナレッジのKPI

• 初回応答時間
• 問い合わせ解決時間
• 一次回答率
• エスカレーション率
• 過去資料の検索時間
• ベテラン社員への質問件数
• 回答案の採用率
• 回答の修正率

AI固有のリスクKPI

• 重大な誤回答件数
• 出典不明の回答率
• 禁止情報の入力件数
• 利用規程違反件数
• AI生成物の差し戻し率
• 秘密情報の検知件数
• 承認されていないAIの利用件数

中小IT企業が最初に取り組むなら何から始めるべきか

中小IT企業では、最初から開発工程全体をAI化する必要はありません。まずは、低リスクで効果を測りやすい業務を一つ選びます。

1. 会議録や顧客ヒアリングの整理
2. 問い合わせ内容の分類
3. 仕様書の表記・形式の統一
4. テスト観点の候補作成
5. 社内手順書や過去障害の検索

導入前チェックリスト

• 生成AIを使う目的は明確か
• 対象業務の現状工数を測っているか
• 入力できる情報を決めているか
• 入力禁止情報を決めているか
• 顧客との契約を確認しているか
• 利用するAI環境を会社が承認しているか
• AI出力を確認する担当者が決まっているか
• 品質評価の項目が決まっているか
• ログや変更履歴を残せるか
• 問題発生時の報告先が決まっているか
• AIが回答できない場合の処理が決まっているか
• 導入前後を比較するKPIがあるか

半数以上に答えられない場合は、ツール導入より先に、業務とルールを整理する必要があります。

よくある質問

IT企業では生成AIをどの業務から導入すべきですか？

人が出力を確認しやすく、誤りが重大事故につながりにくい業務から始めるのがおすすめです。具体的には、会議録の整理、問い合わせ分類、テスト観点の候補作成、仕様書の表記統一、社内手順書の検索などです。

顧客のソースコードを生成AIへ入力してもよいですか？

一律には判断できません。顧客との契約、秘密保持義務、再委託条件、利用するAIサービスのデータ利用条件、保存期間、管理者設定などを確認する必要があります。

AIが生成したコードはそのまま商用利用できますか？

そのまま利用するのは避けるべきです。動作確認、コードレビュー、脆弱性検査、依存関係、既存コードとの類似、オープンソースライセンス、顧客契約との整合性を確認します。

シャドーAIは禁止すれば防げますか？

禁止だけで完全に防げるとは限りません。承認済みの利用環境、用途別ルール、相談窓口、例外申請を整えることが重要です。

生成AI導入の効果はどのように測ればよいですか？

利用回数だけでなく、正式な成果物が完成するまでの総工数と品質を測ります。作成時間、レビュー時間、修正率、手戻り、欠陥、問い合わせ解決時間、回答採用率、規程違反件数などを導入前後で比較します。

まとめ｜生成AIはツール導入ではなく開発工程の再設計として進める

情報通信業は、クラウド、データ基盤、コード生成、社内文書などが整っており、生成AIとの適合度が高い業種です。

一方で、個人単位の利用が先行すると、シャドーAI、顧客コードの入力、生成物の知的財産、オープンソースライセンス、AI出力の品質管理といった問題が生じます。

IT企業が生成AIを定着させるには、業務と工数の棚卸し、低リスク業務の選定、入力情報と利用環境の決定、テンプレート化、品質評価とKPI設定、小規模検証、標準化と継続改善の順で進めることが重要です。

生成AIの目的は、社員へ多く使わせることではありません。営業、要件定義、仕様書、テスト、保守、ナレッジ検索の工程を見直し、人が確認・判断すべき部分を明確にしたうえで、作業時間、手戻り、品質の改善につなげることです。

ツール選定より先に、対象業務、入力情報、確認責任、品質基準を整理しましょう。

ご相談はこちら：AI導入支援サービス／お問い合わせ