生成AI「Claude」は上流工程でこそ効く

古くなった業務システムを作り直すとき、いちばん時間がかかるのは、新しいコードを書くことではありません。今のシステムがどう動いているかを調べること、何を作るかを決めて書類にすること、そして何十冊にもなる書類どうしの食い違いをなくすことです。

スタイルズが参画している大規模な業務システムの再構築プロジェクトでは、Anthropic社の生成AI「Claude」（開発支援ツール「Claude Code」）を、現行システムの調査から要件定義・設計・画面モック・テスト計画まで、上流工程の全体で使っています。本記事では、案件を特定できる情報は伏せたうえで、その使い方と、AIに任せきりにしないための決めごとをご紹介します。

図1　上流工程でのClaudeの使いどころと、エンジニアの役割

舞台は「設計書が実装に追いついていない」大規模システム

対象は、長年にわたって改修を重ねてきたJavaの業務システムです。画面は100を超え、扱うデータの種類も多岐にわたります。設計書は残っていますが、改修のたびに実装との間にずれが生まれ、現行の仕様を正確に知る人は限られていました。

再構築では、今ある機能を漏れなく引き継ぎつつ、他のシステムとの連携のような新しい要件も加えなければなりません。「何が今のシステムの本当の仕様か」を確かめることが、プロジェクト全体の出発点でした。

工程ごとのClaudeの使いどころ

現行を調べる：ソースコードから設計書を起こし直す

Claudeが現行システムのソースコードを読み、画面ごとの処理の流れ、入力チェック、データの読み書きを整理します。そこから、画面ごとの設計書と、「どの画面がどのデータを読み書きするか」を一覧にした表（CRUD表）を作りました。

エンジニアは、読み取った結果を実際の画面やデータと照らし合わせて確かめます。判断の基準は、書類に書いてあることより、実際に動いているものです。食い違いが見つかれば、根拠となるソースコードの箇所とともに記録します。

決めたことを書く：1つの正本から、提出用の書類まで

要件定義書や設計書は、テキスト形式（Markdown）の原稿を正本として、変更の履歴をすべて管理しています。お客様へ提出するWordやPDFは、この正本から自動で作ります。改訂履歴や目次も含めて作り直すため、「原稿は直したのに提出版が古いまま」という事故が起きません。お客様指定の様式（WordやExcel）での提出にも対応しています。

何をいつ、なぜ決めたのかは「決定ログ」に、まだ決まっていないことは課題の一覧に残します。Claudeはこれらを読んでから作業するため、過去の判断と矛盾する変更を持ち込みにくくなります。

画面で確かめる：全画面の「動くモック」

100を超える画面のすべてを、実際に操作できるモック（試作品）として作り、1つのHTMLファイルにまとめてお届けしています。お客様は手元のブラウザで画面を触りながら確認でき、紙の画面仕様だけでは気づきにくい点がレビューの段階で見つかります。指摘はモックと設計書に同時に反映します。

食い違いを機械で見つける：一貫性の検査

書類が増えるほど、人の目だけで食い違いを防ぐことは難しくなります。番号の二重採番、リンク切れ、表の崩れ、画面の作法の違反などは、検査用のスクリプトで毎回確かめています。

他のシステムと連携する部分では、相手側のインタフェース仕様書と、こちらの設計を突き合わせます。文字の扱いや項目の並び順の違いのように、後になるほど直しにくい食い違いを、早い段階で見つけられるようになりました。

テストで確かめる：数千件の自動テスト

データを作る側と受け取る側の両方に同じ規則を実装する箇所では、「作ったデータを受け取る側で読み直して一致するか」を確かめるテストを、数千件の規模で自動で実行しています。

事例：仕様変更1件が、その日のうちにすべての書類に届くまで

ある日の打ち合わせで、画面に入力項目を1つ足し、その値を使ってお知らせを送る、という仕様変更が決まりました。小さな変更に見えますが、画面、データの受け渡しの形式、設計書、要件定義書、テストのすべてに影響します。

この変更では、次の作業をその日のうちに終えました。

• 影響する画面・書類・仕組みの洗い出し
• 入力する側と受け取る側の画面モックの修正と、入力チェックの追加
• 数千件の自動テストと、ブラウザでの操作確認
• 設計書・要件定義書の更新と、Word・PDFの作り直し
• 改訂履歴と決定ログへの記録

エンジニアが担ったのは、何をどう決めるかの判断、差分・画面・PDFの確認、そして成果物を確定させる承認です。

この作業の途中で、Claudeは以前お客様にお伝えした説明の中に不正確な一文があったことを自ら見つけ、報告してきました。結論が変わるものではありませんでしたが、言いにくいことほど先に出てくる仕組みが、品質を保つうえで大きな意味を持っています。

AIに任せきりにしないための決めごと

AIの作業が速くなるほど、人が責任を持つための仕組みが大切になります。このプロジェクトでは、次のことを決めて運用しています。

• AIの生成物は必ずエンジニアが確認し、最終的な判断は人が行う
• 本番環境のデータにはAIを触れさせない。調査用のSQLはAIが書き、実行と結果の確認は担当者が行う
• 社外への送信や投稿、成果物の確定（版管理への登録）は、人が内容を確かめてから行う
• 共有ファイルサーバーなど、AIが触れてはいけない場所をあらかじめ決めておく
• AIには「安易に同調しない」「根拠を示す」「自分の誤りは指摘される前に報告する」というルールを与え、反論や懸念も出させる
• 入力・出力が学習に使われない法人向けプランで利用する

まとめ

生成AIの効果は、コードを書く速さだけではありません。現行を調べ、決めたことを書き、書類どうしを揃え、確かめるという上流工程の積み重ねでこそ、大きな差が生まれます。その前提にあるのは、エンジニアがAIに作業の「型」を教え、判断と承認を人が担う役割分担です。

「設計書が残っていない」「現行の仕様を知る人がいない」といった古いシステムの作り直しや移行は、スタイルズにご相談ください。