Claude Code の「アカウント」とは何か

はじめに

この二年で、「Claude Code / Codex を使いたい」という話は、パッケージを入れてキーを貼る だけの作業から、真面目な技術選定を要する問題へと変わりました。

コミュニティでは同じ種類の疑問が繰り返し現れます。しかも質問しているのは、決して初心者ではありません。

• 「API のクレジットを買ったのに、なぜウェブ版はログインを求めてくるのか」
• 「同じアカウントなのに、昨日は快調で今日はずっと回り続けている。何が変わったのか」
• 「中継業者はどこも IP の話ばかりする。自分でもっと高価なプロキシを挿せば済むのでは」
• 「管理サービスは『割り当て後は環境を変えない』と言うが、保守的すぎないか。もっと良いものに替えたほうが速いのでは」
• 「二分走った長いタスクが途中で切れた。なぜ一度やり直すほうがかえって損なのか」

ばらばらに見えますが、すべて同じ一点を指しています。多くの人が「アカウント」を分割不能な原子として扱っていること。実際にはそれは、三種類の認証情報 + 二段のクォータウィンドウ + 一組の同一性制約の重ね合わせです。この層を分けない限り、上のどの問いにも答えは出ません。

本稿は「うまく立ち回る方法」を説くものではなく、対抗的な手順も一切含みません。やることはひとつだけ——工学的制約を明確にすること。なぜそうなっているのか、そしてその制約の下で各方式の限界はどこにあるのか。

全体で約一万字、原理図を 5 点収録しています。読み終えれば、上の五つの問いに自分で答えられ、自分がどの道を選ぶべきかが分かるはずです。

目次

• 第一章 認証情報論：ひとつのアカウントに三つのものがぶら下がっている
  • 1.1 まず結論から
  • 1.2 二つの経路は、課金システムの時点で分岐している
  • 1.3 API キー：ステートレスな従量入口
  • 1.4 OAuth トークン：サブスクリプション枠を伴う身元
  • 1.5 セッション認証情報：ウェブの層
  • 1.6 派生関係：何から何が作れるか
• 第二章 クォータ論：ローリングウィンドウが体感を決める
  • 2.1 二段のウィンドウ
  • 2.2 ウィンドウはアカウント単位で数えられる
  • 2.3 共有時に生じる行列効果
  • 2.4 429 の読み方：すべての「レート制限」が同じ意味ではない
  • 2.5 ウィンドウモデルでは「均等配分」が成立しない理由
• 第三章 同一性：怖いのは使われることではなく「別人に見えること」
  • 3.1 サーバー側から観測できるもの
  • 3.2 一貫性は「より良いもの」に勝る
  • 3.3 環境固定が怠慢ではなく制約である理由
  • 3.4 はっきり言っておくべき境界
• 第四章 マルチテナント分離：共有方式の限界はどこか
  • 4.1 セッション分離
  • 4.2 クォータ分離
  • 4.3 障害分離
  • 4.4 三つを同時に満たせるか
• 第五章 ストリーミング：中継層で最も難しい部分
  • 5.1 「受け切ってから転送」ができない理由
  • 5.2 四種類の切れ方が、外からは同じに見える
  • 5.3 リトライは冪等ではない
  • 5.4 タイムアウト設定のジレンマ
  • 5.5 バックプレッシャー：見落とされがちな一点
• 第六章 引き継ぎと復元：管理クライアントがあなたの端末で何をするか
  • 6.1 問題の定義
  • 6.2 バックアップ・上書き・復元
  • 6.3 置換ではなくマージする
  • 6.4 冪等性と「最初のバックアップが正」
  • 6.5 クラッシュ安全性：途中で電源が落ちたら
  • 6.6 撤収時の対称性
• 第七章 可観測性：何が見えることを要求すべきか
  • 7.1 素朴な判定基準
  • 7.2 具体的に見えるべきもの
  • 7.3 ひとつのアンチパターン
• 第八章 デバイス紐付け：なぜ認証情報は「この端末」に発行されるのか
  • 8.1 一度のログイン、複数の端末
  • 8.2 失効が一級市民でなければならない理由
• 第九章 選定：一枚の判断表
  • 9.1 入場コストだけでなく、退出コストも数える
  • 9.2 この二つは二者択一ではない
• 第十章 九つの誤解、一枚の表で
• おわりに

第一章 認証情報論：ひとつのアカウントに三つのものがぶら下がっている

1.1 まず結論から

Claude や ChatGPT のアカウントは、技術的には「ひとつのもの」ではありません。少なくとも三種類の、互いに等価でない認証情報を派生させます。

最も直感に反し、最もよく踏まれるのが最後の列です——三つは開ける扉が異なり、互いに代替できません。

1.2 二つの経路は、課金システムの時点で分岐している

