生成AIが速くなったぶん、曖昧さの代償も速く返ってくる
ここ数年で、AIにコードを書かせる開発スタイルが一気に実用段階に入りました。設計の相談から実装、テストコードの生成まで、対話しながら進められるツールが揃っています。中小企業の業務システム開発でも「見積りより短い期間で動くものが出てきた」という感触を持つ方は増えているはずです。
一方で、現場でよく聞くのは別の話です。「速く出てきたが、思っていたものと違う」。これはAIの性能の問題ではなく、ほとんどの場合、渡した指示が曖昧だったことの結果です。人間の開発者なら「ここ、どういう意味ですか」と聞き返す場面でも、AIは文脈から妥当そうな解釈を一つ選んで、そのまま最後まで書き切ってしまう。曖昧な要件は、曖昧なまま、しかし一見きれいなコードになって返ってきます。
この記事では、受注開発の現場で実際に効いている「指示の設計」の考え方を、発注する側・社内で要件をまとめる側の視点から整理します。プログラミングの知識は前提にしません。
曖昧さには種類がある — まず自社の要件を分類する
「曖昧な要件」とひとくくりにすると対処できません。実務では次の4種類に分けると、どこを埋めるべきかが見えてきます。
| 種類 | 典型的な表現 | AIが起こしやすい結果 |
|---|---|---|
| 範囲の曖昧さ | 「顧客情報を管理したい」 | 項目が勝手に増減する。必要な項目が欠け、不要な項目が付く |
| 境界の曖昧さ | 「月末に締める」 | 月末が土日のときの挙動が未定義のまま実装される |
| 優先順位の曖昧さ | 「使いやすく、かつ厳密に」 | 相反する要求のどちらかを勝手に選ぶ |
| 責任の曖昧さ | 「エラーが出たら知らせて」 | 誰に、どの手段で、どのレベルから通知するかが決まらない |
この4つのうち、受注側が質問して埋められるのは「範囲」と「境界」までです。「優先順位」と「責任」は、業務を回している側にしか決められません。ここを曖昧なままAIに投げると、もっともらしい実装が出てきて、運用開始後に初めて食い違いが露見します。
指示書に書くべき5つの層
AIに渡す指示（プロンプト）を、思いついた順に書くと抜けが出ます。次の5層で整理すると、現場では漏れが減ります。
| 層 | 書く内容 | 書かないとどうなるか |
|---|---|---|
| 1. 目的 | 誰のどの業務を、どう楽にするのか | 技術的に正しいが業務に合わない設計になる |
| 2. 入出力 | 何が入力され、何が出力されるか（項目名・型・桁） | 項目の解釈がぶれる。CSVの列順などで後戻りする |
| 3. ルール | 計算式、判定条件、例外処理 | AIが一般論で埋める。自社固有の慣行が反映されない |
| 4. 制約 | 既存システム、利用環境、セキュリティ要件、予算・期日 | 実装後に「そのライブラリは社内で使えない」が判明する |
| 5. 受け入れ条件 | 何ができたら完成とみなすか | 完成の判断が主観になり、検収が長引く |
特に軽視されがちなのが 5の受け入れ条件 です。「請求書が出せること」ではなく、「2024年4月分の実データ120件を投入して、現行の手作業の結果と全件一致すること」まで書けると、AIに対してもテストコードの生成指示がそのまま出せます。開発者向けの仕様というより、検収の合格ラインを先に言語化する作業だと考えてください。
実装で詰まりやすい場所は、だいたい決まっている
AIを使った開発でトラブルになる箇所には偏りがあります。発注側があらかじめ答えを用意しておくと、手戻りが大きく減る論点を挙げます。
日付・時刻まわり
締め日が休日に重なるとき、年度をまたぐとき、月末日が存在しない日付（たとえば2月31日のような入力）をどう扱うか。ここは業界ごとに慣行が違い、AIは一般的な実装を選びます。
権限と見える範囲
「営業は自分の担当分だけ、課長は課の全件、経理は金額のみ参照」といった権限設計は、後から足すと作り直しになりがちです。最初の指示に含めるか、含めないかを明示的に決める必要があります。
既存システムとのつなぎ込み
会計ソフトや販売管理システムとの連携は、API（システム同士がデータをやり取りするための接続口）が公開されているか、CSVの手動取り込みになるかで難易度が一桁変わります。AIは既存システムの仕様を知らないため、ここは人間が調べて渡すしかありません。
過去データの移行
Excelで何年も運用してきた台帳には、表記ゆれ、セル結合、手書きメモの混入がほぼ必ずあります。移行対象の範囲と、クレンジング（データの整形・清掃）をどこまでやるかを決めておかないと、ここだけで工数が膨らみます。
個人情報・機密情報の取り扱い
顧客情報や従業員情報を扱う場合、個人情報保護法（2022年4月施行の改正法）で定められた安全管理措置や、漏えい時の報告義務への対応が関係します。また、総務省・経済産業省が2024年に公表した「AI事業者ガイドライン」では、AIの利用にあたって透明性や説明可能性への配慮が示されています。自社のケースでどこまでが必要になるかは、取り扱うデータの性質によって変わるため、開発着手前に一度整理しておくことをおすすめします。
発注側が準備しておくと効くもの
完璧な要件定義書は必要ありません。むしろ、次のような「生の材料」のほうが有効に働きます。
- 現在使っているExcelやフォームの実物（ダミーデータに置き換えたもので可）
- 例外処理のリスト：「このお客様だけ締め日が違う」「この商品は税率が別」といった、担当者の頭の中にあるルール
- やらないことの一覧：今回のスコープに入れない機能を明記する。これが曖昧さを最も強く削ります
- 運用後に誰が何をするか：マスタ登録は誰か、エラー時の一次対応は誰か
たとえば次のような場面です。受注管理システムの相談で「とりあえず受注を一覧で見たい」とだけ伝えた場合と、「受注後にキャンセルと数量変更が月に数件あり、変更履歴を残したい。ただし金額の遡及修正は経理の承認が要る」まで伝えた場合では、出てくる設計がまったく別物になります。後者は最初から履歴テーブルと承認フローを含む構造になりますが、前者から後者へ変更するのは作り直しに近い作業です。こうした運用上の例外は、システムの骨格そのものを決めます。
AIを使うからこそ、人間が決める部分が重くなる
開発にAIを使うと、実装そのものの時間は短縮されます。その結果、プロジェクト全体に占める「何を作るか決める時間」の比重が相対的に上がります。独立行政法人情報処理推進機構（IPA）が継続的に公表している「DX白書」などでも、日本企業のDXにおける人材・体制面の課題が繰り返し指摘されています。ツールが速くなっても、決める人がいなければ前に進まないという構造は変わりません。
逆に言えば、判断の速い組織ほどAI活用の恩恵が大きいということです。中小企業の場合、経営者と現場の距離が近く、その場で決められる強みがあります。これは大企業に対する実質的なアドバンテージになり得ます。
まとめ
AIを使った業務システム開発で成果を分けるのは、ツールの選択よりも指示の設計です。要点を整理します。
- 曖昧さを4分類で点検する — 範囲・境界・優先順位・責任。後ろ2つは発注側にしか決められません
- 指示は5層で書く — 目的／入出力／ルール／制約／受け入れ条件。特に受け入れ条件を先に言語化する
- 詰まる場所は事前に答えを用意する — 日付、権限、既存システム連携、データ移行、個人情報の扱い
- 完璧な仕様書より生の材料 — 現行のExcel、例外ルール、やらないことの一覧
- 決める速度が開発速度になる — 実装が速くなったぶん、意思決定がボトルネックになります
弊社では、この「決める部分」を一緒に整理するところから受注開発をお引き受けしています。要件が固まっていない段階でのご相談でも構いません。むしろ、固める前のほうが手戻りを減らせる場面は多くあります。まずは現在お使いのExcelや業務の流れをお聞かせいただければ、どこから着手すべきかをご提案します。