AIが書いたコードをそのまま本番に入れていいのか? 中小企業の現場で起きているリスクを整理する

AI開発・生成AI活用公開日:2026年6月7日
高畑 拓海
高畑 拓海

株式会社シンシア 開発支援事業部 部長

Share
目次開く
  1. 要点
  2. 著者見解
  3. 何が起きているのか:AI活用の「プレゼン成功」と「コード混入」の非対称性
  4. 「動くコード」と「運用できるコード」は別物である
  5. 中小企業ほど「不具合後の対応コスト」が致命的になる理由
  6. 問題の本質はリテラシーではなく「判断の仕組み」の欠如
  7. 現場がすぐできる現実的な対策:いきなり完璧を目指さない
  8. 開発会社・外部パートナーに求められる姿勢の変化

シンシアへのご相談

自社のAI活用・開発体制について相談する

AIをどこまで内製するか、どの業務から着手するか、体制をどう組むか。開発会社・SIer・事業会社の開発部門の方からのご相談を無料で承っています。同じ問題を自社でも解いている立場としてお話しします。

AI活用の進め方を相談する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

アスキーの記事「このままで大丈夫? 中小企業の現場を変えつつあるAIの危うさ」は、AI生成コードを躊躇なく本番に組み込む中小企業の実態とリスクを指摘している。開発PM・エンジニアとして複数案件を担当してきた私の立場から、「エンジニア目線では不安しかない」という問題提起をさらに現場に引き寄せて整理したい。


要点

  • 中小企業の現場でAI活用が加速しており、AIで作成したプレゼンが増え説得力が増した事例が報告されている
  • 一方でChatGPTが生成したコードを「ほいほい組み込む」事例も増加しており、不具合発生時に誰がサポートするのかという問題が指摘されている
  • プレゼン作成と異なりコードは「動く・動かない」だけでは品質を判断できず、セキュリティホールや保守コストは表面に出ない
  • 記事筆者は「中小企業のAIリテラシはまだまだ」「野放しにしていると大きなしっぺ返しを食らう」と警鐘を鳴らしている
  • 問題は個人のリテラシー不足だけでなく、AI生成物を検証・承認するプロセスが組織に存在しないことにある

著者見解

何が起きているのか:AI活用の「プレゼン成功」と「コード混入」の非対称性

記事では、AIで作成したプレゼンが増え説得力が増した事例が紹介されている。プレゼン作成は成果物が可視化しやすく、非専門家でも品質を判断できる。一方、AI生成コードはアウトプットが「動く・動かない」では判断できない。セキュリティホール・依存関係の問題・保守コストは表面に出ない。この非対称性を理解せずに「AIでプレゼンも資料もコードも同じように作れる」と扱うことが、リスクの根本にあると私は考えている。

「動くコード」と「運用できるコード」は別物である

AI生成コードは一見動作する。しかし、エラーハンドリング・ログ設計・スケーラビリティ・テストカバレッジは生成時に考慮されないことが多い。現場PM・開発者として複数案件に携わってきた経験から言うと、不具合が顕在化するのは「リリース直後」ではなく「運用が始まってから数週間〜数ヶ月後」が多い。

記事が「不具合が起こった際に、果たして誰がサポートしてくれるのか」と問うている点は正確で、AI生成コードには保守の文脈が存在しない。責任の空白が生まれる。実務でいうと、コードの保守性・可読性・変更容易性まで含めて「運用できる状態」と呼ぶべきで、AI生成物はここを担保しない。この違いを社内で言語化できていないことが、最初のリスクだと思っている。

中小企業ほど「不具合後の対応コスト」が致命的になる理由

大企業であれば、不具合対応にIT部門やベンダーを動員できる。中小企業は人的リソースも予算も限られており、障害対応が事業停止に直結するリスクがある。AI生成コードの構造を把握しているエンジニアが社内にいない場合、外部ベンダーに調査・修正を依頼しても「誰も書いていないコード」は解析コストが高くなる。記事が指摘する「あとで大きなしっぺ返し」は、技術的負債という言葉では収まらない事業リスクになりうる。

