Open WebUIを開く前に、朝のテスト報告を用意する

月曜の朝8時30分、開発者が夜間テストの結果を開く。赤いジョブが三つある。一つはテスト用データベースとの接続が切れ、一つは不安定なタイムアウト、もう一つは金曜に変えたコードでアサーションが失敗した。赤い表示を見るより、その理由を仕分けるほうが時間がかかる。定期実行するコーディングエージェントなら、失敗したアサーションとログの抜粋を冒頭に置いた短い報告を、チャットに用意しておける。

AIモデルやツールを使うセルフホスト可能なチャット画面のOpen WebUIは、v0.13.3で定期実行にコーディングエージェントを使えるようにした。GitHub上のリリース時刻は2026年11月8日23:48 UTCだ。自動化に端末、作業ディレクトリ、その端末で使えるエージェントを保存して、チャットへ結果を届けられる。特定の環境で処理を開始できるようになったことが、朝の報告を現実的にする。Open WebUI v0.13.3リリースノート

最初に予約するなら、人が数分で確認できる報告がよい。自動化には証拠を集めてもらい、次の判断はプロジェクトの責任者に残す。毎回作れる報告が役に立ってから、次の権限を渡すべきか判断できる。

自動化がエージェントの作業場所を覚える

Open WebUIの自動化は以前からプロンプトの定期実行に対応している。通常の応答処理経路でチャットを開始するので、モデルの設定、ツール、フィルター、適用されるメモリー設定が結果に影響する。v0.13.3では、端末で見つかったコーディングエージェントを選べる。端末を選ぶと、モデル選択にエージェントとモデルの組み合わせが「エージェント/モデル」の形式で表示される。端末やフォルダーを変えると候補も変わり得る。Open WebUIは実行前に保存済みの端末とエージェントを確認する。どちらかがなくなっていれば失敗し、所有者は実行ログを調べられる。Open WebUI自動化文書

保存した実行設定でスケジューラーがチャットを開始する。Open WebUI v0.13.3リリースノートをもとにしたTelli.shオリジナル図解。

作業ディレクトリで、間違えると高くつく素朴な疑問に答えられる。似たファイル名のプロジェクトが二つあるときや、同じプロジェクトの機能ブランチとリリースブランチがディスク上にあるとき、どちらを読ませるか。パスを明記すれば意図した場所から始まり、レビュー担当者の確認先にもなる。ただし、これは開始場所だ。ほかに何を扱えるかは、読み書きの権限、アクセスできるファイル、環境変数、ネットワーク、エージェントの挙動で決まる。

結果の行き先も定まっている。コーディングエージェントの自動化はチャットに出力する。リリースノートでは、チャンネルを出力先にできる通常モデルの自動化と分けて説明している。個人の朝の確認なら、実行履歴とチャットで足りる。チーム向けの通知が欲しければ、何をどこへ共有し、誰が元ログを見られるかを別に決める。失敗したジョブをどこで調べるか知っている担当者も要る。Open WebUI v0.13.3リリースノート

最初のジョブには小さく、内容が分かる入力を渡す

月曜のテスト報告なら、直近の夜間テストの要約、機械が出したコミットID、少数の失敗ログを用意する。既存のCI成果物の出力処理や、使い捨てディレクトリへの手動コピーで、安定した入力が作れる。各ファイルには、失敗をジョブとコミットにひもづけられるだけの情報を入れる。明らかな秘密情報と無関係なログは事前に除く。慣例に沿った名前と確認可能な時刻があれば、最新ファイルを推測させずに済む。

一つのチャット回答に三つの出力を求める。注意が必要な失敗の短い一覧、環境要因または原因未確定の失敗の一覧、各項目の証拠へのリンクかパスだ。元のCI画面と照合できるよう、簡潔な形を指定する。同じテストがマトリックスで六回動いたという理由で同じ課題を六件登録するジョブは、小さな確認を大きなレビュー作業に変えてしまう。

役立つプロンプトは、出力に何を残すかを指定する。以下はコミットの記録とジョブ要約を用意した試験データの例だ。ディレクトリとファイルは例示である。

指定されたプロジェクトフォルダーから、書き出したテスト要約と関連する失敗の抜粋を読む。入力にある実行ID、コミット、時刻から始める。マトリックス内の重複した失敗をまとめる。異なる失敗ごとに、テスト名、最短で役立つ抜粋、元のパスを示す。明確な失敗と考えられる原因を分ける。要約が存在しない、古い、または不完全なら、何が足りないか示して終了する。ファイルは変更しない。

こうした指示で曖昧さは減るが、端末の権限も依頼に合わせる。ファイルを読むだけなら、読み取り専用にするか、リポジトリの認証情報を持たないコピーを使う。失敗したテストは、ソース、外部依存、試験用ファイルに由来する任意の文字を出力することがある。文字は証拠として扱い、新しい指示として実行しない。持ち主が起きる前にジョブが動くなら、特に重要になる。

もう一つの定期作業にも応用できる。技術責任者は日付付きの依存関係一覧と、別に取得した脆弱性情報を渡し、該当しそうなバージョンと根拠の記録を引用するよう頼める。役立つ出力は、正確なパッケージ名、版、出典がある確認リストだ。信頼できるスキャナーに決定的な照合を任せ、人がその依存関係を実行経路で利用するか判断できる。ファイルを固定すれば、実行ごとに説明が変わっても検証し直しやすい。

