はじめに

過去に担当していたデータ連携処理を、あらためて見直すことになりました。

きっかけは、連携先の仕様変更に備えて、既存の処理が問題なく動くかを確認したくなったことです。

コードもドキュメントも検証に必要な情報も残っていましたが、「どの条件で正常になるのか」「何を確認すればよいのか」はすぐには出てきませんでした。

そこで今回は、AI にコードとドキュメントを読んでもらいながら、仕様の整理、テストデータ作成、評価の進め方の整理を一緒に進めました。

今回やりたかったことは、次の 3 つです。

連携先の仕様が変わっても、既存の仕組みで正しく取り込めるか見立てること
その確認に使えるテストデータを、仕様に沿って作ること
加工後のデータがどこへ渡り、次に誰が処理するのかを把握すること

この記事で書きたいのは、結果そのものよりも次の点です。

AI に仕様理解を進めてもらうには、どんなインプットが効くのか

先に結論

最初に次の 4 つを渡すと、かなり進みやすかったです。

何を評価したいか
最初に見るファイル
実行してよい範囲
何をもって OK とするか

完璧な仕様書を最初から渡すというより、AI が探索を始めるための足場を渡すイメージです。

どんなことがやれるシステムか

今回対象にしたのは、入力データを受け取り、加工し、連携先へ引き渡す仕組みです。

登場するシステムをざっくりまとめると、次のようになります。

入力データを受け取る保管領域
データを整形、振り分けする処理基盤
加工後データを受け取る連携先
次の処理へつなぐ通知や連携トリガー
コードとドキュメントを読みながら、仕様整理やテスト観点の洗い出しを進める AI

全体としては、ファイルを置くと加工処理が走り、その結果が次のシステムへ引き渡される構成です。今回はこの流れを前提に、仕様理解とテストデータ作成をどこから進めるとやりやすいかを確認しました。

今回やってもらったこと

今回 AI にやってもらったのは、ざっくり次の内容です。

処理の入口と変換条件を読む
条件に合うテストデータを作る
検証環境で処理を実行する
設定済みの通知や連携トリガーを確認する
その先の連携経路を整理する

実際には、データ加工処理の入口を起点にして変換条件を追い、最終的に連携先へ引き渡される流れだと確認できました。

途中で効いた具体例もありました。変換ロジックを追うと、特定条件を満たすデータは処理対象として残ることが分かりました。これが分かったことで、今回の目的に対して妥当なテストデータの条件を判断しやすくなりました。

どういうインプットが効いたか

1. 「仕様を教えて」ではなく「何を評価したいか」を渡す

最初に効いたのは、依頼を「このコードの仕様を教えて」ではなく、「連携先の仕様が変わっても正しく処理できるか評価したい」と置いたことでした。

これだけで、AI の探索がかなり絞れます。

どの入力が処理対象か
どの行が正常データとして残るか
成功時にどこへ出るか
失敗時にどこへ落ちるか
連携先へは誰が引き継ぐか

2. 最初に見るファイルを 1 つ渡す

コードベース全体を自由に読ませるより、入口を 1 つ渡した方が早いです。

今回は次の 3 つが効きました。

処理の入口ファイル
変換ロジックの本体
既存の単体テスト

特にテストファイルがあると、AI が想像で仕様を補完しにくくなるので助かります。

3. 実行してよい範囲を先に決める

これもかなり大事でした。

途中で「ローカルにこだわらず、利用可能な検証環境を使ってよい」と切り替えたことで、AI が実運用に近い検証へ進めるようになりました。

この一言があるだけで、AI は次のように動きやすくなります。

ローカル検証より検証環境の確認を優先する
実行対象や保存先を確認する
出力ファイルの中身まで見にいく

4. OK 条件は途中で更新してよい

AI を相手にするときは、最初の指示を最後まで固定しなくて大丈夫でした。

今回だと、AI が変換条件を見つけたあとに、「その条件ならこのテストデータで OK」と返せたことで、次へ進みやすくなりました。

つまり、AI に必要なのは最初から完全な正解ではなく、途中で受け入れ条件を更新できる会話です。

実際に投げるならこんな感じ

今回の経験を踏まえると、次のような形で渡すとかなり進めやすいです。

しばらく触っていなかったデータ連携処理の仕様を忘れています。

やりたいこと:
連携先の仕様が変わっても、正しく処理できるか評価したいです。

最初に見てほしいもの:
- 処理の入口ファイル
- 変換ロジック
- 既存テスト
- 関連ドキュメント

やってほしいこと:
1. 正常データになる条件を整理する
2. その条件に合うテストデータを作る
3. 必要なら検証環境で処理を実行する
4. 設定している通知や連携トリガーを確認する
5. 後続の連携経路も分かれば整理する

制約:
- ローカルにこだわらなくてよい
- 利用可能な検証環境を使ってよい
- 分からない仕様は仮説を出しながら進めてよい

完了条件:
- なぜそのテストデータでよいか説明できること
- 出力先が正しいことを確認できること
- その先に誰が処理するか説明できること

ポイントは、全部を細かく書くことではなく、AI が次の一手を決められる材料を渡すことです。

逆に、進みにくかった投げ方

逆に、次のような投げ方だと進みにくいです。

「これ調べておいて」だけで目的がない
入口ファイルがない
実環境を触ってよいか分からない
何が分かれば完了なのかがない

AI は便利ですが、探索の優先順位を決める材料がないと、どうしても広く浅くなりやすいです。

まとめ

今回やってみて感じたのは、AI に必要なのは完璧な仕様書よりも、次の 4 点だということでした。

評価目的
入口ファイル
実行範囲
OK 条件

過去に担当した処理を見直すときほど、この 4 点があるだけでかなり進めやすくなります。

「以前触っていた処理だけど、今は仕様を思い出せない」という場面は普通にあるので、同じような状況の人にはかなり相性のいい進め方だと思います。

注意事項
本ブログに掲載している内容は、私個人の見解であり、所属する組織の立場や戦略、意見を代表するものではありません。あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。