【ITニュース解説】5 Challenges with "Wrapper"AI App and Solutions.

AI（人工知能）技術を活用したアプリケーション開発は、一見すると既存のサービスにAIの機能を組み合わせるだけのように見えるかもしれない。しかし、実際に開発を進めていくと、予想外の複雑な課題に直面し、それらを乗り越えるための工夫が必要となる。ここでは、GitHubリポジトリを分析して職務経歴書を自動生成する「AIレジュメツール」の開発経験から得られた五つの主要な課題と、その解決策について解説する。このツールはGo言語でバックエンドサービスを構築し、Next.jsでユーザーインターフェースを提供している。当初は単にいくつかのAIのAPI（Application Programming Interface、異なるソフトウェア同士が通信するための窓口のようなもの）を統合するだけの簡単な「ラッパーAIアプリ」（既存のサービスをAIで包むようなアプリ）だと考えられていたが、開発を進めるにつれて、アプリケーションを持続的に稼働させ、コストを適切に管理することの難しさが明らかになった。

最初の課題は、特に大規模なGitHubリポジトリを分析する際に発生する、長時間の処理とそれに伴うタイムアウトの問題である。大きなリポジトリの分析には20分以上かかることがあり、これによりシステム全体の処理が中断され、最終的にタイムアウトエラーが発生してしまう。ユーザーはせっかく準備を進めていた職務経歴書が、完成直前で失われるという不便さに直面する。この問題に対処するため、大きなデータを小さな塊に分割し、それぞれを並行して処理する「Map-Reduce」という技術が導入された。これにより、巨大なリポジトリでも効率的に処理できるようになった。さらに、リポジトリのサイズに応じて、システムが処理にかかる時間を予測し、タイムアウトの時間を自動的に調整する仕組みが取り入れられた。また、一時的なネットワークの問題などで処理が失敗した場合に、すぐに諦めるのではなく、時間を置いて再試行する「指数バックオフ再試行」という手法が実装された。これは、再試行のたびに待機時間を長くしていくことで、システムへの負荷を抑えつつ、成功するまで粘り強く試行する。ユーザーの進捗が失われるのを防ぐためには、サーバーとユーザーのブラウザ間で自動的に接続を維持・再接続する「EventSource」という技術を活用し、中断なくデータを受け取れるように工夫が凝らされている。

二つ目の課題は、異なるAIプロバイダが提供するAIモデルを組み合わせて利用する際に生じる、応答フォーマットの違いである。例えば、ClaudeというAIは「content_block_delta」という形式で、OpenAIは「choices[].delta.content」という形式で、GeminiというAIもまた独自の形式でストリーミングデータ（少しずつデータを送り続ける方式）を返してくる。これらの異なる形式を適切に処理できないと、データの解析が失敗し、アプリケーションが正常に動作しなくなる。この問題の解決策として、複数のAIプロバイダからのストリーミング応答を統一的に処理できる「普遍的なストリーミングパーサー」が開発された。このパーサーは、送られてくるデータの内容からどのAIプロバイダからのものかを自動的に識別し、それぞれのプロバイダに合った解析方法を適用することで、形式の違いによる問題を解消した。

三つ目の課題は、AIモデルが情報を処理する際の「トークン」（AIが情報を処理する際の最小単位のようなもの）の消費量と、それに伴うコストの管理である。特に大規模なリポジトリを分析する場合、AIのトークン消費量が膨大になり、予測不能な高額なコストが発生する恐れがあった。場合によっては、一つの大きなリポジトリの分析だけでAPI利用料が50ドル以上にもなり、これではサービスを持続的に提供することが経済的に困難になる。この課題に対しては、賢いトークン使用量の見積もりと予算管理の仕組みが開発された。システムは処理を開始する前に、どれくらいのトークンが必要になるかを事前に計算し、予算の範囲内で収まるように処理を小さな塊に分割する「動的チャンク分割」という戦略を採用している。これにより、コストを常に監視し、予測可能な範囲に抑えながらサービスを提供することが可能になった。

