AGI Cockpit｜Browser Identity実測｜Defaultからnote-readerへ

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。

AIにWebの仕事を任せる時、気になるのは「操作できるか」だけじゃないんだよね。

今、どのアカウントでログインしているのか。別の仕事のログインが混ざっていないか。

Defaultだけでnote、WordPress、別アカウントの管理を回そうとすると、仕事を渡す前にログイン先を確認したくなる。必要なら再ログインする。別アカウントで操作しないかも気になる…。これでは、AIに任せても人が横で見続ける形になりやすい。

そこで使うのが、AGI CockpitのBrowser Identityです。

Afterはシンプル。

仕事用のブラウザをIdentityで分ける。タスクやAutorunに「この仕事場を使う」と先に割り当てる。次の仕事でも、同じIdentityを再利用する。

料理に例えると、毎回ひとつの作業台を片づけ直すのではなく、note用、WordPress用、確認用の作業台を分けておく感覚かな。AIへ渡す前に作業台が決まっていれば、ログイン確認のために人が抱え続ける仕事を減らしやすい。

今回はDefaultからnote-readerへ切り替え、保存済みのnoteログインを使い、元へ戻すところまで実測。さらに記事を仕上げる前に、私自身も同じ流れを画面で試し、「試せた・記事へ進む」と回答しています。

感想や時短量。ここには足さない。ここからは、実際に起きたことを土台に、使う人にとって何が変わるのかを見ていきます。

AGI CockpitのBrowser Identity実測。仕事場を先に分ける

Browser Identityは、設定画面に名前を登録しただけでは、まだ準備段階。

実際に使う時は、対象のタスクやAutorunへIdentityを割り当てます。今回なら、タスクのBrowser IdentityをDefaultからnote-readerへ変更。

変更前：Default
選ぶもの：note-reader
変更後：このタスクはnote-readerのブラウザ空間を使う

ここが、利用者にとって一番大きな違いです。

「AIさん、noteを見て」と頼んでからログイン先を探させるのではなく、note用の仕事場を選んでからボールを渡せる。

分け方の基本は、これで十分。

1サービス × 1アカウント × 必要なら役割

たとえば、同じWordPressでもownerとmanagerを分けたいなら別Identity。ログイン中の管理画面と、ログアウト状態の公開確認も別Identity。別会社や別クライアントのアカウントも分けます。

逆に、同じnoteアカウントを見るたびに新しいIdentityを作る必要はありません。note-readerを次のタスクでも再利用する。そのための仕事場なんだよね。

一度用意したログインを、次の仕事でも使える

note-readerを割り当てた状態で、内蔵ブラウザからnoteを開きました。

ログイン情報の入力。なし。

それでも、ログイン後に表示される「投稿」リンクと「投稿メニュー」ボタンがDOMにありました。

しかもね。ログイン必須の通知ページhttps://note.com/notificationsへ移動しても、ログイン画面へ戻されず通知ページが開いたんです。

今回確認できた事実はひとつ。note-readerに保存されていたnoteのログイン状態を、そのタスクで再利用できた。

初回だけは、そのIdentityでログインを用意する必要があるんだよね。Chromeのセッションを取り込むimport-sessionという方法もあります。ただ、今回は未実施です。

でね。一度用意した仕事場を同じIdentityで使う運用なら、タスクを作るたびにログインし直す前提から離れられます。今回の実測でも再ログインはしていません。

違うIdentityの仕事場へは、そのまま入れなかった

次に、タスクの割り当てをnote-readerからDefaultへ戻しました。

その状態で、先ほどのnote-readerのSessionへアクセスしようとすると——Cockpitが拒否。

Browser access denied:
Identity identity-msb0cgjj-8ead59 is not assigned to task 66ebe410

Sessionが消えたわけじゃない。今タスクに割り当てられているIdentityと、開こうとしたSessionのIdentityが違ったため、入れなかったんです。

だからといって、「どんな誤操作も防げる」とまでは言えない。でも、少なくとも今回の実測では、Defaultを選んだタスクからnote-readerのSessionへそのまま入ることはできませんでした。

あ、そうだ。複数アカウントを扱う時に大事なのは、AIへ指示した後で「今どっち？」と確認することだけじゃない。仕事を始める前に、使うIdentityを選ぶこと。

そのひと手間が、誤ったアカウントで作業を始めるリスクを減らす運用になります。

戻せば、同じ仕事場を続きから使えた

では、Defaultへ戻した時にnote-readerの仕事場は壊れたのか…。

もう一度、タスクへnote-readerを割り当てました。

