AI App Builder · ロナク・ゾエブ

ステータス（2026年10月）： 初期設計とアーキテクチャの草案は作成済みで、実装は初期段階です。

概要

共同開発者と私は、長時間のタスクのためのパーソナルAIアシスタントを開発しています。ローカル、クラウド、またはその両方で動作し、1回のチャットセッションでは終わらない仕事を担うことを目指しています。たとえば、毎週のリサーチの要約、受信箱の監視、あるいはエージェントが構築して最新の状態に保つ、技術文書管理のための小さなアプリなどです。AI App Builderは仮称です。

最後の例は、私たちが最初に構築を予定している専門的なアプリケーションです。技術文書台帳は、プロジェクトの文書と、それぞれの主要な情報を管理するものです。計画している版では、エージェントがプロジェクト文書一式をもとに台帳を作成して最新の状態に保ち、入力した各項目から出典にたどれるようにします。これにより、人がその値を確認できます。

より広くは、タスクごとに適したAIモデルを選び、エージェントが作成し、継続的に保守・更新するアプリケーションをホストすることを目指しています。各アプリケーションは、独自のデータ、インターフェース、バージョン履歴を持ちます。リサーチの要約や受信箱の監視のようなシンプルなツールから、課題管理や文書管理、データ処理のための、より専門的なアプリケーションまでを想定しています。設計では、アプリケーションを構築するエージェントがそのインターフェースも書くため、インターフェースはタスクに必要なあらゆる形をとれます。表、グラフ、ドキュメントビューアーなど、12個ほどの信頼できるコンポーネントが、現在のモデルがそれをうまく行えるよう支えます。エージェントは定期実行のタスクも実行できるようになり、将来的には会議に参加して、要約やフォローアップのアクションを手伝えるようにもなります。

計画していること

ロードマップは5つの段階で構成しています。順序は目安で、段階どうしが重なることもあります。たとえば音声やコンピューター操作 (computer use) は、他の作業と並行して開発する可能性があります。各段階に日程は設定していません。

初期設計とアーキテクチャ（現在の段階）：プロダクト要件と主要なワークフロー、アーキテクチャと技術設計、既存のエージェントフレームワークとツールの組み込み方、開発と検証の進め方。
コアエージェントフレームワークとセキュリティ（次の段階）：エージェントランタイムとモデルの選択、サンドボックスでの実行とツール連携、権限・承認・利用量の管理、コスト追跡を含む実行履歴。
永続的な実行とハイブリッド実行：中断から復旧できるタスク、ローカル・クラウド・その両方での実行と環境間の引き継ぎ、デスクトップとの連携とコンピューター操作、音声の入出力。
アプリケーションの生成と編集：エージェントが生成し、ビジュアルに編集できる、独自のデータを持つ永続的なアプリケーション。バージョン履歴、ロールバック、共有に加え、複数ユーザーでの共同作業のためのアクセス管理と共有ワークフロー。
自動化と最初のアプリケーション：定期実行のエージェント、トリガー、監視。専用のメール受信箱を持ち、権限と承認の範囲内でユーザーや外部の相手とやり取りできるエージェント。要約やフォローアップのアクションといった会議の支援。そして、リサーチ、情報の監視、技術文書管理のための最初のアプリケーション。

タスクは、ユーザーが停止して再開しなくても、ローカルとクラウドのリソース間をスムーズに移れるようにしたいと考えています。まずは、エージェントのステップ間のチェックポイントでの引き継ぎから始めます。実行中の処理を移すことは、その後に検討します。

設計と各段階については、『長時間のタスクを担うAIエージェントのためのプラットフォーム：アーキテクチャとロードマップ』でより詳しく説明しています。

設計原則

現在の設計は、次の原則に基づいています。いずれも、完成後にプラットフォームがどう動くことを想定しているかを示すものです。

コアは小さく保ちます。各機能は、プラットフォームのコア機能、薄いアドオンのケイパビリティパック、エージェントがその上に構築するアプリケーションのいずれかです。
タスクは永続化され、再開できます。チャット、定期実行のエージェント、メールのスレッドは、すべて同じ種類のタスクです。エージェントの各ステップを記録するため、中断されたタスクも止まったところから再開できます。
アプリケーションはサンドボックス化します。各アプリケーションは専用のサンドボックス化されたフレーム内で動作し、認証情報を保持しません。バージョンは追記のみなので、ロールバックのコストを小さく抑えられます。
操作は権限と照合します。提案中のポリシーでは、操作はリスクに応じて許可、拒否、または承認待ちとなり、認証情報はモデルのコンテキストに入れません。このポリシーの詳細は、まだ検討中です。
コストは最初から追跡します。利用量はリクエストごとに記録し、リクエスト時点の価格で計算します。
エージェントは特定のモデルやプロバイダーに縛られません。doc-processing-toolkitがエージェントループを提供するため、タスクを別のモデルや別のプロバイダーで続けられます。標準ツールはdoc-processing-std-toolsが提供します。

開発の進め方

このプラットフォームは、私の既存の2つのプロジェクトを土台にしています。エージェントフレームワークのdoc-processing-toolkitと、エージェント向けの標準ツールのライブラリであるdoc-processing-std-toolsです。私たちはこれらの上に、より汎用的なAIアプリケーションプラットフォームを構築しています。

他のプロジェクトと同様、実装にはAIコーディングエージェント (Claude Code、Codex、GitHub Copilot) を使っています。私の進め方については、『仕様ファースト、テストファースト』で詳しく紹介しています。また、このプロジェクト用のタスクボードを用意する予定です。エージェントがタスクを割り当てられたり、自らタスクを引き受けたりして、プルリクエストを作成できるようにします。OpenAIがハーネスエンジニアリングに関する記事で説明したのと同様の進め方です。