「入口が違うだけで、その先は同じモデルに繋がっている」と考える人が多いのですが、技術的に同じ重みへ到達するのは事実である一方、課金・認証・レート制限という三つの軸で完全に分離された二つのシステムです。

この分離は意図的な設計です。理由は単純で、二種類の利用者が求めるものが根本的に違うからです。プログラムからの呼び出し側は、予測可能な単価、水平にスケールする並行性、「誰かがオンラインである」ことに依存しない安定性を求めます——ステートレスな鍵が最も適します。個人のサブスクリプション利用者は「定額で好きなだけ」を求め、事業者は一部のヘビーユーザーに潰されないためクォータを導入せざるを得ません。そしてクォータを機能させるには、消費を特定の人物に帰属させる必要があり——ゆえに身元が要り、ログインが要ります。

ここまで腑に落ちれば、「なぜ〜できないのか」という疑問の多くは自然に解消します。事業者が繋ぎたくないのではなく、繋いだ瞬間に二つの課金体系が整合しなくなるのです。

1.3 API キー：ステートレスな従量入口

API キーの技術的特徴は四文字で言えばステートレス計量です——いかなるログインセッションにも紐付かず、どの端末で、どのクライアントから使おうと同じ。この文字列を添えればサーバーは受け付ける。課金はトークン単位で精算されます。

ステートレスだからこそ、プログラムからの呼び出し（CI、バックエンドサービス、バッチ処理）に極めて向いています。「誰かがそこに座ってログインしている」必要がありません。

そしてステートレスだからこそ、人に向いたどの画面も開けません。ウェブ版の対話画面もデスクトップクライアントも、求めているのは「課金できる認証情報」ではなく「ログイン済みの身元」です。サーバー側ではこの二つはまったく別の認証経路です。

これが「API のクレジットを買ったのに、なぜウェブ版がログインを求めるのか」への完全な答えです。製品の作りが不親切なのではなく、手元のその文字列は最初からブラウザを開くためのものではないのです。

1.4 OAuth トークン：サブスクリプション枠を伴う身元

二種類目は OAuth トークンで、通常は対になっています。短命のアクセストークンと、それを延命するリフレッシュトークンです。

API キーとの根本的な違いは出自にあります。

• API キーは管理画面で「作成を押す」ことで生まれます。無から生じます。
• OAuth トークンはすでにログイン済みのセッションから交換して取り出すものです——「人がログインした」という事実が先に存在しなければ、発行の話にすらなりません。

帰結は二つ。

サブスクリプション枠に載り、従量枠には載りません。 公式 CLI やエディタ拡張でタスクを走らせると消費されるのは、プランに含まれるあの枠であって、トークン単位で別建てされる残高ではありません。同じ事業者でも「サブスクリプション」と「API」の請求が二本立てなのはこのためです。

派生には前提があります。 トークンを取り出せるかどうかは、元のセッションが属するアカウントのプラン帯に依存します。無料帯のセッションからは、通常コマンドラインやエディタで使えるトークンは派生できません——どこかの仲介者が「渡さない」のではなく、認可スコープが発行の瞬間に限定されているのです。

実務上の含意は明快です。コマンドラインやエディタ拡張を使うつもりなら、「アカウントを持っている」は「有料帯のアカウントを持っている」まで補完されなければなりません。 これは発注前に確認すべきことであって、設定の途中で気づくことではありません。

1.5 セッション認証情報：ウェブの層

三種類目はウェブのセッション認証情報、形としてはブラウザの中のあの Cookie です。

技術的特徴はログイン環境と強く結びついていること。セッションはある一回の具体的なログイン動作の中で発行され、サーバーは「そのセッションがその後どんな環境に現れるか」を観測しています。環境が急変したときに再検証を求められるのは、ごく普通のサーバー挙動です。

この点は第三章で展開します。本稿で工学的含意が最も重い一点だからです。

1.6 派生関係：何から何が作れるか

三者の関係を一本の鎖にすると、こうなります。

メールでログイン ──► セッション認証情報 ──► （プラン帯が許せば）OAuth トークン
                          │
                          └──► ウェブ版の対話画面

API キー ──► 従量 API     （上の鎖とは完全に並行で、交わらない）

覚えておくべき性質。

1. 矢印は一方通行です。 セッションから OAuth トークンは作れても、逆は成立しません。
2. API キーの線は孤立しています。 上のどの段階にも参加せず、上のどの段階からも作れません。
3. 「設定完了」には段階があります。 セッションを得ればウェブ版が使え、さらに OAuth トークンを得てコマンドラインとエディタが使えます。前者は必須、後者は任意の第二段階です。

