結論: tuitterは「ブラウザを開かずターミナルだけでXを使いたい」開発者向けの最小構成TUIクライアントだ。Bun×TypeScriptで起動が速く、必須環境変数はX_CLIENT_IDの1つだけ。OAuth 2.0でX API v2に接続するため旧Twitterクライアントが直面した認証問題を回避できる。さらに2026年4月のアップデートでtuitter.confによる1日あたりの利用時間制限機能が追加され、Xの可処分時間をシステム的にキャップできるツールとしての性格も帯び始めた。

本記事は「AI自動化ツール完全ガイド2026」クラスタの一部です。tuitterに限らず、データパイプライン・ワークフロー自動化・ターミナル系ツールを横断的に整理した全体像はAI自動化ツール完全ガイド2026｜ノーコードからコードまで徹底比較を参照してください。

GitHub Starsは2026年5月時点で388に到達し、Benjamin Dicken氏（@bddicken）の個人プロジェクトとして注目を集めている。本稿ではインストール手順、X Developer App設定、tuitter.confの活用、OAuth 2.0認証フローの内部挙動、他のターミナルXクライアントとの比較までを実コードベースで解説する。

tuitter screenshot

tuitterとは：ターミナルで動くTypeScript製Xクライアント

tuitterはX（旧Twitter）をターミナルから操作するためのTUI（Terminal User Interface）クライアントだ。実装言語はTypeScript（99.7%）+ Shell（0.3%）、ランタイムにBun、UIフレームワークに同じ著者のOpenTUIを採用している。X API v2に対しOAuth 2.0で接続し、タイムライン閲覧・ツイート投稿・いいね・ブックマークといった主要操作をテキストUI内で完結させる。

TUIはGUIのようにマウスではなくキーボード中心で操作するUI形式で、SSH先のリモートサーバーや軽量端末でも動く点が利点だ。同じ「特定領域に特化したTUI」という発想の事例として、Kubernetesログ集約のkubetail、Vim上のスプレッドシートcell.vimなどがあり、tuitterはそのSNSフィード版と位置付けられる。

主要スペック:

  • 言語: TypeScript（99.7%）+ Shell（0.3%）
  • ランタイム: Bun
  • UIフレームワーク: OpenTUI（同著者作）
  • API: X API v2
  • 認証方式: OAuth 2.0（PKCE + Authorization Code Flow）
  • ライセンス: リポジトリのLICENSEを参照
  • GitHub Stars: 388（2026年5月時点）
  • 作者: Benjamin Dicken（@bddicken）

tuitterの使い方：3コマンドで起動できるBunベース構成

セットアップに必要なコマンドはわずか3行だ。Bunを未インストールなら追加で1行加わるが、依存関係解決が高速なため初期構築のテンポを止めない。

# Bun未導入の場合のみ
curl -fsSL https://bun.sh/install | bash

# tuitter本体
git clone https://github.com/bddicken/tuitter.git
cd tuitter
bun install

bun installはnpm installより数倍高速で、TypeScriptトランスパイルとパッケージ解決を含めても多くの環境で数秒以内に終わる。

次に環境変数ファイルを準備する:

cp .env.example .env

.envの中身は以下の構成で、必須なのは1つだけだ。

# 必須
X_CLIENT_ID=your_client_id_here

# 任意（デフォルトあり）
X_CLIENT_SECRET=your_client_secret_here
X_REDIRECT_URI=http://127.0.0.1:8787/callback
X_OAUTH_SCOPES=tweet.read users.read tweet.write like.write like.read bookmark.write bookmark.read offline.access
X_TOKEN_STORE_PATH=~/.tuitter/oauth-token.json
X_IMAGE_MODE=auto

最小構成ではX_CLIENT_IDのみ設定すれば動く。Confidentialクライアントとして登録しているX Developer Appの場合のみX_CLIENT_SECRETを追加する。

最後にグローバルコマンド化してそのまま起動する:

bun link
tuitter

bun linkによってtuitterコマンドがPATH上に登録され、初回起動時にブラウザが開いてOAuth認証フローが始まる。承認後はトークンがローカル保存され、以降はブラウザを介さず直接起動できるようになる。

X Developer App設定：OAuth 2.0でClient IDを取得する手順

