2026年1月、フリーランスとして2件目の案件に参画しました。
最初にあったのは、「AIを使って効率化したい」という大きな要件でした。
案件の領域は労務BPO・社会保険申請で、既存システムへLLMを組み込むことは決まっていました。ただ、UI/UXや、処理のどこまでをLLMに任せるかといった部分はほとんど決まっていません。
そこから実際に作っていったのが、OCRや小規模なRAG、1問1答形式のウィザードです。
この記事では、2件目の案件をどう探したかではなく、参画後に実際に何を作り、どこまで担当していたのかを書いていきます。
2件目の案件を探したときに何を優先していたかは、前の記事でまとめています。
労務BPOの社会保険申請で、「AIを使って効率化したい」というところから始まった
LLMを社会保険申請周りで使うこと、既存システムへ組み込むことは決まっていました。
一方で、当初の要件は「AIを使って効率化したい」というもので、設計はほとんどありませんでした。
そこから自分が整理していったのが、ユーザーがどう操作するのか、そして処理のどこまでをLLMに任せるのかという部分です。
当初はジェネレーティブUIの構想がありました。
ただ、自分は会話のラリーが増えるほどユーザー側の負荷も増えると考え、チャットだけで完結させる形から、1問1答のウィザードを中心にして、必要な部分だけLLMを使う形へ変えていきました。
実装中にも、LLMへ任せる範囲を広く取りすぎたと感じる部分があり、徐々にその範囲を絞っています。
当時は、AIを使うことそのものよりも、UXを優先したいという感覚がありました。
実際に作ったのは、OCR・小規模RAG・1問1答のウィザードだった
実際に取り組んだ機能の一つがOCRです。
対象は、入退職連絡票のような帳票でした。画像だけではなく、ExcelやPDFも扱っています。
読み取っていたのは、基本的な個人情報や社会保険の届出に必要な項目です。ExcelやPDFについては、文字列化したうえでLLMへ渡していました。
読み取り結果は、そのまま入力フォームへ反映する作りにはしていません。
一度モーダル上に結果を表示し、ユーザーが内容を確認する。そのうえで、チェックした項目だけをフォームへ反映する形にしていました。
当時の感覚ではOCRの精度は高く、特に困った項目もありませんでした。
もう一つ使っていたのが、小規模なRAGです。
FAISSとLangChainを使い、対象にしていたドキュメントは約10ファイル。所定の場所へファイルを置いたあと、手動のバッチ処理でベクトル化していました。
インデックスは永続化せずメモリ上だけで保持し、チャンク処理もしていません。
ユーザーから質問を受けると、FAISSで類似する文書を検索し、その結果をプロンプトに含めてLLMへ送り、回答を返します。
プロンプト側には、推測しないこと、分からない場合は「不明」とすること、与えられた情報を使うことなどの制約を入れていました。必要な処理では、指定したフィールドやJSON構造で返す形にもしています。
文書量が少なかったこともあり、当時は検索精度について大きな問題は感じませんでした。
一方で、自分にはLLMやRAGを深く理解して使いこなしているという感覚はありませんでした。
既存の処理を参考にしながら、自分でも手を動かして実装している。その感覚のほうが近かったです。
顧客ヒアリングからリリースまで担当した
この案件では、実装だけではなく、顧客ヒアリング、要件整理、基本設計、詳細設計、実装、テスト、リリースまで担当しました。
「AIを使って効率化したい」というところから始まり、UI/UXやLLMへ任せる範囲を整理し、実際の機能へ落としていくところまで関わっています。
当時は、この仕事に対して強い成長実感がありました。
LLMやRAGについて深く理解できている感覚とは別に、顧客から話を聞くところからリリースまで担当する仕事をしていました。
参画から約半年で、開発中心から運用・バグ改修中心へ変わっていった
参画当初は、ここまで書いてきたような開発が仕事の中心でした。
ただ、参画から約半年が経つ頃には、バグ改修や運用に関わる仕事の比重が大きくなっていきました。
最初はOCRやRAG、ウィザードなどの開発が中心でしたが、その後はすでに動いているものへの対応が中心になっていった形です。
現在振り返ると、この変化については違和感もあります。
2件目の案件で自分がしていた仕事は、参画した直後と約半年後でも同じではありませんでした。前半はAIを使った機能の開発、そこから徐々に運用・バグ改修へと、仕事内容の比重が変わっていった案件でした。
コメント