腾讯エンジニアが AI で老朽プロジェクトをリファクタリングする手法を公開

「胡言乱语」から正確なコードへ：AI に古いプロジェクトを読み込ませる方法

腾讯プログラマーによる寄稿 | 2026年8月7日 17:36 発表（広東）

実務の負債を抱えたプロジェクトを、AI がメンテナンス可能な形へリファクタリングする

作者：被删

AI 時代の新たな役割：AI の世話役。

AI が強力になった現在でも、多くの人は「AI は新プロジェクトの迅速な開発には向いているが、重厚な歴史資産を抱えた既存プロジェクトでは大きな力を発揮できない」と考えています。

ここ半年ほどはプロジェクトのリファクタリングに注力してきました。初期段階では AI を活用しても難航しましたが、現在は AI が問題を効率的に特定し、プロジェクトのニーズに即した最適なソリューションを提示できるようになりました。この劇的な転換点となったのは、プロジェクト向けに AI 用のコンテキスト（文脈）エンジニアリングを構築し始めた時です。

もちろん、この一年で AI の能力自体も飛躍的に向上しました。また、私のリファクタリング努力により、プロジェクトの品質やアーキテクチャの合理性も着実に高まっています。しかし、AI 用のコンテキスト整備が果たした役割は極めて重要でした。

本稿では、リファクタリングの過程で、以前は AI が胡散臭い回答を繰り返していた状況をどう変え、今では AI が効率的にプロジェクトを支えるパートナーとなったのかについてお話しします。

思考：AI による生産性向上とは、いったい何を向上させているのか？

過去一年間で AI の能力は劇的に進化しました。当初は明確な小タスクしか処理できませんでしたが、現在は問題の特定や実行可能なソリューションの提案、さらには自己の実行とテストまでを支援できるようになり、私たちの業務における関与度が高まっています。

現在では多くの新事業が「AI ネイティブ」プロジェクトとして始動しており、企画からリリースに至るまで開発者が一行もコードを書かずに、すべて AI が完結させるケースすらあります。

しかし、AI の能力がどれほど強力になったとしても、共通認識として「歴史債務（技術的負債）の蓄積が深刻な既存プロジェクトでは、AI の活用は限定的であり、開発者の深い関与が必要である」という考え方が根強く残っています。

その大きな理由の一つは、「AI が持つコンテキスト知識が不足している」ことです。

ビジネス上のボトルネックは往々にしてコンテキストの欠如に起因します

実は AI と開発者に本質的な違いはありません。決定的な差は、私たちが AI よりも豊富なコンテキストを持っている点にあります。そのコンテキストとは以下のようなものです。

・事業の歴史的背景や、プロジェクト全体の協業体制（他モジュールとの関係性など）

・過去の要件定義書や技術仕様書（これらは別ファイルに保存されているか、開発者やプロダクトマネージャーの頭脳の中に存在します）

・実際の稼働状況：どのブランチの機能が現在も動いているのか、あるいは単なる後方互換性のために残された機能で実際に実行されることはないのか

・アーキテクチャ設計と技術的負債の現状：どの技術改修が中途半端に終わっているか、完全なリファクタリングが未完了であるかなど

これらの課題は、AI であれ新規参入した開発者であれ直面するものです。私たちが過去に行ってきた「規範の策定」「ドキュメント作成」「汎用化・プラットフォーム化」などの活動は、すべてこれら対接やコミュニケーションのコストを削減するためでした。

現在では多くの人が AI にコード記述を任せることで、開発コストは大幅に低下しました。しかし今、私たちが直面しているのはむしろ「コミュニケーションと協業のコスト」です。人間同士の間でそうであるように、人間と AI の間でも同様の課題が生じています。

リファクタリングを通じて、AI が維持可能なプロジェクトへと変革する

さて、改めて「AI による業務効率化」とは具体的に何を指すのでしょうか。

