ロードマップ

Goal: Build an AI-powered Connector Hub — Standalone (portal assistant), Copilot (embedded in host system), Hub (central cross-system orchestration). Principles: Provider-agnostic (no vendor lock-in), minimal-abstraction, protocol-first, connector-first (integration is the core value).

製品ビジョン

FIM One は、3つの段階的なモードで機能する AI コネクタハブ です：

Standalone   → 独自の AI アシスタント (Portal)
Copilot      → ホストシステムに組み込まれた AI (iframe / widget / embed)
Hub          → 中央クロスシステムオーケストレーション (Portal / API)

Hub モードが主要な差別化要因です。 エンタープライズクライアントは、ERP、CRM、OA、財務、HR などのレガシーシステムを持っており、これらが AI を通じて相互に通信する必要があります： GTM パス：ランド・アンド・エクスパンド

ステップ	モード	実行内容
Land	Copilot	1つのシステムに組み込み、UI 内で価値を実証
Expand	Copilot → Hub	より多くのシステムにロールアウト；Hub がそれらを集約

既知の問題

本番環境で再現可能だが、まだ修正されていないトラッキング済みのバグ。各項目は症状、疑わしい影響範囲、および回避策（ある場合）を記載しています。修正がスコープ化され、スケジュール化されると、項目はバージョンセクションに移動します。

エージェントエディタが編集なしでも未保存変更警告を表示する。 /agents/[id] 経由で既存のエージェントを開き、すぐに戻るをクリックすると、フィールドに触れていないのに「未保存の変更」ダイアログがトリガーされます。ダーティチェックは 20 以上のフィールドをロードされたエージェントペイロードと比較するため、状態初期化とダーティ比較の間で非対称なデフォルトが 1 つあれば、ファントムミスマッチを引き起こすのに十分です。現在の疑いは、ネストされた model_config_json / notification / approval-routing フィールドの 1 つ、おそらく undefined vs null vs "" 正規化からです。特に org スコープのエージェントで再現します。回避策：ダイアログを閉じてください（「破棄して離脱」）— 実際には何も変更されていないため、データ損失はありません。試みられた修正（cb40c86a）はリソースピッカーの関連する孤立バッジのちらつきを削除しましたが、これは解決しませんでした。
エージェント編集の保存が Input should be 'initiator', 'agent_owner' or 'org_members' で失敗することがあります。 Pydantic は /api/agents/{id} PUT 境界で confirmation_approver_scope フィールドを拒否します。ただし、データベースに保存されているすべての値は 3 つの有効なリテラルの 1 つです。疑い：フロントエンドの as "initiator" | "agent_owner" | "org_members" キャストはコンパイル時のみの約束であるため、レガシーまたは予期しないランタイム文字列（テンプレート、インポート、または古いマイグレーションから生じた可能性がある）が setConfirmationApproverScope を通過し、そのまま返されることがあります。回避策：保存する前に、Approval → Approver Scope ドロップダウンで明示的に値を再選択してください。
Playground の停止と再試行は、ページ更新で常にクリアされる一時的なビジュアルアーティファクトを表示します。 3 つの同時レンダリングソース — activeConversation.messages（DB スナップショット）、SSE messages ストリーム、および楽観的な pendingQuery プレースホルダー — は単一の派生状態に折りたたまれていないため、「再試行」をクリックしてからペアの assistant レスポンスが到着するまでの間、UI は (a) プリストリームウィンドウで同じクエリを 2 回簡潔にレンダリングし、(b) hasLiveMessages が true で、スナップショットが再ロードされる前に、再試行履歴から以前の孤立したユーザーバブルをドロップし、(c) SSE「done」イベントと次の selectConversation 更新の間の狭いウィンドウでちらつきます。データは決して失われません — すべてのユーザーメッセージ（中止された再試行を含む）は conversation.messages に永続化され、normalize_alternating_messages 経由で次の LLM 呼び出しに持ち込まれ、48ba08c6 レンダリング修正で導入された HistoryTurn.orphanUserContents 経由で更新後に正しくレンダリングされます。文脈として、Claude 独自の web UI は類似のバグクラスを示しています — レスポンスの途中で停止し、すぐに後続クエリを送信すると、後続クエリが最初のクエリの兄弟編集ブランチとしてフォークされることがあり、新しいターンとして追加されるのではなく — これは楽観的 UI + SSE + 永続化履歴設計の既知の難しい問題であり、FIM One 固有の欠陥ではありません。適切な修正には、3 つのレンダリングソースを単一の派生状態に折りたたむことが必要です。より広い Playground ステートマシンリファクタリングまで延期されています。

出荷済みバージョン

v0.1 (2026-02-22) — MVP: ReAct + DAG Planner

ReActAgent with tools (calculator, python_exec, web_search)
DAG Planner (LLM generates dependency graphs)
Portal UI with streaming + KaTeX

v0.2 (2026-02-24) — マルチモデル + メモリ

リトライ / レート制限 / 使用状況追跡
ネイティブ関数呼び出し (JSON のみの解析なし)
マルチモデルサポート (高速 + メイン LLM)
メモリ: WindowMemory、SummaryMemory
FastAPI バックエンド SSE ストリーミング付き

v0.3 (2026-02-25) — Web Tools + MCP

Web tools (web_search, web_fetch) via Jina/Tavily/Brave
File operations tool
MCP client (standard tool integration)
Tool auto-discovery + categories
DAG visualization with click-to-scroll
Code exec in Docker (--network=none)

v0.4 (2026-02-25) — マルチターン + エージェント

マルチターン会話 (DbMemory)
ツールステップ折りたたみUI
HTTPリクエスト + シェル実行ツール
エージェント管理 (作成、設定、公開)
JWT認証
エージェント単位の実行モード + 温度制御

v0.5 (2026-02-28) — Full RAG + Grounded Gen

Full RAG パイプライン (embedding + vector store + FTS + RRF + reranker)
Grounded Generation (引用、信頼度スコア)
ナレッジベースドキュメント管理 (CRUD、検索、再試行、スキーマ移行)
ContextGuard + ピン留めメッセージ (トークン予算マネージャー)
DbMemory 永続化 + LLM Compact
DAG 再計画 (最大3ラウンド)

v0.6 (2026-03-01) — コネクタプラットフォーム

コネクタ CRUD: 作成、読み取り、更新、削除
ConnectorToolAdapter: コネクタ → BaseToolに変換
ユーザーごとの認証情報: AES-GCM暗号化
確認ゲート: 書き込み操作の承認
監査ログ: すべてのツール呼び出しを記録
サーキットブレーカー: 障害時の段階的な機能低下
ユーティリティツール: email_send、json_transform、template_render、text_utils
埋め込みオプション: Jina、OpenAI、カスタムプロバイダー