この鎖が、よくある戸惑いを説明します。管理サービスの設定後、「ウェブ版が先に使え、コマンドラインは後から」になりがちなのはなぜか。 それが本当に二段階だからです。この二つを「設定すれば全部使える」と言い切るサービスは、第二段階を隠しているか、アカウントのプラン帯が足りない場合を考慮していないかのどちらかです。

第二章 クォータ論：ローリングウィンドウが体感を決める

2.1 二段のウィンドウ

サブスクリプション枠の計量方式は、多くの人の直感とは違います。月次のプールではありません——「今月は N 回、使い切ったら終わり」ではないのです。主流の実装はローリングウィンドウ、しかも通常は二段構えです。

• 短いウィンドウ、数時間の規模。「いま続けて作業できるか」を決めます。小さいので当たるのは高頻度の出来事で、大規模なリファクタリングやエージェントの長時間実行では特にそうです。
• 長いウィンドウ、数日の規模。「今週の総量」を決めます。当たる頻度は低いものの、一度当たると回復も長引きます。

「ローリング」とは、ウィンドウの境界が特定の正時に固定されず、いまこの瞬間から遡って測られるという意味です。したがって「零時まで待てばリセット」は存在せず、あるのは「最も古い消費がウィンドウから滑り出て、少しずつ枠が戻ってくる」だけです。

2.2 ウィンドウはアカウント単位で数えられる

本章で最も重要な一文であり、以降の結論の土台です。

二つのウィンドウはどちらもアカウント単位で数えられます。人単位でも、端末単位でも、IP 単位でもありません。

サーバーから見れば、ひとつのアカウントはひとつのクォータ主体です。その背後に一人いるのか十人いるのかは、知りませんし、知る必要もありません。

2.3 共有時に生じる行列効果

2.1 と 2.2 を重ねると、共有アカウント方式の構造的な問題が浮かび上がります。

ひとつのアカウントに 5 人がぶら下がっているとします。各人の日常的な使用量はさほど多くなく、見た目には十分に余裕があります。ところがローリングウィンドウは瞬間的な同時実行に極めて敏感です。うち一人が大規模なリファクタリングを開始し、短いウィンドウが二十分で 90% まで引き上げられると、残る 4 人は何の前触れもなく一斉に壁にぶつかります。しかも誰が原因かも、あとどれだけ残っているかも見えず、いつ回復するかも判断できません。回復は最も古い消費がいつ滑り出るかに依存し、その消費は彼らのものではないからです。

これは「スケジューリングの作り込みが足りない」で解決する問題ではなく、クォータ主体の粒度が決めていることです。クォータがアカウント単位で数えられ、そのアカウントが共有される限り、この結合は必ず存在します。

2.4 429 の読み方：すべての「レート制限」が同じ意味ではない

壁にぶつかったとき返ってくるのは、たいてい HTTP 429 です。しかし 429 は層によって意味がまったく異なり、区別できないと誤った対処をします。

誤読されやすいのは二つ目です。多くのクライアントの既定戦略は「バックオフして再試行」ですが、ウィンドウクォータの場面ではリトライは無効なばかりか、回復を後ろにずらします——失敗した各リクエストも集計に入りうるからです。

判定基準は単純で、応答に明確なリセット時刻が示されているかを見ます。示されていればクォータなので素直に待つ。示されておらず間隔が短ければレート制限なので、バックオフして再試行してよい。

だからこそ「残枠とリセットまでのカウントダウンが見える」ことは飾りの機能ではなく、トラブルシュートに必要な情報です。見えなければ、壁にぶつかったときにできるのは当て推量だけです。

2.5 ウィンドウモデルでは「均等配分」が成立しない理由

自然に浮かぶ考えがあります。中間層でクォータを配分し、各人を 1/5 に制限すればよいのでは、と。

ローリングウィンドウのモデルでは、この案には避けられない問題が二つあります。

第一に、正確に配れません。 中間層が数えられるのは自分が転送したリクエスト数ですが、サーバー側のウィンドウの数え方（どう重み付けし、どう換算し、境界がどう滑るか）はサーバーの実装詳細であり、外部に約束されていません。自分の尺度で配った線と、向こうが自分の尺度で数えた線は必ずずれます——ずれた部分が「こちらはまだ十分残っているのに、向こうはもう 429」です。

第二に、正確に配れたとしても割に合いません。 仮に厳密に五等分できたなら、各人が得るのはアカウント枠の 1/5 です。利用者が実際に買ったものは「ひとつのサブスクリプション」ではなく「サブスクリプションの五分の一」——それならそう言ったほうがましです。

したがって共有方式の正当な位置づけはこうです。使用量が多くなく、時折の待ちを許容でき、低い敷居と低い初期費用を重視する。 これは十分に真っ当な位置づけであり、ただ「安定して予測できる」とは別のことだ、というだけです。

第三章 同一性：怖いのは使われることではなく「別人に見えること」

3.1 サーバー側から観測できるもの

