ライブレポート：このスピードの中では、ただひたすら消去法だけで進む

4月15日から4月30日まで。2週間。1人。そこにAIが加わった。

これはライブレポートです。振り返り（レトロスペクティブ）ではありません。

このシリーズの過去の記事では、「形（Shape）」について書いてきました。暗黙の契約、パターン、そして24年間にわたる単独開発についてです。この記事は、その「形」にAIが加わり、スピードが変化した時に何が起きるのかについて書いたものです。

私はまだその渦中にいながらこれを書いています。形は変わりませんでした。しかし、速度には大きな違いがありました。

2週間でやったこと

2週間。1人。以下がそのリストです。

• APIゲートウェイ: Zuplo。5つのサービスを1つの公開APIの背後に統合。
• カスタムドメイン: 本番環境用の

  gw.ldxhub.io

  、開発者ポータル用の

  gw.portal.ldxhub.io

  。
• DevPortal（開発者ポータル）: APIリファレンスの自動生成。加えて、導入、各サービスのガイド、料金体系、MCPのセットアップ、「どこでも使える（use anywhere）」ことの解説。
• 認証: Auth0を利用したGoogle OAuth、GitHub OAuth、およびメール認証。サインアップから最初のAPI呼び出しまで約30秒。
• 無料枠: 月間25,000クレジット。クレジットカード登録不要。
• 課金: 統合クレジットシステム。1クレジットあたり0.0001ドル。4つのプラン（Free、Starter 15ドル、Standard 50ドル、Pro 150ドル）。超過分も同レートで課金。
• Stripe連携: 有料プランのサブスクリプションおよび超過分の決済用に接続。
• 非同期のメータリング（課金計測）パイプライン: ジョブの完了「後」（リクエストが

  202 Accepted

  を返してから数分、あるいはそれ以上経過した後）にクレジット消費を発火させ、ゲートウェイの課金APIにバッチ処理で送信する独立した経路。
• 5つの公開サービス: StructFlow、RefineLoop、RenderOCR、CastDoc、ExtractDoc。
• 4つの統合チャネル: n8nノード（検証済み、マーケットプレイス公開）、Difyプラグイン（検証済み、多言語対応）、Claude DesktopなどのAIアシスタント向けMCP、および直接のAPI呼び出し。
• マーケティングページ: 企業LP（

  ldxlab.io/ldxhub

  、および各サービスごとのページ）上の4つの製品ページ。それぞれ開発者ポータルへリンク。
• 8本の予約投稿記事: dev.toとZenn向けに、設計哲学を解説する記事。この記事はその5本目にあたります。

これらはすべて表面的なものです。華やかなものは一つもありません。しかし、すべてやらなければならないことでした。

形は保たれた

過去の記事で触れた「形（Shape）」は変わりませんでした。

ジョブが入り、APIが処理を保持する。APIは再試行が必要なものを再試行する。APIは報告すべき実際の結果が出た時に報告する。2003年に音楽配信プラットフォームを動かし、2006年から2014年まで電子書籍プラットフォームを動かしていたのと同じ形が、今は構造化抽出サービスとその他4つのサービスを包み込んでいます。

変わったのは、その内部でのスピードでした。

加速したもの、しなかったもの

加速したもの:

• API設計のイテレーション：すべてのインターフェースは、最終形に落ち着くまでに3〜4回形を変えました。
• 4ヶ国語（英語、日本語、中国語、ポルトガル語）でのドキュメント作成：マーケットプレイスのプラグインがそれを要求しており、順を追って作業する時間がなかったため。
• エッジケースの言語化：「入力に

  inputs

  も

  file_id

  も無かったらどうなるか？」といった疑問に、それが出たのと同じ時間内に文章で回答。
• マーケットプレイスのプラグイン申請（n8n、Dify）：提出、審査、バージョンアップ。
• マイグレーション、フィクスチャの作成、動作確認（サニティチェック）。

変わらなかったもの:

• 課金構造に関する意思決定。
• 統合の境界線をどこに引くか（どのエンジンを使うか、どの表層に出すか）。
• 何をリリースし、何をスキップするか。
• 何をレガシーな内部APIに残し、何を公開サービスにするか。

AIは「判断」を代替したわけではありません。AIは「タイピング」の大部分を代替したのです。

（"大部分"、です。公開サービスとレガシーな内部APIを橋渡しするラッパー部分については、私自身がタイピングしました。それらは小規模で退屈なものであり、24年間この仕事をしてきた私の頭の中にすでにある形そのものでした。説明するよりも、自分でタイピングした方が速かったのです。）

最も困難だったこと

あやうく諦めかけたのは、非同期ジョブのクレジット・メータリング（課金計測）でした。

ほとんどのAPIゲートウェイは、リクエスト時にメータリングを行います。これは簡単です。しかし私が必要としていたのは、ジョブが「完了」した時、つまりリクエストが

202 Accepted

