🤖

CodexでThreadInを0→1で作って、ソフトウェア開発の見え方が変わった

に公開

ここ最近、Codexを使って小さな実験をしていました。

それが ThreadIn です。
https://threadin.io/

ThreadIn は、オンライン上のコメントやスレッドを読んだときに、単なる翻訳ではなく、

  • スラング
  • tone(ニュアンス)
  • sarcasm(皮肉)
  • meme
  • cultural context(文化的背景)

まで含めて理解できるようにする Chrome Extension です。

最初は「英語コメントを理解するためのツール」と考えていました。

でも作っていく中で、自分の中での理解が変わっていきました。

今はむしろ、

「インターネットの文脈を理解するためのレイヤー」

だと思っています。

多くの人は、単語の意味は分かります。
でも、本当に困っているのはそこではありません。

「言葉は読める。でも相手が本当に何を言いたいのか分からない。」

これは英語学習者だけではなく、ネイティブスピーカーでも同じです。

インターネットの文化、コミュニティごとの空気感、ミーム、皮肉、略語、暗黙知。

オンラインの会話には、辞書や翻訳だけでは届かない「文脈」が大量にあります。


Codexは「デジタル社員」ではなく、Jarvisだった

最近、AI Agent を「デジタル社員」と表現する人が多いです。

でも、自分が Codex を使って感じたのは少し違いました。

自分にとって Codex は、むしろ Jarvis に近かったです。

頭の中にあるアイデアを、すぐにコード、UI、コンポーネント、スクリプト、動くプロダクトに変換していく感覚。

これは本当に衝撃的でした。

以前は、アイデアがあっても、実際に形になるまでには長いチェーンが必要でした。

  • 要件整理
  • デザイン
  • フロントエンド
  • バックエンド
  • テスト
  • リリース

そのどこかで熱量が落ちていく。

でも今は違います。

「ちょっと試したい」が、数時間後には動くUIになっている。

「こういう体験が欲しい」が、数日後には本当に触れるプロダクトになっている。

この変化はかなり大きいと思います。

以前、何かアイデアを思いついたとき、自分の最初の反応は:

「これを作るには結構なチームが必要だな」

でした。

でも今は:

「まず Codex に作らせてみよう」

になっています。

この変化は、本当に大きい。


ただし、まだ完全な「ノーコード時代」ではない

もちろん、だからといって

「誰でも完全にノーコードでプロダクトを作れる」

とはまだ思っていません。

少なくとも、今の段階ではそうではないです。

Codex はかなり強い。

  • コードを書く
  • UIを組む
  • 修正する
  • リファクタリングする
  • デバッグする
  • ビルドを直す

かなりのことができます。

でも、プロジェクトが少し複雑になると、問題は別のところに出てきます。

特に厄介なのは、繰り返し発生するバグです。

Codex は時々、同じ場所をぐるぐる回ります。

一つのバグを直したと思ったら、別のバグを3つ増やす。

「違う、そこじゃない」が何回も起きる。

そこで自分がやるようになったのは、Codex に対して:

  • ログを追加させる
  • 状態を可視化する
  • パラメータを出力する
  • 分岐を追跡する
  • イベントを埋め込む

ことでした。

そして、その情報をもう一度 Codex に渡して、問題を再分析させる。

これを繰り返してようやく直る。

この経験で強く感じたのは:

AI Coding 時代の本当のスキルは、「AIに何を見せるか」なのかもしれない。

ということです。

全部のコードを書く必要はない。

でも:

  • どこが怪しいのか
  • 何が重要な情報なのか
  • どこを見るべきか
  • 何が変化したのか
  • 修正が本当に正しいのか

を判断する力は、まだ人間側に必要です。

つまり今のAI開発は:

「AIが全部作る」

ではなく、

「AIが高速に作り、人間が方向修正する」

に近い感覚でした。


Codexが強くなるほど、「昔の起業の形」が弱くなる

ThreadIn を作っていて、もう一つ強く感じたことがあります。

それは:

Codex がここまで強くなると、昔は成立していた起業の形が、だんだん成立しにくくなる。

ということです。

以前なら、小さな機能を作って、UIを付けて、APIを繋げるだけでも、ある程度の価値がありました。

でも今は、それが圧倒的に安く、速く作れてしまう。

昔なら小さなチームが必要だったものが、今では一人 + AI で週末に作れてしまう。

これはかなり大きな変化です。

ただ、機会がなくなるわけではないと思っています。

むしろ、機会は別の場所に移動している。


一つ目の大きな機会は「インフラ」

AI Native なプロダクトが増えれば増えるほど、重要になるのはインフラです。

例えば:

  • GitHub
  • CI/CD
  • デプロイ
  • モニタリング
  • ログ
  • モデルルーティング
  • 支払い
  • 権限管理
  • データ基盤

もし画像や動画を扱うなら:

  • FFmpeg
  • GPU処理
  • メディアパイプライン

なども重要になります。

AI はアプリケーション層を爆発的に増やす。

でも、その裏側のインフラ価値は、むしろさらに大きくなると思っています。

「作ること」が安くなるほど、

「安定して運用すること」

の価値が上がるからです。


二つ目の機会は「マルチモーダル」

もう一つ、かなり大きいと感じたのがマルチモーダルです。

画像、音声、動画。

この領域は、単純なテキスト生成とは違います。

問題は「生成できるか」ではなく:

  • センス
  • 審美眼
  • テンポ
  • 演出
  • 判断
  • 一貫性

だからです。

実際、ThreadIn の動画やサムネイルを作っている時にかなり感じました。

AI はすでに自分より上手い。

でも、インターネット上の本当に優れたプロモーション動画やビジュアルと比べると、まだ差があります。

「使えるもの」は作れる。

でも「強いもの」を安定して作るのは、まだ難しい。

だから自分は、マルチモーダル領域の本当のチャンスは:

「画像生成」そのものではなく、価値ある生成フローを作ること

だと思っています。

無限にガチャを回すのではなく、

  • ワークフロー
  • テンプレート
  • 品質判断
  • 垂直特化
  • 再現性

を作ること。

ここにはかなり大きな可能性があると思っています。

https://www.youtube.com/watch?v=XFQHYzuOs0c


最後に

今回 ThreadIn を作って、自分が一番強く感じたのは:

「ソフトウェア開発の生産方式そのものが変わり始めている」

ということでした。

これは、ある日突然世界が変わるような話ではありません。

静かに、でも確実に進行している変化です。

最初は:

「AI がコードを少し書ける」

だったものが、

今では:

  • UIを作り
  • デバッグし
  • 動画を生成し
  • 素材を作り
  • デプロイを手伝い
  • プロダクトを形にする

ところまで来ている。

そして気づくと:

「アイデア」と「動くプロダクト」の距離が、ものすごく短くなっている。

AIGC の変化は、基盤モデルだけで起きるわけではないのかもしれません。

むしろ:

  • 個人開発者の強化
  • 小さなチーム
  • 高速な検証
  • 低コストな試行錯誤
  • AI Native なワークフロー

という形で、別の方向から急速に進んでいる。

今回 ThreadIn を作ったことで、自分はその変化をかなりリアルに感じました。

そして今、一番面白い時代に入ってきている気がしています。

https://threadin.io/

Discussion