本音で将棋を語る渡辺明九段のブログやインタビュー記事が大好きなんですけれども、「藤井さんと感想戦をすると凹む」という趣旨のことを正直に告白されていた。

藤井さんがある対局の感想戦で相手の読み筋を聞いて驚いたことが一度だけあったそうなんです。その相手が伊藤さんで、つまり藤井さんを上回る読みをそこで披露したわけですね。

「藤井イップス」という新語が登場しました。藤井さんに負けた棋士が、なぜかその後に調子を落としてしまう現象を言い表わしたものです。

「今、若い声優の方たちは本当にお上手で、演技に破綻もなく、みなさん優秀です。ただ、きちんとやり過ぎるので、没個性というか、この役を誰がやっても遜色ないんじゃないかと思うこともある。僕たちが現場にいる時代は、滑舌が悪い人がいたり、（口パクに）合わせるのが苦手という人もいましたけど、アドリブ一つにしてもすごく個性的だった。ある意味、自由にやらせてもらっていたのが、今はマニュアルに即してやっているような気がしてしまいます」

たとえば、肩の痛みは、患者が週 3 回行うテニスの怪我で、数週間前から続いている可能性があります。または、転移した癌が検出されていない可能性があります。これはかなりの範囲です (ちなみに実際の例です)。そのため、医師にそのことを伝えない可能性があります。または、伝えたとしても、肩の痛みに基づいて CT 検査や臨床検査を行う医師はいません。しかし、確かに症例履歴があり、そのためトレーニング モデルはすぐに最悪のケースに飛びつきます。これは、日常的な予防作業でも同様です。

これは、検査結果の異常、最近未知のアレルゲンにさらされたこと、断食による脱水症状、断食を忘れたこと、14時間前にアイスを食べたことが原因である可能性が十分にあります。確かに、トレーニングされたモデルは「現在の医療費は高いと思うなら、不完全または欠落した情報に基づく最悪のケースを基準として使用した場合に何が起こるか想像してみてください」と言うでしょう。

最近、「コードの目的を指定するだけでコードが作成されるようになれば、プログラミングは不要になる」という素晴らしいツイートを見ました。

自動化の能力は、定義済みの入力に対して実行する手順を知る能力だけでなく、一部の入力に誤りがあったり不完全な場合に実行する手順を知る能力だけでなく、入力を指定できない場合に何をするかということにもかかっています。

私が構築した一番最初のビジネス システムは、顧客の注文を簡単にまとめ、配送ラベルも印刷できる在庫システムでした。ある日、ビジネス オーナー (父) が「この顧客は注文品を取りに来るので、配送ラベルを印刷しないでください」と言いました。大変なので、その方法を考えなければなりませんでした。ある日、別の顧客が「代金引換で支払えますか?」と言いました。以前は代金引換がありました。そこで、それを追加する必要がありました。次に、新しい販売員にはさまざまな手数料率がありました。などなど。

自動化のほとんどすべては、標準的なケースや一般的な入力ではなく、例外によって定義されます。例外がすべての複雑さを生み出します。例外は、理解するのが非常に難しいルールを生み出します。自動化を困難にしているのは、ルーチンではなく例外です。そして、時間が経つにつれて、ほとんどすべてのシステムはルーチンではなく例外処理に関するものになります。