Open WebUIのDefaultモード、Nativeモードのツールの利用の違い　何を使ってくれるか？

by
Open WebUIは、LLMチャット以外の機能でも様々な機能があるが、「使ってくれる」かどうかは難しい。というか、基本的には、モデルのその場の気分次第という感じを受けることもある。たとえば、MCPを有効にしても使ってくれるかどうかは気分次第のような。LLMのモデルって、気分があったのか？　ジャイアンツが負けた日の次の日は機嫌が悪いとか（昭和の例だな）というか、Open WebUIの使い方は「使ってくれるようにする戦い」をするのがOpen WebUIなのかもしれない。しかし、そんな状態だと、機能追加しても話題にならないということになる。
 
まず、第一歩がDefaultモードとNativeモード。違いをまとめてみた。
 
結果として、
 
Defaultモード：連携しない純粋なLLMチャット向き
コンテキストサイズが大きくならない。
気分？モデル次第で動く。動かせるの連携が少ない。使えたとしても連携な仕方が雑。
ちなみに、Skillに関しては、制限は聞くが、機能はつかない。（そもそも制限がかかっている中で機能はつかない。）
 
Nativeモード：サポートされている全ての連携機能が使える
コンテキストサイズが肥大しがち
 
ということだった。
 
つまり、KBだとか、Skillだとか、Toolがといっていても、Defaultモードだとそもそも付かないか、動くかどうか運次第。
Defaultモードの連携で何が面倒かというと、動作確認は何度かやってうまくいって、動作させてOKとなるが、本番だと一切動く気配がないということが起きる。
Nativeモードにすれば、毎回ほぼ必ず動く。動かない、期待通りではないというときは、プロンプトかモデルがものすごく小さいかのいずれか。トラブルシューティングがものすごく楽。
 
 
切り分けの質問
 
Defaultモード
あまり細かく書くと類推して答えてしまう。
この会話で利用可能な mcp / tools / functions の機能をタイプごとに分けて全てを列挙して。
アクセスできるターミナルの名前を確認し、Terminal / shell / exec / run_command に相当するものがあるか確認して。
使えないものは、最後に利用できないものとして記載して。
 
Nativeモード
連携するのが当然として、細かく聞いてみた。
この会話で利用可能な mcp / tools / functions の名前と対応する関数をタイプごとに分けて全てを列挙して。
アクセスできるターミナルの名前を確認し、Terminal / shell / exec / run_command に相当するものがあるか確認して。
使えないものは、最後に利用できないものとして記載して。
 
以下がモデルの設定パラメーター
MCP
– Mcp.playwright
 
Capabilities
– Vision
– File Upload
– File Context
– Web Search
– Image Generation
– Code Interpreter
– Terminal
– Usage
– Citations
– Status Updates
– Builtin Tools
 
Default Features
– Web Search
– Image Generation
– Code Interpreter
 
Builtin Tools
– Time & Calculation
– Memory
– Chat History
– Notes
– Knowledge Base
– Channels
– Web Search
– Image Generation
– Code Interpreter
– Task Management
– Automations
– Calendar
 
Terminal
Open Terminal
 

Default Mode

動き
最初に、以下が有効になっていると以下を行なう。
Default Features
  • Web Search
  • Image Generation
  • Code Interpreter
そのあと推論が起きる。
ただし、ここの部分で得られる結果が推論に入るとは限らない。モデル次第。
また、連携で関数が出てこない。
 
Builtin Tools
  • Memory: 利用可能機能ではなく会話文脈情報
以下は、モデルの判断次第
  • Chat History
  • Code interpreter
  • Terminal
  • MCP
それ以外は使えない。
 
Default Features の Web Search
  → プロンプト投入後、推論前に自動実行されやすい
Builtin Tools の Web Search
  → モデルが必要と判断したときに使う道具
 
以下が使える機能の最大設定
 

Defaultモード切り分けの回答

利用可能な機能とターミナル状況について説明します。

