v0.129.0 で App Settings へ移動

本ページの調整値は .env ではなく、アプリ内の App Settings 画面（サイドバー下部のスライダーアイコン）で設定し、app_settings.jsonc に保存されます。.env に残った値は無視され、起動ログにキー名が 1 度だけ列挙されます。既存の設定を引き継ぐには chatwalaau settings migrate --write を実行してください。機能の有効化ゲートと シークレットは .env のままです。詳細は設定 -> アプリケーション設定。

モデルと推論

v0.107.0 で変更

チャットモデルは モデルオファリングカタログ（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 デプロイは、起動時に警告を出してそのまま起動し（アプリ内の App Settings 画面で修正可能）、チャットは利用できず、実行しようとした時点で chatwalaau models add / App 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": "https://<resource>.services.ai.azure.com/api/projects/<project>",
      "family": "bare"
    },
    // 任意: embeddings / image / live / decision / transcription / speech 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 つ必須、それ以外は任意。 chat offering は最低 1 つ必須。 embeddings / image / live / decision / transcription / speech は任意。複数のチャットモデルがある場合、default: true （無ければ先頭）が既定として使われます。

ポイント:

秘密情報はファイルに書きません。 環境変数を名前で参照（api_key_env）するか、名前付き auth_profiles エントリ、または共有 Entra ID レーンを使います。 endpoint / base_url の ${VAR} は環境から展開されます。
family はゲートウェイモデルが提示する生成オプションを上書きします: openai-reasoning（effort + verbosity）、anthropic-adaptive、bare（生成コントロールなし。非推論のゲートウェイモデル向け）。family は provider と整合している必要があります（azure-openai / openai / foundry は openai-reasoning または bare、anthropic は anthropic-adaptive または bare）。それ以外の組み合わせは起動時に拒否されます。省略するとプロバイダが推論します。
不正なカタログは起動時に即座に失敗し、問題の offering 名を示します。タイプミスでモデルが黙って消えることはありません。
DEMO_MODE は常にレガシーレーンを使います。レガシーの *_MODELS 変数はカタログを後継として非推奨になりました（カタログが無い場合は引き続きサポートされます）。
カタログの不変条件（CLI・GUI・サーバのいずれもが強制）: chat offering は最低 1 つ、その中で既定はちょうど 1 つ。id は一意。embeddings、image、 live、decision は各 1 つまで。live と decision の offering は azure-openai プロバイダを使い、他の操作と兼用できません。hosting は anthropic プロバイダにのみ適用されます。live offering は Live 会話を有効にする GPT-Live の音声デプロイです。decision offering は decision_evaluate ツールを提供する Microsoft-Decision-1 のデプロイです（v0.195.0）。family、hosting、context_window、 base_url、api_version、image_defaults、capabilities は適用されず、指定すると拒否されます。
音声の offering（v0.205.0）: transcription（音声入力、azure-openai）と speech （読み上げ、azure-openai または elevenlabs）は各 1 つまでで、他の操作と兼用できず、チャット専用の項目は指定できません。elevenlabs は speech 専用のプロバイダで、 api_key_env が必要です。詳しくは音声とスピーチを参照してください。

デプロイが機能を提供できない場合

一部の機能はモデルのデプロイが供給しており、使えるかどうかはモデルではなくそのデプロイの作り方で決まります。

Foundry 上の Claude: ホスティングオプションを正しく選ぶ

Foundry にはデプロイ作成時に選ぶ 2 つのホスティングオプションがあります。 ポータルで「Default settings」を選ぶと、制限のある Hosted on Azure になります。

	Hosted on Azure	Hosted on Anthropic
推論の実行場所	Azure インフラ	Anthropic インフラ
hosted web search	❌ 非対応	✅ 対応
Structured output	❌ 非対応	✅ 対応

非対応の機能を使うリクエストは設計上 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 は送信を止めます。 App Settings 画面から、またはファイルに直接記述します。

