- 日常業務の中で、同僚からテキストをスクリーンショットにして送られてくることが頻繁にあり、これはコード検索やコンテキスト把握を極めて難しくする非効率なやり方
- スクリーンショットで受け取ったコードは、変数定義、モジュールの場所、例外処理などの文脈がまったく分からず、検索欄に一つひとつ打ち込むか、コーディングエージェントを使うしかない
- ビルドエラーログをスクリーンショットで送られると、何をビルドしたのか、どの行で失敗したのか、正確なエラーメッセージが分からず、問題解決が不可能になる
- テキストのコピー＆ペーストやファイル/GitHubリンクの共有を使えば、IDEの検索機能を活用でき、全体のコンテキストも確認できる
- 画面表示に関する問題でない限り、テキストはスクリーンショットではなくコピー可能な形で共有してこそ、共同作業の効率を確保できる
スクリーンショット問題の事例 1: コード
- 同僚とコード関連の課題を議論する際に、コードのスクリーンショットを受け取ることがある
slug 変数の定義、baseUrl の生成方法、ドメインをハードコードしている理由、例外処理の方法、そのモジュールの場所など、重要なコンテキストをまったく把握できない- スクリーンショット内のコードを検索欄に手で打ち込むか、コーディングエージェントを使って関連モジュールを探さなければならない
- コピー＆ペーストを使えば、同じ行でもより多くのコンテキストを確認でき、IDEの検索機能にもそのまま貼り付けられる
- ファイルそのものやGitHubリンクを共有するほうが、はるかに効率的
スクリーンショット問題の事例 2: ビルドエラーログ
- 「ビルドに失敗したのですが、確認してもらえますか？」という依頼とともに、エラーログのスクリーンショットが送られてくる
- 何をビルドしたのか、どの行で失敗したのか、正確なエラーメッセージが何なのかがまったく分からない
- 自分のワークステーションでフルリビルドすると成功してしまうケースもある
- エラーログ全体をコピーするか、ログをファイルにダンプして送れば、簡単に解決できる問題
正しいテキスト共有の方法
- テキストをスクリーンショットで送らず、コピー可能な形で共有すること
- スクリーンショットは、画面表示の見た目の問題を示したい場合や、純粋なテキストでは失われる関連情報がある場合にのみ使う
- ファイル共有やGitHubリンクの提供が、コンテキスト把握とコード検索のための最善の方法
4件のコメント
エディタ上で表示される読みやすさや、OSが標準で対応しているキャプチャ用ショートカットの手軽さから、コードをキャプチャして投稿することもありますが
ショートカット一発で、キャプチャした画像内のコードを外部共有できる Text fragments などのリンクに変換して、そのまますぐ貼り付けられるプログラムがあれば、それを使うと思います。
Slack に投稿したときにプレビュー表示されて、リンク先に入ればコードをコピーできるようなもの
注目を集めてみようと思って、コードを見栄えのいい画像スクリーンショットに変えてくれるサイトを置いておきます。
https://ray.so/
私もメッセンジャーやメールで何か送るときは、できるだけテキスト中心で使うようにはしていますが、実際には場合によってはテキストだけを使うほうがかえって不便なこともありますよね。
それに比べると、スクリーンショットのキャプチャはショートカットキーをひとつ押して画面をさっと範囲選択し、そのまま貼り付けるだけでGUI上で処理できるので、送る側としてはより楽だと感じるのでしょう。
ですが本文でも指摘されているように、受け取る側にとってはスクリーンショットだけでは文脈が十分に伝わらないことも多いですし、検索やコピー＆ペーストもしづらいので不満が出るのだと思います。データ転送や保存に本来必要なものよりはるかに大きなオーバーヘッドが生じるという点はさておき。
まあ個人的には、こういうことを一つひとつ言い出すなら、社内で内部ドキュメントをWikiではなくWordファイルで作る、といったあたりからして不満ではあるのですが……
Hacker Newsの意見
他のコメントでも触れられていたように、Appleプラットフォームの自動OCRは本当に画期的だと思う
こうした機能は、すべてのプラットフォームのドキュメントビューアに標準搭載されるべきだと思う
もう一つ望みたいのは、スクリーンショットにメタデータを含めることだ。たとえばInstagramの画像をキャプチャしたらそのURLを含め、ブラウザでは現在見ているURLとDOMパス、地図アプリでは座標、PDFビューアでは文書のSHA1ハッシュとオフセットを含める、といった具合だ
もちろんプライバシーの問題はあるだろうが、こういうアイデアはすでに学術界で扱われていそうだと思う
最近ではファイルという概念が抽象化されていて、スクリーンショットがモバイルコンピューティング時代の共通言語になったように感じる
ちなみに Screenshot Conf にもぜひ触れておきたい
スクリーンショットはOSレベルで処理されるので、アプリが自分が撮られたことや位置情報を知るようになるのは危険だ
EvernoteやCloudAppのような企業も試みたが、結局うまくいかなかった。スクリーンショットはシンプルだからこそ役に立つ
私が作っているシステムではURLに多くのコンテキスト情報を持たせているのに、スクリーンショットにはそれが含まれない
そのため、いつもURLをテキストで別途要求しなければならない
スクリーンショット後のUIにAIインサイト、商品検索、Gemini/LLMとの会話のような機能を入れている
誰もがスクリーンショットを情報の保存や検索に使っているからだ
だが、人々がワープロとして使ってしまうことを恐れて、製品版では削除された
私はスクリーンショットをよく使うほうだ
理由は、80文字幅を保てて可読性が高く、等幅フォントやシンタックスハイライトもそのまま保持されるからだ
コードやターミナル出力がメールやモバイルチャットで崩れないようにするには、スクリーンショットがいちばん確実だ
もちろんファイル全体が必要なときは添付するが、関係する部分はスクリーンショットでも一緒に送る
スクリーンショットは拡大しないといけないし、アクセシビリティの面でも不利だ
テキストで送れば検索もコピーもしやすい
ほとんどのシステムはすでに等幅フォントをサポートしていて、問題はむしろGmailのレンダリングのような環境要因だ
Gmailには幅制限もなく、フォントサイズもばらばらで読みにくい
長いURLや広い画面では、むしろ可読性の低下がひどくなる
色やフォーマット、文脈がそのまま見えるからだ
問題を説明するときには、**「百聞は一見にしかず」**という言葉が当てはまる
そのほうが自分のエディタでフォント、幅、色を好みに合わせて見られるし、検索や編集もできる
スクリーンショットは結局、相手に不便を強いることになる
MacとiOSのテキスト認識とコピー機能は本当に革新的だ
スクリーンショットや写真内のテキストをそのままコピーしてメモに貼り付けられる
あの瞬間、本当に未来に生きている感じがした
Safariでは画像内テキストの翻訳もでき、特に日本語のWebページ翻訳に便利だ
ファイル保存なしでそのまま処理できるので便利だ
昔はスクリーンショットをWord文書に貼って送っていた
でも今になってLLMでテキストを再抽出しようという提案は、あまりにも無駄だ
結局必要なのは、テキストをスクリーンショット並みに簡単に共有できるUIの革新だ
プログラマー志望の人たちがこういうことをしているのを見るともどかしくなる
文書の中に別のWordファイルを実体オブジェクトとして貼り付ける形だった
私が書いた『Slackで助けを求める方法』の7つ目のルールは、**「テキストのスクリーンショットを貼らないこと」**だ
AppleのOCRが優れていても、検索できないという問題は依然として残る
原文リンク
私は文書全体やコードへのリンクを一緒に送りつつ、関連部分のスクリーンショットも添えるやり方を好む
視覚的な文脈が残るので、あとで見返したときに記憶に残りやすい
新人開発者は最初の数週間、よくテキストのスクリーンショットを共有する
だがモバイルでは読みづらく、Slackは画像を圧縮するので拡大もできない
そのため結局、多くはテキストで共有する方法を学ぶようになる
MS Teamsではコードブロック対応がひどく貧弱なので、スクリーンショットが使われることが多い
機能自体はあるが、あまり目立たない
スクリーンショットは速くて一貫した方法だ
Webアプリでもネイティブアプリでもサイトでも、どこでも同じやり方で動く
受け手には不便かもしれないが、送る側にとっては効率的だ
私はLinuxでxfce4-screenshooterのカスタム動作をtesseract OCRスクリプトにつないでいる
選択範囲をキャプチャすると、自動的にテキストがクリップボードにコピーされる
認識が難しい場合にはGemma3-4B + llama.cppを使う
最近はほとんどのブラウザに Text Fragment という機能があり、便利に使っています。
この文章のハイライトされた リンク で動作するか確認してみてください