Tweet Composerで複数Xアカウントを切り替えて投稿する方法｜TOKEN_FILE活用術

複数のXアカウントを運用していると、「テスト投稿してから本番アカウントに切り替えたい」「本番と検証用を安全に分けたい」という場面が必ず出てきます。

Claude Codeで構築したTweet ComposerにTOKEN_FILE切り替え機能を組み込むことで、Xアカウントの切り替えをワンクリックで完結させることができます。

この記事では、実際にこの仕組みを構築した際の手順と、遭遇したトラブル・解決策を公開します。特定のサービス名は伏せていますが、複数アカウントを実務で使い分けているSNS担当者の方にそのまま応用できる内容です。

Xの複数アカウント管理に困っていませんか？

企業のSNS担当者がXを運用する場面では、複数のアカウントを同時に管理するケースが珍しくありません。手動での切り替えは一見シンプルに見えますが、運用ミスや作業効率の低下につながりやすいのが現実です。

企業が複数Xアカウントを運用する主な理由

企業がXの複数アカウントを使い分ける理由は、大きく以下の3つに分類されます。

目的	具体例
ブランド別	企業公式アカウント + サービス別アカウント
用途別	告知専用アカウント + コミュニティアカウント
テスト・開発用	本番投稿前に確認するためのテストアカウント

なかでも「テスト用アカウントで内容を確認してから本番投稿する」というワークフローは、誤投稿リスクを下げるうえで特に有効です。自動化ツールを使っている場合はなおさら、テストなしで本番に送ることは避けたいところです。

手動切り替えの3つのリスク

Xのブラウザ上での手動アカウント切り替えには、以下のリスクが伴います。

1. ログイン状態の混在によるミス投稿複数タブでログイン中に投稿先を取り違えるケースがあります。特に自動化スクリプトからの投稿では、切り替え漏れが本番事故につながります。

2. 認証情報のハードコードスクリプトに直接トークンを書いてしまうと、アカウントを切り替えるたびにコード修正が必要になります。GitHubなどに誤ってコミットすれば情報漏洩のリスクもあります。

3. 操作の属人化担当者しか知らない切り替え手順が増えると、引き継ぎが困難になります。システムとして仕組み化する必要があります。

Tweet Composerのマルチアカウント対応の仕組み

Tweet Composerとは、Claude Codeから操作できるXの投稿管理Webツールです。ツイート文の作成・下書き保存・スレッド投稿などを、ブラウザ上のUIから行うことができます。

このツールにマルチアカウント機能を追加する際、核心となるのが「TOKEN_FILE切り替え」という手法です。

accounts.jsonとtokens/ディレクトリの役割

マルチアカウント対応後のフォルダ構成は以下のようになります。

tweet-composer/├── accounts.json          # アカウント名 → トークンファイルパスのマッピング├── tokens/│   ├── dify_base.json     # 本番アカウントのトークン│   └── shukatsu.json      # テストアカウントのトークン├── x_api_bridge.py        # アカウント切り替えロジック└── server.py              # APIエンドポイント

accounts.json の内容は次のようなシンプルな構成です。

{  "dify_base": "tokens/dify_base.json",  "shukatsu_test": "tokens/shukatsu.json"}

アカウント名（"dify_base"）とそのトークンファイルのパスを対応させているだけです。セキュリティ上、accounts.json と tokens/ フォルダは .gitignore に追加し、リポジトリには含めないようにします。

TOKEN_FILE切り替えのメカニズム

X APIを呼び出す x_api.py には、TOKEN_FILE というモジュールレベルの変数があります。この変数にトークンファイルのパスを指定することで、どのアカウントとして動作するかが決まります。

重要なのは、x_api.py 自体は変更不要という点です。実行時に別のファイルから上書きするだけで切り替えができます。

