10月5日、James Alan Millerが「Self-improving AI is widening what counts as a software change」と題した記事を公開した。この記事では、自己改善型AIの台頭によって「ソフトウェア変更」の定義そのものが拡張されつつあり、CIOが従来のITチェンジマネジメントをどう再設計すべきかについて詳しく論じられている。

コードを変えなくても「変更」は起きる

従来のシステム変更は、コード・設定・インフラのどこかを誰かが書き換えた、という形で識別できた。AIエージェントはその境界を曖昧にする。

プロンプトが変わる。利用するモデルが切り替わる。ルーティングポリシーが変わる。ツールが追加・削除される。スキル、権限、ワークフローが変わる。これらはいずれも、従来のアプリケーションコードをほとんど変更しないまま、システムの振る舞いを変える可能性がある。

AIオートメーションスタートアップのAutohealが構築する「自己改善型ソフトウェアファクトリー」はわかりやすい事例だ。Autohealはソフトウェア開発・運用プロセスの自律的改善を目指す新興企業で、複数のAIエージェントが協調して動作するアーキテクチャを採用している。同社の「Evaluator」エージェントが他エージェントの出力を採点し、「Healer」エージェントがプロンプト・ツール・スキル・モデル選択の改善案を提案する。ただし、この提案は即座に本番に反映されるわけではない。過去のベンチマークでテストされ、Gitでバージョン管理され、エンジニアの承認が必要だ。

つまり「AIが自律的にコードを書き換える」というSF的な話ではなく、AIが既存の変更管理プロセスに組み込まれている、というのが現状に近い。

問題は技術的サイズではなく、ビジネスへの影響

記事が強調するのは、変更の「大きさ」ではなく「影響範囲」で優先度を判断せよ、という点だ。

• 内部サマリーの文言を変えるプロンプト調整 → 影響は軽微
• 顧客への返金可否を変えるプロンプト調整 → 影響は重大
• HRシステムでのモデル変更 → 候補者スクリーニングに影響
• ERPでのワークフロー変更 → 承認フローや金融トランザクションに影響

データ分析・データサイエンス向けプラットフォームを提供するAlteryx（NYSE: AYX）のCIO、Julie Irish氏はTechTargetの取材に対し、「AIエージェントへの監督レベルは、ミスの結果に見合ったものであるべきだ」と述べている。下書きや内部サマリーのような容易に修正できる作業と、送金・データ削除・顧客への連絡・法的権利への影響といったアクションは、別カテゴリで扱う必要がある。

AIプラットフォームベンダーのHarnessは、CI/CDおよびソフトウェアデリバリー管理を手がける企業で、テスト・人間によるゲート・段階的ロールアウト・カナリアリリース・リスクスコアリング・ロールバックといった従来型のソフトウェアデリバリー管理を、非決定論的なAIエージェントに適用しようとしている。コントロール手法は馴染みのあるものだが、何をコントロール対象とすべきかの判断が難しくなった、というのが本質的な変化だ。

「証拠は十分か」より「どこまで変更を許可するか」

AIが提案する改善案を承認する際、「この証拠は十分か？」という問いより、「この証拠はどの範囲の変更を正当化するか？」という問いの方が実用的だと記事は指摘する。

過去のテストで新バージョンが優れた結果を出したとしても、それは「すでに知っている条件」での評価に過ぎない。本番では未知の条件が待っている。

そこで提案されるのが、スコープを段階的に切る考え方だ：

• 影響が小さく可逆性が高い変更 → 広い適用を比較的少ない証拠で正当化できる
• ERP承認・顧客返金・雇用判断・金融トランザクションに関わる変更 → より厳格な証拠と限定的な適用範囲が必要
• 影響範囲が広すぎる変更 → いったん分割して管理可能な単位に落とす

「証拠は確実性を買うものではなく、スコープを買うものだ（evidence should buy scope, not certainty）」というフレーズは記事のキーコンセプトといえる。

人間の承認ゲートを設けることは有効だが、それも万能ではない。自動化ポリシーで「テストをパスしたから本番デプロイ可」とする場合でも、「どのテストが有効か」「合格基準は何か」「どの程度のリスクを許容するか」を誰かが決定しなければならない。判断がなくなるわけではなく、判断の所在が変わるだけだ。

また、承認は一度きりでは不十分な場合もある。承認時点では合理的だった変更が、6ヶ月後には別のモデルや業務ルール、下流システムとの組み合わせで動いているかもしれない。承認は永続的な許可を意味しない。

再構成と監査証跡

プロンプト・モデル・ツール・権限・ワークフローがすべて変更対象になる以上、「何かが起きたとき、当時どの設定で動いていたか」を追跡できることも必要になる。

DomoはBIおよびデータ可視化プラットフォームを提供する企業で、同社の最近のアップデートはその一例だ。パイプラインのバージョン管理機能が追加され、エージェントやアシスタントが開始したプロセスの可視性が向上した。MCP（Model Context Protocol）トリガーにより、エージェントがどのタイミングでプロセスを開始したかも識別できる。MCPはAnthropicが策定したオープンな標準仕様で、AIモデルと外部ツール・データソースを接続するためのプロトコルとして業界での採用が広がっている（公式ドキュメント）。

監査証跡として必要なのは、元のタスク・使用した情報・実行したアクション・受けた承認・関与した他エージェント・最終的なビジネス上の結果、をつなぐ記録だ。

CIOへの実務的含意

記事の結論は明快だ。自己改善型AIは既存のチェンジマネジメントを捨てる理由にはならない。バージョン管理・テスト・段階デプロイ・人間によるレビュー・ロールバックは引き続き機能する。

変わるのは「変更」の定義そのものだ。CIOに求められるのは、AIシステムが改善されることを止めることではなく、「既知の条件下でうまく機能した」という証拠を、「どこでも・何にでも・永続的に適用してよい」という証明と混同しないことだ。

詳細はSelf-improving AI is widening what counts as a software changeを参照していただきたい。