3ヶ月後：まだコーディング中、まだ学習中、まだ行き詰まることも

更新（2026年）： S&P 500金融チャットボットプロジェクトは最終的に終了しました。Sydneyは復活し、現在はブログコンテンツと製品にフォーカスしています。Sydneyを試す →

---

コーディングの旅の更新を書くべきかどうか悩んでいました。進捗は派手でもなく、外から見える形でもなかったので、なぜわざわざ？

まあ、この投稿が将来の自分へのリマインダーになるかもしれません。進歩は時に遅くなり、成長はしばしばスパート的に起こるということを。

4月中旬の自己評価チャットボット構築に関する前回の投稿以来、いくつかのコースに取り組みました：

• CourseraのReact Basics（Meta提供）
• CourseraのReact Advanced（Meta提供）
• Django Webフレームワーク
• Full Stack

なぜこれらのコースを選んだのか？

個人的な経験とこれらのコースを選んだ思考プロセスを共有したいと思います。同じような旅をしている（またはこれからする）方の参考になれば幸いです。

マシンへの指示がうまくなること

フルタイムの仕事をしながらコーディングを始めて約10ヶ月が経ちました。（2023年10月に公開したコーディング経験ゼロで自分のチャットボットを構築した方法：学んだ教訓で詳しく読めます。）

Generative AI（chatGPT、Anthropic Claude、Visual Studio CodeのMicrosoft CoPilotなど）の助けなしには絶対にここまで来れませんでした。しかし、コーディングすればするほど、これらの基盤モデルはパワフルだけれど、まだインターンのようなものだと気づきます。計画を立てたり、曖昧なタスクを解決するのはまだ得意ではありません。指示が具体的であればあるほど、出力は良くなります。

つまり、コーディングの指示をますます具体的にする必要があります。しかし、どうやって？これまでは自然言語で欲しいものを説明してきました。基本的なレベルでは機能しますが、より複雑なタスクには不十分です。

そこで次の論理的な質問は、何を学ぶかということです。

解決しようとしているビジネス/ユーザーの問題にフォーカスする

このウェブサイト用のチャットボット（コードネームSydney）は遅かったのです（おそらく「今も」）。遅さは以下の両方で発生しました：

• 起動時間
• 会話中

ストリーミングが有効になっていないため、ユーザーは完全な回答を見るまで比較的長い時間待たなければなりませんでした。

つまり、私の目標はシンプルでした：高速でレスポンシブにすること。

目標はシンプルです：高速でレスポンシブにすること。しかし、より基礎的な知識がなければ、管理可能な問題に分解するのは困難です。そこで、スケーラブルで安全かつ高速なフロントエンドフレームワーク、バックエンドフレームワーク、フルスタック（データベースを含む）についてもっと学ぶことにしました。

ReactとDjangoの経験

• React: ReactはDjangoに比べて比較的学びやすく、デプロイも簡単です。（当然！）現在のチャットボットのフロントエンドはReactを使用しており、ClaudeとChatGPTがほとんどのコーディングタスクを問題なく処理できることがわかりました。本番環境へのReactのデプロイもかなりシンプルで、チャットボットページは会話中により応答性が高くなったようです。
• Django: DjangoとDjango Rest Framework（DRF）は学習曲線が急でした。特にCloud SQLデータベースを使用したデプロイとセキュリティの確保が大変でした。Djangoの包括的な性質から、適切なレベルのセキュリティでのデプロイには時間がかかりました。しかし、本番環境でDRFを使ったストリーミングHTMLレスポンスをまだ動作させることができません！WebSocketsを使えば動作させることはできましたが、そのアプローチはDRFから大きく逸脱するため、まだ採用していません。

Langgraphストリーミングをシンプルなフロントエンドで動作させるフレームワークや方法をご存知でしたら、教えてください！

4月に言及した金融チャットボットはどうなった？

