Agentic Coding で意識していること・新開発サイクル

最近感じているコツ

AIに思った通りの出力をさせるためのコツみたいなのが少しわかってきたのでまとめてみる。まだまだ遅れているなと思いつつひとまず現状についてメモ書きを残しておきたい気持ちになった。

以下記載のあたらしい開発サイクルを自分の中の土台とし、これに肉付けしていくことで改善サイクルを回していけそうな気がしている。

なにも目新しいことは書いていない点ご了承ください。

Agentic Coding の時に意識すること

  1. 現状分析をさせてレポートとして整理させる。
  2. コードを生成するなら公式ドキュメントなど質の高い情報をできるだけ渡す。
  3. 生成したいものに対してどういった指示をすればよいかを聞いて、不足情報があればさらにコンテキストを渡す。
  4. 方針をできるだけ固めた上で生成を指示する。
  5. 生成結果の正しさを自分自身にもう一度レビューさせる

ざっくりこんなステップでやるのが良いのかなと思う。これまでは一度の指示に参照リンクや指示をまとめて会話しながら実装をさせるスタイルをとりがちだったが、これだと会話が長くなるとコンテキストが失われていくので後半になるほど質が落ちたり、架空の論理の上で回答をし始めたりすることが多々あった。

ポイント２つ

おおきくこの以下２つを意識して指示ができると結果がかなり変わるなとここ最近感じている。

  1. 最終生成物の前に、現状分析レポートなどの中間生成物を出力すること。ここをいかに揃えることができるかが大事な気がする。

    「まずは参照するデータを渡すことから始めましょう」みたいなのは初歩中の初歩なので「リポジトリのここのコードを参考にしてください」みたいなことはしていたのだが、現状分析レポートのような中間生成物をわざわざ生成してから最終的な指示をするといったことはやっていなかった。

    これをやるようになってから質の高い出力になった気がしており、職場の先輩が出してくるAI出力の質に少し追いついた気がしている。（いままで自分の出力と他の人の出力の質の違いを感じていた）

  2. ベストプラクティスや料金表の記載があるドキュメントを持ってきて渡す。

    感覚的な話だが、以下図でいうところの「意識外（理解していないこと）」にあたる情報を収集する、させることができるかが重要と感じている。

    意識外のもの（＝まだ理解していない詳しい仕様）としては、ベストプラクティス・料金表・アンチパターン・AIに出させた確認すべき観点などが該当する。

    こういったものを丁寧に探すか探させてから、レビューさせると人間の脳内メモリで処理できる限界を超えたレビューが返ってきて「人間ができないレベルの網羅性をAIの能力をフル活用して出力できているな」と感じられるアウトプットになる。

まだ途中だが、新しい開発サイクルが少し見えてきた

AI使って開発する文脈だとツールは色々あるとは思う。ただ個人的には各フェーズで最適なミニマムなツールを組み合わせて回せる方が柔軟性が高くていいなと感じている。

例えばtaktとかはかなりよい開発者体験だなと思ったのだが、よく作り込まれているだけにかなりトークンを食うし、そこまで作り込まれたものでなくとも十分なアウトプットが得られるのではないかと思っている。

そのため現状は以下のような流れでひとまず進めてみている。

  1. grill-meで要件定義
    • ここがかなり重要。ドメインごとにさらに細かくgrill-meで深掘りするなどすればよりよい整理ができるので整理が甘いところに対して何度も実行するべき。
  2. setup
    • CLAUDE.mdやAGENT.mdなどAgentic Codingを快適かつ質を高くするために様々な設定をしておく必要がある。
    • SKILLやMCPなどもこのタイミングで入れておくのがよいし、MCPなんかはPlaywrightをこのタイミングで入れるなどしておけば以降のE2Eテストが捗るので、テストやインフラ構築を行うために便利なSKILLやMCPを入れておくのが良い。
    • 3.ではテストの洗い出しなどを行なっていくので、テストの実行環境やCICDもこのタイミングで先に整備しておくと以降のテストをAIによる自己改善ループを回しやすくなる。
  3. テスト観点の洗い出し
    • ここもAgentic Coding ネイティブなサイクルを行うにあたって重要になってくる。
    • 考え方としては「ここで定義したテスト項目が全部通っていれば動作確認完了とみなして、リリースして良い」とできるくらいしっかりと洗い出す。
    • ここのテスト観点は人間による観点の抜け漏れがないかのレビューをしっかり行うこと。
    • 以下ではpm-ai-shipping/device-tests skillに頼って、grill-meで定義した要件を参考に必要なテストを洗い出してもらう想定の図になっている。