先に断っておきます。本節は対抗手段を一切論じません。中立的な事実をひとつ述べるだけです——サーバーが認証時に観測できる信号は、「認証情報を持ってきたかどうか」だけではありません。

成熟したオンラインサービスであれば、セッションの更新、機微な操作、異常検知といった場面で、一組の文脈信号を参照します。おおよそ三層に分かれます。

これらをサーバーがどう重み付けし、閾値をどこに置いているかは、誰も公開していませんし、知っていると称すべきでもありません。「この通りにやれば絶対に安全」という規則表を掲げる者は、その一点をもって信頼できないと判断してよいでしょう。

3.2 一貫性は「より良いもの」に勝る

一方で、システム設計の原理から導ける経験則がひとつあり、これは相当に頑健です。

異常検知にとっては、「急変」のほうが特定の値そのものより注目に値します。

異常検知は本質的に「正常とはどういう姿か」をモデル化し、そこからの逸脱を探します。あるアカウントが長期にわたって安定した文脈の中で活動していれば、その文脈自体がベースラインになります。ベースラインが安定しているほど、以後の各アクセスの説明コストは下がります。逆に、今日はここ、明日はあそこというアカウントは、たとえ個々の「あそこ」が単体では正常に見えても、変化そのものが説明を要するものになります。

ここから、本稿で最も直感に反し、かつ最も重要な工学的結論が出ます。

安定は、「より良い」に勝る。

「もっと速く綺麗なネットワーク出口に替えれば、アカウントはより安全になるはずだ」というのが直感でしょう。しかし異常検知の視点では、あなたがやったことは不連続を一度作り出したことです。その不連続の代償は、得られた品質向上を上回りかねません。

3.3 環境固定が怠慢ではなく制約である理由

これが、管理型サービスにあるあの保守的に見える規則——一度割り当てた実行環境は変えない——の説明になります。

門外漢はこれを「事業者が楽をしている」と読みがちです。実際にはこれはコストを払って買った制約です。「どの経路が優れているかに応じて動的にスケジューリングする」という、はるかに先進的に聞こえるやり方を放棄し、各アカウントのベースラインが長期にわたり動かないことと引き換えにしています。

その判断根拠が §3.2 です。アカウントの可用性は、文脈の品質よりも文脈の安定性にはるかに敏感である。 品質の上限を少し譲って、ベースラインが揺れないことを買う——割に合う取引です。

同じ論理が別の設計も説明します。アカウントを替えても環境は替えない。 アカウントと実行環境は二層であり、アカウントの交換が必要なときは、その層だけを動かします。両方を同時に動かせば、「新しいアカウント」を「新しい文脈」にそのまま置くことになり、変数が二つ同時に動く最悪の組み合わせになるからです。

3.4 はっきり言っておくべき境界

ここで一言挟まねばなりません。この領域で最もよくある誤導だからです。

いかなる第三者も、アカウントが「ずっと使える」ことを保証できません。

アカウントが使えるかどうかを最終的に判断するのは公式であって、いかなる仲介者でもありません。事業者に——管理型サービスを含めて——できるのは二つだけです。

1. 不要なリスクを増やさない：無意味な不連続を作らず、明らかに異常な操作パターンを取らない。
2. 状態をありのまま伝える：問題が起きたら即座に明示して通知する。エラー画面の前で自分のせいかどうかを推測させない。

「アカウントを守ります」「BAN されません」「BAN されたら補償します」といった約束は、考えが足りていないか、できないと知りつつ言っているかのどちらかです。事業者の専門性は、約束の見栄えよりも、この境界を明文で書く覚悟があるかで測るほうが有用です。

第四章 マルチテナント分離：共有方式の限界はどこか

第二章ではクォータの結合を扱いましたが、それは三つある分離課題のひとつにすぎません。ひとつのアカウントを共有するには、三種類の分離を同時に解く必要があります。

4.1 セッション分離

問題：同一アカウント下の対話は自然にひとまとめになります。A が一覧を開いたときに B のセッションが見えてはいけません。通常の解：中間層に「対話の帰属」表を持ち、利用者ごとに一覧をフィルタします。

限界：フィルタは表示層のものであって、保存層のものではありません。対話自体は同じアカウント名義の下にあり、アカウント単位のあらゆる操作（停止、公式による整理）は全員に等しく及びます。

そしてこの帰属表に課される工学的要件は、見た目よりはるかに厳しく、共有設計の複雑さがどこに潜んでいるかを示す最良の例です。

要件一、クリティカルパス上の読み取りです。 一覧を開くたびに参照するため、遅延がそのまま体感になります。当然、インメモリキャッシュを速い経路に置きたくなります。

