CLI中心だったTK Agentを確認しやすくするため、Python標準ライブラリのHTTPサーバーで動くlocalhost専用GUIを追加した。ブラウザから会話を実行でき、生成済みの記事・SNS下書きを一覧で確認できる。

Browser
  ↓ http://127.0.0.1:<available-port>/
GUI
  ↓
Manager / Router / 専門Agent / Memory

既存の確認処理は確認ハンドラへ集約し、GUIではブラウザの確認ダイアログにつなぐ。Webサイト反映で承認なしに処理が進まない設計は維持した。

下書き本体とレビュー状態を分ける

Markdownの下書きと品質管理用の状態情報を分離した。状態情報には、種別、状態、生成元Context、関連する記事、更新日時を保存する。同じ依頼と同じContextからの再生成はsource keyで検出し、既存の下書きを再利用する。

GUIでは記事を「採用」「要修正」「見送り」にできる。SNS下書きでは一括採用ではなく、案1から案3のうち採用する案を選ぶ。候補見出しの表記揺れにも対応し、選択結果は状態情報へ残す。

画像と投稿前の確認

下書き中の画像参照を抽出し、許可したassets配下のPNG、JPEG、SVG、WebPだけをlocalhostでプレビューする。assets外のパスは拒否し、任意ファイルを読めないようにした。

複数の画像がある場合は、単独投稿用の1枚もカルーセル用の複数枚も選択できる。採用した本文、ハッシュタグ、文字数、選択画像は投稿前プレビューでまとめて確認できるが、この画面から外部SNSへ送信はしない。

投稿パッケージには本文、採用案、画像、関連記事、文字数、作成日時、状態を保存し、同一内容は重複として再利用する。手動投稿画面は本文コピーや選択画像の確認を補助し、人間が投稿した後に手動投稿済みという記録だけを残す。

運用上の工夫と検証

既定ポートが他プロセスに使われていたため、GUIはlocalhostの空きポートを順に探して起動するfallbackを備えた。GUIのAPIではパストラバーサルを拒否し、JavaScript構文、状態API、候補選択、投稿パッケージ保存、重複検出を確認した。

AIによる生成、レビュー、人間による投稿を別の段階として扱うことで、便利さを保ちながら公開操作を見えにくくしない構成にした。