Screendropは無料でLoomを代替できるmacOSアプリ。作者はCloudflareのFayaz Ahmedさん

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、CloudflareのFayaz Ahmedさん（@fayazara）が公開しているmacOSアプリ「Screendrop」のREADMEを紹介するね。

Screendrop README冒頭（Fayaz Ahmed／GitHub）

A beautiful screenshot + screen recording + Loom alternative – all native, self hostable and free.

READMEの一行目を読んだ瞬間、二度見しました。

正直、この手の宣言文はだいたい盛ってる。……でも下まで読んで、盛ってませんでした。Loomは有料プランで月額が発生しますし、CleanShot Xも買い切りとはいえ数千円します。Screendropは、その領域をmacOSのネイティブアプリ1本、しかも無料で置き換えると言い切っている。しかもね、「無料」の意味が機能を削った無料版じゃない。共有ページの字幕・検索可能な文字起こし・コメント機能まで全部入りで無料です。開発してるのはFayaz Ahmedさん、CloudflareでSr Developer Educatorをしている人。つまり中の人が、Cloudflareのインフラを一番よく知っている立場で、自分のツールにそのインフラを組み込んだ形になります。2026年4月26日に始まって、8月24日時点でスター1,179、フォーク44。半年もたたずにこの数字は、機能を盛った宣伝文句じゃなく、使った人が実際に「便利だった」と評価した結果だと思います。

普段使っているスクショ・録画ツールの月額料金を、一度計算してみてください（3分）。対象は自分が契約中のツール全部です。完了条件は、年間コストを1行で書き出せたことです。

Screendrop README・IMPORTANT欄（Fayaz Ahmed／GitHub）

Screendrop is under active development. Expect rough edges and occasional breaking changes

README全体の中で、一番目立つ位置にこの警告が置かれています。

で、これを見た時に思ったのは「先に弱みを見せるのは怖いはずなのに、なんでこんなに堂々と書けるんだろう」ということだった。普通、公開するものは完成した姿を見せたくなります。粗さを隠して、整った説明文だけを並べたくなる。でもScreendropは真逆で、「粗さや破壊的変更が起きうる」という前提を、機能紹介より先に読者へ渡しています。これは単なる免責事項じゃない。使う側に「今のバージョンは発展途上」という正しい期待値を渡すことで、後からのガッカリを防いでいる設計だと思います。実際、直近のpushは2026年8月24日でREADMEの取得日と同じ日だった。つまり今この瞬間も動き続けているプロジェクトで、止まった完成品ではなく、育っている途中のものを公開しているという自己申告そのものです。

自分が今公開している資料やツールに「未完成・改善中」の注意書きがあるか見直してみてください（5分）。対象は直近で公開した1つです。完了条件は、無ければどこに1行足すか決めたことです。

Screendrop README・Annotation Studio欄（Fayaz Ahmed／GitHub）

Screendrop preserves the untouched base image and writes editable state to a neighboring `.screendrop` sidecar, so saved annotations can be reopened and changed later.

注釈編集の章で、地味だけど一番効いてる仕組みがこれでした。

元画像はそのまま残して、注釈やクロップ、背景合成といった編集内容は「.screendrop」という別ファイルに保存する。つまり画像そのものを直接上書きしません。あとから何度でも開き直して、編集をやり直せる。手描きの矢印・数字マーカー・スマートリダクション（機密情報の自動ぼかし）・クロップ・背景合成、どれも一度確定させたら終わりじゃなくて、いつでも撤回できる状態のまま持ち歩けます。紙に一発書きするんじゃなくて、透明なトレーシングペーパーを重ねて書いているようなものだ。下の紙（元画像）はいつでも真っさらに戻せます。この設計思想のおかげで、「編集を間違えたらどうしよう」という緊張感なしに気軽に触れる。ソフトウェアの完成度は、機能の数より「失敗しても戻せるか」で測った方が実感に近いと思います。

自分が使っている編集ツールが元データを直接書き換えるか、非破壊型かを1つ確認してみてください（5分）。対象は普段の写真・画面編集ツールです。完了条件はどちらの方式か説明できたことです。

