Construct AI でスタートアップ向け内部ツールを構築する

スタートアップ企業では、内部ツールはスプレッドシートやチェックリスト、毎週実行されるプロンプトとして始まることがよくあります。プロセスは機能しますが、インターフェースは使いにくく、人々はタブ間で値をコピーし、ステータスを頭で覚え、毎回同じ設定を繰り返します。Construct は、そのような繰り返しのプロセスを、ファイルや作業を行うエージェントと同じワークスペース内に存在する小さなプライベートアプリに変換できます。

これは、パブリックな SaaS 製品へのワンクリックパスではありません。Construct ワークスペースアプリは、1 つのワークスペースに特化した内部インターフェースです。あなたが作業を説明すると、エージェントがアプリを書き、ビルドできるか確認し、デスクトップで開き、ソースを検査や後からの変更のために利用できるようにします。

繰り返しのプロセスから始める

最も良いリクエストは、ソフトウェアアーキテクチャを規定するのではなく、作業自体を説明することです。例えば、「所有者、優先度、ステータス、完成したレポートへのリンクを持つ研究リクエストトラッカーを構築する」や、「この定期的なローンチチェックリストをチームが更新できるアプリにする」などです。Construct はリスト、フォーム、ダッシュボード、または空白のインターフェースから開始できます。エージェントはアプリパッケージを作成し、React と TypeScript のソースを書き、必要な機能を宣言し、結果を検証します。成功したビルドは、別のホスティングプロジェクトに送る代わりに、Construct Web デスクトップに直接開きます。

リクエストの具体性は重要です。「運用ダッシュボードを構築する」では未解決の選択肢が多く残ります。「未完了の研究リクエストを表示し、オペレーターが所有者を割り当て、関連するレポートをレビュー済みとしてマークできるようにする」とすれば、エージェントに境界のあるワークフローと、アプリが有用かどうかを判断する明確な方法が与えられます。

アプリは作業と共にある

ワークスペースアプリは隠れた成果物ではありません。そのソースは Files の Apps// フォルダにあり、検査および編集できます。成功したビルド後、アプリはプライベートなワークスペースインストールとして表示され、デスクトップ、Launchpad、または Spotlight から再び開くことができます。

アプリの永続的な状態は AppData// の下に別途保存されます。この分離は重要です。インターフェースを変更しても、アプリが既に管理しているレコードを上書きする必要はありません。再ビルドでコードを更新しても、既存のアプリデータはワークスペースに残り、通常のワークスペースストレージクォータにカウントされ続けます。

このモデルにより、起動後も周囲のエージェントが有用であり続けます。同じワークスペースには、ソース、関連ファイル、会話、診断情報が含まれます。インターフェースに別のフィールドが必要になったり、ランタイムエラーが発生した場合、次のタスクはスクリーンショットや曖昧なバグレポートではなく、実際のアプリから始められます。

ワークスペースアプリの機能

現在のランタイムは意図的に汎用 Web ホスティングプラットフォームよりも狭く、内部ツールをワークスペースの目的に近づけます。サポートされる機能：React インターフェース、TypeScript/TSX、宣言された権限でのワークスペースファイルの読み書き、アプリスコープの JSON ステート、許可された接続アプリの呼び出し、宣言された HTTPS オリジンへのネットワークリクエスト。サポート外：任意の npm パッケージのインストール、アプリ UI からのターミナルやエージェントオーケストレーションの実行、パブリックアプリレジストリへの自動公開。

アプリ UI は、ワークスペースファイル、アプリスコープのストレージ、通知、ウィンドウ制御、明示的に許可された呼び出しのための小さな Construct SDK を受け取ります。作成したエージェントが利用できるすべてのツールを継承するわけではありません。エージェントはビルド中に広範な実行面を利用できますが、完成したインターフェースは独自の狭い契約で動作します。

権限は設計の一部

内部ツールは、信頼されたワークスペース内で生成されたという理由だけで広範なアクセスを得るべきではありません。ワークスペースアプリは、使用するネイティブ機能、接続アプリ、ネットワークオリジンを宣言します。それらの許可リスト外の呼び出しは実行時に拒否されます。

プラットフォームは、アプリがゲートウェイコールを行う際に、現在のワークスペースメンバーシップと権限を再確認します。ファイル操作はユーザーのワークスペースアクセスの対象であり、アプリはそのファイルアクセスを使用して別のアプリのパッケージを書き換えることはできません。直接ネットワークアクセスは、ワイルカードドメインではなく、正確な HTTPS オリジンに制限されます。

