最も難しかった開発経験

Baseconnectは、企業情報のデータベースを提供しています。WebページやPDFなどの公開情報から、企業、部署、人物、連絡先の情報を抽出・構造化し、顧客に届けています。本番パイプラインは収集、抽出、検証、保存の工程から成り、モデルを使う抽出処理も組み込まれています。

2026年からAIエンジニアのインターンとして、企業情報の抽出品質の改善に携わっています。抽出漏れや誤抽出、データの誤りの原因を調べ、データ生成パイプラインのコード修正、評価方法の設計、既存データの修正を進めています。S3に保存されたデータは、顧客に直接提供する本番データです。このデータを使ってパイプラインを調査・修正するため、自分用の作業環境も整えました。コードを変更した際は同じデータで検証し、PRを作成します。既存データの修正も、私が本番環境で直接実行しています。

インターンを始めた当初は、稼働中の本番パイプライン、初めて扱う業務データ、大量の既存コードを理解する必要がありました。Claudeで調査・開発を進める中で、会話が終わると調査結果を引き継ぎにくく、コード案が業務の要件に合わないこともありました。そこで作業を九つの段階に分け、各段階で誰が何をするかを決めました。

九つの段階のうち、五つは私による判断・実行、二つはAIへの依頼、二つは記録に当たります。AIが調査と実装を支援し、私が課題を定義して、妥当性やリスクを判断し、最終的に結果を検証します。その後の開発、レビュー、検証も、この手順に沿って進めています。

記録は三か所に残します。まず、変更前に受け入れ基準をMarkdownファイル（.md）へ書きます。対象、比較用サンプル、保護する正常データ、新しい処理の動作をログで確認する方法を定めます。次に、検証結果をPRのコメントにまとめます。変更前後の比較、正常データへの影響、処理が動いた記録を、レビュー担当者と後から読む自分が確認できるようにします。さらに、調査、dry-run、本番実行、実行後の確認をダッシュボードとログに記録し、新しいAIセッションの開始時に読み込んで作業を続けます。

先に基準を決めておくと、検証で確かめることが明確になります。経緯をまとめておけば、次の会話で説明し直す手間も減らせます。レビュー担当者が根拠を確かめられ、新しいセッションでも作業を再開できるように、記録の残し方を整えました。

旅行会社では、業務要件を整理し、開発担当者と日程を調整してテストを進めました。自分のスタジオでは、繰り返す業務を手順にまとめ、カスタマーサポート担当者と分担しました。こうした経験を生かし、インターンでも一つのチケットを「タスク → 処理バッチ → 各段階の実施記録」に分けています。進行中のバッチには、次の作業、担当者、関連PR、資料のパスを記録します。コードのマージ、dry-run、本番実行、実行後の確認を別々の段階として管理し、どこまで進んだかを把握しています。

データの比較では、同じ対象を安定した業務上のキーで結び、バッチごとの結果を追えるようにしています。比較の前に対象範囲と環境がそろっているかを確認し、条件が異なる結果は分けて扱っています。

AIと長期の作業を進めるうちに、四つの課題が繰り返し現れました。過去の判断や手順が抜けること、調査・検証結果が会話ごとに散らばること、人が経緯を覚えて説明し直す必要があること、文脈が増えるほどコストと不要な情報も増えることです。そこで、データベースを備えた自分用のダッシュボードをつくりました。タスクと処理バッチの状態、PRの受け入れ状況と基準のチェックリスト、検証結果と問題分類、作業ログ、誤りを検出するルールの状態と推移、新しいセッションで再開するための情報を保存しています。

AIの支援を受け、Python標準ライブラリのHTTPサーバー、ローカルデータベース、HTML/JSの画面で実装しました。判断や統合の支援には高性能なモデル、調査や繰り返し作業には軽量なモデルを使っています。人とAIが同じ記録を参照しながら進められるよう、毎日使って改良を重ねています。

S3に保存され、顧客に直接提供する本番データには、部署名の混在、人物と所属の対応誤り、役職分類の不一致などが生じることがあります。既存データを修正するとともに、パイプラインのどの処理で誤りが生まれたかを調べ、同じ問題が繰り返される原因にも対応します。

既存データと、誤りの発生源をそれぞれ修正しました。既存データについては、誤りの種類ごとに修正処理をtransformへまとめ、再利用・改善できるようにしました。dry-runとバックアップを備え、修正するデータと、一見不自然でも業務上正しいため残すデータを区別しています。発生源については、同じ修正方針を本番パイプラインの抽出・検証・保存の該当箇所に反映するPRを作成しました。新しい形の問題が見つかった際も、既存のtransformにルールを追加し、検証しながら改善できます。

本番環境でのデータ修正は、私が実行しています。dry-runで差分を確かめ、バックアップを取ってから本番で実行し、結果を確認します。検証結果はPRとタスクの記録に残します。この手順で、1.5か月に38件のデータ修正タスクを解決しました。

チームでは誤りを分類し、同じ種類の誤りを検出すると、アラートとタスクが生成されます。私は既存のtransformをそのまま使えるか、改善してから実行するかを判断し、本番パイプラインの該当箇所も修正します。実行前にはバックアップを取ります。失敗時はバックアップから復元する想定ですが、これまで復元が必要になる失敗は発生していません。

3か月、約320時間で作成した190件のPRが、同僚のレビューを経てマージされました。このうち後半の1.5か月、約180時間はデータ修正に集中的に取り組み、38件のタスクを解決しました。取り組みの中で、特定のデータ項目の精度は40％台から85％に、データカバー率は30％台から75％に改善しました。修正の根拠と検証結果は、ダッシュボード、受け入れ基準を記したMarkdownファイル（.md）、PRのコメントから確認できるようにしています。

数値は、2026年10月時点の本人の業務記録をもとに集計しています。

この経験では、繰り返す作業の進め方を整え、使いながら改善できるツールにまとめることを大切にしました。九つの段階で作業を進め、判断と検証を記録し、タスクを進捗の追えるバッチに分けました。データの修正方法はtransformにまとめ、本番パイプラインにも反映しました。CorpLink-AI、自分用のダッシュボード、日常で使う三つのアプリも、同じ考え方からつくっています。過去の記録や判断を次の作業に生かし、繰り返す手間を減らしたいと考えています。