ChatGPT Annotationsで画面を指してAIに相談する。人とAIの分け方を動画から整理しました

出典: ChatGPT Annotationsで作る人間とAIの共同作業場（Generative AI and InfoBusiness Institute）

AIに全部を任せたのに、出来がどこか物足りない時がありますよね。あなたはどうでしょうか。では人は、仕事のどこに手を残せばいいのでしょうか。

1から10まで丸投げすると、そこそこのものしかできません。Bossさんはそう話します。そこは多くの人がすでに体感している、という前置きつきでした。だから人がレビューを入れる、という流れです。

Bossさん（動画の中で・3:47〜）

1から10まで全部丸投げしてると、ああの、そこそこのもんしか出来上がらないよねっていうのはね、あの、皆さん体感されてるところだとは思うんですよ。

そのうえで、これまでのやり方が例に挙がりました。AIで叩き台のスライドを作り、PowerPointに書き出して、自分で手直しする流れです。形にするまではAIに頼み、仕上げは人の手で行う形ですね。そこから「これからは違う」と続けます。

話は、2年ほど前の ChatGPT の Canvas にも及びました。結論は、Annotations を使うと人間とAIの共同の作業場を自分好みに作れる、というものです。

私は、丸投げそのものが悪いとは思っていません。任せられるなら、できるだけ任せたいのが本音です。人が毎回あとで手直しする前提のほうが、私には重たく感じます。

先に決めたいのは、出す・止める・任せるの境界です。どこまでなら、そのまま出してよいでしょうか。どこで止めて、見直しますか。そこが決まれば、実行から確かめまでを委ねられます。

境界を決めるのは、人の手に残す最後の一手です。私はそう考えています。できあがった形を見て、温度が合っているかを身体で確かめます。その確かめ方を人が持っているから、残りを安心して渡せるんです。

人が縦に掘るのは、意図と違和感です。何を伝えたいのか、どこがしっくりこないのか。そこは私が持ちます。並べる、作り直す、数をそろえるのは、AIやコードに横へ広げてもらえば十分ですよね。

動画の例で気になったのは、PowerPointに書き出して外で手直しする流れでした。この形だと、どこをどう直したかがAIの側に残りにくく、次に頼む時に同じ直しをまた一から伝え直すことになりがちだと私は見ています。困りますよね。

だからこそ、Bossさんの言う共同の作業場に私は惹かれます。直す場所が同じ画面の上にあれば、人が見た所とAIに渡る所をそろえる足場になります。任せる前に何を決めておくかは、dotsに仕事を頼む前に決めておくことをまとめた記事にも書きました。

人は、全部を見張る役ではないんですよね。境界を先に決め、その内側は実行から確かめまで任せます。ここが分かれ目です。私はこの分け方で、人の手を残す場所を選んでいます。

直してほしい所を、あなたはAIにどう伝えていますか。文章で丁寧に説明すれば足りると思いがちですよね。本当にそれで届くのでしょうか。

共同作業とは共有すること、とBossさんは語ります。見ている「ここのこれをこうしたい」を正確に伝えられるようにする仕組みが Annotations だ、という説明でした。

Bossさん（動画の中で・12:47〜）

見ているところ、え、ここのこれをこうしたいっていうね、その情報っていうのを正確に伝えることができるっていうね、そのためのあの、ま、プロダクトというか仕組み、ま、それがね、アノテーションです。

後半では、Red Runner（動画のAIキャラクター）が Annotations を解説しています。画面上の文章や図などを選び、コメントと一緒に会話のAIへ渡せる機能だそうです。

例に出たのは、レポートの図を直したい場面でした。Red Runner によると、「2番目の章の右にある青い図のこの項目」と言葉で説明する代わりに、その対象を指して相談できます。見ているものをそのまま渡せる見せ方ですね。

私にも、これに近い場面がありました。10月12日、別の動画の紹介記事で、見出し画像を直してもらおうとした時です。私は「CSVと入っている見出し画像」と言葉で指しました。

ところがAIは、本文の文のほうから直していました。画像からではありません。あとでAIが答えた直し方は、文字の誤りと本文との食い違いだけを見る基準です。絵の見せ方までは、見直していませんでした。

同じ答えの中でAIは、「この画像のここ」と指してもらうのが最短、と書いています。指せば早い、という見立てですね。ただ、Annotations があれば防げたとは言い切れませんし、指す精度と全部の対象を確かめる仕組みは、そもそも別ものなんです。

言葉で指すと、受け取る側は言葉に近い所から探しにいくと私は考えています。CSVの語が入っていれば、まず文字を探しますよね。画像の中身より、本文の文のほうが言葉としては近くにあります。入り口がずれやすいのは、そのためでしょう。

