近年、「生成AIがあればプログラマーでなくてもシステム開発ができる」という話をよく耳にします。

実際、これはある意味では正しいです。

  • 簡易的な社内ツール
  • 単機能の業務自動化
  • Google Apps Scriptでの小規模処理
  • APIを1つ使うだけの仕組み

こういった範囲であれば、生成AIは非常に強力な味方になります。

しかし、実務の現場では以下のような相談も増えています。

「最初は問題なかった、途中から使えなくなった」
「機能を追加していく内にエラーが改善されないループに入ってしまった」
「結局、外部のエンジニアに依頼することになった」

AIイメージ1

なぜこのようなことが起きるのでしょうか。

小規模開発と“高度化”の境界線

生成AIが特に能力を発揮できる主なケースは以下です。

  • 要件が明確
  • 範囲が限定的
  • 新規にゼロから作る
  • 単発のコードの改修・修正

一方で難易度が急上昇するのは、以下のような設計思想や構造が複雑になるケースです。

  • ファイルが複数に分かれる
  • データベース設計が絡む
  • 非同期処理が増える
  • 外部APIが複数になる
  • 既存システムと連携する
  • 保守・改修フェーズに入る

このような複雑な構築においての本質は、コードを書けるかどうかではなく構造を維持できるかどうかになります。

最新の生成AIはどこまで進化しているのか?

2025年以降、生成AIは更に大きく進化しています(とはいっても2020年~2025年頃までの目を見張る進化と比較すると一定落ち着いたと論じる見識者も少なくありません)。

① 長大なコンテキストに対応

最新モデルは、数10万〜100万トークン規模の文脈を扱えるものも登場しています。

これはつまり、

  • 大量のコード
  • 長い仕様書
  • 過去のやり取り

を一度に参照しながら回答できる、ということです。

2025年以前のように「長いコードは読めない」という制約はかなり緩和されています。

② プロジェクト横断の参照も可能に

最近では、

  • 過去の会話履歴を参照
  • 別プロジェクトの内容を明示的に読み込ませる
  • メモリ機能を使う

といったことも可能になっており、つまり今渡されている情報だけが全てという成約はなくなりつつあります

それでも残る"本質的な制限"

ここが非常に重要で、生成AIは高度に進化していますが、参照できる=全自動で完全理解できるではありません

①トークンは依然として有限

別プロジェクトを参照する場合も、

  • 履歴を読み込む
  • 要約する
  • 再注入する

といった処理が必要になります。

つまり、情報量に応じてトークンは消費され、会話が長期化すればするほど、コストも複雑性もはね上がります。

②AIは"現在の入力"を前提に推論している

過去履歴を参照させたとしても、AIはあくまで今回渡された情報が正しいという前提で推論します

このため、もし、

  • 修正が正しく反映されていない
  • 一部のみ変更されている
  • 認識違いがある

といったズレがあると、そのズレを前提に推論を重ねます。

これが、実際の現場で頻発する修正ループの大きな要因です。

よくある失敗パターン

以下は非常に多いケースの一例です。

  1. 「エラーが出るので直して」とAIに依頼
  2. AIが仮説ベースで修正案を提示
  3. 人間側が内容を完全には理解せず反映
  4. 別の箇所との整合性が一部崩れる
  5. 新たなエラー発生
  6. 再度AIへ修正依頼
  7. コードが段階的に複雑化・冗長化し劣化していく

このループに入ると、

  • トークン消費が急増
  • 会話が肥大化
  • エラーの原因が複数箇所に散らばり生成AIが追えなくなる

という状態になります。

高度なモデルでも、この構造的問題は解決しません。

AIイメージ2

将来的にはどうなるのか?

以下のような技術はその内ほとんど全ての生成AIで可能になるはずです。

  • 長期記憶型
  • エージェント型自律システム
  • 複数プロジェクトで知識を蓄積・共有するモデル

このため、将来的には、現在よりも高度に以下のような機能が充足されるはずです。

  • エラー履歴を自動管理(より高度な自動デバッグ機能)
  • 設計思想を保持
  • プロジェクト全体を横断して理解

しかし現時点においては、AIは強力な補助ツールであり設計責任者ではないという位置付けが現実的です。

中小企業のIT担当者が取るべき戦略

重要なのは「丸投げ」ではなく「統制」です。

① 設計思想と全体設計は人間側が握る

  • コンセプト設計
  • 開発価値
  • データ構造
  • 処理ロジック
  • 命名規則

最低限、この辺りを最初に決め確定しておくことが重要です。

② AIへの依頼は"具体的かつ明確に"行う

【悪い例】

  • エラーが出ています。修正してください。
  • 動かなくなったので確認して

【良い例】

  • 発生画面
  • 再現手順
  • 期待する動作と実際の挙動
  • エラーログ全文
  • 直前に変更した内容

一例として上記の内容をセットで伝えると生成AIの回答精度は劇的に上がります。

③ AIの修正根拠を必ず確認し理解する

生成AIは、基本的には「なぜこの変更・修正が必要なのか?」を都度説明してくれます。その説明内容を理解した上で反映の可否を人間側で判断しなければ、場合によって修正の無限ループに入ります。

④ フェーズで使い分ける

生成AIは、以下のブロックでは協力な能力を発揮します。

  • 初期構築
  • 案出し
  • テストコード生成
  • ドキュメント整備

しかし、以下のような案件では人間側で依頼内容やフローを管理・調整することが必要になります。

  • 複雑な既存システムの改修・修正
  • 個別で進めていたプロジェクトの統合
  • 複雑な連携システム内の一部の構築・改修・修正

2026年前期時点での現実的な共働指針

現時点では、生成AIの活用指針としては以下が現実的です。

  • 単発~小規模開発ではほぼ一人で完遂可能な主力開発者
  • 中規模開発では強力な補助者
  • 高度な大規模開発では人間側で設計思想の理解及び構築統制が必要

最近のモデルは、複数プロジェクトや長文コードの理解も可能になりつつありますが、依然、設計思想と言語化は人間側の能力に依存し、生成AIの能力発揮もそれ次第です。

よって、中小企業のIT担当者に求められることは、AIをただ使う能力ではなくAIを管理できる能力になるかと思います。

そして、その能力がまだ鍛えられていない場合には、早めにご相談いただくことで、結果的にコストは抑えられシステム性能は向上します。

ということで、ケースバイケースで臨機応変にAIと向き合っていきましょう!