X APIに絶望し全て捨てた。Claude Codeで1日で再構築した狂気。

※この記事は、Claude Codeで1人開発しているSNS運用SaaS「ThreadPost」の開発日記です。

全部やり直した。

昨日までの僕を殴りたい。OAuth 2.0で綺麗に実装できたと自惚れていた自分をだ。

「できた。完璧だ。」そう思ってテスト投稿ボタンを押した瞬間、画面には僕のではない、全く別のアカウントへの投稿完了通知が出た。背筋が凍った。バグじゃない。仕様だ。

X API v2のドキュメントを信じて突き進んだ結果、僕は画像投稿にはOAuth 1.0aが必須という、Twitter時代から続く巨大な負債の沼に頭から突っ込んでいた。2024年にもなって、署名生成やHMAC-SHA1なんて言葉を聞きたくなかった。でも、やるしかない。

僕はその場で、昨日書き上げた数百行のOAuth 2.0のコードを全てゴミ箱に捨てた。そしてClaude Codeに向かってこう打った。「全部やり直しだ。今すぐOAuth 1.0aに切り替えるぞ。1日で終わらせる。」これが、狂気のような24時間の始まりだった。

今週の全体像

今週は、破壊と再生の1週間だった。当初の予定では、XとThreadsの連携をサクッと終わらせて、分析機能のUIを整えるはずだった。しかし、現実は甘くない。APIの仕様という名の壁に正面衝突し、予定は全て吹き飛んだ。

結果として、23件のコミットを積み上げ、認証基盤をゼロから作り直した。企業なら仕様策定とセキュリティレビューだけで3週間はかかる工程だ。それをAIという相棒と共に、1日で強行突破した。

• 総コミット数: 23件
• 実装した新機能: 2件
• 修正した致命的バグ: 2件
• 壊した回数: 4回

地図は書き換わった。モダンな設計を捨て、泥臭く動くことを最優先した結果、ThreadPostはついにSNS運用の核心へと足を踏み入れた。

X API v2という蜃気楼、そして1.0aへの回帰

OAuth 2.0 PKCE。最新の、最もセキュアで、実装もスマートな認証方式だ。僕はこれを使ってX API v2を繋いだ。プロフィール取得も、テキスト投稿も動いた。ところが、画像投稿を実装しようとした瞬間に絶望が訪れた。

X API v2において、ユーザー個別のコンテキストで画像をアップロードするには、依然としてOAuth 1.0a (3-legged)が必要だ。v2でもできるという噂はあるが、Free/Basicプランの制限やドキュメントの不備が多すぎて、実質的に使い物にならない。

何が起きたか。OAuth 2.0で取得したトークンを使って画像投稿APIを叩くと、アプリ所有者である僕のアカウントに画像が紐付く。複数のユーザーが利用するSaaSにおいて、これは致命的な欠陥だ。僕は決断した。「17:08 - X OAuth 2.0を廃止してOAuth 1.0aに統一」。このコミットメッセージが、僕の決意の全てだ。

OAuth 1.0aの実装は、2.0に比べて圧倒的に面倒だ。リクエストのたびに、コンシューマーキー、トークン、タイムスタンプ、ノンスを組み合わせ、特定の順序で並べ替え、HMAC-SHA1で署名を作らなければならない。1文字でも間違えれば、APIは無情にも401 Unauthorizedを返す。

ここでClaude Codeの真価が発揮された。「OAuth 1.0aの3-leggedフローを実装して。署名生成ロジックも含めて全部だ。」この指示だけで、AIは複雑怪奇な署名生成コードを吐き出した。人間が手書きすれば、デバッグだけで数時間は溶ける部分だ。

しんたろー:
12件中8件が一発OK。残り4件はこっちの指示がクソだった。成功率67%。綺麗なコードよりも、今日動くコードの方が100倍価値がある。

Threads API：ドキュメントの嘘とメタタグの罠

Xの騒動が落ち着く間もなく、次はThreads APIが牙を剥いた。ThreadsはMetaの傘下にあるため、APIの挙動はInstagram Graph APIに近い。だから楽勝だと思っていた。それが大きな間違いだった。