良いニュースは、このプロジェクトが多くの方の興味を引いたことです。多くの質問やコメントをいただきました。悪いニュース？完成には程遠いです T.T その理由は：

1. 検索品質、ベクトルストアの月額コスト、エンベディングコストのバランス

4月の投稿で述べたように、WeaviateのServerless Cloud Vector Storeを評価しています。実際にお金がかかります。このプロジェクトでは、おそらく以下のようになります：

• データ量: 1,000万以上、おそらく1,250万〜1,500万のデータオブジェクト
• コスト見積もり: ベクトル次元512で、月額コストは$600〜$750の範囲

この金額は本番環境の企業には管理可能ですが、このようなサイドプロジェクトには高すぎるかもしれません。コストを下げる方法を見つける必要があります。

Weaviateの価格設定の仕組みに基づくと、2つのレバーがあります：データオブジェクトの数を減らすか、ベクトル次元を減らすかです。どちらも異なるトレードオフがあります。

データオブジェクトを減らす方法

• 積極的なテキストクリーニング: S&P 500の500社それぞれが過去10年間に複数の提出書類を持っていることを考えると、10Kと10Q提出書類の全体的なテキストサイズを削減すると役立つかもしれません。このオプションは使い果たしたと思います。
• チャンクサイズの増加: チャンクサイズを256から512、1,000、2,000、3,000に増やすことで、データオブジェクトの数を2倍、4倍、10倍減らせます。しかし、大きなチャンクは精度が低くなる傾向があるため、検索品質が低下する可能性があります。

ベクトル次元を減らす方法

ベクトル次元の削減は検索品質と直接相関しているようです。次元が低いほど、検索品質は悪くなります。OpenAIの「text-embedding-3-small」と「text-embedding-3-large」を様々な次元で実験中です。良い推奨があれば共有してください！

OpenAIの「text-embedding-3-large」モデルの使用は、エンベディングフェーズのコストも増加させます。例えば、23社の10K/10Q提出書類の過去10年分のエンベディングを1024次元で生成するのに$4.5かかりました。S&P 500全体では$100以上かかる可能性があります。（はい、私はちょっとケチなんです。以前から知っていましたか？ :P）

2. クエリ翻訳、構造化、検索中のレイテンシー

クエリ翻訳と構造化が精巧であればあるほど、より良い検索語句/コンテンツ検索語句を生成でき、より高品質な検索結果が得られます。しかし、レイテンシーも増加します。

• クエリ翻訳は、最初のユーザーの質問を検索に適したサブ質問に翻訳するようモデルに依頼するステップです。例えば、「Airbnbの営業利益率は2020年から2022年にかけてどう変化しましたか？」という元の質問に対して、モデルは以下のようなサブ質問を生成できます：

[
"What was Airbnb's operating margin in the 10-K filing for the year 2020?",
"What was Airbnb's operating margin in the 10-K filing for the year 2021?",
"What was Airbnb's operating margin in the 10-K filing for the year 2022?"
]

• クエリ構造化は、これらの質問を検索クエリやコンテンツ検索クエリに変換し、関連するフィルターと共に提供するようモデルに依頼するステップです。上記の例で、質問1に対してモデルは以下を返す可能性があります：

\{
    "content_search": "What was Airbnb's operating margin in the 10-K filing for the year 2021?",
    "company_conformed_name": "Airbnb, Inc.",
    "form_type": "10-K",
    "conformed_period_of_report": "2021-12-31"
\}

検索では、返す結果が多いほどモデルの処理に時間がかかります。返す結果を減らすとレスポンスタイムは速くなりますが、コンテキスト不足により回答の質が低下する可能性があります。

まとめ

取り組んでいることはまだありますが、この投稿はすでに予定より長くなったので、ここでまとめます。

フルタイムで働きながらコーディングを学んでいる方はいますか？すべてが同じくらい重要に感じられるとき、次に何を学ぶかをどう決めていますか？

よろしくお願いします、Chandler