はじめに
「簡単なタスクなので、すぐできると思います」
入社して間もない頃、社長からそう言われて任された仕事がありました。
今振り返れば、経験者にとっては、それほど難しい仕事ではなかったのかもしれません。
ただし、当時の私は、GitHubでプルリクエストを作った経験が数えるほどしかないヒヨッ子です。
当然、全然簡単ではありませんでした。
環境構築で詰まり、複数のリポジトリを行き来し、データベースの変更に怯え、最終的には初めての本格的なPRが1,000行を超えました。
マジで反省してます。
この記事では、そんな状態からスタートアップの長期インターンに参加し、Webアプリの機能開発やLLMを使ったデータ抽出システムの改善に取り組むなかで学んだことを書きます。
技術の詳しい解説というより、失敗と反省が中心です。
これから長期インターンに参加する学生や、AIを使った開発に興味がある方の参考になれば幸いです。
インターンの前提
私は大学院に通いながら、スタートアップ企業で週30〜40時間ほど、有給インターンとして働いています。
職種はAIエンジニアです。
主な業務は、Webアプリケーションの機能開発と、LLMを利用したデータ抽出システムの精度改善でした。
触った技術は、主に以下です。
- Python
- Ruby on Rails
- SQL
- TypeScript
- AWS
- 各種LLM API
採用時にはコーディングテストがあり、Railsを使ったスクレイピングアプリの開発と、AWS EC2へのデプロイを行いました。
スクレイピング部分をLambdaやCodeBuildで動かす課題もありました。
もちろん、AIにもかなり助けてもらいました。当時はAntigravityやGeminiを使って実装しましたが、現在の開発環境なら、同じ課題ももう少し楽に進められる気がします。
とはいえ、入社時点の私は、チーム開発にも大規模なコードベースにもほとんど慣れていませんでした。
そんな状態でも、入社2日目には普通にタスクが飛んできました。
スタートアップは待ってくれません。
初見からワケワカメ
最初に担当したのは、企業情報を提供するWebアプリの機能改善でした。
そのアプリには、企業のコンプライアンススコアや、コンプライアンス違反に関するアラートを表示する機能があります。
しかし、表示されるアラートの内容やスコアリングに課題があり、その改善を任されました。
具体的には、次のような作業です。
- データベースに新しいテーブルを作成する
- スコアリングAPIにフィルタリング機能を追加する
- 新しいスコアリング方法を企画・実装する
- フィルタリングしたデータをWebアプリの画面に反映する
箇条書きにすると、それほど怖く見えません。
しかし、実際には次々と壁が現れました。
まず、READMEを読んでも環境構築ができません。
次に、二つのリポジトリを横断しながら、既存の実装を確認して設計を練り直す必要がありました。
さらに、データベースに新しいテーブルを追加し、そのデータを画面に表示する都合上、障害を防ぐために二段階でリリースする必要もありました。
何を、どの順番で、どのリポジトリに実装するのか。
初心者の私には、ほとんどパズルでした。
そして、ようやく完成させた初めての本格的なPRは、1,000行を超えました。
レビューしてくださったPMには、今でも申し訳なく思っています。
当時の私は、目の前の実装を終わらせることに必死で、「どうすればレビューしやすい単位に分けられるか」まで考えられていませんでした。
コードが動くことと、チームで開発できることは別物です。
インターンに参加して最初に学んだのは、その当たり前の事実でした。
なお、環境構築で詰まっていた原因は、Auth0のキーが.envファイルに正しく入っていなかったことでした。
先輩に助けてもらい、ついでにDBeaverのセットアップとREADMEの更新までしていただきました。
マジ感謝です。
唐突にエラー対応を任されてワケワカメ
別のタスクでは、Webスクレイピングを使って企業データを自動収集するシステムの精度改善を担当しました。
私の主な業務は、次のようなものでした。
- プロンプトの修正
- 正規表現の修正
- スコアリング方法の調整
- 参照サイトのブラックリスト・ホワイトリスト管理
- 複数のLLM APIへのタスク配分の調整
その頃、コスト削減のため、利用するモデルをOpenAI APIからQwen系のモデルへ移行する計画が進んでいました。
モデルの移行は別のメンバーが担当し、私は精度改善に集中する、という分担でした。
ところが、移行直後にシステムでエラーが発生し、精度改善そのものが進められない状態になりました。
Slackで担当者とやり取りしていたところ、最終的に「この部分は担当範囲的にそちらです」と、エラー対応が私のところにやってきました。
しかも、移行に合わせてDagsterによるフロー管理が導入されており、私はエラーの見方すらよく分かっていませんでした。
さらに、頼りにしていたPMは体調不良で不在。
正直、かなり焦りました。
原因は一つではありませんでした。
Qwen側の出力形式が安定せず、期待していたJSON以外の形式が返ってくることがありました。
機械学習APIの処理が重く、タイムアウトするケースもありました。
プロンプトがモデルにとって重すぎることもありました。
一つ直したら、別のエラーが出る。
別のエラーを直したら、今度は精度が落ちる。
派手な解決策はなく、ログを読み、仮説を立て、地道に一つずつ潰していきました。
当時は「よく分からないプロジェクトの障害対応を、突然一人で任された」という気分でした。
ただ、終わってみれば、案外なんとかなりました。
この経験から学んだのは、分からないタスクでも、分解して一個ずつ確認すれば、少なくとも前には進めるということです。
そ、剣は一つなり
「そ、剣は一つなり」という言葉があります。
北辰一刀流の開祖、千葉周作に由来するとされる言葉で、複数の敵に囲まれても、自分に向かってくる剣はその瞬間には一本だけ、という意味です。
仕事でも、似たようなことがあると思います。
タスクを分解すると、やることが10個、20個と並ぶことがあります。
一覧を見た瞬間は、それだけで心が折れそうになります。
私も一度、11個のデータ抽出フローをまとめて改善する仕事を任されました。
「11個」という数字だけを見て、かなり圧倒されていました。
しかし、同時に11個のフローを直す必要はありません。
今、自分が確認するエラーは一つです。
今、修正するプロンプトも一つです。
今、レビューする差分も一つです。
一つずつ処理していけば、11個でもいずれ終わります。
AIを使う場合も同じでした。
表でAIと対話しながら、裏で別のAIに調査させたり、テストを走らせたり、レビューをさせたりすることはできます。
複数の処理を並行して進めながらも、自分がその瞬間に向き合う対象は一つにする。
この状態を作れるようになってから、以前よりも落ち着いて仕事を進められるようになりました。
インターン前にやっておけばよかったこと
インターンに参加する前に、もっと資格や専門知識を勉強しておけばよかった。
最初は、そう思うのではないかと考えていました。
しかし、実際に一番やっておけばよかったと思ったのは、資格の勉強ではありません。
開発そのものの練習です。
特に、AIを使った開発の進め方です。
職場では、git worktreeを使って複数の作業環境を作ったり、subagentを使って調査・実装・レビューを並列化したりすることが珍しくありませんでした。
同じAIを使っていても、開発フローを知っている人と知らない人では、出せる速度がまったく違います。
たとえば、私が最初のタスクに現在の知識で取り組むなら、次のように進めると思います。
- 二つのリポジトリを同じ作業ディレクトリから参照できるようにする
- AIに両方のコードを読ませ、データの流れと変更箇所を整理させる
- 実装順序、二段階リリースの方法、PRの分割方針を先に決める
- 実装中は、別のセッションでレビューやテスト項目の洗い出しを進める
当時の私は、AIにコードを書かせることは知っていました。
しかし、AIを使って開発工程そのものを設計する発想が足りていませんでした。
AI時代には、「コードを書かせる技術」以上に、「どう仕事を分け、どこをAIに任せるかを考える技術」が重要なのだと思います。
ドメイン知識は、やはり必要だった
ここまで書くと、「では、細かい知識はすべてAIに聞けばよいのか」と思われるかもしれません。
私自身、一般的な技術であれば、名前と用途を知っていれば、AIとの対話を通してかなりのところまで進められると感じています。
一方で、専門的な判断が必要な場面では、知識不足がそのまま選択肢の少なさにつながりました。
データ抽出の精度改善が頭打ちになった際、社長からファインチューニングを提案されたことがあります。
しかし、学習データを準備するコストがかかり、実施したからといって必ず精度が上がるわけでもありません。
当時の私はLLMの学習や評価について十分な経験がなく、短期間で自信を持って実施計画を作れませんでした。
PMから固有表現抽出の導入を提案された際も、実装コストや検証期間を考えて見送ることになりました。
もちろん、見送る判断自体が間違いだったとは限りません。
ただ、自分に経験があれば、より具体的な工数を見積もり、選択肢として真剣に比較できたかもしれません。
AIは、知識の穴をかなり埋めてくれます。
しかし、自分の知らない選択肢を、常に完璧に提示してくれるわけではありません。
最後に判断するには、やはり基礎知識と実装経験が必要でした。
上司の時間を、しっかり奪う
これは、私が十分にできていなかったからこそ、強く残っている教訓です。
あるときPMから、「上司の時間をしっかり奪った方がいい」と教えてもらいました。
もちろん、何も整理せずに質問を投げ続けるという意味ではありません。
進捗、認識、優先順位、納期、困っていることを、丁寧かつこまめに共有するという意味です。
私は当初、「できるだけ自分一人で解決してから報告した方がよい」と考えていました。
しかし、長い時間悩んだ末に相談すると、そもそもの方向性がずれていることがあります。
一人で頑張った時間が、そのまま手戻りになることもあります。
周囲の仕事ができる人を観察すると、上司とのコミュニケーション回数が多いことに気づきました。
完成してから見せるのではなく、計画の段階で確認する。
問題が大きくなってから相談するのではなく、違和感がある時点で共有する。
納期に間に合わないと確定してから伝えるのではなく、怪しくなった段階で交渉する。
上司の時間を奪うことは、必ずしも迷惑をかけることではありません。
むしろ、チーム全体の手戻りを減らすために必要な仕事なのだと学びました。
AI時代に必要なのは、壁打ちする力かもしれない
これは、あくまで現時点での私の考えです。
これからも、研究を行えるほど深い専門知識は必要だと思います。
同時に、広く浅い知識の価値も以前より高くなるのではないかと感じています。
ああ、この技術は詳しくないけれど、たしかこういう用途に使えたはず
この程度の知識でも、AIとの壁打ちを始めるきっかけになります。
存在を知っていれば、AIに比較させたり、実装方法を調べさせたり、現在の課題に適用できるか検討したりできます。
逆に、技術の存在自体を知らなければ、AIに尋ねるための問いも生まれません。
重要なのは、何を知っているかだけではなく、曖昧な知識を起点に問いを作り、AIとの対話を通して具体化する力なのかもしれません。
私がインターンで最も学んだのは、特定のライブラリの使い方ではありませんでした。
- 分からないことを整理すること
- タスクを分解すること
- AIに渡す部分と、自分で判断する部分を区別すること
- 必要なタイミングで人に相談すること
結局、AIを使った開発でも、最後に問われるのは仕事の進め方でした。
週30〜40時間働いて思ったこと
長期インターンには、行けるのであれば行った方がよいと思います。
チーム開発の進み方、PRの出し方、コミュニケーションの取り方、リリースの考え方など、個人開発や大学の研究だけでは得にくい経験ができました。
スタートアップ特有のスピード感にも触れられました。
一方で、当たり前ですが、週30〜40時間働くとかなり忙しくなります。
研究や授業と両立するなら、時間だけでなく体力も削られます。
通勤もつらいです。
リモートワークは楽そうに見えますが、入社直後や認識合わせが必要な仕事では、私はむしろ難しさを感じました。
また、親切に教えていただいた先輩の契約終了も、想像以上に辛かったです。
会社では、人が入ることもあれば、去ることもあります。
それでも、周囲の学生やエンジニアから受けた刺激は非常に大きなものでした。
同世代で自分よりはるかに実装が速い人、研究と仕事を両立している人、自分から積極的に仕事を取りに行く人。
そうした人たちは、よい意味でライバルになりました。
インターンで得た一番大きなものは、技術力そのものより、自分の現在地が見えたことかもしれません。
結局、気合いとAIだった
この記事を雑に一言でまとめるなら、「結局、気合いとAIだった」になります。
ただし、気合いだけでは長続きしません。
AIだけでも、何を作るべきかは決まりません。
- 分からない仕事に手をつける気合い
- 一つずつ問題を分解する力
- AIを使って調査や実装を加速する工夫
- 抱え込まずに人へ相談する勇気
その組み合わせで、なんとか仕事を進めてきました。
入社当初の私は、初PRを1,000行以上にしてしまうような初心者でした。
今も、分からないことは大量にあります。
それでも、知らないプロジェクトのエラー対応を任され、11個の処理フローを改善し、少しずつチーム開発の進め方を覚えました。
最初からできる必要はありません。
目の前に来る剣は一つです。
一つずつ受けていけば、案外どうにかなるものだと思います。
最後に
最後まで読んでいただき、ありがとうございました！
今回が初めての記事執筆なので、面白く書けたか正直不安です。
今後は、私が気になった機械学習や数学系の記事を少しずつ書いてみようかなと思います！
機械学習、統計、Web、ネットワーク、GNNをはじめとするグラフ分野、数学、競プロなどの勉強会があれば、ぜひお誘いください！飛んでいきます。