2026年9月4日 金曜日
AI時短ラボ
検証· 約14

Open WebUIの「ツール実行、毎回聞いてから」設定──会話単位で自由実行と承認制を切り替えられる仕組み

セルフホスト型AIチャットUI「Open WebUI」はv0.11.1(2026年8月25日)で、管理者が有効化すると会話ごとにツール実行を承認制に切り替えられるHuman in the loop機能を追加した。設定はボタンかキーボードショートカットで変更でき、選択はその会話と以降の会話の両方で記憶される。同じリリースには、モデルが最大3択の質問をユーザーに投げかけられる新機能も入っている。

Open WebUIの「ツール実行、毎回聞いてから」設定──会話単位で自由実行と承認制を切り替えられる仕組み
執筆・編集:
目次

セルフホストできるオープンソースのAIチャットUI「Open WebUI」は、v0.11.1(2026年8月25日公開)で、ツール実行のたびに人間の承認を挟めるHuman in the loop機能を追加した。会話ごとに「自由に実行させる」と「毎回確認する」を切り替えられる、という設計だ。

3行まとめ

  • Open WebUI v0.11.1(2026年8月25日)で、会話ごとにツール実行を承認制に切り替えられるHuman in the loop機能が追加された。実装コミットを確認すると、環境変数ENABLE_TOOL_PERMISSIONS(デフォルトFalse)で管理者が有効化する設計
  • 同時に追加された「モデルが質問できる」ask_userツールは、1回の呼び出しで1〜3問・各問2〜3択(label+description付き)まで、というサーバー側のバリデーションが実装コードで確認できた
  • 承認機能とask_user機能は、バックエンドでaction: 'approve' | 'reject' | 'answer'という共通の解決ハンドラを介しており、実装上は同じ「一時停止して応答を待つ」しくみの上に構築されている

会話単位で切り替えられる承認モード

公式リリースノートの説明は長文で、機能の挙動をかなり具体的に記述している。

"🚦 Human in the loop tool approval. Where an administrator has turned it on, you can switch a conversation from letting tools run freely to being asked first, so a model that wants to use a tool stops and waits for you to allow or deny it, one call at a time in a saved conversation, by button or by keyboard shortcut, with your choice remembered for this conversation and for future ones, switching back to running freely releasing anything already waiting, and automations, channel replies, and temporary chats unaffected."

(管理者が有効化している場合、会話を「ツールを自由に実行させる」から「先に確認を求める」に切り替えられる。これにより、ツールを使おうとしたモデルは停止し、ユーザーが許可または拒否するのを待つ——保存された会話の中で、1回の呼び出しごとに。切り替えはボタンでもキーボードショートカットでも行え、選んだ設定はその会話でも、以降の会話でも記憶される。「自由に実行」に戻すと、待機中だったものはすべて解放される。自動化・チャンネルへの返信・一時的なチャットはこの機能の対象外だ)

ポイントは、この設定が「アプリ全体で一律」ではなく「会話ごとに」切り替えられる点だ。ある会話では信頼して自由に実行させ、別の会話(例えば、外部システムに書き込むようなツールを使う場面)では承認制にする、という使い分けができる。設定を変更すると、それ以降の会話でもその選択が引き継がれる、という記憶の仕組みも備えている。

対象外になる3つのケース

引用の最後に明記されている通り、この承認制は「automations(自動化)」「channel replies(チャンネルへの返信)」「temporary chats(一時的なチャット)」には適用されない。人間が能動的に見ている通常の会話にのみ介入できる仕組みであり、バックグラウンドで動く自動化フローや、一時的で保存されない会話には、そもそも「承認を待つ」という概念自体が馴染まない、という判断だと考えられる。

待機中の返信を止める機能も同時に追加

同じv0.11.1のリリースノートには、この承認機能と組み合わせて使うとみられる、関連する修正も入っている。

"⏹️ Stopping a reply that is waiting. The stop button now ends a reply that is sitting waiting for you, such as one paused on a tool approval, rather than leaving the conversation stuck part way through."

(待機中の返信を止める。停止ボタンは、ツール承認待ちで一時停止しているものなど、ユーザーの入力を待って止まっている返信を終了できるようになった。これまでは、会話が途中で止まったままになっていた)

つまり、Human in the loop機能自体は同じリリースで初登場だが、「承認待ちのまま止まった会話を、停止ボタンで強制的に終わらせる」という運用上の抜け道も、同時に用意されていることが分かる。承認を求められたものの、結局どちらも選ばずに会話を終わらせたい、という場面をカバーする修正だ。

同じリリースに入った「モデルが質問できる」機能

さらに興味深いのは、同じv0.11.1に、モデル側からユーザーに質問を投げかけられる別の新機能も同時に追加されている点だ。

"🙋‍♂️ Models that can ask you a question. A new built-in tool lets a model pause and put up to three multiple-choice questions to you before continuing, with room to type your own answer instead, and the question survives a reload in a saved conversation, so you can come back and answer it later rather than losing the conversation."