過去一年で AI は多くの業務に組み込まれ、開発プロセスの効率化に貢献することは間違いありません。しかし、その役割はそれだけではありません。問題の特定やシステム現状の分析、技術方案の設計と実装、コードレビューなど、AI が担える範囲は広がっています。現在、多くの人が AI をより深く活用しようとしていますが、依然として対象となるのは AI 原生で生まれた新プロジェクトに限られるケースがほとんどです。

旧来の事業と新規事業の違いは、AI に提供できる「文脈（コンテキスト）」の充分さにあります。技術負債が多く維持コストが高い既存プロジェクトこそ、AI を活用したリファクタリングに適しています。リファクタリングの過程で AI に対して十分な文脈情報を段階的に蓄積していけば、最終的には AI がメンテナンス可能なプロジェクトへと生まれ変わります。

これまでのリファクタリングの理由は、大きく分けて三つでした。すなわち、アーキテクチャ設計が業務の拡張に対応できなくなったこと、技術負債が深刻化して専門的な対策が必要になったこと、そして新規参入者が既存のコードを自分の流儀で書き直そうとしたことです。

現在のリファクタリングは、プロジェクト内の既存課題を解決するだけでなく、AI が日常的なトラブルシューティングや機能拡張、アーキテクチャ最適化に参加できるようにするための文脈情報を整備することが目的です。これにより、開発者は高コストな維持作業や繰り返しのコミュニケーションから解放され、真の意味でのプロジェクト効率化が実現します。

AI 向け文脈情報の構築

私は昨年末からプロジェクトの技術負債の整理に取り組み始めました。今年に入り AI の能力は飛躍的に向上しましたが、依然として判断ミスが発生することがあります。

判断が誤る原因の一つに、アーキテクチャの過剰設計や、設計段階では想定していた実装プロセスが実際には変形してしまっていることが挙げられます。さらに深刻なのは、コード上では存在するものの実際に実行されていない「生きた」コードが存在することです。開発者も AI も、コード内の参照関係だけではそれが本当に動作しているのかを判断できません。なぜなら、コード上には正しい参照があるにもかかわらず、実際の稼働時にはそのパスが一度も通らないケースがあるからです。

こうした文脈情報は、AI 以外からは入手が困難な場合が多く、開発者自身ですら把握できていないことが珍しくありません。

長年のプロジェクトにおいて、文脈情報の維持は常に業務上の痛点でした。チームのナレッジ構築は重要ですが、その価値を可視化しにくいことから、コスト対効果などの理由で、多くのチームが知識基盤の整備に着手できず、むしろ技術力が高いチームほど「コードを読んで自分で解決する」というスタイルを好む傾向さえあります。

開発者はドキュメント作成や閲覧を嫌がり、細かな情報や協業の内容は各自の頭の中に留め置かれます。情報の非対称性や欠落が協業プロセスでのズレを生み、アーキテクチャ設計や技術方案が当初の意図通りに完遂されないことも多々あります。

私たちが過去に推進してきた「機能コンポーネント化」「プラットフォーム化」「汎用化」の目標は、すべて開発・維持コストの削減にあります。開発者が合意した規範やプロトコルを強制することで、それらが協業における文脈情報として機能するのです。

AI と協働する場合も同様です。開発コストが AI によって劇的に低下した現在、業務効率のボトルネックは「人間同士の協業」や「人間と AI の協業」に生じています。チームドキュメントやナレッジを整備するのは人間同士の協業を減らすためですが、AI 向け文脈エンジニアリングを構築する目的は、「同じ内容は一度だけ AI に伝えれば十分」という状態を作ることです。

AGENTS.md から始める

AI の文脈知識を蓄積する最もシンプルな方法は、静的な文脈から始め、コードリポジトリに紐付く「AGENTS.md」を作成することです。

ただし、AI が扱える文脈には限界があります。そのため、プロジェクト情報をドメインごとに分割し、重要な内容のみをプロジェクトのルートディレクトリにある AGENTS.md に配置する必要があります。例えば：

