AWS Japan Blogで2026年5月に公開された「AI、技術的負債、そして AI を使いこなす力への道筋」という記事が、エンジニア組織にとって非常に示唆に富む内容でした。本記事では、この内容をベースに、技術的負債の解消とチームのAIスキル向上を同時に実現するアプローチを解説します。

多くの組織が直面する3つの課題

AWSの記事では、多くの組織が抱える共通の課題を3つに整理しています。これらは現代のソフトウェア開発組織であれば、どこでも見られる普遍的な問題と言えるでしょう。

1つ目は、技術資産の全体像が見えていないという問題です。組織は自社のシステム、ツール、アプリケーションを正確に把握できていません。ドキュメントが不十分で、数年前に去った人しか理解していないシステムが少なくありません。この「知識の断絶」は、システムの保守や改修において重大なリスクとなります。

2つ目は、コードに埋もれた知見が活用されていないという問題です。レガシーコードには依存関係、パターン、リスク、アーキテクチャ上の決定が埋め込まれています。しかし、チームがそれを忘れていたり、そもそも知らなかったりすることが多く、せっかの知見が眠った状態になっています。この知見を掘り起こすことは、技術的負債の返済において非常に価値があります。

3つ目は、トレーニングと実践のギャップです。手順通りにこなせる「機械的なスキル」と、自分自身の環境で実際に手を動かして身につく「問題解決の実践力」には大きな隔たりがあります。この隔違いを埋めるには、トレーニングではなく「経験」が必要なのです。従来の研修プログラムだけでは、この実践力を育むことができないという課題があります。

リアルタイムアーティファクトによる解決アプローチ

AWSが提唱する解決策は、最新のコミットまで反映された正確なドキュメントアーティファクトを必須にすることから始まります。これは従来のドキュメント作成とは根本的に異なるアプローチです。

従来のドキュメント作成は「書いて終わり」になりがちで、コードの変更に追いつけず陳腐化していました。しかし、AIを使えばプログラム的にドキュメントやその他の成果物をリアルタイムに生成できます。このアプローチでは、コミットやメインブランチへのプッシュ、コードの変更があるたびに自動的に更新されるアーティファクトを作ります。

重要なのは、それが存在し、コードの実態に即しており、変更に合わせて更新され続けることです。名称は「リビングドキュメント」でも「リアルタイムアーティファクト」でも構いません。名前よりも中身が重要です。この「生きたドキュメント」は、組織の知識資産として長期的な価値を持ち続けます。

AWS Transform customを使った実践

具体的なツールとして紹介されているのが、AWS Transform customです。これはre:Invent 2025で発表されたモダナイゼーションエージェントで、アプリケーションコードを分析して有用な情報を抽出できます。従来の静的解析ツールとは異なり、AIを活用してコンテキストを理解し、人間が読みやすい形式で出力します。

記事では以下の手順を推奨しています。

• レガシー資産から1つか2つのアプリケーションを選ぶ
• AWS Transform customで分析を実行する
• 出力結果を確認し、チームが知っていることと照合する
• 「どのようなコンテキストを追加すればもっと有用になるか」を検討する

このプロセスで生成されたマークダウンファイルなどの成果物は、レガシー資産に関する検索可能で記述可能な知識体系の始まりとなります。最初は不完全でも、反復的に改善していくことで品質が向上していきます。

AIを使いこなす力の養成という予想外の成果

このアプローチの予想外の成果は、それ自体がAIを使いこなす力を養う演習になるということです。本来の目的はドキュメント生成ですが、その過程でチームのAIスキルも向上します。

チームがAIに何を探してほしいかを記述し、コンテキストを提供し、出力結果を磨き上げていくプロセス。これは他のあらゆるAIユースケースに転用できるスキルの実践です。

• 何を求めているかを記述するにはどうすればよいか
• コンテキストをどう管理するか
• 有用なものに近づけていくにはどうすればよいか

これらは抽象的なスキルではなく、AIを効果的に使うための実践的なスキルです。コードの分析であれ、文書の作成であれ、前例のない問題解決であれ、共通して使える能力です。

この「何かを始めて、改良し、コンテキストを管理し、求めているものに到達する」という規律こそが、AIを使った問題解決の核心です。チームはトレーニングモジュールではなく、実際の課題に対する実作業を通じてこれを学びます。これが「AIを使いこなす力（AI fluency）」の本質です。

組織に定着させる3ステップ

記事では、年末までにポートフォリオ内のすべてのアプリケーションが正確なリアルタイムアーティファクトを持つことを目標に設定することを推奨しています。OKRはAIの使用を義務化するものではなく、成果を定義するものです。AIツールの利用を強制するのではなく、成果物を求めることで自然とAIが活用されるようにします。

この目標への道筋には3つのステップがあります。

1. 基本的なやり方を教える仕組みを提供する

チームにツールを使ってアーティファクトを生成する方法を示します。具体的で手を動かせるものにします。読み物ではなく、実際にやってみることが大切です。ワークショップ形式で、実際のプロジェクトコードを使って演習を行うのが効果的です。

2. 実験を奨励する

チームが自由に試し、定義を改善し、AIを独自に使いこなす力を身につけられるようにします。記事では「多様性はバグではなく、仕様です」と表現しています。チームごとのばらつきは問題ではなく、むしろ望ましいことです。それぞれのチームが自分たちのワークフローに最適な方法を見つけていくプロセスが重要です。

3. 成果を自動化する

プロセスが理解できたら、CI/CDフックやスケジュールジョブ、エージェントトリガーとしてパイプラインに組み込みます。誰かが忘れずに実行しなければならない状態ではなく、アーティファクトが自動的に生成される状態にするのです。これにより、ドキュメントの鮮度が常に保たれるようになります。

まとめ

AIを使いこなす力は、座学ではなく実践で身につきます。ドキュメントを「書く」のではなく「生成させる」というパラダイムシフトは、技術的負債の解消だけでなく、チームのAIスキル向上にもつながります。一つの取り組みで、複数の価値を生み出すことができるのです。

まずは小さなアプリケーションから始めてみてはいかがでしょうか。AIにコードを分析させ、その出力を精査し、改善していくプロセスそのものが、AIを使いこなす力を育む場になるはずです。組織全体でこの取り組みを広げていくことで、技術資産の可視化とチームのAIスキル向上を同時に実現できます。

本記事の内容は、AWS Japan Blogの記事をベースに、エンジニア組織での実践的な活用方法として再構成しました。詳細は元の記事もご参照ください。技術的負債の解消は現代の組織にとって重要な経営課題です。