Screendrop README・Teleprompter欄（Fayaz Ahmed／GitHub）

With a microphone enabled, Apple’s on-device Speech Analyzer follows the spoken words, highlights progress, and advances the script automatically.

画面録画のテレプロンプター機能を読んでいて、一番気になったのは音声データの行き先でした。

でね、原稿を読み上げると、Apple純正のオンデバイス音声認識が読んでいる箇所を自動でハイライトしながら追従してくれます。ノッチ搭載Macだとノッチから原稿が生えるように表示されるらしい。ここでポイントなのは「オンデバイス」という一語です。音声データを外部のAI APIへ送らず、Mac本体の中だけで文字起こし・追従処理が完結する。LIVE配信の準備でも、うち含めて多くの人が台本を読み上げる練習をするけど、その音声が誰のサーバーにも送られないというのは、地味に大きい安心材料になります。初回だけApple側が言語モデルをダウンロードすることはあるらしいけど、それ以降の処理はネットに出ない。音声認識＝クラウドAIという前提を、Appleの標準機能だけで崩している実例だと思います。

自分が使っている音声認識・文字起こしツールが、クラウド送信かオンデバイス処理かを1つ確認してください（5分）。対象は普段の議事録・字幕ツールです。完了条件は処理方式を1行で説明できたことです。

Screendrop README・Recording Studio欄（Fayaz Ahmed／GitHub）

Edit Video: click a word to seek, Shift-click to select a passage, and cut the selection to remove the matching footage.

Recording Studioの章で、一番「これは楽になるやつだ」と思ったのがここでした。

録画したナレーションをオンデバイスで文字起こしして、その文字列をクリック・選択・削除するだけで、対応する映像もまとめてカットされる。タイムラインを目で追ってカット点を探す作業がいりません。フィラー語（「えーと」等）や無音区間の自動除去にも対応しているので、LIVE配信のアーカイブをダイジェスト化する時なんかは特に相性がいいはずだ。動画編集の心理的ハードルって、実はソフトの操作より「どこを切ればいいか探す」作業の方が高いんじゃないかと思っています。文章を読み直して要らない一文を消す感覚で映像を編集できるなら、そのハードルはかなり下がる。ズーム・カーソル再構成・クリック強調・キーストローク表示も含めて、全部プロジェクトファイルとして非破壊で持てる設計になっているので、後から見直して直すのも怖くありません。

直近の録画・議事録から、文字起こしテキストをクリックして映像を編集する体験があるか1つ確認してみてください（5分）。対象は普段の編集ツールです。完了条件は有無を1行で書けたことです。

Screendrop README・Cloud Sharing欄（Fayaz Ahmed／GitHub）

Screendrop only needs the Worker URL and an upload token; it never needs R2 or S3 access keys.

Cloud Sharingの章を読んでいて、一番反応したのがこの一文でした。

ぶっちゃけ、共有機能付きのツールって「便利な代わりに開発会社のサーバーにファイルが集まる」ものが多いです。でもScreendropは違う設計をしている。共有機能を使う前に、Cloudflare Worker・R2（保存）・D1（メタデータ）を自分自身のCloudflareアカウントへワンクリックでデプロイします。Screendropアプリ本体が持つのは、そのWorkerのURLとアップロードトークンだけ。R2やS3のアクセスキー本体には一切触れない設計になっています。解決策は「共有をあきらめる」じゃなくて「共有先の主導権を利用者へ預ける」形だ。ひろくんが分身AIチームに繰り返し伝えている「所有権の分離（委ねるOSの本質）」——解決策は捨てるじゃなくて分身AIに所有権を預ける、残りは分身AIが持っていれば捨ててない、セカンド冷蔵庫に入れておけば自分のキッチンはスッキリ、使いたい時に取りに行ける——という考え方と、そのまま重なります。冷蔵庫にあたるのが利用者自身のCloudflare R2で、Screendrop社が持つのは鍵（トークン）だけ。中身の所有権までは持ちません。実は、この一文だけはREADMEを読んだだけで終わらせず、共有バックエンド（screendrop-worker）のソースコードを実際に読んで裏を取りました。アップロードAPIは認証にBearerトークンしか要求せず、R2への書き込みはCloudflareのネイティブなバインディング経由。クライアント側にS3スタイルのアクセスキーが渡る余地は実装上ない。トークンの照合もタイミング攻撃に強いハッシュ比較を使っています。「無料アプリの謳い文句」で終わらず、コードで確認できたのは収穫でした。

