はじめに：開発の「作り方」が変わりつつある
ここ数年、業務システムの受注開発の現場では、AI エージェントと呼ばれるツールの利用が広がっています。AI エージェントとは、人間が出した目的（「この画面に検索機能を追加して」など）を受けて、関連するファイルを自分で探し、コードを書き、テストを実行し、エラーが出れば修正を繰り返す——という一連の作業を、比較的自律的に進める AI ツールの総称です。従来の「入力中の次の一行を予測して補完する」タイプの AI とは、作業の単位が大きく異なります。
この変化は、開発会社の内部事情にとどまりません。見積もりの根拠、進捗の見え方、検収のやり方、そして「何を納品物とみなすか」まで、発注する側の判断にも影響します。この記事では、中小企業の経営者・システム担当者の方が、ベンダーと話すときに押さえておくと役立つ論点を整理します。
従来の開発支援 AI と AI エージェントの違い
まず、言葉の整理をしておきます。同じ「開発で AI を使う」でも、できることの範囲が違います。
| 種類 | やること | 人間の関与 |
|---|---|---|
| コード補完型 | 入力中の数行を予測して提案する | 常時。人が書き進める前提 |
| チャット相談型 | 質問に対してコード例や設計案を文章で返す | 人が内容を読み、自分の手で反映する |
| AI エージェント型 | 目的を受けて複数ファイルを横断的に読み書きし、テスト実行・修正まで回す | 指示と、結果のレビュー・承認 |
エージェント型では、人間の役割が「書く人」から「仕様を決め、出てきたものを判断する人」に寄ります。ここが、発注側にとっても重要な変化点です。
速くなる工程と、ほとんど変わらない工程
「AI を使えば全部安くなるのでは」と期待されることがありますが、工程によって効き方がかなり違います。実感として差が出やすいところと、出にくいところを分けて考えるのが現実的です。
| 工程 | AI エージェントの効き方 |
|---|---|
| 要件のヒアリング・業務整理 | 効きにくい。現場の例外運用を聞き出す作業は人間の仕事 |
| 画面・CRUD（登録・参照・更新・削除）の実装 | 効きやすい。定型的で、既存パターンを参照しやすい |
| 既存システムとの連携・データ移行 | 条件次第。仕様書が残っていない古いシステムほど難航する |
| テストコードの作成 | 効きやすい。網羅的なパターン出しは得意領域 |
| 受入テスト・業務上の妥当性判断 | 効きにくい。「この計算でよいか」は発注側しか判断できない |
つまり、ボトルネックは実装からレビューと意思決定へ移動する傾向があります。発注側の確認が遅れると、速くなった分がそのまま待ち時間に変わります。プロジェクト開始時に「誰が、どのくらいの頻度で確認するか」を決めておくことが、以前より重要になりました。
見積もり・契約で確認しておきたいこと
AI エージェントの利用が前提になると、見積書の読み方にも注意点が増えます。たとえば次のような場面です。ある業務システムの改修で、ベンダー A は従来どおりの人月見積もり、ベンダー B は「AI 活用により短期間」とだけ記載している——このとき、価格だけで比べると判断を誤ります。確認したいのは次の点です。
- レビュー体制：AI が生成したコードを、誰がどの基準で確認するのか。人間のレビューが工程に組み込まれているか
- 著作権・利用権：納品されるソースコードの権利の所在。AI 生成物を含む場合の扱いを契約書に明記しているか
- 秘密情報の取り扱い：自社の仕様書・テストデータを外部の AI サービスに入力するのか。入力する場合、学習に利用されない設定になっているか
- 保守の継続性：生成されたコードを、後から別の担当者が読んで直せる状態か（設計意図のドキュメントが残るか）
特に 3 点目は社内規程にも関わります。個人情報を含むデータを扱う場合、改正個人情報保護法（2022 年全面施行）での委託先の監督義務の考え方を踏まえ、再委託と同様にサービス利用先まで確認しておくと安全です。また、総務省・経済産業省が 2024 年に公表した「AI 事業者ガイドライン」も、利用側が守るべき考え方の参考になります。いずれも個別案件への当てはめは専門家の確認が必要な範囲ですので、ここでは「契約書に書いてあるか確認する」というレベルで捉えてください。
実装で詰まりやすい箇所
AI エージェントを使っても、むしろ使うからこそ表面化しやすい論点があります。
1. 既存システムの「暗黙の仕様」
長年使ってきた基幹システムには、ドキュメントに残っていないルールが埋まっていることが珍しくありません。「このコードが入っているときだけ締め日が違う」といった類です。AI は既存コードから読み取れる範囲は拾えますが、コードに現れない運用上の例外は拾えません。ヒアリング段階で現場担当者を巻き込むことが、結局いちばん効きます。
2. もっともらしいが間違っている出力
AI は、一見整っているが事実と異なる内容を出すこと（ハルシネーション）があります。業務システムでは、金額計算・日付計算・権限制御のまわりが特に危険です。自動テストと、発注側による受入テストの二段構えを前提に計画してください。
3. 権限とログ
開発の速度が上がると、権限設計やログ出力といった「見えない要件」が後回しになりがちです。誰が何を見られるか、いつ誰が何を変更したかを追えるか。これは発注側から明示的に要求項目として出しておくべきものです。
発注前のチェックリスト
- 自社側のレビュー担当者と、確認にかけられる時間を決めたか
- 成果物にソースコードと設計ドキュメントが含まれるか、契約で確認したか
- 自社データを外部 AI サービスに渡すかどうかを確認したか
- 受入テストで「業務として正しいか」を見る項目を自社で用意したか
- 納品後に誰が保守するか（自社／ベンダー）を想定しているか
まとめ
AI エージェントは、実装のスピードを押し上げる一方で、仕様を決める力とレビューする力の重要性を相対的に高めます。発注側にとっての要点は、「AI を使っているから安い・速い」を鵜呑みにせず、レビュー体制・権利関係・情報の取り扱い・保守のしやすさを具体的に確認することです。
逆に言えば、この 4 点を押さえられる発注者であれば、従来は予算的に手が届かなかった規模の業務改善にも取り組みやすくなっています。まずは小さな範囲で一度組んでみて、自社の確認プロセスが回るかどうかを試すところから始めるのが、現実的な進め方だと考えています。