残課題

taktなど使っていれば仕様駆動のサイクルが自動で回るのだが、なんかもっとミニマムにやりたいなという気持ちがある。どういったものならしっくりくるかが自分の中で言語化できていないために自作もいまいちできていないが、大まかには仕様駆動のようにADR履歴を残していってくれる仕組みだけ整備したいと考えている。

改めてGmail送信のウォームアップについて

hoshimachi-suisei-fc.jp

また神奈川の入試メール問題のようなGmailによる送信制限問題が身近なところで起きていた。

正直あまり普段からメール配信を触るわけではないので、実際どのようにして対策して送信戦略を立てるべきか？はあまり詳しくない気がしている。（SPF・DKIM対応とかしたことはあるけども）

そのため改めて整理しておく。

何が問題だったか

今回メールの送信制限がかかってしまったのは「最初から大量の会員登録が見込まれる」✖️「会員登録の仕組みがメール送信の仕組みに依存している」というこの掛け算のケースであった。 であるがゆえにおそらく考慮漏れで、こういった事態が起きてしまったのではと思う。

そのためもし、新規会員登録がGoogleのSNS認証などで完結するのであればこういったことは起こらなかったはず。これはシステム設計者として他山の石としたい。

つまり対策としては以下２つがあった。

  1. そもそもメール依存の認証方式にしない
  2. 新規ドメインを使わない
  3. しっかりとウォームアップ戦略をたてる

このうち1,2の方針であればなにもそれ以上の対策は不要な可能性が高い。ただどうしても新しいドメインが使いたい場合は3.のウォームアップをちゃんとやる方法を考えないといけない。

どうやってウォームアップすべきか

そもそも大まかに何をしないといけないか？だが、新規送信用ドメインの信頼度（レピュテーション）を上げていくための活動をしなければならない。おもに以下対応が必要になります。

  1. SPF / DKIM / DMARC の設定
  2. 送信量を段階的に増やす
  3. 「エンゲージメントの高いユーザー」から送る
  4. 指標を監視する

こういった対応を丁寧にする必要がある。ただこういったことを全部自分でやるのは大変すぎるのでこういった設定やレピュテーション監視も一元的にできるSendGridなどのプラットフォームを使うべきである。

今回のようなケースに必要な別途対応

ただ今回は、会員登録時のメール送信という観点で上記のようなサーバー管理者側で送信数を制御することができない状況だった。

そのため例えばだが以下のような対応を行う必要があったのだろうと思われる。確かにサイトによってはこういった対応をしているのも見たことがあったが、もしかするとメール運用者が裏で「こういったやり方にした方がいい」と言ってくれているのかもなと思った。

リリース前 2〜4週間
    └── β期間 or 事前登録フォームを設けて
        少量のウェルカムメールを流してウォームアップ開始

リリース当日
    └── 一気に大量送信せず、登録受付を時間帯でレート制限
        （例：1時間あたり500登録まで受付）

技術者としてこういったことが起こりそうな時にきちんと口を挟めるようにここに整理しておいた。

「バーコードだけでポイント管理できるってどういう仕組みなの？」について

技術解説

記事を書こうとしたきっかけ

先日友達と買い物にいった際、会員カードを発行しました。

その際、「バーコード一つでポイントシステム導入できるのってどんな仕組みなんだろうね」みたいなことを言っていて少し引っ掛かりました。