まず、エンドポイントが違う。ドキュメントにはこう書いてある、と思って実装しても動かない。「01:19 - Threads API正しいエンドポイントに修正」。長期トークンを取得するためのURLが、微妙に、しかし決定的に間違っていた。さらに、client_idが必要だったり不要だったり、パラメータの要求がエンドポイントごとにバラバラだ。

次に襲ってきたのが、Facebookドメイン認証の罠だ。「09:49 - Facebookドメイン認証用メタタグを追加」。コードをいくら直しても、認証のコールバックが返ってこない。原因はコードではなく、ThreadPostのドメインがMeta側に正当な所有物として認められていないことだった。

そして、分析機能だ。「19:27 - Threads分析をInsights APIから取得するように修正」。ユーザーのフォロワー数を取得するだけなのに、通常のUser APIでは値が返って来ない。わざわざInsights APIという別系統のAPIを叩き、過去24時間のメトリクスとして取得しなければならない仕様だった。リダイレクトの待機時間を3秒から1秒に削るような、細かいUXの調整を繰り返しながら、ようやくThreadsも僕の支配下に入った。

しんたろー:
Threadsのドキュメントは、書いた本人も信じてないんじゃないか。結局、自分の手で叩いたレスポンスだけが真実だった。

落とし穴

X API v2のドキュメントを信じてOAuth 2.0を実装した。これが全ての元凶だった。最新のAPIを使えば、最新の機能が使えるという淡い期待。画像投稿しようとしたら、なぜか他人のアカウントに投稿されるという怪奇現象が発生したとき、僕は自分の才能を疑った。

原因は僕の脳ではなく、APIの設計思想の断絶にあった。OAuth 2.0の時間返してと天を仰ぎながら、即座に1.0aのコードを書き始めた自分の切り替えの早さが一番の狂気だ。個人開発にサンクコストなんて言葉はない。動かないコードは、たとえ昨日までの自分が心血を注いだものであっても、ただのゴミだ。

今日の数字

今回の開発を、冷静に数字で振り返ってみる。1日の実装で23コミットを積み上げた密度は、まさにVibe Codingの極致だ。OAuth 2.0実装に費やした6時間を学習コストと割り切り、1.0aへの移行を修正コストとして処理した。このスピード感は、組織に属していたら絶対に不可能だ。

• 総コミット数: 23件
• 実装時間: 14時間（企業なら2〜3週間の内容）
• 削除した行数: 1,200行
• AIとの対話回数: 150回以上

しんたろー:
コミット1件あたり約36分。飯を食っている間も、風呂に入っている間も、頭の中はHMAC署名の順序でいっぱいだった。

FAQ

Q: なぜOAuth 1.0aのような古い規格を今さら使うの？

X API v2の画像投稿機能が、依然として1.0aの署名方式を要求するからだ。最新の2.0だけでは、SaaSとして不可欠なユーザーごとの画像投稿を安定して実現できなかった。技術的な美しさよりも、ユーザーが画像を投稿できるという実利を取った。

Q: AI開発においてドキュメントの重要性は変わった？

AIはドキュメントを読み解くのが得意だが、そのドキュメント自体が嘘をついている場合は無力だ。今回のようにAPIの仕様変更や隠れた制約がある場合、最後は人間が実際に叩いてみるしかない。ドキュメントを信じるな、レスポンスを信じろ。

Q: 1日でこれほどの実装をこなすコツは？

完璧主義を捨てることだ。特にAPI連携は、最初から綺麗な抽象化を狙うと仕様変更のたびに死ぬ。まずは泥臭くハードコードでもいいから動かし、Claude Codeにリファクタリングさせるリズムが最速だ。

泥沼の先に、光が見えた。

一時はどうなることかと思った。自分が書いたコードを全部捨てる時の、あの虚無感。でも、それを乗り越えて投稿完了の文字を画面に見た時、全ての疲れが吹き飛んだ。

APIの仕様変更に振り回されるのは、開発者の宿命だ。でも、僕らにはAIがある。1人で3週間分の仕事をこなし、仕様の罠を力技でねじ伏せる。そんな開発のリアリティを、これからも届けていきたい。

もし、あなたがAPIの仕様変更や複雑な認証フローに頭を抱えているなら。あるいは、SNS運用をもっとスマートにしたいと考えているなら。僕が泥をすすりながら完成させた、この機能を試してみてほしい。

👉 ThreadPostでSNS運用を自動化する