AIと人が同じブラウザを使える「ego lite」とは？実際に使って分かった便利さと注意点

こんにちは。AlgomaticでソフトウェアエンジニアをしているGo（@53able）です。

AIエージェントへWeb操作を任せるとき、ブラウザ自動化ツールを「速そう」で選ぶと判断を誤ります。CLIの待ち時間、複雑タスク全体の完了時間と成功率、ログイン状態の再利用、人間への引き継ぎ、認証情報の分離を分けて評価する必要があります。

• まず、ego liteとagent-browserの違い

• ego liteを選ぶのは、ログイン共有とハンドオフが必要なとき ログイン済み環境を引き継いで使える

• 人間の操作を邪魔しない

• 独立したWebタスクを別々のTask Spaceへ割り当てられる

• 既存のAIエージェントから使える

• 同じ画面のまま、人間へ操作を引き継げる

• CLI待ち時間とタスク全体の所要時間を分けて測る 複数の操作をJavaScript一本にまとめられる

• HTMLではなく圧縮されたSnapshotを読む

• 要素を意味的に参照できる

• ブラウザプロセスは共有されたが、保存領域は分離されなかった

• 公式の「最速」は、条件付きで支持される 完了した3タスクでは所要時間が約30〜62%短かった

• Real-World Benchでも平均所要時間と成功数で上回った

• 800試行ではagent-browserのCLI待ち時間が約4分の1

• ego liteの安全運用を支える仕組み 人間のタブとエージェントのTask Spaceを分ける

• 操作を目視し、停止・引き継ぎできる

• ハンドオフ中は、人間とエージェントが同時に操作しない

• 再開には人間の明示的な許可が必要になる

• Snapshotはページを変更しない

• 公式資料では、閲覧データを端末内に保持する

• 操作結果を後から確認できる

• 要件ごとにagent-browserとego liteを使い分ける

• 導入前に確認し、運用中に制御する境界 運用で制御するリスク

• 採用前に確認する事項

• エンジニアを募集しています！

• Sources

まず、ego liteとagent-browserの違い

ego liteは、人間とAIエージェントが同じブラウザで作業するためのChromiumベースのブラウザです。人間は通常のタブを使い、AIエージェントはタスク専用のTask Spaceでページを操作します。人間の確認が必要になったら、ページの状態を保ったまま操作権を人間へ渡し、確認後にエージェントへ戻せます。

lite.ego.app

AIエージェントは、操作用CLIのego-browserからego liteへ指示を送ります。Task Spaceの作成、ページ移動、Snapshotの取得、クリック、入力、JavaScriptの実行などが対象です。

一方、agent-browserは、Vercel Labsが公開しているAIエージェント向けのブラウザ操作CLIです。コマンドからページを開き、Snapshotで要素を読み取り、クリックや入力を実行します。独立したブラウザセッションを起動する方法と、--cdpで既存のChromeへ接続する方法があります。独立セッションではCookieとstorageを分離できますが、同じChromeへ接続した場合は共有されます。

agent-browser.dev

つまり、ego liteは人間との共同作業とハンドオフを中心に設計されたブラウザ製品であり、agent-browserはブラウザ操作を自動化するCLIです。両者は同じ種類の製品ではないため、機能数ではなく、どのWeb操作に適しているかで比べる必要があります。

この違いから、得意な場面も分かれます。ログイン状態を引き継がない公開サイトの処理や、起動済みブラウザへの低遅延なCLI操作ではagent-browserを選びます。 ローカル測定では、agent-browserのCLIワークフロー中央値は158.7 ms、ego-browserは623.3 msでした。

ログイン済み環境を共有し、同じ画面のまま人間へ操作を引き継ぐなら、ego liteを選びます。 ただし、Task Spaceを認証情報の分離境界として扱わないことが前提です。

最後の条件は重要です。ego lite 0.4.7.3の実機確認では、2つのTask Spaceが同じbrowserContextIdを返し、CookieとlocalStorageも共有されました。

ego liteは、人間とAIエージェントが同じブラウザを共有しながら、表示ページ、タブ、参照番号、操作権をタスクごとに分ける設計です。

「Space」は製品機能全体を指し、「Task Space」は人間の通常領域と分けられたエージェント用の作業空間を指します。

ログイン済み環境を引き継いで使える