引っ掛かった理由は、自分自身前職でスーパーのアプリ上にバーコードを表示させてポイントシステムを導入するといった部分に端っこの方だけとはいえ関わっていたのに、この疑問に回答できなかったのが悔しくて引っ掛かりました。

そのためどういう仕組みでどういう企業が導入しているか？と少し歴史的な経緯も交えつつここで整理できればと思います。

ポイントサービス事業者

近年はポイントサービスを提供している会社はPosシステムとセットで展開しているところが多い。自分の知っている範囲だと以下あたり。

もっと有名なものもあるとは思いますが実体験ベースで話すため、経験がなんとなくあるこの辺りを実例に出しています。

なぜPosサービスを展開している事業者がポイントサービスを展開？

まず、押さえておきたいのはバーコードを読み込めるのはバーコードリーダーだけという点である。

当たり前のことだが、この制限によってバーコードによるポイントサービスを提供できる企業は限られる。

バーコードリーダーを提供している業界の古株が東芝テックである。また寺岡精工は調べたところシェアが広いわけではないが、中小企業をメインにバーコードリーダー含めたPosサービスを提供している。（自分が経験があるためこの辺りの名前を上げているだけで業界的に他に有名なところもいろいろあるはず。）

東芝テックの歴史については面白い本があったので最後におまけで書き足します。

そのためこれら企業がバーコードによるポイントサービスを提供するには、Posで読み取ったバーコード情報を自分達のサーバーに転送し、自分達のポイント管理DBにて管理するだけなので仕組みというとそれだけって感じです。

また、これら企業のPosは他企業のポイントサービスにて発行されたバーコードを読み取って連携することで、いろんな企業のポイントサービスの窓口にもなっています。

Posレジで読み取れる形式でバーコードが発行されていさえすれば楽天ポイント、dポイント、Paypayポイント、といったものも各自がバーコードを発行し、東芝テックや寺岡精工のサーバー経由で連携するような処理をしているのだと想像できます。

バーコードリーダーの代替となるタブレット端末

上記で見てきたように、バーコードリーダー端末を提供している企業がバーコードを用いたポイントサービスを展開しているのはお分かりいただけたかとおもいます。

ただ、バーコード or QRコードの読み取りは近年ではタブレット端末などのカメラを使って行うことも可能になってきています。

むしろタブレット端末がこれだけ一般化した世の中では小規模事業者がPosを導入するにはこの選択肢が最適かと思います。

このあたりを押さえ始めたのがAirレジなのかなーと個人的には思っています。(実際にどこが先駆けなのかまではあまり知らないですが)

タブレット端末であれば、独自のバーコード読み取りカメラ機能をもったアプリをダウンロードするだけでいいので、コストは押さえることができるし、定期的なアップデートも簡単です。

つまりどんどん高機能化することが簡単なのが物理のバーコードリーダーでは今までできなかった強みだったりするのだと思います。

少しPosの話に脱線しましたが、バーコードでポイントサービスを小規模事業者が行うには、こういったアプリによるスモールスタートという選択肢もあることがわかってもらえたらOKです。

バーコードとQRコードの歴史

str.toyokeizai.net

上記整理をするのにこの本が非常に役に立ったので、ここで以下二つの部分を紹介します。

  1. バーコードが普及した経緯とは？（東芝テックの役割も含めて）
  2. QRコードは何がすごい？

バーコードが普及した経緯

そもそも、QRコードはトヨタの生産システムの一部を担っていた「デンソー」によって開発された。当時の既存バーコードは油などの汚れに弱く、読み取り装置側も精度が悪く少し曲がったりくしゃくしゃの袋に貼られていたりすると読み取れなかった。

これらを改善するために独自のバーコード規格とそれを読み取るバーコードリーダーの開発が行われた。これによってNDコードという独自バーコード規格と油汚れがあっても読み取れるバーコードリーダーが誕生した。

これらがトヨタの工場に導入されると今度はこれを外に売っていく動きが出てきた。

その頃、国内ではセブンイレブンジャパンが初代Posレジを導入したところでバーコードリーダーの精度の悪さに四苦八苦していたらしい。このことをレジメーカーだった東芝テック経由で知ることになり、精度の高さから気に入られ導入が決定する。

