非エンジニアのAI開発のリスクをどう防ぐか｜全部レビューするより、すぐ直せる体制に

私たちが開発を支援しているお客様の会社で、エンジニアではない社員の方（非エンジニア）が、AIを使って自社の業務システムを直すようになってからの話です。技術者が変更の中身を確認することを、レビューと呼びます。

続けるうちに、見た目の調整はレビューを外し、設計やデータの持ち方に関わる変更だけを確認する形にしました。

技術者が確認するほど安全に思えるでしょう。ただ、私たちの考えは変わりました。鍵になるのが、フィードバックループです。

フィードバックループとは？

フィードバックは、作ったものを動かして分かったことを、次の修正に返すことです。バグは、システムの不具合を指します。

非エンジニアの変更を技術者は全部レビューすべきか

バグがあってもすぐに直せる体制は、AIの高速なフィードバックループと相性がよいと私たちは考えています。

実は、元に戻すのが大変な変更そのものが少なくなってきたと感じています。バックアップ（保存しておいたデータの写し）があれば最悪の場合も戻せますし、AIが危険なコード（システムを動かすプログラム）を出してくる可能性も低くなっています。

ソフトウェア開発を長く調査している Google Cloud の研究プログラム DORA も、変更のリスクを下げて規制上の決まりを満たすための承認について、同じ向きの報告をしています。

Traditionally, these goals have been met through a heavyweight process involving approval by people external to the team proposing the change: a change advisory board (CAB) or a senior manager. However, DORA’s research shows that these approaches have a negative impact on software delivery performance. Further, no evidence was found to support the hypothesis that a more formal, external review process was associated with lower change fail rates.

（訳）これまでは、変更を出すチームの外にいる人（変更を審査する委員会や上の立場の管理者）が承認する重い手続きで、この2つの目的を果たしてきました。ところが DORA の調査では、こうした手続きを踏むと、ソフトウェアを利用者に届ける仕事の成果に悪い影響が出ると分かっています。さらに、外の人の審査をより正式にすれば変更の失敗が減るという仮説も、証拠では確かめられませんでした。

引用: 「Streamlining change approval」（DORA、2025年10月更新）

全部レビューしない代わりに決めておく4つのこと

① 依頼は背景と課題から書く

依頼する人は、背景や課題を飛ばして、やり方から伝えてしまいがちです。

② AIの最初の一手を要件定義にする

私たちは、依頼の入口を仕組みとして強制することが必要だと考えています。

③ 顧客が使う画面のバグは軽くても通さない

顧客は、お客様の会社のサービスを利用する方を指します。

④ 人の確認が要るかは4つの見方で決める

以前は、変更がシステムのどこに触れるかで決めていました。いまは、失敗したときの被害が大きく元に戻すのも重い変更に、人の確認を集めています。

社員が自分たちでシステムの改修を回せるようになった

社員の方が自分で不具合に気づいて直したことを、私たちは良い兆候だと受け止めています。日々の業務は、私たちより現場の方のほうが解像度高く理解している部分が多いからです。無駄な外注費用が抑えられれば、私たちが本来やるべきことに集中するための予算もできます。

まとめ

• 以前は、社員の方の変更を技術者がすべてレビューしていた。いまは、ふだんの改修をほとんど確認していない
• バグのないシステムを検証して作るより、バグがあってもすぐに直せる体制にする
• 先に決めておくのは、依頼の書き方、AIの最初の一手、顧客が使う画面の扱い、人の確認が要る変更の決め方
• 直したい所がすぐ直り、社員の方が自分たちで改修を回せるようになった

非エンジニアの社員によるAI開発の進め方で迷っている方は、お気軽にご相談ください。