🔍 テリーナ名確認結果

  • 現在の環境: Linux (x86_64) ホスト f10df24e8a96
  • シェル状態: /bin/bash が動作可能（Python 3.12.13も利用可）
 

✅ 利用可能な機能カテゴリー一覧

カテゴリ
ツール名/対応項目
使用可否
リスクレベル
ターミナル
run_command / shell実行
⚠️ 標準チャットでは不可（このモデルには制限あり）
–
ファイル操作
フイルス読み書き確認は不可
❌ 利用できない機能として記載します。
🔴
システム情報
OS/ホスト名取得のみ可能(文字列)
⚠️ 実効性は環境依存で制限あり。
–

🛑 現在使えない主な項目（重要）

以下のツールは、このチャットインターフェースでは利用できません：
  • システムコマンドの実行 (ターミナル経由など)
  • ファイルの直接アクセス・操作
  • ネットワークリソース呼び出し/外部API

📋 追加の確認事項

  • 「[2026-06-07] カレン（トヨタ車種）」や「赤色」「大学5年」などの個人情報について、これは利用可能機能ではなく会話文脈情報として受け取っています。安全配慮の観点から特定の利用制限は設けられておりませんが、データ保持などはシステムポリシーに従います。

⚠️ 最終的に記載：現在使えないもの

  • ターミナルコマンド実行（run_command相当機能） → ❌ 利用不可・標準チャットではサポート外です。
  • 画像生成ツール → エラーが発生しており、このセッション内での使用は現時点で制限されています。

💡 まとめ：現状の利用可能性について

  1. ターミナルコマンドを実行したい場合やファイル操作をしたい場合は、適切な環境（Pythonスクリプト実行や安全なAPI経由）を準備する必要があります。
  2. チャット自体のテキスト生成・情報収集については通常通り可能ですが、ツール連携には依存しない設計になっているためご注意ください。
 
何か他に確認したいことがあればお知らせください！
 

Native Mode

Builtin Toolsが関数レベルで使える
 
MCPはサンプルでMCP: Playwrightだけをオンにした。
 
 

Nativeモードの切り分けの回答

まず、利用可能なツールの一覧を整理し、ターミナルのアクセスを確認します。
確認しました。ターミナルは正常に動作しています（ホスト f10df24e8a96、ユーザー u3bfd6eb0）。
以下に利用可能な全てのツール・関数をカテゴリ別に列挙します。
 

🖥️ ブラウザ自動化（MCP: Playwright）

関数名
説明
tool_browser_navigate_post
URL にナビゲート
tool_browser_navigate_back_post
前のページに戻る
tool_browser_click_post
ページ上でクリック
tool_browser_type_post
テキスト入力
tool_browser_fill_form_post
複数フォームフィールドを一括入力
tool_browser_select_option_post
ドロップダウンからオプション選択
tool_browser_hover_post
エレメント上にホバー
tool_browser_drag_post
ドラッグ＆ドロップ
tool_browser_press_key_post
キーボードキーを押下
tool_browser_evaluate_post
JS 式をページ/エレメントで評価
tool_browser_run_code_unsafe_post
Playwright 用 JS コードを実行（Unsafe）
tool_browser_snapshot_post
アクセシビリティスナップショット取得
tool_browser_take_screenshot_post
スクリーンショット撮影
tool_browser_console_messages_post
コンソールメッセージ取得
tool_browser_network_requests_post
ネットワークリクエスト一覧取得
tool_browser_network_request_post
個別ネットワークリクエストの詳細取得
tool_browser_handle_dialog_post
ダイアログ処理（alert/confirm/prompt）
tool_browser_file_upload_post
ファイルアップロード
tool_browser_drop_post
ファイル/MIMEデータをエレメントにドロップ
tool_browser_resize_post
ブラウザウィンドウのリサイズ
tool_browser_close_post
ページを閉じる
tool_browser_tabs_post
タブの一覧・作成・閉じる・選択
tool_browser_wait_for_post
テキスト出現/消失または時間待機
 

📁 ファイルシステム

