コーディングAIの「探し物」を減らす。過去の対話から開発環境を整えるアプローチ

昨今のコーディングAI（AIエージェント）は非常に強力ですが、作業を任せていると「必要なファイルを見つけるのに何度も検索を繰り返している」「古い仕様書を読み込んで誤ったコードを出力する」といった場面に遭遇することがあります。こうしたAIの「探索のつまずき」は、作業時間の増加を招くだけでなく、意図しない実装を引き起こす原因にもなります。

これを解決するための実用的なアプローチとして、「過去のAIとの作業記録（セッション履歴）を振り返り、AIが迷ったポイントを特定して開発環境を整える」という手法が注目されています。本稿では、このアプローチの要点や具体的な改善例、そして実践する際の効果と限界について整理します。

過去の作業から「つまずき」を拾う

このアプローチの核となるのは、エンジニアリングにおける「ふりかえり」をAIの作業環境にも適用することです。教育者・エンジニアであるMatt Pocock氏は、直近のコーディングエージェントとのセッション履歴（例えば過去10回分など）を読み込ませ、「AIが関連情報を探すのに時間がかかった場所」や「古い文書に頼ってしまった場所」を分析させるというアイデアを提案しています。

AIがスムーズに作業できなかった箇所をあぶり出し、リポジトリ内のナビゲーション（ファイルの配置や誘導）を改善することで、次の作業環境を整えやすくするという考え方です。Pocock氏の見解によれば、こうした整理はトークンの節約にもつながると評価されています。

つまずきと改善先を結ぶ具体例

では、具体的にどのような「つまずき」を拾い上げ、どう環境を整えればよいのでしょうか。仮定のシナリオとして、いくつか具体的な例を挙げてみます。

仮の例1：ファイルの場所が分からず迷走する

つまずき: AIに「データベースのスキーマを変更して」と頼んだところ、リポジトリ内をあちこち検索し、無関係なバックアップファイルを開いてしまった。
改善先: AI向けの指示書やプロジェクトのルートにある説明ファイルに、「データベース関連の定義は必ず src/db/schema.ts を参照すること」という誘導を追記する（見つけにくいファイルへの道標を置く）。

仮の例2：レビュー時に毎回同じ指摘を受ける

つまずき: AIが生成したコードに対し、毎回「ここでは社内標準のユーティリティ関数を使って」と人間が修正指示を出している。
改善先: 人間の判断が必要な設計基準やコーディング規約は、レビュー向けのドキュメントとして明文化し、AIが参照しやすい場所に置く。一方で、機械的に判定できるインデントや型エラー、テスト要件などは、AIへのプロンプトで縛るのではなく、LintツールやCI、自動テストを導入してシステム側で弾くようにする。

これらの例のように、全プロジェクト共通の画一的なルールを作るのではなく、そのプロジェクトの実際の履歴に基づき、必要なナビゲーションやチェック機構をピンポイントで足していくのが特徴です。

実践方法と外部ツールの関係

実際にこの分析を行う場合、特別なツールがなくても、AIとの対話で自然文を用いて依頼することが可能です。ただし、AIは過去のセッションを自動的に記憶・把握しているわけではないため、分析対象となる過去の作業履歴（ログ）にAIがアクセスできる状態にしておく必要があります。会話へログ全文を貼り付けることは必須ではなく、ファイルを読む権限がある環境であれば、対象ログの保存場所や対象セッションを指定して取得させることも可能です。

たとえば、以下のような依頼の形が考えられます。

（過去の作業履歴テキストを添付する、またはログの参照先を指示して）
過去の作業記録を読んで、AIエージェントが情報の検索に手間取った箇所や、古い情報に依存してエラーを起こした箇所を特定してください。そのうえで、次回の作業でAIが迷わないようにするため、リポジトリの構造やドキュメントにどのような改善を加えるべきか提案してください。

なお、この一連の分析と提案を補助する仕組みとして、Pocock氏は自身のGitHubリポジトリ等で retro という外部スキルを公開しています。これは対象となるセッション履歴を読み込んで改善候補を提案してくれるものですが、あくまで氏が独自に作成した外部拡張スキルであり、各AIツールに標準装備されているコマンドではありません。また、このスキルであっても、実行環境に履歴へのアクセス権限がなければ過去のセッションを自動で読み込むことはできません。

効果と限界（トレードオフ）

このアプローチは非常に合理的ですが、実践にあたっては効果と限界を一緒に理解しておく必要があります。

効果の面では、AIのコンテキスト（一度に処理できる情報量）の最適化に役立ちます。Anthropic社の公式解説でも、コンテキストは有限の資源として扱うべきとされています。ファイルパスやWebリンクといった軽い識別子を手掛かりにし、必要時に必要な情報を読みに行かせる（Just-in-Time）方式は有効であり、リポジトリの階層や命名の整理は、その強力な手掛かりとなります。

一方で、以下のような限界や注意点もあります。

検索速度のトレードオフ: 必要な情報をその場で探索（Just-in-Time）させる方式は、必要なデータを事前取得してコンテキストに含めておく方式に比べ、探索の手間がかかり処理が遅くなるというトレードオフがあります。
提案の取捨選択が必要: 分析によって改善案が出ても、具体的な履歴の場面に結びつかない一般論であれば捨てるべきです。提案されたものをすべて採用するのではなく、人間が内容を判断し、承認したものだけを実装する必要があります。
順調な作業を邪魔しない: 作業がスムーズに進んだセッションに対して、無理やり新しいルールを作る必要はありません。
保守のコスト: 自動チェックやドキュメントを追加すれば、それを後から保守したり、不要になったら削除したりする判断が求められます。これは「一度設定すればAIが自動で環境を修正し続けてくれる」ような魔法の機能ではありません。

コーディングAIに気持ちよく働いてもらうためには、彼らが迷わず動ける「整った作業場」が必要です。過去の探索のつまずきを拾い、次の作業のために少しずつ環境を整備していくこの取り組みは、結果として人間にとっても見通しの良いプロジェクトを作ることにつながるはずです。

あとがき

今回紹介した「retro」の考え方は、さっそく自作スキルの「hansei（反省）」にも盛り込んでみようかと思います。

参考

この記事は Gemini Pro が執筆しました。