v0.7 (2026-03-06) — 管理プラットフォーム + マルチテナント

管理プラットフォーム: ユーザー管理、ロール切り替え、パスワードリセット、アカウント有効化/無効化
招待制登録: 3つのモード (オープン/招待/無効) + 招待コード CRUD
ストレージ管理: ユーザーごとのディスク使用量、クリア、孤立ファイルのクリーンアップ
会話モデレーション: 管理者による一覧表示/削除
ユーザーごとの強制ログアウト: すべてのトークンを無効化
API ヘルスダッシュボード: システム統計、コネクタメトリクス
初回セットアップウィザード: ガイド付き管理者アカウント作成
個人センター: ユーザーごとのグローバル指示、言語設定
JWT 認証: トークンベースの SSE 認証、会話の所有権
グローバル MCP サーバー: 管理者がプロビジョニング、すべてのセッションで読み込み
後方互換性: registration_enabled → registration_mode 自動マイグレーション

v0.7.x (2026-03-07 to 2026-03-12) — 安定性 + ポーランド

招待コード管理
ユーザーごとのクォータ (429 強制)
構造化監査ログ
機密ワードフィルタリング
管理者ログイン履歴
管理者ファイルブラウザ
強化された管理者ビュー (model_name、tools、kb_ids フィールド)
Docker Compose デプロイメント (単一イメージ、名前付きボリューム)
OAuth 自動検出 (window.location から)
拡張思考 / 推論サポート (LLM_REASONING_EFFORT、LLM_REASONING_BUDGET_TOKENS) OpenAI o シリーズ、Gemini 2.5+、Claude 向け
管理者ツール単位の有効/無効切り替え (無効なツールはチャット実行時に除外)
MCP サーバー管理をコネクタページに移動
デュアルデータベースサポート: SQLite (ゼロコンフィグデフォルト) + PostgreSQL (本番環境); Docker Compose は自動的に PostgreSQL をプロビジョニング
モデル設定ドキュメントページ (プロバイダーごとの拡張思考セットアップ)
SSE Protocol v2: リアルタイム回答ストリーミング (delta_reasoning、usage フィールド、および分割 done/suggestions/title/end イベント); SQLite プールサイズ 5 -> 20
AI Builder 拡張: 7 つの新しいビルダーツール (GetSettings、TestConnection、ImportOpenAPI (コネクタ向け); ListConnectors、AddConnector、RemoveConnector、SetModel (エージェント向け))、エージェント上の is_builder フラグ、ビルダープロンプト自動更新、SSRF ガード
SSE v2 フロントエンド: ストリーミングドットパルスカーソル、DAG 再計画ラウンドスナップショット (折りたたみ可能なカード)、DAG レイアウトをステップ状態から分離
AI Builder コンセプトドキュメントページ (コネクタおよびエージェントビルダーガイド)
組織システム: 完全な CRUD (ロールベースのメンバーシップ: オーナー/管理者/メンバー)、管理者管理 UI
3 段階のリソース可視性 (個人/組織/グローバル) エージェント、コネクタ、ナレッジベース、MCP サーバー向け
すべてのリソースタイプの公開/非公開 API; 公開エージェントのオーナー委譲
管理者設定可視性エンドポイント (クローン・トゥ・グローバルを置き換え); 統一された build_visibility_filter() クエリヘルパー
データベースコネクタ (フェーズ 1-3): PG/MySQL/Oracle/SQL Server + 中国レガシー DB への直接 SQL アクセス; スキーマ内省、AI アノテーション、読み取り専用クエリ実行、暗号化された認証情報、コネクタごと 3 つのツール (list_tables、describe_table、query)
評価センター: 定量的なエージェント品質ベンチマーク — テストデータセット CRUD (プロンプト + 期待される動作 + アサーション)、評価実行 (並列実行 + LLM グレーダー + ケースごとの合格/不合格/レイテンシ/トークン結果)、自動ポーリング付き結果ビューア; マイグレーション r8t0v2x4z567
3 つのモデルロール (General/Fast/Reasoning) (ティアごとの env コンフィグ分離); 高速モデルはメインモデル設定を継承しない
StepOutput データクラス (構造化データとアーティファクト渡し用の通常文字列ステップ結果を置き換え)
DAG 実行用ツールキャッシュ — 実行ごとの同一ツール呼び出しキャッシュ (非同期ロックスタンピード防止付き) (DAG_TOOL_CACHE)
ステップごとの LLM 検証 (失敗時 1 回の再試行) (DAG_STEP_VERIFICATION)
自動ルーティング: 高速 LLM がクエリを ReAct または DAG として分類; /api/auto エンドポイント; フロントエンド 3 方向モード切り替え (AUTO_ROUTING)
~~Shadow Market Organization + Resource Subscriptions~~: 組み込み Market org (shadow、自動参加なし) は Platform org を置き換え; マーケットプレイスブラウジングおよび明示的なサブスクリプション経由でリソースを発見 (プルモデル); Market API (共有リソースへのサブスクリプション); Market への公開は常にレビューが必要; リソースサブスクリプションテーブル; グローバル可視性を置き換える org ベースのリソース共有
~~Agent Auto-discovery and Sub-agent Binding~~: エージェント上の discoverable フラグ; sub_agent_ids ホワイトリスト; CallAgentTool (タスクを専門エージェントに委譲)
~~MCP Server Credentials + Per-User Override~~: mcp_server_credentials テーブル; PUT /api/mcp-servers/{id}/my-credentials エンドポイント; 認証情報フォールバック動作用の allow_fallback フラグ
~~Connector/KB Toggle~~: POST /api/connectors/{id}/toggle および POST /api/knowledge-bases/{id}/toggle (リソースの一時停止/再開)
~~Standalone KB Conversations~~: 会話上の kb_ids フィールド (エージェントバインディングなしの直接 KB チャット)

v0.8 (2026-03-20) — コネクタ宣言型設定 + 段階的情報開示

v0.8.1 (2026-03-29) — プログレッシブディスクロージャー成熟度 + ReAct強化

