CiscoのAIコード書き換え、無制限トークンの先に98%という目標
Ciscoは、27歳のエンジニアに無制限のAIトークンを与え、24カ月以内にレガシーコードの98%を書き換える取り組みを進めていると報じられている。CiscoのAIコード書き換えは、異例に広範な目標と少人数の予定チームを組み合わせたものだ。その重要性は、Ciscoが何を変更するつもりなのか、そして変更が正しく機能することをどう立証するのかにかかっている。
Fortuneの報道を伝えたTom’s Hardwareによると、社長兼最高製品責任者のJeetu Patelは、サンフランシスコでの会話を経て、元スタートアップ創業者のPadmanabhan Krishnamurthyを後押ししたという。この任務には、最初の4週間の実証期間も含まれるとされる。これらの詳細が示すのは、独立して検証済みのモダナイゼーション成果ではなく、実験と野心である。
中心となる緊張関係は、無制限のコード生成と説明責任を伴うソフトウェア提供の間にある。AmazonはすでにAI支援によるアプリケーション更新について説明しており、有用な比較対象となる。Ciscoの報じられた野心は、変更を生成しやすくなったとき、小規模なエンジニアリングチームがどこまで組織上の責任を引き受けられるのかという、より広い問いを提起している。
CiscoのAIコード書き換えは、完了済み移行ではなく目標から始まる
報じられた任務は経営陣の後押しを示すものであり、Ciscoがソフトウェアをモダナイズしたことを証明するものではない。
Tom’s Hardwareによるレガシーコード任務の報道では、この提案を主導したエンジニアとして、Paddyの名で知られるKrishnamurthyが特定されている。彼は2人チームを提案したとされる。Patelは、AIモデルが指示の受信や応答生成の際に処理するテキスト単位であるトークンを無制限にすることを含め、後押しを提供した。
報道によれば、Krishnamurthyは以前、Patelより組織階層で5段下の職位にいた。このプロジェクトは、ツールの変更であると同時に責任の変化として位置付けられている。元創業者には、既存のエンジニアリング上の前提に挑戦する余地が与えられることになる。
そのつながりには、独立して検証可能な買収の経緯がある。CiscoのEzDubs買収通知によると、この取引は2025年11月25日に完了した。CiscoはEzDubsを、リアルタイム音声翻訳を専門とするAIソフトウェア企業と説明した。その目的には、コラボレーション分野のエンジニアリング人材を拡充することが含まれていた。
この経緯は、買収されたスタートアップがCiscoに加わったという説明を裏付ける。ただし、書き換え提案やその実現可能性を独立に検証するものではない。買収発表は、Ciscoのレガシーソフトウェアを変革する公開計画ではなく、コラボレーション機能に関するものだ。
報じられた任務の表現にも注意が必要である。リファクタリングとは、外部から観察可能な挙動を維持しながら、ソフトウェアの内部構造を変更することを指す。書き換えは実装の置き換えを伴う場合があり、異なる設計判断や互換性リスクを持ち込む可能性がある。
これらの用語は重なる作業を指すことがあるが、進捗の尺度として互換ではない。自動化された内部整理と、顧客が依存するコンポーネントの置き換えには大きな差がある。モダナイゼーション・プログラムでは、各変更がどの分類に属するかを特定する必要がある。
公開報道では、98%という数字の根拠となる詳細な棚卸しは示されていない。また、完了が生成された変更、受け入れられた変更、本番導入、旧実装の廃止のいずれを意味するのかも説明していない。こうした定義がなければ、この割合は運用範囲よりも野心を明確に伝える。
同様の注意はスケジュールにも当てはまる。2026年10月30日に公開された報道は、その日にプロジェクトの時計が動き始めたことを示すものではない。読者は、公開日だけから正確な完了日を算出することは避けるべきだ。
したがって、有用な出発点は限定的である。Ciscoの社長は、明確な見出し目標を掲げた積極的なエンジニアリング実験を承認したと報じられている。その実験が再現可能なモダナイゼーション・プログラムになるかどうかは、別の問いとして残る。
無制限トークンは、レビューと責任範囲へ圧力を移す
生成の制限をなくすことは、エンジニアリング作業が蓄積する場所を変えるが、変更を受け入れるために必要な作業をなくすものではない。
可視化される出力がコードであるため、無制限のAIトークンは無制限のエンジニアリング能力のように聞こえる。しかし、生成されたパッチ、すなわちソースファイルへの変更提案には、存在する理由がなお必要だ。誰かが何を変えるのか、なぜ安全なのか、誰が保守するのかを明らかにしなければならない。
共有認証コンポーネントのモダナイゼーションを仮定してみよう。AIツールは、より明快なコード、新しい依存関係、追加のテストを提案するかもしれない。それでも、その提案は既存の権限ルールやサポート対象の顧客構成に照らして評価する必要がある。
この例はCiscoのプロジェクトの説明ではなく、あくまで例示である。もっともらしいソフトウェアを生成することと、本番環境で導入された挙動への責任を引き受けることが異なる活動である理由を示している。作成の高速化は、プログラマー不足を解消するのではなく、レビュー担当者の不足を露呈させる可能性がある。
エンジニアリングマネージャーは直ちに圧力に直面する。提案された変更がチームの評価能力を上回る速度で到着すれば、レビュー待ち行列は膨らむ。マネージャーはその時、作業範囲を狭めるか、レビュー能力を増やすか、各提案に添える証拠のあり方を変えるかを決めなければならない。
セキュリティ専門家も関連する問題に直面する。プロセスがアクセス境界を維持し、機密情報を適切に扱っているかを理解する必要がある。見た目がより整理されたパッチであっても、以前は間接的に強制されていた前提を変えてしまうことがある。
プロダクトオーナーは、内部改善と顧客に影響する変更を区別しなければならない。外部ソフトウェアコンポーネントである依存関係の置き換えは、AIツールが直接編集するファイルの範囲を超えた挙動を持ち込む可能性がある。したがって受け入れは、単に置き換えの見栄えではなく、周辺システムに依存する。
これらの責任は報告系統をまたぐため、経営層の後押しは重要である。小規模な中央チームは手法を開発できるが、影響を受けるチームには変更を承認する方法がなお必要だ。権限が不明確なら、成功したデモのすべてが、結果を誰が引き受けるかという交渉に変わるだろう。
これがCiscoのAIコード書き換えの野心が持つ組織的な意味である。この実験は、小規模なチームが他チームから信頼されるプロセスを作れるかを試す。成果物には、再現可能な証拠、理解しやすい変更境界、障害への対処経路が含まれる必要がある。
既存の保守担当者は、そのプロセスの中心であり続ける。彼らは、なぜ扱いにくい実装が存在するのか、あるいはどの顧客要件が特殊な分岐を説明するのかを知っている場合が多い。その知識は、現在の実装を変更すべきだという結論につながる場合でも、有用な証拠となる。
ドキュメントは、エンジニアリング能力をめぐる問いの一部となる。チームが置き換え提案を評価する前に、設計判断、インシデント履歴、互換性要件にアクセスできる必要がある。検索可能なエンジニアリング知識ベースは、コーディングのワークフローと並行して、その情報問題に対処する。
結果として生じる圧力は、実験の双方に及ぶ。小規模チームは作業をレビュー可能にしなければならず、既存チームは反対意見を具体的に説明しなければならない。無制限の生成も組織的な経験も、自動的な答えを与えるものではない。
Amazonのアプリケーション更新は、より限定的な比較対象となる
境界が定められた移行は、定義されていないソフトウェア資産全体を対象とする割合よりも、明確な証拠を提供する。
AmazonはAI支援モダナイゼーションの業界先例を示している。同社は2024年12月のアプリケーション変革発表で、社内アプリケーションをJava 17へ更新したと説明した。Javaは、エンタープライズソフトウェアで使われるプログラミング言語およびランタイムである。
Amazonは、この取り組みが数万の本番アプリケーションを対象とし、4,500人年超の開発作業を削減したと述べている。これは独立評価ではなく、同社が報告した結果である。それでも、レガシーコードを書き換えるという一般的な約束よりは、具体的な変革を示している。
この具体性は重要だ。バージョン更新には、特定可能な開始状態と目標状態がある。レビュー担当者は、アプリケーションがビルドできるか、期待される挙動が維持されるか、新しいランタイムが要件を満たすかを検証できる。
より広範な書き換えは、多くの異なる目標を組み合わせうる。アーキテクチャの単純化、依存関係の置き換え、保守性の改善、不要になった機能の削除を伴うかもしれない。同じAIツールが変更の生成を支援する場合でも、各目標にはそれぞれの受け入れ基準が必要である。
AWSのJava更新ワークフローにも、明示的な人間による受け入れ手順が残されている。そのドキュメントは、元のコードをビルドし、変換を実行し、開発者に結果の検証と受け入れを求める流れを説明している。言語互換性の変更と追加の依存関係更新を区別している。
この区別が有用なのは、モダナイゼーションが一つの操作で完結することはほとんどないためだ。言語更新が成功しても、すべてのライブラリが最新であることは示されない。ビルドが通っても、すべての顧客ワークフローが正しく動作することは示されない。
したがってAmazonの例が裏付ける結論は限定的である。AI支援による変革には、説明可能な境界を持つ具体的なエンタープライズ活用例がある。ただし、Ciscoの報じられた目標が達成可能であることを示すものではない。また、ごく小さな実装チームが、関連する受け入れ作業のすべてを独力で実行できることも示していない。
測定に関する教訓もある。推定された開発時間の削減は、想定される代替プロセスに依存する。この推定は、本番導入されたアプリケーション、受け入れられた変更、継続的な運用パフォーマンスと併せて示されることで、より有益になる。
Ciscoの実験も、同様に具体的な報告から恩恵を受けるだろう。初期ワークロードの説明があれば、チームが再現可能な変革を試しているのか、より広範な再設計を探っているのかが明らかになる。どちらにも価値はありうるが、不確実性は異なる。
エンタープライズの購入者にとって、この区別はベンダーの主張をどう解釈するかに影響する。社内デモは、特定の環境における特定のプロセスについての証拠である。サポートされる顧客向け機能には、保守、ドキュメント、障害対応に関する追加の約束が求められる。
競争上の圧力は、速度と同じくらい証拠にも関わる。AIモダナイゼーションを語る企業には、何が変革され、受け入れがどのように行われたかを説明する必要性が高まっている。劇的な見出しの割合は、明確に境界付けられた結果ほど有用な情報を提供しない。
この比較はCiscoの物語を現実的なものに保つ。その重要性は、積極的な経営層の支援がAI支援エンジニアリングの到達範囲を広げられるかを試す点にある。Amazonの経験は、この実験をあらかじめ結論づけることなく文脈を与える。
98%という数字は、有用な指標になる前に定義を必要とする
読者が何を完了として数えるのかを知って初めて、モダナイゼーションの進捗率は意味を持つ。
進捗率には分母、すなわち進捗を測る基準となる総量が必要だ。この取り組みでは、ソースコード行数、リポジトリ、アプリケーション、あるいは選定されたコンポーネントがその総量になり得る。報道からは、どの解釈が適用されるのかは明らかではない。
こうした選択により、進捗の見え方は大きく異なる可能性がある。ファイルの再整形は、保守性を変えずに多数のソースコード行に触れることがある。一方で、小規模ながら中核的なコンポーネントの置き換えは、比較的少ないコードにしか影響しなくても、広範な検証を必要とする場合がある。
完了の判定基準も同じくらい重要だ。変更案を生成することは中間段階にすぎない。それをソースリポジトリへ受け入れることは別の段階であり、デプロイと旧実装の廃止にはさらに作業が必要となる。
これは、98%という目標が本質的に不合理だという意味ではない。公開されている説明だけでは、その目標を評価しにくいということだ。読者がこれをエンジニアリング上の予測として解釈する前に、対象範囲と受け入れ基準を知る必要がある。
リファクタリングという表現も、別の測定上の課題を生む。動作の維持はリファクタリングの中核だが、既存テストが検証できるのは、それらがカバーする振る舞いだけである。テストがすべて成功しても、未テストのあらゆる条件が変わっていないことまでは証明できない。
この隔たりが、レビューと運用時の観察が重要である理由を説明する。既存の振る舞いが意図せず失われるリグレッションは、自動テストに含まれていないシナリオで発生し得る。信頼性は、個々の検査を決定的なものとみなすのではなく、複数の証拠を組み合わせることで得られる。
研究もまた、スピード感と測定された生産性を同一視すべきではないと警告している。METRの開発者生産性実験では、経験豊富な開発者16人が、使い慣れたオープンソースプロジェクトで246件のタスクを完了する様子を調べた。2025年初頭のAIツールを利用できるようにしたところ、完了までの時間は19%増加した。
それでも参加者は、ツールによってより速く終えられたと考えていた。この結果は、主観的な利便性と測定可能なデリバリー速度を分けて評価する必要がある理由を示している。Ciscoの結果を予測するものでも、その後のAIツールにも同じ制約があることを立証するものでもない。
METRはその後、この区別を強調した。2026年2月の実験設計に関する更新では、参加者とタスク選定が変化したため、新しい測定結果の解釈が難しくなっていると説明した。研究者らは速度向上の可能性を認めつつ、利用可能な証拠では改善幅を正確に確定できないと警告した。
これらの知見を総合すると、AIコーディングに関する普遍的な結論ではなく、慎重な測定を支持する。ツールの能力は変化し、異なるタスクは異なる制約を露呈させる。使い慣れたオープンソースの保守作業で得られた結果を、大企業のモダナイゼーション計画へそのまま移し替えることはできない。
Ciscoにとって重要なのは、プロセス全体が改善するかどうかだ。レビューや修正で節約した時間を使い果たすなら、生成が速くなっても価値は限定的である。逆に、大量のコードを意図的に変更せずに残したとしても、信頼できるプロセスなら価値を提供できる。
したがって、信頼できる評価では活動と成果を区別する必要がある。変更パッチの提案は活動を示し、受け入れられた変換はレビューを経た進捗を示す。安定したデプロイと保守負担の軽減は、その作業が目的を達成したことを示すより強い証拠となる。
無制限のトークンは、実験に対する潜在的な制約を一つ取り除く。しかし、こうした測定上の問題を解決するものではない。Ciscoが、印象的なデモンストレーションと持続的なエンジニアリング改善をどう区別するかを説明すれば、報じられた目標はより有益な意味を持つ。
小規模チームにも組織の知識へのアクセスが必要だ
この実験の最も強い形は、再設計の自由と、既存ソフトウェアが現在のように動作する理由へのアクセスを組み合わせることにある。
人員配置の話は、単純な世代間対立の解釈を誘う。若い創業者が、大組織が受け入れてきた前提に挑むという構図だ。この枠組みは、報じられた機会の変化を捉えているが、どのエンジニアリング判断が正しいかを確定することはできない。
若さが健全なアーキテクチャを自動的に生むわけではなく、在籍年数が実装を維持する正当性を自動的に与えるわけでもない。有用な区別は、提案が検証に耐えるかどうかにある。小規模チームには、アイデアを試す十分な自由と、結果を解釈する十分な文脈の両方が必要だ。
Krishnamurthyの創業者としての経歴が報じられていることは、この組織上の問いに関係する。スタートアップでの経験は、狭く割り当てられた作業ではなく、問題全体に目を向ける姿勢を促し得る。それでも、変更の影響を受けるシステムを理解することの代わりにはならない。
組織に蓄積された知識は、一見すると非効率に見えるものを説明できる。異例のリトライ手順は、特定の運用条件に対応しているのかもしれない。冗長に見えるチェックは、古い統合を保護している可能性がある。これらは仮説上の例であり、Ciscoのソフトウェアに確認された機能ではない。
可能な限り、こうした説明は検証可能な要件にすべきだ。そうしなければ、モダナイゼーションは古い判断を覚えている人物を見つけることに依存する。理由を記録することで、新しい実装は必要な振る舞いを維持しつつ、元の設計に疑問を投げかけられる。
逆方向の責務も重要である。既存チームは、文書化された要件と、検証されないまま残存してきた慣行を区別すべきだ。障害条件や受け入れ基準を示すとき、反対意見は実行可能なものとなる。
ここでは、エンジニアリング判断に取って代わることなく、経営層の後押しが役立ち得る。リーダーシップはアクセスを認め、責任範囲をめぐる対立を解消し、評価に必要な時間を守ることができる。しかし、熱意によって正しさを確立したり、期限を証拠の代わりにしたりすることはできない。
したがって、小規模チームの最も価値ある貢献は、大量の置換コードではなく、再現可能なプロセスかもしれない。そのプロセスは、提案された変換を関連要件と明確な承認経路に結び付ける。他チームはその後、手順を一から作り直すことなく、同様の作業を評価できる。
この可能性は、提案された人員規模の解釈を変える。コンパクトなチームは、変換手法を開発し、導入を調整する役割を担える。それは、その人たちだけでテスト、セキュリティ、サポート、保守のすべての責任を負えると主張することとは異なる。
また、この話がエントリーレベルの雇用について語れる範囲も限られる。買収した企業の創業者に異例の責任を与えることは、一般的な採用傾向を示すものではない。この事例は、労働市場の結果ではなく、特定の経営判断に関する証拠を提供している。
開発者にとって実務上の示唆は、生成されたコードを取り巻く作業にある。要件を理解し、トレードオフを説明し、証拠を確立することは、草案作成が容易になっても必要であり続ける。プロジェクトが組織の境界をまたぐ変更を試みるとき、こうした責務はより明確になる。
より広く知識労働者にとっての対応物は、文脈へのアクセスである。AIシステムは、以前の判断が重要だった理由を見落としながらも、もっともらしい答えを生成できる。有用な自動化には、その理由を取得し、不確実性を明らかにする仕組みが必要だ。
したがってCiscoの実験は、組織学習の試験でもある。小規模チームが散在する知識を再利用可能な受け入れ証拠へ変換できれば、見通しは改善する。経験豊富な保守担当者を、より速い出力を妨げる障害物としてのみ扱うなら、その見通しは弱まる。
パイロットの証拠、本番受け入れ、保守負担を注視する
次に有益な更新では、何が評価を通過し、誰が受け入れ、その後に何が起きたのかが説明されるだろう。
CiscoのAIコード書き換えは、今後数カ月で具体的な証拠が示されれば評価しやすくなる。報じられた4週間の実証期間は、読者に短期的な参照点を与える。ただし、報道では正確な開始日も、公開発表も確定していない。
最初の兆候は、パイロットの対象範囲と結果の説明である。読者は、特定可能な作業負荷、明示された変換目標、受け入れ基準を探すべきだ。これらの詳細があれば、チームがより広範な目標を代表する何かをテストしたのかが分かる。
成功したデモンストレーションは、成果と限界の両方を明らかにすれば、その主張を強める。たとえば、どの変更に人間による修正が必要だったかを報告すれば、プロセスの実際の要求を把握しやすくなる。これは証拠の基準であり、Ciscoが何を開示するかの予測ではない。
新たに生成されたコードだけを示すデモは、より弱い裏付けしか提供しない。互換性や受け入れについて説明せず、出力だけを示すことになる。長期目標が単独の事例を作ることではなく、既存ソフトウェアを変更することに関わるため、この違いは重要だ。
二つ目の兆候は、本番デリバリープロセスへの受け入れである。読者は、責任を負うチームが範囲を限定した変換を承認し、デプロイしたことの確認を探すべきだ。ロールバック手順、すなわち以前のバージョンへ戻すための定義された方法があれば、プログラムが失敗をどう扱うかも明確になる。
この兆候は、実験を運用上の責任と結び付けるため、モダナイゼーションの主張を強める。影響を受けるチームが、単に称賛するのではなく、作業を評価できることを示すからだ。それでも、承認はそのデプロイの範囲内で解釈する必要がある。
反対に、デプロイを伴わないデモンストレーションが繰り返されても、中核的な疑問は解決されない。プロセスは有用な提案を生成できても、受け入れ要件を満たすのに苦労する可能性がある。その結果は、すべての変換に価値がないことを証明するのではなく、デリバリー上の制約を特定することになる。
三つ目の兆候は、デプロイ後の保守負担である。読者は、その後の修正、サポートの必要性、旧実装を廃止できるかどうかに関する証拠を注視すべきだ。こうした結果は、モダナイゼーションが作業を減らしているのか、それとも単に別の場所へ移しているのかを明らかにする。
安定を保ち、将来の保守を簡素化する変更は、プロジェクトの前提を支持する。広範な継続的介入を必要とする変更は、それを弱める。いずれの結論も、最初の置き換えがどれだけ速く実現したかだけに基づくべきではない。
これらの兆候は、AIモダナイゼーションの主張を評価するエンタープライズの購買担当者にとっても、より良い枠組みとなる。ベンダーに対し、提案された変更とデプロイ済みの変更、デプロイ済みの変更と持続的な改善を分けて示すよう求めるべきだ。報じられた結果を生んだ作業負荷を理解できるだけの詳細を要求する必要がある。
エンジニアリングリーダーにとって、直近の行動は自組織内で範囲を限定した保守課題を検討することだ。既存の受け入れ基準を確立し、その制約を理解する人々を特定し、デプロイまでの経路全体を測定する。生成速度と並行して、レビューと修正に要する労力を比較する。その結果を別の場所で再現する際に制約となる前提を記録する。CiscoのAIコード書き換えが注目に値するのは、経営層の後押しと無制限の実験がソフトウェアのモダナイゼーションをどこまで進められるかを試しているからだ。その最終的な重要性は、当初の熱狂が過ぎ去った後に何が信頼できる状態で残るかにかかっている。次の更新が届いたときには、具体的な問いを投げかけるべきだ。どの受け入れられた変更がソフトウェアを保守しやすくし、その判断を裏付ける証拠は何か。
