【ITニュース解説】I built a gateway that retries LLM refusals until I get a real answer

近年、ChatGPTをはじめとする大規模言語モデル（LLM）は私たちの生活や仕事に深く浸透し、その能力は多くの分野で注目されている。特にソフトウェア開発の現場では、コードの生成やアイデア出しなど、LLMを開発アシスタントとして活用する動きが広がっている。しかし、LLMのAPI（プログラム間の連携インターフェース）を実際に使ってみると、ユーザーが求めている直接的な答えやコードを返さず、「AIとして、それはできません」「倫理的な観点から」といった拒否回答に遭遇することが少なくない。例えば、特定の機能を持つコードを求めているにもかかわらず、セキュリティに関する一般的な講義が返ってきたり、質問の一部だけを意図的に無視したりする、といった状況だ。開発者は、このような拒否回答に直面すると、再度の質問やプロンプト（指示文）の調整に手間がかかり、作業効率が大きく低下してしまう。

このような問題を解決するために開発されたのが「armor-gw」というツールである。これは、ユーザーが開発しているアプリケーションと、OpenAIなどの大規模言語モデルAPIとの間に位置する「ゲートウェイ」として機能する。ゲートウェイとは、ネットワークの出入り口でデータの中継や変換を行うプログラムや機器のことで、armor-gwはアプリケーションからのリクエストをLLMに送り、LLMからのレスポンスを受け取る際に、その内容を詳細にチェックする役割を担う。もしLLMからのレスポンスがユーザーが求める「本物の答え」ではなく、拒否回答だった場合、armor-gwはそれを「拒否」と判断し、適切な回答が得られるまで自動的に再試行を繰り返す。

armor-gwが拒否回答を検出する方法は非常に高度だ。単に「できません」といったキーワードが含まれているかを調べるだけではない。LLMは表現を巧妙に変えるため、そのような単純な方法はすぐに通用しなくなるからだ。このゲートウェイは、13種類もの異なる検出器を使ってレスポンスを検査する。これには、求めていない代替案を提示する回答、長い説明文だけで肝心の情報が欠けている回答、質問の一部分だけを意図的に省略する回答、さらには特定のキャラクターを演じているかのように見せかけて拒否する回答など、様々な種類の巧妙な拒否パターンを識別する能力を持つ。

拒否が検出されると、armor-gwはただ単に同じリクエストを再送信するわけではない。元のリクエストを62種類もの異なる「修正オペレーター」のいずれかによって修正し、LLMに再度送信する。例えば、質問の言い回しを変えたり、特定の情報を含めたり、質問の焦点を調整したりすることで、LLMが回答しやすくなるように工夫する。さらに、この再試行は単一の修正で終わらず、複数の異なる戦略に基づいた修正版のリクエストを並行してLLMに送り、最も早く「クリーンな（拒否ではない）回答」を返してきたものを採用する。これにより、回答を得るまでの時間を最小限に抑えることができる。

このゲートウェイの賢い点は、どの修正戦略が特定のLLMや特定の質問に対して最も効果的かを学習する能力も持っていることだ。過去の成功と失敗の経験から、「このモデルには、このような言い換え方が有効だ」「あのモデルには、プロンプトに特定の情報を加えると良い」といった知識を蓄積し、次に拒否が発生した際に最適な戦略を選択できるようになる。また、拒否の原因がポリシーによるものか、安全上の理由か、モデルの能力不足か、あるいは単なる回答の回避なのかを診断し、その原因に応じた再試行戦略を立てることで、より効率的に「本物の答え」にたどり着くことを目指す。

システムエンジニアを目指す人にとって重要なのは、このarmor-gwが既存のアプリケーションに非常に簡単に組み込める点である。LLMのAPIを使うアプリケーションは、通常、OpenAIが提供するAPIの形式に合わせて作られている。armor-gwはOpenAIのAPIと完全に互換性があるため、アプリケーション側のコードをほとんど変更することなく、LLMへの接続先URLをarmor-gwのアドレスに変更するだけで利用を開始できる。これにより、開発者は複雑な設定なしに、LLMからの信頼性の高い回答をアプリケーションで活用できるようになる。さらに、複数のLLMモデルをバックエンドで利用したり、あるモデルが応答しない場合に別のモデルに切り替えたりする「フェイルオーバー」機能も備わっている。

このゲートウェイの開発には、いくつかの興味深い技術的な課題解決が含まれる。最も難しかったのは、やはり「拒否の検出」だったという。LLMが言葉を巧みに言い換えるため、キーワードリストだけでは不十分だ。そこで開発者は、「エンティティ生存率」というユニークな指標に着目した。これは、元のリクエストに含まれていた専門用語や固有のキーワードが、LLMからのレスポンスの中にどれだけ生き残っているか（登場しているか）を調べるものだ。もしリクエストで提示した重要な技術用語がレスポンスに全く現れない場合、いくらもっともらしい文章が返ってきても、それは質問に答えていない、つまり拒否であると判断できる。

また、単に拒否を突破するだけでなく、得られた回答の品質を高く保つことも重要だ。LLMの回答には、思考の過程を示す余分な情報、免責事項、無駄な問いかけ（「さらに詳しく説明しましょうか？」といったもの）が含まれることがある。armor-gwはこれらの「ノイズ」を自動的に除去し、ユーザーが本当に求めている核心情報だけをアプリケーションに届けることで、出力の「清潔さ」を保つ。

さらに、LLMモデルは日々更新されるため、昨日まで機能していた拒否突破戦略が明日には通用しなくなる可能性がある。この課題に対応するため、armor-gwには「回帰バンク」と呼ばれるテストケース群が用意されており、定期的に実行することで、特定のトピックに対する成功率が急激に低下していないかを監視する。もし成功率が著しく低下した場合は、その戦略が古くなったことを示し、新たなアプローチを検討する必要があることを教えてくれる。

armor-gwは、自己ホスト型（ユーザー自身でサーバーに設置して運用する方式）で、MITライセンスの下で公開されており、Python 3.9以降が動作する環境であれば、簡単なコマンド一つでデプロイ（配置・実行）できる。このツールは、LLMをより信頼性の高い開発パートナーとして活用するための強力な味方となるだろう。システムエンジニアを目指す人々にとって、このような課題解決の視点や、実際に問題に対処するツールの設計は、非常に参考になる実践的な学びとなるはずだ。