DBコネクタ（DatabaseMetaTool）、MCPサーバー（MCPServerMetaTool）、オンデマンドツール読み込み（request_toolsメタツール）のプログレッシブディスクロージャー
DAG品質全面改善（5つの改善：モデルアップグレード、スキル自動検出、引用検証者、構造化コンテンツ保持、ドメイン認識ルーティング）
ReActでのドメインモデルエスカレーション（専門ドメインが推論モデルに自動エスカレート）
モデルごとのネイティブ関数呼び出しトグル（tool_choice_enabled）
ReActサイクル検出（決定論的重複ツール呼び出し防止）
ReAct完了チェックリスト（ツール使用時の事前回答検証）
リソースフォークフェーズ1（系統追跡付きMCPサーバー + スキルフォークエンドポイント）
ワークフロー接続依存関係自動購読（再帰的サブワークフロー依存関係解決）
プリビルトソリューションテンプレート（初回登録時にマーケットに8つの業界別ソリューションをシード）
管理者通知改善（タイムゾーン対応、マスタースイッチ、SMTP Reply-To）
ターンごとのトークン予算サーキットブレーカー（REACT_MAX_TURN_TOKENS）
一元化されたツール切り詰め、動的システムプロンプト予算配分
ファイル添付ダウンロード、重複メッセージ送信修正

v0.8.2 (2026-04-10) — 智能体コア強化 + ビジョンドキュメント

智能体コアフェーズ 0 — コンパクト提示词を9セクション構造化フォーマットにアップグレード; 空のツール結果保護（(no output) の代わりに説明的なメッセージ）; アンチループ提示词 + サイクル検出閾値を2に低下; ドメイン分類器 + プリフライトDB設定解決を並列化（リクエストあたり400～1100 ms削減）; SSE end イベントを回答直後に送信、タイトル/提案をバックグラウンドタスクに移動
智能体コアフェーズ 1（コンテキストアンチブロート） — MicroCompact ルールベースの古いツール結果クリーンアップ（最後の6つを保持）; REACT_TOOL_RESULT_BUDGET=40000 集計上限; コンテキストオーバーフロー時のリアクティブコンパクト（予算の50%に自動コンパクトして再試行、クラッシュの代わりに）
智能体コアフェーズ 2（速度） — キーワードベースのツールプリセレクション（明らかなマッチでLLM呼び出しをスキップ、200～500 ms削減）; SharedHttpClient LLM接続プーリング; 200トークン以上の回答では完了チェックをスキップ; FallbackLLM はプライマリ+高速をラップし、429/503/529/接続エラーで自動フェイルオーバー
インテリジェントドキュメント処理（ビジョン対応） — 適応的なドキュメント処理: PDFページはビジョン対応モデル（GPT-4o、Claude 3/4、Gemini）向けにPyMuPDFで画像としてレンダリング、テキストのみフォールバックはpdfplumberで実行。モデルごとの supports_vision フラグ。DOCUMENT_PROCESSING_MODE、DOCUMENT_VISION_DPI、DOCUMENT_VISION_MAX_PAGES 経由のモード。DOCX/PPTX埋め込み画像抽出。会話ターン全体でのマルチターンビジョン永続化。スマートPDF処理（テキストリッチページはテキスト+画像を抽出; スキャンページはフルページPNGとしてレンダリング）。--network=none コード実行用の一般的なデータサイエンスパッケージを備えた事前構築サンドボックスイメージ（Dockerfile.sandbox）
リソースフォーク完了 — 智能体 / コネクタ / ワークフローフォークエンドポイントを追加、5タイプ系統追跡を完了（KBフォークは削除 — 本質的にユーザーローカル）
ファイル整合性ガードレール — システム提示词ルールは、ターゲットファイルが読み取り不可の場合、智能体が無関係なファイルコンテンツを代替することを防止; アップロードされたファイルにはメッセージコンテキストに file_id が含まれ、直接 read_uploaded_file アクセス用

v0.8.3 (2026-04-16) — ユニバーサルドキュメント変換 + エージェントコアフェーズ 3

ユニバーサルドキュメント変換（convert_to_markdown + OCR） — Microsoft MarkItDownをラップした組み込みエージェントツール。PDF、Word、Excel、PowerPoint、HTML、JSON、CSV、XML、ZIP、EPUB、Outlook .msg、画像、オーディオ、YouTube URLをMarkdownに変換します。LiteLLMOpenAIShimは任意のビジョン対応LLM（Claude、Gemini、Bedrock、Azure）経由でOCRを有効にします。ビジョン対応RAG取り込みとゼロリグレッションのテキストのみフォールバック。LLM_SUPPORTS_VISION環境変数でオプトアウト可能
エージェントコアフェーズ 3（ランタイム不変性の強化） — 会話復旧（ぶら下がりtool_useの自動修復）；構造化コンパクト作業カード（圧縮ラウンド全体での型付きWorkCardマージ）；ターンレベルプロファイラー（REACT_TURN_PROFILE_ENABLED）；ユーザーごとのレート制限（LLM_RATE_LIMIT_PER_USER）；tool_callsを含む空のコンテンツアシスタントメッセージは削除されなくなりました

v0.8.4 (2026-04-17) — 提示词キャッシュ + 推理正確性

システム提示词セクションレジストリとキャッシュブレークポイント — メモ化された PromptRegistry はシステム提示词を安定したプレフィックス + 動的サフィックスに分割; キャッシュ対応プロバイダー (Claude、Bedrock Anthropic、Vertex Claude) はプレフィックスで cache_control: {"type": "ephemeral"} を受け取り、ターンあたりの入力token節約は約60～80%; 非キャッシュプロバイダーは単一の連結メッセージを取得 (動作変更なし)
提示词キャッシュの可観測性 — cache_read_input_tokens と cache_creation_input_tokens は UsageSummary → TurnProfiler → done_payload.cache フィールドで追跡; ターンごとに構造化された turn_cache ログ行。キャッシュ正当性プローブとしても機能
会話復旧MVP — 合成 tool_result 行は中断されたターン後に永続化; POST /chat/resume はモノトニックカーソルからキャッシュされたSSEイベントをリプレイ; フロントエンド useSseResume フックは指数バックオフ (300ms → 1s → 3s、最大3回試行) で自動再接続し、「再接続中…」インジケーターを表示
思考ブロック永続化と署名 — reasoning_content + Anthropic signature は metadata_["thinking"] に永続化され、後続のターンでリプレイ; Claude 4マルチターン会話でのHTTP 400署名不一致を修正
プロバイダー対応推理リプレイポリシー — core/prompt/reasoning.py の集中化された reasoning_replay_policy() はプロバイダーファミリーごとにシリアル化をゲート: Claude は署名付きで思考ブロックをリプレイ; DeepSeek-R1/Qwen-QwQ/Gemini-thinking/o-series はアウトバウンドで reasoning_content をドロップ (以前はリーク、プロバイダーKVキャッシュを破壊し、APIドキュメントに違反)

v0.8.5 (2026-04-23) — Channel Integration + Hook System + Contributor i18n