問題の本質はリテラシーではなく「判断の仕組み」の欠如

記事は「中小企業のAIリテラシはまだまだ」と表現しているが、個人の知識不足として捉えると対策が「研修で終わる」落とし穴にはまる。現場目線では、問題の本質は「AI生成物をどのフローで検証し、誰がGoサインを出すか」というプロセスが組織に存在しないことにある。リテラシーを高めても、判断の仕組みがなければ同じリスクが繰り返される。組織として運用できるルールが必要だ、というのが私の考えだ。

現場がすぐできる現実的な対策:いきなり完璧を目指さない

まずAI生成コードの「利用可能な範囲」を明文化することが出発点になる。例えば、スクリプト・自動化ツールはOK、本番システムへの直接組み込みは要エンジニアレビュー、といった区分を1枚のドキュメントにするだけで判断基準が生まれる。社内にエンジニアがいない場合は、外部パートナーとの「軽量レビュー契約」を検討する価値がある。月次でもレビュー窓口があるだけでリスクは大きく下がる。また、不具合発生時の連絡先と対応フローを事前に決めておくことが最低限の保険になる。いきなり「AI禁止」や「全件審査」ではなく、まず判断基準を1枚のドキュメントにするところから始めることが現実的だと思っている。

開発会社・外部パートナーに求められる姿勢の変化

中小企業がAIを自力で使い始めている今、外部の開発パートナーには「作って終わり」ではなく「顧客が自力でやったことのリスクを拾う」役割が求められるようになっている。PM・エンジニアとして顧客折衝を担ってきた経験から、「なぜそのコードを入れたのか」を責めるより、現状を把握して次の選択肢を提示することが信頼につながる。AI普及が進む中で、開発支援の価値は「コードを書く速度」ではなく「判断の質と運用の安心感」に移行しつつある。この変化に向き合えるかどうかが、開発会社側にも問われていると感じている。


出典: このままで大丈夫? 中小企業の現場を変えつつあるAIの危うさ(アスキー) - Yahoo!ニュース

Share

シンシアへのご相談

自社のAI活用・開発体制について相談する

AIをどこまで内製するか、どの業務から着手するか、体制をどう組むか。開発会社・SIer・事業会社の開発部門の方からのご相談を無料で承っています。同じ問題を自社でも解いている立場としてお話しします。

AI活用の進め方を相談する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

高畑 拓海のプロフィール写真

この記事の書き手に直接相談する

高畑 拓海株式会社シンシア 開発支援事業部 部長

記事の内容について、より具体的に自社のケースで聞きたいことがあれば、高畑 拓海を指名してご相談いただけます。営業担当ではなく、 実際に手を動かしている本人が回答します。

シンシアの開発事例

株式会社Atsumell様|サービスを止めずにデータ基盤を刷新したBPマッチングプラットフォームの開発事例

