生成AI関連
小さく始める生成AI活用
近年、生成AIの進化によって「これまで外部のシステム開発会社へ委託していた業務システムや内部ツールを、自社で内製化できるのではないか」と考える企業が増えています。コーディングエージェントは設計の壁打ちから実装、テストの生成までを支援するようになり、業務に詳しい担当者がプロンプトを書くだけで動くアプリケーションが生まれる事例も珍しくなくなりました。
しかし、生成AIによって「コードを書ける人」が増えることと、「業務で安定して使えるシステムを内製で持てる」ことは、同じではありません。ソフトウェアエンジニアリングは、コードを動かす段階を越えると、要件定義、設計、テスト、運用、保守という地続きの工程に踏み込みます。AIが書いたコードを読み解く力、属人化を防ぐ仕組み、組織でコードを管理する文化など、生成AIが登場した今だからこそ、改めて整理しておきたい論点があります。
本記事は、生成AIを活用した内製化に取り組む前に押さえておきたい主要な論点を、総論として整理するものです。何を対象に内製化するのか、どのようなリスクがあるのか、組織として何を準備すれば腰を据えて進められるのかを、過去の記事や外部の事例も参照しながらご紹介します。
「内製化」という言葉は、企業によって意味する範囲が大きく異なります。基幹システムを丸ごと自社開発に置き換える話なのか、外注していた小規模な業務ツールだけを巻き取る話なのか、あるいは現場の担当者がAIに指示して作る簡易スクリプトを指すのか。最初に整理しておきたいのは、自社が想定している内製化の対象を明確にすることです。
生成AIで現実的に内製化を始めやすいのは、業務寄りの小規模ツールや、データ整形・集計・社内向け業務アプリといった領域です。これらは要件の変動が大きく、外部委託では小回りが利かない一方、影響範囲が限定的でテストや切り戻しが容易だからです。逆に、基幹システム、決済処理、個人情報を多量に扱う領域、可用性が事業継続に直結する領域は、内製化の対象に据えるとしても、慎重な体制設計と段階的な検証が前提になります。
| 内製化の対象例 | 内製化のしやすさ | 主な留意点 |
|---|---|---|
| 業務データの集計・整形スクリプト | 高い | 属人化、データ取得経路の管理 |
| 部署内の業務効率化ツール | 高い | 利用範囲の拡大に伴う保守責任 |
| 社内向けの簡易Webアプリ | 中程度 | 認証、権限設計、ホスティング |
| 顧客向けの問い合わせ補助ツール | 中程度 | 個人情報、応答品質、責任分界 |
| 受発注や在庫管理などの業務基幹 | 低い | 業務継続性、データ整合性、監査 |
| 決済・金融処理・個人認証 | 低い | 法規制、外部監査、セキュリティ要件 |
最初の一歩として向いているのは、現場の担当者が日々の作業で繰り返している小さな工程を対象に、生成AIによる支援を入れることです。小さく始めて、運用に乗せながら学ぶことで、内製化の感覚を組織が掴めるようになります。小さく始めることの考え方や、導入と定着の前提については、過去記事でも整理しています。
生成AIによってコードを書く速度は劇的に上がりました。一方で、業務で使えるシステムを継続的に維持していく難しさは、AIが登場しても基本的には変わっていません。むしろ、コードが速く増える分だけ、設計・テスト・運用・保守の工程に注意を向ける必要性は高まっています。
| 工程 | 主な作業 | 内製化で起きやすいこと |
|---|---|---|
| 要件定義 | 業務の現状把握、課題設定、対象範囲の合意 | 「動くもの」が先行し、関係者間の要件合意が曖昧なまま進行する |
| 設計 | データ構造、画面構成、外部連携、エラー設計 | AIが提案した構造をそのまま採用し、保守性の検証が抜ける |
| 実装 | コード作成、ライブラリ選定、依存管理 | 動作確認だけで満足し、ライブラリ選定の根拠が残らない |
| テスト | 単体・結合・受け入れの観点設計と実行 | 動作確認のみで、想定外の入力やエラー処理が抜ける |
| 運用 | 監視、障害対応、バックアップ、権限管理 | 担当者の手元で動かしているため、運用が属人化する |
| 保守 | 仕様変更、依存ライブラリ更新、脆弱性対応 | 触れる人がいないままブラックボックス化し、改修が困難になる |
特に難しいのは、「動いている」ことと「使い続けられる」ことの差を組織として認識することです。生成AIが書いたコードは初回の動作確認には合格しても、数か月後にライブラリのバージョンが変わったり、業務要件が拡張されたりした際に、誰が直せるのか、どこを直せばよいのかが不明確になりがちです。
内製化を進めるうえでは、コードを生み出す工程だけでなく、生み出されたコードを誰がどのように維持していくかまでを含めて検討する必要があります。これは外部委託でも同じ論点ですが、内製の場合、責任の所在が社内に閉じるぶん、最初から運用と保守の設計をしておくことが重要になります。
生成AIによる内製化を進めるうえで、もっとも見落とされやすいのが「AIが生成したコードを、適切にレビューできる体制を組織として持てるかどうか」という問いです。コードを書く速度が上がっても、レビューする力が追いつかなければ、内製化はかえってリスクを膨らませることになります。
生成AIが書くコードには、見た目には自然に動くものの、レビュー観点ごとに確認しないと気づけない問題が潜むことがあります。代表的な観点は次のとおりです。
| 観点 | 確認したいこと | 起こりうる問題の例 |
|---|---|---|
| セキュリティ | 入力検証、認証、権限、機密情報の取り扱い | SQLインジェクションが残る、APIキーがコードに直接書かれる |
| 依存ライブラリ | 実在性、メンテナンス状況、ライセンス | 実在しないパッケージ名を提案され、攻撃者が悪用する経路を生んでしまう |
| 設計整合性 | 既存コードとの一貫性、責務分離 | 似た処理が複数箇所に重複し、修正漏れの温床になる |
| 可読性 | 命名、コメント、関数の長さ | 過度に短縮された変数名、意図の読み取れない処理 |
| エラー処理 | 想定外入力、外部呼び出しの失敗 | 例外を握り潰して、障害発生に気づけない状態を作る |
| ライセンス | 採用したコード片の出典と利用条件 | 商用利用に制限のあるコードが意図せず紛れ込む |
特に、実在しないライブラリやパッケージをAIが提案してしまう「パッケージハルシネーション」のような事象は、近年広く議論されています。AIが提示する名前を信じて検索した結果、同名のパッケージを悪用する攻撃者の罠にかかるおそれもあり、依存関係の検証は内製化に欠かせない工程です。AI生成コードに対する脅威の体系は、過去記事でOWASPのフレームワークに沿って整理しています。
レビューの体制を考えるうえで重要なのは、AIにレビューさせる工程と、人間がレビューする工程の使い分けを明確にすることです。同じAIモデルだけでレビューさせると同じバイアスがかかりやすいため、最終的な判断は人間が担う前提を置く必要があります。コーディングエージェントを実務で使う際のレビュー、スコープ、破壊的操作の扱いは、社内勉強会の知見として記事にまとめています。
AIが生成したコードを「動いたから良し」とせず、人間が読み、理解し、必要に応じて書き換えられる状態を維持することが、生成AIによる内製化の品質を支える前提になります。
生成AIによって、コードを書ける人の裾野は広がりました。業務に詳しい担当者が、自分の作業を効率化する小さなスクリプトを作る場面も増えています。これは内製化の入口として有効である一方、組織として何の方針も設けないまま個人ごとに自由にスクリプトが量産されると、かつてのExcelマクロが辿った道を再現してしまうおそれがあります。
Excelマクロは、業務担当者が自分の手元で作業を自動化できる手軽さから、多くの現場で活用されてきました。しかし、担当者が異動・退職した後、コードが残っていても理解できる人がいない、コメントが書かれていない、ファイル名や置き場所がばらばらで探せない、といった理由で「動いているが誰も触れない」状態に陥った例は数多くあります。生成AIで書かれたスクリプトも、同じ末路をたどる可能性が十分にあります。
属人化を抑制するために、組織として最低限揃えておきたい工夫があります。
生成AIの Skills と呼ばれる仕組みは、業務手順や設計指針を再利用可能な単位として残すための仕掛けです。個人が頭の中に持っていた手順を Skills として外部化すれば、別のメンバーや別のエージェントが同じ品質で作業を再現できるようになります。Skills の基本的な考え方と作成手順は、過去記事で詳しく整理しています。
属人スクリプトのリスクを完全に排除することは現実的ではありません。重要なのは、「あとから人が読んで理解できる」状態を保つルールを、組織として最初から運用に組み込むことです。コメントと手順書を残すというごく基本的な習慣が、内製化の継続性を大きく左右します。
複数人で生成AIを使いながら開発を進める場合、コードのバージョン管理とレビューの仕組みは欠かせません。個人で小さなスクリプトを書く場合と異なり、内製化を組織として進める段階では、「誰が、いつ、何を、どのような理由で変更したか」を後から追える状態を持つことが前提になります。
Gitは、個人開発から大規模開発まで広く使われているバージョン管理の仕組みです。内製化の現場でGitを使う際に、特に意識しておきたい点を整理します。
| 項目 | 内容 |
|---|---|
| ブランチ運用 | AIに任せる変更は専用ブランチで作業し、本番ブランチへ直接コミットしない |
| プルリクエスト | 変更内容、目的、テスト結果、AIへの指示内容を本文に残す |
| コードレビュー | 一定規模以上の変更は人間のレビューを必須にし、観点をチェックリスト化する |
| マージ条件 | テストの自動実行、レビュー承認、必要に応じてセキュリティスキャンを通す |
| 履歴の保持 | コミットメッセージとPR本文で、なぜその変更をしたかを後から追える状態にする |
特にAIエージェントは、自律的にファイルを書き換えるため、Gitのコミット単位や差分の見やすさを意識しないと、「変更が大きすぎてレビューできない」状態に陥りがちです。コーディングエージェント関連の記事でも触れているとおり、自分がレビューできる単位までスコープを分割するという運用は、内製化でも同じく有効です。
AIエージェント自身に向けて、プロジェクトの前提、命名規則、実行手順を伝えるAGENTS.mdのようなファイルを整備しておくと、人間が毎回同じ指示を出さなくても、エージェントが共通の前提に従って動けるようになります。AGENTS.mdの考え方は、過去記事で整理しています。
さらに、AIが理解しやすい設計書を整えることも、内製化のチームワークを支えます。AI時代の設計書には、目的、対象範囲、制約、データの流れ、外部連携などを構造化して書くことで、人間とAIの双方が同じ前提で作業を進められるようになります。
Git、AGENTS.md、設計書といった組織運用の土台は、それ自体が直接の成果物を生むものではありません。しかし、内製化を継続的に進めるうえで、土台を整えるかどうかが「数年後も保守できているか」「人が入れ替わっても運用できるか」を左右します。コードを早く生み出すだけでなく、生み出されたコードを組織として扱えるようにすること。これが、内製化を腰を据えて進めるための前提です。
生成AIによる内製化を進めるとき、セキュリティと法務の検討は「後から考える」ではなく「最初から組み込む」べき領域です。動かしてから対処しようとすると、すでに本番データやお客様情報が外部サービスを経由してしまった、外部のコード片を商用利用条件に違反して取り込んでしまった、といった取り返しのつかない事態に発展しかねません。
| レイヤー | 検討事項 |
|---|---|
| データ | どの情報を生成AIに渡すか、匿名化やマスキングの基準は何か |
| コード | 生成されたコードのライセンス、外部由来のコード片の取り扱い |
| 認証・権限 | 内製ツールが扱う認証方式、最小権限、シークレット管理 |
| ログ・監査 | 誰がいつ何をしたかの記録、AIへの依頼内容の保管期間 |
| 法令・契約 | 個人情報保護、顧客契約上のデータ利用条件、業種別の規制 |
| 外部連携 | クラウドサービス、外部API、第三者ライブラリの利用方針 |
特に、生成AIに業務データや顧客情報を直接入力する場合、利用規約や契約上の制約を事前に確認しておく必要があります。社内データを安易にクラウド型のAIサービスへ送ることに不安がある場合、ローカルLLMという選択肢も検討に値します。
セキュリティ脅威の体系を理解するうえでは、OWASPが公開しているTop 10 for LLM Applicationsのような業界標準のフレームワークを参照することが有効です。攻撃面の整理、対策の優先順位付け、社内の検討項目の網羅性確認に活用できます。
また、内製化を進める段階では、開発環境と本番環境の分離、シークレット情報の取り扱い、ログの保管方針、社外公開時の脆弱性検査など、運用面の設計も並行して進めます。これらは外注の場合は委託先のセキュリティ運用に乗せられる場合もありますが、内製の場合は自社で責任を持つ前提になります。
「動くものを作る」だけでなく「安全に運用し続ける」ところまでを範囲に含めて、最初から設計に組み込んでおく。これが、生成AIによる内製化を中長期で続けるための前提です。
ここまでに整理した論点を踏まえると、生成AIによる内製化は、思いつきで始められるものでも、短期で完結するものでもないことが見えてきます。一方で、論点を整理して段階的に進めていけば、自社の業務に即した内製化を着実に育てることは十分に可能です。
| フェーズ | 主な活動 | 押さえる論点 |
|---|---|---|
| 準備期 | 内製化の対象選定、対象業務の整理、利用するAIサービスとローカル環境の選定、情報セキュリティ方針の整理 | 何をどこまで内製化するか、機密情報の取り扱い、利用方針 |
| 立ち上げ期 | 小さな対象業務でのPoC、コーディングエージェントの選定、Skills化、Gitリポジトリと運用ルールの整備 | 動くものを作ることと運用ルール整備を並行する |
| 拡張期 | 対象業務の拡大、レビュー体制と教育、AGENTS.mdの整備、セキュリティ運用の組織化、保守体制の整備 | 個人の成果を組織知に変換し、属人化を抑制する |
定着フェーズに進むためには、「導入したツールが使われ続ける」状態をどう作るかが鍵になります。利用率を上げる前に整理しておくべき観点は、過去記事でもまとめています。
内製化を組織として腰を据えて進めるうえで、すべての論点を自社単独で同時に整えるのは、現実的に難しい場面もあります。要件整理、エージェントやSkillsの設計、コードレビュー文化の醸成、Gitやセキュリティの運用ルール、教育の体制まで、論点は多岐にわたります。フェーズによって必要な専門性も変化するため、必要に応じて外部の専門家と並走することは、検討に値する選択肢です。
Tech Funでは、生成AIによる内製化を進めるお客様に対し、業務の整理、PoC設計、セキュリティと運用の検討、社内への展開設計まで含めて並走支援を行っています。「何から始めればよいか分からない」段階でも、まず論点を一緒に整理するところからお手伝いできます。
生成AIによる内製化は、企業にとって大きな機会である一方、ソフトウェアエンジニアリングが要求する論点を踏まえて取り組む必要があります。本記事で整理した主要な論点を、改めて振り返ります。
これらは、内製化を短期の効率化にとどめず、組織として継続できる仕組みに育てるために欠かせない論点です。生成AIは、人間の創意工夫を増幅する強力な道具です。論点を整理し、土台を整えてから取り組めば、内製化はお客様の業務に深く根差した、変化に強い基盤になっていきます。
Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた支援を3つのパックでご提供しています。
生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。