ChromeからCookie、ログイン状態、拡張機能、ブックマークを移行できます。CRM、社内管理画面、SNSなども、普段の認証状態を引き継いで利用できます。

一般的なブラウザ自動化では、AI用に別のブラウザやプロファイルを起動するため、ログイン状態を移す手間が生じます。ego liteは日常利用するブラウザ自体を人間とエージェントで共有し、この手間を減らします。

実機では、Task Space article verification xからログイン済みのXを開き、X公式アカウントを表示できました。画面下部にはTask Space名とAgent is in control、Take over、Stopが表示され、どのタスクを誰が操作しているか確認できます。

この実機確認の対象は、ログイン済みのXをTask Spaceから開くことと、操作状態の表示です。

人間の操作を邪魔しない

エージェントは、タスク専用の「Task Space」で作業します。人間が使っているタブ、マウス、フォーカスを奪いません。

人間が調べ物を続けている間に、エージェントへ別サイトの比較や管理画面の確認を任せられます。普段のタブを使いながら、必要なときだけTask Spaceを確認できます。

独立したWebタスクを別々のTask Spaceへ割り当てられる

調査、QA、データ収集など、依存関係のないタスクを別々のTask Spaceへ割り当てられます。それぞれのTask Spaceは、表示中のページ、タブ、参照番号、操作権を分けて保持します。順次処理と並列処理の完了時間差は測定していません。

Space一覧画面では、人間が使うSpaceとエージェントのTask Spaceをカードとして並べて確認できます。

下の実機画面では、人間がXを開いているSpaceの隣に、公式ドキュメントとGitHubリポジトリを開いた2つのTask Spaceが残っています。エージェントが操作権を持つ2つのカードには、青い光とRunningが表示されています。

通常のブラウザ画面では、右上の丸い数字から、現在開いているTask Spaceの数を確認できます。実機で2つのTask Spaceを作ると2になり、1つ閉じると1へ変わりました。

エージェントのコマンド実行が終わってもTask Spaceを残している間は数字が表示されたため、これは「現在実行中のコマンド数」ではなく「開いているTask Space数」です。操作権の所在は、Task Spaceの青い光やAgent is in controlで確認します。

既存のAIエージェントから使える

Claude Code、Codex、Cursorなどのエージェントは、ego-browserを通してego liteを操作できます。ブラウザに内蔵された専用AIへ乗り換える必要はありません。

同じ画面のまま、人間へ操作を引き継げる

CAPTCHA、SMSやメールの認証コード、ハードウェアキー、決済確認など、人間が操作すべき場面ではTask Spaceをハンドオフできます。求人応募なら正式送信の前、予約なら支払いページの手前で止める、といった使い方です。

ハンドオフすると、人間が同じTask Spaceの同じタブを操作します。別ブラウザでページを開き直さないため、入力済みフォームや認証フローの状態を保ったまま交代できます。

ego liteを選ぶ理由は、人間とエージェントがページ状態を失わずに交代できることにあります。

CLI待ち時間とタスク全体の所要時間を分けて測る

ego liteは、LLMとブラウザの往復、入力情報、操作の試行錯誤を減らすことを狙って設計されています。しかし、設計上の狙いだけでは実際の所要時間は決まりません。仕組みを確認した後、公式の複雑タスク評価と、独自に測定したCLI待ち時間を分けて検証します。

複数の操作をJavaScript一本にまとめられる

ego-browserでは、ページの移動、読み取り、クリック、抽出、集計を一つのNode.js heredocにまとめられます。

操作ごとにCLIを呼び出す方式で発生する「コマンドを実行する、結果を読む、次のコマンドを考える」という往復を、一つのheredocへまとめられます。ツール呼び出し回数は減りますが、実際の所要時間が短くなるかは別に測定します。

HTMLではなく圧縮されたSnapshotを読む

WebページのHTMLには、スタイル、スクリプト、非表示要素など、操作判断に不要な情報が大量に含まれます。HTMLをそのまま渡すと、操作判断に不要な情報までLLMの入力に含まれます。

ego liteのSnapshotは、Chromiumのaccessibility treeをもとに、見出し、リンク、入力欄、ボタンなどの意味構造を抽出します。公式資料では、典型的なページは約200〜400トークンに収まると説明されています。

同じX画面に対して、表示範囲を対象にSnapshotを取得すると、見出し、ナビゲーション、リンク、URL、refが意味構造として出力されました。この実行で得たSnapshotは3,430文字です。これは文字数であり、公式資料のトークン数とは直接比較できません。