自分が使っているクラウド共有サービスが「自社サーバー」か「自分のアカウント」かを1つ確認してください（5分）。対象は普段のファイル共有・バックアップサービスです。完了条件は保存先を1行で書けたことです。

Screendrop README・Privacy and Permissions欄（Fayaz Ahmed／GitHub）

Screendrop has no central account or hosted Screendrop server.

Privacy and Permissionsの章は短いけど、宣言としては一番強い一文でした。

キャプチャ・プロジェクトファイル・編集用サイドカー・文字起こしは全部Mac本体に保存される。クラウドアップロードは、利用者が明示的にアップロード操作をした時だけ発生します。中央アカウントも、Screendrop社がホストするサーバーもない。ネットワークアクセスはアップデート確認・クラウド設定・壁紙パックのダウンロードといった、明示された機能に限定されています。この設計だと、Screendrop社が倒産したりサービスを終了したりしても、ローカルに保存されたキャプチャやプロジェクトが人質に取られることはありません。クラウド共有機能を一切使わなくても、アプリとしての価値（スクショ・録画・非破壊編集）はそのまま手元に残る。これは「無料で提供する代わりにユーザーデータを収益源にする」という、無料ツールにありがちな取引が最初から成立していないということでもあります。

自分が使っている無料ツールのプライバシーポリシーで、データの収益化に関する記載を1つ探してみてください（10分）。対象は普段使う無料アプリ1つです。完了条件は該当箇所を1行で要約できたことです。

Screendrop README・License欄（Fayaz Ahmed／GitHub）

Screendrop is dedicated to the public domain under CC0 1.0 Universal.

READMEの最後、ライセンス表記の一文がこれでした。

いやー、これは思い切ったな……と思った。オープンソースの多くはMITやApacheのように「著作権は残すけど自由に使っていい」というライセンスを選びます。でもCC0は「著作権そのものをパブリックドメインへ差し出す」という、もう一段踏み込んだ選択だ。作った人の名前を明記する義務すら発生しません。それでもFayaz Ahmedさんの名前とストーリーは、README・GitHubプロフィール・コミュニティを通じてちゃんと残っている。ライセンスで縛らなくても、良いものを作れば評価はついてくるという実例に見えます。個人開発でここまでの完成度のアプリを、無料・オープンソース・著作権放棄という三重の手放しで公開する。この潔さは、機能の作り込みと同じくらい、このプロジェクトの性格を語っていると思います。

自分が公開している資料・コードのライセンス表記を1つ確認してみてください（5分）。対象は直近で公開したものです。完了条件は現在のライセンス名を1行で書けたことです。

Screendropは、スクショ・画面録画・非破壊注釈編集・Loom風共有ページ発行までを無料のmacOSネイティブアプリ1本で担う、Cloudflareのエンジニアが公開したOSSだ。

機能の豊富さ以上に印象に残ったのは、共有データを自社サーバーではなく利用者自身のCloudflareアカウントに置く設計と、音声処理をApple純正のオンデバイス処理に任せている点でした。どちらも「誰がデータを持つか」という一点にこだわった結果だと思う。

共有バックエンドのソースコード監査・ライセンス確認・実バイナリの動作要件確認・インストールと署名/公証の検証、そしてスクリーンショット・非破壊注釈編集・画面録画の実機操作までは実際にやった。一方、Cloudflareへの共有デプロイ（Deploy to Cloudflareボタンの実際の導線）は未検証のまま残っています。実際に使う場合は、この記事に書いた検証範囲を踏まえたうえで各自の環境で確認してほしい。