この記事の途中に、以下の記事の引用を含んでいます。
When programs assume the system will never change, episode 4: Stealing strings
シンプルな自動化の罠――「Yes/No」の自動応答で起きた実話
企業で使う業務自動化プログラム。
その一工程で、Windows標準のコンソールアプリを呼び出し「Are you sure (Y/N)?」と確認される処理があります。
自動化のため、プログラムで「Yes」を答えたい――そう考えたとき、問題は多言語対応でした。
欧米だけでなく、世界中の人に使われるアプリでは、「Y/N」だけでなくドイツ語なら「J/N」など、肯定・否定の文字が異なるため、単純に「Y」をハードコーディングできません。
ここで顧客は、実行ファイル内部の「Yes」「No」リソース文字列を引っ張ってくれば多言語にスマート対応できるのでは、と考えました。
いちいち各国ごとの「肯定/否定表リスト」を作るより効率がよいからです。
しかし…この選択には、思わぬ落とし穴が待っていました。
「リソース文字列を流用するのはダメ」――記事の明確な主張
この記事では、
“No, it’s neither supported nor acceptable.
Unless documented otherwise, resource strings are considered implementation details of the program. Absent any promises to the contrary, Windows reserves the right to change any resource string, or to move them to another location.”
（引用：When programs assume the system will never change, episode 4: Stealing strings）
と明快に断じています。
要するに「リソース文字列は、アプリ実装の都合でいつでも変えられる部分であり、外部から参照するのは非公式・非サポート」だということです。
Windowsが勝手に場所や内容を変えるのも自由。だから「ビルド済みバイナリから直接文字列を盗む」のは絶対にやってはいけない――と警鐘を鳴らしているのです。
文字列リソースの「不変性」を勝手に信じると起きる惨事
なぜ、こんなにも「やってはいけない」のか？
記事で具体例として紹介されているのは、言語パック修正時に起きやすい問題です。
翻訳チームが「Y/N」表記のミスを見つけて修正する際、既存パックの都合上、元の文字列は消さず新しい場所に新しい文字列を追加することがあったそうです。
このとき、プログラム本体は新しい文字列を使い始めるのに、「バイナリから直にYes/No表記を拾う外部プログラム」は、古い場所の誤った文字列に依存し続ける…。
このズレが「微妙なバグ」や「思わぬ動作不良」を生む本質的原因となります。
更にリソースの仕様そのもの――
* バイナリ形式やオフセットはWindowsやアプリのバージョン、ビルドによって変わる
* 言語ごとに管理法や位置付けが異なる可能性
* そもそも公的なAPIとして「ここからYes/No表記を取得せよ」と保証されていない
こうした背景を無視して実装してしまうのは、「家の柱の太さは未来永劫変わらない」と信じて無断で壁に穴を開けるようなもの。
表層的には動いても、体制変更によりいつ崩壊するか分かりません。
「ラッキーなバッドプラクティス」に頼らず公式APIで戦う覚悟を
筆者は、なぜ多くの現場で「裏技的ショートカット」を使ってしまうかに着目すべきと考えます。
システムやアプリは一見「変わりそうにない部分」をハードコーディングしてクリアすることで、「今だけうまくいく設計」に陥りがちです。
特にWindowsのように歴史ある巨大OSの場合、「古くからのバイナリ互換維持」が重視される一方、実装の詳細は絶えず変わります。
APIが明示的に仕様を保証し、ドキュメントに明記されたもの以外は、「．．．．まあ大丈夫なんじゃ…」と勝手に信じ込むのは極めて危険です。
現代の開発現場では、ユーザー体験やメンテナンス効率、セキュリティ面で「ブラックボックスを勝手に覗いて依存しない」ことが最優先事項です。
リソース文字列逆引きのような「ラッキーなバッドプラクティス」は数年後に大きな負の資産＋思わぬ事故を招きます。
実際、こうした「依存の脆さ」はバージョンアップ・ローカライズ・アップデートと絡み合い、修正コストだけが膨れ上がることを身をもって学ぶ開発者も多いはずです。
これからの開発現場へ：「仕様の外側」に賭けるな、新たな視点がトラブルを回避する
この記事は単なる一つのバグ談義で終わりません。
「自作プログラムがシステムの未公開内部仕様に依存するのは、たまたま動作するものの、長期的な保証はなく、一瞬で『資産』が『負債』になること」。
これが現代開発の最大の教訓です。
ユーザーごとのカスタマイズ、自動化、多言語対応などを実現したいなら、「公式に約束された手段」のみを信じること
それがシステム設計の鉄則。
派手な裏技を仕込むより、「何も起こらない」プログラムを静かに組む勇気が、将来の不具合・事故を未然に防ぐ最良の方法となります。
みなさんの日々の開発や業務効率化の現場でも、「今、偶然動いているのは本当に公式な仕様にのっとっているのか？」
定期的に振り返る習慣を持ちたいものです。
categories:[technology]
コメント