知識インデックス

各分野の知識は、どこで入手すべきかを記述します。具体的には以下のような項目です。

• ビジネス背景に関する知識
• アーキテクチャ情報と技術ソリューションの蓄積
• 汎用コンポーネントおよび規範
• 外部連携システムの情報
• その他、業務に関する各種規範など

要件

• AI がコードを自動生成・提出する際、コミットメッセージは必ず | pub で終わらせます（これはプロジェクトリポジトリの規範です）。

知識の定着化規範

• ルートディレクトリの AGENTS.md と CLAUDE.md には、索引概要（パスと 1〜2 文の要約）のみを記載し、詳細な記述はここに積み重ねないこと。
• 会話の中で再利用可能なルール、互換性に関する知見、トラブルシューティングの結論、あるいはプロジェクト固有の知識が明らかになった場合は、必ず該当するモジュール内の AGENTS.md に記録し、同時にルートディレクトリの AGENTS.md と CLAUDE.md における知識索引も更新すること（内容は各モジュールの内容を基準とする）。
• 知識索引に内容の陳腐化や不正確さが認められた場合は、自ら修正するか、新しい AGENTS.md を作成して対応する。これは簡単な一歩です（yuankai さんの積極的な共有への感謝を込めて）。

AI と共に業務リファクタリングを進める

現在、AI の能力は飛躍的に向上していますが、それでも「コードが動いているなら手を出さない」という考えから、多くの業務でリファクタリングが先送りされています。この歴史的教訓は、依然として多くの人々の判断に影響を与えています。

もしその業務がすでに更新を停止している状態であれば、大きな問題にはならないかもしれません。しかし、プロジェクトが急速に進化し続けているのであれば、AI 対応可能な形へリファクタリングを進めておくべきです。そうすれば近い将来、より多くの作業を AI に任せる体制を整えることができるようになります。

まず、私たちが取り組んでいる教育向けミニプログラムプラットフォームについて簡単に紹介します。このプラットフォームは、教育現場向けの「プロジェクト制作＋カリキュラム提供＋ミニプログラムの体験・公開」を統合したシステムです。教育コンテンツの生産から学習プロセス、プロジェクト開発、作品の体験と公開管理に至るまでを一貫してサポートする仕組みで、主な機能は以下の通りです。

• 自由創作／AI コーディング：ミニプログラムのプログラミング、コンパイル、プレビュー、公開、および AI を活用したコーディング支援
• カリキュラム学習・制作：プロジェクトベースの学習やカリキュラム作成、能力設定。ミニプログラムプレビュー、リッチテキスト編集知識パネル、コードエディタ、AI 対話機能、クイズなど多様なコンテンツセクションを含む
• リソース管理：学校・クラス・学生アカウント、ミニプログラムの管理、クラウド開発および混元（Hunyuan）リソースの統括

image自由創作（コード編集＋ミニプログラムプレビュー＋AI 対話＋コードバージョン管理＋素材ライブラリリソース管理）

imageシステムの複雑さは、大きく 2 つの側面に分類されます。

フロントエンドの WEB アプリケーション自体が抱える複雑さには、業務上の複雑なインタラクション設計（例：コース学習や自由創作、コース制作といった複雑なセクションでは、横画面・縦画面への対応、ドラッグによる調整、アニメーション効果などの多様な要件を同時にサポートする必要がある）が含まれます。さらに、機能の高度な結合も課題です。複数の複雑なインタラクションページ間のロジックが if/else 文で無理やり分離されているケースがあります。また、一部には過度な設計による技術的複雑さもあります。例えば、コードエディタに OT（Operational Transformation）協働機能をサポートさせることで、実装の複雑さが大幅に増大しました。

このプロジェクトでは、WEB 以外のモジュールも多数関わっています。一般的なバックエンドモジュールに加え、シミュレータープレビュー用のコードコンパイルモジュール、プロジェクト管理やコード取得を担う Node モジュール、AI Agent モジュール、課金機能モジュール、そして腾讯云や混元といったサードパーティのサービス連携など、多岐にわたる要素が絡み合っています。