図や画像の中の一点は、文章で書くほど長く、あいまいになります。言葉だけで場所を渡されると、手がかりが少ないんですね。指してもらえれば、迷う幅はぐっと狭まります。差は大きいですよ。

ずれが起きると、人は同じことを言い直す側に回ります。どの画像か、何を見てほしいか、どの基準で直すか。言い直すたびに、管理のボールが人の手へ戻ってきます。これはつらいですよね。

指す入り口は、正確さを競うための物ではないと私は考えています。私が同じことを言い直す回数を減らすための物です。そこが減った分だけ、何を任せてどこで止まるかの判断に手を戻せます。本当に考えたいのは、そこですから。

画面を指してAIに頼めるのは便利ですよね。では、そのしくみのどこまでが最初から入っていて、どこから先をアプリの側で作るのでしょうか。境目が見えると、自分の仕事への持ちこみ方も考えやすくなります。

Bossさんが見せたのは、自作の Diagram Report Studio です。Codex アプリの中のブラウザーで動かしていました。始まりは、文章から図解を出してくれる Napkin AI のクローンを作れないか、と思ったことだったそうです。

文章を流しこむと、図解入りのレポートになります。図の右上の「AIに相談」を押すと注釈の画面が開き、配色や図解の種類、図の形、余白、文字サイズが並びます。図の形は、ループや歯車、階段にも変えられます。

14:53の画面には、Codex の答えが文字で出ていました。「AIに相談」ボタンはこのアプリの実装です。黒い注釈の画面とコメント欄、送信ボタンは標準で、配色や余白の項目と最初の依頼文はアプリが足した物でした。

Red Runner は、これを Annotations Extensibility の話として整理します。何を選べるか、何を添えるか、どんな調整項目を出すかを、アプリ側で決められます。公式の説明でも、選べる対象の宣言と独自の操作の追加ができるとあります。

私がこの章で見てほしいのは、標準と独自の境目です。指して、コメントを付けて、送ります。ここまでは標準ですね。何を選べるようにするか、何を一緒に渡すかは、画面を作る側が決める仕事なんですね。

この境目を分けずに見ると、全部を自作しないといけない気がしてきます。逆に、全部が最初から入っていると思いこむ人もいるでしょう。どちらも、自分で手を入れる場所を見失ってしまいます。惜しいですよね。

私が一番いいと思ったのは、調整項目が先に並んでいる点です。これは大きいですね。選ぶ物が目の前にあれば、頼み方が言葉の上手下手に左右されにくくなります。配色も余白も、押して選べばいいのですから。

最初から入っている依頼文も、アプリの設定でした。ここも作る側が書ける場所です。よく頼む言い回しを先に置いておけば、毎回ゼロから書かずにすみますよね。これは助かります。

言葉だけで図を直してもらうと、どの言い方なら通じるのかを毎回探すことになり、人が毎回手直しする前提からなかなか抜けられません。項目があれば、頼む側の迷いがひとつ減ります。ここが違いですね。

委ねるなら、人が選ぶ所と任せる所の線を先に引いておきたいと私は考えています。調整項目は、その線を画面の形にした物です。ここは人が選び、その先は任せます。線が見えていると、委ねやすいですよね。

人間は、自分が何をしたいのか、どこに違和感があるのかを深く確かめます。AIは、その意図を受けて案を横に広げます。持ち場が違うんです。項目を決めることは、確かめた意図を渡すための器づくりでもありますね。

ただ、項目が並んでいても、人が指した図とAIが触る図がずれていたら意味がありません。そこを揃えるのが、次の章で見る同じIDの話です。指す場所と渡す中身を、画面を作る側が自分の仕事に合わせて一つずつ決められることこそ、手間をかけて自作する値打ちだと私は考えています。

人が画面で指した図を、AIが別の図と取りちがえないのはなぜでしょうか。試しに変えた色や形が、気づかないうちに残ってしまう心配はないのでしょうか。

Red Runner によると、このアプリはレポートを1枚の画像にしていません。本文と図、図の中の項目を、編集できるデータとして持たせています。図や項目には、それぞれ識別のためのIDがあります。

Red Runner（動画の中で・18:48〜）

人が画面で選んだ項目とAIが操作する項目を同じIDで結びつけるためです。

操作には、データを読む、文字や形を変える、保存するがあります。この操作をAIへ公開するのは WebMCP の役目です。人の編集画面とAI向けの編集ツールは、同じ編集の処理を通ります。