Feishu Channel (Phase 1 subset) — Org-scoped Channel リソースと Fernet 暗号化認証情報；FeishuChannel はインタラクティブカード送信 + コールバック（署名検証 + URL チャレンジ）をサポート；Settings → Channels 管理 UI（リスト、作成/編集（ダーティ状態保護付き）、詳細（コピー可能なコールバック URL 付き）、テスト送信）；CRUD API（/api/channels）およびイベントコールバックエンドポイント（/api/channels/{id}/callback）。2026-04-24 路演向けに早期リリース
Agent Hook System（ReAct + DAG ランタイムで稼働中） — src/fim_one/core/hooks/ の PreToolUseHook / PostToolUseHook 抽象化；model_config_json で hooks.class_hooks を宣言するエージェントは、チャットセッションごとにフックがインスタンス化および登録されます。最初のコンシューマー FeishuGateHook は、エージェントが requires_confirmation=True ツールを呼び出すときにリンクされた Feishu グループに承認/却下カードをポストし、実行をブロックし、判定に基づいて再開または中止します
設定可能な確認ゲート（インラインまたはチャネル） — すべてのエージェントは承認セクションを取得し、3 つのルーティングモード（自動 / インラインのみ / チャネルのみ）、承認者スコープセレクター（開始者 / 所有者 / 組織内の誰でも）、ツール単位のオーバーライド、および明示的な承認チャネルピッカーがあります。自動モードは、チャネルがリンクされていない場合、インラインの承認カードに適切にフォールバックします。POST /api/confirmations/{id}/respond は Feishu webhook と単一の決定記録パスを共有します
エージェント単位のタスク完了通知 — 長時間実行される ReAct または DAG エージェントは、タスク完了時に組織のチャネルにサマリーカードをプッシュできます。汎用アウトバウンド通知パターンの最初のコンシューマー
Hook 承認 Playground — Channels 詳細シートには「Test Approval Flow」アクションがあり、完全な本番パス（本物の ConfirmationRequest 行、実際の Feishu コールバック、ステータス遷移）を実行します——本番フックが使用するのと同じコードパス
貢献者向け i18n CI フォールバック — .github/workflows/i18n-sync.yml は PR マージ後にマスターで EN → ZH/JA/KO/DE/FR に翻訳し、[skip ci] で自動コミットします；貢献者はローカルで LLM_API_KEY を必要としなくなります。プリコミットロケール編集ガードは、生成されたロケールファイルへの手動編集を拒否します（正当な翻訳修正の場合は ALLOW_LOCALE_EDIT=1 オーバーライド）。スモークテストプッシュで end-to-end 検証済み
Exa 統合ドキュメント — 専用の Integrations セクションと、完全な Exa 検索サーフェス（neural / fast / deep-reasoning / instant）、フィルタリング、コンテンツ取得、および 3 つのチューニング済みプリセットをカバーする第一級の Exa ページ
Xinchuang（信創）データベースサポート — Database Connector は PostgreSQL/MySQL と並んで KingbaseES（人大金仓）、HighGo（瀚高）、DM8（达梦）をリストアップするようになりました。PG 互換ドライバーは asyncpg を再利用；DM8 は dmPython を使用します。scripts/test_xinchuang_dbs.py は CLI からのライブ接続性を検証します
Channels + Hook System アーキテクチャドキュメント — docs/architecture/hook-system.mdx は 3 つのフックポイントを説明し、FeishuGateHook を end-to-end で説明します；既存のアーキテクチャページはクロスリンク；README は Messaging Channels を第一級の機能としてリストアップします
強化 — 重複した Feishu コールバッククリックは二重決定の代わりに置換カードを生成；並行コールバッククリックは条件付き UPDATE ... WHERE status='pending' 行数チェックで解決；保留中の承認は CHANNEL_CONFIRMATION_TTL_MINUTES（デフォルト 24h）後にバックグラウンドスイーパーで自動期限切れ；Settings → Channels は組織ロールを尊重（メンバーは読み取り専用 UI を表示）；並行ツール呼び出しアグリゲーターは、すべてのデルタに対して index=0 を再利用するプロバイダーを処理；セッション期限切れリダイレクトはクエリ文字列を保持

計画されているバージョン

v0.8.6 — チャネル & フックポーリッシング

目標: v0.9 本番環境対応化の波が到来する前に、v0.8.5 チャネル + フックロールアウトからの未解決の問題を解決する。スコープは意図的に狭い — 新機能ではなくポーリッシング。

フック単位の設定パススルー — 現在 class_hooks エントリは単なる文字列ですが、FeishuGateHook.timeout_seconds、poll_interval_seconds、または callback_base_url をエージェント単位でオーバーライドするには、スキーマが {"name": "feishu_gate", "config": {...}} オブジェクトを受け入れて、それらをフックファクトリへの kwargs として転送する必要があります。低リスクのフォローアップです。現在のデフォルト（120秒タイムアウト / 1.5秒ポーリング / 環境変数コールバック URL）は当面受け入れ可能です。
DAG tools_used 精度 — 完了通知カードは現在 plan.steps[*].tool_hint（プランナーの提案）から tools_used を導出していますが、ステップごとの ReAct ループが実際に選択した実際のツール名ではありません。DAG エグゼキューターのステップ完了コールバックから実際に選択されたツール名を取得して、通知カードが実際に実行されたものを反映するようにします。
委譲されたサブエージェントと Workflow AGENT ノードのフック継承ポリシー — 現在 CallAgentTool 子とワークフロー AGENT ノードは、親のフックレジストリを継承しない新しい ReActAgent を作成するため、委譲経由で到達する機密ツール呼び出しは feishu_gate を静かにバイパスします。決定して文書化します: 子エージェントは継承するか（デフォルト安全、ゲートバイパスを防止）、それとも分離するか（チームが承認ゲートなしの作業を子エージェントに委譲できるようにする）？Eval Center の実行は設計上オプトアウトのままです（自動化は人間の承認でブロックできません）。
プレイグラウンドフォローアップ提案が復元され、エージェント単位でオプトイン — v0.8.5 後処理リファクタリングは提案生成をファイア・アンド・フォーゲットバックグラウンドタスクに移動し、post_processing / suggestions SSE イベントをドロップしたため、回答の下のチップ行は表示されませんでした。提案は現在 done と end の間でインラインでストリーミングされ、新しいエージェント単位の suggest_followups トグル（デフォルトオフ）でゲートされます — タスクスタイルエージェントは静かなままで、明示的にオプトインする会話型エージェントは 1 つの高速モデルラウンドトリップを支払い、チップを取得します。