最も複雑な「自由創作」「コース学習」「コース制作」ページについて、過去半年のリファクタリングを AI 分析で可視化したものが以下の通りです：

imageimage

AI もこの複雑さの中で効果的に動作できるようにするためには、AI を活用して既存の設計と実装プロセスを再構築する必要があります。

では、AI に「何をすべきか」をどう教えるのか。答えはシンプルです。「我々がどのように行うか」を AI に示せば、AI はそれを実行します。ただし、AI がコードを自己流で読み解いて理解しようとするだけでは不十分な場合が多く、初期段階では人間による適切な誘導が不可欠です。

一、プロジェクトから不要になったコードを削除する

技術的負債の多い業務システムにおいて、最も混乱を招くのは「実際には機能していない」コードが多数存在することです。私たちのプロジェクトもその典型例です：

• 純粋な WEB プロジェクトであるにもかかわらず、古いクライアント向けの互換性コードをコピー＆ペーストして改造した結果、環境判定のための if/else ブロックが無数に残っています。
• コードエディタには OT 協働機能が設計されていましたが、実際の実装では HTTP リクエストによる同期のみで、協働機能は実装されませんでした。
• 一時期 WebIDE へのアーキテクチャ変更を試みましたが実現せず、その名残としてモジュール間で N 種類もの非整合的なメッセージ通信方式が混在しています。
• AI Agent 機能は当初 WEB アプリ内で実装されていましたが、現在は独立した Node モジュールへ移行済みです。しかし、フロントエンド側では新旧の処理経路が複雑に絡み合い、どのコードが実際に有効なのかを判別することが困難になっています。

これらの技術的負債は開発者にとって負担となるだけでなく、AI にとっても大きな障壁となります。なぜなら、単に「コードが参照されているか」だけで実効性を判断できないからです。一部の条件分岐は環境変数に記述されており、同じプロジェクトの開発者であっても正確な挙動を把握するのが難しいケースさえあります。

しかし、これらの負債を整理・解消する過程で、AI を活用して参照されていない不要コードを素早く特定し、実際のシステム動作やチームメンバーからのヒアリング情報を組み合わせながら、AI と協力してリファクタリングを進めることができます。同時に、そのプロセスと知見を AI に学習させることも可能です。

「汚い山」の整理における第一歩は、「コードが実際に動く状態」と「コードの外観」を一致させることです。

二、複雑なアーキテクチャをシンプルにするための「引き算」

実は多くのビジネスにおいて、それほど高い複雑さは必要ありません。しかし実際の開発現場では、過度な設計が至る所に散見されます。そして何より恐ろしいのは、一度過度に設計したものを完全には改修できず、さらに数回にわたる不十分なリファクタリングの末に、多くの過去の負債（デッドコードや技術的負債）が残ってしまうことです。

プロジェクトへの参画が増えるにつれ、私はこの事柄をより深く理解するようになりました。アーキテクチャ設計が重要なのは、それが高級そうに見えるからではなく、複雑さを抑制できるからです。

例えば先ほど挙げた例では、OT（Operational Transformation：協同編集）によるコードの同時編集機能を実装しましたが、実際のビジネスシーンには協働のニーズはなく、可視な未来においてもそのような需要は存在しません。

これは「複雑さのために複雑さを追加する」という過度設計の典型例です。多くのプロジェクトで見られる現象ですが、「シンプルにする」よりも「複雑にする」方が価値があるように見えてしまう傾向があります。私はこの考えには賛成しませんが、理解はできます。

私たちは設計段階で将来の事業拡大を過剰に考慮しがちですが、実践してみると、ビジネスの変化は想像とは大きく異なることがほとんどです。優れたアーキテクチャとは、現在の状況に根ざし、業務の変動に応じて柔軟に調整できるものです。

