業務の言葉で書いた要求を、AI に開発者の言葉へ書き換えさせる── 要求は業務の言葉で書き、AI にシステム開発者が読める表現へ書き換えさせ、仮定を分けて読み返してから作らせると、作り違いを作る前に見つけられる

01運営者は、作らせる前に要求の書き換えを AI に頼んだ

2026 年 7 月、運営者は資材審査を手伝う仕組みを AI に作らせようとしていた。頼みたいことは四つあった。

一つ目は、判定の基準を仕組みの中に持たせること。二つ目は、電子添文や審査報告書、RMP、適正使用ガイドのような基準資料を、使う人が目的に合わせて貼り付けられる画面。三つ目は、審査を受ける資料をワード、PDF、パワーポイント、エクセルのどの形でも読み込めること。四つ目は、未承認薬や適応外の勧め、誇大な表現、他社製品の誹謗といった審査の条件を、画面で選べることである。

運営者はさらに、一つ目は作成中の部品ができるまで待ち、二つ目から四つ目は画面の側として先に作るよう分担を決めた。ここまでは、資材審査の仕事をしている人の言葉で書かれている。

そのうえで運営者は、すぐに作らせなかった。まずこの内容を、システム開発者が読んで分かる専門の表現に書き換えるよう求めた。記録に残っているのは依頼の側で、AI が返した書き換えの全文は残っていない。この回で扱うのは、この順序そのものである。

業務を知る人が AI に開発を頼むとき、要求はどの言葉で書けば正しく伝わるのか。答えは、業務の言葉で書き、AI に開発者の言葉へ書き換えさせ、その書き換えを自分で読み返してから作らせる、である。

02書き換えとは、一つの要求を「何を・どの形で・どの条件で」に分けることである

業務の言葉と開発者の言葉は、同じ要求の別の面を書く。業務の言葉は、何のためにそれが要るかを書く。開発者の言葉は、何を受け取り、何を返し、どの条件で動くかを書く。

たとえば「基準資料を貼り付けられる画面」は、業務の人には十分な指示である。開発者には足りない。資料の種類はいくつか、貼るのは文字かファイルか、貼った資料は次の審査でも使えるか、が決まっていないからである。

下の表は、運営者の四つの要求を開発者の言葉に書き換えた場合の例である。記録の中の AI の答えではなく、書き換えでどこが増えるかを示すために作った。

増えたものは、どれも業務の人が頭の中では決めている事柄である。書き換えは、その決めている事柄を紙の上に出す作業になる。決めていない事柄があれば、そこで初めて見つかる。

03作り違いの多くは、作る前の要求の段階で生まれる

情報処理推進機構が 2019 年に公開した「ユーザのための要件定義ガイド 第 2 版」は、システム開発の遅れの半分以上が要件定義の失敗から来ると述べている。要求が正しく伝わらないまま作り始めると、ずれは作った後に見つかる。

作った後に見つかるずれは、直すのに手間がかかる。画面を作り直し、つながる部品も直し、もう一度確かめる。要求の段階で見つかれば、文を一つ直せば済む。

ずれが生まれる理由の一つは、言葉が通じないことである。資材審査の人にとって「適応外」は説明の要らない語だが、開発者には意味が分からない。逆に、開発者にとって当たり前の「入力の検証」や「既定値」は、業務の人が決めるべき事柄だと気づかれにくい。

AI に書き換えさせる手順は、この二つの言葉の間に一段を置く。業務の人は自分の言葉で書いてよく、開発者は自分の言葉で読める。両方を知る人を毎回探さなくても、最初の書き換えは AI にできる。

04よい書き換えは、解釈が一つで、確かめられる要求になっている

要求の良し悪しには、国際規格 ISO/IEC/IEEE 29148 が示す条件がある。この規格は、一つ一つの要求が満たすべき性質を九つ挙げている。業務の言葉を書き換えるときに特に効くのは、次の四つである。

書き換えには境界もある。第一に、AI が書き換えるのは言葉であって、業務の決まりではない。どの審査条件を入れるか、どの資料を基準にするかは、業務の人が決める。