{
  "id": "claude-opus-5-foundry",
  "provider": "anthropic",
  "model_ref": "claude-opus-5",
  "hosting": "foundry",
  "base_url": "https://my-aifoundry.services.ai.azure.com/anthropic",
  "capabilities": {
    "web_search": false,
    "native_structured_output": false,
    "mcp": false,
    "skills": false,
    "image_generation": false,
    "computer_use": false
  }
}

設定ごとに振る舞いが異なり、その違いが重要です:

設定	「利用不可」にしたときの動作
Web search	機能そのものを外します。代替が存在しないためです。システムプロンプトの web search 案内も同時に外れるので、エージェントが「検索できる」と主張することはなく、出典を捏造することもありません。
Structured output	このモデルで機能を OFF にします。出力スキーマを設定済みの run-target は、このモデル上では素の文章で応答し、Built-in agent のカードがその旨を表示します。縮退経路はありません -- かつて本プロジェクトが実装していた forced-tool-use フォールバックは Agent Framework と互換性がなく、v0.125.0 で削除されました。
MCP	このモデルから MCP ツールをすべて外します（stdio と HTTP のどちらのサーバーも）。MCP 案内も同時に外れます。MCP サーバ自体は動作し続け、他のモデルはツールを保持します。変わるのはこのモデルに提示される内容だけです。v0.203.0 より前は案内だけが外れ、ツールは送られたままでした（修正済み）。
Skills	このモデルから Agent Skills を外します。スキルは一切提示されず、`load_skill` / `read_skill_resource` / `run_skill_script` も存在しません。Skills 管理画面とディスク上のスキルは無変更です。
Image generation	この chat モデルから `image_generate` / `image_edit` を外します。image オファリング自体と他の chat モデルには影響しません。
Computer Use	このモデルから *`computer_` のデスクトップ操作ツールを外します（v0.170.0）。画像を読めないモデルや、クリック精度の低いモデルに使います。Foundry** プロバイダーのモデルには、そもそも提供されません（そのコネクタはツールが返す画像を捨てるため）。Computer Use を参照。
CodeAct	このモデルから、CodeAct の計算用サンドボックスである `execute_code` を外します（v0.172.0）。関数呼び出しが弱いモデルに使います。サンドボックス自体は App Settings > CodeAct が ON のときだけ存在します。
Function calling	常時利用可能として表示され、無効化できません（下記参照）。

これは ChatWalaʻau の設定ではなくプロバイダ側の制約です。Responses API は JSON 出力フォーマットとホスト型 Web search ツールの両方を含むリクエストを拒否します（Web Search cannot be used with JSON mode.）。ChatWalaʻau はターンを失敗させる代わりに、Structured output を要求するターンでは Web search を剥落させます。

どこで起きているかは明示されるので、「検索しなくなった」理由が分かります。

スキーマ設定中は、ChatWalaʻau Core カードと Custom agent エディタの両方に "Web search is dropped while structured output is on" と表示されます
Prompt Dump のツールサーフェスは web_search を理由 structured output 付きの EXCLUDED として一覧します

Structured output を OFF にすれば（Core カードのフォーマットをクリアする、または Custom agent から outputSchema を削除する）、次のターンから Web search が戻ります。

Function calling を無効化できない理由

MCP ツールも 3 つの skill ツールも 2 つの画像ツールも、すべて function tool として プロバイダに届きます。関数呼び出しができないモデルはそれらを一切保持できないため、「function calling オフ、MCP オン」と書けるカタログは、存在し得ないものを記述していることになります。ChatWalaʻau はその組み合わせを検証するのではなく、取り除きました。語彙全体を 1 箇所で見渡せるよう行は表示し、値は 利用可能 に固定されています。

Function calling をサポートするモデルのみを chat オファリングとして登録してください。 ファイルに "function_calling": false と書くと、その旨を述べるエラーで読み込みが拒否されます。

これは opt-in ではなく opt-out です

書かなかった Capability は有効を意味します。capabilities ブロックが無いオファリング、Default のままのキー、未知のモデル、カタログ自体が無い場合 — そのすべてが「利用可能」に解決されます。明示的に 利用不可 を選んだときだけ機能が外れます。これらの設定を追加しても既存のオファリングの挙動が一切変わらないのは、このためです。