コード編集における協働機能のリファクタリングでは、以下の 2 段階で実施しました。

• リファクタリングステップ：コアとなる改修点 / AI の役割 / AI のパフォーマンス
• 第 1 回リファクタリング：OT と WebSocket を停止し、HTTP による更新送信と定期ポーリングへ移行 / 補助的な最適化案の提示と実行支援 / 判断が不正確な場合が多く、誘導が必要
• 第 2 回リファクタリング：定期ポーリングを停止し、HTTP によるコード送信は維持しつつ、AI が更新したコードをプッシュして取得する仕組みへ変更 / 主導的な案の提示と実行支援 / 多くの場合で分析が正確であり、偶発的に誘導が必要

第 1 回リファクタリングの際に AI に十分なコンテキスト情報を付与したおかげで、第 2 回では AI が主導する方針が全体的に明確になり、判断もほぼ正確でした。その結果、実装効果も非常に良好でした。

「技術的負債（スーパースラッシュ）の整理」ステップ 2：複雑な問題を単純化する。

三、規範を定め、プロジェクトに制約と境界を設定する

プロジェクトがメンテナンス困難になる真の原因は、業務そのものの難易度ではなく、明確な規範や境界の欠如、そして長期間にわたる収束プロセスの不足にあります。

私たちのプロジェクトではページ数が多く、インタラクションも複雑です。特に自由度の高いクリエイティブページやコース制作ページなどは、画面幅への対応（レスポンシブ）、各セクションのドラッグ＆ドロップ、表示・非表示のアニメーション、そして多言語対応など、多くの要素が絡み合っています。

業務が急速に迭代（アップデート）する一方で、開発アーキテクチャも進化し続けています。しかし、デザイン稿自体も頻繁に変更され、同じコンテンツでも時期によってデザイン稿の表現が異なるという問題が発生しました。その結果、プロジェクト内の各ページで多くの不整合が見られるようになりました。もちろん、これには開発過程におけるスタイルの繰り返し変更による破損も含まれており、これについては後述する自動化テストの章で詳しく説明します。

しかし、スタイルに関する問題は典型的な課題であり、解決策はシンプルです。デザインチームと連携し、プロジェクト全体の規範を統一することです。具体的には以下の通りです。

• ページレイアウト規範（タイトル・コンテンツ・間隔など）
• 画面幅への対応規範
• ユニットコンポーネントの統一規範（ポップアップ・テーブル・ボタンなど）
• ページスクロールに関する規範

これらのスタイル規範を現場に落とし込むため、2 つのアプローチを組み合わせて実施しました。

1. 統一コンポーネントの構築：過去のデザイン稿で規範に適合しない要素をすべて整理し、統一されたコンポーネントとして再編成する。
2. 規範の蓄積と AI による自動チェック：AI に規範を学習させ、MR（Merge Request）プロセス内で自動的にルール違反を検出させる。

こうして規範が確立されれば、今後の長期的な迭代プロセスにおいても、継続的なガバナンスと遵守が可能になります。

「技術的負債の整理」ステップ 3：実行に根拠を持たせる。

四、基準を定め、自動化テスト基盤を構築する

明らかに、今後は AI を活用した開発ニーズがさらに増えるでしょう。要件定義からアーキテクチャの改修、バグ修正に至るまで、変更が他の機能にどのような影響を与えるかを素早く判断するのは困難です。そのため、自動化テストの基盤整備はもはや必須となっています。

かつてフロントエンドで大量のテストケースをカバーしなかったのは、変化が激しく、ケースの維持コストが高すぎるからです。

しかし今は AI がいます。AI の支援により、自動化テストの開発工数は劇的に減りました。今やテストケースの維持コストは、AI へのコンテキスト提供とトークン使用量のみとなっています。

単体テスト・E2E テストのカバー率向上と MR パイプラインによる回帰テスト

