AI分析9分で読めます

完璧なプロンプトを書く前に、Loomで直したい箇所を見せよう

LoomのRecord for agentは短い画面録画をAIへの依頼書に変えます。公開ベータが不具合報告やデザインへの意見、実行前の確認をどう変えるか考えます。

K
Ken Jo

問題は一目で分かります。試作ではフォームの下にあるボタンが、アプリでは横にあり、スマートフォンではエラー文のせいで両方とも見えなくなる。これをAIのコーディングエージェントへ正確に説明するには、人に見せる以上の時間がかかることがあります。

2026年10月22日、AtlassianはLoomの複数の更新を発表しました。その一つが、説明付きの画面操作をAIへの指示に変える録画モードRecord for agentです。同僚に仕事の様子を見せる非同期動画ツールLoomが、その習慣を次の仕事を実行するソフトウェアにも広げます。サポート文書では、Business + AIとEnterprise向けの公開ベータで、録画は最大5分とされています。発表、現在の要件。

注目点は、エージェントが動画を受け取れること自体ではありません。慣れた録画から、確認、編集して渡せる依頼書を作れることです。最長のプロンプトを競うより、引き継ぎの質を実務の問題として扱えます。

白い背景の中央に置かれたLoom公式の青いロゴ。 製品を識別するためのLoom公式ロゴです。Record for agentの画面ではありません。ロゴ:Loom / Atlassian。商標使用方針。

録画は、文章で抜け落ちる情報を運べる

有用な不具合報告には「フォームが壊れている」以上の情報が必要です。開始時の状態、問題を起こす操作、期待した結果、実際の結果です。スクリーンショット、コピーしたURL、チャットに分散していれば、修正前に関係を組み直す必要があります。

Loomの文書では、音声の指示、画面のキーフレーム、操作イベント、閲覧リンクを組み合わせます。Chrome拡張機能はコンソールメッセージやネットワークリクエスト、レスポンスのメタデータも取得できます。デスクトップ版には、画面上の該当部分へ注意を向ける選択・描画ツールがあります。これらは依頼書の材料であり、修正案が機能する証明ではありません。取得内容の詳細。

私たちは、これにより伝達の単位が変わると考えます。画像は状態を、文章は意図を示しますが、短い操作説明は、ある状態をどう別の状態へ変えたいかを伝えられます。生成された依頼書は、その説明と実行可能な仕事をつなぎます。

録画を、文脈を詰めた小包と考えるとよいでしょう。必要な情報をそろえ、それ以外は最小限にします。5分の制限は、一つの問題、その影響、明確な完了条件に絞る助けにもなります。

説明付き画面録画から指示の確認、仕事の委任へ至る四つの段階。 独自制作の引き継ぎ解説図。依頼書の確認と、エージェントによる作業実行は別の段階です。

望ましい動作を見せると、デザインの意見を伝えやすい

購入手続き画面を調整するチームを考えます。想定例では、デザイナーが承認済みレイアウトと現在のアプリを開き、三つの違いを示します。狭い画面で配送選択肢が消える、合計金額の更新が遅い、確認文の強調が違う、というものです。価値があるのは見た目だけでなく、二つの画面の関係です。

生成されたプロンプトの確認者は、各観察を動作の条件へ直すべきです。同じ瞬間を見ていないエージェントにとって「これを動かす」は曖昧です。「狭い画面で配送方法を変えた後も合計金額を見える状態に保つ」なら、検証する結果が分かります。

デザインファイルと動くページをまたぐ変更では、特に便利です。Loomの例にも、Figmaとウェブサイトを行き来してUI変更を説明する流れがあります。参照画面を残せても、どれを正しい基準とするかはチームが決めます。整った試作でも、読み込み、エラー、権限の状態が省かれているかもしれません。対応する作業例。

そのため、守るべき条件を一文加えましょう。購入画面なら、合計が選択した配送方法と一致することや、変更した入力欄にキーボードのフォーカスが残ることです。こうした条件は見本に描かれにくく、枠線の位置以上に重要です。

製品内の文言にも同じ方法を使えます。実際の表示場所で文を見せ、誰が読み、どの判断を助けるべきか説明します。初回案内の流れを録画すれば、一文の抜粋では分からない不自然な移行も伝わります。

不具合報告には、再現できる始点と確認できる終点が要る

二つ目は、繰り返される問い合わせです。デスクトップでは文書をアップロードできるのに、小さな画面では進捗表示が空になるとします。短い録画で、ファイル形式、選択操作、画面の移行、表示が消える地点を残せます。

それでも依頼には完了の定義が必要です。「アップロードを直す」だけでは、ファイル拒否、通信応答の不足、成功結果の表示失敗のどれか分かりません。観察した症状と推測した原因を分けた依頼書のほうが役立ちます。

最初の依頼は、表示の欠落を再現し、担当層を特定し、回帰確認付きで変更を提案する範囲に絞りたいところです。その後サーバーエラーが見つかれば、証拠を基に調査を広げられます。レイアウトの相談を、黙ってアップロード全体の作り直しへ変えるべきではありません。

ログを読むのが苦手な人にも利点があります。先に診断せず、壊れた操作を見せられます。技術者やエージェントは取得した文脈で調査でき、元の観察は修正後の比較用に残ります。