**約11ヶ月・のべ4名のリレーで、機能開発を止めることなく基盤の刷新を完了しました。** 参画時期の重なりは最大2〜3名で、メンバーは1ヶ月の短期集中から5ヶ月の継続稼働までさまざまです。それでも積み上げが効いたのは、**先に入ったメンバーが構造を残していたから**でした。2025年7月に導入された Repository 層の上で、半年後に別のメンバーが移行作業を進めています。認可条件はコード上の仕様コメントとして、スナップショット方式はアーキテクチャドキュメントとして残り、いずれも「引き継いだ人が読んで分かる」形になっています。 この期間に手掛けた業務機能は、協力会社のラベル分類機能、パートナー企業管理画面、CSV による一括招待とデータ出力、案件辞退フロー、ステータス変更通知メールなど多岐にわたります。基盤刷新と機能開発は、どちらかを止めて行ったものではありません。 > 大規模な基盤刷新は「一度止めて作り直す」以外にも方法があります。呼び出し側を壊さない層を挟み、テーブル単位で少しずつ移し、移行と改善を混ぜない。この3つを守れば、リリースを止めずに土台は入れ替えられます。事業を止められないプロダクトほど、この進め方の価値が出ます。 ### この事例からの示唆 **稼働中のサービスでも基盤は入れ替えられる。** 前提は、呼び出し側の契約(戻り値の形)を保つ中間層を挟むこと、移行単位をテーブルや画面まで小さく割ること、そして移行と機能改善を同じコミットに混ぜないことの3点です。この3つが崩れると、不具合が出たときに原因が移行なのか改善なのか切り分けられなくなり、結果として一度止めるしかなくなります。 **メンバーが入れ替わる前提の体制では、成果物より「残る構造」が価値になる。** 短期参画のエンジニアを増やしても積み上がらないプロジェクトは、設計判断が個人の記憶に閉じていることが原因であるケースが多いです。この事例では、認可条件をコード上の仕様コメントとして、データ設計をアーキテクチャドキュメントとして残す運用を徹底しました。開発体制の失敗パターンについては[システム開発の失敗から立て直す方法](https://blog.xincere.jp/articles/system-development-failure-patterns)でも整理しています。 **要件が固まりきらない領域ほど、データ設計で制約を表現する。** 「協力会社が人材情報を編集したら応募内容が変わってしまう」といった問題は、運用ルールやUIの注意書きでは再発します。スキーマとトリガーで表現すれば、アプリ側の実装漏れがあっても壊れません。要件を仕様に落とす工程そのものについては[要件定義の進め方](https://blog.xincere.jp/articles/requirements-definition-process)を参照してください。 ### よくある質問 **Q. 稼働中のサービスを止めずに基盤刷新はできますか。** A. できます。この事例では約11ヶ月にわたり、機能リリースを継続しながらデータアクセス基盤の移行と主キー変更まで実施しました。ただし「一斉に切り替える」やり方では現実的に困難で、呼び出し側を壊さない中間層を用意して段階移行する設計が前提になります。 **Q. 途中でメンバーが入れ替わる体制でも品質は保てますか。** A. 設計判断がドキュメントとコードに残っていれば保てます。この事例では参画時期の重なりが最大2〜3名、1ヶ月だけの参画者もいる体制で、前任の導入した層の上に後任が半年後の移行作業を積み上げています。 **Q. どのくらいの規模・期間の支援ですか。** A. 約11ヶ月、のべ4名(同時稼働は最大2〜3名)です。プロジェクトの規模や費用感の考え方は[システム開発とは](https://blog.xincere.jp/articles/what-is-system-development)で解説しています。 ### 関連する支援領域 - [システム刷新の進め方|検討・計画から移行までの方法](https://blog.xincere.jp/articles/core-system-renewal-guide) — 稼働中システムを止めずに刷新する判断基準 - [業務システム開発の要件定義とは?進め方・手順を7ステップで解説](https://blog.xincere.jp/articles/business-system-development-requirements-definition-steps) — 要件を仕様に落とす工程 - [システム開発の失敗から立て直す方法](https://blog.xincere.jp/articles/system-development-failure-patterns) — 体制・引き継ぎで詰まったときの選択肢 同じように「稼働を止められないプロダクトの基盤を作り替えたい」という課題をお持ちでしたら、[開発のご相談](https://blog.xincere.jp/contacts)からお問い合わせください。現状のコードとデータ構造を確認したうえで、段階移行の設計からご一緒します。

株式会社Atsumellの事例を読む →

この記事が役に立ったら、Google で優先表示を

Google 検索の「優先するソース」に blog.xincere.jp を追加すると、シンシアの新着記事がトップニュースなどで見つけやすくなります。

Google で優先ソースに追加