AIを組み込むアプリの基本構成

「うちのサービスにもAIを入れたい」という相談で、最初に決めるべきなのはどのモデルを使うかではありません。AIを呼ぶ処理をシステムのどこに置き、既存の機能とどう切り離すか、という構成の話です。ここを曖昧にしたまま作り始めると、あとから利用料の管理も、障害時の切り分けも、モデルの入れ替えもできなくなります。

本記事では、OpenAI や Anthropic、Google などが提供する既存のAI APIをWebアプリに組み込む前提で、最初に決めておくべき構成の考え方を整理します。モデルそのものを学習させる話ではなく、既製のAPIを業務やプロダクトにどう当てはめるかの話です。

AIを呼ぶ場所はサーバー側の一箇所に集める

最も基本的で、最も間違えやすいのがここです。原則は二つあります。

一つ目は、外部AI APIの呼び出しをブラウザから直接行わないことです。画面のJavaScriptから直接APIを呼ぶと、認証の鍵がブラウザに置かれます。鍵は簡単に読み取られ、第三者が自社の契約で使い放題になります。AI APIは使った分だけ課金されるAPIなので、これは請求書に直結します。画面は自社サーバーの窓口を呼び、そのサーバーが外部APIを呼ぶ形にしてください。

二つ目は、AIを呼ぶ処理をアプリの中の一箇所にまとめることです。「この画面から直接呼ぶ」「あの処理からも呼ぶ」と散らばると、モデルを変えるとき、記録を取るとき、上限を設けるときに全箇所を触ることになります。AI呼び出しを担当する部品を一つ用意し、他の処理はその部品を通してだけAIを使う。この形にしておくと、あとから差し替えや制御を一箇所で行えます。

この部品が受け持つのは、入力の整形、モデルとパラメータの指定、外部APIへの送信、失敗時の扱い、入出力の記録です。逆に、どんな文章をどう作るかという業務ロジックは、この部品の外側に置きます。

AI部分は「なくても本体が動く」ように切り離す

外部のAIサービスは、自社の管理外にあります。速度が落ちることも、一時的に応答しないことも、仕様が変わることもあります。したがって設計上の前提は、AIは止まりうる部品です。

そこで問うべきは、「AIが使えないとき、このサービスは何ができるか」です。

• 要約や提案のようにAIが補助をしている機能なら、AI部分だけを非表示にし、本体はそのまま使えるようにします。
• AIの出力が処理の途中に必要な場合は、人が手で入力する経路や、あとで処理し直す経路を用意します。
• AIの出力そのものが商品である場合は、止まったことを利用者に伝える画面と、復旧後に再実行する手段が必要です。

あわせて、AI機能を管理画面から止められるスイッチを用意しておくと現実的です。費用が想定を超えたとき、外部サービスの障害が長引いたとき、出力に問題が見つかったとき、リリースを待たずに止められます。非機能要件として、こうした停止と縮退の条件を最初に決めておきます。

同期か非同期かは、応答時間で決まる

AIを組み込む構成でもう一つ大きいのが、利用者を待たせる作りにするかどうかです。判断の軸は、AIの応答にどれくらいかかるかです。

ここで大切なのは、推測ではなく実測で決めることです。短い入力での試用時は速くても、実際の業務データを入れると入力が長くなり、応答も遅くなります。試作の段階で本番に近い長さの入力を通し、時間を測ってから構成を決めてください。

なお、同期から非同期への作り替えは、画面・サーバー・データ構造の三つに同時に手が入るため、あとからでは高くつきます。迷う場合、あるいは入力の長さが利用者によって大きくばらつく場合は、最初から非同期を前提にしたほうが安全です。具体的な作り方はAI処理を待たせない作り方で扱います。

入出力の記録は最初から入れる

AI機能は、動作を目で見ても正しさを判断できない部分があります。おかしな出力が報告されたとき、何を送って何が返ってきたのかが残っていなければ、原因を調べることも、改善したかを確かめることもできません。

記録しておきたいのは、送信した内容、返ってきた内容、使ったモデルと設定、所要時間、消費したトークン量（料金の単位となる文字のまとまり）、そして失敗した場合はその理由です。これらは後述の費用管理と品質改善の両方で使います。

ただし、記録には個人情報が含まれ得ます。保存期間を決める、閲覧できる人を限る、不要な項目は保存前に落とす、といった扱いを設計に含めてください。スタートアップのセキュリティと個人情報保護の考え方がそのまま当てはまります。

モデルと設定は「外に出しておく」

AIモデルは短い周期で新しいものが出ます。安くなることも、速くなることも、出力の傾向が変わることもあります。したがって、モデル名や設定値をコードの中に埋め込むのではなく、設定として外に出し、切り替えられるようにしておきます。

そのうえで、用途ごとに使うモデルを分けられる形にしておくと、費用と品質の調整幅が広がります。分類のような単純な処理には軽いモデル、文章を書かせる処理には性能の高いモデル、といった使い分けです。この考え方はAI利用料が膨らまない設計で詳しく扱います。

一方で、最初から複数モデルの切り替え機構を作り込む必要はありません。MVPの段階では「設定で変えられる」ところまでで十分です。実際の利用が始まり、費用と品質のデータが取れてから、使い分けを設計するほうが判断を間違えません。

作り込む前に決めておきたいこと

弊社は既存のAI APIをWebアプリに組み込む立場で開発しています。その経験から言えるのは、構成の失敗の多くは技術的な難しさではなく、決めるべきことを決めないまま作り始めたことに起因するという点です。

作り始める前に、次の四つに答えられる状態にしておくことをおすすめします。

1. AIが止まったとき、このサービスは何ができて何ができないか
2. 一回の処理に何秒かかる見込みで、利用者を待たせてよいか
3. AIに何を送ってよく、何を送ってはいけないか
4. 費用の上限をどこに置き、超えたら何を止めるか

この四つが決まっていれば、構成はおのずと定まります。逆に、これらが決まらないまま「とりあえずAIを呼んでみる」と、動くものはできても運用に乗りません。

AI活用開発やWebシステム開発で、既存サービスへのAI機能の組み込みを検討されている場合は、お問い合わせからご相談ください。オンラインで状況を伺い、そもそもAIで解くべき課題かどうかから一緒に整理します。

本記事は一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。