テストケースの構築と整備は一度で完了するものではなく、継続的な取り組みが必要です。そこで私はこのプロジェクトを数期に分けて進めました。

• 期間：主な内容 / AI の役割 / 具体的な対応
• 第一期：プロジェクトの自動化テスト能力（単体・E2E）の構築 / 主導：方針策定と実行 / AI に期待する挙動を指示し、調整を行う
• 第二期：MR 回帰パイプライン（単体・E2E）およびパイプライン用イメージの構築 / 支援：方針策定と実行 / 社内 CI/CD ツールや Docker 構築などのコンテキストを提供し、AI に実装を指示
• 第三期：テストケースの整理と追加（P0/P1/P2 の優先度分類） / 支援：文脈に基づき整理 / 既存のテストケースを提供して分析させ、コア機能と非コア機能の境界を AI に示唆・調整させる
• 第四期：複雑なフローにおけるテストケースの整理と追加 / 支援：分析と実行 / 複雑なフローのコンテキストを提供し、AI に分析とケース構築を指示

単体テストは主に単純な機能の検証に用いられ、モックデータに基づいて構築されます。一方、E2E テストは複数ページにわたるロードやインタラクションを含むため、実際の環境で連続して実行されるケースも少なくありません。実環境での実行にはテストアカウントの準備が必要であり、テスト完了後にはデータのクリーンアップも不可欠です。例えば、テスト中に作成された空のプロジェクトなどは削除しないと、すぐにアカウント制限に達してしまいます。

この一連の作業には、合計で約 1〜2 か月を要しました。改修前後では変化が顕著で、最大の改善点は以下の通りです。以前はリリース前に必ず手動でコア機能を回帰テストする必要がありましたが、特に「自由創作」「学習コース」「コース制作」のように、シナリオは異なるものの機能が強く結合しているこれらの領域のページにおいて、その負担が大幅に軽減されました。

もちろん、新方針が稼働し始めた当初は、テストケースのカバー率と有効性を確認するために人手による検証も併せて行いました。しかし現在では、ほぼ手動テストは不要です。昨年は毎回のリリースでコアフローに問題が発生していましたが、ここ数ヶ月のリリースではユーザーからの報告がほとんどなく、実際にはユーザー数は継続的に増加しています。

視覚回帰テストの構築

昨年までは、プロジェクト全体がバグの特定・修正や技術負債の整理、新機能への迅速な対応で手一杯でした。そのため、スタイル（デザイン）の問題はケースバイケースでの対応しかできませんでした。

今年上半期に大半の技術負債を解消し、単体テストと E2E テストのカバー率が安定したことで、ようやくスタイル問題が課題として浮上してきました。

前述の「規範策定」の部分でもスタイル問題への対処方針は説明しましたが、「気づかないうちにスタイルが壊れてしまう」という根本的な問題は解決していません。スタイルが壊れる原因は多岐にわたり、統一コンポーネントの変更、自己テスト・レビューの不十分さ、AI による変更の境界線不透明などが挙げられます。これは開発者にとって再作業の連続となり、デザイナーにとっては確認と指摘の繰り返しという過酷な状況を生み出しています。

すでに全体の自動化テストフレームワークが構築されているため、新しい視覚回帰テストのパイプラインを設けるのは苦痛ではありません。プロジェクトに特化した Docker 環境を用いて、視覚回帰専用のパイプラインを追加し、その結果物をコードリポジトリと連動させることができます。

ただし、視覚回帰は一枚の大きなスクリーンショットですべてのスタイル問題を網羅できるわけではありません。パイプラインの安定性を考慮し、各テストケースに対して許容されるピクセル誤差の範囲を定義する必要があります。したがって、視覚回帰の全体像としては以下のような構成になります。

• 大きなスクリーンショット：大規模なレイアウト異常を検出するために使用。許容誤差は比較的大きく設定しますが、文字や角丸などの細部までは検出できません。
• コンポーネントごとの小さなテストケース：各コンポーネントを個別に分割し、各種状態でのスタイル回帰をカバー。許容誤差は厳しく設定し、精密な問題の発見に役立てます。