公式の説明では、Site tools は提案段階の標準 WebMCP の ChatGPT 側の実装です。内蔵ブラウザーからサイトの道具を呼ぶ物とされています。一方、同じIDで結ぶのは、このアプリの作り方の話です。

Red Runner はさらに、変更を試すプレビュー、編集データへの適用、ファイルの保存を分けました。試す・入れる・残すが、それぞれ別の操作になっています。

Red Runner（動画の中で・19:36〜）

変更を試すプレビューと編集データへの適用とファイルの保存を分けました。試しただけの見た目をうっかり保存済みにしないためです。

私がこの章で大事にしたいのは、同じ物を同じ名前で呼ぶ筋です。人は画面を見ています。AIはデータを見ています。だから、間にひとつの名前が要りますよね。

10月2日、私は、AIが出す成果物のページはどこを見ればいいかが毎回分かりにくい、と伝えました。それから、AIが作る成果物のページには、全ての見出しに英字のIDを付けてもらう決まりにしました。

報告では、ページのURLの後ろに「#ID」を付けて、見てほしい節を1行ずつ書いてもらいます。出す前には、AIがそのURLを開きます。見出しが画面の上端に来るかも、AIが確かめる決まりですね。

「#ID」付きのURLでも、ページ内のリンクを押しても、その見出しへ飛ぶことは、10月2日にAIで確かめています。

向きは動画と逆です。動画では、人がAIに向けてここを指します。私の決まりでは、AIが私に向けてここを指します。それでも、同じ物を同じ名前で呼ぶ筋は変わらないんですよね。

名前がずれていたら、どちらの向きでも話はかみ合いませんよね。見出しの言葉は、書き直されることがあります。英字のIDなら言葉が変わっても同じ節を指せるので、図や項目にIDを持たせる作りと考え方は同じだと私は見ています。

ただ、IDで正しく指せることと、全部を確かめたことは別の話です。指す精度が上がっても、漏れがないかは別のしくみで調べます。枚数やIDの一致は、人の目ではなくコードに数えてもらいたいところです。

プレビューと適用と保存を分けておけば、見るだけの段で何度でも試せます。気に入らなければ、適用の前で引き返せばいいんです。試すことに身構えなくてすみますね。

実行まで委ねたいからこそ、止まる場所は先に作っておきたいと私は思います。プレビューと適用と保存を分ける作りは、試した変更を本番に残さないための止まる場所です。ここは外せません。

AIを仕事に入れると、どこまで任せていいか迷いますよね。判断までAIに渡すのか、決まった処理はコードに回すのか。その線は、どこに引けばいいのでしょうか。

Red Runner によると、Bossさんからは「LLMの出番をできるだけ少なく」という条件が出ていました。そこで使ったのが、TypeSafe のAIモデル Jev です。Jev は文章を読み、用意した選択肢や確率で判断を返します。長い文章を書く役とは、使いどころが違うんですね。

今回 Jev が受け持ったのは、内容が手順か比較か、項目に順序があるか、の判断です。原稿から項目を取り出す所や、図の配置・線・色はコードの持ち場です。判断があいまいな時は、人が選び直せる一覧が出ます。画面には「文章生成LLM 0回」とありました。

Treg は、外部のツールやAPIを探し、使い方を確かめ、利用につなげるサービスです。この図解アプリでつないだのは、公開カタログの検索、仕様の確認、参考サービスの登録までです。画像や動画を作る外部サービスの実行は「まだ入れていない」と、Red Runner ははっきり言っていました。

公式の説明では、Jev は状態と型の決まった質問に、形の決まった答えを返すモデルです。Treg の公式文書には、1つの窓口でAPIを探し、実際に呼び出すところまで扱えると書かれています。動画のほうは、このアプリでどこまでつないだかの話ですね。

Red Runner（動画の中で・21:01〜）

共同作業のために全ての操作で大きなAIを呼ぶ必要はない。必要な判断と繰り返し使う編集機能を分けた設計です。

この分け方に、私は賛成です。意味を読んで選ぶ所は、AIの出番でしょう。数えて、並べて、保存します。ここは毎回同じ結果が出るコードのほうが向いています。

10月4日、アンケートの自由記入とメルマガへの返信の実物50件で、Clef-flash・Clef・Jevの正解数をAIに比べてもらいました。同じ質問、同じ正解で並べてもらっています。私がしたのは、比べると決めて結果を見たことだけです。Jevは、文章を書かずに、選ぶ・分ける・はい／いいえを返す役です。

Jevの分は、9月21日にAIで回した結果です。差は0〜4件でした。比べ方の中身はClefとJevを並べて比べた記事にまとめています。

