AI 関連の論文やニュースは、毎日いくつもの場所で公開される。arXiv には新しい論文が分野別に追加され、企業や研究組織のブログには研究成果、製品発表、モデル公開、評価結果が掲載される。情報源へ接続する手段も既にあり、arXiv には公開 API があり、多くの Web サイトは RSS または Atom のフィードを提供している。情報を取得する入口そのものが不足しているわけではない。
取得できることと、毎日読めることの間には別の作業が残る。同じ研究が論文と企業ブログの双方に掲載されれば、題名や説明の表現が異なっていても一つの話題として扱う必要がある。英語の題名と概要を読んで内容を把握し、一日に公開された項目の中から確認すべきものを選び、後から原典へ戻れるように出典を保持しなければならない。情報源を巡回する時間だけを減らしても、重複の判定、話題の整理、優先順位付けという編集作業は減らない。
この作業を人手で行う場合、日によって確認する情報源や判断基準が変わりやすい。項目数が多い日は一部を読み飛ばし、少ない日は広い範囲まで確認するため、日次レポートの対象範囲を一定に保ちにくい。さらに、収集、翻訳、要約、保存を別々の操作として行えば、途中で止まった処理や参照元を追跡する負担が増える。継続的な情報確認には、個々の作業を速くするだけでなく、毎日同じ入力条件と出力形式で繰り返せる処理経路が必要になる。
そこで、AI 関連の論文とニュースを収集し、一日の話題として整理して保存する ai-digest というソフトウェアを作った。ai-digest は、取得した項目をそのまま時系列に並べるのではなく、明白な重複を減らし、内容の近い項目を話題単位へまとめ、日本語の見出しと箇条書きを持つ日次レポートへ変換する。各話題には元の論文や記事へのリンクを残すため、レポートは原典の代替ではなく、その日に読む対象を選ぶための入口として機能する。
本稿では、ai-digest がどのような入力を受け取り、どの処理を通常のプログラムで固定し、どの判断を生成 AI に担当させたかを順に確認する。機能の説明から始め、API キーの有無による処理差、構造化された出力と出典の対応、生成処理と閲覧処理の分離へ進む。そこから、生成 AI を継続運用可能なソフトウェアへ組み込む際には、モデルの応答だけでなく、その前後にある選別、検証、保存、失敗時の処理まで設計対象になることを示す。
1. ai-digest というソフトウェアを作った
ai-digest は、AI 関連の論文とニュースを一日一回収集し、日本語の日次レポートと一枚のサマリー画像を生成するソフトウェアである[1]。
入力となるのは、arXiv から取得した論文と、設定した RSS または Atom フィードから取得したニュースである。各項目は、論文かニュースかという種別、題名、URL、概要、公開日時、取得元を持つ共通の形式へ変換される。情報源ごとに異なる取得方法をこの段階で吸収するため、その後の重複排除や話題整理では、論文とニュースを同じ処理対象として扱える。
収集した件数は、その日に起きた話題の数とは一致しない。一つの論文について、著者の所属組織が解説記事を公開し、別の企業ブログが応用例を紹介すれば、取得結果には複数の項目が現れる。これらを独立したニュースとして表示すると、同じ出来事がレポート内の複数箇所を占め、ほかの話題が押し出される。ai-digest は、URL の一致と題名の類似度で明白な重複を先に減らし、その後に残った項目を内容に基づいて話題単位へまとめる。
この二段階の整理には役割の違いがある。URL や題名から判定できる重複は、同じ入力に対して同じ結果を返す通常のプログラムで処理できる。一方、題名が異なる論文とニュースが同じ研究を扱っているかどうかは、概要に書かれた対象、方法、結果を読まなければ判断できない。形式的な一致を先に処理し、意味的な関係だけを生成 AI に残すことで、モデルへ渡す入力を減らしながら、表記差を超えた話題整理を行う。
完成物は、モデルが返した文章だけではない。日付ごとの JSON、ブラウザーで読める HTML、各話題の画像、一日の内容をまとめた PNG が同じ処理から生成される。Flask の閲覧画面では、保存済みの日付を一覧から選び、過去のレポートを読むことができる。生成された HTML は単独でも閲覧できるため、日付別のディレクトリーを静的な Web サーバーへ配置すれば、生成処理を動かさずに公開できる。
| 工程 | 入力と処理 | 処理が必要になる理由 | 得られる結果 |
|---|---|---|---|
| 収集 | arXiv と設定済みのニュースフィードから、一定時間内に公開された論文と記事を取得する。 | 情報源を個別に巡回すると、確認範囲と実行時刻が日ごとに変わり、同じ条件で比較できない。 | 複数の情報源を、共通の項目形式を持つ一つの入力集合へ変換する。 |
| 重複排除 | URL の一致と正規化した題名の類似度を使い、明白に重複する項目を減らす。 | 同じ内容を繰り返しモデルへ送ると、入力量が増えるだけでなく、一つの話題が複数の表示枠を占める。 | 意味的な判断が必要な候補だけを後続処理へ渡す。 |
| 話題整理 | 内容の近い論文とニュースをまとめ、重要度順の話題として構成する。 | 取得項目は記事単位であり、一日に起きた出来事の単位とは一致しない。 | 記事数ではなく、その日に確認すべき話題数として読めるようにする。 |
| 編集 | 英語の題名と概要を日本語化し、見出し、カテゴリー、箇条書き、出典の対応を組み立てる。 | 原文の一覧だけでは、各項目を開くまで内容と優先順位を判断できない。 | 原典を読む前に、その日の全体像と確認順序を把握できるようにする。 |
| 画像処理 | 論文図またはニュースの代表画像を取得し、取得できない場合は見出しを使ったカードを生成する。 | 外部サイトの応答や HTML 構造は制御できず、画像取得を必須にすると一件の失敗でレポート全体が止まる。 | 外部画像の有無にかかわらず、各話題が一定の表示領域を持つ。 |
| 保存 | 話題、出典、実行件数、画像を日付別の JSON と通常ファイルとして記録する。 | 生成結果をその場で表示するだけでは、後日の閲覧や表示形式の再生成に利用できない。 | API を再度呼び出さずに、過去のレポートを表示し直せる。 |
| 表示 | 保存済みデータから HTML と日次サマリー画像を生成し、読み取り専用の Flask アプリケーションで公開する。 | 閲覧要求のたびに収集や生成を行うと、API の遅延、障害、費用がそのまま表示機能へ波及する。 | 生成処理の状態から独立して、保存済みの日次レポートを継続して読める。 |
この処理経路では、各工程の出力が次の工程の入力になる。収集した項目がなければ重複排除は始まらず、重複排除後の候補がなければ話題整理も行えない。話題が生成されても、出典との対応を復元できなければ原典へ戻れず、保存されなければ翌日以降の閲覧に利用できない。どこか一つの機能だけが存在しても、日次レポートとしての利用条件は満たされない。
このため、ai-digest の中心を Claude API の呼び出しだけに置くことはできない。Claude API が担当するのは、候補項目を読み、意味の近いものをまとめ、日本語の話題へ編集する工程である。その前には情報源の選定、時間範囲の判定、共通形式への変換、重複排除があり、その後には出典番号の検証、画像処理、ファイル保存、HTML 生成、閲覧経路が続く。モデルの応答は完成品ではなく、処理経路の中間に置かれた構造化データである。
ai-digest が反復可能にしたのは、要約文の生成そのものより、外部情報が日付を持つ閲覧物へ変わるまでの手順である。毎日の実行で情報源、対象時間、最大トピック数、保存形式を同じ条件に保つため、処理条件の差を減らし、その日に取得された情報の違いを比較しやすくなる。ai-digest というソフトウェアを作ることは、生成 AI に文章を書かせる処理を追加することではなく、論文とニュースを継続的に読むための経路を固定することであった。
2. 論文とニュースを毎日読める形にする
2.1 情報がないのではなく、読む形になっていない
AI の新着情報を取得する経路は既に整備されている。arXiv は外部のソフトウェアから論文の題名、著者、概要、公開日時などを取得できる公開 API を提供している[2]。企業や研究組織の Web サイトでも、題名、リンク、更新日時、概要を配信できる Atom や RSS が使われている[3][4]。情報源へ接続し、新着項目を機械的に取得するところまでは、生成 AI を使わなくても実現できる。
しかし、取得された項目の件数は、その日に起きた出来事の数とは一致しない。新しい研究が arXiv に公開されると、所属組織が研究内容を解説し、企業が応用可能性を紹介し、ニュースサイトが別の題名で報道することがある。取得処理から見れば、それぞれ異なる URL と題名を持つ独立した項目である。一方、日々の動向を確認する側から見れば、複数の記事が指している研究上の出来事は一つである。
記事単位の一覧をそのまま表示すると、同じ研究が複数の表示枠を占める。表示件数に上限がある場合、その重複によって別の話題がレポートから押し出される。重複は単に一覧を長くするだけでなく、一日に何が起きたかという全体像を偏らせる。このため、URL や題名が一致する項目を除くだけでなく、表現の異なる論文とニュースが同じ内容を扱っているかを判定し、話題の境界を引き直す必要がある。
言語の違いも、翻訳だけでは解消しない。英語の題名や概要を一件ずつ日本語へ変換すれば、各項目の内容は読みやすくなる。しかし、数十件の候補を比較し、どの研究が同じ流れに属し、どの発表を先に確認すべきかを決める作業は残る。個々の文章を理解する処理と、複数の項目を横断して一日の主要な話題を構成する処理は、目的が異なる。
さらに、情報の価値は公開された事実だけでは決まらない。日次レポートでは、過去 24 時間という観測範囲の中で、ほかの候補と比較したときに何を残すかが問われる。単独では興味深い論文であっても、同じ日に大きなモデル公開や重要な評価結果が重なれば、限られた表示枠から外れることがある。ここで必要になるのは絶対的な価値判定ではなく、特定の日、特定の情報源、特定の件数上限の中で行う相対的な選択である。
ai-digest が処理対象とするのは、この取得後に残る分断である。情報源ごとに分かれた項目を共通の形式へ変換し、形式的な重複を減らし、内容の近い項目を話題単位へまとめ、日本語の見出しと要点を付ける。その結果、論文や記事の一覧は、その日に確認すべき出来事の一覧へ変わる。
2.2 検索基盤ではなく日次の閲覧物を作る
収集した情報をどのように残すかは、最終的な利用方法から決める必要がある。将来の調査で任意のキーワードを検索するなら、本文の保存、全文索引、検索順位、条件による絞り込み、重複文書の管理が必要になる。検索時点では何を探すかが決まっているため、システムには大量の情報を失わずに蓄積し、問い合わせに応じて取り出す能力が求められる。
ai-digest が想定する利用場面は異なる。利用者が最初から特定の論文名や研究者名を知っているとは限らない。知りたいのは、過去 24 時間に収集された範囲で、どのような話題が現れたかである。この場合、必要なのは検索語に一致する文書を返すことではなく、検索語を入力する前の段階で、確認対象を有限な件数へ整理することである。
| 観点 | 検索基盤 | ai-digest の日次レポート |
|---|---|---|
| 利用開始時の状態 | 探したい語句、人物、製品、研究分野などが決まっている。 | その日に何が起きたかをまだ把握していない。 |
| 情報量の扱い | 将来の問い合わせに備え、可能な限り多くの情報を保持する。 | 一日の確認時間に収まるよう、表示する話題を先に絞る。 |
| 主要な処理 | 保存、索引作成、検索条件との照合、順位付けを行う。 | 重複排除、話題統合、日本語化、日次の重要度評価を行う。 |
| 出力単位 | 検索条件に一致した文書や文書内の該当箇所を返す。 | 複数の論文や記事をまとめた一日の話題を返す。 |
| 原典との関係 | 蓄積した本文や索引から必要な情報を直接取り出す。 | 要点を確認した後、出典リンクから原典へ移動する。 |
この目的の違いは、ai-digest の保存方式にも表れる。ai-digest は取得したすべての本文を長期的な検索対象として保存するのではなく、日付ごとに選ばれた話題、要点、出典、画像をレポートとして残す。過去のレポートは日付から読み返せるが、任意の語句で全文を探索するための索引は持たない。機能が不足しているのではなく、保存対象を日次の閲覧結果へ限定している。
標準設定では、過去 24 時間の候補から最大 6 件の話題を生成する[1]。この上限は、収集可能な件数やモデルが処理できる件数を示したものではない。一枚のサマリー画像に配置でき、毎日継続して確認できる量から逆算した出力条件である。候補が 6 件を超えれば、何を残すかという選択が必要になり、その判断によって日次レポートの性格が決まる。
出力件数を先に定めると、収集量を増やすだけではレポートの価値は上がらなくなる。候補が増えるほど、類似項目をまとめ、重要度を比較し、表示枠へ残す話題を選ぶ処理が重くなる。収集能力の拡大は入力の網羅性を高める一方で、選択基準が曖昧なままでは、最終結果を不安定にする。日次の閲覧物では、どれだけ取得したかだけでなく、どの条件で削減したかが品質を左右する。
ai-digest は、情報をすべて内部へ取り込むことで価値を作るのではない。過去 24 時間という時間範囲、設定された情報源、最大 6 件という表示枠を組み合わせ、その範囲内で読む順序を作る。検索基盤が将来の問いに備えて情報を保持する仕組みであるのに対し、ai-digest は今日の確認作業を開始できる状態まで情報を編集する仕組みである。
3. 収集から日次レポートまでを一つの処理にする
3.1 論文とニュースを共通の項目へ変換する
ai-digest の処理は、外部の情報源から項目を取得するところから始まる。論文については、設定された arXiv カテゴリーごとに公開日時の新しい順で項目を取得し、対象期間より古い論文へ到達した時点で、そのカテゴリーの読み込みを終える[5]。ニュースについては、設定された複数の RSS または Atom フィードを読み、各記事から題名、リンク、概要、公開日時、配信元を取り出す[6]。
両者は同じ新着情報であっても、取得元の構造が異なる。arXiv では論文識別子、著者、カテゴリー、要旨などが一定の形式で配信されるのに対し、ニュースフィードではサイトごとに公開日時や概要の持ち方が揃っていない。概要へ HTML が含まれる場合があり、公開日時が欠落した項目もある。外部形式をそのまま後続工程へ渡すと、重複排除や要約処理の内部に、情報源ごとの例外処理が入り込む。
ai-digest は、この差異を収集段階で共通の項目へ変換する。内部で保持するのは、論文かニュースかを示す種別、題名、URL、概要、公開日時、出典名である。後続工程は、この共通構造だけを受け取るため、項目が arXiv の Atom 応答から得られたのか、企業ブログの RSS から得られたのかを判定する必要がない。
| 観点 | arXiv 論文 | ニュース記事 | 内部で保持する形式 |
|---|---|---|---|
| 情報源 | 設定された arXiv カテゴリーから取得する。 | 設定された RSS または Atom フィードから取得する。 | 取得元の種類にかかわらず、一つの項目として扱う。 |
| 内容 | 論文題名と要旨を主な説明として使う。 | 記事題名とフィード内の概要を使う。 | 題名と概要という共通の欄へ格納する。 |
| 公開日時 | arXiv が提供する日時を使って対象期間を判定する。 | フィードに公開日時がある項目だけを対象期間と比較する。 | 日時情報を持つ新着項目として後続工程へ渡す。 |
| 出典 | arXiv カテゴリーや論文 URL を保持する。 | 配信元名と記事 URL を保持する。 | 話題生成後も原典へ戻れる参照情報として残す。 |
この変換によって、外部サービスの形式変更が影響する範囲を収集器の内部へ閉じ込められる。あるニュースサイトを追加する場合は、そのフィードを共通項目へ変換する処理を用意すればよく、重複排除、話題整理、画像生成、保存、表示の実装は再利用できる。反対に、共通項目の構造を変更すれば後続工程へ広く影響するため、外部形式の都合を安易に内部構造へ持ち込まないことが重要になる。
収集器を分ける設計は、拡張性だけでなく障害の局所化にも関係する。一つのニュースフィードの取得に失敗しても、別のフィードや arXiv の収集結果まで無効にする必要はない。情報源ごとの取得を独立させ、取得できた項目だけを共通集合へ加えることで、外部サイトの一時的な障害を日次処理全体の停止へ直結させにくくしている。
3.2 明白な重複をモデルへ送る前に減らす
収集された項目には、同じ内容を指す重複が含まれる。完全に同じ URL が複数のフィードへ現れる場合もあれば、追跡用のパラメーターや表記差によって URL は異なるが、題名がほぼ同じ場合もある。ai-digest は、URL の完全一致と、正規化した題名の類似度を使って、こうした明白な重複をモデルへ送る前に除く[7]。
題名の正規化では、大文字と小文字、全角と半角、句読点、連続した空白など、内容の違いを表さない表記差を減らす。そのうえで文字列の類似度を比較し、設定された基準以上に近い項目を重複とみなす。この判定は内容の意味を理解しているわけではないため、題名が大きく異なる紹介記事と原論文を統合することはできない。一方、同一記事の再配信や軽微な題名変更を取り除く用途には、言語モデルよりも結果が予測しやすい。
この前処理がない場合、同一内容の概要が複数回モデルへ送られる。直接的には、入力文字数と API 利用量が増える。さらに、同じ情報が複数の候補として提示されれば、その反復が話題の重要度を実態以上に大きく見せる可能性がある。重複排除は費用削減だけではなく、入力集合の偏りを抑える処理でもある。
形式的な重複と意味的な重複を分けることで、モデルへ任せる判断範囲も明確になる。URL が同じか、題名がほぼ同じかという判定は通常のプログラムで処理する。題名の異なる論文とニュースが同じ研究成果を扱っているか、複数の記事を一つの話題へ統合すべきかという判断は、概要の意味を読まなければ決められない。この後者だけを話題整理の工程へ残す。
重複時にどちらを残すかは、入力順序によって決まる。ai-digest は論文を先に、ニュースを後に連結し、先に現れた項目を残す。原論文と紹介記事の題名が十分に近ければ、論文が一次資料として残りやすい[7]。これはモデルが出典の信頼性を評価した結果ではなく、収集順序と重複排除の規則を組み合わせた設計上の優先順位である。
この規則には限界もある。題名の異なる紹介記事は形式的重複として除かれず、意味処理まで残る。反対に、題名が似ていても内容の異なる項目が誤って重複と判定される可能性がある。現在の処理は、完全な同一性判定を目指すのではなく、モデルへ渡す前に明白な反復を低い費用で減らすためのものとなっている。
3.3 閲覧可能な成果物まで一度に生成する
日次バッチは、収集、重複排除、話題整理、画像処理、保存、HTML と PNG の生成を順に実行する[8]。各工程は独立した機能を持つが、運用上は一回の実行として接続されている。途中で得られる日本語の見出しや箇条書きは、画面へそのまま表示して終わる最終成果ではなく、出典と画像を付け、日付別に保存するための中間データである。
要約結果を端末へ表示するだけなら、生成時点では内容を読める。しかし、翌日に同じ結果を参照するには、出力を別の場所へ保存し、日付を付け、出典 URL を整理し、表示形式を整える作業が残る。この手作業を毎日繰り返せば、要約を自動化しても、日次運用全体は自動化されない。ai-digest は生成後の工程まで同じ処理へ含めることで、一回の実行をそのまま日次アーカイブの追加へ結び付けている。
処理順序には依存関係がある。収集結果がなければ重複排除は行えず、重複排除後の候補がなければ話題を生成できない。話題が生成されても、参照元が一件も対応しなければ原典へ戻れないため、その話題は公開対象として利用できない。画像取得に失敗した場合はローカルカードへ切り替えられるが、利用可能な話題そのものがなければレポート生成は失敗として終了する。
| 工程 | 正常時の出力 | 失敗時の扱い | 後続工程への影響 |
|---|---|---|---|
| 収集 | 対象期間内の論文とニュースを共通項目として返す。 | 一部の情報源が失敗しても、取得できた情報源の項目を残す。 | 全情報源から一件も得られなければ、日次処理を終了する。 |
| 重複排除 | 明白な重複を除いた候補集合を返す。 | 完全一致と題名類似度で判定できる範囲だけを処理する。 | 残った候補が話題整理の入力になる。 |
| 話題整理 | 見出し、箇条書き、カテゴリー、出典番号を持つ話題を返す。 | 箇条書きや有効な出典を持たない話題は公開対象から除く。 | 利用可能な話題が一件もなければ、レポートを生成しない。 |
| 画像処理 | 原典の画像またはローカル生成したカードを話題へ付ける。 | 外部画像を取得できなければ、見出しとカテゴリーからカードを生成する。 | 画像取得失敗だけではレポート全体を停止しない。 |
| 保存と表示 | JSON、HTML、個別画像、日次サマリー画像を日付別に保存する。 | 保存または描画に失敗すれば、その日の成果物は完成しない。 | 正常に保存された結果だけが閲覧アプリケーションから参照される。 |
正常系を一つにつなぐだけでなく、どの失敗を許容し、どの失敗で処理を止めるかも工程ごとに異なる。ニュースフィードの一つが読めなくても、ほかの情報源から十分な項目を取得できればレポートは作れる。外部画像が得られなくても、代替カードによって表示形式を保てる。一方、収集項目がゼロの場合や、話題整理の結果に有効な出典がない場合は、内容のない成果物を残さず異常終了する。
実行結果には、収集件数、重複排除後の件数、生成された話題数、使用したモデル、生成日時が記録される[8]。これにより、たとえば表示された話題が少ない日について、最初から収集件数が少なかったのか、重複排除によって候補が減ったのか、話題整理によって統合されたのかを件数の推移から確認できる。
ただし、この統計だけでは、どの項目が重複として除かれ、モデルへ何が送られ、どの候補が採用されなかったかまでは再現できない。現在の記録は、日次処理の規模と完成結果を確認するためのものであり、判断過程を完全に監査する記録ではない。閲覧物として必要な情報を残す設計と、生成過程を追跡可能にする設計は、保存すべきデータの範囲が異なる。
一連の処理を一つのバッチへまとめた結果、ai-digest では「要約が生成されたこと」と「読める日次レポートが完成したこと」が区別される。要約は途中工程の成功にすぎず、出典との対応、画像の確保、日付別の保存、HTML と PNG の生成まで完了して初めて、その日の成果物として利用できる。日次運用を成立させているのは個別機能の存在ではなく、各工程の出力、失敗条件、代替経路を接続した処理全体である。
4. API キーなしでも ai-digest は動く
4.1 plain モードでは意味的な編集だけを外す
SUMMARIZER_BACKEND に plain を指定すると、言語モデルを呼び出さずに日次処理を完了できる[9]。この設定で停止するのは、複数項目の意味的な統合、日本語への翻訳、内容に応じた分類、重要度に基づく話題構成である。arXiv とニュースフィードからの収集、URL と題名による重複排除、画像処理、JSON と HTML の保存、サマリー画像の生成、Flask による閲覧はそのまま動作する。
この挙動は、ai-digest の処理が言語モデルを前提とした一枚岩ではないことを示している。通常モードと plain モードは、収集から重複排除まで同じ経路を通り、話題を生成する段階だけで分岐する。その後は再び同じ形式のトピックを受け取り、画像、保存、HTML、PNG の生成へ進む。意味処理の実装だけを交換しても、後続工程を書き換えずに済む構成である。
plain モードでは、重複排除後の各項目が一つのトピックになる。公開日時の新しい順に最大件数まで選ばれ、題名は原文のまま使われる。概要は文単位に分けられ、最大 4 件の箇条書きとして転記される。論文のカテゴリーには arXiv の分類名を、ニュースには配信元の名称を使うため、分類結果も内容分析ではなく取得元から機械的に決まる。
この方式では、一件の項目をレポートへ載せることはできるが、複数の項目を一つの出来事として扱うことはできない。原論文とその紹介記事が題名類似度による重複排除を通過すれば、それぞれ別のトピックとして表示される。英語の題名と概要も日本語化されないため、情報源を一か所へ集約する効果は残る一方、読むための編集負担は利用者側へ戻る。
plain モードの動作から、API キーの役割をソフトウェア全体の起動条件とみなすことはできない。API キーがなくても、情報を取得し、明白な重複を除き、画像と出典を持つレポートとして保存し、過去分を閲覧できる。API キーによって加わるのは、取得済みの項目を読み、その関係を判断し、日本語の話題へ再編成する工程である。
処理境界をこの位置へ置いたことで、外部 AI サービスの障害や認証設定の不足が、収集器、画像生成、保存形式、閲覧アプリケーションの実装まで巻き込まない。API が使えないときは出力品質が低下するが、日次処理そのものは別の実装で継続できる。ai-digest における縮退運転とは、全機能を停止することではなく、意味的な編集を外し、決定論的に実行できる工程を残すことである。
4.2 デモモードでは外部条件なしで完成形を確認する
python cli.py demo を実行すると、リポジトリに同梱されたサンプルデータからレポートを生成できる[10]。このモードでは、arXiv やニュースフィードへの接続と API 呼び出しを行わない。保存済みの入力と話題データを通常の検証処理へ渡し、代替カードの生成、JSON 保存、HTML 生成、サマリー画像の作成には本番と同じコードを使う。
デモモードで共通化されている範囲は、完成形を確認するうえで重要である。サンプル専用の HTML や固定画像を表示するだけなら、画面の見た目は確認できても、本番で使われる保存処理、画像描画、テンプレート、ファイル配置が正常に動くかは分からない。ai-digest のデモは、外部入力だけを固定し、その後の成果物生成を実際の処理経路へ通すため、表示例であると同時に出力系の動作確認にもなる。
plain モードとデモモードは、いずれも API キーを必要としないが、確認している対象が異なる。plain モードでは実際の情報源へ接続するため、収集、公開日時の判定、重複排除、画像取得を含む日次運用を試せる。ただし、言語モデルが行う話題統合と日本語化は確認できない。デモモードでは外部通信をすべて外すため、最新情報の取得は確認できないが、事前に用意された話題が最終成果物へ変換される経路を安定して再現できる。
| 観点 | plain モード | デモモード | 通常モード |
|---|---|---|---|
| 主な目的 | API を使わず、実際の新着情報で日次処理を継続する。 | 外部設定を行う前に、生成物と表示形式を確認する。 | 新着情報を意味的に編集した日本語レポートを生成する。 |
| arXiv とフィードへの接続 | 接続する。 | 接続しない。 | 接続する。 |
| 言語モデルへの接続 | 接続しない。 | 接続しない。 | 接続する。 |
| 入力データ | 実行時に取得した論文とニュースを使う。 | リポジトリに保存されたサンプルを使う。 | 実行時に取得した論文とニュースを使う。 |
| 話題整理 | 各取得項目を機械的に一つのトピックへ変換する。 | サンプルに含まれる話題を通常と同じ検証処理へ通す。 | 複数項目を統合し、日本語の話題として生成する。 |
| 画像処理 | 外部画像を取得し、失敗時には代替カードを生成する。 | 外部画像を取得せず、ローカルの代替カードを生成する。 | 外部画像を取得し、失敗時には代替カードを生成する。 |
| 確認できる範囲 | 収集系と出力系を含む、API なしの実運用を確認できる。 | 保存、描画、HTML、ファイル配置など、外部通信後の工程を確認できる。 | 収集から意味的編集、出力までの全工程を確認できる。 |
| 出力形式 | JSON、HTML、PNG を生成する。 | JSON、HTML、PNG を生成する。 | JSON、HTML、PNG を生成する。 |
外部 API を利用するソフトウェアでは、最初の成果物を見るまでに複数の条件が関与する。API キーが正しいこと、通信先へ接続できること、利用モデルがツール呼び出しへ対応していること、情報源に対象期間内の新着があること、日本語を描画できるフォントが存在することが必要になる。初回実行が失敗しただけでは、認証、通信、入力データ、画像生成、HTML 表示のどこに原因があるかを直ちに特定できない。
デモモードは、これらの外部条件から、保存と表示に関する条件を切り離す。デモが正常に完了すれば、少なくともサンプルの読み込み、トピック検証、代替カード生成、JSON 保存、HTML と PNG の生成は動作していると判断できる。その後に通常モードが失敗した場合は、収集先、認証情報、互換 API、取得データなど、デモで通らなかった経路へ調査範囲を絞れる。
ただし、デモの成功は本番実行全体の成功を保証しない。デモでは外部フィードの形式変更、arXiv への接続、API の利用制限、モデル応答の変動、外部画像の取得を通らない。デモが確認するのは、固定された入力から成果物を作る経路であり、外部サービスとの接続条件は通常モードまたは plain モードで別に検証する必要がある。
plain モードとデモモードを分けたことで、ai-digest は API キーがない状態を一種類の制限として扱わず、二つの異なる用途へ対応している。実際の新着情報を処理したい場合は plain モードを使い、まず完成形とローカルの出力処理を確認したい場合はデモモードを使う。外部依存をすべて満たすまで何も確認できない構成を避け、運用継続と導入時の切り分けを別の経路として用意したことが、この二つのモードの役割である。
5. API キーが追加するのは話題単位の編集である
5.1 記事項目を一日の話題へ組み替える
Claude を利用する場合、ai-digest は重複排除後の候補から先頭の最大 60 件を取り出し、各項目の題名、出典名、概要をモデルへ渡す[11]。一つの概要から使う文字数にも上限を設けているため、取得した本文や要旨を無制限に入力する構成ではない。入力件数と概要の長さを先に制限し、その範囲内で最大トピック数まで日次レポートを作らせる。
モデルへ渡される時点で、候補は既に選別されている。情報源、対象期間、取得上限、明白な重複の除外は通常のプログラムによって完了しており、モデルが新たに Web を検索することも、候補外の論文を補うこともない。モデルが判断するのは、与えられた項目の間にどのような関係があり、その中から何を一日の主要な話題として残すかである。
この工程は、各項目を独立に短くする要約処理とは異なる。独立要約では、入力が 30 件あれば出力も原則として 30 件のままであり、同じ研究を扱う論文、開発元の発表、第三者の記事は別々に残る。ai-digest では、複数の項目が同じ対象、手法、発表を扱っていると判断した場合、それらを一つのトピックへまとめる。入力の境界を維持したまま文章を短くするのではなく、入力項目の境界そのものを引き直している。
たとえば、新しい基盤モデルについて、技術報告書、開発企業の発表、外部メディアの記事が同じ日に取得されたとする。三件をそのまま表示すれば、表示枠を三つ使い、同じモデルの説明が繰り返される。内容上の共通部分を一つの話題へ集約すれば、モデルの名称、主要な技術的特徴、公開条件、評価結果を一か所で確認できる。残りの表示枠には、別の研究や製品発表を載せられる。
| 処理 | 項目ごとの要約 | ai-digest の話題編集 | 出力への影響 |
|---|---|---|---|
| 入力の扱い | 各項目を独立した文章として処理する。 | 複数項目の対象、方法、結果、発表主体を比較する。 | 記事の件数と話題の件数を分けられる。 |
| 重複への対応 | 同じ内容でも項目ごとに要約が残る。 | 意味上の重なりが大きい項目を一つの話題へまとめる。 | 同じ出来事が複数の表示枠を占めることを減らす。 |
| 言語 | 原文を短くするだけなら、言語は入力に依存する。 | 題名と概要を読み、日本語の見出しと箇条書きへ再構成する。 | 異なる情報源を同じ言語と形式で比較できる。 |
| 順位 | 入力順または公開日時順のままになりやすい。 | 候補間の内容を比較し、重要度が高いと判断した話題から並べる。 | 限られた表示件数の中で読む順序を作れる。 |
| 出典 | 一つの要約に一つの入力項目が対応する。 | 一つの話題へ複数の根拠項目を関連付ける。 | 統合後も元の論文や記事へ戻れる。 |
話題の統合だけでなく、表示件数を絞る処理も同じ API 呼び出しの中で行う。モデルには、内容が重なる項目をまとめたうえで、重要度が高い順に最大件数まで返すよう指示している[11]。候補が最大 60 件あり、表示枠が最大 6 件であれば、統合した後にも選択が必要になる。ここでは、すべての候補を短く掲載するのではなく、一日の閲覧物として残す話題を選ぶ。
この重要度は、AI 分野における普遍的な価値を測定した数値ではない。設定された情報源から対象時間内に取得され、重複排除を通過した候補の中での相対的な順位である。収集対象に含まれない学会発表や、入力上限の外側に置かれた記事は比較対象にならない。モデルが返す順位を評価する際には、どの候補集合に対する順位なのかを同時に見る必要がある。
モデルへのツール説明では、各トピックについて、日本語のカテゴリー、40 文字以内の見出し、2 件から 4 件の箇条書き、根拠にした入力項目の番号を返すよう求めている[11]。見出しと箇条書きは閲覧画面のための文章であり、出典番号は後続プログラムが元の URL を復元するためのデータである。一つの応答の中に、人間が読む部分と、アプリケーションが処理する部分を同時に含めている。
カテゴリーは、固定された分類一覧から選ばせていない。その日の候補に応じて、「基盤モデル」「推論効率」「評価・ベンチマーク」のような短い日本語名を生成させる。固定分類を使えば、日付をまたいだ集計や検索は容易になる一方、既存の分類に収まりにくい話題を近い箱へ押し込むことになる。ai-digest は長期的な分類統計よりも、その日の内容を一覧で理解することを優先し、日次レポート内で意味が通る名称を採用している。
この選択には代償がある。同じ内容でも日によって「基盤モデル」と「大規模言語モデル」のように異なる名称が付く可能性があり、カテゴリー名を使った長期比較は安定しない。自由な分類は一日の可読性を高めるが、時系列分析に必要な分類体系を提供するものではない。日次閲覧物としての目的が、固定分類による集計より前に置かれている。
API キーによって加わる処理を整理すると、翻訳だけではないことが分かる。モデルは、候補間の関係を読み、記事単位を話題単位へ組み替え、表示件数へ収まるよう選び、日本語の見出しと箇条書きへ編集する。plain モードでも情報は集められるが、Claude を利用することで、取得結果が原文の項目一覧から、一日に読む順序を持つレポートへ変わる。
5.2 Anthropic の Messages API を処理境界として使う
ai-digest は、話題編集の呼び出しに Anthropic の Messages API を使う[12]。リクエストには、使用するモデル、最大出力トークン数、システム指示、候補項目を含む利用者メッセージ、レポート構造を表すツール定義を渡す。応答からは通常の文章ではなく、指定したツールの呼び出し内容を取り出し、トピックへ変換する。
API キーは、この呼び出しを認証するために使われる。arXiv API やニュースフィードへの接続には使用されず、HTML や画像を表示する Flask アプリケーションにも渡されない。認証情報を必要とする範囲を意味処理のバッチへ限定しているため、閲覧プロセスを外部 AI サービスから分離できる。
標準の Anthropic API では API キーを設定するが、ai-digest は Bearer トークンと接続先の基底 URL も指定できる。これにより、Anthropic の Messages API と同じ呼び出し形式を提供する別サービスへ、話題編集の接続先を切り替えられる。さくらの AI Engine は Anthropic 互換の Messages API エンドポイントを提供し、アカウントトークンを Bearer 認証に使用できる[13]。
接続先を設定として切り出した理由は、特定のモデル名をソフトウェアの処理構造へ埋め込まないためである。収集、重複排除、画像処理、保存、表示はそのまま残し、話題編集を担当するクライアント、接続先、認証方式、モデル識別子だけを交換できる。これにより、別モデルを試す際に、アプリケーション全体を別実装へ置き換える必要がなくなる。
| 設定対象 | 役割 | 変更時に維持される範囲 | 別途確認が必要な範囲 |
|---|---|---|---|
| 認証方式 | API キーまたは Bearer トークンで接続先へ認証する。 | 収集、保存、表示の処理は変わらない。 | 接続先が要求するヘッダーとトークン形式を確認する必要がある。 |
| 接続先 URL | Messages API を呼び出す事業者を切り替える。 | 候補項目と期待するレポート構造は同じものを使える。 | エンドポイントのパス、認証、機能対応を確認する必要がある。 |
| モデル識別子 | 話題統合、翻訳、分類、順位付けを行うモデルを選ぶ。 | モデル前後の通常プログラムは再利用できる。 | 日本語品質、統合判断、ツール呼び出しの安定性はモデルごとに異なる。 |
| 出力上限 | モデルが返せる応答量を制限する。 | 保存するトピックの形式は変わらない。 | 話題数と箇条書き数に対して十分な出力量があるかを確認する必要がある。 |
5.3 互換 API には名前以上の条件がある
接続先が Anthropic 互換を掲げていても、ai-digest がそのまま動作するとは限らない。ai-digest が利用するのは、メッセージを送って文章を受け取る基本機能だけではない。レポート構造を表すツール定義を送信し、特定のツールを選ぶよう強制し、応答から、tool_use 形式、すなわち指定したツール名と入力値を持つデータを取得する必要がある。
互換 API が通常のテキスト応答には対応していても、ツール定義を無視する場合がある。ツールを受け付けても、特定ツールの強制選択に対応していなければ、モデルが説明文だけを返す可能性がある。さらに、API 側が tool_use を返しても、選択したモデル自体がその機能を十分に処理できなければ、必要な項目が欠けたり、期待した型と異なる値が含まれたりする。
ai-digest は、応答の中にツール呼び出しがなければ処理を失敗として終了する。ツール呼び出しがあった場合も、出典番号が入力範囲内かを確認し、有効な箇条書きや出典を持たないトピックを除外する。互換 API との通信が成功したことと、公開可能なレポートデータが得られたことを分けて判定している。
| 確認段階 | 確認する内容 | 満たさない場合の現象 | ai-digest への影響 |
|---|---|---|---|
| 接続 | 指定した URL へ到達し、認証が受理されることを確認する。 | 認証エラー、接続エラー、対象外のエンドポイントが返る。 | 話題編集を開始できず、その日のバッチが失敗する。 |
| 要求形式 | Messages API のメッセージ、システム指示、出力上限を受け付けることを確認する。 | 未知の項目として拒否されるか、設定の一部が無視される。 | 期待した条件でモデルを呼び出せない。 |
| ツール機能 | ツール定義、特定ツールの強制選択、tool_use 応答に対応することを確認する。 | 通常の文章だけが返るか、異なる応答形式になる。 | レポート構造を抽出できず、処理を失敗として終了する。 |
| モデル出力 | カテゴリー、見出し、箇条書き、出典番号を利用可能な形で返すことを確認する。 | 項目の欠落、型の不一致、範囲外の出典番号が生じる。 | 不正な話題が除外され、利用可能な話題がなければ成果物を作れない。 |
| 内容品質 | 話題統合、日本語化、重要度、出典対応が用途に合うかを確認する。 | 通信と構造は正常でも、話題のまとめ方や表現が期待と異なる。 | 技術的には完走しても、日次レポートとしての品質が変化する。 |
このため、互換性には少なくとも三つの層がある。第一は、認証とエンドポイントへ接続できる通信上の互換性である。第二は、ツール定義や tool_use を同じ形式で扱えるプロトコル上の互換性である。第三は、同じ入力から用途に合う話題統合と日本語出力を得られる意味処理上の適合性である。最初の二つを満たしても、三つ目の結果まで同一になるわけではない。
モデルを変更すれば、同じ候補と同じツール定義を使っても、統合する項目、話題の順位、カテゴリー名、見出し、日本語表現が変わり得る。話題編集には、候補間の関係と重要度を評価する判断が含まれるためである。スキーマは出力項目の形を揃えるが、各項目へ何を書くかまでは一意に決めない。
交換可能にしているのは、結果ではなく処理位置である。どのモデルを使っても、重複排除後の候補を受け取り、同じトピック構造を返し、その後の画像処理と保存へ渡す位置に配置される。別モデルへ切り替えた際に比較できるのは、この共通境界を通過した結果であり、結果の内容が同一であることではない。
この境界を固定すると、変更後の差異を工程ごとに調べられる。収集件数や重複排除後の件数が変わった場合は、情報源、対象期間、収集器、重複判定を確認する。API 切り替え後に話題数、統合関係、日本語表現だけが変わった場合は、接続先またはモデルの意味処理を比較する。HTML、画像、日付別ファイルの構成が変わった場合は、モデルではなく後続の描画や保存処理が対象になる。
ai-digest における API の交換可能性は、生成 AI を無差別に差し替えられるという意味ではない。必要なプロトコル機能を満たす実装を、話題編集という限定された工程へ配置できるという意味である。API キーが追加する価値は、情報源への接続でもファイルの生成でもなく、候補間の意味を読み、記事の集合を一日の話題へ変換する処理にある。
6. モデルには自由文ではなくレポート構造を返させる
6.1 build_report の入力として受け取る
ai-digest は、モデルへ完成した記事本文を自由形式で書かせない。カテゴリー、見出し、箇条書き、出典番号を持つレポート構造を定義し、build_report というツールの入力として返すよう求める。Anthropic のツール定義では、ツール名、用途の説明、入力値の構造を指定し、tool_choice によって特定のツールを選択させることができる[14]。
自由文の応答は、人間がその場で読む用途には適しているが、後続のプログラムから扱うには不安定である。ある実行では冒頭に説明文が付き、別の実行では見出しが省略される可能性がある。箇条書きの数、カテゴリーの位置、出典の書式も一定しない。文章として意味が通っていても、どこからどこまでが一つの話題で、どの URL を対応させればよいかをプログラムが毎回推測することになる。
ai-digest の後続工程では、トピックごとに題名を表示し、箇条書きを列挙し、カテゴリーから表示色を決め、出典リンクを配置する。さらに、同じデータを JSON、HTML、個別画像、日次サマリー画像へ展開する。この処理には、自然な文章よりも、各値の役割と位置が決まった中間データが必要になる。ツール呼び出しを使う理由は、モデルの文章能力を高めるためではなく、確率的に生成された応答を既存のプログラムへ接続可能な形へ近づけるためである。
build_report の入力スキーマでは、topics という配列の中に複数のトピックを格納する。各トピックには、日本語のカテゴリー、40 文字以内を想定した見出し、2 件から 4 件を想定した箇条書き、根拠となる入力番号を持たせる[11]。この構造によって、モデルが何を返すべきかだけでなく、後続処理が何を受け取るかも一つの境界として定まる。
| フィールド | モデルが行う判断 | 後続処理での用途 | 構造だけでは保証できないこと |
|---|---|---|---|
| category | トピックの内容を表す短い日本語の分類名を付ける。 | レポート上の分類表示と、カテゴリーごとの表示色に使う。 | 同じ内容へ毎回同じ分類名が付くとは限らない。 |
| title | 複数の入力項目を代表する日本語の見出しを作る。 | HTML、個別画像、サマリー画像の主見出しに使う。 | 原文の限定条件や技術的な差異が正確に残るとは限らない。 |
| bullets | 話題の要点を日本語の短い文へ整理する。 | 日次レポートの本文と画像内の説明に使う。 | 重要な要点の選択や要約内容の正確性までは保証されない。 |
| source_indexes | どの入力項目がトピックの根拠になるかを選ぶ。 | 元の題名と URL を復元し、出典リンクを生成する。 | 選ばれた出典が箇条書きの全記述を十分に支えるとは限らない。 |
ツール呼び出しを強制しても、返された値が常に期待どおりであるとは限らない。現在の ai-digest は build_report の利用を tool_choice で指定しているが、ツール定義に strict は設定していない[11][14]。モデルが通常の説明文だけを返す可能性は抑えられる一方、配列内の値、文字列の長さ、件数、必須項目が厳密に守られることまで API 側へ委ねた構成ではない。
このため、API 応答を受け取った時点ではレポートを完成扱いにしない。ai-digest は tool_use の応答から build_report の入力値を取り出し、各トピックをアプリケーション内部のデータへ変換する。箇条書きは空文字を除き、最大 4 件までに制限する。出典番号は整数であり、実際の入力配列の範囲内にあるものだけを採用する。利用可能な箇条書きまたは出典を持たないトピックは破棄する[11]。
| 検査対象 | 検査内容 | 不正な場合の処理 | 防げる不具合 |
|---|---|---|---|
| ツール呼び出し | 応答内に tool_use 形式のデータが含まれるかを確認する。 | 見つからなければ日次処理を失敗として終了する。 | 説明文だけの応答を空のレポートとして保存することを防ぐ。 |
| 箇条書き | 空でない値だけを取り出し、文字列として整形する。 | 利用可能な箇条書きがなければ、そのトピックを除外する。 | 本文を持たない見出しだけの話題が掲載されることを防ぐ。 |
| 出典番号 | 整数であり、入力配列の範囲内にあるかを確認する。 | 範囲外の番号を無視する。 | 存在しない入力を参照し、誤った URL を生成することを防ぐ。 |
| トピック全体 | 利用可能な箇条書きと出典が少なくとも一つずつあるかを確認する。 | 条件を満たさないトピックをレポートから除外する。 | 根拠または説明を欠いた話題が正常な成果物として残ることを防ぐ。 |
この検査は、モデルの応答を正しい内容へ修正するものではない。見出しが原文の主張を正確に表しているか、複数の記事を同じ話題へまとめた判断が妥当か、箇条書きが重要な限定条件を落としていないかは、配列や文字列の型を確認しても判定できない。ここで検査しているのは、後続処理が利用できる最低限の形と、参照先が実在することである。
JSON Schema は、JSON 内の値の型、必須項目、配列や文字列に関する制約を表現するための語彙を定義している[15]。この仕組みによって、「topics は配列である」「title は文字列である」「source_indexes は整数の配列である」といった構造条件を記述できる。一方、「この見出しは論文の内容を正確に表している」「この話題はほかの候補より重要である」という意味上の妥当性は、JSON の構造からは判定できない。
ai-digest の構造化出力は、生成 AI の不確実性をなくすための仕組みではない。変動し得る出力のうち、後続工程へ渡してよい形を限定し、不正な参照や欠落した話題を公開前に除くための境界である。形式上の検査によってプログラムの安定性は高められるが、要約内容の検証には原典との比較という別の工程が必要になる。
6.2 出典 URL はモデルに生成させない
ai-digest は、モデルへ渡す候補項目に 0 から始まる番号を付ける。各項目には題名、出典名、概要を記載するが、モデルへ URL を書き直させることはしない。モデルは、生成したトピックの根拠として最大 3 件の source_indexes を返し、アプリケーションがその番号を元の入力配列へ照合して題名と URL を取り出す[11]。
URL は意味を説明する文章ではなく、特定の原典を指す識別情報である。モデルへ URL の再生成を任せると、文字列の一部が欠ける、存在しないパスが加わる、似た別記事の URL が返るといった可能性が生じる。見た目がもっともらしい URL であっても、実際に取得した項目と一致している保証はない。
番号による参照では、モデルが担当する範囲を「どの入力がこの話題の根拠か」という選択へ限定できる。リンク文字列そのものは、収集時に取得して保存した確定済みデータから復元する。意味上の関係付けにはモデルを使い、識別子から実データを取り出す処理には通常のプログラムを使う分担である。
| 方式 | モデルへ求める出力 | 発生し得る不整合 | ai-digest の選択 |
|---|---|---|---|
| URL を直接生成 | 根拠となるページの URL を文字列として返させる。 | 文字列の欠落、存在しない URL、入力にないページへの参照が起こり得る。 | 採用しない。 |
| 題名を再生成 | 根拠となる記事や論文の題名を書かせ、後から検索する。 | 翻訳、短縮、表記差によって元の項目と一意に対応しない。 | 出典の識別には使わない。 |
| 入力番号を選択 | 根拠となる候補の番号だけを返させる。 | 範囲外の番号や、内容と合わない番号が選ばれる可能性は残る。 | 番号を範囲検査し、元データから題名と URL を復元する。 |
番号を使っても、モデルが誤った入力を根拠として選ぶ可能性は残る。あるトピックの説明に対して、関連はあるが直接の根拠にならない記事を選ぶこともあり得る。番号方式が保証するのは、掲載されたリンクが実際の入力候補のいずれかであることまでであり、その出典が箇条書きの全内容を正確に裏付けていることではない。
それでも、参照範囲を入力集合へ限定する効果は大きい。範囲外の番号はプログラム側で無視され、有効な出典を一件も持たないトピックは掲載されない。モデルが入力に存在しない論文名や URL を作ったとしても、それを正常な出典リンクへ変換する経路がない。出典なしの文章をそのまま公開する場合と比べ、少なくとも根拠候補の実在性を確認できる。
この構成では、話題の文章と出典情報が異なる方法で作られる。見出し、カテゴリー、箇条書きはモデルが生成する。出典の題名と URL は収集済みデータから取り出す。両者を結ぶ source_indexes だけがモデルの判断になる。生成された説明と確定済みの識別情報を直接混ぜず、その間に検査可能な番号を置くことで、どこに不確実性が残るかを限定している。
ai-digest が構造化しているのは、見た目の形式だけではない。モデルが行う意味判断、プログラムが保証する識別情報、公開前に除外する異常値を別々の層へ配置している。モデルには話題の境界と根拠候補を選ばせるが、URL の生成、番号の範囲判定、出典を欠く話題の除外は任せない。自由文をレポート構造へ変える目的は、生成内容を完全に正しくすることではなく、確率的な判断が通常のソフトウェアへ影響する範囲を明示することにある。
7. AI が選ぶ前に候補範囲は決まっている
7.1 情報源と時間範囲は設定によって決まる
Claude が日次レポートの主要な話題を選ぶとき、公開されている AI 情報を自ら検索しているわけではない。標準設定で収集する論文は、arXiv の cs.AI、cs.LG、cs.CL に属する項目である。ニュースは、OpenAI、Google AI Blog、Hugging Face Blog の設定済みフィードから取得する。さらに、公開から 24 時間以内という時間条件を適用する[1]。
この時点で、モデルが比較できる対象には境界がある。設定されていない論文誌、学会サイト、大学のプレスリリース、政府資料、企業ブログ、GitHub リポジトリは候補に入らない。対象に含まれる情報源であっても、フィードに掲載されていない記事、公開日時を取得できない項目、通信障害によって取得できなかった項目は、後続の話題整理へ進まない。
最終レポートにある話題と、世の中で実際に起きた出来事の間には、収集工程による選別が存在する。ある話題が掲載されていない場合、その原因はモデルが重要でないと判断したことだけではない。情報源が設定されていなかった、対象時間から外れていた、取得に失敗したという可能性もある。モデルの選択結果を評価するには、モデルへ届く前の候補集合がどのように作られたかを確認する必要がある。
| 候補から外れる段階 | 具体的な条件 | レポートへの影響 | 確認する対象 |
|---|---|---|---|
| 情報源の設定 | arXiv カテゴリーまたはニュースフィードが収集対象に登録されていない。 | その情報源で公開された項目は、内容にかかわらず候補にならない。 | ARXIV_CATEGORIES と NEWS_FEED_URLS の設定を確認する。 |
| 公開時間の判定 | 公開日時が過去 24 時間の範囲から外れている。 | 継続的に議論されている話題でも、新着項目がなければ当日の候補に残らない。 | LOOKBACK_HOURS と各項目の公開日時を確認する。 |
| 入力データの不足 | フィードに公開日時がない、または必要な項目を解析できない。 | 記事が存在していても、日次処理の対象として判定できない。 | 情報源が提供する RSS または Atom の内容を確認する。 |
| 外部接続 | DNS、TLS、タイムアウト、配信元の障害などによって取得要求が失敗する。 | 取得できなかった情報源の項目が候補集合から欠落する。 | 収集時の警告と情報源ごとの取得件数を確認する。 |
時間幅を 24 時間に限定すると、一回の実行で処理する件数と API 利用量を抑えられる。前回の実行と対象期間を連続させれば、毎日の新着を小さな単位で確認できる。反面、処理が一日以上停止した場合や、前日に選ばれなかった項目を再評価したい場合でも、対象期間を変更しない限り自動的には候補へ戻らない。
情報源を増やせば候補の網羅性は高まるが、入力件数、重複、取得障害、確認すべき利用条件も増える。大学や企業の発表を追加すれば、arXiv に現れない製品情報や運用事例を拾える一方、同じ研究を扱う論文、公式発表、解説記事の重複が増える。収集範囲の拡張は、単に取得 URL を追加する作業ではなく、後続の統合と選択へ渡す候補集合を再設計する変更になる。
ai-digest の日次レポートは、AI 分野全体の網羅的な観測結果ではない。設定された情報源と時間範囲から得られた項目を材料として作る閲覧物である。この限定によって、レポートが何を観測し、何を観測していないかを説明できる。観測範囲を明示できることは、網羅性を主張することよりも、出力の解釈を安定させる。
7.2 最大 60 件と原典優先が入力を形作る
収集された項目は、重複排除を経た後に言語モデルへ渡される。ただし、モデルが受け取る候補は最大 60 件であり、61 件目以降は API 呼び出しの入力に含まれない[11]。この上限はモデルが重要度を評価した後に適用されるのではなく、評価を始める前に通常のプログラムが適用する。
最大件数を設ける直接の理由は、API へ渡す入力長、処理時間、利用料金の上限を予測可能にすることにある。候補数を制限しなければ、発表が集中した日の入力だけが大きくなり、通常の日と比べて応答時間や費用が急増する。さらに、モデルが扱えるコンテキスト長に収まっていても、候補が増えるほど話題間の比較と統合が複雑になり、安定した件数のレポートを得にくくなる。
この運用上の制御は、情報選択にも直接影響する。60 件より後ろに置かれた項目は、内容が重要であっても、モデルによる比較を受けられない。レポートに掲載されなかった理由は「モデルが低く評価した」ことではなく、「モデルへ入力されなかった」ことになる。入力上限は計算資源の設定であると同時に、ソフトウェアが認識できる範囲を定める編集規則でもある。
ai-digest は、収集結果を論文、ニュースの順に連結する。重複排除でも先に現れた項目が残るため、原論文と紹介記事の題名が近い場合は論文が優先されやすい。さらに、重複排除後の先頭 60 件をモデルへ渡すため、論文が多い日にはニュースが入力上限の外側へ押し出される可能性がある。
| 処理順序 | 実装上の動作 | 直接得られる効果 | 生じ得る偏り |
|---|---|---|---|
| 論文の収集 | 設定された arXiv カテゴリーから論文を取得する。 | 研究成果の一次資料を候補へ含められる。 | カテゴリー数と取得件数が多い日は、候補の前半を論文が占める。 |
| ニュースの収集 | 論文の後ろへニュースフィードの項目を追加する。 | 製品発表、公式解説、運用情報を補える。 | 入力上限へ到達した場合、後方のニュースがモデルへ渡らない。 |
| 重複排除 | URL または題名が重複したとき、先に現れた項目を残す。 | 原論文を一次資料として残しやすい。 | ニュースに固有の提供条件や社会的文脈が失われる場合がある。 |
| 入力件数制限 | 重複排除後の先頭から最大 60 件をモデルへ渡す。 | 入力長、処理時間、API 利用量の上限を保てる。 | 並び順の後方にある項目は、内容を評価される前に除外される。 |
原典を優先する方針は、出典の追跡という目的に合っている。研究成果について、第三者の記事だけを残すより、手法、実験条件、限定事項を確認できる論文を残した方が、レポートから一次資料へ戻りやすい。しかし、論文だけでは製品の提供地域、料金、利用条件、導入企業の反応、規制上の論点まで把握できないことがある。一次資料の優先と、周辺情報の保持は同じ目的ではない。
候補が少ない日には、この順序による影響は表面化しにくい。重複排除後の件数が 60 件以内なら、論文とニュースの全候補がモデルへ渡る。発表が集中した日だけ、固定された並び順が入力採否を決める。平常時に問題が見えない設計でも、入力上限へ到達したときには、その順序が明示的な選択規則として働く。
入力構成を均衡させる方法としては、論文とニュースに別々の枠を設ける、情報源ごとに最大件数を定める、公開日時順に全項目を混在させる、前日にモデルへ渡らなかった項目を次回へ繰り越すといった方式が考えられる。ただし、いずれも異なる編集方針を持つ。論文枠とニュース枠を固定すれば情報源の多様性は保ちやすいが、論文だけが多い日にもニュース用の枠が残る。繰り越しを行えば取りこぼしは減るが、「過去 24 時間の日次レポート」という時間境界が曖昧になる。
現在の ai-digest は、原典を先に置き、最大入力件数を固定する単純な規則を採用している。この規則は再現しやすく、処理量も予測しやすい。一方、候補が上限を超えた場合には、話題の重要度より先に情報源の種類と並び順が入力を決める。モデルの出力を検討するときは、最大 60 件という数値だけでなく、その 60 件がどの順序で構成されたかを見る必要がある。
7.3 最大 6 トピックは表示上の制約であり編集方針でもある
モデルへ最大 60 件の候補を渡しても、標準設定でレポートに残すのは最大 6 トピックである[1]。この件数は、一枚のサマリー画像を 6 つの領域に分け、各領域へ見出し、箇条書き、画像を配置する表示形式と対応している。モデルが処理可能な最大件数から決めたのではなく、完成したレポートをどの量で読ませるかという出力側の条件から定めている。
候補が 6 件以下なら、重複や不正出力を除き、各項目を一つずつ表示できる。候補が 6 件を超えると、複数の項目を同じ話題へまとめても、すべてを掲載できるとは限らない。モデルには、統合後の話題を相互に比較し、表示枠へ残すものを選ぶ処理が加わる。サマリー画像の区画数が、話題選択の必要性を発生させている。
| 制約 | 直接の目的 | 候補集合への作用 | レポートで失われる可能性がある情報 |
|---|---|---|---|
| 過去 24 時間 | 一回の実行を一日の新着確認として扱う。 | 対象時間外の項目を収集段階で除く。 | 前日に選ばれなかった話題や、数日にわたり進展する動向が残らない。 |
| 設定済み情報源 | 収集対象と取得処理を管理可能な範囲へ限定する。 | 未登録の媒体を観測対象から外す。 | 論文誌、学会、政府資料、未登録企業などの発表が含まれない。 |
| 最大 60 入力 | API の入力長、利用料金、処理時間を制御する。 | 並び順の先頭から一定件数だけを意味評価へ渡す。 | 61 件目以降は内容を比較されず、重要な項目でも選択対象にならない。 |
| 最大 6 トピック | 一枚のサマリー画像と短い閲覧時間へ収める。 | 統合後の話題から表示するものを選ぶ。 | 関連性があっても、上位の表示枠へ入らない話題は掲載されない。 |
| 最大 3 出典 | 一つの話題に付くリンク数を読みやすい範囲へ抑える。 | モデルが選んだ出典番号の先頭から一定件数だけを残す。 | 同じ話題を扱うすべての論文や記事を一覧できるわけではない。 |
| 最大 4 箇条書き | HTML と画像内へ収まる説明量にする。 | 生成された要点を一定件数へ切り詰める。 | 実験条件、制約、反対意見などが要点から外れる場合がある。 |
最大 6 件という設計は、情報を読みやすくするために、掲載しない話題が生じることを受け入れている。入力をすべて残す一覧では、利用者が読む対象を後から選ぶ。ai-digest では、レポート生成の段階で選択を行い、利用者へ提示する件数を先に減らす。読む負担を小さくする代わりに、選択過程がレポートの内容を大きく左右する。
一枚の画像へ収めるという条件は、見た目だけの制約ではない。表示領域が固定されれば、見出しの長さ、箇条書きの件数、画像の比率、出典数にも上限が生じる。その結果、原典に含まれる詳細をどこまで残し、どこを省くかという編集判断が必要になる。表示形式が情報を受動的に描画するのではなく、保存される情報の粒度を上流から規定している。
表示件数を増やせば、除外される話題は減る。一方、サマリー画像が長くなり、毎日の確認時間も増える。話題数を減らせば一覧性は高まるが、少数の統合判断と重要度評価に依存する割合が大きくなる。最適な件数はモデル性能だけでは決まらず、レポートを一日にどれだけの時間で確認するか、原典へ何件移動できるかという利用条件によって変わる。
ai-digest が作るのは、その日に存在した AI 情報の完全な記録ではない。設定された情報源から 24 時間以内の項目を取得し、順序と入力上限によって最大 60 件へ絞り、意味的に統合した後、最大 6 件を表示する。この各段階で候補集合は狭くなる。最終レポートはモデルだけが選んだ結果ではなく、収集設定、実装上の順序、計算資源の上限、表示面の大きさが共同で作った結果である。
この構造によって、AI に任せた判断と、ソフトウェア設計者が先に固定した判断を区別できる。モデルは与えられた候補の関係と重要度を評価するが、どの情報源を見るか、何時間を対象にするか、何件まで読ませるか、何件を表示するかは評価しない。ai-digest における話題選択は、AI が単独で行う選択ではなく、人間が定めた候補範囲の内部で行われる限定された編集である。
8. 生成が失敗しても過去のレポートは読める
8.1 日次バッチと閲覧アプリケーションを分ける
ai-digest では、論文やニュースを収集してレポートを生成する処理と、生成済みのレポートを閲覧する処理を別のプロセスへ分けている。日次バッチを担当する cli.py は、外部情報源への接続、Claude API の呼び出し、画像処理、JSON と HTML の保存を行う。一方、Flask で動く app.py は読み取り専用であり、情報収集も Claude API の呼び出しも行わない[16]。
閲覧アプリケーションが参照するのは、日次バッチによって既に保存された JSON と画像である。日付一覧の表示、一日分のレポート、サマリー画像、個別画像の配信は、保存済みファイルだけで完結する。レポートを開くたびに情報源へ接続したり、モデルへ同じ入力を送ったりする必要はない。
生成と閲覧を同じ要求経路へ置くと、一回の画面表示に複数の外部条件が加わる。Web 要求を受けてからフィードを取得し、モデルへ要約を依頼し、画像を探し、HTML を組み立てる構成では、いずれか一つが遅れるだけで画面の応答も遅くなる。API の利用制限や一時障害が発生すれば、保存済みの過去レポートまで表示できなくなる可能性がある。
ai-digest は、外部依存を伴う処理を一日一回のバッチへ集約する。生成に数十秒かかっても、その待ち時間は閲覧要求へ持ち込まれない。日中に同じレポートが何回読まれても、追加の API 呼び出しや要約費用は発生しない。生成回数は日次処理の回数で決まり、閲覧回数から独立している。
| 観点 | 閲覧時に生成する構成 | ai-digest の事前生成構成 | 運用上の帰結 |
|---|---|---|---|
| 応答時間 | 収集、API 応答、画像取得が終わるまで画面を完成できない。 | 保存済みの JSON と画像を読み取って表示する。 | 閲覧時間が外部 API の応答速度に左右されにくい。 |
| 外部障害 | 情報源またはモデル API の障害が、そのまま画面表示の失敗になる。 | 当日の新規生成は失敗しても、過去の保存済みレポートは表示できる。 | 障害範囲を新しい日付の追加へ限定できる。 |
| API 利用量 | 同じ日付を開くたびに生成処理が繰り返される可能性がある。 | 日次バッチで一度だけ生成し、その結果を繰り返し読む。 | 閲覧数が増えてもモデルの利用料金は増えない。 |
| 認証情報 | Web プロセスが API キーを保持する必要がある。 | API キーは日次バッチだけに渡し、閲覧側には渡さない。 | 公開要求を処理するプロセスから認証情報を分離できる。 |
| 再現性 | 閲覧時刻やモデル応答によって、同じ日付の表示内容が変わり得る。 | 保存したレポートを、その日の確定結果として表示する。 | 同じ日付を開いたときに同じ内容を確認できる。 |
この分離は、API キーの配置にも影響する。Claude API を呼び出すのは日次バッチだけであるため、インターネットから要求を受ける Flask プロセスへ API キーを設定する必要がない。閲覧機能が侵害された場合の影響を完全になくすものではないが、少なくとも閲覧処理から外部 AI サービスを操作する認証情報を外せる。
閲覧側が外部ネットワークへ接続しないことは、障害原因の切り分けにも役立つ。過去レポートを表示できない場合は、保存ファイル、日付の指定、Flask の経路、ファイル権限などを調べればよい。arXiv、ニュースフィード、Claude API の状態は閲覧処理に関与しない。生成時の問題と表示時の問題を、別の調査対象として扱える。
日次バッチが失敗した場合、その日付の新しいレポートは作られない。収集件数がゼロだった場合、API 呼び出しが失敗した場合、有効なトピックを得られなかった場合には、処理は正常な日次レポートを残さず終了する。一方、それ以前の日付に保存された JSON や画像は書き換えられないため、既存のアーカイブは引き続き閲覧できる。
この構成が保証するのは、更新の成功ではなく、更新失敗の波及範囲を狭めることである。当日の情報を得られないという欠落は残るが、一回の生成障害によってサービス全体が読めなくなる事態は避けられる。ai-digest では、日次レポートを作る可用性と、作成済みレポートを読む可用性を別々に成立させている。
8.2 外部画像の取得には代替経路を持たせる
ai-digest は、各トピックへ一つの画像を付ける。出典が arXiv 論文の場合は、ar5iv が提供する HTML から最初の figure を探す。ニュース記事の場合は、ページ内の Open Graph または Twitter Card の代表画像を探す[17]。Open Graph の og:image は、Web ページを代表する画像の URL を表すメタデータである[18]。ar5iv は、arXiv 上の論文を LaTeXML で変換し、HTML5 として閲覧できるようにするサービスである[19]。
実画像を取得できれば、見出しだけでは分からない情報を補える。論文の構成図、モデルの処理経路、評価グラフ、研究対象の写真が得られれば、レポートを開いた時点で話題の種類を視覚的に判別しやすくなる。ニュースの代表画像も、製品、組織、発表内容を一覧上で区別する手掛かりになる。
ただし、画像の取得条件は ai-digest だけでは制御できない。出典ページへ接続できること、HTML を解析できること、期待するメタデータや figure が存在すること、画像 URL が有効であること、対応可能な形式と大きさであることが必要になる。配信元が HTML の構造を変更すれば、それまで取得できていた画像が見つからなくなる場合もある。
外部画像を必須条件にすると、一つのトピックの装飾的な要素が、日次レポート全体の生成可否を決める。本文と出典が正常に生成されていても、出版社の画像サーバーが一時的に応答しないだけで成果物を残せなくなる。情報の意味内容を生成する工程と、表示を補助する外部画像の取得工程では、失敗時に止めるべき範囲が異なる。
ai-digest は、出典に記載された順に画像取得を試し、利用可能な画像が得られた時点で採用する。すべての取得に失敗した場合、または画像取得を無効にして実行した場合は、カテゴリーと見出しを使ったカードを Pillow で生成する[17]。画像領域そのものをなくすのではなく、ローカルで確実に作れる最低限の表示へ切り替える。
| 段階 | 取得対象 | 得られる情報 | 失敗時の処理 |
|---|---|---|---|
| 論文画像 | ar5iv の HTML 内にある論文図を探す。 | 研究対象、モデル構成、実験結果などを視覚的に示せる。 | 利用可能な図がなければ、ほかの出典または代替カードへ進む。 |
| ニュース画像 | Open Graph または Twitter Card の代表画像を探す。 | 製品、組織、発表内容を一覧上で識別しやすくする。 | メタデータや画像を取得できなければ、次の出典を試す。 |
| ローカルカード | トピックのカテゴリーと見出しから画像を描画する。 | 話題の名称と分類を一定のレイアウトで表示する。 | 外部サイトへ依存せず、画像領域を確保する。 |
この代替経路によって、外部画像の取得失敗は表示品質の低下として扱われる。論文図を取得できた場合に比べれば、代替カードから読み取れる情報は少ない。見出しとカテゴリーは分かるが、モデル構造や評価結果までは確認できない。それでも、HTML とサマリー画像の配置は維持され、ほかのトピックとの一覧性も崩れない。
失敗時にすべてを維持しようとすると、外部画像を別の検索サービスから探す、生成 AI で代替画像を作る、複数形式へ変換するといった追加処理が必要になる。処理経路が増えるほど、新たな通信障害、利用料金、権利確認、誤った画像を対応させる危険も増える。ai-digest は、外部画像を得られない場合に内容を推測した画像を作るのではなく、既に確定しているカテゴリーと見出しだけを描画する。
ここで維持しているのは、実画像と同等の情報量ではなく、日次レポートとしての最低限の構造である。画像取得が成功すれば視覚情報を追加し、失敗すれば文字情報だけのカードへ縮退する。制御できない外部依存を表示品質の改善へ使いながら、その失敗を成果物全体の欠落へ広げない設計になっている。
8.3 日付別の通常ファイルとして保存する
生成されたレポートは、日付を名前にしたディレクトリへ保存される。各ディレクトリには、話題と実行統計を持つ report.json、一日分を単独で表示する index.html、表示用のスタイルシート、全トピックをまとめた summary.png、個別トピックの画像が置かれる[20]。データベースへ登録するのではなく、通常のファイルによって日次アーカイブを構成している。
この保存方式は、ai-digest が扱うデータの単位と一致している。一回の実行で作られるのは、一日最大 6 件の読み取り中心のレポートである。生成後に複数利用者が同じレコードを頻繁に更新する処理はなく、過去の日付を条件付きで書き換える必要もない。日付ごとのまとまりを一つのディレクトリとして扱えば、保存場所と閲覧単位が同じになる。
| ファイル | 保持する内容 | ほかのファイルとの関係 | 再利用方法 |
|---|---|---|---|
| report.json | 話題、箇条書き、出典、画像名、収集件数、使用モデル、生成日時を保持する。 | HTML とサマリー画像を生成する元データになる。 | API を呼び出さず、表示形式だけを再生成できる。 |
| index.html | 一日分の話題、箇条書き、出典、画像を表示する。 | 同じ日付ディレクトリ内の画像とスタイルシートを参照する。 | ディレクトリ単位で静的 Web サーバーへ配置できる。 |
| style.css | 単独 HTML のレイアウトと表示規則を保持する。 | index.html から参照される。 | 内容を再生成せず、外観を調整できる。 |
| summary.png | 最大 6 件の話題を一枚の画像へまとめる。 | report.json と各トピック画像から生成される。 | 一日の概観、共有用画像、アーカイブの入口として利用できる。 |
| topic-N 画像 | 外部から取得した画像またはローカル生成した代替カードを保持する。 | HTML と summary.png の双方で使われる。 | 同じ画像取得処理を繰り返さずに再描画できる。 |
report.json を意味内容の保存先とし、HTML と PNG を表示成果物として分けることで、要約とレイアウトを別々に更新できる。文字サイズ、余白、画像配置、スタイルシートを変更した場合でも、保存済み JSON を読み込んで再描画すればよい。レイアウトを試すたびに Claude API を呼び出し、話題の統合や日本語要約を作り直す必要はない。
この再利用には、費用だけでなく内容固定の意味がある。表示変更のたびにモデルを再実行すると、同じ入力であっても話題の順位、見出し、カテゴリー、箇条書きが変わる可能性がある。保存済み JSON から描画すれば、意味内容を同じ状態に保ったまま、表示処理だけを比較できる。モデル出力の変化と、レイアウト変更の効果を混同せずに済む。
日付ディレクトリは、バックアップと移動も単純にする。一日分の成果物が一か所へまとまっているため、ディレクトリ単位で複製、圧縮、削除、静的公開ができる。データベースのダンプ、移行手順、スキーマ更新を用意しなくても、現在の保存量と利用方法で必要な運用を実現できる。
通常ファイルを選んだことは、データベースが不要な技術であることを意味しない。全文検索、複数日を横断するカテゴリー集計、利用者ごとの既読管理、同時編集、細かな更新履歴が必要になれば、日付ディレクトリを順番に読むだけでは処理しにくくなる。保存済みデータの件数が増えれば、一覧取得や横断分析の費用も増える。
現在の ai-digest が必要とするのは、一日分の結果を保存し、過去の日付から読み出し、表示だけを再生成できることである。この条件では、通常ファイルは保存内容を直接確認でき、障害時にも特別な問い合わせ手段を使わず調査できる。データベースを導入していないことは、構成要素を減らすこと自体が目的なのではなく、現在の更新単位と読み取り方法に対して追加の保存層が必要ないという判断である。
生成系と閲覧系の分離、外部画像の代替経路、日付別ファイルによる保存は、それぞれ異なる失敗へ対応している。API や収集先が失敗した場合は過去の閲覧を残し、画像だけを取得できない場合は表示品質を下げてレポートを完成させ、レイアウトを変更する場合は意味処理を再実行せず保存済み JSON を使う。すべての障害を隠すのではなく、失敗した工程に応じて失う機能の範囲を限定している。
ai-digest の日次運用は、毎日必ず新しいレポートを生成できることによってだけ成立しているのではない。新しい生成に失敗しても過去分を読み続けられ、外部画像がなくても文字情報を残せ、表示変更だけなら API を使わず再生成できる。継続利用を支えているのは正常時の一連の処理に加え、各工程が失敗したときに何を諦め、何を維持するかを分けた構成である。
9. ai-digest を作って見えたのはモデルの外側だった
9.1 モデルが担当するのは一つの工程である
ai-digest の成果物で最も目立つのは、日本語の見出しと箇条書きである。英語で公開された論文やニュースが日本語へ整理され、複数の項目が一つの話題として表示されるため、利用者から見れば言語モデルがレポート全体を作っているように見える。しかし、Claude API が受け取る時点で、処理対象は既に収集、時刻判定、形式統一、重複排除を経ている。API の応答後にも、出典番号の検査、画像処理、ファイル保存、HTML 生成、閲覧処理が続く。
モデルの前にある工程は、何を読ませるかを決める。設定された arXiv カテゴリーとニュースフィードから項目を取得し、過去 24 時間という条件で対象を絞り、URL と題名から明白な重複を除く。さらに、入力順序と最大 60 件という上限によって、モデルが比較できる候補集合が確定する。Claude は世界中の AI 情報から重要なものを探すのではなく、この段階までに作られた候補だけを読む。
モデルの後にある工程は、生成結果を公開可能な成果物へ変える。モデルが返した出典番号を収集済みの項目へ照合し、範囲外の番号を除外する。有効な箇条書きや出典を持たない話題は掲載しない。残った話題へ画像を付け、日付別の JSON、HTML、個別画像、サマリー画像として保存する。モデルの応答が得られたことと、日次レポートが完成したことの間には、通常のプログラムによる検査と変換がある。
| 処理領域 | 主な処理 | その領域が決めること | 失敗した場合 |
|---|---|---|---|
| モデルより前 | 情報源の選定、収集、時刻判定、共通形式への変換、重複排除、入力件数制限を行う。 | モデルが観測し、比較できる候補の範囲を決める。 | 重要な項目でも候補に入らず、モデルによる評価を受けない。 |
| モデル | 意味の近い項目を統合し、日本語化、分類、順位付け、要約を行う。 | 候補をどの話題へまとめ、限られた表示枠へ何を残すかを決める。 | 話題の統合や日本語表現が不適切になり、利用可能な出力を得られない場合がある。 |
| モデルより後 | 出典番号の検査、異常な話題の除外、画像処理、保存、描画、閲覧を行う。 | 生成結果のうち、どの部分を正常な成果物として公開できるかを決める。 | モデル応答が存在しても、日次レポートとして保存されない。 |
既稿では、生成 AI の価値はモデル単体の性能だけでは決まらず、データ、権限、既存システム、評価、業務工程へ接続されて初めて具体的な成果になると整理した[21]。ai-digest では、この命題が小さな日次処理として現れている。Claude が担当するのは、通常の文字列比較では扱いにくい意味上の関係を読み、記事の集合を話題へ再構成する工程である。収集先への接続、日時の比較、URL の保持、ファイルの生成、Web での公開までを担当するわけではない。
通常のプログラムだけでも、新着項目を並べた一覧は作れる。plain モードが示すように、収集、重複排除、画像処理、保存、閲覧は言語モデルなしでも成立する。ただし、題名の異なる論文とニュースを同じ出来事として統合し、複数の候補を比較して日本語の話題へ編集する処理は弱くなる。反対に、言語モデルへ論文や記事を渡せば要約は得られるが、定期収集、対象期間、URL の整合性、保存方式、閲覧時の可用性は別に実装しなければならない。
両者を組み合わせる意味は、通常のプログラムを生成 AI で置き換えることにはない。入力と出力を機械的に保証できる工程は通常のコードへ残し、内容を読まなければ決められない箇所だけをモデルへ渡す。ai-digest における生成 AI の役割は、ソフトウェア全体を自動化することではなく、決定論的な処理だけでは埋めにくい意味処理の区間を担当することにある。
9.2 モデルへ任せない判断が結果を形作る
既稿では、AI に出力を任せる前に、人間が問い、判断軸、優先順位、任せない領域を決める必要があると論じた[22]。ai-digest では、これらの判断が抽象的な方針ではなく、環境変数、固定値、処理順序、失敗条件として実装されている。
どの arXiv カテゴリーを見るか、どのニュースフィードを読むか、何時間前までの項目を対象にするかは、収集設定が決める。論文をニュースより先に並べること、重複した場合に先の項目を残すこと、最大 60 件までをモデルへ渡すことは、通常のコードが決める。最大 6 トピックとすること、各話題へ付ける出典を最大 3 件とすること、箇条書きを最大 4 件とすることも、モデルが変更できない外部条件である。
モデルは、この枠内で項目間の関係と重要度を評価する。設定されていない情報源を追加することはなく、61 件目以降を自ら読み直すこともない。最大 6 件では足りないと判断して表示枠を増やすこともできない。AI に選択を任せていても、選択肢の作成、比較可能な件数、出力可能な量は、モデルを呼び出す前に決まっている。
| 判断 | 判断主体 | 実装上の表れ | 最終結果への影響 |
|---|---|---|---|
| 観測する分野 | ソフトウェアの設定者 | arXiv カテゴリーとニュースフィードを指定する。 | 設定外の分野や媒体は、重要度にかかわらず候補にならない。 |
| 対象とする時間 | ソフトウェアの設定者 | LOOKBACK_HOURS で公開からの時間を制限する。 | 対象時間外の項目はモデルへ届かない。 |
| 原典の優先 | 実装上の処理順序 | 論文をニュースより先に並べ、重複時には先の項目を残す。 | 論文が一次資料として残りやすくなる。 |
| 評価する最大件数 | 実装上の固定値 | 重複排除後の先頭から最大 60 件をモデルへ渡す。 | 後方の項目は意味評価を受けない。 |
| 話題の統合と順位 | 言語モデル | 候補間の内容を比較し、話題を構成して重要度順に並べる。 | 同じ候補でもモデルによって統合関係や順位が変わり得る。 |
| 表示する最大件数 | ソフトウェアの設定者 | MAX_TOPICS で最大 6 トピックへ制限する。 | 選ばれなかった話題はレポートへ表示されない。 |
この構造を無視すると、レポートの欠落をすべてモデルの判断として解釈してしまう。ある企業の発表が掲載されなかった理由は、モデルが重要でないと判断したからとは限らない。その企業のフィードが設定されていなかった、公開日時を取得できなかった、入力上限より後方に置かれたという場合もある。最終出力だけを見ても、どの段階で候補から外れたかは区別できない。
人間が先に判断範囲を定めることは、モデルの自由度を不当に奪うことではない。日次レポートの対象範囲と利用条件を説明可能にするための前提である。観測対象が明示されていれば、「このレポートにないから重要でない」という過剰な解釈を避けられる。入力上限と表示上限が分かっていれば、掲載件数が少ないことを網羅性の証明と取り違えずに済む。
ai-digest の出力が表しているのは、世界の AI 動向そのものではない。設定された情報源から一定時間内に取得できた項目を、所定の順序と入力上限でモデルへ渡し、最大 6 件へ編集した結果である。この限定を明示することで、結果の有用性と射程を同時に説明できる。AI の判断を評価する前に、AI が判断できる範囲を設計した側の選択を確認する必要がある。
9.3 表示物を残すことと判断過程を残すことは異なる
既稿のローカル RAG 構築では、画面に自然な回答が表示されたことだけで処理全体の成立を判断せず、文書抽出、分割、埋め込み、保存、検索、生成を別々に観測する必要を示した[23]。ai-digest にも同じ区別がある。完成した HTML を読み返せることと、なぜその話題が選ばれ、別の候補が除外されたかを後から再現できることは別の能力である。
現在の report.json には、最終的に採用された話題、見出し、箇条書き、出典、画像名と、収集件数、重複排除後の件数、トピック数、使用モデル、生成日時が保存される[8][20]。この情報があれば、過去の日次レポートを再表示し、同じ話題内容から HTML とサマリー画像を作り直せる。
一方、最終成果物へ至る途中のデータは保存していない。収集された全項目、重複として除かれた項目、モデルへ渡した最大 60 件の完全な内容、API の生応答、モデルが返した後に破棄されたトピック、採用されなかった候補、情報源ごとの取得失敗は report.json から確認できない。保存された件数から処理規模は分かるが、個々の項目がどの段階を通過したかまでは追跡できない。
| 確認したいこと | 現在の保存結果で確認できること | 現在の保存結果では確認できないこと | 追加する記録 |
|---|---|---|---|
| 何件を処理したか | 収集件数、重複排除後の件数、最終トピック数を確認できる。 | 各情報源から何件取得し、どの理由で何件を除いたかは分からない。 | 情報源別件数、除外段階、除外理由を記録する。 |
| どの項目をモデルへ渡したか | 採用トピックに結び付いた出典を確認できる。 | 入力上限内の全候補と、61 件目以降にあった項目は分からない。 | モデル入力に使った候補一覧と入力順序を保存する。 |
| なぜ話題が掲載されたか | 掲載後の見出し、箇条書き、出典を確認できる。 | モデルがどの候補を統合し、どの候補を除外したかは再現できない。 | API の生応答と、変換前の tool_use 入力を保存する。 |
| 不正な応答があったか | 正常に保存されたトピックだけを確認できる。 | 範囲外の出典番号や、箇条書きを欠いて破棄されたトピックは残らない。 | 検証エラーと破棄理由を構造化ログとして残す。 |
| 同じ結果を再現できるか | 保存済みトピックから HTML と PNG を再描画できる。 | 同じ入力を同じモデルへ送り、同じ編集結果を得たかは確認できない。 | モデル識別子、入力、応答、主要な生成設定を保存する。 |
| 費用と性能を比較できるか | 使用したモデル名と生成日時を確認できる。 | 入力トークン、出力トークン、料金、API 応答時間、全処理時間は分からない。 | API 利用量と工程別処理時間を記録する。 |
保存済み JSON から HTML と PNG を再生成できるため、表示成果物の再現性はある。同じ見出し、箇条書き、出典を使い、レイアウトだけを変更して比較できる。しかし、モデルへ入力した候補集合が残っていなければ、別のモデルで同じ候補を再編集する比較はできない。API の生応答がなければ、モデルが不正な値を返したのか、アプリケーション側の変換で除外されたのかも判定しにくい。
再描画と再生成は、同じ「再現」という言葉で扱われやすいが、必要な記録が異なる。再描画は、確定した話題データから HTML や画像を作り直す処理である。再生成は、収集項目から重複排除とモデル編集を再び実行し、同じ結果になるかを確認する処理である。前者には report.json があればよいが、後者には元の候補集合、順序、プロンプト、モデル、API 応答が必要になる。
中間データを保存すれば観測可能性は高まるが、保存量と管理対象も増える。論文概要やニュース要約を全件残せば、日次レポートより大きなデータ集合を扱うことになる。API 応答を保存する場合は、利用条件、機密情報の混入、保存期間も検討しなければならない。詳細ログを追加することは、単純な機能追加ではなく、ai-digest を閲覧ツールから検証基盤へ近づける変更になる。
現在の保存方式は、一日最大 6 件のレポートを軽量に残し、過去分を読み返し、表示だけを再生成する目的に適している。モデルの比較、要約誤りの原因調査、情報源の偏りの測定、API 費用の評価まで行う場合には不足する。この不足は、日次閲覧物としての失敗を直ちに意味するものではなく、現在の保存対象が完成結果へ限定されていることから生じる。
ai-digest を作ったことで、生成 AI の実装における観測対象も具体化した。画面に表示された日本語だけを見ても、候補範囲、重複排除、入力上限、モデル判断、検証処理のどこが結果を決めたかは分からない。モデルの外側にある工程を分離して記録して初めて、生成内容の変化を原因別に調べられる。
モデルの外側とは、生成 AI と無関係な周辺処理を指すのではない。何をモデルへ見せるか、どの出力を採用するか、何を保存して後から検証できるようにするかを決める領域である。ai-digest の日次レポートは Claude の要約能力だけから生まれたものではなく、この前後の境界によって形を与えられている。
10. ai-digest がまだ解決していないこと
10.1 情報源の範囲が出力の上限になる
ai-digest がレポートへ載せられるのは、設定された収集経路から取得できた情報だけである。標準設定では、arXiv の一部カテゴリーと、OpenAI、Google AI Blog、Hugging Face Blog のフィードを対象とする[1]。学会の採択一覧、査読済み論文誌、大学のプレスリリース、政府の政策資料、企業の全発表、GitHub 上で公開された新しい実装は、それぞれに対応する収集器またはフィードを追加しない限り候補へ入らない。
この制約は、モデルを高性能なものへ変更しても解消しない。Claude が判断できるのは、収集と重複排除を経て入力された項目の間だけである。収集されなかった発表について、モデルが重要性を評価したり、既存の話題へ関連付けたりすることはできない。最終レポートの網羅性には、モデル性能より前に情報源の構成による上限がある。
情報源を増やせば、現在は観測できない種類の情報を取得できる。学会サイトを加えれば採択動向を追え、政府資料を加えれば制度変更を扱え、GitHub を加えれば論文公開前後の実装状況を確認できる。一方、同じ研究が論文、公式発表、リポジトリ、解説記事として繰り返し現れるため、取得件数と重複判定の負荷も増える。
| 追加する情報源 | 得られる情報 | 新たに必要となる処理 | レポートへ生じ得る偏り |
|---|---|---|---|
| 学会と論文誌 | 採択結果、査読済み論文、会議日程を取得できる。 | 採択日、公開日、開催日の違いを区別し、arXiv 版との重複を判定する必要がある。 | 同じ研究が投稿版、採択版、出版版として複数回現れる。 |
| 大学と研究機関 | 研究成果の背景、研究者の説明、社会的な意義を補える。 | 論文との対応付けと、広報表現を原論文の主張から区別する必要がある。 | 発表能力の高い組織がレポート上で目立ちやすくなる。 |
| 政府と標準化機関 | 政策、規制、調達、標準化の進展を扱える。 | 施行日、公開日、意見募集、最終決定を別の状態として管理する必要がある。 | 研究開発と制度動向を同じ重要度基準で比較しにくくなる。 |
| GitHub | 実装公開、更新頻度、ライセンス、利用方法を確認できる。 | リポジトリの複製、派生実装、更新通知を整理する必要がある。 | 更新回数の多さが技術的重要性として過大に見える場合がある。 |
| 企業の製品発表 | 提供地域、料金、利用条件、導入事例を補える。 | 研究成果、製品提供、販売促進表現を分けて扱う必要がある。 | 発表頻度の高い企業が候補集合を占めやすくなる。 |
候補数が増えれば、最大 60 件という入力上限へ到達する日も増える。現在の実装では、上限を超えた項目はモデルによる意味評価を受けない[11]。情報源を追加して取得範囲を広げても、入力順序や情報源別の配分を見直さなければ、新しく追加した媒体が候補の後方へ置かれ、最終レポートへ反映されない可能性がある。
収集範囲の拡張には、取得可能性とは別に、日次レポートへ必要な情報かという判断が伴う。製品提供条件は研究論文だけでは得られないが、すべての製品更新を収集すれば研究動向が埋もれる。政策資料は社会的な影響を理解するために必要だが、論文と同じ尺度で重要度を比較すると、どちらかが恒常的に優先される可能性がある。情報源の追加は、単なる入力件数の増加ではなく、レポートが何を AI 動向として扱うかを変更する。
外部 API やフィードを継続利用する場合は、提供元の条件も処理設計へ含める必要がある。arXiv は API 利用者に対して利用条件の確認と、arXiv データを使用していることの表示を求めている[2]。取得処理が技術的に成功していても、要求される謝辞、アクセス頻度、表示条件を満たしていなければ、公開ソフトウェアとしての運用は完成しない。
現在の ai-digest は、限定された情報源から一日分の閲覧物を作るという目的に合わせ、観測範囲を小さく保っている。この範囲を超えて AI 分野の横断的な観測基盤へ発展させる場合には、収集器を増やすだけでは足りない。情報源別の役割、候補配分、重複の優先規則、利用条件、入力上限を一体として再設計する必要がある。
10.2 構造化出力だけでは内容品質を保証できない
ai-digest は、モデルの応答をカテゴリー、見出し、箇条書き、出典番号という構造で受け取り、範囲外の出典番号や、利用可能な本文を持たないトピックを除外する[11]。この検査によって、出典リンクを作れない話題や、後続処理が扱えない応答を正常な成果物として保存することは減らせる。
一方、構造が利用可能であることと、内容が妥当であることは一致しない。異なる研究を同じ話題へまとめる、論文の限定条件を箇条書きから落とす、比較実験の結果を一般的な性能差として表現する、専門用語を別の概念へ訳すといった誤りは、JSON の型や出典番号の範囲を調べても検出できない。
内容品質には、少なくとも複数の評価対象がある。個々の箇条書きが原典に書かれているかという事実一致だけでなく、統合した項目が同じ話題であるか、原文の限定を保っているか、重要な候補を落としていないか、見出しが内容を過度に一般化していないかを別々に確認する必要がある。
| 評価対象 | 確認する内容 | 想定される誤り | 必要となる評価方法 |
|---|---|---|---|
| 出典との一致 | 見出しと箇条書きが、関連付けられた原典に書かれている内容を表しているかを確認する。 | 原典にない因果関係、数値、評価、将来予測が追加される。 | 原典と生成文を文単位で照合し、支持、不支持、判断不能に分類する。 |
| 話題統合 | 一つにまとめられた論文と記事が、同じ研究、製品、出来事を扱っているかを確認する。 | 名称や分野が似ているだけの別研究を一つへ統合する。 | 人間が統合可否を判定し、モデル結果との一致率を測定する。 |
| 限定条件 | 対象データ、実験条件、適用範囲、比較対象が要約後にも残っているかを確認する。 | 特定条件での結果が、一般的な性能向上として記述される。 | 原典中の条件文を抽出し、箇条書きへの反映状況を確認する。 |
| 重要度 | 候補集合の中から日次レポートへ残す話題の選択が目的に合っているかを確認する。 | 広報量の多い発表や有名企業の記事が過度に優先される。 | 人間による順位と比較し、不一致の理由を候補別に記録する。 |
| 日本語表現 | 専門用語、主語、否定、比較関係が原文と対応しているかを確認する。 | 専門語の誤訳、主張主体の入れ替わり、否定表現の欠落が起きる。 | 技術用語と関係表現を対象に、翻訳上の誤りを分類する。 |
NIST の生成 AI 向けリスク管理資料は、生成 AI を利用するシステムについて、設計、開発、導入、運用、評価の各段階で信頼性に関するリスクを管理する必要を示している[24]。この資料が ai-digest の具体的な合格基準を定めているわけではないが、自然な文章が返ったことだけを品質確認とせず、用途に応じた評価を継続する必要があるという位置づけに使える。
現在のシステム指示では、推測や誇張を避け、原文に記載された事実だけを書くよう求めている[11]。この指示は出力方針をモデルへ伝えるが、実際の応答が毎回その条件を満たしたことを証明する記録にはならない。指示を強く書くことと、指示違反を検出することは異なる処理である。
評価可能な状態へ進めるには、同じ入力に対する出力を一定期間保存し、人間が判定できる基準を用意する必要がある。話題統合の誤り、事実の追加、限定条件の欠落、翻訳の誤り、重要度の不一致を別の種類として記録すれば、モデルやプロンプトを変更したときに、どの誤りが減り、どの誤りが増えたかを比較できる。
モデル変更の評価では、完成した 6 件だけを比較しても十分ではない。候補集合と入力順序が同じでなければ、出力差がモデルによるものか、収集結果によるものかを区別できない。前章で整理したように、現在はモデルへ渡した全候補と API の生応答を保存していないため、過去の日付へ遡って厳密な比較実験を行うことは難しい。
日次レポートを読むための軽量なソフトウェアと、モデル品質を継続評価する基盤では、必要な記録が異なる。前者には、最終トピックと出典を保存すればよい。後者には、入力、出力、モデル設定、人間評価、誤り分類、処理時間、利用量を残す必要がある。内容品質の検証を強化することは、要約機能を一つ追加するのではなく、ai-digest に評価用の別工程を加えることになる。
10.3 画像を取得できることと再掲載できることは異なる
ai-digest は、ar5iv の HTML やニュースページのメタデータから画像 URL を探し、取得できた画像を日次レポートとサマリー画像へ使用する[17]。技術的には、画像 URL が存在し、サーバーが応答し、対応形式であればファイルとして保存できる。しかし、取得できることは、その画像を別の Web ページへ複製して公開できることを意味しない。
arXiv では、投稿者が論文へ適用するライセンスを選択する。Creative Commons ライセンスのように条件付きで再利用を認めるものもあれば、arXiv 上での配布を認める非独占ライセンスのように、第三者の再利用権を一律には与えないものもある[25]。同じ arXiv 上の論文であっても、図の再掲載条件は論文ごとに異なり得る。
arXiv の公式案内も、論文中の図を再利用できるかは適用されたライセンスによって決まり、必要な許諾が含まれない場合は投稿者または著作権者へ確認する必要があるとしている[26]。ar5iv が論文を HTML として表示していることは、元の図へ新しい再利用権を付与するものではない。
ニュースサイトの Open Graph 画像にも同じ問題がある。og:image はページを代表する画像の場所を示すメタデータであり[18]、第三者による複製や再配布の許諾を示す項目ではない。企業ロゴ、製品画像、報道写真、外部から提供された素材では、それぞれ権利者と利用条件が異なる可能性がある。
| 画像の扱い | 表示上の利点 | 権利と運用上の課題 | ai-digest で必要となる変更 |
|---|---|---|---|
| 外部画像を複製して保存 | 論文図や公式画像を HTML とサマリー画像の双方で安定して表示できる。 | 画像ごとに複製と再掲載が認められているかを確認する必要がある。 | ライセンス情報、権利者、取得元、確認結果を画像とともに保存する。 |
| 外部 URL を直接参照 | 自分の保存領域へ画像ファイルを複製せずに表示できる。 | 直リンクが許可されるとは限らず、配信元の変更や削除で表示が崩れる。 | HTML とサマリー画像で異なる表示方式を用意する必要がある。 |
| 利用可能なライセンスだけを採用 | 確認済みの画像に限定して公開できる。 | ライセンス情報の取得方法が媒体ごとに異なり、自動判定できない場合がある。 | 不明な画像を除外し、確認済み条件だけを許可する規則を実装する。 |
| ローカルカードへ統一 | 見出しとカテゴリーだけを使い、外部画像へ依存せず表示を一定に保てる。 | 論文図や製品画像が持つ視覚情報を利用できない。 | 画像取得を既定で無効にし、すべての話題をカードとして生成する。 |
現在は、画像の取得元をホスト名として表示するが、ホスト名の表示だけで再利用条件を満たすとは限らない。必要な表示には、著者名、作品名、ライセンス名、ライセンスへのリンク、改変の有無が含まれる場合がある。出典を示す処理と、利用条件を満たす表示は別に設計しなければならない。
権利確認を自動化する場合も、単にライセンス名を文字列で探すだけでは不十分である。論文全体のライセンスと、論文内で第三者から引用された図の権利が一致しない場合がある。ニュース記事の画像が配信元自身の制作物であるとは限らない。機械的な判定で不明な画像を許可すると、確認できないものを利用可能と誤認する。
公開範囲が個人の確認用から一般公開へ広がるほど、画像処理の位置づけも変わる。個人用の日次レポートでは表示品質の向上として扱えた機能が、公開サービスでは権利情報の収集、判定、保存、表示を伴う処理になる。確実性を優先するなら、不明な外部画像は使用せず、ローカル生成カードへ切り替える方式が最も単純である。
画像処理に残る課題は、取得成功率だけではない。どの画像を使えるかを判定し、その判断根拠を後から確認できる状態にする必要がある。外部画像を継続利用するなら、画像解決処理は表示補助機能から、権利情報を扱う保存工程へ拡張される。
11. ai-digest というソフトウェアを作るということ
ai-digest を作ったことで、AI 関連の論文とニュースを日本語の短いレポートとして毎日確認できるようになった。利用時に目に入るのは、最大 6 件の見出し、箇条書き、画像、出典である。しかし、その表示を作るために実装した処理の大半は、日本語の文章を生成する部分ではなかった。
レポートの生成前には、情報源と対象時間を定め、arXiv とニュースフィードを共通形式へ変換し、URL と題名から明白な重複を除き、候補を最大 60 件へ制限する。Claude はその範囲で意味の近い項目をまとめ、日本語のカテゴリー、見出し、箇条書き、出典番号を返す。応答後は出典番号を元の入力へ照合し、画像を用意して、日付別の JSON、HTML、PNG として保存する。API キーが追加するのは、この処理経路のうち、記事単位の入力を話題単位へ組み替える編集工程である。
plain モードが示すように、通常のプログラムだけでも収集、重複排除、画像処理、保存、閲覧までは実行できる[9]。一方、言語モデルだけでは、情報源、対象時間、URL の整合性、永続化、公開、障害時の代替を保証できない。ai-digest は両者を代替関係として扱わず、識別情報と反復処理を通常のコードへ置き、文章の意味を比較しなければ決められない処理をモデルへ置いた。
モデルへ任せなかった判断も、出力を大きく形作っている。Claude が話題を選ぶ前に、対象となる情報源、過去 24 時間という時間幅、論文を先に置く順序、最大 60 件の入力枠がある。Claude が話題を返した後には、最大 6 件の表示枠、最大 3 件の出典、最大 4 件の箇条書きがある。日次レポートは、モデルの判断だけでなく、これらの制約を通過した結果である。
出典 URL をモデルへ生成させず、入力番号から復元する方式も、この役割分担を表している。どの入力が話題の根拠になるかは意味判断であるためモデルへ任せる。URL の文字列と入力範囲の整合性は確定済みデータから検証できるため、通常のプログラムへ残す。モデルの柔軟性を使いながら、識別情報まで確率的な出力にしない構成である。
作ったことで明らかになった課題も同じ境界上にある。情報源を増やすには候補配分と重複規則を見直し、内容品質を評価するにはモデル入力と生応答を保存し、外部画像を一般公開するにはライセンスの確認と記録を加える必要がある。観測範囲、評価記録、権利条件、障害境界は、モデルへ長い指示を書くだけでは作れず、アプリケーション側のデータ構造と運用工程として実装しなければならない。
生成 AI をソフトウェアへ組み込むとは、モデルへ作業を委任するだけではない。モデルが読む候補をどこから作り、どの判断だけを任せ、返された値のどこを検査し、何を保存し、外部依存が失敗したときに何を残すかを決めることである。ai-digest は、記事単位の入力を一日の話題へ組み替え、原典へ戻れる形で保存し、生成系の障害から閲覧系を分離するために、通常のプログラムと生成 AI の境界を定めたソフトウェアである。ai-digest というソフトウェアを作ることは、AI に日次レポートを書かせることではなく、AI の判断を日次レポートとして成立させる工程を作ることであった。
参考文献
- id774, ai-digest README（2026-07-29 閲覧）. https://github.com/id774/ai-digest/blob/master/README.md
- arXiv, arXiv API Access（2026-07-29 閲覧）. https://info.arxiv.org/help/api/index.html
- Mark Nottingham and Robert Sayre, The Atom Syndication Format, RFC 4287（2005-12）. https://www.rfc-editor.org/rfc/rfc4287
- RSS Advisory Board, RSS 2.0 Specification, version 2.0.11（2009-03-30）. https://www.rssboard.org/rss-specification
- id774, ai_digest/collectors/arxiv.py（2026-07-29 閲覧）. https://github.com/id774/ai-digest/blob/master/ai_digest/collectors/arxiv.py
- id774, ai_digest/collectors/news_rss.py（2026-07-29 閲覧）. https://github.com/id774/ai-digest/blob/master/ai_digest/collectors/news_rss.py
- id774, ai_digest/dedup.py（2026-07-29 閲覧）. https://github.com/id774/ai-digest/blob/master/ai_digest/dedup.py
- id774, cli.py（2026-07-29 閲覧）. https://github.com/id774/ai-digest/blob/master/cli.py
- id774, ai_digest/analyzer/plain.py（2026-07-29 閲覧）. https://github.com/id774/ai-digest/blob/master/ai_digest/analyzer/plain.py
- id774, Demo mode（2026-07-29 閲覧）. https://github.com/id774/ai-digest/blob/master/doc/DEMO.md
- id774, ai_digest/analyzer/summarizer.py（2026-07-29 閲覧）. https://github.com/id774/ai-digest/blob/master/ai_digest/analyzer/summarizer.py
- Anthropic, Messages（2026-07-29 閲覧）. https://platform.claude.com/docs/en/api/messages
- さくらインターネット, 利用手順（2026-05-20 更新）. https://manual.sakura.ad.jp/cloud/ai-engine/02-howto.html
- Anthropic, Define tools（2026-07-29 閲覧）. https://platform.claude.com/docs/en/agents-and-tools/tool-use/define-tools
- Austin Wright, Henry Andrews and Ben Hutton, JSON Schema Validation: A Vocabulary for Structural Validation of JSON, Internet-Draft（2022-06-16）. https://json-schema.org/draft/2020-12/json-schema-validation
- id774, app.py（2026-07-29 閲覧）. https://github.com/id774/ai-digest/blob/master/app.py
- id774, ai_digest/images/resolver.py（2026-07-29 閲覧）. https://github.com/id774/ai-digest/blob/master/ai_digest/images/resolver.py
- The Open Graph protocol（2026-07-29 閲覧）. https://ogp.me/
- Deyan Ginev et al., ar5iv: A web service offering HTML5 articles from arXiv.org as converted with latexml（2026-07-29 閲覧）. https://github.com/dginev/ar5iv
- id774, ai_digest/storage.py（2026-07-29 閲覧）. https://github.com/id774/ai-digest/blob/master/ai_digest/storage.py
- id774, 生成 AI の競争軸は、モデルから業務実装へ移る（2026-06-25）. https://blog.id774.net/entry/2026/06/25/4922/
- id774, AI に任せる前に、人間が残すべき判断（2026-06-21）. https://blog.id774.net/entry/2026/06/21/4912/
- id774, MacBook Pro にローカル RAG を構築する（2026-07-18）. https://blog.id774.net/entry/2026/07/18/5104/
- Chloe Autio, Reva Schwartz, Jesse Dunietz, Shomik Jain, Martin Stanley, Elham Tabassi, Patrick Hall and Kamie Roberts, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile（2024-07-26）. https://doi.org/10.6028/NIST.AI.600-1
- arXiv, arXiv License Information（2026-07-29 閲覧）. https://info.arxiv.org/help/license/index.html
- arXiv, Permissions and Reuse（2026-07-29 閲覧）. https://info.arxiv.org/help/license/reuse.html