このようにしてバーコードとバーコードリーダーは普及していった。

今ではPosレジトップシェアを誇る東芝テックは、この頃から時代の変遷の最中に関わっていたことがよくわかった。

QRコードは何がすごい？

バーコードはそもそも一次元コードと呼ばれ、情報は横方向に積み上げるしかなく、高度経済成長でさまざまな種類の情報を格納しないといけなくなった近代では格納できる情報量に限界があった。

そこで横方向だけではなく縦方向にも情報を詰める2次元コードの開発が急がれた。当時から二次元コードはアメリカにてすでにいくつか開発されていたがどれも一長一短であり用途によって推奨されるコードが別々になっており非効率な状況だった。

こういった中で開発されたQRコードは以下のような特徴を持っているこれまでの規格を上回るものだった。

  1. 容量: 二次元コードの中で最大
  2. 小型化: 他の最も小さいものと変わらない程度
  3. 高速読み取り: 最高速
  4. 誤り訂正: 30%まで向上

要するに最も大量の情報を高速に処理できる新規格がQRコードだったということである。

このことがわかると世の中のQRコードを採用しているサービスが一体どれくらいのデータをQRコードに持たせているのか？それはバーコードでは足りないのか？といったところが気になるところである。

まとめ

ちょっとした一言に引っかかって調べ始めたバーコードに関する疑問ですが深掘りしていくと、世の中の裏側の歴史を知ることができました。

ちょうどタイミングよく本屋でバーコードに関する本と出会えたのもこの記事を書くきっかけになりました。長々とお読みいただきありがとうございました。

Postman InterceptorでブラウザのCookieとPostmanを同期する

Postman Interceptor

Postman InterceptorというChromeの拡張機能がある。

これをinstallすると以下のような画面になる。

1. リクエスト・レスポンスのキャプチャ

今回の記事のメインではないがNetwork通信処理をキャプチャできる。

以下は開発中のGoogleログイン機能だが、これをキャプチャしてみる。（以下画像のrequestResponseの履歴は一旦無視してください。）

  1. 上記のStart Captureをクリック
  2. GoogleログインをクリックしてNetwork通信が発生。
  3. Stop Captureを押すとPostmanを開きますか？とダイアログが出る。

  1. Postmanを開くとHistoryタブに飛ばされキャプチャ結果がまとめられたページに飛ばされる。

    通信ログを見てみるとaccounts.google.com/o/oauth2/v2/auth=~などGoogleとの通信部分がキャプチャできていることがわかる。

このようにしてブラウザ上のRequestResponseをキャプチャすることができる。

2. Cookieの同期

この記事の本題だがブラウザ上で取得したCookieのデータを同期することができる。

  1. Postman側でStart Syncingボタンから開始

  1. Postman側のStop Syncingを押した後、Manage Cookiesタブで確認すると上記のaccess_tokenというCookie内の情報が取得できていることが確認できる。

まとめ

このようにCookieの同期をすることでCookie認証などを使っているAPIへのローカルでのテストが簡単になるので、ぜひ使ってみてください！

Goの*[]T型はほぼ意味ない

Go

モチベ

[]List{Task: []Task} のような大きめのオブジェクトを効率的に渡すためにポインタを使おうとしたが、実際どう実装するのが効率がいいのか整理がついてなかったので整理する。

GoのSliceの仕組み

そもそもSliceは配列への参照をすでに持っている。つまり引数や返り値でSliceを受け渡す＝配列への参照を持った構造体（以下画像の左の部分）を渡すor返すということである。

Go Slices: usage and internals - The Go Programming Language

上記を踏まえたSliceをポインタ型で渡すor返すとは？（*[]T型のこと）

そもそも配列本体の参照しか持っていないスライスのポインタを受け渡すことになる。

スライス自体は大した容量ではないのに、無駄に2重参照してしまうことになる。だからスライスのポインタ型はあまり意味がない。

サイズが大きいオブジェクトのSliceを扱う場合はどうすべき？