判定の役を小さく切り出すと、比べることができます。同じ正解で数えられるからです。長い文章を書く役だと、こうはいきませんよね。これが切り出す良さですね。

数える所の話でも、私の手元にひとつ例があります。10月12日、書評記事の図解13枚とアイキャッチをAIに作り直してもらいました。見比べのページには、目立つ5枚だけが並んでいました。

並べなかった1枚に、使ってはいけない決まりのカッコが残っていたんです。作ったAIも、別のAI（Codex）の検収も、そこを見落としていました。

それからは、見比べページを作るスクリプトが、並べる枚数を記事の中の画像の数と合わせる作りになっています。合わなければ止まります。単純ですよね。

枚数を数えるのに、大きなAIは要りません。見るのは、記事の中の画像の数と並んだ数が同じかどうかだけです。それで足りるでしょう。Red Runner が配置や線をコードに回したのと、同じ筋だと私は考えています。

成果物を人が一件ずつ止めて合否を出す形を、私は目指していません。止めるのは、枚数が合わない時や、判断があいまいな時です。その場所を先に決めておけば、ほかは流してかまいません。止める場所を決めてから任せる、この順番で私は委ねます。

自分の仕事にも、AIと相談する入り口を作ってみたくなりますね。そう思った時、何から考えればいいのでしょう。画面を作る前に、決めておくことがありそうですよね。

最後に Red Runner は、スライドの中で作業デモを見せます。説明文からレポートを作り、図のここを直したいと指して、コメントで「内容はそのままで文字を大きくして余白を広く」と頼む流れです。

デモでは、レポートを読んだAIが図のIDを指定し、WebMCP 経由で文字サイズと余白を変えていました。変わったのは、指定した所だけです。そのあと編集画面で色や図の形を試し、合わなければ戻して整えていました。

応用の例として、文章ならこの段落、企画ならこの案、資料ならこのグラフ、と Red Runner は挙げます。そして、人とAIの共同作業場を自分の手で作れる時代になった、と結んでいました。

Red Runner（動画の中で・23:57〜）

自分がよく使う画面にAIと相談する入り口を用意する。そこにその仕事で必要な編集操作を[つなげる]。

入り口は、仕事ごとに違ってよいと私は考えています。文章を直す人と図を直す人では、指したい場所が違いますよね。まず決めたいのは、自分が何を指して相談したいのかです。

私の手元では、絵で見て決める確認は赤ペンのシートで返してもらいます。文面の確認と、公開・送信・削除などの最終判断は、今までどおり確認の通知です。入り口は二つですね。

この形に決める前の10月7日の夜、同じお題・同じ2問で、html-plan と赤ペンのページをAIに1枚ずつ作ってもらい、見比べました。私が選んだのは「赤ペンの方がよい」でした。

そのあと、この案で採用しています。設計の分かれ道、画面の配置、実装の計画などが、赤ペンのシートに回る確認です。比べた時の様子はhtml-planと赤ペンを並べて試した記事に残しています。

答えは、シートで作った文を自由入力に貼って返す形です。絵で決めるものと、言葉で決めるもの。どちらで返すかは、確認の中身で決まるんですね。

Bossさんのアプリでは、図を指す先が決まっていました。だから文字を大きく、余白を広くという頼み方が、そのまま通ったのでしょう。何を指すかが決まると、渡すものもはっきりします。

頼む範囲は、広げてかまいません。直す所も、試す所も、合わなければ戻す所も任せられます。私はそこまで委ねたいと思っています。

それでも、保存や公開の手前には人が止まる場所を残します。実行を委ねるほど、ここで止まると決めた一点が効いてきます。私はその一点を手元に置いたまま、残りを任せます。

私が伝えたかったのは、人とAIが同じ物を見ているかを先に確かめてから任せよう、という一点です。指す精度を上げることと、全部を確かめる仕組みは別に用意します。そのうえで試す段と残す段を分けておけば、AIに渡せる範囲は広がります。

Red Runner が見せた、図や項目の一つずつにIDを持たせる作りは、文章にも表にも通じると私は思います。段落でも、表の一行でも、図の中の一項目でも、言葉が変わってもぶれない名前があれば、人とAIの話はかみ合いますよね。

止まる場所も同じ考え方です。見るだけで済む段と、本番に残る段の境目が決まっていれば、手前ではいくら試してもかまいません。数える仕事はコードに回せば十分でしょう。人が持つのは、意図と違和感を確かめるところです。

私は、人が全部に目を光らせる形より、止まる一点を決めて残りを預ける形を選びます。頼み方を磨くより先に、同じ物を同じ名前で呼べる場を整えます。そこから、委ねる幅を広げていくつもりです。