見出し画像

生成AIに修正案を作らせた。その後、人が確認したこと

【公式】株式会社ディーシステム

既存の文書検索システムに、PDFリンクを追加する。

検索結果から、そのままPDFを開けるようにする改修です。

担当者は、対象システムの構成と変更仕様を整理し、生成AIへ修正案を求めました。

すると、コードはすぐに返ってきました。

必要なデータがそろい、想定した場所にPDFがあれば、URLを作れそうな内容です。

では、そのまま既存システムへ入れられるのでしょうか。

ここで、人の仕事が始まりました。

必要なデータが欠けていたら、どうなるのか。指定した場所にPDFがなかった場合、何を返すのか。URLの生成中にエラーが起きても、検索結果まで止まらないか。PDFではないデータへ、誤ってリンクを付けないか。

正常な条件で動きそうなことと、既存システムへ組み込めることは、同じではありませんよね。

生成AIが作ったのは、完成した答えではありません。

対象システムの構成や実データへ照らし、異常時の動きを確認しながら、何を守るのかを決めるための実装案でした。

今回の事例から見えてきたのは、AIがどこまでコードを書けるかではありません。

AIがコードを書いた後、エンジニアが何を確認し、どのように業務で使える変更へ仕上げたかです。

AIへ聞く前に、人が仕様を整理する

生成AIへ「PDFリンクを追加して」と頼めば、何らかのコードは返ってくるかもしれません。

でも、どの検索結果へリンクを付けるのでしょうか。PDFの保存場所は、どの情報から特定するのでしょうか。バックエンドは画面側へ何を返し、フロントエンドはどこへリンクを表示するのでしょうか。

既存の検索処理へ、どこまで影響させてよいのかも決めなければなりません。

ここが曖昧なままでは、生成AIも足りない前提を補いながらコードを書くことになります。

その前提が、実際のシステムと合っているとは限りませんよね。

今回、担当者は生成AIへ依頼する前に、対象システムの構成を調べました。

ブラウザから検索結果が返るまでに、どの処理を通るのか。PDFはどこに保存され、検索結果のデータはどこで作られているのか。バックエンドとフロントエンドは、それぞれ何を担っているのか。

その上で、改修仕様を整理しました。

これは、単なるプロンプト作成ではありません。

要件と必要なデータを確認し、処理の責務を分け、変更する場所と変更しない場所を決める。

すでに、設計の仕事が始まっています。

生成AIがコードを書き始める前に、人は「何を作らせるのか」を決めなければなりません。

曖昧な依頼から、業務で使える変更は生まれにくいからです。

一つのAIで作り、別の視点でレビューする

担当者は、一つの生成AIへ仕様を渡し、修正案を作らせました。

その後、別の生成AIへ元の仕様と生成された修正案を渡し、レビューを求めています。

一度作った案を、そのまま採用しなかったのです。

別のAIに見せれば、安全になる。

そういう単純な話ではありません。

二つのAIが同じことを言ったからといって、そのコードが対象システムへ適合する証明にはなりませんよね。

ここで増やしたのは、正しさの保証ではなく、確認の視点です。

一つ目のAIが見落としている条件はないか。仕様とコードがずれていないか。例外が起きたとき、どこまで処理が止まるのか。

別の角度から問題候補を探すために、レビュー工程を置きました。

そして、その指摘を採用するかどうかは、人が判断しています。

AIが出した案と、別のAIが示した指摘。既存コードの構造や実際のデータ、守るべき既存機能。

それらを照らし合わせて、変更内容を決めました。

生成AIは、考える材料を増やせます。

ただ、どの指摘が今回のシステムに当てはまるのかを決めるには、そのシステムを知っている人が必要です。

正常に動くコードでも、既存システムには入れられない

生成された初期案は、必要なデータがそろっている場合には、PDFのURLを作れそうな内容でした。

対象がPDFで、ファイル名が想定した形式になっている。必要なフォルダ情報があり、指定した場所にPDFも存在する。

こうした条件がそろえば、正常に動く可能性があります。

では、一つでも前提が外れたら、どうなるのでしょうか。

必要なデータがない。ファイル名が想定した形式ではない。指定した場所にPDFがない。検索結果がPDFではない。URLの生成中に例外が起きる。

既存システムでは、常に理想的なデータだけが来るとは限りません。

過去に登録されたデータもあれば、異なる形式のファイルや、一部の情報が欠けたデータもあります。

正常なデータを一つ通し、URLが作れれば、コードは動いたように見えます。

ただ、既存システムへ入れるなら、それだけでは足りませんよね。

前提が崩れたときに何が失敗し、その影響がどこまで波及するのか。

AIが書いたコードだけでなく、AIが書かなかった前提まで読む必要があります。

PDFリンクの失敗で、検索全体を止めない

初期案を確認すると、PDFのURL生成中に例外が起きた場合、検索結果全体の生成処理まで失敗する可能性がありました。

PDFリンクは、今回新しく追加する機能です。

一方、検索結果を返す処理は、すでに使われている既存機能です。

PDFリンクを作れなかったとき、検索結果まで返らなくなってよいのでしょうか。