短いセットアップで実際の作業が見えてくる

Open WebUIの文書には、自動化全体の設定と非管理者用の個別権限がある。v0.13.3または互換性のある後継版を使い、機能が有効で、アカウントに権限があるか確かめる。端末は接続され、自動化のコンテキストで許可されていなければならない。モデルエディターに見える端末でも、コンテキスト設定により定期ジョブからは使えないことがある。通常チャットで動き、定期実行で失敗する理由になり得る。Open WebUI Automations · Open Terminal接続文書

1. 試験データを用意する。 成功した実行、代表的な失敗、コミットと時刻のマニフェストを一時作業場所に置く。入力は小さくし、本番の鍵、クラウド設定、個人ファイルは外に置く。
2. Automationsを開いてジョブを作る。 タイトル、プロンプト、モデル、スケジュールを設定する。エディターで端末を選び、作業ディレクトリを明記し、モデル選択から対象エージェントを指定する。そのフォルダーで使えるエージェントが表示されるまで待つ。
3. エディターから一回実行する。 生成されたチャットと実行ログを開く。コミット、元ファイル、重複排除、ファイル権限を確認する。元の成果物と照合し、作業ツリーに変更がないか見る。
4. 異常例を試す。 別の試験データからマニフェストを除くか、意図的に古い入力を指定する。報告には不足する証拠が見えるようにする。自動化で使えない端末の場合、実行履歴に失敗が出るか確かめる。
5. 定期実行時刻を設定し、最初の数件を読む。 CIの書き出し完了時刻と実行予定を比べる。早く開始して前日の結果を読んだなら、文章が最新らしくてもスケジュールの問題だ。入力の約束が変わったり、報告がずれたりしたら停止する。

試験データと報告用プロンプトは対にして扱う。フォルダー名、ブランチの付け方、テストの所属を変えたら、試験データも更新する。結果をまとめるための証拠が静かに失われるのを防げる。プロンプトを変えるときは以前の例を残し、同じ入力で二つの出力を比較する。複数の定期ジョブが同じ最新実行を特定する必要があるなら、入力のマニフェストを直すのが最も安価なこともある。

端末の選択には権限の境界が伴う

セルフホストのチャットでも、外部のモデルやエージェントにつながる。選んだエージェントのプロバイダー、送るデータ、使えるサービス認証情報を確認する。コンテナや使い捨て作業場所にチェックアウトを置けば、処理を制限する場所になる。同じ利用者がホスト全体を読めたり、エージェントにリポジトリの書き込み認証情報があったりするなら、開始ディレクトリだけの効果は小さい。Open WebUIの端末文書では、自動化を含む利用先を別々に指定できる。管理者は実行前に公開範囲を絞れる。Open WebUI端末接続文書

読み取り専用の報告では、証拠、実行権限、レビューの判断を切り分けられる。Telli.shオリジナル図解。

節約できるのは、結果を開いてから確認先が分かるまでの時間だ。多くは信頼できるコマンドでも処理できる。コマンドに実行IDと状態を出させ、エージェントに異なる出力形式をまたいで失敗を説明させる。うまくいかないときは、報告のIDとマニフェストを比較すれば、別のエージェントを試す前に入力の誤りを調べられる。

費用も同じ確認に含める。選んだエージェントが有料モデルを呼べば、定期実行も利用量を消費する。長いログは入力を増やし、繰り返す失敗は繰り返す分析になる。まず短い頻度で動かし、長さを絞ったログからどれだけ有用な確認が得られるか測る。毎回同じ大きなファイルを処理するなら、安価で決定的な処理に変更の有無を記録させる。毎日の実行も、入力上限が分かれば予算を立てやすい。

小規模チームでは所有者も端末と同じくらい重要だ。Open WebUIの文書によると、自動化は作成者に属し、その人にだけ見える。個人の報告には使える。複数人で使うリリース承認には、証拠を共有し、担当者不在時に責任を引き継ぐ別の手順が要る。自動化履歴は個人の調査を助け、共有のCI検査は出荷するチームからビルド判断が見えるようにする。Open WebUI自動化のアクセス制御

朝の報告の価値は、レビューで分かる

最初の一週間が終わったら、人が実際に開いた報告を見る。緊急とされた各項目のリンクや抜粋を確認し、失敗の見逃し、既知の問題の重複、コミットの間違いを数える。次に見るテストを見つける役に立ったか、確認者に聞く。自動回答の件数より、スケジュールの価値が分かる。

出力が引き続き役立つなら、一ファイルずつ新しい証拠を加えられる。端末の接続先を安定させ、認証情報を絞り、コードやインフラの変更は通常のレビューに通す。信頼して次の行動を取れ、疑わしいときにすぐ確認できる朝の報告が、進歩の目安になる。

出典

• Open WebUI v0.13.3リリースノート
• Open WebUI自動化の設定、権限、実行履歴
• Open WebUIの端末接続とコンテキスト

---

作業の背景にある会話と判断を検索できる記録に残すなら、Telli.shのアカウントを作成できます。