ここのすべてが加算的で既存の抽象化の背後にあります — スキーマ変更なし、破壊的な API 変更なし、v0.8.5 と v0.9 の間で段階的にランディングするのは安全です。

v0.9 — 可観測性 + 本番環境対応

目標: 本番環境グレードの運用、デバッグ、モニタリング。Hook System を導入 — 智能体の指示の下に位置する決定論的な強制レイヤーで、LLMによってオーバーライドできません。

コネクタ認可レイヤー（データレベルRBAC）

既存のRBAC制御はリソース可視性（誰がコネクタを見られるか）を制御しますが、実行時認可（呼び出し元がそれを通じて何ができるか）は制御しません。管理者が高権限認証情報を使用してDB/APIを設定すると、そのコネクタを使用する組織のすべてのメンバーが管理者の影響範囲を継承します。このセクションでは、3つの異なるアップストリーム機能層にわたってこのギャップを埋めます：

Tier 1 — DBモード（フル管理者+基本/レガシー）: 管理者は単一のDB認証情報（rootまたは最小権限サービスアカウント）を提供します。ほとんどのレガシーシステムはユーザーごとのDBアカウントを発行できないためです。強制はConnectorScopeGuardを介して接続上で発生します。これはPreToolUseフックで、呼び出し元のアイデンティティごとにquery / execute呼び出しをフィルタリングします。機能：破壊的な動詞（DROP、TRUNCATE、スコープなしのDELETE/UPDATE）をブロック；テーブルレベルの許可/拒否リスト；pii=trueセマンティックアノテーションによるカラム編集；スコープ述語の自動注入（例：すべてのSELECTにAND dept_id = :caller_deptを追加）。設定はコネクタ上のscope_rules JSONフィールドで、ロールベースのマッチング；デフォルトは曖昧な場合は拒否です。
Tier 2 — Open APIモード（ユーザーごとのAPIキー）: 推奨パス。ユーザーは独自のAPIキーを持参します（v0.8で出荷 — connector_credentials + allow_fallback=false）；アップストリームシステムのネイティブ認可がスコープを自然に強制します。残りの作業：ユーザーごとの認証情報を要求するコネクタごとの管理UI（管理者フォールバックをグローバルに無効化）と、どの組織メンバーがまだ独自のキーをバインドしていないかを示すヘルスダッシュボード。
Tier 3 — 中間層（ログインチケット交換）: ユーザースコープのAPIキーがないフロントエンド/バックエンド分割システム向け。システムのログインエンドポイントをユーザー提供の認証情報で呼び出し、返された短命チケットをキャッシュし、有効期限時に自動更新します。APIキー / OAuth と並んで新しいLoginTicketCredentialタイプ；コネクタ仕様はauth_type: login_ticketをlogin_endpoint、ticket_field、およびrefresh_strategyで宣言します。アダプタレイヤーはリクエストごとにチケットをアウトバウンド認可ヘッダーに変換します。
クロスティア監査可能性: すべてのツール呼び出しにcaller_user_id、effective_credential_source（ユーザー / 管理者フォールバック / チケット）、およびscope_rules_appliedをConnectorCallLogにスタンプするため、オペレーションは事後に「実際に誰が何を誰として実行したのか」に答えることができます。

チャネル → 統合プロモーション

現在、Feishuはチャネル + コネクタペアとして構成されています — 配信パイプとAPIサーフェス。エンタープライズロールアウトには3番目のロールが必要です：統合（同じサードパーティバインディングがSSOと組織グラフ同期も提供します）。v0.9に登場します。既存のFeishuバインディングが必要な4つのファセットのうち3つをすでにカバーしており、アイデンティティストーリーが上記のTier-2認可のブロックを解除するため（ユーザーはログイン時に独自の上流トークンを取得でき、APIキーを手動でプロビジョニングする必要がなくなります）。

チャネル → 統合モデル：Channelを「アウトバウンドのみの配信」からThirdPartyIntegration親に昇格させ、3つのオプトイン機能を備えます — (a) 配信（既存のチャネル動作：カードを送信、確認をゲート）；(b) ログイン（OIDC / カスタムSSO；「Feishuでログイン」はFIMセッションと上流プラットフォームトークンの両方を生成）；(c) 組織グラフ同期（上流の部門/メンバーをFIM組織構造にミラーリング；スケジュール済みまたはWebhook駆動）。管理者はバインディングごとに各機能を切り替えます。
Feishu SSOを統合機能として：既存のFeishuアプリバインディング（app_id/secretはすでにチャネル上にあります）を再利用して、「Feishuでログイン」をFeishuテナントが組織にバインドされているすべてのユーザーに公開します。ログイン時に取得されたトークンは、ユーザーのFeishuコネクタのデフォルト認証情報になります — Tier-2強制のための「独自のAPIキーを取得する」という摩擦を排除します。
組織グラフ同期（Feishu → FIM組織）：Feishuの部門+メンバーをFIMにプル；Feishuテナント管理者/部門長/メンバーロールをFIM所有者/管理者/メンバーにマップ。次のWeComとDingTalk、およびv1.0のKingdee / Yonyou / SAP ERP-OAアダプタの基盤。

パブリックAPI（フェーズ2）

フェーズ1（リリース済み）：APIキー認証ミドルウェア、スコープサポート、キュレーション済みOpenAPI仕様、インタラクティブプレイグラウンド付きMintlify APIリファレンス。

可観測性とエージェントランタイム

Prompt Cache + Reasoning Follow-ups (Batch A MVPs から)

これらの項目は Batch A で出荷された部分的な作業 (Conversation Recovery、System Prompt Registry、Thinking Blocks) を完成させ、キャッシュ対象を残りのプロバイダーファミリーに拡張します。

