公開日: 最終更新:
執筆・編集：株式会社Nexa 編集部（下書きと機械検査はAI、公開前に人が確認）／約16分で読めます。公式ドキュメント・公式発表などの一次情報を確認したうえで執筆・更新しています。AIツールの仕様や料金は変わることがあるため、導入判断の前に各公式サイトの最新情報もご確認ください。記事の作り方と検査の方針
Tweet ComposerとClaude Codeを組み合わせることで、XのマルチアカウントをTOKEN_FILE切り替えで安全に管理できます。
- 要点1: accounts.json + tokens/フォルダの構成でアカウントとトークンを分離管理
- 要点2:
x_api.TOKEN_FILEのランタイム上書きにより、コードを変更せずにアカウントを切り替えられる - 要点3: テストアカウントで確認してから本番投稿する安全なワークフローを構築可能
対象: Claude CodeでXのSNS運用を自動化したい企業担当者・個人事業主
今日やること: X_CLIENT_IDをKeychainに登録し、最初のアカウントをTweet Composerに追加する
複数のXアカウントを運用していると、「テスト投稿してから本番アカウントに切り替えたい」「本番と検証用を安全に分けたい」という場面が必ず出てきます。
Claude Codeで構築したTweet ComposerにTOKEN_FILE切り替え機能を組み込むことで、Xアカウントの切り替えをワンクリックで完結させることができます。
この記事では、実際にこの仕組みを構築した際の手順と、遭遇したトラブル・解決策を公開します。特定のサービス名は伏せていますが、複数アカウントを実務で使い分けているSNS担当者の方にそのまま応用できる内容です。
※本記事のX API仕様（トークンの有効期限・アプリ種別・自動化ポリシー）はX API公式ドキュメントで2026年10月7日に確認しています。
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/
│ ├── main_account.json # 本番アカウントのトークン
│ └── shukatsu.json # テストアカウントのトークン
├── x_api_bridge.py # アカウント切り替えロジック
└── server.py # APIエンドポイントaccounts.json の内容は次のようなシンプルな構成です。
{ "main_account": "tokens/main_account.json", "shukatsu_test": "tokens/shukatsu.json"}アカウント名（"main_account"）とそのトークンファイルのパスを対応させているだけです。セキュリティ上、accounts.json と tokens/ フォルダは .gitignore に追加し、リポジトリには含めないようにします。
TOKEN_FILE切り替えのメカニズム
X APIを呼び出す x_api.py には、TOKEN_FILE というモジュールレベルの変数があります。この変数にトークンファイルのパスを指定することで、どのアカウントとして動作するかが決まります。
重要なのは、x_api.py 自体は変更不要という点です。実行時に別のファイルから上書きするだけで切り替えができます。
# x_api_bridge.py
import x_api
def 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_idX 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のフローが始まります。
- ブラウザが開き、Xのアプリ認証画面が表示される
- 追加したいアカウントでXにログインして「認証」ボタンをクリック
http://127.0.0.1:3891/callbackにリダイレクトされ、認証コードが渡される- 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": "main_account"}'AI導入に関するお困りごとは、株式会社NexaのAI顧問がサポートします。「何から始めればいいか分からない」という段階からご相談いただけます。
テスト→本番の安全な投稿ワークフロー
マルチアカウント機能を実装する最大の目的は、「テストアカウントで確認してから本番に投稿する」安全なワークフローの実現です。
なぜテストアカウントが必要なのか
Claude Codeを使ったSNS自動化では、生成したテキストをそのまま投稿することになります。このとき、以下のリスクが存在します。
- 文字数オーバー: X（Twitter）の文字制限（280文字）を超えた場合、投稿に失敗する
- 改行・フォーマットのズレ: 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": "main_account"}'
# 本番投稿
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_idKeychainからのアクセスが失敗する場合（リモート接続でのアクセス制限など）は、ファイルフォールバックが有効です。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の自動化に関するルール（2026年10月7日確認）で認められています。「1アカウント = 1アプリ」ではなく「1アプリ = 多アカウントに対してOAuth認証」という設計です。
ただし同ルールでは、1つのアカウント内または複数アカウントをまたいで重複・実質的に同一の内容を投稿することを禁止しています。各アカウントの投稿内容が目的別に異なることを前提に運用してください。スパム的な自動投稿や過度な同時実行はレートリミットやアカウント凍結の対象になる場合もあるため、人間が確認・管理するワークフローの中でAPIを活用することが大前提です。
Q. アクセストークンの管理はどう行えばいいですか？
今回の実装では、tokens/ フォルダに各アカウントのトークンファイルを格納します。このフォルダは .gitignore に追加してGitリポジトリには含めないようにしてください。
X APIのOAuth 2.0では、offline.access スコープを付与するとリフレッシュトークンが発行されます。X API公式ドキュメント（2026年10月7日確認）によると、アクセストークンの有効期限は2時間、リフレッシュトークンは使うたびに新しいトークンへ置き換わる一回限り（ローテーション）の仕様です。固定の有効期間は公式ドキュメントに明記されていないため、アプリ側でリフレッシュ処理を実装し、失効時は再認証する運用にしておくと安全です。
また、トークンファイルのパーミッションは 600（オーナーのみ読み書き可）に設定しておくと安全です。
chmod 600 tokens/*.jsonQ. 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が不要になり、ローカルアプリでの認証がより安全になります）。
Q. Client Secretは必ず必要ですか？
いいえ。X API公式ドキュメント（2026年10月7日確認）では、Native App・Single page App は「Public client（公開クライアント）」に分類され、Client Secretを保持せずPKCEで認証できます。一方、Web AppやBot（自動化アプリ）は「Confidential client」に分類され、Client Secretでの認証が必要です。Tweet ComposerのようにローカルPCやサーバー上で動かすツールは、Native Appとして登録すればClient Secretの管理が不要になります。
Q. 1投稿あたりの文字数制限は何文字ですか？
X API公式ドキュメント（2026年10月7日確認）では、投稿の文字数上限は280文字です。ただし文字の数え方には注意が必要で、半角英数字などは1文字として数えますが、絵文字や日本語・中国語・韓国語などのCJK文字は2文字分として数えられます。日本語中心のツイートでは実質140字前後が上限になるため、テストアカウントで文字数オーバーを確認する工程（本記事のテスト→本番ワークフロー）が特に重要です。
＼ AI活用の「次の一手」を一緒に考えませんか ／
AI顧問の無料相談はこちらまとめ
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上でアカウントを追加し、ドロップダウンで切り替えるだけで複数アカウントの管理ができます。
法人向けAI導入・活用の月額伴走サービス
AI導入の疑問を、週1回のMTGで相談できる「AI顧問」
株式会社Nexaでは、ChatGPT・Claude・Claude CodeなどのAI導入に関する質問や、社内活用・業務自動化の進め方を週1回相談できる 月額7万円（毎月3社限定で月額5万円）のAI顧問サービス を提供しています。
「自社では何から始めるべきか」「この業務はAI化できるか」「どのツールを選ぶべきか」を、無料相談で整理します。
AI導入を検討中の方へ