tuitterを動作させるにはX側で「OAuth 2.0対応のDeveloper App」を1つ用意する必要がある。手順は以下の通りで、初めてX APIに触れる場合でも10分程度で完了する。

  1. console.x.com にログインする
  2. 既存ProjectまたはAppを選択するか、新規Project/Appを作成する
  3. App設定画面で OAuth 2.0 を有効化する
  4. Callback URL（Redirect URL） に http://127.0.0.1:8787/callback を追加する
  5. Client ID をコピーして .env の X_CLIENT_ID に貼り付ける
  6. Confidentialクライアント設定の場合は Client Secret も X_CLIENT_SECRET に追加する
  7. （任意）必要に応じてScopesを変更する

OAuthが失敗する場合の典型的な原因は「console.x.comに登録したCallback URL」と「.envのX_REDIRECT_URI」の文字列不一致だ。プロトコル（http/https）、IP表記（127.0.0.1 vs localhost）、末尾スラッシュの有無まで完全に一致させる必要がある。

デフォルトのリクエストスコープは以下の8種類で、読み取り・書き込み・リフレッシュをカバーする。

tweet.read
users.read
tweet.write
like.write
like.read
bookmark.write
bookmark.read
offline.access

読み取り専用で運用するならX_OAUTH_SCOPESを絞り込めば、トークン漏えい時の被害範囲を最小化できる。

# 読み取り専用スコープ例
X_OAUTH_SCOPES=tweet.read users.read like.read bookmark.read offline.access

tuitterのOAuth 2.0認証フロー：初回と2回目以降の挙動

tuitterの認証は標準的なOAuth 2.0 Authorization Code Flow（PKCE併用）だ。初回だけブラウザでユーザー操作を要求し、以降はローカルに保存したRefresh Token経由で再認証なしに動く。offline.accessスコープが含まれているのはこのためで、長期運用での再ログイン手間を抑える設計になっている。

sequenceDiagram participant U as ユーザー participant T as tuitter participant B as ブラウザ participant X as X API U->>T: tuitter コマンド実行 T->>T: ~/.tuitter/oauth-token.json 確認 alt 初回（トークンなし） T->>B: OAuth URL を開く B->>X: 認証リクエスト X->>B: ログイン・権限承認 B->>T: 127.0.0.1:8787/callback へリダイレクト T->>X: Authorization Code で Token交換 T->>T: Access/Refresh Token を保存 else 2回目以降 T->>X: Access Token で API 呼び出し alt Access Token 期限切れ T->>X: Refresh Token で更新 T->>T: 新しい Token を保存 end end T->>U: TUI 画面を描画

ローカルに保存されるのは~/.tuitter/oauth-token.json（パスはX_TOKEN_STORE_PATHで変更可）で、Access TokenとRefresh Tokenを含む。ファイルパーミッションが緩いと他ユーザーが読み取れる可能性があるため、明示的に絞っておくのが安全だ。

chmod 600 ~/.tuitter/oauth-token.json
ls -la ~/.tuitter/oauth-token.json

トークンを破棄してログイン状態をリセットしたい場合は単にこのファイルを削除すればよく、次回起動時に再びブラウザ認証が走る。

tuitter.confで1日あたりの利用時間を制限する

2026年4月以降に追加された機能として注目すべきがtuitter.confによる画面時間制限（screen-time limit）だ。Xの可処分時間をクライアント側でキャップする発想で、SNS依存対策ツールとしての性格が強くなっている。

設定は起動ディレクトリにtuitter.confを置き、秒単位で上限を書くだけだ:

# 1日あたり30分（1800秒）に制限
MAX_SECONDS=1800

利用時間は同ディレクトリの.tuitter状態ファイルに日次で蓄積され、上限に達するとUI上に大きな赤い警告バナーが表示されてその日は使えなくなる。翌日にロールオーバーする仕組みになっている。

具体的な使い方:

  1. tuitter.confにMAX_SECONDS=<秒数>を記述する
  2. そのディレクトリからtuitterを起動する
  3. 上限に達したら自動でブロックされ、翌日以降に再開できる

注意点として、設定ファイルと.tuitter状態ファイルは「起動ディレクトリ」を基準にするため、複数ディレクトリから起動するとそれぞれ独立にカウントされる。意図的に別カウントにしたい場合を除き、起動ディレクトリは固定するのが運用上は素直だ。

# 起動ディレクトリを固定する例（zshの関数化）
tuit() {
  cd ~/.tuitter-runtime && tuitter
}

画像表示モード：Kittyターミナルでインライン画像を表示する