すると、同じSession、同じタブ、同じログイン状態が残っていました。URLもログイン必須の通知ページのまま。再ログインはしていません。

同じ場所へ帰ってきた。

これなら、noteを見るタスクを終えるたびに仕事場を作り直さず、次もnote-readerを選んで続きから使える。

ただし、今回確認したのは同じ実測中にDefaultへ切り替え、もう一度note-readerへ戻した範囲です。アプリ再起動後や長期間経過後まで同じ結果になる、と広げてはいません。

作業後はDefaultへ戻す。保存データは消さない

実測の最後は、タスクをDefaultへ戻しました。

ここで行ったのは、タスクが使うIdentityの変更だけ。note-readerのSessionや保存データは削除していません。

割り当て変更と、データを消す操作は別物なんだよね。

• Defaultや別Identityへ切り替える：タスクが使う仕事場を変える
• clear：対象データを消し、関連Sessionを閉じる操作
• remove：Identityと全データを消す操作

clearとremoveは破壊範囲があるので、「使い終わったから」と軽く実行しない。今回は、どちらも未実施。Chromeからのimport-session、Identityの新規作成・更新、AGI Cockpitのアプリ再起動も試していません。

note側で記事の編集、保存、投稿、公開も行っていません。外向き変更。0件。

名前は権限ではない。役割と指示をセットにする

note-readerやreadonlyという名前を見ると、読むだけの安全なIdentityに見えます。

でも——名前だけで技術的な閲覧専用になるわけではありません。draftと名付けても、公開ボタンが消えるわけじゃないんだよ。

Identity名は、利用者とAIが仕事場を見分ける目印。実際の操作範囲は、タスクの指示と承認境界で決めます。

今回なら、こうしました。

Identity：note-reader
役割の目印：保存済みのnoteログインを再利用する
許可：閲覧状態の確認
禁止：編集、保存、投稿、公開、clear、remove

つまり、Identityで「どのアカウントを使うか」を分け、指示で「何をしてよいか」を決める。この2つをセットにすると、人がすべてのクリックを監視するのではなく、AIへ安全にボールを渡しやすくなります。

中身は、価値を支える裏方

Browser Identityは、Cookie、cache、localStorage、permissions、proxy authなどを別々の永続領域に分けます。

この仕組みがあるから、仕事場ごとにログイン状態を持ちやすい。ただ、利用者が毎回内部構造を意識する必要はありません。

覚えるのは、「仕事場を分ける」「タスクへ割り当てる」「同じ仕事には同じIdentityを使う」。まずはこれで十分です。

最短の始め方。UIでIdentityを選んでから頼む

まずは、よく使うWeb業務を1つだけ選びます。今回のようなnote閲覧でも、WordPressの下書き確認でもかまいません。

UIで試す5手順

1. AGI Cockpitで対象タスクを開く
2. タスクの「Browser Identity」選択欄を開く
3. 使いたいIdentityを選ぶ
4. 内蔵ブラウザで対象ページを開き、想定したアカウントか確認する
5. 次回も同じ仕事には同じIdentityを割り当てる

設定画面はIdentityを管理する場所。実際に使う場所は、タスクやAutorunの割り当て欄です。

Autorunでも考え方は同じ。定期的にWordPressを確認するならWordPress用、ログアウト状態で公開ページを見るなら公開確認用を先に割り当てます。

すぐ使える分け方は、こんな感じ。

CLIを使う場合も、補助操作は短いです。

cockpit task browser-identity note-reader
cockpit task browser-identity default

ぶっちゃけ、Browser Identityの価値は「Cookieを分ける機能です」で終わらない。

どの仕事場を使うか決めてから、AIへ仕事を渡せること。

毎回ログインからやり直さず、同じ仕事場を次も使う。Defaultへ何でも詰め込まず、サービス、アカウント、必要なら役割で分ける。

人が抱えたまま監視する仕事を、少しずつAIへ渡していく。その受け渡しを整えるのが、Browser Identityのユーザー体験なんだよ。

あわせて読みたい

実測条件

• 実測日時：2026年8月26日 15:06〜15:09 JST
• 対象Identity：note-reader（identity-msb0cgjj-8ead59）
• 対象サイト：https://note.com/
• 一次記録SHA-256：04572a4bf6a9060ae09ca201dde2bb0505e0905b3f75ba0132d0767598f06124
• 操作境界：読み取りのみ
• 利用者確認：ひろくん本人が同じ切り替え手順を画面で試し、「試せた・記事へ進む」と回答