AI内製化は何を残す？4つの社内資産
目次
AIの試作品は、驚くほど早く作れる。会議メモを要約する。問い合わせを分類する。社内文書から回答案を返す。短期間で「動くもの」まで進めやすくなった。
ところが、本番運用の話になると景色が変わる。
誰が回答の正しさを確認するのか。参照文書が更新されたら、誰が反映するのか。誤回答が起きたとき、どのログを見て止めるのか。ここを外部ベンダーだけが知っている状態では、AIの内製化とは呼びにくい。
一方で、モデル基盤や認証、監視まで全部自社で作る必要もない。大事なのは開発作業の比率ではなく、改善を続けるための資産が社内に残るかである。
AIの内製化で社内に残したい資産は、次の4つだ。
- 業務判断
- 仕様と評価基準
- 運用ログ
- 改善権限
この4つが揃えば、実装を外部へ依頼しても主導権は失わない。逆に、コードだけ社内で書いていても、判断や評価を外部に依存していれば改善は止まりやすい。
AIの内製化は「全部作ること」ではない
内製化という言葉から、社内エンジニアだけで企画、開発、運用を完結する姿を想像しがちだ。だが、AIシステムはモデルだけでは動かない。
Google CloudのMLOps解説では、実運用に必要な要素として、データ検証、テスト、デプロイ、監視、メタデータ管理などを挙げている。AIを組み込んだ仕組みは、モデルやプロンプトの作成より周辺運用の方が広い。
すべてを一度に抱え込むと、内製化の準備だけで時間を使う。そこで、内製と外部活用を二者択一にし ない。
社内に残すべきものは、事業と業務に近い判断である。共通基盤の構築や専門的なセキュリティ検証は外部の力を借りてもよい。境界を決めるときは、「誰が作るか」ではなく「誰が変更を判断できるか」で見る。
たとえば、営業メールの返信案を作るAIを考えてみよう。LLMのAPI接続は外部へ任せられる。しかし、値引きの承認条件、機密情報の扱い、返信してはいけない相手、最終確認者は自社が決める領域だ。
この切り分けが、選択的なAI内製化の出発点になる。
1. 業務判断を社内に残す
最初の資産は、AIに任せる業務の判断ルールである。
AI導入の相談では「メール対応を自動化したい」「問い合わせを全部処理したい」といった大きな単位で話が始まりやすい。だが、実際の業務には例外がある。
- 新規顧客と既存顧客で承認者が違う
- 金額や契約条件を含む返信は人が確認する
- 個人情報を含む添付は別の経路で扱う
- 判断材料が不足したら返信せず担当者へ戻す
こうした条件は、業務部門が持つ暗黙知だ。外部ベンダーがヒアリングして文書にすることはできる。ただし、正しさを決める責任まで渡してはいけない。
業務判断は、最低でも次の形で残す。
| 項目 | 記録する内容 |
|---|---|
| 対象業務 | AIが扱う依頼と扱わない依頼 |
| 判断条件 | 分類、金額、相手、期限などの分岐 |
| 人の確認 | 必ず承認が必要な場面 |
| 停止条件 | 情報不足、矛盾、禁止データ、異常時の戻し先 |
この表は、要件定義の前段にある業務ルールだ。AIが読める仕様書の書き方でも、曖昧な言葉を入力、判断、出力へ分ける必要性を扱っている。内製化では、その元になる判断を更新できる担当者を社内に置く。
2. 仕様と評価基 準を社内に残す
2つ目は、AIの振る舞いを説明する仕様と、合格を決める評価基準である。
「よい感じに要約する」「正確に回答する」だけでは、改善の方向を決められない。正確さを上げた結果、回答不能が増えることもある。回答率を上げれば、根拠の弱い回答が混ざるかもしれない。
そこで、期待する振る舞いをテスト可能な形にする。
問い合わせ分類AIなら、次のように分けられる。
- 対象ラベル: 資料請求、相談、採用応募、営業提案、判定不能
- 入力例: 実際の表現を一般化した代表ケース
- 期待結果: 正しいラベルと、通知するか否か
- 禁止結果: 営業提案を顧客相談として通知しない
- 合格条件: 重要ケースを落とさず、誤通知を許容範囲に収める
NISTのAI Risk Management Frameworkは、AIリスクをGovern、Map、Measure、Manageの4機能で継続的に扱う。評価は納品前の一回限りの検査ではない。利用状況やリスクが変われば、測り直して管理方法を更新する。
仕様と評価セットを社内が持っていれば、モデルや開発会社を変更しても同じ条件で比較できる。これがないと、担当者の感覚で「前よりよさそう」を繰り返 すことになる。
3. 運用ログを社内に残す
3つ目は、AIが何を入力として、どう処理し、どんな結果を返したかを追える運用ログである。
ログというと、開発者向けのエラー記録を想像するかもしれない。AIの運用では、業務改善の材料でもある。
残したいのは、少なくとも次の情報だ。
- 実行日時と処理対象
- 使用した仕様、プロンプト、参照データの版
- AIの出力と人が修正した内容
- 承認、差し戻し、停止の結果
- エラー理由と再実行の有無
ただし、機密情報を無制限に保存してはいけない。保存期間、閲覧権限、マスキング、削除方法も仕様に含める。
ログがあれば、「精度が悪い」という漠然とした声を分解できる。参照文書が古かったのか。分類条件が足りなかったのか。モデルの出力が不安定だったのか。人の承認待ちが詰まったのか。原因ごとに打ち手が変わる。
デジタル庁のガバメントAI「源内」も、現場の課題を反映しながら段階的に構築している。完成品を一度導入して終わるのではなく、利用から学び、次の変更へつなぐ運用が前提にある。
4. 改善権限を社内に残す
4つ目は、改善を実行する権限である。
仕様書やログがあっても、変更のたびに外部ベンダーへ依頼し、数週間待つ状態では改善速度が上がらない。とはいえ、本番設定を誰でも変更できる状態は危険だ。
改善権限は段階に分ける。
| 変更 | 社内での扱い例 |
|---|---|
| 参照文書の追加 | 業務責任者がレビュー後に反映 |
| プロンプトの修正 | 検証環境で評価セットを通してから承認 |
| モデル変更 | コスト、品質、データ取扱いを比較して責任者が判断 |
| 外部システムへの書き込み | 個別承認または権限付き実行に限定 |
| 停止・切り戻し | 異常時に社内担当者が即時実行できるようにする |
すべての変更権限を配るのではない。小さな改善は現場で回し、高リスクな変更はレビューを通す。重要なのは、社内に判断者と実行経路があることだ。
IPAの「DX動向2025」は、AI・生成AIの利活用とシステム開発の内製化をDXの課題として並べている。内製化は人を増やすだけでは進まない。業務部門、情シス、開発担当、外部パートナーの責任をつなぐ必要がある。
AI内製化の進め方を5段階にする
4つの資産を一度に完成させる必要はない。次の5段階で進めると、試作と運用準備を並行できる。
1. 対象業務を一つに絞る
件数があり、判断ルールを説明でき、人が結果を確認できる業務を選ぶ。全社横断の万能AIから始めない。
2. 代表ケースと停止条件を作る
正常例だけでなく、情報不足、矛盾、禁止データ、権限外の例を集める。AIが答えない方がよい場面を先に決める。
3. 仕様と評価セットを共有する
業務部門と開発側が、同じ入力例と期待結果を見る。外部パートナーにもこの成果物を渡し、実装だけを会話の中心にしない。
4. ログと承認経路を組み込む
誰が何を確認したか、問題が起きたらどこで止めるかを運用へ入れる。本番化の直前に考えるのでは遅い。
5. 小さな変更を社内で回す
参照文書や分類条件など、低リスクな変更から社内運用へ移す。モデル基盤や大きな権限変更は、必要に応じて専門家と進める。
この順番なら、外部支援を使いながら内製能力を育てられる。外注をやめることが目的ではない。外部の専門性を使っても、業務の主導権と学習結果を社内に残すことが目的だ。
内製と外部支援の境界を決めるチェックリスト
計画を始める前に、次の質問へ答えてみてほしい。
- AIに任せる業務と、任せない業務を説明できるか
- 代表ケースと禁止ケースが揃っているか
- 合格条件を数値または判定表で示せるか
- 出力を誰が確認し、どの条件で承認するか決 まっているか
- 参照データの更新責任者がいるか
- 実行ログを社内で確認できるか
- 異常時に停止、差し戻し、切り戻しができるか
- 外部パートナー変更時に仕様と評価セットを持ち出せるか
半分以上が未回答なら、採用やツール選びより先に業務と仕様を整理する段階だ。AI要件定義ツールの選び方も、機能比較だけでなく権限、変更管理、成果物の持ち出しやすさまで見る必要がある。
AIの内製化は、コードを何割自社で書いたかでは測れない。業務判断、仕様と評価、運用ログ、改善権限。この4つを社内に残せれば、外部パートナーと組んでも学習速度は自社のものになる。
逆に、4つが外へ出たままなら、ツールを導入するたびにゼロから説明し直すことになる。AIを作る前に、何を自社の資産にするかを決める。そこから内製化は始まる。
AIの対象業務、評価条件、運用権限を整理したい場合は、株式会社Atsumellへ相談することもできる。実装だけでなく、業務フローと要件の整理から支援している。
