支払い済みなのに1週間使えない、という投稿

海外の技術者が集まる掲示板に、ある会社の担当者がこんな相談を書き込んだ。自分たちのチームは1年以上、Claudeの有料チームプラン（複数人で使う法人向けの契約）を使ってきた。特別な業種でも危険な使い方でもない、ごく普通の会社だ。請求はすべて支払い済みで、管理画面にも支払い済みと表示されている。それなのに、ある日から1週間以上サービスにアクセスできない。

困ったのはその先だ。問い合わせ窓口にメールを送っても、返ってくるのはAIチャットボットの自動応答だけで、人間の担当者に話が届いた手応えがない。投稿者は、他に連絡を取る手段はないか、同じ経験をした人はいないか、何をしたら解決したのかを尋ねている。そして最後にこう添えていた。社内の業務フローをClaude前提で組んでしまった人たちが、いま完全に手が止まっている、と。

念のため書いておくと、これは一方の当事者による投稿であり、私はその会社の契約状況も、停止の理由も、その後どうなったかも知らない。だからこの話を、特定の会社を責める材料として読むのは筋が違う。この投稿の価値は、有料でSaaSを使っている会社なら明日にでも自分の身に起こりうる事故の、生々しい記録だという点にある。 犯人探しではなく、自分たちの業務がどれだけ他人の判断ひとつで止まる設計になっているかを点検するきっかけとして読みたい。

なぜ有料でもアカウントは止まるのか

多くの人は、料金を払っている以上サービスは動いて当然だと思っている。感覚としては正しい。ただ、実際のクラウドサービスの運用は、そういう単純な作りにはなっていない。

第一に、アカウントの停止は人間の判断ではなく自動の仕組みで起きることが多い。世界中の何百万というアカウントを少人数のチームで見ているため、不正利用や規約違反の疑いは機械が検知して先に止め、確認は後から人間がやる、という順番になる。検知の材料は、短時間の異常な利用量、普段と違う国からのログイン、支払い方法の変更、メンバーの急な増減、複数アカウントの関連づけなど多岐にわたる。悪意がなくても、たとえば出張先から全員がログインした、社内ツールから自動でまとめて処理を投げた、法人カードを切り替えた、といった普通の出来事が引き金になりうる。

第二に、サポートの一次対応をAIが担う体制はいま業界の標準になりつつある。これ自体は責められる話ではない。むしろ、よくある質問の九割をAIが即答するからこそ、残りの一割に人手を回せる。問題は、自動判定で止まったアカウントの解除という、まさに人間のレビューが必要な案件が、その一次対応の網に吸い込まれて滞留したときだ。利用者から見ると、機械に止められて機械に相談窓口をふさがれている状態になる。支払い済みであることは、止まらない保証ではなく、止まったときに交渉できる根拠でしかない。

止まるのはツールではなく業務手順

ここが非エンジニアにとって一番大事なところだ。AIサービスが止まったとき、失われるのはソフトの利用権だけではない。実際に止まるのは、その周りに組み上げた業務手順のほうだ。

たとえば毎週月曜に、営業担当が先週の商談メモを貼り付けて要約させ、その要約を営業会議の資料に流し込んでいるとする。この手順は誰の頭の中にもある。ただ、そこで使っている指示文（プロンプト）は、担当者の個人チャット履歴の中にしか残っていないことが多い。過去の出力も同じ場所にある。ツールにログインできなくなった瞬間、手順を実行できないだけでなく、手順そのものの記録が取り出せなくなる。これは業務の属人化ならぬ、業務の属ツール化と言っていい。

もうひとつ厄介なのが、復旧までの時間を自分たちで決められないことだ。社内のパソコンが壊れたなら、買い替えるか修理するか、判断は自分たちの手にある。しかし他社のクラウドサービスが止まったときの復旧時期は、相手の対応キューの中にある。1日で戻るかもしれないし、投稿者のように1週間を超えるかもしれない。自社でコントロールできないのは復旧時間であって、止まったときに何日耐えられるかは自社で設計できる。 この線引きができていれば、同じ事故でも被害の大きさはまったく変わる。

現場ではこう効く（4つの具体例）

抽象的な話にしないために、実際にありそうな現場を並べる。