何も黙って消えることはありません。外されたツールは prompt dump に provider capability という理由付きで除外として現れ、Built-in エージェントカードは選択中のモデルが何を外しているかを明示し、サーバログにはオファリング名を含む 1 行が出ます。

同じ規則は「誰の設定でもない不在」にも適用されます。ホスト型 Web search は Structured output が ON のあいだ剥落します（プロバイダが両者の組み合わせを拒否するため）。この場合は理由 structured output 付きの除外として一覧され、このカタログではなく run-target 側のカードを指し示します。

実際にリクエストが失敗するまでは、すべて Default のままにしてください。Default は「利用可能」であり、これらの設定が存在しなかった頃と同じ挙動です。

Foundry で Claude と web search を両立するもう一つの方法

そのデプロイをネイティブ foundry プロバイダとして登録すると、プラットフォーム提供の web search が使えます（Anthropic 側の制限を受けません）。ただしネイティブ側の生成オプションはデプロイ名で判定されるため、Claude のデプロイでは生成オプションが表示されません。通常は Hosted on Anthropic で作り直すほうが適切です。

モデルの表示順

ファイル内の chat offering の並び順が、そのままモデルセレクタの表示順になります。 最もよく使うモデルを先頭に置けば、先頭に表示されます。

default: true フラグが決めるのは、新しいチャットでどのモデルが初期選択されるか だけです。そのモデルを一覧の先頭に移動させるものではありません。ファイル内で 3 番目にある default は 3 番目に表示され、それでも初期選択されるモデルです。

v0.106.0 での変更

v0.106.0 より前は、default モデルはファイル内の位置にかかわらず常にセレクタの先頭へ引き上げられていました。default が先頭にない場合、アップグレード後はドロップダウンの並びが変わって見えます（default が実際の位置に表示されるようになります）。どのモデルが応答するかは変わりません。以前の見た目に戻すには、App Settings 画面でそのモデルを先頭にドラッグしてください。

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 / live / decision / transcription / speech]: 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（App Settings 画面）。 チャットサイドバー下部のギア／スライダーアイコン（info アイコンの隣）から App Settings 画面を開きます。左ペインは検索可能な設定リスト（更新ボタン付き）、右ペインはモデルオファリングカタログのエディタです。offering は操作ごとにまとめて構成します -- Chat（最低 1 つ、既定はちょうど 1 つ）、 Embeddings（0〜1）、Image（0〜1）、Live（0〜1）。参照する各環境変数には 検出済み / 未設定のインジケータが表示され、値を一切見ることなくキーの有無を確認できます。保存はインプロセスのホットリロードで即座に適用され（再起動不要）、適用中は進行インジケータが表示されます。

各 offering はコンパクトな行（id / プロバイダ / モデル / 既定）で表示され、編集したいときにクリックで展開します。グリップハンドルをドラッグして並べ替えでき、その順序がそのままチャットのモデルセレクタの表示順になります。

注記

GUI からの保存はクリーンな JSON を書き出すため、model_offerings.jsonc に手書きしたコメントは保持されません（名前付きの auth_profiles エントリは保持されます）。CLI の編集はサーバの次回起動時に反映され、GUI の保存は稼働中サーバをその場でホットリロードします。新しい環境変数は増えません -- どちらの方法も MODEL_OFFERINGS_FILE（既定 model_offerings.jsonc）を使います。

タスク別モデルの割り当て

セレクタで選ぶチャットモデルとは別に、ChatWalaʻau はいくつかのバックグラウンド補助モデルを実行します -- チャットのタイトル生成、ユーザーメモリ抽出、エージェントメモリ整理、Teams 会議の要約、自然言語質問からオントロジー SPARQL への変換、そして v0.169.0 からは Live 会話が任せた作業の実行です。これらは既存のチャット offering のいずれかに割り当てられ、その offering のプロバイダ・エンドポイント・認証情報を自動的に引き継ぎます。

GUI. App 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" }。

未割り当てのタスクはチャット自身のモデル（次いでカタログ既定）を使います（既定の挙動。 Live delegation では選択中エージェント自身のモデル）。役割キーは session_title / user_memory_extraction / agent_memory_curation / meeting_summary / ontology_nl / live_delegation です。

