AI、技術的負債、そして AI を使いこなす力への道筋

本記事は 2026 年 4 月 14 日に公開された「AI, Technical Debt, and the Path to Real Fluency」を翻訳したものです。
※ 本記事では、原文の “AI fluency” を「AI を使いこなす力」と訳しています。単なる AI に関する知識ではなく、実践を通じて身につく AI を使った問題解決力を意味しています。

まさに今、私がお話を伺っているエンタープライズのリーダーの誰もが同じ 3 つの問題に頭を悩ませています。これらは特定の業界や企業規模に限った話ではなく、金融サービス、政府機関、ヘルスケアなどで見られます。そして、これらの問題は往々にして同時に現れます。

1 つ目の問題は、ほとんどの組織が自社にどのようなシステム、ツール、アプリケーションがあるのかを実は把握していないということです。技術資産は広範囲にわたり、ドキュメントは不十分で、多くの場合、それを理解していた人はすでに退職しています。問題があることは分かっていて、それが足かせになっていると感じているのに、どこに問題が潜んでいるのかを正確に特定できないのです。何か新しいことを始めるたびに、「はい、でも実は…」がまた一つ出てきます。

私自身、インディアナ州の CTO としてこれを身をもって経験しました。課題があることは分かっていましたが、体系的に対処できるほどの精度で毎回安定して課題を特定することができませんでした。

2 つ目の問題は、AI の幅広い導入をどう促進するかです。技術チームは AI の活用方法を模索していますが、多くはコード生成やテスト作成の段階で止まっています。明確なユースケースも、どこに AI の変革が必要で、どのようなインセンティブが求められるかを判断するフレームワークもありません。それがなければ、AI の本格的な導入は構想のままなかなか進みません。

3 つ目の問題は最も言語化しにくいものですが、チームが AI ツールを使っている様子を観察すると明らかになります。それは、トレーニングが提供する手順通りにこなせるスキルと、自分自身の環境で実際に手を動かして身につく問題解決の実践力との間にあるギャップです。チームを前者から後者へ導くためには、トレーニングではなく経験が重要です。

私がお客様にお伝えしているのは、1 つのアプローチでこれら 3 つの問題すべてに対処できるということです。そしてそれは、最新のコミットまで反映された正確なドキュメントアーティファクト (コードから自動生成されるドキュメント類の成果物) の作成を必須にすることから始まります。

今いる場所から始める：未知を既知にする

この業界で 30 年間働いてきましたが、優れたドキュメントを見たことがありません。効果的なドキュメント作成は時間がかかり、デリバリーのプレッシャーと相反するためです。開発者にドキュメントを書くことを期待し続ける限り、この状況は変わらないでしょう。

最近、もっと有望なものを目にしました。それは、チームが AI を使って、作業の副産物としてリアルタイムにドキュメントやその他の有用なアーティファクトをプログラム的に生成しているケースです。

AI はコードにコメントを書いたりドキュメントアーティファクトを作成したりすることを気にしません。しかも、目にしたものをうまく読み解くのが得意です。十分なコンテキストを与えてコードを読み込ませれば、チームが忘れていた、あるいはそもそも知らなかった情報、例えば依存関係、パターン、リスク、ロジックに組み込まれたアーキテクチャ上の判断などを浮き彫りにしてくれます。

実践的な出発点として、AWS Transform custom のモダナイゼーションエージェントがあります。すぐに使える変換定義 (TD) が用意されており、ニーズに合わせてカスタマイズできます。1 つの TD でコードを読み取り、アプリケーションを変更することも移行を行うこともなく、コードに関する情報を生成できます。

レガシー資産から 1 つか 2 つのアプリケーションを選び、分析を実行して、AWS Transform custom が何を教えてくれるか確認してみてください。すでに知っていたこと、疑っていたこと、そして本当に驚くようなことが見つかるでしょう。そして、チームがアプリケーションについて実際に知っていることと、その出力結果を照合する時間を取ってください。精度の感触を掴んだら、「チームがどのようなコンテキストを追加すれば、これをもっと有用にできるか？」と自問してみてください。

既製のツールは、お客様がどのように、そしてなぜそうしているかを熟知しているわけではありません。しかし、アーキテクチャ標準、既知の制約、技術的な意思決定、ソフトウェアバージョンの基準など、企業固有のコンテキストでこれらのツールを拡張することができます。