30人規模の税理士事務所の場合。 決算期に、顧問先から届く試算表や領収書の説明メモをClaudeに読ませ、確認事項の一覧と顧問先向けメールの下書きを作らせている。担当者ひとりが1日20件処理していたものが、この手順のおかげで35件まで伸びていた。ここでアカウントが止まると、単に効率が落ちるのではなく、すでに35件前提で組んだ申告期限までのスケジュールが破綻する。しかも繁忙期なので、代替手段を検討する余裕そのものがない。この事務所にとっての正解は、決算期に入る前に、確認事項一覧のフォーマットと指示文を共有フォルダに出しておき、最悪は手作業でも同じ品質の一覧が作れる状態にしておくことだ。

10人規模のマーケティング会社の場合。 提案書の骨子づくり、競合の公開情報の整理、記事の初稿、月次レポートのコメント欄。ほぼ全工程にAIが入っている。代表がひとりで管理者アカウントを持ち、メンバーを招待して使わせている構成が多い。この会社のリスクは二重だ。サービス側が止まる可能性に加えて、管理者ひとりに紐づいた契約であるために、代表が出張中や体調不良のときには請求元も問い合わせ履歴も誰も触れない。提案の締切が明日という日にログインできなくなれば、提案自体を落とすことになる。備えとしては、指示文のテンプレート集を社内の共有ドライブに置き、管理者を最低2名にしておくことが先だ。

製造業の総務・人事担当の場合。 従業員120人の会社で、総務担当が2名。就業規則に関する社員からの問い合わせに対して、規則の該当条文を探して平易な回答文を作るのにAIを使っている。加えて、月次の安全衛生委員会の議事録の整形、採用候補者へのスカウト文の作成。ここが止まったときの痛みは、締切があるものより、じわじわ滞留する問い合わせのほうに出る。回答が遅れれば社員の不満が溜まり、担当者は残業で埋め合わせる。総務の仕事は止まっても外からは見えないため、経営に報告が上がらないまま2名が消耗する。この職場では、よく来る問い合わせ20件分の回答テンプレートをあらかじめ文書化しておくだけで、止まった1週間の負荷はかなり下がる。

ひとりで動く個人事業主の場合。 フリーランスのライターやデザイナー、社労士や行政書士のような士業の方は、法人チームより深刻になりやすい。代わりに動く人がいないからだ。取材音声の文字起こしの整理、クライアントへの提案文、見積書の説明文まで一人二役でAIに任せていると、止まった瞬間に稼働が半分になる。しかも個人契約は法人契約よりサポートの優先度が上がりにくい。ここでの現実解は、月額数千円の別サービスを一つだけ併用しておくことだ。全部を二重化する必要はなく、納品物に直結する工程だけ逃げ道を持てばいい。

明日からできる備え（4ステップ）

やることは多くない。むしろ多くすると続かない。私が勧めるのは次の4つだけだ。

一つ目は、指示文の外出しだ。社内の共有ドライブにプロンプトというフォルダを作り、業務ごとに1ファイル、テキストで置く。ファイル名は「月次レポート_コメント作成」のように業務名で付ける。中身は使っている指示文をそのまま貼り、末尾に、この手順が使えないときは誰が何分で代替するかを1行書き足す。週1回、5分でいい。これだけで、止まったときに失われるのがアクセス権だけになる。

二つ目は、代替経路を1つ決めることだ。ここで欲張って複数のサービスを契約しても管理しきれない。品質が多少落ちても業務が止まらない線はどこかを決め、その線を守れる代替を一つだけ用意する。同じ会社のサービスであっても、法人契約とは別に個人のアカウントを1つ持っておくだけで、緊急時の逃げ道になることは多い。重要なのは、緊急時にどれを使うかを事前に紙に書いておくことで、事故の当日に検討を始めないことだ。

三つ目は、契約情報の二重化だ。管理者権限を持つ人を2名にする。請求書の送付先メールアドレスを個人アドレスではなく共有アドレスにする。契約プラン名、契約開始日、組織のID、直近の請求書番号を1枚のメモにまとめ、経理と情シス担当（いなければ代表）の両方が見られる場所に置く。止まったときの問い合わせでこの情報が即座に出せるかどうかで、対応の初速が変わる。

四つ目は、月1回の耐久テストだ。毎月どこかの1日を決め、その日はAIを使わずに通常業務を回してみる。すると、どの工程が本当に依存しているかが手触りでわかる。多くの会社は、想像より依存度が低い工程と、想像よりはるかに依存している工程の両方を発見する。備えの目的はAIの利用を減らすことではなく、どの工程が止まると事業が痛むのかを事前に知っておくことにある。