# x_api_bridge.pyimport x_apidef switch_account(account_name: str) -> dict:    """指定したアカウントのTOKEN_FILEに切り替える"""    accounts = _load_accounts()    if account_name not in accounts:        raise ValueError(f"アカウント '{account_name}' が見つかりません")    token_file = accounts[account_name]    # モジュール変数をランタイムで上書き    x_api.TOKEN_FILE = token_file    # 切り替え後のユーザー情報を返す    user_info = x_api.get_user_info()    return {"account": account_name, "user": user_info}

x_api.TOKEN_FILE = token_file というシンプルな1行で、以降のすべてのAPI呼び出しがそのアカウントで実行されます。

server.py には、以下の4つのAPIエンドポイントを追加します。

エンドポイント	メソッド	機能
/api/accounts	GET	アカウント一覧取得
/api/accounts/switch	POST	アカウント切り替え
/api/accounts/add	POST	新規アカウント追加（OAuth認証フロー）
/api/accounts/{name}	DELETE	アカウント削除

フロントエンド（サイドバー）には、現在選択中のアカウントを表示するドロップダウンを設置します。選択肢を変えると POST /api/accounts/switch が呼ばれ、即座に切り替えが完了します。

セットアップ手順 — アカウントを追加して切り替える

実際にマルチアカウント機能を使い始めるまでの手順を解説します。

事前準備（X_CLIENT_IDのKeychain登録）

Tweet ComposerのOAuth認証には、X Developer PortalのClient IDが必要です。これは「どのXアカウントか」ではなく「どのアプリか」を示すIDで、複数アカウントで共通して使えます。

# macOSのKeychainに登録security add-generic-password -a "$USER" -s "X_CLIENT_ID" -w "your-client-id"

Keychainではなくファイルで管理したい場合は、~/.x_x_client_id というファイルにClient IDを書くことでもフォールバックとして機能します。

echo "your-client-id" > ~/.x_x_client_id

X Developer Portalの設定では、User authentication settings の Callback URI に http://127.0.0.1:3891/callback を追加しておく必要があります。この設定が抜けると、後述する認証エラーの原因になります。

アカウントの追加方法（OAuth 2.0 PKCEフロー）

Tweet ComposerのUIから「+ アカウント追加」をクリックすると、OAuth 2.0 PKCEのフローが始まります。

1. ブラウザが開き、Xのアプリ認証画面が表示される
2. 追加したいアカウントでXにログインして「認証」ボタンをクリック
3. http://127.0.0.1:3891/callback にリダイレクトされ、認証コードが渡される
4. Tweet Composerがアクセストークンを取得し、tokens/ フォルダに保存

このフローで重要なのは、Client IDは1つで何度でも別アカウントの認証ができるという点です。認証画面でログインするXアカウントを変えるだけで、そのアカウントのトークンが発行されます。

アカウントの切り替え方法（APIと UI）

追加済みのアカウントへの切り替えは2つの方法で行えます。

UIから切り替え（推奨）:サイドバーのアカウントドロップダウンから選択するだけです。選択するとアカウント情報（@username）が更新され、以降の投稿がそのアカウントで行われます。

Claude Codeから切り替え（自動化向け）:Claude CodeがTweet ComposerのAPIを呼び出すスクリプトの中で、事前にアカウントを切り替えることができます。

# テストアカウントに切り替えてから投稿確認curl -X POST http://localhost:8234/api/accounts/switch \  -H "Content-Type: application/json" \  -d '{"account": "shukatsu_test"}'# 確認後、本番アカウントに切り替えて投稿curl -X POST http://localhost:8234/api/accounts/switch \  -H "Content-Type: application/json" \  -d '{"account": "dify_base"}'

---

Claude Codeを使ったX APIの詳細な設定や、自社のSNS運用フローへの組み込みについて、個別にご相談いただけます。「どのアカウント構成が自分の用途に合うか」「セキュリティの観点でどう設計すべきか」といった段階から対応しています。

Claude Code個別指導の無料相談はこちら →

---

テスト→本番の安全な投稿ワークフロー

マルチアカウント機能を実装する最大の目的は、「テストアカウントで確認してから本番に投稿する」安全なワークフローの実現です。

なぜテストアカウントが必要なのか