第二に、AI は足りない事柄を推測で埋めることがある。ファイルの上限や既定の選択のように、元の要求に書かれていない数や動きが書き換えに出てきたら、それは AI の仮定である。仮定は仮定として印を付けさせ、業務の人が決め直す。

第三に、開発者の言葉に変えても、目的の一文は残す。何のためにその機能が要るかが消えると、開発者は条件に合っていても役に立たないものを作れてしまう。

05資材審査の条件は、規制の項目と判定の定義の両方が要る

この手順が最も効くのは、業務の決まりが細かく、開発者がそれを知らない場面である。資材審査の仕組みはその典型である。

運営者が選べるようにしたかった審査の条件は、厚生労働省が 2018 年 9 月に出した「医療用医薬品の販売情報提供活動に関するガイドライン」の項目と重なる。このガイドラインは、虚偽や誇大な表現、承認された効能・効果や用法・用量以外の使用を勧めること、他社製品を誹謗・中傷して自社製品を優れたものと訴えること、などをしてはならない行為として挙げている。比較試験では、試験の設計と結果を正確に示すことも求めている。

開発者に渡すには、この項目だけでは足りない。条件ごとに、何を入力に取り、何を返すかを決める必要がある。

同じ型は、審査の仕組みに限らず使える。社内の文書管理の改修を情報システム部門に頼むとき、外部の開発会社に見積もりを頼むとき、メディカルの問い合わせ記録の項目を増やすときにも、業務の人の言葉と作る人の言葉は分かれる。

どの場面でも、規制や社内規程の解釈は業務の側に残る。AI の書き換えは、その解釈を開発者が読める形にするところまでである。

06AI は両方の言葉を書けるが、あなたの業務の前提は知らない

AI がこの書き換えに向いているのは、業務の文書と技術の文書の両方の書き方を知っているからである。要求を機能・入力・出力・条件に分けて書く型は、開発の世界で広く使われており、AI はその型で書ける。

研究もこれを支える。2024 年に Lubos らが発表した論文は、大規模言語モデルに ISO 29148 の性質で要求の質を判定させ、改善案を出させた。モデルは要求の欠点を 74〜89% の割合で見つけ、技術者は提案された書き換えの 66〜100% を改善と評価した。一方で、判定が最初から技術者と一致したわけではなく、技術者がモデルの説明を読んでから一致が大きく上がった。

AI に欠けているのは、業務の前提である。Anthropic が公開している Claude への指示の書き方の指針は、Claude を、能力は高いが仕事の決まりや進め方を知らない新しい同僚として扱い、望むことを正確に説明するよう勧めている。指示の背景や目的を伝えると、目的に合った答えが返りやすいとも書いている。

だから書き換えの依頼には、目的と読み手を書く。目的は、何のための仕組みか。読み手は、システム開発者である。それでも AI は前提の欠けを推測で埋めるので、書き換えを業務の人が読み返す段が要る。

07明日からは、業務の言葉で書き、書き換えさせ、読み返してから作らせる

手順は五つある。

1. 業務の言葉で、要求に番号を付けて書く。何のための仕組みか、誰が使うか、何を扱うか、何を判断するかを、ふだんの言葉で書く。分担や順番が決まっていれば、それも書く。
2. 読み手を指定して書き換えを頼む。「システム開発者が読める専門の表現に書き換えて」と頼み、要求ごとに機能・入力・出力・条件・できたと言える基準の五つで書くよう形を指定する。
3. 仮定と未決の点を分けて出させる。元の要求に無かった数や動きには印を付けさせ、決めるべき点を一覧にさせる。
4. 業務の言葉に戻させて読み返す。書き換えを、もう一度業務の言葉で要約させる。最初の要求と比べ、意味が変わった箇所を直させる。
5. 決めた版だけを作らせる。仮定を一つずつ決めてから、その版で開発を頼む。最初の要求と書き換えは並べて残しておく。

一つ目と五つ目の判断は人が行う。二つ目から四つ目は AI に任せられる。四つ目を省くと、AI の推測がそのまま仕様になり、作った後でずれに気づくことになる。