活用例
許可されたブラウザー自動化
ブラウザー自動化では、機能よりも信頼の扱いが問題になりがちです。スクリプトが作業できるかだけでなく、何へのアクセスを認めるか、実行時の責任を誰が持つかが重要です。
具体的な作業
チームは、権限のある業務の反復作業を自動化します。エクスポート機能がない管理画面からのレポート取得、ページの表示確認、定期的なセッション更新、回帰テストの実行などです。実行を依頼する主体は、人からエージェントへと広がっています。
普段使いのブラウザーでは難しい理由
自動化のアクセス権は、すべてを許可するか、何も許可しないかになりがちです。ブラウザーを操作できるスクリプトは、その中のCookieをすべて読めることが多く、保存済みの認証情報を渡せば、本来の管理範囲の外に持ち出すことになります。自動操作がセッションの所有者自身の操作に見えるため、実行者も分かりにくくなります。問題が起きても、どのスクリプトが誰の権限で何を行ったかの記録が残っていないことがあります。
Isolineでできること
自社製を含め、すべての自動化クライアントを信頼しない前提で扱い、秘密情報ではなく参照情報を渡します。
- 呼び出し側の自己判断ではなく、コントロールプレーンが範囲を限定し、取り消し可能な認可を発行します。
- 通常の出力には参照情報と秘密情報を除いたメタデータを使用し、生のCookie、パスワード、プロキシ認証情報、二要素認証の秘密情報、鍵を含めません。
- 契約で定める値は型付きの閉じた語彙とし、翻訳しません。呼び出し側は説明文を解析せず、シリアライズされた応答を検証できます。
- 操作を実行者の識別情報と付与された権限にひも付け、自動化した作業の責任関係を明確にします。
ワークフローを整える
- 許可された作業と、必要なワークスペース権限を持つプロファイルを選びます。
- インストール済みバージョンに対応した開発者向けインターフェースを使用してください。ローカルのライフサイクルAPIは管理アプリ専用です。
- Cookie、パスワードなどの秘密情報を含めずに、操作の結果を記録します。
この用途での利用権限について
「許可された」とは、対象システムの利用規約、API方針、または明示的な合意で自動化が認められていることを指します。プラットフォームのルールに反するスクレイピング、利用回数やボット検知の制限回避、使用権限のないアカウントへの自動アクセスは含みません。