「生成AIを導入したのに、思ったほど楽にならない」
中小企業のIT支援をしていると、この相談を受ける機会が増えました。ツールは最新のものを入れている。技術者のスキルも低くない。それでも期待した効果が出ない。
原因を追っていくと、多くの場合、問題はAIの手前にあります。AIに渡している日本語が曖昧なのです。
AI駆動開発のボトルネックは、コード生成ではない
生成AIを使ったシステム開発の議論は、どうしてもコード生成やテスト自動化に集まります。目に見えて成果が出る領域だからです。
しかし実務上の制約は、その上流にあります。
大規模言語モデルは、渡された文脈を条件として出力を組み立てる仕組みです。条件が緩ければ候補は広く散らばり、出力は毎回ぶれます。条件を絞れば収束します。極めて素直な仕組みです。
つまり、要件定義書やプロンプトの曖昧さは、そのまま成果物の品質リスクに転化します。
裏を返せば、要件定義が弱い組織はAIを入れても成果が出ません。むしろ曖昧さが増幅されて返ってきます。「AI活用が進まない」の正体が、実は「要件定義が書けていない」であるケースは、決して珍しくありません。
日本語は、曖昧なまま成立してしまう言語
ここで日本企業には固有の不利があります。日本語の構造そのものが、曖昧さを許容するようにできているのです。
具体的には、次の4点です。
- 主語を省略できる：行為主体が人かシステムか判別できない
- 連体修飾が重なる：係り受けが多義的になる
- 範囲を閉じずに済む：「等」「など」「適宜」「必要に応じて」
- 程度を語感で表現する：「速やかに」「大量に」「原則として」
たとえば「承認後、速やかに通知する」という一文。日本の業務文書ではごく普通の表現ですが、誰が承認するのか、誰が誰に通知するのか、速やかにとは何時間以内なのか、いずれも指定されていません。
人間同士なら、文脈と経験で補えます。「これは部門長の承認で、システムが担当者にメール通知する話だな」と読み替えられる。
しかしAIは、欠けた部分を確率的に補完します。しかも補完したことを申告せず、もっともらしい出力として返してきます。
日本語の便利さが、そのまま品質リスクに転化する。これがAI時代に浮上した、新しい構造問題です。
要件定義書を「AIが読める日本語」にする6つのルール
では、どう手当てするか。私が中小企業に提案しているのは、次の6点を記述ルールとして明文化することです。
① 主語の明示 行為主体を必ず記述し、人が行うのかシステムが行うのかを区別します。「通知する」ではなく「システムが担当者に通知する」と書きます。
② 一文一義 接続助詞で文を連結せず、短文に分解します。「〜し、〜のうえ、〜する」という書き方をやめるだけで、解釈のブレは大きく減ります。
③ 曖昧語の禁止 「等」「など」「適宜」「必要に応じて」を使いません。対象を列挙し切るか、「これ以外は対象外」と明示して範囲を閉じます。
④ 定量表現 期間・件数・閾値を数値で記述します。「速やかに」は「1営業日以内に」、「大量に」は「1万件以上」と書き換えます。
⑤ 例外条件の前置 適用除外を後段に埋め込みません。例外は本文の前に置き、読み手が原則と例外を取り違えないようにします。
⑥ 用語の統一 表記ゆれを排し、用語集を整備して運用します。「顧客」「取引先」「得意先」が混在する文書は、それだけで解釈が割れます。
いずれも新しい技術ではありません。要件定義の基本と言ってもいい内容です。
技術者の文章力は、能力ではなく訓練の問題
長年この業界にいて感じてきたことがあります。
コードは正確に書ける技術者でも、日本語の仕様書となると曖昧になりやすい。これは能力の問題ではなく、そのための訓練を受ける機会がなかっただけだと考えています。
プログラミング言語は、曖昧さを許しません。書いた通りにしか動かないので、書き手は嫌でも厳密になります。一方、日本語の文書は曖昧でも受理されてしまう。誰も指摘しないまま、何年も過ぎていきます。
裏を返せば、ここは組織として手当てできる領域です。
- 要件定義書のレビュー基準に「主語の明示」「曖昧語の排除」を組み込む
- 技術者への文章訓練を、技術研修と同等に位置づける
- 業務側とIT側の共通言語として、記述ルールを整備する
いずれも、新規のライセンス費用やインフラ投資をほとんど必要としません。
中小企業にとって、最も費用対効果の高いAI準備
AI活用で削減できるのは「作る時間」です。一方で増えるのは「決める時間」であり、その大半は言語化の工数です。
つまり、生成AIの導入効果は、組織の言語化能力の上限で頭打ちになります。ツールを高性能なものに替えても、この上限は上がりません。
だからこそ、中小企業にとって記述ルールの整備は、最も費用対効果の高いAI準備だと考えています。数百万円のツール導入より先に、要件定義書のフォーマットとレビュー基準を見直す。順序が逆になっている組織が、非常に多いのが実感です。
そして副次効果として、人間同士のコミュニケーション品質も向上します。仕様の認識違いによる手戻り、担当者交代時の引き継ぎ漏れ、ベンダーとの認識齟齬。これらは要件定義書の曖昧さに起因することが大半です。
AI対応と開発品質の改善が同じ方向を向く。数少ない、迷わず着手できる施策だと思います。
まずは、一文から
すべてを一度に変える必要はありません。
手元にある要件定義書を1ページだけ開いて、次の3点を確認してみてください。
- すべての文に主語が書かれているか
- 「等」「適宜」が使われていないか
- 一文が3行を超えていないか
おそらく、いくつも見つかると思います。それが、御社のAI活用の伸びしろです。
参考記事 日経クロステック「AIに任せるほど言語化が重要に、『カクヤス』が実践で得たAI駆動開発の本質」（2026年9月2日） https://xtech.nikkei.com/atcl/nxt/column/18/03734/082800003/
コメント