関数名
説明
list_files
ディレクトリ内のファイル・ディレクトリ一覧
read_file
ファイルの内容を読み込み（テキスト/画像対応）
display_file
ユーザーのファイルビューアで開く
write_file
ファイルにテキスト内容を書き込み
replace_file_content
ファイル内の文字列を置換
grep_search
ディレクトリ内でテキスト/正規表現検索
glob_search
グローブパターンでファイル検索
 

⚙️ ターミナル / プロセス（run_command 相当）✅

関数名
説明
run_command
シェルコマンドをバックグラウンドで実行
get_process_status
プロセスの出力・ステータス取得
send_process_input
プロセスの stdin にテキスト入力
kill_process
プロセスを強制終了
list_processes
全追跡プロセスの一覧
 
✅ 確認済み: run_command は正常動作しています。シェル実行環境として bash（Linux x86_64）が利用可能です。
 

⏱️ タイムスタンプ / 計算

関数名
説明
get_current_timestamp
現在時刻の Unix タイムスタンプ取得
calculate_timestamp
日付調整付きのタイムスタンプ算出
 

📚 ナレッジベース（Knowledge Base）

関数名
説明
kb_exec
ナレッジベースに対しファイルシステムコマンド実行
query_knowledge_files
セマンティック/ベクトル検索でKBファイルを検索
query_knowledge_bases
KBの名称・説明を意味的に検索
search_knowledge_bases
KBを名称・説明で文字列検索
kb_execは、シェルのrun commandと同じ。Terminalにアクセスできない場合は、kb_execが実行しようとする。

💬 チャット履歴（Chat History）

関数名
説明
search_chats
過去のチャット会話をタイトル/メッセージ内容で検索
view_chat
チャットの完全な会話履歴を取得
 

🧠 メモリ（Memory）

関数名
説明
search_memories
ストレージされたメモリを検索
add_memory
新しいメモリを保存
replace_memory_content
既存メモリの内容を更新
delete_memory
メモリを削除
list_memories
全メモリを一覧表示
 

🌐 Web検索（Web Search）

関数名
説明
search_web
パブリックウェブを検索
fetch_url
URL の主要なテキストコンテンツを取得・抽出
 

🖼️ 画像生成（Image Generation）

関数名
説明
generate_image
テキストプロンプトから画像を生成
edit_image
既存画像をプロンプトで編集
 

📝 ノート（Notes）

関数名
説明
search_notes
ノートをタイトル/内容で検索
view_note
ノートの完全な内容を取得
write_note
新しいノートを作成
replace_note_content
ノートの内容を更新
 

💬 チャネル（Channels）

関数名
説明
search_channels
チャンネルを名称・説明で検索
search_channel_messages
チャネル内のメッセージを検索
view_channel_thread
スレッド内の全メッセージを取得
view_channel_message
個別メッセージの詳細を取得
 

✅ タスク管理（Task Management）

関数名
説明
create_tasks
複数ステップのタスクリストを作成
update_task
タスクの状態を更新（完了・進行中など）
 

⏰ オートメーション（Automations）

関数名
説明
create_automation
定期的または1回限りのスケジュール付き自動化を作成
update_automation
既存の自動化を更新
list_automations
スケジュール済み自動化を一覧表示
toggle_automation
自動化を一時停止/再開
delete_automation
自動化を削除
 

📅 カレンダー（Calendar）

関数名
説明
search_calendar_events
カレンダーイベント/リマインダーを検索
create_calendar_event
イベント/リマインダー/アラームを作成
update_calendar_event
既存イベントを更新
delete_calendar_event
イベントを永久削除
 

❌ 利用できないもの（この環境では該当しない・未搭載）

カテゴリ
詳細
PPTX → PDF 変換
LibreOffice / soffice がインストールされていないため、PPTX を PDF に変換する機能は不可
外部 API 直接呼び出し
requests/urllib などの WebAPI 直接叩く関数はない（fetch_url で静的ページ取得のみ可能）
メール送受信
メールクライアント/SMTP 機能なし
データベース操作
SQL / Redis / MongoDB 等への直結ツールなし
GUI アプリ起動
X11/Wayland や GUI アプリケーションの起動は不可（ヘッドレス環境）
音声・動画処理
STT/TTS、動画エンコード/デコード用ツールなし
ファイル圧縮/展開
zip/tar はシェルコマンドで可能だが、専用関数はない
 

