AIに「こういう機能を作って」と頼めば、動くものはすぐにできます。画面が表示され、データが保存され、一通りの操作が通る。ここまでは、AIに仕事を任せ始めた人なら、すでに経験しているはずです。
私たちがエージェント型のコーディングツールで開発を進める中でも、そうでした。ところが、動くものができた後で、同じ種類の問題が何度か見つかりました。URLのIDを変えると他人のデータが見えた。処理が止まっても、何が起きたのか追えるログがなかった。同じ処理が同時に走ると、二重に登録された。どれも、機能としては「動いて」いました。
なぜ、こうなるのか。私たちの見方はこうです。AIは、頼まなかった品質を作るとは限りません。しかも、入っていないことに気づく仕組みは、AIの実装とテストの中にはありません。この記事では、私たちが実際に抜け落とした三つの品質と、それがテストをすり抜けた理由、そして非機能の条件をどこに書けば実装に入るのか、という私たちの考えを紹介します。
非機能要件とは、「何ができるか」の外側にある条件
システムへの要求は、大きく二つに分けられます。「注文を登録できる」「履歴を検索できる」のような、何ができるかを決めるのが機能要件です。それに対して、どのくらい速いか、止まったらどう復旧するか、誰がどこまで見てよいか、同時に使われたらどうなるか、といった、動き方の質を決めるのが非機能要件です。
機能要件は、依頼の中に自然と入ります。「注文を登録できるようにして」と頼めば、それが機能要件です。一方、非機能要件は、依頼の目的の外側から来ます。業務のルール、運用の都合、悪意のある利用者、同時に使う人の数。これらは「注文を登録できるようにして」という一文のどこにも書かれていません。
以前の記事「目的だけ渡したら、AIが頼んでいない仕様を育て始めた」では、AIが頼んでいない検査（作業結果に付けたメモの値の照合や、ファイルのハッシュ値の一致確認）を自分で足し続けた話を書きました。AIが何も足さないわけではありません。AIが自分から足すのは、渡された目的に直結する「より確実な手段」です。目的の外側から要る条件は、言葉にして渡さなければ入らない。私たちはそう理解しています。
私たちが抜け落とした、三つの品質
いずれも、AIに任せた開発で、頼んでいなかったために入っておらず、後から足したものです。実際の業務仕様は書けないので、何が足りなかったかの種類だけを書きます。
セキュリティ：権限の確認と、秘密情報の扱い
一つ目は、権限の確認がなかったことです。URLやIDを書き換えるだけで、他人のデータが見えました。機能としては正しく動いています。自分のデータを見る操作は、何の問題もなく通るからです。
二つ目は、鍵やパスワードのような秘密情報が、コードや設定に平文で入っていたことです。これはテスト環境では便利でした。問題は、本番に入れる前に外す、という観点が抜けていたことです。AIの問題というより、私たちの管理の問題だったかもしれません。
どちらも、総合テスト（システム全体を業務の流れに沿って確かめる工程）の障害報告で見つかり、本番に出す前に直しています。
運用容易性：ログと、環境ごとの設定
処理が止まったとき、何が起きたのかを追えるログがありませんでした。開発中は、目の前で動かしているので、止まれば画面で分かります。本番では誰も見ていません。後から追えるかどうかは、運用に入って初めて問われます。
設定が環境ごとに分かれていなかったことも、本番に入れる段階で問題になりました。環境ごとに変わる値が、分けて扱われていなかったためです。
これらも、総合テストの障害報告で見つかり、本番に出す前に直しています。
同時実行への備え：レースコンディション
三つ目は、いちばん見つけにくいものでした。結果は二重登録のような機能の誤りとして現れますが、その原因になる「同時に使われる」という条件は、依頼の外側にあります。レースコンディションとは、二つ以上の処理が同時に走ったときに、その順序や間合いによって結果が変わってしまう状態のことです。私たちの場合、同じ処理が同時に走ると、二重に登録されたり、数が合わなくなったりしました。また、ある処理が値を読んでから書き戻すまでの間に、別の処理が割り込んで、片方の更新が消えることもありました。
これは、総合テストでは見つかりませんでした。処理が重なる状況は、意図して作らなければテストでは起きないからだと、私たちは考えています。表に出たのは、負荷がかかる状況になってからです。最初は、原因のよく分からない不具合として報告されました。
なぜ、テストをすり抜けたのか
三つに共通しているのは、機能のテストでは見つからないことです。権限の抜けは、悪意のある操作をしなければ出ません。ログの不在は、止まってみなければ困りません。レースコンディションは、同時に動かさなければ起きません。どれも、正常な操作を一人で一度だけ行うテストでは、通ってしまいます。
そして、AIに任せた開発では、テストもAIが書きます。AIが書いたテストは、AIが実装したときと同じ理解の上に立っています。依頼の外側にある条件は、実装で抜けるのと同じ理由で、テストからも抜けます。この点は「人にとって保守しやすいコードは、AIにとっても保守しやすいのか」でも、業務のバリエーションの網羅について書きました。
つまり、非機能要件は、頼まなければ入る保証がなく、入っていないことを知らせる仕組みも、AIの実装とテストの中にはありません。見つかるのは、総合テストのように別の目で見られたとき、あるいは負荷などの条件が実際にそろったときです。「AIに任せた開発が、システム連携でつまずく理由」で書いた二重送信も、同じ構図でした。同じ依頼を2回受けても結果が1回分になる性質（冪等性）が、頼まなかったので入っていなかったのです。
どこに書けば、実装に入るのか（私たちの方針）
正直に書くと、私たちはここまでの三つを、それぞれ個別の障害として調査し、直しただけです。開発のルールを作り直すところまでは、まだ進んでいません。ここからは、この経験から考えている方針です。
非機能の条件を、毎回の依頼文に書くのは現実的ではありません。依頼のたびに「権限も確認して、ログも出して、同時実行も考えて」と書き続けることはできませんし、書き忘れた依頼から抜けます。置き場所は、依頼文の外にあるべきだと考えています。
- 作業ルールに、毎回守る条件として書く。作業ルールとは、AIが作業を始めるたびに読む決まりごとのファイルです。「データを返す処理は、呼び出した利用者にそのデータを見る権限があるかを確認する」「秘密情報はコードと設定に直接書かず、環境ごとに外から与える」「同じデータを複数の処理が更新しうる場合は、同時実行を前提に設計する」といった、業務によらず毎回当てはまる条件を置きます（文面は説明用の例です）。作業ルールを書き足すときの注意は「コードは継ぎ足せても、文章は継ぎ足せない」に書きました。
- 完成の基準に、確かめられる形で書く。「他人のIDを指定したら拒否される」「同じ登録を同時に2回送っても、登録は1件になる」「処理が途中で止まったら、どこまで進んだかがログで分かる」のように、できたかどうかを判定できる文にします。何ができれば完成かを人が書く、という点は「すぐ古くなる前提で作る」でも触れました。
- テストの題材として、意図して作らないと起きない状況を渡す。同時実行、応答の喪失（送った処理の結果が返ってこず、送り直される状況）、他人のIDでのアクセス、設定のない環境での起動。こうした状況は、AIに任せたテストからは出てきにくいので、人が一覧にして渡します。
三つに分けるのは、性質が違うからです。作業ルールは「作るときに守ること」、完成の基準は「できたと言える条件」、テストの題材は「壊そうとして試すこと」です。一つの条件が三つの場所に別の形で現れることもあります。たとえば権限なら、ルールには「確認する」、基準には「他人のIDは拒否される」、題材には「他人のIDでアクセスする」と書きます。
何を盛り込めばよいか分からないときは、既存の一覧から選ぶ
ここまで読んで、「そもそも、非機能の条件として何を挙げればよいのか分からない」と感じる方もいると思います。経験が浅いうちは、権限、ログ、同時実行といった項目そのものを知らないのがふつうです。私たちも、障害として出てから気づいたものばかりでした。
この問題には、先人が作った一覧があります。IPA（情報処理推進機構）の「非機能要求グレード」は、非機能要件を、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目に整理し、項目ごとに要求の水準（レベル）と、システムの重要度に応じたその目安（グレード）を示したものです。発注する側と開発する側の間で、非機能要求の認識の行き違いを防ぐために作られました。[1] 私たちが抜け落とした権限の確認とログは、この一覧ではセキュリティと運用・保守性に当たります。
全部を満たす必要はありません。一覧を眺めて、自分の業務で要る項目を選び、それを上の三つの場所に落とす。それだけで、「知らなかったので頼まなかった」という抜けは減らせるはずです。私たちもまだこの一覧を使っていないので、これも試していない方針です。
システムの開発を発注する側の方へ
非機能の条件には、発注する側にしか分からないものが多くあります。次の点を早い段階で伝えていただけると、AIに任せる開発でも抜けを防ぎやすくなります。
- 誰が、どのデータを見てよいか。部署や役職による違い、取引先ごとの区別など。
- 同時にどのくらい使われるか。月末や締め日など、集中する時間帯があるか。
- 止まったときに、誰がどう気づき、どう復旧したいか。運用の体制と、許容できる停止時間。
まとめ：動くものと、業務に出せるものの間
AIは、依頼の内側にあるものをよく作ります。依頼の外側にある条件は、言葉にして渡さなければ入る保証がなく、入っていないことを知らせる仕組みも、AIの実装とテストの中にはありません。私たちが抜け落とした権限の確認、ログ、同時実行への備えは、どれもそうでした。
だから、非機能の条件は、依頼文ではなく、作業ルール、完成の基準、テストの題材に書く。何を書けばよいか分からなければ、既存の一覧から選ぶ。これが、動くものを業務に出せるものにするために、私たちがこれから試そうとしていることです。
参考資料
- IPA（独立行政法人情報処理推進機構）. システム構築の上流工程強化（非機能要求グレード）紹介ページ。非機能要求グレード2018の本体、利用ガイド、項目一覧などを公開。プロジェクトは終了しアーカイブ扱いだが、資料は入手できる。
注文の登録、在庫の例は、説明のために構成したものです。資料確認日：2026年11月10日