ask yoshi taka Blog

生成AIがコードを読む時代、私たちはどうコードを理解すべきか？：生きているアプリケーションと死んでいるソースコード

ask_yoshi_taka — Sun, 04 May 2025 12:06:41 GMT

あるプロダクトやアプリケーションを解析するとき、当然ソースコードを読みます。しかし、ソースコードだけでそのプロダクトが理解できるのでしょうか？ソースコードだけを読んでも、なぜこのアプリがエラーを出すのか、わからなかったことはありませんか？

ソースコードを使うメリット

改めて書くまでもないですが念のため

すべてが記載されている

ソースコードに基づいてアプリケーションが動く以上当然です

ソースがドキュメントだ。バグも完全に記述されている。 ――まつもとゆきひろ

『オブジェクト指向スクリプト言語Ruby』（⁠まつもとゆきひろ／石塚圭樹（著⁠）⁠、アスキー）p.563 https://gihyo.jp/dev/serial/01/agile/0004 より孫引き

解析手順が豊富

プログラミング言語が生まれたときから機械化や調査の対象であり、手法も豊富です。

e.g. HotSpotの分析

Bug Prediction at Google (google-engtools.blogspot.com) - What

生成AIが活用しやすい

コードなので構文としては似ており、要約や評価は生成AIが得意としているところです

ソースコード(だけ)を使うデメリット

ある程度生成AIで解決できますが、まだまだ不十分です。

量が多すぎて当たりをつけづらい

ソースコードは本にも例えられる通り分量が多いです。構造化されていればまだしも、構造化されてないならなおさら当たりをつけづらいですね。

抽象化を進め量を圧縮したならば、見たい部分を見るまでなんどもジャンプを求められることはよくあります。結局どこで設定しているのかわからない状態。

ある程度の規模を超えると生成AIでもコンテキスト量制限にかかります。

挙動が読みづらい

典型的な例として、依存関係の上書きがあります。Aという設定を複数の箇所で設定しているときの順位はコード見てもわからないでしょう。

さらに環境変数がソースコードの外で設定されていたらどうでしょう。

何をしたいのかが不明瞭

このソースコードによって最終的に何を解決するのかは不明瞭です。

結局readmeやドキュメント、誰かの解説頼りになります。

Howは豊富ですがWhy / So what?が不明瞭ということです。

コードだけ見てもコードの構造はわかりますがシステムの全体像を把握しづらいですね。

優先順位がつけづらい

よく使われるhotspotは確率であり、必ずしも重要とは限りません。普段触ってないファイルが重要かもしれません

作成したコード外の動きは教えてくれない

利用しているライブラリの動き、動作するOSの動きは教えてくれません。親切なときや不具合を修正したときは記録が残っていることがあります。

コードが使われているとは限らない

パスはあるが現実的には誰も呼んでないことも

見るべきは動いているアプリケーション

上記を解決…というより補完できるのが動的な解析です。

どのパスが重要かはAPIの呼び出し量から確認できます。どんな流れで動作しているかはAPMでわかります。パフォーマンスの問題検知も動かしたほうが速いです。コード見るよりログ見たほうが早いことも。

異常系として停止したときの動きが知りたいならカオスエンジニアリングが便利でしょう。正常系と異常系、両方通じることがそのシステムの専門家への近道です。

設計図だけ見てもよくわかりませんし、標本やDNAだけ見ても難しい。 (そこからだけで引き出すにはかなりの知識と観察力が必要です。)

実際の機械や生き物が動いているところを見れば一気に理解が進みます。旭川動物園のような行動展示です。

百聞は一見にしかずですね。体験しましょう

動的な解析と侵襲度

非侵襲的、つまり悪い影響を与えないほうが安全ではあります

メトリクス、トレーシング、ログの順に情報量と同時にリスク(侵襲度)が増えていきます。

特にログは慎重に扱う必要があります。

ログのリスクはとにかく情報量が多いこととのトレードオフです。ディスクがいっぱいになる、ネットワークがログデータで埋まる、コストが嵩む、各種I/Oを消費する、ローテーション時に重くなる、アプリケーションのリトライなどで一気にログが増加する、ログ収集のリトライで一気に消費が増えるといった事象が起こり得ます。ログが原因でアプリケーションが停止するということです。逆にメトリクスだとそうそう起きません。

ソースコードと動的な解析、どちらが先か

生成AIでコードを要約しつつ、動的な解析をおすすめします。

動的にやってみて、その部分のソースコードを読むのを繰り返す。ある程度慣れてきたら通しで読む。

というのも、詳しくないものの理解を深めるにはまずメンタルモデルを組み立てる必要があるからです。

とりあえずやってみる：メンタルモデルの組み立て

学習のモデルはいろいろありますが、実務向けのEAT(Experience(経験)、Awareness(気づき)、Theory(理論))にせよ、Accelerated形式にせよ、まずはある程度行動してみることです。

メンタルモデルを組み立てたあとはモデルを修正していきます。固着したメンタルモデル自体が学習の障害になり得るので、柔軟に壊す。

Book Summary: Accelerated Expertise (commoncog.com) - A summary of Accelerated Expertise, the best book on accelerating training programs we have today.

理解を進めるうえでの改善

目的を持つことで理解が深めやすくなります。

ソースコードも漫然と読まず、疑問を持ちながら読んだり、改善点を見つけながら読みましょう。ソースコードの改善はもちろん、ドキュメントの改善、テストの追加…

バリデーションなどは簡単なシミュレータを作ることで便利になります。

動的な理解もそうです。どこが遅いのか、重要なAPIはどれか、リスクが大きそうな部分はどこか…自問自答しましょう。

最後に

生成AIでだいぶ楽になったところはあっても、新規プロジェクトを除けば開発のうちほとんどがコード理解と言われますし、実際にそう感じます。

長い時間アプリに関わっていても理解が浅い人はだいたいObservabilityに興味がありません。理解が早くて深い人になるために、実際に動いているアプリケーションを見て触り観測しましょう。

2025年現在、AI開発支援が組織に与える現実的なインパクト

ask_yoshi_taka — Mon, 14 Apr 2025 17:57:30 GMT

日本でもすでに動きは起こっているので整理します。

開発人材・外注ニーズの変化と凋落

簡単なことはAIに任せれば良い、ジュニアレベルのエンジニアは不要になるとよく言われています。

ここで、どのような業務が任せられるかもう少し分解して具体的に考えてみましょう。

以下のような部分を委託することは以前からよく行われてきました。

機能拡張で、既存の似たような部分を真似して作る
簡単なものを明確に切り出して、タスクやチケットとして渡す
あまり重要ではないツールの作成をまるっとお任せする

これらはすべて、現在のAIが得意する領域であり、すでに実務で取り入れられ、高速で解決されています。

したがって、以下の採用は大きく抑制されます。

週2,3日程度の副業(開発)
オフショア
ジュニアエンジニア/インターン (よく言われていることですね)

社内ミニツールによる効率化

使い捨てのスクリプト、社内用の管理ツールが容易に作成できます。

開発者は定義的にも他者のために効率化をしますが、意外と自分たちの効率化ツールを作らないものです。(feature factoryの罠)

生成AIそのものだけではなく、生成AIで作ったミニツールにより、人手で行っていたものが効率化されます。そして人手で行っているようなものはあまり難度が高くない傾向にあることから、ニーズが変わります

リリースがすべて: より速く、より小さくのために投資できるか

AIにより開発できる機能の分量が増えれば増えるほど、リリースプロセス全体がボトルネックになります。

もしリリース頻度を増やせず、複数のものをまとめてリリースすることになれば災害が起こります。アイテムごとの障害率を考えれば、まとめることで障害確率は当然増えますし、組み合わさった新しい障害が生じることもあります。原因特定が難しくなり時間がかかりることもあれば、ロールバックが難しくもなります。

残念ながらほぼすべての日本企業はリリースが貧弱であり、基本中の基本であるロールバックすら期待される水準に達していないことが多いようです。

リリースをより速く、より頻度を増やし、より安全にするには以下のようものを手に入れる努力が必要です

開発面

デプロイとリリースの分離、フラグによるコントロール、セグメンテーションとステージドロールアウト、それらごとのモニタリング、自動ロールバック、GitHubフローに類するブランチモデル、CI/CDの高速化…

上記の概念を聞いたことがないなら、それだけ差がついているということでしょう。これらを導入するには、工数も時間も技術力も優先順位変更も必要です。

一方、VercelやCloudflareを基盤としているごく最近のスタートアップなら、基盤に組み込まれているので容易でしょう。

QA面

E2E含めた自動テストの拡張が必須です。外部の会社にQA作業を委託している企業が多いようですが、手動テストでは間に合わなくなるでしょう。

開発関係以外の側面

顧客へのリリースとコミュニケーションプロセス改善、文面作成プロセスの効率化、開発以外の部分の単純化、慣性の打破、なにより意思

リリース改善はプロセス改善であり、人間に関わる難しい問題です。ここで実力に差が生まれます。

準開発者への支援

組織の中には、開発者ほどではなくとも時折プログラミングがタスクになる人がいます。

コーポレートIT/情報システム
Webマーケティング (タグやMAなど)
技術サポート

このような人たちはプログラミングが専門というわけではないですが素養がある傾向にあります。そして社内受託に近く、極小の人数で評価されないわりに多くの要求に苦しんでいます。

こんなときAI支援によりプログラムやツールをサクサク作れれば効率化が見込めます。開発とその他の狭間でボールが落ちがちなので支援できると良いですね。

最後に

個人がAIを使うのは簡単ですが、組織的な変化によって初めて大きな成果が生まれます。気づいて動きましょう

言語モデル/AIによるITエンジニアリング論点

ask_yoshi_taka — Sat, 15 Apr 2023 08:53:31 GMT

AIによってITエンジニアの業務がどのように変わるのでしょうか。「仕事がなくなる！単価が一気に下がる！」といった意見もありますが、裏付けがやや大雑把な印象です。もう少し具体的な影響を短期、中期、長期で検討してみます。

＊プロンプトインジェクション含め、セキュリティ関係は除いて考えます。セキュリティだけでかなりの分量になるため。

短期目線

採用：単純なコーディング、技術試験は不要に

まず、AIを使えば問題をすぐ解ける以上、試験として成り立ってないため避けるべきです。

そして、そもそも機械のほうが得意なことを測定する意味がなくなりました。採石場から石材を運ぶ人員を採用するために、個人の腕力や脚力を測定するようなもの。今必要なのは大型ダンプを扱う技能です。

＊AI以前に選考方式としては効果もエビデンスも弱く無意味という指摘もあります。

乗り換えられるようにする

AIを使ったサービスが大量に生まれ始めました。オープンソースのツールも多数あります。自社で基盤を作成することもあるでしょう。

今は1ヶ月単位で進歩があるほど進化が激しい状態です。何を使うにせよ、乗り換え可能なのが重要です。すぐ捨てられるようにしましょう。手のひらを返す速度で勝ちましょう

中期目線

可読性のあるコードは不要になるのでは

毎回AIがコードを生成し、AIがドキュメントを書き、AIがコードの要点と影響範囲、変更点を抽出するなら、ソースコードに人間が介在する余地がありません。さよならリーダブルコード…

保守性、再利用性も不要になるのでは

毎回ソースコードを生成すれば保守性や再利用性も不要です。

コードのリファクタリングもいらない

可読性や保守性の観点では不要に

プログラミング言語選択の基準が変わる

可読性や書きやすさは考慮不要となりそうです。一方、実績が豊富と有利です。過去データが大量に溜まっているため。

新しいプログラミング言語は不要になるか

要求がなければ無理に新しい言語を作る動機はなくなります。新しい言語には当然過去コードが存在しないのでAIが使えなくなります。

一方、新しい時代、AIに最適化した、AIネイティブの言語が出てきてもおかしくありません。学習用コードもある程度の量が生まれれば十分です。

(Web)フレームワークは不要になるか

Webフレームワークを織り込んだ学習モデルが前提になることから、しばらくは必須でしょう。

Webフレームワークの目的である開発効率周りをほぼAIで達成できるとすると不要になりかねません。

パフォーマンスのオートチューニングが可能に

すでにプロンプトをもとに簡単なタスク分解、タスク実行までできる状態です。

目標値を指定すれば、自動的に負荷試験環境を作成し、負荷試験実行、評価、変更のフィードバックサイクルを回すまでが視野に入ります。

RDBの設定レベルでは数年前から存在するのですが(資料を参照)、コーディングレベル、アプリケーションレベルで可能になります。

形式手法による一部機能のバグゼロ達成

TLA+やAlloyといった形式手法は著名事例を除きほぼ開発に使われていませんが、AIが「仕様」を書くようになれば、一気に標準になる可能性があります。それにより形式手法を適用しやすい部分に関して、欠陥がないことを証明できるようになります。

品質の向上(事前欠陥検出)

UTのテストケースがテスト技法にそってないことがよくありますが、AIが書いたりレビューすることでケース自体の品質向上が期待できます。

テストのメンテナンスコストも話題になりますが、AIが生成すればメンテナンスコストを考えなくてすむため、大量のテストケースを実行し続けることが可能です。

Mutation TestやProperty-based testingといったあまり使われてない手法も容易に利用できそうです。

パフォーマンスと同様、これもフィードバックループによるオートチューニングが期待できます。

オートチューニングのための実験できる環境が必要

オートチューニングの話が何回か出てきました。本番ワークロードをもとにフィードバックループを回すためには、本番環境で安全に実験できる仕組みが不可欠です。

カナリアやリリースコントロールが必須になるでしょう。
＊実際はSaaSビジネスなら現時点で必須です。

ローカル開発環境は必要か

AIを使うにはサーバと通信する必要があります。光の速度が有限である以上、ローカル環境からサーバに毎回通信すると時間がかかりストレスが溜まります。

GitHub Codespacesのような、リモート開発による脱ローカル環境が浸透しつつありますが、AIの面からも背中を押す可能性があります。

いわゆる開発のしやすさはいらなくなるか

機械が読めれば良いとすると、Developer Experienceは不要になるかもしれません。LLM Experience(仮)を向上させる必要があります。

AIさんがスムーズに開発できるよう、いろいろしてあげるイメージです。

IaC(Infrastructure as Code)は必要なのか

インフラをコードにするメリットはプロンプトで代用できます。プロンプトを通して指示すれば十分になりそうです。

IaCの仕組み自体は残るかもしれませんが、人間がなにかする必要はなくなりそうです。

CI/CDはさらに重要になりそう

フィードバックループを回すための基盤です。テレメトリや各種データを集約した、AIが使うプラットフォームとなりそうです。

(データ分析での)SQLの重要性が減る

SQLで数値を問い合わせるより、プロンプトからAIに説明してもらったほうが的確でしょう。さようならHaving句。

より少人数の開発に。フルスタック化が進む

今までのシステム開発の流れを鑑みると、生産性が上がるにつれ少人数化、多能工化が進んできました。今が1チームでPdM:エンジニアが1:4から1:10ぐらいだとすると、1:3ぐらいになるかもしれません。

EM(Engineering Manager)のポジションが減る

組織の中でエンジニアの割合が高いことから、EMが生まれてきた面があると思います。エンジニアの割合が減少すればEMのポジションが減りそうです。

組織内での分散化が進む

重複開発を避け、共通部分を作成しリソース最適化として効率化するか、重複開発を許容してでも開発の依存関係をなくしフロー最適化するか。

永遠のジレンマです。

生産性が高まるに連れ、リソースよりフローを重視し、分散化に天秤が傾くでしょう。スピードのほうが大事になります。

社内プラットフォームの価値が低下するか？

重複開発大いに結構とすると、あえてプラットフォームを保有する価値が減ります。一方、プラットフォームも爆速かつ低コストで作れるようになるとすれば、価値は変わらないとも考えられます。

日本のレガシーIT企業が壊滅する

日本では古い技術、古いアプリケーションを大事に長く使う傾向があります。特にIT企業であっても創業から10年20年経つとそうなります。

今まではそれでも問題ありませんでした。世界中の攻撃者は日本語が読めず、日本をあえて狙う組織はアジア拠点がほとんどでした。

AIにより日本語の壁がなくなり、今まで以上に攻撃が低コストになり、無差別で攻撃されるようになると、レガシープロダクトがすべて乗っ取られ、既存IT企業が壊滅する可能性があります。日本は犯罪者の狩場になりそうです。

＊セキュリティの話ですが日本特有と思われるので書いておきます。

長期目線

むしろソースコードは不要で機械語でよいのでは？

これは飛躍しすぎですね。AIといってもソースコードのオートコンプリートなので。とはいえ誰かが学習モデルを作れば可能かもしれません

タイピング力は必要か

いよいよConversational Programmingが主流になるということで、画面の前で話すだけでプログラムが作成できるようになります。スマホでもOK。

キーボードといえばHHKBやREALFORCEではなくYAMAHAの話が主流になりそうです（？）

ITエンジニアとAI、どちらが勝つか

もちろん勝者は資本家です。歴史的にもよくあることでした。ホワイトカラーが壊滅するとなると、農家も勝つかもしれません。コモディティ強い。現物持ちましょう。大混乱に備え食料も備蓄しておきましょう

さいごに

IT開発関係としては10年に一度の激動の時代になりました。特に今回の波は、今までの波を乗り越えてきたBigTechも終わりになりえる時代だと思います。2023年4月現在、AIの進化が速いので月1でよいのでLLM関係の情報を追いたいですね。

AIがサクサク動くコードベースにしよう

ask_yoshi_taka — Mon, 02 Jun 2025 01:24:09 GMT

コードベースの状態によってはAIを使っても生産性が上がりにくいことがあります。どのようなコードベースだとAIが力を発揮しやすいでしょうか。以下を参考にしてみてください。

コードは短く

コードが短いほうがコンテキストに収まりやすいです

ファイルを責務ごとに分割し、凝集度を高くする

必要な情報がコンテキストに収まりやすくなります。影響箇所が少ないほうがコンテキスト読み出しが不要になり安定します。

特にAIエージェントの場合、最低限のコンテキストだけを読む事が多いので大事です。無関係な読み出しで時間をつかったり迷走したりするのは避けたいところ

不要な設定やメッセージ用テキストは別ファイルに分離する

普段は読まなくてすむのでコンテキストが節約できます。

コメントは無駄なく丁寧に

コメントがあるほうがAIが理解しやすくなります。特にWhyはコードベースからは読み取りづらいのでWhyを書きましょう

かといって見ればわかることはコンテキストの無駄なので避けましょう

変数名は丁寧に

変数名が適切ならAIが理解しやすくなります。

ディレクトリ構造に秩序を

どこに何があるか、時間をかけて探さなくて済むようにしましょう

主流のライブラリ/ツール等を使う

主流のほうが学習サンプルが多いため精度が高くなります

ドキュメントがしっかりしたライブラリ/ツールを使う

ドキュメントが細かいほうが読ませたときに精度が高くなります

テストを厚めに書く

テストが多いほうが修正ミスを捉えやすくなりますまた、テストから仕様がわかるためスムーズに理解できるようになります。

開発ドキュメントを書く

ドキュメントを読ませることでお互いの前提が揃い、同じ間違いが減ります。やり方や場所をまとめておきましょう。AIは記憶喪失が起きるので毎回教えてあげる必要があり、それが簡単なほうが便利です。

ビルドやテスト時間は短く

イテレーション速度が上がり、単位時間あたりのアウトプットが増えます。 AIの思考や記述時間よりこちらがネックになることがあります。

これらの部分もAIで高速化しましょう

診断/デバッグ方法を準備しておく

複雑な不具合はデバッグログや機能のon/offなどで診断できるようにしましょう。AIエージェントが実行できるぐらい平易だとよいですね

このような部分もAIで作りましょう

さいごに

整理整頓されたコードベースとそうでないコードベースでは、AIが出せる生産性に差が生まれます。

AIの生産性を上げるために、AIでコードベースを洗練させましょう。

CTOに役立つ！AWS請求からアーキテクチャを読み、コストを削減する技術。PDF編

ask_yoshi_taka — Sun, 30 Apr 2023 07:34:40 GMT

とにかくAWSのアーキテクチャやコストを今すぐ把握しないといけない！ということはたまにあります。知っている人の話を聞くことが最も重要なことの一つですが、文書からわかることも多いでしょう。

この記事では請求書のPDFという、あまり利用されないが強力なツールから読み解く方法を解説します。

手っ取り早く概況を掴みたい新任CTOや、M&Aなんて言われて困っているCTO、EM、Staff+ Engineerにおすすめです。

請求書PDFが読めるようになるメリット

ある程度アーテクチャがわかる

構成図やドキュメントは更新されていなかったり、存在しないことすらあります。

請求書に乗るキャッシュフローは事実。逆引きして読み解くスキルさえあれば、構成図より正確です。

「利益は意見、キャッシュは事実」に近いですね。

同じ条件で比較して、コスト削減の余地がつかめる

どのアカウントも請求書は同一条件で提出されます。決算書の開示に近いですね。管理会計は別の仕組みにしましょう。

DDやPMIにも効果的

買収(検討)時のDD(Due Diligence)ではビジネス部分が最優先。IT DDとして情報システム周りの検討はありえますが、プロダクト開発運用部分の優先順位は非常に低く、短い時間や少ない機会のなか、資料をもらうことすら困難です。

PDF一つで概略がわかるようになれば、改善の余地が探れ、シナジーが予測できるようになります。何より自社より水準が低い場合、PMIの覚悟ができます。

請求書からわかること

PDFだけでも思ったよりたくさんのことがわかります

Savings Planの利用状況 (コスト削減の余地)
AWS契約の状況
開発/本番でAWSアカウントを分離しているかどうか
プロダクトやサービスごとにアカウントが分離できているか
同一のorganizationに入れているか
どのAWSサービスを利用しているか
大まかなアーキテクチャ
セキュリティの成熟度
おおよその技術力

請求書(invoice)であり、Billing(明細)やCost Explorerは除きます。Billingが確認できると解像度が一気に上がり、最適な提案が可能になります。Cost Explorerを使えるとamortizationも見えるので理想です。

Amazon Chime

音声/ビデオ通話関係の処理がある可能性があります。電気通信事業法を含め、業界関係の法律やガイドラインを確認する必要があります

Amazon Connect

支払会社の関係で領収書のPDFは別です。

電話関係の処理がある可能性があります。業界関係の法律やガイドラインを確認する必要があります。特にアウトバウンドに注意。

Amplify

ある程度モダンなアーキテクチャが想定されます。ビルド料金が含まれるので確認。

API Gateway

API Gatewayでバランシングしてるかがわかります。バランシング候補の一つ。

合わせて確認

ELB / AppSync

AppStream

Windowsが潜んでいる可能性があります。テック企業で必要とされるようなエンジニアとはスキルセットが違うので難しいです。

AppSync

ある程度モダンなアーキテクチャが想定されます。

合わせて確認

ELB / API Gateway

CloudFront

CloudFrontの利用がないがS3はあるなら、CDNが使えていない可能性があります。

おおよそのアクセス数がわかります。ビジネスに比べて多すぎるようなら、botや攻撃、権限設定ミスの可能性があります

合わせて確認

CloudSearch

実質deprecatedなので移行を考える必要があります。

CloudTrail

2017年8月から開設したアカウントはデフォルトonです。料金が0ならそれより古く、またセキュリティ成熟度が低いでしょう。

CloudWatch

ログ(CloudWatch Logs)が一番多いことが想定されます。ビジネスやアクセス量次第です。3rd Partyのモニタリングツールを入れているなら、ポーリングによるMetricsの料金も嵩みます。

EC2利用アプリケーションではCloudWatch LogsではなくローカルのEBSに出力している可能性があります。NAT Gateway含め通信コストも確認。

Metricsのコストを、不要リージョンを封鎖する方法もあります。特に日本のみがターゲットのビジネスでは有効です。

Code*

CI/CDをAWSサービスに寄せているということです。自社との統合を検討しましょう。

Cognito

料金があるならMAUを逆算できます。連携なしログインだと5万MAUまで無料であり、toBだとほとんど費用がかかってないことも。

Config

あらゆるプラクティスでonにしろと指南されており、存在しないとセキュリティに不安が残ります。

料金がかかっていても下げる方法に気づいていないことが多いです。特にEC2のAuto Scalingと組み合わさると嵩みます。

高頻度デプロイやSecurity Hubが原因のことも。高頻度デプロイはむしろ望ましいことです。

合わせて確認

EC2

Cost Explorer

Cost Explorerを熱心に見ている人がいるということです。期待が持てます。

Data Pipeline

Data Pipelineはメンテナンスモードに入りました。移行の必要があります。

📝 Data Transfer

ビジネスに対してアウトバウンド通信量が多すぎないか、確認したいです。CDNが使えてないか、最悪攻撃の可能性があります。

合わせて確認

CloudFront

Database Migration Service

システム移行中かもしれません。一応通常時のレプリケーションにも使えますが、最適ではなさそうです。

Direct Connect

オンプレミスと接続している可能性があります。

DynamoDB

主なデータストアかどうかを金額で判断します

📝 EC2

EC2と聞くとEC2インスタンス周りのように見えますが、歴史的経緯から関係ないものも混ざっています。代表的なものがNAT GatewayとEBSです。Cost Explorerでは「EC2 その他」の扱いです。

やたら金額が大きいときは、アーキテクチャが古く、開発や組織がうまく回ってない可能性があります。一方、外部製品のセルフホスト版を運用していることもあります。

EC2があっても、RDSなどのデータストアが料金にないことがあります。RDBが自前運用の可能性があるのでマネージドサービスに移したいところです。

ある程度近代的なアーキテクチャだが金額が多いとすると、NAT GatewayのData Processed Byteが多い可能性があります。S3 / DynamoDBの利用状況によってはVPC Endpointを推奨。アプリの初期化や起動時に、ライブラリやイメージを取得していることもあります。特にFargateならイメージPullにコストがかかりがちです。

合わせて確認

RDS
ELB / API Gateway

ELB

ELBでバランシングしてるかがわかります。バランシング候補の一つ。

合わせて確認

ELB / AppSync

GuardDuty

存在するならある程度セキュリティ意識があることが読み取れます。

KMS

高すぎるときは、クレデンシャルを取得するKMSアクセスがアプリケーション内でキャッシュができてない可能性があります。

合わせて確認

Secrets Manager

📝 RDS

データストアとして一番可能性があります。存在しない場合、なんのマネージドサービスをデータストアとしているか、EC2で運用していないかを確認。

Secrets Manager

高すぎるときは、クレデンシャルを取得するSecrets Managerアクセスがアプリケーション内でキャッシュができてない可能性があります。

合わせて確認

KMS

Security Hub

Onということは最低限セキュリティに気を使っています。

Config代が嵩む原因のこともあります。

📝 S3

S3料金が多いと、一見データ量が原因のように見えますが、思ったよりAPIアクセスが多い可能性があります。特にLIST API。

S3の利用がないのにEC2は多い場合、静的ファイルをサーバから流す構成になっている可能性があります。

合わせて確認

CloudFront
Data Transfer

サポート

重要なプロダクトについて、本番環境でサポート契約がないと不安です。

WAF

セキュリティにある程度気を使っている可能性があります

Marketplace

支払会社の関係で領収書のPDFは別です。

古めのサービスを表しているかもしれませんし、3rd Party SaaSをAWS経由で購入したほうが楽という重い組織構造を表しているかもしれません。

PDFだけだとわからないことの例

RIの購入状況
外部ベンダーから付与される割引クーポンの規模
各種インスタンスの古さ

BillingやCost Explorerなら読み取れます。

結論

請求書PDFをざっと眺めるだけでも結構なことがわかりますね。

BillingとCost Explorerが追加できればほとんど明らかにできます。Billingから読み解く記事が続編になる予定です。

コスト削減のご相談は@ask_yoshi_takaまで。請求書PDFだけでも提案できます

AWS Config Advanced Query: SQL-Like Queries for Fast Cloud Insights

ask_yoshi_taka — Mon, 10 Feb 2025 13:36:17 GMT

Instantly analyze AWS resource configurations across accounts without complex scripts

Ever struggled to understand the actual configuration of your AWS resources?

IaC (Infrastructure as Code) is great, but every team abstracts things differently, making it hard to know what’s actually configured in AWS right now.

Need to quickly check configuration differences between dev and production?

Looking for a way to query AWS resources across multiple accounts without writing custom scripts?

There’s an underrated but powerful AWS-native tool that simplifies this: AWS Config Advanced Query.

With SQL-like queries, you can instantly pull resource configurations across your AWS accounts, ensuring compliance, debugging misconfigurations, and tracking infrastructure changes — all without complex scripts or manual checks.

In this guide, we’ll explore practical examples to help you leverage AWS Config Advanced Query for better cloud visibility and governance.

Find Lambda functions using a runtime older than Node.js 22

This query identifies all Lambda functions that are still using Node.js versions older than 22.

SELECT
  accountID,
  resourceId,
  configuration.runtime,
  configuration.lastModified,
  configuration.description
WHERE
  resourceType = 'AWS::Lambda::Function'
  AND configuration.runtime LIKE 'nodejs%'
  AND configuration.runtime < 'nodejs22.x'
  ORDER BY accountID

Don’t just detect EOL — celebrate the team that upgrades to the latest version the fastest! 🏎️ 🏁

Find instances configured with Aurora I/O-Optimized

This query lists all RDS instances that have the Aurora I/O-Optimized storage type enabled.

SELECT
    accountId,
    configuration.dBInstanceClass,
    configuration.engineVersion,
    resourceName
WHERE
    resourceType = 'AWS::RDS::DBInstance'
    AND configuration.storageType = 'aurora-iopt1'
ORDER BY
    accountId

I/O-Optimized comes with a 30% premium on Reserved Instance pricing. Fun fact: It also improves I/O speed!

Find tables using Provisioned Mode in DynamoDB

This query finds all DynamoDB tables using Provisioned Mode instead of On-Demand Mode.

SELECT
  resourceId,
  accountId,
  configuration.provisionedThroughput.readCapacityUnits,
  configuration.provisionedThroughput.writeCapacityUnits
WHERE
  resourceType = 'AWS::DynamoDB::Table'
  AND (
    configuration.provisionedThroughput.readCapacityUnits > 0
    OR configuration.provisionedThroughput.writeCapacityUnits > 0
  )

Unless you’re a DynamoDB expert, On-Demand mode is recommended over Provisioned mode.

Find CloudFront Distributions that do not support IPv6

This query identifies all CloudFront distributions that have IPv6 disabled.

SELECT
  accountId,
  configuration.aliasICPRecordals,
  configuration.distributionConfig.cacheBehaviors.items,
  configuration.distributionConfig.httpVersion,
WHERE
  resourceType = 'AWS::CloudFront::Distribution'
  AND configuration.distributionConfig.isIPV6Enabled = false
order by
  accountId

List all used Public IPs across accounts

This query extracts all used Public IP addresses across AWS accounts.

SELECT
  accountId,
  configuration.association.publicIp,
  configuration.interfaceType,
  availabilityZone,
  resourceId,
WHERE
  resourceType = 'AWS::EC2::NetworkInterface'
  AND configuration.association.publicIp > '0.0.0.0'
ORDER BY
  accountId,
  configuration.interfaceType

List all Elastic IPs (EIPs)

This query lists all allocated Elastic IPs (EIPs) across AWS accounts.

SELECT
  accountId,
  resourceName,
  awsRegion,
  resourceId,
  relationships,
WHERE
  resourceType='AWS::EC2::EIP'
ORDER BY
  accountId

AWS Config resource schema documentation is as follows:

Conclusion

AWS Config Advanced Query makes it easy to analyze resource configurations across accounts with SQL-like queries. No complex scripts or manual checks are needed — just write a query and get insights instantly.

Start using AWS Config Advanced Query today to improve cloud governance, detect misconfigurations, and simplify compliance monitoring!

AWSコストチェインの頻出パターンを抑え一気にコストを削減する

ask_yoshi_taka — Thu, 15 Aug 2024 14:26:47 GMT

AWSのコスト削減のために単一のサービスとにらめっこしていても効果が薄いでしょう。複数のサービスが連鎖するコスト構造を理解することで、チェインの起点から修正しレバレッジを効かせて削減することができます。

この記事では、起点側の修正で終点側の呼び出しを抑えるパターンを取り上げます。
＊終点側を高速化することで起点も高速化するパターンは除きます。

前提として、大まかなコスト内訳は確認済みとします。

S3 -> CloudTrail -> GuardDuty

S3オブジェクトへのリクエストはCloudTrailにデータイベントという形で記録され、それをGuardDutyが監査する、といったパターンの連鎖です。

クライアントから抑える

外部からのアクセスが嵩むならCloudFrontを挟む (CloudFrontはCloudTrailに記録されない。アクセスログはS3同様取得可能)
特にAPIからのS3呼び出しを控え、署名付きURLを活用する
オブジェクト一覧が必要ならS3 Inventoryを検討する
データ基盤宛の場合はテーブル形式からジョブのアクセス方式まで見直す

CloudTrailへの記録を抑える

CloudTrailで記録するデータイベントはフィルタリング可能です。AWSアカウントのワークロードと既存のセキュリティ施策、セキュリティ要件に応じて検討しましょう。除くことでこの経路でトレースができなくなりますが支障ないかどうかです。

AWS Config -> SecurityHub -> GuardDuty

ECS TasksやEC2が起動終了を繰り返すことでネットワークインターフェースなどにアクセスし、それがAWS Configに記録され、さらにSecurity Hubなどで検査される連鎖パターンです

Amazon Inspector起因のパターンもありました

初期トリガーから抑える

もしECS Taskの数や起動頻度を下げることができれば抑えることができます。率直に言って難しく、アーキテクチャレベルの検討が必要になることが多いでしょう。

AWS Configの記録量を抑える

この連鎖ではこちらが本命です。やり方は二種類あります

特定の記録種類を除外する
随時記録から日次記録に変更する全体変更のほか特定の記録種類だけに留めることも可能

ワークロードと既存のセキュリティ施策、セキュリティ要件を考慮して選択しましょう。

API Gateway + Lambda

上記は基本的な図であり、Lambdaの内部では別のチームのAPIを追加で呼び出し、DBでのデータ追加変更はデータ基盤に流れ、ログはログ基盤に保存されるといった連鎖が続くことになります。

API Gateway + Lambdaとしていますが、ELB+ECSなどでもおおよそ同じです。

クライアントで抑える

クライアントとバックエンドでの担当チームが異なるとやや難しいですが、起点だけあり一番効果が大きいです。

ポーリングを控える。頻度を下げる
不要なリクエストを排除する
クライアント側でキャッシュしてもらう
リトライを抑える（ためにエラーリクエストを減らすことも可能。一部はバックエンドで対応可能)

特に基幹系アプリケーションでポーリングさせるとユニットあたり原価が跳ね、粗利率に対して大きい影響がありえます

API Gateway周辺で抑える

ELBでもだいたい同じです

preflightリクエストのOptionsメソッドを固定レスポンスにする
preflightリクエストにAccess-Control-Max-Ageをつける
API Gatewayのキャッシュ機構を使う
Lambda Authorizerのttlキャッシュを使う
処理不要でレスポンスの中身を問わないなら固定レスポンス機能を使う
Lambdaを挟まず直接AWSサービスを呼び出すことも検討する
マッピングテンプレート(VTL)だけで処理が終わらないか検討する

Lambdaで抑える

DBアクセスを控える、クエリチューニングするのは当然として、

ローカルメモリキャッシュを使う方法があります。ただしインスタンスレベルなので別のインスタンスには効果がないほか、インスタンス終了時に消えてしまいます。

初期起動の段階で全キャッシュする方法もあります。起動時にDBから取得して保存する、sqlite/levelDBなどを内蔵しておくなど。キャッシュの宿命で同期の方法は必ず検討しましょう(stale cache)

当然多数のインスタンスがあればすべてのインスタンスで保持されるわけなので無駄があるといえばあります。DBから全取得の場合、thundering herdが起きやすいのでトラブル時のカスケード障害に注意が必要です。ほとんど存在しない項目の存在チェックを毎回しているならブルームフィルタも効果的です。

リモートキャッシュという形でキャッシュサーバを準備する話になると、アーキテクチャレベルで修正が必要になるため割愛します。

次はログの部分です。ロギングの実装方法次第ですが、JSONを自前で組み立てると無駄な処理時間を使うのでロガーに任せましょう。テンプレート機能が活用できます。

このときログを少しでも切り詰めるとログ代が抑えられます。スペースを限界まで削る、キー名に略語を使い、uuidは切り詰める(そもそもuuidの必要性を確認する)

本番アプリケーションでスタックトレースをそのまま出すのはやめましょう。開発やライブラリ制作者用であり、本番でのトラブルシューティングにはほぼ使えません。きちんとコード内でハンドリングして行動に結びつくメッセージを出力するとよいです。

ログと一口に言ってもいろいろあり、監査に使うような「アーカイブ」ならCloudWatch Logsに直接出力する必要はありません。(保存エラー時の処理を検討しつつ、) S3に直接保存するほうがコストが抑えられます。

最後に

CloudTrailやGuardDutyあたりは後段のため、これらだけが増えることはなく起因があるはずです。

構造と流れ、数字とその変化を理解すればアセスメントと提案までは容易です。コストを本気で削減したいならDeepDiveしましょう。

クラウドコスト半減&原価作り込みに関心がある方は歓迎します。

コスト削減したい人向け記事集

Breaking the Cost Chain: A Deep Dive into Reducing AWS Costs via Service Dependency Optimization

ask_yoshi_taka — Mon, 03 Feb 2025 13:37:26 GMT

💰 Struggling to optimize AWS costs despite tweaking individual services?

Many engineers fine-tune AWS resources — adjusting Lambda memory settings, optimizing EC2 instance types, or enabling S3 lifecycle policies — expecting noticeable cost savings. But despite these AWS cost optimization efforts, total AWS expenses often remain stubbornly high.

The real issue? Hidden cost chains. A single S3 request can trigger CloudTrail logging, which then feeds into GuardDuty analysis, creating a cascading effect that inflates your AWS bill.

This guide provides actionable AWS cost optimization strategies for DevOps engineers, SREs, and FinOps professionals looking to reduce AWS costs at scale by breaking down interdependent cost chains. We’ll explore high-impact optimizations that go beyond isolated fixes, helping you minimize AWS expenses without sacrificing performance or security.

🚀 Let’s dive into AWS cost chain optimization best practices and start cutting unnecessary cloud expenses today.

AWS Config -> SecurityHub -> GuardDuty

Frequent start/stop cycles of ECS tasks or EC2 instances generate network interface events. These events are recorded by AWS Config and subsequently analyzed by Security Hub, forming another cost chain that adds to your overall expenses.

When running off-the-shelf solutions like Databricks on AWS, frequent EC2 instance lifecycle events are common, further increasing the volume of logged network interface changes.

In some cases, Amazon Inspector may also contribute to this cost chain, depending on your security configurations.

💰 Quick Wins

Exclude specific log types.

Switch from continuous logging to daily logging.

Optimizing from the First Trigger: ECS Task Launches

Reducing the number or frequency of ECS Task launches can help lower costs. However, achieving this often requires architectural changes, which can be complex and challenging to implement.

Minimizing AWS Config Logs

The key optimization here is reducing AWS Config logging overhead. There are two main approaches:

Choose the best approach based on your workload, existing security measures, and security requirements to ensure an optimal balance between cost savings and compliance.

S3 -> CloudTrail -> GuardDuty

Requests to S3 objects are logged as data events in CloudTrail. These events are then audited by GuardDuty, creating a cost chain that compounds expenses across services.

Optimizing from the First Trigger: S3 Access

Implement CloudFront if external access is high. Unlike direct S3 requests, CloudFront requests are not logged in CloudTrail, but access logs can still be obtained.
Use signed URLs to minimize direct API calls to S3.
ConsiderS3 Inventoryfor frequent object listings as a cost-effective alternative.
Review table formats and access patterns in data pipelines to optimize performance.

In addition, executing a large number of Athena queries can generate a high volume of “StartQuery” events in CloudTrail.

Reducing CloudTrail Logging Overhead

CloudTrail allows you to filter data events, reducing unnecessary logging overhead. Evaluate the impact of excluding specific logs based on your workload, existing security measures, and compliance requirements.

However, be cautious — removing logs may affect traceability and limit forensic capabilities.

API Gateway + Lambda

The diagram above represents a basic architecture. However, within the Lambda function, additional API calls to other teams’ services may occur, database updates propagate to the data platform, and logs are stored in the logging infrastructure — forming an extended chain of dependencies.

Although this example uses API Gateway + Lambda, a similar architecture can be implemented with ELB + ECS with comparable results.

💰 Quick Wins

Optimize preflight requests: Use a fixed response for OPTIONS method requests.
Set Access-Control-Max-Age for preflight requests: Reduce the frequency of repeated CORS preflight requests.
Use fixed responses when processing is unnecessary: If the response content does not matter, use API Gateway’s fixed response feature.

Optimizing at the Client Side

Reducing unnecessary requests at the client side is one of the most impactful optimizations since it directly reduces the load on the backend. While this can be challenging when different teams manage the client and backend separately, addressing inefficiencies at the source yields the greatest cost savings.

Key Strategies:

Minimize polling: Reduce the frequency of polling or avoid it whenever possible.
Eliminate unnecessary requests: Prevent redundant API calls that do not add value.
Leverage client-side caching: Encourage caching to minimize duplicate requests.
Reduce retries: Decrease error-prone requests to limit automatic retries (some cases can be handled on the backend).

In enterprise applications, excessive polling can significantly increase per-unit costs, potentially impacting gross margins.

Optimizing Around API Gateway

The same optimizations generally apply to ELB as well. Reducing overhead at the API Gateway level can improve performance and lower costs.

Key Strategies:

Optimize preflight requests: Use a fixed response for OPTIONS method requests.
Set Access-Control-Max-Age for preflight requests: Reduce the frequency of repeated CORS preflight requests.
Leverage API Gateway caching: Store frequent responses to minimize redundant processing.
Enable TTL caching for Lambda Authorizer: Reduce the number of authorization calls.
Use fixed responses when processing is unnecessary: If the response content does not matter, use API Gateway’s fixed response feature.
Consider calling AWS services directly instead of using Lambda: Reduce unnecessary function invocations.
Evaluate whether processing can be handled with mapping templates (VTL) alone: Avoid Lambda where possible by utilizing API Gateway’s built-in processing capabilities.

Minimizing Overhead in Lambda

Optimizing Database Access and Caching

While optimizing queries and minimizing database access is fundamental, additional caching strategies can further reduce overhead.

Leverage local memory caching: This can improve performance, but it is instance-specific, meaning it does not persist across instances and is lost when the instance is terminated.
Preload data at startup: Fetch necessary data from the database at startup and store it locally, or embed a lightweight database like SQLite or LevelDB. However, caching inherently introduces stale cache risks, so synchronization strategies must be carefully considered.
Be mindful of redundancy: If multiple instances maintain separate caches, memory usage may become inefficient. Additionally, bulk retrieval from the database at startup can trigger a thundering herd problem, potentially leading to cascading failures.
Use Bloom filters for rare existence checks: If your system frequently checks for the existence of rarely used items, Bloom filters can be an effective solution.
Remote caching requires architectural changes: Using a dedicated cache server (e.g. Redis) involves architectural modifications and is beyond the scope of this discussion.

Optimizing Logging for Cost Efficiency

The way logging is implemented significantly impacts performance and cost.

Avoid unnecessary processing when structuring logs: Instead of manually constructing JSON logs, rely on logging libraries with built-in template functions to minimize overhead.
Reduce log size to lower costs: Optimize storage by eliminating unnecessary spaces, using abbreviations for key names, and truncating UUIDs (after verifying if full UUIDs are truly necessary).
Do not expose full stack traces in production: Stack traces are primarily useful for development and library maintainers but are rarely effective for production troubleshooting. Instead, ensure proper error handling and output actionable log messages that guide resolution steps.
Optimize long-term audit logs: If logs are intended for long-term retention and auditing, storing them directly in S3 instead of CloudWatch Logs can significantly cut costs. However, ensure proper handling for storage failures.

Final Thoughts

CloudTrail and GuardDuty operate downstream in the service chain, meaning their cost increases are always triggered by upstream events. Identifying the root cause is key to effective cost optimization.

By understanding the architecture, data flow, and numerical trends, conducting assessments and making recommendations becomes much easier. If you’re serious about cost reduction, it’s time to Deep Dive.

Practical AWS FinOps: Cost Management from Unit Economics to Optimization

ask_yoshi_taka — Fri, 10 Jul 2026 01:00:00 GMT

1. First Steps: Democratization

Democratize Cost Data

Ideally, tools like AWS Cost Explorer should be visible to all AWS users. There is no reason to hide this data. Without visibility, engineers lack the motivation to reduce costs and cannot determine priorities.

Leverage AWS Organizations

It is highly recommended to use AWS Organizations to gain cross-account visibility. Logging into each account individually to check costs is inefficient and painful.

IAM Permissions

Keep in mind that access control and IAM policies for these views require careful planning (e.g., saving custom views requires update permissions).

Key Features to Enable

Cost Explorer (and saved views)
Savings Plans / Reserved Instances (RI) dashboards
Cost Optimization Hub
Cost Anomaly Detection

2. Clarify Unit Economics

Tie Costs to Business Metrics

It is natural for AWS costs to increase as revenue or product usage grows. However, if you do nothing, you won’t know whether a cost spike is driven by business growth or pure inefficiency.

Define Your “Unit”

The right unit depends on your business model:

Brick-and-mortar / Retail Tech: Number of locations/stores.
B2C SaaS: Number of active users.
Developer Tools: Number of user accounts.

Align with FP&A

Collaborate closely with the Financial Planning & Analysis (FP&A) team to identify your core cost drivers. Discuss unit costs rather than just the total aggregate spend.

Isolate Controllable Metrics

Separate what the development team can control from what they cannot. Engineers cannot directly control total revenue, but they can easily optimize the cost per unit. Breaking down responsibility unlocks more actionable solutions.

Level Up Your Metrics

To mature your FinOps practice, break down costs beyond the product level into specific feature levels. This is relatively easier to achieve if you are using Serverless architectures.

Separate Dev vs. Prod Costs

Development environments are largely fixed costs proportional to the number of engineers. Production environments are variable costs proportional to customer volume. Your primary target for strict management should be Production costs.

3. Amortization & Showback

Centralized Discount Management

Upfront discounts from Savings Plans or Volume Discounts (PPA) are usually owned by a centralized team. However, you must accurately reflect these benefits to individual product teams.

Default to Amortized Costs

If you do not look at amortized data, individual product costs will appear to spike or drop erratically. Make it a habit to use Amortized Costs as the default view in AWS Cost Explorer.

Separate Cash Flow from Cost Control

Treat the cash flow of purchasing Savings Plans as a separate issue from daily cost optimization. This aligns with the principle of isolating controllable metrics—dev teams cannot control enterprise-level discount purchases.

4. Monthly / Quarterly Tasks

Prioritize Savings Plans (SP) over Reserved Instances (RI)

Savings Plans offer higher flexibility, reducing the risk of missed discounts or over-commitment while lowering management overhead.

When to Buy SP

Unless you have highly predictable architectures and a dedicated team member specializing in RI management, stick to Savings Plans.

Leverage Instance Savings Plans

Note that SageMaker, Lambda, and Fargate are covered by Compute SP, while Instance SP offers higher discounts for specific EC2 families. Also, utilize DB Savings Plans, which cover not only RDS but also OpenSearch and DynamoDB.

Strategic Over-commitment

Targeting a slight over-commitment can sometimes yield better ROI than under-committing.

Staggered Purchases

Divide your purchases into multiple cycles throughout the year to allow easier adjustments.

5. Daily Tasks

AWS Cost Anomaly Detection

This is a highly effective, free anomaly detection tool. Even though it has a 1-to-2-day delay from the actual event, catching alerts here is far better than realizing a spike on next month’s invoice.

Alert Setup

Set up one master alert for the AWS management team, and encourage individual product teams to set up their own.

Threshold Tuning

Fine-tuning the alert thresholds is essential to avoid alert fatigue.

6. Strategies for Cost Reduction

Understand the Bill Details

Analyze at the Resource Level

Use Cost Explorer’s hourly/resource granularity to analyze costs down to specific Lambda functions or CloudWatch Logs groups.

Look Beyond the Service Name

An “EC2” charge often includes NAT Gateway data transfer fees.
An “S3” charge might be driven by API request calls rather than actual data storage.
Sometimes, an abnormal spike in a service’s cost is caused by an external DDoS attack.

Verify Facts, Don’t Guess

Check the AWS Billing page and Cost Explorer to see exactly which AWS APIs are draining cash. Rely on hard data, not assumptions.

Grasp the Request Cost Structure

Visualize a Single Request

Map out a basic API request flow to see how much each component costs.

Include Hidden Fees

Factor in NAT Gateways, outbound data transfers, and cross-AZ communication fees. Add the high-cost items directly to your architecture diagrams.

Account for Third-Party Expenses

Don’t forget external APIs, partner integrations, and operational tooling. Third-party tracing and logging platforms (e.g., Datadog, New Relic) tend to be deceptively expensive.

The Power of Upstream Caching

Visualizing the data flow shows why reducing requests as close to the user as possible is so valuable. Edge or frontend caching is highly cost-effective.

Data flow is cash flow—imagine money leaking out with every step a request takes.

Bonus

These architecture maps are also incredibly useful for data security (e.g., tracking PII flow) and performance optimization.

Performance ≈ User Experience ≈ Cost

Align Cost with UX

“Cost cutting” alone often fails to motivate engineering teams. Instead, prioritize optimizations that simultaneously reduce latency and improve user experience. Lowering API latency or utilizing frontend caching reduces data transfer costs while making the app faster for users.

Focus on the Hot Paths

Unlike pure performance tuning, cost-driven optimization should focus strictly on the high-traffic, standard execution paths.

Bonus

You can also pitch this as a sustainability/decarbonization initiative.

Scalability and Reliability Perspectives

Waste Impacts Stability

Wasted resources can hinder autoscaling and lead to system failures. Like performance, frame cost optimization as a way to improve reliability to elevate its priority.

7. Execution: Framework for Optimization

Focus Rigorously on Production Apps

For a growing business, focus on reducing production environment costs that impact unit economics (the parts that scale with user growth). Dev environment costs are usually a small fraction of the budget and are driven by headcount. Spending too much time cutting dev costs is counterproductive.

Do the Hard Work

Avoid doing only the easy tasks that yield minor results. Be prepared to refactor application source code and modify core architectures for meaningful impact.

Optimize Upstream (The Frontend/Edge First)

If you optimize the upstream components and successfully reduce the number of requests sent downstream, you achieve massive leverage. This often eliminates the need to optimize downstream components altogether. Fix things closest to the user first.

Optimize Downstream (The Core Dependencies Next)

Conversely, fixing a bottleneck at the deepest layer of your dependencies (e.g., optimizing a heavy database query in a shared platform API) will aggregate benefits across all consumer services at once.

Start with Low-Hanging Fruit for Momentum

Tackle easy, low-risk items first to build execution momentum. However, audit your backlog regularly to ensure you aren’t only doing the easy tasks.

Clean Up the Invisible Areas

When costs are visualized, people tend to only optimize what they can see on the graph. If you want to reduce Total Cost of Ownership (TCO), dig into the obscure, unallocated shared costs that are hard to attribute. Significant breakthroughs come from tackling these complex, ambiguous areas.

8. Budget Management & Continuous Forecasting

Avoid Delayed Reporting

Traditional monthly tracking means looking at reports days or weeks after the billing cycle closes. While good for high-level trend analysis, it is too slow for incident response; by the time you notice a spike, the incident has already passed. Finding out after the fact is useless.

Real-Time Detection

Ensure you can detect anomalies the moment they occur using tools like AWS Cost Anomaly Detection.

Shorten the Review Cycle

During intensive cost-reduction phases, leverage AWS Cost Forecasting features. Review variances between your budgeted baseline and projected spend on a weekly or daily cycle rather than waiting for the month-end bill.

B2Bアプリでプロダクトマネージャーが漏らしがちな機能

ask_yoshi_taka — Sun, 19 Jan 2025 06:33:02 GMT

B2BアプリケーションやSaaSには典型的なパターンがあり、あえて洞察しなくても実装が確定する機能は多くあります。

＊優先度は洞察で決まります

この記事では、いくつか見てきた中で、実装までなかなか至らずユーザーにフラストレーションが溜まりがちなものを主に述べてきます。

なおエンジニア向けプロダクトは顧客層が特殊なため除きます。

業務に不可欠系

業務は反復が基本です。

似たものを何度も入力をする手間を避けるには繰り返し入力機能やテンプレート機能、以前の作業をもとにしたコピー機能で効率化できます

人は間違えるもの。なにかデータを追加する機能があれば、それに対する修正機能と削除機能は必ず発生します。CRUD(create, read, update, and delete)とはよく言ったものです。とにかく戻せるように(undo)。あえて実装しないなら問い合わせフローを考えておきましょう。

全文検索機能

業務は反復が基本です。過去の履歴をもとに、真似して仕事をしたいもの。

そのためには検索が必要です。項目ごとの検索も便利ですが、全項目を一括して検索できる全文検索が一つのゴールです。

考慮点として全文検索は運用コストとエンジニア工数がかかることが多いことが挙げられます。より柔軟な検索ほどコストと工数が上がる傾向にあります。

漏れがちな背景

toBアプリケーションはオペレーションに密接するためオペレーション業務経験がないと難しいのかもしれません。

管理系機能

enterprise readyという意味でも大事です

アカウント関係

例えばプロダクトの新規導入時や異動の季節には少なくとも数十人単位で登録が必要になり、一括登録機能がないと手が回りません。修正/削除も同様です。修正のためには一括出力機能も必要です。

ビジネスでは複数の部署やチームに所属することがあります。しかし素朴な実装だと一人は一つの場所にしか所属しない制約となっています。ここで問題なのが、この制約を外すにはアプリケーションおよびデータベースに大幅な改修が発生することです。場合によってはサービスのメンテナンス時間が必要になります。一番最初から対応していれば…となりますが経験がないとなかなか難しい。

監査ログ

ここに大体書いてありますが補足すると

なんらかの不正やセキュリティ侵害を調査する際に行動ログは必須です。いつどこで誰がなにをしたのかトレースできる必要があります。

速やかに特定できるよう、このログだけで完結できるほど特定しやすいことやフィルターできるとよいですね。

人が思うより(小さい)不正は一般的です。わかりやすいのは営業機密の窃盗でしょうか。

仮に機能が存在しないと、膨大なエンジニア工数を使って精度が低いログを毎回急ぎの差し込みで提供する羽目になります。提供方法もファイルなら経路を考える必要があります。

監査ログ機能は運用コストとエンジニア工数が大きくかかります。また、複数プロダクトではインターフェイスを揃える部分が難関です。上記の通り急ぎの需要が発生することがあり、ユーザーから見てプロダクトごとにバラバラでは不都合でしょう。

漏れがちな背景

PdMは日常的に他社サービスを探求していると思いますが、どうしてもtoCが多くなります。個人ではエンタープライズアプリケーションを触る機会はまずないでしょう。仮に経験があったとしても管理機能の操作権限がなくその部分は触ったことがないのではないでしょうか。

社内で利用しているサービスの権限を一時的にもらって操作してみるのが一番ですね

本番でのテスト系機能

ユーザーには直接影響ありませんが…

リリース後や不具合発生時に、本番で検証できるアカウントがあると便利です。

問題は、この本番でのテストユーザーがトラッキングやKPIといった部分に影響してしまうことです。各所共通のテストアカウントフラグと除外設定を準備したいところ。

KPIが歪むほか、テストユーザーの動作によるトラブルが起き得ます。

この件に関してはエンジニアからも提案すべきですがなかなか手が回らずボールが落ちがちです。

デモ機能

ユーザーには直接影響ありませんが…

B2Bだと見込み顧客にセールスまたはマーケティングによるデモを挟むことが多いでしょう。このデモをどのアカウントで行うのでしょうか。本番環境でしょうか？

アカウント準備、シナリオとそのデータ準備、保守が必要です。デモ環境に対するリリースはどのようにすべきでしょうか。開発中の機能をチラ見せしたいこともあれば、デモで使う環境はデモ中は安定していてほしいという。

セールスエンジニアを採用していればある程度設定を任せられますが、存在しないならセールス等が直接スムーズに設定できるようにする必要があります。

その他

アプリケーションのパフォーマンス(速度)改善やサイト解析ツール系の導入、サポート業務に資するトラブルシューティング系機能も現実的には漏れがちです

最後に

海外のSaaSアプリケーションをいろいろ触ってみるのがおすすめです。オンボーディングから差が出ています。管理系機能実装をまるっとお任せできるようなSaaSもあるので触ってみたり、機能一覧だけでも眺めてみたり、導入したりするのも一案です。

外資系企業なら会社のお金で寄付を増やせるかもしれません。Benevityを確認しよう。

ask_yoshi_taka — Fri, 31 Jul 2026 03:00:00 GMT

外資系企業では、会社が寄付を上乗せしてくれる福利厚生として Benevity を導入していることがあります。利用すると、自分が1万円寄付した場合に会社がさらに1万円寄付する（マッチング寄付）など、自己負担を増やさず寄付額を大きくできます。

できること

企業負担の寄付（Giving Credits）
マッチング寄付（社員の寄付に会社が上乗せ）
ボランティア時間の記録・マッチング

寄付できる対象

多数の国内の団体に対して寄付が可能です。もちろん国外も含まれます。

日本赤十字や国境なき医師団、ユニセフといった著名どころはもちろん、災害支援として、日本および各国の緊急募金にも寄付可能です。

自然/科学系ならWWF Japanや京都大学iPS細胞研究財団など。

テック系も揃っています。たとえば、

Apache Software Foundation
Python Software Foundation
Unicode Consortium
日本Rubyの会
NPO法人Waffle

Apache Software Foundation (apache.org)

Unicode Consortium (unicode.org)

日本Rubyの会 (ruby-no-kai.org)

その他地元の団体なども多くあります。

寄付可能団体リスト

おおよそ日本では認定NPOや公益財団法人などが多い印象です。

Benevityはtechsoupなどの非営利団体データベースを利用して寄付先を管理しており、実際に表示される団体は各企業のポリシーによって異なります。

Benevityを経由して寄付したい組織
   │
Benevity
   │
TechSoup
   │
各国の非営利団体データ

団体名の検索方法

データベースが正規化されていないため検索のやり方によって精度が異なります。英語または日本語で検索してみましょう。英名がない場合はローマ字のこともあります。

マッチング寄付を諦める前に

すでに継続的に寄附している団体がある場合、切り替えるのは若干手間がかかります。また、benevityは日本の寄付金控除が利用できないこともあります。

その場合、領収書をアップロードすることでマッチングさせることができます。 request a matching画面からアップロードすると、OCRにより団体名金額日付などを入力されます。ただ、日本語の領収書がほとんどでしょうから、自分の名前が日英表記として差異が出てしまいます。そこはコメント欄などで補足しましょう。

どれくらい遡って領収書が提示できるかは組織の設定次第です。管理者に確認ください

さいごに

benevityを使い寄付を無理なく続けましょう

イギリスの街で見かけたイギリス英語

ask_yoshi_taka — Thu, 12 Feb 2026 00:00:00 GMT

綴り差(centreなど)や単語差は有名なのでそれ以外で。地域差はあると思いますが大きめの街の傾向ということで。イギリス英語だけではなくイギリスの英語も含む。

店でのHow are you -> Thank you

チェーンなどで店員がHow are you?と聞いているように見えます

といっても特に意味はなく、(Good.というかgというかgすら消えて) Thank youと返すことが多いです

せいぜいこんにちは、どうもぐらいの用途です。やはり会話はシチュエーションがあってそこでの定型応答が大事ですね

Please

アメリカではあまりpleaseが出てくる印象はなく、特定のフレーズとセットで使うことが多い認識です(コロケーション)

イギリスでは指示の文章に非常によく出てきます。pleaseだらけです。

Point

![help point](../../assets/british-english.jpg)

pointに集約

設備の場所をpointと呼ぶことが多いです

電話する場所: call point
消火器などの場所: fire point
待ち合わせ場所: meeting point
支払場所: payment point
非常用インターフォン: help point

まだまだ無限に出てきます

アメリカだと設備名を書くことが多い印象です。それこそ「消火器」など。場所をポイントと呼ぶのはなにか重要なイベントがあるような場所ぐらいかなと思います

bun

アメリカの店で見かけるbunといえば、小さくて丸いパン状の生地のもの。◯◯ bunとすることで可能性が広がります。具材、用途、属性…。結果として具が入ってたり載せたりすることも多くなります。

![british bun](../../assets/british-english-bun.svg)

これはbun.sh

イギリスでは焼いた甘い小型の菓子パン／ティーパンとして定着しています。小型なのは同じですがおやつ前提の印象です。そのため、英国話者にとってbun.shのマスコットに違和感を覚える人が少なくなさそうです。

collection / collect

紙チケットを受け取るならcollect、駅でもチケットはcollectとcollectが大量に出てきます。受け取る、発券する、引き換えるならcollect。アメリカならpickupやprintでしょう。

call at

電車などで駅に停車するならcall at。アメリカならstop atあたりが多いかと

reduce

saleでもdiscountでもoffでもなくreduced。とにかくreduce

bylaws

イギリスではbylaws表記がちょくちょく出てきます。条例含め、地方自治体・公共機関が定めるローカル規則ですね。一方アメリカでは bylaws は主に会社や団体の内部規則を意味するため、街中で掲示されていると違和感を覚えやすい語です。

service

特に公共インフラでなんでもservice。行為全体を指す

obstruct / obstruction

特に公共インフラで、具体的より抽象的に伝える

店名につくfone

phoneのこと。つまり携帯電話関係の店。発音と綴りの一致化で親しみやすくした？

two courseなど

2品構成のコースであり、前菜かデザート + メイン。コースが2個ではない。ドリンクが含まれることもある

bill / check

店ならイギリスはbill。アメリカはcheck

-bury / -bery / berry / burry / -borough / -brough / -burgh など

地名にやたら出てきます。防御された場所・城塞・囲われた集落を指し、ドイツ語の -burg（ブルク）と同じ。-tonもそうですが同じようなパターンの地名が大量にあります。(聖人名/人名/都市名)+地形語

地名のRussell

ありふれた苗字でもあり、有力貴族の苗字でもあり、著名人も多く排出している。なのでRussellがついた地名が増殖する

Julian map と packed table による高速な civil_from_days

ask_yoshi_taka — Fri, 28 Aug 2026 10:00:00 GMT

Unix epochからの通算日を年月日へ戻す処理は、一般に civil_from_days と呼ばれます。前の記事で扱った days_from_civil の逆変換です。

civil date -- days_from_civil --> epoch day
civil date <-- civil_from_days --- epoch day

この記事では出力年を 1..9999 に限定し、Ben JoffeのJulian mapによる年復元と、366要素のpacked month/day tableを組み合わせます。Bunではさらに、二つの定数除算を上方丸めしたbinary64逆数との乗算へ置き換えます。

Apple Silicon上の今回の測定では、実行時間が通常のHoward Hinnant実装の約13%（Bun）、26%（Rust）、30%（C）になりました。削減率ではそれぞれ約87%、74%、70%です。

前提

入力範囲は、暦年 1..9999 に対応する次のUnix epoch dayです。

-719162 <= epochDay <= 2932896

両端はそれぞれ 0001-01-01 と 9999-12-31 です。

TypeScript実装

Bun向けのホットパスは、年月日を一つの整数へpackして返します。

packed = year * 512 + month * 32 + day

月は 1..12、日は 1..31 なので、下位9 bitへ月日を格納できます。

const INV_146097 = (1 / 146_097) * (1 + Number.EPSILON);
const INV_1461 = (1 / 1_461) * (1 + Number.EPSILON);

const MONTH_DAY = new Uint16Array(366);

for (let dayOfMarchYear = 0; dayOfMarchYear <= 365; dayOfMarchYear++) {
  const n = 2_141 * dayOfMarchYear + 197_913;
  const marchMonth = n >>> 16;
  const day = Math.floor((n & 65_535) / 2_141) + 1;
  const janOrFeb = dayOfMarchYear >= 306;
  const month = janOrFeb ? marchMonth - 12 : marchMonth;

  MONTH_DAY[dayOfMarchYear] =
    (Number(janOrFeb) << 9) | (month << 5) | day;
}

/**
 * Returns year * 512 + month * 32 + day.
 * Preconditions: -719162 <= epochDay <= 2932896.
 */
export function civilFromDaysPacked(epochDay: number): number {
  const q = ((epochDay << 2) + 2_877_875) | 0;
  const century = (q * INV_146097) | 0;
  const julian =
    (q + ((century - (century >> 2)) << 2)) | 0;
  const year = (julian * INV_1461) | 0;
  const remainder =
    (julian - Math.imul(year, 1_461)) | 0;

  return (
    (year << 9) + MONTH_DAY[remainder >>> 2]
  ) | 0;
}

通常のオブジェクトが必要なら、ホットループの外で展開できます。

export function unpackCivilDate(packed: number) {
  return {
    year: Math.floor(packed / 512),
    month: (packed >>> 5) & 15,
    day: packed & 31,
  };
}

civilFromDaysPacked 自体にオブジェクト生成を含めると、カレンダー計算より割り当てコストを測る比率が大きくなるため、ベンチマークではpackした整数を返しています。

Rust実装

Rustではtableをコンパイル時に生成できます。定数除算はそのまま記述し、最適化をコンパイラに任せます。

#[derive(Clone, Copy, Debug, Eq, PartialEq)]
pub struct CivilDate {
    pub year: i32,
    pub month: u32,
    pub day: u32,
}

const fn build_month_day_table() -> [u16; 366] {
    let mut table = [0u16; 366];
    let mut r = 0usize;

    while r <= 365 {
        let n = 2_141 * r as u32 + 197_913;
        let march_month = n >> 16;
        let day = (n & 65_535) / 2_141 + 1;
        let month = if r >= 306 {
            march_month - 12
        } else {
            march_month
        };

        let year_bump = u16::from(r >= 306);
        table[r] = (year_bump << 9) | ((month << 5) | day) as u16;
        r += 1;
    }

    table
}

const MONTH_DAY: [u16; 366] = build_month_day_table();

#[inline]
pub fn civil_from_days(epoch_day: i32) -> CivilDate {
    let q = 4 * (epoch_day + 719_468) as u32 + 3;
    let century = q / 146_097;
    let julian = q + century * 3 + (century & 3);
    let year = julian / 1_461;
    let day_of_march_year = julian % 1_461 / 4;
    let packed = MONTH_DAY[day_of_march_year as usize] as u32;

    CivilDate {
        year: (year + (packed >> 9)) as i32,
        month: (packed >> 5) & 15,
        day: packed & 31,
    }
}

C実装

Cでは次の初期化をプログラム開始時に一度実行します。本番用途では、生成結果を static const uint16_t[366] として埋め込めば初期化も不要です。

#include <stdint.h>

typedef struct {
    int32_t year;
    uint32_t month;
    uint32_t day;
} civil_date_t;

static uint16_t month_day[366];

static void init_month_day_table(void) {
    for (uint32_t r = 0; r <= 365; ++r) {
        const uint32_t n = 2141u * r + 197913u;
        const uint32_t march_month = n >> 16;
        const uint32_t day = (n & 65535u) / 2141u + 1u;
        const uint32_t month = r >= 306u
            ? march_month - 12u
            : march_month;

        month_day[r] = (uint16_t)(
            ((r >= 306u) << 9) | (month << 5) | day
        );
    }
}

static inline civil_date_t civil_from_days(int32_t epoch_day) {
    const uint32_t q = 4u * (uint32_t)(epoch_day + 719468) + 3u;
    const uint32_t century = q / 146097u;
    const uint32_t julian = q + century * 3u + (century & 3u);
    const uint32_t year = julian / 1461u;
    const uint32_t day_of_march_year = julian % 1461u / 4u;
    const uint32_t packed = month_day[day_of_march_year];

    return (civil_date_t) {
        (int32_t)(year + (packed >> 9)),
        (packed >> 5) & 15u,
        packed & 31u
    };
}

通常の `civil_from_days`

Howard Hinnantの基準実装をTypeScriptで書くと次のようになります。

function civilFromDaysHinnant(epochDay: number) {
  const z = epochDay + 719_468;
  const era = Math.floor(z / 146_097);
  const dayOfEra = z - era * 146_097;
  const yearOfEra = Math.floor(
    (dayOfEra -
      Math.floor(dayOfEra / 1_460) +
      Math.floor(dayOfEra / 36_524) -
      Math.floor(dayOfEra / 146_096)) /
      365,
  );
  const year = yearOfEra + era * 400;
  const dayOfYear =
    dayOfEra -
    (365 * yearOfEra +
      Math.floor(yearOfEra / 4) -
      Math.floor(yearOfEra / 100));
  const marchMonth = Math.floor((5 * dayOfYear + 2) / 153);
  const day =
    dayOfYear - Math.floor((153 * marchMonth + 2) / 5) + 1;
  const month = marchMonth + (marchMonth < 10 ? 3 : -9);

  return {
    year: year + (month <= 2 ? 1 : 0),
    month,
    day,
  };
}

これは広い年範囲を扱える、明快で移植性の高い実装です。今回の限定版は、この汎用性を固定範囲での速度と交換します。

Julian mapで年を復元する

今回の年復元はBen JoffeのJulian mapを利用します。

q       = 4 * (epochDay + 719468) + 3
century = floor(q / 146097)
julian  = q + 3 * century + (century & 3)
year    = floor(julian / 1461)
rem     = floor((julian - 1461 * year) / 4)

Gregorian calendarの400年周期を補正した後、一時的にJulian calendarの4年周期へ写すことで、年復元の依存鎖を短くします。

元のJoffe式 q - (century & ~3) + 4 * century は、century = (century & ~3) + (century & 3) を使うと、上の短い式へ整理できます。

1461 = 4 * 365 + 1 なので、julian / 1461 がMarch-basedの年を返し、余りを4で割った値がMarch 1から数えた年内日になります。

0 <= rem <= 365

1月と2月はMarch-based yearの末尾にあります。rem >= 306 の年補正をtableのbit 9へ格納することで、実行時の比較と加算も除去します。

月日を366要素のtableから取得する

通常は年内日から月日を復元するために、乗算、シフト、除算、1月・2月の補正を行います。しかし rem は 0..365 の366通りしかありません。

各値に対応する年補正、月、日を次の10-bit整数へ格納します。

(yearBump << 9) | (month << 5) | day

取得は次だけです。

const packed = MONTH_DAY[dayOfMarchYear];
const year = marchYear + (packed >>> 9);
const month = (packed >>> 5) & 15;
const day = packed & 31;

tableの大きさは、

366 * 2 = 732 bytes

です。一般的なPCのL1 cacheには十分小さい一方、cold cache、組み込み環境、コードサイズを重視する用途では算術版が有利な可能性があります。

Bunで除算を上方丸め逆数へ置き換える

Bunでは /146097 と /1461 より、あらかじめ求めた逆数との乗算が高速でした。

const INV_146097 = (1 / 146_097) * (1 + Number.EPSILON);
const INV_1461 = (1 / 1_461) * (1 + Number.EPSILON);

実際のbinary64値は次のとおりです。

INV_146097 = 0.0000068447675174712704
bits        = 0x3edcb5835e647c33

INV_1461   = 0.00068446269678302542
bits        = 0x3f466db072f2284e

通常の最も近いbinary64逆数では、割り切れる入力の積が整数よりわずかに小さくなり、Math.floor が1小さい値を返す場合があります。1 + Number.EPSILON を掛け、真の逆数よりわずかに大きい隣接値を使うことでこれを避けます。

どちらも、

INV_d * d - 1 = 2^-52

です。対象範囲の最大商は約100と10000なので、上方誤差はそれぞれ約 2.3e-14 と 2.3e-12 以下です。一方、割り切れない整数入力が次の商境界まで持つ距離は少なくとも 1/146097 と 1/1461 です。したがって、上方誤差によって次の整数へ到達することはありません。

この議論は指定範囲とIEEE-754 binary64に依存します。範囲を広げる場合は再証明と再検証が必要です。

また、二つの積は非負で2³¹未満の整数へ切り捨てられるため、Bun版では Math.floor を32-bit整数化の | 0 に置き換えられます。

const century = (q * INV_146097) | 0;
const year = (julian * INV_1461) | 0;

最終版では、q の定数部分も畳み込み、シフト、積、戻り値をint32ドメインへ閉じています。

const q = ((epochDay << 2) + 2_877_875) | 0;
const remainder =
  (julian - Math.imul(year, 1_461)) | 0;

また、非負の century について、

3c + (c & 3) = 4 * (c - floor(c / 4))

なので、Bun版では次の別形を使います。

const julian =
  (q + ((century - (century >> 2)) << 2)) | 0;

これは今回のBunでは有効でしたが、最適化されたC/Rustではコンパイラが元の式をすでに同等の命令列へ変換できます。一般にこちらが速いと主張するものではありません。

追加tableなしの4-wide SIMD版

複数の日付をまとめて変換できる場合、732-byte tableをさらに大きくする代わりに、月日復元を算術式へ戻して4入力をNEONで並列処理できます。

January/February補正は、packed表現では次の一回の加算になります。

year += 1, month -= 12

packed += 512 - 12 * 32
        = 128

Clangの4要素vector型で中心部分を書くと次の形です。

typedef uint32_t u32x4 __attribute__((ext_vector_type(4)));

static inline u32x4 civil_from_days_4(u32x4 epoch_day) {
    const u32x4 q = epoch_day * 4u + 2877875u;
    const u32x4 century = q / 146097u;
    const u32x4 julian = q + century * 3u + (century & 3u);
    const u32x4 year = julian / 1461u;
    const u32x4 rem = (julian - year * 1461u) >> 2;
    const u32x4 n = rem * 2141u + 197913u;
    const u32x4 march_month = n >> 16;
    const u32x4 day = (n & 65535u) / 2141u + 1u;
    const u32x4 jan_feb = (u32x4)(rem >= 306u);

    return year * 512u + march_month * 32u + day
        + (jan_feb & 128u);
}

Apple Silicon／Clang -O3 -march=native ではNEON命令へ展開されました。同じランダム入力配列を処理し、scalar側の自動vectorizeを無効にしたbatch比較は次のとおりです。

算術版	ns/件	scalar比
scalar	2.694	1.00倍
4-wide SIMD	0.713	3.78倍

全3,652,059 epoch dayについてHinnant実装と一致しました。これはARM64向けbatch APIのスループットであり、1件を返すscalar APIやpacked table版のレイテンシと同一の比較ではありません。

32-bit整数の境界

入力範囲では、

306 <= epochDay + 719468 <= 3652364
1227 <= q <= 14609459
0 <= century <= 99
0 <= julian < 14610000
0 <= year <= 9999
0 <= dayOfMarchYear <= 365

となり、整数部分は符号付き32-bitへ十分収まります。year bumpを含む MONTH_DAY の各値は10 bit、table全体は732 bytesです。

全数検証

指定範囲のすべてのepoch dayについて、Hinnant実装と比較しました。

2932896 - (-719162) + 1
= 3,652,059 inputs

検証対象はHinnant、Neri–Schneider、Ben Joffe、Bunの上方逆数版、packed table版です。TypeScript、Rust、Cの最終実装は全件一致しました。

ベンチマーク

Apple Silicon ARM64上で、決定的な疑似乱数で生成した 2^20 件のepoch dayを24回処理しました。入力位置はラウンドごとに回転させています。5回測定した最小値です。

Bun 1.4.0
rustc 1.96.0 -C opt-level=3 -C target-cpu=native
Apple clang 21.0.0 -O3 -march=native

今回再測定した結果は次のとおりでした。

環境	通常のHinnant	今回の限定版	実行時間削減率	スループット
Bun	37.088 ns/件	4.830 ns/件	87.0%	7.68倍
Rust	5.734 ns/件	1.500 ns/件	73.8%	3.82倍
C	5.315 ns/件	1.603 ns/件	69.8%	3.32倍

Bunでは、year bumpをtableへ移しつつdouble演算を残した版が6.091 ns/件、int32ドメインへ閉じた最終版が4.830 ns/件でした。year bumpのtable化に加え、定数畳み込み、Math.imul、シフトを使ってdoubleとint32の往復を減らした効果が出ています。

RustとCでは、ソース上の定数除算をコンパイラが乗算とシフトへ変換できます。そのため、明示的な逆数より通常の整数除算表記が適切でした。packed tableによる月日復元の依存鎖削減が大きく効いています。

これらは特定のCPU、コンパイラ、JIT、入力分布での結果です。別世代のApple Silicon、x86-64、Node.js/V8、ブラウザ、別バージョンのRustやClangでは必ず再測定してください。

先行研究と今回の位置づけ

この実装の年復元はBen JoffeのJulian mapを利用しています。Gregorian calendar変換を乗算とシフトへ変換する方法は、NeriとSchneiderがEuclidean affine functionとして体系化しています。Howard Hinnantの実装は基準となる汎用アルゴリズムです。

したがって、Julian map、年復元、定数除算のstrength reduction、年内日tableのいずれも、単独の新規技法として主張するものではありません。

今回の構成は次の限定特殊化です。

出力年を 1..9999 に限定する
Ben JoffeのJulian mapで年を復元する
0..365 のMarch-based年内日を、year bumpも含む732-byteのpacked tableへ写す
Bunでは範囲証明した上方丸めbinary64逆数を使う
CとRustでは定数除算のstrength reductionをコンパイラに任せる

調査した公開実装の範囲では、この固定範囲、Bunの上方丸め逆数、Joffe式、packed month/day tableを組み合わせた同一構成は確認できませんでした。ただし、あらゆるCPU、言語、入力範囲で最速または最適であることを意味しません。

正確な表現は次のとおりです。

Apple Silicon上の今回のBun、Rust、Cベンチマークにおいて、比較したHinnant、Neri–Schneider、Ben Joffe実装より高速だった。

まとめ

年 1..9999 に対応するepoch dayへ範囲を限定すると、civil_from_days は次の構成で高速化できました。

Julian mapでGregorianの400年補正を行う
1461日のJulian 4年周期から年とMarch-based年内日を復元する
366要素のpacked tableからyear bump、月、日を一度に取得する
Bunでは二つの定数除算を上方丸め逆数との乗算へ置き換える

今回のApple Silicon測定では、実行時間が通常のHinnant実装の約13%（Bun）、26%（Rust）、30%（C）になりました。さらに、追加tableを使わないCの4-wide SIMD算術版は、scalar算術版の約3.78倍のbatch throughputでした。

汎用コードではHinnant実装、tableを避けるならNeri–SchneiderまたはJoffeの算術版が適しています。入力範囲が保証され、732-byte tableが許容でき、変換がホットパスにある場合に今回の限定版が候補になります。

参考資料

Howard Hinnant, chrono-Compatible Low-Level Date Algorithms
Cassio Neri and Lorenz Schneider, Euclidean Affine Functions and Applications to Calendar Algorithms
Cassio Neri, EAF supplementary implementation
Ben Joffe, The Julian Map
Ben Joffe, A Very Fast 64-Bit Date Algorithm
Ben Joffe, fast-date-benchmarks
マジックナンバー化による高速な days_from_civil

Fast civil_from_days with Julian Map and Packed Table

ask_yoshi_taka — Fri, 28 Aug 2026 10:00:00 GMT

Converting a Unix epoch day back into a civil year, month, and day is commonly called civil_from_days. It is the inverse of the days_from_civil operation covered in the previous article.

civil date -- days_from_civil --> epoch day
civil date <-- civil_from_days --- epoch day

This article restricts output years to 1..9999 and combines Ben Joffe’s Julian-map year recovery with a 366-element packed month/day table. In Bun, two constant divisions are additionally replaced with multiplication by upward-rounded binary64 reciprocals.

In the Apple Silicon benchmarks reported here, the bounded implementation reduced execution time by approximately 87% in Bun, 74% in Rust, and 70% in C compared with the usual Howard Hinnant implementation.

Preconditions

The input range corresponding to civil years 1..9999 is:

-719162 <= epochDay <= 2932896

The endpoints are 0001-01-01 and 9999-12-31, respectively.

TypeScript Implementation

The Bun hot-path implementation returns the date packed into one integer:

packed = year * 512 + month * 32 + day

Months are in 1..12 and days are in 1..31, so the month and day fit in the low nine bits.

const INV_146097 = (1 / 146_097) * (1 + Number.EPSILON);
const INV_1461 = (1 / 1_461) * (1 + Number.EPSILON);

const MONTH_DAY = new Uint16Array(366);

for (let dayOfMarchYear = 0; dayOfMarchYear <= 365; dayOfMarchYear++) {
  const n = 2_141 * dayOfMarchYear + 197_913;
  const marchMonth = n >>> 16;
  const day = Math.floor((n & 65_535) / 2_141) + 1;
  const janOrFeb = dayOfMarchYear >= 306;
  const month = janOrFeb ? marchMonth - 12 : marchMonth;

  MONTH_DAY[dayOfMarchYear] =
    (Number(janOrFeb) << 9) | (month << 5) | day;
}

/**
 * Returns year * 512 + month * 32 + day.
 * Preconditions: -719162 <= epochDay <= 2932896.
 */
export function civilFromDaysPacked(epochDay: number): number {
  const q = ((epochDay << 2) + 2_877_875) | 0;
  const century = (q * INV_146097) | 0;
  const julian =
    (q + ((century - (century >> 2)) << 2)) | 0;
  const year = (julian * INV_1461) | 0;
  const remainder =
    (julian - Math.imul(year, 1_461)) | 0;

  return (
    (year << 9) + MONTH_DAY[remainder >>> 2]
  ) | 0;
}

If an ordinary object is needed, unpack it outside the hot loop:

export function unpackCivilDate(packed: number) {
  return {
    year: Math.floor(packed / 512),
    month: (packed >>> 5) & 15,
    day: packed & 31,
  };
}

Allocating an object inside civilFromDaysPacked would make object allocation a significant part of the benchmark. Packing the result keeps the measurement focused on the calendar conversion itself.

Rust Implementation

Rust can generate the table at compile time. The constant divisions are left as /, allowing the compiler to perform its usual strength reduction.

#[derive(Clone, Copy, Debug, Eq, PartialEq)]
pub struct CivilDate {
    pub year: i32,
    pub month: u32,
    pub day: u32,
}

const fn build_month_day_table() -> [u16; 366] {
    let mut table = [0u16; 366];
    let mut r = 0usize;

    while r <= 365 {
        let n = 2_141 * r as u32 + 197_913;
        let march_month = n >> 16;
        let day = (n & 65_535) / 2_141 + 1;
        let month = if r >= 306 {
            march_month - 12
        } else {
            march_month
        };

        let year_bump = u16::from(r >= 306);
        table[r] = (year_bump << 9) | ((month << 5) | day) as u16;
        r += 1;
    }

    table
}

const MONTH_DAY: [u16; 366] = build_month_day_table();

#[inline]
pub fn civil_from_days(epoch_day: i32) -> CivilDate {
    let q = 4 * (epoch_day + 719_468) as u32 + 3;
    let century = q / 146_097;
    let julian = q + century * 3 + (century & 3);
    let year = julian / 1_461;
    let day_of_march_year = julian % 1_461 / 4;
    let packed = MONTH_DAY[day_of_march_year as usize] as u32;

    CivilDate {
        year: (year + (packed >> 9)) as i32,
        month: (packed >> 5) & 15,
        day: packed & 31,
    }
}

C Implementation

In this C version, the initialization routine must run once at program startup. Production code can instead embed the generated values in a static const uint16_t[366], eliminating runtime initialization.

#include <stdint.h>

typedef struct {
    int32_t year;
    uint32_t month;
    uint32_t day;
} civil_date_t;

static uint16_t month_day[366];

static void init_month_day_table(void) {
    for (uint32_t r = 0; r <= 365; ++r) {
        const uint32_t n = 2141u * r + 197913u;
        const uint32_t march_month = n >> 16;
        const uint32_t day = (n & 65535u) / 2141u + 1u;
        const uint32_t month = r >= 306u
            ? march_month - 12u
            : march_month;

        month_day[r] = (uint16_t)(
            ((r >= 306u) << 9) | (month << 5) | day
        );
    }
}

static inline civil_date_t civil_from_days(int32_t epoch_day) {
    const uint32_t q = 4u * (uint32_t)(epoch_day + 719468) + 3u;
    const uint32_t century = q / 146097u;
    const uint32_t julian = q + century * 3u + (century & 3u);
    const uint32_t year = julian / 1461u;
    const uint32_t day_of_march_year = julian % 1461u / 4u;
    const uint32_t packed = month_day[day_of_march_year];

    return (civil_date_t) {
        (int32_t)(year + (packed >> 9)),
        (packed >> 5) & 15u,
        packed & 31u
    };
}

The Usual `civil_from_days`

Howard Hinnant’s reference implementation can be written in TypeScript as follows:

function civilFromDaysHinnant(epochDay: number) {
  const z = epochDay + 719_468;
  const era = Math.floor(z / 146_097);
  const dayOfEra = z - era * 146_097;
  const yearOfEra = Math.floor(
    (dayOfEra -
      Math.floor(dayOfEra / 1_460) +
      Math.floor(dayOfEra / 36_524) -
      Math.floor(dayOfEra / 146_096)) /
      365,
  );
  const year = yearOfEra + era * 400;
  const dayOfYear =
    dayOfEra -
    (365 * yearOfEra +
      Math.floor(yearOfEra / 4) -
      Math.floor(yearOfEra / 100));
  const marchMonth = Math.floor((5 * dayOfYear + 2) / 153);
  const day =
    dayOfYear - Math.floor((153 * marchMonth + 2) / 5) + 1;
  const month = marchMonth + (marchMonth < 10 ? 3 : -9);

  return {
    year: year + (month <= 2 ? 1 : 0),
    month,
    day,
  };
}

This is a clear, portable implementation with a broad year range. The bounded version trades that generality for speed over a fixed domain.

Recovering the Year with the Julian Map

The year-recovery stage uses Ben Joffe’s Julian map:

q       = 4 * (epochDay + 719468) + 3
century = floor(q / 146097)
julian  = q + 3 * century + (century & 3)
year    = floor(julian / 1461)
rem     = floor((julian - 1461 * year) / 4)

After correcting for the Gregorian 400-year cycle, the calculation temporarily maps the count into Julian four-year cycles. This shortens the dependency chain for recovering the year.

The original Joffe expression, q - (century & ~3) + 4 * century, reduces to the shorter expression above by using century = (century & ~3) + (century & 3).

Because 1461 = 4 * 365 + 1, julian / 1461 gives the March-based year, while the remaining value divided by four gives the day counted from March 1:

0 <= rem <= 365

January and February are the final two months of this March-based year. Storing the rem >= 306 year correction in bit 9 of the table removes the runtime comparison and addition.

Recovering Month and Day from a 366-Element Table

The arithmetic version recovers month and day with multiplication, shifts, division, and a January/February correction. Here, rem has only 366 possible values, from 0 through 365.

The corresponding year correction, month, and day are stored in a ten-bit integer:

(yearBump << 9) | (month << 5) | day

The lookup and decoding are:

const packed = MONTH_DAY[dayOfMarchYear];
const year = marchYear + (packed >>> 9);
const month = (packed >>> 5) & 15;
const day = packed & 31;

The table occupies:

366 * 2 = 732 bytes

That is small enough for L1 cache on ordinary PCs and servers. An arithmetic implementation may still be preferable with a cold cache, on embedded systems, or when code and data size matter more than hot-loop throughput.

Replacing Division with Upward-Rounded Reciprocals in Bun

In Bun, multiplication by precomputed reciprocals was faster than /146097 and /1461:

const INV_146097 = (1 / 146_097) * (1 + Number.EPSILON);
const INV_1461 = (1 / 1_461) * (1 + Number.EPSILON);

The resulting binary64 values are:

INV_146097 = 0.0000068447675174712704
bits        = 0x3edcb5835e647c33

INV_1461   = 0.00068446269678302542
bits        = 0x3f466db072f2284e

With the ordinary nearest binary64 reciprocal, an exactly divisible input can produce a product just below the expected integer, causing Math.floor to return one less. Multiplying by 1 + Number.EPSILON selects a neighboring value just above the exact reciprocal and avoids that failure.

For both divisors:

INV_d * d - 1 = 2^-52

The maximum quotients in this domain are approximately 100 and 10,000, so the upward errors are at most approximately 2.3e-14 and 2.3e-12. A nondivisible integer input remains at least 1/146097 or 1/1461 from the next quotient boundary. The upward error therefore cannot reach the next integer.

This argument depends on the specified input range and IEEE-754 binary64 arithmetic. A wider range requires a new proof and exhaustive verification.

Both products truncate to nonnegative integers below 2³¹ in this domain. The Bun implementation can therefore replace Math.floor with 32-bit integer coercion using | 0:

const century = (q * INV_146097) | 0;
const year = (julian * INV_1461) | 0;

The final implementation also folds the constant part of q and keeps the shifts, product, and return value in the int32 domain:

const q = ((epochDay << 2) + 2_877_875) | 0;
const remainder =
  (julian - Math.imul(year, 1_461)) | 0;

For nonnegative century values:

3c + (c & 3) = 4 * (c - floor(c / 4))

The Bun implementation consequently uses this equivalent form:

const julian =
  (q + ((century - (century >> 2)) << 2)) | 0;

This form helped in the tested Bun environment. Optimizing C and Rust compilers can already lower the original expression to an equivalent instruction sequence, so it is not assumed to be universally faster.

Four-Wide SIMD Without an Additional Table

When several dates can be converted together, month/day recovery can be returned to arithmetic and evaluated across four NEON lanes instead of enlarging the lookup table.

The January/February correction becomes one addition in the packed representation:

year += 1, month -= 12

packed += 512 - 12 * 32
        = 128

The core can be expressed with Clang’s four-element vector type:

typedef uint32_t u32x4 __attribute__((ext_vector_type(4)));

static inline u32x4 civil_from_days_4(u32x4 epoch_day) {
    const u32x4 q = epoch_day * 4u + 2877875u;
    const u32x4 century = q / 146097u;
    const u32x4 julian = q + century * 3u + (century & 3u);
    const u32x4 year = julian / 1461u;
    const u32x4 rem = (julian - year * 1461u) >> 2;
    const u32x4 n = rem * 2141u + 197913u;
    const u32x4 march_month = n >> 16;
    const u32x4 day = (n & 65535u) / 2141u + 1u;
    const u32x4 jan_feb = (u32x4)(rem >= 306u);

    return year * 512u + march_month * 32u + day
        + (jan_feb & 128u);
}

Apple Clang with -O3 -march=native lowered this function to NEON instructions. Processing the same randomized input array, with automatic vectorization disabled for the scalar side, produced:

Arithmetic version	ns/item	Relative throughput
Scalar	2.694	1.00x
Four-wide SIMD	0.713	3.78x

The SIMD implementation matched Hinnant across all 3,652,059 epoch days. This is ARM64 batch throughput, not a like-for-like latency comparison with the one-item scalar API or packed-table implementation.

32-Bit Integer Bounds

Within the input domain:

306 <= epochDay + 719468 <= 3652364
1227 <= q <= 14609459
0 <= century <= 99
0 <= julian < 14610000
0 <= year <= 9999
0 <= dayOfMarchYear <= 365

The integer portion therefore fits comfortably in signed 32-bit values. Every MONTH_DAY entry, including the year bump, fits in ten bits, and the complete table occupies 732 bytes.

Exhaustive Verification

Every epoch day in the specified range was compared with the Hinnant implementation:

2932896 - (-719162) + 1
= 3,652,059 inputs

The tested candidates included Hinnant, Neri–Schneider, Ben Joffe, the Bun upward-reciprocal variant, and the packed-table variant. The final TypeScript, Rust, and C implementations all matched throughout the complete range.

The endpoints and Unix epoch were also checked directly:

-719162 -> 0001-01-01
       0 -> 1970-01-01
 2932896 -> 9999-12-31

Benchmarks

The benchmarks ran on Apple Silicon ARM64. Each implementation processed a deterministically generated array of 2^20 epoch days 24 times, rotating the input position between rounds. The best result from five trials was recorded.

Bun 1.4.0
rustc 1.96.0 -C opt-level=3 -C target-cpu=native
Apple clang 21.0.0 -O3 -march=native

Fresh measurements produced the following results:

Environment	Usual Hinnant	Bounded version	Time reduction	Throughput
Bun	37.088 ns/item	4.830 ns/item	87.0%	7.68x
Rust	5.734 ns/item	1.500 ns/item	73.8%	3.82x
C	5.315 ns/item	1.603 ns/item	69.8%	3.32x

In Bun, the version with a table-stored year bump but remaining double arithmetic took 6.091 ns/item, while the int32-domain final version took 4.830 ns/item. In addition to storing the year bump, folding constants and using Math.imul and shifts reduced transitions between double and int32 operations.

Rust and C compilers already lower division by constants to multiplication and shifts where profitable. Leaving integer division in the source was therefore appropriate in those languages. Replacing the month/day arithmetic dependency chain with the packed lookup produced the larger remaining improvement.

These measurements apply to one CPU, compiler/JIT version, and input distribution. Other Apple Silicon generations, x86-64, Node.js/V8, browsers, and different Rust or Clang versions should be measured independently.

Prior Work and Positioning

The year-recovery stage is based on Ben Joffe’s Julian map. Neri and Schneider systematically study Gregorian calendar conversion using multiplication, shifts, and Euclidean affine functions. Howard Hinnant’s implementation is the general reference baseline.

The Julian map, year recovery, strength reduction of constant division, and lookup of month/day from day-of-year are therefore not claimed as individually new techniques.

The construction presented here is a bounded specialization that:

restricts output years to 1..9999;
recovers the year with Ben Joffe’s Julian map;
maps the 0..365 March-based day to a 732-byte packed table containing the year bump, month, and day;
uses range-proven upward-rounded binary64 reciprocals in Bun; and
leaves constant-division strength reduction to the C and Rust compilers.

Among the public implementations examined, I did not find the same construction combining this fixed range, the Bun upward-rounded reciprocals, the Joffe mapping, and a packed month/day table. This does not establish optimality across all CPUs, languages, or input domains.

A precise performance claim is:

In these Apple Silicon benchmarks for Bun, Rust, and C, the bounded implementation was faster than the Hinnant, Neri–Schneider, and Ben Joffe implementations compared here.

Summary

Restricting the input to epoch days corresponding to years 1..9999 enables the following civil_from_days specialization:

apply the Gregorian 400-year correction through the Julian map;
recover the year and March-based day from a 1,461-day Julian cycle;
recover the year bump, month, and day together from a 366-element packed table; and
in Bun, replace two constant divisions with upward-rounded reciprocal multiplication.

In these Apple Silicon measurements, the bounded implementation reduced execution time by approximately 87% in Bun, 74% in Rust, and 70% in C compared with the usual Hinnant implementation. The table-free four-wide C SIMD arithmetic version additionally delivered approximately 3.78 times the batch throughput of its scalar arithmetic counterpart.

For general-purpose code, Hinnant’s implementation remains the clear and broadly ranged choice. If a table is undesirable, the arithmetic Neri–Schneider or Joffe implementations are strong alternatives. This bounded version is intended for a measured hot path where the range guarantee and 732-byte table are acceptable.

References

Howard Hinnant, chrono-Compatible Low-Level Date Algorithms
Cassio Neri and Lorenz Schneider, Euclidean Affine Functions and Applications to Calendar Algorithms
Cassio Neri, EAF supplementary implementation
Ben Joffe, The Julian Map
Ben Joffe, A Very Fast 64-Bit Date Algorithm
Ben Joffe, fast-date-benchmarks
A Faster days_from_civil Using Magic-Number Division

AWS Cost Optimization Techniques for Databricks on AWS Workloads

ask_yoshi_taka — Mon, 27 Jan 2025 13:47:13 GMT

This guide focuses on practical AWS cost optimization strategies for scenarios where you deploy Databricks on your own AWS infrastructure, instead of leveraging a fully managed (serverless) Databricks solution. By applying these techniques, you can reduce AWS costs while maintaining efficient performance for Databricks workloads.

Reduce AWS Config Costs

A typical challenge with off-the-shelf solutions is the frequent spin-up and shutdown of EC2 instances. This activity generates a significant volume of inventory and change-tracking data in AWS Config, leading to higher costs.

Over time, AWS has introduced additional managed rules for EC2 in AWS Config, which has steadily increased the cost per instance. (EC2 instances are often seen as flexible but somewhat “legacy” in AWS and are frequent targets for attacks, necessitating more rules.)

Additionally, Config recording often triggers other AWS security services, creating a chain reaction of escalating costs.

To manage these expenses, consider either excluding EC2 (or other resources) from AWS Config recording or switching from continuous recording to daily recording.

However, keep in mind that this setting applies to all EC2 instances in the account. Applications or bastion hosts running on EC2 could unintentionally fall outside AWS Config’s monitoring, potentially increasing security risks.

Consider S3 Versioning

Delta tables include a time-travel feature, which may overlap with S3 versioning. Depending on your specific needs, you might find that S3 versioning is entirely unnecessary.

If you decide to disable S3 versioning, keep in mind that older object versions will not be automatically removed. Be proactive in cleaning them up completely to avoid unnecessary storage costs.

On the Delta table side, you can manage retention by removing data beyond its retention period using the VACUUM command.

Databricks recommends disabling bucket versioning so that the VACUUM command can effectively remove unused data files.

Databricks recommends retaining three versions and implementing a lifecycle management policy that retains versions for 7 days or less for all S3 buckets with versioning enabled.

Use the S3 Storage Lens feature to analyze the size breakdown of your S3 buckets and gain insights into your storage usage. This tool also allows you to visualize the amount of data being used by S3 versioning, helping you identify potential areas for optimization.

Reduce EBS Costs

Start by migrating your EBS volumes from gp2 to gp3. This simple change can result in approximately 20% cost savings. For detailed configuration steps, refer to the following resources:

Ideally, gp3 should be set as the default volume type.

Another critical consideration is to verify whether any jobs are attaching a large number of EBS shuffle volumes. Most workloads don’t require additional shuffle volumes, as each worker already comes with 30GB + 150GB of EBS storage by default.

Key settings to review include:

aws_attributes.ebs_volume_type: Specifies whether shuffle volumes should be added, and if so, their type. aws_attributes.ebs_volume_size: Defines the size of the EBS volume (in GiB). aws_attributes.ebs_volume_count: Determines the number of EBS volumes.

For instance, setting ebs_volume_count to 2 effectively doubles your disk usage. To improve efficiency, you can also enable local storage autoscaling by activating enable_elastic_disk.

Reduce NAT Gateway Traffic

When configuring AWS environments — not just for Databricks — always set up an S3 Gateway Endpoint to ensure that S3 data transfers are cost-free. This is a best practice for minimizing unnecessary NAT Gateway traffic.

For high-volume data transfers or specific destinations, consider setting up PrivateLink to further optimize costs.

Avoid Incremental Listing in Auto Loader

While the exact version is unclear, Incremental Listing in Auto Loader has been deprecated. By default, every 8th operation triggers a full directory scan using the S3 List API. This significantly increases API call charges as well as overall processing costs, including additional time and resource consumption.

Purchase Savings Plans

Consider purchasing Savings Plans to reduce EC2 costs. While EC2 Reserved Instances (RIs) typically offer greater discounts, Savings Plans are a better option if your workloads are not entirely predictable.

Leverage Spot Instances

Optimize your cluster costs by configuring the percentage of your cluster to use Spot Instances.

Keep in mind, however, that the DBU cost remains unchanged when using Spot Instances. To achieve the best overall cost savings, including DBU and instance costs, start by reviewing the discount rates for the instance types you plan to use.

Consider Upgrading Instance Types

Upgrading your EC2 instance family can deliver better performance and potentially reduce costs. However, EC2 costs don’t always scale proportionately with DBU rates. In some cases, EC2 costs may remain unchanged while DBU rates increase. Since DBU costs heavily influence per-instance pricing, it’s crucial to monitor these changes closely.

You may also consider exploring Graviton-based instances. However, be aware that several features are unavailable, as documented. Additionally, DBU rates aren’t always lower, and performance gains are not guaranteed, making thorough testing essential before deployment.

Additional Measures

Right-sizing your clusters is, of course, essential. You can optimize Databricks costs by tailoring configurations on a per-cluster basis. Be sure to review recommended practices step by step for maximum efficiency.

For example, default cluster settings often incur additional costs due to idle DBU usage for up to two hours. Adjust these settings as needed to avoid unnecessary expenses.

Upgrading your runtime version and adopting the latest features of Databricks and Delta Tables are highly recommended. These updates can improve performance and reduce costs.

Additionally, don’t overlook improvements on the Spark side, as well as relevant updates from AWS, which can directly impact your setup’s efficiency and capabilities.

For further optimization tips, check:

Although not directly tied to AWS, third-party monitoring tools like Datadog may charge you for the EC2 resources used by Databricks.

I won’t cover overall architecture or general performance optimization in this article.

Challenging Issues

CloudTrail

Costs scale proportionally with the volume of service access.

GuardDuty

Enabling S3 Protection can lead to significant costs when analyzing Unity Catalog access on S3. You can review the cost breakdown in the GuardDuty usage section. Note that the underlying data source for this analysis is CloudTrail.

Finally

Cost optimization can feel overwhelming, but starting small can lead to big results. Begin by focusing on AWS Config settings — adjust recording intervals or exclude unnecessary resources to immediately reduce costs while maintaining essential monitoring. Small changes like these can pave the way for larger, more comprehensive optimizations down the line. Let’s take the first step today!

This article is the English version of the original article written in Japanese, available here.

Databricks on AWS上のAWSコストを削減する技術

ask_yoshi_taka — Fri, 19 Jan 2024 03:26:32 GMT

サーバーレス(マネージド)ではなく自組織のAWS上で運用した場合です。

AWS Config代を削減する

既製品でよくある仕組みでEC2が起動終了を大量に繰り返します。それに応じて、リソースのインベントリと変更の追跡をすべくAWS Configが大量のデータを取得し料金が膨れ上がります。

年々AWS ConfigのEC2周りマネージドルールが増えており、EC2 1台あたりのConfigコストも増加傾向です。
＊EC2は攻撃の対象になりがち、AWSとしても古い仕組み、ある意味なんでもできるということでルールが増えていく模様加えて、Configデータを起点にセキュリティ系AWSサービスのコストが連鎖して上昇します。

対策としてはAWS ConfigでEC2等の記録除外設定を入れるか、即時記録ではなく定期的な記録に変更するかのどちらかです。

一方、EC2すべてに設定することから、EC2上のアプリケーションや踏み台サーバが同一アカウントにあると、AWS Configで追跡できずリスクが高まります。

S3にあるデータの保持期間を検討する

Deltaテーブルにはタイムトラベル機能があり、S3のバージョニングと競合しています。要件によりますがS3側のバージョニングは不要ではないでしょうか。

S3のバージョニングを停止してもオブジェクトの古いバージョンは残ったままです。全部削除しましょう。

Deltaテーブル側ではVACUUM処理により保持期間が切れたものを削除できます。

Databricks では、*VACUUM* コマンドで未使用のデータファイルを効果的に削除できるように、バケットのバージョン管理を無効にすることをお勧めします。

EBS代を削減する

まずEBSをgp2からgp3に変更しましょう。20%程度のコスト削減が見込めます。設定方法は以下のリンクより。

初期設定をgp3にしてもらえると嬉しいですね。

次に重要な点として、ジョブ等に大量のEBS シャッフルボリュームがアタッチされていることがあるので確認しましょう。多くのワークロードでは追加のシャッフルボリュームはいらないはず。そもそも初期設定でワーカーに30GB+150GBのEBSが準備されています。

aws_attributes.ebs_volume_type シャッフルボリュームを足すかどうか、および足す場合の種類 aws_attributes.ebs_volume_size AWS EBS ボリュームのサイズ (GiB 単位) aws_attributes.ebs_volume_count AWS EBS ボリュームの数

見ての通りebs_volume_count を2にすれば2倍ディスクを消費します。enable_elastic_diskでローカルストレージのautoscalingも可能です。

NAT Gatewayの通信を抑える

必ずS3 Gateway Endpointを設定し、S3との通信料金を無料にしましょう。

通信先とデータ量次第で、PrivateLinkを設定しましょう。

Savings Planを購入する

Savings Planを買ってEC2代を節約しましょう。

EC2 RIのほうが安い傾向にあるものの、ワークロードが完全に読めていない限りはSavings Planが確実です。

Spot Instanceを活用する

Spot Instance割合が設定できます。

ただしDBUは変わらないようです。

どのインスタンスを使うか決めるパラメータとしては以下が考えられます。
(インスタンスDBU + インスタンス単価** ( Spot Instance割合 ( 該当インスタンスRI割引後価格) + (1 — Spot Instance割合)* SavingsPlan適用時価格) + *EBS代)** _該当インスタンスでの実行時間 _ 該当インスタンスの数*

なかなか複雑です。まずは利用したいインスタンスの割引率を見てみましょう。

インスタンスの最新化を検討する

EC2のファミリをアップグレードすればIntelなら第6世代まではコストを抑えつつ性能が上がります。

ただし、EC2インスタンスの料金とDBUが必ずしも比例しているわけではない模様。確認したところEC2料金はそのままでもDBUが上昇することがあります。DBUのほうがインスタンスあたり単価が大きいので注意。

Graviton系インスタンスも利用可能です。残念ながらドキュメントにある通り、複数の機能が利用できません。またDBUも安いということはなさそうで、パフォーマンスは向上するとは限らず検証が必要です。

その他対応事項

当然ですがクラスターのサイズを調整しましょう。Databricks料金ごと最適化できます。以下のリンクは推奨事項です。一つずつ確認しましょう。例えばクラスタの初期設定ではDBU含めアイドル2時間分追加コストがかかります。

Runtimeのバージョンを上げつつ、DatabricksやDelta Tableの最新機能に移行していきましょう。Spark側の進化も忘れずに。AWSもたまに関係ある良いアップデートがあります。

最適化はこちら。このページにもある程度記載されつつ、サイドバーやページ内リンクからさらに詳細ページに飛べます。

下記の記事は細かいtipsが載っていておすすめです

AWSと直接関係ないですが、Datadogなど3rd Partyモニタリングツールは確認しないとDatabricksのEC2分の料金が請求されます。

全体のアーキテクチャ、一般的なパフォーマンス最適化といった話は割愛します。

対応が難しいもの

CloudTrail

基本的には各種サービスのアクセスと比例します。

GuardDuty

S3 Protectionを有効にしていると、S3上のUnity Catalogのアクセス解析代が多くかかります。バケット内訳はGuardDutyの使用状況欄から確認できます。

解析の元ネタはCloudTrailです。

最後に

DatabricksでかかるAWS代を節約してDatabricksのDBUをたくさん使いましょう（？）

データセンターは公害か

ask_yoshi_taka — Sat, 02 May 2026 00:12:20 GMT

データセンター(DC)が話題になることが増えました。しかしギャップがあるようなので情報を整理しました。

特に問題となる設備

データセンターにはサーバだけあるわけではありません。冷却設備と電源、非常用含めたディーゼル発電機が問題になりやすいです。

騒音/低周波/振動

サーバというより冷却設備と電源設備の騒音です。低周波は外部に長くいないと影響を感じにくいでしょう。

排熱

特に夏場は影響が無視できなくなります。温暖化やヒートアイランドに埋もれがちですが、局所的には負荷を増やす方向に働きます。

臭いと危険なガス

主に非常用ディーゼル発電機から発生します。ここでポイントとなるのが、定期試験運転は法令や保守要件により不可避であり、月次・年次で実施されることです。短時間であってもイベント性が高く、騒音・排ガス・臭気として住民に知覚されやすい点が特徴です。消防法で求められた負荷試験にもなればさらに負荷をかけて動かすことになります。

(消火用のガスもありますがこれは他の建物でも変わらないので除外)

雇用

立ち上げ期はともかく、運用は少人数です。地域によくある誤解として、Googleのソフトウェアエンジニアのような良質な雇用が多数集まるという期待があります。実際は契約業者に作業を任せますし、人数も少なく、そもそも人員はソフトウェアエンジニアではありません。効果は限定的です。

不透明

セキュリティ上の必然もありNDAが多くなります。しかし住民から見ると説明がない施設になるでしょう。

日本でのデータセンター建設の地域メリット

日本の場合固定資産税による税収アップは間違いないです。日本では基本的に誘致のために税金を今のところ使ってないので黒字でしょう。印西市の事例がわかりやすいですね。

あまり日本では問題にならなそうな項目

海外では議論になっても日本ではそこまでではないという項目もあります。

現時点では、日本の電力系統は比較的安定しています。また電気代が変動制ではないので住民が電気代増加に巻き込まれることもないでしょう。※ただし、DC密集地での「変電所容量の奪い合い」という産業的な制約は出始めています

空冷式が多く、水利用は相対的に少ない傾向があります。高湿度環境では蒸発冷却の効率が出にくいことも一因と考えられます。

DC誘致のために税金を使う底辺への競争も発生していません。

なぜ一部のオンプレエンジニアは反対運動に理解を示さないのか

仕事場への認識

住民から見れば、巨大な電力消費施設・排熱施設・非常用発電機施設ですが、エンジニアから見ると「ラックがある場所」です。視野がラック内・ケーブル・手順書・入館申請に閉じがち。日本のオンプレエンジニアはデータセンターを「入館する場所」として見ていて、住民は「押し寄せてくる産業施設」として見ている。

データセンター特有の音、温度、湿度も慣れてしまえば背景に興味はなくなるでしょう。

時間の流れの非対称性

基本的になにかあるとき、日中に訪問するだけの人が多いので、24時間365日向き合う住民感覚とはずれるでしょう。データセンターは24時間稼働です。たまにいくだけなら問題を感じにくい。

職能ギャップ

サーバやラックに詳しくてもファシリティは専門外です。建物の建設、設計や保守をしているわけではないので。そしてファシリティを担当する専門家は特定企業にいるごく少数でしょう。レイヤーが異なるので触る機会も見る機会もありません。

コロケーション型としてよくある、DCのラックやスペースを借りるだけのタイプならなおさら無関係です。電源・空調・発電機といった設備は完全に外部化され、問題認識が生まれにくい構造になります。

都市型DCの特殊性

大手町にあるような都心型データセンターは地下にあります。騒音振動などは減衰され、景観は関係なく、排熱も都心に紛れて気づけません。そのため都市型しか知らなければ反対への理解は難しいでしょう。

結論

海外よりは問題が発生しづらいのは幸いですが、それでも問題は必ず発生します。押し付けではない本物の住民理解やコミュニケーションが必要かと思います。

Datadogコスト効率化プロダクトを作ってみて仮説検証して考えたこと

ask_yoshi_taka — Mon, 06 Oct 2025 01:21:00 GMT

当初の仮説

AWSのFinOps領域は競合が多く、ツールも成熟している。一方で、Datadogはクラウドプロバイダに次ぐ支出規模（コスト2位）になることが多いにもかかわらず、基本的なコスト削減が十分に行われていないケースが多く、競合も少ないと考えた。

これまでDatadogのコスト削減を実践してきたが、海外を含めても、（手前味噌ながら）下記のレベルに到達している公開情報は見当たらず、差別化の余地があると判断した。

Datadogの支払い/コストを削減するtips集 (veritycost.com) - AWSといったクラウドプロバイダへの支払いを100とすると、Observabilityベンダーとの支払いは、おおよそ15〜30程度となります。

また、コスト削減のようなボトムライン改善型サービスは、ユーザーとサービス提供者の間で利益相反が起きやすいものの、マイクロSaaSとしてニッチ市場で収益を確保する分には問題ないと考えた。＊1

仮説が外れた要因

コストへの無関心

そもそも多くのエンジニアやエンジニア組織は、根本的にコストに関心がない。

コスト削減やコストコントロールは「自分の仕事ではない」と捉えられており、興味を持たれにくい。

仮に関心があったとしても、AWSコストの管理だけで手一杯である。

さらに、Datadogのコストまで意識が向く層でも、比較基準が乏しく、しばしばダニング＝クルーガー効果が働く可能性がある。

ここまで突破できたとしても、大きめの組織では、実際に担当しているのは現場エンジニア一人だけというケースが多く、購買の意思決定者からは遠く離れている。

そのため、たとえ予算枠内に収まる安価なツールであっても、導入判断まで至るのは難しい。

コスト可視化機能の登場

Datadog自身もDatadogコスト可視化機能を提供し始めており、「少し見えれば十分」と考える大多数の利用者層にはそれで満足されてしまう。

Cloud Cost Management | Datadog (www.datadoghq.com) - Unify cost and performance data to empower engineers to optimize workloads and enable FinOps to reduce waste and drive…

APIキーのハードル

Datadogをプラットフォームとして考えると、実質的にはOIDCが使えず、権限の強いAPIキーしか3rd Partyツールと連携できない。

セキュリティ上の不安が残るのは当然で、これでは試してもらうこと自体が難しい。

結論

総合して考えると、プロダクトを導入してもらうには、現状（＝「何もしない」）との間に圧倒的な差、すなわち10倍差が必要だった。

しかし、それを満たすだけの価値、認知・導入・運用コストを含めて既存行動を変えるに足る圧倒的な便益を提供できなかったということになる。

学び

プロダクト開発という点では、ほぼ100％ vibe codingでの開発や、Rust言語・ GenAI APIを組み込んだプロダクト開発の勘を習得できた（検証前に開発するのは良くないが、それはそれとして開発したかったので）。＊2

GitHub - yoshi-taka/dd-cost-optimizer (github.com) - Contribute to yoshi-taka/dd-cost-optimizer development by creating an account on GitHub.

また、顧客候補の探し方などマーケティング面での経験を積むことができ、結果的には「得した」と言える。

＊1 特に成果報酬型のコスト削減は悪夢
＊2 AIは競合的技術である。いくら電卓で計算しても暗算が速くならないのと同じであり、指示されたことをただやるだけの人間が全く学ばないのと等しい。AIからの提案について自分でひと手間かけない限り成長せず、人体実験の被験者や服従者の気持ちになることができる。今回はAIが得意とする「言語の構文周り」に関してはあえてそれで挑戦し、言語周辺の開発インフラについては徹底的に調べて最適化した。アーキテクチャや非機能要件についても本番レベルで対応している

Datadogの支払い/コストを削減するtips集

ask_yoshi_taka — Mon, 12 Jun 2023 06:02:55 GMT

AWSといったクラウドプロバイダへの支払いを100とすると、Observabilityベンダーとの支払いは、おおよそ15〜30程度となります。

この記事では大まかな方針を記載し、削減余地が大きいログ、APM、Infra Hostについては詳述します。

金額と明細を可視化する

Admin以外の権限のユーザーだと利用量は参照できますが、具体的な金額が見えません。Standard RoleなどにDatadogのBillingを参照できる権限をつけるとよいでしょう。まずは金額と明細をメンバーに共有しましょう。

Usage Attributionで明細を可視化する

![](../../assets/datadog-cost-reduction-tips-378b319c87d6-01.png)

[https://docs.datadoghq.com/ja/account_management/billing/usage_attribution/](https://docs.datadoghq.com/ja/account_management/billing/usage_attribution/)

契約プラン次第ですが各チームに自分で調査してもらうのに便利です。

ログを削減する

LambdaのSTART / ENDログを転送抑制する

Lambdaでは必ずSTART / ENDログが出力されますが、このログは情報量が少ないです。特にトレースを導入しているなら不要でしょう。除外するとログが半分以下になることも。

設定方法は以下の通り。転送ルートがLambda Extensions経由でもDatadog Forwarder経由でも有益です。

REPORTログはlambda enhanced metricsとしてduration計算などに使われます。一方、送信しingestとして取り込みさえできればログindexには不要です。indexから除外も検討しましょう

どのログが多いのかログ画面のTree Mapで可視化する

![](../../assets/datadog-cost-reduction-tips-378b319c87d6-02.png)

[https://docs.datadoghq.com/ja/dashboards/widgets/treemap/](https://docs.datadoghq.com/ja/dashboards/widgets/treemap/) 画像はイメージです

ログ画面でTree Mapを使い、カテゴリごとに量を可視化しましょう。同時に複数のカテゴリでグルーピングできます。アカウント、サービス、Hostあたりが便利です。

どのログが多いのかメトリクスから探る

![](../../assets/datadog-cost-reduction-tips-378b319c87d6-03.png)

[https://docs.datadoghq.com/ja/dashboards/querying/](https://docs.datadoghq.com/ja/dashboards/querying/) 画像はイメージです

メトリクスを使うなら、datadog.estimated_usage.logs.ingested_bytesからおおよそ可視化できます。

メトリクスの強みはSplit Graph機能です。グラフをカテゴリで分割できるので見やすく助かります。

ログPatterns機能で不要なログパターンを探る

![](../../assets/datadog-cost-reduction-tips-378b319c87d6-04.png)

[https://docs.datadoghq.com/ja/logs/explorer/analytics/patterns/](https://docs.datadoghq.com/ja/logs/explorer/analytics/patterns/)

Patterns機能は過小評価されています。不要なパターンのログ、おかしいログが出てないか、コスト削減の観点では量が多いものを探してみましょう。

Statusで絞る

WARN、ERRORといったログが大量に出ているのは良くない傾向です。整理整頓しましょう。アプリケーションも改善できる可能性があります。

二重出力を確認する

たまに二重に出力されています。Datadogの設定ミスの可能性が高いです。

サンプリングする

代わり映えのないログはサンプリングを検討しましょう

転送量を削減すれば、AWS内ならDatadog ForwarderのLambda実行コスト、転送コストも削減可能です。Datadog ForwarderのLambdaとしてのコストは地味に嵩みます。

APMを削減する

可視化する

方法はログと同じです。上記を参照ください。

プロキシ的なサービスを除外する

安定しているサービスはAPMの対象から除外すると良いでしょう。

サンプリングする

トレース全体をサンプリングする方法と、トレース内の特定のアクセスだけをサンプリングする方法があります。DD_TRACE_SAMPLING_RULESにより、例えばDBアクセスだけをサンプリングすることが可能です。

二重出力を確認する

たまに二重に出力されています。Datadogの設定ミスの可能性が高いです。

Infra Hostを削減する

AWS Integrationから除外する

Datadog Agentを入れていないEC2ホストもAWS Integrationを設定していると課金対象となります。EC2全部について監視不要ならAWS Integration画面からEC2連携を除外しましょう。

CloudWatch Metric Streamsを設定しているときは追加作業が必要です。AWS側で名前空間からEC2を除外し、Datadogに流れないようにしましょう。

その他利用量の削減

API テストを減らす

実行回数で課金されるため、1分に1回のチェックだと1時間に1回のチェックに比べ60倍の金額となります。開発環境なら長くても良いでしょう。ワークロードに応じて間隔を空けましょう。

ロケーション数とも金額が比例するため、東京だけに絞るのも一つの方法です。

他のDatadog機能と連携をしないなら別のサービスに切り替えたほうが安いことも。

時間帯によって間隔を変更できると便利ですが、標準機能には今のところ存在しないため、行うならDatadog APIで随時設定する仕組みを準備しましょう。

Sensitive Scannerを削減する

Lambdaの標準ログはSensitiveデータが入りようがないのでSTART / END / REPORTログを除外しましょう。

条件の変更

カード払いから領収書払いに切り替えることもできます。有利かどうかは経理部門やファイナンス部門に確認しましょう。

コミットメントや各種プランも適宜見直しましょう。

最後に

以下の記事でも述べた通り、特にログの部分はAWSコストと連動しています。一石二鳥を狙うとよいです。

How Busy Engineers Can Reduce Datadog Costs with Actionable Tips

ask_yoshi_taka — Mon, 20 Jan 2025 13:29:43 GMT

Feeling the pinch of rising Datadog expenses?

If you’re searching for effective Datadog cost optimization strategies, this guide is for you. It provides actionable tips to reduce Datadog costs by focusing on high-impact areas such as log management, APM (Application Performance Monitoring), and infrastructure hosts. By implementing these techniques, you can significantly cut Datadog expenses without sacrificing visibility or performance.

Start by Making Costs and Details Transparent Across Your Organization

I know you are busy — bring others on board to drive cost-saving initiatives.

Any roles except the Datadog Admin role can view usage but don’t have access to detailed cost data.** **Consider granting roles like Standard Role the ability to access Datadog billing details. Start by sharing the cost breakdown and insights with your teams.

You can request access to more detailed reports.

Further detailed usage reports can also be created on request by your account representative.

Use Usage Attribution for Detailed Insights

If you’re on an Enterprise plan, this feature is a powerful tool for enabling teams to investigate their own usage patterns independently.

Optimize Log Volume

Suppress Lambda START/END Logs

Lambda automatically generates START/END logs, but they provide minimal value. If you’re already using tracing, these logs are likely redundant. Excluding them can significantly reduce log volume, sometimes by more than half. This is effective whether you’re using Lambda Extensions or Datadog Forwarder for log transfer.

By suppressing logs on the client side, you can reduce subsequent ingestion processes downstream.

Avoid Indexing REPORT Logs

Lambda REPORT logs support enhanced metrics like duration calculations. However, once they’re ingested, they don’t need to be indexed. Consider excluding them from the log index to save costs, and also exclude them from the Sensitive Data Scanner for the same reason.

Use Tree Map Visualization to Analyze Log Volume

Leverage the Tree Map feature on the log screen to analyze log volume by category. You can group logs by multiple dimensions simultaneously, such as account, service, or host, for better insights.

![](../../assets/datadog-cost-reduction-tips-c2e34f0bba8b-01.png)

[https://docs.datadoghq.com/dashboards/widgets/treemap/](https://docs.datadoghq.com/dashboards/widgets/treemap/)

Explore Log Volume Using Metrics

![](../../assets/datadog-cost-reduction-tips-c2e34f0bba8b-02.png)

[https://docs.datadoghq.com/dashboards/querying/](https://docs.datadoghq.com/dashboards/querying/)

If you prefer metrics, the datadog.estimated_usage.logs.ingested_bytes metric can provide a clear visualization of log volume. A standout feature is Split Graphs, which allows you to break down graphs by category for better clarity and actionable insights.

Identify Unnecessary Log Patterns Using the Patterns Feature

![](../../assets/datadog-cost-reduction-tips-c2e34f0bba8b-03.png)

[https://docs.datadoghq.com/logs/explorer/analytics/patterns/](https://docs.datadoghq.com/logs/explorer/analytics/patterns/)

The Patterns feature is often overlooked. Leverage it to pinpoint unnecessary or anomalous log patterns. To optimize costs, prioritize addressing high-volume logs that provide little value.

Filter Logs by Status

A high volume of WARN or ERROR logs is a red flag. Address these logs to clean up your system and potentially identify opportunities for application improvements.

Check for Duplicate Log Outputs

Occasionally, logs are outputted twice. This is often due to a misconfiguration in Datadog. Investigating and fixing this can save unnecessary costs.

Implement Log Sampling

For repetitive or low-value logs, consider implementing sampling.

Trim Your Logs

Use abbreviations and cut down on spaces or symbols.

e.g., mapping AccountID to aid

Framework-generated logs often have a lot of bloat — perfect for optimization.

Avoid Polling and Preflight Requests

Eliminate unnecessary calls by understanding the flow from frontend to backend.

Reducing transfer volume not only minimizes Datadog Forwarder execution costs but also significantly lowers cloud data transfer expenses.

Optimize APM

Apply the same approach as log management.

Start with Visualization

See the sections above for actionable insights.

Exclude Low-Impact Proxy Services

For stable services with minimal insights, exclude them from APM monitoring to optimize data collection and save on costs.

Sample Detailed Trace

Choose between sampling entire traces or targeting specific access points. With DD_TRACE_SAMPLING_RULES, for instance, you can apply sampling specifically to database access traces.

Identify and Eliminate Duplicate Traces

Duplicate trace outputs can occur due to configuration errors in Datadog. Regularly audit and resolve these issues to avoid redundant costs.

Fix N+1 Query Issues

Avoiding N+1 queries is essential, as they can severely affect both performance and reliability while also driving up Datadog costs due to the increased number of spans.

Optimize Infrastructure Hosts

Exclude Unmonitored Resources from AWS Integration

Even EC2 hosts without the Datadog Agent are billed if they’re part of AWS Integration. If monitoring all EC2 instances isn’t necessary, exclude them from the AWS Integration settings. For setups with CloudWatch Metric Streams, additional steps are required. Remove EC2 from the namespace on AWS to stop data from being sent to Datadog.

Additional Usage Optimization

Reduce API Test Frequency

API Test Billing is based on execution frequency, so running tests every minute costs 60 times more than hourly tests. In development environments, longer intervals are often sufficient. Adjust the frequency according to workload demands. Costs also scale with the number of locations. Limiting tests to a single region, such as Northern Virginia, can be an effective cost-saving measure. Dynamic interval adjustments based on time of day would be helpful, but this isn’t a built-in feature. You can implement such functionality using the Datadog API for custom configurations.

Optimize Sensitive Data Scanner

Lambda logs, such as START, END, and REPORT logs, typically don’t contain sensitive data. Exclude these logs from scanning to reduce unnecessary cost.

Indexing and Sensitive Data Scanner require separate filter settings. If you want to apply exclusions collectively, you’ll need to exclude them from being sent on the client side.

Turn Off RUM Session Replay to Cut Costs If You Don’t Need It

RUM Premium, with its Session Replay feature, comes at a higher price than standard RUM.

If Session Replay isn’t part of your workflow, double-check that sessionReplaySampleRate is set to 0 to avoid unnecessary costs.

Conclusion

Datadog costs are closely tied to cloud costs. Look for solutions that can address both areas simultaneously for maximum efficiency.

This article is the English version of the original article written in Japanese, availablehere.

効率的な情報収集のポイント：見ないようにする

ask_yoshi_taka — Sun, 23 Feb 2025 09:24:19 GMT

現代人は情報の量は十分でも情報の多さや品質に困っている人が多いようです。

この状況を変えるには、良質なコンテンツを探すだけでは足りず、不要な情報をいかに避けるかがポイントです。

このとき重要な概念がシグナル/ノイズ(S/N)比です。良質なコンテンツを増やすだけでは効果が薄く、ノイズを削ることで効率が一気に上昇します

当記事では良質なコンテンツ(シグナル)の集め方ではなく、不要な情報(ノイズ)の避け方について記述します。前半は基本的な考え方を紹介し、後半は実際の手順を説明します。

注意力は貴重な資産です。他者に奪われないように自分でコントロールしましょう。

トレンド/ランキングは無視

トレンドやランキングはまず役に立ちません。

非プロフェッショナル層からの注目が集まっても価値が低い
同じ層でもクオリティの低い話ほど注目が集まりがち
みんな見るので差が生まれない

低い✕低いで時間の無駄です。専門誌サイトのランキングでも上位は低俗なものが上がることがあります。

たまに役に立つという声もあると思いますが、むしろたまに役に立つことが問題です。脳の報酬系的には毎回報酬がもらえるよりランダムなほうが夢中になるとよく言われるところです。

気合いで我慢するのは難しいので環境調整として非表示にしましょう。

転載サイトは無視

Yahooニュースに代表される転載サイトを見ても、結局出典にあたる必要があるので時間の無駄です。

コメント欄は無視

これは特に日本のネット環境が特にそうなのですがコンテンツに対するコメントの質が低すぎます。

そもそも目を通してすらいない人の感想を見ても無駄ですし、大喜利大会なら自分で主催したほうが楽しめます。そのコンテンツのマーケティングや広報をしていない限りは可能なら非表示にしたほうがよいです。

住んでいるところの最新交通情報はともかく、専門分野で背景不明のどこの誰かすら不明な人の感想を検証するのは時間がかかるだけです。

惰性で同じものを見るのを辞め、卒業する

世の中にはもっと面白いものがあります。なんとなくではなく目的意識を持ち、より良いものを探しましょう。よく見てるサイトや人がどのような位置づけか意識できるようになってくれば、その分野への習熟度が上がってきた証です。

最初は面白いことを言っていてもネタ切れで時事ネタばかりになるパターンもあります。卒業の季節です。

エンタメの連載もの、連続ものには注意が必要です。作成側は次の回の気を引くべくテクニックを駆使してきます。相手は気を引くプロです。飽きてきたら卒業しましょう。

論点を明確化できたら放置する

気になる議論があったとします。論外のコメントを除外したとしても、外から眺めていると途中で議論が堂々巡りになっていることがほとんどです。

いまはChatGPTもあり、賛成反対の論点の整理は簡単です。自分なりに整理できたあとは、決着しなかったり前に進まなかったりするようなら放置しましょう。

議論に参加したくなるかもしれませんが、コピーした意見が増えるだけで新しい価値が足せないなら時間がもったいないですね。

ネット時事にコメントしない

そのコメントすると新しい価値が生まれますか？前に進みますか？

いわゆる一丁噛みは時間がもったいないだけではなく、注意が意味不明な他人に奪われている証拠です。

1年後にその事象が価値あるか考えてみましょう。

情報収集と娯楽を分ける

今やっていることは情報収集でしょうか？娯楽でしょうか？情報収集のつもりがいつの間にか娯楽になってませんか？

情報収集中に誘惑が多すぎて娯楽となりあっという間に時間が溶けることは避けたいですね。

娯楽だと割り切ったとしても後で後悔するかどうか、明日もやりたいかどうかがポイントです。

例えば音楽が好きで演奏が楽しく、もっとやりたいと思うならどんどんやりましょう。漫画を読むのもそうです。

もし昨日を振り返ってこの時間が無駄だったと後悔するなら行動しましょう。もっと楽しいことは必ず見つかります。

無駄な情報を減らす環境を整備する方法(環境調整)

ここからは無駄な情報を減らす具体的な方法に入ります。

サイトやサービス側は注意力を奪う達人であり、何十億何百億円とお金と人材をかけています。いくら努力して見ないようにしても正面から戦っては勝てません。

注意を自分のものにするには事前の準備で決まります。我慢や努力ではなく、環境を整備することでネット時代に対応しましょう。

サイトの要素を非表示にする

見えなければ気になりません。

PCならuBlock Origin Liteが便利です。広告ブロックが主な機能ですが、右クリックから要素ごと非表示(ブロック)にする機能が有益です。

サイトごとブロックする

見ることすら無駄なサイトもあります。例えばBlockSiteを使えばうっかりクリックしてもブロックされ大丈夫です。

一つのツールだけにしたいならuBlock Origin Liteでページ丸ごと消すのも可能です。スマホの場合はやや難しいですがNextDNSあたりが無難です。

Google検索から非表示にするにはuBlacklistが便利です。Yahooニュースを消すとすっきりします。noteなどのコンテンツサイトも工夫すれば特定のユーザーだけ非表示にできます。

通知を消す

標準設定では通知が多めな傾向にあります。必要最小限に絞りましょう。通知ゼロでOKなことも。サイト側の設定か、PCやスマホの設定で消せます。

メール通知も消す

何もしないと各サイトがメールでおすすめを送ってくることがあります。クオリティが低いようならメール設定画面から送信停止しましょう。

送られてきたメールを毎回無視するのではなく元を断つ。地味な作業ですが効果的です。

Webサイトがあるアプリはアンインストールする

アプリのほうが便利なのは間違いないですが、その分注意力を奪われます。事業提供者側は摩擦(フリクション)を減らして使うハードルを下げ、たくさんの時間を使ってもらおうと一生懸命です。

ここは逆にハードルを上げて不便にしましょう。

また、前述の通りPCのほうがカスタマイズして不要なものを断てるため効果的です。

ChatGPTなど作業ツール系のアプリならそのまま使ってもらってOKです。

事例: Twitter ( X )

まずはトレンドやおすすめ欄をひたすら除去します。

![無駄を削ったあと](../../assets/efficient-information-gathering-avoid-noise-3be7cf70544f-01.png)

無駄を削ったあと

きりがなくとも目に付くユーザーをひたすらミュートしていきましょう。ちょっと不快ならすぐミュートぐらいでちょうどよいです。表示する義務はありません。流行りもの系はハッシュタグ付きが多いのでキーワードミュートで消せます。

フォローもどんどん外しましょう。フォローバックも義務ではありません。ネット有名人などをフォローするということは、結果的にその人の思想が自分の中に入っていくということです。その人の言動に似ていくということであり、本当にその人のようになりたいか判断しましょう。その人からしか取れない情報はありません。

ポストは面白くてもリポストがいまいちなタイプの人もいます。対象者のリポストをオフにする機能を使いましょう。

![bskyにも欲しい](../../assets/efficient-information-gathering-avoid-noise-3be7cf70544f-02.png)

bskyにも欲しい

ユーザーが多いだけあり、上位互換の優れた人は探せばいます。そのような人はフォロワーが少ない傾向にあります。

情報をただ転送しているだけな人の話はそのジャンルの入門フェーズ以外は避け、時が来たら卒業しましょう。(その後は実務家の実践だけを見ていくとよいです。)

タイムラインについて、「おすすめ」欄をしばらく眺めるのは良いのですが、見ている間にフォローしていない人が表示されたら切り替えの合図です。これ以上は見るだけ無駄というサインなので、「フォロー中」欄に切り替えるか他のことをしましょう。

標準設定ではメールをやたら送ってくるので設定を変更しましょう。

そもそも見る価値はあるのか

英語圏の多くの専門分野の専門家はBlueSkyに脱出してしまったので(e.g. IT, 学術)、あまり見る価値はありません。

日本を対象とした分野の専門家(e.g. 国内旅行)はまだXに多いので興味あるジャンル次第です。

全体的には衰退傾向にあり復活はないでしょう。

目的を決める

情報収集なのか、売り込みにつなげたいのか、不特定多数から注目を浴びたいのか。目的をはっきりさせ、目的に繋がらないことはやらないことでSNSを乗りこなすことができます。できなければSNSに乗りこなされます。

事例: YouTube

チャネルごと非表示にできるのは良い点です。最初はレコメンドがひどいので積極的に非表示にしましょう。ある程度こなすと安定してきます。

![興味なしは効果なし。チャネルごと消しましょう](../../assets/efficient-information-gathering-avoid-noise-3be7cf70544f-03.png)

興味なしは効果なし。チャネルごと消しましょう

コメント欄は非表示に。コメントが役に立ったことはありません。

![すっきり！YouTubeのコメントはコメント者の背景がわからないので地獄](../../assets/efficient-information-gathering-avoid-noise-3be7cf70544f.png)

すっきり！YouTubeのコメントはコメント者の背景がわからないので地獄

トップ画面のサイドバーも非表示にすると余計なトレンドなども消せます。

![平和なサイドバー](../../assets/efficient-information-gathering-avoid-noise-3be7cf70544f-05.png)

平和なサイドバー

さいごに

今やってることが生きがいなら問題ないのですが、時間を無駄にしたと後悔することがあるなら事前準備しましょう。

たかがネットに見えても、どれくらい1日に時間を使っているか測れば凄まじい量の時間を消化していることが見える時代です。

無駄を削ってもっと楽しいことをしましょう。

外部プラットフォームと内部プラットフォーム: そのリスクと方針

ask_yoshi_taka — Tue, 09 Jan 2024 05:50:12 GMT

ある程度組織が大きくなってくると、プラットフォームの必要性が叫ばれます。一方で、プラットフォームに関わったことがある人は少ないようです。

プラットフォームエンジニアリングは本当に必要なのでしょうか？

この記事ではプラットフォームで混同されがちな概念を説明し、(内部)プラットフォーム作成のヒントを解説します。

外部プラットフォームとは
内部プラットフォームとは
内部プラットフォームの典型例
プラットフォームのリスク
必要なのか？
立ち上げ方針

まずは混同されがちな外部プラットフォームと内部プラットフォームの違いからです。

外部プラットフォーム a.k.a プラットフォームビジネス

外部プラットフォームとはビジネス的なプラットフォームを指します。

Amazon.co.jpで探せるプラットフォームが題名にある書籍のほとんど、プラットフォームビジネスで出てくるほうです。エンジニア以外がプラットフォームと発話したらこれです。プラットフォームを提供する主体はプラットフォーマーと呼ばれます。よく外部にAPIを提供していますね。

プラットフォームを作ったときには想像もしていなかったようなことを、プラットフォームユーザーが生み出すことができます。新たなビジネスが生まれ、エコシステムができるかもしれません。

Amazon社のプラットフォームが有名です。フライホイールの図は見たことある人も多いでしょう。

プロフィットセンターであり、組織としては限界まで投資可能です。

ユーザーは組織外がほとんどです。顧客や協業先が代表的。

積極的に使ってもらうことに価値があり、そのためDevExやDevRelが効果的です。

ここのゲームプレイに関しては別稿に譲ります。

内部プラットフォーム≒プラットフォームエンジニアリング

いわゆる共通基盤です。組織内部のサービスを共通化することで無駄を省きます。内部のQCD改善が目標です。

コストセンターであり、どこまで投資するか難しい判断が求められます。(無駄をなくす目的なのにあまりにも多くの人員を割いたら本末転倒です。)

ユーザーはほぼ内部顧客です。組織内の別のサービスであることが多いでしょう。

Team Topologyのplatform team が扱うものです。DevExは欲しいところですが、現実的にはそこまで工数をかけられないでしょう。内部限定でありハイコンテキストを前提とすれば、完全なドキュメント等がなくても組織内でカバーできます。

内部プラットフォームの典型例

認証認可基盤ユーザー基盤決済基盤ログ基盤測定基盤などが代表的です。

開発生産性(development productivity)向上系のものもあります。CI/CD、IaCなど。

内部プラットフォームのリスク

「同じものが2つ以上あると非効率だから共通化しよう！」「今後必要になりそうだから共通化できそうなところを切り出しておこう！」

その通りなのですが、なかなかそううまくはいかない現実があります。

単一障害点になる

プロダクトAとプロダクトBが同期リクエスト形式で依存するプロダクトPがあるとして、プロダクトPが障害になったら全部障害です。

プロダクトAに高信頼性が求められるなら、プロダクトPはそれを遥かに上回る信頼性が必要です。

複雑化する

共通部分を切り出したら見落としがよくなるように見えます。しかし、長く時間経つとプラットフォーム側が複雑になり、見通しが悪化することがよくあります。特にビジネス優先（クライアント優先）だとプラットフォーム側にロジックを寄せることがありがちです。

クソコード動画「共通化の罠」 pic.twitter.com/MM750CNXc2
— ミノ駆動 (@MinoDriven){" "} May 12, 2019

{" "}

わかりやすい動画。サービスでも同じことが起きます

改修速度が落ちる

その領域に特化したチームを用意したのだから開発速度が上がりそうですが、悪化することはよくあります。

何につけても多数の影響範囲を確認しながら作業する必要があるからです。影響範囲が存在するならクライアント側それぞれの事情を加味して調整が必要です。特にクライアント側の対応が発生するときが一大プロジェクトになります。

純粋に開発速度で負けることもあります。ゴールデンイメージとしてAWSなどをラップしたものを作ったものの、その改善速度についていけないといったことです。大手プロバイダーとはその部分にアサインできる人数に差がありますね。IaCの社内共通モジュールが化石化しがちです。

外部の基盤に不足している機能を補うべくOSSや社内ツールが生まれ、外部基盤側が新バージョンでその機能を追加したので不要になるが、そのツールに依存してしまい乗り換えできず、新バージョンが使えなくなり非効率となるというサイクルを歴史的に見てここ数十年繰り返していますね。なにもしなかったらいつも最新バージョンが使えるので悲しいことです。

そしてソフトウエア開発において速度の悪化はコストや品質の悪化を招く要因の一つです。

優先順位がつけられない。不満がたまる

さまざまなクライアントからの改修要望についても優先順位をつけるのも大変で、優先順位を調整する作業だけでも工数が多くかかります。

優先順位をつけるメカニズム例として、話し合い方式、トークン方式、HiPPO方式、先着順、声が大きい人優先などがあります。

どうしてもクライアントのチームとは優先順位が異なるためプラットフォームに対する不満は増える一方です。

改修スケジュールが見えないので、結局クライアント側でその機能を作り、それが二重三重にもなることも。

(その機能要望ですか？最速で3年後に着手開始です)

共有地の悲劇

n+1や重いクエリのような非効率なプラットフォームを呼び出す処理があったとしても、各クライアントには改修する動機があまりありません。自分のチーム内なら確認するでしょうが、他チームはそもそも影響が見えないし見方もわからないでしょう。

そしてプラットフォームが障害になり、そのまま全プロダクトが大障害になることも。

プラットフォーム内はお互いに無関係

プラットフォーム内の各サービスについて、「共通」という部分は共通点がありますが、扱っているドメインはバラバラです。会社組織をバックオフィスでくくったとして法務と税務、HRやファイナンスはやることが違いすぎるでしょう。分類するときに「その他」になんでもかんでも放り投げているイメージです。

特にプラットフォーム部門で組織目標や方針を立てるときに影響します。

需要がない

新プロジェクトで必要な機能について、共通基盤側で作ると効率的に見えます。今後他のチームでも使うかもしれないですよね。

しかし、新プロジェクトが消滅したり、優先順位が変わることでその基盤部分が不要になることは時折あります。手を付けていれば残念ながら貴重な工数と特に時間を無駄にしたことになります。仮に1年延期だとしても一手無駄にしていますね。特にスタートアップだと厳しい状況に。

需要があるという仮説が検証されないまま作ってしまったプロダクトです。使う予定や使いたいという言葉と、実際に使っている状態では天と地ほどの差があります。

QCDが悪化

QCDを改善するはずが、長年経つとむしろQuality Cost Deliveryが悪化しているように外から見えます。遅い高いおいしくない状態です。

内部プラットフォームは必要なのか？

プラットフォームの存在意義で致命的なところは共通部分ということです。組織内部のサービスで共通ということは、組織の外部でも共通であり、トレンドを見渡せばコモディティ化が進みます。陳腐化済みのものを開発するメリットはありません。

特化した外部SaaSなら同じ領域でもプロフィットセンターとなり、プロダクトマネジメント、デザイン、DevExに投資できます。プロダクト品質にも差が出ます。

エンジニアの立場からすると、内部プラットフォームはすでに世の中にあるものを作るだけなので面白みに欠けることがあります。例えば決済に関心があれば決済のSaaSにいったほうが面白い問題に取り組めます。もしくは自分たちで新しくプロダクトを立ち上げるか。(そういうスタートアップもよく見かけます)

ただ、現在、プラットフォームを代替できるようなSaaSはコスト面で不利です。ユーザー数や利用量課金のため、最終的に自分たちで作成したほうが人件費を加味しても安くなる傾向にあります。

また、同様の機能が多数存在すると、セキュリティ、コンプライアンス面で効率が悪くリスクが高くなることは否めません。デザイン/UX面でも強い一貫性を保ちたいところです。

組織の規模がハイパースケーラーレベルなら外部SaaSより難しい問題にエンジニアが取り組めるかもしれません。残念ながら日本企業でそのレベルに到達できた企業は厳し目に見て存在しません。

もちろん適切に作成できた基盤は使い回しが容易でプロダクト立ち上げがスムーズになります。Meta社のThreadsが約5ヶ月でローンチしながら、高いスケーラビリティやセキュリティ、品質を担保できたことはプラットフォームがあるからこそです。

プラットフォームの立ち上げ方針

既存の主プロダクトからサービスを抽出し分離する

主プロダクトから抽出すれば、その部分は需要があることが既に証明されています。主プロダクトは肥大化しがちなので分離できるとお互いにメリットがあります。

人を集める

エンジニアリング難易度は高く、組織内で最高のアクセス量や高信頼性が求められます。そのような分野に関心がある方を募集しましょう。プラットフォームは関係者が多く調整も難しいですが、それを逆手に取って難易度が高いことを歓迎する人材がよいですね。

なるべくプロダクトとして扱う

せっかく作っても使われなかったら意味がありません。乗り換えのメリットを打ち出していきましょう。

通常のプロダクト同様、プロダクトマネジメントとして内部のドキュメント、デリバリ、マーケティング、ヒアリング、UX(DevEx)改善をしていきましょう。測定も忘れずに。工数は限られていますがここにも投資しましょう。

コピーアンドペーストの勝利(?)

内部でレジストリを作成してバージョン管理してコンポーネントを再利用できるようにする…というのは理想ですが、現実はクライアントはバージョンアップしませんしバージョン上げるとおかしくなるでしょう。(言語やフレームワークを常に最新化できている組織なら心配ありません。)

ライブラリやIaC周りはサンプルだけ提供して真似してもらうほうがよいです。個別に進化してもらい、フィードバックをもらい反映しましょう。

shadcnのようなイメージ。

本当に内部の需要が多いことが証明されたらコンポーネント化し、サービス化を狙っていくのもよいですね。

障害時の動作を検討する

中央集権型だと障害時に全滅するため、レプリケーションによる分散という方法もあります。一方、データ同期やstale cacheといった難しい問題が生まれます。

なるべくイベント型で非同期にしたほうが障害に強いものの、データ復旧といった部分には違った難しさがあります。

Everything fails

ということで分散システムでは必ず部分が壊れるため対応を検討しましょう。

リソース不足で要求に答えれないときは要求元からのレンタルを検討する

要求元が人員を貸し出し、要求先の一員として同じ基盤上に同じ開発スタイル、開発スタックで作成するとスムーズに進みます。 (Away Team)

Limitation

この記事ではPlatform Engineering自体は説明していません。チーム組成やKPIの難しさはプロダクトとはまた別にあります。

Conclusion

組織によってはエンジニアの数十パーセントがプラットフォームが占めることがあります。プラットフォーム自体が負債になりえるのでうまく計画しましょう。

マジックナンバー化による高速な曜日計算

ask_yoshi_taka — Mon, 24 Aug 2026 15:00:00 GMT

曜日を求めるアルゴリズムとして、Tomohiko Sakamotoの手法がよく知られています。

この記事では、対象年を1年から9999年に限定し、Sakamotoの計算に含まれる定数除算とmod 7を、乗算・シフト・ビット抽出に置き換えます。

Apple Silicon上でCのインライン・バッチ処理を測定したところ、通常のSakamoto実装に対して約30%の高速化を確認しました。

最初に完成した実装を紹介し、その後で定数5243と74899が機能する理由を説明します。

実装例

TypeScript

/** Returns 0=Sunday, ..., 6=Saturday.
 *
 * Preconditions:
 * - year: 1..9999
 * - month: 1..12
 * - day: 1..31
 */
const SCALED_MONTH_TERM = new Uint32Array([
  0, 224_697, 149_798, 374_495, 0, 224_697, 374_495, 74_899, 299_596, 449_394, 149_798, 299_596,
]);

export function weekdayBoundedDistributed(year: number, month: number, day: number): number {
  year -= Number(month < 3);

  const product = Math.imul(year, 5_243);
  const base = year + (year >>> 2) - (product >>> 19) + (product >>> 21) + day;

  return ((Math.imul(base, 74_899) + SCALED_MONTH_TERM[month - 1]) >>> 16) & 7;
}

TypeScriptでは、32-bit整数乗算を明示するためにMath.imulを使用しています。また、右シフトには符号なし右シフトの>>>を使用しています。

Rust

/// Returns 0=Sunday, ..., 6=Saturday.
///
/// Preconditions:
/// - year: 1..9999
/// - month: 1..12
/// - day: 1..31
#[inline]
pub fn weekday_bounded_distributed(
    mut year: u32,
    month: u32,
    day: u32,
) -> u32 {
    const SCALED_MONTH_TERM: [u32; 12] = [
        0, 224_697, 149_798, 374_495,
        0, 224_697, 374_495, 74_899,
        299_596, 449_394, 149_798, 299_596,
    ];

    year -= (month < 3) as u32;

    let product = year * 5_243;

    let base = year
        + (year >> 2)
        - (product >> 19)
        + (product >> 21)
        + day;

    (
        (
            base * 74_899 +
            SCALED_MONTH_TERM[(month - 1) as usize]
        ) >> 16
    ) & 7
}

C

#include <stdint.h>

/*
 * Returns 0=Sunday, ..., 6=Saturday.
 *
 * Preconditions:
 * - year: 1..9999
 * - month: 1..12
 * - day: 1..31
 */
static inline uint32_t weekday_bounded_distributed(
    uint32_t year,
    uint32_t month,
    uint32_t day
) {
    static const uint32_t scaled_month_term[12] = {
        0u, 224697u, 149798u, 374495u,
        0u, 224697u, 374495u, 74899u,
        299596u, 449394u, 149798u, 299596u
    };

    year -= month < 3;

    const uint32_t product = year * 5243u;

    const uint32_t base = year
        + (year >> 2)
        - (product >> 19)
        + (product >> 21)
        + day;

    return (
        (
            base * 74899u +
            scaled_month_term[month - 1]
        ) >> 16
    ) & 7u;
}

通常のSakamotoの手法

Sakamotoの手法では、次の月補正値を使用します。

0, 3, 2, 5, 0, 3, 5, 1, 4, 6, 2, 4

Cで書くと、基本形は次のようになります。

static uint32_t weekday_sakamoto(
    uint32_t year,
    uint32_t month,
    uint32_t day
) {
    static const uint8_t month_term[12] = {
        0, 3, 2, 5, 0, 3,
        5, 1, 4, 6, 2, 4
    };

    year -= month < 3;

    return (
        year
        + year / 4
        - year / 100
        + year / 400
        + month_term[month - 1]
        + day
    ) % 7;
}

1月と2月を前年の13月、14月に相当するものとして扱うため、month < 3の場合に年を1減らします。

その後、

year
+ floor(year / 4)
- floor(year / 100)
+ floor(year / 400)
+ month term
+ day

を計算し、7で割った余りを曜日とします。

Sakamotoの手法については、次の記事でも実装と考え方が紹介されています。

マジックナンバー化

今回の検討は、Falk Hüffner氏による次の記事をきっかけに始めました。

この記事では、入力範囲を限定することで、うるう年判定を乗算、マスク、比較による短い式へ変換しています。

同じように、曜日計算でも入力範囲を限定すれば、Sakamoto式の定数除算や剰余演算を短い整数演算へ変換できるのではないかと考えました。

今回の実装では、年を1以上9999以下に限定しています。

1月と2月について年を1減らした後でも、年の値は次の範囲に収まります。

0 <= year <= 9999

この限定範囲を利用して、次の二つの変換を行います。

const uint32_t product = year * 5243u;

product >> 19; // year / 100
product >> 21; // year / 400

さらに、Sakamoto式の中間値をvalueとすると、次の式でvalue % 7を求められます。

((value * 74899u) >> 16) & 7u

今回のポイントは、次の二つの定数です。

5243
74899

ただし、5243を使った0以上9999以下の整数の100除算は既知の最適化(strength reduction)です。

今回の実装では、同じ積year * 5243からyear / 100とyear / 400の両方を取り出しています。こちらについては後ほど説明します。

月補正値の分配

最初に作成した実装では、通常の月補正値を加えてから、全体を74899倍していました。

value =
    year_term
    + month_term[month - 1]
    + day;

weekday =
    ((value * 74899u) >> 16) & 7u;

これでも通常のSakamoto式より高速でしたが、月補正値の加算が最終乗算の前にあるため、計算の依存鎖に含まれます。

そこで、乗算の分配法則を使います。

(year term + month term + day) * 74899

= (year term + day) * 74899
  + month term * 74899

月補正値は12個しかないため、あらかじめ74899倍した値を保持できます。

通常の月補正値は次のとおりです。

0, 3, 2, 5, 0, 3, 5, 1, 4, 6, 2, 4

これを74899倍すると、次の値になります。

0, 224697, 149798, 374495,
0, 224697, 374495, 74899,
299596, 449394, 149798, 299596

この変形により、月補正値の加算を最終乗算の後へ移動できます。

Apple Silicon上のClangでは、この部分が積和命令を使ったコードへコンパイルされました。

月テーブルは12バイトから48バイトへ増えますが、年ごとのテーブルや曜日結果のテーブルを追加するわけではありません。一般的なPCやサーバーではキャッシュライン1本に収まる大きさです。メモリやコードサイズを優先する環境では、12バイトの通常月テーブルを使う分配前の実装も選択できます。

なぜ`5243`で100除算できるのか

補正後の年をyearとします。

対象範囲は次のとおりです。

0 <= year <= 9999

yearを次のように分解します。

year = 100 * q + r
0 <= r < 100

ここで、

5243 * 100
= 524300
= 2^19 + 12

です。

したがって、

5243 * year

= 5243 * (100 * q + r)

= 2^19 * q
  + 12 * q
  + 5243 * r

となります。

year <= 9999なので、q <= 99かつr <= 99です。

残りの部分の最大値は、

12 * 99 + 5243 * 99
= 520245
< 2^19

です。

つまり、12 * q + 5243 * rから19ビット目への桁上がりはありません。

そのため、

(year * 5243u) >> 19

は、対象範囲で常にyear / 100と一致します。

同じ積で400除算できる理由

今度はyearを次のように分解します。

year = 400 * q + r
0 <= r < 400

また、

5243 * 400
= 2097200
= 2^21 + 48

です。

したがって、

5243 * year

= 2^21 * q
  + 48 * q
  + 5243 * r

となります。

year <= 9999より、q <= 24かつr <= 399です。

残りの部分の最大値は、

48 * 24 + 5243 * 399
= 2093109
< 2^21

です。

したがって、21ビット目への桁上がりはありません。

そのため、

(year * 5243u) >> 21

は、対象範囲でyear / 400と一致します。

以上から、一度の乗算結果を共有して次の二つの値を取得できます。

const uint32_t product = year * 5243u;

const uint32_t century = product >> 19;
const uint32_t four_centuries = product >> 21;

なぜ`74899`で`mod 7`を計算できるのか

Sakamoto式の途中結果をvalueとします。

今回の入力範囲では、valueは次の範囲に収まります。

0 <= value < 13000

valueを次のように分解します。

value = 7 * q + r
0 <= r < 7

定数74899には、次の関係があります。

7 * 74899
= 8 * 2^16 + 5

また、

74899
= 2^16 + 9363

です。

これらを使って展開すると、

74899 * value

= 74899 * (7 * q + r)

= (8 * q + r) * 2^16
  + 5 * q
  + 9363 * r

となります。

value < 13000なので、q <= 1857です。

残りの部分の最大値は、

5 * 1857 + 9363 * 6
= 65463
< 2^16

です。

したがって、5 * q + 9363 * rから16ビット目への桁上がりはありません。

そのため、

(74899 * value) >> 16
= 8 * q + r

となります。

8 * qの下位3ビットは必ずゼロです。

したがって、下位3ビットを取り出せばrだけが残ります。

((value * 74899u) >> 16) & 7u

これは対象範囲でvalue % 7と一致します。

32-bit整数の範囲

この実装は、32-bit整数のオーバーフローを利用していません。

最初の積の最大値は次のとおりです。

9999 * 5243
= 52424757
< 2^32

最終段について、value < 13000という少し広い上限を使っても、

12999 * 74899
= 973612101
< 2^32

です。

したがって、すべての積は32-bit符号なし整数に収まります。

全入力での検証

今回のアルゴリズムは年1〜9999に限定しています。

そのため、対象となるすべての入力について、通常のSakamoto式と比較できます。

次はTypeScriptによる全件検証です。

const monthTerm = [0, 3, 2, 5, 0, 3, 5, 1, 4, 6, 2, 4] as const;

function weekdaySakamoto(year: number, month: number, day: number): number {
  year -= Number(month < 3);

  return (
    (year +
      Math.floor(year / 4) -
      Math.floor(year / 100) +
      Math.floor(year / 400) +
      monthTerm[month - 1] +
      day) %
    7
  );
}

for (let year = 1; year <= 9_999; year++) {
  for (let month = 1; month <= 12; month++) {
    for (let day = 1; day <= 31; day++) {
      const expected = weekdaySakamoto(year, month, day);

      const actual = weekdayBoundedDistributed(year, month, day);

      if (actual !== expected) {
        throw new Error(`mismatch: ${year}-${month}-${day}: ` + `${actual} !== ${expected}`);
      }
    }
  }
}

console.log("verified");

比較する入力数は次のとおりです。

9999 * 12 * 31
= 3,719,628

年1〜9999、月1〜12、日1〜31のすべてで、通常のSakamoto式との一致を確認しました。

日については各月の日数を考慮せず、すべて31日まで検証しています。したがって、実在する日付より広い入力集合で一致しています。

この関数自体は、4月31日のような実在しない日付を拒否しません。入力値が実在する日付かどうかの検証は、呼び出し側の責務です。

定数探索

今回採用した式の形について、定数とシフト量も探索しました。

100除算と400除算を同じ積から取得する次の形式では、

product = year * C;

year / 100 = product >> shift;
year / 400 = product >> (shift + 2);

年0〜9999の全域で成立する最小シフトは19でした。

その最小シフトにおける定数は、5243のみでした。

また、最終剰余の次の形式では、

((value * C) >> shift) & 7

valueの対象範囲全体で成立する最小シフトは16でした。

基本となる定数範囲内では、定数は74899のみでした。

これは、あくまで上記の式の形に限定した最小性です。

あらゆるプログラムやstraight-line expressionの中で、この実装が最適であることを意味するものではありません。

ベンチマーク

Apple Silicon上で、Clangの次の条件を使って測定しました。

-O3 -march=native

ランダムな年、月、日をあらかじめ配列へ格納し、それを繰り返し処理しています。

インライン・バッチ処理の結果は、おおむね次のとおりでした。

実装	時間
通常のSakamoto	約0.528 ns/件
最初のマジックナンバー版	約0.430 ns/件
月補正分配版	約0.370〜0.373 ns/件

通常のSakamoto実装に対する月補正分配版の改善率は、約29〜30%でした。

scalar呼び出しでも高速化を確認しましたが、改善率はインライン化の有無、関数呼び出しの方法、コンパイラが生成する命令列によって変わります。

また、Intel x86-64、Rust、Node.js、ブラウザJavaScriptなどでは、同じ改善率になるとは限りません。

掲載したRust版とTypeScript版については、通常のSakamoto式との全件一致を確認しています。性能値を比較する場合は、対象となるCPU、コンパイラ、JITごとに測定する必要があります。

先行研究と今回の位置づけ

5243による0以上9999以下の整数の100除算は既知のstrength reductionです。

例えば、整数から10進文字列への高速変換でも、次の形が使用されています。

(value * 5243) >> 19

したがって、定数5243自体を新しいものとして主張するものではありません。

また、2026年8月17日にBen Joffe氏が公開した次の記事では、7が2^3 - 1であることを利用し、限定範囲の剰余を乗算とシフトで求める原理が紹介されています。

今回の実装のポイントは、これらの考え方を年1〜9999に限定したSakamoto式へ適用し、次の一つの実装へまとめたことです。

同じ積year * 5243からyear / 100とyear / 400を取得する
定数74899によって最終的なmod 7を3ビット抽出へ変換する
月補正値を事前にスケーリングする
月補正の加算を依存鎖の後段へ移動する

同じ定数構成とSakamoto式への適用については、調査した範囲では先行例を確認できていません。

ただし、構成要素となる定数除算、strength reduction、限定範囲での剰余計算は既知の技法です。

まとめ

年を1〜9999に限定することで、Sakamotoの曜日計算に含まれる定数除算とmod 7を、乗算、シフト、ビット抽出へ置き換えられました。

主な変換は次の二つです。

const uint32_t product = year * 5243u;

product >> 19; // year / 100
product >> 21; // year / 400

((value * 74899u) >> 16) & 7u

さらに、月補正値をあらかじめ74899倍することで、月項を年計算から続く依存鎖の後段へ移動しました。

手元のApple Silicon環境では、Cのインライン・バッチ処理で通常のSakamoto実装より約30%高速になりました。

一方、この実装には年1〜9999という適用範囲があります。また、性能差はCPUやコンパイラ、JITによって変化します。

一般的なアプリケーションコードでは、読みやすく範囲制限のない通常のSakamoto式で十分です。今回の実装は、曜日計算がホットパスにあり、入力範囲が明確で、性能差を実測できる場合に向いています。

Faster Day-of-Week Calculation with Magic Numbers

ask_yoshi_taka — Mon, 24 Aug 2026 15:00:00 GMT

Tomohiko Sakamoto’s method is a well-known algorithm for calculating the day of the week of a given date.

This article restricts the supported year range to 1 through 9999 and replaces the constant divisions and modulo operation in Sakamoto’s calculation with multiplication, bit shifts, and bit extraction.

In an inlined batch benchmark written in C and run on Apple Silicon, this implementation was approximately 30% faster than the ordinary Sakamoto implementation.

I will first show the finished implementation and then explain why the constants 5243 and 74899 work.

Implementations

TypeScript

/** Returns 0=Sunday, ..., 6=Saturday.
 *
 * Preconditions:
 * - year: 1..9999
 * - month: 1..12
 * - day: 1..31
 */
const SCALED_MONTH_TERM = new Uint32Array([
  0, 224_697, 149_798, 374_495, 0, 224_697, 374_495, 74_899, 299_596, 449_394, 149_798, 299_596,
]);

export function weekdayBoundedDistributed(year: number, month: number, day: number): number {
  year -= Number(month < 3);

  const product = Math.imul(year, 5_243);

  const base = year + (year >>> 2) - (product >>> 19) + (product >>> 21) + day;

  return ((Math.imul(base, 74_899) + SCALED_MONTH_TERM[month - 1]) >>> 16) & 7;
}

The TypeScript implementation uses Math.imul to explicitly perform 32-bit integer multiplication. It also uses the unsigned right-shift operator >>>.

Rust

/// Returns 0=Sunday, ..., 6=Saturday.
///
/// Preconditions:
/// - year: 1..9999
/// - month: 1..12
/// - day: 1..31
#[inline]
pub fn weekday_bounded_distributed(
    mut year: u32,
    month: u32,
    day: u32,
) -> u32 {
    const SCALED_MONTH_TERM: [u32; 12] = [
        0, 224_697, 149_798, 374_495,
        0, 224_697, 374_495, 74_899,
        299_596, 449_394, 149_798, 299_596,
    ];

    year -= (month < 3) as u32;

    let product = year * 5_243;

    let base = year
        + (year >> 2)
        - (product >> 19)
        + (product >> 21)
        + day;

    (
        (
            base * 74_899 +
            SCALED_MONTH_TERM[(month - 1) as usize]
        ) >> 16
    ) & 7
}

C

#include <stdint.h>

/*
 * Returns 0=Sunday, ..., 6=Saturday.
 *
 * Preconditions:
 * - year: 1..9999
 * - month: 1..12
 * - day: 1..31
 */
static inline uint32_t weekday_bounded_distributed(
    uint32_t year,
    uint32_t month,
    uint32_t day
) {
    static const uint32_t scaled_month_term[12] = {
        0u, 224697u, 149798u, 374495u,
        0u, 224697u, 374495u, 74899u,
        299596u, 449394u, 149798u, 299596u
    };

    year -= month < 3;

    const uint32_t product = year * 5243u;

    const uint32_t base = year
        + (year >> 2)
        - (product >> 19)
        + (product >> 21)
        + day;

    return (
        (
            base * 74899u +
            scaled_month_term[month - 1]
        ) >> 16
    ) & 7u;
}

The ordinary Sakamoto method

Sakamoto’s method uses the following month offsets:

0, 3, 2, 5, 0, 3, 5, 1, 4, 6, 2, 4

A basic C implementation looks like this:

static uint32_t weekday_sakamoto(
    uint32_t year,
    uint32_t month,
    uint32_t day
) {
    static const uint8_t month_term[12] = {
        0, 3, 2, 5, 0, 3,
        5, 1, 4, 6, 2, 4
    };

    year -= month < 3;

    return (
        year
        + year / 4
        - year / 100
        + year / 400
        + month_term[month - 1]
        + day
    ) % 7;
}

January and February are treated as the thirteenth and fourteenth months of the previous year. Therefore, the year is decremented when month < 3.

The algorithm then evaluates:

year
+ floor(year / 4)
- floor(year / 100)
+ floor(year / 400)
+ month term
+ day

The remainder after division by seven is the day of the week.

The following page provides another explanation and implementation of Sakamoto’s method:

Replacing the divisions with magic numbers

This investigation was inspired by Falk Hüffner’s article:

That article restricts the input range and transforms leap-year testing into a short expression involving multiplication, masking, and comparison.

I wondered whether restricting the input range could similarly turn the constant divisions and remainder operation in Sakamoto’s formula into shorter integer operations.

This implementation supports years from 1 through 9999.

After decrementing the year for January and February, the adjusted year remains within the following range:

0 <= year <= 9999

This bounded range allows the following two transformations:

const uint32_t product = year * 5243u;

product >> 19; // year / 100
product >> 21; // year / 400

If value is the intermediate result of Sakamoto’s expression, value % 7 can also be calculated as follows:

((value * 74899u) >> 16) & 7u

The two important constants are therefore:

5243
74899

Using 5243 to replace division by 100 for inputs between 0 and 9999 is not new. It is a previously known optimization that replaces division by a constant with multiplication and a bit shift.

One published example is:

https://www.moria.us/blog/2023/01/optimizing-numtostring

The implementation in this article additionally obtains both year / 100 and year / 400 from the same product, year * 5243.

Distributing the month term

The first version of this implementation added the ordinary month term before multiplying the complete intermediate value by 74899.

value =
    year_term
    + month_term[month - 1]
    + day;

weekday =
    ((value * 74899u) >> 16) & 7u;

This was already faster than the ordinary Sakamoto implementation. However, the month-term addition remained in the dependency chain before the final multiplication.

The multiplication can be distributed:

(year term + month term + day) * 74899

= (year term + day) * 74899
  + month term * 74899

There are only twelve month terms, so their scaled values can be stored directly.

The ordinary month terms are:

0, 3, 2, 5, 0, 3, 5, 1, 4, 6, 2, 4

After multiplication by 74899, they become:

0, 224697, 149798, 374495,
0, 224697, 374495, 74899,
299596, 449394, 149798, 299596

This transformation moves the month-term addition after the final multiplication.

On Apple Silicon, Clang compiled this part of the C implementation into a multiply-add instruction.

The month table grows from 12 bytes to 48 bytes. On typical desktop and server processors, it still fits within a single cache line. In an environment where memory or code size is more important, the earlier implementation with the 12-byte unscaled month table can be used instead.

Why `5243` performs division by 100

Let year be the adjusted year.

Its range is:

0 <= year <= 9999

Write year as:

year = 100 * q + r
0 <= r < 100

We have:

5243 * 100
= 524300
= 2^19 + 12

Therefore:

5243 * year

= 5243 * (100 * q + r)

= 2^19 * q
  + 12 * q
  + 5243 * r

Because year <= 9999, both q <= 99 and r <= 99.

The largest possible value of the remaining terms is:

12 * 99 + 5243 * 99
= 520245
< 2^19

The expression 12 * q + 5243 * r therefore cannot carry into bit 19.

Consequently:

(year * 5243u) >> 19

is exactly equal to year / 100 throughout the supported range.

Why the same product performs division by 400

Now write year as:

year = 400 * q + r
0 <= r < 400

We have:

5243 * 400
= 2097200
= 2^21 + 48

Therefore:

5243 * year

= 2^21 * q
  + 48 * q
  + 5243 * r

Because year <= 9999, we have q <= 24 and r <= 399.

The largest possible value of the remaining terms is:

48 * 24 + 5243 * 399
= 2093109
< 2^21

These terms cannot carry into bit 21.

Consequently:

(year * 5243u) >> 21

is exactly equal to year / 400 throughout the supported range.

A single multiplication can therefore provide both quotients:

const uint32_t product = year * 5243u;

const uint32_t century = product >> 19;
const uint32_t four_centuries = product >> 21;

Why `74899` calculates `mod 7`

Let value be the intermediate result of Sakamoto’s expression.

Under the stated input conditions:

0 <= value < 13000

Write value as:

value = 7 * q + r
0 <= r < 7

The constant 74899 has the following properties:

7 * 74899
= 8 * 2^16 + 5

and:

74899
= 2^16 + 9363

Expanding the multiplication gives:

74899 * value

= 74899 * (7 * q + r)

= (8 * q + r) * 2^16
  + 5 * q
  + 9363 * r

Because value < 13000, we have q <= 1857.

The largest possible value of the remaining terms is:

5 * 1857 + 9363 * 6
= 65463
< 2^16

The expression 5 * q + 9363 * r therefore cannot carry into bit 16.

Consequently:

(74899 * value) >> 16
= 8 * q + r

The lowest three bits of 8 * q are always zero. Extracting the lowest three bits therefore leaves only r:

((value * 74899u) >> 16) & 7u

This is exactly equal to value % 7 throughout the supported range.

No 32-bit overflow is required

This implementation does not depend on 32-bit integer overflow.

The largest first product is:

9999 * 5243
= 52424757
< 2^32

Using the slightly wider bound value < 13000, the largest final product is:

12999 * 74899
= 973612101
< 2^32

All products fit within an unsigned 32-bit integer.

Exhaustive verification

Because the supported year range is finite, every input in the stated domain can be compared with the ordinary Sakamoto implementation.

The following TypeScript program performs the exhaustive comparison:

const MONTH_TERM = [0, 3, 2, 5, 0, 3, 5, 1, 4, 6, 2, 4] as const;

function weekdaySakamoto(year: number, month: number, day: number): number {
  year -= Number(month < 3);

  return (
    (year +
      Math.floor(year / 4) -
      Math.floor(year / 100) +
      Math.floor(year / 400) +
      MONTH_TERM[month - 1] +
      day) %
    7
  );
}

for (let year = 1; year <= 9_999; year++) {
  for (let month = 1; month <= 12; month++) {
    for (let day = 1; day <= 31; day++) {
      const expected = weekdaySakamoto(year, month, day);

      const actual = weekdayBoundedDistributed(year, month, day);

      if (actual !== expected) {
        throw new Error(`mismatch: ${year}-${month}-${day}: ` + `${actual} !== ${expected}`);
      }
    }
  }
}

console.log("verified");

The number of compared inputs is:

9999 * 12 * 31
= 3,719,628

The optimized implementation matched the ordinary Sakamoto formula for every year from 1 through 9999, every month from 1 through 12, and every day from 1 through 31.

The test deliberately checks every day through 31 without considering the actual length of each month. It therefore verifies a larger input set than the set of valid calendar dates.

The function itself does not reject nonexistent dates such as April 31. Date validation remains the caller’s responsibility.

Searching for the constants

I also searched the constants and shift amounts for the expression forms used by this implementation.

For the shared-product form:

product = year * C;

year / 100 = product >> shift;
year / 400 = product >> (shift + 2);

the smallest shift that works for every year from 0 through 9999 is 19.

At that shift, 5243 is the only valid constant.

For the final remainder form:

((value * C) >> shift) & 7

the smallest shift that works throughout the required intermediate-value range is 16.

Within the fundamental multiplier range, 74899 is the only valid constant.

These are conditional minimality results. They apply to the two expression forms above and do not prove that this program is optimal among all possible straight-line programs.

I also tested more aggressive forms that attempted to directly combine the year and month/day terms into one multiply-shift expression, but did not find a solution in the searched expression families.

Benchmark

The C benchmark was run on Apple Silicon with Clang using:

-O3 -march=native

Random years, months, and days were generated in advance and repeatedly processed from arrays.

The approximate inlined batch results were:

Implementation	Time
Ordinary Sakamoto	0.528 ns/item
Initial magic-number version	0.430 ns/item
Distributed month-term version	0.370–0.373 ns/item

The distributed version was approximately 29–30% faster than the ordinary Sakamoto implementation in this benchmark.

The scalar version was also faster, although the improvement depends on inlining, calling conventions, compiler decisions, and the generated instruction sequence.

The same percentage should not be assumed for Intel x86-64, Rust, Node.js, or browser JavaScript. The Rust and TypeScript implementations shown above were exhaustively verified for correctness, but performance should be measured independently on the target CPU, compiler, or JavaScript engine.

Prior work and the scope of this result

Replacing division by 100 with multiplication by 5243 and a right shift is a known optimization for inputs between 0 and 9999.

For example, the following expression appears in work on fast integer-to-decimal conversion:

(value * 5243) >> 19

See:

The constant 5243 and the division-by-100 transformation are therefore not new.

On August 17, 2026, Ben Joffe published an article describing how the fact that seven equals 2^3 - 1 can be used to calculate a bounded remainder using multiplication and shifts:

The general idea of replacing bounded constant division and remainder operations with multiplication and shifts is also established work.

The contribution of the implementation in this article is the particular specialization of these ideas to Sakamoto’s formula for years 1 through 9999:

obtain both year / 100 and year / 400 from the same product, year * 5243;
convert the final mod 7 into a three-bit extraction using 74899;
pre-scale the month terms;
move the month-term addition out of the critical dependency chain.

I did not find an earlier implementation using this same combination of constants and transformations for Sakamoto’s algorithm. This is not, however, a claim that the underlying multiplication-and-shift techniques are new.

Conclusion

By restricting the supported year range to 1 through 9999, the constant divisions and final mod 7 in Sakamoto’s day-of-week calculation can be replaced with multiplication, shifts, and bit extraction.

The two central transformations are:

const uint32_t product = year * 5243u;

product >> 19; // year / 100
product >> 21; // year / 400

and:

((value * 74899u) >> 16) & 7u

Pre-scaling the month terms additionally moves the month-term addition out of the critical dependency chain.

On my Apple Silicon system, the C implementation was approximately 30% faster than the ordinary Sakamoto implementation in an inlined batch benchmark.

The implementation has an explicit year range of 1 through 9999, and performance depends on the CPU, compiler, JIT, and surrounding code.

For most application code, the ordinary Sakamoto formula is simpler and sufficiently fast. This bounded implementation is most appropriate when day-of-week calculation is on a hot path, the input range is known, and the performance benefit has been measured on the target system.

This article is the English version of the original article written in Japanese, available here.

A Faster days_from_civil Using Magic-Number Division

ask_yoshi_taka — Wed, 26 Aug 2026 12:51:20 GMT

Howard Hinnant’s days_from_civil is a well-known algorithm for converting a civil year, month, and day into a day count relative to the Unix epoch.

This article restricts the input years to 1 through 9999 and replaces the /400, /100, /4, and /5 operations in days_from_civil with two independent 32-bit integer multiplications, shifts, and a 12-element lookup table.

In inline batch benchmarks on Apple Silicon, the bounded implementation reduced execution time by approximately 37–80% compared with the usual Hinnant implementation across Bun, Rust, and C in the tested environment.

We will start with the complete implementations, then explain why 1461 combines the common-year and four-year terms, why 5243 implements both /100 and /400, and how the epoch offset is folded into the month table.

Implementations

The preconditions are:

year: 1..9999
month: 0..11, where 0 is January
day: 1..31

These functions do not validate whether the date actually exists. For example, February 31 is accepted as an arithmetic input.

TypeScript

const EPOCH_MONTH_TABLE = new Int32Array([
  -719_163, -719_132, -719_469, -719_438,
  -719_408, -719_377, -719_347, -719_316,
  -719_285, -719_255, -719_224, -719_194,
]);

/** Returns days since 1970-01-01. */
export function ymdToEpochDays(
  year: number,
  month: number,
  day: number,
): number {
  const adjustedYear = year - (month <= 1 ? 1 : 0);
  const centuryProduct = Math.imul(adjustedYear, 5_243);

  return (
    (Math.imul(adjustedYear, 1_461) >>> 2) -
    (centuryProduct >>> 19) +
    (centuryProduct >>> 21) +
    EPOCH_MONTH_TABLE[month] +
    day
  );
}

TypeScript uses Math.imul to request 32-bit integer multiplication explicitly. All shifted values are nonnegative under the preconditions, so unsigned right shift, >>>, is used.

Rust

const EPOCH_MONTH_TABLE: [i32; 12] = [
    -719_163, -719_132, -719_469, -719_438,
    -719_408, -719_377, -719_347, -719_316,
    -719_285, -719_255, -719_224, -719_194,
];

/// Returns days since 1970-01-01.
///
/// Preconditions:
/// - year: 1..=9999
/// - month: 0..=11
/// - day: 1..=31
#[inline]
pub fn ymd_to_epoch_days(year: u32, month: u32, day: u32) -> i32 {
    let adjusted_year = year - u32::from(month <= 1);
    let century_product = adjusted_year * 5_243;

    ((adjusted_year * 1_461) >> 2) as i32
        - (century_product >> 19) as i32
        + (century_product >> 21) as i32
        + EPOCH_MONTH_TABLE[month as usize]
        + day as i32
}

C

#include <stdint.h>

/*
 * Returns days since 1970-01-01.
 *
 * Preconditions:
 * - year: 1..9999
 * - month: 0..11
 * - day: 1..31
 */
static inline int32_t ymd_to_epoch_days(
    uint32_t year,
    uint32_t month,
    uint32_t day
) {
    static const int32_t epoch_month_table[12] = {
        -719163, -719132, -719469, -719438,
        -719408, -719377, -719347, -719316,
        -719285, -719255, -719224, -719194
    };

    const uint32_t adjusted_year = year - (month <= 1u);
    const uint32_t century_product = adjusted_year * 5243u;

    return (int32_t)((adjusted_year * 1461u) >> 2)
        - (int32_t)(century_product >> 19)
        + (int32_t)(century_product >> 21)
        + epoch_month_table[month]
        + (int32_t)day;
}

The Usual `days_from_civil`

Howard Hinnant’s implementation, adapted to zero-based months, can be written as follows:

function daysFromCivil(year: number, month: number, day: number): number {
  year -= month <= 1 ? 1 : 0;

  const era = Math.floor(year / 400);
  const yearOfEra = year - era * 400;
  const marchMonth = month + (month > 1 ? -2 : 10);
  const dayOfYear =
    Math.floor((153 * marchMonth + 2) / 5) + day - 1;
  const dayOfEra =
    yearOfEra * 365 +
    Math.floor(yearOfEra / 4) -
    Math.floor(yearOfEra / 100) +
    dayOfYear;

  return era * 146_097 + dayOfEra - 719_468;
}

January and February are treated as the final two months of the preceding computational year. This moves the leap day to the end of that year. The calculation then splits the date into a 400-year era, a year within the era, and a day counted from March 1.

The Transformations

There are three main transformations.

First, the common-year contribution and the /4 leap-year contribution are combined:

Math.imul(adjustedYear, 1_461) >>> 2

Second, /100 and /400 are obtained from one shared product:

const product = Math.imul(adjustedYear, 5_243);

product >>> 19; // adjustedYear / 100
product >>> 21; // adjustedYear / 400

Third, the month contribution, -1, and the Unix epoch offset are folded into one lookup table.

The number of days before each month has only 12 possible values, so (153 * month + 2) / 5 is replaced with a lookup table.

const EPOCH_MONTH_TABLE = new Int32Array([
  -719_163, -719_132, -719_469, -719_438,
  -719_408, -719_377, -719_347, -719_316,
  -719_285, -719_255, -719_224, -719_194,
]);

Combining the 365-Day and Four-Year Terms

The year contribution begins with:

365 * adjustedYear + floor(adjustedYear / 4)

Since 1461 = 4 * 365 + 1:

floor(1461 * adjustedYear / 4)
= 365 * adjustedYear + floor(adjustedYear / 4)

The input is nonnegative, so the division by four becomes an unsigned shift:

Math.imul(adjustedYear, 1_461) >>> 2

This replaces a multiplication, an independent shift, and their addition with one multiplication followed by a shift.

Folding the Epoch Offset into the Month Table

The original tail of the expression is:

DOY_TABLE[month] + day - 1 - 719468

The constant terms can be precomputed for each month:

EPOCH_MONTH_TABLE[month]
= DOY_TABLE[month] - 719469

The runtime expression then becomes only:

EPOCH_MONTH_TABLE[month] + day

For example, January uses 306 - 719469 = -719163. The table remains 48 bytes; only its values change.

Why `5243` Implements Division by 100

After the January/February adjustment, the range is:

0 <= adjustedYear <= 9999

Write the adjusted year as:

adjustedYear = 100q + r
0 <= r < 100

We have:

5243 * 100
= 524300
= 2^19 + 12

Therefore:

5243 * adjustedYear
= 2^19 * q + 12q + 5243r

Within the input range, q <= 99 and r <= 99. The maximum value of the remaining part is:

12 * 99 + 5243 * 99
= 520245
< 2^19

It cannot carry into bit 19. Consequently:

Math.imul(adjustedYear, 5243) >>> 19

is exactly floor(adjustedYear / 100) throughout the bounded range.

Why the Same Product Implements Division by 400

Now write:

adjustedYear = 400q + r
0 <= r < 400

We also have:

5243 * 400
= 2097200
= 2^21 + 48

Thus:

5243 * adjustedYear
= 2^21 * q + 48q + 5243r

Here q <= 24 and r <= 399. The maximum remaining part is:

48 * 24 + 5243 * 399
= 2093109
< 2^21

It cannot carry into bit 21. Therefore:

Math.imul(adjustedYear, 5243) >>> 21

is exactly floor(adjustedYear / 400) throughout the range.

One multiplication can consequently be shared:

const product = Math.imul(adjustedYear, 5243);
const century = product >>> 19;
const era = product >>> 21;

Replacing the Month Division with a Table

The March-based calendar uses:

floor((153 * marchMonth + 2) / 5)

marchMonth has only 12 possible values. Expanded and reordered for zero-based Gregorian months, those values are:

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
306 337   0  31  61  92 122 153 184 214 245 275

The lookup replaces the month adjustment branch, multiplication, addition, and /5. The final implementation additionally stores each value after subtracting 719469, folding both the Unix epoch offset and the day-index correction into the same table.

The table occupies 48 bytes. That is small on ordinary PCs and servers, but the relative performance of a table and arithmetic can still depend on cold-cache behavior, code size, bounds checks, and JIT optimization.

32-Bit Integer Bounds

Using the inclusive upper bound of 9999, the largest products are:

9999 * 5243
= 52424757
< 2^31

9999 * 1461
= 14608539
< 2^31

The TypeScript implementation therefore does not wrap a signed 32-bit Math.imul result.

All intermediate values fit comfortably in 32 bits. Across the complete specified input set, the output range was:

-719162 <= result <= 2932896

Exhaustive Verification

Every input in the bounded domain was compared with the usual Hinnant implementation:

for (let year = 1; year <= 9_999; year++) {
  for (let month = 0; month < 12; month++) {
    for (let day = 1; day <= 31; day++) {
      const expected = daysFromCivil(year, month, day);
      const actual = ymdToEpochDays(year, month, day);

      if (actual !== expected) {
        throw new Error(
          `mismatch: ${year}-${month}-${day}: ` +
          `${actual} !== ${expected}`,
        );
      }
    }
  }
}

The number of comparisons was:

9999 * 12 * 31
= 3,719,628

The TypeScript, Rust, and C implementations all matched across the complete set.

The test intentionally checks every day through 31 without accounting for the actual length of each month. It therefore includes nonexistent dates such as February 31. The conversion remains arithmetically consistent, but callers are responsible for validating real civil dates.

Benchmarks

The benchmarks were run on Apple Silicon ARM64. Each implementation processed a pre-generated array of 2^20 dates 32 times. The input position was rotated between rounds to prevent an optimizer from hoisting an identical loop.

Inputs were generated with a deterministic pseudorandom sequence over:

year: 1..9999
month: 0..11
day: 1..28

The best result from seven trials was recorded. The toolchain was:

Bun 1.4.0
rustc 1.96.0 -C opt-level=3 -C target-cpu=native
Apple clang 21.0.0 -O3 -march=native

Results:

Environment	Usual Hinnant	Bounded version	Time reduction	Throughput
Bun	14.738 ns/item	3.018 ns/item	79.5%	4.88x
Rust	2.001 ns/item	1.192 ns/item	40.4%	1.68x
C	1.923 ns/item	1.205 ns/item	37.3%	1.60x

The effect is especially large in Bun, where ordinary floating-point division plus Math.floor is replaced with Math.imul and shifts.

C and Rust compilers can already lower division by constants to multiplication and shifts. Even so, combining the 365-day and /4 terms, sharing one product between /100 and /400, and folding the remaining constants into the month table reduced execution time by about 37–40% in this environment.

These results apply to one CPU, compiler/JIT version, and input distribution. Intel x86-64, other Apple Silicon generations, Node.js/V8, browsers, and different Rust or Clang versions may produce different results.

Prior Work and Positioning

This implementation is based on Howard Hinnant’s days_from_civil. Strength reduction from division by constants to multiplication and shifts is also well established.

Division by 100 using 5243 over integers from 0 through 9999 is itself known:

(value * 5243) >> 19

The construction here applies the bounded shared-product technique from the earlier article, “A Faster Day-of-Week Calculation Using Magic Numbers,” to days_from_civil.

The relevant combination is:

obtain /100 and /400 from the same adjustedYear * 5243 product;
combine 365 * adjustedYear + floor(adjustedYear / 4) as floor(1461 * adjustedYear / 4);
replace the March-based month expression with a 12-element table that also contains the epoch offset;
use explicit Math.imul and unsigned shifts in JavaScript; and
complete the calculation in 32 bits by restricting years to 1..9999.

Neri and Schneider systematically study multiplication-and-shift Gregorian calendar conversion and dependency-chain reduction through Euclidean affine functions. The individual ingredients and the general optimization strategy are therefore not claimed as new.

Within the public implementations examined, however, I did not find the same bounded days_from_civil construction combining the 1461 year product, one 5243 product for both /100 and /400, and this epoch-adjusted month table.

This does not establish optimality across all expressions, languages, CPUs, or input domains. It is a target-specific optimization for a clearly bounded year range.

The Inverse Conversion

This article covers days_from_civil, which converts a year, month, and day into a serial day number. The inverse operation is normally called civil_from_days:

civil date -- days_from_civil --> serial day
civil date <-- civil_from_days --- serial day

Although the two functions are inverses, their optimization structures differ substantially. civil_from_days must recover the era, year, month, and day from one integer, and it uses different divisions, corrections, and magic constants. It is therefore best treated separately.

Summary

Restricting the year to 1..9999 allows the constant divisions in Hinnant-style days_from_civil to be replaced with two independent multiplications and shifts.

The central transformations are:

Math.imul(adjustedYear, 1_461) >>> 2;

const centuryProduct = Math.imul(adjustedYear, 5_243);

centuryProduct >>> 19; // adjustedYear / 100
centuryProduct >>> 21; // adjustedYear / 400

and:

EPOCH_MONTH_TABLE[month] + day;

In the Apple Silicon benchmarks reported here, the bounded version reduced execution time by approximately 80% in Bun and 37–40% in Rust and C compared with the usual Hinnant implementation.

For ordinary application code, the clearer and broadly ranged days_from_civil is generally sufficient. This bounded implementation is intended for cases where civil-date conversion is on a hot path, the input range is guaranteed, and the performance difference has been measured on the target environment.

References

Howard Hinnant, chrono-Compatible Low-Level Date Algorithms
Cassio Neri and Lorenz Schneider, Euclidean Affine Functions and Applications to Calendar Algorithms
Cassio Neri, EAF supplementary material
A Faster Day-of-Week Calculation Using Magic Numbers

マジックナンバー化による高速な days_from_civil

ask_yoshi_taka — Wed, 26 Aug 2026 12:51:20 GMT

年月日をUnix epochからの通算日へ変換する方法として、Howard Hinnantの days_from_civil がよく知られています。

この記事では対象年を1年から9999年に限定し、days_from_civil に含まれる /400、/100、/4、/5 を、互いに独立した二つの32-bit整数乗算、シフト、12要素のテーブルに置き換えます。

Apple Silicon上でBun、Rust、Cのインライン・バッチ処理を測定したところ、通常のHinnant実装に対して、今回の環境では約37〜80%の実行時間短縮を確認しました。

最初に完成した実装を示し、その後で 1461 が平年項と4年項をまとめられる理由、定数 5243 が /100 と /400 の両方に使える理由、epochオフセットを月テーブルへ畳み込む方法を説明します。

実装例

前提は次のとおりです。

year: 1..9999
month: 0..11（0が1月）
day: 1..31

この関数は日付の妥当性を検証しません。たとえば2月31日も計算できます。

TypeScript

const EPOCH_MONTH_TABLE = new Int32Array([
  -719_163, -719_132, -719_469, -719_438,
  -719_408, -719_377, -719_347, -719_316,
  -719_285, -719_255, -719_224, -719_194,
]);

/** Returns days since 1970-01-01. */
export function ymdToEpochDays(
  year: number,
  month: number,
  day: number,
): number {
  const adjustedYear = year - (month <= 1 ? 1 : 0);
  const centuryProduct = Math.imul(adjustedYear, 5_243);

  return (
    (Math.imul(adjustedYear, 1_461) >>> 2) -
    (centuryProduct >>> 19) +
    (centuryProduct >>> 21) +
    EPOCH_MONTH_TABLE[month] +
    day
  );
}

TypeScriptでは32-bit整数乗算を明示するために Math.imul を使います。対象値は常に非負なので、右シフトには符号なしの >>> を使用しています。

Rust

const EPOCH_MONTH_TABLE: [i32; 12] = [
    -719_163, -719_132, -719_469, -719_438,
    -719_408, -719_377, -719_347, -719_316,
    -719_285, -719_255, -719_224, -719_194,
];

/// Returns days since 1970-01-01.
///
/// Preconditions:
/// - year: 1..=9999
/// - month: 0..=11
/// - day: 1..=31
#[inline]
pub fn ymd_to_epoch_days(year: u32, month: u32, day: u32) -> i32 {
    let adjusted_year = year - u32::from(month <= 1);
    let century_product = adjusted_year * 5_243;

    ((adjusted_year * 1_461) >> 2) as i32
        - (century_product >> 19) as i32
        + (century_product >> 21) as i32
        + EPOCH_MONTH_TABLE[month as usize]
        + day as i32
}

C

#include <stdint.h>

/*
 * Returns days since 1970-01-01.
 *
 * Preconditions:
 * - year: 1..9999
 * - month: 0..11
 * - day: 1..31
 */
static inline int32_t ymd_to_epoch_days(
    uint32_t year,
    uint32_t month,
    uint32_t day
) {
    static const int32_t epoch_month_table[12] = {
        -719163, -719132, -719469, -719438,
        -719408, -719377, -719347, -719316,
        -719285, -719255, -719224, -719194
    };

    const uint32_t adjusted_year = year - (month <= 1u);
    const uint32_t century_product = adjusted_year * 5243u;

    return (int32_t)((adjusted_year * 1461u) >> 2)
        - (int32_t)(century_product >> 19)
        + (int32_t)(century_product >> 21)
        + epoch_month_table[month]
        + (int32_t)day;
}

通常の `days_from_civil`

Howard Hinnantの実装を、0始まりの月へ合わせて書くと次のようになります。

function daysFromCivil(year: number, month: number, day: number): number {
  year -= month <= 1 ? 1 : 0;

  const era = Math.floor(year / 400);
  const yearOfEra = year - era * 400;
  const marchMonth = month + (month > 1 ? -2 : 10);
  const dayOfYear =
    Math.floor((153 * marchMonth + 2) / 5) + day - 1;
  const dayOfEra =
    yearOfEra * 365 +
    Math.floor(yearOfEra / 4) -
    Math.floor(yearOfEra / 100) +
    dayOfYear;

  return era * 146_097 + dayOfEra - 719_468;
}

1月と2月を前年の末尾として扱うことで、うるう日を計算年の最後へ移します。その後、400年周期、周期内の年、3月から数えた年内日へ分解します。

今回の変形

最適化は大きく三つです。

まず、平年の日数と /4 のうるう年項をまとめます。

Math.imul(adjustedYear, 1_461) >>> 2

次に、一度の乗算から /100 と /400 の両方を取得します。

const product = Math.imul(adjustedYear, 5_243);

product >>> 19; // adjustedYear / 100
product >>> 21; // adjustedYear / 400

最後に、月項、-1、Unix epochオフセットを一つのテーブルへ畳み込みます。月初までの日数は12通りしかないため、(153 * month + 2) / 5 も同時にテーブルへ置き換えられます。

const EPOCH_MONTH_TABLE = new Int32Array([
  -719_163, -719_132, -719_469, -719_438,
  -719_408, -719_377, -719_347, -719_316,
  -719_285, -719_255, -719_224, -719_194,
]);

365日項と4年項を一つにする

年に関する先頭部分は次の形です。

365 * adjustedYear + floor(adjustedYear / 4)

1461 = 4 * 365 + 1 なので、

floor(1461 * adjustedYear / 4)
= 365 * adjustedYear + floor(adjustedYear / 4)

となります。入力は非負なので、4除算は符号なし右シフトにできます。

Math.imul(adjustedYear, 1_461) >>> 2

これにより、乗算、独立したシフト、その加算を、一つの乗算とシフトへ置き換えられます。

epochオフセットを月テーブルへ畳み込む

元の式の末尾は次の形です。

DOY_TABLE[month] + day - 1 - 719468

月ごとに変わらない定数部分をあらかじめ計算します。

EPOCH_MONTH_TABLE[month]
= DOY_TABLE[month] - 719469

実行時の末尾は次だけになります。

EPOCH_MONTH_TABLE[month] + day

たとえば1月は 306 - 719469 = -719163 です。テーブルの大きさは48バイトのままで、格納する値だけが変わります。

なぜ `5243` で100除算できるのか

1月と2月の調整後も、年は次の範囲です。

0 <= adjustedYear <= 9999

少し広く adjustedYear <= 9999 として証明します。

adjustedYear = 100q + r
0 <= r < 100

また、

5243 * 100
= 524300
= 2^19 + 12

なので、

5243 * adjustedYear
= 2^19 * q + 12q + 5243r

です。対象範囲では q <= 99、r <= 99 であり、余分な部分の最大値は、

12 * 99 + 5243 * 99
= 520245
< 2^19

となります。19ビット目への桁上がりがないため、

(Math.imul(adjustedYear, 5243) >>> 19)

は対象範囲で常に floor(adjustedYear / 100) と一致します。

同じ積で400除算できる理由

今度は、

adjustedYear = 400q + r
0 <= r < 400

とします。

5243 * 400
= 2097200
= 2^21 + 48

なので、

5243 * adjustedYear
= 2^21 * q + 48q + 5243r

です。q <= 24、r <= 399 より、余分な部分は最大でも、

48 * 24 + 5243 * 399
= 2093109
< 2^21

です。したがって、

(Math.imul(adjustedYear, 5243) >>> 21)

は対象範囲で常に floor(adjustedYear / 400) と一致します。

以上から、一度の乗算結果を共有できます。

const product = Math.imul(adjustedYear, 5243);
const century = product >>> 19;
const era = product >>> 21;

月の除算をテーブルへ置き換える

March-based calendarで使われる月項は次の式です。

floor((153 * marchMonth + 2) / 5)

marchMonth は 0..11 の12値しか取りません。元の0始まり月へ対応させて展開すると、

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
306 337   0  31  61  92 122 153 184 214 245 275

です。

このテーブルにより、月の分岐、乗算、加算、/5 を一つのテーブル読み出しへ置き換えられます。最終実装ではさらに各値から 719469 を引き、Unix epochオフセットと日番号の補正も同じテーブルへ畳み込んでいます。

テーブルは48バイトです。一般的なPCでは小さいですが、cold cache、コードサイズ、bounds check、JITの扱いによって算術式との性能関係は変わります。

32-bit整数の範囲

広い上限 9999 を使った二つの積の最大値は、

9999 * 5243
= 52424757
< 2^31

9999 * 1461
= 14608539
< 2^31

です。したがって、TypeScriptの Math.imul で符号付き32-bitの折り返しは発生しません。

その他の中間値も32-bit整数へ十分収まります。最終結果は、指定された入力集合で次の範囲でした。

-719162 <= result <= 2932896

全入力での検証

対象となるすべての入力について、通常のHinnant実装と比較しました。

for (let year = 1; year <= 9_999; year++) {
  for (let month = 0; month < 12; month++) {
    for (let day = 1; day <= 31; day++) {
      const expected = daysFromCivil(year, month, day);
      const actual = ymdToEpochDays(year, month, day);

      if (actual !== expected) {
        throw new Error(
          `mismatch: ${year}-${month}-${day}: ` +
          `${actual} !== ${expected}`,
        );
      }
    }
  }
}

比較した入力数は、

9999 * 12 * 31
= 3,719,628

です。TypeScript、Rust、Cの各実装で全件一致しました。

day は各月の実際の日数によらず31まで検証しています。そのため、2月31日のような実在しない日付も含まれます。関数は入力を拒否せず、通算日として連続的に計算します。実在する日付かどうかの検証は呼び出し側の責務です。

ベンチマーク

Apple Silicon ARM64上で、事前生成した 2^20 件の年月日を32回処理しました。入力位置はラウンドごとに回転させ、同一ループの巻き上げを防いでいます。

入力は次の範囲から決定的な疑似乱数で生成しました。

年: 1..9999
月: 0..11
日: 1..28

7回測定した最小値を採用しています。コンパイル・実行条件は次のとおりです。

Bun 1.4.0
rustc 1.96.0 -C opt-level=3 -C target-cpu=native
Apple clang 21.0.0 -O3 -march=native

結果は次のとおりでした。

環境	通常のHinnant	今回の限定範囲版	時間短縮	スループット
Bun	14.738 ns/件	3.018 ns/件	79.5%	4.88倍
Rust	2.001 ns/件	1.192 ns/件	40.4%	1.68倍
C	1.923 ns/件	1.205 ns/件	37.3%	1.60倍

Bunでは、通常の浮動小数点除算と Math.floor を Math.imul とシフトへ置き換える効果が特に大きく出ました。

CとRustのコンパイラは定数除算をもともと乗算とシフトへ変換できます。それでも、365日項と /4 をまとめ、一つの積を /100 と /400 に共有し、残りの定数を月テーブルへ移した限定範囲版が、この環境では約37〜40%高速でした。

ただし、これは特定のCPU、コンパイラ、JIT、入力分布に対する結果です。Intel x86-64、別世代のApple Silicon、Node.js/V8、ブラウザ、異なるRust/Clangバージョンで同じ差になるとは限りません。

先行研究と今回の位置づけ

この実装はHoward Hinnantの days_from_civil を基礎にしています。また、整数の定数除算を乗算とシフトへ置き換えるstrength reductionは既知の技法です。

5243 による、0以上9999以下の整数の100除算も既知です。

(value * 5243) >> 19

今回の構成は、先の記事「マジックナンバー化による高速な曜日計算」で使用した限定範囲向けの共有積を、days_from_civil へ展開したものです。

ポイントは次の組み合わせです。

同じ積 adjustedYear * 5243 から /100 と /400 を取得する
365 * adjustedYear + floor(adjustedYear / 4) を floor(1461 * adjustedYear / 4) にまとめる
March-basedの月項を、epochオフセットも含む12要素テーブルへ置き換える
JavaScriptでは Math.imul と符号なしシフトを明示する
年を 1..9999 に限定し、32-bit範囲内で完結させる

NeriとSchneiderはEuclidean affine functionとして、Gregorian calendar変換の乗算・シフト化と依存鎖短縮を体系的に扱っています。したがって、構成要素や一般的な最適化方針を新しいものとして主張するものではありません。

一方、年1〜9999の days_from_civil に対して、1461 の年積、/100 と /400 を共有する 5243 の積、epoch補正済み月テーブルを組み合わせる同一構成については、調査した公開実装の範囲では確認できませんでした。

これは、あらゆるCPU、言語、式の形の中で最速または最適であることを意味しません。対象範囲と実行環境を固定した高速化です。

逆変換について

この記事が扱う days_from_civil は、年月日を連続した通算日へ変換します。逆向きの変換は通常 civil_from_days と呼ばれます。

civil date -- days_from_civil --> serial day
civil date <-- civil_from_days --- serial day

両者は逆関数ですが、最適化の構造はかなり異なります。civil_from_days は一つの整数からera、年、月、日を復元する必要があり、使う除算、補正、マジックナンバーも異なります。そのため、別の記事として扱うのが適切です。

まとめ

年を1〜9999に限定することで、Hinnant型 days_from_civil の定数除算を、互いに独立した二つの乗算とシフトへ置き換えられました。

中心となる変換は次の二つです。

Math.imul(adjustedYear, 1_461) >>> 2;

const centuryProduct = Math.imul(adjustedYear, 5_243);

centuryProduct >>> 19; // adjustedYear / 100
centuryProduct >>> 21; // adjustedYear / 400

EPOCH_MONTH_TABLE[month] + day;

Apple Silicon上の今回の測定では、通常のHinnant実装より、Bunで約80%、RustとCで約37〜40%実行時間を短縮しました。

一般的なアプリケーションでは、読みやすく広い年範囲を扱える通常の days_from_civil で十分です。今回の実装は、年月日変換がホットパスにあり、入力年の範囲が明確で、対象環境で性能差を実測できる場合に向いています。

参考資料

Howard Hinnant, chrono-Compatible Low-Level Date Algorithms
Cassio Neri and Lorenz Schneider, Euclidean Affine Functions and Applications to Calendar Algorithms
Cassio Neri, EAF supplementary material
マジックナンバー化による高速な曜日計算

ふるさと納税で危険な年収帯

ask_yoshi_taka — Sun, 05 Apr 2026 08:56:47 GMT

ふるさと納税の限度額の目安を、公式に基づいて算出すると次のようになる。

![ふるさと納税の整理図](../../assets/furusato_true.svg)

なぞのジャンプがある

上記の図の通り年収440万前後および650万円前後でジャンプが発生している。これは主に所得税率の境目で起きる。

傾きが急になる理由

ふるさと納税の控除は、ざっくり次の3つに分かれる。

所得税控除
住民税基本分
住民税特例分

このうち、上限額を実質的に決めているのは住民税特例分である。
住民税特例分には住民税所得割額の20%という上限があるため、この枠をどこまで使い切れるかで、ふるさと納税の限度額が決まる。

追加で寄附した金額は、まず所得税控除と住民税基本分に配分され、残りを住民税特例分が受け持つ。

ここで、所得税率が切り替わって高くなると、追加の寄附額に対して 所得税控除 の割合がそれまでより多くなる。すると、そのぶん 住民税特例分 が受け持つ額はそれまでより小さくなる。

つまり、所得税率が高くなったあとは、同じ1万円を追加で寄附しても 住民税特例分の枠 の減り方がそれまでより遅くなる。
その結果、住民税特例分の上限に達するまでに許される寄附額が増え、グラフの傾きが急になる。税率差が大きい方が急になりやすい。

逆に、税率帯が変わらない区間では、追加寄附1万円あたりで 住民税特例分 をどれだけ使うかもほぼ一定なので、グラフの傾きもほぼ一定になる。

細かいギザギザ

細かいギザギザは社会保険の等級表を表している。曲線は階段的になり、局所的な戻りや細かい折れは等級切替の影響が強い。

![ふるさと納税の拡大図](../../assets/furusato_true_zoom_300_400_v4.svg)

等級表切り替えの影響

N字型折れ

![ふるさと納税の600万から700万円帯拡大図](../../assets/furusato_true_zoom_600_700_v4.svg)

654万円付近のN字型折れ。

654万付近のN字型折れは制度上ありうるもの。年収653万は月額だと544,166円、654万だと545,000円。この1万円差で標準報酬月額の等級が切り替わる。その結果、健康保険・支援金・厚生年金の従業員負担が一段上がり、ふるさと納税上限の変化は一時的に鈍化し、場合によってはマイナスになる。450万付近も似ている。

この議論は最も単純なモデルをベースとしており、扶養控除、保険、住宅ローン、iDeCoなど控除が増えれば増えるほど年収がずれていく。自分の状況に合わせたいなら税理士に確認するのが良いでしょう。

ふるさと納税の早見表などをもとに寄付する場合、この近辺では見落としが発生することがあり、例えば650万円から逆算するなら限度額超過に注意が必要です。よくわからなかったら保守的に考えるのが楽です。多少限度額を越えても損はしません。

細かい補足

できるだけ単純なモデルとした

対象は 単身・扶養なし・iDeCo等なし
会社員前提
協会けんぽ東京
40歳未満
賞与なし
社会保険料は年収固定率ではなく、標準報酬月額の等級表ベースで計算する

一般的な図表との違い

よく使われる簡便式は住民税特別控除を限界税率1本で使うため、境目で見かけ上の階段大ジャンプが出る。簡便式は、国税庁・総務省の控除ルールから上限額を逆算した「目安用」の式。実際の税務実務そのものが、この簡便式を使って最終税額を確定しているわけではない

年収1000万以上

所得税率の切り替わりのタイミングで同様の事象が発生する

なににせよ、ふるさと納税は、共同体に責任を負う市民の立場からすれば、速やかに廃止されるべき制度でしょう。

参考コード

bun

// furusato_tufte.ts
// bun run furusato_tufte.ts
//
// 出力:
//   - furusato_tufte.svg
//
// 前提:
//   - 単身
//   - 配偶者控除・扶養控除なし
//   - iDeCo なし
//   - 基礎控除あり
//   - 会社員（協会けんぽ東京・40歳未満・賞与なし）
//   - 社会保険料は標準報酬月額の等級表で計算
//   - 300万円〜1000万円を 1万円刻み
//
// ねらい:
//   - ジャンプ地点を自動検出
//   - 注釈は白い箱 + 細いリーダー線
//   - 660万円 / 850万円の補助線は出さない
//   - x/y 軸と目盛りを明示

const W = 1400;
const H = 930;

const M = {
  top: 80,
  right: 80,
  bottom: 200,
  left: 110,
};

const DEFAULT_X_MIN = 300; // 万円
const DEFAULT_X_MAX = 1000; // 万円
const STEP_YEN = 10_000;

const BASIC_DEDUCTION = 480_000;
const RESIDENT_BASIC_DEDUCTION = 430_000;
const MONTHS_PER_YEAR = 12;
const RECONSTRUCTION_SURTAX_RATE = 0.021;

const ASSUMPTIONS = {
  unemploymentInsuranceEmployeeRate: 0.005, // 一般の事業 令和8年度
} as const;

const HEALTH_INSURANCE_TABLE = [
  { upperBound: 63_000, employeeHealth: 2_856.5, employeeSupport: 66.7 },
  { upperBound: 73_000, employeeHealth: 3_349.0, employeeSupport: 78.2 },
  { upperBound: 83_000, employeeHealth: 3_841.5, employeeSupport: 89.7 },
  { upperBound: 93_000, employeeHealth: 4_334.0, employeeSupport: 101.2 },
  { upperBound: 101_000, employeeHealth: 4_826.5, employeeSupport: 112.7 },
  { upperBound: 107_000, employeeHealth: 5_122.0, employeeSupport: 119.6 },
  { upperBound: 114_000, employeeHealth: 5_417.5, employeeSupport: 126.5 },
  { upperBound: 122_000, employeeHealth: 5_811.5, employeeSupport: 135.7 },
  { upperBound: 130_000, employeeHealth: 6_205.5, employeeSupport: 144.9 },
  { upperBound: 138_000, employeeHealth: 6_599.5, employeeSupport: 154.1 },
  { upperBound: 146_000, employeeHealth: 6_993.5, employeeSupport: 163.3 },
  { upperBound: 155_000, employeeHealth: 7_387.5, employeeSupport: 172.5 },
  { upperBound: 165_000, employeeHealth: 7_880.0, employeeSupport: 184.0 },
  { upperBound: 175_000, employeeHealth: 8_372.5, employeeSupport: 195.5 },
  { upperBound: 185_000, employeeHealth: 8_865.0, employeeSupport: 207.0 },
  { upperBound: 195_000, employeeHealth: 9_357.5, employeeSupport: 218.5 },
  { upperBound: 210_000, employeeHealth: 9_850.0, employeeSupport: 230.0 },
  { upperBound: 230_000, employeeHealth: 10_835.0, employeeSupport: 253.0 },
  { upperBound: 250_000, employeeHealth: 11_820.0, employeeSupport: 276.0 },
  { upperBound: 270_000, employeeHealth: 12_805.0, employeeSupport: 299.0 },
  { upperBound: 290_000, employeeHealth: 13_790.0, employeeSupport: 322.0 },
  { upperBound: 310_000, employeeHealth: 14_775.0, employeeSupport: 345.0 },
  { upperBound: 330_000, employeeHealth: 15_760.0, employeeSupport: 368.0 },
  { upperBound: 350_000, employeeHealth: 16_745.0, employeeSupport: 391.0 },
  { upperBound: 370_000, employeeHealth: 17_730.0, employeeSupport: 414.0 },
  { upperBound: 395_000, employeeHealth: 18_715.0, employeeSupport: 437.0 },
  { upperBound: 425_000, employeeHealth: 20_192.5, employeeSupport: 471.5 },
  { upperBound: 455_000, employeeHealth: 21_670.0, employeeSupport: 506.0 },
  { upperBound: 485_000, employeeHealth: 23_147.5, employeeSupport: 540.5 },
  { upperBound: 515_000, employeeHealth: 24_625.0, employeeSupport: 575.0 },
  { upperBound: 545_000, employeeHealth: 26_102.5, employeeSupport: 609.5 },
  { upperBound: 575_000, employeeHealth: 27_580.0, employeeSupport: 644.0 },
  { upperBound: 605_000, employeeHealth: 29_057.5, employeeSupport: 678.5 },
  { upperBound: 635_000, employeeHealth: 30_535.0, employeeSupport: 713.0 },
  { upperBound: 665_000, employeeHealth: 32_012.5, employeeSupport: 747.5 },
  { upperBound: 695_000, employeeHealth: 33_490.0, employeeSupport: 782.0 },
  { upperBound: 730_000, employeeHealth: 34_967.5, employeeSupport: 816.5 },
  { upperBound: 770_000, employeeHealth: 36_937.5, employeeSupport: 862.5 },
  { upperBound: 810_000, employeeHealth: 38_907.5, employeeSupport: 908.5 },
  { upperBound: 855_000, employeeHealth: 40_877.5, employeeSupport: 954.5 },
  { upperBound: 905_000, employeeHealth: 43_340.0, employeeSupport: 1_012.0 },
  { upperBound: 955_000, employeeHealth: 45_802.5, employeeSupport: 1_069.5 },
  { upperBound: 1_005_000, employeeHealth: 48_265.0, employeeSupport: 1_127.0 },
  { upperBound: 1_055_000, employeeHealth: 50_727.5, employeeSupport: 1_184.5 },
  { upperBound: 1_115_000, employeeHealth: 53_682.5, employeeSupport: 1_253.5 },
  { upperBound: 1_175_000, employeeHealth: 56_637.5, employeeSupport: 1_322.5 },
  { upperBound: 1_235_000, employeeHealth: 59_592.5, employeeSupport: 1_391.5 },
  { upperBound: 1_295_000, employeeHealth: 62_547.5, employeeSupport: 1_460.5 },
  { upperBound: 1_355_000, employeeHealth: 65_502.5, employeeSupport: 1_529.5 },
  { upperBound: Number.POSITIVE_INFINITY, employeeHealth: 68_457.5, employeeSupport: 1_598.5 },
] as const;

const PENSION_TABLE = [
  { upperBound: 93_000, employeePension: 8_052.0 },
  { upperBound: 101_000, employeePension: 8_967.0 },
  { upperBound: 107_000, employeePension: 9_516.0 },
  { upperBound: 114_000, employeePension: 10_065.0 },
  { upperBound: 122_000, employeePension: 10_797.0 },
  { upperBound: 130_000, employeePension: 11_529.0 },
  { upperBound: 138_000, employeePension: 12_261.0 },
  { upperBound: 146_000, employeePension: 12_993.0 },
  { upperBound: 155_000, employeePension: 13_725.0 },
  { upperBound: 165_000, employeePension: 14_640.0 },
  { upperBound: 175_000, employeePension: 15_555.0 },
  { upperBound: 185_000, employeePension: 16_470.0 },
  { upperBound: 195_000, employeePension: 17_385.0 },
  { upperBound: 210_000, employeePension: 18_300.0 },
  { upperBound: 230_000, employeePension: 20_130.0 },
  { upperBound: 250_000, employeePension: 21_960.0 },
  { upperBound: 270_000, employeePension: 23_790.0 },
  { upperBound: 290_000, employeePension: 25_620.0 },
  { upperBound: 310_000, employeePension: 27_450.0 },
  { upperBound: 330_000, employeePension: 29_280.0 },
  { upperBound: 350_000, employeePension: 31_110.0 },
  { upperBound: 370_000, employeePension: 32_940.0 },
  { upperBound: 395_000, employeePension: 34_770.0 },
  { upperBound: 425_000, employeePension: 37_515.0 },
  { upperBound: 455_000, employeePension: 40_260.0 },
  { upperBound: 485_000, employeePension: 43_005.0 },
  { upperBound: 515_000, employeePension: 45_750.0 },
  { upperBound: 545_000, employeePension: 48_495.0 },
  { upperBound: 575_000, employeePension: 51_240.0 },
  { upperBound: 605_000, employeePension: 53_985.0 },
  { upperBound: 635_000, employeePension: 56_730.0 },
  { upperBound: Number.POSITIVE_INFINITY, employeePension: 59_475.0 },
] as const;

// -----------------------------
// Tax model
// -----------------------------
function salaryDeduction(s: number): number {
  if (s <= 1_625_000) return 550_000;
  if (s <= 1_800_000) return Math.floor(s * 0.4 - 100_000);
  if (s <= 3_600_000) return Math.floor(s * 0.3 + 80_000);
  if (s <= 6_600_000) return Math.floor(s * 0.2 + 440_000);
  if (s <= 8_500_000) return Math.floor(s * 0.1 + 1_100_000);
  return 1_950_000;
}

function incomeTaxRate(taxable: number): number {
  const rounded = Math.floor(taxable / 1000) * 1000;
  if (rounded <= 1_949_000) return 0.05;
  if (rounded <= 3_299_000) return 0.1;
  if (rounded <= 6_949_000) return 0.2;
  if (rounded <= 8_999_000) return 0.23;
  return 0.33;
}

function incomeTaxDeductionAmount(taxable: number): number {
  const rounded = Math.floor(taxable / 1000) * 1000;
  if (rounded <= 1_949_000) return 0;
  if (rounded <= 3_299_000) return 97_500;
  if (rounded <= 6_949_000) return 427_500;
  if (rounded <= 8_999_000) return 636_000;
  if (rounded <= 17_999_000) return 1_536_000;
  if (rounded <= 39_999_000) return 2_796_000;
  return 4_796_000;
}

function lookupByMonthlySalary<T extends { upperBound: number }>(
  monthlySalary: number,
  table: readonly T[],
): T {
  return table.find((row) => monthlySalary < row.upperBound) ?? table[table.length - 1];
}

function socialInsurance(s: number): number {
  const monthlySalary = s / MONTHS_PER_YEAR;
  const healthRow = lookupByMonthlySalary(monthlySalary, HEALTH_INSURANCE_TABLE);
  const pensionRow = lookupByMonthlySalary(monthlySalary, PENSION_TABLE);

  const monthlyHealthInsurance = healthRow.employeeHealth + healthRow.employeeSupport;
  const monthlyEmployeesPension = pensionRow.employeePension;
  const annualUnemploymentInsurance = s * ASSUMPTIONS.unemploymentInsuranceEmployeeRate;

  return Math.round(
    monthlyHealthInsurance * MONTHS_PER_YEAR +
      monthlyEmployeesPension * MONTHS_PER_YEAR +
      annualUnemploymentInsurance,
  );
}

function incomeTaxableIncome(s: number): number {
  return Math.max(0, s - salaryDeduction(s) - BASIC_DEDUCTION - socialInsurance(s));
}

function residentTaxableIncome(s: number): number {
  return Math.max(0, s - salaryDeduction(s) - RESIDENT_BASIC_DEDUCTION - socialInsurance(s));
}

function incomeTaxAmount(taxable: number): number {
  const rounded = Math.floor(taxable / 1000) * 1000;
  const baseTax = Math.max(
    0,
    Math.floor(rounded * incomeTaxRate(rounded) - incomeTaxDeductionAmount(rounded)),
  );
  return Math.floor(baseTax * (1 + RECONSTRUCTION_SURTAX_RATE));
}

function furusatoLimitSimple(s: number): number {
  const taxable = incomeTaxableIncome(s);
  const t = incomeTaxRate(taxable);
  const residentIncomeLevy = residentTaxableIncome(s) * 0.1;
  const denom = 0.9 - t;

  if (denom <= 0) return 0;
  return Math.floor(2000 + (0.2 * residentIncomeLevy) / denom);
}

function isFullyDeductible(s: number, donationYen: number): boolean {
  const deductionBase = donationYen - 2_000;
  if (deductionBase <= 0) return true;

  const incomeTaxBefore = incomeTaxAmount(incomeTaxableIncome(s));
  const incomeTaxAfter = incomeTaxAmount(Math.max(0, incomeTaxableIncome(s) - deductionBase));
  const incomeTaxReduction = incomeTaxBefore - incomeTaxAfter;
  const residentBasicReduction = deductionBase * 0.1;
  const residentSpecialNeeded = deductionBase - incomeTaxReduction - residentBasicReduction;
  const residentSpecialCap = residentTaxableIncome(s) * 0.1 * 0.2;

  return residentSpecialNeeded <= residentSpecialCap;
}

function furusatoLimitTrue(s: number): number {
  let lo = 2_000;
  let hi = furusatoLimitSimple(s) + 200_000;
  while (isFullyDeductible(s, hi)) {
    hi *= 2;
  }

  while (hi - lo > 1) {
    const mid = Math.floor((lo + hi) / 2);
    if (isFullyDeductible(s, mid)) {
      lo = mid;
    } else {
      hi = mid;
    }
  }

  return lo;
}

// -----------------------------
// Data
// -----------------------------
type Point = {
  salaryYen: number;
  salaryMan: number;
  limitYen: number;
};

type Gain = {
  startMan: number;
  endMan: number;
  centerMan: number;
  deltaYen: number;
};

// -----------------------------
// Detect jumps
// -----------------------------
type Jump = {
  index: number;
  salaryBeforeYen: number;
  salaryAfterYen: number;
  limitBefore: number;
  limitAfter: number;
  delta: number;
};

function median(arr: number[]): number {
  const xs = [...arr].sort((a, b) => a - b);
  const n = xs.length;
  if (n % 2 === 1) return xs[(n - 1) / 2];
  return (xs[n / 2 - 1] + xs[n / 2]) / 2;
}

function fmtYen(n: number): string {
  return n.toLocaleString("ja-JP");
}

function fmtMan(nYen: number): string {
  return `${(nYen / 10_000).toFixed(1)}万円`;
}

function fmtSalaryMan(nYen: number): string {
  return `${Math.round(nYen / 10_000)}万`;
}

function fmtDonationMan(nYen: number): string {
  return `${(nYen / 10_000).toFixed(1)}万`;
}

function fmtAxisSalaryMan(nMan: number): string {
  return `${nMan}万`;
}

function fmtAxisDonationMan(nYen: number): string {
  if (nYen === 0) return "0";
  return `${(nYen / 10_000).toFixed(1)}万`;
}

function fmtDeltaManCompact(nYen: number): string {
  return `+${(nYen / 10_000).toFixed(1)}`;
}

function escapeXml(s: string): string {
  return s.replaceAll("&", "&amp;").replaceAll("<", "&lt;").replaceAll(">", "&gt;");
}

function makeJumpCallout(params: {
  x: number;
  y: number;
  boxX: number;
  boxY: number;
  title: string;
  line1: string;
  line2: string;
}) {
  const { x, y, boxX, boxY, title, line1, line2 } = params;

  const boxW = 320;
  const boxH = 112;
  const anchorX = x < boxX ? boxX : boxX + boxW;
  const anchorY = boxY + 56;

  return `
    <line x1="${x}" y1="${y}" x2="${anchorX}" y2="${anchorY}"
          stroke="#666" stroke-width="1.2" />

    <circle cx="${x}" cy="${y}" r="4.5" fill="#111" />

    <rect x="${boxX}" y="${boxY}" width="${boxW}" height="${boxH}"
          fill="#fffefa" stroke="#d8d4cc" stroke-width="1" rx="2" />

    <text x="${boxX + 14}" y="${boxY + 29}" class="anno strong">${escapeXml(title)}</text>
    <text x="${boxX + 14}" y="${boxY + 61}" class="anno">${escapeXml(line1)}</text>
    <text x="${boxX + 14}" y="${boxY + 91}" class="anno">${escapeXml(line2)}</text>
  `;
}

function makeSimpleCallout(params: {
  x: number;
  y: number;
  boxX: number;
  boxY: number;
  title: string;
}) {
  const { x, y, boxX, boxY, title } = params;
  const boxW = 280;
  const boxH = 58;
  const anchorX = x < boxX ? boxX : boxX + boxW;
  const anchorY = boxY + boxH / 2;

  return `
    <line x1="${x}" y1="${y}" x2="${anchorX}" y2="${anchorY}"
          stroke="#666" stroke-width="1.2" />

    <rect x="${boxX}" y="${boxY}" width="${boxW}" height="${boxH}"
          fill="#fffefa" stroke="#d8d4cc" stroke-width="1" rx="2" />

    <text x="${boxX + 14}" y="${boxY + 37}" class="anno strong">${escapeXml(title)}</text>
  `;
}

type AnnotationLayout = {
  x: number;
  y: number;
  boxX: number;
  boxY: number;
};

function overlaps(a: AnnotationLayout, b: AnnotationLayout): boolean {
  const boxW = 320;
  const boxH = 112;
  return !(
    a.boxX + boxW <= b.boxX ||
    b.boxX + boxW <= a.boxX ||
    a.boxY + boxH <= b.boxY ||
    b.boxY + boxH <= a.boxY
  );
}

function clamp(n: number, min: number, max: number): number {
  return Math.max(min, Math.min(max, n));
}

const BOX_W = 320;
const BOX_H = 112;
const BOX_GAP_X = 30;
const BOX_GAP_Y = 20;
const CURVE_CLEARANCE = 18;

type ChartConfig = {
  xMin: number;
  xMax: number;
  output: string;
  title: string;
  subtitle: string;
  limitFn: (salaryYen: number) => number;
  showJumps: boolean;
  simpleCalloutSalaryMans?: number[];
};

type ChartData = {
  points: Point[];
  gains: Gain[];
  diffs: number[];
  jumps: Jump[];
  plotW: number;
  plotH: number;
  maxY: number;
  gainBandTop: number;
  gainBandH: number;
  gainBandBottom: number;
  gainMax: number;
  sx: (xMan: number) => number;
  sy: (y: number) => number;
};

function buildChart(config: ChartConfig): ChartData {
  const points: Point[] = [];
  for (let s = config.xMin * 10_000; s <= config.xMax * 10_000; s += STEP_YEN) {
    points.push({
      salaryYen: s,
      salaryMan: s / 10_000,
      limitYen: config.limitFn(s),
    });
  }

  const gains: Gain[] = [];
  for (let startMan = config.xMin; startMan < config.xMax; startMan += 50) {
    const startYen = startMan * 10_000;
    const endYen = (startMan + 50) * 10_000;
    gains.push({
      startMan,
      endMan: startMan + 50,
      centerMan: startMan + 25,
      deltaYen: config.limitFn(endYen) - config.limitFn(startYen),
    });
  }

  const diffs: number[] = [];
  for (let i = 1; i < points.length; i++) {
    diffs.push(points[i].limitYen - points[i - 1].limitYen);
  }

  const baseStep = median(diffs);
  const jumpThreshold = baseStep * 3;
  const jumps: Jump[] = [];
  for (let i = 1; i < points.length; i++) {
    const delta = points[i].limitYen - points[i - 1].limitYen;
    if (delta > jumpThreshold) {
      jumps.push({
        index: i,
        salaryBeforeYen: points[i - 1].salaryYen,
        salaryAfterYen: points[i].salaryYen,
        limitBefore: points[i - 1].limitYen,
        limitAfter: points[i].limitYen,
        delta,
      });
    }
  }

  const plotW = W - M.left - M.right;
  const plotH = H - M.top - M.bottom;
  const maxYRaw = Math.max(...points.map((p) => p.limitYen));
  const yTickStep = 25_000;
  const maxY = Math.ceil((maxYRaw * 1.08) / yTickStep) * yTickStep;
  const gainBandTop = M.top + plotH + 54;
  const gainBandH = 56;
  const gainBandBottom = gainBandTop + gainBandH;
  const gainMax = Math.max(...gains.map((g) => g.deltaYen));
  const sx = (xMan: number) =>
    M.left + ((xMan - config.xMin) / (config.xMax - config.xMin)) * plotW;
  const sy = (y: number) => M.top + plotH - (y / maxY) * plotH;

  return {
    points,
    gains,
    diffs,
    jumps,
    plotW,
    plotH,
    maxY,
    gainBandTop,
    gainBandH,
    gainBandBottom,
    gainMax,
    sx,
    sy,
  };
}

function intersectsCurve(
  layout: AnnotationLayout,
  points: Point[],
  sx: (xMan: number) => number,
  sy: (y: number) => number,
): boolean {
  const minX = layout.boxX - CURVE_CLEARANCE;
  const maxX = layout.boxX + BOX_W + CURVE_CLEARANCE;
  const minY = layout.boxY - CURVE_CLEARANCE;
  const maxY = layout.boxY + BOX_H + CURVE_CLEARANCE;

  return points.some((p) => {
    const px = sx(p.salaryMan);
    const py = sy(p.limitYen);
    return px >= minX && px <= maxX && py >= minY && py <= maxY;
  });
}

function layoutJumpAnnotations(
  jumps: Jump[],
  points: Point[],
  sx: (xMan: number) => number,
  sy: (y: number) => number,
  plotW: number,
  plotH: number,
): AnnotationLayout[] {
  const placed: AnnotationLayout[] = [];

  jumps.forEach((j, idx) => {
    const x = sx(j.salaryAfterYen / 10_000);
    const y = sy(j.limitAfter);

    if (idx === 0) {
      placed.push({
        x,
        y,
        boxX: clamp(x + BOX_GAP_X, M.left + 10, M.left + plotW - BOX_W - 10),
        boxY: clamp(y + BOX_GAP_Y, M.top + 10, M.top + plotH - BOX_H - 10),
      });
      return;
    }

    if (idx === 1) {
      placed.push({
        x,
        y,
        boxX: clamp(x - BOX_W - BOX_GAP_X, M.left + 10, M.left + plotW - BOX_W - 10),
        boxY: clamp(y - BOX_H - 36, M.top + 10, M.top + plotH - BOX_H - 10),
      });
      return;
    }

    const xCandidates =
      idx % 2 === 0
        ? [x + BOX_GAP_X, x + 80, x - BOX_W - BOX_GAP_X]
        : [x - BOX_W - BOX_GAP_X, x - BOX_W - 80, x + BOX_GAP_X];
    const yCandidates = [y - 96, y - 220, y + BOX_GAP_Y, y - 340, y + 140];

    const defaultLayout: AnnotationLayout = {
      x,
      y,
      boxX: clamp(xCandidates[0], M.left + 10, M.left + plotW - BOX_W - 10),
      boxY: clamp(yCandidates[0], M.top + 10, M.top + plotH - BOX_H - 10),
    };
    let chosenLayout = defaultLayout;
    let found = false;

    for (const candidateX of xCandidates) {
      for (const candidateY of yCandidates) {
        const nextLayout = {
          x,
          y,
          boxX: clamp(candidateX, M.left + 10, M.left + plotW - BOX_W - 10),
          boxY: clamp(candidateY, M.top + 10, M.top + plotH - BOX_H - 10),
        };
        if (placed.some((prev) => overlaps(prev, nextLayout))) continue;
        if (intersectsCurve(nextLayout, points, sx, sy)) continue;
        chosenLayout = nextLayout;
        found = true;
        break;
      }
      if (found) break;
    }

    placed.push(chosenLayout);
  });

  return placed;
}

function renderChart(config: ChartConfig) {
  const data = buildChart(config);
  const yTickStep = 25_000;
  const polyline = data.points
    .map((p) => `${data.sx(p.salaryMan)},${data.sy(p.limitYen)}`)
    .join(" ");
  const xTicks: string[] = [];
  for (let x = config.xMin; x <= config.xMax; x += 50) {
    xTicks.push(`
    <line x1="${data.sx(x)}" y1="${M.top + data.plotH}" x2="${data.sx(x)}" y2="${M.top + data.plotH + 6}"
          stroke="#444" stroke-width="1" />
    <text x="${data.sx(x)}" y="${M.top + data.plotH + 24}" text-anchor="middle" class="tick">${fmtAxisSalaryMan(x)}</text>
  `);
  }
  const yTicks: string[] = [];
  for (let y = 0; y <= data.maxY; y += yTickStep) {
    yTicks.push(`
    <line x1="${M.left - 6}" y1="${data.sy(y)}" x2="${M.left}" y2="${data.sy(y)}"
          stroke="#444" stroke-width="1" />
    <text x="${M.left - 12}" y="${data.sy(y) + 5}" text-anchor="end" class="tick">${fmtAxisDonationMan(y)}</text>
  `);
  }
  const gainBars = data.gains
    .map((g) => {
      const x = data.sx(g.centerMan);
      const topY = data.gainBandBottom - (g.deltaYen / data.gainMax) * (data.gainBandH - 18);
      return `
    <line x1="${x}" y1="${data.gainBandBottom}" x2="${x}" y2="${topY}"
          stroke="#9a9487" stroke-width="2" />
    <text x="${x}" y="${topY - 6}" text-anchor="middle" class="mini">${fmtDeltaManCompact(g.deltaYen)}</text>
    `;
    })
    .join("\n");
  const jumpAnnotations: string[] = [];
  if (config.showJumps) {
    const annotationLayouts = layoutJumpAnnotations(
      data.jumps,
      data.points,
      data.sx,
      data.sy,
      data.plotW,
      data.plotH,
    );
    data.jumps.forEach((j, idx) => {
      const { x, y, boxX, boxY } = annotationLayouts[idx];
      jumpAnnotations.push(
        makeJumpCallout({
          x,
          y,
          boxX,
          boxY,
          title: `${fmtSalaryMan(j.salaryAfterYen)}付近でジャンプ`,
          line1: `${fmtDonationMan(j.limitBefore)} → ${fmtDonationMan(j.limitAfter)}`,
          line2: `+${fmtDonationMan(j.delta)}`,
        }),
      );
    });
  }
  if (config.simpleCalloutSalaryMans?.length) {
    config.simpleCalloutSalaryMans.forEach((salaryMan, idx) => {
      const point = data.points.find((p) => p.salaryMan === salaryMan);
      if (!point) return;
      const x = data.sx(point.salaryMan);
      const y = data.sy(point.limitYen);
      const simpleBoxW = 280;
      const simpleBoxH = 58;
      const boxX =
        idx === 0
          ? clamp(x + BOX_GAP_X, M.left + 10, M.left + data.plotW - simpleBoxW - 10)
          : clamp(x - simpleBoxW - BOX_GAP_X, M.left + 10, M.left + data.plotW - simpleBoxW - 10);
      const boxY =
        idx === 0
          ? clamp(y + BOX_GAP_Y, M.top + 10, M.top + data.plotH - simpleBoxH - 10)
          : clamp(y - simpleBoxH - 36, M.top + 10, M.top + data.plotH - simpleBoxH - 10);
      jumpAnnotations.push(
        makeSimpleCallout({
          x,
          y,
          boxX,
          boxY,
          title: `${salaryMan}万付近でジャンプ`,
        }),
      );
    });
  }
  return {
    svg: `<?xml version="1.0" encoding="UTF-8"?>
<svg width="${W}" height="${H}" viewBox="0 0 ${W} ${H}" xmlns="http://www.w3.org/2000/svg">
  <style>
    .title {
      font-family: Georgia, "Times New Roman", serif;
      font-size: 30px;
      fill: #111;
    }
    .subtitle {
      font-family: Georgia, "Times New Roman", serif;
      font-size: 16px;
      fill: #555;
    }
    .axislabel {
      font-family: Georgia, "Times New Roman", serif;
      font-size: 18px;
      fill: #222;
    }
    .tick {
      font-family: Georgia, "Times New Roman", serif;
      font-size: 15px;
      fill: #444;
    }
    .anno {
      font-family: Georgia, "Times New Roman", serif;
      font-size: 16px;
      fill: #222;
    }
    .mini {
      font-family: Georgia, "Times New Roman", serif;
      font-size: 12px;
      fill: #7a7469;
    }
    .miniLabel {
      font-family: Georgia, "Times New Roman", serif;
      font-size: 13px;
      fill: #7a7469;
    }
    .strong {
      font-weight: 700;
    }
  </style>
  <rect width="100%" height="100%" fill="#fbfbf8" />

  <text x="${W / 2}" y="42" text-anchor="middle" class="title">
    ふるさと納税の上限額とジャンプ点
  </text>
  <text x="${W / 2}" y="68" text-anchor="middle" class="subtitle">
    ${escapeXml(config.subtitle)}
  </text>

  <line x1="${M.left}" y1="${M.top + data.plotH}" x2="${M.left + data.plotW}" y2="${M.top + data.plotH}" stroke="#222" stroke-width="1.2" />
  <line x1="${M.left}" y1="${M.top}" x2="${M.left}" y2="${M.top + data.plotH}" stroke="#222" stroke-width="1.2" />

  ${xTicks.join("\n")}
  ${yTicks.join("\n")}

  <polyline fill="none" stroke="#1f1f1f" stroke-width="2.4" points="${polyline}" />

  ${jumpAnnotations.join("\n")}

  <text x="24" y="${M.top - 22}" text-anchor="start" class="axislabel">上限寄附額</text>
  <text x="${M.left}" y="${data.gainBandTop - 12}" text-anchor="start" class="miniLabel">50万増で増える額</text>
  <line x1="${M.left}" y1="${data.gainBandBottom}" x2="${M.left + data.plotW}" y2="${data.gainBandBottom}"
        stroke="#c8c2b6" stroke-width="1" />
  ${gainBars}
</svg>
`,
    diffs: data.diffs,
    jumps: data.jumps,
  };
}

const charts: ChartConfig[] = [
  {
    xMin: DEFAULT_X_MIN,
    xMax: DEFAULT_X_MAX,
    output: "furusato_tufte.svg",
    title: "300-1000 simple",
    subtitle:
      "単身・扶養なし・iDeCoなし・会社員(協会けんぽ東京・40歳未満・賞与なし・簡便逆算式) / 1万円刻み",
    limitFn: furusatoLimitSimple,
    showJumps: true,
  },
  {
    xMin: 1000,
    xMax: 2000,
    output: "furusato_tufte_1000_2000.svg",
    title: "1000-2000 simple",
    subtitle:
      "単身・扶養なし・iDeCoなし・会社員(協会けんぽ東京・40歳未満・賞与なし・簡便逆算式) / 1万円刻み",
    limitFn: furusatoLimitSimple,
    showJumps: true,
  },
  {
    xMin: 0,
    xMax: 2000,
    output: "furusato_true_0_2000.svg",
    title: "0-2000 true",
    subtitle:
      "単身・扶養なし・iDeCoなし・会社員(協会けんぽ東京・40歳未満・賞与なし・控除式を数値探索) / 1万円刻み",
    limitFn: furusatoLimitTrue,
    showJumps: false,
  },
  {
    xMin: DEFAULT_X_MIN,
    xMax: DEFAULT_X_MAX,
    output: "furusato_true.svg",
    title: "300-1000 true",
    subtitle:
      "単身・扶養なし・iDeCoなし・会社員(協会けんぽ東京・40歳未満・賞与なし・控除式を数値探索) / 1万円刻み",
    limitFn: furusatoLimitTrue,
    showJumps: false,
    simpleCalloutSalaryMans: [440, 650],
  },
  {
    xMin: 1000,
    xMax: 2000,
    output: "furusato_true_1000_2000.svg",
    title: "1000-2000 true",
    subtitle:
      "単身・扶養なし・iDeCoなし・会社員(協会けんぽ東京・40歳未満・賞与なし・控除式を数値探索) / 1万円刻み",
    limitFn: furusatoLimitTrue,
    showJumps: false,
  },
];

for (const chart of charts) {
  const rendered = renderChart(chart);
  await Bun.write(chart.output, rendered.svg);
  const baseStep = median(rendered.diffs);
  const jumpThreshold = baseStep * 3;
  console.log(`[${chart.title}] base step (median): ${baseStep} yen`);
  console.log(`[${chart.title}] jump threshold: ${jumpThreshold} yen`);
  console.log(`[${chart.title}] detected jumps:`);
  for (const j of rendered.jumps) {
    console.log(
      `${fmtMan(j.salaryAfterYen)}: ${fmtYen(j.limitBefore)} -> ${fmtYen(j.limitAfter)} (delta ${fmtYen(j.delta)})`,
    );
  }
  console.log(`Generated: ${chart.output}`);
}

GitHubで会社用とプライベートアカウントを分けよう(問題ないよ)

ask_yoshi_taka — Thu, 28 Jan 2021 15:00:00 GMT

普段使うサービスで、会社用のアカウントとプライベートのアカウントを分けると便利でセキュアですよね？うっかり間違って仕事のデータを大公開してしまうリスクも小さくなります

ただ、日本国内では、アカウント分離はNGで、個人ごとに1つのアカウントに集約しないと規約違反であるという言説が広まっているようです。

![認識共有用に頑張って書いた図。指摘歓迎です](../../assets/github-work-personal-accounts-ok-b00557c3bd78-01.png)

認識共有用に頑張って書いた図。指摘歓迎です

そこでGitHub Supportに事実を確認したところ(英語)、規約違反ということはないという話でした。会社側で有償のオーガニゼーションを契約し、仕事用アカウントを所属させていれば、各自のプライベートアカウントは無料でOKです。

ロジックとしては、オーガニゼーションに所属させているアカウントは有償コーポレートアカウント(名称仮)なので、個人アカウントに対する無料アカウントの複数所持禁止条項は無関係となります。

該当条項

One person or legal entity may maintain no more than one free Account (略).

サポートからの回答(根拠1)

回答のうち重要な部分を引用します。以下は共有許可をもらっています。(太字は筆者)

ポイント1

Yes, that’s right. The 𝗧𝗼𝗦 that we’re discussing here 𝗮𝗽𝗽𝗹𝗶𝗲𝘀 𝗼𝗻𝗹𝘆 𝘁𝗼 𝗽𝗲𝗿𝘀𝗼𝗻𝗮𝗹 𝗮𝗰𝗰𝗼𝘂𝗻𝘁𝘀. As per GitHub’s Terms of Service, a user is only allowed to have a single free, personal account.

ポイント2

So, again, 𝗶𝘁’𝘀 𝗽𝗲𝗿𝗳𝗲𝗰𝘁𝗹𝘆 𝗳𝗶𝗻𝗲 𝘁𝗼 𝗵𝗮𝘃𝗲 𝗮 𝗽𝗲𝗿𝘀𝗼𝗻𝗮𝗹 𝗮𝗰𝗰𝗼𝘂𝗻𝘁 𝗮𝗻𝗱 𝗮 𝘄𝗼𝗿𝗸 𝗮𝗰𝗰𝗼𝘂𝗻𝘁, it’s just that one of them would need to be on the paid plan in order to meet that criteria of our terms!

傍証(根拠2)

英語圏で当件が騒がれていないこと、多数のサービスで一字一句同じ条項が使われていること。特に英語圏のほうがコンプライアンス周り厳しい人多いので、誰かが解説するか、論議が巻き起こるはずなのに1つも見つからないのが不思議でした。

まとめ

GitHubだけが特別ということはありません。素直にアカウントを分けましょう！

SaaSのコスト削減したいなら

Google Sheetsでエドワードタフテっぽいグラフを作る

ask_yoshi_taka — Sat, 15 Mar 2025 03:17:18 GMT

データ可視化のパイオニアである、エドワードタフテ。わかりやすいところなら、キャッチーな脱パワーポイント、6 pagerやWBRといったAmazonの文化にも影響を与えたようです。

その中でもデータインク比という指標が有名で、これを上げたいところ。

もちろんドローイングツールを使い、あとからこつこつオブジェクトを足し引きして加工してもよいのですが、スプレッドシートの機能を活用したほうが再現性が高く、更新時の工数も減ります

というわけでGoogle Sheetsでやってみます。

最初のグラフ

デフォルトのままです

データラベルを使う

各データポイントの詳細な数字を表示することができます。

グラフエディタ-> 設定 -> 系列 -> ラベル

「数値形式」である程度数字を見やすくしておくこと。今回は3桁区切りを追加しました。

データラベルで最後の値だけ数字をつける

系列のデータポイントが多すぎたり、最後(最新)の値だけ重要なら最後の値だけ数字表示をつけましょう。

ラベルは系列とは別の範囲を選択可能です。

最後の行だけ系列と同じデータを入れた列を作り、それをラベルに設定すればOK。

デフォルトだとラベルの位置は「自動」であり右側にはみ出ます。

カスタマイズからデータラベルを「左」あたりにしておきましょう。

同じ方法で最後だけではなく年といった間隔だけを数字表示することができます

凡例ゼロにする場合、数値ではなく文字にして情報を少し追記しておけば、ラベルに表示できます。

データポイントに形をつける

必要そうならポイントのサイズを操作して形をつけましょう。

データポイントが多いなら形をつけると逆によくわからなくなります

グリッドを消す

全データポイントに数値を入れているか、データポイントに形があれば縦罫線は不要でしょう

横罫線も標準だと濃いめなので薄いほうがよいですね

凡例を加工する

ものによっては凡例を消しましょう。

必要なら「位置」を「内側」にしましょう

軸の表示を加工する

X軸、Y軸のタイトルは見ればわかるなら消しましょう。不要な情報です。

Y軸の「倍率」や「数値形式」を操作して桁を圧縮します。

もちろん必要に応じて正規化してください

X軸の時系列も「数値形式」で見た目を圧縮しましょう。傾けるのも一つの方法です。

これでだいたい完成です。労力と可視化のバランスが取れたかと思います。

色や太さは自動のままなのでメッセージに応じて変更しましょう。御存知の通り、色だけで判別させるのは良くない習慣です。

時系列の累積グラフ

各系列ごとに累積させたいなら残念ながら専用の列を別に作る必要があります。

ARRAYFORMULA関数あたりならサクッとできます

(系列同士の足し算は積み上げグラフでOK)

その他

Y軸0始まりの0を消すことはできないようです。必要なら図形で隠しましょう

主グリット線だけデータポイントを大きくすることはできなさそう。月次データで年始だけ強調するなど

重要データポイントへの注釈はグラフ機能だけではできません。矢印などを引いて加工が必要です

最後に

今はChatGPTなどに聞けばやり方は教えてくれます

ゴール設定というかグラフの方針が大事ですね

ほどほどにやりましょう

参考資料

Remove the legend to become one - Remains of the Day (www.eugenewei.com) - When I started my first job at Amazon.com, as the first analyst in the strategic planning department, I inherited the…

How to Reduce AWS Lambda Cold Start Times by Shrinking Deployment Package Size

ask_yoshi_taka — Wed, 23 Jul 2025 15:33:57 GMT

AWS Lambda cold starts are a common pain point for engineers.

This article highlights a practical way to reduce cold start times: keep your deployment package as small as possible.

Why Package Size Matters for Cold Starts

Whenever an AWS Lambda function experiences a cold start, the code package (sometimes a ZIP archive) is downloaded from S3. The smaller the package, the faster the initialization — that’s basic physics.

Furthermore, Lambda enforces a strict 250MB unzipped deployment size limit, and direct uploads are capped at 50MB zipped. Anything larger requires uploading to S3, adding friction to your CI/CD pipeline.

Besides performance, minimizing package size accelerates deployments, reduces the attack surface, and can even improve your CI/CD feedback loop. This principle also applies to Lambda Layers and container-based deployments. Leaner is always better.

Step 1: Audit Your Lambda Deployment Package

First, verify what’s inside your ZIP. Is your code package larger than you expected?

You can download the deployed ZIP from the AWS Lambda console and inspect its contents. On macOS, the following command summarizes directory sizes post-extraction:

du -sh * 2>/dev/null | sort -hr

Step 2: Find Your Biggest Functions (with AWS Config Advanced Query)

If you want to identify oversized Lambdas across accounts, leverage AWS Config Advanced Query:

SELECT
  accountId,
  resourceId,
  configuration.codeSize,
WHERE
  resourceType = 'AWS::Lambda::Function'
  AND configuration.codeSize > 123456789 -- bytes
ORDER BY
  configuration.codeSize desc

AWS Config Advanced Query: SQL-Like Queries for Fast Cloud Insights - Instantly analyze AWS resource configurations across accounts without complex scripts.

You can also use observability tools like Datadog to monitor Lambda function package sizes in bytes, making it easier to spot unusually large deployments across your environment.

Watch out for functions with identical sizes down to the byte. This can indicate misconfigured deployments or duplicate artifacts.

Step 3: Tips for Reducing Deployment Size

Let’s break down optimization tips using TypeScript (Node.js) and Python, two of the most popular Lambda languages.

Audit Your Development Dependencies

Development-only binaries (like mypy) can easily sneak into your production package, sometimes eating up 50MB or more. Even with separate requirements.txt files for dev and prod, transitive dependencies (e.g., via SQLAlchemy) may still bloat your deploy. Always verify your artifacts using both manual inspection and your package manager’s tree/list commands.

Watch Out for Duplicate or Monolithic Artifacts

It’s surprisingly common to see multiple Lambda functions with different names but identical, oversized packages — especially in monorepos. This usually signals a broken build step or poorly configured packaging logic.

Dependency Resolution Pitfalls

We’ve seen cases where multiple versions of native libraries (like OpenSSL) are bundled, doubling the size. Audit your dependencies carefully.

For TypeScript: Apply Frontend Optimization Practices

Never deploy raw code. Always bundle with tools like esbuild.

Backend engineers unfamiliar with frontend practices often overlook this, resulting in massive unoptimized bundles. Use bundle analyzers (e.g., webpack-bundle-analyzer) to visualize and shrink your output.

Prefer ES Modules (ESM) over CommonJS, as ESM tends to produce smaller, more efficient bundles.

Find and Remove Unused Code with Knip

Knip is a tool that scans your TypeScript (and JavaScript) projects to detect unused files, exports, and dependencies.

Use it to keep your Lambda artifacts minimal and free from dead code:

npx knip  # npm
pnpx knip # pnpm
bunx knip # bun

Review the report, and safely remove what you don’t need. This will help shrink your deployment package and reduce the attack surface.

Watch the e18e Initiative

For cutting-edge improvements in Node.js ecosystem package size and startup performance, keep an eye on the e18e initiative. They are working on reducing polyfills, minimizing legacy code, and supporting more efficient modules. While not specifically aimed at serverless, these improvements naturally benefit AWS Lambda and similar environments.

For Python: The .py Purge

Python loads .pyc bytecode, so you can safely delete all .py source files from your ZIP after compilation:

python -m compileall -b .
find . -name "*.py" -delete

The tradeoff: tracebacks won’t show the original source. For production workloads (especially third-party modules), this is usually acceptable — proper error handling matters more than debugging tracebacks.

Reducing AWS Lambda Cold Starts - Introduction AWS Lambda functions with large dependencies can suffer from significant cold starts.

Automate This in CDK

If you use AWS CDK, hook this cleanup into your deployment pipeline for repeatable results.

Node.js 22+: enableCompileCache

Starting with Node.js 22, you can use enableCompileCache().

This leverages V8’s code cache and stores cached bytecode in temporary files.

While I haven’t benchmarked the impact on Lambda yet, enabling this option could potentially improve performance if your deployment environment supports it.

Final Thoughts

AWS Lambda’s abstraction is powerful, but it’s easy to overlook deployment hygiene.

Trimming your deployment size is one of the simplest, highest-leverage optimizations for cold start latency, security, and operational agility — not just for Lambda, but for all serverless platforms.

Less is more. Audit, optimize, and delete ruthlessly.

More resources

The Fastest Node 22 Lambda Coldstart Configuration - Speedrun - Beat bundling by 100 ms.

Best practices for working with AWS Lambda functions - Best practices for using AWS Lambda.

日本でレイターステージの採用が難しい理由

ask_yoshi_taka — Mon, 14 Jul 2025 06:37:14 GMT

スタートアップがレイターステージに差し掛かると、資金に余裕が生まれ、プロダクトも安定し、採用を一気に加速したくなるフェーズに入ります。今までの苦労が報われ、知名度も上がり、ポジションも十分に準備できています。

が、採れない。

こんなに頑張ってるのに…やることたくさんあるのに…人がたくさん必要なのに… なぜでしょうか。

想起はされても応募しない

まずは、自社目線ではなく「求職者の目線」で考えましょう。

「リスクを取って挑戦したい」「裁量のある環境で働きたい」「カオスを楽しみたい」といったタイプの人は、レイターでは物足りなく、アーリーステージのスタートアップに向かうでしょう。

一方で、「安定した企業で働きたい」「ブランドのある会社に行きたい」「技術だけに集中したい」そんな人はメガベンチャーに向かいます。

レイターステージは、このどちらでもない「中途半端な位置」に見られがちです。

求める人物像とのミスマッチ

レイターになると、いわゆる「スタートアップっぽい人材」ではなく、やや保守的な人の応募が増えてきます。

これは、これまでのブランディングや露出の成果でもあります。論理的に言えば、広く認知されればされるほど、そういう層にも届くのは自然な流れであり、むしろそのような層に届いていることが成果の証拠です。

「スタートアップらしさ」に惹かれる人材のパイが限られていることもあり、あえてその外側にいる人を採用し、組織として適応する準備が必要になります。

もっとも危険なのは、表面上の経歴(lineage)、肩書きや知名度がAクラスでも、実力としてはB〜Cクラスの人材がタイミング的に集まりがちなことで、彼らが中核ポジションに入ると、会社の成長そのものに大きなダメージを与えます。

レイターのSaaS全部同じように見える問題

アーリーステージでは、創業メンバーの個性や言葉によって差別化が可能です。面談でも直接その熱量に触れられるため、候補者にとっても「この人と働きたい」「この船に乗りたい」という意思決定がしやすいフェーズです。

一方、レイターステージになると、会社の見た目は判で押したように同じになります。

「SaaS ARR〇〇億」
「プロダクトに手応えが出てきたフェーズ」
「事業成長に伴い人材強化中」
「スケール期のSaaSで社会にインパクトを」

もはや別のレイターステージの会社名と交換しても、おそらく誰も違和感を持たないでしょう。

洗練されることは悪いことではありません。むしろ組織として成熟してきた証です。しかし同時に、それは「語れる独自性が失われる」リスクでもあります。

特に採用市場では、候補者は当然のように複数社を比較検討します。

エージェント・求人票・SNS・口コミ・知人経由など、インプットの経路は限られており、各社が似たタイミングで、似た言葉で、似たメッセージを発信している状態になります。

こうなると、候補者の目には「カタログスペックで比較するしかない」ように見えてしまいます。

加えて、この情報の均質化は、候補者側だけに限りません。実は、採用に関わる側、つまり人事、現場マネージャー、エージェント、面接官も、似たようなインプットに晒されています。

採用のテンプレート的ノウハウ
採用系note・HRメディアで繰り返される「勝ちパターン」
候補者でもありうる採用に携わるメンバーの転職体験・他社比較
競合他社の採用プロセス

など、皆が似たような情報ソースを参照し、似たような“正解”を学んでいるのです。

その結果、「今風の採用をしているつもり」が、気づかぬうちに“他社と同じことを同じように言っている”状態を生み出しています。

つまり差別化できないのは、候補者の比較眼が厳しいからではなく、採用側の発信自体が“テンプレート化”してしまっていることが原因でもあります。

発するメッセージがどこかで聞いたような言葉になるのは、むしろ必然です。差別化ができないのではなく、差別化が崩れていく構造そのものが、レイターステージにはあるのです。

本当に会社が伸びるのか

「IPOで終わり」がまだスタンダードな日本において、レイターステージに入社する意味は、「入ってからさらに伸びていく期待」がなければ薄れてしまいます。

ワクワクしたくてスタートアップに来たのに、成長の手応えがなく、「もう国内の刈り取りしか残っていない」と感じたら、優秀な人ほど他へ流れてしまうでしょう。

特に、国内市場に閉じたビジネスモデルの場合、「天井感」が早く訪れるため、海外展開など、もう一段上のスケール戦略が求められます。一方で海外で勝負となるとさらに一段階経営レベルを引き上げる必要があります。

内情が想像以上に伝わっている

このフェーズでは、退職者も増え、社員数も増え、「社員の知人経由」で社内の雰囲気や実態がかなりの精度で知られるようになります。

つまり、候補者は応募前に「どんな会社か」だいたい把握していると考えるべきです。

逆に言えば、内情を知ろうともしない候補者は、ミスマッチの可能性が高いかもしれません。

自社を、知人に心から推薦できるでしょうか？競合と比べて魅力があると言えるでしょうか？

採用をブーストする前に、まずは魅力の根本を見直す必要があるかもしれません。(プロダクト開発と同じ話ですね)

魅力ある組織にするために採用したいというのは一理ありますが、鶏が先か卵が先か状態です。

レイター特有の問題に対処できる人材がまだ少ない

特に日本では、SaaSやスタートアップのスケール経験が浅く、「組織フェーズの壁」に直面したときにナレッジも人材も足りない状況です。

このフェーズを乗り越えるには、スケール経験者が必要ですが、そもそも数がいません。

これは構造的な問題であり、10〜20年かけて徐々に解消されていくものでしょう。

応募してくれたのにアトラクトできない

ここまでの壁を突破し、カジュアル面談まで進んだのに断られるのは悲しいことです。全員承諾はもともと無理とはいえ、承諾率が低すぎることはレイターステージ特有のなにかがあるかもしれません。

思えばアーリーステージでは創業メンバーが熱を持って直接語りかけていました。今は、最近入社したマネージャーが業務に忙殺される中、気もそぞろに話すだけです。ビジョンはもとより、現場で行われている業務の解像度も追いついていないかもしれません。

「語る人が減っていく」なか、創業の熱と成長の実績を候補者に言葉で伝えられる人を、どう育て、どう配置するかが鍵になります。

月並みですが、カルチャーデックの活用、面接の設計、トレーニングが必要になります。

これらをどうするか

もちろん、上記のような構造的問題をすぐに解決するのは難しいですが、「待遇を上げる」ことは最もシンプルで即効性のある手段です。

「お金ではなく志が大事」という気持ちは大切ですが、それだけで人が集まる時期は、もう過ぎ去っています。

(2010年代ごろの米国ではIPO後の成長なり買収による早期exitが狙えながら、アーリーより確実性のあるレイターステージはある意味狙い目だったという話もありますね)

さいごに

ここで述べたことは、採用だけでなく離職予防の観点でも重要です。

今の採用計画は、現実に即しているでしょうか？

理想論ではなく、「今の会社がどこに立っているか」を冷静に見極める必要があります。

※本記事で言う「レイターステージ」は、主に日本市場における文脈を想定しており、おおむねシリーズC後半〜上場直前（Pre-IPO）のフェーズを指します。アメリカのスタートアップではレイターがもっと長期にわたることもありますが、日本ではこのあたりが「レイター」の実質的な意味合いになります。

Optimizing Queries with Functional Indexes: A Practical Guide

ask_yoshi_taka — Mon, 03 Mar 2025 13:37:09 GMT

Did you know that MySQL 8.0 finally supports functional indexes? We usually think about applying them to JSON columns or for computed functions, but in real workloads, these straightforward use cases don’t always pan out. So, here are some other scenarios where functional indexes can actually shine. By the way, the examples here also apply to PostgreSQL, so feel free to take note if that’s your jam.

Making Comparison Operators Work with Indexes

You’ve probably seen how composite indexes can stop being fully utilized when you introduce a comparison operator somewhere in the middle. For instance, if you have a composite index on (a,b,c) and then run:

WHERE a = 1 AND b > 1 AND c = 1

the query will only use the index on (a,b) effectively — it performs a range scan on b and basically ends there. This is the classic “range scan stops index usage” scenario.

But if you create a functional index like:

CREATE INDEX idx_comp ON TBL (a, (b > 1), c);

You can keep using all parts of the index — a, then the boolean result of (b>1), then c. Think of (b>1) as a helper flag to indicate whether b is greater than 1, so you can still do all your filtering via an index.

However, due to a known MySQL bug, you have to rewrite your query slightly:

WHERE a = 1
  AND ((b > 1) = TRUE)  -- For now, comparing to TRUE is required to trigger the index
  AND c = 1

See the bug report for more details:

MySQL Bugs: #99775: Functional index and equality condition between two columns (bugs.mysql.com) - some addl context: a condition is evaluated as IS TRUE; where a=b behaves like a=b IS TRUE.

Granted, in a simpler scenario like WHERE a=1 AND b>1 AND c=1, you might just build an index (a,c,b). But functional indexes really shine when you need to handle multiple comparisons, like WHERE a > 1 AND b > 1 AND c >1. Something like:

CREATE INDEX idx_comp ON TBL ((a > 1), (b > 1), (c > 1));

plus a slight tweak to the query can solve otherwise painful multi-range queries.

Downsides

You’re hardcoding constants into the index. That means if the threshold changes, the index definition also needs to change.
Logic is now in your index. Whenever that logic changes, you have to remember to update the index, too.
For now, because of the MySQL bug mentioned, you usually need to modify your query syntax a bit.

Using an Index for NOT Conditions

Here’s the deal: negation (NOT) conditions often cause your composite index to behave like it does with simple comparisons, meaning it may drop out after the first column and revert to a range scan. For example, if you have an index on (a,b,c) and you do:

WHERE a = 1 AND b <> 1 AND c = 1

The DBMS will likely only make full use of (a) and partially use (b) before giving up. It’s basically the same phenomenon we saw with comparisons like b>1.

To fix that, you can convert the b<>1 logic into a function that returns a boolean-like result. One straightforward technique is to use the absolute value function as a “flag generator.” For instance:

CREATE INDEX idx_comp ON TBL (a, (ABS(b - 1) > 0), c);

By doing ABS(b-1), you’re effectively calculating the distance from 1; if that distance is greater than 0, it means b is not equal to 1. Then, in the query, you’d do:

WHERE a = 1
  AND ((ABS(b - 1) > 0) = TRUE)
  AND c = 1

That little hack treats (ABS(b-1)>0) as a stored “flag” in the index, so the optimizer can keep walking through (a,(ABS(b-1)>0),c) in a single pass.

Pro tip: If you don’t want to compare against =TRUE, you could index (ABS(b-1)) itself and then just do WHERE ABS(b-1)>0. That’ll work too — some people find it a bit cleaner.

This trick isn’t limited to just a single negation either. If you need multiple negative conditions, or a mix of > and <>, you can set up your functional index with several boolean-flavored expressions.

Downsides

Same as the comparison operator downsides, plus the rewrite in the query is a bit more confusing.
You do have to rewrite the query, whereas with a normal index you wouldn’t.

OR Conditions and Indexing

OR conditions are notoriously tough to optimize using a single index. If you do something like:

WHERE price > 100 OR stock < 50

The database usually picks either price or stock to use for an index range scan, not both. If the logic was trivial, you could rewrite this as two separate queries with a UNION, but that’s not always feasible.

One workaround is to transform OR logic into a function, then build a functional index on that. For example:

CREATE INDEX idx_greatest_price_stock ON products (
    (GREATEST(price - 100, 50 - stock))
);

Then rewrite your condition to:

WHERE GREATEST(price - 100, 50 - stock) > 0;

So if either condition “triggers” (price > 100 or stock < 50), GREATEST(...) will be above 0, and the index can handle it.

Column IS NOT NULL

A check like column IS NOT NULL might turn into a range scan as well. But if you create:

CREATE INDEX idx_f ON TBL ((column IS NOT NULL));

and then query:

WHERE (column IS NOT NULL) = TRUE

It can prevent that from degrading into a range scan. Think of it as a “pre-check” for nulls.

Flag IS NOT TRUE

If you have a three-valued column, say TRUE, FALSE, or NULL, it’s usually best to redesign it to avoid tri-state booleans. But if you’re stuck, you can do:

CREATE INDEX idx_f ON TBL ((flag IS NOT TRUE));

And then:

WHERE (flag IS NOT TRUE) = TRUE

Boom, you now have an index-based approach.

Text Matching

Comparing long text fields can be expensive, and indexing them can be overkill too. One old-school trick is to store a hash of the URL:

WHERE url_crc = CRC32('https://www.example.com/')
AND url = 'https://www.example.com/'

Previously, you had to keep a separate column url_crc. But now, with functional indexes, you can do:

CREATE INDEX idx_crc ON TBL (CRC32(url));

So you don’t need an extra column if you just want to speed up those lookups (though your query does still have to use CRC32(url) for the condition). This approach also helps if you’re dealing with huge text-based keys or if, for some reason, you used a VARCHAR-based UUID as a primary key (not recommended!). You can convert it to an integer or shorter hash on the fly and let the index handle the rest.

Transforming IN / BETWEEN

IN and BETWEEN queries often lead to range scans as well. You can theoretically do something like:

CREATE INDEX idx_in ON TBL ((ids IN (0001, 0002)));
CREATE INDEX idx_bet ON TBL ((ids BETWEEN 0001 AND 0002));

This is only really viable if you have fixed values or a small range you care about. It’s a pretty niche scenario but can help in edge cases.

Converting Any Range Scan Into a Functional Index

If you can live with the constant values inside your index definition, you can convert almost any range-based query into something that uses a functional index. For example, even LIKE 'STR%' can be turned into:

CREATE INDEX idx_l1 ON TBL ((str LIKE 'STR%'));

…but obviously, that’s only useful if ‘STR’ is fixed. For partial matches like mid-string or end-of-string, you could do:

CREATE INDEX idx_l2 ON TBL (SUBSTRING(str, 5));

To handle some substring lookups (for example, searching by a domain in email addresses).

ORDER BY

The same concept applies to ORDER BY. If your WHERE condition becomes a range scan, you might lose index-based sorting. But if you can turn part of the WHERE logic into a function, you can keep all your sorting inside the index. For example:

WHERE a = 1 AND b > 1
ORDER BY c

usually means you lose ordering by c. But with:

CREATE INDEX idx_comp ON TBL (a, (b>1), c);

you can index from a all the way through c. If you need (c,b) ordering:

CREATE INDEX idx_comp ON TBL (a, (b>1), c, b);

And if you’re sorting on something like (a+b), you can also create a functional index on (a+b).

Other Use Cases

Date-based filtering, like indexing YEAR() or DATE().
Price calculations in your queries.
Case conversions (UPPER(), LOWER()).
Rounding functions like FLOOR().

Just note that nondeterministic functions (e.g., RAND()) can’t be used in functional indexes.

Comparison of Similar Features

Here’s a quick table comparing approaches. Moving from left to right, the column is “closer” to being a real, physical column.

Each option shifts where and when you pay the cost. If you only need the computed value for filtering, a functional index is handy. Keep in mind any index will add overhead for updates.

In other words, functional indexes store the “precomputed” result inside the index itself, letting you filter on it without adding a new column. But there’s always the tradeoff: if this is part of your fundamental logic, maybe consider re-architecting to keep your data model clean.

Wrap-Up

By encoding logic into functions, you can greatly expand how you leverage indexes. It’s a powerful trick for queries that would otherwise suffer from partial index usage, range scans, or expensive lookups on big text columns. At the same time, be aware of the maintainability tradeoffs — hardcoding constants and rewriting queries can accumulate technical debt if not revisited later.

Production Readiness Checklist: Avoid Commonly Overlooked Mistakes

ask_yoshi_taka — Mon, 17 Feb 2025 13:36:27 GMT

Think your team is fully prepared for launch? You might be missing some critical steps.

Most teams have a Production Readiness Checklist, but even well-prepared organizations overlook crucial risks that can cause downtime, rollbacks, or post-launch chaos.

Did you align your release with marketing campaigns to prevent mismatched user expectations?
Is your rollback plan not just documented, but actually practiced?
Have you tested synchronization across external services, or just assumed it will work?

Small gaps in preparation can lead to major failures. This checklist highlights the commonly overlooked but high-impact areas to ensure a smooth, failure-resistant launch.

Let’s dive in. 🚀

Marketing Readiness: Are You Prepared for Launch-Day Campaigns?

A product launch isn’t just about shipping code — it’s about delivering a seamless user experience. If marketing and engineering aren’t aligned, users might see ads for features that aren’t live yet, leading to confusion and frustration.

Press releases
Social media campaigns
Advertising campaigns
Paid search ads
Advance schedule notifications for enterprise customers

👉 No marketing events planned? Ensure your release strategy accounts for user engagement and visibility.

Release Playbook: Documenting Steps & Rollback Plans

A rollback plan is only as good as its execution. Have you tested it under realistic failure conditions?

Step-by-step release guide is documented
Rollback plan is in place
Dry run has been conducted
Rollback procedure has been practiced
Clear criteria for halting the release are defined
Potential fallout is understood in case of failure

Quality Assurance: Testing on Rare Devices & Critical Environments

A last-minute bug in an edge-case environment can delay the entire release. Is there a process in place for handling unexpected failures?

Easily test on niche or uncommon but critical devices
Seamlessly verify functionality in rare yet essential environments

Have you verified synchronization with external services, systems, or infrastructure?

Not yet
Not yet, but there’s still buffer time to resolve any potential issues
Connections successfully tested
Application executed, and results appear correct

Crisis Readiness: War Rooms, Communication, and Contingencies

Crisis situations require rapid coordination and clear decision-making. Ensure these protocols are in place before launch.

War room set up with decision-makers on standby — Ensure all key personnel are available and aligned.
Necessary tools and resources prepared— Incident response tools, monitoring dashboards, and communication platforms should be pre-configured.
Video calls arranged for remote teams— Ensure seamless communication across locations.
Video links available for teams on different floors or rooms— Critical for large organizations with distributed teams.
Snacks and meals organized— A well-fed team performs better in high-pressure situations.
Rest areas accessible— Burnout during crisis handling is real. Provide spaces for breaks.
Contingency plan in place if transportation options are no longer available— Consider how late-night deployments impact team logistics.
System established to capture user feedback — Monitor real-time issues reported by users.
Handoff plan ready if the crisis extends — Ensure the next shift can seamlessly take over if needed.

Rollout Strategy: Gradual Expansion vs. Full-Scale Launch

Limited rollout — Best for complex changes, high-risk updates, or when monitoring early adopters before full deployment.
Full-scale release — This option should be avoided whenever possible. If chosen, ensure executive leadership is fully aware of the risks and has explicitly signed off on the potential impact of failure. A failed full-scale release can lead to extended downtime, severe customer impact, and reputational damage.

Regardless of the approach, a solid rollback plan must always be in place.

Final Confidence Check: Are You Truly Ready to Ship?

Fully prepared and confident for launch — Final review completed, green light given.
All team concerns have been addressed — Ensure no lingering doubts remain.
Some team members may still have unspoken concerns if asked privately — Conduct last-minute check-ins with key team members.
Potential risk areas have been identified

If any of the above points remain uncertain, take action now before proceeding with the release.

Conclusion

A successful launch isn’t just the responsibility of one team — it’s the result of seamless cross-functional collaboration. Whether you’re an engineer, product manager, SRE, or marketing lead, your role is crucial in making sure everything aligns before going live.

This checklist isn’t just a formality; it’s a tool to proactively identify and close gaps before they turn into major failures. Every overlooked detail — whether it’s a missing rollback test, an uncoordinated marketing push, or an unverified external dependency — can impact the entire launch.

✅ Take ownership beyond your role. If you see a gap, raise it.

✅ Collaborate cross-functionally. A smooth launch requires alignment across engineering, operations, and business teams.

✅ Drive the release to success. A launch isn’t done when the code ships — it’s done when customers experience a seamless transition.

No matter your role, shipping a great product requires an all-hands-on-deck mindset. Let’s make this launch a success — together. 🚀

Python Defaults That Hurt Performance

ask_yoshi_taka — Fri, 03 Apr 2026 15:00:00 GMT

Python is often described as slow.

In practice, however, much of that perception comes not from the language itself, but from relying on its defaults.

Python prioritizes readability and backward compatibility. As a result, its default settings are not always optimized for performance.

In this article, we’ll look at a few common “default traps” that are easy to overlook in production systems.

Running an outdated Python version

Python versions have a direct impact on performance.

Starting from Python 3.11, the Faster CPython project has introduced significant interpreter-level optimizations with each release.

Despite this, older versions are still widely used due to compatibility concerns, operational constraints, or simply because tutorials and onboarding materials lag behind.

This is one of the simplest—and most impactful—performance traps.

New versions are typically released around October each year, so it’s worth keeping track.

Status of Python versions (devguide.python.org) - Official page showing the lifecycle and support status of Python versions.

Using the standard json library by default

Python’s standard library is reliable, but not always fast.

In many other languages, high-performance JSON handling is closer to the default experience. In Python, this is not necessarily the case.

Given how central JSON is—across APIs and data processing alike—the standard json module can become a bottleneck, especially in CPU-bound workloads.

Libraries such as orjson or simdjson are often worth considering.

ijl/orjson: Performance (github.com) - Performance benchmarks and comparison charts from the orjson README.

Recreating HTTP/TCP connections (e.g., boto3)

Connection reuse and pooling are widely supported across modern languages and libraries.

However, how much benefit you get “by default” depends heavily on API design and usage patterns.

In Python, it is easy to write simple code that unintentionally recreates connections on every request. Without explicit configuration, you may not benefit fully from keep-alive or connection pooling.

For example, libraries such as boto3 or requests require careful handling of connection reuse.

If left unaddressed, repeated connection setup can increase both latency and cost.

Programming DynamoDB with Python (Boto3) (docs.aws.amazon.com) - AWS documentation covering best practices such as connection reuse and timeout strategies.

Converting iterables to lists too early

Python makes heavy use of iterators.

While lazy evaluation and streaming are widely emphasized across modern languages, it is still common in Python to eagerly convert everything into lists.

This pattern can lead to:

unnecessary memory allocation
repeated full scans of data

As data volume grows, this can become a significant performance issue.

Avoid designs that repeatedly convert iterables to lists, process everything, and then reconstruct iterables again. Pay attention to how many full passes your code performs.

Blocking I/O and synchronous execution

Python code is often concise, but it can hide significant I/O wait time.

If you simply write API calls in sequence, they will execute sequentially. In many cases, these operations are also blocking, meaning no other work is done while waiting for I/O.

Modern languages often provide stronger default support for asynchronous execution.

In Python, however, concurrency typically needs to be introduced explicitly.

When your workload is dominated by I/O latency, using async or parallelism can significantly improve throughput.

Tooling also matters (uv, ruff)

Python’s tooling ecosystem has long been fragmented, but fast, modern tools such as uv and ruff have gained rapid adoption.

These tools are designed to be fast even with minimal configuration, and can noticeably improve the developer experience compared to traditional toolchains.

For new projects, they are worth considering.

uv (docs.astral.sh) - Official documentation for uv, a fast Python package manager, virtual environment tool, and runner.

Pythonのハマりどころ: そのまま使うと遅くなる理由

ask_yoshi_taka — Fri, 03 Apr 2026 15:00:00 GMT

Pythonは遅い、とよく言われる。

しかし実際には、その多くは言語そのものの問題ではなく、「デフォルトのまま使っていること」に起因している。

Pythonは可読性や後方互換性を重視した設計であり、初期設定は必ずしもパフォーマンス最適ではない。

本記事では、実運用で見落とされがちな初期設定の罠をいくつか取り上げる。

古いバージョンを使い続ける

Pythonのバージョンは、そのまま性能に直結する。

特に3.11以降では、Faster CPythonプロジェクトにより、バージョンごとにインタプリタレベルでの最適化が大きく進んでいる。

にもかかわらず、互換性や運用、チュートリアルやオンボーディングの都合で古いバージョンが使われ続けるケースは少なくない。

これは最も単純で、かつ影響の大きい「罠」である。

新しいバージョンが毎年10月ごろにリリースされるので確認しよう。

Status of Python versions (devguide.python.org) - Pythonの各バージョンの状態とサポート期間を確認できる公式ページ。

標準jsonライブラリをそのまま使う

Pythonの標準ライブラリは信頼性が高い一方で、必ずしも高速ではない。他言語では高速なJSON処理が標準で提供されることも多いが、Pythonではそうではない。

アプリケーションにせよデータ分析にせよほとんどがjsonを操作する時代、特にjsonモジュールが遅く、スピードやCPU負荷に影響しがち。orjsonやsimdjsonといった高速な実装を利用しよう。

ijl/orjson: Performance (github.com) - orjsonのREADMEにある性能比較とベンチマーク。

HTTP/TCP接続を使い捨てる（boto3など）

近年の言語やフレームワークでは、接続再利用やコネクションプーリングが標準的に提供されている。ただし、その恩恵をどの程度「デフォルトで受けられるか」は、API設計や利用方法に依存する。

Pythonでは、シンプルに書いたコードが結果として接続を使い捨てる形になりやすく、明示的に設定しなければ最適な動作にならない場合がある。

例えば多くのHTTPクライアントは、特別な設定をしない限り、接続の再利用が十分に活用されない。boto3やrequestsなどでは、TCP接続のkeep-aliveやコネクションプーリングの設定が重要になる。

これらを意識しない場合、不要な接続確立が繰り返され、レイテンシとコストの両方に影響を与える。

Programming DynamoDB with Python (Boto3) (docs.aws.amazon.com) - boto3利用時の設定やコネクション再利用、タイムアウト方針などを説明するAWS公式ドキュメント。

iterableをすぐにlistに変換する

Pythonでもイテレーターをよく使う。遅延評価やストリーム処理は多くの言語で重視されているが、Pythonではlistへの変換が安易に行われがちである。

このパターンは、

不要なメモリ確保
無駄な全件評価

を引き起こす。

特にデータ量が増えたとき、顕著な性能低下につながる。 listに変換して全件処理してはiterableに戻す、といった処理を繰り返す設計は避けよう。何度も何度も全件処理してないか確認すること。

ブロッキングI/Oと同期処理に注意

Pythonのコードは簡潔に書けるが、その背後でI/O待ちが発生していることは少なくない。

同期的なAPI呼び出しをそのまま並べると、処理は逐次実行される。さらに、多くの場合これらはブロッキングI/Oであり、待ち時間のあいだ他の処理を進めることができない。

モダンな言語では非同期処理が標準的に組み込まれていることが多いが、Pythonでは明示的に設計しなければ逐次実行になる。

I/O待ちが支配的なワークロードでは、asyncや並列処理を導入することで、スループットが大きく改善する場合がある。

uvを使おう

Pythonの開発環境は長らく分散していたが、近年はuvやruffといった高速なツールが急速に普及している。

これらは初期設定のままでも高速に動作するよう設計されており、従来のツールチェーンと比較して開発体験に差が出る。

新規プロジェクトでは必ず使おう。

uv (docs.astral.sh) - Pythonのパッケージ管理、仮想環境、実行を高速化するuvの公式ドキュメント。

リモートファーストによりフラット化が進み、フルリモートを否定する組織は生きた化石になる

ask_yoshi_taka — Sat, 20 Nov 2021 06:55:30 GMT

![太古の特徴をそのまま残すシーラカンス wikipediaより](../../assets/remote-first-flattening-full-remote-fossil-f3fff80977e3-01.png)

[太古の特徴をそのまま残すシーラカンス wikipediaより](https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Latimeria_Chalumnae_-_Coelacanth_-_NHMW.jpg)

今後の働き方についてフルリモートワークのままにするか、オフィスに戻るか…個人的に悩んでいる方、組織全体で検討している方も多いでしょう。個人レベルの利点なら通勤時間の削減、引っ越しによる豊かな環境、柔軟な仕事の仕方といった面はよく謳われています。組織レベルでも出張代や時間の削減、オフィス賃料の削減、採用の優位性などは実感できるのではないでしょうか。

実は、全員フルリモートワークを前提とするリモートファーストには前記以上に組織全体を進化させる大きなメリットがあります。以下、なぜフルリモートワークを組織レベルで推進すべきか説明します。

フラット化による心理的安全性の担保
非公式的な経路依存を削減
組織の成長力アップ

＊なんらかの理由で対面業務や物理的作業が発生する職種は除きます。

フラット化による心理的安全性の担保

はじめに、物理的なオフィスを考えてみましょう。古代より権力者は豪勢な建物で権勢を見せつけてきました。現代の大企業幹部も同様です。メンバーのいる場所より高い階層、豪華な部屋、分厚いドアを好んできましたし、従業員側もそのような場所に入るときに萎縮したり、そもそも近づくことを好まない様子が見受けられます。

本社勤務とその他の事業所や地域での有利不利、中央と周辺の関係に悩んだことのある方もいらっしゃるでしょう。権力者と文字通り近いことがその人物にもパワーを与え、逆もしかりです。

組織階層の上位にいる人物は尊重されたい、権力を行使したいと、意識的または無意識的に考え、下位にいるメンバーもそれを敏感に感じ取ることに長けています。

以下の論考には物理的なオフィスならではの興味深い事例が多数記述されています。オフィスにおける人間・組織を動かすパワー・ゲーム ―体験・見聞事例からの考察―

私が知っている企業幹部は手はじめにブルーの絨毯を自分のオフィス部屋に敷いた。次に、家具のおおいをブルーの布に変え、壁やブラインドまで青く塗り直した。やがて秘書の椅子もブルーになった。その幹部のパワーが大きくなるにつれ、ファイル・キャビネットや床、コーヒー茶碗までブルーに変えていった。ほかの幹部はそれほど色に凝っていなかったので、ブルーの威力は驚くほどで、まもなく彼のシンボルカラーになってしまった。部下たちも周囲に合うからといってブルー系統の服を着るようになり、はじめは冗談のつもりがやがて忠誠を示すシンボルになってしまった。

他には、業務とは直接関係のない、無意識のイメージによって、特定の人物が有利になったり不利益を被ったりします。アンコンシャス・バイアスと呼ばれ注目されるようになってきました。

体の大きさ、性別(男性であること)、服装や顔つきといった外見的特性が有利になることを実証した研究も複数あります。この中には声質や声の(物理的な)大きさ、発音やイントネーション、話し方も含まれます。

今まで述べてきたことが心理的安全性に反すること、心理的安全性が優れた組織には重要な要素であることは繰り返すまでもないでしょう。

ところが、リモートワークにより物理的に会わなくなったことで、これらは無効化されました。なんとか画面上で威厳や品格を発揮しようとも、大きくないディスプレイのさらに小さなウィンドウ、自宅のすぐ途切れるwifi回線では、スーツもネクタイも識別できません。人間は服装といったちょっとしたシグナルから敏感に権威性を判断するわけですが、それらがほぼ0になります。

権力を行使する相手がいないこと、権力が行使できないことが、経営層がオフィスに戻りたがり、従業員がそうでもない大きな理由の一つでしょう。

フルリモート組織でパワーゲームが完全になくなったとは言えませんが、余地が減ったことは間違いありません。

逆に、従業員側の力は向上しました。長い説教(と称したなにか)をされても、リモートではミュートや音量調整でやり過ごすことができます。録音録画から外部の力を使った反撃も可能でしょう。

女性なら慣習的に必要とされたメイクの手間と時間が削減され、身体的に移動が難しい人、じっとしていることが難しい人は、特に日常生活に支障を感じていない人と同様に働けるようになりました。マイクもスピーカーも品質がよくないため、声による影響も削減されました。リモートワークでは顔が見えないとよく言われますが、バイアスの点ではそれが逆にプラスになります。とにかく成果やアウトカムに集中したい人も過ごしやすくなりました。フルリモートワークはD&Iを支える基盤となります。

成果に関係のない、パワーゲームに対応している時間が削減されたことも喜ばしいですが、それ以上にバイアスが削減され、評価が公平になる。適材適所で抜擢される。文字通り全員がリモートワークで働くことにより、各自が公平に評価されると同時に公平に人を評価し、心理的安全性が高まり、卓越した組織となるでしょう。

個々の生産性が向上したこと以上に、組織の向き先が変わることが違いを生みます。目的地に早く到着したいなら、個々の速度の足し算はもとより、皆で協力し目的地の方向へ進路を向け続けることが鍵です。

非公式的な情報経路への依存を削減

リモートワークで雑談ができなくなったとこぼす人は多く見受けられますね。

非公式な情報パスは有益ですが、情報の非対称性が大きいのが欠点です。前時的な事例ですがタバコ部屋やゴルフ場、居酒屋でものごとが決まるという事例も古い資料には出てきます。

ちょっとした雑談による情報収集で優位性が生まれます。雑談は軽く見られがちですが強力で、オフィスなら遠隔地在住の方、家庭の事情がある方、雑談にマイクロアグレッションが含まれそれが不快な方は参加が困難です。情報の流れをコントロールすることでパワーを行使するタイプもいます。組織デザインではキツネと呼ぶようです。

このようなときはまず無駄をとり、その後冗長性を付け加えることが効果的です。情報共有の時間、コミュニケーションの時間を制度として設けるのが妥当ではないでしょうか。

加えて、チャットツールやコラボレーションツールといった道具の力を借り、公式な情報経路を最適化しましょう。週次会議で情報共有するとします。3階層あったとして、最上層の会議での報告から考えると、最悪のパターンで全員にその情報が届くには約2週間かかります。定例会議で情報を降ろしていく流れは、ITがなかった時代のものです。

組織の成長力アップ

完全フルリモートなら、全国から採用が可能です。採用の対象も広がり、オフィスでは働きづらい方も視野に入ります。採用市場が今後ますます厳しくなるなか、スケールしやすくなりますね。

顧客も全国がターゲットとなります。ITやデザイン、その他対面が必要のない業種なら、地方から大都市に挑戦することも可能です。市場規模が広がります。

特筆すべき点として、今まで地域によって細分化された市場がまとまり、プレイヤーが増え競争が盛んになることで、採用にせよ販売にせよ競争力が磨かれます。対してオフィス前提の組織は好意的に見て現状のままでしょう。東京外の給与水準も上昇余地がありますね。

今までフルリモート組織が少なかった理由

上記3点のメリットがありながら、今までフルリモート組織は少なかった理由として、誕生から浸透まで時間がかかったことが挙げられます。フルリモート企業を支えるIT基盤となるプロダクトは主に2010年代に生まれているためです。

ところがコロナ禍で世界中で状況が変わり、ほぼ全員がリモートのなにかしらを体験しました。フルリモートが可能であることを認識(Situational Awareness)し、存在が当たり前になりました。新しい概念を売り込むときに難しい点は認識を変えることです。認識が変わらないと検討さえしてもらえません。しかし、2020年に従業員も幹部も顧客も採用候補者も突然認識が変わり、突然フルリモート組織との付き合いが遡上にのぼるようになりました。今フルリモート組織が受容され始めた背景です。

フルリモート組織が効果的な条件

新しいものを受け入れるにあたり、行動やプロセスが変わらなければ効果が薄くなります。リモートワークであってもスーツを着ているような習慣が続くようでは成果はおぼつかないでしょう。

新しいものを受容するときは、新しい慣習を身につけることで初めて大きな差が生まれます。人によってはOSのインストールに例えることもあります。

テクノロジーの例えになりますが

🙈 新しいもの + 古いプロセス e.g. AWSでウォーターフォール
🙈 古いもの + 新しいプロセス e.g.オンプレミスでアジャイル
😊 新しいもの+ 新しいプロセス e.g. AWSでアジャイル

ものごとと慣習、両方を変えることで高い相乗効果を生みます。

ハイブリッドワークではだめなのか

上記の3点で語られている課題はすべて、オフィスから発生します。慣習的に出社するメンバーが存在する限り、意識的または無意識的に、オフィスにいる従業員やいるタイプの従業員が有利なようにものごとは進むでしょう。

また慣習については一般に、相反する2つを組み合わせたハイブリッドというのは不可能です。成果を出したいならどちらかしかありえません。

＊テクノロジー業界の話ですが過去にプライベートクラウドというものがマーケティングメッセージとして生まれ、立ち消えました。

まとめ

次の10年の壁を乗り越えるにあたり、リモートワークを受容し、新しい慣習を身につけたフルリモート組織が優位に立つでしょう。何より働きやすく、安全で協力的な職場です。

ぜひみなさんもフルリモート組織への転職を検討したり、組織を生み出したりしてみてください🥳

SaaS事業者やCTO/CEO/CFOのためのテクノロジー/セキュリティDD入門…でありDD必要ということだけは覚えておいてください

ask_yoshi_taka — Wed, 03 Jul 2024 08:32:38 GMT

SaaS事業者がSaaS等を買収する際、セキュリティやテクノロジーDD(デューデリジェンス: ざっくりいえば買収先に対する状況調査)を怠る事例が多発しています。

開発面やセキュリティによる事業リスクが見過ごされ、買収してから問題が表面化、買収失敗で特別損失の計上を株主に伝えることになるでしょう。毎回PMI(買収後のプロセス)で担当エンジニアやCTOが悲鳴を上げています。 (買収前にちょっと中身を見ただけでわかるレベルなのに…どうして😭😭) 投資家からの怒号、社内からの悲鳴は避けたいですね。

もちろん財務や事業、法務、人事、コーポレートITといったバックオフィスといったところはDDで精査しているのですが、なぜか技術面だけぽっかり穴が空いています。

米国では当然に行われるのになぜ日本では行われないのでしょうか。

日本でやらない理由

個人的な予測です。

(1) 本やweb記事に書いてないから

Big 4が出すような資料を定期的に確認してますが、テクノロジーやプロダクトセキュリティDDには言及がありません。各社の専門外というのはありそうですがチェック項目にすらないことがほとんどです。

(2) 誰もやっていないから

人は真似するもの。M&A、特にDDは回数も関わる人数も少ないので良い経験も積みにくいでしょう。

外部のM&A支援コンサルだと回数積みやすいのですが、結局やってないので0になにを掛けても0です。

聞き及ぶところでは一部のメガベンチャーではテクノロジーDDを行っているようですが少数派です。

(3) 国内SaaS同士の買収の実績がまだ少ないから

失敗例や成功例が伝播できてない状態です。

(4) IT DDでカバーできそうな気がするから

IT DDは多くのM&Aマニュアルに記載があります。ITとあるのでプロダクトも含まれそうですが実際は社内システムといったコーポレートITだけです。もちろん社内IT統合はコスト効率化の面で重要な観点ですがプロダクトとはまた違います。

(5) エンジニアリングが軽視されているから

プロダクトを買収する以上、エンジニアリングの重要性は全体の5割とはいいませんが数割を占めるでしょう。単純に全社員における人数でも数割占めることがあります。一方、M&Aは長期経営計画における重要トピックの一つです。この状態でテクノロジーDDを無視するということは経営陣がエンジニアリングを軽視していると考えざるを得ません。結局全ては言葉ではなく行動です。

M&AにCTOが介在しないケースも見聞きします。機密保持のためDDは人数が絞られるとはいえ、さすがに成功させるのは無理があるでしょう。

リスク項目とアセスメント

どんなところを見ればいいのかの一例です。DDレベルだと大きなインパクトがありそうなところだけになります。

開発体制

M&Aは買収先に大きく伸びてもらうのが目的の一つです。

まずは開発は外注しているのか、開発メンバーのうち社員の割合はどの程度かを確認しましょう。内部統制にも関わる事項です。

その後買収先のスキルレベルをアセスメントしましょう。技術者外だと判断しづらいですが見る人が見れば一発でランクがわかります。補助的に各種成熟度確認ツールをつかうのもありです。

買収先が自社より明らかにランクが低い場合、(買収を見送ることをおすすめするものの)人を投入することになるでしょう。

過去1年程度のインシデント状況とその対応を確認しましょう。インシデントに追われている状態で追加機能開発は困難です。

コードベース / アーキテクチャの確認

DDは期間も人数も限られており、コードベースの確認に力を入れることはできません。アーキテクチャレベルの確認が主になるでしょう。

AWSであれば以下の記事も参考にできます。AWSの参照権限をもらったり資料をもらうのはなかなか大変ですが、領収書はPDF一つで明確な事実が確認できます。

あとはFour Keysといった外部のパフォーマンス基準も使いましょう。その中でもリリース頻度だけ聞けば実力がおおよそわかります。

大まかな技術的負債とその対応予定も聞きましょう。

プロダクトセキュリティ

まずは外部脆弱性診断機関からの診断結果を説明してもらいましょう。

自社でセキュリティエンジニア、特にレッドチーム側の人材を抱えていればスキャンが可能です。法律と常識、モラルの範囲内で確認し、セキュリティリスクが多ければ買収金額の交渉材料となります。

自社や標準的な開発セキュリティ基準に当てはめて開発状況を確認しましょう。SecurityHubの依頼ぐらいはできるのはないでしょうか

個人情報や決済関係データの保有状況を忘れずに。

技術スタックに合わせ、ライセンス周りの遵守状況も確認が必要です。リスク多し。

セキュリティポリシーや過去のセキュリティインシデント一覧ももらいましょう。

テクノロジーコスト

プロダクトのユニットエコノミクスはどうか。AWSなら領収書も見ながら削減ポテンシャルを確認しましょう。

開発系メンバーを自社標準のSaaSに組み込むときに追加費用はどれくらいか。

契約チェックの一環としてベンダー契約のコミットメント状況や長期契約を合わせて見ます。

DDでやること

CTOを巻き込む

CTO抜きで話が進み、青天の霹靂となることがあります。プロダクトが重要なら早めに巻き込みましょう。DDの失敗をPMIで巻き返すことはできません。

脆弱性診断の結果をもらう

ある程度真面目に開発している会社ならば外部脆弱性診断は実施済みのはずです。結果と対応計画を提出してもらいましょう。

外部脆弱性診断にもレベルがあり、脆弱性診断会社にも能力差があります。診断能力が低いと重要な脆弱性を見過ごします。

以下のラック社の表でいうLV 2が最低限確認したい診断結果です。

自社にセキュリティエンジニアが在籍していれば診断を行った機関のレベルを確認できます。

深刻な脆弱性が多かったり、修正する能力やキャパシティがないようだったりするようなら買収見送りも検討しましょう。

もし直近の診断結果が存在しないようなら計画を立ててもらいましょう。(診断依頼の費用負担は売主側だと思います。)

そもそも診断がない場合はその時点で能力が怪しく、PMIにコストがかかることを想定しましょう。

公開リソースを確認する

公式サイトや採用サイト/求人広告からおおよそのアーキテクチャを推測できます。

開発ブログ含めた採用露出を確認しましょう。技術内容のほか、採用力がわかります。

プロダクトがさわれるならChrome DevToolsやスキャンツールでアーキテクチャや利用技術、バージョンまである程度特定できます。

AWS等の領収書をもらう

前述のとおりです。

追加情報として、代理店が介在していればAWS Organization統合の難易度が上がります

開発ドキュメントをもらう

アーキテクチャや開発プロセスを確認します。

まずドキュメントがあるか確認しましょう。すぐに出せる資料がないなら危険信号です。

体制イメージとロードマップを検討する

今後体制をどうしていくのか。特に自社とのギャップがある場合どう引き上げるのか。日本では解雇が難しいため例えば自社では採用しないレベルのメンバーについてはどう育成したり別のポジションを用意したりするのか。

開発体制や技術標準は自社と揃えるのか、ばらばらにするのか。統制を考えればなるべく高い方に揃えたいですね。

子会社は採用しづらいことがあります。母集団形成は自社と同じように行うのか、別々なのか。そもそも自社の採用に困っている状況で子会社の支援ができるのか。

誰が子会社との間に立つのか。100%稼働が取れる人を割り当てるのが望ましいです。

支援する場合何人ぐらい必要なのか。自社からどれくらい送るのか。送ることができる状況なのか。

いくつかPMIにまたがって行う項目も記載しましたが、実行計画がイメージできないなら買収を控えたほうが良いでしょう。

特にプロダクトセキュリティ関係の実行計画を立てる

例えばアプリがどうしようもないならWAFでしのぐしかありません。脆弱性対応で開発がストップも考えられます。

AWS APIレイヤーで検知や統制するならSecurity Hubなど含め追加コストがかかります。

なににせよコストがかかるので予算を抑えておく必要があります。

自社システムとのデータ連携、API連携方法を検討する

連携しないなら買収する意味はないでしょう。

新規開発予定を確認する

自社ロードマップとのすり合わせが必要です。

その他確認事項

過去のインシデント事例一覧をもらう。セキュリティも含む
セキュリティポリシーの有無を確認する

見えてきたリスクをもとに、法務等担当者に相談しましょう。買収金額や契約条件の交渉に反映させる必要があります。今後かかるコストも想定しておきましょう。

PMIからどう巻き返すか

DDの時点でなにもせず買収してしまった時点で内容は運を天に任せるしかありません。DDの内容をカバーしつつ、より具体性を伴わせる必要があります。撤退戦が一番難しく、負け戦は負け方が大事です。

一にも二にもセキュリティ

とにかくプロダクトセキュリティを優先してアセスメントおよび改善していきましょう。その中でも特にデータ侵害の有無が最優先です。データのありかを深堀りしましょう。

アプリよりはAWSといったインフラのほうが手を打ちやすいです。どうしようもないアプリに対してすぐできることは各種バージョンアップとWAFぐらい。余裕があればアプリケーションへのランタイムセキュリティ、コードベースへのセキュアコーディング支援ツール、SecurityHub含めたCSPMツールといった形で手間をかけずに自動化したいところです。

表明保証の期間中にはせめてアセスメントは終わらせたいです。

開発改善はきっぱり諦める

開発はそのままにしておきます。開発プロセスや体制改善について、セキュリティ関係以外は後回しにせざるを得ません。プロダクトセキュリティに関連するので開発周りのアセスメントだけは早めに行うのが望ましいです。

最後に

CEO / CFOの方は最悪DDにはセキュリティとテクノロジーDDも必要だということだけを覚えて帰ってください。

CTOの方は経営戦略上M&Aは最重要項目の一つであり、それゆえ他人事ではなくCTOが積極的に関わる必要があることを抑えておきましょう。

無意味無計画な買収が減り、誰もよろこばないPMIが少しでも減ることを願ってやみません。

短期海外旅行で便利なもの2023

ask_yoshi_taka — Sat, 16 Dec 2023 12:01:00 GMT

eSIM

以前はモバイルルーターを使っていた人も、eSIMがおすすめです。

短期でその国の通信会社と契約するイメージ。しかもWebだけで完結し、何も持ち運ばなくてよいです。そして安い。国が違ってもほぼいつものスマホと同じ体験に。よほど古いスマートフォン以外では使えます。

出発の数営業日前に買っておくのが無難。やろうと思えば現地に着いた後でも日本のAmazonなりで購入して対応可能です。(電子データのやり取りが主で、送付物はQRコードが印刷された紙だけです)

設定方法は割愛しますが簡単です。設定自体にネット接続が必要なので空港のWifiを使いましょう。

クレジットカードのコンタクトレス決済 + Apple Pay / Google Pay

現金はなるべく減らしたいものの、クレジットカードを見せるのは心配。そんなときはApple Pay等で完結させるのが楽です。

支払いをクレジットカードでお願いする -> お店の決済端末にスマホをかざす

で終了です。新しめのお店だったら確実でしょう。日本と全く同じように使えます。

ちなみに持っている物理カードがタッチ対応していなくても、Apple Pay等に登録するとスマートフォンでは使えることがあります。電子的なやりとりだからでしょう。

![お店にこういうマークがあれば確実](../../assets/short-overseas-trip-useful-items-2023-0864013c4d95-01.jpg)

お店にこういうマークがあれば確実

クレジットカードの海外キャッシング

現地の現金を準備したいときはクレジットカードの海外キャッシングが便利かつレートが良い傾向にあります。現地で銀行っぽいところのATMにクレカを入れて引き出しましょう。

帰国時税関 Visit Japan Web

帰国時の税関処理がWebで完結します。

名前と裏腹に日本在住者も使えます。使い勝手は微妙…ですが紙よりは良いでしょう。旅行前におおよそ仕上げることもできます

オンラインチェックイン

意外と多くの方がオンラインチェックインを使っていないように見受けられます。航空会社のチェックインをWebで行えば紙チケットの代わりにQRコードがもらえ、スマホだけで搭乗まで完結できます。 (紙も持っていたほうがリスク分散にはなるという考えもありといえばあり)

Webのほうが早く席を指定できるので有利です。ツアーでも問題なくオンラインチェックイン可能です。

各国の入国電子申請

Web申請が必須の国もあれば、紙でOKの国もあります。とはいえWeb申請が楽なので事前に調べて済ませておきましょう。

前述のように、入国帰国手続きはペーパーレスでスマホだけで済ませることが可能です。現金を使わないならスマホ一つ(とパスポート)だけで旅行できるかもしれません。

カメラで翻訳系のアプリ

Googleなどのアプリ。街中で気になったものがあれば内容を確認できます

おまけ

洗濯

コインランドリーを使えば荷物が圧縮できます。ホテルや周辺にあるか確認しましょう。洗剤の有無も忘れずに。もちろん国内旅行でもできます。

ホテル荷物預け入れ

ホテルではチェックイン前、チェックアウト後でも荷物を預かってもらえます。立地が良いところだと便利。もちろん国内旅行でもできます。

ホテルで朝食付きにするか

数日同じだと飽きるので長く泊まるときは素泊まりがおすすめです。多くのホテルの朝食は個別で頼むことも可能です。もちろん国内旅行でもできます。

Uber Eats

日本のアカウントでそのまま注文できます。ホテルならロビーかホテル入り口付近で受け取ればよいでしょう。

ログイン時のSMS認証周りは説明が難しいので割愛。検索してください

ホテルと航空券は直接予約

直接予約のほうが安いです。

OTA(Online Travel Agent)は結局マージンを取るので今の時代あまりメリットがありません。キャンペーンで大幅割引のときだけは検討

特に海外OTAのほとんどは日本の旅行業登録をしておらず、なにかあったときの補償も期待できません。

上記はすべて国内旅行でも同様です

Table-Driven Programming: An Underrated Superpower

ask_yoshi_taka — Sun, 06 Jul 2025 15:21:02 GMT

When you’re cranking out business logic, nothing beats a good lookup table. It’s simple, legible, and keeps the “ifs” from exploding all over your codebase.

From Spaghetti to Spreadsheet

def get_unit_price(seats):
    if seats >= 100:
        return 12.0
    elif seats >= 50:
        return 14.0
    elif seats >= 25:
        return 16.0
    elif seats >= 10:
        return 18.0
    else:
        return 20.0

Swap in a table and watch the clutter disappear:

pricing_table = [
    {"min":    0, "rate": 20.0},   # 0-9 seats -> $20/seat
    {"min":   10, "rate": 18.0},   # 10-24 seats
    {"min":   25, "rate": 16.0},   # 25-49 seats
    {"min":   50, "rate": 14.0},   # 50-99 seats
    {"min":  100, "rate": 12.0},   # 100+ seats
]

def get_unit_price(seats):
    for rule in reversed(pricing_table):
        if seats >= rule["min"]:
            return rule["rate"]

Works in any language. No fancy pattern-matching required — just a loop.

Why Bother?

Readable: Every rule looks the same, so you’re skimming, not spelunking.
Flexible: Need a new tier? Tweak the table — no code surgery.
Test-Friendly: Your test cases are the data. Validate the rows, not a forest of conditionals.
Brain-Friendly: Most messy branches are just an implicit table anyway. Make it explicit and move on.

Hot take: Nine times out of ten, “business logic” is just a spreadsheet waiting to happen.

Multi-Dimensional? No Problem.

Category     | Origin Group | Band  | Tariff Rate (%)
-------------|--------------|-------|-----------------
Electronics  | FTA          | low   | 2.0
Electronics  | FTA          | mid   | 1.5
Electronics  | FTA          | high  | 0.5
Electronics  | non-FTA      | low   | 5.0
Electronics  | non-FTA      | mid   | 4.0
Electronics  | non-FTA      | high  | 3.0
Apparel      | FTA          | low   | 8.0
Apparel      | FTA          | mid   | 6.0
Apparel      | FTA          | high  | 3.0
Apparel      | non-FTA      | low   | 12.0
Apparel      | non-FTA      | mid   | 10.0
Apparel      | non-FTA      | high  | 8.0

tariff_dict = {
    ("electronics", "FTA", "low"): 2.0,
    ("electronics", "FTA", "mid"): 1.5,
    ("electronics", "FTA", "high"): 0.5,
    ("electronics", "non-FTA", "low"): 5.0,
    ("electronics", "non-FTA", "mid"): 4.0,
    ("electronics", "non-FTA", "high"): 3.0,
    ("apparel", "FTA", "low"): 8.0,
    ("apparel", "FTA", "mid"): 6.0,
    ("apparel", "FTA", "high"): 3.0,
    ("apparel", "non-FTA", "low"): 12.0,
    ("apparel", "non-FTA", "mid"): 10.0,
    ("apparel", "non-FTA", "high"): 8.0,
}

# Band classification based on quantity
def resolve_band(quantity):
    if quantity < 100:
        return "low"
    elif quantity < 1000:
        return "mid"
    else:
        return "high"

# Main lookup function
def find_tariff_rate(category, origin_group, quantity):
    band = resolve_band(quantity)
    key = (category, origin_group, band)
    return tariff_dict.get(key, None)  # None if no match found

This mindset alone can improve code clarity — even if you don’t fully implement it.

Externalize Your Logic

With first-class functions in most modern languages, you can also store behaviors — not just constants — in tables and apply them dynamically.

Because rules are just data, you can:

Store them in JSON, a DB table, or even a Google Sheet.
Let non-devs edit promo rates or tax rules without a code push.
Skip deploys for every tiny tweak. Change data, hit save, done.

Business Impact

From Code to Data

The real power? You’re transforming business logic from hardcoded control flow into externalized data. This enables:

Non-engineers to own rule updates
Logic changes without redeploys
Lower risk and faster iteration

Bonus point: AI won’t rewrite your logic in a table-driven style unless you ask it to. But if you do, it can refactor it instantly.

That means table-driven design isn’t just human-friendly. It’s AI-friendly too.

Fewer Tests, Fewer Bugs

If your logic is just data, there’s no need to write unit tests checking whether your code correctly re-implements those rules. You just verify the data.

Faster Release Cycles

Releasing application code is often slow, risky, and tightly coupled to engineering cycles. Logic-as-data enables sub-minute updates with near-zero rollback cost.

Roll forward via code: 0.5 day

Rollback via infra: 10 min

Rollback via config/data: 1 min

Empower Business Users

Provide an admin UI. Let domain experts own their logic. Engineering effort drops to zero.

⚠️ Caveats to Keep in Mind

Always include a sensible default or fallback.
If you change the table’s shape, the surrounding code must change too — plan ahead.
Data isn’t type-checked at compile time. Add validation or linting for safety.
Rules-as-data doesn’t protect you from bad rules. Only paranoia survives.
Memory access is expensive. If you’re squeezing every last nanosecond out of the hot path, pause and benchmark before trading branches for a lookup table.

You (Probably) Shouldn (specbranch.com) - I have been working on another post recently, also related to division, but I wanted to address a comment I got from…

Final Thought

As Code Complete reminds us (ch. 18, “Table-Driven Methods”), turning sprawling branch logic into a data table doesn’t just shrink the code you have to reason about. It also slashes the bug surface area and puts the knobs straight into the hands of the people who actually own the rules.

台北b-monsterメモ

ask_yoshi_taka — Wed, 13 Dec 2023 14:08:56 GMT

現在台北スタジオはなくなりました。以下過去の参考です

先人の記事はいくつかあります。参考にしつつ補足です

新光三越の入館方法

通常の時間帯なら三越に普通に入るだけです。

朝方や夜間といった、三越の営業時間外でも入館可能です。入り口は1階にあります。正面入り口は閉ざされているため、新光三越A9の建物をぐるっと回って開いてそうな扉を探しましょう。エレベータホール前に警備員の方がいました。そこからエレベータで5階まで上がります。

持ち物

手ぶらでOK。日本同様に全部レンタルできます。受付の方にレンタルしたい旨を伝え、現金で支払いましょう。

2023年現在、台北スタジオではタオルは無料のままです。

台北スタジオでもプロテイン飲料が買えるようです。台湾のドラッグストアやコンビニでは入手しづらく、必要な方は買ってみましょう。

サンドバッグ番号

不明なら受付の方に聞く

Wigmore Hallから眺める敬称一覧と歴史

ask_yoshi_taka — Sat, 07 Mar 2026 02:36:42 GMT

ロンドンのWigmore Hallで演奏を聴こうと思い立ち、オンラインで申し込みをしてみました。すると最初に驚くのが敬称（title）の多さです。

![titleのスクロール量](../../assets/wigmore_title.png)

titleのスクロール量

フォームのプルダウンをスクロールすると、軍人・聖職者・貴族・政治家など、実に多様な敬称が並びます。

title	意味
Mx.	性別を特定しない敬称
1st Lt	First Lieutenant（陸軍などの中尉）
2nd Lt	Second Lieutenant（少尉）
Air Chief Marshal	英空軍最高階級の一つ（大将級）
Air Commodore	英空軍准将
Air Marshal	英空軍中将
Air Vice-Marshal	英空軍少将
Alderman	市議会の長老議員（歴史的役職）
Ambassador	大使
Baroness	女男爵
Bishop	司教
Brig. Gen.	Brigadier General（准将）
Brother	修道士の敬称
Canon	カノン（大聖堂参事）
Cantor	宗教儀式の詠唱者（ユダヤ教など）
Capt.	Captain（大尉／艦長など）
Cardinal	枢機卿
Cmdr.	Commander（海軍中佐級）
Colonel	大佐
Comte	伯爵（フランス語）
Councellor	評議員／参事官
Count	伯爵
Countess	伯爵夫人
Dame	女性ナイト爵位
Dean	学部長／大聖堂長
Dowager Viscountess	先代子爵夫人
Dr.	博士号保持者
Earl	伯爵（英国貴族）
Estate of	故人の遺産・財産を表す法的表現
Father	神父
Flight Lieutenant	英空軍大尉
Flying Officer	英空軍中尉
Fr.	Father（神父の略）
Gen.	General（将軍）
Group Captain	英空軍大佐
H.R.H.	His/Her Royal Highness（殿下）
Herr	ドイツ語の「Mr.」
Hon.	The Honourable（名誉称号）
Ing.	Engineer（主に欧州の工学称号）
Judge	裁判官
Justice	上級裁判官
Lady	貴族女性敬称
Lord	貴族男性敬称
Lt.	Lieutenant（中尉）
Lt. Cmdr.	Lieutenant Commander（海軍少佐級）
Lt. Col.	Lieutenant Colonel（中佐）
Maestro	音楽家・指揮者の敬称
Maj. Gen.	Major General（少将）
Major	少佐
Marshal of the Royal Air Force	英空軍最高階級
Mme.	Madame（仏語の既婚女性敬称）
Mms.	複数女性の敬称
Monsignor	カトリック高位聖職者
Pilot Officer	英空軍少尉
Professor	教授
Rabbi	ラビ（ユダヤ教指導者）
Rear Adm.	Rear Admiral（少将・海軍）
Representative	下院議員
Revd Canon	聖職者＋大聖堂参事
Reverend	牧師
Sen.	上院議員
Senator	上院議員
Sgt.	Sergeant（軍曹）
Signor	イタリア語のMr.
Signora	イタリア語のMrs.
Sir	ナイト爵位
Sister	修道女
Squadron Leader	英空軍少佐
Sr.	Senior
The Right Hon.	枢密院メンバー等の敬称
The Rt. Rev.	Right Reverend（高位司教）
Very Reverend	上級聖職者
Vice Adm.	Vice Admiral（海軍中将）
Viscount	子爵
Warrant Officer	准士官
Wing Commander	英空軍中佐

この一覧を眺めていると、イギリス社会の歴史的階層がそのままプルダウンメニューに圧縮されているようにも見えます。

suffix（Jr. や III など）も入力できるのですが、こちらのリストは省略します。

![suffixのスクロール量](../../assets/wigmore_suffix.png)

さらに住所入力の country（地域）も興味深く、島嶼地域が独立した項目として分かれていたり、「Okinawa」と「Ryukyu Islands」が別項目として存在していました。

こうしたデータを見ると、単一の最新マスタではなく、

20世紀初頭の国名リスト
英国系組織の住所台帳
旅行業界などの国コードといった複数のデータベースを統合した痕跡があるように感じられます。

オンラインフォームという何気ないインターフェースですが、そこには英国社会の制度史と、情報システムの継ぎ足しの歴史が同時に埋め込まれているようです。

海外旅行保険の選び方: 何を優先して補償を決めるか

ask_yoshi_taka — Sun, 15 Feb 2026 03:00:00 GMT

海外旅行保険は、補償項目が多く、一見すると「全部つけたほうが安全」に見えます。しかし実際には、保険料に強く影響する項目と、そうでない項目がはっきり分かれています。この記事では、海外旅行保険を選ぶときに迷いやすいポイントを、実務的な優先順位で整理します。

簡単な用語整理

意外と混乱しやすいので、最初に用語を押さえておきます。「誰が、誰に、何を払うのか」を意識すると整理しやすくなります。

保険料：保険契約のために支払うお金
保険金：事故や病気など、保険事故が起きたときに受け取るお金

保険料が大きく変わる項目を把握する

特に次の項目は、設定すると保険料が大きく跳ね上がりやすい傾向があります。

携行品損害
旅行キャンセル費用

これらは、保険金額を少し上げるだけでも保険料が急増します。発生頻度が高く、かつ請求が比較的起こりやすいリスクであるため、保険会社側も慎重な料率設定をせざるを得ないのでしょう。

一方で、治療・救援費用や個人賠償責任は保険金額を大きく増やしても保険料の増加はわずかです。最悪のケースに対処できる、まさに「保険」の本領発揮です。

クレジットカード付帯保険を前提に考える

クレジットカード付帯保険と内容が重複している部分を削ることで、保険料は大きく下げられます。携行品損害は重複しやすい項目です。

一方、クレカ付帯では治療・救援費用が不足気味なことが多い。前述の通り、ここは保険金額を増やしても保険料はあまり増えません。追加契約するなら、むしろここを厚くするのが合理的です。

実務上よくある構成は、

携行品損害：クレカ付帯でカバー
治療・救援費用、賠償責任：海外旅行保険で上乗せ

という分担です。複数枚カードを持っている場合は、最も条件の良いものを一枚選ぶだけで十分でしょう。

付帯条件を確認する

「カード名＋付帯保険」で保険の案内資料を検索し、資料をAIに整理させるとよいでしょう。カードを複数枚保持しているときは全部確認して一番良い条件のものを探しましょう。

クレカでの自動付帯/利用付帯

利用付帯は「カードを使った場合のみ有効」です。対象となる支払いは航空券に限らず、空港までの公共交通機関が含まれるケースも多い。

タッチ決済で電車やバスに乗り、そこで利用付帯条件を満たす、という運用も可能です。複数カードを持っている場合、それぞれで利用付帯条件を成立させることもできます。

重複補償をさらに削る

損害保険は原則として実損てん補です。同じ内容に複数加入しても、損した金額以上は受け取れません。

死亡保障や傷害後遺障害は、生命保険と重複していることが多い項目で、生命保険の保険金は損害保険と異なり重複して受け取ることが可能です。ただ、海外で亡くなった場合と、日本国内で亡くなった場合とで、冷静に考えると、残された人の生活に関しては経済的になにかが変わるわけではありません。その意味で、海外旅行保険でさらに死亡保障を増やす意義は限定的でしょう。もし不安があるなら生命保険のほうの保障を変更すべきです。

※ただし、周知の通り治療費については国によって桁が変わるため、治療費に対する保険金はこの限りではありません。

ツアー契約時はあえて分割払いを狙う

脱線しますが、旅行代理店の破産が時折発生しています。クレジットカードで分割払いにすると、未引き落とし分の引き落としが停止できます(支払停止の抗弁)。金利は増えますが保険料だと考えると検討の余地ありです。

さいごに

韓国、台湾に数日程度ならクレカの付帯保険で十分という考えもできますが、遠い場所に長くいるなら海外旅行保険は必須でしょう。お得に安心を買いたいところです

イギリスのホテル部屋の特徴

ask_yoshi_taka — Thu, 05 Mar 2026 14:15:44 GMT

電源はプラグのほか、USB type Aが使えることが多い。時折type Cも利用可能。Type Aは空港など様々な場所で使えて便利。

シャワーとドライヤー

天井式のシャワーがよくある。配管の都合で最初は水が出るので距離を取らないと冷たい思いをする。ドライヤーは部屋に付属していないか、あったとしてもクローゼットや引き出しなど浴室以外にある。

イギリスの電気規格（BS 7671）では浴室内の電源設置が厳しく制限されているため。

都市ホテルではシャワーのみの部屋も多く、バスタブ付きの部屋は上位カテゴリに設定されていることがある。

冷暖房

ラジエータ式のセントラルヒーティングが主流なのはヨーロッパ共通。イギリスのホテルでは浴室にあり、タオルウォーマーを兼ねてパイプにタオルが掛けられていることが多い。触ると熱いので気をつけること。その分ヒートショックは少なさそう。

温度を調整したいなら部屋のどこかにあるダイヤルを探すこと

冷房はないことが多い。温暖化で今後エアコン付きの部屋が増える可能性も。

ベッド・寝具

イギリスのベッドの特徴は、高さがあることと、縦幅が小さく感じること。縦幅が通常190cmと世界でも短いほうでありながら、枕が多数置いてある状態でベッドメイクされているので頭の位置が押し出される。枕はサイズや硬さが異なるものが並んでいることが多いので、好みに合わせて使うとよい。ベッドランナーは見かけない。

その他

トイレに緊急時用のボタンがある。ボタンではなく紐式のこともある。

イギリス旅行におけるコインランドリーの使い方

ask_yoshi_taka — Wed, 11 Feb 2026 20:20:11 GMT

旅行で洗濯を前提にすると持ち物が一気に減って便利です。一つのやり方が現地のコインランドリー活用でしょう。

イギリスではクリーニング店laundretteがコインランドリーを併設しているイメージです。なんなら同じ場所同じ機械で店員が洗い物をしていることがあります。特にロンドンで泊まるようなエリアなら近場で探すことも簡単です。

コインランドリーの使い方

£のコインを準備する
店や機械の注意書きをよく読む。AIを駆使して注意書きの理由も調べると良い
洗剤がなければその場で洗剤を買う
洗い物と洗剤を入れ、コインを投入して洗濯
乾燥機にもコインを投入して乾燥

洗濯水温や乾燥機の温度、乾燥時間は洗い物に合わせて適宜調整してください

![コインランドリーの洗剤販売機](../../assets/uk-laundrette.jpg)

洗剤販売機。仕組みが気になる。

必要なもの

最低限現金 (1ポンドコイン)が必須です。さらに洗剤をその場で買うなら端数が必要になることがあるので確認しておきましょう。洗剤はスーパーでまとめて買っておいたほうが楽でお得な面も

両替については、店員がいれば対応してくれることがあります。ただし人がいないうえ両替機もないコインランドリー型もありえます。お札しか持ってないようならそのへんの店で何かを購入しましょう。

クリーニングは小規模業者が多く、機械の更新やキャッシュレス決済導入、決済手数料に耐えられないのかと想像します。

Laundrette / Launderetteは本当にコインランドリーか？

Laundrette / Launderette は、日本語で言う「コインランドリー」とは必ずしも一致しません。あくまで小規模なクリーニング関連サービスの総称で、業態には幅があります。実際には、以下の3パターンがありえます。

1. クリーニング＋コインランドリー（最も一般的）

店員常駐
セルフ用の洗濯機・乾燥機あり
同じ店内・同じ機械で、店員が業務での洗濯をしていることもある

ロンドンなど都市部で最もよく見かける形です。旅行者が「イギリスのコインランドリー」と呼んでいるものは、ほぼこれ。

2. クリーニングのみ

セルフ洗濯不可
Service wash（まとめ洗い）や dry cleaning のみ提供
外観は laundrette だが、コイン投入口が存在しない

住宅地寄りのエリアや、小規模店舗で見られます。看板だけで判断すると誤解しやすいタイプ。

3. コインランドリーのみ（少数派）

無人、または営業時間限定で店員がいることもある
完全セルフサービス
両替機がないケースもありうる

日本の感覚に一番近いですが、英国では相対的に少なめです。

検索・見分け方のコツ

Google Maps の表記
- launderette → 上記いずれも含みうる
- self-service laundry → パターン1または3の可能性が高い
写真から
- カウンター＋作業台 → クリーニング併設
- 大型洗濯機がずらり → セルフ比重高め
レビューで
- たとえばservice wash / staff did my laundry という記述があるか

注意事項

上記の通り、地域によってはlaundretteが必ずしもセルフサービスを提供しているとは限りません。近くにセルフ式がなければ、service wash（まとめ洗い）としてクリーニングに任せるのも一案です。配達に対応していることもあります。クリーニング料金はコインランドリー型と比べてもそこまで高くない印象です。なお、これも現金のみの可能性があります。

機械が古い場合、扉が閉まりにくいことがあります。遠慮せず、しっかり押し込みましょう。

Why Dependency Reduction Is Still Hard

ask_yoshi_taka — Tue, 24 Mar 2026 15:00:00 GMT

Including initiatives like e18e, reducing dependencies is a highly valuable practice. I’m a big fan of e18e.

If you remove dependencies, Renovate / Dependabot PRs will decrease.
This reduces the security blast radius and also lowers the burden of investigation and ongoing maintenance. In addition to improving developer experience, it can also improve production performance.

That said, the path is not easy. The fact that many repositories still rely on jest makes this quite clear.
These challenges are also largely common across other languages.

Common Challenges

Social (Sociotechnical)

We meet again.

As Gerald Weinberg put it, “no matter how it looks at first, it’s always a people problem.”
Dependency reduction is no exception.

Low Interest in Non-Functional Concerns

Most maintainers and code owners are not deeply interested in dependencies or non-functional requirements themselves.
Given limited time, attention naturally gravitates toward feature development.

Lack of Trust in PR Authors

PRs from unfamiliar contributors are often ignored or left unreviewed.
This is even more true in the age of AI. Building trust comes first.

Different Processes Across Repositories

Some repositories accept direct PRs, while others require opening an issue first.
Understanding each repository’s workflow can be burdensome. Even when documented, effective contributions often require reading the “room.”

You Still Need to Release

Especially for poorly maintained repositories, releasing can be more burdensome than making the change itself.
As long as the project is still in use, you cannot simply merge and walk away.

No Real Interest in the Repository Itself

If the last update was years ago, or there are no incentives within an organization, improvements are unlikely to move forward.

Even with AI, Review Is Still Required

If only part of a library is used, it’s possible to rewrite it inline with AI.
This is particularly effective for removing legacy dependencies. However, the review burden still remains significant.

Ambiguous Ownership

In repositories with multiple maintainers, it is often unclear who is responsible for reviewing dependency-related changes, leading to stagnation.

Still Not a Common Practice

Dependency reduction is not yet standard practice.
Its value often needs to be explained each time, which adds cognitive overhead.

Technical

If this were purely a technical problem, it would feel much easier.

Ensuring Compatibility Is Hard

Even when replacing parts of lodash or moving to native APIs, subtle behavioral differences can occur.
If compatibility is not 100%, uncertainty remains, increasing validation costs or causing PRs to be rejected.

Even Minor Upgrades Can Break Things

e18e efforts can significantly reduce dependencies, sometimes just through upgrades.
However, even minor version updates can introduce issues, not only within the library itself but also through interactions.

Insufficient Test Coverage

Tests are often deprioritized.
Without sufficient regression tests, it’s hard to be confident that everything still works.

Benefits Are Hard to Measure

Removing a single dependency may have only a small performance impact.
Moreover, due to transitive dependencies, removing one explicit dependency may not change the final dependency graph.

This is common in performance work: meaningful gains often come only after many small improvements are accumulated. However, improving the entire ecosystem to achieve that is time-consuming.

After the Easy Wins, Only Hard Dependencies Remain

After easy fixes, what remains are complex dependencies.
Fixing A may require changes to B, which in turn affects C and D.

Hard to Understand Impact Scope

Especially in monorepos, it takes time to determine how far the impact of a dependency removal extends.
Even seemingly unrelated scripts can be affected.

Dependencies Come Back

Even after significant effort to reduce them, dependencies can quickly accumulate again.

Recommended Approaches

Remove Completely

If a tool like knip confirms that a dependency can be removed without impact, this is the simplest approach.
It is effectively risk-free.

Make Small, Incremental Changes

Smaller PRs are easier to review and help build trust.
However, this increases the number of reviews and releases required.

Replace with AI-Generated Implementations

A more aggressive approach, but it can often be effective. Breaking away from legacy constraints and rebuilding from scratch can sometimes be faster.
That said, adoption and community considerations require care.

Prevent Reintroduction

Reducing dependencies is not enough. You also need to prevent them from creeping back in.
Tools like the following can help establish guardrails:

GitHub - e18e/action-dependency-diff (github.com) - GitHub Action to show dependency diff in pull requests and help catch dependency creep.

Conclusion

Even when the goal is simply to remove dependencies, the same kinds of challenges found in broader software development inevitably emerge.

A future where AI solves all of this doesn’t seem particularly realistic. And even if it did, whether our electricity bills go down or up is a different question.

P.S. I also built a small tool in this area:

Package Replacement (package-replacement.veritycost.com) - Copy-first registry for vendoring small package behavior into your repo.

なぜ依存関係の削減は難しいのか

ask_yoshi_taka — Tue, 24 Mar 2026 15:00:00 GMT

e18eも含め、依存関係の削減は素晴らしい取り組みです。

依存関係を削除すれば、Renovate / Dependabot のPRは減ります。セキュリティ上の影響範囲が小さくなるのはもちろん、調査や追従の負担も減ります。開発体験の改善に加え、本番パフォーマンスが向上することもあります。

とはいえ、道のりは平坦ではありません。いまだに多くのリポジトリがjestのままであることからも、それはよく分かります。なお、こうした課題は他の言語でもかなり共通しています

よくある課題

社会的なもの

まずはこれ。というかこれがすべて。

機能以外に関心が向きにくい

ほとんどのメンテナやコードオーナーは、依存関係や非機能要件そのものには強い関心を持っていません。忙しさもあり、関心はどうしても機能追加に集中しがちです。

PR作成者への信頼がない

よく知らない人からのPRは、レビューされずに流れてしまうことも少なくありません。 AIの時代はなおさらです。まずは信頼を得る必要があります。

リポジトリごとに進め方が違う

そのままPRを送ってよいリポジトリもあれば、先にissueを立てる必要があるものもあります。やり方を読み解くだけでも負担です。書いてあるだけまだ親切で、実際には空気を読む必要があることも多いでしょう。

結局リリースしないといけない

とくにほぼ保守されていないリポジトリでは、変更そのものよりもリリースが負担になります。使われている限り、改善して終わりにはできません。

そもそも該当リポジトリに関心がない

最終更新が何年も前だったり、組織内でインセンティブがなかったりすると、改善は進みません。

AIを使っても結局レビューは必要

外部ライブラリの一部だけを使っている場合、AIでinline実装を書き下ろすことも可能です。とくにレガシー依存の削除には有効です。ただし、最終的なレビューの負担は依然として重く残ります。

オーナーシップが曖昧

複数メンテナのリポジトリでは、依存関係の変更を誰がレビューするのか定まっていないことが多く、結果として放置されがちです。

やっている人がまだ少ない

依存関係削減はまだ開発の常識とまでは言えず、毎回その意義を説明する必要があります。理解コストが高いのも課題です。

技術的なもの

AIになんとかしてほしいもの。

現実的に互換性の担保が難しい

lodashの部分置き換えやネイティブAPIへの移行でも、微妙に仕様がずれることがあります。 100%互換でないと不安が残り、検証コストが増えたり、PRが見送られたりします。

バージョンアップでも不具合は起こりうる

e18e対応により依存関係が一気に減ることがありますが、マイナーバージョンアップであっても不具合が出る可能性は否定できません。ライブラリ単体だけでなく、相互作用が原因になることも多いです。

テストが薄く、自信を持ちにくい

テストは後回しになりがちです。リグレッションテストが不足していると、「本当に大丈夫か」を確信できません。

効果が分かりづらい

単一ライブラリの削減では、パフォーマンス改善のインパクトが小さいことがあります。また、transitive dependencyの影響で、明示的な依存を削っても最終的な構造が変わらない場合もあります。

パフォーマンス改善ではよくあることですが、小さな改善を積み重ねて初めて大きな効果が現れることがあります。しかし、そのためにエコシステム全体を改善していくのは手間がかかります。

複雑なものしか残っていない

単純な修正の後に残るのは複雑な依存です。 Aを直すためにB、そのためにCとDを…というドミノ的な修正が発生します。

影響範囲に自信を持ちづらい

とくにモノリポでは、依存削除の影響がどこまで及ぶかの把握に時間がかかります。無関係に見えるscript類もやっかいです

削減しても再び増える

大きな労力をかけて削減しても、依存関係は簡単に再び増えていきます。

やり方おすすめ

完全に削除する

knipなどで影響範囲なく削除できる場合は最も簡単です。文字通りノーリスクです。

小さく分けて送る

レビューしやすく、信頼も得やすくなります。ただしレビューとリリース回数は増えます。

AIで代替実装を作る

大技ですが有効です。古いしがらみを断ち、新しく作り直したほうが進むこともあります。ただし採用やコミュニティとの関係には注意が必要です。

予防する

依存関係は削るだけでなく、増やさない仕組みも重要です。以下のようなツールでガードレールを設けるとよいでしょう。

GitHub - e18e/action-dependency-diff (github.com) - PR上で依存差分を可視化し、依存の増加を検知しやすくするGitHub Action。

最後に

依存関係の削除であっても結局他の開発と同じような課題が浮かび上がります。AIが全部やってほしいですね

P.S. このあたりに関連して、こんなツールも作りました。

Package Replacement (package-replacement.veritycost.com) - Copy-first registry for vendoring small package behavior into your repo.

The Titles in Wigmore Hall's Booking Form

ask_yoshi_taka — Tue, 18 Aug 2026 10:18:03 GMT

I was booking a concert at Wigmore Hall in London when I noticed something unusual in the booking form: the title dropdown was extremely long.

It didn’t stop at Mr, Ms, and Dr. It included military ranks, aristocratic titles, religious titles, diplomatic titles, and several titles I had never seen before.

![A long list of titles in the Wigmore Hall booking form](../../assets/wigmore_title.png)

The title dropdown in Wigmore Hall's booking form

Some examples:

Air Chief Marshal
Dowager Viscountess
Monsignor
The Right Hon.
Wing Commander
H.R.H.
Estate of

The suffix field is similarly extensive, combining academic degrees, honours, and post-nominal letters.

![A long list of suffixes in the Wigmore Hall booking form](../../assets/wigmore_suffix.png)

The booking form also contains an extensive suffix list

Why so many titles?

Wigmore Hall has been around since 1901. Over that time, it has dealt with performers, patrons, donors, diplomats, clergy, military officers, and members of the aristocracy.

Many of the entries are forms of address that are still used in Britain.

“Wing Commander,” for example, is an RAF rank. “The Right Hon.” is a style used by certain senior politicians and members of the peerage. “Monsignor” is an honorific used for some Catholic clergy. “Dowager Viscountess” refers to the widow of a viscount who retains the title after it passes to a successor.

Some entries are harder to classify. “Estate of,” for example, isn’t a title at all. This suggests that the field is used for more than choosing how to address a person.

The list may simply reflect the types of records the booking system has needed to handle over time.

The country list is odd too

The address form contains another unusual list. Both “Okinawa” and “Ryukyu Islands” appear as separate entries in the country or region field.

I don’t know the source of this data, so I can’t say why both entries exist. The list could come from an old address database, or it could combine data from several sources.

Either way, “Ryukyu Islands” is an unusual entry in a current address form.

We usually associate legacy software with old code or infrastructure. But lists of titles, countries, regions, and other categories can also remain in a system for years.

Removing an entry can be difficult. Existing customer records may use it. Another system may expect it. In some cases, nobody may know why the entry was added in the first place.

As a result, a dropdown can contain information from several generations of a system.

This is the English version of the original Japanese article.

ask yoshi taka Blog

生成AIがコードを読む時代、私たちはどうコードを理解すべきか？：生きているアプリケーションと死んでいるソースコード

ソースコードを使うメリット

すべてが記載されている

解析手順が豊富

生成AIが活用しやすい

ソースコード(だけ)を使うデメリット

量が多すぎて当たりをつけづらい

挙動が読みづらい

何をしたいのかが不明瞭

優先順位がつけづらい

作成したコード外の動きは教えてくれない

コードが使われているとは限らない

見るべきは動いているアプリケーション

動的な解析と侵襲度

ソースコードと動的な解析、どちらが先か

とりあえずやってみる：メンタルモデルの組み立て

理解を進めるうえでの改善

最後に

関連記事

2025年現在、AI開発支援が組織に与える現実的なインパクト

開発人材・外注ニーズの変化と凋落

社内ミニツールによる効率化

リリースがすべて: より速く、より小さくのために投資できるか

開発面

QA面

開発関係以外の側面

準開発者への支援

最後に

関連記事

言語モデル/AIによるITエンジニアリング論点

短期目線

採用：単純なコーディング、技術試験は不要に

乗り換えられるようにする

中期目線

可読性のあるコードは不要になるのでは

保守性、再利用性も不要になるのでは

コードのリファクタリングもいらない

プログラミング言語選択の基準が変わる

新しいプログラミング言語は不要になるか

(Web)フレームワークは不要になるか

最新の構文、書き方、イディオムに追随できるか

パフォーマンスのオートチューニングが可能に

形式手法による一部機能のバグゼロ達成

品質の向上(事前欠陥検出)

オートチューニングのための実験できる環境が必要

ローカル開発環境は必要か

いわゆる開発のしやすさはいらなくなるか

IaC(Infrastructure as Code)は必要なのか

CI/CDはさらに重要になりそう

(データ分析での)SQLの重要性が減る

より少人数の開発に。フルスタック化が進む

EM(Engineering Manager)のポジションが減る

組織内での分散化が進む

社内プラットフォームの価値が低下するか？

日本のレガシーIT企業が壊滅する

長期目線

むしろソースコードは不要で機械語でよいのでは？

タイピング力は必要か

ITエンジニアとAI、どちらが勝つか

さいごに

AIがサクサク動くコードベースにしよう

コードは短く

ファイルを責務ごとに分割し、凝集度を高くする

不要な設定やメッセージ用テキストは別ファイルに分離する

コメントは無駄なく丁寧に

変数名は丁寧に

ディレクトリ構造に秩序を

主流のライブラリ/ツール等を使う

ドキュメントがしっかりしたライブラリ/ツールを使う

テストを厚めに書く

開発ドキュメントを書く

ビルドやテスト時間は短く

診断/デバッグ方法を準備しておく

さいごに

CTOに役立つ！AWS請求からアーキテクチャを読み、コストを削減する技術。PDF編

請求書PDFが読めるようになるメリット

ある程度アーテクチャがわかる

同じ条件で比較して、コスト削減の余地がつかめる

DDやPMIにも効果的