DEV Community: Kaziu

「先頭カラムが同じインデックス、それ1つ無駄ちゃう？」— 冗長インデックスの見つけ方と消し方

Kaziu — Tue, 15 Sep 2026 07:02:01 +0000

テーブルのインデックスを眺めていて、こんな2本が並んでいるのを見つけたことはないだろうか。

KEY        `idx_logs_on_import_id`            (`import_id`)
UNIQUE KEY `idx_logs_on_import_id_and_file`   (`import_id`, `file_path`)

結論から言うと、上の単独インデックスはたいてい消せる。この記事では「なぜ消せるのか」「本当に消していいのか（消せない例外）」「どう機械的に見つけるか」「安全な消し方」までを一通りまとめる。

なぜ「単独 `(import_id)`」が冗長なのか

ポイントは 複合インデックスの “左端プレフィックス（leftmost prefix）” は、単独インデックスとしても使える という B-Tree インデックスの性質だ。

(import_id, file_path) というインデックスは、まず import_id で並び、その中で file_path で並ぶ。電話帳が「姓 → 名」の順に並んでいるのを想像するといい。

「姓だけで探す」→ できる（左から順に並んでいるから）
「名だけで探す」→ できない

同じように (import_id, file_path) は、

WHERE import_id = ? → 効く（左端が import_id）
WHERE file_path = ? → 効かない（2番目のカラム単独では使えない）

つまり WHERE import_id = ? の検索は、複合インデックスがそのまま賄える。単独の (import_id) は複合と役割が丸かぶりというわけだ。

冗長インデックスは「あって困る」

「使わないだけで害はないのでは？」と思うかもしれないが、インデックスはタダではない。

書き込みが遅くなる：INSERT / UPDATE / DELETE のたびに、全インデックスを更新する必要がある。冗長な1本ぶん、無駄な更新コストが毎回乗る。
ディスク・メモリを食う：インデックスは実データとは別に実体を持つ。バッファプールも圧迫する。
オプティマイザの選択肢を無駄に増やす：実行計画の検討対象が増える。

読み取りのメリットはゼロ（複合で足りる）なのに、書き込みコストだけ払っている状態。これが「冗長」を消すべき理由だ。

どうやって機械的に見つけるか

目視で全テーブルを追うのは非現実的。ツールに任せよう。

1. MySQL 標準ビュー `sys.schema_redundant_indexes`（おすすめ・導入不要）

MySQL 5.7 以降なら追加インストール不要で使える。左端プレフィックスの重複を判定し、削除用の SQL まで生成してくれる。

SELECT
  table_name,
  redundant_index_name,     -- 冗長な方（消す候補）
  redundant_index_columns,
  dominant_index_name,      -- それを包含している方（残す）
  dominant_index_columns,
  sql_drop_index            -- そのまま実行できる DROP 文
FROM sys.schema_redundant_indexes
WHERE table_name = 'logs';

出力イメージ：

redundant_index_name : idx_logs_on_import_id
dominant_index_name  : idx_logs_on_import_id_and_file
sql_drop_index       : ALTER TABLE `app`.`logs` DROP INDEX `idx_logs_on_import_id`

2. `pt-duplicate-key-checker`（Percona Toolkit / CLI）

DB 全体をまとめてスキャンして、重複・冗長インデックスと DROP 文を吐く定番ツール。CI や定期ジョブに組み込みやすい。

pt-duplicate-key-checker --host 127.0.0.1 --user readonly --ask-pass

3. `sys.schema_unused_indexes`（未使用インデックスの検出）

「冗長」とは別軸で、「前回のサーバ起動以降、一度もクエリで使われていないインデックス」を洗い出せる。ただし後述の FK 注意あり。

4. ORM 付属のツール（例：Rails の `active_record_doctor`）

アプリ側から detect_extraneous_indexes（冗長）や detect_unindexed_foreign_keys（FK に索引が無い）を検出できる。マイグレーションと同じ言語で回せるので CI 相性が良い。

【重要】消してはいけない冗長候補：外部キー（FK）の索引

ツールが「未使用」「候補」と出しても、消すとエラーになるインデックスがある。それが 外部キーの索引だ。

MySQL は「親テーブルの行が削除・更新されたとき、それを参照している子行がいないか」を毎回チェックする。これは実質 WHERE fk_column = ? の検索で、索引が無いと毎回フルスキャンになって激遅。だから MySQL は「FK を張るなら子カラムに索引を必ず持て」と要求し、無ければ自動で作る。