それは違いますよね。

PDFを直接開けなくても、検索結果そのものは利用できます。

リンクの追加に失敗したために、これまで見られていた検索結果まで失う必要はありません。

そこで、設計を見直しました。

URLの初期値を空にし、検索結果ごとに例外を処理する。URLの生成に失敗しても検索結果自体は返し、PDFリンクだけを表示しない。PDFではないデータには、URLを付けません。

ここで行ったのは、例外処理を一つ追加したことだけではありません。

どの失敗は許容し、何は止めずに守るのか。

その境界を決めています。

担当者が守ろうとしたのは、新しく加えるPDFリンクではありません。

これまで動いてきた検索機能です。

新機能を追加するとき、その機能を動かすことばかりに目が向きやすいですよね。

でも、既存システムの改修では、追加機能が失敗したときに、既存機能を巻き込まないことも考えなければなりません。

AIが作った案を、実際のシステムへ合わせる。

その中心にあったのは、コードの書き方ではなく、守る対象を決める設計判断でした。

AIの前提を、実データで確認する

コードの中には、さまざまな前提が埋め込まれています。

この項目にはフォルダ名が入り、別の項目にはファイル名が入る。ファイル名は決まった形式で、指定した保存先には対象のPDFが存在する。だから、文字列を組み合わせれば正しいURLになる。

コードだけを読むと、自然に見える前提もあります。

ただ、その前提は、実際のデータや保存規則と一致しているのでしょうか。

担当者は、検索結果のデータ構造とファイルの保存方法を追いました。

どのデータからフォルダ名とファイル名を取得するのか。PDFであることを、どの条件で判定するのか。該当するファイルがない場合はどう扱い、保存場所とファイル名の規則が実環境でも成り立っているのか。

確認を進めると、前提が外れた場合に、存在しないURLを作ったり、意図しないファイルを参照したりする可能性が見えてきました。

生成AIは、渡された仕様とコードから、処理の形を作ることができます。

でも、顧客環境のデータが、どのように蓄積されてきたかまでは自動的には分かりません。

例外的なファイル形式があるのか。過去データに欠損があり、保存規則が途中で変わっていないか。

そこは、人が実データへ照らして確認します。

担当者が読んだのは、AIの処理だけではありません。

AIが前提にした世界と、実際のシステムが一致しているかを確認したのです。

AIのコードを評価するには、全体構成を知らなければならない

生成AIがコードを書いてくれるなら、システム構成を詳しく理解しなくてもよい。

そう考えたくなることもありますよね。

今回の事例では、むしろ逆でした。

AIが出したコードは、検索処理のどこへ入るのか。URLの生成に失敗した場合、どの処理へ影響するのか。バックエンドが返すデータを変えると、画面側はどう動くのか。既存の検索結果へ影響させずに変更できるのか。

これらを判断するには、提案されたコードより広い範囲を見る必要があります。

担当者は、生成AIを使う前に、ブラウザから検索結果が返るまでの処理経路を調べていました。

Webサーバーとアプリケーションが、それぞれ何を担い、PDFがどこに置かれているのか。検索結果のデータはどの処理で作られ、バックエンドとフロントエンドの責務はどう分かれているのか。

その理解があったからこそ、AI案の影響範囲を考えられました。

どの処理を変更し、どの処理には触れないのか。失敗した場合はどこで止め、既存機能の何を残すのか。

AIを使うほど、人がシステムを理解しなくてよくなるわけではありません。

AIの案を評価するために、システム全体を見る力が必要になります。

AIのレビューを、人の判断だけで終わらせない

一つ目の生成AIが案を作り、別の生成AIがレビューする。人が既存システムと実データへ照らして確認する。

これで改修案は整いました。

では、担当者が一度確認すれば、それで十分なのでしょうか。

人が判断した内容が、担当者の頭の中だけに残っていると、将来の変更時に同じ確認を繰り返せるとは限りません。

なぜこの例外処理を入れたのか。なぜURL生成に失敗しても検索結果を返すのか。どのデータにはリンクを付けてはいけないのか。

時間がたち、別の人がコードを変更すると、その判断の背景が見えにくくなることがあります。

そこで、人が確認した内容をテストへ変えました。

正常にURLを生成できることだけでなく、PDFではない場合にはURLを付けないこと、必要なデータが欠けていても検索結果を返すこと、URL生成に失敗しても既存の検索処理が続くこと、既存の検索結果へ影響しないことを確認します。

何を守るべきかという判断を、繰り返し実行できる条件として残したのです。

別の生成AIにレビューさせ、人が確認して終わりではありませんでした。

レビューで見つけた観点を、将来も確かめられる形へ変えています。

最後はテストで、繰り返し確認できる状態にする

担当者は、修正した案について、単体テストと結合テストを作成しました。

自動テストも実行し、用意した条件で結果を確認しています。

ただ、テストの数が多ければ、安全だと証明できるわけではありませんよね。

見るべきなのは、どの条件を確認したかです。

必要な情報がそろい、正常にURLを作れる場合。検索結果がPDFではない場合。ファイル名や保存先の情報が欠けている場合や、対象ファイルが見つからない場合。URL生成中に例外が起きた場合。