Sliceに格納する大きいオブジェクトはポインタ型であるべきか、その必要はないか？という話。要は以下のどちらにすべきか？の話。

// A:[]BigObject
sliceA = append(sliceA, BigObject{})
// B:[]*BigObject
sliceB = append(sliceB, &BigObject{})

結論: Bでやりましょう。

Aでやってしまうとメモリを大きく消費するポイントが2つある。

  1. appendはcapが足りなくなると、capを一定のルールに従って増やした新配列を作成し、その芯配列に既存配列の値を全てコピーする。（既存配列全てをコピーするので重い）
    1. その際のコピーは値コピーとなるのでSliceに含まれるオブジェクトが大きいとこの新規配列のタイミングでメモリを大量に消費することになる。
  2. appendでcapが足りている場合、配列の末尾にBigObjectを追加するだけ。
    1. これもBigObject自体が大きければメモリを消費するが1.に比べるとこれ単体のサイズ分しか消費しないのでまだマシ。

[]T, []*T, *[]Tの違いで整理

https://www.reddit.com/r/golang/comments/12sb4iq/should_i_use_a_slice_pointer_or_a_slice_of/

上記のようなスレッドを参考に、結論は以下のように整理しました。

  • []T：Tのサイズが小さければOK
  • []*T：Tのサイズが大きければこちらの方が良い。Tが小さいなら過剰。
  • *[]T：無駄な2重参照をしている。やる意味なし。（※実務で有効な場面はほぼない）

2025年に読んで良かった本 / 聞いて良かったPodcast

2025年 呼んでよかった本

技術書でちゃんと年間通しては12冊くらいしか読めてないのかと改めて見返してみると、積読が多すぎたなと言う一年だった。

まぁCKA取得のために時間かなり取られたのでそんなもんかなと言う印象、技術イベントとかも色々追っかけてたし。来年はもう少し計画的に積読消費できるようにしたいですね。

技術書以外も2冊だけ紹介。

単体テストの考え方/使い方

book.mynavi.jp

今年読んだ中で１番よかった。エンジニアは全員読むべき。

今までのテスト駆動開発によるMock至上主義の自分の考え方を根本から覆される内容になっていて、自分の中の単体テストに関する考え方を大きく変えてくれた本。

本にも記載がある「Mockを使いすぎることによる実装との結合度が上がってしまう問題」に言語化できない程度のモヤモヤを抱えていたが、その部分を整理して新しい指針を示してくれた。

昔からテストを書いてきてTDDが現れる前の考え方を知っている人からすると、一周回って戻ってきたなという感じなのかもしれないが、エンジニア人生が短い自分からするとこの本の指針は新しいものだった。