Gemini Context Cache Adapter: Google Gemini は Anthropic が使用するインライン cache_control マーカーではなく、別の REST API (POST /v1beta/cachedContents → cacheName を返す → 後続の generateContent 呼び出しで cachedContent: "<cacheName>" で参照) を使用します。ライフサイクル管理 (プリフィックスの事前登録 → cacheName の参照 → TTL 対応の無効化) を備えた GeminiCacheAdapter が必要で、OpenAICompatibleLLM の Gemini パスまたは LiteLLM の Gemini プロバイダーに統合されます。読み取り割引は約 0.25×、最小プリフィックスは 32,768 token (Gemini Pro) / 4,096 (Flash) — 主な受益者は長いコンテキストの KB/RAG 智能体とドキュメント集約的なワークフローです。
Prompt registry を planner / verifier / domain classifier に拡張: PromptRegistry + DYNAMIC_BOUNDARY パターンを ReAct から残りの LLM 呼び出しサイトに拡張します: DAGPlanner、PlanAnalyzer、StepVerifier、CitationVerifier、DomainClassifier、ExecutionModeRouter、CompactUtils。現在、これらは呼び出しのたびにプロンプトをゼロから再構築しています。ReAct より呼び出し頻度が低いため ROI は低いですが、キャッシュの全体像を完成させます。
エージェント単位の cache_ttl 設定: エージェント所有者が ephemeral (5 分、デフォルト、安価な書き込み) と extended (1 時間、書き込みコストは 2 倍ですがバッチ/スケジュール済みワークフロー向け) の間で選択できるようにします。Agent モデルのフィールドとして表示し、サポートされている場所で cache_control: {"type": "...", "ttl": "..."} を通じて渡します。
DAG ステップレベルのチェックポイントテーブル: 現在の A1 Conversation Recovery MVP は合成 tool_results とキャッシュされた SSE イベントを永続化しますが、DAG 中間ステップの状態はメモリ内にのみ存在します。新しい dag_execution_step テーブルは各ステップの tool_calls、results、artifact 参照をスナップショットするため、DAG 途中の切断は完了したステップを再実行せずに再開できます。フロントエンドの useSseResume フックと組み合わせてエンドツーエンドの連続性を実現します。
Message の専用 tool_call_id カラム: 現在 tool_call_id は metadata_ JSON に存在し、孤立した tool-use クエリに対して json_extract(...) / ::json->> ルックアップが必要です。トラフィックが多いデプロイメントでは、第一級のインデックス付きカラムにより、recovery パスが O(n) スキャンではなく O(log n) で実行できます。スケールが必要になるまでは低優先度です。
ストリーム中の thinking token 再構築: 現在の再開の粒度は「次の完全な SSE イベント」です — ドロップが thinking デルタ内で発生した場合、クライアントは次のイベントから再開します。token レベルの再開には、進行中の thinking ブロックのバッファリングされた token を再発行する必要があります。ニッチな改善で、ユーザーが不安定な接続で thinking UX のちらつきを報告した場合にのみ追求する価値があります。
API relay キャッシュ正確性プローブ: 各設定済みリレーを通じて 2 つの同一 Claude リクエストを送信し、実際に課金された入力と cache_read_input_tokens を比較し、cache_control マーカーを削除するか 0.10× 割引を通じないリレーにフラグを立てるバックグラウンドツール (管理者トリガーまたはスケジュール済み)。Workspace レベルの「relay health」シグナルとして表示されます — 中国の API プロキシを通じてルーティングするエンタープライズ向けの有用な運用ツール。

信頼性フォローアップ（Agent Core優先度マトリックス）

Agent Core統合ブループリント（Phase 0–3、I.1–I.16）の大部分はv0.8.2およびv0.8.3で提供されました。以下の項目は、まだ対応が必要な並列優先度マトリックスからのものです。

コンテンツ置換状態の永続化（ストリーミング不変量#2）：「一度表示されたら、運命は確定」— クライアントに既に送信されたメッセージコンテンツは、再開/リロード時に遡及的に変更されてはいけません。A1のSSEカーソルに合わせた置換台帳が必要です。実際のユーザーに見える不具合の理解に基づいてブロックされています。アクティブな苦情はありません。
添付ファイルコンテキストルーター：alreadySurfaced + readFileState重複排除、添付ファイル予算の集約、およびライブネスチェックを使用したスマートな添付ファイル注入。毎ターン同じ50KB PDFエクスプレクトを再送信することを防ぎます。ワークスペースファイルオフロード（既にv0.9計画に含まれている）と連携します。
サイドクエリワーカー（プロンプトワーカープール）：リコール/分類/要約/セッションメモリクエリ用の専用軽量プール。メインエージェントLLM呼び出しとレート制限予算を競合させません。前提条件：プロンプトレジストリの拡張（上記）。

エコシステム & スケーリング

スケジュール済みジョブ + イベントトリガー型智能体 (Loop): cron風のバックグラウンドタスクトリガー; scheduled_jobs + job_runs DBテーブル; APScheduler統合; ジョブ CRUD API + ジョブ履歴 UI; メッセージプッシュコネクタ経由の結果通知。スコープはタイムトリガー (cron) とイベントトリガー (webhook インバウンド) の両パターンをカバー — バックグラウンドで非同期実行される智能体は Hub モードの非同期サブ智能体ユースケースです。
プリビルトソリューションテンプレート (Market シードコンテンツ): 初回ユーザー登録時に Market に公開される 8 つの即座に使用可能な業種別ソリューション — Financial Audit、Contract Review、Data Reporting、IT Helpdesk、HR Onboarding、Sales Assistant、Content Writer、Meeting Summary。各テンプレートは智能体 + スキルを中国語 SOP とともにバンドル; ensure_solution_templates() 経由でべき等にブートストラップ、Market org に公開してマーケットプレイスの即座の利用可能性を実現 (v0.8.1 でリリース)
DB スキーマ高度なビルダー: 大規模データベース向けの AI 駆動スキーマ管理智能体 — 戦略的なテーブルアノテーション (パターンベース、SQL 実行インフォームド)、ドメインプレフィックス別の一括可視性管理、1K～7K+ テーブルデプロイメント向けの反復的マルチラウンドアノテーション; 既存のバッチアノテーションジョブを補完し、選択性とビジネスコンテキスト推理を提供
リソースフォーク (パッケージフェーズ 1 — v1.0 パッケージシステムの前提条件): すべてのリソースごとのフォークエンドポイント実装 — MCP Server、Skill、Agent、Connector、Workflow。KB フォークは削除 (本質的にユーザーローカル)。各 POST /api/{type}/{id}/fork はユーザー所有の深いコピーを forked_from 系統追跡とともに作成 (v0.8.1 で完了)
ワークフロー単位の credential_policy オーバーライド (owner | caller | auto): 5 つのワークフロートリガーパスは現在、コネクタアクションを実行する ID をハードコード — webhook/cron は wf.user_id (オーナー) を渡し、manual/batch は current_user.id (呼び出し元) を渡します。これは一般的な「オートメーションはオーナーとして実行、手動実行は呼び出し元として実行」という期待に合致していますが、エンタープライズデプロイメントではワークフロー単位でオーバーライドが必要な場合があります (例: 現在のオンコールエンジニアの下で実行する必要がある cron、または手動実行でもオーナーの認証情報を借用する必要がある共有テンプレート)。Workflow モデルに credential_policy フィールドを追加し、Schedule / API-Key 設定の隣の UI に表示して、デフォルトの trigger_source → identity マッピングをオーバーライドします。前提条件: 上記の trigger_source 可観測性。

