なにをやっているのか

生成AIをモデルに問い合わせるだけの実装として見るなら、ここ数年で難易度は下がりました。ChatGPTやClaudeのAPIを呼ぶコード自体は、チュートリアルを一通りなぞればひとまず動くようになっています。実際の案件で人が足りていないのは、その前後の工程です。出力品質をどう定義してどう測るか、社内データをどこまでモデルに渡してよいか、応答時間と費用のバランスをどう取るか、公開後にどう改善を続けるか、業務側の要件をどう技術要件に翻訳するか、安全性をどう検証するか。このいずれかで止まっている案件は少なくありません。

評価設計は特に人を選ぶ工程です。出力が「それらしい日本語」になっているかどうかは誰でも判定できますが、業務として使える精度かどうかは別の話です。RAGASのような評価フレームワークを導入するにしても、何を正解とみなすか、どの誤りを許容するかという設計は人が決める部分として残ります。ここを任せられる人は、モデルを呼べる人の数に比べるとまだ少ない印象です。

私たちは2022年に大阪でインフラ事業として創業し、2026年から東京でSES事業を立ち上げています。案件の紹介は日に複数件入ってきますが、お願いできる方がまだ足りていない状態です。Python・生成AI領域も同じ傾向で、モデルを呼ぶだけの実装より、評価設計やデータの扱いまで見られる人を探している案件が目立ちます。

なぜやるのか

PoCを作れる人と、運用に載せて回せる人では、求められる経験が違います。前者はAPIの使い方とプロンプトの書き方を覚えれば到達できますが、後者は評価設計・データ設計・運用改善といった、正解が一つに決まらない判断の経験が問われます。案件を選ぶ側から見ると、この違いは技術構成の知識よりも効いてくる場面が多いです。

安全性の検証も同様です。OWASPが公開しているLLMアプリケーション向けのリスク一覧のような整理は、社内のセキュリティ担当や監査部門から参照されることがあります。プロンプトインジェクションへの対策や、出力に個人情報が混ざっていないかの確認を、実装とは別の工程として経験しているかどうかは、案件選びで差になりやすい部分です。

権限管理も見落とされがちです。社内データをモデルに渡す際、どの部署のどのデータを、誰の権限で参照させるかを設計する作業は、モデルの選定や実装より地味ですが、事故が起きたときの影響はこちらのほうが大きくなります。

どうやっているのか

案件選びの入り口は、カジュアル面談です。その場にある案件の中から、合いそうなものを3件お見せします。生成AI関連の案件では、評価設計やデータの扱いに関する経験を聞かれることが多く、お話をうかがって合わないと感じた場合は、その場で正直にお伝えします。

スキルシートも、生成AI案件では書き方が変わってきます。モデルを呼んだ経験だけでなく、出力の評価基準をどう作ったか、運用開始後にどんな改善を加えたかを書けるかどうかで、客先面談での印象が変わります。客先で聞かれやすい質問は、面談の前に一緒に整理します。

こんなことやります

契約形態は準委任です。稼働形態は案件によって異なり、専任で入るものもあれば、他の業務と並行して進めるものもあります。

求めるのは、Pythonでのバックエンド開発の経験に加えて、生成AIの出力を評価する仕組みを考えた経験や、社内データを扱う際の権限設計に関わった経験です。まずはカジュアル面談で、いまある案件の状況からお伝えします。