X_IMAGE_MODE環境変数で画像レンダリングを切り替えられる。Kittyターミナル使用時はターミナル内に直接画像を表示でき、SSH越しの低帯域環境では画像描画自体を止められる。

モード 動作 推奨環境
auto 環境を検出して最適な方式を自動選択 デフォルト。多くの環境で動作
kitty Kitty画像プロトコルで描画 Kitty・WezTermなど対応端末
off 画像表示を完全に無効化 SSH・低帯域・テキスト専用端末 
# Kittyを使っている場合
X_IMAGE_MODE=kitty

# SSH先や低帯域でテキストだけ見たい場合
X_IMAGE_MODE=off

画像描画を有効にしたままだと、メディアの多いタイムラインを開いた瞬間にターミナルが重くなることがある。リモート作業中はオフ、ローカル作業中はkittyかautoという切り替えが扱いやすい。

他のターミナルX/Twitterクライアントとの比較

ターミナルからXを操作するツールは過去にも複数存在したが、X API v2のOAuth 2.0時代で生き残っているものは限られる。tuitterの位置付けを横並びで整理する。

ツール 言語 認証 投稿 画像表示 状態 特徴
tuitter TypeScript + Bun OAuth 2.0 (X API v2) ✅ ✅ Kitty対応 アクティブ 公式API、screen-time制限あり
rainbowstream Python OAuth 1.0a ✅ 限定的 旧API依存で停滞 旧Twitter時代の老舗CLI
oysttyer Perl OAuth 1.0a ✅ ❌ メンテ縮小 軽量・テキスト専用
nitter Web自己ホスト 不要 ❌ ✅ 読取のみ サードパーティ閲覧フロントエンド
twurl Ruby OAuth 1.0a ✅ ❌ API検証用途 curl相当のCLIラッパー
tut Go OAuth 2.0 ✅ 限定的 Mastodon専用 Xではなく分散SNS向け

旧来のOAuth 1.0a系クライアントの多くはAPI v2移行とアクセス制限強化で実用に耐えなくなっている。一方tuitterはX API v2 + OAuth 2.0 + Refresh Tokenという現代的な設計を最初から採用しており、その意味では「2026年時点で動くターミナルXクライアント」という枠で見るとほぼ一強状態だ。

なお、SNSの「自動投稿」「スケジューリング」「複数アカウント運用」といった用途にはtuitterは設計上向いていない。これらはエージェント的な実行が必要なので、AIエージェントフレームワーク比較2026年版で扱われるツール群やTypefully API直叩きの方が適している。

OpenTUIフレームワーク：tuitterのUI基盤

tuitterのUIレイヤを担うOpenTUIは、同じ著者であるBenjamin Dicken氏が開発しているTypeScript製ターミナルUIフレームワークだ。tuitterの実装はOpenTUIのリアルワールド事例として位置付けられる。

OpenTUIの主な特徴:

  • TypeScriptネイティブ: 型推論が効くTUIコンポーネント定義
  • Bun前提: Node.jsより起動が速く、TypeScriptをそのまま実行できる
  • ボックスモデル: BoxやTextといった基本要素を組み合わせる宣言的な書き方
  • イベント駆動: キーボード入力やAPIレスポンスをイベントで処理

これらの設計選択により、tuitter本体はビジネスロジック（API呼び出し・トークン管理・キーバインド）に集中でき、画面描画はフレームワーク側に委譲される。bun installから起動までが速いのも、JS/TSのトランスパイルがランタイムレベルで最適化されているBunの恩恵が大きい。

tuitterのコード読みポイント：認証とAPIクライアントの分離

リポジトリを読み解くうえで押さえておくと早いポイントを挙げておく。

  1. OAuth関連: 127.0.0.1:8787で待ち受けるコールバックサーバーがエントリポイントの一部に含まれる。Authorization Code受領後にX APIのトークンエンドポイントへPOSTし、Access TokenとRefresh Tokenを取得する古典的な流れだ
  2. APIクライアント: X API v2の/2/tweets、/2/users/me、/2/likesなどのエンドポイントを呼ぶ薄いラッパが配置される。レート制限（X-RateLimit-Remainingヘッダ）の扱いは要確認
  3. UIコンポーネント: OpenTUIのBox/Textを組み合わせてフィード表示、投稿フォーム、トースト通知を構成する
  4. 設定読み込み: .envはBunが標準で読み込み、tuitter.confはカレントディレクトリから個別に読み込まれる