実際に止まったときの初動

備えていても止まるときは止まる。そのときの動き方を、順番で書いておく。

最初にやるのは切り分けだ。全員が使えないのか、特定のひとりだけなのか。ブラウザを変えても、別の回線からでも同じか。これを3分で確認する。ひとりだけの問題なら、そのアカウントの再ログインや招待し直しで解決することが多い。組織全体なら、契約か請求に紐づく停止の可能性が高い。

次に、証拠をそろえる。支払い済みが確認できる請求画面のスクリーンショット、直近の請求書PDF、エラー画面のスクリーンショット、組織名と管理者のメールアドレス。これらを1つのフォルダにまとめる。問い合わせを何度も出し直すと別々の案件として処理されて余計に遅くなるため、送信は1つのスレッドに集約し、追記は同じスレッドへの返信で行う。

問い合わせ本文は、感情を書かず、事実と依頼だけを短く書く。以下をそのまま使ってもらっていい。

Subject: [Account suspended] Team plan inaccessible since YYYY-MM-DD

Organization: (組織名)
Admin email: (管理者メールアドレス)
Plan: Team (paid, active since YYYY-MM)
Latest invoice: (請求書番号 / 支払日 / 金額)
Issue: All members have been unable to access the workspace since YYYY-MM-DD.
Payment status shows as paid in the billing page (screenshot attached).
Request: Please have a human reviewer check the status of this account.

その上で、社内には即日で状況を共有する。担当者が黙って残業で吸収するのが一番まずい。どの業務が何日遅れるのかを一覧にして、優先度の低いものは止める判断を経営側が出す。SNSや掲示板で公開して反応を待つ方法は、実際に動くこともあるが最後の手段だ。契約内容や社内情報を晒すことになるので、書く前に何を書かないかを決めておく。

よくある誤解を3つ正す

一つ目は、お金を払っているのだから止まるはずがないという誤解。すでに書いた通り、停止の多くは自動判定で起きる。支払い状況は判定材料の一つに過ぎず、支払い済みは止まらない理由にはならない。契約書に稼働率の保証（SLA）がある場合でも、返金の根拠にはなっても、今日業務が動く保証にはならない点は押さえておきたい。

二つ目は、バックアップとは出力を保存しておくことだという誤解。これは半分しか正しくない。過去の出力を保存していても、新しい仕事は進まない。本当に保存すべきなのは、出力ではなく手順と指示文だ。逆に言えば、指示文さえ手元にあれば、別のサービスでも精度は落ちつつ同じ作業を進められる。

三つ目は、別のAIに移せば同じことができるという誤解。指示文は移植できるが、出力の質は同じにはならない。日本語の文章の自然さ、長い資料の読み込み、指示に対する素直さは、サービスによって癖が違う。だから乗り換え先には完全な代替を期待せず、品質が落ちても業務が止まらない線を先に決めておく必要がある。代替手段の目的は同じ品質を出すことではなく、業務を止めないことだと割り切ると、準備はぐっと軽くなる。

社内の業務フローをClaude前提で組んでしまった人たちが、いま手が止まっている。

冒頭の投稿の、この一文がすべてを表している。悪いのはAIを深く使い込んだことではない。深く使い込んだのに、その前提が消えた日の手順を書いていなかったことだ。

まとめ

有料で1年以上使っていた会社が、支払い済みのまま1週間以上アクセスできず、問い合わせても自動応答しか返ってこない。この一件から持ち帰るべきなのは、特定のサービスへの不信ではない。他社のサービスの上に自社の業務手順を建てている以上、復旧時間は自分たちの手にないという事実だ。

だから設計を変える。指示文と手順は必ずツールの外に置く。代替経路を一つだけ決めて紙に書く。管理者と請求情報は2人で持つ。月に1日だけAIなしで回してみる。この4つは、どれも1時間もかからない。それでいて、止まった1週間の被害は目に見えて小さくなる。

AIを業務に組み込むこと自体は、いま迷う段階を過ぎている。組み込んだ上で、止まった日の手順まで書いてあるかどうかが、これからの差になる。使いこなす力と同じくらい、使えなくなった日に慌てない設計が、非エンジニアの実務では効いてくる。

自社のどの業務がどれだけAIに依存しているか、止まったとき何日で痛むのかを整理したい方は、Claude Worksの無料30分相談をご利用ください。業務の棚卸しと、止まらない手順設計の当て方を、現場の具体例に合わせて一緒に整理します。