AIに複数モジュールを統合させる前に、仕様の「橋」を設計する
複数のモジュールや製品を統合してアプリを作るとき、AIに「機能を統合して」と指示しただけでは、期待どおりのものにならないことがあります。
原因の一つは、モジュール間の責務やデータのつながりが整理されていないことです。
今回は、小規模事業向けアプリを個人開発した経験をもとに、AIで複数モジュールを統合するときに意識したい設計手順をまとめました。
統合したかったアプリ
作りたかった流れは、次のようなものでした。
Gmailで受信した注文メールから注文内容を抽出する
↓
注文に必要な材料の在庫状況を確認する
↓
労働時間の負荷が偏らないよう、部署へ作業を指示する
手元には、すでに単体アプリとして動く3つのモジュールがありました。
- モジュールA：Gmailの受信メールから受注内容を抽出し、正式な案件として登録する
- モジュールB：在庫を把握し、増減を管理する
- モジュールC：労働時間を把握し、過重負荷がないか確認する
一見すると、A → B → C の順につなげれば完成しそうです。しかし、実際にはそのまま接続できませんでした。
単純に接続すると何が起きるのか
たとえば、モジュールAは「案件」を管理しています。一方、モジュールBが管理しているのは「在庫」です。
AのデータをBへ渡すだけでは、次のような判断が必要になります。
- 案件の商品と在庫の商品は同じ概念なのか
- 案件数量と在庫の引当数量はどう対応するのか
- 在庫が不足している案件を、どの状態として扱うのか
- 在庫確認の結果から、作業量をどのように算出するのか
- 部署への作業指示は、A・B・Cのどこが責任を持つのか
これらは実装上の問題というより、統合後のアプリに必要な仕様そのものです。
ここを決めないままAIに「A、B、Cを統合してください」と依頼すると、AIは既存コードを読みながら、接続に必要な仕様まで推測することになります。
その結果、AIが暗黙に新しいルールを作り、各モジュールの前提と噛み合わない、ちぐはぐな製品になりやすくなります。
まずベースモジュールを決める
改善策として、最初に「どのモジュールを統合後のアプリの土台にするか」を決めます。
候補としては、次のようなモジュールです。
- 処理の起点になるモジュール
- 共通基盤になるモジュール
- 最も完成度が高いモジュール
- 今後のアプリケーションの中心になるモジュール
今回の例では、Gmailから注文を受け取る処理が起点です。また、受注管理は他のモジュールに依存せず、単体で独立しています。そのため、モジュールAをベースにするのが自然です。
ここで、考え方を次のように変えます。
A・B・Cを統合する
ではなく、
モジュールAをベースにして、
モジュールBの在庫管理機能と、
モジュールCの労働時間管理機能を追加する
と考えます。
このように土台を決めると、何を残し、何を追加し、どこを接続仕様として新設するかを判断しやすくなります。
モジュール間のギャップを仕様化する
次に、モジュール間で接続が必要な機能を切り分けます。
受注管理と在庫管理の間には、たとえば次のような橋渡しが必要です。
モジュールA：受注管理
│
│ 案件
↓
────────────────────
統合に必要な仕様
- 商品コード
- 商品名
- 受注数量
- 納期
────────────────────
↓
モジュールB：在庫管理
重要なのは、モジュールAの内部実装をそのままモジュールBへ渡すことではありません。両者の間で必要になるデータ、責務、状態を明示します。
たとえば、案件を次のように定義します。
案件
├─ 商品コード
├─ 商品名
├─ 受注数量
└─ 納期
そして、在庫引当という中間概念を定義します。
在庫引当
├─ 商品コード
├─ 必要数量
├─ 現在庫
└─ 不足数量
この「在庫引当」が、受注管理と在庫管理をつなぐ仕様です。
AIに渡せる指示へ変換する
接続仕様が決まると、AIへの指示も具体的になります。
モジュールAの案件情報から商品コードと受注数量を取得する。
モジュールBの在庫管理機能を使って在庫引当を作成する。
不足数量を計算し、不足がある場合は案件に「在庫不足」状態を記録する。
既存の受注登録処理と在庫更新処理の責務は変更しない。
この指示には、少なくとも次の情報が含まれています。
- 入力：案件の商品コードと受注数量
- 接続先：在庫管理機能
- 中間処理：在庫引当
- 出力：不足数量
- 状態変更：案件を「在庫不足」にする
- 制約：既存モジュールの責務を不用意に変えない
AIに設計判断を丸投げではなく、人が決めた統合仕様を実装させる形に変えることができます。
統合は「直接接続」ではなく段階的に進める
統合の流れは、次のようになります。
ポイントは、A・B・Cを直接つなげないことです。
各モジュール
↓
機能を切り分ける
↓
ギャップを整理する
↓
データ・責務・状態を仕様化する
↓
ベースモジュールへ必要な機能を追加する
↓
テスト・調整する
この段階を設けることで、AIが一度に理解・判断しなければならない不確定要素を減らせます。
まとめ
複数モジュールをAIで統合するとき、「すべてのコードを渡して統合してください」と依頼する方法には限界があります。
各モジュールが独立したアプリとして完成しているほど、それぞれに固有の設計思想、データ構造、状態管理の前提があります。
統合で重要なのは、モジュール本体を無理につなぐことではありません。モジュールの間にある、まだ存在しない概念やルールを仕様として定義することです。
- 統合後のベースモジュールを決める
- 必要な機能だけを切り出す
- モジュール間のデータ・責務・状態を定義する
- 接続仕様をAIへの具体的な実装指示に変換する
- 小さく追加して、テストと調整を繰り返す
AIは実装を大きく加速できます。しかし、統合の境界にある仕様まで推測させると、意図しない設計が入り込みやすくなります。
だからこそ、人が「モジュール間にどんな橋をかけるのか」を先に決めることが、AIを使った統合開発では特に重要だと感じています。