既存システムにAIを導入：作り直さない5ステップ

すでに稼働しているアプリをお持ちだとします。POSシステム、受発注アプリ、社内ダッシュボード、あるいは数年前に構築した顧客ポータルかもしれません。そこで出てくるのが「ゼロから作り直さずに、AIを追加できないか？」という疑問です。結論から言うと、ほぼ必ずできます。本記事では、Rancangin Aja（RAT）での進め方をもとに、既存アプリにAIを導入するためのロードマップを5つのステップで解説します。

ここでいう「移行」という言葉は、少し誤解を招きます。アプリを新しい場所へ移すのではなく、既存の仕組みの上にAIレイヤーを追加するのです。この違いは重要です。多くの経営者は全面的な作り直しが必要だと考え、費用を想像して、構想そのものをあきらめてしまうからです。

なぜ作り直さないのか

すでに動いているアプリを作り直すことは、ソフトウェアにおいて最も高コストでリスクの高い判断の一つです。理由は次のとおりです。

• 既存アプリには文書化されていない業務ルールが数多く埋め込まれています。作り直すということは、それらをすべて再発見することであり、たいていはバグを通じて発見することになります。
• 作り直しが何か月も続く間も、ビジネスは既存アプリに新機能を求め続けます。つまり、二重にコストを払うことになります。
• ユーザーは既存システムに慣れています。全面刷新は、教育の負担を増やします。
• AIの価値は通常、すべてが新しくなったアプリからではなく、1つか2つの特定の機能から生まれます。

そこで私たちのアプローチは、既存アプリを「信頼できる唯一のデータ源」として残し、その横にAIをサービスとして追加する、というものです。

ステップ1：データと業務フローを棚卸しする

AIの話をする前に、2つのことを把握する必要があります。どんなデータがあるか、そして業務フローのどこにAIが入り込めるかです。

データの棚卸し

私たちが確認する質問は次のとおりです。

• アプリにはどんなデータが保存されているか。注文、顧客、商品、チャット、文書など。
• どうやってアクセスできるか。APIはあるか。データベースへの直接アクセスか。それとも手動エクスポートのみか。
• どの程度整っているか。空欄の列、不統一なフォーマット、重複データはないか。
• コードとアカウントの所有者は誰か。別のベンダーがアプリを作った場合、ここがよく障害になります。

業務フローの棚卸し

アプリを毎日使っているチームと一緒に座り、人がテキストや文書を扱う繰り返し作業をしている箇所を探します。読む、打ち直す、分類する、要約する、返信する。AIの候補はたいていそこにあります。

このステップの成果物： アクセス可能なデータソースの一覧、有望な業務フロー上のポイントの一覧、そして技術的な障害（例：APIがない）の一覧です。

正直に言うと： 棚卸しの結果、本当の問題はAIがないことではなく、データが整理されていないことや、プロセスが曖昧なことだとわかるケースは少なくありません。その場合は、まず土台を整えることをおすすめします。この点はまだAIが必要ないビジネスとはで詳しく書いています。散らかったデータの上にAIを載せても、散らかった答えが速く出てくるだけです。

ステップ2：価値の高いユースケースを1つ選ぶ

ステップ1で挙がった候補から、1つだけ選びます。3つでも5つでもありません。選定基準は次のとおりです。

最初のユースケースとして適しているのは、価値とデータの準備状況が高く、リスクが低いものです。たとえば、B2Bの受発注アプリで、チームが毎日何十通もの注文メールを読み、システムに打ち直しているケース。AIがメールを読み取り、品目と数量を抽出し、人が確認するための注文ドラフトを作成できます。データはあり（メールと注文フォーマット）、リスクは低く（保存前に確認がある）、成果も測定できます（入力時間の削減）。

ほかのユースケースのアイデアは、中小企業向けAI活用事例10選をご覧ください。

ステップ3：作り直しではなく、APIでAIレイヤーを追加する

ここが技術面の核心です。私たちがよく使うアーキテクチャのパターンは3つあります。詳細を理解する必要はありませんが、ベンダーから説明を受ける際に選択肢を知っておくと役立ちます。

パターンA：既存アプリの横にAIサービスを置く

独立した小さなサービス（通常はNode.js/NestJSまたはPython）を構築します。その役割はただ1つ、既存アプリからデータを受け取り、AIで処理し、結果を返すことです。既存アプリ側には、このサービスへの「呼び出し」を1つ追加するだけで済みます。

• 向いているケース： APIがある、または少しのコード追加が可能な既存アプリ。
• メリット： 既存アプリにはほとんど手を入れません。AIサービスに問題が起きても、既存アプリは動き続けます。
• 例： 顧客詳細ページの「要約」ボタンから、AIサービスを呼び出してチャット履歴を要約する。

パターンB：既存データベースの上にRAGを構築する

ユースケースが「自社のデータや文書を理解するAI」であれば、RAG（Retrieval-Augmented Generation、検索拡張生成）のレイヤーを構築します。データベースや文書のデータをインデックス化し、AIは関連する部分をもとに回答します。元のデータベースは変更せず、読み取るだけです。

• 向いているケース： 商品カタログ、業務マニュアル（SOP）、問い合わせチケットの履歴、社内ナレッジベース。
• メリット： AIは作り話ではなく、御社のデータに基づいて回答します。回答の出典も表示できます。
• 仕組みはRAGをわかりやすく解説：ビジネス文書を理解するAIで説明しています。

