Webエンジニア向けプログラミング解説動画をYouTubeで配信中!
▶ チャンネル登録はこちら

【ITニュース解説】I tried to check if our new blockchain tools were being used. The tool that would have told me was also silently broken — and so were two other things.

2026年09月19日に「Dev.to」が公開したITニュース「I tried to check if our new blockchain tools were being used. The tool that would have told me was also silently broken — and so were two other things.」について初心者にもわかりやすく解説しています。

作成日: 更新日:

ITニュース概要

開発者が新機能の利用状況を確認中、確認ツールがCloudflare設定ミスでサイレント停止。同様にフィードバック機能もデータベース未設定やセキュリティ設定ミスで動作せず。クラッシュしない「フェイルオープン」設計が、問題発生を隠蔽し発見を遅らせた。適切な監視の重要性を学ぶ事例。

ITニュース解説

システム開発の現場では、新しい機能が意図通りに動いているか、また想定外のトラブルが発生していないかを確認することが非常に重要だ。この記事は、あるエンジニアが自身の開発した機能の利用状況を確認しようとした際に、次々と発見された「静かに発生する問題」について語っている。

まず、エンジニアは新しく開発したAPIの利用状況を把握するため、専用のエンドポイントを呼び出した。これはCloudflare KVというクラウドデータストアから利用回数を読み出す仕組みだが、呼び出すとエラーで停止した。原因は、本番環境で必要な設定値が読み込まれていなかったことと、Cloudflare KVデータストアがそのプロジェクトに正しく連携(バインド)されていなかったためだ。この連携は通常の画面操作だけでなく、設定ファイルでの記述も必要だった。

この問題がこれまで表面化しなかったのには理由がある。システム内の多くの機能が、エラーで停止するのではなく「フェイルオープン」という設計になっていたためだ。フェイルオープンとは、一部の機能が利用できなくても、システム全体が停止するのを避け、エラーを発生させずに処理を進める考え方である。これはユーザー体験を損なわない点では優れているが、裏側で問題が発生していても開発者に通知されないため、気づきにくいという欠点がある。今回もこの「静かに失敗する」挙動が、問題が長期間放置される原因となっていた。バインド修正後、利用状況が確認できるようになり、実際に4,852回ものAPI呼び出しがあったことが判明した。同時に、APIのアクセス制限を行う「レートリミット」機能も、設定不足により同様に機能していなかった。

API利用状況の問題解決後、エンジニアは「他に同様の問題はないか」と考え、ウェブサイトのフィードバックフォームの動作を確認した。このフォームはCloudflare D1というデータベースを使用していたが、調査の結果、データベース内にフィードバックを保存する「テーブル」が作成されていなかったことが判明した。そのため、リリース以来、ユーザーからのすべてのフィードバックは静かに破棄されていた。しかし、偶然にもデータベースのバインドが壊れる前の、たった一つのフィードバックが見つかり、それは開発者にとって嬉しい内容だった。

データベースのバインドを修正し、テーブルを作成してフォームをテストすると、今度は別の問題が起こった。フォームに埋め込まれた、ボットからの投稿を防ぐためのアンチボットウィジェットが正しく読み込まれないのだ。原因は、ウェブサイトのセキュリティ設定であるCSP(Content Security Policy)ヘッダーにあった。この設定は、ウェブサイトが読み込むスクリプトの出元を制限するものだが、アンチボットウィジェットが必要とするドメインからのスクリプト読み込みまでブロックしてしまっていたためだ。CSP修正後、再度テストすると、今度はアンチボット認証がエラーで失敗した。これは、必要な秘密鍵とサイトキーのコピーペーストミスが原因だった。

このように、エンジニアは数時間の間に四つの異なる問題に直面したが、それらはすべて「フェイルオープン」という共通の設計パターンによって「静かに失敗」していた。API利用状況の確認、レートリミット、フィードバックの保存、アンチボット認証のすべてが、エラーを発生させずに動作しない、という形で問題が隠蔽されていたのだ。

フェイルオープンは、利用者にとっては中断が少なく見えるため優れた設計だ。しかし、開発者が裏側で発生している問題を検知できない大きなリスクを伴う。エラーが通知されないため、問題が長期間放置され、ビジネスに影響を与える可能性もある。この経験から得られる教訓は、システム開発において「エラーにならないこと」が必ずしも「正しく動いていること」を意味しないということだ。特に、複数の外部サービスやコンポーネントが連携する現代のシステムでは、設定ミスや環境の問題が「静かな失敗」として隠れてしまうことが多い。そのため、開発者は、たとえフェイルオープン設計を採用していても、必要な設定や連携が正しく行われているかを定期的に自動でチェックし、問題があれば開発者に「大声で」通知する仕組みを構築する必要がある。これは、システムの健全性を保ち、信頼性を向上させる上で不可欠な対策となる。

関連コンテンツ

関連IT用語

関連ITニュース