forkして自分用機能を足したい場合、追加しやすいのは「カスタムフィード（特定リストやキーワード絞り込み）」「キーバインド変更」「投稿前の文字数バリデーション強化」などだ。逆に、複数アカウント切り替えや高度なメディアアップロードはOAuthとAPI設計から踏み込んだ改修が必要になる。

tuitterのセキュリティ運用

OAuth 2.0で取得したトークンはローカルファイルに平文で保存される。利便性とのトレードオフで、運用面では以下の点を気にしておくと安全側に倒せる。

# トークンファイルの保護
chmod 600 ~/.tuitter/oauth-token.json

# トークン保存先を専用ディレクトリへ
mkdir -p ~/.config/tuitter
chmod 700 ~/.config/tuitter
echo 'X_TOKEN_STORE_PATH=~/.config/tuitter/token.json' >> .env

シェアード環境（複数ユーザーが入る開発VM等）で使うのは設計上推奨されない。Refresh Tokenが流出すれば長期にわたりアカウントを操作される可能性があるため、tuitterは個人用ローカル端末で使うのが本来想定されているユースケースだ。

スコープ最小化も併せて重要だ。書き込みが不要ならtweet.write like.write bookmark.writeを外し、読み取り専用にしておく。tuitter自身の機能は一部制限されるが、トークン漏洩時のリスクは大幅に下がる。

tuitterが向いているユースケース・向かないユースケース

向いているケース:

  • コーディング中のチラ見: tmuxやzellijのペインに常駐させ、コンテキストスイッチを抑える
  • SSH先サーバー作業: 開発VPS上で動かしておき、ブラウザを開かず手元のターミナルから確認する
  • Kittyユーザー: 画像付きツイートまでターミナル内で完結させる
  • SNS時間制限: tuitter.confのMAX_SECONDSで1日の上限をシステム的に固定する
  • API学習: X API v2 + OAuth 2.0 + RefreshTokenの実装サンプルとして読む

向かないケース:

  • チーム運用・自動投稿: 自動化用途にはKestraなどのワークフローエンジンや、Typefully APIの直叩きの方が適している
  • 複数アカウント並行運用: 単一トークン前提の設計で、複数アカウントは想定外
  • DM中心の使い方: TUIでのリッチなメディア表示や通知体験はGUI公式アプリに分がある
  • モバイル: TUIである以上、Termuxなどを除けば実質的にデスクトップ端末用

tuitterに関するよくある質問

Q. Bun以外（Node.js）で動かせますか？ A. 公式手順はBun前提だ。Node.jsで動かすにはトランスパイル設定と.env読み込みの差分を埋める必要があり、現状はBunに揃えるほうが圧倒的に省力。

Q. X API v2の無料プランで使えますか？ A. 認証フロー自体は無料プランで通るが、Read/Postのレート上限は厳しい。タイムラインのポーリング頻度を上げると即座に上限に達するので、X_IMAGE_MODE=offや手動更新中心の運用が現実的だ。

Q. APIキーが流出した場合は？ A. console.x.comから即座にClient ID/Secretを再発行する。あわせてローカルのoauth-token.jsonを削除し、.envを更新したうえでアプリを再起動する。

Q. 画像が表示されない A. ターミナルが画像プロトコルに対応していない、またはX_IMAGE_MODE=offになっている可能性が高い。Kitty・WezTerm・Ghostty以外では画像表示が制限される。

Q. tuitter.confを設定したのに制限がかからない A. tuitter.confは「起動ディレクトリ」のものを読む。別ディレクトリから起動していないか、また.tuitter状態ファイルの書き込み権限が落ちていないかを確認する。

まとめ：tuitterはターミナル中心ワークフローに馴染むX TUIクライアント

tuitterは「ブラウザを開かずターミナル内でXを使い切る」という単一目的に振り切った設計が特徴だ。Bun + TypeScript + OpenTUIという比較的新しい組み合わせで、起動の速さと依存解決のシンプルさを両立している。OAuth 2.0 + X API v2を採用し、旧Twitterクライアントが直面した認証問題を回避している点も実用上は大きい。

加えてtuitter.confのMAX_SECONDSによりSNS時間管理ツールとしての側面も持ち、単なる「ターミナル版X」を超える性格を帯び始めた。フォーク前提のコードベースとしても読みやすく、自前のキーバインドや独自フィードを足す出発点としても扱える。

開発者でかつターミナルから離れたくない層にとって、tuitterは数少ない実用候補のひとつだ。

参照ソース