モデルと推論
チャットモデルは モデルオファリングカタログ （model_offerings.jsonc）で
のみ設定します。レガシーのプロバイダ別変数（AZURE_OPENAI_MODELS,
ANTHROPIC_MODELS, OPENAI_MODELS, FOUNDRY_MODELS, MODEL_MAX_CONTEXT_TOKENS,
ANTHROPIC_HOSTING、およびプロバイダ別のチャット endpoint/key 変数）は
削除されました。以下のプロバイダ別セクションに出てくる *_MODELS 等のスニペット
は、各 offering に必要な値を示すものです。それらの値はカタログの offering に
記述してください。共有の Azure 認証変数と OPENAI_API_KEY は保持されます。
マルチモデル切替
model_offerings.jsonc に複数の offering を記述し、会話の途中で切り替えられます:
- 入力欄の上に モデルセレクタが表示（モデルが 1 つだけのときは非表示）
- セッションごとのモデル選択が再読込後も保持
- 別モデルで再生成 -- Regenerate のシェブロンから選択
- 各アシスタントメッセージに生成したモデルを表示
- すべてのモデルが同じツール・Skills・MCP を共有
モデルごとのコンテキスト上限は、各 offering の context_window フィールドで
指定します（未指定時は 128000 が既定）。入力欄上のコンテキストバーは、モデル
切替時に自動更新されます。
モデルオファリングカタログ
すべてのチャットモデルを 1 つの JSONC ファイルで管理します。MODEL_OFFERINGS_FILE
に指定します（既定 model_offerings.jsonc、作業ディレクトリ基準で解決）。これが
モデルルーティングの単一の情報源です。カタログが無い非 demo デプロイは、
起動時に警告を出してそのまま起動し（アプリ内の Model Settings 画面で修正可能）、
チャットは利用できず、実行しようとした時点で chatwalaau models add / Model Settings
画面を案内するメッセージを返します（DEMO_MODE=true はカタログ無しで動作）。
各 offering が 1 つのモデルを記述します:
{
"auth_profiles": { "gateway": { "api_key_env": "GATEWAY_API_KEY" } },
"offerings": [
// 既定のチャットモデル（chat offering が最低 1 つ必須）
{
"id": "gpt-5.2",
"provider": "azure-openai",
"model_ref": "gpt-5.2", // 実際のデプロイメント名
"endpoint": "${AZURE_OPENAI_ENDPOINT}",
"default": true,
"context_window": 400000
},
// Anthropic 互換ゲートウェイ経由の Claude（offering 単位の hosting）
{
"id": "claude-opus-4-8",
"provider": "anthropic",
"hosting": "foundry",
"model_ref": "claude-opus-4-8",
"base_url": "https://my-gateway.example.com/anthropic",
"auth_profile": "gateway"
},
// 非 OpenAI 系の Foundry ファミリー: OpenAI の推論コントロールを無効化
{
"id": "deepseek-v4",
"provider": "foundry",
"model_ref": "my-deepseek-deployment",
"endpoint": "${FOUNDRY_PROJECT_ENDPOINT}",
"family": "bare"
},
// 任意: embeddings offering と image offering は各 1 つまで
{
"id": "embeddings",
"provider": "azure-openai",
"model_ref": "text-embedding-3-small",
"endpoint": "${AZURE_OPENAI_ENDPOINT}",
"operations": ["embeddings"]
}
]
}
利点:
- ゲートウェイ。 複数のモデルファミリーを提供する 1 つのエンドポイントを、
endpoint/base_urlを共有する複数 offering として表現できます（新しい プロバイダ設定は不要）。 - ホスティングの混在。 direct の Claude と Foundry ホストの Claude を 1 つの
インスタンスで併用できます（offering 単位の
hosting）。グローバルなANTHROPIC_HOSTINGでは不可能でした。 - チャットモデルは 1 つ必須、それ以外は任意。
chatoffering は最低 1 つ必須。embeddings/imageは任意。複数のチャットモデルがある場合、default: true（無ければ先頭）が既定として使われます。
ポイント:
- 秘密情報はファイルに書きません。 環境変数を名前で参照（
api_key_env）するか、 名前付きauth_profilesエントリ、または共有 Entra ID レーンを使います。endpoint/base_urlの${VAR}は環境から展開されます。 familyはゲートウェイモデルが提 示する生成オプションを上書きします:openai-reasoning（effort + verbosity）、anthropic-adaptive、bare（生成 コントロールなし。非推論のゲートウェイモデル向け）。- 不正なカタログは起動時に即座に失敗し、問題の offering 名を示します。 タイプミスでモデルが黙って消えることはありません。
DEMO_MODEは常にレガシーレーンを使います。レガシーの*_MODELS変数は カタログを後継として非推奨になりました（カタログが無い場合は引き続き サポートされます）。- カタログの不変条件（CLI・GUI・サーバのいずれもが強制）:
chatoffering は 最低 1 つ、その中で既定はちょうど 1 つ。id は一意。embeddingsとimageは各 1 つまで。hostingはanthropicプロバイダにのみ適用されます。
デプロイが機能を提供できない場合
一部の機能はモデルのデプロイが供給しており、使えるかどうかはモデルではなく そのデプロイの作り方で決まります。
Foundry 上の Claude: ホスティングオプションを正しく選ぶ
Foundry にはデプロイ作成時に選ぶ 2 つのホスティングオプションがあります。 ポータルで「Default settings」を選ぶと、制限のある Hosted on Azure になります。
| Hosted on Azure | Hosted on Anthropic | |
|---|---|---|
| 推論の実行場所 | Azure インフラ | Anthropic インフラ |
| hosted web search | ❌ 非対応 | ✅ 対応 |
| ネイティブ構造化出力 | ❌ 非対応 | ✅ 対応 |
非対応の機能を使うリクエストは設計上 400 で拒否されます。症状は次のとおりで、
毎ターン失敗します。
web search not supported in your workspace
対処は ChatWalaʻau 側の設定変更ではなく、デプロイの作り直しです。
- Foundry ポータル → モデルカタログ → 対象の Claude モデル → Deploy → Custom settings
- Model version settings を展開し、Hosted on Anthropic とラベルされたバージョンを選択
- デプロイ名を控え、offering の
model_refをその名前に変更
同一 Foundry リソース内であれば、エンドポイント URL と認証は変更不要です。変わるのは デプロイ名だけです。
Anthropic は web search ツールを 3 バージョン公開していますが、3 つとも server-side tool です。したがって Hosted on Azure ではどれも動作せず、新しい 2 つは code execution （これも非対応）を必要とするため、さらに動きません。
制限のあるデプロイのまま使う場合
その offering に「このデプロイでは提供できない」と伝えれば、ChatWalaʻau は送信を止めます。 モデル設定画面から、またはファイルに直接記述し ます。
{
"id": "claude-opus-5-foundry",
"provider": "anthropic",
"model_ref": "claude-opus-5",
"hosting": "foundry",
"capabilities": {
"web_search": false,
"native_structured_output": false
}
}
2 つの設定は挙動が異なり、その違いが重要です。
| 設定 | 「Not available」にしたときの動作 |
|---|---|
| Hosted web search | 機能そのものを外します。 代替が存在しないためです。システムプロンプトの web search 案内も同時に外れるので、エージェントが「検索できる」と主張することはなく、出典を捏造することもありません。 |
| Native structured output | 結果ではなく機構が変わるだけです。 Structured Output は forced-tool-use フォールバック経由で動作し続け、スキーマに準拠した JSON を返します。 |
黙って消えることはありません。外されたツールはプロンプトダンプに provider capability
という理由付きで除外表示され、サーバーログにも offering 名を含む 1 行が出ます。
実際にこれが原因で失敗するまでは、両方とも Default のままにしてください。Default は 「プロバイダに任せる」という意味で、これらの設定が存在する前のすべての offering の挙動と 同じです。
そのデプロイをネイティブ foundry プロバイダとして登録すると、プラットフォーム提供の
web search が使えます（Anthropic 側の制限を受けません）。ただしネイティブ側の生成
オプションはデプロイ名で判定されるため、Claude のデプロイでは生成オプションが表示され
ません。通常は Hosted on Anthropic で作り直すほうが適切です。
モデルの表示順
ファイル内の chat offering の並び順が、そのままモデルセレクタの表示順になります。 最もよく使うモデルを先頭に置けば、先頭に表示されます。
default: true フラグが決めるのは、新しいチャットでどのモデルが初期選択されるか
だけです。そのモデルを一覧の先頭に移動させるものではありません。ファイル内で 3 番目
にある default は 3 番目に表示され、それでも初期選択されるモデルです。
v0.106.0 より前は、default モデルはファイル内の位置にかかわらず常にセレクタの先頭へ 引き上げられていました。default が先頭にない場合、アップグレード後はドロップダウンの 並びが変わって見えます（default が実際の位置に表示されるようになります）。どのモデルが 応答するかは変わりません。以前の見た目に戻すには、モデル設定画面でそのモデルを先頭に ドラッグし てください。
offering の作成（CLI と GUI）
JSONC を手書きする必要はありません。カタログは運用者が設定可能で、方法は 2 つ
あります。どちらも同じ MODEL_OFFERINGS_FILE を読み書きするため、併用できます。
list は従来どおり稼働中サーバの状態を反映し、下記の作成コマンドと画面はファイル
そのものを管理します。
CLI（オフライン、サーバ不要）。 chatwalaau models コマンドはローカルのカタログ
ファイルを読み書きし、無ければ作成します:
# 対話ウィザード: offering を 1 つ作成して追記
$ chatwalaau models add
Provider [azure-openai / anthropic / openai / foundry]: anthropic
Model ref: claude-opus-4-8
Operation [chat / embeddings / image]: chat
Offering id: claude-opus-4-8
Default chat model? [y/N]: y
Base URL: https://api.anthropic.com
Hosting [direct / foundry]: direct
Family (optional):
Context window (optional): 200000
API key environment variable name: ANTHROPIC_API_KEY
Wrote model_offerings.jsonc (1 offering).
# id を指定して既存の offering を編集 / 削除
$ chatwalaau models edit claude-opus-4-8
$ chatwalaau models remove claude-opus-4-8
# 稼働中サーバが提供中のモデルを一覧（読み取り専用、従来どおり）
$ chatwalaau models list
ウィザードが尋ねるのは API キーの環境変数の名前（api_key_env）だけで、秘密の
値ではありません。chatwalaau init は .env を書き出した直後にこの「最初のモデルを
設定する」ステップを実行す ることもできます（chatwalaau init --no-model や
非対話実行ではスキップ）。したがってモデルは init の前でも後でも設定できます。
GUI（モデル設定画面）。 チャットサイドバー下部のギア／スライダーアイコン（info アイコンの隣）からモデル設定画面を開きます。左ペインは検索可能な設定リスト （更新ボタン付き）、右ペインはモデルオファリングカタログのエディタです。offering は 操作ごとにまとめて構成します -- Chat（最低 1 つ、既定はちょうど 1 つ）、 Embeddings（0〜1）、Image（0〜1）。参照する各環境変数には 検出済み / 未設定のインジケータが表示され、値を一切見ることなくキーの有無を 確認できます。保存はインプロセスのホットリロードで即座に適用され（再起動不要）、 適用中は進行インジケータが表示されます。
各 offering はコンパクトな行（id / プロバイダ / モデル / 既定）で表示され、編集 したいときにクリックで展開します。グリップハンドルをドラッグして並べ替えでき、 その順序がそのままチャットのモデルセレクタの表示順になります。
GUI からの保存はクリーンな JSON を書き出すため、model_offerings.jsonc に手書きした
コメントは保持されません（名前付きの auth_profiles エントリは保持されます）。CLI
の編集はサーバの次回起動時に反映され、GUI の保存は稼働中サーバをその場でホットリロード
します。新しい環境変数は増えません -- どちらの方法も MODEL_OFFERINGS_FILE（既定
model_offerings.jsonc）を使います。
タスク別モデルの割り当て
セレクタで選ぶチャットモデルとは別に、ChatWalaʻau はいくつかのバックグラウンド補助 モデルを実行します -- チャットのタイトル生成、ユーザーメモリ抽出、エージェント メモリ整理、Teams 会議の要約、自然言語質問からオントロジー SPARQL への変換です。 これらは既存のチャット offering のいずれかに割り当てられ、その offering のプロバイダ・ エンドポイント・認証情報を自動的に引き継ぎます。
- GUI. Model Settings 画面の Task model assignments セクションに、各タスクと 「チャッ ト offering ＋ Follow session / default」のドロップダウンが並びます。
- CLI.
chatwalaau models role listでタスクと現在の割り当てを表示、chatwalaau models role set <role> <offering-id>で割り当て、chatwalaau models role clear <role>で解除します。 - ファイル.
model_offerings.jsoncの任意のトップレベルrolesブロックに保存されます。 例:"roles": { "session_title": "gpt-4o-mini" }。
未割り当てのタスクはチャット自身のモデル（次いでカタログ既定）を使います（既定の挙動）。
役割キーは session_title / user_memory_extraction / agent_memory_curation /
meeting_summary / ontology_nl です。
v0.109.0 以降、この割り当てが専用の SESSION_TITLE_MODEL /
USER_MEMORY_EXTRACTION_MODEL / AGENT_MEMORY_CURATION_MODEL /
TEAMS_MEETING_SUMMARY_MODEL / ONTOLOGY_NL_MODEL 環境変数を置き換え、これらは削除
されました。残存する変数は無視されます（起動時に後継の役割を案内する助言が出ます）。
Anthropic（Claude）プロバイダ
Azure OpenAI と並べて Claude モデルを有効化できます。同じセレクタに表示され、ターン
単位で選べます。Anthropic は既定で無効で、ANTHROPIC_MODELS 未設定なら何も
変わりません。
1 変数で 2 つのホスティングを選択:
# direct（Anthropic 公開 API） | foundry（Azure AI Foundry 上の Anthropic）
ANTHROPIC_HOSTING=direct
ANTHROPIC_MODELS=claude-sonnet-4-5-20250929,claude-haiku-4-5
Direct ホスティング:
ANTHROPIC_API_KEY=sk-ant-...
# ANTHROPIC_BASE_URL=https://your-gateway.example.com # 任意のプロキシ
Foundry ホスティング（Azure AI Foundry 上の Anthropic）-- エンドポイントと認証を それぞれ 1 つだけ指定します:
ANTHROPIC_HOSTING=foundry
ANTHROPIC_FOUNDRY_RESOURCE=my-aifoundry # リソース名（サブドメイン）のみ
# または: ANTHROPIC_FOUNDRY_BASE_URL=https://my-aifoundry.services.ai.azure.com/anthropic/
# 認証 A -- API キー（api-key ヘッダで送信）:
ANTHROPIC_FOUNDRY_API_KEY=<foundry-key>
# 認証 B -- Entra ID: API キーを空にして AZURE_CREDENTIAL_MODE
# （cli | managed-identity | default）+ AZURE_TENANT_ID を再利用。
ANTHROPIC_FOUNDRY_RESOURCE は Azure AI Services のリソース名（サブドメイン）で
あり、Foundry のプロジェクト URL ではありません。Entra ID 認証では
ANTHROPIC_FOUNDRY_API_KEY にトークンを入れないでください。そのまま api-key ヘッダ
として送られ HTTP 401 になります。
Anthropic は各リクエストに出力上限として max_tokens を必須とします:
ANTHROPIC_MAX_TOKENS=8192
ホスト型 Web 検索は Claude で標準利用できます（web_search_20250305）。その他の
エージェント機能は、モデルがツール呼び出しに対応していればどちらのプロバイダでも
動作します。STT・TTS・画像生成・RAG 埋め込みは専用の Azure モデルで動き、チャット
プロバイダの選択に依存しません。
OpenAI（direct）プロバイダ
OpenAI 公開 API のモデルを Azure OpenAI・Anthropic と並べて有効化できます。同じ
セレクタに表示され、ターン単位で選べます。OpenAI は既定で無効で、OPENAI_MODELS
未設定なら何もしません。
認証は API キーのみです:
OPENAI_MODELS=gpt-5.1
OPENAI_API_KEY=sk-...
# OPENAI_BASE_URL=https://your-gateway.example.com # 任意（OpenAI 互換ゲートウェイ）
本リリースは推論モデル（例: gpt-5.x / o系）をサポートします。これらは Azure OpenAI
の推論モデルと全く同じ挙動です -- 同じ推論努力度・冗長度コントロール、ホスト型 Web 検索
（WEB_SEARCH_COUNTRY による国別スコープ）、構造化出力、バックグラウンド応答に対応します。
非推論モデル（gpt-4o / gpt-4.1）は後続リリースで対応予定です。
Microsoft Foundry プロバイダ
Microsoft Foundry プロジェクトにデプロイした推論モデルを、他のプロバイダと並べて
有効化できます。同じセレクタに表示され、ターン単位で選べます。Foundry は既定で
無効で、FOUNDRY_MODELS 未設定なら何もしません。
FOUNDRY_MODELS=gpt-5.1
FOUNDRY_PROJECT_ENDPOINT=https://<resource>.services.ai.azure.com/api/projects/<project>
認証は Entra ID のみで、Azure OpenAI と同じ Azure 認証設定を再利用します:
AZURE_CREDENTIAL_MODE（cli = az login、Azure ホスト環境では
managed-identity、または default）と AZURE_TENANT_ID のピン留めです。
API キーのオプションはありません -- Foundry プロジェクトエンドポイントは
Entra ID で認証します。サインインする ID にプロジェクトリソース上の Foundry
データプレーンロール（例: Azure AI User）を付与してください。
AZURE_OPENAI_API_KEY はこのプロバイダには適用されません。
Foundry のチャットモデルデプロイは何でも列挙できます。生成コントロールは モデルファミリーに合わせて変わります: OpenAI 推論系デプロイ（gpt-5.x / o系の 名前）は Azure OpenAI 推論モデルと同じ推論努力度・冗長度コントロールを公開し、 それ以外のファミリー（例: DeepSeek）は生成コントロールを表示しません -- それらのモデルが拒否するパラメータはリクエストに含まれません。 Web 検索（引用付き）と構造化出力は全ファミリーで動作します。 バックグラウンド応答は本リリースでは未対応です。
このプロバイダは Foundry プロジェクトエンドポイント（FOUNDRY_*）からモデルを
ネイティブに提供します。Anthropic プロバイダの Foundry ホスティングオプション
（ANTHROPIC_HOSTING=foundry + ANTHROPIC_FOUNDRY_*、Foundry の Anthropic ルート
経由で Claude モデルを提供）とは別物です。
モデル ID は全プロバイダ間で一意である必要があり（AZURE_OPENAI_MODELS・
ANTHROPIC_MODELS・OPENAI_MODELS・FOUNDRY_MODELS）、衝突は起動 時に拒否されます。
モデルセレクタは Azure を先頭、次に Anthropic、次に OpenAI、次に Foundry を並べ、
既定モデルは Azure が設定されていればその先頭モデルです。
メッセージ単位の生成オプション
モデルセレクタの隣に生成オプションパネルがあり、選択中のモデルが受け付ける
オプションごとにコンパクトなコントロールを1つずつ表示します。利用可能なオプション・
許可値・既定値はすべてバックエンド（GET /api/model の model_options カタログ）が
提供し、UI はモデルが広告したものだけを描画します。そのため、そのモデルで使えない
コントロールは決して表示されません。環境変数はありません。各オプションのセッション
単位の選択はリロード後も保持され、解決された値はモデル名とトークン使用量の横に表示され、
セッションに保存されます。
推論努力度
メッセージごとにモデルの思考の深さを設定します。
| プロバイダ | レベル | 既定 | 仕組み |
|---|---|---|---|
| Azure OpenAI（gpt-5.5 / gpt-5.4） | low, medium, high, xhigh | medium | reasoning.effort |
| OpenAI（direct、gpt-5.x / o系） | low, medium, high, xhigh | medium | reasoning.effort |
| Microsoft Foundry（gpt-5.x / o系デプロイ） | low, medium, high, xhigh | medium | reasoning.effort |
| Anthropic（Opus 4.8 / 4.7） | low, medium, high, xhigh, max | xhigh | adaptive thinking + output_config.effort |
冗長度（Azure OpenAI gpt-5.x）
思考の深さとは独立に、回答の簡潔さ／詳しさを設定します。Azure OpenAI gpt-5.x の
みで提供（low / medium / high、既定 medium）、OpenAI Responses API の
text.verbosity に対応します。既定値の選択は出力中立で、非既定値を選ぶまでリクエ
ストは一切変わりません。
現在サポートする2モデルファミリーはいずれも推論／adaptive-thinking モデルです。
Anthropic Opus 4.7/4.8 は temperature・top_p・top_k を HTTP 400 で拒否し、
Azure OpenAI gpt-5.x の推論モデルも受け付けません。したがってオプションカタログは
これらのモデルにサンプリング系パラメータを提供しません。ただし仕組みは汎用で、将来
非推論モデルが追加されれば temperature / top_p を広告でき、対応するスライダーが
自動的に表示されます。
プロンプトキャッシュ（入力トークンコスト）
すべてのモデル呼び出しは、大きく安定したプレフィックス -- システムプロンプトと全 ツールスキーマ -- を毎回送り直します。長いターン（特に 1 メッセージが多数の逐次モデル 呼び出しに展開されるコーディングのツールループ）では、このプレフィックスが何度も 課金されます。プロンプトキャッシュは安定プレフィックスをキャッシュ可能として マークし、1 度だけ課金して以降の呼び出しでは安価に再読込します。出力透過であり、 モデルの応答は同一で、課金とレイテンシだけが変わります。
既定で有効、かつプロバイダ非依存です:
- Anthropic（Claude）: バックエンドがシステムブロック（ツール定義も併せてカバー）
と直近の会話メッセージ数件に
cache_controlブレークポイントを注入します。これに よりエージェント／コーディングのツールループで、会話タール（ツール結果・ファイル内容・ 思考）が毎モデルコールでフル価格再課金される代わりに、大幅割引で再読込されます。 - Azure OpenAI: 約 1024 トークン以上のプレフィックスでプロンプトキャッシュが 自動適用されます。設定は不要です。
非常に長いツールループでは、sliding-window の履歴コンパクションが会話プレフィックスを
ずらし会話キャッシュの命中率を下げます。キャッシュを優先する場合は
COMPACTION_KEEP_LAST_GROUPS を上げる（安定窓を広げる）か、
ANTHROPIC_PROMPT_CACHE_TTL=1h を設定（数分の空白を跨いで保持）してください。
# マスタートグル（既定 true）。false でキャッシュを完全に無効化。
PROMPT_CACHE_ENABLED=true
# Anthropic のキャッシュ寿命: 5m（既定）または 1h（拡張キャッシュ）。不明値は 5m。
ANTHROPIC_PROMPT_CACHE_TTL=5m
有効なプロバイダがキャッシュ使用量を報告すると、メッセージ単位のトークン表示に
cache_read_input_tokens / cache_write_input_tokens が含まれ、節約を直接確認できます。
Claude でクレジット消費がまだ多いと感じる場合 は、メッセージ単位の推論努力度
（上記のセレクタ）も下げてください。Anthropic の既定は xhigh で、毎ステップの思考に
多くの出力トークンを使います。多くのコーディング編集には medium や low で十分です。
構造化出力（JSON）
アシスタントの回答を散文ではなく JSON（任意で特定の JSON Schema）に拘束し、 機械可読にできます。全ベースプロバイダ（Azure OpenAI / Anthropic / OpenAI）で動作し、 メッセージ単位のオプトインです。オフのときはリクエストは従来どおり変わりません。
チャット UI で。 入力欄上部のモデルオプションの隣に { } 構造化出力トグルが
あります。オンにすると次の回答が JSON で返り、コピー可能なコードブロックとして
表示されます。2モード:
- 汎用 JSON ― トグルをオンにするだけ。整形済みの JSON オブジェクトが返ります。
- 明示スキーマ ― 小さなエディタ（
+schema/editボタン）を開いて JSON Schema を 貼り付けます。回答はスキーマに拘束されます。空または不正なスキーマは汎用 JSON に 縮退します。
構造化出力に対応しないモデルではトグルは非表示になり、best-effort フォールバックのみ 対応するモデルにはその旨が注記されます。
「スキーマなし」の意味はモデルによって異なります
スキーマを書かずにトグルをオンにすると既定スキーマにフォールバックします。この既定は プロバイダごとの性質です。
| プロバイダ | スキーマ未指定時の既定 |
|---|---|
| Azure OpenAI / OpenAI | 任意の JSON オブジェクト（{"type": "object", "additionalProperties": true}） |
| Anthropic（Claude） | {"answer": "..."} ― answer という文字列 1 つを持つオブジェクト |
この違いは ChatWalaʻau の都合ではありません。Anthropic の構造化出力はすべてのオブジェクトに
additionalProperties: false を要求し、省略も認めず、フリーフォーム JSON を求める手段も
提供していないため、「任意の JSON オブジェクト」を表現できないからです。機能自体を
使えなくするのではなく、妥当な最小形にフォールバックし、実際に得られる形をスキーマ
エディタが明示します。驚きにはなりません。
形が重要な場合は必ず自分のスキーマを指定してください。 明示スキーマはどのプロバイダでも 既定より優先されます。
strict 規則を満たすスキーマは、どのプロバイダでも動作します。
{
"type": "object",
"properties": { "answer": { "type": "string" } },
"required": ["answer"],
"additionalProperties": false
}
すべての配列に "items"、すべてのオブジェクトに "additionalProperties": false が必要で、
宣言したプロパティはすべて "required" に列挙する必要があります。違反はエディタが
該当サブスキーマのパス付きで、送信前に一覧表示します。
Web 検索と構造化出力は同時に使えません（プロバイダがその組み合わせを拒否します）。 そのため構造化出力がオンの間は、そのターンの Web 検索はスキップされます。その他の ツール（コーディング、天気など）は通常どおり動作します。
出荷モデルの既定である native の strict 構造化出力はプロバイダ側で形を保証するため、 別途の検証ステップは不要です。ChatWalaʻau は軽量・非ブロッキングなチェックのみ 行い、メッセージに小さな JSON バッジを表示します（パースできなかった場合 ― 例: 長すぎて途中で切れた回答 ― は amber 表示）。回答をブロックしたり書き換えたりは しません。
API 経由で。 OpenAI 互換 Responses API は標準の text.format フィールドを
受理するため、既存の OpenAI SDK コードがそのまま動作します ―
OpenAI 互換 API を参照。
信頼性: 一時的なプロバイダエラー
モデルプロバイダはまれに一時的なサーバエラー（HTTP 5xx） ―「The server had an error processing your request.」― を返すことがあります。コーディングセッションでは 1つの質問が多数の逐次モデルコールに展開されるため、1ターンに1回は引く確率が高くなります。
ChatWalaʻau がこれを自動的に処理します:
- 出力前は自動再送。回答のストリーミングが始まる前にエラーが起きた場合、バック エンドが自動的にリクエストを再送します（少数回の上限付き、短いバックオフ）。まだ何も 表示・保存されていないため安全で、モデルは単純にターンを最初からやり直します。再送中は チャットに「Temporary server error -- retrying...」 という短い通知を表示し、停止では なく進行中であることが分かるようにします。
- 黙った重複は起こさない。回答のストリーミングが始まった後にエラーが起きた場合は 再送しません（重複出力の恐れがあるため）。「一時的なサーバエラー ― 再送してください」 という明確なメッセージが出るので、もう一度送るか、会話が非常に長い場合は新しいチャットを 開始してください。
再送しても解決しないエラーは区別して報告され、再送対象外です:
| 状況 | 表示 | 対処 |
|---|---|---|
| クレジット/クォータ切れ | プロバイダ名を含む課金メッセージ | クレジット追加/クォータ引き上げ、または別の設定済みモデルに切替 |
| レート制限（429） | レート制限メッセージ | 少し待って再試行、推論努力度を下げる、またはデプロイのクォータを引き上げ |
| 出力後の一時的 5xx | 「一時的なサーバエラー ― 再送してください」 | 再送。会話が非常に長い場合は新しいチャットを開始 |