注記

v0.109.0 以降、この割り当てが専用の SESSION_TITLE_MODEL / USER_MEMORY_EXTRACTION_MODEL / AGENT_MEMORY_CURATION_MODEL / TEAMS_MEETING_SUMMARY_MODEL / ONTOLOGY_NL_MODEL 環境変数を置き換え、これらは削除されました。残存する変数は無視されます（起動時に後継の役割を案内する助言が出ます）。

Anthropic（Claude）プロバイダ

Claude モデルは、モデルオファリングカタログの中で "provider": "anthropic" を持つオファリングとして設定します。ほかのモデルと同じセレクターに表示され、ターンごとに選べます。オファリングごとにホスティングを選べるので、 direct と Foundry 上の Claude を並べて使えます。

direct ホスティング（Anthropic の公開 API）-- キーは、オファリングが名前を指定する環境変数に置きます:

{
  "id": "claude-opus-4-8",
  "provider": "anthropic",
  "hosting": "direct",                 // 省略時の既定
  "model_ref": "claude-opus-4-8",
  "api_key_env": "ANTHROPIC_API_KEY"   // または auth_profile
  // "base_url": "https://your-gateway.example.com"  // 任意のプロキシ
}

Foundry ホスティング（Microsoft Foundry 上の Anthropic）-- オファリングの base_url に、Anthropic on Foundry の完全な URL を指定します:

{
  "id": "claude-opus-5",
  "provider": "anthropic",
  "hosting": "foundry",
  "model_ref": "claude-opus-5",        // Foundry のデプロイ名
  "base_url": "https://my-aifoundry.services.ai.azure.com/anthropic"
  // 認証 A -- API キー: "api_key_env": "MY_FOUNDRY_KEY"
  // 認証 B -- Entra ID: api_key_env を省略すると共有の Azure 資格情報を使います
  //           (AZURE_CREDENTIAL_MODE = cli | managed-identity | default)
}

Foundry 上の Claude は endpoint ではなく base_url を使います

base_url は https://<resource>.services.ai.azure.com/anthropic です。Foundry の プロジェクト URL（.../api/projects/...）ではなく、Azure AI Services のリソース名 から組み立てます。このホスティングでは endpoint は使いません。v0.163.0 からは、 endpoint を指定したオファリングや base_url のないオファリングは、カタログの保存時と読み込み時に、直し方を示すメッセージとともに拒否されます。Entra ID 認証では、 api_key_env でトークンを指定しないでください。そのまま api-key ヘッダーとして送られ、 HTTP 401 になります。

廃止された環境変数

ANTHROPIC_HOSTING、ANTHROPIC_MODELS、ANTHROPIC_FOUNDRY_RESOURCE、 ANTHROPIC_FOUNDRY_BASE_URL、ANTHROPIC_FOUNDRY_API_KEY はもう読まれません。カタログがこれらを置き換えました。ただし下位の Anthropic ライブラリは今も ANTHROPIC_FOUNDRY_* の 3 つを探すため、ChatWalaʻau は起動時にこれらを自身のプロセスから取り除き（カタログがその名前を参照している場合を除く）、それぞれについて警告を出します。.env から削除してください。

Anthropic はすべてのリクエストで、出力の上限として max_tokens を必須とします。その下限は App Settings の Anthropic max tokens 設定です。

Anthropic SDK 1.x（v0.192.0）

v0.192.0 から Claude は Anthropic Python SDK 1.x（httpx2 ベース）で動作します。 ChatWalaʻau が Claude に送る内容（思考、推論努力度、プロンプトキャッシュ）は変わりません。変わるのは 2 点です。OpenAI 互換 API 経由で送った temperature / top_p は Claude では無視されます。また、Claude のエンドポイントの TLS 証明書は OS の証明書ストアで検証されます（特定の CA バンドルを使うには SSL_CERT_FILE または SSL_CERT_DIR を設定します）。