[Web開発者のための］大規模サービス技術入門

gihyo.jp

この本は今年読んだ中で2番目によかった。これもエンジニア全員読むべき。 今年の読んだ本で印象強く残っているのがこれと先に挙げた「単体テストの考え方/使い方」だった。

けっこう古い本なのだが、2025年9月？あたりにxで再バズりしていたような気がする。その波に乗って読んでみたら大規模サービスでぶち当たるリアルな問題をストーリー調で分かりやすく伝えてくれるものだった。

今まで大規模サービスに携わった経験の少ない自分からすると、どのあたりに問題が出やすいかの色眼鏡を増やしてくれる内容になっていてありがたかった。

具体的には、OSキャッシュの話、DBのI/O最適化の話、大規模サービスになることで小さな変更がどれだけ大きな影響を与えるかの話、この辺りの温度感と見るべきポイントの指針をくれる。

定期的に読み返すことでどういった部分が大規模サービスでボトルネックになるのかのパフォーマンスチューニングのヒントになる視点が散りばめられていてよかった。

桜の森の満開の下

桜の森の満開の下 (講談社文芸文庫 さB 2)

技術書じゃないですが、国語の先生を目指している人が課題図書として読むように言われていて面白いから是非と勧められて読んだ本。

様々の話の短編集になっていて、エロとホラーが混ざったような話が散りばっていて小説苦手な自分でも面白かった。

データ分析基盤入門＜基本編＞

gihyo.jp

これは個人的に今後データ分析基盤の開発に携わる機会が増えそうなので、そもそもデータ分析基盤でどういった概念・言葉が使われていて、どういった技術・設計になっているのかを知るために買った本。

自分と同じようにデータ分析基盤に関わるエンジニアが最初に読んでおくとどういった部分が重要で押さえておくべきところなのかといった部分を知ることができるので、はじめに読むのにちょうど良いなと思いました。

Go言語 100Tips

book.mynavi.jp

2月くらいからまたGo言語を使った開発に携わることができそうで、2年ほど実務から離れていたGo言語のTipsを学ぶために読み始めました。（2025年に買った本ではないですが）

まだ全部は読めていませんが、Go言語について深く知りたい人は一通り目を通せば中級者に慣れる本だと思います。

少し2025年時点では古く、途中のMapの内部構造に関するTipsは最新のVersionでは使えませんが（内部構造がそもそも改善されている）Goという言語の設計思想や注意点といった部分からインプットできるので非常に良い本かなと思います。

夜と霧

https://amzn.asia/d/gxTTcRO

名著なので今さらと言う感じ。

なんかの性格診断をした時にこの本を勧められた記憶があって、本屋で見かけたので購入。

心理学者の著者が考えていることが、自分が今までしんどい思いをしていた時と同じ考え方で物事を捉えていて性格診断もなかなかバカにできないなと思った。

具体的には、辛いことがあってもそれを俯瞰して「自分はどこまで耐えられるだろうか、見ものだな」とか「こんなことに耐えるとはなかなかやるな自分」とかどこか俯瞰して自分の体と頭を切り離しているところがそっくりだと思った。

起きている物事自体はショッキングだが著者の心理描写が面白くて読む手が止まらなかった。（まだ途中だけど）

2025年 聞いてよかったPodcast

結構Podcastも色々聞いていて直接有名な人が本に言及してくれていると理解が進みやすくてありがたいなと感じることが多い。ちなみにfukabori.fmが多いw

「fukabori.fm」69. チームトポロジー(前編) w/ miholovesq

fukabori.fm

自分はTeamToporogies本を持っていたのですが、内容がいまいちどこから読み込めばいいのか、どうやって活かせばいいのか？がわからず読めずにいたのですが、翻訳してくれた人がこの本の勘所を教えてくれるいい回だったなと思います。

「ひまじんプログラマーの週末エンジニアリングレッスン」#328 マルチスレッド、マルチプロセス、asyncioのお話

open.spotify.com

今年は自分が比較的レイヤーの低い部分の勉強をしていた際に、プロセスってそもそも何？とかNode.jsの非同期とは？Goのgoroutineとは？みたいな部分で迷っていた時にその辺りの理解の一助になってくれた。

個人的にはPython周りの話がなるほどと言う感想で、Pythonはデフォルトだと並列処理ができないところをFastAPIは並列化するためのライブラリを組み込んだ上で並列処理できるようにしているので早い。しかもそれはgoroutineの仕組みに近い。といったところが面白かった。

「fukabori.fm」34. NewSQLとは w/ tzkb

fukabori.fm

DB界隈では有名人のこば(tzkb)さん出演回。

NewSQLとは？に至る前にこれまでのDBの歴史を振り返ってくれている。新米エンジニアからしたらそんな時代のことから聞かせてもらえるのはありがたい。

「Web系で難しいのはWriteのスケールアウト」と言うところから話が始まって、Spannerと言うNewSQLが出てくるまでとそれを受け継いで進化していった「YugabyteDB/CockroachDB/TiDB」あたりの話も面白かった。

趣味でOSSをやっている者だ 50: SQLアンチパターン第2版・削除フラグを添えて (t_wada)

oss4.fun

t_wadaさん出演回。

最近2025年年末に話題になっていた削除フラグについて何が問題なのかと対応策について話してくれている。

それだけではなく、SQLアンチパターンの第2版の改訂部分に関することも話してくれていて、今となってはアンチパターンではなくなったので削除された項目について話してくれているのも学びになった。

これを聞いてSQLアンチパターン第2版を買おうと思った。決め手は付録？についている正規化に関する章が追加されてその部分がちょうど良い内容だったと聞いたのが決め手でした。

まとめ

来年はもう少し基礎を固めるような本をしっかり読んでいきたいなと振り返ってみると思いましたね。

あと技術書以外も読んでもっと紹介したいかも。

deleted_at(ソフトデリート)の取り扱いについて

DB アーキテクチャ・設計・概念

論理削除がもたらす地獄って何がある？について幾つかのソースをもとに整理しておく。

50: SQLアンチパターン第2版・削除フラグを添えて (t_wada)

oss4.fun

ここではSQLアンチパターン第２版についての話がメインだが、その中で削除フラグについても触れている。

  • 削除フラグ自体を否定しているのではない。要件によっては必要な場面もある。

  • ただしそれは本当に「削除フラグ」という曖昧な概念に押し込めていいものか検討すべし。

    場合によってはアーカイブフラグや非表示フラグというカラムで管理するのが適切かもしれない。ビジネスロジックの解像度をもっと上げてそれでも削除フラグという概念に押し込めるのであれば良い。

デメリット

  • SQLでJOINする際にいちいちWHERE NOT NULL deleted_at がJOINの数だけ多くなり可読性が下がる。かつそれを書き忘れることによるバグを生みやすくなる。などのクエリ上の問題。
  • 以下要因によるパフォーマンス低下の問題もある。
    1. インデックスに残り続けることによるパフォーマンス悪化。
      1. ソフトデリート済みのレコードは、ディスク上のインデックス構造に残り続ける。
      2. そのためメモリ上に載せるページの有効行の割合が少なくなる。
      3. 有効ではないソフトデリート済みのレコードが有効な行と同等に扱われることで、メモリからの追い出しが頻発し、キャッシュヒット率が安定しなくなる。
      4. 結果、１クエリあたりのメモリ（バッファキャッシュ）上のページアクセス数と、ディスク I/O が増加し、パフォーマンスが悪くなる。
    2. IS NULL を使っているとOptimizerがインデックスを使わない判断をしやすくなる。
    3. 複合インデックスの並び順を間違えて、（deleted_at, email）などとすると全レコードスキャンが発生する人間的ミスが起きる可能性が残る問題。

論理削除という技術的負債、それでも僕たちは使い続ける

syu-m-5151.hatenablog.com

上記ブログの図がすごく整理されていてわかりやすいと思う。

一意制約の崩壊

UNIQUE制約をカラムにかけていた場合、機能しなくなる。（sample@examle.comを持つレコードをソフトデリートすると別のユーザが使えなくなる）

→ 自分がもし使う場合は解決策として複合UNIQUE制約をかけるようにしていたが、これはあまり綺麗なやり方ではない。

外部キー制約の崩壊

外部キー制約があれば、削除された参照先レコードについて考える必要がない。

しかし、論理削除が入ると参照先レコードが論理削除済みかアプリケーションコードで判定するようにしなければならない。実に相性が悪い。

CASCADE削除の崩壊

ON DELETE CASCADEによる削除機能が働かない。

usersが論理削除されてもそれを参照する他テーブルの関連データは削除されない。

削除したければこれもアプリケーションコードで実装が必要。

本当の問題

この記事でも、先ほどのPodcastでもそうだがやはりこの論理削除というものをモデルとしてきちんと設計に落とし込んでいないのが問題である。またその実現手段は他にもあることを考慮していないのも問題。

まぁとにかくPodcastで述べられている内容とほぼ同じ。

その他ツイートの内容

まぁ以下で述べられているのも同じことですね。「一生データ整合性を設計で担保しないといけなくなるし、外部キー制約(cascade)もユニーク制約も効かない、レコードが消されないのでインデックスも太る、プロジェクトに入ってきた新参の人がフラグを見逃す可能性」

https://x.com/mattn_jp/status/2001576782412071410?s=20