最近、お話を伺った銀行のチームは、複雑で複数のシステムから構成される、レガシー環境全体での日付とタイムゾーンの処理について特に懸念していました。ここで有効なのが、AWS Transform custom のコード分析 TD をカスタマイズして、資産全体の日付と時刻のロジックを浮き彫りにするというアプローチです。これは自社ビジネスの将来にとって重要な課題にピンポイントで切り込む取り組みであり、汎用的な AI ユースケースとは一線を画すものです。

このプロセスから生まれるアーティファクト（リポジトリに保存された Markdown ファイルなど、お好みのテキスト形式で構いません）は、価値あるものの始まりです。それは、検索可能で体系化された、レガシー資産のナレッジベースです。プロセスを自動化して、好きな名前を付けてください。リビングドキュメントでもリアルタイムアーティファクトでも構いません。名前は重要ではありません。重要なのは、それが存在し、コードの実態に即しており、変更に合わせて更新され続けることです。

隠れたメリット：実際の業務を通じて AI を使いこなす力を身につける

このアプローチの予想外の成果は、それが AI を使いこなす力を養う演習になるということです。チームが AI に何を探してほしいかを記述し、コンテキストを提供し、出力結果を磨き上げていくとき、他のあらゆる AI ユースケースに転用できるスキルを実践することになります。自分が求めるものをどう記述するか？コンテキストをどう管理するか？有用なものになるまで、どう磨き上げていくか？

これらは机上の知識ではありません。コードの分析、ドキュメントの作成、前例のない問題の解決など、AI と効果的に協働するための実践的な技術です。何かを始め、改善し、コンテキストを管理し、求めるものに到達するという実践の積み重ねこそが、AI による問題解決の核心です。こうしたスキルは研修で学ぶものではありません。実際の課題に向き合う中で身につくものです。

AI の利用を義務化しても導入の問題は解決しません。チームに AI と真剣に向き合うことを求める、具体的で意味のあるタスクを与えることで解決するのです。

すべてをつなげる：OKR にする

(翻訳時注釈: OKR とは Objectives and Key Results の略で、目標と主要な結果を意味します。)

ここまでで、技術資産を理解するための方法が手に入りました。そしてその過程で、AI を使いこなす力も身につけられます。では、これを組織として定着させるにはどうすればよいでしょうか？

ポートフォリオ内のすべてのアプリケーションが、年末までに現行のコードを正しく反映するリアルタイムアーティファクトを持つことを目標に設定することを検討してください。リアルタイムアーティファクトとは、一度書いて終わりのドキュメントではなく、コミットやメインブランチへのプッシュ、コードの変更があるたびに自動で更新されるアーティファクトのことです。今日実際に稼働しているアプリケーションの姿をそのまま映し出す、生きた記録を作成しましょう。

OKR は AI の使用を義務化するものではなく、成果を定義するものです。

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

1. 基本的なやり方を教える仕組みを提供する。チームにツールを使ってこれらのアーティファクトを生成する方法を示します。具体的で手を動かすようなものにしてください。
2. 実験を奨励する。チームが自由に試し、定義を改善し、AI を独自に使いこなす力を身につけられるようにします。多様性はバグではなく、仕様です。(翻訳時注釈: チームごとのばらつきは問題ではなく、むしろ望ましいことです)
3. 成果を自動化する。プロセスが理解できたら、CI/CD フックやスケジュールジョブ、エージェントトリガーとしてパイプラインに組み込みましょう。誰かが忘れずに実行しなければならない状態ではなく、アーティファクトが自動的に生成される状態にするのです。

3 つのステップすべてを完了したとき、解決しているのはドキュメントの問題だけではありません。技術資産に関する組織としてのナレッジを、一貫して自動的に生成するプロセスを構築したのです。

これらのアーティファクトは以下のことに活用できます：

• アプリケーションの動作に関する正確なコンテキストを必要とする AI エージェントへの情報提供
• 監査およびコンプライアンスワークフローのサポート
• オンボーディングの加速
• インシデントになる前のリスクの可視化

成果

AI 導入に苦戦しているお客様は、十分にインパクトがあり、かつ安全に始められるユースケースを探していることが多いです。ここで紹介したアプローチがまさにそれです。

コードを変更したり、チームを置き換えたりするわけではありません。組織が常に必要としながらも、なかなか実現しきれなかったこと、つまり組織そのものを理解することを AI を使って行うのです。そしてその過程で、その後のあらゆる AI 投資の成功確率を高める AI を使いこなす力、習慣、組織としてのナレッジを構築することになるのです。

この記事はカスタマー ソリューション マネージャーの仁科 みなみが翻訳しました。