v0.210.0（Microsoft Agent Framework 1.24）から、長いサーバー側の検索の途中で Claude のターンが一時停止しても、回答が届くまで自動で続行します（モデル呼び出し 1 回につき最大 10 回）。続行のたびに課金対象のリクエストが発生し、ターンのトークン使用量にはそのすべてが含まれます。

Claude では、ホスト型の Web 検索（web_search_20250305）がそのまま使えます。それ以外のエージェント機能も、モデルがツール呼び出しに対応していれば、どちらのプロバイダでも動作します。音声認識、音声合成、画像生成、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 プロジェクトにデプロイした推論モデルを、他のプロバイダと並べて有効化できます。同じセレクタに表示され、ターン単位で選べます。Model Offering Catalog に foundry の offering を追加します。endpoint はプロジェクトのエンドポイントです。

{
  "id": "gpt-5.1-foundry",
  "provider": "foundry",
  "model_ref": "gpt-5.1",
  "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 上の Claude

このプロバイダ（"provider": "foundry"）は、Foundry のプロジェクト endpoint からモデルをネイティブに提供します。Anthropic プロバイダの Foundry ホスティング （"provider": "anthropic"、"hosting": "foundry"）とは別物で、そちらは Anthropic のルートで Claude を提供し、endpoint ではなく base_url を使います。

モデル ID は全プロバイダ間で一意である必要があり（AZURE_OPENAI_MODELS・ ANTHROPIC_MODELS・OPENAI_MODELS・FOUNDRY_MODELS）、衝突は起動時に拒否されます。モデルセレクタは Azure を先頭、次に Anthropic、次に OpenAI、次に Foundry を並べ、既定モデルは Azure が設定されていればその先頭モデルです。

生成オプション（エージェント側で設定）

モデルの思考の深さは、メッセージごとの設定ではなくエージェントの設定です。各 Run-Target が自分のモデルと推論努力度を固定し、エージェント構築時に一度だけプロバイダへ渡されます。

Run-Target	モデルと努力度の設定場所
組み込み ChatWalaʻau Core エージェント	Declarative Agents & Workflows の Core カード（モデル・推論努力度・構造化出力）。スマートフォンでは入力欄上部のエージェントボタン（モデル＋努力度）。
カスタム Prompt エージェント	エージェント詳細画面、または YAML の `model.id` / `model.options.effort`
Harness エージェント	Harness 詳細画面、または YAML の `model.id` / `model.options.effort`
Workflow のエージェントノード	そのノードが参照する Prompt エージェント

選択可能な努力度と既定値はバックエンドが提供します（GET /api/model の model_options カタログ）。したがって各画面は選択中のモデルが広告したものだけを描画し、生成オプションを受け付けないモデルではコントロールが表示されません。環境変数はありません。組み込みエージェントの選択はアプリケーション設定に保存され、再起動なしで適用されます。

組み込みエージェントの選択はサーバ全体に及びます

組み込みエージェントは、チャット・Microsoft Teams・CLI・OpenAI 互換 API・バックグラウンド処理（チャットタイトル、ユーザー／エージェントメモリ、議事録、Ontology）すべてに応答します。モデルや努力度を変更すると、それらすべてが同時に変わります。変更を行う画面は、適用前にその旨を表示します。

既定の努力度は xhigh なので、短いバックグラウンド処理 -- 特にチャットタイトル -- も何もしなければ高い努力度で生成されます。気になる場合は、努力度 medium の Prompt エージェントを選択するか、組み込みエージェントを medium にして、コストに見合うエージェントだけ引き上げてください。

推論努力度

モデルの思考の深さを設定します。全推論プロバイダで共通の1本のラダーです。

プロバイダ	レベル	既定	仕組み
Azure OpenAI（gpt-6 / gpt-5.x）	`low`, `medium`, `high`, `xhigh`, `max`	`xhigh`	`reasoning.effort`
OpenAI（direct、gpt-5.x / o系）	`low`, `medium`, `high`, `xhigh`, `max`	`xhigh`	`reasoning.effort`
Microsoft Foundry（gpt-5.x / o系デプロイ）	`low`, `medium`, `high`, `xhigh`, `max`	`xhigh`	`reasoning.effort`
Anthropic（Claude）	`low`, `medium`, `high`, `xhigh`, `max`	`xhigh`	adaptive thinking + `output_config.effort`

カタログの family が bare のモデルは推論オプションを受け付けないため、コントロールは表示されません。

努力度から自動的に決まるもの

選択するのは努力度だけです。他はすべて努力度から導出され、両推論ファミリーで同一です。

努力度から導出	`low`	`medium`	`high`	`xhigh`	`max`
冗長度（OpenAI 系 `text.verbosity`）	low	medium	high	high	high
最大出力トークン（思考と回答の合計）	16000	32000	48000	64000	96000

固定値（選択不可）: OpenAI の reasoning summary（detailed）、Anthropic の thinking モードと表示（adaptive / summarized、budget_tokens は送信しません）。

把握しておくとよい2点:

冗長度は独立に選べません。 「よく考えて簡潔に答える」は表現できないため、必要な場合はプロンプトで簡潔さを指示してください。
low では出力が 16000 トークンで打ち切られます。 非常に長い単一回答はここで止まる可能性があるため、長文生成では努力度を上げてください。

temperature / top_p が無い理由

サポートする2モデルファミリーはいずれも推論／adaptive-thinking モデルです。Claude は temperature・top_p・top_k を HTTP 400 で拒否し、OpenAI の推論モデルも受け付けません。したがってオプションカタログはサンプリング系パラメータを提供しません。ただし仕組みは汎用で、将来非推論モデルが追加されれば temperature / top_p を広告でき、対応するコントロールが自動的に表示されます。

プロンプトキャッシュ（入力トークンコスト）

すべてのモデル呼び出しは、大きく安定したプレフィックス -- システムプロンプトと全ツールスキーマ -- を毎回送り直します。長いターン（特に 1 メッセージが多数の逐次モデル呼び出しに展開されるコーディングのツールループ）では、このプレフィックスが何度も課金されます。プロンプトキャッシュは安定プレフィックスをキャッシュ可能としてマークし、1 度だけ課金して以降の呼び出しでは安価に再読込します。出力透過であり、モデルの応答は同一で、課金とレイテンシだけが変わります。

既定で有効、かつプロバイダ非依存です:

Anthropic（Claude）: バックエンドがシステムブロック（ツール定義も併せてカバー）と直近の会話メッセージ数件に cache_control ブレークポイントを注入します。これによりエージェント／コーディングのツールループで、会話タール（ツール結果・ファイル内容・思考）が毎モデルコールでフル価格再課金される代わりに、大幅割引で再読込されます。
Azure OpenAI: 約 1024 トークン以上のプレフィックスでプロンプトキャッシュが自動適用されます。設定は不要です。

非常に長いツールループでは、sliding-window の履歴コンパクションが会話プレフィックスをずらし会話キャッシュの命中率を下げます。キャッシュを優先する場合は App Settings -> Chat & session のコンパクション保持グループ数を上げる（安定窓を広げる）か、 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 が含まれ、節約を直接確認できます。

ターン全体での節約 -- 1 リクエストが多数のモデル呼び出しに展開されるコーディングターンではこちらが重要です -- を見るには、アシスタントメッセージ下部の in / out の数値をクリックしてください。詳細画面には、そのターンの累計キャッシュ読み出し／書き込みが、全額課金された入力と並べて表示されるため、その比率がキャッシュの効果そのものになります。

ヒント

Claude でクレジット消費がまだ多いと感じる場合は、メッセージ単位の推論努力度 （上記のセレクタ）も下げてください。Anthropic の既定は xhigh で、毎ステップの思考に多くの出力トークンを使います。多くのコーディング編集には medium や low で十分です。

構造化出力（JSON）

アシスタントの回答を散文ではなく JSON（任意で特定の JSON Schema）に拘束し、機械可読にできます。全ベースプロバイダ（Azure OpenAI / Anthropic / OpenAI）で動作し、エージェントが要求しない限りオフです。オフのときはリクエストは従来どおり変わりません。

設定場所。 メッセージ単位ではなくエージェント側です（v0.165.0 以降）。 Declarative Agents & Workflows の組み込み ChatWalaʻau Core カード、またはカスタム Prompt エージェントの YAML の outputSchema で設定します。オンのあいだは回答が JSON で返り、コピー可能なコードブロックとして表示されます。2モード:

汎用 JSON ― トグルをオンにするだけ。整形済みの JSON オブジェクトが返ります。
明示スキーマ ― 小さなエディタ（+schema / edit ボタン）を開いて JSON Schema を貼り付けます。回答はスキーマに拘束されます。空または不正なスキーマは汎用 JSON に縮退します。

オファリングが Structured output を Not available と宣言しているモデルではコントロールが非表示になり、Core カードがそのモデルの withhold 対象として structured output を名指しします -- コントロールの不在が「このビルドに無い機能」と読まれないようにするためです。既にスキーマを設定済みの run-target は、そのモデル上では素の文章で応答します。構造化された回答として偽装されることはありません。

Structured output が ON のあいだ Web search は剥落します

プロバイダが両者を含むリクエストを拒否するため、ChatWalaʻau は JSON を要求するターンでホスト型 Web search を外します。Core カード、Custom agent エディタ、Prompt Dump のいずれもその旨を表示します。 Structured output と Web search は同じターンに同居できませんを参照してください。

「スキーマなし」の意味はモデルによって異なります

スキーマを書かずにトグルをオンにすると既定スキーマにフォールバックします。この既定はプロバイダごとの性質です。

プロバイダ	スキーマ未指定時の既定
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...」 という短い通知を表示し、停止ではなく進行中であることが分かるようにします。
黙った重複は起こさない。回答のストリーミングが始まった後にエラーが起きた場合は再送しません（重複出力の恐れがあるため）。「一時的なサーバエラー ― 再送してください」という明確なメッセージが出るので、もう一度送るか、会話が非常に長い場合は新しいチャットを開始してください。

回答途中で切れた接続も再送対象です（v0.143.1）。 プロバイダがリクエストを受理し、ストリーミングを開始した後で、回答が完了する前に接続が閉じられた場合、それはネットワークの中断であって会話の問題ではありません。一時的なサーバエラーと同じ規則に従います — まだ何も表示されていなければ自動的に再送し、回答の一部が既に画面に出ていれば明確に報告します。完了しなかった回答に対する課金は発生せず、ツールが二重に実行されることもありません。v0.143.1 より前は、これが内部エラーとして報告されていました。

再送しても解決しないエラーは区別して報告され、再送対象外です:

状況	表示	対処
クレジット/クォータ切れ	プロバイダ名を含む課金メッセージ	クレジット追加/クォータ引き上げ、または別の設定済みモデルに切替
レート制限（429）	レート制限メッセージ	少し待って再試行、推論努力度を下げる、またはデプロイのクォータを引き上げ
出力後の一時的 5xx	「一時的なサーバエラー ― 再送してください」	再送。会話が非常に長い場合は新しいチャットを開始
回答途中の接続切断（v0.143.1）	「モデルプロバイダへの接続が回答の途中で切断されました」	再送。毎回ほぼ同じ地点で起きる場合は、プロバイダまでの経路にアイドルタイムアウトが無いか運用者に確認を依頼

マルチモデル切替​

モデルオファリングカタログ​

デプロイが機能を提供できない場合​

Foundry 上の Claude: ホスティングオプションを正しく選ぶ​

制限のあるデプロイのまま使う場合​

Structured output と Web search は同じターンに同居できません​

Function calling を無効化できない理由​

モデルの表示順​

offering の作成（CLI と GUI）​

タスク別モデルの割り当て​

Anthropic（Claude）プロバイダ​

OpenAI（direct）プロバイダ​

Microsoft Foundry プロバイダ​

生成オプション（エージェント側で設定）​

推論努力度​

努力度から自動的に決まるもの​

プロンプトキャッシュ（入力トークンコスト）​

構造化出力（JSON）​

「スキーマなし」の意味はモデルによって異なります​

信頼性: 一時的なプロバイダエラー​