要件二、絶対に失ってはいけません。 ここで要件一と衝突します。キャッシュは揮発性だからです。この一部しかなければ、プロセス再起動、キャッシュの追い出し、インスタンス移行のいずれかが起きた時点で、全利用者の対話一覧が同時に空になります。しかもこの障害には厄介な性質があります——障害に見えないのです。利用者に見えるのは空の一覧であり、最初に思うのは「自分のデータが消えた」であって「サービスが壊れた」ではありません。

要件三、再構築できなければなりません。 前二つを合わせると解はひとつしかありません。二重書き込みとコールドスタート時の再投入です。永続ストレージを真の出所とし、キャッシュを速い経路とし、プロセスの起動時に真の出所からキャッシュを埋め直します。

ここははっきり書いておく価値があります。共有方式が安く見えるのは、コストがサブスクリプション費用から工学的複雑さへ移っているからです。 そのコストは消えず、支払う場所が変わっただけであり、どこかの工程が甘ければ、その代償を負うのは利用者です。

要件四、ソートキーの落とし穴。 非常に具体的で、特に踏まれやすい細部です。この種の表は「最終アクティブ」で並べる必要がありますが、時刻フィールドがタイムゾーン解釈をまたいだ瞬間に問題が起きます。書き込み側と読み取り側でタイムゾーンの理解が食い違えば、同じ瞬間が異なる値に換算され、並び順が崩れます。

安全なやり方は、ソートキーを生の整数タイムスタンプで保持することです。タイムゾーンの意味を持つ日時型は使わず、人が読む用は別列に持ちます。整数はいかなるタイムゾーン換算にも関与せず、構造的にこの問題を免れます。

4.2 クォータ分離

第二章で決着済みです。できません。 クォータ主体はアカウントであり、粒度はそこにあります。中間層にできるのは自分の側で絞ることだけで、それはサーバーの実際のウィンドウとは重ならない別の曲線です。

4.3 障害分離

問題：アカウントに問題が起きたとき、影響範囲はぶら下がっている全員です。

限界：これは共有という語の定義が決めていることで、技術的に迂回する手段はありません。ひとつのアカウントの事故は、一群の人々の事故です。

4.4 三つを同時に満たせるか

満たせません。理由は明快です。

セッション分離は中間層で「装う」ことができますが、クォータ分離と障害分離はクォータ主体を分割しなければ本当には解けません。

そして「クォータ主体を分割する」を平たく言えば、ひとつのアカウントをひとりで使うということです。

これがアカウント管理という路線の存在理由のすべてです。共有方式より「高級」なのではなく、問題を本当に解ける唯一の層へ移しただけであり、その代償として全員が自分のサブスクリプションを持つ必要があり、コスト構造がまるごと変わります。

第五章 ストリーミング：中継層で最も難しい部分

ここまでは「アカウント」という静的な資産の話でした。本章は視点を変え、一回のリクエストが経路上で何を経験するかを見ます。AI 系サービスには通常の API とは決定的に異なる性質があります——応答がストリーミングで、一度のやり取りが数十秒続きうること。これが本来問題にならないはずの多くを難題に変えます。

5.1 「受け切ってから転送」ができない理由

最も横着な実装は、上流の応答をメモリに読み切ってから一度に送り出すものです。通常の API なら問題ありませんが、ストリーミングでは災厄になります。最初の一文字までの遅延が、数百ミリ秒から生成時間全体へ跳ね上がります——利用者は動かないカーソルを三十秒眺めることになり、体感としてはフリーズと区別がつきません。

したがって中継層は受けながら転送するしかなく、それは生成の全期間にわたり二本の生きた接続を保持することを意味します。以降のすべての面倒はここから来ます。

5.2 四種類の切れ方が、外からは同じに見える

経路上のどの区間も切れうります。クライアントの回線が揺れた、中継層のインスタンスが再起動した、跨ぐ区間がタイムアウトした、上流自身がエラーになった。問題は、この四つがクライアントからはまったく同じに見えることです——ストリームが止まり、区別できる情報は何もありません。

その結果、現象からリトライすべきかを判断できません。実用的な緩和策は、中継層が切断時に構造化された終了イベントを補うことです。どの区間で切れたか、上流が意図的に終えたのか、エラーコードはあるか——知っている情報を外に出します。完璧にはなりません（切れたのが中継層自身なら、そのイベントも出せません）が、大半の場合は覆えます。

ここに実用的な品質判定があります。ストリームが死んだとき、何か教えてくれるかを見る。 黙って終わる実装は、自分でも追跡していないということです。

5.3 リトライは冪等ではない

通常の API のリトライはたいてい安全です——失敗したなら課金もされていないので、送り直せばよい。しかしストリーミングでは、中断した瞬間に上流はすでに大半を生成しており、枠は実際に消費済みであることがあります。したがってリトライには実コストが伴います。二重消費（利用者視点では一度しか成功していないのに、実際は二回消費）、繋ぎ直せない（生成には確率性があり、二回目は一回目の続きにならない）、帳簿が不透明（中継層が黙ってリトライすれば、利用者には「枠が理由もなく減る」としか見えません）。

