要約

  • pai-auth-ws-client 1.6.0は、AI用途の設定を解決する呼び出しとチャット呼び出しを追加し、どちらの結果型もプロバイダーとモデルを示す。
  • 公開Java契約には共通の解決IDや設定バージョンがなく、事前に見た状態が後の回答に使われたことを、このクライアントだけでは立証できない。

まず、この実装は「モデルに文字列を投げるだけ」の薄暗い窓ではない。1.6.0のREADMEによれば、アクセスにはportal-ai-gatewayロールを持つPAI Bearerトークンが必要で、呼び出し元IPもAI_LLM_WS_IP_WHITELISTに入っていなければならない。標準のTLS・ホスト名検証を使い、useは一つのURLパス要素として符号化される。接続は5秒、応答は90秒で区切られ、時間切れは504のgateway_timeoutになる。チャット結果には用途、プロバイダー、モデル、遅延も含まれる。防御と運用の輪郭はかなり明確だ。

クライアントがサーバーの監査台帳を丸ごと複製しないことも、欠陥ではない。資格情報や完全なプロンプト、内部方針を各アプリへ配る必要はない。公開リポジトリからは、この版が本番配備されているか、ゲートウェイがどんな私的ログを持つか、呼び出し側が独自の相関IDを付けるかは分からない。DTOに欄がないという事実を、LACNICに記録がないという主張へ広げてはならない。

確認できる論点はもっと狭い。1.6.0は二つの時点をAPIにした。resolve(token, use)で用途に対応する設定を照会し、chat(token, use, messages)で用途とメッセージを改めて送る。READMEは、useを決めるのは呼び出しアプリで、クライアントはゲートウェイへ転送するだけだと説明している。

AiResolveDataには、用途、プロバイダー、モデルIDと表示名、有効状態、タイムアウト秒数、資格情報名がある。成功、HTTP状態、エラーも含む。AiChatDataは、テキスト、用途、プロバイダー、モデルID、遅延を返す。保存した応答を見れば、少なくともゲートウェイがどの提供者とモデルを申告したかは分かる。これは小さくない前進だ。

それでも、解決そのものには名前がない。二つの型にはresolutionId、configurationId、設定バージョン、共通のリクエストID、トレースID、相関IDがない。チャット実装も、先の解決オブジェクトや、そこで発行された不透明な券を受け取らない。useとメッセージをもう一度送るだけである。

プロバイダーとモデルが一致すれば十分に見える。しかし、属性の一致は状態の同一性ではない。解決型自身が、設定には有効・無効、タイムアウト、資格情報名もあることを示している。同じプロバイダーとモデルを選びながら、別の規則だけを変えた二つの版は成立する。二回の要求の間にuseの対応が更新されることも論理上は可能だ。公開資料は更新が起きたとは述べていない。起きた場合に、同じ二つの文字列では版を区別できない、と示しているだけだ。

たとえば午前10時、アプリが要約用途を解決し、プロバイダーA、モデルB、60秒という状態を記録したとする。10時1分のチャットもAとBを返した。この一致には意味がある。だが、その間に設定17から設定18へ変わり、両方がAとBを使っていたなら、どちらが回答を生んだかは公開クライアントから分からない。似た二枚の写真は、一枚の受領票にはならない。

これは競合状態や脆弱性の告発ではない。サーバーはチャット内で解決と実行を原子的に行い、完全な内部トレースを保存しているかもしれない。アプリが独自IDを入れる場合もある。非公開文書に別の保証がある可能性もある。証拠の境界は双方向だ。見えない仕組みを「ない」と書いてはいけないし、「きっとある」として公開契約の穴を埋めてもいけない。

時期は新しい。GitHubの1.6.0リリースは2026年9月12日付で、Java 17によるMaven全59テストの合格と構造検証の合格を報告する。1.5.1との比較では8コミット先にあり、最後の二つがAIゲートウェイクライアントの追加と呼び出しの堅牢化だ。長年放置されたAPIではなく、新機能の公開契約が固まる瞬間に検討している。

PortalAiClientTestは、守ろうとした不変条件を具体的に示す。Bearerの送信、カタログ値の読み取り、予約文字を含むuseの符号化、役割付きメッセージの直列化、空の用途の拒否、タイムアウトの504化、PortalWSClientからの委譲である。妥当な試験だ。解決IDをチャットへ渡す試験がないのは、そのための欄が契約にないからだ。

最小の改善は、二つの操作を無理に一体化することでも、内部設定を公開することでもない。resolveが不透明なresolutionIdまたは設定バージョンを返せばよい。厳格モードではチャットがそれを受け取り、期限切れや置換済みなら明示的に失敗する。柔軟モードでは可用性のため現在の設定を使えるが、実際に実行したIDを返す。どちらにも合理性がある。問題は、助言を固定と誤認させることだ。

私的なモデル解決受領票は簡潔でよい。解決IDを用途、方針・設定バージョン、プロバイダー、モデル、時刻、呼び出し要求に結ぶ。チャット後に実行ID、状態、遅延、再試行・キャッシュ、必要に応じてプロンプトや証拠パッケージと回答のハッシュを加える。ハッシュなら機密本文を配らずに同一性を確かめられる。秘密値は記載しない。

この受領票は回答の正しさ、公平さ、有用性を保証しない。その前の問いに答える。どの制御状態がこの出力を作ったのか。モデルカタログは経路の予定であり、回答は実行された出来事だ。両者の間を推測で渡るなら、監査は最初の一歩でつまずく。

LACNICにとっても防御になる。共通IDがなければ、予想外の回答を、実際には変更がなくても「ゲートウェイが黙って変えた」と疑われやすい。受領票があれば連続性を示すか、分岐点を限定できる。証拠を増やすことは責任を無限に広げるのではなく、むしろ責任の範囲を狭める。

なお、同じリポジトリについて以前扱ったJava 8の文書とJava 17のビルド・バイトコードの食い違いは別問題である。あちらはクライアントを起動できるかという互換性だった。今回は起動後、ゲートウェイの判断を再現できるかを問う。同じソフトウェアでも、検査している境界は重ならない。

出典