日次の情報収集が動き始めると、別の製品や技術も調べたくなります。しかし、既存ジョブを複製して検索語だけを書き換えると、片方がもう片方の予算を使ったり、未通知の記事が通知済みと判定されたりします。増やす対象は検索条件だけではありません。
2026年10月4日の取り組みでは、Xを使う既存の調査にClaude Code関連の調査を追加しました。本記事は、この拡張を題材に「独立した調査単位」をどう設計するかを解説します。URL正規化や公開日抽出ではなく、予算と実行履歴の境界が主題です。
最近の取り組みで確認できたこと
10月4日の非公開記録には、別予算枠の調査を追加し、手動実行後に日次ジョブを有効化したことが残っています。執筆時には記録だけで結論を出さず、設定読込、収集処理、配送履歴同期の差分と、追加されたテストを確認しました。
実装では調査単位を「トラック」と呼び、設定ファイル、SQLite台帳、取得結果の保存先、通知の識別子を分けています。既存トラックの既定動作を残したまま、許可された名前で追加側を選ぶ方式です。任意の設定ファイルを外部から渡す入口にはしていません。
10月5日に手元の作業ツリーで全体テストを再実行し、70件が成功しました。追加変更は未コミットの状態です。この数字は公開済みリリースの保証ではなく、その作業ツリーに対する確認結果です。また、同日の保存済み定期実行ログに検索成功と10投稿の取得を確認しました。今回の記事制作では有料検索を再実行しておらず、通知先での実着信確認も行っていません。
仕組みを分解する
1. 調査単位を入口で固定する
入口で選べるトラックを列挙し、それぞれを既知の設定へ対応付けます。自由入力をそのままファイルパスへ変換しないことが重要です。手元の実装はトラック名を許可集合で検査し、台帳名や保存先の部分名にも形式制約を設けています。
検索語や取得上限を毎回モデルに決めさせるのではなく、承認した設定を読む境界にします。ただし、名前の形式検査だけでは二つの設定が同じ保存先を指す事故を防げません。設定同士を比較するテストも必要です。
2. 予算台帳と取得結果を分ける
日付を主キーにした台帳を共有すると、既存調査の「本日実行済み」が新調査にも効いてしまいます。今回の方式ではトラックごとに別のSQLiteファイルを使い、同じ日でも独立して実行できるようにしました。応答と候補記事の保存先も分け、ファイル名が日付だけでも上書きしない構造にしています。
本番とドライランも分離対象です。本番台帳だけを分けても、試験側のファイルが共有なら検証結果が混ざります。別ファイル方式は小規模運用で境界が見やすい一方、全体集計には複数台帳の読み取りが必要になります。
3. 通知の識別子まで分ける
検索に成功したかと、結果を通知済みかは別の状態です。台帳が別でも配送履歴の照合キーが衝突すると、別テーマの通知を自分の成功と誤認できます。実装は通知識別子の接頭辞とジョブ名を分け、配送履歴の同期も対象の接頭辞で絞ります。
共有する通知先と、共有してはいけない状態を区別する設計です。同じチャットへ届けること自体は問題ではありませんが、どの調査の結果なのかを追跡できる必要があります。
4. 分離後の再実行を検証する
追加テストでは、二つのトラックがそれぞれ一度ずつモック検索でき、追加側を同日に再実行しても検索回数が増えないことを確認しています。これは固定入力に対する試験です。並列プロセス、ネットワーク断、すべての配送失敗まで一括して保証するものではありません。
小さく再現する手順
実APIを呼ぶ前に、架空の調査A・Bを用意します。次は構成を説明する例であり、実際の運用名や設定を転載したものではありません。
“`text
調査A: 台帳 a.sqlite3 / 保存先 a/ / 通知接頭辞 aa
調査B: 台帳 b.sqlite3 / 保存先 b/ / 通知接頭辞 bb
同じ対象日でAを実行 → モック検索1回
同じ対象日でBを実行 → モック検索1回
同じ対象日でBを再実行 → Bの検索回数は増えない
“`
まず、台帳・保存先・接頭辞・ジョブ名が異なることを比較します。次にモック応答を使って上の順序を実行し、各保存先に期待した候補だけがあるか確認します。最後に不正なトラック名や親ディレクトリを指す値を渡し、検索前に拒否されることを確かめます。
費用上限は各調査だけでなく合計でも設計します。たとえば架空の予算単位でAを3、Bを2とした場合、全体上限が4なら両方を最大まで動かすことはできません。個別上限の設定と、合計上限の承認は別の確認です。ここでは実際の私的な予算額は示していません。
確認指標
第一は**状態の非共有**です。異なる保存先という文字列比較に加え、実行後に他トラックの台帳や候補が変わっていないかを検査します。今回のテストは設定の分離と独立実行を確認していますが、あらゆる障害下の非干渉を証明したわけではありません。
第二は**同日再実行時の検索回数**です。確認した固定ケースでは追加側のモック検索は1回のままでした。実請求額を測った試験ではないため、「本番でも絶対に追加課金されない」とは表現しません。
第三は**共有制約の残量**です。X公式資料は、一定時間内のリクエスト数を制御するレート制限と、取得等に対する利用課金を別概念として説明しています。アプリ内で予算を二つに分けても、提供元のアプリ単位・利用者単位の制限やクレジット残高まで分かれるとは限りません。時間窓の異なる数値をそのまま使用率にしないことも重要です。
失敗しやすい点と安全策
- **検索語だけを変える。** 台帳、候補、応答、配送履歴の識別まで一覧化し、共有の意図を確認します。
- **別予算だから全体も安全と考える。** 個別上限の合計を全体予算と照合します。共通の認証やサービス側の上限は残ります。
- **片方だけ価格設定を更新する。** 価格承認の有効期限を持つ構成では、すべてのトラックを同時に点検します。期限はローカルな運用判断であり、提供元の価格保証期間ではありません。
- **通知済みの範囲を曖昧にする。** 今回は記事履歴もトラック内で管理されるため、同じ記事が別テーマで候補になる可能性があります。横断重複排除が必要なら別の仕様として設計します。
- **テスト成功を配送成功に読み替える。** 検索、保存、通知生成、実着信を別々に確認し、未確認箇所を残します。
再現チェックリスト
- [ ] トラック名と設定の対応を許可集合で固定した
- [ ] 台帳・応答・候補の保存先を分けた
- [ ] ドライランも本番および他トラックから分けた
- [ ] 通知識別子と配送履歴の照合範囲を分けた
- [ ] 二つの独立実行と同日再実行をモックで試した
- [ ] 個別予算の合計と共有レート制限を確認した
- [ ] 未コミット変更と本番実績を区別して記録した
次に改善するなら
次の候補は、全設定を読み込んで台帳名・保存先・接頭辞の衝突を一括検査する仕組みです。全体予算を原子的に予約する共通台帳や、テーマ横断の通知重複排除も考えられますが、今回の追加で完了した機能ではありません。小規模な分離を出発点に、共有すべき制約だけを後から明示的に集約する方針が扱いやすいと考えています。
参考情報
- 執筆根拠：2026年10月4日の非公開日次記録、10月5日に確認した実装差分・追加テスト・保存済み定期実行ログ。同日に未コミット変更を含む全70テストを再実行。私的な原資料は公開していません。
- [X公式：Rate Limits](https://docs.x.com/x-api/fundamentals/rate-limits) — 制限の単位と利用課金との区別。2026年10月5日確認。
- [X公式：Pricing](https://docs.x.com/x-api/getting-started/pricing) — クレジットによる従量課金と最新価格の確認先。2026年10月5日確認。個別の単価や契約条件は再現時に再確認してください。