最初の一文字が分水嶺です。

つまり責任ある実装は、最初の一文字より前なら黙ってリトライし、その後は正直に切断を報告するものです。切断を「成功したように」包むのは、短期的には苦情を減らし、長期的には利用者の枠を自分の見栄えのために使うことです。

5.4 タイムアウト設定のジレンマ

短く設定すれば、長考タスクが途中で切られます。それはまさにエージェント型プログラミングの主戦場で、大規模なリファクタリングが数分走るのは普通のことです。長く設定すれば、固まった上流が期限まで資源を占有し続けます。

「総タイムアウト」より適しているのはアイドルタイムアウトです。総時間は見ず、直近のデータ塊から何秒経ったかだけを見ます。吐き続けている限り打ち切らず、閾値を超えて何も来なければ固まったと判定します。この発想はローリングウィンドウと同根です——どちらも「絶対量」を「直近の活動からの相対」に置き換えており、後者こそが健全性を正しく表すからです。

5.5 バックプレッシャー：見落とされがちな一点

中継層が上流から受け取る速度と、クライアントへ送り出す速度は必ずしも一致しません。クライアントの消費が遅い（回線が悪い、あるいは単に固まった端末）にもかかわらず中継層が全速で引き続ければ、間のバッファは膨らみ続けます。一本の接続では気づかず、数百・数千の同時接続が揃って膨らめばメモリを食い尽くします。

正しい振る舞いは、下流の消費速度が上流の読み取り速度に反圧をかけることです。クライアントが受け切れないなら、上流からの読み取りを止める。現代のストリーミングフレームワークの多くはこの機構を内蔵していますが、手書きの転送ロジックでは極めて頻繁に抜け落ち、しかも高い同時実行下でしか露見しないため、テスト環境では検出できないことがほとんどです。

本章を一行にまとめれば、ストリーミングは「転送」をステートレスな行為からステートフルな行為に変えた、ということです。一区間増えるごとに、切れうる箇所がひとつ、管理すべきバッファがひとつ、下すべきリトライ判断がひとつ増えます。経路が短いほど体感が安定しがちなのは、短いことが高級だからではなく、壊れうる箇所が少ないからです。

第六章 引き継ぎと復元：管理クライアントがあなたの端末で何をするか

6.1 問題の定義

管理下のアカウントは、あなた自身の端末で公式クライアントを動かす必要があり、それらのクライアントは身元情報をローカルの設定ファイルに保持しています。そこで問題になるのが、あなたにはすでに自分のログイン状態があるということです。

設計のない実装はそれを上書きします。結果として管理期間中は自分のアカウントが使えず、終わったあとは自分でログインし直すことになり、しかも元々何を設定していたか覚えていない公算が大きい。多くの方式では、この体験上の代償が黙って利用者に転嫁されています。

6.2 バックアップ・上書き・復元

責任ある実装は、これを厳密に対称な三段構えにします。

引き継ぎ前   現状をそのまま一部保存する
     ↓
稼働中       管理側の設定が有効。あなたのものは影響を受けない
     ↓
撤収時       保存したものを戻し、管理側の痕跡も一緒に取り去る

言うのは簡単ですが、正しく作るにはいくつかの非自明な細部があります。

6.3 置換ではなくマージする

設定を書くときは置換ではなくマージすべきです。 設定ファイルには身元情報のほかに、利用者自身の設定——好み、履歴、プロジェクト単位の設定——が入っています。まるごと置換すればそれらは消えます。

正しいやり方は、管理に本当に必要な数個のキーだけを書き、残りはバイト単位でそのまま残すことです。撤回時もその数個だけを外します。もともとそれらのキーを含まない設定ファイルは、引き継ぎと復元を一巡してもまったく同一であるべきです。

だからこそ、この種の方式を説明するとき「あなたの設定は変更しません」は嘘であり、「管理に必要な数項目だけを書き、残りはそのまま残します」が真です。前者は利用者が信じません（変えないわけがないと知っているからです）。後者は検証に耐えます。

6.4 冪等性と「最初のバックアップが正」

最もバグが出やすい箇所です。バックアップは冪等でなければならず、しかも最初の一部が正です。 次の順序を考えてください。

1. 引き継ぎ、あなたの元の設定をバックアップ —— この時点でバックアップ = あなたの原本 ✓
2. 管理下で稼働、設定は管理状態に書き換わる
3. 何らかの理由（再接続、切り替え、クライアント再起動）で再び引き継ぎが走る
4. ここで無条件にもう一度保存すると —— バックアップ = 管理状態の設定 ✗
5. 撤収して復元 —— 管理状態が戻され、あなたの原本は永久に失われる