インパクト: FIM One を自信を持ってスケールで実行します。4 つの柱: トレースレイヤー (何が起こったかを確認)、フックシステム (何が起こる必要があるかを強制)、智能体ワークスペース (永続的なファイル管理 + ハンドオフ)、IM チャネル (智能体がユーザーが働く場所に存在)。プリビルトソリューションテンプレートはコールドスタートを排除; ダッシュボード拡張は運用上の健全性を表示します。「智能体が従う可能性のある指示」と「システムが強制する保証」の間のギャップは閉じられます — デモと本番エンタープライズツールの違いです。

v1.0 — ホットプラグ + 埋め込み可能

目標: ゼロ再起動のコネクタ追加、パッケージエコシステム、および埋め込み配信。 インパクト: エンタープライズは FIM One をゼロから数日でマルチシステムオーケストレーションにデプロイ。パッケージシステムはクリエータエコシステムを作成 — ソリューション作成者は複合バンドル (スキル + エージェント + コネクタ + KB + ワークフロー) を公開、エンタープライズはワンクリックでインストール、クリエータは採用から収益を得る。インストール/フォークの二重性は「そのまま使用」と「テンプレートからカスタマイズ」の両方のユースケースを単一メカニズムでカバー。

凍結された機能（リリース済み、メンテナンスのみ）

直交性戦略に従い、これらの機能はリリースされ動作していますが、新しい機能は追加されません（バグ修正のみ）：

機能	バージョン	凍結理由
ReAct エージェント	v0.1, v0.9	モデルがネイティブツール呼び出しを備えている。ループ中の自己反省（v0.9）は長いチェーンでの目標のずれを防ぐ。ツール観察合成品質が向上（8K文字、`REACT_TOOL_OBS_TRUNCATION`で設定可能）
DAG計画 / 再計画	v0.1, v0.5, v0.7.5	モデルの推論能力が向上。分解がシングルショットになりつつある。ステップごとの検証がv0.7.5でリリース（`DAG_STEP_VERIFICATION`）。強化：カスケード障害伝播、検証者ステータス修正、プランナーツール説明、完全な再計画履歴、ホワイトリストベースのツールキャッシュ。14個のエンジン定数が環境変数として公開 — さらなる計画プリミティブは予定されていない
メモリ（ウィンドウ、サマリー、コンパクト）	v0.2, v0.5	コンテキストウィンドウが拡大（200K以上）。外部メモリ管理の必要性が低下
RAGパイプライン	v0.5	プロバイダーがネイティブに検索を構築（OpenAI file_search、Gemini Search Grounding）
グラウンデッド生成	v0.5	モデルが引用に改善。5段階パイプラインは限定的な価値を追加
ContextGuard / ピン留めメッセージ	v0.5	現状のままリリース。新機能なし

検討対象外（無期限延期）

直交性戦略に基づき、以下は高い実装コストと吸収リスクを抱えています：

機能	延期理由
マルチ智能体オーケストレーション（深い階層）	プロバイダーがネイティブに構築中（OpenAI Swarm、Google A2A、および同様のマルチ智能体オファリング）。FIM Oneの CallAgentTool は1段階の委譲ケースをカバー；イベントトリガー型バックグラウンド智能体は v0.9 のスケジュール済みジョブでカバー
智能体の自己修正スキル（手続き型メモリ）	実行中に智能体が独自の `skill.md` を更新する — 高い複雑性、セキュリティ/監査の表面積が大きい。智能体スキルシステム（v0.8）のリリースが先決。エンタープライズ顧客が自己改善型智能体を明示的にリクエストした場合は再評価
~~智能体ワークスペース（ツール出力ファイルオフロード）~~	v0.9 に昇格。価値は選択的読み取りであり、コンテキスト容量ではない — フレームワーク横断的な検証で確認済み。元の延期理由（「200K+ ウィンドウは緊急性を低減」）は誤り
クロスセッション長期メモリ	コンテキストウィンドウが急速に拡大中（200K–2M）；プロバイダーが組み込みメモリを追加中（OpenAI メモリ、Gemini コンテキストキャッシング）；実装コストが高い割に差別化価値が低い。エンタープライズ顧客が明示的にリクエストした場合に再評価
メモリライフサイクル（TTL、クォータ）	クロスセッションメモリに依存；一緒に延期
アクティブコンテキスト圧縮ツール（智能体トリガー型）	ContextGuard（v0.5）で明示的に凍結。200K+ のコンテキストウィンドウは価値を低減。コンテキストコストがエンタープライズの主要な課題にならない限り再検討しない
ブラウザオートメーション / コンピュータユース	高い保守コスト（DOM 変更、アンチボット、サンドボックス化）。業界は Computer Use モード（Anthropic、OpenAI Operator、Google Mariner）と MCP ブラウザツール（Puppeteer/Playwright MCP）に収束中。MCP 統合経由で消費し、自社構築しない。安定した Computer Use MCP 標準が出現した場合に再評価
Web プッシュ通知	Service Worker + VAPID 経由のブラウザネイティブプッシュ。IM チャネル統合（v0.8）と重複（Lark/Slack/WeCom/Email などのエンタープライズ推奨チャネルをカバー）。IM プッシュはエンタープライズ価値が高い；Web プッシュはポータルのみユーザー向けの付加機能。IM チャネルのリリース後に再評価 — ユーザーが IM カバレッジ外のブラウザ通知をリクエストした場合
マルチユーザーワークフロー協調編集	同じワークフロー設計図のリアルタイム共同編集（Figma/Notion スタイル）、カーソル認識、競合解決、ノード単位のロック付き。高い実装コスト（CRDT / OT、プレゼンス基盤）、現在の「1 編集者のみ + バージョン差分」モデルに対するエンタープライズ需要が不明確。複数のエンタープライズが共有ライブ編集を明示的にリクエストした場合に再評価
ノード単位のワークフロー実行権限（実行時 RBAC）	単一ワークフロー実行内の細粒度認可 — 例：「ノード X は実行に `finance_approver` ロールが必要」。現在の認可はワークフローレベル（誰がトリガーできるか）とコネクタレベル（どの認証情報が実行するか）で発生；ノード単位の RBAC は第 3 の軸を追加し、実装複雑性が高い割にアクティブな顧客リクエストがない
クロスオーグワークフロー共有とライブアップデート	別のオーグからワークフローをサブスクライブし、再フォークなしで上流アップデートを受け取る。現在のサブスクライブ = フォーク（スナップショット）であり、上流の破壊的変更は伝播しない。ライブアップデートは上流互換スキーマ進化 + 競合解決が必要；保守コストが高い。エンタープライズが「子会社間のワークフロー共有」をリクエストした場合に再評価