ワークスペースファイルのみを読み書きするリクエストトラッカーの場合、ファイルアクセスのみを宣言すれば十分です。承認されたレコードを接続サービスに投稿するツールには、その特定のアプリターゲットも必要です。有用なデフォルトは、ジョブを完了するための最小の権限セットです。

検証はビルドを作成するが、保証ではない

起動前に、Construct はパッケージ構造とマニフェストをチェックし、相対インポートを追跡し、パッケージ境界を強制し、TypeScript と JSX をコンパイルし、設計上の発見を報告します。成功した検証は、決定論的なビルド ID を持つ不変のアーティファクトを作成し、アプリを開きます。

これはパッケージがワークスペースランタイムでビルドできることを証明しますが、すべてのボタン、データ形状、接続サービス、エッジケースが正しく動作することを証明するわけではありません。ランタイム検証は依然として重要であり、特に権限、ストレージ動作、または外部呼び出しを変更した後は重要です。

Construct は、ワークスペースアプリから制限されたコンソール、ネットワーク、ゲートウェイ、ランタイムエラーの診断情報をキャプチャします。エージェントは最近のエラーを検査し、ソースを修復し、再度検証し、変更された動作を確認するようユーザーに依頼できます。このループは、使い捨てのコードスニペットを生成するよりも、小さな内部製品を維持することに近いです。

ドラフト変更は最後の有効なビルドを置き換えない

信頼性モデルは意図的に保守的です。成功したビルドは現在のランタイムアーティファクトになります。後続のソース編集はアプリにドラフト変更があることをマークしますが、新しいソースが検証されるまで、アプリを開くと最後の成功したビルドが実行され続けます。

検証が失敗した場合、動作中のアーティファクトは置き換えられません。編集をキャンセルすると、ソースと以前のビルドの両方がそのまま残ります。デスクトップは、アプリが準備完了か、ドラフト変更があるか、または一度も正常にビルドされたことがないかを表示できます。

これは最後の有効なビルドへのフォールバックであり、完全なバージョン履歴ではありません。修復中に動作中のツールを保護しますが、すべての履歴ビルドをブラウズしたり復元したりすることを約束するものではありません。

内部ツールかワークフローか？

すべての繰り返しプロセスにインターフェースが必要なわけではありません。人々が状態を表示、入力、フィルタ、またはレビューする必要がある場合は、ワークスペースアプリを使用します。主な価値が既知のエージェントステップ、接続アプリアクション、通知のシーケンスを実行することである場合は、Construct ワークフローを使用します。プロセスをバックグラウンドで実行し、誰かが画面を開くのを待つ必要がない場合は、スケジュールされたエージェントジョブを使用します。

両者は同じ操作をサポートできます。ワークスペースアプリはキューとレビュー面を提供し、ファイルは永続的なレコードを保持し、スケジュールジョブは新しい作業を準備します。重要な境界は、アプリ UI が密かに無制限のエージェントにならないことです。自動化は依然としてそのために設計された実行面と権限を通じて実行されます。

ワークスペースアプリの適切なユースケース

適しているのは、明確なオペレーターと永続的なワークスペースコンテキストを持つ狭いツールです：受付フォームとレビューキュー、繰り返し操作のチェックリスト、ワークスペースレコード上の軽量トラッカー、ファイルまたはアプリスコープの JSON データのダッシュボード、明示的に許可された接続サービス上の焦点化されたインターフェース、既存のワークフローを実行および検査しやすくする小さなユーティリティ。

適さないのは、パブリックな顧客向けサイト、任意の npm エコシステムを必要とする製品、複雑なマルチサービスシステム、または独立して運用されるインフラストラクチャとセキュリティコントロールを必要とするワークロードです。パブリックレジストリアプリも別の開発者およびレビューワークフローに従います。プライベートワークスペースビルドは自動的にパブリックアプリレジストリに昇格しません。

最小限の有用なインターフェースを構築する

最短の道は、1 つの繰り返しプロセスとそれを操作する必要がある 1 人の人物から始めることです。アプリが管理するレコード、オペレーターが取るべきアクション、アクセスするファイルやサービス、成功結果の見え方を指定します。次に、Construct にそのプロセスを実行および監督しやすくする最小のインターフェースを構築するよう依頼します。

最初のビルドが開いたら、それを使用します。不足しているフィールド、不明瞭なステータス、不要な画面は、長い仕様書よりも動作するツールでより早く明らかになります。Construct は以前の良好なビルドを利用可能に保ちながらソースを修正できるため、毎回の編集を新しいソフトウェアプロジェクトにすることなく、内部ツールを改善する余地が生まれます。