「自社にどんなシステムやアプリケーションが動いているのか、実は誰も全体像を把握していない」――AWSのPrincipal Go To Market Specialistを務めるJoe Cudby氏が、2026年4月14日にAWSブログで公開した記事「AI, Technical Debt, and the Path to Real Fluency」では、この身も蓋もない現実から議論が始まります。氏は米インディアナ州のCTOをはじめ複数の経営技術職を経てAWSに参画した、業界30年の技術リーダーです。本記事では、その提言を開発現場の視点から噛み砕き、AIで技術的負債を可視化しながら、同じ動きの副産物として開発チームの「AIフルエンシー（AIを使いこなす力）」を育てる進め方を整理します。
「自社のシステムを誰も把握していない」状態はなぜ生まれるのか
Cudby氏は、企業のリーダーと話す中で共通して浮かび上がる課題として、技術資産の可視化不足、AI導入が局所最適に留まっていること、そしてスキルギャップの3点を挙げています。これは特別な組織だけの話ではなく、長く続いている事業会社であればどこでも程度の差はあれ抱えている問題です。
原因は単純で、ドキュメントは書かれた瞬間から古くなり、コードや設定だけが日々動き続けるからです。氏自身も「30年のキャリアで本当に優れたドキュメントを見たことがない」と率直に述べています。その結果、現場では「コードを読まないと本当の挙動はわからない」状態が常態化し、新しい人が入っても立ち上がりが遅く、リスク評価も属人化します。
この状態のままAIを導入しても、コード補完やテスト生成といった「目の前のタスク高速化」に止まりがちです。Cudby氏が指摘する3つ目の課題、すなわち「手順通りに動かせるスキル」と「問題を切り分けて解ける実践的な力」のギャップも、ここから生まれます。AIに渡せる前提情報が薄いままだと、出力は当たり障りのない平均的なものになり、チームは「思ったほど効かないな」という体験を繰り返してしまいます。
出発点を「いま」に置く ― AIで未知を既知に変える発想
Cudby氏が提案するアプローチはシンプルです。理想の未来から逆算して計画を立てるのではなく、まず「いま自社にあるものを正確に知る」ことから始める、というものです。氏はこれを「未知を既知に変える」と表現します。
具体的な打ち手として記事で紹介されているのが、AWS Transform customのモダナイゼーションエージェントです。アプリケーションを変更したり移行を実行したりしなくても、コードを解析して挙動や依存関係に関する情報を生成できる、と説明されています。記事では、ある銀行のチームが複雑なレガシー環境における日付とタイムゾーンの処理に的を絞り、エージェントの挙動をカスタマイズして調査を進めた事例も紹介されています。
ここで重要なのは、ツールそのものよりも「AIを情報生成装置として使う」という発想の転換です。AIに対して「ここを直して」と頼むのではなく、「ここで何が起きているのか説明してほしい」と頼む。設計レビューや障害対応の現場感覚に近い使い方で、開発者にとっても腹落ちしやすい入口です。
リアルタイムアーティファクトという考え方 ― 書いて終わらないドキュメント
Cudby氏が強調するもう一つのキーワードが「リアルタイムアーティファクト」です。これは「一度書いて終わりのドキュメントではなく、コミットやメインブランチへのプッシュ、コードの変更があるたびに自動で更新されるアーティファクト」と定義されています。
開発者にとっては、これはむしろ自然な発想に近いはずです。ADR（Architecture Decision Records）やOpenAPI仕様書、SBOM、データリネージュなど、ソースコードの近くに置かれて自動更新される「真実のソース」は、すでに馴染みのある概念です。Cudby氏の提言は、これをアプリケーションの説明書きやランブック、コンプライアンス向けの根拠資料といった、これまで人手に頼りがちだった領域まで広げていこう、というものです。
運用に乗せるうえでのポイントは、生成タイミングをイベントに紐づけることです。コミット、PRマージ、デプロイ、本番でのインシデント発生など、コードや状態が変わった瞬間にAIエージェントが必要なアーティファクトを再生成し、リポジトリやWiki、内部ポータルにプッシュする。こうすることで「ドキュメント更新を忘れた」という典型的な失敗が、構造的に起こりにくくなります。
副産物としての「AIフルエンシー」 ― 机上の知識ではなく実践で身につく力
このやり方の隠れた効能として、Cudby氏は「AIを使いこなす力」、すなわちAIフルエンシーの育成を挙げています。氏は、研修で身につく「手順通りに動かせるスキル」と、自分たちの環境で泥臭く手を動かす中で身につく「問題解決のフルエンシー」を明確に区別し、両者を埋めるのは経験であって座学ではない、と述べています。
リアルタイムアーティファクトを自分たちの手で作る過程では、開発者は次のような実践的な技能を反復することになります。
- 欲しいものを言語化する力――「アーキテクチャ概要が欲しい」では曖昧で、「主要コンポーネント間の同期/非同期呼び出しを区別して図示してほしい」のように要求を具体化する力
- コンテキストを渡す力――関連リポジトリ、設定ファイル、過去の障害票など、AIに見せるべき情報を取捨選択する力
- 出力を批判的に読み解く力――生成された説明文や図に対して「ここは本当か」「この前提は今も成り立つか」と問い直し、改善ループを回す力
これらは特定のモデルやツールに固有のスキルではなく、AIエージェントを業務に組み込むあらゆる場面で効いてきます。だからこそCudby氏は、研修プログラムを増やすよりも、実務の中でこの三つを繰り返す機会を設計することのほうが、組織のAI活用力を底上げするうえで効果的だと主張しているわけです。
OKRとCI/CDで仕組み化する ― 多様性を許容しつつ品質を担保する
個人の頑張りだけでは続かないため、Cudby氏は組織的な定着策としてOKR化を提案しています。記事で示されている目標例は「ポートフォリオ内のすべてのアプリケーションが、年末までに現行のコードを正しく反映するリアルタイムアーティファクトを持つこと」というものです。
そのうえで、定着に向けた具体的な動きを次の3ステップで整理しています。
- 基本のやり方を教える仕組みを用意する。サンプルプロンプト、参考リポジトリ、レビュー観点を社内に共有し、最初の一歩のハードルを下げる
- 実験を奨励する。チームごとに使うエージェントや書式が違っても構わない、という前提を明確にする。氏は「多様性はバグではなく、仕様です」と表現しています
- 成果が出たやり方をCI/CDパイプラインへ自動化する。実験で良かったプロンプトや生成プロセスは、人手で回し続けるのではなくパイプライン上のステップとして埋め込み、すべてのコミットで動く前提に変える
多様性を尊重しつつ品質を担保するうえで、CI/CD化は要になります。アーティファクト生成のステップに対して、リンタや静的解析と同じく「形式チェック」「リンク切れ確認」「最低限の情報項目の存在確認」を入れることで、出力のばらつきを許容範囲に収められます。これは、Infrastructure as Codeを最初に導入したときの議論と同じ構図で、開発者にとっては抵抗の少ない発展形と言えるでしょう。
開発チームが今日から踏み出せる3つのステップ
記事ではAIエージェント連携、監査・コンプライアンスワークフロー、オンボーディング加速、リスク可視化といった応用例も示されていますが、最初から全部を狙う必要はありません。開発チームとして無理なく始めるなら、次の3ステップが現実的です。
- 一つのサービスを選び、現行コードからアーキテクチャ概要と外部依存リストをAIで生成し、Pull Requestとしてレビューに乗せる。最初の出力はおそらく粗いが、それを直すレビューが最初の学習機会になる
- そのリポジトリのCIに「マージ時にアーティファクトを再生成して更新する」ジョブを追加し、「ドキュメントだけ古い」状態を構造的に消す。ここで初めて「リアルタイム」の効能が出始める
- 四半期OKRに「対象サービス数」を入れて広げる。テンプレートやプロンプトは共通化しつつ、現場ごとの工夫は許容する。良いものはパイプラインに昇格させる
Cudby氏のメッセージを一行で要約するなら、「AIの価値は、未来のすごい機能ではなく、いま手元にあるコードを正しく理解し続けることから生まれる」となるでしょう。技術的負債の解消とAIフルエンシーの獲得は別々の取り組みではなく、一つの動きの表と裏です。開発チームにとっては、難しい新領域を学び直すというよりも、既に持っているCI/CDやコードレビューの文化を、AIエージェントを前提に少しだけ拡張するという、地続きの進化として捉えるのが現実的だと考えます。