録画がテストケースを置き換えるわけではありません。録画は人が出会った状況を保ち、テストはソフトウェアが満たし続ける動作を示します。良い工程は、前者を適切な後者へつなげます。

プロンプトのコピーとJiraタスク作成は、別の入口になる

公開ベータはChrome拡張機能、またはバージョン2.0以降のデスクトップアプリから使えます。文書は基本のプロンプト作成とJiraの作業項目作成を分け、後者にはAtlassian管理アカウントと有効なJira契約が必要としています。プロジェクト管理を変えずに試したい小さなチームには重要な違いです。提供条件と設定。

最も簡単な試験は、よく理解しているプロジェクトで影響の小さい仕事を一つ選ぶことです。

  1. 対象のデザイン、公開テストページ、開発環境を開き、説明できる開始状態を用意する。
  2. 対応するLoom録画機能でRecord for agentを選び、関連操作を見せながら変更を一つ説明する。
  3. 5分以内に停止し、生成された作業計画を最初から最後まで読む。
  4. 曖昧な参照を直し、無関係な資料を除き、具体的な受け入れ条件を加える。
  5. プロンプトをMarkdownとして選んだエージェントへコピーするか、アカウントに対応する引き継ぎやJiraの方法を使う。
  6. 変更を受け入れる前に、元の場面に照らして結果を確認する。

この順序なら、最初の試験を理解しやすく保てます。明確な依頼の準備時間と、その後の確認質問の数を比べれば、機能が役立つかも判断しやすくなります。

エージェントが速く終えるだけでは不十分です。同僚が変更内容と、それが元の観察をどう解決するか説明できなければ、引き継ぎには改善の余地があります。減らしたいのは確認そのものより、文脈の再構成です。

文脈が豊かになるほど、共有の判断も丁寧に行う

技術情報が役立つのは、画面だけでは経緯が分からないことがあるからです。失敗した要求、予想外の転送、コンソールエラーが、見た目とは異なる原因を示す場合があります。同じ情報に、別のツールへ送りたくない内容が含まれることもあります。

録画前には対象のテストページを使い、仕事の範囲を明確にします。録画後は、生成された依頼書にアカウント固有URL、顧客ID、不要なログがないか確認します。取得項目の一覧を踏まえ、普通の画像添付と同じ扱いにせず具体的に点検しましょう。

目的は、解決に必要な情報を残すことです。許可されたサーバー記録を探すためのリクエストIDなら役立つかもしれません。無関係なURLの一覧や、たまたま映った個人通知は、UI作業の依頼にほとんど価値を加えません。

引き継ぐ入力説明できること確認者が判断すること
音声による指示変更の意図と重要な理由実装できるほど具体的か
キーフレームや選択要素関係する画面状態や部品関連し、共有権限のある文脈か
クリックと閲覧リンク操作の経路元のセッション以外でも再現できるか
Chromeの技術メタデータ画面の背後で失敗した処理の手掛かり必要で、共有に適しているか

これは確認のための問いであり、追加の製品権限や、全情報が毎回タスクに含まれるという約束ではありません。実際に送る依頼へ何を含めるか、チームが決めるためのものです。

画面の取得とエージェントの実行の間に置く三つの問い:範囲、文脈、受け入れ条件。 有用な確認では、何を変更してよいか、どの情報を渡すか、結果をどう評価するかを点検します。

最初に測りたいのは、説明がどれだけ残るか

少なくとも三つの使い方で手間を減らせそうです。デザイナーは長文を書かず見た目の違いを伝えられます。サポート担当は記憶が新しいうちに操作を残せます。開発者は、参照と期待結果が明確な仕事をエージェントへ渡せます。

それぞれ失敗の形も違います。デザインの意見は正常系以外の動作を落としやすく、サポートの録画は他の人に再現できないアカウント状態に依存するかもしれません。開発者の録画では、細部が多すぎて本題を見失うことがあります。

最初の評価では、慣れた仕事をいくつか選び、エージェントとリポジトリは同じにします。依頼書に必要な修正、確認質問の頻度、最終変更が条件を満たすかを記録します。動くカーソルの単発デモより、伝達品質が分かります。

出力の質と仕事の難しさも分けましょう。簡単な文言修正は、ほぼどんな依頼でも成功するかもしれません。読み込み状態、狭い画面の配置、ツール間の移行など、小さくても文脈が効く仕事のほうが参考になります。それでも、戻しやすく担当者が確認しやすい範囲にします。

人から人へ録画で仕事を説明する習慣があるため、Loomはこの方法を広めやすい立場です。その明瞭さをエージェントにも持ち込めます。一方で、入力が豊かなら達成すべきことを言わなくてよい、と思い込む危険もあります。

良い依頼書は、別の人にも理解できる

Record for agentは、すべての画素を文章で説明するより、見せるほうが効率的な出発点になるという、筋の通った選択です。元の観察と受け入れた変更がつながり、人にもエージェントにも分かりやすい仕事になれば理想的です。

次の録画を送る前に、その場にいなかった人でも成功の条件を説明できるか、問いかけてください。できれば有用な依頼書です。できなければ、次に改善すべきなのはコードより先に指示です。

出典

元資料と確認済みノートを一緒に残す

Telli.shは、自分が利用を許可された録音の元資料と確認済みノートを一緒に保管するための、独立した場所を提供します。音声ノートから始める。


← ブログに戻る