社内提出に備え、学習ツールから私的な抽出コードを切り離す設計
今回やったこと
一般公開しない学習ツールを社内へ提出する可能性に備え、提出物を汎用コアに絞る方針を整理した。特定サービス向けの抽出処理や私的なアダプタは除外候補とし、クリーンな別リポジトリへ移す想定である。実際の提出や分離が完了したという記録ではない。
実装ステータス
構想段階。ここでは記録された提出範囲の方針を説明する。ファイル一覧は候補であり、移行済みの成果物として扱わない。
提出物の境界を先に決める
開発中のリポジトリには、ツールの中心機能だけでなく、特定の入力元を扱うコード、作業用の手順、個別環境に依存する仕組みが一緒に置かれることがある。社内提出のように共有範囲が変わるとき、リポジトリ全体をそのまま渡すのではなく、何を汎用コアとして残すかを先に決める必要がある。
記録された除外候補は parse_cloudtech.py、scripts/extract.js、scripts/udemy_extract.js、scripts/relay_server.py、docs/EXTRACTION.md である。これらは私的な抽出アダプタや特定製品向けの処理に関わるものとして整理されている。一方、残す候補には build_quiz.py、bank_common.py、dedup_report.py、retire_report.py と samples/ が挙がっている。
| 扱い | 記録された候補 |
|---|---|
| 除外候補 | parse_cloudtech.py, scripts/extract.js, scripts/udemy_extract.js, scripts/relay_server.py, docs/EXTRACTION.md |
| 残す候補 | build_quiz.py, bank_common.py, dedup_report.py, retire_report.py, samples/ |
| 汎用化が必要 | SET_META |
これは提出準備のために記録された候補一覧で、監査済みの最終マニフェストではない。各ファイルが提出時点でも存在するか、依存関係が残っていないかを確認する作業は別途必要になる。特に SET_META は汎用化が必要な対象として明示されているため、そのまま残せるとは限らない。
クリーンな別リポジトリを想定する
提出物を元の開発環境からそのまま渡すのではなく、クリーンな別リポジトリへ移す想定が記録されている。これは、除外ファイルを個別に消したつもりでも、履歴や設定、周辺資料から元の用途が残る可能性を考慮した境界設計として読める。ただし、実際にどの移行方法を採用するかや、履歴をどう扱うかまでは素材に記載されていないため、具体的な手順として断定しない。
この方針で解決したいのは、提出物に私的な抽出アダプタや特定製品向けコードを含めないことだ。一方、ファイル名だけを見て安全性を判断することはできない。汎用コア側から除外候補への依存がないか、設定やサンプルに固有情報が含まれないかを確認する必要がある。こうした確認は、素材にある提出方針を実作業に移す段階で必要になる検討事項であり、完了済みの検査結果ではない。
実施済みと構想を混ぜない
提出の可能性に備えて境界を考えたことと、実際にコードを分離して提出したことは別の状態である。現時点で確認できるのは、残す候補・除外候補・汎用化対象と、クリーンな別リポジトリを想定する方針までだ。移行完了や社内提出を示す事実はない。
共有範囲が変わる可能性があるツールでは、機能開発と並行して提出単位を考えておくと、後から不要なコードを切り分けやすい。ただし、境界を決めただけで漏えい防止が完了するわけではない。実際に提出するときは、対象ファイルとその依存を確認し、方針どおりの構成になっているかを別途検証する必要がある。
更新履歴
- 2026-09-27: 初稿を作成。