-- これは「未使用」に見えても、FK のために必須。消すと ERROR 1553。
KEY `fk_logs_on_user_id` (`user_id`),
CONSTRAINT `fk_logs_on_user_id` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`)

見分け方：その FK カラムを「左端」に持つ “別の” インデックスがあるか？

あるなら（例：複合インデックスの左端が FK カラム）→ FK の要件はそちらが満たすので、単独インデックスは消せる。
無いなら → その索引が FK 唯一の頼み → 消せない（消すと ERROR 1553: Cannot drop index ... needed in a foreign key constraint）。

冒頭の例で単独 (import_id) を消せるのは、複合 (import_id, file_path) の左端が import_id で、FK の索引要件も肩代わりできるからだ。

安全な消し方

マイグレーション

インデックスを1本 DROP するだけ。可逆（ロールバックで復活）にしておく。

class RemoveRedundantIndexFromLogs < ActiveRecord::Migration[8.0]
  def change
    remove_index :logs, column: :import_id, name: 'idx_logs_on_import_id'
  end
end

素の SQL なら：

ALTER TABLE `logs` DROP INDEX `idx_logs_on_import_id`;

適用前に「本当に消せるか」を実地で裏取り

とくに FK が絡むカラムは、机上で「複合が包含するはず」と思っても、実際に DROP して ERROR 1553 が出ないかを一度確認しておくと安心だ。開発 DB で up → down して、元に戻せることも確認しておく。

# 実際に DROP が通るか（FK エラーが出ないか）を確認
bin/rails db:migrate:up   VERSION=<version>
# 確認できたら元に戻す（開発 DB を汚さない）
bin/rails db:migrate:down VERSION=<version>

up が ERROR 1553 を出さずに通れば、「複合インデックスが FK の索引要件を満たしている」ことの動かぬ証拠になる。

Railsのstructure.sqlって何？何のため?

Kaziu — Tue, 15 Sep 2026 02:55:12 +0000

Railsのプロジェクトを触っていると、db/structure.sql という巨大なファイルに出会います。
「これ何？勝手に書き換わるけど触っていいの？」と戸惑いがちなこのファイルを、初心者向けにまとめます。

結論：DBの「完成形の設計図」

structure.sql は、ひとことで言うと

今のデータベースの構造を、ゼロから丸ごと再現するためのSQL命令をまとめた「完成形の設計図（スナップショット）」

です。しかもRailsが自動で生成・更新するファイルで、人が手で書くものではありません。

中身はこんなイメージです。

CREATE TABLE `deals` (              -- 「案件」テーブルを作る命令
  `id` bigint unsigned NOT NULL,
  `name` varchar(255),
  ...
);

CREATE TABLE `contacts` ( ... );    -- 「コンタクト」テーブルを作る命令
...（全テーブル分つづく）...

-- 末尾に「どの設計変更まで適用済みか」の台帳
INSERT INTO `schema_migrations` VALUES
('20260806000000'),
('20260805000000'),
...

前半に全テーブルの CREATE TABLE、末尾に「どこまで変更を適用済みか」の台帳（schema_migrations）が入っています。

前提知識：マイグレーションとの関係

structure.sql を理解するには、マイグレーションとセットで考えるのが近道です。

マイグレーション = DB構造の変更履歴（＝設計変更の指示書の束）
- 例：「dealsテーブルにstatus列を追加する」といったファイルが1変更につき1つ
- ファイル名は 20260803000000 のような 日付＋番号
structure.sql = その履歴を全部適用し終えた最終結果のスナップショット

図にするとこうです。

① 開発者がマイグレーションファイルを書く（変更の指示書）
         例:「dealsにstatus列を追加」

② db:migrate を実行 → 実際にDBが変更される

③ ★このときRailsが自動でstructure.sqlを"今のDBの姿"に更新する★

つまり structure.sql は、db:migrate の副産物として自動更新されるもの。原則、手で編集しません。

何のためにあるの？

一番の存在理由は、新しくDBを一から作るときに速いからです。

新メンバーが環境構築するとき、あるいはテスト用DBを毎回作り直すとき、DBを「まっさら → 最新の形」にする必要があります。その方法は2つあります。

方法	やること	速度
マイグレーションを全部実行	何百個の指示書を1個ずつ順番に実行	遅い
`structure.sql` を読み込む	完成形を一発で再現	速い

なぜマイグレーション全実行は遅いのか

理由①：歴史をもう一度なぞるので無駄が多い

マイグレーションは変更履歴なので、全実行すると過去の回り道まで再現します。

① dealsテーブルを作る
② dealsにstatus列を追加
③ ②のstatus列を削除する   ← 気が変わった
④ dealsにstate列を追加

最終的に欲しいのは「statusは無く、stateがある」状態だけ。でも全実行は②で作って③で消す無意味な往復まで律儀に再現します。structure.sql は最終結果だけなので回り道しません。

理由②：1個ずつ直列でしか実行できない（オーバーヘッド）

マイグレーションは順序依存なので並列化できず、1個ごとに「Rails起動→コード読込→SQL変換→実行→台帳記録」の準備・後片付けが発生します。これが数百回積み重なる。
structure.sql は1本の巨大なSQLを流し込むだけなので、この繰り返しコストがほぼゼロです。

理由③：中間状態の作り替えが積もる

同じ「state列を追加」でも、マイグレーションはテーブル作成→列追加→列削除→別の列追加…と中間状態を何度も作り替えます。インデックスの貼り直しなどが絡むとさらに遅くなります。

たとえ話

マイグレーション全実行 = 料理番組を1話目から全部見て、途中の失敗作まで作り直して追体験する
structure.sql = 完成した料理の写真とレシピを見て、それだけ作る

欲しいのは完成品だけなので、後者が圧倒的に速い、というわけです。

だから2つを使い分ける

structure.sql とマイグレーションは、どちらか一方が偉いのではなく、場面で使い分けます。

場面	使うもの	理由
新環境構築・テストDB作成	structure.sql（完成形）	履歴をなぞる必要はなく、速く最新状態を再現したい
稼働中の本番DBを変更	マイグレーション（差分だけ）	既存データを保ったまま「今回の変更分」だけ安全に当てたい

新メンバーの環境構築は「まっさら → 最新形にしたいだけ」なので、structure.sql が最適です。

補足：schema.rb と structure.sql

Railsの設計図には2形式があり、プロジェクトごとにどちらか一方を選びます。

ファイル	中身	特徴
`db/schema.rb`	Rubyで書かれた設計図	シンプル。Railsのデフォルト
`db/structure.sql`	生のSQLで書かれた設計図	トリガーやDB独自機能まで忠実に表現できる

MySQLのトリガーや細かい制約など、Rubyの schema.rb では表現しきれない機能を使っているプロジェクトでは structure.sql を選びます。

まとめ

質問	答え
structure.sqlって何？	今のDB全体の構造を再現するSQLをまとめた「完成形の設計図」
Railsが作るの？	はい。`db:migrate` 実行時に自動生成・更新される
手で書く？	原則ノー。自動更新される
何の役に立つ？	新環境・テストDBを一瞬で最新構造にするため

SQL複数カラムの計算結果をインデックスにまとめる設計手法と、書き込みオーバーヘッドの限界

Kaziu — Mon, 14 Sep 2026 14:42:59 +0000

データベースで複数のカラムを掛け合わせた検索（例：(単価 × 数量 - 割引) × 税率）を実行すると、通常は全件スキャン（Table Scan）が発生して大幅な遅延を引き起こします。

この記事では、複数カラムの計算結果を単一または複合インデックスへ集約する方法と、気になる書き込み時のオーバーヘッド（遅延リスク）のレベル感・警戒時の対策について解説します。

1. 複数カラムの計算結果をインデックスにまとめる2つの手法

例えば、以下の 5 カラムを持つ orders テーブルを考えます。

price（単価）
quantity（数量）
discount（値引き）
tax_rate（税率）
status（注文ステータス）

「合計請求金額が 10,000 円以上の完了済み（completed）注文」を高速検索したい場合、アプローチは 2 通り存在します。

アプローチA：式インデックス（Expression Index）を直接貼る

計算式そのものをインデックスに定義し、status カラムと組み合わせた複合インデックスを作成します。

SQL (PostgreSQL)

CREATE INDEX idx_orders_total_amount_and_status ON orders (
  ((price * quantity - discount) * (1 + tax_rate)), 
  status
);

Rails migration

class AddCalculatedIndexToOrders < ActiveRecord::Migration[7.0]
  def change
    add_index :orders, 
              ["((price * quantity - discount) * (1 + tax_rate))", :status],
              name: "idx_orders_total_amount_and_status"
  end
end

アプローチB：生成列（Generated Column）＋複合インデックス【おすすめ】

式が複雑な場合、テーブルに「計算結果カラム」を定義してそこにインデックスを貼る方が、SQLの可読性とメンテナンス性が格段に向上します。

Rails (Migration)

class AddTotalAmountToOrders < ActiveRecord::Migration[7.0]
  def change
    change_table :orders do |t|
      # 1. 4つのカラムを使った計算列を定義（DB側で自動計算＆保存される）
      t.virtual :total_amount, 
                type: :decimal, 
                precision: 10, 
                scale: 2, 
                as: "(price * quantity - discount) * (1 + tax_rate)", 
                stored: true

      # 2. 生成列と status の複合インデックスを作成
      t.index [:total_amount, :status], name: "idx_orders_total_amount_and_status"
    end
  end
end

2. 書き込み（INSERT / UPDATE）オーバーヘッドのレベル感

計算インデックスや生成列を使用すると、対象カラムのいずれか 1 つでも INSERT または UPDATE されるたびに「再計算＋ B-Treeインデックスの再配置」が発生します。

パフォーマンスへの影響度は「データ件数」よりも「1秒あたりの書き込み・更新回数（TPS）」に依存します。

警戒レベル	1秒あたりの書き込み/更新数 (TPS)	アプリへの影響・状況判定・推奨アクション
レベル 1：安全	〜 50 回/秒	一般的なWebシステムやECサイト。ミリ秒以下の処理で完結する。対策不要（積極的に導入して良い）
レベル 2：注意	100 〜 500 回/秒	スパイク時のアクセスやSNSアプリ。書き込みのレイテンシがわずかに上昇。モニタリング継続（Slow Queryログを監視）
レベル 3：警戒	1,000 回/秒以上	IoTデータ受信、金融取引、大量バッチ処理。CPU使用率急増・ロック詰まりが発生。要対策（アーキテクチャの見直しが必要）

どのくらいの「データ量」で影響が大きくなる？

データ量が増えると、「インデックス自体のサイズがメモリ（RAM）に入り切らなくなったタイミング」でパフォーマンスが急激に落ちます。

メモリに収まるサイズ（〜数百万件）：
インデックスの更新処理がすべてメモリ（RAM）上で完結するため、計算オーバーヘッドがあってもミリ秒以下（数ミリ秒）で終わります。
メモリに入り切らないサイズ（数千万件〜億単位）：
インデックスを更新するたびにディスク（SSD/HDD）への読み書きが発生します。こうなると、1回の UPDATE の遅延が数ミリ秒から数ミリ秒〜数秒へと跳ね上がります。

特に遅くなりやすい「ワーストケース」のパターン

同じ書き込みでも、以下のパターンは特にオーバーヘッドが大きくなります。

更新が超頻繁なカラム（例：updated_at や status）が含まれている
price などの金額は一度決まると滅多に変わりませんが、status や updated_at が計算式に含まれていると、ステータスが変わるたびに計算＆インデックス再配置が発生します。
一括更新（UPDATE ... WHERE や BULK INSERT）を行う
1件ずつの更新なら数ミリ秒の遅延で済みますが、UPDATE orders SET price = price * 1.1 のように10万件を一括更新する場合、10万回の再計算とインデックス更新が同時に走り、DBが数秒〜数分フリーズします。

Rails の `dependent: :destroy` が激重になる話を簡単な例で

Kaziu — Mon, 14 Sep 2026 06:28:26 +0000

何が起きるか

親レコードを消すと、子レコードも一緒に消えて便利な dependent: :destroy（いわゆる cascade 削除）。
でも子がコールバックを持っていると、削除のたびにそれが発火します。

class Author < ApplicationRecord
  has_many :books, dependent: :destroy
end

class Book < ApplicationRecord
  belongs_to :author, touch: true   # 消すと親の更新日時を更新（いわゆる touch）
  after_destroy :reindex_search     # 1件消すたびに Elasticsearch を再インデックス（同期・重い）
end

author.destroy すると…

Author を1件destroy
 └─ books が1000件あれば 1件ずつ destroy（cascade）
      └─ そのたびに親を touch し、after_destroy で
         Elasticsearch 更新が「直列」で1000回走る 😱

件数が少ないうちは気づかず、本番のデータ量で突然タイムアウトします。

対策：重い子だけ「コールバック無し」で先に消す

delete_all はコールバック（cascade も touch も）を発火させず、SQL 1発で消します。

ActiveRecord::Base.transaction do
  Book.where(author_id: author.id).delete_all  # ① 重い子を静かに一掃
  author.destroy                               # ② もう子はいないので連鎖しない
end

# Elasticsearch の更新は捨てずに、あとで非同期・一括で1回だけ
ReindexJob.perform_later(author.id)            # ③ トランザクションの外で

ポイント3つ

やること	理由
重い子を `delete_all` で先に消す	コールバック（cascade / touch）を発火させない（`destroy_all` は発火する）
本体はそのあと消す	連鎖する子が残っていないので重い処理が走らない
重い処理（ES再インデックス）は非同期ジョブで一括	「同期で1件ずつ」→「非同期でまとめて1回」に置き換え

用語メモ

cascade（カスケード） … 親を消すと子も連鎖して消える挙動。dependent: :destroy がこれ
touch … 中身は変えず「更新された印」として関連レコードの更新日時だけ更新すること
destroy = 1件ずつ読み込み、コールバックを呼ぶ（安全だが遅い）
delete = SQLで直接、コールバックを呼ばない（速いが自己責任）

SQLの自己結合（self-join）を一番簡単な例で

Kaziu — Mon, 14 Sep 2026 04:51:17 +0000

「同じテーブルを自分自身に結合する」のが自己結合です。
初めて見ると「え、同じテーブルをJOIN…？」と戸惑いますが、
⭐️ 親子・上下の関係が1つのテーブルに入っているときの定番テクニックです。

例：社員テーブル（社員も上司も“社員”）

上司も社員なので、同じ employees テーブルに入っています。

id	name	manager_id（上司のid）
1	山田（部長）	(なし)
2	佐藤	1
3	鈴木	1

「各社員と、その上司の名前を並べて出したい」とき、
employees をもう一度、別名で結合します。

SELECT
  emp.name     AS 社員,
  boss.name    AS 上司
FROM employees AS emp
LEFT JOIN employees AS boss   -- ← 同じテーブルを別名で結合
  ON emp.manager_id = boss.id;

結果:

社員	上司
山田（部長）	(なし)
佐藤	山田（部長）
鈴木	山田（部長）

ポイントは「別名（AS）」

同じテーブルなので、AS emp / AS boss と別名を付けて別テーブル扱いにするのが肝です。

emp.name … 社員本人の名前
boss.name … 上司の名前

別名がないと「どっちの name？」が区別できません。

LEFT JOIN にする理由

上司がいない人（部長など）も結果に残したいので LEFT JOIN を使います。
INNER JOIN だと上司がいない行が消えてしまいます。

まとめ

親子・上下の関係が同じテーブルにあるとき、テーブルを別名で自分自身に結合すると「本人＋相手」を1行に並べられる。 これが自己結合。

社員×上司、カテゴリ×親カテゴリ、取引先×その親の取引先など、
「同じ種類のもの同士の関係」を1テーブルで持つ設計で活躍します。

「Blob」って何？ブラウザでファイルをダウンロードする仕組み

Kaziu — Fri, 11 Sep 2026 03:13:11 +0000

CSVダウンロード機能を実装すると、こんな見慣れないコードが出てきます。

const blob = new Blob([response.data], { type: 'text/csv' })
const objectURL = window.URL.createObjectURL(blob)
downloadFile(objectURL, 'データ.csv')

「Blob？」「URLを作る？」「それをダウンロード？どこから？」を、この記事でスッキリさせます。

Blob とは

Blob = 中身が何でもいい「データのかたまり」。ブラウザにとっての"ファイルのようなもの"です。文字・画像・CSV・PDFなど何でも入り、「これはCSVです」といった種類ラベル（MIMEタイプ）を持てます。

ブラウザに「これはファイルだよ、保存してね」と伝えるには、データを"ファイルの形"＝Blobにする必要があります。生の文字データのままでは、ただの文字列としか扱われません。

手紙に例えると

手紙の例え	実際のもの
書類（CSVの中身）	`response.data`
封筒に入れる	`new Blob(...)`
宛名シールを貼る	`createObjectURL` のURL
投函する＝保存	`<a download>` をクリック

コードの意味

// ① バイナリのまま受け取る（これを忘れるとCSVが壊れることがある）
const response = await api.get(url, { responseType: 'blob' })

// ② データを「CSVファイル」の箱に入れる
const blob = new Blob([response.data], { type: 'text/csv' })

// ③ その箱を指す一時的なURLを発行する
const objectURL = window.URL.createObjectURL(blob)

// ④ そのURLをファイルとして保存させる
downloadFile(objectURL, 'データ.csv')

ポイントは ③のURL。これは https://... のようなサーバー上の場所ではなく、
いま手元（ブラウザのメモリ）にあるデータを指す案内シール です。

downloadFile の中身も単純で、「download属性つきの<a>を作ってJSでクリックするだけ」。

function downloadFile(url, filename) {
  const a = document.createElement('a')
  a.href = url
  a.download = filename
  a.click()
}

リンク先が blob: URL なので、サーバーに行かず、手元のデータをそのままファイル保存 します。
つまり「URLをダウンロード」と言っても、落とし直しではなく、すでに持っているデータを保存しているだけなのです。

補足：使い終わったURLは片付ける

createObjectURL のURLはメモリを占有し続けるので、使い終わったら解放するのが丁寧です。

window.URL.revokeObjectURL(objectURL)

まとめ

Blob = ブラウザにとっての"ファイルのようなデータのかたまり"
createObjectURL のURLは、サーバーではなく手元データへの案内シール
<a download> クリックで、そのデータがファイルとして保存される
この流れは画像・PDF・ZIPなどどんなファイルでも同じ

Ruby のブロックと yield を一番簡単な例で

Kaziu — Thu, 10 Sep 2026 05:24:33 +0000

Ruby を書いていると必ず出てくる「ブロック」と「yield」。
難しく見えますが、要は 「処理を渡す」「渡された処理を実行する」 だけです。

ブロックとは

メソッドに渡す「処理のかたまり（コードの切れ端）」 のこと。
{ } か do...end で囲みます。

[1, 2, 3].each { |n| puts n }
#              └──────────┘ これがブロック

.each に「各要素で puts n してね」という指示書を渡しています。

1
2
3

{ } と do...end は同じもの。長いときは do...end を使うだけです。

[1, 2, 3].each do |n|
  puts n
end

yield とは

メソッドの中の「yield と書いた場所」で、渡されたブロックを実行する命令。

def あいさつ
  puts "こんにちは"
  yield              # ← ここで渡されたブロックを実行
  puts "さようなら"
end

あいさつ { puts "元気ですか？" }

こんにちは
元気ですか？    ← yield の場所にブロックが差し込まれる
さようなら

yield は好きな場所に置け、何回でも呼べ、値も渡せます。

def 数える
  yield 1
  yield 2
end

数える { |n| puts "#{n}番目" }
# 1番目
# 2番目

2つの関係

ブロック = 渡す「やることメモ」（呼ぶ側が書く）
yield = そのメモを実行する命令（メソッド側が書く）

差し込む場所を決めるのがメソッド、差し込む中身を決めるのが呼ぶ側。

実践編：yield で処理を「挟み込む」

yield の本当に便利な使い方が、共通の前処理と後始末で、渡された処理を挟むパターンです。

def with_debug
  old = Rails.logger.level
  Rails.logger.level = :debug   # 前処理：ログを debug に
  yield                         # 呼び出し側の処理を実行
ensure　# エラーが起きても起きなくても、最後に必ず実行される(=finally)
  Rails.logger.level = old      # 後始末：必ず元に戻す
end

使い方：

with_debug do
  # この中だけログが debug になる
  user.save!
end
# ここを抜けると自動で元のログレベルに戻る

なぜ便利か

共通部分（ログ切替と復元）を1か所にまとめられる。使う側は「何をしたいか」だけ書けばよい。
ensure で後始末が保証される。ブロックの中でエラーが起きても、ログレベルは必ず元に戻る。

もし yield を使わなければ、使う場所ごとに「切替 → 処理 → 復元」を毎回コピペする羽目になります。yield なら枠（前後処理）はメソッド側、中身は呼ぶ側、ときれいに分けられます。

もう一つの例：処理時間を測る

同じパターンで「実行時間の計測」も書けます。

def measure(label)
  start = Time.now
  yield
ensure
  puts "#{label}: #{Time.now - start}秒"
end

measure("重い処理") do
  heavy_task
end
# => 重い処理: 1.23秒

「共通の前後処理でブロックを挟む」 ——これは Ruby で頻出の設計パターンです。
File.open { |f| ... }（開いて必ず閉じる）なども、この仲間です。

OCRで名刺を一括登録する機能をつくった話 — “1ページ複数名刺”という落とし穴

Kaziu — Tue, 14 Jul 2026 11:38:57 +0000

はじめに

展示会などでたまっていく紙の名刺を、CRMに手入力するのはなかなか大変です。そこで 「名刺を詰め込んだPDF（や画像）をアップロードすると、取引先・担当者データを自動で一括登録する」 機能を実務にて作りました。

最初は「OCRに投げれば終わりだろう」と思っていたのですが、実際にやってみると OCRは意外と万能ではない こと、そして どこで処理を分けるか という設計判断が肝になることに気づかされました。この記事では、その勘所と、いちばん悩んだ 「1枚のページに複数の名刺が並んでいたらどうするか」 という問題を共有します。

全体の流れ

ファイル（PDF / JPEG / PNG）をアップロード
サーバー側でバリデーション（形式・サイズ・ページ数）
「取り込み中」の履歴レコードをつくり、すぐにレスポンスを返す
重い処理（OCR → 構造化 → 登録/更新）はバックグラウンドジョブで実行
フロントは履歴IDをポーリングして進捗を表示

ポイントは 「受付」と「処理本体」をきっぱり分ける ことです。OCRや名寄せは数十秒〜数分かかることもあるので、リクエストの中で同期的に全部やろうとするとタイムアウトします。受付APIは「ファイルを保存して履歴をつくり、ジョブを起動するところまで」で潔く終わらせます。

OCRは“2段構え”

名刺の読み取りは、実は2つの異なる処理に分かれます。

文字を読む（OCR） … 画像から文字列を抽出する。ここは Google Cloud Vision のような汎用OCRの担当。
項目に振り分ける（構造化） … 抽出したテキストのうち「どれが会社名で、どれが氏名で、どれが電話番号か」を判定する。ここは自前の項目抽出モデルの担当。

名刺画像 → ①OCR(文字を全部読む) → テキスト → ②構造化(項目に仕分け) → { 会社名, 氏名, email... }

「OCR＝構造化まで全部やってくれる」と思いがちですが、①は文字と位置を出すだけ、②はそれを項目に整理するだけ。役割が別なのです。

設計で効いたポイント

バリデーションは“中身”で判定する。
「PDFかどうか」を拡張子やContent-Typeで見ると、画像を .pdf にリネームするだけで突破されてしまいます。ファイル先頭のマジックバイトで実体を判定するのが安全です。

大きいファイルはメモリに載せない。
名刺100枚分ともなるとファイルは大きくなります。ストレージ（S3等）へ送る際は全体をメモリに読み込まず、そのままストリームで流す。サイズチェックもメタデータだけ見て、中身は読みません。

PDFのページ数チェックは軽い読み取りで。
「◯ページまで」を受付時に弾きたいだけなら、画像化ライブラリ（ImageMagick等）は重すぎます。ページ数を数えるだけならレンダリング不要で、軽量なPDFパーサでメタデータを読めば十分です。

いちばん悩んだ問題：「1ページに複数名刺」

要件を詰める中で出てきたのが、1枚のスキャン画像（PDFの1ページ）に名刺が複数枚並んでいるケースです。コピー機やフラットベッドスキャナで数枚まとめて取り込めば、当然こうなります。

OCRは“名刺単位”には分けてくれない

ここが盲点でした。汎用OCR（Vision等）は「ページ内の全文字＋各文字の位置座標」は返してくれますが、「どの文字がどの名刺のものか」を論理的に分離する機能はありません（Google Cloud Vision の公式ドキュメントにも、1ページ上の複数文書を識別・分離する組み込み機能はなく、ブロックの位置を解析する独自ロジックが必要、と明記されています）。

さらに、OCRの「ブロック（文字の塊）」は レイアウト上の近接 でまとめられるため、隣り合う名刺が1つに融合したり、1枚の名刺が複数に割れたりします。「1ブロック＝1名刺」にはなりません。

構造化モデルも「名刺1枚分のテキスト」を仕分ける前提なので、複数名刺のテキストが混ざったまま渡すと、「A社の会社名＋B氏の氏名」が合体した誤ったデータが生まれてしまいます。

つまり「名刺ごとに切り分ける工程」を自前で挟む必要がある

OCR(全文字＋座標) → 【自前】名刺ごとに切り分け → 名刺A分 → 構造化
                                            → 名刺B分 → 構造化 → …

この切り分けの難易度は、名刺の並び方で大きく変わります。

並び方	アプローチ	難易度
固定テンプレート（常に2×3等）	ページを決め打ちで等分	低（ただし全ユーザーが同じ並べ方を強制される）
整然と並ぶが枚数可変	座標の“すき間”から行・列を動的に検出	中（ルールベース。傾き・密着・空きマスに弱い）
完全にバラバラ	名刺領域を検出するAIモデルを用意	高（モデルの学習・運用が必要）

真ん中の「座標から格子を推測する」方法は、こんなイメージのルールベース処理です。

すべての文字の座標を集める
X座標の大きなすき間を「列の境界」とみなす
Y座標の大きなすき間を「行の境界」とみなす
各マスを1名刺として、文字をグルーピングする

AIではなく幾何計算なので比較的軽い一方、傾き・名刺同士の密着・不揃いなサイズ・空きマスがあると崩れます。堅牢にするほど実データでのチューニングが必要になり、突き詰めると「AIで名刺そのものを検出する」方向に近づいていきます。

学び：仕様側で“制約”できると一気にラクになる

技術で無理にバラバラ配置へ対応するよりも、「名刺は等間隔に並べてスキャンしてください」といった入力の制約を設けるほうが、開発コストも精度リスクも大きく下がります。「どこまでの入力を許すか」はエンジニアだけで決めず、プロダクト側と早めにすり合わせるべき論点でした。

重複データの扱い（名寄せ）

一括登録では「すでに登録済みの取引先/担当者」との重複が避けられません。ここは

取引先は「会社名」または「会社名＋住所」で一致判定（支店を区別したいニーズもあるため住所も選べる）
担当者はメールアドレスで一致判定

を事前に選ばせ、ヒットしたものは更新、しなかったものは新規登録として扱います。「重複時に既存データを名刺の値で上書きするか」もユーザーが選べるようにしました（勝手に上書きされたくないニーズがあるため）。

まとめ

OCRは「文字を読む」＋「項目に仕分ける」の2段構え。OCRだけで構造化まで完結はしない。
受付と処理本体を分離し、重い処理は非同期ジョブへ。大容量ファイルはストリーム、バリデーションは中身で。
最大の落とし穴は 「1ページ複数名刺」。OCRは名刺単位に分けてくれないので切り分けは自前実装が必要で、並び方次第で難易度が激変する。
だからこそ 「入力をどこまで制約できるか」をプロダクトと握ることが、技術選定と同じくらい重要。

“OCRに投げるだけ”に見える機能ほど、実は要件と制約の設計が肝になる——という良い事例でした。

(後日談)

さんざん「1ページに複数名刺だったらどう切り分けるか…」と唸っていたのですが、プロダクト側に確認したら——

「PDFは1ページに名刺1枚の想定です」

……でした。盛大な取り越し苦労。笑

しかし勉強にはなりました。技術で殴る前に、まず要件を疑う。良い教訓になりましたわい。

Elastic search 基礎の基礎

Kaziu — Mon, 13 Apr 2026 05:56:56 +0000

(自分用メモ)

Mysqlとの違い

MySQL	ES
データベース	index
行(１件のデータ)	document
カラムの型	mapping

なので「インデックス再構築」はデータベース作り直しってイメージ

データの形

ESはJSON

{
    "deal": {
      "id": 1,
      "name": "TOYOTAへの提案",
      "has_materials": true
    }
  }

検索クエリの書き方

基本形

GET index name/_search
{
  "query": {
    ここに条件を書く
  }
}

query はSQLの WHERE 句

完全一致で検索したいっす (term)

SQLでいうと
WHERE has_materials = true

{
  "query": {
    "term": { "deal.has_materials": true }
  }
}

複数の条件をANDでつなぎたい (= bool + filter)

SQLでいうと
WHERE has_materials = true AND invoice_id = 3

{
  "query": {
    "bool": {
      "filter": [
        { "term": { "deal.has_materials": true } },
        { "term": { "deal.invoice.id": 3 } }
      ]
    }
  }
}

bool + filter の配列に条件を並べるとAND

テキストを部分一致で検索したい（= match）

SQLでいうと
WHERE name LIKE '%トヨタ%'

{
  "query": {
    "match": { "deal.name": "トヨタ" }
  }
}

マッピングって何ですの？

MySQLの「カラムの型定義（int, varchar...）」と同じ。
フィールドの型をあらかじめ宣言しておくもの。

{
  "deal": {
    "id":            { "type": "integer" },
    "name":          { "type": "text" },
    "has_materials": { "type": "boolean" }
  }
}

mapping変更したら？

インデックス作り直しですわ

NestJSの基本アーキテクチャと実プロジェクトでの活用事例

Kaziu — Wed, 18 Feb 2026 04:57:00 +0000

※ 本記事に掲載しているコード例は実際のプロダクトをベースにしていますが、プロジェクト名・サービス名・変数名など、特定のプロダクトを識別できる情報は変更・汎用化して記載しています。

(０から全部自分で書いてなく、AI生成したのを修正しプロジェクトの辞書の様に使用する目的)

NestJSはTypeScriptで構築されたサーバーサイドフレームワークで、Angularに影響を受けたモジュール指向のアーキテクチャが特徴です。本記事ではNestJSの基本概念を解説しつつ、実際のSaaSプロダクト（GraphQL API / マルチテナント構成）でどのように活用しているかを紹介します。

(*追記)↑って立派に書いたけど、そのプロジェクトあまり従事しなかったので、この記事のことあんま頭に入ってないです笑

1. Module（モジュール）

NestJSの基本

NestJSのアプリケーションは Module を単位として構成されます。@Module() デコレータで providers（提供するサービス）、imports（依存するモジュール）、exports（外部に公開するサービス）を定義し、DIコンテナを構成します。

@Module({
  providers: [CatService],
  imports: [DatabaseModule],
  exports: [CatService],
})
export class CatModule {}

実プロジェクトでの活用

本プロジェクトでは、レイヤードアーキテクチャに沿って3層のモジュールに分離しています。

app.module.ts
  ├─ ResolverModule群（interface/di/）  ← プレゼンテーション層
  ├─ UseCaseModule群（app/di/）         ← アプリケーション層
  └─ RepositoryModule群（infra/prisma/di/） ← インフラ層

ディレクトリ構成は以下のようになっています。

packages/api/src/
├── app/                      # Application層
│   ├── di/                   # UseCaseモジュール定義
│   └── useCases/             # UseCase実装
├── domain/                   # Domain層
│   ├── entities/             # ドメインエンティティ・型定義
│   ├── restrictFilters/      # 権限フィルター
│   └── common/               # 共通型・ユーティリティ
├── interface/                # Interface層
│   ├── di/                   # Resolverモジュール定義
│   ├── resolvers/            # GraphQL Resolver
│   ├── schema/               # リクエスト/レスポンス型
│   └── auth/                 # 認証Guard
├── infra/                    # Infrastructure層
│   ├── prisma/               # Repository・Mapper
│   └── ...                   # 外部サービス連携
└── entities/                 # GraphQL ObjectType定義

ResolverModuleは、UseCaseModuleを imports して依存を解決します。

@Module({
  providers: [CommentResolver],
  imports: [
    CommentUseCaseModule,
    UserUseCaseModule,
  ],
})
export class CommentResolverModule {}

UseCaseModuleは、RepositoryModuleや他のServiceModuleを imports します。

@Module({
  providers: [CommentUseCase],
  exports: [CommentUseCase],
  imports: [
    PrismaCommentRepositoryModule,
    PrismaRoomRepositoryModule,
    NotificationServiceModule,
  ],
})
export class CommentUseCaseModule {}

ポイント: NestJSのModule機構を活用して、クリーンアーキテクチャ的な依存の方向（interface → app → domain ← infra）を実現しています。

2. Controller / Resolver

NestJSの基本

REST APIの場合は @Controller() に @Get() / @Post() などのデコレータを使います。

@Controller('cats')
export class CatController {
  @Get()
  findAll() { return 'All cats'; }

  @Post()
  create(@Body() dto: CreateCatDto) { ... }
}

GraphQLの場合は @Resolver() に @Query() / @Mutation() / @ResolveField() を使います。

実プロジェクトでの活用

本プロジェクトではGraphQLを採用し、Code-Firstアプローチでスキーマを自動生成しています。

// app.module.ts
GraphQLModule.forRoot<ApolloDriverConfig>({
  driver: ApolloDriver,
  autoSchemaFile: join(process.cwd(), 'src/schema.gql'), // TypeScriptから自動生成
  fieldResolverEnhancers: ['guards'],
}),

Resolverの実装例：

@Resolver(() => GqlComment)
export class CommentResolver {
  constructor(private readonly commentUseCase: CommentUseCase) {}

  // Query: データ取得
  @UseGuards(AuthGuard)
  @Query(() => [GqlComment])
  async commentList(
    @Args('input') input: GetCommentListInput,
    @Context() context: OperationContext,
  ) {
    return this.commentUseCase.getCommentList(input, context);
  }

  // Mutation: データ変更
  @UseGuards(AuthGuard)
  @Mutation(() => GqlComment)
  async createComment(
    @Args('input') input: CreateCommentInput,
    @Context() context: OperationContext,
  ) {
    return this.commentUseCase.createComment(input, context);
  }

  // ResolveField: ネストされたフィールドの解決
  @ResolveField('author', () => GqlUser)
  async getAuthor(@Parent() comment: Comment) {
    return this.userUseCase.findOne({ id: comment.userId });
  }
}

主なデコレータ

デコレータ	用途
`@Resolver(() => Type)`	クラスをResolver宣言
`@Query(() => Type)`	GraphQL Query定義
`@Mutation(() => Type)`	GraphQL Mutation定義
`@ResolveField('name', () => Type)`	ネストフィールドの解決
`@Args('input')`	入力引数のバインド
`@Parent()`	親オブジェクトへのアクセス
`@Context()`	GraphQL Context（認証情報等）の取得

InputType（リクエスト型）

GraphQLの入力型もデコレータで定義します。

@InputType()
export class CreateCommentInput {
  @Field(() => GraphQLJSON)
  content: Prisma.JsonObject;

  @Field()
  roomId: string;

  @Field(() => [Int], { nullable: true })
  imageIds?: number[];
}

これにより、以下のGraphQLスキーマが自動生成されます。

input CreateCommentInput {
  content: JSON!
  roomId: ID!
  imageIds: [Int!]
}

3. Service / UseCase

NestJSの基本

@Injectable() デコレータを付けたクラスをServiceとして使い、ビジネスロジックを集約します。

@Injectable()
export class CatService {
  constructor(private readonly catRepository: CatRepository) {}

  findAll() {
    return this.catRepository.findAll();
  }
}

実プロジェクトでの活用

本プロジェクトでは「Service」ではなく 「UseCase」 と命名し、ユースケース単位でクラスを分割しています。

@Injectable()
export class CommentUseCase {
  constructor(
    private readonly commentRepository: PrismaCommentRepository,
    private readonly roomRepository: PrismaRoomRepository,
    private readonly notificationService: NotificationService,
  ) {}

  async createComment(input, context: OperationContext) {
    // 1. ドメイン検証
    const room = CoreAssert.isNotEmpty(
      await this.roomRepository.findOneById({ id: input.roomId }, context),
    );

    // 2. ドメインエンティティ作成
    const comment = createCommentSeed({
      ...input,
      userId: context.executor.userId,
    });

    // 3. DB保存
    const created = await this.commentRepository.create(comment);

    // 4. 通知・外部連携
    await this.notificationService.send({ ... });

    return created;
  }
}

ポイント: UseCase内でドメイン検証 → DB保存 → 副作用（通知・外部連携）の順で処理を組み立てています。Repositoryや外部サービスは全てコンストラクタインジェクションで注入されるため、テスタビリティが高いです。

4. DI（依存性注入）

NestJSの基本

NestJSのDIは、TypeScriptの型情報からプロバイダーを自動解決します。@Injectable() クラスをModuleの providers に登録し、コンストラクタの型で自動注入されます。

実プロジェクトでの活用

層をまたぐ依存は imports / exports で制御しています。

Resolver → constructor(useCase: CommentUseCase)     // 型で自動解決
UseCase  → constructor(repo: PrismaCommentRepository) // 型で自動解決

Module定義側：

// UseCaseModule: CommentUseCaseを外部に公開
@Module({
  providers: [CommentUseCase],
  exports: [CommentUseCase],          // 他のモジュールから利用可能に
  imports: [PrismaCommentRepositoryModule],
})
export class CommentUseCaseModule {}

// ResolverModule: UseCaseModuleをimportして利用
@Module({
  providers: [CommentResolver],
  imports: [CommentUseCaseModule],    // CommentUseCaseが利用可能に
})
export class CommentResolverModule {}

循環依存が発生する場合は forwardRef() で回避します。

@Module({
  imports: [forwardRef(() => RelatedModule)],
})
export class SomeModule {}

5. Guard（認証・認可）

NestJSの基本

CanActivate インターフェースを実装したGuardクラスを作成し、@UseGuards() デコレータで適用します。

@Injectable()
export class AuthGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest();
    return validateToken(request.headers.authorization);
  }
}

実プロジェクトでの活用

本プロジェクトはマルチユーザー型SaaSのため、ユーザータイプ（管理者 / ゲスト）に応じて異なる認証Guardを振り分けるパターンを採用しています。

@Injectable()
export class MultiUserAuthGuard implements CanActivate {
  constructor(
    private readonly adminAuthGuard: AdminAuthGuard,
    private readonly guestAuthGuard: GuestAuthGuard,
  ) {}

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const ctx = GqlExecutionContext.create(context);
    const request = ctx.getContext().req;
    const userType = request.headers['x-user-type'];

    if (userType === 'Admin') {
      // JWT検証（外部認証サービス）
      return this.adminAuthGuard.canActivate(context);
    } else if (userType === 'Guest') {
      // セッショントークン検証
      return this.guestAuthGuard.canActivate(context);
    }

    throw new UnauthorizedException();
  }
}

さらに @ResolveField レベルでの細かい権限制御も実装しています。

@ResolveField('author', () => GqlUser)
@UseGuards(UserTypesGuard)
@RequiredUserTypes('ADMIN')  // カスタムデコレータでメタデータ指定
async getAuthor(@Parent() comment: Comment) {
  return this.userUseCase.findOne({ id: comment.userId });
}

UserTypesGuard は Reflector を使ってメタデータを読み取り、権限チェックを行います。

@Injectable()
export class UserTypesGuard implements CanActivate {
  constructor(private reflector: Reflector) {}

  canActivate(context: ExecutionContext): boolean {
    const requiredTypes = this.reflector.get<string[]>(
      'requiredUserTypes',
      context.getHandler(),
    );
    if (!requiredTypes) return true;

    const gqlContext = GqlExecutionContext.create(context);
    const user = gqlContext.getContext().req.user;
    return requiredTypes.includes(user.executor.userType);
  }
}

6. Entity定義の多層構造

NestJSの基本

一般的なNestJSアプリケーションでは、1つのEntityクラスがDB定義とAPI定義を兼ねることが多いです。

実プロジェクトでの活用

本プロジェクトでは3層のEntity定義を使い分けています。

層	ファイル例	用途
GraphQL Entity	`entities/Comment.entity.ts`	`@ObjectType()` でAPI出力型を定義
Domain Entity	`domain/entities/Comment/index.ts`	Brand型による型安全なビジネスモデル
Prisma Model	`prisma/schema.prisma`	DBスキーマ定義

GraphQL Entity（API層）

@ObjectType()
export class Comment {
  @Field(() => Int)
  id: number;

  @Field(() => GraphQLJSON)
  content: Prisma.JsonObject;

  @Field()
  createdAt: Date;

  @Field(() => [CommentImage])
  commentImages: CommentImage[];  // ネストフィールド
}

Domain Entity（ドメイン層）

Brand型を使って、同じ number 型でもIDの種類を区別します。

// Brand型の定義
type Brand<T, U> = T & { __brand: U };

// IDを型レベルで区別
export type CommentId = Brand<number, 'CommentId'>;
export type UserId = Brand<number, 'UserId'>;

// 型エラー: CommentId と UserId は互換性がない
const commentId: CommentId = 1 as CommentId;
const userId: UserId = commentId; // コンパイルエラー!

ドメインエンティティの定義：

export type Comment = {
  id: CommentId;
  content: Prisma.JsonObject;
  roomId: RoomId;
  userId: UserId;
  tenantId: TenantId;
  createdAt: Date;
  updatedAt: Date;
};

// ファクトリ関数
export const createCommentSeed = (payload: CommentSeed): CommentSeed => {
  return { ...payload };
};

Prisma Model（DB層）

model Comment {
  id        Int       @id @default(autoincrement())
  content   Json?
  roomId    String
  Room      Room      @relation(fields: [roomId], references: [id], onDelete: Cascade)
  userId    Int
  createdAt DateTime  @default(now())
  updatedAt DateTime  @default(now()) @updatedAt
}

ポイント: 3層に分けることで、API仕様の変更がドメインロジックに影響しない、DBスキーマの変更がAPI層に漏れないという利点があります。

7. Prisma連携（Repository + Mapper）

NestJSの基本

NestJSではTypeORMやPrismaを直接サービスから利用するのが一般的です。

実プロジェクトでの活用

本プロジェクトではRepository + Mapperパターンを採用し、Prismaの型をドメイン型に変換しています。

Repository

@Injectable()
export class PrismaCommentRepository {
  async create(input: CommentSeed, db = client): Promise<Comment> {
    const prismaComment = await db.comment.create({
      data: {
        contentJson: input.content,
        roomId: input.roomId,
      },
      include: { Room: true },
    });

    // Prisma型 → Domain型への変換
    return PrismaCommentMapper.toDomainComment(prismaComment);
  }

  async findList(input, context, db = client): Promise<Comment[]> {
    const results = await db.comment.findMany({
      where: {
        roomId: input.roomId,
        Room: { tenantId: context.tenantId }, // テナント隔離
      },
      orderBy: { createdAt: 'asc' },
    });
    return results.map(PrismaCommentMapper.toDomainComment);
  }
}

Mapper

export class PrismaCommentMapper {
  static toDomainComment(prismaComment): Comment {
    return {
      id: prismaComment.id as CommentId,
      content: prismaComment.contentJson as Prisma.JsonObject,
      roomId: prismaComment.roomId as RoomId,
      userId: prismaComment.userId as UserId,
      tenantId: prismaComment.Room.tenantId as TenantId,
      createdAt: prismaComment.createdAt,
      updatedAt: prismaComment.updatedAt,
    };
  }
}

トランザクション

複数テーブルにまたがる操作は prisma.$transaction() で原子性を保証します。

const result = await prisma.$transaction(async (db) => {
  const room = await this.roomRepository.create(roomData, context, db);
  await this.memberRepository.create(memberData, db);
  return room;
});

ポイント: Repositoryメソッドはオプショナルな db 引数を受け取り、トランザクション内でもスタンドアロンでも動作するよう設計されています。

8. 認証コンテキストの流れ

マルチテナントSaaSにおける認証情報の伝搬フローです。

1. GraphQLリクエスト
   ├─ Header: Authorization: "Bearer <JWT>"
   └─ Header: x-user-type: "Admin" or "Guest"

2. Guard（認証処理）
   ├─ Admin → JWT検証 → OperationContext生成
   └─ Guest → セッション検証 → OperationContext生成
   └─ request.user = OperationContext にセット

3. Resolver
   └─ @Context() context: OperationContext で取得

4. UseCase / Repository
   └─ contextを利用した権限制御・テナント隔離

OperationContext はZodスキーマで型安全に定義されています。

export const operationContextSchema = z.object({
  tenantId: tenantIdSchema,
  executor: z.union([
    z.object({
      userType: z.literal('ADMIN'),
      userId: userIdSchema,
      role: roleSchema,
    }),
    z.object({
      userType: z.literal('GUEST'),
      userId: userIdSchema,
    }),
  ]),
});

export type OperationContext = z.infer<typeof operationContextSchema>;

カスタムデコレータ @Context() でResolverに注入します。

export const Context = createParamDecorator(
  (data: unknown, context: ExecutionContext) => {
    const ctx = GqlExecutionContext.create(context);
    return ctx.getContext().req.user as OperationContext;
  },
);

権限フィルターでDB操作時のテナント隔離を行います。

export const commentRestrictFilter = (
  context: OperationContext,
): Prisma.CommentWhereInput[] => {
  return [{ Room: { tenantId: context.tenantId } }];
};

// 使用例
const comments = await prisma.comment.findMany({
  where: { AND: commentRestrictFilter(context) },
});

9. まとめ：NestJS標準 vs 実プロジェクト

観点	NestJS標準	実プロジェクト
API方式	REST (`@Controller`)	GraphQL Code-First (`@Resolver`)
ビジネスロジック	Service	UseCase（ユースケース単位で分割）
データアクセス	ORM直接利用	Repository + Mapper パターン
認証	単一Guard	MultiUser振り分けGuard
型安全	TypeScript標準	Brand型 + Zod バリデーション
テナント隔離	なし	OperationContext + RestrictFilter
Entity	単一定義	3層（GraphQL / Domain / Prisma）
Module構成	機能単位	レイヤー単位（Resolver / UseCase / Repository）

おわりに

NestJSはそのままでも十分に強力なフレームワークですが、プロジェクトの規模や要件に応じてアーキテクチャをカスタマイズできる柔軟性も持っています。

本プロジェクトでは、NestJSのDI機構を活かしつつ、以下のような工夫を加えています。

レイヤードアーキテクチャ: Module単位でレイヤーを分離し、依存の方向を制御
Code-First GraphQL: TypeScriptのデコレータからスキーマを自動生成
Brand型: IDの取り違えをコンパイル時に検出
RestrictFilter: マルチテナントのデータ隔離をパターン化

NestJSの基本概念（Module / DI / Guard / Decorator）を理解しておけば、プロジェクトの要件に合わせた拡張も容易です。ぜひ参考にしてみてください。

たった1枚の引き伸ばされた画像から、AWS Lambdaのコード移行とCI/CD構築に至った話

Kaziu — Sat, 08 Nov 2025 00:42:07 +0000

始まり

ある日、開発中の画面でサムネイル画像が不自然に引き伸ばされて表示されていることに気づきました。

「ああ、このパターンな。CSSのobject-fitがcoverになってるのをcontainにすれば直るやつじゃ」

そう高を括ってコードを修正。しかし、表示は変わらず引き伸ばされたまま。ブラウザの開発者ツールで画像のURLを直接開いてみると、Amazon S3から返されている画像そのものが既に引き伸ばされていました

「まじすか先輩」

しかし、わしはプロジェクトに参加したばかりでしかもインフラはよぉ知らん。該当の画像生成処理がどこに書かれているのか見当もつきませんので同僚に聞いてみましたわ

「すんまへん、このサムネイル画像、どうもAWS側でリサイズされてるっぽいんですが、どこの処理か分かりますか？」

すると、同僚から

「ああ、その処理は別のインフラ用リポジトリにあるLambda関数がやってるんですよ。ただ、そのリポジトリを直接編集しても意味なくて、今のアプリケーション用リポジトリにコードを移行して、CI/CDを再設定する必要があるんですわこりゃ」

わしの頭の中は「あーLambda聞いたことあるわー、awsのやつじゃわー」て感じでしたが、とりあえずやってみました。

STEP1: Lambdaてそもそもなんですの？

これは「特定のイベントをきっかけに、自動で動いてくれる小さなプログラム」で、サーバーの管理を自分でする必要がない「サーバーレス」という仕組みの一つで、例えば以下のようなイベントをきっかけに処理を実行できます。

Amazon S3にファイルがアップロードされた時
API Gatewayにリクエストが来た時
特定の時間になった時 (cronのように)

今回のケースでは、「S3バケットにオリジナル画像がアップロードされたら、Lambda関数が起動してサムネイル画像を生成し、別のS3バケットに保存する」という処理が行われていたのです。これなら、画像が引き伸ばされている原因も、Lambda関数のコードを修正すれば解決できそうです

STEP 2: Lambda関数の移行とCI/CDの構築

旧インフラリポジトリから、Lambda関数のソースコードを現在のアプリケーションリポジトリに持ってくる。
持ってきたコードを修正し、画像が引き伸ばされないようにする。（今回はリサイズのロジックを修正、resize methodをthumbnail methodに変）
コードが更新されたら、自動でAWS上のLambda関数にデプロイされる仕組み（CI/CD）をGitHub Actionsで構築する。

▼ GitHub ActionsでLambdaに自動デプロイ
GitHub Actionsのワークフローを使い、特定のブランチ（例: main）にコードがプッシュされたら、自動でAWS Lambdaにデプロイされるように設定します。.github/workflowsの中に設定します

# sample code
name: Deploy to AWS Lambda

on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'デプロイ先の環境を選択してください'
        required: true
        type: choice
        options:
          - release-candidate
          - staging
          - production

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: ${{ github.event.inputs.environment }}
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      # ... (Node.jsやPythonのセットアップ、依存パッケージのインストールなど) ...

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-1

      - name: Build and Zip
        run: |
          # ビルドやパッケージングの処理
          zip -r function.zip .

      - name: Deploy to Lambda
        run: |
          aws lambda update-function-code \
            --function-name ${{ secrets.YOUR_LAMBDA_FUNCTION_NAME }} \
            --zip-file fileb://function.zip

このワークフローのポイントは2つです

1. 環境に応じたSecretsの利用

GitHubリポジトリの Settings > Environments で release-candidate, staging, production の各環境がありました。なのでそれぞれの環境のSecretsに YOUR_LAMBDA_FUNCTION_NAMEというキーで、対応するLambda関数名（例: rc-YourLambdaFunctionName）を登録しておきます。
ワークフローが実行されると、選択された環境に応じて適切な関数名が自動で読み込まれるため、デプロイ先を間違えるリスクを低減できます。

2. 手動トリガーによる安全なデプロイ

on: push を使わず on: workflow_dispatch を使うことで、意図しない自動デプロイを防ぎます。開発者はGitHubのActionsタブから「Run workflow」ボタンを押し、デプロイしたい環境を選択するだけで、安全かつ確実にリリース作業を行えます。

🔥 つまずきポイント：GitHub Actionsの「Run workflow」が表示されない！

ワークフローを作成し、いざ手動で実行テストをしようとした時のことです。GitHubリポジトリのActionsタブを見ても、手動実行ボタンである「Run workflow」が表示されません。

原因は単純で、workflow_dispatch を含むワークフローファイルが、リポジポジトリのデフォルトブランチ（mainやmaster）にマージされていないと、手動実行のUIは表示されないという仕様でした。
開発ブランチでいくら試行錯誤してもボタンは現れません。この仕様を知らずに、githubと戦っておりました

まとめ

たった1枚の引き伸ばされた画像でしたが、AWS Lambda、そしてCI/CDの世界に飛び込めました

表示の不具合は、必ずしもフロントエンド、バックエンドが原因とは限らない。
AWS Lambdaは、イベント駆動で動く便利な自動処理プログラム。
ワークフローの手動実行（workflow_dispatch）は、デフォルトブランチでしか有効にならない。

てなわけでバグも修正され、気持ちよくなりましたわ〜

A better way to call functions in a child component from a parent component in React

Kaziu — Thu, 06 Mar 2025 07:49:18 +0000

❓Question

// should define in child component (<Body>) 
//   to follow the Container-Presenter pattern, but how?
const handleUpdate = useCallback(() => {
  hoge()
}, [])

return (
  <Body />
  <Footer>
    <Button onCliCk={handleUpdate} />
  <Footer />
)

ChatGPT's answer

In this situation, ChatGPT might suggest using useRef and useImperativeHandle, which works, but there is a better way, I think.

That approach often adds complicated code, and some engineers may not be familiar with them

My answer

set a useState in parent component to store function states, and assign functions themselves in initial useEffect in child component

▼ Parent component

const [{handleUpdate, ....}, setHandlers] = useState({
  handleUpdate: undefined,
  hoge: undefined,
  .........
})

return (
  <Body setHandlers={setHandlers} />
  <Footer>
    <Button onCliCk={handleUpdate} />
  <Footer />
)

▼ Child component <Body>

const onUpdate = useCallback(() => {
  update()
}, [])

useEffect(() => {
  setHandlers({
    handleUpdate: onUpdate,
    hoge: onHoge,
    .............
  })
},[])

It would be simpler than using useRef and useImperativeHandle.
This pattern is kind of Function Injection

Your answer

what do you think?

DEV Community: Kaziu

「先頭カラムが同じインデックス、それ1つ無駄ちゃう？」— 冗長インデックスの見つけ方と消し方

なぜ「単独 (import_id)」が冗長なのか

冗長インデックスは「あって困る」

どうやって機械的に見つけるか

1. MySQL 標準ビュー sys.schema_redundant_indexes（おすすめ・導入不要）

2. pt-duplicate-key-checker（Percona Toolkit / CLI）

3. sys.schema_unused_indexes（未使用インデックスの検出）

4. ORM 付属のツール（例：Rails の active_record_doctor）

【重要】消してはいけない冗長候補：外部キー（FK）の索引

安全な消し方

マイグレーション

適用前に「本当に消せるか」を実地で裏取り

Railsのstructure.sqlって何？ 何のため?

結論：DBの「完成形の設計図」

前提知識：マイグレーションとの関係

何のためにあるの？

なぜマイグレーション全実行は遅いのか

たとえ話

だから2つを使い分ける

補足：schema.rb と structure.sql

まとめ

SQL複数カラムの計算結果をインデックスにまとめる設計手法と、書き込みオーバーヘッドの限界

1. 複数カラムの計算結果をインデックスにまとめる2つの手法

アプローチA：式インデックス（Expression Index）を直接貼る

SQL (PostgreSQL)

Rails migration

アプローチB：生成列（Generated Column） ＋ 複合インデックス【おすすめ】

Rails (Migration)

2. 書き込み（INSERT / UPDATE）オーバーヘッドのレベル感

どのくらいの「データ量」で影響が大きくなる？

特に遅くなりやすい「ワーストケース」のパターン

Rails の `dependent: :destroy` が激重になる話を簡単な例で

何が起きるか

対策：重い子だけ「コールバック無し」で先に消す

ポイント3つ

用語メモ

SQLの自己結合（self-join）を一番簡単な例で

例：社員テーブル（社員も上司も“社員”）

ポイントは「別名（AS）」

LEFT JOIN にする理由

まとめ

「Blob」って何？ ブラウザでファイルをダウンロードする仕組み

Blob とは

手紙に例えると

コードの意味

補足：使い終わったURLは片付ける

まとめ

Ruby のブロックと yield を一番簡単な例で

ブロックとは

yield とは

2つの関係

実践編：yield で処理を「挟み込む」

なぜ便利か

もう一つの例：処理時間を測る

OCRで名刺を一括登録する機能をつくった話 — “1ページ複数名刺”という落とし穴

はじめに

全体の流れ

OCRは“2段構え”

設計で効いたポイント

いちばん悩んだ問題：「1ページに複数名刺」

OCRは“名刺単位”には分けてくれない

つまり「名刺ごとに切り分ける工程」を自前で挟む必要がある

学び：仕様側で“制約”できると一気にラクになる

重複データの扱い（名寄せ）

まとめ

(後日談)

Elastic search 基礎の基礎

Mysqlとの違い

データの形

検索クエリの書き方

基本形

完全一致で検索したいっす (term)

複数の条件をANDでつなぎたい (= bool + filter)

テキストを部分一致で検索したい（= match）

マッピングって何ですの？

mapping変更したら？

NestJSの基本アーキテクチャと実プロジェクトでの活用事例

目次

1. Module（モジュール）

なぜ「単独 `(import_id)`」が冗長なのか

1. MySQL 標準ビュー `sys.schema_redundant_indexes`（おすすめ・導入不要）

2. `pt-duplicate-key-checker`（Percona Toolkit / CLI）

3. `sys.schema_unused_indexes`（未使用インデックスの検出）

4. ORM 付属のツール（例：Rails の `active_record_doctor`）

Railsのstructure.sqlって何？何のため?

アプローチB：生成列（Generated Column）＋複合インデックス【おすすめ】

「Blob」って何？ブラウザでファイルをダウンロードする仕組み