購入代行 Bot（korekae-bot）

2課題

代わりに買い物を引き受ける取り決めがあり、依頼の受け取り、手数料の計算、支払いの状況の管理を、一対一の会話の中で手作業で回していたため、誰の分がどこまで進んでいるのかがすぐ分からなくなる。これを会話の場に置いた自動応答の上で完結させたい、というのが出発点である。ただし対象とする領域には外部へ提供された公式の接続口がなく、状態を取る手立てを別に用意する必要があった。

3要件・制約

要件は三つに整理した。第一に、預かる資格情報を平文で置かないこと。保管も、運用中の入れ替えも、あらかじめ想定に入れること。第二に、依頼の単位を会話の側の構造に対応させ、後から誰の分か辿れるようにすること。第三に、状態の取得は必要な最小限の頻度に抑えること。

4設計

構成は、命令の受け口、業務の処理、保管の入出力、そして移行の記述という層に分けた。公式の接続口がない領域を扱うため、預かった資格情報は共通鍵の認証付き暗号で暗号化したうえで、単一ファイルの保管先へ収める。依頼は会話の枝の単位で管理し、状態の遷移をそこへ紐づけた。

6実装

保管の鍵は版を持たせ、更新の処理の中で古い版のものを自動的に暗号化し直す。保管先の構造の変更は積み重ねの記述として管理し、起動時に内容の要約値を照合する。ただし要約値を持たない古い行は照合の対象から外れる。配備は、版管理の自動処理から転送し、常駐の管理下で入れ替える経路を自作した。健全性の確認に失敗した場合は、直前の世代の成果物と依存へ自動的に戻る。移行と試験の規模は本節末の計測に示す。

DB マイグレーション — 26 件（起動時チェックサム検証つき。checksum NULL の既存行はスキップ）¹

テスト — 60 ファイル / 661 ケース²

7性能対策

保管の有効期限は固定の時間ではなく、次の更新時刻までの残りから毎回計算する形にした。下限だけを設けてある。対象の性質ごとに期限は分けており、会話の履歴と応答の文脈は短く、変化の少ない目録は長く保つ。

8結果

本番で、権限の宣言が足りないために起動と終了を繰り返す事態が起きた。常駐の記録を解析して、原因が管理画面側の設定の未有効化にあることまで特定し、再起動の間隔と一定時間内の上限を引き上げる設定でその場の暴走を止めた上で、記述側の恒久的な修正を変更要求として起こした。発生の回数は本節末の計測に示す。調査の記録は別の文書として残してある。ただし恒久的な修正はまだ取り込まれていない。

本番障害対応 — 458 回のクラッシュループを journalctl から根本原因（Portal の Intent 未有効化）まで特定し、systemd hardening で即時に暴走を停止³

9検証で判明した注意点

恒久的な修正の変更要求は未取り込みで、主枝の先頭は原因を入れた記述そのものである。したがって本番で運用中とは断定できない。

安全性の改修は最初の段だけが主枝に入り、残りは変更要求のまま開いている。

保管されている画面の画像は実機の記録ではなく、自作の見本を自動操作で書き出した合成である。実際の画面として扱えない。

以前の記録にある試験の件数は、作業用の複製を重ねて数えた誤りである。実装の節に示した計測の側が正しい。

容器化と外部の実行基盤の設定が残っているが、これは初期の段階の遺物で、現在の配備の経路では使っていない。

文書に現れる再暗号化の管理命令は実在しない。文書と実装の乖離であり、実装の側が正しい。

保管の有効期限についても、文書の側は古い記述のままである。ここでも実装の側が正しい。

10AI 支援の関与

実装は言語モデルのエージェントとの協働で進めた一方、本番の暴走を止めた障害対応は、記録の解析から原因の特定と恒久的な修正の起草まで人の側で行っており、AI の関与は実装の作業に限られる。