Claude Codeを使ったSNS自動化では、生成したテキストをそのまま投稿することになります。このとき、以下のリスクが存在します。

• 文字数オーバー: X（Twitter）の文字制限（140文字）を超えた場合、投稿に失敗する
• 改行・フォーマットのズレ: Markdownで書いた文章がXのUIで意図した表示にならない
• URLの展開: URLを含む場合、展開後の文字数計算が変わることがある
• 画像の添付ミス: 画像付き投稿のアップロードが失敗している場合がある

これらを本番前に確認するためのテストアカウントがあると、誤投稿・失敗投稿のリスクを大幅に下げられます。

実際のワークフロー例

実際の運用では、以下のような手順で投稿を行います。

ステップ1: テキストの生成

Claude Codeがツイート文・スレッド構成を生成します。生成されたテキストは POST /api/compose/thread でTweet Composerに送信します。

ステップ2: テストアカウントで確認投稿

# テストアカウントに切り替えcurl -X POST http://localhost:8234/api/accounts/switch \  -d '{"account": "shukatsu_test"}'# テスト投稿curl -X POST http://localhost:8234/api/post/thread \  -d '{"tweets": ["ツイート1の内容", "ツイート2の内容"]}'

テストアカウントのタイムラインでフォーマット・文字数・画像の表示を確認します。

ステップ3: 本番アカウントで投稿

確認できたら、本番アカウントに切り替えて同じ内容を投稿します。

# 本番アカウントに切り替えcurl -X POST http://localhost:8234/api/accounts/switch \  -d '{"account": "dify_base"}'# 本番投稿curl -X POST http://localhost:8234/api/post/thread \  -d '{"tweets": ["ツイート1の内容", "ツイート2の内容"]}'

このフローにより、同じコード（Tweet Composer）を使いながら、テストと本番を安全に分離できます。

ポイントアカウント切り替えはAPIを通じて行われるため、Claude Codeのスクリプトに直接トークンを記述する必要がありません。セキュリティとメンテナンス性が高い設計です。

よくあるトラブルとその解決策

実際にマルチアカウント機能を実装・利用する中で遭遇したトラブルと、その解決策をまとめます。

X_CLIENT_IDがKeychainに登録されていない場合

症状: アカウント追加時に「X_CLIENT_IDが未登録です」というエラーが表示される。

原因: アプリケーションが起動している環境（別のMacやリモートサーバー）にKeychainの登録がない場合に発生します。

解決策:

# Keychainに登録するsecurity add-generic-password -a "$USER" -s "X_CLIENT_ID" -w "your-client-id"# または、ファイルフォールバックを使うecho "your-client-id" > ~/.x_x_client_id

Keychainからのアクセスが失敗する場合（リモート接続でのアクセス制限など）は、ファイルフォールバックが有効です。x_api.py が ~/.x_x_client_id を自動的に参照します。

OAuthコールバックがfaviconリクエストで消費される問題

症状: アカウント追加時に、OAuth認証画面で「認証」をクリックしてもアカウントが追加されず、error: unknown と表示される。

原因: OAuth 2.0 PKCEのコールバックサーバーが handle_request() 1回だけを受け付ける設計になっている場合、ブラウザが最初に送る favicon.ico のリクエストがコールバックとして消費されてしまいます。

解決策: コールバックサーバーを、code パラメータを受け取るまでループするように修正します。

# x_api_bridge.py に追加した独自の認証フローdef _run_auth_flow(port=3891, timeout=120):    """faviconリクエストを無視して、正しいコールバックだけを処理する"""    server = HTTPServer(('127.0.0.1', port), _CallbackHandler)    server.timeout = 1    start_time = time.time()    while time.time() - start_time < timeout:        server.handle_request()        if _CallbackHandler.received_code:            return _CallbackHandler.received_code    raise TimeoutError("認証がタイムアウトしました")

ポイントは「_CallbackHandler.received_code に値が入るまでループする」という実装です。faviconなどのリクエストは code パラメータを持たないため、ループを継続します。

Mac miniなどリモート環境での認証フロー