パターンC：イベント駆動の自動化

既存アプリで何かが起きるたびに（新規注文、チケットの受付、文書のアップロードなど）、AIサービスに「シグナル」が送られ、AIが処理を行います。分類する、ラベルを付ける、通知を送る、項目を埋める、といった処理です。

• 向いているケース： ユーザーの操作なしにバックグラウンドで動くプロセス。
• メリット： アプリの画面はまったく変わりません。ユーザーには結果が「すでに入力済み」の状態で見えるだけです。
• 例： 届いたクレームのチケットすべてに、カテゴリと優先度を自動で付与する。

これら3つのパターンは組み合わせることもできます。重要なのは、既存アプリが中心であり続け、AIは取り外し可能な追加機能であるということです。

AIモデルの選び方について

私たちは、モデルの提供元（OpenAI、Claude、あるいはOllama経由のローカルモデル）をシステムを大きく改修せずに切り替えられるよう、AIレイヤーを設計します。これには2つの理由があります。コスト（単純な作業には安価なモデル、難しい作業には高性能なモデル）と、プライバシー（機密データはローカルモデルで処理できる）です。

ステップ4：実データで検証し、数字で測る

5つの例を使ったデモでは見栄えのよいAIのプロトタイプも、500通りのバリエーションがある実データでは失敗することがあります。そのため、本番投入の前に評価を行います。

1. 御社の実際の事例を集めます。先ほどの注文メールの例なら、実際のメール50〜100通と、その正解（御社のチームが手作業で作成）を用意します。
2. そのすべてに対してAIを実行します。
3. 何パーセントが正解か、どの種類の誤りが最も多いかを集計します。
4. 指示（プロンプト）、データの処理方法、または使用モデルを改善します。これを繰り返します。

結果は、たとえば「AIは92%のケースで正解し、誤りの大半は表記が統一されていない商品単位に関するもの」といった正直な数字になります。そこから判断できます。人による確認を前提に使うには十分か、それとも先に改善が必要か。

この段階で、利用コストも見えてきます。1回のリクエストあたりのトークン数、1日あたりのリクエスト数、月あたり何ルピアかかるか。高すぎる場合は、一部の作業に小さなモデルを使うことで、たいていは抑えられます。

ステップ5：人が関与しながら段階的に展開する

いきなり全ユーザーに公開してはいけません。私たちが使っているパターンは次のとおりです。

1. 提案モード： AIが入力や提案を行い、人が判断します。AIの出力はすべて「AIによる提案」と明示します。2〜4週間運用します。
2. 半自動モード： （評価に基づいて）AIの確信度が高いケースは、結果をそのまま採用します。確信度の低いケースは引き続き人が担当します。
3. 抜き取り確認付きの自動モード： 大部分を自動化し、人はランダムに抽出したサンプルを確認し、エスカレーションに対応します。

どの段階でも、AIが何を提案し、人が何を判断したかをすべて記録します。その差分が、次の改善のための材料になります。これがヒューマン・イン・ザ・ループと呼ばれるもので、多くの企業では、モード3まで進まなくてもモード1か2で効果の大部分を得られます。

考慮すべきリスクとコスト

コストについて言えば、既存アプリに1つのAIユースケースを追加する方が、新しいアプリを作るよりはるかに手頃なのが一般的です。費用の目安はアプリ開発とAI連携の費用内訳にまとめています。なお、APIの利用料と品質モニタリングには継続的な月額費用がかかる点にご注意ください。

作り直しが本当に必要なのはどんなときか

公平を期すために言えば、継ぎはぎでの対応が意味をなさない状況もあります。

• 既存アプリにまったくアクセスできない：コードもAPIもなく、データベースは連絡の取れなくなったベンダーの手元にある。
• 技術がすでにサポート終了しており安全でない（例：何年もセキュリティアップデートが提供されていないフレームワーク）。
• 既存アプリが現在の業務プロセスにもはや合っておらず、AIは変えたいことの一つにすぎない。
• 連携にかかるコストが、小さな新バージョンを作るより高い。

こうした場合でも、私たちは段階的な作り直しをおすすめします。（AIを組み込んだ）新しいモジュールを既存のものと並行して構築し、ユーザーを少しずつ移行させます。進め方は経営者のためのSDLC解説で説明しているプロセスに沿います。

ロードマップのまとめ

1. データと業務フローを棚卸しする。何にアクセスできるか、人がどこで繰り返し作業をしているかを見つける。
2. ユースケースを1つ選ぶ：価値が高く、データが揃っていて、リスクが低く、測定できるもの。
3. 既存アプリの横にAIレイヤーを追加する：独立したサービス、RAG、またはイベント駆動の自動化。
4. 実データで検証し、感覚ではなく数字で精度を測る。
5. 人による確認を挟みながら段階的に展開し、効果が実証されてから拡大する。

次のステップ

既存アプリへのAI導入は、すべてを壊して作り直すことを意味しません。適切なユースケースを1つ選び、独立して動くように設計したAIレイヤーを用意すれば、数年ではなく数週間で効果を実感できます。すでに稼働しているアプリがあり、どのユースケースが最も理にかなっているかを知りたい方は、無料相談をご予約ください。WhatsAppでのご連絡（インドネシアで最も普及しているチャットアプリです）や、メール（hello@rancanginaja.com）でも承ります。初期の調査をお手伝いし、私たちのAIエンジニアリングサービスが、今動いている仕組みを妨げることなくどう組み込めるかをご提案します。