メインコンテンツまでスキップ
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": "${FOUNDRY_PROJECT_ENDPOINT}",
"family": "bare"
},
// 任意: embeddings / image / live 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 は任意。複数のチャットモデルがある場合、default: true (無ければ先頭)が既定として使われます。

ポイント:

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

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

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

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

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

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

非対応の機能を使うリクエストは設計上 400 で拒否されます。症状は次のとおりで、 毎ターン失敗します。

web search not supported in your workspace

対処は ChatWalaʻau 側の設定変更ではなく、デプロイの作り直しです。

  1. Foundry ポータル → モデルカタログ → 対象の Claude モデル → DeployCustom settings
  2. Model version settings を展開し、Hosted on Anthropic とラベルされたバージョンを選択
  3. デプロイ名を控え、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
}
}

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

設定「利用不可」にしたときの動作
Web search機能そのものを外します。 代替が存在しないためです。システムプロンプトの web search 案内も同時に外れるので、エージェントが「検索できる」と主張することはなく、出典を捏造することもありません。
Structured outputこのモデルで機能を OFF にします。 出力スキーマを設定済みの run-target は、このモデル上では素の文章で応答し、Built-in agent のカードがその旨を表示します。縮退経路はありません -- かつて本プロジェクトが実装していた forced-tool-use フォールバックは Agent Framework と互換性がなく、v0.125.0 で削除されました。
MCPこのモデルから MCP ツールをすべて外します(stdio と streamable-HTTP の両方)。MCP 案内も同時に外れます。MCP サーバ自体は動作し続け、他のモデルはツールを保持します。変わるのは このモデル に提示される内容だけです。
Skillsこのモデルから Agent Skills を外します。スキルは一切提示されず、load_skill / read_skill_resource / run_skill_script も存在しません。Skills 管理画面とディスク上のスキルは無変更です。
Image generationこの chat モデルから image_generate / image_edit を外します。image オファリング自体と他の chat モデルには影響しません。
Function calling常時利用可能として表示され、無効化できません(下記参照)。

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

これは 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]: 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_urlhttps://<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_HOSTINGANTHROPIC_MODELSANTHROPIC_FOUNDRY_RESOURCEANTHROPIC_FOUNDRY_BASE_URLANTHROPIC_FOUNDRY_API_KEY はもう読まれません。 カタログがこれらを置き換えました。ただし下位の Anthropic ライブラリは今も ANTHROPIC_FOUNDRY_* の 3 つを探すため、ChatWalaʻau は起動時にこれらを自身のプロセス から取り除き(カタログがその名前を参照している場合を除く)、それぞれについて警告を 出します。.env から削除してください。

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

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 プロジェクトにデプロイした推論モデルを、他のプロバイダと並べて 有効化できます。同じセレクタに表示され、ターン単位で選べます。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_MODEcli = 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_MODELSANTHROPIC_MODELSOPENAI_MODELSFOUNDRY_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/modelmodel_options カタログ)。したがって各画面は選択中のモデルが広告したものだけを 描画し、生成オプションを受け付けないモデルではコントロールが表示されません。環境変数は ありません。組み込みエージェントの選択はアプリケーション設定に保存され、再起動なしで 適用されます。

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

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

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

推論努力度

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

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

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

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

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

努力度から導出lowmediumhighxhighmax
冗長度(OpenAI 系 text.verbositylowmediumhighhighhigh
最大出力トークン(思考回答の合計)1600032000480006400096000

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

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

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

サポートする2モデルファミリーはいずれも推論/adaptive-thinking モデルです。Claude は temperaturetop_ptop_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 で、毎ステップの思考に 多くの出力トークンを使います。多くのコーディング編集には mediumlow で十分です。

構造化出力(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 outputNot 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)「モデルプロバイダへの接続が回答の途中で切断されました」再送。毎回ほぼ同じ地点で起きる場合は、プロバイダまでの経路にアイドルタイムアウトが無いか運用者に確認を依頼