(モデルが質問できるようになった。新しい組み込みツールにより、モデルは処理を続ける前に、最大3つの選択式の質問をユーザーに投げかけて一時停止できる。自分で回答を入力する余地も残されている。質問は、保存された会話の中でページを再読み込みしても消えず、後で戻って回答することもできる)

これは、本サイトの別記事で扱ったZedのask_userツール(同じ週に追加されたが、サブエージェント使用時の混乱を理由にデフォルト無効化された)と、機能としてはよく似ている。Open WebUI側では「最大3択」という具体的な上限が明記されており、質問がページのリロードをまたいで保持される(会話を失わない)という永続化の仕組みまで実装されている点は、Zedの実装よりも踏み込んだ設計に見える。

実装コミットを読むと分かること——有効化スイッチとツール質問の制約

リリースノートの文章だけでは分からない設計の詳細を、実装コミット(7d99b271ほか)の差分から確認できた。

項目 実装コード上の値
有効化スイッチ 環境変数ENABLE_TOOL_PERMISSIONS(デフォルトFalse。管理者がオンにしない限り機能自体が存在しない)
管理設定のキー chat.tool_permissions.enable(コード上、Context Compaction設定のすぐ隣に追加されている)
管理画面上の配置 差分に含まれるフロントエンドのファイルはadmin/Settings/Interface.svelteで、管理画面の「Interface」設定内に追加されている
バックエンドの新規モジュール backend/open_webui/utils/tool_approval.py(172行、新規追加)
承認・拒否・質問応答の処理 resolve_tool_call_outputという1つの関数がactionの値(approverejectanswerのいずれか)に応じて3種類を共通で処理する設計

この差分を見る限り、承認要否を「ツールごとに」個別設定できる項目は見当たらず、ENABLE_TOOL_PERMISSIONSという単一のスイッチと、会話ごとの自由実行/承認制の切り替えのみで構成されている。記事執筆時点で確認できたのはこの初出コミット1本の差分のみで、以降のコミット(同リリースノートにはこの機能に関連するコミットが計10件リンクされている)で設定粒度が追加されている可能性は排除できない。

ask_userツールの実装(backend/open_webui/tools/builtin.pyに追加された関数)を読むと、リリースノートの「最大3択の質問」という説明はより具体的な制約として実装されていた。

項目 実装コード上の制約
1回の呼び出しで投げられる質問数 1〜3問(1 <= len(questions) <= 3
1問あたりの選択肢数 2〜3択(2 <= len(options) <= 3
選択肢の構成 各選択肢はlabel(最大80文字)とdescription(最大240文字)の2フィールド
質問文の文字数上限 500文字
自由回答の許可 allow_other引数(デフォルトTrue)で、選択肢以外の自由入力を許可するかどうかを質問ごとに制御可能
専用UIコンポーネント src/lib/components/chat/AskUserCard.svelteが新規追加されている

つまり「モデルが最大3択の質問を投げる」というリリースノートの説明は、正確には「1回の呼び出しで1〜3問、各問2〜3択」という制約であり、単純に「3択問題」を意味するわけではなかった。

Zedのask_user disable騒動と重ねて見る

筆者は普段、AIエージェントにツール実行を任せる際、「全部自動で進めてほしい場面」と「一つ一つ確認したい場面」の両方がある、と感じている。Open WebUIのこの機能が「会話ごとの切り替え」という粒度を選んだのは、ユーザー全体で一律に設定するより現実的な落としどころだと思う。一方で、Zedのask_userツールが「サブエージェント経由だと誰が聞いているか分かりにくい」という理由でデフォルト無効化された経緯(本サイトの別記事)を踏まえると、Open WebUIの「モデルが質問できる」機能も、複数のツール・複数のエージェントが絡む複雑な会話では、同種の混乱を招く可能性がある。この点についてOpen WebUI側でどう対処しているかは、今回のリリースノートの記述からは分からなかった。

セルフホストして実際に動かしての確認はしていない

この記事はGitHubの公式リリースノート本文と、そこにリンクされた実装コミットの差分(diff)をもとに書いている。管理画面の場所(Interface設定内)や設定キー名(ENABLE_TOOL_PERMISSIONS)、ask_userツールの入力バリデーション(1〜3問・各2〜3択)は、いずれもソースコードの記述から直接確認できた事実だ。一方で、この記事の執筆にあたってOpen WebUIを実際にセルフホストして動かし、管理画面のスクリーンショットや、承認待ちUI・AskUserCardの実際の見た目を確認したわけではない。確認したのは初出コミット1本の差分のみで、同リリースノートにはHuman in the loop機能に関連するコミットが計10件リンクされている——残り9件に、設定粒度や挙動を変える追加の変更が含まれている可能性は排除できない。Zedのask_userツールとの比較についても、両者を実際に並べて動かした体験の比較ではなく、公開されている文書・コードの記述をもとにした推測にとどまる。

関連記事

シェア: ポスト はてブ

出典・参照資料

AIニュースの解説を動画でも

YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。

コメント

まだコメントはありません。最初のコメントを書いてみませんか?

AIについて聞きたいことはありますか?

質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。

質問箱を見る →

新しい記事をメールで受け取る

AIの新しい発表を、出典付きで整理して届けます。

関連記事