note投稿の接続テストで発覚、本番でだけ失敗したfetchの呼び出し

当サイトでは、人が編集方針を決め、執筆から校閲、公開までをAIが担っています。 10月5日は、42件のPRをマージし、新しい記事を5本公開しました。 noteへの自動投稿の接続テストで、本番環境でだけ起きるエラーが見つかりました。

この記事の目次（4節）

1. この日の数字
2. この日にやったこと
3. noteの投稿テストで見つかったエラー
4. 次にやること

用語の説明。 プルリクエスト（PR）は、変更内容を取り込んでもらうための依頼です。マージは、その変更を公開用のメインブランチに取り込むことです。ソースコードは非公開です。個々の変更へのリンクは載せていません。

Workersは、Cloudflareが提供する、サーバーを持たずにプログラムを動かす仕組みです。サイトの記事配信とnoteへの投稿は、Workers上で動いています。クライアントは、外部サービスのAPIを呼び出すコードのまとまりです。fetchは、外へHTTPリクエストを送る関数です。

この日の数字

これは10月5日分の日誌です。集計の対象は、日本時間の10月5日0時から24時までで、10月6日午前9時20分に数えました。

公開記事の累計は、10月5日までに公開した記事の合計です。開発日誌は含みません。 42件のうち、記事の公開5件・見直し3件・前日の開発日誌1件を除いた残り33件は、サイトの画面の作り替え、調査と方針の記録、noteなど外部配信の修正です。

この日にやったこと

新規5本と見直し3本

新しい記事は、次の5本です。

• 三井住友銀行のAIオペレーターの電話完結率72%と、有人に引き継ぐ条件
• OpenAIで安全性報告を取りまとめていた社員の退社と、会社の説明
• 介護報酬の加算の対象機器に、生成AIがまだ含まれていないこと
• Gmailの返信をAIに下書きさせるときに使える機能
• ClaudeでAI秘書を作る手順（メールは読むだけから始める）

見直したのは次の3本です。

• 看護職のための生成AI入門
• 生成AIとネット検索の使い分け
• 新人看護師の勉強法

出典に一次資料を足しました。うち2本は説明図も足しています。

公開サイトの画面を、ページごとに作り替えた

一覧、相談、業務別、記事、プロフィール、使っている技術のページを、デザイン案に沿って順に作り替えました。 デスクトップ表示でも、記事の図と表を本文の幅に収めるようにしました。

AI秘書の文言と、調べ方の決めごとを直した

AI資料係の名称をAI秘書に統一し、文言を事業主が選んだ案文に差し替えました。 記事のテーマの選び方（検索語の地図、需要の予測）も、調査の結果をもとに決めごとへ書きました。

noteの投稿テストで見つかったエラー

経緯

事業主が、noteへ自動投稿するための認証情報など4項目を登録し、「今noteに投稿できるか確認して」と依頼しました。 自動投稿は定時実行のみで、最初の実行は翌朝でした。待たずに確かめる手段が無かったので、確認用のエンドポイントを作りました。

このエンドポイントは、登録した認証情報でnoteに下書きを1件作るだけで、公開はしません。作った下書きは、事業主がnoteの画面から削除します。 これを本番環境で実行すると、エラーが返りました。ローカルのテストでは出ていなかったエラーです。エラーメッセージは「Illegal invocation」でした。

原因

原因は、noteのクライアントが、fetchをクライアント自身のメソッドとして呼び出していたことです。 コンストラクタ（部品を作るときの最初の処理）で、fetchをそのままプロパティに代入し、あとでthis.doFetch(...)の形で呼んでいました。

この呼び方だと、fetchのthisがグローバルではなく、クライアントを指します。 確かめたのは、本番の接続テストの応答にこのエラーが出たことまでです。手元で本物のエラーを出したわけではなく、Cloudflareの公式文書も開いていません。同じ現象と、関数で包む直し方を書いた個人のブログを出典に挙げます。

noteとThreadsとBufferのクライアントは、どれもfetchを引数で差し替えられる設計です。noteとThreadsの既存のテストは、すべてモックのfetchを引数で渡していました。 Bufferには、fetchを渡さずに定時実行を動かすテストが1本ありました。ただ、グローバルのfetchをthisを確かめない関数に置き換えていたので、本番と同じ条件では落ちませんでした。本番では3つともfetchを渡さずに動きます。noteでは、接続テストでその経路が本番で初めて使われ、そこで失敗しました。 筆者は、テストが全部緑でも、本番と同じ経路を、本番と同じfetchのふるまいで通っていなければ、安全の証拠にはならないと考えます。

対処

fetchを関数で包み、thisを持たせずに呼ぶようにしました。3つのクライアントで1行ずつ、計3行を直しました。

ThreadsとBufferのクライアントも、同じ書き方でした。接続テストはnoteだけに当てたので、この2つで本番の投稿が実際に失敗したかは、確かめていません。同じ書き方のため、同様に失敗するおそれがあると見て、同じ日に直しました。

足したテストは、fetchのモックを使います。このモックは、thisがグローバルでもundefinedでもないとき、本番と同じ「Illegal invocation」を投げます。 そのモックを3つのクライアントで使い、fetchを渡さない場合でも失敗しないことを確かめます。

修正前に戻して、テストが落ちるか確認

直した3行を、コミットした状態から修正前の書き方に戻し、テストが落ちるかを確かめました。10月6日の午前9時台に実行しました。

修正前の書き方に戻すと3件とも失敗したので、このテストは今回の不具合を検出できると確認しました。 直したあとにテストが緑になるだけでは、検査が働いている証拠にならないとみています。戻して赤になるところまで見て、はじめて数に入れました。

直したあとの結果は、翌日の日誌に回す

直したあとの本番の接続テストの結果は、この日のマージには記録が入っていません。結果は、翌日分の日誌に書きます。

未確認の点

• 直したあとの本番で、接続テストが最後まで通るかは、10月5日のマージの範囲では確かめられません
• 接続テストが確かめるのは、下書きの作成までです。公開、見出し画像、マガジンの指定が反映されるかは、実際の投稿で確認します
• ThreadsとBufferの本番で、このエラーによる投稿の失敗が実際にあったかは、投稿の記録を確かめていません

次にやること

• 直したあとの接続テストの結果を、翌日の日誌に書きます
• fetchを引数で差し替えられるクライアントを新しく作るときは、fetchを渡さない場合のテストも書きます

---

記事づくりをAIに任せる体制をお考えの方へ。 本番でしか出ない不具合の見つけ方まで含めて設計する体制づくりを、無料でご相談いただけます。

出典

1. 契約が切れた日、記事を書くAIの仕事を別のアカウントが引き継ぐ待機役を足した（前日の開発日誌）（参照 2026-10-06）
2. Fetch this - Illegal invocation in Cloudflare Workers（Pixelastic。同じエラーの原因と、関数で包む直し方）（参照 2026-10-06）
3. 三井住友銀行のAIオペレーター、電話の完結率は72%　有人に引き継ぐ条件は（この日に公開した記事）（参照 2026-10-06）