この仕組みの利点は、開発プロセスでテストケースの異常が期待通りかどうかを正確に判断できず、AI が誤って他のスタイルを変更してパイプラインを通過させてしまった場合でも、MR（Merge Request）の段階ですぐに発見できることです。

下の画像は、パイプラインの異常を検知した際、AI が修復処理中にスタイルを誤って変更してしまった例です。この場合、MR の時点で明確に気づくことができます：

imageMR でのカスタムルール適用

既存の機能が壊れていないことをパイプラインで保証するだけでなく、新たに追加された機能も定めた規範に従って実行されているかを確保する必要があります。そのために必要なのが、MR パイプライン内で AI がコードレビューを行う機能です。

この機能は当初、自社で構築する予定でしたが、ちょうど「工蜂」に類似した機能が提供されていたため、早速試用することにしました。手順も非常に簡単で、プロジェクト内に AI レビューのルールを追加し、工蜂上でそのルールファイルを AI に指定するだけです（図参照）：

imageもちろん、この機能は最近追加されたばかりで、まだ実践段階にあります。そのため、有効性と効果を検証するには十分な時間が経過していません。

これで、毎回の MR マージ時には以下のパイプラインを通過する必要があります：

四、技術的負債の解消：問題の再発を防ぐ

五、債務管理の日常化

前述した通り、技術的負債が生じる原因の多くは、リファクタリングや新方案の実装が不徹底であることにあります。その結果、問題が積み重なり、長期的に負債へと変貌していきます。

多くの歴史的プロジェクトでこうした課題を目にします。実際、ほぼすべてのプロジェクトに以下の共通の問題が存在しています：

• 業務のスピードアップにアーキテクチャ設計が追いつかず、技術的負債となる
• 技術リファクタリングが中途半端で、新たな負債を生む
• プロジェクトの反復的な改修により、新旧の負債が重層的に蓄積する

過去に見てきた実際の稼働プロジェクトでは、技術改造を完全に完了させた例はありませんでした。多くの場合、チームは意欲的に着手しますが、その後の業務方向の変更や、新機能へのリソース集中、コスト対効果の低下などにより、改造が中途半端で終わることが多々あります。

しかし、AI を活用することで、この課題をより効果的に解決できるようになります。集中的な技術特化プロジェクトとして行っていた改造を、日常の開発プロセスに組み込むことで、継続的な改善を実現できるのです。

解決策はシンプルです。前述の「規範の策定」を補完し、継続的なガバナンスの方針を示すことで、今後の開発プロセスにおいて AI が新しい規範に従いながら過去の課題も同時に整理できるようにします。また、MR（Merge Request）レビュー時に導入した AI による自動チェックを活用すれば、新たに発生する問題を検知することも可能です。

「コードの腐敗」を解消する第五のステップ：毎日少しずつ手を加えれば、プロジェクトは長く保たれます。

結びに代えて

元々は、AI に頼って過去半年間のコードリポジトリの変遷を振り返る記事を書こうと考えていました。しかし、いざ書いてみると「もっともらしいが味気ない」という感想しか浮かびません。やはり手書きの方が味わいがありますね。

AI が担える役割は増え続けており、我々が介入する機会は減りつつあります。いつになったら完全に任せていいのでしょうか？それとも、本当に任せるべきなのでしょうか？

旧時代の守人である私のような「古参」の視点からすれば、実装の実行、コミュニケーションの効率化、記録の蓄積といったタスクは AI に委ねて構いませんが、「思考」だけは人間が行うべきだと考えます。

AI には私の思考を代筆することはできません。十分なコードやドキュメントを読み込み、AGENTS.md から始まり私と共にリファクタリングを進めてきたとしても、やはり「思想の核」という部分では物足りないのです。

微信で開くにはこちらへ