四つ目の課題は、AIがリアルタイムで情報を生成し続ける「ストリーミング」の途中で、エラーが発生して処理が中断してしまうことである。ネットワークの不安定さ、AIモデルの一時的な応答停止、あるいは不適切なデータ形式など、様々な原因で生成処理が途中で停止し、ユーザーは不完全な職務経歴書を受け取ることになる。これではユーザーの時間が無駄になるだけでなく、途中までかかったAIのAPIコストも無駄になってしまう。この問題に対処するため、途中で失敗しても回復できるような「レジリエントなストリーミングアーキテクチャ」（障害に強く、回復力のある構造）が構築された。具体的には、生成プロセス中の重要な段階で「チェックポイント」（途中経過）を保存する仕組みが導入された。これにより、もし途中で処理が中断しても、最後に行ったチェックポイントから再開することが可能になる。また、全体を最初からやり直すのではなく、失敗した最終段階だけを賢く再試行するロジックも実装され、効率的なエラー回復が実現された。

最後の課題は、AIサービス自体が持つ本質的な不安定さである。AIモデルが一時的に利用できなくなったり、APIへのアクセス制限（レート制限）に達したり、APIキーが何らかの理由で使えなくなったりすることは珍しくない。単一のAIプロバイダだけに頼ってしまうと、そのプロバイダに障害が発生した場合、アプリケーション全体が完全に機能停止してしまう。この問題を解決するために、非常に洗練された「フォールバックシステム」（ある機能が使えないときに、別の代替機能に切り替える仕組み）が実装された。これは、あるAIプロバイダが利用できない場合に、自動的に別のAIプロバイダに切り替えて処理を継続する仕組みである。さらに、異なるAIモデル間で出力の品質がばらつかないように、それぞれのモデルの得意不得意に合わせて、AIへの指示（プロンプト）や、出力されたデータを調整する後処理ロジックが組み込まれている。これにより、どのAIモデルを使用しても一定の品質を保つことが可能になる。加えて、サーバーで何か問題が発生した際に、ユーザーが気づく前に開発者が対応できるよう、開発者自身に警告メールを送信する仕組みも導入され、システムの信頼性が高められている。

これらの開発経験から、AIアプリケーションを構築する上でいくつかの重要な教訓が得られた。まず、「コスト管理が極めて重要」である。AIアプリケーションはトークンの消費によってコストが急増する可能性があり、開発の初期段階からコスト最適化を最優先で考える必要がある。賢い予算管理と、適切なAIモデルの選択戦略が成功には不可欠となる。次に、「AIの信頼性には冗長性が不可欠」である。従来のウェブサービスとは異なり、AIプロバイダは本質的に不安定であることを前提とし、モデルの障害やAPIの停止、出力のばらつきに備えて、フォールバックシステムを必ず導入しなければならない。これはオプションではなく、本番環境でAIアプリケーションを運用するための必須要件だ。さらに、「プロンプトエンジニアリングはソフトウェアエンジニアリングである」という点も重要だ。AIへの指示文（プロンプト）の管理は、コードの管理と同じ規律で行うべきである。バージョン管理、テスト、そしてプロンプトの体系的な最適化は、アプリケーションが大規模になるにつれて、一貫した品質を維持するために不可欠な要素となる。また、「AIのためのストリーミングアーキテクチャ」も重要である。ユーザーはリアルタイムのフィードバックを期待するが、AIの処理には時間がかかるため、中断を適切に処理し、途中から再開できるような堅牢なストリーミングシステムを構築することが、優れたユーザー体験を提供するために不可欠である。最後に、「大規模な品質管理」も忘れてはならない。AIの出力は本質的に予測不可能であるため、手動での介入なしに一貫した結果を保証するためには、自動化された品質スコアリング、検証システム、そして再試行メカニズムが必要となる。これらの洞察は、システムエンジニアを目指す上で、AI技術を扱う際に非常に役立つ知識となるだろう。