バージョンとモードの整合性

Version	Standalone	Copilot	Hub	Notes
v0.1–v0.3	Working	Not yet	Not yet	Portal-only, single-user
v0.4	Working	Not yet	Not yet	Multi-conversation, agent management
v0.5	Working	Not yet	Not yet	Knowledge base + RAG
v0.6	Working	Possible	Possible	Connectors ship; Copilot/Hub possible with manual wiring
v0.7	Working	Ready	Ready	Admin platform; multi-tenant auth; ready for production
v0.8	Working	Ready	Optimized	RBAC + audit log per-system; easier to onboard
v0.9	Working	Ready	Production	Observability, performance, hardening
v1.0	Working	Optimized	Enterprise	Package system, creator program, hot-plug, embeddable widget, webhooks, batch

リソース配分 (v0.8–v1.0)

直交性戦略は努力の方向を決定します:

カテゴリ	配分	バージョン	理由
コネクタプラットフォーム (v0.6+)	50%	継続中	コア差別化; 吸収リスクなし
エンタープライズ機能 (RBAC、監査、セキュリティ、可観測性)	30%	v0.8–v1.0	地味だが耐久性がある; 本番環境要件。エージェントトレースレイヤーは商用アンカー
エージェントインテリジェンス (スキルシステム、スケジュール済みエージェント)	15%	v0.8–v0.9	指令+ツール+スキル差別化ストーリー; 吸収リスク低 — フレームワークはパターンを検証しますが、エンタープライズ SOP は顧客固有
v0.1–v0.5 メンテナンス	5%	継続中	バグ修正のみ; 新機能なし

メトリック駆動型マイルストーン

成功は以下のメトリクスで測定されます:

メトリック	v0.7 ターゲット	v0.8 ターゲット	v1.0 ターゲット
デプロイされたコネクタ	5	20+	100+
エンタープライズ顧客	1–2	5–10	20+
平均コネクタセットアップ時間	2週間	2日	5分 (ホットプラグ)
トークン効率 (DAG vs ReAct-only)	30% 削減	40% 削減	50% 削減
アップタイム SLA	99.5%	99.9%	99.95%
サポートチケットテーマ	統合、セットアップ	コネクタカスタムロジック	ホットプラグ、スケーリング

未解决的问题 / 待定事项

マーケットプレイスモデレーション: コミュニティパッケージと個別リソースを検証する方法は？パッケージ設定の認証情報漏洩を自動スキャンするか？ (v1.0)
トークン経済学: マルチユーザー、マルチエージェントシナリオの価格設定方法は？ (v1.0)
パッケージバージョニング: インストール済みパッケージの破壊的変更 — マイグレーションスクリプトによる自動アップグレード、または更新ごとの手動承認？依存関係のダイアモンド問題の解決？ (v1.0)
パッケージ価格設定: 無料 vs 有料ティア、Creator Program のコミッション率、決済プロバイダー統合？ (v1.0)
パッケージ認証情報 UX: インストール時の認証情報収集 — ウィザード形式のステップバイステップ、または遅延セットアップ？同じコネクタタイプを使用するパッケージ間での認証情報共有？ (v1.0)
テレメトリオプトアウト: プライバシー設定をどのように尊重するか？ (v0.8)
コネクタバージョニング: コネクタ API の破壊的変更をどのように管理するか？ (v0.8)
レート制限: ユーザーごとのワークフローレート制限が実装済み (スライディングウィンドウ 10 回/分、3 同時実行)。コネクタごと、エージェントごとのレート制限は TBD (v0.9)
コネクタ認可ティア選択: 管理者が特定のアップストリームシステムに適用されるティアを発見するにはどうするか？自動プローブ (ユーザーごとの API キーを試す → ログインチケットにフォールバック → 共有 DB にフォールバック) vs. コネクタ仕様での明示的な宣言？「このコネクタは Tier 2 をサポートしていますが、管理者は Tier 1 で動作することを選択しました」を UI で表現し、非技術系管理者を混乱させないようにするにはどうするか？ (v0.9)
統合 vs コネクタの二重性: Feishu バインディングが同時に SSO プロバイダーと API 呼び出しサーフェスである場合、設定でそれをどのように提示するか？ 3 つのトグルを持つ 1 つのオブジェクト、または認証情報を共有する 3 つの個別バインディング？アンインストールセマンティクスへの影響 (SSO を取り消すとコネクタが削除されるか？) (v0.9)

ロードマップ

変更履歴

Documentation Index

​製品ビジョン

​既知の問題

​出荷済みバージョン

​v0.1 (2026-02-22) — MVP: ReAct + DAG Planner

​v0.2 (2026-02-24) — マルチモデル + メモリ

​v0.3 (2026-02-25) — Web Tools + MCP

​v0.4 (2026-02-25) — マルチターン + エージェント

​v0.5 (2026-02-28) — Full RAG + Grounded Gen

​v0.6 (2026-03-01) — コネクタプラットフォーム

​v0.7 (2026-03-06) — 管理プラットフォーム + マルチテナント

​v0.7.x (2026-03-07 to 2026-03-12) — 安定性 + ポーランド

​v0.8 (2026-03-20) — コネクタ宣言型設定 + 段階的情報開示

​v0.8.1 (2026-03-29) — プログレッシブディスクロージャー成熟度 + ReAct強化

​v0.8.2 (2026-04-10) — 智能体コア強化 + ビジョンドキュメント

​v0.8.3 (2026-04-16) — ユニバーサルドキュメント変換 + エージェントコア フェーズ 3

​v0.8.4 (2026-04-17) — 提示词キャッシュ + 推理正確性

​v0.8.5 (2026-04-23) — Channel Integration + Hook System + Contributor i18n

​計画されているバージョン

​v0.8.6 — チャネル & フック ポーリッシング

​v0.9 — 可観測性 + 本番環境対応

​コネクタ認可レイヤー（データレベルRBAC）

​チャネル → 統合プロモーション

​パブリックAPI（フェーズ2）

​可観測性とエージェント ランタイム

​Prompt Cache + Reasoning Follow-ups (Batch A MVPs から)

​信頼性フォローアップ（Agent Core優先度マトリックス）

​エコシステム & スケーリング

​v1.0 — ホットプラグ + 埋め込み可能

​凍結された機能（リリース済み、メンテナンスのみ）

​検討対象外（無期限延期）

​バージョンとモードの整合性

​リソース配分 (v0.8–v1.0)

​メトリック駆動型マイルストーン

​未解决的问题 / 待定事项