はじめに
AIを使った開発で、リポジトリ内の依存環境について最新情報を確認するためのコンテキストを作りました。
最初の目的はシンプルで、
- 利用中の依存環境を把握する
- 外部の最新情報と照合する
- サポート終了や非推奨化などの懸念を洗い出す
というものでした。
ただ、実際に使ってみるとそれ以上に、
- 新規参画時の環境棚卸し
- 資料にない前提条件の発見
- 口頭で共有されていた事情の明文化
- 属人化した知識の発見
- 現在の構成理由そのものの再確認
に役立ちました。
この記事では、この仕組みを 依存環境クロールコンテキスト と呼び、その構成と副次的な効果をまとめます。
このコンテキストの理想としては定期的な実行ですが、本題と逸れる事と情報システム部の意向次第ではGithubとの連携などもできないケースがあるため、この記事ではCursor Automationsなどには言及しません。
最初にAIへ依頼した内容
実際の依頼内容を抽象化すると、次のようなものでした。
定期的な依存関係チェックのためのクロールコンテキストを作成する。
依存環境の最新情報を確認する際は、
実施内容を提示して実行確認を取った上で調査する。
調査対象:
- 過去のクロール結果
- 別ブランチ、未マージPR
- 利用中の主要フレームワークやエンジン
- 各プラットフォーム向けSDK
- 外部SDK
- 社内ドキュメント
- インターネット上の公式情報
実行ごとに日時単位で結果を保存する。
出力:
- 最新情報や変更点
- 懸念事項、警告事項
各項目には、
- 人間が対応内容や備考を書く欄
- AIまたは人間が後続対応を書く欄
を用意する。
人間用の欄にはAIは記入しない。
次回の調査では、
過去の調査結果と対応履歴も参照する。
ポイントは、単発の検索結果ではなく、前回までの判断も次回のコンテキストへ戻すようにしたことです。
何を作ったのか
やりたかったことは、
リポジトリ内で前提になっている環境と、リポジトリ外の現在の状況との差を定期的に確認する
ことです。
対象は、たとえば次のようなものです。
- フレームワーク / ゲームエンジン
- 外部SDK
- モバイルOSやプラットフォームSDK
- ビルド環境
- 外部サービスやAPI
- 社内ドキュメント
- 関連する別ブランチや未マージPR
重要なのは、「最新版かどうか」だけを見ることではありません。
実際のプロジェクトでは、
- 互換性の都合で特定バージョンを維持している
- 大きな更新は特定のタイミングでまとめて行う
- 過去の不具合を理由に更新を止めている
- 別の対応が終わるまで更新できない
といった事情があります。
そのため、知りたいのは単純な新旧ではなく、
なぜ現在この状態なのか、その理由が今も有効なのか
です。
コンテキストの構造
厳密な処理順序よりも、見るべき情報をグループ化しておく方が扱いやすかったです。
[現在のプロジェクト]
- リポジトリ
- 設定ファイル
- 別ブランチ
- 未マージPR
+
[外部・周辺情報]
- 公式ドキュメント
- Release Notes
- Migration Guide
- Support Policy
- 社内ドキュメント
+
[過去の判断]
- 過去のクロール結果
- 人間の備考
- AI / 人間による対応履歴
↓
[今回の整理]
- 最新情報
- 懸念事項
- 警告
- 要確認事項
↓
[履歴として保存]
次回のクロール時に再利用
単なるWeb検索ではなく、
現在の実装 + 外部の現在値 + 過去の判断
を同時に見る構成です。
既存の近い考え方と比べる
今回の仕組みに完全に一致する定番名称は、少なくとも調べた範囲では見つかりませんでした。
一方で、部分的に近い考え方はいくつかあります。
Dependency Drift / Dependency Freshness
概要
現在利用している依存と、最新安定版との差を把握する考え方です。
libyear では、利用中の依存のリリース時点と最新安定版との差を時間として計測し、依存環境がどれだけ現在から離れているかを可視化します。
相違点
今回のクロールコンテキストでは、古いこと自体を問題とはみなしません。
たとえば古いSDKを使っていても、
- 他SDKとの互換性
- 更新時期をまとめる運用方針
- 過去に発生した不具合
- 現在進行中の移行作業
などを理由に、意図的にその状態を維持していることがあります。
そのためバージョン差は、警告そのものではなく、
なぜ現在この状態なのか
を確認する入口として扱います。
参考
Software Composition Analysis（SCA）
概要
ソフトウェアが利用しているOSSなどの構成要素を解析し、
- 脆弱性
- ライセンス
- 更新状況
などを確認する仕組みです。
依存関係を機械的に棚卸しし、リスクを継続的に確認する用途で使われます。
相違点
今回のクロールコンテキストでは、依存パッケージそのものだけでなく、
- 社内ドキュメント
- 別ブランチ
- 未マージPR
- 過去の人間による判断
- 更新を見送った背景
まで参照します。
そのためSCAよりも、プロジェクト固有の事情を含めて判断材料を集めることを重視しています。
参考
- IBM: Software Composition Analysis
https://www.ibm.com/think/topics/software-composition-analysis
Architectural Fitness Functions
概要
アーキテクチャとして守りたい性質を、継続的かつ客観的に検証するための考え方です。
たとえば、
- 特定方向の依存を禁止する
- 循環依存を許さない
- 性能を一定値以下にしない
といった条件を、CIなどで継続確認できます。
相違点
今回のクロールコンテキストでは、最初から正解を定義できないことが多くあります。
このSDKは古い
という事実だけでは、違反とは限りません。
まず、
なぜ現在このバージョンなのか
を確認し、その事情が現在も有効かを見る必要があります。
そのため、自動判定するガードレールというより、人間が判断すべき疑義を集める仕組みに近いです。
参考
- Continuous Architecture: Fitness Functions
https://www.continuous-architecture.org/practices/fitness-functions/
Context Engineering
概要
AIが適切に判断できるように、必要な情報を収集・整理・構造化して与える考え方です。
単一のプロンプトを書くことよりも、
- どの情報を集めるか
- どの順序や形式で渡すか
- 過去の判断をどう保持するか
- どの情報を更新し続けるか
といった、AIが利用する文脈全体の設計を重視します。
相違点
Context Engineering は非常に広い概念で、依存環境の監視自体を指すものではありません。
今回のクロールコンテキストは、その具体的な適用例として、
現在のリポジトリ
+
外部の最新情報
+
並行して進んでいる変更
+
過去の人間の判断
をAIへ与え、
今、確認すべきことは何か
を判断できる状態にしています。
そのため、新しい名称を付けるよりも、
Dependency DriftやSCAのような依存環境チェックを、Context Engineeringによってプロジェクト固有の事情まで広げたもの
と説明するのが、現時点では一番近いと考えています。
参考
- Google Cloud: Context Engineering
https://cloud.google.com/discover/ai-context-engineering
実際に使って分かった副次的な効果
新規参画時の環境棚卸しになる
新しく参画したプロジェクトでこのコンテキストをセットアップすると、AIはまず、
このリポジトリは何に依存しているのか
を調べる必要があります。
その過程で、
- 使用フレームワーク
- SDK
- 外部サービス
- ビルド環境
- 関連リポジトリ
- バージョン固定箇所
などが自然に洗い出されました。
結果として、依存関係チェックの準備そのものが、新規参画者向けの技術構成調査になりました。
明文化されていない事情が出てくる
初回クロールでは、
「なぜこの構成になっているのか分からない」
という疑義がいくつか出ました。
既存メンバーに確認すると、
昔この問題があったので、今はこの構成にしている
といった回答が返ってくることがあります。
チーム内では共有されていても、資料には残っていない情報です。
これは、AIが事情を知らないからこそ出てくる疑問でもあります。
その疑問をきっかけに、複数人の頭の中に分散していた事情を、
「現在この構成である理由」
という1つの項目へまとめて残せるようになりました。
ここは、この仕組みで最も有用だった部分の1つです。
「最新版へ上げるべきか」ではなく「今の判断を説明できるか」
この仕組みは、最新版への更新を促すためのものではありません。
プロジェクトごとに事情があり、最新版を使えないことや、必要なタイミングでまとめて更新することは普通にあります。
問題なのは、その判断が、
- 誰かの記憶にしかない
- 口頭でしか共有されていない
- 理由は知られているが資料に残っていない
状態になっていることです。
クロールで疑義が出ると、既存メンバーは、
なぜ今は更新しないのか
を説明することになります。
その回答を人間用の備考欄へ残すことで、
散らばっていた暗黙知を「この依存についての現在の判断」という単位にまとめられる
ようになりました。
属人化の発見にもなる
AIからの疑義に対して、
「この理由は○○さんしか分からない」
となれば、それ自体が属人化の発見です。
通常、属人化は担当者が不在になってから問題になることがあります。
この方法では、
現在の構成を第三者へ説明できるか
という観点から、先に見つけられます。
理由を説明していたら、構成自体を見直すこともあった
さらに、
なぜ現在この構成なのか
を整理している途中で、
その理由は今も有効なのか？
という話になることもありました。
過去には合理的だった判断でも、
- 当時の制約がなくなった
- SDK側の問題が解消した
- プラットフォーム仕様が変わった
- 別の選択肢が使えるようになった
といった変化があります。
その結果、
現在の構成理由を確認
↓
過去の事情を明文化
↓
その事情が現在も有効か確認
↓
必要なら構成そのものを見直す
という流れが生まれました。
依存関係のチェックが、過去の技術判断を再評価するきっかけにもなっています。
人間専用の記入欄を分ける
出力には、人間だけが記入する欄を用意しました。
### 外部SDK A
AI調査:
現在利用しているバージョンについて、
今後のサポート方針に変更あり。
懸念:
将来的なプラットフォーム更新で影響する可能性あり。
人間による対応・備考:
<!-- AIは記入しない -->
対応履歴:
これは、
- AIが調査した事実
- AIが出した懸念
- 人間が確認した事情
を混ぜないためです。
AIに「おそらくこういう理由だろう」と補完させると、後から見たときに事実と推測の区別がつきにくくなります。
人間の判断だけは明示的に分離しておく方が、履歴として使いやすく感じました。
過去の結果も次回に使う
クロール結果は上書きせず、実行単位で残します。
context-drift/
├─ 2026-01-10/
│ ├─ information.md
│ └─ warnings.md
├─ 2026-02-10/
│ ├─ information.md
│ └─ warnings.md
└─ 2026-03-10/
├─ information.md
└─ warnings.md
これによって、
- 前回は問題なし
- 今回サポート終了予定が発表された
- 人間が対応方針を記入した
- 次回は対応済みか確認する
という形で、警告一覧ではなく判断の履歴として使えます。
まとめ
最初は、
AIに依存環境の最新情報を定期的に確認させる
ためのコンテキストでした。
しかし実際には、
- 依存環境の棚卸し
- 外部環境とのズレの検知
- 暗黙知の明文化
- 属人化の発見
- 過去の技術判断の記録
- 現在の構成理由の再確認
- 構成そのものの見直し
までつながりました。
特に有用だったのは、
AIが疑問を出せる状態にすることで、人間側が「説明していなかった前提」を発見できる
ことです。
この意味で、単なる Dependency Checker というより、
プロジェクト内の前提と外部環境の現在とのズレを、AIが確認できる形に整理した依存環境クロールコンテキスト
と捉えると、用途を説明しやすいと感じています。
AIへコンテキストを与えるために環境を整理した結果、人間にとってもプロジェクトの前提が整理される。
この副作用は、当初想定していた以上に大きなものでした。