まとめ

  • 総カテゴリ数: 13 カテゴリ
  • 総関数数: 約 70 関数
  • ターミナル/シェル実行: ✅ run_command で確認済み（Bash on Linux x86_64）
  • ブラウザ自動化: ✅ Playwright Chromium が動作確認済み
  • ファイル生成系: Python-pptx, python-docx, openpyxl, pandas, numpy すべて利用可能
  • 未搭載機能: PPTX→PDF変換、メール、DB操作、音声/動画処理
 
 
 
今回の切り分けで分かったのは、Open WebUIでは「機能を有効にした」だけでは不十分ということだ。Defaultモードの場合は、使いたい機能があるからオンにするのではなく、モデルに余計な判断をさせないために、必要な機能だけをオンにするという発想が必要になる。Defaultモードでは、サポートされているわずかな機能のうちのWeb検索やCode Interpreterなどが有効でも、それらがNativeモードのように関数レベルでモデルへ公開されているわけではなさそうだ。モデルが必要と判断した場合だけ使われたり、あるいは推論前に自動実行された結果だけがコンテキストとして渡されたりする。一方、Nativeモードでは、MCP、Terminal、ファイル操作、Notes、Calendarなどが関数レベルでモデルに見えるため、Open WebUIの連携機能を本格的に使うならこちらが本命になる。ただしNativeモードは便利な反面、使える関数一覧や説明が大量にコンテキストへ入るため、モデル自体のコンテキストサイズを大きめにする必要があり、またプロンプトが重くなりやすいという欠点もある。
つまり、Open WebUIの使い分けは次のようになる。
  • Defaultモード：軽量なLLMチャット向き
  • Nativeモード：ツール連携を前提にしたAgent向き
Open WebUIは単なるチャット画面ではない。しかし、その機能をモデルに確実に使わせるには、モード選択、プロンプト設計、ツール定義、MCP構成を含めて「使ってくれるようにする戦い」が必要になる。そして、この「戦い」が顕著になってきている背景には、ユーザのプロンプト自体が変化していることもあるのではないかと思う。
 
数年前であれば、
「○○について教えて」
 
で終わっていた。
 
しかし最近は、
「調べて」 「実行して」 「修正して」 「カレンダーを確認して」 「GitHubへ反映して」 「ブラウザで操作して」
 
というように、AIに知識を求めるのではなく、実際の作業を依頼する場面が増えている。
 
すると、モデルの賢さだけでは足りなくなる。どのツールを使うか。 いつ使うか。 何回使うか。 結果をどう解釈するか。
 
 
 
で、終わったと思っていた。しかし、この話題には続きがあって、Open Terminalが気分でしか使われない問題が発生。Open Terminalは、Open WebUIからTerminalを触らせるもので、以下の用途がある。
例えば、
  • インフラエンジニアにとってはdockerやkubernetes,パブリッククラウドのCLIなどをLLMから操作できる。
  • 一般ユーザの場合、ユーザアプリの作成などを行える。
 
と考えられがちで使うのはレアケースと考えられがちだが、実は一般ユーザの視点では、ファイル生成などもOpen Terminalで行える。
 
何を意味するのか
 
Open Terminalが使えないということは、LLMチャットからパワーポイントの生成ができない！
 
ということが発生する。
 
パワーポイントをよく作る人には、実は、Open Terminalは必須になる。しかし、使ってくれるかどうかはわからない。使えない場合、Pythonコードが表示されて、自分でやってくれと。パワーポイントを使うメインのユーザにとっては、Pythonコードなんてエラーメッセージみたいなものである。さて、困った。
 
続きは次回。もちろんバチっと解決ができる。

コメントする