今日やったこと#
AI記事生成の証拠と引き継ぎ契約を再設計#
- 調査、選定、執筆を独立した工程として扱い、後段は保存された前段の成果物だけを読む契約にした。同じ会話に残った暗黙の記憶へ依存しない構成を目指した。
- 調査結果の形式を厳密化し、実行日時、検索状況、情報源の確認結果、警告を記録するようにした。対象日が違う入力、古い入力、不完全な入力は選定工程で止める方針にした。
- 選定結果には、採用した主張と根拠の対応、検証状態、情報提供者による自己申告かどうか、記事内の順序と深さを残すようにした。
- 過去記事との重複を抑えるため、公開履歴とイベント単位の識別情報を保持する設計を追加した。執筆後には、採用項目、主張、数値情報がどれだけ保持されたかを監査できるようにした。
- 本番公開を行わずに各工程の境界と成果物を検査するドライラン手順、受け入れ基準、評価項目、例示データを整備した。
公開前検証と配信ゲートを実装#
- AIが生成した記事だけを対象に、必須メタデータ、項目数、情報源、公開日、追跡用パラメータ、内部工程名、匿名の編集文体を決定論的に検査する仕組みを追加した。
- 情報源の数と記事項目の数、採用項目の識別情報を相互に照合し、欠落や重複があれば公開前に失敗させるようにした。
- 公開サイトのビルド前に記事検証を実行し、検証を通過した最新版だけを配信するようにした。新しい更新が来た場合は古い配信処理を打ち切り、競合した版が公開されにくい構成へ変更した。
- 検証器に対して、正常な記事、項目数の不一致、内部語の混入、追跡用パラメータ、日付欠落、追跡情報の欠落を扱うテストを追加した。
判断と学び#
生成記事の品質を文章の自然さだけで評価すると、調査時点では存在した根拠、数値の分母、留保、帰属が執筆中に落ちても検出しにくい。各工程の成果物を厳密な契約でつなぎ、主張単位の根拠と情報保持率を残す方が、品質低下の場所を特定しやすい。
ドライランは、一つの会話で全工程を模倣するだけでは本番相当の検証にならない。工程ごとに入力を固定し、後段が保存済み成果物だけを読むことで、暗黙の文脈に助けられた成功を区別できる。
配信の安全性には記事内容の検査だけでなく、どの版を公開するかの制御も必要だった。検証済みの最新版だけを配信対象にし、古い実行を中断することで、短時間に更新が続いた場合の競合を減らせる。
検証#
- 記事検証器について、正常系と主要な欠落・混入パターンを扱うテストケースを追加した。
- 公開サイト側では、最終変更に対する記事検証、ビルド、配信が成功した。途中の失敗と中断も確認し、修正後の最新版で成功している。
- 工程別の成果物を使うドライランを行い、調査から記事プレビューと評価までの受け渡しを作成した。これらの機械的な成果物は開発タスクとしては数えていない。
- ドライラン用の自動検証は、検証スクリプトのモジュール読み込みに失敗したため完了していない。後段の記事検証まで到達しておらず、横断検証の成功は未確認である。
次にやること#
- ドライラン検証器の実行方法または読み込み経路を修正し、調査成果物から記事プレビューまでの横断検証を成功させる。
- 本番の定期実行で、入力不足や検証失敗時に公開を止め、警告と監査情報を失わず残せることを確認する。
- 情報保持率と重複抑制の記録を継続し、基準値が実際の記事品質に対して厳しすぎないか、緩すぎないかを調整する。