したがって規則は、すでにバックアップがあれば決して上書きしないでなければなりません。最初の一部だけが本物の原本で、以後はすべて汚れたデータです。

見落とされやすい境界がもうひとつ。「もともとこのファイルが無かった」も状態のひとつであり、記録されなければなりません。さもないと復元時に「中身を戻す」と「こちらが作ったものを消す」を区別できず、区別しない実装は、利用者が一度も持ったことのないファイルを残していきます。

6.5 クラッシュ安全性：途中で電源が落ちたら

ここまではすべて手順が完走する前提でした。しかし現実にはプロセスは kill され、マシンはスリープし、ディスクは埋まります。ですから問うべきです——どの段階で中断しても、システムはどんな状態にあるか。

① 利用者の元の設定を読む
② バックアップファイルを書く      ← ここで死ぬ：バックアップが不完全かもしれない
③ 管理側の設定を書く              ← ここで死ぬ：バックアップは無事、設定が中途半端
④ ……稼働……
⑤ バックアップから復元            ← ここで死ぬ：設定が中途半端かもしれない
⑥ バックアップを削除（必要なら）  ← ここで死ぬ：設定は復元済み、ファイルが残るだけ

危険なのは ② ③ ⑤ です——「半分書けた」設定ファイルは、クライアントにとって破損だからです。

定石は一時ファイルに書いてから原子的にリネームすることです。ファイルシステムはリネームの原子性を保証します。見えるのは古いファイルか、完全な新しいファイルかのどちらかで、中間はありません。設定書き込みではほぼ普遍的な解であり、コストは極めて低く、やらなければ低確率で利用者の設定を壊します——再現コストが非常に高く、たいてい本番で事故が起きてから発見される種類のバグです。

⑥ の残骸はむしろ安全です。バックアップファイルが一つ余分にあっても何も壊れず、「すでにあれば上書きしない」規則が次回も守ってくれます。この種の設計では、失うくらいなら残すほうがよい——優れた判断基準です。

6.6 撤収時の対称性

撤回は引き継ぎと同じだけ網羅的でなければなりません。 引き継ぎで三箇所（コマンドライン設定、エディタ拡張、デスクトップクライアントの参照先）に触れたなら、撤回でも三箇所すべてを戻す必要があります。一箇所取り残した結果はたいていエラーではなく、静かな劣化です——エディタの設定が削除済みの実行ファイルを指したまま、拡張は見つけられずに内蔵版へこっそり戻り、利用者は引き継ぎが効かなくなったことにまったく気づかず、ただ「最近どうも変だ」と感じるだけです。

静かな失敗は、エラーより十倍調べにくいものです。この種のクライアント工学で最も投資に値する部分です。

第七章 可観測性：何が見えることを要求すべきか

7.1 素朴な判定基準

管理型サービスは本質的に、あなたに代わって資産を保有し、あなたに代わって運用するものであり、情報の非対称は構造的に生じます。ですから託すに足るかを見る最も有効な単一指標は、技術的な宣伝文句ではなく、こうです。

本来あなたには見えないものを、どれだけ自発的に見せるか。

状態を公開することにはコストがあります——いったん開示すれば、問題が起きたときに曖昧に済ませられなくなります。そのコストを払う気のある事業者は、たいてい本当に耐えられる事業者です。

7.2 具体的に見えるべきもの

おおよその優先順位で。

加点項目が二つ。逆向きの判定基準としても有効です。

• 測定結果をありのまま出しているか。 常に「すべて正常」と表示するパネルは、たいてい実際には測っていません。「未点検」や「点検失敗」を表示する覚悟のあるパネルのほうが、常時グリーンより信頼できます。
• 自分で点検を起動できるか。 受動的に通知を待つのと能動的に検証するのは別の体験であり、掌握感が生まれるのは後者だけです。

7.3 ひとつのアンチパターン

警戒すべき設計がひとつ。結論だけを与え、根拠を与えないものです。

パネルに「回線は健全」と出ているが、それがいつ、何に基づいて出た結論なのかは分からない。この設計の問題は、あなたの実体験と結論が食い違ったときに現れます——自分の側の問題なのか、向こうの問題なのか、判断のしようがありません。

良いやり方は、結論・時刻・出所を揃えて出すことです。**「これは 10 分前にあなた自身が起動した点検の結果です」**のほうが、ぽつんと置かれた「健全」よりはるかに役に立ちます。

第八章 デバイス紐付け：なぜ認証情報は「この端末」に発行されるのか

8.1 一度のログイン、複数の端末

もっともな疑問です。アカウントが自分のものなら、何台で使おうと関係ないのでは？

