📝
外部APIの値をDBにフラグとして持ち込まないこと
それでもAIが答えてくれないこと #4
導入
自分は「未来のエンジニアを困らせる負債を増やさない」ことを信条にしている。
今回のケースは、外部SaaS APIと自前DBの二重管理が招いた不整合にどう向き合うか、という判断だった。
事例
あるテーブルに is_xxxx というカラムが追加された。
- テーブル自体は3年前から存在
- is_xxxx は半年前に ALTER TABLE で追加
- バッチ処理で外部SaaS APIを叩き、レスポンスの値（true/false）を格納
一見便利そうに見えるが、実際にはこうだった：
- 外部APIはテーブルの全レコードを網羅していない
- is_xxxxの仕組み変更前の古いデータは未対応
- そのため、半年前以前のデータはすべて false 固定
つまり、このカラムは「古いデータ＝false」という誤った状態を内包していた。
なぜ問題か？
外部APIのレスポンスと is_xxxx の値は整合していない。
それにもかかわらず、エンジニアはDBのカラムを見て実装してしまう。
- 不整合に気づかずバグを埋め込む
- 原因究明に余計な時間を費やす
- バッチ処理やカラムの存在意義を説明するコストが発生する
これはまさに 二重管理の弊害 であり、未来のエンジニアに負担を押しつける構造だった。
自分の判断
is_xxxx カラムを廃止することだった。
source of truth を間違えたくなかったからだ。
- フラグをDBに持ち込まず、毎回外部APIを叩く
- レスポンスそのものを唯一のtruthとする
- バッチ処理は廃止する
幸い、この外部SaaS APIはレート制限が緩く、料金はバッチ処理を稼働するよりもかなり安く、十分なレスポンス速度があった。
だからこそ「毎回APIを叩く」判断に現実味があった。
未来
is_xxxx カラムを削除すれば、バッチ処理は不要になる。
説明コストもなくなり、不整合に悩まされることもない。
エンジニアはAPIのレスポンスだけに注目すればよくなる。
つまり、責任は外部API側に委ね、私たちはその結果に集中できる状態になる。
学び
- 外部APIが十分に使えるなら、DBにコピーを持ち込むべきではない
- 二重管理は「安心感」ではなく「負債」を生む
- 判断の本質は「廃止する」にある
まとめ
技術的には、外部APIの値をDBに同期することは簡単だ。
しかし、その実装が未来のエンジニアを混乱させ、不整合や説明コストを増やすなら、やらない方がいい。
外部APIをsource of truthにし、is_xxxx カラムを廃止する判断こそ、AIが答えられない部分であり、記事に残す意味がある。
Discussion