Claude Code・Codex・Clineの個人ルールを1ファイルに集約した話
Claude Code、Codex、Cline（ClinePass）と、複数のAIコーディングエージェントを併用している。それぞれに「mise優先」「Beadsでタスク管理」といった自分用のルールを設定してきたが、ツールごとに書き方も置き場所も違い、1つ変えるたびに3箇所を直しに行く状態になっていた。 そこで今回は、個人ルールの正本を1ファイルにまとめ、各ツールの設定ファイルからはそれを参照するだ […]
MONTH
2026年9月
【ISUCON14】定期巡回からイベント駆動へ。Matcherを「必要なときに起こす」設計を試す
DB接続プールを50へ増やした後、次のテーマとしてMatcherに取り組んでいる。しかし、設定を変えてベンチの数字を見るだけでは、自分の中に理解が残っていない感覚があった。 そこで今回は、Matcherが「いつ動くのか」から考え直すことにした。一定間隔で待ち行列を確認する方式を、ライドの作成や椅子が空いたことをきっかけに動かす方式へ変えてみる。 今日のゴールは、イベントで起きるMatcherを実装 […]
【ISUCON14】近傍マッチングの次に詰まったのは、DBではなく接続待ちだった
近傍マッチングによってスコアは1,000台から5,000台まで伸びた。しかし、ベンチ結果には「椅子の実移動時間への不満99.3%」が残った。 近い椅子を割り当てているのに、なぜ移動時間の評価がほぼ全滅するのか。ライド完了数、椅子の稼働状況、APIとMySQLの時間を分けて調べた。 結論から言うと、SQL自体ではなく、SQLを実行する前のDB接続待ちがボトルネックだった。接続プールの上限を10から5 […]
【ISUCON14】ランダム配車を近傍マッチングへ——乗車地点に近い椅子を選ぶ
前回は、Matcherが1回の呼び出しで処理する待機ライドを1件から最大10件へ増やした。マッチング待ちへの不満は33.3%から5.6〜10.0%へ減り、複数件化が待機列の解消に効くことを確認できた。 しかし、改善後のスコアは1,611点と1,873点で、改善前の1,758点を安定して上回らなかった。お迎え時間への不満も85.0〜94.4%残っている。 待機ライドを早く割り当てても、遠くにいる椅子 […]
【ISUCON14】1件ずつ処理するMatcherを複数件対応にするとスコアは伸びるのか
前回は、高頻度APIの裏で実行されていたSQLへ複合インデックスを追加した。MySQLの総検査行数は1.5685億行から989万行へ減り、総実行時間も250秒から111秒へ短縮した。 しかし、単発のベンチマークスコアは2,225点から1,685点へ低下した。DBが軽くなっても、椅子とユーザーがマッチし、ライドが完了しなければスコアにはつながらない。 今回は次のボトルネック候補であるMatcherに […]
【ISUCON14】高頻度APIを支えるDB負荷を複合インデックスで93%削減した
前回のプロファイリング（alp × pt-query-digest）により、Nginxで観測したAPI合計処理時間の約97%が「通知系API（chair/notification, app/notification）」と「位置情報更新（chair/coordinate）」に集中していることが判明した。 これらのAPI内部では、インデックスのないSQLが高頻度に実行されていた。そこで今回は複合インデ […]