そうした条件でも、検索結果そのものは返り、既存の検索結果や画面表示へ影響しないことを確認しました。

人が一度確認しただけでは、その判断は個人の経験にとどまります。

テストへ変えることで、同じ条件を繰り返し確認できます。

今後、別の修正が入ったときにも、守ると決めた動作が変わっていないかを確かめられます。

AIの提案をレビューしたことよりも、そのレビュー結果をテストとして残したこと。

そこに、業務で使うための最後の一歩がありました。

AI生成コードの後に確認すること

今回の事例から、AI生成コードを既存システムへ入れる前に確認すべき観点が見えてきます。

前提は合っているか

AIへ渡した仕様は、実際の要件と一致しているか。データ形式や保存規則は、コードが想定したとおりか。必ず存在すると考えている情報に、欠損はないか。

変更範囲は適切か

どの処理を変更するのか。バックエンドとフロントエンドの役割を崩さず、変更しなくてよい処理まで巻き込んでいないか。

異常時に何が起きるか

データやファイルがない場合、形式が違う場合、一部の処理だけが失敗した場合に、その影響がどこまで波及するのか。

既存機能を守れるか

追加機能が動かなくても、既存機能は使えるか。戻り値やデータ構造を壊し、別の画面や処理へ影響させていないか。

テストで再確認できるか

正常系だけでなく異常系も再現できるか。既存機能への影響を確認し、人が判断した内容を将来も繰り返し確かめられるか。

チェック項目を増やすことが目的ではありません。

このシステムでは、何を守るべきか。

その判断に合わせて、確認する内容を決めます。

AIの出力を、業務で使える変更へ変えるのは人である

生成AIは、仕様からコード案を作れます。

別の視点でレビューし、問題候補を挙げたり、実装のたたき台を早い段階で用意したりすることもできます。

ただ、その案を既存システムへ入れるには、人の仕事が残っています。

仕様と実際の要件は一致しているか。AIが置いた前提は実データと合い、変更範囲は適切か。異常時にはどこまで失敗し、追加機能が動かなかったときに何を守るのか。

さらに、顧客環境へ適用できる形になっているかを判断し、その内容をテストで繰り返し確認できる状態へ変えます。

生成AIを使うとは、答えを受け取ることではありません。

検証すべき案を早く得て、人がシステムへ照らし、設計を変え、テストで確かめ、業務で使える変更へ仕上げることです。

AIが作ったコードを確認する人は、単なる間違い探しをしているわけではありません。

対象システムの構成とデータを理解し、何を止めずに守るかを決め、変更の責任範囲を定めています。

AIがコードを書く時代ほど、何を前提にし、何を守り、どこまで確認するかを決められるエンジニアの役割は大きくなります。

AIの案を、実務で使える変更へ仕上げる

ディーシステムでは、生成AIが出したコードを、そのまま答えとして扱いません。

システムの構成や実データへ照らし、異常時の影響を考える。既存機能を守れる形へ設計を見直し、最後はテストで確かめます。

AIを使うことと、エンジニア自身が判断すること。

その両方を、実務の中で大切にしています。

ディーシステムの生成AI活用や、エンジニアの仕事については、サービス情報・採用情報でも紹介しています。


次に読む記事

同じ改修を、別の視点から読む

同じ改修で、なぜシステム構成から確認したのか

生成AIへ修正案を求める前に、対象システムの構成、処理経路、既存コード、実データを確認しました。

当初考えていた改修方法を変更し、既存機能への影響が小さい方法を選ぶまでの判断を紹介します。

分からなかったシステムを、説明できるまでの成長

この改修を担当した社員は、最初からシステム全体を理解していたわけではありません。

基本用語を調べ、処理の流れを図にし、自分の案と不明点を整理する。その過程を、担当者の成長という視点から紹介します。

未経験の技術でも、AIを使えば納品まで進められるのか

生成AIを使えば、知らない言語の構文を調べたり、既存コードを読み解いたりする入口には立てます。

ただ、納品まで担うには、AIの出力を読み、既存実装へ合わせて直し、テストし、変更内容を説明できるところまで持っていく必要があります。

生成AIを、現場で使い続ける条件を読む

AI活用が、PoCの先で止まるのはなぜか

生成AIの出力を確認できても、それだけで組織への導入が進むわけではありません。

誰が使うのか。どの業務へ組み込むのか。誤りや例外をどう扱うのか。

実証実験の後に必要になる、業務・データ・運用の設計を考えます。

勉強会を開いても、現場で使われなかった理由

生成AIの基本的な使い方を説明し、勉強会で「使えそうだ」という反応を得ても、日常業務へ戻ると利用が止まることがあります。

知識を伝えることと、実際の仕事で使われ続けることの間に何が必要なのかを考えます。

AIで整えた報告から、何が消えるのか

生成AIを使えば、日報や報告書を短時間できれいに整えられます。

一方で、現場で迷ったこと、違和感を覚えたこと、判断の前提、未確認事項といった一次情報が削られる場合があります。

AIに文章を整えさせるとき、人が残すべき情報を考えます。