録音データ、NotebookLM、Codexで業務システムの機能追加をほぼ1日で形にした話

はじめに

ある既存業務システムに対して、条件分岐の多い新規機能を追加する機会がありました。

詳細なプロジェクト名や作った機能の中身は出せないのですが、ざっくり言うと、ユーザーの状態や所属情報に応じて表示内容や操作可否を切り替え、既存データと連携しながら状態を更新する画面です。

今回よかったのは、AIにいきなり実装を頼んだことではありません。録音データから要件を起こし、NotebookLMで論点を整理し、Codexで既存コードを読みながらPRDと実装まで一気通貫で作れたことです。

結果として、ほぼ1日でレビュー可能な状態まで持っていけました。

何が難しかったか

新規機能といっても、完全に独立した小さな画面を作るだけではありませんでした。

既存の業務システムには、すでにユーザー情報、権限や状態判定、操作履歴、環境ごとの設定値、運用上の確認フローがありました。今回の機能は、それらをまたぎながら動く必要がありました。

難しさは主に次の点です。

ユーザーごとに表示すべき内容が変わる
既存データを見て、ユーザーごとの状態を判定する
状態に応じて、次に取れる操作を出し分ける
本番環境と検証環境で参照する設定値が違う
既存の運用ルールに合わせてデータを更新する必要がある
口頭で共有された要件に、確定事項と未確定事項が混ざっている

つまり、単純なCRUD画面ではなく、「既存業務のルールを壊さずに、新しい導線を足す」タイプの開発でした。

使ったもの

今回使ったのは、録音データ、NotebookLM、Codexです。

録音データ: 打ち合わせで出た背景、条件、例外、運用上の注意点を残す
NotebookLM: 録音内容から要件、論点、確認事項を整理する
Codex: 既存コードを調査し、PRD化し、実装する

この組み合わせが効いた理由は、口頭の情報をそのままコードにしなかったことです。

口頭の依頼は、実装に必要な順番で話されるとは限りません。「この場合は表示する」「でもこのユーザーは例外」「この条件を満たすまでは出さない」「更新処理は既存処理に合わせたい」といった情報が、会話の中に散らばります。

そこで、まず録音を残し、NotebookLMで論点を並べ替えました。そのうえで、Codexに既存コードを読ませながら、実装できる粒度に落としました。

まず要件を構造化する

最初にやったのは、録音内容を次の観点で分解することでした。

この機能の目的
対象ユーザー
表示条件
状態判定の方法
再操作や状態更新の扱い
操作可否を切り替える条件
検証環境と本番環境の差分
実装前に確認すべき未確定事項

この時点では、まだコードを書きません。

先に「何を満たせば完成なのか」を整理します。ここを飛ばすと、AIはそれっぽいコードを書けますが、業務ルールに合っているかを判断しづらくなります。

PRDを作ってから実装する

次に、Codexで既存コードを読みながらPRDを作りました。

PRDでは、実装フローを次のような粒度まで落としました。

ログイン情報や画面遷移時の情報から対象ユーザーを特定する
ユーザーの状態情報を取得する
所属やターゲット条件を取得する
表示対象の項目を決める
環境に応じて参照する設定値を切り替える
既存データから操作済みかどうかを判定する
状態に応じて操作導線を出し分ける
状態更新では既存運用に合わせて履歴を残し、関連データを更新する

ここまで分解すると、実装時の迷いがかなり減ります。

特に既存システム上の開発では、「新しく作るロジック」と「既存に合わせるロジック」を分けて考える必要があります。AIに任せる場合でも、この境界を明確にしておくと手戻りが減ります。

実装で意識したこと

実装では、既存画面で使われているフロントエンド構成やデータ取得方法に寄せました。

新しい技術スタックを持ち込むよりも、既存の保守者が読める形にすることを優先しました。AIを使うと、つい新しい書き方やきれいな抽象化を入れたくなりますが、業務システムでは「周囲のコードと同じ文法で読める」ことが重要です。

状態管理では、次のような役割に分けました。

ユーザーの状態を確認するデータ
対象条件を確認するデータ
操作状態を確認するデータ
履歴として残すデータ

実名の保存先は出せませんが、ポイントは「画面に表示するための状態」と「運用上残すべき履歴」を分けたことです。

また、環境差分も最初から設定として持たせました。検証環境と本番環境で参照先が違う場合、あとから文字列を差し替える運用にすると事故りやすくなります。環境判定を通して、必要な設定値を切り替える形にしました。

レビューの指摘をプロンプトに入れる

今回もう1つ効いたのが、過去のコードレビューで注意を受けたことを、あらかじめCodexへのプロンプトに入れたことです。

たとえば、既存コードの書き方に合わせること、既存の運用ルールから外れた実装にしないこと、確認が必要な前提を勝手に決め打ちしないことなどです。

AIに「この機能を作って」とだけ依頼すると、動くコードは出てきても、過去にレビューで問題になった癖をまた踏むことがあります。そこで、以前指摘された観点を先に渡しておくことで、最初の出力からレビューしやすい形に近づけました。

これはかなり実用的でした。プロンプトは単なる依頼文ではなく、自分たちのレビュー基準をAIに渡す場所でもあると感じました。

AIに任せたこと、任せなかったこと

AIに任せたのは、主に次の作業です。

録音から出てきた要件の整理
PRDの下書き
既存コードの調査
実装方針の整理
コードの初稿作成

一方で、人間側で判断したこともあります。

要件として何を優先するか
既存運用に合わせるべき箇所はどこか
本番反映前に確認すべき項目
AIが作った実装が業務上の前提を外していないか

特に業務システムでは、AIがコードを書けることよりも、既存運用に合っているかを判断することのほうが重要です。

ほぼ1日でできた理由

速かった理由は、AIが速いからだけではありません。

録音データがあり、会話の情報を取りこぼさなかったこと。NotebookLMで要件を構造化したこと。Codexに既存コードを読ませて、既存設計に合わせたこと。そして、過去レビューで受けた注意点をプロンプトに入れたこと。

この4つがそろうと、開発の待ち時間がかなり減ります。

従来なら、打ち合わせ後に議事録を作り、要件を整理し、既存コードを調べ、実装し、動作確認し、最後に資料を作る、という流れになります。今回はその各工程をAIで圧縮しつつ、人間が判断すべきところに集中できました。

注意点

もちろん、AIを使えば何でもそのまま本番投入できるわけではありません。

録音から起こした要件には、確定情報と未確定情報が混ざります。設定値、表示開始条件、状態更新条件、通知や履歴の扱いなどは、最終確認が必要です。

また、AIが生成したコードは、動くように見えても業務運用上の前提を外す可能性があります。既存のデータ更新ルールに合っているか、履歴を残すべき場所に残しているか、環境判定が既存と一致しているかは、人間が確認する必要があります。

今回の成果も、「AIで1日で本番リリースした」というより、「AIを使って、1日でレビュー可能な状態まで持っていけた」と捉えるのが正確です。

まとめ

今回の開発では、録音データ、NotebookLM、Codexを組み合わせることで、口頭の依頼からPRD、実装までをほぼ1日で作ることができました。

ポイントは、AIにいきなりコードを書かせないことです。

まず録音を残す。次に要件を構造化する。既存コードを読ませる。過去のレビュー観点をプロンプトに入れる。PRDにする。実装する。

この順番を守ると、AIは単なるコード生成ツールではなく、業務システム開発の伴走者としてかなり使えます。特に既存システムの上に、詳細は出せないけれど条件分岐の多い機能を追加する場面では、録音、NotebookLM、Codexの組み合わせはかなり実用的でした。