2つのゲートウェイを評価しました。どちらも仕様上は非同期のレポートが可能でした。1つ目は最後まで試しました。APIもドキュメントも揃っていましたが、UIや運用時の挙動にどうしても無視できない粗さがありました。私は2つ目のゲートウェイを使いたいと思い、そちらに戻りました。

2つ目のゲートウェイこそが、私が着地したい場所でした。しかしそこに辿り着いた時、私が必要としている非同期メータリングが本当に可能なのかどうか、確信が持てませんでした。まさにその部分のドキュメントが薄かったのです。サポートボットを試しましたが、ボットにも分かりませんでした。その後、人間の担当者が対応してくれ、ジョブ完了側からメータリングイベントを発火させ、バッチ処理で送信する方法を手順を追って教えてくれました。

それは機能しました。

この構築作業の中で、「向こう側の人間」が可能だと確認してくれるまで本当にできるか分からなかったのは、この部分だけです。私はこのことを覚えておきたいと思っています。24年間一人で作り続けてきて、この特定の未知の領域を抜ける最速の道は、一人で解決することではなく「質問し、相手から適切な回答をもらうこと」だったのです。

（Stripeに関しても小さなつまずきがありました。ゲートウェイの課金フローを機能させるために、Stripe側で何か設定が必要だと勝手に思い込んでいたのです。私はしばらくその「何か」を探していました。しかし、そんなものはありませんでした。ゲートウェイがエンドツーエンドで処理を行い、Stripeはただ送られてきたものを受け取るだけだったのです。「これとどう統合すればいいのか？」の答えが「すでに統合されている」であることも、時にはあるのです。）

意思決定の量

これは私にとって驚きでした。

アウトプットは劇的に増加しました。それは予想通りです。予想外だったのは、それに伴って「意思決定と分岐の量」も掛け算で増えたことです。それらは一つひとつ個別に決着をつける必要があります。近道はありません。一つひとつの決着自体も早くなったため、それらがボトルネックになることはありませんでした。

しかし、疲労の種類が違うのです。

私は24年間、一人でシステムを構築してきました。「疲れる」ということがどういう感覚かは知っています。しかし、これは別の何かです。スピードが速まることで、疑問、回答、小さな軌道修正など、すべてが圧縮され、落ち着く暇がありません。ひとつのフェーズに留まることはなく、常に継ぎ目（シーム）に立たされているような感覚です。

24年間の単独作業からは予想もしていなかったことがあります。私はこれまで「分岐を見落とすこと」を恐れたことはありませんでした。意思決定の量は常に、一人の人間の頭に収まる範囲内だったからです。しかし今、アウトプットが倍増したことで、新たな恐怖が生まれました。「他の5つの決着をつけている間に、本来検討すべきだった何かが通り過ぎてしまったのではないか」という恐怖です。道は進み続け、隣接する分岐は広がり続けます。私は決定を下す前に、そのすべてを見ておきたいのです。この恐怖は以前は存在しませんでした。致命的ではありませんが、ただ確かにそこに存在しています。

これにどう対処すべきか、私にもきれいな答えはありません。ただ重要に思えますし、私が読んできたAIツールの記事には書かれていなかったので、ここに記しておきます。

理論ではなく、消去

ここが、私が留めておきたい部分です。

このスピードの中では、理論をこねることはしません。消去していくのです。

すべての選択肢をモデル化し、会議でトレードオフを比較検討し、プレゼン資料を作っている時間はありません。あるものを1時間手に取り、それが次のものとの接触に耐えられるかを確認し、残すか捨てるかを決めます。生き残るのは、反論を挟む余地がなかったものだけです。

これは生産性の主張ではありません。ただの描写です。

摩擦が十分に小さくなった時、つまり「タイピング」がもはや律速段階ではなくなった時、意思決定の行われ方が変わります。何かが「何を可能にするか」ではなく、何かが「何をサポートできないか」という「消去法」によって決定が下されるようになります。肯定的なケースよりも、否定的なケースの方が声が大きくなるのです。「これを追加したらどうなるか？」と問うのをやめ、「これを後から削除するのが難しくなる要因は何か？」と問うようになります。

これが一般化できることなのかどうかは分かりません。ただ、この2週間に起きたのはそういうことでした。

終わりに

スピードは美徳ではありません。それは単に、摩擦がなくなった時に起こる結果に過ぎません。24年経って、私に残されていた摩擦は、ほぼ「タイピング」だけでした。

私はタイピングを取り除きました。形（Shape）はすでにそこにありました。

この疲労感もまた、レポートの一部です。

このシリーズの記事:

• アコーディオン・パターン：私が一つの巨大なLLMプロンプトを書くのをやめた理由
• ジョブがいつ終わるかは誰にもわかりません。それでも、私は正確に報告したいと考えています。
• 24年間一人で作り続けたとき、何が生き残るのか
• 動的設計だけでは不十分です。運用がもう半分の要素なのです。

この記事の英語版: Live report: at this speed, you don't theorize. You eliminate. (dev.to)

GitHubで編集を提案