出力の一部を抜粋します。

Task Space: article verification x (id 5)
URL: https://x.com/X
Viewport: 1494 x 888
Snapshot characters: 3430
--- Snapshot excerpt ---
root
  container
    container
      banner
        container
          heading
            link "X" [ref=5666, loc=css:a[aria-label="X"], url=https://x.com/home]
              svg_root
          navigation "Primary"
            link "Home" [ref=5750, loc=css:a[aria-label="Home"], url=https://x.com/home]
              svg_root
              text "Home"
            link "Search and explore" [ref=5751, loc=css:a[aria-label="Search and explore"], url=https://x.com/explore]
              svg_root
              text "Explore"

HTMLそのものではなく、操作対象の役割、参照番号、ロケーター、URLを読み出していることが分かります。

Snapshotは、LLMへ渡す情報を操作に必要な意味構造へ絞ります。入力トークンと処理時間への効果は、利用するページとモデルで別に測定します。

要素を意味的に参照できる

ego-browserのSnapshotでは、リンク、入力欄、ボタンなどに@N形式の一時的な参照番号が付きます。エージェントはCSSクラスや画面座標を推測せず、意味構造から操作対象を選べます。

実機でexample.comをSnapshotすると、Learn moreリンクは次のように出力されました。

anchor [ref=16, loc=href:https://iana.org/domains/example, url=https://iana.org/domains/example]
  text "Learn more"

操作コードは参照番号だけを指定します。

await click('@16', { label: 'open Learn more' })

実行後はIANAの説明ページへ移動しました。

Result URL: https://www.iana.org/help/example-domains
Result title: Example Domains

この操作では、CSSクラスも画面座標も指定していません。@Nは直近のSnapshotに対してだけ有効なため、ページが再描画された後はSnapshotを取り直します。長期間再利用する対象には、同時に出力されるlocを使います。

ブラウザプロセスは共有されたが、保存領域は分離されなかった

一般に、タスクごとにChromium一式を起動すれば、タスク数に応じてプロセスとメモリが増えます。公式ドキュメント「Space」は、ego liteのSpaceが同じブラウザプロセスを共有し、タスクごとに独立したBrowserContextを持つと説明しています。今回、比較対象側のプロセス数、メモリ、起動時間は測定していません。

ego liteアプリ0.4.7.3で2つのTask Spaceを作成した実機確認では、メインプロセスは1つでした。ブラウザプロセスを共有する点は再現できています。

ego lite version: 0.4.7.3
main process count: 1
main process PID: 7224

一方、BrowserContextと保存領域の分離は、同じ環境で再現できませんでした。2つのTask Spaceは異なるページTargetを持っていましたが、CDPから取得したbrowserContextIdは同一でした。さらに、Task Space AでCookieとlocalStorageへAを書き込み、Task Space BでBへ上書きすると、Task Space AからもBが読み出されました。以下のログのSpace A/Bは、この2つのTask Spaceを指します。

Space A: targetId=43F531...  browserContextId=7CD827...
         cookie=space_probe=A  localStorage=A
Space B: targetId=69E765...  browserContextId=7CD827...
         cookie=space_probe=B  localStorage=B
Space Aを再読:
         cookie=space_probe=B  localStorage=B

Task Space Bで上書きした後、Task Space AでもCookieとlocalStorageの値がBになりました。

この結果は、公式ドキュメントの「Cookieとstorageが分離される」という説明と一致しません。現行環境で実証できたのは、1つのメインプロセスで複数のページTargetを動かし、タブと操作状態をTask Spaceごとに分けることです。CookieやlocalStorageに機密情報を置くタスクでは、Task Space間の分離を前提にしません。

公式の「最速」は、条件付きで支持される

結論から言えば、Citro Labsが公開したベンチマークでは、複雑なタスク全体の平均所要時間と成功数でego liteが比較対象を上回っています。 一方、製品紹介の「最大3.45倍」は算出過程を確認できず、公表結果を第三者が実行ログから再集計することもできません。確認できるのは「特定のベンダーベンチマークでは速かった」までで、「どの条件でも最速」ではありません。

公式が速度の根拠として示しているのは、4タスク比較とReal-World Benchの2つです。

完了した3タスクでは所要時間が約30〜62%短かった

READMEの比較画像は、同じモデル（gpt-5.5）、同じ推論設定（medium）、同じエージェント（Pi）で、各タスクを5回実行した中央値を示しています。

完了した3タスクで最大の差は、Xの投稿収集における87秒対226秒です。画像はこの結果を「2.6x faster」、README本文は「最大2.5倍」と表記しており、公開資料から表記差の理由は確認できません。一方、製品紹介は「最大3.45倍」としていますが、正確なプロンプト、ツールのバージョン、各試行の実行ログが公開されていないため、算出過程を確認できません。

Real-World Benchでも平均所要時間と成功数で上回った

Real-World Benchの比較記事は、31タスクを154の判定項目で評価しています。記事によると、同じモデル（gpt-5.6-sol）を最大の推論設定で使い、各ツールで31タスクを2回ずつ実行し、成績がよかった一方の実行を採用しています。

平均所要時間は次点より約12%短く、最も長いツールとの所要時間比は約1.34です。4タスク比較とReal-World Benchは、モデル、タスク、試行設計が異なるため、倍率を直接比較できません。どちらの公開資料にも、3.45倍の算出過程はありません。

評価ハーネスと31タスクのデータセットは公開されており、タスク数と154の判定項目は確認できます。新しい比較実験を実行する基盤は公開されています。

一方、公表値の算出に使った実行ログ、agent-browserとの接続実装、ツールごとの完全な設定は、調査時点の公開リポジトリに含まれていません。そのため、30/31対23/31や平均518秒という公表結果を、第三者が同じ実行記録から再集計することはできません。

このベンチマークでは、ego liteの少ない平均ターン数、短い平均所要時間、高い完全成功数が同時に観測されています。ただし、ターン数の削減だけが差を生んだと確認する比較実験はありません。複雑なタスク全体では速かったという結果はあるが、その効果をすべての仕事へ一般化はできない、というのが公開資料から出せる結論です。

800試行ではagent-browserのCLI待ち時間が約4分の1

次に、ブラウザ起動後のCLI自体にどれだけ待つかを測定しました。ego-browser 0.4.7.3とagent-browser 0.34.0を、外部通信のないローカルページで比較しています。ブラウザ本体の起動時間は含めず、起動済みのセッションを再利用しました。実行順を交互に入れ替えた2回の測定から、各測定項目・各ツール200試行、合計800試行を集計しています。

対象は、各ツールが推奨するSnapshotコマンドと、「ページを開く→Snapshotを取る→参照番号でリンクをクリックする→遷移先のURLとRESULT_OKを確認する」というCLIワークフローです。全試行が成功しました。

測定では、外部通信のないHTTPサーバーを127.0.0.1:8765で起動し、各CLIコマンドをtime.perf_counter()の前後で計測しました。計測の中心部分は次の通りです。

def run(cmd, *, input_text=None, timeout=60):
    started = time.perf_counter()
    proc = subprocess.run(
        cmd,
        input=input_text,
        text=True,
        stdout=subprocess.PIPE,
        stderr=subprocess.PIPE,
        timeout=timeout,
        env={**os.environ, "NO_COLOR": "1"},
    )
    elapsed = time.perf_counter() - started
    if proc.returncode:
        raise RuntimeError(f"command failed: {cmd}")
    return elapsed, (proc.stdout + proc.stderr).strip()

順序効果を偏らせないため、試行ごとに実行順を交互に入れ替えました。失敗した試行も消さず、後続試行を継続する設計です。

for i in range(WORKFLOW_REPS):
    order = ("agent", "ego") if i % 2 == 0 else ("ego", "agent")
    for tool in order:
        fn = ego_workflow_trial if tool == "ego" else agent_workflow_trial
        data["cli_workflow"][tool].append(safe_trial(fn, i + 1))

各ワークフローは、SnapshotにOpen resultがあること、参照番号で/result.htmlへ移動すること、遷移先の#oracleがRESULT_OKであることを成功条件にしました。集計に記録した環境と制約も記事内へ残します。

{
  "run_count": 2,
  "versions": {
    "ego_browser": "ego-browser 0.4.7.3 / Chromium 150.0.7871.101",
    "agent_browser": "agent-browser 0.34.0"
  },
  "environment": {
    "machine": "arm64 / Apple M3 Pro",
    "memory_bytes": 38654705664,
    "server": "http://127.0.0.1:8765",
    "session_mode": "warm",
    "execution": "alternating sequential trials",
    "cold_start_measured": false,
    "network_dependency": false,
    "background_load_controlled": false
  }
}

中央値だけでなく、長い停止にも差が出ました。ego-browserの最大値はSnapshotで3.1943秒、CLIワークフローで3.2796秒です。agent-browserの最大値は、それぞれ0.0493秒と0.2540秒でした。

このローカルページで、ブラウザ起動後のCLI操作にかかる時間を優先するなら、agent-browserを選びます。ego-browserは1回のnodejs呼び出し、agent-browserは5回のCLI呼び出しでワークフローを実行しましたが、それでもagent-browserの中央値が短い結果でした。

この測定から判断できるのは、単純なローカルページに対する、ブラウザ起動後のCLI応答速度です。複雑なサイト、LLMの推論、並列実行、入力トークン、メモリ、ブラウザをゼロから起動する時間は、対応する実タスクで別に測定します。Snapshotの出力形式も異なるため、文字数をトークン効率の比較には使いません。

ローカル測定とReal-World Benchは、測定対象と条件が異なるため直接比較できません。前者は、固定したローカルページに対するCLI呼び出しの待ち時間です。後者は、異なるモデル設定、ライブサイト、ログイン状態、成功判定、試行の選び方を含むタスク全体の観察値です。

したがって、「ego liteは速い」という主張は、Citro Labsの複雑タスク評価では支持されるが、CLI操作そのものやあらゆるワークロードで支持されるわけではないと判定します。採用時は、公開倍率をそのまま使わず、実際のタスクで完了時間、成功率、ツール呼び出し回数、入力トークン、メモリを比較します。

ego liteの安全運用を支える仕組み

ego liteはAIを完全に閉じ込めるサンドボックスではありません。安全運用の中心は、操作の可視化、排他的な操作権、人間へのハンドオフです。

人間のタブとエージェントのTask Spaceを分ける

エージェントの操作対象は専用Task Space内に限定され、人間が開いているタブや入力中のフォームから分離されます。

表示中のページ、タブ、参照番号、操作権はTask Spaceごとに分かれます。ただし、今回確認したego liteアプリ0.4.7.3では、CookieとlocalStorageのTask Space間分離を再現できませんでした。認証情報や機密データについては、Task Spaceをセキュリティ境界として扱いません。

操作を目視し、停止・引き継ぎできる

人間はTask Spaceへ切り替え、エージェントが何をしているか確認できます。問題があれば操作を引き継ぐか、タスクを停止できます。

決済、送信、公開、削除、認可などの高影響操作は、運用ルールとして実行前にハンドオフします。公式ドキュメントは、「読み取り専用、変更禁止」「送信前に必ず確認」といった境界を依頼時に指定する方法も推奨しています。

ハンドオフ中は、人間とエージェントが同時に操作しない

公式ego-browser Skillでは、一つのTask Spaceを操作できる主体は一時点で一方だけです。エージェントがhandOffTaskSpaceを実行すると、Task Spaceは人間が操作する状態へ移ります。内部的には、エージェントが作ったTask Spaceの操作権を一時委譲するagentDelegatedToUserという状態が使われます。

人間が操作している間、エージェントのブラウザ命令はネイティブブリッジで拒否されます。エージェントはエラーを迂回したり、自動再試行したりせず、そこで停止しなければなりません。人間がego liteのGUIから突然操作を引き継いだ場合も、同じハードストップとして扱います。

実機でhandOffTaskSpaceを実行すると、画面下部の表示はYou're in controlへ切り替わり、操作権をエージェントへ戻すReturn to agentが表示されました。人間が操作権を戻した後はAgent is in controlへ変わり、ボタンもTake overへ切り替わります。

再開には人間の明示的な許可が必要になる

人間が認証や確認を終えたら、チャットで「続行」などと明示します。その返答を受けた後、エージェントは別の実行でtakeOverTaskSpaceを呼び、同じTask Spaceから作業を再開します。

handOffTaskSpaceとtakeOverTaskSpaceを同じスクリプトで連続実行してはいけません。takeOverTaskSpaceには操作権を自動確認して止まる仕組みがないため、人間の返答前に呼ぶと、ハンドオフ中の排他性が失われます。

アプリ本体・CLIの0.4.7.3と、GitHub上のego-browser Skillリリースv1.2.3は別のバージョン体系です。これらのAPI規則は、v1.2.3に固定した公式Skillで確認しました。公式Webサイトにはハンドオフ専用ページがなく、日本語のego-browserページだけではAPI手順を把握できません。利用前に、インストール済みSkillのバージョンを確認します。

Snapshotはページを変更しない

Snapshotはページ構造を読み取る機能です。Snapshotを取得しただけでは、送信、アップロード、削除などの外部状態は変化しません。

最初はSnapshotによる読み取りと候補整理に限定し、変更操作を段階的に追加できます。

公式資料では、閲覧データを端末内に保持する

公式資料は、Chromeから移行したCookie、履歴、ブックマーク、拡張機能、ブラウザプロファイルをクラウドへアップロードせず、端末内に保持すると説明しています。ego lite自体へのアカウント登録も不要です。

公式説明どおりなら、クラウド上のリモートブラウザへ認証情報を複製する方式と比べ、認証データの保存場所を限定できます。

操作結果を後から確認できる

タスク後に関連ページをTask Spaceへ残せるため、エージェントがどのページへ移動し、最終的に何を表示したか確認できます。結果をページ情報やダウンロードファイルから読み戻す運用も可能です。

要件ごとにagent-browserとego liteを使い分ける

一つの総合点で順位を決めると、測定対象と証拠の強さの違いが隠れます。要件別の判断は次のとおりです。

ログイン状態を引き継がない公開サイトの処理はagent-browserへ、ログイン済み画面で人間の介入が必要な処理はego liteへ振り分けます。ego liteを使う場合も、Task Spaceを認証情報の分離境界にはしません。

導入前に確認し、運用中に制御する境界

公式資料が説明する端末内保存、専用タブ、ハンドオフだけでは、すべてのリスクを防げません。

運用で制御するリスク

• ハンドオフ地点へ到達する前に、エージェントが誤った入力を行うこと

• 人間が確認画面の送信先、金額、公開範囲を読み違えること

• Webサイトへ入力・送信した情報が外部へ送られること

• 利用するAIエージェントの構成によって、ページ内容がモデル提供先へ送信されること

• 悪意あるページの指示やプロンプトインジェクションに従うこと

• ブラウザ外のAPI呼び出しやファイル処理は、Task Spaceの制御対象にならないこと

採用前に確認する事項

• Chromeデータの移行によって、エージェントが利用できる権限も強くなること

• Task Spaceを認証情報の分離境界として扱えないこと

• MITライセンスの対象は公開リポジトリの内容で、ブラウザ本体は別配布であること

• 独立したセキュリティ監査の公開結果を、今回の調査で見つけられなかったこと

ego liteは「AIを完全隔離するから安全」なのではありません。

専用タブ、公式資料上の端末内保存、操作の可視化、排他的な操作権、人間の明示的な再開許可によって、AIへ任せる操作と人間が確認する操作を分けやすいブラウザです。

検索、読み取り、要約、候補整理は、要件に合う方のツールへ任せます。送信、購入、削除、アカウント認可は人間確認を既定とし、ハンドオフ時には対象、内容、金額、送信先を確認します。

ツール選定で重要なのは、どちらが常に優れているかではありません。CLI待ち時間、複雑タスクの完了時間と成功率、ログイン状態、人間の介入、保存領域の分離を別々の要件として扱い、タスクごとに使い分けることです。

エンジニアを募集しています！

ここまで読んでいただきありがとうございました！

Algomatic では、「AI革命で人々を幸せにする」をミッションに、変化の速い領域でも 学びや試行錯誤を続けられる エンジニアを募集しています。

もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！

Sources

• agent-browser公式リポジトリ

• agent-browserセッション管理（現在のmain）

• agent-browserコアSkill（現在のmain）

• Real-World Bench比較記事

• ego-browser-benchmark-framework

• Real-World Benchデータセット

• ego liteの4タスク比較画像

• ego liteユーザーガイド

• ego lite公式リポジトリ

• 公式ドキュメント索引

• 公式クイックスタート

• 公式ドキュメント「ego liteとは」

• 公式ドキュメント「Space」

• 公式ドキュメント「Snapshot」

• 公式ドキュメント「ego-browser」

• 公式ドキュメント「Skills」

• ego-browser Skill v1.2.3

• Task Spaceヘルパー実装 v1.2.3

• Task Space E2Eケース

• GitHub latest release