http://takagi-hiromitsu.jp/diary/20101204.html#p01
詳細はリンク先などを見ていただいて、思ったことを。
２０００年にベースを付くって、２００５年にSIして、導入。２０１０年にクローラーによるアクセスにより設計の不具合が発覚した。
という部分で「いま思えばあのコードはまずかったよなぁとか、あの設計じゃ同じ事起きるんじゃないかなー」って思っているエンジニアは多いんじゃないかと思います。
おそらく各図書館と、MDISとは保守契約が結ばれていたでしょうが、たとえば１０億円のシステムだったとして、毎年１億円の保守費用を払って常にバージョンアップするというような契約ならまだしも、毎年１０００万の保守費用で、ハード故障の仲介と、相談できますよというレベルの保守だったとしたらMDISの「動きとしては正常」的な返答を誰が責められるのでしょうか。
システムは完成！してしまえばその時点から劣化が始まります。目に見える床とかだと、痛んできたなとか、張り替えなきゃなとか思うのにソフトだからわかんないんですよね。
今回の物もASP.NET版の設計はASP時代にメジャーだったコネクションのセッション保持から、コネクションプーリング型への転換がなされたから防げるようになったんでしょうけど、それを意図してそう変更した訳じゃないので、
神田記者：時代にあった製品を納めるという部分の話なんですが、私の取材だと、岡崎の場合ASP版という図書館ソフトウェアを使っておられると、ただそれは新しいバージョンが、ASP.NET版というのがあって、これはもう2006年から各地の図書館に御社納入されていると。.NET版の方は、今回のようなアクセスがあっても問題は起こらないわけですね。なぜその改良を元のASP版、旧版の方にも加えなかったのか、それはまさに時代の要請に合わせて御社はプログラムを改良されてこられたわけなので、それを反映させればよかったんじゃないかと思うのですが、そこはいかがでしょうか？
門脇社長：まず、.NET版がですね、こういった機械的なアクセスに対応できているということは、設計上、後でわかってますけども、.NET版とASP版でしたっけ、ASP版は、設計が全く別の設計の形をとっておりまして、クローラ対策という形で.NET版を出したということではなくて、
こういう記者からツッコミを受けたってそんなのどうすることも出来ないよ！としか言えないと思います。
robots.txtで対応しましたとか、コンテンツのURLを切り替えて対応しましたとかプログラムは修正出来ないという状況で、とりあえず眼前の状況に対応してくれと言われればこれくらいが対応の限界だと思います。
アプリケーションがSIした組み込みなのがいけないと言われてもASP（ApplicationServiceProvider）型が最善とは思いませんし、図書館毎にカスタマイズして導入しているような今回の場合だとASPでとなってもそうそううまくいくわけでもないです。それはAzure等のクラウドとか呼ばれている物にしたって何も状況は変わりません。
ではどうすればいいのか。
少なくともインストールした後もこれを「瑕疵だ瑕疵だ」とか「瑕疵範囲外なので調べられません」とか「プログラムを変更しない範囲で調査」とか言わないで済む必要があります。これは契約の甲乙両方が努力する必要がありますし、年度が替わっていたら新しく売り上げが立たないことに本気で調査なんて出来ない訳です。
「結局金か！」となるのがつらいところですが、常にバージョンアップする仕組みにしておいてもこちらの顧客からのアラートが最優先になって調査されるわけではないので、MS等がやっているようなインシデント（1回何万円）等と決めておいて、最優先に調査、変更する予算提示をするというメニューくらいしかないのかと思います。
別のプロジェクトに関わっているのに、昔やったでしょとか言って今すぐに無料で調査してよっとか言われて困っているエンジニアは何処にだって居るはずなのです。