症状: リモートからSSH接続したMac miniでTweet Composerを起動してアカウントを追加しようとすると、OAuthコールバックが届かない。

原因: OAuth認証でブラウザが開くのはメインMac側です。しかし、コールバックサーバー（127.0.0.1:3891）はMac mini側で動いています。ブラウザのリダイレクト先はメインMacのlocalhostになるため、Mac miniのコールバックサーバーには到達しません。

解決策: 以下のいずれかで対処します。

方法A: Mac miniのローカル環境で直接操作するリモートではなく、Mac miniに直接ログインした状態でアカウント追加を行います。

方法B: コールバックURLを手動で渡すXの認証画面で「認証」をクリックした後、ブラウザのアドレスバーに表示されるURL（http://127.0.0.1:3891/callback?code=...&state=...）をコピーし、Mac mini側のターミナルで以下を実行します。

curl "http://127.0.0.1:3891/callback?code=[実際のコード]&state=[実際のstate]"

アカウント追加後は切り替えAPIを使うだけなので、認証フローを完了させるのは一度だけで済みます。

よくある質問

Q. X APIで複数アカウントを管理するのはXのポリシー上問題ありませんか？

1つのXアプリ（Client ID）で複数アカウントを管理することは、Xの利用規約上問題ありません。XのAPIは「1アカウント = 1アプリ」ではなく、「1アプリ = 多アカウントに対してOAuth認証」という設計になっています。

ただし、スパム的な自動投稿や過度な同時実行はレートリミットやアカウント凍結の対象になる場合があります。人間が確認・管理するワークフローの中でAPIを活用することが大前提です。

Q. アクセストークンの管理はどう行えばいいですか？

今回の実装では、tokens/ フォルダに各アカウントのトークンファイルを格納します。このフォルダは .gitignore に追加してGitリポジトリには含めないようにしてください。

Xの公式推奨は「90日ごとのトークン再生成」ですが、OAuth 2.0のリフレッシュトークンを実装することで、期限切れを自動検出・更新できます。

また、トークンファイルのパーミッションは 600（オーナーのみ読み書き可）に設定しておくと安全です。

chmod 600 tokens/*.json

Q. OAuth 2.0 PKCEのコールバックURIはどこで設定しますか？

X Developer Portal にログインし、対象のAppの Settings → User authentication settings → Edit を開きます。

Callback URI / Redirect URL の欄に http://127.0.0.1:3891/callback を追加してください。この設定が抜けていると、OAuthの認証後にエラーが返ります。

また、Type of App は Native App を選択することで、PKCEフローが使用できます（Client Secretが不要になり、ローカルアプリでの認証がより安全になります）。

まとめ

Tweet ComposerへのマルチアカウントOAuth 2.0対応を実装するポイントをまとめます。

• 構成の要点: accounts.json でアカウントとトークンファイルをマッピング。x_api.TOKEN_FILE のランタイム上書きで切り替えを実現
• 安全なワークフロー: テストアカウントで確認 → 本番アカウントで投稿の2段階フローでミス投稿を防ぐ
• よくあるハマりポイント: Keychain登録のし忘れ、faviconによるコールバック消費、リモート環境での認証の問題
• セキュリティ: tokens/ フォルダは .gitignore に追加。ファイルパーミッションは 600 に設定

最初のステップは、X Developer PortalのClient IDを security add-generic-password でKeychainに登録することです。その後はTweet ComposerのUI上でアカウントを追加し、ドロップダウンで切り替えるだけで複数アカウントの管理ができます。

---

Claude Codeを活用したSNS運用自動化の個別指導を提供しています

株式会社Nexaでは、Claude Codeを活用したX/SNSの業務自動化について個別指導・企業研修を実施しています。「複数アカウントの安全な運用フロー設計」「X APIとClaude Codeの連携方法」など、担当者の課題に合わせてサポートします。非エンジニアの方でも取り組めるよう、ゼロから丁寧にご支援します。

Claude Code個別指導の詳細・無料相談はこちら →

---