技術的には、一部の認証情報をあちこちにコピーする作り方も可能です。ただ、より成熟したやり方は端末ごとの発行です。各端末が一度ずつ認可を通し、その端末に属する認証情報を受け取ります。

この一手間で得られるものが三つ。

1. 可視性：どの端末が使われ、それぞれ最後にいつ動いたかが見えます。
2. 失効可能性：使わなくなった端末や、見覚えのない端末を、他に影響を与えずに単独で失効できます。
3. 爆発半径の縮小：ある端末の認証情報が漏れても、影響範囲はその一台です。

8.2 失効が一級市民でなければならない理由

強調したいのは 2 点目です。多くの方式で「失効」は後付けの機能であり、作りも雑になりがちです。しかしセキュリティモデルから見れば、発行と失効は対称な一対でなければなりません——発行しかできないシステムは、時間の経過とともに、自分でも把握していない有効な認証情報の山を必ず作ります。

利用者にとっては、「自分で端末を失効できるか」を見るほうが、宣伝文にセキュリティ用語が何語含まれるかを数えるよりずっと有効です。

第九章 選定：一枚の判断表

前八章の結論を、実行可能な形に圧縮します。

9.1 入場コストだけでなく、退出コストも数える

選定の議論でほぼ誰も持ち出さない観点があります。うまくいかなかったとき、乗り換えるのにどれだけ払うことになるか。

これは商務の問題ではなく技術の問題です。退出コストは結合点の数と深さでほぼ決まります。

三点、注意する価値があります。

API キーの退出コストの低さは、著しく過小評価されています。 公式 API の形は高度に収斂しており、多くのクライアントがベース URL の変更に対応します。今日 A 社、明日 B 社への移行コストはほぼゼロ。囲い込みがほとんど無いという、実に確かな長所です。

管理型の退出コストを判断する鍵は、第六章のあの復元ロジックです。 きれいに復元できる実装なら、退出時はアンインストール一回で端末が元に戻ります。復元が雑な実装なら、変更された箇所を自分でひとつずつ探すことになり、しかもどこが変えられたのかを知りません。ですから第六章の細々とした約束事（最初のバックアップが正、置換ではなくマージ、撤回は対称に）が決めているのは「使い心地」ではなく、いつでも去れる自由があるかどうかです。

代理購入したアカウントは最も深く結合します。 肝心な問いはひとつだけ。更新をやめたら、このアカウントはまだ自分のものか。 事業者によって答えは大きく異なり、問題が起きてから訊くのでは遅すぎます。逆に、持ち込みアカウントは管理形態のうち最も浅い結合です。アカウントは終始あなたのもので、管理されるのはそれを動かす環境だけです。

9.2 この二つは二者択一ではない

従量とサブスクリプションは併存できますし、成熟したチームの多くは実際にそうしています。対話的な開発はサブスクリプションのアカウントで（UI と連続性が要る）、CI とバッチ処理は API キーで（ステートレスと並行性が要る）。両者の技術特性はちょうど補い合うので、無理に一方を選ぶほうが面倒を招きます。

第十章 九つの誤解、一枚の表で

おわりに

冒頭の五つの問いに戻ります。いまなら答えが出るはずです。

• API のクレジットを買ったのにウェブ版がログインを求める —— 二つの並行した認証経路であり、鍵からは身元を作れません。
• 昨日は快調で今日は回り続ける —— おそらくローリングウィンドウであり、アカウントが共有なら、消費した人はあなたとは限りません。
• なぜ「より良い」ではなく「固定」を強調するのか —— 異常検知は正常の姿をモデル化するので、不連続そのものが説明を要するからです。
• 「環境を変えない」は保守的すぎないか —— 意図して払ったコストであって、怠慢ではありません。
• 長いタスクが途中で切れたときリトライがなぜ損か —— 最初の一文字より後では枠が消費済みで、リトライは二重請求になり、しかも繋ぎ直せません。

もう一段抽象化すると、本稿が本当に言いたいのは素朴な一文です。

この領域では、制約をはっきり述べる者のほうが、約束を美しく述べる者より信頼に値する。

制約は検証可能だからです——自分で当たりに行って、言われた通りかを確かめられます。約束はたいてい検証できない場所に置かれ、検証できるようになった頃には、たいてい既に支払い済みです。

次に選定をするとき、「枠はどう数えるのか」「ストリームが切れたらどう扱うのか」「抜けるとき端末はきれいに戻るのか」——この二言三言を余分に訊くようになれば、本稿の目的は達せられます。

本稿は公開されている観測可能な機構と一般的な工学的トレードオフのみを論じ、サーバー側の規則の詳細を含まず、いかなる対抗手段も提供しません。クォータウィンドウや認証経路に関する記述は、利用者の視点からの振る舞いの一般化であり、いかなる事業者の内部実装を表すものでもありません。