Web ページを開いたまま、その内容を本質を保って要約する Chrome 拡張機能 web-digest を作った[1]。長い記事、技術文書、ブログ、ニュース、GitHub の README や Issue などを読んでいるとき、Chrome のツールバーからボタンを押すと、現在表示しているページから主要な内容を取り出し、要約結果を右側の Side Panel に表示する。
Web ページを AI に要約させること自体は、すでに珍しい機能ではない。Gemini in Chrome でも、現在開いているページの内容を使って要約できる。web-digest を作った理由は、ページ要約という機能が存在しないからではなく、本文の取り出し方、長文の分割方法、要約で何を残すか、どの AI API を使うかまで自分で制御したかったからである。とくに、長いページを途中で切り捨てず、文書構造に沿って段階的に圧縮し、原文を残したまま要約を横へ置くところまでを一つの読み方として実装した。
ここでいう要約は、元の文章を一定の文字数まで短くする処理ではない。中心命題だけを残して根拠や条件を落とせば、文章は短くなっても意味は変わりうる。反対に、同じ主張を説明する複数の例、言い換え、導入のための説明、修辞を減らしても、結論を支える構造が残っていれば読者が受け取る判断材料は保てる。web-digest では、中心命題、主要な根拠、因果関係、結論を左右する条件や留保を残し、それらを変えない範囲で重複を減らす。この処理を単なる短縮ではなく、意味を保った圧縮として扱っている。
利用時に必要な操作は少ない。最初に自身のさくらの AI Engine の API トークンを設定する。その後は、要約したいページを開いて Chrome のツールバーにある web-digest のボタンを押す。拡張機能は、その操作を起点に現在のページを読み、本文を抽出し、文章量を確認する。通常の長さならそのまま要約し、一度に扱うには長ければ文書構造に沿って分割して段階的に圧縮する。最後に全体を一つの要約へ統合し、元のページを残したまま Side Panel に表示する。
1. web-digest を作った
web-digest を作った直接の理由は、Web 上の長文を読むとき、全文を読み始める前に「この文章は何を主張しており、自分が詳しく読む必要があるのはどこか」を把握したい場面が増えたからである。長文だから読まないと決める前に、中心命題、主要な根拠、結論、条件を数分以内に確認できれば、その後の読み方を変えられる。概要だけで十分な記事ならそこで読み終えられるし、自分の判断に関係する内容なら原文を詳しく読める。
生成 AI のチャット画面へ URL を貼り、要約を依頼する方法でも要約そのものはできる。しかし、日常の Web 閲覧へ組み込むと操作の境界が目立つ。記事を見つけるたびに別の画面へ移動し、URL や本文を渡し、要約を待ち、その結果を読んでから元のページへ戻る必要がある。個々の操作は難しくなくても、この手順を多数の記事について繰り返すと、要約を使うための操作自体が閲覧の流れを分断する。
そこで、要約する機能をブラウザの閲覧動作へ寄せた。読んでいるページ上で web-digest のボタンを押すと、その一回の操作が「現在のページを要約する」という明示的な指示になる。拡張機能はそのページを読み、処理を開始し、結果を同じブラウザ画面の右側へ返す。利用者から見ると、ページを開く、ボタンを押す、要約を読むという流れになる。別のサービスへ文章を持ち運ぶ操作が消えることで、要約を特別な作業ではなく閲覧手順の一部として使える。
この操作体系は、どのページを読むかという権限の境界にもつながっている。web-digest は、ブラウザで開いたページを常時監視して自動的に収集する仕組みではない。要約処理が始まるのはツールバーのボタンを押したときであり、対象になるのもその時点で表示しているページである。要約したい文章を利用者が選び、その選択の後にだけ本文抽出が始まる。操作を一回にした結果、利用者の指示とページへのアクセス開始を同じ地点に置くことができた。
本文の抽出も、特定の Web サービスごとに処理を切り替える設計にはしていない。Zenn ならこの CSS クラス、WordPress ならこの要素というようにサイト名へ依存すると、対象サイトを増やすたびに個別対応が必要になり、デザイン変更でも壊れやすい。代わりに HTML が持つ文書構造を見る。主要な本文領域を探し、見出し、段落、リスト、引用、表、コードなどを文章の構成要素として取り出す。ナビゲーション、フッター、フォーム、リンクの集合のような本文ではない要素は可能な範囲で除外する。
この方法なら、対象は「対応サイトの一覧」ではなく「本文として読める構造を持つ Web ページ」になる。技術記事、個人ブログ、ニュース、技術文書、GitHub の README や Issue では見た目も HTML の細部も異なるが、読者が必要とするのはサイトの外枠ではなく、その中に置かれた文章である。抽出時にサイト固有の装飾を落として文書の構造を残せば、その後の要約処理は同じ経路へ流せる。
一方、汎用的な抽出には限界もある。Web ページである以上、すべての本文が通常の HTML 要素として取得できるとは限らない。特殊な DOM 構造、読み込み後に生成される内容、拡張機能からスクリプトを実行できないページでは、本文を十分に取得できない場合がある。web-digest は、この例外を埋めるために多数のサイト専用処理を持つより、一般的なページを一つの抽出規則で扱うことを優先している。対象範囲を広げるために実装を複雑化すると、サイト側の変更を追跡し続ける別の保守問題が生じるためである。
要約結果を別タブではなく Side Panel に表示する設計も、単なる画面配置ではない。別タブに要約だけを表示すると、原文と比較するたびに画面を往復する必要がある。ページ内へ要約を直接挿入すれば往復は減るが、元ページの DOM や CSS を変更することになる。Side Panel なら、原文には手を加えず、同じブラウザ画面の中で原文と要約を並べられる。
この配置によって、要約だけを読む場合と原典へ戻る場合を同じ閲覧経路の中に置ける。たとえば要約に「ある手法には特定の条件が必要である」と書かれていれば、その条件が自分の環境にも当てはまるかを原文ですぐ確認できる。結論だけで十分なら Side Panel だけを読めばよく、根拠が必要なら横にある原文を読む。要約を原文から切り離された完成品として扱うのではなく、原文のどこまで読む必要があるかを判断する入口として使う設計である。
そのため web-digest の処理は、ページを短く作り直すことでは完結しない。現在のページを取得し、本文構造を残して整理し、本質を保った要約へ圧縮し、その結果を原文の隣へ置くところまでが一つの機能になる。ブラウザ上で原文と要約を同時に残すことによって、読む時間を減らしても、必要になった情報へ戻る経路は失われない。
2. 長い文章には、削ればよいものと削れないものがある
長い文章を読む負荷については、生成 AI によって公開される文章量が増えたことを考えた既稿でも扱った。そこで取り上げたのが、内容の増加と文章量の増加が一致しないケースである。
todesking は、ちょっとしたアイデアを生成 AI で長文へ膨らませ、そのまま公開する行為を批判した[2]。生成 AI を使えば、一つの着想から長い文章を作ること自体は難しくない。短い主張の前に一般的な背景を置き、複数の利点と欠点を列挙し、似た事例を追加し、最後に将来展望を加えれば、中心命題をほとんど変えないまま文章量だけを増やせる。たとえば「この設計では状態を分離した方がよい」という一つの判断について、設計一般の説明、ありがちな失敗例、利点の列挙を何段落も加えることはできる。しかし、それらを削除しても判断の根拠が変わらないなら、増えたのは情報量ではなく読む量である。
この種類の長文に対しては、短くすることがそのまま改善になる。同じ命題を三回説明しているなら一回にできる。同じ役割の例が五つあるなら、代表的な一つで足りる場合がある。前後の段落を削除しても、読者が受け取る中心命題、根拠、条件、結論が変化しないなら、その部分には圧縮できる余地がある。
ところが、長い文章には別の種類もある。かなり本格的な無職である todesking は、有益な知見が含まれている一方で文章が長く、読むには要約が欲しいという趣旨の意見を表明した[3]。この場合、読者にとっての負荷は同じように「長い」という形で現れるが、長くなった原因が異なる。
ある結論を正確に伝えるには、結論だけでは足りないことがある。どの前提から始めたのか、何を観察したのか、どの選択肢と比較したのか、どこまでが確認済みなのか、どの条件で結論が変わるのかまで書かなければ、読者はその結論を自分の状況へ適用できない。文章が長い理由がこうした判断材料の蓄積にあるなら、単純な削除は読みやすさと引き換えに意味を変える。
| 長文化の種類 | 文章量が増える原因 | 削除したときの影響 | 適した処理 |
|---|---|---|---|
| 内容を増やさない水増し | 同じ命題を背景説明、類似例、一般論、修辞、言い換えによって繰り返す。 | 一部を削っても中心命題、根拠、条件、結論がほとんど変わらない。 | 重複そのものを削減する。 |
| 説明に必要な長文 | 前提、観察、比較、根拠、条件、例外、反論への応答を残すことで文章量が増える。 | 削りすぎると、結論が成立する範囲や読者が判断するための材料まで失われる。 | 原典を残し、読む側で必要な粒度へ圧縮する。 |
たとえば技術記事で「この方法は有効である」とだけ書けば短い。しかし、実際の判断には、その方法を試した環境、比較対象、測定条件、失敗したケース、適用できない条件が必要になることがある。「有効である」という結論だけを残した文章は、元の記事より読みやすくても、読者が自分の環境で同じ判断を再現するための情報を失っている。
さらに、前提と留保は結論の意味そのものを変える。ある方法が「常に有効」であることと、「特定の条件では有効」であることは別の主張である。長文から条件部分だけを落とせば、文章量は減るが、限定された主張が一般的な主張へ変わってしまう。これは要約の程度の違いではなく、情報の変形である。
そのため、文章の長さだけを見て「短い方がよい」と判断することはできない。見るべきなのは、段落を削ったときに何が失われるかである。同じ内容を繰り返している部分なら圧縮できる。結論の成立条件や根拠を担っている部分なら、原典には残す必要がある。文章量ではなく、各部分が判断にどの程度寄与しているかによって扱いを変える必要がある。
ここで書き手と読者では、情報を削る意味も異なる。書き手が公開前に文章を削れば、その情報は原典から消える。後から読者が必要になっても、その文章だけからは取り戻せない。一方、原典を十分な情報量で残したまま読者側で要約すれば、最初は圧縮された内容だけを読み、必要になった時点で根拠や条件を原文へ確認しに戻れる。
web-digest が対象にしているのは、この後者の読み方である。原文の中心命題、主要な根拠、因果関係、条件、留保を要約側へ残しながら、同じ主張の反復、複数の類似例、導入のための説明などを圧縮する。要約だけで判断できる範囲では読む量を減らし、要約では足りない範囲では原文へ戻る。
この分担なら、書き手に対して「読者のために最初から情報を削れ」と要求する必要がない。原典は説明に必要な情報を保持し、読者はそのすべてを最初から同じ密度で読む必要もない。長文そのものをなくすのではなく、情報を保存する段階と、人間が読む段階を分けることで、正確さと読解負荷を別々に扱える。
3. ページを開いたまま、そのページだけを読む
Chrome 拡張として設計するときに最初に決めたのは、「どのページを、いつ読むか」という境界である。要約機能には表示中のページ本文を取得する必要があるが、そのために閲覧中の全サイトへ常時アクセスする権限まで持たせる必要はない。web-digest では Manifest V3 の activeTab を使い、利用者が拡張機能のボタンを押した時点のタブだけを一時的な対象にしている。activeTab は、利用者の明示的な操作を起点として、その時点のタブへ限定的なアクセスを与える仕組みである[4]。
この権限設計によって、要約の開始操作とページへのアクセス開始を同じ一点に置ける。利用者が web-digest のツールバーボタンを押すまでは、拡張機能はそのページ本文を読まない。ボタンを押した時点で初めて、そのタブに対して本文抽出処理を実行する。閲覧中のページを自動判定して先回りで読み込む処理や、ページ遷移を監視して要約対象を蓄積する処理は必要ない。
実際の本文取得には chrome.scripting を使う。これは拡張機能から対象タブへスクリプトを注入するための API であり、activeTab によって一時的に得たアクセス権と組み合わせて使える[5]。web-digest では、要約を要求された瞬間にだけ抽出処理を注入し、その処理がページの DOM を読み取って必要な文章を返す。常駐する content script を全ページへ読み込ませる構成にはしていない。
抽出処理が読むのは、ページの見た目を構成するすべての要素ではない。見出し、段落、リスト、引用、表、コードなど、文章の論理を構成する部分を順序付きのブロックとして取り出す。一方、ナビゲーション、フッター、フォーム、非表示要素、リンクが大部分を占める領域などは本文から外す。ここでサイト名や CSS クラスを個別に列挙するのではなく、HTML の意味構造と文章密度を使って本文候補を選ぶことで、特定のサービスに依存しない抽出を目指している。
本文を読み取った抽出処理は、ページ自身を書き換えない。要約用のボタンをページ内へ追加したり、原文を置換したり、CSS を上書きしたりせず、読み取ったブロックだけを拡張機能側へ返す。ページ内で動く処理の役割を「読むこと」に限定すると、元ページの JavaScript や表示状態へ影響を与える範囲も小さくできる。
取得したブロックは service worker に渡される。ここが一回の要約処理全体を管理する場所になる。本文の空白や重複を整え、短すぎる入力を判定し、長文なら分割方法を決め、要約用の指示と本文を組み合わせ、AI Engine へ要求を送る。成功すれば要約結果をタブ単位のセッション状態として保持し、失敗すれば原因に応じた状態を保持する。本文取得、AI への通信、結果表示を別々の場所から勝手に実行させず、一つの処理経路へ集めている。
結果の表示には Chrome の Side Panel を使う。Side Panel API は、現在閲覧しているページを残したまま、拡張機能の UI をブラウザの横へ表示できる[6]。要約だけを別タブへ開く方式では、根拠を確認するたびに原文との間を往復しなければならない。ページ内へ要約を直接挿入する方式では、元ページの DOM やスタイルへ介入する必要がある。Side Panel なら、そのどちらも避けながら原文と要約を同時に表示できる。
| 構成要素 | 担当する処理 | 持たせない役割 |
|---|---|---|
| ツールバーのボタン | 現在のページを要約するという利用者の明示的な操作を受け付ける。 | ページを自動監視したり、閲覧履歴から要約対象を選んだりしない。 |
| 本文抽出処理 | 現在のページから見出し、段落、リスト、引用、表、コードなどを読み取る。 | ネットワーク通信、API トークンの参照、ページの書き換えは行わない。 |
| service worker | 本文整形、長さ判定、長文分割、AI Engine への要求、処理状態の管理を行う。 | ページ表示そのものを変更しない。 |
| Side Panel | 処理中、成功、失敗の状態と最終的な要約結果を表示する。 | 本文抽出や AI Engine への要求を開始しない。 |
| 設定画面 | 利用者自身の API トークンとモデル名を保存する。 | 閲覧ページの本文や要約履歴を管理しない。 |
この分離には、権限を減らすだけでなく、どの情報がどこまで届くかを限定する効果がある。ページ本文を読む抽出処理には API トークンを渡さない。設定画面にはページ本文を渡さない。Side Panel は完成した状態と要約を表示するだけで、AI Engine と直接通信しない。権限だけを少なくしても、内部で必要以上に情報を共有すれば境界は曖昧になるため、処理の役割とデータの到達範囲を同時に分けている。
外部通信先も同様に限定している。Web ページ側への恒久的な host permission は持たず、要約要求を送る先としてさくらの AI Engine の API origin だけを manifest に指定する。これによって、閲覧サイトへのアクセスは activeTab による一時権限、外部への送信は AI Engine への host permission という二つの経路に分かれる。どの Web サイトでも読める恒久権限と、どこへでも送信できる権限を同時に持たせる構成にはしていない。
Chrome の拡張機能向けプライバシー指針でも、必要になるかもしれない権限を先に広く取得するのではなく、activeTab などを使って必要な場面に限定する考え方が示されている[7]。web-digest では、この原則を単なる manifest の設定に留めず、操作体系にも反映した。ページを読む契機はツールバーボタンだけであり、Side Panel を開いたことやページを移動したこと自体では新しい要約処理は始まらない。
この制約によって、web-digest が何をする拡張機能なのかも明確になる。閲覧履歴から興味を分析するものではなく、バックグラウンドで記事を収集するものでもない。現在開いている一つのページについて、利用者が読む負荷を下げたいと判断したときだけ処理する。機能の対象を一ページ、一操作、一要約に絞ることで、権限、データの流れ、UI の役割を同じ境界へ揃えられる。
この設計は、次に扱う長文処理にもつながる。web-digest が保持するのは閲覧履歴や記事データベースではなく、その一回の操作で取り出した文書構造である。長いページを処理するときも、過去に収集した情報や検索基盤へ逃がすのではなく、そのページから得た見出しと本文ブロックだけを使って段階的に圧縮する。
4. 長文は、構造を残したまま段階的に圧縮する
通常の長さのページなら、抽出した本文を一回の要求で要約できる。ところが、長文そのものを対象にする拡張機能である以上、入力上限を超えた時点で「長すぎるので処理できない」と停止すると用途と実装が矛盾する。かといって、上限に収まるところまで先頭から本文を切り出せば、後半にある結論、反例、条件、参考情報を丸ごと失う可能性がある。web-digest では、一回の要求で扱える範囲を超えた場合だけ、文書を複数の部分へ分け、それぞれを圧縮した後に全体へ戻す。
長文を複数段階で処理する考え方は、長文要約の研究でも使われている。Zhang らの SummN は、長い入力を複数の区間へ分け、それぞれを段階的に要約し、その結果から最終的な要約を生成する枠組みを提案した[8]。一度に入力できる長さ自体も長文要約では継続的な課題であり、Huang らは長文書を効率よく処理する注意機構を検討するとともに、政府報告書のような長い文書を対象とした GovReport を提示している[9]。長文要約では、単にモデルへ全文を渡せるかだけでなく、長い入力からどの情報を残して最終出力へ反映するかまで設計対象になる。
モデルが扱えるコンテキスト長が伸びれば、分割そのものが不要になるようにも見える。しかし、入力欄へ文章全体を収められることと、文章の各部分を同じ精度で利用できることは別である。Liu らは、長いコンテキストの中で重要情報を置く位置によって性能が変わり、とくに中間部の情報を十分に利用できない場合があることを示した[10]。Ravaut らはこの位置による偏りを要約課題で検証し、長文要約でも入力のどこに情報が存在するかによって利用され方が変わることを報告している[11]。Wan らも、長文要約の忠実性を調べ、文書中ほどにある内容が要約へ反映されにくくなる位置偏りを確認している[12]。
この性質を考えると、「モデルの最大入力長より短ければ全文を一度に渡せばよい」とは必ずしもならない。入力可能な文字列が増えても、その中から中心命題、反論、条件、例外を均等に拾える保証までは得られない。一方で、すべてのページを無条件に細かく分割すれば、短い記事まで複数回の API 要求が必要になり、処理時間と利用量だけが増える。そこで web-digest は、通常のページには一回の要約経路を残し、一回の処理予算を超える長文だけを段階処理へ切り替える。
分割単位には、単純な文字位置ではなく、本文抽出時に残した文書構造を使う。web-digest は本文を一つの巨大な文字列として扱う前に、見出し、段落、リスト項目、引用、コード、表のセルというブロックとして保持している。長文を分けるときは、まず大きな見出しの境界を使い、それで収まらなければ下位見出し、さらに段落などのブロック境界へ降りる。一つのブロックだけで処理予算を超える場合に限って、そのブロック内部を分割する。
| 分割の優先順位 | 境界 | 理由 |
|---|---|---|
| 第 1 段階 | 主要な見出し | 章単位の論点を保ったまま分離でき、前後の異なる主題を混ぜにくい。 |
| 第 2 段階 | 下位見出し | 一つの章が大きすぎる場合でも、小項目ごとの論理的まとまりを残せる。 |
| 第 3 段階 | 段落、リスト、引用、コード、表 | 見出しだけでは収まらない場合に、意味のある最小単位を壊さず分割できる。 |
| 最終手段 | 単一ブロックの内部 | 一つのブロックだけで処理予算を超える場合に限り、入力上限へ収めるために分割する。 |
見出し境界を優先するのは、見た目を整えるためではない。見出しは、その文章でどこまでが同じ論点に属するかを著者自身が示した情報だからである。たとえば一つの章で方法を説明し、次の章で制約や反例を説明している記事を固定文字数で分けると、方法の途中と制約の途中が同じチャンクへ入り、逆に一つの論点が複数のチャンクへばらける場合がある。見出しを境界として使えば、少なくとも著者が与えた論理的な区切りを保った状態で圧縮できる。
分割した各部分を要約するときには、その断片だけを孤立して渡さない。ページ全体のタイトルと、その部分が属していた見出しの文脈を添える。同じ「有効である」という文でも、方法の説明に属するのか、比較結果に属するのか、制約条件に属するのかで役割は異なる。チャンク化によって前後の文章を切り離しても、少なくとも文書内での位置づけを残しておけば、部分要約が局所的な文章だけを見て意味を取り違える可能性を減らせる。
各チャンクでは、中心となる主張、主張を支える根拠、因果関係、適用条件、結論を変えうる留保を残して圧縮する。たとえば一つの結論を説明する似た実例が五つ並んでいれば、すべてを同じ長さで保持する必要はない。一方、そのうち一つだけが結論の例外を示しているなら、それを他の類似例と同じものとして落とすと意味が変わる。圧縮対象を文字数ではなく、それぞれの情報が結論に対して持つ役割で判断する必要がある。
部分要約を作った後も、それらを順番に連結しただけではページ全体の要約にならない。章ごとに別々に圧縮すると、同じ中心命題が複数の要約へ重複して現れたり、前半の根拠と後半の結論の関係が切れたりする。そこで web-digest は、各チャンクの要約をもう一度入力し、ページ全体の中心命題、主要論点、論点間の因果関係、結論、条件へ再統合する。
非常に長いページでは、チャンク要約を集めた結果そのものが、一回の統合要求へ収まらない場合もあり得る。その場合も一部を捨てて上限へ合わせるのではなく、要約済みの中間結果をさらに複数群へ分けて圧縮し、最終的に一つへ統合する。原文から部分要約、部分要約から中間要約、中間要約から最終要約というように、情報量を段階的に減らす。
この方式では、長いページほど API 要求の回数は増える。処理時間も通常のページより長くなる。その代わり、入力上限を超えた箇所以降を切り捨てたり、文章の先頭だけから全体を推測したりせずに済む。長文への対応で優先したのは、一回で処理する速さよりも、原文全体が最終要約へ到達する経路を残すことである。
web-digest が長文処理で保存しようとしているのは、元の文字列を均等に縮小したものではない。保存対象は、文章が何を主張し、その主張が何に支えられ、どの条件まで成立し、何が結論を変えうるのかという構造である。同じ主張の反復は圧縮できるが、反論、条件、例外を削れば論理そのものが変わる。長文を段階的に扱う理由は、処理上の入力制限を回避することだけではなく、その違いを最後の要約まで維持するためにある。
5. 要約には、さくらの AI Engine を使う
現在の web-digest は、要約を生成する外部サービスとして、さくらの AI Engine を利用する。ブラウザ拡張機能の中で大規模言語モデルを動かすのではなく、前章までの処理で抽出・整形した本文を AI Engine へ送り、返された要約を Side Panel に表示する構成である。さくらの AI Engine は OpenAI 互換の Chat Completions API や Responses API などを提供しており、利用者が発行したアカウントトークンで API を利用できる[13]。web-digest では、そのうちチャット生成 API を要約処理に使っている。
ブラウザ側と AI Engine 側の役割は分けている。ブラウザ側では、利用者が選んだページだけを読み、ナビゲーションなどを除いて本文を抽出し、見出しや段落などの構造を保った状態へ整える。短いページならその本文を直接送り、長いページなら複数の部分へ分けて段階的に圧縮する。AI Engine が担当するのは、渡された文章から中心命題、根拠、因果関係、条件、留保を取り出し、不要な反復を減らす処理である。Web ページを読む処理と、文章の意味を判断して圧縮する処理を同じ場所へ混ぜていない。
| 処理 | 実行する場所 | 扱う情報 |
|---|---|---|
| ページ本文の取得 | Chrome 拡張機能 | 現在のページから見出し、段落、リスト、引用、表などを取得する。 |
| 本文の整形と長文分割 | Chrome 拡張機能 | 不要な要素を除き、入力量に応じて文書構造を保ったまま処理単位を作る。 |
| 意味的な圧縮 | さくらの AI Engine | 本文や部分本文から、主張、根拠、因果関係、条件、留保を保った要約を生成する。 |
| 結果表示 | Chrome の Side Panel | 生成された最終要約を元ページの横へ表示する。 |
AI Engine への通信は、API 固有の処理を担当するモジュールへ集約している。さくらの AI Engine の Chat Completions API では、Bearer 認証を使い、モデル名とメッセージ列を要求として渡す[14]。web-digest もこの形式に従い、要約用の指示と処理対象の文章をメッセージとして送る。本文抽出処理や Side Panel が API の URL、認証ヘッダー、応答形式を直接扱う構造にはしていない。
この分離によって、要約の内容を決める部分と、特定の API へ接続する部分も分けられる。どの情報を残し、どの重複を減らすかという指示は要約プロンプトが担い、どのモデルへどの形式で要求を送るかは通信モジュールが担う。モデル名も設定画面から渡すため、本文抽出処理が特定モデルを前提に動作する必要はない。API 側の仕様と、Web ページから何を読み取るかという仕様が直接結び付かない構成である。
認証には BYOK、利用者自身の API トークンを使う方式を採った。web-digest の作者が共通の API トークンを埋め込み、それを利用者全員で共有する方式ではない。利用者は自身で取得したさくらの AI Engine のトークンを設定画面へ入力する。トークンは Chrome の拡張機能用ストレージに保存され、AI Engine へ要求するときの Authorization ヘッダーにだけ使用される。
共通トークンを持たないため、web-digest 専用の中継サーバーも必要ない。ページから抽出した本文は、いったん作者のサーバーへ送ってから AI Engine へ転送するのではなく、利用者の Chrome からさくらの AI Engine へ直接送信される。web-digest 独自のバックエンドを挟まないため、web-digest 側でページ本文、要約結果、API トークン、利用履歴をサーバー保存する仕組みを持つ必要もない。
この構成では、料金と API 利用量の帰属も明確になる。API を利用する主体は、それぞれの利用者自身である。作者が全利用者分の API 使用量をまとめて負担し、あとから利用回数を計測して課金する必要はない。利用者側も、自身が契約している AI Engine の利用条件と残量の範囲で web-digest を使うことになる。拡張機能が独自の利用者登録や料金管理を持たずに済むのは、この認証方式の直接的な帰結である。
一方、BYOK にすれば API トークンが暗号学的に秘匿されるわけではない。Chrome のプロファイルを操作できる者からトークンを完全に隠すことは、ローカルで動く拡張機能だけでは保証できない。web-digest が制御しているのは、トークンをソースコードやリポジトリへ含めず、ページ本文へ渡さず、要約結果へ混ぜず、独自サーバーへ送らないという範囲である。利用者の端末そのものを信頼境界の外に置く設計ではない。
ページ本文についても同じ境界がある。web-digest 独自のサーバーへは送信しないが、要約を生成するためには本文をさくらの AI Engine へ送る必要がある。外部へ一切送信せずに要約するローカルモデルではないため、機密情報を含むページを扱う場合には、AI Engine へその内容を送信すること自体を許容できるかが判断条件になる。独自バックエンドを持たないことと、外部通信が存在しないことは別である。
インストール後の準備は、この構成を反映している。GitHub から web-digest を取得して Chrome へ読み込み、拡張機能の設定画面で自身の Sakura AI Engine API token を保存する。モデルを明示的に変更したい場合はモデル名も設定できる。その後は要約したいページでツールバーのボタンを押すだけで、ページ取得から AI Engine への要求までが開始される。
実行すると、元の記事を表示したまま右側の Side Panel に処理状態が表示され、要約が完成すると同じ場所へ結果が出る。長文であれば内部では複数回の API 要求が発生する場合があるが、利用者がチャンクごとに操作する必要はない。部分要約から最終統合までを一回の実行として扱い、最後にページ全体の要約だけを表示する。
この画面配置は、AI Engine の出力を原典から独立した新しい文章として読ませるためのものではない。左側には要約元の記事が残り、右側にはその圧縮結果がある。要約だけで概要を把握できればそこで読み終えられ、根拠や条件が必要ならそのまま原文へ戻れる。AI Engine は原典を置き換える場所ではなく、人間が原典へ入る前の読解量を減らす処理層として使っている。
6. AI が書いた長文を、AI が要約して人間が読む
web-digest を使うと、文章の生成から読解までの間に AI が二度入ることがある。人間が題材、問題設定、中心命題を決め、生成 AI を使って長文の執筆を補助する。その文章が Web に公開されると、今度は web-digest が別の AI に本文を渡して要約し、人間は圧縮された文章から読み始める。人間から始まった文章が AI を経由して長文化され、公開後にもう一度 AI を経由して短くなり、人間へ戻ってくる。
この構造だけを見ると、かなり迂回しているように見える。人間が読むのが最終的に短い要約なら、最初から短い文章を書けばよいようにも思えるからである。しかし、生成時に増えた文章と要約時に減らした文章が、単純に同じ情報を往復させているとは限らない。執筆段階では、短い中心命題に前提、根拠、具体例、比較、反論への応答、条件、留保を加えることで、第三者が検証できる文章へ展開する。要約段階では、その情報をすべて均等に削るのではなく、結論を支える構造を残しながら重複を減らす。長文化と圧縮は逆方向の文字数操作に見えて、担っている役割が異なる。
既稿「AI だけが文章を書き続けるディストピアの果て」では、AI が過去の AI 生成物を次の情報源として読み、その出力が再び情報環境へ戻っていく循環を考えた[15]。生成 AI が普及する以前は、外部世界で起きた出来事を人間が観察して記録し、その記録を次の人間が読むという経路が中心だった。生成 AI が大量の文章を公開側へ供給すると、後から読む人間や AI が接する情報の中に、すでに AI によって展開、整理、言い換えられた文章が増える。
web-digest は、この循環へさらに読解側の AI を追加する。情報の流れを単純化すると、次のようになる。
| 段階 | 担当 | 情報に対して行うこと |
|---|---|---|
| 問題設定 | 人間 | 何について書くか、何を主張するか、どの根拠を採用するかを決める。 |
| 文章化 | 人間と生成 AI | 中心命題を、前提、根拠、具体例、条件を含む長文へ展開する。 |
| 公開 | Web | 十分な情報量を持つ原典として文章を残す。 |
| 圧縮 | web-digest と AI | 中心命題と判断材料を残しながら、重複や補助的な説明を減らす。 |
| 読解 | 人間 | 要約から全体像を把握し、必要に応じて原典や参考資料へ戻る。 |
この流れが成立する背景には、生成側と読解側で処理能力の増え方が異なるという事情がある。生成 AI を使えば、構成案の作成、段落の展開、草稿の修正といった作業の一部を短縮できるため、一人の人間が文章を生成する側の処理量は増やしやすい。
一方、人間の読解時間は同じ方法では増えない。文章を生成する計算能力が十倍になっても、一日に自由に使える時間が十倍になるわけではない。しかも長文を正確に読むには、単に文字列を目で追うだけでなく、前提を理解し、根拠を比較し、必要ならリンク先や一次資料を確認する時間がかかる。生成量の増加は、そのまま読者側の未処理情報量の増加になる。
この非対称性が続けば、読者は公開された文章を全文読むか読まないかの二択では処理できなくなる。タイトルだけで切り捨てれば、有益な文章まで見逃す。すべて全文を読めば、使える時間を超える。そこで、まず要約で中心命題と構造を確認し、その結果を使って全文を読む価値を判断する段階が入る。AI 要約は、単に読了時間を短くするだけでなく、限られた読解時間をどの文章へ配分するかを決める前処理になる。
ただし、この構造を「AI が文章を書き、AI が要約し、人間は結論だけ受け取ればよい」という形まで閉じると、別の問題が生じる。生成時に AI が誤った根拠を加え、要約時に別の AI がその誤りを中心命題として残した場合、人間が原典や一次資料へ戻らなければ、その変形を確認する場所がない。さらに、要約を次の AI が読み、その結果が次の文章へ使われれば、途中で失われた条件や加えられた誤りが後続の情報環境へ引き継がれる。
web-digest で原文を閉じず、Side Panel に要約を表示する理由はここにもある。画面の一方に要約を置き、もう一方に要約元のページを残す。要約で「この文章では A が B の原因だと論じている」と把握したあと、その因果関係が重要なら原文の該当箇所を読む。原文が研究や一次資料を参照していれば、さらにそのリンクを辿れる。AI が作った圧縮結果から、情報量の多い層へ逆方向に移動できる。
この戻る経路があるかどうかで、AI を読解へ入れる意味は変わる。原典を消して要約だけを保存すれば、圧縮時に捨てた情報は失われる。原典を残したまま要約を上に重ねれば、要約は情報を置き換えるものではなく、情報へ到達する順序を変えるものになる。最初から全文を読む代わりに、要約から入り、必要性に応じて詳細へ降りていく。
その結果、人間が読む対象も一種類ではなくなる。概要だけを知ればよい文章では要約だけを読む。自分の仕事や判断に関係する文章なら原典へ進む。数値、研究結果、制度、仕様のように正確性が重要なら、さらに参考文献や一次資料まで確認する。同じ文章でも、読者の目的によって必要な情報量は異なるため、すべての読者へ最初から同じ深さの読解を要求する必要がない。
生成 AI によって公開される文章量が増えるほど、この階層的な読み方には実用上の意味が出てくる。生成側では、検証可能性を残すために必要な説明を削らずに書く。公開時には、その長文を原典として保存する。読解側では AI が最初の圧縮を担当し、人間がどこまで深く読むかを決める。AI が生成と要約の両方へ入ること自体よりも、その間に原典を残し、人間がどの段階でも戻れる構造を維持することが、この情報の流れを成立させる条件になる。
7. 最初から短く書けばよいとは限らない
ここまでの構造を見ると、「最終的に読者が要約を読むなら、人間向けの記事は最初から要約程度の長さにすればよい」とも考えられる。しかし、公開前に書き手が情報を削ることと、公開後に読者側で圧縮することは同じではない。前者では削られた情報そのものが原典から消える。後者では原典を残したまま、読む順序と読む量だけを変えられる。
既稿「シンプルな判断の裏にある情報量」では、表面上は短い判断であっても、その判断へ到達するまでに大量の情報処理が存在し得ることを考えた[16]。たとえば「この案を採用する」という結論だけなら一文で書ける。しかし、実際の判断には、比較した案、採用しなかった理由、費用、失敗条件、将来の変更可能性、前提としている環境が含まれていることがある。表面に現れる結論が短いことと、結論を支える情報まで少ないことは一致しない。
文章でも同じである。「この方法は有効である」という一文だけなら短い。しかし、その方法を採用できるのが特定の環境だけなのか、別の方法より何が優れていたのか、どの条件では失敗したのか、測定した範囲はどこまでなのかを書けば文章は長くなる。これらは結論を飾る補助情報ではない。読者が同じ判断を自分の状況へ適用できるかを決める材料である。
| 残す情報 | 短い結論だけでは分からなくなること |
|---|---|
| 前提 | どの条件の下で結論が成立しているのか判断できなくなる。 |
| 比較対象 | 何に対して優れている、劣っているという評価なのか分からなくなる。 |
| 根拠 | 結論が観察、測定、推論のどこから導かれたのか確認できなくなる。 |
| 失敗条件 | 同じ方法を別の環境へ適用したときに破綻する境界が見えなくなる。 |
| 留保 | 限定された結論が、一般的に成立する結論のように読まれる可能性が生じる。 |
この情報を公開前に書き手が削れば、読者は後から必要になっても同じ文章から取り戻せない。たとえば記事中に「この方法は高速である」とだけ残し、測定環境や比較対象を削った場合、読者は何に対して高速なのかを確認できない。要約で同じ一文へ圧縮された場合でも、原典が残っていれば測定条件まで戻れる。見た目には同じ短い文でも、背後に原典が存在するかどうかで情報への到達可能性が異なる。
ここには不可逆性の差がある。書き手が原稿から一段落を削除して公開すれば、その段落は公開情報から失われる。読者が要約によって一段落を読み飛ばしても、原典そのものは残る。後から必要になれば読み直せる。公開前の短縮は情報集合そのものを小さくするが、読解時の圧縮は利用時に参照する部分集合を小さくする。この二つを同じ「短くする」という操作として扱うと、原典を残す意味が見えなくなる。
さらに、AI による要約は原典を完全に写し取る処理でもない。抽象型要約では、元の文章をそのまま抜き出すのではなく、モデルが内容を再構成して短い文章を生成する。この過程では、原典に書かれていない内容が加わったり、条件が落ちたり、複数の記述が不正確に統合されたりする可能性がある。Maynez らは、抽象型要約モデルの出力に入力文書と整合しない内容が含まれることを人手評価によって調べ、事実への忠実性が要約品質とは別に検証すべき問題であることを示した[17]。
この問題は、単に文章が読みやすいかどうかを測るだけでは捉えにくい。要約が流暢で、主要な話題も含んでいたとしても、原文にない因果関係を加えていれば、読者が受け取る意味は変わる。Kryscinski らは、一般的な要約評価指標だけでは原文との事実的一貫性を十分に捉えにくいという問題から、要約と原文の整合性を評価する方法を提案した[18]。要約の短さや自然さだけでは、原典と同じことを言っているかまでは保証できない。
要約品質を一つの尺度で決めることが難しい理由もここにある。Fabbri らの SummEval は、多数の自動評価指標と人間評価を比較し、要約品質を単一の指標だけで評価する難しさを示した[19]。ある要約が重要な内容を多く含んでいても、原典との事実的一致が弱い場合がある。逆に原典へ忠実でも、重要度の低い情報を多く残せば読解負荷は下がらない。
Tang らは、要約で発生する事実誤りを複数の種類に分け、データセットや要約手法によって誤りの傾向が異なることを調べている[20]。さらに、誤りを検出する評価手法も、すべての誤り種別やデータセットに対して一様に機能するわけではない。つまり、「この要約は自動評価を通ったから原典と同じ意味である」と単純には扱えない。
これらの研究から、AI 要約を避けるという結論を出す必要はない。用途を限定すれば、要約は長文を読むための有効な入口になる。最初に要約を読んで中心命題と主要な条件を把握し、内容が自分の判断に関係しなければそこで終える。重要なら原典へ戻る。数値、比較条件、制度、研究結果のように正確さが必要な箇所は、さらに一次資料へ進む。要約を最終的な情報源ではなく、どこまで読むかを決める前処理として使えばよい。
web-digest が原文を Side Panel の裏へ隠さず、同じ画面に残しているのもこのためである。要約に「特定条件では有効」と書かれていれば、その条件が何を指すのか原文で確認できる。要約で条件そのものが落ちている可能性を疑った場合も、すぐ比較できる。原典が隣にあることで、要約の誤りや情報損失をゼロにできるわけではないが、それを検証する経路は残せる。
書き手側での短縮は、公開される情報そのものを減らす。読者側での要約は、原典を保持したまま一度に読む情報量を減らす。この違いがあるから、長文と要約はどちらか一方を選ぶ関係にはならない。書き手は説明に必要な前提、根拠、条件、留保を原典へ残し、読者は目的に応じてその情報を圧縮して読むことができる。
最初から短く書くことが適している文章はもちろんある。同じ主張の反復や不要な一般論を削ることまで否定する理由はない。しかし、削れば主張の成立条件や判断材料まで失われる文章については、短さを公開時の制約にするより、十分な情報量を持つ原典と、読解時に生成する要約を分けた方がよい。情報を保存する段階と読む段階を分離することで、正確さのための長さと、人間が処理できる読解量を同時に扱える。
8. 長文をなくすのではなく、読むときに圧縮する
web-digest の機能自体は小さい。利用者が Chrome のツールバーからボタンを押すと、その時点で表示しているページだけを読み、主要な本文を抽出する。通常の長さなら一回で要約し、長文なら見出しや段落の構造を使って複数の部分へ分け、それぞれを圧縮したうえで全体を再統合する。完成した要約は原文を消さず、同じブラウザ画面の Side Panel に表示する。
この一連の処理で変えているのは、原典が持つ情報量ではなく、読者が最初に接する情報量である。元の記事には、中心命題だけでなく、その命題を支える根拠、比較、条件、例外、留保を残せる。web-digest は、それらを保存した原典とは別に、読者が全体像を把握するための圧縮された入口を作る。長文を公開することと、短く読むことを別の段階へ分けている。
| 段階 | 保持する情報量 | 役割 |
|---|---|---|
| 原典 | 中心命題、根拠、比較、条件、例外、留保まで残す。 | 主張を正確に伝え、必要なら判断過程を確認できる情報源になる。 |
| AI による要約 | 中心命題と判断に必要な構造を残し、重複や補助的な説明を減らす。 | 全文を読む前に、その文章をどこまで読む必要があるか判断する入口になる。 |
| 原典の詳細箇所 | 要約だけでは不足した条件や根拠を再確認する。 | 具体的な判断や検証が必要になったときに情報量を戻す。 |
| 参考文献・一次資料 | 原典が依拠した観察、仕様、研究、制度などへ遡る。 | 原典自体の正確性まで確認する必要がある場合の検証先になる。 |
読者は、この情報量の異なる層を最初から最後まで順番に読む必要はない。まず要約を読む。内容が自分の関心や判断に関係しなければ、そこで読み終えられる。重要な内容なら原典へ進み、要約では省かれた条件や根拠を確認する。さらに数値、研究結果、仕様、制度のように正確性が重要なら、原典に示された参考文献や一次資料まで辿る。読む深さを文章ごとに変えられる。
これは、長文を読む負荷を AI にすべて肩代わりさせるという話でもない。要約は原典より情報量が少なく、生成過程で意味を取り違える可能性もある。だからこそ、要約だけを保存して原典を捨てる構成にはしない。要約は最初の選別と全体把握に使い、判断に必要な情報が不足すれば原文へ戻る。読解量を減らすことと、検証可能性を残すことを同時に成立させる。
生成 AI によって文章を作る速度が上がるほど、この分離には意味が出てくる。書き手は、読者が全文を読む負担を恐れて、判断に必要な説明まで先回りして削る必要がない。前提や根拠を含む文章を原典として残せる。一方、読者も公開されたすべての長文を同じ深さで精読する必要はない。AI に最初の圧縮を任せ、どこまで読むかを自分で決められる。
正確に伝えるために必要な長文まで書き手が削る必要はなく、原典は十分な情報を持つ形で残し、読む側が AI によって本質を保った要約を得ればよい。
web-digest は、この考え方を Web 閲覧の操作へ落としたものである。長文を短文へ置き換えるのではなく、長文を原典として残したまま、その上に読者用の圧縮結果を重ねる。情報を保存する段階では削りすぎず、読む段階で必要な量まで圧縮する。長文をなくすのではなく、読むときに圧縮するという役割分担である。
現在の web-digest は、要約エンジンとしてさくらの AI Engine のみに対応している。本文抽出、長文分割、要約結果の表示と、AI Engine へ接続する処理は分離しているため、今後のバージョンではこの基本構造を保ったまま、ほかの生成 AI API も選択できるよう接続部分の汎用化を検討する。
参考文献
- id774, web-digest, GitHub repository（参照 2026-08-16）. https://github.com/id774/web-digest
- id774, この物量の文章を、一体誰が検証できるのか（2026-07-30）. https://blog.id774.net/entry/2026/07/30/5160/
- todesking, 有益な知見がスロップに包まれて出てくることが一般的になった、本当に過酷な時代。（2026-08-14）. https://x.com/todesking/status/2088587244840137003
- Chrome for Developers, The “activeTab” permission. https://developer.chrome.com/docs/extensions/develop/concepts/activeTab
- Chrome for Developers, chrome.scripting. https://developer.chrome.com/docs/extensions/reference/api/scripting
- Chrome for Developers, chrome.sidePanel. https://developer.chrome.com/docs/extensions/reference/api/sidePanel
- Chrome for Developers, Protect user privacy. https://developer.chrome.com/docs/extensions/develop/security-privacy/user-privacy
- Yusen Zhang et al., SummN: A Multi-Stage Summarization Framework for Long Input Dialogues and Documents, Proceedings of the 60th Annual Meeting of the Association for Computational Linguistics（2022）. https://aclanthology.org/2022.acl-long.112/
- Luyang Huang et al., Efficient Attentions for Long Document Summarization, Proceedings of NAACL-HLT（2021）. https://aclanthology.org/2021.naacl-main.112/
- Nelson F. Liu et al., Lost in the Middle: How Language Models Use Long Contexts, Transactions of the Association for Computational Linguistics 12（2024）. https://aclanthology.org/2024.tacl-1.9/
- Mathieu Ravaut et al., On Context Utilization in Summarization with Large Language Models, Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics（2024）. https://aclanthology.org/2024.acl-long.153/
- David Wan et al., On Positional Bias of Faithfulness for Long-form Summarization, Proceedings of NAACL-HLT（2025）. https://aclanthology.org/2025.naacl-long.442/
- さくらインターネット, さくらの AI Engine 利用手順（参照 2026-08-16）. https://manual.sakura.ad.jp/cloud/ai-engine/02-howto.html
- さくらインターネット, さくらの AI Engine Inference API（参照 2026-08-16）. https://manual.sakura.ad.jp/api/cloud/ai-engine/inference.html
- id774, AI だけが文章を書き続けるディストピアの果て（2026-07-27）. https://blog.id774.net/entry/2026/07/27/5121/
- id774, シンプルな判断の裏にある情報量（2026-08-14）. https://sizu.me/id774/posts/w5z156t83bfs
- Joshua Maynez et al., On Faithfulness and Factuality in Abstractive Summarization, Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics（2020）. https://aclanthology.org/2020.acl-main.173/
- Wojciech Kryscinski et al., Evaluating the Factual Consistency of Abstractive Text Summarization, Proceedings of EMNLP（2020）. https://aclanthology.org/2020.emnlp-main.750/
- Alexander R. Fabbri et al., SummEval: Re-evaluating Summarization Evaluation, Transactions of the Association for Computational Linguistics 9（2021）. https://aclanthology.org/2021.tacl-1.24/
- Liyan Tang et al., Understanding Factual Errors in Summarization: Errors, Summarizers, Datasets, Error Detectors, Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics（2023）. https://aclanthology.org/2023.acl-long.650/