CodexでThreadInを0→1で作って、ソフトウェア開発の見え方が変わった
ここ最近、Codexを使って小さな実験をしていました。
それが ThreadIn です。

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 はすでに自分より上手い。
でも、インターネット上の本当に優れたプロモーション動画やビジュアルと比べると、まだ差があります。
「使えるもの」は作れる。
でも「強いもの」を安定して作るのは、まだ難しい。
だから自分は、マルチモーダル領域の本当のチャンスは:
「画像生成」そのものではなく、価値ある生成フローを作ること
だと思っています。
無限にガチャを回すのではなく、
- ワークフロー
- テンプレート
- 品質判断
- 垂直特化
- 再現性
を作ること。
ここにはかなり大きな可能性があると思っています。
最後に
今回 ThreadIn を作って、自分が一番強く感じたのは:
「ソフトウェア開発の生産方式そのものが変わり始めている」
ということでした。
これは、ある日突然世界が変わるような話ではありません。
静かに、でも確実に進行している変化です。
最初は:
「AI がコードを少し書ける」
だったものが、
今では:
- UIを作り
- デバッグし
- 動画を生成し
- 素材を作り
- デプロイを手伝い
- プロダクトを形にする
ところまで来ている。
そして気づくと:
「アイデア」と「動くプロダクト」の距離が、ものすごく短くなっている。
AIGC の変化は、基盤モデルだけで起きるわけではないのかもしれません。
むしろ:
- 個人開発者の強化
- 小さなチーム
- 高速な検証
- 低コストな試行錯誤
- AI Native なワークフロー
という形で、別の方向から急速に進んでいる。
今回 ThreadIn を作ったことで、自分はその変化をかなりリアルに感じました。
そして今、一番面白い時代に入ってきている気がしています。

Discussion